听 Phish 写了 30 年代码，AI agents 改掉了工程师的心流

Christopher Meiklejohn 这篇《Rift》最有意思的地方，不是“程序员爱听什么歌”。

他写的是一套持续 30 年的工作条件反射：Phish 的长段即兴一响，编码状态就启动。到了 2026 年 1 月，工作重心转向管理 AI agents，这套反射突然不灵了。

音乐没有消失。消失的是音乐和工作的咬合。

这不是反 AI。Meiklejohn 也承认，agent 工作可能有更高杠杆，也仍然属于工程工作。问题在别处：当工程师从“亲手写代码”转向“打开会话、提问、审查、切换、返工”，过去那种靠连续注意力产生的 flow，还能不能回来？

Phish 不是背景音乐，是进入工作状态的开关

Meiklejohn 的经历不能直接套到所有程序员身上。

他 1995 年接触 Phish，1998 年 15 岁开始职业编程。后来长期做分布式系统、后端服务和研究写作。这类工作吃的不是短促反应，而是长时间装载上下文：代码、系统边界、失败路径、论文结构，都要在脑子里同时站住。

Phish 恰好适配这种节奏。

这支乐队的长 jam、渐进展开和即兴结构，不像一首三四分钟流行歌那样快速给出段落终点。它更像一条长线，允许人停留在问题里。对分布式系统和后端开发来说，这种“停得住”很重要。

他提到，2021 到 2023 年写两百多页博士论文时，常一边看 Phish 直播，一边写分布式系统内容。这里的音乐不是降噪白噪声，而是身份锚点。音乐响起，身体知道该进入哪种状态。

这也是这篇文章的知识增量：很多人谈 AI 编程，只谈产出、速度、替代。Meiklejohn 提醒的是，工程工作还有一层不容易被指标捕捉的东西——人怎么进入创造状态。

从写代码到管 agents，断的是连续注意力

2026 年 1 月之后，他的工作形态变了。

过去是自己进入问题内部，写代码、调试、构建系统。现在更像坐在调度台前：打开多个会话，提出任务，审查结果，发现偏差，再让 agent 返工。

这不一定更低级。很多时候，它可能更高杠杆。一个人能同时推进更多任务，也能把部分机械劳动交出去。

但它改变了节奏。

差别就在这里。

上一代 AI 编程助手更像副驾驶。工程师仍在键盘前维持主线，模型补一段、改一段、解释一段。agentic work 更像分派任务。人不再一直沿着一条问题线向前走，而是在多个半成品之间来回检查。

这会影响两类人。

对软件工程师来说，动作要变得更具体：不要只学会“让 agent 写代码”，还要学会写清验收标准、保留关键设计判断、给重要模块留出深度编码时间。否则很容易变成只会催产出，不再真正理解系统。

对关注 AI agents 的技术管理者来说，采购和推广也不能只看 demo 速度。更现实的做法是先选低风险模块试点，记录返工率、审查时间、线上问题和代码所有权，再决定团队要不要扩大使用。只统计“开了多少会话”“合了多少 PR”，会把问题看薄。

这不是说 agent 没价值。限制在于，目前很多团队还没把“监督 agents”设计成一种稳定工作。工具先来了，人的节奏还没跟上。

新心流能不能建立，要看三个变量

我更在意的不是“AI 会不会让工程师更快”。这个问题太粗。

更准确的问题是：在 agentic world 中，什么是 flow？

也许有人会在多线程审查、快速判断和系统编排里获得新的满足。资深工程师本来就常做抽象、拆解和验收，agent 只是把这些动作放大了。

但也可能出现另一种结果：工作被切得更碎，工程师每天都在看输出、挑错误、补提示、追返工，产出变多，进入问题内部的时间变少。

接下来最该看三个变量：

这三个变量比单纯的效率数字更接近问题核心。

如果 agentic work 最后只是更多会话、更密集切换、更快合并，它当然可能提高吞吐量。但工程师的职业满足感未必同步增长。

Meiklejohn 的案例价值正在这里。它没有证明所有程序员都会失去心流，也没有证明 AI agents 会伤害工程文化。它至少表明，工具改变的不只是交付方式，还会改变人和工作之间的节奏关系。

30 年里，Phish 曾经是他进入工程世界的门。现在门还在，音乐也还在，只是门后面的房间换了。

agentic world 中什么是 flow？这个问题，可能比“AI 能写多少代码”更难回答。