企业官网建设流程全解析

1. 从两个真实痛点说起：为什么需要 Slash commands 和 Subagents

如果你已经在用 Anthropic 的 Claude Code 做日常开发，大概率遇到过这两种情况：一是某个提示词你反复手敲，比如「帮我审查这段代码的安全问题」「把这份 Markdown 整理成规范格式」，每次都要重新组织语言，效率很低；二是你让 Claude 做一件复杂的事，比如「审查整个模块并给出补丁」，结果主会话上下文被大量代码细节塞满，后面再聊别的它就开始「失忆」。

这两个痛点对应的正是 Anthropic 在 Claude Code 里提供的两大工具：Slash commands（斜线命令）和Subagents（子代理）。前者解决「单步、高频、可模板化」的操作复用问题，后者解决「独立上下文、专有权限、复杂角色」的封装问题。简单说，Slash commands 是给主会话加「快捷键」，Subagents 是给主会话配「专职助手」。

这篇内容聚焦落地配置：从settings.json/config.toml骨架入手，接入 TaoToken 统一 Key/API 通道，给出可复制的命令定义与子代理配置片段，并设计一次可复现的调用验证动作。适合已经装好 Claude Code、想进一步把工作流规范化的开发者。如果你还没配好 API 通道，下面会先讲清楚怎么用 TaoToken 把 Key 统一管起来，再进入命令和子代理的配置。

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

在配置 Slash commands 和 Subagents 之前，先把模型调用通道理顺。Claude Code 默认走 Anthropic 官方接口，但很多人在多项目、多工具之间切换时，Key 管理很乱。TaoToken 提供统一的 API 通道，把 Key 集中管理，Claude Code、Coding Plan、模型对话等场景可以共用一套凭证。

2.1 获取 API Key

打开 TaoToken 控制台，进入 API Keys 页面创建一个新 Key。建议按用途命名，比如claude-code-dev，方便后续排查是哪个项目在用。创建后复制 Key，注意它只显示一次。

2.2 配置环境变量

Claude Code 读取的是环境变量，最直接的方式是在 shell 配置文件里写死，或者用.env文件配合启动脚本。以 macOS/Linux 的~/.zshrc为例：

# TaoToken 统一 API 通道 export ANTHROPIC_BASE_URL="https://taotoken.net/api" export ANTHROPIC_API_KEY="sk-你的TaoToken密钥"

Windows PowerShell 用户可以在$PROFILE里加：

$env:ANTHROPIC_BASE_URL = "https://taotoken.net/api" $env:ANTHROPIC_API_KEY = "sk-你的TaoToken密钥"

改完记得source ~/.zshrc或重开终端。验证环境变量是否生效：

echo $ANTHROPIC_BASE_URL # 应输出 https://taotoken.net/api

注意：ANTHROPIC_BASE_URL末尾不要带斜杠，否则部分客户端会拼出双斜杠导致 404。这是我自己踩过的坑，排查了半小时才发现。

2.3 settings.json 骨架

Claude Code 的项目级配置放在.claude/settings.json，用户级放在~/.claude/settings.json。项目级优先。一个最小骨架如下：

{ "model": "claude-sonnet-4-20250514", "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-你的TaoToken密钥" }, "permissions": { "allow": ["Read", "Bash(git:*)"], "deny": ["Bash(rm -rf:*)"] } }

这里env字段可以在项目内覆盖全局环境变量，适合团队协作时统一通道。permissions控制工具权限，后面配置 Subagent 时会用到类似的粒度。

2.4 config.toml 骨架（可选）

如果你用的是支持 TOML 配置的客户端或自建脚本，可以这样写：

[api] base_url = "https://taotoken.net/api" api_key = "sk-你的TaoToken密钥" model = "claude-sonnet-4-20250514" [permissions] allow = ["Read", "Bash(git:*)"] deny = ["Bash(rm -rf:*)"]

两种格式选一种即可，关键是base_url和api_key指向 TaoToken。配置完成后，先跑一次最简单的对话验证通道是否通：

claude -p "回复 OK 两个字母即可"

如果返回OK，说明 Key 和通道没问题，可以进入下一步。

3. Slash commands 配置：把高频提示词变成快捷命令

Slash commands 的本质是 Markdown 文件，放在.claude/commands/（项目级）或~/.claude/commands/（用户级）。文件名就是命令名，比如optimize-markdown.md对应/optimize-markdown。

3.1 命令文件结构

一个完整的命令文件包含 YAML frontmatter 和正文模板：

--- name: "optimize-markdown" description: "优化 Markdown 文档，整理结构、简化语言、修复格式问题" argument-hint: "粘贴 Markdown 内容或使用 @file 引用，例如 @README.md" allowed-tools: - "Read" - "Write" model: "claude-sonnet-4-20250514" --- 请作为专业文档编辑者，处理下列 Markdown 内容： 1. 保留所有关键信息点。 2. 优化章节标题层级。 3. 简化冗长句子，改进段落衔接。 4. 修复列表缩进、代码块标记、表格对齐等格式问题。 5. 文末附「改动与建议」小节，列出主要修改项（不超过 3 条）。 输入来源： - 若用户粘贴内容，直接处理。 - 支持文件引用：@file（例如 @README.md）。 输出：仅返回优化后的完整 Markdown，顶部加一行注释说明由 /optimize-markdown 生成。

frontmatter 里几个字段值得说明：allowed-tools限制这个命令能调用哪些工具，argument-hint会在输入/时提示参数格式，model可以给特定命令指定不同模型。正文部分就是提示词模板，支持$ARGUMENTS占位符接收参数。

3.2 带参数的命令示例

比如一个修复 issue 的命令.claude/commands/fix-issue.md：

--- name: "fix-issue" description: "根据 issue 编号定位问题并给出修复方案" argument-hint: "issue 编号，例如 /fix-issue 123" allowed-tools: - "Read" - "Bash(git:*)" --- 请处理 issue #$ARGUMENTS： 1. 用 git log 查找相关提交历史。 2. 阅读涉及的文件，定位问题根因。 3. 给出最小修复方案，附 diff 格式补丁。 4. 说明验证步骤。

调用时输入/fix-issue 123，$ARGUMENTS会被替换成123。

3.3 命令的作用域与优先级

项目级.claude/commands/优先于用户级~/.claude/commands/。同名命令项目级覆盖用户级。在/help列表里会标注来源是 project 还是 user。团队协作时把通用命令放项目级，个人习惯放用户级。

4. Subagents 配置：封装独立上下文的专职助手

Subagents 解决的是「主会话上下文被污染」的问题。每个子代理有独立的上下文窗口，主会话只拿到最终结果，中间过程不占用主会话的 token。

4.1 子代理文件结构

子代理文件放在.claude/agents/（项目级）或~/.claude/agents/（用户级），同样是 Markdown + YAML frontmatter：

--- name: "code-reviewer" description: "专注代码质量审查：样式、性能、安全、可读性、测试覆盖" model: "claude-sonnet-4-20250514" tools: - "Read" - "Bash(git:*)" - "Bash(python:*)" --- 你是一个专注代码审查的子代理，名为 Code Reviewer。职责： 1. 优先检查功能正确性与潜在错误（边界条件、异常处理、资源泄漏）。 2. 提出可执行的改进建议，适当处给出最小可行补丁。 3. 报告安全问题与潜在漏洞（注入、命令执行、不安全依赖）。 4. 检查代码风格一致性，必要时给出重构建议，但不做大规模重写。 5. 对每条建议评估影响级别（低/中/高）并列出验证步骤。 行为约束： - 修改建议需带上下文行（至少 2 行），注明文件路径与行号范围。 - 补丁使用统一 diff 格式，简短可直接应用。 - 运行测试或 git 操作前先报告命令，征得同意。

frontmatter 里tools字段控制子代理能用的工具集。省略则继承主线程所有工具，建议显式列出以限制权限。

4.2 子代理的调用方式

两种调用方式：显式调用和自动委派。显式调用在会话里说「请使用 code-reviewer 子代理审查 src/utils/parser.py」，Claude 会启动子代理并把结果返回主会话。自动委派则是 Claude 根据任务描述自行判断是否匹配某个子代理的description。

也可以用/agents交互界面创建、管理、选择子代理，适合不熟悉文件编辑的用户。

4.3 权限粒度对比

选择原则：单步、频繁、可模板化用 Slash commands；需要独立上下文、专有权限、复杂行为用 Subagents。

5. 验证请求：一次可复现的调用验证

配置写完不代表生效，需要设计一次可复现的验证动作。下面这套流程可以同时验证 Slash command 和 Subagent 是否被正确加载。

5.1 验证 Slash command

在项目根目录创建.claude/commands/hello-check.md：

--- name: "hello-check" description: "验证 Slash command 是否生效" --- 请回复：SLASH_COMMAND_OK，并说明当前使用的模型名称。

启动 Claude Code，输入/hello-check。如果返回包含SLASH_COMMAND_OK，说明命令被正确加载。如果/hello-check不在补全列表里，检查文件路径和 frontmatter 格式。

5.2 验证 Subagent

创建.claude/agents/verify-agent.md：

--- name: "verify-agent" description: "验证 Subagent 是否生效，返回固定标记" tools: - "Read" --- 请回复：SUBAGENT_OK，并列出你可用的工具名称。

在会话里输入「请使用 verify-agent 子代理执行验证」。如果返回SUBAGENT_OK且工具列表只有 Read，说明子代理的独立上下文和权限限制都生效了。

5.3 验证 API 通道

用一条命令同时验证通道和模型：

claude -p "用一句话说明当前 API 通道是否正常，并输出模型名"

如果返回正常且模型名与你配置的一致，说明 TaoToken 通道、Key、模型三者都通了。这一步建议在配置完 settings.json 后立刻做，避免后面排查时混淆是通道问题还是命令配置问题。

6. 本篇常见错排查

配置过程中最容易卡在几个地方，这里集中列一下。

命令不生效：先确认文件扩展名是.md，frontmatter 用---包裹且格式正确。YAML 对缩进敏感，allowed-tools下的列表项要统一缩进。再确认路径是.claude/commands/而不是.claude/command/（少个 s 是常见笔误）。

子代理不触发：description字段要写清楚适用场景，Claude 靠它判断是否委派。如果 description 太模糊，自动委派不会命中。显式调用时用「请使用 xxx 子代理」的句式，比「用 xxx」更稳。

API 返回 401：检查ANTHROPIC_API_KEY是否有多余空格或换行。用echo $ANTHROPIC_API_KEY | wc -c看长度是否合理。如果 Key 是从网页复制的，注意别把前后空白带进去。

API 返回 404：大概率是ANTHROPIC_BASE_URL末尾多了斜杠，或者路径写成了/v1。TaoToken 的 base url 就是https://taotoken.net/api，不要自己加后缀。

模型名报错：不同客户端对模型名的要求不同，有的要完整版本号，有的接受别名。先用claude -p "test"确认默认模型能通，再在 frontmatter 里指定具体模型。

权限被拒：Subagent 的tools字段如果限制了工具，子代理执行时调不到对应工具会报权限错误。排查时先把 tools 去掉，确认功能正常后再逐步收紧。

上下文没隔离：如果发现子代理的中间过程出现在主会话里，检查是不是把子代理当普通命令用了。Subagent 必须通过委派调用，直接/verify-agent是当 Slash command 跑的，不会隔离上下文。

7. 把配置沉淀成团队资产

Slash commands 和 Subagents 配好之后，建议把.claude/目录纳入版本控制。项目级的命令和子代理跟着仓库走，新成员 clone 下来就能用，不用口头传授提示词。用户级的放个人目录，放一些跨项目的通用命令。

TaoToken 的统一 Key 通道在这里的价值是：团队共用一套 API 凭证，不用每个人各自申请、各自配置。配合settings.json的env字段，项目级配置可以直接把通道写死，成员只需要在本地环境变量里放自己的 Key，或者由团队统一分发。

后续如果要扩展，可以按「一个命令解决一类高频操作、一个子代理封装一个专业角色」的原则逐步加。命令别贪多，超过 20 个反而记不住；子代理的 system prompt 要写详细，它是子代理行为的唯一依据。

需要进一步操作的话，可以到 TaoToken 控制台管理 API Keys，或者查阅接入文档了解通道细节。如果主要做长期编码和 Agent 工作流，Coding Plan 会更合适；单纯验证模型效果，用模型对话页面就够。配置过程中遇到报错，优先对照第 6 节的排查清单，大部分问题都能定位到具体字段。