Commit Graph
58 Commits
Author SHA1 Message Date
chengma f693d2a6fc fix: 统一顺运宝单条采集客户端选择 (#174) 2026-08-12 09:56:15 +08:00
chengma 9ad067503e feat: 任务改用采集采购独立序号 (#172) 2026-08-12 09:21:21 +08:00
chengma 5528b4b874 fix: 修复顺运宝采购完成状态与重复采购 (#169) 2026-08-11 18:05:27 +08:00
chengma 9e328984e9 fix: 修复顺运宝采集任务孤儿状态 (#165) 2026-08-11 17:00:33 +08:00
chengma df1287f8eb feat: 展示任务PDD店铺和客户端名称 (#158) 2026-08-11 15:49:01 +08:00
chengma b527204204 feat: 支持顺运宝批量创建采集任务 (#153) 2026-08-11 14:59:26 +08:00
chengma 9d4d6fc1e5 feat: 增加顺运宝店铺筛选 (#151) 2026-08-11 14:39:13 +08:00
chengma c39f5a7912 feat: 增加蝦皮店铺图片筛选 (#150) 2026-08-11 12:04:38 +08:00
chengma 38d6a0a04b feat: 展示蝦皮主图和店铺 (#142) 2026-08-11 11:18:51 +08:00
chengma 4259be0e55 feat: 支持无SKU目录导入策略 (#141) 2026-08-11 11:03:18 +08:00
chengma c05c4fafdb feat: 展示顺运宝观测规格 (#140) 2026-08-11 10:46:11 +08:00
chengma 0588ef18c8 refactor: 切换蝦皮数据到目录接口 (#135) 2026-08-11 10:16:48 +08:00
chengma 3ac4467f6c feat: 增加商品目录导入记录 (#134) 2026-08-11 10:11:15 +08:00
chengma 273bcc14a6 feat: 实现商品目录批量导入接口 (#133) 2026-08-11 10:06:10 +08:00
chengma a9f22b9b0e feat: 按创建人隔离采集采购任务 (#127) 2026-08-10 23:10:28 +08:00
chengma a7bc9a940a feat: 采购详情展示 PDD 核单结果 (#125) 2026-08-10 19:59:47 +08:00
chengma 546d9ef7e2 fix: 允许已采集 PDD 商品重新采集 (#121) 2026-08-10 19:38:40 +08:00
chengma 10bb892e6c feat: 移除 Client 真实采购手工授权 (#114) 2026-08-10 18:37:35 +08:00
chengma a26219091a fix: 简化真实采购创建并恢复客户端选择 (#112) 2026-08-10 18:15:28 +08:00
chengma 66565d50cc feat: 采购价格仅展示选定规格 (#113) 2026-08-10 17:56:03 +08:00
chengma e1b32ea024 feat: 固定创建真实采购任务 (#112) 2026-08-10 17:52:48 +08:00
chengma 7106f6b024 feat: 顺运宝下一步支持单条建采购任务 (#106) 2026-08-10 16:34:55 +08:00
chengma 188725ff64 feat: 支持批量导入 PDD 商品链接 (#104) 2026-08-10 16:14:24 +08:00
chengma 3aaa40cfe0 feat: 增加真实采购任务安全模式 (#98) 2026-08-10 15:11:38 +08:00
chengma 775e38894e feat: 顺运宝支持输入 PDD 商品 ID (#95) 2026-08-10 14:26:03 +08:00
chengma 5a77bde534 feat: 增加规格匹配建议与决策审计 (#90) 2026-08-10 12:41:17 +08:00
chengma d1165b9e17 feat: 重构顺运宝规格主链路 (#88) 2026-08-10 12:24:23 +08:00
chengma 13cfced80d feat: 迁移 Admin Repository 到 MySQL 8 (#79) 2026-08-10 02:21:31 +08:00
chengma d99c81310d feat: PDD 批量采集支持可选客户端 (#74) 2026-08-10 00:49:51 +08:00
chengma 4433e3af37 feat: 完成规格映射与采购任务创建 (#69) 2026-08-09 22:55:14 +08:00
chengma 518e6df349 feat: 统一蝦皮与顺运宝 PDD 关联入口 (#68) 2026-08-09 22:40:58 +08:00
chengma 57a6484fd5 docs: 澄清顺运宝规格状态语义 (#67) 2026-08-09 22:34:22 +08:00
chengma c6ef54dce1 feat: 建立顺运宝采购处理状态 (#67) 2026-08-09 22:32:19 +08:00
chengma 155dd3b4a2 feat: 统一 Admin 主列表分页 (#64) 2026-08-09 21:51:20 +08:00
chengma 919522ff79 fix: 修复顺运宝分页总数误判 (#60) 2026-08-09 19:01:04 +08:00
chengma 05a54b044d feat: 统一顺运宝日期同步并记录历史 (#59) 2026-08-09 18:22:58 +08:00
chengma 4b5cd13807 fix: 增强顺运宝同步完整性保护 (#58) 2026-08-09 17:17:42 +08:00
chengma 008bb87620 feat: 支持管理员自助修改密码 (#57) 2026-08-09 16:49:28 +08:00
chengma 2cce9e3888 fix: 用户密码最小长度调整为六位 (#55) 2026-08-09 16:14:58 +08:00
chengma e0c0dac7a0 feat: 增加客户端采购员归属管理 (#54) 2026-08-09 16:02:25 +08:00
chengma eea0d65ef8 feat: 实现 Admin 采购员账号管理 (#51) 2026-08-09 13:50:55 +08:00
chengma 0a7db404a1 feat: 实现 Admin 首次初始化与网页登录 (#50) 2026-08-09 13:36:41 +08:00
chengma a18d4e67ae feat: 顺运宝支持指定日期同步 (#53) 2026-08-09 13:24:02 +08:00
chengmaandClaude Opus 5 5e426cacf6 feat: 顺运宝货运单同步 (#46)
顺运宝模块此前是骨架,「同步」点了提示"待接入"。5195 个蝦皮商品已经
进系统,但货运单(真实订单)一条都没有,后面的规格匹配无从谈起。

按接口契约(docs/admin/08,从 4 份 HAR 还原)实现:配置、登录(界面
手工输验证码)、会话缓存到 SQLite、按日期范围增量同步、落 syb_orders。

shopee_sku_id 绝不被同步覆盖。它是规格匹配的结果,顺运宝那边根本没有
这个值(只给 11 位商品ID,蝦皮規格ID 是 12 位)。同步写进去就是写空,
把人工攒的匹配成果洗掉且不报错。它只出现在 INSERT 列清单里,不在
DO UPDATE SET 里;repository 层和 service 端到端各有一个测试守着。

增量从「上次同步日期当天」重拉,不是第二天。created 筛选粒度是日期而
last_synced_at 精确到秒,从第二天拉会漏掉当天晚些时候创建的单且不报错。
宁可重复拉(upsert 幂等)也不能漏。中途失败不更新 last_synced_at,
否则下次跳过这段区间,漏的单永远补不回来。

日期运算用 UTC+8,不是 UTC。审查时从 HAR 确认 created 是当地时间:
抓包于 2026-07-28T03:31:45Z(= 11:31 UTC+8),同一响应里 created 是
"2026-07-28 10:37:59";若它是 UTC 则等于 18:37 UTC+8,比抓包晚 7 小时,
订单创建于未来,不成立。用 UTC 算会在本地 00:00-08:00 把"今天"算成昨天,
当天早晨的单这轮拉不到。用 time.FixedZone 写死,不用 LoadLocation——
那要读系统 tzdata,Windows 默认没有,打包成 exe 会失败。

金额一律取 detail/listByStock 的值:08 §5.1 实测同一响应里 amtOrder
在列表接口是分、escrowAmount 却不是,单位不统一,取错差 100 倍。

迁移 v5 纯追加(syb_session、syb_sync_state、syb_orders.product_spec),
v1-v4 逐字未动,CheckSchema 覆盖新表新列。

会话有效性判断把「网络故障」和「明确未登录」的分类集中在 Client.do()
一处——网络抖一下就判定登出的话,验证码会弹个不停,还会丢掉有效会话。

测试全部用 httptest 假服务端,不打真实站点。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-09 11:49:13 +08:00
chengmaandClaude Opus 5 edfe39cc35 feat: 蝦皮数据页分页与状态筛选 (#43)
导入真实样本后 /shopee 一次吐 3.4MB / 5195 行。但只加分页会把问题从
「5195 行糊在一起」变成「260 页里藏着 6 个」——那 6 个待补规格的商品
仍然找不到。所以分页和状态筛选一起做。

HTML 3.4MB → 16.7KB。

状态条显示全量而不是本页:「共 5195 个商品 · 第 1/260 页」。
显示「共 20 个商品」会让操作员以为总共就 20 个。筛选后显示筛选结果
总数:「待补规格:6 个商品」。

列表查询和 COUNT 共用同一套筛选条件拼装。分开写两份 WHERE,迟早
有天忘了给 COUNT 也加条件,页码算错而且没人发现(#19 踩过一次)。

page 越界兜到最后一页而不是显示空表格——空表格会让操作员以为数据没了。
总数为 0 时显示「第 1/1 页」,不出现「第 1/0 页」。

「待补规格」用 EXISTS 不用 JOIN+DISTINCT:一个商品有多个失败 SKU 时
JOIN 会出重复行,DISTINCT 又让 LIMIT/OFFSET 的行为难推理。

分页控件是 <a href> 纯 GET,浏览器前进后退和书签都正常。首末页用
<span class="disabled"> 禁用,语义上不再是链接,不只靠颜色区分。

这是全项目第一个分页页面,通用逻辑单独放 service/pagination.go 供
后面四页复用,规则写进 05 §3.2 而不是蝦皮页那一节(#34 踩过这个错)。
05 §3 的每页条数从「建议 50」改为「统一 20」并写明理由。

实现踩到 html/template 的 URL 上下文转义:夹在字面量 & 中间的动态内容
会被整体当成一个参数值转义,?/= 变成 %3F/%3D 让链接失效。改为在 Go 里
把整段 URL 拼好,模板作为单个 pipeline 输出,并加了回归测试。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 11:40:07 +08:00
chengmaandClaude Opus 5 64d5e74d0d feat: 蝦皮数据页改为商品级列表与规格弹窗 (#41)
原来是 SKU 级一行,问题不在行数(6092→5195 只少 15%),在语义错了:
pdd_goods_url / pdd_goods_id 在 shopee_products 上,是商品级字段。
商品 24420648774 有 62 个 SKU,列表里 62 行显示同一个 PDD 链接,
将来双击任意一行编辑的也是同一个字段,操作员会以为改的是这一行。

加了两列,都是防止聚合后丢信息:

「SKU 数」—— 只显示颜色数和尺码数会严重误导。实测 602 个商品(11.6%)
的颜色数×尺码数大于实际 SKU 数,最悬殊的 26886533818 是 15×5=75 但
实际只有 28 个。蝦皮报表只含有销售成绩的 SKU,数据本来就不全。

「待补」—— 原来解析失败的行整行标黄,聚合成数量后这个信号会丢。
23 条失败分布在 6 个商品里,其中 4 个是「部分失败」:数字看着正常,
坏数据被吃掉,永远没人去补。现在待补>0 整行标黄。

颜色数/尺码数只统计 parse_ok=1,否则空值会被算进 DISTINCT 多出
一个「空颜色」。

弹窗只读,待补的行显示 spec_raw 原文——不显示的话人工不知道该填什么,
保留原文这个设计就白做了。复用 #18 的弹窗机制,app.js 未改动。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 11:12:25 +08:00
chengmaandClaude Opus 5 e29d6683ad feat: 蝦皮 Excel 报表导入 (#38)
蝦皮数据模块此前整个是骨架,四个入口全返回 501,excelize 连依赖都没装。
本工单做导入和列表,Save/Delete/Collect 保持 501。

真实样本实测:5195 个商品 / 6092 个 SKU,23 行解析失败。

upsert 白名单式,pdd_goods_url / pdd_goods_id 既不在 INSERT 列清单里
也不在 DO UPDATE SET 里。报表没有这两列,写进去就是写空值——操作员
攒几周的 PDD 链接会被一次导入洗光,而且不报错,等到建采购任务才发现。
有独立测试守着:往 DO UPDATE SET 里加回这一行,测试立刻变红。

按 sheet 名字取「最佳表現商品」,不用第 0 个。工作簿有 5 个 sheet,
另外 4 个是广告报表,连 商品規格ID 列都没有;蝦皮调顺序时按下标
会静默导入一张完全不相干的表。

按列名找索引。40 列里 32 列是统计指标,蝦皮加一列所有列号就错位,
而且不报错——会把「點擊率」当成「商品規格」存进去。

规格解析三种格式:含【】53.4%、逗号+空格 26.4%、只有逗号 20.2%,
只认【】会漏掉 46.6%。括号不配对(21 行)和右半整个被【】包住(2 行)
一律判整体失败,不逐段硬凑——错法不统一,针对每种错法写规则等于在猜,
而且没有人工核对过的正确答案可验证。失败时 color/size/advice 必须全空,
原文存进 spec_raw 交人工补。

不写 DELETE + INSERT 的全量替换,将来手动新增的 SKU 会被删掉。

excelize v2.9.1 的 go 指令正好是 1.23.0,与项目固定版本一致。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 09:57:12 +08:00
chengma c59b4b0d59 fix: 修复 PDD 页面误判与失败回执 (#35) 2026-08-07 17:58:30 +08:00
chengma 93beef8b36 feat: 保存并展示 PDD 店铺与价格采样信息 (#31) 2026-08-07 17:13:25 +08:00
chengmaandClaude Opus 5 f0d7da37cf feat: 采集采购页,采集与采购统一展示 (#19)
原来的采购任务页是骨架:var rows []gin.H 从不查库,页面永远为空;
TODO 写的还是只查 task_type = 'purchase'。所以 #18 建出来的采集任务
在界面上哪儿都看不到——用户点完「创建采集任务」只能盯着
collect_status 猜。

模块名定为「采集采购」(用户指定),直接点出这页装的是哪两类任务,
比泛称「任务」更能让人一眼知道点进去看什么。路由 /tasks 不变,
改路由会让已有书签和文档链接全失效,没有收益。

列不按类型并列——两种任务字段完全不同,并列会让采集任务行一半是空列。
改成固定列 + 一列「目标」把业务信息概括成一句话:
  采集  PDD 737116531267
  采购  SO-001 · M/黑色 · 2件 · ≤¥42.00
拼接逻辑在 service 层,模板只负责显示。

统计和列表共用同一个筛选条件拼装函数。分开写的话总有一天会忘了
给统计也加条件,数字和表格对不上,操作员会以为页面坏了。

无主任务的客户端列显示「—」。#17 之后采集任务默认无主,这列会大量为空。

详情弹窗只读,采购专有字段(数量、价格上限、目标规格)在采集任务里
整段不出现,不显示空行。复用 #18 的弹窗机制,app.js 无需改动。

顺带清掉 PDD 页加进来之后一直没跟上的模块计数:多处「四个模块/四个页面」
改成五个。其中 06-quality-security.md 那两处是验证清单,
照着做的人只会测四个页面,PDD 页永远不在回归范围里。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 15:16:05 +08:00