本节对应 Checklists for multi-step workflows，关注多步任务的进度与遗漏。

问题

Agent 已经知道要看改动、读源码、检查测试、写报告，但执行到后面时，可能忘记前面还有未完成的步骤。

例如，已经读完 diff 就开始写结论，实际没有读被改函数的调用上下文。任务看起来结束了，却缺少支持结论的重要材料。

解决方案

把工作写成可跟踪的清单，为每一步说明什么证据能够表明它已完成。存在依赖时，写明后一步需要前一步的什么结果。

不要单纯把每句话改成复选框。清单需要能回答：正在做什么、已经拿到什么、还缺什么。

检查清单把应该做的事情列出来，帮助 Agent 跟踪进度、减少遗漏。清单中的勾选只是完成状态的记录；是否真的完成，要核对实际结果。需要强制执行的条件，还要由相应的程序机制落实。

清单、状态记录与执行约束分别负责什么

部分负责什么用“运行测试”举例
SKILL.md 中的清单说明应做的步骤和完成条件要求运行测试，并检查结果
任务或计划工具记录待办、进行中、已完成等状态将“运行测试”记为已完成
实际执行的验证器检查指定条件，给出结果测试程序运行后返回通过或失败
接入工作流的执行约束根据检查结果决定是否允许继续检查失败时阻止后续提交或发布

这些职责可以配合，但写下一个 - [ ] 不会自动把后面几层都配置好。清单也可以只在文本中维护，不一定调用专门的任务工具。

例如，Claude Code 的任务列表用来跟踪任务状态；OpenAI 官方指南中的 update_plan也通过步骤和状态更新计划。由这些接口的职责可知，记录“已完成”和检验结果是不同的工作；不能仅凭状态更新就推断测试已经通过。具体工具是否可用，取决于所用产品和会话配置。

如果需要在特定事件发生时自动运行检查，可以另外配置相应机制。例如，Claude Code 的 hooks可以在生命周期事件触发时运行命令，并在支持阻断的事件上返回阻断决定。强制检查需要实际配置检查逻辑与阻断规则；约束范围也仅限于该规则检查的条件。本节先理解这个边界，暂不展开配置。

最小示例

官网原例：跟踪表单处理的五个步骤

下面是官网示例的中文译文，保留原有脚本和文件名。这是 SKILL.md 的正文片段：

## 表单处理工作流

进度：
- [ ] 步骤 1：分析表单（运行 `scripts/analyze_form.py`）
- [ ] 步骤 2：创建字段映射（编辑 `fields.json`）
- [ ] 步骤 3：验证映射（运行 `scripts/validate_fields.py`）
- [ ] 步骤 4：填写表单（运行 `scripts/fill_form.py`）
- [ ] 步骤 5：验证输出（运行 `scripts/verify_output.py`）

这里的清单让 Agent 看见还有哪些步骤。第 3、5 步列出了验证动作，但验证能力来自实际运行的脚本，而不是复选框。脚本由谁调用、验证失败后如何处理、是否有程序阻止下一步，需要工作流另外落实。

这些路径是官网示例的设定，本页没有提供对应表单脚本，也没有将此例标记为已运行。

迁移练习：为代码审查记录步骤与完成证据

下面沿用审查任务，将本站已有工作步骤整理成完整教学文件：

---
name: review-diff
description: 用户要求审查当前 Git 仓库未提交改动、检查 diff 或查找回归时使用。
---

## 进度

- [ ] 确认审查范围，列出需要检查的改动文件。
- [ ] 查看改动，并补充与审查相关的未跟踪文件内容。
- [ ] 读取相关函数及测试，记录结论所依据的位置。
- [ ] 对疑似问题核对触发条件，必要时运行现有测试。
- [ ] 汇总问题与证据，写明已检查和未检查的范围。

只有拿到对应结果后才标记完成。
缺少文件、工具或其他前置条件时，记录缺少什么；不要标记已完成。

例如，“读取相关函数及测试”需要实际读取记录；“运行测试”需要命令及结果。尚未核对触发条件，就不能把疑似问题写成已经确认的缺陷。

怎样检查

将清单和执行记录逐项对照：

标记完成的项目应能找到的证据
确认范围明确的文件或目录范围
读取源码与测试对应读取记录和代码位置
核对问题触发输入、分析依据或测试结果
完成报告结论及覆盖范围

没有执行证据的勾选不算完成证明。即使有“已运行测试”的记录，也还要核对测试结果是通过还是失败。

如果工作流声称“验证失败就不能进入下一步”，还应在受控的失败用例中检查：程序是否真的阻止后续动作。只在清单里写下这句话，尚不能证明存在这样的约束。本页给出的是检查方法，尚未报告模型清单执行或阻断机制的评测成绩。

上一节：输出模板 · 下一节：验证循环