大厂"像用水一样烧token"的神话,以及其背后隐藏的三大结构性局限

最近,"循环工程(Loop Engineering)"在软件开发行业受到了极大关注。它指的是一种闭环(closed-loop)开发方式:AI生成代码(generate)、测试(test)、部署(deploy),再将结果反馈作为输入,从而实现全流程自动化。这是一种愿景——像拥有无限token的超大型AI组织那样,在最大限度减少人工介入的情况下让产品无限进化。

但现实并非如此。迄今为止被认为在循环工程上取得实质成果的案例,几乎无一例外都局限于能够"像用水一样"消耗token的LLM公司,或是Google、Meta、微软这类科技巨头。真正从零基础(zero-base)出发、并成功接入实际上线服务的产业级案例,却难得一见。本专栏结合具体案例与文献资料,分析阻碍循环工程成为通用解决方案的三个决定性瓶颈。

1. token富豪的专属特权——缺乏完善的文档、测试与场景

要让循环工程真正发挥效果,需要有LLM能够理解的丰富文档、用户场景以及与数据库相关的测试代码作为支撑。这是只有拥有庞大数据基础设施的组织才享有的特权。

成功案例——仅在精心整理的数据之上才能运转的循环

大厂的成果无一例外都建立在"精心整理的内部数据"这一基础之上。

  • Google:在内部超过1万名开发者、8种编程语言的范围内,历时3个月应用了基于机器学习的代码补全(ML-Enhanced Code Completion)。结果显示,构建-测试的迭代时间(coding iteration time)减少了6%,上下文切换(context switch)减少了7%,建议采纳率(acceptance rate)达到25%~34%。但ML实际编写的代码仅占全部代码的约3%[1]。也就是说,即便投入巨大资源,自动化的实际占比依然有限——这一点是大厂自己证明的。
  • Meta:将基于自有代码库训练的"CodeCompose"部署给1.6万名工程师,在15天内提供了450万条建议。建议采纳率为22%,开发者输入代码中8%来自CodeCompose,定性反馈中91.5%为正面评价[2]。值得注意的是另外一点:Meta在训练前阶段,特意过滤掉了诸如"PHP-ism"之类的陈旧模式以及未进入生产环境的实验性代码。正是因为人工先对高质量数据进行了筛选,循环才得以运转起来。
  • 微软/GitHub:被广泛引用的"使用Copilot开发速度提升55%"这一数据,其确切出处并非微软的内部大规模应用结果,而是GitHub进行的对照实验(controlled experiment)。约95名专业开发者被分为两组,要求实现一个JavaScript HTTP服务器,使用Copilot的小组平均耗时71分钟完成,比对照组(161分钟)快55%(p=0.0017)[3]。但必须明确指出,这一结果是在"规范明确、通用单一任务"的理想条件下取得的。

现实的高墙——在未经整备的环境中,反而滋生大量Bug

中小型组织或初创公司的情况则截然不同。在测试覆盖率低、文档不完善的环境中引入AI编程助手,反而会出现相反的效果:缺陷大量滋生。一个代表性发现是,未经审查即采纳的AI生成代码中,相当一部分(部分分析显示约48%)可能存在安全漏洞[4]。想要运转循环,首先需要用于验证循环输出的"基准数据",而大多数企业在缺乏这一基础的情况下,只是盲目追逐潮流,最终以失败告终。

归根结底,循环工程的第一道准入门槛并非模型性能,而是输入数据的质量——而这本质上正是"token富豪"们的专属特权。

2. 行业领域知识的盲区——即便是LLM也找不到最佳实践

要让LLM找到最优实现模式,该领域的代码与架构必须在预训练(pre-training)数据中得到充分体现。像Web、移动应用这类通用领域,在GitHub上资源丰富,但制造、金融、医疗等特殊行业的核心逻辑,在公开数据中几乎不存在。

具体的局限案例——在业务逻辑面前崩溃的转换

遗留代码现代化是最能清晰暴露这一局限的领域。COBOL至今仍是关键任务(mission-critical)资产,目前仍处理着全球约70%的银行交易[5]。

  • 通用LLM的局限:在一项实务对比分析中,让通用工具GitHub Copilot将COBOL程序转换为Java,结果给出的是缺乏对业务逻辑与系统上下文理解的"表面化转换"。它遗漏了DB2集成,也未能识别控制新客户编号生成的NCS(Named Counter Server)的作用[6]。这说明公开数据中不存在的领域规则,模型是无法自行创造出来的。
  • 即便是专用工具也离不开人工验证:IBM推出了基于1.6万亿token训练、并用数千对COBOL-Java程序进行微调的专用模型(基于Granite 20B的watsonx Code Assistant for Z)[5]。但2026年的一份实务评测仍明确指出,"不应期待未经精细化处理(refinement)即可直接用于生产环境的结果"。也就是说,即便是专用工具,也无法省去资深开发者的人工验证和语义等价性(semantic equivalence)测试[6]。
  • 在领域逻辑上持续失败:在涉及约400名开发者的ZoomInfo案例中,Copilot在生成样板代码(boilerplate)方面表现有用,但在领域特定逻辑(domain-specific logic)上却举步维艰[3]。

若没有能够指导精确行业知识的人类专家介入,循环只会收敛于看似合理、实则错误的方向。在金融、医疗等监管严格的环境中,这一盲区带来的风险只会更大。

3. 经济性的幻象——token成本与验证人力的双重账单

即便部分解决了第1点(数据)和第2点(领域知识),最后还有一道关卡:持续"运转"循环本身的成本。大厂能够像用水一样消耗token的原因很简单——他们拥有自己的基础设施,或者本身就是模型制造商。而对于普通组织而言,每月都会收到账单。

第一张账单——失控攀升的token成本

智能体式(agentic)编程的成本,相较于简单的对话或推理任务要高得多。

  • 一项研究发现,智能体式编程任务消耗的token量比对话、代码推理任务高出约1,000倍,若算上重试与自我修正(self-correction)循环,单个任务可达到100万至350万token[7][8]。
  • 更大的问题在于不可预测性。即便重复执行同一任务,token使用量也可能出现高达30倍的波动,而且token用得更多并不代表准确度会更高——准确度实际上在中间成本区间达到峰值,超过该区间后便趋于饱和。更糟的是,前沿模型往往无法准确预测自身的token成本,且存在系统性低估的倾向[8]。这使得预算编制这件事本身几乎无法成立。
  • 成本会直接体现在现金流上。Claude Code按每位开发者活跃使用日计费,约为13美元,而在大力推行自动化的情况下,每位工程师每月费用可飙升至5002,000美元[9]。当GitHub Copilot转为按token量计费后,开发者反映成本增加了1050倍,持续运行智能体会话的用户预计每月支出750~3,000美元。其中,依赖"氛围编程(vibe coding)"的非开发者群体受到的冲击最大[10]。

我自己为了高效使用token,也会根据用途搭配使用多种LLM,但最终得出的结论是:与其把烧token的钱投入其中,不如直接投资AI巨头企业,投资回报率(ROI)可能会更好。归根结底,安全等需要谨慎对待的部分仍必须由人来审阅确认,而事实证明,构建让LLM能真正理解的文档,才是更高效的做法。

第二张账单——隐藏的验证人力成本

循环的输出无法免费获得信任,必须有人阅读、验证并修正,而这部分成本往往会抵消节省下来的效益。

  • 非营利研究机构METR于2025年进行的一项随机对照试验(RCT)彻底颠覆了传统认知。16名经验丰富的开发者在平均约100万行代码规模的成熟开源仓库中完成246项真实任务,使用AI工具时工作速度反而慢了19%——但他们自己却认为速度提升了20%[11]。
  • 不过,这一结果需要谨慎解读(不确定性标注:中等)。METR自身在2026年的后续复核中承认存在选择效应(selection effect)的可能性,并正在修正实验设计;部分后续估算显示,效应大小已变为老参与者-18%、新参与者-4%[12]。也就是说,这不应被解读为"AI总会拖慢速度"这一定律,而应视为一个强烈信号——在成熟代码库中,验证负担可能会侵蚀生产力收益。

综合来看——只能在大厂的财务报表上闭环的ROI

归根结底,循环工程的投资回报率(ROI),只能在能够以接近零边际成本获取token的大厂财务报表中部分成立。对于普通组织而言,(1)波动巨大的token成本与(2)不会减少的验证人力成本叠加形成的"双重账单",要拿去交换一个连保证都谈不上的速度提升。如果对编程本身、对行业领域缺乏理解,最终只会陷入徒劳空转的无限循环。

三大瓶颈总结

结构性瓶颈 大厂为何能够跨过 普通组织为何会失败
1. 输入数据(文档、测试、场景) 内部已积累大量经过整理、筛选的代码、测试与场景(例如Meta对训练数据的预先过滤) 测试覆盖率与文档不足→缺乏验证标准,导致Bug大量滋生
2. 领域知识(行业专属逻辑) 可直接基于自有领域数据进行微调 制造、金融、医疗的核心逻辑在公开数据中缺失→转换流于表面且容易出错
3. 经济性(token与验证成本) 拥有自有基础设施/模型→token边际成本≈0 单任务耗费100万至350万token,波动最高达30倍+验证人力成本→ROI不达预期

结论——循环是电动工具,而非自主运转的先知

试图直接照搬大厂循环工程成功案例的做法,大多都会失败。因为其成功的本质并非"出色的AI模型",而是围绕该模型的三项基础设施前提:经过整理的数据、积累的领域知识、以及接近零边际成本的token获取渠道。在不具备这些前提的组织中,期望剥离人工介入、实现完全自动化的循环,近乎是一种试图用工具性能来弥补基础设施缺失的错觉。

"LLM是Excel,不是先知。"正如Excel能加速计算,却不能代替会计判断一样,循环也只是加速开发的电动工具,并非能够自主孕育出正确产品的神谕(oracle)。现实可行的策略并非追逐闭环神话,而是先建立让人类留在验证环节(human-in-the-loop)中的渐进式、局部自动化,然后在此基础上逐步积累数据与领域知识,慢慢扩大循环的覆盖范围。

参考文献(References)

  1. Google Research, "ML-Enhanced Code Completion Improves Developer Productivity," 2022. (内部1万名以上开发者/8种语言/迭代时间减少6%/ML代码占比约3%/采纳率25~34%)
  2. Murali, A. et al., "AI-assisted Code Authoring at Scale: Fine-tuning, deploying, and mixed methods evaluation (CodeCompose)," Proc. ACM Softw. Eng. (FSE), 2024. (采纳率22%/占输入代码的8%/正面反馈91.5%)
  3. Peng, S. et al., "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot," arXiv:2302.06590, 2023; GitHub Research Blog, 2022. (对照实验约95人,速度提升55%);关于ZoomInfo领域逻辑局限的相关内容:引自Bakal等人(arXiv:2502.13199)。
  4. 关于AI生成代码安全漏洞的报告(部分分析显示未经审查代码中约48%可能存在漏洞)及斯坦福大学的研究(使用AI编程工具时安全缺陷呈上升趋势)。基于公开的二次报道,精确数值因环境而异(不确定性:中等)。
  5. IBM Research, "Application modernization with IBM generative AI (watsonx Code Assistant for Z)," 2023-2025. (Granite 20B/1.6万亿token训练/COBOL处理全球约70%的银行交易)
  6. CROZ, "An Honest Take on watsonx Code Assistant for Z," 2026(实务评测);Vicky's Notes(Medium), "Comparing AI Tools for COBOL2Java," 2024(Copilot遗漏业务逻辑、未能识别NCS的案例)。
  7. iternal.ai, "Tokenization in NLP: Tokens, Usage & Cost Guide," 2026. (智能体式编程任务单次消耗100万~350万token)
  8. Stanford Digital Economy Lab, "How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks," arXiv:2604.22750, 2026. (相较对话约高1,000倍/同一任务波动最高30倍/成本提升并不直接转化为准确度提升/模型无法准确预测自身成本)
  9. Atlas Cloud, "How to Reduce AI Coding Token Cost," 2026(引用CloudZero 2026)。 (Claude Code每人活跃日约13美元/自动化情形下每月500~2,000美元)
  10. TechJournal, "GitHub Copilot Token Billing Backlash," 2026. (转为按量计费后反映成本增加1050倍/运行智能体会话的用户预计每月7503,000美元/氛围编程用户受冲击最大)
  11. Becker, J., Rush, N., Barnes, E., Rein, D., "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," METR / arXiv:2507.09089, 2025. (16名资深开发者·246项任务,使用AI时慢19%,而自我感知为快20%)
  12. METR, "We are Changing our Developer Productivity Experiment Design," 2026. (承认选择效应并修正实验设计/后续估算:老参与者-18%,新参与者-4%)

本专栏中的所有量化数据均基于公开的一次与二次文献来源,由于各来源的测量条件不同,直接比较时需谨慎。已确认的结果与解读性推测已在正文中加以区分标注。