企业官网建设流程全解析

1. 为什么你的 Claude Code 需要一个“专属助手团队”

如果你已经在用 Claude Code 写代码，大概率经历过这样的场景：主对话里刚聊完架构设计，转头让它审查一段代码，它却把前面几百行的上下文一起“背”着走，响应变慢、token 飙升，审查结果还容易被无关信息带偏。更麻烦的是，团队里每个人对“代码审查”的标准都不一样，今天让它查安全，明天让它查命名，每次都要重新粘贴一大段提示词。

Claude Skills 和 SubAgent 就是来解决这两个问题的。Skills 是把重复的指令、检查清单、操作流程封装成可复用的“技能包”，需要时按需加载；SubAgent 则是把特定任务委派给拥有独立上下文的“专家助手”，主会话保持干净，子代理专注干活。两者组合起来，你就能从“每次手动指挥一个通用 AI”，升级成“管理一支各司其职的 AI 开发团队”。

这篇内容面向希望构建专属 AI 开发助手的开发者，会交付可复制的 Skills 目录结构、SubAgent 定义文件和 settings.json 骨架，并给出通过 TaoToken 统一 Key/API 通道接入的验证步骤。目标很明确：从零跑通一个可扩展的助手工作流，让你看完就能动手搭起来。

2. 前置准备：用 TaoToken 统一 Key 与 API 通道

在配置 Skills 和 SubAgent 之前，先把模型接入通道理顺。Claude Code 本身支持多种模型，但如果你想让主会话、子代理、技能脚本都走同一个 Key，避免到处散落配置，用 TaoToken 做统一入口会省很多事。

TaoToken 提供兼容的 API 通道，你只需要一个 Key，就能在 Claude Code 的 settings.json 里统一配置模型访问。官网地址是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 端点是 https://taotoken.net/api （注意这个不加 UTM 参数）。

操作路径很简单：先到控制台创建 API Key，然后把它写进 Claude Code 的配置文件。如果你还没创建 Key，可以走这个 deep link 直达：https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite 。创建完成后，Key 的管理页面在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite ，后续轮换或新增都从这里进。

注意：Key 只存在本地配置文件或环境变量里，不要提交到 Git 仓库。团队共享时用环境变量注入，别把明文 Key 写进项目级 settings.json。

接入文档可以参考 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，里面有完整的参数说明和示例。配置好之后，Claude Code 的主会话、SubAgent、Skill 脚本就都能复用同一个通道，不用每个地方单独填一遍。

3. 可复制配置：Skills 目录结构与 SKILL.md 骨架

Skills 的核心是“按需加载”：启动时只读技能名称和描述，任务匹配时才加载完整指令。所以目录结构要清晰，SKILL.md 要写好触发描述。

个人级 Skill 放在~/.claude/skills/下，项目级 Skill 放在<项目根目录>/.claude/skills/下。每个技能一个独立目录，目录名就是技能名，里面放一个SKILL.md。结构如下：

~/.claude/skills/ └── code-review/ ├── SKILL.md └── scripts/ └── check.sh

项目级同理：

<项目根目录>/.claude/skills/ └── api-doc-gen/ └── SKILL.md

SKILL.md的骨架可以这样写，重点是开头的描述要能让 Claude 判断“什么时候该用这个技能”：

--- name: code-review description: 当用户要求审查代码、检查代码质量、查找潜在 bug 或安全问题时使用。适用于 Python、JavaScript、Go 等语言。 --- # 代码审查技能 ## 执行步骤 1. 读取用户指定的文件或目录 2. 按以下清单逐项检查： - 命名规范：变量、函数、类名是否清晰一致 - 错误处理：是否有未捕获的异常、边界条件遗漏 - 安全隐患：硬编码密钥、SQL 注入、路径穿越 - 性能问题：不必要的循环嵌套、重复计算 3. 输出格式：按严重程度分级（高/中/低），每条给出文件行号和修改建议 ## 参数 - `$ARGUMENTS`：要审查的文件路径或目录 - `$1`：语言类型（可选，默认自动识别）

这里$ARGUMENTS和$1、$2是占位符，调用技能时传入的参数会替换进去。比如你输入/code-review src/main.py python，$1就是python。

项目级 Skill 和用户级 Skill 可以同名，Claude 会根据描述让你选择用哪一个。实测下来，把团队规范写进项目级 Skill，新人拉下代码就能用同一套审查标准，比口头传达靠谱得多。

4. 可复制配置：SubAgent 定义文件与 settings.json 骨架

SubAgent 的定义文件是 Markdown 格式，放在.claude/agents/目录下。项目级放<项目根目录>/.claude/agents/，用户级放~/.claude/agents/。每个子代理一个.md文件，文件名就是代理名。

一个只读代码审查子代理的定义骨架：

--- name: code-reviewer description: 只读代码审查专家。当需要审查代码质量、安全漏洞、性能问题时使用。不能修改文件。 model: claude-sonnet-4-6 tools: - Read - Glob - Grep --- # 代码审查专家 你是一名资深代码审查员，只读不写。你的职责是： 1. 读取指定文件，逐行分析 2. 按高/中/低三级输出问题，每条包含文件路径、行号、问题描述、修复建议 3. 重点关注：安全漏洞、错误处理、边界条件、命名规范、重复代码 ## 约束 - 禁止使用 Edit、Write 工具 - 禁止执行任何 shell 命令 - 输出必须结构化，便于直接贴进 PR 评论

关键参数说明：

settings.json骨架用来统一模型通道和权限。项目级放在.claude/settings.json，用户级放在~/.claude/settings.json：

{ "model": "claude-sonnet-4-6", "apiKey": "${TAOTOKEN_API_KEY}", "baseUrl": "https://taotoken.net/api", "permissions": { "allow": ["Read", "Glob", "Grep"], "deny": ["Bash(rm -rf)"] }, "agents": { "code-reviewer": { "model": "claude-sonnet-4-6" }, "test-writer": { "model": "claude-haiku-4-5" } } }

这里apiKey用环境变量${TAOTOKEN_API_KEY}注入，避免明文。baseUrl指向 TaoToken 的 API 端点。agents字段可以给不同子代理分配不同模型：审查用 Sonnet 保证质量，测试生成用 Haiku 控制成本。

创建好之后，在项目里重启 Claude Code，输入/agents就能看到注册的子代理列表。如果没显示，检查文件是否放在正确目录、YAML 头格式是否正确。

5. 验证请求：从零跑通一个可扩展工作流

配置写好了，得验证它真的能跑。按下面步骤走一遍，确认 Skills 和 SubAgent 都正常工作。

第一步，确认模型通道。在 Claude Code 里输入/model，看当前使用的模型是否走了你配置的通道。如果显示的是你 settings.json 里指定的模型，说明 TaoToken 接入生效了。想单独验证模型对话，可以走这个链接快速测试：https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model-chat&utm_campaign=rewrite 。

第二步，验证 Skill 加载。输入/skills命令，应该能看到你创建的技能列表。个人级和项目级的技能都会列出来，同名时会标注来源。如果某个技能没出现，检查SKILL.md的 YAML 头是否有name和description。

第三步，调用 Skill。输入/code-review src/main.py，观察 Claude 是否加载了对应的技能指令，并按你定义的清单输出审查结果。成功的话，你会看到分级的问题列表，而不是泛泛的“代码看起来不错”。

第四步，验证 SubAgent。在对话里说“用 code-reviewer 审查 src/main.py”，主代理应该会委派给子代理执行。子代理在独立上下文里跑完，把结构化结果返回主会话。你可以对比一下：直接让主会话审查，和委派给子代理审查，后者的输出更聚焦、格式更统一。

第五步，验证并行。同时委派两个子代理，比如一个审查代码、一个生成测试，观察它们是否并行执行、互不干扰。这一步跑通，说明你的助手工作流已经具备扩展能力。

如果你打算长期用这套工作流做编码和 Agent 任务，可以考虑 Coding Plan，入口在 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite ，适合需要稳定通道和批量调用的场景。

6. 本篇常见错排查

配置过程中最容易踩的几个坑，这里集中说一下。

Skill 不触发：最常见的原因是description写得太模糊。Claude 靠描述判断是否加载技能，如果只写“代码审查”，它可能匹配不到具体场景。改成“当用户要求审查代码、检查质量、查找 bug 时使用”，触发率会明显提升。

SubAgent 不显示：先检查目录。项目级必须是<项目根目录>/.claude/agents/，用户级是~/.claude/agents/，少一层或多一层都不行。再检查文件扩展名，必须是.md，YAML 头用---包裹，name和description不能少。

模型调用报错：如果提示认证失败，检查settings.json里的apiKey环境变量是否真的注入了。可以在终端echo $TAOTOKEN_API_KEY确认。baseUrl要写https://taotoken.net/api，不要多加路径或斜杠。

子代理权限过宽：审查类子代理如果给了Edit权限，它可能会直接改代码，违背“只读审查”的初衷。在tools列表里只保留Read、Glob、Grep，把写操作挡在外面。

并行任务互相污染：如果两个子代理同时写同一个文件，会出现冲突。设计工作流时，让写操作集中在主会话或单一子代理，其他子代理只读。需要并行写时，分配不同的输出目录。

Skill 脚本执行失败：SKILL.md里引用的脚本路径要用相对路径，并且确保有执行权限。在 Linux/macOS 下chmod +x scripts/check.sh，Windows 下注意换行符和路径分隔符差异。

排查完这些，你的 Skills 和 SubAgent 基本就能稳定运行了。接下来就是按团队需求不断往里加技能、加专家，让这套助手工作流越长越壮。