企业官网建设流程全解析

1. 为什么你的 Claude Code 用久了会变“笨”

刚上手 Claude Code 的时候，很多人都会经历一个蜜月期：终端里敲几句话，它就能帮你读文件、改代码、跑测试，效率直接翻倍。但用上一两周，尤其是同一个项目连续对话几天之后，你会明显感觉到它开始“跑偏”——前面说过的需求它忘了，改代码只改一半，问它某个函数在哪它开始胡编。这不是模型退化了，而是上下文窗口被塞满了。

大模型的上下文窗口是有硬上限的，单位是 token。你贴进去的代码、文档、历史对话、系统提示词，全都算在里面。一旦接近上限，模型就会自动丢弃较早的信息，表现就是前后逻辑矛盾、遗漏需求、批量修改不完整。日常最典型的两个症状：长对话越聊越偏，批量重构改着改着漏文件。

解决这个问题有两条路。一条是会话层面的：用/compact压缩冗余对话，用/clear直接清空重来，用/context看当前占用比例，心里有数。另一条是配置层面的：把该持久化的规则写进CLAUDE.MD，把重复性的专项流程封装成 Skill，让每次新会话都能带着“记忆”和“技能”轻装上阵，而不是靠堆对话历史硬撑。

这篇就聚焦后一条路，顺带把多工具、多项目下 Key 和 API 通道分散的问题一起收掉。核心思路是：用CLAUDE.MD管规则，用 Skill 管能力，用统一的 API 通道管接入。下面直接给可复制的东西。

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

在动手写配置之前，先把接入层理清楚。Claude Code 本身是个客户端，它需要连到一个兼容 Anthropic 协议的 API 端点。如果你同时在用多个工具（CC、Cursor、各种脚本），每个都单独配 Key、单独记地址，时间一长必然乱。我的做法是统一走一个通道，所有工具共用同一套 Key 和 Base URL。

TaoToken 在这里扮演的就是这个统一通道的角色。它的 API 地址是https://taotoken.net/api，兼容 Anthropic 的接口格式，Claude Code 可以直接对接。你需要先去控制台拿一个 API Key，然后把它写进环境变量或配置文件里。

拿 Key 的入口在控制台，具体路径是console页面下的api-keys管理。生成之后复制出来，注意只显示一次，丢了就重新生成。拿到 Key 之后，Claude Code 的接入方式有两种：一种是走环境变量，一种是写进settings.json。我推荐后者，因为可以跟项目配置一起管理，换机器时不容易漏。

这里先给一个最小可用的环境变量写法，方便你快速验证通道是否通：

export ANTHROPIC_BASE_URL="https://taotoken.net/api" export ANTHROPIC_API_KEY="sk-你的Key"

设置完在终端里echo $ANTHROPIC_BASE_URL确认一下有没有生效。这一步看着简单，但后面所有配置都依赖它，别跳过。

3. 可复制配置：CLAUDE.MD 三层骨架 + Skill + settings.json

3.1 CLAUDE.MD 的三层结构与职责

Claude Code 读取CLAUDE.MD是按层级来的，优先级从低到高是：全局 → 项目根目录 → 子文件夹。内层覆盖外层，层层叠加。理解这一点很关键，因为它决定了你把什么规则放在哪一层。

全局CLAUDE.MD放在用户配置目录下，对所有项目生效，适合放通用习惯，比如“回答用中文”“改代码前先说明改动点”“不要自动执行破坏性命令”。项目根目录的CLAUDE.MD只对当前项目生效，适合放项目专属规范，比如技术栈、目录约定、启动命令、测试方式。子文件夹的CLAUDE.MD优先级最高，只对所在目录及下级生效，适合放模块级规则，比如某个子包必须用某种设计模式、某个目录禁止直接改。

在项目里执行/init会自动生成项目级的CLAUDE.MD和.claude目录结构。全局的那份用/memory命令进入记忆管理，选User memory来编辑。下面给一份可以直接抄的项目级骨架：

# 项目约定 ## 技术栈 - 语言：TypeScript 5.x + Node 20 - 框架：Express + Prisma - 测试：Vitest，测试文件放在 __tests__ 目录 ## 目录结构 - src/routes：路由层，只做参数校验和转发 - src/services：业务逻辑，禁止直接操作数据库 - src/repos：数据访问层，所有 Prisma 调用集中在这里 ## 编码规范 - 所有导出函数必须有 JSDoc 注释 - 错误统一用 AppError 类抛出，不要裸 throw new Error - 提交前必须跑 `pnpm test` 和 `pnpm lint` ## 常用命令 - 启动开发：pnpm dev - 跑测试：pnpm test - 生成 Prisma client：pnpm prisma generate ## 禁止事项 - 不要修改 migrations 目录下的历史文件 - 不要在生产配置里硬编码密钥

这份骨架的写法有个技巧：规则要具体到可执行，别写“代码要优雅”这种没法验证的话。写“所有导出函数必须有 JSDoc”就比“注意注释”有用得多，因为模型能明确判断有没有做到。

3.2 把细分规则拆出去，保持主文件清爽

CLAUDE.MD写太长会占用上下文，而且维护起来痛苦。更好的做法是主文件只留核心规则和引用，细分内容拆成独立文档放在.claude/docs/下，需要时让模型自己去读。比如：

## 详细规范索引 - API 设计规范见 .claude/docs/api-style.md - 数据库迁移流程见 .claude/docs/migration.md - 前端组件约定见 .claude/docs/frontend.md

这样主文件保持在几十行，模型在遇到相关任务时会自动去读对应文档，既省 token 又不丢信息。

3.3 Skill 的定位与配置片段

Skill 和CLAUDE.MD是互补关系，不是替代。CLAUDE.MD是全程默认生效的规则总控，Skill 是按场景触发的专项能力单元。把复杂重复的流程塞进CLAUDE.MD会让主文件臃肿，而且没法做到“只在特定场景执行”。Skill 可以手动/skill 名称调用，也能在特定场景自动触发，还支持嵌套组合。

Skill 分项目级和全局级。项目级放在.claude/skills/下，只对当前项目生效；全局级放在系统配置目录，所有项目可用。一个 Skill 就是一个文件夹，里面至少有一个SKILL.md描述它的用途和触发条件。下面给一个自定义 Skill 的配置片段，功能是“代码评审”：

--- name: code-review description: 对指定文件或目录做代码评审，检查命名、错误处理、边界条件和测试覆盖 --- # 代码评审 Skill 当用户要求评审代码时，按以下步骤执行： 1. 读取目标文件，理解其职责 2. 检查命名是否表意清晰，函数是否单一职责 3. 检查错误处理：是否有未捕获的异常、是否有裸 throw 4. 检查边界条件：空值、越界、并发场景 5. 检查测试覆盖：对应测试文件是否存在，关键分支是否覆盖 6. 输出评审报告，按严重程度分级：阻塞 / 建议 / 可选 输出格式： - 文件路径 + 行号 - 问题描述 - 修改建议（给出代码片段）

把这个文件夹放到.claude/skills/code-review/下，重启会话后就能用/skill code-review调用。你也可以在CLAUDE.MD里写一句“代码修改完成后自动调用 code-review Skill”，让它场景化触发。

3.4 settings.json 示例

settings.json放在.claude/目录下，用来配置模型、权限、环境变量等。下面这份是接入 TaoToken 通道的示例：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-你的Key" }, "model": "claude-sonnet-4-20250514", "permissions": { "allow": [ "Read", "Edit", "Bash(pnpm test)", "Bash(pnpm lint)" ], "deny": [ "Bash(rm -rf *)", "Bash(git push --force*)" ] } }

permissions这块建议认真配。allow里放你信任的只读和测试命令，deny里放破坏性操作。这样模型在执行命令前不会反复问你，效率高很多，同时危险操作被硬拦住。

4. 验证请求：确认配置真的生效了

配置写完不代表生效，得实际验证。下面给一套具体的验证动作，按顺序做一遍。

第一步，验证 API 通道。在终端里直接发一个请求，确认 Key 和地址没问题：

curl https://taotoken.net/api/v1/messages \ -H "x-api-key: sk-你的Key" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-sonnet-4-20250514", "max_tokens": 64, "messages": [{"role": "user", "content": "回复 OK 两个字母"}] }'

如果返回里有正常的content字段，说明通道通了。返回 401 就是 Key 错了，返回 404 就是地址写错了。

第二步，验证CLAUDE.MD被读取。在项目里启动 Claude Code，输入/memory，看Project memory里是不是你写的那份内容。然后随便问一句“这个项目用什么测试框架”，如果它答出 Vitest，说明项目级配置生效了。

第三步，验证 Skill 可调用。输入/skill code-review，看它是否按你写的步骤执行。如果提示找不到 Skill，检查文件夹路径是不是.claude/skills/code-review/SKILL.md，注意大小写和层级。

第四步，验证上下文占用。输入/context，看当前 token 消耗构成。正常情况下系统工具和系统提示词占大头，对话消息占小头。如果你发现对话消息占比异常高，说明该/compact了。

第五步，验证权限配置。让模型执行一个deny列表里的命令，比如rm -rf test，看它是否被拦住。被拦住说明权限配置生效。

这五步走完，整套配置就算落地了。后面每次新会话，模型都会自动带着这些规则和技能启动，不用再重复交代。

5. 本篇常见错排查

配置过程中最容易踩的坑集中在几个地方，我按出现频率排一下。

Key 无效或过期。表现是 curl 返回 401，或者 Claude Code 启动时报认证失败。先去控制台确认 Key 还在、额度还有，然后检查settings.json里的 Key 有没有多余空格或换行。环境变量和配置文件同时存在时，环境变量优先级更高，别两边写的不一样。

Base URL 写错。常见错误是写成https://taotoken.net/api/带尾斜杠，或者写成https://taotoken.net漏了/api。正确写法是https://taotoken.net/api，不带尾斜杠。这个细节会导致 404，但报错信息不一定直白。

CLAUDE.MD 没被读取。先确认文件名大小写，必须是CLAUDE.MD全大写。然后确认位置，项目级的必须在项目根目录，不是.claude/里面。子文件夹级的必须在目标文件夹内。用/memory能看到当前生效的是哪几份。

Skill 调用不到。检查三点：文件夹名和SKILL.md里的name是否一致；SKILL.md的 frontmatter 格式是否正确，---不能少；重启会话后 Skill 才会被加载，改完不重启不生效。

上下文爆了但没察觉。养成习惯，长对话每隔一段时间跑一次/context。如果对话消息占比超过 40%，就该/compact了。如果压缩后还是高，直接/clear重开，把关键结论写进CLAUDE.MD或临时文档，别硬撑。

权限配置不生效。settings.json的permissions只在会话启动时读取，改完要重启。另外allow和deny的匹配是前缀匹配，Bash(pnpm test)能匹配pnpm test --watch，但匹配不了pnpm run test，写的时候注意。

6. 把通道和配置固定下来

配置这东西，一次配好，后面就是复利。CLAUDE.MD让你不用每次重复交代项目规范，Skill 让你把重复流程一键化，统一的 API 通道让你换工具时不用重新折腾 Key。三件事叠在一起，日常开发里那些琐碎的、重复的、容易忘的环节就被收掉了。

如果你还没拿 Key，去控制台生成一个，然后按上面的settings.json示例接进去。接入过程中遇到认证或配置问题，直接翻接入文档对照排查。想先验证模型通不通，用模型对话页面发一句话最快。如果你打算长期在编码和 Agent 场景里用，Coding Plan 那条线更适合，额度和稳定性都更省心。

最后留一个我自己的习惯：每次项目结构有大变动，就顺手更新一次项目级CLAUDE.MD，把新的目录约定和命令补进去。这个动作花不了两分钟，但能让后面几十次会话都少走弯路。