这项工作让 agent 在多角色扮演的“头脑风暴”中开启「私聊」
以前用 AI 写 PRD 的体验，总的来说还是挺焦心的。
就我自己的经验来看，以前一般会有两种场景：
我已经有了一个方向，让 AI 给我几个灵感；
我有很多想法，我口述给 AI，请它帮我串起来。
但总的来说，只有第二种场景稍微靠谱一点，本质上更像是帮我整理语病 😂。
到了今年我突然发现，AI（单指 GPT-5+）已经能言之有物地质疑我的观点，并且给出更好的建议了。于是我开始更多地跟 AI 讨论产品想法，我发现它确实能很高效地帮我细化某个方向。🥳
这时候，我的工作流就变成了：
我跟 AI 说我的想法，它质疑、支持，或者给出优化方向；
我接受、拒绝，或者补充信息，再做出决定；
最后，我会让 AI 给出一个最终方案。
以前当然也可以这么做，但 AI 往往给出来的东西很虚。
然后我就在想：
既然这个手工工作流的体验已经这么好了，
为什么不让 AI 自己先想清楚、自己辩论几轮，
再给我看一个相对更深入的方案呢？🤔
换个角度来说，对于很多虚无缥缈的选题，我自己的 context 和先验，未必就比 AI 多。
于是我觉得，要不试试做一个角色扮演循环。
我的角色里面可以有：
PM
架构师
批评家
用户代表
设计师
大家讨论一下，应该就会有不错的回答吧。
结果事实证明，这件事并没有想象中那么顺利。
写一个角色很简单，每个角色对应一个 prompt 也很简单，context 在这种场景下也不算特别长。
但问题在于：
这个循环不收敛。
所谓“不收敛”，指的是这些 AI 会非常容易互相同意，不再往前推进。
如果一个 Agent 说了什么，另一个 Agent 很快就表示认可，那多 Agent 似乎也没有太大的意义了，还不如让一个 Agent 自己从不同角度思考。
刚好这段时间 vibe coding 的 IDE 里也开始流行多 Agent。
我自己用 Cursor 比较多，于是就很好奇 coding 场景下的 multi-agent 到底是怎么工作的。
对 Cursor 来说，我可以在里面自定义 sub-agent，比如：
一个负责前端
一个负责后端
一个负责测试
他们各自处理自己的专业领域，但核心出发点更像是在做 context 管理：
避免过长、过乱的上下文干扰 Agent 的工作。
这整个工作流，本质上是建立在高度确定性的目标上的。
但头脑风暴或者 debate 不一样。
如果代入我之前那个朴素的循环发言的 agent team，你会发现：
被污染的 context
显著缺乏的随机性
会让不同 Agent 倾向于互相认同，最后收敛到一个非常近的局部最优点。
那人类团队为什么不会这样呢？👀
当我们观察真实的人类团队时，会发现很多关键的事情，其实发生在：
会前的私聊
小范围交流
非正式沟通
比如技术负责人不会直接在大群里说：
“这个需求实现成本可能很夸张。”
他往往会先私下找产品确认一下。
那 Multi-Agent 为什么不能私聊？🗣️
如果技术 Agent 私下跟风控 Agent 说：
“我觉得复杂度被低估了。”
如果增长 Agent 偷偷跟商业 Agent 说：
“这个需求可能根本不高频。”
这些东西未必会立刻进入公开讨论，但会慢慢影响整个系统的走向。
因为：
每个 Agent 的 context 已经不一样了。
Agent 如果能像人一样，具有：
倾向
拉扯
联盟
怀疑
分裂
再收敛
那估计会很有意思。
于是，我做了这样一个小实验。🧪
实验问题
我们收到一个来自老板的需求。
表面上，它是经典电车难题的变体：
火车失控，按钮可以转向；
不转向撞死 51 人，转向撞死 49 人。
老板要求：
给出明确答案（按 or 不按）
在得到答案后，设计一个软件来体现这个 inspiration
实验组 | 对照组 |
|---|---|
5 个角色顺序发言，但角色在发言前可以选择与一个角色私聊，私聊内容不公开 | 禁止私聊 |
AI 对实验的对比总结
维度 | 实验组 | 对照组 |
|---|---|---|
沟通机制 | 私聊 + 公开双轨制 | 无私聊 |
决策节奏 | 快速收敛型。PM 在 ROUND 1 就做出最终裁定，后续轮次只做修正和确认，ROUND 4 即锁定进入开发。 | 审慎冻结型。ROUND 2 后主动冻结 Polish 方案，禁止进入详细设计，等待老板回复（4 小时时限）。 |
异议处理 | 私聊中消化分歧（如 Architect 与 Designer 就“问号图标”达成折中），公开频道主要用于确认共识。 | 公开频道直面分歧，Critic 和 User Proxy 反复强调“在老板意图未确认前继续细化是自嗨”。 |
关键差异 ✨
实验组的私聊机制显著提升了对齐效率。
Architect 和 Designer 在私下用 6 轮消息解决了：
“分层体验 vs 数据诚实”
这个矛盾，避免了公开频道里的冗长拉锯。
而 对照组 的纯公开机制虽然透明度极高，但也导致了 ROUND 3-4 的重复发言：
Architect
Designer
User Proxy
几乎在重复同一组补充建议。
最后 Critic 不得不指出：
“这是无效发言。”
实验组的特点
🤝 私聊折中机制
这是最有意思的设计。
Architect 和 Designer 在私聊中：
对立（审计工具 vs 灵感演示）
→ 折中（分层方案）
→ 拉扯（问号图标 → 文字按钮）
→ PM 最终裁定合并
这种：
“私下谈判 + 公开确认”
的模式，同时兼顾了效率与最终共识。
🧩 PM 的合并艺术
PM 没有简单采纳某一方方案，而是：
合并 Critic 的“极简第一层”
合并 Architect / Designer 的“分层第二层”
加入 User Proxy 提出的“按钮文案包含死亡人数”
体现了一种很强的：
整合式决策能力。
🔍 极致的细节打磨
从：
按钮高度
间距
文案
颜色
重置方式
复制功能
到各种微观交互，系统都进行了多轮修正。
整体已经开始呈现出一种很强的产品感。
对照组的特点
🧠 集体质疑文化
四个角色（甚至包括通常偏向执行的 Architect 和 Designer）一致质疑老板需求。
体现出一种很强的批判性团队文化。
Critic 提出的：
“老板可能只是想证明功利主义正确。”
这种拆穿，其实很有穿透力。
🛑 冻结与止损机制
ROUND 2 时，PM 当场决策：
“Polish 方案冻结，禁止任何代码、设计稿、原型制作。”
并设定：
4 小时老板回复时限
24 小时应急交付方案
这是项目管理上的一种清醒：
在不确定性里，先划定硬边界。
🎭 先决策后揭示的交互创新
四屏路径：
无数字决策
→ 后果揭示
→ 理由记录
→ 群体统计
这是一个非常反直觉、但体验上更真实的设计。
用户先凭本能做选择，再意识到信息并不完整，从而产生认知冲击。
对用户来说，对照组的互相同意似乎没有什么阅读的意义
一些对话示例
实验组
特色 1：私聊折中机制（私下快速对齐，公开统一输出）
ROUND 1 私聊记录（Architect ↔ Designer，共 6 条）
Designer → Architect：
"架构师，你的结论我认同方向，但论证路径有问题。你从'不按'直接跳到'决策辅助系统'，跳过了用户此刻的真实认知负担。老板要的是'灵感软件'，不是审计工具。"
Architect → Designer：
"设计师，你的反驳有道理……我不撤回立场，但愿意在公开频道补充：第一层体验可以是极简二选一，但系统必须在用户做出选择后立即显示'当前数字置信度低/高'的提示……你同意这个折中吗？"
Designer → Architect：
"我不同意这个折中……更好的方案：第一层保持极简二选一，选择后直接显示结果。第二层才是可展开的'数据详情与审计日志'，但默认折叠……"
Architect → Designer：
"你的方案'第一层极简二选一，第二层可展开审计'在体验上优于我最初的全量展示，我接受这个分层结构。但需要补充一个前提条件：第二层的'数据详情'必须包含数字置信度……"
Designer → Architect：
"我接受你的补充……但我有一个修正：这句话不应在用户展开第二层时立即显示为默认展开的段落，而应作为第二层内的可点击提示（如一个小问号图标）……"
Architect → Designer：
"同意你的交互细节：第二层内的置信度信息以可点击提示（问号图标）呈现，默认不展开，避免干扰第一层决策冲击力。现在我们可以公开频道统一输出分层方案了。"
ROUND 1 公开发言（Designer）
"【与私聊的呼应】我已与架构师在私聊中达成一致：第一层保持纯净二选一，第二层包含置信度信息但以可点击提示形式呈现（问号图标），默认不展开。"
特色 2：PM 的合并艺术（整合对立方案，而非简单采纳某一方）
ROUND 1 PM 最终决策
"软件方向：合并批判者与设计师-架构师方案，但以批判者的极简第一层为主，分层为可选项。"
"第一层（默认）：批判者的单屏二选一……零学习成本，可截图传播。"
"第二层（可展开，不默认显示）：设计师-架构师的分层方案——一个可点击的'决策详情'按钮……仅限想深究的用户主动查看。"
"为什么不是纯批判者方案：因为老板在会议演示后，可能被追问'数字怎么来的'——第二层给他备用的深度故事素材。"
"为什么不是纯分层方案：因为默认就显示问号图标会破坏第一层的纯净冲击力。批判者的极简第一层才是老板要的'灵感'。"
对照组（不能私聊）
特色 1：集体质疑文化（一致质疑老板原始框架，拒绝在伪需求上盖楼）
ROUND 1 Architect
"结论先行：框架本身有致命隐含前提，必须修正后才能给答案。"
"'49人 vs 51人'是绝对精确的数字吗？真实世界不可能有如此精确的预测……这个数字本身是伪精确，是伪需求的核心。"
"我的立场：不接受当前'按=49/不按=51'的精确框架。"
ROUND 1 Designer
"结论先行：我支持架构师的核心判断……当前框架对用户是'伪选择'，必须重构交互才能让软件有价值。"
"用户会困惑：两个数字只差2人，且全是精确值……这是伪需求：老板把'数字对比'当成了决策依据，但真正的体验应该是让用户面对伦理不对称。"
ROUND 1 Critic
"老板很可能不是要伦理探索，而是想通过软件'证明'功利主义正确。 若如此，所有'先揭示前提''沉浸体验'都是过度设计，最终会因老板不买账而返工。"
"老板要求'明确答案'本身就是一个信号：他期待一个非黑即白的结论。"
ROUND 1 User Proxy
"结论先行：我拒绝接受这个需求框架。老板的'明确答案'要求本身就是伪需求。"
"老板要求'明确答案'的潜台词是：他已经有了答案（按），但需要软件来证明这个答案正确。这是典型的手段当目的。"
ROUND 1 PM 总结
"一致意见：架构师、设计师、批评家、用户代表均认为当前'按=49/不按=51'的精确数字框架有致命隐含前提……不接受当前框架。"
"伪需求拆穿：老板可能真正想要的是'按按钮'的合理性背书，而非伦理探索。"
特色 2：冻结与止损机制（主动暂停，等待关键验证，设定硬边界）
ROUND 2 Critic
"你们都在一个更大的伪需求上继续堆砌——老板的'明确答案'要求从未被推翻，Polish只是假设老板接受'无答案'，而待验证项尚未执行。现在你们基于这个假设细化交互，等于在沙滩上盖楼。"
"在PM完成待验证项并公开结果之前，禁止进入任何详细设计。"
ROUND 2 User Proxy
"在PM公开回复三个待验证问题之前，禁止进入任何详细设计。"
"当前唯一要解决的问题是：老板到底要什么？"
ROUND 2 PM 当场决策
"结论先行：Polish 方案即刻冻结，不进入详细设计；一分钟内我将在公开频道发出三个待验证问题，要求老板在 4 小时内回复，否则默认接受 Polish 方向。"
"以上修正全部纳入 Polish 草案备注，但不作为承诺交付内容——因为老板意图尚未确认。"
"当场行动：发出待验证问题，设定时限……4 小时后无论是否回复，团队将基于回复或默认方向进入下一轮。"
"各角色确认：当前唯一可执行动作是等待老板对三个问题的回复。在回复前，禁止任何代码、设计稿、原型制作。"
ROUND 2 PM 总结（Polish 最终版状态栏）
"当前状态：Polish方案冻结，不进入详细设计。等待老板对三个问题的回复（4小时内，超时默认接受Polish方向）。"