江湖小栈

Do Better

0%

Superpowers 与 Brainstorm：AI 结对开发从写代码走向共创方案

发表于 分类于 Hot°C：
本文字数： 1.1k 阅读时长 ≈ 1 分钟
讨论 AI 结对开发如何从直接生成代码转向需求澄清、方案共创、任务拆解和验证闭环。

很多 AI 失败并不是因为不会写代码，而是因为太快开始写代码。Brainstorm 和 Superpowers 一类的工作方法，提醒我们先把问题想清楚，再让 Agent 动手。

先共创问题，再生成实现

Brainstorm 的核心是通过连续提问澄清目标、用户、边界和约束；Superpowers 强调把这种方法固化为可执行的开发流程。它们把“给我写一个页面”拆成“为什么做、谁使用、已有规则是什么、怎样算完成”。

1
需求 → 澄清 → 方案候选 → 选择 → 计划 → 实现 → 验证 → 复盘

一个前端需求的提问清单

  • 页面属于哪个门户、菜单和权限层级？
  • URL 是否必须与后端菜单 Code 完全一致？
  • 大屏、小屏和无权限状态分别怎样展示？
  • 是否需要事件发布、路由参数和弹窗能力？
  • 现有设计系统中有哪些组件可以复用？
  • 验收需要哪些命令、截图和边界场景？

让方案先于代码

Agent 可以先输出候选方案和取舍，再由开发者选择。这样能够把不可逆的架构决定留在人的控制范围内：

1
2
3
4
5
6
type Proposal = {
  decision: string;
  alternatives: string[];
  risks: string[];
  acceptance: string[];
};

结对开发的边界

AI 适合快速搜索、生成样例、补充测试和发现遗漏；产品语义、权限边界、安全风险和最终取舍仍然需要人负责。好的结对开发不是让 AI 代替判断，而是让判断过程更透明。

如何在项目中落地

可以把每一个开发任务放进独立的工作目录或任务文档中，并固定留下四类文件：

1
2
3
4
5
tasks/2026-04-report/
├── brainstorm.md  # 问题、用户、候选方案和取舍
├── spec.md        # 选定方案、状态、约束和验收
├── plan.md        # 可执行的小步骤
└── review.md      # 变更、检查结果和遗留风险

开始时不要直接让 Agent 修改代码，而是先提出目标、现状、约束和至少一个反例。Brainstorm 阶段可以用几个问题筛掉歧义：是否影响已有路由？小屏是否有不同交互？没有数据、无权限、接口超时怎么办？哪些内容必须保留旧行为？

确认方案后再进入 Plan，把任务拆成可以单独验证的步骤。例如先新增类型和测试，再实现组件，再接菜单和路由，最后补截图和文档。每一步完成后都运行局部检查，避免最后才发现方案从一开始就不成立。

适合哪些任务

Superpowers 式流程特别适合跨文件改造、复杂表格、权限菜单和发布流程。对于修正一个拼写错误则不必引入完整仪式；流程应该根据风险调整，而不是把所有任务都变重。

小结

当 AI 从“代码生成器”变成“开发伙伴”，最重要的升级不是更长的 Prompt，而是一套先思考、再执行、可验证、可复盘的协作纪律。

相关推荐
bulb