万金科技·AI技术官
万金科技·AI技术官
面向消防工程与技术服务公司的一套行业 SaaS ERP。本页依次解读它的产品功能（依据官方产品手册）、PC 端全部页面、功能结构图、与 EHR + CRM + ERP 的差距及陀螺匠底座方案，网关接口和技术框架放在最后。
官方定位是“国内首个深度融合 AI 能力的消防行业垂直 ERP”。手册反复强调一句话：一切业务围绕项目展开。项目是主线，任务是执行单元，合同挂在项目上，收付款挂在合同和项目上，采购和报销要关联项目归集成本。理解这条主线，其余模块就都是围绕它的支撑。
| 阶段 | 动作 | 涉及模块 | 手册要点 |
|---|---|---|---|
| 1 建档 | 新建业主单位 → 新建项目 → 关联合同 → 组建项目团队 | 单位管理 · 项目管理 · 项目合同 | 一个项目 1 份收入合同、多份支出合同；无合同需打开“无需关联”开关；支持批量导入单位 |
| 2 收款计划 | 按合同约定创建分期收款计划 | 项目合同 · 收款管理 | 到期前 7 天黄色预警，超期红色预警并持续提醒 |
| 3 派单执行 | 创建任务（维保/维修/检测/评估/物联安装）→ 指派 → 工程师微信公众号接单 | 任务管理 · 设施维保 · 维修工单 | 移动端签到（GPS + 水印拍照）→ 填写记录 → 提交审核；维保发现隐患自动联动维修组 |
| 4 采购供应 | 采购申请 → 询价比价（供应商微信报价）→ 采购订单 → 入库 → 领料出库 | 采购管理 · 库存管理 | 零星采购走单独的轻流程，面向施工/维修现场临时采购；订单可自动生成付款申请 |
| 5 财务闭环 | 付款申请 / 费用报销 / 资金调拨 → 审批 → 支付 → 发票归集 | 财务管理 · 审批中心 | 所有财务单据先在“流程引擎”配好审批规则；发票支持拍照识别与验真 |
| 6 经营看板 | 经营看板 / 维保看板 | 数据统计 | 新增合同、应收/实收、未来回款账龄（30/60/90 天）、采购分析、待解决隐患 |
以下 35 个页面全部实际打开并截图核对过（截图已逐张发到对话里）。每个页面记录路由、页面结构、列表字段与主要按钮，这基本就是一份可以直接拿去做原型的清单。所有列表页共用一套模式：顶部统计卡 → 筛选条（重置/查询/展开）→ ProTable（导出 / 新增 / 刷新 / 密度 / 列设置）。
项目统计（项目/合同/任务三个页签，本月新增趋势条）、通知通告、工作动态（按动态类型/人员/日期筛选）、日程计划·待办（周视图）。右上角有 AI 助手入口。
统计卡：项目总数、类型占比环图、进行中、关联合同数、关联任务数。
头部：状态、关注星标、业主单位、类型、截止日。页签：概况 / 实施 / 成本 / 材料 / 收款 / 合同 / 资料 / 图纸。右栏：项目计划节点、项目统计（实施任务数、已收款金额、收款执行率）、项目成员。概况含项目动态时间线。
统计卡：综合任务总数、类型占比（设施维保/消防检测/安全评估）、进行中、未关联任务。
统计卡：签订总数、签订金额、未关联合同、收款未完成、失效合同。
左侧材料类型树（新增类型），右侧列表。
页签：全部记录 / 待采购。
标题带合计金额。
进项/销项切换；页签全部发票 / 我创建的。
左侧二级：付款申请 / 待付单据 / 已付单据。
左侧二级：账户管理 / 资金到账 / 余额调整 / 资金调拨。账户以卡片展示（汇总账户 → 交易明细）。
经营看板：经营总览（新增/续签合同、新增客户/项目、应收/实收）、业务管理（待解决隐患、已做未结工单、维保/检测/评估/物联服务到期）、财务分析（收入类型环图、未来回款账龄）、采购分析。另有维保看板。
左侧图纸列表；中间四步向导：上传 DWG/DWF → 选择识别类型 → 框选区域 → 导出材料清单/采购单；右侧识别结果（总设备、识别类型、框选区域）。
成员管理 / 组织架构（部门名称、成员、主管）/ 职务。
内置 7 个角色：系统管理员、成员、任务管理、采购员、项目管理、财务管理、系统子管理员；可新增管理角色。
按业务卡片配置审批：新增出库单、入库单、维修服务单、支出合同、用章申请、采购申请、采购订单（可开“自动生成付款申请”）、询价定标、询价单、费用报销、余额调整、资金调拨、零星采购。每项含“表单配置”和“编辑”（X6 流程图）。
每个应用的可见性 / 可见范围，决定左侧菜单显示。
未截到的页面：维保任务/记录/签到（试用角色无权限）、通知公告详情、个人中心、微信 H5 端（业主签字、供应商报价、维修服务报告）、以及 /iotDevice/*、/check/* 两个以微前端方式挂载的物联/检测子应用。
根节点按左侧一级菜单分支；叶子节点是页面级功能，灰色小字为前端路由目录名。
看完手册和全部页面之后，客户的判断依然成立，而且可以说得更具体：云消防的“ERP”是消防服务商视角的项目成本核算 ERP，不是通用制造/贸易 ERP；CRM 只是客户档案；EHR 基本不存在。
候选底座陀螺匠·企业助手 V2.5（CRMEB 出品，AGPL-3.0 开源）的定位是“OA + CRM + 人事 + 低代码”，恰好长在云消防最短的地方，而它自己最短的地方（采购、库存、项目成本）又正是云消防最长的。下面把三者放在一张表里对照。
后台左侧是十个一级入口：办公、待办、客户、AI、项目、财务、人事、行政、云盘、库存，底部是系统（低代码与设置）。下面按一级入口列出真实二级/三级菜单，方括号里是路由前缀，便于对照源码。
crud/module/gongzitiaojiegou），说明薪酬只是台账，没有核算引擎| 领域 | 客户需要的核心能力 | 云消防 | 陀螺匠 V2.5 | 以陀螺匠为底座还要做什么 |
|---|---|---|---|---|
| EHR / 人事 | 员工档案与入转调离、考勤/排班/假期、薪酬与社保、绩效、培训、招聘、证书与合同到期提醒 | 几乎没有 | 约八成 | 档案（未入职/在职/离职、转正）、考勤统计、排班、假期类型、绩效、职级体系都是现成的；要补的是薪酬核算与社保（现在只是低代码工资条台账）、招聘、证书与劳动合同到期提醒（可用低代码实体 + 触发器实现） |
| CRM | 线索池与公海、商机阶段/漏斗、跟进记录与提醒、报价单、客户分级、合同续签、满意度 | 薄 | 约八成 | 公海、线索池、商机（含赢单/输单）、合同签约（电子签）、合同订单、回款、发票、业绩目标、企微 SCRM 都有；要补商机阶段漏斗视图、正式报价单、客户分级与满意度。若客户要云消防式的“单位 → 建筑场所 → 设备”结构，需扩展客户实体 |
| 项目管理 | 项目、任务、合同关联、成本归集、工单、现场执行 | 完整 | 约三成 | 陀螺匠项目只有项目/任务/进度/动态，已能关联客户与订单；缺收款计划、成本归集、工单派发、现场签到与水印拍照。这部分按云消防的页面清单新开发，移动端在 uni-app 工程里做 |
| ERP · 供应链 | 物料、供应商、采购申请/订单/询比价、多仓库位批次、入出库、盘点、预警、销售发货、BOM | 采购强、库存弱 | 库存强、采购无 | 陀螺匠库存已有多仓、良品/残次、在途/占用、盘点、调拨、台账、过低预警，比云消防的单仓入出库完整；但供应商、采购申请、采购订单、询比价整条采购链没有，需要按云消防 api-invoicing-center 那一组页面新开发并挂到“采购入库”上；库位/批次、BOM 视客户是否需要 |
| ERP · 财务 | 收付款、应收应付账龄、发票、资金账户、报销、凭证总账/对接金蝶用友、预算、多维报表 | 基础 | 约三成 | 陀螺匠只有收支记账 + 开票 + 报销审批（审批通过自动记流水）；需新开发付款管理、资金账户、应收应付账龄、预算控制；总账建议对接金蝶/用友 |
| 平台能力 | 权限、审批流、待办、消息、多端、可配置表单 | 微服务、流程引擎 | 低代码、AI、多端 | 陀螺匠的实体设计 + 表单 + 流程 + 触发器 + 图表 + 对外接口是一套完整的低代码栈，加上 AI 智能体应用和企微集成；缺多租户（客户单企业部署通常不需要） |
能覆盖多少：看过真实后台之后，比上一版估得更乐观一些：客户要的 EHR 约八成、CRM 约八成可以直接用现成模块；库存管理陀螺匠反而比云消防做得好；真正要从零写的收窄为采购链（供应商 / 采购申请 / 采购订单 / 询比价）、项目执行与成本核算、付款与资金账户三块，其余是在现成模块上改。
改造路径建议：第一步把陀螺匠部署起来让客户直接用人事、CRM、库存、审批和云盘，两周内能见到东西；第二步用低代码搭薪酬台账、证书到期提醒、供应商档案、采购申请这类“表单 + 审批”需求做过渡；第三步按 Laravel 模块化方式新开发采购订单与询比价（挂到现有入库单）、项目成本域、付款与资金账户，前端沿用 Element UI；移动端在 uni-app 工程里加任务签到、水印拍照。云消防这份分析里的页面清单与字段可以直接作为这三块新模块的原型依据。
需要先想清楚的四个风险：第一，技术栈是 PHP + Vue 2（移动端 Vue 3），若你们团队主力是 Java/React，维护成本要算进去；第二，AGPL-3.0 要求分发的衍生作品同样开源——把改造后的系统交付部署给客户是否构成“分发”、客户是否接受源码开放，需要在签约前确认，或者直接购买 CRMEB 商业授权规避（这一点建议咨询律师，我不是法律顾问）；第三，陀螺匠是单企业 OA 模型，没有云消防那样的多租户和二级服务商结构，如果客户以后想做 SaaS 会受限；第四，低代码适合台账和审批，库存/采购/成本结转这类有算法的业务要写代码，别指望拖拽解决。
陀螺匠资料来源：官方 V2.5 功能清单与移动端功能结构图（doc.crmeb.com 图片，已分段放大阅读结构图；功能清单长图仅读取前几屏）、演示后台 demo.tuoluojiang.com 逐个一级入口展开的真实菜单与 14 个页面截图、CRMEB 社区功能介绍帖、Gitee 仓库说明。
2026-08-25 在已登录的浏览器里注入录制脚本，先自动遍历 73 个页面，再手动走完新增项目 / 单位 / 合同 / 供应商 / 材料 / 采购申请 / 报销 / 付款和一次审批。再编辑、删除若干条数据。共拦截 1353 条网关请求，去重后 192 个接口，其中 28 个写接口（新增 16、修改 8、删除 2、其它 2），分属 10 个微服务。所有请求经 /gateway/<服务名>/… 转发，Bearer Token 鉴权，列表统一 current / pageSize 分页，字典统一走 api-user/dicts/code?dictCode=…。
响应包有两种壳：主流是 {data, resp_code, resp_msg, success, showType, traceId}，少数采购/收款接口是 {total, code, data}。实体普遍带 creatorId / createBy / createTime / updaterId / updateTime / isDeleted / tenantId 审计字段。完整的请求体和响应 JSON 在抓取包 api/ 与 api-write-requests.json 里。
| 操作 | 接口 | 请求体关键字段 | 说明 |
|---|---|---|---|
| 新增项目 | POST api-user/project/add | projectName, contactsId(业主单位), projectAddress, lng/lat, projectType, principalId, remark | 地址带高德经纬度；编号由 api-user/number/getNumber 按规则预取 |
| 新增单位 | POST api-user/unit/add | unitName, creditCode, unitTypeIds/unitTypeCode, industryList, headerPic, 联系人、区域、地址 | 统一信用代码可走企查查补全（product/suppliers/qcc 同源） |
| 新增收入合同 | POST api-user/unit/contract/add | projectId[], contractName, contractAmount, contractType, 起止日期, 附件 | 一份合同可关联多个项目 id |
| 新增支出合同 | POST api-user/expenditure/contract/save | contractName, contractTypeId, contractPartyAId, contractPartyBId, contractHandlerId, 金额、期限 | 保存前先调 POST api-workflow/approve/business/find/formCodeAndArgs（formCode=payContract, amount, projectIds）拿审批流 |
| 支出合同签订 | PUT api-user/expenditure/contract/signed | id, contractDate, contractStatus, signFileList | 状态机推进 + 签约附件 |
| 新增供应商 | POST api-invoicing-center/product/suppliers/add | supplierName, creditCode, supplierCategoriesId, contactName, 电话、地址 | |
| 新增材料 | POST api-invoicing-center/product/info/add | productName, productCode, 类型、品牌、规格、单位 | 类型树来自 product/categories/tree/sync |
| 提交采购申请 | POST api-invoicing-center/invoicing/purchase/request/submit | name, applyTime, projectId, taskType, applicantUserId, productAddDTOList[], fileAttachmentList, imageList, businessId, taskActorList[] | 业务单据里直接内嵌审批人列表 taskActorList，说明审批人由前端按流程引擎配置算好后随单提交 |
| 报销草稿 / 提交 | POST api-financial/reimbursement/draft · …/reimbursement/insert | isAssociatedWithProject, projectId, departmentId, payee, applicationDate, workOrderId, reimbursementDetailDtoList[], businessId | 草稿与正式提交分两个端点；POST …/get/list/reimbursement/invoice 用于关联发票 |
| 付款申请 | POST api-financial/payment/application/save | paymentTypeId, paymentAmount, payee, invoiceStatus, applicationDate, estimatedReturnDate, salaryMonth, reimbursementPaymentRelatedList[] | 可把多张报销单合并成一次付款 |
| 审批通过/驳回 | PUT api-workflow/flw/task/update | taskId, businessId, actorId, approveResult, imageList, attachList | 统一的审批动作接口；配套 flw/instance/info、flw/task/data/info、flw/comment/list/by-instance/{id} |
| 新建维修工单 | POST api-user/task/repair/add | projectId, type, executeFinishDate, unitContactsId, taskRepairItemsList[], isBackfill, dynamicContent, options | isBackfill 支持补录已完成的维修 |
| 新增入库单 | POST api-invoicing-center/in/warehouse/order/save | title, inWarehouseDate, invoicingOrderId(采购订单), productSuppliersId, warehouseType, totalAmount, totalQuantity, 明细 | 入库单挂采购订单 |
| 新增出库单 | POST api-invoicing-center/out/warehouse/order/save | title, outWarehouseDate, warehouseId, outWarehouseOrderItemsList[], totalQuantity, totalAmount, receiverUserName | |
| 新增发票 | POST api-financial/task/add | invoiceType, invoiceHeader, invoiceNumber, issueDate, invoiceDetailsType, issueAmount, taxExcluded, taxAmount, fileAttachmentList | 发票在财务服务里叫 task |
| 编辑项目 / 单位 / 收入合同 | PUT api-user/project/update · PUT api-user/unit/update · PUT api-user/unit/contract/update | 与 add 同一套字段 + id | 更新用 PUT，字段与新增一致 |
| 编辑材料 / 仓库 | PUT api-invoicing-center/product/info/update · PUT api-invoicing-center/warehouse/upd | id + 全量字段；仓库有 isDefault | 命名不统一（update / upd） |
| 删除工单 / 合同 | DELETE api-user/work/order/del/{id} · DELETE api-user/unit/contract/del/{id} | 路径参数 id | 软删除，进回收站（recycle/station/list） |
| 签到配置 / 维修内容 | PUT api-user/sign/in/config/update · POST api-user/maintenance/content/save | taskType, isWatermarkCamera, distance / maintenanceName, remark | 业务设置 |
| 消息已读 | PUT api-notice/notice/message/batch/read | id[] |
规律：新增用 add / save / insert / submit，修改用 PUT …/update（个别 upd），删除用 DELETE …/del/{id} 且为软删除，状态推进用 PUT …/signed、…/task/update，需要审批的单据在提交前先调 approve/business/find/formCodeAndArgs 取审批流并把 businessId + taskActorList 塞进请求体——这是把工作流和业务单据解耦的典型做法，定制系统可以照搬。
api-user业务主服务，50 个接口：用户/组织/权限 + 项目/单位/任务/合同/维保/签到/系统设置api-invoicing-center供应链，14 个：供应商 / 物料 / 采购 / 询价 / 仓库api-financial财务，16 个：收付款 / 报销 / 账户 / 用章api-workflow工作流引擎（Flowable 命名）api-stats经营看板api-iot-center物联网设备（本次新发现）api-todo · api-notice · api-dynamics待办 / 消息 / 业务动态api-aiAI 助手与智能数图（对接 Dify）api-uaa认证中心（登录时调用，本次已登录未触发）AI 对话接口字段（difyConversationId）表明后端接的是 Dify 平台。
前端从构建产物直接确认；后端只能从网关服务名和接口风格推断，已标注为“推断”。
| 视图层 | React 确认 |
| 应用框架 | UmiJS 4（umi.js 主包、p__路由__index 分包约定，hash 路由） |
| UI 组件库 | Ant Design 5 + Ant Design Pro（ProLayout 混合布局、ProTable/ProForm），emotion CSS-in-JS，自定义左侧菜单组件 |
| 状态管理 | dva（redux + redux-saga）+ Umi useModel |
| 请求 | axios / umi-request，统一走 /gateway/ |
| 微前端 | qiankun，/iotDevice/*、/check/* 为子应用 |
| 工具库 | dayjs、lodash、decimal.js、crypto-js、qrcode |
| 图表 | ECharts（看板环图、趋势） |
| 流程图 | AntV X6、G6（流程引擎的审批流设计器） |
| 地图 | 高德、百度、OpenLayers（单位定位、签到、全景地图） |
| CAD 图纸 | 浩辰 GStarSDK 网页看图（智能数图 / 项目图纸页签） |
| 3D | three.js + OBJ/MTL Loader |
| 视频 | zlplayer + hls.js（设备中心监控流） |
| 物联推送 | Paho MQTT over WebSocket |
| 导入导出 | SheetJS xlsx、jsPDF + html2canvas |
| 入口 | 统一 API 网关 /gateway/<服务名>/… |
| 认证 | api-uaa：OAuth2 password / sms 模式，Bearer Token |
| 微服务 | api-user（业务主库）、api-invoicing-center（供应链）、api-financial（财务）、api-workflow、api-stats、api-todo、api-notice、api-dynamics、api-ai |
| 技术栈 | 服务命名、/oauth/token、flw/instance（Flowable）等风格高度符合 Java Spring Cloud（Gateway + Spring Security OAuth2 + Flowable）体系 |
| 多租户 | 请求带 tenantId；按“服务商 / 二级服务商 / 业主单位”三层组织，授权记录与试用期控制 |
| 移动端 | 微信服务号 + H5（同一套 React 代码的 WeChat/* 路由），公众号推送任务与审批 |
推断项仅依据公开的前端产物与接口路径，未接触源码；若需要精确版本，可在浏览器 Network 面板看响应头，或向对方索取技术文档。