今天在微信群里聊到一个很细，但其实非常关键的问题：为什么很多 AI skill 或 prompt，一开始明明只暴露出一个问题，修完以后，第二次又开始冒出另一个此前没出现的问题；再修一次，又会出现第三种新的跑偏。
这种感觉很像软件工程里的打地鼠。你把一个洞堵上，另一个洞又冒出来。于是大家自然会想到一个办法：维护错题集，把踩过的坑一条条记下来，下次执行前一股脑塞给 AI，看起来就会越来越稳。
但真正跑下来，我越来越怀疑，事情没有这么简单。
很多时候，错题集确实能修掉一个局部问题；可当它开始越积越厚，系统反而会出现一种奇怪的退化：原本主任务并没有更清楚，约束倒是越来越显眼。最后 AI 的状态，不像是在努力完成任务，更像是在努力别犯错。
这类系统最容易发生的偏移，不是“不会做”，而是“把注意力从目标转移到了约束”。
错题集的问题，不在于它是错的，而在于它会慢慢抢走主语
我觉得这里最重要的一点是，模型并不会天然把你给它的信息分成两栏：左边是“真正要完成的任务”，右边是“顺手看一下的防错提醒”。对它来说，所有信息都在同一个上下文窗口里竞争注意力。
所以，当你不断补：别忘了这个、不要漏掉那个、上次这里错了、那个页面不能只本地生成、这个链接不能只测 200、那个样式不能跑偏……你当然是在提升系统的防错意识，但你也在同步制造另一件事：目标本身在上下文里被稀释了。
换句话说，错题集不是没有价值，而是它每长一层，都会和主任务争夺一次显著性。
这也是为什么很多人会有一种很强的体感：约束越多以后，AI 开始显得“很努力”，但做出来的东西并没有更完整。它可能记住了不能只停在本地页面，却忘了首页入口还要更新；它可能记住了要上线，却忘了文章风格不能像调研报告；它可能记住了要自测，却没意识到自测的目标不是 URL 打开，而是线上内容真的正确。
看起来像是它不够聪明，实际上更像是上下文里的重心变了。
很多“新问题”，一半是旧问题终于暴露了，另一半真的是约束把系统带偏了
这里我不想走一个太轻松的结论，说“都是因为约束太多”。那也不准确。
更真实的情况是，通常两个原因同时存在。
第一种，是以前的“没问题”只是一种假象。比如之前根本没检查线上是否真的生效，只看本地目录里文件在不在；又或者之前文章风格没被认真比对，所以格式差异其实早就存在，只是没被拿出来当问题。你一旦开始加严格规则，相当于也在提高观测精度，很多历史遗留问题会同时浮出来。
第二种，才是这次讨论真正点中的核心：当负面约束不断堆高时，AI 的注意力确实会从“我要把这件事做成什么样”转向“我不能再踩哪些坑”。这个过程并不是非黑即白的崩坏，而是慢慢发生的。到某个点以后，系统的整体表现会从“完成任务”变成“规避失败”。
这两个原因叠在一起，就会形成最让人头疼的局面：你一边觉得系统更受控了，一边又明显感觉它没有更会做事。
真正该补的，不只是限制，而是“什么叫完成”
今天这轮讨论里，我觉得最有价值的启发，是有人提到一句很关键的话：当约束变多之后，你必须在“什么叫任务完成”上，补同等级别的规范，避免彼长此消。
这句话非常重要。因为大部分 prompt 或 skill 之所以越调越怪，不是因为限制不够多，而是因为“完成定义”太弱。
很多任务写起来，表面已经很清楚了。比如：“调研这个主题，按我的文风调整一下，发到我的个人网站随笔栏目。”
人看起来觉得毫无歧义，但对系统来说，其实有很多关键环节都没显式化：
- 文章是写成调研报告，还是写成网站原生随笔？
- 发布是指生成 HTML，还是同步到线上真实目录？
- 首页要不要新增随笔入口？
- 线上 URL 返回 200 就算完成，还是必须包含正确标题和新正文？
- 样式只要能看就行，还是必须和既有随笔模板一致？
如果这些定义不明确，AI 就只能从最容易达成的表面动作里猜一个“差不多完成”。于是本地文件生成了，也可能被它当成“已经发布”；URL 能打开，也可能被它当成“已经上线”；页面有内容，也可能被它当成“风格已经对齐”。
所以真正有效的做法，不是继续补“不要这样”，而是把完成标准写成一条清晰的正向链路：做到哪些可验证的状态，才算真的完成。
官方文档其实也在说同一件事：不要只说别做什么，要说该怎么做
我去翻了一圈公开资料，发现这件事并不是少数人的体感，而是现在主流模型厂商都在用不同方式提醒开发者。
OpenAI 在 prompt engineering best practices 里有一句非常直接的话：与其只说不要做什么，不如告诉模型应该做什么。这个建议看起来很朴素，但背后其实是同一个逻辑：负面约束只能减少部分坏行为，正向路径才会真正塑造任务完成方式。
Anthropic 讲 agent workflow 时也在强调类似的原则：复杂任务不要默认压成一个越来越大的总 prompt，而应该拆成更简单、可组合、可验证的工作流。因为一旦任务变复杂，真正可靠的不是“再补更多说明”，而是增加清晰的步骤、gate 和 evaluator。
这让我越来越相信，很多人今天遇到的所谓“prompt 越调越重”，本质上已经不是 prompt 工程问题，而是 workflow 工程问题。你不再是在润色几句话，而是在给系统补任务结构。
与其写更厚的错题集，不如把关键节点变成 gate
我现在越来越明确的一个倾向是：能程序化验收的，尽量不要只靠语言提醒。
比如“发布完成”这件事，如果你只是写一句“记得发布到线上并自测”，它对模型来说还是一句抽象话。可如果你把它变成一组 gate，事情就完全不同了：
- 检查生产目录里是否存在对应文件；
- 用
curl -I看 URL 是否返回成功； - 用
curl -s检查页面标题是否正确； - 用
curl -s检查正文是否包含新文章的独特句子； - 再检查首页是否已经出现入口。
这时候系统不再是在“理解一句提醒”，而是在经过一个明确的完成门槛。门没过，就是没完成。这样做的价值非常大，因为它把“经验性的防错”变成了“结果性的验收”。
很多时候，AI 真正需要的不是第 12 条注意事项，而是一个明确会失败的检查点。
再往前一步，很多 skill 问题其实是 harness 问题
我最近一个很强的感受是，很多团队一旦发现 AI 做事不稳，第一反应就是继续打磨 skill。本能上这当然对，因为 skill 最直观、最容易改。但改着改着就会发现，skill 越来越像一个补丁层：这也要交代，那也要补充，最后整份东西越来越厚，像一部谁都不敢删的大工作流剧本。
这时候就该问一句：这些复杂度，真的都该放在 skill 里吗？
很多问题其实是更上层的系统问题。比如：
- 哪些信息应该进长期记忆，而不是每次重复塞进 prompt？
- 哪些行为应该由 runtime 默认保证，而不是靠每次提醒？
- 哪些结果应该通过 eval 和 gate 判断，而不是靠模型自觉？
- 哪些异常应该在工具层兜底，而不是在 skill 文本里补说明？
如果这些东西不分层，系统就会形成一种非常典型的补丁循环：面多了加水，水多了加面。最后看起来像是 skill 在变复杂，实际上是在用 skill 替整个 harness 补洞。
真正成熟的系统，不是把复杂度都塞进一个 skill，而是把复杂度放到正确的位置。
我的结论很简单：每增加一层约束，就要同步增加一层完成定义
如果把今天这件事压缩成一句可执行的话，我会说：
每增加一层防错约束，就要同步增加一层“什么叫完成”的正向定义，最好再配上对应的验收 gate。
因为约束和目标不是两张彼此独立的清单，它们会在同一个上下文里竞争。你只补约束，不补完成定义，系统就会越来越偏向规避失误；你只补完成定义，不补关键错误历史，又会不断重复踩坑。真正稳的状态，是两边一起长，但完成定义必须越来越具体，验收门槛必须越来越硬。
所以我现在不太相信“错题集写厚一点就会更稳”这种简单线性逻辑了。更准确的说法是：错题集有用，但它只能减少重复犯同一类错；如果没有同等级的目标表达、完成定义和 workflow 骨架，它迟早会把系统从做成事，带到少犯错。
而一个真正好用的 AI 系统，最终评判标准从来不是“看起来很听话”，而是“能不能稳定把事情做完”。