过去一个月，Postgres 19 有多项重要功能被回退。即便后续开发一切顺利，发布时间也可能比原计划晚约一个月。围绕这些变化，一种颇具传播力的说法开始出现：AI 找到了补丁中的复杂缺陷，而修复范围太大，所以项目只能在开发周期后段撤销补丁。
这个解释听起来完整，却把几个不同的问题压缩成了一条过于简单的因果链。AI 是否参与发现问题、缺陷是否真实、修复是否适合当前阶段，以及维护者为什么决定回退，必须分别验证。
“发现缺陷”和“决定回退”不是一回事
一次补丁回退通常至少包含三层判断：
- 技术判断：问题能否稳定复现，根因是否确实位于该补丁；
- 修复判断：修复需要局部修改，还是会触及执行器、优化器、存储或并发控制等更大范围；
- 发布判断：在当前开发阶段继续修改，是否会引入更多未验证风险。
AI 可能参与第一层，例如生成边界条件、组合 SQL、审查代码路径或提示潜在不变量。但即使某条 AI 线索最终指向了真实缺陷，也不能直接得出“这个功能是被 AI 撤下的”。
真正执行回退的是维护者，依据则是可复现证据、修复复杂度、评审能力和发布时间窗口。换句话说，AI 最多是缺陷发现链条中的一个工具，不是发布治理的决策主体。
这一区分很重要。否则，项目历史会被改写成一个吸引眼球但不可审计的故事：AI 提问、AI 找到 Bug、项目被迫延期。这样的叙述会掩盖补丁此前经历过哪些人工评审、问题何时进入讨论，以及维护者如何权衡风险。
为什么开发周期后段更容易选择回退
大型数据库补丁很少是“修正一个条件判断”这么简单。一个看似局部的问题，可能意味着原有设计遗漏了事务可见性、崩溃恢复、并行执行、复制或查询计划变化等交互。
开发早期，维护者还有空间重构接口、补充测试并等待更多平台反馈。越接近稳定阶段，修改预算越低。此时面对侵入性修复，常见选择通常只有两个：
- 合入较大修复，并承担新回归缺陷未被发现的风险；
- 回退整项功能，让它回到后续开发周期重新设计和评审。
因此，“Bug 很复杂”和“补丁被回退”之间并不需要 AI 才能建立联系。这本来就是成熟基础设施项目的发布纪律。延期也不自动证明缺陷由某种工具发现，只说明项目为了重新稳定代码树付出了时间成本。
把 AI 线索变成可审计的 PostgreSQL 缺陷报告
与其争论发现者是人还是模型，更有价值的做法是把线索变成任何维护者都能独立复现的材料。下面是一套可以改造的最小验证流程。
运行前，将 PG_COMMIT 改成待验证补丁所在的提交哈希。示例会以调试和断言模式编译 PostgreSQL，执行回归测试，再启动一个临时实例：
set -euo pipefail
export PG_COMMIT="replace-with-the-commit-to-test"
export WORKDIR="$PWD/pg-ai-repro"
rm -rf "$WORKDIR"
git clone https://github.com/postgres/postgres.git "$WORKDIR"
cd "$WORKDIR"
git checkout "$PG_COMMIT"
./configure \
--prefix="$WORKDIR/local" \
--enable-debug \
--enable-cassert
make -j"$(getconf _NPROCESSORS_ONLN)"
make check
make install
local/bin/initdb -D "$WORKDIR/demo-data"
local/bin/pg_ctl -D "$WORKDIR/demo-data" -l "$WORKDIR/postgres.log" start
local/bin/createdb repro
local/bin/psql -X -v ON_ERROR_STOP=1 repro <<'SQL'
CREATE TABLE accounts (
id bigint PRIMARY KEY,
balance bigint NOT NULL CHECK (balance >= 0)
);
INSERT INTO accounts
SELECT i, 1000
FROM generate_series(1, 1000) AS g(i);
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
SELECT sum(balance) AS total_balance FROM accounts;
SQL
local/bin/pg_ctl -D "$WORKDIR/demo-data" stop
这段 SQL 只是测试框架，不对应此次回退中的某个具体缺陷。实际使用时，应把事务替换成触发目标问题的最小 SQL，并同时记录：
- PostgreSQL 提交哈希和编译参数；
- 操作系统、编译器及关键依赖版本；
- 完整 SQL、并发度和执行顺序；
- 预期结果与实际结果；
- 日志、断言失败或崩溃栈；
- 在补丁前一个提交上是否仍能复现。
如果问题涉及并发，仅提供一段“偶尔失败”的 SQL 不够。应使用固定会话顺序、屏障或循环压力测试，并给出失败频率。若 AI 生成了测试用例，还应保留原始提示、模型输出以及人工删改记录，避免后续把人工推理错误归因于模型。
AI 报告也需要做反向验证
AI 很擅长提出可疑场景，却也容易生成不存在的函数、误解 PostgreSQL 语义，或者把预期行为描述成缺陷。审阅一份 AI 辅助报告时，可以按下面的清单检查：
- 不依赖报告作者的私有环境，第三方能否复现？
- 失败是否只出现在目标补丁之后？
- 是否引用了真实存在、版本匹配的代码路径？
- 预期结果是否有文档、标准或既有测试支持？
- 缩减测试用例后，问题是否仍然存在？
- 修复建议与缺陷证明是否被错误地混为一谈？
尤其要警惕最后一点。AI 可能正确发现异常，却给出危险修复；也可能提出合理重构，但并未证明当前实现有错。缺陷成立、修复正确、适合立即合入，是三个独立结论。
如何更准确地描述这类事件
面对重大功能回退，比较稳妥的表述方式是：项目发现了阻断发布的问题；候选修复在当前阶段风险过高；维护者因此选择回退。只有在提交记录、邮件讨论或可复现实验明确支持时，才应进一步说明 AI 在发现过程中扮演了什么角色。
团队采用 AI 辅助数据库开发时，也可以坚持三条边界：
- 线索不等于证据：模型输出必须落到可运行测试上；
- 归因不替代分析：记录是谁发现的，不如解释为何会失败；
- 工具不承担治理责任：是否合入、回退或延期，仍由维护流程和风险判断决定。
Postgres 19 的回退值得关注，但真正值得学习的不是“AI 击败了人工评审”这样的戏剧性叙事，而是成熟项目如何在发布后期面对高风险变更：保留证据，控制范围，并在不确定性过高时果断撤回。