LLM 代码风格与 Token 成本的深度洞察

背景

在过去的一年中，作者在使用 Claude 进行功能创建与代码审查的过程中，敏锐地察觉到了 Token 消耗与遗留编程模式之间的张力。每当认为某项任务完成时，往往会面临回归测试失败或边缘情况处理等新问题，而这一切都伴随着 API 调用中输出 Token 成本的稳步上升。

作者指出，现代 Web 开发正处于一个“甜蜜点”：通用特性正在消除大量代码行并提升质量。然而，LLM 生成的代码往往显得冗长、脆弱且不安全，甚至重复解决平台早已解决的问题。这种现象让作者怀疑是否存在某种“阴谋”，即 LLM 倾向于将 Web 平台向后拉，尽管像 Ryan Dahl、Alex Russell 和 Dimitri Glazkov 等人已经通过 Web Components 等技术让 Web 平台变得更好。

作者强调，其立场并非强制推广某种特定的代码风格（如 Tab vs 空格），而是基于实用主义和经济学视角。由于 LLM 的训练语料库中充斥着过时的 Node.js 模式，导致其默认生成的代码效率低下。本文旨在揭示这一现象背后的 Token 经济账，并提供具体的优化方案，帮助开发者在 API 价格飙升前降低输出成本。

核心内容

1. 运行时环境的认知偏差

Deno 和 Cloudflare Workers 等现代运行时原生实现了 Web API 表面（包括 URL、URLSearchParams、fetch、FormData、Headers、Request、Response、AbortController、ReadableStream、crypto 等）。这是 Deno 的刻意架构选择，也是 WinterCG 正在标准化的最小通用 API 表面。

这意味着浏览器和服务端代码可以使用相同的 API 表面，无需翻译层、垫片（shims）或适配成本。平台已经正确、安全地解决了大量问题，且无需依赖第三方库。

然而，LLM 并不了解你的运行环境。其训练语料库主要由这些 API 普及之前的 Node.js 代码主导，例如 require('url')、querystring.parse()、Express 中间件模式、带有自定义超时包装器的 axios 以及用于表单解析的 multer。这些模式在模型的学习数据中占据统计优势，因此模型会本能地“伸手”抓取这些过时且冗长的模式。

核心矛盾： 模型默认生成的代码与平台已提供的原生能力之间的差距，构成了大部分输出 Token 成本的来源。

2. 各场景下的 Token 消耗对比与优化

作者通过估算不同代码模式的 Token 经济效应，展示了使用原生 Web API 相比 LLM 默认生成的手动实现方案，能带来巨大的 Token 节省。以下是具体案例：

查询参数解析 (Query Parameter Parsing)

• 模型默认（手动解析）： 约 140 Tokens。
  • 代码涉及手动分割 URL、处理键值对、解码 URI 组件。
  • 缺陷： 对格式错误的键静默失败；对于重复参数，仅保留最后一个值；若键为 __proto__，则存在原型污染风险。
• Web API 原生方案： 约 12 Tokens。
  • 使用 new URL(rawUrl).searchParams 配合 Object.fromEntries。
  • 优势： 按规范处理所有边缘情况，代码量减少约 90%。

表单数据处理 (Form Data)

• 模型默认（按字段状态管理）： 约 200+ Tokens（以 3 字段表单为例）。
  • 模型会为每个字段生成 useState 钩子、变化处理函数等。
  • 缺陷： 随着字段数量增加，代码量线性增长，且逻辑冗余。
• Web API 原生方案： 约 14 Tokens。
  • 使用 new FormData(event.target) 配合 Object.fromEntries。
  • 优势： 一次性摄取整个表单数据。无论字段数量多少，成本基本固定，可轻松扩展至二十个字段。

Fetch 生命周期与取消 (Fetch Lifecycle and Cancellation)

• 模型默认： 约 90 Tokens。
  • 手动创建 AbortController，设置 setTimeout 触发 abort，并在 try...finally 中清除定时器。
  • 缺陷： 如果在重构过程中遗漏了 finally 路径，会导致定时器泄漏。
• Web API 原生方案： 约 12 Tokens。
  • 直接使用 AbortSignal.timeout(5000)。
  • 优势： 无需管理生命周期，无泄漏风险。

并行异步与故障隔离 (Parallel Async with Failure Isolation)

• 模型默认： 约 100 Tokens。
  • 使用 Promise.all 配合 .catch 捕获错误，并手动维护一个 anyFailed 标志位。
  • 缺陷： 丢失具体的错误详情；每次使用都需发明临时的状态约定。
• Web API 原生方案： 约 10 Tokens。
  • 使用 Promise.allSettled(tasks)。
  • 优势： 返回每个任务的结构化结果（包含 status 为 "fulfilled" 或 "rejected" 及对应的值或原因），保留完整错误信息。

UI 组件 (UI Components)

• 模型默认（自定义模态框）： 约 250 Tokens（JS 生命周期管理）。
  • 涉及 useState、useEffect 管理 body overflow、ARIA 属性、键盘陷阱、背景点击处理等。
  • 缺陷： 逻辑复杂，易出错，且重复造轮子。
• 语义化 HTML 原生方案： 约 25 Tokens。
  • 直接使用 <dialog> 标签。
  • 优势： 自 2022 年起，所有主流浏览器均支持 <dialog>。它原生处理焦点陷阱、Escape 键、无障碍树和背景遮罩。
  • 其他示例： 手风琴效果可使用 <details>/<summary>；表单验证可使用原生 <form> 约束验证（如 required、type="email"、pattern、minlength）。

关键要点

• Token 成本不对称： 在 API 定价中，输出 Token 的成本通常是输入 Token 的 3 到 5 倍。因此，减少输出代码量具有极高的经济价值。
• LLM 的训练偏差： LLM 倾向于生成过时的 Node.js 模式（如 require、querystring、手动表单处理），因为其训练数据中这些模式占主导地位，而非现代 Web 标准 API。
• 原生 API 的高效性： 现代运行时（如 Deno、Cloudflare Workers）原生支持 Web API，开发者应直接利用这些能力，避免让 LLM 生成冗余的适配层或手动实现。
• 显著的成本节约：
  • 查询参数解析：减少约 90% 的 Tokens。
  • 表单处理：从 200+ Tokens 降至 14 Tokens，且具备更好的可扩展性。
  • Fetch 取消：从 90 Tokens 降至 12 Tokens，消除定时器泄漏风险。
  • 并行错误处理：从 100 Tokens 降至 10 Tokens，保留完整错误上下文。
  • UI 组件：从 250 Tokens 降至 25 Tokens，利用浏览器原生无障碍和交互支持。
• Prompt 工程的重要性： LLM 不知道你的运行环境。开发者必须在 Prompt 中明确指定使用 Web API 或原生特性，以纠正模型的默认行为。

意义与影响

这篇文章揭示了 AI 辅助编程中一个被忽视的经济维度：代码风格与 Token 成本之间的直接关联。

1. 从“功能正确”到“经济高效”的转变： 开发者不应仅满足于 LLM 生成的代码能运行，更应关注其生成代码的 Token 效率。冗长的代码不仅增加费用，还增加了维护复杂度和潜在的安全漏洞（如原型污染