1. 从“甩手掌柜”到“团队主管”我为什么给AI装了30多个Skill先说结论装了30多个Skill之后我最大的感受不是AI变聪明了而是我终于可以从“一字一句教AI干活”的泥潭里爬出来了。过去大半年我一直在折腾怎么让AI更听话、更专业。用过的路子不少写长Prompt、做Few-shot示例、调temperature参数、给AI喂各种文档……说实话都有用但都差点意思。长Prompt越写越长维护成本直接爆炸Few-shot示例换个场景就失效参数调来调去最后还是得人工兜底。直到我开始正经用Skill在Claude Code、Codex等编程助手生态里也叫Agent Skill或Codex Skill才慢慢把“给AI当保姆”的状态扭转过来。现在我的工作流里AI不再是“你问他答”的聊天框而是一个有8个固定岗位的虚拟团队——有产品经理、有架构师、有代码审查员、有测试工程师、有文档工程师甚至还有个专门做专利交底书辅助的岗位。这篇文章就把我这套“岗位制”的完整打法拆开讲为什么Skill比长Prompt好用、30多个Skill怎么分类管理、每个岗位配了什么Skill、中途踩过哪些坑、以及我自己总结的6条避坑经验。不管你是写代码的、做AI应用开发的还是像我一样想把AI用到实际工作流程里的普通用户这套思路应该都能给你一些启发。先说清楚一个概念免得后面绕晕我说的Skill本质上是一个封装好的“能力包”——里面放了针对特定任务的System Prompt、参考示例、工作流程甚至一些工具调用的配置。AI装上Skill之后遇到对应任务就会自动启用这套流程输出质量比临时写Prompt稳定得多。举一个最简单的例子。我装了一个叫“Code Review”的Skill它规定了每次审查代码必须从安全性、性能、可读性、边界条件四个维度输出结论每个维度给出具体行号和修改建议。以前我让AI“帮忙看看代码有没有问题”AI只会泛泛地说“这里可以优化一下”。现在装了Skill它输出的是结构化的、可执行的问题清单。这就是Skill和普通Prompt的本质区别普通Prompt是即兴发挥Skill是标准化作业。2. 为什么是“岗位制”而不是“全家桶”我的Skill架构设计思路2.1 从30多个Skill里悟出的管理哲学我陆续装了超过30个Skill这个数量在圈子里不算多但已经足够让人头疼有的Skill互相冲突有的死活不触发有的只在特定场景好用。教训很直接——装Skill和招人一样不是越多越好而是要分好工、理顺汇报关系。所以后来我彻底重构了组织方式不再按照“这个Skill能干什么”来分类而是按照“我把什么岗位外包给AI”来分类。一个岗位对应一个明确的职责边界岗位下面挂若干个Skill作为它的工具集。打个比方我请了个“前端工程师”他的活儿是切页面、写交互、调样式这些职责细分开来就用不同的Skill去支撑。这样设计的最大好处是当任务来临时我能快速判断应该调度哪个岗位、启用哪个Skill而不是在30多个Skill里大海捞针。团队主管不可能让UI设计师去扛服务器对吧AI岗位制也是同一个逻辑。2.2 8个岗位的职责说明书我把30多个Skill归到了8个岗位下基本上覆盖了我日常工作流里AI能帮上忙的所有环节。每个岗位的定位和核心Skill如下表所示岗位职责边界挂载的核心Skill产品经理需求分析、PRD撰写、功能拆解PRD Generator、User Story Writer架构师技术选型、系统设计、方案评审System Design Assistant、API Designer程序员功能开发、代码生成、接口联调Code Generator、Spring AI助手、Bug Fixer代码审查员Code Review、性能排查、安全审计Code Reviewer、Security Scanner测试工程师测试用例设计、自动化测试脚本、边界条件验证Test Case Designer、Playwright助手文档工程师README撰写、接口文档、项目总结README Generator、Doc Translator数据分析师日志分析、性能数据解读、可视化建议Data Analyzer、Log Miner专利辅助专员交底书框架、专利检索辅助、技术方案梳理Patent Drafting Assistant、Claim Mapper2.3 岗位之间怎么协作光有岗位划分还不够还得解决协作问题。我现在的做法是建立了一个“岗位调度Prompt”——当收到一个综合任务我会先让“产品经理”拆需求再把拆好的需求喂给“架构师”架构师输出方案后交给“程序员”落地最后“代码审查员”和“测试工程师”验收。这个流程跑下来AI输出的质量有了质的飞跃。举一个实际例子。上个月我需要快速开发一个小工具放在Spring AI项目里做原型验证。如果用传统方式我得自己写清楚需求文档、技术方案、代码实现……一整套流程下来大半天没了。但用岗位制跑了一遍产品经理岗的PRD Generator先产出了需求文档架构师岗的System Design Assistant给出了模块划分和接口定义程序员岗的Code Generator直接生成了核心代码框架最后测试岗的Test Case Designer补了一组边界测试用例。整个流程跑完大约40分钟。虽然代码不能直接上生产但用来原型验证完全够了。这里有一个容易被忽略的要点岗位制不是把多个Skill串联起来而是每个岗位输出的结果恰好是下一个岗位需要的输入格式。这才是协作顺畅的关键。3. 8个岗位的Skill实配清单到底装了什么、怎么用3.1 产品经理岗把一句话需求变成结构化PRD这个岗位我装了3个Skill核心是PRD Generator。它的工作方式很有意思你只需要输入一个模糊的需求描述比如“做一个团队任务看板”它会自动输出PRD框架——目标用户、核心场景、功能清单、优先级排序、验收标准甚至连用户故事都给你写好。还有一个Skill叫User Story Writer专门负责把PRD里的功能点拆成“作为XX我想要XX以便XX”格式的用户故事。用这个Skill产出的用户故事直接可以作为程序员岗开发时的输入比我自己盯需求文档要省心得多。实际使用的时候注意PRD Generator的输出质量和你给的信息量成正相关。如果你只扔给它一句话它确实能给你输出一个PRD但里面大概率充满陈词滥调。我的经验是至少给它三个约束——目标用户是谁、核心痛点是什么、现有方案有什么不满。有了这三条输出质量完全不在一个量级。3.2 架构师岗让AI先想清楚再说怎么干架构师岗的核心Skill是System Design Assistant这是我用的频率最高的Skill之一。它内置了一套系统设计方法论先明确功能需求和非功能需求再画模块图文字版、定义数据模型、设计接口、最后给出部署建议。另一个比较特色的是API Designer专门负责RESTful API设计。它会根据你描述的业务场景输出完整的API文档URL、方法、请求参数、响应结构、错误码连版本管理策略都考虑到。我自己做Spring AI项目集成的时候经常会先让它把接口定好再让程序员岗去实现。用架构师岗有个心得它给出的方案不一定是最优的但一定是最完整的。它不太会漏掉关键模块和关键接口这对后期开发效率的影响非常大。以前我自己写设计文档经常会忘掉日志、监控、异常处理这些细节但System Design Assistant默认就会覆盖这些非功能性需求。3.3 程序员岗代码生成的核心输出方程序员岗是我装Skill最多的岗位大概挂了6-7个。其中有两个值得专门拿出来说。第一个是Code Generator这家伙内置了大量代码模式库——从通用的CRUD接口到复杂的并发控制都有现成的模板可以参考。用它的正确姿势不是“帮我写一个登录功能”这种粗粒度指令而是“用Spring AI实现一个基于向量数据库的检索增强生成功能要求支持多种文档格式”。输入越精确输出越专业。第二个是Spring AI助手这算是我的偏门配置。因为我最近在折腾Spring AI生态所以专门找了一个针对性的Skill。它内置了Spring AI框架的常用API、配置项、最佳实践能帮我把“怎么用Spring AI构建一个智能问答机器人”这种问题转化成具体的代码实现。如果你不用Spring AI这个Skill对你没价值但思路是通用的——针对你最常用的技术栈去找一个对应的Skill装上比自己查文档效率高一截。3.4 代码审查员岗把“帮我看看代码”变成工程化审查这个岗位我墙裂推荐。Code Reviewer这个Skill内置了四种审查维度安全性有没有SQL注入、XSS这些隐患、性能有没有明显的时间复杂度过高、多余的IO操作、可读性变量命名、函数拆分、边界条件有没有处理空值、超限输入。实际用下来它对边界条件的审查最有价值。我自己写代码的时候最容易漏的就是边界情况——比如用户输入为空、列表元素为零、并发量突增。Code Reviewer每次都能补一刀“这里如果传入的list为空会怎样”就这一句话就能帮我挡住很多低级bug。Security Scanner是我后加的偏安全审计。它会模拟攻击者的思维方式检查代码里有没有安全漏洞。说实话它对复杂漏洞的识别能力有限但查常见的配置错误、弱密码硬编码这类问题绰绰有余。3.5 测试工程师岗比很多手动测试都靠谱Test Case Designer这个Skill它生成测试用例的水平比我认识的一些初级测试还强。它会根据功能描述自动输出正常流程、异常流程、边界条件三大类测试用例每条用例包含测试步骤、预期结果、优先级。举一个我在实际项目中遇到的例子。我给一个文件上传功能让它写测试用例它除了基础的上传成功/失败之外还生成了上传空文件、上传超限文件、上传特殊字符文件名、并发上传十个文件、在弱网状态下上传……总共12条用例其中有三条是我自己根本想不到的。Playwright助手是配合E2E测试用的它能直接生成可在Playwright框架里跑的自动化测试脚本支持浏览器自动化操作。这个配置能帮我把测试工程师岗的产出无缝衔接到CI流水线里。3.6 文档工程师岗项目收尾不用再焦虑写README这件事很多开发者都讨厌我也不例外。README Generator这个Skill内置了优秀README的结构模板项目简介、功能特性、技术架构、快速开始、目录结构、部署说明、常见问题。你只需要提供项目背景和代码库结构它就能产出一份像模像样的README。Doc Translator则是我发现的一个小宝藏它不只是做机械翻译而是会按照英文技术文档的写作习惯重新组织语序和段落结构。我最近在整理一份技术方案投稿用这个Skill把中文版转成了英文版翻译质量比我自己逐句翻的流畅得多。3.7 数据分析师岗和专利辅助专员岗数据分析师岗我并没有用得太重主要就是Data Analyzer和Log Miner两个Skill在处理运维日志、性能测试数据这类活。Log Miner能从一堆日志里快速提取错误模式、统计频次、定位异常时间点排查问题的时候特别好用。专利辅助专员岗可能是所有人里最特别的我自己在做的项目涉及一些创新方案需要整理专利交底书。Patent Drafting Assistant这个Skill能根据技术方案描述生成交底书的框架技术领域、背景技术、发明内容、实施方式、技术效果。它不会替你写出专利内容——这也不应该——但能帮你把思路结构化把空白框架填好节省大量从零开始的整理时间。Claim Mapper则是辅助梳理权利要求层次关系的帮助我看到哪些技术特征是必要技术特征、哪些是附加特征。4. 最值得装的12款Skill直接给你清单30多个Skill装了这么久真要让我推荐给普通用户我会压缩到12款以内。再多就是负担而且维护Skill的成本会吃掉你用AI省下的时间。4.1 编程开发类立刻能提效的6款Skill名称解决的问题适合人群Code Generator从需求直接生成代码框架全栈/后端开发Code Reviewer结构化代码审查避免低级bug有Code Review需求的团队Bug Fixer根据报错信息定位并修复问题日常需要调试的人API Designer快速产出RESTful接口文档前后端协作场景Unit Test Writer自动生成可运行的单元测试有测试覆盖率要求的项目Refactoring Assistant在不动功能的前提下优化代码结构老代码维护者4.2 文档与知识管理类多花5分钟省出半天Skill名称解决的问题适合人群README Generator按优秀开源项目标准生成README开源项目维护者Doc Translator高质量技术文档中英互译经常接触英文文档的开发者Meeting Notes Summarizer把会议记录整理成决议和Todo List经常开会的人Knowledge Base Builder把零散笔记整理成结构化知识库Notion/Obsidian用户Patent Drafting Assistant生成专利交底书框架有专利申请需求的研发人员WorkBuddy Skill把工作流封装成标准化任务模板想沉淀团队SOP的人4.3 这几个Skill别乱装这里单独提醒一句。市面上有一些Skill打着“万能”“全自动”的旗号宣称能“自动挖掘漏洞”“无限制聊天”我一律不碰。原因很简单这类Skill往往通过绕过模型安全限制来“增强能力”本质上是在制造风险而且一旦模型方升级安全策略这类Skill会立刻失效你依赖的流程就全断了。真正稳定可靠的Skill一定是帮助把任务做得更专业、更标准化的而不是去钻安全空子。Skill和Agent的区别也顺带说一下Skill是单点能力的封装Agent是能自主决策、多步骤执行的工作流本体。你可以理解为Skill是工具Agent是用工具干活的人。我这一套“岗位制”其实就是用Agent的思路去编排Skill但更轻量、更可控。5. Skill怎么装、怎么自定义连Prompt都不用写的高级玩法5.1 Skill安装的常见姿势Skill的安装方式取决于你用的是哪套生态。以编程助手类Claude Code、Codex等为例子最常见的安装方式是这样的把Skill文件通常是一个包含系统提示词和示例的markdown文件或者是一个带目录结构的文件夹拷贝到指定的skills目录下然后在对话中通过“skill名”或者让它自动触发。具体的目录结构大致是~/.config/my-ai-assistant/skills/ ├── code-review/ │ ├── SKILL.md # 核心提示词描述这个Skill的职责、工作流程、输出格式 │ └── examples/ │ └── review_example.md # 给AI参考的输入输出示例 ├── readme-generator/ │ ├── SKILL.md │ └── templates/ │ └── template.md └── ...SKILL.md是灵魂它会告诉AI你是做什么的、什么时候被触发、应该遵循什么步骤、输出格式长什么样。有的Skill还支持内置参考文件、代码模板甚至预置一段工具调用的配置。5.2 自己写一个Skill到底难不难在Skill生态里有一类特殊的角色叫Skill Creator它本身就是一个Skill——用来帮用户编写新的Skill。它会在你和它对话的过程中自动采集你的需求、整理工作流程、生成SKILL.md文件整个过程基本不需要你手动写Prompt。我拿自己制作“专利交底书辅助Skill”的经历来还原一遍过程。我一开始只是把自己做交底书常年用的框架整理成了几段文字然后丢给Skill Creator说“帮我把这段流程封装成一个Skill”。它先是问了我几个问题触发场景是什么、输入信息有哪些、输出格式要不要固定、要不要加示例。然后自动把治理框架转化成了一个标准化SKILL.md连示例文档都帮我生成了。前后大概15分钟一个专属Skill就落地了。这个流程的价值在于它让Skill的定制门槛降到了几乎为零。你不需要懂Prompt工程不需要会写代码只要你脑子里清楚“我平时做这件事的步骤是什么”就能把它沉淀成一个Skill。5.3 Skill触发与调用的两个细节细节一明确触发场景。SKILL.md里最好写清楚“当用户要求做XX时你必须启用此Skill”这样模型才能准确识别。细节二示例比描述更重要。给AI看两个好的输入-输出示例比在描述里说一百句“请按照专业格式输出”都管用。Skill定制时宁可多花点时间准备示例也不要执着于把描述写得漂亮。6. 踩坑记Skilled的5个经典翻车现场和排查办法装了30多个Skill踩坑无数。这5个问题是出现频率最高的也是新手最常遇到的。6.1 Skill之间互相打架AI不知道该听谁的这是我早期最头疼的问题。两个Skill的职责边界模糊比如Code Generator和Spring AI助手都声称自己负责“生成代码”。当用户提出一个Spring AI相关的开发任务时AI有时候会用Code Generator的通用模板生成代码而完全不调用Spring AI助手的专业提示词。排查思路打开Skill配置文件检查触发条件trigger的description确保每个Skill的触发场景没有重叠。我当时把Code Generator的触发描述改成了“当用户要求生成通用代码框架时”把Spring AI助手的触发描述改成了“当用户明确提到Spring AI框架或相关技术栈时”冲突就明显缓解了。6.2 装了Skill之后AI变“笨”了输出不如不装这个现象通常发生在Skill的SKILL.md写得过于冗长、约束过多时。模型被过度的指令捆绑反而失去了泛化能力。我碰过一次给一个文档类Skill塞了十几条输出规则结果AI生成的README连基本的信息架构都丢了比用默认Prompt还差。排查思路删掉SKILL.md里的冗余指令只保留核心流程和硬性要求。如果一条规则去掉后不影响输出结构那它就是多余的。6.3 Skill在部分场景不触发怎么叫都不出来Skill不触发的原因80%是触发描述写得太窄。比如你写“当用户请求生成README时”但用户实际说的是“帮我把项目的说明文档写了”模型可能就识别不到。排查思路把触发条件改写成覆盖多种表达方式的版本比如“当用户请求生成README、说明文档、使用指南、项目介绍时你必须启用此Skill”。还可以在对话里用“Skill名”的形式手动强制调用这是最简单直接的兜底方案。6.4 Skill只认英文中文输入时效果打折不少社区下载的Skill默认是针对英文环境优化的你用中文提问时AI会机械地套用英文Prompt里的输出格式导致中文交互场景下结果很别扭。排查思路要么找中文优化过的Skill版本要么自己改SKILL.md把输出格式和示例改成中文。这类问题通常在社区的评论区能看到反馈选Skill时多看一眼有没有中文用户的使用反馈。6.5 更新Skill时发现配置格式变了老文件不兼容Skill生态还在快速演进配置格式说变就变。我遇到过两次一次是某个字段被改名一次是示例文件的目录结构从单文件变成了多文件导致所有旧Skill无法加载。排查思路更新Skill之前先备份更新之后用最小任务验证一遍是否能正常触发。另外尽量选择维护活跃的Skill仓库star高、更新频繁的通常更靠谱。7. 给Skill写一份“岗位说明书”的实操模板很多教程会告诉你“怎么装Skill”但很少告诉你“怎么给Skill定规矩”。其实Skill装完之后还有一道关键工序给它写一份岗位说明书。我基于实践总结了一套模板你可以直接复用。# 岗位名称XXX ## 触发条件 当用户要求[做某事]时你必须启用本Skill。 等同表达的触发词[同义词列表] ## 工作流程 1. 第一步收集输入信息缺什么问什么不要猜 2. 第二步按照XX顺序逐项处理 3. 第三步输出XX格式的结果 ## 输出格式 - 必须包含字段A、字段B、字段C - 可选包含字段D - 不得包含无实质内容的套话 ## 质量基线 - 输出的内容必须达到以下标准[三条以内如结构完整、数据准确、逻辑自洽] - 禁止输出[明确禁止的行为如猜测不存在的数据、跳过边界情况分析] ## 参考示例 [附2-3个高质量输入输出示例]用这个模板写完SKILL.md后我的意思是从头到尾别偷懒——触发条件一定要写清楚工作流程一定要具体到步骤参考示例一定要真实。我自己早期就是嫌麻烦随便写几段话塞进去结果Skill的触发率和输出质量很不稳定。花20分钟把岗位说明书写好后面能省出十倍的调教时间。8. Skill岗位制的下一步从“调用工具”到“沉淀团队”30多个Skill、8个岗位这套体系跑顺之后我又琢磨了另一件事这些Skill能不能进一步沉淀成一支可复用的“AI团队”让协作流程自动化目前Skill的主流使用方式还是“人在回路”——人判断该叫哪个Skill然后手动触发。但Skill生态已经在往更复杂的“多Skill协同”方向走了。比如有的Agent框架支持在Skill内部调用另一个Skill相当于一个岗位在干活的时候能把它的上下游岗位一起拉起来。一旦这条链路跑通AI团队就不是我手动编排而是任务驱动式的自动编组。我试过在几个开源Agent框架里搭这种调度逻辑用下来有一个很明显的感受岗位说明书写得越细调度成功率越高。之前我总觉得Skill写个大概就行但现在我回头看凡是触发逻辑模糊、输出格式不固定的Skill在自动化协作里基本就是哑弹。所以如果你真的打算长期用Skill这套体系我的建议是从一开始就把每个Skill当做一个正式员工来管理。写清楚的职责说明、明确的触发条件、固定的输出格式、可复用的参考示例。这不是形式主义这是让AI团队从“能用”走向“好用”的唯一路径。另外提醒一句Skill生态迭代非常快我写这篇文章时用的工具和配置可能过几个月就会有变化。但“给AI定岗位、按岗位配Skill、用说明书管协作”这个思路我觉得是经得起时间考验的。工具会变流程会变但把AI当成团队成员来管理的底层逻辑不会变。