AI 写代码出错后反复修改仍无效，是许多开发者的困惑。其根源不在于 AI 能力不足，而在于人机协作的模式。本文揭示了如何通过提供架构级指引而非症状级描述，让 AI 成为高效的执行者，从根本上解决问题。
智能速览
向 AI 反馈报错信息属于症状级修复，无法解决架构层问题。
AI 生成的代码与测试可能共享盲区，制造“一切正常”的假象。
提供架构性约束和方向，能让 AI 一次性完成跨文件的精准修改。
AI 是能力的放大器，使用者的领域知识和判断力决定了其最终效果。
精华内容
当 AI 在错误的代码架构上缝缝补补时，只会陷入越改越错的循环。打破困局的关键，在于改变协作的思路。
症状级修复的陷阱
一个典型案例是，AI 生成的 C 项目中，本应 300ms 并发完成的请求耗时 905ms。向 AI 反馈错误信息后，它连续三轮修改，只是换了一种方式继续串行，甚至引入了新错误。
问题在于，报错信息只是症状，而非病因。AI 的 DNS 解析、socket 创建等每一行代码或许都是对的，但它们被组织在了一个错误的架构上。在错误的基础上打补丁，只会让整体结构更混乱。
测试与代码的共谋
更值得警惕的是，AI 生成的测试代码本身也存在盲区。在一次代码审查中发现，bench 模式下所有 HTTP 请求均告失败，但测试报告却显示 0 错误，全部通过。
原因是代码将每一次调用都无条件计为“成功”，而测试也只验证了这个数字。实现与测试由同一模型生成，它们拥有一致的认知缺陷，完美地互相配合，构建了一个外人难以察觉的错误闭环。
从给方案到给方向
破局的关键在于改变提问方式。当不再提供报错信息，而是给出一个架构级指令：“fetch 不要自己管事件循环。创建连接，注册到全局事件循环，返回一个 pending Promise。I/O 由全局事件循环统一驱动。”，AI 一次性便将 9 个文件全部修改正确，耗时从 905ms 降至 302ms。
另一个例子是，提出“每个线程有且只有一个 epoll”的约束，AI 能立刻用 thread-local 存储重写所有接口，十几处修改无一遗漏。你的一个准确判断，AI 能将其落实到每一行代码上。
四个实操建议
不要贴报错，要讲方向。给出“这一层不应该知道上面那一层的存在”这类约束，而非具体修改方案。
AI 卡住时，问题往往不在卡住的地方。可能是别处的耦合导致无法封装，需先解耦。
使用最强模型，并开启手动确认模式。架构级改动需要强大理解力，手动确认能帮你把关每一步。
务必审查测试本身。确保测试验证的是真正的业务结果，而非仅仅是“有输出”。
AI 不会取代有经验的开发者，而是放大其专业能力。未来的编程，将是人机智慧深度协作的时代。你是否也找到了与 AI 高效共舞的节奏？
关键评论
AI 写代码取代不了程序员，反而是保护高水平的程序员，因为它提高了门槛。
AI 应该用于协作开发，而不是用于替代开发，它是跟在使用者的思绪后面跑的。
AI 写代码的水平跟输入指令者持平，如果指令者自己没发现问题，AI 也无法突破。
