把变化留在边缘，把公共骨架固定下来
- 接口先标准化，避免每个客户改协议。
- 数据库先标准化，避免每个项目重画表结构。
- 模板先标准化，避免客户自己猜该准备什么。
- 差异放在适配器和映射层，不反复改核心。
Boundary
标准化边界
不是给每个客户重新发明一套数据模型，而是固定公共骨架，让适配差异留在边缘。标准接口
标准接口：query / feedback / sync / schema / health
标准数据
标准数据：知识资产、会话记忆、反馈、学习任务、审计事件
标准模板
标准模板：菜单映射、权限映射、知识导入
标准返回
标准返回：answer + steps + warnings + sources + learningImpact
标准适配
标准适配：宿主系统负责把自己的字段翻译到标准协议
Domain Model
为什么要分软件域 / 租户域 / 用户域
这不是为了学术好看，而是为了让同一套引擎能够复用，又不把不同项目的数据搅在一起。软件域
按 softwareId 区分不同软件产品。不同软件的菜单结构、术语和业务逻辑不能混在一起。
租户域
按 tenantId 区分客户或组织实例。即便是同一套软件，不同租户的菜单开通、规则和知识也可能不同。
用户域
按 userId、roleCodes、permissionCodes 收口权限上下文。智引不接账号密码，只消费宿主给出的可信上下文。
Deployment
数据库应该怎么放
客户不一定懂建什么库，所以你要给标准脚本和明确建议，而不是让对方自由发挥。推荐：独立数据库或独立 schema
最稳妥。知识、反馈、审计与宿主业务库隔离，升级和迁移边界清楚，也方便未来多项目复用。
可选：宿主现有数据库内单独命名空间
适合客户运维约束较强的场景，但仍要保持 Ziin 自己的表结构和版本治理，不要混进宿主核心业务表。
不建议：直接塞进宿主业务表
短期看省事，长期会导致知识、反馈、审计与业务表互相污染，后续升级、迁移和跨项目复用都很难做。
Delivery Pack
标准交付包
如果客户不知道该准备什么，那说明交付包还不标准。这里把核心交付项固定下来。给客户什么
SQL、模板、接入清单、2 天接入流程和公开文档链接。
客户需要提供什么
菜单清单、权限码、试点模块、手册/FAQ/错误库、宿主 token 上下文字段。
为什么这套抽象有普遍意义
因为绝大多数业务系统接入时都会遇到菜单不统一、权限不统一、文档不统一、部署不统一这四个问题。
Standard Layers
标准化不是一句口号，而是四层一起固定
真正可复用的产品，不是只固定接口，而是从协议到交付都能重复复制。协议层
统一 query、feedback、sync、schema、health 契约，让 Web、App、小程序、宿主智能体共用一套能力出口。
数据层
统一知识、记忆、学习任务、审计事件模型，避免每接一个客户就重画数据库。
映射层
宿主系统只负责把自身菜单、权限、术语和路由翻译到标准模型，不碰核心返回结构。
交付层
通过 SQL、模板、清单、示例代码和运营台，形成可重复交付的产品包。