ubiquitous-language

ubiquitous-language 技能概述

ubiquitous-language 的作用

ubiquitous-language 技能会把一段杂乱的对话整理成一个 DDD 风格的术语表：它会提取领域术语，识别歧义和同义词漂移，然后生成一个规范的 UBIQUITOUS_LANGUAGE.md 文件。如果你需要为产品、工程或 Technical Writing 建立共享词汇，这个 ubiquitous-language 技能可以帮助你把术语说清楚，而不是让模型即兴发挥。

适合谁安装

如果你正在定义领域模型、编写产品某个领域的文档、统一团队术语，或者清理规格说明和文档里让人困惑的表达，就适合安装这个 ubiquitous-language 技能。它尤其适合你已经有一段真实对话、访谈记录或需求讨论，希望快速把术语标准化的时候。

它为什么有用

它真正要解决的并不是“写一份词汇表”，而是“防止语义漂移”。当你最大的风险是不一致的命名、一个词承载太多含义，或者同一个东西被叫成好几个名字时，这个技能特别强。它更关注选定一个规范术语，并说明哪些说法要避免，而不是单纯生成一段说明文字。

如何使用 ubiquitous-language 技能

安装并定位技能文件

通过你的 skills manager 使用 ubiquitous-language install 流程，或者从仓库路径 mattpocock/skills 下的 skills/deprecated/ubiquitous-language 安装。先从 SKILL.md 入手；这里没有 helper scripts、references 或 resource folders，所以主要行为都集中在这一个文件里。

提供合适的源材料

要想把 ubiquitous-language 用好，最好提供一段包含真实领域语言的对话、笔记、工单线程或草拟规格说明。一个好的提示词会明确上下文和决策范围，例如：“从这段面向订单管理应用的产品发现对话中提取 ubiquitous-language 词汇表。优先处理 customer、order、invoice、shipment 和 refund 这些术语，并标出任何看起来含义过载的词。”

调整提示词以提升输出质量

这个技能在你明确告诉它哪些术语重要、词汇表服务于谁的时候表现最好。如果你想把 ubiquitous-language 用于 Technical Writing，就直接说明，并要求输出可复用于文档、UI 文案和 API docs 的术语。也可以加入约束，比如“优先使用有明确立场的规范术语”“指出要避免的别名”或“聚焦对用户可见的术语”。

按一个简单工作流来走

先贴入源对话或笔记；接着要求生成词汇表和它识别出的歧义；然后把生成的 UBIQUITOUS_LANGUAGE.md 对照产品现实进行审核：确认每个术语是否真的彼此独立，同义词是否应该合并，以及是否有术语需要改成团队实际在用的说法。

ubiquitous-language 技能 FAQ

它比普通提示词更好吗？

如果你想要的是可重复的术语清理，而不是一次性的摘要，那么答案是肯定的。普通提示词可能只会给你一串术语，而 ubiquitous-language 技能是专门用来识别歧义、提出规范写法，并把结果保存成可复用文件格式的。

它不做什么？

它不能替代和利益相关方的领域校验。它可以从对话中推断并整理术语，但不知道你们团队正式采用的是哪个标签。如果源材料太少或自相矛盾，输出应当被视为待审核的草稿，而不是最终事实来源。

对新手友好吗？

友好，只要你能提供清晰的源文本和目标领域。新手最常见的错误，是只说“给我一份词汇表”，却没有提供足够的领域上下文。对话越具体、受众越明确，ubiquitous-language 指南的表现就越好。

什么时候该跳过它？

如果你只需要一段简短的营销定义、一个通用词汇页，或者一个没有真实术语冲突的宽泛分类体系，就可以跳过这个技能。它最有价值的场景，是语言选择会影响实现、文档或跨职能对齐的时候。

如何改进 ubiquitous-language 技能

提供更多领域证据，不要堆更多空话

最大的提升来自更丰富的源语言：用户故事、支持工单、上手文案和产品讨论都很有帮助。对 ubiquitous-language 的使用来说，术语周围如果带有示例，比抽象的功能清单更容易被规范化。

要求它做出真正重要的决策

告诉技能你要优化什么：文档之间的一致性、UI 中更少的同义词、API 命名更清晰，还是更贴近 DDD。 如果你把 ubiquitous-language 用于 Technical Writing，就要求它优先选择适合标题、标签、表格行以及跨文档复用的术语。

留意常见失败模式

要防止它把彼此不同的概念过度合并、发明团队根本不会用的术语，或者把领域细微差别压扁成过于泛化的表达。如果第一版看起来太抽象，就补充边界案例的例子，并要求它围绕这些差异重写词汇表。

用具体纠正来迭代

提升输出最快的方法，是明确指出哪些术语选择不对，以及原因是什么。例如：“用 customer 代替 account，把 order 和 purchase 分开，且把 refund 和 credit 视为不同概念。” 这种反馈会让下一轮 ubiquitous-language 技能输出更精准。