端到端交付案例

案例目标：把会议录音转写、聊天记录和一份旧方案整理成“会议纪要 + 行动清单 + 对外邮件草稿”。这类任务包含多份材料、多种产物和明确验收，非常适合练习 WorkBuddy 的真实交付能力。

第 0 步：整理工作空间#

Project-Review/
├── input/
│   ├── transcript.txt
│   ├── chat-export.txt
│   └── previous-plan.docx
├── output/
└── brief.md

使用材料副本。先人工确认文件能打开、时间范围一致、没有超出任务范围的个人敏感信息。

第 1 步：先做材料清点#

只读取 input，不生成正式文档。
请输出材料清单，并说明：
- 每份文件包含什么；
- 哪些信息互相冲突；
- 缺少哪些会影响纪要准确性的内容；
- 你准备如何区分“已决定”“建议”和“待确认”。

这一步能提前发现转写缺段、版本过旧或聊天记录时间不完整。材料有问题时，继续润色只会把错误包装得更漂亮。

第 2 步：下达交付简报#

基于 input 材料，在 output 生成复盘包：

1. meeting-notes.md
   - 会议目标、关键结论、争议点、待确认事项；
   - 每条结论标注来源文件；
   - 不把建议写成已决定。

2. actions.csv
   - 字段：任务、负责人、截止时间、状态、依据；
   - 缺少负责人或日期时写“待确认”，不要猜。

3. follow-up-email.md
   - 200—300 字；
   - 语气专业、简洁；
   - 只包含已确认结论和行动项。

约束：
- 不修改 input；
- 发现冲突先列出，不自行裁决；
- 完成后给出文件清单和自检结果。

第 3 步：观察执行，而不是等待答案#

在任务过程中检查：

• 是否只访问了工作空间；
• 是否先解析再生成；
• 是否请求不必要的外部权限；
• 是否遇到文件格式兼容问题；
• 是否把不确定信息标注出来。

若过程偏离，立即暂停并缩小任务，不要等到最后一次返工所有产物。

第 4 步：按证据验收#

会议纪要#

抽查三条关键结论，回到原始材料核对。重点看事实是否被改写、否定词是否丢失、发言人是否错配。

行动清单#

检查每个行动项是否都有依据。负责人、时间缺失时必须显式“待确认”，不能补出看似合理的信息。

邮件草稿#

确保邮件没有引入纪要之外的新承诺；附件、日期、称呼仍需人工确认。

第 5 步：反馈要具体#

低效反馈：“再专业一点。”

有效反馈：

请只修改 follow-up-email.md：
- 开头直接写本次确认的两个结果；
- 删除“非常”“全面”等空泛修饰；
- 行动项用 3 个项目符号；
- 保留所有日期和负责人原样；
- 不修改另外两个文件。

反馈同样要有范围、目标和禁区。

质量门槛#

常见失败模式#

• 直接让 AI“总结一下”：没有定义产物和用途。
• 材料混在输出目录：容易误改原件。
• 默认 AI 会补全负责人：生成了没有依据的承诺。
• 只检查排版：忽略事实一致性。
• 一次反馈改全部文件：引入新的版本漂移。

可复用验收清单#

• 原始材料使用副本
• 先清点再生成
• 事实、建议、待确认被区分
• 每个行动项可回溯
• 输出文件名和位置固定
• 原始文件未修改
• 对外发送前由人复核