发现渠道：社区讨论与聚合入口
给编程 Agent 同一份需求，换一个 JavaScript 框架，生成成本会差多少？Nolan Lawson 在 10 月 28 日的文章里做了一个范围很明确的测试：用 Opus 5.5 的高推理设置，分别以十二种框架生成一个可搜索、筛选的宝可梦展示应用，每种跑五次。文章今天因社区讨论再次受到关注，并非今天发布的新版本。
测试给 Agent 功能规格和一致性测试，以可访问性树检查交互，也就是检查界面向辅助技术提供的角色、名称与状态，尽量不要求各框架采用相同的页面内部结构。Lighthouse 的性能与可访问性检查没有预先告知 Agent。官方工具和技能可以使用，但“可以用”不表示每次真的用了。Angular 五次中有两次未形成可测成品；费用仍计算五次，代码和性能指标只能统计成功样本。
作者按 API 价格折算的中位成本，从 Hono 加 htmx 的 2.67 美元到 Angular 的 4.97 美元；这不是他使用订阅服务的逐次实际账单。大部分成功成品的 Lighthouse 分数接近满分，JavaScript 载荷、代码量和花费却不同。它说明同一个小任务的生成路径存在差异，尚不能回答长期维护哪个框架更便宜：这里没有持续加功能、多人接手或复杂应用状态的实验。
可信度 65 · 重要性 76 · 新颖度 77
技术与主题
AI 编程 · 评测与基准 · 前端框架 · 任务一致性测试 · 生成成本
deepsun
HN 原文讨论；质疑小型生成任务是否覆盖框架的长期价值。
忠实转述（非原句）：他认为，框架的重要作用是让一个长期项目在人员变化、功能增加后仍有约定可循。一个近似静态的小应用，难以表现跨模块依赖、复用和本地化等问题。因此，他质疑仅用这种任务评价框架是否划算，也追问有了 Agent 后哪些框架价值仍然成立。
robgibbons
回复 deepsun；提出不同的机制解释，而非复测结果。
忠实转述（非原句）：他反问：一致的约定难道不能同样帮助 Agent？在后续回复里，他把框架理解成限制可选路径的工具：面对少数明确接口，可能比自由组合整套标准库更容易。这为维护性提出另一种解释，但没有证明哪一种框架在本测试之外更优。
incrudible
同一讨论下的个人项目经历，未提供匹配对照数据。
忠实转述（非原句）：他尝试让 Agent 使用原生 JavaScript，起初顺利，项目变大后却感觉缺陷和混乱增加，后来回到 React。他看重的是较容易推理的状态转换和稳定接口，同时不喜欢频繁变化的外围生态：模型若以为自己知道旧 API，可能先写错，之后才去查文档。这是一种实际维护痛点，不能由此推出所有项目都应使用 React。
编辑评读
这份测试最有用的地方，是把“Agent 会不会用某框架”改成一个可比较的具体任务。模型熟悉度、查文档的路径、框架默认配置都可能进入成本。作者观察到某些运行反复查迁移指南，这提供了排查方向，但没有隔离变量，不能直接断言某份文档造成了全部差价。
选型时还需要明确要节省哪一种工作。一次生成少花几美元，与下一位维护者能否理解状态流转，是不同目标。框架约定可能增加初始代码，却减少后续修改的选择空间；反过来，简单内容页也可能根本不需要复杂框架。可迁移的方法是固定一个真实功能，再加入一次跨页面状态修改和一次陌生人接手，分别记录生成费、缺陷及理解时间。这是编辑建议，今天的测试并未覆盖这些阶段。
核查依据
- 支持本文所述原始机制、条件或署名评论；读取范围见research-audit。
- 支持本文所述原始机制、条件或署名评论；读取范围见research-audit。
- 支持本文所述原始机制、条件或署名评论；读取范围见research-audit。
- 支持本文所述原始机制、条件或署名评论；读取范围见research-audit。
- 支持本文所述原始机制、条件或署名评论；读取范围见research-audit。
- 支持本文所述原始机制、条件或署名评论；读取范围见research-audit。