最近我在用 AI 改代码时，越来越少直接丢一句“把这个功能做了”。我先让它做一件更土的事：把相关文件找出来。
这一步听起来很笨，但返工真的少很多。
为什么我现在先让它“勘测”
AI 一上来就改，最常见的问题不是写不出来，而是改错地方。
它可能会：
- 看到一个相似文件就下手，结果改到旧实现
- 没看清入口文件和调用链，补丁能跑但接不进去
- 顺手帮你“优化”几处无关代码，最后 diff 变大，审查变累
很多人把这类问题归结为模型不够强。我现在更倾向于把它看成施工顺序错了。
你让一个人刚进陌生项目就直接动手，他也容易乱拆。
我现在常用的三步
第一步，只找文件，不写代码。
我会先让它回答：这个需求最可能涉及哪些文件、入口在哪、数据从哪进哪出。
第二步，让它复述改动面。
不是让它开始生成，而是先说清楚：准备改哪几处，为什么改这些，不改哪些。
第三步，最后才让它提交补丁。
到这一步，如果它列出来的文件和思路基本对了，后面的代码通常会稳很多。
这个小动作，实际省掉了什么
省掉的不是几秒钟，而是后面的连锁返工。
尤其在老项目、多人项目、或者规则比较多的代码库里，真正贵的不是“写一段代码”，而是“写完以后发现改动面扩散了”。
先勘测一轮，相当于先把爆炸半径圈出来。
而且这里还有个额外好处：如果 AI 连相关文件都找不准，那问题通常不在模型，在你的任务描述。这个反馈来得越早越好。
我现在判断一个 AI coding 流程顺不顺，先看这个
不是看它一口气能写多少行。
我先看它会不会老老实实先读目录、找文件、讲清改动边界。
会这个，后面的代码才值得看。
不会这个，写得再快，也只是更快地把项目搅乱。