从想法到作品 / 章节 05
第五章｜把好用的方法变成 Skill
读完这一章，你可以
把重复的小游戏检查方法写成一份 Skill，并验证它是否有效。
前面我们做了几轮检查：先看玩法约定，安排操作，记录现象，修改之后再回归。现在你可能会发现，每次让 Agent 检查作品，都要重新解释这一套。
项目说明能保存目标和约定。如果想把一整套工作方法带到不同任务中，Skill 就很合适。我们先看官方的小例子，再把游戏检查流程整理成自己的版本。
先用一个小例子认识它
Agent Skills 官方入门材料中的掷骰子案例很短：准备一个 SKILL.md，说明什么时候使用、怎样调用随机数命令，然后让 Agent 掷一次骰子。
这个例子容易观察：Agent 是否找到了技能，是否读取说明，是否真的运行相应命令，返回了什么结果。它帮助我们理解 Skill 在工作中的位置。
Skill 可以包含工作步骤、参考资料、脚本和素材。通常先由名称与描述告诉 Agent“有什么能力、什么时候该用”，需要时再读取正文和相关资源。这就是按需读取技能的基本思路。
对使用者来说，先记住两件事：技能要能被工具发现，描述要让 Agent 判断出适用场景。文件放错位置与描述过于含糊，都会影响使用。
从网页检查理解技能的分工
我们前面的实际需要是检查游戏。Anthropic 的 webapp-testing 是一个参考：它把检查本地网页的方法、辅助脚本与使用示例组织在一起。
理解一份检查技能时，可以先问三件事：它处理什么任务，执行时会使用什么能力，需要哪些环境或文件。选择技能时，把这些条件与当前项目对上。
这份技能使用 Python Playwright 脚本与网页交互。下一章使用的 Playwright MCP 则通过工具接口控制浏览器。二者解决问题的入口不同，读到相关名字时可以先记住：Skill 组织方法，具体行动还需要工具和环境来执行。
沿着这个思路，我给大家准备了一份短小的游戏检查技能，文件已经放进资料包，下面直接练习加载与调用。
把当前流程写成一份 Skill
配套文件在 playable-review/SKILL.md。它围绕我们已经讨论过的游戏检查工作组织内容：读取玩法、安排场景、记录现象、排序问题、给出下一步。
最小结构是：
playable-review/
└── SKILL.md文件顶部放名称和描述，正文写处理方法。例如：
---
name: playable-review
description: 检查可运行小游戏的玩法与交互，按需求安排试玩、记录复现步骤并整理修改建议。适用于游戏初版体验、功能修改后的回归检查和问题整理。
---name 让我们引用它；description 解释任务匹配关系。名字可以简短，描述要具体到能与其他任务区分。正文再说明怎么做，不要把一整套步骤挤进描述里。
结构和字段可以回看技能说明与例子。先做一个自包含的小文件，等确实出现较长资料或重复脚本，再拆出其他目录。
放进当前工具，让它被发现
在 ZCode 中，可以通过设置中的技能管理入口查看、新建和启停技能。按官方说明添加文件后，刷新列表，先确认名称出现，再引用它处理任务。用户级技能与项目级技能影响的范围不同，当前练习可先限定在自己的项目中。ZCode Skill 文档给出了目录与导入方式。
如果使用 DSH 或其他工具，就按它的技能入口与目录约定添加。同一个技能内容可以理解和迁移，实际发现位置要与客户端匹配。
安装完成后，先明确调用。ZCode 可以在输入框输入 $ 选择技能，再补充当前任务：
$playable-review
请检查当前贪吃蛇的速度选择、暂停和重新开始。
先读玩法约定，列出准备检查的场景，再根据实际操作整理结果。
本轮先给出问题和修改建议。这次调用中，Skill 提供检查方法，后面的文字提供本次对象和重点。把二者结合起来，才能避免每次都生成同一份空泛清单。
怎样看出它用上了
可以观察技能读取记录，也可以让 Agent 先说明采用了哪套流程，再查看它的实际行动与输出。对于这份例子，输出应能对应到游戏中的场景和现象：怎样操作，预期什么，看到什么，接下来建议改哪里。
只有一份格式漂亮的报告还不够帮助我们继续开发。比如“加强用户体验”很难执行；“暂停后点击重开，按钮仍显示继续”就可以转成明确任务。
如果没有调用，先检查它是否出现在技能列表、是否启用、文件格式是否完整。若明确引用能用而自然任务不触发，再看描述是否写清场景。每次只调整一个相关因素，再用同一条任务试，比较前后变化。
通用指令、快捷命令与 Skill 怎样分工
我们已经有了三种保存信息的方式。可以沿当前项目理解：
| 需要留下什么 | 可以放在哪里 |
|---|---|
| 项目入口、运行方式、当前玩法约定 | 项目说明与工具支持的项目指令文件 |
| 一句经常发送的任务，例如“总结今天改动” | 工具提供的快捷命令或模板 |
| 检查小游戏的一套步骤、判断和输出方法 | Skill |
同一个内容先放到最合适的地方。项目事实经常随版本变，检查方法可以跨版本复用；技能运行时再读取项目事实，就不必把每个版本的细节都写进技能。
例如，轻松档的具体速度属于游戏配置；“检查不同档位下的开局和重开”属于检查方法。分清这两层，技能更容易持续使用。
换个游戏，沿用方法
- 01读玩法
- 02安排试玩
- 03记录现象
- 04整理建议
怎样把它改成自己的版本
第一次使用之后，找一个真实缺口调整。假设它只检查开始和结束，却漏了暂停恢复，就补上相关场景；若输出问题太多、看不出先后，可以要求按“阻断玩法、影响体验、可选改进”组织，并依据影响说明理由。
修改后用同一份游戏与同一项任务再试，观察是否补上了缺口。每次改动都有使用经历作为依据，技能就会逐渐变得贴合自己。
Agent Skills 的编写建议也强调这一方向：从真实工作或已有材料中提炼，再根据执行结果完善。你前面和 Agent 讨论过的纠正、输入输出和检查步骤，都是很好的起点。
练习：提炼一项重复工作
从自己的学习或社团事务里选一件反复做的事，写清输入、处理方法、输出、适用场景。可以是整理活动通知、检查报名信息，或按固定要求审阅一份材料。
先判断：它是一句快捷提示，还是需要多步骤处理的技能？再写一个有具体适用场景的描述，试着用两条相关任务和一条无关任务检查触发范围。
想好以后，看看参考思路
参考思路：如果“整理活动通知”需要提取时间地点、识别缺失信息、形成统一格式，它适合有一套方法；“把这一句改短”通常直接发任务就可以。
现在我们已经留下了检查方法。下一步很自然：Agent 怎样真正打开游戏，点击按钮，读取日志，把检查做起来？这就轮到工具连接了。
停一下，检查自己的理解
RECALL / 一分钟回忆
先凭自己的理解选一项，再看解释。