2026-11-02 规则调整（三条）

1. 四层改为并行，互不压制

原来「零成交（转化层）」会压制「成交未核销 / 核销率低（履约层）」—— 这是把四层当成漏斗了。现在拆开：转化层、履约层各自独立判定；只有履约层内部保留根因去重（成交未核销 → 核销率低，同一根因不报两条）。文档和规则地图里的「互斥」表述同步改为「履约层内命中则不再判…」。

2. 隐藏「点亮后的投稿数」

lit_posts 实测只有 14 / 1413 家非零（合计 42 次），数据不可信。它本来就没有在任何界面展示过；这次更进一步，同步时不再向生意经请求该指标 （visible_checkin_item_cnt_1d），少一列无用数据。

3. 上榜信息作为检测指标

数据实况：980 家「-」（未上榜）、433 家有内容（「入围XX榜」或「XX榜第N名」）。

新增两条 T 级规则（流量层）： | ID | 判定 | 问题文案 | |---|---|---| | RANK0 | 上榜信息为空或「-」 | 未上榜（好评榜/人气榜均未进入） | | RANK_IN | 有内容但没有「第 N 名」 | 仅入围未进榜：{榜} |

db.aggregate_period 新增 rank_note（取最近一次有内容的）
接口 payload 增加 rank
表格新增「上榜」列：显示最好名次（绿色「第2名」）/「入围」/「—」
抽屉里显示完整榜单内容（金色左边框的提示块）
文案配置面板新增 4 个模板字段

当前命中（2026-11-02 周期，1413 家）

未上榜 980（69%）、仅入围 155（11%）、有点名次 278 家。规则总数 15 → 17 条，平均每家 7.24 个问题。

表格

新增「上榜」列后 14 列；收紧内边距与列宽后 1148px < 容器 1155px，无横向滚动条。

同步数据改为「弹窗确认」

原因

同步数据 一点就执行 —— 但这个操作会消耗平台配额、跑 3~9 分钟、还会弹出浏览器窗口，误点代价不小。

实现

点按钮先查 /api/sync/status：

有任务在跑 → 不发新请求，提示「同步正在进行中（21:23 开始），完成后会自动刷新」
空闲 → 弹出确认框

确认框内容： | 项 | 值 | |---|---| | 统计窗口 | 2026-10-04 ~ 2026-11-02（前端按今天往前 29 天算） | | 数据来源 | 抖音来客 · 生意经报表集市 | | 预计耗时 | 3 ~ 8 分钟（平台排队时间不定） | | 会消耗 | 1 次建任务配额（每天约 30 次） | | 上次同步 | 2026-11-02 01:04 |

底部提示：同步期间会弹浏览器窗口、不影响继续使用工作台、每天 01:00 也会自动同步。按钮：取消 / 开始同步；支持 Esc、点遮罩、× 关闭。

实测

直接调用 showSyncDialog() 渲染正常，字段与按钮齐全
点击按钮时因当时正有同步在跑，正确走了「进行中」提示分支（没有重复发起）
该次手动同步最终 21:23:10 → 21:32:06 成功，下载 294KB 并自动入库

备注

同步期间如果同时用 ego 浏览器做别的自动化，会和同步脚本抢浏览器，导致变慢。这次手动同步用了 9 分钟（平时 3~5 分钟），期间我正好在用 ego 核对界面。

导入历史增加「导出」按钮

需求

「每一条历史导入数据后面加一个导出按钮，可以用于导出历史报表」

实现

每行历史记录右侧加【导出】按钮，点击下载该批次的检测清单 GET /api/export.csv?period=<批次周期>
文件名自带周期：门店检测清单_2026-11-02.csv
若该批次的周期在当前数据库里已不存在（早期批次记录的是旧值 2026-11），按钮置灰，悬浮提示「该批次的数据已被后续导入覆盖，无法导出」
历史行的文件名改为单行省略号截断，右侧固定显示周期 + 时间 + 按钮

顺带修复

导出的 CSV 里有 153 个单元格带换行（来自动作文案里的 \n，如「1. 检查…⏎2.点亮…」）， Excel 打开会出现多行单元格。现在导出时把 \r\n 统一压成空格。

验证

点击第一个可用按钮 → 下载 门店检测清单_2026-11-02.csv，1414 行 × 16 列，含诊断结论/主因/全部问题/整改动作
2026-11 的两条历史记录按钮正确置灰
导出后 CSV 里不再有换行单元格

导出改为「纯门店数据」

需求

「导出就导出实际门店参考就好，不用计算问题诊断、原因和整改动作这些。这些内容在单家门店查询时展示即可」

改动

导出（左侧栏【导出数据】+ 导入历史每行的【导出】）不再包含诊断内容。

原来 16 列里有 4 列是诊断：诊断结论 / 主因 / 全部问题 / 整改动作 —— 全部移除。

现在是 17 列纯指标：

门店ID, 门店名称, 城市, 评分, 访问次数, 成交券数, 核销券数, 核销率, 核销金额,
待核销券(估算), 商责退单率, 投诉率, 差评率, 评价回复率, 发布视频数, 门店点亮数, 上榜信息及排名

顺带调整：

文件名 门店检测清单_<周期>.csv → 门店数据_<周期>.csv
左侧栏按钮 导出清单 → 导出数据
导出接口内部不再调用 rules.fmt_tpl 渲染文案，只输出数字

保持不变

筛选条件（KPI 卡 / 城市 / 问题类型 / 评分区间 / 搜索）仍然生效—— 问题类型筛选需要先判定，所以内部还是会跑诊断，只是结果不进导出文件。

验证

2026-11-01 导出：1414 行 × 17 列，列名与内容均无诊断字段；左侧栏按钮点击下载 门店数据_2026-11-02.csv 正常。

导出改为「原样返回导入的原始文件」

问题

用户指出导出的仍是加工数据。核对后发现：

生意经原始文件有 40 列，我们库里只存了 23 列
导出里混了 3 个计算列：核销率（核销券÷成交券）、待核销券（成交券−核销券）、差评率（中差评÷评价数）
其中 经营风险差评率是平台直接给的，我们却自己算了一遍，数字可能对不上

方案（用户选择）

导出 = 原样返回当时导入的文件，不含任何计算列。

实现

batches 表新增 file_path，记录原始文件在 data/processed/ 下的文件名
收件箱导入：先算归档名 → 导入时写入批次 → 再移动文件
上传接口 /api/import：同样把原件保存一份到 data/processed/
老批次自动回填：用 created_at 的时间戳匹配 processed/ 里的文件名前缀（如 2026-11-02T21:32:14 ↔ 20261102_213214_门店数据_....xlsx）
新接口：
- GET /api/batch/<id>/file —— 指定批次的原始文件
- GET /api/export.file?period= —— 该周期最近一次的原始文件
下载时文件名去掉时间戳前缀，恢复成 门店数据_2026-10-04_2026-11-02.xlsx
前端：左侧栏按钮改为【导出原始数据】，导入历史每行按钮改为【原始文件】；没有留存原件的批次（早期 Windows CSV）按钮置灰
移除不再使用的 exportCsv()；/api/export.csv 保留为「筛选结果 CSV」接口

验证

/api/batch/11/file 下载得到 40 列 × 1428 行，与原始 xlsx 完全一致
左侧栏点击 → 门店数据_2026-10-04_2026-11-02.xlsx
历史列表 8 条：5 条可下载，3 条（2026-10 的 CSV、一条重导入）置灰

开发日志_2026-11-02.md 7.3 KB 文件歷史 原始文件