刚开始使用 AI 编程助手时，我很容易把它当成一个“更聪明的自动补全”：写一句需求，然后期待它交出能直接合并的代码。偶尔确实成功，但更多时候是表面看起来完整，细节却和项目习惯对不上。后来我慢慢意识到，AI 的上限常常取决于它拿到了多少有效上下文，以及任务有没有清楚的边界。
第一步不是提问，而是给上下文
如果同一个需求交给刚加入项目的同事，我们大概会先告诉他入口文件、现有实现、测试位置和不能破坏的行为。对 AI 也应该如此。我的习惯是先让它阅读相关目录，概括目前的数据流，再开始讨论修改方案。
这一步看似多花了一轮对话，实际上最省时间。它能提前暴露误解，比如把服务端状态当成本地状态、忽略项目已经封装好的请求函数，或者准备安装一个仓库里根本不需要的新依赖。
先阅读以下文件，不要修改：
- src/features/search/
- tests/search.spec.ts
请说明筛选条件从输入到 URL 的流向，
并列出你认为需要改动的文件。把“做完功能”改成几个可检查的动作
“给列表加筛选”通常包含状态、URL 同步、空结果、移动端布局和测试。一次全部生成，任何一处理解错误都会扩散。我现在会先让 AI 完成最小闭环，例如只增加纯函数和单元测试；确认无误后，再接到组件上。
一个好的子任务应该能用一句明确的话验收，而不是只能凭“看起来差不多”判断。
拆分也方便回退。某一步方向不对，只需要丢掉这一小段改动，不会连带清理半天生成代码。
给改动范围画一道线
AI 很喜欢顺手整理代码：改命名、抽工具函数、更新相邻样式。很多改动单独看没问题，放在需求里却会增加评审成本。我会明确写出“只修改哪些文件”“不要改公共 API”“不要新增依赖”。如果确实发现结构问题，让它先记录建议，不要混进本次补丁。
AI 完成，不等于任务完成
最后一步仍然是人来验收。我会看完整 diff，而不只看 AI 的总结；运行相关测试和构建；再用真实操作走一遍主路径。尤其要留意“为了让测试通过而降低断言”的情况，这比没有测试更容易带来错觉。
现在我的流程可以缩成四句话：先读项目，复述理解；拆成小步，逐步实现；限制范围，减少惊喜；运行验证，审查差异。它不神奇，但比不停寻找“万能提示词”稳定得多。