# 宁泉经营驾驶舱 · 重构版系统架构方案 V1 版本日期：2026-05-28 ## 一、系统定位 宁泉经营驾驶舱不是普通 BI 大屏，而是面向经营管理决策的数字化系统。 系统定位： 经营决策系统 + 车辆资产经营中台 + 租赁关系数据中台 + Hermes 智能运营中枢 核心目标： - 让管理层先看到经营结果，而不是先看到模块。 - 让异常能下钻到车辆、租车人、合同、回款、维修、保险和责任人。 - 让 Hermes 只做解释、建议、知识管理和督办，不绕过规则和人工审批。 ## 二、总—分—明细信息架构 ### 总 经营总览只回答四个问题： - 今天赚不赚钱。 - 现金有没有风险。 - 哪些车正在拖累经营。 - 哪些事项必须管理层决策。 ### 分 经营总览承接原型六大经营模块： - 车辆实时状态分布。 - 收入与欠租回款追踪。 - 单车利润模型 UE。 - 维修停运与资产损耗。 - 租车人群体风控雷达。 - 经营异常与决策待办。 ### 明细 明细层不再是“大屏模块”，而是经营追责入口： - 单车经营档案。 - 租赁关系档案。 - 租车人风险档案。 - 收款与欠租记录。 - 维修、保险、违章、事故记录。 - 审批与督办记录。 ### 闭环 经营异常与决策待办、决策审批和 Hermes Agent 形成闭环： - 规则识别异常。 - Hermes 在经营异常与决策待办中解释原因、证据和金额影响。 - 管理层确认动作。 - 系统追踪负责人、截止时间、结果回写。 ## 三、经营主线 系统必须围绕车辆资产生命周期，而不是围绕单个租车人。 正确主线： 车辆资产 -> 租赁记录 -> 租车人 -> 收款/欠租/押金 -> 维修/违章/保险/事故 -> 单车利润 -> 风险判断 -> 经营待办 -> 执行闭环 错误主线： 车辆与租车人强绑定 正确模型： 车辆资产 <-> 租赁记录 <-> 租车人 ## 四、数据中台层级 ### 1. 数据采集层 来源： - 车辆系统。 - 滴滴平台系统。 - 交管违章系统。 - 财务报表。 - 押金租金流程。 - 维修流程。 - 保险资料。 - 客服话术和制度文档。 方式： - Excel/CSV 静态导入。 - 后台截图和人工补录。 - 企业微信 API 暂定由 Hermes 采集适配器接入，先覆盖外部联系人会话、车辆群消息、附件和回执证据。 - 后期 API 接入。 企业微信采集入口先按三类场景设计： - 机器人添加到个人微信后形成外部联系人会话，采集租车人咨询、催收沟通、投诉和续租意向。 - 机器人拉入车辆群后形成车辆群事件流，采集报修、事故、违章、续保、退车和任务回执。 - 企业微信后台消息、附件、图片和处理结果进入证据库，供 Hermes 归类、摘要和生成业务口径候选。 企业微信采集只作为“信息进入系统”的方式，不直接改变经营总览版块结构。 ### 2. 数据标准化层 统一规则： - 车牌统一。 - 租车人身份统一。 - 日期统一。 - 金额统一。 - 状态统一。 - 风险标签统一。 - 来源证据统一。 ### 3. 标准底表层 一期标准底表： - 车辆资产表。 - 租车人表。 - 租赁记录表。 - 收款流水表。 - 维修事件表。 - 保险违章表。 - 风险事件表。 ### 4. 经营宽表层 核心宽表： `vehicle_operation_summary` 前端页面不直接读取多个原始表，统一读取经营宽表和规则命中记录。 ### 5. 指标与规则层 指标： - 车辆状态。 - 应收/实收/欠租。 - 单车利润 UE。 - 维修停运损失。 - 保险脱保预警。 - 租车人风险评分。 - 经营待办。 规则： - 欠租超过 15 天进入经营待办。 - 保险 3 天内到期进入经营待办。 - 维修金额超过 10000 进入管理层审批。 - 维修停运超过 7 天进入停运预警。 - 合同即将到期且无欠租无事故进入续租推荐。 - 事故车维修成本过高进入残值处置建议。 ## 五、Hermes 优先与企业微信 API 采集分工 当前阶段先主要部署 Hermes，先跑通智能分析、规则记忆、日报生成、业务口径治理和企业微信 API 信息采集。企业微信不直接驱动前端大屏，而是先进入数据中台、证据库和 Hermes 口径/规则队列。 ### Hermes 定位：智能分析、规则记忆和业务口径治理层。 负责： - 记住客户指标口径和规则变更。 - 记住管理层关注规则，例如欠租、断保、维修停运、事故处置和续租机会。 - 通过企业微信 API 采集外部联系人会话、车辆群消息、附件、图片和处理回执。 - 将企业微信消息按车辆、租车人、风险类型和流程节点归类。 - 把规则命中解释为经营结论、金额影响、建议动作、责任岗位和截止时间。 - 生成经营日报、周报、月报。 - 在 Hermes 内部治理客服话术、合同条款、押金规则、维修流程、保险事故和财务平账口径。 - 将审批结果沉淀为后续日报和管理层偏好。 不负责： - 不直接登录后台。 - 不直接修改原始业务数据。 - 不替管理层审批。 - 不在未确认前自动对外回复或替员工承诺处理结果。 ### Hermes 企业微信 API 采集适配器 定位：企业微信信息入口与证据采集层，服务 Hermes 分析和数据中台，不负责经营判断本身。 负责： - 同步企业微信通讯录、外部联系人、客户群和车辆群关系。 - 接收消息回调或 API 拉取结果，形成标准消息事件。 - 采集同意、驳回、转交、已处理等企业微信回执。 - 留存图片、附件、截图和处理证明。 - 将客服会话高频问题转为 Hermes 业务口径候选条目。 - 将报修、事故、欠租、续租、投诉等消息转为风险事件候选。 当前边界： - 暂定只做采集、归类、摘要和证据留存。 - 不自动发送企业微信消息。 - 不自动接管客服会话。 - 不绕过数据中台和规则引擎直接生成经营待办。 ### LLM 定位：语言生成与表达能力，可作为 Hermes 的表达能力组件。 负责： - 对异常指标做自然语言解释。 - 生成经营日报、周报、月报。 - 生成审批建议文案。 - 回答制度、押金、维修、平账等业务口径问题。 不直接改原始数据。 ## 六、商务化命名 | 原模块名 | 系统命名 | 业务含义 | | --- | --- | --- | | 传统总览 | 经营总览 | 管理层先看经营结论和关键决策事项 | | 数据底表 | 数据中台 | 统一底表、宽表、规则和质量口径 | | 车辆模块 | 车辆档案 | 查询单车资产、租赁关系和风险明细 | | 收入模块 | 收入与欠租回款追踪 | 看应收、实收、欠租和回款率 | | 利润模块 | 单车利润模型 UE | 看单车收入如何流向成本和净利 | | 维修模块 | 维修停运与资产损耗 | 看停运、维修、资产损耗 | | 租车人模块 | 租车人群体风控雷达 | 看欠租、事故、投诉、黑名单 | | 待办模块 | 经营异常与决策待办 | 管理层仅处理必须决策事项 | | AI 能力 | 经营异常与决策待办内置 Hermes Agent | 经营分析、业务口径治理、规则记忆、日报督办 | ## 七、页面结构 主导航只保留三个一级入口： 1. 经营总览：经营结论、六大模块、现金风险、资产风险和决策待办。 2. 数据中台：底表、宽表、字段映射、数据质量。 3. 车辆档案：车辆、租赁关系、回款、维修、保险、风险。 决策审批从经营总览的异常事项进入，Hermes Agent 并入“经营异常与决策待办”，不再作为独立页面。辅助文档和隐藏页面承接实施路线，不占用主导航。 ## 八、UI 风格规范 整体风格定位为企业级深色 SaaS 经营系统，而不是传统 BI 大屏或营销页。 界面原则： - 背景使用深色纯色底，避免传统大屏蓝色发光和复杂科技线条。 - 面板使用低透明玻璃质感和弱边框，减少强描边、强外发光和重复边框。 - 顶部导航保持轻量化，只保留管理层高频入口。 - 经营总览先呈现经营结论，再展示可下钻的经营模块。 - 图表必须服务经营问题：趋势看现金，桑基看利润流向，排行看损失，雷达看风险越线。 - 管理层页面减少说明文字，明细和规则进入二级页面承接。 - 颜色只表达状态和风险：蓝色为主操作，绿色为正向，橙色为预警，红色为高风险，灰色为中性。 - 核心数字大字号展示，说明文字降权，避免密集文本压过经营结论。 - 所有卡片、表格、按钮、状态标签统一使用 8-16px 圆角，避免过度装饰。 ## 九、一期到四期实施路线 ### 一期：先把经营看清楚 目标：先把经营看清楚，再谈 AI 自动化。先建立车辆经营状态总表、风险总表与老板日报，确认老板办公室未来看到的是经营驾驶舱，不是普通报表。 输出： - 静态页面。 - 架构文档。 - 数据映射。 - 规则样例。 - 智能体配置样例。 - 车辆经营状态总表：在租、闲置、维修、待退、欠租、保险、违章、风险等级。 - 风险总表：车辆风险、司机风险、资金风险、流程风险。 - 老板日报：今日异常、待处理事项、影响金额、责任人、处理状态。 ### 二期：数据中台样板 目标：用真实 Excel 跑通标准底表和经营宽表。 输出： - 原始资料目录。 - 字段映射表。 - 7 张标准底表。 - `vehicle_operation_summary`。 - 数据质量检查。 ### 三期：Hermes 智能运营中枢 目标：先把 Hermes 的经营分析、规则记忆、业务口径治理、企业微信采集适配和日报督办跑通。 输出： - 规则命中记录。 - 管理层日报。 - 客服与制度业务口径。 - 指标口径和规则记忆。 - 审批督办闭环。 - 企业微信消息事件样本与技术难度评估。 ### 技术难度评估 - 静态原型和三张核心底表：低难度，可用现有 Excel、截图和人工样本先跑通。 - 企业微信外部联系人会话：中等难度，取决于客户联系权限、会话内容存档、客户同意和身份映射。 - 企业微信车辆群消息：中高难度，取决于客户群 API 可见范围、群名/车牌映射、附件下载和消息噪声过滤。 - AI 自动预警：不建议第一步做，必须等三张核心底表和风险规则稳定后再接 API，否则会变成“消息很多但结论不可靠”。 ### 四期：Hermes 企业微信 API 与接口化经营系统 目标：在 Hermes 口径稳定后，接入企业微信 API、车辆/财务/违章等系统 API，形成准实时经营系统。后台自动化只作为 API 缺失时的补充方案。 输出： - 企业微信通讯录、外部联系人、车辆群消息和处理回执。 - API 接口清单。 - 自动更新宽表。 - 实时预警。 - 办公室经营大屏。 - 多角色权限与设置。 ## 十、一期验收标准 一期不是验收“页面好看”，而是验收经营逻辑是否闭环： - 管理层能从总览看到今天最重要的经营结论。 - 每个结论都能下钻到六大模块内明细表、车辆档案或租赁关系。 - 每个待办都有金额影响、建议动作、负责人和截止时间。 - 数据中台能说明每个指标从哪来，但不承担集中明细查询。 - Hermes Agent 在经营异常与决策待办中解释异常、治理业务口径和生成日报，但不替管理层审批。 - 实施路线能清楚区分静态原型、数据中台、半自动、接口化四个阶段。