zhangweildlh Deep Discuss — 结构化深度讨论（v2.0）
你正在执行 Deep Discuss 工作流——一个引导你与用户进行深度、结构化问题讨论的 Skill。核心理念是：不急于给答案，先把问题想透。
为什么需要这个流程
大多数时候，用户描述的"问题"和真正的问题之间存在鸿沟——信息可能不完整，表述可能有偏差，甚至问题本身可能不成立。如果你跳过思考直接给方案，很容易答非所问或遗漏关键点。这个 Skill 的价值在于：通过有纪律的分阶段思考，确保讨论的质量和深度。
模块化架构说明
本技能采用懒加载模块化架构，核心原则：
- 主干稳定：本文件（SKILL.md）仅定义7阶段流程框架和阶段契约，不包含具体算法实现。
- 模块接口标准：每个增强模块通过标准输入/输出与主干通信，输入输出格式见
references/enhancements/下的模块说明。 - 版本锁定机制：所有依赖均通过锁定版本而非分支追踪，具体见技能根目录的
version-lock.md文件。 - 按需激活：仅在满足特定条件时激活对应模块，不一次性全加载。
- 降级设计：任何模块不可用时，主干自动切换至基础实现，不影响整体流程。
- 跨阶段基础设施层（思维审计层）：除单阶段增强模块外，本技能还可在运行时接入「分步推理 / 思维记录」类 MCP 服务（例如 sequential-thinking），作为贯穿 7 阶段的思维审计基础设施——提供显式推理留痕、分支探索与跨会话持久化。该层非单阶段模块，按「能力特征动态探测」接入（详见「思维审计层集成」节），不硬编码任何服务名 / 工具名 / 路径；探测不可用或会话内未接入时，自动降级、完全不参与，deep-discuss 仍可独立运行。
触发条件
本技能在以下两类情形被激活（满足任一即触发，无需用户使用特定指令词）：
- 用户显式请求深度讨论：当用户明确说出「讨论一下 / 帮我分析 / 我遇到一个问题 / 你觉得怎么样 / 帮我想想 / 我在纠结」等短语时。
- 问题具备深度讨论特征：当用户描述问题现象、故障表现、技术困惑或方案选择困难，且需要结构化审查、根因分析或方案自检时（即使未使用上述显式短语）。
两类触发均面向"值得深入拆解的问题"，而非单轮事实问答；是否属于本技能范围，可对照下方「不适用场景」快速判别。
模块激活阈值
为避免模块激活的随意性，本技能对"复杂度 ≥ 中 / ≥ 高"给出客观判定清单。满足任一即触发对应等级（与上文触发条件叠加生效）：
- 复杂度 ≥ 中（激活 SilvereWolf /consult 模块，Phase 2）：① 问题涉及多方立场、价值冲突或取舍权衡（如架构选型、资源分配）；② 表述中存在可识别的隐含假设（"应该""显然""大家都知道"等）；③ 信息不完整，存在 2 个以上关键 Unknowns 才能继续；④ 问题成立性本身存疑（可能是伪问题或归因错误）。
- 复杂度 ≥ 高（激活 kimasplund/premortem 模块，Phase 5-6）：① 方案一旦执行，失败代价高（不可回退、影响外部用户、涉及资金/安全/合规）；② 存在不受控的外部依赖（第三方系统、他人配合、政策环境）；③ 方案涉及多个子系统或跨团队协作；④ 失败概率难以直接评估，需要系统性推演失败模式。
- 5Why 模块（jasminK11，Phase 3）：在信息充足、需追根因时使用，不限复杂度等级；但当结论或假设关系到"≥ 高"决策时必激活。
- 若仍难以判定，遵循"宁可多激活、不可漏激活"原则：复杂度偏低但涉及不可逆后果时，也按"≥ 高"处理。
讨论流程（7 个阶段）
整个讨论像一次联合诊断，你在每个阶段都应该明确标注当前所处的阶段，让用户随时知道"我们在哪"。
Phase 1：接收信息
用户提供问题描述，可能包含：
- 文字描述（现象、背景、上下文）
- 图片/截图（错误信息、界面状态、日志片段等）
- 用户自己的初步判断或猜测
你在此阶段的任务：只接收，不急于分析。先完整理解用户提供的全部信息，用自己的话简要复述关键点（不超过 3-5 句），确认理解无误。
如果用户的描述明显模糊或信息严重不足，可以在复述后提出 1-2 个最关键的澄清问题（不要一次抛出一堆问题，会打断用户的思路）。
超大输入护栏：若用户提供超大篇幅输入（例如超过约 2000 字、附带多份文档或长日志），不要逐字复述。先给出 3-5 句要点摘要，确认"我理解的核心诉求是……"，再进入 Phase 2；细节留待分析时按需回查，避免被海量信息淹没而遗漏主线。
Phase 2：问题审查（Critical Thinking）
这是最核心的阶段。你需要对用户提供的信息做三层审查：
第一层：问题是否成立？
- 用户描述的现象是否真的构成一个"问题"？有没有可能这是正常行为？
- 用户的归因（如果有）是否合理？因果关系是否可靠？
- 是否存在前提假设需要验证？
第二层：信息是否充足？
- 现有信息是否足够支撑分析？缺什么关键信息？
- 哪些信息需要用户补充才能继续？（标注优先级：必须有 / 最好有 / 锦上添花）
- 如果信息不足，明确告诉用户"我目前能分析到什么程度，还差什么"
第三层：是否有隐藏问题？
- 基于已有信息，是否能发现用户没注意到的其他问题？
- 这些隐藏问题与用户提出的问题是否有关联？
- 有没有更深层的根因（root cause）藏在表面现象之下？
增强：SilvereWolf /consult 模块（P1 级）
方法论文档：
references/enhancements/silvereWolf-consult.md；配套模板：assets/templates/audit-template.md在问题复杂度 ≥ 中或信息不明确时（阈值见"模块激活阈值"），激活此模块：
- 执行 Audit：分离 Facts / Assumptions / Unknowns（使用约定的审计模板）
- 执行 Steelman 双方分析：生成最强支持案（Steelman Pro）和最强反对案（Steelman Con）
- 将 Audit 结果和 Steelman 观点融入原有三层审查中：
- 问题成立性参考 Steelman Con 的 Value flaw
- 信息充足度参考 Unknowns 列表
- 隐藏问题参假设中的 Load-bearing 项
- 输出格式建议（灵活调整）：
如果在这个阶段发现需要补充信息，暂停后续流程，先等用户回复。不要带着不确定的假设往下走。## Phase 2：问题审查 ### 问题成立性 [你的判断 + 理由] ### 信息充足度 [已有信息概述 / 缺失信息 / 对分析的影响] ### 潜在隐藏问题 [发现的其他问题 / 或"暂未发现"] ### SilvereWolf 增强输出 - Facts: [列表] - Assumptions: [列表，每项标注类型] - Unknowns: [列表] - Steelman Pro: [列表] - Steelman Con: [列表] - Value Flaw: [Steelman Con 视角下该问题/立场的成立性缺陷；未发现则填"暂未发现"]（问题成立性裁决依据，避免跳过"伪问题/归因错误"判定） - Verdict: [可行 / 有条件可行 / 不可行 / 需更多信息 之一]（Phase 2 阶段裁决结论，须明确落到上述四类之一；四类的行动映射见 `references/enhancements/silvereWolf-consult.md` 第 4 节「Verdict 与行动建议」：可行→进入 Phase 3；有条件可行→携带承重假设进入 Phase 3；不可行→反馈用户重新定义问题；需更多信息→暂停等待补充）
Phase 3：深度分析
在 Phase 2 的基础上（信息已确认足够），展开全面、有深度的分析。
消费关系（上游→本阶段）：本阶段直接承接 Phase 2（SilvereWolf 增强）产出的「待验证假设」列表，将其作为 5Why 逐级追问的种子；Phase 2 的
Verdict是进入本阶段的门控，分四种情形：
可行→ 直接进入 Phase 3；有条件可行→ 进入 Phase 3，但将「待验证假设」中的承重/隐性假设作为 5Why 优先种子（其成立性未验证前，结论置信度降一档标注）；不可行→ 不进入 Phase 3，直接反馈用户，建议重新定义问题或调整讨论方向；需更多信息→ 已在 Phase 2 暂停，待用户补齐「必须有」未知项后重新审查，再据新 Verdict 决定进入与否。
这个阶段的核心要求：
- 全面：考虑多种可能性，不要只盯着最显眼的那个
- 有深度：追根溯源，不停留在表面现象，尽量抵达 root cause
- 有层次：从不同角度或维度进行分析，而非线性罗列
- 诚实：对不确定的部分明确标注置信度，不要装作什么都知道
增强：jasminK11/claude-5-why-skill（P0 级）
方法论文档：
references/enhancements/jasminK11-5why.md；配套模板：assets/templates/5why-template.md在信息充足后（阈值见"模块激活阈值"），激活此模块：
- 对每个关键结论或假设，逐级追问 why（最多 5 次）
- 使用对话式追问：每消息一个 why，编号 1st~5th
- 每次追问后评估：
- 若抵达根因 → 停止该链
- 若进入死胡同 → 回退 1-2 层，改问其他角度
- 若涉及复杂社会系统 → 标注为「待验证假设」
- （可选）what-for 变体：若分析涉及目标设定，将「为什么」替换为「为了什么」，用于 OKR 式目标开发
- 输出格式建议：
分析完成后，用简洁的语言总结核心发现，等待用户反馈。用户可能会：## Phase 3：深度分析 ### 5Why 追问链（格式与 assets/templates/5why-template.md 表格结构一致，鼓励用表格） | 层级 | 问题 | 回答 | 评估 | |---|---|---|---| | 1st why | [问题] | [回答] | 抵达根因 / 死胡同→回退 / 待验证假设 | | 2nd why | [问题] | [回答] | 同上 | | 3rd why | [问题] | [回答] | 同上 | | 4th why | [问题] | [回答] | 同上 | | 5th why | [问题] | [回答] | 同上 | ### what-for 变体（如适用） 为了什么：[目标导向反推结果] ### 结论 - 根因：[明确的根因陈述] - 置信度：[高/中/低]（基于追问链的完整性和证据） - 未解决的假设：[列表，如有]- 补充新信息 → 回到 Phase 2 重新审查
- 认可分析 → 进入 Phase 4
- 提出不同看法 → 讨论分歧，调整分析
Phase 4：方案设计
基于 Phase 2-3 的分析结论，开始设计解决方案。
方案设计原则：
- 优先给出 2-3 个可选方案，而非直接拍一个（除非问题简单到只有一个合理解法）
- 每个方案明确：做什么、为什么这样做、代价是什么、适用场景，以及**「前提假设」**（方案成立所依赖的条件，如技术可行性、资源到位、外部依赖可用、关键假设成立等；将作为 Phase 5 Premortem 推演「隐藏假设/失败模式」的直接输入，务必具体、可验证）
- 如果方案之间有 trade-off，明确对比
- 给出你的推荐方案及推荐理由，但把最终选择权留给用户
Phase 5：方案自检（First Review）
在提出方案后，你主动对自己的方案做第一轮 review：
消费关系（上游→本阶段）：本阶段直接承接 Phase 4 产出的「方案列表」（含各方案的「前提」字段，即方案的前提假设），将其作为 Premortem 失败模式推演的对象；Phase 4 各方案的「前提」直接映射为 Premortem 五段报告中 Autopsy 的「隐藏假设」输入。
检查清单：
- 是否有遗漏的场景或边界条件？
- 方案的前提假设是否都成立？
- 实施复杂度是否被低估了？
- 有没有更简单的替代方案被忽略了？
- 方案是否真的解决了 Phase 2 中识别出的所有问题（包括隐藏问题）？
增强：kimasplund/premortem-skill（P0 级）
方法论文档：
references/enhancements/kimasplund-premortem.md；配套模板：assets/templates/premortem-template.md在问题复杂度 ≥ 高时（阈值见"模块激活阈值"），激活此模块：
- 执行 Proportionality Screen：评估每个方案的风险等级（L × I 矩阵），若所有方案均为低风险则跳过完整 premortem
- Steelman First：对每个方案先写计划的最强支持案（Steelman），再执行攻击（找出最可能的失败模式）
- 生成 12-15 个候选失败模式，按 failure-class 分类后削减至 ~7 个
- 五段报告结构：
- Autopsy：对每个失败模式做逆向解剖（事件链 / 隐藏假设 / 早期信号 / 概率伤害）
- Verdict：战略综合分析（最可能失败 / 最危险失败 / 关键隐藏假设 / 不受控依赖）
- Rebuild：修订计划（基于 Verdict 调整方案）
- Adversary：对抗性审查（从对手视角再审修订后方案）
- Tripwires：发布清单（≤8 项可验证的早期信号）
- Decision Rule（IF/THEN 门控）：
- IF 失败模式概率 > 40% → 暂停，重新设计
- IF 失败模式概率 20-40% → 修订方案并增加缓解措施
- IF 失败模式概率 < 20% → 进入 Phase 6
- 输出格式建议：
如果发现问题，直接在这个阶段修正，不需要等用户指出。## Phase 5：方案自检 ### Proportionality Screen [风险等级评估结果] ### 五段报告 - Autopsy：[事件链 / 隐藏假设 / 早期信号 / 概率伤害] - Verdict：[战略综合分析结果] - Rebuild：[修订计划] - Adversary：[对抗性审查结果] - Tripwires：[≤8 项可验证的早期信号] ### Decision Rule [IF/THEN 门控评估结果] ### 修订后方案 [基于自检的方案修订]
Phase 6：最终确认（Final Review）
用户确认方案方向后，做最后一轮 review：
- 方案的完整性：所有步骤是否都覆盖到了？
- 风险预案：如果方案执行中出现意外，怎么办？
- 验证方式：方案执行后，怎么确认问题真的解决了？
- 还有没有什么补充建议？
增强：kimasplund/premortem-skill 的 Calibration Review 和 Commitment 等级（P0 级）
- 校准概率份额（
5/10/15/20/30/40 粗梯） - 评估 Commitment 等级（champion / endorse / accept / comply）
- 执行 Decision Rule 最终裁决
- 索取具体承诺：要求用户给出一项具体行动承诺（如「下周三前完成 X」）
- 输出最终确认报告：
## Phase 6：最终确认 ### 方案完整性 [检查结果] ### 风险预案 [应对意外情况的预案] ### 验证方式 [方案执行后的确认方法] ### Calibration Review [概率份额校准结果] ### Commitment 等级 [评估结果] ### 具体承诺 [用户给出的具体行动承诺] ### 补充建议 [其他建议]
Phase 7：执行（可选）
只有在用户明确说"开始执行"、"动手吧"、"搞起来"等指令时才进入这个阶段。
执行时遵循：
- 按 Phase 4-6 确认的方案步骤逐步执行
- 每完成一个关键步骤，简要汇报进展
- 遇到意外情况时暂停，回到讨论模式
- 写操作授权门槛：若执行涉及修改文件、运行命令、改动代码或系统配置，在动手前逐项列出将执行的具体操作（含目标路径/命令），并向用户取得显式授权（如"确认执行以上 N 项操作？"）后再进行；不默认代用户执行任何写操作
行为准则
阶段推进的节奏
- 不要跳阶段。即使问题看起来简单，也至少过一遍 Phase 1-4
- Phase 2 是最关键的质量门控，如果在这一步发现信息不足，宁可多问一轮也不要带着假设往下走
- Phase 5 和 6 可以根据问题复杂度适当合并，但不能完全跳过
- 如果用户中途提供了新信息，评估是否需要回到更早的 Phase 重新分析；回退深度按"新信息影响哪一阶段结论"决定：只影响方案细节→回 Phase 4，影响根因判断→回 Phase 2-3
- 若用户中途将话题转向一个与当前问题无关的全新问题时：先快速确认是要"暂停当前讨论、开启新讨论"还是"两件事并行"，不要混在同一轮里分析，避免两边都浅尝辄止；若并行，用编号分别跟踪（问题 A / 问题 B）
沟通风格
- 直接、坦诚，不要绕弯子。用户不玻璃心，更重视有效信息
- 如果用户的判断有误，直说，但要给出理由
- 对不确定的事情用概率/置信度表述，而非模棱两可的"可能"
- 输入语言以用户当前使用的语言为准：用户用中文就用中文讨论，用英文就用英文，不要擅自切换；若用户混用语种（如中文夹英文术语），保持同样混用风格，仅对必要的陌生术语给出中文释义
- 每次回复末尾简要标注当前阶段和下一步建议，保持讨论的节奏感
标注当前阶段
每次回复的开头用简洁的方式标注当前阶段，例如：
Phase 2 → 问题审查
或者在阶段转换时：
Phase 2 done → Phase 3：深度分析
这样用户随时知道讨论进行到哪里了。
思维审计层集成（运行时探测）
本技能可在运行时接入「分步推理 / 思维记录」类 MCP 服务，作为贯穿 7 阶段的思维审计基础设施层（而非单阶段增强模块）。其完整方法论文档与接口契约见 references/enhancements/sequential-thinking-adapter.md。核心纪律如下。
探测纪律（硬约束，不可省略、不可仅文档检查）
⚠️ 激活强制动作（位于 Phase 1 之前、不可省略、不可延后）：本 Skill 每次被激活后，必须实际调用
sequential-thinking服务的真实接口（无论该服务是直接连接到 Agent，还是经任意名称聚合器中转，具体接入途径在运行时探测确定，绝不硬编码dynamic-mcp或任何分组名）做一次真实调用，以运行时结果判定服务可用性。仅凭「适配层文档存在」「SKILL.md 提及该层」等静态事实不足以判定服务可用——这正是 P3-03 类错判（把"文档存在"误当"服务可用"）的根因。确切调用参数、失败判定与"已探测"缓存约定见references/enhancements/sequential-thinking-adapter.md§3.5「强制探活执行协议」。该强制动作以scripts/probe_seq_thinking.py作为激活探活器清单，激活后运行它即可获得需执行的调用与验收点。
- 每次激活必实际调用探测、会话内只探一次：进入 Phase 1 之前真实执行一次探测调用（运行时枚举全部可用 MCP 工具/服务、按能力特征匹配、再用真实入口实测
process_thought），不得仅以文档/代码静态存在替代真实调用；结果缓存至会话级变量，同一对话会话内后续激活（含用户切换新问题）直接复用，不再重复探测。新开会话或显式「重新探测」指令时才重新探测。 - 按能力特征匹配，不按名称匹配：运行时发现主机「全部可用 MCP 工具 / 服务」（须同时覆盖「直接连接暴露的工具」与「各聚合器分组内的工具」两类拓扑，聚合器名称任意、不得假设为特定名；枚举机制由主机决定，不得假设具体 API 名），比对适配层文档 §2 的「能力特征集合」（记录单条思维 + 生成摘要 + 清空历史 三件套即视为可适配）。具体服务名、工具名、接入路径一律以探测结果为准，本文件与适配层文档均不硬编码。
- 记录探测结论：探测后登记
available/access_path（直接连接 Agent，或经某聚合器中转，二者皆可）/tool_names（真实调用名，直连时为mcp__<服务名>__<工具名>形式）/functions（各工具功能）。 - 不可用即静默降级：
available=false时不打扰用户、不阻塞流程，全部阶段按基础模式运行（思维审计层完全不参与）；仅在用户需要时可于 Phase 1 开头以一行注明[思维审计层不可用，已切换至基础模式]。
各阶段一句话映射（available=true 时生效；完整表格见适配层文档 §4）
- Phase 1：用「记录思维」工具写入信息摘要，锚定上下文。
- Phase 2：每条关键判断各记一条思维；对替代问题成立性用分支探索。
- Phase 3：5Why 每步记一条；死胡同用分支、早前结论用修订修正。
- Phase 4：每个候选方案记一条并打标签，便于回溯对比。
- Phase 5：每个失败模式记一条，标注被挑战假设 / 公理。
- Phase 6：用「生成摘要」工具产出结构化思维链路，作为汇报素材。
- Phase 7 / 会话切换：每步记留痕；切换问题前「清空历史」或「导出会话」保存，旧讨论可用「导入会话」续推。
激活阈值：复杂度 ≥ 中 且思维审计层可用时即启用（该层轻量、近乎零额外成本）；复杂度偏低但用户希望保留推理链路时，也可显式 opt-in。
版本锁定与模块依赖
本技能依赖以下外部模块，版本已锁定在 version-lock.md：
- jasminK11/claude-5-why-skill（用于 Phase 3 深度分析）
- kimasplund/premortem-skill（用于 Phase 5 方案自检和 Phase 6 最终确认）
- SilvereWolf/idea-friction-feasibility-auditor（用于 Phase 2 问题审查）
思维审计层（sequential-thinking 等 MCP 服务）不进入上述 commit 锁定表：它是运行时按能力特征动态探测接入的 MCP 服务，非 git 上游模块，无固定版本可锁；其可用性、接入途径与工具名均在每次激活时探测确定（详见「思维审计层集成」节与
references/enhancements/sequential-thinking-adapter.md）。
更新流程：
- 每季度检查上游仓库是否有新版本（仅读取 CHANGELOG 或标签，不自动拉取）
- 仅当确认更新不破坏接口契约时，才考虑更新
version-lock.md中的版本号 - 更新前必须在隔离环境中验证新版本与主干的兼容性
- 更新后运行回归测试（使用典型问题场景走查完整流程）
降级机制
任何依赖模块不可用时（网络、版本不兼容、接口 mismatch 等）：
- Phase 2：退化至原有三层审查（问题成立性/信息充足度/隐藏问题）
- Phase 3：退化至多维度脑暴雨式分析（考虑技术/流程/风险/成本等维度）
- Phase 5：退化至原有检查清单（5项）
- Phase 6：退化至原有四项检查（完整性/风险预案/验证方式/补充建议）
- 思维审计层（MCP 服务）不可用时：默认无任何额外提示、不阻塞流程，所有阶段按基础模式运行（无显式思维留痕 / 分支 / 跨会话持久化）；如需告知用户，可在 Phase 1 开头注明
[思维审计层不可用，已切换至基础模式]。 - 在阶段输出中明确标注：
[模块名称] 暂不可用，已切换至基础模式 - 不中断整个讨论流程，仅影响该阶段的深度程度
加载时启动自检（必做）
每次激活本技能时，先完成「思维审计层集成」节的激活强制探测（运行时枚举 + 真实调用 process_thought，见该节），再执行下方自检，避免"静默降级"导致用户误以为模块已生效。技能根目录附带 scripts/selfcheck.py，可运行 python scripts/selfcheck.py（或 uv run python scripts/selfcheck.py）自动完成下方一致性核对（含第 4 项强制探活机制检查）；手动核对时遵循下方清单：
前置：思维审计层探测（每会话一次）：在自检之前或紧邻，先执行「思维审计层集成」节的探测（会话内仅一次，结果缓存复用）。探测不可用时不计入自检失败，仅按降级纪律处理。
- 模块存在性：确认
references/enhancements/下三个模块文件（jasminK11-5why.md、kimasplund-premortem.md、silvereWolf-consult.md）均存在且非空。 - 版本标记一致性：逐项核对以下三处 commit 必须互证一致，任一不匹配即视为版本偏离：
- 模块首行 ↔ 锁表：读取三个模块文件首行的
<!-- 版本锁定: commit:... -->，确认其 commit 出现在version-lock.md的锁定表中； - 更新记录 ↔ 首行：若模块文件「更新记录」小节引用了上游 commit（形如
基于 <repo>@<commit>），其<commit>必须与文件首行的 commit 完全一致，禁止遗留占位符（如<真实commit>）； - 主干锁 ↔ main HEAD：读取
version-lock.md中「主干」行的 commit，须等于当前仓库git rev-parse --short main的值，或为其已合入 main 的祖先提交（仅当指向未合入 main 的悬空 commit 才视为版本偏离）。
- 模块首行 ↔ 锁表：读取三个模块文件首行的
- 处置：若自检发现缺失或版本偏离，在 Phase 1 开头明确向用户提示"检测到 [模块名] 不可用/版本偏离，已切换至基础模式"，而非等到对应阶段才悄悄降级；若无异常则无需提示，不打扰用户。
示例
典型场景 1：技术故障排查
用户：「我的网站在 Safari 上打开慢，但 Chrome 正常，不知道是不是 CSS 问题」 流程：Phase 1 收集现象/浏览器/环境 → Phase 2 审查问题成立性（是否真为 CSS）、信息充足度（需网络面板/性能分析）、隐藏问题（可能是字体加载/渲染阻塞） → 如信息不足暂停等待补充 → Phase 3 激活 5Why 追问根因 → Phase 4 给出 2-3 个方案（字体预加载/关键 CSS 内联/字体回退策略） → Phase 5 Premortem 评估方案风险 → Phase 6 最终确认并索取承诺。
典型场景 2：架构决策困境
用户：「我们要开发新功能，该用微服务还是单体架构？团队 8 人，预计维护 3 年」 流程：Phase 1 接收团队规模/维护周期/业务边界 → Phase 2 审查：是否真需要微服务（Value Flaw：过度设计）、信息充足度（需业务边界清晰度/运维能力/部署基建）、隐藏问题（认知负载/分布式事务/测试复杂度） → Phase 3 5Why 分析核心驱动力 → Phase 4 方案：单体+模块化/微服务/模块化单体+未来拆分预留 → Phase 5 Premortem 评估各方案失败模式 → Phase 6 Calibration+Commitment。
典型场景 3：问题澄清不足
用户：「用户说 APP 崩溃了，但没给日志，我也没法复现」 流程：Phase 1 收集仅有信息 → Phase 2 审查：信息严重不足，Unknowns「必须有」：崩溃日志/复现步骤/设备型号/版本号 → Verdict：「需更多信息」→ 暂停流程，明确列出必须补齐的信息等用户回复。