experts

专家

围绕一个问题组建一个聚焦的专家小组，并给出由主持人牵头形成的建议。

这是一项面向复杂决策的跨领域专家小组技能。它不局限于某个行业或问题类别，但每个专家席位仍须达到相同的专家级标准。

这项技能首先用于获取专家判断，而不是通用任务路由。

运行模式

• 当用户需要专家建议、多角度评估、第二意见或明确权衡取舍的建议时，使用这项技能。
• 将用户明确调用 $experts 视为许可：在环境支持的情况下，可组建子 Agent 专家小组。
• 优先选择领域专家，而不是通用执行角色。
• 要求每位专家在看到其他专家的结论之前，先独立形成自己的观点。
• 将意见分歧视为有价值的输出，而不是失败。
• 让最终回答聚焦于判断、理由、权衡取舍和适用边界。
• 当环境支持子 Agent 和并行委派时，优先采用真正的多专家执行方式，并在安全的情况下并行收集独立意见。
• 当环境不支持子 Agent 或并行委派时，在单个线程中模拟相同的小组结构：先明确区分各专家观点，再进行综合。
• 不要仅仅因为执行是在单线程中进行，就把小组意见合并成一个笼统的回答。

资源映射

先阅读 references/roles-index.md。然后仅加载与问题匹配的专家卡片。

常见专家卡片：

• references/role-chair.md
• references/role-architect.md
• references/role-frontend-expert.md
• references/role-backend-expert.md
• references/role-product-expert.md
• references/role-security-expert.md
• references/role-privacy-expert.md
• references/role-performance-expert.md
• references/role-data-expert.md
• references/role-devops-expert.md
• references/role-platform-expert.md
• references/role-mobile-expert.md
• references/role-search-expert.md
• references/role-payments-expert.md
• references/role-compliance-expert.md
• references/role-ml-expert.md
• references/role-itinerary-expert.md
• references/role-budget-travel-expert.md
• references/role-travel-risk-expert.md
• references/role-family-travel-expert.md
• references/role-local-transport-expert.md
• references/role-experience-curator.md
• references/role-destination-culture-expert.md
• references/role-information-discovery-expert.md
• references/role-source-verification-expert.md
• references/role-recency-expert.md
• references/role-coverage-analyst.md
• references/role-signal-vs-noise-analyst.md
• references/role-qa-expert.md
• references/example-platform-modernization-panel.md
• references/example-analytics-dashboard-panel.md
• references/example-subscription-billing-panel.md
• references/example-ai-assistant-panel.md
• references/example-task-local-identity-panel.md
• references/example-family-japan-panel.md
• references/example-istanbul-culture-panel.md
• references/example-ai-release-watch-panel.md
• references/example-acquisition-rumor-panel.md
• references/task-local-expert-template.md

仅在需要高质量参考、了解专业专家组输出应有的样式时，才阅读示例。

专家组模式

组建专家组前，选择一种模式：

• advisory：仅提供专家判断和建议
• decision-support：提供建议以及具体的后续步骤计划
• deep-dive：通过收集更多证据，对复杂问题进行调查后再给出建议

除非用户要求制定执行计划或进行更深入的分析，否则默认使用 advisory。

工作流

除非用户要求范围更窄的交付内容，否则请按以下顺序执行。

1. 明确问题

提取并重述：

• 需要评估的确切问题
• 期望作出的决策或产出的结果
• 已知的约束、假设和审批情况
• 相关代码、文档、系统或制品
• 时间敏感性
• 评审小组模式

组建评审小组之前，先将模糊请求转化为明确的评估问题。

2. 选择评审小组成员

选择一个小型评审小组，由一名 chair 和两至六名专家组成。

选择与实际决策范围相匹配的专家。优先考虑不同视角，而不是增加人数。

如果 references/roles-index.md 中的角色卡适用，请优先使用。如果没有完全匹配的角色卡，则综合出一名任务专属专家，明确命名其专业视角和职责范围。

2a. 必要时综合任务专属专家

只有当角色库未覆盖某个实际决策视角时，才创建任务专属专家。

任务专属专家必须：

• 代表真正的专家学科，而非临时拼凑的职位名称
• 具有范围明确且站得住脚的专业视角
• 可能因实质性理由与至少一名其他专家意见相左
• 提供现有角色卡无法妥善涵盖的决策价值

不要创建虚构的细分席位，例如：

• 以功能名称命名的专家
• 以实施步骤命名的专家
• 泛化的“智能审查员”变体
• 仅仅换种说法重复其他角色卡内容的专家

创建任务专属专家时，请阅读 references/task-local-expert-template.md 并定义：

• 专家名称
• 专业视角
• 决策范围
• 所需证据
• 核心评估标准
• 关键未知因素
• 否决条件
• 明确的非目标，以及与相近专家的职责边界

任务专属专家仅对当前评审小组有效，除非用户明确要求将其纳入角色库。

3. 收集独立意见

请每位专家独立评估问题。

每份意见应涵盖：

• 核心判断
• 证据依据，以及哪些内容是推断、哪些是直接观察所得
• 信心水平，以及该信心水平的主要原因
• 推理过程和假设
• 首选方案
• 主要风险
• 可能改变建议的关键未知因素
• 会促使专家改变立场的决策门槛
• 专家会否决的事项及原因

不要过早让专家受彼此意见影响。

如果专家并行工作，应先分别收集意见，再进行交叉质询。

如果专家在同一线程中工作，也要保持输出结构彼此独立：

• 分别撰写每位专家的部分
• 不要让后续专家悄然沿用先前的结论
• 即使同一个 Agent 模拟多个席位，也要保留分歧

4. 进行交叉质询

收集独立意见后，请专家相互质疑。

重点关注：

• 隐含假设
• 被低估的成本
• 被忽视的故障模式
• 优先事项上的分歧
• 其他专家在哪些条件下可能是对的

此阶段应以证据为依据，并保持简洁。

5. 提交主席建议

由 chair 综合评审小组意见，形成可直接用于决策的结果。

返回：

• 问题
• 最终评审小组成员
• 每位专家的核心观点
• 支撑各观点的证据和信心情况
• 共识点
• 分歧点
• 建议方案
• 权衡与风险
• 建议适用或不适用的边界

用户要求继续推进时，请在建议之后附上简短的后续步骤计划。除非用户明确要求，否则不要将报告扩展为完整的执行手册。

专家标准

对每位专家应用以下规则：

• 以所分配视角下资历最深的专家身份行事。
• 严谨、具体，并严格限定讨论范围。
• 优先采用有依据的推理，而非自信的语气。
• 区分观察到的事实、推断和猜测。
• 说明置信度，以及哪些因素会提高或降低置信度。
• 明确说明假设。
• 指出妨碍提出更有力建议的关键未知因素。
• 说明否决条件，而不只是偏好的结果。
• 对薄弱的表述、虚假的二选一和缺乏依据的主张提出质疑。
• 以帮助用户做出更好的决策为目标，而非争胜。

选择规则

• 优先选择能够揭示实质性权衡的最小专家组。
• 优先选择领域专家，而非泛泛的评审者。
• 只有在领域视角不足以应对时，才增加角色专家。
• 避免纳入视角相同、职责重复的专家。
• 只有当决策确实涉及跨职能风险时，才扩大专家组。
• 如果问题范围狭窄，某位专家会占据主导，则减少专家人数并明确说明原因。

输出结构

返回专家组结果时，使用以下结构：

# Expert Panel Report

## Question
- <the decision or problem being assessed>

## Decision Criteria
- <which evaluation axes matter most in this panel>
- <which constraints are primary versus secondary>

## Panel
- chair: <why this chair is appropriate>
- <expert>: <perspective and remit>

## Expert Opinions
- <expert>: <core judgment, rationale, major risks>
- evidence: <what is known, what is inferred>
- evidence quality: <direct evidence | indirect evidence | expert inference>
- confidence: <high | medium | low> and why
- critical unknowns: <what could still change the answer>
- reject conditions: <what would make this expert reject a path>

## Agreement
- <shared conclusions>

## Disagreement
- <meaningful differences in view or priorities>

## Recommendation
- recommended path: <best option>
- why: <main justification>

## Tradeoffs
- <what is gained and what is given up>

## Minority View
- <which dissenting view did not win>
- <under what conditions that view becomes stronger>

## Confidence and Unknowns
- <where the panel is confident>
- <where the panel is still reasoning under uncertainty>

## Immediate Implications
- <what should be decided, validated, or sequenced next if this recommendation is accepted>
- <what signal should trigger re-evaluation of the panel's conclusion>

## Boundaries
- holds when: <conditions where this advice fits>
- avoid when: <conditions where this advice should not be followed>

决策规则

• 优先明确说明权衡，而非给出含糊的最佳实践。
• 优先提出符合用户实际限制的建议，而非理想化环境中的建议。
• 证据不完整时，说明不确定性。
• 如果少数意见会实质性影响风险，则予以保留。
• 将建议质量与实施难度分开说明。
• 如果专家组缺少必要视角，则指出并相应调整专家组后再作结论。

风险信号

出现以下情况时，应停止并重新评估：

• 问题仍然过于模糊，无法判断
• 专家组包含视角重叠、没有明确分工的专家
• 专家用不同措辞重复相同观点
• 建议掩盖了尚未解决的分歧
• 证据过于薄弱，无法得出可信结论
• 用户要求实施方案，但专家组只给出了建议