规则完全不动,只改名字,消除误导。 ## 为什么改 页面原名「仓储中心 24 小时发货时效」,但判定规则是「到 13:00 / 18:00 核验时刻仍未发货即超时」,**没有满 24 小时的门槛**(业务 2026-10-20 已三次纠偏定版)。 名字和规则打架,导致看的人以为「不满 24 小时不该算超时」。 实测例子:10-27 16:00 创建的单,今天 13:00 核验时只等了 **21 小时**就被判超时; 13:00 轮 599 单里有 416 单属于 10-27 16 点后创建。业务看到就问「创建时间都在 7 点后, 为什么算超时」—— 其实是名字里的「24 小时」在误导(那些是**昨天**晚上的单, 不是今天的)。 ## 改了什么 用户可见(2 处): - 侧栏菜单:`仓储中心24小时发货时效` → `仓储中心发货时效` (不加括号:侧栏现有最长 label 12 字,加了会到 18 字溢出) - 页面标题:`仓储中心 24 小时发货时效` → `仓储中心发货时效(到点未发即超时)` 其余为注释同步(8 个文件),代码逻辑与判定口径**零改动**: `warehouseShipTimelinessRegistry/Service/NotifyJob/NotifySettings`、 `warehouseLogisticsExceptionRegistry`、`frontend/api/warehouseShipTimeliness`、`backend/index`。 ## 不变的部分 - 核验时点、窗口上界(07:00 / 16:00)、仓级例外(山东 15:00、洛宁 13:00) - 数据源与起算点(订单两表 + `created`) - 钉钉推送抬头本来就是「【仓储中心发货时效】」,不用改 ## 验证 - 前端 eslint 通过、`npm run build` 通过(31.86s) - 浏览器真渲染(本地 5173,等足 75 秒数据返回): - 标题 = `仓储中心发货时效(到点未发即超时)` - 侧栏项 = `仓储中心发货时效`,全页 `body` 内已无「24小时」字样 - 数据正常渲染:超时未发 599 单 / 不计考核 849 / 涉及仓库 8 个 / 最久未发 13 天 - 明细「创建时间」列完整显示 `2026-10-27 19:xx` 这类日期,不存在时区错位 - 无 pageerror - 后端 `npm run check`:本次只动注释,不影响
拼多多自动化运营平台
公开的拼多多业务精简版。欢迎所有人克隆、修改、分发代码并提交 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、密码、令牌、数据库备份或真实业务数据。