在答案出现之前

把一个问题交给 AI 之前，先用自己的话写下来：要改变什么，谁会受到影响，怎样才算完成。这几句话很朴素，却决定了后面是在解决问题，还是在欣赏一段看起来不错的代码。

我更愿意把判断理解为一种责任：能解释选择，也愿意承担选择的后果。它不要求每一行都由自己敲出来，但要求自己知道，哪些部分已经确认，哪些部分还只是猜测。输入框可以很短，问题的边界不能含糊。

读懂一次改变

阅读生成的代码时，最有用的问题未必是“这段写得好不好”，而是“它改变了哪些约定”。一个漂亮的函数可能悄悄改变错误处理，一个简洁的重构可能让原本容易定位的问题变得分散。

• 这次修改是否解决了最初的问题？
• 遇到空值、失败或重复请求时，会发生什么？
• 如果删掉其中一半，功能还成立吗？

这些问题不需要问得气势汹汹。它们只是让视线从输出的流畅程度，回到实际行为。看懂一小段，往往比接受一大段更踏实。

把信心换成证据

“应该没问题”可以是继续探索的起点，不能是交付的终点。让一个最小的例子跑起来，亲手触发一次失败，把关键输入和预期输出并排放着。需要什么证据，就做什么检查，不必为了显得严谨而堆满仪式。

如果暂时无法验证，就把未知写清楚。坦白地留下一句“这里还没有确认”，比用一段完整解释掩盖空白更有价值。生成工具可以帮助列出可能性，确认哪一种发生，仍然需要面对具体的环境。

保留那一秒停顿

最想保留的能力，是在按下接受之前停一秒：这是我认可的方案，还是只是第一个抵达的方案？如果没有工具在旁边，我能不能说清楚它为什么适合这里？

不是每个细节都值得深究。可以把机械性的工作交出去，把注意力放在目标、边界和取舍上。但这份分工需要主动发生。工具给出的速度越快，越值得给判断留一个明确的位置。最后留下的代码，应该是经过选择的代码。