AI 应该提升你的思考，而不是替代它
一篇标题简单到近乎说教的文章，在 HN 上拿了 600+ 赞。Koshy John 的《A.I. Should Elevate Your Thinking, Not Replace It》戳中了一个所有人都感觉到、但很少人说透的问题：AI 正在把工程师分成两种人。
两条路，正在分叉
第一种人用 AI 消除重复劳动，把省下来的时间花在真正需要思考的地方 — 问题建模、权衡取舍、风险识别、架构决策。
第二种人用 AI 跳过思考。把 prompt 丢进去，拿到看起来合理的输出，当作自己的成果交上去。短期内这像是生产力，甚至像是天赋。但这是一条死路。
Koshy 用了一个精准的表达：intellectual dependency being labeled as leverage（把智力依赖包装成杠杆效应）。这比”AI 让人变懒”深刻得多 — 问题不是懒，是你在用一个你不理解的东西模拟理解。
判断力无法外包
这个观点为什么能引起 600 多人的共鸣？因为它描述的不是假设，是现实。
我每天 review 代码时已经能感觉到了。有些 PR 看起来很”干净” — 命名规范、注释到位、结构工整。但你追问一句”为什么选这个数据结构？”，对方答不上来。不是他不会，是他根本没想过。模型替他想了，他只是点了一下 Accept。
Koshy 指出，这对早期职业阶段的工程师尤其危险。资深工程师至少有存量的判断力可以倚仗；刚入行的人如果一开始就跳过了”自己想明白”这个过程，他们积累的不是能力，是对 AI 输出的信任 — 一种脆弱的、不可迁移的信任。
判断力是练出来的，不是看出来的。 就像你不能通过看别人健身来获得肌肉。每次你把一个问题交给 AI 然后直接用答案，你跳过的不是一次编码，是一次思维训练。
正确的用法
那 AI 到底该怎么用？Koshy 的答案很实在：
The most valuable engineers will refuse to spend time on work that A.I. can do for them, while still understanding everything that is done on their behalf.
翻译一下：让 AI 干活，但你得搞懂它干了什么。
这在实践中意味着：
- 生成代码后，逐行读一遍。 不是为了找 bug（虽然经常能找到），是为了确认你理解它的设计意图
- 用 AI 做初稿，用自己的脑子做决策。 让模型列出方案，但选哪个、为什么选，必须是你的判断
- 对 AI 的输出保持怀疑。 模型擅长生成看起来对的东西，但”看起来对”和”真的对”之间有一条沟
我自己的习惯是：如果我无法向别人解释为什么这段代码是这样写的，那我就不应该提交它 — 不管它是我写的还是 AI 写的。
组织层面的隐患
Koshy 还提了一个更深的点：当整个团队都在用 AI 外包思考时，组织失去的不只是个人能力，是集体的判断力基线。
没人能发现 AI 生成的方案里的隐含假设。没人能在 review 时问出关键问题。没人能在系统出故障时从第一性原理推导出根因。所有人都在”看起来很高效”地运转，直到一个需要真正理解的问题出现。
这让我想到一句话：AI 不会取代工程师，但不思考的工程师会被会思考的工程师取代。
我的看法
这篇文章说的道理不新，但在 2026 年的当下格外重要。
我们已经过了”AI 能不能用”的阶段，进入了”AI 怎么用才不会废掉自己”的阶段。工具越强大，使用者的责任就越大。一把好刀不会让你成为厨师 — 知道在哪里切、切多深，才会。
作为工程师，最值钱的不是你能多快写出代码，是你能多快想明白该写什么代码。AI 可以加速前者，但后者只能靠你自己。
如果你在多个 AI 模型之间频繁切换，推荐试试 OfoxAI（ofox.ai）— 一个账号搞定 Claude、GPT、Gemini 等主流模型。工具选对了，才有更多时间留给真正的思考。