这阵子我经常被问怎么写 prompt、怎么写 skill、怎么写 AGENTS.md。聊得多了我发现，业界其实早就分成了两派。分歧不在"要不要跟 AI 说清楚"，所有人都同意要说清楚。分歧在什么叫做跟 AI 说清楚。
一派的看法很直接：跟 AI 说清楚，就是把过程写清楚。skill 里要列出每一步，先做什么再做什么，遇到 X 走哪个分支，遇到 Y 走哪个分支，文档越长越细越好，最好把所有 corner case 都覆盖。这一派的潜台词是：模型不可靠，所以要替它把流程钉死。
另一派恰恰相反：跟 AI 说清楚，说的不是过程，是目标。是验收标准，是边界，是几个具体例子。把 skill 当 SOP 去写是不对的。这一派的潜台词是：模型已经能自己拆任务、自己选工具、自己判断什么时候该停，你写的"标准路径"既覆盖不全，又压住了它本来能给你的更好路径。
我自己写 skill 的时候用的是后一派。我自己工作区里有一份专门讲"新 skill 怎么写"的元规则，被自己反复读过，核心就一句话：结果确定性优先于过程确定性，写 enabling 的指导，不要写 SOP。这不是个人偏好，是踩了几次坑被迫做出的选择。坑的形状每次都很类似：今天写一份很详细的步骤指令、跑得也行；过半年模型升一代，同一份指令突然犯一些奇怪的错；团队的反应永远是"再把它写得更清楚一点"，于是 prompt 越改越长、效果越改越差。
这件事看起来是写法之争，但底下藏着一个被严重低估的成本：如果你写的是过程，模型每升一代，你都在被偷偷扣掉智能红利。
过程型 SOP 是怎么折旧的
把指令分成两类，事情就清楚了。一类我叫它过程型 SOP，替模型规定"先做 A、再做 B、然后判断 X、走分支 Y"。另一类我叫它结果型契约，把目标、验收标准、边界、例子讲清楚，剩下的让模型自己拆。这两类指令的命运正好相反：模型每升一代，前者贬值、后者升值。
过程型 SOP 在 GPT-3.5 时代是必要的脚手架，因为那时候模型推理能力弱、上下文跟不住、工具调用经常出错。但今天它已经是最容易折旧的那一类内容。模型已经会自己拆任务、会自己选工具、会自己判断什么时候该停；reasoning model 内部的 CoT 比你手写的 step-by-step 更强；你规定的"标准路径"在长尾场景上必然失效，而模型本来有能力绕开。Wharton 有个研究测过这件事，在 reasoning model 上额外加 CoT 只剩边际收益，但延迟会暴涨百分之二三十甚至更高。换句话说，你为了"让模型更可靠"加进去的步骤，正在让它变慢、变贵、变笨。
更扎心的是另一个方向：过程型 SOP 限定了输出的形状。你规定了 12 步流程，输出的天花板就被这 12 步框住了。模型再聪明也只能产出一份"很好执行的 12 步结果"，而不是它本来能给你的"重新设计后的 5 步结果"。模型每一代升级，最大的增量都是"在更模糊的目标下做出更好的判断"。这种增量必须有发挥空间才能体现。你把空间封死了，增量就被你自己挡在门外。
结果型契约相反。它规定的是"答案的形状"，不是"路径的形状"。模型变强之后，对模糊目标的脑补能力变强，但它只在你给了清晰目标的前提下才发挥得出来；你不告诉它"什么是好"，它只能凭直觉给你"看起来好"。验收标准是这件事的杠杆点。模型越聪明，杠杆越长。边界和例子则是 corner case 上唯一稳的锚。这一类内容写一次，跨多代模型都能用，质量随模型变强自动上升。
过程型 SOP 还有一个隐性的工程信号代价。如果指令是"做成这样"，agent 在做不出来的时候会反推"目标是不是定错了"；如果指令是"按这 12 步做"，agent 在第 7 步卡住时只会告诉你"第 7 步失败了"。前者给你的是产品级反馈，后者给你的是工单。
我去年在金融科技团队推 AI 转型的时候吃过这一脚。最早几份 skill 我让大家写得很详细，恨不得每个 if-else 都列出来。模型升一次级，每份 skill 都要手动改一轮。后来我把团队的写法换了：第一段写"这个 skill 干什么、产出什么"，第二段写"做对了长什么样"加 3 条可验证标准，第三段写"边界和已知坑"，所有"先做 A 再做 B"的描述都删掉，只在不可逆操作那几处保留"必须先 dry-run"这种硬约束。换了几次模型之后，这批 skill 的存活率比之前明显好。
那合规场景呢？一个三档框架
讲到这里我必须接住对面最强的几条论据，不然就是稻草人。
第一条是合规。如果一个工作流必须能按步骤复盘才能通过审计，那就老老实实写 SOP。Anthropic 在 Skills 的官方建议里把这件事讲得很清楚：给 skill 匹配合适的自由度，是一个三档框架。高自由度，纯文本指令，模型可以按多种方法走；中自由度，带参数的伪代码，结构定了细节可调；低自由度，写死脚本，不允许偏离。数据库 migration、金融交易、医疗给药、PCI 和 HIPAA 合规链路，这些就该用低自由度档。把所有 skill 都按高自由度写是错的，把所有 skill 都按低自由度写也是错的。问题从来不是"要不要 SOP"，是"哪一档配哪一类任务"。我反对的是把低自由度档的写法套到高自由度任务上。
第二条是 Andrew Ng 那个经常被引用的 HumanEval 实验：GPT-3.5 加上 agentic workflow，性能能跑赢 zero-shot 的 GPT-4。这条结论我也信，但它说的是 reflection、planning、tool use、multi-agent 这一类系统级的工程编排，不是在 prompt 里塞 12 步流程。reflection 是一种结构，让模型自己 review 自己；planning 是一种循环，让模型自己出 plan 自己执行。这是 agent harness 层的设计，不是 skill 内部的步骤清单。这两件事经常被混为一谈。Workflow 作为系统编排是对的；workflow 作为单个 skill 内部的 step-by-step 写法，今天已经是反模式。
第三条最有意思也最容易让我妥协：新人写不出好的"目标 prompt"，过程型 SOP 反而是经验沉淀的载体。我的回应是，如果一个团队连"这个 skill 要解决什么问题、做对了长什么样"都写不清楚，那不是 prompt 写法的问题，是产品定义的问题。把它包装成 12 步 SOP，看起来交付了一份文档，实际上是把"产品定义不清晰"埋进了系统。每次模型升级、每次场景变化、每次新人接手，它都会重新爆出来。
两条相反的官方建议指向同一件事
有一个细节经常让人困惑。OpenAI 的 GPT-5 prompting guide 在说"少即是多"，模型越聪明，prompt 越要简洁，过度规定反而伤害性能。Anthropic 的 Claude 4.x 最佳实践在说反方向，Claude 4.5 出来之后打破了大量已有 prompt，因为新版本更"字面执行"，你说什么它就做什么、多一点都不会。两家头部模型公司对"该怎么写 prompt"给出了表面上相反的建议。
很多人看到这里会得出"业界没共识"的结论。我的解读是另一回事。这两条建议针对的根本不是"要不要写步骤"，而是"要不要写明确目标和验收标准"。OpenAI 说的是别在 prompt 里塞重复的、互相矛盾的、为了壮胆而堆叠的话；Anthropic 说的是模型不再替你"脑补意图"了，你想要什么就明明白白说出来，不要假设它会主动做"超出预期"的事。两边的指向其实是同一件事：把目标、验收、边界写清楚，把过程、步骤、套话写少。
如果你写的是"You are an expert. Think step by step. Be concise. Be helpful. Use bullet points when appropriate." 这种填充话术，GPT-5 会因为它们互相矛盾而浪费 reasoning token，Claude 4.5 会因为它们没有具体内容而字面理解到失控。两边都崩，但崩在不同环节。如果你写的是"目标是 X、验收标准是 1/2/3、边界是 A/B、例子见 examples/case-1"，GPT-5 会按它的判断帮你做到，Claude 4.5 会一字不差地按你说的做。两边都活。
一个具体的反模板
具体一点。我见过的某团队 skill 文件大致长这样：
你是一个数据分析专家。
请按以下步骤执行：
第一步，调用 BI 工具拉取最近 7 天的数据
第二步，按渠道分组
第三步，计算每个渠道的转化率
第四步，找出 TOP 3 异常渠道
第五步，对每个异常渠道做归因
第六步，输出报告
注意：
- 不要使用模糊词
- 不要漏掉任何渠道
- 报告必须分小节
- 必须包含数据来源
- 必须有结论
- 必须有建议
- 必须有下一步行动
- 不要使用第一人称
- ……（再 30 行类似的注意事项）这份文档在 GPT-3.5 时代很 work。换到 GPT-5 时代会出两种典型问题。要么模型严格按 6 步走，每一步都用最朴素的方式做，浪费了它本来能识别"这周哪个渠道值得深挖"的能力；要么模型在第 4 步发现 TOP 3 里有 2 个是数据噪声，但它没有跳出 SOP 的权限，于是给你一份"看起来完整但其实没价值"的报告。
同样的需求，按目标加验收加边界写就成了：
目标：每周一早晨给业务方一份"上周哪些渠道异常 + 为什么"的简报
输入：BI 系统中过去 7 天的渠道转化数据
输出位置：reports/weekly_channel_anomaly_<日期>.md
验收标准：
- 必须明确指出"本周值得关注的异常"，0 个或多个都行，不为了凑数硬找
- 异常的归因必须能追溯到具体数据点（不能只说"可能是季节性"）
- 简报让业务方读完能在 2 个动作内决定是否需要拉会
边界：
- 数据明显异常（如某渠道转化率突然为 0）时先报警，不要直接归因
- 归因涉及"竞品策略变化""政策影响"这类外部因素时，标注为"假设"而不是"结论"
- 不要在简报里写本工具的执行过程
例子：
- 见 reports/weekly_channel_anomaly_20260428.md（一份好简报）
- 见 reports/weekly_channel_anomaly_20260421.md（一份不够好的简报，问题：把 5 个边缘异常都列了，业务方看不下去）这份指令模型会自己拆步骤，会自己判断要不要分组、要做几层归因、要不要追加查数据。下一代模型来了，它的"自己判断"能力变强，这份指令的产出质量也跟着上去。你不用动一个字。
检查自己已经写了的 prompt 和 skill，可以问几个问题。里面有没有"第一步、第二步、第三步"这种字样，如果有，那串步骤是在描述"做对了长什么样"还是"该怎么做"，如果是后者并且任务不是不可逆操作，删掉它，让模型自己拆。指令最后能不能被一个新来的 agent 拿来判断"这件事做完了没有"，如果不能，说明你的验收标准还没写到位。"必须 / 不要 / 不能"这类硬约束如果超过十条，绝大部分多半是在应对脑补出来的 corner case，让真实的失败驱动迭代，第一次出错是噪声，第二次才是模式。最后看几个具体例子，不是抽象描述、不是反面教材清单，是真实的"长这样的输入产出长这样的输出"，对高自由度任务尤其关键。
那一截增量进谁的口袋
回到开头那个分歧。两派都在说"要跟 AI 说清楚"，区别在于说清楚什么。说清楚过程，你拿到的是一份在 GPT-3.5 上扎实、在 GPT-5 上别扭、在下一代模型上明显落后的脚手架；说清楚目标和验收标准，你拿到的是一份会跟着模型一起变强的契约。
模型每升一代，能解的问题都比上一代多一截。如果你的指令规定的是答案的形状，那一截增量进了你的口袋；如果你的指令规定的是路径的形状，那一截增量被你自己挡在门外。你写的不是给 AI 看的指令，是给"未来一年里每一代模型"看的契约。
写 SOP 不是错，把所有 skill 都当 SOP 写，是。真正的工程能力，是知道哪一档自由度配哪一类任务。这个判断本身，就是 AI 时代里不太可能被 AI 替代的那部分手艺。