本节对应 Templates for output format，解决同类任务输出缺项、结构不一致的问题。
问题
“输出一份清楚、专业的分析报告”仍然允许很多写法。有的回答只有结论，有的列出发现却没有支持数据，有的没有给出后续建议。
如果任务需要这些信息，使用者就得每次重新追问。问题在于：要求表达了期望，却没有展示交付结果应有的结构。
解决方案
给出实际模板，并说明如何填写。Agent 可以直接参照栏目、排列顺序和占位提示生成结果，减少对格式要求的猜测。
短模板可以直接放进 SKILL.md；较长或只在特定场景使用的模板，可以放进 assets/，在 SKILL.md 中说明何时读取。
当任务需要稳定的输出结构时，把必要的栏目和填写提示写成模板，让 Agent 根据本次任务填入内容。模板能减少结构遗漏，内容是否正确仍需要验证。
最小示例
官网原例：直接展示报告结构
下面是官网示例的中文译文。这是放在 SKILL.md 正文中的一个片段，尚不是完整技能：
## 报告结构
使用以下模板，并根据具体分析的需要调整章节：
```markdown
# [分析标题]
## 摘要
[用一段话概括关键发现]
## 关键发现
- 发现 1 及其支持数据
- 发现 2 及其支持数据
## 建议
1. 具体、可执行的建议
2. 具体、可执行的建议
```
这个例子把三件事放在了一起：
| 模板里的内容 | 告诉 Agent 什么 |
|---|---|
| “摘要 → 关键发现 → 建议” | 报告默认按什么结构组织 |
[分析标题]、[用一段话概括关键发现] | 这里需要填入本次任务的内容 |
| “支持数据”“具体、可执行” | 填写时需要满足什么要求 |
“发现 1、发现 2”是列举方式的示例，不要求每份报告恰好有两条发现。官网也明确允许按具体分析调整章节。模板中哪些栏目必须保留、哪些可以调整，应由任务需求决定并在指令里说清楚。
迁移练习：把模板用于代码审查
代码审查需要更具体的结构：指出文件之后，还要说明什么情况下出问题、有什么影响、依据是什么。因此，不能只照搬上面的分析报告栏目，而要按审查任务选取必要字段。
下面的 assets/report-template.md 来自本站现有练习，仅省略了历史章节说明：
# 审查报告
## 问题
- 文件与行号：
- 触发输入或交错顺序：
- 具体表达式与影响：
- 证据（读取内容、测试结果）：
## 覆盖范围
- 已检查：
- 未检查：
- 用到了哪些参考文件：
- 是否修改文件：默认应为否
与它配套的完整最小 SKILL.md：
---
name: review-diff
description: 用户要求审查当前 Git 仓库未提交改动、检查 diff 或查找回归时使用。
---
1. 查看当前改动，读取相关源码与测试。
2. 报告前读取本技能目录内的 `assets/report-template.md`。
3. 每个问题重复填写模板中的“问题”部分，引用源码或实际测试作为证据。
4. 没有发现问题时如实说明，并填写覆盖范围。
目录关系是：
review-diff/
├── SKILL.md
└── assets/
└── report-template.md
模板文件与它的完整练习包可在机制参考附录查看。
怎样检查
先看结构，再核对内容：
- 必要栏目有没有缺失？ 对代码审查例子，检查位置、触发条件、影响、证据和覆盖范围是否齐全。
- 占位提示有没有被真实内容替换？ 不能只保留“发现 1 及其支持数据”，也不能为了填满模板编造缺陷；没有发现问题时如实说明。
- 填入的内容有没有依据？ 打开报告引用的源码或测试结果，确认它们确实支持结论。
“有证据这一栏”与“证据支持结论”是两项不同的检查。模板能减少结构遗漏，内容真实性仍需要验证。本页没有把模板的存在当成模型已经正确填写它的证据。