Agent Skills 系列（7）：制作你的第一个 Skill？先用「选型向导」诊断你的高频痛点

📌 系列说明

如果你已经认同「规范不该靠每轮对话重讲一遍」（见第 1 篇），也清楚 SKILL.md 怎么写、怎么装（见第 2、3 篇），甚至了解了什么值得做成 Skill 的黄金三原则（见第 4 篇），接下来的问题非常实际：在你的具体业务场景下，你最该优先制作的第一个 Skill 是什么？

🔍 为什么你很难定下第一个 Skill

万事开头难。在接触 Agent Skills 概念时，我们往往会陷入两种极端：

1. 大而全的幻想：试图写一个「万能开发规范 Skill」，把代码风格、Git 提交、接口定义、测试规范全部塞进一个文件。结果是 description 过宽，导致模型在不需要的时候频繁触发，或者因为上下文过载而选择性忽略关键规则。
2. 无从下手的空白：觉得自己的项目「挺简单的」，似乎没有什么特别需要规范的地方，直到在日常对话中一次次因为包管理器用错、目录建错、或者模型手算对账出错而反复打字纠正。

好的 Skill 应该符合重复、稳定、可执行三条标准。但每个人的角色不同、系统不同、痛点不同，最迫切需要固化的「数字资产」也完全不同。

为了帮你快速诊断，我们把之前的选题经验、官方构建指南以及非技术场景的想象力扩展，浓缩成了下面这个**「Skill 选型向导」**交互工具。

🛠️ 在线诊断：Skill 选型向导

请在下方根据你的实际工作角色和环境进行选择，向导会实时计算并生成最适合你当前业务的 Skill 推荐清单，并支持一键导出为 Markdown。

🚀 拿到推荐清单后，如何开始第一步

向导会根据你的选择，将推荐的 Skill 划分为三个优先级：

• P1（高优先级）：这是你本周最该落地的最小可行性版本（MVP）。它们通常对应你每天都在重复打字纠正的高频痛点。
• P2（中优先级）：可以作为你下阶段的迭代目标，或者将它们作为大块的参考材料放进 references/ 目录中。
• P3（低优先级）：适合在团队协作规模扩大、或者系统复杂度提升时，作为渐进式披露的补充规范。

1. 先生 Skill，再写代码

如果你正在开启一个新项目（Greenfield），千万不要等项目写完了再去补 README。在写第一行代码之前，先把向导推荐的 2～3 个高频 Skill（如团队默认值、脚手架规范）写好并安装。这会帮你省下大量的团队沟通和模型纠错 token。

2. 宁窄勿宽，用例驱动

在起草你的第一个 SKILL.md 时，正文保持在 50~100 行即可。最重要的是把 description 写得足够精确。

• 反例：description: "Help with frontend development"（过宽，会导致任何前端任务都触发它，抢占上下文）。
• 正例：description: "Use this skill when creating a new list page or table component in this project"（极窄，只有在新建列表页时才触发）。

3. 善用 references/ 渐进式披露

不要把长篇累牍的 API 接口定义、完整的错误码表、或者几百行的设计 Token 塞进 SKILL.md 的正文。把它们丢进 references/ 目录，在主文件里只写索引和「何时去读哪份文件」的规则。模型会在需要时自动去读取这些厚文档，从而在日常对话中保持上下文的干净。

🎨 非技术岗位的想象力边界

在向导底部的**「思路库」**中，我们为市场、销售、创始人、创作者等非技术角色列出了许多无法穷举但极具落地价值的思路。

非技术 Skill 同样遵循「窄 description + 触发测试」的逻辑。例如，一个创作者的「视频脚本 Playbook Skill」，它的 description 应该写成 Trigger when writing or editing video scripts for the tech column。这样，当你让模型帮你写周报或日常邮件时，它绝对不会跑来用视频口播的语气来折磨你。

把那些你每次都要叮嘱模型的「品牌语气」「禁用词」「报价单必填项」固化下来，让它们成为你一人公司或日常办公的数字化资产。