Appearance
Skill 推荐与选型
选择 Skill 不应该从“装多少个”开始，而应该从任务稳定性开始。Skill 的收益来自重复和约束：同类任务越常见、流程越固定、返工代价越高，越值得沉淀成 Skill。
先判断是否需要 Skill
| 任务特征 | 建议 |
|---|---|
| 偶尔做一次，目标还在探索 | 先用普通提示词 |
| 经常重复，但步骤简单 | 写成项目文档或检查清单 |
| 经常重复，且容易漏步骤 | 适合 Skill |
| 需要调用外部系统 | Skill + MCP 或本地工具 |
| 需要人工确认高风险动作 | Skill 中写清确认点 |
Skill 的位置介于“提示词”和“自动化系统”之间。它比提示词稳定，比完整系统轻量。
优先沉淀的几类 Skill
代码审查
适合把团队的高频 review 意见写进去，例如边界条件、异常处理、日志、权限、数据库迁移、兼容性。验收标准应包括“指出风险和文件位置”，而不是只说“代码质量不错”。
前端页面验证
适合写清设计约束、响应式检查、截图验证、文本不重叠、交互可用等规则。它的价值在于让 Agent 不只改 CSS，还能用浏览器验证实际效果。
文档改写
适合写清文档口吻、结构、禁用套话、图示要求、导航入口和构建验证。本站这类技术文档就很适合沉淀文档 Skill。
测试补齐
适合规定先读现有测试风格、再补边界用例、最后运行指定测试。测试 Skill 不应只生成 happy path，而应关注失败路径和回归风险。
发布说明
适合把 commit、issue、PR、影响范围、升级注意事项整理成稳定格式。它能减少发布前的机械整理工作。
选择现成 Skill 还是自建
| 选择 | 适合情况 | 注意点 |
|---|---|---|
| 现成 Skill | 通用任务，例如浏览器操作、摘要、测试思路 | 先审内容和权限，不要盲装 |
| 项目 Skill | 项目规范强，例如目录结构、构建命令、文档风格 | 应跟仓库一起版本化 |
| 团队 Skill | 多项目共享，例如安全审查、发布流程 | 需要维护版本和适用范围 |
现成 Skill 解决通用能力，自建 Skill 解决“这个团队怎么做事”。长期看，真正拉开差距的是自建规则质量。
评估一个 Skill 是否好用
| 维度 | 判断问题 |
|---|---|
| 触发明确 | Agent 是否知道什么时候用 |
| 范围克制 | 是否只服务清晰场景 |
| 步骤可执行 | 是否能按步骤操作，而不是只讲原则 |
| 禁区具体 | 是否写清不能做什么以及原因 |
| 验收可查 | 是否有命令、截图、测试或清单验证 |
| 可维护 | 是否能随着项目变化更新 |
如果一个 Skill 只有宽泛建议，没有输入输出和完成标准，它更像提示词片段，不像工程资产。
装配顺序
更稳妥的顺序：
- 先补一个项目说明类 Skill 或文档，告诉 Agent 技术栈、命令、目录、禁区。
- 再补高频任务 Skill，例如测试、文档、前端验证、代码审查。
- 最后接入外部工具类 Skill，并审查权限。
不要一开始安装大量重叠 Skill。触发条件重叠会让 Agent 在规则之间摇摆，反而降低稳定性。
维护节奏
- 重复出错两次以上，就把规则写进 Skill。
- Skill 长到难读时，把背景材料放到 references 或项目文档。
- 技术栈升级后，更新命令、路径、禁用规则和验证方式。
- 长期不用的 Skill 应删除或迁出默认加载范围。
总结
Skill 选型的核心不是数量，而是任务是否重复、边界是否清楚、验收是否可验证。通用能力可以先用现成 Skill，项目习惯和团队标准应尽早自建。一个好 Skill 应能让 Agent 少问、少猜、少返工。