企业官网建设流程全解析

上周我在折腾 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 工作方式的精密组织工程”了。