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

「开源之道」昨日阅读 · 2026-10-31

今天的线索指向同一个反常现象：开源世界里，制定规则的人正在被「谁承担成本」这个问题逼到墙角，而规则的制定权本身正在换手。

① 有一篇论文把 2025-10 至 2026-10 整整一年、31 个组织发布的 50 份灰文献全部编码了一遍，问 PR 会被什么取代。答案是：「限制准入」是报告为已采用最多的回应；而「外部贡献」这一项——只有两份文献提了替代方案，零采用。 同时它扔出一句让所有做实证的人脊背发凉的话：评审搬进 agent 会话就不留 PR 评论，关闭了 PR 的项目就从样本里消失。（arXiv:2610.34933） ② 同一天，Linux Foundation 那份 234 人调查的细节被翻出来：59% 的维护者说贡献量涨了，其中约 25% 的进队 PR 被判定为「AI slop」，大项目这一比例升到 31%；但只有 35% 的项目有成文的 GenAI 政策，32% 既没有政策也没有计划。（LF Research、TechPowerUp 2026-10-20） ③ 而在「谁来立规矩」这一层，10 月 22 日发生了两件同一天的事：AAIF 宣布四个新项目——Agent Skills（Anthropic 捐）、Open Responses（OpenAI 捐）、OpenEnv（Hugging Face 捐）、OpenSandbox（阿里捐），一年从 3 个变成 10 个；同一天宣布成员突破 305 家，一个季度净增 60 家。（AAIF、LF 新闻稿） ④ 而今天实测那个被捐赠的标准仓库，得到的数据与新闻稿不一致：agentskills/agentskills（26,831 ★）默认分支最后一次提交停在 2026-08-09——捐赠日 2026-10-22 之后零提交；根目录无 GOVERNANCE.md、无 MAINTAINERS；112 个 open item 待着。法律上已经易主，运营上停在原地。

这四件事拼在一起，是一个正在闭合的环：AI 让贡献变便宜 → 维护者被淹 → 项目收紧准入 → 对外部人关上门 → 而「能力本身」（skills、协议、运行时）正被四家大公司成批捐进一个中立基金会——只是捐进去之后，还没有人真正接手。 换手的不只是代码，是规则由谁写的资格。今天最该记下的一句：当所有人都在讨论「AI 该不该被允许进开源」时，真正的问题已经变成了「开源还允不允许外面的人进来」——以及，那些已经被交出来的，有没有人接住。

📄 最新开源研究论文

今日真正的新论文有三篇，且它们从三个不同角度指向同一个问题：审核这个动作，正在从「人看代码」变成「机器看机器」——而制度仍然假设是前者。

1. 机器审核机器：当 AI 攻击者写出连三个 AI 审阅者都放过的补丁

  • 标题：CyberDual: AI Attackers versus AI Code Reviewers in Real Software Maintenance
  • 作者：Chenyuan Yang、Hwiwon Lee、Jongseong Kim、Yihan Yang、Dongjun Kim、Yinfang Chen、Lingming Zhang
  • 发表：arXiv:2610.34435（cs.CR / cs.AI / cs.SE），2026-10-25 提交
  • 摘要：开源项目现在会让 AI agent 审核进队代码，但被审的代码可能本身就出自一个 AI 攻击者。作者搭了 CyberDual 这个竞技场：攻击 agent 在真实上游开源项目的日常维护工作里藏一个有利用价值的 bug，审核 agent 去找并修；胜负由执行裁决——把攻击者的 PoC 在生产出来的代码上重跑一遍。任务是每季度用最新上游历史重建的，所以每一次攻击都是新的。结果：三个 agentic 审核者能抓到 1,088 次有效攻击中的 85–91%；但当攻击者把 bug 拆散铺陈在真实的上游提交里时，约每六个攻击位就有一个在审核之后仍留下可用的 exploit。最强攻击者是开放权重的 GLM 5.3，几乎从不拒答，28 个穿透全部审核的攻击里有 13 个出自它。审核者失手时的失败模式极具症候性：Claude 系审核者多数情况下直接批准了攻击，GPT-6-Sol 则多数情况下改错了地方；换一家厂商的审核者能抓住 Claude 审核者约三分之二的漏网。补充发现：Claude Sonnet 5 会拒绝五分之一的攻击位，但其攻击能力与 GPT-6-Sol 相当——拒答率并不削减攻击能力。
  • 为什么与开源之道相关：这不是安全论文，这是一份关于「审核」这个制度动作的可行性报告。开源的全部质量保证，建立在「有第二个人会认真看」这个社会预期上；这篇论文测的正是：当第二个人也是机器时，这个预期还成不成立。
  • 开源之道视角点评：最值得记住的是那个失败模式的分布——「Claude 通过，GPT 改错」。这两句话各自是一种制度失灵：一种是判断权放弃了，一种是能力对了但对象找错了。 而「换一家厂商能补三分之二」更是把问题挑明：审核能力不是通用的，它是与攻击者的分布耦合的——这正是为什么审计这个职能在社会里从来不能只由被审计方自己承担（审计必须来自外部，且必须可追责）。开源现在做的事，是把审计外包给一个既没有立场、也没有可追责主体的第三方。威廉姆森讲治理结构的选择取决于交易的三维属性（不确定性、资产专用性、交易频率），而 agentic review 在这三维上都极差：不确定性高（每季度重建的攻击面）、专用性为零（模型可换）、频率极高（每月百万级 PR）。按交易成本理论，这个组合本来就该被内化或被禁止，而不是被外推给一个市场化的黑箱。 另外那句「拒答不削减能力」值得所有人抄下来：对齐（alignment）与能力（capability）是两根独立的轴，把安全寄托在前者而不检验后者，是一种制度上的自我安慰。

2. 同一模型、不同 harness：能力差了一倍，账却算在「模型」头上

  • 标题：How Deterministic SAST and AI Security Agents Divide the Work: Coverage, Harness Policy and Cost in Snyk VulnBench 2.0
  • 作者：Liran Tal、Chris Liu、Charlotte Fereday、Sebastian Roth、Brian Clark（Snyk）
  • 发表：arXiv:2610.38617（cs.CR / cs.AI / cs.SE），2026-10-28 提交
  • 摘要：基准 VulnBench 2.0，含 20 个开源 Web 应用（Go / JS-TS / Python / Java）里 108 个手工精选、攻击者可达的漏洞，其中 62 个跨多文件。判定极严：必须同时定位攻击者可控的 source 与危险 sink，各在两行以内才算命中。在统一盲测协议下评估九种产品化配置：Snyk Code 静态分析器、Claude Code 的 /security-review（三档模型与 effort，其中一档挂 Snyk MCP）、Codex Security（GPT-5.6 Luna / Terra / Sol）、DeepSec（两个模型后端）。结果：Snyk Code 宏召回 82.4%（89/108），Claude Code (Opus 5, xhigh) 79.3%（85/108）；二者在 28 个漏洞上判断不一致（16 vs 12），差异小到无法区分优劣。任何一方单独都不够：两者合并覆盖 101/108，正好等于全部七种可比配置的并集上限；且 AI 配置还额外报出至少 7 个参考集里没有、Snyk Code 也没报的真实漏洞。最关键的一条：AI 引擎漏什么，取决于 harness 不亚于取决于模型——去掉 Claude Code 内置的 review policy 之后，同一模型在其策略排除的漏洞类别上从命中 16/20 掉到 9/20（即 policy 贡献了其中 7 个）；DeepSec 的无模型文件筛选只保住 108 条流中的 56 条。覆盖与成本只有很弱的关联。
  • 为什么与开源之道相关：这篇论文用数据把「模型能力」和「制度设计」这两件事拆开了——而这一拆，正好落在开源治理最核心的那个类比上：同一个人，放进不同的规范环境里，产出完全不同。
  • 开源之道视角点评：那句「没有 Claude Code 内置 review policy，同一模型在策略排除的类别上只命中 9 个而非 16 个」是今天整份日报里最有分量的一个数字，因为它是制度对产出的独立贡献的定量估计——在这一个例子里，约束条件贡献了约 78% 的增量。这几乎就是哈耶克讲的规则与自发秩序关系的一个可测样本：规则不是替人做事，规则是让人能做到本来做不到的事。同时它给了「AI 会取代维护者」这个流行叙事一记闷棍：真正在起作用的不是那个模型，是那套 harness 里写好的策略——而策略是人写的、可审的、可争论的。换句话说，agentic 安全审计里最有价值的部分，恰恰是它最像开源的那部分（公开的策略文件），而不是它最像 AI 的那部分（模型权重）。反过来也成立：Codex Security 定位到 80 个但只在行级命中 34 个——「找得到」与「说得清在哪里」，中间隔着一次完整的可审计性要求，这跟开源世界里「提了 issue 但没给最小复现」是同一种不合格。

3. 一百五十万个 skill 里，每 17 个就有一个在教 agent「别问」

  • 标题：When Skills Tell Agents Not to Ask: A Large-Scale Study of Oversight Directives in Agent Skills
  • 作者：Timofey Sanko、Yuan Tian
  • 发表：arXiv:2610.37734（cs.CR / cs.AI / cs.SE），2026-10-27 提交
  • 摘要：分析 GitSkills 上 153 万个英文 skill（以 SKILL.md 为核心的可复用指令包），首次大规模研究「放松监督指令」（oversight-loosening）——即告诉 agent 不经批准就继续、用 --no-verify 绕过检查、不必回报之类的行。人工标注 2,097 个样本训练检测器后规模化统计：约每 17 个 skill 就有 1 个（约 8.8 万个）含放松指令；70.1% 是无条件的（而非仅在 CI 之类特定情形）；执行 shell 代码、安装包、使用 sudo 的 skill，出现放松指令的 odds 是同量监督语言的 1.7–1.8 倍，且没有以更多「收紧」来补偿。扩散特征是少数上游源而非采纳者改写：2.4% 的 skill 家族承载了一半的放松类副本，1.1% 的不同放松单元贡献了一半的放松出现次数。检测侧：开源 skill 扫描器最多抓到 46%（精确率 < 0.4）；用同一 codebook 提示底层 LLM 则抓到 61%、精确率 0.71。
  • 为什么与开源之道相关：skill 是当下分发「行为规范」最快的通道——一行写进被大量复制的 skill，就作用于每一个加载它的 agent。这与许可证、CONTRIBUTING、CODE_OF_CONDUCT 属于同一类东西：都是对行为的规则约束。区别只在于，后三者处在公开、可 diff、可争论的轨道上，而前者没有。
  • 开源之道视角点评：这篇可以读成一则关于制度复制机制的寓言。开源靠「少数人写的文件」支撑千万人使用，那是因为被复制的是共识；而 skill 生态复制的是未经审议的行为指令，且扩散呈典型重尾分布——2.4% 的上游贡献了一半的副本。这既是它危险的地方，也是它高效的地方，两者是同一个性质的两面。最该停下来想的是那句 70.1% 无条件：「总要问」和「从不问」的差别不在语气，在默认值。 奥斯特罗姆的八原则里有一条被谈得最少但最要紧——受规则影响的人有权参与修改规则。153 万个 skill 的使用者，对写下「不必回报」的那一行，既没有投票权也没有 diff 权。这不是恶意，这是治理层根本没有被建立起来。而 10-31 记录的 vLLM「fail-closed 默认返回说明」之所以是好设计，恰恰是因为它的默认值经过了公开争论；同一套机制在无人审议的生态里，默认值的方向往往是反的——而这 70% 的反方向，正在被复制进下一个季度的每一个 agent。

📰 开源动态摘要

1. AAIF 一年从 3 个项目到 10 个：四家公司同一天把自家协议捐进中立托管

  • 来源：Agentic AI Foundation 官方公告 2026-10-22、Linux Foundation 新闻稿

  • 摘要：在 AGNTCon + MCPCon 北美站上，AAIF 宣布四个新项目：Agent Skills（Anthropic 贡献）、Open Responses（OpenAI 贡献）、OpenEnv（Hugging Face 贡献）、OpenSandbox（阿里贡献），与已有的 A2A、Agent Router、agentgateway、AGENTS.md、goose、MCP 并列，托管项目从 2025 年 12 月创立时的 3 个增长到 10 个。AAIF CTO Manik Surtani 的表述是「四个不同的公司选择把它们交给中立治理」。同一天公布的成员数据：一个季度新增 7 家 Gold、33 家 Silver、18 家 Associate，总数达 305 家；新 Gold 包括蚂蚁集团、盖茨基金会、MongoDB、Nutanix、加拿大皇家银行、Vercel、Vultr；Associate 名单里出现了 NIST、Mozilla、SLAC 国家加速器实验室、香港中文大学。

  • 开源之道点评：这条要连着 10-31 记录的 LF 调查一起读：一边是只有 35% 的项目有成文 GenAI 政策、32% 连计划都没有，另一边是一年之内 10 个 agent 基础设施项目被捐进同一个中立托管方。这两个数字放在一起说明一件事——规则是在协议层被书写的，不是在贡献政策层。 当单个项目还在为「要不要禁 AI 生成的 PR」争吵时，agent 如何获得能力（Skills）、如何跨厂商通信（Open Responses）、在哪里安全执行（OpenSandbox）这三层已经有人写好了。这跟 10-26 那份阿里巴巴 9 项目实证是同一个机制的放大版：存活的判据是治理权是否转移到中立通道，而这里转移的速度是一年 7 个。

    但今天必须补一条硬核验，因为它与新闻稿直接冲突。 直接查 agentskills/agentskills 仓库（2026-11-01 实测）：

    • 默认分支最后一次提交：2026-08-09（docs: add OpenClaw to client showcase (#492)），距今近三个月，而捐赠日是 2026-10-22——捐赠之后零提交。
    • 26,831 ★，112 个 open issue+PR，未归档。
    • 仓库根目录无 GOVERNANCE.md、无 MAINTAINERS（此前已记录，今日复核仍未补）。
    • 此前已记录的另外两条事实仍在：83 个已合并 PR 的 merged_by 全部为 null（合并者身份不公开）、57 个 open PR 中 18 个来自同一账号。

    这组数据把新闻稿里那句「all under open, vendor-neutral governance」（皆在中立治理之下）逼到了一个具体问题上：托管（hosting）不等于治理（governance），而「中立」这个词在文件层面暂时找不到对应物。 一个 26,831 星、被宣称有 70+ 平台采用的事实标准，在被捐给中立基金会之后的近三个月里没有一行提交、没有一个成文治理文件、没有一次可追溯的合并署名。——这不是丑闻，它更接近一个尚未真正启动的移交：项目从一个公司的手里，法律上移到了基金会名下，而运营上停在了原地。AAIF 说的「10 个项目」是托管名册的计数，不是治理活动量的计数。

    可检验的观察点因此要改得更硬——① 默认分支是否在 2026-12-31 之前出现第一笔捐款方之外的提交；② GOVERNANCE.md 或 MAINTAINERS 是否落地（这是「治理存在」的最低物证）；③ 新合并的 PR 是否开始出现非 null 的 merged_by。 三条里若两年内仍是零，那么「捐赠给中立基金会」在实际效果上就是一次名分转移而非权力转移——而这恰好是 10-26 那份阿里巴巴 9 项目研究里「存活条件=捐给中立基金会」的必要但不充分条件。代码是公开的，这不假；但公开的代码如果没有一个会回应 issue 的主体，它离公地还差一个「谁负责」。

2. Linux Foundation：GenAI 让编码时间减半，但 25% 的进队 PR 被判定为「AI slop」

  • 来源：LF Research《Open Source Development in the GenAI Era 2026》、TechPowerUp 2026-10-20 报道
  • 摘要：LF Research 对维护者群体的调查显示：GenAI 让各类 OSS 开发任务的生产力提升最多 50%；59% 的维护者报告贡献量上升，但估算约 25% 的进队 PR 是低质「AI slop」，在贡献者超过 50 人的大项目中升至 31%。治理侧的数字更刺眼：只有 35% 的项目有成文的 GenAI 使用政策，32% 既无政策也无计划。信任侧：71% 的维护者同意 GenAI 降低了参与开源的门槛，但 53% 不同意 GenAI 改善了社区信任。另一个反常项：21% 的人报告高复杂度任务用 GenAI 反而更慢；46% 认为 GenAI 增加了新人指导需求，32% 认为减少了。研究者自己的结论是：需要更强的 AI 治理——清晰的贡献政策、标准化的署名与验证、以及对人类导师制的持续投入。
  • 开源之道点评：这份调查最有价值的地方，是它同时记录了效率收益和它落在谁头上。生产力的 50% 提升记在贡献者账上，25–31% 的清理成本记在维护者账上——两笔账不在一张表里，所以永远不会被放在一起讨论。 这与 10-31 GSoC 那篇论文（导师用「检查」补差额，而检查消耗的是项目自我更新的时间）是同一笔账的两次独立核算，两批不同的人马、不同的方法，得出同一个方向。当两篇独立研究算出一个相同的隐形成本，那它就不是个案了，是制度缺口的度量。 那句「71% 说门槛降低了，53% 说信任没变好」尤其值得记：门槛降低与信任提升不是同一件事，甚至可能互为代价——门槛降低是把「证明我能做」的成本降到零，而信任恰恰建立在那个证明过程上。这正是 meritocracy 的算法前提：功绩制需要可信的功绩信号，而 AI 摧毁的正是信号本身，不是能力。

3. PyTorch 2.15.0 发布：一次几乎没有「对外」色彩的版本，把力气全花在平台铺开上

  • 来源：pytorch/pytorch v2.15.0 Release Notes（2026-10-28 发布）
  • 摘要：核心变化：重写的 NCCL 后端成为默认（附带 hang 时 dump 的 flight recorder，可用 TORCH_DIST_USE_NCCL2=0 或 nccl-legacy 回滚）；torch.distributed 引入单向传输与 NIXL 后端；FSDP2 与流水线并行获得更细的显存/通信控制；Blackwell 上的 NVFP4 4-bit 解码加速；Apple Silicon 获得 FP8 与更快的 decode（MoE decode 1.32–1.34x tokens/s）以及公开的 torch.mps.Stream API；平台面大规模铺开——AMD gfx950 的 FlyDSL kernel、gfx1250 (MI450) 的 Tensor Data Mover、ROCm 10.0 wheels、Intel GPU 的 SYCL kernel 与多卡 profiling、CUDA 13.2 作为默认 wheel（13.4 并行提供）、torch.compile 支持 Python 3.15。破坏性变更里有一条值得注意：import torch 在同一进程内不可再被重复执行。开发者侧新增 spin test 和 [no-ci] 持久化 PR 标题前缀（跳过 build/test/lint）。
  • 开源之道点评：这是一次**「把硬件矩阵铺满」的版本**——AMD、Intel、Apple、NVIDIA 四条后端线在同一版里同时推进，PyTorch 作为基金会的价值已经越来越像「多方硬件共同维持的公共适配层」，而不是一个研究框架。 制度和它的产出是对得上的：PyTorch Foundation 的成员结构（10-21 刚迎来 9 家新成员）直接映射到了这份 release notes 的硬件清单上。 值得单独挑出来的是 [no-ci] 前缀——一个用来跳过全部 CI 的 PR 标题标记。这是给贡献者的一个显式的、可审计的例外通道：不是偷偷绕过检查，而是写进标题、留下痕迹地绕过。对照昨天 vLLM 的 fail-closed 默认，这两种设计思路的差别不在松紧，而在例外是否可见。开源的制度设计里，最难的从来不是「允不允许例外」，是让例外留下名字。

🔍 Project Pulse：vLLM —— 一个把规则写到极细的项目，为什么积压反而更多

项目：vllm-project/vllm（95,989 ★ / 24,227 fork / 9,665 open issues+PR，Apache-2.0） 本次观察切入：10-30 看过 vLLM 的「值班表」（11 名 Project Leads / 57 名 Active Committers / 18 名 Emeritus），10-31 看了它的反面 Pico CSS。今天回到 vLLM，但换一个问题：治理结构的复杂度提上去了、规则写细了，为什么 open PR 还在 9,665？

【L1】发布节奏：稳定到近乎机械，而且是有意的 一手数据：v0.32.0（2026-10-18）→ v0.31.0（2026-10-05）→ v0.30.0（2026-09-22）。间隔分别是 13 天、13 天——连续三个 minor 版本，节奏几乎精确到两周。在一个日增数十个提交的推理框架上维持这个节奏，说明发布这件事已经被完全制度化了：不是「做完就发」，是「到点就发，做不完的下一班」。对照 10-31 Pico CSS 的 v2.1.1 停摆 18 个月后才被归档，vLLM 的 L1 给出的信号是相反的：版本号在动，而且动得规律——这本身就是治理还没失效的最直接证据。

【L2】治理结构：57 个活跃提交者、68 个采样作者，CODEOWNERS 细到单文件 一手数据（近 30 天 100 个提交采样）：68 个不同作者，前五名 BugenZhao 13、Thangnguyenvn98 9、njhill 3、hao-aaron 3、vMaroon 3。分布极平——没有任何人超过 13%，第一名只有第二名的 1.4 倍。这是与 Pico（876:12）完全相反的形态：贡献高度分散，没有单点。 治理的「规则密度」是本文最值得看的部分。.github/CODEOWNERS 的粒度到了单文件级：/vllm/compilation/breakable_cudagraph.py @ZJY0516、/vllm/model_executor/layers/mamba/gdn/qwen_gdn_linear_attn.py @tdoublep @ZJY0516 @vadiklyutiy。而 vllm/config 这一行的注释写得极坦白：

「Any change to the VllmConfig changes can have a large user-facing impact, so spam a lot of people」 — 该路径挂了 8 位 owner。

同时 GOVERNANCE.md 返回 404——vLLM 没有成文的治理文件，它有的是 CODEOWNERS 加上一份详尽到近乎法条的操作规则。 顺便核实：仓库中确实曾有过 [docs] Add lightweight AI assisted contribution policy 的相关 PR（2025-12-18），但该条已在关闭状态。

【L3】新人通道：入口是开的，但「进来」和「被看见」是两件事 68 个采样作者里，出现一次的就有约 40 个——入门的门槛极低，走完全程的比例极低。而 [no-ci] 那类机制（PyTorch 有）在 vLLM 侧不存在对应物，意味着每一个新人的第一个 PR 都要跑完整的 CI 矩阵——在推理框架这种测试极重的仓库里，这是把第一道门槛设在了「等技术」而不是「等判断」上。这不是错，但它解释了为什么 9,665 个 open item 会长期存在：进来的速度快于被判断的速度，而判断权集中在 CODEOWNERS 那几十个人手上。

开源之道判断：vLLM 的制度健康是好的，但它好在一个特定的方向上——它把 L3（治理机制）做得极重极细，代价是把「判断」这条通道做成了瓶颈。可检验的观察点：

  1. GOVERNANCE.md 是否会补上——目前它靠 CODEOWNERS 这一人肉可读的机制在运行。CODEOWNERS 能回答「谁来审」，回答不了「谁有权改 CODEOWNERS」。 这个区别在项目平稳时无所谓，在需要改 CODEOWNERS 的那一刻会变成全部问题。
  2. 第一名贡献者 BugenZhao（13/100）是否会进入 CODEOWNERS——入榜即说明「高频贡献 → 审核权」的转换通道通畅；半年后仍是 13% 且在表外，则说明贡献与权力之间有断层。
  3. 9,665 这个数字的方向——它涨，说明判断速度赶不上进入速度；它跌，说明规则起效。在两周一版的节奏下，这个数字比版本号更能反映项目的真实状态。
  4. 对照检查：今天是 11-01，正是 CyberDual 论文说的「每季度用最新上游历史重建攻击面」的时点。vLLM 每月数百万次下载、24,227 个 fork，是这个攻击面的最高价值目标之一，而它的防御依赖的是 CODEOWNERS 上那几十位志愿者。

桥接：用阿西莫格鲁的框架，vLLM 是典型的包容性制度（inclusive institutions）——参与门槛极低（68 个作者/月）、产权清晰（Apache-2.0）、审核权按领域分散而非按公司集中。它的效率来自这里。但它同时暴露了包容性制度的一个未被充分讨论的脆弱点：包容性扩大的是「参与」，不一定扩大「决断」。 当进入成本被 AI 进一步压低（今天 LF 的 25% AI slop、GSoC 的导师过载都是同一股力量），包容性制度会先在最需要决断的那个环节堵塞。开源不需要更多人写代码，它需要更多人有资格说「这个不合并」——而后者从来没有被任何一份 CONTRIBUTING 好好写过。

📡 今日新来源发现

来源类型发现方式推荐理由推荐加入
aaif.io/news基金会官方新闻多次检索命中（项目捐赠、成员增长）AAIF 的一年 3→10 项目扩张与 305 家成员数据的一手来源，是观察 agent 基础设施治理权集中度的主入口建议加入（高置信）

处理说明：aaif.io 作为域已以 agentic.ai 名义登记于监控列表第 6 条，但其官方新闻页 aaif.io/news 是独立且更可靠的一手公告流（本次四项目公告 + 成员数据均由此核验）。按规则追加为待确认条目，待人工审核后改为 ✅ 活跃。

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