项目复盘提示词：用Gemini做深度原因分析的关键步骤

要让Gemini生成有深度的归因分析，仅问“哪里做得不好”远远不够。AI很容易停留在表面，给出“沟通不畅”“资源不足”这类泛化结论。更高效的方法是：通过提示词切断表层归因路径，强制模型从执行层逐层穿透到系统层，再深入到认知层。

看一个真实场景。复盘项目时发现“用户次日留存率从32%暴跌至18%”——这个数据足够尖锐。但如果提问不加约束，Gemini大概率会给出“产品体验欠佳”“运营策略失误”等通用回应。关键在于，在提示词中施加硬性约束。

第一步：锚定复盘目标，杜绝模糊归因

提问前，先锁定项目中一个具体可量化的负面结果。例如“次日留存率从32%骤降至18%”，而非“用户体验差”。模糊结果会触发Gemini调用通用话术库，直接输出万能归因。因此，提示词开头必须写明：

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

此举等于设置锚点，将讨论范围牢牢锁定，避免偏离核心。

第二步：强制分层归因，封堵敷衍出口

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

① 执行层（实际发生了什么）：列出导致该结果的3个可追溯的操作动作或决策节点，每个动作必须对应到具体人/角色/时间点。这一步迫使Gemini无法用“有人执行不到位”这类模糊表述跳过细节。

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

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

三层必须按顺序输出，禁止跳层。若Gemini跳过系统层直接谈认知层，说明仍在使用捷径。

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

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

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

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