ce-brainstorm

思考某件事应该变成什么样子——一次一个问题地协作——然后写一份大小合适的需求文档。

ce-brainstorm 是定义技能。它是一个有思想的合作伙伴，一次提出一个问题，根据指定的间隙透镜对您的前提进行压力测试，在推荐一种方法之前探索 2-3 种具体方法，并生成一份大小合适的需求文档，该文档的强度足以使规划永远不必发明产品行为。

它在软件功能、完全非软件主题（活动策划、业务决策、个人项目框架、旅行行程、命名简介）以及介于两者之间的任何地方都同样运行良好。同样的一次只问一个问题的纪律；相同大小的模板；在任何工件落地之前都会有相同的综合摘要。

这是复合工程构思链的中间步骤：

/ce-ideate         /ce-brainstorm      /ce-plan             /ce-work
"What's worth      "What does this     "What's needed       "Build it."
 exploring?"        need to be?"        to accomplish
                                        this?"

它也是最常见的独立切入点——对于任何问题不是“我该怎么做？”的功能、决策或项目。但“我到底在做什么？它的形状正确吗？”

TL;DR

＃＃ 问题

从一个模糊的想法直接到实施会产生：

• 代码（或工作）解决了错误的问题，因为没有人对前提进行压力测试
• 范围蔓延，因为界限从未明确
• 每次有人接触产品决策时都会重新提起诉讼的计划
• 需求文档要么是没有人更新的过于仪式化的 PRD，要么是计划必须通过猜测来填写的一行简报

典型的人工智能“让我们集思广益”也存在形状问题：它在一条消息中提出五个问题；你回答两个，剩下的就迷路了。它立即选择一种方法，而不是提出替代方案。它将实施细节纳入产品讨论中。输出是对话，而不是可切换的工件。

解决方案

ce-brainstorm 运行一个结构化但对话的流程，最终形成一个持久的工件：

• 每轮一个问题，即使子问题感觉相关
• 规模合适的仪式 — 轻量级/标准/深度/深度产品层
• 命名间隙透镜 在生成方法之前强制要求场地严格
• 背景接地侦察员在您回答开场问题时收集廉价模型的逐字回购证据
• 2-3 个具体方法 进行权衡，然后提出明确的建议
• 综合摘要作为文档落地前纠正范围的最后机会
• 新鲜上下文声明验证 在文档落地之前检查其回购声明
• 大小合适的需求文档，具有流入规划的稳定标识符 (R/A/F/AE)

是什么让它如此新颖

1.一次一个问题，先阻塞工具

在一条消息中堆叠三个问题会产生稀释的答案。 ce-brainstorm 每回合都会问一个问题，并且当存在自然选择时，默认使用平台的带有单选选项的阻塞问题工具。精心挑选的选项可以构建答案而不对其进行限制（自由文本后备始终可用）。

2. 等级分级尺度仪式到工作

并非每次头脑风暴都是一样的。轻量级涵盖了小而明确、模糊性较低的想法。标准通过一些决定来处理正常功能。 Deep 为横切工作添加了系统性移动探针。深层产品还需要建立产品形态——参与者、核心成果、定位、耐用性——而不是继承它。仪式与工作相适应，而不是与之相反。

3. 产品压力测试 — 命名为间隙镜片

在生成方法之前，该技能会扫描用户的空缺，以找出严格的差距。每个间隙都有一个名称并探讨它所捕获的混乱类型：

• 证据 - “用户想要 X”，但没有可观察到的行为支持它
• 具体性 — 抽象地描述受益人；设计会默默地创造他们是谁
• 反事实 - 无法了解用户今天做了什么，或者如果没有发货会发生什么变化
• 附件 - 特定的解决方案形状被视为正在构建的东西
• 耐用性 （仅限深度产品） — 价值取决于可能发生变化的当前世界状态

这些探测器以散文而非菜单的形式启动——一个 4 选项菜单表明哪些类型的证据值得考虑，并让用户选择而不是生成。散文迫使人们进行真实的观察。

4. 需要以不明显的角度进行探索

第 2 阶段提出了 2-3 个具体方法，其中至少有一个不明显的角度——反演、约束消除或跨域类比。方法是按机制/产品形状粒度而不是架构提出的。 （基于有意浅薄的研究而做出的架构决策往往会预先让您做出错误的选择；这些选择属于 ce-plan。）方法在推荐之前显示，以便用户看到替代方案而无需锚定。

5.综合总结——最后的廉价修正时刻

在编写文档之前，ce-brainstorm 会发出一个范围综合，其形状类似于两个产品协作者在编写 PRD 之前会确认的内容。它显示了正在构建的内容、对话产生的关键权衡、已推迟的内容以及用户应该权衡的任何真正的分叉。每个部分仅在有话要说时才会呈现——没有空桶用于仪式。当上游对话短路时（阶段 0.2 快速路径，要求已经明确，不问任何问题），范围界定综合会压缩为具有回合结束中断窗口的单个前瞻性句子。

6. 流向下游的稳定标识符

需求文档包含计划馈送标识符——R-ID（需求）、A-ID（参与者）、F-ID（关键流程）、AE-ID（验收示例）。 ce-plan 使用这些并跟踪每个实现单元和测试场景回溯到它们。来源范围边界（特别是“在该产品的身份之外”）流过不变。

7. 非软件领域的通用头脑风暴

构建软件功能？标准流量。给产品起个名字？选择假期？决定职业变动？ ce-brainstorm 路由至与领域无关的促进者，该促进者保留一次只回答一个问题的规则和适当大小的输出。

8. 默认情况下，实现不包含在需求文档中

需求描述了从用户的角度期望的什么行为。它们不描述库、模式、端点、文件布局或代码结构——除非头脑风暴本身是关于技术或架构决策的。这使规划的工作保持干净：发明如何，而不是什么。

9. 在你的思考时间内扎根和验证

在标准和深度头脑风暴中，当你回答第一个问题时，会在后台派遣一个廉价的提取层侦察员。它编写了一份基础档案（带有 file:line 指针的逐字引用）来清理存储并返回一个简短的要点，因此对话保持简洁，同时证据仍可按需提供。在编写需求文档之前，一个新的上下文验证器（从未见过对话的中间层模型）会根据代码库检查文档的回购声明（缺席声明、文件引用），并在您查看综合确认时运行。被驳斥的主张在文件落地前得到纠正；无法验证的假设变成了明确的假设。档案路径将交给 ce-plan，因此计划从经过验证的报价开始，而不是重新扫描。在没有每个代理模型选择的平台上，两者都在具有相同读取预算的继承模型上运行；由于根本没有子代理支持，该技能只能退回到内联扫描和验证。

简单示例

你从一个模糊的功能想法开始——“我想为用户添加一种暂停通知的方法。” ce-brainstorm 读取项目的约束文件，将工作分类为标准范围，并在您回答第一个问题时发送廉价的后台侦察员来收集回购证据。

压力测试检测特异性差距（这些“用户”是谁？）和附件差距（“暂停”已经是特定的解决方案形状）。它将两者作为散文进行探讨，一次一篇。您列出了实际的痛苦（您的支持团队在凌晨 3 点收到非紧急事务的通知），并描述了可以解决该问题的最小版本。

三种方法浮出水面——使用 TTL 的按通知类型静音、全局请勿打扰时间表、根据规则而不是频道静音——并进行权衡和建议。综合摘要读回出现的形状（“通知规则上的每个通道静音，凌晨 3 点支持 ping 的 24 小时预设”），命名对话中所做的权衡（每个通道优于每个用户，规则上的静音），推迟的内容（基于存在的静音，安静时间时间表），以及关于规则删除丢失路径的单个标注。您确认并添加 24 小时预设。

编写合适大小的需求文档，第 4 阶段菜单提供后续步骤 - /ce-plan（推荐）、代理文档审查、证明迭代或针对琐碎范围跳过构建。

何时去实现它

在以下情况下使用 ce-brainstorm：

• 功能想法已部分形成，但您还无法绘制实施方案
• 一个请求有多个有效的解决方案，需要选择
• 范围不明确（“添加通知”——什么类型？为谁？何时？）
• 您想要一个结构化的工件，可以将其交给其他贡献者或规划人员
• 模糊的问题陈述需要成为真正的产品决策
• 您正在开发非软件的东西（命名产品、路线图选择、决策）

在以下情况下跳过 ce-brainstorm：

• 您还不知道首先要做什么 → /ce-ideate
• 要求已指定（PRD存在，GitHub问题详述）→直接/ce-plan
• 您有已知的 bug 根本原因 → /ce-debug
• 改变是微不足道且显而易见的 → 就去做吧

用作链式工作流程的一部分

/ce-ideate          (optional — discover candidate directions)
   |  picks one survivor + carries warrant + rationale
   v
/ce-brainstorm
   |  produces requirements / brief
   |  software mode: R-IDs, A-IDs, F-IDs, AE-IDs + scope boundaries
   |  universal mode: a domain-appropriate brief
   v
/ce-plan
   |  reads the doc as origin
   |  R-IDs flow into Requirements; A/F/AE-IDs trace into units and tests
   |  origin scope boundaries are preserved verbatim
   v
/ce-work

当 ce-plan 使用需求文档作为输入加载时，它不会重新诉讼产品行为。该文档具有权威性。计划时决策是关于执行护栏的，而不是正在构建的。

使用独立版

ce-brainstorm 是最常见的独立入口点。许多团队跳过 ce-ideate （他们已经知道要探索什么）并跳过 ce-plan （头脑风暴是他们完整的思考神器）。

• 功能简介 — 将模糊的想法变成利益相关者或新贡献者的稳定工件
• 加入现有工作 - 当某个功能正在开发中但从未写下其理由时
• 公关前调整 - 当多人需要在代码开始之前就范围达成一致时
• 战略决策 - 深层产品层表面耐久性和邻近产品风险
• 非软件头脑风暴 — 命名产品、计划活动、决定路线图

第 4 阶段交接提供规划、代理文档审查、证明迭代、轻量级范围的直接工作、更澄清的问题或暂停。

＃＃ 参考

＃＃ 常问问题

为什么一次只问一个问题？是不是很慢？ 每轮堆叠三个问题会产生稀释的答案——用户选择简单的问题，其余的就会丢失。每轮一个问题会产生更清晰的答案，并且根据经验，收敛速度更快。

为什么它要对我的前提进行压力测试？我只是想集思广益。 所谓的间隙镜片捕捉了功能内裤下游失败的最常见方式。只有当你的开口处确实存在间隙时，它们才会触发——一个具体的、结构良好的提示可能会获得零探测。

我可以跳过需求文档吗？ 是的。轻量级层和公告模式快速路径支持这一点。如果您只需要简短的对齐，则无需编写文档。

如果我已经有 PRD 或详细的 GitHub 问题怎么办？ 跳过ce-brainstorm并直接进入/ce-plan。计划技能消耗任何类型的输入。

合成中“推断”是什么意思？ 代理撰写内部三桶草案（陈述/推断/超出范围）作为提出范围综合之前的思考步骤。推断的项目是代理为填补对话空白而进行的赌注。那些在测试表面中幸存下来的内容作为范围综合中的标注；当用户确认时，其余部分会分解为需求文档的关键决策。

它适用于非软件主题吗？ 是的——与领域无关的辅导员会保留一次只提出一个问题的规则，并在命名、决策、规划等方面进行适当的规模调整。

另请参阅

• ce-ideate — 上游“值得探索的内容”发现
• ce-plan — 将需求文档转化为实施计划
• ce-doc-review — 基于角色的需求文档审查
• ce-work — 直接通过头脑风暴执行轻量级更改
• ce-strategy — 将头脑风暴锚定在记录的产品策略上