切换外观
curl-bagder 的噪音画像
状态：由 scripts/build_corpus.py noise curl-bagder 生成的 noise.json 整理，2026-10-14 抓取。原文删除或编辑后重建，数字会小幅变化。原文不入库，下文只引极短的通用片段。
窗口是 2026-08-03 至 08-16，主人公是 curl 维护者 Daniel Stenberg；来源与范围见语料说明。手写情境指 prototype/data/story/scenario.mjs 的 37 帧。
一眼看差别
- 量差一个数量级。 两周 1676 条，手写情境 112 条。每 12 小时一帧，平均 60 条、最多 128 条，每帧原文约 2 万字符；手写情境每帧 3 条、约 100 字。
- 三分之一是低信息量。 他人发来的输入里 33% 是机器人、状态模板、空内容或单纯致谢，这还只是文本规则抓得到的部分；手写情境的同类输入是作者特意放进去的 21 条。
- 重复是常态。 13% 的输入与 7 天内更早的一条近似重复（Copilot 的固定开场、同一提交触发的多条 CI 失败、同一段话既发评审又发评论）；手写情境是 0。
- 同一件事被说很多次，而且跨渠道。 每个事项中位 5 条、最多 79 条输入；HTTP/2 服务器推送、Windows 回环连接卡顿、性能测试这三件事都同时出现在邮件列表、Mastodon 与 GitHub 上，说法并不一致。
- 长短悬殊。 中位 134 字符，P90 1208 字符，最长 5.6 万字符，76 条超过 2000 字被截断；手写情境最长 67 字。手写情境是中文，字符更密，但 P90 仍相差 25 倍。
- 时间不整齐。 中位间隔 3.4 分钟，362 次与上一条落在同一分钟内；8% 在当地凌晨 0–7 点到达。手写情境的消息按公式均匀铺开，夜里没有输入。
- 会过时、会被改写。 53 条评论落在已关闭的线程上；84 条发出后被编辑过，我们看到的是改后的版本；7 条被 GitHub 折叠。
并排指标
| 指标 | 真实语料 | 手写情境 |
|---|---|---|
| 输入条数 | 1676 | 112 |
| 帧数；每帧均值 / 中位 / 最多；空帧 | 28；59.9 / 53.5 / 128；0 | 37；3.0 / 3 / 9；3 |
| 每帧原文字符 中位 / 最多（截断后） | 21,324 / 50,284 | 101 / 376 |
| 渠道数（前缀归并） | 5 | 25 |
| 作者：他人 / 本人 / 机器人 / 自动化账号 | 965 / 405 / 282 / 24 | 65 / 26 / 13 / 8 |
| 不同作者；前 5 位占比 | 286；62% | 27；59% |
| 低信息量合计（占全部；占他人发来） | 520（31%）；33% | 21（19%）；24% |
| 其中机器人 / 模板通知 / 空内容 / 致谢附和 | 306 / 153 / 20 / 41 | 21 / 0 / 0 / 0 |
| 核心文本完全重复（其中 ≥30 字） | 171（117） | 0（0） |
| 近重复（≥30 字，7 天内 4-gram Jaccard ≥ 0.6） | 215（13%） | 0（0%） |
| 事项数；只出现一次的 | 221；13 | 13；4 |
| 每事项输入数 中位 / P90 / 最多 | 5 / 18 / 79 | 8 / 15.8 / 17 |
| 跨渠道出现的事项（真实语料含 CI 失败归入 PR） | 23 | 8 |
| 非 GitHub 渠道里直接链接 GitHub 线程的输入 | 10 | 0 |
| 长度（字符）P10 / 中位 / P90 / 最长 | 33 / 134 / 1208 / 56,552 | 18 / 35 / 47 / 67 |
| 超过 2000 字被截断；短于 20 字 | 76；45 | 0；14 |
| 到达间隔（分钟）P10 / 中位 / P90 / 最长 | 0.4 / 3.4 / 27.1 / 412 | 3 / 13 / 736 / 1400 |
| 同一分钟内连续到达 | 362 | 0 |
| 当地 0–7 点到达 | 139（8%） | 0 |
| 发出后被编辑过 | 84 | 0 |
渠道分布：GitHub 1041（评论 367、评审 335、新 PR 129、状态变化 172、讨论 23、新 issue 15）、Mastodon 464、CI 152、邮件列表 15、博客评论 4。手写情境的 25 个渠道名各只有几条，真实语料集中在少数渠道、每个渠道很厚。
本人的 405 条（他的评论、评审、关闭、Mastodon 帖子、邮件）也保留为输入，与手写情境里“用户消息”的地位相同；标注时不把它们当作待判断的来信。
噪音长什么样
| 类型 | 量 | 形态 |
|---|---|---|
| 评审机器人 | Copilot 116 次评审，其中 28 次只说没有新意见；Augment 3 条、代码扫描 1 条 | 每次以同样的“Pull request overview”开场，长度常过千字 |
| CI 失败通知 | 152 条，来自 89 个提交，单个提交最多 10 条 | 111 条在 24 小时内被同一分支、同一工作流的成功运行覆盖：很快修好或重跑转绿 |
| 自动化测试账号 | testclutch 24 条 | 资料自称机器人、类型却是普通用户；内容多为“这个失败大概不是 PR 的错” |
| 依赖更新机器人 | renovate 9 条 | 版本号表格 |
| 状态模板 | 他人关闭、合并、重开 72 条；本人关闭 78 条 | 只说明状态变了，原因要回到线程里找 |
| 致谢与附和 | 41 条 | “Thanks!”“LGTM!”、行内评审里的“ack” |
| 空内容 | 20 条 | 只有 @提及、表情或附件，如“@bagder 😊” |
| 社交回复 | Mastodon 上他人 350 条 | 玩笑、鼓励、跑题的追问；文本规则几乎抓不到，弱标注里多数无人回应 |
| 低质量贡献 | 例：一个 AI 生成的“加固”PR | 他用一句话关闭，认为毫无意义 |
| 迟到与改写 | 已关闭线程上的评论 53 条，编辑过 84 条，被折叠 7 条 | 当时看到的内容与现在抓到的可能不同 |
口径不一的例子。 8 月 5 日他在邮件列表和 Mastodon 同时问“还有人用 HTTP/2 服务器推送吗”，随后在邮件列表说准备 2027 年移除，并在 Mastodon 回复别人“HTTP/3 没有服务器推送”；紧接着有人引用 RFC 9114 的“Server Push”一节反问。同一主题在邮件列表 3 条、Mastodon 7 条、GitHub 8 条、CI 6 条，四个渠道的说法彼此对不上：有人说设计里依赖这个功能，有人质疑事实，PR 在讨论另一处细节。性能测试一事也分散在 GitHub 讨论、邮件列表、博客与 Mastodon 四处。
被替代与重复提交。 同一问题常有前后两个 PR（如一个 PR 说明“replaces”另一个），同一段评审意见会作为行内评论和普通评论各发一次；这些都按原样保留。
指标口径
- 作者类别。
self是本人；bot是 GitHub 机器人账号（类型为 Bot 或名字以[bot]结尾）、CI 通知与 Mastodon 标为机器人的账号；automation是类型为普通用户、但公开资料自称机器人或自动化的账号。手写情境按同一口径：程序发出的提醒为bot，群发资讯与营销为automation。 - 低信息量。 依次判断：作者是
bot或automation；状态模板（关闭、合并、重开，不含请求评审与批准）；去掉引用、签名、链接、@提及、“文件:行号”前缀后没有文字；或 40 字以内的致谢与附和（如 thanks、LGTM、ack、any update）。只是下限：闲聊、跑题和过时内容不在其中。 - 重复。 “核心文本”是去掉引用、签名、链接与提及后的小写文本。完全重复数一条与更早某条的核心文本相同；近重复只看 ≥30 字的核心文本，与 7 天内更早的输入比较 4 字符片段的 Jaccard 相似度。
- 事项。 真实语料按线程：GitHub issue/PR/讨论、邮件列表线程、Mastodon 帖子下的对话、博客文章；CI 失败归入对应 PR，推到主干的归入分支。手写情境按作者标注的第一个关联条目。
- 长度 按 Unicode 字符计，含 Markdown 与引用；间隔 是相邻两条输入的到达时间差。
局限
- GitHub 通知按公开事件重建；他实际开着哪些通知、怎样过滤，都不可见。
- Mastodon 只覆盖他自己帖子下的对话，线程之外提到他的帖子需要登录才能查，没有收录。
- 文本规则只给低信息量的下限；更接近真实的“噪音比例”来自他后来的行为，见弱标注：他人发来的 1271 条中 409 条应被忽略。
- 对照来源 enron-steffes-j 的噪音形态不同：机器人少、长转发和整段引用多。