23 AI 上完、五断点修完之后，组织长什么样

23 AI 上完、五断点修完之后，组织长什么样

上一章收的是资产，这一章收的是形状

上一章讲完那五样组织资产之后，有一句话是这么说的：每一样都在向前咬住这本书前面讲过的一件事。

这句话是对的，但它只收了一半。

它收的是资产：流程损耗图、人机分工和责任表、接进真实数据的工作流、验收指标、可复制 playbook。这五样让一条流程具备了可检查、可维护的基础。事情有没有做成，还要看约定结果和持续投入；下一条流程能否照着走，要另验接手条件与场景差异。

还有一半要检查：工作变了，原来的组织安排是否还接得住？

把组织图拿出来，先别急着重画。看任务变化以后，原来的授权、协作、资源和结果承接还能不能覆盖。如果能，旧框也可以继续用；如果不能，先改那个失配的接口。图上有没有新格子，不是改造成功的证据。

这一章提出一种候选形状，叫责任单元。它必须和已有部门、项目制、流程负责人安排放在一起比较，而不是先宣布旧图作废。

比较之前，先看看现有组织图表达了什么，又没有表达什么。

出了事，第一眼能不能看出该找谁

先从一个更老的问题问起：岗位为什么存在？

把一个岗位一层一层剥掉。名称可以改，运营专员改叫增长运营，昨天的事今天照做。人可以换，老王走了小李接。每天干的活可以变，今年做的和去年做的早就不是一回事。用的系统可以变，从 Excel 换到 CRM 又换到某个新平台。连部门归属都可以变，市场划到销售底下，销售又划回总部。

只要某一类结果仍然需要稳定发生，岗位设计就不能只写动作，还要回答：谁可以调动资源，谁处理异常，谁接住结果，条件变了由谁改安排。这是本书从责任一侧看岗位的方式，不是说岗位只有这一种功能。

任务可以拆，执行可以转交。拆开之后，原来捆在一起的判断、批准、复核和纠偏，也可以分给不同的人或机制。但不能只把动作交出去，把权限、资源和后果留成一笔糊涂账。

把 AI 放进来，先看它实际接走了哪一段工作。能生成初稿，和能独立交付不是一回事；能按规则推进，和这套规则一直适用也不是一回事。执行安排变化以后，原来的授权、控制和责任是否仍然够用，要重新核对。

本书要求结果有人持续承接。这不等于每一个中间动作都由人决定，也不等于判断、批准、复核、纠偏和损失承担必须压在同一个人身上。要能找到各自的接口，查到实际权限，验证异常处置和交接，确认组织有资源接住后果。

第十八章留下了一个组织方式的选项：人机协同的责任单元。这里把它展开。围绕一类可验收的结果，把负责的角色、可调用的人机能力、授权边界、控制与反馈安排放在一起，我把这样的设计称为责任单元。

它是本书拿来讨论协作安排的一个单位，不是组织必须拆到的最小一格，也不要求在编制表上新加一行。既有岗位、部门或项目组若已能履行这些责任，可以沿用。

判断它是否站得住，不只问出了事找谁。还得问：被找到的人能否获得信息、调动资源、处理异常，超出权限时谁接手，人员变化后责任如何不断线。名字是入口，实际履行才是要检查的东西。

换一个名字，不能算换一种组织

责任单元这个说法，容易让人想起独立核算、事业部或项目组。名称相近或不同，都还不能说明安排有没有变化。

先分清两个问题：这笔收入与成本记在哪里，这个结果由谁持续承接。两种边界可能重合，也可能不重合。不能因为关注责任，就把核算当成次要问题；不知道总投入和损失落在哪里，也很难判断一个安排是否值得保留。

责任单元要增加的，是一项明确检查：跨过岗位或部门的工作，能否沿着结果追到有效的授权、控制和承接安排。已有机制回答得好，不需要再造一个新词。

一个人带着一组 Agent，可能完成一类结果；几个人分工，也可能完成。参与者数量不能单独划定边界，签一个名字同样不能。还要看结果是否可验收，任务与上下文是否接得上，权限够不够，异常和后果能否被及时处理。

个人能多做一些事，不等于组织已经多了一项可交接的能力。他不在时谁接，方法能否复用，条件变了谁更新，这些都得另查。责任单元这个名字有用与否，就看它能不能帮助我们把这些问题查清楚。

一个人做得更多，公司就该变小吗

一个人借助 AI 能交付更多工作，并不能直接推出公司应该变小，更不能推出公司一定会消失。这里至少隔着两笔账：把工作放到外部，要付多少寻找、协调、验收和持续维护的成本；留在组织内部，又需要多少管理和公共投入。AI改变了哪些成本、改变多少，要在具体业务里算。

责任问题也不能替代这笔比较。它让我多问三件事：损失来了由谁承担，有没有可用的资源；错误发生后，谁能推动流程和规则真正改掉；人员变化以后，原有承诺如何继续履行。我把这三问简写成“赔得起、改得动、等得起”。

这是一组检查问题，不是公司的定义，也不能据此宣布只有公司能做到。内部组织安排、外部合作及其组合，仍要逐项比较：哪些责任确实有人承接，哪些只是写在承诺里，协调和维护的代价由谁承担。

对制造企业，这个检查同样不能只盯着屏幕里的流程。AI 改了信息采集或计划建议，要继续查它怎样进入排产、设备操作、交付和客户承诺。信息环节变快，不等于物理环节的约束消失；物理环节仍在，也不能反过来证明信息安排不必变。

所以我不在这里押公司变大还是变小。先把内部保留、外部委托、局部重配这几种安排放到同一组结果和成本要求下。哪一种拿得到更稳定的结果、能承担相应后果，又付得起持续运行的代价，再选哪一种。

能做多少，还要看接得住多少

一个单元该画多大，要看它交付什么结果，依赖哪些专业和资源，边界扩大以后还能否维持质量与控制。

假如一条错误规则被自动重复使用，它可能把一次错误扩散成一批错误；但扩散多快、多远，仍取决于权限、流量限制、监测和处置。不能只数 Agent，也不能只看某个人愿不愿意签字，就推定能承接多大的结果。

能力扩大了，承接条件没有跟上，就不能把边界照着能力往外推。这时可以补授权和资源，缩小范围，拆分职责，或者暂缓运行；不是只能再加一个人或再画一个格子。

后果承接是边界设计的一项约束，不是唯一尺度。执行效率、专业分工、共同知识、协作成本和投入产出仍然要算。本书选择把承接问题问得更细，不因此宣布它已经取代组织存在的其他理由。

我要求的检查很具体：不能因为审核环节都在、表格都齐，就推定它们真起了作用。

这一条连我自己那支 AI 团队也没能例外——三道审核叠在一起，照样让一句没跑过测试的「全部通过」穿了过去。它不能证明什么，只是让我更不敢把这句判断划掉。

这类经历能暴露一种失效方式，不能证明哪一种组织形态最优。接下来这五层，是我据此提出的一种安排，是否合适，还要回到真实结果、投入和交接条件上检验。

结果有人持续承接

责任单元，是把一组持续结果及其所需的权责、资源和协作安排放在一起检查的设计。它可以设具名牵头人，但不是要求一个人包办所有决定。

先看结果承接。谁负责什么结果，谁处理争议，谁能调动必要资源，谁接住已经发生的后果，都要明确。目标定义、专业判断、审批、叫停和验收可以分工。真正的问题是，有责任的人拿不到信息、调不动资源，或者几方都有一段权力，冲突发生后却没有有效的裁决和升级路径。

再看 AI 工作流。搜索、整理、生成、编码、分析、监控、按规则执行，可以随技术和业务变化重新组合。调整执行方式时，必须同时检查授权和承接条件；不能只把任务搬过去，把未结事项留在原处。

第三是上下文。企业知识、历史经验、可用数据、流程规则和判断依据，要让获授权的执行者取得，也要有纠错和更新的入口。存进去不等于用得对，自动写回不等于内容已经可信。

第四是控制机制。第11章的风险、恢复条件、判断要求和后果传播，提供的是选择控制的依据，不是一维对应一种人审方式。具体采用预授权限额、抽检、复核、审批还是禁止使用，要看权限、适用限制、控制效果和后果承接条件。逐单点头并不是责任成立的证明。

第五是对外责任链。客户、协作方和后来的接手者，能否在约定响应窗口内找到有权、有信息、有资源的承接者？组织内部怎样分工，不能成为外部问题无处处理的理由。

人可以换，班可以交，系统可以重做。必须持续的，是对结果的承接，不是某一个自然人永远坐在中心。交接要包含权限、资源、记录和未结事项；没有把这些交过去，换一个名字不叫接手。FDE可以帮助这一安排成形，也可以完成合格交接后离开，不必永远兼任结果负责人。

原承接者 → 核实交接 → 新承接者。

箭头表示需要核实的交接，不表示业务永不出错或交接已经完成。

相关，但不是同一个概念

可委托工作闭环，讲的是一件事是否具备交出去的条件。工作单元，讲的是任务被拆成什么颗粒。责任单元，讲的是这些工作及其后果由怎样的组织安排持续承载。三者不能当成别名互换。

一个责任单元可以承载多个工作单元；同一工作也可能需要多个单元协作，但接口、分工和争议处理不能因此悬空。任务拆分方式可以变化，承接安排也可以调整，前提是交接有效。

现有部门、业务线、班组是一种实际安排，不是等待改名的半成品。岗位则描述具体的职责与授权接口。要采用责任单元这个设计，就得说明它比原安排具体改变了什么：少了哪处交接断点，解决了哪种资源冲突，怎样改善质量、成本或后果处置。只有名字不同，就没有证明出现了新的组织能力。

说到这儿，我得把一件自己的事拿出来讲。

我自己公司里有过一位高级咨询师。她的活是跟客户开会、把需求搞清楚、用 PPT 把方案讲出来，做了大半年，图是手绘的，逻辑清楚，配色讲究。后来我自己跟客户谈完，转身让 AI 把方案讨论清楚、把 storyline 梳出来、把图和文字组装出来——原本一周的事，不到一杯咖啡的工夫。她没做错任何事，是岗位被我重新定义了。后来她自己另谋高就，我们体面地分了手。

我当年只能把她的岗位拆掉，那时候我给不出别的答案。

如果今天再遇到同样的情况，我会多问一层：这条线要拿回什么结果，原有岗位能否重新承担，所需权限、能力和支持如何补上。这是今天的推演，不是当时已经发生的安排，也不能保证换一个问法就能保住某个岗位。

再看我自己写书时的一段工作记录。

写这本书的时候边上跑着一支 AI 团队。有一天修个小毛病：一条注释跨了页，检查程序死活说它「在 PDF 里一次都没出现」，人眼看着明明在。执行的那一岗连改四轮匹配算法，四轮全败。第五轮才回头看最笨的一件事——被检查的 PDF 是两小时前的旧文件，前四轮分析的根本不是当前这版。

真因找到，改法上去，灯转绿。只看那盏灯，事就算完了。可留痕里记着一行数：这条注释被数成 6 份，实际是 2 份。灯是绿的，数是假的——算法一放宽，几个标点巧合的碎片也算成了匹配。是留痕自己把虚增抖出来的，不是那盏绿灯。补两条硬约束再跑，恰好 2 份。

那一天有几件事没变过：改的人不能自己判自己过，得另一岗独立复核；复核的不许只说「我看过了」，得把跑出来的输出贴上来，带通过数和失败数——这条规矩是上次栽跟头换来的。还有一处机器判定和实际对不上，执行岗没偷偷改掉它凑绿，是登记成一笔挂账，写明超出自己权限。最后东西摆到我面前，我一个字一个字看完，签字。

这套记录、独立复核和签认，帮我们追完了这一次错误。它没有消灭错误。要放进几千人的企业，还得另查跨部门资源、专业制衡、业务连续性和规模化后的控制成本，不能拿个人团队的局部实践直接拼组织图。

企业也不必按“工具、流程、岗位、责任单元”逐级通关。先找当前结果被什么卡住，再决定补哪一项；没有必要为了到达某个阶段而改组织。

先看哪里需要改，再决定画什么图

图 R10-F18｜组织图要不要改，看结果。原安排有效可以保留，失配可以先修订职责接口；采用责任单元也是待验证的选项。三种安排用质量、总投入、协作成本与后果承接同尺度比较。上方图标仅作示意，不规定三种安排的唯一拓扑。

现在把镜头拉远，看整条结果怎样穿过组织。

组织图可以帮助我们找交接，也表达专业分工、授权和控制。层级多，不等于每一层都多余；减少一次交接，也不等于减少了全部协调成本。先看工作记录：等待发生在哪，返工为何发生，哪个决定需要谁的专业和权限。

如果 AI 确实缩短了研究、起草、编码或核对的一段工作，下一步要查的是：节省有没有传到最终结果，复核和维护有没有增加，瓶颈是否转移。执行仍然可能是瓶颈，技术和数据也可能先卡住；不能预先宣布，管理只剩判断和责任。

查清这些，才有资格比较组织安排。原来的岗位和部门能通过补接口、调权限、改流程把问题解决，就保留。跨部门反复掉交接、没有人能协调完整结果时，可以试责任单元；试下来还要与原安排比较，不能因为换了名字就算改造成功。

两种安排都需要可信的记录、专业判断、有效授权和持续交付。科层组织不是只有汇报线，责任单元也不能只靠签名取信。组织图是否值得改，要由工作和结果来回答，不能由图本身来证明。

如果选择较自主的单元，就要说明公共资源怎么分、冲突如何处理、谁能改变共同规则。可以把共享底座、结果承接和跨单元仲裁画出来，作为一种待检验的设计；它们未必对应三个管理层级，更不是所有公司的统一形态。

管理岗位也按实际任务重新看。信息汇总减少以后，是否还有需要保留的专业判断、协调、培养和控制工作？哪些可以委托，哪些必须另配资源？没有验清这些，不能从一段任务变快直接推出整个管理岗位被淘空。

责任单元若有价值，应当在这样的比较里显现：结果更稳，承接更清楚，总投入值得，换人以后仍能运行。做不到，就继续修改或撤回这个安排。

别先问要设几个，先问那条线后面站着谁

读到这里，先别开会讨论该设几个责任单元。先选一条重要的 AI 流程，把实际承接安排摊开。

这条流程出了问题，能不能在约定时间内找到有权处理的人？牵头者、专业判断者、批准者和接替者可以不同，但谁处理什么、冲突往哪里升级，不能靠临时猜测。答得出名字是入口，信息、权限和资源接得上，问题才有机会被处理。

CEO先选一条线，明确结果、牵头安排、分工和所需资源；CHO把岗位要求写成具体结果与授权边界，不预设所有判断都必须本人保留；CIO和AI转型负责人把授权、留痕、停止条件以及第11章选定的控制方式接进系统。纸上写了什么，系统就应当能够执行、检查并留下记录。

再问三件事：拿回了约定结果吗？后果处理需要的资源到位吗？换人或换系统以后还能接得住吗？答不上来的先标为待查，不急着宣布整个部门无效。先约定观察窗口和验收条件，也不承诺所有改造都能在一个季度内验明。

哪些证据，会让我收回判断

我选择不让结果责任悬空，这是本书的规范立场。但怎样实现它，哪种组织设计更好，必须接受经验检验。

我能拿出来的是这些局部实践和一组待检验的设计。评价别人的方案，也应要求对方说明适用范围、实际证据和未解决的问题，不能因为我没见过完整样板，就说完整样板一定不存在。

如果我建议某条流程重配接口，而原来的安排在同样目标和约束下已经稳定受益，我就撤回这条流程必须重配的建议。如果原部门、项目制或流程负责人做得一样好，甚至更好，我就撤回责任单元更优、应当普遍推广的主张。

如果我把审批等待判成瓶颈，就该在动手前说清：改哪一处、预期先改变哪个信号、用什么记录来观察。资源确实到位、改动确实实施，等待却没有减少，就要重查这个诊断；如果等待减少了，质量或净收益却更差，就不能把“流程更规范”当成功。

如果一套做法声称可以复制，就要先约定合格接手者、支持条件、场景差异和维护成本。可比条件下仍然每次重做，而且拿不到可承受的增量，就把它降为本地办法。不能把难例移出样本，保住一个好看的复制率。

如果在相同约束、约定观察期和可比较任务上，AI承担复核、监控与纠偏的方案，能够达到质量和风险底线，整体效果不差、总成本更低，我就不坚持保留原来那道人工确认。撤掉按钮之前，权限、适用限制、异常阻断及后果承接仍须分别核实；控制方式可以换，不能把自动运行误当成组织不再需要负责。

这些比较要在事前写清目标、质量底线、成本范围和观察窗口。证据不足，结论就是还不知道，不是已经被推翻，也不是已经被证明。

本书的答案因此不压在一张新组织图上。原安排能满足，就保留；不能满足，就把查明的失配处改清楚。责任单元网络是一种可供检验的设计，不是所有组织唯一的终点。

最后押一个注，以这本书写作的 2026 年为起点。

三年以后你招高管，招聘启事上那一栏写的可能不再是部门名字，是一个后果域——不是「负责市场部」，是「对获客这条线的结果负责，包括它砸了的时候」。到那天，组织图上的格子就不是按谁管谁画的，是按谁认哪笔账画的。

这话我押在这儿。2029 年你翻回这一页，看我押错没有。它是我的预测，不是责任单元成立的前提。

而这个设计成不成立，不能只看出事时找不找得到谁。还要分别验证：有没有取得约定结果，承接者是否真有信息、权限和资源处理后果，交接以后能否持续，迁到新场景是否仍然成立。名字让问题有入口，能力让后果有人接，结果决定这套安排值不值得继续。