把 AI 当作结对伙伴，而不是答案机器把 AI 当作结对伙伴，而不是答案机器

第一次用 AI 写代码时，我常常只给出一个模糊的目标，然后期待它交回一个完整答案。结果通常很像：代码看起来合理，却没有解决我真正关心的问题。

后来我发现，协作质量首先取决于我能否说清楚什么叫“做完”。

把愿望换成验收条件

“帮我优化这段代码”并不是一个容易验证的任务。优化什么？响应时间、内存占用，还是可读性？允许改变接口吗？必须兼容哪些输入？

我现在会先写下三个条件：

1. 当前行为是什么，可以怎样稳定复现？
2. 希望得到什么结果，用什么方式确认？
3. 哪些地方必须保持不变？

例如，一次日期解析任务可以写成：输入必须是 YYYY-MM-DD；非法日期应当报错；不同的机器时区不能改变输出。

让模型暴露假设

模型擅长补全，但补全并不总是我们想要的行为。缺少上下文时，一个流畅的答案可能只是把未经确认的假设藏得很好。

我会要求它在实现之前列出假设，尤其是可能影响数据和接口的部分。

请先检查已有实现，再说明：
- 哪些行为已经被测试覆盖？
- 你认为问题出现在哪一层？
- 最小修复涉及哪些文件？
- 还有哪些事实需要确认？

这一步不一定花很久。有时只是一句话，却可以省去后面整段错误方向上的实现。

小步反馈比长篇指令更有效

我更愿意让 AI 先实现一个可以运行的小切片，再根据实际结果调整。一次失败的测试、一条具体的错误信息，比“再聪明一点”更有帮助。

反馈应当描述观察到的行为。例如：“空数组输入时返回了异常，我希望返回零”，比“这里写得不对”清楚得多。

保留自己的判断

可以把生成交给工具，把判断留给自己。

审核时，我通常先看新增依赖、公共接口和数据流向，再看函数内部。某个局部实现很漂亮，并不意味着整个方案值得维护。

AI 能帮助我们更快地探索，但探索的速度越快，越需要明确的边界。真正有价值的协作，是每一步都能回答：这次变化解决了什么，我们怎么知道它已经解决？