AI 尚未重建组织。是焦虑先重建了管理

隧道视野是指当注意力、判断力，甚至感知本身都被压缩到过于狭窄的范围时所发生的现象。眼前的事物愈发醒目，而周围的信号——有时甚至是更为重要的信号——却逐渐淡化。

受OpenClaw的影响，我的团队在去年三月经历了一段异常紧张的时期。我们每两周就要发布一个Agentic OS——一款面向智能体的Linux操作系统——而且节奏几乎立刻就加快了：每两周一次发布、每日同步、每周设定里程碑。

管理层传达的信息很简单：快点行动。让AI负责快速的部分。如果等到所有问题都彻底想清楚再行动，时机就会错过，别人早已抢先推出产品。

这一波浪潮必须抓住，等等。

令人感到奇怪的是，最值得深入思考的部分反而成了很少有人愿意讨论的话题。我们究竟是在加速解决问题，还是仅仅在加速产出“问题已解决”的证据？

视野变窄并不意味着判断更敏锐

隧道视野最危险之处不在于让人变得盲目，而在于留在视野中的事物会显得仿佛就是正确的答案。

在速度、压力、恐惧、疲惫等多重因素下，个人的注意力会被收束成一点。组织也会出现类似的情况。当外部标杆愈发耀眼时，内部团队更容易将注意力集中在那些最显眼的信号上：速度、发布、公关、曝光度，以及抢占市场先机的紧迫感。

于是，复杂的问题被简化为一些易于操作的举措：缩短周期、增加同步频率、提前汇报、强化里程碑管理。

这些举措本身并无不合理之处，但叠加在一起时，它们的性质便悄然改变。它们开始承担起原本不属于自己的功能：用更高频的可见性来填补本应由判断力提供的稳定性空白。

视野的收窄并不等同于判断力的清晰。更多时候，它只是让人更容易忽视那些决定成败的关键要素：问题是否被清晰界定、用例是否真正收敛、边界是否划定、风险是否已被明确，以及最终由谁来承担代价。

AI降低了原型开发的门槛，但并未降低复杂系统落地的难度

借助AI编程，编写代码的速度更快；基于智能体的产品也更容易启动运行。过去需要数周才能拼凑出来的东西，如今几小时内就能摆在桌面上。

这给管理层带来的刺激是立竿见影的：既然别人都能跑起来，我们为什么还在讨论边界问题？

于是，组织往往把外部信号误读为内部结论：只要能运行，剩下的就只是执行了。

然而，那些并未因此变得简单的环节——目标定义、场景收敛、权限边界、质量标准、协同机制、风险归因、故障回滚——却被悄然推至边缘，很大程度上是因为它们并不“显眼”。

原型越廉价，就越容易营造出成功近在咫尺的错觉。一旦这种错觉占据主导，人们往往会选择阻力最小的路径：不是把问题想清楚，而是进一步加快节奏——压缩周期、增加汇报、提升曝光度，用管控来弥补判断上的不足。

前者要求直面不确定性，后者则可能仅凭焦虑驱动。

焦虑驱动型管理的标志：以时间而非问题为导向组织压力

健康的管理应当围绕问题本身来配置资源：

• 问题是否真的清晰？
• 能否砍掉一半的场景？
• 哪些风险需要尽早暴露？
• 阶段如何划分，何时可以进入沙盒测试、试点或小范围上线？

而焦虑驱动型管理则倾向于围绕时间来施加压力：

• 今天同步了吗？
• 日报发了吗？
• 为什么还没有更明确的结果？
• 周期还能再压缩吗？

这两组问题看似都在推动进展，但实质上指向的方向截然不同。前者聚焦于解决问题，后者则试图平复不安。

久而久之，我明白了为何这种组织行为不仅让我感到不满，甚至隐隐愤怒。它形成了一种微妙的激励机制：高频同步天然奖励那些能被展示的内容，惩罚那些无法被量化呈现的判断。

一段时间后，团队在将工作转化为可见进展方面的能力，远胜于将不确定性转化为清晰边界的本领。

而我们得到的，却是一种看似高效的表象：更忙碌、更密集、更快、更显眼——却未必离正确更近一步。

Linux操作系统安全团队较早感受到裂痕并不意外

并非每个团队都会在同一时刻撞上这堵墙。像我这样的团队，专注于Linux操作系统安全，会更早遇到瓶颈，因为我们面临的不仅是能否把东西做出来，更是做出来之后具备什么样的能力，以及由此带来的后果。

在应用层，尽早跑通原型确实有助于试错，粗糙的结果也不一定会引发系统性事故。但在操作系统安全领域，演示逻辑并不能直接照搬到真实系统中。

这里牵涉到系统边界、执行权限、故障影响范围、回滚成本以及可审计性负担。你可以接受某个组件还不够智能，但很难接受它已经被赋予了本不该拥有的能力。

在安全领域，真正昂贵的往往不是让系统运转起来，而是回答那些缺乏光环的问题：它是否应该具备这类能力？在什么范围内运行？能访问哪些资源？

出错时由谁来承担责任？回滚路径在哪里？

这些问题在发布会的PPT上不会成为亮点，但在复杂系统中，它们才是真正的成本结构。遗憾的是，在已经深陷FOMO（害怕错过）的管理层面前，这一整套判断与权衡很可能被隧道视野所掩盖。

让人精疲力竭的不仅是工作量，还有不断证明工作“真实存在”的需求

与团队交流后，我意识到许多人反感的并非日报本身，而是一种工作状态：不断地被打断、被质疑、被要求证明自己的价值。你不仅要完成工作，还要持续提供“工作正在进行”的证据。

最糟糕的不仅仅是耗费的时间，更在于它对注意力结构的破坏。深度判断依赖于思维的连续性。许多重要决策并不会在一次同步会议中浮现，它们是在一段相对完整的思考过程中慢慢酝酿而成的。

一旦思维被切割成碎片，人们就会从解决问题转向为组织“表演一致性”。你开始选择那些当下就能展示的东西，而不是那些虽重要但暂时看不见的部分。

对我而言，还有另一种代价，它会渗入身体。这不是一次冲刺式的疲劳，而是长期处于高度警觉状态所带来的缓慢消耗。

我反对的不是速度，而是用高频执行来假装不确定性已经很低

坦率地说，管理层的焦虑并非无源之水。外部变化正在加速，期望也在重塑。日报和高频同步本身并非一无是处。在应急响应、任务已明确的工作场景，或者多个团队确实需要紧密协作时，它们甚至可能是必要的。

我反对的是另一种现象：问题尚未收敛，边界尚未划定，工作却已经在高确定性执行阶段的节奏下推进。那不是执行，而是用密度代替判断。

技术团队也不能以复杂性为借口。划定边界并不等于拒绝行动，厘清风险也不等于保守。成熟度不在于动作更慢，而在于更快地区分哪些可以先做、哪些必须先想清楚、哪些绝不能越界。

专注不同于收窄。真正的专注是在把握全局的前提下汇聚资源；而在压力之下，收窄则会舍弃周边信息，直到只剩下那个愈发醒目——也愈发危险——的局部目标。

真正值得加速的是让问题收敛的能力

如果说在AI时代有什么值得加速的，我希望寄望于几种看似不起眼、但从长远看更经济的思维方式：

• 问题定义：不要过早用华丽的辞藻包装方向。先问：我们到底在解决什么具体问题？为什么需要用新的方式来解决？
• 场景收敛：焦虑会让组织想要一步到位——叙事、产品、平台、云迁移、战略定位。成熟的加速往往始于敢于取舍的勇气。
• 明确边界：权限、数据、可审计性、回滚、责任——这些不应留到产品上线后再考虑。越是接近高权限系统，这些问题就越需要及早公开讨论。
• 阶段门控式判断：哪些只是原型，哪些适合沙盒测试，哪些可以进入试点，哪些绝不允许接触生产环境。这比单纯缩短几天周期更重要。

速度本身并不是一种能力。真正的能力在于知道速度该用在何处。

AI是否会重塑组织，最终取决于它首先放大了什么

AI几乎肯定会持续改造产品、流程和角色，这一点难以阻挡。但在任何实质性重构开始之前，许多组织可能会先经历另一件事：AI就像一个放大器，将原有的习惯与本能进一步强化。

当组织与AI相遇时，最先被放大的是什么？

• 你是先厘清问题，还是先炒热故事？
  （界定问题的能力 vs. 构建叙事的冲动）
• 你是先明确边界，还是先加快节奏？
  （边界判断能力 vs. 以管控平复焦虑的本能）
• 你是先设立阶段门控，还是简单地让汇报与同步更频繁？
  （成熟的门控机制 vs. 更密集的汇报）
• 你是否会拓宽视野，关注风险、成本与停止条件——还是随着事务越来越繁忙，注意力被收窄到只剩演示、公关与发布速度？
  （更广阔的判断视野 vs. 更狭窄的隧道）

如果变革首先催生的不是更好的判断力，而是更快的自我证明，那么它究竟在重建什么？它是否真的在重建组织能力？

更令人唏嘘的是，不少管理者对此竟表现出由衷的兴奋。

也许，这就够了。