超级能力的"减速带"：为什么 AI 编程的第一步不是写代码？

"

前言：当 AI 开始"抢"开发者的饭碗

GitHub 上有一个有趣的项目叫 Superpowers，它不是一套 AI 工具，而是一套 AI 开发的"行为准则"。其中最核心的一个 Skill 叫 Brainstorming，它的第一条规则就是：

"You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior."

翻译过来就是：在做任何创造性工作之前——创建功能、构建组件、添加功能或修改行为——你必须使用这个 skill。

更有意思的是它的第二条规则：

"Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it."

不要调用任何实现 skill，不要写任何代码，不要搭建任何项目，也不要采取任何实现行动——直到你展示了设计并且用户批准了它。

这不是在限制 AI 的能力，而是在给 AI 开发装上"刹车"。今天，我们就来分析这个看似"反直觉"的设计哲学。

---

一、"太简单了，不需要设计"——最大的谎言

1.1 简单项目的陷阱

Anti-Pattern: "This Is Too Simple To Need A Design"

这是 Brainstorming Skill 明确列出的反模式：

"Every project goes through this process. A todo list, a single-function utility, a config change — all of them. 'Simple' projects are where unexamined assumptions cause the most wasted work."

翻译：

• 一个待办事项列表
• 一个单功能的工具
• 一个配置变更

这些看起来"简单"的项目，恰恰是未经验证的假设造成最大浪费的地方。

1.2 为什么简单项目更需要设计？

核心原因：简单项目的"简单"往往是错觉。

案例：用户要求"做一个简单的待办事项列表"

看起来很简单，但实际需要回答的问题：

1. 数据模型：

   • 待办事项有哪些字段？（标题、描述、截止日期、优先级、标签...）
   • 是否支持子任务？
   • 是否支持重复任务？

2. 交互逻辑：

   • 如何添加任务？
   • 如何标记完成？
   • 如何删除任务？
   • 是否支持撤销？

3. 状态管理：

   • 数据存储在哪里？（LocalStorage、数据库、文件）
   • 如何同步？
   • 如何处理冲突？

4. 边界情况：

   • 任务标题为空怎么办？
   • 截止日期已过期怎么办？
   • 删除任务是否需要确认？

如果你不问这些问题，直接开始写代码：

• 写到一半发现需求理解错了
• 数据模型设计不合理，需要重构
• 边界情况没考虑到，一堆 bug

Brainstorming Skill 的核心价值：强制你在动手之前，先把这些"隐形问题"显性化。

---

二、AI 编程的"硬门禁"（HARD-GATE）

2.1 什么是硬门禁？

Brainstorming Skill 定义了一个硬门禁：

<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any project, 
or take any implementation action until you have presented a design and the 
user has approved it.
</HARD-GATE>

这不是建议，而是强制规则。

2.2 硬门禁的检查清单

Brainstorming Skill 定义了一个 9 步检查清单：

核心思想：在实现之前，必须通过多重验证。

2.3 为什么需要这么多步骤？

每一步都有它的价值：

1. 探索项目上下文：避免重复造轮子，理解现有架构
2. 一次一个问题：避免信息过载，确保每个问题都被充分思考
3. 2-3 种方案：避免过早陷入单一方案，强迫思考权衡
4. 分段展示：增量验证，避免在大方向错误时浪费细节设计
5. 自我审查：在用户审查之前，先自己检查一遍
6. 用户审查：最终的"绿灯"，确保设计符合预期

---

三、对话式设计：AI 如何"理解"需求

3.1 一次一个问题

Key Principles：

"One question at a time - Don't overwhelm with multiple questions"

为什么？

反例：

AI：这个功能需要支持哪些用户角色？权限如何设计？是否需要多租户？
数据存储选什么数据库？缓存策略是什么？

用户看到 5 个问题，大脑直接死机。

正例：

AI：这个功能需要支持哪些用户角色？
   A. 只有普通用户和管理员
   B. 需要支持多级权限
   C. 不需要权限控制

用户只需要做一个选择，然后继续下一个问题。

3.2 多选题优于开放题

"Multiple choice preferred - Easier to answer than open-ended when possible"

为什么？

• 降低认知负担：选择比从零开始思考容易
• 提高回答质量：选项本身提供了上下文
• 加速对话：避免来回澄清

示例：

❌ 开放题：

AI：你希望这个功能的交互流程是怎样的？

✅ 多选题：

AI：你希望这个功能的交互流程是怎样的？
   A. 向导式（分步引导）
   B. 单页表单（一次性填写）
   C. 自由组合（拖拽式）

3.3 YAGNI 原则

"YAGNI ruthlessly - Remove unnecessary features from all designs"

YAGNI = You Aren't Gonna Need It

核心思想：只设计当前需要的功能，不为"未来可能需要"的功能预留空间。

案例：

• 用户要求：做一个简单的博客
• ❌ 不需要：评论系统、标签系统、搜索功能、SEO 优化、社交分享
• ✅ 需要：文章列表、文章详情、发布文章、编辑文章

未来有需求再说。现在设计的越多，未来重构的成本越高。

---

四、设计文档：从对话到书面

4.1 为什么需要写设计文档？

对话是动态的，文档是静态的。

在对话中，需求可能会不断变化。但当对话结束后，需要有一个稳定的文档来记录最终的设计决策。

4.2 设计文档的内容

Brainstorming Skill 要求设计文档包含：

1. 架构：系统的整体结构
2. 组件：每个组件的职责
3. 数据流：数据如何在系统中流动
4. 错误处理：如何处理异常情况
5. 测试：如何验证系统正确性

4.3 自我审查的四维检查

在用户审查之前，AI 需要先进行自我审查：

1. 占位符扫描（Placeholder scan）

• 是否有 "TBD"、"TODO"？
• 是否有不完整的部分？
• 是否有模糊的需求？

2. 内部一致性（Internal consistency）

• 各个部分是否互相矛盾？
• 架构是否与功能描述匹配？

3. 范围检查（Scope check）

• 是否足够聚焦？
• 是否需要分解成多个子项目？

4. 歧义检查（Ambiguity check）

• 是否有两种不同的理解方式？
• 如果有，选择一种并明确说明

---

五、Visual Companion：何时该用可视化？

5.1 不是所有问题都需要可视化

关键判断标准：

"Would the user understand this better by seeing it than reading it?"

使用浏览器：

• 原型图、线框图
• 布局对比
• 架构图
• 并排视觉设计

使用终端：

• 需求问题
• 概念选择
• 权衡列表
• 文字选项（A/B/C/D）
• 范围决策

5.2 何时提供可视化？

Just-in-Time 原则：

"Do NOT offer it upfront. Wait until a question would genuinely be clearer shown than told."

示例：

❌ 错误时机：

AI：我们要开始设计了。我可以用浏览器给你展示原型图。
User：好的。
AI：第一个问题，这个功能的主要用户是谁？

✅ 正确时机：

AI：这个功能的主要用户是谁？
User：产品经理。
AI：好的，接下来我们需要确定页面的布局方式。
    这部分如果我用原型图展示会更直观，要我在浏览器中打开吗？
User：好的。

---

六、给我们的启示

6.1 AI 编程的核心矛盾

AI 的能力：快速生成代码 AI 的风险：快速生成错误的代码

Brainstorming Skill 的解决方案：

• 不限制 AI 的能力
• 但限制 AI 的"启动条件"
• 强制在实现之前先设计

6.2 从"编码优先"到"设计优先"

传统开发流程：

需求 → 编码 → 测试 → 修复 → 重构

Brainstorming 流程：

需求 → 头脑风暴 → 设计 → 用户审查 → 实现计划 → 编码

核心变化：

• 在"编码"之前插入了多个"减速带"
• 每个"减速带"都是为了避免方向错误

6.3 对 AI 产品设计的启示

1. 能力越强，约束越重要

• AI 可以快速生成代码，所以更需要强制设计流程
• AI 可以快速生成方案，所以更需要强制评估权衡

2. 用户体验 = 交互质量 + 输出质量

• 交互质量：一次一个问题、多选题、即时反馈
• 输出质量：设计文档、自我审查、用户审查

3. 工具 vs 方法论

• Superpowers 不是一套工具，而是一套方法论
• 工具可以加速执行，方法论可以保证方向

---

七、总结：慢即是快

Brainstorming Skill 的核心哲学：

"慢即是快"（Slow is Fast）

在动手之前多花时间设计，看起来"慢"了，但实际上：

• 减少了返工
• 减少了重构
• 减少了 bug
• 最终交付更快

给我们的三点启示：

1. 不要因为"简单"而跳过设计：简单项目往往是隐藏假设最多的地方
2. 对话式设计优于一次性需求：一次一个问题，逐步细化
3. 设计文档是对话的终点：从动态对话到静态文档，才能进入实现阶段

AI 编程的未来：

• 不是 AI 直接写代码
• 而是 AI 先帮你设计，再帮你写代码
• 不是取代开发者，而是增强开发者的设计能力

---

参考资源：

• Superpowers 项目：https://github.com/obra/superpowers
• Brainstorming Skill：https://github.com/obra/superpowers/blob/main/skills/brainstorming/SKILL.md

---

如果你觉得这篇文章有帮助，欢迎点赞、转发，让更多人看到 AI 编程的正确打开方式！