最近一个多月我一直在折腾 Agent Skill陆陆续续给手头的 AI 助手装了三十多个 Skill干脆照着公司组织架构给 AI 分了八个岗位从需求分析、架构设计、代码落地到测试验收一整套跑下来效率比单开一个对话窗口高太多了。这篇文章把整套玩法做个复盘包括岗位怎么拆、Skill 怎么选、Agent 怎么调教以及哪些坑是真金白银踩出来的。先说结论Skill 不是堆得越多越好八个岗位背后对应的是八个明确的职责边界。安装 Skill 最核心的逻辑不是“多”而是“每个 Skill 解决一类确定性的问题”。单次对话里塞太多互相干扰的 Skill反而会让模型在意图识别上犯迷糊。所以本文会围绕岗位设置、Skill 搭配、工作流设计和实测效果四个方面展开希望对正在搭建自有 AI 工作流的朋友有参考价值。1. 内容整体设计与思路拆解1.1 为什么要给 AI “安排岗位”而不只是“装插件”先聊一个比较容易混淆的问题Agent、Skill、Plugin 这三者到底什么关系我自己的理解是Agent 是一个带有自主规划能力的执行者Skill 是这个执行者手里的一本“操作手册”Plugin 则是具体干活的工具接口。过去我们给 ChatGPT 装插件本质上是给模型绑了一堆可用工具但模型并不知道什么时候该用哪个而 Skill 的核心差异在于它携带了明确的目标定义和执行步骤——你告诉 Agent“你是前端工程师”它就会主动调用前端相关的 Skill、套用对应的编码规范来干活。岗位化就是把“工具包集合”升级为“角色与职责的映射表”。我不需要记住自己装了三十多个 Skill 各自叫什么我只需要记住“产品岗”负责写需求拆解文档“架构岗”负责技术选型和模块划分“测试岗”负责生成测试用例和自检清单。这背后是对模型工作方式的妥协大模型在自由对话中最擅长“回答”但在多步骤任务中最擅长“按流程执行”。岗位化的本质就是给模型创造一套温室环境让它每次输出都走在预设的轨道上。1.2 八个岗位如何覆盖一个完整项目生命周期我把常见项目从零到一拆成了八个阶段每个岗位对应一个阶段的核心产出这样安排岗位的时候思维非常清晰岗位名称核心职责对应项目阶段项目经理需求澄清、任务拆解、排期启动产品经理需求文档、用户故事、验收标准需求架构设计师技术选型、模块拆分、接口设计设计前端工程师UI 实现、交互逻辑、联调开发后端工程师数据库设计、接口开发、业务逻辑开发测试工程师测试用例、边界条件、回归测试验收运维工程师部署脚本、环境配置、监控报警发布文档工程师README、接口文档、使用教程交付这个表格就是我安装 Skill 的指导思想。实际执行的时候一个岗位不一定只有一个 Skill比如“前端工程师”我装了 HTML/CSS 代码规范、React 组件写法、Tailwind 类名速查这三个 Skill因为前端这个活儿本身跨越了多个技术栈。1.3 为什么 30 多个 Skill 反而是可控的三十多个 Skill 听起来很多但如果给它们做一次分类就会发现逻辑其实很清晰。我一般把 Skill 分成三类职责型 Skill像“需求模板生成器”“Code Review 清单”这种绑定到固定岗位由角色触发。工具型 Skill像“DrawIO 流程图生成”“PPT 结构模板”“思维导图整理器”这种跨岗位复用任何角色需要时都可以调用。领域型 Skill像“专利辅助撰写”“数学建模优化”“SQL 优化器”这种只在特定任务下激活。分类之后三十多个 Skill 只是看起来多真正同一个任务里会被同时触发的一般不超过五六个。这也是 Skill 数量必须有限制的核心原因模型需要在每个决策点做意图判断选择过多会显著增加判断失败的概率。我实测下来如果给 Agent 挂上超过 50 个 Skill 且不分类错误触发率会急剧上升往往问一个技术问题它却去调用了 PPT Skill。2. 核心细节解析与实操要点2.1 Skill 的本质一份人机都能读懂的“执行手册”在动手选 Skill 之前必须先理解 Skill 在目前主流 Agent 系统中的存在形态。拿我用的 Claude Code Skill 举例一个 Skill 在工程层面就是一个文件夹里面最少包含一个 SKILL.md 文件负责描述这个 Skill 是干什么的、什么时候触发、执行分哪几步。更高阶的 Skill 还会带上参考代码、模板文件、checklist 等附件在执行任务时作为参考上下文一并提供给模型。这里面最核心的设计原则是SKILL.md 的元信息部分决定模型什么时候用这个技能正文部分决定模型怎么用这个技能。比如一个“Python 代码审计”Skill元信息要写明 on 条件比如代码文件后缀是 .py、用户提到“审一下代码”和 priority 优先级正文要写明审计的维度安全性、性能、可读性、输出的格式按严重级别列问题清单、以及必须规避的误报点。这个结构本质上是在用 Prompt Engineering 的方法约束模型行为只不过把 Prompt 固化成了可复用的文件资产。2.2 三十多个 Skill 从哪里来官方市场、社区、自己写Skill 的获取渠道大概有三个不同渠道的质量差异非常大这里分享一些我筛选时的经验。第一个渠道是各家官方 Skill 市场。Claude Code 有自己的 Skill 仓库、OpenClaw 也有 Skill 市场这些官方来源通常经过基础质量审核SKILL.md 的格式也比较规范推荐新手从这里起步。我在官方市场里挑得最多的是“文档生成器”“代码重构助手”这类与开发流程直接相关的 Skill它们的触发条件和输出格式都做得比较克制和 Agent 本身的协作很顺畅。第二个渠道是社区和 GitHub 开源仓库。这个渠道质量参差不齐甚至有拿老旧的 Prompt 模板套个文件夹就发布的情况。我自己筛选社区 Skill 有几个硬指标一是看更新时间半年以上没更新的基本不考虑二是看 README 和 SKILL.md 是否写了明确的触发条件和参考示例三是看 issue 区有没有人反馈误触发问题。社区里收藏价值比较高的是一些垂直领域的 Skill比如针对 DrawIO 的流程图生成、针对 PPT 的 Markdown 转大纲脚本、针对数学建模的 LaTeX 公式模板这些属于“场景明确、不依赖实时信息”的类型不容易因为模型版本更新而过时。第三个渠道是自己开发。说实话用了十几二十个外界 Skill 之后你会发现需求总是贴合不到 95%——要么输出格式不合口味要么触发条件不够精准。这时候就该上手写自己的 Skill 了。自定义 Skill 不必从零开始把官方文档的模板拿来改就是一个非常高效的起点。例如我想生成一个“敏捷开发每日站会报告”Skill只需要在模板里定义输入昨天的任务、今天的计划、阻塞项、输出格式三段式列表、触发条件用户提及“站会”或“daily standup”整个开发过程大概十几分钟效果却很稳定。2.3 Skill 开发速成一个最小可用 Skill 只需要四步如果你想完全掌控自己的 Skill可以考虑自己开发。这里分享一套我压箱底的四步法第一步定边界。想清楚这个 Skill 只解决什么问题、不解决什么问题。例如“Java 单元测试生成器”的边界是只处理 Java 文件只生成 JUnit 5 格式不负责修改业务代码。边界越窄模型的触发准确率越高。第二步写示例。在你的 SKILL.md 里至少放一个输入输出示例。示例的作用是给模型一个“输出锚点”没有示例的 Skill 会让模型自由发挥输出格式千奇百怪。这一步最容易被忽略但也是实测下来提升效果最明显的一步。第三步定校验。在 SKILL.md 中明确写清楚最后的输出如何自检。比如代码类 Skill 要规定“输出前必须检查有没有语法错误”“有没有未使用的 import”“有没有硬编码的密钥”。把校验步骤交给模型自己做能大大减少低质量输出。第四步试迭代。在真实任务里跑五次以上观察哪些地方触发不了、哪些地方触发了但输出跑偏然后改元信息或正文里的描述。一个 Skill 的成熟往往需要经过二三十次任务的打磨刚开始不够好很正常。2.4 岗位与 Skill 的映射我最终保留了哪 30 多个光说理论容易飘这里把我在本地实际使用的岗位-Skill 映射表列出来方便做个参照。注意这不是一个一次性列完的清单而是经过多轮增删后沉淀下来的当前状态项目经理岗WBS 任务拆解、排期估算、每日站会报告生成。产品经理岗PRD 需求文档模板、用户故事拆分、验收标准生成。架构设计师岗技术选型对比表、模块划分与依赖关系、接口设计规范。前端工程师岗React 组件规范、Tailwind 类名速查、HTML 语义化检查。后端工程师岗数据库 Schema 设计、OpenAPI 接口文档生成、SQL 性能优化。测试工程师岗单元测试用例生成、边界条件分析、Code Review 检查清单。运维工程师岗Dockerfile 生成、CI/CD 流水线配置、日志监控排查。文档工程师岗README 自动生成、Markdown 格式规范化、DrawIO 架构图生成。剩下的若干 Skill 属于跨岗位的“工具型”比如“思维导图整理器”“会议纪要提炼器”“LaTeX 公式助手”谁都能用、随叫随到。这样配置下来每个岗位的职责是独立的同时因为存在共享工具型 Skill各岗位之间又能协作而不至于孤立。3. 实操过程与核心环节实现3.1 环境准备我如何搭建多 Skill 共存的工作区工欲善其事必先利其器。Skill 再多跑不起来等于零。我当前的主力环境是 Claude Code Codex 双引擎一个偏向结构化和长流程任务一个偏向快速代码补全和重构两个引擎共享同一套 Skill 工作区。目录结构大致长这样~/.agents/skills/ ├── product-owner/ # 产品岗 Skill │ ├── SKILL.md │ └── prd-template.md ├── frontend-dev/ # 前端岗 Skill │ ├── SKILL.md │ └── react-patterns.md ├── test-engineer/ # 测试岗 Skill │ ├── SKILL.md │ ├── unit-test-checklist.md │ └── examples/ └── shared/ # 共享工具型 Skill ├── drawio-generator/ ├── ppt-structure/ └── mindmap-creator/在这个结构里SKILL.md是主入口文件模型优先读取examples/目录放示例代码可以在输出时作为 few-shot 参考。每个 Skill 文件夹大小控制在几百 KB 以内避免把模型上下文撑爆。这里有一个实测下来的重要参数单个 SKILL.md 最好控制在 100 行以内超过这个长度模型执行时“遵循度”会下降。如果执行细节确实很多可以把细节拆到附带的模板或参考文件里让 SKILL.md 只保留“触发条件 执行步骤 输出格式”这个骨架。3.2 岗位化工作流的一次全流程实操从一句话需求到一个可运行的项目为了让你对“八个岗位协作”有直观感受这里跑一个完整案例。任务是我随口提的一句话“帮我写一个带用户登录和文章列表的 Flask 博客应用。”第一步项目经理介入把这句话拆成七个子任务需求确认、数据库设计、后端 API 开发、前端页面开发、登录认证实现、测试用例编写、部署脚本准备。这一步的输出是一个 Markdown 格式的任务分解表格每个子任务后面标了预估耗时和依赖关系。第二步产品经理细化第一个子任务输出 PRD 的核心段落包括用户故事“作为访问者我想注册账号以便管理自己的文章”、功能清单、验收标准“登录状态失效后跳转到登录页”等。这里产品岗的 Skill 自动识别到这是 Web 应用把安全需求密码加密、Session 管理也加到验收标准里了。第三步架构设计师根据 PRD 给出技术选型Flask SQLite Jinja2模块拆分建议以及数据表结构设计。它生成的表结构直接落到 SQL 语句方便后端直接用。第四步后端工程师接手生成 models.py、views.py、auth.py 三个文件的完整代码并且调用了 SQL 优化 Skill在查询文章列表的地方自动加了分页和索引建议。第五步前端工程师生成模板文件包括 login.html、register.html、index.htmlCSS 样式复用了 Tailwind 类名速查 Skill整体页面风格统一。第六步测试工程师生成 pytest 测试文件覆盖注册、登录、登出、文章 CRUD、未登录访问受保护页面的跳转等八个用例。这里测试岗 Skill 自动生成了测试数据夹具省得我手动造数据。第七步运维工程师生成 Dockerfile 和 docker-compose.yml配置了数据卷和环境变量还跑了一遍 SQLite 数据库文件权限的检查。第八步文档工程师汇总所有内容生成 README.md包含快速启动方法、目录结构说明、API 接口文档和常见问题排障。整个流程从发出需求到拿到全部产出大约花了十分钟。如果是传统对话式交互这个任务我大概率要开七八轮对话而且需要自己整理各轮的上下文衔接。岗位化工作流的价值就在这里每个岗位的 Skill 在进入自己的环节时是拿着上一个岗位的产出继续往深里做的不会把自己局限在单轮问答里。3.3 让岗位协作不“串味”的上下文交接技巧岗位化协作最容易翻车的地方是上下文交接。如果项目经理的输出直接全量塞给架构师架构师会被一大堆排期信息干扰。我的方法是设定“交接契约”在每个 SKILL.md 里明确写清楚“你只需要关注输入中的哪些部分”。实际操作层面我做了两件事。第一给每个岗位的 SKILL.md 增加一个input_scope字段写明本 Skill 的输入应该是上一环节产出中的哪个小节。第二在流程编排层用一个“工作台”文件每次交接前先把上一环节的产出格式化整理成标准段落再喂给下一个岗位。这个“工作台”文件其实就是一段固定的 System Prompt但它保证了每个岗位拿到的输入是干净、完整的。3.4 定时清理与 Skill 复用让工作区保持健康三十多个 Skill 常驻在 Agent 环境里时间长了上下文会越来越冗余。我的做法是每个月做一次“Skill 体检”主要检查三件事一是哪些 Skill 过去一个月从来没有触发过考虑删除或合并二是哪些 Skill 的 SKILL.md 描述含糊导致误触发频率高需要重写元信息三是哪些 Skill 的输出格式已经过时比如 React 项目从 CRA 迁移到了 Vite前端 Skill 里的脚手架命令就需要更新。对于重复用途的 Skill建一个模板仓库统一管理是很值得投入的事。模板仓库里每个 Skill 都带版本号、变更记录、维护状态换新机器时一条命令就能全部同步下来省掉了重复配置的时间。4. 常见问题与排查技巧实录4.1 Skill 装多了之后 Agent“变傻”了怎么排查这是最大的坑没有之一。当你把几十个 Skill 一股脑塞给 Agent 时它会在意图识别阶段出现明显的“决策疲劳”——明明在聊 Python 代码却非要去翻 PPT 相关的 Skill。我这边的排查思路分三步第一步检查 Skill 的元信息是否足够具体。很多出问题的 Skill 都是把触发条件写得过于宽泛比如“当用户提到代码时触发”这种描述等于没写。第二步检查各个 Skill 之间是否有重叠。比如既有一个“SQL 生成器”又有一个“数据库优化器”模型很容易拿不准该用哪个。第三步启用调试模式看触发日志。目前主流 Agent 方案基本都有 debug 或 verbose 模式可以看到每个请求命中了哪些 Skill、优先级排序是怎样的。根据日志结果我通常会调整冲突 Skill 的priority值或者干脆合并成一个更细粒度的 Skill。4.2 写了 SKILL.md但 Agent 就是无视它怎么办SKILL.md 写好但 Agent 不触发大概率是命名和描述跟用户口语表达对不上。比如你给“Linux 运维脚本生成器”这个 Skill 的触发词是“deploy”“服务器”“运维”但真实项目里用户说的是“上一下线”或者“搞个发布脚本”模型就不会联想到这个 Skill。解决方法是给 SKILL.md 增加“同义词扩展”。实测效果好的一种做法是在元信息里直接列出至少十个常见的用户表达变体。比如“服务器”要扩展出“机器、主机、虚机、ECS、CVM、云主机、裸金属、节点、node”等覆盖面越广、触发准确率越高。list 里的每一项其实都是模型的“召回关键词”值得认真设计。另外还有一种情况是 Agent 认为这个 Skill 的优先级不够高。这时可以通过调高priority或增加一个明显的触发前缀来解决但要注意这样做的副作用是可能引入误触发。4.3 多岗位协作时产出之间互相矛盾怎么办多个岗位各自工作时偶尔会出现前后不一致的情况。最典型的是架构师设计了一个接口后端实现时因为技术细节悄悄改了一个字段名导致前端和测试都跟着错位。为此我引入了一个“一致性校验”流程在最后一个文档工程师岗位收尾前增加一次全局比对专门检查几个关键交接物之间是否存在字段名、数据格式或者路径的冲突。这个比对过程在工程上并不复杂核心是给后端生成代码的 Skill 加一条硬性规范接口实现必须严格返回架构设计阶段的字段名如有改动必须同时更新接口文档和前端 mock 数据并在最终交付时标注改动位置。这听起来像公司里的团队规范但在 Agent 协作中同样适用因为模型默认不会主动维护你数据库和前端代码之间的一致性。4.4 实测下来的独门优化技巧和推荐配置分享几个从三十多个 Skill 中反复试出来、效果最稳的小技巧每个岗位 Skill 的 SKILL.md 末尾加一段“输出前必看”清单用否定句式写明“不要做什么”。比如测试岗位写“不要生成只覆盖正常路径的用例至少包含 3 个异常分支”指令的直接性比含糊的期望描述高很多。用表格替代长文来定义输出格式。表格在引导模型输出结构化内容上比散文高效得多尤其是在排期、对比、参数项比较多的场景。把“参考示例”放在 SKILL.md 靠前的位置而不是附件里。优先呈现的示例能更有效地锚定模型输出风格。30 多个 Skill 的完整列表中我个人认为“单位净值”最高的几个是DrawIO 流程图生成器、SQL 性能优化和边界条件分析。前两个几乎每周都在用边界条件分析则真正改善了代码质量在代码审查环节减少了不少低级错误。4.5 Skill 与 Agent 的边界什么时候该写 Skill什么时候该写 Agent最后再补一个很多人问的问题同一种需求到底做成 Skill 还是做成独立 Agent我自己的判断标准很简单——看它是否需要独立的记忆和跨会话状态。如果这个任务只是“拿到输入、按固定规则输出”那就是 Skill 的范畴轻量、可复用、不占额外上下文如果这个任务需要维护项目进度、持续追踪多个文件的变更、靠长期记忆来做决策那就应该直接写成一个独立 Agent。市面上流传的“Agent 会取代 Skill”的说法并不准确它们解决的问题粒度不一样合理搭配比二选一要高效得多。我用一个简单的矩阵来判断任务归属任务步骤是否固定、是否需要长记忆、是否需要外部工具、是否需要和其他角色协作。固定短流程 不依赖记忆 → 用 Skill 最省心固定长流程 需要跨会话追踪 → 做成专属 Agent 更合适。5. 写在最后的经验之谈说点大实话Skill 岗位化这件事真正改变的不是 AI 的能力上限而是我的工作方式。过去我是在给 AI 当“翻译官”——把需求翻译成 Prompt再把 AI 的产出翻译回项目上下文光是在两者之间来回对齐就得耗掉不少精力。现在八个岗位各司其职我只需要在关键节点做决策和验收把时间留给了真正需要人判断的问题。哪怕你暂时不需要三十多个 Skill照着“先定岗、再挂 Skill、最后串流程”这个顺序跑一遍也会明显感觉到 AI 从“答话工具”变成了“能交差的下游”。最后再分享一个坚持了很久的习惯每次新增 Skill 前先在旧任务上复跑一遍旧 Skill确认新东西不会破坏原本稳定的流程再正式纳入工作区。听起来保守但这恰恰能保证我的 Skill 库里长期留下的是不断正向叠加的能力而不是一锅互相干扰的碎 Prompt。