一篇关于 AI 软件开发流程的实践文章披露：团队登记了二十多个代码仓库，每次交付只拉取涉及仓库，并通过 Git 工作树隔离修改。我们注意到，AI 编程的竞争正从“会不会写代码”转向“能否管住跨仓库工程”。
这是什么
这套方法的核心是“一个主仓加多个业务仓”。主仓保存工作流、规范、脚本和仓库清单，Agent（能理解并执行开发任务的 AI 助手）从主仓启动；涉及修改的仓库，则从固定基线建立工作树（Git 提供的独立工作目录），让代码变更不直接污染原工程目录。
它还规定，Agent 每次动手前必须知道哪些仓库可读、哪些可写，以及编译、测试和代码检查命令。范围之外的操作由命令行工具直接拒绝。文章也坦承两个坑：工作树可能占满磁盘，未合回的修改可能丢失。
行业怎么看
这条路线的价值不在于把所有代码重新塞进单体仓库，而在于保留企业既有的多仓结构，同时给 AI 补上权限、基线和集成规则。对拥有复杂存量系统的团队，这比迁移仓库更现实，也更容易逐步采用。
但我们不认为它已经成为通用答案。反对意见很直接：主仓可能诱导 AI 越界访问其他代码，清单也可能落后于实际权限；工作树带来额外磁盘、清理和合并成本。更关键的是，Git 操作和构建检查能约束过程，却不能保证跨仓改动在业务上正确，最终仍依赖测试覆盖与人工审查。
对普通人的影响
对企业 IT：AI 开发工具正在进入权限治理阶段。企业需要先梳理仓库、测试命令和合并流程，否则直接扩大自动化范围，管理成本可能高于手工开发。
对个人职场：程序员的核心工作会更多转向定义需求、设定约束和验收结果。熟悉 Git、测试和架构边界的人，更容易把 AI 的产出变成可靠交付。
对消费市场：多端产品更新速度可能提高，但消费者暂时不会直接感知到 AI 编程工具的变化。率先受益的会是内部系统复杂、频繁迭代的企业软件与开发服务。