Autostockstaple Log Analysis

AutoStockStapleMain 日志分析

该 skill 仅用于 AutoStockStapleMain。

不要复用该流程到其他任务，例如 AutoStockpileMain、信用购物（credit shopping）、出售（selling），或通用 issue 故障排查。

适用范围

只要你要分析 AutoStockStapleMain 的日志，就使用本 skill（不需要用户先提出特定问题）。
并且：只要运行本 skill，就必须执行“账单重建/剩余账单时间线”的还原，而不是只在用户问到“还剩多少券/账单”时才做。

重要澄清：

• 本 skill 不适用于 AutoStockpileMain；后者是另一套任务流，应使用独立的分析流程/skill。

本 skill 重点包括：

• 购买重建：AutoStockStapleMain 实际买了什么
• 账单重建（必做）：逐步还原可见的剩余账单（券/账单）变化并建立时间线
• 跨场景账单解读：ValleyIV 与 Wuling 之间切换时如何解释账单数值
• 把日志证据映射回 AutoStockStaple 的 pipeline 节点
• 指出最佳加日志/埋点位置（instrumentation points）

主要证据

优先从目标日志目录读取：

1. go-service.log
2. maafw.log
3. 匹配的 maafw.bak.*.log
4. mxu-tauri.log
5. 当需要运行时 override 时读取 mxu-web-YYYY-MM-DD.log

代码上下文（用于理解任务语义与节点含义）：

• assets/resource/pipeline/AutoStockStaple/ValleyIV.json
• assets/resource/pipeline/AutoStockStaple/Wuling.json
• assets/resource/pipeline/AutoStockStaple/General/Item.json
• docs/en_us/developers/custom.md

工作流

0. 输出契约（必产物）

无论用户具体问什么，运行本 skill 的输出里都必须包含：

• 实际购买顺序（以及“识别到但未购买”的解释，如有）
• 事件时间线
• 账单（券/账单）时间线（基于 CurrentStockBillText 的逐步重建）

1. 锁定任务实例

先定位精确的 AutoStockStapleMain 任务实例。

搜索：

• AutoStockStapleMain
• task_id
• Tasker.Task.Starting
• Tasker.Task.Succeeded
• task end: [cb_detail={"entry":"AutoStockStapleMain"...

注意：

• maafw.log 可能发生了轮转（rotated）。
• 若目标时间点在 maafw.log 中缺失，改去检查 maafw.bak.*.log。
• 不要把其他任务的 task_id 混入本次分析。

2. 还原实际购买

购买真相不能只看商品 OCR 候选，也不能只看进入买入任务。

AutoStockBuyItemValleyIVTask / AutoStockBuyItemWulingTask 只表示“识别到候选商品并进入是否需要购买的判定流程”，不直接等价于“实际已购买”。

先做强制检查：

• 先按目标 task_id 缩小范围，只跟踪本次 AutoStockStapleMain 的事件。
• 优先在已经命中的那一个 maafw*.log 文件内继续向后追踪，不要只看命中的第一小段上下文。
• 如果搜索结果发生截断、分页，或只返回部分命中，不能直接下“没有购买”的结论，必须继续分页或缩小到命中的 maafw*.log 文件重搜。

在 maafw*.log 中搜索：

• Node.Action.Succeeded.*AutoStockBuyItemValleyIVTask
• Node.Action.Succeeded.*AutoStockBuyItemWulingTask
• AutoStockStapleQuantityControl
• AutoStockStapleQuantityControl.*Buy
• AutoStockStapleQuantityControl.*Exclude
• AutoStockStapleQuantityControlConfirmBuy
• AutoStockStapleQuantityControlAction

每次成功点击里都会包含 box=[x,y,w,h]。

随后在附近查找 AutoStockInStapleItemName 的 OCR 结果，并把“点击框（box）”与“OCR 的商品框（box）”做一一对应匹配。

这样才能得到“候选商品名称”。

不要把所有 OCR 候选都当成“已购买”。

• AutoStockBuyItem(ValleyIV|Wuling)Task 动作成功，只能说明“进入候选商品的数量控制流程”。
• 必须继续在同一 task_id 下向后追踪命中的具体物品子节点，例如 AutoStockStapleQuantityControlEchoingRemedy。
• 仅当对应的 AutoStockStapleQuantityControl<Item>Buy 分支识别成功，并继续走到其后的 AutoStockStapleQuantityControlAction / AutoStockStapleQuantityControlConfirmBuy 成功路径时，才把该商品标记为“实际已购买”。
• 如果 AutoStockStapleQuantityControl<Item>Buy 未命中，而 AutoStockStapleQuantityControl<Item>Exclude 成功，则应标记为“识别到该商品，但判定为当前不需要购买”，不能记入购买列表。
• 如果只看到 AutoStockStapleQuantityControl<Item> 命中，但后续 Buy / Exclude 分支未查全，结论必须保持为“证据不足，需继续向后追踪”。

负结论保护规则

只有满足以下全部条件，才能得出“本次没有购买”的结论：

• 对目标 task_id 所在的全部相关 maafw*.log 完成检索。
• 未发现任何实际走通 AutoStockStapleQuantityControl<Item>Buy 并完成后续购买确认的证据。

如果已经发现 AutoStockBuyItem...Task 的 Node.Recognition.Starting， 则必须继续检查同文件后续日志，直到确认以下至少一种结果：

• Node.Action.Succeeded
• Node.Action.Failed
• 任务结束
• 明确切换出该节点并进入其他分支

如果已经发现 AutoStockStapleQuantityControl<Item> 或其 Buy / Exclude 分支的 Node.Recognition.Starting， 则同样必须继续向后检查，直到确认以下至少一种结果：

• AutoStockStapleQuantityControl<Item>Buy 成功并继续进入购买确认路径
• AutoStockStapleQuantityControl<Item>Exclude 成功
• Node.Action.Failed
• 任务结束
• 明确切换出该节点并进入其他分支

禁止仅依据以下局部证据直接下结论“没有购买”：

• Node.Recognition.Starting
• 某一次 Node.Recognition.Failed
• 单个被截断的搜索片段

3. 还原剩余账单并建立时间线

逐步的剩余账单使用：

• AutoStockCurrentStockBill
• CurrentStockBillText

典型信号：

• OCRer.cpp ... CurrentStockBillText ... "text":"4153万"

解读规则：

• 这是该次识别时屏幕上可见的剩余账单数值。
• 如果某次购买点击发生在该次识别之后，把该值视作“购买前的剩余账单”。
• 如果购买之后出现了下一次 CurrentStockBillText OCR，把下一次数值视作“上一次购买后的最新可见剩余账单”。
• 必须构建完整时间线，而不只是购买列表。
• 时间线里需要包含：任务开始、场景切换、商品点击、账单 OCR 点位、以及任务结束。

跨场景账单解读规则

AutoStockStapleMain 可能在 ValleyIV 和 Wuling 之间切换。

当任务发生场景切换时，不要假设“账单数值口径与上一场景完全可直接比较、可当作同一账本连续相减”。

默认解释：

• ValleyIV 与 Wuling 可能使用不同的账单类型/券种口径。
• 若大额账单变化恰好发生在场景切换附近，优先解释为“场景切换导致账单类型口径变化”，而不是“某一个商品消耗了异常巨大数量”。
• 除非日志明确证明“购买的数量与单价”等信息，否则不要把多百万的差值直接归因到某一单购买。

当出现这类情况时，需要在结论中明确写出：

• 大额跳变来自“从某一场景账单口径切换到另一场景账单口径”
• 因此跨场景的数值不应被当作同一种券的连续流水账本来做简单加减推导

优先使用时间线表：

如果最后一次购买之后没有更晚的 OCR 识别结果，需明确说明“最终购买后账单不可用/无法从当前证据得到”。

同时提供事件时间线：

4. 区分 AutoStockStaple 与 AutoStockpile

AutoStockpileMain 是另一套任务。

不要把 AutoStockpileMain 的内容合并进 AutoStockStapleMain 的最终购买结果。

快速区分：

• AutoStockpileMain：go-service 中 autostockpile 的货物礼包/套装选择流程
• AutoStockStapleMain：由 pipeline 节点（如 AutoStockBuyItemValleyIVTask、AutoStockBuyItemWulingTask）驱动的稳定需求物资购买流程

如果用户询问的是 AutoStockStapleMain 前后某段时间范围，你可以提到相邻出现的 AutoStockpileMain 活动，但必须把它与 staple 购买列表分开。

5. 把证据映射回 pipeline

用这些节点来解释行为：

入口与分支选择

• AutoStockInStapleValleyIV
• AutoStockInStapleWuling

它们决定本地搜索循环走向：

• 无法继续买分支
• 买入商品分支
• 售罄分支
• 滑动分支

买入分支

• AutoStockBuyItemValleyIVTask
• AutoStockBuyItemWulingTask

它们是“识别到候选商品并进入后续购买判定”时的最佳 pipeline 节点。

原因：

• 它们同时满足：

  • AutoStockInStapleItem
  • AutoStockInStapleItemDiscounts
  • AutoStockInStapleItemName

• box_index 指向商品名 OCR 的结果

• 识别成功之后立刻发生点击

• 它们的 next 会进入 AutoStockStapleQuantityControl，因此这里只能确定“候选商品是谁”，不能单独作为“已购买”的最终证据

数量控制分支

• AutoStockStapleQuantityControl
• AutoStockStapleQuantityControl<Item>
• AutoStockStapleQuantityControl<Item>Buy
• AutoStockStapleQuantityControl<Item>Exclude
• AutoStockStapleQuantityControlConfirmBuy

它们决定“是否真的需要买”以及“后续走买入还是排除”。

解读规则：

• AutoStockStapleQuantityControl<Item> 命中：说明当前候选商品已被映射到具体物品规则。
• AutoStockStapleQuantityControl<Item>Buy 命中：说明该商品通过数量阈值判定，允许继续购买。
• AutoStockStapleQuantityControl<Item>Exclude 命中：说明该商品被判定为无需购买，应从候选集中排除。
• 只有 Buy 分支继续走到其后的购买动作/确认路径，才算实际购买。