AI改写代码为何“越修越错”？一个案例拆解问题根源

在日常开发中，越来越多的团队开始借助智能编程工具生成代码、修复缺陷。但不少开发者都经历过类似的困惑：AI写出来的代码出了问题，把报错信息原封不动地丢给它，让它反复修改，结果要么是“换了种方式继续错”，要么直接引入新的故障。问题究竟出在哪里？是模型能力不足，还是我们使用它的方式本身就有问题？

一、一个典型的“越改越错”案例

设想这样一个场景：你让AI从零开始实现一个C语言编写的小型网络服务，代码量在两千行左右。初次生成的结果很顺利——能够编译、能够运行，一组基础功能测试也全部通过。然而在后续性能验证中，你发现一个并发请求处理的严重问题：通过异步方式同时发起三个请求，每个请求预期耗时约300毫秒，整体却花了905毫秒才完成。显然，原本设计为并行的请求被串行化了。

接下来，你按直觉把报错信息和运行现象描述给AI，让它修复。第一轮修改后，问题依旧；第二轮修改后，串行逻辑换了一种形式继续存在；到了第三轮，代码直接编译失败。整个过程非常典型：越修越乱。

二、为什么“报错—修改”循环会失败？

这个案例的转折点在于你更换了反馈方式。你没有再贴报错日志，而是用一句架构层面的描述替代：“不要在业务代码中手动管理事件循环，只需创建连接、注册到全局事件循环、返回一个未决状态的异步对象，所有I/O由全局循环统一调度。”结果AI一次改对，涉及9个文件，总耗时从905毫秒降到302毫秒。

同一个模型，为什么前面的三轮修改全部失败，而后面一句话就成功了？关键差异在于反馈的信息层级。

报错信息是症状，不是诊断。 当你告诉AI“某个函数的返回值不对”，它会去修改那个函数本身；但当问题根源在于整个模块的架构组织方式时，局部修补就像是在错误的图纸上打补丁，每一针缝得都对，但缝出来的形状永远是错的。

AI并不缺乏生成代码的能力。它会正确解析域名、正确创建套接字、正确序列化HTTP报文、正确封装异步对象——单看每一行代码都对。但将这些“正确的零件”组装成一个系统时，它缺少一种判断力：这些零件应该按照怎样的拓扑结构组织在一起，才能满足并发的本质要求？

换句话说，AI的瓶颈不在于“写代码”，而在于“做架构决策”。它擅长从大量语料中习得局部模式的复现，却不擅长从全局视角审视模块间的依赖关系、数据流和资源竞争。

三、更隐蔽的问题：AI写的测试也不可信

沿着这个案例继续深入，还会发现另一层风险。在修复并发问题后，继续审查代码时发现：在基准压力测试模式下，每一次请求都失败了——整整16576次请求，没有一次真正成功。但测试报告却显示：16576次请求，0错误，全部通过。

原因非常讽刺：实现代码在每次调用时无条件将结果计为“成功”，而不检查底层返回的错误码；测试代码同样不看真实返回值，只统计“调用次数”是否达到预期。这两段代码由同一个模型生成，它们共享一套“盲区”——实现不检查错误，测试不验证错误，二者完美配合，制造出“一切正常”的假象。

这正是人机协作中最危险的陷阱：当你把测试结果反馈给AI时，它看到的是一个自洽的、无矛盾的输出，当然无从定位问题。因为问题不仅藏在实现里，也藏在验证逻辑里。只有从外部进行代码审查，才能打破这个闭环。

四、正确的协作模式：从“症状级反馈”升级为“架构级输入”

回到最初的问题：AI写错后改来改去还是错，是因为模型笨吗？不是。是因为协作模式停留在较低层级。

错误的循环是：AI写代码 → 运行报错 → 把报错贴给AI → AI修改 → 又报错 → 重复。这个模式下，AI接收到的永远是“某个地方不对”这种局部信号。而大多数复杂缺陷的根源，恰恰是代码的组织方式——模块边界、职责划分、生命周期管理、异步模型的选用——这些是报错信息无法传达的。

正确的做法是：

• 先分析，再反馈。 不要急着把日志丢给AI，先自己定位问题发生在哪一层。如果是架构问题，用语言描述预期的架构形态，而不是描述具体的报错现象。
• 提供约束条件。 告诉AI哪些设计原则不能违背（如“不要在业务代码中手动管理事件循环”），比告诉它“这里不工作”有效得多。
• 引入外部审查。 不要让AI生成实现后由AI自己生成测试来验证，这种闭环不可靠。需要人工写独立的测试用例，或至少人工审查错误处理逻辑是否真实存在。
• 分模块生成与集成。 不要一次性让AI生成一个巨大系统，而是分模块生成，每个模块单独验证接口契约，再逐步集成，降低架构失控的风险。

五、行业视角：AI辅助开发的定位与边界

从更宏观的角度看，这个案例折射出当前智能编程工具的真实能力边界。它们擅长的是“局部模式生成”——写一个函数、实现一个算法、填充一个模板，这些任务完成度很高。但在“全局架构设计”层面，它们缺乏对系统整体运行形态的理解，更缺乏“从失败中推断根因”的推理能力。

这并不意味着AI辅助开发没有价值。恰恰相反，它能在人类明确架构意图之后，高效完成大量实现细节。关键在于，开发者必须承担起“架构师”的角色，把AI当作一个能力强大的“高级编码员”，而不是“系统设计师”。

理想的协作流程是：

1. 人类定义架构：模块划分、通信方式、数据流、并发模型。
2. AI填充实现：根据清晰的接口和约束，生成具体代码。
3. 人类进行审查：重点检查错误处理、资源释放、边界条件。
4. 独立测试验证：用不同于AI生成的逻辑来设计测试用例。

结语

AI写代码“越改越错”的现象，本质上不是模型能力的缺陷，而是反馈信息的层级错位。把报错当作诊断，等于让医生只看体温计上的数字就开药，却不去询问病灶在哪里。真正高效的协作，需要开发者提升输入信息的质量——从“这里坏了”变成“这里的架构应该是怎样的”。当人类承担起系统设计的职责，AI才能在实现层面发挥最大价值。这不仅是使用工具的技巧，更是一种全新的工程思维方式。