项目证据标准：如何证明项目完成
严格区分 Demo、试点、上线、采用、结果和移交，并为五层项目证据建立状态、门禁和脱敏规则。
本章目录
阅读边界： 本章明确区分官方事实、本站工作框架与待案例验证判断。本站框架不是行业认证或合规标准。
1. 项目完成不是一句状态，而是一组可检验的声明
“项目已经完成”通常混合了至少六种不同声明：
- 我们做出了一个可演示的能力。
- 我们在限定范围内完成了真实试点。
- 系统已经进入生产环境。
- 目标用户正在持续使用。
- 原问题的业务指标已经改变。
- 接收团队已经能独立运行和迭代。
这些声明可以先后发生，也可能只发生其中一部分。为了避免把演示写成试点、把上线写成采用、把使用量写成业务结果，本章先区分四个基本对象。
1.1 声明、材料、证据与验收门
| 对象 | 定义 | 例子 |
|---|---|---|
| 声明 / Claim | 项目团队希望别人相信的可检验陈述 | “系统已上线并满足约定质量门槛” |
| 材料 / Artifact | 项目过程中留下的文件、日志、数据或记录 | Eval 报告、发布单、仪表盘、会议纪要 |
| 证据 / Evidence | 能与具体声明、范围、时间、版本和责任人对应的材料 | 指向版本 v1.3、覆盖 4 周真实流量的 SLO 报告 |
| 验收门 / Acceptance gate | 在看到结果前约定的通过、条件通过、暂停或停止规则 | 严重越权失败必须为 0，其他指标达到项目约定阈值 |
一个文件不会因为名字叫“验收报告”就自动成为证据。只有当它能说明支持什么声明、来自哪里、覆盖什么范围、由谁复核、是否仍在有效期内，它才具有可审查性。
1.2 一条最小证据记录必须包含什么
每条证据至少记录：
evidence_id：稳定编号claim_supported：支持哪一条声明artifact_type：访谈、决策记录、测试结果、运行日志、指标快照、确认记录等scope：用户、流程、地区、数据、模型、版本和环境边界source_system：材料来自哪个系统或责任方time_window：产生时间和覆盖窗口owner：材料的维护责任人reviewer：完成回读或事实确认的人method：如何采集、计算或评分status：当前证据状态sensitivity：公开、脱敏、受控、内部或限制级location：可回读的存储位置；必要时记录版本、哈希或不可变快照limitations：已知缺口、偏差、冲突和不适用范围
证据记录不得保存明文密码、API Key、访问 Token、个人敏感信息或未修复漏洞的可利用细节。它应指向受权限保护的原始材料，而不是把秘密复制进证据卡。
2. 本站框架的属性与官方证据边界
本章借鉴风险管理、评测、安全和可靠性工程材料，但不把它们拼成一个不存在的“FDE 官方标准”。
2.1 NIST：可以组织证据，不能冒充认证
NIST AI RMF 1.0 是自愿使用的 AI 风险管理框架。其 Core 使用 Govern / Map / Measure / Manage 四个函数组织治理、场景理解、测量和风险处置。[S1][S2]
NIST AI RMF Playbook 为这些函数提供建议动作。Playbook 明确说明，它不是检查清单，也不是穷尽所有行动的清单；组织应按自身资源和环境选择使用。[S3]
因此，本站可以借用以下组织逻辑：
- 用
Map支持问题、场景、影响与约束证据； - 用
Measure支持 Eval、测试、阈值与持续监控证据； - 用
Manage支持风险处置、事件、停止与恢复证据； - 用
Govern支持责任、政策、文档、监督与移交证据。
但完成本站证据卡不等于“通过 NIST”，也不构成任何 NIST 合规、认证或认可。
NIST AI 600-1 GenAI Profile 是 AI RMF 的生成式 AI 配套参考，同样是自愿使用、跨行业的风险管理资源。它强调预部署测试、持续评估、领域专家参与、事件与反馈记录，以及把安全和韧性阈值放在单纯优化能力之前。[S4]
2.2 ISO/IEC：管理体系和风险指南不是本站项目证书
ISO/IEC 42001:2023 是面向组织的 AI 管理体系标准，公开资料强调建立、实施、维护和持续改进 AI 管理体系。ISO/IEC 23894:2023 提供 AI 风险管理指南。[S5][S6]
这些材料可以提醒项目团队保留职责、风险、监控、审查与改进证据，但本站的单项目证据卡：
- 不是 ISO/IEC 42001 管理体系审核；
- 不能证明一个组织符合 ISO/IEC 42001；
- 不能替代认证机构、监管方、法务、安全或审计部门的正式判断；
- 不能把“参考过 ISO”写成“已获 ISO 认证”。
2.3 厂商工程文档：是方法来源，不是普遍认证标准
OpenAI 的 Eval 文档强调先定义目标，再构造数据集、指标、比较实验和持续评测；Agent 文档进一步用 trace、grader 和工作流级评测观察工具调用、决策路径与最终结果。[S7][S8]
Anthropic 的 Agent Eval 指南强调：Eval 应针对具体任务，明确成功和失败边界，组合确定性检查、模型评分和人工评分，并同时检查环境中的最终结果、Agent 轨迹和评测 harness。它也明确区分开发期 Eval 与长期生产监控。[S9][S10]
这些是高价值工程方法，但仍需按具体业务、风险和系统环境校准。使用某个厂商的 Eval API 或 grader，不等于项目质量已被独立认证。
2.4 OWASP 与 MCP：用于建立威胁和权限证据，不是安全证书
OWASP GenAI/LLM Top 10 提供提示注入、敏感信息泄露、供应链、输出处理、过度代理等风险分类，可用于形成失败模式和安全测试。[S11]
MCP 官方安全建议特别强调：
- 使用最小权限和渐进授权；
- 验证 Token 的 audience，防止凭证被错误用于其他服务；
- 禁止 token passthrough，不把客户端 Token 原样转发给下游；
- 对敏感工具调用保留清晰的人类确认；
- 正确实现 OAuth、scope、会话和重定向校验。[S12][S13]
这些要求应进入方案门、质量门和运行门。一次“安全评审完成”的会议纪要，不能代替权限测试、Token 边界、审计日志和真实攻击场景验证。
3. 两套维度必须分开：证据层、证据等级与证据状态
本站同时使用三种不同概念，不能混写。
3.1 五层项目证据回答“证明项目的哪个部分”
- 问题证据
- 方案证据
- 质量证据
- 运行证据
- 结果与移交证据
3.2 E0-E4 内容证据等级回答“公开结论有多强”
| 等级 | 含义 | 可支持的公开表达 |
|---|---|---|
| E0 | 只有观点或假设 | 讨论题、待验证判断 |
| E1 | 有官方材料、论文、法规或规范 | 定义、原则、外部事实 |
| E2 | 有项目过程材料 | 项目记录、试点复盘、方法案例 |
| E3 | 有基线、结果、观察窗口和口径 | 结果案例、采用或业务变化声明 |
| E4 | E1-E3 齐备，且项目参与者完成事实确认 | 可复核案例和同行评审材料 |
五层证据齐全不自动等于 E4。比如，五层都由供应商单方自报、无法回读原始材料，仍可能达不到 E4。反过来，一条 NIST 官方原则可以是 E1，但它不能证明某个具体项目已经上线。
3.3 证据状态回答“这一条材料现在可靠吗”
| 状态 | 定义 | 使用规则 |
|---|---|---|
Missing |
应有但不存在 | 必需项为 Missing 时，相关阶段不得通过 |
Planned |
已定义采集方法、责任人和时间，但尚未产生 | 只能证明团队知道要收集，不能证明结果 |
Observed |
已看到材料或现象，但尚未回读来源、方法或责任人 | 可用于调查，不足以独立验收 |
Verified |
已核对来源、范围、时间、版本、方法和验收条件，并由适当角色确认 | 可用于阶段验收；仍受有效期与适用范围限制 |
Contested |
存在冲突数据、不同解释或责任方异议 | 必须保留争议，不能挑选对项目有利的一条 |
Not publishable |
材料存在且可在授权范围内评审，但因隐私、商业秘密、安全或合同不能公开 | 可以内部验收，不能公开展示原始内容 |
Not publishable 是公开属性，不是低质量状态。一个内部可完整回读的生产日志，可以同时是 Verified + Not publishable。
Verified 也不是永久状态。模型、数据、流程、权限或生产版本改变后，旧证据必须重新确认适用范围；超出有效窗口时，应降回 Observed 或标记为不再适用，不能继续沿用旧结论。
4. Demo、试点、上线、采用、结果与移交不能混用
| 阶段声明 | 最小含义 | 至少需要的证据 | 不能用什么代替 |
|---|---|---|---|
| Demo / 演示 | 在受控输入、受控操作者和受控环境中展示某项能力 | 方案范围、演示样本、已知失败、版本记录 | 一段顺利录屏不能证明真实流程可用 |
| Pilot / 试点 | 在限定用户、真实或近真实数据、明确时间窗内验证关键假设 | 问题、方案、质量三层基本 Verified；限定运行数据至少 Observed | 内部测试、一次客户演示、没有退出条件的“试运行” |
| Launch / 上线 | 特定版本进入生产环境，具备真实身份、权限、监控、回滚和运行责任 | 质量门通过；生产发布、权限、监控、回滚、值守证据 Verified | 域名可访问、接口返回 200、部署到一台服务器 |
| Adoption / 采用 | 目标用户在正常工作流中持续完成真实任务 | 用户分母、目标任务、重复使用、留存/覆盖、人工绕行与反馈 | 注册数、访问量、培训签到、少量种子用户试用 |
| Outcome / 结果 | 原问题的指标相对基线发生可测变化 | 同口径前后数据、观察窗口、样本量、成本与风险、归因限制 | “业务反馈很好”、模型准确率、使用量上涨 |
| Transfer / 移交 | 接收团队已接受责任，并能独立运行、评测、恢复和修改 | 责任确认、权限移交、运行/Eval 资产、培训、演练与未结风险 | 发一份文档、开一次培训会、把代码仓库链接发给客户 |
4.1 推荐的阶段声明句式
不要写：
项目已成功落地。
改写为：
版本
v1.3已于 2026-07-01 面向两个业务组上线；截至 2026-07-19，生产门已通过，采用证据仍在四周观察期内，尚不主张业务结果或完成移交。
阶段声明必须同时给出版本、范围、时间和未完成部分。越精确，越不需要营销形容词。
5. 第一层：问题证据
5.1 这一层要证明什么
问题证据证明的不是“AI 很重要”，而是某个具体用户在某个真实流程中存在值得处理的成本、延迟、错误、风险或机会，并且有人有权决定是否继续项目。
NIST AI RMF 的 Map 函数要求建立场景、目的、范围、利益相关者、影响和风险边界；这为问题证据提供了外部参考，但本站字段是项目工作设计，不是 NIST 检查表。[S2][S3]
5.2 必填字段
| 字段 | 要回答的问题 |
|---|---|
| 目标用户与角色 | 谁实际完成任务，谁受结果影响？ |
| 触发时刻与流程 | 任务何时开始，输入、判断、动作和结束状态是什么？ |
| 当前基线 | 时间、错误、成本、数量、风险或体验当前是多少？ |
| 数据口径 | 分母、时间窗、来源系统、缺失值和计算方法是什么？ |
| 损失或机会 | 不改变会发生什么，改变后可能产生什么价值？ |
| 现有替代方案 | 人工、规则、传统软件或外包目前如何处理？ |
| 项目目的与禁区 | 系统被允许做什么，明确不做什么？ |
| Sponsor、Owner、验收人 | 谁提供资源、谁日常负责、谁有权接受结果？ |
| 受影响方与风险责任人 | 谁可能受益、受损、承担投诉或监管责任？ |
| 成功、暂停与停止条件 | 什么证据出现时继续、修改或停止？ |
5.3 建议材料
- 现场访谈与参与者确认记录
- 当前流程图、任务样本和异常路径
- 来源系统的基线查询、报表或抽样记录
- 项目责任声明与 RACI
- 受影响方、风险和约束登记表
- 无 AI / 规则 / 采购现成产品等替代方案基线
5.4 状态与验收门
问题层只有在以下条件同时成立时才可标为 Verified：
- 至少一名真实用户或流程 Owner 回读了流程描述；
- 基线有来源、分母、时间窗和计算方法；
- Sponsor、Owner 与验收权限明确；
- 项目目的、禁区和停止条件已记录；
- 关键争议没有被隐藏；无法量化的部分说明了替代证据和限制。
问题门通过条件： 团队能够用一页纸解释“为谁、在哪个流程、改变什么、当前多少、谁决定、何时停止”。否则项目只能进入探索，不能进入正式方案验收。
5.5 反例
- 只有领导一句“做一个企业知识 Agent”。
- 用行业市场规模代替本企业流程基线。
- 访谈了管理者，却没有接触真实操作用户。
- 只记录平均耗时，不记录任务量、长尾和失败后果。
- 项目目标写“提升智能化水平”，没有可观察变化。
- 先做完 Demo，再倒推一个与现有能力相配的需求。
6. 第二层：方案证据
6.1 这一层要证明什么
方案证据证明团队在真实约束下做出了可解释、可追踪、可撤销的技术与运营选择，而不是因为“现在流行 Agent”就直接堆叠模型、工具和框架。
6.2 必填字段
| 字段 | 要回答的问题 |
|---|---|
| 方案目标与边界 | 方案解决问题链中的哪一段，不解决哪一段？ |
| 备选方案 | Agent、确定性工作流、RAG、规则、人工、采购产品如何比较？ |
| 决策记录 | 为什么选择当前方案，谁批准，何时需要重评？ |
| 架构与数据流 | 数据从哪里来，经过什么组件，到哪里落地？ |
| 模型、工具与依赖版本 | 使用什么模型、库、协议、外部服务和构建产物？ |
| 数据与知识边界 | 数据所有者、允许用途、更新、删除、留存和质量限制是什么？ |
| 身份与权限 | 用户、Agent、Tool 和服务各自拥有什么权限？ |
| 自主级别与人工确认 | 哪些动作可自动执行，哪些必须预览、确认或双人复核？ |
| 安全与威胁模型 | 提示注入、数据泄露、越权、供应链和失败恢复如何处理？ |
| 假设、风险与依赖 | 哪些条件尚未验证，失败时影响什么？ |
| 降级、回滚与退出 | 模型不可用、输出不可靠、成本超限时如何退回安全状态？ |
| 可复用与定制边界 | 哪些进入产品，哪些只属于当前客户环境？ |
6.3 MCP 相关权限证据
涉及 MCP 或其他工具协议时，方案证据至少应说明：
- 每个 Tool 所需最小 scope，不申请与当前任务无关的能力；
- Token 的签发方、audience、接收服务和有效期；
- 服务端是否拒绝 audience 不匹配的 Token；
- 是否禁止 token passthrough，并为下游服务单独取得适当凭证；
- 敏感操作前用户看到什么信息、确认什么对象和影响范围；
- 重定向、会话、动态客户端注册和第三方授权如何校验；
- 哪些日志可审计，哪些凭证和敏感字段禁止记录。
6.4 状态与验收门
方案层可标为 Verified，至少需要：
- 当前架构、数据流、权限和外部依赖与实际实现一致；
- 至少一个合理替代方案被比较，而不是只写最终选择；
- 关键假设、威胁、人工确认和停止条件有责任人；
- Agent 的自主性由任务需要和风险证明，能用确定性流程的部分没有被无理由 Agent 化；
- MCP/Tool 凭证满足最小权限、audience 校验和禁止 token passthrough；
- 敏感动作存在可测试的人类确认或组织批准机制；
- 回滚、降级和安全失败状态不是上线前临时补写。
方案门通过条件： 评审者能从问题证据追踪到每个关键设计选择，并知道失败时系统如何停止、降级或回滚。
6.5 反例
- 架构图只有模型、向量库和 Agent 框，没有真实系统、身份与数据边界。
- “使用 MCP”被当作权限安全已经解决。
- 把用户 Token 原样转发给下游服务，没有 audience 校验。
- Tool 默认拥有全库写权限，只依赖提示词要求“谨慎操作”。
- 用自动确认按钮或模糊文案绕过敏感操作的人类决定。
- 没有记录替代方案，无法解释为何不用规则或普通软件。
- 供应商、模型和库版本变化后，仍引用旧架构评审结论。
7. 第三层：质量证据
7.1 这一层要证明什么
质量证据证明特定版本在代表性任务上达到预先约定的可接受边界，并且失败类型、安全风险、评分偏差和已知限制可见。
它不是一张“准确率 90%”截图。Agent 的结果具有非确定性，可能在同一任务上走不同路径；评测必须同时考虑任务定义、最终环境状态、轨迹、grader 与 harness。[S7][S8][S9]
7.2 必填字段
| 字段 | 要回答的问题 |
|---|---|
| 任务定义 | 一次 Eval 的起点、允许动作和成功结束状态是什么？ |
| 成功与失败边界 | 什么算成功，哪些失败是严重、一般或可接受？ |
| 测试集来源 | 黄金样本、历史任务、真实流量、合成和对抗样本各占多少？ |
| 样本范围与版本 | 覆盖哪些用户、语言、场景、模型和工具版本？ |
| Grader 组合 | 使用确定性检查、规则、模型评分、人工评分中的哪些？ |
| Grader 校准 | 与领域专家判断的一致性如何，已知偏差是什么？ |
| 试验次数 | 非确定性任务运行多少 trial，是否观察方差和长尾？ |
| 结果与置信边界 | 分子、分母、分布、严重失败数和不确定性是什么？ |
| 上线阈值 | 阈值何时确定，谁有权接受例外？ |
| 安全与权限测试 | 提示注入、越权、数据泄露、Tool 误用、Token 边界如何测试？ |
| 人工复核设计 | 哪些类别必须人工确认，复核者如何看见证据？ |
| 回归与持续 Eval | 模型、提示词、数据、工具或代码变化后如何重跑？ |
| 已知限制 | 哪些场景仍不支持，用户如何被告知和安全退出？ |
7.3 Task-specific Eval 的最低要求
根据 OpenAI 与 Anthropic 的官方方法，本章采用以下工作要求：[S7][S8][S9]
- 针对具体任务。 不用通用基准替代真实业务任务。
- 先定义成功和失败。 阈值不得在看到结果后为了“通过”而调整；确需调整时保留变更理由和旧结果。
- 组合 grader。 确定性结果优先用代码或规则；语义质量可使用模型评分，但要用人工样本校准；高风险判断保留领域专家。
- 检查最终环境状态。 Agent 自述“已完成”不算完成，要查看数据库、文件、工单、订单、权限或其他真实状态。
- 保留轨迹。 最终答案正确但过程越权、泄露数据或调用了错误工具，不能视为完整成功。
- 固定 harness。 测试环境、工具、初始状态和评分逻辑变化会改变结果，必须版本化。
- 覆盖多次试验和长尾。 单次成功不能代表非确定系统稳定。
- 区分开发 Eval 与生产监控。 离线通过不代表长期运行不会因流量、数据和依赖变化而退化。
7.4 状态与验收门
质量层可标为 Verified，至少需要：
- 任务、成功、失败和严重度边界已在主要结果产生前确定；
- 测试集与目标生产任务具有可解释的代表关系；
- Grader 组合与领域专家完成最小校准，模型评分器没有被当作绝对真值；
- Agent 类任务检查最终状态、轨迹和关键 Tool 行为；
- 非确定任务有多次 trial，结果不只报告最佳一次；
- 提示注入、数据泄露、越权、过度代理、凭证边界和人工确认已测试；
- 严重失败、已知限制和例外接受人清晰可见；
- 生产版本与被评测版本可对应，变更后有回归计划。
质量门通过条件： 项目定义的全部硬门满足；任何关键安全、权限或结果完整性证据为 Missing 或 Contested 时不得用平均分抵消。条件通过必须写清期限、流量限制、人工托底和退出条件。
7.5 反例
- 只展示三条精心挑选的成功输入。
- 用模型自己的文字说明判断任务已经完成。
- 数据集只有容易样本，没有真实失败和对抗样本。
- 在看到结果后下调上线阈值，却不保留变更记录。
- 只报告平均准确率，不报告严重错误和长尾。
- LLM grader 没有人工校准，且评分提示与被评系统共享同一盲点。
- Eval 环境允许管理员权限，生产却使用受限权限，或反过来。
- 离线 Eval 通过后，模型或工具版本已变但没有回归。
8. 第四层：运行证据
8.1 这一层要证明什么
运行证据证明某个版本在真实环境中可被识别、监控、回滚和负责，并说明用户是否真的把它用于目标工作流。
Google SRE 将 SLO 作为对服务水平的目标表达，并强调通过监控、发布控制和事故复盘管理真实服务，而不是只看部署动作。[S14][S15][S16]
Anthropic 的 Eval 指南也提醒：开发期评测是受控、任务级检查，生产监控则面对真实分布、长期变化和无法预先穷尽的行为，两者必须结合。[S9]
8.2 必填字段
| 字段 | 要回答的问题 |
|---|---|
| 发布身份 | 当前生产版本、模型、提示词、工具、配置和构建产物是什么？ |
| 环境与范围 | 哪些租户、用户、地区、数据和功能已启用？ |
| 发布策略 | 影子、灰度、Canary、分批或全量如何进行？ |
| 回滚与降级 | 谁能触发，回到什么状态，最近是否演练？ |
| SLI/SLO | 可用性、延迟、完成率、质量、人工复核、成本等目标是什么？ |
| 观测与审计 | 日志、trace、指标、Tool 调用和高风险动作如何记录？ |
| 告警与值守 | 谁响应，严重度、升级和时限如何定义？ |
| 生产 Eval | 真实流量如何抽样、复核、发现漂移和回归？ |
| 使用与采用 | 目标用户分母、真实任务量、重复使用、覆盖和绕行是什么？ |
| 成本与容量 | 单任务成本、峰值、配额、外部依赖和预算阈值是什么？ |
| 事故与复盘 | 发生过什么、影响谁、如何恢复、后续行动是否关闭？ |
| 变更记录 | 模型、数据、权限、工具和代码变化如何关联证据？ |
8.3 生产门与采用门必须分开
生产门 / Production gate 至少要求：
- 生产版本与被评测版本可追踪；
- 身份、最小权限、audience 校验和凭证边界生效；
- 关键 SLI、日志、trace、告警和审计可用；
- 回滚、降级、人工接管和事故责任人明确；
- 发布范围、风险接受和停止条件已批准；
- 敏感动作的人类确认在真实界面和真实权限下可工作。
采用门 / Adoption gate 至少要求：
- 明确目标用户总量和目标任务，不只看注册或访问；
- 有约定观察窗口内的重复使用、任务完成和覆盖数据；
- 记录人工绕行、放弃、错误复核和用户反馈；
- 区分主动真实使用、培训演示、测试流量和项目组代操作；
- 能说明新系统是替代原工作，还是增加了额外搬运和复核成本。
8.4 状态与验收门
运行层可标为 Verified，至少需要：
- 发布记录、生产版本、流量范围和责任人可回读；
- 关键 SLI/SLO、成本、质量和安全监控有真实数据；
- 回滚、降级和事故流程至少完成一次桌面推演或真实演练；
- 生产 Eval 与人工抽查能够发现离线 Eval 未覆盖的问题；
- 使用数据排除了测试流量和项目组代操作；
- 事故、争议和负面信号没有从案例中删除；
- 任何 Token、个人数据和安全细节按最小权限保存，不进入公开证据卡。
运行门通过条件： 生产门通过只允许声明“已上线”；采用门另行通过后才允许声明“已采用”。没有观测能力时，“没有告警”不是稳定性证据。
8.5 反例
- 服务可访问就宣布上线，没有真实身份、日志和回滚。
- 用请求总量代替目标用户完成的真实任务量。
- 把项目组每日测试计入采用率。
- 只看系统 uptime，不看任务完成、质量、人工复核和成本。
- 事故被私下修复，没有影响范围、时间线和后续行动。
- 仪表盘只保留成功率，失败样本和用户投诉无法回读。
- 生产日志记录完整 Token、Prompt 中个人信息或下游秘密。
9. 第五层：结果与移交证据
9.1 这一层要证明什么
结果证据证明原问题发生了可测变化；移交证据证明接收团队能够在原项目组退出后继续承担运行、评测、恢复和改进责任。
结果和移交放在同一层，是因为一个依赖外部团队长期人工托底的“结果”，尚未成为组织可持续拥有的能力。但两者仍需分别验收，不能用结果提升掩盖移交失败，也不能用文档齐全代替业务结果。
9.2 必填字段
| 字段 | 要回答的问题 |
|---|---|
| 结果指标 | 对应第一层的哪项基线，指标定义是否保持一致？ |
| 前后数据 | 基线值、结果值、分母、样本和来源系统是什么？ |
| 观察窗口 | 结果持续了多久，是否覆盖高峰、低谷和异常周期？ |
| 对照与归因限制 | 同期还有哪些流程、政策、人员或市场变化？ |
| 总成本与副作用 | 模型、基础设施、人工复核、错误、培训和迁移成本是什么？ |
| 风险变化 | 风险被降低、转移还是隐藏到其他环节？ |
| 业务与用户确认 | 谁确认指标有意义，谁提出异议？ |
| 后续决策 | 扩大、维持、修改、暂停或停止，理由是什么？ |
| 运行所有权 | 账号、配置、监控、预算、值守和供应商由谁负责？ |
| Eval 所有权 | 测试集、grader、阈值、回归和模型变更由谁维护？ |
| 安全与数据所有权 | 权限审批、审计、事件、保留和删除由谁负责？ |
| 移交资产 | 运行手册、架构、依赖、证据索引、已知风险和待办是否齐全？ |
| 培训与演练 | 接收团队是否独立完成发布、回滚、事故和 Eval 演练？ |
| 接受确认 | 接收责任人是否明确接受范围、限制和未结风险？ |
9.3 结果门
结果声明至少要求：
- 结果指标与第一层基线保持同一口径，变更时说明原因；
- 给出分母、时间窗、样本和来源，不只给百分比；
- 记录成本、人工投入、严重失败和副作用；
- 区分相关性和可归因性，不把同期其他变化全部算作 AI 效果；
- 业务 Owner 确认指标具有业务意义，争议方意见被保留；
- 结果达到项目预先约定的扩大、维持、修改或停止条件。
9.4 移交门
移交声明至少要求：
- 接收团队拥有所需账号、权限、预算、仓库、仪表盘和供应商关系；
- 运行、Eval、安全、数据和业务 Owner 均有明确姓名或岗位；
- 接收团队独立完成一次发布/配置变更、一次 Eval 回归和一次故障恢复演练；
- 凭证不通过文档或聊天明文移交，而通过受控系统和最小权限重新授权；
- 已知限制、技术债、未结风险、支持边界和外部依赖获得明确接受；
- 原 FDE 团队退出、转支持或继续共担责任的条件写入正式记录。
9.5 状态与验收门
只有结果门通过，才能声明“产生结果”；只有移交门通过，才能声明“完成移交”。
如果结果数据是 Verified，但移交材料为 Missing，项目可以写“已观察到结果，尚未完成移交”，不能写“完整交付”。如果移交材料齐全，但业务指标仍在观察，则只能写“完成运行责任移交，结果待验证”。
9.6 反例
- 用模型准确率提升代替业务周期、质量、成本或风险变化。
- 只有一个成功月份，没有基线季节性或异常解释。
- 忽略增加的人工复核、数据清洗和运维成本。
- 把使用增长全部归因于 AI，但同期有强制考核或流程下线。
- 业务负责人没有确认，只有供应商自己计算 ROI。
- 发了操作手册就宣布移交，接收团队从未独立回滚或重跑 Eval。
- 把共享管理员账号和长期 Token 当作“权限已移交”。
- 为了公开案例删除失败、争议和限制，只保留有利数字。
10. 验收决策：不要让总分掩盖关键缺口
证据状态用于描述材料，验收决策用于决定项目下一步。建议使用四种决策：
| 决策 | 含义 | 必须记录 |
|---|---|---|
Pass |
当前声明所需硬门均通过 | 版本、范围、有效期、签字/确认人 |
Conditional pass |
在限制范围、期限和人工控制下可继续 | 未通过项、补证期限、流量限制、退出条件 |
Hold |
关键证据 Missing、Contested 或风险不可接受 | 阻断项、Owner、下一次评审时间 |
Stop |
价值不足、风险不可接受、依赖不可满足或继续投入不合理 | 停止理由、数据/系统处置、可复用资产与教训 |
不建议把五层简单换算成一个百分制总分。一个严重越权风险不能被“文档写得很好”抵消；没有真实基线也不能靠高 Demo 准确率补足。
最低规则是：
- 当前阶段必需层出现
Missing，不得Pass； - 关键证据为
Contested，不得隐藏争议后Pass； Not publishable可以内部通过，但必须由有权限的评审者实际回读；Conditional pass必须有到期日，到期未补证自动回到Hold；- 任何变更导致证据失效时，阶段声明必须重新评审。
11. 公开、脱敏与权限等级
项目证据要支持复核，但“可复核”不等于“全部公开”。建议为每条证据同时标记证据状态和以下公开等级。
| 等级 | 名称 | 可见范围 | 典型内容 |
|---|---|---|---|
P0 |
公开 / Public | 任何读者 | 已授权的方法、聚合指标、无敏感细节的结论 |
P1 |
公开脱敏 / Public redacted | 任何读者 | 隐去组织、人员、系统标识和精确数量，但保留方法、时间窗、分母关系与限制 |
P2 |
受控评审 / Controlled review | 指定同行、客户或 NDA 范围 | 更详细的架构、样本和指标；凭证、个人数据仍不可见 |
P3 |
内部 / Internal | 项目与授权治理人员 | 原始日志、内部指标、事故、合同和风险接受记录 |
P4 |
限制 / Restricted | 最小授权人员和专用系统 | 凭证、个人敏感信息、受监管数据、未修复漏洞细节、密钥与安全配置 |
11.1 脱敏不是只删公司名
公开版至少检查：
- 人名、邮箱、手机号、账号、设备和客户标识
- 小样本、罕见岗位、精确时间与地区组合造成的再识别风险
- Prompt、日志、截图、文件名和 URL 中隐藏的内部信息
- 架构图中的域名、IP、租户、数据库、网络和安全控制细节
- 合同价格、商业条款、供应商折扣和未授权财务数据
- 可利用的漏洞步骤、Token、密钥、Cookie、会话和重定向地址
- 数据样本是否有权被用于公开或模型评测
- 脱敏是否改变了结论，是否选择性删除负面证据
11.2 公开证据的最低完整性
即使做了脱敏，公开案例仍应尽量保留：
- 项目阶段和不能主张的阶段
- 时间窗、样本量级和指标口径
- 方法、验收门和数据来源类型
- 已知失败、限制和人工控制
- 供应商自报、客户确认与独立验证的区别
- 脱敏项类别和脱敏原因
如果脱敏后已无法判断证据是否支持结论，应降低公开主张，而不是用模糊形容词补足。
13. 一次 60 分钟项目证据评审怎么开
- 10 分钟：阶段声明。 项目方只说当前主张什么，不讲完整项目故事。
- 10 分钟：问题与方案门。 回读基线、Owner、边界、替代方案、权限和停止条件。
- 15 分钟：质量门。 抽查失败样本、grader 校准、最终状态、轨迹、安全测试和版本对应。
- 10 分钟：生产与采用门。 回读发布、SLO、日志、回滚、真实用户分母和绕行。
- 10 分钟：结果与移交门。 回读前后口径、成本、副作用、责任接受和演练。
- 5 分钟：决策。 只选
Pass / Conditional pass / Hold / Stop，记录条件、Owner 和到期日。
评审不要求所有材料公开，也不要求一个会议读完全部原始日志。它要求证据索引能把评审者带到有权限、可回读、与声明对应的原始材料。
14. 本章结论
项目证据标准的目的不是增加文档数量，而是限制模糊主张。
一套可信的 FDE 项目记录应做到：
- 把 Demo、试点、上线、采用、结果和移交拆开声明；
- 为问题、方案、质量、运行、结果与移交分别留下证据；
- 区分材料是否存在、是否已验证、是否存在争议、是否可以公开；
- 在看到结果前定义验收门，不用事后改口径保证项目“成功”；
- 把权限、安全、失败、事故、成本和人工托底写进交付事实；
- 允许项目以
Hold或Stop结束，并把停止本身作为负责任的结果； - 不把本站框架包装成 NIST、ISO、OWASP、MCP 或任何公司的认证。
真正完整的交付声明不是“我们把系统做出来了”，而是：
我们能说明它解决什么、为什么这样做、质量到哪里、如何运行、产生了什么变化，以及谁已经能够继续负责。
行动资产
打开《FDE 项目证据卡 v1》，建立阶段声明、五层证据、验收门和公开等级。
来源与证据边界
以下均为官方一手来源。动态页面可能持续更新，引用时应结合本章标注的访问日期；如发现页面变化、链接失效或事实错误，欢迎提交更正依据。
NIST
- [S1] Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, published 2023-01-26. Accessed 2026-07-19.
边界： 自愿风险管理框架；不构成认证，也不自动满足具体国家、行业或组织要求。 - [S2] AI RMF Core, NIST AI Resource Center. Accessed 2026-07-19.
边界： 用于理解Govern / Map / Measure / Manage的结果结构，不把 Core 条目改写成本站合规清单。 - [S3] NIST AI RMF Playbook, NIST AI Resource Center, updated 2025-08-14 on the page accessed. Accessed 2026-07-19.
边界： 建议性、非穷尽、非检查清单；组织按环境选择行动。 - [S4] Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, published 2024-07-26. Accessed 2026-07-19.
边界： 自愿、跨行业的 GenAI 风险管理参考；不是 FDE 项目认证或强制性合规标准。
ISO/IEC
- [S5] ISO/IEC 42001:2023 — Artificial intelligence management system, ISO, 2023 edition. Accessed 2026-07-19.
边界： 面向组织的 AI 管理体系标准；本站项目证据卡不是管理体系认证审核。 - [S6] ISO/IEC 23894:2023 — Guidance on risk management, ISO, 2023 edition. Accessed 2026-07-19.
边界： 风险管理指南；本章只依据 ISO 公开页面，不声称取得或复述付费标准全文。
OpenAI
- [S7] Evaluation best practices, OpenAI developer documentation, continuously updated. Accessed 2026-07-19.
用于： Eval 目标、数据集、指标、人工校准、版本比较与持续评测。 - [S8] Agents SDK — Agent evals, OpenAI developer documentation, continuously updated. Accessed 2026-07-19.
用于： Agent trace、grader、工作流级评测和最终结果检查。
边界： OpenAI 平台工程文档，不是跨厂商质量认证。
Anthropic
- [S9] Demystifying evals for AI agents, Anthropic Engineering, published 2026-01-09. Accessed 2026-07-19.
用于： task-specific eval、成功/失败边界、trial、grader 组合、transcript、outcome、harness、开发 Eval 与生产监控的区别。 - [S10] Building effective agents, Anthropic Engineering, published 2024-12-19. Accessed 2026-07-19.
用于： Workflow/Agent 边界、复杂度控制、工具接口和 Agent 工程模式。
边界： 厂商工程实践，需要结合具体系统和独立项目证据验证。
OWASP 与 MCP
- [S11] OWASP Top 10 for Large Language Model Applications, OWASP GenAI Security Project, 2025 edition page. Accessed 2026-07-19.
用于： 提示注入、敏感信息泄露、输出处理、供应链与过度代理等失败模式。
边界： 开放安全风险参考，不替代组织安全评审、渗透测试或认证。 - [S12] MCP Security Best Practices, Model Context Protocol specification, version 2025-11-25. Accessed 2026-07-19.
用于： least privilege、audience validation、token passthrough 禁止、OAuth 与敏感操作确认。 - [S13] MCP Authorization, Model Context Protocol specification, version 2025-11-25. Accessed 2026-07-19.
用于： 授权协议边界、Token audience、scope 与服务端验证。
边界： 只覆盖 MCP 授权与相关攻击面，不代表企业整体安全合规。
Google SRE / 软件交付
- [S14] Service Level Objectives, Google, Site Reliability Engineering online edition. Accessed 2026-07-19.
用于： SLI/SLO、目标服务水平和用户可见可靠性证据。 - [S15] Release Engineering, Google, Site Reliability Engineering online edition. Accessed 2026-07-19.
用于： 可重复发布、构建身份、发布流程与回滚证据。 - [S16] Postmortem Culture: Learning from Failure, Google, Site Reliability Engineering online edition. Accessed 2026-07-19.
用于： 事故影响、时间线、根因、行动项和不责备复盘。
边界： SRE 实践材料，应按项目规模、组织和风险适配，不是单一上线检查表。
本章尚未完成的证据
- 五层项目证据标准与《FDE 项目证据卡 v1》是本站工作框架，目前没有外部标准组织背书。
- 本章尚未用真实中国企业项目完成 E2/E3 验证，字段完整性、评审耗时和公开脱敏规则仍需案例校准。
- 本章没有定义跨行业通用数值阈值。质量、风险、SLO、采用和结果门必须由具体项目按影响、用户和责任边界确定。
- 中国法律、行业监管、合同、隐私和安全要求必须由有权责任人单独确认；本章不提供法律意见。
- OpenAI、Anthropic、MCP 与 OWASP 页面会持续更新；后续版本将按复核日期更新引用，也欢迎读者报告链接失效或内容变化。
- 本章为公开 Beta，不代表已经完成任何具体项目的法律、隐私、安全、合同或合规审查；这些判断仍须由对应项目中有权的责任人完成。