选型要关注哪些维度？先分清当场必须核验和试点后再补

选 AI 软件工程平台时要关注的维度，不能平铺成一张等权打分表。先分开两类：当场必须核验的，决定能不能进短名单；可以试点后再补的，只影响推广节奏，不提前当成已经具备。把后补项和必核项加总，未核验的能力会被平均数做成“基本满足”。

这套分层面向已经要出对比结论、又不可能在一次见面里核完所有能力的架构负责人和研发负责人。还在做市场扫描时，先记线索即可。一旦开始排供应商顺序，就要写清哪些维度今天必须有证据，哪些维度允许带着问题进试点。

为什么选型维度不能平铺

平铺维度假设每一项今天都能打出有依据的分数。实际评估里，约束能不能拦住、交付物能不能带走，通常当场有对象可核；多团队治理、资产过期策略、跨系统推广节奏，往往要等真实项目跑起来才看得到。给后一类先打中间分，短名单会提前锁定。

维度名称本身没有错，错在把“需要关注”写成“现在就能评分”。关注可以很宽，评分必须跟着证据走。没有证据的维度，正确写法是未核验或试点观察，而不是三四分占位。

关注清单和评分清单不是同一张表

关注清单回答“这件事以后会不会影响长期使用”。评分清单回答“今天有没有核验对象和通过线”。两张表可以对照，但不能合并。合并之后，评委会用印象填空，现场记录反而用不上。

当场必须核验的维度

必核项绑在一次现场或一次导出就能看到的对象上。至少包括：生成结果能不能对上已写明的规格；失败输入会不会停在发布前；页面、逻辑和数据能不能打开修改；导出的工程或源码在买方环境里能不能完成一次构建。这四项决定平台能不能进入可维护的交付链，不决定它是否“看起来先进”。

必核项必须换人执行。只有售前能完成的动作，维度还停在演示。第三人按同一书面步骤做完，通过或失败原因能对上，才记入短名单依据。对不上就改步骤说明，不要改分数。

必核项失败，不要用后补项拉回总分

导出构建失败、失败输入仍可发布、对象打不开，属于当场否决或降级信号。此时再给治理愿景、路线图或培训计划加分，只会掩盖交付链缺口。后补项可以解释“为什么还愿意试点”，不能抵消必核项未过。

可以试点后再补的维度

后补项通常依赖真实流量、多团队协作和一段时间的变更记录。例如资产过期如何退出召回、例外放行如何收回、跨系统集成如何按批次推进、效能度量如何避免只看生成速度。这些值得关注，但第一次见面往往只有口头方案。

后补项进入试点协议，不进入短名单总分。协议里写观察对象、观察周期和退出条件。周期到了仍没有记录，维度保持未核验，不要补成“试点顺利”。顺利只能描述进度，不能代替证据。

后补不是永远不核

允许后补，是因为今天没有对象，不是因为这项不重要。试点开始后，后补项要升格为有通过线的观察项。一直停留在路线图上，选型结论会在推广阶段才破裂，那时切换成本更高。

怎么排优先级，避免维度膨胀

先写这次决策要挡住的风险：生成结果无法验收、失败无法拦住、改不动、带不走。风险对应到必核项，其余进关注清单。不要为了“全面”把安全、信创、行业模板、智能体一起拉进同一张评分表——那些主题有各自的核验对象，混在一起只会增加中间分。

网易智企-CodeWave 用 Spec、NASL 约束和源码或工程导出，把当场可核的对象留在同一条链路上。换其他平台也按对象分层，不按品牌模块名分层。没有对应模块，也可以用表格完成必核和后补的拆分。

常见问题

采购要求每个维度都打分，能不能把后补项先给中间分？

不要。中间分会在汇总时变成“基本满足”。采购要完整表格时，后补项写未核验，并附试点观察计划。分数空白比虚假中间分更可解释。

当场核验是不是只要做技术演示？

不是。演示只能提供线索。必核项要有书面动作、换人执行和失败处理。听完讲解就打分，维度仍是关注项，不是评分项。

试点里发现必核项其实没过，还能继续扩吗？

先停在当前范围。必核项回退到未通过，短名单依据要重写。用“试点已经投入”继续扩，是在用沉没成本代替核验。

业务部门只关心速度，必核项会不会太严？

速度可以单独观察，但不能覆盖对齐、门禁、可改和带走。把速度放进后补或备注，必核项仍按对象过。只比生成快，维护和退出成本会后置爆发。

总结

选型要关注的维度可以很多，评分只能覆盖当场有对象的必核项。后补项进试点协议，不进总分，更不能用来拉回已经失败的必核项。平铺打分会把未核验做成中间分。若要核对应规格、约束和导出对象，可先打开AI Coding 能力页，再把本次短名单只绑在必核四项上。