万物版本控制

# 万物皆版本控制 来源：https://tyoverby.com/posts/version-control-for-everything-else/ AI辅助的智能体编码已突破临界速度，但非编程用例尚未达到同等采用程度。我认为主要原因在于版本控制的缺失。 想象在Git仓库外使用Claude-code。即使处理像重构这样的小任务，使用AI也会压力重重且易出错： - 几乎不可能追踪大语言模型所做的更改。审核AI生成的代码在当下很有用，可以确保在转向其他任务前更改合理；在未来也能帮助理解某些代码为何被编写 - 大语言模型可能使代码库陷入不可挽回的糟糕状态。即便模型足够智能且未犯任何"错误"——人类提示者忘记告知设计约束也可能造成严重后果 - 缺乏"开发分支"与"生产环境"的分离 - 无法通过让多个大语言模型在不同分支并行工作来提升开发效率 即使我只是让Claude处理一个小脚本，也总会新建Git仓库来简化流程。但在编程领域之外，几乎找不到具备相同保护机制和功能的工具。 ## 案例研究：软件开发外循环 软件开发过程管理异常复杂。我们使用问题追踪器和拉取请求管理工作，通过文档、邮件、即时通讯和会议进行沟通。保持这些渠道信息的同步与更新需要专人负责。在此场景中，假设我们关注以下系统： 1. GitHub Issues（读写） 2. 拉取请求（读写） 3. Google日历（读写） 4. Google Docs（读写） 5. Gmail（只读） 6. Slack（只读） 你希望利用大语言模型找出信息未在不同服务间同步的环节（例如邮件沟通后更新问题）。虽然当今的大语言模型或许能独立完成这项任务，但*最大问题在于这些服务均无内置机制允许模型提出待人类审核的操作*。 ### 方案一：代理层 在不改变底层服务的前提下，可构建代理层作为"拉取请求"中转，实现跨多服务的更改预览与审核后再发布。智能体通过该代理操作，将变更暂存直至人工审核、批准并发布。 此方案面临多重挑战： 1. 构建此类定制系统耗时费力，且随需集成服务增多复杂度剧增 2. "回滚"功能可能无法实现，底层服务可能缺乏"撤销"所需机制——尤其当更改已被后续操作覆盖时 3. 底层服务中合并冲突的检测与解决并非总能实现 4. 缺乏原子性：若点击"发布"后某服务拒绝变更，其他服务的更改已生效。若已发布更改无法回滚，问题尤为严重 5. 代理层阻碍全局视图——你无法预见合并更改后的完整状态，如同代码审查只能查看差异，而无法同时查看差异前后的完整代码库 ### 方案二：万物皆Git 若可脱离GitHub、Google Docs等平台，可将这些功能迁移至Git。Jane Street著名的代码审查流程将评审意见直接嵌入源代码注释（https://www.janestreet.com/tech-talks/janestreet-code-review/），这种工作流使大语言模型参与代码审查变得轻而易举，因为所有过程都由版本控制追踪。为何不将问题追踪与代码库并置？将拉取请求和代码审查元数据纳入源码管理？把Google Docs中的设计文档转为Markdown提交？理想情况下，所有这些内容都与代码存储在同一仓库中，从而实现对代码、问题和文档的原子化更新，避免跨服务协调。 我认为主要障碍在于：若无足够投入，这种模式将大幅降低人类用户体验。虽非不可逾越，但需付出大量努力。 ## 对LLM更友好的世界即对我更友好的世界 虽然本文将内容框定为"让大语言模型在编程外更有用的要素"，但只需将"大语言模型"替换为"初级开发者"或"高级开发者"，所有论点同样成立。受益的不仅是智能体式大语言模型——*我个人*若能使用具备分支、版本历史和原子化变更功能的工具，效率也将大幅提升。 要说服管理层投资开发者生产力工具可能不易，但我认为未来几年，论证"AI基础设施"投入（恰好也能提升开发者体验）会相对容易。或许你能利用这点优势：D 相关推荐链接： - 本地优先软件运动（https://www.inkandswitch.com/essay/local-first/local-first.pdf）长期倡导基于合并与无冲突的数据同步技术 - Irmin（https://irmin.org/）是用于构建类Git数据库的OCaml库，支持分支、合并等功能