# AI 的标杆是所有权

**Summary:** Publiczny Profil 那篇 AI 编程时间线之所以有价值，是因为它展示了旧质疑如何快速过时；在我看来，下一个衡量标准是所有权，而不是代码生成。

- Canonical: https://markhuang.ai/zh/news/ai-goalpost-is-ownership
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-07-03
- Section: News
- Tags: AI, 软件工程, Coding Agent, 开发者工具, AI 治理
- Source: [Publiczny Profil](https://publicznyprofil.github.io/ai_cant_do_your_work/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一个卡通开发者和 AI 助手在蜿蜒的代码块小路上移动抽象标杆](https://cdn.markhuang.ai/news/ai-goalpost-is-ownership/hero.webp)

*真正值得问的，不是 AI 的标杆有没有挪。而是新的标杆量的是所有权，还是噱头。*

[Publiczny Profil 的文章](https://publicznyprofil.github.io/ai_cant_do_your_work/)《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 生成的回答](https://meta.stackoverflow.com/revisions/421831/1)，因为版主们说平均正确率太低，数量又太大，压垮了志愿审核。那是实打实的问题，不是单纯的反 AI 情绪。

后面的条目则说明这种质疑没法一直停在原地。Google 在 [2024 年 10 月的财报发言](https://blog.google/company-news/inside-google/message-ceo/alphabet-earnings-q3-2024/)中提到，Google 超过四分之一的新代码由 AI 生成，再经工程师审核接受。[METR 2025 年 7 月的研究](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)发现，经验丰富的开源开发者在使用 2025 年初的 AI 工具操作自己熟悉的仓库时，反而慢了 19%；不过 METR 后来[提醒这个结果已经过时](https://metr.org/blog/2026-02-24-uplift-update/)，很可能无法反映 2026 年初工具的实际影响。Google DeepMind 还报告，一个高级 Gemini Deep Think 模型在 2025 年国际数学奥林匹克竞赛中达到了[正式金牌水准](https://deepmind.google/blog/advanced-version-of-gemini-with-deep-think-officially-achieves-gold-medal-standard-at-the-international-mathematical-olympiad/)，六题解出五题，拿到 35 分。

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

![一个卡通开发者把 AI 生成的抽象代码块分拣到不同的审核托盘里](https://cdn.markhuang.ai/news/ai-goalpost-is-ownership/why-it-matters.webp)

*实际的工作不是在抽象层面接受或拒绝 AI 输出，而是把该进产品的部分和需要修改或删除的部分分清楚。*

## 我会保留的部分

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

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

> **Info:**
>
> 严肃的问题不是 AI 能不能生成代码，而是周围的流程能不能把代码变成有人愿意为之负责的变更。

## 公开分歧本身就是重点

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

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

![一个卡通开发者和 AI 助手把速度、验证和所有权当作抽象符号放在天平上平衡](https://cdn.markhuang.ai/news/ai-goalpost-is-ownership/tradeoff.webp)

*这里的取舍不是速度与人力的取舍，而是速度与让速度真正有用的验证和所有权之间的取舍。*

## METR 是那张警示标签

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

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

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

## 所有权才是新标杆

[GitLab 2026 年 6 月的 AI 问责研究](https://ir.gitlab.com/news/news-details/2026/GitLab-Research-Reveals-Organizations-Are-Generating-AI-Code-Faster-Than-They-Can-Control-It/default.aspx)为这场争论提供了更具体的企业视角。他们报告，91% 的受调查组织正在使用两个或更多 AI 编码工具，78% 表示开发者编写和提交代码的速度更快了。但同时也报告，85% 认为 AI 把瓶颈从写代码转移到了审核和验证上，82% 认为 AI 生成的代码有可能制造出一种组织还没准备好应对的新型技术债。

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

![一个卡通开发者在发光的 AI 生成代码块通过生产环境关卡之前进行检查](https://cdn.markhuang.ai/news/ai-goalpost-is-ownership/workflow-risk.webp)

*生产环境的考验不是代码出现得够不够快，而是代码跨过上线门槛之前，来源、审核、测试、权限和回滚方案是否都看得见。*

## 我还不会照单全收的部分

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

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

## 我的收获

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

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