企业官网建设流程全解析

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

第一次听说 Claude Code 的时候，我正被一个祖传项目折磨得够呛——三千多行的老代码，注释比代码还少，改一个字段要翻七八个文件。当时我的第一反应是：命令行里跑 AI 改代码，听着挺酷，但真能干活吗？折腾了一个下午把它装好、配好、跑通第一次代码修改之后，我的结论是：这东西对"读代码"和"小步修改"这两件事的效率提升是实打实的，但它不是魔法，你得先理解它的工作方式，才能用得顺手。

这篇内容面向的是完全没接触过 Claude Code 的开发者，或者装了一半卡在某个报错上的人。我会从环境准备讲起，一路走到"让它帮你改完第一处代码并提交 Git"，中间所有我踩过的坑、绕过的弯路都会写清楚。核心关键词包括 Claude Code、安装、代码修改、Git、CLAUDE.md，这几个词基本串起了整个入门链路。

先说清楚它是什么。Claude Code 是一个运行在终端里的编程助手，它和你在网页上聊天的那种 AI 最大的区别在于：它能直接读写你本地的文件、执行命令、跑测试、操作 Git。你告诉它"把用户模块里的手机号校验改成支持国际区号"，它会自己去找到相关文件、读懂上下文、改代码、然后告诉你改了哪些地方。这种"能动手"的能力，是它和普通对话式 AI 的分水岭。

那为什么需要先装一堆东西？因为 Claude Code 本质上是跑在 Node.js 环境里的一个命令行工具，它依赖 Git 来做版本管理和差异对比，依赖一个像样的终端来交互。所以安装路径基本是：Node.js → Git → Claude Code → 配置 → 第一次实战。下面我按这个顺序拆开讲，每一步都会说明"为什么需要它"，而不是干巴巴地甩命令。

2. 装之前先把地基打好：Node.js 与 Git 的安装细节

2.1 Node.js 版本选择与安装方式

Claude Code 对 Node.js 有版本要求，太老的版本会直接报错。我的建议是直接上 LTS（长期支持）版本，写这篇内容时对应的是 18 以上的版本，稳妥起见选 20 或更高。为什么强调版本？因为我在一台老机器上用过 Node 16，安装 Claude Code 时 npm 直接抛出一堆依赖解析失败，折腾半天才发现是版本太低。

安装方式分两种，看你系统：

• Windows：去 Node.js 官网下载 LTS 的.msi安装包，双击一路下一步即可。安装完打开 PowerShell 或 CMD，输入node -v和npm -v，能打印出版本号就说明成了。
• macOS：推荐用 Homebrew，brew install node，干净利落。如果你没装 Homebrew，也可以直接下.pkg安装包。
• Linux：用 nvm 管理版本最省心，nvm install 20 && nvm use 20，避免和系统自带的旧 Node 打架。

提示：Windows 用户如果之前装过 Node，建议先卸载干净再装新版，残留的全局 npm 包有时会引发奇怪的路径冲突。

装完之后有个容易被忽略的点：npm 的全局安装目录最好确认一下在 PATH 里。Windows 上默认是%APPDATA%\npm，macOS/Linux 上通常是/usr/local/bin或 nvm 管理的目录。如果后面claude命令提示"不是内部或外部命令"，八成就是这里没配好。

2.2 Git 安装与最小必要配置

Git 是 Claude Code 的另一个硬依赖。原因很直接：Claude Code 在修改代码前后会依赖 Git 来追踪差异，你也能随时用git diff看它到底动了什么。没有 Git，它的很多能力会打折扣。

安装同样分平台：

• Windows：下载 Git for Windows，安装时有个选项叫"Adjusting your PATH environment"，选默认的"Git from the command line and also from 3rd-party software"就行。装完会附带一个 Git Bash，后面很多操作在 Git Bash 里做会更顺。
• macOS：brew install git，或者装 Xcode Command Line Tools 时自带。
• Linux：sudo apt install git或对应发行版的包管理器。

装完必须做两件事，否则第一次提交会卡住：

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

这两行配置决定了你每次 commit 的作者信息。我见过有人跳过这步，结果 Claude Code 帮忙改完代码要提交时，Git 直接报"请告诉我你是谁"，一脸懵。

另外建议顺手配一下默认分支名和换行符处理：

git config --global init.defaultBranch main git config --global core.autocrlf input

core.autocrlf input在跨平台协作时能避免大量"整个文件都变了"的假差异，这个坑我在 Windows 和 Linux 混合团队里踩过不止一次。

2.3 验证环境是否就绪

在装 Claude Code 之前，先跑一遍检查：

node -v npm -v git --version

三个命令都能正常输出版本号，说明地基打好了。如果npm -v报错，多半是 Node 装歪了；如果git --version找不到命令，就是 PATH 没配好。这一步别嫌麻烦，环境问题越早发现越好解决。

3. 安装 Claude Code 并完成首次认证

3.1 全局安装与常见报错处理

环境就绪后，安装本身只有一行命令：

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

-g表示全局安装，这样在任何目录下都能直接敲claude调用。安装过程会拉取依赖，网速正常的话一两分钟搞定。

但这一步是报错重灾区，我整理了几个高频问题：

权限问题在 macOS 上尤其常见。很多人第一反应是加sudo，但用sudo npm install -g会带来后续一堆权限混乱。正确做法是把 npm 的全局目录改到用户目录下：

mkdir ~/.npm-global npm config set prefix '~/.npm-global' export PATH=~/.npm-global/bin:$PATH

最后那行 export 记得写进.bashrc或.zshrc，否则重启终端就失效了。

3.2 认证流程与订阅状态确认

安装完成后，在终端输入claude，它会引导你完成认证。通常是通过浏览器登录账号、授权，然后终端会拿到一个凭证。整个过程跟着提示走就行。

这里有个热词里提到的典型问题值得单独说：your organization has disabled claude subscription access for claude code。这个提示的意思是，你所在的账号组织关闭了 Claude Code 的访问权限。遇到这个不是安装问题，而是账号权限问题，需要联系组织管理员，或者换一个个人账号。别在这个报错上反复重装，方向错了。

认证成功后，终端会进入 Claude Code 的交互界面。第一次进去建议先敲个/help看看有哪些命令，再敲/status确认当前登录状态和可用模型。这一步花两分钟，能让你后面少走很多弯路。

3.3 在 VS Code 里使用 Claude Code

很多人习惯在 VS Code 里干活，不想来回切终端。Claude Code 可以很好地和 VS Code 配合：直接在 VS Code 内置的终端里运行claude就行，它会自动感知当前打开的项目目录。

如果你想要更紧密的集成，可以装对应的 VS Code 扩展，这样能在编辑器侧边栏直接对话。不过我的经验是，内置终端方案已经够用，而且更稳定——扩展偶尔会有版本兼容问题，终端方案基本不会出幺蛾子。

注意：在 VS Code 终端里跑 Claude Code 时，确保终端的工作目录是项目根目录，否则它读文件会找错地方。

4. 第一次代码修改：从读懂项目到提交 Git

4.1 选一个合适的练手项目

别一上来就拿生产环境的核心项目开刀。我的建议是找一个你自己写的、规模不大的项目，或者 clone 一个开源小项目来练手。为什么？因为第一次使用你需要建立信任感，得能看懂它改了什么、判断改得对不对。项目太大、太陌生，你根本没法验证它的输出。

进入项目目录，先确认这是个 Git 仓库：

cd your-project git status

如果提示"not a git repository"，就git init初始化一下。Claude Code 在有 Git 的环境里工作得最顺，因为它能随时对比改动。

4.2 用自然语言下达第一个修改指令

启动 Claude Code：

claude

然后你就可以用大白话提需求了。比如项目里有个函数把日期格式化成了YYYY/MM/DD，你想改成YYYY-MM-DD，直接说：

把项目里所有日期格式化的分隔符从斜杠改成短横线，改完告诉我动了哪些文件。

它会先搜索相关代码、读取文件、理解上下文，然后给出修改方案。这里有个关键习惯：先让它说清楚打算怎么改，再让它动手。你可以追问"你准备改哪几个文件？每个文件改什么？"，确认无误后再让它执行。这个"先看方案再执行"的节奏，是安全使用 Claude Code 的核心。

4.3 看懂它改了什么：git diff 是你的安全带

改完之后，别急着相信。立刻跑：

git diff

这个命令会逐行显示所有改动，新增的行前面是+，删除的是-。你要重点看三件事：改的地方对不对、有没有误伤无关代码、有没有引入明显的逻辑错误。

我踩过的一个坑是：让它改一个变量名，结果它顺手"优化"了旁边一段它认为冗余的代码，虽然没报错，但改变了原有行为。所以git diff必须逐段过一遍，尤其是它主动做的"额外改动"。

如果发现改错了，回退很简单：

git checkout -- .

这会把所有未提交的改动丢弃，回到干净状态。所以养成习惯：在让 Claude Code 动手前，确保工作区是干净的，这样出问题一键回退，不会牵连你之前没提交的工作。

4.4 提交这次修改

确认改动没问题后，提交：

git add . git commit -m "将日期格式化分隔符改为短横线"

你也可以让 Claude Code 帮你生成 commit message，它读得懂 diff，写出来的信息通常比手写的还规范。但提交这个动作我建议你自己确认后再做，别让它自动提交——提交历史是你的项目档案，值得亲自把关。

5. CLAUDE.md：让 Claude Code 真正懂你的项目

5.1 CLAUDE.md 是什么，为什么必须有

用了几次之后你会发现一个问题：每次新开一个会话，Claude Code 对你的项目一无所知，你得反复交代"这个项目用的是什么框架""测试怎么跑""代码风格是什么"。CLAUDE.md 就是解决这个问题的——它是放在项目根目录的一个 Markdown 文件，Claude Code 每次启动会自动读取它，相当于给 AI 的一份项目说明书。

这个文件的价值在于"一次编写，长期受益"。你把项目约定写进去，后面所有会话都自动遵守，不用重复解释。热词里专门提到 CLAUDE.md，说明这是入门阶段最该掌握的一个概念。

5.2 一份实用的 CLAUDE.md 该写什么

不用写得多华丽，覆盖这几块就够用：

# 项目说明 ## 技术栈 - 后端：Python 3.11 + FastAPI - 前端：React 18 + TypeScript - 数据库：PostgreSQL 15 ## 常用命令 - 安装依赖：pip install -r requirements.txt - 跑测试：pytest tests/ - 启动开发服务：uvicorn main:app --reload ## 代码规范 - Python 遵循 PEP 8，用 black 格式化 - 提交信息用中文，格式：动词 + 对象 - 新增函数必须写 docstring ## 注意事项 - 不要修改 migrations 目录下的历史文件 - 敏感配置放在 .env，不要硬编码

这份文件的关键是"具体"。写"遵循代码规范"没用，写"用 black 格式化、函数必须写 docstring"才有指导意义。命令部分尤其重要，写清楚了 Claude Code 就能自己跑测试验证改动，形成闭环。

5.3 让 Claude Code 帮你生成初版 CLAUDE.md

如果你懒得从零写，可以直接让它生成。在项目根目录启动 Claude Code，输入：

阅读这个项目的结构和配置文件，帮我生成一份 CLAUDE.md，包含技术栈、常用命令、代码规范和注意事项。

它会扫描项目、读 package.json 或 requirements.txt、看目录结构，然后产出一份初稿。你在此基础上删改补充即可。这个"让 AI 写说明书给 AI 看"的操作，实测下来能省不少事，而且它发现的一些项目细节，可能连你自己都忘了。

6. 几个让效率翻倍的实操习惯

6.1 小步快跑，别一次提大需求

新手最容易犯的错，是一上来就提"帮我重构整个用户模块"。这种大需求它也能做，但改动面太大，你根本没法逐行验证，出了问题也难定位。正确做法是把大任务拆成小步骤：先改数据模型，验证；再改业务逻辑，验证；最后改接口，验证。每一步都git diff确认，每一步都可回退。这种节奏看起来慢，实际上因为返工少，总体更快。

6.2 善用会话上下文，但别让它无限膨胀

Claude Code 在一次会话里会记住之前的对话和它读过的文件，这是好事，你可以连续追问。但会话太长之后，它的响应会变慢，而且容易"记混"。我的习惯是：一个独立的任务开一个新会话，任务做完就退出。这样每次上下文都干净，它也不会被无关信息干扰。

6.3 遇到它"卡住"时怎么办

有时候它会反复尝试同一个错误方案，或者对某个报错束手无策。这时候别干等，主动介入：把完整的报错信息贴给它，或者直接告诉它"换个思路，试试用 XX 方法"。它本质是个工具，你是主导者，卡住了就给它更多信息或更明确的指令，比让它自己瞎撞高效得多。

6.4 关于本地模型和远程模型的取舍

热词里有人问能不能让 Claude Code 调用本地模型。技术上通过配置是可以对接兼容接口的本地服务的，但我的实测体会是：本地小模型在"读懂复杂项目上下文"这件事上和云端大模型差距明显，改简单脚本还行，改真实项目容易给出似是而非的方案。入门阶段建议先用官方默认配置把流程跑顺，等熟悉了它的工作方式，再考虑折腾本地模型的事。

7. 我踩过的那些坑，你可以直接跳过

第一个坑是在错误的目录启动。有次我在用户主目录敲了claude，结果它把整个主目录当成了项目，搜索文件时慢得要命，还差点读到无关的敏感文件。记住：永远先cd到项目根目录再启动。

第二个坑是没配 Git 就让它改代码。没有 Git，它改完你没法对比差异，出了问题也没法回退，等于裸奔。所以 Git 不是可选项，是必选项。

第三个坑是盲目相信它的输出。它偶尔会"自信地"给出错误方案，尤其是涉及具体业务逻辑时。它不了解你的业务规则，只能根据代码字面意思推断。所以业务相关的改动，一定要人工把关。

第四个坑是CLAUDE.md 写得太笼统。我第一版就写了句"注意代码质量"，结果它该咋样还咋样。后来改成具体的命令和规范，效果立竿见影。这个文件的质量，直接决定了它在你项目里的表现。

第五个坑是认证状态过期没察觉。用了一段时间后突然所有请求都失败，排查半天发现是登录凭证过期了。敲/status一看便知，重新认证即可。养成定期看一眼状态的习惯，能省下不少无谓的排查时间。

把上面这套流程走一遍，你基本就跨过了 Claude Code 的入门门槛。剩下的就是多用、多总结，慢慢摸清它在哪些任务上靠谱、哪些任务上需要你多盯着。工具是死的，用工具的思路是活的，这个道理在 AI 编程助手这里体现得尤其明显。