2026-09-01 每日思考

今天刷到 AnkiDroid 被 Google Play 要求移除 Open Collective 捐赠链接的消息，评论区一片哀嚎。我盯着这条新闻看了很久，脑子里浮现的却是自己那个 AI 代码审查工具 MVP 里的一行代码——某个安全漏洞检测规则的实现，依赖了一个 GitHub 上只有 3 个 star 的小库。

这大概是开源生态最吊诡的地方：我们一边享受着免费的基础设施红利，一边随时可能被上游的一次政策调整、一次仓库删除、甚至一次 BGP 劫持打得措手不及。Softaculous 被劫持 33 小时，AnkiDroid 被平台掐住捐赠通道，这两件事本质上是一回事——你把自己的命脉交给了你无法控制的一方。

我不是在说"别用开源"或"别上架应用商店"，那太幼稚了。我想说的是，我们这些做工具的人，尤其是做 AI 工具的人，可能对"依赖"这件事过于麻木了。我的代码审查工具在 MVP 阶段就集成了十几个开源组件，每个都有各自的许可证、维护节奏和安全公告。我在写漏洞检测规则，可我自己每天都在依赖链上裸奔。

更让我不安的是 AI 审计论文里提到的一个现实：2025-2026 年出现了大量匿名发布的前沿模型，开发者用化名上传权重，出了问题你连该起诉谁都不知道。这和开源依赖的问题如出一辙——你用的模型、你调用的 API、你集成的 Agent 框架，它们的真实出处和训练数据来源，你验证过吗？

BLOOM-WILT 那篇论文给的思路很有意思：与其事后追责，不如用 logit 倾斜主动逼出模型的隐藏行为。这让我想到，也许我的审查工具也应该更"主动"一点——不是等代码写完了再扫描，而是在 AI 生成代码的过程中实时干预，用类似"行为探测"的方式让问题在产生之前就暴露。

当然，这还只是个想法。眼下我能做的，是给项目加一份依赖清单，标注每个组件的许可证、维护状态和已知漏洞，至少让我自己的工具经得起自己的审查。如果你也在做 AI 工具，建议你今天就去看看你的依赖树——你可能会吓一跳。

明天的事，明天再说。