交付新标准：从回答问题到完成工作
30 秒结论
本书主张：生成内容不等于完成工作。只有结果能够继续编辑、接受核验并进入下一业务环节，AI 才完成了一次业务交付。
- 企业应按任务闭环评估 AI，而不只看回答是否流畅。
- 从 L1 回答升级到 L5 系统，人的责任不会消失，而会从逐句操作转向标准、异常和治理。
- 纯问答与任务型工作流解决不同问题，选择哪一种应由任务风险和交付要求决定。
你可能遇到的场景
每周一，你需要把上周会议纪要和本周业务数据整理成一份周报，交给负责人开会决定资源安排。输入可以是“6 月 30 日销售明细.xlsx”、上周周报和会议纪要；目标不是得到一段漂亮文字，而是让下一位同事可以继续编辑、核对和接手。
最后会得到什么
最终产物是一份可编辑的周报或会议纪要包，结构固定为：
- 一页结论与待决定事项；
- 数据或事实明细，以及每项的来源和版本；
- 行动项表（负责人、截止时间、交付物、验收标准）；
- 待确认清单、修改记录和下一步流转位置。
照着做
- 保留原始表格和会议纪要，列出本次使用的版本、读者、截止时间和下一动作。
- 先生成结论、事实来源和行动项草稿，不直接覆盖原周报，也不直接发送。
- **中间检查点：**逐项抽查数字、日期、负责人和引用，确认每项都能回到原件；无法回溯的内容标为待确认。
- 将草稿改成可编辑的周报或会议纪要，附上检查记录，交给业务负责人确认后再进入会议或群聊。
案例参考
可以先看品胜电子：竞品调研与产品物料制作，观察资料整理和可交付物如何分开描述；其中的客户陈述仍应按本页的来源和人工确认要求复核，不能直接当作你的效果承诺。
做完检查
打开最终文件，确认关键数字、引用和版本至少各抽查 3 项都能回到原始资料；再确认接收人能编辑文件、看到待确认项，并知道下一步保存或审批位置。任一项不满足，只能标为草稿。
需要注意
如果输入版本冲突、来源打不开或产物不可编辑，保留原件和当前草稿，停止外发，回到上一稳定版本或改成人工整理；由业务负责人确认口径，内容复核者确认事实和表达后再继续。
深入阅读
继续读本页的方法或模型、案例与证据和边界与下一步，再对照来源目录理解交付判据、产品事实与社区方法的边界。
为什么重要
如果验收停留在“生成了一段文字”，团队容易高估采用效果：使用者仍要搬运数据、重做格式、追查数字、补齐审批，真实成本被留在对话窗口之外。企业 AI 负责人据此决定试点是否值得扩大，业务负责人据此决定结果能否进入经营会、客户沟通或系统写入。
这套标准把采购演示中的“能生成”转换为运营现场的“能交付”，也让失败可以被记录：究竟是输入不足、事实不可查、格式不可用，还是流程没有接住结果。
方法或模型
本书建议：用“可编辑、可验证、可流转”三个判据共同定义业务交付；任一判据不满足，都应把任务视为未完成或降级为草稿。
| 判据 | 通过条件 | 最小验收证据 |
|---|---|---|
| 可编辑 | 产物能在约定工具中继续修改，关键结构没有被压平 | 可打开的源文件、字段或版式抽查记录 |
| 可验证 | 数字、引用、计算、版本和关键判断能回到来源 | 来源链接、公式、数据期间、样本抽查或勾稽表 |
| 可流转 | 结果能按权限进入保存、分享、评审或下一流程 | 保存位置、版本号、接收人、审批或写入记录 |
五层任务闭环用于判断团队当前在交付链的哪一层，不用于追求无条件升级：
| 层级 | 用户真正需要的结果 | AI 的角色 | 人的核心职责 |
|---|---|---|---|
| L1 回答 | 信息、解释、建议 | 对话助手 | 判断可信度与适用性 |
| L2 产物 | 文档、表格、演示、网页 | 内容与文件生产者 | 审阅事实、结构和表达 |
| L3 操作 | 查询、录入、整理、发布前准备 | 工具执行者 | 确认授权与关键动作 |
| L4 流程 | 周报、研究、月结、会议闭环 | 工作流编排者 | 定义标准、异常与回退 |
| L5 系统 | 跨岗位、跨数据源、持续运行 | 组织级 AI 工作层 | 治理、度量与持续改进 |
本书主张：纯问答用法与任务型工作流的差异在于使用方式和责任链，而不是对整个产品类别作优劣判断。
| 维度 | 纯问答用法 | 任务型工作流 |
|---|---|---|
| 使用方式 | 用户提问并自行衔接后续步骤 | 先定义任务卡，再按阶段推进和验收 |
| 交付物 | 答案、建议、草稿或局部生成 | 约定格式的文件、记录或流程结果 |
| 复用 | 依赖历史对话、收藏或人工复制 | 固化输入规范、模板、Skill 或运行记录 |
| 治理 | 主要核验单次输出 | 同时管理权限、确认点、异常、回退和审计证据 |
案例与证据
千问办公官方简介将 Word、Excel、PPT、网页等列为可交付产物形态。 R3 这项产品事实只说明官方列出的交付范围，不证明每种任务都能一次完成，也不代表所有账号、地区和权益下的能力完全相同。
本章的三个交付判据、五层闭环和使用方式比较属于社区方法。它们用于设计任务和验收，不是行业统计结论；企业应使用自己的失败样本、人工修改量和后续流转记录检验其适用性。
企业行动
先选一个每周发生、结果可人工判断且失败可逆的 L2 交付，不从跨系统自动写入开始。
| 责任角色 | 本轮动作 | 必留证据 |
|---|---|---|
| 业务负责人 | 选择一个可验收交付，明确接收人和下一动作 | 任务目标、完成定义、停止决定 |
| 使用者 | 保存输入版本、生成产物和运行记录 | 输入清单、产物链接、异常记录 |
| 内容复核者 | 按三个判据抽查事实、格式和流转条件 | 勾稽结果、修改清单、通过或退回结论 |
出现以下任一信号时停止升级，先修复任务设计：
- 产物无法在约定工具中继续编辑；
- 关键数据、引用或计算无法追溯；
- 结果无法进入约定的下一业务环节；
- 为补救错误新增了未记录的人工步骤。
边界与下一步
三个判据不要求所有任务都自动完成。高风险决策、专业判断和对外动作可以把“人工复核并明确确认”定义为交付的一部分。L1 也不是低价值层级：临时解释和探索性问题通常不需要建立完整工作流。
本章只定义什么算交付，不定义具体任务字段。团队应先选定一个可验收结果，再把它写成结构化任务卡。