令牌效率的时代，库的时代

# 令牌效率的时代，库的时代 — GolemUI 博客 来源: https://golemui.com/blog/the-age-of-token-efficiency/ 不久以前，大概六个月吧，我还深信AI不会取代我们程序员。它只会帮助我们，做我们的助手。那时我主要是在ChatGPT里发一些一次性提示词，帮我解决一些零星的算法问题，但令我欣慰的是，几乎所有代码仍然是我亲手写的。 六个月后，我不确定没有Claude我还能不能做好日常工作。而且我并不孤单：84% 的开发者 (https://survey.stackoverflow.co/2025/ai) 正在使用或计划使用AI工具，早在2023年2月，GitHub 就已经测量到 Copilot 启用的文件中 46% 的代码是 AI 生成的 (https://github.blog/news-insights/research/github-copilot-for-business-is-now-available/)，其 CEO 预测 “很快” 就会达到 80% (https://www.freethink.com/robots-ai/github-copilot)。 令牌币流入库建筑 ## 五十位开发者，同一个答案 章节标题为 “Fifty developers, one answer” (https://golemui.com/blog/the-age-of-token-efficiency/#fifty-developers-one-answer) 最近在 DevBcn 上，我有机会向真人验证这一点，我们在那里展示了 GolemUI (https://golemui.com/blog/golemui-at-devbcn-2026/)。我特意问了每一位路过我们展位的开发者，他们是如何使用AI的。 我这个极其不科学的调查，涵盖了来自不同公司、世界不同地区的约五十位开发者，得出了一些真正令人震惊的一致性。他们基本上都说了同样的话： 这与 Gartner 的预测 (https://www.gartner.com/en/newsroom/press-releases/2025-07-01-gartner-identifies-the-top-strategic-trends-in-software-engineering-for-2025-and-beyond) 相符：到 2028 年，90% 的企业软件工程师将使用 AI 代码助手，而 2024 年初这一比例还不到 14%，开发者的角色将从实现转向编排。 46% 的代码是 AI 生成的，在 Copilot 启用的文件中，早在 2023 年 2 月 — GitHub (https://github.blog/news-insights/research/github-copilot-for-business-is-now-available/) 到 2028 年，90% 的企业工程师使用 AI 助手 — Gartner (https://www.gartner.com/en/newsroom/press-releases/2025-07-01-gartner-identifies-the-top-strategic-trends-in-software-engineering-for-2025-and-beyond) 不知道你怎么想，但对我来说，在写了将近30年软件之后（是的，我老了！），这有点令人伤感。不过恐怕这种伤感只是因为这个行业正在经历一些重大变革，而我们人类不喜欢变化。所以我个人愿意保持乐观，相信这最终会是好事，希望从长远来看是这样。 是吗？答案可能取决于你最喜欢的 AI 视频博主。 ## 令牌效率的时代 章节标题为 “The age of token efficiency” (https://golemui.com/blog/the-age-of-token-efficiency/#the-age-of-token-efficiency) 但对于你和我们这些现在就在这个行业工作的人来说，这会把我们留在哪里——不是五年后，而是今天？ 公司开始从“不限量令牌”转向更计量、更企业化的模式。Gartner 预测全球 AI 支出将在 2026 年达到 2.5 万亿美元 (https://www.gartner.com/en/newsroom/press-releases/2026-1-15-gartner-says-worldwide-ai-spending-will-total-2-point-5-trillion-dollars-in-2026)，一年内增长 44%。其中大部分是基础设施，而不是你的令牌账单，但正是这种数字会让财务部门在链条下游开始提问。而“不限量”悄悄地变成： 我们即将进入一个狂野的度量世界，围绕着两个数字构建： - 每个功能的令牌成本。 - 对所生成代码的信任百分比。 第一个你至少可以放到仪表盘上，尽管没人会同意“功能”是什么。第二个才是真正的麻烦：信任在你的墙内基本上是没法衡量的。你只能在你比 AI 更了解某个领域时衡量对代码的信任，现在这往往只在你是该领域的行业专家时才会发生。 ## 信任，房间里的那头大象 章节标题为 “Trust, the elephant in the room” (https://golemui.com/blog/the-age-of-token-efficiency/#trust-the-elephant-in-the-room) 在我看来，信任是现代AI房间里的大象。让我回到开头我说过的话： > “我不确定没有Claude我还能不能做好日常工作” 这句话值得更细致的解读。是的，我依赖Claude帮助我，但我能否信任它做的事情，归结为一个问题：我是它工作的领域的行业专家吗？这个问题把我的工作分成两部分，基于我关心的是“如何”完成还是“什么”被完成： - 我的核心使命：我的业务实际交付的东西，我是专家的地方。在那里我同样关心“如何”和“什么”。 - 其他地方：我不是专家，我主要关心“什么”。 基本上，在处理 GolemUI 源代码时，我知道我占据优势。我让Claude帮助我，但Claude主要是向我汇报的下属。 现在，当我需要更新我们的网站时，我主要关心“什么”。网站很重要，但它不是我的核心使命，没人期望我是营销网站方面的专家。 信任问题就存在于第二个桶里。借助AI，你可以编写以前从未能接触到的应用领域，那些没人会说你是行业专家的领域，那么你该如何信任你并不完全理解的东西？ 我敢肯定你也有自己的独门绝技：你开启一个新的会话，告诉它“你是后端架构师”，让它审查这样那样。但最终结果是一样的。这就是如何埋下一颗 定时炸弹：你无法完全评判的代码，因为看起来能工作就被交付，在你宁愿不打开的应用角落里滴答作响。 而且数字表明你没有想象它。在 2025 年 Stack Overflow 开发者调查 (https://survey.stackoverflow.co/2025/ai) 中，采用率上升而信任度下降，在同一份调查中： 66% 的最大挫折感：“AI解决方案几乎正确，但并不完全正确” — Stack Overflow 2025 (https://survey.stackoverflow.co/2025/ai) 45% 的人表示调试 AI 代码比他们希望的时间更耗时 — Stack Overflow 2025 (https://survey.stackoverflow.co/2025/ai) 希望我已经讲清楚了两个关键点，我认为它们如今是大多数资深开发者焦虑的核心：我们如何证明自己在高效使用令牌，以及我们如何证明我们信任正在构建的东西。 ## 当定时炸弹爆炸 章节标题为 “When the time bomb goes off” (https://golemui.com/blog/the-age-of-token-efficiency/#when-the-time-bomb-goes-off) 如果你同意这个信任前提，那么这就会把你置于这样的境地：除非你能够验证你交付的所有代码，否则你基本上就是在玩彩票。也许永远不会出事。也许会的。 而炸弹已经爆炸了。在 2026 年 1 月发布几天后，Moltbook (https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys)，这个面向 AI 代理的氛围编码社交网络，被发现完全敞开：它的数据库密钥放在客户端 JavaScript 中，行级安全从未开启，云安全公司 Wiz 的研究人员可以读写整个生产数据库，包括 150 万个 API 令牌。 150 万个 API 令牌暴露 — Moltbook 的氛围编码发布，2026 年 1 月 — Wiz Research (https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys) 92% 的人在代码交付前对其生产就绪有信心 — CloudBees 2026 (https://www.theregister.com/ai-ml/2026/05/20/ai-code-boom-drives-production-failures-higher-spending/5243787) 81% 的人看到与 AI 生成代码相关的生产问题增加，同一调查 — CloudBees 2026 (https://www.theregister.com/ai-ml/2026/05/20/ai-code-boom-drives-production-failures-higher-spending/5243787) 我想这会引起你的共鸣：如今AI已经消除了塑造每个专业人士能力的传统疆界。你可以端到端地开发一个应用，AI 不仅能更快地构建你以前能构建的东西，还能构建你以前无法构建的东西。 但现在谁来为 bug 负责并承担责任？这个问题曾经微不足道：引入 bug 的开发者负责修复，交付它们的公司/组织负责问责。 Andrej Karpathy (https://karpathy.bearblog.dev/sequoia-ascent-2026/)，前 OpenAI 和 Tesla AI 负责人，也是第一个创造“vibe coding”这个术语的人，他的回答是：没有任何改变。他现在将实践一分为二：vibe coding 提升下限，agentic engineering 提升上限，但在问责方面他丝毫不让： > “你仍然要为你的软件负责，和以前一样。” Simon Willison，Django 的联合创始人，AI 辅助开发方面最受关注的发声者之一，他也在公开场合思考同样的问题，而他没那么绝对。他曾经在 vibe coding（你提示、接受并交付，从不阅读代码）和负责任的工程（你审查、测试并理解你交付的一切）之间划清界限。但到了 2026 年 5 月，他承认这条界限在他自己的实践中正在模糊 (https://simonwillison.net/2026/May/6/vibe-coding-and-agentic-engineering/)：随着代理变得更加可靠，他不再审查每一行代码。但有一件事仍然困扰着他： 让我描绘一幅画面，看看你是否觉得熟悉。Aiden 是一名资深 UI 开发者，正在为他的公司端到端地构建一个应用：一个财务应用，需要整合销售和收入的摘要。 Aiden 在 DB/后端等方面并不强。他的 UI 规格很严格；对于非 UI 部分，他依赖于众所周知的 AI 技巧：时不时在会话中问： > “你确定这是正确的实现/规格吗？” 我敢肯定你也经历过。现在，Aiden 的一个定时炸弹爆炸了：在他完全 vibe coding 的区域里有一个关键 bug。 假设它和 grid 有关：AI 从头构建了自己的 grid，有点失控。存在难以重现的 bug（grid 通过了测试，当然；这是另一种 bug），而 Aiden 对那段代码一头雾水……大多数用过 grid 的人会告诉他： > “Aiden，处理 grid 可能会变得相当复杂。我认为你应该删掉所有这些代码，然后告诉 Claude 使用 [插入你最喜欢的 grid 库]。” 你可能会说 grid 就是应用本身，是屏幕上的东西。但看看 Aiden 的业务方实际要求的是什么：一个正确的销售和收入摘要。这才是“什么”，也是唯一会有人追究他责任的东西。Grid 纯粹是“如何”，而 Aiden 掉入了 AI 陷阱。 ## 库的时代 章节标题为 “The age of libraries” (https://golemui.com/blog/the-age-of-token-efficiency/#the-age-of-libraries) 所以这里的关键问题超越了 grid。Aiden 应该把令牌花在 grid、图表、表单、验证上吗？我相信有两种思路： - 是的！借助 AI，你现在可以构建自己的定制化、完全符合需求的应用，让它完全如你所愿。 - 不！在你的技术栈上大力投入，为你的用例找到最好的库，让它们去花令牌。 我们的赌注押在第二种思路上。在说了这么多之后，我们认为，从一开始就不考虑要使用哪些库，让你的 AI 代理直接从零开始构建，是一个完全的错误。这些部分的真正成本不在于编写它们，而在于维护它们，在于信任它们。这就是为什么你需要把你的令牌间接委托给其他行业专家，他们能够构建你可以安全复用的可靠软件部件。 而这正是前一节中的问责问题终于得到解答的地方。当 bug 出在你购买的库里时，有地方可以提交工单：有变更日志、支持合同、一个声誉取决于修复它的团队。 这就是当你自己无法构建信任时信任的样子，也是为什么我们说信任“在你的墙内”是无法衡量的。你无法衡量对你团队中没人理解的代码的信任。但你可以从那个代码是其核心使命的团队那里购买信任。 我已经能听到反对的声音了：如果AI降低了编写代码的成本，那肯定也降低了拥有代码的成本吧？只要把 bug 丢给 Claude 就行了！我肯定你试过：你粘贴堆栈跟踪，AI 漂亮地道歉，重写了一半 grid，测试又变绿了。 但回到信任问题。一个你无法评判的修复，在你团队中没人理解的代码里，这不是维护，而是又一次轮盘赌旋转。而当 bug 换了一顶帽子再次出现时，你向谁升级？ 你 vibe coding 出来的 grid 没有变更日志，没有支持合同，也没有声誉取决于它的团队。AI 让接触代码变得便宜，但并没有让为代码负责 (https://lucumr.pocoo.org/2026/2/13/the-final-bottleneck/) 变得便宜。 这不仅仅是我的直觉。GitClear，一家靠衡量代码质量生存的公司，分析了 2023 年到 2026 年中期的 6.23 亿次代码变更 (https://www.gitclear.com/the_ai_code_quality_maintainability_gap)，趋势线都指向同一个方向：代码重复率创历史新高，比 2023 年增加了 81%；开发者现在复制粘贴代码块的可能性大约是重构的五倍；维护旧代码的变更比例暴跌了 74%。我们编写代码的速度比以往任何时候都快，而照看代码的时间却比以往任何时候都少。 现在，我不打算假装我们知道哪种思路会胜出，如果有人告诉你他们知道，那么，下次问他们要彩票号码吧。 ## 卓越的守门人 章节标题为 “Gatekeepers of excellence” (https://golemui.com/blog/the-age-of-token-efficiency/#gatekeepers-of-excellence) 我们还尚未明确的一点是，如今 AI 出现后，流行的库会怎样。让我提一个实验：选一个大型的、专业维护的库，比如 AG Grid 或 Highcharts，看看它过去几年的发布历史……你注意到什么了吗？ 我去拉了数据，这是我第二次极其不科学的调查，不过这次直接来自 npm 注册表和 GitHub。公平地说，发布数量是一个粗略的代理，发布节奏部分是一种策略选择，而且这种模式并非处处成立：它在拥有专门专家团队的库中表现明显，在社区运营的库中则少得多。但这种分化本身就是关键。把视野放宽，Octoverse (https://octoverse.github.com/) 显示整个生态系统比以往任何时候都更快交付： 13 → 27 个 AG Grid 稳定版本 2022 年 vs 2025 年 — npm 注册表 (https://www.npmjs.com/package/ag-grid-community?activeTab=versions) ×2.6 Highcharts 提交活动 2022 年到 2024 年间 — GitHub (https://github.com/highcharts/highcharts/graphs/contributors) 约 10 亿次 GitHub 提交 2025 年 — 一年内增长 25% — Octoverse (https://octoverse.github.com/) 我们认为，在 AI 环境中，库维护者必须采取这种立场：全面拥抱 AI，同时成为各自领域卓越的守门人。关心“如何”的内部专家检测、移除并防止负面乘数效应；一个曾经要等几个月的功能请求现在几天内就能交付。一个建立在这些库之上的应用生态系统正在涌现：你把大部分令牌花在你的核心使命上，而在其他地方你要求你的 AI 依赖这些库，正是为了避免再埋下一颗定时炸弹。 ## 会说代理语言的库 章节标题为 “Libraries that speak agent” (https://golemui.com/blog/the-age-of-token-efficiency/#libraries-that-speak-agent)