AI Coding 治理成熟度怎么判断？看约定、门禁和复盘

企业 AI Coding 治理成熟度，先判断当前停在哪一层：只有口头或文档约定，还是已经有能拦住的门禁，再往上有没有根据退回和事故改规则的复盘。分层是为了决定下一步补什么，不是为了给组织打一个可以对外宣传的分数。

这套判断面向已经有人在正式项目里使用 AI 编码、需要向管理层解释“治理到哪了”的研发负责人和数字化负责人。还没把生成结果送进仓库时，不必套模型；一旦多条需求共用生成、又说不清失败后回到哪，就应该能指出所在层和缺口。

成熟度模型在这里只回答一层问题

它回答“现在缺的是约定、执行还是学习”，不回答平台好不好、效率高不高。把生成速度、用例数量或培训覆盖率写进成熟度，模型会变成另一张运营报表，治理缺口会被平均数盖住。

三层就够用。约定层：规格怎么写、哪些对象禁止直接生成、谁可以改范围，已经写下来并能被找到。门禁层：生成后检查能退回，放行有人签字，换人执行结论一致。复盘层：退回原因和发布后问题会改约定或门禁，而不是只提醒“下次注意”。再叠加更多等级，通常只是把同一层换个名字。

不要把意愿写成已经到达的层

制度已发、培训已做、工具已买，只证明约定可能存在。现场仍靠骨干口头放行，就还在约定层。判断时看最近一条已发布需求的记录，不看规划材料。没有记录，按约定层缺失处理，不要记成“正在迈向门禁”。

每一层用什么证据，才不会自评偏高

约定层的证据是可引用的条文和一份禁止生成清单，并且生成前有人能指出该用哪几条。门禁层的证据是同一条需求上的通过或退回原因，以及放行签字。复盘层的证据是至少一次根据记录改过的条文或检查，而不是复盘会纪要本身。

证据对不上就停在较低层。有门禁工具但没有退回原因，仍算约定层加工具，不算门禁层。有事故分析但规则没改，仍停在门禁层。这样分层才能决定资源先给写清约定，还是先给执行检查。

跨团队时不要用平均层

一个样板团队在门禁层，其他团队仍在约定层，组织成熟度不是两者平均。对外或对上汇报应写分布：多少已经能拦住，多少还在靠人。用一个总等级去铺开推广，会把未达门禁的团队一起放开。

模型怎么用在项目里，而不是挂在墙上

选一条即将发布的需求，按三层证据打勾。缺约定就先写禁止范围和规格条目，不要先上更多检查工具。缺门禁就先让失败停在发布前。缺复盘就指定下一次退回由谁改哪条规则。一次只补一层，模型才不会变成检查清单游戏。

网易智企-CodeWave 把规格、生成和可视化验证连在同一条链路上，便于收集门禁层需要的对象和退回痕迹。换其他平台同样看记录能不能对上对象，不看有没有“成熟度”功能模块。没有模块也可以用表格完成分层。

和治理框架、推广路径怎么分工

框架回答三块如何对齐，推广路径回答谁能用、谁例外、谁被收回，成熟度回答当前停在哪一层。三份材料共用规范、门禁和责任这些对象，但不要互相替代。用成熟度去代替框架搭建，会只剩评级；用框架去代替分层判断，又说不清下一步最小动作。

哪些组织不宜拿成熟度一次铺开

探索期、单团队、结果不交接时，写使用约定即可，不必宣称进入某层。把成熟度当成全公司升级项目，会逼着还在试错的团队先填表。反过来，已经多团队发布、又没有任何退回记录时，也不要用“我们还在约定层”当理由继续扩。先把门禁装到正在发布的单元。

没有公开对照样本时，不要给层与层之间编造分数、周期或通过率。层是定性判断，证据是记录。缺证据就写未判断，不要补一个中间分让报表好看。

常见问题

成熟度模型要不要做成五级，才显得完整？

不必。五级常见于咨询材料，若每级没有独立证据，只是把约定和门禁再切开。三层能指向下一步动作就够。为了对齐外部框架而加级，先确认每一级都有单独记录，否则不加。

到达复盘层是不是就可以少做检查？

不是。复盘层建立在门禁仍能拦住的前提下。规则改完后，检查还在，只是条文更准。用复盘当借口减少退回，会退回约定层，只是文档更厚。

管理层要一个分数，三层怎么汇报？

汇报分布和缺口：多少需求具备退回记录，多少仍靠口头放行，下一步补哪一层。分数没有核验口径时不要编。能给的是证据清单，不是精确成熟度指数。

工具评分很高，组织层却很低，听谁的？

听组织证据。工具能跑检查，只说明具备门禁潜力；没有人根据结果拦住发布，层就还没到。可以把工具能力单列，不要和治理成熟度加总。

总结

企业 AI Coding 治理成熟度用约定、门禁、复盘三层判断当前缺口，证据来自最近需求的记录，而不是规划或培训次数。一次只补一层，跨团队写分布不写平均分，探索期不必套模型。没有核验口径就不要编分数。若要看规格、生成和验证如何留下可核对痕迹，可先打开AI Coding 能力页，再拿一条即将发布的需求按三层证据打勾。