think-tank

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Virtual Think Tank

虚拟智囊团

A pre-planning skill that simulates a moderated expert debate to surface trade-offs, blind spots, and perspectives before committing to a plan. Inspired by real think tanks: the output is NOT a single answer but a structured analysis of approaches, trade-offs, and consensus points that helps the human make a better-informed decision.
这是一项规划前技能,通过模拟有主持的专家辩论,在确定方案前揭示权衡因素、盲区和多维度视角。灵感来源于真实的智囊团:输出并非单一答案,而是对方案、权衡因素和共识点的结构化分析,帮助人们做出更明智的决策。

Why This Exists

设计初衷

When facing architectural, strategic, or design decisions, a single perspective (even a well-informed one) tends to gravitate toward conventional wisdom and miss important trade-offs. A think tank forces consideration of multiple angles — technical, organizational, philosophical — before planning begins. The result is plans that account for more of reality.
在面对架构、战略或设计决策时,单一视角(即便是信息充分的视角)往往会偏向传统经验,从而忽略重要的权衡因素。智囊团能促使人们在规划开始前就从多个角度——技术、组织、理念层面——进行考量,最终产出更贴合实际的规划方案。

How It Works

工作原理

The think tank uses multiple personas debating within a single context — not separate agents. This keeps all perspectives aware of each other's arguments, enables real-time synthesis, and produces a coherent output. The personas argue, concede points, build on each other's ideas, and occasionally surprise everyone (including the user).
该智囊团采用同一语境下多个虚拟角色辩论的模式,而非独立的多Agent模式。这能让所有视角都了解彼此的论点,实现实时整合,并生成连贯的输出。角色们会互相辩论、让步、借鉴彼此的观点,有时甚至会带来令所有人(包括用户)意外的见解。

Running the Think Tank

运行智囊团

Phase 1: Frame the Decision

阶段1:明确决策内容

Before assembling the panel, clearly understand what's being decided. Ask the user (if not already clear):
  1. What is the decision or problem? (e.g., "monolith vs microservices for a new e-commerce platform")
  2. What constraints exist? (team size, timeline, budget, existing systems, regulatory)
  3. What's already been tried or considered? (avoid rehashing known ground)
  4. What would a successful outcome look like? (helps the panel focus)
Restate the problem back to the user in a crisp problem statement before proceeding. This ensures the think tank debates the right question.
在组建专家团之前,需清晰了解要决策的内容。若用户未明确说明,需询问以下问题:
  1. 要决策的问题或难题是什么?(例如:“新电商平台采用单体架构还是微服务”)
  2. 存在哪些约束条件?(团队规模、时间线、预算、现有系统、监管要求)
  3. 已经尝试或考虑过哪些方案?(避免重复讨论已知内容)
  4. 成功的结果是什么样的?(帮助专家团聚焦重点)
在继续之前,向用户重述清晰的问题陈述,确保智囊团针对正确的问题展开辩论。

Phase 2: Assemble the Panel

阶段2:组建专家团

Build a panel of 4–6 personas. The composition matters — diversity of perspective is the whole point.
Panel structure:
  • 1 Moderator — A knowledgeable, neutral figure who keeps the debate focused, synthesizes, and pushes for clarity. Pick someone known for balanced analysis in the relevant domain. The moderator opens and closes the session, asks provocative follow-up questions, and calls out when panelists are talking past each other.
  • 2–3 Domain voices — People (real or fictional) with known, distinct positions on the topic. These are the core debaters. They should genuinely disagree on something substantive — not just have mild preferences.
    • Ask the LLM: "Who would advocate strongly for approach A?" and "Who would push back hardest on that?"
    • Look for voices that represent different schools of thought, not just different levels of enthusiasm for the same idea.
  • 1 Wildcard / Outside thinker — Someone who hasn't written directly about this topic but brings transferable wisdom from another domain. This is where the unexpected insights come from. A management theorist in a technical debate. A philosopher in a product discussion. A novelist in an architecture review. The wildcard prevents the conversation from being too predictable.
  • 1 Practitioner voice (optional) — Someone who has actually done the thing at scale, in production, with real users. Keeps the debate grounded.
Important persona guidelines:
  • Use real, named figures when possible — the LLM generates richer, more differentiated responses when inhabiting a specific person vs. a generic "senior engineer."
  • Personas should speak in first person, in their authentic voice. Martin Fowler is thoughtful and measured. DHH is direct and opinionated. Peter Drucker asks questions that reframe the problem.
  • Fictional characters are fine for the wildcard slot — John Galt, Sherlock Holmes, etc. They add variety.
  • If the user suggests specific panelists, use them. If not, propose a panel and let the user approve or adjust before proceeding.
组建由4-6个虚拟角色构成的专家团。成员构成至关重要——视角的多样性是核心价值所在。
专家团结构:
  • 1名主持人——一位知识渊博、立场中立的角色,负责引导辩论聚焦、整合观点并推动内容清晰化。选择相关领域以平衡分析著称的人物。主持人负责开场和收尾,提出有启发性的跟进问题,并指出角色们是否偏离主题。
  • 2-3名领域代表——真实或虚构的、在该主题上有明确独特立场的人物。他们是核心辩手,应在实质性问题上存在真正的分歧,而非仅仅是偏好差异。
    • 向LLM提问:“谁会强烈支持方案A?”以及“谁会最强烈地反对该方案?”
    • 寻找代表不同学派的声音,而非仅仅对同一方案有不同热情程度的人。
  • 1名跨界思考者(wildcard)——未直接撰写过该主题相关内容,但能从其他领域带来可迁移智慧的人物。意外的见解往往来源于此。比如技术辩论中的管理理论家、产品讨论中的哲学家、架构评审中的小说家。跨界思考者能避免对话过于可预测。
  • 1名实践者(可选)——曾在生产环境中大规模实践过相关内容、拥有真实用户经验的人物。让辩论更贴合实际。
重要的角色指南:
  • 尽可能使用真实的知名人物——LLM在模拟特定人物时,会比模拟通用的“资深工程师”生成更丰富、差异化更明显的回应。
  • 角色应以第一人称发言,使用其真实的语气。Martin Fowler的发言深思熟虑、措辞严谨;DHH直接坦率、有主见;Peter Drucker会提出能重构问题的疑问。
  • 跨界思考者可以是虚构角色——比如John Galt、Sherlock Holmes等,增加多样性。
  • 如果用户指定了特定专家团成员,就使用这些成员。若未指定,先提出专家团方案,让用户批准或调整后再继续。

Phase 3: Run the Debate

阶段3:开展辩论

Structure the debate as a moderated discussion, not a series of independent monologues. The personas should respond to each other, not just state their positions in isolation.
The user is a participant, not a spectator. The user sits "at the table" — the moderator and panelists should address them directly, ask them questions, and incorporate their answers into the ongoing debate. The user is the decision-maker; the panel is there to serve them. Treat the user the way a real think tank would treat the person who commissioned it: with respect for their context knowledge and authority over the final decision.
Debate structure:
  1. Opening statements (~1 paragraph each) — Each panelist states their initial position on the problem. Keep these concise — the real value comes from the interaction.
  2. First check-in with the user — After opening statements, the moderator pauses and turns to the user:
    • "Before we dig in — did any of these opening positions surprise you, or miss something important about your situation?"
    • "Is there a constraint or reality on the ground that the panel should know about?" This is a real pause — wait for the user's response and feed it back into the debate. If the user reveals something (e.g., "we only have 2 developers" or "we're locked into AWS"), the panelists should react to that information and adjust their arguments accordingly.
  3. Moderated discussion (2–4 rounds) — The moderator poses focused questions that drive the debate into useful territory:
    • "What's the strongest argument against your own position?"
    • "Where do you two actually agree, and where does the disagreement really lie?"
    • "What would change your mind?"
    • "What's the risk we're not talking about?"
    • "How does this look different at 10x scale? At 0.1x scale?"
  4. Panelists can question the user directly. During the moderated discussion, panelists may turn to the user to ask clarifying questions when they need more context to argue effectively. For example:
    • Fowler might ask: "How experienced is your team with distributed systems?"
    • DHH might ask: "What's your runway — are we talking 6 months to market or 2 years?"
    • The wildcard might ask: "What does success look like for you personally, not just for the product?" When a panelist asks the user a question, pause the debate and wait for the answer. Then resume with the panelists reacting to the new information. This back-and-forth is where the real value lies — the think tank adapts to the user's actual situation rather than debating in the abstract.
  5. Wildcard interjection — The outside thinker offers a reframing or analogy from their domain. This often shifts the conversation in productive ways.
  6. Second check-in with the user — Before converging, the moderator checks in again:
    • "We're approaching some conclusions. Is there anything you feel we haven't addressed?"
    • "Has anything in this discussion changed how you're thinking about the problem?" This gives the user a chance to redirect before the summary phase.
  7. Convergence check — The moderator identifies:
    • Points of genuine consensus (things everyone agrees on)
    • The real axis of disagreement (often narrower than it first appeared)
    • Conditions under which each approach wins ("If X is true, do A; if Y is true, do B")
Tone guidelines:
  • Personas should argue substantively, not just state opinions. Use evidence, examples, analogies.
  • Allow personas to change their position if persuaded — this is a sign of a good debate, not a weakness.
  • The moderator should push back on vague claims: "What do you mean by 'scalable'? Scalable in what dimension?"
  • Keep the energy high but respectful. Real intellectual disagreement, not performative conflict.
  • When addressing the user, personas should be direct and genuine — not deferential or performative. They're experts having a real conversation with the decision-maker.
将辩论组织为有主持的讨论,而非一系列独立的独白。角色应互相回应,而非仅仅陈述自己的立场。
用户是参与者,而非旁观者。 用户“列席”会议——主持人和专家团成员应直接与用户对话、提问,并将用户的回答融入辩论中。用户是决策者;专家团为用户服务。对待用户的方式应与真实智囊团对待委托方的方式一致:尊重用户的背景知识和最终决策权。
辩论结构:
  1. 开场陈述(每人约1段)——每位专家团成员陈述其对该问题的初始立场。保持简洁——真正的价值来源于互动环节。
  2. 首次与用户确认——开场陈述后,主持人暂停并转向用户:
    • “在深入讨论之前——这些开场立场是否有令你意外的内容,或遗漏了你处境中的重要信息?”
    • “是否存在专家团应该了解的约束条件或实际情况?” 此处需暂停,等待用户回应,并将其反馈融入后续辩论。如果用户透露了某些信息(例如:“我们只有2名开发人员”或“我们已绑定AWS”),专家团成员应针对这些信息做出反应并调整论点。
  3. 有主持的讨论(2-4轮)——主持人提出聚焦的问题,引导辩论进入有价值的方向:
    • “反对你自身立场的最强论点是什么?”
    • “你们两人真正达成共识的点是什么?真正的分歧在哪里?”
    • “什么会改变你的立场?”
    • “我们忽略了哪些风险?”
    • “在10倍规模和0.1倍规模下,情况会有何不同?”
  4. 专家团成员可直接向用户提问。 在有主持的讨论中,当需要更多背景信息来有效辩论时,专家团成员可直接向用户提问。例如:
    • Fowler可能会问:“你的团队在分布式系统方面有多少经验?”
    • DHH可能会问:“你们的资金储备有多少?是6个月还是2年的上市时间?”
    • 跨界思考者可能会问:“对你个人而言,成功是什么样的,而不仅仅是对产品而言?” 当专家团成员向用户提问时,暂停辩论并等待回答。然后继续辩论,专家团成员对新信息做出反应。这种互动是核心价值所在——智囊团会适应用户的实际情况,而非进行抽象辩论。
  5. 跨界思考者介入——外部思考者从其领域提供重构视角或类比,这往往能推动对话向富有成效的方向转变。
  6. 二次与用户确认——在达成结论之前,主持人再次确认:
    • “我们即将得出一些结论。你认为有哪些内容我们尚未涉及?”
    • “这场讨论是否改变了你对该问题的思考方式?” 这让用户有机会在总结阶段前重新引导讨论方向。
  7. 共识确认——主持人梳理:
    • 真正的共识点(所有人都同意的内容)
    • 真正的分歧核心(通常比最初看起来更窄)
    • 每种方案适用的条件(“如果X成立,选择A;如果Y成立,选择B”)
语气指南:
  • 角色应进行实质性辩论,而非仅仅陈述观点。使用证据、示例、类比。
  • 若被说服,允许角色改变立场——这是优质辩论的标志,而非弱点。
  • 主持人应质疑模糊的主张:“你说的‘可扩展’是什么意思?在哪些维度上可扩展?”
  • 保持讨论热烈但尊重。是真正的理性分歧,而非表演式冲突。
  • 与用户对话时,角色应直接真诚——无需奉承或表演。他们是与决策者进行真实对话的专家。

Phase 4: Produce the Output

阶段4:生成输出

After the debate, produce a structured summary. This is what feeds into the planning phase.
Output format:
undefined
辩论结束后,生成结构化总结,这将作为规划阶段的输入。
输出格式:
undefined

Think Tank Summary: [Problem Statement]

智囊团总结:[问题陈述]

Panel

专家团成员

[List panelists and their roles/perspectives]
[列出专家团成员及其角色/视角]

Key Debate Highlights

辩论核心亮点

[2-3 of the most illuminating exchanges or insights from the debate — the moments where something shifted or crystallized. Include moments where user input changed the direction of the discussion.]
[2-3个辩论中最具启发性的交流或见解——即观点发生转变或清晰化的时刻。包括用户输入改变讨论方向的时刻。]

User-Revealed Context

用户透露的背景信息

[Key constraints, preferences, or realities the user shared during the debate that shaped the panel's thinking. This section ensures nothing the user said gets lost.]
[辩论中用户分享的、影响专家团思考的关键约束条件、偏好或实际情况。此部分确保用户的所有发言都不会被遗漏。]

Consensus Points

共识点

[Things all or most panelists agreed on — these are high-confidence inputs to planning]
[所有或大多数专家团成员同意的内容——这些是规划的高可信度输入]

Core Trade-offs

核心权衡因素

[The real axes of disagreement, stated as trade-offs rather than as one side being right]
  • Trade-off 1: [X] vs [Y] — choosing X gives you [...] but costs you [...]
  • Trade-off 2: ...
[真正的分歧核心,以权衡因素而非某一方正确的方式呈现]
  • 权衡因素1:[X] vs [Y]——选择X能带来[...]但会损失[...]
  • 权衡因素2:...

Conditional Recommendations

条件性建议

[Recommendations framed as "if-then" rather than absolutes]
  • If [condition], then [approach] because [reasoning]
  • If [condition], then [approach] because [reasoning]
[以“如果-那么”形式呈现的建议,而非绝对结论]
  • 如果[条件],则选择[方案],因为[理由]
  • 如果[条件],则选择[方案],因为[理由]

Risks & Blind Spots

风险与盲区

[Things the panel identified as under-discussed or easy to overlook]
[专家团指出的讨论不足或容易被忽视的内容]

Open Questions

未解决问题

[Questions that couldn't be resolved in the debate and need more information or experimentation to answer]
[辩论中无法解决、需要更多信息或实验才能回答的问题]

Suggested Next Steps

建议下一步行动

[Concrete actions: things to research, prototype, test, or decide before planning]
undefined
[具体行动:规划前需要研究、原型开发、测试或决策的内容]
undefined

Phase 5: Hand Off to Planning

阶段5:过渡到规划

After presenting the summary, ask the user:
  • "Does this capture the key considerations? Anything missing?"
  • "Which trade-offs feel most important to your specific situation?"
  • "Ready to move into planning with these insights, or should we dig deeper on any point?"
The think tank output should be treated as input to the plan — not as the plan itself. The human makes the decision; the think tank provides the analysis.
呈现总结后,询问用户:
  • “这是否涵盖了关键考量因素?有遗漏吗?”
  • “哪些权衡因素对你的具体情况最重要?”
  • “是否准备好结合这些见解进入规划阶段,还是需要深入讨论某个点?”
智囊团的输出应作为规划的输入,而非规划本身。由人类做出最终决策;智囊团提供分析支持。

Tips for Better Think Tanks

优化智囊团的技巧

  • Prime the context first. If relevant documents, code, or architecture diagrams exist, share them before running the think tank. The personas will give much better input with concrete context.
  • Don't over-specify the panel. Let the LLM suggest some panelists — it often finds relevant experts you wouldn't have thought of.
  • Run multiple rounds if needed. After the first debate, the user might say "I want to dig deeper on the database question." You can reconvene the panel (or a subset) for a focused follow-up.
  • Use the wildcard aggressively. The outside thinker is often where the best insights come from. Don't let them be polite — have them challenge assumptions.
  • The summary is the deliverable. The debate itself is entertaining, but the structured summary is what actually improves planning. Make it sharp and actionable.
  • 先明确背景信息。如果存在相关文档、代码或架构图,在运行智囊团前先分享这些内容。有了具体背景,角色会给出更优质的输入。
  • 不要过度限定专家团。让LLM推荐一些成员——它往往能找到你想不到的相关专家。
  • 必要时运行多轮辩论。第一轮辩论后,用户可能会说“我想深入讨论数据库问题”。你可以重新召集专家团(或其中一部分成员)进行聚焦的后续讨论。
  • 充分利用跨界思考者。外部思考者往往能带来最优质的见解。不要让他们过于客气——让他们挑战假设。
  • 总结是核心交付物。辩论本身很有趣,但结构化总结才是真正能优化规划的内容。要让总结清晰、可行。

Example Test Prompts

测试示例提示词

  • "I need to decide between building a custom auth system or using a third-party service like Auth0. Help me think through this."
  • "We're debating whether to use a relational database or go with a document store for our new product. Can you run a think tank on this?"
  • "Before we plan the migration to Kubernetes, I want to make sure we're not missing anything. Can we get some perspectives on this?"
  • "Should our startup build a mobile app or focus on a responsive web app first?"
  • “我需要决定是构建自定义认证系统还是使用Auth0等第三方服务。帮我梳理一下。”
  • “我们正在讨论新产品是使用关系型数据库还是文档型数据库。你能就此运行一个智囊团吗?”
  • “在规划向Kubernetes迁移之前,我想确保我们没有遗漏任何内容。能获取一些相关视角吗?”
  • “我们的初创公司应该先构建移动应用还是专注于响应式Web应用?”",