与 AI 一起工作 | 1. 我们需要的不是更快的 AI，而是更慢一点的判断

现在，写一份方案、整理一次会议、起草一篇文章，都可以在几分钟内得到一版看起来相当完整的答案。

这当然是好事。很多原本琐碎、消耗注意力的工作被压缩了，人终于可以把时间留给更重要的事情。但也正因为答案来得太顺滑，我们很容易把“已经生成”误认为“已经想清楚”。

AI 提供的是速度，而判断从来不是速度的副产品。

快，不等于已经理解

一个流畅的回答很擅长掩盖自己的来路。它会给出清楚的结构、自然的语言和足够自信的语气，于是我们很容易忘记追问：这个问题本身定义对了吗？它依据的事实可靠吗？如果照着做，谁来承担后果？

这些问题不难，却无法被“再生成一次”替代。

真正需要警惕的，并不是 AI 偶尔给出错误答案，而是我们在高效率中逐渐失去停顿的习惯。过去，人会因为资料不足而多查几页书；现在，答案太快抵达，反而让人跳过了提出疑问的那一步。

图中真正重要的不是最左侧的“快速生成”，而是中间那次主动的停顿。它并不拖慢工作，反而避免我们用很高的速度奔向一个没有想清楚的方向。

有三件事，值得刻意慢下来

第一，是输入任务之前。不要只问“帮我写一份方案”，而要先想明白：这份方案是给谁看的，要解决什么问题，什么算成功。问题不清楚，再漂亮的答案也只是把模糊包装得更有说服力。

第二，是采用结论之前。尤其当结论涉及事实、数据、他人评价或重要决定时，至少抽查其中一两条关键依据。我们不必把每次使用 AI 都变成审计，但应知道哪些地方一旦出错，代价会很高。

第三，是对外发布之前。AI 可以替我们完成初稿，却不能替我们署名、解释和负责。只要一段话以自己的名义发出，它就应当经过自己的判断。

三个常见的时刻

设想让 Claude Code 或 Codex“给项目加上用户登录”。它很快就能读代码、列计划，甚至写出一版可运行的改动。但“登录”到底意味着什么？只支持现有账号还是允许注册？谁能访问哪些数据？已有的部署方式和测试约束是什么？这些边界没有说清楚，工具越能干，越可能把一个模糊需求扩展成一大串并不需要的改动。这里需要慢下来的，是输入任务之前。

再设想让 AI 编程助手修一个线上报错。它可能很快定位到一处可疑代码，给出补丁，并解释为什么“这样就能修复”。这时最重要的不是马上接受改动，而是追问：报错能稳定复现吗？这个补丁覆盖的是根因，还是只掩盖了一个表象？现有测试是否真的证明它没有伤及别的流程？能生成代码，不等于已经完成验证。这里需要慢下来的，是采用结论之前。

最后是工具真正开始行动的时候。比如让 Codex 清理旧文件、批量迁移配置，或让接入外部工具的 Agent 查询数据库、发送消息。模型可以按指令执行，却不天然知道哪些文件仍在被依赖、哪些数据不该离开当前权限边界、哪条消息会影响协作对象。执行前确认范围，执行后查看变更，这并非不信任工具，而是在把责任留给真正能够承担它的人。这里需要慢下来的，是授权工具执行之前。

把判断留在工作流里

与其为自己规定复杂的使用规范，不如保留三个很小的动作：

1. 在提问前，先用一句话写下改动边界：要解决什么，不做什么。
2. 在采用前，要求工具给出可复现的验证方式，再看测试或实际结果。
3. 在授权执行前，确认它会改什么、访问什么，以及出错后怎样回退。

这些动作看起来有点“慢”，但它们让工具的速度真正服务于人，而不是让人被工具的速度推着走。

未来的差距，或许不在于谁更早拥有 AI，而在于谁能在答案唾手可得时，依然保持提问、辨别和负责的能力。我们需要的不是更快的 AI，而是在关键处更慢一点的判断。