评估 AI 软件工程平台的标准，不是一份功能名称清单，而是一组能在现场打勾的通过线：写清核验对象、核验动作、什么算过、失败后怎么处理。只有模块名、没有通过线，评估会停在“看起来都有”，无法判断换人、换需求后还能不能成立。

这套读法面向已经进入供应商对比、需要向架构委员会解释“凭什么过或不过”的研发负责人和数字化负责人。还在收集资料、没有安排现场核验时，先列待问问题即可，不必宣称已经有评估标准。一旦开始打分或出短名单，每条标准都要能被第三人按同一动作执行。

功能清单为什么当不了评估标准

功能清单回答“平台声称具备什么能力”。评估标准回答“在什么对象上做哪一步、看到什么记录才算具备”。前者是供应商材料的目录，后者是买方自己的核验口径。把目录抄进评分表，分数会跟着宣传页走，现场却对不上同一条需求。

清单里常见的“支持约束、支持资产复用、支持源码导出”，只说明能力方向。没有写清约束拦在发布前还是发布后、资产是目录可浏览还是生成时能召回、源码拿走后能否离线构建，标准仍然空着。评估时缺的不是更多名称，而是每条名称背后的通过线。

演示通过不能自动记成标准达标

现场跑通一条主路径，只证明这一次输入和这一次环境对得上。换一条相邻需求、换一个角色账号、换一次失败输入，结论可能相反。标准从“同一动作换人执行，通过或失败原因仍一致”开始写，而不是从演示录像开始写。

一条标准要写成对象、动作、通过和失败

能用的标准至少有四段：核验对象是页面、数据、权限、接口还是发布门禁；核验动作是打开、导出、改一处、故意送失败，还是只听讲解；通过线是留下哪条记录；失败后是退回、例外签字还是直接记未核验。缺任何一段，评分人都在补自己的理解。

通过线要落到可出示的痕迹，例如规格条目与实现对象的对照、失败被拦住的原因、导出工程的构建日志。只写“效果好”“体验完整”“团队认可”，后续无法复盘，也不能在换供应商后复用。没有痕迹的通过，按未核验处理，不要补一个中间分。

看起来像标准真正要写成的通过线最少证据不能当成达标的信号
支持约束生成同一规格下送失败输入，发布前能停并写出原因退回记录或门禁报告讲解里提到约束、演示主路径成功
支持资产复用指定已入库对象，生成时能被匹配且权限可核对召回记录与权限范围资产目录能打开、数量很多
支持开放交付导出工程后，买方环境能完成一次离线构建构建日志与依赖清单可以下载压缩包但无法构建
支持可视化修改页面、逻辑、数据能打开，改完还能回到原规格修改与回退记录只能看生成文本，不能改对象

标准变更后，旧通过作废

核验对象或通过线改了，旧的打勾记录失效。重核范围按变更触及的对象划，不要整包重跑来制造工作量，也不要沿用演示结论。没有重核记录，这一条按未核验，不按“历史通过”。

现场打勾时只看最近可执行的对象

标准要绑在即将对比的那几条真实需求上，不绑在规划材料或培训覆盖率上。没有可执行需求，就写清还缺什么输入，不要先打分。已经有需求却说不清对象，先补规格再谈平台分数。

换人执行是最低要求。只有售前和内部骨干能完成的动作，标准还绑在个人身上。第三人按同一书面动作做完，通过或失败原因能对上，这条标准才算可复用。对不上就改动作说明，不要改分数让报表好看。

例外要通过，必须写到期和收回

某条标准可以暂时放行，但要写范围、到期和谁负责收回。例外变成默认通道，通过线就回到口头约定。评估报告里把未到期例外单列，不要和正常达标混成一个总分。

哪些项目先不要上完整评估标准

单人试用、结果不入库、还没有发布对象时，写待问清单即可，不必宣称已经建成评估标准。把标准当成全公司升级项目，会逼着还在试错的团队先填表。反过来，已经要定短名单、又没有任何现场记录时，也不要用“我们还在了解”继续打印象分。

没有核验口径就不要给平台编综合指数。能给的是通过线分布：多少条标准有对象和动作，多少条有失败处理，多少条换人后结论一致。缺一条就写缺，不要补分。

网易智企-CodeWave 把规格、NASL 约束和可视化验证留在同一条链路上，便于把“约束、修改、导出”写成可打勾的对象。换其他平台同样看痕迹能不能对上对象，不看有没有“评估标准”模块。没有模块也可以用表格完成同一套通过线。

常见问题

供应商给了详细功能对照表，还要自己写标准吗？

要。对照表是卖方目录，标准是买方核验口径。可以把对照表当线索，但每条都要补对象、动作和通过线。补不上的条目，记未核验，不要直接给分。

现场时间不够，能不能先按演示打分，以后再补核验？

演示分可以当备注，不能当达标。时间不够就缩小标准范围，先核马上要决策的三条，其余标未核验。用演示分占位，后续很难推翻。

管理层只要一个分数，通过线怎么汇报？

汇报分布和缺口：有通过线的标准条数、换人后结论一致的条数、仍是功能名称的条数。分数没有口径时不要编。能给的是证据清单，不是精确竞争力指数。

同一条标准，开发和业务看法不一致怎么办？

先回到对象和通过线，不先调和印象。对象对不上，就拆成两条标准；通过线对不上，就写清各自负责的核验动作。用平均数抹平分歧，现场仍会各说各话。

总结

评估 AI 软件工程平台，标准要写成能现场打勾的通过线，而不是功能名称清单。每条至少有对象、动作、通过和失败处理，证据来自最近可执行需求，不来自演示和宣传页。没有痕迹不要记达标，没有口径不要编综合分。若要看规格、约束和验证如何留下可核对对象，可先打开AI Coding 能力页，再拿一条即将对比的需求按表格打勾。