bot 造 bot：有些 PR 人没读就合了

SpaceXAI 的内部做法被摊开讲了一场 45 分钟的分享：Grok Bot 团队正在用 Grok Bot 造 Grok Bot——agent 负责设计、编码、测试、发货，人退到评审位。 流水线的细节比口号耐看：一张 Figma 帧直接变成完整流程稿，一个项目拆给四个工程 bot 分头改，X 上反复出现的 bug 报告自动转成修复提案、没人手工搬运上下文；最激进的一条是，有些 PR 在人读过之前就已经合并了。 这条线值得和另一派做法放在一起看。前面聊过"助手替你答应交易"的事故，教训是出手前该有人点头；而这里的信条正相反——先合并、出问题再回滚。 两种哲学都能成立，差别在回滚成本：能一键撤销的代码合并，赌的是可逆；把住址发给陌生人这种事没有撤销键，赌的就成了不可逆的损失。快与稳的分界线，其实画在"这一步可不可逆"上。 对想复制这套模式的团队，三个前置条件缺一不可：合码前的自动化门禁足够硬（测试、扫描、审查 bot 全绿才放行）；回滚路径演练过不止一次；留给人的只保留"例外才介入"的抽查位。三条不满足，"人没读就合"就不是效率，是埋雷。 另一个被低估的收益是上下文零搬运：bug 报告直接变提案，意味着人省下的不是打字时间，而是转述失真——机器读原话，比听人转述更接近现场。 一场内部分享敢把"PR 先合后看"讲出来，说明回滚文化已经先于监管跟上了——你的团队里，第一个可以放心先合的门禁是哪一道？