AI 先压缩的，是研发组织里的信息中间层

今天看到一篇小红书，标题很抓人，叫“AI 先杀职场中登”。这类标题如果只当情绪口号看，很容易滑过去。但它引用 Block 这个案例时，其实点中了一个更值得认真看的命题：AI 正在先改写研发组织，而不是先改写岗位名称。

很多人现在讨论 AI 对软件行业的影响，还是下意识问一句：程序员会不会被替代？我越来越觉得，这个问题问得有点晚了。因为在真正大规模替代写代码之前，组织里的协作结构已经先开始被重写。

AI 这轮先压缩的，不是某个 title，而是研发组织里那些依赖信息差、串行流转和人工协调才能运转的中间结构。

为什么 Block 这个案例值得看

先把事实边界说清楚。Block 的大规模裁员是真的。CNBC 报道里直接写了，裁员规模是 more than 4,000 employees，大约接近公司员工总数的一半。更关键的是，这件事在官方口径里不是简单的“经济不好，降本增效”，而是明确和 AI、和更小更强的团队组织方式绑在了一起。

Block CFO 的表述很直白：公司希望“用 AI 自动化更多工作”，从而“让更小但更强的人才团队跑得更快”。这句话的分量在于，它不是旁观者的评论，而是公司高层自己给出的组织重构逻辑。

再往前走一步，Block 官方那篇《From Hierarchy to Intelligence》更彻底。它不是在说“AI 是一个提效工具”，而是在说：传统 hierarchy 里有一部分协调、对齐、传递、管理的功能，本身就应该被 intelligence layer 接走。它甚至把“no permanent middle management layer”写进了组织设想里。

这就意味着，Block 不是单纯在买更强的 coding tool，而是在尝试用 agent 改写组织的控制回路。

真正发生变化的，不是写代码，而是代码周围那圈人肉流转

过去一个软件需求为什么常常要经过很多层？并不是因为每一层都在创造新价值，而是因为现实世界里有太多断点。需求在产品和研发之间断一次，研发和测试之间断一次，CI 失败和修复之间再断一次，跨团队依赖又断一次。每一次断点，背后都要有人补上：同步状态、传递上下文、催一下进度、解释一下风险、再组织一次会。

所以很多中间层岗位的真实价值，未必是“我做了一个结果”，而是“我让结果能在断裂的系统里继续流动”。

这套东西在前 AI 时代当然成立，因为信息差真的存在，串行等待真的不可避免。但 agent 一旦能自己读 ticket、找代码、开分支、写实现、跑测试、修 CI、看日志，这条链路里大量原本必须靠人传递的动作，就会被收进一个更连续的执行闭环。

Block 工程博客里公开提到，95% 的工程师已经在常态化用 AI，第二大群体已经在并行跑 3 到 5 个 agent 实例。它还描述了一种以前几乎不可能成为日常的工作方式：agent 自己读工单、自己建分支、自己提 PR、自己盯 CI、自己修失败，人类主要在 review 时介入。这个变化不是“写代码更快了”那么简单，而是很多原来需要层层传递的中间动作，开始被压进同一条回路里了。

过去中间层存在的重要原因，是系统不连续；现在 agent 的价值之一，就是把这条链路重新接起来。

所以被压缩的，不是管理者，而是“只做协调的管理者”

我不太认同一种粗暴说法：AI 会先替代 manager。更准确的说法应该是，AI 会先压缩那些主要靠协调存在、却不真正拥有判断与问责权的 manager 职能。

这两者差别很大。

如果一个人的主要工作是：追状态、开会、同步、转述、向上包装、向下分发，那他最危险。因为这类价值本质上建立在信息差和串行流转上。而 AI agent 恰恰最擅长把这部分摩擦打平。

但如果一个管理者真正做的是另外几件事，情况就完全不同了：定义优先级，承担架构后果，拍板资源配置，处理跨团队冲突，扛事故，接审计，做风险接受，给外部合作方和客户兜责任。这里面的核心价值不是“传递信息”，而是“承担后果”。这类角色短期并不会因为 agent 能写更多代码就消失。

所以我更愿意把这件事说成一句更精确的话：被压缩的不是 middle management 这个词，而是 coordination-only management 这种组织形态。

哪些角色更脆弱，哪些角色更稳

如果把岗位 title 暂时放下，只看任务结构，我现在更倾向用五个问题来判断一个角色的韧性。

这个任务是不是高度标准化。
结果是不是容易自动验证。
角色是否承担问责与后果。
工作是否依赖跨边界整合。
价值是否建立在人际信任与博弈上。

按这个框架看，软件组织里最脆弱的，通常不是“junior”或“中层”这些名字，而是下面这些任务束：大量标准实现、大量标准测试、大量标准运维，以及主要靠状态同步、项目推进、信息搬运而存在的协调工作。

更稳的则是另一类：强 ownership 的技术负责人，平台和架构边界设计者，安全、合规、审计、事故响应这类高责任角色，以及销售、客户管理、合作关系这类高信任密度角色。不是因为 AI 碰不到这些事，而是因为这些事的价值中心不在“产出内容”，而在“对结果负责”。

这也是为什么我不太喜欢那种泛泛的岗位预测。AI 不是按岗位名册裁人，它是按任务结构重新定价。

这件事对技术管理者真正的提醒

很多管理者看到这种案例，第一反应会是：那我要不要重新学写代码？我觉得这只对了一半。

技术管理者当然必须亲自下场用 agent。否则你根本无法判断团队口中的“AI 已经提效很多”到底是事实，还是演示版幻觉。但如果只把结论停在“管理者也得会写代码”，还是太浅。

真正更重要的，是管理者要把自己从“传话筒”升级成“组织设计者”。谁能重写流程，谁能把 repo、上下文、验收标准、约束、审查回路和 agent 编排成新的生产函数，谁就不是被替代的对象，反而会成为放大器。

换句话说，AI 对管理层的要求，不是简单地下沉回执行层，而是上移到更高杠杆的设计层。

也别把社交媒体里的每个数字都当真

这里我觉得也需要克制一点。像“会议减少 70% 到 80%”“某项目从 15 人变成 4 人加 AI”这类说法，传播力很强，但我目前还没看到足够扎实的公开原始出处。能够确认的是，Block 在播客摘要和工程博客里都已经公开呈现了“小团队 + 多 agent 并行”的方向；不能确认的是，这些特别整齐、特别戏剧化的数字已经到了可以当事实引用的程度。

这并不影响大的判断成立，但会影响我们怎么讲。真正有说服力的表达，不需要靠把所有戏剧性数字都照单全收来撑场子。趋势本身已经足够强了。

值得相信的，不是每个传播中的细节数字，而是那条越来越清楚的组织逻辑：小团队 + agent 并行，正在替代大团队 + 层级协作。

最后一句

围绕这篇小红书，我最终更愿意保留的，不是“AI 开始杀职场中登”这种带情绪的说法，而是一个更冷一点、也更能落到组织设计上的判断：

AI 先压缩的，不是程序员，而是研发组织里的信息中间层。

谁的价值主要来自信息搬运、串行协调和流程存在感，谁会先被重估。谁能定义方向、承担后果、处理例外、并把 agent 编排进真实生产系统，谁反而会变得更重要。

这篇文章不是在预测某个 title 会消失，而是在提醒一件更现实的事：软件组织比代码更早进入 AI 重构期。