HN讨论 · 身份未知2026-08-20

审查验证 LLM 生成代码：过滤噪音与确认测试有效

开发者用 LLM 快速生成代码后，审查和验证成为瓶颈：LLM 审查返回的 findings 各不相同、需人工过滤；完全手动审查比重写更耗时；LLM 写的测试也无法确认是否断言真实产品流程。

查看原始信号hn:49378314

目标用户

使用 LLM 生成代码并需要保证代码质量与正确性的软件开发者

潜在需求

需要一种高效的审查验证方法，能降低 LLM 审查噪音、减少手动审查时间，并确认 LLM 生成的测试确实断言预期产品流程而非仅写通过/失败的逻辑测试。

发生场景

开发者可以快速生成大量 LLM 代码，但交付前必须审查和测试；让 LLM 审查会产生不同的 findings，仍需人工过滤噪音；如果完全手动审查，理解代码的时间可能超过自己重写。

来源证据

开发者指出用 LLM 审查代码会返回不同的 'findings'，仍需人工过滤噪音；完全手动审查又可能比自己写代码更耗时。

It's become very fast to generate code nowadays, but how do you review and test all of it? Every time you ask a model to review some piece of code, it comes back with different "findings". So, you still have to filter through the noise of their findings to get to actual defects. And if you try to do the full review manually, then it might take more time to just understand the code than writing it yourself from the beginning. As for testing, you can ask the LLM to write the tests, but you can't

https://news.ycombinator.com/item?id=49378314

为什么值得留意

LLM 生成代码的速度已大幅提升，审查验证却成为新的时间瓶颈；提问者明确描述了噪音、耗时和测试断言三个具体阻碍，评论也只给出零散的人工经验，尚无统一解法，适合探索工具或流程改进。

已有方案

人工介入流程（HITL）
测试覆盖率报告辅助改进测试
PR review agent 总结未解决的评论

未满足部分

LLM 审查结果噪音大，缺少过滤机制
手动全面审查代码耗时超过重写
无法确认 LLM 写的测试是否断言真实产品流程

可能延伸 · 模型推测

将多个模型对同一 diff 的审查结果自动交叉比对并合并重复项
结合覆盖率与需求语义，对 LLM 生成的测试断言做行为验证
把 PR 历史评论和 diff 作为上下文，自动汇总未解决问题并忽略已解决项

目前未知

仅一个 HN 帖子提问，样本量小
评论中的做法是个人经验，未被系统验证
提问者可能只是孤立个体，不代表广泛需求

继续核实

LLM 生成代码的审查中，'噪音 findings' 的比例有多大？现有工具是否已解决？
开发者目前如何确认 LLM 测试断言的是产品行为而非逻辑通过？
是否有开源项目已实现 PR review agent 的总结未解决评论功能？

主题词

llm code reviewgenerated code validationtest assertion qualityreview noise filtering