PostgreSQL 18 已经发布，Release Notes 给出了正式变化；PostgreSQL 19 尚未正式发版，能够观察的主要是开发分支上的提交记录。面对数千条 commit，真正困难的不是“找出改动”，而是判断哪些变化会影响查询性能、运维方式、兼容性和日常开发体验。
演讲者采用了一条值得复用的路线：让 AI 先批量归纳 commit，再逐项生成解释与验证代码，最终通过人工校验筛掉重复项、内部重构和缺乏证据的结论。这里最有价值的并不是某个提示词，而是一套从原始提交到可验证结论的工程流程。
Release Notes 与 commit 日志回答不同的问题
Release Notes 是发布团队整理后的稳定视图，适合确认 PostgreSQL 18 已经交付了什么。它通常会合并相关提交，并把底层实现转换为用户能够理解的描述。
commit 日志则更接近研发现场。它能提前暴露 PostgreSQL 19 的发展方向，但噪声也更多：同一项功能可能横跨多个提交，后续提交可能修正甚至撤销早期实现，大量测试、重构和注释变更也不等于用户可见特性。
因此，两类材料应采用不同结论强度：
- PostgreSQL 18 的条目可以标记为“已发布”，但仍需核对版本和适用条件。
- PostgreSQL 19 的条目只能称为“候选变化”或“开发中能力”。
- 单个 commit 不能直接等同于完整特性，应继续查找相关提交、测试和文档。
- 性能收益必须通过基准测试确认，不能把提交描述里的特定测试结果推广到所有负载。
把数千条提交压缩成可审查的候选集
比较稳妥的处理方式是分四层推进。
第一层只做机械筛选：按时间、分支、目录和关键词缩小范围。第二层让模型归并相似提交，并按照 SQL、执行器、存储、复制、备份恢复、监控、安全、客户端工具等领域分类。第三层要求模型为每个候选项提供证据，包括 commit hash、涉及文件、前置条件和潜在风险。第四层才生成解释和验证脚本。
这套顺序很重要。如果直接要求模型“总结 PostgreSQL 19 新特性”，模型很容易把历史能力、讨论中的补丁或自己的推断混在一起。先固定证据，再写结论，可以显著降低这种风险。
候选项可以使用统一的数据结构保存：
{
"name": "候选特性名称",
"status": "released-or-development",
"area": "planner",
"commits": ["commit-sha"],
"user_impact": "用户能够观察到的变化",
"verification": "待执行的 SQL 或命令",
"confidence": "low-medium-high"
}
其中 confidence 不应由语言流畅度决定。至少存在正式文档、测试用例或多个相互印证的提交时，才适合提高置信度。
可以这样实践：生成 PG 19 候选提交批次
下面的示例假设 PostgreSQL 源码仓库已克隆到当前目录的 postgres。它以 PostgreSQL 18 Beta 1 标签为起点，从当前开发分支提取提交，再按每 80 条一个批次生成供 AI 分析的 Markdown 文件。
先提取日志：
git clone https://github.com/postgres/postgres.git
cd postgres
git log REL_18_BETA1..master \
--date=short \
--pretty=format:'%H%x09%ad%x09%s' \
> ../pg19-commits.tsv
cd ..
wc -l pg19-commits.tsv
如果仓库已经存在，只需在更新远端引用后运行 git log。分析某个历史快照时，应把 master 换成明确的 commit hash，避免不同日期运行得到不同结果。
创建 build_prompts.py：
from pathlib import Path
BATCH_SIZE = 80
source = Path('pg19-commits.tsv')
out_dir = Path('prompt_batches')
out_dir.mkdir(exist_ok=True)
rows = [line for line in source.read_text(encoding='utf-8').splitlines() if line]
instruction = '''
你正在分析 PostgreSQL 开发分支的提交记录。
请完成以下任务：
1. 合并属于同一项工作的提交，不要把修复和测试重复计为特性。
2. 区分用户可见变化、性能优化、内部重构、文档与测试变更。
3. 每个结论必须列出原始 commit hash；证据不足时标记为低置信度。
4. 不得声称这些变化已随 PostgreSQL 19 正式发布。
5. 输出 JSON 数组，字段为 name、area、commits、user_impact、risk、confidence。
待分析提交：
'''.strip()
for index in range(0, len(rows), BATCH_SIZE):
batch = rows[index:index + BATCH_SIZE]
number = index // BATCH_SIZE + 1
content = instruction + '\n\n' + '\n'.join(batch) + '\n'
(out_dir / f'batch-{number:03d}.md').write_text(content, encoding='utf-8')
print(f'generated {(len(rows) + BATCH_SIZE - 1) // BATCH_SIZE} batches')
运行：
python3 build_prompts.py
ls prompt_batches | head
这些批次可以交给 Copilot 或其他支持长文本分析的模型。这里故意不让模型立即编写长篇解读，而是先输出结构化候选项，便于去重、排序和追踪证据。
针对筛选后的单个候选项，可以继续使用更严格的提示词：
根据下面列出的 commit hash 和提交说明，解释该候选变化。
要求：
- 只陈述证据能够支持的行为，不补充未经确认的 API、GUC 或 SQL 语法。
- 指出这是已发布特性还是开发分支候选变化。
- 给出验证所需的 PostgreSQL 版本、初始化参数和最小 SQL。
- 同时给出反例或边界条件。
- 若无法从材料确认 SQL 语法，明确写“需要查阅补丁或文档”，不要猜测。
代码校验不能只看“能运行”
模型生成的 SQL 即使语法正确，也未必验证了目标变化。审查时至少要回答三个问题：测试是否运行在正确版本上，是否建立了能够触发目标路径的数据分布，以及结果是否具有可比较的基线。
性能类变化通常需要保留 EXPLAIN (ANALYZE, BUFFERS, SETTINGS) 输出，并在相同硬件、参数和数据集上比较版本。运维类变化则应覆盖失败路径，例如权限不足、磁盘空间不足、主备延迟和回滚行为。涉及新参数时，还要检查默认值、重启要求以及对旧配置文件的兼容性。
对于 PostgreSQL 19，测试环境最好固定到具体源码提交：
cd postgres
git rev-parse HEAD
./configure --prefix="$HOME/pg19-test" --enable-debug
make -j"$(getconf _NPROCESSORS_ONLN)"
make install
这段命令只是通用的源码构建实践，不代表候选特性已经稳定。执行验证时，应把 git rev-parse HEAD 的结果与 SQL、配置和测试数据一起归档，否则几周后很难复现结论。
采用这套方法时的检查清单
AI 很适合完成聚类、摘要和草稿生成，却不适合作为版本事实的唯一来源。真正可发布的技术解读应保留一条完整证据链：Release Notes 或 commit、对应代码与测试、可复现命令，以及人工审核结论。
发布前可以检查以下项目：
- PostgreSQL 18 的结论是否能在正式 Release Notes 或文档中定位。
- PostgreSQL 19 是否始终标注为开发中，避免把候选提交写成发布承诺。
- 每个特性是否关联具体 commit，而不是只有模型总结。
- SQL、参数名和系统视图字段是否在目标版本实际存在。
- 性能结论是否包含环境、数据规模、执行计划和对照组。
- 是否说明兼容性、回滚成本以及功能可能在正式发布前改变的风险。
把 AI 放在信息压缩和证据整理的位置，这套流程才能规模化。它可以帮助工程师从数千条提交中更快找到值得验证的变化，但“什么已经交付、什么值得采用”仍然必须由源码、文档和实验共同回答。