Superpowers 测试驱动开发：解决AI编程商业应用交付问题
Superpowers 测试驱动开发：解决AI编程商业应用交付问题
AI 编程遇到的问题
Vibe Coding只配做Demo，碰复杂商业软件必乱成一锅粥!
更触目惊心的是，5600个AI生成应用，扒出2000+安全漏洞、400+暴露密钥，医疗记录、银行账号、家庭住址随手就能扒，10%的应用裸奔式泄露用户数据，无编程基础的创作者，连最基础的安全防护都不懂!
这其实是因为使用顺序导致的，常规 AI 编程使用顺序：
- 输入提示词
- 等待AI输出结果
- 人工检查AI输出结果
- 人工反复修改 AI 的输出错误
虽然 AI 编程可以用，但是更累了，耗时去调/纠正，过程是很痛苦的！
就像一个人干了活，说干好了，然后不知道干了什么，要我们自己去验收纠正，这个过程很痛苦！
而且这个过程很难规模化，每个任务验收标准都不同，重复做起来特别心累！
说不能做商业应用的，大概率是没有做完验收这个过程，然后崩溃了！
整个coding过程，是黑箱，即使有记录，但是上下文有限
到验收的时候，各个代码都在不同的文件中，上下文挤不下，一旦上下文压缩了，就会漏细节。
所以，还要拆块验收。
测试驱动开发的AI编程 vs 传统AI编程
- 传统AI编程的典型问题
- 黑箱生成：直接输出最终代码，缺乏验证闭环。
- 技术债累积：生成代码可读性差、难以维护（如嵌套回调地狱）。
- 被动修正：依赖用户发现错误后反馈。
# 传统AI生成（未经验证）
def calculate_discount(price):
return price * 0.9 # 硬编码折扣，未处理负数等边界
- 测试驱动开发 AI编程方法论
核心原则：
- 测试驱动开发：先写测试，再生成代码，最后重构。
- 持续重构：持续分析优化结构。
| 维度 | 测试驱动开发的AI编程 | 传统AI编程 |
|---|---|---|
| 输入要求 | 需提供测试用例或验收标准 | 仅需自然语言描述 |
| 生成过程 | 迭代生成（测试→代码→重构） | 单次生成完整代码 |
| 代码质量 | 高内聚低耦合，通过测试覆盖 | 可能存在隐藏缺陷 |
| 反馈机制 | 自动化测试即时反馈 | 依赖人工审查 |
| 典型工具 | PyTest + SonarQube + GitHub Copilot | 纯LLM（如ChatGPT） |
测试驱动开发 AI编程 的本质进化：
- 从“结果正确”到“过程可控”：通过测试和重构形成质量闭环。
- 从“单次博弈”到“持续演进”：代码随测试用例和需求变更迭代优化。
github链接：https://github.com/obra/superpowers
Superpowers 执行纪律层：落地执行，怎么做好（给执行过程加纪律，不许边干边乱改）
商业交付还有一个老问题：很多失败不是因为方向错，而是因为执行乱。
计划没拆清，测试没先写，代码改完没人审，最后还匆匆宣布完成。
所以你发明第三层：执行纪律层。
superpowers 在这里像工地监理。
它不重新定义产品边界，也不替你管理变化档案，而是盯着执行过程本身。
缺少 superpowers，就等于缺少对执行过程的强制纪律。
没有人持续盯着“任务是否拆细、测试是否先写、审查是否按计划进行、阶段是否规范收尾”。
| 缺失点 | 直接后果 |
|---|---|
| 没有细计划约束 | 任务容易一口气做太大，偏离原设计 |
| 没有测试驱动开发纪律 | 先写实现、后补验证，回归风险上升 |
| 没有中途 review | 偏差积累到最后才暴露 |
| 没有阶段收尾机制 | 代码看似完成，实际缺验证与整理 |
它强调的不是“想到了就做”，而是：
- 先 brainstorm（头脑风暴），把意图说清。
- 再 writing-plans（编写计划），把任务拆细。
- 实施时走 TDD（测试驱动开发），不许先写一堆没验证的代码。
- 每个关键步骤后做 code review（代码审查），对照原计划审查偏差。
- 最后再决定怎么收尾、归并、保留还是丢弃分支。
这一步的本质，是把 “做事” 变成 “按规则做事”。
计划和纪律都有了，但 AI 还是可能在没真正完成时就宣布完成。
子解法：Superpowers（执行纪律层）
- 对应特征：即使知道“做什么”，AI 在“怎么做”的细节上依然容易出错（幻觉、不测试、Debug 低效）。
- 为什么需要：不处理会导致代码可运行但充满隐藏 Bug，或者 Debug 过程变成和 AI 的冗长拉锯战。
- 具体做法：
- 苏格拉底需求澄清：在编码前强制对齐隐含细节。
- 强制测试驱动开发 TDD：必须先写测试，不写测试就视为代码无效（甚至删除代码）。
- 子 Agent 并行开发 + 双阶段 Code Review：模拟人类团队的高标准评审。
- 4 阶段根因调试：用系统化方法论替代随机尝试。
- 预期效果：提升代码健壮性，缩短调试时间，产出具有生产级质量的代码。
- 可能风险：对开发者的工程素养要求较高，学习曲线陡峭。
很多团队有了 spec（规格）和 plan（计划）以后，就以为后面只剩写代码。
可实际翻车往往发生在执行层。
- 第一，AI 会直接写代码，不先拆成小任务。
- 第二，它没看到失败测试就开始实现。
- 第三，遇到 bug 它会先打补丁，而不是先找根因。
- 第四，最危险的是，它经常没跑完验证就提前说 done。
Superpowers（超级能力）的主线很清楚。
- 先用 writing-plans（编写计划）把实现计划压到 2 到 5 分钟的小动作，每一步都写精确路径、代码和验证命令。
- 真正开工时，再进入 executing-plans（执行计划）或 subagent-driven-development（子代理驱动开发），严格按计划执行。
- 执行过程中，test-driven-development（测试驱动开发）要求先看见失败测试，再写实现。
- 最后用 systematic-debugging（系统性调试）和 verification-before-completion（完成前验证）把修 bug（缺陷/漏洞）和收尾也收紧。
这里要特别强调，它不是给 AI 多几个技巧，而是让 AI 在任何时刻都先进入正确的纪律模式。
也就是说，它不是增强灵感，而是在降低失控自由度。
使用流程
第一步：看实现计划文件
Superpowers（超级能力）对计划的要求非常苛刻，它默认执行者几乎没有上下文，而且还喜欢过度设计。
所以计划里不是写"实现导出功能"，而是要写清楚改哪些文件、先写什么 failing test（失败测试）、跑什么命令确认它失败、再写多少最小代码、最后再跑什么命令确认它通过。
计划写得越具体，AI 乱发挥的空间就越小
第二步：怎么执行计划，而不是把计划当建议
到了真正开工这一步，Superpowers（超级能力）有两个选择。
一个是 executing-plans（执行计划），在当前会话按计划逐步执行。
另一个是 subagent-driven-development（子代理驱动开发），给每个任务派新 subagent（子代理），并在任务之间插入评审。
两种方式都不是"看着差不多就开始"，而是先读计划、先批判性审计划，没有问题才继续。
更重要的是，Superpowers（超级能力）把审查顺序也规定了。
先看 spec compliance（规格合规/一致性），也就是实现有没有偏离目标；再看 code quality（代码质量），也就是代码本身有没有问题。
这个顺序能避免一种常见失误，就是代码写得挺漂亮，但其实做偏了。
为什么 TDD（测试驱动开发）必须的好习惯
Superpowers（超级能力）最强硬的一条纪律就是 TDD（测试驱动开发）。
它不是建议你尽量先写测试，而是明确说，没看到失败测试就不能写生产代码。
如果你先写了代码，再想补测试，它的态度不是"补一下"，而是删掉重来。
为什么这么严格？
因为如果测试一上来就通过，你根本不知道它是不是测到了正确行为。
对于这个订单导出案例来说，先写失败测试，等于先把"字段顺序稳定"、“当前筛选条件生效”、"空值处理正确"这些行为钉死，再允许实现代码出现。
第四步：怎么处理 bug（缺陷/漏洞）和收尾
Superpowers（超级能力）对这两步都加了硬门槛。
比如这个案例里的调试记录，展示的是导出的 customer_name（客户名称）列为空时，不能直接猜是前端问题，而是要先查根因，沿着查询、映射、序列化一层层看数据在哪一层断了。
等修完以后，也不能直接说"已经好了"。
verification-before-completion（完成前验证）要求你先确定什么命令能证明这件事成立，再立刻运行完整命令，读完整输出，看退出码和失败数，只有 fresh evidence（新鲜证据）支持，才允许你说完成。
Superpowers（超级能力）不替你决定功能目标，也不替你写治理原则，它做的是把实现过程里的偷步空间大幅压缩。
这样 AI 就不容易跳过计划、跳过测试、跳过根因分析，也不容易在没有证据时提前宣布 done。
因为以后不只是订单导出，像批量导入、定时报表、第三方同步、通知发送这类功能，只要进入实现阶段，都应该先问一句，我有没有把执行纪律先立起来。
更多推荐
9
0- 0
已为社区贡献1条内容
所有评论(0)