第4篇：中级pian——三件套skill组合：1+1+1>3
让Vibe Coding从“野路子”变“正规军”
4.1 为什么需要三者组合？
单独使用任何一个，都只能解决单点问题：
| 单独使用 | 能解决 | 不能解决 |
|---|---|---|
| 只有Karpathy | AI不乱猜、不乱写 | 流程规范、变更追溯 |
| 只有Superpowers | 流程门禁 | AI行为纪律、变更记录 |
| 只有OpenSpec | 变更追溯 | AI行为、流程门禁 |
三者组合，形成完整闭环：
text
Karpathy（行为纪律）→ 约束AI怎么做
Superpowers（流程门禁）→ 规定AI怎么推进
OpenSpec（变更追溯）→ 记录AI做了什么
4.2 组合使用的收益
收益1：AI行为可预测
以前：遇到模糊需求直接猜 → 跑偏
现在：Karpathy强制反问 → 澄清后再行动
收益2：代码质量可控
以前：500行抽象类，难以维护
现在：Karpathy原则2限制≤50行 + TDD强制测试
收益3：变更历史可追溯
以前：改了什么都记不清
现在：OpenSpec归档，完整的历史档案
收益4：审查自动化
以前：人工审查AI代码，效率低
现在：Superpowers自检Karpathy原则，自动返工
收益5：团队协作友好
以前：每个人配置不同，AI行为不一致
现在：规则和技能随项目共享，团队统一
4.3 完整工作流
从需求到代码的完整流程：
| 步骤 | 操作 | 涉及规范 | 产出 |
|---|---|---|---|
| 1 | 输入模糊需求 | - | 一句话需求 |
| 2 | Karpathy自动反问 | Karpathy原则1 | 【理解】【假设】【待确认】 |
| 3 | 用户回答 | - | 澄清后需求 |
| 4 | 调用brainstorming | Superpowers | 技术方案对比 |
| 5 | 用户选择方案 | - | 确定技术选型 |
| 6 | /opsx:new | OpenSpec | proposal + tasks + specs |
| 7 | /opsx:explore（可选） | OpenSpec | 起草spec草案 |
| 8 | /opsx:apply | OpenSpec启动 | - |
| 9 | 每个任务自动5阶段 | Karpathy+Superpowers | 高质量代码 |
| 10 | /opsx:archive | OpenSpec | 变更归档 |
4.4 核心：改造过的5阶段apply
在/opsx:apply执行时，每个任务自动经历：
text
Phase 0: 任务宣布
Phase 1: Karpathy - 编码前思考
输出【理解】【假设】【边界】【待确认】
有【待确认】则暂停等待
Phase 2: Superpowers TDD - RED
写失败的测试 → 运行确认失败
Phase 3: Superpowers - GREEN
写最少代码让测试通过 → ≤50行
Phase 4: Superpowers - 代码审查
检查Karpathy4条原则
不通过则返回Phase 3
Phase 5: OpenSpec - 标记完成
更新tasks.md，继续下一个任务
4.5 今天对话中的干货
三者的边界
问：Karpathy和Superpowers不都包含“写测试”吗？重叠了？
答：Karpathy的原则4说“目标驱动——必须验证”，但没规定怎么验证。Superpowers的TDD给出了具体方法：RED→GREEN。Karpathy定义What（要验证），Superpowers定义How（怎么验证）。
为什么是OpenSpec而不是其他？
问：GitHub Issues也能记录变更，为什么要用OpenSpec？
答：OpenSpec的区别在于规范与代码同仓、变更即代码。openspec/目录纳入版本控制，每次PR都包含对应的spec变更。Issues是外部系统，与代码仓库分离。
核心洞见
“Karpathy管人（AI），Superpowers管流程，OpenSpec管文档。——三者各管一摊，互不冲突，形成完整闭环。”
