BPOS-MVP/docs/产品设计.md

产品设计 · 三面一体

2026-07-27 定稿。本文档回答一个问题:这个产品由哪几张脸组成,每张脸对谁、说什么。 背景:治理中心此前是平铺的九个区,设计态与运行态混在一排 —— 定义企业的人和看企业跑的人 挤在同一套导航里,谁都找不到自己的第一屏。本次拆分把它按心智一分为二,与工作台合成三面。

---

一、概念模型:三面一体

产品按一条因果链排成三面:

设计中心 ──定义──▶ 运营中心 ──派发──▶ 工作台
(企业怎么运转)    (今天跑得怎样)     (在企业里干活)
   类 · 规则         实例 · 监控        人 · 劳动

• 设计产生运营的形状:设计侧每发布一个数据域,运营侧自动长出一个台账位; 每发布一个流程包,运营侧的驾驶舱就多一类可监控的流。
• 运营产生工作台的内容:流程跑起来,任务、审批、消息才落到人的工位上。
• 工作台产生驾驶舱的数字:人把活干完,八指标才有读数 —— 圈闭合。

面	地址	网页标签	一句话	谁用
设计中心	/design	深靛底 + 路网章	定义企业:战略 → 方法 → 能力 → 对象	业务架构师 / 管理者
运营中心	/ops	深色底 + 仪表章	看企业跑:驾驶舱 + 处置 + 沉淀	PM / 当班主管
工作台	/	蓝渐变 + 机器人章	干活:任务五要素	全员

• /gov 保留为跳转(302 → /ops),旧链接不断。
• 三面共用一套登录会话(ADR-010);顶栏互跳,入口按权限亮灯(见第六节)。
• 网页标签三章并立:多标签并开时,靠图标即可分辨"我在定义、在监控、还是在干活"。

二、设计中心 /design

左轨 = 企业蓝图(首页)+ 四库。

企业蓝图(首页)

一屏把四库串成因果链,回答"这家企业被定义成什么样、哪里还没定义完":

战略 ────── 方法 ────── 能力 ────── 对象
流程包  →   活动库  →   工具箱  →   数据域
 ↓健康度     ↓健康度     ↓健康度     ↓健康度
未闭合草稿   未安装引用   未授权工具   未发布域

• 每库一张卡:总数、健康度、最近变更;点卡即入库。
• 下方是待补清单:闭合校验未过、编排引用了未安装的活动、没有任何调起规则的流程包 —— 全部聚在这里,点进即改。设计者的"需处置"不散落在四库里 (为此流程包区原有的「需处置」页签已删除:同一件事两处显示,就是散落)。

四库

库	定位	内容
流程包	战略 —— 企业以哪些流转运转	现工作流区整体迁入:编排工作区(画布 + 属性卡)、边映射校验、版本谱系、导出依赖文件。触发器的定义并入本库:包详情"调起它的触发器"从只读变可编辑(规则 / 输入装配 / 目标版本),另设「调起规则」页签横览全部触发器。触发器不再是独立一区
活动库	方法 —— 每件事怎么干	现活动库区平移:货架、契约面、范式、资产版本谱系、安装两审
工具箱	能力 —— 系统能对世界做什么	现工具区平移:读/写目录、白名单授权、幂等口径、引用反查
数据域	对象 —— 企业运营什么	现数据区的定义面:域与对象 schema、字段、放行规则、被谁引用。行数据不在这里 —— 那是运营的事

一条纪律

设计中心里没有任何运行态数字(在跑几单、30 天起单数、死信数都不出现)。 设计者看的是定义完不完整,不是今天忙不忙 —— 运行态数字一旦混进来, 设计页面就会退化成第二个监控页。

三、运营中心 /ops

左轨 = 驾驶舱(首页)+ 固定位 + 动态位 + 固定位。

◉ 驾驶舱(首页)
── 固定 ──
任务
员工
── 台账(动态,随数据域长) ──
quote_intake
quote_pricing
…
shared
── 固定 ──
知识库
系统

落地实测:域的实际粒度是活动域(quote_intake / quote_pricing / quote_sourcing / quote_negotiate / quote_alternative)+ shared,不是本文起初设想的「报价域 / 共享域」。 决策不变(域 = 导航项),只是数量比示意图多。域名是复合键,左轨按下划线断行呈现。

驾驶舱(首页)

经营第一屏,从现"记忆 · 度量仪表"升格而来:

• 度量八指标(OS 8.3,零埋点):自主率 / 纠正率 / 有效自主率 / 打扰率 / 断点率 / DMN 覆盖率 / 单位成本 / 终态分布 —— 走 report 模块,与工作台汇报同源同口径;
• 异常面:异常工作流、未闭合草稿、在途任务 —— 点数字直达处置页。

落地偏差:死信卡不做。死信目前只以治理者消息要素送出,没有按 kind 计数的查询面 —— 与其摆一个查不出数的卡位,不如记进 docs/debt.md 等查询面补上再加。

固定位

位	内容
任务	现任务管理区平移:运行看板 / 任务 / 审批单 / 需处置。触发器的处置并入:启停开关、近 30 天起单、死信重投 —— 定义在设计中心,开关在这里
员工	现员工区平移(员工 / 岗位授权),补上工作组管理(ADR-011 欠账:建组 / 改组 —— 起单时的岗位绑定)
知识库	活动记忆四层 + 技能资产 + 候选增量的回放与放行。"记忆的终点是成为模型"这条进化管线的人工放行口在这里
系统	LLM 实例 / 通道实例,现系统区平移

动态位:台账 ×N

按数据域动态生成导航项 —— 设计侧一发布新域,运营侧自动长出一位。 点进去是该域全部对象的行数据、版本历史、被哪些任务引用。 域的 schema 不在这里改(那是设计的事);这里做的是运营动作:查行、看版本、追引用。

这是"设计产生运营的形状"最直观的一处:导航本身就是被设计出来的。 数据来源:ledger.listObjects(已有),无需新后端能力。

四、与工作台的联动

• 三面互跳:每面顶栏(或轨底)有另两面的入口,按权限亮灯。跳转带上下文: 运营中心看某任务 → "去工作台处理"直达该单;工作台任务详情 → 有运营权者见"去运营中心看这条流"。
• 同一语言:工作台里人看到的任务、审批、台账字段,与运营中心管理的是同一份投影、同一套词。 运营中心是工作台的管理者视角,不是另一套系统 —— 字段名、状态名、终态五名逐字一致。
• 闭环叙事:设计中心发布流程包 → 运营中心看它跑、放行知识沉淀 → 工作台的人把活干完 → 数字回到驾驶舱。产品讲的就是这一个圈。

五、现状迁移映射

后端模块、授权模型、数据一概不动 —— 这是一次纯前端的信息架构重排:

现九区	去向
工作流	设计 · 流程包
活动库	设计 · 活动库
工具	设计 · 工具箱
数据(schema 面)	设计 · 数据域
数据(行数据面)	运营 · 台账 ×N
触发器(规则 / 装配定义)	设计 · 流程包 - 调起规则
触发器(启停 / 死信处置)	运营 · 任务 - 需处置
任务	运营 · 任务
员工	运营 · 员工(+ 工作组管理,新)
记忆(度量仪表)	运营 · 驾驶舱(首页)
记忆(活动记忆)	运营 · 知识库
系统	运营 · 系统

前端改动清单:

1. 壳层:gov-shell 一分为二(/design 与 /ops 各一套左轨与路由),/gov 302 → /ops;
2. 网页标签:tab-identity 从两章扩为三章;
3. 新页两张:企业蓝图(设计首页)、驾驶舱(运营首页)—— 数据全部来自既有接口的再聚合;
4. 新界面一处:工作组管理(员工位内;org.saveWorkGroup 已在出口,缺的只是界面);
5. 触发器编辑面:从独立区改为流程包区的「调起规则」页签(包详情内只留一枚「改规则」入口, 不重复摆表单);已补 PUT /api/gov/triggers(trigger.upsert 用例本就在模块出口,只缺 HTTP 面)。

六、权限

授权模型不动:仍是九治理功能 × 读/写/治三动作(客体三类中的 governance 类)。 变化只在归属与亮灯:

• 九功能按上表归属两面;
• 台面入口按"是否持有该面任一功能的读权"亮灯 —— 无权者看不见入口,有读权者进去只读, 动作仍逐功能校验(读是 read,动才是 govern);
• 不新增"设计权 / 运营权"这类粗粒度开关,不做两层叠加 —— 单组织 ≤50 人用不上, 且现有 grants 数据零迁移。

七、边界(本设计不做的)

• 不动后端:模块、契约、授权、数据库都保持原样;
• 不做对象级动态导航:台账动态位止于"域"粒度,对象在域内切换;
• 不做设计中心的运行态回显:哪怕"看起来有用"也不加 —— 纪律见第二节;
• 不做工作台的管理者混入:运营能力永远住运营中心,不往工作台塞管理页签。

八、落地顺序建议

1. 壳先行:两套左轨 + 三章标签 + /gov 跳转 + 权限亮灯(纯搬迁,一次可验);
2. 两张首页:驾驶舱(度量升格)→ 企业蓝图(四库健康度);
3. 归位改造:触发器定义并入流程包、台账动态位、数据域定义面瘦身;
4. 补欠账:工作组管理界面。

每步落完都可独立验收;顺序可按当期在做的活动开发穿插。

九、MVP 底座落地记(2026-07-28)

三面拆分之后铺的底座,与本文的关系:

• 数据按上表四域重划,十八对象由六个活动槽位的声明物化而来(不是手写建表);
• 流程包只落一个实例:unified-quote v1,拓扑与 docs/MVP示例工作流.html 的 FIG.1 一比一 (14 节点 / 16 边,手绘几何逐点取自那张 SVG)。与图有两处语义同构、呈现有别: A5 定价审批建为内置审批点(审批不是任务),故图上的 G3「审批结果」被它吸收; G2 的两条互斥分支显式汇合于 G2J —— 图上画成两条线各扎进 A4,那是隐式合并,闭合校验不收;
• 活动只落槽位契约:六个槽位有完整的入参/出口/域声明/工具名,业务模型是 MVP 步骤标题级的 人类工单骨架 —— 起单后是真人在做,不是假跑;实现待底座齐备后按 A1→A7 逐个开发;
• 工具箱三类并列:功能工具(交给系统)/ LLM 工具(交给模型)/ 人类工具(交给人), 外加接入段(自定义导入已实装,MCP 仅呈现)。

---

附 · 决策记录

决策	选择	理由
拆分形态	两个独立台面(+工作台成三面)	产品叙事最干净:定义 / 监控 / 干活是三种心智;权限天然分界
触发器归属	定义归设计(流程包内),处置归运营	同一对象两种动作各归其位;避免两边各放一份
度量归属	升为运营首页(驾驶舱)	"看企业今天跑得怎样"需要开屏答案;与活动记忆分开是两种心智
动态位形态	域 = 导航项,随发布长	"设计产生运营的形状"要在导航上直接可见;对象级太碎
权限粒度	保留九功能粒度,入口按读权亮灯	grants 零迁移,细粒度保住;≤50 人不需要两层模型
设计中心 IA	蓝图首页 + 四库平铺	因果链要有一屏能讲;四库直达的稳定导航同时保住
交互基调(2026-07-28)	设计台卡片式,运营台列表式	设计是「看清一件东西的全貌」——卡片一眼见轮廓;运营是「查一堆记录里的那一条」——列表可扫可比
数据四域(2026-07-28)	project / customer / intel / supplier	流转单据归项目(每一单的受理记录→比价→草案→报价单),沉淀资产按内容归客户/情报/供应商;按活动名分域会让「同一个客户」散在七处
活动与工具解耦(2026-07-28)	槽位只声明工具名	注册、连接值、白名单全在治理侧 —— 活动代码里看不到授权表,也就绕不开它