页面加载出错，提示重新加载。合并 ClickHouse（ClickHouse）下 ClickBench（ClickBench）的 2165 号拉取请求（pull request）可能会关闭相关问题，但显示 None yet，Assignees No one assigned。之后再次加载出错，并出现代码建议提示：建议可批量作为单次提交，未改动代码则无效；拉取请求关闭、查看部分变更、待处理评审、多行评论或排队合并时无法应用；删除行不支持，须修改当前行代码才能生成有效建议，且当前无法应用，需稍后再试。

成功合并这个拉取请求后，可能会关闭相关的问题，但目前暂无；其他相关项也暂无。该拉取请求尚未指派给任何人，指派人一栏显示为“无人指派”。

围绕用 Rust 重写 PostgreSQL 的 pgrust 在数据库基准 ClickBench 中因涉嫌作弊被要求除名，多数评论把它当作 AI 或氛围式编程项目失控的证据，少数人则认为指控多为误解、作者已用开源测试版自证，并批评社区借机宣泄反 AI 情绪。

质疑 pgrust 是靠 AI 或氛围式编程刷榜、工程质量失控

• 多名评论者把事件解读为 AI 辅助开发的典型翻车：提交差异大到 GitHub 无法渲染、疑似针对基准查询做手写优化或缓存、超出基准范围就难以支撑；失望、对超长拉取请求摘要无人阅读的吐槽，以及“报告和新提交都像大语言模型写的”的怀疑，都被归入对 AI 项目的不信任。（较多人） > 有人形容这像 Claude 在“作弊”，人类则闭眼写代码，项目越往后越难推进。（@verdverm）

认为作弊指控多系误读，作者已用可审计的测试版自证

• 项目作者详细说明：被提交的只是早期预览版，真正跑分走的是 SQL 到 Gravity IR 中间表示再到汇编的即时编译管线；所谓“结果缓存”其实是字典压缩里的谓词或条件缓存，ClickBench 允许保留这类中间数据缓存，ClickHouse 自己也有类似缓存。之前只支持 43 条 ClickBench 查询属于过早提交，新的测试版已支持几乎所有 PostgreSQL 的 SQL，只差部分 CTE 和 MERGE 语句的缺陷；若发现问题欢迎指出，他们会继续修。（高赞） > 作者表示，与其在 GitHub 上争辩，不如把 0.4 做完并开源，让大家直接审计。（@malisper）

认为社区在借题发挥，误导读基准并非 AI 项目独有

• 有人提醒，不准确或误导性的基准在 AI 时代之前就长期存在，既有真作弊也有无心之失；重点不是它是否由 AI 生成，而是作者是否承认并修正。该观点认为本贴更像用现成结论去印证既有敌意，而不是就事论事。（少数人） > 有人认为，作者已经承认并试图修正问题，而跟帖却更像借这件事为既有的反 AI 情绪找证据。（@acalvino4）

认为基准方法本身有缺陷，应在随机数据上验证

• 有评论者把争论拉回方法论：如果基准结果没有随机化、又可能命中缓存，就很难说明真实性能；因此部分基准应该在随机数据上运行，否则容易退化成对固定查询的过拟合。（少数人） > 有人把事件概括成一句话：基准没有随机化，某处返回了缓存结果。（@bmacho）

有价值的补充

• 背景：pgrust 是 PostgreSQL 的 Rust 重实现，ClickBench 是数据库基准测试集，相关拉取请求正是因涉嫌作弊要求把 pgrust 移除；ClickBench 规则允许保留中间数据缓存，因此“有缓存”不直接等于直接缓存查询结果。（@teiferer）
• 有人提问“先发测试版、几周后再放源码”在开源里是否正常，显示部分人关注的是发布与审计流程，而不是 AI 本身。（@torben-friis）
• 面对连续版本说明，有人调侃要先坐等 pgrust 0.5 再介入风波，折射出部分人对“预览版/测试版”节奏的疲劳与不信任。（@HackerThemAll）