当AI开始自动给你的代码库提PR，我们该担心什么 | 文档 GitHub刚刚发布了一个野心勃勃的

当AI开始自动给你的代码库提PR，我们该担心什么 | 文档 GitHub刚刚发布了一个野心勃勃的新项目：Agentic Workflows。

设想一下，每天早上你打开电脑，发现代码库里已经躺着几个自动生成的PR，文档更新了，测试覆盖率提高了，CI失败被自动分析了，Issue也被自动分类了。

听起来很美好，对吧？

这套系统的核心思路是把AI编程代理塞进GitHub Actions里，用Markdown文件定义任务，然后让Copilot、Claude或Codex这些模型去执行。

官方强调了安全设计：默认只读权限、沙箱执行、网络隔离、工具白名单。

但社区的反应相当精彩。

有人挖出了一个真实案例：Dependabot创建了一个版本升级的Issue，AI代理接手后，没有用正确的go get命令，而是直接在go.mod里加了一个replace语句。

这根本不是正确的做法。

更离谱的是，PR里还混入了一些无关的改动，AI审查员指出了问题，但人类维护者没注意就直接合并了。

这暴露了一个根本性问题：AI代理并没有真正理解它在做什么，它只是在模式匹配字符串，然后生成看起来正确的新字符串。

类似的问题在npm的package.json里也很常见。

代理不会用npm install命令，而是直接编辑JSON文件，然后幻觉出一个版本号。

重命名变量时更糟糕，代理不会用IDE的重构工具，而是暴力用字符串替换，然后编译、看报错、再改，烧掉大量算力。

有开发者分享了应对策略：在提示词里明确写上「添加依赖时用cargo add，不要指定版本」，问题就消失了。

但这治标不治本，当上下文窗口变长，模型遵循指令的能力会下降。

更深层的担忧是：执行安全和决策验证是两回事。

权限控制解决的是代理能做什么，但真正的失败往往来自代理在权限范围内做了错误的事情，而且信心满满。

还有人吐槽GitHub的优先级问题。

Actions的核心功能还有一堆bug没修，付费用户遇到问题一年了还没解决，现在却在往上面堆AI功能。

有开源维护者直言：我交的钱被拿去搞AI噱头，而不是改进核心产品，这让我很恼火。

域名选择也引发了争议。

官方用的是github.github.io而不是github.com，这违反了人们被教导的防钓鱼规则。

GitHub自己说过github.io是用户生成内容的域名，官方内容应该在github.com上。

现在自己打脸，等于在训练用户忽视域名安全。

不过也有人看到了价值。

把代理放在一个能访问CI、Issue和源码的中心化平台上，确实是个合理的位置。

关键是要把AI调用和实际应用分开，这个架构思路是对的。

项目团队在评论区积极回应，承认这还是早期研究，欢迎反馈。

他们修复了一些被指出的问题，包括那个go.mod的案例。

自动化本身其实不是问题，问题是我们还没有好的方法来验证AI的决策质量。

代码不只是字符串，它承载着组织的知识。

让AI慢慢改进代码库是个好想法，但前提是每一步都经过人类审视。

否则，你得到的不是助手，而是一个需要你不断收拾烂摊子的实习生。