1. 为什么我给AI“安排岗位”而不是“多装几个插件”大概从去年下半年开始我电脑里的AI工具就开始失控了。ChatGPT、Claude、Codex、各种本地模型界面加上陆续装进Claude Code和Codex里的Skill插件前前后后加起来超过30个。东西越多干活反而越乱。这边写代码用Codex那边写文案切回ChatGPT中间还要手动复制上下文有时候一个问题在两个工具里来回问了三遍答案还不一样。更崩溃的是Skill装多了以后互相打架有的Skill拦截了用户输入有的Skill抢着输出最后出来的结果连我自己都不知道是哪个流程在起作用。后来我停下来想了想问题的根源在于我把AI当成了一个“万能接线员”什么需求都往一个口里丢但并没有给它建立一套清晰的“岗位职责”。真正的转折点是我开始把AI当成一家微型公司来管理。我不再追求“一个AI什么都会”而是反过来给AI公司里安排了8个明确的岗位——有人专门写代码有人专门审代码有人专门做产品分析有人专门处理文档。每个岗位背后挂载对应的Skill岗位之间用清晰的交接逻辑串联起来。30多个Skill不再是杂物而是每个岗位手底下的专用工具。这篇文章就是把整套思路和完整实操过程分享出来从岗位设计、Skill开发规范、工作流编排到中途踩过的坑、调试排查的方法。如果你也在被“AI工具太多但效率不高”困扰这一套“岗位制”思路可以直接拿过去抄作业。先解释两个基础概念方便后面展开。所谓Skill简单理解就是给AI写的一份“操作手册工具箱”。它告诉你使用的AI模型遇到什么场景调用什么方法按什么步骤执行调用本地哪段脚本或外部API。比如我装了一个“项目架构师Skill”当我把一段业务需求丢给AI时这个Skill会自动触发AI会按照里面预设的步骤先画模块边界、再设计接口、最后生成目录结构。没有这个SkillAI也能干活但它会自由发挥质量完全看运气。而Agent智能体则是AI的“身份包装”。一个Agent可以挂载多个Skill有自己的系统提示词、记忆机制、权限边界和工具列表。我的做法是8个Agent对应8个岗位30多个Skill按岗位归堆分发。这么一来每个Agent拿到的上下文更干净更专注于自己岗位的活输出质量明显提升。2. 8个岗位的整体设计与分工逻辑2.1 岗位清单与核心职责说明下面这张表是我目前实际在跑的8个岗位配置。每个岗位我先讲清楚它“管什么事”再说明它需要核心关注什么避免它的职责越界。岗位名称核心职责挂载Skill数量主要适用场景需求分析师把模糊的需求转成明确的任务描述和验收标准3产品需求梳理、项目启动、任务拆解架构师设计系统模块、接口、数据模型4新项目搭建、重构方案设计主程序员核心功能代码实现、算法编写6功能开发、脚本编写、算法实现代码审查员代码规范检查、潜在Bug识别、性能优化建议4代码提交前审查、技术债务清理测试工程师生成测试用例、模拟异常输入、给出回归清单4功能测试、边界测试、上站前检查文档工程师生成README、接口文档、操作手册3项目文档维护、知识沉淀数据分析师数据清洗、指标计算、可视化方案3数据报表、运营分析运维监控员检查环境配置、日志分析、异常排查4部署检查、线上问题定位合计下来正好32个Skill跟标题里说的“30多个”对上了。岗位数量不建议盲目增加我试过加到12个效果反而变差因为岗位之间接口太多交接容易出错。8个是比较平衡的数字覆盖了从需求到上线全链路又不会让管理层级过深。2.2 为什么是“8个岗位”岗位边界如何划定最初设计岗位数量时我参考的不是团队编制而是“一个最小软件交付闭环需要哪些角色”。需求进来必须先有人把它聊清楚这就是需求分析师。方案定了要有人把技术路线规划出来这就是架构师。代码要落地主程序员上场。写完的代码不能直接上要有审查员把关。测完了要留证据、留文档这就是测试工程师和文档工程师的活。数据类任务单独拎出来给数据分析师。最后上线出问题运维监控员负责兜底。岗位边界划定的核心原则是“一个岗位只对一种产出负责”。比如需求分析师只输出需求文档和验收标准不负责写代码。主程序员只写代码不做代码审查。这样每次AI的产出都可以用统一的验收标准去判断出问题也能快速定位是哪一环没做好。这里特别提一下“8个岗位”不等于“8个独立的AI窗口”。我实践下来的最优解是在同一个终端环境里通过配置管理8个不同的AI配置入口之间通过文件系统和特定的交接文档通信。如果每个岗位都单独开一个ChatGPT窗口上下文完全隔离任务交接会变得非常痛苦。3. 4类核心Skill的开发与选择标准3.1 SKILL.md规范与描述文件的重要性30多个Skill里有一部分是我从社区下载的现成方案但更多是按照项目需求自己改造或开发的。如果你到GitHub上搜“skill”相关项目常见的目录结构是这样的my-skill/ ├── SKILL.md ├── scripts/ │ ├── preprocess.py │ └── postprocess.py └── assets/ └── templates/SKILL.md是这个Skill的说明书也是AI读取入口。我第一次开发Skill时没把这个当回事写的描述含糊不清结果AI经常在错误场景触发这个Skill或者触发了但不知道具体该调用哪个脚本。后来我总结了SKILL.md必须包含的三个核心要素第一个是触发条件。写得越具体越好。比如“当用户输入包含重构且提到了模块拆分时触发”而不是“当用户需要重构时触发”。触发条件模糊是Skill被乱调用的头号原因。第二个是执行步骤。AI会严格按照你写的步骤顺序执行。我踩过的坑是步骤写得不够细AI跳步结果输出结论但没给依据。现在我的SKILL.md里执行步骤都按“先分析再设计最后输出”的三段式写防止跳跃。第三个是输出格式。同一岗位的Skill输出尽量保持统一结构方便下一个岗位接手。比如代码审查员的Skill输出固定为“问题列表严重级别修改建议”这样主程序员拿到后不需要二次解析。下面是一个简化版的SKILL.md开头示例可以拿来参考--- name: api_design_skill description: 当用户需要设计RESTful API接口时使用。触发词接口设计、API、端点规划。重点输出资源路径、请求参数、响应结构。 ---3.2 三个关键参数触发条件、执行边界、输出格式在实际调Skill参数时有三个地方最影响体验我单独展开讲讲。触发条件这块很多人写得太泛。比如“当用户需要帮助时”这等于没写。我自己的经验是触发条件里至少要包含两个维度场景词和任务动词。场景词解决“在什么背景下”任务动词解决“要做什么动作”。举个例子“当用户提交一段Python代码且要求检查代码质量时”就比“代码有问题时”精确得多。执行边界解决的是“Skill能干什么、不能干什么”。我试过不给Skill设置边界结果AI在写代码审查意见的时候顺便把代码重写了一遍输出格式完全失控。现在每个SKILL.md里都有一句明确的“本Skill只负责X不负责Y”。这句话看着简单但能省掉大量后期纠错时间。输出格式是不同Skill之间能否顺畅协作的基石。比如需求分析师的输出是一个结构化的需求文档架构师读了这份文档才能开始做模块设计。如果输出格式乱下游岗位的工作就会被污染。我的做法是给每个岗位定义一套统一输出模板模板固定写在Skill的output section里让AI每次输出都按照这个模板走。3.3 从零开发一个Skill的完整流程示例为了把流程讲清楚我以自己开发的“代码审查Skill”为例完整走一遍从零开发的过程。这个Skill后来被我用了将近三个月总计审查了上千个文件稳定性很高。第一步明确需求。我希望AI能在我提交一段代码后按“可读性、性能、安全隐患、边界条件”四个维度给出审查意见。注意审查和修改是两个动作我的边界设定是“只提意见不改代码不生成修改后的代码”。第二步准备脚本。检查本地环境确认需要的Python环境可用并写一个简单的辅助脚本scan_patterns.py用于扫描常见的不良代码模式。这个脚本不是必须的但它能让AI的“检查”动作落到实处而不是凭空判断。第三步编写SKILL.md。把触发条件、执行步骤、边界和输出格式写清楚。核心执行步骤我写的是逐行阅读代码标注可疑位置。调用scan_patterns.py扫描常见模式。对每个问题按严重程度分级。输出统一格式的审查报告。第四步测试。用有问题的代码测试观察AI是否触发Skill、是否按步骤执行、输出是否符合格式。这个环节需要反复迭代。我最初的版本是让AI直接输出“问题建议”但后来发现它经常跳过严重级别的标注导致主程序员分不清优先级。后来我在SKILL.md里加了强制要求“所有问题必须标注严重级别级别选项为高危、中危、低危。”这才算稳定下来。写到这里顺便插一句很多社区Skill的质量参差不齐尤其是描述文件写得烂的往往加载了反而帮倒忙。我的筛选标准就三条一是触发条件是否明确到不产生歧义二是执行步骤是否可以被AI按序严格执行三是输出格式是否统一。三条都满足才值得挂到岗位上。4. 实操过程8个岗位的完整落地步骤4.1 准备阶段Skill文件与执行环境的整理在动手把所有Skill和岗位串起来之前先做环境整理。我的目录结构是这个样子的~/ai-workspace/ ├── agents/ │ ├── analyst/ # 需求分析师 │ │ ├── agent.md │ │ └── skills/ │ │ ├── prd_writer/ │ │ ├── user_story_splitter/ │ │ └── acceptance_criteria_checker/ │ ├── architect/ # 架构师 │ ├── developer/ # 主程序员 │ ├── code_reviewer/ # 代码审查员 │ ├── tester/ # 测试工程师 │ ├── documenter/ # 文档工程师 │ ├── data_analyst/ # 数据分析师 │ └── devops/ # 运维监控员 └── shared/ ├── templates/ # 共享输出模板 └── workflows/ # 跨岗位交接流程定义每个岗位一个文件夹里面放agent.md身份和职责说明和skills子目录。这么做的好处有两个一是路径本身就在告诉AI“你是哪个岗位”减少身份混淆二是Skill按目录隔离互相之间不会因为加载顺序问题产生干扰。如果你用的是Claude Code或Codex这类支持自定义Skill目录的工具直接在配置里指定这个根路径即可。如果你用的是通用聊天界面也可以把agent.md的内容放到系统提示词位置把Skill内容放在每次会话开头的固定段落里。两种方式的底层逻辑是一样的——给AI一个清晰的岗位身份再给它这个岗位专属的工具集。4.2 岗位交接机制输出文件怎么传递给下一个岗位岗位之间的交接是整个体系里最容易翻车的地方。如果交接信息丢了一半下游岗位等于在垃圾数据上做决策。我的解决方案是引入了一个“交接文档”的机制。每一个岗位完成任务后必须往shared/workspace/目录下写一个结构化的交接文档命名规范是next_[目标岗位]_[任务编号].md。举个例子需求分析师完成需求梳理后会生成一份next_architect_001.md里面包含一以下信息任务背景摘要、核心需求列表、验收标准、已知约束条件、需要的交付物说明。架构师上岗后第一件事是读取这份交接文档再结合自己的架构设计Skill往下推进。光是这个改动就让整个流程的准确率提升了一个台阶。之前没有交接文档时每次换岗都要重新解释一遍背景上下文窗口又有限聊着聊着前面的细节就丢了。现在所有背景都用文件固化下来既方便AI读取也方便我人工抽查。4.3 一个真实任务的多岗协作全程记录下面用一次真实的项目“给公司内部工具加一个导出报表功能”来完整展示8个岗位是怎么协作的。第一阶段需求分析师上岗。它读取用户原始的零散描述——“要把报表导出来方便运营看”识别出需求痛点输出一份简明需求文档明确“导出格式支持Excel和CSV、数据范围支持时间筛选、权限控制按角色区分”。这些细节是我原始描述里没有的但Skill里预设的问答模板会引导AI主动补全。第二个阶段架构师接手。它读取交接文档后设计出模块方案新增一个export模块复用已有的数据查询服务增加两个API端点前端加一个导出按钮。架构文档输出后我审核了一遍确认没有过度设计才放行进入开发。第三阶段主程序员上岗。程序员Agent拿着架构文档按Skill里设定的开发规范逐步实现代码。这里需要注意主程序员Skill里要挂上项目自己的代码风格指南否则它写出来的代码跟现有工程风格不一致后续审查阶段会被打回。第四阶段代码审查员接手。审查员按照设定的四个维度检查代码发现两个问题一个是时间筛选有边界遗漏另一个是导出大文件时内存占用偏高。问题按级别标注为“中危”和“高危”返回给主程序员修改。修改完之后测试工程师上岗。测试Agent根据需求文档和代码变更生成测试用例包括正常路径、空数据路径、超大文件路径和越权访问路径。它把每条用例的执行结果记录下来生成测试报告。最后是文档工程师和运维监控员。文档工程师补齐接口文档和操作说明运维监控员检查部署配置和依赖环境确认没有破坏性变更。整个流程下来一个功能从需求到交付大概用了不到一个小时全流程我只需要在关键节点确认。以前自己动手写至少要大半天。5. 排错经验与实战避坑指南5.1 Skill之间互相干扰的排查与解决岗位体系跑起来后第二个面临的重大问题就是Skill互相干扰。症状很典型——AI明明在做代码审查输出的却是需求分析风格的内容或者一个简单的文件操作任务AI突然调用了测试用例生成的Skill。排查这个问题我花了很长时间才发现根因在触发条件重叠。多个Skill的触发条件都包含“代码”这个关键词导致AI加载了错误的Skill。解决方法是给每个Skill的触发条件加限定前缀比如“当用户提交待审查代码时”和“当用户要求生成测试用例时”就完全区分开了。另一个常见干扰来源是Skill描述里引用了别的Skill的名称。AI读到某个Skill描述里提到了“调用测试工程师能力”就会主动加载测试岗位的上下文导致角色混淆。现在我在所有Skill的描述里禁止出现“调用其他Skill”这类表述只允许描述自己的职责范围。5.2 上下文超限与输出截断的应对策略30多个Skill和8个岗位最大的上下文压力来自于加载的Skill数量。每个Skill的描述文件本身就要占据上下文窗口窗口一满AI就开始“失忆”表现为回答冗长但核心信息丢失或者干脆截断。我在实践中摸索出的应对策略是“按需加载、用后即撤”。具体来说岗位Agent上岗时只加载与当前任务直接相关的3到4个Skill其他Skill不放在系统提示词里。任务完成后交接文档写入工作区随后当前岗位的上下文可以释放。另外SKILL.md文件本身要控制篇幅。单个Skill描述控制在300字以内Script脚本不超过200行。文件越长AI越容易把注意力分散在不关键的信息上。如果某个流程确实复杂拆成两个Skill分步执行比硬塞在一个Skill里效果好得多。5.3 角色错乱问题AI为什么会突然“串岗”串岗是经验里最让人头大的问题明明在让程序员Agent写代码回答里突然冒出了测试报告的语气。原因其实出在prompt历史里的残留上下文。当前岗位的对话历史中包含了上一个岗位的输出如果那个输出风格特别鲜明AI容易被带跑偏。我的解决方案是每切换一个岗位就清空一次对话历史只保留交接文档作为输入然后再以岗位身份开启新会话。这个方法牺牲了一点连续性但换来的是角色稳定性和输出质量的大幅提升。还有一个容易忽略的细节岗位身份说明agent.md要写得足够具体。不只是“你是一名程序员”而是“你是负责XX项目后端模块的Python程序员你只负责代码实现不负责测试设计和文档编写若接到这类任务请拒绝并提示切换岗位”。越具体串岗概率越低。5.4 30多个Skill的管理与版本迭代框架Skill装多了以后管理就变成了一个新问题。我给自己定了一套轻量化管理规范不复杂但很有效。每个Skill文件头部都要写创建日期和版本号例如version: 1.2.0。改动Skill时先复制出一个副本修改后在测试环境跑一遍确认效果变好才替换正式文件。这一点类似代码发布流程能防止“改坏了想回退却找不到原版”的尴尬。定期做Skill健康检查频率大概是每两周一次。检查项目包括最近一周有没有触发过、触发的输出质量是否稳定、描述文件里有没有过时的术语或路径。那些超过一个月没触发过的Skill我会先下线观察而不是直接删除避免之后想用又要重新找。关于Skill的获取渠道我个人不太建议只依赖社区下载的现成方案。别人的Skill往往是围绕他自己的业务场景优化的直接搬大概率不匹配。更好的方式是只参考别人的结构和设计思路自己动手把内容改造成匹配自己工作流的版本。这个“本地化”过程才是Skill真正发挥价值的开始。6. 效果评估与长期维护建议整套体系上线运行后的变化最直观的体现是任务流转效率。原来一个需求从提出到代码落地我需要不断切换上下文、手动搬运信息、反复校对输出。现在每个岗位在上岗前自动拿到交接文档干完活按时把结果写回工作区我只需要在关键节点做审核。时间成本至少节省了一半更重要的是输出质量从“偶尔惊喜”变成了“稳定合格”。关于最终效果和落地经验这里有几个实在的心得可以分享第一不要追求Skill数量。30多个Skill听着很厉害但真正高频使用的可能只有十几个。数量多不如分类清晰每个岗位把自己核心的3到4个Skill用透效果远比堆砌几十个乱七八糟的Skill要好得多。第二岗位设计要从小做起。我最初设计岗位时是拍脑袋想到什么角色就加什么角色结果管理成本剧增。后来调整为先从“需求、开发、测试”三个最刚需的岗位跑起来跑顺了再逐步扩展架构师、运维等角色。渐进式落地比一次性铺开更容易掌控。第三保持Skill的“本地化”。再好的现成Skill都要根据自己的工作流、团队习惯、项目特点做二次修改。我的所有Skill几乎都改过三轮以上每一轮都是根据实际跑任务的效果迭代出来的。Skill不是装了就完事它需要像代码一样持续维护。如果你正在考虑给AI装Skill、安排岗位我个人体会最深的建议是先把岗位职责定义清楚再谈Skill数量。岗位是骨架Skill是血肉骨架歪了肌肉再发达也没用。先选一个你最痛、最重复、最耗时的任务场景用“岗位Skill”的方式跑通一整个闭环你会立刻感受到这套方法与随手问问AI的区别。