当团队把 AI 编码助手接入项目时，往往默认成本只与模型价格有关。Hacker News 上的一则讨论提出了另一个变量：你选的 JavaScript 框架，本身就在决定 AI 的账单。
发生了什么
这则讨论的核心论点是：不同 JavaScript 框架对 AI 编码工具的开销并不相同。框架的抽象层越多、约定越隐晦、生成代码越冗长，AI 就需要读取更多文件、理解更多隐式规则、产出更长的补丁。讨论在 Hacker News 上获得了一定关注，参与者围绕框架复杂度如何转化为 token 消耗、上下文窗口占用和推理延迟展开了争论。需要说明的是，目前公开信息仅停留在观点与经验层面，没有统一的基准测试或量化结论。
为什么重要
过去十年，前端框架的选型标准主要是开发体验、生态和性能。AI 编码工具的普及引入了第四个维度：机器可读性。
这个维度之所以关键，是因为 AI 助手的成本结构与人类开发者不同。人类可以靠记忆和直觉跳过大量样板代码，AI 则必须把相关上下文读进窗口。一个依赖大量隐式约定、宏、编译期转换的框架，会让 AI 在每次改动前加载更多内容；一个 API 表面庞大、写法多样的框架，则会让模型更容易生成不一致的代码，进而触发更多轮修正。
换句话说，框架的“魔法”对人类是便利，对模型可能是负担。当企业开始按 token 或按席位为 AI 工具付费时，这种负担会直接体现在预算和响应速度上。
影响与看点
对开发者而言，这意味着技术选型需要多问一句：这个框架的代码对模型是否友好？显式 API、稳定的目录约定、较少的编译期黑箱，可能会成为新的加分项。
对框架维护者而言，这是一个尚未被充分重视的竞争维度。文档是否结构化、类型定义是否完整、示例是否易于检索，都会影响 AI 工具的表现。可以预见，未来会有框架主动宣传自己的“AI 友好度”。
对团队管理者而言，值得关注的是成本归因。当 AI 账单上升时，问题未必出在模型或提示词，也可能出在代码库本身的复杂度。
需要克制的是，目前还缺乏跨框架的公开对照数据，任何“某框架 AI 成本高 X 倍”的说法都缺乏依据。真正值得跟踪的，是社区是否会形成可复现的评测方法。
一个独立判断：AI 编码工具的普及，正在把“代码库的可理解性”从软性工程文化变成硬性成本项，而框架设计者还没有为此做好准备。
