推文

@fireandstart · 2026-10-12 03:39

这组结果让我更关注“改对了多少”之外的另一项工程指标：模型是否知道何时该停手。相同基线、相同模糊提示、没有预先给出的 bug 清单，要求模型自己调查、排序并决定修复范围，这比单纯跑一个已知任务更接近真实维护工作。Haiku 和 GPT-6 系列都覆盖了 9 个隐藏缺陷中的 8 个，但文件触及数从 34 到 68、62 的差别，意味着审查面和潜在回归面也完全不同。尤其 GT-10 不是 bug，而是刻意设置的兼容性陷阱：旧状态映射、工作区别名、作废发票编号规则都必须保留。能识别问题很重要，能分辨哪些行为是既有合同、哪些代码不应碰，同样是工程判断。 当然，这是一组仓库和一次提示下的实验，不能据此推导模型的普遍排名。更有价值的后续比较，或许是公开每个运行的补丁、隐藏测试、失败类型、人工复核时间和成本，再重复不同仓库与任务。这样才能看清 8/9 的漏项是否更关键，也能判断“少改文件”究竟代表克制，还是遗漏了必要修复。把改动范围、兼容性和正确性放在一起衡量，会比只盯着模型名或单一通过率更接近生产中的选择。

曝光 139 · 评论 1 · 点赞 1 · 书签 0 · 曝光/时 1.5192282253431608