Shadow Operating Layer
老板放进组织里的 AI 影子。它深入会议、群聊、私域、销售、客服、项目和经营数据，持续观察客户资产是否被有效经营。
Shadow 识别 LTV 增长机会和组织执行断点，并每天以老板能看懂的方式汇报。
Boss Operating Layer
Shadow Operating Layer 先定义要改变的经营状态，再决定需要什么界面。
老板最怕的不是没有数据，而是数据、会议、群聊和客户反馈互相割裂。Shadow 先把老板真正关心的问题固定下来：客户资产有没有被经营、机会有没有转成结果、风险有没有提前暴露、责任人有没有闭环。
老板每日简报
每天输出客户资产变化、关键风险、增长机会、未闭环责任和老板追问建议，适合在车上、会前、饭局前快速阅读。
客户资产雷达
追踪高价值客户、沉睡客户、投诉客户、复购信号、转介绍机会和服务到期节点，避免老客户长期无人经营。
会议影子
旁听或整理关键会议，把结论、责任人、截止时间、风险和老板该追问的问题整理成行动卡。
组织执行断点
识别只报动作不报结果、客服未闭环、销售未跟进、项目无负责人、跨部门交接丢失等执行问题。
Shadow Ontology
把企业经营变成 AI 能理解、能执行、能审计的对象系统。
Shadow 借鉴 ontology 的思想，但服务的是老板经营现场：客户不是一行 CRM 数据，会议不是一段纪要，账号不是一个登录入口。它们都要拥有状态、关系、权限、下一步动作和复盘记录。
经营对象
客户、会话、订单、报告、会议、负责人、费用、风险与机会进入统一对象层，不再只是一堆资料。
业务规则
LTV 分层、复购窗口、投诉升级、报价边界、隐私权限和人工确认点被写成可执行规则。
执行动作
小B AI 员工生成追问、工单、话术、会议纪要、复购提醒和老板简报，并留下状态。
治理边界
脱敏、角色权限、审批、日志、成本和离职回收从第一天进入系统，而不是上线后补救。
把老板每天要追的事，压缩成一个可操作的 Command Center。
界面不只是展示数据，而是持续回答三个问题：什么对象发生了变化，谁应该行动，下一步有没有闭环。Shadow 的产品感来自经营动作，而不是好看的图表。
今日经营状态
高价值客户 286 人进入本周重点经营池
体检后服务、口腔复诊、会员续费信号上升
会议事项、客服投诉、销售跟进仍有未闭环
API、订阅、自动化任务进入月度成本视图
今天发生了什么
A Day With Shadow
Shadow 不是报表页面，而是跟着企业一天一起运行。
晨间简报
老板打开 Shadow，先看到昨日客户资产变化、异常投诉、未闭环会议事项和今日最值得追问的 5 件事。
业务会前
系统把参会客户、历史沟通、上次责任人、风险记录和建议追问整理成会前作战卡。
一线执行
销售、客服、社群 Agent 根据客户阶段生成话术、工单和唤醒动作，关键承诺必须人工确认。
异常升级
报告解释超时、客户投诉、费用异常、Agent 审核不过等事项进入 C-AI-O 和负责人视图。
复盘沉淀
当天失败样例进入知识库更新队列，老板看到哪些动作有效、哪些流程仍然断裂。
先确认老板需要的是经营判断，而不是另一张数据大屏。
老板已经发现客户资产、会议执行或团队汇报存在失真，希望有一个系统持续观察真实经营现场。
企业没有任何客户数据、会议记录、销售跟进或业务流程沉淀，只想买一个聊天机器人。
今天哪些客户机会正在被浪费，哪个负责人没有闭环，哪场会议需要追问，哪个老客户值得重点经营。
Operating Sequence
从观察到追问，Shadow 如何参与老板的一天。
每一步都会留下状态、证据和责任人。系统可以建议，也可以在授权范围内行动，但不能越过人类裁决权。
感知
读取被授权的客户、会议与执行信号，保留来源与时间。
判断
用对象关系区分普通波动、增长机会与需要升级的经营风险。
追问
把复杂信号改写成老板可以直接问责任人的问题。
闭环
记录负责人回应、后续动作和结果，让下一次判断带着历史。
Deliverables
交付的不是一张驾驶舱，而是一套老板能持续使用的经营仪表。
Shadow 观察对象清单
定义客户、客户群、订单、负责人、会话、会议、风险、机会等对象。
老板简报模板
日报、周报、会前简报、追问卡和责任人卡。
LTV 指标口径
复购、唤醒、加购、续费、转介绍、投诉挽回等指标定义。
执行追踪机制
谁负责、何时反馈、如何验收、什么情况升级给老板。
Operating Metrics
老板看见的不是更多数据，而是更短的决策延迟。
Shadow 的判断质量，取决于上下文、岗位执行和基础设施是否可靠。
企业 AI 施工通常先从一个模块切入，再逐步连接上下文、AI 员工、老板简报和运维治理。
