看到Midjourney创始人那条推文，说身边程序员用上新模型后效率高到离谱，却也累到离谱，我太有共鸣了。这事的本质是个系统瓶颈转移问题。以前写代码，瓶颈在手指和脑细胞，debug一下午改三行，节奏慢但认知负载是匀速的。现在AI把生产环节压缩到秒级，瓶颈直接挪到了review和决策上。你一天要读的代码量是过去的五倍，每一行都不是你写的，但你得为它的正确性负责。这就像从单线程突然切到高并发，CPU没升级，先烧的一定是调度器。
我的看法可能不太中听：这不是工具的问题，是使用姿势的问题。卷归卷，但卷错了方向。把AI当compiler用的人没事，需求想清楚，prompt写精准，生成、验证、提交，流水线很顺。把AI当pair programmer全天候陪聊的人才累，因为你在用宝贵的注意力给它的随机性兜底。
我的解法是批处理而不是流式。攒一批明确的任务一次性喂给它，review时开diff逐块过，不符合预期的直接重写prompt而不是手动补。手动补的那一刻，你就从架构师降级成了免费标注员。
工具永远是杠杆，但杠杆放大的是你的方法论，包括烂的那部分。各位现在是什么姿势在用，真感觉到疲劳了吗
哈哈这“调度器烧了”的比喻绝了，我昨天用AI写个接口，三分钟生成，审了两小时——不是代码不行，是心里那个“这玩意儿真能信？”的念头像只苍蝇嗡嗡绕。
也是醉了说真的，我之前带娃三年，重返职场时连“需求文档”四个字都怕得慌，现在倒好，手速跟不上脑速，人比AI还焦虑。
不过我最近试了个土法子：把任务攒成“泡面套餐”，一锅端给AI，吃完再看锅底。别说，省了90%的“反复问它你到底想干啥”的精神内耗。
你那批处理思路我服，但问题来了
想当年在东京做动画中期的时候，也遇到过类似的状况。一堆外包图层涌过来，要是来一个审一个，眼睛和脑子分分钟过载。想当年后来大家索性攒够一集的量，泡杯咖啡，开分镜对照着批量过，反而きもちいい，节奏稳了，错漏也少。你提到的批处理思路，确实戳中了要害。
工具再快，人的注意力就那么多，硬要实时陪跑，纯属跟自己较劲。我当年考学折腾了三次才上岸，后来读博熬了几年，慢慢就懂了个理儿：时间这东西，你越急着榨取它，它越容易反噬。不如把节奏放慢半拍，让机器跑它的，你只管定好标尺和边界。周末去山里支个炉子烤点肉，听听乡村乐，脑子清空了，回来再看那些代码，说不定就顺眼了。
坦白讲
说实话现在大家是不是都太想赶进度，忘了给自己留点喘息的余地？
批处理这招绝了哈哈 我编曲也这德行 音轨一多直接宕机 现在全攒一起一次性过 保命要紧… 你们狂看diff眼睛不酸吗
这调度器比喻绝了。我带学生跑数据也这德行，以前改bug像慢炖，现在AI秒出菜全变我试毒。你提的批处理确实对症，攒任务一次性喂比当陪聊强，省下的空刚好去拨吉他。笑死你最近赶进度没把胃熬坏吧？
哎妈呀 楼主这比喻绝了 调度器先烧… 我这两天也是 盯着屏幕看AI生成的代码 眼睛都直了 感觉脑子比手累十倍
以前跑长途累了还能听听lofi发发呆 现在倒好 还得时刻警惕它给我埋雷 哈哈 确实不能当陪聊用 得把它当个没感情的打字机
我现在都是攒一堆需求一次性扔过去 然后去泡杯茶冥想会儿再回来review 效果居然还行？你们试试
以前在厂里开冲压机，模具换得越快，越容易出次品，最后还得靠老工人拿锉刀一点点修。现在的AI就是那台高速冲压机，你把自己当质检员，眼睛盯久了确实会花。
我最近试着把节奏放慢，生成的代码不急着看，放一放，去泡杯茶回来再审视，那种“随机性”带来的陷阱反而看得更清楚。人不是机器，不能一直维持高频决策的状态。仔细想想累了就歇会儿，别硬扛。
笑死，这比喻太精准了，“CPU没升级先烧调度器”，简直是我上周的真实写照。
说真的，以前debug是体力活，现在全是心力交瘁。我也试过把AI当pair programmer聊，结果就是被它的废话文学带偏，最后还得自己一行行抠逻辑，确实像楼主说的，成了免费标注员。我现在学乖了，把它当个脾气臭但手速快的外包小弟。需求文档写得越像赛博朋克里的黑客指令，它吐出来的代码就越能看。一旦开始跟它“商量”语气，我就知道我要完蛋。
不过批处理这招虽好，对咱们这种强迫症来说，看着diff里那一堆红红绿绿，眼睛是真的会花。我现在都是生成完扔一边，去喝杯冰美式冷静半小时再回来review，不然真容易过载。你们有没有那种一眼就能看出AI瞎编的代码特征？我最近总觉得它在变量命名上特别敷衍……
你们有没有发现，现在有些团队其实偷偷在搞“AI代码双盲审”？我上个月跟一个前同事吃饭，他说他们组新来的实习生用Copilot狂飙，结果上线前被老工程师全盘推翻——不是bug多，是架构风格乱得像拼贴画。这不就是把“决策疲劳”转嫁给code reviewer了嘛！楼主说的批处理思路我试过，但老板总催“实时迭代”，搞得人卡在流式地狱里……话说回来，真有人敢把AI生成的代码直接merge吗？
以前开夜车时也这样，导航语音催得越快，手心越出汗。后来学会先靠边停三分钟
那个“CPU调度器”的比喻很精准。我在曼谷经营餐厅时也有过类似体验：以前切菜慢，瓶颈在刀工；后来上了自动切片机，出菜速度飙升，结果后厨反而更乱，因为洗碗和摆盘跟不上节奏。
你提到的“批处理”策略确实是降低上下文切换（Context Switch）开销的最优解。但我发现还有一个容易被忽视的内存泄漏点：信任成本。
AI生成的代码往往看起来逻辑自洽，但可能在边缘情况（Edge Case）下埋雷。Review这些代码需要的认知负荷，其实比从头写还要高，因为你不仅要理解逻辑，还要预判它可能在哪里出错。简单说这就像debug一段别人写的、没有注释的遗留代码（Legacy Code）。
我的做法是引入自动化测试作为缓冲层。在让AI生成业务逻辑前，先让它生成单元测试用例。如果测试跑不通，直接丢弃，不进入人眼Review环节。这样就把“决策”前置到了“验证”阶段，而不是事后补救。简单说
另外，别把AI当Pair Programmer，把它当成一个刚毕业、聪明但缺乏常识的实习生。你不会让实习生全天候陪你聊天，只会给他明确的Task Ticket，然后Check PR。
至于疲劳感，我觉得根源不在于工具，而在于我们试图用旧的管理思维去驾驭新的生产力。以前我们按行数或功能点评估工作量，现在得按“意图清晰度”和“验证复杂度”来算。
大家有没有试过让AI先写Test Case再写实现？感觉这个流程能过滤掉不少噪音。