企业官网建设流程全解析

9月29日，照例先看了一眼后台的用量仪表盘。OpenAI API 的调用量已经降到月初的一半不到，这个数字我其实一点不意外——最近两周，我把大部分能迁移的工作流都挪到了 Claude Code 底下，又给一批轻量任务接上了本地模型，用量自然就砍下来了。不少朋友看到这个标题，第一反应是"OpenAI 是不是调整了什么策略？"其实更准确地说，是我在主动降低对单一供应商的依赖，顺手把工具链重新打磨了一遍。这篇文章就当作这几天的操作日记，把为什么砍量、怎么砍量、如何把 Claude Code 打磨成真正顺手的"自我优化"工具这件事完整地梳理一遍，里面包括安装配置、多模型接入、CLAUDE.md 记忆文件、hooks 自动化等实操内容，也把我踩过的坑一并列出来。想把手头 AI 工具链重新整顿一下的朋友，这篇应该能少走不少弯路。

1. 先说结论：OpenAI 用量砍半，是我主动做的

1.1 用量账单背后的真实变化

先解释一下"用量砍半"到底砍在哪。我这边主要统计的是一般场景下的 API 调用，包括代码补全、文本处理、还有一部分自动化脚本里的模型调用。八月的时候，这些调用量还很可观，几乎每天都有稳定的请求量；进入九月中下旬后，曲线开始明显往下走，到现在差不多是月初的 45% 左右。

砍量的原因有三层：

• 成本控制：按 token 计费的 API 调用，长期跑起来这笔钱并不少。有些重复性任务，比如格式化日志、批量生成测试数据、给代码写注释，完全没必要每次都走一次昂贵的大模型接口。
• 任务分流：把适合本地模型的轻量任务切出去，让本地小模型处理；把需要复杂推理、多文件修改的重活留给 Claude Code。任务被拆开之后，API 的调用自然就降下来了。
• 减少供应商锁定：之前所有 AI 能力都挂在 OpenAI 一家上，万一某个接口调整或者出现临时不可用，整个工作流都会跟着停摆。迁移一部分任务到其他模型，也是给自己留一条退路。

所以我说的"用量砍半"，是指我自己的实际调用量，这是主动调整的结果，不是某个服务商单方面发生了什么变化。

1.2 任务分流：把"重活"和"轻活"分开

这次用量能降下来，关键动作是"任务分级"。我把平时的 AI 任务分成了三类：

1. 轻量任务：文本分类、关键词提取、简单改写、JSON 格式化这类。这些用本地小模型就够了，比如通过 LM Studio 跑一个 7B 左右的量化模型，响应速度很快，支持 OpenAI 兼容接口，往代码里一接就能用。
2. 中等任务：代码解释、单文件 bug 修复、单元测试生成。这类任务我一般交给第三方 API 接入后的 Claude Code 处理，比如接 DeepSeek 或者通义千问。
3. 重任务：跨文件重构、架构调整、复杂问题排查。这类必须交给能力最强的模型，我给 Claude Code 配上 Anthropic 官方接口或者顶配模型来做。

分完之后效果很明显：用量账单上最显眼的大额调用消失了，取而代之的是本地模型的静默处理和一些第三方 API 的低频调用。整体成本大概降了六成，而任务完成质量没有明显下降。

1.3 这次削减带来的实际收益

用量砍半不是一个数字游戏，背后是实实在在的收益：

• 成本：每月 API 支出明显下降，省下来的预算可以投到其他工具上，比如给 Claude Code 配更好用的第三方接口。
• 稳定性：核心工作流不再依赖单一供应商。之前某个接口不稳定，整个自动化流程都会卡住；现在可以快速切到备用模型，影响范围小很多。
• 效率：Claude Code 在代码任务上的表现，比如多文件理解、自动执行命令、主动修改代码，确实比单纯的 API 调用更适合编程场景。同一个任务，在 Claude Code 里完成的轮次更少，结果也更可控。

如果你现在也面临 API 费用偏高、或者对单一供应商依赖过重的问题，可以参照我这个思路：先梳理任务类型，再决定哪些留在原处、哪些迁移出去。不要一上来就追求"全部替代"，把任务合理分流，才是更稳的做法。

2. 为什么是 Claude Code：它解决了什么问题

2.1 Claude Code 和普通聊天 AI 的本质区别

很多人分不清 Claude Code 和平时用到的 Claude 聊天网页、或者 API 调用有什么区别。简单说，Claude Code 是一个跑在终端里的 AI 编程代理，它不只会"回答你"，还会"动手做事"。

它的核心能力包括：

• 读取项目文件：它能理解整个项目的目录结构、代码内容、配置文件，而不是只看到你粘贴过来的那一段代码。
• 自动修改代码：告诉它"把登录接口改成支持刷新令牌"，它会自己找到相关文件、完成修改、甚至跑一遍测试来验证。
• 执行终端命令：它可以在你确认后直接运行命令，比如安装依赖、执行脚本、运行测试等。
• 多步任务推理：它能把一个复杂任务拆成多个步骤，逐步执行，并在过程中根据结果调整策略。

这些能力叠加起来，它就不只是一个"问答工具"，更像是一个初级开发搭档。当然，它仍然需要你在关键节点做判断和确认，但它确实能接手大量重复性劳动。

2.2 "默认工具"和"趁手工具"的差距

用了一段时间 Claude Code，我有一个很明显的感受：默认状态下的 Claude Code，和打磨之后的 Claude Code，完全是两个工具。

默认状态下，它对你的项目一无所知。每次打开新会话，它不认识你的代码规范、不知道你的项目结构、不理解你常用的命令。你每次都要重新介绍一遍背景，对话效率很低。比如我自己的项目里，前端用 Vue 3 + TypeScript，后端用 Go，部署走 Docker Compose。如果不在每次会话里把这些背景信息交代清楚，它给出的建议就经常会跑偏——比如用 npm 管理 Go 后端的依赖，或者生成不符合项目规范的组件代码。

但打磨之后就不一样了。通过 CLAUDE.md 可以让它记住项目背景；通过自定义命令可以把高频操作固化成一条指令；通过 hooks 可以让它在特定动作前后自动执行某些检查。打磨的本质，就是把"通用助理"变成"懂你这个项目和团队习惯的专用工具"。

2.3 自我优化到底在优化什么

标题里说的"打磨自我优化"，我理解有两条线：

一条线是优化 Claude Code 本身的使用方式。包括写好 CLAUDE.md、配置好模型供应商、把常用操作做成快捷命令、把容易出错的动作加上 hooks 校验。这些是"你"在优化"它"。

另一条线是让 Claude Code 帮你优化工作流。比如让它审查你的代码并给出规范建议、让它自动补充测试、让它帮你更新项目文档。这些是"它"在帮你优化"事情"。

两条线结合起来，就形成了一个正向循环：你给 Claude Code 喂了足够多的项目上下文，它给出的建议就更准确；建议准确了，你更愿意让它承担更多任务；任务变多变复杂之后，你又会对自动化、校验提出更高要求，于是再去配置 hooks、调命令。这个过程就是"自我优化"在工作流层面的实际体现。

3. 打磨 Claude Code 的几个核心维度

3.1 用 CLAUDE.md 建立项目级记忆

Claude Code 在启动时会自动读取当前项目的 CLAUDE.md 文件，把它作为项目的"长期记忆"。这是我目前认为最重要的一项配置。没有它，每次会话就是失忆式聊天；有了它，Claude Code 一进入项目就自带完整上下文。

我的 CLAUDE.md 一般包含五块内容：

• 项目概述：这个项目是干什么的、用户群体是谁、核心功能有哪些。
• 技术栈：前端框架、后端语言、数据库、部署方式，以及版本管理工具。
• 编码规范：命名风格、目录约定、组件写法、错误处理习惯等。
• 常用命令：如何启动开发环境、如何跑测试、如何构建、如何部署。
• 架构要点：核心模块的职责边界、关键数据流、哪些地方不能随便改。

写 CLAUDE.md 有一个经验：不要写大而全的教科书，只写那些 AI 一旦不知道就会出错的信息。比如"项目使用 pnpm 而不是 npm"，这类信息价值极高；而"代码应该清晰易读"这种废话写了等于没写。

3.2 自定义命令：把高频操作固化成 slash 指令

Claude Code 支持自定义 slash 命令。你可以在项目的.claude/commands/目录下放 Markdown 文件，文件名就是命令名。比如我创建一个review.md，内容是：

请对当前分支上的代码改动进行逐文件审查。 重点检查： 1. 是否有明显逻辑错误或边界遗漏 2. 是否符合项目的编码规范 3. 是否需要补充单元测试 4. 是否存在性能隐患 输出格式： - 问题列表（按严重程度排序） - 对应文件与行号 - 修改建议

之后我在对话里输入/review，Claude Code 就会按照这份指令执行代码审查，输出固定格式的报告。类似的，我还会配置/test自动跑测试并汇总失败原因，/commit根据 git diff 生成符合规范的提交信息，/doc更新 README 和接口文档。

这项操作的价值在于：把重复性任务的执行逻辑沉淀成指令文件，之后每次调用都是同样的标准，不会因为对话语境变化而漏掉关键检查项。

3.3 hooks：让 AI 在关键节点自动执行动作

hooks 是 Claude Code 另一个很有用的机制。它可以在某些事件发生时自动触发外部命令或脚本。常见的事件包括：

• PreToolUse：在 AI 即将执行某个工具（比如运行 Bash 命令、编辑文件）之前触发，可以用来做校验或告警。
• PostToolUse：在工具执行完之后触发，可以用来做结果检查或日志记录。
• Notification：在某些通知事件发生时触发。具体事件类型可以通过官方文档进一步确认，比如任务完成、需要用户输入等场景。

我实际使用的一个场景是：在 Claude Code 每次运行git commit之前，用 PreToolUse 钩子跑一遍 lint 检查，如果检查不通过就阻止提交。这样能避免 AI 把带着明显风格问题的代码直接提交上去。hooks 的配置写在.claude/settings.json里，形式大致如下：

{ "hooks": { "PreToolUse": [ { "matcher": "Bash(git commit*)", "hooks": [ { "type": "command", "command": "npm run lint && node check-config.mjs" } ] } ] } }

注意一点：hooks 是增强手段，不是替代码检查工具本身。它更适合做"流程控制"，比如强制校验、自动记录、失败拦截，真正深入的分析还是要靠专门的检查工具。

3.4 多模型接入：不要被单一供应商锁死

Claude Code 默认对接 Anthropic 的接口，但它也支持通过环境变量配置自定义的 API 端点和密钥。这就意味着，可以把第三方模型接进来使用。我目前实际在用的组合是：

很多社区工具也为多模型切换提供了便利，比如 CC Switch 这类工具就是典型代表。它的价值在于：把多个模型供应商的配置集中管理，随时切换，不用每次改环境变量。这也让我在某个供应商接口出问题或者价格调整时，能有非常灵活的应对空间。

4. 实操：从零搭一套顺手的环境

4.1 安装和登录（npm 方式）

Claude Code 的官方推荐安装方式是通过 npm。前提是机器上有 Node.js，建议版本 18 以上。安装命令很简单：

npm install -g @anthropic-ai/claude-code

安装完成后，在终端输入claude就可以进入交互界面。如果你是第一次使用，需要完成登录验证，方式有几种：

• 订阅账号授权：用 Claude 订阅账号走 OAuth 登录流程，这种方式跟 ChatGPT 订阅登录的逻辑类似，适合日常个人使用。
• API Key 方式：在 Anthropic 控制台申请 API Key，然后通过环境变量指定：

export ANTHROPIC_API_KEY=你的密钥

之后输入claude启动时，它会自动读取这个环境变量。我把这行配置写进了~/.zshrc，省的每次手动 Export。升级方面，Claude Code 更新迭代很快，官方也提供了在线升级的入口，建议保持更新频率，新版本经常会修复一些终端适配问题。

4.2 VS Code 集成配置

很多人不习惯纯终端操作，希望能在 VS Code 里用 Claude Code。这块有两个思路。

第一个思路是在 VS Code 的集成终端里直接启用 Claude Code。因为 VS Code 自带终端，你在项目根目录打开终端、输入claude启动，它就能读取当前项目文件，完成代码修改后你在编辑器的 Diff 视图里直观看到改动。这种方式不需要额外插件，最省事。

第二个思路是安装 VS Code 扩展市场里的 Claude Code 相关扩展（具体以官方扩展为准）。这种图形化方案的优势在于：可以选中代码片段直接发送给 Claude Code，还能在侧边栏里查看执行状态。我个人的实际体验是：大部分场景直接用集成终端就够了，扩展插件更适合可视化需求更强的用户。日常使用中，我是把终端拆成上下两栏，上栏跑 Claude Code，下栏跑构建/测试命令，两边配合工作效率很高。

4.3 接入第三方和本地模型

接入第三方模型的核心思路，是让 Claude Code 把请求发到你指定的 OpenAI 兼容或者 Anthropic 兼容端点。这个操作对不同模型的差异其实很小，关键配置就是两个环境变量：

export ANTHROPIC_BASE_URL=https://你的API端点 export ANTHROPIC_AUTH_TOKEN=你的密钥

ANTHROPIC_BASE_URL指向你所用服务商的兼容端点，ANTHROPIC_AUTH_TOKEN换成对应的访问令牌。不同供应商的模型能力差异会直接影响 Claude Code 的实际表现，第三方模型在复杂任务上的表现可能不如官方模型，所以我在实际使用中会把第三方模型留给中等任务，复杂重构还是切回官方接口。

接线本地模型的时候，我用的是 LM Studio。它可以在本地起一个服务，默认监听http://localhost:1234/v1，提供 OpenAI 兼容接口。要让 Claude Code 用上它，同样是通过环境变量把 Endpoint 指过去。因为这种转换需要协议适配，部分场景下可能要借助协议转换代理来对接，否则 Claude Code 可能不识别 OpenAI 格式的请求。本地模型这块可以先用一些小一点的量化模型做文本生成、代码解释、日志分析，跑起来之后再把更重的任务慢慢往 Claude Code 上挪。

4.4 我的 CLAUDE.md 模板

给一个我实际在用的简化模板，只保留最核心的部分，供参考：

# 项目名称：用户中心服务 ## 项目概述 基于 Go 实现的用户注册、登录、鉴权服务，面向 To B 客户提供 API。 ## 技术栈 - 语言：Go 1.22 - Web 框架：Gin - 数据库：MySQL 8.0（GORM 访问） - 缓存：Redis 7 - 部署：Docker Compose + Nginx ## 编码规范 - 错误处理：统一返回 { code, message, data } 结构 - 命名：接口入参使用 Request 后缀，出参使用 Response 后缀 - 目录约定：handler/ 放 HTTP 处理，service/ 放业务逻辑，repo/ 放数据访问 - 禁止在 handler 中直接写 SQL ## 常用命令 - 本地启动：make dev - 运行测试：make test - 构建镜像：make build - 代码格式化：gofmt -w . ## 架构要点 - 切换用户状态必须先调用 authService.Validate - 订单模块和支付模块通过事件总线解耦，不要直接互相调用 - 配置文件统一放 config/ 目录，禁止硬编码环境地址

这个模板的核心原则就是信息密度高、每一条都有实际用途、AI 犯错时能派上用场。你把这样的文件放在项目根目录之后，Claude Code 每次进来都会自动读取，给出的建议准确率会高很多。

5. 这几天踩过的坑和排查手册

5.1 组织策略导致的订阅访问被禁

有次我在公司项目目录下启动 Claude Code，直接弹出了类似 "Your organization has disabled Claude subscription access for Claude Code" 的报错。网上不少人也遇到过，这个问题的本质不是工具坏了，而是组织管理员在控制台里限制了 Claude Code 的订阅访问权限。

处理办法分几种情况：

• 如果你是管理员：登录 Anthropic Console，在组织设置里找到 Claude Code 的访问控制开关，把它启用。具体路径一般是 Organization Settings 下的访问策略，不同版本可能有差异。
• 如果你是普通成员：联系管理员确认是否开放了权限。如果公司策略就是不开放，就用个人账号或者 API Key 方式代替。
• 临时绕过：如果只是想在个人项目里用，可以用自己的个人订阅账号重新登录，绕开组织限制。

这个报错很容易让人误以为是网络或者安装问题，实际上只要看到 "organization" 和 "subscription access" 同时出现，优先排查组织权限，不要浪费时间去重装。

5.2 依赖缺失与重装

还有一次是另外一台 Windows 机器上装某个编程代理工具，长时间挂着某个平台二进制依赖缺失的报错。具体错误大概是missing optional dependency @openai/codex-win32-x64这一类的。这类问题在跨平台的 Node 工具里挺常见——安装器在下载平台专用二进制包时失败，常见诱发因素是网络问题或者 npm 配置里禁用了 optional dependencies。

排查思路如下：

• 先确认 Node 和 npm 版本，太旧的可能导致 optional dependencies 安装异常。
• 检查 npm 配置，看看是否设置了--no-optional之类的参数：

npm config get optional

如果返回 false，需要把它改成 true 或移除相关配置：

npm config set optional=true

• 清理缓存重新安装：

npm cache clean --force npm install -g 包名

• 如果还是不行，可以试试把全局包卸载干净再装一次。这类平台二进制依赖出错，大部分时候重装就能解决，关键是重装时候保证网络环境稳定。

5.3 第三方 API 接入时的鉴权细节

接入第三方 API 最容易出问题的点，反而不是网络，而是环境变量没配对。常见的情况有：

• 变量名拼写错误，比如把ANTHROPIC_AUTH_TOKEN写成ANTHROPIC_API_KEY，导致服务商不认账。
• 密钥里带了换行或空格，这个非常隐蔽，肉眼看不出来，鉴权就是一直失败。我的经验是赋值后用echo "${变量}"确认一下内容。
• 第三方端点要求的是 Bearer Token 格式，而你在配置里用了裸密钥。这种情况需要带上Bearer前缀，或者在服务商控制台里找到正确的凭据类型。

遇到鉴权失败，先把环境变量整体打印出来看看，而不是盲目怀疑网络。我至少有一半的"网络问题"实际上是环境变量配错了。

5.4 终端命令执行失败的处理

Claude Code 在执行终端命令时，偶尔会遇到"权限被拒"或者"命令不存在"的情况。有几个排查点：

• 工具权限：Claude Code 默认不会执行所有终端命令，它需要用户的确认或者预先在配置里放行。如果你希望某些命令直接可用，可以在设置里把对应命令加入允许列表。例如在.claude/settings.json中配置allowedTools。
• Shell 环境：如果某个命令在你自己终端里能跑，但 Claude Code 里报错，很可能是它的环境变量和你日常环境不一致。注意 Claude Code 进程继承的环境变量，以及在启动前是否 source 了对应的 profile 文件。
• 交互式命令：Claude Code 不适合执行需要交互式输入的命令，比如某些会弹出确认菜单的脚本。这类命令要提前写好非交互参数，或者包一层自动化脚本。

碰到终端命令问题，我的做法是：先在普通终端里手动跑一遍同样的命令，确认命令本身没毛病，然后才去排查 Claude Code 这边的环境差异。这一步能帮你快速定位问题边界。

结尾：一点个人体会

这几天的折腾下来，我最深的感受是：AI 工具链里其实不存在"一个工具打天下"的解法。OpenAI 的模型能力确实强，但把它用在所有场景里，既不经济也不灵活；Claude Code 这类 AI 编程代理的潜力很大，但默认配置只是一个起点，真正让它发挥价值的是你为它注入的项目上下文、自动化规则和模型路由策略。用量砍半这件事，表面上看是成本控制，实质上是我把"什么任务该交给什么模型"这个问题想得更清楚了。

最后再分享一个小技巧：不要一次性把 CLAUDE.md 写得很完美，先写一个粗糙的初版，然后在用 Claude Code 的过程中，一旦发现它因为缺少背景信息而犯错，就立刻把那类信息补充到 CLAUDE.md 里。持续迭代两到三周，这份文件就会变得非常贴合你的项目习惯，那时候 Claude Code 的"自我优化"才算真正上线了。工具会持续更新，供应商的价格和策略也会变，但只要你的优化流程是可持续的，这套工作流就能不断跟着调整，帮你长期保持高效率。