AI 没有制造管理问题,它只是让问题更快暴露

我原本以为，这篇文章会很好写。

标题已经有了：AI 没有制造管理问题，它只是让问题更快暴露。

最近几次和企业管理者交流，我反复碰到类似的困惑。有人自己已经把 AI 用得很深，却很难把这种能力传到团队里；有人投入了人和钱做 AI 项目，最后却说不清楚问题出在哪里。谈话常常从工具开始，最后落到目标、流程和责任。

我甚至已经想好了结构：个人效率为什么没有变成组织效率，AI 怎样放大目标不清和责任模糊，组织又应该怎样调整。

但真正沿着这个方向聊下去以后，我发现自己不断停下来。

有时候是因为案例并不能证明我想证明的东西；有时候是因为一句刚刚听起来很正确的话，再多问一步，就没有那么确定了。聊到后面，我不得不承认，这篇文章真正值得保留的，可能不是那个一开始就已经想好的答案，而是我怎样一次次怀疑它。

最先让我停下来的，是一个软件项目的故事。

最近的一次交流里，有人跟我讲，项目中有两位工程师同时开发不同的功能。放在以前，每个功能可能都需要不少时间；有了 AI 以后，两个人推进得都很快。从各自负责的任务看，需求已经完成，页面也能运行，似乎没有什么问题。

可当这些代码回到同一个项目里，事情开始变得混乱。

公司原本已经搭好了一套可以重复使用的公共组件，像一盒大家约定共同使用的积木。有人按照这套积木开发，有人绕开它重新写了一套；更麻烦的时候，有人为了满足眼前的功能，直接改动了最底层的公共部分。局部看，每个人都完成了任务；整体看，却越来越难说清楚这个项目正在变好，还是只是在更快地积累问题。

我最初听到这个故事时，很容易把问题归结为代码风格不统一。

但再想一步，代码风格可能只是一个影子。如果未来越来越多的代码本来就不是写给人逐行阅读的，那么真正重要的，未必是两个人写出来的代码长得像不像，而是：他们各自完成的局部结果，能不能共同形成一个仍然可以理解、控制和继续演化的系统？

也正是从这个问题开始，我逐渐形成了标题里的判断。

但写下这句话以后，我又越来越觉得，它也许只说对了一半。

01一、每个人都变快了，组织为什么没有一起变快

在传统的软件开发项目里，一个需求从提出到完成，中间通常存在几种不同的判断。

有人理解业务目标，有人判断会影响哪些系统，有人拆解功能之间的依赖，有人协调时间与进度，最后才由工程师完成具体实现。这个流程当然不总是有效，也经常显得缓慢、繁琐，甚至官僚。但它至少保留了一些重要的问题：这件事为什么要做，会影响什么，谁来做决定，出了问题由谁承担。

AI 进入以后，“从需求到功能实现”这一段突然被压缩了。

一个工程师可以理解需求、设计方案、生成代码、修改错误，几乎一个人走完整条链路。原来需要几个人来回沟通的工作，现在可能在一次长对话里就已经做完。

这当然是一种真实的进步。问题在于，执行步骤被压缩了，不代表原来那些判断也自动完成了。

需求实现得很快，但它是否符合整个系统的方向？修改公共部分到底是一次合理的重构，还是为了完成眼前任务留下的隐患？两个功能是否应该合并成一套共同能力？当前留下的问题是可以接受的阶段性取舍，还是项目已经掉到某条安全水位线以下的信号？

这些问题不会因为代码已经生成而消失。

更值得警惕的是，旧流程可能消失得比新责任形成得更快。

以前，架构师、项目经理和工程师的分工不一定合理，但至少大家大致知道哪些问题应该由谁关注。现在，工程师可以跨过原来的多个环节直接完成结果，架构师容易退化成一个“大号工程师”，项目经理仍然能看到任务有没有结束，却未必看得见系统内部发生了什么。

谁都和结果有关，最后却可能没有人真正对整体负责。

这并不是 AI 出现后才有的问题。

我自己以前写代码时，也主动留下过不那么完整的实现。

有一次写接口，我知道其中一个逻辑分支并没有被真正处理好。但按照当时的业务条件，那个分支暂时不会被触发。为了赶上当前的交付，我先把可以运行的部分做完，再在代码里留下一段注释，提醒以后修改的人：一旦条件发生变化，这里的逻辑必须重新处理。

我当时并不是不知道问题，也不是认为这样做最好。我只是做了一个很现实的取舍：先完成眼前必须完成的事，把代价留到以后。

多人并行开发时也是一样。两个人的功能可能本来应该抽出一块共同能力，但工期很紧时，谁都不愿意为一项暂时看不见的成果停下来。

过去的问题常常是没有时间做得更完整。

可到了 AI 时代，情况出现了一点微妙的变化。原来两个人需要一周完成的任务，现在并没有因此继续获得一周时间。更常见的可能是，工期也随之被压到一天，甚至半天。速度释放出来以后，很快又被新的需求填满。

于是，原来的“没有时间判断”，逐渐可能变成“流程里已经没有人负责判断”。

我在另一场交流中曾经这样描述这种感觉：原来的速度是二，有了 AI 以后，速度变成了十。但并不是只有某一个人从二变成十，整个行业都在变成十。过去可以被缓慢执行掩盖的目标、协作、反馈和责任问题，会在更短时间里堆到眼前。

这似乎也不只是我的个人感受。DORA 在 2025 年关于 AI 辅助软件开发的研究中，把 AI 描述成一种“放大器”：它不会自动修复组织原有的系统，而会放大其中已经存在的优势和薄弱环节。反馈机制清楚、工程基础扎实的团队可能因此跑得更快；缺少协作、质量控制和共同标准的团队，也可能更快地感受到不稳定。^[1]

沿着这条线看，文章标题似乎成立了。

AI 像一面镜子，只是这面镜子把时间调快了。过去几个月才会充分暴露的问题，现在可能在一个迭代里就已经无处可藏。

可问题也恰恰出在这里。

02二、“加速”真的解释了全部变化吗

如果只是执行速度变快，那么即使没有 AI，只要出现一种能把执行速度提高五倍的工具，同样的问题是不是也会暴露？

我想，答案很可能是会。

大型项目在工期紧张、团队磨合不足的时候，本来就会出现局部最优、重复建设、技术债和责任模糊。AI 只是让这些问题出现得更快、更集中、更难拖延。

顺着这个推理，我一度觉得，AI 并没有带来什么新的管理问题。

但再往下想，这个结论又太简单了。

AI 提供的不只是速度。它还提供了更大的知识边界、更强的分析和推理能力，以及越来越多的自主执行能力。一个过去只能完成局部实现的普通工程师，现在可以借助 AI 触及架构、测试、数据处理甚至产品分析；一个并不了解全部历史背景的人，也可能在很短时间内生成一套完整得像是已经经过充分思考的方案。

这和单纯把原来的动作做快，并不是一回事。

当人不再逐行阅读 AI 生成的代码时，代码质量要怎样控制？不看代码和不控制质量当然不是同一件事。团队可以依赖测试、规则和各种自动检查，但由谁来设计这些控制？谁来判断检查覆盖了真正重要的风险，而不是只覆盖了最容易被发现的部分？

当 AI 给出一套看起来完整的业务方案时，生成方案的人、确认方案的人和最后承担结果的人，还是不是同一个人？如果不是，他们之间的边界在哪里？

这些问题中，有一些显然是旧问题。目标不清、责任模糊、部门协作不畅，在没有 AI 的时候就已经存在。

有一些更像是被放大的旧问题。错误可以被更快复制，局部产出可以迅速淹没下游，未经校准的方向可以以更低成本生产出大量“完成品”。

还有一些可能真的是 AI 带来的新问题：人在没有理解过程的情况下接受结果，判断被不知不觉地外包，组织无法解释一项决策究竟是怎样形成的，责任则在“这是 AI 给的”和“这是人确认的”之间来回漂移。

但到现在为止，我没有足够的亲身案例，清楚地划出这三类问题的边界。

所以我不想为了让文章显得完整，就替自己把这个问题回答掉。

我现在更愿意承认：加速是答案的一部分，但不是全部。AI 究竟在多大程度上只是暴露旧问题，又在多大程度上创造了新的组织问题，仍然是一个需要继续验证的假设。

这让标题没有那么确定了，却也让问题变得更真实。

不过，把前面的几个场景放在一起时，我还是看见了一个共同的空缺：产出在迅速增加，负责判断这些产出是否正确、是否值得、是否应该继续的人，却没有同步增加。无论暴露出来的是旧问题、被放大的问题，还是 AI 带来的新问题，它们最后都会经过这一道判断。

03三、当执行越来越便宜，什么开始变得稀缺

也正因为如此，虽然我还不能解释 AI 带来的全部变化，却越来越感觉到：当执行能力迅速增加以后，组织真正稀缺的东西正在发生转移。

以前，一个好想法可能卡在没有人、没有时间、没有技术能力把它做出来。现在，许多事情“能不能做”的门槛正在下降，真正困难的问题慢慢变成了：值不值得做，应该怎样做，做到什么程度，以及谁来为这些判断负责。

这首先是衡量标准的问题。

功能做完了，不等于系统更健康；内容生成得更多，不等于沟通更有效；销售线索增加，不等于线索质量和成交结果更好；客服处理时间缩短，也不等于用户真正得到了解决。

Klarna 的公开经历给了我一个很有意思的对照。2024 年，它公布了 AI 客服上线后的成果：处理量增加、响应速度加快，成本也显著下降。仅从这些指标来看，这是一个很有说服力的结果。^[2]

但到 2025 年，Klarna 的 CEO 又公开反思，公司此前过度强调成本，导致服务质量下降，并表示需要让用户始终保留获得人工服务的选择。^[3]

这并不能简单证明 AI 客服成功或失败。

它更像是在提醒我们：一个项目最初选择什么指标，决定了组织最先看见什么。处理量、时间和成本容易计算，复杂问题的解决质量、用户信任和长期关系却更难被放进同一张表里。如果衡量标准没有随着能力变化重新校准，组织很可能不是没有获得结果，而是只获得了自己最容易计算的那部分结果。

但指标不会自己选择自己。由谁决定用什么衡量结果，由谁发现原来的指标已经漏掉了重要的东西，又由谁在短期数字很好看时提出修正，这些本身就是系统级判断。

回到开头的软件项目。过去的架构师可能会参与需求分析、技术方案和代码评审。未来，这些具体动作不一定还要由同样的职位、按照同样的流程完成。一个与时俱进的架构角色，也许不需要在每个项目里逐行检查代码，而是需要同时理解业务和系统，把关键约束、允许修改的边界、质量标准和判断依据，提前写进团队与 AI 共同工作的环境里。

他可能更像一个把业务经验、系统经验和 AI 协作方式连接起来的人。

我还不确定这个角色最终应该叫什么，甚至它也未必需要由一个固定的人长期承担。但这项责任不能因为原来的职位正在变化就一起消失。

AI 可以生成方案，却不能替组织决定由谁承担判断；可以发现大量问题，却不能自动决定哪些问题必须现在解决；可以帮助团队重构系统，却不能替团队承受推翻已有成果时的心理和现实代价。

04四、也许组织需要的不是一次改造，而是持续校准

如果一开始就无法制定一套永远正确的规则，组织还能做什么？

我目前想到的答案，不是先设计一套完美的 AI 管理制度，而是建立周期性的对齐和复盘。

这个想法首先来自我自己使用 AI 的过程。

最近我几乎每天晚上都会回头看一次当天的工作。不是简单列出完成了几件事，而是看哪些地方走偏了：原来以为应该这样做，实际运行以后为什么不合适；哪些步骤仍然是我在按照过去的习惯控制，哪些事情已经可以交给 AI；今天出现的问题，是一次偶然的执行错误，还是说明整个协作方式需要调整。

有时复盘以后，第二天只是改一句提示、换一个步骤。有时却会发现，前面一直坚持的做法本身已经不值得继续。

这种回看并不是为了证明今天做对了什么。恰恰相反，它更像是暂时把已有做法放到一边，再问一次：如果今天重新开始，我还会这样设计吗？

个人的方法当然不能原样复制到组织。一个人的复盘不需要协调多方责任，也不必面对不同角色对已有成果的保护。但它至少让我看见，人与 AI 的协作方式不可能只在开始时设计一次，之后就永远不变。

到了团队里，复盘未必需要每天发生。一个项目、一次迭代或者一个阶段目标结束时，可能是更合适的节点。只有在目标暂时完成时，人们才有可能从执行状态里退出来，看见执行过程本身。

探索中当然会出现问题。两个工程师可能采用不同的实现方式，AI 可能给出不成熟的方案，原来制定的规范也可能很快过时。问题本身并不可怕。真正危险的是，组织没有一个明确的时间点把这些问题重新归拢、判断和处理。

但复盘也很容易变成另一种形式主义。

大家总结哪些地方做得不错，把原来的经验重新写一遍，再列出几条下次注意事项。这样的复盘更多是在确认过去，而不是重新检查过去。

我现在越来越觉得，一次真正的复盘，需要保留“如果从头再来一次”的勇气。

这并不意味着每次都要推倒重来。它只是要求我们暂时放下对已有方案的依恋，重新问：如果今天第一次面对这个问题，我们还会选择同样的结构吗？哪些代码、流程和岗位仍然有价值？哪些产物最大的价值，只是让我们知道这条路走错了？

这个过程可能并不舒服。

对工程师来说，最难接受的事情之一，就是发现自己花了很长时间完成的东西，在下一个阶段已经不值得继续保留。即使代码主要由 AI 生成，人仍然会把它理解为“我和 AI 一起完成的成果”。承认它应该被重构，甚至从头再来，并不会因为生成成本降低就变得轻松。

可 AI 时代可能会让这种情况更常见。

执行成本下降以后，代码、方案和流程本身未必还是最重要的资产。一次探索留下的判断、失败经验和边界认识，反而可能比最终产物更有价值。有时候，一段工作的意义不是形成了一个可以长期使用的答案，而是让团队用更低的成本确认了一条路不值得继续走。

如果组织能够在每个阶段重新吸收这些经验，修改下一阶段的规则、工具和协作方式，它就不只是在“使用 AI”，而是在和 AI 一起改变自己的工作系统。

我暂时不想给这种能力一个更大的名字。对我来说，它现在只意味着一件很朴素的事：AI 的能力在变，团队的能力在变，业务环境也在变，组织需要持续观察结果、承认偏差，并把新的判断重新写回工作方式。

一次培训、一次流程再造或者一份 AI 使用规范，都不太可能完成永久的转型。所谓“AI 落地”，也许不是一个做完即可关闭的项目，而是一段需要反复校准的过程。

05五、我决定继续追问的问题

写到这里，我仍然不能证明，AI 没有制造新的管理问题。

随着 Agent 获得越来越多自主行动能力，责任、判断、信任、隐私和控制都可能出现过去没有的形态。标题里的绝对表达，仍然需要被后面的观察不断检验。

但我越来越确定的是，AI 的能力越强，组织原来的目标、责任、衡量标准和反馈机制，就越难继续躲在缓慢的执行速度后面。

过去，一个方向错误的项目可能因为推进缓慢，很久以后才让人意识到问题。现在，它可能在很短时间内交付出大量结果。过去，一个能力很强的人也只能影响有限的工作；现在，他可以借助 AI 同时推动许多任务，也可能同时放大自己的盲点。

AI 没有让管理变得不重要。

恰恰相反，当执行越来越容易，管理中那些不能被直接生成的部分——目标、取舍、责任、判断和修正——开始变得更加清楚。

写到最后，我又回到最开始的那个软件项目。

两位工程师都完成了自己的功能。也许他们使用不同的方式本身并不是问题，也许其中一次改动底层组件，最后会被证明是更好的方案。我们现在掌握的信息，还不足以判断谁对谁错。

真正让我在意的是：当他们各自向前跑的时候，谁会在某个时间点停下来，看一看这两个局部正在把整个项目带向哪里？如果方向出现偏差，谁有责任指出来，又由谁决定接下来是继续、修正，还是重新开始？

我现在还不知道这个角色最后会叫什么，也不知道每一种组织是否都需要相同的答案。

只是越来越觉得，在 AI 把每个人都推得更快以后，这个问题已经不能再一直没有人回答。

这不是我已经得到的答案。

这是我决定继续追下去的问题。

06资料说明

^[1]: Google Cloud DORA，《State of AI-assisted Software Development 2025》。报告将 AI 描述为组织系统的放大器，强调其效果取决于既有技术与组织环境。

^[2]: Klarna，2024 年 2 月 27 日新闻稿《Klarna AI assistant handles two-thirds of customer service chats in its first month》。Klarna 当时披露，其 AI 客服在上线首月承担了约三分之二的客服对话，处理量相当于约 700 名全职客服，并预计带来约 4000 万美元利润改善。

^[3]: Bloomberg，2025 年 5 月 8 日关于 Klarna CEO Sebastian Siemiatkowski 反思 AI 客服成本优先与服务质量的报道。