任务交付协议：先定义完成
30 秒结论
本书建议：在启动 AI 任务前先定义“完成”，再决定提示词、工具和自动化方式。
本章将任务卡唯一规范定义为五个字段：目标、输入、约束、交付、验收。其他章节和附录只引用这一定义，不另建同义字段体系。
你可能遇到的场景
同事只发来一句“帮我做一份经营分析”，但没有说给谁看、数据到哪一天、是否可以使用客户关系管理系统（CRM），或谁来确认。你可以把输入例子写成“本周 CRM 机会清单、上周版本、阶段字典，截止 6 月 30 日”，先把模糊请求变成一张普通用户也能填写的任务卡。
最后会得到什么
最终产物是一张五字段任务卡：
- 目标：为谁完成什么任务，支持什么决定；
- 输入：资料、系统、期间、版本和授权范围；
- 约束：口径、格式、禁做动作和停止条件；
- 交付：文件类型、结构、命名、位置和可编辑要求；
- 验收：检查人、检查方法、退回条件和确认点。
照着做
- 把原请求改写成“读者—决定—截止时间”，并列出已有输入、缺失输入和无权限输入。
- 填好约束、交付和验收，明确是否允许发送、写入或发布。
- **中间检查点：**让业务负责人复述五个字段；只要目标、口径、版本或确认人说不清，就先补卡，不让 AI 猜。
- 用任务卡运行一次，保存输入版本、产物、人工修改和最终验收记录。
案例参考
可先看优克拉：产品研发与考勤算薪，把它当成“输入—处理—产物—验收”的任务卡练习；案例中的具体客户陈述仍需保留来源和人工复核边界。
做完检查
逐项检查五个字段是否都有可执行内容：例如“验收”必须写出具体检查人和退回条件，而不能只写“没问题就发”。字段不完整时，任务只能停留在澄清阶段。
需要注意
如果目标变更、输入版本冲突或高风险动作没有确认人，保留原任务卡和原始资料，停止运行，回到上一稳定版本；由业务负责人重新确认口径，必要时改成人工整理或只读分析。
深入阅读
继续读本页的方法或模型、案例与证据和边界与下一步，并使用任务交付与审核模板核对五字段定义。
为什么重要
“帮我做一份经营分析”没有说明谁要据此作决定、数据截止到哪天、使用什么口径、最终交付什么文件，也没有说明谁来核对。AI 即使生成完整报告，也可能在错误的问题上高质量作答。
任务卡把模糊需求变成可观察的协议。业务负责人可以在运行前确认方向，使用者可以识别缺失输入，内容复核者可以按同一标准退回，团队也能比较不同工具或不同版本的真实完成率。
方法或模型
五段式任务卡是本书后续工作流的共同输入合同：
| 字段 | 必须回答的问题 | 可验收写法 | 不合格写法 |
|---|---|---|---|
| 目标 | 为谁完成什么任务，支持什么决定 | 供周一经营会决定是否追加华东预算 | 给领导看 |
| 输入 | 允许使用哪些资料、系统、期间和版本 | 使用附件 A 明细，数据截至 6 月 30 日 | 看附件 |
| 约束 | 采用什么口径，禁止什么，何时必须停止 | 同比按去年同期；缺失值不得补造 | 尽量专业 |
| 交付 | 输出格式、结构、位置、命名和可编辑要求是什么 | 1 页摘要、可编辑表格、校验说明 | 一份报告 |
| 验收 | 谁在何时检查什么，什么情况退回 | 财务勾稽总计，业务负责人确认后发布 | 没问题就发 |
把任务卡转成可运行任务时，按六步执行：
- 澄清目标：复述读者、决定和截止时间；方向不一致时不进入处理。
- 检查输入：列出已获得、缺失、无权限和可信度存疑的资料；确认版本、日期和主键。
- 锁定约束：写明统计口径、格式规范、禁止项、权限边界和异常处理。
- 定义产物：把最终结果拆成可检查的中间产物与最终交付，并约定保存位置。
- 写出验收：指定检查人、抽查方法、退回条件以及发送、写入、发布前的确认点。
- 运行与复盘：保存任务卡、输入版本、生成版本、人工修改、异常和最终确认人。
任务缺字段时先补齐，不允许 AI 自行猜测业务口径。涉及付款、删除、人员决策、系统写入或对外发布时，把预览、明确确认和回退方式写入“约束”和“验收”。
案例与证据
经营周报的快速任务卡可以写成：
| 字段 | 示例 |
|---|---|
| 目标 | 为销售负责人形成周会材料，支持判断各区域是否需要资源支持 |
| 输入 | 本周 CRM 机会清单、上周版本、已确认的阶段字典 |
| 约束 | 只统计已定义阶段；金额单位统一；缺失负责人时标红，不补造 |
| 交付 | 1 页摘要、区域明细、异常名单和校验说明，保存为新版本 |
| 验收 | 汇总与明细勾稽；异常可追溯到记录 ID；发群前由业务负责人确认 |
运行时先输出字段字典和异常规则，确认后清洗，再生成汇总并核对总计，最后用“观察—可能原因—需要决定”组织摘要。这样即使建议被修改，数据底座和审阅路径仍可复用。
这是社区实践示例，不代表特定业务的统计口径。可复制的空白任务卡放在 提示词附录，附录不得改变本章五个字段的含义。
企业行动
| 责任角色 | 责任 | 验收证据 |
|---|---|---|
| 业务负责人 | 批准目标、业务口径和高风险动作；决定继续或停止 | 已确认任务卡、闸门记录、停止决定 |
| 使用者 | 准备输入，按卡运行，记录版本、异常和人工修改 | 输入清单、运行日志、产物版本、修改记录 |
| 内容复核者 | 检查事实、数字、专业质量和读者可用性 | 勾稽表、来源抽查、修改意见、验收结论 |
第一次实施时，从一个高频、输入稳定、失败可逆的任务抽取 5 个真实样本。每次只调整一个字段或规则，比较返工原因；连续 3 次在同一边界内通过验收后，才考虑固化为模板、Skill 或定时任务。
出现以下情况应停止本轮执行：目标或读者发生变化；关键输入缺失或版本冲突；口径无法由负责人确认；产物无法按约定格式交付；高风险动作没有明确确认或回退办法。
边界与下一步
任务卡不能替代专业判断，也不能把未知信息变成事实。对于探索性任务，目标可以写成“形成问题清单或验证假设”，但输入边界、禁止项和本轮交付仍需明确。
本章只定义任务协议。工具如何连接文件、浏览器和协同系统，以及不同运行环境承担什么责任，将由后续架构章节定义。