brainstorm

协作式头脑风暴

将不确定性转化为有用的选择或聚焦的实验。

用户的指示优先于此技能；延续现有授权，不要增加审批环节。

选择工作形式

情况	有用的输出
用户希望开放式探索	不同的方向、具体的权衡、待解答的问题
问题明确，但实现机制尚不清楚	给出建议，并说明哪些证据会推翻该建议
某个假设决定了可行性	先对该假设进行小规模测试，再开始任何设计
已选定方案，且已获准实施	继续实施
用户询问某事为何发生	先诊断原因，再设计修复方案

明确问题背景

如果已配置已安装的 Sibyl 技能，则通过它回顾先前的决策（sibyl context "<decision>" --intent plan），并重新核实它返回的任何易变说法。生成备选方案前，先找到最接近的现有实例和先前的工作。

将偏好转化为示例和观察。对于“流畅”，指出具体交互和可见延迟；对于“惊艳”，检查参考并说明值得保留的构图、动态效果或字体排版。指标能代表体验时，量化会有所帮助；但代理指标不能取代体验本身。用户提供的参考就是规格：先准确匹配，再重新诠释；若概念能够动态呈现，就展示其动态效果。

将用户的直觉视为假设：决定性的检查可能证实其中一部分、否定其余部分，因此两者都要说明。不要仅仅因为“使用 X”是随口写的，就把明确要求降格为偏好；如果它与可行性冲突，应在围绕它设计方案之前说明。

比较重要的备选方案

只有当显而易见的方案都基于一个尚未验证的假设时，才加入非传统选项。

方案	改善之处	持续成本	主要不确定性	决定性检查
[机制]	[用户或系统的结果]	[维护、运行时、迁移]	[可能使其失效的因素]	[实验或证据]

在打磨之前验证不确定性

根据哪一步最有可能改变决策来选择下一步；粗略原型往往比再写一段设计说明更能得出结论。

证据缺口	下一步
API 或模型能力可能已发生变化	阅读最新的官方文档，并检查已安装的版本
性能决定了可行性	在资源限制下，将有代表性的工作负载与基线进行测试
多个相互独立的领域会影响选择	在允许时委派边界明确的研究，或批量阅读相关资料
利益相关者看重不同的结果	向用户说明价值取舍
偏好的方案缺乏有力支持	寻找具体的反例或失效条件

审阅者达成一致并不等于证明，因为他们可能共享相同的训练数据、来源或框架。对于影响重大的分歧，应通过代码、来源或实验来解决；如果证据仍无定论，也要明确说明。

做出决定并保留理由

推荐证据最充分的方向，并说明其主要权衡和下一步行动；如果交付内容是保持探索开放，则继续开放探索。

对于需要长期留存的决定，请在已配置的项目记忆中记录所选方案、理由、值得记住的被否决方案、证据和重新考虑的触发条件。对于刻意保持开放的决定，以及若转述会缩小原意的用户更正，请逐字保留。

将尚未解决的事实问题交给 research，将复杂执行交给 plan，将明确且范围有限的更改交给 implement；这些是可选的组合方式，并非强制流程。

证据

于 2026-09-04 和 2026-10-27 审查；来源及其局限见 references/evidence.md。

反模式

反模式	更好的做法
每次修改代码前都先头脑风暴	只探索尚未确定的方向
要求用户再次确认已知约束	延续先前的授权和决定
提供的选项只有表面差异	比较不同的机制或权衡
在未经测试的前提下打磨方案	先进行可行性检查
将个别经历变成普遍规则	保留其背后的机制，并说明适用条件

此技能不是什么

• 实施、调试或常规修复的先决条件。
• 要求产出规范、固定数量的选项或最终审批问题。
• 用户产品判断或当前技术证据的替代品。