有人在博客里写,自己现在写代码,更多时间花在“用文字实现”上——写详细的提示词、画系统边界,把原本敲代码的时间挪去敲文档。这话乍一听很合理:AI接管了敲键盘的活,人负责想清楚要什么。可你真去测一下,这套“时间转移”的说法未必站得住。
实测:越老练,越可能被拖慢
METR做过一次对照实验:16名经验丰富的开源开发者,在自己最熟悉的代码库里做246个真实任务,一部分随机分到“可以用AI”,一部分不能用。结果是,允许用AI的人平均反而多花19%的时间才干完活。
更扎心的是感受错位。动手前,这些开发者预测AI能让自己快24%;做完之后,即便数据摆在眼前,他们依然坚持认为自己快了20%。经济学家和机器学习专家事先押注的提速幅度更夸张,分别是39%和38%。没有一个群体猜对方向。
为什么懂代码的人反而更慢
原文作者自己也提到,上下文窗口是硬约束——代码库越大,能塞进提示词的信息占比越小,过厚的文档反而没用。这不是错觉。检索类基准测试显示,AI agent在大代码库里常见的毛病是“高召回低精度”:检索出一堆看似相关的文件却用不上,复杂检索脚手架带来的提升,远不如底层模型本身的进步。LongCodeBench更直接:上下文涨到接近百万token量级,某些模型的正确率能从29%掉到3%——“上下文窗口大”和“会用上下文”是两件事。
我更在意的是,原文那句“仍在用文字实现”听着云淡风轻,其实藏着一个没验证的假设。对一个对代码库了如指掌的老手来说,这恰恰是最吃亏的场景:AI要花时间去“调查”一个他一眼就能定位的问题,生成看起来合理却难合入的代码,还得让人逐行核对。省下的敲键盘时间,搭进去做审查和纠错。
- 结论.AI在“生疏代码库+常见模式”场景表现更稳,在“专家+成熟代码库+定制任务”场景反而拖后腿。
挑模型的依据也在松动
原文建议“为任务挑对模型”,听着是常识,但挑选的依据本身出了问题。OpenAI在2026年2月宣布放弃SWE-bench Verified,理由很直接:GPT、Claude、Gemini三大模型家族都被发现能“复现原始解答的痕迹”,基准已被污染;不少判定失败的任务,其实是模型交出了功能正确的补丁,却被测试脚本误判。就算是更新的SWE-Bench Pro,OpenAI自己估计公开任务里约三成也有问题:测试过严、需求写不清、覆盖不足。
厂商还在照常放榜:Claude Opus 4.6在SWE-bench Verified上跑到80.84%,Gemini 3是76.2%,GPT-5是74.9%——GPT-5这个成绩还是剔除了23个在自家基础设施上跑不稳的任务之后得出的。三个数字挂在同一张榜上,看着像模型能力的排名,实际上脚手架、提示词、重试次数都不一样,根本不是同一把尺子量出来的。
- 风险.公开榜单分数已不能直接横向比较,靠榜单选型的决策基础比想象中脆弱。
接下来该看什么
体感会骗人,榜单也会骗人,只有秒表不会。
METR在2026年2月又做了一轮回访,用上更新的工具:老参与者提速18%,新招募的参与者只有4%,但两组的置信区间都包含“没有效果”,METR自己都判定这批数据因幸存者偏差不可靠,没能干净推翻此前“变慢”的结论。也就是说,“AI到底有没有让资深程序员变快”,现在还是一个悬而未决的问题,谁都别急着下定论。
对普通开发者和团队来说,更现实的做法,是原文作者自己无意中点出来的那条路:与其信公开榜单或个人体感,不如拿自己的代码库、自己的任务,搭一套小规模的私有评测,老老实实跑一遍再下结论。敲代码的时间确实在减少,但把它换算成“设计和提示词的时间一定划算”,目前还看不出证据。
那位博主说自己“仍在用文字实现,而非代码”,这句话本身没错——错的是把这种转移默认当成一件净赚的事。时间从键盘挪到了文档,谁也没规定这笔账一定是赚的。