第 11 章：用 Agent 辅助制作与改进 Skills
本章让 Agent 根据设计说明起草 Skill，再检查生成的名称、描述、正文和资源引用。创建技能文件与运行技能处理业务是两个独立步骤。
11.1 让 Agent 创建技能，要先给什么
不只说“帮我做一个技能”
如果只提出“做一个办公技能”，Agent 需要猜测适用任务、输入格式、输出文件和处理规则，容易生成范围很大但难以使用的说明。
可以先提供四类材料：
| 材料 | 本章使用什么 |
|---|---|
| 工作目标和范围 | 第九章的订单巡检报告技能设计说明 |
| 真实输入结构 | 第三章的五张CSV与业务口径 |
| 理想输出要求 | Excel清洗、异常、汇总、公式图表；Word核对报告 |
| 容易出错的情况 | 重复记录、编号冲突、反馈缺失、输入格式不匹配 |
这些材料已经存在，不需要从头口述。本章配套创建需求单把它们整理成可直接使用的输入。
先把资料复制到独立演示文件夹，避免让创建过程改动整套课程。创建需求与实际业务输入要区分：这次要生成的是技能文件，运行技能后才会生成办公成果。
样例用来说明规则，不能代替规则
本批已支付口径6,352单只是固定样本结果。技能应写清清洗与状态口径，不能固定答案。
同样，第四章 Python 程序读取去重后的 JSON，而本案例输入是含重复、冲突及关联关系的多张CSV。让 Agent 复用代码之前，应先说明这个差异。
11.2 在 WorkBuddy 中辅助创建
WorkBuddy 官方技能页面提供“创建技能”入口，可通过描述需求开始创建流程。具体位置按操作时客户端显示为准。WorkBuddy 技能说明
进入创建入口，提供本章需求单和相关资料，输入：
请根据“创建需求单.md”和“订单巡检报告技能设计说明.md”，
创建订单巡检报告技能，名称使用 order-inspection-report。
“输入资料”目录中的CSV与口径文件是输入示例，不要把示例中的数量写成固定结果。
本轮先生成技能说明初版，写清适用条件、输入、输出、步骤和异常处理。
不要生成不存在的脚本引用，也不要虚构文档工具或技能名称。
明确运行时需要具备的 Excel、Word 文件生成与检查能力。
创建完成后展示实际生成的文件，以及仍需要准备的运行条件。
本轮不执行订单分析，不生成办公成果。如果创建器询问关键信息，先查看需求单是否已有答案。输出位置、适用范围等会影响结果的问题，应明确回答；已有资料没有说明的功能，不必为了填满模板而增加。
创建完成后，查看实际文件或可导出的技能内容。自动出现在技能列表中，只能说明它被登记或发现，不能证明生成的 Excel 和 Word 一定正确。
11.3 在 Codex 中使用技能创建能力
Codex 官方文档提供 $skill-creator 调用方式，可以通过自然语言描述技能需求。官方创建说明
在 Codex 对话中选择该技能，输入：
$skill-creator
请读取当前工作空间中的创建需求单.md、订单巡检报告技能设计说明.md和输入资料目录中的CSV与口径文件。
在当前工作空间的 skill-drafts/order-inspection-report/ 中创建技能说明初版。
使用 name 和 description 元数据，正文包括输入、处理规则、输出和检查要求。
本轮不添加脚本或办公模板；不引用未提供的资源。
不要写入用户级技能目录，不修改模型配置，不执行本次业务任务。
生成后说明每个文件的用途、执行所需条件和未验证事项。这里指定普通草稿目录，是为了先查看内容再按第八章的方法安装。该目录不是自动发现路径，仅生成文件不等于已安装。
不需要在两款软件中各制作一套完全相同的技能。可以选择一款软件完成创建，再比较另一款的入口和需求表达方式。Codex 使用 OpenAI 或 DeepSeek 路线时，都按同一份需求检查结果。
如果创建器额外生成了界面元数据，先查看它控制的显示或调用设置；不要把它误当作业务执行脚本，也不要要求所有客户端具有相同的附加文件。
创建器与生成的技能
skill-creator 自身也是一项技能，负责指导创建过程；order-inspection-report 是本次要生成的业务技能。前者帮助组织文件，后者负责以后处理订单巡检资料。
审查时先看磁盘上的实际文件，再决定安装范围。创建器返回“完成”后，仍需确认正文没有引用不存在的脚本，也没有把样例答案保存为规则。
11.4 生成之后，重点审查什么
先看范围和触发描述
适用描述应该围绕本次任务，例如：
根据约定格式的电商订单与反馈资料生成Excel交易核对工作簿和Word核对报告，用于电商订单分析及配套办公文件交付。
如果描述变成“处理所有办公、编程、营销与数据任务”，范围就偏离了设计。用户只想润色一段文字时，不应被带入完整的订单统计流程。
再看资源和执行条件
检查正文提到的文件、工具与命令是否真实存在。例如，它写“运行 scripts/report.py”，但目录里没有该脚本，就不能算完整的可执行流程。
本轮只创建说明初版。说明可以写“检查环境中是否具备 Excel 和 Word 生成能力”，但不能写“已自带完整文档工具”，除非确实提供并验证了对应资源。
最后看数据规则和成果要求
| 要检查的地方 | 合理要求 |
|---|---|
| 去重 | 同编号且字段一致才合并，冲突另行处理 |
| 已支付口径 | 包含已支付与已发货，不含待支付和已取消 |
| 反馈 | 未提供就说明缺失，不补写满意度结论 |
| Excel | 公式引用明细，图表引用汇总，检查计算结果 |
| Word | 数字与已核对的统计一致，事实与建议分开 |
| 交付说明 | 区分已完成、失败和未验证事项 |
不能只检查 Markdown 看起来是否整齐。影响结果的业务口径、资源和依赖更值得逐项核对。
11.5 用具体问题推动修订
配套审查与修订示例提供了几段故意设计的错误说明，用于展示。它们不是某次客户端真实失败记录，也不应该安装成技能。
示例一：把样例答案写死
假设初版写成“已支付口径固定显示6,352单”，可以反馈：
初版把本次样例的6,352单写成了固定规则。
请改为按清洗后的可用订单计算，包含“已支付”和“已发货”。
样例数量仅用于检查，不得用于替代计算。
修改后检查正文是否还有其他固定姓名、商品名称或数字被误作通用规则。示例二：同编号冲突被静默丢弃
假设写成“同编号只保留第一条”，可以反馈：
设计说明要求区分完全重复和同编号冲突。
请改为：字段完全相同才合并；同编号内容不一致时隔离全部版本并列出差异，明确统计范围。
保留隔离清单，不把可用订单统计冒充全部原始业务。
修改相应步骤和检查要求，不扩展其他业务功能。修改后再检查，而不是不断加句子
让 Agent 同时查看旧规则与新规则，避免正文前面要求“保留第一条”，后面又要求“隔离全部版本”，造成互相矛盾。
触发范围有问题，优先修改描述；执行规则有问题，优先修改正文；工具缺失则准备依赖或收窄能力范围。不要把所有问题都塞进 description。
只修订实际存在的问题；规则正确的部分保持一致。
11.6 从说明初版到可用技能
先做文件检查，再做实际调用
首先确认元数据、引用路径和规则一致性。准备好运行环境后，在独立演示项目安装技能，用第三章资料执行一次，核对8,150行原始订单、7,930条可用订单、6,352单已支付口径以及79单支付异常。
接着换一个变化输入，例如删除反馈部分，观察是否仍能正常统计并说明缺少反馈。核对标准单独保留，不作为生成业务成果时的输入，以免直接照抄答案。
如果暂时没有办公文件生成或公式计算工具，就明确记录为“说明已生成，执行条件未齐备”，继续完善资源。不能把生成说明文件描述为完成了 Excel 和 Word 交付。
手工制作和辅助创建各有什么价值
手工制作帮助理解每一部分的作用；辅助创建减少初稿整理工作。两种方式最终都需要检查业务规则，并用实际输入验证。
以后可以复用本章的需求单结构：任务、适用范围、输入、输出、规则、依赖、检查方法。复用的是描述需求的方法，不是把每个技能写成相同长度和相同复杂度。
下一章开始加入参考资料、模板和 Python 脚本，让需要稳定计算与格式控制的步骤有具体资源可用。