AI 上完之后，组织怎么办

最近见过一位企业负责人。他说想看看 AI 转型，聊到 RAG，也就是让 AI 先查公司自己的资料再回答，聊到企业知识库该怎么管，他的反应很轻：“这个不复杂，找两个新人整理一下就行。”那一刻，我脑子里冒出四个字：叶公好龙。

让我警惕的，是把企业知识库治理想成资料整理。那场会谈给我的，是一个需要继续追问的信号，不足以证明这家企业的全部组织安排都出了问题。

资料可以请新人整理，来源可信度、维护责任、使用权限、错误处理和反馈回流，却不能靠“整理一下”四个字带过。两个人能不能把事情办成，要看这些安排是否已经存在，他们有没有相应的信息、权限和资源，不是看他们够不够勤奋。

如果真正的缺口没有查清，只报一个系统上线日期，缺口不会因此消失。

账号、系统、培训和试点，让AI有机会进入公司。它的输出一旦被真实工作依赖，就要继续查：谁有权使用，谁维护依据，质量怎样检查，出了问题怎样处理。组织能力不能只靠工具清单来证明。员工对知识贡献的顾虑，也该进入这个检查：

我贡献给组织 AI 的判断，最后是用来放大我，还是替代我？

如果这个问题没有答案，AI 用得越多，组织未必越聪明。它可能只是让几个聪明员工更快，也可能让流程更乱，让责任更模糊，让知识更分散，让员工更会保护自己。这本书处理的，就是这个问题。

本书要回答的是：可调用的能力，如何成为可持续的组织能力。

我的主张是，AI 改变了工作的能力边界以后，企业要检查原来的授权、协作、知识更新和结果承接，是否还覆盖得住新的工作。覆盖得住，就保留；有明确失配，就比较修复办法。该改的是已经查明的问题，不是为了上 AI 先重画一张组织图。

模型不适用、数据拿不到、需求本身不成立，也会让项目走不下去。先找瓶颈，别把所有问题都叫成组织问题。

这本书不打算教老板买哪一个工具。它要帮老板追问：为什么输出快了，交付仍然慢？为什么工时省了，收益没有出现？为什么知识存进去了，下一次还得从头解释？为什么每一步都有人确认，出了问题却没有人能处理？

这些问题要逐个定位，也要逐个验证。先说清要改善哪个结果、哪处接口妨碍了它，再看改动有没有产生预期变化，连同复核、维护和处理后果的成本一起算。规则写全、名字填上，只说明有了可以检查的安排，不说明事情已经做成。

我把这件事称为组织底层系统升级。它不以改了多少岗位、增加多少 Agent 为成绩。工作的授权、控制和责任要接得上，结果还得持续拿得回来。

岗位、流程、知识、责任、治理，是本书选择的五个诊断入口。它们帮助我们定位问题，不是五种必须出现的病。先看岗位，是为了把“裁不裁这个人”拆成“哪些任务变了，哪些结果还需要承接”；再沿着工作往下查，看交接、知识和控制在哪一步出了缺口。

诊断之后，需要有人把问题落实到具体改动：业务要什么，系统能做什么，哪些承诺可以交出去，异常又由谁处理。这些职责可以由现有岗位承担，也可以由临时小队或专门角色协作完成。书中讨论的现场翻译与孵化角色，是一种组织办法，不是必须新增的职位。

这更像一份给企业一号位的改造说明书：选一条真实流程，写清目标与边界，试着修一处，再按事前约定的结果决定保留、扩大、缩小还是停止。书中的90 天、180 天安排提供推进节奏，不保证任何企业都能按同一日历完成转型。

写到最后，问题还会再往前走一步：当执行成本和协作条件继续变化，什么工作值得放在一个持续的组织安排里？最后一章提出责任单元作为一种可比较的设计，并说明它需要接受哪些检验。现有部门、项目制或流程负责人已经做得一样好，就没有理由为了这个名字另起一套。

合上这页之前，可以先拿一条正在运行的 AI 流程问自己：原来想改善什么，现在实际改善了什么，付出了什么代价？如果变化没有出现，先查瓶颈，再决定改工具、改接口，还是停下这个项目。

组织图可以不换。改善有没有发生，得拿结果说话。