AI 编程工具遍地开花,为什么还需要一个工作流框架?—

AI 编程工具遍地开花,为什么还需要一个工作流框架?——superPlus 全面解析

“
当每个 AI 编程助手都能生成代码时，真正的差距不在于"能不能写"，而在于"能不能写出对的代码、并且知道自己写对了"。
”

一、一个思想实验

假设你是一个 Tech Lead，团队来了三个新成员：

Alice：每天写 500 行代码，但不看需求文档
Bob：每天写 300 行，但不写测试
Carol：每天写 200 行，但会先看需求、写测试、做 Code Review、写文档

一年后，谁的代码最值得保留？

这其实不是一个关于"产量"的问题，而是一个关于可信任度的问题。Alice 和 Bob 的代码会让项目变成技术债的泥潭，只有 Carol 的代码能在长期维护中存活。

现在打开你用的 AI 编程工具——它运行起来更像 Alice、Bob、还是 Carol？

如果你用过 Claude Code、Cursor 或 OpenCode 写过代码，你一定经历过这样的循环：

告诉 AI 要实现什么功能
AI 刷刷刷写出一堆代码
运行，报错
把错误贴回去让 AI 修
修好了，但引入新 bug
再修……再出 bug……
一小时后，你发现自己手动重写还快些

这不是你的问题，也不是 AI 不够聪明。问题在于：AI 编程缺少一个工程化的工作流。 你写代码时，有需求文档、有设计评审、有 Code Review、有测试用例、有上线 checklist。但 AI 写代码时，通常只是一个"一次性提示 → 生成代码"的直筒子——没有设计、没有测试、没有验证、没有归档。

那如果，我们把软件工程的纪律，套到 AI 写代码的过程中呢？

这就是 superPlus 在做的事——把每个 AI 代理训练成 Carol。

二、当前 AI 编程的四个结构性缺口

我系统梳理了当前主流 AI 编程工具的现状，发现四个结构性缺口：

缺口 1：没有需求-代码的双向追溯

你用 AI 实现了一个功能。过两个月，业务方说"这个逻辑不对，当时不是这么说的"。你看着代码，完全想不起来当时为什么这样做，AI 也不会记得。传统软件工程有 PRD、有设计文档、有 CR 记录。AI 编程里这些全丢了。

缺口 2：没有质量门禁

AI 写完了，它说"写好了"。你怎么验证？

功能覆盖了所有场景吗？
边界情况处理了吗？
字段命名和 API 文档一致吗？
异常路径有回滚吗？

没有任何工具回答这些问题。

缺口 3：没有依赖路径管理

AI 改了一个字段类型。看起来无害。但：

前端表单用了它
API DTO 映射了它
Service 层转换了它
DAO 层持久化了它

谁来检查这条链路通了没有？没有人。

缺口 4：没有知识沉淀

修了一个 bug → 下次 AI 可能犯同样的错。做了一次重构 → 下一次 AI 又回到旧模式。完成了功能 → 没有人更新文档。每次对话都是新的开始，项目没有"记忆"。

三、superPlus：用工程纪律补缺口

superPlus 是一个 AI-Native 规格驱动开发（Spec-Driven Development）工作流套件。它不是又一个 AI 编程助手，而是让现有 AI 编程助手（Claude Code、Cursor、OpenCode 等）按照软件工程纪律工作的方法论框架。

不是 AI 编程助手 → 它跑在 Claude Code / Cursor / OpenCode 之上
不是框架 → 它不约束你的技术栈
是一个方法论 + 工具集 → 定义 AI 该怎么一步步把代码写对

融合两大开源项目的思想

superPlus 继承并扩展了两个开源项目的核心思路：

来源	核心贡献	superPlus 的扩展
OpenSpec	Artifact DAG、3D 验证、智能增量合并	→ 5D 验证（+ 业务流完整性 + 字段一致性）→ 两端补全：前加 exploring/designing，后加 apply-change
Superpowers	子代理 TDD 实现、systematic debugging	→ 上层加规格约束（write-plan-tasks）→ 下层加 5D 验证兜底（verify-change）→ 调试闭环加知识沉淀和自动触发

superPlus 是独立的工作流套件，不依赖也不扩展任一项目。

对四个缺口的回应

缺口	superPlus 方案	具体技能
无追溯	制品管道 ——每一步都有产出物，任何时候可回溯	write-plan-tasks → apply-change → archive-change
无门禁	5D 验证 ——7 轮交叉检查，CRITICAL 自动阻止	verify-change
无路径管理	字段一致性追踪 ——全链路比对，消灭"命名漂移"	verify-change（Field Consistency 维度）
无沉淀	根因调试闭环 + Spec 同步 ——修复即归档，实现即文档	root-cause-debugging → sync-specs

四、13 个技能全景

superPlus 以"技能"（skill）为基本单位组织工作流：8 个核心技能 + 5 个辅助技能。

核心 7 步流水线

exploring ──→ designing ──→ write-plan-tasks ──→ apply-change ──→ verify-change ──→ sync-specs ──→ archive-change(探索)       (设计)        (生成制品)           (TDD 实现)       (5D 验证)          (合并规格)      (归档收尾)

技能	触发时机	核心产出	纪律铁律
`exploring`	需求不明确	探索摘要（对话中）	只探索不实现
`designing`	需求明确	设计文档 `docs/designs/`	禁止写任何代码
`write-plan-tasks`	设计获批	4 件套（proposal + specs + plan + tasks）	独立 subagent 审查设计无曲解
`apply-change`	任务就绪	实现代码（测试全部通过）	TDD + 两阶段审查
`verify-change`	实现完成	5D 验证报告 + Issues Triage	7 轮交叉检查，CRITICAL 自动进入调试回路
`sync-specs`	验证通过	合并后的主规格库	冲突检测 + 增量合并
`archive-change`	全部完成	归档目录 `docs/changes/archive/`	幂等性确认

辅助技能

技能	用途	关键特性
`quick-change`	小型变更（4 步浓缩）	3D 验证 + 内置轻量调试回路
`root-cause-debugging`	系统化调试	5 阶段 + 知识捕获 + verify-change 自动触发
`test-driven-development`	TDD 红-绿-重构	硬性纪律：先写失败测试后才能写实现代码
`using-git-worktrees`	隔离工作区	自动检测 .gitignore 状态
`writing-skills`	编写/编辑技能文档	把 TDD 应用于流程文档编写

五、规格驱动：制品管道详解

superPlus 最独特的设计是一套不可跳过的制品管道。从设计文档到最终代码，必须经过 4 个制品阶段：

docs/designs/YYYY-MM-DD-<topic>-design.md         │         │ write-plan-tasks         ▼docs/changes/<name>/├── 1.proposal.md        ← 为什么做（Why）├── 2.specs/             ← 做什么（What）—— delta 规格│   └── <capability>/spec.md├── 3.plan.md            ← 怎么做（How）—— 架构方案└── 4.tasks.md           ← 具体步骤（Steps）         │         │ apply-change（TDD）         ▼         code（所有测试通过）         │         │ verify-change → sync-specs         ▼docs/specs/<capability>/spec.md  ← 主规格库（多人协作的信任锚点）

关键纪律：没有 plan 不能写 tasks，没有 tasks 不能写代码。每个步骤都不能跳过。

制品模板示例

1.proposal.md 的 YAML frontmatter：

---title:"[变更标题]"status:draftcreated:YYYY-MM-DDauthor:AI(superPlus)impact:medium-files:["src/path/file.ts",...]-capabilities:["capability-name"]-dependencies:[]---

4.tasks.md 的要求是每步 2-5 分钟，附带完整代码和命令，不留占位符——这是确保 AI 子代理能独立执行的关键设计。

六、子代理并行 TDD 实现

apply-change 是真正"写代码"的阶段。它会读取 tasks.md 中的依赖关系，智能调度多个 AI 子代理：

调度逻辑

4.tasks.md    │依赖图分析    ├── Task A (独立) → @fixer TDD → 验证通过    ├── Task B (独立) → @fixer TDD → 验证通过    ├── Task C (依赖A) → 等待A完成 → @fixer TDD → 验证通过    └── Task D (依赖B+C) → 等待B、C完成 → @fixer TDD → 验证通过                            │                    合并验证 ←┘                    ├── Spec 合规审查（由独立 oracle 执行）                    └── 代码质量审查（由独立 oracle 执行）                            │                    全部测试通过

独立模块 → 多个子代理并行执行
共享依赖 → 先串行后并行
每个任务 → 严格执行 TDD 三阶段
两阶段审查 → 规格合规 → 代码质量，不可跳过

TDD 铁律

RED（写失败测试）→ 验证 RED（确认测试本身有效）→ GREEN（写最小实现）→ 验证 GREEN → REFACTOR（清理，保持绿色）

必须先看到测试失败（证明测试有效），然后才允许写实现代码。禁止 mock 测试和超过需求的 YAGNI。

七、5D 验证：7 轮交叉检查

验证是 superPlus 最强大的差异化能力。它继承 OpenSpec 的 3D 验证并扩展了 2 个原创维度：

维度	英文	聚焦	典型发现
完整性	Completeness	所有任务都完成了？	未实现的需求、缺失的测试
正确性	Correctness	代码和规格一致？	实现偏离 spec、遗漏边界场景
一致性	Coherence	遵守了架构设计？	层边界被破坏、架构走样
业务流完整性 ⭐	Business Flow	状态机完整、异常路径有处理？	死状态、缺少回滚、规则只在 UI 层校验
字段一致性 ⭐	Field Consistency	字段全链路对齐？	字段丢失、命名漂移、类型不匹配

7 轮检查流程

Round 1: 全局完整性扫描Round 2: 全局一致性扫描Round 3-7: 各维度聚焦检查（完整性 → 正确性 → 一致性 → 业务流 → 字段）

业务流完整性的典型发现：状态机中有无法到达/无法退出的死状态、关键操作缺少回滚机制、业务校验规则只在 UI 层实现而未在 API 层防护。

字段一致性的典型发现：前端表单叫 userName，后端 DTO 叫 username，数据库列名 user_name——这种"命名漂移"在传统开发中总是到联调阶段才手忙脚乱地发现，而在 superPlus 中会被自动标记出来。

发现问题后分为三类：

CRITICAL → 必须修，自动进入调试修复回路
WARNING → 建议修，不阻塞
SUGGESTION → 记录在案，供后续参考

八、根因调试闭环

root-cause-debugging 是 superPlus 独有的差异化能力。它不是简单地"修 bug"，而是一个完整的 调查 → 修复 → 归档 闭环：

5 阶段流程

阶段	操作	产出
Phase 1 根因调查	读错误栈 → 复现 → 检查最近变更 → 可视化数据流 → 向后追踪到根因	根因假设
Phase 2 模式分析	找同类问题 → 对比其他项目实现差异	模式匹配报告
Phase 3 假设验证	每次只验证一个假设 → 最小测试验证	确认 / 否认
Phase 4 TDD 修复	写失败测试 → 单点修复 → 3D 验证 → 完整测试套件	修复代码
Phase 5 知识捕获	主动询问是否将发现写入 specs / design / 调试注释	沉淀文档

自动触发回路

verify-change 发现 CRITICAL 问题    → 自动调用 root-cause-debugging    → 5 阶段调查 + 修复    → re-verify（增量重验）    → 全部通过 → 继续 sync-specs

相比 Superpowers 的 systematic-debugging，新增的关键能力：

进度看板 — 进入技能即创建 todo，防止中断后丢失上下文
知识沉淀询问 — 修复完成后主动询问是否写入 specs / design / debug notes
验证回路自动触发 — verify-change 发现 CRITICAL 后自动调用，无需人工选择

此外还有一条重要的安全保障：连续 3 次修复失败 → 质疑架构设计——这时问题不再是"怎么修 bug"，而是需要重新审视设计本身。

九、Quick-Change：两条路径按需选择

7 步流程对大型特性很合适，但有时候你只是改个字段、修个小 bug。superPlus 提供了第二条路径：

路径	步骤	制品格式	适用场景
全流程	7 步	4 件套（proposal + specs + plan + tasks）	中大型需求、新功能
quick-change	4 步	单文件 `1.change.md`	小型改动（加字段、改校验、修小 bug）

Quick-Change 流程

Quick Spec（单文件规格） → Implement（直接编码） → Verify（3D验证） → Finalize（同步+归档）

适合 1-3 个文件、5-50 行代码的范围。

关键设计：仅手动调用

Quick-change 最微妙的设计决策是：通过 /sp-quick-change 命令手动触发，AI 不会自动检测并"降级"使用。

为什么不做成自动检测？因为 AI 倾向于走捷径——如果 AI 可以自动选择路径，它总是倾向于选更短的那条，哪怕变更很复杂。于是 superPlus 选择让人来决定：你输入命令才走轻量模式，默认总是全流程。

实操演示：给订单详情加 couponCode 字段

传统 AI 编程模式：

你："给订单详情加一个 couponCode 字段"AI：（刷刷刷改完三个文件）你："等一下，订单 Service 的 DTO 没改"AI：（又改）你："数据库没有这个列……"

使用 superPlus quick-change：

你：/sp-quick-change 给订单详情加 couponCode 字段Step 1 - Quick Spec：  创建 1.change.md → 你确认变更范围和影响  ✓ 确认：前端展示 + API 返回 + DB 存储Step 2 - Implement：  AI 直接改代码（软 TDD，现有测试全绿）  ✓ 3 个文件修改完成Step 3 - Verify：  3D 验证：  ✓ 正确性：代码实现了 spec 需求  ✓ 业务流：订单详情返回新字段，前端正常展示  ✓ 字段一致性：couponCode → couponCode → coupon_code 全链路对齐Step 4 - Finalize：  ✓ specs 同步到主规格库  ✓ 变更归档

差别不是"快了多少"，而是可信任度——你知道 couponCode 在前端、API、数据库三层是对齐的，因为机器帮你检查过了。

十、和同类方案怎么比？

superPlus 不是第一个尝试给 AI 编程加入结构的工作流。但它在关键维度上做了差异化：

能力维度	OpenSpec	Superpowers	superPlus
需求探索	⭐⭐⭐	⭐	⭐⭐⭐ exploring 技能
设计文档	⭐⭐⭐	⭐	⭐⭐⭐ designing 技能
规格编制	⭐⭐⭐	⭐	⭐⭐⭐ 完整 4 件套管道
代码实现	⭐	⭐⭐⭐	⭐⭐⭐ 子代理并行 TDD
质量控制	⭐⭐⭐（3D）	❌	⭐⭐⭐⭐（5D + 7 轮）
调试修复	❌	⭐⭐	⭐⭐⭐ 5 阶段 + 知识捕获 + 自动触发
文档同步	⭐	❌	⭐⭐⭐ 智能合并 + 冲突检测
变更归档	❌	❌	⭐⭐⭐ 幂等归档 + 完整性验证

superPlus 的定位很明确：在 OpenSpec 和 Superpowers 各自擅长的领域都不比它们差，在它们缺失的领域补上原创能力。 目的不是替代二者，而是提供一条更完整、更工程化的 AI 编码工作流。

十一、争议与回应

"这不就是加了一堆文档步骤吗？"

文档是产出物，不是目的。superPlus 的核心不是文档，而是每个步骤的质量门禁：

设计阶段：2-3 个方案让你选，不是随便写写
计划阶段：独立 AI 审查是否曲解了设计
实现阶段：TDD + 两阶段审查（合规 + 质量）
验证阶段：7 轮交叉检查，CRITICAL 直接阻止

文档只是这些过程的自然产出。没有质量门禁的文档才是累赘，有质量门禁的文档是资产。

"让 AI 按流程走，不会降低效率吗？"

短期看，是的。写一个 design doc 需要时间，走 7 步流程需要时间。

但问题在于：你把时间花在了哪里？

花在前期明确需求 → 后期少返工
花在验证 → 上线少出事故
花在归档 → 以后回溯省时间

效率不是"写代码的速度"，而是从需求到可交付的端到端时间。而且对于小型改动，有 quick-change 轻量路径可以选。

"中小项目有必要吗？"

没必要每次都走全流程。这就是 quick-change 存在的意义。

但有一条底线建议：如果这个变更出了问题会影响线上用户或业务数据，至少走 quick-change——永远不要直接改。

十二、安装与快速上手

superPlus 目前已适配四个平台：

平台	安装方式	体验
OpenCode	插件安装 `opencode.json` → `"plugin": [...]`	🥇 13 个 `/sp-*` 斜杠命令，最佳体验
Claude Code	`/plugin marketplace add xcyxiaoxiang/superplus`	技能自动发现
Codex CLI	`codex plugin marketplace add xcyxiaoxiang/superplus`	需工具映射适配
Cursor	符号链接到 `.cursor/skills/`	技能文件发现

OpenCode 一键体验

{"plugin": ["superplus@git+https://github.com/xcyxiaoxiang/superplus.git"]}

安装后在 TUI 中输入 / 即可看到全套命令：

/sp-exploring           /sp-designing/sp-write-plan-tasks    /sp-apply-change/sp-verify-change       /sp-sync-specs/sp-archive-change      /sp-quick-change/sp-root-cause-debugging/sp-tdd                 /sp-writing-skills/sp-worktrees           /sp-superplus

最快上手路径：

/sp-exploring       # 探索一个新需求/sp-designing       # 尝试设计架构/sp-quick-change    # 试一个小改动

十三、一个更深的思考：AI 编程的工程化拐点

去年我观察到一个趋势：AI 编程工具开始分化。

第一代（Copilot、Codeium 等）解决"代码补全"——让开发者打字更快
第二代（Claude Code、Cursor、Cursor Agent 等）解决"代码生成"——让 AI 独立完成任务
第三代应该解决什么？ 我的判断是："代码信任"

当 AI 写的代码占比从 20% 提升到 80%，开发者的角色从"写代码的人"变成了"审核代码的人"。这时候，信任比效率更重要。

需求	传统方案	superPlus
了解变更背景	问同事 / 翻聊天记录	读 proposal.md
确认功能完整	手动测试	5D 验证报告
检查字段对齐	联调时才能发现	Field Consistency 自动标记
修 bug	凭经验猜	root-cause-debugging 5 阶段系统化调查
知识交接	写 Wiki（没人看）	自动同步到 specs 库

当 AI 写的代码越来越多，这些"工程保障"会从加分项变成必需品。

superPlus 给出的方案并不性感——它本质上就是把软件工程的老规矩翻译给了 AI。但或许，真正工程化的东西本来就不应该性感。它应该枯燥、可预测、可重复——就像一条流水线。

⭐ Star 项目：github.com/xcyxiaoxiang/superplus
🐛 提 Issue：反馈问题或建议
🔧 提 PR：技能改进、新语言模板、平台适配
开源协议：MIT
当前版本：v0.2.3

如果你也对"AI 编程的工程化"这个话题感兴趣，欢迎在评论区讨论或到 GitHub 提 Issue。正在寻找 contributors！