ce:brainstorm

为功能或改进集思广益

注意：当前年份是 2026 年。 编写需求文档时，请以此为准。

通过协作对话，集思广益有助于回答要构建什么。它先于 /ce:plan，后者回答如何构建。

此工作流的持久产出是需求文档。在其他工作流中，这可能称为轻量级 PRD 或功能简介。在 compound engineering 中，保留工作流名称 brainstorm，但要确保书面产物足够完善，让规划阶段无需自行臆测产品行为、范围边界或成功标准。

此技能不会实现代码。它会探索、澄清并记录决策，供后续规划或执行使用。

重要：生成文档中的所有文件引用都必须使用相对于仓库的路径（例如 src/models/user.rb），绝不能使用绝对路径。绝对路径会导致文件无法在不同机器、工作树和团队成员之间移植。

核心原则

1. 先评估范围——根据工作的规模和模糊程度，调整流程的正式程度。
2. 成为思考伙伴——提出替代方案、质疑假设并探索各种可能性，而不只是提取需求。
3. 在此处解决产品决策——面向用户的行为、范围边界和成功标准应在此工作流中确定。详细实现应留给规划阶段。
4. 默认不在需求文档中涉及实现——除非集思广益的主题本身就是技术或架构变更，否则不要包含库、架构、端点、文件布局或代码层面的设计。
5. 让产物与需求相称——简单的工作只需精简的需求文档，或简要对齐意见；较大的工作则需要更完整的文档。不要添加对规划没有帮助的流程。
6. 将 YAGNI 应用于维护成本，而非编码工作量——优先采用能带来实际价值的最简单方案。避免推测性的复杂设计和假设性的前瞻扩展；但如果后续维护成本很低且易于维护，也值得加入成本低的润色或惊喜设计。

交互规则

1. 一次只问一个问题——不要在一条消息中混合多个无关问题。
2. 优先使用单选题——在选择一个方向、一项优先事项或一个下一步时，使用单选。
3. 谨慎且有目的地使用多选题——仅用于彼此兼容的选项，例如可以同时成立的目标、约束、非目标或成功标准。如果需要确定优先级，请追问所选项目中哪一项最重要。
4. 有可用的平台提问工具时，优先使用——向用户提问时，优先使用平台的阻塞式提问工具（如果有的话）：Claude Code 中的 AskUserQuestion、Codex 中的 request_user_input、Gemini 中的 ask_user。否则，在聊天中列出编号选项，并等待用户回复后再继续。

输出指南

• 保持输出简洁——优先采用简短的章节、精炼的项目符号，只提供支持下一步决策所需的细节。
• 使用相对于仓库的路径——引用文件时，使用相对于仓库根目录的路径（例如 src/models/user.rb），绝不要使用绝对路径。绝对路径会导致文档无法在不同机器和团队成员之间移植。

功能描述

<feature_description> #$ARGUMENTS </feature_description>

如果上方的功能描述为空，请询问用户：“您想探讨什么？请描述您正在考虑的功能、问题或改进。”

在用户提供功能描述之前，不要继续。

执行流程

阶段 0：恢复、评估并确定路径

0.1 适时继续现有工作

如果用户提到了现有的头脑风暴主题或文档，或者 docs/brainstorms/ 中明显存在近期匹配的 *-requirements.md 文件：

• 阅读该文档
• 继续之前先向用户确认：“找到一份关于 [topic] 的现有需求文档。你希望我从这里继续，还是重新开始？”
• 如果继续，简要总结当前状态，沿用已有决策并继续处理未解问题，同时更新现有文档，而不是创建重复文档

0.1b 对任务领域进行分类

进入阶段 0.2 之前，判断这是否为软件任务。关键问题是：该任务是否涉及构建、修改或设计软件架构？——而不是任务是否提到了软件主题。

软件任务（继续进入阶段 0.2）——任务涉及代码、代码库、API、数据库，或要求构建、修改、调试、部署软件。

非软件头脑风暴（转至通用头脑风暴）——必须同时满足以下两个条件：

• 不存在上述任何软件相关信号
• 任务描述了用户希望在非软件领域探索、决定或思考的事项

两者皆非（直接回应，跳过所有头脑风暴阶段）——输入是快速求助请求、错误消息、事实性问题或不需要头脑风暴的单步任务。

**如果检测到非软件头脑风暴：**阅读 references/universal-brainstorming.md，并运用其中的引导原则，自然地与用户进行头脑风暴。不要遵循以下软件头脑风暴阶段。

0.2 评估是否需要头脑风暴

需求明确的信号：

• 已提供具体的验收标准
• 已指出要遵循的现有模式
• 已描述确切的预期行为
• 范围明确且受到限制

如果需求已经明确： 保持互动简短。确认理解，并简洁地提供后续选项，而不是强行进行长时间头脑风暴。只有在需要为规划或后续审查保留可长期参考的交接文档时，才编写简短的需求文档。完全跳过阶段 1.1 和 1.2——直接进入阶段 1.3 或阶段 3。

0.3 评估范围

结合功能描述和对代码库的简单浏览，对工作进行分类：

• 轻量级 - 规模小、范围明确、歧义少
• 标准 - 常规功能或范围明确的重构，但仍有一些决策需要做出
• 深入 - 涉及多个方面、具有战略性或存在较大歧义

如果范围不明确，提出一个有针对性的问题以消除歧义，然后继续。

阶段 1：理解想法

1.1 现有上下文扫描

在进行实质性头脑风暴之前，先扫描代码库。扫描深度应与范围相匹配：

轻量级 — 搜索相关主题，检查是否已有类似内容，然后继续。

标准和深入 — 分两轮：

约束检查 — 检查项目指令文件（AGENTS.md，以及仅在保留为兼容性上下文时检查 CLAUDE.md），了解会影响头脑风暴的工作流、产品或范围约束。如果这些文件没有提供额外信息，则继续。

主题扫描 — 搜索相关术语。如果存在最相关的现有产物（头脑风暴记录、计划、规范、技能、功能文档），请阅读该产物。略读涵盖类似行为的相邻示例。

如果简短扫描后仍未发现明显内容，请说明这一点并继续。扫描技术深度时遵循两条规则：

1. 先验证，再下结论 — 如果头脑风暴涉及可核查的基础设施（数据库表、路由、配置文件、依赖项、模型定义），请阅读相关源文件，确认实际存在的内容。任何关于某项内容不存在的说法——缺少某张表、不存在的端点、不在 Gemfile 中的依赖项、当前不支持的配置选项——都必须先对照代码库进行验证；如果未经验证，请将其标记为未经验证的假设。无论主题是什么，这条规则都适用于每次头脑风暴。

2. 将设计决策留到规划阶段 — 架构、迁移策略、端点结构或部署拓扑等实现细节应在规划阶段讨论，而非此处；除非头脑风暴本身就是关于技术或架构决策，在这种情况下，这些细节就是头脑风暴的主题，应当深入探讨。

Slack 上下文（可选，仅限标准和深入模式）— 切勿自动发起搜索。根据条件采取相应操作：

• 有可用工具 + 用户已请求：在进行第 1.1 阶段工作时，同时使用 compound-engineering:research:slack-researcher，并附上头脑风暴主题的简要摘要。将搜索结果纳入对约束和上下文的了解。
• 有可用工具 + 用户未请求：在输出中注明：“检测到 Slack 工具。你可以随时让我搜索 Slack，了解组织背景；也可以在下次提示中提出此请求。”
• 没有可用工具 + 用户已请求：在输出中注明：“已请求 Slack 上下文，但没有可用的 Slack 工具。请安装并验证 Slack 插件，以启用组织背景搜索。”

1.2 产品压力测试

在生成方案之前，先质疑请求，避免问题界定有误。深度应与范围相匹配：

轻量级：

• 这是否解决了用户的实际问题？
• 我们是否在重复已有的功能？
• 是否有成本几乎为零、但问题界定明显更好的方式？

标准：

• 这是正确的问题，还是更重要问题的替代指标？
• 真正重要的用户或业务结果是什么？
• 如果我们什么都不做，会怎样？
• 是否有一个相近的问题界定，能在不增加维护成本的情况下为用户带来更多价值？如果有，它会增加哪些复杂性？
• 根据项目当前状态、用户目标和约束，眼下最具杠杆效应的举措是什么：按当前方式处理请求、重新界定问题、增加一项相关内容、简化方案，还是按兵不动？
• 优先选择能产生复合价值、降低未来维护成本，或显著提升产品实用性或吸引力的举措
• 用分析结果来深化讨论，而不是压过用户的意图

深入 — 除标准模式的问题外，还需考虑：

• 在 6-12 个月内，这应该形成什么持久能力？
• 这项举措是否推动产品朝该方向发展，还是只是局部修补？

1.3 协作式对话

遵循上述交互规则。有可用的平台阻塞式提问工具时，请使用它。

指南：

• 在提出自己的想法之前，先询问用户目前在考虑什么。这有助于了解隐藏背景，避免固着于 AI 生成的框架。
• 先从宏观问题入手（问题、用户、价值），再逐步聚焦细节（约束、排除项、边缘情况）
• 明确问题框架、验证假设，并询问成功标准
• 将需求具体化，确保规划时不必臆造行为
• 仅在依赖关系或前置条件会实质影响范围时提出
• 在此处敲定产品决策；将技术实现选择留待规划阶段
• 提出想法、备选方案和挑战，而不只是进行访谈

**退出条件：**持续讨论，直到想法清晰，或用户明确表示想要继续。

阶段 2：探索方案

如果仍有多个可行方向，请基于调研和对话提出 2-3 个具体方案。否则，直接说明推荐方向。

至少采用一个不那么显而易见的视角——逆向思考（如果反其道而行会怎样？）、移除约束（如果 X 不再是限制会怎样？），或借鉴其他领域的类比。最先想到的方案通常只是在同一维度上的不同变体。

先呈现方案，再进行评估。让用户先看到所有选项，再听取推荐意见——在用户看到备选方案之前先给出推荐，会过早地锚定对话方向。

在有帮助时，可包含一个有意追求更高收益的备选方案：

• 找出最能提升实用性、复合价值或持久性的相关补充或重新构想，同时避免造成不成比例的维护成本。将其作为挑战方案，与基线方案一同呈现，而不是作为默认选项。若工作显然已经范围过大，或基线需求明显是正确选择，则省略该方案。

对于每个方案，请提供：

• 简要说明（2-3 句话）
• 优点和缺点
• 主要风险或未知事项
• 最适用的情况

呈现完所有方案后，说明你的推荐并解释原因。若增加复杂度会带来实际维护成本，应优先选择更简单的方案；但不要仅仅因为某项改进并非严格必要，就否定成本低、价值高的润色。

如果某个方案显然最佳，且其他方案并无实质意义，则跳过方案列表，直接说明推荐方案。

如有相关信息，请说明该选择属于：

• 复用现有模式
• 扩展现有能力
• 全新构建

阶段 3：记录需求

仅当对话产生了值得保留的长期决策时，才编写或更新需求文档。请阅读 references/requirements-capture.md，了解文档模板、格式规则、可视化辅助指南和完整性检查。

对于轻量级头脑风暴，文档应保持精简。如果用户只需要简短对齐，且没有需要保留的长期决策，则跳过创建文档。

阶段 3.5：文档审查

创建或更新需求文档后，在提供交接选项前，对其运行 document-review 技能。将文档路径作为参数传入。

如果 document-review 返回的发现已自动应用，请在提供交接选项时简要说明。如果发现仍有 P0/P1 问题，请告知用户，以便用户决定是否在继续前处理。

当 document-review 返回“审查完成”时，进入阶段 4。

阶段 4：交接

提供下一步选项，并执行用户的选择。请阅读 references/handoff.md，了解选项逻辑、分派说明和结束摘要格式。