CI的绿灯，可能成了新瓶颈

这周约一个做代码审计Agent的创始人聊。他们现场演示：Agent按需求生成十几个PR，CI全绿，流水线漂亮。但旁边的工程负责人脸黑了一半。因为合并审查的人不够。代码是机器写完了，决策还是人来做。

这场景挺典型。过去CI默认人是慢变量。一个团队一天写多少代码，一个变更影响哪些模块，测试能不能覆盖，都有经验值。CI把两件事绑在一起：执行验证和协调合并。跑测试、过静态检查、审批、合并，一条链解决。前提是人不会一夜之间把仓库淹掉。

Agent把前提打穿了。代码生成速度上去，行为却不按预设路径走。同样一个目标，不同Agent可能生成不同补丁。测试通过，也不等于意图正确。你原来指望CI做守门员，结果守门员前面涌来的是洪水。

旧路线：给CI装个AI插件

第一条路线很常见。把AI塞进现有CI，做失败分析、预测该跑哪些测试、识别异常构建、定位根因。这条路线有商业价值，尤其对大型企业。他们最怕流水线变慢、噪音太多、没人看日志。

但我判断这类东西更像降本增效工具。客户买的是省人力、省时间。壁垒来自集成深度，不是算法本身。今天你能接Jenkins，明天大厂接GitHub Actions，后天GitLab原生做一套。估值逻辑容易按SaaS用量走，天花板取决于它能嵌入多少流程。

新路线：做合并前的信任层

第二条路线更激进。不是帮CI跑测试，而是重做Agent时代的合并控制面。它要回答的不是测试有没有过，而是这段代码为什么可以进主干。谁生成的，依据什么上下文，改了什么风险面，哪些测试是Agent自己补的，哪些是人类确认的，回滚路径是什么。

这有点像我做嵌入式AI时反复碰到的问题。算法只是入口，真正卡人的是工程化和迭代机制。谁能把验证变成一条可审计、可回放、可追责的链，谁就有定价权。

这个技术壁垒有多高，我目前看到三层。

• 工具链耦合。必须接代码仓、流水线、工单、审批、日志、制品库，少一环就只是玩具。
• 策略表达。不同团队、不同合规场景，合并标准不一样。把标准做成可配置，不是可聊天。
• 责任边界。Agent生成代码出了事故，谁签字，谁回滚，谁赔，这些不是模型能自动解决的。

商业模式上，我更倾向按风险定价，而不是按席位。低风险前端PR，和动数据库迁移的PR，验证成本完全不同。如果产品能把风险识别清楚，就有机会从工程预算里拿钱。退出路径也相对清楚：独立平台，或被开发工具大厂、安全厂商、云平台收购。前者要熬，后者看能否形成标准接口。

不过这里有个坑。CI本身已经够重，Agent又把它变得更重。很多团队不是缺更多规则，而是缺能落地的规则。如果新控制面让开发者更烦，它就会变成下一个没人用的审批系统。

我最近看这类项目，会问一个问题：当Agent开始自己生成测试、自己解释失败、自己决定是否回滚，人类还要不要守住那个合并按钮。这个问题没有答案，但答案会决定这家公司是工具，还是基础设施。

---

📌 本文编译自 Hacker News，原文：https://stack72.dev/ai-broke-the-assumptions-behind-ci/

版权归原作者所有，本文为基于公开报道的编译与独立分析。