过去半年我的大部分编码工作基本都交给了 AI Agent。Cursor 和 Claude Code 两款工具我都在用而且是按项目性质来回切换。用得越深一个痛点就越明显同一个项目的编码规范、同一个框架的写法约定、同一个团队的审查标准每次都要我在提示词里从头交代一遍。写短了它自由发挥写长了上下文窗口又扛不住。直到我把整套工作流切到 Skills 驱动这个问题才算真正根治。Skills 这套机制往简单了说就是给 AI Agent 准备一份岗位说明书。你不需要每次重复教它只需把说明书放进约定好的目录Agent 遇到相关场景时会自己读取并照着执行。这篇文章我按三条线来写先讲清楚 Skills 的核心原理和触发机制再列一份 8 类值得安装的技能选型清单然后分别走一遍 Claude Code 和 Cursor 的完整接入流程最后把我在实测里踩过的坑和最终留用的组合一起交代出来。无论你是刚开始接触 Agent 编程的新手还是已经在用 Cursor / Claude Code 的老手这应该都能当一份直接抄作业的参考。1. Skills 是什么从每次重新教到一次封装到处用1.1 一个每天都在发生的低效场景想象一下这个画面你用 Claude Code 做代码审查第一次很认真在提示词里写了 500 字的要求——重点看安全问题、留意性能瓶颈、按项目的 eslint 规范提意见、不要随意改逻辑、输出要按严重程度分级。它执行得不错你挺满意。第二天你换个文件继续审查同样的规则又得写一遍。再过几天你切到 Cursor好重新教一遍。这种每次重新教的模式有三个直接后果。第一上下文窗口被重复指令白白占掉真正留给代码分析的空间变小了。第二规则每次写出来都不一样今天强调安全明天忘记性能AI 的输出质量完全是随机波动。第三团队里如果每个人都用自己的教法同一个项目的 AI 行为会非常分裂你很难沉淀出一套统一的工程实践。Skill 解决的正是这个问题。它把一整套规则、步骤、示例、禁忌封装成一个可复用的单元。你写一次放到指定目录之后不管在哪个项目、哪个工具里Agent 都能按同一套标准执行。我用了这段时间最直观的感受是AI 的输出从碰运气变成了稳定发挥。1.2 Skill 的物理结构一个文件夹加一份 SKILL.mdSkill 的实体结构其实简单到有点朴素。它就是一个文件夹里面最关键的文件叫SKILL.md。以我常用的一个代码审查类 skill 为例目录大概长这样code-review/ ├── SKILL.md ├── references/ │ ├── security-checklist.md │ ├── performance-checklist.md │ └── style-guide.md ├── scripts/ │ └── extract_diff.py └── templates/ └── review-report.mdSKILL.md是整个 skill 的大脑。它开头有一段 YAML 格式的 frontmatter里面最重要的两个字段是name和description。description尤其关键它相当于这个 skill 的名片Agent 就是靠它来判断这个能力我该不该用。frontmatter 下面就是正文用 Markdown 写清楚这个 skill 的执行逻辑背景是什么、什么时候用、按什么步骤做、有哪些绝对不能碰的禁忌、最好附带几个输入输出示例。references目录用来放参考资料比如安全审查清单、性能最佳实践这种内容量大但不需要每次都读的文档。scripts目录放可执行脚本比如自动提取 git diff、分析依赖树之类的辅助工具。templates目录放输出模板保证 AI 每次产出的报告格式统一。1.3 触发机制description 写得好不好直接决定 Skill 会不会上班刚开始用 Skills 的人最容易忽略一个点Agent 并不是把所有 skill 的内容一次性加载进上下文那样上下文窗口早就爆了。它的工作方式更像一个先看名片、再决定要不要深聊的过程。每次会话开始时Agent 会扫描所有已安装 skill 的name和description相当于把一堆名片摆在桌上。当对话中出现与某个description高度匹配的任务时它才会把完整的SKILL.md内容读进上下文然后照章执行。这也是为什么我一直强调写 Skill 时description的重要性占七成正文占三成。description写得含糊比如只写一句用于代码审查Agent 很可能在真正需要它的时候完全不触发或者在不需要的时候误触发。好的description应该像一句精准的检索式包含触发场景、任务类型、预期产出。后面在写 Skill 的章节里我会给正反例这里先记住结论就行。1.4 Skills 与普通提示词、Rules 的差异很多同学会问那我直接在提示词里写规则不也一样吗或者像 Cursor 那样建一个.cursor/rules文件不是更省事这三者看着像实际定位完全不同。方式触发机制典型场景主要问题普通提示词手动输入每次都要写一次性任务不可复用、规则不一致、占上下文Rules如 .cursor/rules总是生效无条件下发全局约定、项目常量无法按需加载规则多了互相打架Skills按场景自动匹配触发专项任务、复杂工作流需要维护description 要打磨打个比方Rules 像公司的员工手册贴在墙上人人进来都看得到但它不可能指导你完成一次复杂的商务谈判Skills 像不同岗位的 SOP 手册平时锁在柜子里你接手某个岗位时才把它打开照着做。这个区别很重要——全局规则适合放无论做什么都要遵守的内容比如代码风格、提交信息格式而 Skills 适合放只有特定任务才需要的深度能力比如安全审查、性能分析、文档生成。理解了这个底层逻辑后面选型和安装 Skill 的时候你就知道什么内容该往哪里放了。2. 8 类值得优先安装的 Skills按场景选型清单市面上能装、值得装的 Skill 其实远不止 8 类但绝大多数人日常开发用到的场景就集中在下面这几块。我按投入产出比排了序越靠前的越建议优先安装。2.1 前端开发类前端是我个人装的第一个 Skill也是回报最快的一类。原因很简单前端项目的风格一致性太难靠提示词维持了。项目里用了什么组件库、Tailwind 的 class 顺序约定、颜色和间距走的是哪套 design token、按钮组件有哪些变体……这些信息写进提示词又臭又长不写的话 AI 每次都能给你整出个新风格。一个像样的前端开发类 skill至少应该包含组件库使用规范、样式方案约定、响应式布局要求、可访问性检查清单外加一两个从现有代码里提炼的示范片段。装上之后你让 AI照着项目现有风格实现一个表单页它真的会去读 group 组件、用现有的类名体系而不是另起炉灶。社区里比较有名的 superpower skills 包就带了一套完整的前端 skill涵盖 HTML/CSS/JS、React、Tailwind 等方向。另外 GitHub 上搜frontend skills能翻到不少写得不错的单文件 skill挑一个跟自己技术栈匹配的即可。2.2 代码审查类代码审查是我日常使用频率最高的 Skill。没有它的时候让 AI 审代码基本是在碰运气——它可能只改了几个错别字也可能像个刚学会语法的新手一样把没事的地方全给你改一遍。装了这个 skill 之后AI 会按照里面写好的审查维度逐项过安全问题、性能隐患、错误处理缺失、可读性、与项目架构的契合度。好的审查类 skill 通常还会规定输出的格式按严重程度分 P0/P1/P2 分级每个问题给出定位、原因、修复建议和示例代码。这样你拿到手的不是一段天马行空的评论而是一份可以直接转发给同事的审查报告。我有时会把它和 git diff 提取脚本配合起来用让 AI 只审查本次改动的代码行效率比全量审查高得多。2.3 测试驱动开发类测试类的 Skill 对两类人价值最大一是想认真补测试但不知道从哪下手的项目二是想让 AI 自动生成测试但不想每次强调测试风格的人。一个合格的 TDD skill 会定义完整的测试流程先分析被测模块的行为列出测试用例矩阵再按正常路径—边界值—异常路径的顺序生成测试同时约定 mock 的粒度——哪些层要 mock 掉哪些层必须跑真实逻辑。我自己在接入这类 skill 后最明显的变化是AI 生成的测试不再是为覆盖率而写的假测试而是真的在验证业务行为。它甚至会主动提醒我漏掉了某个并发场景或空指针分支这在以前手动写提示词的时候几乎不可能出现。2.4 文档沉淀类程序员不爱写文档这是世界性难题。但文档又是项目长期可维护性的根基所以让 AI 来写就成了最优解。文档类 skill 的核心能力包括根据代码库自动生成 README、为模块生成 API 文档、维护 CHANGELOG、给复杂函数补注释。这类 skill 最讲究的是风格统一。你有没有遇到过 AI 写的 README 一会儿中文一会儿英文、一会儿表格一会儿列表那是因为你每次给的写作要求都不一样。文档 skill 里会固定一套模板和风格指南让 AI 每次产出的文档结构一致、措辞统一。我一般会同时装一个文档审查类的 skill让它检查 AI 自己刚写的文档有没有遗漏关键信息双保险。2.5 数据库与 SQL 优化类数据库相关的 Skill 包含两部分能力设计能力和调优能力。设计能力指根据业务需求给出表结构、索引方案、分区策略调优能力指分析慢查询、解释执行计划、给出索引优化建议。这类 skill 的知识密度特别高没有它的时候AI 很容易给出加个索引就行这种空泛建议有了它它会真正去看EXPLAIN ANALYZE的输出指出全表扫描在哪一步发生、哪个索引没被用上。如果你经常写后端接口我建议给这类 skill 配一个 schema 文档作为 reference 文件这样 AI 在优化 SQL 的时候能结合真实的表结构来判断而不是凭空猜测。2.6 图片生成与设计规范类图片生成类的 Skill 最近热度很高社区里甚至流传着各种图片生成 skills 安装包。这类 skill 的核心价值在于把一段有效的文生图提示词模板封装起来。如果你用 Cursor 或 Claude 这类支持图片生成的 Agent装上之后只要说一句生成一张科技风格的博客封面图AI 就会自动套用画幅比例、风格关键词、光影描述、负面提示词等一整套模板出图质量比裸提示词稳定太多。设计规范类的 skill 则更适合前端和产品同学把项目的设计 token、色彩系统、字体规范、组件间距规则放进 referencesAI 在生成界面时就会严格遵守保证输出与设计稿一致。这两个方向可以分开装也可以合并成一个看你实际用到的频率。2.7 论文阅读与研究辅助类研究类的 Skill 在 Codex 用户里讨论得很多但它在 Claude Code 和 Cursor 里同样适用。一个研究辅助 skill 做的事包括把一篇论文按问题—方法—实验—结论的结构拆解、解释关键公式的推导过程、对比多篇论文的异同、帮你整理相关工作的脉络。这类 skill 的价值在于它强迫 AI 用一种结构化方式处理信息。没有它你让 AI总结这篇论文它可能只给你一段不痛不痒的概括有了它你会得到一份逐节拆解、含要点表格和延伸阅读建议的研究笔记。对研究生和需要追踪前沿技术的人来说这是我认为投入产出比最高的一类 skill——毕竟读论文这件事AI 真的比人快得多。2.8 项目接手与代码考古类最后这一类是我换项目或者接手老代码时的救命工具。项目 onboarding skill 会指导 AI 完成一系列动作读入口文件、梳理目录结构、识别核心模块与数据流、找出关键配置文件、生成一份架构说明文档。它相当于给 AI 装了一个入职培训流程让 AI 在一开始就快速建立对陌生代码库的完整认知。代码考古类 skill 则是反过来用给一段这个函数是干什么的为什么这里要这么写的问题它会沿着调用链追溯、查看 git 历史、对比前后改动最后给你一份带证据链的完整解释。我有个老项目是六年前写的当时既没文档也没注释全靠这类 skill 帮我快速恢复记忆。如果你经常要阅读自己不熟悉的代码这两类 Skill 强烈建议装。整理成表就是下面这样方便你对照自己的技术栈挑选类别核心场景典型输出前端开发类组件开发、样式实现符合项目风格的代码代码审查类PR 复核、代码走查分级审查报告测试驱动类测试设计与生成行为化测试用例文档沉淀类README、API 文档统一风格的文档数据库与 SQL 类表设计、慢查询优化建表方案、索引建议图片与设计类文生图、界面规范高质量图片、规范代码论文研究类论文拆解、综述结构化研究笔记项目考古类接手项目、理解老代码架构说明、调用链分析3. Claude Code 接入 Skills 全流程目录、安装与首次触发3.1 前置准备装好 Claude Code 本体接入 Skills 之前必须先有一个能正常运行的 Claude Code 环境。安装方式很简单只要你的机器上有 Node.js建议 18 及以上版本一条命令就能完成npm install -g anthropic-ai/claude-code装完先验证一下版本claude --version如果能正常输出版本号说明安装成功。接着在终端里直接输入claude进入交互模式首次运行会引导你完成账号登录按提示操作即可。我自己常用的系统是 macOS 和 UbuntuUbuntu 上如果遇到权限问题多半是 npm 全局目录权限没配好搜一下npm global permission fix加上sudo chown命令基本能解决。登录成功之后就可以进入下一步了。3.2 建立 Skills 目录并理解两种层级Claude Code 的 Skills 目录分两个层级作用域完全不同个人级全局~/.claude/skills/放在这里的所有项目都能用。项目级你的项目/.claude/skills/只有当前项目能用适合放业务相关的专用 skill。我的建议是通用型 skill代码审查、文档生成、测试放个人级业务相关、绑定了具体技术栈的 skill 放项目级。这样既能在所有项目里复用通用能力又不会让每个项目背上无关的包袱。先手动创建好这两个目录mkdir -p ~/.claude/skills mkdir -p /path/to/your/project/.claude/skills目录建好之后每个 skill 占一个子文件夹文件夹里至少要有SKILL.md。命名规范建议统一用小写字母加连字符比如code-review、doc-writer方便识别也方便在会话里引用。3.3 从社区安装一个现成的 Skill现在社区里已经有不少现成的 Skills 仓库可以白嫖。比较有代表性的是 Anthropic 官方的anthropics/skills仓库里面提供了大量高质量示例还有社区里非常火的 superpower skills 包里面集成了几十个面向开发场景的 skill覆盖前端、后端、数据分析等多个方向安装时按需挑选即可。以安装一个名为code-review的 skill 为例操作分三步# 1. 把整个仓库克隆到临时目录 git clone https://github.com/your-fork/some-skills-repo.git /tmp/skills-repo # 2. 复制你需要的 skill 文件夹这一步是按需拷贝别整个仓库塞进去 cp -r /tmp/skills-repo/code-review ~/.claude/skills/ # 3. 确认目录结构正确 ls -la ~/.claude/skills/code-review/ # 你应该能看到 SKILL.md 文件拷贝完成之后必须重启一次 Claude Code 会话让它重新扫描 skills 目录。不重启的话新装的 skill 不会被识别到这是新手最容易卡住的一步。3.4 验证触发用真实任务测试 Skill 是否上班装好不等于能用一定要做一次触发验证。我的做法是直接抛给它一个典型任务比如对某个文件说帮我审查一下这个文件的代码重点关注安全问题和性能隐患。如果 skill 正常触发Claude Code 的响应里会体现明显的变化它会主动提到正在使用code-reviewskill、输出的格式和 SKILL.md 里定义的模板一致、审查的维度明显比裸提示词更系统。如果测了两次都没有出现上述特征大概率是description没匹配上。这时候打开它的SKILL.md看看 description 里描述的场景和你的提问方式是不是对得上调整描述之后再测。这个装一个、测一个、调一个的节奏比一口气装几十个然后全指望 AI 自动识别要靠谱得多。4. Cursor 接入 Skills 全流程Agent 模式、Rules 取舍与中文设置4.1 Cursor 支持 Skills 的前提版本与 Agent 模式Cursor 对 Skills 的支持和 Claude Code 略有不同最核心的一点是你必须使用 Agent 模式普通 Chat 模式是不会读取 Skills 的。另外旧版本的 Cursor 并不支持 skills 目录建议先把 Cursor 升级到最新版。Cursor 读取 skills 的目录路径是.cursor/skills/你需要在项目根目录下创建mkdir -p .cursor/skills目录结构和 Claude Code 完全一致——每个 skill 一个文件夹里面放SKILL.md。所以你在 Claude Code 里写好的 skill在 Cursor 里可以直接复用文件夹内容只需要把路径从.claude/skills换成.cursor/skills。这个兼容性是我很喜欢的一点同一套 skill 资产在两个工具之间零成本迁移。4.2 Skills 与 .cursor/rules 的取舍Cursor 的老用户肯定都用过.cursor/rules它和 skills 之间很容易让人纠结到底该用哪个。我给一个实操判断标准凡是这个项目的所有 AI 操作都应该遵守的内容放 rules凡是特定任务才需要执行的一套复杂流程的内容放 skills。举个例子。你规定了项目里所有代码必须使用 TypeScript、import 必须排序、文件名必须用 kebab-case这些是全局约束放.cursor/rules最合适因为它每次都会加载确保 AI 不踩线。但当我要求生成单元测试时要按照先列测试矩阵、再写测试、最后跑覆盖率并补充遗漏用例的完整流程执行这是一个复杂的专项流程放 skills 里按需触发才不浪费上下文。一句话总结rules 管底线skills 管能力。两者配合使用而不是互相替代。4.3 导入 Skills 并在 Agent 会话中触发在 Cursor 里安装 skill 也走复制文件夹这条路。把对应 skill 从本地仓库拷贝到项目.cursor/skills/下即可cp -r /tmp/skills-repo/code-review .cursor/skills/然后打开 Cursor切到 Agent 模式新建一个会话。触发方式有两种一种是在提示词里显式引用比如直接写用 code-review skill 审查 src/auth/login.ts另一种是不提 skill 名字直接描述任务让 Agent 靠 description 自动匹配触发。我实测下来显式引用是最稳的。尤其当你同时装了十几个 skill 的时候明确告诉 Agent 用哪一个能避免它误解你的意图、选错 skill。如果自动触发的效果不理想优先检查 description 的匹配度其次检查是不是开了普通 Chat 模式这两个是 Cursor 上最常见的失败原因。4.4 顺手把 Cursor 界面调成中文不少同学在热词里搜索cursor怎么设置中文其实就是想降低上手门槛。方法很简单打开 Cursor 的设置界面找到 Language语言选项选择简体中文重启之后界面就汉化了。设置成中文对 skills 的使用没有任何影响但菜单提示、错误信息看起来会更直观尤其是在设置项比较多的时候中文界面能减少不少迷茫感。我个人建议刚入手 Cursor 的朋友先把这一步做了省得后面每一步都要靠猜。5. 自己动手写 Skill结构、描述与迭代方法5.1 SKILL.md 的标准结构社区里现成的 skill 再多也总有满足不了你具体需求的时候。所以自己动手写 skill 是一定要掌握的能力。一个结构清晰的SKILL.md通常长这样--- name: doc-writer description: 当用户要求为项目生成 README、API 文档或 CHANGELOG 时使用。自动分析代码库结构按照团队统一风格输出文档。 --- # 文档生成 Skill ## 适用场景 - 新项目初始化时生成 README - 为某个模块生成 API 文档 - 根据 git log 更新 CHANGELOG ## 执行步骤 1. 分析项目目录结构与关键文件 2. 识别主入口、核心模块、依赖关系 3. 按照 templates/readme-template.md 的格式生成 4. 检查文档是否包含快速开始、配置说明、常见问题三部分 ## 规则与禁忌 - 一律使用中文术语首次出现时附英文原文 - 不编造不存在的命令或配置 - 不复制代码库中敏感信息密钥、内网地址 ## 示例 这里放一个输入输出对让 AI 理解好的输出长什么样frontmatter 里的name和description是必填项正文部分没有强制格式但按照场景—步骤—禁忌—示例这个结构来写Agent 的执行准确率会明显更高。尤其是示例这个部分很多写 skill 的人会忽略但 AI 是概率模型一个具体的输入输出示例比十句抽象描述都管用。5.2 description 写作公式场景 任务 预期产出前面反复强调 description 的重要性这里直接给公式。我的写法是当 [触发场景] 时使用。负责 [具体任务]输出 [预期成果]。反例和正例对比一下你们就懂了反例用于代码审查。正例当用户要求对代码、Pull Request 或提交记录进行审查检查安全漏洞、性能问题或代码风格时使用。按 P0/P1/P2 严重程度输出审查报告每条附定位、原因和修复建议。反例的问题在于信息量太低Agent 既不知道什么时候该触发它也不知道触发之后该产出什么。正例把触发条件、执行范围、输出格式一次写清Agent 在匹配时几乎不会犹豫。这个公式是我调了十几个 skill 之后沉淀出来的亲测有效。5.3 附件的最佳使用方式该放 references 就放 references写 skill 时最容易犯的错是把所有内容全部塞进SKILL.md。我见过有人把一份 6000 字的公司编码规范全文粘贴进去结果每次触发这个 skill这些文字全都会进上下文直接把窗口占掉一大块。正确做法是分层把最核心的执行流程和规则写在SKILL.md正文里把细节性、参考性的内容放进references/子目录在正文里用详细清单见 references/xxx.md来引用。Agent 在需要时才会去翻阅这些参考文件不需要时就不会读上下文效率会好很多。同理需要跑命令的逻辑就写成一个脚本放scripts/目录让 AI 直接调脚本拿结果而不是让它自己猜命令参数。5.4 迭代方法写一个、测一个、改一个写完 skill 之后别急着大规模部署先跑一轮小规模验证。我的标准流程是三步拿一个代表性任务测试触发效果看它有没有被正确唤醒。检查输出质量对比 skill 里定义的步骤和产出格式找出偏差。比如它漏掉了一个审查维度就说明 SKILL.md 里对应的说明不够明确。修改 SKILL.md重新测试直到输出稳定达标。这个循环通常要跑 3 到 4 轮才能让一个 skill 达到放心用的状态。另外建议把写好的 skill 放进 Git 仓库管理每次改动都留记录一旦改坏了随时可以回滚。我自己维护了一个my-skills仓库团队里其他人直接 clone 就能获得同样的 AI 能力这算是我觉得最值的一笔知识资产投资。6. 实测踩坑清单与我的最终组合6.1 我踩过的 5 个坑接入 Skills 这几个月我踩过的坑不算少挑几个影响最大的列出来帮你们避雷。第一个坑是把 skill 目录放错位置。Claude Code 认.claude/skillsCursor 认.cursor/skills两者不通用。我有一次在 Cursor 项目里把 skill 放进了.claude/skills结果折腾半天才发现路径搞错了。文件夹内容可以复用但路径必须按工具来。第二个坑是 description 太泛导致不触发或误触发。最开始我写的一个 help skilldescription 写的是帮助用户。结果可想而知几乎每个会话都会触发它浪费了大量上下文。后来改成当用户询问项目架构、依赖关系或构建流程时使用触发才变得精准。第三个坑是 skill 体量失控。有些社区 skill 为了全面塞进了几百 KB 的参考资料。看起来是很专业但每次触发都要把这些内容读进上下文响应速度和成本都受拖累。现在我给自己定的标准是单个 skill 的 SKILL.md 控制在 3KB 以内references 总量不超过 50KB。第四个坑是 skill 与 rules 打架。项目 rules 里规定所有错误提示必须用中文某个 skill 却要求输出表格里保留英文术语AI 两边都要遵守结果行为变得不可预测。现在我会定期检查 rules 和 skills 之间有没有冲突冲突时以更具体的一方为准。第五个坑是版本问题。Cursor 的旧版本根本不认.cursor/skills我一开始在老板电脑上装了半天没反应最后发现是版本太旧。现在已经养成了习惯装 skills 之前先把工具升级到最新版省得白折腾。6.2 判断一个 Skill 值不值得装的三个标准GitHub 上 star 数高的 skill 仓库很多但 star 数不代表适合你。我总结了三层判断标准帮你在安装之前快速过滤。第一看它的 description 是否具体。如果 description 说得清楚什么场景触发、做什么、产出什么至少作者是在认真写如果只是一些有用的东西直接跳过。第二看它的 SKILL.md 是否结构化。有没有清晰的场景、步骤、禁忌、示例还是大段散文结构化的 skill 执行稳定性远高于散文式的。第三看它的维护状态。一个半年没更新的 skill很可能已经跟不上最新工具版本。装之前看一眼最近一次 commit 是什么时候比看 star 数有意义得多。6.3 我目前留用的组合最后交代一下我现在的实际配置。Claude Code 和 Cursor 我都装了通用 assets 建在个人级目录项目相关的放项目级。目前留用的组合是前端开发类用frontend-stylist负责按项目设计规范生成界面代码代码审查用code-review审查报告的维度很齐还会自动跑 diff 提取测试类用test-builder生成行为化测试文档类用doc-writer输出风格统一数据库类用sql-optimizer专门处理慢查询图片类用image-prompt-studio出图质量比裸提示词稳定太多研究类用paper-digest拆论文非常好用项目考古类用legacy-explorer接手老代码全靠它。这 8 个 skill 覆盖了我日常 90% 的工作场景剩下的场景再靠手动提示词补足。装了它们之后最明显的变化是我在同一个项目里来回切工具时AI 的行为不再换个工具就变个样因为大家读的是同一套 SKILL.md。这种一致性带来的踏实感是花多少时间配置都值得的。最后再多说一句与多数教程不同的建议不要一次性装几十个 skill。技能越多Agent 在匹配时需要扫描的名片就越多误触发的概率也越高。先挑最痛的两三个场景装起来跑顺了再逐步扩展。我自己也是从最初的 3 个一路加到 8 个的每一个都是实际用了一段时间确认有真实价值后才留下。这套少而精、按需加的策略才是 Skills 正确打开方式。