chengma/cmautobuy
2
0
Fork 0
Code Issues 89 Pull Requests Actions Packages Projects Releases Wiki Activity
110 Commits 1 Branch 0 Tags
512ccf34d6d6904128a4e3fa0d166558d1bc7315
Commit Graph
110 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
chengmaandClaude Opus 5 512ccf34d6 docs: 新增顺运宝接口契约；config.yaml 加入 gitignore 
从 4 份 HAR 抓包和示例脚本还原 docs/admin/08-顺运宝接口.md。
全部结论标了出处，只有单一样本支撑的都标了 [待定]。

抓包验出三件和现有假设不符的事：

1. 登录响应的 JWT 从不参与请求，认证全靠 Cookie。示例脚本里
   self.token 只用于算缓存有效期，没进过任何请求头。Go 侧存 Cookie
   即可，token 都不用存。

2. _capture_refreshed_token 是死代码——它从响应头 X-Requested-With
   读刷新后的 JWT，而 4 份 HAR 共 18 个响应里带该头的是 0 个。
   会话就是 24 小时硬上限，没有滚动续期，不要移植这段逻辑。

3. 金额单位在同一个响应里不统一：amtOrder 在列表接口是分（61200
   对应 612.0），escrowAmount 却不是（505 对应 505.0）。不能假设
   "列表接口的金额都是分"，逐字段确认。这条只有一个样本，已标 [待定]。

还推翻了「货运单规格能直接对上蝦皮商品規格ID」这个前提：顺运宝给的
productId 是 11 位商品ID，蝦皮規格ID 是 12 位。但 productSpec 的格式
与蝦皮报表完全一致，可直接复用 #38 的 ParseSpec，匹配走
"productId 定位商品 → 解析规格 → 在该商品的 SKU 里比对"。

admin/config.yaml 含明文密码且此前没有任何 gitignore 规则挡它，
一次目录级 git add 就会进历史。已加规则，并补 config.example.yaml
作为模板（不含真实凭据，进 git）。

已确认历史提交中从未出现过该凭据。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-09 10:59:00 +08:00
chengma 5fd71981e0 feat: 支持持续自动获取任务 (#45) 2026-08-09 10:54:18 +08:00
chengmaandClaude Opus 5 4022feee43 docs: 记录 #31 #32 验收通过 
两份归档都由实现方写好，本次只更新状态。

#31 遵守了 #20 立的「迁移只追加」规则：v4 用 ALTER TABLE 加 shop_name，
v1/v2 原文未动，CheckSchema 也覆盖了新列。

#32 的 skus 是颜色×尺码的笛卡尔积并带 price_observed_at，
与 #31 的 price_granularity 对得上——两侧独立得出同一结论。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-09 10:19:11 +08:00
chengma cbb03faac8 docs: 归档任务 #44 2026-08-09 10:12:56 +08:00
chengma 7b104e3072 test: 覆盖颜色等待参数校验 (#44) 2026-08-09 10:12:25 +08:00
chengma ed72e62eda perf: 优化颜色采集等待时间 (#44) 2026-08-09 10:10:15 +08:00
chengmaandClaude Opus 5 6d40c1e986 docs: 归档 #41 #43，记录 #38 #41 #43 验收通过 
#41 归档记录了两条防信息丢失的设计（SKU 数列、待补列），以及最危险的
「部分失败」场景实测：28431952912 颜色4/尺码5 数字看着正常，
里面有 4 个 SKU 解析失败，靠整行标黄才藏不住。

#43 归档记录了实现踩到的 html/template URL 上下文转义坑：
夹在字面量 & 中间的动态内容会被整体当成一个参数值转义，
?/= 变成 %3F/%3D 让链接失效，只有真跑起来看 HTML 才发现。

也记了架构角色第二个变异第一次打偏、显示「跳过」的事——
探针无效和代码有问题是两回事，#38 刚犯过一次。

三份都如实列了「未验证到的部分」，主要是浏览器实机交互和
列宽百分比在 table-cell 上的实际行为。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-09 10:06:42 +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
chengma 033bef0614 docs: 归档任务 #42 2026-08-08 11:25:41 +08:00
chengma 5aaf0a937e fix: 允许颜色缺价后继续采集 (#42) 2026-08-08 11:25:06 +08:00
chengmaandClaude Opus 5 ccc146cfbe style: 蝦皮商品名称列再收窄到 18% (#41) 
30% → 18%（初版的六成）。蝦皮标题普遍很长，实测最长 60+ 字且全是
关键词堆砌，不收窄的话这一列会把后面的颜色/尺码/SKU/待补几个数字
挤出屏幕——而那几个数字才是这个页面要看的东西。

数值只写在 app.css 一处，模板注释不再重复具体百分比，
免得下次改了数值忘了同步注释。title 属性保留，悬停看完整标题。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-08 11:16:44 +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
chengma d199867101 docs: 归档任务 #40 2026-08-08 10:30:49 +08:00
chengma d8505a4b2b docs: 更新任务 #39 验收修正 2026-08-08 10:30:49 +08:00
chengma 9dadac2bff feat: 滚动采集评价数量和店铺名 (#40) 2026-08-08 10:30:04 +08:00
chengma 2f83be5e40 fix: 中文显示任务当前步骤 (#39) 2026-08-08 10:29:59 +08:00
chengmaandClaude Opus 5 10b724f62a docs: 归档 #38；改正六份归档里未经验证的 Go 版本说法 
#38 归档记录了打回一次的经过（ParseSpec 两个失败分支无测试覆盖，
其中 size=="" 就是真实数据里 2 行走的分支），以及架构角色第一轮
变异打在死分支上、差点误报「测试没牙」的过程。

改正：/usr/local/go 从 2026-07-02 起一直是 1.26.5，而六份归档都写着
「架构角色亲自执行（Go 1.23.0）」——那是照项目固定版本抄的，
没有实际验证过工具链，违反 CLAUDE.md §9「说验证过必须真的跑过」。
措辞改为不宣称具体版本。已用 GOTOOLCHAIN=go1.23.0 补验，结论不变。

admin/AGENTS.md 加两条 [必须]：
- 交付前至少跑一次带 GOTOOLCHAIN=go1.23.0 的验证。开发机装的可能更新，
  Go 会默默用它编译，测过的不是要交付的那个版本。新加依赖时尤其要跑。
- 改数据库时不要只测全新库，先列出现实中存在哪些 schema 状态再一个个验（来自 #20）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-08 09:59:34 +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 18770f25e1 docs: 归档任务 #39 2026-08-08 09:47:49 +08:00
chengma cb323d37ba feat: 实现 PDD 任务详情窗口 (#39) 2026-08-08 09:46:58 +08:00
chengma 6c12e058c3 docs: 归档任务 #37 2026-08-08 09:26:21 +08:00
chengma 9562da9aad fix: 蛇形遍历颜色并逐色采价 (#37) 2026-08-08 09:25:40 +08:00
chengma e08fd89c91 docs: 归档任务 #36 2026-08-07 18:14:28 +08:00
chengma e65cc2afda fix: 商品页就绪后立即进入规格面板 (#36) 2026-08-07 18:13:10 +08:00
chengma 09b27cec42 docs: 归档任务 #35 2026-08-07 17:59:20 +08:00
chengma c59b4b0d59 fix: 修复 PDD 页面误判与失败回执 (#35) 2026-08-07 17:58:30 +08:00
chengma 51c2292be1 docs: 归档任务 #32 2026-08-07 17:39:16 +08:00
chengma 2d1fdbea3f feat: 执行并提交 PDD 采集任务 (#32) 2026-08-07 17:38:29 +08:00
chengmaandClaude Opus 5 34b4b54b63 docs: 归档任务 #34，记录验收通过 
记录两处主动判断及依据：缩短 /tasks 的 placeholder（工单 [注意] 里
预先写明"真装不下就缩文案，不要把宽度调回去"）；把搜索框宽度规则从
§5.1 提到 §3.1 通用规则（原来写在 PDD 页那一节，另外两页看不到）。

未验证：浏览器实机目视、主题与缩放。用户已实机确认。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 17:23:49 +08:00
chengmaandClaude Opus 5 3fdab7b2a8 docs: 记录 #16 #17 #19 #20 #24 验收通过 
补上 #20 和 #24 的归档（此前只提交了代码），并把 #16 #17 #19
的状态改为验收通过。

#20 归档记录了工单中途被修改的经过：原工单写死「user_version=2 ⇒ 老结构」，
用户实测炸出 table already exists 后才发现 #16 的原地改写让这个版本号
对应两种结构，路径本来就是两条。按 CLAUDE.md §7.5 改工单而不是让实现硬凑。
也记录了变异测试第一轮漏掉两个的原因——架构角色的设计让收敛测试变成了
近乎同义反复。

#24 归档记录了四个变异全部被抓到，其中「破坏原子性判断」那个最关键：
加超时分支最容易顺手把原子抢占破坏掉。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 17:18:32 +08:00
chengma 61d8d1b263 docs: 归档任务 #31 2026-08-07 17:14:12 +08:00
chengmaandClaude Opus 5 6a7cde2ca6 feat: 顺运宝页与采集采购页搜索框收窄 (#34) 
跟上 #23 给 PDD 页做的：搜索框收到 30%，「搜索」按钮紧挨输入框。
蝦皮数据页和客户端列表页按用户要求暂不动。

复用 #23 已有的 .search-narrow 类，没有为这两页新写 CSS 规则——
多写一条就多一处将来要同步的地方。全局规则
.toolbar input[type="text"] 一字未动，它被五个页面共用。

搜索按钮靠左没有加对齐样式，是收窄的自然结果：输入框不再伸展之后，
多余空间留在按钮之后。额外加 margin-right:auto 之类会和 grow 叠加出
难预料的结果。两个表单的 grow 都保留，它负责把删除按钮顶到最右侧。

/tasks 的 placeholder 从「任务编号 / 订单号 / PDD 商品 ID」缩成
「任务编号 / 订单号 / 商品 ID」——收到 30% 之后原文案装不下，
会被截断成看不出意思的半截。缩文案而不是调回宽度。

文档把这条规则从 §5.1 提到 §3.1 表格通用规则里，三个页面都指向它。
原来写在 PDD 页那一节，另外两页要用时看不到。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 17:13:42 +08:00
chengma 93beef8b36 feat: 保存并展示 PDD 店铺与价格采样信息 (#31) 2026-08-07 17:13:25 +08:00
chengma a2fc1501c4 docs: 归档任务 #30 2026-08-07 16:43:49 +08:00
chengma 51062f4c7b feat: 领取 Admin 采集任务并保存本地 (#30) 2026-08-07 16:42:31 +08:00
chengma 107366f1f0 docs: 补充任务 #28 实现提交 2026-08-07 16:14:59 +08:00
chengma 77ec0d997b docs: 补充任务 #28 链接校验记录 2026-08-07 16:14:44 +08:00
chengma f1c2700fde fix: 校验 PDD 采集商品链接 (#28) 2026-08-07 16:14:43 +08:00
chengma 0044442f5d docs: 归档任务 #28 2026-08-07 16:13:48 +08:00
chengma 4aff22c009 feat: 实现 PDD 商品采集基础服务 (#28) 2026-08-07 16:12:39 +08:00
chengma d2decc7a29 docs: 记录任务 #29 验收结果 2026-08-07 15:57:57 +08:00
chengma 52f11eecdc docs: 归档任务 #29 2026-08-07 15:55:18 +08:00
chengma 6d863a1a8a feat: 检测 Android 设备 PDD 安装状态 (#29) 2026-08-07 15:54:12 +08:00
chengma a6e3fe0417 docs: 完成 Android 设备工单验收 (#21 #22 #25 #26 #27) 2026-08-07 15:20:48 +08:00
chengmaandClaude Opus 5 fbfa2fce3d docs: 归档任务 #19 
如实记录打回两次的过程，以及两次都是架构角色的检查指令给窄了：
第一次给的 grep 只覆盖「四个模块」，漏掉「四个页面」这个变体；
第二次改成直接给 6 处确切行号，并点明哪两处的「四个」是对的不许改。

未验证四项：浏览器实机交互、主题与缩放、采购任务真实创建路径
（入口尚未实现，验证用的是手工插库）、目标列规格顺序与工单示意图不同。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 15:17:32 +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
chengma c07fe56ac3 docs: 归档任务 #27 2026-08-07 15:13:07 +08:00
chengma 57503978bd fix: 修复 Wi-Fi ADB 拔线后刷新丢失 (#27) 2026-08-07 15:12:32 +08:00
chengma ffaeb55a25 docs: 归档任务 #26 2026-08-07 14:53:57 +08:00
chengma dc9b000a36 fix: 启动时恢复已保存的 Android 设备 (#26) 2026-08-07 14:53:28 +08:00