Skill 是说明书还是 SOP

一句话结论：skill 该详尽的是执行者推不出来的事实，该写死的是错了收不回的边界，其余流程能省则省。“写多细”之争往下追，是委托中规范与判断的老问题在 agent 时代又出现了一次；答案不是常数，而是随执行者能力移动的函数。

为什么写这篇

一个内部工具的接入信息被写成共享 skill 后，主文件里出现了六步固定流程：先健康检查、再查账号、再定位会话。这六步来自一次成功的排查，却被写成了所有任务的必经关卡。问题不在细节够不够，在于一次经验被升格成了通用路径。同样的倾向在公开讨论里也能看到：GitHub 上有人批评 skill“重步骤、轻意图”，skill-creator 把堆叠全大写的 MUST、ALWAYS 列为黄旗。

讨论对象是给当前主流强模型 agent 使用的 skill。给人用的 SOP 管理是另一个话题，不在此文展开。

二分法问错了问题

“说明书还是 SOP”预设分界在信息量，但真正的分界在判断权的归属。skill 的内容大致分三类：交付给执行者的事实与边界；不规定怎么做、只规定“要什么、怎么算完成”的契约，比如签名、规格和验收标准；以及替执行者把路走完的路径与顺序。前两类越多越稳，第三类越多越脆：写下它的人不在执行现场，却替现场做了决定。

官方 skill-creator 的文本恰好同时包含这两种写法。它建议用“ALWAYS use this exact template”锁死报告结构这类输出格式，同时又警告：如果你发现自己在写全大写的 ALWAYS、NEVER，那就是黄旗。这两句不矛盾。约束输出格式是合理的，格式是契约；约束推理路径是危险的，路径依赖现场。祈使句本身没有问题，没有理由的祈使句才有问题。

“编码所有情况”为什么做不到

想把所有情况预先编码进 skill，会撞上三堵墙。

第一堵是逻辑墙：规则不能自我应用。任何规则被执行前，都要先判断“这条规则此刻适不适用”；再用一条规则消掉这个判断，判断只是被推到上一层。这就是维特根斯坦的规则遵循悖论：写得再全的 SOP，最后总有一句“酌情处理”在兜底。所以“编码所有情况”不是工程量大，是逻辑上做不到。

第二堵是过拟合墙。把一次成功经验泛化成通用流程，和模型训练里的过拟合同构。Superpowers 仓库有两个现成的 issue。#895 中，计划文档把实现写到函数体级别，执行者发现更好方案时，调整反而像违反指令，对规则的字面遵从压过了工程判断；#2530 中，固定的开场提问模板对已有规格的任务照样追问泛泛的动机。维护者最后的修法方向一致、动作不同：#895 改成给签名、规格和验收标准，实现留给执行者；#2530 改成先读用户给的规格，再提有依据的问题。

第三堵是通胀墙。MUST 写多了会贬值，每条强制词都在稀释其他强制词的权威。更隐蔽的是封顶效应：skill 是写作时刻的快照，读者却是整条技术栈里进化最快的部件。按旧模型能力写的流程，就是让更强的模型陪更弱的假设爬行。

老问题的第六次出露

把镜头拉远，这场争论和 skill 没有必然关系。它背后是委托的结构性张力：委托方在写作时刻掌握的信息，和执行方在使用时刻掌握的信息，哪边更值得信任。这个问题已经在至少五个领域爆发过，并排看会发现，分歧都落在同一组变量上：执行者能力、失败可逆性、情境异质性、反馈速度。

序号	领域	争论	要点
1	法学	规则 vs 标准	明线规则事前定死、执行便宜，但必然过宽过窄；“合理注意”式标准灵活，但依赖裁判能力
2	军事	任务式指挥 vs 命令式指挥	上级下达意图而非步骤，因为战场信息在基层手里
3	管理	泰勒制 vs 知识工作	把判断编入工序对重复劳动有效，对判断即本体的知识工作失效
4	软件	瀑布 vs 敏捷、命令式 vs 声明式	“响应变化高于遵循计划”；SQL 说要什么，游标循环说怎么做
5	AI 史	专家系统与脚本	把专家知识编码成规则库，在未枚举的情形前脆弱崩溃

哈耶克 1945 年给过这层结构最早的表述之一：与决策相关的知识天然分散在现场，无法集中到一个规划者手里。套到 skill 上要收窄一步。作者不是中央计划者，更像刚从现场回来的人；agent 对这台机器一无所知，只看得见本次请求。真正写不尽的不是知识，是未来的情境。事实可以写下来，只是会过期；状态无法枚举，只能留给现场判断。

Agent 场景改变了什么

老问题在 agent 场景多出四个新变量。

文档从外部约束变成了注入的先验。 对人来说，SOP 在制度里，判断在人身上，分属两个载体。对模型来说，skill 的文本和阅读并执行它的推理发生在同一个上下文里：文档不只限制动作，还改变模型注意到什么。所以给人写详细 SOP 通常无害，给模型写却可能长出预期之外的行为。

反馈环缺失，文档向多写漂移。 人类组织里下属会顶嘴、会做错，制度随即校准。skill 的作者看不到执行现场：写多了不显错，写少了才出错。漂移的成本是被吃掉的判断空间，而这几乎无人投诉。对抗手段不在写法，在“用完必回改”的循环。

执行者没有制度记忆。 人类员工带着持续记忆工作，agent 每次会话从零开始，skill 是它唯一的跨会话记忆。这带来一条一级判据：值得写下的是重推导成本高、漂移率低的东西，比如环境事实、验证过的接口限制、付过学费的失败；推理流程不值得写，模型现场生成它几乎免费。SOP 式 skill 恰好写反了：它持久化了最便宜的东西。

验证变便宜了。 更可能的原因是验证变便宜，而不只是模型变聪明：能力连续上涨，写法的转向却是台阶式的，而且都发生在测试、diff 和回滚能力就位之后。SOP 是验证昂贵时代的替代品：没法事后检查，就只能事前规定。能跑测试、能看 diff、能回滚之后，事前规定的边际收益掉得很快。“可逆的操作交给判断”正是这条规律的推论：可逆约等于验证便宜。

落到写法：五条判据

1. 后果测试。 错了收不回的才写死：不可逆操作、越权、会把错误传给用户的误报。可逆的操作（查错接口、换顺序、多问一句）交给判断。
2. 重推导成本测试。 环境自己能回答的（--help、配置文件、schema、目录结构）不要抄进 skill，那只是会过期的缓存。值得写的是配置里看不出来的、付过学费才知道的。
3. 确定性进脚本，不进散文。 必须每次一模一样的事写成代码。文字版 SOP 两头不占：不能机械执行，又压住了该转弯时的判断。
4. 事实必须带验证日期。 API 改一个字段、端口换一次，skill 就从资产变成负债，还是有毒的那种：模型会拿着过期事实自信地做错。每条事实断言最好都能指回一个可重跑的验证动作。
5. 焦虑测试。 每条 MUST 都要能回答“这条错了，用户实际损失什么”。答不上来的不是规则，是作者的不放心。

多 agent 共享的 skill 再加一条分层原则：主文件只放事实、边界和一条最短默认路径，细节进 references 按需加载。强模型读五句就走，弱模型被告知去哪查。

结论与行动

Skill 最实用的形态是资深同事的一页交接便签：东西在哪、什么别碰、什么坑会咬人。约束预算只花在两处：不可逆操作和授权边界，其余全部降级为信息。

也不必期待这场争论有终局。“写多细”的答案是执行者能力、失败可逆性、情境异质性和反馈速度的函数，而执行者是整条栈里进化最快的变量，均衡点一直在移动。每个写 skill 的人都会把这场争论重打一遍，这不是缺陷，而是委托这个问题的本质。能做的只有三件事：按五条判据审计现有 skill，把通用流程降级为样例；给每条事实补上验证日期；新规则只在真实失败之后出现。skill 是长出来的，不是一次写全的。

参考资料

• anthropics/skills Issue #202：社区批评 skill-creator“重步骤、轻意图”，官方标记 not planned
• obra/superpowers Issue #895：计划过度规定实现的争论，维护者从“为弱模型写全实现”转向“给规格、执行者写实现”
• obra/superpowers Issue #2530：固定提问模板的反噬
• skill-creator 源码（commit dbd4588）：反 MUST 堆叠警告与 ALWAYS 模板并存
• Anthropic：Agent Skills 编写最佳实践：按任务调节自由度
• Anthropic：Effective context engineering for AI agents：不要把复杂脆弱的分支逻辑硬编码进提示词
• Friedrich Hayek, The Use of Knowledge in Society（1945）
• 站内：Agent Skills 的本质：用渐进式披露把领域能力装进文件系统