执行驱动交付（五）：错误放大坑——为什么一条推测会变成毒资产？
执行驱动交付（EDD）：AI 项目交付方法论 · 5/8
📖 摘要：AI 是忠实执行者 + 模式泛化器——你给它一个错误决策，它不只执行一次，而是泛化成模式、合理化成默认。EDD 因为有经验固化（skill/知识库/黄金集），错误是复利式传播：一条推测进固化层，N 个后续项目重复加载。本文讲三道阻尼器：外部锚点（决策必须有依据）、固化延迟（证据门槛）、版本可逆（能查能回滚）。
📌 本文要解决的核心痛点
- 一条「我觉得是这样」的推测，被 AI 写进 skill，后面 N 个项目都照着错？
- 一次执行就沉淀经验，把未验证的推测当事实——三个月后才发现根是歪的？
- 错误进了固化层，查不出是哪来的，也回滚不了？
- 本文讲错误放大坑：人把推测当事实喂给 AI 的复利式后果，和三道阻尼器的解法。
场景
一个知识库项目做完了，很成功。项目里有个约定：「检索词要做归一化，把『认证』映射成『验证』」——这是当时实测出来的结论，写进了 skill。
第二个项目用这个 skill，也顺。第三个项目，客户领域是财务，问题里全是「凭证」——skill 的归一化规则把「凭证」也映射到了别处，检索全歪。查根因：第一条归一化规则是当时那个项目「实测的」，但 skill 里的描述是「『认证』类术语需要归一化」——被泛化成了「所有近义词都要归一化」。第三条规则其实是当时某个人「拍脑袋觉得该加」的，也混在里面。
人给 AI 一条错误规则，AI 不会只执行一次——它会把这条规则当成这个领域的默认，复制到所有后续项目。 这就是错误放大坑：AI 的忠实，把人的一次失误变成了 N 个项目的系统性错误。
结论
错误放大坑：AI 是忠实执行者 + 模式泛化器——人把推测当事实喂给 AI，AI 把它泛化成模式、合理化成默认，错误复利式传播。防坑的核心只有一句话：防「无依据决策进入固化层」。
这个坑在 EDD 体系里尤其危险，因为 EDD 的核心就是经验固化——每单沉淀 skill、黄金集、知识库。经验固化的速度越快，错误放大的速度也越快：EDD 的反馈循环快是优势，也是放大器。快必须配阻尼器。
推导链：为什么错误是复利式，不是线性式
传统开发，一条错误规则的影响是线性的：改一个地方，影响一个功能。EDD 里，错误规则的传播路径是复利式的：
三个放大环节：
1. 泛化。 你给 AI 一条具体规则（「认证」→「验证」），AI 存进 skill 时存的是抽象规则（「近义词需要归一化」）——抽象的过程丢掉了约束条件（哪类术语、哪个领域、哪个阈值）。
2. 合理化。 模式库里的规则没有来源标注，后来者（包括未来的你）看到一条规则，默认它是验证过的——「它在 skill 里，那它肯定对」。
3. 复利。 每条带病规则 × N 个项目 = 错误的复利。而且病根藏得深：第 N 个项目出问题时，排查者看的是「这个项目哪错了」，几乎不可能想到「根在两年前的一条推测」。
实践动作：三道阻尼器（模板块）
| 阻尼器 | 位置 | 机制 |
|---|---|---|
| 外部锚点 | TR0（边界来源标注）+ TR1（选型靠实测） | 凡决策先问「依据在哪」——答不上来，不进边界卡 |
| 固化延迟 | 执行期（证据门槛）+ TR3（基线化） | 一次执行就沉淀 = 把未验证推测当事实；至少 N 次运行或一组断言通过才沉淀 |
| 版本可逆 | TR2 变更记录 + 备份回滚 | 错误进固化层，能查出哪来的、能回滚 |
外部锚点是三道阻尼器里最重要的一道：只注入有外部依据的决策——客户合同、平台文档、实测数据；纯脑内推演不注入。落地的动作是决策来源标注：边界卡和跑通记录的每条决策标「客户 / 事实 / 推测待验证」。标「推测待验证」的，TR4 终验（验证不过不许固化）——这是错误放大坑的最后一道闸。
固化延迟是第二道：skill/知识库更新设证据门槛——至少 N 次运行或一组断言通过才沉淀。一次执行就沉淀，就是把未验证的推测当事实。这道的反直觉之处在于：它挡住的往往不是错误，是「着急」——项目刚结束的成就感里，最容易把「这次碰巧对了」当成「规律」。
版本可逆是第三道：TR2 变更记录（改了什么/为什么/影响哪）+ 固化层备份可回滚。错误进固化层是防不住的（人总会犯错），防的是「进得去、查不出、回不来」。
伴随字段是沉淀时必做的第四件事——不算第四道阻尼器，因为三道阻尼器防的是「假内容被当真」（来源/证据/回滚），还差一道防「真内容被误用」：沉淀时不标版本、适用场景、约束前提，一条真结论也会被下一个项目用错地方。所以固化放行时同时标注三件事：版本（在什么环境验证的——Dify 1.16.1 / Hermes v0.20 / 版本无关）、适用场景（什么场景成立）、约束前提（依赖什么条件）。证据门槛证明「是真的」，条件标注说明「在哪真的」——放行和标注是同一个动作的两面。
上面反例里那条「输出必须用 JSON」的规则，就是典型的没标约束前提——补一句「下游需要 JSON 时才用」，第二个项目一眼就能看出不适用。
正例实证：来源标注拦住了一条推测
一个交付项目，执行中 AI 建议「检索阈值调到 0.3，效果会更好」——当时没有实测支撑，是它的推断。按外部锚点纪律，这条标了「推测待验证」，没进边界卡。
后来 TR4 终验时专门测了阈值 0.3 vs 0.5：0.3 的召回率高但噪声大，客户场景反而 0.5 更稳。这条推测被验证为「错误」，在 TR4 被拦下——如果它当时直接进了 skill，后面所有检索类项目都会默认 0.3，然后集体「检索结果太乱」。
反例实证：一条「顺手加的规则」，三个项目跟着歪
内部实验，一个项目收尾时，执行记录里有一条「顺手加的」规则：「输出必须用 JSON 格式」。当时项目里确实用 JSON（因为下游要解析），但规则没写约束条件——「本项目下游需要 JSON」。
第二个项目，下游是消息推送（不需要 JSON），AI 照 skill 默认输出 JSON，推送侧解析失败，排查两天。第三个项目前，这条规则才被揪出来改成「下游需要 JSON 时才用」。一条没标来源、没写约束条件的规则，让两个项目各多花两天排查。 如果当初标了「来源：本项目下游需要」，第二个项目一眼就能看出不适用。
边界与版本
固化延迟的证据门槛（初值）：至少 N 次运行（建议 ≥3）或一组断言通过；N 按错误后果调——越界/数据类错误门槛更高
决策来源三分类：客户（直接固化）/ 事实（实测/文档，直接固化）/ 推测（待验证，TR4 终验）——分类是硬要求，不是建议
三道阻尼器不增加流程重量：来源标注是写边界卡时顺手的一列，证据门槛是沉淀时的一个判断——它们挡的是「无依据决策」，不是「正常流程」
反例中的阈值数字（0.3 vs 0.5）为演示性数值，机制以真实项目的来源标注为准
收尾
错误放大坑的本质是信任错位：人信任 AI 的忠实（它不会反驳我），AI 信任人的正确（它不会怀疑我）——两个人都不质疑，错误就一路畅通地进了固化层。
三道阻尼器的共同点：在「决策」和「固化」之间插入一道质疑。外部锚点质疑「依据在哪」，固化延迟质疑「验证过吗」，版本可逆质疑「出错了能翻案吗」。EDD 快，但快必须有这三道闸——没有阻尼器的 EDD，跑得越快，错得越远。
下一篇：TR4 双面闸——为什么验收要双向，对内终验推测项、对外交出凭证？
💬 讨论区：你的经验库/知识库里有没有「不知道哪来的规则」？它让几个项目跟着踩坑了？评论区聊聊你揪出过的最隐蔽的一条。
本文基于真实项目交付经验撰写（2026-08，1 个真实交付项目与内部实战实验）。文中数据均来自实测记录，方法论部分以「已验证 / 推断待验证」标注边界。
