企业官网建设流程全解析

1. 为什么值得在终端里请一个"AI 结对工程师"

1.1 它到底解决了什么问题

先说一个最直接的观察：传统的 AI 代码补全工具，本质上是"你的光标旁边多了一个很会猜的输入法"。它擅长补全下一行代码、写一个函数体、生成一段模板代码。但当你面对的是一个几万行、十几万行的真实项目时，光靠补全远远不够——你需要的是有人能帮你"在代码海洋里找线索"：某个接口在哪里被调用、某个状态为什么会在特定路径下被错误更新、某个函数从哪个版本开始行为变了。这些事如果自己来，就是一遍又一遍的 grep、跳转、读文件、打日志，非常消耗耐心。

@anthropic-ai/claude-code 这个命令行工具解决的就是这个层面的问题。它不是一个挂在编辑器边上的小助手，而是一个能直接在你项目目录里跑起来的"终端 Agent"。它能读取你指定的文件、搜索整个目录、执行 shell 命令、运行测试、然后根据结果决定下一步做什么。换句话说，你把手头的任务用自然语言描述出来，它自己去代码里"现场取证"，再给你结论或者直接动手改。

我自己的体会是，这个工具最适合三类人：一是刚接手陌生项目、需要快速梳理代码结构的开发者；二是日常被重复性重构、补测试、改日志逼疯的"熟练工"；三是愿意尝试"让 AI 先干脏活、自己负责 review"这种协作方式的人。如果你只是想让它帮你写一个几百行的算法题解，那它可能并不比网页聊天框方便多少，但如果目标是"帮我对这个 monorepo 里的某个子项目做一次全面体检"，那体验是完全不同的。

1.2 它和"在网页上问 AI"到底差在哪

很多人一开始会有个疑问：我打开浏览器，把代码片段贴给 AI，它也能给我答案，为什么还要在终端里多装一个工具？

核心区别在于"上下文"和"行动力"。

网页聊天框里，你能提供的信息是有限的。你贴一段代码，它只能基于这段代码和你附带的描述来回答，一旦问题牵涉到其他文件里的定义、依赖包的行为、运行时输出，它就只能靠猜，或者你说一步它做一步。这就像请一个顾问远程指导，对方只能看到你拍照发过去的局部照片，剩下的全靠你口述。

Claude Code 的工作方式更像把一个实习生叫到工位旁边，它自己会去看代码、翻日志、跑命令、改文件。你只需要说"我怀疑订单金额在折扣计算这一步出了问题，帮我查一下整个调用链"，它会自己去搜索折扣相关函数、找到调用方、分析数据流向、然后给你一个完整的调查结论。这种"主动取证"的能力，是网页聊天框很难替代的。

当然，这种能力也带来了新的责任：你要给它权限、你要管理它的上下文长度、你要审查它的每一次改动。我用下来的态度是——把它当成一个能力很强但需要盯着的合作者，而不是一个只需要下命令的机器。这个概念理解透了，后面所有实操环节都会顺很多。

2. 5 分钟把 Claude Code 装好并完成认证

2.1 安装方式与版本选择

安装 @anthropic-ai/claude-code 最常用的方式是通过 npm 全局安装。Node.js 环境没问题的话，打开终端执行：

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

装完后验证一下版本：

claude --version

如果你不想全局安装，也可以用 npx 直接调用：

npx @anthropic-ai/claude-code

不过我实际测试下来，还是推荐全局安装。原因很简单：npx 每次启动都要先做包的解析和版本检查，在大型项目目录里会有可感知的启动延迟；全局安装之后 claude 命令是直接可用的，体感上更接近原生工具。它也有安装脚本方式，但 npm 这条路径最通用、最容易排查问题，对 Windows / macOS / Linux 三平台的支持都算稳定。

有一点需要留意：它的安装要求你的 Node.js 版本不能太老。官方要求通常是最新的 LTS 版本以上，如果你还在用比较旧的 Node，建议先升级再安装，否则运行时会直接报语法错误或者模块加载失败，到时候排查起来会很绕。我遇到过朋友拿 Node 14 跑，报了一堆莫名其妙的错误，最后发现只是版本兼容问题。

2.2 认证配置的两种方式

安装完成只是第一步，真正要让模型帮你干活，需要完成认证。目前常见的有两种方式。

第一种是 OAuth 登录。在终端里直接运行claude，首次启动时会提示你进行账号授权：终端里会弹出一个一次性验证码，浏览器打开授权页面、登录账号、粘贴验证码，回车确认就算完成。这个过程实现的是一次性设备授权流程，后续不需要反复登录。对于个人开发者来说，这是最省心的方式。

第二种是使用 API Key。如果你已经有一套 API 调用额度，或者需要在团队里做批量配置，可以通过环境变量ANTHROPIC_API_KEY来注入密钥。我一般在 shell 配置里这样设置：

export ANTHROPIC_API_KEY="sk-ant-你的密钥"

之后再启动 claude 就不会再走交互式登录了。这个方式的好处是隔离性好，密钥不进项目文件，也方便 CI 环境里的自动化调用。

注意：无论用哪种方式，我都建议不要把密钥硬编码到项目代码里，更不要提交到版本库。这是最基础的安全习惯，尤其在团队协作的项目里，一旦密钥泄露出去，影响范围很难控制。

2.3 一个"最小可用"配置检查清单

装好、认证完，先别急着干活，我建议用下面这套检查清单确认环境是健康的：

这套检查看起来简单，但真的能排查掉一大半"装好了却用不起来"的情况。我遇到最多的两类问题：一是版本过旧导致命令不存在；二是认证信息没写对，启动的时候反复弹授权页。走一遍检查清单，基本就能定位到问题出在哪个环节。

3. 核心交互方式与日常任务实战

3.1 三种不同层级的用法

Claude Code 的交互方式不是只有"一问一答"一种，它实际上可以分为三个层级，你按任务复杂度选用。

第一层是"直接问"。适合快速了解代码：这个函数是干什么的、这个报错为什么会出现、某个依赖为什么会打进产物。它带着项目上下文回答问题，准确率远比贴一段代码给网页聊天框要高。我经常拿它当"能理解整仓库的 grep 加强版"来用，定位问题效率非常可观。

第二层是"指令型"。你让它执行一个明确的任务，比如"帮我给这个模块补上单元测试""把这个函数拆成两个更小的函数""把所有 console.log 换成统一的日志方法"。它会读取相关文件、做出修改、然后给你一份改动摘要。这个过程中，每一步工具调用会先征求你的确认（取决于权限设置），你同意后它才会写入文件。

第三层是"Agent 型"。你给它一个更大的目标，比如"修复登录超时的问题"。它会拆解步骤：先搜 token 刷新逻辑、检查 API 超时配置、试图定位根因、然后改代码、甚至自动跑测试验证。这个层级最接近"AI 工程师"的形态，但也最考验你的掌控力——后续章节我会专门讲怎么避免它失控。

3.2 Slash 命令速查

进入交互界面后，有些以/开头的内置命令会频繁用到。我把它们的功能整理成了一个速查表：

这些命令不需要刻意背，用得多了自然就记住了。对我日常使用频率最高的其实是/clear和/compact这两个——原因后面讲上下文管理时会细说。

3.3 实操：让 Claude Code 给你的项目做一次"体检"

下面用一个我实际跑过的场景来展示完整流程。假设我要接手一个别人留下的"某跨平台系统"模块，代码结构混乱、没有文档、测试几乎为零。我的第一步不是自己读代码，而是让 Claude Code 先扫描一遍。

进入项目目录后启动 claude，然后输入：

请对这个项目做一次初步体检，重点了解： 1. 项目的整体模块划分和目录结构 2. 核心入口文件与启动流程 3. 哪些模块存在明显的重复代码或坏味道 4. 当前是否已有测试，测试覆盖了哪些部分 请给出一个结构化报告，不要修改任何文件

它会自动执行一系列命令来探查项目，比如列出目录、读取关键配置文件、搜索 TODO、统计测试文件数量，然后汇总成一份报告。这个过程通常只需要一两分钟，而同样的事情如果我自己做，光是把整个项目结构摸一遍就要小半天。

拿到它的报告之后，我会继续追问细节，比如"把重复代码最严重的那个模块列出来，分析它和另一个模块的区别"。这样一层一层往下钻，陌生项目的熟悉速度会快很多。重要提醒是：这个阶段明确加上"不要修改任何文件"这句话，让它在"只读模式"下工作。因为体检阶段的重点是把情况搞清楚，而不是让它顺手改东西——一旦它开始改，你很难判断哪些改动是必要的。

/init也很适合放在这一步使用。跑完体检后执行/init，它会把项目结构、常用命令、代码规范等总结写入 CLAUDE.md 文件，这个文件后续会成为整个会话的长期记忆基础。这个方法在"接手陌生项目"场景下几乎是无脑收益，强烈建议试一试。

3.4 权限模型：不是每条命令都会自动执行

Claude Code 和你的本地项目是有真实交互能力的，这既是优点也是风险来源。默认情况下，它执行 bash 命令或修改文件之前会向你确认，具体确认方式取决于权限配置。

我把常用权限策略整理成三类：

• 默认确认制：每个写操作都会弹确认，最安全，适合刚开始使用还不熟悉它行为的时候。
• 允许编辑、命令确认：允许它直接改文件，但运行命令前仍需确认。我个人最推荐的折中方案，兼顾效率与安全。
• 完全自动：所有操作基本不确认，适合在沙盒环境、CI 或一次性任务中跑，日常开发中我很少用。

设置位置在/permissions里。你可以针对不同命令类型设置规则，比如允许它无确认执行npm test，但git push必须确认。这套机制本质上就是"给它画一个围栏，告诉你哪些区域可以自行走动，哪些必须先喊我一声"。

我踩过的坑是：初学时为了省事把权限全放开，结果有一次它在跑测试的时候顺手把我的本地数据库迁移脚本给执行了，差一点把开发数据清掉。从那以后我老老实实把危险命令全部设为"必须确认"，尤其是涉及删除、重置、访问 credential 相关操作的命令。记住一个原则：权限给得越宽，你盯 review 的精力就得给得越足。

4. 让项目"记住"你：CLAUDE.md 与配置体系

4.1 CLAUDE.md 是给 Agent 看的项目管理手册

Claude Code 每次启动时会自动加载项目的 CLAUDE.md 文件，把它作为理解项目的重要依据。这个文件玩得好，整个工具的表现会提升一个档次。

我的理解是，CLAUDE.md 就是"给 AI 同事看的入职手册"。你可以告诉它：这个项目的目录结构是什么样的、常用的构建和测试命令是什么、代码规范有哪些红线、哪些目录绝对不能动、测试应该怎么写。它会在每次会话中参考这些信息，避免反复犯同样的错误。

一个典型的 CLAUDE.md 可能长这样：

# 项目概述 这是一个前后端分离的跨平台应用，前端使用 React，后端使用 Node.js。 # 常用命令 - 启动开发环境：npm run dev - 运行测试：npm test - 构建生产包：npm run build # 代码规范 - 组件文件使用 TypeScript，无特殊理由不允许使用 any - 所有网络请求必须通过 src/api 下的统一封装 - 新增环境变量必须同步更新 README.md # 绝对不要做的事 - 不要修改 database/migrations 目录下已发布的迁移文件 - 不要直接编辑 dist 目录中的文件 - 不要删除 public/assets 下的任何文件

有了这个文件之后，它给出的方案和代码风格就会有明显的"契合项目规范"的感觉，而不是泛泛的通用建议。尤其在你接手一个多模块的复杂项目时，这个文件的价值会被放大数倍。

4.2 常用环境变量与配置项

除了 CLAUDE.md 这种项目级配置，还有一些环境变量和运行参数值得了解。下面列出我实际用过且有明确收益的几项：

--ignore是我个人非常依赖的一个选项。在一个大型 monorepo 里，如果不加任何排除，它会尝试理解所有子包，上下文很快被无关文件占满，响应速度明显下降。我通常会在启动时忽略掉依赖目录和构建产物目录，让它把有限的上下文精力花在真正的源码上，实测效果非常明显。

4.3 MCP 与外部工具扩展

如果你对基础配置已经熟练，下一步值得关注的是 MCP 扩展机制。通过它，你可以给 Claude Code 接上更多的"外部工具"，让它能查询数据库、读取浏览器页面、搜索内部文档等。

我身边用得比较多的是把数据库 schema 接入进来，让它在分析数据相关 bug 时能直接看到表结构和索引情况，而不是靠猜。这个能力有点像给它装上一双"能看到更多现场"的眼睛，能显著提高它在特定场景下的判断准确性。

不过 MCP 的配置本身有一定学习成本，而且每加一个工具都要考虑权限边界，我建议在把基础用法跑顺之后再考虑，不要一上来就贪多。

5. 常见问题与排查技巧实录

5.1 认证失败与请求超时

我遇到过最多的认证问题，通常表现为：启动后反复弹出登录提示，或者输入内容后长时间没有响应。排查时先跑一遍/doctor，它能检查环境变量、登录状态和基本配置是否正常。

如果显示认证异常，先确认ANTHROPIC_API_KEY是否设置正确，再看账号的 API 额度是否用完。环境变量设了但没生效也是个常见坑——终端环境变量改了之后，需要新开一个终端窗口才能让 claude 读取到，很多人在这里卡了半天。

另一个常见表现是请求超时。Claude Code 需要访问国际 API 服务，所以对网络连通质量有要求，波动时容易出现"连接被重置"或"响应超时"的报错。遇到这种情况，我一般先确认自己机器的外网访问是否正常，再看是否需要换个网络环境重试。这个问题没有一劳永逸的解法，只能尽量保证网络稳定、失败后重试，同时把任务拆小，避免长时间单次请求。

5.2 上下文满了、费用超了怎么办

这是一个使用终端 AI Agent 时绕不开的现实问题：上下文窗口是有限的，长会话一定会撞到上限。

我自己的使用习惯是：一个会话只围绕一个任务进行。如果这个任务做完了，立刻/clear开新会话；如果任务还在继续，但明显感觉到它开始"忘事"或者回答质量下降，就用/compact压缩一下对话历史。这两个命令是长会话的续命神器，记住它们基本能处理 80% 的上下文问题。

费用方面，我会在任务进行中不定期用/cost看一眼 token 消耗。如果一个大型重构任务花费明显超出心理预期，就该停下来重新评估方案，而不是让它继续"试错式"地改代码。大型代码库中，启动时用--ignore排除无关目录、主动通过/add-dir限定工作范围，都是很有效的省钱手段。

还有一个小技巧：如果你只是临时问一个小问题，不要开着大项目会话问，工作量完全不成比例，成本会无谓地升高。

5.3 它改错文件了怎么办

任何 AI Agent 都有理解错意图的可能，Claude Code 也不例外。我的处理原则很简单：让它改动前先建立"检查点"。

具体做法分三步。第一，在它动手之前，先把当前分支的 git 状态拍个快照，确保所有改动都是可回滚的。第二，大改动前明确要求它先输出计划，你确认后再执行；从我的经验看，这个"先计划后动手"的机制能拦截掉大量不合适的改动。第三，每次改动后自己git diff看一眼核心文件的差异，不要完全放心地把代码交给它。

如果发现它改错了文件，直接用 git 回退即可。养成"随时提交、频繁 review"的习惯之后，这个风险完全是可控的。真正危险的场景是项目不在 git 管理下——那我就建议你先git init再让 AI 进场。

5.4 问题排查速查表

最后整理一个我在实际使用中沉淀下来的排查表，遇到相似症状可以直接对照处理：

这些坑基本上是我自己一步步踩过来的。工具本身的设计逻辑并不复杂，真正决定它好用不好用的，往往是你愿不愿意花时间建立一套适合自己的"约束和流程"。

我个人现在的固定工作流是：进入项目后先/init建立 CLAUDE.md（如果还没有的话），然后让它在具体任务上"先出方案、再小步执行、每次改动后我 review diff"。这套流程在几个真实项目里跑下来，既有速度又有安全感。如果你也打算试，建议第一周刻意把权限收紧一点，多观察它的行为模式，找到那个"信任边界"之后，再逐步放宽。最后分享一个小习惯：我在开一个重要任务的会话前，会把目标写成一个简短的TASK.md放在项目目录里，然后让 Claude Code 先读这个文件再开工。就这一点小小的变化，比直接在对话框里随手描述任务要有效得多，推荐你试试。