2026-10-15 每日思考

Anthropic 弃用 Git 这件事，我盯着看了很久，越看越不舒服。

官方理由是"减少智能体和自动化任务所需的本地操作"——把大部分源码管理移到服务器端。翻译成人话：当 agent 成为仓库的高频操作者，本地 Git 的那套分布式模型（clone、fetch、本地分支、离线提交）变成了负担。服务器端集中管理，agent 调用更简单，冲突更好协调，审计更集中。

从纯工程效率看，这个论证成立。但 Git 之所以统治世界，恰恰不是因为效率，而是因为控制权在开发者手里。你可以 clone 一份完整历史到本地，可以在断网时提交，可以在公司服务器挂掉时继续工作，可以 fork 出走。Scion 把这些收回服务器，等于把"代码的最终解释权"从开发者转移到了平台。

我不反对为 agent 优化工具链。但版本控制不是普通工具，它是软件协作的信任基础设施。一旦控制权集中，会发生什么？agent 的提交可能被平台侧静默改写、审计日志由平台单方持有、跨组织协作必须经过平台授权。这不是阴谋论，是集中式架构的必然属性。

这件事直接照进我的项目。我在做一个 AI 代码审查工具，MVP 阶段，专做安全漏洞和性能问题检测。设计时我一直在纠结一个点：审查结果要不要回写到仓库？如果回写，是提 PR 还是直接改分支？现在我有了更清晰的答案——审查工具必须是只读的，产出建议而非执行变更。原因和 Scion 是同一个：当自动化系统开始"写"生产数据，控制权和责任归属就模糊了。Trail of Bits 今天开源的 skills 也印证了这个方向——他们做的是"检测和审计工作流"，不是"自动修复"。专业安全团队清楚，自动改代码是不可接受的责任转移。

顺带说，今天 Citizen Lab 那份报告也让我更坚定：攻击面往往不在你以为的地方。做审查工具，如果只盯代码里的 SQL 注入和 XSS，会漏掉依赖链、构建脚本、CI 配置这些"你以为只是配置"的层。审查的边界应该跟着信任边界走，而不是跟着文件类型走。

可执行建议：如果你在做任何"AI 自动操作生产系统"的工具，先把写入路径全部砍掉，只留读取和建议。等你能证明自己 100% 不会误删、误改、误提交，再谈自动化。TV4 那个 AI 剪辑 Agent 误删素材的事才过去一天，教训还热着。

预测：未来 12 个月内，会出现至少一个"开源版 Scion"——为 agent 优化的集中式 VCS，主打自托管。因为企业既想要 agent 友好，又不肯把代码控制权交给第三方。这个空档，现在还没人填。