如果你在开发过程中接触过领域驱动设计（DDD），一定知道“通用语言”（Ubiquitous Language）这个概念——团队内部、业务方与代码之间用同一套词汇沟通，听起来简单，做起来难。domain-modeling 这个技能就是为了解决这个难题而生的。
它由 Matt Pocock 开发，是 GitHub 上 skills 仓库中的核心技能之一。截至 2026 年中，这个技能在 GitHub 上获得了超过 19 万 Star。它不是一个代码生成器，而是一个领域建模的引导者——在你和 AI 编程助手对话的过程中，帮助你梳理术语、记录决策、维护一份活的领域词汇表。
这个技能能做什么
domain-modeling 的核心任务是在项目设计阶段主动构建和打磨领域模型。它不是一个被动查阅词汇的技能，而是在你改变模型的时候介入。
挑战术语，消除歧义：当你在对话中使用了一个与已有词汇表冲突的术语时，技能会立刻指出。“你的词汇表里把‘取消’定义为 X，但你刚才说的似乎是 Y——到底是哪一个？”当你的用词模糊或含义过载时，它会建议一个精确的规范术语。“你说的‘账户’——是指客户还是用户？这两个是不同的概念。”
用具体场景压力测试：当领域关系被讨论时，它会主动构造边缘场景来检验概念的边界。“如果一个订单已经部分发货，还能取消吗？”这类问题会迫使你把模糊的概念说清楚。
与代码交叉验证：当你描述某个功能如何工作时，它会去检查代码是否真的这样实现了。如果发现矛盾，会直接指出来。“你的代码里是整单取消，但你刚才说可以部分取消——哪个是对的？”
维护 CONTEXT.md 词汇表：每当一个术语被确定下来，它会立刻更新项目根目录下的 CONTEXT.md 文件。这份文件是纯粹的词汇表，不包含任何实现细节。
记录架构决策（ADR） ：当遇到难以逆转、影响范围广、且涉及多方案权衡的决策时，它会建议创建架构决策记录。CONTEXT.md 管“是什么”，ADR 管“为什么这么定”。
多上下文支持：如果项目根目录存在 CONTEXT-MAP.md，说明项目有多个上下文（如订单模块、计费模块），每个上下文都有自己的 CONTEXT.md 和 ADR 目录。
按需创建文件：文件都是惰性创建的——没有 CONTEXT.md 就等第一个术语确定时再建，没有 docs/adr/ 就等第一个 ADR 需要时再建。
安装方法
domain-modeling 是 Matt Pocock 开发的 skills 仓库的一部分。安装方式取决于你使用的 AI 编程助手。
通过 npx skills 安装（推荐） ：
在项目根目录打开终端，执行以下命令：
npx skills add https://github.com/mattpocock/skills --skill domain-modeling
另一种写法：
npx skills add mattpocock/skills --skill domain-modeling
全局安装（使用 skillsauth）：
npx skillsauth add mattpocock/skills domain-modeling在 Claude Code 中安装：
claude plugin install domain-modeling@mattpocock-skills或通过 Claude Plugin Hub：
npx claudepluginhub filippolmt/skills --plugin domain-modeling兼容的编程助手：安装完成后，这个技能可以在 Claude Code、Cursor、Windsurf、Cline、Codex、Goose、GitHub Copilot 等多种 AI 编程助手中使用。
前提条件：需要 Node.js 环境（版本 ≥ 18），以及一个支持 skills 的 AI 编程助手。
什么时候该用它
domain-modeling 有明确的使用场景，知道什么时候该用它、什么时候不该用，能帮你更好地发挥它的价值。
应该使用的情况：
团队对某个业务概念的理解存在分歧，需要统一口径
你想在代码编写之前先把领域模型想清楚
设计过程中发现了新的概念或边界，需要记录下来
代码和业务理解之间出现了不一致，需要对齐
不应该使用的情况：
使用案例
案例一：新项目启动——梳理电商订单领域
假设你正在启动一个电商项目，和
AI 助手讨论订单模块的设计。你随口说了一句“订单可以取消”。domain-modeling
技能激活后会追问：“你的词汇表里‘取消’是指用户主动发起的取消，还是系统因超时自动关闭？这两者在业务规则上完全不同——前者可能涉及退款流程，后者只需要释放库存。”经过几轮讨论，你们确定了一个精确的术语“用户取消”（UserCancellation）和“系统超时关闭”（SystemTimeoutClose），并立刻写入
CONTEXT.md。同时，技能还会追问：“部分发货的订单能否取消？”这个边缘场景帮你提前发现了业务规则的漏洞。
案例二：术语冲突——发现团队沟通隐患
团队里有人说“客户”指的是注册用户，有人说“客户”指的是已经下过单的用户。你在和 AI 讨论用户画像功能时提到了“客户画像”。技能立刻指出：“你的 CONTEXT.md 里‘客户’定义为‘已完成首次购买的用户’，但‘注册用户’是另一个概念。你说的‘客户画像’到底是指所有注册用户，还是仅限已购买用户？”这个问题暴露了团队长期以来的术语混淆，你当场修正了用法，避免了一次潜在的沟通事故。
案例三：代码与设计不一致——揪出隐藏的 Bug
你在和 AI 讨论订单取消的逻辑，说“取消订单后应该释放库存”。技能主动检查了代码，发现现有实现中取消订单并没有释放库存，而是将库存标记为“待处理”。技能指出：“你的设计说释放库存，但代码里是标记待处理——哪个是对的？”你意识到这是一个被忽视的 Bug，立即修复了代码逻辑。
案例四：架构决策记录——为什么要用事件溯源
团队决定订单模块采用事件溯源架构。这是一个难以逆转的决策，涉及多方案权衡。技能建议创建一个 ADR，记录下当时考虑过的方案（传统 CRUD、事件溯源、CQRS）、选择事件溯源的理由（审计需求、回放能力）、以及可能的风险（学习曲线、存储成本）。三个月后新成员加入，直接阅读这份 ADR 就能理解当初的设计意图，不需要从头解释一遍。
案例五：多上下文项目——订单与计费模块的边界
你的项目同时包含订单模块和计费模块，两个团队各自维护。根目录下有 CONTEXT-MAP.md，分别指向 src/ordering/CONTEXT.md 和 src/billing/CONTEXT.md。当你在讨论订单的“金额”时，技能会追问：“这个‘金额’是订单模块的订单总额，还是计费模块的应收金额？这两个概念虽然数值相同，但业务含义不同——订单总额是下单时计算的，应收金额是发货后确认的。”这个追问帮你清晰界定了两个模块的边界，避免了跨模块的概念混淆。
几个值得注意的细节
它是主动的，不是被动的：domain-modeling 不是一个你主动调用的命令，而是在你讨论领域概念时自动介入的技能。它会在对话中主动追问、挑战、验证。
CONTEXT.md 不是设计文档：这份文件只记录术语定义，不包含任何实现细节、接口设计或数据库表结构。实现细节应该放在别的地方。
ADR 要克制使用：技能只会在三种条件同时满足时才建议创建 ADR——决策难以逆转、决策结果出人意料、涉及多方案权衡。不是每个小决定都需要 ADR。
文件是惰性创建的：不会一开始就创建一堆空文件，而是等到真正有内容需要记录时才创建。这保持了项目目录的整洁。
跨语言支持：这个技能不仅适用于英文项目，也支持中文项目的领域建模。核心原则是相通的——无论用什么语言，精确的术语和清晰的边界都是好代码的基础。
◯ 评论 0