数据闭环产品化 checklist

一、这份 checklist 解决什么

很多团队的闭环”能跑”：脚本跑得通、Demo 说得圆、指标也好看。但一旦要对外交付，就会暴露一连串问题——换一批数据就失效、换个人就跑不动、出问题说不清是谁的锅、客户问一句”上次为什么判错”就答不上来。

能跑通是工程问题，能交付是产品问题。 本 checklist 用于自检：一条闭环从”能跑”到”能交付”到底还差什么。

用法建议：逐组勾选，任一组的必选项未通过，即不具备对外交付条件。

---

二、数据资产

• 数据来源已登记：来源、口径、更新频率、责任人
• 数据质量规则已定义：缺失、重复、越界、过期的自动检出
• 敏感信息已分级，脱敏在采集侧完成（必选）
• 数据集有版本号，任一次运行可回溯到确定快照（必选）
• 数据分布有基线，漂移可监测
• 数据权限已配置：谁能看、谁能导出、导出留痕

验收口径：给定一次历史运行，能在限定时间内还原出当时用的完整数据快照。

---

三、链路契约

• 每个环节的输入、输出格式已定义，且为机器可读格式
• 环节之间的版本已锚定：数据版本、规则版本、模型版本（必选）
• 规则（标注规则 / 评测口径 / 业务规则）与代码分离，可独立变更与回滚
• 规则变更可灰度、可回滚，变更有评审记录
• 新增环节的接入成本可估算，不依赖个人经验

验收口径：改一条规则后，能说清哪些历史结论受影响，且可在必要时回滚到旧口径重算。

---

四、护栏与门禁

• 每道关键交接点都有自动校验，不靠人工肉眼（必选）
• 校验按风险分级：低风险抽检放行，中风险审核放行，高风险人工签字
• 拦截动作已定义：阻断 / 降级 / 转人工
• 关键场景有不设例外的硬门禁（必选）
• 误拦率有监测，误拦过高时会触发门禁复评
• 豁免有留痕：谁批准、理由、影响范围、失效时间（必选）

验收口径：人为注入一个已知错误，能被预定门禁在预定位置拦截，且拦截记录可查询。

---

五、可观测

• 全链路日志：输入、模型版本、检索依据、校验结果、审核人（必选）
• 指标体系上线：通过率、拦截率、人工干预率、漂移
• 有运行看板，异常可告警到人
• 任意一次输出可在 5 分钟内还原完整链路（必选）
• 指标口径唯一，不存在两套算法算同一个指标

验收口径：客户随机抽一条历史结果，团队能在约定时间内给出完整还原说明。

---

六、责任闭环

• 高风险环节的人工审核覆盖率为 100%（必选）
• 审核台留痕：谁审、依据哪版规则、改了什么
• 责任主体明确：出问题时有唯一可追责的人，而不是”模型的问题”
• 拦截记录与人工修改已结构化存储，并定期复盘（必选）
• 人工干预率随轮次下降的趋势可量化

验收口径：拿出最近一个季度的复盘记录，能说明干预率下降来自哪些具体改动。

---

七、交付与运维

• 有交付文档：部署方式、依赖清单、配置项说明
• 有运维手册：常见故障、处置步骤、升级路径
• 部署可重复：换环境能重跑，不依赖某台机器上的手工操作（必选）
• 有明确的适用边界说明：什么场景适用、什么场景不适用
• 有前置条件清单：客户侧需提供的数据、专家、环境
• 有验收方案：交付后按什么指标验收，周期多长

验收口径：新人按文档独立完成一次部署与验收，无需原作者在场。

---

八、商业化

• 能力可复用：第二个场景接入周期显著短于第一个（必选）
• 独特性已说明：为什么客户不能直接用通用模型自己做
• 成本结构清晰：算力、人力审核、运维各占多少，随量如何变化
• 有分层交付形态：咨询 / 共建 / 平台，对应不同成熟度客户

验收口径：能说清”AI 能力普及之后，我们的数据闭环与信任闭环为什么仍然值钱”。

---

九、怎么判定可以对外交付

七组里，必选项全部通过，且满足下面三条，即可判定具备交付条件：

1. 可复现：同一输入重跑，结论一致
2. 可追溯：任意结论可在限定时间内还原全链路
3. 可复制：新场景接入不需要从零试错

三条里缺一条，交付出去的就是一个会持续产生售后成本的项目，而不是产品。

判断一个应用能否放量，标准不是 Demo 有多惊艳，而是闭环转了多少圈。