企业官网建设流程全解析

天天泡在终端和编辑器里的人，应该都遇到过这种场景：改完代码想看报错，切去浏览器翻半天文档，再切回编辑器继续改……来回折腾半小时。用上 Claude Code 之后，这个流程被大幅简化了——它是一个跑在终端里的 AI 编程助手，能在你熟悉的命令行界面里直接读代码、改文件、跑命令。今天这篇就整理我个人在实际使用中觉得真正用得上的技巧，从安装、编辑器集成到模型接入、踩坑记录都过一遍，适合正在入门、或者已经用了一段时间想榨干它效率的人。

我承担过不少从零搭建开发环境、评估 AI 编程工具落地价值的工作，Claude Code 不是那种“装完就吃灰”的演示级工具，只要配置得当，它确实能沉到日常工作流里。下面这些内容全部来自实际使用和调试的经验，不保证每个技巧都适合你的场景，但至少能帮你少走几段弯路。

1. 安装与基础准备：先把环境搭对，后面才不膈应

1.1 官方安装方式与运行前提

Claude Code 本质上是一个命令行工具，官方通过 npm 分发。所以装它之前，你得先有一个能正常工作的 Node.js 环境。我的建议是直接装 Node.js 18 及以上版本，太老的版本跑起来会遇到各种奇奇怪怪的兼容问题。装好之后，一条命令就能搞定：

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

装完在终端输入claude，就能进入交互界面。如果你是第一次运行，它会引导你完成账号登录和授权，这个过程走的是 OAuth 流程，浏览器里确认一下就行。

这里的“为什么”值得展开一下：Claude Code 选择做在终端里，而不是像 Cursor 那样做一个独立 IDE，核心原因是它能最大化复用你现有的工程化工具链——Git、构建脚本、测试框架、SSH 环境，全部天然可用。你不用把一个项目的目录结构重新录入到某个编辑器里，它天然就站在你项目的最中间。

1.2 Windows、Linux 与 Ubuntu 场景下的细节

Windows 上安装，最容易踩的坑有两个。第一个是 npm 全局安装目录没有写入权限，报错通常是EACCES或EPERM。很多人这时候会顺手在命令前面加一个sudo（在 Git Bash 里）或者用管理员 PowerShell 重开窗口，能解决，但不太优雅。我更推荐先用nvm管理 Node.js 版本，这样 npm 全局目录默认就在用户目录下，压根不会遇到权限问题。

第二个坑是终端选择。Windows 自带的 CMD 对交互式终端工具的支持比较差，建议直接用 Windows Terminal 或 VS Code 内置终端跑 Claude Code。如果你平时用 Git Bash，也基本没问题。还有一点：如果你发现claude命令在重启终端后消失了，多半是环境变量 PATH 没有刷新，重新加载一下~/.bashrc或者新开窗口就行。

Linux（包括 Ubuntu）上安装相对顺滑，但要注意如果服务器是精简版系统，可能缺一些基础依赖。我在一台 Ubuntu 22.04 的机器上装完后，运行时报了找不到libstdc++之类的错误，用包管理器补一下 build-essential 就解决了。如果你和我一样用 nvm，还有一个细节：nvm是挂在某个用户目录下的，如果你用sudo切换用户执行 claude，很可能找不到这个命令。所以建议始终用同一个非 root 用户，以普通权限跑。

1.3 关于下载与可用性的合规说明

安装过程中，有些朋友会遇到下载慢、装不上、或者提示当前地区不支持的情况。这里面需要区分两件事：npm 下载慢是有合规方案解决的——把 npm registry 切到国内镜像源，一条命令就能明显提速：

npm config set registry https://registry.npmmirror.com

但如果你遇到类似 “Claude Code might not be available in your country” 这样的提示，那说明当前网络环境不在官方支持范围内。是否可用、如何获得授权，一切以官方渠道的信息为准，请务必遵守当地法律法规和平台服务条款。我不会在这里介绍任何规避手段，也不建议你去找未经确认的替代安装包，那样既容易踩到安全风险，也可能白白浪费时间。我的态度很简单：工具是拿来提效的，不是拿来折腾的。

2. 编辑器集成：把 AI 塞进你现有的工作流

2.1 在 VS Code 里跑 Claude Code

虽然 Claude Code 本身是终端程序，但我强烈建议在 VS Code 的内置终端里跑，而不是单独开一个终端窗口。原因有三个：一是内置终端自动继承了工作区的环境变量和虚拟环境，不用额外激活；二是跑完代码后，报错信息可以直接点跳转到对应文件；三是本身就有文件树、diff 对比、搜索面板，配合 Claude Code 改代码时上下文是连续的。

启动方式没什么玄学：在 VS Code 里按Ctrl+`打开终端，输入claude进入交互态。首次运行会按引导完成登录。之后每次进入项目目录，它都会自动读取目录下的相关配置文件，把项目上下文带起来。

2.2 权限控制与项目级记忆配置

Claude Code 可以执行命令、改文件，所以权限边界一定要尽早设置。我通常一进来就先把模式切到带确认的状态，让它在执行写操作前询问我。它支持通过/permissions查看和管理权限策略。你在实际操作中也可以这样设置：允许读文件、运行测试命令，但写文件时一律先过问我。

另一个容易被忽略的功能是项目级记忆——CLAUDE.md。你可以把它理解为给模型看的“项目说明书”，它会在每次会话启动时自动加载。我在 CLAUDE.md 里会固定写三段内容：项目结构、常用命令、代码约定。写完这个文件之后，Claude Code 在回答问题和写代码时的表现有一个肉眼可见的提升——因为它不再靠猜，而是真正知道这个项目长什么样。这个文件建议提交到 Git 仓库，团队其他人也能复用。

2.3 效率类联动：用 webhook 把状态推进群里

如果你经常提交一个长时间运行的任务，然后人就去干别的了，那你可能会对这招感兴趣：Claude Code 支持的 hooks 机制，可以在特定事件发生时触发外部通知。社区里有人把这个能力接到了飞书群机器人上，通过简单的 webhook 配置，让任务完成或报错时自动推一条消息到群里。我自己的团队实践是：让 Claude Code 跑完一轮代码审查后，把结论和待办事项推到项目群里，这样不用大家各自盯着终端看输出，只要群里出现消息就去处理就行。

这类配置的主要工作点是写脚本：在项目里加一个脚本文件，调用飞书群机器人的 webhook 地址，然后在 Claude Code 的 hooks 配置里把事件和脚本绑定起来。如果你们全员都用 Claude Code，这个联动很值得试。

3. 进阶玩法：Skills、上下文管理、思考等级与 workflows

3.1 Skills（技能）到底是什么

Claude Code 的技能（Skills）机制，通俗地说，就是你可以给模型预置一套“领域能力包”。一个技能可以包含一个说明文件、若干脚本、数据文件等等，其核心作用是让 Claude Code 在特定场景下知道该调用什么工具、按什么流程做事。如果你开发过通用编程助手，可以把 Skills 理解成“可插拔的插件模板”。

举个例子：你经常让 Claude Code 写数据库迁移脚本，那可以做一个“database-migration”技能，里面写好迁移脚本的模板、检查清单和常用命令。之后只要在对话中提起这个技能，它就会按预设的流程执行，而不是每次从头问你“迁移脚本需要哪些注意事项”。这种封装特别适合团队里反复出现的重复任务。

3.2 如何手动安装 GitHub 上的 Skills

GitHub 上有不少开发者分享了自己做好的 Skills 仓库。手动安装的步骤很直接：先把仓库 clone 下来，然后把里面的 skills 目录复制到项目的.claude/skills目录下。比如：

# 在项目根目录执行 mkdir -p .claude/skills cp -r /path/to/your-skill-repo/skills/* .claude/skills/

装完之后，重启会话，输入/skills应该能看到已生效的列表。这里有一个细节：不是所有叫“skill”的文件夹都能被识别，官方对技能目录内的文件结构有要求——通常需要SKILL.md文件来声明技能的名称、描述和调用方式。如果发现没生效，优先检查这个文件是否存在，以及目录层级是否放到了项目根目录下能识别的位置。

还有一点，团队协作时注意把.claude/skills一并纳入版本控制。实际经验告诉我，技能是在对话中反复消费的“团队资产”，值得维护和迭代，就像维护公共代码库一样。

3.3 1M 上下文、压缩与缓存配置

长上下文是 Claude Code 的一个关键卖点，大上下文窗口意味着你可以把整个核心代码目录放进去，让模型“看到整个项目”再回答。但千万别一股脑把整个仓库塞进去——上下文是有限资源，塞得越多，模型响应越慢、成本越高，关键信息反而可能被淹没。

我在实际使用中习惯用/context命令随时查看当前会话的上下文占用情况。当上下文消耗到比较高的时候，用/compact做一次压缩，把之前的对话内容精简为摘要，腾出空间继续干活。很多人不知道这个操作，结果会话长到一定程度后响应质量肉眼可见地下降，还以为是工具不行。

另外，网上很多人讨论export ENABLE_PROMPT_CACHING_1H=1这个配置，我的实测结论是：如果你用的是支持提示词缓存的 API 账号，这个环境变量确实能让重复上下文的费用明显下降。原理是平台把相同前缀的提示词做了缓存计费，简单说就是同一个项目内反复会话时，成本更划算。如果你是自己付费重度使用，值得设置；如果是走团队统一配额，影响相对小，但也无害。

3.4 思考等级调整与 workflows 搭配

Claude Code 支持通过命令调节“思考力度”，也就是模型在回答前内部推理的强度。低档响应更快、更省算力，高档在处理复杂逻辑、架构设计时更稳。实际操作中，我在/thinking里可以设置low、high甚至xhigh等级。

这里有一个和 workflows 搭配的高级用法：你可以在一个自动化流程里设定不同的思考等级——比如“架构审查阶段用 xhigh，生成代码阶段用 low，最后由 human 复核”的阶段式流程。workflows 的本质是预定义的步骤链条，它能把一个复杂的多阶段任务拆成固定流程，每步可以指定不同的参数和行为。

我自己的经验是，日常对话默认用high是平衡性价比的选择；但当任务明确是“阅读仓库、找 bug、做小改动”这种执行类任务，降到low或medium响应速度会明显提升，而质量损失不大。反之，做代码设计评审时如果还开 low，那基本等于让模型敷衍你。

4. 模型接入玩法：让 Claude Code 跑 DeepSeek 等第三方模型

4.1 为什么可以替换默认模型

Claude Code 默认连接官方模型服务，但它的结构允许通过环境变量把请求指向兼容的 API 端点。社区里很多人把 DeepSeek 等模型接入进来，一方面是因为有多模型选择的灵活性，另一方面也是出于成本和网络环境的现实考量。具体到实现上，核心就是配置几个环境变量：API 地址、令牌和模型名。

这里要提醒一句：API 兼容不一定等于效果完全一致。Claude Code 的部分高级特性（如某些工具调用格式、特殊指令）依赖模型侧的配合，换了模型之后，代码生成质量、指令遵循能力都会有差异。这不代表不行，但心里要有预期，不能指望所有模型都“无感切换”。

4.2 DeepSeek 接入的关键配置

以 DeepSeek 接入为例，社区里流传得比较广的做法是这样设置环境变量：

export ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic" export ANTHROPIC_AUTH_TOKEN="你的API-KEY" export ANTHROPIC_MODEL="deepseek-chat"

把这些环境变量写入你的 shell 配置文件（比如~/.bashrc或~/.zshrc），再启动 Claude Code，它就会走 DeepSeek 的接口。如果要用更强的推理模型，把ANTHROPIC_MODEL换成对应的模型名即可。具体支持的模型名和 API 端点，以 DeepSeek 官方文档为准，我这里不贴可能过期的信息。

实际操作中我的经验是：先单独用 curl 测一下 API 端点通不通，再启动 Claude Code，这样排查问题更快，不容易出错。例如先用curl请求一次接口，确认能返回正常响应，再回终端启动 claude，如果仍然失败，大概率是环境变量名称写错了，或者令牌配置有问题。

4.3 用社区工具管理多套配置

有需求就有生态，社区里很快出现了专门用来切换模型配置的小工具——CCSwitch 就是其中呼声很高的一个。它本质上做了一件很朴素的事：帮你把多套环境变量配置管理起来，在不同 API 供应商或模型之间一键切换。在 Claude Code 场景下，你可以在官方模型和 DeepSeek 模型之间来回切换，不用每次手动改环境变量。

它的配置方式通常是把多套配置写在一个配置文件里，然后调用命令选择当前激活的配置文件。我实际用下来的感觉是：这类工具对“多模型重度用户”确实方便，但如果你平时只用一个供应商，装它反而多了一层概念负担。按需取舍，别被工具绑架。

至于部分用户提到的 OpenAI 兼容接口要独立配置的情况（比如“opencode 接入 Claude Code”之类的场景），思路是一致的：确认工具支持配置 Base URL、API Key、Model 名称，再按对应格式填入即可。

5. 实用场景与常见问题排查实录

5.1 嵌入式场景：Claude Code 与 STM32 开发

Claude Code 的热度虽高，但很多教程集中在 Web 开发上。我特意在嵌入式场景试过一把，这大概是很多人没想到的用法。在 STM32 开发中，它最有价值的用法不是帮你写全部业务代码，而是帮你做三件事：解读寄存器手册、生成初始化代码框架、辅助排查编译链接报错。

比如你从 CubeMX 生成一个工程，想加一个定制的外设初始化代码，可以在项目里放一个精简过的芯片参考文档（注意版权和保密要求），然后让 Claude Code 读指定部分的文档并照此生成代码。它也可以帮你在遇到undefined reference这类链接错误时，快速检查对照的启动文件和链接脚本。

但这里有两个大坑要讲清楚。第一，嵌入式工程目录大、文件杂，千万别让它自己乱翻整个仓库，最好用 CLAUDE.md 限定它“只读哪个目录的代码”。第二，它生成的寄存器代码不一定适配你的芯片型号，凡涉及具体寄存器地址、时钟树配置的地方，务必自己对照参考手册复核一遍。我把它定位成“读手册加速器和骨架代码生成器”，而不是“最终审查者”。

5.2 高频报错的排查速查表

我在使用过程中整理了一张问题排查表，遇到问题先对照这个查，比乱搜关键词高效得多。

这张表之外还有一条我的经验：遇到任何“莫名其妙”的行为，先跑一次日志查看命令（官方一般会提供 diagnostics 相关指令），日志会把真实的错误原因显示出来，排查效率极高，别靠猜。

5.3 存储位置、更新与卸载

Claude Code 的配置文件通常存放在用户目录下的.claude文件夹，Windows 下一般是C:\Users\你的用户名\.claude，Linux 下是~/.claude。日志、历史会话、技能配置都在里面。如果你要备份环境，把这个目录打包带走就可以；如果你要彻底重置，删掉这个目录再重装即可。

升级命令很简单：

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

卸载则是对应的npm uninstall -g @anthropic-ai/claude-code。需要留意的是，卸载 npm 包不会自动清除~/.claude目录下的配置和日志，想彻底清干净，要手动把那个目录删掉。

另外，如果你在浏览器工作流里也用 Claude 系产品，请留意桌面版（desktop）和命令行版不是同一个东西：桌面版是带界面的独立客户端，CLI 才是我们这篇文章讲的终端工具。两者下载方式和支持范围不同，别下错。

6. 基于个人经验的最佳实践收尾

最后聊几句我的体会。CLI 类 AI 工具的上限，往往不取决于模型本身，而取决于你灌给它的上下文质量。Claude Code 里我最推荐花时间做的事，不是研究各种花哨命令，而是认真维护那个CLAUDE.md文件——把你项目的目录结构、构建命令、代码风格、常见坑一次写清楚。我见过很多人抱怨工具“不够聪明”，结果一看，项目里根本没有这个文件，或者写得非常敷衍。这个文件，相当于你给 AI 同事的第一天入职培训，值得认真对待。

另一个反复被验证有效的习惯是：让 Claude Code 在每次会话开始前先用一个命令回顾项目当前状态，比如让它在改代码前先git diff看清改动范围，而不是直接凭记忆动手。如果你发现它在改 A 文件时牵连了 B 文件，多半就是上下文缺少了“当前工作区状态”的感知。给它一个固定的检查节点，能少很多无意义的拉扯。

如果你也把 Claude Code 用在了实际项目里，我建议做两件事：一是把你们团队的CLAUDE.md和技能配置纳入版本控制，持续迭代，这是团队效率的真实积累；二是每个季度回头看一下你的实际用法，把用不上的预设规则移除，保持配置精简有效。AI 工具迭代快，技巧永远追不完，真正能留下的是你在使用过程中沉淀出来的那份判断力。