【深度】Claude Code /plan 模式的致命局限，和我如何用 Qoder 多专家架构解决它

用 Claude Code 三个月后，我发现 /plan 模式已经足够强，但单独用它做复杂项目交付还差几件事。结合阿里 Qoder 的多专家设计思想，我设计了一套高阶方法论，让 AI 编程真正从"对话助手"变成"可靠流水线"。

关键词：Claude Code、Qoder、多 Agent 架构、AI 编程工程化、Quest Mode、Agentic Engineering

适合读者：已经用 Claude Code 写过代码，想用它做完整项目交付的工程师

---

前言：/plan 模式已经足够强，但还不够

Claude Code 的 /plan 模式是我用过的最被低估的功能。

它把 Claude 从一个"听到需求就立刻改代码的急躁初级程序员"，瞬间变成一个"只读权限、先思考后行动"的资深架构师。Anthropic 官方推荐的 Explore → Plan → Implement 工作流，足以应付大多数中小型任务。

但当我用它做了三个月复杂项目交付之后，我发现了一个问题：

/plan 模式强在规划，但弱在执行，更弱在长链路可靠交付。

具体来说：

• 规划阶段它很强，但编码阶段它容易"偏离航线"
• 测试阶段它自己写、自己测、自己判断通过，GAN 架构早就证明了这样做的问题
• 碰到复杂项目，它的上下文会衰减，每个阶段都要重新对齐背景
• 一旦失败，没有状态管理，通常只能从头重来或者放弃

这就是我设计 Quest Mode 的起点。

Quest Mode 不是 Claude Code 或 Qoder 的内置功能，而是我结合 Qoder 的多专家架构设计思想，对 Claude Code /plan 模式的高阶增强方法论。它的目标很明确：让 AI 编程从"聊天"变成"可靠流水线"。

---

一、Claude Code /plan 模式为什么值得用

在说不足之前，先把 /plan 模式的价值说清楚。很多人还没意识到它有多强。

1.1 /plan 模式的工作原理

当你切换到 /plan 模式时，Claude Code 做了三件事：

权限降级：从可读写变成只读。不能修改代码，不能运行危险命令，不能提交 Git。

角色切换：从执行者变成架构师。它会阅读代码、理清逻辑、向你提问确认细节，最后输出一份结构化的实施计划。

风险识别：它会主动告诉你"修改这个模块可能影响 X 功能"，而不是埋头改完再说。

1.2 标准的 Explore → Plan → Implement 工作流

第一步：Explore（探索）
  输入：我想做一个小红书评论分析工具
  Claude 做的事：扫描项目结构，理解技术栈，找到相关文件
  输出：上下文理解 + 澄清问题

第二步：Plan（规划）
  输入：确认需求后
  Claude 做的事：制定详细实施计划，拆解里程碑
  输出：需求文档 + 技术方案 + 任务清单

第三步：Implement（实施）
  输入：确认计划
  Claude 做的事：切换到正常模式，逐个里程碑实现
  输出：代码变更 + 测试结果

这个工作流本身没有问题。Anthropic 的设计很精妙，/plan 模式的只读约束、风险识别、结构化输出，都是工程化的最佳实践。

1.3 /plan 模式真正的价值

很多人把 /plan 模式当成"更谨慎的代码生成"，这是误解。它的真正价值在于：

把决策和执行分离。/plan 阶段专注决策（做什么、怎么做、有什么风险），Implement 阶段专注执行（写代码、跑测试）。决策阶段不应该有执行权限，执行阶段不应该偏离决策。

用 CLAUDE.md 建立长期记忆。把项目规范、编码风格、架构约束写到 CLAUDE.md，Claude 每次新会话都能继承上下文，减少重复说明。

用清晰的验收标准减少反馈回路。给 Claude 测试用例或预期输出，它就能自我检查。模糊的成功标准会让你成为唯一的反馈回路，每个错误都要你介入。

---

二、/plan 模式在复杂项目中的五个局限

说完了价值，说问题。用它做了三个月项目交付后，我总结了五个真实的局限。

局限一：单 Agent 执行，阶段切换时上下文丢失

这是最根本的问题。

/plan 模式是一个 Agent 负责整个流程：规划 → 编码 → 测试。听起来是一个连贯的过程，但实践中有一个致命的问题：

第一阶段做的需求理解，到第四阶段已经记不全了。

每次新阶段开始，Claude 都要重新加载上下文。随着项目变大，加载的上下文越来越多，Claude 开始"遗忘"早期做出的决策。它会在编码阶段偏离最初的需求理解，写一些最初计划里根本没有的功能。

根本原因：没有 L1 信息边界层的设计。每个阶段该知道什么、不该知道什么，没有明确的边界定义。

局限二：编码和测试是同一个 Agent，自己测自己

这是 GAN 架构早就证明过的问题。

Claude 写完代码，自己运行测试，自己判断通过没有。问题很明显：Agent 很难真正否定自己的产出。它会下意识地放过一些问题，或者在修复时引入新的问题。

Anthropic 的官方指南里其实也意识到了这一点，提到"给 Claude 提供测试用例，让它自我检查"。但自己写测试、自己跑测试、自己判断结果，本质上还是同一套判断逻辑在起作用。

局限三：工具权限没有按阶段区分

在 /plan 模式的默认设定里，规划阶段和编码阶段能调用的工具是一样的。这导致：

• 规划阶段 Claude 可能已经开始写代码（它看到文件就想改）
• 测试阶段 Claude 还在改需求（没有门控约束）
• 没有阶段锁定机制，流水线随时可能崩溃

局限四：失败后没有恢复机制

这是最影响生产效率的问题。

测试挂了，Claude 在一堆未提交的变更里来回修改，越改越乱。它的错误修复往往是"试试这个，不行再试试那个"的试错模式，不系统，容易在错误的方向上越走越远。

最后的解决办法往往是"算了重来"。但重来之后，大概率还是会遇到类似的问题，因为没有状态管理，不知道上次失败的具体原因。

局限五：报告质量完全依赖最后一次对话

/plan 模式输出的是结构化计划，但执行完成后的交付报告就不太有结构了。内容取决于 Claude 最后说了什么，格式随机，容易漏项。没有变更清单，没有验收记录，交付物不完整。

---

三、Qoder 的多专家架构带来了什么

2025年8月，阿里发布了 Qoder，一个 Agentic 编程平台。2026年3月，Qoder 上线了 Experts Mode（专家团模式），引起了我的注意。

Experts Mode 的核心思想：输入一句自然语言需求，AI 自动组建多个专项软件工程智能体，并行完成调研、计划、编码、测试、代码审查等任务，交付完整工程结果。

每个专家是经过专项调优的软件工程智能体，各自运行在最适合自身任务的模型上。Qoder 官方称这样做成本可以降至单一顶级模型的 1/2 到 1/5。

为什么这个设计思想重要：

传统的对话式编程是一个 Agent 打天下。Qoder 的 Experts Mode 证明了：不同类型的任务，确实应该由不同专长的 Agent 来处理。

Plan Expert 专注理解需求和拆解任务，它不需要写代码的能力。
Code Expert 专注写代码，它不需要知道需求的原始背景。
Test Expert 专注验证，它不应该和 Code Expert 是同一个人。
Review Expert 专注质量把关，它只有读权限，不能直接改代码。

多专家架构的核心优势：

• 职责边界清晰，每个专家知道自己该做什么、不该做什么
• 专家之间通过结构化文档交接，不依赖 Agent 的记忆
• 独立验证，真正做到"生成和验证分离"
• 每个专家可以运行在最适合自己任务的模型上

这就是我在 Quest Mode 设计中借鉴的核心思想。

---

四、Quest Mode：结合 /plan 和多专家架构的高阶方法论

Quest Mode 是我对 Claude Code /plan 模式的高阶增强方法论，结合了 Qoder 的多专家架构设计思想。它的目标是在 /plan 模式的"先规划后执行"基础上，增加多专家流水线、状态管理、失败恢复，让复杂项目交付真正可靠。

4.1 整体架构

┌─────────────────────────────────────────────────────┐
│                    L6: 约束与恢复层                  │
│  阶段门控 │ 失败策略 │ 超时控制 │ 自动回滚             │
├─────────────────────────────────────────────────────┤
│                    L5: 评估与观测层                  │
│  Code Review │ 自动化测试 │ 报告生成 │ 质量评分         │
├─────────────────────────────────────────────────────┤
│                    L4: 记忆与状态层                  │
│  Quest State.json │ 变更清单 │ 阶段产物 │ 版本快照      │
├─────────────────────────────────────────────────────┤
│                    L3: 执行编排层                    │
│  状态机 │ 阶段门控 │ 并行任务 │ 进度追踪              │
├─────────────────────────────────────────────────────┤
│                    L2: 工具系统层                    │
│  Plan │ Code │ Test │ Review 工具集分层授权           │
├─────────────────────────────────────────────────────┤
│                    L1: 信息边界层                   │
│  需求文档 │ 上下文摘要 │ 各阶段知识卡片                │
└─────────────────────────────────────────────────────┘

4.2 四专家流水线

基于 Qoder 的 Experts Mode 思想，我把原来单 Agent 的流程替换成四个专家：

Master Agent（主持全局，协调四专家分工）
     │
     ├── Plan Expert   → 专注文档：理解需求，拆解任务（借鉴 /plan 模式）
     ├── Code Expert   → 专注代码：实现功能，遵守规范
     ├── Test Expert   → 专注验证：运行测试，检查覆盖率
     └── Review Expert → 专注质量：代码审查，安全审计（无写权限）

和 /plan 模式的关系：Quest Mode 的 Plan Expert 不是另起炉灶，而是把 /plan 模式的最佳实践（只读约束、风险识别、结构化输出）固化为基础能力。

职责分工：

专家	核心职责	借鉴来源
Plan Expert	需求理解、任务拆解、技术方案	Claude Code /plan 模式
Code Expert	代码实现、代码规范、小步提交	—
Test Expert	测试用例、自动化验证、覆盖率检查	—
Review Expert	代码审查、安全审计、质量报告	Qoder Experts Mode

4.3 和 /plan 模式的本质区别

Quest Mode 不是"更好的 /plan 模式"，而是不同的分工：

维度	/plan 模式	Quest Mode
目标	单次任务规划	完整项目交付流水线
Agent	单 Agent 全流程	四专家流水线
验证	Agent 自己测自己	独立 Test + Review Expert
上下文	依赖对话记忆	结构化文档交接
失败恢复	手动重试	自动快照 + 回滚
适用场景	中小型任务	复杂多模块项目

---

五、核心组件详细设计

5.1 状态机与阶段门控

class QuestState:
    INIT = "init"           # 初始状态
    PLANNING = "planning"   # 规划中（Plan Expert 运行）
    PLAN_APPROVED = "plan_approved"  # 方案已确认（用户批准）
    CODING = "coding"       # 编码中（Code Expert 运行）
    CODE_APPROVED = "code_approved"  # 代码已审核
    TESTING = "testing"     # 测试中（Test Expert 运行）
    COMPLETED = "completed"  # 全部完成
    FAILED = "failed"       # 失败
    RECOVERING = "recovering"  # 恢复中

阶段门控规则：

当前状态	触发条件	启动专家	退出条件	审批人
init	用户提交需求	Plan Expert	需求文档输出	用户确认
planning	方案已确认	Code Expert	所有代码变更提交	Review Expert
coding	Review 通过	Test Expert	测试覆盖率 >= 80%	Test Expert
testing	测试通过	Review Expert	质量分数 >= 85	Review Expert

5.2 失败策略

FAILURE_STRATEGIES = {
    "planning": {
        "max_retries": 3,
        "on_max_retry": "请求用户澄清需求",
        "snapshot": "保存方案草稿到 .quest/plan/draft.md",
        "recovery": "从草稿恢复，不从头开始",
    },
    "coding": {
        "max_retries": 5,
        "on_max_retry": "git 回滚到上一稳定 commit",
        "snapshot": "每完成一个文件立即 git add + commit",
        "recovery": "git checkout 到上一 commit",
    },
    "testing": {
        "max_retries": 3,
        "on_max_retry": "Code Expert 修复后重测",
        "snapshot": "保存测试结果快照",
        "recovery": "只重跑失败的测试用例",
    },
}

5.3 记忆管理：.quest/ 目录结构

.quest/
├── state.json              # 当前状态（状态机状态）
├── context.md              # 全局上下文摘要
├── plan/
│   ├── requirements.md     # 原始需求
│   ├── spec.md             # 技术方案（/plan 模式的结构化输出）
│   └── tasks.md            # 任务清单
├── code/
│   ├── changes.md          # 代码变更清单
│   └── files.md            # 已修改文件列表
├── test/
│   ├── results.md          # 测试结果
│   └── coverage.md         # 覆盖率报告
├── review/
│   ├── report.md           # 质量审查报告
│   └── risks.md            # 风险清单
└── reports/
    └── delivery.md         # 最终交付报告

上下文摘要模板（每个阶段开始时自动生成）：

# Quest 上下文摘要

## 项目背景
一句话描述项目在做什么

## 当前阶段
[✓] Plan [ ] Code [ ] Test [ ] Review [ ] Report

## 已完成
- 需求文档已完成
- 技术方案已确认

## 当前瓶颈
认证模块 Token 过期未处理

## 接下来
1. 修复 Token 刷新逻辑
2. 重跑认证测试
3. 生成交付报告

5.4 工具集按专家分层授权

这是关键设计：不是每个专家都需要 bash 权限。

专家	允许的工具
Plan Expert	read, glob, grep, web_search, write（借鉴 /plan 模式）
Code Expert	read, write, exec, git, linter, formatter
Test Expert	exec, read, glob, write（测试文件）
Review Expert	read, glob, exec（安全扫描）, linter（仅读）

Review Expert 没有 exec 的写权限，不能修改代码。它只能运行只读的安全扫描，修复必须通过 Master Agent 协调 Code Expert 完成。

---

六、完整流程

用户提交需求
     │
     ▼
  Plan Expert（借鉴 /plan 模式）
  → 理解需求 → 澄清细节 → 制定方案
  → 输出：requirements.md + spec.md + tasks.md
     │ 用户确认方案
     ▼
  Code Expert
  → 按 spec.md 实现 → 每文件完成立即 git commit
  → 输出：changes.md + 文件变更
     │ Review Expert 通过
     ▼
  Test Expert
  → 写测试 → 运行测试 → 检查覆盖率
  → 输出：test-results.md + coverage.md
     │ 测试通过
     ▼
  Review Expert
  → 代码审查 → 安全审计 → 质量评分
  → 输出：quality-report.md（无写权限）
     │ 质量达标
     ▼
  报告生成器
  → 汇总所有阶段产物 → 生成 delivery.md
     │ 用户确认
     ▼
     交付完成

---

七、四周落地计划

第一周：搭架子
创建 .quest/ 目录结构，编写四个专家的提示词模板，实现基础状态机，配置阶段门控规则。

第二周：引入独立验证
Test Expert 和 Code Expert 完全分离，Review Expert 代码审查功能，测试覆盖率自动检查。

第三周：增强恢复能力
每个阶段快照机制，失败后自动回滚脚本，上下文压缩生成器。

第四周：与 Claude Code /plan 模式集成
用 Claude Code 的 /plan 命令作为 Plan Expert 入口，CLAUDE.md 作为上下文管理基础，封装成可复用项目模板。

---

八、总结

维度	/plan 模式（单独使用）	Quest Mode（多专家流水线）
Agent 架构	单 Agent 全流程	四专家流水线
验证机制	Agent 自己测自己	独立 Test + Review Expert
上下文管理	依赖对话记忆	结构化文档交接
失败恢复	手动重试或放弃	自动快照 + 回滚
工具权限	没有阶段区分	按专家精确授权
报告质量	依赖最后对话	结构化模板生成
适用场景	中小型任务	复杂多模块项目

核心洞察只有一句话：AI 编程的瓶颈从来不是模型有多强，而是工程基础设施能不能兜住长链路可靠交付的任务。

Claude Code 的 /plan 模式是迄今为止最被低估的 AI 编程功能之一。但单 Agent 的局限是真实存在的。Qoder 的 Experts Mode 证明了多专家架构的可行性。我所做的，不过是把这两个洞察合在一起，用工程化的方式落地。

---

相关阅读：

• Harness Engineering 完全指南：AI Agent 时代的核心工程方法论