企业官网建设流程全解析

我最初用 Claude Code，其实只是把它当终端里的“升级版聊天框”。问一句答一句，代码只出建议，执行全靠我复制粘贴，一个中大型重构经常被我拆成几十轮对话，上下文越聊越碎，改完 A 模块又弄坏 B 模块。直到我把思维从“单步聊天”切换到“多 Agent 编排、闭环自愈、Routine 脚本化架构”之后，才意识到之前浪费了多少时间。这篇文章把我实际摸索出来的工作方式完整写出来，包含安装配置、直接执行终端命令的权限边界、多 Agent 任务拆解、自动修复循环的落地条件，以及用 cc-switch 接入 DeepSeek、Qwen、GLM 这类第三方模型的具体做法，适合正在用或准备用 Claude Code 做自动化开发、批量重构的工程师。

1. 单步聊天的天花板：为什么我被迫研究多 Agent 编排

1.1 “一问一答”模式在真实工程里的三宗罪

我印象最深的一次踩坑，是给一个旧支付模块做重构。起初对话很正常，Claude Code 给了我一段修改建议，我复制进项目，编译通过，接着问“下一步”，它又给了一段建议。但到了第六七轮，它已经记不清前面改过哪些文件了，反复重复同一个路径，甚至建议我再改一遍已经改好的函数。最后我只能新建会话，把十几个文件的内容重新贴进去，再要求它从头分析。

这种工作方式的问题非常典型：

• 上下文不断被截断。单次会话窗口有限，聊得越多，最早的约束、变量名、业务规则就被挤得越远。一旦上下文不完整，大模型就成了一个“记忆只有十分钟”的临时工。
• 没有全局任务视角。你问它“下一步做什么”，它只能根据现有会话推断下一步，无法像项目负责人一样维护一张任务总表，更谈不上主动推动多个子任务并行。
• 执行和验证严重脱节。代码改完没有立即跑测试，测试失败又得重新粘贴报错，再让它分析，整个循环低效到让人不想用第二次。

这不是模型能力不够，而是使用方式本身就有问题。我们需要的不是让 Claude Code 一次性回答更大的问题，而是把一个大型任务拆成可验证的小块，让它自己调度、自己执行、自己看结果、自己修正。这就是后面要展开的三件事：多 Agent 编排、闭环自愈、Routine 脚本化。

1.2 编排、自愈、脚本化其实是一个整体

很多教程喜欢把这三个概念分开讲，但我用下来发现，它们必须组合起来才有真正的工程价值。

• 多 Agent 编排解决的是“任务怎么拆、怎么派、结果怎么汇总”的问题。类似大项目里的模块负责人，把需求拆成可并行的子任务。
• 闭环自愈解决的是“拆出去的子任务失败了怎么办”的问题。每个子 Agent 执行完命令后，要能读取报错、修复代码、重新运行测试，形成一个持续反馈的循环。
• Routine 脚本化解决的是“同样的流程下次还要重复跑一遍怎么办”的问题。把经验固化成一套可复用的脚本和步骤，以后直接触发，而不是每次重新教一遍。

我用一个厨房的例子来说明：你一个人又要洗菜又要切菜又要炒菜还要刷锅，这是“单步聊天”；一个后厨团队里，配菜组只负责备料，热菜组只负责炒，洗碗工只负责收盘，主厨统筹整条出餐线，这是“多 Agent 编排”；炒糊了立刻倒掉重新做，而不是等客人投诉，这是“闭环自愈”；把整套后厨流程写成标准作业手册，新人照着做就能出餐，这是“Routine 脚本化”。Claude Code 真正值钱的地方，就是这三种能力可以叠加在同一个工作流里。

2. 环境地基：Claude Code 在 VS Code、Ubuntu、macOS 上的安装与配置

2.1 三种安装形式到底怎么选

很多人在安装阶段就会被各种渠道搞混，因为 Claude Code 并不是只有一种打开方式。目前主流的三种形态是：

我最推荐的是“命令行终端 + VS Code 插件”组合。因为 Claude Code 真正强大的地方是直接执行终端命令，纯聊天界面根本发挥不出它的价值。终端形态也方便写脚本、接入自定义 workflow，甚至直接在服务器上跑。

安装前先确认 Node.js 环境没问题，建议 LTS 版本而不是最新开发版，不然 npm 装包的时候容易出现兼容警告。

node -v npm -v

然后全局安装：

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

装完验证一下：

claude --version

如果以后要升到最新版本，我一般直接用：

claude update

2.2 VS Code 插件配置里容易被忽略的字段

VS Code 插件接入 Claude Code 之后，很多配置不是写在插件界面里的，而是落到 Claude Code 的配置文件里。常见的路径是用户目录下的.claude文件夹，里面会有settings.json这类配置文件。

我建议重点关注几个字段：

• 权限模式：决定是否允许 Claude Code 自动执行命令、是否每次都要弹窗询问。
• 允许命令列表：只放日常开发中用到的安全命令，比如测试、构建、lint。
• 工作目录：打开某个项目时，默认的启动目录必须明确，避免它跑到无关目录里去执行命令。
• 模型选项：指定默认模型，也可以留空让 CLI / 插件自动判断。

我踩过的坑是：改了插件配置之后没有重启 VS Code，导致配置一直不生效。这类配置文件的变更，很多时候不像普通设置那样热更新，重启窗口是最快的验证方式。

2.3 Ubuntu 和 macOS 安装时的常见环境问题

Ubuntu 上最常见的报错是安装成功之后找不到claude命令。这通常是因为 npm 的全局 bin 目录不在 PATH 里。解决办法不是去chmod某个奇怪路径，而是把 npm 全局 bin 加进 PATH：

export PATH="$(npm prefix -g)/bin:$PATH" source ~/.bashrc

macOS 上更多是系统权限拦路。第一次运行 Claude Code 时，如果它要写文件、执行终端命令，系统会弹安全确认。这一步别直接点“始终允许”后不管，要看清它到底要访问哪个目录。我习惯在独立项目目录里测试，而不是让它访问整个用户目录。

另外要提醒一句：如果你在公司电脑上安装，最好先确认安全策略是否允许，不要为了绕过限制去改系统级配置，这既不稳定也不安全。

3. 直接执行终端命令的能力边界：从“问答工具”到“行动者”

3.1 执行命令才是自动化工作流的起点

很多人的误区是把 Claude Code 当成一个“代码解释器”，只输出建议，人工再去执行。但 Claude Code 的核心能力之一是直接调用终端命令：跑测试、看输出、读错误、改文件、再跑测试。这一条链路打通之后，它才真正从一个问答工具变成一个自动化执行者。

我举个例子。以前我遇到测试失败，要手动把终端的报错复制给 Claude Code，让它分析，它给出修复建议，我再改代码，再跑测试，循环往复。现在流程变成：Claude Code 自己跑测试，自己读输出，自己改代码，自己重新跑测试。我要做的只是设定边界和验收条件。

3.2 权限设计：不是所有命令都应该无脑放行

Claude Code 默认执行危险操作前会请求确认，但从工程效率角度，我更倾向于把安全的命令加入白名单，把高风险命令加入黑名单，而不是让它在每个git status上都停下来问我。

我个人常用的配置思路如下：

{ "permissions": { "allow": [ "npm test", "npm run build", "pytest", "git status", "git diff", "git log --oneline" ], "deny": [ "rm -rf *", "sudo *", "git push --force", "DROP TABLE" ] } }

这里面的逻辑是：我只放行那些“可观察、可回滚、低风险”的命令。

• 可观察：命令执行完有明确输出，Agent 能读取输出判断成功与否。
• 可回滚：改了代码可以git checkout退回，不会造成不可逆影响。
• 低风险：不会删除生产数据、不会覆盖远端分支、不会以管理员权限执行未知操作。

如果你一上来就允许“自动接受所有命令”，Claude Code 就可能在你不知情的情况下执行rm -rf或者把本地分支强推到远端。这个风险不是它不够聪明，而是你没有给它设置足够清晰的边界。

3.3 从“执行命令”到“闭环自愈”的跳跃

执行命令本身并不能带来多少收益，真正的收益来自“执行后观察结果、根据结果调整行为”的循环。当 Claude Code 跑完测试发现失败，它能自动从错误栈里提取线索，找到对应代码文件，修改逻辑，再跑测试验证，这时候就形成了一个闭环。

我把这个闭环称为“自愈”的最小单元：触发 → 执行 → 检测 → 修复 → 回归。后面专门用一整章来讲，但它的地基一定是第 3 章的直接执行能力。没有命令执行权限，自愈循环就是空谈。

4. 多 Agent 编排的工作机制：任务拆分、上下文隔离与结果合并

4.1 为什么要用多个 Agent 而不是一个大对话

单次对话最大的瓶颈是上下文窗口和注意力聚焦。你把“重构整个订单服务”这种需求丢给一个大 Agent，它在处理订单数据库模型的时候，很容易被前端展示逻辑干扰。

多 Agent 编排的核心思路是：把一个大型任务拆成多个相对独立的子任务，每个子任务由单独的 Agent 负责，外面再有一个主控 Agent 做分配和汇总。

这个方法之所以有效，不只是因为并行快，更重要的是上下文隔离。每个子 Agent 只需要关注自己的任务描述和对应文件，不必把整个项目都塞进上下文。这就像让后端工程师只看后端代码、前端工程师只看前端代码一样，注意力集中了，准确率自然上升。

4.2 我在一次旧项目重构里使用的编排思路

我有一次要把一个老项目从自定义文件上传逻辑迁移到对象存储，任务涉及前端上传组件、后端接口、数据库字段、异步任务队列四个部分。如果单线程一个个改，很容易改完前端忘了后端。

我当时的执行框架是这样的：

1. 主控 Agent先分析项目结构，输出任务清单，并把四个模块分别定义为四个子任务。
2. 前端 Agent负责替换上传组件，修改上传成功回调，不碰后端代码。
3. 后端 Agent负责修改接口签名和存储逻辑，不碰数据库结构。
4. 数据层 Agent负责新增字段迁移脚本，并检查旧数据兼容。
5. 任务队列 Agent负责异步处理的改造，和前端/后端通过约定好的接口文档对接。
6. 最后验证 Agent统一跑测试、检查接口联调、生成变更报告。

每个子 Agent 拿到的是一个明确边界的小任务，而不是“帮我全部搞定”这种模糊指令。最终结果由主控 Agent 合并，如果有冲突，它再协调相关 Agent 重新处理。

这种编排特别适合这些场景：

4.3 子任务结果合并时的冲突处理

多 Agent 并行之后，最大的坑不是并行本身，而是合并结果时的冲突。两个 Agent 同时改了同一个文件，或者一个 Agent 改了接口名，另一个 Agent 还在用旧接口名调用。

我的处理经验是：

• 每个子 Agent 输出时，不只是返回文字总结，还要产出明确的变更文件列表和 diff。
• 主控 Agent 必须做一次“交叉检查”，对一起改动的文件逐一确认，解决顺序后再合并。
• 如果项目里没有严格的模块边界，就不要强行并行，串行反而更安全。

另外，上下文隔离也不是完全不共享信息。子 Agent 之间需要一份“统一契约”，比如接口定义、数据结构、变更规范。这份契约最好单独写到一个文件里，让所有子 Agent 都能读取，而不是靠对话传递。

5. 闭环自愈：从报错到修复再到验证的三个阶段实践

5.1 闭环自愈的本质是“三阶段循环”

闭环自愈听起来很玄，其实拆开就是三个阶段的循环：执行验证 → 失败诊断 → 修复回归。

• 执行验证：运行测试、构建、lint，得到明确成功或失败信号。
• 失败诊断：读取错误日志、堆栈信息，定位到文件和原因。
• 修复回归：修改代码，重新执行验证，直到通过，或者达到迭代上限后停止。

这个循环看起来简单，但落地时的细节决定成败。

5.2 我在 CI 循环里用的简版自愈框架

下面这段不是某个 CLI 工具的直接语法，而是我在自动化脚本里模拟“Claude Code 自愈循环”的思路。重点看结构，不要把它当成万能命令行直接粘贴，因为不同版本的 CLI 参数可能有差异。

for attempt in {1..5}; do pytest > result.log 2>&1 if grep -q "FAILED" result.log; then claude -p "请读取 result.log，定位失败用例，修复代码中导致失败的问题，不要修改测试文件，修复后重新运行 pytest 验证。" else echo "success" break fi done

这个循环里有几个被很多人忽略的约束：

第一，限制了最大尝试次数。没有上限的话，Agent 可能会在一个简单的逻辑错误上反复打转，白白消耗大量 token。

第二，要求不要修改测试文件。这是自愈里最容易出问题的地方：Agent 发现单测失败后，可能会“机智”地把单测断言给改软，让测试暴力通过。这种假修复会直接毁掉测试的价值。所以我在自愈指令里明确禁止改测试代码。

第三，把结果输出到日志文件再读取。相比直接在终端里抓取输出，日志文件更适合多轮分析，Agent 可以反复读取，不会因为终端滚动丢失信息。

5.3 自愈不是万能的：什么情况会越修越糟

我踩过的几个坑值得单独列出来：

• 只修表面症状。错误信息指向某个空指针，Agent 加了一个 if 判断绕过，但实际上数据流向本来就错了，根因在后面一层。
• 反复修同一个问题。测试用例并没有覆盖真正出错的分支，Agent 改完代码跑了同一批用例，全部通过，就认为修好了，其实问题还在。
• 改动扩散到无关代码。自愈循环里没有加“最小改动”约束，Agent 为了通过测试，顺手重构了旁边的模块。

所以我在自愈场景里一定会加三条规则：

1. 改动限定在错误日志关联的文件范围内，超出范围必须先汇报。
2. 修复之后必须跑完整测试集，而不是只跑单个失败用例。
3. 连续两次修复后仍然失败，立即暂停，把现场情况交给人工判断。

哪怕 Claude Code 能力再强，自动修复也只是用来处理那些“有明确失败信号、有确定修法”的问题。像需求理解错误、产品逻辑不清晰这类问题，放进自愈循环只会越修越乱。

6. Routine 脚本化架构：把高频重复任务变成可复用剧本

6.1 Routine 和普通 Prompt 的区别在哪

普通的 Prompt 是你临时提的需求，比如“帮我看看这个模块怎么优化”。Routine 则是一套结构化的可复用流程，它包含任务目标、工作目录、执行步骤、验收标准、失败处理方式。

说白了，Prompt 是一次性的对话，Routine 是沉淀下来的操作手册。

我最先开始做 Routine，是因为每次新项目初始化都要重复一套动作：创建目录结构、初始化 git、安装依赖、配置 lint、生成 README。这些事情每次让 Claude Code 临时想一遍，既浪费时间，结果还不稳定。后来我把它写成一个 Routine 文件，每次只需要触发，它就会严格按步骤执行。

6.2 我的 Routine 目录长什么样

我在.claude目录下维护了一套私有 Routine 库，按场景分目录：

~/.claude/routines/ ├── release/ │ ├── 00_check_env.sh │ ├── 01_bump_version.sh │ ├── 02_run_tests.sh │ ├── 03_update_changelog.sh │ ├── 04_build.sh │ └── 05_publish.sh ├── new_project/ │ ├── init_git.sh │ ├── setup_config.sh │ ├── install_deps.sh │ └── create_readme.sh └── daily/ ├── update_deps.sh ├── run_lint.sh └── generate_report.sh

每一个脚本对应一个明确的步骤。这样设计的好处是：当某个步骤失败时，Claude Code 可以只处理那一个脚本，而不是把整个 Routine 从头跑一遍。失败处理也可以直接复用第 5 章的闭环自愈逻辑。

6.3 Routine 与多 Agent 编排的经典组合

Routine 不是只能串行跑，它也可以作为编排中的一个节点。拿我最常用的“依赖升级日”来说：

• 编排 Agent 先检查项目依赖列表，生成一份需要升级的清单。
• 分析 Agent 评估每个依赖的 breaking change 风险，把高风险项标记出来。
• 升级 Agent 按风险从低到高逐个升级，每升级一个就跑一遍测试。
• 测试 Agent 负责全量回归，发现失败就调用自愈循环修复。
• 最后，报告 Agent 把升级结果、失败项、修复情况汇总成一份文档。

这套流程单靠任何一个 Agent 都做不完，但组合起来之后，我只需要在工作日早上触发一次，所有升级和回归都是自动完成的。这就是我理解的“Routine 脚本化架构”：它不只是保存几个脚本，而是把一套工程方法论固化成了能自动执行的流程。

如果团队使用，我还会把 Routine 目录放进 Git 仓库，这样不同成员可以 review、讨论、迭代这套流程。Routine 本身也应该像代码一样经过 review，因为它直接影响自动化执行的行为。

7. 兼容性实战：cc-switch 接入 DeepSeek、Qwen、GLM 以及第三方 API 的正确姿势

7.1 为什么要在 Claude Code 里接其他模型

官方模型质量固然好，但实际工程里会有几个现实问题：成本预算、不同任务对模型能力的不同要求、以及团队内部已经部署了其他模型网关。我自己的习惯是简单任务走轻量模型，复杂重构和代码审计才用更高质量的模型。这种诉求下，就需要一个能切换模型的方案。

cc-switch 是我在社区里看到的方案，它可以管理多个模型供应商配置，在 Claude Code 的调用层做切换，接入 OpenAI 兼容接口的模型。用之前必须明确一点：它不是官方工具，使用时要自己评估风险。尤其是 API Key 的安全，永远不要传给不明来源的第三方面板。

7.2 cc-switch 接入 DeepSeek / Qwen / GLM 的核心步骤

下面是我的配置流程，但要注意一点：各家 API 的 Base URL 和模型名称会不定期调整，所以不要把我写的地址当成永久格式，接入前务必以各家官方文档的最新信息为准。

1. 安装并配置 cc-switch。
2. 在 cc-switch 里添加供应商配置，填写名称、Base URL、API Key、模型名称。
3. 让 Claude Code 的数据接入层使用这套配置。
4. 跑一个最简单的测试任务，看看是否正常返回，再逐步上复杂任务。

配置结构大致像下面这样，具体字段名按工具版本调整：

{ "providers": [ { "name": "deepseek", "base_url": "https://api.deepseek.com/v1", "model": "deepseek-chat" }, { "name": "qwen", "base_url": "https://dashscope.aliyuncs.com/compatible-mode/v1", "model": "qwen-max" }, { "name": "glm", "base_url": "https://open.bigmodel.cn/api/paas/v4", "model": "glm-4" } ] }

这类兼容方案容易踩的坑是：不同模型的参数名、上下文长度限制、工具调用格式都有细微差别。有些模型在一个供应商接口下表现正常，换到另一个供应商就频繁报格式错误。这时候不要急着怪模型，先看是不是配置里的参数没有对齐。

7.3 注册账号和不注册账号到底差在哪

一个经常被问到的问题是：“harness 不登录可以用其他模型吗？”我的回答是：可以，但要想清楚代价。

不登录使用第三方模型，整个 CLI 外壳仍然能跑，只要它被配置为通过某个 OpenAI 兼容端点来调用模型。你相当于把 Claude Code 当作一个“Agent 执行框架”在用，本质的对话模型已经换成了第三方服务。

区别主要在几方面：

• 官方模型通道：不登录就无法使用官方模型和配套的订阅额度。
• 会话历史同步：很多云同步、会话记录能力依赖账号体系，不登录时通常只能本地管理。
• 部分高级配置：官方账号的一些特性在第三方模型接入时可能不可用。

所以我的策略是：日常重要任务用官方账号，确保稳定性和数据同步；某些实验性、高成本的批量任务，如果公司内部已经有其他模型通道，再用 cc-switch 切到第三方模型。两条路径分开配置，互不污染。

我个人强烈建议：API Key 不要直接写进任何可能被提交到 Git 的配置文件里。用环境变量或独立的.env文件，并加入.gitignore，是最基本的底线。

8. 从单步聊天升级到自动化工作流的避坑清单

8.1 我踩过的最贵的三个坑

第一，把敏感 Key 放进项目配置里并提交到了仓库。有一次我在一个示范项目里为了方便，直接把第三方 API Key 写进配置文件，后来项目推到公开仓库才意识到问题。虽然马上删除重推了，但这个记录已经留在历史里。现在我只用环境变量，任何 Key 都不进配置文件。

第二，允许自动执行所有命令，结果它差点删掉本地数据库。当时为了追求效率，我开启了“自动接受所有命令”。结果 Claude Code 在处理一个清理脚本时，误判了一个路径，直接跑了删除命令。虽然没造成实际损失，但把我吓出一身冷汗。从那之后，危险命令一律加入 deny 列表，重要目录必须二次确认。

第三，自愈循环没有上限，token 消耗直接爆表。我让它在一次回归测试里自动修复，没有限制循环次数，结果它在同一个问题上反复尝试了几十次，消耗了大量 token 也没解决。后来我所有的自愈循环都加了最大尝试次数，两次失败就停下，宁可人工介入也不盲目硬试。

8.2 这套架构的安全边界怎么设

自动化程度越高，安全边界越重要。我现在坚持几条底线：

• 禁止在自动流程中加入不可逆操作。比如git push --force、清空数据库表、删除生产环境文件，这些都不应该出现在白名单里。
• 敏感操作使用独立沙箱或临时分支。自愈循环、批量修改如果可能影响生产代码，就先在 feature 分支或容器环境里跑，验证通过后再合并。
• 每次自动改动都必须有 diff 审计。让 Claude Code 在修改后输出变更清单，而不是默默改完所有文件。
• 对 Routine 做版本管理。Routine 也是代码，改完之后要有记录，出问题能回退到上一个版本。

8.3 什么情况不建议用这套重型架构

多 Agent 编排、闭环自愈、Routine 脚本化听起来很强大，但并不是所有项目都需要。

如果是临时想了解一个函数怎么写，直接聊天就够了；如果项目只有十几个文件，硬拆成多 Agent 反而增加沟通成本；如果需求本身还在剧烈变化，连验收标准都没定下来，自动化的意义不大。

我的判断标准很简单：这个任务是不是高频、是否可验证、是否值得沉淀。只有这三个答案都是“是”的时候，才值得投入精力去设计编排和 Routine。

如果你刚开始尝试，我建议从小处切入：先把一个构建流程和测试流程串成最简单的自愈循环，跑通了再加一个 Review Agent，然后慢慢把日常任务固化成 Routine。不要一上来就搭一个多 Agent 大架构，那样只会让你陷入配置地狱，而不是提升效率。

我现在回过头看，最大的收益不是“代码写得快了”，而是“过程被管理了起来”。Claude Code 的真正用法，不是当一个更聪明的聊天机器人，而是把它当成一支由 Agent 组成的小队，有人负责拆任务，有人负责执行，有人负责检查，有人负责补救。你要做的事情只有两件：给出清晰的目标，以及守住不能碰的底线。