AI Coding 系列（二）：怎样给 AI 准备上下文，才能真正理解你的代码库

AI Coding 系列二怎样给 AI 准备上下文才能真正理解你的代码库上一篇我们讨论了把 AI 当作结对程序员的工作流。这一篇解决更关键的问题为什么同一个模型在一个项目里表现惊艳在另一个项目里却频频“自信地写错”答案通常不在模型而在上下文。一、代码库上下文不是“把所有代码塞进去”AI 并不需要一次读完整个仓库。真正有价值的上下文是能帮助它做出正确局部决策的信息这个模块负责什么、当前改动的边界在哪里、数据从哪里来又到哪里去、团队有什么约定、什么行为绝不能被破坏。可以把上下文分成四层第一层任务上下文这次要做什么、不做什么、如何验收。第二层代码上下文相关入口、调用链、类型、配置与测试。第三层项目约束目录规范、依赖选择、错误处理、日志与安全要求。第四层历史上下文此前做过哪些取舍为什么不能简单推翻。二、先从“最小闭环”开始收集处理一个新需求时优先给 AI 这些材料• 入口路由、命令、事件处理器或公开方法。• 核心数据请求参数、领域对象、数据库模型、返回结构。• 调用链入口会调用哪些服务服务依赖哪些仓储或外部接口。• 现有测试它们最能说明系统真正承诺了什么。• 相邻实现项目里已经做过的类似功能往往比通用示例更可靠。不要把整个 node_modules、构建产物和无关日志丢进去。内容越多不等于理解越好无关信息会稀释重点也会增加错误关联的概率。三、用“上下文包”替代随手提问一个实用的上下文包可以写成下面这样项目电商订单服务TypeScript NestJS。目标新增取消订单接口。相关文件order.controller.tsHTTP 入口order.service.ts业务逻辑order.repository.ts持久化层order.service.spec.ts现有测试业务规则仅 PENDING 状态允许取消取消后必须记录审计日志不改表结构接口必须保持幂等。请先回答会修改哪些文件、每处修改的目的、需要新增哪些测试。不要输出实现代码。这个结构的优势是AI 先暴露理解再进入编码。若它把幂等性理解错了成本只是一次澄清如果直接生成代码错误可能已经扩散到多个文件。四、让 AI 主动追问而不是替它猜在提示里明确加入一句“缺少信息时先提出不超过五个最关键的问题不要自行假设。”这是提高可靠性的简单方法。好的 AI Coding 不是要求模型永远给答案而是让它知道何时应该暂停。常见的关键问题包括• 状态枚举和状态迁移规则在哪里定义• 取消操作是否要触发退款或库存回补• 审计日志的字段与落库方式是什么• 幂等请求返回 204、200还是业务错误• 是否存在旧接口或异步任务也会修改订单状态五、为项目准备一份“AI 可读说明书”如果团队经常使用 AI 辅助开发建议在仓库维护一个短小、稳定的说明文件。它不需要代替完整文档重点是让 AI 快速建立正确工作方式。建议包含技术栈与启动、测试、检查命令目录职责与主要模块代码风格和命名规则错误处理、日志、配置与密钥规范测试策略禁止事项例如不得修改公共接口、不得引入某类依赖提交前检查清单。它的价值很像新成员入职手册减少重复解释也让每一次协作从更高的起点开始。六、上下文使用的三条边界第一最小授权。只提供任务需要的文件和数据生产日志、用户信息、密钥一律脱敏或排除。第二事实优先。AI 对“项目大概如何”的总结不能代替代码、测试和构建结果。发生冲突时始终以可验证的项目事实为准。第三分段加载。遇到复杂问题先让 AI 阅读入口与测试只有定位到具体模块后再补充它需要的实现细节。这比一次性灌入大量内容更可控。结语AI 的输出质量很大程度取决于你给它的上下文质量。好的上下文不是更多文本而是更清楚的边界、更完整的最小闭环以及明确允许 AI 追问的机制。下一篇我们会进入实战如何把需求拆成 AI 最容易可靠完成的“小任务”并用测试和代码审查把它们重新组合成可上线的改动。