一、Superpowers 的"拖延症"设计
最近持续用了 Superpowers。说实话，它给我留下印象最深的，不是代码生成本身有多快，而是它有个让人"着急"的设计：brainstorming。
啥意思呢？就是当你告诉它"我要做个功能"的时候，它不会立马开始噼里啪啦写代码，而是先问你一堆问题：你到底想解决什么问题？用户是谁？有什么约束条件？
Superpowers 的 README 里开篇第一句就是：
"Superpowers is a complete software development workflow for your coding agents, built on top of a set of composable "skills" and some initial instructions that make sure your agent uses them."
翻译过来就是：看到你要写代码，它不急着动手，而是先退一步，搞清楚你真正想干嘛。
这让我想起以前用 ChatGPT 写代码的经历——往往是我刚描述完需求，它就开始生成代码了。结果写到一半发现："哎呀，我没考虑到这个边界情况"，然后从头再来。效率看着高，实际上在反复折腾。
Superpowers 的做法恰恰相反。它的 workflow 是这样的：
- brainstorming（先聊清楚）
- using-git-worktrees（准备工作区）
- writing-plans（写计划）
- subagent-driven-development（开发）
- test-driven-development（测试）
- requesting-code-review（代码审查）
- finishing-a-development-branch（收尾）
看到没？写代码排在第4位。前面有3个环节都是在做准备。
二、从"聊天"到"出规格"
有人可能会说：这不就是对话体验好一点吗？有什么大不了的？
但 Superpowers 想做的，远不止"聊得开心"。它的目标是：从对话中提炼出 spec（规格）。
README 里有句话很关键：
"Once it's teased a spec out of the conversation, it shows it to you in chunks short enough to actually read and digest."
注意这个动词——tease a spec out（把规格"哄"出来）。它不是随便聊聊，而是要把模糊的想法，转化成清晰的目标、约束和边界。
这让我想到软件工程里的一个老问题：problem framing gap（问题定义鸿沟）。
很多时候，项目失败不是因为程序员不会写代码，而是因为还没搞清楚要做什么，就开始做了。需求模糊、约束不清、验收标准没有，就开始产出代码，结果可想而知。
Superpowers 的 brainstorming，本质上是在填这个鸿沟。它把自然语言的需求，往 spec 的方向推了一步。
三、Kiro：让 spec 落地
如果说 Superpowers 解决了"怎么把需求聊清楚"，那 Kiro 解决的就是"怎么让 spec 变成可执行的计划"。
Kiro 的 slogan 很直接：
"Tame complexity with spec-driven development, advanced steering, and custom agents"
它把从 prompt 到执行的过程，拆成了几步：
- 自然语言 → 结构化 requirements
- Requirements → 架构设计
- 设计 → 离散任务
- 任务 → 代码实现 + hooks 检查
Kiro 的博客里有句话，说得很实在：
"It's fun and feels like magic. But getting it to production requires more."
翻译过来： demo 的时候很爽，但要上生产环境，还差得远呢。
差在哪？Kiro 列了几点：
- 模型做决策时的假设，没有被记录下来
- 你虽然一直在引导 agent，但这些决策没文档
- 需求模糊，没法验证应用是否符合要求
所以 Kiro 的做法是：把 spec 做成产品能力，而不只是讨论的产物。Requirements、design、tasks、hooks，每一步都有明确的交付物。
四、Harness Engineering：让 AI 稳定干活
聊到这里，你可能会觉得：有了 spec，有了计划，应该就能让 AI 好好写代码了吧？
但实际情况是：就算前面都做好了，AI 还是可能在执行阶段翻车。
比如：
- 看不懂 repo 结构，不知道哪份文档是最新的
- 能改代码，但看不到应用运行状态
- 没法稳定验证修复、发现回归问题
- 不遵守架构边界，想怎么改就怎么改
也就是说，spec 解决了"该做什么"，但没解决"怎么稳定地把事情做对"。
OpenAI 最近关于 Harness Engineering 的文章，讨论的就是这个问题。
文章一开头就说：
"Humans steer. Agents execute."
人类掌舵，agent 执行。工程师的主要工作不再是写代码，而是：
- 设计环境（design environments）
- 明确意图（specify intent）
- 建立反馈循环（build feedback loops）
让 agent 能可靠地工作。
文章里有句话特别值得记住：
"From the agent's point of view, anything it can't access in-context while running effectively doesn't exist."
对 agent 来说，运行时看不到的东西，就等于不存在。
这意味着什么？意味着你那些放在脑子里、写在 Slack 里、记在会议纪要里的上下文，对 agent 来说都是空气。只有放在它能读到的地方（比如 docs/ 目录），才算数。
还有一句话也很扎心：
"Building software still demands discipline, but the discipline shows up more in the scaffolding rather than the code."
写软件还是需要纪律的，但纪律越来越多地体现在脚手架（scaffolding）上，而不是代码里。
什么是 scaffolding？
- 文档是否机器可读
- 测试能否自动跑通
- 架构规则有没有 lint 或 hook 兜底
- 代码审查流程是否自动化
这些东西以前属于"最好有"，现在变成了"必须有"。
五、一条链路上的三个环节
把 Superpowers、Kiro 和 Harness Engineering 放在一起看，它们其实是在回答同一条链路上的不同问题：
| 工具/概念 | 解决的问题 | 核心动作 |
|---|---|---|
| Superpowers | 工程入口 | 先聊清楚，别急着写 |
| Kiro | Spec 落地 | 把 spec 变成可执行的计划 |
| Harness Engineering | 长期可靠性 | 让 agent 在复杂环境里稳定工作 |
如果压缩成一句话：
- brainstorming 解决规格形成
- spec-driven workflow 解决执行编排
- harness engineering 解决长期可靠性
六、一个五层框架
如果继续往下抽象，可以用一个五层模型来理解今天的 AI 开发系统：
┌─────────────────────────────────────┐
│ 5. Execution Layer 写代码、跑测试 │
├─────────────────────────────────────┤
│ 4. Harness Layer 环境、约束、反馈 │
├─────────────────────────────────────┤
│ 3. Plan Layer 任务拆解 │
├─────────────────────────────────────┤
│ 2. Spec Layer 需求规格 │
├─────────────────────────────────────┤
│ 1. Intent Layer 原始意图 │
└─────────────────────────────────────┘
Intent Layer：你想解决什么问题（原始意图） Spec Layer：把意图转成工程输入（Superpowers 的 brainstorming 在这里） Plan Layer：把 spec 转成任务序列（Kiro 在这里） Harness Layer：让 agent 可持续工作的系统环境（Harness Engineering 在这里） Execution Layer：写代码、跑测试、调试（大家最熟悉的部分）
一个有趣的现象是：表面上大家还在比拼代码生成能力，但真正拉开差距的，已经越来越是 Spec Layer 和 Harness Layer。
七、回到最初的问题
写到这里，回到标题的问题：brainstorming 之后，还缺什么？
如果只从使用体验看，答案似乎是"更多能力"。但从工程角度看，答案更具体：
缺的不是更强的生成能力，而是一个更完整的工程系统。
这个系统包括：
- 更清晰的 spec（不只是聊出来的，而是能指导执行的）
- 更稳定的 plan（spec 和代码之间的可靠桥接）
- 更可访问的知识（agent 能读到的文档）
- 更可见的工具环境（agent 能用的工具）
- 更明确的架构约束（lint、hook、代码审查）
- 更闭环的自动化验证（测试、CI/CD）
这些都不是新的软件工程原则，但在 AI 参与开发之后，它们的地位明显前移了。
原因不复杂：对人类工程师来说，很多隐含上下文可以靠经验补足；对 agent 来说，凡是看不见、读不到、测不了、约束不了的东西，几乎都不构成稳定前提。
八、不是替代，而是重心转移
所以 AI 编程的真正变化，可能不是"软件工程被替代"，而是"软件工程的重心被重新分配"。
Discipline（纪律）越来越多地落在代码之外的结构上。
当然，这个方向也有张力：
- 过重的流程可能拖慢探索性开发
- 过多的约束可能限制 agent 的自主性
- 对小团队来说，harness 的建设成本不低
不同规模、不同阶段的团队，平衡点并不相同。
但至少有一件事正在变得清楚：
从 prompt -> code 的单跳模式，
到强调规格形成的 spec-driven workflow，
再到强调环境、约束和反馈的 harness engineering。
AI 编程下一阶段真正值得关注的，不再只是模型生成能力，而是工程系统能力。
写在最后
如果你正在用 AI 辅助编程，不妨问问自己：
- 我的需求在交给 AI 之前，有没有先"聊清楚"？
- 我的 spec 是只存在于对话里，还是能指导后续执行？
- 我的 repo 结构、文档、测试，AI 能读懂吗？
- 我有没有建立反馈循环，让 AI 能知道自己做得对不对？
这些问题，可能比"用哪个模型"更重要。
