轻量化Skill生成工具推荐：zao-skill全流程评测
最近一直在调试 Skill，连写了几个长流程。坦白说，写得越多，违和感越强。
流程拆得够细了，规则也列得门儿清，但 AI 跑起来就是——这里漏一条，那里跳一项。纠正一次，下次换场景又忘。反复纠正，反复遗忘。
你肯定也撞过这个墙。写过龙虾 Skill 的人，没人能逃掉这个坑。
根因在哪？一开始我怀疑自己写得不够细，后来才意识到根本不是。
龙虾为什么失控
先给结论：这不止是记忆短板。
龙虾加载你的 SKILL.md 后，会把它塞进上下文。关键在于——文件只在会话启动时加载一次，之后所有操作依赖的是那次加载的快照（frozen at load time）。
你执行中途改了文件、加了规则，AI 完全不知情。它还在拿旧版本做决策。
这就是 AI "失控"的根本原因之一。不是它不想配合，是它耳朵里的指令集压根没刷新。
还有一层问题——Lost in the Middle。Transformer 对上下文开头和结尾注意力最高，中间段容易被忽略。你的关键规则如果卡在文档中部，AI 大概率没读到。
再加上规则写得太模糊："要考虑边界情况"——这种话 AI 看了等于白搭。需要的是"当 X 发生时执行 Y，当 Z 发生时执行 W"这种确定性描述。
所以，如果只抓一个根因，那就是——Skill 没造好。
但怎样才算"造好"？这件事值得从头理一遍。
从始祖技能的一个小bug说起
一切得从 Skill Creator 说起。龙虾自带的"始祖技能"，专门教你如何写 Skill。
用了一阵子，发现一个有意思的细节：Skill Creator 自己提了很多好规范——渐进式披露、精简内容、Non-Duplicate——但它自己并没严格执行。正文和参考文件大量重复，说明文字和规则混在一起，结构相当臃肿。
上一篇【技能下载不是终点】里写过这个发现。当时觉得是小毛病，优化一下就行。
结果在自己写长流程 Skill 时，这个"小毛病"被放大了无数倍。按 Skill Creator 的规范写出来的东西，依然不够稳。
看来始祖技能真的需要迭代了。
行业调研：大家都在怎么干
决定从根上找解法。先看市面上的方案都在做什么：
| 方案 | 特点 | 适合谁 |
|---|---|---|
| Claude Code 2.0 (2026.4) | 强调自动化测试和自更新 | 发布给别人用的技能开发者 |
| 达尔文 Skill | AI自测自改进，循环迭代 | 需要持续优化的重度用户 |
| Skill Creator v0.1.0（内置版） | 文件夹布局、背景规范详细 | 新手入门，但主体怎么写没讲 |
| Matt Pocock / Garry Tan 实践 | 最佳实践、优化理念 | 有经验的开发者 |
调研了一圈，发现一个共性问题：大家都在解决"能写出来"，没人解决"写得稳、AI不乱跑"。
Claude Code 2.0 那套太重了——自动化测试、多轮验证、输入输出对照、循环迭代——结构复杂，资源消耗大。适合做通用分发的技能，不太适合自己写自己用。
内置 Skill Creator 则相反：给了大量背景介绍，但Skill 主体怎么写反而没讲。可能设计者想留自由度，但恰恰是这种自由让 AI 容易跑偏。
于是，自己攒了一套方案。
zao-skill诞生：先减法，后加法
项目起点是 Skill Creator V0.1.0（2026年1月27日）。分两步走。
减法：三轮精简
第一轮：自我合规。 让 Skill Creator 按自己提出的规范改造自己——落实渐进式披露、精简内容、弱化教学属性。你定的规矩，你先遵守。
第二轮：Non-Duplicate 硬约束。 所有内容必须具备唯一价值，禁止冗余、可替代、可合并的信息。人工逐段精读，逐句校验——AI 识别不了隐性冗余，这事只能人做。
第三轮：终极精简。 人工 + AI 双审，把框架压缩到最小可用核心版本，只保留必要、有效、对执行有决定性作用的内容。
三轮下来，文件瘦了一大圈，结构也清楚了。
加法：对标行业标准
精简完开始做加法。对标 agentskills.io 通用规范、Claude Code 2.0，参考 Matt Pocock、Garry Tan、Addy Osmani 的理念，融合达尔文 Skill、黄叔 Skill 等国内实战经验。
加法不做"能写出来"的事——那已经是共识了。做的是 "写得标准、写得稳定、AI不乱跑、可长期迭代" 的事。
具体的五阶段工作流：
Pre-Step Rationalization Bias Check（全阶段强制前置）
│
▼
User Need?
├─ Create new skill→ Phase 1: Design
├─ Draft / update→ Phase 2: Drafting
├─ Review / validate → Phase 3: Validation
└─ Package for release → Phase 4: Packaging
│
▼
技能发布 → 实际使用 → Evolution in Usage（自进化）
最特别的是第一阶段——先跑 Workflow，再写 Skill。
在没形成正式技能文档前，要求你先跑通整个业务流程，验证逻辑可行、无断点、无歧义。所有讨论决策、对标结论、首次试运行的记录统一存到 WIP 目录，Phase 2 写技能时只读这个文件就够了。
这一条是从源头防错的。很多技能不好用，不是写得不好，是设计本身就漏了。
三层防偏：让AI漂移不了
这里重点说两个设计。
Critical Directives 原则声明
Files Are the only Truth。—— 原来单纯依靠 Rationalisation rebuttals 的静态表格提醒，在实践中依然会被AI忽略，当作背景不被重视。
通过第一层命令式的原则声明，先让AI摒弃依赖记忆和上下文的陋习。上下文加载后，在长期项目里，十分容易因为各类文件更新而不及时替换更新，产生上下文腐烂的问题。
对此，通过再加两层控制，来进一步管控这个边界问题。
Pre-Step 三步门控
所有阶段执行前，强制过三步：
- Re-read — 重读当前文件，不依赖记忆和旧上下文
- Follow references — 完整读取所有参考，不跳步
- Check completion — 复核完成度，不提前闭环
写在工作流每一步前面，AI 想跳都跳不过去。
三层自加固防偏架构
同样的偏差知识，在不同位置重复强化：
| 层级 | 做什么 |
|---|---|
| 原则层 (Files Are Truth) | 让AI知道"文件是唯一权威，上下文快照是过时的影子" |
| 执行层 (Pre-Step Bias Check) | 每步强制操作，不信任任何上下文 |
| 反馈层 (Gotchas G01–G03) | 真实错误案例记录，让AI看到"前人踩过的坑" |
这三层用的是同一套偏差知识——原则层定调、执行层强控、反馈层回看，形成一个 AI 跨不过的网格。
弃测试，做校验，靠真实场景进化
行业主流方案都在做重型自动化 Testing。这里的选择不同——不做 Testing，做强 Verification（校验），把测试直接留给使用中的积累和迭代。
校验分双轨：
- Static Check：机器自动检查语法、格式、结构、排版、冗余。自动修正。
- Interactive Check：人机交互核对逻辑合理性、场景适配、边界完整性。
既避免了重型测试的臃肿，又保证了质量。
那测试没覆盖的问题怎么办？靠真实场景进化。
模式：早用 → 用了记 → 记了改。问题分级归档——轻的写进 Gotchas，重的升级到 Critical Directives。同时沉淀 Success Pattern，好的经验也记下来。
关键支撑：全程 Git 版本管控。 每次优化、每次出错、每次迭代都有迹可查、可回滚、可复盘。长期使用中的隐性问题、回归问题、行为变动，离开了 Git 历史很难定位根因。
和前置有限测试不同，真实场景可以覆盖无限复杂的业务情况。技能越用越稳，越用越准。
总结
写到这里，可能有朋友会想：为写个 Skill 搞这么复杂，有必要吗？
说实话，两三步的小流程确实不需要。但如果你要做多路径、多参考文件、复杂边界的 Skill，这些投入很值。
zao-skill 的核心脉络：
- 先跑流程再写技能——源头防错
- Files Are Truth + Bias Check + Gotchas 三层防偏——原则层定调，执行层强控，反馈层回看
- 细化工作流书写规范——AI 不偷懒、不跳步
- 轻量化校验——不做重型测试，高效低成本
- 分层式自进化体系——分级记错，沉淀成功范式
- Git 工程化保障——可追溯、可复盘、可迭代
如果你也在写 Skill 的路上踩过坑，不妨试试这套思路。把技能这件事，真正搞得更稳、更可靠。
参考资料：
- zao-skill 项目：github.com/Sensenkawa/zao-skill
- 腾讯云 Claw 竞赛：tch.cloud.tencent.com/claw
- 前文：技能下载不是终点——Skill Creator 的优化思路