Merge branch 'main' of https://github.com/hobbytp/hobbytp.github.io

Author: hobbytp

content/zh/ai_programming/superpowers.md

@@ -0,0 +1,178 @@
+"Superpowers"是一个用于编码代理的软件开发工作流框架，基于可组合技能和初始指令，帮助代理高效完成开发过程。其核心功能包括设计优化、实施计划制定、测试驱动开发（TDD）、子代理驱动开发以及代码审查等。工作流涵盖从设计到实现的完整过程，并通过技能库自动触发相关技能以确保每任务的高效执行和质量把控。
+
+
+## 核心设计哲学
+
+**Superpowers 的核心设计哲学（Philosophy）**可以概括为四条“硬约束式”原则——它们不是建议，而是通过技能自动触发与强制工作流来落实。
+
+### 1) 测试驱动开发（Test-Driven Development）
+- **主张**：永远先写测试，再写实现。
+- **落地方式**：强调严格的 **RED → GREEN → REFACTOR** 闭环：  
+  1) 写一个会失败的测试（红）  
+  2) 观察其失败（确认测试有效）  
+  3) 写最少代码让测试通过（绿）  
+  4) 重构并保持测试通过（重构）  
+- **强度**：文档里甚至明确“会删除测试之前写的代码”，本质是在流程层面防止“先写实现、后补测试”的滑坡。
+
+### 2) 系统化优于拍脑袋（Systematic over ad-hoc）
+- **主张**：用流程替代猜测，用可复用的方法替代随机试错。
+- **落地方式**：比如调试强调“系统化调试”的**分阶段根因分析**，以及“完成前必须验证真的修好（verification-before-completion）”。  
+- **关键点**：这会强迫智能体在每一步都有“可检验的证据链”，而不是凭感觉宣布完成。
+
+### 3) 降低复杂度（Complexity reduction）
+- **主张**：把“简单”作为第一目标，持续压制不必要的复杂度。
+- **落地方式**：在实施计划与执行里显式强调：
+  - **YAGNI**：不做“可能以后用得上”的功能  
+  - **DRY**：避免重复逻辑导致维护成本爆炸  
+  - 任务拆分为“2–5 分钟粒度”的小步，减少认知负担与偏航概率  
+- **效果**：降低架构过度设计概率，同时让并行子智能体执行更可控。
+
+### 4) 证据优于宣称（Evidence over claims）
+- **主张**：在宣布成功前，必须先验证。
+- **落地方式**：把验证写进每个任务的“验收步骤”，并在分支收尾时再次全量跑测试、确认基线干净。  
+- **本质**：用可复现的检查（测试、命令、清单）取代“我觉得好了”。
+
+---
+
+### 这套哲学的“系统级”体现：强制工作流，而非提示语
+README 里一句话点明设计取向：**“The agent checks for relevant skills before any task. Mandatory workflows, not suggestions.”**  
+也就是说它的哲学不是写在墙上的标语，而是通过：
+- 先澄清规格 → 再设计签字 → 再计划 → 再分任务执行 → 过程中强制 TDD/审查/验证 → 分支收尾
+把“正确的工程行为”固化成默认路径。
+
+
+## 完整工作流程
+
+**Superpowers 的完整工作流程**可以用“一条主线 + 七步强制技能链”来描述：先把需求/设计/计划变成可执行的工程任务清单，再用子智能体/批处理执行，并在每一步强制测试、验证与审查。
+
+---
+
+### 一条主线（从启动到交付）
+1. **启动编程智能体**：一旦识别到你在“要做东西”，不会立刻开写代码。  
+2. **反问澄清意图**：先问清你“真正要做什么”，把模糊想法收敛成**可描述的目标**。  
+3. **抽取规格说明（spec）并分块展示**：把 spec 拆成短段落给你确认，确保你能读懂、能消化、能纠错。  
+4. **你确认设计（sign off）**：设计通过后才进入实现阶段。  
+5. **生成实现计划（implementation plan）**：计划写到“一个不熟悉上下文、甚至不爱测试的初级工程师也能照做”的程度；并强调 **红/绿 TDD、YAGNI、DRY**。  
+6. **你说 “go”**：进入执行期，启动“子智能体驱动开发（subagent-driven-development）”或批量执行。  
+7. **持续按计划推进**：任务执行 → 审查 → 验证 → 继续，尽量避免偏离计划。
+
+---
+
+### 七步强制技能链（The Basic Workflow）
+
+> README 明确：**每次任务前都会检查相关技能；这是强制工作流，不是建议。**
+
+#### 1) brainstorming（头脑风暴/需求与设计澄清）
+- **触发时机**：写代码之前
+- **做什么**：
+  - 通过问题把粗糙想法不断精炼（偏苏格拉底式）
+  - 探索备选方案与权衡
+  - 将设计按“可读的小节”呈现给你逐段确认
+  - **产出**：保存成设计文档（design document）
+
+#### 2) using-git-worktrees（用 Git worktrees 隔离开发）
+- **触发时机**：设计批准后
+- **做什么**：
+  - 在新分支/新 worktree 创建隔离工作区
+  - 运行项目初始化
+  - 验证测试基线是干净的（确保环境可控）
+- **目标**：并行/隔离开发，避免污染主工作区
+
+#### 3) writing-plans（写可执行实现计划）
+- **触发时机**：有已批准设计
+- **做什么**：
+  - 把工作拆成非常小的任务：**每个 2–5 分钟**
+  - 每个任务都包含：
+    - 精确文件路径
+    - 需要写的完整代码（或明确改动点）
+    - 验证步骤（怎么证明做对了）
+- **目标**：把“想做什么”变成“按步骤就能做完”的工程脚本
+
+#### 4) subagent-driven-development / executing-plans（执行计划）
+两种模式二选一（或结合）：
+
+- **subagent-driven-development**（子智能体驱动开发）
+  - 每个任务派发一个“新子智能体”去做
+  - **两阶段审查**：
+    1) 是否符合规格/计划（spec compliance）
+    2) 代码质量审查（code quality）
+  - 适合：并行、快速迭代、降低单个智能体上下文污染
+
+- **executing-plans**（批量执行 + 人类检查点）
+  - 将任务分批执行
+  - 每批结束设置人工 checkpoint 决策是否继续
+  - 适合：你希望更强掌控节奏/风险
+
+#### 5) test-driven-development（实现过程中强制 TDD）
+- **触发时机**：进入实现阶段就会介入
+- **规则**：严格 **RED → GREEN → REFACTOR**
+  - 先写失败测试并确认它确实失败
+  - 写最小实现让测试通过
+  - 重构保持通过
+  - 提交（commit）
+- **额外强硬点**：明确会删除“测试之前写的代码”，防止先实现后补测
+
+#### 6) requesting-code-review（任务之间请求审查）
+- **触发时机**：任务与任务之间
+- **做什么**：
+  - 按计划逐条对照审查
+  - 按严重级别报告问题
+  - **关键问题（Critical）会阻塞继续推进**
+- **目标**：把偏航在小步阶段就截断
+
+#### 7) finishing-a-development-branch（收尾分支）
+- **触发时机**：任务完成后
+- **做什么**：
+  - 最终验证：跑测试、确认整体健康
+  - 给你选择：合并 / 提 PR / 保留 / 丢弃
+  - 清理 worktree
+- **目标**：把“完成”变成可交付、可回滚、可审计的结束动作
+
+---
+
+### 你可以把它理解成：把“好习惯”变成“默认操作系统”
+Superpowers 的关键不是某一个步骤，而是它把**澄清需求 → 设计确认 → 可执行计划 → 小步执行 → TDD → 审查 → 分支收尾**做成自动触发的技能链，让智能体很难走捷径。
+
+---
+
+## 脑洞很大的建议（面向你这种全栈 + MAS 爱好者）
+你可以在 Superpowers 外面再包一层“**双环控制系统**”，把它升级成可量化、可自进化的工程代理流水线：
+
+- **内环**：按 Superpowers 七步跑（保证工程质量与节奏）
+- **外环**：用一个“治理智能体（Governor Agent）”做度量与调参  
+  - 给每个任务打分：偏离计划度、测试增量、复杂度变化、review 返工率、修复是否一次过（verification）
+  - 触发策略：当返工率上升时，自动把任务粒度从 5 分钟收缩到 2 分钟；当测试不稳定时，强制插入“测试基线修复批次”
+  - 最终形成你自己的 **Agent DevOps 仪表盘**：把“AI 写代码靠谱不靠谱”从感受变成数据闭环
+
+如果你愿意，把你常用的环境（Claude Code / Codex / OpenCode、语言栈、CI 平台）告诉我，我可以给你画一张端到端流程图（含 checkpoint 与并行策略），并给出一套你能直接复制到团队里的任务模板与审查清单。
+
+## 脑洞很大的建议（不考虑字数限制版，但先给你一个高能方向）
+鹏哥你是全栈又喜欢 MAS，我建议你把这四条哲学“编译”成一个**可度量的智能体工程宪法（Agent Engineering Constitution）**：
+
+- 给每条哲学定义**硬指标**与**自动惩罚/回滚策略**，比如：  
+  - TDD：若某次提交覆盖率/变更行中测试占比低于阈值 → 自动回滚并要求补红测  
+  - Evidence：任何“完成”必须附带可执行验证命令与产出日志摘要，否则状态不能从 `IN_PROGRESS` 进到 `DONE`  
+  - Complexity：引入“复杂度预算”，超过 cyclomatic complexity 或依赖层级阈值 → 强制进入重构任务队列  
+  - Systematic：调试必须产出根因树（因果链），否则不允许提交修复
+- 然后用多智能体做“**宪法法庭**”：实现智能体写代码，审查智能体只负责判定是否违宪（是否满足四原则），把“工程伦理”变成真正的执行机制。
+
+如果你愿意，我可以进一步按你当前技术栈（比如 TypeScript/Go/Python + GitHub Actions + Claude Code/Codex/OpenCode）把这套“宪法指标”具体化成一份可落地的 CI 规则 + 任务模板 + reviewer checklist。
+
+
+
+## 关键功能：
+- **构思与设计**：代理与用户交互确认需求，细化设计文档。
+- **实施计划**：拆分任务，制定清晰步骤，确保每次开发聚焦具体目标。
+- **子代理开发**：任务由子代理完成，每步有两阶段审查。
+- **测试驱动开发**：严格执行红绿重构循环，确保代码质量。
+- **代码审查**：检查与计划一致性，修复问题后继续执行。
+
+支持三种安装环境：Claude Code、Codex 和 OpenCode，并提供自动更新技能功能。项目使用 MIT 许可，支持用户贡献新技能开发，详细贡献指南可见项目文档。
+
+开发哲学强调简化复杂性、系统化流程、测试优先，以及以证据为基础完成开发。当前为多语言支持，主要使用 Shell 和 JavaScript 编写。
+
+项目主页：29.5k 星，支持通过 GitHub Sponsors 赞助开源开发。
+
+## 参考
+
+* [github](https://github.com/obra/superpowers)