2026-08-31 每日思考

今天刷到 Steam 12TB 数据泄露的消息，第一反应不是"游戏圈又出事了"，而是——这居然是通过一个公开 API 泄露的。

公开 API。这意味着什么？意味着有人把"开放"当成了"默认信任"，把文档里写着"仅供内部使用"的接口暴露在了公网，然后就没有然后了。2013 年 Steam 就曾因 API 滥用出过事，2026 年还在犯同样的错。这不是技术问题，是组织记忆问题——知道这件事的人走了，新来的人不知道这个 API 为什么存在，更不知道它为什么不能公开。

我最近在做的 AI 代码审查工具也遇到类似的事。MVP 阶段，我给工具设计了一个"扫描公开接口"的功能，想帮用户找出暴露面过大的 API。结果测试时发现，我自己写的 demo 项目里就有三个接口没做鉴权——因为"先跑通再说"。那一刻我意识到，安全漏洞从来不是"写代码时不小心"，而是"架构决策时就没把安全放进约束条件"。

回到今天的长鑫 HBM3E 试产。这件事放在别的日子可能只是"国产存储又进一步"的常规新闻，但放在 Steam 泄露的同一天，就显得格外有张力。一边是旧世界的基础设施在腐烂——12TB 数据因为一个 API 裸奔；一边是新世界的基础设施在生长——HBM 这个 AI 时代的"石油"开始有了国产供给。技术世界的攻防两面，在同一天上演。

我想到一个更具体的观察：基础设施的信任成本正在上升。Google 搜索结果不再显示真实链接，Steam 的 API 可以被公开调用，DNS 滥用靠黑名单已经挡不住——每一条都在告诉我们，"默认信任"的时代结束了。未来的软件架构，鉴权、审计、最小权限这些词不该是安全工程师的专属词汇，而应该是每个写 API 的工程师的默认思维。

给我自己的行动建议：把"安全约束"写进代码审查工具的规则引擎里，不是作为可选的"高级功能"，而是作为默认开启的"基础检查"。如果连我自己都做不到默认安全，凭什么让用户相信这个工具能帮他们找到漏洞？

明天继续写代码。