加载失败
METR（来自 metr.org）的研究以“one-shot PRs”（无需人类反馈即可直接合并的 PR）为核心指标，得出在该指标上模型在过去一年没有显著改进的结论。讨论触及两条主线：一是许多开发者在实际工作中感受到 Opus/Sonnet、Codex 等近期版本与 agentic 工具（如 Claude Code）带来的生产力跃迁；二是批评者指出 METR 的样本稀少、遗漏关键版本并把不同厂商模型混合分析，从而使统计结论可疑。评论还把争论扩展到评估方法（如 Brier score、cross‑validation）、工程化改进（agentic tool loops、context rollbacks）与软件工程类比（PSP/TSP），并讨论数据污染（Ouroboros）与成本优化对未来改进路径的影响。
不少从业者和业余项目持有明显相反的结论：他们在日常开发里感受到最近几次版本带来了实质性提升，尤其指向 Anthropic 的 Opus 4.5/4.6 和 OpenAI/Codex 的点释版本。具体例子包括有人说 Opus 4.6 在 Claude Code 中把 agentic 编程从“实验性质”变成可依赖的生产力工具（有评论提到完成了项目中约 75% 的功能），另有用户指出 Codex 5.3 在小众语言如 QML/C++ 上产出更符合习惯用法的代码。常见的正面变化包括减少重复代码、改进的重构/查找既有工具函数能力，以及更好的指令遵循，令实际工作流速度明显提升。多位评论用“night and day”、“game changer”来形容体验差距，称这些改进在工程实践中能显著节省时间。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
对 METR 结论的主要反驳集中在方法论与数据集上：研究以“one-shot PRs”（无需人类反馈即可合并的 PR）为度量，但样本点稀少且把不同厂商/模型混在同一条时间线里。评论指出研究遗漏了被广泛认为关键的发布（如 Opus 4.5/4.6、Gemini），并且 OpenAI 只有一个数据点（GPT5）会把右侧表现人为拉低，从而改变拟合结论。还有人批评统计处理（如 cross-validation、Brier score 的使用和模型比较）可能被误解或过拟合，且把不同实验室的模型当作单一时间序列来拟合本身有偏差。总体观点是：以如此有限且混合的观测来断言“模型一年没进步”并不可靠，应该按厂商/系列分开或补上漏掉的关键版本再判断。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
大量评论认为感知到的生产力跃迁更大程度源于上层工程（即所谓的 harness），例如 Claude Code 的 agentic tool loops、CLI/终端集成、sub-agents、persistent context/rollbacks 等。这样的 harness 允许模型拆解任务、调用工具、运行 smoke tests 和做多文件变更，从而把模型的原生 one-shot 表现放大为可靠的工作流能力。若只测量模型的单次输出（one-shot PR），就忽视了这些系统级改进对实际合并率与开发速度的贡献；许多用户把日常效率提升归因于工具整合和上下文管理而非模型“单步推理”能力的大幅跃迁。评论里也提到终端/agentic 界面比传统聊天界面在某些场景体验上优很多，这进一步说明是工程化而非单纯模型参数带来的变化。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
多位使用者的共识是：模型可以交付更大块的产出，但代码质量、架构合理性和细节可靠性仍未同步达到可完全信任的水平。评论举例包括过度嵌套控制流、不符合既有代码风格的变化、前端用 CSS hack 替代正确重构，以及出现“useless AI slop comment”之类的质量问题；还有人形容模型像“聪明但有严重额叶缺损的朋友”，自信输出却会漏掉关键验证。结果是虽然交互轮数可能减少，但审查单次产出所需的认知负担可能上升——你必须在更大代码块里寻找并修复隐藏的问题。整体结论是：产出量和块大小提高了，但复杂任务仍然要靠人工密集回顾、测试和设计判断。
有评论把当下的缓和归因于训练数据与经济现实：互联网语料有限，新代码里越来越多由 LLM 产出带来 Ouroboros（自我循环）和污染风险，使得单靠规模扩大不再容易带来巨幅提升。与此同时，企业在 token-use 优化、合成数据和后训练（post-training）/RL 管线等方向投入以控制成本，研究重点逐步从单纯放大参数转向 agentic 工程与 harness 优化。多位评论认为未来几年更可能是生态系统、工具链与成本下降的改进期，而不是像 2023/24 那样的能力跨越式提升。该观点也结合了对模型策划、数据净化与长期可训练集稀缺性的担忧。
若以盲测或标准化任务来对比，不少人认为常见日常任务难以区分 4.5 与 4.6，感知差异部分来自用户 prompt 技能、工具熟练度以及行业对 agentic 流程的接受度升级。部分自托管者出于对闭源 scaffolding 的不信任减少频繁测试，有些人也承认自己随时间学会了更好地“驾驭”模型，从而觉得工具变好了。因此“我感觉进步很大”和“研究显示没进步”之间，可能存在样本偏差、文化采样与主观认知差异。评论建议更多标准化、面向反馈循环（incorporate feedback）的 benchmark 来衡量长期进步而非单次合并率。
harness: 指在 LLM 之上的工程化工具与工作流（例如 Claude Code、agentic loops、终端/CLI 集成），负责上下文管理、工具调用与多步执行，从而把模型能力“放大”为可用产品化功能。
one-shot PRs（merge rate）: METR 用的度量：AI 生成的 pull request 在没有人类反馈的情况下被维护者直接合并的比例；该指标对维护者偏好、仓库隐含约定和评审 rubric 非常敏感。
METR（metr.org 的 Many SWE Bench）: 来自 metr.org 的研究，把维护者对 AI 生成 PR 的接受/拒绝及拒绝原因作为实测数据，试图量化 LLM 在真实代码库的一次性合并能力。
agentic / agent: 能够主动拆解任务、调用外部工具（如 CLI、子 agent、网络 API）并在多步循环中执行的系统或工作流，常用于实现自动化的“agentic coding”。
Brier score 与 cross-validation: Brier score 是衡量概率预测误差的指标；cross-validation（如 leave‑one‑out）用于评估模型预测的泛化能力，二者在文中被用来比较拟合函数与测试预测力。
PSP/TSP: PSP/TSP（Personal/Team Software Process）是软件工程里的质量改进方法，强调对任务分解、回顾与缺陷根因分析的个人/团队责任，评论者用它来类比如何持续发现并修复 LLM 产出的常见错误。