AI 生成的代码跑不通，九成不是模型写错了语法，而是它拿到的上下文不完整：缺依赖版本、缺报错原文、缺你真正想改的那一个文件。把报错、文件、环境三样东西一次性喂进去，调试成功率比反复说”还是不行”高得多。
为什么 AI 生成代码总是”差一点”
模型的推理依赖上下文窗口。你只贴一句”这段代码报错了”，它只能猜运行环境、猜依赖版本、猜你改了哪些地方。猜错一次，后面的修改就在错误方向上叠加，越改越乱。
- 上下文缺失：没给完整报错栈、没给相关文件内容。
- 目标漂移：多轮对话后，模型记住的是早期需求，而不是最新改动。
- 验证缺失：没人告诉它”跑通哪条命令算成功”，它就按”看起来对”收工。
可复用的四步调试流程
第一步：锁定最小复现
先把问题压缩到一条命令或一个用例。能给单测就给单测，给不了就给一段最小脚本。模型对”可复现”的问题命中率远高于”偶发”描述。
第二步：完整投喂上下文
一次消息里包含四块内容：完整报错栈（不要截断）、相关文件全文、依赖版本（package.json / requirements.txt）、你期望的行为。不要分五条消息挤牙膏。
第三步：要求先定位再修改
明确要求：先给出根因判断和证据位置，再动手改。直接让它改，它倾向于”顺手重构”，把能跑的部分也改坏。
第四步：给出可执行的验收标准
告诉它跑哪条命令、期望什么输出。有明确验收点，它才会自己迭代到通过，而不是停在”应该可以了”。
一个实用句式：把报错原文、相关文件、依赖版本、期望输出贴在一条消息里，结尾加一句”先说明根因和依据的文件行号，再改；改完运行 <命令> 并把输出贴给我”。这一步能挡掉大部分无效来回。
三种常见卡点与解法
| 卡点 | 表现 | 解法 |
|---|---|---|
| 循环修改 | 改三版还是同一个错 | 清空会话，带上完整上下文重开 |
| 版本幻觉 | 用了不存在的 API | 贴官方文档片段或本地类型定义 |
| 改坏别处 | 一个功能好了，两个功能坏了 | 要求 diff 最小化，禁止顺带重构 |
什么时候该放弃让 AI 修，自己上手
当报错来自你没给它的外部系统（数据库真实数据、内网服务、构建流水线配置），继续追问只会消耗上下文。此时应当自己去读日志拿到事实，再把事实回喂给模型。模型擅长在给定事实上推理，不擅长凭空猜环境。
把调试成本前置到生成阶段
与其事后调试，不如生成前就给约束：项目规则文件写清技术栈与目录约定，任务描述里写明验收命令。相关的配置方法与实战经验可参考 Cursor Rules 项目配置，重构类任务的拆解方式见 AI 重构遗留代码实践。生成阶段多花一分钟写清约束，调试阶段能省十分钟。
AI 改的代码越改越乱，怎么止损？
立刻停止在同一会话继续追加要求，回退到 git 上一个可用提交，用完整上下文开新会话重新描述问题。上下文污染后继续追问，成功率只会继续下降。
要不要把整个项目都丢给 AI？
不要。全量投喂会挤爆上下文并稀释重点。只给相关文件全文加依赖清单，必要时让它自己先检索再读指定文件。
怎么验证 AI 的修复真的有效？
要求它先写一个能复现问题的失败测试，再修复，再让测试通过。没有失败测试，就无法证明修复命中了根因，可参考 AI 生成单元测试的方法。
同一段代码换模型会变好吗？
换模型能解决”单次能力不足”，解决不了”上下文不完整”。先把上下文补齐再考虑换模型，否则只是换一个猜错的对象。
评论 (0)