最烦那种"我用 AI 三分钟搞定"的推文
AI 确实能提效，但三分钟搞定的不是你的代码，是你的智商税。
打开 Twitter 就想关掉
每隔几天，我的 timeline 上就会出现一条类似这样的推文：
"以前写这个要两天，现在用 Claude/GPT/Copilot 三分钟搞定，附截图。"
底下一片 "牛逼""AI 太强了""未来已来"。
然后我点开截图一看——一个 todo app。或者一个天气页面。或者一个登录表单。三分钟搞定的，本来就是三分钟能搞定的东西。
怎么说呢，这类推文让我产生了一种复杂的情绪：一半是 "这有什么好吹的"，另一半是 "我真的落后了吗"。后来我冷静下来想了想，发现这种焦虑本身就是被制造出来的。
AI 布道圈的话术套路
我观察这些 AI 布道者有一段时间了，发现他们的推文有几套固定模板：
"从零到一"模板。 展示一个 demo，强调 "从零开始"，忽略所有前置工作——你得先想清楚需求、先定义好接口、先选择技术栈。AI 完成的只是中间的编码环节。但推文的叙事是 "我啥也没想，AI 全帮我搞定了"。
"生产力飞升"模板。 "以前写一个功能要 X 小时，现在 Y 分钟"。从来不说以前那 X 小时里有多少是思考和调试的时间，现在 Y 分钟之后又有多少时间花在修 AI 的 bug 上。
"未来已来"模板。 任何一个小功能的 AI 辅助实现，都能被包装成 "程序员要失业了"。行了，三年过去了，程序员还在写代码，只是现在边写边跟 AI 吵架。
老实说，我一开始也中过这种毒。看到别人用 AI 写出漂亮代码，觉得自己不用就是落伍。后来实际用了才知道——好看归好看，能不能用是另一回事。
真实的 AI 编程体验
我从去年开始重度使用 Copilot 和 Claude，基本上能用 AI 辅助的场景都试过了。说说真实感受。
写脚本和工具函数，确实快。 这种有明确输入输出、逻辑简单、不需要太多上下文的代码，AI 确实能帮你省不少时间。一个数据格式转换的脚本，以前要写半小时，现在描述一下需求，几分钟就能出个能用的版本。然后你花十分钟修一下 edge case，基本就 OK 了。
写业务逻辑，能提效但有限。 复杂的业务逻辑需要大量上下文：这个字段是什么含义、这个判断为什么要这样做、这个跟那个模块是什么关系。AI 没有这些上下文，它只能根据你给的 prompt 猜。猜对了省时间，猜错了你还得花时间解释。
我有一次让 AI 帮我写一个订单状态机的转换逻辑。它生成的代码看起来很漂亮，但把 "超时未支付" 和 "用户取消" 两个状态的后续处理搞反了。这种 bug 不是写代码能发现的——你得理解业务才知道超时应该进退款流程而不是进发货流程。
调试和排查问题，因情况而异。 如果你能准确描述问题现象和错误信息，AI 确实能帮你缩小排查范围。但很多时候，bug 的根因是隐性的，你需要自己看日志、断点、理解运行时状态。AI 能给思路，不能替你排查。
写测试，比写代码还费劲。 很多人吹 AI 写测试很快，但我的经验是：AI 写的测试大部分是在测 happy path，真正的 edge case 覆盖不到。你想让它覆盖边界条件，得花很多时间描述场景——这个时间可能比自己写测试还长。
写文档，这个真的有用。 让 AI 根据代码生成 API 文档、README、注释，效率很高。而且它生成的文档格式通常比大部分程序员自己写的规范得多。
生产力的边界在哪
AI 编程的边界不是技术边界，是认知边界。
AI 不理解你的系统。 它不知道你为什么要这么设计，不知道哪些是历史包袱，不知道哪个模块碰不得。它看到的只是一段 prompt，不是你的整个技术决策链。
AI 不承担后果。 代码写错了，你半夜爬起来修。AI 的建议出了问题，它不需要负任何责任。所以你得为它生成的每一行代码负责——这本身就消耗注意力。
AI 不做权衡。 "要不要引入这个新依赖" "要不要为了性能牺牲可读性" "要不要为了赶进度砍掉这个功能"——这些工程决策需要上下文、经验、甚至直觉。AI 只能提供信息，不能替你判断。
AI 的"正确"是统计学意义上的。 它给出的答案是训练数据中最常见的模式。但软件工程中的很多决策恰恰需要反直觉、反常规——因为你的场景跟别人不一样。
说白了，AI 是一个非常强的执行工具，但它不是思考工具。你需要自己想清楚做什么、怎么做，然后让 AI 帮你加速执行。如果你连方向都没想清楚就让 AI 来做，它只会帮你更快地走向错误的方向。
那些推文没告诉你的成本
"三分钟搞定" 的背后，有很多隐性成本是推文作者不会提的。
Prompt 工程的时间。 为了让 AI 生成你想要的代码，你得花时间写清晰的 prompt。复杂的逻辑需求，prompt 可能要写好几段。这个时间算进去了吗？
审查和修改的时间。 AI 生成的代码你敢直接用吗？大部分人不敢。你得看一遍，理解一遍，改一遍。审查 AI 代码有时候比审查人写的代码还累——因为你知道人会犯哪些错，但你不知道 AI 会犯哪些错。
调试 AI 引入的 bug。 这类 bug 特别恶心，因为代码看起来是 "对的"——变量名合理，逻辑结构清晰，代码风格统一。但就是行为不对。你需要完全理解这段代码在做什么，才能发现问题。
认知切换的成本。 在 "自己写" 和 "让 AI 写" 之间来回切换，是有认知成本的。有些时候自己写到一半让 AI 接，或者 AI 写到一半自己改，上下文丢失的开销比你想象的大。
过度依赖的风险。 如果你习惯了 AI 帮你写大部分代码，你自己的编码能力会退化。不是说你不会写了，是你会变得不愿意写——因为手写太慢了。等到 AI 给不出正确答案的时候，你会发现自己也写不出来了。
我现在的用法
说这些不是为了反 AI。AI 确实是一个强大的工具，我在工作中每天都在用。只是用法跟那些推文描述的不一样。
把 AI 当高级 autocomplete，不当 developer。 让它帮你补全代码、生成样板、写格式化的逻辑。不要让它做架构决策，不要让它定义 API 接口，不要让它决定技术选型。
关键路径上的代码自己写。 核心业务逻辑、敏感的安全代码、性能关键路径——这些地方我不用 AI。不是因为它不能写，是因为这些地方出了 bug 代价太大，我不愿意承担审查 AI 代码的认知负担。
用 AI 做"第一版"，然后彻底重写。 有时候我想探索一个新方案，但不想从零开始。让 AI 先生成一个草稿，理解它的思路，然后用自己的方式重写。这个过程中 AI 的价值是 "帮你理清思路"，不是 "帮你写代码"。
用 AI 写不重要的代码。 数据迁移脚本、一次性工具、测试数据生成——这些代码不需要长期维护，用 AI 生成完跑一遍就扔。在这类场景下，"三分钟搞定" 确实是真的。
行了不装了
我身边真正在用 AI 提效的工程师，没人在发推文吹。他们就是默默地用，踩坑了就记下来，好用的地方就继续用。
而那些天天发 "AI 改变了一切" 的人，我看了看他们的 GitHub，大部分贡献是 README 和文档更新。
怎么说呢，这也是一种幸存者偏差——真正好用的东西不需要布道，而需要布道的东西往往没那么好用。
AI 确实在改变软件开发的方式，但不是以那些推文描述的方式。它不是让你 "三分钟搞定"，是让你 "同样三分钟但能想得更深"。它不是替代程序员，是把程序员从重复劳动中解放出来——然后去做那些更需要判断力和创造力的事。
至于那些推文，就当广告看吧。看完了该写代码还是写代码。
毕竟，真正靠谱的工程师，不需要靠发推来证明自己的生产力。
Q.E.D.
