CCG vs Superpowers

提问1

我的项目最近在搭建AI工作流，我推荐用CCG Workflow，其他人推荐用superpowers。目前还是各自用自己喜欢的，但是我的领导说，后面要统一用相同的工作流。我有两个疑问，一是二者有什么优劣，二是有必要统一吗，各自用各自的有什么问题和好处

回答1

我会把它们理解成两类东西：

  • CCG Workflow：偏“多模型编排工具”。Claude 负责协调和审核，Codex 偏后端，Gemini 偏前端，配 /ccg:* 命令、OPSX 约束、patch 审核、多模型 review。官方文档也强调“前端/后端自动分流”“外部模型只返回 patch，由 Claude review 后应用”。来源：CCG 官网、GitHub README
  • Superpowers：偏“工程方法论/技能框架”。它不太关心哪个模型写前端后端，而是强制 agent 走 brainstorm、spec、plan、worktree、TDD、review、finish branch 这些流程。来源：Superpowers GitHub README

一句话判断：
CCG 更像“让多个 AI 分工协作的工具链”；Superpowers 更像“让 AI 按团队工程纪律干活的流程层”。它们不是完全同一维度竞争，甚至可以组合，但团队统一时通常要先统一“流程标准”，再决定“工具标准”。

优劣对比

维度 CCG Workflow Superpowers
核心优势 多模型分工，适合全栈任务；Codex/Gemini/Claude 交叉审查；命令直接，自动路由 流程纪律强；强调澄清需求、计划、TDD、review；更适合团队沉淀一致做法
适合场景 前后端边界清晰、希望并行分析/多模型 review、Claude Code 是主入口 中大型改动、质量敏感代码、需要新人也按同一套 AI 开发习惯工作
主要风险 工具链更复杂：Claude Code、Codex CLI、Gemini CLI、Node、jq、模型账号、权限 hook；跨模型上下文传递可能失真 流程可能偏重，简单任务会慢；TDD/计划门槛可能让部分人觉得束手束脚
团队治理 要管多模型权限、成本、日志、数据出境、patch 应用规则 要管流程是否过度、哪些任务必须走完整流程、哪些可以轻量化
可复制性 如果大家环境配置不同，结果差异可能比较明显 更容易统一“怎么做事”，但不同 agent/harness 仍可能有细微差异

有没有必要统一？

有必要统一，但不一定要统一到“所有人必须用同一个工具”。

真正需要统一的是这些东西：

  1. 交付物格式：需求说明、实现计划、测试证据、review 结论、PR 描述应该长什么样。
  2. 风险分级：什么任务必须先写 spec，什么任务必须 TDD，什么任务必须双模型/人工 review。
  3. 代码权限边界：AI 能不能直接改文件、能不能自动运行命令、能不能自动提交、能不能访问生产数据。
  4. 验收标准：改完必须跑哪些测试，失败怎么记录，没跑测试要不要说明原因。
  5. 知识沉淀：prompt、计划、踩坑、最佳实践要放到团队共享位置，而不是散落在个人聊天记录里。

如果完全各用各的，好处是：个人效率高，大家可以探索最佳实践，适合早期试验期。
问题是：PR 质量不稳定、review 成本上升、事故难复盘、新人难学、leader 很难判断“AI 到底怎么参与了这次改动”。

我的建议

不要一上来二选一。可以跟领导提一个折中方案：

  • 统一“团队 AI 开发规范”，不先强制统一工具。
  • 选 2 周试点：同类任务分别用 CCG 和 Superpowers 跑。
  • 对比指标：完成时间、返工次数、review 问题数、测试覆盖、上下文丢失次数、配置成本、团队主观体验。
  • 最后决定：
    • 如果团队最缺的是“工程纪律和可复盘”，优先 Superpowers。
    • 如果团队最想要“多模型分工和效率”，优先 CCG。
    • 如果条件允许，可以用 Superpowers 做底层流程规范，CCG 用在适合多模型协作的复杂全栈任务上。

我个人会主张：统一标准，保留工具弹性；高风险任务强制流程，低风险任务允许轻量化。 这样领导要的可控性有了，开发者也不会被一套工具绑死。

提问2

CCG也有spec相关的东西，还有必要用superpowers吗

回答2

不一定有必要。关键不是“谁有 spec”，而是 spec 之后有没有把工程流程管住。

CCG 的 spec/OPSX 更偏向：把需求变成约束，让多模型执行时别自由发挥。它的强项还是多模型分工、patch review、前后端路由。
Superpowers 的 spec 是整套方法论的一环：brainstorm → spec → plan → worktree → TDD → review → finish branch。它强调的是“AI 开发过程标准化”。参考：CCG、Superpowers README。

我的判断：

情况 是否需要 Superpowers
CCG 已经能稳定产出清晰 spec、实现计划、测试说明、review 记录 不一定需要
团队主要问题是“不同人 AI 工作流不可复盘、测试不一致、PR 质量波动大” 值得引入或借鉴
团队主要目标是“多模型协作提升效率” CCG 更贴题
团队成员用 Claude Code、Codex、Cursor、Gemini 等不同入口 Superpowers 更适合作为统一流程层
简单需求很多，不想每次都走重流程 不要全量强制 Superpowers

我会建议你不要把问题变成“CCG vs Superpowers”，而是拆成两层：

  1. 团队流程层统一：什么任务要写 spec，spec 模板是什么，什么时候必须写测试，什么时候必须 review，PR 怎么说明 AI 参与过程。
  2. 执行工具层允许弹性：有人用 CCG，有人用其他 agent，只要交付物满足统一标准即可。

如果你已经推荐 CCG，可以这样跟领导说：

CCG 也有 spec 和约束机制，所以不一定需要再完整引入 Superpowers。我们可以先统一团队 AI 工作流标准，比如 spec 模板、测试要求、review 规则和交付格式。CCG 可以作为执行工具之一。如果后面发现流程纪律不足，比如 TDD、worktree 隔离、review 节点不稳定，再把 Superpowers 的相关技能吸收进团队规范。

我个人倾向：不要同时全量套两套流程，容易重复提问、重复写 spec、增加摩擦。更好的做法是：以 CCG 为执行方案，然后挑 Superpowers 里有价值的部分，比如 TDD、计划文档、review checklist，变成团队规范。

提问3

关于团队流程层统一你可以展开介绍一下，比如么任务要写 spec，spec 模板是什么，什么时候必须写测试，什么时候必须 review，PR 怎么说明 AI 参与过程

回答3

可以。团队流程层统一，本质不是规定“大家必须用同一个 AI 工具”，而是规定 什么风险等级的任务，必须留下什么证据。工具可以不同，但产出要可 review、可复盘、可交接。

我建议按这 5 块统一。

1. 哪些任务要写 Spec

不要所有任务都写完整 spec，否则大家会很快烦。可以按风险分级：

等级 任务类型 要求
L0 极小改动 文案、样式微调、日志调整、无行为变化的小修 不需要 spec，PR 说明清楚即可
L1 小功能/小 bug 单模块改动、影响范围明确、可快速回滚 写 mini spec，放 issue 或 PR 描述里
L2 中等改动 涉及多个模块、接口变更、状态流变化、权限/数据逻辑变化 必须写完整 spec，开发前 review
L3 高风险改动 支付、权限、安全、数据迁移、核心链路、性能关键路径、公共 SDK/API 必须写完整 spec + 技术 review + 测试计划 + 回滚方案

一个简单判断标准：

如果 reviewer 只看代码 diff 很难判断“为什么这么改”，就应该写 spec。
如果改坏了会影响真实用户、数据、安全、钱、权限，就必须写 spec。

2. Spec 模板

可以不要复杂，但字段要稳定。推荐模板：

# Spec: <功能/问题名称>

## 背景
为什么要做？当前问题是什么？相关链接/issue 是什么？

## 目标
这次完成后，用户或系统应该获得什么能力？

## 非目标
这次明确不做什么，避免 scope creep。

## 需求与验收标准
- Given ...
- When ...
- Then ...

## 方案概述
简述技术方案，不需要贴完整代码。

## 影响范围
涉及哪些模块、接口、数据表、配置、任务队列、前端页面等。

## 风险与边界
可能出错的地方、兼容性问题、性能风险、安全风险。

## 测试计划
单元测试、集成测试、E2E、手工验证分别怎么覆盖。

## 发布与回滚
是否需要灰度、配置开关、数据迁移、回滚步骤。

对于 L1 小任务，可以压缩成 5 行：

背景：
目标：
改动范围：
验收标准：
测试方式：

3. 什么时候必须写测试

建议团队直接定硬规则。以下情况必须有测试，除非 PR 里明确说明为什么不能测：

场景 测试要求
bug fix 必须加回归测试，证明 bug 不会回来
新业务逻辑 必须有单元测试或集成测试
API/接口变更 必须测成功、失败、边界输入
权限/认证/计费/数据隔离 必须测正反用例
数据迁移 必须测迁移前后数据一致性，必要时加回滚验证
重构共享模块 必须跑原有测试，最好补关键行为测试
前端交互变化 至少有组件测试、E2E 或截图/手工验证记录
性能关键路径 必须有基准或对比说明

可以允许这些不强制写测试：

  • 纯文案
  • 注释
  • README
  • 非功能性样式微调
  • 删除死代码，但要说明判断依据
  • 配置小改动，但要有 smoke check

重点是这句话：

“没写测试”不是不允许，但必须解释为什么不写，以及用什么方式替代验证。

4. 什么时候必须 Review

这里建议分两种 review：人类 review 和 AI review。

人类 review：

场景 要求
L0 可以走快速 review 或 self-review，按团队习惯
L1 至少 1 人 review
L2 至少 1 名熟悉相关模块的人 review
L3 至少 1 名模块 owner + 必要时安全/架构/DB review

必须找 senior/owner review 的情况：

  • 权限、认证、租户隔离
  • 支付、订单、账务
  • 数据库 schema/migration
  • 公共 API 或 SDK
  • 任务队列、重试、幂等
  • 大规模重构
  • 性能、缓存、一致性
  • 安全相关输入处理
  • AI 自动生成了大量核心逻辑

AI review 可以作为补充，适合检查：

  • 是否漏测
  • 是否有边界条件
  • 是否违反既有代码风格
  • 是否有潜在并发、权限、空值问题
  • spec 和实现是否一致

但不要规定“AI review 通过就等于可以合并”。AI review 是放大器，不是责任主体。

5. PR 里怎么说明 AI 参与过程

这个很重要。不是为了审判谁用了 AI，而是为了让 reviewer 知道哪些地方需要重点看。

推荐 PR 模板加一节：

## Summary
简述这次改了什么。

## Spec / Issue
链接到 spec、issue 或需求文档。

## Changes
- 改动点 1
- 改动点 2

## AI Assistance
- 使用工具：CCG Workflow / Claude Code / Codex / Cursor / 其他
- AI 参与内容：需求拆解 / 代码生成 / 测试生成 / review / 重构建议
- 人工确认内容：关键设计、边界条件、测试结果、最终 diff
- 需要重点 review 的 AI 生成部分：<文件/模块>

## Tests
- [ ] 单元测试：
- [ ] 集成测试：
- [ ] E2E：
- [ ] 手工验证：
- [ ] 未覆盖项及原因：

## Risk
风险等级：L0 / L1 / L2 / L3  
回滚方式：

## Screenshots / Logs
如有前端或行为变化，附截图、录屏或关键日志。

AI 参与说明不要写成“我用了某某模型，所以没问题”。应该写成：

AI 帮我生成了初版实现和测试，我人工检查了业务逻辑、错误路径和最终 diff。重点请 review auth/permissions.ts 的权限判断和 billingService.ts 的幂等逻辑。

这对 reviewer 很有帮助。

我的推荐落地方式

你可以跟领导提一个轻量版规范：

  1. 先统一任务分级：L0/L1/L2/L3。
  2. L2 以上必须写完整 spec。
  3. bug fix 和业务逻辑变化必须有测试或解释。
  4. L2 以上必须 owner review。
  5. PR 必须说明 AI 参与范围、测试结果、风险和回滚方式。
  6. 工具暂时不统一，CCG、Superpowers、Cursor、Codex 都可以，但交付物必须一致。

这样比“所有人必须用某个 workflow”更容易被团队接受，也更符合管理目标：不是管大家怎么敲键盘，而是管质量、风险和可复盘性。

提问4

项目用svn做版本管理，上面的结论会有所不同吗

回答4

会有不同，但大方向不变：仍然应该统一团队流程层，不一定强制统一 AI 工具。
区别在于，SVN 没有 Git/PR/worktree 那套天然协作机制，所以流程规范反而更重要。

主要变化有 4 点。

1. Superpowers 不能原样套

Superpowers 很多流程默认围绕 Git，比如 branch、worktree、PR、finish branch。你们用 SVN 的话，这部分价值会打折，需要改造成：

Git 流程 SVN 替代
feature branch SVN branch 或独立 working copy
worktree 多 checkout 一个工作目录
PR review svn diff 提交前 review
merge PR SVN merge 或直接 commit
commit history SVN revision + issue/spec 链接

所以 Superpowers 的 spec、plan、TDD、review 思路可以借鉴，但 Git 相关流程要本地化。

2. SVN 项目更需要提交前 Review

Git 项目通常有 PR 卡口。SVN 很多团队容易变成“本地改完直接 commit 到主干”。
这在 AI 工作流里风险更高，因为 AI 可能快速生成大量代码，人还没充分 review 就进了中央仓库。

建议规定：

  • L0 小改动：可以直接提交或轻 review。
  • L1 普通 bug/小功能：至少 self-review + 测试记录。
  • L2 多模块/接口/业务逻辑变更：必须先发 svn diff review。
  • L3 权限、支付、数据、安全、核心链路：必须 spec + 测试计划 + owner review 后再 commit。

3. CCG 要验证 SVN 适配性

CCG 如果主要依赖 patch、spec、多模型 review，那理论上适配 SVN 没问题。
但要确认它有没有强依赖：

  • git status
  • git diff
  • git branch
  • git worktree
  • git commit

如果有，就需要改成：

svn status
svn diff
svn patch
svn revert
svn commit

判断标准很简单：

它能不能基于 SVN working copy 稳定理解改动、生成 diff、做 review，并且不绕过人工提交。

4. Spec、测试、AI 说明规则基本不变

版本管理工具不会改变这些原则：

  • bug fix 要有回归测试。
  • 业务逻辑变化要测成功、失败、边界条件。
  • 高风险任务必须有 spec。
  • 没写测试要说明原因和替代验证方式。
  • AI 生成的关键逻辑必须人工确认。
  • 每个提交要能追溯到 issue/spec/test/review。

SVN 下可以把原来的 PR 模板改成“review/commit 模板”：

## Summary
本次改动做了什么。

## Spec / Issue
需求、缺陷或 spec 链接。

## AI Assistance
- 使用工具：
- AI 参与内容：
- 人工确认内容：
- 需要重点 review 的部分：

## Tests
- 单元测试：
- 集成测试：
- 手工验证：
- 未覆盖项及原因：

## Risk
风险等级：L0 / L1 / L2 / L3
回滚方式：

## SVN
- svn diff 链接或附件：
- review 人：
- commit revision：

我的结论是：

用 SVN 后，统一流程层更有必要；但更不建议盲目照搬 Git 原生的 AI workflow。
比较稳的做法是：借鉴 Superpowers 的流程纪律，用 CCG 或其他工具执行，但团队统一 spec、测试、review、commit 说明和 SVN diff 审核规则。

posted @ 2026-05-06 22:56  Jay_Auditore  阅读(87)  评论(0)    收藏  举报