Superpowers搞不定的需求分析，OpenSpec也没管——我造了个自定义skill

像"退款后累计消费要不要扣减""折扣精度按分还是按元""并发支付时怎么保证一致性"这类问题的发现，更多依赖AI自身的理解能力，用头脑风暴处理这种需求，感觉就像拿着一份菜谱问厨师"你想做什么菜"——菜谱都有了，你该做的是检查食材齐不齐、步骤有没有遗漏，而不是重新设计菜单。需求文档里写出来的部分没问题，但没写出来的那些——交互细节、边界条件、异常处理、数据模型——才是真正坑你的东西。你的痛点是哪个，就

wind瑞

474人浏览 · 2026-04-22 08:08:14

wind瑞 · 2026-04-22 08:08:14 发布

你肯定经历过这种场景：产品经理发来一份需求文档，你仔细看了一遍，觉得逻辑清晰，没什么问题，于是开工。写到第三天，突然发现一个业务规则没定义——"退款之后会员等级要不要降？"

你去问产品，产品说"这个你看着办"。你看着办完上线了，产品说"不对啊，退款不应该降级的"。

这种事情发生得多了，你就会发现一个规律：产品给的需求永远少一半。不是产品不负责，是很多细节他们自己也没想到。需求文档里写出来的部分没问题，但没写出来的那些——交互细节、边界条件、异常处理、数据模型——才是真正坑你的东西。

之前我一直用Superpowers的头脑风暴技能来处理需求，但后来发现它并不适合所有场景。摸索了一阵之后，我给自己造了一个专门对付这种"半成品需求"的AI技能，今天把整个思路和踩过的坑分享一下。

Superpowers的头脑风暴很强大，但处理不了半成品需求

用Claude Code做开发的人大概都知道Superpowers——一套AI编程技能体系，从头脑风暴到写计划到执行代码，覆盖了开发的完整流程。其中有个brainstorming技能，专门处理从0到1的需求探索。你有一个模糊的想法，比如"我想做一个社区动态功能"，它帮你把想法变成可执行的设计方案。这个能力很强，我用了很多次。

但有一种场景它不合适：产品已经给了需求文档。不是模糊的想法，是有具体功能描述、有交互流程、有业务规则的素材。但这种素材又不够完整——逻辑有断点、边界没说清楚、异常场景直接省略了。

我管这种需求叫"半成品"：从0到1的探索产品已经做完了，但还没到可以写代码的程度，缺失太多。准确说，它处于0.5的位置，差的是系统性补全。

用头脑风暴处理这种需求，感觉就像拿着一份菜谱问厨师"你想做什么菜"——菜谱都有了，你该做的是检查食材齐不齐、步骤有没有遗漏，而不是重新设计菜单。头脑风暴处理的是"你想做什么"，而我的需求是"产品说的这些到底缺了什么"。

我造了一个专门找需求隐藏问题的AI技能

这个技能叫req-structurer，定位很明确：需求是输入，不是创作对象。它不发明新功能，只找出缺失的部分。区分事实和推断，不知道的就标"待确认"，不编造内容。

核心武器是一个六维度检查清单，不管需求是什么类型，逐项扫描：

交互完整性
用户操作路径有没有断点；空状态和加载状态有没有描述；操作反馈是否完整；
边界与异常
数据边界、并发冲突、权限控制、错误处理；
业务规则
排序规则、状态流转、计算规则、限制条件；
数据模型
字段定义、关联关系、初始数据；
非功能性需求
性能、兼容性、安全要求；
上下文衔接
上下游依赖、导航入口、术语一致性。

工作流分四个阶段。先探测项目的技术栈和代码模式——看pom.xml、Spring Boot配置、已有的数据库表结构和实体类。然后只提取不推断，把需求里已有的信息梳理出来。接着按六维度系统性扫描，找出缺失和模糊之处，分成两层呈现——需要你确认的关键问题（控制在5-8个）和自动采纳的默认值。最后生成结构化规格文档，AI推断的部分用注释标注，和用户确认的部分严格区分。

说白了就一件事：系统性地保证需求没有遗漏。不依赖灵感和经验，靠检查清单逐项过。

一份会员等级需求藏着8个坑，六维度扫描全挖出来了

拿一个后端常见的需求举例。产品发来的需求是这样的：

用户注册后自动成为普通会员，根据消费金额累计升级。4个等级：普通、银卡、金卡、钻石。升级门槛分别是0元、500元、2000元、5000元。不同等级有不同折扣：银卡9.8折，金卡9.5折，钻石9折。管理员可以手动调整等级和冻结权益。连续12个月无消费自动降级。

看起来挺清楚的，对吧？如果你直接拿着这个需求开始建表写代码，大概率不会觉得有什么问题。但用req-structurer过一遍六维度扫描，出来的结果是这样的：

交互完整性维度发现三个关键问题："累计消费金额"是历史总消费还是滚动周期内消费？退款后累计消费要不要扣减？扣减后等级降不降？这三个问题直接影响核心逻辑，但需求里一个字没提。

边界与异常维度发现两个：折扣金额精度怎么处理——199元×9.5折=189.05元，按分算还是按元算？两笔订单几乎同时支付成功，累计消费的累加怎么保证一致性？

业务规则维度发现两个：普通会员有折扣吗？折扣适用所有商品还是排除特价商品？数据模型维度发现一个：4个等级的配置是硬编码还是数据表？

维度	发现的问题	数量
交互完整性	累计消费定义、退款影响、手动调整后逻辑	3
边界与异常	折扣精度、并发一致性	2
业务规则	普通会员折扣、折扣适用范围	2
数据模型	等级配置硬编码vs数据表	1
非功能性+上下文	无关键问题，全部采纳默认值	0

一共扫出8个关键问题，19个自动采纳的默认值。

发现需求里的坑不能靠灵感，得靠检查清单。不系统性地扫一遍，这些坑你就会在开发过程中一个一个踩到。每个坑的代价是：停下来→找产品确认→改代码→测试。一个小坑浪费半天，一个大坑浪费两三天。而六维度扫描把这半天到两三天的工作量压缩到了几分钟的交互确认里。

和头脑风暴不是替代关系，是一条pipeline的两个入口

req-structurer和brainstorming不是替代关系，是分工。brainstorming处理"从0到1"——你有一个模糊想法，需要探索和设计。req-structurer处理"从0.5到1"——你已经有需求素材，需要补全和结构化。

分流判断很简单：输入是一个模糊想法或意图，走brainstorming；输入包含具体的功能描述、页面说明、交互流程，走req-structurer。

两条路径最终汇入同一条pipeline。不管需求从哪条路径进来，输出的spec格式一致，后续的writing-plans和executing-plans都可以直接消费，不需要额外适配。

OpenSpec也能做需求分析？研究完它的设计之后，我觉得深度不一样

聊到这里可能有人会问：OpenSpec不也是干这个的吗？

OpenSpec是Fission AI做的一个开源项目，核心定位是Spec-Driven Development——先写spec再写代码。它有一套完整的工作流：/opsx:propose创建提案，自动生成proposal.md、specs目录、design.md、tasks.md，然后/opsx:apply执行实现，最后/opsx:archive归档。还有一个可视化的Dashboard来管理所有spec。在GitHub上热度很高，社区也很活跃。

我仔细读了OpenSpec的文档和设计理念之后，发现它的思路和我做req-structurer的出发点不同。理论上，把会员等级需求喂给/opsx:propose，它也能生成一堆结构化文件。但从设计上看，两者的侧重点有明显差异。

但仔细看就会发现区别。OpenSpec的spec格式长这样：

### 需求：会员折扣
系统必须根据会员等级应用对应的折扣。

#### 场景：金卡会员下单
- 假设 一个金卡会员，累计消费2000元
- 当 该用户提交一笔订单
- 则 系统必须应用5%的折扣

这是行为验证格式——Given/When/Then场景描述。适合验证系统行为是否正确，但从它的设计来看，没有内置类似六维度这样的显式检查清单。像"退款后累计消费要不要扣减""折扣精度按分还是按元""并发支付时怎么保证一致性"这类问题的发现，更多依赖AI自身的理解能力，缺乏系统性的覆盖保证。当然，如果用的模型足够强，AI可能也会发现不少问题——但可能发现和保证发现是两回事。

	req-structurer	OpenSpec
核心机制	六维度检查清单，逐项扫描	AI理解后生成artifacts
spec格式	业务建模（数据结构+业务规则+异常处理）	行为验证（Given/When/Then）
用户参与	过程中交互确认，逐项过	生成后review，整体看
生命周期	一次性，交付即结束	持续演化，propose→archive循环
解决的核心问题	需求有坑没发现	spec越来越多管不过来

理解能力不稳定，今天想到了明天可能漏了；检查清单每次都一样，不会因为AI的状态而改变覆盖度。这是我在设计req-structurer时的核心出发点——用机制补足AI理解力的不确定性。

为什么不把它们结合起来？分析完设计理念，我觉得不太合适

有人可能会想：能不能结合一下，用req-structurer分析需求，用OpenSpec管理spec的生命周期？听起来很合理。我没有实际做过这个集成，但从两者的设计理念来分析，硬凑在一起会有几个明显的摩擦点。

第一，spec的定义完全不同。req-structurer的spec是业务建模格式——数据结构、字段定义、业务规则、异常处理。OpenSpec的spec是行为验证格式——Given/When/Then场景。同一个需求两种描述方式，硬转换会丢信息或者加噪音。

第二，两条完整的pipeline互相竞争。req-structurer → writing-plans → executing-plans是一条完整的pipeline。OpenSpec的/opsx:propose → /opsx:apply是另一条完整的pipeline。两条pipeline都从需求走到代码，串起来不是互补，是重复。

第三，spec归属冲突。req-structurer输出到docs/superpowers/specs/，OpenSpec管理在openspec/specs/。两个目录都说自己是source of truth，到底听谁的？这恰恰是需求管理中要避免的情况。

我的判断是：它们解决的是同一个领域的不同问题，硬整合的收益不大。你的痛点是哪个，就用哪个。不是所有好工具都得塞到一起用。不过这是基于设计分析得出的结论，如果有人真的跑通了两者的集成流程，欢迎告诉我，我很想了解实际效果。

到底该用哪个？一个简单的判断标准

总结一下我这段时间的实际使用经验：

需求是一个模糊想法——比如"我想做一个XX功能"，连功能范围都不确定。这时候用brainstorming，它的强项是从零开始探索需求边界，帮你想清楚到底要做什么。

需求有素材但不完整——产品给了需求文档或原型描述，有具体功能点，但细节有缺失、边界条件模糊。这是最常见的情况，用req-structurer，六维度扫描把缺的补上，输出结构化spec，直接对接后续的开发流程。

前两种场景在我的日常工作里占了90%以上。brainstorming和req-structurer汇入同一条pipeline，输出统一的spec格式，后续的writing-plans和executing-plans直接消费，不需要额外适配。

需求已经清晰，但项目在持续迭代中spec越来越多——功能模块几十个，AI助手每次都丢上下文，spec文件散落各处管不过来。这种情况OpenSpec的propose→apply→archive循环和可视化Dashboard能帮上忙。注意，这个判断基于我对OpenSpec文档的分析，不是实际项目中的使用经验。后续将会研究OpenSpec，在项目中验证它的工作流程特性和项目落地实践。