一位开发者打开IDE仪表板,看到「PCW 98%」显示——意思是98%的代码是AI写的。这不对劲,所以他做了实验。结果令人震惊:当他手动输入49个字符时,系统只承认其中46个是人类贡献,而把自己代码复制粘贴一行直接归零,全部计入AI得分。
到底发生了什么?
2026年4月,William O'Connell在自己博客上发表了这件事。他在公司用Windsurf(基于VS Code的AI IDE),分析仪表板显示「% new code written by Windsurf」指标为98%。本人感觉只有10~20%。「我手写的代码比AI写的少49倍?那我应该早就把token预算用光、要么因为神级生产力被升职、要么因为49/50的开发者被解雇了吧?」于是他开始了实验。
Windsurf自己也在官方博客写道:「客户的PCW值通常会达到85%以上,常常95%以上。」「这不是幻觉,而是基于计算方式的准确数字」——他们这样强调。 但当你拆解测量方式时,声称这「准确」就站不住脚了。
O'Connell先尝试用mitmproxy拦截网络流量,但被protobuf编码挡住了。所幸仪表板的API响应中暴露了user_bytes、codeium_bytes、total_bytes、percent_code_written字段。他发现了5个偏差。
Windsurf PCW削减人类贡献的5种机制
1. 自动补全的闭合括号/引号不算人类输入。打49个字符,user_bytes只增加46。
2. 粘贴不计入user_bytes。把自己的代码移动到另一个文件?0分。
3. 重构整体记为AI得分。让AI移动你写的函数?100% AI贡献。
4. 没有会话边界。重启后,编辑器忘记每行的来源。
5. 「提交时测量」——并非如此。实际上每次输入计数器都在变。
O'Connell做了一个决定性实验:在human_file.js里手动输入一行(49字符),让AI在ai_file.js里写同长度的一行。然后他把自己写的函数复制到AI文件里,又让AI把自己的函数移到另一个文件。结果:AI被记为写了人类两倍以上的代码(67.9%)。其实两个文件长度几乎相同。
Cursor的「AI Share of Committed Code」是更诚实的git级测量。但当O'Connell粘贴一个100行的JS文件,让AI只把双引号改成单引号时,100行整体都被记为「AI编写」。AI实际只触碰了49行而已。 结果是,两种工具都有偏差,而方向永远是「高估AI比重」。
这为什么是更严重的问题?
Anthropic的Claude Code负责人Boris Cherny在2026年1月发推说「我的代码100%是Claude写的。公司整体也几乎100%。」引发了热议。 类似地,Microsoft CEO Satya Nadella自夸30%,Google则是75%。这是高管喜欢公布的数字,对AI公司来说也是证明自己工具价值的数字。
但METR的研究给出相反结果。在16名资深开源开发者的RCT(随机对照试验)中,使用AI工具的组慢了19%。更可怕的是他们都相信「AI让我变快了」——本人感觉快了20%,实际却慢了19%。
GitClear分析了5年内2.11亿行代码变更,结果同样震撼:重构比例从2021年的25%降到2024年的10%以下,复制粘贴代码从8.3%涨到12.3%,翻了4倍(历史首次「复制粘贴」超过「移动」)。 AI增加了代码量,但代码库的健康度以可测量方式恶化了。
| 厂商指标 | 现场该追的真信号 | |
|---|---|---|
| 测量单位 | 字节/行数(数量) | PR周期时间、合并后修复率(质量) |
| 偏差方向 | 高估AI比重 | 中立——合并后通过issue/回滚验证 |
| 测量时点 | 输入时或提交时 | 合并后7~30天内追踪 |
| 决策用途 | 「AI都做了,裁人吧」 | 「哪里在累积验证债务」 |
| 法律风险 | 「大部分代码不受版权保护」 | 保守估算人类贡献比例 |
这不只是指标精度问题。「我们公司90%的代码是AI写的」这一句话一旦说出口,经营层就会开始问「那为什么需要这么多人?」另外美国法院已明确AI生成作品不受版权保护,所以「大部分代码是AI写的」这个指标对法务团队来说是噩梦。
韩国现场也开始出现同样的烦恼。某公司内部指南文章引用Goodhart定律指出:「把AI代码接受率作为KPI,会导致不做质量验证就盲目接受的行为。」 另一位CTO则指出「AI 1分钟写完的代码,人要花10分钟review的讽刺」。 指标在说谎的同时,真正的成本已经转移到代码评审时间上了。
核心整理: 在PR里抓真信号的验证清单
- 把仪表板的PCW/AI Share数字只当「方向性」看
Windsurf自己的指南也明确写着「directional proxy」。绝对值无意义。只在同团队、同工具、同季度内追踪趋势变化。 绝对不要跨工具、跨团队比较。 - PR评审时先看「diff布局」
AI写的PR通常会把不需要改的地方一起改(O'Connell实验中「100行全是AI」的模式)。如果diff范围异常广,先问「这次改动的真实意图是什么」——这就是信号。 - 测试看起来太干净就要怀疑
METR研究发现,AI经常制造「用硬编码值通过的自我满足型测试」。 如果断言直接对比输入值,或者只有happy path没有边缘情况,就是红灯。加一个失败用例,看测试会不会崩。 - 自动检测重复代码和死代码
GitClear研究中翻4倍的复制粘贴模式如果进入PR,必须拦截。 jscpd、SonarQube duplications,甚至简单地用grep检查同一函数签名是否出现在两处,效果都很大。AI倾向于不重用现有代码,而是新写一份相似的。 - 「让AI为自己的代码辩护」
Adam Ferrari提出的验证模式:把PR diff交给同模型或别的模型,让它解释「为什么需要这次改动、可能有什么风险」。如果「作者」自己也说不清,那不是节省了评审时间,而是把债务推后了。
给经理的一句话清单
「我们团队AI代码比例是X%」这种汇报上来时,只问两个问题。① 这个数字是怎么算的?(Windsurf PCW?Cursor Share?自定义?)② 同一季度内PR合并后修复率、回滚率怎么变化的?两个问题都答不出来,这个数字就别用作决策依据。
想再深入了解
Your AI Might be Lying to Your Boss William O'Connell的原创实验记 — 直接调试Windsurf和Cursor测量方式的完整报告 williamoconnell.me
Percentage of Code Written Windsurf官方PCW说明 — 厂商立场:85~95%是正常的,以及6条caveat windsurf.com
METR: Early-2025 AI on Experienced Developers 16位资深开发者RCT — 用AI慢19%,但本人觉得快了20% metr.org
GitClear AI Copilot Code Quality 2025 2.11亿行分析 — 复制粘贴4倍,重构从25%降到10% gitclear.com
Anthropic、OpenAI「100% AI代码」发言报道 Boris Cherny和Roon声称自己代码100%来自AI fortune.com
Quantifying AI Coding Impact Adam Ferrari的测量模式分析 — PCW的局限和替代指标建议 adamferrari.substack.com
提高AI代码评审可信度的开发组织运营原则 韩国企业内部导入案例 — 在AI评审之上叠加资深评审的双层结构 brunch.co.kr
