热榜上的 Skills 文章大多是一种：「这10个必装，效率翻倍」。但没人讲装完之后会发生什么------skill 之间打架、AI 该用的时候不用、不该用的时候乱用，最后你还得给它收拾烂摊子。
我也装了30多个，同样经历过"什么火装什么"的阶段。后来我不收藏了，改成给每个 skill 安排一个岗位：它只负责我前端工作里的一个环节，别的环节不许碰。现在这个8人团队跑着我日常的开发全流程，这篇文章就把分工表公开。
为什么你装的 Skill 不干活
先说两个我踩过的坑，你可能正在踩：
- description 写成广告页。「一个强大的助手，能帮你做X、Y、Z」------AI 看完还是不知道什么时候该用它。技能不靠功能数量取胜，靠的是触发条件写得准。
- 岗位重叠。装了两个都能"代码审查"的 skill，AI 每次随机挑一个用，输出忽好忽坏，你还以为是模型变笨了。
根因是同一个：我们把 Skill 当"作弊码"收藏，但它本质是一份岗位说明书（JD）。招人时你不会先看简历炫不炫，你会先想"我哪个环节缺人"。装 Skill 也一样。
下面按一条前端需求的完整流程------需求 → 计划 → 写码 → 调试 → 测试 → 审查 → 交付------逐个介绍我的8个岗位。
8人团队分工表
先看表，细节在下面：
| 岗位 | Skill | 来源 | 管哪一段 |
|---|---|---|---|
| 需求面试官 | brainstorming | Superpowers | 动手前先把你问明白 |
| 计划经理 | writing-plans | Superpowers | 把需求拆成可验证的步骤 |
| UI设计师 | frontend-design | anthropics/skills | 压住 AI 的模板脸 |
| 编码规范员 | Vercel React Best Practices | Vercel | 性能规则自动生效 |
| 调试侦探 | systematic-debugging | Superpowers | 先查证据再动手改 |
| 测试工程师 | webapp-testing | anthropics/skills | Playwright 真实跑页面 |
| 评审员 | requesting-code-review | Superpowers | 提交前自查一遍 |
| 文档助理 | docx / xlsx / pptx | anthropics/skills | 交付物直接出文件 |
两个出处说明一下，都是当下最热的 Skill 仓库：Superpowers （obra/superpowers）约28万 Star，anthropics/skills 官方仓库约17万，前几天都还在持续更新；想自己再淘点别的，可以看 VoltAgent 的 awesome-agent-skills（3.3万+ Star），相当于 Skill 的集市。
岗位1：需求面试官 ------ brainstorming
以前一句话需求丢进 Claude Code，它哗啦生成一整个组件，乍一看没问题，跑三轮就露馅。装上 brainstorming 之后，AI 收到需求会先甩回一串问题：给谁用的？边界情况怎么处理？哪些状态可以不写？
像面试前先把你问倒的面试官。需求问清楚，返工成本最低。
岗位2：计划经理 ------ writing-plans
需求问清楚后，writing-plans 把它拆成若干个小步骤，每一步都带独立的验收方式。AI 按计划一步步执行，中途跑偏一眼就能看出来，不用整段推倒重来。
岗位3：UI设计师 ------ frontend-design
让 AI 写页面的人都知道那种"模板脸"：渐变背景 + 大圆角卡片 + 三列功能介绍，像同一家公司批发的。frontend-design 专门压这种同质化长相，产出的页面起码像认真设计过的。
岗位4：编码规范员 ------ Vercel React Best Practices
AI 写 React / Next.js 时这个 skill 自动生效，把性能和组合式写法的规矩执行到位。最大好处是不用你额外叮嘱------写码当下就避开了 useEffect 滥用、props 一路透传这类要等 review 才抓得到的坑。
岗位5：调试侦探 ------ systematic-debugging
AI 调试最大的坏习惯是"猜改"：看一眼报错，猜一个，改一行，再猜。systematic-debugging 给它立了死规矩------先复现、再隔离范围、收集证据，最后才动手。装完之后"修一个 bug 出三个"的情况肉眼可见地变少。
岗位6：测试工程师 ------ webapp-testing
AI 说"已完成，可以跑"的时候，别信。webapp-testing 会让它用 Playwright 真实打开本地页面点一遍，把截图当证据交回来。前端交付前，这是我能接受的最低验收标准。
岗位7：评审员 ------ requesting-code-review
提交前让它自己过一遍，按严重程度列出问题。相当于我先替自己的脑子做一轮预审，真正提交出去的代码干净很多。
岗位8：文档助理 ------ docx / xlsx / pptx
官方仓库三件套。需求收尾时的验收表、对比数据、说明文档，直接让 AI 出成文件，不用手工跟格式搏斗。这个岗位出场率不算高，但每次出场都省的是整块时间。
三条分工原则，直接抄
分工表可以照搬，但真正让 skill 干活的是这三条：
1. 一个岗位一个职责，description 里写触发条件。 description 不是堆功能的地方，是写"什么时候用我"的地方。我自己写 skill 的模板：
markdown
---
name: component-review
description: 提交前自查 React 组件的性能与可访问性问题。当用户说「自查一下」「这个能提交吗」，或准备 git commit 时触发。
---2. 流程岗和资源岗分开。 流程岗（brainstorming、调试侦探）管"怎么思考"，资源岗（frontend-design、docx）管"长什么样、出什么格式"。让一个流程岗顺便干资源岗的活，它就是团队里最大的搅屎棍。
3. 两个技能岗位重叠，裁掉一个。 触发条件打架时，AI 会随机选，效果约等于都没装。发现重叠，留下用得勤的那个，另一个直接删，不用心疼。
最后
8人团队现在撑着我每天的产出：一句话需求进来，面试官问清楚、计划经理拆步骤、AI 全盘实现整个组件、测试工程师守最后一道门，我负责 review 和拍板。
这个团队还有空编制。如果要你给 AI 团队加一个岗位，你会加什么？评论区是招聘现场，让我看看你的 JD。