企业官网建设流程全解析

第一次用 Claude Code 的时候，我的第一反应是：这不就是个跑在终端里的聊天框吗？直到我让它去改一个跨了十几个文件的字段重命名，它自己翻完了整个代码仓库，顺带改了测试、跑了 lint，最后还把改动整理成了几个干干净净的 commit，我才意识到，这东西跟网页上那些对话式 AI 完全不是一回事。Claude Code 是 Anthropic 推出的终端 AI 编程工具，但把它理解成“能写代码的 AI”就太亏了。真正拉开差距的地方在于它的记忆机制、子代理和 Skills 体系，能让你像管理工作团队一样去管理它——每个人负责什么、遵守什么规范、输出什么产出物，全都可以通过配置来控制。

这篇内容我围绕 Claude Code 配置展开，结合我在真实项目里的使用经验，把搭建一支“AI 工程团队”的完整思路、实操步骤和踩过的坑都过一遍。不管你是刚装好 Claude Code 的新手，还是已经在用但觉得“这 AI 怎么总不听话”的进阶用户，应该都能拿到一些能直接落地的东西。

1. 为什么说 Claude Code 是一支可以配置的“AI 工程团队”

1.1 从“聊天助手”到“协作者”的范式变化

大多数人对 AI 编程的认知还停留在“对话框里提问，旁边飘代码建议”。这种模式解决的是单点问题：某个函数怎么写、某个报错怎么解。但真实项目里，需求很少是单点的。改一个字段可能要牵连数据库脚本、接口定义、前端类型、测试用例和线上文档，这时候对话式助手的劣势就暴露了——它看不见全局。

Claude Code 解决问题的思路完全不一样。它不是“你问我答”，而是以你的终端为工作台，以整个项目作为上下文。它能读取目录结构、搜索关键代码、同时打开多个文件进行修改，还能直接执行命令并读取输出结果。说白了，它具备了一个真实工程师在本地开发时的完整闭环：读代码、改代码、跑命令、看结果、根据结果再调整。

我常用一个类比：Copilot 这类工具像是一个打字很快的副驾驶，你说一句它补一句；而 Claude Code 更像是一个能独立接任务的协作者，你给它目标，它会自己去查资料、写方案、动手改、跑测试，最后回来向你汇报。这种从“补全”到“执行”的转变，就是 agent 范式的核心。配置做得好，它能替代的就不只是“手写代码”这一环节。

1.2 把 AI 能力映射成团队里的不同岗位

既然说它是“工程团队”，我们就得先想清楚团队里有哪些角色。配置 Claude Code 之前，我强烈建议你先做一次“岗位盘点”，想明白自己需要它扮演什么。下面这张表是我自己项目里的映射思路：

这个映射的价值在于：你在使用的时候不再只把它当“写代码的人”，而是有意识地分派任务。比如重构之前，我会先让它做架构分析；改完之后，我会让它进入“审查者”模式，只提问题不动手。这种角色意识能让你的使用方式从“乱枪打鸟”变成“按流程协作”，而后面要讲的 Subagents、Skills、CLAUDE.md，本质上都是为了让这些角色能稳定复现。

1.3 和代码补全类工具的差异在哪里

很多刚接触的人会问：我现在的 IDE 里已经有 AI 补全了，为什么还要折腾一个命令行工具？我的答案很直接：补全工具优化的是“写”的效率，Claude Code 优化的是“做完一件事”的效率。

补全工具的场景是：你正在敲键盘，它预测你的下一步。但代码写完之后还有大量工作——编译报错怎么办、测试挂了怎么办、这个接口改了调用方要不要跟着改、代码风格符不符合团队规范。这些工作在传统流程里靠的是人肉经验，而 Claude Code 可以通过配置把这些经验固化下来。

比如我有个项目里约定，所有对外暴露的接口必须有单元测试，否则合并请求不允许通过。以前这个靠 code review 人来盯，现在我在配置里写明“每次改动完成后必须检查对应测试是否存在，缺失就补上”，它就会在交付代码时主动检查。这种“把规范变成执行动作”的能力，是补全类工具不具备的。这也是配置 Claude Code 和配置一个普通插件最本质的区别：你配置的不是快捷键，而是一整套协作流程。

2. 环境准备：把地基打好再谈“组建团队”

2.1 先搞定 Node.js 和 Git 两个基础依赖

Claude Code 是一个基于 Node.js 的 CLI 工具，所以环境准备第一步不是安装它本身，而是把 Node.js 装好。这里我直接给结论：建议使用 Node.js 18 及以上版本，太老的版本会遇到 API 兼容性问题，报一些莫名其妙的错。装完之后打开终端确认一下：

node -v npm -v

输出里能看到 v18.x 或更高版本就说明 Node 环境没问题。如果你电脑上还没有 Node.js，去官网下载 LTS 版本安装包，一路下一步就好。这里提醒一句：装完之后记得重新打开终端，否则 PATH 环境变量可能不会生效，命令行里会提示“node 不是内部或外部命令”。

Git 也建议提前配好。虽然 Claude Code 不强制要求依赖 Git 才能运行，但它的很多高级功能，比如生成 commit 信息、查看改动记录、按 diff 审查代码，都需要 Git 作为底层支撑。配置用户名和邮箱是很多人容易漏掉的一步：

git config --global user.name "your-name" git config --global user.email "your-email"

如果你平时用 IDE 内置的 Git 工具，可能从来没配过这两项，但终端里跑 Claude Code 时会遇到 commit 失败的问题。提前配好，省得后面一脸懵。

2.2 安装 Claude Code 并完成首次登录授权

基础环境就绪后，安装本身其实非常简单，一条全局 npm 命令就能搞定：

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

安装完成后验证一下版本号，然后进入你的项目目录，直接运行：

claude --version cd your-project claude

首次启动会进入一个授权流程，需要你登录 Anthropic 账号并授权。授权方式有两种：一种是使用订阅账号直接登录，另一种是配置 API Key。两者的区别在于，订阅登录适合个人开发者在自己的主力机上用，计费走订阅额度；API Key 适合自动化脚本、CI 流程或多人共享环境，便于按量控制成本。

授权完成之后，Claude Code 会在你的用户目录下创建一个.claude文件夹，里面存放全局配置、日志和认证信息。这时候我建议你干一件事：把claude --version的输出和安装时间记录到项目文档里。听起来有点多余，但 Claude Code 更新非常频繁，遇到行为变化时，能第一时间判断是“配置问题”还是“版本升级带来的变化”。

提示：不要在多个终端窗口同时执行首次授权流程，登录状态写入会互相覆盖，可能造成“已登录但请求始终失败”的假象。

2.3 在 VSCode 里把 Claude Code 用顺手

Claude Code 的本质是终端工具，所以 VSCode 里最佳的使用方式不是找插件，而是直接用内置终端跑claude。我会把终端面板固定在编辑器右侧，左边是代码，右边是 Claude Code 的工作窗口，它改文件、跑命令，我实时看代码变化。这种双栏布局比来回切窗口舒服很多。

还有一个小配置值得做：在.vscode/settings.json里把 Claude Code 会用到的命令加入终端的“允许运行”列表，避免每次执行都弹一次权限确认。当然，这是在你已经信任当前项目的前提下。第一次使用时我建议保持默认的严格模式，观察一下它到底会执行哪些命令，再逐步放开权限，这样心里有底。

如果你希望 Claude Code 能和终端本身有更深度的集成，比如通过快捷键唤起，可以在 Claude Code 交互界面输入：

/terminal-setup

这个命令会检测你当前的 shell 环境并自动写入集成脚本。集成之后，你可以在普通终端里通过快捷键直接唤起 Claude Code，甚至把它接到 Git 的某些操作上。这一步不是必须的，但对高频使用者来说，能省掉每次输入claude再等启动的重复操作。

3. 团队记忆与项目规则：用 CLAUDE.md 统一“三观”

3.1 全局记忆和项目记忆各放哪里

Claude Code 最核心的配置机制就是 CLAUDE.md 文件。你可以把它理解为“团队手册”——每次会话开始，Claude 都会自动读取这个文件，把它当作自己的背景知识，所有后续操作都基于这份约定执行。

按作用范围不同，CLAUDE.md 可以放在三个层级：

• 全局层：放在~/.claude/CLAUDE.md，对所有项目生效。适合写通用的编码偏好，比如“提交信息用 Conventional Commits 规范”“不要修改锁文件”。
• 项目层：放在项目根目录的CLAUDE.md，只对当前项目生效。适合写项目技术栈、目录结构、构建命令、特殊约定。
• 子目录层：放在任意子目录下，Claude 在读取该目录下文件时会被触发。适合给大型 monorepo 的每个子模块单独定义规则。

层级之间不是互斥关系，而是叠加。Claude 会优先读取更具体的配置，但对于冲突的信息，项目根目录的配置通常拥有更高解释权。我实际用下来的经验是：全局文件里只放你自己最不能忍的原则，项目文件里放跟这个项目强相关的知识，别把两层写重了，否则后期维护会遇到“改了一处忘了另一处”的问题。

3.2 写出一份高可用 CLAUDE.md 的经验结构

很多人第一次写 CLAUDE.md 会走两个极端：要么只写两行“你是我的编码助手”这种废话，要么写了个几千字的大全，结果 Claude 每次都要消耗大量上下文去读规则，反而影响执行效率。根据我的经验，一份高可用的 CLAUDE.md 应该控制在 80 行以内，并且按照下面的结构组织：

# 项目：用户中心服务 ## 技术栈 - 后端：Java 17 + Spring Boot 3 - 数据库：MySQL 8 + MyBatis-Plus - 构建工具：Maven ## 常用命令 - 启动服务：mvn spring-boot:run - 跑全部测试：mvn test - 代码检查：mvn spotless:check ## 目录约定 - controller/ 只做参数校验和路由转发 - service/ 放业务逻辑，禁止直接操作数据库 - mapper/ 只放 MyBatis 接口和 XML ## 编码约束 - 所有新接口必须补充单元测试 - 禁止使用 System.out.println 打印日志，统一用 SLF4J - 修改数据库字段必须同时提供迁移脚本 ## 禁止事项 - 不要升级 pom.xml 中依赖的主版本号 - 不要改动 application-prod.yml 中的生产配置

这份结构里最核心的部分不是技术栈，而是“常用命令”和“禁止事项”。前者让 Claude 不用每次问你“怎么跑测试”，后者能在你不在的时候守住底线。你会发现，一旦把这些规则写清楚，Claude Code 的响应质量会有一个质的提升——它不再是“等指令再动”，而是“在规则框架内自主行动”。

3.3 用 settings.json 控制权限边界

CLAUDE.md 管的是“团队三观”，但光有三观不够，还得有“行为边界”。Claude Code 的权限控制主要通过.claude/settings.json完成，它决定了 Claude 能执行哪些命令、能访问哪些文件、在什么情况下需要征求你的同意。

下面是我在一个中大型项目里的推荐配置结构：

{ "permissions": { "allow": [ "Bash(npm run *)", "Bash(git *)", "Read(**)", "Edit(**/*.java)", "Edit(**/*.xml)" ], "deny": [ "Bash(rm -rf *)", "Bash(curl *)", "Edit(**/application-prod.yml)" ] } }

设置allow里的Bash(npm run *)之后，Claude 执行 npm 脚本就不会逐条问你要授权，体验会流畅很多。而把rm -rf和 curl 加入deny可以有效防止它做危险操作。权限表达式中**代表任意路径，*代表任意字符，写规则的时候先想清楚是要精确匹配还是通配。

另一个值得关注的是 hooks。简单理解，hooks 可以在特定事件发生时让你插入一段脚本或提示。比如我配置过一个 preToolUse hook，在 Claude 准备执行git push之前弹出一条确认提醒，避免它未经授权就推送代码到远端。配置 hooks 需要在.claude/settings.json中声明脚本路径，逻辑不复杂，但对安全性的提升很明显。

4. 成员定岗：Subagents、Skills 与 MCP 扩展

4.1 Subagents：把复杂任务拆分给“专人”处理

Claude Code 在运行比较复杂的任务时，会有一个任务规划层，它会把大目标拆成子目标，然后委派给不同的“子代理”（Subagents）去执行。默认情况下 Claude Code 自带一些基础子代理，比如负责代码搜索的、负责文件编辑的。但真正让团队运作起来的关键，是你能自定义子代理，做到“专人专事”。

自定义子代理的方式非常简单：在.claude/agents/目录下创建一个 Markdown 文件，文件里的 frontmatter 声明这个代理的名字、职责、可用工具和完成标准。下面是我给一个后端项目定义的“接口实现专员”示例：

--- name: backend-developer description: 负责 Java 后端接口实现和数据模型设计 tools: Read, Edit, Bash model: sonnet --- 你是一名资深 Java 后端工程师，擅长 Spring Boot 开发。 完成代码时必须遵守以下规则： 1. Controller 层不允许写业务逻辑 2. 每个新增接口必须给出对应的单元测试 3. 完成后运行 mvn test 并确认测试通过

定义好之后，我在主会话里给它下达指令，比如“让 backend-developer 实现用户注册接口”，主模型会判断这个子代理适合执行任务，然后委派给它。子代理完成后会把结果返回给主会话。这种机制特别适合大型仓库——主代理负责统筹思路，子代理专注执行局部任务，不会因为上下文过长而“忘了前面在干什么”。

4.2 Skills：把团队里反复出现的“手艺”沉淀下来

如果说 CLAUDE.md 是团队手册，那 Skills 就是团队的手艺包。一项技能可以是一套操作流程、一段领域知识、甚至一个自动化脚本的组合，它让 Claude Code 在面对特定场景时，能自动调用最合适的处理方式。

Skill 的组织形式是.claude/skills/<技能名>/SKILL.md。我举个实际例子：我们这个团队经常要审查代码，但不同仓库的规范有差异，于是我把审查流程做成了一个 skill，放在所有共用的配置目录里：

--- name: code-review description: 按团队 Code Review 规范审查代码改动 --- ## 执行步骤 1. 使用 git diff 查看本次改动的完整内容 2. 按优先级检查：正确性 > 安全性 > 性能 > 可读性 3. 每个问题必须给出：文件位置、问题描述、修改建议 4. 不修改代码，只输出审查报告

有了这个 skill 之后，每次进行审查实践，我只需要跟主会话说“用 code-review 技能看看最近的改动”，它就会按照上述流程规范执行一遍。技能包的优势在于可复用、可分享、可版本控制，团队的优秀实践可以通过这个机制持续沉淀。相关热搜词里很多人搜“claude code skills 安装”，其实它们并没有复杂的安装过程，把 SKILL.md 放进正确目录，然后在会话里通过/skills加载即可。

4.3 MCP：让“团队”接入外部工具生态

MCP 是 Model Context Protocol 的缩写，你可以把它理解成给 Claude Code 开的一扇门，让它能读取本地文件系统之外的数据，或者操作外部的工具和服务。这相当于是给团队成员配备了“外设”，能从更多渠道获取信息。

比如我现在的开发环境里接入了几个 MCP server：一个用来检索项目文档，一个用来连接数据库执行只读查询，还有一个用来操作 GitHub 的 Issue。配置命令很直接：

claude mcp add docs -- npx -y @modelcontextprotocol/server-filesystem ./docs claude mcp add mysql-readonly -- npx -y your-mysql-mcp-server --readonly claude mcp list

claude mcp list可以查看当前项目已经配置的所有 MCP server 列表。配置之后，Claude 会多出对应的工具调用能力。比如我说“查一下 docs 目录里关于部署的说明”，它就能通过 filesystem MCP 直接定位并读取。

这里我提一个经验：MCP 不是越多越好。每个 MCP server 都会占用上下文空间，接太多反而会影响核心任务的执行质量。我的标准是“只接入当前项目必须用到的服务”，能用一个通用工具解决的就不要重复接三个。配置 MCP 后如果发现响应变慢或老是答非所问，优先排查是不是 MCP 工具列表太长了。

5. 团队协作实测：从需求到交付的一次完整闭环

5.1 给 AI 成员一张合格的“需求卡”

在和 Claude Code 协作的过程中，最影响产出质量的环节不是写代码，而是写需求。我见过太多人上来就是一句“帮我写一个用户注册功能”，然后抱怨 AI 写出来的东西不满足预期。问题是，你在公司也不会这么跟同事说话——需求至少要讲清楚目标、边界和验收标准。

我现在会在项目目录里维护一份“需求卡”模板，每次让 Claude Code 干活之前先填好：

需求：在支付模块新增退款重试功能 背景：当前退款失败后没有自动恢复机制 约束： - 必须复用现有消息队列，不引入新中间件 - 失败超过 3 次后不再自动重试，转人工处理 验收标准： - 新增单元测试覆盖重试逻辑和次数上限 - mvn test 全量通过 - 不修改生产环境配置文件

把这段内容直接粘给 Claude Code，它会非常清楚地知道自己要干什么。很多配置的威力不是体现在单独的设置项上，而是体现在“人和 AI 之间有一套稳定的协作接口”这件事上。需求卡就是这套接口的一部分，它让每一次任务的起点变得一致，也让后续的自动化执行有了基线。

5.2 从分析到实现：一个实际任务的完整流程

现在演示一个完整调用。假设我们后端服务里，用户下单后需要发送站内通知，但通知服务偶尔不稳定，需求是增加一个重试机制。我会先让 Claude Code 做方案分析：

claude "先分析 notification 模块当前的发送流程，输出问题清单和改动方案，不要直接改代码"

它会在项目里搜索相关文件，整理出调用链，然后给出方案。确定方案没问题后，再进入实现阶段：

claude "按刚才确认的方案实现重试机制，要求复用现有的 retry 组件，补充单元测试，完成后跑 mvn test"

这时候 Claude Code 会进入 agent 模式，自己读代码、改文件、执行测试命令。如果测试失败，它会读报错信息、反向定位问题、继续修改，直到测试全部通过或它明确告知需要人工介入。我盯着它的执行过程，偶尔在关键节点打断问一句“为什么这里选择用指数退避而不是固定间隔”，它能给出完整的理由。

这里提一个实用技巧：在需求描述比较清晰、权限配置已经信任当前项目时，可以用claude -p启动非交互式模式，直接执行任务然后退出，适合放进 CI 脚本里做自动化的代码检查或报告生成。配合--output-format json，可以把输出结果结构化，方便后续程序处理。

5.3 建立“写代码”和“审代码”双角色循环

有了实现能力之后，很多人会掉进一个坑：让同一个上下文既写代码又审查代码。这就像让运动员自己给自己当裁判，惯性思维会让它很难发现自己的问题。我的做法是把两个动作拆开，用不同的会话、不同的角色指令去完成。

实现完成之后，我会先退出当前会话，重新开一个独立的 Claude Code 实例，用审查者的身份去检查刚才的改动：

claude -p "只审查最近一次 commit 的代码改动，忽略格式问题，重点关注：边界条件、并发安全、数据库事务、异常处理。输出问题清单并按严重程度排序，禁止修改代码。"

之所以要开新会话，是因为审查者不应该带着实现者的“方案预设”，否则很容易自我肯定。新会话的上下文里只有代码事实和审查标准，没有实现过程中的各种理由，反而更容易发现问题。根据我的实际经历，这种双角色循环每次都能挑出几个值得修改的点，比如某个边界情况没处理、某个接口的异常被吞掉了。

整个流程走下来就像带了一个实习生：先讨论方案、再让 TA 动手、然后让 TA 换双眼睛自己审一遍，最后你亲自把关。配置做得越好，这个循环里的“人工介入点”就越少，效率提升越明显。

6. 高频踩坑记录与排查速查

6.1 常见问题速查表

配置 Claude Code 的路上不可能一帆风顺，下面这张表是我踩坑比较多、也经常被朋友问到的问题汇总：

6.2 我的几个压箱底配置建议

最后分享几个我实际用下来觉得“早该知道”的配置习惯。

第一，非交互式模式是做自动化的宝贝。把claude -p接到 CI 流程里，可以定时做全项目的代码审查或安全检查。我用它写过一个脚本，每天凌晨跑一次claude -p "分析最近一天的所有 commit，输出潜在问题报告" --output-format json，然后把结果发到团队的消息群里，等于给代码库加了一个夜间巡检员。

第二，正确使用 /compact 和 /clear 区分“压上下文”和“开新会话”。上下文接近上限时，/compact会总结之前的内容并精简上下文，但保留任务主线；/clear则是彻底清空重新开始。写代码遇到方向性错误时，我会优先用/clear，而不是在一个混乱的上下文里继续纠缠。这跟真实团队开会一样，方案跑偏了先停止，回到出发点重新对齐，别在错误方向上硬冲。

第三，CLAUDE.md 需要持续维护。项目结构变化了、依赖升级了、规范更新了，都要同步更新这份“团队手册”。我会在每个版本迭代结束后，花十分钟检查一下当前配置是否还准确。配置和代码一样，有技术债务，不维护就会慢慢腐烂，最后变成没人想碰的僵尸文档。

我个人在实际操作中的体会是：Claude Code 的配置价值不是一次性投入，而是滚雪球。刚开始你可能只需要一份 CLAUDE.md 和一个基础权限配置，随着项目深入、踩坑增多、经验固化，配置会越来越厚，AI 成员的战斗力也会越来越强。这里面最核心的心法就一句话：你希望 AI 团队给你带来多少价值，就要愿意沉淀多少规范给它。把那些反复出现的提示词变成 Skills，把踩过的坑写进 CLAUDE.md，把危险的命令锁进 deny 列表。坚持半年之后再回头看，这支“团队”会比刚开始那一天默契得多。