最近读到 Josh Morony 的一篇文章：Some thoughts on Angular and LLMs。它不像一篇严谨的行业报告，更像一个长期使用 Angular 的开发者，在 AI 开始改变编程方式之后，记录下来的几段犹豫、判断和怀旧。
我很认同这种写法。关于 AI 和前端框架的讨论，很多时候都急着宣布谁会胜出：React 会不会继续扩大优势，Angular 会不会被淘汰，开发者是不是很快就不需要学习框架。原文没有急着下结论，而是承认这些判断缺少足够证据，同时把自己真正观察到的变化说清楚：写代码的工作正在变化，框架的价值也会跟着重新分配。
LLM 会写掉大部分语法，但写不掉工程判断
原文提出了几个我认为很可能成立的判断：以后绝大多数代码会由 AI 生成，人类不再逐字输入语法；但对于复杂系统，架构、规划和维护仍然需要有经验的工程师。
这两句话放在一起很重要。它说的不是“程序员不需要了”，而是程序员的工作重心会移动。
一个组件该怎么声明，一个表单该怎么绑定，一个接口调用该如何封装，这些事情越来越适合交给 LLM。它们有明确的输入和输出，有大量公开的范例，也容易通过编译器、类型检查和测试来验证。让人逐字符地输入这些内容，本来就不是软件开发中最有价值的部分。
但是，下面这些问题不会因为模型能生成 TypeScript 就自动消失：
- 这个状态应该归哪个模块所有？
- 哪些数据可以缓存，哪些数据必须以服务端为准？
- 失败之后应该重试、回滚，还是阻断后续操作？
- 一个看似简单的需求，会不会破坏权限、幂等性和审计边界？
- 为了今天的速度接受的技术债，半年后由谁来维护？
LLM 可以给出很多局部正确的实现，但它未必知道一个项目真正不能被破坏的前提。复杂系统的难点从来不只是“把函数写出来”，而是知道这个函数不应该越过哪条边界。
所以，AI 生成代码之后，工程师需要投入更多时间理解全局，而不是更少。代码输入减少了，系统判断反而变得更重要。
Angular 的优势，可能恰好是它的边界感
原文对 Angular 的判断很有分寸：Angular 具备支撑良好架构的结构，也能和 LLM 配合得很好；但 React 已经成为默认选择，训练数据和社区规模会继续强化这种默认。已有大型 Angular 项目会继续使用 Angular，而需求简单的新项目可能更容易选择 React。
我觉得这里最值得讨论的，不是哪一个框架“更先进”，而是框架是否把系统的边界表达得足够清楚。
Angular 的模块组织、依赖注入、路由、模板、表单和约定，常常会让一个小项目显得有些正式。但当应用变大、参与者变多、业务规则变复杂时，这些约束也会带来一种可预测性：新代码应该放在哪里，依赖从哪里来，页面和服务怎样连接，很多问题都有相对明确的答案。
这对 LLM 也有帮助。模型面对一个约定清楚的项目，更容易找到正确的入口和相邻实现；生成代码之后，人也更容易检查它有没有越过架构边界。框架的价值不只在于减少代码量，也在于减少“每个人都可以自由发挥”的空间。
当然，这并不意味着 Angular 天然适合 AI，或者 React 天然不适合工程化。React 项目同样可以建立严格的目录、状态和依赖规则，Angular 项目也可能被写成混乱的“大泥球”。最终起作用的，是项目是否把关键约束写下来，并用类型、测试、评审和自动化检查把它们固定住。
开发体验的价值，正在从框架迁移到工作流
这是原文最打动我的部分。
过去我会很在意 Angular 的新特性。更好的表单 API、更清晰的控制流、更合理的变更检测方式，都会直接改善写代码的感受。开发者体验不是装饰：开发者少一点重复劳动，就更有精力理解业务；代码更容易读懂和修改，长期质量也更可能提高。
但现在，开发体验的“获得方式”正在改变。它不再只来自框架语法，还来自 LLM、项目规则、提示词、代码检索、测试循环和自动修复工具组成的工作流。
以前，Angular 中重复导入很多依赖是一件令人烦躁的小事。现在，如果模型能够根据项目结构正确补全这些导入，我可能根本不会把它当成重要问题。以前，表单 API 的改进会让我兴奋，因为我需要亲手写下每一个表单字段；现在，我更可能让模型完成迁移，然后检查迁移是否影响了验证逻辑、错误提示和提交流程。
这不是说 API 设计不重要了。更准确地说，是 API 的价值不再主要体现在“我输入它时有多舒服”，而体现在“它能否让整个系统更容易被理解、生成、验证和维护”。
当我审查 AI 写出的表单代码时，我通常不会逐字符检查每一行。我会看它是否符合现有的数据流，是否正确处理加载和失败状态，是否保留了权限和校验规则，是否让下一个人能够继续修改。语法层面的便利仍然存在，只是它不再是开发体验的全部。
框架之争会变得没有以前那么重要
如果大部分样板代码都可以由模型生成，框架选择的差异会缩小一部分。模型可以快速学习一个框架的常用写法，也可以根据官方文档完成迁移。工程师真正关心的，可能会越来越接近这些问题：
- 团队能不能理解并约束生成的代码？
- 项目的架构是否足够清楚，让模型和新人都能找到正确的扩展点？
- 有没有稳定的类型检查、测试、构建和发布流程？
- 出现错误时，能不能快速定位是需求、生成代码还是系统边界出了问题？
这会削弱框架的身份属性。过去，一个团队可能因为“我们是 Angular 团队”而形成共同体，也会围绕依赖注入、Observable、Signals 或变更检测建立技术认同。以后，这些实现细节仍然需要理解，但它们未必还会构成同样强烈的身份认同。
这其中确实有一点失落感。亲手写代码、等待编译、研究一个新 API、把复杂问题整理成优雅的抽象，这些过程本身曾经就是工作的乐趣。当模型把其中很大一部分接过去之后，我们得到的是效率，也会失去一部分“我正在制造这个东西”的感觉。
我对 Angular 的判断
我不认为 Angular 会因为 LLM 出现就消失。对已经拥有复杂业务、成熟团队和长期积累的组织来说，迁移框架的成本不会因为 AI 能写代码就消失。相反，稳定的架构和明确的约束，可能会让这些团队更愿意继续使用熟悉的技术栈。
我也不认为 Angular 会自动成为 AI 时代的赢家。React 的生态、默认地位和训练数据优势都是真实存在的。对于页面简单、团队规模小、需要快速试错的项目，React 仍然很可能是更顺手的选择。
对我来说，更现实的结论是：不要把框架当成能力的全部，也不要把模型当成架构师。
选择 Angular，应该是因为它能帮助团队表达边界、保持一致性，并且适合项目的长期维护；选择 React，也应该配套建立同样清晰的工程约束。至于具体的组件语法、导入方式和表单写法，可以交给 AI 加速，但前提是我们仍然知道它为什么这样写，以及什么时候不能这样写。
AI 写掉的是代码输入，不是责任。框架变得不那么耀眼之后，真正留下来的，可能正是软件工程最朴素的部分：理解问题、设计边界、验证假设，然后对系统在真实世界里的行为负责。