Demo 活了，组织为什么死了
Demo 之后最危险的一秒
最危险的一刻，不是 Demo 翻车。
是 Demo 很顺。
屏幕上输出正常，老板点头，团队松一口气。演示的人讲完最后一句，会议室里会出现一种很微妙的放松：你看，AI 能做这件事。
我现在反而会在这一秒警惕。
因为很多公司的误判，就是从这一秒开始的。
Demo 活了。
组织还没活。
Demo 能跑，只说明一段技术链路在一个被控制过的场景里暂时连起来了。输入被准备好了，问题被缩小了，边界被提前收住了，演示路径也被设计过。
这当然有价值。
但它还没有回答另一些更硬的问题：明天谁每天用？谁复核输出？什么叫成功？出错谁升级？规则谁维护？经验写回哪里？三个月后它还在不在真实流程里？
老板如果只看见 Demo 成功，很容易以为公司已经进入 AI 改造。
其实只是会议室里出现了一个好看的瞬间。
组织改造从来不是一个瞬间。它是一套新的工作方式进入旧流程，和旧责任、旧 KPI、旧知识库、旧审批习惯打架。
打赢了，才叫组织能力。
没打，就只是一个被全公司围观过的功能。
技术链路短暂成立
Demo 的边界要说清楚。
Demo 证明的是：输入可以进去，模型可以处理，输出可以展示。
这叫技术链路短暂成立。
它不证明业务流程已经改变。
它不证明员工愿意使用。
它不证明一线主管知道怎么验收。
它不证明法务、财务、运营、销售这些角色知道自己在新流程里的位置。
更不证明这个能力可以被复制、被审计、被维护、被新人接手。
很多 AI 项目最容易混淆的，就是“功能能跑”和“组织能跑”。
功能能跑，是工程问题。
组织能跑，是管理问题。
工程问题问：接口通不通，延迟高不高，成本能不能接受，效果能不能达到测试集。
管理问题问：它放进哪一步，改变谁的动作，谁来复核，错了谁改机制，哪些知识要沉淀，哪些权限要收住。
这两组问题都重要，但不是一组问题。
如果公司只用工程问题验收 AI 项目，最后得到的常常是一个能演示、能截图、能写周报、但进不了日常经营的系统。
它不是没用。
它是还没有被组织接住。
POC 死在组织链路
很多 POC 不是死在模型上。
它死在组织链路上。
我看过一些 B2B AI 场景的复盘，反复出现的不是一个模型参数问题，而是五个组织问题。
场景不真。
会议室里选的是最顺的样例，真实现场里遇到的是脏数据、例外需求、客户临时变更、上游资料缺失。
数据不稳。
试点时有人手工整理输入，上线后没人持续维护数据，AI 输出自然开始漂。
责任不明。
业务说这是技术项目，技术说这是业务需求，最后一线员工变成事实上的兜底人。
验收不清。
大家都说“效果还不错”，但没人能说清楚到底是速度变快了，错误变少了，返工变少了，收入变多了，还是风险降低了。
上线后无人维护。
POC 时有人盯，汇报时有人讲，上线后规则变了、流程变了、员工绕开了系统，却没人负责更新。
所以一句话要钉住：
技术链路能跑，不代表组织链路能跑。
POC 真正要验证的，不只是 AI 能不能做某个动作，而是这个动作能不能进入组织的日常运行。
如果不能，它就不是组织能力。
它只是一次技术展示。
真实流程负责人
第一道门，是有没有真实流程负责人。
没有负责人，AI 项目就没有家。
这里的负责人，不是提需求的人。
提需求的人可能只是觉得某个环节慢、某类材料多、某个岗位忙。他能描述痛点，但不一定为流程结果负责。
真正的流程负责人，是上线以后每天要对这个流程结果负责的人。
比如一个合同审核 AI，如果上线后合同风险漏了、业务审批慢了、法务复核堆了，谁要面对后果？是法务负责人、销售负责人、风控负责人，还是某个项目 PM？
说不清，就不要急着扩大试点。
因为 AI 一旦进入流程，就会改变权力和责任。
它会改变谁先看到信息，谁先做判断，谁有资格修改输出，谁能让流程继续往下走。
这些东西如果不在上线前讲清楚，后面一定会用人情、习惯和甩锅来补。
很多 Demo 之所以最后变成展示品，不是因为技术太弱，而是因为组织里没有一个人愿意把它接回自己的流程。
一个没有负责人的 AI 项目，最常见的命运是：大家都觉得有用，但没人真正负责让它有用。
这就是死局。
验收指标
第二道门，是验收指标。
AI 项目最怕一句话：
效果还不错。
这句话听起来友好，实际很危险。
不错在哪里？
速度快了多少？错误少了多少？返工少了多少？客户等待少了多少？一线少查了多少资料？主管少做了多少重复复核？风险暴露提前了多少？
如果答不上来，POC 就永远可以被解释成“还行”。
“还行”不是经营语言。
老板需要的是经营语言：时间、质量、错误率、返工率、收入、成本、风险、满意度。
技术团队可以用准确率、召回率、延迟、成本评估系统。
但业务验收必须回到业务指标。
一个 AI 客服项目不能只说回答像不像人，要看升级工单有没有减少、首响有没有变快、错误承诺有没有下降。
一个 AI 投放辅助项目不能只说建议看起来专业，要看异常发现是否提前、复盘是否更完整、下一轮规则是否真的被更新。
验收指标不是为了给项目找麻烦。
它是为了防止一个项目永远停在“大家感觉不错”的状态里。
感觉不错，不能进预算。
指标变了，才有资格谈组织能力。
复核与责任
第三道门，是复核与责任。
人在回路中，不是让人点一下确认。
点确认太便宜了。
真正的回路，要分清五个角色：使用人、复核人、验收人、裁决人、维护人。
使用人把 AI 放进日常动作里。
复核人检查 AI 输出有没有越界。
验收人判断这个能力是否改变业务结果。
裁决人在例外和冲突出现时拍板。
维护人负责规则、知识、权限和提示词持续更新。
如果这些角色没有拆开，所谓人在回路中，最后会变成一种很糟糕的安排：AI 做输出，基层员工签字，出了问题追基层。
这不是责任设计。
这是把风险往下倒。
老板要尤其警惕这种“完美单边赌局”：AI 输出带来效率，上级拿收益；AI 输出出错，一线背责任。
这种机制只会教员工抵抗 AI。
他们会绕开系统，会保留手工流程，会把 AI 当成额外负担，而不是新的生产方式。
所以复核与责任不是合规装饰。
它决定 AI 能不能被组织真用。
没有责任重写，AI 项目越成功，组织摩擦越大。
知识沉淀
第四道门，是知识沉淀。
一次异常如果只停在群聊里，组织下次还会再错一次。
这是很多 AI 项目的暗伤。
系统上线后，真实现场一定会出现例外：数据缺了，客户改口径了，上游信息不完整，规则冲突了，AI 给了一个看似合理但实际不能用的建议。
这些例外不是麻烦。
它们是组织学习的入口。
如果处理完就算了，经验只留在某个人脑子里、某个群聊里、某次会议纪要里，这个组织就没有长出记忆。
下一次新人接手，还是重新踩坑。
下一次 AI 调用，还是读不到这条判断。
下一次主管复盘，还是靠人回忆。
所以 Demo 要变成组织能力，必须回答一个问题：这次使用中产生的新规则、新例外、新判断，写回哪里？
知识库不是资料仓库。
它应该接住四类东西：规则、例外、判断、结果。
谁负责更新，也要写清楚。
没有知识维护人，知识库很快会变成文档坟场。旧内容没人删，新内容没人补，AI 读得越勤，错得越隐蔽。
组织记忆不是把文档堆起来。
组织记忆是让下一次判断站在上一次复盘之上。
上线后维护
第五道门，是上线后维护。
AI 项目上线不是结束。
是维护开始。
很多公司对 AI 项目的想象，还是软件交付思维：需求确认，开发测试，上线验收，然后项目结束。
但 AI 进入组织流程后，环境会一直变。
业务口径会变。
客户问题会变。
政策和权限会变。
员工也会变。他们会找到更省事的用法，也会找到绕开系统的办法。
如果没有维护节奏，系统会慢慢退化。
一开始大家觉得新鲜，愿意试。两个月后，规则过期，输出变慢，异常没人处理，员工发现手工更快，系统就变成摆设。
最后复盘时，大家会说：这个 AI 不好用。
其实不一定是 AI 不好用。
是组织没有安排它持续变好。
上线后维护至少包括四件事：看使用数据、处理异常、更新知识、调整责任。
谁每周看？谁决定改？谁通知业务？谁保留记录？
这些小问题不性感，但决定系统能不能活过三个月。
老板真正要问的，不是 Demo 当天炫不炫。
老板要问：三个月后，它还在不在流程里？
投放管理脱敏案例
我用一个脱敏场景说。
一个营销服务组织的投放管理人机协作系统。
投放管理不是一个人坐在那里调参数。
它牵动目标、预算、素材、账号、节奏、异常、客户反馈、复盘和下一轮策略。里面有大量信息整理，也有大量经验判断。
AI 当然可以帮忙。
它可以整理投放数据，可以初筛异常，可以生成复盘草稿，可以对比历史案例，可以提醒某类风险。
但真正难的，不是让 AI 给建议。
真正难的是把建议放进流程。
谁看这个建议？
谁改？
谁复核？
谁决定异常要不要升级？
谁把这次处理结果写回知识库，让下一轮不用重新靠人记？
如果这些问题不清楚，AI 就只是旁边多了一个输入框。
输入框再聪明，也不会自动变成组织能力。
这个场景有价值，是因为它逼着组织重新拆一条协作链：哪些动作让 AI 先做，哪些判断必须由人接，哪些异常必须升级，哪些经验必须沉淀，哪些输出必须留痕。
所以我不愿意把人机协作讲成“AI 替代某个岗位”。
太粗。
更准确的说法是：AI 进入之后，任务、判断、复核、知识和责任被重新分配。
这才是组织操作系统的变化。
老板 Demo 复盘清单
所以老板看 AI Demo，不要只问“准不准”“快不快”“酷不酷”。
要问十个更硬的问题。
| 模块 | 检查问题 | 判断口径 |
|---|---|---|
| 真实流程 | 接进哪条业务流程？ | 不能只写“提升效率”，必须写流程节点 |
| 流程 owner | 谁对流程结果负责？ | 不是提需求的人，而是上线后背结果的人 |
| 使用人 | 谁每天用？ | 具体岗位或角色，不写“业务团队” |
| 复核人 | 谁检查 AI 输出？ | 复核标准要写清 |
| 验收人 | 谁说它算成功？ | 必须业务侧承认 |
| 验收指标 | 改善什么指标？ | 速度、质量、错误率、返工、收入、风险至少选一项 |
| 异常升级 | 出错谁处理？ | 异常不能只甩给一线 |
| 规则维护 | 规则谁更新？ | 没有维护人，系统会退化 |
| 知识沉淀 | 经验写回哪里？ | 群聊不算组织记忆 |
| 三个月复盘 | 怎么判断还在流程里？ | 看真实使用、指标变化、例外处理、知识更新 |
这十个问题问完，大多数 Demo 会立刻降温。
这不是坏事。
降温，才有机会变成项目。
真正危险的是所有人都兴奋，所有人都点头，但没有一个人愿意把它接进自己的流程。
AI 上线之后，组织不会自动改变。
它只会暴露旧组织里原本就模糊的地方：谁负责、谁判断、谁复核、谁维护、谁承担后果。
这些地方不补，Demo 越漂亮，落地越痛苦。
所以 C02 的结论很简单：
Demo 活了，不代表组织活了。
AI 项目从演示走向能力，不靠掌声，靠流程、责任、指标、知识和维护。
老板不要问 Demo 炫不炫。
老板要问：这个东西三个月后还在不在流程里。
一个 Demo 过不了这张表，就不要假装它已经是组织能力。