最近在技术社区里看到一个挺扎心的讨论：用了AI编程助手之后，代码产出翻了三倍，人却比以前更累了。
这不是个例。从Cursor到Copilot再到Claude Code，AI编程工具越来越强，但开发者的疲惫感似乎不降反增。问题出在哪？
从“垒砖”到“审稿”
过去写代码，像垒砖。每一行都是自己敲出来的，脑子里装着整个模块的结构，清楚知道哪里承重、哪里留缝。累归累，但收工的时候能看到一面完整的墙。
现在和AI结对编程，角色变了。你不再是一个建造者，而成了一个验收员——验收一个速度极快、从不喊累、但偶尔会自作主张的施工队。
它每交出一段代码，你得检查：逻辑对不对？边界条件考虑了吗？有没有调用一个压根不存在的API？这段代码会不会在某个角落里埋下隐患？
这种“审核”带来的消耗，和“创造”完全不同。创造是连贯的、沉浸的，大脑进入心流状态，多巴胺持续给正反馈。审核却是碎片化的、高警觉的——你的注意力在“理解这段代码”和“判断它是否正确”之间高频切换，这种切换本身就在大量消耗心力。
简单说：写一下午代码，累但满足。审一下午AI写的代码，累且空虚。
隐形成本：理解的时间超过了思考的时间
一个被很多人忽视的事实是：花在“理解AI写了什么”上的时间，正在悄悄超过以前花在“自己琢磨怎么写”上的时间。
以前写一个函数，从设计到实现，思路是连续的。你知道自己为什么这么写，也知道哪里可能有问题，因为这些问题你在写的过程中已经推演过一遍。
现在AI一口气吐出几十行甚至上百行，你必须从头读一遍，重新在脑子里跑一遍它的逻辑。这就像考试时帮别人检查卷子——字写得再好，思路不是你的，你得重新推导一遍，这比重做一遍还累。
更麻烦的是调试。自己写的bug，你大概知道它可能藏在哪——你对自己犯过的错有模糊的记忆索引。但AI写的bug完全是盲区。你不知道它当时为什么这么写，也不知道它在哪个环节理解错了。你只能一行一行地反向工程一个你并不了解的推理过程。
预期被拉高了，但思考时间没变
还有一层更难察觉的变化：老板和产品的预期变了。
以前评估一个功能要两天，对方说行。现在对方说：“你不是有AI吗？今天能弄完吧？”
AI写代码确实快，但AI解决不了需求不清晰、接口没对齐、边界条件没想清楚。这些东西始终得人脑来推演。AI生成的速度越快，留给“想清楚”的时间就越少，人就越焦虑。
AI并没有提高程序员工作的上限。它提高的是别人对你速度预期的上限。
以前你只需要做一件事——写代码。现在你在同时做三件事：想清楚需求、审核AI的产出、管理外界的预期。这三件事叠加，比单纯写代码累太多了。
怎么破局？几个实际的做法
疲惫归疲惫，总不能回到全手写时代。几个在实践中验证过的方法：
第一，给AI划定明确的边界。适合交给AI的是：脚手架代码、样板代码、单元测试、SQL查询。不适合的是：核心业务逻辑、涉及并发和状态的模块、任何需要长期维护的抽象。标准很简单——自己写不动的、写完了不心疼的，给AI；自己要对它负责的，亲手写。
第二，AI写的核心逻辑，看完再合。测试跑通不代表代码正确。AI生成的代码测试通过率是会骗人的——它可能恰好绕过了你没写出来的边界条件。一个模块上线三天后才发现数据竞争，就是因为测试没覆盖到那个场景，而AI恰好在那个地方用了共享可变状态。
第三，主动减速，不被工具带节奏。AI一秒吐几百行，但你不能被它催着走。生成越快，阅读越要慢。一个可行的原则是：AI写了多少代码，就用多少时间去理解它。不是扫一眼，是真的理解。
说到底
我们正在用一套为“人写代码”设计的流程和组织方式，去驱动一个“人+AI一起写”的新模式。中间的摩擦、冗余、心智开销，没人帮我们重新设计过。
很多人觉得累，不是因为他们不够努力，也不是因为AI不好用。而是因为他们的大脑不知不觉变成了AI的质检流水线——这本身就是一件极其消耗能量的事。
技术不会停下来等我们适应。我们能做的，是在拥抱效率的同时，主动为自己保留思考的时间。毕竟写代码这件事，最贵的从来不是敲键盘的速度，而是想清楚的那几分钟。
热门跟贴