Skip to content

evaluation.md

Latest commit

 

History

History
206 lines (154 loc) · 9.37 KB

evaluation.md

File metadata and controls

206 lines (154 loc) · 9.37 KB

SU/CCB 协作机制 — 行业通用性与可行性评估报告

评估日期: 2026-04-08 评估方式: Claude + Codex 双重独立审计后综合 评估对象: tmp/ 下的 ccb-plugin + codex-skills 完整设计（v0.2） 状态: 初始评估，待实际使用后复盘

一、行业适用性

场景 评级 理由
独立开发者 + AI 协作 ★★★★★ 核心设计用例——一人做架构师+PM，AI 做执行
2-5 人小团队 ★★★★☆ 类似轻量 lead-review 系统，需解决角色分配
后端/平台/API 密集 ★★★★★ 风险承载型工程最强，审批门+ADR 天然适配
全栈 Web 项目 ★★★★★ 明确的模块边界、验证命令、接口定义
数据管道/ETL ★★★★☆ 适配，勘探模式可能比实施模式更常用
从零开始的项目 ★★★★★ project.yaml 自动扫描 + 渐进式文档
成熟项目维护 ★★★☆☆ 初始化成本高（需补建索引），补建后收益明显
移动端（Flutter/RN） ★★★★☆ 适配，但 UI 验证需人工参与更多
合规/审计敏感项目 ★★★★★ ADR + 审批门 + 可审计契约天然适配
原型/Hackathon ★★☆☆☆ 流程过重，不推荐
底层基础设施/内核 ★★☆☆☆ 验证链路复杂，半开放实施的自主边界不好定义
10+ 人团队 ★★☆☆☆ 二元模型不支持多角色分工，需要治理层才行

明确不适用的场景

  • 需要交互式调试的嵌入式/硬件项目
  • 高度依赖 GUI 操作的无代码/低代码平台
  • 超小一次性项目、高度视觉化探索性产品工作

二、与现有工程实践的映射

角色映射

SU/CCB 角色 传统团队对应 映射质量
Claude（决策者） Tech Lead / 架构师 强——方案设计、任务拆分、审查
Codex（执行者） Senior Dev 强——自主实现、回抛不确定性

流程映射

SU/CCB 步骤 Agile/Scrum 对应 映射质量
Step 1-2（需求+设计） Backlog Refinement + Solution Design 强
consult 模式 Tech Discussion / RFC / 架构评审会 强
Step 3（任务切片） Sprint Task Slicing 强
Step 4（派工+执行） Task Assignment + Execution 强
Step 5（审查） Code Review + QA 中——不看代码细节，看设计符合性
Step 6（归档） Sprint Closure + Documentation 强
ADR（decisions/） ADR 实践 完美兼容
精简回执 PR Description 中——更结构化
审批门（红黄绿） Stage Gate 强

与传统 Code Review 的关键差异

传统 Code Review 是事后审查。SU/CCB 在编码前插入设计审查 + 协商，编码后插入回执审查——减少了"正确实现了错误的东西"的概率。

核心洞察

这套机制本质上是把敏捷开发的 Planning → Execution → Review → Retrospective 循环编码化，让 AI 代替人承担其中"可自动化"的部分。它不是新发明，而是成熟工程实践的 AI 化编排。

三、实际落地障碍

学习曲线

  • /su:init：低（一条命令）
  • /su:plan：中（需理解审批门时机）
  • 协商模式：对用户透明（自动触发），但调试时复杂
  • 整体评估：一周内可上手，一个月内熟练

最可能的失败模式

失败模式 概率 原因 缓解措施
用户跳过审批门直接催执行 高 人类天性——"别废话，直接做" 简单任务提供快速通道
协商在简单任务上浪费时间 中 简单改动不需要多轮讨论 Claude 自动判断是否需要协商
async transport 不稳定 中 ask/hook 依赖 daemon 和 pane 路由 pend 兜底 + 错误重试
仪式化模板过多 中 小项目模板显得臃肿 提供裁剪版（只保留核心3机制）
索引文件过期不更新 中 architecture.yaml 等需要持续维护 首次 plan 自动刷新
用户对 spec 质量要求低 低 20-50 行已经很轻量了 —

协商模式 ROI 分界线

值得协商（ROI 正） 不值得协商（ROI 负）
跨模块变更 单文件编辑
Schema/接口变更 明显 bugfix
安全/性能敏感路径 格式化/CRUD
遗留代码理解不足 简单测试补充
迁移/重构爆炸半径不明 实现细节不影响接口
架构选择有多个可行方案 方案明显唯一

四、竞品与替代方案对比

功能矩阵

维度 SU/CCB Cursor Copilot Windsurf Aider
核心定位 AI 工程操作系统 AI 编辑器 AI 编码助手 AI 流式编程 AI 终端配对
设计-执行分离 ✅ 核心 ❌ ⚠️ 弱 ❌ ❌
审批门 ✅ ❌ ❌ ❌ ❌
多 AI 协作 ✅ ❌ ❌ ❌ ❌
多轮协商 ✅ ❌ ❌ ❌ ❌
文档治理 ✅ ❌ ❌ ❌ ❌
异步派工 ✅ ❌ 同步 ❌ 同步 ❌ 同步 ❌ 同步
产品集成度 低（CLI） 高 高 高 中
上手摩擦 中 低 低 低 低
适合场景 严肃工程 快速原型+日常 Issue→PR 连续交互 快速改动

差异化核心

市面上其他方案把 AI 当**"智能补全工具"，SU/CCB 把 AI 协作当"工程管理问题"**来解决。这是唯一把设计审查、审批门、回抛机制、多模型编排作为一等公民的方案。

威胁

Cursor/GitHub/Windsurf 正在快速吸收 planning、review、background agents、rules 到原生产品中。SU/CCB 的护城河在于治理严格性和多模型协作编排——但如果不产品化可靠性，差异化会被蚕食。

五、执行者（Codex）的真实体验反馈

真正有帮助的部分

  1. 角色分离——认知负荷大幅降低，不用一边想设计一边写代码
  2. "先读 spec 再探索"——执行路径清晰
  3. 显式回抛——遇到边界问题主动回抛，避免"做完才发现方向错"
  4. 精简回执——<2k 让审查方快速定位关键信息
  5. 基于回执审查而非重读全部 diff——效率极高

感觉是形式化开销的部分

  1. 简单任务的完整 Step 命名流程
  2. 答案已经明显时的协商轮次
  3. 小项目的模板膨胀
  4. command → contract → template → index → archive 之间的间接跳转层过多

如果只保留 3 个核心机制（Claude + Codex 一致选择）

# 核心机制 不可妥协的理由
1 角色分离 + 审批门 灵魂——没有这个就是普通的 AI 自动补全
2 精简回执 + 回抛规则 执行质量的核心保障——防止方向性错误
3 协商模式 v0.2 最大价值——设计质量飞跃，尤其在复杂/遗留场景

六、SWOT 分析

评估
Strengths（优势） 强治理、显式委托边界、可审计契约、ADR 兼容、多模型协作、设计-执行分离的唯一性
Weaknesses（劣势） 安装摩擦、流程开销、async 传输脆弱性、比编辑器原生 agent 更难上手
Opportunities（机会） 定位为小团队/合规团队的"AI 工程操作系统"；遗留系统现代化最佳伴侣；CCB 协议标准化后可扩展更多 provider
Threats（威胁） Cursor/GitHub/Windsurf 正在把 planning/review/background agent/rules 吸收进原生产品；差异化可能被蚕食

七、最终判定

场景 判定
独立专业开发者、高级小团队、后端/平台/集成密集型项目 推荐
移动/全栈产品团队（裁剪协商+保留快速通道） 有条件推荐
原型优先、超小项目、高度视觉化探索性产品 不推荐

八、复盘待验证项

以下假设需要在实际使用后验证，作为后续复盘的检查清单。

  • 协商模式在中等复杂度任务中是否真的减少了返工？
  • 审批门是否被用户普遍跳过？快速模式使用频率如何？
  • async transport（ask/hook/pend）的实际故障率是多少？
  • project.yaml 自动扫描的准确率如何？手动修正频率？
  • 精简回执 <2k 限制是否足够？是否有信息丢失？
  • consult 模式的平均轮次是多少？soft_max=3 是否合适？
  • SuperClaude 集成是否真的提升了设计质量？还是增加了延迟？
  • 小项目是否感觉流程过重？裁剪版是否需要？
  • 首次上手到熟练的实际时间？
  • 与 Cursor 等产品的互补/冲突关系在实践中如何表现？

参考来源

本地设计文件

  • tmp/00-设计总览.md
  • tmp/ccb-plugin/README.md
  • tmp/codex-skills/README.md

外部竞品参考（2026-04-08 访问）

评估完成。待实际使用后进行第一轮复盘。