AI 编程的虚假繁荣：八成代码成废料，谁在承担代价？

2026 年 5 月 14 日，微软做出了一项令硅谷震惊的举动——终止了内部对 Claude Code 的授权许可。

这并非因为工具难用。也并非因为工具过于强大。

根本原因在于 Token 消耗彻底失控——而这种失控并非源于业务需求，而是一场自上而下的恶性内卷。

微软并非个例。Uber 首席技术官 Praveen Neppalli Naga 在四月透露，公司仅用四个月便耗尽了 2026 全年的 Claude Code 预算。Uber 运营负责人 Andrew Macdonald 随后在访谈中道出了更残酷的真相："Token 使用量的激增，并未带来同等比例的有用功能增长。"

请留意这一表述：并非"AI 工具昂贵"，而是"Token 消耗未能转化为实际产出"。若投资回报率（ROI）为正，即便账单高昂也是利好——毕竟投入一元赚回三元，谁愿削减预算？微软与 Uber 削减授权、严控预算，恰恰揭示了一个事实：Token 消耗的增长与业务产出之间，并不存在因果关联。

那么，Token 消耗为何会失控？答案隐藏在一种名为"Tokenmaxxing"的机制中——这才是成本螺旋的真正引擎。

这便是 AI 编程的第一重困境——成本螺旋。

若仅仅是"贵"，企业尚可控制。更为致命的是，一套名为"Tokenmaxxing"的机制正将这种"贵"转化为一种主动行为。

Salesforce 采取了两项举措：一是推出 Mac 小组件，每 15 分钟刷新个人 Token 花费，并显示"最低预期花费"——Claude Code 每周 100 美元，Cursor 每周 70 美元；二是开发网页工具，允许查看任意同事的 Token 消耗详情。

这传递的信号十分明确：每月至少需消耗约 170 美元的 Token，否则你可能被视为 AI 使用不足。

于是员工开始"刷 Token"。有人让 Claude 生成自己根本无法开发的功能原型；有人窥探同事花费，计算出"略高于平均值"的安全区间，随后将自身用量刷至该水平。

微软亦有工程师坦言，自己会主动进行 Tokenmaxxing——并非工作需要，而是担忧被贴上"AI 使用过少"的标签。他会向 AI 提问文档中已明确记载的问题，即便手写更高效也默认启用 Agent，然后坐视其失败。

多邻国曾尝试将 AI 使用纳入绩效考核，随后又撤回。CEO Luis von Ahn 的反思颇为诚恳："我们发现员工会产生疑惑，'是否为了用 AI 而用 AI？'绩效考核的核心在于将本职工作做到极致，无需强制使用。"

但 YC 走得更远。合伙人 Tom Blomfield 在《Startup School》中直言："最大化 Token 使用，而非最大化员工人数，将成为关键转变。最优秀的公司，将是那些践行 Tokenmaxxing 的公司。"

他建议创业者承受"高到令人不适的 API 账单"，因为这笔支出替代的是更为昂贵的人力成本。

问题在于：这笔支出的替代效应，至今缺乏数据验证。Uber 的 Macdonald 已明确指出——"更高的 Token 使用量并未转化为同等比例的有用功能增长。"

Tokenmaxxing 的本质，是将企业内部的 AI 转型焦虑，转化为员工刷 Token 的行为激励，进而转化为模型厂商的 API 收入。企业自以为在购买效率，实则是在缴纳一笔"转型焦虑税"——而税率的制定者，并非你自己。

Tokenmaxxing 解释了 Token 消耗失控的原因。但失控之后呢？成本究竟流向何处？

传统软件开发的成本结构是线性的：一名工程师编写一份代码，领取一份薪水。AI 编程彻底粉碎了这一结构。

表面上，你节省了人力。一名熟练使用 AI 工具的开发者，代码产出量确实可翻数倍。但省下的资金并未消失——它发生了转移。

第一站：Token 账单。米哈游有员工为实现某项目，构建数十个 Agent 协同工作，结果一夜之间烧掉价值 200 万人民币的 Token。Meta 在 30 天内消耗了 60.2 万亿个 AI Token，按公开 API 价格计算，这笔成本约为 3.3 亿美元。

第二站：清理成本。2026 年 Web 开发 AI 现状报告显示：AI 代码的清理成本是工具成本的 3 至 5 倍。你花 1 元让 AI 编写的代码，需花费 3 至 5 元去清理它。

第三站：维护成本。LogiFlow 的实测案例表明：AI 代码的维护成本是人工代码的 4 倍。

将这三站相加，总账如下：你节省了一名年薪 50 万的工程师，但 Token 费、清理费与维护费之和可能超过 80 万。资金从工资条转移到了云账单，且在转移过程中产生了额外损耗。

此处存在一条更底层的规律：软件开发的复杂性不会转移，只能选择在开发阶段或后续维护阶段爆发。AI 编程让你在开发阶段跑得更快，但它并未消除复杂性——只是将复杂性推迟了。而推迟的代价是利息：今日省下的每一分开发成本，明日都需在清理、运维及故障修复中连本带利地偿还。

若 AI 代码仅仅是"贵"，尚可算一笔账，评估其价值。

但 AI 代码的问题不止于贵——它还在系统性地制造一种更隐蔽的危险：看似正确，实则不可维护。

GitClear 分析了 2.11 亿行代码，发现 AI 代码的"克隆率"——直接复制粘贴或微调后重复使用的比例——激增了 4 倍。这意味着大量 AI 生成的代码是"复制体"：写出来能运行，但经不起任何变动。

LogiFlow 的实测结果更为触目惊心：AI 代码每次修改，有 38% 的概率引发连锁故障。修复时间从人工代码的 45 分钟延长至 4 小时。一个看似微不足道的改动，可能如抽掉一块积木般导致整面墙坍塌。

CodeRabbit 的审计数据显示：AI 代码的严重缺陷密度是人工代码的 1.7 倍，安全漏洞高出 274%。

Meta 内部已出现疑似案例——部分 SEV 线上事故被认为与粗心的 AI 代码生成有关。开发者更关注利用 AI 快速产出大量代码，而非产品质量本身。

最反直觉的发现来自 SlopCodeBench：AI 代码并非"越迭代越好"，而是越迭代越差。

原因不难理解。AI 生成代码的依据是现有代码库。当代码库中 AI 代码比例日益增高，AI 训练自身、迭代自身的"原材料"便在退化。首次生成的代码或许 80 分，以这些 80 分的代码为上下文再次生成，可能降至 70 分。再循环一轮，变为 60 分。

这是一个自我污染的循环。

而 54% 的代码已由 AI 生成（2026 年 Web 开发报告），72% 的开发者每日都在使用 AI 编码工具（Sonar 2026 报告）。代码库被 AI 代码渗透的速度，远超大多数人的直觉。

AI 代码最危险之处，不在于它写得差——差代码一眼便能识破，修补即可。

危险在于它写得"看似完美"。

格式规范，注释详尽，符合设计模式，变量命名考究。从表面审查角度看，几乎挑不出毛病。但真正的问题潜藏于结构深处：模块间耦合可能不合理，边界条件可能未处理，异常路径可能被优雅地跳过——因为 AI 倾向于生成"最可能的路径"，而非"所有可能的路径"。

试想此类场景：Code Review 时，一段 AI 生成的支付回调代码看似无懈可击——异常捕获完整，日志规范，连注释都撰写了三行。审查者扫视一眼，予以批准。三个月后凌晨两点，一个罕见的并发场景触发了边界条件：当两笔退款同时到达且用户账户余额为零时，代码步入了一条 AI 从未考虑过的路径。资金状态不一致，级联故障扩散至三个微服务，整个支付链路瘫痪四小时。事后复盘，问题根源仅有一行——AI 在处理边界条件时默认退款操作是串行的，而审查者未曾察觉，因为它隐匿于一段"看似专业"的代码之中。

这种技术债是隐性的。它不会在 Code Review 时暴露，不会在测试用例中显现，却会在六个月后的某个深夜，因一个边界条件触发，导致整个系统崩溃。

而到那时，最熟悉这段代码的 AI，或许已更换版本，对之前的生成结果一无所知。

质量螺旋并非孤立运转——它与成本螺旋相互咬合。

成本压力迫使团队用更多 AI 替代人力。人力减少意味着代码审查变糙——人手不足，审查时间缩短，每个 PR 只能粗略查看。审查变糙让低质量代码流入生产环境。低质量代码推高运维成本——故障更频繁、修复更耗时。运维成本吞噬 AI 省下的资金。于是继续用更多 AI 来"提效"。

两条螺旋开始啮合。但还缺一环——人。

2025 年，METR 进行了一项实验，结果令许多人坐立难安。

他们让一组资深开发者分别在使用和不使用 AI 工具的情况下完成相同任务。结果是：使用 AI 的开发者**实际上慢了 19%，但他们自认为快了 20%**。

感知与现实的偏差，高达 39 个百分点。

想象一位开发者的一天：他让 AI 生成了一个数据处理模块，五分钟便拿到一份看似完整的代码。他觉得自己推进飞速，信心满满地切换至下一任务。但实际上，接下来的两个小时，他都在调试这段"看似正确却无法运行"的代码——边界条件遗漏、异常路径缺失、与上游模块接口不匹配。每修复一处，AI 又引入新问题。时间全耗在纠偏上，但他并不觉得慢——因为每当 AI 给出新代码时，那种"又解决了一个问题"的即时反馈，让他误以为自己在高速推进。

这便是认知债的可怕之处：你不知自己不知。

技术债留存于代码中。你可通过重构、重写、增加测试来偿还。虽痛苦，但至少可见。

认知债留存于人脑中。你获得了 AI 的输出，却未获得理解。代码跑通了，功能实现了，但你不知其为何能跑、边界条件何在、何处脆弱。六个月后，当问题真正棘手、AI 也无能为力时，这一差距便会暴露——且无法弥补。

Margaret-Anne Storey 提出的三重债务模型中，认知债与技术债、社会债并列第三种债务。但在 AI 编程语境下，其危险性被放大：技术债至少有代码可查，认知债却连痕迹都无。

开发者从"生产者"转变为"审查者"。以往写代码，需厘清每一步逻辑；如今审查 AI 代码，只需判断"看似是否正确"。认知负荷看似降低，实则从"主动思考"降级为"被动判断"。

而"被动判断"的可靠性远低于直觉。AI 代码的表面质量太优——格式规范、注释完备、符合设计模式——审查者极易被"看似专业"的表象蒙蔽，放过那些深藏结构中的问题。

更深远的危险在于：初级工程师的成长路径正被切断。

学习编程者皆知，真正能力并非在"写"的过程中生长，而是在"想"的过程中——拆解问题、权衡方案、踩坑调试、理解为何 A 方案优于 B 方案。这些"慢"的过程，恰恰是工程师能力成长的核心。

AI 跳过了所有这些"慢"的过程。初级工程师拿到 AI 输出，直接提交。他们跳过了拆解、跳过了权衡、跳过了踩坑。产出速度确实快了，但能力的地基是空的。

2026 年的数据已现端倪：斯坦福大学研究显示，22-25 岁年轻人在 AI 高暴露职业中的就业率下降了 6%。企业更愿用一个 AI 工具加一名资深工程师，而非招聘三名初级工程师。

短期看，这很合理。长期看，这意味着 5 到 10 年后，将出现一批"中间层缺失"的工程师队伍——有资深的老者，有被 AI 驯化的新人，却缺少能独立架构、独立排障的中坚力量。

这便是"领导真空"。

认知螺旋一旦启动，便与成本螺旋、质量螺旋开始啮合——

认知退化让审查更粗糙。审查更粗糙让更多低质量代码进入生产。低质量代码推高运维成本。运维成本吞噬 AI 省下的资金。成本压力迫使团队继续用更多 AI"提效"。更多 AI 使用进一步加深认知退化。

三条螺旋，一个闭环。每一条都在加速另外两条。而且——这个系统没有刹车。

没有管理者会主动说"我们少用点 AI"——那等于承认倒退。没有工程师会主动说"我自己写更靠谱"——那等于承认低效。没有公司会在财报中称"我们的 AI 投入未带来可衡量的回报"——那等于承认判断失误。

所有人都在持续加码。原因各异，但方向唯一。

三条螺旋啮合在一起，形成了一个正反馈的死循环。但此循环并非均匀伤害所有人——

Anthropic 预计 2026 年第二季度销售额超 109 亿美元，一季度前该数字为 48 亿——翻了一倍多。英伟达 2026 财年收入 2159 亿美元，同比增长 65%。Cursor 在 2026 年 4 月的收购选择权估值已达 600 亿美元，年化收入突破 30 亿美元。

而同一时间线上：微软砍掉了 Claude Code 许可，Uber 四个月烧完全年预算后开始放缓招聘，多邻国撤回了 AI 绩效考核，Shopify 设置了 Token 日消费预警机制。

一边是模型厂商与算力公司的收入曲线陡峭上扬，一边是使用 AI 的企业在账单与预算间疲于奔命。这绝非巧合——前者吞噬的是后者燃烧出来的。

是那些无法将 Token 消耗转化为资产、却仍在盲目追风的企业。

Uber 的 Macdonald 已将话挑明："更高的 Token 使用量并未转化为同等比例的有用消费者功能增长。"Uber 尚且如此——一家拥有顶尖工程团队、充足预算、充足试错空间的公司。那些资源远不及 Uber 的中小企业呢？那些听信 YC"最大化 Token 使用"的创业公司呢？

米哈游联合创始人刘伟表示，未来三年最多投入 1000 亿元深耕 AI，"即便最终不成功，没做出来，也认了，就当放一场大烟花。"

1000 亿，放一场烟花。这是豪气，亦是无奈。但对大多数企业而言，它们连放烟花的资格都没有——它们的预算只够买一颗糖衣炮弹。

更残酷的是，那些真正被螺旋绞住的企业，往往是最早拥抱 AI 的那批。它们用得最多，依赖最深，代码库中 AI 代码比例最高，团队中认知退化最严重。它们并非不知有问题——而是已无法回头。砍掉 AI 工具意味着承认此前投入全部沉没，意味着团队产出将断崖式下跌。故只能继续加码，继续烧 Token，继续在这个无刹车的飞轮上越转越快。

这不是选择，是惯性。

回到最初的问题：AI 编程究竟是生产力革命，还是糖衣炮弹？

答案是：取决于你是谁。

若你是模型厂商，这是革命——你的收入在翻倍。若你是算力基础设施，这是革命——你的订单排到了明年。若你是 AI 编程工具，这至少是估值的革命。

但若你是使用 AI 编程的企业——

糖衣是甜的：代码产出快了，团队看起来更"AI 原生"了，汇报 PPT 上可写"全面拥抱 AI"了。

炮弹是真的：总账更大了，代码更脆弱了，人更不会思考了。且这三件事在互相加速。

糖衣的甜味，被模型厂商和算力公司吃走了。炮弹击中的，是企业自己的预算、代码库和人才梯队。

这不是效率革命。这是一笔越来越贵的转型焦虑税——你交得越多，越不敢停；越不敢停，交得越多。

直到有一天，账单上写着一个你付不起的数字。

打破螺旋的第一步，是算清总账——非 Token 账单，而是 Token+ 清理 + 运维 + 认知退化的全成本。复杂性不会消失，只会选择在哪个阶段爆发。承认这一点，比继续加码更需要勇气。

三条螺旋解释了 AI 编程为何停不下来。但此处有一个更反直觉的问题：若 AI 编程注定不可持续，为何它未像其他泡沫般自然破裂？为何整个行业看似仍在加速？

答案藏在一个经典理论框架中。

1991 年，杰弗里·摩尔在《跨越鸿沟》中提出一个模型：任何颠覆性技术的采纳者，皆可分為五类——创新者（2.5%）、早期采用者（13.5%）、早期大众（34%）、晚期大众（34%）、落后者（16%）。这五类人从左至右排开，形成一条钟形曲线。

但这条曲线并非连续。在早期采用者与早期大众之间，有一条巨大裂缝——摩尔称之为"鸿沟"。

鸿沟的本质非技术不够好，而是两类人的需求截然不同。早期采用者追求技术潜力，愿冒险，对价格不敏感，无需参考意见。早期大众是实用主义者，厌恶风险，对价格极度敏感，做任何决定前都要看"别人用得如何"。

用服务早期采用者的策略去打早期大众，必然失败。因早期大众不会参考早期采用者的意见——他们觉得那些人是疯子。

摩尔以诺曼底登陆为喻：你要进入主流市场（欧洲），但中间隔着一条鸿沟（英吉利海峡）。唯一办法是集中全部兵力，在一个极小的细分市场登陆（诺曼底滩头），站稳脚跟后再向周围扩展。

将 AI 编程现状置入此框架，一个被喧嚣掩盖的事实浮出水面——AI 编程正卡在鸿沟里。

先看一个矛盾：Token 消耗半年增长超 4 倍，但同期企业 AI 使用率仅涨不到 2 个百分点。同一群人用得更多，而非更多人开始用。

这便是鸿沟的典型特征——早期采用者已疯狂入场，但早期大众几乎未动。

早期采用者侧的信号很热闹：97% 的开发者试过 AI 编程工具，41% 的代码由 AI 生成，GitHub Copilot 付费用户 180 万，TRAE 核心用户全年使用超 200 天。

但早期大众侧的信号冷得刺骨——Zoominfo 内部 400 多名开发者的调研显示，GitHub Copilot 生成代码的采纳率仅 20%。SoftDoc 的数据是 13%-21%。DX AI 对 13.5 万名开发者的分析，合并代码中 22% 由 AI 编写。换言之，AI 每生成 5 行代码，仅 1 行最终被留下。剩余 80%，全是浪费。

工业级任务通过率极低。SWE-bench Pro 测试显示，GPT-5 在工业级复杂任务中通过率仅 23.3%。三次才能对一次——早期大众无法接受此比例。

现在，三条螺旋与鸿沟理论可合而观之。

成本螺旋让早期大众算不过账——微软砍许可、Uber 烧完预算，这些案例传至早期大众耳中，便是"AI 编程太贵了"。

质量螺旋让早期大众不敢信任——38% 连锁故障率、采纳率仅 20%、信任度暴跌至 29%，这些数据传至早期大众耳中，便是"AI 代码不靠谱"。

认知螺旋让早期大众更不敢押注——年轻人 AI 高暴露职业就业率下降 6%、5-10 年后领导真空，这些趋势传至早期大众耳中，便是"用了 AI 团队会变弱"。

三条螺旋每转一圈，鸿沟便宽一分。而模型厂商无动力去填此鸿沟——它们赚的是早期采用者的钱，早期采用者用得越深，Token 消耗越大，收入越高。至于早期大众信不信、敢不敢用，那不是它们的问题。

这便是为何 AI 编程的鸿沟非"等一等就能自然跨过"的，而是一条可能越裂越宽的鸿沟。

AI 编程要真正跨越鸿沟，非靠更多 Demo、更多融资新闻、更多"AI 原生"口号。摩尔的理论说得很清楚：早期大众需要的是可验证的价值、可参考的成功案例、可放心的完整产品。

翻译成具体指标，需同时满足三个条件——

**第一，采纳率突破 50%**。当前 20% 的采纳率意味着 AI 编程还停留在"辅助工具"阶段。当采纳率稳定超过 50%，才说明 AI 输出质量达到了早期大众的及格线。从 20% 到 50%，还有 2.5 倍的差距。

**第二，工业级任务通过率突破 60%**。当前 23.3% 的通过率意味着 AI 在复杂任务中"三次才能对一次"。早期大众不会接受此比例——他们要的是"用了就比不用好"，而非"用了还要花更多时间修"。

第三，出现可复制的"整体产品"标杆案例。非"某大厂在用"这种模糊背书，而是"某中型企业在 X 场景下，投入 Y 成本，获得 Z 产出，以下是完整的工具链 + 审查流程 + 培训方案 + 合规机制"。早期大众做决定前，要看的是这种可参考的完整方案。目前，几乎没有。

三个指标，一个均未达到。而三条螺旋还在加速运转，让每一个指标都更难达到。

摩尔给出的跨越策略是"诺曼底登陆"——非试图一次性征服整个主流市场，而是集中全部兵力，在一个极小的细分市场登陆，站稳后再扩展。

对 AI 编程而言，这意味着：不要试图让 AI 写所有代码，而是找到一个价值可验证、风险可控、参考意见可传播的细分场景，先打赢这一仗。

这些场景有一个共同特征：价值可量化、风险可控、输出可验证。候选的"滩头阵地"已经出现。

关键原则是摩尔所说的"宁做鸡头，不做凤尾"——选择一个足够小、能打赢的战场，而非试图一次性征服整个主流市场。

但更关键的是，要构建"完整产品"——不只是 AI 编程工具本身，而是工具 + 审查流程 + 质量门禁 + 合规检查 + 责任归属 + 培训体系 + 同行参考案例。早期大众需要的非"一个更聪明的代码补全工具"，而是一套让他们放心使用的完整系统。

一些实践已在路上：SPEC 模式（Doc→Tasks→Changes→Preview）将 AI 生成逻辑白盒化；文档驱动 AI 开发（DDAD）用文档规范作为人机协作的"共同语言"；JetBrains AI 利用静态代码分析对 AI 生成内容进行二次校验。

这些实践的方向是对的，但还远远不够。因它们解决的是"工具层"的问题，而早期大众卡住的地方是"信任层"和"价值层"——我敢不敢上线？省下的时间真的变成了产出吗？

直到有一天，某个中型企业在某个细分场景下，拿出了一份完整的投入产出账本——非 Token 消耗量，非代码生成行数，而是"我们投入了 X，产出了 Y，以下是完整的工具链、流程和培训方案，隔壁公司可以照着做"——那一天，鸿沟才有可能被跨越。

在那之前，AI 编程会继续在鸿沟里打转。早期采用者继续加码，Token 消耗继续飙升，模型厂商的收入继续翻倍。而早期大众继续观望，继续等待，继续被三条螺旋的负面案例劝退。

鸿沟不会自己消失。它只会被有意识的行动填平——或者被无意识的惯性越裂越宽。

AI 编程不是没有价值。对创新者和早期采用者来说，它确实提升了效率、改变了工作方式。但他们加起来只占市场的 16%。剩下 84% 的人，面对的是另一套逻辑：他们需要可验证的价值、可参考的案例、可放心的保障。而三条螺旋正在系统性地摧毁这些东西。

糖衣炮弹的糖衣，只有 16% 的人尝到了甜味。炮弹的碎片，却打向了所有人。

打破螺旋的第一步，是算清总账——非 Token 账单，而是 Token+ 清理 + 运维 + 认知退化的全成本。复杂性不会消失，只会选择在哪个阶段爆发。承认这一点，比继续加码更需要勇气。

第二步，是停止试图一次性征服整个市场，而是找到一个足够小的战场，集中全部兵力打赢它——然后让胜利可以被复制、被参考。这是跨越鸿沟的唯一路径。

非"全面拥抱 AI"，而是"在一个地方证明 AI"。

在那之前，这笔转型焦虑税，还会继续涨。