作者是 Claude Code 团队的工程师，他自己天天用 AI，也很喜欢 AI。他这篇文章不是叫你少用，而是提醒：AI 越好用，人越容易不动脑。
以前 AI 经常犯明显的错，你自然会盯着它。现在它写出来的东西又漂亮、又基本正确，你看一眼觉得"没毛病"，就过了。
就算你同时开了好几个 AI，看结果的眼睛还是只有你这一双。
没有人会逼你思考，所以你得主动把"想一想"放进每天的工作里。
最可怕的是：这个滑落是一点一点发生的，每一步都觉得很合理。
判断标准：就算让 AI 帮你，你也讲不清这个结果为什么对，那它就已经不归你了。
不需要什么都懂。大项目没人能全记住，需要时让 AI 给你讲清那一块就行。关键是你得知道自己哪里不懂。
错了也没多大事。
后果要别人来承担。
我先猜过答案吗？问 AI 之前先自己猜一个，猜错也没关系。读完一个漂亮回答后，你就很难想到别的可能了。
我是让它帮我想，还是替我想？两种都行，但你得知道自己选的是哪种。
如果它错了，会是因为什么？想出来，然后真的去试一下。AI 说"我很确定"不算数，实际测一下才算。
听过反方意见吗？有争议的事，让 AI（最好不止一个）站到对面去反驳。
敢当着以后要维护它的人拍胸脯吗？这是"能不能交付"的标准。
我已经不再练哪些本事了？有些可以放弃，但要是你自己决定的，而不是不知不觉丢掉的。
所以要做到三件事：
先定好"什么样才算完成"。事后再定，你会给任何结果找理由。
AI 说"做完了"时，先看它实际跑了什么命令、输出是什么，再看它的总结。完成要看得见：测试结果、截图、日志。
做完后问一句"我还有什么漏掉的吗？"作者说几乎每次都能再挖出两三个问题。
变量名看着合理，测试也过了，你就批准了。但中间可能悄悄改了一个执行顺序，或者翻转了一个默认值。你确实"看过"，但只看到了你本来就想找的东西。
如果产出多到你根本审不过来，那你已经不是在审查，而是在祈祷。
这时该做的是放慢，而不是再开一个 AI。
要求说得模糊时，以前同事会追问你"你到底想要什么"。AI 不会追问，它会自己把空白填上，交给你一个看起来完成了的东西。
你说不清楚，往往是因为你自己还没想清楚。
改了两轮还不对？别再小修小补，把需求重新写一遍。
不确定时，让 AI 反过来采访你，问出它没搞懂的地方。
AI 之间互相传摘要，传到第三个就没人读过原文了。
东西出了问题，最后担责的是人。而且"这件事该多信 AI"本身就是一个判断，你得一直练着才能判断准。
要监督 AI，需要的恰恰是那些用多了 AI 会退化的本事。
更强的模型也替不了你回答这些问题：做什么？为什么值得做？会影响谁？你愿意放弃什么？
先说一句你的猜测："我觉得是 X 的原因"。我的结论和你不一样时，正好查查谁错了。
讲清三件事：要做什么、不用管什么、做到什么程度算完成。
问我：反过来论证一下，另一种方案好在哪？ 或 什么情况下你这个结论是错的？
删除文件、取消任务（scancel）、覆盖数据、上线代码：让我先说方案，你看懂了再点同意。别条件反射地点"同意"。
先让我讲原理，你自己写，我来检查。作者引用的研究里，直接让 AI 生成代码的人，事后测验分数低了 17%。
别只看其他 Claude 会话的总结，要它们附上原始命令和日志路径。审不过来就少开几个。
重要任务时，可以把下面这段直接贴给我：
做完后，在写总结之前，按顺序给我： 1. 你替我做的所有决定和假设（用了什么默认值、冲突时选了哪边、哪些没做） 2. 你实际运行的检查命令，以及原始输出 3. 这些检查证明了什么，没证明什么 4. 关于这次改动的 3 个小问题（不带答案），我答对了才采用
问之前写下"我觉得会怎样"；做完后写下"它有一件事没检查"。
不用 AI，自己动手做一件"忘了会很糟"的事。
列一下"我已经不再自己做的事"，决定哪些真的可以放弃。问问自己：如果明天没有 AI，我会多迷茫？