企业官网建设流程全解析

最近只要打开技术社区，十有八九能看到一个词：skills。前两年大家还在研究怎么把提示词写得更长更细，今年风向突然变了，从 Claude Code 到 Codex、Cursor，几乎各家 AI 编程助手都在推技能包机制，社区里也冒出一堆诸如 superpower skills、baoyu skills 之类的仓库。如果你还没搞清楚这些 skills 到底是什么、跟平时往输入框里粘贴的 prompt 有什么区别、怎么开发自己的 skills，这篇文章会一次性讲透。我会从底层逻辑聊到完整实操，再穿插这半年我在真实项目里踩过的坑和使用经验，让刚接触的朋友能照着做，已经上手的朋友也能找到一些优化写法的新思路。

先说清楚一件事：这里的 skills 不是面试简历里写的“技能特长”，而是给 AI Agent 装的“工作方法包”。一个 skill 本质上是一组结构化的指令和资源文件，AI 在对话过程中会根据任务描述自动加载它，然后按照里面预设的流程去完成特定类型的工作。你可以把它理解成给实习生发了一本标准作业手册，而不是每次都在边上口头交代一遍。对用 Claude Code、Codex、Cursor 这类编程助手的开发者来说，skills 正在成为工作流里最值得投入的一部分，学会开发自己的 skills，相当于把高频重复的工作一次性沉淀下来，之后每次遇到同类任务都是稳定输出。

1. skills 不是简历技能，是给 AI 装上的“工作方法包”

1.1 从 prompt 到 skills：为什么提示词解决办法越来越不好使了

咱们先回忆一下过去两年大家是怎么用 AI 干活的。最早的玩法是人肉写提示词，每次要处理一个新任务，就在输入框里贴一大段身份设定、目标描述、步骤要求，运气好了 AI 能给你整个七七八八，运气不好它就会自由发挥，你得多轮纠正，搞到最后比自己做还累。后来有些经验的人开始整理个人提示词库，把常用的系统提示词存成模板，但这套做法有个致命问题：提示词只是“一次性输入”，Agent 每次会话都要重新理解一遍，一旦任务描述有偏差，或者换了个工具、换了模型，原先有效的措辞可能就完全失效了。

skills 解决的正是这个问题。它把工作流程从提示词里抽离出来，固化成一个独立的、可复用、可共享的模块。我在实际项目里做过对比，在同一个代码审查任务上，把原先 3000 多字的系统提示词改造成一个 skill 之后，不仅输出质量更稳定，对模型版本的敏感度也明显降低了。原因是提示词靠模型“临场发挥”来理解你的意图，而 skill 靠一套预设的检查流程和输出规范来约束模型行为，前者的成功率取决于模型的“心情”，后者的成功率取决于流程设计是否严谨。

1.2 SKILL.md 到底长什么样：一个文档加一堆资源

一个最小可用的 skill，核心是一个叫 SKILL.md 的 Markdown 文件。这个文件就是技能包的大脑，里面一般包含两大部分：头部的前置信息和正文的执行流程。前置信息通常包括技能名称、适用场景的 description 描述，正文则用清晰的步骤告诉 Agent 在什么情况下、按照什么顺序去做哪些事。

比如我本地写了一个“图片还原设计稿”的 skills，对应热词里大家都在搜的前端开发场景。它的目录结构长这样：

image-to-design/ ├── SKILL.md # 技能包主文件 └── references/ ├── frontend-stack.md # 前端技术栈偏好说明 └── design-principles.md # 还原设计稿时要注意的设计原则

SKILL.md 开头长这样：

--- name: image-to-design description: 当用户上传 UI 设计稿截图、网页截图或产品原型图，希望前端开发工程师将图片还原成可运行的页面代码时使用。适合从单张设计稿生成完整的 React/Tailwind 页面。 --- # 图片还原设计稿 1. 先全局观察设计稿，列出页面的整体布局结构，包括头部、导航、主内容区、侧边栏、底部等区域划分。 2. 分析视觉规范，提取主色、辅助色、文本字号、间距、圆角、阴影等设计 token。 3. 识别组件清单：按钮、输入框、卡片、弹窗、表格、图表等，逐一列出。 4. 按照用户指定的前端技术栈（默认 React + Tailwind）生成代码。 5. 生成代码时优先还原布局结构，再处理细节样式；移动端适配采用移动优先策略。

看到这里你就能理解了，SKILL.md 不仅告诉 AI “是什么”，更重要的是告诉它“按什么顺序做”。传统的提示词也会写步骤，但写完之后这些步骤就融化在长文里，模型很容易忽略掉细节；而 skill 文件被独立加载，模型读取它就是一套明确的流程契约，执行起来更接近“照着 checklist 打钩”。

1.3 skills 与 MCP、插件的关系：工具库和工序卡

很多朋友会把 skills 跟 MCP（Model Context Protocol）搞混，这也是社区里最常见的疑惑点。其实两者的定位完全不同。MCP 解决的是“AI 能调用什么工具”的问题，比如联网搜索、操作浏览器、读写数据库，这些都是 MCP Server 提供的能力；skills 解决的是“AI 接到任务后按什么流程干活”的问题，它描述的是工作方法，不直接提供工具能力。

我用一个比喻来解释：如果把 AI 助手比作一个新入职的厨师，MCP 就是厨房里安装好的各种厨具和电器——有烤箱、有搅拌机、有低温慢煮机，能力就摆在那里。而 skills 则是一份份菜谱，告诉他做红烧肉要先焯水再炒糖色，做蛋糕要先打发蛋白再翻拌面糊。没有 skills，厨师看到一厨房工具会手足无措；没有 MCP，再好的菜谱也没有工具可以执行。

所以实际使用中，两者通常是配合的。一个完善的 skill 可以在步骤中明确写出“调用某某 MCP 工具去获取网页内容”，也可以指定“使用某某命令来执行测试”，这就是 skills 调用 MCP 工具的典型用法，后面我们会详细拆解。

2. 动手写第一个 skills：从结构设计到完整示例

2.1 本地目录结构与会话配置：skill 放哪里才生效

先解决环境问题。不同的 AI 编程工具对 skills 的存放位置要求略有不同，但大方向一致：要么放在用户级目录，全局生效；要么放在项目级目录，只在对应仓库生效。

以 Claude Code 为例，全局 skills 放在~/.claude/skills/目录下，项目级 skills 放在.claude/skills/目录下。Codex 和 Cursor 也支持类似的结构，只是目录名称不同，有的叫.cursor/skills，有的叫.codex/skills。我个人的习惯是：通用型技能放在全局目录，比如“图片还原设计稿”“代码审查”“写测试用例”这些跨项目通用的都放全局；跟具体项目绑定的技能放项目目录，比如某个服务特有的部署流程、某个数据库的 Schema 分析流程。

还有一点容易被忽略：有些工具需要在配置里显式开启 skills 功能。我在第一次尝试时就在 Cursor 里找了半天没找到技能包入口，最后发现是新版本的配置项没打开。如果你配置完了技能不被加载，先回去检查这一项是否启用。

2.2 以“图片还原设计稿”为例拆解 SKILL.md 的编写思路

上面已经给出了一个简化版，这里我把完整的设计思路拆开讲，毕竟“给前端开发用的图片还原 skills”是热词榜上反复出现的高频需求，值得展开。

写一个图片还原类技能，关键不在于教 AI“看懂图片”——那本来就是多模态大模型的能力——而在于教它“如何有序地看懂，以及如何把看懂的东西转成代码”。我在设计这个技能时，花了最多时间在“信息提取顺序”上。如果让 AI 拿到图就开始写代码，它通常会盯着视觉最突出的部分做，结果就是色块差不多、布局细节全乱套。

完整的执行顺序我用了这几个阶段：

第一，整体结构识别。先要求 AI 用一两句话描述页面用途，然后把版面划分成区域层级，比如顶部导航、Hero 区、功能列表、页脚。每个区域都要写明它在整张图里的位置占比和大致边界，这一步相当于给后续编码画了蓝图。

第二，设计规范提取。这一步是新手最容易漏掉的。页面里按钮的圆角到底是 8px 还是 12px？主色是偏蓝还是偏青？标题用什么字号？这些信息如果不显式让 AI 去提取，它就会凭训练数据里的“平均审美”来猜，虽然第一眼看起来不差，但跟原稿一比对细节就会露馅。我在技能里让 AI 把所有提取到的色值、字号、间距、圆角、阴影整理成一份 design tokens 列表，之后再写代码时就全部从这份 tokens 里取，不走“想象力”。

第三，组件清单梳理。把图像里出现的每个 UI 组件都列出来，标注状态（默认态、悬停态、选中态）。做这一步是为了避免在代码实现时漏掉交互细节。

第四，编码实现。按照提取出的结构和 tokens 写代码，并且在 SKILL.md 里强调：优先保证结构正确，不要一开始就陷入圆角是不是差 1px 这类细节；遇到图片和图标资源用占位符加注释说明，方便开发者后续替换。

第五，移动端检查。还原稿不仅要适配桌面端，还要在步骤里规定：如果设计稿只有桌面版，AI 必须额外输出一套移动端布局建议，并且解释响应式断点如何设置。

你看，一个 skill 的质量高下，其实就取决于你有没有把这些“老师傅脑子里默认知道的事”逐条写出来。

2.3 编写时最容易踩的三个坑

第一个坑是 description 写得太宽泛。这是加载失败的头号原因。比如“当用户上传图片时使用”这种描述，看似没问题，实际模型要在一堆 skill 里做选择，它无法判断这个技能到底解决什么具体需求。我的建议是：description 里写清楚输入是什么、输出是什么、典型场景是什么。好的描述大概长这样：“当用户上传 UI 设计稿截图、网页截图或产品原型图，希望还原成可运行的前端页面，使用该技能，输出 React/Tailwind 代码和设计规范说明。”这段描述信息密度高，模型一看就知道该不该调用。

第二个坑是步骤数量失控。有的技能把流程拆成二十多步，每一句都像法律条文，结果 AI 执行到中间就忘了前面，甚至开始自作主张跳过某些环节。我实践下来，一个 SKILL.md 的正文步骤建议控制在 5 到 10 步，每步一句话说清楚目标和完成标准即可，重点信息可以放在 references 目录的文档里，让模型按需翻阅，而不是一股脑塞进主文件。

第三个坑是写死了工具链。有些开发者在 skill 里直接指定“必须使用某某库 xxx 版本”，这在你自己环境里没问题，一旦共享出去，别人没有那个依赖就完全跑不动。更灵活的做法是给出推荐方案加上备选方案，比如“优先使用 Tailwind CSS，如果没有 Tailwind，可以使用普通 CSS Modules”这种表达，让技能在不同项目里都能落地。

3. 场景实战：查资料、生成 PPT、写测试用例与前端辅助

3.1 网页查资料型 skills：怎么防止 AI 编造来源

热词里反复出现“claude code 网页查资料的 skills”，可见很多人最需要的不是写代码技能，而是让 Agent 学会正确地查资料。这个需求其实很典型：Claude Code 这类工具默认不能上网，需要接一个联网搜索的 MCP 服务才能获取网页内容。但“能上网”和“会查资料”是两回事，我把这个技能的设计逻辑拆给你看。

我在 skills 里给 AI 定义的流程是：先明确用户要查的问题，拆分出关键词；第二步通过 MCP 搜索工具获取搜索结果的标题和摘要；第三步打开 2 到 3 个相关性最高的页面，完整阅读正文；第四步把关键信息逐条摘录，并记录来源 URL 和发布日期；最后一步，生成回答时必须把来源链接作为引用附上。这里面最关键的约束在第四步和第五步：我不允许 AI 在没有实际打开过某个页面的情况下引用那个页面。这样能有效遏制编造来源和幻觉，也是“利用 MCP 工具但不被工具带偏”的核心写法。

有朋友会问，为什么不直接把“从某某网站上查一下”写进 skill 里？因为在不同的 MCP Server 里，工具名称差异很大，有的搜索工具叫web_search，有的叫search_web，有的还要求传 region 参数。我的经验是，在 SKILL.md 中不要写死具体工具名，而是写“使用你当前环境中可用的搜索工具”，这样换一个 MCP 配置也能跑通。

3.2 生成 PPT 和文档类 skills：从大纲到备注的完整链路

热词里“github claude code ppt skills”上榜，说明很多人想让 AI 直接把一个主题扩写成 PPT。市面上有不少自动化 PPT 生成方案，但真正稳定可靠的是让它先输出结构化大纲、再调用接口生成文件，而不是寄希望于 AI 自己打开软件去排 Excel。

我在 PPT 类 skill 里设定了这样的产出步骤：第一步，根据主题和受众，明确演示的核心目标和信息层级，先产出目录页大纲；第二步，将大纲细化成每一页的标题和要点，每页要点不超过 4 条，每条不超过 15 个字，防止页面上文字过多变成“演讲者念稿”；第三步，为每页写出演讲备注，长度在 50 到 100 字之间，让 AI 的作用从“排版员”升级为“内容顾问”；第四步，根据大纲生成 PPT 文件或对应的 JSON 数据，供渲染工具读取。

这个技能的灵魂在第二步和第三步。大多数 AI 生成的 PPT 之所以难看，不是因为排版工具不够好，而是内容组织太松散、信息根本没有分层。你在 skill 里把信息层级规则定死了，产出质量才能稳定。同理，写文档类技能的思路也是一样的，先定结构、再填内容、最后统一格式，三个步骤缺一不可。

3.3 测试用例编写 skills：把“测试思维”变成可执行步骤

很多测试同学也许觉得自己用不上编程助手的 skills，其实恰恰相反，恰恰是这个岗位最适合把重复劳动技能包化。以“接口测试用例生成”为例，我在技能里预设了这样的思维框架：先读取接口文档，列出请求方法、路径、参数类型、必填项、默认值；然后按等价类划分正常场景，再按边界值划分边界场景，再补充异常场景，包括参数缺失、类型错误、超长字符串、未授权访问等；最后还要加入业务规则相关的用例，比如订单状态下不允许重复支付这类状态机逻辑。

这个 skill 的难点不在于“写用例”，而在于让 AI 学会按优先级排列测试场景。我的做法是在 SKILL.md 里定义一个用例优先级映射规则：影响核心业务流程的不论出现概率多低都是 P0；常见输入边界和异常输入是 P1；不常见的冗余异常是 P2。AI 按这个规则去生成用例，最终产出的用例集才有真正的工程指导价值，而不是给领导汇报时用来凑数的。

3.4 前端开发常用 skills 与移动端场景

回到热词里反复出现的前端和移动端，我简单整理一下大家用得最多的几类。除了前面说的图片还原，前端场景里最受欢迎的是组件代码生成类技能，比如“生成一个可复用的表单组件”和“分析现有代码并重构为规范写法”。这类技能通常会把团队的项目规范、命名约定、目录结构预置进 skill 里，让 AI 生成的代码从一开始就符合团队口味。

移动端 H5 开发跟桌面端有一些差异，如果不特殊说明，AI 经常忽略触摸事件、扫码、iOS 安全区域、刘海屏适配这些问题。我在移动端相关技能里加了一条硬性规则：输出页面时必须为底部安全区预留env(safe-area-inset-bottom)适配，所有可点击区域的最小尺寸不低于 44x44pt。这类细节看起来很小，但少了它，生成的页面拿到手机上根本没法用。把这些经验沉淀到 skill 里之后，整个团队的 AI 生成代码质量会瞬间上一个台阶。

4. 在 skills 中调用 MCP 工具：给 Agent 装上“手和眼睛”

4.1 为什么要在 skill 里调用 MCP：纯指令解决不了的问题

很多朋友第一次接触 skills，会好奇为什么不直接给模型塞一个“查资料”的指令就完事了。原因前面已经提过，查资料这个动作涉及具体的工具调用，模型本身没有执行这个动作的能力，必须借助外部的 MCP Server。同样的情况还有操作浏览器、读写本地文件、连接数据库、发送请求等，这些都属于工具能力，而 skills 的价值就在于把“何时调用什么工具、拿到结果之后怎么处理”这套决策流程固化下来。

举个例子，我的“竞品分析”技能里写了一个分支判断：如果用户给出的是竞品网址，就调用浏览器 MCP 打开页面并提取文本；如果用户只给了公司名，就调用搜索 MCP 找官网、报告、新闻稿。这个分支看起来毫不起眼，但它代表了 Agent 处理任务的关键智慧——不是无脑调用工具，而是根据输入自动选择最合适的工具组合。

4.2 如何在 SKILL.md 里写 MCP 调用的具体逻辑

在 SKILL.md 里描述 MCP 调用，不需要写代码，而是用自然语言把调用时机和工后处理讲清楚。通常我会在相关步骤后面加上一段“工具使用说明”。比如：

### 获取网页内容 1. 根据用户提供的 URL，使用你环境中可用的浏览器工具（例如 browser_navigate、page_content 等，以实际工具名称为准）打开页面。 2. 页面加载完成后，优先提取正文文本，忽略导航栏、弹窗、广告区域。 3. 如果页面内容被登录拦截，尝试读取页面标题和 meta description，并在结果中注明“内容为空，可能被登录墙拦截”。 4. 将提取出的文本整理成摘要，保留关键数据点，注明页面来源和访问时间。

注意，我在这里没有写死任何工具名，而是给了“以实际工具名称为准”的提示。这么写的原因很简单：MCP Server 不同，工具名差异巨大，硬编码会直接导致技能在其他环境失效。更聪明的做法是让模型自己去发现环境里有哪些工具，根据名称判断哪个适合当前场景。你在 skill 里给的判断标准越清晰，模型选对工具的概率越高。

4.3 调用 MCP 工具时最容易翻车的三个细节

第一个细节是鉴权问题。部分 MCP 工具需要 API Key 或本地 Token，如果环境变量没配好，模型调用时会报权限错误。这类问题最坑的地方在于报错信息可能被模型解释成“网络问题”或者“网站不支持”，然后它就开始编。我的对策是在技能里加一条指导：“如果 MCP 工具因为权限或认证返回错误，请如实告知用户需要检查哪些环境变量，不要编造替代数据。”这条规则虽然简单，却有效避免了最危险的幻觉。

第二个细节是超时问题。浏览器类 MCP 操作真实页面，耗时通常很长，几十秒甚至一分钟都有可能。模型在等待过程中如果没收到明确说明，可能出现重复调用，白白浪费 token。我在技能里会写明“页面加载可能需要 20 秒以上，调用后等待结果，不要重复触发同样的导航操作”。

第三个细节是工具返回结果太大。一个网页的全文可能有几万字，直接全量塞给模型会撑爆上下文窗口。这也是为什么我在技能里要求“优先提取正文文本，忽略导航弹窗等无关区域”，同时还要求做摘要整理而不是原样保存。

5. 进阶场景盘点：学术研究、数学建模与安全测试类 skills

5.1 学术研究类 skills：从文献检索到综述输出

学术研究类技能在社区里也很热，相关热词“academic research skills”直接上榜。这个场景跟网页查资料很像，但对信息准确性和引用规范的要求更高。我给学术场景写的技能包含这么几个阶段：选题拆解、关键词扩展、文献检索、全文精读、信息抽取、综述撰写。

每个阶段都有细致的约束。比如文献检索阶段，我会让 AI 借助学术搜索 MCP 工具按标题、摘要、年份排序；同时只保留近五年的论文，除非有经典文献背景铺垫的需要。在综述撰写阶段，我会要求它区分“作者观点”和“论文实验发现”，不能混为一谈；引用的每一条结论都必须对应到真实的论文条目，并且附上 DOI 或者出处链接。学术写作最忌讳的“凭空捏造引用”，通过这类设计能大幅降低发生概率。

5.2 数学建模类 skills：把比赛流程沉淀成固定套路

数学建模是另一个高频搜索场景。每年各种建模竞赛季，都会有大量同学在找“skills 推荐”。数学建模赛题通常时间紧、任务重，最大的痛点是：队伍里负责编程的人、负责建模的人、负责写论文的人经常信息不同步，AI 生成的结果跟论文模型还经常对不上。

数学建模类 skill 可以解决一部分这种问题。我设计过一套建模工作流：先读题并提取约束条件，建立问题假设清单；然后根据问题类型推荐候选模型，比如优化类问题用整数规划或启发式算法，预测类问题用回归或时间序列模型；模型确定后要求 AI 先写一个“模型验证计划”，用样例数据跑通之后再全量运行；最后把模型公式、参数含义、运行结果整理成一个“论文公式附页”，方便论文组直接引用。这套流程把经验变成了统一语言，队伍协作顺畅很多。

5.3 渗透测试类 skills：授权环境是底线

热词里出现“渗透测试skills”，我也关注过这类仓库。需要特别强调的是，这类技能必须建立在严格合规的前提下使用：只允许在获得授权的测试环境、自建的靶场、本地虚拟机或者专门的漏洞测试平台上运行。任何未授权的扫描、探测、攻击都是违法的，这个底线不能碰。

在合规范围内，这类 skill 真正有用的部分是“方法论沉淀”。比如信息收集阶段，按照域名信息、IP 端口、Web 指纹、目录结构的顺序有条理地收集；漏洞分析阶段，根据指纹信息匹配已知漏洞类型，并解释每种漏洞的形成原理和检测方式。这类技能本质上是把一名安全测试工程师的分析思路整理成可执行的 checklist，对新手特别友好。但请记住，任何操作都要提前确认授权边界，我写这类技能时第一行永远是“确认目标是授权测试目标”。

5.4 值得关注的社区仓库：baoyu、mattpocock 与吴恩达教程

社区里已经有不少人把 skill 玩法玩得很透。国内比较有代表性的是“baoyu skills”仓库，里面收集了大量现成的技能包，从写周报、写 PRD 到代码审计都有，适合直接“抄作业”后再根据自己的需求修改。国外的 mattpocock’s skills 也很有名，他是 TypeScript 圈子的老面孔，他整理的技能包更偏前端工程化和代码开发方向，有很强的实战参考价值。另外吴恩达在 Agent 相关的课程和教程里也专门讲过 skills 的设计，虽然更偏教学导向，但原理讲得非常透彻，适合想搞懂底层的朋友阅读。

看到这么多社区资源，你可能会问：直接下载别人写好的技能包不就行了，为什么还要自己开发？我的观点是：拿来主义只能解决 80% 的通用需求，剩下 20% 的个性化流程——比如你们团队的代码规范、你们产品的特殊逻辑——只能靠自研。别人写的 skill 本质上是他脑内工作流的切片，你自己的 skill 才是你经验的可执行版本。

6. 开发与调试 skills 的经验：常见问题与排查方法

6.1 skills 不生效时，按这个顺序排查

我遇到过不少朋友反馈“skills 配置了但一点反应都没有”，这里整理一个排查顺序，基本能覆盖九成以上的问题。

这里面最容易被忽视的是最后一行。我有的技能在通用目录下写死了“使用 Tailwind”，但在一个 Vue 项目里，这个指引就会跟现有代码风格产生冲突，AI 生成的结果自然不对。后来我在所有自定义技能后面加了“如果项目有自定义规范，优先遵循项目规范”，问题立刻少了很多。

6.2 用“对话复盘法”开发新技能：从成功案例反向提炼

这个方法我想重点推荐给想开发自己 skills 的朋友。很多人的做法是凭空设计流程，然后让 AI 照着执行，结果写出来的技能总差点意思。我的做法恰好相反：不着急写 SKILL.md，而是先在对话中不预设任何流程，把要处理的任务从头到尾自己主导一遍，每一轮都给 AI 明确的指令和纠偏。等这次对话成功产出了满意的结果，再回头把整个对话过程中你下达的指令、修正意见、输出标准抄录下来，提炼成 SKILL.md 的正文。

这背后的逻辑很简单：你亲手指导 AI 的过程，就是你脑内工作流的最好输出样本。那些你下意识纠正过的地方，往往就是这个领域最核心的经验。把它们固化下来，比闭门造车写出来的技能接地气得多。我有至少一半的自用技能都是这么反向生成的，其中就包括一套很复杂的“遗留系统重构方案”技能，效果比我第一版纯设计出来的好太多。

6.3 版本管理与团队共享：像管理代码一样管理技能

随着自建 skills 越来越多，你会发现它也需要版本管理。我的做法是把所有个人技能放在一个 Git 仓库里，仓库结构按“名称/版本”组织，每个技能维护一个 CHANGELOG，记录当时为什么加这个步骤、删掉了哪个环节。这样做的好处是，当你某次更新导致技能质量下降时，可以快速回退到上一个可用版本。

团队共享场景更要注意命名规范和目录规范。我跟团队定的约定是：技能名称必须体现业务场景，禁止出现“test1”这种命名；description 必须写清楚输入输出，否则代码评审不给过；所有技能必须附一个 README，说明依赖的 MCP 工具和环境变量。有了这套流程，团队仓库里的技能包使用率才会逐步上升，否则大部分技能会躺在仓库里吃灰。

另外还有一个实操小技巧：把技能开发放进日常迭代里。每做完一个重复性的任务，就问自己一句：“如果这个任务要做十次，我愿不愿意花半小时把它写成 skill？”愿意，就立刻写。很多高效的技能包，都来自这种“事后固化”，而不是一开始就冲着宏大主题去开发。

聊了这么多，我自己最大的感受是：skills 真正改变的其实不是 AI 的输出质量，而是我们的工作方式。过去我总觉得 Agent 的能力上限取决于模型本身，踩过几次坑之后才意识到，同等模型能力下，技能包设计得好不好，输出质量的差距可能比换一个更大的模型还要明显。我现在已经把大量重复性工作都沉淀成了技能包，从写测试用例到生成技术方案再到读论文做综述，每个技能都在持续迭代。最后再分享一个小技巧：如果你不知道从哪个任务开始，就翻一下最近两周的对话记录，找出你向 AI 重复描述次数最多的那类需求，恭喜你，那就是你的第一个 skill 选题。