工具退场以后(下)| AI 提高效率以后,团队为什么反而更忙?

工具退场以后 | 余一思

我认识一个团队，去年底开始用 AI 工具。

一开始效果很好。代码生成得快了，文档也能自动写。所有人都觉得，今年应该能轻松一点。

可半年过去，他们反而比之前更忙了。

每周的会没少，文档没少，加班也没少。有人甚至觉得，事情比去年还多。

我问他们为什么。

他们想了想，说：“不知道，就是感觉事情更多了。”

一个 AI 工具最轻松的时刻，往往是演示完成的那一刻。

需求被读取，文档和代码自动生成，测试全部通过。屏幕上的流程简洁、完整，仿佛原来需要几天完成的工作，已经被压缩到几分钟。

但演示结束以后，另一部分工作才刚刚开始。

有人需要补充业务上下文，有人需要核对生成结果，有人需要处理没有被工具理解的例外。错误一旦进入真实系统，最终承担排查、解释和修复成本的，往往又是另一群人。

AI 并不总是消灭工作。

很多时候，它只是改变了工作发生的位置。

代码生成得更快了，但需要有人准备更完整的上下文；文档自动写出来了，但需要有人逐条核对那些看起来正确的内容；工具完成了一次漂亮的演示，业务团队却可能要在之后很长的时间里纠正偏差、解释例外。

前面的节省集中而醒目，容易被记录。

后面的成本分散在不同的人和漫长的日常里，很少出现在同一张报表上。

于是，组织可能看见“生成时间下降了百分之多少”，却看不见为了让生成可靠，有多少人重新整理了需求、补齐了规则，又完成了多少次人工验证。

每一个孤立的工具，还会向组织征收一笔“上下文税”。

同一个业务概念，在需求工具里解释一次，在代码工具里解释一次，在测试工具里再解释一次。到了排障和监控工具里，也许还要重新解释。

工具节省的是一次执行的时间，组织承担的却可能是长期搬运上下文的成本。

如果 AI 提高了局部效率，却让更多人反复说明同一件事，那么组织得到的未必是能力，只是更快地产生了更多需要解释的结果。

所以，比建设工具更重要的，是让 AI 参与标准化。

它可以从散落的需求和技术文档中提取共同结构，识别缺失项；可以发现代码里的非标准写法，协助迁移；也可以整理历史故障、排障过程和最佳实践，让它们逐渐成为可检索、可验证、可复用的知识。

先识别非标，再协助迁移，最后持续守护。

AI 既使用资产，也帮助生产资产。

标准越清楚，它能够稳定处理的事情就越多；AI 参与得越深，原本散落的经验也越容易被整理成标准。

这个循环一旦建立，即使前端工具更换，底层积累也不会跟着归零。

这才是工具真正经过一个团队以后，应该留下的东西。

所谓组织资产，不是某一份文档，也不是把大量内容堆进一个知识库。

它更像一套彼此连接、能够持续更新的组织记忆。

为什么当初这样设计？哪些约束不能打破？同一个字段在不同业务里分别意味着什么？过去发生过哪些故障，又是怎样恢复的？什么情况下可以降级，什么风险绝不能接受？

文档、代码、测试、监控、故障记录和架构决策，都是这种记忆的载体。

重要的不是内容有多少，而是它们能否被找到、被理解、被验证，也能随着系统变化持续更新。

一份长期无人维护的文档，不是资产，只是遗迹；一套已经偏离真实业务的测试，也不是资产，只是一种虚假的安心。

资产之所以成为资产，是因为它能在下一次决策中继续发挥作用。

当团队把个人经验变成共同理解，把临时判断变成可以复用的规则，它积累的就不只是一套代码，而是下一次面对不确定性时，更快抵达清晰的能力。

但现实里，工具往往比资产更容易被看见。

一个新入口，可以在十分钟内完成演示；一段自动生成的过程，可以被录成视频；调用次数、使用人数和生成代码量，也很容易写进报表。

相比之下，梳理一个长期含糊的业务概念，可能需要反复讨论几周；统一一套接口规范，需要协调多个团队；补齐测试、日志和监控，往往只有故障没有发生时，才能显出价值。

这些工作的成果，常常表现为“一些事情没有发生”。

需求没有被误解，边界条件没有击穿系统，故障没有继续扩大。

可“没有发生”，很难被展示。

于是，灯光更容易落在舞台中央的工具上，而不是那些让工具真正可靠的人和事上。

这并不是说建设工具不重要。

问题在于，如果评价只看见入口的完成，却没有看见上下文由谁提供、结果由谁验证、长期成本由谁承担，那么工具创造的收益就会集中出现，代价却被悄悄分散到业务和日常维护之中。

我见过一个团队，做工具的人和用工具的人，一年里只开过两次会。第一次是需求评审，第二次是复盘。

复盘的时候，做工具的人说：“我们做的功能，你们都没用。”

用工具的人说：“你们做的功能，我们都不敢用。”

两边说的都是实话。可这两句实话之间，隔着大半年的距离。

如果每个团队都建设自己的入口，却没有共同的接口规范、知识结构和质量基线，最后得到的，可能只是一座座亮起的小岛。

每座岛上都有自己的助手、流程和演示，却很少有桥把它们连接起来。

真正需要建设的，不只是更多工具，而是岛屿之间的桥：统一的标准、可复用的资产、持续更新的知识，以及从生成、验证到反馈的完整链路。

组织最终会积累它持续重视的东西。

如果被反复看见的是工具，就会有越来越多的工具；如果灯光的落点慢慢从入口移向结果，组织才会积累真正能够留下来的能力。

AI 也会改变管理者的工作。

过去，研发经理的一部分职责，是拆解任务、分配人力、跟进进度，在关键节点完成评审。

当 AI 承担越来越多执行工作以后，管理者需要设计的，不再只是一张任务表，而是一套人和 AI 共同工作的系统。

哪些工作可以自动生成，哪些环节必须由人确认；哪些低风险变更可以自动执行，哪些高风险操作需要严格审批；生成结果怎样进行独立验证，发生问题时又如何快速回退。

设计工作系统，不是把 AI 塞进原来的流程，而是重新画一遍流程图。

还有一个问题，会决定这套系统最终带来什么：

AI 节省下来的时间，去了哪里？

如果开发效率提高一倍，团队随即接入两倍的需求，那么大家并不会因此更从容，只会以更快的速度重新回到满负荷状态。

工具创造出来的余地，不会自然留下来。没有优先级和边界，它很快就会被更多任务填满。

所以，当“做出来”越来越容易，“不做什么”反而变得更加重要。

过去，一个想法可能因为开发成本太高而自然消失。未来，大量想法都能迅速变成原型，甚至直接上线。真正稀缺的，将不再是实现能力，而是判断能力：这个问题值得解决吗？它应该进入系统吗？用户最终会得到什么？我们愿意承担它长期存在的成本吗？

AI 降低了行动的门槛，却没有替我们决定行动的方向。

能够迅速完成一件事，并不意味着那件事值得被完成。

健康的人机协作，不应该让一群人负责建设工具，另一群人负责吸收工具留下的误差。

做工具的人不只交付一个入口，也愿意走进业务，和使用它的人一起承担最终结果；做业务的人也不只是提供场景、补充语料和验证结果，他们对问题的理解，同样应该被看见、被命名，并沉淀成组织资产。

工具提高的不应该只是某个环节的速度，而是整个系统从理解问题、生成方案、验证结果到获得反馈的能力。

这比做出一个演示慢得多。

但它也是团队真正迈向下一阶段的一级台阶。

那天，群里的讨论持续了一阵。

后来有人问：“那我们现在能做些什么，来迎接 AI 时代？”

我想了想，说：

“先假设，今天使用的工具明天就消失了。然后看看，我们还留下了什么。”

需求有没有变得更清楚？散落的文档、代码、日志和案例，有没有逐渐成为可以复用的资产？系统边界有没有被重新梳理？生成的结果，有没有独立而可靠的验证方式？

如果答案都是否定的，那么我们得到的，也许只是一段短暂的效率提升。

如果其中一些已经发生了改变，那么工具便没有白白经过我们。它帮助团队从“怎样更快完成”，走向了一个更重要的问题：我们究竟应该完成什么？

工具有一点像建筑外面的脚手架。

搭建的时候，它们十分醒目。可建筑真正完成以后，脚手架终究会被拆掉。最后留下来的，不是那些曾经包围建筑的钢管，而是空间怎样被划分，光从哪里进入，人又将在里面怎样生活。

工具也是这样。

它们会一代代出现，也会一代代退场。

真正留下来的，是一个团队怎样定义问题，怎样验证结果，怎样把个人经验变成共同资产，又怎样在更多可能性面前作出取舍。

工具终会退场。

而它曾经穿过我们的方式，会留在工作里，成为工作新的形状。

写完这两篇，我仍然想把问题留给正在使用 AI 的你：

AI 为你的团队省下来的时间，最后去了哪里？

它变成了更从容的思考、更可靠的系统，还是很快又被新的需求填满？你们是在积累可以复用的资产，还是正在建造一座新的工具孤岛？

欢迎把真实经历留在评论区。不同团队给出的答案，也许比任何一场工具演示都更接近 AI 进入工作之后的真实世界。

如果你也在观察 AI 怎样改变工作，可以关注「余一思」。我会继续写下那些工具之外、却真正决定结果的变化。