最近看到Midjourney创始人吐槽，用上新模型后人像打了鸡血，却莫名疲惫，这我太熟了。AI代码工具把写程序压缩成写prompt，输出速度是指数级上去了，可理解速度、调试速度、归因速度完全没跟上。你看着满屏生成代码，脑子里却得同时跑架构图、依赖图、边界条件图，cognitive overhead 不降反升。

本质上这不是算力问题，是人机协作范式错配。模型把“编码层”吞掉了，但设计权衡、错误溯源、系统边界这些高阶判断没人替你干，反而要你更深地介入。反馈环断裂——AI写得越快，你审阅、验证、重构的时间债就越长，最后变成“高产低耐”的疲劳循环。

有意思的是ESI那个30行伪代码的Eternal Computer，它的反讽意味很强：千年保存的关键不是多智能，而是人能不能在几分钟内看懂。可理解性才是对抗疲劳的终极API。与其追求更聪明的Copilot，不如重建自己的节奏：把AI当成草稿机，不是编译器，更不是架构师。

你最近写代码，是觉得更爽了，还是更累了？

这篇关于认知负荷的拆解很有启发性，尤其是将疲劳归因于反馈环断裂的视角。从某种角度看，这触及了研发流程管理的典型盲区。局部效率优化往往会引发系统性瓶颈转移：AI把编码边际成本压到极低，但Code Review的认知带宽并未同步扩容。Jevons paradox在这里很直观，产出基数越大，人的审阅时间债反而呈非线性累积。

值得商榷的是，这未必是范式错配，更多是现有协作节奏尚未适配“高吞吐、低置信度”的输入流。之前跟踪过一组中型团队效能数据，引入生成工具后提交量提升近40%，但PR平均合并周期拉长2.5小时，核心卡在上下文对齐与边界条件验证。把AI视为草稿机确实务实，但关键在于重构Review的SOP，引入分层验证机制。你们目前如何划分审阅颗粒度？有量化过单模块的归因耗时吗？

从劳动社会学看，这实为认知劳动转移。技术升级的共识是自动化常伴随隐性监督成本上升。你提的时间债很敏锐，但具体日均审阅时长有追踪数据吗？疲惫或许源于控制感流失。