企业 AI 落地最后一步：把经验变成标准件

项目能跑通一次，不算落地。把这次的经验，变成下次不用重新摸索的标准件，才是真正收口的那一步。

9-21 我们发了《没有责任矩阵，AI 项目迟早会乱》，9-22 发了《回退预案比模型参数更重要》——责任矩阵告诉你「出问题找谁」，回退预案告诉你「出错了往哪退」。这两样本身就是项目里最该留下的标准件。这篇补的是更前面一步：一个企业 AI 项目跑通之后，怎么把更多一次性的经验，也变成能带走、能复用的东西。

很多项目不是没做成，是换个人就做不成

经验如果只长在几个核心成员的脑子里，项目交付那天，能力也就跟着人走了。下次换个团队、换个场景，又要从头摸索一遍。

我们常在项目收尾评审上看到一种现象：试点报告写得很漂亮，KPI 也达标了，但只要牵头人一调走，同样的事再没人能原样做第二遍。

假设你在一家金融企业牵头做了一个信贷初审的 AI 辅助工具，试点跑通了，审批效率也确实上去了。三个月后你调去了别的条线，新人接手时面对的是一堆散落在聊天记录和会议纪要里的「当时为什么这么定」。他分不清哪条规则是监管红线、哪条只是当时图省事的权宜之计。

这说明什么——能跑通的试点，留下来的是一份「结果」；能复用的试点，留下的应该是一套「怎么跑通的判断口径」。后者，才是标准件。

我们以前也低估过这件事。一个跑了大半年的场景，关键判断全在某个人的微信里，他一休假，群里就开始互相问「上次那个边界是怎么定的」。等他回来，他自己也要翻半天。经验没变成标准件，就等于每次都要重新付一次「找人」的税。

标准件不是文档，是能直接拿来用的判断口径

所谓标准件，是把一次成功里那些「为什么这么定」的判断，固化成模板、清单、决策门和踩坑记录——让没参与过的人，也能照着做对。

它和写一份漂亮的项目总结不是一回事。总结是给人看的，标准件是给人用的。一份标准件至少要回答三件事：什么情况下该用、按什么步骤做、哪一步错了要停。

前面说的责任矩阵（谁在哪种情况下拍板）、回退预案（出错时退到哪、怎么退），其实就是两个已经成型的标准件。这篇要补的，是「怎么把更多经验也变成这种东西」的方法。

标准件也不一定要多厚。我们见过最有用的一份，其实就半页纸：三行判断口径、一张填空表、一条踩坑提醒。它不追求覆盖所有情况，只保证最常见的一次，新人不会做错方向。

一个能带走的标准件，至少含四样东西

我们复盘过的项目里，能复用下来的经验，几乎都拆成了四个最小单元。你可以把它当模板。

• 决策门：什么情况进、什么情况停。比如「涉及客户直接决策的环节，必须有人工复核节点」。
• 最小模板：照着填就能用的骨架。比如回退预案的六个字段（触发条件、回退目标、谁拍板、恢复条件、时限、复盘口径）。
• 踩坑清单：当初在哪一步栽过、为什么。把「当时图省事的那条」明确标成不要踩。
• 验收口径：怎么算做成了，拿什么指标说话。

缺了任何一样，这份经验下次用起来都会变形。模板给了步骤但没给决策门，新人不敢拍板；给了决策门没给踩坑清单，他还会把别人栽过的坑再栽一遍。

举个例子，一个常见的决策门是：凡涉及对外给客户的 AI 结论，必须保留一条人工复核链路，且复核人不能是生成结论的同一个人。这条不是写进制度里才有效，是变成标准件之后，新人第一天就能在清单上看到、照着卡。

标准件也不是越全越好。第一版能覆盖六成场景就够用了，剩下四成留给复用的人去补——他们补进去的东西，往往比一开始设想的更准。

最容易踩的坑：把总结当标准件

很多团队以为「写份复盘文档」就等于沉淀了经验，其实差得远——文档能被搜到，不代表能被照着做对。

一份标准件和一份复盘文档的分界，在于它有没有「执行动作」。复盘文档通常回答「发生了什么、我们学到了什么」；标准件回答「下次遇到同类情况，第一步点开哪张表、填什么、错了找谁」。前者是记忆，后者是能力。

我们常在复盘会后的归档动作里看到，文档写完就进了共享盘，半年没人打开——因为它没有 owner、没有触发条件，谁该在什么时候用根本说不清。

我们见过一份复盘写得极其详尽，事故时间线、根因分析、改进项一条不落，但半年后同类问题又发生了——因为没人知道那份文档该在「哪个新项目启动前」被打开。它不是标准件，是一份没人会主动去翻的档案。

标准件会过期：最难的是有人管、有人改

标准件会过期。业务口径、监管要求和模型能力都在变，一份半年前的判断口径，可能今天已经不对了。它得有 owner、有更新节奏，而不是写完归档就完事。

假设你在一家能源企业推知识库，去年定的「哪些文档能进库」的标准，今年因为数据分类新规要调整。如果没有人定期回头看，新人会一直按旧标准执行，风险是悄悄累积的——等审计发现，已经是另一个量级的问题。

这套「四样东西 + owner + 更新节奏」是我们团队在一线复盘里形成的实践框架，不是某个外部强制标准，样本也有限；不同组织的治理要求差异很大，具体字段要结合自身情况调整。

也别指望一次写到位。标准件的第一版通常是粗糙的，真正让它变准的，是后面几次复用里被人改出来的。所以更新的动作本身，比第一版的完整度更重要。

把小步快跑和沉淀分开，反而更快

有人担心「每做一次就要沉淀标准件，会不会拖慢节奏」。实际恰恰相反：不在成功时顺手固化，等失败或人员变动再来补，成本要高得多。

我们的做法是，在每个试点收尾时，强制留半小时把「这次能复用的三件事」记下来。它不是正式文档，就是一张能贴在下个项目起点的清单。等攒够几次，再合并成更完整的标准件。

落地不是把项目做完，是把做项目的能力留下来。

我们吃过反向的亏：有个项目收尾时没人愿意花那半小时，理由是「这周太忙了，下周补」。结果下周没有人记得当时纠结过哪几个边界，那份经验就这么散了。后来我们把「收尾留半小时」写进了试点 checklist，变成不填就不算结项。

你今天能做的一个最小动作

如果今天只能做一件事：

• 挑一个你刚跑通的项目，列出「换个人接手，他最可能需要知道的三条判断口径」。
• 把其中一条「当时为什么这么定」写下来，并标清它是监管红线还是权宜之计。
• 指定一个 owner，约定每半年回头看一次。

你会发现，一旦经验能被写下来、被交接，你对「这个人走了怎么办」的焦虑会小很多。

签名式自检

• 这个项目做完，换个人接手，能不能照着做对？
• 当时「为什么这么定」的判断，写下来了吗，还是只在几个人脑子里？
• 有没有一张清单，标清了「哪一步错了要停」？
• 这份经验，半年后还有人维护、有人更新吗？
• 你手上最该被固化成标准件的，是哪一件？

关于作者

参考资料

1. ISO/IEC 42001:2023《人工智能管理体系》要求组织建立 AI 风险与治理职责，并把风险控制落到可执行流程，可作为「经验与流程应纳入治理框架」的体系化佐证。https://www.iso.org/standard/81230.html
2. NIST《AI Risk Management Framework (AI RMF 1.0)》（NIST.AI.100-1，2023-01）把风险治理与可执行的缓减动作放在第一层，用于说明「决策门 + 验收口径」可对接通行的 AI 风险治理框架。https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
3. 欧盟《人工智能法案》（EU AI Act，Regulation (EU) 2024/1689）对高风险 AI 系统设风险缓减与人工监督义务，可作为「标准件中决策门与外部合规要求衔接」的旁证。https://eur-lex.europa.eu/eli/reg/2024/1689/oj
4. 文中「信贷初审 AI 辅助工具」「能源企业知识库」两节为假设场景，构造用于说明，非亲历项目，亦不指向任何具体客户。