cxb-plan

带灵感发散与评分审查的协作规划。

它做什么

cxb-plan 的目标不是生成“看起来像方案”的文字，而是生成真正可执行的实施计划。它让一个设计者保持责任归属，引入独立的灵感源扩大备选空间，并在方案被视为批准前执行评分审查。

默认角色映射：

• 设计师：Claude
• 灵感源：Gemini
• 评审员：Codex

工作流

阶段 1：需求澄清

在正式写方案前，设计师会先使用五维就绪度模型：

维度	权重	需要回答的问题
问题清晰度	30 分	我们到底在解决什么问题，为什么现在做？
功能范围	25 分	明确的范围是什么？
成功标准	20 分	如何验证任务已完成？
约束条件	15 分	受哪些边界、时间或兼容性约束？
优先级 / MVP	10 分	最小可接受交付是什么？

如果就绪度还没达标，Claude 会继续追问，除非你明确要求直接推进。

阶段 2：灵感发散

Claude 会向灵感源 Provider 请求替代方案、权衡点或值得参考的模式。

每条建议都要被分类为：

• Adopt
• Adapt
• Discard

这个分类动作很关键，因为 Gemini 的职责是扩大选项空间，而不是代替你批准方案。

阶段 3：方案撰写

成熟方案通常包含：

• 问题定义
• 方案方向及其理由
• 实施步骤
• 依赖与顺序
• 风险与缓解表
• 验收标准

阶段 4：评分审查

评审员会用 Rubric A 对方案进行评估。

维度	权重	标准
清晰度	20%	其他开发者能否不猜测就执行
完整性	25%	是否覆盖需求和边界情况
可行性	25%	是否符合真实仓库与工具限制
风险评估	15%	风险是否具体且有缓解路径
需求对齐	15%	是否能够回溯到原始请求

通过规则：

• 加权总分 >= 7.0
• 任一维度不得 <= 3

如果未通过，Claude 会修订后再次提交，直到达到设定的最大轮次。

阶段 5：输出

批准后的方案通常会写入：

plans/add-bulk-export-plan.md

一个好的方案输出通常会保留：

• 最终批准方案
• 评审评分
• 尚未消除的风险
• 灵感来源及被放弃的备选项

真实示例

输入：

Plan a safe migration from ad hoc webhook retries to a persisted retry queue.

理想输出应具备：

• 对比内存队列和持久化队列的设计
• 明确指出重放和去重风险
• 包含上线与回滚步骤
• 包含监控和测试要求
• 在开始实现前通过评分门禁

最佳实践

• 在规划阶段就要求清晰的验收标准。
• 涉及迁移、认证、计费、Schema 的任务，必须显式要求回滚设计。
• 把灵感源视为备选项来源，而不是批准方。
• 如果 Codex 认为方案不可行，先修方案，再写代码。

适合触发 cxb-plan 的请求

• “为把上传改成 signed URL 设计一个上线方案。”
• “先规划这个重构，并让 Codex 打分审查。”
• “给我一个经过评审、带清晰验收标准的 MVP 方案。”