今年七月,一篇题为《AI Is a Bad Tool》的读者投稿在科技媒体ByteCode.News上刷屏。作者Hideki Idoru的论断很干脆:AI编程工具是彻底不透明的黑箱,没人能验证它生成的代码是否真的正确;所谓"AI能发现安全漏洞"是一句拿不出证据的空话;"prompt engineering"不过是继SEO之后又一场行业骗局。
这篇文章修辞力很强,情绪也很足。但把它放到过去两年真实发生的一批随机对照实验和大规模现场研究面前,四个核心论断里只有一个勉强站得住,其余的要么被数据打了折扣,要么直接被推翻。
生产力:"一概而论"这个判断先站不住
原文把AI编程说成纯粹的时间浪费。真实数据分裂得很厉害。Google内部对96名全职工程师做的随机对照实验显示,复杂企业级任务的耗时降低了约21%,只是置信区间偏宽。Microsoft联合Accenture和一家财富100强公司,对4867名开发者做了三组现场实验,AI访问权限与任务完成量提升26.08%相关,经验较浅的开发者获益更明显。
反过来,METR对16名经验丰富的开源开发者、246个真实任务做的随机对照实验发现,允许使用AI工具反而让任务完成时间增加了19%——尽管这些开发者主观上都觉得自己变快了。
三组实验方向完全相反,说明AI编程的净收益取决于任务复杂度、代码库熟悉度和开发者经验。METR的反直觉发现尤其值得留意:在成熟代码库里干活的资深工程师,用了AI反而更慢,但他们自己感觉不到。原文把AI一律定性为"浪费时间",这个前提本身就不成立。
安全漏洞:黑箱论遇到了具体的CWE数字
原文说AI"发现安全漏洞"是unsubstantiated claim,拿不出证据。但反过来看,AI生成代码本身的安全性,恰恰是过去两年被量化得最细的一块。
对733个真正被采纳进GitHub项目的Copilot代码片段做的分析发现,29.5%的Python片段和24.2%的JavaScript片段存在安全问题,涉及43种CWE类别。给Copilot Chat提供扫描器警告后,它能修复最多55.5%的已发现问题。另一项对7703个明确标注为AI生成的GitHub文件的分析,查出4241个CWE实例、覆盖77种漏洞类型,不过87.9%的文件没查到问题。
再往前看,2024年一项对比108个Java问题的研究里,ChatGPT代码含248个漏洞,Stack Overflow答案含302个——两边都不安全,只是程度不同。这三项研究合在一起说明,AI代码的安全性根本不是"无法验证的空谈",而是可以拿CWE编号一条条数出来的具体问题。原文的"黑箱不可测"论,在安全这条线上站不住。
- 风险.29.5%的采纳率意味着,团队如果不做扫描器复核就合入AI代码,大概率是在批量引入已知漏洞类型,不是运气问题。
可维护性和prompt engineering:骗局论过度简化了
原文最狠的一句是,验证AI代码所需的努力不亚于甚至超过自己写。2025年一项对151名参与者(95%为专业开发者)的两阶段实验部分证实、部分推翻了这个说法:AI辅助的初始开发耗时中位数确实降低了30.7%,但后续由其他开发者接手独立演进这段代码时,完成时间和代码质量都没有显著差异。这既不支持AI代码天然优越,也撑不起原文"garbage code"的重判断——AI写的东西,长期看和人写的差不多难维护,不是更差。
原文把prompt engineering一棍子打成"complete scam",类比SEO骗局。但对243个GitHub仓库、1262次prompt变更的分析显示,只有21.9%的变更被记录进commit message。这说明的不是prompt无效,而是行业还没建立起像样的文档规范去证明它有效或失效。更准确的说法或许是:prompt的效果真实存在,但高度依赖模型版本和上下文,构不成一门可迁移的稳定学科——这和"骗局"是两回事。
黑箱说得容易,拿CWE编号一条条数出来才是真功夫
原文最锋利的一句,是说AI暴露的其实是软件工程行业本已存在的抽象层缺失——如果代码能被AI轻易生成,说明它本该被框架或LSP自动化掉。这句话目前没有任何实证研究能证实或证伪,它更像是一种工程哲学直觉,而不是可检验的命题。
- 结论.对开发者最现实的动作不是站队"AI是不是烂工具",而是先分清自己手头的任务属于哪一类——成熟代码库里的复杂重构,大概率该谨慎使用；陌生领域的初次实现,AI的时间收益基本兑现。
对工程管理者来说,单看"首次实现速度"衡量AI价值已经不够用了,得把审查、扫描、后续维护成本一并算进去,才算得出真实ROI。接下来值得盯的,是有没有更多针对"验证债务"和生产环境事故率的长期追踪数据——这才是能把这场辩论从情绪拉回事实的下一步证据。