上周我在折腾 Claude Code 的配置方案时发现一个在开发者圈子里传得很凶的开源项目标题大意是“把 Claude Code 变成 66 个专家”。说实话我第一次看到这句话是有点反感的——见多了“一个提示词让 AI 脱胎换骨”的 C 语言式标题总担心又是一堆花里胡哨的功能设定点进去后会听到预制的“智能客服口气”。但看了这个 5.8k Star 项目的实际内容之后我确实重新想清楚了一件事大多数人所谓的“会用 AI”其实只停留在“会下指令”离“会设计协作流程”还差得很远。“66 个专家”当然不是真的分裂出 66 个人格而是这套开源项目把 Claude Code 的日常用法重新组织成了一份“专业角色目录”。你可以随手在终端里唤醒一个“API 设计专家”或者调出一个“SQL 优化教练”甚至让“代码审查专家”以一套严格的验收清单来审视你的提交。刚开始我只觉得这是个挺花哨的提示词集合配置进去用了三天之后才慢慢意识到它背后藏着一套非常值得学习的思路AI 很强但如果不给它明确的身份、边界、任务契约它就只会变成一台“极其听话的废话生成器”。这篇文章我会从设计逻辑、核心机制、完整实操、真实使用感想、常见坑几个角度把这件事拆开讲清楚。无论你是只用过几天 Claude Code 的新手还是整天跟 Agent 打交道的重度用户都可以在中间找到对你有用的东西。1. 这个项目到底在解决什么问题1.1 一句话理解“66 个专家”先别急着脑补科幻电影。这个开源项目做的事情其实特别朴素它准备了一堆精心编写的角色能力文件每个文件都对应一个专职岗位的“人设”。“人设”不是让你更多像聊天伙伴而是把 AI 的行为边界、思维方式、输出格式、说话口吻全部固化下来让它在不同任务中自动切换状态。你可以把它理解成同一台服务器上跑着 66 个不同的虚拟桌面每个桌面里打开着不同岗位的开工手册。你要做“算法选型”就进算法专家的桌面你要写“政务材料”就切到公文教练的桌面你甚至还可以让“数据库索引专家”和“性能监控专家”在同一个会话里轮流发言像两个顾问轮流给你建议一样。我在一开始也以为这不就是“一堆角色扮演提示词”吗后来实际用起来才发现它真正狠的地方在于“分工”和“约束”。同一个 Claude Code如果没有任何专家角色它遇到“帮我做个库存模块”时会非常均匀地平铺展开需求讨论、表结构、接口、页面、测试什么都没漏但什么都做得大而空。一旦用上了“后端专家数据库专家”这样的角色组合AI 会在第一轮就主动向你确认分页策略和库存扣减并发问题输出的质量完全不是同一个量级。1.2 为什么这个痛点普遍存在很多人现在用 Claude Code工位还停留在“开一个终端敲一句 prompt看输出”。这种方式不是不能用但有一个天然缺陷没有任何一个通用模型能在每一次回答中都自动采用“资深架构师视角”或“资深编辑视角”。因为通用 AI 的关键机制之一就是“顺着概率往下接”。你问它“这段代码怎么写”它会自动倒向“最普通、最常见、最不易出错”的那种写法。这种写法对简单任务没问题但对复杂问题就是灾难。举个生活中的例子。一个刚进后厨的新手和一个干了十几年的老师傅如果用同一份菜谱做同一道菜味道差异一定很大。差别不在“知道多少步骤”而在老师傅对每步的判断标准、对火候的敏感度、对突发状况的预案。这些判断标准没法直接写进一份简单的菜谱里只能通过“这个师傅做菜时脑子里转的那套东西”来体现。开源项目的专家角色干的就是这件事把“老师傅脑子里转的那套东西”提前写进 Claude Code。1.3 合适的人群与使用场景根据我这段时间的观察这类“专家矩阵”式玩法最适合下面三类人正在用编码助手做真实项目的开发者而不是偶尔写段脚本的体验者。需要让 AI 频繁处理不同领域任务的自由职业者、独立开发者、小团队。对提示词略有基础但已经受够“模板式回答”想让 AI 输出更接近专业交付物的人。如果你是那种直接把需求粘贴进去、只要最终能跑就行的人那这套方案前期会把你的配置复杂度拉高不少可能不划算。但一旦你的产品处于真实业务里、需要跟质量、成本、风格、交付标准打交道它就值回票价。2. 设计思路解析为什么是“角色工程”而不是“提示词工程”2.1 单个万能提示词的极限在哪里我见过不少开发者试图写一个“包打天下”的超级提示词比如“你是一名顶级全栈工程师、架构师、产品经理、运维专家、设计师、测试工程师……请根据我的需求给出最佳方案。”这句话看起来什么都说了实际效果却非常差。因为模型在接收这种指令时会同时激活大量互相重叠的行为模板最后输出结果大概率是“每条线都擦了边每条线都不够深”。而且这些模板之间还会打架你既要求它“给出完整代码”又要求它“先讲设计理念”矛盾之下模型只能选择最中庸的路线——先简单说几句理念再甩一段平平无奇能跑的代码。这种“全能式提示词”的失效本质上是因为缺少“场景开关”。你把 6 种角色的指令焊死在同一个上下文里模型只能在“混合状态下”做平均化输出。角色工程的核心则是把这些指令拆开、分成独立的场景包并在需要时只加载其中一个。2.2 66 个角色不是随意堆的而是一套专业分工体系我拉出这个项目的角色目录清单看了很久发现它的分类明显是按照“成熟技术团队的组织架构”去设计的。领域类角色前端性能专家、后端架构师、数据库优化师、安全审核员、DevOps 工程师、算法工程师。流程类角色需求分析员、任务拆解师、代码审查专家、测试设计专家、发布经理。通用软技能类角色文档写作者、沟通教练、复盘顾问、汇报整理师、反方辩手。行业垂直角色比如面向电商、内容平台、教育、金融等细分领域的专家。这种组织结构带来的好处是当你面对一个复杂任务时可以像“组一个虚拟项目组”那样挑选角色而不是指望 AI 一个人懂所有事。比如说你今天要完成一次“登录模块的安全改造”。你可以先调“安全审计员”做风险静态检查再叫“后端架构师”评估整体改动方案接着让“代码审查专家”对实际操作做逐行把关最后由“文档写作者”输出一份给团队看的改造说明。整个过程下来同一套 Claude Code 底座却体验到了四个人接力做事的节奏。2.3 专家之间的协作与冲突解决有人会问既然有这么多角色我是把它们全部加到同一个会话里一起做吗这个项目给出的思路很聪明不要让所有专家同时上台而是让它们“按需出场、轮流发言”同时在系统的全局配置里设计了一套极其关键的“冲突裁决规则”。具体做法是角色文件里不仅写“你擅长什么”还会写“你什么时候应该闭嘴”。比如一个“风险控制专家”被要求当开发专家说“方案可行”时你必须站出来指出三个潜在失败场景但你又不能为了反对而反对必须给出可量化的依据。这就解决了多数人做多角色 prompt 时的最大难题角色之间互相抢话或者一团和气。这种思路本质上是在模拟真实工作场景中的“不同岗位协作必须遵守的秩序”。真实团队里不会让研发、财务、法务、客服同一时间抢一个麦克风而是每次就一个目标让相应角色发言其他角色只做被动参考。项目的核心价值之一就是把这种秩序固化到了配置里。3. 核心机制解析这些“专家”到底是如何装进 Claude Code 的3.1 角色定义的载体Markdown、JSON 与配置目录从项目结构上看它的每一个“专家”都不是一堆散兵游勇的文字而是有着清晰结构的角色定义文件。我见过的大多数同类工具都会用 Markdown 描述角色人设再用一份 JSON/YAML 来挂载角色的触发规则、适用场景、禁用语。具体参考结构大致如下# 角色: 前端性能专家 # # 适用场景: 页面加载速度优化、性能预算、关键渲染路径分析 # 触发词: frontend, performance, LCP, bundle size # 专长: 网络请求优化、渲染性能、构建产物分析 你是一名专注前端性能的前端性能专家。 行为准则 - 先搞清楚用户的核心性能指标而不是直接做优化 - 分析瓶颈时优先考虑网络链路和渲染链路 - 每次修改都必须给出 Before/After 的预期量化结果 - 不要直接抛出大段重构代码先说明改动思路再动手 默认输出格式 1. 问题判断 2. 影响因素分析 3. 可执行方案 4. 风险提示这种结构最关键的一点是把“人设”和“行为契约”分开。人设负责让模型进入状态行为契约负责让模型的输出收敛到可用的范围内。很多自己写的“角色提示词”只堆砌了人设没有行为契约结果就是 AI 沉浸式扮演一个专家却依然输出一堆正确的废话。3.2 动态加载方案66 个专家如何避免上下文爆炸你可能已经想到如果一个专家定义文件动辄几百字66 个全扔进上下文那 Claude Code 就算有再大的窗口也不够用。这个项目解决方式很简单也很有启发性不在启动阶段加载全部角色而是在需要时按需注入。项目中通常有一个调度器或者选择器脚本它会根据用户的输入关键词自动挑出 1 到 3 个最相关的角色定义再把这些定义补到当前会话的指令前缀里。这里面的匹配逻辑也很讲究不是简单做关键词命中而是综合了“语义相似度 场景规则”。比如用户输入“帮我优化一下这个 MySQL 查询最近越来越慢了”选择器可能同时激活“数据库优化师”“后端性能分析师”两个角色而不会把“UI 设计师”拉出来。一个特别值得学习的设计细节是选择器本身也被定义成“角色”。也就是说它是 66 个专家之外的“第 67 个角色”职责不是回答问题而是判断该叫谁上台。我后来自己复刻项目时发现只要把这个调度角色写清楚整体的可用性会翻一倍。3.3 与 Claude Code 的集成点斜杠命令、钩子、记忆文件从实操层面讲这些专家角色可以通过 Claude Code 的自定义命令机制来实现。斜杠命令把每个专家定义放到指定命令目录下比如/expert命令输入/expert security-audit就加载安全审计员角色。钩子通过特定事件触发角色比如在 Git 提交前自动调用“代码审查专家”检查 diff。记忆文件在全局记忆文件如 CLAUDE.md里声明“专家目录的位置”和“默认调度规则”让 Claude Code 随时知道哪些角色可用。我最常用的是斜杠命令方式因为它足够直观且不会污染全局上下文。你不需要让所有专家常驻脑子里只需要在要做某类任务时用一条命令把对应专家“指名道姓”地喊进来。举个例子我创建一个review专家后会在代码提交前执行claude -p 审查当前 git diff --expert review这个命令会触发一个高度结构化的代码审查过程AI 先读取 diff再按照代码审查专家的人设逐项检查最后输出一份包含问题等级、风险原因、修改建议的审查报告。4. 实操记录在本地复现一套“专家矩阵”4.1 准备基础环境与获取项目先把前提条件列清楚。你本机需要装好 Node.js 以及 Claude Code 或对应运行环境同时拿到一个可用的 API 密钥。整个过程在 macOS 和 Linux 上跑起来基本顺畅Windows 下如果配合 Git Bash 或 WSL 也没太大问题。克隆项目到本地项目会提供一个角色目录里面可能已经内置了几十个 Markdown 专家模板。安装依赖多数这类项目只依赖少数几个脚本不会有重量级依赖装起来很快。检查配置入口看项目中是否包含配置文件、启动脚本或调度器说明。我第一次跑的时候只改了配置文件的路径五分钟就启动了第一个专家角色。如果你在运行阶段看到类似“找不到自定义命令目录”的报错不用慌基本就是环境变量或目录权限的问题后面排查章节会专门说。4.2 创造属于自己的角色文件这个项目最有价值的地方不是那 66 个专家本身而是它定义角色文件的方式。我强烈建议你先复制一两个模板改成自己的别直接拿着预置角色硬上。下面是我自己为一个“Node.js 后端重构专家”写的角色文件# 角色: Node.js 后端重构专家 # # 适用场景: 旧代码重构、模块拆分、去耦合、技术债治理 # 触发词: refactor, nodejs, legacy, module split 背景: 你是一名专注 Node.js 后端重构的架构师参与过大量老项目的模块化拆分 你熟悉从“能跑”到“好维护”之间需要走完的关键路径。 任务行为: - 第一轮先回答“这个模块当前的核心职责是什么”而不是急着给重构代码 - 把重构理由拆成“可维护性 / 性能 / 可测试性”三个维度讲 - 严格限制每次重构的影响范围不做跨模块的连带改动 - 改完代码后必须给出可执行的测试验收点 禁止事项: - 不要一次性输出大段完整代码要分步骤交付 - 不要为了“更优雅”引入不必要的新依赖 - 不要忽略对现有外部接口的兼容性影响 输出结构: - 现状诊断 - 重构边界 - 分步实施计划 - 风险清单 - 验收测试点写完这个文件后把它放进命令目录。然后在 Claude Code 里执行启用命令角色就能被识别。我发现一个值得分享的经验角色文件里写得越具体效果越好。特别是“禁止事项”这段它能明显压制 AI 自动生成“大而全但无法落地”回答的冲动。4.3 用一次代码审查任务验证效果我建议你不要一上来就拿自己的核心项目做实验先用一个小仓库跑通流程。这里是我做的验证过程准备一个 Git 仓库里面有几处明显的坏味道比如长函数、魔法数、重复的三层循环。调用默认 Claude Code 模式问“看看这个仓库有哪些问题”。再调用/expert code-review问同样的问题。对比两份回答的深度和行动力。我的真实感受是普通模式下AI 的回答像“礼貌的代码朋友”指出问题也给出建议但语气和判重都像在做“通用检查”。专家模式下的回答则像“一个有点操心的技术主管”它会按严重程度排序会把每个问题关联到具体业务风险最后甚至提醒我“先不要动 xx 文件因为它在别处被引用了”。这个差别不是模型本身能力变了而是角色定义里的行为契约把回答逼到了另一个方向。4.4 从单角色到多角色的接力协作如果说单专家只是开胃菜那多专家协作才是这套玩意的正餐。我在做一次“服务拆分方案”时实际跑了一个三专家接力流程claude -p 分析当前订单服务的拆分边界 --expert domain-mapper claude -p 评估拆分后的事务一致性问题 --expert transaction-specialist claude -p 给出6个月的平滑迁移计划 --expert release-planner关键技巧是每次调用都以上一次的输出作为输入上下文。也就是说domain-mapper 先输出一个初步方案我把它作为内容片段传给 transaction-specialist 继续挑毛病最后再交给 release-planner 做计划。整个过程约等于一个流水线提出问题 - 领域建模 - 风险评估 - 落地计划。这种接力模式上来会让人适应不了因为每一步都要人为传递上下文。但它有个巨大优势每个专家都只负责一个小环节它的上下文窗口里塞满了高度相关的领域知识不会因为同时兼顾多个目标而稀释质量。5. 实际使用三周后我的效果观察5.1 质量提升最明显的几个场景用了差不多三周后我总结了几个效果特别显著的场景第一是代码审查。有了固定的审查角色后每次提交前检查出来的问题从“语法/规范类”提升到了“并发风险/边界条件/隐式耦合”这个层级。过去靠人工审查才能捕捉到的深水区问题现在 AI 会主动列出来虽然不能完全替代人工但它帮我节省了大量“扫描代码”的时间。第二是需求拆解。每天面对大量模糊需求时我会用“需求分析员”先做一轮任务拆解。它会强制我把一个含糊的表述拆成“业务目标、约束条件、验收标准、非目标”四个部分。自从用了这个流程我在和同事确认需求时几乎没有再出现过“聊到最后发现两边理解完全不一样”的情况。第三是文档输出。给专家角色绑定一套格式契约之后它产出的文档稳定在许多技术人员都很少有的“报告风格”里段落间有逻辑递进每节末尾有“这句的关键假设是什么”完全不像 AI 默认的百科式写作。5.2 成本与时间账值不值我当然也关注 token 消耗。实测下来使用专家角色后单轮的 token 消耗通常会增加 20%~40%。原因很简单角色定义文件本身会占用上下文且专家输出往往更长、更结构化。但总时间成本反而是下降的。为什么因为普通模式生成结果后通常还需要我再写一轮甚至两轮追问来“校准方向”。比如我让它写接口文档第一版写得规整但完全不符合团队要求的模块命名就得再来一轮纠正。而专家模式因为提前写清了“禁止事项”和“输出结构”第一版往往就能直接用返工率大幅下降。如果你是在真实项目里用这个成本结构是相当划算的。如果你只是随手做点小实验那多出来的 token 可能会让你觉得不值这是很多人在初期配置后容易产生“怀疑人生”情绪的主要原因。5.3 它并不是万能钥匙边界也很明显必须说点反面的。专家角色没办法让 AI 突然拥有它本不具备的知识。如果你的角色定义里写“你是资深 Rust 编译器专家熟悉内联汇编优化”但模型本身对这方面的知识储备很浅那它就是扮演得再像给出来的建议也可能是不准确甚至危险的。还有一类问题是“过度形式化”。当任务明明很简单时专家角色依然会按固定格式输出“五段法”让简单问题显得异常臃肿。我现在遇到非常小的需求会直接切回普通模式避免专家角色产生杀鸡用牛刀的效果。另一个边界是专家矩阵对单一任务的串行处理很在行但面对那种“需要通盘综合考虑”的全局性任务反而吃亏。如果交给它一个整体架构设计任务它会因为过度强调职责边界而丧失全局平衡感。这种湿度判断恰恰是使用者要保留的最重要能力。6. 常见问题与排查技巧速查6.1 角色没有生效 / 回答没有任何变化这是刚配置时最容易遇到的问题。通常原因不是角色文件没写好而是调用时没有正确加载。排查顺序确认命令目录路径和 Claude Code 配置指向的是同一个目录。确认角色文件名后缀是否匹配一般是.md。直接在斜杠命令里输入角色名看看是否报“未找到”。查看系统全局记忆文件确认它是否包含了要激活的角色的索引。我踩过最大的坑把角色文件塞到了普通目录里结果 Claude Code 根本没扫描到。后来统一把角色文件放进命令规范目录后问题立刻消失。6.2 专家之间的意见冲突多专家协作时意见冲突几乎是必然的。安全专家说不能这么改性能专家说必须这么改。这时最忌讳的就是两个角色同时进入辩论模式。我的处理方式是在供给两个专家的最终 prompt 中预留一个“仲裁规则”比如明确写“冲突发生时优先遵循安全约束如果安全性没有差异再考虑性能优化”。你会发现只要你在对话开场就定义了优先级专家们的表现会非常收敛不会再像吵架一样。6.3 上下文不够用专家多了反而“变笨”这是最难缠的问题。你连续切换多个专家后之前的对话内容会一直留在上下文里专业角色越多AI 越容易表现出“遗忘”或“回答平庸”。解决办法有三个在切换专家时手动清理无用的历史对话或开启精简上下文模式。每个专家只处理一小段高聚合度的输入不要把大量碎片喂进去。把专家定义做成“按需注入”而不是“一开始就全量挂载”。我自己的习惯是把每个专家的“核心指令”压到 200 字以内把“行为契约”留在角色文件里这样真正进入上下文的部分不会太多。6.4 角色提示词被全局记忆文件覆盖还有一个隐蔽问题如果你在全局记忆文件里写了大量强调“你是 Claude、你是通用助手”的内容它可能会覆盖专家角色的设定。全局记忆的优先级如果高于角色文件专家味就会被冲淡。遇到这个情况要么把全局记忆里的相关指令移除要么在角色文件里显式声明“这里是专家模式请忽略全局记忆中的通用助手指令”。这两种方法我都试过显式声明通常更稳定因为它不需要你本地同时修改全局文件。最后再分享一个最近的实际体会配置 66 个专家只是入口真正的分水岭是你愿不愿意为不同任务设计不同契约。我反复折腾这套项目之后最大的收获不是某个专家角色多好用而是我彻底放弃了“一句话让 AI 变成高手”的幻想。会用 AI 的人从来不是会写华丽指令的人而是懂得给 AI 找对位置、画清边界、定好验收标准的人。如果你准备开始玩这套“专家矩阵”也请一定从自己最痛的那个场景下手。先建一个角色用一周再迭代它。等你发现 AI 开始主动追问“这个需求的一致性约束是什么”时你就理解为什么说“66 个专家本质上是一场针对 AI 工作方式的精密组织工程”了。 
长河君 · 2026/10/21 12:18:11 · 阅读 1.2k 把Claude Code变成66个专家：角色工程实战解析
上周我在折腾 Claude Code 的配置方案时发现一个在开发者圈子里传得很凶的开源项目标题大意是“把 Claude Code 变成 66 个专家”。说实话我第一次看到这句话是有点反感的——见多了“一个提示词让 AI 脱胎换骨”的 C 语言式标题总担心又是一堆花里胡哨的功能设定点进去后会听到预制的“智能客服口气”。但看了这个 5.8k Star 项目的实际内容之后我确实重新想清楚了一件事大多数人所谓的“会用 AI”其实只停留在“会下指令”离“会设计协作流程”还差得很远。“66 个专家”当然不是真的分裂出 66 个人格而是这套开源项目把 Claude Code 的日常用法重新组织成了一份“专业角色目录”。你可以随手在终端里唤醒一个“API 设计专家”或者调出一个“SQL 优化教练”甚至让“代码审查专家”以一套严格的验收清单来审视你的提交。刚开始我只觉得这是个挺花哨的提示词集合配置进去用了三天之后才慢慢意识到它背后藏着一套非常值得学习的思路AI 很强但如果不给它明确的身份、边界、任务契约它就只会变成一台“极其听话的废话生成器”。这篇文章我会从设计逻辑、核心机制、完整实操、真实使用感想、常见坑几个角度把这件事拆开讲清楚。无论你是只用过几天 Claude Code 的新手还是整天跟 Agent 打交道的重度用户都可以在中间找到对你有用的东西。1. 这个项目到底在解决什么问题1.1 一句话理解“66 个专家”先别急着脑补科幻电影。这个开源项目做的事情其实特别朴素它准备了一堆精心编写的角色能力文件每个文件都对应一个专职岗位的“人设”。“人设”不是让你更多像聊天伙伴而是把 AI 的行为边界、思维方式、输出格式、说话口吻全部固化下来让它在不同任务中自动切换状态。你可以把它理解成同一台服务器上跑着 66 个不同的虚拟桌面每个桌面里打开着不同岗位的开工手册。你要做“算法选型”就进算法专家的桌面你要写“政务材料”就切到公文教练的桌面你甚至还可以让“数据库索引专家”和“性能监控专家”在同一个会话里轮流发言像两个顾问轮流给你建议一样。我在一开始也以为这不就是“一堆角色扮演提示词”吗后来实际用起来才发现它真正狠的地方在于“分工”和“约束”。同一个 Claude Code如果没有任何专家角色它遇到“帮我做个库存模块”时会非常均匀地平铺展开需求讨论、表结构、接口、页面、测试什么都没漏但什么都做得大而空。一旦用上了“后端专家数据库专家”这样的角色组合AI 会在第一轮就主动向你确认分页策略和库存扣减并发问题输出的质量完全不是同一个量级。1.2 为什么这个痛点普遍存在很多人现在用 Claude Code工位还停留在“开一个终端敲一句 prompt看输出”。这种方式不是不能用但有一个天然缺陷没有任何一个通用模型能在每一次回答中都自动采用“资深架构师视角”或“资深编辑视角”。因为通用 AI 的关键机制之一就是“顺着概率往下接”。你问它“这段代码怎么写”它会自动倒向“最普通、最常见、最不易出错”的那种写法。这种写法对简单任务没问题但对复杂问题就是灾难。举个生活中的例子。一个刚进后厨的新手和一个干了十几年的老师傅如果用同一份菜谱做同一道菜味道差异一定很大。差别不在“知道多少步骤”而在老师傅对每步的判断标准、对火候的敏感度、对突发状况的预案。这些判断标准没法直接写进一份简单的菜谱里只能通过“这个师傅做菜时脑子里转的那套东西”来体现。开源项目的专家角色干的就是这件事把“老师傅脑子里转的那套东西”提前写进 Claude Code。1.3 合适的人群与使用场景根据我这段时间的观察这类“专家矩阵”式玩法最适合下面三类人正在用编码助手做真实项目的开发者而不是偶尔写段脚本的体验者。需要让 AI 频繁处理不同领域任务的自由职业者、独立开发者、小团队。对提示词略有基础但已经受够“模板式回答”想让 AI 输出更接近专业交付物的人。如果你是那种直接把需求粘贴进去、只要最终能跑就行的人那这套方案前期会把你的配置复杂度拉高不少可能不划算。但一旦你的产品处于真实业务里、需要跟质量、成本、风格、交付标准打交道它就值回票价。2. 设计思路解析为什么是“角色工程”而不是“提示词工程”2.1 单个万能提示词的极限在哪里我见过不少开发者试图写一个“包打天下”的超级提示词比如“你是一名顶级全栈工程师、架构师、产品经理、运维专家、设计师、测试工程师……请根据我的需求给出最佳方案。”这句话看起来什么都说了实际效果却非常差。因为模型在接收这种指令时会同时激活大量互相重叠的行为模板最后输出结果大概率是“每条线都擦了边每条线都不够深”。而且这些模板之间还会打架你既要求它“给出完整代码”又要求它“先讲设计理念”矛盾之下模型只能选择最中庸的路线——先简单说几句理念再甩一段平平无奇能跑的代码。这种“全能式提示词”的失效本质上是因为缺少“场景开关”。你把 6 种角色的指令焊死在同一个上下文里模型只能在“混合状态下”做平均化输出。角色工程的核心则是把这些指令拆开、分成独立的场景包并在需要时只加载其中一个。2.2 66 个角色不是随意堆的而是一套专业分工体系我拉出这个项目的角色目录清单看了很久发现它的分类明显是按照“成熟技术团队的组织架构”去设计的。领域类角色前端性能专家、后端架构师、数据库优化师、安全审核员、DevOps 工程师、算法工程师。流程类角色需求分析员、任务拆解师、代码审查专家、测试设计专家、发布经理。通用软技能类角色文档写作者、沟通教练、复盘顾问、汇报整理师、反方辩手。行业垂直角色比如面向电商、内容平台、教育、金融等细分领域的专家。这种组织结构带来的好处是当你面对一个复杂任务时可以像“组一个虚拟项目组”那样挑选角色而不是指望 AI 一个人懂所有事。比如说你今天要完成一次“登录模块的安全改造”。你可以先调“安全审计员”做风险静态检查再叫“后端架构师”评估整体改动方案接着让“代码审查专家”对实际操作做逐行把关最后由“文档写作者”输出一份给团队看的改造说明。整个过程下来同一套 Claude Code 底座却体验到了四个人接力做事的节奏。2.3 专家之间的协作与冲突解决有人会问既然有这么多角色我是把它们全部加到同一个会话里一起做吗这个项目给出的思路很聪明不要让所有专家同时上台而是让它们“按需出场、轮流发言”同时在系统的全局配置里设计了一套极其关键的“冲突裁决规则”。具体做法是角色文件里不仅写“你擅长什么”还会写“你什么时候应该闭嘴”。比如一个“风险控制专家”被要求当开发专家说“方案可行”时你必须站出来指出三个潜在失败场景但你又不能为了反对而反对必须给出可量化的依据。这就解决了多数人做多角色 prompt 时的最大难题角色之间互相抢话或者一团和气。这种思路本质上是在模拟真实工作场景中的“不同岗位协作必须遵守的秩序”。真实团队里不会让研发、财务、法务、客服同一时间抢一个麦克风而是每次就一个目标让相应角色发言其他角色只做被动参考。项目的核心价值之一就是把这种秩序固化到了配置里。3. 核心机制解析这些“专家”到底是如何装进 Claude Code 的3.1 角色定义的载体Markdown、JSON 与配置目录从项目结构上看它的每一个“专家”都不是一堆散兵游勇的文字而是有着清晰结构的角色定义文件。我见过的大多数同类工具都会用 Markdown 描述角色人设再用一份 JSON/YAML 来挂载角色的触发规则、适用场景、禁用语。具体参考结构大致如下# 角色: 前端性能专家 # # 适用场景: 页面加载速度优化、性能预算、关键渲染路径分析 # 触发词: frontend, performance, LCP, bundle size # 专长: 网络请求优化、渲染性能、构建产物分析 你是一名专注前端性能的前端性能专家。 行为准则 - 先搞清楚用户的核心性能指标而不是直接做优化 - 分析瓶颈时优先考虑网络链路和渲染链路 - 每次修改都必须给出 Before/After 的预期量化结果 - 不要直接抛出大段重构代码先说明改动思路再动手 默认输出格式 1. 问题判断 2. 影响因素分析 3. 可执行方案 4. 风险提示这种结构最关键的一点是把“人设”和“行为契约”分开。人设负责让模型进入状态行为契约负责让模型的输出收敛到可用的范围内。很多自己写的“角色提示词”只堆砌了人设没有行为契约结果就是 AI 沉浸式扮演一个专家却依然输出一堆正确的废话。3.2 动态加载方案66 个专家如何避免上下文爆炸你可能已经想到如果一个专家定义文件动辄几百字66 个全扔进上下文那 Claude Code 就算有再大的窗口也不够用。这个项目解决方式很简单也很有启发性不在启动阶段加载全部角色而是在需要时按需注入。项目中通常有一个调度器或者选择器脚本它会根据用户的输入关键词自动挑出 1 到 3 个最相关的角色定义再把这些定义补到当前会话的指令前缀里。这里面的匹配逻辑也很讲究不是简单做关键词命中而是综合了“语义相似度 场景规则”。比如用户输入“帮我优化一下这个 MySQL 查询最近越来越慢了”选择器可能同时激活“数据库优化师”“后端性能分析师”两个角色而不会把“UI 设计师”拉出来。一个特别值得学习的设计细节是选择器本身也被定义成“角色”。也就是说它是 66 个专家之外的“第 67 个角色”职责不是回答问题而是判断该叫谁上台。我后来自己复刻项目时发现只要把这个调度角色写清楚整体的可用性会翻一倍。3.3 与 Claude Code 的集成点斜杠命令、钩子、记忆文件从实操层面讲这些专家角色可以通过 Claude Code 的自定义命令机制来实现。斜杠命令把每个专家定义放到指定命令目录下比如/expert命令输入/expert security-audit就加载安全审计员角色。钩子通过特定事件触发角色比如在 Git 提交前自动调用“代码审查专家”检查 diff。记忆文件在全局记忆文件如 CLAUDE.md里声明“专家目录的位置”和“默认调度规则”让 Claude Code 随时知道哪些角色可用。我最常用的是斜杠命令方式因为它足够直观且不会污染全局上下文。你不需要让所有专家常驻脑子里只需要在要做某类任务时用一条命令把对应专家“指名道姓”地喊进来。举个例子我创建一个review专家后会在代码提交前执行claude -p 审查当前 git diff --expert review这个命令会触发一个高度结构化的代码审查过程AI 先读取 diff再按照代码审查专家的人设逐项检查最后输出一份包含问题等级、风险原因、修改建议的审查报告。4. 实操记录在本地复现一套“专家矩阵”4.1 准备基础环境与获取项目先把前提条件列清楚。你本机需要装好 Node.js 以及 Claude Code 或对应运行环境同时拿到一个可用的 API 密钥。整个过程在 macOS 和 Linux 上跑起来基本顺畅Windows 下如果配合 Git Bash 或 WSL 也没太大问题。克隆项目到本地项目会提供一个角色目录里面可能已经内置了几十个 Markdown 专家模板。安装依赖多数这类项目只依赖少数几个脚本不会有重量级依赖装起来很快。检查配置入口看项目中是否包含配置文件、启动脚本或调度器说明。我第一次跑的时候只改了配置文件的路径五分钟就启动了第一个专家角色。如果你在运行阶段看到类似“找不到自定义命令目录”的报错不用慌基本就是环境变量或目录权限的问题后面排查章节会专门说。4.2 创造属于自己的角色文件这个项目最有价值的地方不是那 66 个专家本身而是它定义角色文件的方式。我强烈建议你先复制一两个模板改成自己的别直接拿着预置角色硬上。下面是我自己为一个“Node.js 后端重构专家”写的角色文件# 角色: Node.js 后端重构专家 # # 适用场景: 旧代码重构、模块拆分、去耦合、技术债治理 # 触发词: refactor, nodejs, legacy, module split 背景: 你是一名专注 Node.js 后端重构的架构师参与过大量老项目的模块化拆分 你熟悉从“能跑”到“好维护”之间需要走完的关键路径。 任务行为: - 第一轮先回答“这个模块当前的核心职责是什么”而不是急着给重构代码 - 把重构理由拆成“可维护性 / 性能 / 可测试性”三个维度讲 - 严格限制每次重构的影响范围不做跨模块的连带改动 - 改完代码后必须给出可执行的测试验收点 禁止事项: - 不要一次性输出大段完整代码要分步骤交付 - 不要为了“更优雅”引入不必要的新依赖 - 不要忽略对现有外部接口的兼容性影响 输出结构: - 现状诊断 - 重构边界 - 分步实施计划 - 风险清单 - 验收测试点写完这个文件后把它放进命令目录。然后在 Claude Code 里执行启用命令角色就能被识别。我发现一个值得分享的经验角色文件里写得越具体效果越好。特别是“禁止事项”这段它能明显压制 AI 自动生成“大而全但无法落地”回答的冲动。4.3 用一次代码审查任务验证效果我建议你不要一上来就拿自己的核心项目做实验先用一个小仓库跑通流程。这里是我做的验证过程准备一个 Git 仓库里面有几处明显的坏味道比如长函数、魔法数、重复的三层循环。调用默认 Claude Code 模式问“看看这个仓库有哪些问题”。再调用/expert code-review问同样的问题。对比两份回答的深度和行动力。我的真实感受是普通模式下AI 的回答像“礼貌的代码朋友”指出问题也给出建议但语气和判重都像在做“通用检查”。专家模式下的回答则像“一个有点操心的技术主管”它会按严重程度排序会把每个问题关联到具体业务风险最后甚至提醒我“先不要动 xx 文件因为它在别处被引用了”。这个差别不是模型本身能力变了而是角色定义里的行为契约把回答逼到了另一个方向。4.4 从单角色到多角色的接力协作如果说单专家只是开胃菜那多专家协作才是这套玩意的正餐。我在做一次“服务拆分方案”时实际跑了一个三专家接力流程claude -p 分析当前订单服务的拆分边界 --expert domain-mapper claude -p 评估拆分后的事务一致性问题 --expert transaction-specialist claude -p 给出6个月的平滑迁移计划 --expert release-planner关键技巧是每次调用都以上一次的输出作为输入上下文。也就是说domain-mapper 先输出一个初步方案我把它作为内容片段传给 transaction-specialist 继续挑毛病最后再交给 release-planner 做计划。整个过程约等于一个流水线提出问题 - 领域建模 - 风险评估 - 落地计划。这种接力模式上来会让人适应不了因为每一步都要人为传递上下文。但它有个巨大优势每个专家都只负责一个小环节它的上下文窗口里塞满了高度相关的领域知识不会因为同时兼顾多个目标而稀释质量。5. 实际使用三周后我的效果观察5.1 质量提升最明显的几个场景用了差不多三周后我总结了几个效果特别显著的场景第一是代码审查。有了固定的审查角色后每次提交前检查出来的问题从“语法/规范类”提升到了“并发风险/边界条件/隐式耦合”这个层级。过去靠人工审查才能捕捉到的深水区问题现在 AI 会主动列出来虽然不能完全替代人工但它帮我节省了大量“扫描代码”的时间。第二是需求拆解。每天面对大量模糊需求时我会用“需求分析员”先做一轮任务拆解。它会强制我把一个含糊的表述拆成“业务目标、约束条件、验收标准、非目标”四个部分。自从用了这个流程我在和同事确认需求时几乎没有再出现过“聊到最后发现两边理解完全不一样”的情况。第三是文档输出。给专家角色绑定一套格式契约之后它产出的文档稳定在许多技术人员都很少有的“报告风格”里段落间有逻辑递进每节末尾有“这句的关键假设是什么”完全不像 AI 默认的百科式写作。5.2 成本与时间账值不值我当然也关注 token 消耗。实测下来使用专家角色后单轮的 token 消耗通常会增加 20%~40%。原因很简单角色定义文件本身会占用上下文且专家输出往往更长、更结构化。但总时间成本反而是下降的。为什么因为普通模式生成结果后通常还需要我再写一轮甚至两轮追问来“校准方向”。比如我让它写接口文档第一版写得规整但完全不符合团队要求的模块命名就得再来一轮纠正。而专家模式因为提前写清了“禁止事项”和“输出结构”第一版往往就能直接用返工率大幅下降。如果你是在真实项目里用这个成本结构是相当划算的。如果你只是随手做点小实验那多出来的 token 可能会让你觉得不值这是很多人在初期配置后容易产生“怀疑人生”情绪的主要原因。5.3 它并不是万能钥匙边界也很明显必须说点反面的。专家角色没办法让 AI 突然拥有它本不具备的知识。如果你的角色定义里写“你是资深 Rust 编译器专家熟悉内联汇编优化”但模型本身对这方面的知识储备很浅那它就是扮演得再像给出来的建议也可能是不准确甚至危险的。还有一类问题是“过度形式化”。当任务明明很简单时专家角色依然会按固定格式输出“五段法”让简单问题显得异常臃肿。我现在遇到非常小的需求会直接切回普通模式避免专家角色产生杀鸡用牛刀的效果。另一个边界是专家矩阵对单一任务的串行处理很在行但面对那种“需要通盘综合考虑”的全局性任务反而吃亏。如果交给它一个整体架构设计任务它会因为过度强调职责边界而丧失全局平衡感。这种湿度判断恰恰是使用者要保留的最重要能力。6. 常见问题与排查技巧速查6.1 角色没有生效 / 回答没有任何变化这是刚配置时最容易遇到的问题。通常原因不是角色文件没写好而是调用时没有正确加载。排查顺序确认命令目录路径和 Claude Code 配置指向的是同一个目录。确认角色文件名后缀是否匹配一般是.md。直接在斜杠命令里输入角色名看看是否报“未找到”。查看系统全局记忆文件确认它是否包含了要激活的角色的索引。我踩过最大的坑把角色文件塞到了普通目录里结果 Claude Code 根本没扫描到。后来统一把角色文件放进命令规范目录后问题立刻消失。6.2 专家之间的意见冲突多专家协作时意见冲突几乎是必然的。安全专家说不能这么改性能专家说必须这么改。这时最忌讳的就是两个角色同时进入辩论模式。我的处理方式是在供给两个专家的最终 prompt 中预留一个“仲裁规则”比如明确写“冲突发生时优先遵循安全约束如果安全性没有差异再考虑性能优化”。你会发现只要你在对话开场就定义了优先级专家们的表现会非常收敛不会再像吵架一样。6.3 上下文不够用专家多了反而“变笨”这是最难缠的问题。你连续切换多个专家后之前的对话内容会一直留在上下文里专业角色越多AI 越容易表现出“遗忘”或“回答平庸”。解决办法有三个在切换专家时手动清理无用的历史对话或开启精简上下文模式。每个专家只处理一小段高聚合度的输入不要把大量碎片喂进去。把专家定义做成“按需注入”而不是“一开始就全量挂载”。我自己的习惯是把每个专家的“核心指令”压到 200 字以内把“行为契约”留在角色文件里这样真正进入上下文的部分不会太多。6.4 角色提示词被全局记忆文件覆盖还有一个隐蔽问题如果你在全局记忆文件里写了大量强调“你是 Claude、你是通用助手”的内容它可能会覆盖专家角色的设定。全局记忆的优先级如果高于角色文件专家味就会被冲淡。遇到这个情况要么把全局记忆里的相关指令移除要么在角色文件里显式声明“这里是专家模式请忽略全局记忆中的通用助手指令”。这两种方法我都试过显式声明通常更稳定因为它不需要你本地同时修改全局文件。最后再分享一个最近的实际体会配置 66 个专家只是入口真正的分水岭是你愿不愿意为不同任务设计不同契约。我反复折腾这套项目之后最大的收获不是某个专家角色多好用而是我彻底放弃了“一句话让 AI 变成高手”的幻想。会用 AI 的人从来不是会写华丽指令的人而是懂得给 AI 找对位置、画清边界、定好验收标准的人。如果你准备开始玩这套“专家矩阵”也请一定从自己最痛的那个场景下手。先建一个角色用一周再迭代它。等你发现 AI 开始主动追问“这个需求的一致性约束是什么”时你就理解为什么说“66 个专家本质上是一场针对 AI 工作方式的精密组织工程”了。