企业官网建设流程全解析

1. 为什么值得花一个下午把 Claude Code 跑通

我第一次接触 Claude Code 的时候，心态其实挺随意的——命令行里敲个claude，问两句，改个 bug，能有多难？结果真上手才发现，从安装、认证、项目初始化到第一次让它动我的代码，中间踩的坑比我想象的多得多。尤其是"让它改代码"这一步，很多人卡在权限确认、Git 状态、CLAUDE.md 配置这几个环节上，最后误以为"这工具不好用"，其实是流程没走对。

这篇东西就是把我自己从零到跑通第一次代码修改的完整路径写下来。核心关键词就几个：Claude Code、安装、代码修改、Git、CLAUDE.md。它解决的核心问题是——让一个命令行里的 AI 助手，安全、可控地读你的项目、改你的文件、跑你的命令，而你全程知道它在干什么。适合谁看？适合已经会基本命令行操作、装过 Node.js、用过 Git，但还没把 Claude Code 真正用起来的开发者。如果你连 Git 都没装过，别急，我在第 2 节会把前置环境一起带上。

我先把结论摆前面：Claude Code 的本质是一个跑在终端里的 agent，它不是一个聊天窗口，而是一个能读文件、写文件、执行 shell 命令的"操作员"。理解这一点，你后面所有的配置思路都会顺——你要做的不是"教它写代码"，而是"给它划好边界，让它在边界内自己干活"。这个认知差，是新手和老手最大的分水岭。

2. 装之前先把地基打好：环境与依赖清单

2.1 Node.js 与 npm 的版本要求

Claude Code 是通过 npm 分发的，所以 Node.js 是硬依赖。我实测下来，Node 18 是底线，Node 20 LTS 最稳。Node 16 及以下会直接报错，别浪费时间试。装 Node 的方式我推荐两种：

• 官网下载 LTS 安装包，一路下一步，最省心；
• 用 nvm（macOS/Linux）或 nvm-windows 管理多版本，方便以后切版本。

装完验证一下：

node -v npm -v

两条命令都能输出版本号，说明环境通了。这里有个小坑：Windows 上如果之前装过旧版 Node，PATH 里可能残留旧路径，导致node -v显示的版本和你以为的不一样。遇到这种情况，去"环境变量"里把旧路径删掉，重开终端。

2.2 Git 不是可选项，是必选项

很多人以为 Git 只是"用来提交代码的"，跟 Claude Code 没关系。错。Claude Code 大量依赖 Git 来做变更追踪和安全回滚——它改了什么文件、改了哪几行，靠的就是 Git 的 diff。如果你在一个没有 Git 初始化的目录里让它改代码，它会一直提醒你"当前不是 Git 仓库"，而且你也没法一键撤销它的改动。

Git 安装（Windows）：

# 官网下载 Git for Windows，安装时保持默认即可 # 安装完成后验证 git --version

macOS 一般自带，或者brew install git。Linux 用包管理器装就行。装完必须配置身份，否则第一次提交会报错：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

注意：这里的邮箱建议和你代码托管平台用的一致，不然提交记录会显示成"未知作者"，后面排查问题很麻烦。

2.3 一个干净的测试项目

我强烈建议不要一上来就在你正在维护的生产项目里试 Claude Code。新建一个空目录，git init，随便放几个文件，用它来练手。等你能熟练控制它的行为了，再放到真实项目里。这个习惯能帮你省下至少一次"它把我文件改乱了"的惊吓。

mkdir claude-demo && cd claude-demo git init echo "# demo" > README.md git add . && git commit -m "init"

到这里，地基就打好了。Node、Git、一个干净的 Git 仓库，三样齐活。

3. 安装 Claude Code：三种方式与各自的坑

3.1 全局 npm 安装（最主流）

这是官方推荐、也是我用得最多的方式：

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

装完输入claude看能不能起来。如果提示command not found，八成是 npm 全局 bin 目录没进 PATH。查一下：

npm config get prefix

把这个路径下的bin（Windows 是根目录）加到系统 PATH 里，重开终端即可。这个坑在 Windows 上尤其常见，因为 npm 全局目录默认不在 PATH 里。

3.2 项目内本地安装

如果你不想污染全局环境，可以在项目里装：

npm install @anthropic-ai/claude-code --save-dev npx claude

好处是版本跟着项目走，团队协作时大家用的版本一致。坏处是每个项目都要装一遍，占空间。我个人在正式项目里更倾向这种方式，因为版本可控这件事在团队里太重要了。

3.3 版本升级与降级

Claude Code 迭代很快，有时候新版反而有 bug。升级：

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

想锁死某个版本：

npm install -g @anthropic-ai/claude-code@1.x.x

实操心得：升级前先记下当前版本号（claude --version），万一新版出问题，能立刻回退。我吃过一次亏，新版改了权限确认的交互逻辑，我一时没适应，差点误操作。

3.4 首次启动与认证

第一次运行claude，它会引导你完成认证。整个过程是交互式的，跟着提示走就行。认证信息会存在本地配置目录里，之后不用重复登录。如果中途认证失败，最常见的原因是网络环境不稳定或者浏览器回调没成功，重试一次通常就好。

认证成功后，你会看到一个交互式界面，可以直接输入自然语言指令。到这一步，安装就算完成了。

4. 第一次对话：先让它"读"，别急着让它"写"

4.1 用只读任务建立信任

新手最容易犯的错，就是一上来就说"帮我把这个功能实现了"。正确做法是先让它做只读任务，观察它的理解能力。比如：

帮我梳理一下这个项目的目录结构，说明每个主要文件的作用

它会去读文件、给你一份总结。这个过程你能看出两件事：一是它读文件的范围对不对，二是它的理解准不准。如果连目录都读错，说明你的项目结构或者配置有问题，先解决这个。

4.2 理解它的工作循环

Claude Code 的工作方式是一个循环：理解任务 → 读取相关文件 → 提出方案 → 请求执行权限 → 执行 → 反馈结果。关键在"请求执行权限"这一步。它每次要改文件或跑命令，都会先问你。你可以选择允许一次、允许这个会话、或者拒绝。

这个设计是它的安全底线。我见过有人嫌麻烦，把所有权限都设成自动允许，结果它跑了一条rm命令把临时文件删了——虽然没造成大损失，但吓出一身汗。权限确认不要关，这是保命的。

4.3 第一次代码修改的完整流程

假设我们有个简单的 Python 文件calc.py：

def add(a, b): return a + b def divide(a, b): return a / b

我们让它加一个除法除零保护。指令可以这样写：

calc.py 里的 divide 函数没有处理除数为 0 的情况，帮我加上保护，除数为 0 时返回 None，并补一个简单的测试

接下来会发生什么：

1. 它读取calc.py，确认当前实现；
2. 它提出修改方案，展示 diff；
3. 它请求你确认是否写入；
4. 你确认后，它修改文件；
5. 它可能还会问要不要跑测试。

整个过程你能看到每一处改动。这就是"可控"的含义——你不是把代码交给它，而是和它一起改代码。

改完后，用 Git 看一眼：

git diff

确认改动符合预期，再决定提交还是回滚。这一步千万别省。

5. CLAUDE.md：让 AI 记住你的项目规矩

5.1 CLAUDE.md 到底是什么

CLAUDE.md是 Claude Code 的项目级配置文件，放在项目根目录。它会在每次会话开始时被自动读取，相当于给 AI 的一份"项目说明书"。你可以在这里写：项目用什么技术栈、代码风格要求、目录约定、常用命令、禁止事项等等。

为什么它重要？因为没有它，你每次都要重复解释一遍项目背景；有了它，AI 一进来就知道规矩，省下大量沟通成本。

5.2 一份实用的 CLAUDE.md 模板

# 项目说明 ## 技术栈 - Python 3.11 - 依赖管理用 pip + requirements.txt - 测试框架 pytest ## 代码规范 - 遵循 PEP 8 - 函数必须有 docstring - 禁止使用 print 调试，用 logging ## 常用命令 - 跑测试：pytest - 格式化：black . ## 禁止事项 - 不要修改 migrations 目录下的文件 - 不要直接改 requirements.txt，先问我

这份文件不用写得多漂亮，关键是把你踩过的坑写进去。比如你被某个目录的自动生成文件坑过，就明确写"不要动这个目录"。

5.3 分层配置：全局与项目级

Claude Code 支持多层配置：用户级（全局）和项目级。全局的放你个人的通用偏好，项目级的放这个项目特有的规矩。项目级优先级更高。我一般全局只放"回答用中文""改动前先展示 diff"这类通用要求，项目相关的全部放项目里的 CLAUDE.md。

注意：CLAUDE.md 会被提交到 Git 仓库，团队共享。所以别在里面写敏感信息，比如密钥、内部地址。这个坑我见过有人踩，把测试环境的账号密码写进去了，提交后才发现。

6. 权限、安全与 Git 的配合使用

6.1 权限模式的选择

Claude Code 有几种权限模式，从严格到宽松。我的建议是默认用最严格的，只在明确知道自己在干什么时才放宽。严格模式下，每次写文件、跑命令都要确认，虽然点得多，但安全。宽松模式适合你已经完全信任当前任务、且项目有 Git 兜底的情况。

6.2 用 Git 做安全网

这是我最想强调的一点：在让 Claude Code 改代码之前，确保工作区是干净的。

git status

如果显示有未提交的改动，先提交或者 stash。这样万一 AI 改乱了，一条命令就能回滚：

git checkout -- .

或者更精细地回滚单个文件：

git checkout -- calc.py

我自己的习惯是：每让 AI 完成一个独立的小任务，就提交一次。这样历史清晰，出问题也好定位。别攒一大堆改动一起提交，那样回滚粒度太粗。

6.3 敏感文件与目录的排除

有些文件你绝对不想让 AI 碰，比如.env、密钥文件、生产配置。可以在项目里配置忽略规则，或者在 CLAUDE.md 里明确写"禁止读取和修改 .env"。双保险更稳妥。

7. 常见问题与排查速查表

7.1 安装与启动类问题

7.2 使用过程中的典型问题

问题一：它读不到我的文件。通常是工作目录不对。Claude Code 是以你启动它的目录为根的，如果你在父目录启动，它看不到子目录里的细节。解决方法是cd到项目根目录再启动。

问题二：它改完代码后测试跑不过。先别急着怪它，用git diff看改动，很多时候是它改对了但你的测试本身有问题，或者它漏改了关联文件。把报错信息贴给它，让它继续修，通常两三轮就能收敛。

问题三：它反复问同样的问题。说明 CLAUDE.md 没写好，或者你的指令太模糊。把项目约定补进 CLAUDE.md，指令尽量具体到文件和函数。

问题四：改动范围超出预期。这是权限没控好。检查是不是开了自动允许，或者指令里说了"顺便优化一下"这种模糊要求。指令越具体，它越不会乱来。

7.3 我的独家避坑清单

• 永远在 Git 干净的状态下开始任务；
• 一次只让它做一件事，别把五个需求塞进一条指令；
• 改动后必看 diff，别闭眼确认；
• CLAUDE.md 里写清楚"禁止事项"，比写"要做什么"更重要；
• 遇到它理解偏差，别骂它，把上下文补全，它就能纠正。

8. 从"能用"到"好用"的几个进阶习惯

跑通第一次修改只是起点。真正让 Claude Code 发挥价值的，是把它嵌进你的日常工作流。我自己的做法是：把重复性任务（比如写测试、补类型注解、重构小函数）交给它，把需要判断力的任务（架构设计、复杂业务逻辑）留给自己。它是个执行力很强的助手，但不是决策者。

另外，善用它的"解释"能力。遇到不熟悉的代码，直接让它讲一遍，比你自己啃快得多。我经常用它来快速理解接手的老项目，效果很好。

最后说个细节：Claude Code 的会话是有上下文的，长会话会消耗更多资源，也容易让它"记混"。所以一个任务做完，开新会话，保持上下文干净。这个习惯能让它的表现稳定很多。

我在实际使用中最大的体会是：把它当成一个需要明确指令、需要边界约束、但执行力极强的初级工程师。你给它的信息越清晰、约束越明确，它的产出就越靠谱。反过来，模糊的指令加宽松的权限，就是灾难的开始。这个平衡点，得你自己在实操里慢慢找。