企业官网建设流程全解析

我第一次认真用 Claude Code，还是在它刚火起来那阵。坦白说，第一周我的用法和绝大多数人一样朴素——把需求敲进去，等它一段一段帮我改代码。那会儿我觉得它就是个终端里的高级问答机：报错贴进去，它给修复方案；方案不行，我再贴新报错，它再给新方案。就这么一轮一轮磨，效率不能说没有，但真的很像在“手摇发电”：每一步都靠我盯着，靠我把上一个回合的结论手动搬进下一个回合。

后来接触了多 Agent 编排、闭环自愈这些概念，再配合 Routine 脚本化架构把流程固化下来，我才发现自己之前对 Claude Code 的用法完全是在浪费它的能力。这篇文章我想把这三件事彻底讲明白：它们分别解决什么问题、底层是怎么转的、你在真实项目里应该怎么落地。文章末尾我也会聊到从安装到接入本地模型、第三方模型服务的完整配置，毕竟连不上模型、配不好 IDE，后面的一切都是空谈。无论你是刚开始用 Claude Code，还是已经用了一段时间但总觉得差点意思，这篇都值得花十分钟读完。

1. 从一问一答到流水线：单步聊天为什么撑不起真实工程

很多人（包括一开始的我）把 Claude Code 当成一个增强版 ChatGPT 来用。你问一句，它答一句；你发现哪里不对，再补一句。这种模式在改一个孤立函数的时候勉强够用，但只要任务范围一大，问题立刻露出来。

1.1 单步聊天的本质：你成了人肉上下文搬运工

单步聊天最大的问题不是“慢”，而是上下文断裂。我给你讲个具体场景：我让 Claude Code 帮我修一个接口报错，第一轮它看完堆栈给了个猜测，我去改；第二轮报错变了，它又给新的猜测；第三轮发现第一轮的改动影响到了另一个模块。这时候我得自己手动汇总前两轮的结论，还要重新跟它解释这个项目的目录结构、依赖关系、命名规则。换句话说，模型本身没有“任务所有权”，它不记得自己上一轮做了什么，也不负责验证结果到底通没通过。

你可以把这种模式想象成流水线上只有一台机器，而且每加工完一个零件，机器就把图纸扔掉，等着你重新把下一张图纸递过来。短期任务还能忍受，一旦任务链条超过五步，人工搬运上下文的成本就会指数级上升。我见过不少朋友抱怨“Claude Code 越用越蠢”，其实不是模型变傻了，而是你一直在用单步聊天这种最原始的方式驱动它，它根本没有机会形成全局视角。

1.2 从“聊天”切换到“派活”：三个关键转变

要摆脱单步聊天的困局，我总结下来要做三个转变：从“描述问题”变成“描述目标”；从“逐轮确认”变成“一次授权”；从“输出文字”变成“验收结果”。

具体来说，以前我是这么说的：“帮我看看这个 UserService 的报错，我觉得可能是 Redis 连接的问题。”这属于描述问题，而且把怀疑塞给了模型，它很容易被你带偏。现在我会这么派活：“在 UserService 里排查登录接口偶发超时的根因，定位到问题后直接修复，并跑一遍项目现有的单测确认没有回归。如果遇到需要我决策的地方，停下来问我，不要自作主张下结论。”注意区别：我给了目标、给了边界、给了验收标准，也给了决策的触发条件。

这三个转变看起来简单，实际影响非常大。目标清晰之后，Claude Code 会自己规划步骤、自己安排检查点，而不是你推一步它走一步。一次授权意味着它可以连续执行多条终端命令、多次文件编辑，不再每做一步都回来问你“要不要继续”。验收结果则逼着它把话说完整：改动是否能通过测试，性能有没有恶化，文档有没有同步更新。做到这三件事，你才算真正从“聊天模式”切换到了“协作模式”，后面的多 Agent 编排、自愈循环、Routine 脚本化，全都是在这个基础上长出来的能力。

2. 多 Agent 编排：把一个大型任务变成一支能协作的团队

当你习惯了让 Claude Code 一口气干完整个任务，下一个瓶颈很快会出现：任务太大，单个 Agent 的上下文窗口装不下，或者装得下但精力过于分散。这时候就该引入多 Agent 编排了。

2.1 为什么要拆：超大 Agent 干活反而更慢

很多人有个误解，认为模型上下文窗口越大，就越应该把所有东西一股脑塞给同一个 Agent。我实际测下来，结论恰恰相反。当一个 Agent 既要看后端接口代码、又要管前端组件、还要兼顾数据库表结构时，它的注意力会被均匀稀释，经常出现“改对了 A 却破坏了 B”的情况。而且上下文一长，模型很容易“忘掉”早期给它的约束条件，你明明在第一轮说过不要动公共工具类，它改到后面还是动了。

类比一下就明白了：你让一个全能型员工做一套完整系统，他也能做，但他需要切换上下文、回忆各种细节，效率一定比一个三五个人的专业团队低。多 Agent 编排的核心思路就是各管一段、上下文隔离：每个子 Agent 只看到自己负责范围内的文件、命令和规范，把不确定性锁在局部，再由主导 Agent 统一汇总和决策。

2.2 Claude Code 里的三套编排姿势：主从派发、流水线、并行分组

在实际使用中，我总结出三种最常用的编排模式，你可以按任务性质选。

主从派发模式适合“先规划、再执行”的任务。主导 Agent 先读取项目结构、理解需求，拆出若干个子任务，然后通过 Task 工具把子任务分别交给专门的子 Agent。比如前端 UI、后端接口、数据库迁移各派一个。子 Agent 干完把结果汇报回来，主导 Agent 负责整合和最终检查。这种模式的好处是每份上下文都很干净，失败时也能立刻定位是哪个环节出的问题。

流水线模式适合有严格先后依赖的任务。比如先让“分析 Agent”梳理现有代码并输出问题清单，再让“改造 Agent”按问题清单逐项修改，最后由“验证 Agent”跑测试并输出报告。每个 Agent 的输入是上一个 Agent 的输出，链路上没有交叉干扰。这种模式有点像工厂产线，上一道工序不合格，产线就不能往下走。

并行分组模式适合互不依赖的批量任务。比如项目里有十几个独立的 ESLint 报错文件，或者十几个需要加注释的模块，我会拆成几组并行处理，最后统一汇总 diff。并行分组对算力消耗比较大，但对时间敏感的场景非常划算。

2.3 实测：用编排模式跑通一个前后端小项目

说个我印象比较深的实操案例。有一次我在本地起一个新项目，要求是一个带用户登录的前后端分离 demo。我如果按老办法用单步聊天，光是前后端目录结构、依赖版本、联调接口就得来回沟通二三十轮。后来我改成了编排模式：先让一个“需求分析 Agent”读我写的需求文档，输出一份接口契约和目录规划；再把这份契约分别派给“前端 Agent”和“后端 Agent”并行开发；等两边都完成后，叫一个“测试 Agent”启动服务、跑接口用例，把失败结果返回给后端 Agent 修。

一轮跑下来，最直观的感受是上下文的噪音没了。前端 Agent 从头到尾只见过前端目录，它不会因为看到了后端的奇怪代码而分心；后端 Agent 只需要对着接口契约实现，不用操心页面长什么样。最终落地时间比单步聊天快了大概一倍，而且出错的位置集中在接口契约本身，修正一次就全局生效。这个经历让我彻底相信：多 Agent 编排不是花架子，它是让 Claude Code 从“小工”变成“工程负责人”的关键一步。

3. 闭环自愈：让 Agent 自己发现问题、自己修正、自己验证

编排让多个 Agent 协作干活，但无论怎么拆，执行过程中一定会有失败和报错。如果每次失败都要你盯着、把错误贴回去、等它重新调整，那效率还是会大打折扣。这时候就需要第二个机制——闭环自愈。

3.1 一个能自愈的 Agent 到底在循环里做什么

闭环自愈不是指 Agent 能神奇地不出错，而是指它知道自己出错了，并且能在这个信息回传之后自己调整。完整的链路是：目标注入 → 执行动作 → 获取反馈 → 判断偏差 → 修正动作 → 再次验证。你发现没有，关键点在于“反馈”必须真实地回到决策端，而不是由你人工转述。

举个最常见的场景：Claude Code 修改了一个 Python 文件，然后自己执行pytest，看到测试失败，它需要读取失败信息、定位是哪个逻辑导致、修改代码、再跑一次测试。这个循环可以重复若干次，直到测试通过或达到重试上限。整个过程中，你只需要在一开始告诉它“目标是通过所有测试”，剩下的事情它自己转。如果没有这个闭环，执行完一个动作它就会停下来等下一个指令，和你用单步聊天没有任何区别。

闭环自愈还有一个隐藏的好处：它让 Agent 学会了“验证”而不是“猜”。单步聊天里模型经常说“我觉得应该没问题了”，因为它没有手段去确认。而闭环模式下，模型会自己跑测试、跑 lint、跑构建，看到真实的绿灯和红灯。验证能力一旦被激活，模型的判断质量会有质的提升，因为它不再依赖幻觉式的自信，而是依赖环境反馈。

3.2 在 Claude Code 里把自愈转起来：Harness 循环与 Hook 回调

Claude Code 能实现闭环自愈，背后有两个关键机制：Harness 控制循环和Hook 回调体系。

Harness 可以理解为驱动 Agent 的外层执行框架。它负责把用户的目标转成一个可以被机器循环执行的任务队列，每次 Agent 行动完成后，Harness 会检查当前状态是否满足“完成条件”，不满足就继续循环。你在实际操作时，可以在任务描述里明确写上“最多重试三次，每次都要把测试结果告诉我”，这样 Harness 就会严格按这个边界去执行，不会无限跑下去。

Hook 回调则更像是你给 Agent 装上的“自动检测仪器”。Claude Code 支持很多钩子事件，比如工具调用前触发、工具调用后触发、会话结束前触发等等。我常用的做法是在PreToolUse和PostToolUse里挂上脚本：比如每次 Agent 执行完文件编辑，自动跑一遍eslint，如果有报错，就立刻把报错内容作为新上下文塞回给 Agent；或者每次执行完测试命令，自动把覆盖率摘要交给主导 Agent 判断。这样一来，Agent 不需要“想起来”要验证，而是环境主动推着它完成验证。

下面是一个很典型的 Hook 配置片段，我把 lint 和测试的自动检查挂到了每次工具调用之后：

{ "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "cd $CLAUDE_PROJECT_DIR && eslint . --format compact || echo 'ESLINT_FAILED'" } ] }, { "matcher": "Bash", "hooks": [ { "type": "command", "command": "if [ \"$TOOL_INPUT\" = \"pytest\" ]; then pytest --tb=short; fi" } ] } ] } }

这个配置想表达两件事：第一，只要 Agent 改了文件，eslint 的结果就要回来；第二，如果 Agent 执行了pytest命令，测试输出就必须被完整记录下来。这些反馈进入上下文后，Agent 的下一次动作就会基于真实的报错去修正，而不是凭感觉乱改。

3.3 给自愈加护栏：别让 Agent 变成“无限盲改怪”

闭环自愈听着美好，但你如果不管控，很容易变成另一个极端：Agent 反复试错但始终过不了验证，白白消耗时间和 tokens。我见过最离谱的一次，是某个 Agent 因为一个变量名大小写问题，连续改了十二次，每次都换一个不相关的地方，越改越离谱。所以护栏一定要提前设计好。

我常用的护栏有三个。第一个是重试次数上限，任何任务都必须明确规定最多循环几轮，超过就停下来向你汇报，让你人工介入。第二个是验证标准前置，任务一开始就说清楚“什么算通过”，比如测试全绿、lint 零报错、构建产物小于某个体积。第三个是变更记录审计，让 Agent 在每一轮循环里都要输出“改了哪个文件、为什么改、验证结果如何”，这样即使循环失败，你也能看到整个试错路径，不至于两眼一抹黑。

我把有无护栏的效果整理成了一张表，供你参考：

我自己现在的习惯是，比较大的任务永远开启护栏，小的临时需求才允许自由试错。自由试错有时候能发现一些你没想到的解决方案，但有护栏才叫工程化，没有护栏只能叫碰运气。

4. Routine 脚本化架构：把高频操作沉淀成可复用、可自动触发的流程

多 Agent 编排解决的是“任务并行”的问题，闭环自愈解决的是“执行反馈”的问题。但还有一个问题被很多人忽略了：同一个项目里，很多流程是重复的。比如每次开发前拉最新代码、跑测试、清理日志；每次上线前做代码检查、构建、生成变更记录。这些流程第一次靠对话驱动没问题，第二次、第三次你还靠对话重新描述一遍，就太蠢了。Routine 脚本化架构，就是把这类高频流程固化成 Agent 每次都能自动加载和执行的“操作手册”。

4.1 为什么要做脚本化：重复让 AI 干活的前提是流程先标准化

我在最开始用 Claude Code 的时候，每周都要花不少时间重复描述一套固定流程：“先看下 git 状态，把最近的提交整理一下，然后跑一遍测试，最后按模板写个周报。”描述得再熟练，每周也至少浪费三四轮对话。更要命的是，每次描述都会有一些细微差异，Agent 的执行路径也跟着变，上周好用这周就不好使了。

Routine 脚本化的思路是：先把流程写成标准文档，再让 Agent 按照文档执行。这样有几个肉眼可见的好处：第一，你不需要每次都解释背景，Routine 文档里写清楚了；第二，执行过程可复现，不会因为你的表达差异导致 Agent 行为漂移；第三，Routine 可以搭配参数、入口和 Hook 自动触发，真正做到“一键执行”甚至“无需执行，自动触发”。

4.2 写一个可执行的 Routine：目录结构与文档模板

官方对 Routine 的定义可能不同环境略有差异，但我在项目里的落地方式非常统一：在项目根目录维护一个routines/目录，每个 Routine 是一个 Markdown 文件，文件名就是流程名。然后在CLAUDE.md里加一段指引，告诉主导 Agent 哪些场景应该去读取哪个 Routine。

一个规范的 Routine 文档，我总结下来至少要有五个部分：

1. 触发场景：什么情况下应该使用这个 Routine，避免 Agent 误触发。
2. 执行步骤：按顺序列出的操作步骤，每个步骤要具体到命令或产出物。
3. 验证标准：执行完之后的验收条件，例如测试全绿、构建通过、文件格式正确。
4. 退出条件：哪些情况应该停止执行并请求人工介入。
5. 变更记录：本次执行的偏差和改进建议，方便日后迭代。

下面是我项目里一个“周报生成”Routine 的简化模板，可以参考：

--- name: 周报生成 trigger: 每周五下午当用户说“生成周报”时触发 --- ## 1. 目标 基于最近的 git 提交记录，生成一份本周工作周报。 ## 2. 执行步骤 1. 运行 `git log --since="last week" --oneline --no-merges` 获取提交列表。 2. 按模块分类提交信息，统计关键改动和影响范围。 3. 读取 `routines/templates/weekly-report.md`，按模板填充内容。 4. 输出周报到 `docs/weekly/` 目录。 ## 3. 验证标准 - 周报必须至少包含本周提交数、主要改动点、待办事项三项。 - 未完成的任务必须明确标注出来。 ## 4. 退出条件 如果本周提交记录为空，停止执行并告知用户。

4.3 让 Routine 自动触发：启动参数与 Hook 事件两手抓

文档写好了，但如果你还是每次手动把文档路径贴给 Agent，那脚本化的意义就少了一半。真正的自动触发有两种做法。

第一种是启动参数绑定。Claude Code 支持通过命令行参数指定初始任务，比如claude -p "按照周报生成Routine执行"，配合 IDE 快捷键或者 shell 别名，一条命令就能拉起整个流程。如果是项目内有固定流程，可以在项目级配置里加上默认的 Agent 行为，让它在启动时先加载routines/README.md摸清有哪些可用的 Routine。

第二种是Hook 事件触发。比如有些项目我在提交代码前想自动跑一遍完整的“发布前检查”Routine，那我可以把 Routine 的执行命令挂到 Git 的 pre-commit hook 上，或者挂到 Claude Code 的工具调用事件上。只要你进入某个状态（比如修改了特定目录的代码），Hook 就会把对应的 Routine 文档注入上下文。我尤其推荐把 Routine 和闭环自愈结合：Routine 负责定义“做什么”，Hook 负责触发“什么时候做”，自愈负责“出错了怎么办”。三者组合，基本上就是一个非常完整的自动化工作流。

4.4 Routine 需要持续演化：执行记录与复盘更新

很多人写完 Routine 文档就再也不动了，这是不对的。Routine 不是一次性的文档，它会随着项目演进慢慢过时。比如你以前的上线检查只需要构建和测试，现在多了一步“迁移数据库”，如果你不更新 Routine，Agent 就永远不知道这件事。

我的习惯是：每次执行完 Routine 后，都要求 Agent 在文档末尾追加一条“本次执行备注”，记录实际做的步骤和文档的差异。攒够几轮之后，我再集中决定要不要更新正式流程。另外，一个 Routine 如果连续三次执行都没有任何偏差，说明它已经很稳定了，这时候可以考虑把它从“文档驱动”升级成“脚本驱动”或者自动触发，进一步减少人工参与。反过来，如果某个 Routine 频繁出现偏差，那大概率是流程设计或者验证标准写得不够清楚，我会优先重写验证标准，而不是简单堆执行步骤。

5. 从安装到接模型：让 Claude Code 进你的日常工作流

前面讲了一堆编排、自愈、Routine 的架构思路，但你如果刚接触 Claude Code，第一关其实是环境准备。这一章我完整过一遍从安装到接入 LM Studio 本地模型、DeepSeek/Qwen/GLM 等第三方模型服务的全过程，顺便把容易踩的坑一并说了。

5.1 安装、命令行检查与 IDE 集成的完整流程

Claude Code 的安装门槛不算高，但有几个前置条件值得注意。在 Ubuntu 和 macOS 上，我推荐的安装方式是直接通过 npm 安装：

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

安装完成后运行：

claude --version

能正常输出版本号，说明安装成功。需要注意的是，Node.js 版本不要太老，建议 18 以上，否则某些依赖会装不上或者运行时行为异常。Windows 上我也见过不少人在折腾，建议优先在 WSL 里使用，原生 CMD 环境下有些 ANSI 转义和路径处理会让终端输出非常难受。

装完之后，日常使用就是在终端敲claude进入交互式会话。如果你习惯在 VS Code 里开发，可以装官方的 Claude Code 插件。装了插件之后，你可以在编辑器里直接打开终端面板运行claude，也可以选中代码片段直接发送给 Agent 作为上下文。这个集成对做代码审查特别方便：选中一个函数，输入“帮我指出潜在问题”，Agent 就能基于当前文件内容直接回答，省去了一堆手动复制粘贴。

5.2 接本地模型和第三方 API：LM Studio 与国产模型服务配置实操

Claude Code 的默认后端是 Anthropic 自己的模型，但很多场景下你可能想接本地部署的模型，或者接 DeepSeek、Qwen、GLM 这些第三方模型服务。这个需求在社区里非常活跃，我实测下来有两种主流方案。

第一种是直接用环境变量指向兼容的 API 端点。Claude Code 本身支持通过环境变量配置 API 地址和密钥，当你把它指到任何兼容 OpenAI 格式的服务时，就可以绕过默认后端。举两个例子。

接 LM Studio 本地模型的思路是这样：先在 LM Studio 里加载好模型并开启本地服务，默认端口一般是一串固定地址。然后启动 Claude Code 前设置：

export CLAUDE_CODE_USE_LOCAL_MODEL=1 export OPENAI_API_BASE=http://localhost:1234/v1 export OPENAI_API_KEY=lm-studio claude

这样 Claude Code 会走 LM Studio 提供的本地推理接口，不需要把代码和对话内容发到外部服务。对隐私敏感的项目来说，这种本地模型的方案我很推荐，代价是模型能力一般弱于云端旗舰模型，复杂代码推理会有差距。

第二种是用CC Switch 之类的模型切换工具接入 DeepSeek、Qwen、GLM 等模型服务。这个工具本质上是一个配置管理器，帮你统一维护多个模型服务的 API 地址、密钥和模型名称，切换时只需要一条命令或者一个交互菜单，不需要手改环境变量。我个人觉得这种工具的定位很像“遥控器”：把底层的复杂配置藏起来，只暴露一个简单的切换入口。

配置好之后，你可以在 Claude Code 里发一个简单的任务测试链路是否通，比如“读取当前目录结构并输出一份项目概览”。如果模型能正常响应，说明端到端配置没有问题。

5.3 配置和使用中的几个高频坑与我的处理方式

配置这块我踩过的坑不少，挑几个最常见的说。

第一个坑是API 地址写错导致一直超时。有的模型服务端点是/v1，有的是自定义路径，配置错了表面上看起来是连不上，实际是路径不匹配。排查方法很简单，先用 curl 手动请求一下你配置的端点，确认能返回正常的结果，再启动 Claude Code。小成本验证，能帮你省掉大把浪费时间。

第二个坑是上下文长度和响应上限。本地模型往往对超长上下文支持不佳，你在 Claude Code 里一旦把项目整个塞进去，很容易触发超长警告甚至直接中断。解决方法是按目录范围来限定 Agent 的读取范围，比如明确告诉它“只看 src/auth 目录下的文件”，或者定期使用会话压缩命令，把早期的非关键内容折叠掉。

第三个坑是Agent 执行了危险的终端命令。多 Agent 编排和自愈循环一旦跑起来，Agent 操作权限很大，它可能自己执行rm -rf、覆盖文件、安装依赖。我的处理方式是尽量使用沙箱环境，或者提前在配置里把终端命令白名单收紧，只允许常见的git、npm test、python这些命令，其他高危操作必须经过确认。安全这件事永远不能指望模型自觉。

最后一个我特别想提醒的坑是：不要在一个长时间会话里反复切换模型。很多模型切换工具虽然方便，但切换后历史上下文的兼容性会出问题，经常出现新模型看不懂旧对话的情况。我现在的习惯是一个会话固定用一个模型，需要换模型就直接开新会话，保持上下文的干净统一。

关于 Routine 脚本化架构，我再分享一个实际操作中的体会：把 Routine、Hook 和自愈组合起来跑通之后，你的开发模式会从“频繁介入式”变成“异常驱动式”——只有 Agent 遇到它无法决策的问题时你才出场，绝大多数重复流程它自己就消化掉了。这个转变带来的效率提升，远比你在聊天里省下的几轮对话更明显。