AI项目推不动?问题不在技术,在治理

我以前总觉得，AI项目推不动，是因为甲方太保守。

直到有一次跟一个甲方业务负责人吃饭，他说："你那个AI准确率99%我信。但我管的这条业务线，一年营收十几个亿。真出一次错，损失可能就是几百万。你让我为了那1%的效率提升，担100%的后果风险，我不敢。"

我当时就愣住了。原来不是甲方保守，是我站在技术视角只看"AI能做什么"，人家站在业务视角看的是"出了事我要扛什么"。

从那之后我就明白了：AI项目的核心矛盾，早就不是"AI够不够聪明"，而是"信任够不够扎实"。

这是今天做AI项目的普遍困境——技术上跑得通，业务上不敢用。模型准确率95%，业务负责人不敢签字；Agent功能全跑通了，权限只敢开到"查询级"；演示的时候惊艳全场，真要上线了，人人都往后缩。

但你以为"不敢用"是最大的问题吗？

不是。

更大的问题藏在后面——你好不容易说服业务方用起来了，结果发现人变了。

质检员不复审了，反正AI大部分时候是对的；业务员开始绕着AI走，专挑AI识别不准的场景下手；出了问题，业务方说"是AI判的"，技术方说"人确认过的"，两边甩锅；本来人会主动思考、主动发现问题，有了AI之后，人变成了AI的"执行手"，脑子不动了。

你看，"不敢用"只是第一层困境。真正的深坑在第二层——用起来了，但人和AI的协作方式不对，系统反而更脆弱了。

上一篇我们聊了"AI工具引入三关过滤器"——帮你判断一个工具该不该引、引到什么程度。那是入口。

但如果工具过了三关、进入了深水区，接下来怎么办？

当AI从"辅助工具"变成"能自己做决定"的时候，你怎么管？怎么既让业务方敢用，又避免人的行为跑偏？

这就是今天要聊的——AI深水区的项目治理。

这是"AI时代项目经理能力重构"系列的第三篇。三篇连起来，就是一条完整的路径：

第一篇：个人层面——越用AI越忙怎么办？（AI垃圾活效应）
第二篇：项目层面——AI工具该不该引？（三关过滤器）
第三篇：深水区——AI能自己做决定了，怎么管？（人机协作治理）

从入口到深水区，一整套项目级的AI治理框架。

治理的核心：从"管AI"到"管人机关联"

很多人一听到"AI治理"，就觉得是技术团队的事——模型安全、数据安全、权限控制……这些当然重要，但它们只是治理的一部分。

真正的AI项目治理，管的不是AI，是人和AI的关系。

为什么这么说？因为AI项目的风险，从来不是单一维度的。它至少有三层：

• 技术风险：AI本身出错了——识别错了、生成错了、理解错了。这一层靠技术团队解决。
• 交互风险：AI没出错，但人用错了——人过度依赖AI、人绕过AI的约束、人用AI做了不该做的事。
• 组织风险：人和AI都没出错，但系统出问题了——责任不清、流程不顺、激励错位，导致整个系统的效率反而下降了。

大多数团队，把90%的精力花在了第一层——技术风险上。但真实项目里，出大事的往往是第二层和第三层。

就像那个经典的AI质检场景：

• 技术风险：AI的漏检率是多少？——技术团队在管。
• 交互风险：质检员会不会因为有了AI就不复审了？——没人管。
• 组织风险：出了漏检，算AI的还是算人的？——没人说得清。

你看，后两层的风险，技术团队管不了，安全机制也管不了。这是项目经理的活。

所以AI深水区的治理，核心不是"把AI管得更严"，而是**"把人和AI一起工作的规则设计好"。**

很多人以为治理是"限制AI"，会让业务方更不敢用。其实刚好相反——边界越清楚，业务方反而越敢用。因为他知道什么情况AI会停、什么情况人兜底、出了事谁担责。未知的风险才让人怕，写清楚的风险反而不可怕。

这就是为什么我说，AI时代的项目经理，正在从"流程管理者"变成"人机协作规则设计者"。

一个核心工具：AI自主决策约束书2.0

设计规则，不能靠拍脑袋，也不能靠开几次会就定了。得有一个结构化的工具，把所有关键问题都过一遍。

这个工具就是AI自主决策约束书2.0。

你可以把它理解为AI项目的"交通规则手册"——什么能做、什么不能做、拿不准的时候找谁、出了事谁担责，全部写在纸上，各方签字确认。

它不是法律，没有强制效力。它的约束力，来自各方对"把规则说清楚对大家都好"的共识。

它也不是技术文档，它的读者是项目经理、甲方业务负责人、安全合规负责人——所有跟这个AI项目利益相关的人。

约束书2.0的核心框架是六章，这里我重点讲每一章解决的是什么问题：

为什么是业务负责人兜底？因为AI最终服务的是业务目标，业务负责人对业务结果负责，也就必须对AI的使用边界有最终签字权。技术团队提供能力，但不替业务做风险决策。

六章从目标到边界到权限到迭代到博弈到责任，一条线穿下来。每一章都是一个必答题，你不回答，项目运行起来它也会以"问题"的方式冒出来。不如提前想清楚，写在纸上。

想深入了解每一章的具体要素、必答问题和填写模板，可以看前面已发布的AI自主决策约束书相关文章。

四套配套机制

这就像汽车和交通的关系。

一辆车再安全——有气囊、有ABS、有碰撞五星评级——你也不能让它随便开。你得有交通规则：什么路限速多少、什么灯能走、出了事故谁的责任。车的安全是技术问题，路上的安全是规则问题。

AI项目也是一样。模型再准、算法再强，也不能没有治理规则。AI的准确率是"车的安全"，人机协作的规则是"交通规则"。前者管的是AI本身出不出错，后者管的是人和AI一起工作时系统出不出错。

如果说约束书是**"规则手册"——所有规则都写在里面，那这四套机制就是"规则落地的四个抓手"**：

• 分级授权机制：是"权限怎么放"的抓手
• 迭代重审机制：是"规则怎么更新"的抓手
• 行为审计机制：是"规则怎么监督"的抓手
• 熔断回滚机制：是"出事了怎么止损"的抓手

一个载体，四个抓手，合起来就是完整的AI深水区治理体系。

分级授权：不是"能不能"，是"从哪一级开始"

很多项目上AI，一上来就问"能不能全自动运行"。这是个错误的问题。

正确的问题是：我们从哪一级开始？

我常用的是"人机协同五级"模型，不是二元开关，是梯度授权：

• H1 纯人工 → H2 AI辅助 → H3 AI建议+人确认 → H4 人机共决双签 → H5 AI主导+事后审计

AI拿不准就找人，人拿不准就往上推。每升一级，都要有数据支撑、有业务方主动确认。

收边界可以快，放边界必须慢。

我见过的团队里，80%都卡在H3升不到H4/H5——不是技术不行，是业务方觉得还不到时候。这很正常，也应该是这样。

迭代重审：能力在增长，边界就得跟着重画

这是AI项目跟传统项目最大的不同。

传统软件上线就基本定了，AI系统上线才是动态调整的开始。能力在增长，边界就得跟着重画。

迭代重审是"双轨制"：

• AI侧：每次模型迭代，边界都要重审。小版本技术自审，中版本四方评审，大版本约束书全面修订。
• 人侧：定期复盘人的行为变化——复核通过率有没有异常？有没有人反复提交相似数据？决策模式有没有变？

只看AI的数据是发现不了问题的。必须把人的行为和AI的决策放在一起比对。

行为审计：你假设人会博弈，才不会真的博弈

很多人觉得，"行为审计"就是监控员工，不太光彩。

但你换个角度想：你提前把审计规则说清楚，反而能减少博弈。

因为大家知道"这么做会被发现"，就不会去做了。审计的最大作用，不是事后抓坏人，是事前减少博弈的动机。

常用的手段就三个：异常检测、交叉验证、定期抽检。

举个具体的例子：AI审批系统上线后，你发现有个业务员提交的单子，AI通过率特别高，人工复核也很少打回来。一查才发现，他专挑AI识别最稳的那类客户往系统里塞，把模糊的、难判的全都走人工通道——等于AI成了他的"绿色通道"，人工成了他的"垃圾桶"。

这种问题，光看AI的准确率数据是发现不了的，必须把人的行为数据和AI的决策数据放在一起比对。

这也是为什么行为博弈审查是约束书里的独立一章——博弈无处不在，不是某一个环节的事，是每一条规则设计时都要考虑的事。

好的治理不是假设人都是好人，而是假设人都会趋利避害，然后把规则设计成「趋利避害的结果，刚好就是系统想要的结果」。

这不是不信任人，这是规则的一部分。就像路上有摄像头，不是为了罚你，是为了让大家都守规矩。

熔断回滚：出事了能及时踩刹车

再完善的规则，也会有意外。关键是出了意外能不能及时止损。

熔断机制至少要有三层：

• 输入层熔断：敏感操作（删除/导出/绕过）直接拦截
• 运行层熔断：连续失败N次、置信度低于阈值、操作超出权限……触发暂停，转人工
• 后果层熔断：已经造成损失了，能不能快速回滚？数据能不能恢复？

三层熔断，一层比一层靠后。越靠前的熔断，损失越小；越靠后的熔断，代价越大。

很多项目只做了第一层，甚至一层都没做。真出事了，只能眼睁睁看着损失扩大，然后整体下线。

三个真实案例：一正一反一进阶

说了这么多框架，你可能会问：这些东西在真实项目里能用吗？

我挑了3个最有代表性的案例。有的来自我自己的项目，有的来自行业公开报道，有的来自我跟同行的交流。细节做了脱敏处理，但核心逻辑都是真实的。

这三个案例不是随便堆的，刚好对应治理的三个阶段：

• 反面案例：不做治理的代价是什么
• 正面案例：好的治理长什么样
• 进阶案例：治理怎么跟着能力一起长

你可以对照一下，你的项目现在在哪个阶段。

案例一：反面——星巴克AI库存系统，边界没划清上线就翻车

验证的机制：决策边界 + 熔断机制

2025年9月，星巴克在北美超过11000家门店开始推广AI库存清点系统，用平板摄像头和激光雷达自动清点糖浆、牛奶等物料。官方说能把数小时的盘点工时压缩到数分钟。

结果呢？上线9个月后，系统被叫停了。AI分不清燕麦奶和牛奶，经常漏统计物品，库存数据严重不准，门店员工怨声载道。

为什么翻车？表面看是模型准确率的问题，根子上是边界放得太大——默认AI可以"全量自主清点"，没有置信度阈值，没有分级试点，没有熔断机制。

如果他们上线前有一份《AI自主决策约束书》，明确了AI的决策边界和熔断机制，这次翻车完全可以避免。能力还在L1，就给了L3的权限。跳级的代价，就是上线即翻车。

类似的反面案例还有很多：某头部金融平台Agent误删生产配置，根因就是权限给多了，Agent能直接操作基础设施；某零售企业AI定价系统上线后价格乱跳，因为没有熔断机制，出了问题只能整体下线。

这些事故的共同特点：不是AI技术不行，是治理没跟上。

（注：星巴克AI库存系统事件据路透社2026年5月报道，上线9个月后因频繁出错被叫停。）

案例二：正面——华为HiAI + 亚马逊AI仲裁，按"决策性质"划边界

验证的机制：决策边界划分维度

很多人划边界，是按"功能模块"划的——这个模块AI管，那个模块人管。但更成熟的团队，是按"决策性质"划的。

华为HiAI系统：项目决策权根据实时数据在人类管理者与AI系统之间动态流转——"数据在哪一边，决策权就倾向哪一边"。

亚马逊AI仲裁系统：能处理83%的团队冲突，仅在冲突涉及价值观判断时才移交人类管理层。

你看，划边界的维度不止一种。

按"功能模块"划是初级玩法——简单直接，但容易僵化。按"决策性质"划是进阶玩法——事实判断交给AI，价值判断留给人。边界跟着决策的性质走，而不是跟着功能模块走。

这也是为什么我说治理是"设计人机协作规则"，而不是"给AI画圈圈"。画圈圈是一维的，设计规则是多维的。

案例三：进阶——自动驾驶OTA监管，能力进化了边界就得重画

验证的机制：迭代重审机制

如果说前面的汽车类比讲的是"治理体系长什么样"，那这个案例讲的就是"治理体系怎么跟着能力一起长"。

以前的汽车，出厂时什么样，报废时基本什么样。安全认证做一次就行。但智能汽车不一样，OTA一升级，辅助驾驶的能力就变了。

问题就来了：一次升级，要不要重新做安全认证？

现在行业的共识是：能力进化了，安全就得重新审。而且不是一次审完就完事，是每次大版本升级都要审。监管方还在探索"分级认证"——小迭代走快速通道，大迭代走完整认证。

这个案例最有意思的地方在于：它告诉我们，治理不是写完就锁起来的文件，是跟着能力一起长的活体系。

AI系统的能力在持续增长，安全边界就得持续重画。这不是凭空想出来的，是自动驾驶行业用血淋淋的事故验证过的。

一句话收束：AI的价值不在"它能做多少"，而在"它能在多大的边界内可靠地做"。边界越清楚，能放开的范围就越大。这就是治理的价值。

怎么落地？从"三级跳"开始

说了这么多框架和机制，你可能会问：听起来挺好，但真到项目里，怎么落地？

我的建议是：别一上来搞大而全的治理体系，从"三级跳"开始。你可以把它理解为五级模型的"简化落地版"——实习生对应H1-H2，参谋对应H3，专家对应H4-H5。

第一级，AI实习生，查询类，零风险。只能查数据、查信息、解释指标，不做任何判断，不给任何建议。目标是让业务方先习惯"有问题问AI"，建立基本信任。

第二级，AI参谋，建议类，低风险。可以分析数据、识别问题、给出建议，但只给建议，不直接执行。目标是验证AI的建议质量，让业务方觉得"这东西还挺靠谱"。

第三级，AI专家，执行类，中高风险。可以在授权范围内自主决策、自动执行，配熔断机制、审计机制、回滚机制。目标是在可控范围内释放AI的最大价值。

跟三级跳对应的，是治理体系的版本演进路径：

• v0.1 试点版——只写红色禁区和L1权限，跑两周再填。不用追求完整，能把"什么绝对不能碰"说清楚就行。
• v0.5 推广版——L2跑通了，黄色观察区补满，绿色自主区选1-2个低风险场景试点开放。
• v1.0 稳定版——三级权限全部跑通，四套机制正式运转，四方签字确认。

之后每次模型迭代、发现新博弈场景、业务目标调整，都升小版本号。

版本号不是形式主义，是治理体系"活"起来的证据。每升一次版，就意味着项目各方对AI的边界又对齐了一次。

如果治理不是你说了算，怎么办？

我知道很多项目经理会说："你说的都对，但治理不是我定的——甲方说怎么弄就怎么弄，技术团队想怎么干就怎么干，我能怎么办？"

确实，现实中大多数项目经理没有最终决策权。但治理体系不只是一个"决策工具"，它还是一个**"沟通工具"和"风险管理工具"**。

即使治理方案不是你拍板，你也可以用它做两件事：

第一，做"向上管理"——把风险显性化。

甲方说"AI要全面上线、全自动运行"，你不用硬扛。你可以说："好的，我来评估一下全面上线的边界和风险。目前这几个场景属于红色禁区，必须人工确认；这几个场景可以放绿色自主区，但需要配套熔断机制。我们先从H3开始跑，跑稳了再升级？"

你不是在反对，你是在把甲方的"政治正确"翻译成"可执行的方案"。

第二，做"局部优化"——在你能说了算的范围内用。

就算整体方案不是你定的，你至少可以在你的团队内部执行分级授权——哪些环节可以用AI、哪些只能辅助、哪些绝对不能依赖AI。

你改变不了全局，但你可以改变你能控制的那部分。而很多时候，局部的规则设计，反而能决定整个系统的实际运行效果。

所以，AI治理不只是给"有决策权的项目经理"准备的。只要你在项目里承担责任，你就需要它——哪怕只是用来保护自己。

最后说几句

做项目管理这么多年，我越来越相信一个道理：

好的规则不是束缚，是信任的基础设施。边界越清楚，中间的灵活度越大。

对AI是这样，对人是这样，对人和AI一起工作的混合系统，更是这样。

我们这一代项目经理，赶上了一个很有意思的时代。以前管的是人和流程，现在还要管AI和人机协作。以前的工具是WBS、甘特图、风险矩阵，现在还要加一样东西——人机协作的治理体系。

它不是什么高大上的新概念，就是一个朴素的想法：在让AI干活之前，先把规矩说好。

如果你今天就想试试，不用搞什么完整的治理体系，也不用等v0.1。找一张A4纸，写下你这个项目里AI绝对不能碰的三件事，拿给甲方业务负责人过目、签字。就这一步，就比90%的AI项目强。

也许再过两年，"AI项目治理"会跟"项目章程"一样，成为每个AI项目的标配。到那时候回头看，我们今天的讨论，就是这个工具最早的雏形。

本文是"AI时代项目经理能力重构"系列的第三篇。

第一篇《AI垃圾活效应》：个人层面为什么越用AI越忙，以及怎么用三关过滤器过滤垃圾活。

第二篇《AI工具引入三关过滤器》：把三关过滤器迁移到项目级，帮你判断一个工具该不该引、引到什么程度。

第三篇就是今天这篇：当AI进入深水区、能自己做决定的时候，怎么用治理体系来管理人机协作的规则。

三篇连起来，就是一个完整的路径：从个人怎么用AI，到项目怎么引AI，再到AI进入深水区怎么管。从入口到深水区，一整套项目级的AI治理框架。

如果你想深入了解约束书的完整框架和使用细节，可以看我前面发布过的AI自主决策约束书相关内容。那里有六章的详细拆解、每一章的操作要点，以及更多真实案例。