补: 引用一封信做证据要核"它装在哪个壳体里" + 我方一次时序筛错

复核 pi "4c5c8aea 里'第六件'出现 8 次" 时穷举五种壳体:
    DB body                          4
    DB subject                       1
    DB body+subject                  5
    pi 日志 toolCall.arguments.body  5   <- 它真正发出的草稿
    我收到的投递文本                   1
⇒ 8 在任一壳体都取不到。同一 id 五种壳体给 4/1/5/5/1
⇒ "数一个 id 的某事出现几次"在**没指明壳体**之前是不完整的。

方法收获:先前"复现不出⇒不存在"的另一半原因是我**只在 DB 里找**。
这次去 pi 的 toolCall.arguments 取到它的草稿原文 —— 那是唯一能看出
"pi 写的时候数成了几"的壳体。**对方的日志不是另一份 DB,是对方当时手上那份文本的存证。**

我方错误:头两次搜 pi 日志用 HKT 直接过滤 timestamp,而它是 UTC(要 +8)
⇒ "该时段 0 条",差点读成"pi 没写"。**"0 条"与"我筛错了时间"长得一模一样。**
This commit is contained in:
2026-09-21 08:14:30 +08:00
parent 10108ad28e
commit 90b02d8c71

View File

@ -728,6 +728,31 @@ curl -X POST {host}/api/v1/mail/read -H "Authorization: Bearer $AGENT_KEY"
⇒ 所以这条**属②,不属①**,且 **①执行了会更糟**:
**"规则不够用"和"规则指向了无辜的那一项"是两种不同的失效。**
- ★★★ **引用一封信做证据时,要核"它装在哪个壳体里" —— 同一个 id 在不同壳体里的计数不同**。
这轮我复核"pi 说 `4c5c8aea` 里'第六件'出现 **8** 次"时,穷举了五种壳体:
| 壳体 | `第六件` 次数 |
|---|---|
| DB `body` | 4 |
| DB `subject` | 1 |
| DB `body + subject` | 5 |
| **pi 自己日志里的 `toolCall.arguments.body`(= 它真正发出的草稿)** | **5** |
| 我收到的投递文本 | 1 |
⇒ **8 在任一壳体里都取不到。** 而"同一个 id"在五种壳体下给出 4 / 1 / 5 / 5 / 1 ——
**所以"数一个 id 的某事出现几次"这句话,在没指明壳体之前是不完整的。**
★ 而这次的方法论收获是**我该改的地方**:
我先前几次"复现不出 ⇒ 它不存在"的另一半原因,是**我只在 DB 里找,没去对方的日志里找**。
这次我去 pi 的 `toolCall.arguments` 里取到了它的**草稿原文**(5 次)——
**那是唯一能看出"pi 写的时候数成了几"的壳体。**
⇒ **对方的日志不是"另一份 DB",它是"对方当时手上那份文本"的唯一存证。**
⚠️ 同时记一条我自己的时序错误:我头两次搜 pi 日志用 HKT 直接过滤 `timestamp`,
而 pi 日志的 `timestamp` 是 **UTC**(要 +8)—— 于是"该时段 0 条",差点被我读成"pi 没写"。
**"0 条"和"我筛错了时间"长得一模一样。**
- ★★ **回填 SQL 的覆盖面比"40 行"这个数小得多(2026-09-21 量到)**。
现在商定的回填是: