我为 AI 编程代理写了 50 多个技能——真正管用的只有这 5 条规则
过去几个月，我为 AI 编程代理写了 50 多个技能（SKILL.md 文件）：股票分析流程、内容生成系统、文档转换工具，甚至还有一个 GitHub 趋势聚合器。网上那些所谓的「最佳实践」，真用起来大部分都不靠谱。下面这 5 条规则，是经历了实战检验后幸存下来的。
规则一：技能文件要短。3 条原则胜过 13 个框架
我写的第一个技能文件是个 174KB 的庞然大物——里面塞了 13 个写作框架、学术理论和 40 个示例。代理加载它之后，每次产出都是千篇一律、毫无灵魂的内容。
问题不在于技能太复杂看不懂，而在于太重、根本没法照着做。当大语言模型（LLM）把 174KB 的内容一次性丢进上下文时，它只会机械地匹配表面形式，完全忽略实质内容。
我把这个技能重写为 3 条原则加 5 条硬性约束，输出质量立刻提升了。技能文件应该能装进脑子里——如果它长到需要目录，那它是一本书，不是技能。
规则二：硬性门槛比长篇指令更管用
大语言模型（LLM）在遵循「确保质量要高」这类抽象要求时表现很差，但执行具体脚本却很擅长。
所以我不再写「标题必须有吸引力」，而是写：
- 标题评分 ≥ 6.5，否则不发布
- 文章至少包含 2 张图片，发布前用
grep -c '!\['验证 - 先抓取真实市场数据；拿不到新数据就跳过发布
空泛的建议会被忽略，但门槛脚本无法无视。设计技能时，要围绕「失败时能明确报错」的检查点来做。
规则三：接口设计比示例更重要
上下文工程（context engineering）的转向是真实存在的：设计一套干净的工具参数模式，对代理性能的提升远大于写 10 个调用示例。
我花了 30 分钟重构某个 API 的参数结构，而不是去补写更多文档，结果代理就不再犯同样的错误了。示例是教学，接口是约束。约束胜出。
规则四：技能应该承载你的判断，而不是通用知识
通用知识该放在文档里。技能应该承载的是你的观点——那些你交了学费、踩了坑才领悟到的教训。