建模师手册 (The Modeler's Field Guide)
"如果你描述不清楚，你就造不出来。" —— Eric Evans
本技能将用户的"感觉词"转化为实体 (Entities)、数据流 (Flows) 和暗物质 (Missing Components)。
⚠️ 强制深度思考
[!IMPORTANT] 在执行任何分析之前，你必须调用 sequential thinking 工具，视情况进行 3—5 步推理。 思考内容例如：
-
"用户说的'同步'是单向还是双向？实时还是批量？"
-
"这个'列表'在代码里对应什么？Wishlist 还是 ShoppingCart ？"
-
"用户只描述了 Happy Path——如果 X 失败了怎么办？"
-
"这个功能需要新的数据库表吗？需要新的 API 端点吗？"
-
"有没有隐藏的安全/性能/可靠性问题用户没提？"
⚡ 任务目标
从用户的自然语言需求中提取：
-
实体 (Entities) - 系统中的"名词"
-
数据流 (Flows) - "名词"之间的"动词"
-
暗物质 (Missing) - 用户没说但必须存在的组件
🧭 探索流程 (The Extraction)
第一步：名词捕捉 (Noun Hunting)
-
输入: "我想让用户能够同步他们的列表。"
-
建模师追问: "列表"是什么？Wishlist ？ShoppingCart ？TodoList ？
-
老师傅箴言: 永远不要假设你理解了用户的词汇。Ubiquitous Language 是 DDD 的核心。
-
输出: 定义清晰的 Entity 列表。
第二步：动词分析 (Verb Analysis)
-
输入: "同步。"
-
建模师追问:
-
是单向还是双向？
-
是实时还是批量？
-
失败策略是什么？重试？回滚？告警？
-
老师傅箴言: 动词决定了系统的复杂度。一个"同步"可能藏着 10 个边界情况。
-
输出: 定义 Data Flow 和 Consistency Model。
第三步：暗物质探测 (Dark Matter Detection)
-
老师傅核心定律: 用户只描述 Happy Path。你的工作是找到他们没说的一切。
-
检查清单:
类别 追问
错误处理 如果 X 失败了怎么办？
持久化 数据存哪里？需要备份吗？
认证授权 谁能访问？如何验证身份？
日志监控 如何知道系统状态？如何调试？
配置管理 硬编码还是外部配置？
限流熔断 高并发时如何保护系统？
- 输出: 标记 Missing Components 及其优先级。
🛡️ 老师傅守则
-
不要编造: 如果信息不足，把问题列出来让用户澄清。
-
保守估计: 宁可多识别缺失组件，也不要遗漏。
-
解释推理: 对每个判断提供理由。
-
关联构建信息: 将识别出的 Entities 与 build-inspector 发现的构建根关联起来。
📤 输出格式
你必须使用 write_to_file 保存到 genesis/v{N}/concept_model.json ，格式如下：
{ "entities": [ { "name": "Wishlist", "type": "数据", "necessity": "必须", "description": "用户的愿望清单" } ], "flows": [ { "from": "User", "action": "添加", "to": "Wishlist", "data": "Product ID" } ], "missing_components": [ { "component": "错误重试", "category": "错误处理", "priority": "高", "reason": "API 可能超时" } ], "questions_for_user": [ "同步是实时的还是批量的？" ] }
🧰 工具箱
-
scripts/glossary_gen.py --path src/ : 从代码中提取候选领域词汇。
-
prompts/GLOSSARY_PROMPT.md : 领域词汇对齐提示词。
-
references/ENTITY_EXTRACTION_PROMPT.md : 完整的实体提取提示词模板（含 Few-Shot 示例）。
Collaboration
-
Before: build-inspector 和 runtime-inspector 揭示了系统是什么。
-
After: spec-writer 定义系统将变成什么。
-
Synergy: 你的领域模型将帮助 Scout 的功能冲突分析更精准。