版本：v1.3 ｜ 2026-08-17 ｜ 面向：主会话（tech lead）与全体开发 agent
上游：业务口径基线 v2.1（docs/business/xijian-business-baseline.md，唯一口径源）｜ 产品文档：docs/product/xijian-prd.html + 推荐子系统专属 docs/product/xijian-recommend-prd.html
v1.1：达人推荐子系统入编 ｜ v1.2：Schema 三分法定案（按新需求重新设计）+ 里程碑测试节律 + ux 实操走查
| 业务域 | 职责 | server（domains/） | console（features/） | miniapp | 数据 |
|---|---|---|---|---|---|
| 配置中心 | 基线 §12A 全部口径数字与开关 | config-center | settings/config | — | 新表 xijian_config |
| 达人域 | 三层库+旁类、档案、分级（ROI>10/CPM 阈值）、推荐指数、标签 | influencers | influencers | 入驻绑定 | 新表（演进域，旧数据映射导入）+ 采集同步 |
| 项目与计划域 | 项目/场次/业务单元；来客计划同步与管理（生效中筛选） | projects / plans | projects / plans | — | 共库既有 + 计划同步表 |
| 商单域 | 12+2 阶段、招募/报名、定向邀约、反选辅助（评分卡+推荐指数）、状态流 | orders | tasks / orders | 报名/入园/回填 | 新表（演进域，12+2 新状态机；旧 task_order 只读映射） |
| 结算域 | 达标自动判（可配阈值）、自动触发结款审批、打款双通道、三数一致 | settlement | finance/* | 结算查询 | 新表为主 + 历史旧表只读 + 审批流 |
| 数据域 | 来客同步、前端数据日更、场次看板（总曝光/总销售+多维图表） | datasync / dashboard | dashboard | — | 数据中台拉取 |
| 消息集成域 | 与消息工作台（天择侧）的接口：档案查询/议价落库/开权限动作/聊天导出 | msgbridge | — | — | API 契约为主 |
| 系统域（已建成） | RBAC/审计/健康 | system | system-* | — | xijian_audit_log |
域间硬依赖：配置中心 → 一切判定逻辑；达人域 → 商单域（唯一键：抖音号+手机号）；项目与计划域 → 开定向/开秒杀；商单状态流 → 结算域触发。
P0（链路主干，先跑通一条商单全生命周期） 1. 配置中心（基线 §12A 全量项）——一切自动判定的地基，最先做 2. 达人域基础：三层库新模型建表 + 档案 + 共库对接实证（连测试库 alembic upgrade、旧表摸底分类、RBAC 管理员一次性导入） 3. 建联登记自动化（§6.1）——8 月底存量达人进企微的硬期限直接依赖 4. 项目与计划域：计划同步 + 开定向/开秒杀达人线（§6.3，会议最大新需求） 5. 商单状态流（§7.2）：12+2 阶段 + 报名确认后自动触发（入园邀请 §6.4 / 拉群 §6.5）+ 达标自动判（可配阈值）+ POI 校验（§7.3）
P1（自动化增强） 6. 达人推荐子系统一期（§5.3/§6.13，战略级）：SOP 数字化清单 + 双锚建议价 + 决策留痕 + 特征快照库/标签库（从第一天按对外标准建——护城河地基）。前置数据项在 P0 末段先行：视频指标 API 接入、达人属地/接单密度/退款率内部聚合。二期（AI 内容理解·豆包视频模型）、三期（C/C 飞轮全自动）随 P2 排 7. 一键催发（§6.10）+ 时效自动催发（§4，全量统一标准） 8. 批量发送好友申请（§6.11，500/周 KPI 配套） 9. 结算域：自动触发结款审批 + 三数一致校验 + 对私手机号自动匹配（§7.5/7.6） 10. 场次数据看板（§6.12） 11. 议价落库接口 + 消息集成域契约（§6.2/6.8 配合项）
P2 12. 交稿审核 AI 化（§6.6，探店线） 13. 打款全线自动化（达播/云剪表） 14. 历史数据项目归属 AI 补录（§12 答复：AI 模糊匹配+人工兜底）
里程碑硬约束：存量达人进企微 8 月底前（P0-3 优先）；AI 自动回复 9-10（消息集成域配合项提前）；小程序周更节奏（达人侧功能提前一周排队）。
xijian_config（Alembic 迁移，key/value/value_type/description/source/updated_by/updated_at（分组由 key 前缀派生，无独立 group 列））；启动加载+进程内缓存，写入即失效重载app/domains/config_center/——读接口全域可用（cfg("roi.excellent_min")），写接口挂 system.config.write 权限 + 审计打点cfg()，机检（check_structure 扩展）grep 业务域内魔法数字告警；每个配置项注释 baseline_ref 指向基线条目独立新库（2026-08-17 用户拍板）：新系统使用全新数据库 xijian（开发/测试用 xijian_test），与旧 lynoxi/lynoxi_test 库完全解耦；同 MySQL 实例部署（跨库只读旧数据方便）。原「共库启动」演进为「同实例新库 + 跨库只读」。
数据获取分工与方式（2026-08-17 定案）：犀见不负责数据抓取，且外部数据一律走 API、绝不直连外部数据库（减少外部依赖）。三个口子：① 集星达人数据 → dls.lynoxi.com API（见 docs/dev/jixing-api-notes.md，含超时/重试/解包三坑）；② 项目经营数据 → 数据中台 API（ai.iphome.cn，20+ 表含达人带货归因/视频/订单/售后明细）；③ 林客计划数据 → 中台补充中（B3，就绪前 mock 不卡）。MCP 仅作人与 agent 的调研通道，服务端运行时集成一律 REST API（协议匹配：类型契约/超时重试/缓存/监控/易 mock 全在 API 侧成熟）。旧 api 生产容器内 8 个定时任务稳定运行中（集星月更/来客日同步/飞书 0701 镜像/订单过期/支付对账/优质达人自动入池）——它们持续维护 lynoxi 库数据，犀见跨库只读消费、不打扰不重写；集星等采集是否迁中台为将来议题，不预设。
Schema 三分法：
| 类型 | 策略 | 适用 |
|---|---|---|
| 新域新表 | 按 v2.1 口径自由设计（建在 xijian 库，表名不再需要 xijian_ 前缀） | 配置中心、推荐子系统（特征快照/标签/留痕）、邀约批次、计划库、RBAC（改为新表+一次性导入管理员，不再直连旧 admin_user 系） |
| 演进域 | 新表按新模型设计（xijian 库）；切流时自 lynoxi 旧库一次性映射导入 | 商单（12+2 新状态机）、达人三层库（分级/推荐指数新模型） |
| 历史旧表 | 跨库只读 lynoxi.*，不重建不写 | 历史成交价（行情锚）、旧订单（推荐标签） |
旧 schema 的坑（0701 错误 ROI 公式、单位混用、分页参数四套并存）是不照搬的理由；每张新表设计须对照基线条目注明口径出处。
xijian / xijian_test 新库 + alembic upgrade 实证；旧表结构摸底（生成 docs/dev/schema-notes.md，标注每张旧表属三分法哪类；必读 legacy 四件套与 gotchas）产品定调（2026-08-17）：统一运营台的主工作面板就是消息台——各类信息管理最终融合进以会话为中心的工作面（前端归一 B/C 阶段的信息架构以此为纲）；消息台亦是与达人端的主要沟通面板。工程上犀见只提供接口性能力（基线 §0）：达人档案查询（按唯一键）、议价结果写入（确认卡后）、开定向/开秒杀执行、30 天聊天导出、阶段状态查询。契约先行：每个接口在 docs/dev/msgbridge-contract.md 定义后再实现，变更走版本记录。
| 场景 | 流程 |
|---|---|
| 日常功能开发 | 主会话拆单 → 单 agent 批量承包（相关功能一批）→ 自验全绿 + commit → 主会话终验（含实机走查） |
| 涉及口径判定的逻辑 | 同上 + api-tester 契约测试必须覆盖阈值边界（阈值从配置中心取，测试验证可配性） |
| 写共库旧表 / 资金相关 / 对外发送（企微） | 全评审链：实现 → 独立 review → 修复轮 → 我终验；企微真实发送必须有 dry-run（三不自动化宪法） |
| 合入生产 / 切流 | 全评审链 + 测试环境实证 + 用户拍板 |
里程碑分层与测试节律（v1.2 定案）：
| 层 | 单位 | 收口要求 |
|---|---|---|
| 小里程碑 | PO 开发单 | 自验全绿（两端测试链） |
| 中里程碑 | 本纲领编号项 | qa-acceptor 实证验收 + 全量测试 |
| 大里程碑 | P0/P1/P2 期末 | 全量回归 + ux-reviewer 实操走查 + 终审级 review + 用户验收 |
CI 每 push 已跑两端全量，上表为最低保障线而非上限。
每完成一个 P0/P1 编号项在此打勾并注 commit；优先级调整须记录理由。与基线冲突时以基线为准。