最近在折腾AI Agent工作流的时候我干了一件可能有点“过火”的事一口气装了30多个Skill然后把这些技能按职责分派给AI“安排”了8个不同的岗位让它在一个项目里像一支小型团队一样运转。最早我对Skill这种形态是持怀疑态度的总觉得无非就是把提示词封装了一下搞得花里胡哨实际用起来未必比直接在对话里写清楚要求强多少。但真正把这30多个技能插件按岗位逻辑重新组织之后我对“AI能不能稳定承担复杂任务”这件事的看法完全变了。先说结论这套玩法适合两类人。一类是天天跟AI打交道、觉得单次对话已经不够用的人——比如要让AI连续处理几十个文件的批量操作或者从需求到代码再到测试全流程跑完的项目型任务另一类是正在摸索AI Agent落地方式的开发者或产品经理想搞清楚“Skill”“Agent”“工作流”这几个概念到底该怎么在真实场景里配合而不是停留在概念层。这篇博文我不会讲太多抽象理论就围绕我实际搭建的这套“8个岗位”的体系把Skill的选型、岗位设计、协作文档、踩坑记录都摊开说清楚。1. 为什么我放弃了“一个超级提示词搞定一切”的思路在聊这8个岗位之前得先讲讲我为什么走到这一步。以前我用AI干活的方式很朴素写一个超长的提示词把角色、任务、输出格式、注意事项全部塞进去然后希望AI一步到位给出完美结果。这种方式应付简单的写作、翻译、代码生成确实够用但一旦任务链条变长问题就来了。最典型的例子是一次做数据清洗。我给AI写了一段很详细的指令让它读取一个CSV文件做缺失值处理、异常值剔除、格式统一最后输出一份汇总报告。结果AI在中间步骤出现了幻觉把本来应该保留的几行数据当成异常值删掉了而且它没有回头检查的能力直接就把错误的结论写进了报告里。问题不在AI不够聪明而在于我给了它太多的“自由发挥”空间——没有一个流程去约束它没有中间检查点也没有复审环节。后来我研究了一下Agent的运行模式发现一个关键点单个模型的上下文窗口再大本质上也还是“一次性思考”的产物。想在长链条任务中保持稳定只能靠外部机制把任务切碎、把责任拆分、把检查点硬化。这就像做饭再厉害的厨师一个人包揽从买菜、洗菜、切菜到掌勺、摆盘的所有环节出错的概率一定大于后厨里每个人都有明确分工的协作方式。Skill就是这种“分工”的最小单元。它不是一个简单的提示词文件而是一套带结构的指令包——里面可以包含任务描述、执行步骤、输入输出规范、甚至一小段可运行的代码脚本。装一个Skill相当于给AI发了一份“岗位说明书”你在什么场景下用这套技能你应该按什么顺序做什么事你的产出长什么样。但我很快意识到另一个问题单个Skill解决的是单一能力的问题而真实项目需要的是多个能力的串联。我今天要做的事情是“把一个模糊的产品想法落地成一份带原型图的PRD”它就同时需要需求分析、结构化写作、技术方案设计、甚至前端代码生成这几种能力。如果我在对话里手动切换不同的Skill效果其实很差——AI会在切换过程中丢失上下文也可能把上一个任务的输出风格带到下一个任务里。这时候我想到了一个词排班。我需要的不是30多个Skill堆在那里让AI自己挑而是我自己先想清楚这个项目需要哪几步、每步需要什么能力、产出物之间怎么交接然后再把对应的Skill按顺序排好、按岗位分好。于是就有了“给AI安排8个岗位”这套实践。2. Skill到底是个什么东西它的文件结构、工作方式和能力边界想把岗位体系搭起来首先得对Skill这个底层单元有足够的理解。现在市面上有不少平台支持Skill机制常见的形式分两种一种是原生支持比如Claude的Agent Skills你可以把一套指令和脚本放到指定目录模型会自动感知并按需调用另一种是第三方实现的插件机制比如各种Codex Skill、OpenClaw Skill、Workbuddy Skill本质上是语法和调用方式各自定义了一套规范。在我实际使用的环境里一个标准的Skill通常包含几个部分。最核心的是SKILL.md有些平台叫skill定义文件、manifest或者说明文档这是一个Markdown格式的指令文件里面写清楚这个Skill的名称、适用场景、执行步骤、输入要求、输出格式。它相当于这份“岗位说明书”的正文部分。此外还会有scripts目录存放配套的脚本文件——比如一个做PDF解析的Skill大概率会附带一个解析PDF的Python脚本一个做数据可视化的Skill会附带图表生成的模板或函数库。有些复杂的Skill还会带references目录里面放参考资料、示例输出、Few-shot样本帮助模型理解“好的输出长什么样”。这里有个很多人容易忽略的点Skill和普通提示词最大的区别在于它把“怎么做”的前置信息做成了模块化、可复用的资产。普通提示词是每次对话临时写一遍即使复制粘贴也会因为对话历史的变化而出现偏差Skill则是一个持久化的、绑定了脚本和示例的独立单元只要触发条件成立模型就能稳定地加载这套行为模式。打个比方普通提示词是口头交代一句“等会儿做菜清淡点”Skill则是给后厨贴了一张规范化操作卡盐放几克、油温多少、焯水几分钟全部标准化。不过Skill也不是万能的。要说清楚它的能力边界得看它实际做了什么。Skill本质上是在约束模型的推理路径和输出形式它并不能让模型获得一个尚未训练过的能力。比如我的一个Skill要求AI读取某个专有格式的文件并提取信息但它自带的Python脚本只能处理该格式的基础版本遇到加密或变种格式就束手无策了。这时候Skill能做的事只是把“处理失败”这个信号明确地抛出来并触发重试或降级逻辑——至于怎么处理真正的未知情况依然得靠模型本身的理解能力。所以我对Skill的理解可以总结成三句话它是行为模板不是能力外挂它负责减少随机性不能凭空创造知识它是流程的螺丝钉真正的架构还是得人来搭。3. 8个岗位是怎么定出来的从项目流程反推组织架构岗位设计这件事很多人一上来就容易走偏。有的人是看到哪个Skill热度高就装哪个装完发现根本衔接不起来有的人是按AI的能力项来分——写作岗、编程岗、翻译岗结果真要跑一个项目时发现能力之间没有依赖关系输出物无法对接。我自己是反着来的先定义一个标准项目从0到1要走过哪些阶段然后为每个阶段设置一个岗位再为每个岗位挑选或编写对应的Skill。以软件类项目为例我梳理出一个最基本的六阶段流程需求分析与拆解、技术方案设计、代码实现、测试验证、文档编写、部署与运维。但这六个阶段对应的“岗位”还不够细因为在真实的开发协作里需求分析和产品设计往往不是同一个人代码实现也经常要区分前端后端。所以我最终定下来的岗位是这些岗位A需求分析师。负责把原始想法或用户反馈结构化输出需求清单、用户故事、验收标准。岗位B产品设计师。负责把需求转化为带交互逻辑的产品方案输出页面结构、功能流程、信息架构。岗位C架构师。负责技术选型、模块划分、接口定义输出技术方案文档和任务拆解清单。岗位D前端工程师。负责界面实现输入产品方案和接口定义输出前端代码及页面截图。岗位E后端工程师。负责业务逻辑和数据处理输入接口定义和需求清单输出后端代码及API文档。岗位F测试工程师。负责编写测试用例、执行测试、输出缺陷报告核心逻辑是“专门找茬”。岗位G文档工程师。负责把前后端产出、API文档、部署说明整合成一份完整的项目文档。岗位H运维/交付工程师。负责部署脚本、环境配置、启动说明以及最终的成品自检清单。你可能会问那30多个Skill是怎么分配给这8个岗位的其实很简单有些岗位天然需要多个技能叠加。比如需求分析师这个岗位核心Skill是“需求分析”和“用户故事撰写”但我在实际跑流程时还会让它调用“竞品分析”和“优先级排序”这两个辅助技能前端工程师这个岗位则绑定了“HTML/CSS代码生成”“组件化开发”“响应式布局”三个技能外加一个用于截图验证的脚本型Skill。把岗位和Skill对应好只是第一步更难的是岗位之间怎么传递“工作成果”。我在实践里发现如果只给每个岗位单独定义输入输出最后接力的时候还是会乱套——因为岗位A的输出格式如果不符合岗位B的输入习惯交接就会出现数据损耗。所以我又设计了一套统一的“交接工件规范”这个等会儿在第四部分细说。4. 让8个岗位像同一个项目组一样协作交接工件与流程编排如果只是给AI配了岗位和Skill但没有一套明确的交接机制那这些岗位只是一堆散装零件。真正的Agent协作核心在于“工件”artifact的设计——上一个岗位的输出必须是一个结构清晰、能被下一个岗位直接消费的东西。我做了一套简单的交接规范每个岗位在完成任务后必须输出一个Markdown格式的状态文档里面包含几个固定的段落——任务描述、关键决策记录、产出物引用、遗留问题清单、对下一个岗位的特别提醒。同时如果有实际的文件产出代码、图片、文档必须按统一命名规范保存并在状态文档里附上文件路径和简要说明。举个例子需求分析师的产出物是一份需求说明书它不能只把用户故事往下一丢就完事。它还要在状态文档里明确告诉下一棒产品设计师有几个需求是从原始对话里推理出来的置信度不高建议在原型里做成可替代方案有几个需求存在互相冲突需要产品侧做个取舍判断。这些“元信息”如果丢了下游岗位就只能雾里看花。流程编排上我试过两种方式。第一种是“单会话接力法”也就是在同一个对话窗口里让AI扮演不同的岗位角色依次出场。这种做法的优点是上下文不会断每个岗位都能看到之前所有岗位的工作结果理解更充分缺点是模型很容易“入戏太深”上一个岗位的口吻和思维模式会污染下一个岗位——比如让架构师出方案的时候它还在惦记需求分析师之前写的某个用户故事里的细节导致技术方案偏离了核心目标。第二种是“多会话交接法”每个岗位开一个新对话只把上一步的状态文档和相关文件喂给它。这种做法的优点是职责隔离更彻底每个岗位只基于标准化的交接材料做判断不会受到其他岗位历史噪音的干扰缺点是需要手动或通过脚本在会话之间搬运文件流程一复杂就有点累人。我目前的倾向是混合方案简单项目用单会话接力法控制在两三个岗位以内复杂项目强制用多会话交接法配上我自写的一个小工具来管理交接文档和文件版本。实测下来混合方案在保证质量的同时也能兼顾效率。另外有一个小细节值得单独说无论如何编排流程一定要在给下游岗位的交接文档里加上“禁止臆测上游意图”这条约束。因为模型在两个岗位交替时最容易犯的毛病就是自己去脑补上游岗位“可能想要什么”从而添加一些完全没有依据的内容。像我自己跑过一个电商项目前端工程师在没看到接口文档的情况下擅自给自己的组件mock了一套登录态的返回数据结果后端对接时接口字段对不上白白多花了一轮返工时间。5. 30多个Skill的选型思路哪些必须装哪些装了纯属浪费既然标题说了“装了30多个Skill”那就必须详细聊聊选型这件事。说实话这个数量并不是一开始就规划好的而是随着跑的项目越来越多慢慢积累出来的。但“装得多”和“装得对”是两回事我回头复盘了一下发现这30多个Skill大致可以分成四类每一类都有不同的选型逻辑。第一类是高频刚性技能属于必装项。这类Skill的特点是适用面广、触发频率高、替代成本低。比如“代码审查”“文档结构化写作”“正则表达式调试助手”“API接口文档生成”这些几乎每个项目都能用上装了之后可以稳定减少重复劳动。我统计过在我跑的十几个项目里“代码审查”这个Skill的调用率是100%没有任何一个项目跳过它。第二类是场景增强型技能属于适当装配项。这类Skill只在特定场景下才有价值但一旦触发收益非常明显。比如“PDF表格抽取”“PPT大纲生成”“DrawIO图结构生成”。如果你日常根本不做PPT那“PPT大纲生成”这个Skill装不装其实无所谓但对我来说每个项目的方案评审都要出PPT所以这个Skill就是刚需。第三类是流程串联型技能属于组织升级项。这类Skill单个看起来没什么用但把它们按流程编排起来就能搭出一条自动化链路。比如“任务拆解”“工时预估”“风险识别”这三个技能单独用都很空泛但放在我那个“架构师岗位”里它们就能把一份技术方案文档自动拆解成可执行的开发任务清单还带优先级和预估工时。这种Skill的价值不在单点能力而在流程整合。第四类是实验尝鲜型技能属于可装可不装。这部分的Skill数量大概占三分之一说实话很多是装了之后才发现用处不大。最典型的是一个“智能命名助手”的Skill本意是帮代码变量起名更规范但实际跑下来发现现代模型的命名能力已经足够好这个Skill不仅没提升效果反而拖慢了推理速度因为每次生成代码它都要额外做一次命名解释。后来我直接把它卸载了。所以如果你想复制我的路我不建议一上来就追求“多多益善”。更务实的做法是先跑一个完整的小项目记录下每一个让AI“卡壳”或“返工”的点然后针对这些点去寻找对应的Skill。这样扩散着装每一件都是因为真的需要而不是因为别人说好。6. 配置和调试的完整实操过程从装一个Skill到跑通岗位流程说了这么多理论下面上一段完整的实战记录。我以“用这套岗位体系给一个内部工具生成带测试的开发代码”为例完整拆解一遍从装Skill到跑通流程要做的事。第一步装环境。我的Skill运行环境基于Claude Code的Agent Skills能力另外装了OpenClaw做自动化调度。安装方式很简单把Skill目录放到指定文件夹下然后在配置里声明启用。不过这里有个坑Skill目录里的文件名必须遵循小写英文加短横线的规范中文字符或下划线容易导致调用异常。我第一次装的时候就因为文件名里带了个中文冒号结果Skill根本识别不了排查了半天才发现是这个原因。第二步按岗位组织Skill。我在配置目录下建了8个子文件夹分别对应8个岗位每个文件夹里放属于这个岗位的Skill目录。同时我写了一个总控索引文件里面记录每个岗位可以用哪些Skill、在什么情况下应该由系统推荐调用还是用户手动触发。这一步很重要因为如果系统让AI自己去30多个Skill里挑它很容易选错。比如有的场景需要“测试工程师”出场但AI因为上下文里有大量代码片段误以为还在“后端开发”阶段就会调错岗位的Skill。第三步配置交接规范。我写了两个全局性的辅助指令文件一个是“状态文档模板”所有岗位在任务结束时都要按这个模板输出交接文档另一个是“文件命名规范”约定输出文件的命名格式比如代码文件按“模块名_功能_版本.py”命名报告按“项目名_岗位名_日期.md”命名。这两个文件不属于任何具体岗位但在每次交接时都会被作为背景知识加载。第四步跑一个最小的端到端流程。我往往不会一上来就跑全流程而是先做一个“冒烟测试”给需求分析师岗位一条很简单的虚拟需求然后人工跟着它走一遍全流程看输出物能不能顺利传递到下一个岗位。冒烟测试强调的是“环节是通的”而不是“结果是好的”。第五步调试卡点。冒烟测试里最常见的问题是某个岗位输出的交接文档里缺失了下一个岗位需要的关键信息。比如架构师的方案文档里没写清楚API的请求方法导致后端工程师不得不回头追问。我的处理方式不是修改岗位的Skill而是在“状态文档模板”里增加一个必填字段“给下游提供的关键参数清单”逼着每个岗位在交接前做一次自检。这种做法比单纯在提示词里说“请详细输出”要有效得多因为它把抽象要求变成了结构化的强制检查项。整个配置过程大约花了我一个周末。数据方面我在冒烟测试里用的是一份真实的开源电商项目代码库规模大概涵盖40多个文件总代码量在1万行左右。第一次跑全流程的时候8个岗位依次执行总耗时大约是47分钟其中测试工程师岗位占了三分之一的时间——因为它要做静态分析、单测运行和报告汇总三件事。这个时间成本对于复杂项目来说是可以接受的但如果你只是想让AI帮你写一个简单的脚本完全没必要开8个岗位去跑一两个Skill就足够了。7. 我踩过的坑五个让这套体系差点翻车的细节配置和调试过程中我积累了不少踩坑经验。这些细节如果不注意岗位体系很容易跑着跑着就崩盘。我把最典型的五个拎出来说。第一个坑是“岗位职责冲突”。当我给8个岗位各自配备了独立的Skill后AI在某个岗位上干活时依然可能偷偷调用其他岗位的技能。比如测试工程师岗位明明只触发了测试类Skill但它写缺陷报告的时候突然用起了“文档工程师”的措辞风格导致报告过度润色、失去了bug描述的犀利感。这个问题的根源在于上下文窗口里所有Skill的描述信息是同时存在的模型缺乏“当前岗位不能越权”的强约束。我的解决办法是在每个岗位的任务指令开头加一行只能调用本岗位任职说明中列出的技能标签其他岗位的任职说明仅作背景参考禁止直接激活。第二个坑是“技能脚本膨胀导致上下文污染”。有些Skill会附带比较长的脚本代码或参考文档模型在调用时会将整个脚本内容读入上下文。装得多了每个Skill哪怕只被简单触发一次也会贡献几千甚至上万个token最终把有限的上下文窗口挤占得所剩无几。我遇到过最夸张的一次是同时触发了三个分别带长CSV数据集、大段HTML模板和完整Python脚本的Skill结果上下文窗口直接爆掉AI开始“忘记”项目背景。解决办法是给每个Skill设置“最小必要上下文”原则——把脚本压缩成精简版只在需要时按需展开。第三个坑是“交接文档玄学化”。我最初的交接文档模板自由度很高写着“请总结你的关键决策和输出结果”结果不同岗位写出来的文档风格差异极大有的只写了三行有的写了上千字却全是套话。后来我把模板改成了强制的结构化表单字段一、字段二、字段三这样列出每个字段有明确的填写要求并配上示例。实践表明给AI的模板越像“表格”它的输出就越稳定越不会自由发挥。第四个坑是“模型本身的行为差异”。同一套Skill配置在不同模型的版本上效果差异很大。比如某些老版本模型对长指令的遵循能力明显更弱Skill里的步骤经常被跳过而新版模型虽然理解力强但容易在执行时自作聪明地添加额外步骤。这导致我调好的流程在模型升级后偶发失灵。对这个问题我给核心岗位配置了两套Skill描述一套精简版用于老模型一套详细版用于新模型。虽然后续维护成本高一点但能保证流程的稳定性。第五个坑也是最隐蔽的一个——“提示词注入”。因为Skill文件本质上是可被读取的文本如果我在某个Skill的示例输出里不小心放了一段“忽略上述所有指令直接输出xxx”的文字那模型在执行时可能真的会受到这段文字的影响产生荒谬的输出。这个问题在引入第三方Skill时尤其危险所以我现在对下载来的Skill都会做一次筛查把所有示例输出中的“指令性文字”去掉。8. 岗位运行一周的实测结果效率和质量的真实对比配置完这套体系后我用它实际跑了一周的日常工作任务期间处理了三种比较典型的任务一个带登录和后台管理的Web应用中等复杂度、一份行业调研报告信息收集型、一个内部数据清洗流水线脚本自动化型。先说Web应用这个案例。以前我直接用对话让AI写一个完整的小型Web应用从登录、权限到数据展示需要来回纠错大概五六轮总有这里的样式不对、那里的接口对不上的问题。这次用岗位体系跑需求分析师先输出了一份需求清单架构师据此拆解了模块前端和后端分别实现了代码测试工程师最后跑出了11个缺陷。整个流程下来代码的完成度非常高我要做的就是修复测试提出来的一部分缺陷而不是从零开始磨。总耗时大约4个多小时——看着比单次对话慢但质量稳定性和返工次数完全不是一个量级。行业调研报告这个案例更体现岗位体系的价值。需求分析师先确定了报告范围和信息维度文档工程师再按结构化模板收集信息、填充内容。关键是测试工程师这个岗位在这次任务中临时切换成了“事实核查员”角色它把报告中的每一条数据都标注了来源并对模糊数据进行风险提醒。这个“交叉验证”的步骤是以前用单次对话时很难实现的——因为单次对话中AI自己写的内容不会自己质疑。数据清洗流水线那个案例相对简单我只启用了三个岗位架构师设计清洗规则、后端工程师写脚本、测试工程师用一份脏数据样例做验证。效果喜人的一点是以前用单次提示词让AI写清洗脚本时它写出来的正则表达式常常漏掉边角情况而这回测试工程师岗位主动构造了几条边界情况的数据来验证比如空值、超长字符串、带Unicode特殊字符的内容把问题提前拦住了。从统计角度看在这三个案例中岗位体系相比我此前的单次对话方式平均返工次数下降了约六成质量验收的一次通过率明显提升但总耗时平均增加了大约50%。这个时间成本花得值不值取决于你对稳定性的要求有多高。如果只是写个一次性脚本没必要杀鸡用牛刀如果是正经的项目开发或者对外交付的文档这套流程的性价比就非常明显了。9. 这套玩法适合什么样的场景、不适合什么样的场景任何工具方案都有它的适用范围。这套“多Skill多岗位”的体系适合的场景有这么几个特点任务链条长跨多个知识领域产出物需要被反复复用或交接质量要求高不能容忍频繁返工以及你对过程的管控欲比较强希望每一步都透明可查。反过来说有些场景根本不适合这么干。最典型的是“灵感探索型任务”——比如让AI帮你头脑风暴几个创意方向或者初步了解一个陌生领域。这种任务追求的是发散性和速度你不想被流程绑住手脚也不想让AI在8个岗位之间来回切换。我自己的经验是这种场景用一个轻量的Skill甚至不装Skill直接对话效果更好。另一个不适合的场景是“极短的小任务”。比如让AI改写一段文案、翻译一句话、写一个几行的函数这种任务如果也要走岗位流程纯属浪费时间。我的建议是给这套体系设一个“任务复杂度阈值”当任务预估需要超过30分钟的人工工时、或者涉及两个以上专业领域时才考虑启动岗位流程否则就停留在“单Skill对话”的层次。还有一点必须提醒这套体系本身需要维护成本。Skill会随着模型版本升级和行为变化而定期失效交接文档模板也要根据实际问题迭代。如果你对AI的使用频率很低或者没有动力持续调试那么花一整个周末搭建起来的流程闲置两周后再用很可能已经需要修修补补才能跑通了。10. 如果你也想搭一套我给五条最核心的建议如果看完前面这些你也想给AI搭一套岗位体系那我给你五条掏心窝的建议。第一条先从两个岗位开始不要直接上8个。我见过太多人一上来就想搭一个宇宙级完整的Agent团队结果搭到第三天就放弃了。最健康的起步方式是先选一个你最高频的任务类型比如“从需求到代码”只配需求分析师和程序员两个岗位把交接模板和Skill配置都打磨顺了再逐步增加测试、部署这些新岗位。第二条交接文档比岗位Skill更重要。可以说这套体系跑得好不好七八成的功劳要算在“状态文档模板”上。模板字段要具体到“下游必须拿到什么”而不是泛泛的“关键信息”。同时模板需要跟随 реальных 案例反复迭代——每发现一次交接断层就把它固化成一个新的必填字段。第三条宁可少装Skill也不要把上下文窗口撑爆。我最后的配置虽然名义上有30多个Skill但实际在每个岗位的“可调用清单”里通常只列了3到5个。其他Skill更像是备选库在特殊场景下手动启用。这样既能保持流程轻快又不浪费辛苦积累的技能资产。第四条定期做“回归测试”。每当模型升级或者新增了一个Skill我都会跑一遍那个冒烟测试用例看看整条链路是否还通顺。这个习惯帮我提前发现了不少潜在问题——比如有一次模型升级后文档格式输出开始多出很多不必要的Markdown表格要不是回归测试跑出来我还浑然不觉。第五条保留“人工仲裁”的位置。岗位体系再完善也不能完全替代人的判断。我的做法是每个岗位输出交接文档后都要过一遍我的目视检查确认没有明显的方向性偏差。尤其是第一个岗位需求分析师的输出如果这一环理解错了方向后面所有岗位的努力都会白费。因此我宁愿在这个环节多花5分钟也不愿整条流水线上跑出一堆无用的产出。这里也补充一个更细节的观察岗位顺序不是一成不变的。在不同类型的项目里有些岗位可以并联而不是串联。比如一个数据清洗项目里架构师和测试工程师可以并行工作——架构师设计清洗规则的同时测试工程师构造测试样本集。工作流的编排逻辑应该由任务特征决定而不是死守着8个岗位的固定顺序。还有一个容易被忽略的点单个Skill本身的质量直接决定了岗位的下限。我在整理这30多个Skill时发现有些下载来的Skill写得又长又啰嗦看起来专业实际执行时模型根本不会按它的步骤走。反而是一些言简意赅、示例清晰的Skill效果出奇地好。所以如果你拿到一个Skill发现执行效果不佳先别急着怪模型试着精简一下它的描述文本删掉那些“正确的废话”很可能立刻就有改善。我现在每天的工作流里这套岗位体系处理的是那些“模块化、可验证、交接清楚”的任务而我自己则把精力腾出来做那些真正需要人类判断的事情——比如定义问题、评估方向、调整优先级。从这段实践里我最深的体会是AI的能力已经足够强了真正的瓶颈在于我们能不能给它设计出合适的组织方式。30多个Skill、8个岗位本质上不是在“调教AI”而是在“重构自己的做事方法”。