changan-su/forsion/self-brainstorm

自我脑暴 Self-Brainstorm

一条思路推到底,盲区就跟到底。self_brainstorm 把你从当前对话里分裂出几个视角分身: 它们看得见到目前为止的全部对话(不用你复述背景),各自独立表态、再互相拆台, 最后把逐席立场交回给你——综合出结论的仍然是你。

什么时候用

• 用户在开放性决定上找你:方案取舍、架构选型、买不买/换不换/学哪个、职业或计划的岔路口。
• 用户抛出开放设计题:「你会怎么设计/重构/改造 X」「给 X 做个方案」——没有标准答案、

好方案需要经受反面检验的构想题。

• 用户请你把关:「你觉得这样行吗」「有没有我没想到的坑」——这类问题的价值恰恰在反面视角。
• 你自己要给出错了代价不小的建议,而手上只有一条思路:先拆自己的台,再开口。
• 用户点名:「多角度想想」「你和自己讨论一下」「正反方辩一辩」。

和 start_discussion 怎么分工

两个都是思辨工具,默认先选 self_brainstorm:分身天生共享当前对话的全部上下文 (用户刚说过的约束、你们已排除的选项都在),不用把背景重新打包成议题,起步快、轮次少、 结论直接回你手上综合。start_discussion 留给两种情况:用户点名要找某个具体 agent 对辩(@了谁),或议题与当前对话无关、需要一个完全独立的外部立场从零聊起。 拿不准就用 self_brainstorm——它是轻的那个。

什么时候不用

• 有标准答案的事实问答、翻译、算术、查资料——单次回答就够,别为了仪式感开会。
• 机械执行类任务(改文件、跑命令、走流程)。
• 刚脑暴过同一话题:摘要已在对话里,接着用,别重复开。
• 时间敏感的快问快答:分身讨论要多花几十秒,用户只想要一句话时别拖堂。

topic 怎么写

中立陈述问题,不要把你的倾向烤进题面。 分身是从你分裂出来的——题面带了倾向, 所有席位都会顺着坡滑。

• 差:「为什么我们应该用 SQLite 而不是 Postgres?」
• 好:「本项目该用 SQLite 还是 Postgres?背景:单机部署、写入量低、团队没有 DBA。」

当前的倾向可以作为背景写进去(让 Challenger 有靶子),但问题本身保持开放。

perspectives 怎么设计

不传就用默认三席(拆台者/钢人建设者/另辟蹊径者),已经够用。要自定义时,记住: 视角是任务契约(审什么 + 必须产出什么),不是性格。「乐观者/悲观者」这类人格标签 产出高度雷同;按问题本身的轴线切才拉得开:

• 选数据库 →「迁移成本核算(必须给出数字量级)」×「查询性能(必须给出最坏场景)」
• 要不要重构 →「维护成本视角(列出现状每月实际疼在哪)」×「风险视角(列出重构会碰坏什么)」
• 职业选择 →「五年后视角(倒推现在)」×「现金流视角(算账)」

引擎总会自动补一个 Challenger 席,你不必自己写反方——把自定义席位留给问题特有的轴。 rounds 默认 2(独立表态+交叉拆台);问题简单、只想要几个独立观点时传 1。

拿到摘要之后

摘要只是原料,你的综合才是交付物:

1. 按论据强弱权衡,不按席位数投票——三席里一席说中要害就该赢。
2. 分歧点向用户明说:「X 视角认为…但 Y 指出…,我倾向后者,因为…」。
3. 别把摘要原样倒给用户;引用某席位的关键论点可以,整段转贴不行。
4. Challenger 没找到实质缺陷时,这本身就是信息——可以更有底气地推荐。

用户在子聊天区能看到各分身的讨论过程,所以不用复述过程,直接给结论和理由。