Appearance
企业AI交付清单专题
版本：
v1.2最后更新：
2026-07-08适用对象：需要把企业知识库、客服助手、审批助手、Agent 工作流、多模态能力或内部 Copilot 从 Demo 推到可上线状态的产品、交付、平台和架构同学
很多 AI 项目卡住，不是因为模型不够强，而是因为交付前没人把问题问全。
团队常见状态是：
- 功能已经能跑
- 演示效果也还不错
- 业务方已经看到了价值
但一旦准备正式上线，马上就会暴露出这些空白：
- 业务边界没写清
- 数据权限说不明
- 评测集不完整
- 回滚和人工接管没有准备
- 成本和容量没有测过
- 告警、值班、审计、审批没有挂到组织里
所以这篇真正想解决的问题是：
企业 AI 系统上线前，到底要准备哪些可执行交付项，才能从“能跑”进入“能接住”。
根据 2026-07-08 可访问的 OpenAI Production best practices、Evaluation best practices、Latency optimization、Prompt caching、Background mode、File search 等官方资料，可以先建立一个核心共识：
交付清单不是文档目录，而是一张风险边界与上线证据清单。
1. 为什么 AI 交付比普通功能更需要 checklist
AI 系统和传统接口最大的差别在于：
- 很多问题不会直接报错
OpenAI 当前 production best practices 与 eval 文档都在强调一件事：
- 生成式系统存在不确定性，必须靠评测、监控和逐步上线来控制风险
1.1 传统功能更像“坏了就报错”
例如：
- 接口超时
- 字段缺失
- SQL 报错
1.2 AI 系统更像“没报错但已经变差了”
例如：
- 命中了旧文档
- 工具参数偏了
- 结构化输出开始漂移
- 成本突然上升
- 用户感觉回答“不太对”，但系统没有 500
所以 AI 上线前真正需要的是：
- 一张把模糊风险翻译成可验证证据的清单
2. 交付清单不是文档目录，而是风险边界清单
很多团队会把“交付文档”写成一堆说明材料，但真正缺的不是说明，而是：
- 哪些问题必须在上线前被回答
- 哪些证据能证明已经回答
更好的 checklist 不只是写：
- 要关注安全
- 要关注评测
而是写成：
- 要验证什么
- 谁负责验证
- 怎么证明验证通过
- 不通过时怎么处理
如果没有这四层，清单很容易变成仪式感文档。
3. 一张最小可用的企业 AI 交付清单应该覆盖什么
建议至少覆盖下面 10 个模块：
- 业务目标与边界
- 数据来源与权限
- 模型、Prompt 与工作流设计
- 输出协议与工具动作
- 评测与验收
- 安全、合规与审批
- 可观测性、trace 与告警
- 回滚、降级与人工接管
- 成本、性能与容量
- 组织责任与持续运营
前 5 项更偏：
- 能力正确性
后 5 项更偏：
- 生产可持续性
4. 业务目标与边界清单
上线前至少要明确：
- 系统解决什么问题
- 什么结果算成功
- 覆盖哪些场景
- 明确不覆盖哪些场景
- 出错时用户会看到什么
4.1 最容易漏掉的一项：它不能做什么
很多团队会写：
- 这是一个企业 AI 助手
但不会写：
- 它不回答哪些问题
- 它不执行哪些动作
- 证据不足时必须拒答还是转人工
如果边界不写清，后面的评测与验收标准一定会漂。
4.2 更好的写法
不要写：
- 提升效率
更适合写：
- 首答命中率目标是多少
- 哪类问题必须给出引用
- 哪类动作必须进入审批
- 多大比例允许人工复核
5. 数据来源与权限清单
任何企业 AI 系统都离不开数据边界确认。
至少要确认：
- 数据来自哪里
- 谁拥有读取权限
- 是否包含敏感信息
- 数据多久同步一次
- 删除与权限变更多久生效
- 会话与日志保留多久
5.1 知识库类系统必须问清的几件事
例如：
- 不同部门是否看到不同文档
- 权限收回如何同步到检索层
- 引用的原文片段是否会越权暴露
- 文档更新后旧索引多久失效
5.2 最常见反模式
例如：
- 业务上分权了，检索层没分权
- 文档删除了，向量索引还在
- 用户没权限打开原文，却能通过回答间接看到内容
6. 模型、Prompt 与工作流设计清单
OpenAI 当前关于 prompt engineering、reasoning、model selection、production best practices 的资料都在提醒一件事：
- 不要把系统设计理解成“选个模型就结束”
上线前至少要能回答：
- 用了什么模型
- 为什么选它
- 是否有 fallback
- Prompt 谁维护
- 工作流是否有状态机
- 是否涉及检索、工具、审批或人工介入
6.1 这层最值得写进交付包的不是“名字”，而是“理由”
例如：
- 为什么用中模型而不是大模型
- 为什么这一段要低温
- 为什么这一步必须人工确认
如果只记录配置，不记录理由，后续交接时最容易丢失上下文。
6.2 Prompt 是否版本化
至少要明确：
- Prompt 有没有版本号
- 改动是否有评测
- 失败样例是否回流
否则上线后很容易陷入：
- 到底是哪句改坏了
7. 输出协议与工具动作清单
如果系统不只是“回答问题”，而是会：
- 抽字段
- 调工具
- 触发动作
- 进入审批
那交付前必须确认协议层。
至少要回答：
- 输出是自然语言还是 schema
- 字段是否有 required / enum 约束
- 工具参数如何校验
- 哪些动作允许自动执行
- 哪些动作必须确认或审批
7.1 这里最容易出事的地方
例如：
- 看起来是 JSON，但语义不稳定
- 模型说“已执行”，实际上工具没成功
- 同一动作在不同页面里有不同风险级别
7.2 更好的交付证据
例如：
- schema 文件
- tool registry 清单
- 批准动作列表
- 失败回路说明
8. 评测与验收清单
没有评测，AI 项目就只能靠感觉上线。
至少要确认：
- 离线评测集是否存在
- 高风险样例是否单独覆盖
- 验收标准是否明确
- 改模型 / 改 Prompt / 改检索是否都会回归
8.1 更好的验收证据
例如：
- 样例集版本
- eval 报告
- 高风险样例通过率
- 退化场景列表
- 已知限制说明
8.2 最常见反模式
例如：
- 只用演示问题做验收
- 只看准确率，不看引用和越权
- 只有平均分，没有关键场景分
OpenAI 当前 eval 文档也明确强调：
- 评测集应覆盖真实任务与真实失败模式
9. 安全、合规与审批清单
这层的目标不是“让文档看起来完整”，而是明确：
- 哪些风险被自动控制
- 哪些风险必须人工承担
至少要确认：
- 是否有敏感数据边界
- 是否有高风险动作审批
- 是否有 guardrails
- 是否有审计日志
- 是否有人工在环场景
9.1 对企业场景尤其重要的动作分级
建议至少明确：
- 只读动作
- 低风险写动作
- 中风险操作
- 高风险不可自动执行动作
9.2 哪些证据最值得写进交付包
例如：
- 风险分级表
- 工具白名单
- 审批门禁表
- 审计字段说明
10. 可观测性、trace 与告警清单
交付前至少要确认系统出了问题时，团队能看见什么。
建议至少具备：
- request ID
- trace
- 模型信息
- tool 调用记录
- token 使用
- 错误分类
- 高风险动作日志
10.1 交付前至少要演示一次什么
建议至少当面演示：
- 一次正常请求的 trace
- 一次失败请求的 trace
- 一次工具调用记录
- 一次高风险动作或审批日志
这比“口头说已经接了监控”更有说服力。
10.2 告警不该只盯错误率
还要考虑：
- 质量漂移
- 成本飙升
- 延迟恶化
- 安全拦截异常
11. 回滚、降级与人工接管清单
AI 项目如果没有这层，几乎不算准备好上线。
至少要确认：
- 模型能否切回旧版
- Prompt 是否可回退
- retrieval / tool schema 是否可回退
- 人工接管怎么发生
- 降级后用户体验是什么
11.1 更实用的降级顺序
很多企业系统更适合按下面顺序降级：
- 先切轻功能
- 再切只读模式
- 再切人工审批
- 最后切人工接管
11.2 背景任务也要有回滚思路
OpenAI 当前 background mode 文档提醒了一个现实：
- 长任务可能是异步运行的
所以交付清单里还要问：
- 异步任务失败时如何中止
- 结果是否可撤销
12. 成本、性能与容量清单
AI 系统的成本问题经常不是上线后才有，而是上线后才第一次看见。
至少要确认：
- 单请求成本预估
- 高峰并发能力
- P50 / P95 延迟
- 长任务是否异步化
- 是否启用缓存、batch、flex 或 background 模式
12.1 企业里最容易被低估的两类成本
第一类是：
- 输出过长导致的生成成本与延迟
第二类是：
- 检索、评测、重试和后台任务带来的隐藏成本
12.2 OpenAI 当前资料对成本优化有什么直接启发
从 prompt caching、latency optimization、flex processing、background mode 可以直接得到几个落地问题：
- 哪些固定前缀值得缓存
- 哪些任务可以异步
- 哪些任务适合低优先级处理
- 哪些链路必须控制输出长度
13. 组织责任与持续运营清单
真正能上线的系统，不是只靠代码完成，而是组织接得住。
至少要明确：
- 业务 owner 是谁
- 技术 owner 是谁
- 安全 / 审批 owner 是谁
- 谁看告警
- 谁处理线上失败样例
- 谁维护 eval 集
13.1 交付真正完成的标志
不是：
- 代码合并了
而是：
- 出事时知道谁处理
- 退化时知道谁回归
- 数据变化时知道谁更新
- 系统变更时知道谁审批
14. 一张更实用的上线前检查顺序
比起随机地“想到什么补什么”，更推荐按顺序过：
- 先确认业务目标与边界
- 再确认数据来源与权限
- 再确认模型、Prompt 与 workflow
- 再确认输出协议与工具动作
- 再跑评测与验收
- 再确认安全、审批、审计
- 再确认 trace、告警、值班
- 最后确认回滚、成本与容量
这个顺序的好处是：
- 先锁定“做什么”
- 再锁定“怎么安全地做”
- 最后锁定“怎么持续运行”
15. 企业里最常见的交付反模式
15.1 只有功能说明，没有上线证据
这类项目最容易在真正上线时返工。
15.2 只验证“好场景”，不验证失败场景
上线后通常会被真实用户迅速打穿。
15.3 只有全局指标，没有关键场景指标
结果是：
- 平均看起来不错
- 关键场景其实不稳定
15.4 没有回滚和人工接管
这样上线一旦出问题，只能硬扛。
15.5 没有明确 owner
这会让交付看似完成，但运营无法持续。