我最近越来越频繁地遇到一种很荒谬的场景:
任务还没开始,脑子已经开始开会了。
这个需求要不要丢给 Claude Code?还是 Cursor 更顺手?如果只是查一段旧逻辑,用 Copilot Chat 够不够?要不要让 Codex 跑一版?Gemini 的长上下文会不会更适合?
然后十分钟过去了。
代码一行没写,浏览器标签页开了五个,终端里挂着两个会话,脑子里还有一个声音在问:我是不是又选错工具了?
这不是矫情。
我觉得这是 AI 编程进入 Agent 阶段以后,很多开发者正在经历的一种新疲劳:不是写不动代码,而是每天都在做太多“该让谁来写、写到哪一步、我该不该信它”的判断。

一、AI 没有让工作日变短,只是让工作日更密
Stack Overflow Blog 在 5 月 21 日发了一篇文章,标题很直接:Coding agents are giving everyone decision fatigue。
我喜欢这篇文章,不是因为它爆了。事实上,我顺手看 Hacker News,同题链接当时只有 4 points、0 comments,完全不是那种英文技术圈集体冲进去吵架的热点。
但它戳中了一个更适合在微信里聊的日常感受:AI 工具越多,人的心智负担反而越明显。
文章里有一句核心判断:随着软件工程师的时间从“写代码”转向“组织 prompt”和“review 代码”,工作日正在变得更密、更紧张。
这句话我太有共鸣了。
以前写代码累,是因为要自己啃文档、查 API、补类型、改语法错误。现在这些事确实被 AI 吃掉了一大块。问题是,省下来的时间并没有自动变成休息。
它变成了另一堆工作:
- • 给 Agent 讲清楚上下文
- • 判断它读没读懂项目
- • 看它改了哪些文件
- • 确认有没有引入安全和性能问题
- • 决定这段代码能不能进主分支
- • 如果不行,还要判断是 prompt 写错了、模型不行,还是需求本身没说清楚
所以我现在越来越不喜欢一句话:AI 提高了开发效率。
这句话太粗了。
更准确的说法可能是:AI 降低了“生成代码”的成本,但把压力后移到了“判断和收口”。

二、真正变贵的不是代码,是 review
Stack Overflow 那篇文章把这件事说得很直白:容易生成的代码,给软件开发生命周期后半段带来了更大压力,尤其是 code review、DevOps/SRE、安全和基础设施。
这点我觉得很多团队已经感受到了。
AI 最擅长制造“看起来完成了”的东西。
一个功能页面,它能很快拼出来;一段脚本,它能很快跑起来;一个 API,它能很快补齐参数和错误处理。问题是,“能跑”和“能进生产”中间隔着一条很长的河。
以前一个人写一天代码,reviewer 可能看半小时。
现在一个 Agent 半小时吐出一大坨 diff,reviewer 反而要花更久理解:
- • 这个改动是不是解决了真正的问题?
- • 有没有绕开现有抽象,偷偷复制了一套逻辑?
- • 有没有把边界条件写死?
- • 有没有为了通过测试改坏语义?
- • 有没有新增一个以后没人维护的复杂度?
这就是“代码变便宜,review 变贵”。
Stack Overflow 文章里还引用了一个很典型的例子:某位工程师产出了团队其他人 7 倍的代码,而且质量也不错;但问题是,团队里其他人花了大量时间在 review 她的代码上,而不是写自己的代码。
这不是在否定高产。
它提醒我们:软件开发不是打字比赛。一个人的输出量如果把整个团队的判断能力吃光,那瓶颈只是换了地方。
以前瓶颈在“谁来写”。
现在瓶颈越来越像是:谁来判断这东西到底好不好。

三、为什么你会在工具选择上卡住
很多人以为“选择 AI 工具”只是偏好问题。
我不这么看。
当工具只是补全几行代码时,选错了也没什么。不好用就关掉,手写就完了。
但 Agent 不一样。你一旦让它读仓库、改文件、跑命令、生成 PR,它就进入了真实工程链路。工具选择不再是“哪个回复更聪明”,而是会牵动一串后果:
- • 它能看到多少上下文?
- • 它会不会乱改无关文件?
- • 它生成的 diff 好不好审?
- • 它的执行日志够不够透明?
- • 它失败以后,我能不能快速接手?
- • 团队其他人能不能复现它的过程?
所以你会犹豫,不是因为你没主见。
是因为每次选择 Agent,本质上都在选择一套工作流。
更麻烦的是,工具每天都在变。
今天这个模型代码能力更强,明天那个 CLI 支持更好的 repo 操作,后天又有人说某个插件能自动生成测试。开发者很容易进入一种状态:一边想赶紧开工,一边又怕错过更优解。
这就是决策疲劳最隐蔽的地方。
它不一定表现为“我不会做决定”。
它常常表现为:我每个决定都能做,但每个决定都要消耗一点点注意力。
半小时之后,你终于选好了工具,可真正该思考业务逻辑的时候,脑子已经没那么清爽了。
四、80% 被编辑,说明人还没退出战场
Stack Overflow 文章还引用了 Smartsheet 的研究:其企业用户的 automation intensity 同比增长 55%,overall activity 增长 46%。他们的判断是,工作日没有变长,但同样的时间里塞进了更多活动。
这个描述非常准确:不是更长,是更密。
Smartsheet 还提到,80% 的 AI-generated content 在最终定稿前会被编辑。这里要说清楚,它说的是 AI 生成内容,不是只指代码;但放到代码场景里,这个趋势同样值得警惕。
AI 可以给你一个初稿。
但“能不能用”,仍然要人判断。
而且 AI 生成的东西有个特点:它不像你自己写的代码,你天然知道每一行为什么在那里。你 review AI 代码时,经常要倒着补上下文:它为什么这么设计?它是不是误解了需求?它是不是为了迎合 prompt 编了一个不存在的约束?
这也是为什么我觉得“人人都是 builder”这句话只说对了一半。
是的,AI 让更多人能更快做出原型、页面、脚本、自动化流程。
但 builder 不是只负责把东西搭起来。
builder 还要负责做判断:什么该做,什么不该做;什么能上线,什么只能当 demo;什么应该自动化,什么必须留给人。
Stack Overflow 那篇文章把新的 SDLC 瓶颈概括为一个词:judgement。
我觉得翻成中文,不只是“判断力”,还包括“负责收口的能力”。
生成越快,收口越重要。
如果没有收口,AI 帮你省下来的时间,会以 bug、返工、review 堆积、线上风险的形式要回来。
五、我的建议:别每天重新选工具,先定默认流程
我不是想劝大家少用 AI。
恰恰相反,我觉得现在更应该用,只是别把每天都过成工具评测日。
我自己的做法很简单:先定默认流程,再允许例外。
第一,给工具分工。
比如:一个工具负责日常代码库修改,一个工具负责解释和查资料,一个工具负责长任务探索,一个工具负责最终 review。分工不一定固定成行业标准,但要固定成你自己的默认值。
默认值的意义是:小任务不要重新开会。
第二,给 Agent 设边界。
我越来越喜欢在第一轮 prompt 里说清楚:先读哪些文件,先给计划,不要直接改;改动范围限制在哪;必须跑哪些检查;不确定的地方先问我。
这听起来慢,其实是在省后面的 review 时间。
第三,控制 diff 大小。
AI 很容易一口气改太多。越大的 diff,越容易让 reviewer 放弃逐行理解,最后变成“看起来差不多就合”。这很危险。
我宁愿让 Agent 做三个小 PR,也不愿让它生成一个巨大的“顺手重构”。
第四,团队要把“谁来判断”写清楚。
如果一个 PR 是 AI 生成的,那责任人不是 AI,而是按下合并按钮的人。这个原则不能模糊。工具可以协助解释,测试可以协助兜底,但最终要有人对结果负责。
第五,允许自己不追最新。
这点很反直觉。
AI 工具发展太快,永远会有更新、更强、更会跑的东西。但开发者真正稀缺的不是“知道所有工具”,而是保持一套稳定工作流的能力。
能稳定交付,比永远追最新更重要。

六、别让 AI 把你变成审批机器
我现在对 AI 编程的态度很明确:它不是替我写代码那么简单,它是在重排我的工作日。
以前我主要消耗在实现上。
现在我更多消耗在选择、组织上下文、检查结果、判断风险上。
这不一定是坏事。工程师本来就不该只做打字员。真正有价值的部分,本来就是理解问题、拆解系统、做权衡、承担判断。
但问题是,如果工具只负责不断生成,而流程没有重新设计,人就会被推成一个疲惫的审批机器:
上午 approve 这个,下午 reject 那个,晚上再回头看一个 Agent 改了 18 个文件的 PR。
这不是我想要的 AI 工作流。
我想要的是:AI 帮我减少低价值重复劳动,也帮我减少不必要的选择;而不是给我塞更多半成品,让我每天在“要不要相信它”里耗光脑力。
所以,下次当你发现自己“代码还没写,先选 AI 工具选了半小时”,不用太自责。
这不是你效率低。
这是整个软件开发流程正在迁移,而我们还没给新流程建立足够清晰的默认值、边界和判断机制。
AI 时代最该练的,也许不是 prompt 花活。
而是这件事:让工具多干活,但不要让工具替你制造更多决定。
下期我想聊一个更硬但很关键的话题:当 AI 写代码越来越快,测试会不会从“上线前的保护网”,变成 Agent 工作流里的刹车系统?
参考来源
- • Stack Overflow Blog: Coding agents are giving everyone decision fatigue[1]
- • Smartsheet Research: AI is making work denser, not lighter[2]
- • Hacker News / Algolia: Coding agents are giving everyone decision fatigue[3]
引用链接
[1] Coding agents are giving everyone decision fatigue: https://stackoverflow.blog/2026/05/21/coding-agents-are-giving-everyone-decision-fatigue/
[2] AI is making work denser, not lighter: https://www.smartsheet.com/content-center/inside-smartsheet/research/ai-making-work-denser-not-lighter
[3] Coding agents are giving everyone decision fatigue: https://hn.algolia.com/api/v1/search?query=Coding%20agents%20are%20giving%20everyone%20decision%20fatigue&tags=story
夜雨聆风