AI Task Brief

更新时间：YYYY-MM-DD

任务

• 真实场景：
• 使用者/受众：
• 要完成的决策或动作：
• 截止时间：

输入与边界

• 已知事实与来源：
• 允许使用的文件：
• 数据敏感等级：公开 / 内部 / 机密 / 受限
• 明确不提供的材料：
• 版权或授权限制：

输出与验收

• 最终交付物：
• 格式与长度：
• 可观察的完成标准：
• 必须由人确认的事项：

工作方式

• AI 可以做：
• AI 不可以做：
• 人工审阅者：
• 失败时如何暂停、回滚或通知：

证据位置

• 无 AI 基线：
• 原始来源：
• 测试/反馈：
• 最终版本：

逐组说明其作用与填写要点：

**第 1 组：任务。** 决定简报是否成立的三要素是真实场景、使用者和要完成的动作。注意动词是"决策或动作"，不是"学习 Python"这类主题词。截止时间给整份记录一个可回查的节奏点。

**第 2 组：输入与边界。** 这一组是 AI 协作的事实红线。"已知事实与来源"区分了事实与推测；"允许使用的文件"限定了模型能读取的范围；"数据敏感等级"四选一即可完成脱敏分级；"明确不提供的材料"主动声明禁区；"版权或授权限制"回答材料能否合法进入模型。简言之，这一组回答"能用什么、不能用什么"。

**第 3 组：输出与验收。** 全模板最容易被写坏、也是最核心的一组。"最终交付物 + 格式与长度"定义成品形态；"可观察的完成标准"必须写成第三方能核验的动作；"必须由人确认的事项"把所有最终判断——事实、授权、成本、署名——留在人这边。

**第 4 组：工作方式。** 划清 AI 与人的分工边界，并预设失败路径："AI 可以做 / 不可以做"防止越权代做，"人工审阅者"指定责任主体，"失败时如何暂停、回滚或通知"让失控时有动作可依。

**第 5 组：证据位置。** 链接或路径化的证据登记处：无 AI 基线、原始来源、测试/反馈、最终版本。它让"证明 AI 帮了什么"和"证明我学会了什么"成为可回访的文件操作，而不是一句口头感觉。

## 四、把验收标准写成动作，而不是形容词

模板末尾单独用一段话强调验收标准的写法：

> 验收标准要写成动作，例如"用户能在 10 分钟内完成导入并看到可解释的错误报告"，不要写"体验好"或"足够智能"。

这句话在 [「用 AI 学习一切」章节](https://gitcode.com/GitHub_Trending/en/up/blob/aeab7ff8e297a6772908f546f41cb05d40b482ee/docs/threads/part-3/1-ai-learning.md?utm_source=gitcode_repo_files) 里被反复强化："体验好""架构先进""学会 AI"都不是验收标准。合格的写法是一个**可观察动词 + 条件 + 对象**，例如：

- "用户能在 10 分钟内完成一次导入，并看到一份可以解释的错误报告"；
- "我能在不翻稿的情况下，向同事用三分钟说明项目风险并回答一个追问"。

如果暂时写不出这种句子，宁可把它写成"待核验"，也不要拿"体验好"填空——因为后者无法被任何人复查或复述，也就不构成[术语索引](https://gitcode.com/GitHub_Trending/en/up/blob/aeab7ff8e297a6772908f546f41cb05d40b482ee/docs/reference/glossary.md?utm_source=gitcode_repo_files)定义的"完成标准"。

## 五、填入七步闭环：简报先于提示词

模板在方法论上的位置是七步闭环的第 1 步。结合 [「用 AI 学习一切」的七步闭环](https://gitcode.com/GitHub_Trending/en/up/blob/aeab7ff8e297a6772908f546f41cb05d40b482ee/docs/threads/part-3/1-ai-learning.md?utm_source=gitcode_repo_files)：

1. **定义真实结果**（写清场景、受众、动作、截止时间和验收标准）——这里就是任务简报；
2. **保存无 AI 基线**：先独立做一次，暴露缺口；
3. **准备可信材料**：官方文档、教材、论文、现有代码与真实案例；
4. **设计引导练习**：让 AI 提问、解释、比较、提示，不代替关键步骤；
5. **主动产出**：关闭材料后自己解释、编码或写作；
6. **通过多源反馈**：AI 只是一个意见来源；
7. **更新状态**：保存作品、错误、成本与下一项最小任务。

该章节对缺失步骤的后果说得非常直接：缺少第 1 步，"AI 会把愿望包装成答案"；缺少第 2 步，"你不知道能力是否增长"；缺少第 6、7 步，"错误会在下一次对话里重复"。简报对应的就是第 1 步，其余六步可由 [AI 学习记录](https://gitcode.com/GitHub_Trending/en/up/blob/aeab7ff8e297a6772908f546f41cb05d40b482ee/docs/templates/ai-learning-log.md?utm_source=gitcode_repo_files) 与 [证据链](https://gitcode.com/GitHub_Trending/en/up/blob/aeab7ff8e297a6772908f546f41cb05d40b482ee/docs/templates/evidence-chain.md?utm_source=gitcode_repo_files) 承接。

## 六、会话开始前、进行中、结束后如何使用同一份简报

简报不是填完就归档的文件，它应该贯穿一次 AI 协作的全程。从 [「用 AI 学习一切」章节](https://gitcode.com/GitHub_Trending/en/up/blob/aeab7ff8e297a6772908f546f41cb05d40b482ee/docs/threads/part-3/1-ai-learning.md?utm_source=gitcode_repo_files) 可以提炼出一套最小会话协议：

- **开始前，让 AI 只做边界复述**：请它用不超过 8 条要点复述目标、受众、输入、验收标准、限制、未知项和无法确认的内容；列出准备使用的来源；先不要生成最终交付，只指出最可能导致返工的 3 个风险。
- **进行中，每次只推进一个可检查切片**：要求"拆成最小可验证切片，每次只推进一个，说明输入、假设、改动、检查方式和下一步"；如果前提冲突，暂停并提问，不要悄悄替换需求。
- **结束时，生成状态更新而不是漂亮总结**：输出"已完成与证据位置、已被确认的判断、仍会重复的错误与未决问题、下一项最小任务"四项，并且不声称记得其他会话、不把推断写成事实。

这里的"重新粘贴任务简报"也是一种失控救援手段：当模型回答"越来越完整却不再回答原任务"（需求漂移）时，把简报原文贴回去并要求列出冲突和未知项，是把对话拉回轨道的标准动作。

## 七、从学习到项目开发：一份 task-brief.md 的工程化用法

模板的应用场景不止个人学习。在 [「AI 开发与资源层」章节](https://gitcode.com/GitHub_Trending/en/up/blob/aeab7ff8e297a6772908f546f41cb05d40b482ee/docs/threads/part-3/2-ai-development-and-resource-layer.md?utm_source=gitcode_repo_files) 中，作者把同样的结构移植成项目的 `task-brief.md`（真实场景、使用者、要完成的动作、截止时间、来源、文件允许范围、数据敏感等级、验收标准、AI 可做与不可做、人工审阅者、回滚方案），并明确规定"每个项目先创建一页 task-brief.md"。该章节对项目任务多了一条硬要求：

> 每个关键决定都必须能够被测试、被解释，或被回滚。

在代码语境里，简报还要与三道交付门配合使用：

- **能解释**：没有聊天记录，负责人能说明关键决定和限制；
- **能测试**：真实输入、边界情况、权限和失败路径都有检查；
- **能回滚**：出现数据风险、供应商中断或质量下降时，知道谁暂停、如何通知、怎样恢复。

项目目录建议使用 `00-brief/`（任务简报和验收标准）打头、`07-operations/`（权限、监控、部署和回滚）收尾的分层结构，让简报本身成为版本化的工程文件。

## 八、从简报到证据闭环：它连接哪些模板

一张简报完成使命的标准不是被填满，而是被后续模板接力。在 [toolkit.md](https://gitcode.com/GitHub_Trending/en/up/blob/aeab7ff8e297a6772908f546f41cb05d40b482ee/docs/templates/toolkit.md?utm_source=gitcode_repo_files) 定义的工具链中，与 AI 任务简报关系最直接的四张工作表是：

- [AI 学习记录](https://gitcode.com/GitHub_Trending/en/up/blob/aeab7ff8e297a6772908f546f41cb05d40b482ee/docs/templates/ai-learning-log.md?utm_source=gitcode_repo_files)：协作后马上打开，保存无 AI 基线、引导练习、错误、证据、独立表现和迁移结果；
- [AI 项目评分卡](https://gitcode.com/GitHub_Trending/en/up/blob/aeab7ff8e297a6772908f546f41cb05d40b482ee/docs/templates/ai-project-scorecard.md?utm_source=gitcode_repo_files)：每次发布或试点后填写，用完成率、返工、成本、安全与回滚状态而非生成速度评价项目；
- [作品简报与交付卡](https://gitcode.com/GitHub_Trending/en/up/blob/aeab7ff8e297a6772908f546f41cb05d40b482ee/docs/templates/artifact-brief.md?utm_source=gitcode_repo_files)：当任务面向真实受众时，把简报升级为包含独立版、结构版、反馈版、交付版四版本的作品卡；
- [AI 经历案例复盘](https://gitcode.com/GitHub_Trending/en/up/blob/aeab7ff8e297a6772908f546f41cb05d40b482ee/docs/templates/ai-case-review.md?utm_source=gitcode_repo_files)：当"任务"变成分析他人公开经历时，用这套复盘表区分事实、判断、结果与可迁移原则。

模板之间不是并列的课程，而是一条可往返的证据链路：简报定义任务边界，学习记录留三次对照样本，评分卡量化发布结果，复盘卡沉淀原则。任何一步发现证据不足，都可以退回上一张缩小任务。

## 九、一份可直接模仿的完整示例

把上面所有要点落成一份实际可复制的完整简报，比十份只写了一半的填空更接近"会用"：

```markdown
# AI Task Brief

更新时间：2026-09-07

## 任务
- 真实场景：我想把一份手写的月度记账 CSV 整理成可汇报的收支报表
- 使用者/受众：我自己（下月还要复查）与两位合作成员
- 要完成的决策或动作：在 6 份 csv 上跑通同一套清洗逻辑并生成错误说明
- 截止时间：2026-09-14

## 输入与边界
- 已知事实与来源：csv 字段结构已核对，账单来源是月度导出文件
- 允许使用的文件：docs/samples/ 下的 6 个 csv
- 数据敏感等级：内部
- 明确不提供的材料：员工姓名列、合同金额列
- 版权或授权限制：报表仅用于本项目内部，不对外发布

## 输出与验收
- 最终交付物：一份合并后的收支报表 + 一份清洗说明
- 格式与长度：CSV + 500 字以内的说明文档
- 可观察的完成标准：用户能在 10 分钟内完成导入并看到可解释的错误报告
- 必须由人确认的事项：清洗规则是否改动原始数据、成本是否在预算内、报表署名

## 工作方式
- AI 可以做：读取允许的文件、生成清洗脚本、指出字段不一致
- AI 不可以做：自动跳过报错行、删除任何原始列、代写最终结论
- 人工审阅者：我（2026-09-14 前复核）
- 失败时如何暂停、回滚或通知：保留原始 csv 副本，出错即停止并抄送两位成员

## 证据位置
- 无 AI 基线：docs/baseline/手动清洗记录与用时
- 原始来源：docs/samples/
- 测试/反馈：docs/feedback/两位成员试用反馈
- 最终版本：docs/output/report-2026-09-14.csv