AI 的标杆是所有权

Publiczny Profil 的文章《It Still Can't Do My Job》用一条犀利的时间线梳理了从 2022 年 ChatGPT 发布到 2026 年 7 月的 AI 编程争论，并延伸到 2027、2028、2030、2033 年的预测。核心论点是：很多对 AI 的否定在当时是合理的，但随着工具进步，这些说法很快就过时了。

我的看法是，这篇文章的价值不在于给预测打分，而在于提醒我们：软件行业一直在用错误的尺度衡量工作。代码生成早已不是那条有趣的边界线。真正的边界是所有权：谁理解这次变更，谁负责验证，谁能回滚，上线之后谁来担责。

答案快照

问题	我的看法
发生了什么？	2026 年 7 月的一篇文章把四年来的 AI 编程争论梳理成一连串不断移动的标杆——从"写不好玩具程序"到"生产环境谁来负责"。
为什么重要	这个论点最有力的版本不是"AI 什么活都能干"，而是：旧的能力质疑衰减得很快，团队需要比凭感觉更靠谱的检验方式。
做好了谁受益？	开发者、工程负责人、安全团队、产品人员——他们需要 AI 工具帮助产出经过审计的软件成果，而不只是更大的 diff。
我的论点	标杆应该挪。应该从"模型能不能写代码"挪到"组织能不能为模型帮助交付的东西负责"。

文章是一面镜子

这篇文章有说服力，是因为它没有假装怀疑派一直就是错的。它从 2022 年 12 月的 Stack Overflow 事件讲起：当时社区临时禁止了 ChatGPT 生成的回答，因为版主们说平均正确率太低，数量又太大，压垮了志愿审核。那是实打实的问题，不是单纯的反 AI 情绪。

后面的条目则说明这种质疑没法一直停在原地。Google 在 2024 年 10 月的财报发言中提到，Google 超过四分之一的新代码由 AI 生成，再经工程师审核接受。METR 2025 年 7 月的研究发现，经验丰富的开源开发者在使用 2025 年初的 AI 工具操作自己熟悉的仓库时，反而慢了 19%；不过 METR 后来提醒这个结果已经过时，很可能无法反映 2026 年初工具的实际影响。Google DeepMind 还报告，一个高级 Gemini Deep Think 模型在 2025 年国际数学奥林匹克竞赛中达到了正式金牌水准，六题解出五题，拿到 35 分。

这些事实并不能解决"工作会不会被替代"的问题。但它们确实让轻率的肯定或否定都站不住脚。一个模型可以在 2022 年对 Stack Overflow 质量构成威胁，2024 年在 Google 用于经过审核的代码生成，2025 年在某项成熟仓库生产力研究中表现令人失望，又在同一年展现出顶尖的数学推理能力。这些事情完全可以同时成立。

我会保留的部分

这篇文章最有价值的一条思路是：质疑需要有保质期。"它写不出贪吃蛇"只在它确实写不出贪吃蛇的时候才是有用的批评。"它写不了生产软件"要有用，就得说清楚具体的生产测试：哪个仓库，什么风险等级，走什么审核流程，怎么回滚，谁来负责。

很多 AI 讨论到了这里就开始变糊。支持者夸大了从 demo 到稳定系统之间的距离。怀疑者有时把每一种失败模式都当成永久性的。更有用的态度要窄得多：说清楚任务类别，衡量输出，然后判断人的工作是前移了、后移了、还是真的消失了。

公开分歧本身就是重点

围绕这篇文章的 Hacker News 讨论已经很好地画出了这条分界线。一些读者把这条时间线当作有用的证据，说明大家一直在低估 AI 的进展。另一些人反驳说，幻觉问题并没有消失，高管的说法往往跑在现实前面，替代工作岗位和做出更好的软件也不是一回事。还有几个人把注意力放在这篇文章本身是否带有 AI 写作的质感上——这也算是围绕这个话题的文化疲劳的一部分。

我不会把这些反应总结成某种共识。把它们当分类来看更有用。乐观派看到的是能力在持续叠加。怀疑派看到的是验证、经济和问责问题还没解决。务实派问的是：AI 到底在哪里真正消除了工作，而不是把工作挪进了审核、治理或清理环节。

METR 是那张警示标签

METR 2025 年的结果之所以重要，是因为它同时打破了两种简单化的叙事。这项研究让 16 位经验丰富的开源开发者在他们熟悉的仓库上完成 246 个真实任务，结果出人意料：允许使用 AI 工具时，完成速度反而更慢。Sean Goedecke 的分析很有价值，因为他点出了这个实验设置的关键：在大型成熟代码库里工作的资深维护者，在熟悉的问题上本来就已经非常快，而高质量的库或编译器工作，留给随手生成补丁的余地本来就不大。

但 METR 在 2026 年 2 月的更新同样重要。METR 表示旧结果已经过时，后续实验数据存在选择偏差，而且到 2026 年初，开发者从 AI 获得的加速很可能比 2025 年初更多。测量问题变得更难了，因为开发者越来越不愿意脱离 AI 工作，会选择不同的任务，还会同时使用多个 Agent。

这正是 Publiczny Profil 那篇文章能落地的原因。标杆确实挪了，但不是沿着一条干净利落的直线挪的。测量目标变了，因为工作流变了。当 Agent 在并行跑，开发者在旁边监督、暂停、审核、切换上下文时，用秒表来量生产力就比早期的编码时间研究更难读。

所有权才是新标杆

GitLab 2026 年 6 月的 AI 问责研究为这场争论提供了更具体的企业视角。他们报告，91% 的受调查组织正在使用两个或更多 AI 编码工具，78% 表示开发者编写和提交代码的速度更快了。但同时也报告，85% 认为 AI 把瓶颈从写代码转移到了审核和验证上，82% 认为 AI 生成的代码有可能制造出一种组织还没准备好应对的新型技术债。

这才是我在意的那个标杆。如果代码生成得更快，但组织说不清代码从哪来、本来要做什么、上线之后谁负责，那收益就是不完整的。可能仍然值得用，甚至可能带来根本性的变化。但工作并没有消失，它只是变了形状。

我还不会照单全收的部分

这篇文章的预测部分读起来有意思，但我不会把它当证据。2027 年一个打磨完善的开放世界游戏、2028 年一个季度完成遗留单体重构、2030 年 AI 独立值班、2033 年零员工的十亿美元创始人——这些是故事桥段。它们可能猜对也可能猜错，不应该和 Stack Overflow 的政策变化、Google 财报发言、METR 的数据、DeepMind 认证的 IMO 成绩塞进同一个证据桶里。

移动标杆这个框架的风险在于，它容易把所有谨慎都等同于否认。有些谨慎确实是否认，有些是纪律。一个生产环境工程师追问来源、安全、回滚、测试、延迟、成本和问责，不一定是在把标杆从 AI 身边挪开。他可能是在把标杆挪向这份工作中一直真实存在的部分。

我的收获

我喜欢这篇文章，因为它拒绝接受"今天 AI 的边界会停住不动"这种安慰人的想法。但当它把未来描绘得不可避免、而不是基于实际测量时，我就不太信了。正确的反应既不是恐慌也不是耸肩，而是不断更新衡量标准。

对软件团队来说，这个标准现在应该是所有权。给我看任务，给我看 diff，给我看测试，给我看模型看到了什么，给我看它改了什么、猜了什么、跳过了什么，合并之后谁准备接 pager。如果 AI 能在更难更乱的工作上持续通过这个测试，那标杆就应该再挪。在那之前，"它还是干不了我的活"既太宽泛也太舒服了。