我把现在用来写公众号的 Skill 重新打开，认真数了一遍。
217 行，12 个模块，87 条项目符号。
里面写了什么题值得做，标题不要怎么起，开头应该出现什么，第一人称不能虚构哪些经历，配图要提供什么信息，甚至连"真正的问题不是 A，而是 B"这种常见 AI 句式都单独列进了禁用清单。
照理说，规则已经够细了。
可文章写出来，偶尔还是会出现熟悉的味道：段落过于整齐，每一节都像在交作业，结尾又忍不住升到行业、责任和未来。人工改完这一篇，下一篇换个题，它又可能从另一个角落长回来。
以前我会继续补规则。发现一句不自然，就往 Skill 里再加一句"禁止这样写"。
这次读到《深入理解 AI Agent：设计原理与工程实践》里关于动态提示词和 Agent Skills 的章节，我才意识到，也许我一直在修错地方。
Skill 不是一张贴在模型面前、模型必须逐字遵守的规章制度。它更像一本放在书架上的操作手册。
手册写得再厚，也要先被找到、被拿下来、翻到正确那一页，最后还得有人检查新人是不是真的照着做了。
任何一步没发生，继续往手册里加第 88 条规则，都不会让结果变好。
材料中的图 2-11：Agent 先看到 Skill 元数据，匹配任务后读取核心流程，需要时再进入子文档和脚本。来源：《深入理解 AI Agent：设计原理与工程实践》第 2.5 节。
第一种失效：它根本没有被叫过来
Skill 文件最上面的 description，常常比下面两百行正文更重要。
模型启动时不会把所有 Skill 的完整内容都背下来。按照 Agent Skills 的渐进式披露思路，常驻上下文里的通常只是名称和一小段描述。模型先用这份目录判断当前任务是否与某个 Skill 有关，命中之后，才加载完整的 SKILL.md。
Anthropic 当前的官方文档写得很直接：description 是 Claude 判断是否触发 Skill 的匹配依据，所以它必须同时说明"做什么"和"什么时候使用"。OpenAI 的开发者页面也已经把 Skills 与 MCP、UI 一起列为扩展 ChatGPT 和 Codex 的插件组成部分。
这里最容易犯的错误，是把 description 写成产品介绍。
比如："帮助创作高质量公众号文章。"
听起来没错，但它没有告诉 Agent，用户说哪些话时该触发，也没有说明改稿、排版、发布和复查算不算范围。模型面对"这个标题太像 AI 了，重写一下"时，完全可能把它当成一个普通改写任务，直接凭通用能力处理，而不是加载整套公众号规则。
我们当前的公众号 Skill 也有类似的历史痕迹。它的 description 仍然把核心对象写成 programmers，后面列 Codex、Claude Code、Cursor 对比和程序员职业变化。可账号现在已经在扩展到产品、运营、管理者和其他使用 AI 工具的人。正文里即使写了更宽的选题方向，入口描述没有同步扩大，路由判断仍可能停在旧定位上。
这解释了一个让我以前很困惑的现象：我明明"写进 Skill 了"，结果却像完全没写。
因为那段规则可能一直躺在文件里，根本没有进入本轮上下文。
一篇文章没有遵守 Skill，不一定是模型公然违反规则。先确定它失败在哪一层。
第二种失效：它被加载了，但拿到的是一整间仓库
我们的公众号 Skill 没有长到离谱。
217 行仍低于 Anthropic 官方 skill-creator 给出的"500 行以内较理想"的经验建议。只看文件长度，很难断言问题就在"太长"。
但它有另一个更实际的问题：内容是平铺的。
选题比例、候选评分、资料研究、文章类型、标题示例、正文语气、去 AI 味、配图、HTML、草稿发布和验证，全放在同一个 SKILL.md 里。
当我只是问"今天写什么"，发布命令和 HTML 配色也会一起加载；当我只想把现有文章上传草稿箱，选题方法和几十个标题示例仍然跟着进来。
这些规则都没有错，只是它们不该每次同时出现在模型眼前。
材料里把 Skills 的加载分成三层：先看元数据目录，再读核心流程，最后才按需要打开参考文档、模板或脚本。Anthropic 当前的官方 skill-creator 也采用相似结构：主文件负责工作流和选择逻辑，细节进入 references/，确定性的重复操作进入 scripts/，模板与素材进入 assets/。
这套结构省下的不只是 token。
更重要的是，它减少了本轮任务里同时竞争注意力的规则数量。
写文章时加载选题与文风；做配图时再加载视觉规则；准备发布时才读取微信上传和验证流程。模型看到的每条规则都与眼前动作有关，反而更容易执行。
我现在更愿意把 Skill 主文件看成目录加主流程，而不是一部百科全书。
不是删除规则，而是让规则在真正需要时出现。主文件越像清晰的路线图，细节越适合进入按需资源。
第三种失效：写的是审美愿望，不是可执行动作
"像人写的。"
"有感情一点。"
"不要太 AI。"
这三句话，人看了也知道方向，真要逐句修改时却很难执行。
什么叫像人？是少用小标题，还是允许一句话单独成段？什么叫有感情？是增加惊叹号，还是写出作者在某个具体后果面前的犹豫？"AI 味"又指标题公式、均匀段落、抽象名词，还是虚构的第一人称经历？
如果 Skill 只写审美目标，模型只能用自己对这些词的平均理解去补空白。平均理解生成的，往往正是我们不喜欢的平均文章。
当前 Skill 已经比早期版本进了一步。它列出了不能虚构同事、生产事故和实测数据，也点名了一些高频 AI 句式，还要求每节至少出现具体场景、个人判断、真实不确定性或代价。
但在文风这件事上，禁用清单仍然比段落级的正反例更完整。
模型知道"不要写什么"，不一定知道遇到同一信息时"应该改成什么"。
最有价值的材料不是再写一句"开头要抓人"，而是保留一段原稿和人工改稿：哪句背景被删了，哪个抽象判断换成了工作现场，哪里故意留了一句短句，哪些事实因为没有证据而降级成了判断。
修改痕迹比形容词更接近操作说明。
这也是原材料第 2.5 节给出的一个实用方法：从几篇真正满意的原创文章开始，让 Agent 归纳初版规则，再用它处理新题目。作者逐句改稿，把反复出现的修改整理回 Skill，同时为规则保留正例、反例和适用范围。
不是让模型模仿几句口头禅，而是让它看见判断过程。
第四种失效：文章写完了，却没人知道规则到底有没有用
Skill 最容易制造一种虚假的完成感。
文件建好了，YAML 没报错，Agent 也说"我会遵循这些要求"。我们便默认它已经生效。
可真正需要回答的是两件事：该触发的时候，它触发了吗？触发以后，结果真的更好吗？
Anthropic 官方的 skill-creator 已经把测试放进创建流程：先准备几条真实用户会说的话，再观察触发情况和输出结果。它甚至建议对 description 做训练集与保留测试集的重复评估，而不是凭作者看一眼就判断路由写得好不好。
写作 Skill 很难像代码那样用一个单元测试断言"自然度等于 90 分"，但并不等于完全不能测。
我会为公众号 Skill 保留三组提示：应该触发的、容易漏触发的，以及明确不该触发的。
"写一篇 Codex 新功能的公众号文章"应该触发；"这篇标题太像 AI 了，保留主题重写"也应该触发；"帮我给同事写一句请假消息"则不该把整套公众号工作流叫进来。
输出测试也不必追求一个神奇总分。可以固定检查标题是否含具体冲突，前 150 字有没有工作场景，是否虚构经历，是否提供可收藏资产，以及禁用句式有没有重新出现。
最后再保留人工盲评。
同一个题目生成两版，隐藏哪一版用了新 Skill。只问一个问题：哪一篇更像这个账号会发的文章？
如果答案长期没有区别，Skill 写得再漂亮也只是文档工程。
先测触发，再测输出。把"感觉这版好一点"变成可重复检查的样本。
我准备怎么改这份公众号 Skill
这次我不会再给它追加第 88 条项目符号。
主文件只保留路由、核心工作流、三到五条不可妥协的原则，以及每个阶段应该进入哪份参考资料。选题、文风、配图、排版和发布各自进入独立文件，需要时再读。
description 会从"面向程序员的工具文章"改成更准确的触发条件，覆盖选题、写作、改稿、去 AI 味、配图、排版和公众号草稿发布，同时明确普通短消息和非公众号写作不应触发。
文风规则不再只积累禁用词。我会保存几组真实的原稿与人工修改稿，记录为什么删、为什么换、什么情况下允许例外。
最后补一组固定测试。每次大改 Skill，不先拿当天文章试运气，而是重跑相同的触发样本和写作样本，再决定新版是否真的更好。
这张检查单可以用于写作、代码审查、数据分析等不同类型的 Skill。规则数量排在最后，路由和验证排在前面。
我现在不再问"Skill 里还缺哪条规则"。
我会先问：它这次有没有被叫来？加载的是不是当前需要的部分？规则能不能转成动作？写完以后，有没有证据说明结果真的变好了？
四个问题里只要有一个答不上来，继续把手册写厚，意义都不大。