你的开源项目真的对AI友好吗？这不是在问代码能不能编译或测试是否通过——而是问一个自主运行的AI编程代理，能不能在没有人全程盯着的情况下真正理解、导航、并为项目做出贡献。
对大多数维护者来说，答案大概是否定的。而这正在变成一个真正的问题。
Simon Willison本周发布了一份实用指南，展示了编程代理已经成为Git的熟练用户。它们理解分支、提交和仓库历史，能克隆仓库并探索整个演进过程，不需要额外的网络请求。这意味着瓶颈已经转移：代理们不再为版本控制犯愁了。它们真正卡住的地方，是你的README、提交信息，以及代码组织方式。
另一篇关于让项目"吸引AI"的文章（在HN上获得了65分且持续上涨）列出了具体的摩擦点：杂乱的目录结构让代理困惑；未记录的配置选项迫使它们猜测；不一致的提交信息让决策追溯变得困难。这些不是bug——它们是设计选择，对人类协作者有意义，但对AI代理形成了无形的壁垒。
实际影响很直接："好代码"的定义正在扩展。人类可读性仍然重要，但机器可读的上下文正变得越来越有价值。清晰的提交信息服务于双重目的。明确的依赖文档帮助代理理解构建需求。结构良好、约定可预测的仓库让代理能快速定位自己。
这不是在教人给机器人写代码。这是承认AI代理现在是合法的协作者——而就像任何协作者一样，它们需要信号才能有效工作。Willison的指南表明，代理已经能胜任处理Git的机械部分。下一步是确保它们能理解代码背后的决策。
对维护者而言，这意味着要用一个新的问题来审视项目："一个AI代理能理解这个代码为什么存在、它是如何演进的、它应该做什么吗？"如果答案不确定，那就是一个具体的行动项——改进文档、澄清提交历史、重构模糊的模块。
转变已经在发生。Willison指出，开发者不再需要记住Git命令，只需要知道有什么可能性。这种认知解放延伸到更远处——当代理能处理整个工作流模式时。但这一切只有在仓库给它们足够上下文才能独立操作时才有效。
最先想通这一点的维护者将拥有结构性优势。他们的项目会吸引更多代理贡献、更快地发现bug、更顺畅地接纳人类贡献者。那些把"AI友好"当作可选项的项目，可能会发现随着生态系统围绕它们转变，维护变得越来越困难。