AI Coding 最危险的不是写错代码，而是写出一段“看起来能修”的代码

AI Coding 最危险的时刻，不是它写不出代码。

更危险的是，它十分钟就写出了一段“看起来能修”的代码。

比如一个订单卡在处理中。

渠道回调显示成功，系统日志里也有回调记录，但业务订单迟迟没有推进。你把日志、代码片段和报错贴给 AI，让它帮你修。

AI 很快定位到一段状态更新逻辑，改了代码，补了一个测试，然后告诉你：

问题已经修复。

这时候真正的问题来了：

你敢合并吗？

如果这是一个脚本问题，你可能敢。

但如果这是支付、信贷、账务、履约这类系统里的状态卡住，你大概率不会只看 AI 的总结就合并。

因为你真正关心的不是“它有没有改代码”，而是：

• 它有没有找到真正的断点？
• 它有没有看懂状态机？
• 它有没有处理幂等、重试和补偿？
• 它有没有破坏历史兼容？
• 它如何证明这个问题以后不会再出现？

这就是我最近越来越明确的一个判断：

AI Coding 真正要进化的，不是提示词，而是证据链。

AI 太容易“看起来完成”

很多人讨论 AI Coding 时，关注点还在 prompt 怎么写、模型怎么选、工具怎么切换、怎么让 AI 少废话、怎么让 AI 一次改得更多。

这些当然重要。

但它们解决的主要是：AI 能不能更快给出答案。

复杂业务系统里更麻烦的问题是：AI 很快给出了一个局部成立的答案，而且这个答案看起来足够像真的。

它改动很小，看起来合理。

它补了测试，但测试只覆盖当前报错。

它解释得很完整，但没有证明全链路闭合。

它让当前问题消失了，但可能绕过了幂等、状态机、重试或补偿逻辑。

所以 AI Coding 的风险不只是“写错”。

更常见的风险是“局部正确”。

AI 生成一段明显错误的代码，反而容易被发现。真正麻烦的是它生成一段看起来合理、当前测试也能过、总结还很完整的代码。

这种代码最容易让人放松警惕。

但真实工程里，完成不是代码被改了，而是证据链闭合了。

同一个问题里，其实藏着四层工程

还是前面那个订单状态卡住的问题。

渠道回调显示成功，系统日志也有记录，但业务订单没有推进。AI 已经写出了一段“看起来能修”的代码。

这时如果我们反过来看，会发现 prompt engineering、context engineering、harness engineering、loop engineering 这几个词，其实不是四个孤立的新概念。

它们都在回答同一个问题：

如何让 AI 进入真实工程协作，而不是只生成一段局部成立的代码？

如果只做 prompt engineering，你可能会这样问：

帮我看一下这个订单为什么卡住，并修复代码。

这当然有用。

好的 prompt 能让 AI 更清楚任务目标、输出格式和约束。但它主要解决的是“怎么把问题说清楚”。

它无法保证 AI 知道这个系统有哪些状态，哪些状态允许跳转，回调和业务单之间是什么关系，什么是可重试，什么是不可重试，哪些历史状态不能被直接修正。

所以只靠 prompt，很容易把一个链路级问题压缩成代码片段级问题。

再往前一步，就是 context engineering。

你开始给 AI 更多事实：

• 订单状态机。
• 渠道回调日志。
• 回调流水表。
• 业务订单表。
• 幂等记录。
• 消息发送和消费日志。
• 相关代码路径。
• 最近一次类似问题的修复记录。

但这里的重点不是“给得越多越好”。

真正重要的是把这些材料组织成一条任务相关的事实链路：

回调是否可信 → 回调是否被处理 → 状态是否允许推进 → 事件是否发出 → 下游是否消费 → 业务单是否最终一致。

Context engineering 解决的是：

AI 应该基于哪些事实工作。

只有上下文还不够。

如果 AI 只能聊天，它最多只能给建议。要让它真正进入工程现场，还需要 harness。

它要能查代码引用，看 diff，跑单元测试和集成测试，构造回放数据，查日志，执行 SQL 或查询模拟结果，调用知识库，并且被 guardrail 限制不能乱改无关模块。

Harness engineering 解决的是：

AI 如何从“会分析”，变成“能参与工程过程”。

最后，问题还不只是这一次修掉。

如果这次 AI 漏看了幂等记录，review 才指出来，那么这条反馈不能只停留在本次对话里。

它应该沉淀成状态卡住排障 checklist，回调处理回归测试，状态机知识库，一条“修状态问题必须检查幂等和重试”的 skill 规则，或者一条 review 规则：不允许只改状态判断，不补证据链。

这就是 loop engineering 要解决的事：

这次成功和失败，如何进入下一次。

所以 prompt、context、harness、loop 不是四个为了追新的名词。

它们是在描述同一件事的不同层面：

我们正在把原本靠资深工程师脑子维持的排障、验证和交付过程，一层层外显给 AI。

AI Coding 的核心资产不是提示词，而是证据链

真实工程里，尤其是支付、信贷、账务、履约这类系统，很多问题不是代码片段级问题，而是链路级问题。

状态卡住时，工程师真正想看的不是“哪一行代码可能错”。

他真正想看的是一条证据链。

第一，外部事实是否成立。

渠道真的成功了吗？渠道返回的是最终成功，还是中间状态？有没有异步通知延迟？有没有重复通知？有没有金额、币种、订单号不一致？

第二，系统是否接收。

回调有没有进入系统？签名校验有没有通过？回调流水有没有落库？有没有被网关、幂等、限流、灰度策略挡掉？

第三，处理是否成功。

幂等有没有命中？状态 guard 条件有没有通过？当前订单状态是否允许推进？是不是因为历史状态或补偿状态导致逻辑跳过？

第四，状态是否推进。

渠道流水、支付单、业务订单、账务单、履约单是不是一致？有没有只推进了技术单，没推进业务单？有没有状态更新成功但事件没发出去？

第五，下游是否收到。

MQ 有没有发出？消费者有没有消费？消费失败有没有重试？重试是否被幂等挡住？任务表里有没有遗留失败任务？

第六，补偿是否生效。

如果某一步失败，有没有重试机制？有没有补偿任务？有没有人工修复入口？补偿会不会重复执行？

第七，修复是否安全。

这次改动有没有破坏历史状态？重复回调是否安全？并发场景是否安全？账务和审计链路是否还能对上？

如果 AI Coding 只围绕代码生成，很容易跳过这些证据。

它会倾向于找一个局部断点，然后给一个局部修复。

比如放宽一个状态判断，加一个空判断，补一段重试，吞掉一个异常，或者改一个测试断言。

这些修改可能让当前报错消失，也可能让当前测试变绿。

但它不一定证明问题被修掉了。

所以未来一段时间，AI Coding 能力的关键不是谁的 prompt 更漂亮，而是谁能把证据链设计得更完整。

可以把差异压成一张表：

层次	常见做法	更工程化的做法
提问	把报错贴给 AI	明确问题、边界、不能破坏的行为
上下文	粘几段代码	提供状态机、日志、数据、历史案例
工具	让 AI 给建议	让 AI 查引用、跑测试、看 diff、构造回放
验证	AI 说修好了	用测试、日志、状态链路证明修好了
沉淀	本次对话结束	写入 checklist、skill、知识库、监控

这个表里真正有价值的，不是多了几个步骤。

而是它改变了 AI Coding 的完成定义。

以前的完成定义是：

AI 改了代码，测试过了。

更工程化的完成定义应该是：

问题有证据，修复有边界，结果可验证，经验能沉淀。

真正被外显的，是资深工程师的隐性判断

很多工程经验以前并不会被写下来。

老工程师知道，状态卡住不能只改状态判断。

他知道回调成功不等于业务成功。

他知道测试通过不等于账务一致。

他知道线上问题修复后必须补回归用例。

他知道有些状态不能回退，有些异常不能吞，有些重试不能随便加，有些补偿不能重复执行。

这些判断过去存在于人的经验里、团队的 review 习惯里、事故复盘里。

AI 不天然知道这些。

它看到一段报错，就会倾向于找一段代码。

它看到一个测试失败，就会倾向于修到变绿。

它看到用户说“帮我修一下”，就会倾向于尽快给出一个修复。

这不是模型不努力，而是它不知道你的工程判断在哪里。

所以 AI Coding 工程化的过程，其实是在做一件事：

把人的隐性工程判断，变成 AI 可以读取、执行、验证和反馈的系统结构。

Prompt 外显人的意图。

Context 外显系统事实。

Harness 外显工程现场。

Loop 外显反馈机制。

但这几个词背后真正重要的是：人的工程判断开始被拆出来，放到更明确的位置。

以前你可能只是在 review 时说一句：

这个状态问题不能只看当前报错，要看幂等和重试。

现在这句话应该变成 checklist。

以前你可能只是在事故复盘里写一句：

重复回调会导致状态推进被跳过。

现在这句话应该进入知识库和回归测试。

以前你可能只是在心里知道：

没有验证证据，不要说完成。

现在这句话应该变成 workflow 里的 hard gate。

AI Coding 的进化，不是让模型替代工程判断。

恰恰相反，它会逼着我们把工程判断说清楚、放对位置、接进流程。

为什么“看起来能修”的代码更危险

AI 写出明显错误的代码，风险反而可控。

因为人一眼能发现。

真正危险的是那种看起来很合理的代码。

改动很小。

测试是绿的。

代码风格符合项目习惯。

AI 总结得很完整。

问题在测试环境复现不了。

这时候 review 人很容易放松警惕。

尤其是 AI 会倾向于局部闭合。

当前报错没了。

当前测试过了。

当前状态推进了。

但复杂系统需要的是全链路闭合。

状态是否从源头到终态都一致？

重复回调是否安全？

失败重试是否安全？

历史数据是否安全？

修复是否留下可审计证据？

如果这些问题没有答案，代码越像真的，风险越高。

因为它会把 review 的注意力从“有没有真的修好”转移到“代码看起来是否合理”。

这也是 AI Coding 和传统手写代码一个很大的差异。

过去一个人写代码，他至少知道自己为什么这么改。虽然他也可能错，但他通常能解释自己的判断链。

AI 写代码时，解释常常是后生成的。

它可以给出一个很顺的总结，但这个总结未必等于真实推理过程，也未必覆盖真正的业务证据。

所以面对 AI 生成的修复，我越来越不愿意只问：

代码有没有问题？

我更愿意问：

它用什么证据证明这个问题被修掉了？

这个问题会逼着我们从代码审美回到工程事实。

让一次修复变成系统资产

如果这次状态卡住的问题修完了，但所有经验都留在这次对话里，那这次 AI 协作没有真正变成资产。

它只是一次对话。

下一次再遇到类似问题，AI 可能还是会漏看幂等记录，还是会只改状态判断，还是会只补 happy path 测试。

所以真正值得建设的，是一个能把 AI 协作经验写回自身的工程系统。

它要做的第一件事，是给失败分类。

这次 AI 漏看了幂等表，是上下文问题。

知识库里没有写清楚状态推进和幂等记录之间的关系，下次 AI 当然还会漏。

这次 AI 只能看代码，不能查日志、不能构造回放、不能跑相关测试，这是 harness 问题。

它没有进入真实工程现场，只是在代码片段上做推理。

这次 AI 只补了 happy path 测试，这是验证问题。

重复回调、消费失败、补偿重试这些更关键的路径没有变成回归用例。

这次 reviewer 又提醒了一遍“状态问题必须检查幂等和重试”，这是规则沉淀问题。

如果同一句 review 意见反复出现，它就不该只存在于评论里，而应该进入 checklist、skill 或 review gate。

这次 AI 为了让测试通过，想改断言或放宽状态判断，这是 guardrail 问题。

有些操作不能靠模型自觉避免，而应该在流程里明确禁止。

这样看，一次 AI 修复结束后，真正要问的不是“这次有没有修好”，而是：

这次暴露出来的问题，应该写回哪里？

写回测试，它就变成回归防线。

写回 checklist，它就变成排障路径。

写回知识库，它就变成系统事实。

写回 skill，它就变成执行约束。

写回 guardrail，它就变成禁止动作。

这就是我理解的下一阶段。

不是单纯让 AI 多跑几轮。

也不是给 AI 一个更长的 prompt。

而是让每一次 AI 协作都能反过来改造工程系统。

Anthropic 讲 context engineering，本质上是在讨论有限上下文里如何管理高信号事实。

LangChain 讲 harness，本质上是在模型外面建设工具、状态、约束和反馈系统。

Loop engineering 的关键也不是让 AI 不停循环，而是让每一轮反馈能被测量、被验证、被写回系统。

这些方向放在一起，其实指向同一件事：

下一阶段比拼的不是谁更会问 AI，而是谁的工程系统更会从 AI 的成功和失败中学习。

一次 AI 修复如果没有沉淀，只是一次对话。

一次 AI 修复如果进入工程系统，才会变成下一次的能力。

结尾：Loop 之后，改变下一次的起点

Loop engineering 解决的是：

这一次执行、验证、反馈和修正，如何进入下一轮。

但如果继续往前看，更关键的问题会变成：

下一轮开始之前，工程系统有没有因为上一轮变得更好？

也就是说，loop 不是终点。

Loop 的下一阶段，是把每一次 AI 协作变成工程系统的学习材料。

所以我现在越来越少把 AI Coding 理解成“怎么让模型写出更好的代码”。

对简单任务，这当然重要。

但一旦进入真实业务系统，尤其是状态、资金、账务、履约这类链路，真正决定质量的不是模型这一次说得多漂亮，而是这一次协作有没有改变下一次的起点。

下一次开始时，AI 是否更容易拿到正确上下文？

是否更容易进入正确工具环境？

是否更容易被测试和证据约束？

是否更不容易重复同一种错误？

如果答案是肯定的，这次 AI 协作才真正进入了工程系统。

Prompt 让 AI 听懂你要什么。

Context 让 AI 知道事实是什么。

Harness 让 AI 能进入工程现场。

Loop 让 AI 的反馈进入下一次。

但 loop 之后，还要再问一步：

这些反馈有没有改变下一次的起点？

真正要建设的，不只是能执行任务的 AI agent。

而是一个能验证、能纠偏、能沉淀、能持续学习的 AI 工程系统。