B2B SaaS 中 AI 编码代理的运营风险
如今在 B2B SaaS 领域，我接触到的每一位运营人员都承受着同样的压力。董事会希望公司借助 AI 加速发展，供应商则承诺能带来巨大的生产力提升。
有些提升确实是真的。我每月参加一个 AI 编码代理从业者的交流会，从他们的现场演示中可以看到，现在提交的 PR（Pull Request，拉取请求）数量大幅增加。
今年早些时候，我开展了一个试点项目，用 AI 代理来生成单元测试。之所以选单元测试，部分原因是它们确实很需要，但更主要的是它们不在核心生产流程中。这是一个很好的学习案例，试点工作的周期时间明显缩短了。
我并不是一个只想用 AI 加速自己工作的独立开发者。我是一名工程负责人，正在研究如何安全地大规模使用 AI。如果放任不管，AI 代理可能会生成大量看似合理、但绝不应该靠近生产环境的代码。
那些登上新闻的故障通常比较戏剧化：某个面向消费者的平台上线了由 AI 生成、AI 审查、且没有任何人工参与的代码，结果是一个简单的漏洞，攻击者就能接管用户账号。这件事在新闻上热炒几天，一些用户抗议离开，然后事件就渐渐被人遗忘。
但在垂直领域的 B2B SaaS 中，故障并非如此运作。
编码代理会做出一个看似合理的改动——不是明显离谱，也不是所谓的「AI 幻觉」。只是那种疲惫的审查者扫一眼就放过的改动，因为测试通过了，PR 看起来也合理。但「看似合理」和「正确」不是一回事。一个看似合理但实际错误的改动，可能会破坏客户的工作流程，引入一堆小纸片式的缺陷，或者制造一个安全漏洞。
当然，没有 AI 介入时也会发生这种情况。但 AI 让你更频繁、更快速地制造这些问题。
AI 编码代理在 B2B SaaS 中的运营风险
最近我就亲眼目睹了一件事。我的一位客户的交付链中有个供应商，推送了一个糟糕透顶的版本，里面全是回归问题，还新增了一个性能瓶颈。我不知道这是不是AI导致的，但这不重要。我客户的反应很干脆：这种事情只有一次机会。他们在行业里人脉很广，等别的买家刚要跟这家供应商的销售团队接触，客户的评价早就传到他们耳朵里了。
消费者端的AI失败之所以容易被淡忘，是因为普通用户根本不认识其他所有用户。但B2B市场不一样。买家之间互相认识。大家坐在同一个标准委员会里，参加同一场区域会议，一旦有供应商让他们日子不好过，他们就会互相通气。在一个小型的B2B垂直领域中，一次严重的失败就会变成你甩不掉的名声。
所以，不要把AI编码代理当成一个提升生产力的功能来用。要把它当作一种运营风险来对待。
我们在运行生产软件时，做了很多事情来限制风险：良好的监控和告警、出问题时自动通知工程师的机制、事件响应纪律、以及大量的单元测试和集成测试。
这些做法之所以存在，是因为生产系统会出故障。优秀的运维人员会尽量在客户发现之前就捕获问题。如果做不到，他们就限制损害、修复问题，然后从中吸取教训。
AI编码代理也应该纳入同样的运营模型。你做了什么来确保你的代理在已知边界内运行？当它开始偏离边界时，你又如何知道？
我所说的“代理”，不是指什么神奇的程序员替代品。而是指在你交付流程中的一个定制工具，专门针对你的代码库、架构、业务规则和故障模式，完成一项有限的、受约束的任务。
我今年使用的方法很简单：先用人工判断“浸泡”一个新代理，直到你尽可能多地找出它的故障模式。然后，你构建测试、约束条件和审核关卡，让它始终在已知边界内运行。只有到了这一步，你才让它以真正的规模去干活。
AI编码智能体在B2B SaaS中的操作风险
我合作的那些团队正在创建范围很窄的智能体：一个专门写单元测试，另一个在一个有限的功能区域内修复缺陷。这听起来可能有点小家子气，但我认为这才是正确模式。
风险不仅仅在于智能体做了糟糕的改动。真正的危险在于：它做了一堆看起来合理的改动，拉取请求（Pull Request）很长，每个人都在赶进度，于是人类审查开始走马观花。
相比直接放手不管、庆祝拉取请求数量，这种起步方式要慢得多。但之后每个新智能体的搭建都会更快，因为你已经建好了脚手架、积累了经验。测试、审查习惯、约束条件和可观测性这些都可以复用和优化，而不必每次都从头发明。
最终，工作不是"盯梢智能体"，而是"运行一套系统"。
当信任建立起来之后，没有人应该永远手工检查每一个输出——那同样不可扩展。但你仍然需要留意"漂移"（drift）。你需要知道，工具何时开始超出你验证过的边界运行。
最困难的部分是在智能体工作时盯着它们。你需要抓住它们开始超出已验证边界——也就是开始漂移——的那一刻，赶在一堆看似合理但实际错误的改动进入生产环境之前。传统监控是为"相同输入可靠产生相同输出"的系统构建的。智能体比这要乱得多。我认为还没有人完全解决如何"好好盯着它们"这个问题。
这就是为什么迄今为止，我总是从"需求强烈且影响范围小"的地方开始。
我选一个团队确实感到痛苦，但出问题不太可能影响客户的场景。我提过单元测试和缺陷修复是很好的选择。文档更新和范围很小的重构也值得考虑。
老天爷，千万别从客户可见的工作流开始。也别从授权、计费或数据迁移开始。这些领域最终也会受益于智能体，但先在一些"不可能不小心搞砸公司"的事情上学习吧。