21 90 天、180 天、1 年如何把 AI 组织改造跑成闭环

21 90 天、180 天、1 年如何把 AI 组织改造跑成闭环

我看过一家企业，四个动作一个不缺。规划做完了，POC 跑通了，报价也给了，推动的副总还拍了板。

然后什么都没发生。

技术那一侧的答案，它是买到了。组织那一侧的答案，一个都没开始准备。

停在这个位置上的 AI 项目不止这一个。这类项目在技术侧通常都挑不出毛病：系统在技术层面全部达标，供应商的交付报告写得很漂亮。它们的共同点不是技术验证失败，是技术验证成功之后，没有人接得住。

我讲这个开头，是因为老板手里那张 AI 转型路线图，通常回答不了这件事。让人做一张出来，交上去的十有八九是这样一张表：第一季度部署知识库，第二季度上智能客服，第三季度跑数据分析，第四季度全员普及。有逻辑，有进度，有时间节点，放进 PPT 汇报给董事会，一页纸显得很充实。半年后，它会变成一个沉默的证人。工具部署了，可没有哪条流程被改写。培训做了，可没有哪个岗位的工作方式真的变了。Demo 给管理层看过了，可落地的阻力不会因为 Demo 通过就消失。这种东西不叫路线图，叫采购计划。

这种停摆不是个案，它的样子往往还很体面——没有人反对，也没有人推进。项目停在审批环节，业务线说没有人手做接口对接，IT 说预算不在这一年，运营说流程还没梳理清楚。三句话单独拿出来听，每一句都成立。合在一起，就是没有人负责。

组织没准备好接住一个已经通过验证的系统，它就在技术可行和组织落地之间的空隙里悄悄搁置了。注意这个空隙里没有反对票。AI 转型很少死于有人拍桌子说不行，它死于每个人都说「这事挺好，就是不归我」。

真正的路线图不告诉你什么时候买什么工具。它告诉你的是这几件事：哪条流程要被改写，谁对结果负责，90 天后看哪张账，180 天后改哪条制度，第一年结束时组织有没有学会复制。

第一切口：选老板能看见账变化的流程

第一步，不要选最复杂的流程。这是一个很常见的陷阱：很多老板觉得流程越复杂，AI 能改进的空间越大，一旦跑通，就能说服全公司。听起来合理，实践里却往往走不通。

最复杂的流程，通常也是权责最模糊的流程，涉及部门最多、例外最多、审批最多、历史包袱最多，管理层也最难在 90 天内看到结果。第一切口不要选最难的流程，要选老板能看见账变化的流程。

这里的账，不是财务报表里的某个科目。我建议先看流程损耗三账：时间账、等待账、知识账。

时间账，看员工在这条流程里到底花了多少工时，其中多少是重复劳动。等待账，看多少时间耗在等回复、等审批、等上游数据、等确认上。知识账，看这条流程里的专业判断，有多少已经写成了别人能用的东西，又有多少还只活在几个老员工的脑子里。

流程损耗三账都可以算，但不必同时建。挑切口的关键只有两问：哪一张账，老板每天都在肉身感受？哪一张账一旦摆出数字，老板会说“这个值得改”？

最适合当第一切口的流程，通常有三个特征。结果能被直接看见。改进能在 30 到 90 天内被测出来。有一个具体的人，愿意把自己的名字签在这件事上。

三个特征缺一个，项目就容易变成亮点工程——大家都觉得有价值，但没人真正负责。

这种项目的下场很好认：季度总结里它是亮点，年度复盘里它没踪影。

三个特征都齐了，也还是可能选错。有一条路我带着走了一个月，最后发现不能走。

那件事当时怎么看都对。客户要建联大量达人，需求明确得不能再明确。照着上面那三条挑，它一定会被挑中。

我想做的事很直接。让系统自动去加达人好友，自动发评论，自动私信。把建联这件事整个自动化掉。

技术上不难。做出来了。问题是两头都不答应。

一头是平台。这类社交平台对自动化动作很封闭，风控很紧，动不动就关号。这里有个反常的地方值得停一下：系统跑得越顺，账号反而越危险。而那是客户的账号，不是我的。

这一层其实是查得到的。做之前谁都能查到平台不欢迎这类动作。但查到的不是一条禁令，是一个概率——可能关号，不是一定关号。

一个概率是不会让人停手的。它只会被当成一项可以承受的风险，折进排期里，然后接着往下做。

另一头更要命。那一层是我们跟客户一起做测试的时候，才想明白的。

单独加一两个达人，没问题。但客户真实的需求是要见大量达人。量一上去，性质就变了。

我一个月后才想明白这个「性质就变了」到底变的是什么。一两个达人被 AI 加，没有人会在意。那看上去只是一次效率高一点的联系。可成百上千个达人都这么被加，事情就不是效率了。它成了一种对待人的方式。而对方能感觉出来。

达人是被 AI 自动加的，加完之后又一路都在跟 AI 互动。他知道自己面对的不是一个人，是一套流程。到这一步，达人自己的感受不好。这件事没写在任何一版需求文档里，也没有哪个功能点对应它。

这件事一想通，结论就很清楚了。这是一个必须要人类介入的环节。

两头的代价，撞上去的方式完全不一样。平台那一头是明的。风控就在那儿摆着，做之前查一查也能查到。达人那一头是暗的。它不在系统里，也不在需求里，它在量里。做一个的时候它不存在，做一千个的时候它已经发生了很久。

我在当时的文档里写下的一句话是：这不是技术难不难的问题，是产品立场问题。

想明白还不算完。同一份文档里，我把它落成了一条产品原则：不要让 AI 越权执行关系动作。AI 不应该替人完成社交关系动作。写下这条的时候，我要挡的不是某一个功能，是往后所有长得像它的功能。一次判断只挡一次，一条规矩挡的是往后每一次。

选切口的那三个特征，管的是这条流程值不值得动，不管这条流程该不该由 AI 来动。它们能帮你避开选错难度，避不开选错方向。

0-30 天：建账，定人

0-30 天只做两件事：建账，定人。

建账，就是拿三张账把这条流程的现状测一遍。

时间账，翻过去一个月：员工在哪几个节点上花掉了多少工时，其中多少是重复动作。等待账，把等回复、等审批、等数据的时间加总，再和实际干活的时间比一比。知识账，数一数这条流程里的判断标准，有多少已经落成文档，有多少还只存在于某个负责人的经验里。

这些数字一开始不必精确到小数点后两位，但必须能追溯到出处，不能只靠“大家感觉这里很慢”。感觉不能验收。

定人，就是在 30 天内把一个人的名字锁死，由他对这条流程的 AI 改造负完整责任。

这个人不是 IT 系统管理员。不是供应商项目经理。也不是“AI 项目组”这种没有身体的集体名词。他得是懂这条流程业务逻辑、能对结果负责的内部人。而且他必须清楚：90 天后自己要交什么。

账没建起来就选工具，是在赌博，赌 AI 工具的能力恰好和流程的真实痛点匹配。这个赌局有时会赢，更多时候会输：工具买回来了，流程没有改变，最后有人说“我们试过 AI，没用”。不是 AI 没用，是你没有先把账和人定清楚。

三张账也不是财务部的新表格，是老板和业务负责人共同看流程的方式。时间账让人看见重复劳动，等待账让人看见组织摩擦，知识账让人看见经验是不是还困在个人身上。

很多企业一谈 AI 就立刻跳到工具。工具当然重要，但工具只是解法；没有把账算清楚，就只能拿到供应商递来的答案，拿不到从自己的组织问题里长出来的答案。

举四条常见流程，看看账不同、切口会差出多远。

客服流程最痛的是客户历史信息找不到，切口就落在客户画像和订单历史联动上。维修流程最痛的是前线拿不到设备说明书和历史案例，切口就落在知识检索和故障排查上。招聘流程最痛的是简历初筛和入职后的实际表现对不上，切口就落在筛选标准结构化和入职后复盘上。总办信息采集最痛的是每天手动追公开数据，切口就落在自动抓取、入库和初步分析上。

同样叫 AI，切口完全不同，因为账不同。所以 0-30 天不能省。省这一个月不是为了跑得快，是拿后面三个月去赌。

31-90 天：进入真实流程

31-90 天只做一件事：让 AI 进入真实工作流程。不是演示，不是沙盘，不是老板看一眼觉得有意思。是真实业务产出要开始依赖这条流程。

进真实流程之前，先把这条流程里的活拆成四类。

第一类是有规律可循的重复动作，AI 可以直接接手。第二类是要对信息做判断的分析活，让 AI 出初稿、人来定。第三类是要调用老经验的知识活，得慢慢把判断标准沉成知识库，再让 AI 去引。第四类是有人要为后果签字的责任节点，AI 只能打下手，替不了。

把这四类在流程上的分布标出来，才谈得上 AI 从哪儿切、怎么切、哪个节点必须留人复核。

跳过这一步直接上线会怎样？AI 大概率被用在它最擅长、但对业务影响最小的地方。那些真正耗时、真正承重、真正错不起的判断节点，一个都没被碰到。

试点范围不用大。三到五个人的团队，一个完整业务周期，一条真实流程，能产出真实业务结果就够了。

到这里最容易走偏的，是把试点当成一场技术验收：跑通了就算过，跑不通就换工具。回头看开头那家企业——它的技术答案是买到了，四个动作全做完，结果为零。所以试点真正要买的从来不是技术答案，是组织答案。

试点的目的不是证明 AI 多强，是把组织卡点逼出来。哪个节点的复核标准说不清楚？哪个判断没人愿意签字？哪部分知识始终没沉下来？哪段流程人机一协同反而更慢了？

这些才是 90 天最值钱的东西。它们全是组织问题，不是技术问题，只有真实跑过一遍才会露出来。

我当时是他们的实施顾问，在现场。技术这一关是过了的——系统我们交了，能跑，他们自己的政策和业务知识库也建起来了，验收没问题。

问题出在验收之后。员工手里有了 AI，工作方式还是老样子——还是按原来那套干活。

知识库也一样。建完之后很长一段时间没有人更新维护，上传的东西也不够；更要紧的是，组织流程没有跟着改，知识管理这件事本身没有真正做起来。库还在那儿，内容停在了上线那一天。

后来董事长下了命令：重新排查，重新上传。这一遍动员了多个部门，前后折腾了几个月。

同样一件事，做了两遍。第一遍是项目预算里的活，有节奏、有人管；第二遍是被追着做的。技术验收签字的那天，组织改造一步都还没开始——所以第 90 天那场会，必须有人坐下来认这笔账。

组织问题只有真跑一遍才会露出来——这句话反过来说就是：跑完这一遍，必须有人坐下来认这些问题。所以第 90 天的会不能开成总结会。

第 90 天：开决策会

第 90 天必须开一次复盘会。不是总结会，是决策会，只允许四个结论：停下、调整、扩大、复制。

切口被证明不适合 AI 介入，就停下，把原因写清楚。方向对、执行有问题，就调整了再继续。试点达到验收标准，就往更大范围扩。这条流程的经验能迁到另一条流程上，就启动第二条流程的三账测量。

开会必须带三类证据进门。

第一，三张账的数字和 30 天前比，哪张变了、变了多少。第二，复核机制跑这段时间，逮到过哪些 AI 错误、怎么处理的。第三，流程责任人对下一步有什么具体建议。

没有证据就不要拍板。AI 转型不是靠气氛推进的。靠气氛推进的项目，最后都会死在气氛里。

四个结论里，最难开口的是「停下」。

前面讲的那条自动建联的路，最后就是停在这个结论上的。但它不是被谁罚了才停的。那时候还没到见客户的日子，是我自己先刹的车。

停下不等于什么都不做。真正费劲的是停下之后重新划界线，一条一条划。

继续做的是这四件事。筛选谁该联系。生成建联的话术。推荐用哪个渠道联系。把内容复制好、排好队，提醒运营去发。

不做的是这三件事。自动发评论。自动加好友。自动私信。

界线划完，还有一件更细的事：产品里的说法跟着全改了。原来叫「自动触达」，改成「AI 辅助建联」。原来叫「自动发评论」，改成「生成评论建议」。

还有第三条，改的东西不一样。原来叫「触达失败」，改成「待人工处理」，或者「渠道不可用」。前两条改的是 AI 干什么，这一条改的是 AI 干砸了之后归谁。一件事失败了就摆在那儿，跟一件事失败了有人接，是两种流程。而要是那条路本身就走不通，说清楚是路的问题，人才不会白接。

这看起来像文字游戏，其实不是。界面上写着「自动」，用的人就真会以为可以撒手。措辞不是包装，是在告诉使用者这里该不该有人。

所以第 90 天那场会，选了「停下」并不算完。停下只是选完了。接下来要动手改的是三样东西。这条流程里哪些动作继续做，哪些不做。产品里那些暗示「不用管」的措辞。还有岗位职责里对应的那一段。三样都改完，这个「停下」才算真的落了地。

91-180 天：选择产能去向

90 天后，如果结论是扩大或复制，接下来 90 天面对的就不再只是技术问题，是人力和制度问题。AI 释放出来的产能流向哪里？如果没有答案，制度化就会停在纸面上，员工也会用脚投票。

员工心里那几个问号，其实很朴素。把时间省出来，对我是好事还是坏事？做得更快，会不会只是被要求做更多？AI 做对了算谁的绩效，做错了算谁的责任？

产能分配的方向只有四个：降本、增产、提质、重组。

降本，是把省下来的工时折算成人力成本的节约。增产，是把这些工时重新投进产品交付，把产出做多。提质，是把工时挪到判断型和知识型的活上，把结果做稳。重组，是重画岗位边界，该合的合、该拆的拆，长出一套新的职责结构。

四个方向可以组合，但不能都选。都选，等于没选。

含糊的产能分配，翻译成员工听得懂的话就是一句：你先努力，后果再说。这句话一出口，员工立刻开始保护自己。少贡献真实的业务上下文，少暴露真实的问题，少把自己的判断交给组织。

AI 转型最怕的不是员工不会用工具，是员工不再相信组织会公平处理 AI 带来的变化。

第 180 天：把临时做法变成正式规则

第 90 天认下来的那些卡点，靠开会认一次是不会自己消失的。复核标准说不清楚，下一个季度还是说不清楚；没人愿意签字的判断，换个人来一样没人签。所以 180 天要做的事只有一件：把 90 天逼出来的组织答案，从会议纪要挪进制度。

到了 180 天，衡量的东西要换一次。这时候的里程碑不再是系统运行了多少节点，是三件事。第一，负责这条流程的岗位职责说明书是否已经改写。AI 在哪些节点介入，人负责什么，如何复核，出了事谁处理，都必须写进职责。

第二，绩效口径是否已经更新。方向应该从“用了多少 AI、写了多少 prompt、调用了多少次工具”，转向“拿回了什么结果”：结果更稳定、产出更多、返工更少、经验更可复用。

第三，流程里积累的判断标准和处理经验，是否已经形成可调用的知识资产。它们不能只存在于个别员工的操作习惯里，也不能只躺在项目群文件里，而要进入组织记忆。

这三件事没做完，就别急着复制第二条流程。否则组织会同时跑两条没有制度接住的流程。复核标准、责任归属、绩效分配，这三摊混乱不会被分摊掉，只会叠起来。

180 天还有一个很现实的动作：把试点期的“临时做法”改成“正式规则”。

试点期里怎么干都行——某个骨干盯复核，某个项目经理盯日志，某个业务负责人盯异常，某个技术同学盯系统。但到了 180 天，这些动作要是还得靠人盯着，就说明制度化根本没完成。

正式规则至少写清楚五件事。谁定期看 AI 的输出质量。谁维护知识库。谁批准权限变化。谁处理异常升级。谁决定这条流程能不能复制到第二个团队。

第二条那个「谁」要是空着，知识库照样会建起来，也照样会旧下去——建成那天不是它开始起作用的那天，是它开始变旧的那天，除非有人被指定去养它。

这五条听起来像管理细节，实际决定 AI 能不能从试点走进日常。

很多公司试点成功、规模化失败，就是因为没有把这些临时动作固化。试点时大家都在场，上线后大家都回到自己的岗位；系统还在，责任散了。这就是制度化失败。

制度化失败的账不是不结，是延后到一个更贵的时点一次性结。前面那家企业的知识库就是这么荒的：第一遍是项目预算里的活，第二遍是被一号位追着补的。而且要靠一号位下命令才能让知识库重新更新，说明缺的从来不是执行力，是机制——命令能解决这一次，解决不了下一次。

第一年的指标：第二条流程有没有更快

第一年还要看一个信号：第二条流程有没有跑得更快。如果第一条流程花了 90 天，第二条流程还是花 90 天，先别急着判组织没学会。两条流程的难度、数据准备、风险和验收标准相近吗？如果可比，再追问哪些经验被复用了；如果第二条流程用了不到一半的时间，也要确认不是少做了复核、放低了标准。

这个指标比“AI 覆盖多少流程”更重要。覆盖数量容易做，复制速度难做。复制速度背后，是组织有没有积累方法：选切口的方法、三张账的模板、复核责任表、知识库治理方式、异常升级机制，有没有被复用？

如果这些东西都要重新讨论，说明组织没有学习；如果可以拿来就用，再按场景微调，说明组织能力开始长出来。AI 转型真正的规模化，不是同时开十个项目，是第十个项目比第一个项目更容易跑通。

180 天那三件事管的是制度有没有落地，第一年这两件事管的是能力有没有长出来——它们不是两套竞争标准，是同一条路上的两个刻度。所以第一年结束的真正里程碑，不是 AI 覆盖了多少人、多少流程，是另外两件。

第一，第一条流程攒下的判断标准、复核规则、典型错误案例，有没有整理成能检索的知识资产，让第二条流程上线时直接引用。第二，从第一条流程到第二条流程，从启动到跑通的时间有没有明显缩短。

时间缩短，加上质量守住、经验确实被复用，才是组织学会了的证据。没缩短，则要查是新场景更难，还是旧经验没有进入新流程。别把一张工期表当成学习能力的判决书。

一个人处理过某类问题，这叫个人记忆。要变成组织记忆，回到第九章检查：经验是否经过核验、按权限进入流程，规则更新后是否真的被下一次调用。存成文档，只是其中一步。

AI 进入流程以后，组织记忆建设的需求不减反增。通用模型可以升级，但它不会替企业保存每一次取舍的来龙去脉。知识没有积累，下一条流程就可能重新付一遍解释和纠错的成本。

复制的是能力，不是工具

这个指标听起来抽象，落到具体项目上其实很好认。举两个形态不同的例子。它们不是同一个项目的两个阶段，是两种不同的复制方向。

第一个是最常见的横向复制。给一家企业做 A 部门的知识库治理，口径、分类、更新责任、权限规则一条条梳理清楚，中间少不了争执——分类到底按业务线还是按文档类型，过期内容谁有权删，检索不到的时候走人工还是走上级。这些问题在 A 部门都吵完了。等 B 部门提出同样的需求，真正需要重做的只有一件事：权限要隔离，两个部门的内容不能互相看见。

除此之外，分类怎么定、谁负责更新、过期内容怎么处理、检索不到的时候走什么流程——B 部门迁移过去，再按自己的业务做一些改善就可以用。

这就是第二条流程更快的真实样子。它不是因为工具更熟练了，是因为那些需要讨论和拍板的东西，已经有了一版可以拿来改的答案。第一条流程最贵的成本不在系统，在争执；争执一旦有了结论，结论就是资产。

第二个例子更有意思，因为它复制的方向是向外的。

我做过一个制造企业的维修知识 RAG。最初的需求很内部：维修人员到客户现场服务，需要快速拿到答案。难点不在技术，在知识体量——整套装备很大，涉及大量配件说明书，还有图片和视频讲解。

人的记忆是有上限的。型号一多，即便按不同机型分配专门的服务人员，前线维修人员还是经常要呼叫总部支援。这件事的本质不是维修人员不专业，是没有人能把一整套多型号装备的处理经验都装进脑子里。RAG 不是让人变成百科全书，是让人在需要的时刻拿到需要的答案。

所以第一步做的是把内部维修知识拉通，让维修人员在前线能直接检索，不用每次都往回问。

这一步做好以后，一个新的可能性自己冒出来了。系统既然已经能回答“这个型号的这个部件出现这种症状该怎么处理”，那里头总有一部分问题足够简单、足够标准。这些问题，为什么不直接开放给客户自己查？

于是同一套能力，从内部支持外溢成了客户侧的自助排查助手。

这两个例子说的是同一件事。第一个流程跑通以后，真正有价值的产物不是“这条流程更快了”，是组织多了一块可以搬走的能力。

所以第一年该盘点的不是上了几个 AI 场景，是有几块能力已经具备了被搬走的条件。就问三句：它的口径写清楚了吗？它的责任人定下来了吗？换一个部门用，改的是配置，还是得从头再吵一遍？

复制一个工具很容易，买一份授权就行。复制一套能力才是组织在长本事。

CEO 必须说清产能分配

还有一件事，CEO 不能躲：产能释放以后，到底怎么分配？这不是 CHO 一个部门能决定的，也不是业务负责人自己能决定的，因为它会影响组织信任。

员工要是觉得 AI 一提效、组织立刻就裁人，他不会把真实的业务上下文交出来。他要是觉得自己把经验喂给组织的 AI，换来的只是自己更容易被替换掉，他就会开始留一手——留判断，留经验，留异常，留真实反馈。

员工一旦开始留，AI 就只能学到表层。

表层很快，也很脆。

所以产能分配不是财务问题，是组织契约问题。CEO 必须说清楚哪些场景为了降本，哪些为了增产，哪些为了提质，哪些为了重组。说清楚不代表永远不调整，是让员工知道组织要往哪里去。

AI 转型最怕偷偷摸摸。越偷偷摸摸，员工越会把它理解成组织偷袭。

四类推进角色必须到位

这条路线的治理层里，四类推进角色必须到位。它不是第十九章六类责任图的删减版：业务 owner 仍对具体流程结果负责，治理负责人仍负责规则、权限、审计和例外；下面四类只负责把 90 天试点推进起来。

CEO 负责三个决策节点：第一个切口是哪条流程；第 90 天复盘时选择停、调整、扩大还是复制；产能分配方向是降本、增产、提质还是重组。这三个决定不能下放给 IT 或供应商。

CHO 负责三个制度接口：岗位职责更新、绩效口径调整、AI 影响流程的动态清单。CHO 如果只做培训，不做制度接口，员工会在新工作方式里没有规则、没有保障、没有方向。

CIO 负责三个技术接口：运维接得住、数据治理规则清楚、权限地图持续维护。CIO 如果只关注系统上线，不关注这些接口，风险会随着 AI 系统增加而积累。

AI 转型负责人负责推进和连接：推进三账测量，推进试点启动和复盘，推进 CEO、CHO、CIO 在正确时间做出正确决定。他不是协调员，是组织翻译和闭环负责人。

老板真正需要的路线图

前面这几套东西——三张账、四类活、第 90 天的四个结论、180 天的三件制度化、第一年的两个刻度——不需要读者背下来。把它们摊平在一张表上，老板每个阶段该问什么、该留下什么、什么信号说明跑偏了，一眼能看完。老板真正需要的，不是一张“AI 项目进度表”，是这样一张能在会上拍板的表。

日期是建议节奏，不是自动升级许可。未取得相应证据，就调整、暂缓或停止；原制度已经适用，不必为交差而改制度。这张表的价值不在于显得管理规范，在于它逼着老板每个阶段都问结果。没有结果，就别接着讲愿景。AI 转型最怕的从来不是慢，是忙了半年，最后只留下一份项目进度。

这周就可以做一件事：找出公司里那条已经有人在用 AI、却没有明确复核责任人的流程，约上它的业务负责人谈一次。

谈的东西就五样：谁在复核，怎么记录，出了问题找谁，哪张账会变，90 天后拿什么验收。

这不是启动新项目，也不用申请新预算，只是把一条已经在跑的流程的责任归属，从口头挪到文件上。谈完这一次，你才知道自己的组织现在站在路线图的哪一格。

要是 90 天后你还说不出哪条流程缩短了、谁在复核、哪张账变了，这不是 AI 的问题，是你没给 AI 一个真实的组织切口。

AI 转型不看路线图写得漂不漂亮，看组织有没有真的学会接住它。没有真实流程，AI 没有落点。没有责任人，流程没有主人。没有流程损耗三账，试点没法验收。没有复盘和制度化，90 天就只是一个项目周期。

路线图真正的价值，是让组织在每一个阶段都清楚自己要留下什么能力。没有能力沉淀，所有进度都是幻觉。老板要看的从来不是热闹，是能力。