Jeremy Schneider：Postgres SBOM 上的智能体失控：推倒重来
内容提要
作者为 CloudNativePG 构建 Postgres 扩展容器，重点解决 SBOM 与来源验证问题。初期 PGRX 与上游验证命令不一致导致用户困惑，后改用 Docker 自定义 SBOM 生成器重构，将逻辑集中于单一模块，构建改动极小。AI 可加速编码但无法判断正确设计。项目已可测试，包含 PG-Cron 等扩展，后续将合并 PR 并提交上游。
延伸解读
设计一致性的重要性
文章指出，初期PGRX与上游验证命令不一致，导致用户困惑。作者认为需要单一、一致的命令来验证来源和SBOM材料。这提醒我们，在设计工具时，用户体验的一致性至关重要，尤其是当底层实现不同时，应尽量统一对外接口，减少用户的学习成本。
AI辅助开发的局限
作者使用AI智能体加速编码，但AI无法判断正确设计。AI依赖开发者提出正确问题和明确目标优先级。这强调了在AI辅助开发中，人类仍需主导设计决策，AI更适合执行具体任务，而非替代架构思考。
Docker自定义SBOM生成器的优势
作者重构后采用Docker自定义SBOM生成器，将逻辑集中在单一模块，构建管道改动极小。这种方法提高了代码的优雅性和可维护性，同时保持了构建流程的简洁。对于需要生成SBOM的项目，这是一个值得借鉴的实践。
项目现状与未来计划
CNPG-Extensions项目已可测试，包含PG-Cron等扩展，并实现了自动化更新。作者计划合并PR并提交上游，未来将提供完整的SBOM和来源证明。对于CloudNativePG用户，这是一个值得关注的替代方案，但需注意其尚未完全上游化。
Q&A
CloudNativePG 的 Postgres 扩展容器项目主要解决了什么问题？
该项目为 CloudNativePG 构建 Postgres 扩展容器，重点解决 SBOM（软件物料清单）和来源验证问题，确保容器具有完整的清单、来源和证明信息。
为什么作者决定重新设计 SBOM 生成方案？
因为最初 PGRX 和上游的验证命令不一致，导致用户需要不同的命令来验证安全性和来源信息，这太令人困惑。作者认为需要提供一个简单、一致的命令来验证来源和 SBOM 材料。
重构后采用了什么技术方案来生成 SBOM？
重构后使用了 Docker 的自定义 SBOM 生成器功能，并包含一个插件 API，供后续 PGRX 构建过程使用。大部分逻辑集中在自定义 sbom-generator 模块中，构建管道的改动非常小。
AI 在项目开发中起到了什么作用？有哪些局限性？
AI 可以加速编码，但无法判断正确的设计。它依赖开发者提出正确的问题并明确设计的目标和优先级，不能主动告诉开发者什么才是正确的设计。
CNPG-Extensions 项目目前包含哪些扩展？
包含 PG-Cron、PG-Partman、PG-Hint-Plan、PG-Stat-KCache、PGSentinel、PLDebugger、PLProfiler、MySQL/MSSQL FDWs 等众多扩展。
项目目前的进展和后续计划是什么？
项目已可供测试，具有比上游更先进的自动化（如 Renovate 自动更新）。后续计划包括：重构 PGRX 分支以保留原生构建主机、清理文档和代码、向上游提交 PR，并继续处理其他上游 PR。
