AI 辅助编程最诱人的承诺是：机器帮我们写掉无聊的部分，人就能少干一点，把时间留给更有创造性的工作。
但很多工程师的真实体感并不是这样。代码生成变快之后，工作并没有自然变轻松，反而变得更密。你一边写 prompt，一边审查 AI 生成的代码，一边追着 bug 解释模型为什么走偏。任务完成得更快了，但脑子也更快被榨干。
Evil Martians 最近写了一篇文章，专门讨论这个问题：AI-assisted 工程师为什么会 burnout。它的重点不是“AI 会不会替代程序员”，而是一个更近、更现实的问题：如果 AI 已经进入日常开发，我们怎样才能不被它拖进更高强度、更低满足感的工作循环？
真问题不是未来，而是今天怎么工作
围绕 AI 编程的讨论，经常会滑向几个宏大问题：
- AI 能不能独立解决复杂工程问题？
- 代码质量到底够不够？
- 工程师会不会被替代？
- 效率是不是唯一指标？
这些问题当然重要，但它们太容易把人拉进未来焦虑。对今天坐在电脑前工作的工程师来说，更重要的是另一组问题：
- 这些工具现在到底适合做什么，不适合做什么？
- 我该怎样把它嵌进自己的工作流？
- 使用 AI 之后，我的精力、判断力和成就感会发生什么变化？
- 这种工作方式能不能长期持续？
很多人讨论 AI 的命运，却忽略了自己的能量账本。工具也许会留下来，但你能不能以健康的状态留在这个行业里，反而是更急迫的问题。
AI 的效率陷阱：时间少了，强度高了
假设有两个工程师都要完成一个 4 小时左右的功能。
一个人按传统方式做：自己想设计、自己写代码、边写边调整。整个过程可能慢一点，但认知负荷是分散的。写代码的动作本身也会带来反馈：这里抽象对了，那边测试过了，系统在脑子里慢慢成形。
另一个人使用 agent：先写计划，再让 AI 生成实现，自己负责审查、纠偏和调试。表面上看，他可能 2 小时就完成了同样的功能。
问题在于，后者不是“少工作了 2 小时”，而是把原本 4 小时里分散发生的思考、判断、审查和修正压缩进了 2 小时。
更糟的是，任务提前完成后，人往往不会真的停下来。因为 AI 让这件事看起来“很轻松”，你会觉得自己还能再接一个任务。于是 4 小时里，传统工程师完成了一个稳定任务，而 AI-first 工程师完成了两个高强度任务。
这就是效率陷阱：AI 降低了生成代码的摩擦，却没有降低理解、判断和负责的成本。相反，它常常把这些成本集中到更短时间里。
为什么 AI 写代码会削弱成就感？
传统编程里有一个很重要的循环：
- 规划
- 亲手构建
- 看到结果
这个循环不只是交付机制，也是成就感来源。你在实现过程中理解系统、碰到阻碍、做出取舍，最后把东西跑起来。很多工程师喜欢编程，并不只是喜欢“功能上线”，而是喜欢中间那段专注、试探和逐步成形的过程。
AI-first 工作流改变了这个循环。你从“规划”直接跳到“结果”，中间的构建过程被模型拿走了。你面对的不是自己一行行写出来的代码，而是一大块需要审查的输出。
于是工作里最让人有连接感的部分减少了，最消耗脑力的部分增加了：
- 写代码变少
- 审代码变多
- 做判断变多
- 追溯模型推理变多
- 对结果的所有权变弱
这会带来一种奇怪的空心感：东西确实做完了，但不像“我做出来的”。成就感不足时，人很容易用更多任务来补偿。于是工作量继续增加，疲惫继续累积。
这像一次悄悄发生的职业变化
很多人选择做程序员，不只是因为软件有商业价值，而是因为喜欢编程这个活动本身。就像画家喜欢画画，作家喜欢写作，工程师也喜欢把抽象问题变成可运行系统。
但当 AI 接管越来越多“写”的部分，工程师的日常工作会逐渐转向：
- 定义目标
- 拆任务
- 写 prompt
- 设计约束
- 审查输出
- 调试生成结果
- 维护质量边界
这些仍然是工程工作，但体感已经不完全一样了。职位名称没变，职级体系没变，组织对产出的期待甚至更高了，可你的实际工作内容已经悄悄变成另一种职业形态。
面对这种变化，大致有几条路：
- 学会欣赏这种新工作方式，并重新建立可持续的节奏。
- 完全无视 AI，继续按旧方式工作。
- 勉强使用 AI，但一直怀念过去的 craft 感。
- 彻底转向别的领域。
现实一点看，第一条路最值得投入。不是因为 AI-first 工作流天然更好，而是因为它已经进入现实工作。与其一边使用一边被它消耗，不如主动设计新的边界和节奏。
AI burnout 的几个日常来源
1. 上下文从脑子里流走
使用 agent 时，模型掌握的上下文越来越多，人自己掌握的上下文可能越来越少。
你不再需要亲自穿过每个模块、每个边界条件、每个历史决策。它们开始存在于 prompt、工具调用和 agent 的上下文窗口里。短期看这很省事，长期看会削弱判断力。
工程判断很大程度来自沉浸。你越了解一个系统，就越能提前闻到坏味道，知道哪些捷径会在以后变成债。反过来，如果你只是监督一个自己不再真正理解的系统，工作会变得非常累。
2. 没有留给被动思考的时间
传统开发里，很多思考不是在“正式思考”时发生的。你写着写着，脑子在后台处理问题；走路、洗澡、睡前，答案可能自己冒出来。
AI 会把沉默填满。你还没来得及真正想清楚，模型已经给出方案。你开始快速同意、否定、修改它的建议。看起来效率很高，但很容易错过那些慢一点才会出现的连接。
结果就是：一开始的方案看起来还行，生成了一堆代码之后，才发现方向不够好，只能返工。
3. 初期速度制造了错误预期
刚开始用 AI 做项目时，很容易产生一种兴奋感：功能一个接一个出现，进度条跑得飞快。
但这会迅速变成新的基线。你自己会以这个速度要求自己，客户或管理者也会以这个速度预期后续交付。一旦项目进入复杂区，速度自然下降，你就会觉得自己“变慢了”。
真正危险的不是 AI 让你快，而是它让所有人误以为这种速度可以长期保持。
4. Review 变成新的瓶颈
AI 让写代码更快，但团队里的 reviewer 没有变成三倍。
生成代码越多，需要审查的代码也越多。更麻烦的是，很多 AI 生成代码并不是“明显错”，而是“表面能跑，但架构、边界和长期维护性都有隐患”。这种代码最耗资深工程师的注意力。
如果团队里有人把 AI 生成的代码直接丢给 reviewer，质量责任就会集中到少数人身上。生成端轻松了，评审端过载了。
这也是我之前写过的那篇 AI 写代码越来越快，开发团队却越来越累 里讨论的核心问题：代码生成速度提升之后，真正稀缺的是上下文、判断和 review 吞吐。
5. 可能性太多，边界消失
手写代码时，尝试一个新方向是有成本的。这个成本本身会帮你做筛选：这个想法值不值得试？
AI 把这种摩擦降得很低。每个新想法都只需要一个 prompt。于是你很容易不断分叉、不断试验、不断“再让它改一下”。等你意识到已经花太久时，注意力和精力都已经被消耗掉了。
怎么让 AI 编程更可持续？
原文最后给了一组自救建议。放到日常工程工作里，我觉得可以归纳成五件事。
第一，重新承认自己的贡献
AI 生成了代码，不代表你没有工作。
目标定义、上下文选择、约束设计、方案判断、质量把关，都是实打实的工程劳动。只是这些劳动不像手写代码那样可见，所以更容易被低估。
可以试试几个动作：
- 每天记录自己完成了哪些任务，而不是只看生成了多少代码。
- 在团队里展示结果，讲清楚你做了哪些判断和取舍。
- 记录工作时间，让高强度 AI 任务在时间上变得可见。
- 把“我只是让 AI 写了”改成“我完成了一次设计、审查和交付”。
成就感不会凭空回来，它需要被看见。
第二，先规划，少返工
AI 工作流里最值得投入的不是“让它赶紧写”，而是“让它先想清楚”。
一个更稳的流程是：
- 先让 agent 出计划。
- 认真读计划。
- 在计划阶段修正错误和遗漏。
- 把任务拆小，尽量一次只推进一个明确边界。
- 如果 3 到 4 轮还没有得到靠谱结果，停下来换方法，不要继续硬磨。
生成代码很便宜，但审查错误方向上的大量代码很贵。前面多花 10 分钟，后面可能少掉 2 小时的认知垃圾清理。
第三，不要连续做多个 AI-heavy 任务
AI-heavy 任务看起来轻松，实际很耗脑。尤其是那些需要连续 prompt、review、debug 的任务，本质上是高密度认知训练。
不要因为完成得快，就立刻接下一个同类任务。更好的做法是：
- 一个 AI-heavy 任务结束后，安排一段低强度工作。
- 不要同时开多个 agent 跑多个方向。
- 给每个任务设 checkpoint，到点再决定是否继续。
- 不要把自然休息时间全部拿来 prompt AI。
可持续不是降低效率，而是避免把一天压成几个小时的高强度透支。
第四，保留一点手写代码的 craft 时间
不是所有任务都要交给 AI。
如果某个任务你本来就喜欢，或者它能帮你加深对系统的理解，可以故意留给自己写。尤其是个人项目、学习项目、探索性重构，不一定要追求最快。
可以给自己设一些规则：
- 每天或每周保留一段不用 agent 的 coding 时间。
- 对特别熟悉、特别享受的任务，选择手写。
- 用 AI 的 Ask 模式辅助理解，而不是直接生成实现。
- 个人项目里少用 agent，保留动手的乐趣。
AI 可以替你省掉无聊部分，但不要让它把你喜欢的部分也一起拿走。
第五，重新寻找新角色里的乐趣
工程师的角色正在变化。既然变化已经发生，就需要在新的工作形态里重新找到值得投入的部分。
这些方向可能会变得更重要：
- 和用户沟通，识别真实需求。
- 做原型，快速验证假设。
- 设计 agent 的约束、规则和 guardrails。
- 建立更好的测试、评审和交付流程。
- 做性能优化、可靠性和系统边界设计。
- 提升沟通能力，把复杂判断讲清楚。
如果旧的快乐来自“亲手写出每一行代码”，新的快乐可能来自“设计出一个能稳定产出好结果的系统”。这不是完全相同的满足感，但它可以被培养。
结语
AI 辅助编程不是问题本身。问题出在我们把它当成无限加速器，却没有同步调整节奏、边界和评价方式。
如果 AI 让你更快完成任务，却也让你更少休息、更少享受过程、更难感到自豪，那就不是单纯的效率提升，而是一种透支。
真正健康的 AI 工作流，应该让工具帮你，而不是把你推向更密、更急、更难停下来的工作日。
慢一点也没关系。保留判断力，保留好奇心，保留一点对编程本身的喜欢。行业会继续变化，但你需要带着能量走到下一阶段。
关于
本文改写自 Evil Martians 文章 AI-assisted engineers are burning out, is this fine?，原作者为 Ivan Chepurin 和 Travis Turner。
关注我获取更多资讯
