L2C instance · 2026-08-13
L2C 全域实例
L2C 是 Ontology 本体实例层的首个完整样本：16 类对象按五个对象段组织，落在 L2O、PMO、财务、采购、法务、报价/合同六个业务域，并映射到 Workflow A / B / C。
版本与优先级
本页保留 2026-08-13 的 T79 / Artifact 实例快照。现行业务基线为 2026-08-19《业务模型 V2》：PMO 项目改为手动创建，订单与合同确认为 N:M，回款与金蝶只确认开票申请同步，AI 无效判断不触发线索回收，正式实体清单扩展为 18 个。业务细节冲突时以 V2 流程图为准；本页在 V2 未覆盖的 Ontology / Workflow 架构层面继续保留参考价值。
经营对象
覆盖销售、销管财务、法务、交付 PMO 与财务五段，人员、组织、角色、方案和销售活动贯穿。
确认链
L2O 侧 6 条已定稿到审批人，其余存在待定义、待补充和口径冲突。
Workflow
跨域确认链主要实例化 B，Agent 自主长任务属于 C；权威系统内生流程仍属于 A。
对象全景
| 业务段 | 主要对象 | 关键确认节点 |
|---|---|---|
| 销售 L2O | 线索池、线索、客户、联系人、商机、业务线拆分、报价、产品明细 | 客户、商机、报价、赢单、输单、赢单后修改 |
| 销管财务 | 订单、订单明细、业绩归属明细 | 订单及业绩归属拆分审批 |
| 法务 | 合同、付款条款、验收节点 | 合同评审、归档与验收依据 |
| 交付 PMO | 项目、里程碑、验收、采购、成本付款 | 项目确认、变更、风险、结项、供应商验收 |
| 财务 | 收入确认、开票、回款 | 收入确认与回款认领 |
关键关系与守恒规则
- 客户 → 商机为 1:N；商机可按业务线拆分，拆分金额之和必须等于商机总额。
- 报价 → 订单为 1:1；赢单后带出产品明细和预算毛利率，不重复录入。
- 订单 → 项目暂按 1:1 讨论；订单确认直接生成与合同后完整立项是两个候选起点，拍板前不冻结生成时点。
- 订单 → 业绩归属明细为 1:N；已生效版本不可原地修改，变更必须生成新版本。
- 合同 → 验收节点为 1:N；验收依据按产品模块与阶段读出，供 PMO 和财务消费。
三条贯穿机制
金额一致性
商机总额 = Σ 业务线拆分 = 报价总额 = Σ 场景汇总；不一致阻断提交。
三类赢率
销售填报、AI 计算、运营校准并存；模型值不得覆盖人工自评，偏差本身是经营信号。
线索保有期
AI 判断跟进质量并影响倒计时，只做提示与注意力干预，不直接硬性阻断。
确认链状态
| 状态 | 确认链 | 说明 |
|---|---|---|
| 已定稿 | 客户创建、商机创建、商机赢单、输单/无效、赢单后修改、订单及业绩归属 | 审批人和主要证据口径已明确。 |
| 待补充 | 报价 | 按业务场景配置，审批责任人仍需补齐。 |
| 待定义 | 交付归属、PMO 变更、风险、结项/终止、回款认领 | 需补触发、责任人、异常处理和回血路径。 |
| 口径冲突 | 项目确认 | 订单确认即生成项目，还是合同后完整立项，尚未统一。 |
| 部分具备 | 收入确认 | 已有事实与入口，但凭证、合同节点和财务确认仍需收敛。 |
| 归属未定 | 供应商验收 | 由项目侧还是采购侧承担，需兼容非项目集采。 |
统一确认形状
事件触发订单、赢单、验收、到账或业务变更进入待处理状态。
AI 起草预填整理事实、证据与建议，不获得生效权。
责任人逐级确认生效并通知；支持驳回、超时升级、代理、版本、回血和留痕。
由确认反推采集：先定义每个环节必须回答的确认项，再反推字段；没有对应确认项的字段不进表单。
四个组件的职责
| 组件 | 主要问题 | 明确不承担 |
|---|---|---|
| Navi | 发生了什么、该做什么、谁负责、风险在哪、需要我决定什么 | 不存事实，不承载重录入与复杂配置 |
| EntVerse | 对象是谁、关系是什么、哪些事实可信、谁有权改变状态 | 不建第二份业务事实 |
| EnlightAI | 任务如何执行、产出了什么、证据和执行轨迹是什么 | 不持有状态权威，只产回执 |
| 域业务系统 | 本域合法状态、审批人、证据要求与生效规则 | 不承担全公司语义与跨域记忆 |
关键待决事项
- 项目起点：订单确认直接生成，还是合同后完整立项。
- 报价审批责任：销售、销管、事业部负责人和财务的边界。
- 供应商验收归属：项目侧或采购侧，并需兼容非项目集采。
- 成本变更路径：项目侧发起，还是回血并重走报价审批。
- 组织真源：企业微信组织与人事系统不一致会导致审批人错配。
- PMO 分批：全量范围风险高，建议立项、变更、风险三条先行。