从一次真实交付看：AI 撞见错误方案时，为何停工比偷偷改设计更优剖析一个 AI 交付任务在 N1 就发现方案自带无效药方

从一次真实交付看：AI 撞见错误方案时，为何停工比偷偷改设计更优

封面图：夜色书桌前，一只毛绒小龙在台灯下对着笔记本电脑与摊开的笔记本写笔记，旁边放着咖啡

TL;DR

本文基于一次 8 条需求（N1–N8）的真实交付，AI 在 N1 跑测试就发现：方案开出的"stub _remote_asset_sha"药剂只救活 9 个红测试里的 2 个，其余 7 个在 store_pull → pull.select_as_asset 上游就已失败。
根因是 host-dependent 误判：2026-10-28 的"302 passed"只在 darwin-x64 验证，换机器即红。
结论：把"规范本身错误"设为唯一能触发停工的合法例外，动作固定为 停止 → 清理 → 汇报，绝不就地修补规范；并把判据、动作、汇报格式写进提示词。
配套决策矩阵与流程护栏可直接落地到任何 AI 实施任务。

背景与问题

规范只描述"正常路径"。一旦执行端发现正常路径走不通，就进入真空：规范没说，指南没提，AI 只能临场发挥。临场发挥的默认倾向几乎总是两种之一——继续做（进度好看）或者就地修（显得能干），两种都会把一个设计层缺陷伪装成一个实施层小问题。

真实案例：8 条需求的交付任务，做到 N1 时先跑测试复核现状，发现 9 个测试红。追查结论：

9 个测试是 host-dependent，非 network-dependent。2026-10-28 那轮"302 passed"在 darwin-x64 验证，换机即红。
方案药方"stub _remote_asset_sha"只能救活 2/9；其余 7 个在 store_pull → pull.select_as_asset 失败，位置在 _remote_asset_sha 上游，按方案实现等于在缺陷主体上空转。

停工决定与清理动作：AI 写明发现阻断性缺陷，先清理空的 worktree、把主仓库恢复到干净同步状态，并说明为什么这不只影响 N1

注意：停工时没有任何代码变更，唯一动作是清理空 worktree、把主仓库恢复到干净同步状态。

为什么停，而不是悄悄改对

非局部问题。 N2–N8 来自文档评审，从未真正执行验证。N3 护栏 #2 依赖 store_pull 真实控制流（未跑过）；N2 的"needs core"规则从没在真实 manifest.json 上跑过，其误报是断言而非测量。
爆炸半径扩散。 改动牵动每个产品的 release.yml，8 个 PR 自动合入两个共享生产仓库，依据是一套从未验证的规范。
规则本就写明："If the design is wrong or cannot satisfy the task, stop and flag it — do not patch the design yourself inside an implementation task."

AI 解释为什么选择停下来而不是悄悄修：9 个测试的失败原因、方案药方的无效性、N2–N8 的未验证假设，以及爆炸半径

叠加后不再是"我觉得该停"，而是继续执行的期望损失 > 停工的期望损失。

合规前置：用证据把"停"变成可审计决定

停工报告先做一张合规表：读完角色定义、九步工作流、三类指南、公共指南、两份仓库级 AGENTS.md（含阻塞规则）后才停，运行模式/仓库状态/凭证已确认。关键一行是 origin/master 同步（ahead 0 / behind 0）——证明没留半成品状态。

动第一行代码之前完成的合规核验表：角色与技能文件、三类指南、公共指南、仓库级 AGENTS.md、技能目录解析、运行模式、仓库干净同步、凭证就位

停工三件套：固化进提示词

发现规范与事实冲突时（测试红/文档与实现不符/前提不成立）：
  1. 判据：区分「实施可补救」与「规范本身错误」。
     规范本身错误 → 触发停工，禁止就地修补规范。
  2. 动作：停止实施 → 清理工作树、把仓库恢复到
     干净同步状态 → 不留半成品。
  3. 汇报四要素：
     a. 异常描述（哪条规范、错在哪）
     b. 已验证证据（明确区分「我验证过的」与「我推断的」）
     c. 影响面（哪些需求/仓库/下游会被牵动）
     d. 建议方案与需要人来决策的点
禁止：为让测试变绿而修改断言或测试本身。
禁止：把未验证规范当成事实继续实现。

流程护栏：

读规范/合规核验 ──► 跑测试基线 ──► 实施 N1
      │                  │              │
      │                  └─异常─┐        │
      │                        ▼        ▼
      │                 判据：规范本身错？──否──► 带病标注继续
      │                        │是
      │                        ▼
      │              停止 → 清理 → 汇报四要素
      │                        │
      └──── 设计层修正后重跑 ◄──┘

结果与生产落地建议

零行代码、一份报告，拦下：① 注定无效的变更（7/9 仍红）；② 高风险自动合并（8 PR、2 共享生产仓库、全依赖 release.yml）；③ 把缺陷移回设计层（改一次方案，N1–N8 全受益）。

生产建议：

提示词显式声明"规范本身错误"是合法停工触发，不扣进度分。
停工必须伴随清理（工作树删除、主仓库恢复干净同步）。
汇报固定四要素缺一不可；强制区分"我验证过的"与"我推断的"。
涉及共享仓库/命令面变更时，显式列出被牵动的下游。
动第一行代码前先完成合规与基线核验，并把结果作为表格亮出。

总结

规范只描述正常路径，"规范本身错误"是执行端真空地带；填它的默认倾向（照做/就地修）都错，例外通道必须写进提示词。
判继续还是停看两问：缺陷局部还是根上、影响面是否顺依赖扩散。根上错误 + 扩散影响 = 停。
停工三件套 + 合规前置，让"停下来"成为可审计、可交接、可随时重来的动作，而非一次放弃。

作者简介：kylinlab.tech，专注 AI 智能体与自动化交付。完整规范与提示词条款见 kylinlab.tech 大家在生产中怎么处理"实现端发现设计错了"？评论区交流～