2026-09-19 每日思考

今天两条新闻撞在一起，让我停下来想了很久：一条是微软内部把抓取新闻训练 AI 称为"人类历史上最大规模的劳动盗窃"，另一条是安全团队用 Claude 辅助攻破了 OpenAI。一个讲数据从哪来，一个讲能力往哪去，但本质是同一件事——我们正在为"智能"补交它一直没付的账。

我在做 AI 代码审查工具的 MVP，主攻安全漏洞和性能问题检测。这个位置很尴尬：我的模型权重来自公开数据训练，我的评测集里塞满了别人的开源代码，而我的产品价值恰恰是"发现别人代码里的问题"。今天那条盗窃新闻像一面镜子——我有没有认真想过，我用来训练和评测的每一行代码，它的作者是否同意？行业惯例是"公开即默许"，但惯例不等于正当。我现在的做法是：评测集只用明确带宽松许可证的仓库，并记录来源与版本；对客户代码坚持不落盘、不回流训练。这不是道德洁癖，是产品护城河——当企业客户开始问"我的代码会不会进你的训练集"，能给出可审计答案的工具才有资格进采购名单。

第二条新闻更让我警惕。Hacktron 攻破 OpenAI 的入口不是模型本身，而是 SSO 配错和 libheif 的堆溢出。这正好是我的工具该抓的东西，但它也暴露了一个残酷现实：AI 辅助攻击正在把"发现漏洞"的成本压到极低。我的检测如果还停留在模式匹配已知 CVE，就是在和自动化攻击赛跑中必输。真正有价值的方向是理解数据流与权限边界——比如"这个用户输入最终流到了哪个系统调用"，而不是"这行代码是否匹配某条规则"。这也是我最近在重构检测引擎的原因：从规则库转向污点分析加调用图，哪怕召回率暂时下降。

给同行的可执行建议：第一，现在就去审计你的训练与评测数据来源，能写出清单的留下，写不出的砍掉；第二，把安全检测的重心从"已知漏洞匹配"移到"数据流与权限边界分析"，因为攻击方已经用上了 AI，规则库的更新速度追不上生成速度。预测一句：未来一年，能在采购问卷里回答"数据来源可审计 + 检测逻辑可解释"的 AI 工具，会拿到绝大多数企业订单，其余的会被合规部门一票否决。