不要让AI推送到GitHub：我的惨痛教训

不要让AI推送到GitHub，除非你审阅过。让它审查你的改动、写提交信息、准备拉取请求——但推送这一步必须由人来做。这条规则我是用昂贵的方式学到的：一次未经审阅的推送，把我数据库的主密钥公开到了互联网上，清理花掉了我再也要不回来的四个小时。

下面讲清楚到底发生了什么，AI在你的代码历史上该做什么、不该做什么，以及一套让你既能保持速度、又不用担惊受怕的工作流。

AI把我的密钥推上GitHub的那一天

当时我在构建FIKR Space，我的SaaS平台。进展飞快。AI在帮我处理一切。

有一天我对它说：“提交这些改动，并推送到main。”

它照做了。没有询问。没有给我看它在提交什么。

结果我不小心把Supabase服务密钥——那把能打开我整个数据库的主密钥——放进了一个配置文件里。它现在进了git历史。在GitHub上。公开的。

我不得不立刻轮换所有密钥，强制推送以从历史中抹掉那次提交，检查每一个相连的服务是否出现安全漏洞，并花了四个小时去修复一件三十秒的审阅本可以避免的事。

教训是：永远不要盲目地把git交给AI。但这个故事还有同样重要的后半段——只要用对方式，AI在git上太强了。如果git对你还是个模糊的概念，先从写给非技术创始人的git入门开始，再回来；本文讲的是AI在其中的位置。

不要让AI推送到GitHub：它应该做什么

在提交之前审查每一处改动。每次提交前，我都会运行一个保存好的审查命令。AI会读取到底改了什么，检查每个被修改的文件有没有bug、遗留的调试输出和安全问题——硬编码的密钥、暴露的密钥——并提出改进建议。一个真实的例子：我正要提交支付处理代码的改动。审查发现了我遗留的一个硬编码测试API密钥、支付失败时缺失的错误处理、草率的类型写法，以及一个我忘了更新的测试文件。全都在提交之前被抓了出来。

替你写提交信息。好的提交信息很难写，AI让它变得轻松。审查完改动后，它会起草一条清晰、描述详尽的信息，列出增加了什么以及为什么。需要的话我可以修改，但通常第一次就对了。

准备你的拉取请求。功能分支准备好后，AI会审阅其中的每一次提交，写出标题和描述，列出改动清单，并加上测试说明。专业、完整，每个功能为我节省三十分钟的写作时间。

理清合并冲突。当一个文件的两个版本相撞时，AI会读取两个版本，理解每处改动的意图，给出同时保留两边改进的解决方案，并解释为什么这样选。比手工对比版本快得多。

AI绝不能做的六件事

1. 未经确认就推送到main分支。main是你的用户看到的内容。务必确认。一定要。
2. 未经明确许可就强制推送。强制推送会改写历史，也可能毁掉历史。只有在你确切知道原因时才用。
3. 不问就删除分支。分支不值钱。别让AI自动清理它们。
4. 不审阅就提交。这条规则本可以保住我的密钥。每次提交前都要审阅改动。
5. 跳过你的安全检查。自动化的提交前检查有它存在的理由。绝不要让AI绕过。
6. 改写不是它创建的提交。修改别人的提交就是改写共享历史——只要有别人碰这个项目，就很危险。

注意其中的规律：这份清单上的一切，要么不可逆，要么是公开的。AI可以起草任何东西；但它不确认任何东西。

本书The Solopreneur RevolutionLuis Gonçalves 讲述如何在不辞职的情况下用 AI 打造独立创业者事业。获取本书 →

回报：每个功能从30分钟降到4分钟

认真把这套设置好的理由，不只是安全——还有速度。围绕一个功能的git杂务，在使用前后我的耗时如下：

我每天提交五到十次。每天节省130–260分钟。在我构建FIKR Space的十一个月里，这就是数百个小时——由一位还会抓出我本会上线的bug的助手夺回来的。

安全的工作流，一步一步来

1. 做出你的改动。
2. 对所有改动运行你的AI审查命令。
3. 修复它标出的问题。
4. 让AI起草提交信息；你批准或修改。
5. AI创建提交。
6. 由你推送——或者在AI推送之前，由你明确确认。

以及它底下的规则：提交前一定审阅差异，绝不把密钥放进代码（它们属于环境变量），推送到main务必确认，让AI起草、由你批准，拿不准的时候就手动做。

未经审阅的推送，是AI伤害你最响亮的方式，但它和那种悄无声息的失败是同一种模式——接受你从未检查过的输出，直到损害不断累积。这个故事更缓慢的版本，是AI如何破坏你的代码库。

12 周企业职业生涯从来都不是计划申请加入 Solopreneur Accelerator。立即申请 →

常见问题

为什么推送比提交风险更大？

提交是你机器上的本地快照——那里出错是私密的，也容易撤销。推送则是把这些快照发布到GitHub，在那里它们可以被看到、被克隆、被抓取。我泄露的密钥，是在被推送的那一刻才变成一场耗时四小时的紧急事件。这就是为什么推送始终是需要人来做的那一步。

如果密钥真的流到了GitHub，我该怎么办？

一旦它落地，就当它已经泄露，即使你几秒钟后就删掉——自动化的抓取程序一直在监视公开仓库。立即轮换密钥，从历史中抹掉那次提交，并检查这个密钥能访问的每一项服务是否有可疑活动。然后修复根源：密钥放在环境变量里，绝不放在git会追踪的文件里。

我能让AI推送吗？

可以——在它向你展示即将推送的确切内容、而你明确确认之后。规则不是“AI永远不碰git”；我大部分git工作流都由AI运行。规则是：任何不可逆或公开的事，没有你先看过就不会发生。

审查每一处改动不是很慢吗？

恰恰相反，因为审查的重活由AI自己干。我经过审阅的工作流每个功能只需4分钟，手工则要30分钟——而且它在硬编码密钥、缺失的错误处理和被遗忘的测试上线之前就抓出来了。我花四个小时清理泄露密钥，代价就是仅此一次跳过了两分钟的审阅。