1. 当Skill变成员工的“职业技能证书”最近半年我一直在折腾一个方向把AI从“一个能聊天的模型”改造成“一个能干活的下属”。标题里的“装了30多个Skill给AI安排了8个岗位”就是这次折腾的阶段性成果。所谓Skill你可以理解为给AI额外安装的“职业技能包”。就像给员工发一本岗位说明书加一套工具清单你告诉AI“你现在的角色是代码审查官你需要先把diff拉出来再按这5个维度逐条检查发现问题要给出修改建议而不是只丢一句‘看起来不错’”。装完Skill之后AI在对应场景里的输出质量跟我裸用默认模型完全是两个水平。为什么非要这样干原因很简单默认的AI是“通才”什么都懂一点但不会主动按你的规范去执行。你让它审查代码它可能只扫一眼语法你让它写专利交底书它可能给你编出一堆不符合格式要求的“技术方案”。而Skill做的事情就是把“行业规范团队SOP个人偏好”固化成模型能直接调用的指令资产。装30多个Skill本质上是在给AI构建一套“岗位能力矩阵”。这篇文章就围绕这套实践来写重点拆解三件事一是8个岗位到底怎么划分、每个岗位挂载了哪些Skill二是Skill安装、配置、管理的完整实操过程三是调试过程中踩过的坑怎么排查。适合正在玩Claude Code、Codex、Cursor等AI编程工具想把AI从“玩具”变成“生产力工具”的同学参考。2. 从“会聊天”到“有岗位编制”思路转变是关键2.1 一门手艺一个SkillAI能力的颗粒度游戏刚开始玩Skill的时候我犯过一个挺典型的错误想搞一个“万能Skill”把所有需求都塞进去。结果就是这个Skill的指令文件超过500行模型加载之后反而变得迟钝遇到具体任务不知道该调哪条规则。后来我换了个思路按“手艺”拆分不按“岗位”合并。做饭的归做饭摆盘的归摆盘切菜的归切菜。每个Skill只负责一件非常具体的事描述写得精准触发条件写得清晰剩下的交给模型自己去组合调用。举个例子同样是在“代码审查”这个岗位上我装了三个Skill各管一段diff-review只分析git diff检查改动本身有没有引入bug、风格是否统一。security-scan专注安全漏洞比如SQL注入、越权、敏感信息硬编码。architecture-check站在全局视角看这次改动是否破坏了原有架构边界。这三个Skill分开装工作时可以按需调用也可以组合起来一起跑。效果就是AI审查同一段代码能从三个完全不同的角度输出意见覆盖面比单人审查还全。2.2 30多个Skill怎么管理没有目录结构一定会翻车装了30多个Skill之后第一个现实问题就是找不到、分不清、改不动。我的解决方案是建立明确的目录分类绝对不能把所有Skill平铺在一个文件夹里。目前我的Skill仓库长这样skills/ ├── 01-code/ # 编程开发类 ├── 02-docs/ # 文档撰写类 ├── 03-review/ # 审查评审类 ├── 04-data/ # 数据分析类 ├── 05-patent/ # 专利与知识产权 ├── 06-test/ # 测试与质量保障 ├── 07-devops/ # 运维与部署 └── 08-creative/ # 创意与内容生成分类的逻辑跟公司组织架构对齐——“8个岗位”就是8个一级分类。每个分类下面挂3到5个Skill对应岗位的具体技能。这样无论是手动管理还是写脚本批量检查都非常方便。2.3 Skill和Agent的区别一个像“技能”一个像“人”这个话题在网上讨论得很多我说说我自己的理解。Skill是“能力包”它定义了AI能做什么、按什么流程做Agent是“执行体”它决定AI什么时候调用什么能力、任务进行中如何决策。打个比方Agent是员工Skill是员工手里的工具箱。员工决定“这个任务需要扳手还是螺丝刀”然后从工具箱里取用。如果只有Agent没有Skill员工就只能赤手空拳上阵如果只有Skill没有Agent工具摆了一地但没人知道该用哪个。在实际落地中我通常用Agent来定义一个岗位角色比如“后端开发专家”然后在Agent的配置里挂载对应的一组Skill比如python-dev、api-design、performance-tune。这样分工清晰职责明确也方便做权限控制。3. 8个岗位的岗位说明书Skill组合实战拆解3.1 岗位一代码审查官Code Reviewer这套岗位是ROI最高的。以前我带团队做Code Review最耗时的就是逐行过diff现在这部分基本交给了AI预审。挂载SkillSkill名称职责说明触发场景diff-review分析git diff检测逻辑错误、遗漏边界条件提交PR/MR时security-scan检测常见安全漏洞给出修复建议涉及用户输入、权限、加密的改动style-enforcer检查代码风格是否匹配团队规则合并前最终检查这套组合跑下来AI会先输出一份带风险等级标注的审查清单标注每个问题的文件位置、行号、问题类型、修改建议。最明显的改善就是团队里那种“低级错误合并进主干”的情况基本绝迹了因为AI审查的重点恰恰是“语法没问题但逻辑有坑”的隐性错误。3.2 岗位二技术方案架构师Solution Architect这个岗位解决的是“拿到需求不知道从哪下手”的问题。挂载的Skill偏向分析和方案设计requirement-analyzer把模糊的需求描述拆解成功能点、边界条件、非功能需求。tech-selector根据技术栈、团队规模、维护成本给出选型建议。api-designer设计RESTful API的路径、参数、响应结构直接输出OpenAPI规范。我常用的工作流是这样接一个需求之后先让requirement-analyzer跑一遍产出一页纸的需求分析再让tech-selector给出技术选型的对比表最后让api-designer生成接口草案。这三步跑完需求评审会的底稿基本就有了开发团队拿到就能开工。3.3 岗位三自动化测试工程师QA Engineer这个岗位帮我补了不少测试覆盖率上的空白。挂载的Skill有test-case-generator根据代码函数自动生成边界值测试用例。selenium-writer生成端到端测试脚本输出可直接运行的Python代码。coverage-analyzer分析测试覆盖报告定位未被覆盖的关键路径。实际操作中test-case-generator跑一遍能覆盖我自己写用例时经常会漏掉的空指针、越界、参数为空等场景。测试用例生成完之后我只需要做两件事去重、调节期望结果。省的时间非常可观。3.4 岗位四专利与知识产权专员IP Specialist这个岗位比较小众但价值极高。我在科技企业做过专利挖掘最大的痛点就是发明人描述技术方案时要么太抽象要么太细节永远不符合专利代理人的撰写格式。我自定义了一个patent-draftSkill内置了一套专利交底书的标准框架技术领域、背景技术、发明内容、技术方案、有益效果、具体实施方式。同时用Few-shot把两个历史专利作为参考案例写进Skill里。这样AI在生成交底书时格式和描述口径高度统一代理人拿过去能直接改不用推翻重写。另配一个patent-searchSkill辅助做前案检索分析列出潜在对比文件的关键特征帮发明人初步判断新颖性。3.5 岗位五文档工程师Technical Writer程序员讨厌写文档但文档又是刚需。这个岗位的Skill组合如下readme-generator扫描项目代码生成结构清晰的README。api-doc-formatter根据代码注释或OpenAPI文件生成接口文档。changelog-writer对比git commit记录自动生成版本更新日志。changelog-writer是最省心的一个每次发版前跑一条命令AI把commit message归类整理成“新增/修复/优化/破坏性变更”的结构化日志。以前这个活要花半个多小时手敲现在20秒搞定。3.6 岗位六数据分析师Data Analyst分析类的Skill重点在于“把脏数据整理成清晰结论”。我挂了这几个>--- name: sql-writer description: 根据自然语言需求生成SQL查询要求附带解释和边界条件提示。 version: 1.2.0 author: your-name tags: [sql, database, analysis] --- # SQL Writer ## 功能 将用户的自然语言问题转换为可执行的SQL查询并输出执行计划说明。 ## 使用时机 - 用户希望通过数据分析回答业务问题时 - 用户需要快速获取某个数据指标时 ## 执行步骤 1. 明确用户的业务问题和数据口径时间范围、指标定义、维度拆分。 2. 查看数据库Schema确认涉及的表和字段。 3. 生成SQL注意 - 使用JOIN时明确关联键 - 涉及聚合时按业务口径正确使用GROUP BY - 时间字段先明确时区 4. 输出格式 - SQL代码块 - 执行逻辑说明 - 潜在坑位提示如NULL值处理 ## 禁止事项 - 禁止在未确认Schema的情况下直接生成SQL - 禁止将生产库表直接暴露在输出中重点说一下YAML front-matter里的description字段这个字段非常关键——模型靠它来判断“当前这个Skill该不该触发”。如果description写得太泛比如“处理各种问题”那模型在几乎所有任务里都会尝试加载这个Skill既费token又容易干扰主任务如果写得太窄则容易漏触发。我吃过的亏是description写得太长模型无法快速抓取要点后来统一格式改成“做什么什么时候用”匹配率提升非常明显。4.3 在Claude Code中安装并运行Skill真实命令全流程以用户级目录的安装为例完整流程如下# 1. 创建用户级Skill目录 mkdir -p ~/.claude/skills # 2. 将Skill文件复制到目录中 cp -r /path/to/downloaded/sql-writer ~/.claude/skills/ # 3. 检查目录结构是否正确 tree ~/.claude/skills/sql-writer # 确认存在 SKILL.md 文件 # 4. 在当前项目中测试Skill是否被加载 cd /your/project claude # 然后在对话中输入 # /skill list如果在对话中执行/skill list能看到sql-writer说明加载成功。接下来可以直接提一个需求测试效果比如“统计上周每天的新增用户数按渠道拆分”看输出的SQL是否符合预期。4.4 在Codex中配置Skill同样是用目录扫描机制Codex这边的配置逻辑类似但目录名是skills位置略有差异# Codex全局Skill目录 mkdir -p ~/.codex/skills # 复制Skill cp -r sql-writer ~/.codex/skills/ # 在项目里启用 cd /your/project codex # 在对话中可以直接描述任务模型会根据description自动加载对应Skill提示如果你同时在用Claude Code和Codex建议维护一份Skill源仓库然后通过符号链接symlink或者拷贝脚本同步到两个工具的目录里避免两边手动维护造成版本不一致。5. 开发自定义Skill把“知其所以然”变成AI的肌肉记忆5.1 提炼SOP而不是堆砌规则写自定义Skill最核心的不是会YAML语法而是能把日常工作流程“结构化”。我开发patent-draft这个Skill的过程值得展开讲讲。第一步我找了一份已经授权的高质量专利交底书逐段拆解它的结构标注出每个段落的意图和常见写法。第二步把公司研发团队描述技术方案的常见混乱点列出来比如“把背景技术写成产品宣传”“把发明点堆在具体实施方式里”。第三步把这两部分整理成“结构模板正误对比补充提示”写入SKILL.md。这样AI拿到一份研发人员自述能自动按专利交底书框架重新组织语言把“这个技术通过一个模块实现”改写成“一种xxx方法其特征在于包括步骤一……步骤二……”。写出来的初稿基本达到了能交给代理人改稿的级别。5.2 用Few-shot让Skill“一次就懂”Skill里的reference目录就是用来放Few-shot样例的。我给大多数Skill都配了1到3个参考案例每个案例包括“输入-输出”对照。以changelog-writer为例我在reference里放了三种commit风格的输入以及对应的changelog条目写法。这样模型生成的日志风格稳定不会出现“修复了一个问题”这种模糊表达而是“修复订单模块在并发场景下重复创建记录的竞态条件”。5.3 版本控制与变更记录Skill也是代码严重建议给每个Skill加version字段并且用git管理整个Skill仓库。我踩过的一个坑有一次给security-scan更新了检测规则结果发现某些正常代码被误报为“潜在注入风险”捉了半天才发现是规则写得太激进。后来回滚版本就恢复正常。有了git历史每次改完Skill都能做对比测试确认没引入回归再发布。6. 常见问题速查表与排查心法6.1 典型问题一览没生效、乱触发、上下文爆掉问题现象可能原因解决方法Skill装了但没反应目录路径不对或SKILL.md缺失用/skill list检查加载状态确认文件在正确目录模型不按Skill流程执行description写得太泛或太窄重写description明确触发场景和预期输出多个Skill同时被触发description重叠严重重新界定各Skill的边界用否定句式排除生成内容质量不如预期缺少Few-shot参考样例在reference目录添加1到3个高质量示例上下文窗口不够用每个Skill都被加载token开销大精简SKILL.md把详细内容移到reference按需读取生产环境执行了错误操作Skill缺少安全护栏在配置文件里加“禁止事项”列表并增加二次确认流程6.2 排查Skill不生效的三个步骤步骤一确认Skill真的被加载。用命令/skill list或者查看对话启动日志看有没有“Loaded skill: xxx”的记录。如果没加载九成是目录放错或者文件名不对。步骤二确认模型读取到了SKILL.md。把Skill里的description原样复制到对话里问“你觉得这个描述适合触发吗”看模型是否理解正确。如果模型答非所问大概率是front-matter格式有误重点检查YAML缩进和冒号。步骤三确认执行路径有没有被用户指令覆盖。有时候用户直接给了一个非常具体的指令优先级高于Skill的默认流程。这种情况下Skill里的规则会被“绕过”。解决办法是在Skill里写明“即使收到其他指令也务必保留以下环节”。6.3 上下文爆炸问题Skill是耗token大户Skill加载本身就要消耗至少几百个token如果每个任务都把所有Skill加载一遍上下文很快就会被撑爆。我的经验是按岗位启用同一个会话只加载一个岗位的Skill集合不要跨岗位混用。比如“今天只做代码审查”就只带代码审查相关的Skill。善用reference目录SKILL.md只保留指令概要长文档放reference里模型按需读取。定期清理每次会话结束时看一眼加载了哪些Skill如果某个Skill从来没有真正被用到就检查它的description是不是形同虚设。7. 一套可以“直接抄作业”的Skill管理清单折腾了几个月之后我把这套流程沉淀成了一份清单分享出来供大家参考。7.1 安装新Skill前的检查清单这个Skill解决的是不是一个“重复出现3次以上”的问题它的边界是否与已有Skill重叠description是否按“做什么何时用”格式写清楚reference目录是否放了至少1个高质量样例是否加上了version和author元信息放在项目级还是用户级目录7.2 引入团队协作时的注意事项如果要把这套玩法推广给团队有几个坑一定要提前避人员培训成本不是所有人都习惯“用指令跟AI协作”先挑两三个对AI工具熟悉的同事做试点。Skill的版权与保密如果Skill里内置了公司内部的最佳实践切记不要直接推到公开仓库自建私有仓库管理。质量回退机制每个Skill发布之前用一套固定的测试用例做回归防止“升级反而变笨”。7.3 Skill后续还能怎么扩展目前我在尝试的方向是把团队历史代码评审记录清洗成数据集微调一个针对性的审查偏好注入到Skill里。另外也在研究如何让Skill自动调用外部API比如通过scripts/目录里的Python脚本拉取监控数据再基于数据生成分析报告——这一步能做通的话“AI员工”就能从“靠脑子干活”升级成“手脚并用”干活了。