「开源之道」 2026-11-04 搜集事件和材料

「开源之道」昨日阅读 · 2026-11-01

今天这一份，落在同一条断层线的第四个剖面上：准入之后，谁来看见它。

① 前三天我们依次看到了三种作答。 10-31 Pico CSS 用「退出」作答（AI 让这个东西不再必要）；11-03 Django 用「程序」作答（13 行 PR 模板里的必填 AI 声明勾选框）；同一天的 vLLM / Agent Skills 则暴露了「规则写了但没人值班」。今天补上第四种——「规则写了，值班的人也在，但他一个人值完了全部。」

② 先看 CPython 这一周的实际数字。 过去 7 天（2026-10-28 → 11-04），cpython 仓库合并 255 个 PR；其中 92 个来自回移机器人 miss-islington（36%）。剔除机器人后剩下 163 个，来自 47 位不同作者。而这份人工合并里，Gregory P. Smith 一个人合了 55 个（33.7%）——他 55 个里又有 27 个是 [3.14] / [3.15] 的回移，剩下 28 个是 main 分支的真实改动。

③ 再看这 28 个是什么。 抽查 11-01 那天他连发的 12 个 main 提交：minidom getElementById() 重复 ID 稳定化、configparser clear() 改成线性时间、plistlib 二进制写入器用重复计数 struct 格式、idna 增量解码器前导空标签、IPv6Interface.is_unspecified 对 IPv4-mapped 地址、ShareableList 打包失败时解除新块、zoneinfo 拒绝非法 TZif 缩写块大小、zipfile.is_zipfile() 对 file-like 对象抛 ValueError、uu 编解码器要求 begin 行八进制模式、punycode 拒绝前导分隔符、gzip CLI 像 gzip(1) 一样替换输出文件。这是一份教科书式的「维护者清扫清单」：全部是边界条件、畸形输入、静默错误，全部是没人提需求、没人发 PR、只能靠人一条条看出来的东西。

④ 最要命的一条证据是这样的。 gh-161110（minidom 重复 ID 查询顺序不稳定）——issue 由 gpshead 本人在 11-01 18:36:10 创建，同一分钟的 18:36:19 提交了 PR #161111，41 分钟后 19:18:22 自合并，18:36:12 打了两个标签并 self-assign。 整个过程 0 条评论、0 个 reviewer。同一晚 #161113（shutil.make_archive 把 zip 打进自己）和 #161107（plistlib 写入器）同样是 issue + PR + 自合并一气呵成，两条 review 记录都是空的。

⑤ 而制度的另一头长这样。 当前 CPython 未关闭 PR 2,299 个；1,070 个创建于 2026-05-01 之前（积压超过 6 个月）；128 个已经挂着 awaiting merge 标签——按标签定义，那是「已批准、只差合并」的意思，它们在等一个有权点按钮的人。同时 python/peps 那边，Marc Mueller 的 PEP 823（?. / ?[ ]）与 PEP 824（?? / ??=）在 11-01 一口气改了 129 + 66 行，Guido 作为 sponsor 在 03:10 和 03:20 UTC 连续两次 APPROVED，期间只留了一条 3 个字的评审意见：objected -> objects（改个语法笔误）。

所以今天真正想说的是：一套健康的公地制度，不该只由「谁有权盖章」与「谁有劲扫地」两栏构成，而没有第三栏——「谁来看见那些既不需要盖章、也不够资格叫扫地的东西」。 那 1,070 个过期 PR 不是没人管，是没有一个角色的 KPI 是「把它们一条条看过去」；那 28 个边界条件修复也不是被分配的，是某个人恰好还有力气在 11 月 1 日的晚上把清单从头扫到尾。奥斯特罗姆说公地需要「监督」作为第八条设计原则——她没说监督可以被自愿承担，更没说可以被一个人承担。当一个公地的监督职能以「某人今天还有力气」为供给曲线，它在统计上看起来是完全健康的：合并数漂亮、积压有标签、流程有文档。 这就是为什么制度分析必须去看那些没有标签、没有评论、没有 review 记录的动作——它们不在任何看板上。

📄 最新开源研究论文

arXiv 通道说明：今日 arXiv 检索七次查询全部正常返回、无报错，未回退 OpenAlex 充当 arXiv：宽口径（cs.SE OR cs.CY + abs:"open source"，date_from=2026-10-28）22 条、治理向叠加 3 条、供应链向 7 条、econ.GN 口径 15 条、跨类目治理 10 条，去重后约 45 篇候选。 去重核对：已比对 10-26 → 11-03 九天简报的 arXiv 编号全集（2610.34435、2610.34933、2610.36229、2610.36603、2610.37332、2610.37734、2610.38054、2610.38167、2610.38617、2610.29199 等）。候选中有 41 篇为已报道或与开源治理无关（量化金融、氢能市场、合成调查样本、医疗注册库等），逐条剔除。今日入选 2 篇此前未覆盖的新论文，全部经摘要核对。 补充通道：CrossRef（2026-11-02 起 created）与 OpenAlex 两轮检索命中 1 篇确属制度经济学方向、且本报从未报道的论文（SSRN，第 3 条）——虽发表于 2026-01，但未被本报任何一期收录，且与今日主线直接相关，故按「首次覆盖」纳入并标注日期，以免误认为新论文。

1. 高能物理之外的另一块公地：一个要求「提交者自带可复现证据」的贡献标准

  • 标题：Perspective on AI and quantum open-source software
  • 作者：Changhao Li、Bradley A. Chase、Veena Vijayakumar、Mathys Rennela、Alessandro Cosentino、Naixu Guo、Sebastian Hassinger、Farrokh Labib、Seun Omonije、Patrick Rebentrost、Vincent Russo、Nathan Shammah、William J. Zeng、Ben Castanon（14 人，跨 IBM / Unitary Fund / 多所大学）
  • 链接：arXiv:2610.38049（quant-ph / cs.SE / physics.soc-ph，2026-10-27 提交）
  • 摘要：量子开源软件是量子科学的基础设施，AI 正在重塑它的能力与开发方式。但量子软件的大规模验证极其困难，而 AI 生成的贡献会进一步加重维护者负担。作者以三条证据链展开：公开仓库、他们自办的 5 届量子开源黑客松所覆盖的 110 个仓库记录、以及 1,600+ 人的社区调查。分析把「自动验证能力的局限」与「量子软件维护者的评审负担」直接连起来，提出一套要求贡献者为自己的改动附上可复现证据的验证实践与贡献标准，并维护一个开源配套仓库供项目采纳和迭代。
  • 为什么与开源之道相关：这是本报连续追踪的「AI 让供给曲线暴涨、而核验曲线不动」这条线的第三个独立样本——10-30 是 Anthropic 的 29,432 条候选漏洞（安全领域）、10-28 是 GSoC 的 mentor 断层（教育管道）、今天这篇是量子计算。三个完全不同的领域给出同一个结论：瓶颈不在产出，在核验；而核验没有规模效应。 更关键的是它给出的不是抱怨，而是一条可被写进 CONTRIBUTING 的规则。
  • 开源之道视角点评：这篇的做法值得逐字记下——它没有说「禁止 AI 生成」，它说的是「你的改动必须带可复现的证据」。这是把不可验证的属性（你用了什么工具）替换成可验证的属性（我能不能跑出来）的第二次尝试：11-03 Django 用声明（签字承诺我核验过）、内核 10-24 用删标签（只要结果负责），这篇用证据。三条路其实是同一个方向的三个成本档位——声明几乎零成本但只对诚信者有效；证据成本高但对所有人有效；删标签成本最低但把风险全推给维护者。方法论上还有一层：它的样本来自自己办的 5 届黑客松的 110 个仓库——这提醒我们，评估「AI 对开源的冲击」时，最容易的错觉是拿 GitHub 全量数据当样本；而这批数据之所以能采集，恰恰因为作者是社区内部的人。能观测到什么样的公地，取决于你在不在那个公地里。

2. MCP 的「破坏性工具审批」：规范写了，但两端都不兑现

  • 标题：When Neither Side Confirms: Destructive Tool Approval Across MCP Servers and Hosts
  • 作者：Junwei Yao、Zike Yang、Zhijun Wang、Yongxi Zhou、Wenbo Ye
  • 链接：arXiv:2611.02527（cs.SE / cs.CR，2026-11-02 提交）
  • 摘要：LLM agent 通过 MCP 调用会删数据或转钱的工具。规范要求「有一个人可以拒绝工具调用」，但把机制拆给了两端：服务端可以标注工具、或通过宿主向用户提问（elicitation）；宿主应用决定要不要弹窗。作者从源码测了两端：在官方 MCP 注册表的 1,000 仓库抽样中，约 90% 的破坏性工具没有服务端确认（95% CI 82–95），且多数在宿主无法转达问题时直接放行，或回退到一个模型自己就能设的开关。41 个流行的开源宿主与 agent SDK 里，32 个默认没有审批步骤（25 个应用里 16 个）。把抽样的破坏性工具与这些应用配对，60.7% 的组合默认没有任何强制执行的人工批准。经四个 agent SDK 测试，五个低成本模型中有四个在 960 次运行里执行了 479 次注入的删除操作。反事实测算：若宿主对每个未标注为只读/非破坏性的工具都弹窗，无审批比例可降到 5.4%；若只实现「普遍 elicitation 支持」，仍剩 56.7%。
  • 为什么与开源之道相关：这是「规则归属清晰、执行主体为空」的又一个精确标本——和我们 11-02 在 Agent Skills、10-28 在 Argo CD 外围项目上看到的结构完全同构。规范把责任分配给了两端（谁都可以不做什么），却没有指定哪一端必须做什么。用奥斯特罗姆的语言：边界规则（谁在什么位置）写清楚了，监督规则（谁检查）写清楚了，但抵制裁量（不履约的后果）没有。 一条可以被两端各自解释为「不是我」的规则，在制度上等于没有规则。
  • 开源之道视角点评：这篇最有价值的不是 60.7% 这个数，而是那个反事实拆分：修「普遍 elicitation」只能把 60.7% 降到 56.7%——几乎没用；真正有效的是把默认值从「白名单只读」翻成「黑名单默认弹窗」，一步降到 5.4%。这是一个纯粹的默认值（default rule）设计问题，不是能力问题。 制度经济学里最便宜的制度改进从来都是改默认值：它不要求任何人变好，只要求改变「什么都不做」的后果。把这个结论平移回开源治理：当项目说「我们没有禁止 AI 生成贡献」，它实际执行的默认值就是「全部接受，直到有人反对」——而反对方需要付出评审成本，接受方不需要。 Django 11-03 加的那个必填勾选框，本质上就是把默认值从「不声明」改成「必须选一个」，这才是它真正的制度创新，而非那条规则本身。

3. 【制度经济学 · 首次覆盖】当「制度合规成本」被写进公地治理模型

  • 标题：Cost-Driven Governance in Open-Source AI Innovation Commons: Comparative Evidence from Jittor and OpenHarmony（开放源代码 AI 创新公地的成本驱动治理：来自计图与 OpenHarmony 的比较证据）
  • 作者：Zhe Wang（王哲，北京航空航天大学人文与社会科学高等研究院 / 公共管理学院）
  • 链接：SSRN 7196882，DOI 10.2139/ssrn.7196882，48 页
  • 日期说明：CrossRef 记录为 2026-01-01，不是本周新论文。本报此前从未收录（经全库检索确认），按「首次覆盖」纳入。
  • 摘要：AI 创新日益依赖开源协作，维持开源 AI 生态成为关键的治理挑战。既有研究多聚焦参与激励、组织结构与社区协调，对塑造协作可持续性的成本动态关注不足。作者以「创新公地」视角，把开源 AI 社区概念化为创新成本持续累积 → 公地治理适应 → 创新再生产的动态系统，通过对**计图（Jittor，清华发起）**与 OpenHarmony（华为发起，开放原子基金会治理）的对比案例，用三轮定性编码与跨案例比较，识别出两条路径依赖的创新成本演化轨迹，并提出治理机制通过成本分担、成本转化、成本吸收三种方式把创新成本「内生化」的机制，最终给出「创新成本累积—公地治理适应—创新再生产—创新成本再累积」的动态框架。
  • 为什么与开源之道相关：它是少数把「制度合规成本」当作公地治理内生变量的中文语境研究。威廉姆森框架里，合规成本属于 L2（制度环境）向 L3（治理机制）的传导项；这篇论文实际上是把这个传导项显式建模，并声称治理机制可以把它「吸收」进公地内部。这个提法与奥斯特罗姆的「嵌套企业」和「集体选择安排」有亲缘关系，但结论指向不同——奥斯特罗姆讲的是公地成员自下而上制定规则以降低交易成本，这里的「成本吸收」在案例里是由一个掌握行政资源的主体把成本吃下去。
  • 开源之道视角点评：这篇论文的方法本身值得学——它承认成本，不回避成本，这比大量「开源如何提升创新能力」的颂歌式研究诚实得多。但它的框架里有一个必须点出的同义反复风险：如果「治理适应」被定义为「把成本内生化成功」，而成功与否又由案例结局来判定，那么框架就不再是解释变量，而是结论的复述。更值得追问的是「成本吸收」的那笔钱从哪来、要不要偿还：假如成本是被行政资源吸收的，那这个「公地」的可持续性就不取决于成员的自组织能力，而取决于外部资源的持续注入——那是另一个制度类型，不该共用「公地」这个名字。制度的强度不等于公地的强度，一个从不担心搭便车的公地，可能只是因为它没有成员。

📰 开源动态摘要

1. Linux Foundation 的 GenAI 调查：编码时间减半，但 25% 的进队 PR 被判「AI slop」

  • 来源：Linux Foundation Research 官方新闻稿（2026-10-20 发布）、Phoronix《Linux Foundation Estimates 25% Of New Pull Requests To Be Low-Quality AI Slop》（2026-10-20）

  • 摘要：LF Research 的新调查给出两个方向相反的读数：生成式 AI 把开源项目的编码时间砍掉了约一半；但约 25% 进入队列的新 PR 被维护者判定为低质量的「AI slop」。该调查与 LF 的年度 OSPO / 欧洲开源面板同属 LF Research 产品线（后者带 DOI 与 Zenodo 开放数据），但本期的问卷口径与样本量在新闻稿中未完整披露。

  • 开源之道点评：这个 25% 的读数必须放在分母里读。「编码时间减半」与「25% 的 PR 是垃圾」不是两条独立的新闻，它们是同一条曲线的两端：如果单位时间产量翻倍，而合格率从接近 100% 掉到 75%，那么有效产出几乎没变，评审工作量增加了约 33%。这就是本报连续四天在追踪的那个守恒量——AI 削掉的成本，不在系统里消失，它从「写」转移到了「读」。 而系统里唯一没有跟着翻倍配置的资源，是那个「读」的人。

    需要提醒一句方法论：这条数据由基金会新闻稿给出，样本口径不明，且发布在 LF 自家的旗舰叙事时段。 它能用来说明「维护者感知到压力」，不能用来做精确的政策推算。把它和 Anthropic 10-30 的 29,432 → 6,123 → 513 那组硬数字并排放，才构成一个完整判断：前者是感知，后者是账。

2. 「别盲信开源，自己拿回来」：企业侧的一次立场翻转

  • 来源：Techzine Global《“Don’t blindly trust open source, take control”》（2026-11-03）

  • 摘要：该文主张企业不应「盲目信任」开源组件，而应把关键依赖的控制权收回自己手里——包括对上游代码的自主审计、对上游变更的自主评估，以及保留可自行维护的分支能力。这是过去半年「AI 让上游不可信」叙事在企业侧的一次公开表达。

  • 开源之道点评：这句话本身没错，但它的隐含成本结构值得拆开。 「take control」在企业侧通常指三件事：fork 能力、内部补丁流水线、以及把上游差异持续回移的工程。前两件是一次性投入，第三件是永续支出——而正是这第三件，构成了 Linux 生态过去三十年最大的隐性效率红利。当每一家企业都自己拿回控制权，行业的总交易成本会上升；而上升的部分，不会有人记在「安全」这个科目下。

    更根本的一层是：这篇文章把「信任」当成了可选项。但开源从来不是靠「信任上游的善意」运转的，它是靠可验证性运转的——源代码可见、变更可追溯、许可证可据以行动。「别盲信」不是对开源的批评，它恰恰是对开源唯一正确使用方式的描述。 真正该担心的不是企业怀疑上游，而是企业怀疑上游之后，把「自己看」换成了「买一个白名单」——那才是把可验证性重新外包出去。

🔍 Project Pulse

CPython（python/cpython，77,805 ★、37,168 fork，PSF 治理，指导委员会 5 人制）

选定理由：（a） 它是本报监控池里唯一同时具备「成熟宪章治理」与「大规模日常维护现实」的项目——5 人指导委员会、PEP 流程、回移机器人、回移标签构成一套完整的 L2/L3 样本；（b） 上周同一时间 PEP 823/824（?. 与 ?? 操作符）的推进刚好给出「决策层如何运转」的可核证据；（c） 它与 11-03 的 Django 构成两种截然不同的准入代价模型，可直接对照。

【L1 · 大版本发布】

  • 版本线实测（GitHub tags，2026-11-04）：最新 tag 序列为 v3.16.0a1（开发期 alpha）→ v3.15.2 → v3.15.1 → v3.15.0。也就是说 3.15 已进入稳定维护期，主线已切到 3.16 alpha。分支结构：远端仅 3.11 / 3.12 / 3.13 / 3.14 / 3.15 / main 六条——3.16 直接在 main 上开发，没有独立分支，这是 CPython 一贯的「主线即下一版」节律。
  • 回移密度：3.15 分支最近 5 个提交全部是 [3.15] gh-xxxxx: ... (#16xxxx) 形式的回移，时间跨 2026-11-03 一天内（07:39 / 08:57 / 10:27 / 15:08 / 17:47）。同一个 bug 在 main 修完，几小时内落 3.15，再落 3.14——这是它有 miss-islington 的全部原因。
  • 提交活跃度（实测）：近 7 天 118 次提交（committer-date > 2026-10-28）；近 90 天 1,529 次。Doc/whatsnew/3.16.rst 已 62KB 且在 11-03 仍在更新。

【L2 · 治理结构变化】（今日核心）

  • 宪章层：peps/pep-0013.rst（Python Language Governance，Status: Active）明载 2026 任期指导委员会 5 人：Barry Warsaw、Donghee Na、Pablo Galindo Salgado、Savannah Ostrowski、Thomas Wouters，依据 PEP 8107 的选举结果。章程自述其权威原则是「The council has broad authority, which they seek to exercise as rarely as possible」——权威宽阔、但刻意少用。这是一条极罕见的自我约束型宪章条款：它把「不干预」写成了治理美德。
  • 决策层实况（PEP 823/824）：Marc Mueller 于 9-21 提交 PEP 823（None-aware 访问操作符 ?. / ?[ ]）与 824（None-coalescing ?? / ??=），Guido van Rossum 任 sponsor。10-20 Guido 亲自把 How to Teach This 扩写成 mini-tutorial（PR #5177，PR 正文写着「Don’t merge until @cdce8p（PEP 作者）has approved this」——sponsor 改提案要等作者点头，方向是反的）；10-31 18:16 作者本人提交 129 行大改（新增 none-aware binary operators 等被拒想法、Not pythonic or not explicit enough 等常见反对）；11-01 03:10 与 03:20 UTC Guido 连续两次 APPROVED，全程只留一条评论：objected -> objects（改一个语法笔误）；11-01 15:08 更新 post-history。
  • 读法：这是一个「讨论在别处、决议在仓库」的两层结构。 Discussions-To 指向 discuss.python.org（PEP 823 那个帖子已到 117 楼），真正的辩论发生在论坛；仓库里的 PR 只承载最终文本落盘与流程留痕。所以「PR 只有 1 条评论就合并了」不等于没人讨论——这一点必须和 Django（讨论在 PR 上）区分开，否则会得出完全错误的制度判断。

【L3 · 新人加入与社区活力】

  • 人工合并的集中度（实测，2026-10-28 → 11-04）：窗口内合并 255 个 PR，其中 92 个来自 miss-islington 回移机器人（36.1%）；剔除机器人后 163 个，来自 47 位不同作者。gpshead（Gregory P. Smith）一人占 55 个（占比 33.7%）——其 55 个中 27 个是 [3.14] / [3.15] 回移，28 个是 main 分支改动。
  • 那 28 个是什么（11-01 单日抽查 12 条 main 提交）：minidom getElementById() 重复 ID 顺序稳定化、configparser clear() 改线性时间、plistlib 二进制写入器改重复计数 struct 格式、idna 增量解码器前导空标签、IPv6Interface.is_unspecified 对 IPv4-mapped、ShareableList 打包失败解除新块、zoneinfo 拒绝非法 TZif 缩写块大小、zipfile.is_zipfile() 对 file-like 对象的 ValueError、uu 编解码器 begin 行八进制模式、punycode 拒绝前导分隔符、gzip CLI 像 gzip(1) 一样替换输出文件。全部是畸形输入与静默错误的防御性修复。
  • 自审自合的实证：gh-161110 时间线（GitHub issue timeline 实测）：assigned 18:36:10 → labeled ×2 18:36:12 → cross-referenced 18:36:20（对应 PR #161111，创建于 18:36:19）→ referenced 19:18:23 → closed 19:18:25。全程 0 条评论，PR #161111 / #161113 / #161107 的 reviews 端点均返回空数组。即：issue 创建者、PR 作者、合并者、标签打点者，是同一个人。
  • 新人路径：thejesh23 在 11-02 至 11-03 连开 5 个 PR（os.getppid / _zstd / sysconfig docstring 笔误、os.{spawnve,preadv}() 与 tkinter.wm_attributes() 报错信息函数名、glossary「virtual subclass」），其中 4 个在 24 小时内被 StanFromIreland 关闭并落地——新人入场通道是通畅的，且靠的是「小改动 + 有人专门看一眼」这套双件套。
  • 积压侧（实测同日）：未关闭 PR 2,299 个；1,070 个创建于 2026-05-01 之前（>6 个月）；445 个创建于 2026-10-01 之后（新血仍在涌入）；awaiting merge 标签 128 个（按该标签定义＝已批准、只差合并）。

开源之道判断：CPython 的制度健康不是「在变好 / 变差」，而是「它的两个功能被同一批人承担，且其中一个没有名字」。

  • L2 层是健康的，而且健康得很罕见：5 人委员会、宽权少用、sponsor 与作者互相制约（Guido 等着 Marc 点头才合自己的教程扩写），PEP 823 的 129 行大改在 40 分钟内两轮 APPROVED 且只改一个笔误——这是「低摩擦决策」的正面标本，摩擦全花在了论坛那 117 楼上。 这说明它的集体选择层运转良好。
  • 但操作层的实证指向另一个结论：255 个合并里，92 个是机器人，55 个是一个人，剩下 108 个分给 45 个人。 而这个人干的 28 件 main 上的事，全部不在任何看板上——没有 issue 讨论、没有 review、没有标签分类，它们是「有人刚好还有力气在周日晚上把边界条件清单扫一遍」。这是一条隐性的供给曲线，它的自变量是某个人的精力，不是任何制度安排。
  • 最该被记住的对照是那个 awaiting merge: 128。 128 个已批准、只差合并的 PR；同时那 1,070 个超期 PR 正在老去；同时 PEP 823 这样的大改可以在 90 分钟内走完全流程。这三点并存，说明 CPython 不缺流程、不缺评审、不缺决策——它缺的是「有人负责把队列看一遍」。 而奥斯特罗姆的第八条设计原则说的正是这件事：监督必须是被指派的、可追责的，而不是自愿的。

与 11-03 Django 的对照：Django 把「AI 声明」做成必填勾选框，用 13 行模板把无法验证的属性转成可追究的主体；CPython 这边，PEP 823/824 的作者与 sponsor 都在用极其克制的方式迭代文本、互等批准，而日常维护端的准入代价则体现为**「等待被看见」——128 个已批准的 PR 在队列里，1,070 个过期 PR 在更远的队列里。同一件事——AI 时代的准入成本——两种解法：Django 把它前置到提交那一刻（声明），CPython 把它后置到有人看一眼那一刻（排队）。前置的代价是门槛，后置的代价是时间。 没有哪一种更「对」，但后置型的成本，全部由提交者承担，而且不记账**。

⚠️ 误判风险

  • 合并数与作者分布取自 GitHub 单次窗口实测：255 / 92 / 55 / 47 均来自 merged:>2026-10-28 的三页全量拉取（非采样），但 GitHub Search API 存在索引延迟，个别临近窗口边界的 PR 可能被计入相邻一天。方向性结论（约三分之一合并集中在单人）不受影响。
  • 「自审自合」不等于违规：CPython 并无禁止自合的宪章条款（与 Django 明令禁止自合不同），gpshead 是核心开发者，边界条件修复属其职责范围。引用该案例是为了说明监督职能的供给方式，不是指控流程违规。
  • awaiting merge 的 128 个依赖标签语义：该计数成立的前提是标签被规范使用；若部分 PR 挂标后失去批准状态（如后续被要求修改），实际「只差合并」数会低于 128。
  • arXiv 未回退的判断基于工具返回体：七次查询均返回结构化结果与总数，无异常提示；但这只能证明通道正常，不能证明「今日无更新论文」——候选池可能确实只有已报道条目。
  • SSRN 元数据经 CrossRef 间接取得：CrossRef 记录日期为 2026-01-01，与 SSRN 页面的实际上传时间可能存在差异；本文按「非本周新论文」处理，若这一判断有误，会低估其时效性。
  • LF 的 25% 是感知而非账：样本口径未公开，不宜与 Anthropic 的统计数字直接相加或换算。

署名： 「开源之道」·窄廊

声明： 本文基于公开信息检索（arXiv、GitHub API、CrossRef、OpenAlex、Linux Foundation Research、Phoronix、Techzine Global 等）整理，仅供参考；学术引用已追溯至原始论文。Project Pulse 中的合并数、作者分布、回移占比、积压分桶与 gh-161110 时间线，均由 GitHub REST / Search API 于 2026-11-04 实测采集：合并窗口 merged:>2026-10-28（255 条，分三页全量拉取，非采样）；作者集中度已显式区分 miss-islington 机器人（92 条）与人工合并（163 条）；peps/pep-0013.rst、pep-0823.rst、pep-0824.rst 与 Python main / 3.15 分支提交均为当日拉取的仓库原文。如果你对开源内容有什么需求，欢迎留言，窄廊会勤于学习，尽量满足。