企业官网建设流程全解析

Claude Code 用到现在，我越来越觉得它不像一个简单的问答工具，更像一个驻留在终端里、真正能帮你动手改代码的协作者。前两篇笔记里我写过基础交互和单任务开发，这篇想集中聊一个我最近大量使用的场景：多任务并行开发。

所谓多任务并行，说人话就是你手上有好几个需求或缺陷在同时推进，而不是一次只盯一件事。以前我习惯在一个 Claude Code 会话里来回切换，让 Claude 一会儿改这个模块，一会儿改那个模块。结果经常翻车：它把 A 任务的约束带进 B 任务，改了不该改的代码，甚至聊着聊着就忘了最早的需求。后来我摸索出一套组合打法：会话隔离、分支隔离、任务卡，才真正把并行节奏跑顺。

这篇笔记适合已经会 Claude Code 基础操作、但正在被多任务切换折磨的开发者。如果你刚开始接触，建议先读前面两篇，把基础交互和单任务流程过一遍；如果你已经在真实项目里用了，那这篇文章里的大部分坑你应该都见过。我会从为什么单会话会失灵讲起，再给任务拆分、多会话实操、上下文管理和排障的完整方案。

1. 为什么“一个会话干到底”在多任务场景会失灵

1.1 单会话的上下文诅咒

Claude Code 的工作方式是沿用一个对话上下文，它会把你粘贴的代码、执行的命令、修改结果都记在会话历史里，然后基于这些历史做出后续判断。这是它强大的地方，也是它脆弱的地方：上下文窗口是有上限的，一旦任务多、历史长，模型很容易把早期指令忘掉，或者把不同任务的约束混淆在一起。

我有一次在同一个会话里先做接口重构，又顺手修了一个样式问题。结果 Claude 在后续修改中一直认为样式类名要从新接口方案里找，实际那是另一个任务的分支内容。这就是典型的上下文污染。我自己的经验是：一个会话里聊的任务越多，上下文越像一锅粥，最后变成你不断纠正它，比你自己写代码还累。

生活里也好理解：你让一个人同时跟三个项目组对接，他大概率会在 A 项目会议上说出 B 项目的术语。上下文窗口不是无限大的，任务太多，模型只能挑选它认为重要的信息，而这些信息往往是最近的、最显眼的，不一定是正确的。线程一旦堆高，早期的关键约束就会像掉进碎纸机一样找不回来。

1.2 手动切换任务的隐性成本

如果单会话不行，手动切换呢？我试过在同一个会话里用“现在切换到任务 B”来切换，刚开始有效，但多切换几次之后，Claude 会陷入一种混乱。原因其实也不难理解：它一直是同一套权重、同一个历史，你要它硬切，它很难彻底抹掉前面的任务记忆。

更关键的是，你自己也有切换成本。你需要在切换前记录进度、切换后重新描述需求、检查它有没有碰错文件、再补跑一遍测试。这一套下来，所谓“并行”已经退化成“串行加返工”。

我整理过一张对比表，贴在下面，方便你直观感受两种方式的差异。

这个表基本就是我后来的方法论雏形。说白了，并行开发要解决的不是简单地把几个任务丢给同一双眼睛，而是让每个任务都有自己的眼睛和手。单会话内切换再怎么小心，也只是在一个工作台上换图纸；多会话加分支隔离，才是真正给每个任务搭了一个独立工位。理解到这一步，后面所有操作都顺理成章了。

1.3 为什么说“会话就是工作台”

Claude Code 本身允许多个终端同时运行多个会话，每个会话有自己独立的上下文，互不共享，也不互相污染。这就像给每个任务开了一个独立的工作台，上面只放这个任务的图纸和工具。你不需要重新学习什么复杂工具，多会话说白了就是多开几个终端窗口而已。

要利用这个能力，最自然的做法就是配合 Git 分支。一个任务一个分支，一个分支开一个会话。这样代码层面有隔离，AI 上下文层面也有隔离，两边都能保持干净。哪怕两个任务最终要合到一起，合之前各自的改动也互相不影响。

我第一次用这种方式并行三个任务时，感受非常明显：每个会话都很专注，Claude 的反馈质量高了很多，不再出现那种改 A 碰 B 的情况。只要我每次开会话前把任务描述讲清楚，它就像认领了专属职责的员工。接下来要做的，就是在开工之前把任务拆得足够适合并行。

2. 并行开发前：任务拆分与边界划定

2.1 什么样的任务适合并行

不是所有任务都适合并行。我之前吃过亏，在没有做好拆分的时候就开三个会话并行，结果两个任务都改同一个模块，最后合并时冲突一堆，比串行开发还慢。现在我判断一个任务适不适合并行，基本看三条标准。

依赖明确：这个任务依赖的接口、数据、文件都比较清楚，不需要中途频繁找另一个任务的产出。文件边界清晰：要改动的文件跟其他任务的改动基本没有重叠，尤其是不会同时改同一个文件的核心区域。验收独立：可以单独写测试、单独验证结果，不需要等另一个任务完成才能判断对错。

如果三条里有一条不满足，说明这个任务更适合串行或者先做依赖准备。举个反例：全局配置、跨模块数据流重构、需要频繁跟设计对齐的探索性需求，这类任务往往牵一发动全身，强行并行只会让两个会话互相打架。反过来，像“给模块 A 补一套参数校验并加测试”、“新增一个独立脚本用于日志归档”，这类边界清晰的小任务就非常适合并行。它可以像一个流水线上不同工位，互不干扰。

2.2 给任务写一张“任务卡”

并行开发最怕的是任务边界只在你的脑子里，而你的脑子又被好几个会话同时占着。所以我会把每个任务的关键信息落到一张任务卡上，放在仓库的 docs/tasks/ 目录下。任务卡我一般用 Markdown 写，模板长这样：

# 任务卡：TASK-003 日志归档脚本 ## 目标 新增一个独立脚本，把 logs/ 下的过期日志按日期打包并清理。 ## 涉及文件 - scripts/archive_logs.sh - tests/test_archive_logs.sh ## 约束 - 不修改现有部署流程 - 不删除 7 天内的日志 - 所有命令可通过 --dry-run 预览 ## 验收标准 - 能按日期归档，留 7 天 - 测试脚本通过 - 不影响其他模块 ## 当前状态 - [x] 已确认需求 - [ ] 脚本实现中 - [ ] 等待测试

写任务卡有两个直接好处。第一，它把任务边界显式化，Claude 开新会话后只要读这一份文档，就能快速进入状态；第二，它也是你跟 Claude 之间的“合同”，验收标准写清楚之后，Claude 就知道做到什么程度算完，不会自己发挥。如果你嫌每次手写麻烦，可以把模板放进仓库根目录，或者在项目的说明文件里写明任务卡的组织方式。这样新会话启动时，它自己就知道该去翻哪些文件。

有个细节值得多说一句：任务卡里的“约束”不要写得太大而空，要写那种能直接拦住 AI 的条款。比如“不修改现有部署流程”就比“保持系统稳定”有用得多。AI 对具体禁令的遵守程度，远高于对模糊价值观的理解。

2.3 分支策略：一个任务一个分支

任务卡决定上下文的边界，Git 分支则决定代码的边界。我的习惯是每个任务对应一个独立分支，命名上直接用任务编号，方便对应。比如 feature/task-003-log-archive、fix/task-007-list-sort。分支命名里带上任务编号，省得靠记忆去猜。

开会话前，先切换到对应分支，再启动 Claude Code。这样就算 Claude 误操作了，最坏情况也只污染当前分支，不会影响其他任务。主分支我向来保持可部署状态，所有并行任务的分支都是临时工作区，各自测试通过之后，才按顺序合入主干。

这里有个小建议：合入顺序不要随机，优先合入对其他任务影响最大的那个，剩下的冲突会少很多。另外，如果某个任务的分支已经长期没有更新，并且跟主干产生了大量偏差，我通常会先把主干合并回来再继续开发，而不是把冲突拖到最后一次性处理。这个习惯能省下不少合并时的头疼时间。

3. 实操：用多个会话并行推进开发

3.1 终端布局与会话启动

多会话最朴素的做法就是多开几个终端窗口。我自己的习惯是用 tmux 开一个大的工作窗口，然后按任务数量切成左右分屏，有时候也切上下。这样三个任务并行时，三个 Claude Code 会话同时摆在眼前，哪个任务有输出一眼就能瞟到。启动流程大概是这样：

1. 在 tmux 里新建窗口或分屏，进入项目仓库根目录。
2. 执行 git checkout feature/task-003-log-archive，切到对应分支。
3. 在该目录下运行 Claude Code 的启动命令进入交互界面。
4. 把任务卡路径作为第一条指令发给会话，让它先读任务卡再开工。

这里有一个小细节：建议在同一个仓库根目录下切换分支来开不同会话，而不是把仓库 clone 好几个副本。原因很简单，同一份仓库只依赖一个本地索引和缓存，多个 clone 副本容易让工作目录状态和任务分支错乱，也会加大本地磁盘和索引的负担。你只需要保证每个终端窗口当前所在分支各不相同即可。实测下来，这个方式最省心。

3.2 会话初始指令模板

给每个并行会话的初始指令，我会尽量模板化，避免每次手打一大段。下面是我常用的模板，你可以直接复制改一改：

你是 TASK-003 的专属开发助手。 第一步：阅读 docs/tasks/TASK-003.md 任务卡。 第二步：查看当前分支的 git status 和相关代码结构。 第三步：在不修改任务卡之外文件的前提下，开始实现任务。 约束： - 只修改任务卡“涉及文件”中列出的文件； - 执行任何可能产生破坏性影响的命令前先问我； - 每完成一个阶段，用一句话更新任务卡“当前状态”。 开始之前，先告诉我你理解的任务范围和边界。

这段指令包含三个关键作用：让 Claude 锁定任务范围、明确文件边界、约定沟通方式。实测下来，真正起作用的是前两条。没有这两条，它有时候会因为自己的“顺手”去改无关文件，这种改动概率不大但破坏力很强。

模板里提到“先告诉我你理解的任务范围”也有价值。它强制 Claude 在动手前复述一遍，你可以借机判断它有没有理解偏，发现偏了及时纠正，而不是等它把代码写完才发现方向错了。这个“动手前复述”的动作，是我用过所有 AI 编程工具里性价比最高的习惯，强烈建议保留。

3.3 进度落盘与任务恢复

并行开发最尴尬的场景不是并行阶段手忙脚乱，而是并行结束、过了一天，你想回来继续某个任务，结果发现当时忘了留下进度记录。AI 会话可以重开，但上下文记忆不会自动回来。所以我的纪律是：每个会话结束前，让 Claude 输出一段进度摘要，然后我把这段摘要写进任务卡里。

摘要不用很长，包含三块就够：已完成的内容，尽量具体到文件和函数；当前阻塞点，哪些问题没解决、为什么没解决；下一步计划，下次进来从哪开始。恢复阶段的指令也很简单：

读取 docs/tasks/TASK-003.md，先不要改代码。根据“当前状态”和“进度摘要”，告诉我你准备从哪儿继续，有什么需要确认的点。

这样即使隔了一整天，只要任务卡在，我花一分钟就能让 Claude 回到接近原来的状态。损失的无非是一点时间，但不会出现“它完全不记得这个任务”的断档。如果你连进度摘要都没留，还有个补救办法：把之前的 git diff 或最近提交记录喂给新会话，让它通过代码状态反推上下文。虽然不如任务卡直接，但至少能接回大部分上下文。

3.4 并行会话的检查节奏

并行开发不代表把三个会话丢在那当甩手掌柜。我一般会设定一个检查节奏，大约每隔二十到三十分钟切到每个会话看一眼输出，重点看两点。

第一，git status 是否发现它改了预期之外的文件。如果发现多余改动，立刻喊停，把它约束回任务卡范围内。第二，测试是否阶段性地在跑。Claude Code 能直接执行命令，我倾向于让它每完成一个可验证的小里程碑就运行一次相关测试，而不是攒到最后一次性验证。

还有一条经验：开发阶段可以并行，但评审阶段尽量串行。并行跑测试可以，但每个分支合入主干的 code review 我建议一个一个来。原因很简单，review 需要集中注意力，一次性看三个任务的 diff，很容易看漏。分批串行 review 虽然花的时间长一点，但质量会明显更稳。这条经验是我在连续两次合并出线上问题之后总结出来的。

4. 并行会话的上下文与资源管理

4.1 一个会话只对应一个任务

上下文管理的第一条原则：一个会话只对应一个任务。不管这个任务是开发、修 bug 还是重构，都别跟其他任务混在一个会话里。道理前面已经说过，上下文窗口是有限的，哪怕你及时清理历史，也不可避免会有一些残留影响。与其跟它对抗，不如从源头约束。

我见过有人在一个会话里同时带三个需求，每次切换靠文字说明，结果 Claude 越到后面越迷糊，回答的置信度也肉眼可见地下降。这里有一个反直觉的点：很多人觉得“开新会话 = 重新解释 = 浪费时间”，但实际经验是，新会话把任务卡读一遍的成本，远低于在一个混着三个任务的会话里反复纠错、反复澄清的成本。宁可每次都从任务卡开始，也不要在旧会话里硬扛。

我自己踩过最痛的一次，是在一个会话里塞了五个小需求，最后 Claude 把其中一个需求的验收标准套到了另一个需求上，导致我花了整整一个下午改回来。从那以后，我给自己定了一条死规矩：一个会话，一张任务卡，一个任务。

4.2 上下文压缩与会话重置

即使一个会话只对应一个任务，单任务周期长了，上下文也会越堆越长。尤其是你让 Claude 频繁读文件、跑命令、修改代码之后，历史里的代码片段会快速增长。这时候我会做两件事：压缩或重置。

Claude Code 的交互界面里提供了清理和管理上下文的手段，比如清空当前对话、压缩历史等。不同版本命令细节可能不一样，你可以在会话里直接问它有哪些上下文管理命令。我不会把具体命令死记硬背，因为版本更新换代挺频繁，记命令不如记思路。

压缩之后，会话会损失部分早期细节。所以我在压缩前会先让 Claude 把当前进度摘要写出来，存在任务卡里。重置同理。只要任务卡里信息够足，新会话就能快速接上；如果任务卡信息不足，重置前先补齐再动手。这个小习惯帮我省了不少资源，因为长上下文的消耗跟长度正相关。这不是一笔小钱，后面专门说。

4.3 并行数量、时间与资源消耗的权衡

并行会话数越多、单会话上下文越长，token 消耗自然越大。我自己的体会是，普通仓库里开 2 到 3 个并行会话是比较舒服的区间：既有并行收益，又不会让输出速度和消耗费用跑飞。

同时开 5 个以上会话我也试过，结果有几个问题：每个会话都在高频读文件和分析代码，输出会明显变慢；你切来切去也容易漏掉某个会话的异常动作；费用账单更是肉眼可见地暴涨。所以我现在倾向于分批并行：第一批并行 2 到 3 个任务，完成并关闭会话之后，再开下一批。这样开销可控，节奏也更稳。

另外，有些会话不是一直在干活，可能挂着等某个依赖。这种挂机的会话也要及时关掉，别让它躺在后台持续消耗。等依赖就绪、可以开工时，再根据任务卡恢复，成本更低。并行数量的控制不是死规定，但它能帮你把有限的精力放在真正需要盯的事情上。

5. 常见翻车场景与排查实录

5.1 任务串台：Claude 改了别的任务的代码

这是并行开发里最经典的翻车。现象就是，你在 TASK-003 的会话里安排工作，结果它顺手改了 TASK-004 才应该改的文件。我第一次遇到时很懵，因为我的任务卡已经写了边界，但那个边界只写在指令里，没有体现在 Git 分支上。后来我改成每个会话都先在对应分支上启动，再从任务卡开始读，这个问题就基本消失了。

现在的预防手段是双保险：分支隔离管代码，任务卡管上下文。就算 Claude 在某个会话里跑偏，改动只会留在它自己的分支上，不会污染其他任务，review 的时候抓出来也容易。如果你发现任务串台已经发生了，不要慌，先把改动范围查清楚，再用 git revert 或 checkout 还原到改动前状态，最后把任务卡边界再次强调给对应会话。

5.2 进度断档：新会话不记得旧任务

第二个高频问题是进度断档。你隔了一天回来，开个新会话想让 Claude 继续某个任务，结果它一脸茫然，因为你没有留下任何书面记录。这不算 Claude Code 的缺陷，而是工作方法问题。我的解法就是把进度摘要写进任务卡，并严格遵守前面说的“结束前落盘”原则。

如果你已经没落盘，也别慌，还有个补救办法：把之前的 git diff 或最近提交记录喂给新会话，让它通过代码状态反推上下文。虽然不如任务卡直接，但至少能接回大部分上下文。实测下来，任务卡加进度摘要这套组合能让我把断档时间压缩到一两分钟。这还是值得养成习惯的，因为在真实项目里，一个任务拖上三五天太常见了。

5.3 分支冲突：两个任务改了同一片区域

并行分支合并时出现冲突几乎不可避免。预防的核心是拆分时就把文件归属划清楚，前面 2.1 节说的文件边界标准就是为了这个。如果最后还是冲突了，我的建议是别让 Claude 在两个分支之间反复横跳试图自动解决所有冲突。你可以选一个分支作为主分支，手动梳理冲突区域，或者把冲突文件的最终合并方案交给某个单一会话去完成。

记住：冲突不可怕，可怕的是在冲突区域里再叠上 AI 的猜测。解决冲突时，我对 Claude 的要求是只处理冲突区域，不顺手重构旁边的代码。因为冲突本身已经说明这边代码有分歧，再让 AI 自由发挥，很容易引入新的问题。等冲突解决并测试通过后，再考虑是否要做后续优化。

5.4 上下文与开销失控

并行开发最容易低估的就是资源开销。几个长会话同时挂在那里，看起来只是几行文本交互，实际 token 消耗会很快。我见过一个并行三个大任务的会话组合，半天下来消耗量比单任务模式多出好几倍。如果不做控制，月底看到账单的时候确实肉疼。

我的应对策略分三层：第一层，控制并行数量，2 到 3 个封顶；第二层，及时压缩或重置会话，不保留不需要的长历史；第三层，任务完成立刻关会话。这个组合下来，费用基本能维持在一个可接受的范围。另外提醒一下，尽量利用好会话清理命令，别让已经把任务做完、只是没关终端的会话继续占着上下文空间。

5.5 终端断开与会话中断恢复

用 tmux 或远程环境做并行时，偶尔会遇到终端断开、会话中断的情况。好消息是大多数终端复用工具自带恢复机制，断线后重新连回去，原本的会话还在。如果确实会话丢了，我的恢复套路是：重新进入对应分支，打开 Claude Code，让它先读任务卡和上次的进度摘要。只要落盘做得够好，中断就只是一个短暂打断，不会让整个任务推倒重来。

这里再补一句：不要因为怕丢上下文就在一个会话里做所有事。上下文可以重建，但边界和任务范围被污染，代价往往更大。我现在已经习惯了把任务卡当成“外部记忆”，它比任何会话历史都可靠，因为它独立于 AI 的上下文窗口。

6. 我的并行开发节奏与个人体会

6.1 一套顺手的工作节奏

我现在比较稳定的并行节奏是这样：上午精神最好的时候做任务拆分和分支创建，把两到三个任务的卡写好；然后并行开会话推进开发，中间用检查节奏盯一下；下午集中做串行 review 和合并。

这套节奏说白了就是：把需要判断力的事情放在前面集中做，把需要执行力的并行放在中间，把容易出错、需要仔细看 diff 的事情放最后串行做。Claude Code 适合承接中间的并行执行部分，而不是替你做所有的判断。这也符合工具的使用边界：越是目标清晰、边界明确的任务，AI 并行执行的收益越大；越需要综合判断的事情，越要留给自己。

6.2 纪律比技巧更重要

用了这么久多任务并行，我最深的感触是：技术技巧其实不算复杂，真正的门槛是纪律。你愿不愿意每次开工前多花两分钟写任务卡；愿不愿意坚持一个会话只做一个任务；愿不愿意每次结束前落盘进度。这些事情单独拎出来都很简单，但一旦偷懒一次，后面就可能连续翻车。

AI 工具能放大你的好习惯，也能放大你的坏习惯。上下文混乱、边界失控这些问题，根子往往不在工具，而在你怎么组织工作。所以我的建议是，不要急着学更多花哨的骚操作，先把“一个会话一个任务、任务卡落盘、分支隔离”这三条基础纪律执行到位，再去追求更高的并行度。

6.3 一个小技巧：给会话加个可见标签

最后分享一个小技巧。当你同时开着三个会话时，容易搞混哪个窗口对应哪个任务。我通常在 tmux 分屏里给每个窗口起一个带有任务编号的名字，比如 003-log-archive、007-list-sort，这样切窗口的时候一眼就能分辨。这个动作看起来不起眼，但能避免很多低级错误，因为切错窗口、开始在错误分支上发指令的那一刻，真的非常耽误时间。保持每个会话的标识清晰，也算并行开发里一个小成本、高回报的投资。