人生复利系统课，第4节。
我写完第一个Skill，用了三天就觉得不对劲。
那个Skill是「每日AI新闻速递」，每天爬几个网站、翻译、整理、输出一份日报。头一回写的时候，把所有逻辑都塞进一个SKILL.md文件里，洋洋洒洒写了800行。
调用的时候，AI加载800行内容，光是理解就要花十几秒。执行的时候又发现，有些脚本报错了，AI不知道怎么处理，直接把原始错误信息吐出来，我看得一头雾水。
还有个更大的问题。
我用了两周，发现几个新需求：想加几个新网站、想改输出格式、想让脚本在失败的时候自动重试。改了一轮，SKILL.md从800行变成了1200行。每次调用，AI加载更慢，执行更不稳定。
我开始怀疑，Skill是不是写完就不管了？
后来我明白了。Skill不是静态文档，是活的。用着用着发现问题，回去改，改完永久生效。但改的方式不对，Skill会越改越臃肿，越改越难用。
正确的迭代方式，是让Skill越用越聪明，而不是越用越笨。
渐进式披露：让Skill轻装上阵
我之前的问题，本质上是把所有东西都塞进一个文件里。
SKILL.md应该是入口和导航，不是百科全书。
想象一下。你要去一个城市旅行，拿到一本500页的导游手册，从头读到尾再出发，太累了吧？好的导游手册，给你一张地图、几个核心景点、几条推荐路线，剩下的「周边美食详见附录A」「交通攻略详见附录B」。
你先看核心信息，需要的时候再翻附录。这就是渐进式披露。
Skill也一样。
核心步骤、触发条件、输出格式，写在SKILL.md里。详细的参考资料、脚本说明、错误处理逻辑，拆成独立文件。AI加载SKILL.md先抓住核心，需要深入了解某个环节的时候，再去读引用文件。
这样有几个好处：
- 加载快。AI不用每次都读几百行内容，先读核心部分，按需要深入。
- 改动方便。改一个脚本，不用动SKILL.md，改完直接生效。
- 结构清晰。回头看的时候，一眼就知道这个Skill有哪些模块。
一个好的Skill目录长什么样
渐进式披露的核心原则，是让文件按需加载。
一个Skill的目录，可以随着功能扩展逐步演化：从单一文件 → 多个参考文件和脚本组成的结构。
我之前做的daily-ai-news，最终目录是这样：
daily-ai-news/
├── SKILL.md # 入口文档，200行
├── references/
│ ├── platform-strategies.md # 各平台的抓取策略
│ └── search-keywords.md # 关键词库
├── scripts/
│ ├── fetch-news.sh # 抓取脚本
│ └── format-output.py # 格式化脚本
└── evals/
└── evals.json # 测试用例
SKILL.md只有200行。核心内容是：
- 身份卡
- 触发条件
- 输出格式
- 执行步骤的概要
- 各模块的引用链接
详细的平台抓取策略、关键词库、脚本参数，都在引用文件里。AI先读SKILL.md，需要的时候才去读platform-strategies.md或调用fetch-news.sh。
有个原则要注意：避免链式引用。
什么是链式引用？SKILL.md引用A.md，A.md又引用B.md，B.md又引用C.md。AI读SKILL.md的时候，可能只读了一层就停了，后面两层根本没加载。
好的引用深度是一层。所有引用文件直接由SKILL.md链接，不要让引用文件再引用别的文件。
工作流：让AI按步骤走，而不是瞎摸索
我的另一个问题，是执行的时候AI不知道怎么处理报错。
我的Skill有个脚本，调用失败的时候，AI直接把原始错误信息吐出来：「Error: Connection timeout after 30s」。
我看得一头雾水。30秒超时是什么意思？是网站挂了还是网络问题？下一步该重试还是换网站？
AI不知道，因为SKILL.md里没写。
这就是工作流的价值。工作流约束AI按步骤走，每一步该做什么、遇到问题该怎么处理、下一步该怎么走。
一个简单的工作流模板
工作流的核心，是「步骤 → 验证 → 下一步」。
可以在SKILL.md里写一个清单，让AI按步骤走：
## 执行工作流
- Step 1：从HN API抓取最新AI话题
- Step 2：验证数据是否完整（至少5条）；若不完整，返回Step 1重试
- Step 3：格式化为Markdown表格
- Step 4：输出日报文件
- Step 5：检查文件是否生成成功；若失败，返回Step 3重新格式化
每一步都有明确的动作，有验证标准，有失败后的处理方式。
AI调用的时候，会按这个清单走。Step 2发现数据不完整，它知道返回Step 1重试，而不是直接报错。Step 5发现文件没生成，它知道返回Step 3重新格式化，而不是告诉你「出问题了」。
这就是反馈闭环。
验证发现问题，回到之前的步骤修正，再验证，直到通过。AI不再是被动执行，是主动检查、主动修正。
分析类任务的工作流
不写代码的Skill，也需要工作流。
举个例子。做一个「技术方案评估」Skill，帮你在两个方案之间做选择。SKILL.md里可以写：
## 技术方案评估工作流
- Step 1：明确业务目标与技术约束（性能、成本、时限）
- Step 2：列出所有可行的技术方案
- Step 3：从复杂度、可维护性、风险角度逐一评估
- Step 4：对关键差异点进行对比分析
- 若发现关键信息不足，返回Step 2或Step 3补充分析
- Step 5：给出结论性建议，并说明取舍理由
- 若结论无法支撑目标约束，重新审视Step 1的前提条件
Step 4和Step 5都有反馈闭环。发现信息不足，回到前面的步骤补充。发现结论无法支撑目标，重新审视前提条件。
AI按这个流程走，评估质量就稳定了。不会有时候深入、有时候草草收场。
脚本的加固原则：让失败可预期、可处理
第三个问题，是脚本报错的时候AI不知道怎么处理。
我写了一个抓取脚本fetch-news.sh，调用失败的时候直接抛异常。AI拿到原始错误信息，不知道下一步该做什么。
脚本要加固。加固的原则是：失败可预期、输出可理解、参数可解释。
失败可预期：不要让AI猜
脚本要覆盖常见错误场景，把技术异常转化为可理解、可决策的输出。
举个例子。脚本调用一个API，超时了。原始错误信息是「Error: Connection timeout after 30s」。AI看到这个，不知道下一步该做什么。
加固后的输出可以是：
ERROR: API调用超时（30秒）
可能原因：
1. 目标网站响应慢
2. 本地网络不稳定
3. API服务器负载高
建议下一步：
1. 重试一次（timeout已设置为30秒）
2. 检查网络连接状态
3. 等待5分钟后再次调用
AI看到这个，就知道下一步可以做什么了。
输出自解释：让AI理解发生了什么
脚本的输出本身就是AI的上下文。好的脚本不光说明发生了什么，还说明为什么、接下来可以怎么做。
举个例子。脚本检查环境依赖，发现Node.js版本不对。原始输出是「Error: Node version mismatch」。
加固后的输出可以是：
CHECK FAILED: Node.js版本不匹配
- 要求版本：>= 18.0.0
- 当前版本：16.14.0
可选方案：
1. 升级Node.js到18.0.0或更高
2. 使用兼容的构建镜像
3. 调整项目的Node.js依赖配置
AI看到这个，就知道有三个方案可选，而不是只知道「出问题了」。
参数可解释：让数字有来由
脚本里的常量，比如TIMEOUT=30，如果缺乏解释，AI和人都不知道它是否合理。
加固的方式是给常量添加语义化名称，说明来源或依据：
TIMEOUT_SECONDS = 30 # 服务启动通常10-20秒完成，30秒是安全余量
或者在输出中体现：
INFO: 等待服务启动（timeout: 30秒，基于历史数据：平均启动时间12秒）
AI看到这个，就知道30秒不是随便定的，有依据。
用AI来迭代：你负责验收，AI负责试错
说完了结构和工作流，最后讲一个实战方法。
迭代Skill的时候，可以多用AI。你负责定义问题和验收结果，AI负责反复试错、总结规律并封装成可复用的Skill。
有个方法我常用。遇到一个具体任务，比如写公众号文章、做项目复盘、评估技术方案，先把完整目标和上下文告诉AI，让它自己尝试。
执行过程中的追问、走偏、修正，本质上就是一次隐式评测。看到AI哪里走偏了，就知道Skill哪里写得不够准。
任务完成后，让AI复盘一遍：成功执行的完整步骤是什么？中间在哪些地方卡住了？哪些判断逻辑可以固化下来？这个方法适用于哪些场景、不适用于哪些场景？
复盘完，让AI按Skill规范把SKILL.md写出来。快速扫一遍，看看边界划得对不对、步骤是不是能照着做。确认没问题，就入库。
Skill用久了，会冒出新问题。让AI分析一下问题卡在哪：触发条件写得不够清楚？输出要求说得不够细？执行步骤漏了什么场景？
找到原因，直接改SKILL.md。改完验证两件事：原来能跑通的主流程，这次改动有没有影响？新发现的错误场景，有没有覆盖到？
迭代不是瞎改。改完跑一遍，跑通了再往下走。
Skill会自己长大
回到我之前的问题。
我回去改了一轮。SKILL.md从1200行压到200行，详细的策略和脚本说明拆到引用文件里。工作流也加了，每一步都有验证标准，失败了AI知道该干嘛。脚本也加固了，报错的时候会给建议，而不是甩一堆原始日志。
改完之后，调用从十几秒变成几秒。执行也稳了，报错的时候AI能自己修正。
有个现象挺有意思：改一轮，永久生效。以后每次调用，用的都是新版本。
迭代就是这个意思。用着用着发现问题，回去改，改完Skill就强一点。下次调用，AI用的是更强的版本。
改一遍，永久生效。
从初版到好用，可能要改三五轮。但每改一轮，Skill就离真实的方法论更近一步。
迭代的节奏
我的建议是：别等Skill完美了再用。先写个能跑的版本，用几次，发现问题就改，发现有价值的点就加。
迭代是有节奏的。初版写完，先用个三五次，核心问题就冒出来了。第一轮改完，把脚本加固。再用十天，新需求、新边界会出现。第二轮改完，功能补齐，边界也诚实了。用一个月，会发现工作流其实还能更顺。第三轮改完，步骤简化，反馈闭环也更干净。
