企业官网建设流程全解析

结对编程这事，我最早是在团队里跟人练出来的。两个人坐一台机器前，一个负责敲键盘当 driver，另一个盯着全局当 navigator，看起来是协作，其实最微妙的是“谁说了算”。现在这个老搭档换成了 Claude Code，一个跑在终端里的 AI 编程助手，场景突然变得更有意思了——它不再是那种“你问我答”的聊天框，而是能直接读你的项目、改你的文件、帮你跑测试的真正协作者。于是问题来了：人机结对编程里，决策权到底怎么分？

这篇内容围绕 Claude Code 展开，核心就一件事：在真实开发流程里，哪些决策该交给你，哪些决策该交给 AI，哪些决策双方都要过一遍。我会把安装配置、权限模型、CLAUDE.md 边界设定、一次完整实操的过程，以及我踩过的坑都整理出来。适合正在用 Claude Code、或者刚把 AI 编程工具引入团队的人，尤其是那些“总觉得 AI 改代码不放心”的开发者——其实问题往往不是 AI 能力不够，而是你没把决策边界划清楚。

1. 为什么是 Claude Code：结对编程的“第二个座位”怎么选

1.1 从自然语言助手到项目协作体

早期用 AI 写代码，大家用的都是“问答式”工具：把一段报错丢进去，让它给个修复建议，再人工把代码贴回编辑器。这种方式本质上是搜索引擎的升级版，AI 没有上下文，只能做片段级推理，稍微大一点的改动它根本接不住。

Claude Code 不一样。它不是聊天窗口，而是一个跑在终端里的代理式编程助手，第一次启动后会扫描项目结构，读取关键文件，甚至能执行命令、运行测试。你可以直接对它说“帮我给用户模块加上分页查询”，它会自己去翻路由文件、找数据库模型、定位现有接口的写法，然后动手改代码，改完还能跑一遍测试给你看。

我第一感受是：这不就是给团队加了一个“不看需求文档、但代码量惊人的实习生”吗。它的价值不在于某个算法写得比你优雅，而在于它是一个能接住连续任务、能管理一定复杂度的协作体。你给它一个完整的任务描述，它能分解成步骤，能沿着代码的调用链去探索，能自己发现“这里有个 bug 顺便修了”。

这种工作方式不是“AI 替代程序员”，而是把人机关系从“工具使用者”变成了“结对伙伴”。既然成了伙伴，那决策权分配就必须摆到台面上，否则就会出现“AI 改爽了、你慌死了”的局面。

1.2 人机结对与人人结对的核心差异

传统结对编程里，两个工程师之间的决策权分配，一半靠技术能力，一半靠沟通气场。有人擅长系统设计，有人对业务逻辑门儿清，配合好了是 1+1>2，配合不好就是两个人互相礼貌地推诿。

人机结对的情况要简单得多，但也更极端。AI 没有自尊心，不会因为你的方案更优而生气，也不会为了证明自己的存在感而坚持错误方案。这意味着你可以随时打断它、否定它、让它换一种思路重写，完全没有沟通成本。

但 AI 也有天然的短板：它缺乏真实的业务语境，不理解“为什么这个接口要设计成同步”这类潜规则；它对项目全貌的理解是“扫描出来的”，不是“长出来的”；更重要的是，它不会为自己的行为负责，一旦改出问题，锅最终还是你背。

所以人机结对中的决策权分配，本质上不是“谁更强谁说了算”，而是“哪类决策适合谁”：

• 涉及业务目标、产品方向、架构取舍的，必须人来拍板；
• 涉及代码实现、接口调用、命名规范这类局部细节的，AI 可以自主完成；
• 涉及风险控制、权限操作、不可逆动作的，人必须保留一票否决权。

这个分工逻辑想清楚了，后面的每一步实操都有了依据。

2. 开工前准备：Claude Code 的安装与基本配置

2.1 安装与启动

Claude Code 目前的主推形态是命令行工具，官方提供了 npm 包，安装方式非常简单：

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

装完后在终端里进入你的项目目录，直接输入：

claude

就会进入交互式对话界面。

几个前置条件值得提一下：Node.js 版本建议 18 以上，太旧会报语法错误；另外首次启动需要登录 Anthropic 账号并完成 API 密钥配置。如果你是想在 VSCode 里用，官方也提供了 Claude Code 插件，可以直接在编辑器侧边栏打开会话面板，跟终端版共享同一套会话上下文，体验上更顺手。

还有桌面版客户端，本质上是对命令行界面的可视化封装，把对话记录、文件树、配置面板做成了图形界面。如果你不习惯终端布局，装桌面版会更友好。我自己是终端党和 VSCode 插件混着用，终端用来跑长任务，编辑器里用来做局部修改。

2.2 权限模式的选择逻辑

Claude Code 最值得研究的设计，就是它的权限控制体系。它不是让 AI“想干嘛就干嘛”，而是把每个高风险操作都纳入到确认流程里。官方提供了几种权限模式：

• 默认模式：每次执行写操作或运行命令前，都会弹出确认提示，由你按 y 或 n 决定；
• 自动接受编辑模式（acceptEdits）：AI 可以直接修改文件内容，不需要逐个确认，但运行命令仍然需要批准；
• 计划模式（plan）：AI 只读代码、只做分析、只输出方案，不写任何文件；
• 完全放权模式（bypassPermissions）：所有操作全部自动执行，包括运行命令、修改文件，甚至安装依赖。

不同模式对应着不同的协作姿态。我的建议是：初期或者任务复杂度高的时候，用默认模式或计划模式；当你对项目上下文足够熟悉，且任务边界非常清晰时，再切换成自动接收编辑模式；完全放权模式我极少用，通常只在 CI 环境或者一次性脚本任务里才会开，因为它的风险敞口太大。

还记得安装配置时常见的一条报错：welcome to claude code v2.1.272 unable to connect to anthropic services fail。这类问题的排查思路，我会在第 5 章详细展开，这里先记住一点：遇到连接失败，优先检查网络环境和 API Key 状态，不要急着重装。

2.3 多模型配置：接入 DeepSeek、GLM 等兼容模型

Claude Code 默认调用 Anthropic 官方模型，但不少团队也希望能把它接到国产模型上跑，比如 DeepSeek、GLM 这类兼容 OpenAI/Anthropic 接口的服务。实际操作上，Claude Code 支持通过环境变量来覆盖 API 地址和鉴权信息：

export ANTHROPIC_BASE_URL="https://api.example.com" export ANTHROPIC_AUTH_TOKEN="your-token"

设置好之后，Claude Code 的请求就会转发到你指定的模型服务商。也有人写了一些开源小工具（比如 cc-switch）来管理多套环境变量配置，在官方模型、DeepSeek、GLM 之间一键切换，省得每次改 shell 配置。

需要提醒的是：不同模型的能力差异很大，同样的任务在官方模型上可能表现稳定，切到其他模型后可能会频繁偏离指令、逻辑不一致。因此如果你在多模型之间切换，建议把 CLAUDE.md 里的约束写得更严格一些，同时在低风险任务上先做验证。

2.4 让 Claude Code“懂你的项目”：CLAUDE.md 的正确写法

Claude Code 支持在项目根目录放一个CLAUDE.md文件，每次会话启动时它会自动读取这个文件，把它当作项目的“协作备忘录”。这几乎是我认为最值得投入时间配置的东西——没有它，AI 就是一个拥有超强能力但方向感为零的工具；有了它，AI 才知道哪些能做、哪些绝对不能碰。

我的CLAUDE.md一般包含这几块内容：

• 项目简介：这个项目是什么、给谁用；
• 技术栈清单：框架、语言、关键依赖，避免 AI 引入不存在的库；
• 目录结构说明：哪些目录是核心代码，哪些目录是生成物不要动；
• 代码风格约束：缩进、命名、是否使用 TypeScript、是否必须写测试；
• 明确禁区：哪些操作是禁止 AI 做的，比如不要改数据库迁移文件、不要动 CI 配置、不要删除任何已有函数；
• 常用命令：本地启动命令、测试命令、构建命令，让 AI 不用猜。

看起来只是一个文档，但在决策权分配里，它起的作用是“提前把规则刻进协作流程”，相当于跟搭档约法三章。我在第 4 章实操部分会给出一个具体的 CLAUDE.md 片段。

3. 决策权分配模型：四种边界，一条底线

3.1 第一级：任务拆解与方案设计，人来拍板

跟 Claude Code 协作，最容易犯的错就是“一句话需求”直接丢进去：“帮我做个用户系统”。AI 确实能给你列一堆文件、生成一堆代码，但那大概率不是你想要的——因为它没有问过你任何问题。

我的经验是：人机结对的第一步，永远是人先做任务拆解。哪怕是粗略的也行，你得让 AI 知道任务边界、验收标准、优先级。比如你把这个需求改一改：

“给我做一个用户系统，包括注册、登录、个人信息三块。注册要支持邮箱和手机号两种方式，登录用 JWT 无状态方案。先只做后端接口，前端页面不用管。接口返回格式统一为 { code, msg, data }。在 plan 模式下先输出你的实现方案。”

看到了吗？这里我已经拍板了绝大部分决策：注册方式、鉴权方式、返回格式、技术边界。AI 要做的是在这个框架里发挥自己的实现能力。这就像结对编程里，navigator 负责方向和路线，driver 负责具体操作。Claude Code 可以帮你生成方案，但方案的选择权不要交出去。

实际操作中，我会先让它跑一次 plan 模式，把实施步骤列出来，然后我来做“验收式审核”：这个步骤顺序合理吗？漏了什么吗？有没有更好的替代方案？确认没问题之后，才允许它进入写代码阶段。这一步可以避免 90% 的“AI 自嗨式开发”。

3.2 第二级：代码实现与重构，AI 主导

方案定了、边界画了，进入实现阶段，就该给 AI 足够的发挥空间。很多人不放心让 AI 自己改代码，觉得它可能把别的地方改坏。这个担忧合理，但可以通过“细粒度任务”来化解：一次只给它一个明确的任务模块，别让它一口气改十个文件。

在这个阶段，我的 prompt 习惯是：陈述任务、限定文件范围、列出验收标准。比如：

“请为 utils/request.js 新增一个带超时控制的请求方法。要求在超时后自动中断请求并返回自定义错误码。只修改这个文件，不要动其他模块。改完后运行 npm run test:utils 确认全部通过。”

你会发现，当任务范围被限定得很干净时，AI 的执行力非常靠谱。它能自己处理边界情况、补全错误处理、甚至主动加注释。这时你要做的，是把自己从“代码打字机”变成“代码评审者”，把精力放到更高层的质量把控上。

3.3 第三级：工程质量与回归风险，人机共审

AI 把代码写完了，不代表事情就结束了。这里有一个非常关键的思维转变：AI 生成的代码，默认是“看起来能跑”的代码，而不是“长期可维护”的代码。它可能缺少边界测试、可能没考虑并发、可能悄悄引入了一个全局变量污染。

所以无论 AI 表现得多好，最终审查这一关你得自己过。我的做法是：在每个实现阶段结束后，要求 Claude Code 自检，并输出修改摘要；然后我再跑一遍测试命令，用 git diff 逐段查看改动。不是不信任它，而是结对编程的底线要求是“至少一方完全理解代码”——既然 AI 对项目的理解是概率性的，那这个人只能是你。

还有一个实用技巧：要求 AI 在提交前自己先跑一遍 lint 和测试。你可以在指令里明确写“完成代码后，运行 eslint 和 jest，全部通过后再告诉我”。这样相当于让 AI 做了第一轮质量把关，你只需要复核结果。

3.4 第四级：权限与危险操作，永远握在人手里

最后一层，也是最不能放权的一层：危险操作。无论 AI 多聪明、你的 CLAUDE.md 写得多么详细，都不要放开对不可逆操作的控制。

具体来说，以下动作我永远不会让 AI 自动执行：

• 删除文件、特别是批量删除；
• 强制推送（git push --force）；
• 修改数据库表结构或执行数据迁移；
• 清理 git 历史、重置分支；
• 安装来源不明的依赖包；
• 修改配置文件或密钥文件。

在这些场景里，哪怕 AI 主动建议“我可以帮你执行”，我也会打断它，自己手动操作。别看这些操作失败的概率不高，一旦出错，代价是小时级的返工。权限的收紧，不是对 AI 的不信任，而是对生产环境的敬畏。

CLAUDE.md 里我会放这样一段话：“禁止执行任何 git push 操作；禁止删除目录；禁止修改 src/config 下任何文件；所有依赖安装必须经过确认。”这相当于给 AI 划定了一个高墙围栏，让它在安全区内放手干活，墙外的一切必须回到人这边。

4. 实操记录：一次完整人机结对任务的逐环节拆解

4.1 任务上下文与准备

为了把前面的理论落到地上，我用一次真实的小型任务来演示：给一个现有的 Koa 项目加上请求速率限制中间件，并用 Redis 做分布式存储，Redis 挂了的时候要能自动降级为内存模式。

项目本身是一个 Node.js + Koa 的 API 服务，Redis 已经部署在测试环境。我先在项目根目录写好 CLAUDE.md，关键内容如下：

# 项目约束 - Node.js 18+ / Koa 2 框架 - 语言：JavaScript（服务端代码不使用 TS） - 测试：vitest，运行命令 npm test - 代码风格：2 空格缩进，单引号，无分号 - 禁止：修改 src/db 目录、修改 package.json 中名称字段 - 禁止：执行 git push、git reset 等危险命令 - 安装依赖前必须停机确认

写清楚这些，是因为我不希望 AI 在实现中途突然说“这里我换个 ORM 也行”或者“把这个中间件卸载了吧”。

4.2 对话与决策日志

我的第一轮指令，用的是 plan 模式：

“请先读一下 package.json、src/app.js 以及 src/middleware 目录下的现有文件。然后给一个实现方案：在请求入口处增加 rate limit，按 IP+路由 维度限流，默认 60 次/10 分钟；优先使用 Redis 存储；用 ioredis 库；如果 Redis 不可用，降级为内存存储。先输出方案，列出要新增和修改的文件清单。”

Claude Code 读完后，给出了一个五步方案：

1. 安装 ioredis 和 koa-rate-limit（或手写中间件）；
2. 新增 src/middleware/rateLimiter.js，封装限流逻辑；
3. 修改 src/app.js，在路由注册前挂载中间件；
4. 新增 test 目录，覆盖正常请求和超限请求；
5. 在 README 里补充环境变量说明。

我看了之后，对其中一个决策提出了修改：“不要用 koa-rate-limit 这个包，限制太死，我想让限流逻辑更轻量，直接基于 ioredis INCR + EXPIRE 实现。另外测试用例里加一个 Redis 故障降级的用例。”

这里我做的决策是：技术选型不要用第三方轮子，自己实现；AI 做的决策是：合理识别出了挂载点和测试目录。方案调整后，我发出第二轮指令：退出 plan 模式，进入默认确认模式，让它开始动手。

实现过程中，Claude Code 自动创建了中间件文件，修改了 app.js，还贴心地补了一个环境变量 RATE_LIMIT_MAX。我在关键操作上按了几次 y 确认，全程没遇到需要我手动介入的障碍。第一次测试跑下来，限流生效，但有个边界用例没过：连续请求第 61 次时，状态码返回了 429 body，但响应头缺少 Retry-After。Claude Code 主动定位到问题，指出是因为 INCR 返回的是自增后的值，计算剩余秒数时没有用 TTL，于是它改了一版，把 Retry-After 用 TTL 值填充，测试通过。

4.3 这次协作里，谁做了哪些决策

任务结束后，我汇总了一下双方承担的角色。我做的主要决策包括：任务范围界定（只加中间件，不碰路由逻辑）、技术方案选择（自研而不是引第三方库）、降级策略（Redis 挂了用内存兜底）、限流阈值（60 次/10 分钟）。Claude Code 承担的主要决策包括：代码文件组织方式、ioredis 具体 API 调用、错误处理细节、测试用例设计、README 环境变量说明。

这正是人机结对最理想的形态：人负责“做什么、为什么、边界在哪”，AI 负责“怎么做、具体怎么调用、怎么测”。双方各自在自己擅长的维度发力，效率自然是单人开发的几倍。

5. 实操中的常见问题与排查技巧

5.1 常见问题速查表

用了一段时间 Claude Code，我遇到过不少问题，有些是环境问题，有些是协作方式问题。整理成一个表格，方便你对照排查：

5.2 我把这些坑踩过一遍之后的独家心得

第一个心得：CLAUDE.md 不是写一次就完事的，它需要跟着项目的演进不断更新。最初我写得很简略，后来发现 AI 会跑偏到“它自己以为的规范”里，比如把单引号改成双引号、给没有必要的函数加 async。这些都是在审查 diff 时发现的。现在我每次碰到 AI 做了一件我觉得“不应该做”的事，第一反应不是骂它，而是检查是不是 CLAUDE.md 约束漏了。把这条补进去，下一次它就不会再犯。

第二个心得：不要贪多，一次只改一个点。很多人让 AI “顺便把登录模块也优化一下”，结果 AI 优化着优化着，把接口签名都改了，崩溃。人机结对里，“小步快跑”原则比任何 prompt 技巧都重要。一次任务只完成一个可验证的功能点，确认通过后，再进行下一个。

第三个心得：终端版、VSCode 插件和桌面版三者同时用，效率反而更高。终端版适合跑批量修改任务，VSCode 插件适合在编辑器上下文里做局部微调，桌面版则适合观察完整会话记录。它们共享同一套配置文件，不会互相冲突。

第四个心得：安装和配置环节如果卡住了，不要反复卸载重装。大多数问题都集中在网络连通性、Node 版本、API Key 这三个点上，先把这三项逐一排除，再考虑重装。社区里也常有人讨论 “claude code 安装失败”，十有八九是这“三板斧”没轮到。

5.3 最后再分享一个小技巧

大多数人不知道，Claude Code 的交互界面里可以用/init命令自动生成一份初始版CLAUDE.md。它会扫描项目文件、识别技术栈、自动整理出目录结构说明，然后你再在这个基础上做删改。相当于让 AI 先画了个草图，人来定最终的上限和边界。我每次接手新项目，第一件事就是运行/init，然后再花十分钟精修里面的“禁止事项”部分。

这份文件就是你与 Claude Code 之间决策权分配的契约。它写得多细，决定着你后面少操多少心。我在实际使用中发现，凡是 CLAUDE.md 写得认真的项目，AI 的跑偏率会断崖式下降；凡是懒得写的项目，基本都会在第 N 次重构时把人逼疯。如果你刚开始接触 Claude Code，不用急着研究各种高级玩法，先把这条“协作契约”立好，后面的一切都会顺很多。