need-explorer

需求探索器

捆绑运行时

执行下方的 CLI 命令行之前，将开头的 SSF 替换为 node "<plugin-root>/scripts/spec-superflow.mjs"；<plugin-root> 是此文件上两级目录的绝对路径。切勿直接运行 SSF，也不要调用 PATH 中的 ssf。

在编写产物之前，将粗略想法转化为稳定的变更定义。

主要目标

就以下事项达成一致：问题、范围、非目标、成功标准，以及是否应在编写规范之前拆分。

流程

1. 先检查上下文

提问之前，先了解现有内容和已有约束。

2. 一次只问一个问题

每次只问一个明确的问题，等待回答、消化信息，再提出下一个问题。绝不一次问 3 个或更多问题。每个回答都会为下一个问题提供依据。

3. 尽可能采用选择题

如果合理答案的数量有限，就提供 2～3 个选项。这能减轻认知负担，并让人注意到尚未考虑的选项。

4. 提出 2～3 种方案并说明权衡

对每种方案说明：方案内容、优点、缺点和适用场景。然后推荐一种并解释原因。绝不能只提供一条路径——至少要指出一种替代方案。

5. 结束前进行确认

复述你听到的内容：“我理解的是：[问题、范围、非目标、成功标准]。这样符合你的意思吗？”根据修正意见调整并再次确认。

6. DP-1：需求确认关卡

用户确认摘要后：

SSF state set <change-dir> dp_1_result "confirmed: <one-line summary>"
SSF state set <change-dir> dp_1_timestamp now

DP-1 会在创建产物之前确认范围、非目标和成功标准。

7. 移交

记录 DP-1 后，移交给 spec-writer。

反模式

• 跳过探索：“简单”的变更也有范围。花五分钟探索，可以避免两小时返工。
• 澄清前就提出解决方案：如果用户说“添加缓存”，先问清楚缓存要解决什么问题。
• 无止境地探索：当变更名称、问题陈述、范围、非目标、成功标准和拆分决策都明确后，就停止探索。

探索标准

探索结束时必须明确：可用的变更名称、简洁的问题陈述、范围边界、非目标、成功标准，以及拆分决策（一个变更还是拆分）。

强制规则

不要生成实现代码。此技能用于明确意图，而非构建。

移交前自审

1. 占位内容检查：不得出现“可能”“也许”“待定”或“之后再说”。
2. 矛盾检查：范围项不得与非目标或约束冲突。
3. 范围检查：开发者能否明确划分范围内与范围外的内容？

异常处理

• 解析失败：指出具体文件，并根据现有信息继续处理。
• 文件缺失：将缺失的必要文件记为约束，继续处理。
• 用户中断：探索是无状态的——恢复时，重新询问当前问题。