50+ Skills实战总结：AI编程Agent技能设计的5条核心规则

在过去的几个月里，我为 AI 编程智能体构建了 50+ 个 skill（SKILL.md 文件）：股票分析流水线、内容生成系统、文档转换工具，甚至还有一个 GitHub Trending 聚合器。我在网上读到的大多数"最佳实践"在实践中被证明是错误的。以下是经过实践检验的 5 条规则。

规则 1：保持 skill 简短。3 条原则胜过 13 种框架

我的第一个 skill 是一个 174KB 的庞然大物——13 种写作框架、学术理论、40 个范例。智能体加载了它，每次都输出千篇一律、毫无生气的内容。这个 skill 不是复杂到难以理解，而是太沉重以至于无法执行。当 LLM 把 174KB 塞进上下文时，它只匹配表面模式，忽略了实质内容。

我重写成了 3 条原则和 5 条硬约束。输出质量立即提升了。一个 skill 应该能装进你的脑子里——如果你需要目录，它就是一本书，而不是一个 skill。

规则 2：硬关卡胜过长篇指令

LLM 不擅长遵循"确保质量很高"这类话。它们很擅长执行脚本。所以我没有写"标题必须吸引人"，而是写成：

标题得分 ≥ 6.5，否则不发布

文章至少 2 张图片，发布前用 `grep -c '![' 验证

先获取真实市场数据；如果没有新数据，则完全跳过发布

软性建议会被忽视。关卡脚本无法被忽视。围绕检查点设计 skill，这些检查点会大声失败。

规则 3：接口设计胜过示例

上下文工程转向是真实存在的：设计一个干净的工具参数 schema 比写 10 个如何调用的示例对智能体性能提升更大。当我花 30 分钟重构一个 API 的参数而不是写更多文档时，智能体就不再犯同样的错误了。示例教会你；接口约束你。约束取胜。

规则 4：Skill 应该编码你的判断，而不是通用知识

通用知识属于文档。一个 skill 应该编码你的观点——你用失败换来的教训。我最好的 skill 不是引用最多的那个，而是"这里什么坏了以及为什么"注释最多的那个。当你把通用知识复制到 skill 里，你只是在搬运字节。当你编码来之不易的教训时，你在积累经验。

规则 5：将 status: ok 视为不可信

自主智能体最危险的失败模式不是崩溃——而是在错误的方向上悄然成功。我的 cron 智能体在连续数周报告 last_status: ok 的同时，产出的是零价值输出。只看退出码的健康检查只是表演。

现在，每个流水线都有验证层：运行前后的状态指纹、每个发布操作的收据，以及只消费 diff + 信任边界——而不是完整作者上下文的审查者。继承了作者完整上下文的批评者只是一个有观点的格式化器。

这些规则衍生出的技术栈

A-Share Stock Analysis Expert——一个三支柱系统（技术面：MACD/KDJ/RSI/量价；基本面：ROE/PEG/巴菲特比率；情绪面：资金流向、热钱追踪）。构建为智能体 skill，任何编程智能体都可以运行完整的市场扫描。

GitHub Trending Daily——一个零成本、零 API 的聚合器，每 6 小时自动更新一次，这样我的智能体在决定学什么之前总是知道什么最热门。

Humanizer——一个文本去 AI 化工具，移除 24 种最常见的 LLM 写作模式。因为如果你要发布智能体生成的内容，它最好不要读起来像智能体生成的内容。

所有这些都运行在免费 API 和我自己的 GPU 上——没有 SaaS 订阅，不需要购买 API 密钥。

如果你在为 AI 智能体构建 skill，试试这些：https://github.com/Felixwang007——所有内容都是开源的。如果你想要一个 5 分钟内能用的三支柱扫描器，也可以在 skill 市场获取 A-Share Stock Analysis Expert（在香港的 xiaping.coze.com 上搜索"A-Share Stock Analysis"）。

有问题或反例？欢迎在评论区留言——我真心好奇这些规则中哪些在你那里不适用。