Premortem 工程实践：用 AI 工具预防代码缺陷

用失败框架绕过 AI 的礼貌

我开始使用 premortem 的原因很无聊：我不信任默认的审查问题。

当我问编程 agent "这个计划看起来好吗?"，答案通常是有用的，但太客气了。它找理由说计划可行。它注意到一些边界情况。它给我一个整洁的改进清单。不错。

但这不是我在选择实现路径、发布想法、改变认证、移动数据或让 agent 写大量 diff 之前想要的检查。

在那时候，我想要额外的一轮试图推翻这个决策。

所以我开始要求进行 premortem。

这个方法是 Gary Klein 的，不是我的。2007 年他在《哈佛商业评论》上写过项目 premortem。后来 Daniel Kahneman 指出这个技术是对抗过度自信的实用方法。核心思想很简单：假设计划已经失败了，然后解释为什么会这样。

这个小改变对于 LLM 很重要。

这个计划好吗？

现在是六个月以后。这个计划失败了。
解释它是怎么发生的。要具体。

第二个提示给模型一个不同的任务。它不再是批准计划。它是在重构失败。

"什么可能出错？"通常给我一个通用的风险清单。"这已经失败了，为什么？"给我一个故事。第一个破裂点。隐藏的假设。我可能会忽视的信号。我忘记设计的回滚方案。

那更容易处理。

我在两个地方用 premortem 作为第二次检查。

首先，编程决策。

不是每个代码改动都需要这个。我在计划改动成本低但以后撤销成本高的时候用它：迁移、认证改变、数据模型改变、发布计划、可以触及许多文件的 agent 工作流，或者任何我即将说"好的，这应该没问题"但没有足够顾虑的情况。

在我花时间写文章、做小开源发布或想产品创意之前，我会问什么会让它悄悄失败。不是"这有趣吗？"而是"六周后没人在乎，怎么回事？"这通常会表面出比我想要写的更好的问题。

它不是对品味、测试、审查或与人交谈的替代。它只是在计划固化之前的一个便宜的额外检查。

为什么我把它打包成 skill

我一直在手动重新输入这个框架。那有效，但不一致。有时我问得太模糊。有时我让答案变成了一个通用清单。有时我忘记强制模型在最后修改计划。

所以我做了一个小 skill：

https://github.com/PabloNAX/premortem-skill

已经有其他 premortem 提示和 agent 工作流。我做这个是因为我实际如何使用 Claude Code 和 Codex：

• 每个重要失败模式一个调查
• 最后是修改后的计划和检查清单

聊天输出很重要。如果结果变成我必须打开的单独报告，我以后读，通常意味着永远不读。我想要在我还把计划记在脑子里时的对话中的批评。

这个 skill 期望一个具体的计划。如果计划太模糊，它会要求缺失的上下文，而不是编造东西。

然后它运行失败框架：

• 把计划当作已经失败了
• 生成与计划匹配的失败模式
• 分别调查重要的那些
• 把结果合成简短的聊天答案

我想要的输出很小：

最可能的失败
最危险的失败
隐藏的假设
修改后的计划
检查清单

之后我可以深入一个部分：

更深入地探讨回滚失败。
假设我在开始迁移前只有两小时。

一个副项目的例子：我想在一个周末内把一个小应用从 SQLite 迁移到 Postgres。单人，没有预发环境，几个月的真实本地数据。

正常的审查可能会告诉我转储、恢复、测试并保留备份。对，但不够尖锐。

premortem 回来了一个更有用的失败故事：

最可能的失败
SQLite 的松散类型允许 Postgres 拒绝或不同强制转换的行。
导入看起来大部分没问题，但几条记录在切换后变错了。

最危险的失败
没有回滚边界。应用开始写入 Postgres，迁移半成功，
SQLite 副本不再是干净的真相来源。

隐藏的假设
查询是可移植的，数据库切换主要是一个连接字符串。

修改后的计划
1. 先在本地 Postgres 中恢复。
2. 在切换任何东西之前对比行数和示例行。
3. 把数据库后端放在一个环境变量后面。
4. 针对 Postgres 运行正常本地使用一天。

这些都不是奇特的。那就是重点。它找到了我最可能跳过的无聊失败。回滚边界在我碰迁移之前改变了计划。

我也在 skill 本身的发布计划上运行了这个 skill。

有用的抓住是简单的：仓库解释了这个想法，但没有显示输出看起来什么样。访问者会看到安装命令和文本，但没有体验的证明。那改变了 README。我录了短终端演示并把它放在顶部附近。

它也对我的指标提出了反对。我在想 GitHub 星星。premortem 指出星星容易数，容易优化得很差。更好的信号是几个人在真实计划上试它并告诉我输出错在哪。

那是我想要的批评。不是大哲学论证。在我花更多时间在想法的错误版本上之前的小纠正。

输入必须是具体的

Premortem 我的创业想法。

Premortem 这个发布计划：
我正在发布一个 Claude/Codex 的 premortem skill。
受众：已经使用编码 agent 的开发者。
目标：从在真实计划上用它的人那里得到 10 个认真的试验。
渠道：GitHub README、DEV 文章、LinkedIn 帖子。
约束：没有假的生产例子。

那给模型什么要检查的：受众、目标、渠道、约束和失败条件。

对编程也是这样。"Premortem 我的迁移"很弱。"Premortem 这个 SQLite 到 Postgres 的迁移，单人，没有预发环境，需要回滚"很有用。

为 Claude Code 安装：

git clone --depth 1 https://github.com/PabloNAX/premortem-skill && ./premortem-skill/install.sh claude

为 Codex 安装：

git clone --depth 1 https://github.com/PabloNAX/premortem-skill && ./premortem-skill/install.sh codex

我仍然要求 agent 审查计划。我只是不再在那里停下来了。对于重要的决策，我想要额外的一轮，其中计划已经失败，agent 必须告诉我为什么。

声明：我使用 AI 协助来起草和编辑这篇文章的部分。例子和结论来自我自己对 premortem skill 的使用，我在发布前审查了最终文本。

Gary Klein，"Performing a Project Premortem，" Harvard Business Review，2007。https://hbr.org/2007/09/performing-a-project-premortem

Daniel Kahneman，《快思慢想》，2011。

D. J. Mitchell，J. E. Russo，N. Pennington，"Back to the future: Temporal perspective in the explanation of events，" Journal of Behavioral Decision Making，1989。

M. Sharma et al.，"Towards Understanding Sycophancy in Language Models，" Anthropic，2023。https://arxiv.org/abs/2310.13548