上一篇讲的是思路，这一篇直接给可复用的打法：在 VS Code 里到底该怎么问、怎么拆、怎么验、怎么跟 Codex 协作。如果说第一篇是原则，这篇就是作战手册。
先给一份高频小抄
- 先别改代码，先找相关文件
- 先给最小方案，不要直接全局重构
- 先列风险点，再开始改
- 改完后给回归检查清单
如果你不知道该怎么开口，先用这四句，已经能避开很多低质量协作。
一、四类最常用的提问模板
1）理解现有代码
请先不要改代码，先告诉我这个功能涉及哪些文件、入口在哪里、数据是怎么流动的。适合接手旧项目、看不懂某段逻辑时用。它的价值是先建图，而不是急着改。
2）定位问题
这是报错信息 + 相关文件，请先判断最可能的 3 个根因，再告诉我最小排查路径。这样能避免它直接拍脑袋给一个看似合理的答案。
3）最小改动实现功能
目标是 XXX，不改接口协议，不动数据库结构，优先在现有框架里做最小改动实现。适合线上项目，能显著减少它过度重构的倾向。
4）重构整理
先指出重复逻辑和可抽离部分，再给一个低风险重构方案，最后分步骤改。把“先分析后动刀”写进提示词里，质量会高很多。
二、调试时最容易犯的错
最常见的错误其实不是它改错代码，而是你给的输入不够形成闭环。比如只贴一行报错，却不贴：
- 相关文件
- 调用链
- 触发条件
- 最近改了什么
结果就是它只能“猜”。而 AI 一旦开始猜，输出就会从工程问题变成文字游戏。
正确做法是让它同时看到：
- 报错
- 代码片段
- 运行环境
- 你预期它最终修成什么样
三、让它帮你排查 bug 的正确节奏
- 先让它列出最可能的原因，不急着改
- 再让它给验证步骤
- 确认根因后再让它动代码
- 最后让它写回归检查清单
这一套很像真实工程团队的排障流程。区别只是：以前是你自己做完整个闭环，现在多了个能读上下文的协作者。
四、多人协作时，AI 该放在什么位置
如果你在公司项目里用 Codex，最容易出问题的不是技术，而是边界不清。我的建议是：
- 让它做分析、样板、重构草案、测试补全
- 不要让它替你绕过评审
- 不要把未脱敏的敏感信息乱贴进去
- 最终提交前一定人工审阅
AI 可以帮你提速，但不该替代你对代码质量和安全边界的判断。
五、一个很实用的“先计划、再动手”模板
我自己很推荐这种说法：
先不要改代码。请你先：
1. 找出涉及的文件
2. 说明现在的实现方式
3. 给出最小改动方案
4. 标出风险点
5. 等我确认后再开始修改这能极大减少“它一上来就大改特改”的情况。尤其在你对项目还没有百分百把握时，非常有用。
六、什么时候该让它停下来
有几种情况，我建议你直接打断它：
- 开始大范围改与你要求无关的文件
- 开始重写整个架构，但你只想修一个点
- 回答越来越像泛泛建议，而不是基于项目现状
- 它自己都没解释清楚为什么这么改
一个好用的 AI 协作状态应该是：你在控方向，它在提执行效率。一旦方向感被它夺走，质量通常就开始下降。
七、把它真正用成“开发副手”
当你开始形成固定流程后，Codex 在 VS Code 里的价值会越来越明显：
- 新功能前，先帮你扫文件和调用链
- 重构前，先帮你标重复代码和依赖关系
- 报错时，先帮你列排查路径
- 提交前，先帮你做一轮差异审查和风险提示
这时候它不再是“偶尔补全两行”的工具，而是真正意义上的开发副手。
一个常见误用
很多人会反复把同一个模糊需求丢给 AI，希望它自己“越答越准”。现实里更高效的做法是：你不断缩小边界、补上下文、明确不该改什么。真正的效率，不是让它自由发挥，而是让它在你给定的范围内跑得更快。
结语
VS Code + Codex 的关键，不在于问得多复杂，而在于你有没有建立一套稳定的协作节奏。会问、会拆、会验证、会收口，它才会越来越像一个靠谱工程搭子，而不是一个会说很多话的代码生成器。