为何 AI 编程离不开版本控制？
Version Control for Everything
AI 辅助编程已爆发式增长，但非编程场景的落地却因缺乏版本控制而受阻。想象一下在 git 仓库外使用 claude-code，追踪 LLM 的改动、回滚错误状态或并行开发都变得异常困难。文章探讨了将 github issues、google docs 等工具纳入版本控制的两种方案：构建代理层或直接将一切存入 git。作者认为，这不仅能让 LLM 更安全高效，也能提升开发者自身的生产力。毕竟，一个对 LLM 友好的世界，本质上也是对我们人类更友好的世界。
虽然我把这篇博客的主题设定为“让 LLM 在编程之外更有用的工具”，但你完全可以用“初级开发者”或“高级开发者”来替换“LLM”，所有的观点依然成立。
HN 评论区
53- cfjgvjh
我真心希望能给所有东西都做版本控制，但我大部分数据都是二进制的，跟 git 实在不太兼容；我也试过用 LFS，但对我的特定工作流并不适用。
希望未来能出现一些不那么依赖文本的解决方案。
Lore 在这个用途上看起来挺有意思。
- PaulRobinson
> 设计文档从 Google Docs 迁移到纳入版本控制的 Markdown？
这在我所在的团队里效果相当不错。Google Docs 里的设计文档很难与决策保持同步，而且无法被 AI Agent 有效访问。起初我们担心缺少评论功能会是个问题，但事实并非如此——一个 Slack 频道就足以应付。在这个流程中，设计作者做出决策并审查结果，Agent 将其传播到各个相关领域，再进一步落实到具体任务（这些任务也用 MD 编写），最后将描述复制到 Jira。再也不会有“我们改了一个地方却漏掉了依赖它的另一个地方”的情况，或者至少没以前那么严重了。
- Klaster_1
把一切都放在代码旁边的做法在理论上听起来不错，但在大型项目中实践起来简直就是一场噩梦。
想象一下，你的 git 历史里塞满了项目经理提交的记录，需求文档的每一个微小改动都单独生成一个 commit。
我们试过这种做法，结果不得不每天多次 rebase 分支，完全失去了对代码变更的全局概览。
主要问题在于：代码在开发过程中可以存在于多个分支，但文档和需求却不能这样，它们需要有一个对所有人统一的单一事实来源。
我认为我们很快会看到更多协作工具开始适配，以提供或接收文本格式的信息，使其适合 Agent 使用，这将成为一种可行的解决方案。与此同时，我发现目前最实用的方案是维护两个仓库：一个存代码，一个存文档。