设计反思：一个被 AI 改道的低代码插件

这是矩阵工坊的归档反思，也是它开源的原因——把「为什么停更」和「哪里值得继续」写清楚，比只留一堆代码更有价值。

项目初衷

2024 年立项时的判断：DDD 落地难，难在「分层约束靠自觉」。于是有了矩阵框架（运行时约束）+ 矩阵工坊（设计时约束）的组合拳：

框架负责「跑起来之后不跑偏」：kernel 内核强制 DDD/CQS 基础类；
工坊负责「写出来之前就对」：ASN 建模 → 校验 → 生成符合分层的代码。

「架构骨架由工具严格生成，业务血肉由开发者填充」——这就是 Constrained Intelligence 理念的雏形。

转折：AI 编码助手成熟

开发过程中 AI 编码助手迅速成熟，项目面临一个根本问题：

当开发者对着 AI 说「给我一个符合 DDD 分层的订单聚合」，还需要在 IDE 里点选建模面板吗？

低代码工具的核心价值（把重复结构自动化）正在被 LLM 以更低成本覆盖。继续打磨「IDE 内建模面板 + 模板生成」，很可能在发布之日就已过时。于是项目停更。

但有三件事，AI 没有取代

1. 领域知识的结构化（ASN）

LLM 生成代码的质量瓶颈不在代码，而在需求的精确表达。ASN 把限界上下文、原型、前端抽象形式化为可校验的模型——这本质上是给 AI 一个「可验证的脚手架」。约束越精确，生成越可靠。今天的 prompt engineering、spec-driven development，走的是同一条路。

2. 架构一致性的机械化保障

AI 生成单文件很强，保证跨模块一致性很弱。ASN + Generator 的价值在于：分层、依赖方向、命名规范是机械校验的，不依赖模型「自觉」。这与今天「AI 写代码 + 架构守护测试/ArchUnit 兜底」的实践完全同构。

3. 用 DDD 分层组织复杂工具本身

plugin-domain / plugin-infra 的划分让插件本体的业务逻辑（建模规则、校验、生成编排）不依赖 IntelliJ Platform API，可独立测试。这个实践不因 AI 兴起而过时——工具代码也需要架构。

如果今天重做

ASN 保留：它就是 spec。但编辑器从「建模面板」变成「文本 DSL + AI 补全」；
Generator 简化：模板只生成骨架（Skeleton），血肉全部交给 AI（Body）——正是蓝图里 Constrained Intelligence 的完整形态；
IDE 插件的角色变化：从「生成器」变成「AI 的约束提供者与结果校验者」。

给同类项目的建议

先形式化领域约束，再谈自动化——约束是资产，面板是成本；
低代码与 AI 不是二选一：确定性部分用工具，生成性部分用模型；
项目可以归档，设计文档要活下来——这也是本仓库开源的原因。