1. 先说结论30多个Skill我是怎么攒出8个“AI同事”的如果你最近在逛AI编程和Agent社区应该对Skill这个词不陌生。GitHub上涌现了大量skill脚本、skill插件、skill creator工具Codex和Claude Code都开始把Skill作为标准化配置。我手里的活不算少——既有日常的代码项目又要写方案、做测试、处理数据、盯着CI跑构建。在上个月之前我的做法是给AI开一堆对话窗口每个窗口贴一长串提示词告诉它“你现在是架构师”“你现在是测试工程师”。结果一天下来光是复制粘贴提示词就花掉我大半个小时上下文一长角色设定还经常跑偏。后来我研究了一下Claude Code和Codex的Skill机制装了30多个Skill把AI的角色固定成了8个岗位架构评审、代码审查、测试设计、文档撰写、运维值班、数据清洗、提示词调优、安全巡检。说白了就是把原本写在对话框里、每次都要重新粘贴的一大段人设和行为规范抽成一个独立的文件夹里面装满规则、示例、脚本、配置让AI在干活的时候自动加载。这样做的直接收益是我不用再反复解释“你是谁、你要干嘛、你该按什么格式输出”打开项目AI自己就知道该用哪个岗位身份、哪一套流程来做事。这篇文章就把我这一个多月的折腾过程、踩过的坑、沉淀下来的配置方式一次性写清楚。先说结论Skill不是越装越多越好30多个Skill里真正高频使用的其实不到15个剩下的一半是特定场景才调用的备用岗。但正是这些“备用岗”让整个团队看起来完整——遇到专利交底书、数学建模题、论文润色这类比较偏的需求时直接叫对应岗位过来干活不用临时现教。2. 岗位设计方案从“一个人干八个人的活”到“八个人各干各的活”2.1 为什么要给AI分岗位而不是开8个对话框很多人觉得给AI设置角色不就是写个“你是一位资深架构师”就行了吗我刚接触Skill时也是这么想的但实际用下来发现完全不是一回事。普通提示词是“一次性对话设定”你这次说了下次还得说AI一旦在长对话里跑偏你可能要拉回好几次才能恢复它的人设。而Skill把角色设定从“提示词”升级成了“可复用的工程化模块”它不只包含角色描述还包含固定的检查清单、输出模板、常用命令、参考示例甚至可以直接触发脚本去做数据抽取、格式转换这类实际工作。岗位细分带来的另一个好处是上下文隔离。原来我让AI在一个对话里既写代码又写测试又写文档上下文很容易被无关内容污染写文档时思路总被之前的代码讨论带跑。现在每个岗位有自己的Skill目录和独立的启动方式干测试的就专注看测试干文档的就专注整理输出互不干扰。实测下来各岗位的输出质量比混在一个对话里明显高了一截尤其是文档撰写岗输出结构的稳定性提升非常明显。2.2 8个岗位职责表与对应Skill清单我最后定的8个岗位每个岗位配了2到6个Skill有主Skill也有辅助Skill。岗位职责明确分工清晰下面这个表是我活下来的真实配置字段包括岗位名、核心职责、主要Skill、常用触发场景给你做个参考岗位核心职责主要Skill常用触发场景架构评审评估项目技术方案、识别设计缺陷、给出改进建议architecture-review、risk-check新项目启动、大功能改造前代码审查检查代码规范、逻辑漏洞、边界条件pr-review、code-quality提交PR前、Code Review阶段测试设计生成测试用例、设计边界测试方案、执行测试脚本test-case-gen、math-modeling-test功能开发完成后、修复Bug后回归文档撰写生成技术文档、使用说明、注释规范docs-writer、readme-auto项目交付、模块完成、接口变更运维值班检查构建状态、分析日志、处理常见部署问题ci-monitor、log-analyzerCI失败、构建告警、日志报错数据清洗处理CSV/JSON等格式数据、去重、补齐缺失值>skills/ └── pr-review/ ├── SKILL.md # Skill的核心定义人设规则流程 ├── rules.md # 审查规则清单逐条列出检查项 ├── templates/ │ └── review-report.md # 输出报告模板固定格式 └── scripts/ └── diff-analyzer.py # 辅助脚本分析git diffSKILL.md是入口文件相当于岗位描述书里面写清楚这个Skill的职责、适用场景、触发方式和输出要求。rules.md是把审查要点逐条列出来AI在执行时会逐条对照检查避免漏项。templates目录放输出模板保证AI每次产出的报告结构一致。scripts目录放可以实际执行的脚本比如分析git diff、统计代码行数、提取日志关键字。注意不同工具对Skill目录的约定略有差异。以Claude Code为例它支持项目级和用户级的Skill目录Codex也有自己的Skill配置规范。但核心原理是一样的——用标准化的文件夹承载角色规则和工具脚本。建议你先在自己常用的AI编程工具里查一下官方文档确认目录路径再动手搭。3.2 一个标准SKILL.md长什么样拿我的“测试设计”Skill来举例这是当时从社区一个公开skill模板改出来的经过好几轮调优。精简后的SKILL.md是这样的--- name: test-case-gen description: 根据需求描述或代码变更生成覆盖正常、异常、边界场景的测试用例并按指定格式输出。 triggers: - /test - /gen-test --- ## 岗位定位 你是一名资深测试工程师擅长黑盒和白盒测试用例设计熟悉等价类划分、边界值分析、因果图等方法。 ## 工作流程 1. 读取输入的需求描述或diff文件。 2. 识别核心功能模块和输入参数。 3. 按等价类、边界值、异常链路三个维度生成测试用例。 4. 对每个用例标注优先级P0阻断级、P1主要功能、P2次要功能。 5. 输出测试用例表格式见 templates/test-case-template.md。 ## 注意事项 - 测试用例必须覆盖正常路径、异常路径和边界条件三个维度缺一不可。 - 输入参数为空、超长、类型错误等异常场景必须包含。 - 不确定的需求点在输出末尾加“待确认问题”清单不要擅自假设。这份定义的核心是把“角色”落到“流程”上——AI不需要凭空发挥它只要按流程执行输出质量就是稳定的。triggers字段定义了触发词我在命令行里输入 /test 就能直接唤起这个岗位。后面加“注意事项”板块是我自己总结出来的经验如果不显式告诉AI“必须覆盖哪些维度”它的输出会很飘有时只写正常路径边界和异常链路全漏了。3.3 Skill Creator怎么高效制造新Skill装到后面你会发现30多个Skill里有不少是从零写的。刚开始我一个个手写Markdown效率很低。后来用上社区里的Skill Creator工具流程变成给它一个种子描述比如“我要做一个专门检查Python代码里内存泄漏问题的Skill”它会自动生成SKILL.md的框架、规则清单和示例输出。我再根据自己的实际场景修改和补充一个可用版本的Skill从原来的一小时压缩到十几分钟。这里有个关键心得新写的Skill一定要用真实任务去“验收”。我写“数据清洗”Skill时第一次生成的版本连CSV编码都处理不好是拿一个5000行的脏数据文件反复跑了三轮才调顺。Skill不是写出来就完了它是需要“试用期”的至少要经历3到5次真实场景调用把暴露出的问题修掉才能称得上可用。4. 实操过程6个核心岗位的Skill配置与使用实录4.1 架构评审岗从“空谈架构”到“落到代码层”架构评审岗是我最早上线的岗位也是ALTER次数最多的一个。最初版本的SKILL.md只写了“你是资深架构师请评估项目风险”结果输出全是“系统存在潜在扩展性问题”这种正确的废话完全没有落地价值。后来我把规则细化成了三层检查第一层看依赖关系是否合理——有没有循环依赖、有没有版本冲突第二层看性能热点——有没有数据库N1查询、有没有明显无效的循环第三层看扩展性——新增需求时改动范围是否会蔓延到多个模块。同时我给它配了一个 diff-analyzer.py 脚本自动分析当前分支相对主干改动过的文件列表。这样AI在评审时不是凭感觉“通读全文”而是先分析diff再针对改动点做评估。现在的架构评审岗能给出比如“这个接口的加锁粒度太粗高并发场景下会成为瓶颈建议缩小到单key粒度”这种可执行的建议。改后的SKILL.md核心部分长这样## 工作流程 1. 执行 python scripts/diff-analyzer.py 获取当前分支改动文件清单。 2. 逐个模块审查重点检查依赖方向、性能瓶颈、扩展性影响。 3. 用 P0/P1/P2 标注问题严重级别。 4. 每个P0/P1问题必须给出推荐修复方案禁止只提问题不给解法。 ## 输出模板 - 评审结论通过 / 有条件通过 / 未通过 - 阻塞问题清单P0 - 主要问题清单P1 - 改进建议P2 - 总结三句话内概括评审结果这个岗位的实际效果是让我在开发早期就挡住了好几次大坑。有一次写一个数据同步模块架构评审岗指出我的方案在高一致性场景下会出现重复同步的问题建议改成幂等写入加版本号控制。改完后测试岗设计出来的用例确实把高频并发重复调用场景覆盖进去了这就是岗位协作带来的直接价值。4.2 代码审查岗把“这代码有点乱”变成可执行的检查单代码审查岗要解决的问题是怎么让AI的评审意见不流于表面。刚开始它的建议经常是“代码结构不够清晰建议重构”这种说了等于没说的话。后来我把规则拆成了五个维度——正确性、性能、可维护性、安全、测试覆盖。每个维度下再列一级检查项比如正确性下面会查有没有空指针风险边界条件有没有处理循环退出条件是否正确安全维度会查有没有硬编码密钥有没有拼接SQL有没有使用 eval 或类似危险函数现在PR评审的核心流程是这样我先在终端输入 /review触发代码审查岗它读取git diff按五个维度逐项筛查最后输出一份带P0/P1/P2等级的报告并给出每一条问题的修改建议。我只需要看报告决定改哪些就行不用自己逐行盯代码。说得夸张一点现在我没看过的PRAI先帮我筛了一遍小的低级错误基本不会再出现了。这里有一个小技巧代码审查岗的规则文件里我会把团队自己的代码规范片段直接放进去。比如“函数体超过80行必须拆分”“异常信息必须包含上下文关键参数”这类内部约定AI在审查时会严格按照这些规则检查比人肉盯有效得多。如果你有团队编码规范文档建议直接贴进去效果立竿见影。4.3 测试设计岗让用例覆盖“正常异常边界”三件套测试设计岗是我从社区skill模板改出来的但比原版加了很大强度的约束。原版只会生成简单的成功路径用例缺乏对边界值和异常链路的覆盖。我改造后的SKILL.md明确要求按三个维度生成用例正常路径、异常路径、边界条件。以登录功能为例正常路径是输入正确用户名密码登录成功异常路径包括密码错误、用户不存在、账号锁定边界条件包括密码长度为恰好最小值、用户名长度恰好为最大值、连续多次输错后的锁定阈值前后。为了让这个岗位更贴合实际我把“数学建模”里学到的等价类划分和边界值分析方法直接写进了它的rules.md。这个岗位的用途不只是单元测试还能辅助写集成测试和压测场景。有一次拿它帮我设计一套接口压测的测试数据它按边界值方法生成了从0到10万的并发参数组合帮我提前暴露了几个大数据量下的性能瓶颈。这个岗位的产出稳定之后我明显感觉到测试漏测的情况少了。4.4 运维值班岗从“盯着CI看”到“AI帮我盯”运维值班岗算是第二梯队里使用频率较高的岗位了。它的核心功能有两个一是读取CI日志和错误堆栈快速定位失败原因二是监控构建状态在构建失败时自动分析是代码问题还是环境问题。我给它配了 log-analyzer.py 脚本可以在几秒内从几百行日志里提取出关键error和warning分析出现频次最高的错误来源。有一次夜间构建失败早上我来查看时运维值班岗已经生成了分析报告构建失败原因是某个测试用例在特定时区下时间断言失败还附上了修复建议。这个岗位的SKILL.md里我特别加了“禁止猜测”的规则——如果日志信息不足以定位问题必须明确列出缺失信息并给出下一步排查方向而不是直接给一个没有根据的结论。这个规则对运维场景尤其重要AI“一本正经地胡说八道”在运维领域危害极大。4.5 文档撰写岗唯一差点被我删掉又救回来的岗位我得诚实说文档撰写岗一开始效果很烂。第一版SKILL.md只要它“根据代码写文档”结果它写出来的README全是表面话结构难看深度也不够。我一度想把这个岗位删掉。后来我想通了文档写不好的原因不在AI而在我没交代清楚读者是谁、格式是什么、深度要到哪。重新设计后的文档撰写岗收到的是这样的输入模块路径、目标读者终端用户还是开发者、文档类型README/接口文档/变更日志、参考模板。输出时必须按模板走包含概述、安装/依赖、快速开始、API说明、常见问题五个部分。改完之后质量直线上升。我现在每次完成一个模块都会触发文档撰写岗更新对应文档文档从“可有可无”变成了“真正能帮到下一个接手的人”。4.6 安全巡检岗每行配置都可能是漏洞安全巡检岗是我在部署一个内部工具后专门加的。当时我手动检查了一遍配置发现3个潜在问题一个是把API密钥硬编码在配置文件里一个是使用了已公开漏洞的依赖版本还有一个是在日志里打印了敏感字段。这些如果靠人查费时间不说还容易漏。后来我把这三点沉淀成了安全巡检岗的检查规则再配合社区安全审计相关的skill做依赖漏洞扫描每次上线前跑一遍基本能把大部分常见问题自动拦下来。这个岗位的SKILL.md里塞进了一个检查清单硬编码密钥、危险代码模式、日志敏感信息、依赖版本漏洞、越权接口设计。每次巡检会输出一份安全报告按严重程度分级并给出修复建议。安全巡检岗跟代码审查岗有部分职责重叠但我把它们分开是有意的——代码审查偏向代码质量安全巡检偏向安全和合规风险两者视角不同、检查重点也不同。5. 装了30多个Skill之后有哪些问题想劝退你5.1 Skill装太多AI也会“选择困难”30多个Skill装完第一个遇到的实际问题就是触发冲突。我最早是把所有Skill的triggers都设置成短单词比如 /test、/doc、/review结果有一次我在跟AI讨论测试方案时输入了“我们跑个test看看”它直接把测试设计岗的Skill加载进去了整个对话突然切换到用例生成模式非常打断思路。后来我统一把触发词改成带前缀的形式例如 /skill-test、/skill-doc、/skill-review冲突问题就基本消失了。另一个问题是上下文被不必要的Skill占用。某些Skill的SKILL.md特别长加载时会消耗大量上下文窗口如果一次对话里无意中触发了多个Skill上下文很快就被塞满。我的解决办法是在SKILL.md里做“精简版”和“完整版”两层设计SKILL.md只放最核心的角色和流程详细规则放在rules.md里只有在需要深入执行时AI才会去读完整版规则。这样既保证了触发快又不会浪费上下文。5.2 Skill上线前必须有“试用期”否则你就是在给自己埋雷我踩过一个非常典型的坑写好的“数据清洗”Skill第一次上线就因为编码问题导致输出了一批乱码数据当时我没仔细核对就直接用了结果下游分析全被污染。从那以后我给自己定了一条铁律新Skill上线前必须经过至少3次真实任务验证完成一次“验收”。验收标准包括输出格式稳定、关键规则覆盖完整、异常输入能给出对警示而不是乱来。这个“试用期”机制的价值在维护和迭代旧Skill时同样适用。Skill不是写完就能一劳永逸的。我每两周会过一遍高频使用Skill的产出质量如果发现某个岗位最近输出出现了“正确但无用”的迹象就说明SKILL.md里的规则可能已经跟不上需求了需要更新这一版的检查项或输出模板。5.3 安全边界Skill里别塞敏感信息别让AI越权执行这一点我必须单独说。Skill是放在项目目录里的文件如果项目代码需要提交到远端仓库而你的Skill目录里塞了内部API地址、账号信息、内网配置那就等于把这些敏感信息一起提交上去了。我的做法是Skill里只写规则和流程模板所有敏感信息用环境变量引用比如 {{API_KEY}}、{{DB_HOST}} 这样的占位符真正执行时从环境变量读取。另外一个边界是不要赋予Skill执行高风险的命令。我自己设置安全巡检岗时刻意禁止它在没有明确授权的情况下执行删除类操作、修改git历史、批量改写文件等高风险命令。Skill本质上是算法在替你调用代码如果权限范围失控一个小小配置失误可能引发一连串连锁效应。注意任何Skill配置都要先确认运行环境支持到什么程度不要默认AI能主动执行所有命令。尤其是涉及文件删除、网络请求、外部API调用这类操作时默认要加“需要用户确认”的前置条件。6. 给想抄作业的人最小可用方案和一点真心建议6.1 不想装30个那先装这6个30多个Skill听上去很唬人但真正常用的其实就那么几个。如果你想低成本试水我建议只装这6个就能覆盖日常开发的大多数场景代码审查、测试设计、文档撰写、架构评审、安全巡检、数据清洗。这6个岗位串起来基本就是一个小型研发团队的标准配置了。Skill的数量不是关键关键是每个Skill的规则有没有写到“能实际干活”的深度。与其草率地装50个废Skill不如把10个核心Skill调优到80分以上。另外Skill生态变化很快经常有新的skill模板出来后能明显提升效率。像skill creator、archify skill这类工具价值在于能帮你快速生成结构完整的Skill基础框架。我自己的做法是遇到新工具先不急着装先看它的SKILL.md结构和社区反馈明确它对标解决什么问题再决定要不要加入我的“团队”。6.2 装了30多个Skill后我最大的感悟如果你问我这一个月值不值我会说值但前提是你要有耐心去调试、去维护。给AI分岗位的本质是把原来模糊的、随性的对话式协作变成结构化的、可复现的工程化协作。Skill真正的价值不在于“让AI记住自己的角色”而在于让AI变成一个可以被独立调用、独立验证、独立迭代的“功能模块”。最后分享一个小技巧我会定期把一个周末的时间专门用来“优化团队配置”——把手头Skill的SKILL.md逐个过一遍看哪些规则在最近的项目里完全没用到哪些输出模板可以进一步精简哪些岗位之间出现了职责重叠。这个过程有点像软件的版本升级每次升级完整套系统的效率都能往上走一个台阶。希望这篇分享能给你一些参考也欢迎你在自己的项目里试试这套思路折腾出自己的“AI团队”。