
1. 这个“岗位制”的想法是怎么来的先说背景。我平时用AI编程、写文档、做分析、整理资料属于重度用户。用了半年多以后我发现一个问题对话式的AI虽然强大但我每天重复做的事情太多了。让AI画架构图、让它跑一遍代码检查、让它帮我写周报模板、让它总结会议纪要每次都要重新交代一遍背景、格式和要求。效率确实有但没到那种“神器”的地步更像是一个随叫随到的实习生你得不停给指令。后来我开始接触Skill这个概念。说白了Skill就是给AI写好的“岗位说明书操作手册”你把这套东西喂给AI它就记住了这个岗位该干什么、按什么流程干、输出长什么样。再配合一些Agent工具或者支持Skill调用的AI客户端它可以主动识别该用哪个Skill、按什么顺序执行。我陆续收集、测试、改造了30多个Skill最后把他们编成了8个岗位相当于在我的工作流里组建了一个小型的“AI部门”。这篇文章就是我搭这套体系的全过程复盘包括我的分类逻辑、每个岗位配了哪些Skill、具体的配置方法、踩过的坑、以及一些你在官方文档里不容易翻到的细节。如果你也想从“让AI帮你干活”升级到“给AI分工派活”这篇应该能给你一个比较完整的参考。2. 为什么是“岗位”而不是“更多工具”2.1 按角色分比按功能分更贴近真实协作我刚开始收集Skill的时候是按功能整理的画图的一个文件夹写代码的一个文件夹文档的一个文件夹。这种整理方式本身没有错但用起来就会发现一个问题——你不知道什么时候该用哪一个。比如写周报这个场景你可能要写代码总结、要生成图表、还要写几条工作亮点跨了三个文件夹你得手动把多个Skill串起来。而AI本身又不一定知道下一步该调哪个Skill。后来我换了一个思路不按“功能”分按“人”分。写代码的归“工程助理”画图的归“图表专员”文档润色的归“文档编辑”。每个岗位对应一整套流程而不是一个孤立的功能块。这样一来我只需要告诉AI“走一遍工程助理的流程”它就会自己按顺序调用代码审查、依赖检查、代码统计这些Skill最终产出一份完整报告。体验完全是两个层次。2.2 岗位之间能形成“上下游”另外一个很现实的好处是岗位之间可以交接。比如“数据分析师”分析完一份数据输出结论然后“图表专员”根据这份结论自动配图最后“文档编辑”把图和结论整理成带排版的报告。这在传统的“一个工具干一件事”的模式里几乎不可能顺畅跑通因为工具之间没有上下文传递。我搭的8个岗位内部就设计了两套交接链路。一套是“数据分析链路”数据采集 → 数据清洗 → 统计分析 → 可视化 → 结论输出。另一套是“内容生产链路”资料检索 → 大纲策划 → 初稿生成 → 图表创作 → 排版编辑。也就是说我日常工作中80%的重复性、流程性任务都可以从任意一个入口启动AI自动往后跑完整个流水线。2.3 岗位制降低了对“提示词能力”的要求这一点是我的真实体会。以前我为了让AI输出符合预期得写很长很长的提示词不断调整措辞很累。Skill岗位的架构把这种“内功”封装到了技能文件里。比如我写了一百多条关于“如何写一份有洞察力的周报”的规则全部放在“文档编辑”岗位的Skill里。以后我只需要说“用文档编辑岗位生成这周周报”AI就会自己加载这些规则而不是让我每次都重复一遍。我自己的理解是提示词是你直接给AI下指令Skill是给AI做岗前培训。岗位制相当于把岗前培训做成了体系让AI的上手成本大幅降低。3. 8个岗位的总体规划3.1 岗位名单和职责说明先放我的岗位全景图后面逐个拆解。岗位编号岗位名称核心职责主要Skill类型01工程助理代码编写、代码审查、技术方案拆解代码生成、代码审查、依赖分析02数据分析师数据采集、清洗、统计分析、结论输出数据爬取、数据清洗、统计建模03图表专员各类图表制作、流程图绘制、架构图设计图表生成、Mermaid出图、设计规范04文档编辑文案润色、结构化排版、周报月报生成文案优化、排版模板、周报生成05资料研究员资料搜索、知识整理、信息摘要网页检索、PDF摘要、知识库构建06创意策划选题策划、大纲设计、头脑风暴选题生成、结构设计、创意发散07测试质检官自动化测试、质量审查、内容校对测试用例生成、代码走查、文本校对08项目管家任务拆解、进度跟踪、日报汇总任务管理、会议纪要、进度推送3.2 为什么设置8个而不是5个或10个我是从“分工粒度”来考虑这个问题的。5个以内岗位太少很多任务会混杂在一起比如数据分析师和图表专员如果合并分析报告的产出速度就会很慢因为AI会花大量时间在数据上配图质量就会被牺牲。超过10个管理成本就上来了——岗位之间职责可能会有重叠触发匹配也会经常出错比如“文档编辑”和“创意策划”在一些场景下边界会模糊AI分不清该用哪一个。8个岗位对我来说是一个“够用且好管理”的平衡点。每个岗位上挂3到5个Skill总维护量可控日常触发准确率也能保持在较高水平。每个岗位的职责边界也比较清晰能分得清的就独立成岗分不清的就合并。3.3 各岗位的Skill配置参考这里我把我每个岗位对应的主要Skill列一下每个Skill都标注了类型方便你对照。工程助理代码生成、代码审查、依赖分析、技术方案、Git提交信息生成数据分析师网页数据采集、表格数据清洗、统计分析、异常检测、结论生成图表专员通用图表生成、流程图生成、架构图生成、配色规范建议文档编辑长文润色、结构性改写、周报月度汇总、PPT大纲提炼资料研究员检索摘要、PDF信息抽取、多源对比、知识卡片生成创意策划选题发散、文章大纲、用户画像模拟、角度挖掘测试质检官测试用例生成、代码走查、文案一致性校验、数据准确性校验项目管家任务清单拆解、优先级排序、会议纪要、进度追踪汇总4. Skill开发与选型从随便用到分类管理4.1 Skill到底是什么怎么理解它用一句容易懂的话来说Skill是“给AI看的说明书”。它通常是一个文件夹里面包含一个主文件比如SKILL.md以及若干辅助文件比如示例、模板、脚本。主文件里定义了技能的触发条件、执行步骤、输入输出格式、注意事项等等。AI读了这个文件以后在这个技能的框架范围内工作输出质量会稳定很多。我见过有人把Skill理解成“一种超级提示词”其实不完全对。提示词是一次性的“口头交代”Skill是结构化的“系统指令知识库”它可以包含若干步骤、校验规则甚至几条分支路径。更重要的是一个Skill可以在多个Agent平台上复用跨平台迁移很方便。4.2 Skill去哪找怎么判断靠谱找Skill的渠道主要分几类官方市场/插件市场比如Claude官方的一些Skill库、Codex的Skill说明文档、各类Agent平台的技能商店这里的Skill质量比较稳定可以直接用。GitHub开源仓库搜索关键词如awesome-skills、claude-skills、agent-skills能找到大量社区维护的集合。个人博客和技术文章不少开发者在博客里分享自己写的Skill质量有时候比仓库里的还要好因为作者会讲清楚设计和坑。判断一个Skill是否靠谱我一般看三点主文件结构是否清晰。有没有明确的输入项、输出项、步骤说明。如果只是几句话糊弄过去不建议用。是否有示例和边界说明。好的Skill会提供输入示例和输出示例还会写明“不要做什么”这对AI很重要。维护频率。最近一年有没有更新改动记录怎么样。AI工具的API变化很快一个两年没更新的Skill大概率跑不顺。4.3 手写Skill的关键步骤官方下载的Skill往往不完全贴合自己的场景所以我大部分Skill都做了二次改造少数是从零手写的。这里分享一下我写Skill的核心流程。第一写好“身份与职责”段。明确告诉AI“你是一个数据分析助理负责对用户提供的表格进行清洗和统计分析”。这一段相当于岗位JD越明确越好。第二定义“输入项”和“输出项”。输入项告诉AI用户需要提供什么参数比如“输入原始数据表格csv或xlsx”输出项则规定交付物长什么样比如“输出一份markdown格式的数据摘要包含总行数、缺失值、均值、中位数、异常值标记”。这一步能让AI的输出稳定性大幅提升。第三编写“工作流程”。最好是分步骤第几步做什么第几步输出什么。我的习惯是每个步骤控制在100字以内避免AI在长文本里迷失重点。第四写好“边界条款”。这是很多人会忽略的部分。例如“不要试图预测缺失值只需标记缺失位置”、“如果数据超过1000行仅抽样展示前100行的统计结果”。没有边界AI就会自己“发挥想象力”结果往往不可用。第五添加“示例片段”。哪怕只写一段AI也能更准确地理解。如果你希望AI输出某种特定格式的表格务必给一段具体的Markdown表格示例。4.4 Skill管理时容易踩的坑我先说几个我自己踩过的坑大家可以直接避开。坑一文件夹命名混乱。刚开始我直接拿Skill自带的文件夹名往系统里放很多名字长且不规律导致AI调度时经常匹配不上。后来我改成统一命名规则岗位编号_技能名称_版本号比如01_代码审查_v2。这下匹配准确率高了很多。坑二版本更新后没有回归测试。你别觉得Skill是静态文件当你更新了AI客户端的版本或者模型版本以后原本很乖的Skill可能会跑偏。因为底层模型的行为变了对某些措辞的理解也会变。所以我每次升级AI工具后都会跑一遍“技能自检清单”用固定的测试输入确认各岗位的输出质量。坑三过度依赖Skill把该自己判断的事情也交给Skill。Skill适合流程化、规则明确的任务不适合需要复杂价值判断的任务。比如你可以让AI按模板生成周报但如果你连“这周最重要的三个亮点是什么”都想让AI替你判断结果往往会比较离谱。5. 实操过程从安装到部署一个AI部门5.1 我的运行环境设置我先说明一下我采用的是一套比较通用的“Skill调度”架构不绑定某个特定商业产品你自己有支持自定义Skill的AI客户端比如Claude Code、Codex CLI、OpenClaw或者一些开源Agent框架就可以照着搭。具体组件如下AI客户端支持Skill加载的终端型或桌面型客户端我主力用的是本地终端方案。Skill存储目录建立一个统一的目录比如~/ai-skills/下面按岗位分子目录。调度配置在客户端的配置文件中声明各个Skill的路径和触发关键词。运行流程用户提出需求 → 客户端匹配对应Skill → 加载Skill中的说明和规则 → 执行输出。5.2 安装Skill的通用步骤虽然不同工具的安装方式有一些差异但整体流程是通用的我按一个典型流程写一下。下载或者写好的Skill文件夹放进统一的技能目录。在客户端配置中声明Skill路径。例如在你的设置文件里增加一条指向该目录的配置项。启用自己的调度机制。让AI能根据用户输入的关键词自动加载对应Skill。用一段测试输入验证Skill是否生效。例如给“文档编辑”岗位输入一段口语化的文字要求它润色成结构清晰的书面语。根据输出调整Skill内容。如果输出不符合预期优先回去检查Skill的输入输出定义和工作流程描述而不要靠临时加提示词硬掰。5.3 关键配置触发关键词与优先级给岗位设定触发关键词是一项很微妙的工作。关键词太宽泛会出现误触发太狭窄AI又识别不出来。我总结了一条比较实用的规则每个岗位给“强触发词”和“弱触发词”两个级别的关键词。以“图表专员”为例强触发词画图、图表、生成流程图、架构图弱触发词可视化、展示、配图、Mermaid强触发词命中时直接调用对应Skill弱触发词命中时AI可以先询问用户确认再决定是否调用。这种设计能显著减少误调用的情况。优先级设置也不可忽略。当一句话命中了多个岗位的关键词时AI需要知道哪个优先。我的排序规则是测试质检官 工程助理 数据分析师 项目管家 文档编辑 图表专员 资料研究员 创意策划。为什么这样排因为如果任务是“审查代码并生成报告”你肯定希望先审代码再写报告而不是先写报告再回头审。测试质检官和工程助理优先能保证下游任务基于的是更可靠的内容。5.4 岗位协作的链路编排有读者之前问过我“你有8个岗位AI怎么知道要按什么顺序跑”答案是在Skill里写明岗位间的上下游关系。以“写一份季度分析报告”为例我的一句话需求会被拆成这样的执行路径“项目管家”接收指令拆解任务清单输出子任务列表。“资料研究员”根据主题搜索并整理涉及的数据和资料。“数据分析师”拿到资料里的表格做清洗和统计输出结论。“图表专员”根据分析结论补充可视化图表。“文档编辑”把图表和分析结论整合成结构清晰的报告。“测试质检官”最终校验数据一致性、格式规范和逻辑完整性。这个协作链路我是通过在每个Skill的“上下游衔接”段落里维护的。比如数据分析师的Skill里会写“如果你的下游是图表专员请在输出中额外提供一份图表说明如果你的上游是资料研究员请优先处理它标记过的数据源。”虽然一句话不能让AI做到完美编排但多段提示词合力效果会稳定很多。5.5 我实际怎么发指令岗位制配置好以后我的指令简短了很多。这里给你几个我实际使用的高频指令示例都是真实发过的用工程助理帮我审查一下这个仓库的代码输出一个问题清单—— 触发工程助理加载代码审查Skill。让数据分析师跑一下这个CSV给我一份统计摘要和异常标记—— 触发数据分析师加载清洗和统计Skill。用图表专员把这段文字描述画成流程图Mermaid格式—— 触发图表专员加载流程图Skill。文档编辑帮我润色一下这篇周报带上数据口径说明—— 触发文档编辑加载润色与排版Skill。项目管家把这周的待办整理成带优先级的清单—— 触发项目管家加载任务拆解Skill。用习惯以后你会发现和AI协作的方式从“对话驱动”变成了“指令驱动”不需要反复解释背景直接说“让XXX做XX事”剩下的事情它会按岗位规范自己跑。6. 核心岗位拆解与经验补充6.1 工程助理代码审查与生成这个岗位是我日常使用频率最高的。它的核心Skill是代码生成和代码审查其中包含的具体规则包括函数的职责边界、命名风格、错误处理方式、注释语言、以及“不要在代码里写TODO”这类约定。有一个细节值得分享我一开始在代码审查的Skill里只写了“请检查代码中的错误和潜在问题”结果输出全是泛泛而谈。后来我把审查维度拆成五条逻辑正确性、边界条件、性能隐患、安全风险、可读性。每个维度单独给一段描述和示例输出质量立刻上了一个档次。另一个经验是工程助理的Skill应该携带“技术栈说明”。比如我经常写Python和TypeScript就在Skill里备注了“优先基于Python 3.11和TypeScript 5.x审查注意类型注解是否完整”。这样AI在审查时会更贴合实际环境。6.2 数据分析师像带实习生一样带它数据分析师岗位的Skill必须写得像“给实习生的操作手册”因为数据处理本身有太多细节AI不明确就会被“坏数据”带偏。我的数据分析师Skill里包含了一部分固定规则读取数据前先检查列名、单位、缺失值分布。必须报告数据量级行数×列数和内存占用趋势便于判断是否需要抽样。异常值的处理策略分为“标记”“剔除”“替换”三档默认只标记不剔除避免信息丢失。所有结论必须附上计算依据不能只给结果。尤其最后一条对AI来说非常重要。如果你不要求它给出依据它经常会在统计描述里“自我发挥”。加了这条规则以后它虽然多了一点推理步骤但至少每个数字都能对上。6.3 图表专员把思路转成可展示的图图表专员的Skill和数据分析师配合最紧密。它的主要任务是接收到数据结论或者流程描述以后生成图表代码比如Mermaid、PlantUML、ECharts并附带一套视觉建议。给图表专员写Skill时要注意定义“图的种类选择逻辑”。AI如果自由发挥常常会把流程图画成思维导图把架构图画成甘特图。我在Skill里规定了几个映射规则时间顺序用流程图层级关系用架构图或树状图流程分支用状态图数据分布用柱状图/箱线图。规则明确以后它出的图基本不会跑偏。另外Mermaid这种代码型图表特别适合AI生成因为它不需要渲染环境直接把文本贴到支持Mermaid的工具里就能转成图片。我也在Skill里给了一组官方的语法示例避免AI生成不兼容的语法。6.4 文档编辑文案润色与模板化输出文档编辑这个岗位承担了“把AI生成的内容变成人话”的职责。很多人觉得AI写的东西“有AI味”其实根源不是模型不行而是缺少一套系统的润色规则。我的文档编辑Skill里包含了一套“去AI味”规则避免以“随着……的发展”这类句式开头。每段必须有具体的例子、数据或操作步骤不能只说抽象观点。优先使用主动语态少用被动语态。删除“总之”“综上所述”等标记性过渡语。另外文档编辑Skill需要内置几种常用模板周报模板、月报模板、技术方案模板、会议纪要模板。每种模板都定义好了章节结构和重点。比如周报模板里我要求必须包含“本周完成”“遇到的问题”“风险提示”“下周计划”四块并且每条要带量化数据。6.5 项目管家轻量级任务协作中枢项目管家是给“团队协作”设计的个人用起来同样顺手。它的核心价值在于任务拆解和进度汇总。我给项目管家Skill里配置了任务拆解模板输入一个目标输出一个包含负责人即具体调用哪个岗位、截止时间、前置依赖、交付物清单的表格。比如你输入“下周上线一个登录页”它会拆成“工程助理→前端页面开发数据分析师→埋点事件定义测试质检官→验收用例编写”这样几条任务。任务拆解以后进度追踪就方便多了。我每周让项目管家汇总一次完成情况它会把各岗位的输出记录整理成一份进度日报。说实话对于个人开发者来说这个模块的价值被很多人低估了。它让“同时推进多个任务”变得不那么混乱。7. 常见问题与排查技巧实录7.1 Skill没有被触发AI直接当普通聊天处理这是最常遇到的问题。排查思路按顺序走先确认配置里Skill的路径有没有写对。我之前就因为路径少了一个斜杠导致所有Skill都没加载。检查触发关键词是否和实际输入接近。如果你说“帮我画一个用户登录的流程图”而触发词只写了“画图”“图表”那AI确实可能匹配不到。确认调度机制是否启用了“模糊匹配”。有些客户端默认只做精确匹配需要手动开启语义匹配。这里的经验是触发词宁可多写几个同义词也不要贪图省事只写两个词。7.2 Skill加载了但AI输出风格还是“放飞自我”这种问题通常是Skill主文件中的指令太泛。建议你回去检查一下“工作流程”和“边界条款”两个段落。如果这两个部分合计不到400字我基本可以断定它约束不住AI。举个例子我以前写“文档润色”的时候只写了“修正语法错误、提升可读性”结果AI润色完还是一篇四平八稳的官样文章。后来我把“去AI味”规则和每段的段落结构约束写进去输出风格才完全变样。所以请优先加强边界条款不要靠反复修改提示词去硬控。7.3 多个岗位同时触发AI乱套了当你输入一句话同时包含“生成图表”和“写报告”时AI可能把两个岗位的Skill同时加载输出就会很混乱。解决办法就是我前面说的优先级设置。把职责边界和优先级在配置里明确写清楚比如“当图表专员和文档编辑同时匹配时先执行图表专员生成图表后交由文档编辑整合”AI就会按这个顺序跑。7.4 Skill之间传递的数据格式对不上这种情况比较隐蔽但在数据链路里非常常见。比如数据分析师输出的是Markdown表格而图表专员要求输入的格式是CSVAI转换的时候就可能出错。解决办法是在Skill里统一“中间数据格式”。我直接在数据分析师的Skill里写了“输出给图表专员时额外输出一份CSV格式的样本数据”。这样下游拿到数据以后不用猜格式直接可读。每个岗位的输出交接区都尽量保持同一套结构化格式比如都用MarkdownCSV组合就能减少很多格式冲突。7.5 Skill运行不稳定同样的输入有时好有时差和模型参数设置、上下文窗口长度、以及Skill加载的先后顺序都有关系。排查思路把相关Skill的描述控制在必要长度不要一次加载太多不相关的内容。给关键步骤加“必须”或“禁止”这类强度词降低AI自由发挥概率。如果客户端支持把模型temperature调低一些稳定性会有明显提升。7.6 快速排查清单最后整理一张问题速查表遇到问题按照这个表检查一遍大部分坑都能解决。问题优先检查项常见修复方式Skill不触发路径配置、触发词修正路径扩展同义词触发词输出风格失控主文件指令强度补充工作流程和边界条款岗位匹配冲突优先级配置设置岗位优先级和执行顺序数据格式不兼容中间输出格式统一为CSVMarkdown组合运行不稳定模型参数、加载顺序调低temperature精简加载内容Skill无法跨平台复用引用了特定平台的API改为通用步骤和描述8. 个人总结与进阶建议8.1 给新手的三个“少做”建议第一少下载、多改造。Skill不在多在于贴合你的使用场景。我见过有人一口气下100个Skill结果有一大半从来不触发。更好的做法是先下载三五个跟你最高频场景强相关的跑顺了再慢慢扩充。第二少问“哪个Skill最好”多问“我要解决什么问题”。Skill再强如果不在你的工作流里发挥作用就是摆设。建议每次新增Skill前先记录一下自己重复三次以上的AI使用场景然后针对这个场景去找或写Skill。第三少追求一步到位多迭代版本。我第一次写的Skill丑得没法看输出经常跑偏。但不要怕用两周时间每天小改一次你会发现它越来越贴合自己的需求。8.2 进阶方向让岗位之间形成真正的“团队”如果8个岗位跑通了下一步就是让它们之间的协作更自动化。目前大多数Skill之间的协作还是“AI根据上下文自动顺接”主动权还是在你手里。真正进阶的做法是用支持多Agent编排的框架把岗位定义成独立Agent让每个Agent有独立的记忆、工具和日志。这类架构的好处是每个岗位独立运行互不干扰出现问题时可以单独调试数据流转完全由管道控制。缺点也很明显配置复杂度高不适合轻量级用户。我个人的建议是先把Skill岗位制跑上半年把流程理顺、把常见问题摸透再考虑上多Agent编排。8.3 我自己的使用体会从“纯对话式”切换到“Skill岗位制”以后最大的变化不是我的工作量少了多少而是我的思考方式变了。我不再纠结“这句话该怎么问AI”而是想“这个任务该分给哪个岗位、按什么流程跑”。后者是工程化思维前者是提示词思维。工程化思维的收益是长期的你沉淀下来的Skill、岗位配置、协作链路都是可以复用的资产。下一次遇到类似的活儿你不用从零开始直接调用对应岗位就行。另外我想说一点Skill岗位制不是万能的。对于探索性、开放性极强的任务比如“帮我想一个有创意的产品方案”纯靠Skill反而不如直接对话来得灵活。所以我现在是“探索靠对话执行靠岗位”。两个模式切换着用才是效率最高的状态。最后分享一个实用的小技巧在每个岗位的Skill里都留一个“复盘记录”区域。每次你发现AI在这个岗位上输出不理想就在复盘记录里记一句具体原因和修正方式。积累一段时间以后你会有非常清晰的“调教笔记”这是任何现成Skill仓库都替代不了的。我的8个岗位能持续跑稳靠的就是这份持续完善的复盘记录。