嗯我承认这个标题有点夸张了。当你把不用 AI 写代码的人排除掉之后确实有可能出现一种情况Token 使用量更少的人反而生产效率更高。我讲一个故事你们可能就开始有点理解了。一个真实的故事在软件发展的早期也就是 60 年代到 80 年代曾经流行过一个公式LOC全称 Lines of Code per Man-Month。Productivity LOC / MM简单来说就是按程序员写出的代码行数来衡量工作效率。今天听起来很荒谬但在那个时代这确实是一种被广泛使用的指标。然后它引发了一些很有趣的现象。比如程序员宁愿自己手搓代码也不愿意导入公共库因为导入库不会增加代码行数。Bill Gates 曾经说过一句很经典的话他真的说过用代码行数衡量软件开发进度就像用飞机重量衡量造飞机进度一样。如果把 LOC 换算成 TOCTokens of Code放到今天其实就是用 Token 消耗量来衡量一个人的工作效率。上下文的困境看到这里你可能会觉得“嗯这个类比我也能想到。但用了 Token 说明用了 AI而 AI 确实比人写代码快啊。”真的吗接下来我要说的是一些很多老板并不知道的事情。首先我们现在说的 AI 并不是真的 AGI而是 LLM。很多人天天在用 LLM但其实并不理解它的工作原理。你有没有对 LLM 的“记忆能力”感到困惑过为什么我用一个 Chat App 和 LLM 聊天它会记住我为什么我在一个聊天窗口里说过的事情换一个聊天窗口它就不记得了LLM 究竟怎么判断要记住多少事情LLM 真的有记忆吗上下文困境LLM 记忆原理这件事情的原理其实非常简单。一个纯 LLM 模型是完全没有记忆的。对它来说每一次请求都是全新的开始。那为什么我们用 Chat App 的时候它看起来又认识我们呢因为 Chat App 自己把你和模型之间的对话保存了下来然后在每次提问时重新拼接进 Prompt 里。换句话说它手搓了一个记忆系统。哪怕你只是对 AI 说一句简单的“你好”在 App 内部实际上也可能会被拼接成这样“你是一个名叫 XX 的 AI 助手。用户的名字叫 XXXXX。他喜欢 blah blah blah。你现在根据他说的信息进行回复。以下是用户输入你好。”所以模型知道你是谁也知道你的偏好。没有魔法就是这么简单。Session 记忆那为什么我们在一个 Chat 里聊过的事情换一个 Chat 模型就不记得了呢在 LLM 应用领域里Chat 更专业的叫法其实是 Session。因为记忆系统通常分成两个层级App 级别记忆Session 级别记忆Session 级别记录的内容更细但它并不是全局共享的。听到这里你可能会想“那为什么不把所有事情都记住呢”答案很简单因为 LLM 可以接受的上下文长度是有限的。如果你尝试让它记住所有事情那么上下文很快就会爆掉。所以 Session 的存在是必要的。但新的问题又来了。即便分了 Session当一个 Session 持续很长时间后上下文依然会变得越来越长。那该怎么办上下文压缩于是人们想出了一个办法压缩上下文。这个过程其实非常朴素就是把大量历史内容总结成几句摘要。毕竟大部分记忆并没有那么重要。这件事情放在聊天记录上通常没有什么问题但放到写代码场景里问题就比较大了。你可能曾经明确告诉模型“不要这样做”结果很多轮对话之后它突然又开始干同样的蠢事。原因往往不是模型故意犯傻而是你触发了上下文压缩那些它认为不重要的细节被压缩过程丢掉了。注意力稀释当上下文过长的时候问题还不仅仅是达到上限更大的问题是注意力稀释。上下文越长模型需要关注的信息就越多于是它可能开始关注一些无关紧要的内容同时忽略真正重要的信息。这其实和人很像。如果你在阅读一篇又长又枯燥的论文你的注意力往往会逐渐分散到最后甚至不知道论文到底在讲什么。很多时候还不如先看一份大纲再针对自己感兴趣的部分深入阅读。模型也存在类似的问题这就是所谓的 Attention Dilution注意力稀释。因此一个超长上下文并不会让模型工作得更好很多时候它反而会产出质量更差的代码。Tokenmaxxing 排行榜的问题我用的是 Claude 的包月套餐。有一次我让模型总结 10 个并不算长的 Markdown 文档结果居然遇到了“达到 1M 上下文上限”的错误。系统提示我必须购买 API Token才能继续使用超过 1M 的上下文。我当时非常震惊因为那 10 个文档按字数加起来肯定远远不到 1M。天知道 Claude 客户端到底给我塞了多少前置上下文。怎样拿到排行榜的高名次回到文章主题。当一个人想冲 Tokenmaxxing 排行榜的时候他会怎么做其实很简单不停加载大文档或者不断提出特别宽泛的问题。这样模型的上下文一定会疯狂增长上下文增长之后Token 消耗自然也会跟着暴涨。但最大的问题其实并不是 Token 费用。当上下文越来越长时模型思考速度会明显下降注意力分散导致代码质量下降上下文压缩导致最佳实践逐渐丢失模型开始重复犯同样的错误。代码质量下降之后Bug 数量增加Bug 增加之后又要消耗更多 Token 去修复。于是形成一个对员工有利、对公司有害的循环上下文越来越长 → Token 越来越多 → 代码越来越差 → Bug 越来越多 → Token 消耗继续增加。怎样拿到排行榜的低名次我现在几乎 100% 的代码都是 Claude Code 生成的。但这并不意味着我写代码特别快我不知道 Claude Code 在写什么。恰恰相反和很多 AI 编程用户相比我的速度甚至算比较慢的。我曾经把一个使用 Streamlit 作为前端的 Python 项目重构成了“Python 后端 React 前端”的架构。如果让 Claude Code 一次性完成大概十几分钟就能跑出来但我花了三天。原因有两个。第一其中很多技术我自己也不熟悉。有了 Claude Code 之后我敢使用以前没有接触过的技术栈而不用担心项目彻底失控或者时间线无限拉长。我可以一边开发一边学习。第二我把任务拆得非常细。我会逐行阅读它生成的代码不断重构不断调整规则再让 Claude Code 记住这些新的最佳实践。除此之外我还使用了很多别的方法。这些方法太多了不可能在一篇文章里全部讲完我会在后续文章里慢慢展开。最终我写出了一个代码相当简洁、相当优雅的项目。虽然用了三天时间但我有信心它在未来很长一段时间里的 Bug 数量都会比较低。更重要的是如果没有模型帮忙其中很多技术我根本不会我可能需要一个月才能完成。从一个月缩短到三天我已经非常满意了。随着我使用 Claude Code 经验的积累我从最开始每周都把 Weekly Usage 用满到现在一周只使用大约 25%。我敢说我做出来的东西可能超过很多人花 1000 美元 API 费用才能做出来的成果。这还没有计算未来因为 Bug 减少而节省下来的维护成本。那么如果放到 Tokenmaxxing 排行榜里我能排第几名呢我猜大概是倒数吧。结论当然这并不能说明排行榜前几名的人一定是在投机。但它至少说明了一件事Token 使用量并不能衡量生产效率甚至有可能损害公司的工程文化。更长的上下文会让模型思考得更久有时候甚至长达几十分钟。我还听说过一些案例一个问题能让模型连续工作几个小时。而在如此低效率的情况下它最终产出的代码质量却未必更高。你以为自己节省了时间实际上只是把维护成本预支到了未来。在你发现这些问题之前它已经开始损害你的产品质量损害用户对产品的信任。和这些长期成本相比浪费掉的 Token 钱反而是最不严重的问题。