Appearance
AI Coding 提效后，明明能利用AI进行并发开发，但人却更累了？
更新: 6/21/2026 字数: 0 字 时长: 0 分钟
TIP
最近看到一篇讲 AI Coding 的文章，里面有句话戳到我："AI 没有让人更闲，是因为人承担了局部提速后的 buffer 成本。"
我盯着这句话看了很久。因为这正是我这几个月做前端开发的真实状态——手上同时开着三四个项目，每个都挂着一个 Agent 在跑需求，吞吐量肉眼可见地涨了，但我自己一点都没觉得轻松，反而比以前更累。
一、代码是 Agent 写的，但活还是我的
现在我的日常大概是这样的：早上把几个需求分别丢给不同项目里的 Agent，它们各写各的，速度确实快，半天就能堆出一大坨代码。
但接下来呢？
功能到底做没做对，做没做全，得我一个个去 review，手动把项目跑起来一遍遍点、一遍遍试。 有问题就打回去让 Agent 重做。重做之前还得反思——是不是我一开始的提示词没说清楚，于是再改 prompt，再重新 review，再自测。这个循环转一圈下来，时间其实没省多少。
Agent 写得比我快，这点毫无疑问。但"写"从来不是我工作里最重的那部分。真正吃时间的是判断它写得对不对，是来回打磨需求和验收的那些回合。 这些活 Agent 替不了我，反而因为它写得快、我开得多，这种判断和协调的总量比以前更大了。
写代码这件事，从"我的体力活"变成了"我的脑力活"。手是闲下来了，脑子一刻没停。
二、并发不是爽，是脑力透支
一开始我觉得多开几个 Agent 简直爽翻了，并行处理需求，效率拉满。
但跑了一阵子才发现，并发真正的代价是脑子转不过来。
同时盯着三四个项目，意味着我要不停地在它们之间切换上下文：这个 Agent 现在在干嘛、那个输出合不合理、哪个该先看、哪个能放过、哪个必须打回。每切换一次，脑子里就得重新加载一遍这个项目的背景。这不是那种写了一天代码的踏实的累，而是一种持续的、低强度的、停不下来的判断的累。
到了下午，我甚至会发现自己开始"放水"——不是因为某段代码真的没问题，而是因为我已经累了，懒得再细看，下意识就想点 Accept。这其实是很危险的信号。
Agent 可以并发，但我不行。我的判断带宽是串行的。
三、需求一大、边界一糊，Agent 就开始失控
这是我体会最深的一条，也是我现在雷打不动会做的事。
早期我吃过亏：把一个比较大的需求直接整个丢给 Agent，提示词里边界说得也不够清楚，因为会无意识的偷懒，不想打那么多字去描述，会想着ai应该会懂😂。 结果它就开始"自由发挥"——自己猜我没说清的地方，沿着一个看起来合理、实际上跑偏的方向，哗啦啦写出一大套代码。等我 review 时才发现方向错了，推倒重来，时间全白费。
模糊的需求，在 AI 时代的代价被放大了。 以前需求说不清，顶多是我自己边写边卡壳、多问几句产品；现在是 Agent 用极快的速度把错误方向铺成一整片，然后我得花更多时间去识别和纠正。
所以现在我的做法是：需求开发之前，先把大需求拆成一个个小需求点，给每个点都设计好明确的要求和验收面。 拆得越细、边界聊得越透，Agent 越不容易失控。它会顺着我设计好的思路一步步往下走，而不是自己去猜、去发散。
这件事说起来朴素得不能再朴素——拆小、说清。但实践下来，这比我去研究任何花哨的框架和插件都管用。我现在宁可在动手前多花一个小时把需求想透、把边界写明白，也不愿意事后花三个小时去收拾一个跑偏的方案。
四、Review AI 的代码，比 review 同事的还累
跟人合作久了，同事的代码我扫一眼就有数：他的命名习惯、模块怎么拆、爱在哪夹带点小重构，都有迹可循，很多地方凭经验就能跳过去。
但 AI 没有这种一致性。 它每次写出来的东西对我来说都是陌生的，我没法凭经验跳过，只能一段段老实看。而且它有几个让我很头疼的老毛病：
- 把模糊需求猜成确定实现——我没说清的边界，它不问，直接选一个方向写下去。
- 过度抽象——让它写个简单功能，它能给我整出三层封装、一堆工厂类，技术上没错，但纯属造火箭。
- 改了不该改的公共部分——编译能过、测试也能过，但可能悄悄影响了别的地方，上线才暴露。
- 写伪测试——覆盖率数字挺好看，实际上验证的是实现细节，啥也没真正测到。
这些坑的共同点是：表面上一点问题都看不出来。 只有我对这块代码足够熟，才能发现它的选择哪里不对。
我现在越来越认同一句话：你 review 不了的代码，就不应该 merge。 那种"AI 写了 99%，我只管那 1%"的想法是错觉——为了找到那 1%，你得把 100% 都看一遍。
五、它能写，但我不能不看
我越来越觉得，现在的 AI Coding 像开了 L2 辅助驾驶的车——车能自己跑，但我必须全程盯着，手离了方向盘，眼睛和脑子一刻不能松。表面上我不用亲自敲了，实际上注意力的消耗一点没降，甚至更高，因为主动执行变成了被动监控，而被动的持续警觉是最磨人的。
我从一个"写代码的人"，变成了一个"看代码的人"。
六、我现在是怎么用 Agent 的
踩了这些坑之后，我慢慢摸出几条自己的原则，分享给同样有体感的同行：
- 动手前先拆需求。 大需求一定拆成带验收标准的小点，把边界在提示词里讲透，这是防止失控最有效的一招。
- 不盲目追求并发。 与其同时开五个主需求把自己逼疯，不如一个主需求配一两个相对独立的小任务，让脑子还能转得过来。
- review 是底线，不是可选项。 看不懂的代码不合入。宁可慢一点，也别让 bug 在我点 Accept 的那一下溜进测试环节。
- 把功夫花在前面。 提示词写清楚、需求想明白的一个小时，往往能省下后面好几个小时的返工。
TIP
回过头看，AI Coding 确实改变了我的工作，但它改变的方式和我一开始想的不太一样。它没有让我更闲，而是把我的精力从"敲键盘"转移到了"做判断"上——判断需求该怎么拆、判断 Agent 写得对不对、判断这个方案能不能上。
写代码这件事变快了，但把需求稳稳交付出去这件事，并没有自动变快。 省下来的体力，最后都变成了脑力和心力的支出。
但我不觉得这是坏事。它逼着我把更多精力放到真正重要的地方——想清楚要做什么、定清楚边界在哪。当代码本身不再是瓶颈，能不能把需求想明白、把活拆清楚，反而成了拉开差距的关键。
代码变快只是开始，怎么用好自己被释放出来的判断力，才是真正要琢磨的事。