切换外观
curl-bagder 的弱标注
状态：从真实后续行为自动推出的弱标签，由 scripts/label_corpus.py curl-bagder 生成 labels.json。它说明这个人后来把注意力放在了哪里，不是标准答案；没有手写任何整帧批次。
手写情境的每帧都有作者批次，可以逐条比对声明。真实语料没有这种答案，但有另一种证据：Daniel Stenberg 在输入到达之后实际做了什么——回复、评审、关闭、打标签、合并，或者什么也没做；团队里其他维护者是否接手；CI 失败是否很快转绿。弱标注把这些行为整理成三类可检验的判断：哪些输入应被忽略，哪些应合成同一事项，哪些事项当时值得关注、哪几件应在高档位。
推导规则
事项。 按线程划分：GitHub issue/PR/讨论、邮件列表线程（沿 In-Reply-To 找到根）、Mastodon 上同一根帖下的对话、同一篇博客文章的评论。CI 失败归入对应 PR，推到主干的归入分支。每帧、每个事项一条标注，只看他人发来的输入；只有本人发言的事项不标。
行动。 本人的行动：GitHub 评论、评审与行内评论、关闭、重开、合并、打标签、加里程碑、指派、请求评审、标为重复、强推分支，讨论的回复与选定答案，邮件列表、Mastodon、博客上的回复。团队的行动：同类 GitHub 行动，团队成员是在别人开的线程上打过标签、关闭、指派、加里程碑或请求评审的非机器人账号。
档位。 设帧结束时刻为 T，事项在本帧的第一条他人输入到达时刻为 t。
| 弱档位 | 条件（按顺序取第一个成立的） | 建议对应的 Fold 处理 |
|---|---|---|
engaged | 本人在 (t, T+24h] 内对该事项有行动 | normal 以上 |
其中 high: true | engaged 中投入度至少为 2、在本帧排前 3 位；投入度 = 24 小时内本人行动次数，含关闭、合并、批准等决定时再加一，同分按响应快慢 | critical / high |
later | 本人在 (T+24h, T+7d] 才有行动 | normal / low |
delegated | 7 天内只有团队其他人行动 | low / trace |
noise | 7 天内无人行动，且输入全是低信息量，或全被后来的结果覆盖 | 不纳入 |
untouched | 7 天内无人行动，但有实质内容 | trace 或不纳入 |
高档位限 3 件，是因为 Fold 的 64 份预算里 high 每件占 12 份；--high-per-frame 可以调整。
应被忽略的输入。 逐条标注，带依据：
- 强依据：CI 失败在 24 小时内被同一分支、同一工作流的成功运行覆盖；或输入低信息量（机器人、状态模板、空内容、致谢附和，定义见噪音画像），所在事项无人跟进或只有团队跟进，本人也没有直接回复这一条。
- 弱依据（标
in_active_item）：事项有本人跟进，但这一条低信息量，且本人没有直接回复它，例如他没理会的 Copilot 评审。
应合并的输入。 同一事项在本帧的多条输入为一组；不同事项之间有以下关系时并为一组，并记下依据：GitHub 时间线的交叉引用（cross_referenced）、标为重复（duplicate）、PR 正文里的 Fixes/Closes/Replaces（fixes_or_replaces）、邮件列表或 Mastodon 输入直接链接到本帧的 GitHub 线程（links_to）。跨事项的组另记组档位，取成员中最高的一档，任一成员是高档位，组也是。
覆盖
| 项 | 数量 |
|---|---|
| 帧 | 28 帧全部有标注，26 帧有高档位事项 |
| 事项标注（帧 × 事项） | 400，平均每帧 14.3 |
| 档位分布 | engaged 180（其中 high 74）、later 20、delegated 103、untouched 59、noise 38 |
| 按输入条数 | 他人发来的 1271 条中，engaged 698、later 45、delegated 329、untouched 113、noise 86 |
| 应被忽略 | 409 条（32%）：强依据 264，弱依据 145；其中 CI 转绿 111 |
| 合并组 | 278 组，覆盖 1556 条输入（含本人发言）；跨事项的 47 组：交叉引用 31、交叉引用加修复关系 11、外部渠道链接 5 |
| 只有本人发言的事项 | 62，不标注 |
| engaged 的响应时间 | 中位 1.2 小时，P90 15.8 小时 |
高档位 74 件里 60 件是 GitHub 线程，13 件是 Mastodon 对话，1 件是 GitHub 讨论。
抽样核对
由构建这套规则的 Agent 读原文逐条核对，固定随机种子，未经第二人复核，只能作为粗略参考。
| 抽样 | 合理 | 部分合理 | 不合理 | 主要问题 |
|---|---|---|---|---|
| 事项档位 30 件 | 25 | 5 | 0 | 一次机械的目录迁移因“批准并请求评审”两步被排进高档位；对过时版本的报告秒回关闭，被记为 engaged；一句“好难过”的讨论回复落在 untouched 而不是 noise；一个 issue 与它的修复 PR 合成一组，线程级档位却一个 delegated、一个 later（已改为在组上取最高档位） |
| 应被忽略 20 条 | 16 | 4 | 0 | 弱依据里 3 条是本人正在推进的 PR 上的 CI 失败，可能正是他修改的原因；另一位维护者的“LGTM!”是合并信号，不该当作附和 |
| 跨事项合并 10 组 | 8 | — | 2 | 仅凭交叉引用合并的组里，有两组只是同一批 Windows 清理中的不同改动 |
强依据的忽略（CI 转绿、无人理会的机器人与模板）在抽样里没有发现错误；弱依据与“仅交叉引用”的合并要打折使用。
局限
- 事后诸葛。 行动说明注意力去了哪里，不等于当时就该如此；他常常秒回一些小事，而安全报告走私下渠道，这里看不到。
- 本人也会漏，也会在别处处理。 没有公开行动不等于没看：他可能读了 Mastodon 回复只点了收藏，可能在 IRC 或私信里回应。
untouched只表示公开渠道 7 天内无人跟进。 - 投入度偏向他自己的工作。 他自己的 PR 上会有强推、请求评审、关闭等一连串行动，因此常排进高档位；Mastodon 上的热烈闲聊也会因为多次回复而排进高档位。投入度衡量的是花了多少动作，不是事情有多重要。
- 团队的边界是推断的。 团队按“在别人线程上做过维护动作”推出；团队成员推进自己的 PR 也记为
delegated，从他的角度看是“有人在管”，但未必需要他知道。 - 线程粒度粗。 Mastodon 一个根帖下几十条回复算一件事，只要他回复过其中一条，整件事就是 engaged；逐条的取舍只能看忽略列表。
- 时间窗是约定。 24 小时与 7 天是人为阈值，周末与时区会让响应变慢；改变阈值会移动 engaged 与 later 的边界。
- 低信息量规则是英文为主的启发式，漏掉大量闲聊，也会误伤简短但关键的批准。
怎样用于评测
弱标注不能像作者批次那样逐条比对声明，适合三类可观测的检查：
- 忽略。 被测 Agent 把输入处置为 noise 或 duplicate 的集合，与强依据忽略列表比较召回与精确率；弱依据单列，不计入主指标。
- 合并。 同组输入是否进入同一声明（按
sources引用判断）；跨事项组单列。 - 档位排序。 同一帧里，
high事项是否以 high 或 critical 出现，engaged是否不低于 normal，noise与untouched是否被纳入并占用份额；用同帧事项之间的成对排序一致率，而不是要求档位完全相同。
怎样与现有的 teacher-forced 评测衔接，见决策记录。