企业官网建设流程全解析

1. 撞墙那一刻：5小时配额到底卡在哪

第一次被 Claude Code 的配额墙弹脸，是在一个周四凌晨两点。当时我正在重构一个老项目的鉴权模块，上下文已经堆到 8 万多 token，CLI 里连续跑了十几轮工具调用，突然终端返回一行冷冰冰的提示，大意是本周期内的用量已达上限，请等待重置。那一刻我的第一反应不是骂人，而是意识到一个更本质的问题：我把 Claude Code 当成了一个"无限续杯"的对话窗口，但它其实是一个有明确预算约束的工程执行器。

这个认知差，是绝大多数人第一次撞墙的根源。Claude Code 的计费与配额模型，和网页版聊天窗口完全不是一回事。网页版你发一条消息，消耗一次；而 Claude Code 在 CLI 里执行一个任务，背后可能是几十次模型往返——读文件、改文件、跑测试、看报错、再改、再跑。每一次工具调用（tool use）都是一次独立的模型请求，都会计入你的用量。所以你在终端里感觉"我只问了一个问题"，实际上模型可能已经替你干了三十件事。

提示：判断自己是不是"重度消耗型"用户，看一个指标就够了——单次任务里工具调用轮次是否经常超过 15 轮。超过，你就是在高速烧配额。

我后来复盘那次撞墙，发现真正的浪费点有三个。第一，上下文没有做裁剪，把整个大文件反复塞进每一轮请求，token 消耗呈线性甚至平方级增长。第二，任务粒度过粗，我让它"重构整个鉴权模块"，而不是"先改 token 校验函数，跑通测试再继续"。第三，没有断点意识，一旦中断，前面所有上下文全部丢失，重来一遍等于把配额再烧一遍。

所以这篇东西的核心，不是教你"如何绕过配额"——那是没意义的，配额就是配额。我要讲的是：当配额墙必然出现时，怎么让工作流具备断点续传能力，把一次长任务拆成多个可恢复的短任务，让每一次中断都不浪费。这套思路我称之为"三板斧"，后面会一层层拆开讲。它适合所有把 Claude Code 当生产力工具、而不是玩具的人，尤其是那些在 CLI 里跑真实项目、动辄几小时连续作业的开发者。

2. 三板斧总览：把"一次性长跑"改成"可存档的接力赛"

在讲具体操作之前，先把整体设计思路说清楚。很多人一遇到配额问题，第一反应是去找"更省 token 的模型"或者"更聪明的提示词"，这属于战术层面的小修小补。真正管用的，是在架构层面把工作流改造成可中断、可恢复、可验证的形态。

我的三板斧，本质上是三个层次的防御：

• 第一板斧：任务切片与状态外置。把一个大任务拆成若干个"原子步骤"，每一步的输入、输出、结论都写到磁盘上的结构化文件里，而不是只存在对话上下文里。这样即使会话断了，状态还在。
• 第二板斧：上下文预算管理。给每一轮请求设定 token 预算上限，主动裁剪历史，只保留"当前步骤必需"的信息。这是省配额的关键，也是让断点续传真正可行的前提。
• 第三板斧：断点续传协议。定义一套"从哪里断、从哪里续"的约定，包括进度文件格式、恢复时的上下文重建规则、以及幂等性保证——确保重复执行某一步不会产生副作用。

这三者是有依赖关系的。没有任务切片，就没有断点可续；没有上下文预算管理，切片之后每一片还是太贵；没有续传协议，切片了也不知道怎么接回去。所以顺序不能乱。

我用一个生活化的类比帮你理解：这就像装修房子。一次性长跑相当于"请一个师傅从毛坯干到精装，中间不许停"，师傅一旦有事走了，前面砌的墙、铺的线全得重来。而三板斧相当于"把装修拆成水电、泥瓦、木工、油漆四个阶段，每个阶段结束拍照片、写验收单，师傅换人了，下一个师傅拿着验收单接着干"。配额墙就是那个"师傅必须休息"的强制中断，而三板斧让你在师傅休息时，工地状态是完整保存的。

注意：三板斧不是让你"少用 Claude Code"，而是让你"用得更有结构"。省下来的配额，最终是为了让你能跑更复杂、更有价值的任务，而不是为了省而省。

下面我逐板斧拆解，每一板斧都会给出可直接抄作业的文件结构、提示词模板和实操命令。

2.1 为什么"状态外置"是断点续传的地基

先讲一个反直觉的点：Claude Code 的会话上下文，本质上是一种易失性存储。会话一断，上下文就没了。你可能会说"不是有 --continue 或者会话恢复吗"，对，但那恢复的是"对话历史"，不是"任务状态"。对话历史里混杂着大量已经完成的、无关的、甚至错误的中间过程，恢复回来反而拖累后续判断。

真正可靠的状态，必须外置到文件系统。我习惯在项目根目录建一个.claude-workflow/目录，里面放三类文件：

.claude-workflow/ ├── plan.md # 任务总计划，拆解后的步骤清单 ├── progress.json # 进度状态，记录每一步的完成情况 ├── context/ # 每一步的上下文快照 │ ├── step-01.md │ ├── step-02.md │ └── ... └── artifacts/ # 每一步产出的实际文件（代码、报告等）

plan.md是给人看的，也是给模型看的，它定义了"我们要做几件事、顺序是什么"。progress.json是机器可读的进度账本，格式大概长这样：

{ "task": "重构鉴权模块", "steps": [ {"id": 1, "name": "梳理现有鉴权逻辑", "status": "done", "artifact": "context/step-01.md"}, {"id": 2, "name": "改写 token 校验函数", "status": "done", "artifact": "context/step-02.md"}, {"id": 3, "name": "补充单元测试", "status": "in_progress", "artifact": null}, {"id": 4, "name": "跑通集成测试", "status": "pending", "artifact": null} ] }

这个文件的价值在于：任何时候你重新打开 Claude Code，第一件事就是让它读 progress.json，它立刻知道"我干到哪了、下一步该干嘛"。不需要你重新解释背景，不需要它重新理解需求。这就是断点续传的地基。

我实测下来，这套结构让我的"恢复成本"从原来的"重新解释五分钟"降到"读一个文件三秒钟"。别小看这几分钟，配额墙往往出现在你状态最好的时候，恢复成本越低，你越不容易因为烦躁而放弃整个任务。

2.2 上下文预算：给每一轮请求装一个"油表"

第二板斧是省配额的核心。Claude Code 烧 token 的大头，从来不是你的提问，而是它自动塞进去的上下文——项目文件树、相关文件内容、历史对话、工具调用结果。这些加起来，轻松就能到几万 token。

我的做法是给每一轮请求设一个"预算上限"，并在提示词里显式约束。具体来说，在每一步开始前，我会在context/step-XX.md里只放三类信息：

1. 本步骤的目标（一句话，不超过 50 字）
2. 本步骤必需的输入（只放相关文件的关键片段，不放整个文件）
3. 上一步的结论（从 progress.json 里摘出来，不放原始对话）

然后提示词模板大概是这样：

你正在执行一个多步骤任务的第 N 步。 当前步骤目标：{目标} 必需输入：{关键片段} 上一步结论：{结论} 约束： - 只处理当前步骤，不要提前做后续步骤 - 不要读取与本步骤无关的文件 - 完成后，把结论写入 context/step-N.md，并更新 progress.json

这个模板的关键在于"不要读取无关文件"这一条。Claude Code 默认会主动探索项目结构，这在探索阶段是优点，在执行阶段就是烧钱。你明确告诉它"别乱看"，它就会老实很多。

提示：如果你发现某一轮请求的 token 消耗异常高，八成是模型偷偷读了某个大文件。养成习惯，每完成一步就cat progress.json看一眼，心里有数。

2.3 断点续传协议：定义"怎么接回去"

第三板斧是把前两板斧串起来的协议。它要回答三个问题：从哪里断的、续的时候需要什么、怎么保证不重复劳动。

我的协议很简单，就三条规则：

• 规则一：每步结束必须落盘。不管是成功还是失败，都要更新 progress.json，把当前步骤标记为 done 或 failed，并写明原因。失败也是一种状态，比"不知道干到哪了"强一万倍。
• 规则二：恢复时先读账本再干活。重新进入会话，第一句永远是"读 .claude-workflow/progress.json，告诉我下一步该做什么"。让模型自己判断，而不是你替它判断。
• 规则三：每步操作必须幂等。也就是说，同一步骤重复执行两次，结果应该一样。比如"改写函数"这种操作，如果第一次已经改好了，第二次执行应该检测到"已经是目标状态"然后跳过，而不是再改一遍改出问题。

规则三最容易被忽略，但它是断点续传的安全带。我踩过的坑是：某一步是"在文件末尾追加一段配置"，结果恢复时重复执行，配置被追加了两次，程序直接报错。后来我把所有"追加"类操作都改成了"检测-替换"模式，问题就没了。

3. 实操全流程：从任务拆解到优雅续传的完整走一遍

光讲原理没意思，我拿一个真实场景带你走一遍。场景是：给一个已有的 Node.js 项目补充完整的日志系统，涉及梳理现状、设计日志格式、改造多个模块、补测试、跑验证。这个任务如果一次性跑，大概率会在改造到一半时撞配额墙。用三板斧，我们把它变成可续传的接力赛。

3.1 第一步：任务拆解与计划落盘

我不会一上来就让 Claude Code 干活，而是先让它"只做计划，不写代码"。提示词是这样的：

我要给当前项目补充日志系统。请你先不要写任何代码， 只做一件事：把整个任务拆解成 5-8 个原子步骤， 每个步骤必须满足： - 可以在一次会话内完成 - 有明确的输入和输出 - 输出可以落盘为文件 把拆解结果写入 .claude-workflow/plan.md， 并初始化 .claude-workflow/progress.json。

这一步本身消耗很少，但它产出的 plan.md 是整个工作流的骨架。我实测下来，让模型先做计划再执行，比直接执行省 30% 以上的配额，因为它在执行时不会"边想边做"反复横跳。

拆解出来的计划大概是这样：

注意步骤 4 和 5 是分开的。很多人会把"改造所有模块"合成一步，结果就是一步烧掉大半配额。拆开之后，即使步骤 4 之后撞墙，步骤 5 还能在下一个周期继续，前面的成果不浪费。

3.2 第二步：逐步执行与状态落盘

计划落盘后，进入执行阶段。每一步我都用同一套"启动指令"：

读取 .claude-workflow/progress.json， 找到第一个 status 不是 done 的步骤， 只执行那一步。 完成后更新 progress.json， 并把本步骤的结论写入对应的 context 文件。

这套指令的好处是完全幂等。不管我什么时候重新进来，它都会自动找到"下一个该干的活"，不需要我记住进度。我甚至可以在脚本里写一个循环，让它自动一步步跑，直到撞墙为止。

执行过程中，我会盯着两个信号。一个是 token 消耗速度，如果某一步明显比预期贵，我会中断它，检查是不是上下文没裁剪干净。另一个是 progress.json 的更新频率，如果连续几步都没更新，说明模型卡住了，需要人工介入。

注意：不要迷信"全自动"。断点续传的价值在于"可恢复"，不在于"无人值守"。该盯的时候还是要盯，尤其是改造类操作，改错了文件比不改还麻烦。

3.3 第三步：撞墙后的恢复演练

假设执行到步骤 5 时撞墙了。这时候 progress.json 里步骤 1-4 是 done，步骤 5 是 in_progress 或 pending。等配额重置后，我重新打开 Claude Code，第一句话就是：

读取 .claude-workflow/progress.json 和 plan.md， 告诉我当前进度，以及下一步该做什么。 先不要执行，只汇报。

它会汇报："步骤 1-4 已完成，步骤 5 改造模块 B 尚未开始，建议从步骤 5 继续。" 确认无误后，我再发执行指令。整个过程不到一分钟，状态完全恢复。

这里有个细节：恢复时不要让它读原始对话历史。原始历史里可能有大量已经过时的中间状态，读进来反而干扰判断。只读 progress.json 和 plan.md，干净利落。这也是为什么我坚持把状态外置——外置的状态是"提炼过的"，比原始对话精炼得多。

3.4 第四步：验证与收尾

所有步骤 done 之后，最后一步是验证。我会让模型读 progress.json，确认所有步骤状态，然后跑一遍完整测试。如果测试通过，整个任务闭环；如果不通过，把失败信息写入一个新的步骤，追加到 plan.md 里，继续用同样的流程处理。

这套流程跑顺之后，我最大的感受是：配额墙从一个"灾难"变成了一个"节奏点"。以前撞墙我会烦躁，现在撞墙我就当是强制休息，反正状态都在磁盘上，休息完接着干，一点不慌。

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

这套工作流我用了几个月，踩过的坑不少，整理成一张速查表，你遇到问题时可以直接对照。

除了表格里的，再分享几个独家心得。

心得一：给每一步设一个"验收标准"。在 plan.md 里，每个步骤除了写目标，还要写"怎么算完成"。比如步骤 3 的验收标准是"logger.js 能被 require 且导出的函数有 4 个"。有了验收标准，模型自己就能判断该不该进入下一步，减少你的介入。

心得二：失败步骤要记录失败原因，不要直接删掉。我一开始失败就把步骤标记回 pending，结果恢复时模型又用同样的方式失败一次。后来我改成记录"failReason": "..."，恢复时模型会先读失败原因，换个思路再试，成功率高很多。

心得三：定期归档 context 目录。跑多了之后 context 目录会堆很多文件，虽然不影响功能，但会让模型在探索时多读文件。我习惯每完成一个大任务就把 context 归档到context/archive/，保持工作目录干净。

心得四：配额重置时间要记在日历上。不同套餐的重置周期不一样，我习惯把重置时间设个提醒，这样撞墙后知道大概等多久，心里有预期，不会干等。

5. 把三板斧用成肌肉记忆

写到这里，其实核心就一句话：Claude Code 的配额墙不可怕，可怕的是你的工作流没有断点。三板斧——任务切片与状态外置、上下文预算管理、断点续传协议——本质上是在给你的工作流加一层"存档系统"。有了存档，中断就只是暂停，不是重来。

我现在跑任何超过半小时的 Claude Code 任务，都会先花两分钟做计划落盘。这两分钟看起来是"额外开销"，但它换来的是"随时可中断、随时可恢复"的自由。实测下来，同样的任务，用三板斧的总配额消耗反而更低，因为模型不再反复重读无关上下文，也不再因为中断而重做已完成的部分。

最后分享一个小技巧：如果你经常在同一个项目上跑 Claude Code，可以把.claude-workflow/目录加进.gitignore，但把plan.md单独提交到版本库。这样团队里其他人也能看到任务拆解思路，而进度和上下文快照属于个人工作状态，不必共享。这个习惯让我在协作项目里也能放心用这套工作流，不会污染主仓库。

这套东西没有什么高深技术，就是把"工程化思维"用在了 AI 工作流上。你把它用成肌肉记忆之后，配额墙就真的只是一堵墙，翻过去就是了。