当我谈论 AI 辅助编程时，有一个核心流程被我称为”飞轮”：Plan（计划）、Build（构建）、Verify（验证）。理论上，这三个环节环环相扣，形成正向循环。然而在 JavaScript 项目中，这个飞轮却常常变成一个越转越慢、最终卡死的齿轮组——三个环节的噪声不仅都很大，而且逐级递增。

Plan：在流沙上做决策

规划环节的首要任务是理解现有代码库并制定修改策略。但在 JS 生态中，这件事从一开始就充满不确定性。

版本管理的混乱是第一道坎。 JS 库的版本控制几乎形同虚设。以 Next.js 为例，从 12 到 13 再到 14，每个大版本都可能引入破坏性变更。上个版本运行良好的 API，下个版本可能直接废弃。这意味着 Agent 在规划时必须精确了解项目使用的每个依赖的具体版本，否则生成的代码很可能根本无法运行。

模型训练数据的滞后加剧了这个问题。 大语言模型的知识更新速度远远跟不上 JS 生态的迭代节奏。一个库三个月前的用法，今天可能已经完全不同。这迫使我们不得不依赖实时的 Context 索引来弥补。

然而 Context 索引又带来了上下文污染。 每次规划都需要向 Agent 注入大量项目特定的上下文信息：框架版本、配置方式、既有代码模式。上下文越长，LLM 的规划能力就越容易退化。更糟糕的是，索引到的代码未必是最新的、可用的——你可能花了大量 token 让模型理解了一段早已过时的实现。

JS 项目缺乏统一架构更是雪上加霜。 Ruby on Rails 有约定优于配置的强制规范，Spring Boot 有清晰的分层结构，Laravel 项目也有相对固定的组织方式。但 JS 项目？几乎没有统一标准。即使是号称”有态度”的 NestJS，只要团队中有人不守规矩，架构照样会乱成一团。这意味着 Agent 在规划前必须进行大量探索，进一步加剧上下文膨胀。

结果就是一个恶性循环：为了做好规划需要更多探索，探索导致上下文爆炸，上下文爆炸导致规划质量下降，规划质量下降又需要更多探索来弥补。

Build：混乱中的执行

有了规划之后，Build 环节理论上应该是”照本宣科”。确实，随着 Agent 技术的成熟，这个环节已经不像以前那样依赖模型的原始能力了。即使是 Claude Haiku 或 GPT-5-mini 这样的小模型，也能胜任大部分构建任务。

但 JS 语言本身的特性让执行过程依然充满变数。

计划与现实的偏离几乎不可避免。 当 Agent 真正开始写代码时，经常会发现实际情况与规划阶段的假设不符。某个 API 的实际行为与文档描述有出入，某个类型定义比预期更复杂，某个依赖存在未记录的副作用。

各种切面问题让执行变得异常复杂。 CommonJS 与 ES Modules 的混用、不同 Bundler 的配置差异、运行时与构建时的行为不一致——这些问题在其他语言生态中要么不存在，要么有明确的解决方案，但在 JS 中往往需要逐个踩坑。

不过，Build 的混乱尚在可控范围内。真正的深渊在下一个环节。

Verify：真正的混沌

验证是整个飞轮中噪声最大的环节。在 JavaScript 项目中，验证过程需要同时处理多个相互独立却又彼此纠缠的切面。

TypeScript 切面是第一层。 类型检查的结果与 IDE 诊断信息紧密相关，Agent 需要理解并响应这些诊断。但 TS 的类型系统本身就相当复杂，泛型、条件类型、类型推断的边界情况，每一个都可能让 Agent 陷入困境。

CSS 切面是第二层，而且情况更加微妙。 如果项目使用独立的 CSS 文件，Agent 不仅要记得更新 CSS，还要记得对 CSS 运行单独的 Lint 规则，然后再进行一轮验证。这个步骤极其容易被遗忘。如果项目使用 Tailwind CSS，问题就更加有趣了：在同一个 TypeScript 文件里，突然出现了第二种 DSL。这种 DSL 与原生语言特性毫无关系，本质上属于另一个编译器的范畴。当 LLM 需要在同一个文件里处理两套完全不同的概念体系和 Lint 工具时，是非常容易少做、出错的。

构建流程本身又是一层复杂性。 编译、验证、Lint、Format——每一步都可能产生新的问题。CI/CD 流程衍生出的子环节更是数不胜数。整个验证过程极容易偏离初衷，Agent 可能花费大量精力修复一个 Lint 错误，却在过程中引入了三个新的类型问题。

最后还有一个隐藏的陷阱：JS 社区的审美偏好。 大部分 JavaScript 库默认认为”代码写得好看”比”架构设计优秀”更重要。这种价值取向导致了一个后果：当 Agent 在验证过程中需要修改代码时，很容易打破那种表面上的”完美”。一旦这层精心维护的外壳被戳破，露出的是业务逻辑的真实复杂性。Agent 没有能力维持那种精雕细琢的代码风格，于是代码开始变丑。

而丑陋的代码会让下一轮 Plan 更加困难，Plan 的质量下降导致 Build 出现偏差，偏差需要在 Verify 环节修正，修正过程产生更丑的代码。

飞轮确实转起来了，只不过是反方向的。

结语

这并不是说 JavaScript 不能用于 AI 辅助编程，而是说当前的 Coding Agent 架构在面对 JS 生态时会遇到结构性的困难。版本管理的混乱、架构的缺失、多切面验证的复杂性，这些问题相互叠加、彼此放大。

或许我们需要为 JS 项目设计专门的 Agent 策略：更保守的规划、更频繁的验证检查点、更严格的上下文管理。又或许，这恰恰说明了为什么在需要高度可靠性的场景下，那些”无聊”的、有强制规范的语言和框架反而更有优势。

毕竟，AI 和人类一样，在混乱中工作的效率远不如在秩序中。