Claude Artifact · rendered reconstruction

经营对象工作台：L2C 全域架构与产品边界

回答两件事：Navi 经营对象工作台如何贯通 L2C 全域的对象、流程与确认；EntVerse、Navi、EnlightAI 与各业务系统如何分工。

日期 2026-08-13 方向与边界 旭日 L2C 业务口径 淼梅 交付域 PMO 技术评估 泽斌 原始 Artifact 60b94c8e…

原文重建版

本页依据认证会话中的完整渲染稿逐屏转录，恢复 01–07 全部章节、16 类对象口径、15 条确认链、架构图、职责矩阵、现状表和待决事项。原始 HTML/CSS 因跨域 iframe 无法导出。正文保留 2026-08-13 当时的表述；T79 后续收口 Ontology / Workflow 架构边界，2026-08-19《业务模型 V2》进一步收口项目手动立项、订单合同 N:M、报价、回款、线索治理和 18 实体业务口径。架构冲突以 T79 / 仓内 SSOT 为准，业务细节冲突以 V2 业务流程图为准。

问题

事实已在库，确认没有承载

归属、验收、变更散在各处，账往往到月度对账才发现不一致。

方案

统一动作，不统一界面

各域系统自建或接入；确认收敛为业务动作。Navi 与业务系统是同一动作的两个界面，AI 起草、人负责。

范围

16 类对象 · 15 条确认链

L2O 侧 6 条已定稿到审批人，其余 9 条待定义；目标是 09-30 数据结构化串通。

对象模型

对象全景图

图例：实线框 = 一等对象；虚线框 = 附属对象；着色 = 存在确认或审批动作的节点。

销售 L2O线索池 → 线索 → 客户 · 联系人 → 商机 · 业务线拆分 → 报价 · 产品明细 → 赢单

销管财务订单 · 订单明细 · 业绩归属明细

法务合同 · 付款条款 · 验收节点

交付 PMO项目 → 里程碑 → 验收；采购 · 成本付款

财务收入确认 → 开票 → 回款

贯穿全链方案 · 销售活动 · 人员 / 组织 / 角色

关系与基数

关系	基数	规则
线索 → 客户	N:1	判定有效后转客户，可同时创建关联商机
客户 → 商机	1:N	商机按业务线拆分金额，各拆分之和等于商机总额
业务线拆分 → 报价	1:1	拆分金额带入报价；报价锁定到产品级，产品自动归属业务线
报价 → 订单	1:1	赢单后自动带出产品明细与预算毛利率生成订单
订单 → 业绩归属明细	1:N	销售预设、运营审批；已生效版本不可原地修改，变更生成新版本
订单 → 合同	1:N	可分阶段签署或补充协议；合同至少关联商机或订单之一
订单 → 项目	1:1	原稿表述为订单确认事件直接生成项目；后续待决事项同时保留“合同后立项”分歧
合同 → 验收节点	1:N	按产品模块 × 阶段读出，作为收入确认凭证依据
订单 → 回款	1:N	跟踪回款计划与实际到账

三条贯穿全链的机制

机制	规则	失败处理
金额一致性	商机总额 = Σ 业务线拆分 = 报价总额 = Σ 各业务场景汇总；订单从报价带入不重填	不一致阻断提交
三类赢率	销售填报 → AI 计算 → 运营校准，运营校准权限最高；业绩预测 = Σ（业务线拆分金额 × 运营校准赢率）	填报与 AI 偏差超过 20% 触发预警并纳入考核
线索保有期	AI 判断跟进质量；正常按原倒计时，疑似无效则加速；超时回收到销管池重新分配	AI 只提示并影响倒计时，不硬性阻断

确认与审批全景

域	确认链	触发	审批序列	状态
L2O	客户创建	新建 / 修改 / 作废客户	销管；销管本人提交免审	已定稿
L2O	商机创建	新建商机	销售总监 → 售前总监 → 销管；驳回后重提直达销管	已定稿
L2O	报价	提交报价	按业务场景配置，各场景负责人分别审批	待补充
L2O	商机赢单	提交赢单	销管审核凭证：盖章合同/PO、中标通知书、双方邮箱确认邮件三选一	已定稿
L2O	商机输单 / 无效	提交输单	销管审核原因与详情，原因分六类	已定稿
L2O	赢单后修改	赢单后修改商机	销管	已定稿
L2O	订单，含业绩归属拆分	赢单生成订单	产品线负责人 → 销管 → 财务 → 销管负责人	已定稿
交付归属	交付归属确认	赢单	交付事业部 Leader → PMO/PM → 财务	待定义
PMO	项目确认	订单确认事件	PM 逐项确认；合同到位后 PMO 审 QCD	口径冲突
PMO	变更	范围 / 成本变更	PMO；成本类必须回血至报价审批	待定义
PMO	风险	风险上报	PMO 逐级	待定义
PMO	结项 / 终止暂停恢复	项目终态	PMO	待定义
财务	收入确认	上传验收凭证	凭证与合同节点比对 → 财务确认	部分具备
财务	回款认领	回款到账	AI 建议期次 → 财务勾选认领	待定义
采购	供应商验收	供应商交付	归属未定：项目侧或采购侧	归属未定

业绩归属拆分随订单审批一并生效，一步到位，不单独走流程。

统一形状

事件触发业务事件进入待确认状态

AI 起草预填整理事实、证据与建议

责任人逐级确认按序担责与裁决

生效并通知写入权威状态并留痕

要素	规则
驳回	回到提交人修改后重提；部分链定义跳级重提路径
超时	工作日 24 小时未审批触发提醒，并逐级升级
代理	审批人不在可转交同角色他人，转交必须留痕
版本	已生效不可原地修改，变更生成新版本；下游只读已生效版本
回血	下游变更影响上游口径时，反向触发上游变更后确认
留痕	状态变更与责任人操作写回工作台，形成事件账

设计原则：由确认反推采集。

先定义每个环节必须回答的问题清单，全部确认才算通过；再反推支撑问题所需的字段。无对应确认项的字段不进表单。已有实例是赢单九问，PMO 立项卡按同一方法组织。

架构：两条回路

架构图 · 状态回路与认知回路

界面层Navi：高频、轻确认与校准、行动导向。业务系统：低频、批量与配置、表单导向。

业务 Workflow人强参与、确定性状态机、可审计可回滚。业务动作对调用者中立：校验 → 归一 → 权限 → 事务提交 → 事件。

域数据L2O、PMO、财务、采购、法务的权威账本、状态机、事件表与配置版本。

EntVerse 世界模型对象身份与关系、事实汇聚与采信、权限投影、经营记忆、方法论托管。界面中的判断、诊断与建议来自此层。

Agentic Workflow目标驱动、动态规划、只产回执。EnlightAI 承担研究、分析、材料生产与跨系统执行。

确认与审批：两个界面都指向业务 Workflow。
发起长任务：界面层发起 Agentic Workflow。
上下文与权限边界：EntVerse 编译后提供给 Agentic Workflow。
材料、证据与回执：Agentic Workflow 回流 EntVerse。
判断、诊断、建议与待办：EntVerse 返回界面层。
事实明细查询：界面层与域数据双向读取；域数据向 EntVerse 提供事实与事件。

三条链路

链路	路径	职能
状态写面	界面层 → 业务 Workflow	确认与审批经统一动作写入域权威账本；这是改变经营状态的唯一路径
事实读面	界面层 ⇄ 域数据	按权限返回事实明细，不经业务动作，但受同一权限约束
认知回路	界面层 → EntVerse → Agentic Workflow → EntVerse → 界面层	编译上下文与权限，执行长任务，回流材料、证据、回执、判断与建议

原稿的两类 Workflow 对比

T79 后续收口：此表保留 Artifact 的“业务 Workflow / Agentic Workflow”执行轨口径。T79 的正式分类是按状态权威划分的 Workflow A / B / C；跨域确认链主要是 B，Agent 长任务是 C，域权威系统内生流程是 A。

维度	业务 Workflow · 人强参与	Agentic Workflow · Agent 执行
触发	业务事件与状态变更	界面发起、定时、信号触发
路径	确定性状态机，节点与顺序预先定义	按目标动态规划，路径由 Agent 推导
执行主体	人为主，AI 起草与预填	Agent 为主，关键节点由人审核
产出	经营状态改变	材料、证据、执行回执
权威	域业务系统持有状态权威	不持有状态权威，产出须经采信
失败处理	驳回、超时升级、变更重走并回血上游	重试、降级、转人工
审计	逐节点留痕、版本化、可回滚	执行轨迹与证据链
承载	域业务系统	EnlightAI

原稿结论：两类不可相互替代。Agentic 结论进入界面成为建议，最终仍由业务 Workflow 完成状态改变。

业务动作契约与四类后端

统一动作契约：动作名、入参、校验规则、权限要求、状态迁移、事件。契约跨后端保持一致。

自建域库

L2O、PMO；权威在内。

自研系统

报价、合同、采购；权威在内。

外部系统适配

财务、法务归档；权威在外，终态写回。

人工任务

用印、投标；没有系统，回执留痕。

后端形态由域包的数据源适配声明。更换后端只改适配器，动作契约、界面与判断层不动。

各域当前与目标后端

域	当前	目标	变化边界
L2O	现有 CRM 只读镜像，外部	自建域库，内部	更换适配器并迁移数据；动作契约与界面不变
PMO	无系统	自建域库，内部	新增域包，内核零改动
报价 · 合同 · 采购	自研系统，内部	保持	—
财务	金蝶 + 台账，外部	保持外部	确认动作在链上，终态与外部对齐
法务归档	金蝶归档，外部	保持外部	归档号与云盘路径写回
用印 · 投标	既有用印流程	保持	按人工任务型动作接入，回执留痕

自建的判断依据：该域是否需要承载确认与审批动作，而不是是否需要一套界面。

三类扩展

扩展	需要改变	保持不变
更换后端	适配器 + 数据迁移	动作契约、界面、Agent、判断层、权限规则
新增动作	域包流程与动作声明	内核、其他域、已有动作
新增域	域包七件套声明 + 数据源适配	内核代码零改动

四个组件回答什么问题

组件	回答的问题
Navi	现在发生了什么、该做什么、谁负责、风险在哪、需要我决定什么
EnlightAI	事情如何由人与 Agent 完成、产出了什么、是否经过审核、执行证据是什么
EntVerse	对象是谁、关系是什么、哪些事实可信、谁有权改变状态
域业务系统	本域什么算合法状态、谁能让状态生效、需要什么证据

两个人类界面的分工

分工按动作性质划分，不按角色划分。

对象页四段来源：前三段来自认知回路，末段“事实与依据”来自事实读面。

维度	Navi	业务系统
使用场景	随经营节奏，随时随地	集中处理与配置
典型动作	查看差距与建议、单笔确认与驳回、轻度审批与校准、补材料、语音录入、催办	批量核对与调整、多字段录入、审批链与规则配置、权限与角色管理、台账核对
信息形态	结论优先：所处环节 → 差距 → 行动建议 → 依据	表单与列表优先：完整字段、逐行核对
业绩归属确认	逐笔确认或驳回，附 AI 预填与偏差提示	整批比对、调整比例后提交
角色覆盖	全部角色都可使用两个界面。销管、财务、PMO 的日常确认同样在 Navi 完成；销售与 PM 做批量与配置时进入业务系统。
共同约束	调用同一组业务动作；同一事实只确认一次；统一身份与权限。

职责矩阵

● 拥有　○ 消费　— 明确不承担

职责	EntVerse	Navi	EnlightAI	域业务系统
对象身份	● 统一身份与关系契约	○ 按身份取数呈现	○ 按身份取上下文	○ 权威 ID 锚在本域
业务事实	— 不建第二份事实	— 不存事实	— 只存执行证据	● 权威账本
确认与审批	○ 采信结果、守权限	○ 主确认界面	— 只提议不生效	● 状态机与生效权威
语义与记忆	● 公司大脑	○ 捕获与呈现	○ 生成与加工	— 不存整段语义
执行与证据	○ 采信回执	○ 发起与查看	● 计划编译与执行回执	○ 接收写回
方法论	● 托管与分发	○ 呈现结论与依据	● 按方法论执行	● 本域方法论提供方

方法论分公司级与个人级两层，公司级优先。

原稿的路由规则

路由	判据	承载	规则
A · 人强参与	需要担责的状态改变	业务 Workflow	确定性状态机，必须落业务系统；两个界面都可确认；AI 只起草
B · 就地完成	分钟级、当前对象内、人在场、低风险	业务 Workflow	Navi 自闭环；确认后写入域数据。原稿写“可升级为 C”
C · Agent 执行	小时到天级、跨对象跨系统、需回执与审计	Agentic Workflow	界面发起，EntVerse 编译上下文与权限后交 EnlightAI；材料与回执回流，判断下发界面

T79 修订理解：B 中的前置执行任务可以交给 C；C 的回执必须返回 B，由责任人完成确认。A 不可被 C 取代。

四条硬边界

回执不等于状态改变

Agent 完成任务只产生执行回执；满足证据与权限条件后，由业务系统提交状态变化。

同一事实只确认一次

全链路只有一个确认入口。缺业务系统的域仍需建设本域系统；受约束的是重复入口，不是系统数量。

不制造第二份事实

各域权威系统维护自己的行事实；不得为展示方便在其他层复制可写副本。

项目不等于计划

一个项目可关联多个执行计划；计划完成不等于项目完成，产出不等于客户验收。

底座：内核与域包

内核 · 业务无关

身份解析、注册表解释、事件调度、确认流转、权限判定。内核代码不出现任何业务名词。

域包 · 声明式

接入新域是安装域包，不是新建一套平台。验收判据是内核零代码改动。

域包七件套

对象身份锚、生命周期、权限档位；人、组织、角色同为注册对象

关系对象关系与人-对象干系；建立白名单与级联规则

流程与动作触发、审批序列、驳回与超时、粒度、跨域回血

视图角色镜头、对象页结构、看板指标与诊断规则

数据源适配权威在内或在外；同步、码值翻译、外部终态写回

AI 与方法论绑定AI 起草节点与本域方法论挂载点

证据与指标关口通过证据与本域结果指标

承载强度三档

三档共用同一组原语，但不共用同一种产品刚性。

强度	实例	形态
强事实流程	L2C 全域	结构化行事实 + 强审批 + 强验收，可对账、审计、回滚
经营登记册	客户与商机经营	结构化登记册 + 工作台；事实可从会话与文档进入，最终落登记册
轻应用	高敏感探索型关系经营	文档原生、AI 维护、总表是视图；权限先行，敏感原文不进公司事实

现状与缺口

域	权威系统	库中事实	缺口
L2O	自建，替代现有 CRM；过渡期 CRM 只读镜像	客户、联系人、线索、商机、拜访、订单与明细	七条审批链需落地；归属拆分无审批无留痕；线索池与保有期无承载
报价	道一云，八月底改表单化	报价审批单、成本项、毛利	审批链待财务补充；多版本与补充件缺“以哪版为准”的确认
法务	道一云 + 金蝶归档；自研系统在建	合同、归档号、付款条款、验收节点	合同评审无预检；积压无时效度量；抽取结果无人确认就被下游消费
采购	自研采购系统已上线 + 金蝶	采购单 899、成本付款 3,970	供应商验收归属未定；阶段性验收节点未打通至订单
PMO	无系统	项目、材料、周反馈、验收节点、收入跟踪	立项、变更、风险、结项无流程；关键字段覆盖率低；无工时
财务	金蝶 + 台账 + Navi 确认入口	收入确认、收入预测、回款、开票、成本、考核目标 226	回款期次与验收勾稽依靠月度人工；毛利额目标全部为空

已在生产的确认入口

PM 执行收入反馈、项目材料归档、验收日期反馈、风险与行动反馈、收入预测确认。五个入口由 Navi 承担，写入 RevenueOS 行事实并留痕。方案要求把它们收敛为统一动作层，在既有能力上扩展，不引入独立工作流引擎。

建设方式

方式	域	说明
自建替代	L2O	自建 CRM 承载线索至订单全流程与七条审批链；过渡期现有 CRM 保持只读镜像，新旧并行至新流程验证可用
自建新增	PMO	从零建设立项、变更、风险、结项四类流程与项目台账
自研在建	报价 · 合同 · 采购	由同一自研系统承载；采购已上线，报价与合同在建
外部接入	财务	总账、发票、支付履约保留在既有系统；确认动作在链上完成，终态与外部对齐

系统对接契约

下行

订单与商机数据下发至业务系统，触发相应审批流。

上行

审批状态、责任人操作与结果写回工作台，形成事件账与待办。

对接点	约定
金蝶	发起采购申请时按销售订单拉取；合同完成后，应收应付、供应商发票与支付履约对齐形成闭环
采购台账	写回粒度到订单级，含供应商、已付金额、阶段性验收节点；不是汇总看板
合同	合同读出验收节点供 PMO 与财务消费；新增 AI 预检，不合格在提交前驳回，减少法务积压
盖章与投标	投标文件盖章走既有用印流程，不并入本链
过渡	新系统上线后旧 OA 并行运行，直至新流程验证可用

待决事项

事项	分歧	影响	决策人
项目起点	销售侧：订单直接生成项目、PM 确认；交付侧：合同后立项、完整审批。现实中多数项目先开工，合同滞后一到两个月	决定 PMO 需求写法	旭日 · 淼梅 · PMO
报价审批人	现由财务执行并将并入自研系统；交付侧主张审批人应为对报价负责的销售、销管与事业部负责人	阻塞报价审批链定稿	财务 · 销管 · 采购
供应商验收归属	项目侧或采购侧；存在非项目产品集采，不能一律归项目	影响采购与 PMO 边界	PMO · 采购
成本变更路径	项目侧发起，还是重走报价审批；重走影响销售提成，项目侧发起需回血上游	影响毛利口径一致性	淼梅 · PMO · 财务
PMO 范围与批次	复杂度高于 CRM 重做，09-30 全量有风险；建议立项、变更、风险三条先行	决定交付节奏	旭日
业务场景口径	业务线更名为业务场景，报价表单与审批链随之重设	阻塞报价表单设计	销管
组织架构源	自研系统取企业微信组织，业务侧变动以人事系统为准；两套组织不一致会导致审批人错配	影响全部审批链	人事 · 销管 · 研发

分工与节奏

时间	动作
本周	本稿边界拍板；PMO 与公司级 PMO 负责人对审批流，周五与外部专家复核；订单到收入台账继续对齐
本周内	财务与法务补齐报价、合同业务信息表，交自研系统出设计稿
下周初	拉齐自研合同报价采购系统 × L2C × PMO 的订单上下游边界，约定权威与互传数据；确认方案后开发
下周三	PMO 输出需求：确认什么、每条审批链的流转动作与状态、异常处理
下周内	技术评估与工作分解；报工接口先行，在既有 PM 反馈通道新增报工，未确认状态落库、Navi 读出确认
八月底	报价与合同审批流随表单化调整；业务场景口径全局对齐
09-30	各系统数据结构化串通；不要求实时全准，过渡期新旧流程并行；实际交付节点建议按 09-18 组织

角色职责

职责	负责人
L2C 业务口径	淼梅，总产品经理
交付域口径	PMO 负责人
技术评估与实现	泽斌 · 研发
合同报价采购系统	自研系统负责人
方向与终裁	旭日