# 2026-05-13 Agent健身房复盘
一句话概括：**这次发现的不是已经自动修复的问题，而是 5 类以后会反复浪费时间的操作摩擦 / 工具缺口。**
| 优先级 | 发现的问题 | 真实含义 | 计划怎么解决 |
| --- | --- | --- | --- |
| 1 | 商品域标签迁移缺少统一验收，版本、分母、HTML/Excel 同步容易混 | 同一天从 v27 到 v31 连续改层级，用户多次追问“是不是更新了/全局是否同步”；还发生了把 45,341 当大盘分母的口径错误。 | 做一个 taxonomy invariant checker：读明细 CSV、HTML payload、Excel 汇总、迁移审计表和分母源，自动校验旧标签零残留、行数一致、层级路径和分母来源。 |
| 2 | Ark 批量打标长尾靠人工盯进度和补错 | 9335 条 session 归 842 个场景时，真正耗时的不只是打标，而是 sample 卡住、read timeout、error 覆盖 ok、补跑策略不断切换。 | 沉淀批处理诊断器：统一记录并发、超时、ok/error、重试批次和 clean 选择策略，自动给出 only-errors 补跑建议和最终口径。 |
| 3 | 客服搜索推荐方案采集还是浏览器手工链路 | 内嵌浏览器/Chrome/桌面 UI 都尝试过，登录态、搜索词稳定性和页面读取会拖慢批量采集，最后只能先跑 10 个。 | 做客服搜索采集器：商品场景词 -> 搜索词改写 -> 工作台标题采集 -> 本地同源 KB 正文补全 -> Markdown/CSV 输出。 |
| 4 | Anki 高风险操作缺少统一 dry-run 安全预览 | 同一 session 里既重建导入钢琴卡，又删除英语概念卡红 flag；用户还纠正了目标牌组，说明 deck-target 校验和回滚证据必须标准化。 | 做 Anki 牌组操作安全预览：执行前输出目标 deck fingerprint、将变更的 cards/notes、备份路径、回滚命令和 postcheck。 |
| 5 | 推文日报账号名单依赖上轮 raw 回收 | 自动化要求从 config 读 twitter-fetcher.users，但实际 config 只有 key，日报靠 .codex_tmp runner 从上一轮成功 raw 恢复账号。 | 给 twitter-fetcher 加 roster preflight：检查 config、fallback raw、账号数量、API key 和日期窗口，缺口写入可修复报告。 |
## 下一步
| 顺序 | 先做什么 | 为什么 |
| --- | --- | --- |
| 1 | 先做商品标签迁移口径校验器 | 它直接对应昨天最长、最易返工的数据链路，能立刻减少版本/分母/HTML/Excel 不一致。 |
| 2 | 再做 Ark 批量打标长尾诊断器 | 这类大批量 LLM job 会反复出现，超时、补跑、clean 口径需要工具化。 |
| 3 | 把客服搜索采集器做成半自动流程 | 目前卡在登录态和搜索词稳定性，适合先做“搜索词 -> 标题 -> 本地 KB 补全”的可靠骨架。 |
## 一、证据详情
### 1.1 商品标签迁移口径校验器
这是一个高价值主题，不是噪音。连续 v27-v31 标签迁移暴露出同一类问题：层级口径、分母来源、明细 CSV、HTML、Excel 和 migration audit 经常需要同步，但当前主要靠人工反查，容易出现旧标签残留、全局产物未刷新或大盘分母误用。
| 证据 | session | 片段 |
| --- | --- | --- |
| ~/Documents/job-bu | `019e1b60-b114-7142-9df2-2d7c9bc24212` | 用户连续要求把商品域标签从 v27/v28/v29/v30/v31 迁移：定邀/报白移动到商品类目、商品信息改名信息填写并移动到商品创建、商品管理两个子类合并为商品修改，并要求同步更新 HTML 和 Excel。 |
| ~/Documents/job-bu | `019e1b60-b114-7142-9df2-2d7c9bc24212` | 用户追问“这个部分不是更新v27了吗”“v28是按照这个层级吗”“全局的html和excel更新了吗”，说明版本产物、层级口径和展示/明细同步很容易混淆。 |
| ~/Documents/job-bu | `019e1b60-b114-7142-9df2-2d7c9bc24212` | 助手一度按 45,341 有效原声会话当大盘分母，用户指出“大盘好像不是这么多”；随后改按一二级标签总表的 77,328 session 重算大盘提升。 |
示例文件：`out/examples/taxonomy-migration-invariant-checker.md`
### 1.2 Ark批量打标长尾诊断器
这个主题有明确价值：同一批 9335 条商品域 session 在 sample、全量跑、clean 去重和 only-errors 补跑阶段连续暴露出长尾 timeout、落盘粒度不足、error 覆盖 ok 等问题。诊断器应读取源表、jsonl 缓存、清洗结果和日志，自动判断下一步应当 finalize-only、only-errors 补跑、降并发、拉长 read timeout，还是修正 ok 优先清洗逻辑。
| 证据 | session | 片段 |
| --- | --- | --- |
| ~/Documents/job-bu | `019e2173-6169-7043-80d6-0d84fe49459d` | 用户要求 9335 个商品域 session 对齐 842 个原文场景，先本地字符 n-gram/关键词召回 top 候选，再用 Ark 判断 scene 序号或 no_match；用户要求召回放宽，候选从 top14 提到 top30。 |
| ~/Documents/job-bu | `019e2173-6169-7043-80d6-0d84fe49459d` | 80 条 sample 超过正常等待时间，实际写出 76 条；助手中断排查后改脚本：连接/读取分开超时、重试从 3 次降到 2 次、每 20 条强制落盘，长尾失败后用 only-errors 低并发补。 |
| ~/Documents/job-bu | `019e2173-6169-7043-80d6-0d84fe49459d` | 主跑结束 9335 条 clean 中 8850 条成功、485 条 error；后续发现 clean 选择最新记录会让后来的 error 覆盖之前成功 ok，修成 ok 优先，再补真正未完成的 344 条。 |
示例文件：`out/examples/ark-batch-tail-diagnostic.md`
### 1.3 客服搜索推荐方案采集器
这个主题有明确工具化价值：用户已经在真实 ByteHi/kefu 工作台里要求按商品场景关键词批量搜索并记录推荐解决方案，但执行过程被登录态、浏览器连接稳定性和搜索词召回质量反复打断。可沉淀为一个“关键词生成 -> 登录态/页面入口选择 -> 小批量搜索 -> 本地知识库补全 -> Markdown/Excel 输出”的采集器，降低后续同类客服推荐方案盘点的人工成本。
| 证据 | session | 片段 |
| --- | --- | --- |
| ~/Documents/job-bu | `019e2047-5171-7f83-b4fa-eea3ab573057` | 用户要求在 kefu.bytedance.net 客服工作台搜索框里，基于商品领域标签下的场景问题总结关键词，逐个搜索结果，把推荐解决方案记录下来，先跑十个。 |
| ~/Documents/job-bu | `019e2047-5171-7f83-b4fa-eea3ab573057` | 内嵌浏览器被统一登录页拦住，切到 Chrome 仍遇登录态问题，最后用桌面 UI 读取/操作真实页面；SSO 自动过后进入 ByteHi 工作台。 |
| ~/Documents/job-bu | `019e2047-5171-7f83-b4fa-eea3ab573057` | 批量探测超时且浏览器控制连接重置，助手改成缩小批量规模，并用页面搜索结果标题 + 本地同源客服知识库正文抽取方案；直搜不稳定的词改成更容易召回的客服搜索词。 |
示例文件：`out/examples/kefu-search-capture-workflow.md`
### 1.4 Anki牌组操作安全预览
这个主题有效，不是噪音：同一 session 里既有钢琴牌组重建/导入，又有英语概念卡红 flag 删除，中间还出现了用户纠正目标对象和 turn_aborted。问题核心不是 Anki 生成能力，而是高风险牌组操作前缺少统一的 deck-target 校验、dry-run 变更预览和可回滚证据包。
| 证据 | session | 片段 |
| --- | --- | --- |
| ~/Documents/learning-bu | `019e1f6f-b21f-7900-a5f4-c011b0ae1cd5` | 用户先要求把钢琴认音卡顺序打乱，并在背面画 C3-C5 位置图；随后多次用截图纠正视觉理解：不是单个点，而是类似钢琴键；正面是 G3 就把 G3 位置标出来。 |
| ~/Documents/learning-bu | `019e1f6f-b21f-7900-a5f4-c011b0ae1cd5` | 最终钢琴卡重导入 Anki，88 张卡保持随机顺序，背面共 21 张按音高区分的键盘图，字段匹配检查 mismatch_count=0。 |
| ~/Documents/learning-bu | `019e1f6f-b21f-7900-a5f4-c011b0ae1cd5` | 同一 session 后续用户说“红色flag都是要删除掉的卡片”，被问及对象后纠正“不是，是英语概念卡”；最终删除英语概念卡 7 张红 flag 卡，并备份 apkg 和删除报告。 |
示例文件：`out/examples/anki-deck-safety-preview.md`
### 1.5 推文日报账号源预检
这是一个稳定复现的工具缺口，不是噪音：推文日报的设计口径是从 repo-local `.claude/skills/config.json` 读取 `twitter-fetcher.users`，但多轮执行都发现配置缺 roster。当前流程虽然能靠 `.codex_tmp` 上一轮成功 raw artifact 恢复账号继续跑，但这会让账号源、排序和失败产物混入风险变成隐性问题，应该前置成显式 preflight。
| 证据 | session | 片段 |
| --- | --- | --- |
| ~/Documents/Codex/2026-04-21-https-github-com-haopenglau-skills/repo | `019e1eda-4f16-7de0-b35e-283cdae62e0c` | 每日推文总结自动化要求从 .claude/skills/config.json 的 twitter-fetcher.users 读取账号列表，并使用 SOCIALDATA_API_KEY 或 TWITTERAPI_IO_KEY 抓最近完整自然日推文。 |
| ~/Documents/Codex/2026-04-21-https-github-com-haopenglau-skills/repo | `019e1eda-4f16-7de0-b35e-283cdae62e0c` | 助手发现当前 config.json 只有 API key，没有 twitter-fetcher.users，本轮仍依赖 .codex_tmp 里修过排序的 runner 从上一轮成功 raw 里恢复账号列表。 |
| ~/Documents/Codex/2026-04-21-https-github-com-haopenglau-skills/repo | `019e1eda-4f16-7de0-b35e-283cdae62e0c` | 最终日报完成，但明确说明账号名单仍然是从上一轮成功 raw 自动恢复，不是来自当前 .claude/skills/config.json；输出 raw 和 markdown 路径。 |
示例文件：`out/examples/twitter-roster-preflight.md`
## 二、候选清单
| id | 类型 | 风险 | 审批 |
| --- | --- | --- | --- |
| `taxonomy-migration-invariant-checker` | `diagnostic-tool` | `medium` | `pending` |
| `ark-batch-tail-diagnostic` | `diagnostic-tool` | `low` | `pending` |
| `kefu-search-capture-workflow` | `tool-upgrade` | `medium` | `pending` |
| `anki-deck-safety-preview` | `diagnostic-tool` | `medium` | `pending` |
| `twitter-roster-preflight` | `tool-upgrade` | `low` | `pending` |