检查一、二：场景与工具
先看场景是否有真实使用人、历史样本与明确的不做清单，再看工具清单与最小权限矩阵是否成文。两项都过不了，说明项目还没到选型阶段；此时买任何平台都只是把问题往后推，越早停下来越省钱，这也是最容易被忽略的边界。
检查三、四：确认与评测
写操作是否有二次确认、回滚与责任人；样本集是否覆盖典型任务与边界情况，成功率与接管率怎么算。为什么这两项要一起看？因为评测缺少回滚兜底时，团队会下意识地只挑简单任务来测，指标随即失真。
检查五、六：接管与审计
接管入口、接管人与响应时限是否明确并演练过；轨迹日志是否记录输入、工具调用、返回结果与人工确认点，留存多久。日志不全的系统无法复盘，也无法在出现争议时界定责任，等于没有证据，边界也就无从谈起。
检查七、八：条款与运维
合同中数据使用范围、日志归属、故障响应与知识产权是否写清；上线后谁负责更新提示词与知识、按什么节奏复盘。最后两项最容易被跳过，却决定系统半年以后还能不能用，也决定交接是否顺利，这属于合同边界问题。
适用与不适用
适合谁
- 正在做供应商比选与立项评审的项目组
- 准备把试点转为正式上线的业务部门
- 需要给管理层一份可核对清单的负责人
不适合谁
- 只想快速采购一套现成系统的团队
- 还没确定使用人与业务场景的项目
典型场景
某集团的数字化部门把这八项做成评审表，对三家供应商方案逐项打分。结果发现两家报价最低的方案都在日志审计与接管机制上留空，评审组要求补充方案后再比价，最终选择范围更小但八项齐全的一家，试点周期反而更短。
可执行步骤
- 先把八项检查做成一页评审表，每一项都写明可核对的通过标准与证据形式
- 要求供应商为每一项提供可核对的书面证据，而不是只在会上口头说明或指认他人
- 要求对写操作确认、回滚预案与人工接管流程各做一次现场演示，并当场提问
- 从历史任务中抽取小样本做回放，核对成功率与接管率的计算口径是否一致
- 把未通过的检查项逐条列入整改清单，并约定复评时间、复评人与不合格的处理方式
常见坑
- 把八项检查当成交付清单，只在验收时看一次，过程中无人跟进，问题全堆到最后才爆发。
- 供应商用口头承诺补齐缺项，合同里却不写对应条款，上线后出问题根本无法追责与索赔。
- 只测正常流程，不测异常与超时，接管机制直到上线才第一次被真正使用，等于没有验证。
- 日志只存最终结果、不存中间调用，出现争议时说不清究竟是哪一步出的错，责任无法落地。
自检与验收清单
- 八项检查是否都留下了可供第三方复核的书面证据
- 写操作是否都有确认环节、回滚预案与责任人
- 评测样本是否覆盖典型任务以及明显的边界情况
- 接管机制是否演练过，演练记录是否完整留档
- 合同条款与上线后的运维责任是否都落到具体的人
常见问题
八项要一次全过吗？
不必，但场景与工具权限两项必须先过。其余六项可以在试点中补齐，前提是补齐前不接写接口、不扩大到核心业务，否则风险会在系统最脆弱的时候被放大，也让评审失去意义。
小项目也要走八项吗？
可以按比例简化：日志与接管不能省，条款可以借用已有采购合同模板。省掉评测与接管看似加快上线，实际会让后续维护成本成倍增加，也会让团队对系统逐渐失去信心。
谁来组织这次评审？
由业务负责人组织，技术、采购、法务与安全各出一人，用半天时间逐项过。只让技术团队评审，容易漏掉数据使用范围与故障响应这些跨部门条款，也难在会上形成可执行的结论。