想要让Gemini进行深层次原因分析，仅仅问一句“哪里做得不好”远远不够。它很容易被表面归因蒙混过关，直接给出“沟通不畅”“资源不足”这类泛泛而谈的答案。更有效的做法是：利用提示词阻断表面归因路径，逼迫它一层层深入穿透，从执行层面到系统层面，再到认知层面。

先看一个具体场景。假设你正在复盘一个项目，发现“用户次日留存率由32%骤降至18%”——这个数据非常扎眼。但如果不加约束地向Gemini提问，它大概率会归结为“产品体验欠佳”“运营策略失误”这些空洞结论。因此，关键在于提示词中加入“硬约束”。

第一步：锁定复盘焦点，排除模糊表述

在发起提问之前，先明确项目当中一个具体且可验证的负面结果。比如“用户次日留存率由32%骤降至18%”，而不是“用户体验不好”。模糊的结果会触发Gemini调用通用话术库，直接生成万能归因。因此，在提示词开头直接写明：

“本次复盘仅聚焦于：【用户次日留存率由32%骤降至18%】这一事实。”

这个动作就像一个锚点，将讨论范围死死锁定，避免偏离方向。

第二步：强制分层归因，堵死甩锅出口

在提示词中嵌入三层追问结构，每层用不同的动词锚定思维深度：

① 执行层（具体发生了什么）：列出导致该结果的3个可追溯的操作动作或决策节点，每个动作必须对应到具体的人/角色/时间点。这一步是为了让Gemini无法用“有人没执行好”这种模糊表述搪塞。

② 系统层（为什么这些动作会批量出现）：指出支撑这些动作的1项被默认接受但未经验证的流程假设。例如“我们默认灰度发布无需同步更新埋点配置”——这种假设通常隐藏在团队习以为常的操作中。

③ 认知层（为什么这个假设从未被质疑）：说明团队在该项目周期内共享的、未言明的成功经验模板。比如“过去3次迭代都依靠上线后人工核对数据，因此默认自动化校验是冗余成本”。

这三层必须按顺序输出，禁止跳层。跳层即视为归因失效——如果Gemini跳过系统层直接谈论认知层，说明它仍然在偷懒。

第三步：注入反事实锚点，激活因果推演

在提示词末尾加入一句反事实条件：

“如果【灰度发布时同步冻结埋点配置变更】这一条规则在项目启动会上被写入《红线清单》，上述三层归因中的哪一层会最先崩溃？请指出崩溃位置并说明该位置如何引发连锁修正。”

这个反事实条件并非为了幻想补救，而是用不可逆的规则设定倒逼识别真正脆弱的控制点。没有这个锚点，Gemini容易停留在“下次注意”的建议层面——比如“建议加强沟通”“建议增加测试”——但根本无法触及问题的结构性原因。只有通过“如果当初……会怎样”的推演，才能看清哪个环节最脆弱、一旦强化就能引发连锁修正。