跳到主要内容

工作流常见问题

CCW 工作流的常见问题和解答。

通用问题

Main Workflow 和 Issue Workflow 有什么区别?

Main Workflow 用于主要开发(Level 1-5),而 Issue Workflow 用于开发后期的维护工作。

方面Main WorkflowIssue Workflow
用途功能开发开发后修复
时机开发阶段主工作流完成后
并行处理依赖分析Worktree 隔离(可选)

如何选择合适的工作流级别?

什么是最小执行单元?

最小执行单元是指必须作为原子组一起执行的命令集合。拆分这些命令会破坏逻辑流程并产生不完整的状态。

示例:单元 lite-plan -> lite-execute 必须一起完成。在 lite-plan 之后停止会留下计划但没有实现。

Level 1 问题

何时使用 Level 1?

在以下情况下使用 Level 1 (lite-lite-lite):

  • 快速修复(拼写错误、小幅调整)
  • 简单功能(单个函数、小型工具)
  • 配置更改(环境变量、超时值)
  • 文档更新(readme、注释)

不要使用在:

  • 多模块更改
  • 需要持久化记录
  • 复杂重构
  • 测试驱动开发

Level 2 问题

lite-plan、lite-fix 和 multi-cli-plan 有什么区别?

工作流用途使用场景
lite-plan需求清晰单模块功能
lite-fixBug 诊断Bug 修复、生产问题
multi-cli-plan多视角分析技术选型、方案比较

什么是热修复模式?

/workflow:lite-fix --hotfix "Production database connection failing"

热修复模式

  • 跳过大部分诊断阶段
  • 最小化规划(直接执行)
  • 自动生成后续任务用于完整修复 + 复盘
  • 仅用于生产紧急情况

何时使用 multi-cli-plan vs lite-plan?

在以下情况下使用 multi-cli-plan

  • 需要多个视角(Gemini、Codex、Claude)
  • 技术选型决策
  • 方案比较
  • 架构权衡

在以下情况下使用 lite-plan

  • 需求清晰
  • 单视角足够
  • 需要更快迭代

Level 3 问题

plan、tdd-plan 和 test-fix-gen 有什么区别?

工作流用途关键特性
plan标准开发5 阶段规划与验证
tdd-plan测试驱动开发红-绿-重构循环
test-fix-gen测试修复渐进式测试层级(L0-L3)

什么是 TDD(测试驱动开发)?

TDD 遵循红-绿-重构循环:

  1. 红(Red):编写失败的测试
  2. 绿(Green):编写最小代码使测试通过
  3. 重构(Refactor):在保持测试通过的同时改进代码

铁律

没有失败的测试就不写生产代码

为什么 TDD 要求先写测试?

方面测试优先测试随后
证明测试在实现前失败测试立即通过(无证明)
发现编码前发现边界情况编码后发现边界情况
验证验证需求验证实现

test-fix-gen 中有哪些测试层级?

层级类型描述
L0静态类型检查、linting
L1单元函数级别测试
L2集成组件交互
L3E2E完整系统测试

Level 4 问题

何时使用 brainstorm:auto-parallel

在以下情况下使用 Level 4 (brainstorm:auto-parallel):

  • 新功能设计
  • 系统架构重构
  • 探索性需求
  • 不确定的实现方法
  • 需要多维度权衡

brainstorm 中有哪些可用角色?

角色描述
system-architect系统设计
ui-designerUI 设计
ux-expert用户体验
product-manager产品需求
product-owner业务价值
data-architect数据结构
scrum-master流程和团队
subject-matter-expert领域专业知识
test-strategist测试策略

什么是 With-File 工作流?

With-File 工作流提供多 CLI 协作的文档化探索:

工作流用途级别
brainstorm-with-file多视角构思4
debug-with-file假设驱动调试3
analyze-with-file协作分析3

Level 5 问题

何时使用 ccw-coordinator?

在以下情况下使用 Level 5 (ccw-coordinator):

  • 复杂的多步骤工作流
  • 不确定使用哪些命令
  • 需要端到端自动化
  • 需要完整的状态跟踪和可恢复性
  • 团队协作统一执行流程

ccw-coordinator 与其他级别有何不同?

方面Level 1-4Level 5
命令选择手动自动
编排手动智能
状态跟踪各异完整持久化

执行问题

什么是 lite-execute?

lite-execute 是 Level 2 工作流的统一执行命令:

/workflow:lite-execute --in-memory

特性

  • 独立任务并行执行
  • 依赖任务顺序执行
  • 通过 TodoWrite 跟踪进度
  • 可选代码审查

什么是 execute?

execute 是 Level 3 工作流的统一执行命令:

/workflow:execute --session WFS-{session-id}

特性

  • 依赖分析
  • 并行/顺序任务执行
  • 基于会话的进度跟踪
  • 任务完成摘要

会话问题

如何恢复暂停的会话?

/workflow:session:resume  # 恢复最近的会话
/workflow:session:resume WFS-{session-id} # 恢复特定会话

如何完成会话?

/workflow:session:complete --session WFS-{session-id}

这将使用经验教训归档会话并更新清单。

如何列出所有会话?

/workflow:session:list

产物问题

工作流产物存储在哪里?

级别产物位置
Level 1无(无状态)
Level 2memory://plan.workflow/.lite-fix/.workflow/.multi-cli-plan/
Level 3.workflow/active/WFS-{session}/
Level 4.workflow/active/WFS-{session}/.brainstorming/
Level 5.workflow/.ccw-coordinator/{session}/

会话中包含哪些文件?

.workflow/active/WFS-{session}/
├── workflow-session.json # 会话元数据
├── IMPL_PLAN.md # 实现计划
├── TODO_LIST.md # 进度跟踪
├── .task/
│ ├── IMPL-001.json # 任务定义
│ ├── IMPL-002.json
│ └── ...
└── .process/
├── context-package.json # 项目上下文
└── planning-notes.md

测试问题

如何为现有代码添加测试?

# 会话模式(从现有会话)
/workflow:test-fix-gen WFS-user-auth-v2

# 提示模式(直接描述)
/workflow:test-fix-gen "Add unit tests for the auth API"

如何修复失败的测试?

/workflow:test-fix-gen "Tests failing for user registration"
/workflow:test-cycle-execute

工作流将:

  1. 分析测试失败
  2. 识别根本原因
  3. 迭代修复问题
  4. 验证 >= 95% 通过率

故障排除

我的工作流失败了,该怎么办?

  1. 检查错误消息 - 识别根本原因
  2. 查看 state.json - 检查 .workflow/.ccw-coordinator/{session}/state.json
  3. 恢复会话 - 使用 /workflow:session:resume 继续
  4. 调整并重试 - 根据错误修改方法

如何跳过失败的任务?

编辑任务 JSON 将状态设置为 "completed":

jq '.status = "completed"' .workflow/active/WFS-{session}/.task/IMPL-001.json

如何清理旧会话?

# 列出会话
/workflow:session:list

# 删除特定会话
rm -rf .workflow/active/WFS-{session-id}

# 清理所有已完成的会话
/workflow:clean

最佳实践

工作流最佳实践有哪些?

  1. 从简单开始 - 使用满足需求的最低级别
  2. 执行前规划 - 尽可能使用验证步骤
  3. 持续测试 - 将测试集成到工作流中
  4. 代码审查 - 使用内置审查工作流
  5. 记录决策 - 对复杂决策使用头脑风暴工作流

何时使用 worktree 隔离?

Worktree 隔离主要用于 Issue Workflow

  • 主开发完成后
  • 已合并到 main 分支
  • 发现需要修复的问题
  • 需要在不影响当前开发的情况下修复

Main Workflow 不需要 worktree,因为:

  • 依赖分析解决了并行问题
  • 代理并行执行独立任务
  • 不需要文件系统隔离

相关文档