Advanced Elicitation — 结构化深度追问
概述
对任何产出（方案/代码/文档/决策/分析）进行结构化深度审视。不是泛泛的"再看看"，而是从69种具体方法中选择最匹配的5种，逐一应用，层层推进。
核心原则：产出不是终点——深度审视是质量的门禁。
触发条件
通用领域触发矩阵
69种方法覆盖7大领域，68个子场景。AE根据内容类型自动选5种最匹配方法。
AI / 大模型 / 智能体
| 场景 |
触发信号 |
示例 |
| 模型选型审视 |
用户对比多个模型/框架 |
"从不同角度审视 GPT vs Claude vs DeepSeek 的选型" |
| Agent架构审查 |
用户有多Agent系统需要安全性评估 |
"多Agent编排的风险在哪，red team一下" |
| Prompt工程审核 |
用户有prompt链需要审查 |
"这套prompt chain从对抗角度审查" |
| AI输出质量门禁 |
用户有AI生成内容需要多视角验证 |
"这篇AI生成的方案过一下审视" |
| AI产品风险评估 |
用户有AI产品方案需要风险分析 |
"这个AI应用上线前做pre-mortem" |
产品 / 商业
| 场景 |
触发信号 |
示例 |
| 产品方案审视 |
用户有PRD/产品方案需要批判性审视 |
"审视这个PRD，从客户/投资人/竞品三个角度" |
| 商业决策审查 |
用户有重大商业决策需要风险分析 |
"这个定价决策，做二阶效应和pre-mortem" |
| 市场策略审视 |
用户有营销策略需要多视角 |
"这个增长策略，从6顶帽子角度审视" |
| 竞品分析验证 |
用户有竞品分析需要验证严谨性 |
"这个竞品分析的假设有没有漏洞" |
| 用户研究审视 |
用户有用户研究报告需要质疑 |
"这些用户洞察的假设基础牢固吗" |
企业管理 / 战略
| 场景 |
触发信号 |
示例 |
| 战略规划审视 |
用户有年度战略/OKR需要审查 |
"6 Hats审一下这个战略规划" |
| 组织变革审查 |
用户有组织变革方案需要风险评估 |
"这个改组方案做pre-mortem" |
| 项目复盘深度审视 |
用户有复盘报告需要深挖根因 |
"5 Whys深挖这个项目为什么延期三次" |
| 资源分配决策 |
用户有预算/人力资源分配需要审查 |
"这个资源分配的假设审计一下" |
| 运营流程审视 |
用户有SOP需要检查盲区 |
"这个流程有哪些单点故障" |
学术 / 研究
| 场景 |
触发信号 |
示例 |
| 论文批判审视 |
用户有学术论文需要多角度审视 |
"像答辩委员会一样审视这篇论文" |
| 研究方法论审查 |
用户有研究方法需要验证 |
"这个实验设计的假设审计和三角验证" |
| 概念深度审视 |
用户有核心概念需要多角度理解 |
"First Principles审视'智能'的定义" |
| 文献综述验证 |
用户有文献综述需要质量审查 |
"这些文献来源三角验证一下" |
| 理论框架审视 |
用户有理论框架需要挑战 |
"Socratic Questioning挑战这个理论" |
内容 / 创作
| 场景 |
触发信号 |
示例 |
| 文案多角度审视 |
用户有文案需要挑战和改进 |
"SCAMPER这个产品文案的7种写法" |
| 创意方案评判 |
用户有创意方案需要多视角 |
"这个品牌方案做客户视角+竞品视角+内部视角" |
| 写作质量审视 |
用户有长文需要批判性审视 |
"审视这篇文章的逻辑链和叙事说服力" |
| 设计决策审视 |
用户有设计稿需要审查 |
"这个界面设计从易用性/可访问性/一致性审视" |
| 视频脚本审视 |
用户有视频脚本需要多视角 |
"pre-mortem这个脚本 — 观众看完会有什么反应" |
安全 / 合规
| 场景 |
触发信号 |
示例 |
| 安全架构审计 |
用户有系统需要安全审查 |
"红蓝对抗审一下这个系统" |
| 合规方案审查 |
用户有合规方案需要验证 |
"这个数据合规方案的假设全列出来压力测试" |
| 隐私设计审视 |
用户有数据处理方案需要审查 |
"从用户视角+监管视角+黑客视角审视" |
| 灾难恢复验证 |
用户有灾备方案需要测试韧性 |
"Chaos Monkey破坏一下看哪里先崩" |
| API安全审查 |
用户有API设计需要安全审视 |
"Boundary Sweep这个API的所有参数" |
技术 / 架构
| 场景 |
触发信号 |
示例 |
| 架构决策审视 |
用户有架构决策需要多角度审查 |
"Architecture Decision Record从不同阵营辩论" |
| 性能问题诊断 |
用户有性能瓶颈需要多角色诊断 |
"性能面板审查：数据库+前端+DevOps三视角" |
| 代码质量审视 |
用户有代码需要多角度审查 |
"Code Review Gauntlet：从不同哲学审查同一段代码" |
| 技术方案评审 |
用户有技术方案需要风险审查 |
"这个技术方案做Failure Mode Analysis" |
| 技术债评估 |
用户有技术债清单需要优先级判断 |
"这个技术债清单做Cascading Failure模拟" |
自动触发（产生产出后主动建议）
- answer Phase 7 Review 完成 → 建议运行 AE 做多视角审视
- 完成复杂决策/方案/架构 → 建议至少运行1-2轮
- feishu-html 页面交付前 → 建议运行 AE 做设计决策审视
- 产出涉及多学科交叉 → 自动根据内容类型路由到对应领域
手动触发
- "深度审视这个方案"
- "换个角度看看"
- "追问到底"
- "push deeper on this"
- "challenge this"
- "red team this"
- "second opinion on this"
- "质疑这个结论"
- "挑挑刺"
不触发
- 简单事实查询
- 已有明确答案的问题
- 用户明确表示"不需要"
方法库（69种，按类别）
高级推理 (8)
| # |
方法 |
描述 |
流程 |
| 1 |
Tree of Thoughts |
探索多条推理路径后评估选择 |
路径→评估→选择 |
| 2 |
Graph of Thoughts |
建模为互联思想网络揭示隐藏关系 |
节点→连接→模式 |
| 3 |
Thread of Thought |
编织连续叙事线索保持跨长上下文一致 |
上下文→线索→合成 |
| 4 |
Self-Consistency Validation |
多独立方案对比一致性 |
方案→对比→共识 |
| 5 |
Meta-Prompting Analysis |
退一步分析方法论本身 |
现状→分析→优化 |
| 6 |
Reasoning via Planning |
构建世界模型引导的推理树 |
模型→规划→策略 |
| 7 |
Chain-of-Thought Scaffolding |
强制显式中间推理步骤 |
前提→步骤→结论 |
| 8 |
Few-Shot Exemplar Priming |
提供2-3个工作示例对齐输出格式 |
示例→模式识别→应用 |
核心方法 (11)
| # |
方法 |
描述 |
流程 |
| 24 |
First Principles Analysis |
剥离假设从基本真理重建 |
假设→真理→新方法 |
| 25 |
5 Whys Deep Dive |
反复追问钻到根因 |
why链→根因→方案 |
| 26 |
Socratic Questioning |
用定向问题揭示隐藏假设 |
问题→揭示→理解 |
| 27 |
Critique and Refine |
系统识别优劣后改进 |
优劣→改进→精炼 |
| 28 |
Explain Reasoning |
逐步展示思维过程 |
步骤→逻辑→结论 |
| 29 |
Expand or Contract for Audience |
为目标受众动态调整深度 |
受众→调整→精炼 |
| 30 |
Second-Order Thinking |
超越直接后果预判连锁效应 |
行动→后果→二阶→选择 |
| 31 |
Inversion Analysis |
翻转问题：如何保证失败？ |
目标→反转→失败路径→规避 |
| 32 |
Problem Decomposition |
拆解为独立子问题逐解决 |
整体→部分→方案→重组 |
| 33 |
Analogy Mapping |
找到熟悉的平行领域迁移结构 |
源域→映射→目标洞见 |
| 34 |
Steelmanning |
构建对方最强论证再回应 |
对立→最强形式→诚实反驳 |
风险分析 (7)
| # |
方法 |
描述 |
流程 |
| 57 |
Pre-mortem Analysis |
想象未来失败倒推预防 |
失败→原因→预防 |
| 58 |
Failure Mode Analysis |
系统探索每个组件如何失败 |
组件→失败→预防 |
| 59 |
Challenge from Critical Perspective |
扮魔鬼代言人找弱点 |
假设→挑战→加强 |
| 60 |
Identify Potential Risks |
全类别头脑风暴风险 |
类别→风险→缓解 |
| 61 |
Chaos Monkey Scenarios |
故意破坏测试韧性 |
破坏→观察→加固 |
| 62 |
Assumption Audit |
列出所有假设评级后压力测试 |
列表→评级→测试→加固 |
| 63 |
Cascading Failure Simulation |
跟踪单组件失败如何传播 |
触发→传播→放大器→解耦 |
协作模式 (11)
| # |
方法 |
描述 |
流程 |
| 9 |
Stakeholder Round Table |
多角色贡献多元视角 |
视角→合成→对齐 |
| 10 |
Expert Panel Review |
领域专家深度分析 |
专家→共识→建议 |
| 11 |
Debate Club Showdown |
两方辩论+裁判评分 |
论点→反论→合题 |
| 12 |
User Persona Focus Group |
用户角色反馈提案 |
反应→关切→优先级 |
| 13 |
Time Traveler Council |
过去的你和未来的你建议现在的你 |
过去→现在→未来 |
| 14 |
Cross-Functional War Room |
PM+工程师+设计师共解 |
约束→权衡→方案 |
| 15 |
Mentor and Apprentice |
高级教初级问天真的问题 |
解释→问题→更深理解 |
| 16 |
Good Cop Bad Cop |
好人坏人交替审查 |
鼓励→批评→平衡 |
| 17 |
Improv Yes-And |
多人接力构建不阻塞 |
想法→构建→惊喜 |
| 18 |
Customer Support Theater |
愤怒客户+客服揭露痛点 |
投诉→调查→解决 |
| 19 |
Six Thinking Hats |
6种模式轮转(事实/情感/谨慎/乐观/创意/流程) |
白→红→黑→黄→绿→蓝 |
| 20 |
Delphi Method |
专家独立估计→匿名结果→修订→收敛 |
独立→揭示→修订→收敛 |
创造性 (7)
| # |
方法 |
描述 |
流程 |
| 35 |
SCAMPER Method |
7种创意镜头(替代/组合/适应/修改/他用/消除/反转) |
S→C→A→M→P→E→R |
| 36 |
Reverse Engineering |
从期望结果倒推实现路径 |
终点→倒推→路径 |
| 37 |
What If Scenarios |
探索替代现实的后果 |
场景→影响→洞见 |
| 38 |
Random Input Stimulus |
注入无关概念激发意外连接 |
随机→关联→新想法 |
| 39 |
Exquisite Corpse Brainstorm |
每人只看到前一个贡献继续构建 |
贡献→传递→惊喜 |
| 40 |
Genre Mashup |
组合不相关领域找新方法 |
域A+域B→混合洞见 |
| 41 |
Constraint Injection |
故意添加限制(budget/time/tech)强制创新 |
加约束→创造力→评估 |
| 42 |
Morphological Analysis |
参数独立选项枚举后系统组合 |
参数→网格→组合→评估 |
框架重构 (3)
| # |
方法 |
描述 |
流程 |
| 43 |
Abstraction Laddering |
上移(为什么)或下移(怎么做)找正确层次 |
具体↔抽象→正确层次 |
| 44 |
Reframe the Question |
质疑当前问题是否是真正问题 |
陈述→重构→真问题→方案 |
| 45 |
Stakeholder Lens Rotation |
轮流采纳每个利益相关者视角 |
视角A→B→C→发现缺口 |
竞争对抗 (3)
| # |
方法 |
描述 |
流程 |
| 21 |
Red Team vs Blue Team |
对抗攻防分析找漏洞 |
防御→攻击→加固 |
| 22 |
Shark Tank Pitch |
创业者向挑剔投资人推销 |
提案→挑战→精炼 |
| 23 |
Code Review Gauntlet |
不同哲学的高级开发者审查同一代码 |
审查→辩论→标准 |
学习验证 (3)
| # |
方法 |
描述 |
流程 |
| 46 |
Feynman Technique |
像教孩子那样简化解释复杂概念 |
复杂→简化→缺口→掌握 |
| 47 |
Active Recall Testing |
不用参考测试理解 |
测试→缺口→强化 |
| 48 |
Deliberate Practice Loop |
识别子技能→训练→反馈→调整→重复 |
隔离→训练→反馈→调整 |
哲学/伦理 (2)
| # |
方法 |
描述 |
流程 |
| 49 |
Occam's Razor Application |
找最简单充分解释消除不必要复杂 |
选项→简化→选择 |
| 50 |
Trolley Problem Variations |
通过道德困境探索价值权衡 |
困境→分析→决策 |
研究分析 (3)
| # |
方法 |
描述 |
流程 |
| 51 |
Literature Review Personas |
乐观+怀疑+综合研究者评估证据 |
来源→批评→合成 |
| 52 |
Thesis Defense Simulation |
学生向委员会辩护假设 |
论点→挑战→辩护→精炼 |
| 53 |
Comparative Analysis Matrix |
多分析师对选项评分 |
选项→标准→分数→建议 |
| 54 |
Source Triangulation |
至少三种独立来源(定量/定性/专家)确认才接受 |
断言→源A→源B→源C→置信度 |
回顾反思 (2)
| # |
方法 |
描述 |
流程 |
| 55 |
Hindsight Reflection |
想象从未来回看获取视角 |
未来→洞见→应用 |
| 56 |
Lessons Learned Extraction |
系统提取关键教训和可行改进 |
经验→教训→行动 |
技术审查 (5)
| # |
方法 |
描述 |
流程 |
| 64 |
Architecture Decision Records |
多个架构师提案辩论架构选择 |
选项→权衡→决策→理由 |
| 65 |
Rubber Duck Debugging Evolved |
向越来越技术化的鸭子解释代码直到找到bug |
简单→详细→技术→aha |
| 66 |
Algorithm Olympics |
多个方案同台竞技比基准 |
实现→基准→胜者 |
| 67 |
Security Audit Personas |
黑客+防御者+审计员多角度审查 |
漏洞→防御→合规 |
| 68 |
Performance Profiler Panel |
数据库+前端+DevOps专家诊断慢速 |
症状→分析→优化 |
| 69 |
Boundary & Edge Case Sweep |
系统测试极端值/零/空/最大/类型不匹配 |
输入→边界→边缘→失败 |
主流程
Step 1: 接收内容 + 分析上下文
接收待审视的内容。分析：
- 内容类型（方案/代码/文档/决策/架构/报告）
- 复杂度（简单/中等/复杂）
- 风险级别（低/中/高）
- 受众（内部/客户/公开）
Step 2: 智能选择 5 种方法
从69种方法中选择5种最匹配当前内容类型的方法：
- 方案/决策类 → 优先 Risk + Core 方法
- 代码/技术类 → 优先 Technical + Core 方法
- 文案/内容类 → 优先 Creative + Core 方法
- 架构/策略类 → 优先 Framing + Core + Risk 方法
平衡搭配：1-2个核心方法 + 1-2个专项方法 + 1个创造性/框架方法。
Step 3: 展示选项
**深度审视选项**
选择编号 (1-5), [r] 换一批, [a] 查看全部69种, [x] 完成:
1. {方法名} — {一句话描述}
2. {方法名} — {一句话描述}
3. {方法名} — {一句话描述}
4. {方法名} — {一句话描述}
5. {方法名} — {一句话描述}
Step 4: 执行选中方法
用户选择编号 → 基于方法的描述执行深度审视 → 展示该方法揭示的问题/改进 → 询问是否应用改动 → 返回选项菜单。
应用改动：仅在用户明确说"应用"时修改内容。默认只观察不修改。
Step 5: 迭代直到用户说 [x]
每次执行完一个方法后重新展示5个选项（保留上轮最有价值的+替换新的）。用户说 [x] 时输出本轮审视摘要。
与 Hermes 技能的集成
被 answer Phase 7 调用
加载 advanced-elicitation，对 Review 中发现的 Must Fix / Should Fix 项逐一运行 2-3 种方法做深度审视。
被 travel-intel 综合洞察调用
加载 advanced-elicitation，对本周关键竞品动态运行 Pre-mortem + Stakeholder Lens + Inversion。
被 feishu-html 阶段一B 调用
加载 advanced-elicitation，对设计决策树的关键分支运行 Reframe + First Principles + What If。
约束
- 每次最多选5种方法建议，避免选择瘫痪
- 每次执行一种方法后返回到选项菜单（除非用户连续输入多个编号）
- 不主动修改内容，只提出问题/建议
- 如果产出本身质量很高（无明显问题），诚实说"此内容通过了{方法名}审视——无新发现"
- 69种方法不必全部展示给用户——只展示选出的5种。用户说 [a] 时才展开完整列表
常见陷阱
- 一次跑太多方法 → 每次最多执行1-2种再返回菜单
- 方法选择不匹配内容类型 → 代码内容用创意方法会浪费时间
- 替代执行而非审视 → 不是用新方法重做，是用新视角审视已有产出
- 跳过用户确认直接修改 → 永远等用户说"应用"才改
验证清单
jorinyang