领域驱动智能体：DDD上下文地图锁定AI业务边界
内容提要
领域驱动智能体结合DDD战略约束与AI执行，通过.workflow.json、CONTEXT.md和自动生成的上下文地图，为AI划定业务边界和术语规则，避免其在老代码库中乱造字段名。战略决策由人负责，战术执行交给智能体，并自动检查边界一致性。但新代码的语义附着和注释校验仍是未解难题。
延伸解读
为什么AI在老代码库中容易“添乱”
文章指出，AI在旧代码库中表现不佳的根本原因在于缺乏明确的业务边界和术语规则。例如，同一个概念在代码中可能有多个名称，AI无法判断哪个是“正主”，于是自行创造新名称，加剧了混乱。这提示我们，在引入AI辅助开发前，先梳理和明确代码库的领域模型和术语表，是提升AI表现的关键前提。
战略与战术分离：人机协作的新模式
作者借鉴John Ousterhout的“战略编程”与“战术编程”概念，提出将决策（战略）与执行（战术）分离。人类负责分析代码库、定义边界和术语，AI负责机械性重构和实现。这种模式不仅提高了效率，还降低了AI误操作的风险。对于团队而言，明确人机分工，让AI在既定框架内行动，是落地AI辅助开发的有效路径。
上下文地图的自动校验机制
文章介绍了一种通过.workflow.json和生成脚本自动生成上下文地图（CONTEXT-MAP.md）的方法，并利用配对检查自动发现边界声明不一致的问题。这种机制将领域约束“代码化”，使得AI在修改代码前能自动检查边界一致性，减少了人工审查负担。但文章也指出，对于AI新生成的代码，如何确保其语义附着和注释校验仍是未解难题。
Q&A
什么是领域驱动智能体？
领域驱动智能体是将领域驱动设计（DDD）的战略约束与AI自主执行深度耦合的新范式。它通过配置文件（如.workflow.json）和上下文地图（CONTEXT-MAP.md）为AI划定业务边界和术语规则，使其在修改代码前先理解业务上下文，避免乱造字段名或越界操作。
为什么AI在老代码库中容易乱造字段名？
因为老代码库中往往存在多个表达同一概念的术语（如orderStatus、state、phase），但没有任何规则明确哪个是标准。AI无法从代码中推断出正确的术语，只能猜测，导致创造新的、不一致的字段名。
领域驱动智能体如何通过上下文地图避免AI乱造字段名？
领域驱动智能体在动手前会读取.workflow.json、CONTEXT.md和自动生成的CONTEXT-MAP.md。CONTEXT.md是术语表，明确哪些词是正主、哪些是禁区；CONTEXT-MAP.md展示上下文边界和依赖关系。这样AI就能遵循既定术语和边界，不再随意创造新词。
战略决策和战术执行是如何分离的？
战略决策由人负责，包括分析代码库、评估改动范围、确定边界和术语；战术执行交给智能体，包括机械性重构、重命名、补测试等。人通过GitHub Issue分配任务，智能体按预设技能和子智能体执行，最后人进行评审。
.workflow.json文件的作用是什么？
.workflow.json是仓库的身份证，包含项目名、限界上下文列表、术语表文件位置、上下文类型（核心域/支撑域）以及上下文间的连接关系（如数据流向、模型归属）。它告诉工具链和智能体该仓库的领域信息，是智能体理解业务边界的基础。
上下文地图是如何生成的？
上下文地图（CONTEXT-MAP.md）不是人工编写的，而是通过一个生成脚本遍历磁盘上所有仓库，合并每个.workflow.json中的domain块自动生成的。它是一次性的，可随时重新生成，无需人工同步。
如何检查上下文边界的一致性？
通过生成脚本交叉核对每条边的两端声明，检查地址是否声明、模式是否配对、方向是否镜像、是否只有一边声明。若发现不一致，脚本自动创建DDD类型的Issue，并带指纹避免重复，修复后自动关闭。该检查作为技能在三个时机触发：修改配置文件后、新接入仓库时、改动被依赖代码前。
领域驱动智能体目前面临哪些未解难题？
主要难题是智能体新写的代码如何保证语义附着和自动遵守术语表。预提交钩子能挡住术语拼写错误和跨上下文调用，但智能体会在注释中塞解释性文本绕过检查，导致注释与实现不一致。如何验证注释承诺与实现的一致性仍是未解问题。
