面向切面编程（AOP）的回归：LLM 时代的全新诠释

背景

在编写代码时，程序员需要同时兼顾众多维度的需求。传统的编程实践往往将这些错综复杂的关注点交织在每一行代码中，导致代码难以维护、调试困难且扩展性差。

面向切面编程（Aspect Oriented Programming，简称 AOP）早在 20 世纪 90 年代中期就由 Gregor Kiczales 等人在 Xerox Parc 提出，其核心理念是希望程序员能够将这些关注点分离开来，逐一处理，而不是在每一行代码中混合处理所有逻辑。然而，AOP 原有的实现机制——特别是“连接点模型”（join point model），因其类似于恶搞性质的 COME FROM 语句，导致代码难以调试和维护，逐渐被主流开发社区所摒弃。

随着大型语言模型（LLM）编程能力的崛起，这一古老的理念迎来了新的审视机会。本文探讨了在 LLM 的辅助下，AOP 如何通过一种全新的、基于文档生成的方式重新焕发活力，从而解决传统编程中关注点混杂的痛点。

核心内容

程序员面临的 17 重关注点

文章首先列举了程序员在编写代码时必须追踪的 17 个关键维度，这些维度构成了软件质量的基石：

1. 正确性（Correctness）：确保程序行为符合需求，维持重要的不变量，并按预期执行业务逻辑。
2. 效率（Efficiency）：最小化时间、内存和资源消耗。包括避免内存泄漏、碎片化，以及在具有“实时约束”的程序中满足特定的响应时间要求（如 0.2 秒内返回响应）。
3. 可调试性（Debuggability）：当程序出错时，能够轻松定位问题根源并修复。
4. 可维护性（Maintainability）：代码需文档齐全、可读性强，风格内部一致，并与外部代码库风格兼容。
5. 可测试性（Testability）：便于编写单元测试和集成测试，且测试创建过程不过于复杂。
6. 日志记录（Logging）：生成执行路径和变量状态的追踪日志，辅助调试、监控效率及收集行为统计。
7. 安全性（Security）：限制用户仅执行授权操作，通常限于用户原本可执行的操作加上程序明确授予的少量额外权限。
8. 可扩展性（Extensibility）：允许通过少量的小改动轻松扩展程序功能。
9. 隐私性（Privacy）：除非明确授权，否则不得向其他任何人（包括程序所有者）泄露特定用户的数据。
10. 依赖管理（Dependency management）：确保使用第三方库符合许可证法律要求，解决库之间的版本冲突（如库 A 依赖 C v1，库 B 依赖 C v2），并确保这些库不违反上述其他关注点。
11. 部署（Deployment）：程序通常需在非开发环境中运行，需通过环境适配、容器化或转换工具来实现跨环境部署。
12. 可监控性/可观测性（Monitorability/Observability）：对于长期运行的程序，需通过独立接口实时获取日志级别的信息。
13. 持久化（Persistence）：长期运行的程序常需停止和重启，这通常要求程序员额外处理状态保存与恢复工作。
14. 输入验证（Input validation）：大多数程序需接收输入，并验证其格式是否符合预期或可转换为预期格式。
15. 错误处理（Error handling）：出错时应优雅降级，包括记录错误、通知相关人员，并将程序恢复到可接受状态。
16. 国际化和本地化（Internationalization and localization）：支持多语言界面和多地区运行。
17. 无障碍性（Accessibility）：以优雅的方式适配不同身体或认知能力的用户。

除了上述代码层面的关注点，程序员还需处理排期估算、同事沟通等非编码工作。AOP 的初衷正是为了解决将这些关注点从核心业务逻辑中剥离出来的问题。

传统 AOP 的困境：连接点模型

尽管作者认同 AOP 分离关注点的理念，但一直反感其具体的实现机制——“连接点模型”（join point model）。该模型本质上是在程序调用栈上进行运行时模式匹配。

例如，当调用栈顶部出现文件打开例程时，程序会触发日志记录逻辑。正如 Wikipedia 对 AOP 的描述，这种机制与编程史上作为玩笑提出的 COME FROM 语句非常相似，同样难以调试和维护。如果同事新增或重命名了文件打开函数，原有的匹配规则可能会失效，导致日志缺失，这种脆弱性是其被诟病的主要原因。

LLM 时代的 AOP 新范式

得益于 LLM 新近获得的编码能力，AOP 的理念得以以一种更优越的形式重生。在这种新形式中：

1. 分离文档：程序员只需为每个关注点编写单独的文档。
   • 正确性文档：通常是最长的，描述核心业务逻辑。
   • 其他文档：如可维护性文档可直接复用组织的风格指南；安全性、隐私性等文档描述相应的约束条件。
2. LLM 作为“织入器”（Weaver）：传统的 AOP 使用专门的织入器在编译期或运行期修改代码，而在 LLM 时代，LLM 本身充当了织入器。它读取这些分离的文档，生成最终的程序代码。
3. 基于语义而非字符串匹配：
   • 传统模型依赖具体的函数名或字符串进行匹配，极易因重构而失效。
   • LLM 利用其背景知识理解“打开文件”的语义，从而更稳健地处理逻辑织入。
4. 静态且可读的输出：
   • LLM 生成的代码是静态的（非运行时计算），且保持人类可读性。
   • 相比之下，AspectJ 等工具的“编译时织入”虽然存在，但其输出往往是难以阅读的原始 Java 字节码。

核心论点

作者指出，无论是否采用 AOP 理念，LLM 都将被用于生成代码。因此，AOP 的真正价值在于其“关注点分离”的概念，这为我们将指令（prompts）或文档组织给 LLM 提供了一种有用的结构化方法。

此外，这种模式还可以扩展为多 Agent 架构：可以将每个关注点的描述输入给不同的 Agent，由特定 Agent 从各自的角度（如安全性、性能、可读性）对代码进行批判和审查，从而进一步提升代码质量。

关键要点

• 编程的复杂性本质：软件开发不仅仅是实现业务逻辑，还涉及效率、安全、隐私、部署、可测试性等 17 个以上的非功能性需求。传统编程将这些需求混杂在代码中，增加了认知负担。
• AOP 的历史局限：传统的面向切面编程虽然理念先进，但其依赖的“连接点模型”（运行时栈匹配）过于脆弱，类似于 COME FROM 语句，导致调试和维护极其困难，因而未能成为主流。
• LLM 解决了 AOP 的实现难题：
  • 语义理解：LLM 能够理解代码的语义意图，而非依赖脆弱的字符串或函数名匹配，使得关注点的分离更加稳健。
  • 静态可读输出：LLM 生成的代码是静态且可读的，避免了传统 AOP 工具生成晦涩字节码的问题。
  • 文档驱动开发：程序员只需编写关注点文档，LLM 负责将这些文档“织入”代码。
• 关注点分离的新价值：在 LLM 时代，AOP 的核心贡献在于提供了一种组织提示词（Prompts）或需求文档的结构化框架。
• 可扩展的 Agent 协作：该理念可进一步演化为多 Agent 系统，每个 Agent 负责特定关注点（如安全、性能）的代码审查，形成闭环的质量保障体系。

意义与影响

1. 重塑软件工程的组织方式

这篇文章提出了一种将软件工程从“代码为中心”转向“意图为中心”的新范式。通过让 LLM 承担“织入”工作，程序员可以从繁琐的样板代码（如日志、权限检查、异常处理）中解放出来，专注于核心业务逻辑