Claude-Workflow：六阶段结构化开发工作流与智能代理编排系统

Claude-Workflow 是一个专为 Claude Code 设计的六阶段开发工作流插件，通过 ECC 代理编排实现研究、构思、规划、执行、审查、收尾的完整闭环。支持多模型协作、阶段产物持久化、跨会话恢复，同时提供 Codex 兼容版本。

背景：AI辅助开发的工程化需求\n\n随着 Claude Code、Cursor 等 AI 编程助手的普及，开发者逐渐发现：单纯依赖对话式交互难以应对复杂项目的系统性开发。缺乏结构化流程的 AI 辅助往往导致上下文碎片化、决策不一致、产物难以追踪。\n\nClaude-Workflow 应运而生——它是一个原生集成于 Claude Code 的六阶段开发工作流系统，通过代理编排（Agent Orchestration）将 AI 辅助开发从"即兴对话"升级为"工程化流程"。\n\n## 核心架构：六阶段工作流模型\n\nClaude-Workflow 将整个开发过程划分为六个明确的阶段，每个阶段都有特定的目标、产物和负责代理：\n\n### 第一阶段：研究探索（Research/Discovery）\n\n本阶段聚焦于事实收集和现状理解。工作流调用两个专业代理：\n\n- code-explorer：使用 Sonnet 模型分析现有代码库，提取架构事实和依赖关系\n- docs-lookup：使用 Sonnet 模型检索外部文档，补充领域知识\n\n阶段产物包括代码结构图、依赖分析报告、技术约束清单，为后续决策提供事实基础。\n\n### 第二阶段：构思发散（Ideation）\n\n在充分理解现状后，进入创造性思考阶段。由 planner 代理（Opus 模型）主导，探索多种实现路径和设计方案。\n\n此阶段鼓励发散思维，产出多个候选方案及其权衡分析，为下一阶段的结构化规划提供素材。\n\n### 第三阶段：规划收敛（Plan）\n\ncode-architect 代理（Sonnet 模型）将构思阶段的候选方案转化为可执行的技术规划。输出包括：\n\n- 详细的技术方案文档\n- 任务分解与依赖关系图\n- 风险识别与缓解策略\n- 验收标准定义\n\n### 第四阶段：执行实施（Execute）\n\n执行阶段采用 TDD（测试驱动开发）方法论，由 tdd-guide 代理（Sonnet 模型）按 RED→GREEN→REFACTOR 循环推进。每个任务都有明确的测试证据和代码变更记录。\n\n当遇到构建错误时，build-error-resolver 代理自动介入修复，确保流程不中断。\n\n### 第五阶段：审查验证（Review）\n\n代码完成后进入质量把关环节：\n\n- code-reviewer（Sonnet）：常规代码审查，关注可读性、可维护性、最佳实践\n- security-reviewer（Sonnet，条件触发）：安全专项审查，识别潜在漏洞\n\n审查结果记录在合规台账中，未通过的项目返回执行阶段修复。\n\n### 第六阶段：收尾归档（Finalize）\n\ndoc-updater 代理（Haiku 模型，轻量快速）负责更新项目文档、同步路线图、归档阶段产物，并完成最终的 Git 提交。\n\n## 技术实现：ECC 代理编排\n\nClaude-Workflow 建立在 ECC（Everything Claude Code）框架之上，利用其代理管理能力实现多模型协作。每个代理都有明确的角色定义、模型配置和职责边界。\n\n### 代理-模型映射表\n\n| 代理 | 阶段 | 模型 | 职责 |\n|------|------|------|------|\n| code-explorer | 1 | Sonnet | 代码事实提取 |\n| docs-lookup | 1 | Sonnet | 外部文档检索 |\n| planner | 2 | Opus | 方案构思 |\n| code-architect | 3 | Sonnet | 技术规划 |\n| tdd-guide | 4 | Sonnet | TDD 执行 |\n| build-error-resolver | 4-6 | Sonnet | 错误修复 |\n| code-reviewer | 5 | Sonnet | 代码审查 |\n| security-reviewer | 5 | Sonnet | 安全审查 |\n| doc-updater | 6 | Haiku | 文档更新 |\n\n### 阶段产物与持久化\n\n每个阶段都产生结构化的文件产物，存储于项目目录的 claude-workflow/ 文件夹中：\n\n- 阶段报告（Markdown）\n- 决策记录（JSON）\n- 代码变更（Git diff）\n- 审查台账（YAML）\n\n这种设计确保了工作流的可恢复性——即使 Claude Code 会话重置，也能从任意阶段恢复继续。\n\n## 使用方式\n\n### 插件安装\n\nbash\n# 添加市场源\n/plugin marketplace add https://github.com/KaolaBrother/Claude-Workflow\n\n# 安装工作流插件\n/plugin install claude-workflow@kaolabrother-claude-workflow\n\n# 重载插件\n/reload-plugins\n\n\n### 工作流启动\n\nbash\n# 初始化新项目\n/workflow-init\n\n# 推进到下一阶段\n/workflow-next\n\n\n### 手动安装\n\nbash\ngit clone https://github.com/KaolaBrother/Claude-Workflow.git\ncd Claude-Workflow\n./install.sh\n\n\n## Codex 兼容版本\n\n项目同时提供 Codex 原生版本，采用相同的六阶段架构但适配 Codex 的代理系统：\n\nbash\n# 添加市场源\ncodex plugin marketplace add KaolaBrother/Claude-Workflow\n\n# 启用插件\n[plugins."codex-workflow@kaolabrother-private"]\nenabled = true\n\n\nCodex 版本使用 .codex/agents/codex-workflow/ 管理角色配置，支持以下技能：\n\n- codex-workflow-init\n- codex-workflow-next\n- codex-workflow-research\n- codex-workflow-ideation\n- codex-workflow-plan\n- codex-workflow-execute\n- codex-workflow-review\n- codex-workflow-finalize\n\n## 设计哲学与价值\n\n### 结构化优于即兴\n\n工作流强制要求每个开发阶段都有明确入口和出口，避免"边想边做"导致的混乱。阶段间的产物传递确保了上下文连续性。\n\n### 专业化优于通用\n\n不同任务匹配不同能力模型：Opus 负责创造性构思，Sonnet 处理技术实现，Haiku 快速完成文档。这种分工比单一模型处理所有任务更高效。\n\n### 可恢复性优于一次性\n\n所有中间产物持久化到文件系统，支持跨会话恢复。这对于长周期项目尤为重要——开发者可以今天完成规划，明天继续执行，无需重新建立上下文。\n\n### 可审计性优于黑盒\n\n每个阶段的决策、审查、修改都有记录，形成完整的项目历史。这对于团队协作和合规要求至关重要。\n\n## 适用场景\n\n### 复杂功能开发\n\n当需要实现涉及多模块协调、架构变更、接口设计的复杂功能时，工作流的结构化流程能确保不遗漏关键环节。\n\n### 遗留代码重构\n\n研究阶段的事实提取和规划阶段的风险分析，特别适合需要充分理解现有系统后再动手重构的场景。\n\n### 安全敏感项目\n\n内置的安全审查代理和合规台账，为安全关键型开发提供了额外的质量保障。\n\n### 团队协作项目\n\n阶段产物的文件化使得工作流状态可以在团队成员间传递，支持异步协作和代码审查。\n\n## 总结与展望\n\nClaude-Workflow 代表了 AI 辅助开发向工程化、流程化演进的方向。它借鉴了传统软件工程的最佳实践（如 TDD、阶段门控），同时充分利用了多模型 AI 的能力差异。\n\n对于追求开发效率和代码质量的团队，这种结构化工作流提供了一个可复用的框架。随着 ECC 和 Codex 代理能力的增强，未来工作流有望支持更复杂的并行执行、动态代理调度等高级特性。

背景：AI辅助开发的工程化需求\n\n随着 Claude Code、Cursor 等 AI 编程助手的普及，开发者逐渐发现：单纯依赖对话式交互难以应对复杂项目的系统性开发。缺乏结构化流程的 AI 辅助往往导致上下文碎片化、决策不一致、产物难以追踪。\n\nClaude-Workflow 应运而生——它是一个原生集成于 Claude Code 的六阶段开发工作流系统，通过代理编排（Agent Orchestration）将 AI 辅助开发从"即兴对话"升级为"工程化流程"。\n\n核心架构：六阶段工作流模型\n\nClaude-Workflow 将整个开发过程划分为六个明确的阶段，每个阶段都有特定的目标、产物和负责代理：\n\n第一阶段：研究探索（Research/Discovery）\n\n本阶段聚焦于事实收集和现状理解。工作流调用两个专业代理：\n\n- code-explorer：使用 Sonnet 模型分析现有代码库，提取架构事实和依赖关系\n- docs-lookup：使用 Sonnet 模型检索外部文档，补充领域知识\n\n阶段产物包括代码结构图、依赖分析报告、技术约束清单，为后续决策提供事实基础。\n\n第二阶段：构思发散（Ideation）\n\n在充分理解现状后，进入创造性思考阶段。由 planner 代理（Opus 模型）主导，探索多种实现路径和设计方案。\n\n此阶段鼓励发散思维，产出多个候选方案及其权衡分析，为下一阶段的结构化规划提供素材。\n\n第三阶段：规划收敛（Plan）\n\ncode-architect 代理（Sonnet 模型）将构思阶段的候选方案转化为可执行的技术规划。输出包括：\n\n- 详细的技术方案文档\n- 任务分解与依赖关系图\n- 风险识别与缓解策略\n- 验收标准定义\n\n第四阶段：执行实施（Execute）\n\n执行阶段采用 TDD（测试驱动开发）方法论，由 tdd-guide 代理（Sonnet 模型）按 RED→GREEN→REFACTOR 循环推进。每个任务都有明确的测试证据和代码变更记录。\n\n当遇到构建错误时，build-error-resolver 代理自动介入修复，确保流程不中断。\n\n第五阶段：审查验证（Review）\n\n代码完成后进入质量把关环节：\n\n- code-reviewer（Sonnet）：常规代码审查，关注可读性、可维护性、最佳实践\n- security-reviewer（Sonnet，条件触发）：安全专项审查，识别潜在漏洞\n\n审查结果记录在合规台账中，未通过的项目返回执行阶段修复。\n\n第六阶段：收尾归档（Finalize）\n\ndoc-updater 代理（Haiku 模型，轻量快速）负责更新项目文档、同步路线图、归档阶段产物，并完成最终的 Git 提交。\n\n技术实现：ECC 代理编排\n\nClaude-Workflow 建立在 ECC（Everything Claude Code）框架之上，利用其代理管理能力实现多模型协作。每个代理都有明确的角色定义、模型配置和职责边界。\n\n代理-模型映射表\n\n| 代理 | 阶段 | 模型 | 职责 |\n|------|------|------|------|\n| code-explorer | 1 | Sonnet | 代码事实提取 |\n| docs-lookup | 1 | Sonnet | 外部文档检索 |\n| planner | 2 | Opus | 方案构思 |\n| code-architect | 3 | Sonnet | 技术规划 |\n| tdd-guide | 4 | Sonnet | TDD 执行 |\n| build-error-resolver | 4-6 | Sonnet | 错误修复 |\n| code-reviewer | 5 | Sonnet | 代码审查 |\n| security-reviewer | 5 | Sonnet | 安全审查 |\n| doc-updater | 6 | Haiku | 文档更新 |\n\n阶段产物与持久化\n\n每个阶段都产生结构化的文件产物，存储于项目目录的 claude-workflow/ 文件夹中：\n\n- 阶段报告（Markdown）\n- 决策记录（JSON）\n- 代码变更（Git diff）\n- 审查台账（YAML）\n\n这种设计确保了工作流的可恢复性——即使 Claude Code 会话重置，也能从任意阶段恢复继续。\n\n使用方式\n\n插件安装\n\nbash\n添加市场源\n/plugin marketplace add https://github.com/KaolaBrother/Claude-Workflow\n\n安装工作流插件\n/plugin install claude-workflow@kaolabrother-claude-workflow\n\n重载插件\n/reload-plugins\n\n\n工作流启动\n\nbash\n初始化新项目\n/workflow-init\n\n推进到下一阶段\n/workflow-next\n\n\n手动安装\n\nbash\ngit clone https://github.com/KaolaBrother/Claude-Workflow.git\ncd Claude-Workflow\n./install.sh\n\n\nCodex 兼容版本\n\n项目同时提供 Codex 原生版本，采用相同的六阶段架构但适配 Codex 的代理系统：\n\nbash\n添加市场源\ncodex plugin marketplace add KaolaBrother/Claude-Workflow\n\n启用插件\n[plugins."codex-workflow@kaolabrother-private"]\nenabled = true\n\n\nCodex 版本使用 .codex/agents/codex-workflow/ 管理角色配置，支持以下技能：\n\n- codex-workflow-init\n- codex-workflow-next\n- codex-workflow-research\n- codex-workflow-ideation\n- codex-workflow-plan\n- codex-workflow-execute\n- codex-workflow-review\n- codex-workflow-finalize\n\n设计哲学与价值\n\n结构化优于即兴\n\n工作流强制要求每个开发阶段都有明确入口和出口，避免"边想边做"导致的混乱。阶段间的产物传递确保了上下文连续性。\n\n专业化优于通用\n\n不同任务匹配不同能力模型：Opus 负责创造性构思，Sonnet 处理技术实现，Haiku 快速完成文档。这种分工比单一模型处理所有任务更高效。\n\n可恢复性优于一次性\n\n所有中间产物持久化到文件系统，支持跨会话恢复。这对于长周期项目尤为重要——开发者可以今天完成规划，明天继续执行，无需重新建立上下文。\n\n可审计性优于黑盒\n\n每个阶段的决策、审查、修改都有记录，形成完整的项目历史。这对于团队协作和合规要求至关重要。\n\n适用场景\n\n复杂功能开发\n\n当需要实现涉及多模块协调、架构变更、接口设计的复杂功能时，工作流的结构化流程能确保不遗漏关键环节。\n\n遗留代码重构\n\n研究阶段的事实提取和规划阶段的风险分析，特别适合需要充分理解现有系统后再动手重构的场景。\n\n安全敏感项目\n\n内置的安全审查代理和合规台账，为安全关键型开发提供了额外的质量保障。\n\n团队协作项目\n\n阶段产物的文件化使得工作流状态可以在团队成员间传递，支持异步协作和代码审查。\n\n总结与展望\n\nClaude-Workflow 代表了 AI 辅助开发向工程化、流程化演进的方向。它借鉴了传统软件工程的最佳实践（如 TDD、阶段门控），同时充分利用了多模型 AI 的能力差异。\n\n对于追求开发效率和代码质量的团队，这种结构化工作流提供了一个可复用的框架。随着 ECC 和 Codex 代理能力的增强，未来工作流有望支持更复杂的并行执行、动态代理调度等高级特性。