一次面向 PostgreSQL 提交者与核心团队的 AI 工作坊，把讨论重点从“模型能回答什么”推进到了“模型如何参与真实的数据库工程”。三天的内容覆盖 Claude 命令行环境、自动化测试与基准测试、概念验证补丁，以及邮件线程分析和补丁审查。真正值得关注的不是生成代码本身，而是如何让 AI 在可验证、可回滚的边界内缩短调查周期。
AI 更适合承担调查成本，而不是替开发者做决定
数据库内核中的很多想法并非没有价值，而是验证成本太高：需要阅读跨模块代码、构造测试、运行基准，再判断性能变化是否来自目标补丁。AI 自动化工作流可以先完成这些机械但耗时的步骤，例如：
- 从 bug 报告和邮件讨论中提取复现条件、争议点与未回答的问题；
- 定位可能相关的源文件、测试目录和提交历史；
- 生成概念验证补丁，用于确认某条技术路线是否可行；
- 执行测试与基准测试，并把失败日志整理成结构化摘要；
- 检查补丁是否覆盖错误路径、并发场景和回归测试。
这里的关键边界是：概念验证补丁只是实验材料，不等于可以合并的补丁。PostgreSQL 这类系统包含并发控制、崩溃恢复、平台差异和长期兼容性约束。模型可能产出能够编译、甚至通过局部测试的代码，却仍然破坏隐藏的不变量。
命令行让分析过程变得可重复
图形聊天界面适合探索问题，但源码审查需要可重复的输入。把模型接到命令行后，可以明确指定代码范围、测试命令和输出格式，也能将提示词纳入项目脚本进行版本管理。
可以这样实践。下面假设本机已经安装并登录 Claude Code，当前目录是一个 PostgreSQL 源码工作树。脚本只收集补丁和文件列表，不会自动修改代码：
#!/usr/bin/env bash
set -euo pipefail
base_ref="${1:-origin/master}"
report="${2:-ai-patch-review.md}"
git diff --check "$base_ref"...HEAD
git diff --name-status "$base_ref"...HEAD > /tmp/pg-changed-files.txt
git diff --stat "$base_ref"...HEAD > /tmp/pg-diff-stat.txt
git diff "$base_ref"...HEAD > /tmp/pg-patch.diff
{
printf '%s\n' \
'Review this PostgreSQL patch as an investigation assistant.' \
'Do not assume passing tests prove correctness.' \
'Return Markdown with these sections:' \
'1. Behavioral summary' \
'2. Possible correctness or concurrency risks' \
'3. Missing regression tests' \
'4. Portability and compatibility concerns' \
'5. Questions that require a human committer' \
'' \
'Changed files:'
cat /tmp/pg-changed-files.txt
printf '\nDiff statistics:\n'
cat /tmp/pg-diff-stat.txt
printf '\nPatch:\n'
cat /tmp/pg-patch.diff
} | claude -p > "$report"
printf 'Review written to %s\n' "$report"
保存为 review-patch.sh 后，可以运行：
chmod +x review-patch.sh
./review-patch.sh origin/master ai-patch-review.md
运行前需要把 origin/master 改成实际的基准分支。如果补丁包含凭据、客户数据或尚未公开的安全问题，不应直接发送给外部模型；应改用组织批准的环境，并检查数据保留与访问策略。
把测试结果交给模型，但把判定权留给测试系统
AI 可以组织测试流程，但测试命令本身必须由确定性的工具执行。一个稳妥的模式是：脚本运行测试并保留原始日志，模型只负责归纳失败，而不能把摘要当成测试结果。
下面是一个可改造的示例。具体的构建参数和并行度需要根据开发环境调整：
#!/usr/bin/env bash
set -uo pipefail
log_dir="${LOG_DIR:-artifacts}"
mkdir -p "$log_dir"
set +e
make -j"${JOBS:-4}" check-world 2>&1 | tee "$log_dir/check-world.log"
test_status=${PIPESTATUS[0]}
set -e
{
printf '%s\n' \
'Analyze this PostgreSQL test log.' \
'Separate the first causal failure from downstream failures.' \
'Quote exact test names and error lines.' \
'Do not claim the test passed or failed beyond the supplied exit code.' \
"Process exit code: $test_status" \
''
tail -n 2000 "$log_dir/check-world.log"
} | claude -p > "$log_dir/test-analysis.md"
exit "$test_status"
这个脚本保留了三个重要性质：原始日志可审计，退出码不会被模型覆盖，模型看到的输入范围受到限制。对于基准测试，还应记录 PostgreSQL 配置、编译选项、硬件、数据规模、预热方式和重复次数，否则模型很容易为噪声编造解释。
邮件线程与补丁审查需要不同的提示词
长邮件线程的难点是观点不断演化。同一句建议可能已被后续实验否定，也可能只适用于旧版本补丁。因此，线程分析不应只要求“总结”，而应要求模型保留时间顺序和意见归属。
可以使用这样的提示模板：
You are analyzing a PostgreSQL development email thread.
Produce:
- a chronological list of proposed approaches;
- the author of each technical claim;
- evidence offered for and against each approach;
- questions resolved later in the thread;
- unresolved questions;
- assumptions that need verification against the current source tree.
Do not merge conflicting opinions into a consensus.
Do not invent conclusions when the thread is incomplete.
Quote message identifiers or dates when available.
补丁审查则要强调可定位的问题：涉及哪个函数、触发条件是什么、需要什么测试。模型给出的宽泛建议，例如“注意线程安全”，对提交者帮助有限；能够指出锁顺序、资源释放路径或错误处理分支，才值得进入人工审查队列。
在源码树中为 AI 补足工程上下文
工作坊还讨论了如何修改或增加源码树中的内容来改善 AI 使用。可以这样实践：在仓库中维护一份简短、可审查的 AI 指南，记录构建入口、测试层次、禁止事项和补丁输出要求。它不应复制整份开发文档，而应把模型导向权威文件和确定性命令。
例如：
# AI_WORKFLOW.md
## Validation
- Run `git diff --check` before reviewing a patch.
- Use `make check-world` for broad validation when the environment supports it.
- Preserve complete logs under `artifacts/`.
## Review boundaries
- Treat generated patches as experiments until reviewed by a committer.
- Never infer concurrency safety from compilation or regression tests alone.
- Identify affected functions and propose focused regression tests.
- Do not send private bug reports or credentials to unapproved services.
这类文件的价值不在于写得长，而在于它与项目实际流程一致，并能跟随构建系统和审查规范一起更新。
采用时检查四件事
引入 AI 工具前，可以用四个问题约束工作流：输入是否允许离开当前环境，命令是否可能修改源码或系统状态，结论能否由日志和测试复核，最终补丁是否仍由熟悉该模块的人审查。
比较合适的起点是只读任务：归纳邮件、定位代码、整理测试失败和提出测试矩阵。等团队建立提示词、权限、日志留存和人工审查规则后，再逐步允许工具生成概念验证补丁。AI 能显著降低探索复杂想法的门槛，但 PostgreSQL 的正确性标准不会因此降低；它带来的最好结果，是让开发者更快获得证据，而不是更快跳过证据。