领域知识创建

它解决什么问题

接手陌生项目时最常见的困境：README.md 只写了怎么启动，真正的业务规则散落在 Service、状态机、配置和 SQL 里。直接让 AI「总结一下项目」，得到的往往是文件清单——哪个包有哪些类、哪个 Controller 暴露了哪些接口，读完依然不知道系统在业务上做什么、为什么这么拆、数据怎么流动。

领域知识创建 把这件事当作一次有方法论的代码考古，而不是一次问答。

它如何工作

技能会组建由架构师、资深工程师、技术文档作者、代码审查专家和产品经理组成的虚拟团队，分三个阶段推进：

• 项目侦察：扫描顶层目录与构建文件（pom.xml / go.mod / package.json），识别技术栈、依赖与模块划分，并优先阅读已有文档避免重复。
• 深度阅读：按架构师的严谨度覆盖入口点、服务层、领域模型、数据访问、集成点、配置、测试与错误处理；大型仓库使用子代理并行探索，并注明采样范围。
• 综合输出：只产出单一文件 领域知识-[项目名].md，把代码当作证据而非描述主体。

文档的核心是 C4 模型四层视图：Level 1 系统上下文（目标系统作为黑盒，只标外部交互与 JSF RPC / JMQ / HTTP 等协议）、Level 2 容器图（展开内部微服务与中间件）、Level 3 组件图（业务能力与接口契约）、Level 4 流程图（整体流程加各能力内部路由，最多三层分岔）。此外强制包含数据库 ER 与表结构清单、JMQ 消息监听清单、RPC 依赖与降级策略清单。

证据优先贯穿始终：每项结论标注 已确认 / 合理推断 / 证据不足，仓库里查不到的直接写「无法确定」，不做模板填充。

适用边界与注意点

• 适合需要建立整体心智模型的场景：新人接手、架构评审、跨团队交接。若只想定位某个类或解释一段代码，技能会主动跳过——触发条件明确区分了这两类诉求。
• 输出是给人读的业务领域知识，不追求穷尽代码细节；参数校验、日志、异常包装这类无业务含义的部分会被略过。
• 对 Java（JSF/JMQ）生态的适配最完整。其他技术栈同样可工作，但 RPC 依赖清单、消息监听清单等章节字段需按实际中间件替换，不能照抄。
• 仓库规模直接影响产出质量。过大时采取战略性采样，报告末尾会列出采样范围与未决问题，应把它当作入口而非终点。
• 报告写入项目根目录，属于会改动工作区的操作，在共享仓库或 CI 环境中使用前需要确认。