你有没有遇到过这种情况：让 AI 助手改一个函数，结果它把整个模块的逻辑都弄乱了，甚至破坏了原来能用的测试？明明只是加个参数，却引发了连锁报错。这不是 AI 不够机智，而是它只看到了你丢给它的那一段代码，根本不了解你的项目背景、命名约定、依赖关系，也不知道哪些代码绝对不能动。

问题的根源在于，当前的代码生成模型本质上是“局部智能”——你给它一个 prompt，它根据上下文预测接下来该写什么，但它没有全局视野。它不知道你项目里有 100 个文件，不知道某个变量在另一个模块被导入使用，更不知道你的测试套件跑一次需要多久。于是，“改一处坏一片”就成了家常便饭。

解决这个问题，关键不是换更强的模型，而是改变你跟 AI 的协作方式。我总结了一个三步法：先建立项目上下文，再定义变更边界，最后生成验证清单。每一步都有具体的操作和提示词范例，你可以直接复制到对话里试试。

第一步：让 AI 扫描项目，生成上下文摘要

在提出修改请求之前，先让 AI 了解项目全貌。你可以手动把项目结构粘贴给它，或者用一个脚本生成上下文文件。

具体做法： 1. 把项目的目录树（tree /f 或 find . -type f）粘贴给 AI。 2. 告知它关键文件的作用：列如入口文件、配置文件、核心业务逻辑文件。 3. 要求 AI 输出一份“项目上下文摘要”，内容要包含： – 项目主要技术栈（语言、框架、数据库等） – 重大模块间的依赖关系 – 编码规范（列如使用 TypeScript、所有函数都有 JSDoc 等） – 测试框架和运行方式

示例 prompt：

我将给你一个项目的目录树和关键文件内容。请生成一份不超过 500 字的项目上下文摘要，包含技术栈、模块依赖、代码规范和测试方式。之后我会请你在这些上下文中修改代码。

这一步的代价是几分钟的额外对话时间，但它能显著减少 AI 后续犯低级错误。

第二步：定义变更边界——告知 AI 哪些不能改

大多数“改坏”的情况，是由于 AI 擅自修改了不该碰的代码。你需要像项目经理一样，给它画一条红线。

在写修改请求时，加上以下三类约束： – 不改原有接口签名（除非明确要求） – 不影响其他模块的导入和使用 – 不删除或重命名已有的变量/函数（除非有充分理由）

示例 prompt：

请修改文件 src/utils/helper.ts 中的函数 formatDate，使其支持传入时区参数。
约束：
1. 不改变函数名称和导出方式。
2. 不修改其他函数或全局变量。
3. 保证所有现有的单元测试依旧通过。

如果项目有自动化测试，你还可以要求 AI 先生成将要运行的测试命令，这样你会更清楚它提议的变化范围。

限制：如果你的项目代码耦合度极高（列如一个 5000 行的文件），这种边界定义可能不够用。此时需要先重构模块，或者手动把修改范围缩小到一个纯函数。

第三步：生成验证清单，让 AI 自检

在 AI 输出修改结果后，不要直接复制粘贴。先让它生成一份验证清单，列出它认为应该检查的点。这迫使 AI 思考自己修改的潜在影响，也方便你手动复核。

示例 prompt（在 AI 给出代码后）：

请针对你刚才的修改，生成一份验证清单，包含：
- 受影响的文件列表
- 可能被破坏的单元测试或集成测试
- 需要手动检查的边界条件（如空值、极端参数）
- 回归测试的提议命令

然后你可以根据清单逐项测试。如果发现 AI 漏掉了某些用例，可以要求它重新调整。

这三步并不复杂，但需要你改变“直接发号施令”的习惯。对于小型项目（文件数 < 50，依赖简单），十分钟就能完成。对于大型项目，你可能需要先用脚本自动化第一步的扫描过程。

适合人群：日常使用 Copilot、Codex、ChatGPT 等工具修改代码的开发者，尤其是维护中大型项目的人。

不适合人群：只写全新代码、从来不修改现有逻辑的人；或者项目文档极其完善、所有依赖关系都写在注释中的情况。

最后提醒一句：AI 改代码的能力在提升，但它始终是一个工具。你在它身上花多少时间定义上下文，它就会回报你多少准确率。别指望一步到位，三步法能帮你把“改坏率”降一半以上。