最近有个朋友问我你整天折腾 AI到底折腾出什么结果了。我跟他说我前两天干了一件事一口气装了 30 多个 Skill然后给我那台天天写代码的 AI 安排了 8 个岗位。他听完直接愣住问我什么叫给 AI 安排岗位。我说就是把 Skill 当作岗位说明书和工作手册让 AI 像一个小团队一样运转而不是一个只会聊天的机器人。这篇文章我就把这件事的完整过程写出来包括我为什么装这么多 Skill、怎么给 AI 设计岗位、每个岗位到底配了什么技能、实际用起来效果如何以及我在这个过程中踩过的一堆坑。如果你也在用 Claude Code、Codex、Cursor 这类支持 Agent Skills 的工具这篇文章应该能帮你少走不少弯路。1. 先搞明白 Skill 到底是个什么东西1.1 Skill 不是普通提示词是带说明书的工具箱很多人在网上看到 Skill 这个词第一反应是这不就是预设好的提示词吗还真不是。普通的提示词是你每次跟 AI 对话时临时输入的一段话说完就没了下次还得重新说。Skill 是一个结构化的文件夹里面通常包含一个 SKILL.md 文件可能还有模板、脚本和参考文档AI 会根据你当前的任务自动判断要不要调用它。我习惯用一个类比来解释提示词是口传指令你每次都得跟新人交代一遍怎么做。Skill 是书面作业指导书里面不仅有步骤说明还有参考模板、检查清单、甚至可以直接运行的脚本。AI 拿到指导书之后能自己照着做不用你每次都从零开始教。1.2 Skill 的核心优势在于自动触发和附带资源Skill 最关键的设计是它有一个带元数据的描述头。AI 在处理任务时会先看你当前的需求跟哪些 Skill 的描述匹配匹配上的技能才会被激活并加载进上下文。这意味着你不用手动指定请使用某某技能AI 自己能判断该用哪个。就拿 AI 编程工具来说。一个设计良好的 Skill 可以附带一份项目代码规范、一组可复用的 Golang 或 Python 代码片段、甚至一个代码审查脚本。当 AI 接收到写代码的任务时它不仅能看到指导书还能直接调用里面的脚本去检查代码质量。这已经超出聊天助手的范畴更接近一个真正有生产能力的 AI Agent。1.3 为什么所有主流工具都在往 Skill 方向走你可能注意到Claude 有 Agent SkillsCodex 出现了 codex skillSpring AI 也在做类似的东西各家都在卷这个方向。原因其实很朴素大模型本身没有长期工作记忆每次对话都是重新开始你上次教过它的经验、规矩、写法偏好它基本全忘了。Skill 就是用来对抗这种失忆的。把经验沉淀成文件放进项目的固定目录AI 每次开工前都能重新阅读一遍。换句话说Skill 是在用工程化的方式给 AI 做经验持久化。我自己也是把这个思路彻底想明白之后才决定系统性地折腾这件事而不是为了炫耀安装数量。2. 装 30 多个 Skill 之后我发现自己被淹没了2.1 30 个 Skill 堆在一起AI 根本不知道用哪个我刚开始装 Skill 的时候想法很简单哪个看起来有用就装哪个装得越多 AI 应该越强。结果用了几天发现根本不是那么回事。30 多个 Skill 全部放在目录里AI 面对一个任务时要在这么多技能描述里做匹配经常出现两种情况要么匹配到一个驴唇不对马嘴的技能要么好几个技能都想触发上下文一下被塞满了。有一回我让它写一个 JSON 解析的小工具它居然先把测试用例生成和代码审查两个 Skill 都加载进来白白浪费了大量上下文窗口产出质量反而下降了。那时候我才意识到我收集的是一堆工具但这些工具没有组织更没有分工。2.2 真正的瓶颈不是数量是组织方式Skill 装得再多如果它们在 AI 眼里是一堆散件那 AI 就不会知道在什么场景下该选哪个以及多个技能一起出现时谁先谁后。这就像你把螺丝刀、扳手、电钻全倒在一个抽屉里用的时候还得一个个翻效率反而比只有两三件常用工具更低。后来我换了个角度思考。我在现实里带过项目团队里每个人的分工是明确的产品经理负责梳理需求架构师做技术选型开发负责实现测试负责找问题。每个岗位有自己的一套工作方法和产出标准。那我为什么不能把 Skill 也按这个思路给 AI 安排成一个个岗位的岗位技能包这样想清楚之后装了多少个 Skill立刻就不再重要了重要的是每一个 Skill 有没有被放到一个清晰的工作岗位上它的职责边界是什么什么时候被触发产出给谁用。2.3 岗位化组织给 Skill 带来的三个直接好处按岗位重新组织 Skill 之后我明显感受到三个变化。第一个是触发准确性提高了。AI 看到一个需求时能先判断当前属于产品阶段还是开发阶段再决定加载哪个岗位的技能误触发的情况少了很多。第二个是技能之间有了交接逻辑。前一个岗位的输出能成为后一个岗位的输入整个流程顺畅了。第三个是维护成本降低了。我想新增或者修改一个技能时只需要在对应岗位的目录里操作不会影响其他职能。这种组织方式说白了就是把AI 个人能力建设升级成了AI 团队流程建设。单点技能再多也难以形成合力但只要流程清晰、职责明确普通的技能组合也能干出很漂亮的工作。3. 我实际给 AI 安排的 8 个岗位及技能配置3.1 岗位全景图下面这张表是我目前实际在用的岗位结构。每个岗位对应了若干个 Skill负责一个完整工作流里的特定环节。岗位之间通过交接文档协作后一个岗位只认前一个岗位输出的结构化结果。岗位核心职责需要的 Skill 类型主要产出物产品经理需求澄清、规则梳理、PRD 输出需求分析 Skill、PRD 模板 Skill需求文档、验收标准架构师技术选型、方案设计、风险排查系统设计 Skill、技术栈对比 Skill技术方案、架构图素材前端工程师界面搭建、组件实现、交互逻辑前端开发 Skill、UI 还原 Skill页面代码、组件说明后端工程师接口实现、数据模型、业务逻辑后端开发 Skill、API 设计 Skill接口代码、数据库设计测试工程师测试用例设计、边界分析、回归验证测试设计 Skill、Bug 描述 Skill测试用例、验收报告DevOps 工程师部署脚本、环境配置、日志排查运维 Skill、部署脚本 Skill部署文档、运行脚本数据分析师指标口径梳理、SQL 编写、报表输出数据分析 Skill、SQL 优化 Skill分析报告、可视化方案文档工程师README 编写、API 文档、交接文档文档生成 Skill、规范校验 Skill项目文档、用户手册3.2 产品经理岗承接模糊需求的第一道关卡这个岗位是我所有任务的第一站。很多时候我丢给 AI 的需求就是一句话比如我想做个工具方便团队内部汇报这个描述极其模糊如果直接让 AI 写代码最后出来的东西基本不能用。所以产品经理岗的核心 Skill 是需求澄清。它的工作内容是反过来向我提问这个工具的使用者是谁汇报的数据从哪来是按周报还是月报汇总需不需要权限区分第一版大概要覆盖哪些核心功能等需求被追问得足够清楚后这个岗位才会输出一份结构化的 PRD带明确的功能列表和验收标准。以前我总是跳过这个环节直接让 AI 干活结果做出来的东西经常返工。现在每个需求先过一遍产品经理岗后面所有岗位都有了明确依据。如果你做项目时也经常觉得 AI 答非所问大概率是你跳过了需求澄清这一步直接进入了实现细节。3.3 架构师岗在动手写代码之前先想清楚路线架构师岗是我加的比较晚但作用很大的一个岗位。它的核心职责是在产品经理产出 PRD 之后决定这个需求用什么技术路线来落地。比如说要做刚才提到的汇报小工具。架构师岗的 Skill 会基于需求分析这个项目要不要后端还是纯前端就够了如果要保存多人数据localStorage 能不能满足用户并发量大概多少如果只是团队内部几十个人用用一个轻量级方案就行完全没必要上重型架构。我自己以前喜欢让 AI 直接开写结果它经常给我写一个过度复杂的系统明明一个静态页面就能解决的事它给你引入数据库和微服务。后来架构师岗的 Skill 被我设定了一条基本原则能用简单方案绝不上复杂方案同时在方案里写明取舍理由。这个岗位真正解决了AI 不会选型的问题它靠的是 Skill 里固化的判断准则而不是 AI 随机发挥。3.4 前端与后端开发岗把 PRD 翻译成可运行代码开发和测试岗其实是大多数 AI 编程工具最擅长的领域但要有好的产出前提是接受到的输入足够清晰。我的前端岗 Skill 里写明了代码风格要求、组件拆分习惯、以及从 PRD 到界面结构的具体转换步骤。后端岗的技能则聚焦在接口设计、数据模型和异常处理上。这两个岗位的工作是高度协作的。前端需要的接口字段必须以后端定义的契约为准。以前它们经常各写各的前端调用了一个后端根本不存在的方法调试半天找不到原因。后来我让两个岗位共同读取架构师的接口文档甚至在 Skill 里明确规定后端先输出 OpenAPI 规范前端照着调这个问题才彻底解决。给 AI 开发岗用 Skill最大的价值其实是把你自己偏好的技术栈、代码风格、文件组织方式固化下来。AI 默认写 Java 的代码风格比较笨重你在 Skill 里告诉它优先用哪几个库、函数命名用什么风格、目录怎么组织它会一直照做不会中途跑偏。3.5 测试岗与 DevOps 岗为代码质量和发布兜底测试岗的 Skill 在被开发岗的代码产出触发后会自动对照 PRD 里的验收标准设计测试用例。它最大的好处是能覆盖开发时容易忽略的边界情况。比如一个日期选择控件普通需求文档不会提到 2 月 30 日怎么办但测试岗的 Skill 会把这些极端输入作为必测项列进去让 AI 在交付前自己先检查一遍。DevOps 岗负责把所有东西变成可以一键运行和部署的形态。它会在项目末尾生成打包脚本、环境变量说明、以及部署文档。针对不同项目的体量它会判断是用 Docker 还是直接写一个启动脚本就够了。我是希望 AI 不只给我一堆代码还要让我能够把代码跑起来这个岗位解决的就是最后一公里的问题。3.6 数据分析与文档岗让项目可被理解和可被追溯数据分析岗不是每个项目都触发但只要涉及数据统计需求它就会被启用。它提供了明确的指标口径模板和 SQL 编写规范避免我自己每次都要解释什么叫活跃用户、什么叫完成率直接在 Skill 里定义清楚。文档工程师岗则通常最后出现负责把所有决策和交付物整理成文档。一个很实际的现象是AI 写代码能力很强但代码入库之后过两周我自己回头看都认不出来。文档岗保证了项目有 README有接口文档有部署说明。它把我前面所有岗位的产出串联起来形成完整的项目档案。对我这种需要同时维护多个项目的人来说这个价值怎么强调都不过分。我不建议一上来就照搬这 8 个岗位。因为不同人做不同的项目岗位序列不完全一样。比如说我故意没有设置 UI 设计师岗因为我的项目大多以内部工具和数据流为主设计含量比较低。你应该先观察一下自己平时的开发请求里哪些环节最容易出问题、最需要模板化然后按需设置岗位。我的经验是从 3 到 4 个核心岗位跑起等流程顺了再加角色比一步到位要稳得多。4. Skill 目录结构长什么样配置文件怎么写的4.1 一个标准 Skill 的目录解剖如果你要从零开始做一个 Skill先理解它的物理结构会很有帮助。我一般把 Skill 放在项目的.claude/skills/或者.codex/skills/目录下不同工具路径略有差异。每个 Skill 都是一个独立文件夹例如skills/ product-mgr/ SKILL.md templates/ prd-template.md acceptance-criteria.md code-reviewer/ SKILL.md scripts/ check_security.py sql-analyst/ SKILL.md references/ metric-definitions.md可以看出每个岗位的技能包里SKILL. md 是主文件其他资源文件按需组织。模板文件用于保证输出的格式统一脚本文件则用来执行具体的自动化操作。4.2 写好 SKILL.md 的关键是描述头和执行规则SKILL.md 最核心的其实是文件开头的 YAML 描述头。这部分决定 AI 什么时候会主动调用这个技能。以产品经理岗的 Skill 为例我会这样描述--- name: demand-clarifier description: 当用户提出模糊需求、需要梳理业务流程、或者希望产出需求文档时使用。特别适合一句话需求、口头描述的场景。不要用于已经非常明确的技术实现任务。 --- # 需求澄清与 PRD 生成 ## 你的角色 你是产品经理任务是把模糊想法变成可执行的需求说明。 ## 执行步骤 1. 先列出需求中包含的关键角色和使用场景。 2. 自动识别需求描述中的模糊点并生成问题清单。 3. 基于用户回答输出 PRD 文档必须包含功能列表、优先级、验收标准。这个描述头里的使用时和不要使用非常关键。很多人写 Skill 只写它能干什么不写它不能干什么结果 AI 经常误调用。后来我把每个技能的边界条件写清楚误触发的概率大幅降低。4.3 一个有执行清单的 Skill 会比空泛的指导稳定得多我还发现在 SKILL.md 正文里加入执行清单能显著提升稳定性。AI 在长对话里容易遗漏细节但如果你在 Skill 里明确写输出前必须检查以下 5 项它通常能记住并执行。比如我的代码审查 Skill在正文中明确要求先检查是否有硬编码密钥再检查异常处理是否完整然后检查资源是否需要关闭最后检查命名是否清晰。每一个检查后面都附带一个示例和反例。实测几次后我发现技能输出的稳定性比只用请帮我审查代码这类提示词强了不是一点半点。Skill 本质上是一份操作手册加检查表。它不会替 AI 思考但它能保证 AI 的思考是沿着你希望的方向推进的而且每一步都有章可循。4.4 从会回答到会执行Skill 里塞脚本的真香体验我以前觉得 Skill 里放模板就够了直到我发现可以在里面塞可执行脚本效果完全不同。举个例子我正在做一个规范的检查 Skill里面放了一个 Python 脚本AI 可以调用它来扫描代码文件中是否含有可疑的高风险模式。这么做的话AI 就不是根据经验猜测了而是真正跑一遍工具再给结论。Skill 里也可以放参考文档。比如数据分析岗的 Skill 会把所有业务指标的口径定义放在 references 目录里AI 写 SQL 之前先去查这些口径就不会再把同一种指标算出不同数字。这样的技能包从外部来看是一个工作指导书从运行来看已经是一个小型的、具备外部辅助能力的智能程序了。5. 用一次真实任务走一遍 8 个岗位的完整流程5.1 从做一个周报统计小工具到 PRD为了让你对这套岗位化流程有更直观的感觉我拿最近一次实际操作举例。我提的需求非常口语化给团队做一个周报统计小工具要能按人按周统计工时。这个需求经产品经理岗的 Skill 处理之后AI 先反问我数据需要多人同时录入吗每个人录完自己的你只需要汇总对吗要不要区分项目维度统计结果需要导出 Excel 吗这些问题回答完后它产出了一份 PRD其中明确写了第一版要做三个功能成员录入每周工时、按周汇总、按项目筛选。验收标准是录入页能够添加多条记录汇总页能自动计算人均工时筛选项目后数字随之更新。这份文档一出来后面的所有岗位就有了明确的依据。5.2 架构师定方案开发和测试并行开工架构师岗的 Skill 读完 PRD 后给出的技术方案是完全不需要服务端用纯前端加 localStorage 就能实现需求。原因是用户量不超过几十人数据量每周几百条浏览器本地存储足够而且部署最简单——直接打开网页就能用。前端开发岗在工作时根据架构方案开始搭建页面。此时后端开发岗处于闲置状态因为它没有收到任何接口契约需求。测试岗没有被跳过它在前端代码完成后自动生成了一组测试用例。特别针对重复提交、跨周数据隔离、员工姓名特殊字符这些场景设计用例。测试用例可以直接执行几乎能复现我在手工测试中能遇到的大部分坑。5.3 DevOps 打包、文档补位直接交付可用工具DevOps 岗最后把整个前端工程打包成了一个可分发目录并生成了一个说明文件告诉我只要把目录放到静态服务器或者直接双击 index.html 就能用。文档岗生成了一份简短的用户手册配上截图指引团队其他人不需要任何培训就能上手。整个流程走完我发现自己几乎没有手动写过代码也没有像以前那样在对话里反复发大段提示词。因为岗位化的 Skill 自己会判断什么时候该做什么。所有环节都有输出、有交接、有验收。更让我意外的是整个交付过程只花了半个多小时。如果让我传统方式开发这个小工具从写页面到部署可能得花一整个下午还不包括后来修 Bug 的时间。6. 30 多个 Skill 是从哪来的我是怎么筛选的6.1 白嫖社区资源时我会注意这三点我的 30 多个 Skill 有很多不是自己从零写的。GitHub 上有人专门维护了收集 Agent Skills 的仓库awesome-claude-skills 这类项目里能找到大量现成技能。社区里还有人写了 Skill Creator专门用来辅助生成新的 Skill用它自动生成初版结构再自己改效率挺高。不过直接拿别人的 Skill 用有几点你要仔细看。第一是确认它到底是激活什么工具的不同平台的 Skill 格式不一定通用Claude 的 Skill 放到 Codex 里经常需要调整描述头。第二是留意会不会有危险操作很多 Skill 里带着自动化脚本我之前下载过一个处理 PDF 的 Skill里面有个脚本会读取用户目录下的所有文件这种我直接用脚本审查完就删了。第三是别迷信下载量大实用性还是得自己跑一遍才知道。6.2 自己写 Skill 的两条实战经验如果你的需求比较个性化我建议自己动手写几个 Skill其实并不难。写的过程只要抓住两个要点。第一个是把你平时反复对 AI 交代的话整理成文字这就是 Skill 的雏形。你每次写代码前都要叮嘱它先写测试再实现那就把这个要求写进开发岗的 Skill 里。第二个是给 Skill 确定合适的粒度别做太细。我以前给代码审查单独做了四五个细分技能什么 Python 安全审查、JS 注释检查后来发现 AI 根本分不清区别干脆合并成一个统一的代码审查 Skill情况改善很多。自研初期先用抄再改的方式比较省力。找结构清晰的社区版本把里面的知识内容换成你自己领域的术语、流程和标准然后跑一个实际任务看效果再调整描述头。反复几轮之后你就有了一批贴合自己工作习惯的技能库了。6.3 装得快删得也快最后留下的不到 20 个装 30 多个 Skill 的过程中我同时也在不停地删。删掉的标准有三条是否与其他技能重复、是否有过实际触发记录、是否带来了稳定产出。一个月下来实际留存的不到 20 个。但留下来的每一个都在对应岗位上真正发挥过作用。我拿几个还在用的举例。通用的需求澄清来自社区经我大幅改造后变成了产品经理岗的入口。某个针对 Spring Boot 项目的开发规范 Skill 是我自己写的来自我在真实项目中总结的要点。还有一个代码审查 Skill配置了最核心的安全扫描脚本和执行清单不管什么项目都能复用。这给我最大的启示是Skill 的价值不在于数量多而在于匹配度高能跟你的工作流严丝合缝地配合。7. 高频踩坑记录Skill 用了不生效怎么办7.1 Skill 没有自动触发问题多数出在描述头上如果你发现 AI 在面对任务时完全没有调用某个 Skill先别怀疑 AI 蠢大概率是你技能描述里的触发词不够具体或者有多个 Skill 描述太像、让 AI 分不清。我的解决办法是用场景化的句子描述触发条件不只写用于代码审查还要写当用户提供了完整代码文件或 Pull Request 时使用重点检查安全问题与异常处理。改完之后触发概率明显提升。还有一种情况是描述头里没有写不要使用的场景。比如你想让数据分析 Skill 只在真正有数据统计需求时启用就别让它连写普通代码的任务也触发。给触发条件加上负面清单能有效剔除大部分误触发。7.2 上下文被浪费、技能间互相打架装了很多 Skill 的副作用是AI 启动时把所有候选技能都读了一遍白白吃掉大量 token。我在排查后发现两个解决办法。一是把不必要的参考文件尽量精简模板和示例放一两个有代表性的就够了另一个是在每个项目里只放当前需要的岗位目录而不是把 30 多个 Skill 全放在同一个全局目录里。Skill 数量一多冲突的问题也来了。比如我有Python 开发规范和通用代码审查两个技能Python 规范说变量命名用小写下划线通用审查里却多了一行保持命名统一即可AI 就开始左右摇摆。后来我给 Skill 设了优先级原则具体语言规范优先于通用规范。这个原则直接写进系统指令里冲突就平息了。7.3 更新 Skill 后发现 AI 还在用旧逻辑还有一次我改完了 Skill 里的流程步骤结果 AI 执行的时候还是按旧方式来做我一度以为它缓存了旧文件。后来发现真正的原因是我改的是正文内容但触发器描述没动AI 在技能选择阶段直接跳过了我对这个技能的理解。所以我调整完 Skill 之后一般会开个新会话在对话里丢一个明显的测试任务先确认触发成功再观察它是否按照新内容行动。下面这个表是我整理的几个典型问题及对应解法建议截图保存现象可能原因处理方法Skill 不触发描述头过于宽泛、缺少负面条件重写描述头用完整语句描述触发场景多个 Skill 同时触发技能职责边界不清按岗位归并附加优先级规则上下文被大量占用参考文件过多过长精简资源文件同一场景只保留 2-3 个案例加载了但效果不好正文步骤不够可执行增加执行清单和输出检查项更新后还在用旧逻辑新会话未触发、新描述不清晰开新会话测试逐字检查描述头改动引用脚本报错技能目录移动、路径写死所有资源引用改成相对路径如果你是从零开始接触 Skill我建议你上手时保持克制。先选择一两个你重复次数最多的任务来做实验比如代码审查、需求澄清写好 Skill 后连续用几次再迭代调整。不要像我一开始那样追求数量——我装到 30 多个之后发现核心逻辑没有理顺等于给 AI 塞了一抽屉没人认领的工具。反倒是在我把它们按岗位安排好之后这 30 多个技能才真正产生了协同效果。装 Skill 从来不是目的让 AI 像一位靠谱的同事那样知道自己的工作、边界和交付格式才是真正值得花时间的事。