加载失败
原讨论源于对一项用 SWE-bench（以测试通过为准的代码生成基准）评估 LLM 提交 PR 的实验：结论显示许多能让测试通过的改动，在真实维护者眼里不会被合并。评论基于亲身案例与经验把问题归结为两类：一是模型会产出功能正确但臃肿或不可读的实现；二是基准仅衡量行为正确，忽视与代码库约定、架构一致性与维护成本。大家从模型机制（next‑token、RL 奖励）、替代度量（diff、复杂度、熵）以及治理手段（AGENTS.md、lint、仓库专属 eval）多角度讨论如何把“能跑”变成“可合并”。许多实践者分享了用多轮精简、定制规则或人工引导把代理产出变成可接受代码的经验。
大量亲历者举例说明 LLM 生成的代码虽然能通过测试，但常常冗长、控制流奇怪或掩盖异常，导致不可读不可维护。比如有人拿 Codex/GPT 生成的 Rust proc macro 最初约 480 行、改写后 >600 行，人工精简到 <230 行可读性才接受；另有 Claude Code 的 624 行被重写为 334 行甚至 400→130 行的案例。评论普遍描述这类输出像“意大利面”或“三年级学生式”的“能跑即好”实现，必须靠多轮精简、重构或人工改写才能达到维护者接受的质量。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
很多人认为 SWE-bench 等以“tests pass”为准的基准只能证明行为正确，但不衡量与代码库约定、架构契合、可维护性和团队风险偏好等合并门槛。评论建议增加结构性信号（如 diff 大小、引入新模块/依赖、抽象深度）或为具体仓库做“evals for your repo”以对齐真实审查标准；并提醒把测试分数当作弱先验而非决定性指标。实证中也看到在若干开源仓库上不同模型测试分数接近时，代码质量和与原 PR 的等价性却差别很大，说明单纯测试会误导选择。
评论指出维护者对 AI 协助代码存在心理偏见：一旦怀疑是机器产出，审查者更容易默认是“LLM slop”，有时选择静默搁置或直接拒绝，即便功能正确。也有反驳称很多拒绝源于维护者过载、时间有限或合理的工程判断，而不是单纯反 AI；但总体社区信任度低确实提高了合并门槛。另有讨论显示盲审并不总能完全掩盖机器写作的痕迹，审查理由常落在风格、注释或额外摩擦上。
多数人主张用工程化手段约束和校准代理：维护 AGENTS.md/CLAUDE.md、编写定制 linter 规则、为仓库构建专属评测，或把不想要的模式写成会失败的测试（例如用正则检测反模式）以自动拒绝。实践中，增量小步提交、把设计先拆成接口/签名再实现，以及让 agent 在交互中“记忆”学习到的偏好，都能显著减少审查负担。评论把这些做法视为把“能跑”变为“可合并”的可行路径，而不是寄希望于通用模型自发有好 taste。
多条评论把问题归结为模型的生成机制与训练目标：作为 next‑token 预测器的 LLM 无法像人类那样自由回溯和大幅重构，倾向于不断“追加”代码而非删减重构。另有观点指 RL 微调与奖励信号可能把模型朝短期让测试通过的策略拉拢，超高推理设置（如 xhigh）或不同 quant 化也会引入过度复杂或不稳定的行为。这些机制性解释提示改进需要从训练/评估目标、推理超参和代理工作流入手，而非单靠更强的模型就能解决。
评论提出多种替代或补充指标来评估 PR 是否应合并：包含 diff 大小、McCabe 环路复杂度（cyclomatic complexity）、以及将程序映射到最小比特表示来计算代码的“熵”或 cross‑entropy。有人具体建议把时间到完成视为对数正态分布以避免负区间并解释项目延期的偏态风险，并讨论用类型系统估算最大熵以评估实现相对于规范的冗余。评论认为这些量化指标比单纯的“测试绿灯”更能反映长期维护成本，但也承认指标会被规避且需结合人工判断。
部分评论持乐观或务实态度：在有经验工程师引导、良好上下文与多轮精炼下，LLM 可当作快速编码和重构工具显著提速。实践案例包括先生成接口/签名再实现、用 Claude Code Opus、Gemini 3 Pro 等模型做精简与复审，以及把仓库历史和规范喂给 agent 以形成合适的行为准则。另有观点认为模型可能发现“非人类但有价值”的新方法（类似编译器或 AlphaGo 的非直觉策略），但要把这些创新落地仍需技能、治理与审查的配合。
SWE-bench: SWE-bench：一个用于评估模型在写代码任务中能否通过既定测试的基准（tests‑pass 导向），评论中讨论其作为合并决策代理的局限性。
LLM (large language model): LLM：大型语言模型，基于 next‑token 预测生成文本/代码，评论多以此为因解释生成倾向与局限（如无法任意回溯重构）。
AGENTS.md / agentic workflow: AGENTS.md：用于告诉代理（agent）仓库约定、架构与流程的文档或配置，能作为工程化手段让自动化编码符合团队风格。
McCabe cyclomatic complexity（环路复杂度）: McCabe 环路复杂度：衡量程序中控制流复杂度的指标，可用来估算可测试性和维护难度，评论建议与 AI 评估结合使用。
代码熵 / information entropy: 代码熵（信息熵）：用信息论衡量代码中信息量或复杂性的概念，评论提到把程序转为最小比特表示或计算 cross‑entropy 来度量实现与常见抽象的贴合度。
Quantization（Q4/Q6 等）: Quantization：模型权重量化级别（如 Q4、Q6）影响推理表现与稳定性，评论中有人讨论不同 quant 对代码生成质量的影响。