第 10 章：手工制作第一个 Skill
本章手工制作 incident-action-items 技能，将故障记录整理为结论、行动项和待确认问题。通过原始记录与明确补充后的输入，观察同一套规则怎样复用。
10.1 第一个技能只做一件事
技能名称为 incident-action-items，职责是整理故障信息。
输入是一份故障文本，输出是故障信息、已确认结论、行动清单和待确认问题。行动清单明确到任务、负责人、日期，并保留简短原文依据。
这个案例不需要联网、调用外部账号或安装 Python 库。自动连接日志平台、制作 Word 排版都暂不纳入，方便把注意力放在技能文件本身。
准备最小目录
incident-action-items/
└── SKILL.md用文本编辑器创建文件，保存为 UTF-8，确认文件名没有变成 SKILL.md.txt。官方技能说明要求核心文件包含 name、description 和执行说明，可选资源按需增加。Codex 技能结构
本章已经提供完整 SKILL.md。阅读时依次关注元数据、输入来源、判断规则和输出结构。
10.2 写清名称和描述
文件开头写：
---
name: incident-action-items
description: 根据电商系统故障记录提取已确认现象、排查行动和待确认问题。适用于支付回调、订单同步、导出异常等工单整理；不执行生产修复，不把推测写成根因。
---两行 --- 之间是 YAML 元数据，可以先理解为“字段名加字段值”。这里使用英文冒号，并在冒号后留一个空格；分隔线以外才是正文。
name 是技能标识，本例使用小写英文和连字符，与文件夹名称一致。description 说明做什么、什么时候使用，以及容易混淆的边界。
对比下面两种写法：
| 写法 | 问题或优点 |
|---|---|
| 帮助用户高效处理各种工作 | 范围太宽，难以判断何时匹配 |
| 根据故障记录提取结论、行动项和待确认问题 | 任务明确，便于与其他技能区分 |
名称和描述帮助客户端与模型发现技能，不保证每次自动匹配成功。首次使用先显式调用，避免把“没有选中技能”和“技能步骤写错”混在一起。
10.3 正文写方法，不写固定答案
先说明读取什么
读取用户本次提供的故障文本或指定文件。
未提供内容或无法读取时，说明缺少的输入，不根据历史故障猜测。这句话限定了事实来源。某次记录中的姓名与日期都不应该成为技能默认使用的内容。
再说明关键判断
普通摘要容易遗漏任务，机械提取又容易把所有建议当作决定。因此本技能规定：
- 区分决定、行动、提议和待确认事项。
- 负责人或日期没有明确时写“待确认”。
- 谁提出建议，不等于谁负责执行。
- 日期冲突没有最终结论时，保留冲突，不自行选择。
例如，“小许建议增加支付回调重发功能，但本次不做”，可以写进已确认结论，不能变成“小许负责开发支付回调重发功能”。
最后规定输出与核对
默认输出故障概况、已确认安排、行动清单和待确认问题。其中行动清单采用：
| 任务 | 负责人 | 完成日期 | 原文依据 |
|---|---|---|---|
| 根据本次输入提取 | 未明确则待确认 | 未明确则待确认 | 支持该项的原文短句 |
没有行动项时直接说明，不为了填满表格而创造任务。用户要求保存时输出指定的 Markdown 或文本文件；没有要求保存时可以直接回复。
增加“原文依据”是为了便于核对，不是要求把整份故障记录复制一遍。交付前重新核对姓名、日期和决定状态，能帮助发现看似流畅但缺乏依据的提取。
完整技能文件
下面将元数据、规则和输出要求放入同一个文件。保存后，技能目录中至少包含这份 SKILL.md。
---
name: incident-action-items
description: 根据电商系统故障记录提取已确认现象、排查行动和待确认问题。适用于支付回调、订单同步、导出异常等工单整理；不执行生产修复，不把推测写成根因。
---
# 电商故障信息整理
读取用户本次提供的故障文本或指定文件。缺少输入时说明缺口，不沿用历史故障结论。
## 整理规则
- 区分已确认现象、排查假设、已确定行动和未采纳建议；没有证据不确认根因、影响范围或损失金额。
- 行动项列出任务、负责人、完成日期和原文依据。缺少负责人或日期时写“待确认”，提出建议的人不自动成为负责人。
- 分别记录记录日期、计划验证日期和实际恢复时间；未提供的时间不补造。相对日期只有参照明确时才换算。
- 时间或状态有冲突时保留双方说法，列为待确认；只有明确最终决定才能消除冲突。
- 只整理本次输入，不连接生产系统，不重放支付回调、不改订单状态，也不将整理完成写成故障已修复。
## 输出
1. 故障概况：主题、记录日期、已确认现象及已知影响；缺失项写“未提供”。
2. 已确认安排：列出明确的处理范围、计划和不执行的操作。
3. 行动清单：任务、负责人、完成日期、原文依据四列表格。
4. 待确认问题：根因假设、信息缺口及冲突；没有依据时不补造任务。
用户要求保存时，输出到指定位置的 Markdown 或文本文件；否则直接回复。生成 Word 文件需要相应文档工具。
交付前核对姓名、日期、证据与行动项，确保“计划验证”没有写成“已经恢复”。10.4 安装并显式调用
在独立演示项目中放置：
故障技能演示/
├── 故障记录B.txt
└── .agents/
└── skills/
└── incident-action-items/
└── SKILL.md故障记录B.txt 来自本章独立配套资料。不要复制结果核对说明到技能目录，以免技能依靠预先提供的答案。
在 Codex 打开该项目，通过技能列表确认 incident-action-items 可见；CLI 或 IDE 扩展可以输入 $ 选择。未发现时先检查目录和文件名，必要时重启。官方发现与调用说明
在 Codex 对话中输入：
$incident-action-items
请处理当前项目中的故障记录B.txt，将结果保存为“故障整理B.md”。这不是 PowerShell 命令。使用 WorkBuddy 时，沿用第八章的导入与选择方式，按当前客户端支持的包结构处理，不假设两款软件的安装入口完全相同。
观察技能文件是否被读取，再打开生成结果核对。仅看到文件名或一句“已使用技能”，不能替代执行与内容检查。
10.5 用原始输入和补充信息展示复用
原始记录：检查提议与日期冲突
使用本章故障记录B，应得到：
| 任务 | 负责人 | 完成日期 |
|---|---|---|
| 整理两份JSON样例 | 小陈 | 2026-10-16前 |
| 检查中文CSV导出 | 待确认 | 待确认 |
| 整理排查说明 | 待确认 | 2026-10-17与2026-10-18存在冲突 |
自动重发支付回调明确本次不做，不能列为待执行任务。原文没有生产修复时间或已确认根因。
补充后的输入：检查最终决定
新建会话提供同一份记录，并明确补充：
使用incident-action-items处理故障记录B.txt。
补充已确认的最终决定：排查说明由周工负责，最终交付日期为2026-10-19，
该决定取代原记录中的两种日期说法。其他安排保持原文。
另存为故障整理-补充后.md，保留原始文件和此前结果。“整理排查说明”应更新为周工、2026-10-19；JSON样例和CSV检查不变。只有明确最终决定才能消除冲突，技能不能自行选择日期。复用的是处理方法，不把本次姓名与日期写进技能。
10.6 发现问题后，修改对应规则
如果模型把建议者写成负责人，先对照原文与技能，确认规则是否被读取和遵守。规则确实缺失时，可以补充“提出建议不等于承担任务”；本章提供的完整版本已经包含这一条。
如果文件没被发现，应检查目录和元数据，而不是不断往正文加要求。若技能正确读取、规则明确仍执行错误，再考虑提示、模型表现和输入歧义等因素。
修改技能后重新使用原始记录与补充后的输入检查，观察原有正确结果是否保持。不要直接把这两种输入的答案写进技能，让它只能通过已知样例。
本章资料已提供完整技能源文件，结构校验与客户端行为验证需要分别看待：校验能发现格式问题，不能证明模型一定按规则执行。配套核对说明列出预期，操作时再记录实际结果。
下一章将用 Agent 辅助创建和修改 Skill，重点观察如何表达制作需求，以及怎样审查自动生成的文件。