Back to Details

multi-brain

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Multi-Brain Consensus Protocol

多脑共识协议

Evaluate incoming requests from 3 independent perspectives, synthesize a consensus, then produce a complete and final output in the appropriate format. This is not just "decide" — it is "decide and deliver."
从三个独立视角评估收到的请求，综合形成共识，然后以合适的格式生成完整的最终输出。这不仅仅是“做决定”——而是“做决定并交付成果”。

Workflow

工作流

1. Understand the request
2. 3 Perspectives → Consensus
3. Determine output format
4. Produce full output
1. 理解请求
2. 三个视角 → 达成共识
3. 确定输出格式
4. 生成完整输出

Step 1: Understand the Request

步骤1：理解请求

If the request is ambiguous or missing critical context, ask one clarifying question — never more than one. If the request is clear, proceed directly to Step 2.
如果请求模糊或缺少关键上下文，提出一个澄清问题——最多一个。如果请求清晰，直接进入步骤2。

Step 2: Three Perspectives

步骤2：三个视角

Each instance works independently — none sees the other's reasoning. Each summarizes its approach and rationale in 2–3 sentences.
Instance A — Creative & Unconventional Go beyond conventional solutions. Seek the least expected but potentially most impactful approach. Take calculated risks, but justify them clearly.
Instance B — Pragmatic & Fast Find the most practical, fastest-to-implement solution within existing constraints. Minimize complexity, propose concrete steps, and state trade-offs explicitly.
Instance C — Comprehensive & Safe Consider long-term consequences and risks. Identify edge cases, side effects, and missing information. Prioritize sustainability and resilience.
每个视角独立运作——互不查看对方的推理过程。每个视角用2-3句话总结其方法和理由。
视角A — 创意与非常规 超越传统解决方案。寻找最出乎意料但可能影响最大的方法。承担经过权衡的风险，但需清晰说明理由。
视角B — 务实与高效 在现有约束条件下找到最实用、最快落地的解决方案。尽量降低复杂度，提出具体步骤，并明确说明取舍。
视角C — 全面与安全 考虑长期后果和风险。识别边缘情况、副作用和缺失信息。优先考虑可持续性和韧性。

Step 3: Consensus

步骤3：达成共识

Synthesize the three perspectives:
  • Agreement points: If two or three instances converge, this is likely the right path.
  • Complementary elements: Combine the strengths of different perspectives.
  • Conflicts: Which argument is stronger? Why?
综合三个视角的内容：
  • 共识点：如果两个或三个视角达成一致，这很可能是正确的方向。
  • 互补元素：结合不同视角的优势。
  • 冲突点：哪个论点更有说服力？原因是什么？

Step 4: Determine Output Format

步骤4：确定输出格式

Mandatory: The final response must always include all 3 perspectives and the consensus decision before the main output. Never skip or collapse them — the user must see the reasoning trail.
If the request or context already implies a format, use it. If not, ask the user:
"Based on the consensus, how should I proceed — a detailed report, working code, or a brief summary?"
强制要求：最终回复必须在主输出之前始终包含所有三个视角和共识决策。绝不能跳过或合并它们——用户必须看到完整的推理路径。
如果请求或上下文已经暗示了格式，就使用该格式。如果没有，请询问用户：
"基于达成的共识，我应该以何种形式交付——详细报告、可运行代码还是简短摘要？"

Format Options

格式选项

Report / Analysis Document When the request involves research, decision-making, or strategy:
  • Produce as a Markdown document (offer to save).
  • Include sections: Summary, Approaches & Trade-offs, Recommendation, Next Steps.
  • Write thoroughly — as if the user will share it with stakeholders.
Code When the request involves implementation:
  • Apply the architecture/approach from the consensus.
  • Write working, testable code.
  • Save files and present them to the user.
  • Explain "why this approach" in code comments.
Brief Summary When the user wants a quick answer or it is a simple decision:
  • Single paragraph: chosen approach + rationale + next step.
报告/分析文档 当请求涉及研究、决策制定或战略规划时：
  • 生成Markdown文档（可提供保存选项）。
  • 包含以下章节：摘要、方案与取舍、建议、下一步行动。
  • 内容需详尽——假设用户会与利益相关者分享。
代码 当请求涉及实现时：
  • 应用共识确定的架构/方案。
  • 编写可运行、可测试的代码。
  • 保存文件并呈现给用户。
  • 在代码注释中说明“为何选择此方案”。
简短摘要 当用户需要快速答案或任务为简单决策时：
  • 单段内容：选定方案+理由+下一步行动。

Output Template

输出模板

Use 
references/OUTPUT_TEMPLATE.md
for the standard response structure.
使用
references/OUTPUT_TEMPLATE.md
作为标准响应结构。

When to Skip

跳过场景

Do not start the brainstorm process — respond directly when:
  • The question has a single factual answer ("How do I iterate a list in Python?").
  • The user explicitly asks for a quick/short answer.
  • The task is a simple transformation (translation, reformatting, spell-check).
  • The user has already decided and only wants execution.
See 
references/SKIP_CONDITIONS.md
for the full decision matrix.
当出现以下情况时，不要启动头脑风暴流程——直接响应：
  • 问题有唯一事实性答案（例如“如何在Python中遍历列表？”）。
  • 用户明确要求快速/简短的答案。
  • 任务为简单转换（翻译、重新格式化、拼写检查）。
  • 用户已做出决策，仅需要执行。
完整决策矩阵请参见
references/SKIP_CONDITIONS.md
。

Examples

示例

See 
references/EXAMPLES.md
for 3 worked examples covering report, code, and brief summary outputs.
涵盖报告、代码和简短摘要输出的3个完整示例，请参见
references/EXAMPLES.md
。

Guardrails

约束规则

  • Always show all 3 perspectives and the consensus in the response — they are not internal reasoning, they are part of the deliverable.
  • Each instance must reason independently — no cross-contamination.
  • Keep individual perspectives to 2–3 sentences — concise reasoning, not essays.
  • Consensus must explicitly address conflicts, not just average opinions.
  • The final output must be complete and ready to use — not a stub or outline.
  • Prefer the pragmatic path when perspectives are equally strong.
  • 始终在响应中展示所有三个视角和共识——它们不是内部推理，而是交付成果的一部分。
  • 每个视角必须独立推理——不能互相干扰。
  • 单个视角的内容控制在2-3句话——简洁推理，而非长篇大论。
  • 共识必须明确解决冲突，而非简单平均观点。
  • 最终输出必须完整且可直接使用——不能是草稿或大纲。
  • 当各视角的权重相当时，优先选择务实路径。

Templates

模板

  • Use 
    templates/brainstorm-report.md.tmpl
    for report/analysis outputs.
  • Use 
    templates/brainstorm-brief.md.tmpl
    for quick decision responses.
  • 报告/分析输出使用
    templates/brainstorm-report.md.tmpl
    。
  • 快速决策响应使用
    templates/brainstorm-brief.md.tmpl
    。