yanhui
1139e4c364
业务 2026-10-29 第三次报同一件事：13:00 轮里作废的单、已经发货的单还在考核。 根因不是判定写错，而是**订单两表各自停更**，停更期间聚水潭做的「取消 / 发货」 订单表完全看不到 —— status 仍是 Delivering、send_date 仍是空。 ## 现场证据（2026-10-29 13:00 轮） - 当天 qmcust 停在 07:25（6 小时），13:00 轮 159 单**全部**来自它 - 订单表侧：159 单 status 全 Delivering、send_date 全空、labels 里**没有** 「发货前售后」⟹ 原来的 `presaleVoid` 判据（订单表 labels 含关键词）完全失效 - 状态镜像表（停在 11:52，比订单表新鲜 4 小时）： `order_status_name='已取消'` **11 单**，`order_labels` 里才有「发货前售后」 「已打印被取消」；其余 145 单「发货中」 qmcust 13:25 补数后重算，误判量比想象大得多： **overdue 159 → 16，作废剔除 195 单、已发剔除 17 单。** ## 改动 判据（新增，排在窗口判断与「不计考核」之前）： | 判据 | 处理 | |---|---| | `order_status_name='已取消'` | 作废，剔除（计 `stateVoidSkipped`） | | `send_time` 有值 | 已发，剔除 | | `order_status_name='已发货'` | 已发，剔除 | | `logistic_status_name` ∈ 已揽收/运输中/派送中/已签收/拒收 | 已发，剔除 | - `loadOaConfirmInfo` → `loadStateInfo`，同一次 IN 多取 4 个语义列，**不增加往返** - ⚠️ **判据只用 `order_status_name`**：`aftersale_status_name='已作废'` 是「售后单被撤销、 订单照常发货」，近 2 天 1387 单全是这种，混为一谈会把该考核的单全放跑 - ⚠️ `未揽收` / `无物流单` **不算已发**（后者是连快递单都没录，当天 39/159 单是这种） - 状态镜像表纳入 `dataSources` 停更监控（它停了，「取消了吗」的依据就过期了） - 明细/导出新增「聚水潭状态」「物流状态（聚水潭）」「状态表抓取时间」； 页面「发货状态」列改优先显示聚水潭终态，与订单表不一致时打 ⚠ ## 验证 - 后端 `npm run check` 496/498（2 个失败是老问题：负缓存 TTL、Windows 文件权限） - WST 单测 **25/25**，新增两组：终态剔除（含「售后已作废不能误剔」的反向保护）、 状态表纳入新鲜度监控 - 真实数据（本地直连生产 MSSQL，2026-10-29 13:00 轮）： `overdue=16 / stateVoidSkipped=195 / stateShippedSkipped=17`， 明细里「已取消」残留 **0**；剩余 16 单全是河南洛宁仓「发货中 + 无物流单」的真积压 - 作废证据交叉核对：状态表近 2 天「已取消」59263 单，94% 带「发货前售后」标签， 与业务口径一致
拼多多自动化运营平台
公开的拼多多业务精简版。欢迎所有人克隆、修改、分发代码并提交 Pull Request，代码按 MIT 许可证开放。
保留商品监控、仪表盘、激励看板、营销活动、推广、商品分析、工单以及在线客户端与执行任务等现有模块。部分菜单仍沿用原项目的占位页面。
已删除市场数据、店铺管理和运营工具整组页面、Claw 对话、skills 管理、平台切换与其他平台演示页，以及对应路由、页面资源、专属配置接口和权限项。首页为仪表盘。保留业务仍使用的模型配置、商品数据查询、桌面会话和自动上架公共服务继续可用；Claw 补全与图搜备用通道已经移除，缺失资料需使用业务接口或手工补充。
本地启动
需要 Node.js 22。团队开发机器无需安装或初始化 MySQL、Redis 及第三方数据库；使用管理员发放的部署 Key，一次注册后自动连接中央系统数据库、公网 TLS Redis 和第三方数据库。完整步骤及安全边界见 远程系统数据库部署。
npm --prefix backend ci
npm --prefix frontend ci
npm run remote:dev
首次启动时填写配置请求地址和部署 Key，系统自动写入被 Git 忽略的本机配置并重启后端。保存一次性显示的管理员账号和密码后直接登录，不需要在本地创建数据库或继续执行设置向导。前端默认访问 http://localhost:5173，API 默认代理到本地后端。
拉取主仓库更新后必须停止旧的 npm run remote:dev 进程并重新启动，保证前后端使用同一版本。MKH 页的强制刷新带有版本协议校验；如果新前端仍代理到未重启的旧后端，页面会停止展示可能过期的库存并明确提示重启，不再将旧值冒充为“最新数据”。
验证与构建
npm --prefix backend run check
npm --prefix frontend run check
前端构建输出位于 frontend/dist。部署时需为单页应用配置路由回退，并代理 /api 与 /cubejs-api 到后端。
启动时会迁移旧侧栏配置，并删除已退役页面的权限、专属设置和专用数据表。上架测算旧偏好表中的商品分析阈值会先迁移到商品分析专用表；其他保留模块的数据不受影响。迁移仅作用于实际配置给此实例的系统数据库。
参与修改
开始开发前请阅读 仓库提交与合并规范（多用户与 AI 开发必读）。准备更新生产服务器时必须继续阅读 服务器部署规范（开发者与 AI 必读）。AI 工具的规则入口为 AGENTS.md。每个任务使用独立目录和分支，通过 PR、同步验证和独立审核合并，禁止强推或覆盖其他开发者的工作。
所有用户均可 Fork 仓库、创建分支并提交 Pull Request。直接推送本仓库需要仓库所有者授予协作者写权限。提交时请说明修改和验证结果，勿提交 .env、密码、令牌、数据库备份或真实业务数据。