AI Agent Skills 完全指南：从 Prompt 到技能包开发实战

最近只要打开技术社区十有八九能看到一个词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 跟 MCPModel 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. 进阶场景盘点学术研究、数学建模与安全测试类 skills5.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 配置了但一点反应都没有”这里整理一个排查顺序基本能覆盖九成以上的问题。现象可能原因排查方法技能完全不加载功能开关未开启检查工具设置里 skills 相关选项是否启用技能目录放错位置放到了不识别的位置核对全局/项目级目录路径是否正确模型从不调用该技能description 描述与任务不匹配把 description 写得更具体带上输入输出样例技能被调用但步骤混乱SKILL.md 步骤太多或前后矛盾精简步骤保证每步相互独立、顺序清晰工具调用失败环境变量或鉴权配置缺失检查 MCP Server 日志和配置项生成结果跟预期偏差大skill 与项目规范冲突在 skill 里加入“以项目 README 或规范文档为准”的兜底条款这里面最容易被忽视的是最后一行。我有的技能在通用目录下写死了“使用 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 选题。