AI 辅助编程会成为事故隐患吗？

LLM 辅助编码正在快速普及。对于站点可靠性工程（SRE）团队来说，AI 辅助编程究竟意味着更高效率，还是新的生产事故隐患？

AI 辅助编码正在快速进入软件开发流程。海外某大型科技公司负责人曾透露，公司内部已有相当比例的代码由 AI 编写；另一家海外科技公司也曾公开提到类似趋势。在一些创业公司中，这一比例可能更高。海外某创业孵化机构分享的数据显示，在其某一批孵化企业中，部分公司的代码库几乎主要由 AI 生成。与此同时，AI 代码编辑器的迅速走红，也说明科技行业正在以极快速度接受这类工具。

开发者现在可以比以往任何时候都更快地编写和发布代码。但速度提升并不必然带来软件可靠性提升。在某些情况下，它甚至可能带来相反结果。

LLM 辅助编码的问题，以及对 SRE 的影响

LLM 辅助编码可以显著提升开发效率，让代码编写和部署速度变得更快。但如果缺乏成熟的自动化流程、测试体系和监控机制，更频繁的部署也可能带来更高的系统不稳定性。可靠性团队需要持续关注变更失败率（Change Failure Rate，CFR）等指标，以便尽早识别风险信号。

AI 辅助编码还可能让开发者写出远超实际需要的代码量。这些额外代码往往更冗长、更复杂，不仅会扩大单次变更规模，也会提高系统理解成本。一旦发生生产故障，排查难度也会随之增加。换句话说，代码写得更快，并不等于系统变得更简单、更可靠。

此外，LLM 生成的代码常常“看起来能用”，但未必足够稳定。CI/CD 流水线中的单元测试、集成测试、静态分析和代码审查，确实可以帮助团队发现一部分问题，但它们无法覆盖所有场景。只要测试和审查存在盲区，就仍然会有缺陷进入生产环境的可能。

随着开发者越来越依赖 LLM，他们可能会把更少时间用于深入分析代码，把更多时间用于接受、修改或批准 AI 给出的建议。久而久之，这种变化会降低开发者对代码库的熟悉程度，也会减少团队中的领域专家数量。

所谓领域专家，指的是那些真正理解系统内部机制、依赖关系、运行行为和历史技术决策的人。在复杂系统中，他们往往是事件响应、根因分析和故障恢复中不可替代的关键角色。

这种影响对初级开发者尤其明显。对于尚未建立可靠代码判断标准的初级工程师来说，他们很难像资深开发者那样，凭借经验判断 AI 生成代码是否符合最佳实践。更重要的是，如果他们过早依赖 AI 生成结果，也可能失去通过亲手实践来积累工程经验的机会。

开发团队可能乐于看到功能发布速度变快，但对 SRE 团队来说，领域专家减少与生产事件增加同时发生，无疑会带来更大压力。事件数量上升，会加重响应负担；专家数量下降，则意味着团队在关键时刻更难获得足够深入的系统知识。

与此同时，在 AI 普及带来的效率压力下，很多工程团队被要求用更少资源完成更多工作。因此，企业未必会增加事件响应人员预算。更糟糕的情况是，现有团队规模反而可能被进一步压缩。

AI 能解决 AI 带来的可靠性问题吗？

LLM 辅助开发正在把软件代码的生产速度推向人类手工编写之外。至少，它正在形成一种“工程师与 AI 协同工作”的混合速度。这一趋势很难逆转，SRE 团队也不得不面对现实：如果 AI 正在改变软件开发的速度和规模，那么可靠性工程也需要借助 AI 工具来应对新的挑战。

简单来说，AI 驱动开发带来的规模和速度问题，可能也需要 AI 驱动的可靠性工具来缓解。

现代事件管理平台已经开始使用 LLM 自动化处理一些耗时的手工任务。例如，通过导入与事件相关的协作频道记录和会议纪要，基于 LLM 的聊天机器人可以快速帮助一线响应人员了解事件进展，也可以为管理层生成简洁清晰的状态更新。这些数据还可以进一步用于生成初步的事件报告和复盘分析。

与此同时，新一代基于 LLM 的工具正在出现，并有望显著增强 SRE 团队的能力。这类工具有时被称为 AI SRE。

AI SRE 可以快速处理数千个数据点，包括系统指标、代码变更、日志和链路追踪信息，从中识别潜在问题。它们可以响应告警、评估影响范围、定位可疑变更，并给出修复建议。对于研发团队来说，除了引入 AI SRE，更重要的是先把需求、开发、测试、发布、故障复盘和知识沉淀等环节打通。例如借助 PingCode 这类智能化研发管理工具，将研发全生命周期中的目标、需求、代码变更、测试发布和 Wiki 经验沉淀连接起来，也能帮助团队更快追踪变更来源、定位风险，并让可靠性改进有据可依。

需要明确的是，AI SRE 工具并不是为了取代人类工程师，而是为了增强团队能力，让工程师能够更快、更高效地解决问题。

不过，必要的防护措施仍然至关重要。LLM 工具和人一样，也会犯错。因此，AI SRE 工具在初期最好以“只读”模式运行：它可以发现问题、分析原因、提出修复建议，但不能直接执行修复操作。

如果 AI SRE 工具能在建议旁边给出置信度，响应人员就可以更快判断该建议是否值得采纳。例如，如果系统判断“配置错误导致服务中断”的可能性为 92%，团队就应该认真对待这一诊断结果；如果置信度较低，则应继续采用传统排查方法，而不是盲目相信 AI 的判断。

当团队准备赋予 AI SRE 更多主动职责，甚至允许它部署修复方案时，仍然必须让它遵循与人工编写代码相同的工程防护流程，包括代码审查、CI/CD 检查、灰度发布和金丝雀部署等。

使用 AI SRE 时需要注意什么？

能力越大，责任越大。由于 AI SRE 工具通常需要与代码库、监控系统、日志平台和知识库深度集成，并可能对整个工程组织产生重大影响，企业在采用这类工具时必须谨慎评估。

首先是公司数据安全问题。AI SRE 需要访问大量关键数据，包括代码仓库、知识库、监控指标、日志和链路追踪信息。技术负责人必须清楚了解这些数据会被如何使用：数据会传输到哪里？会存储在哪里？会被如何处理？供应商如何保证安全？是否符合企业自身的数据安全和合规要求？

大语言模型通常依赖大量数据来提升效果，软件供应商也希望利用更多数据来改进其生成式 AI 方案。但这同样会带来风险。此前曾有企业员工将敏感代码和内部资料输入海外某生成式 AI 工具，引发数据泄露担忧。类似地，如果 AI SRE 工具未经充分隔离和约束，就可能将企业专有数据用于模型训练，进而带来数据外泄、竞争信息暴露或安全风险。

除了安全性，成本也是一个关键因素。基于生成式 AI 的系统通常资源消耗较高，运行成本也不低。如果缺乏控制，使用量可能迅速转化为高额支出。基于 LLM 构建的应用，例如 AI SRE 工具，通常会按照 token 消耗计费。每个 token 可以理解为模型处理的一小段输入或输出。发送给模型的数据越多，模型生成的内容越多，总成本就越高。

预算有限的 SRE 团队需要仔细判断什么时候值得调用 AI。对于无需复杂分析的简单事件，或者反复分析也无法产生有效洞察的复杂事件，过度调用 AI 可能并不划算。

最后一个风险，是 SRE 团队可能过度依赖这些工具。如果工程师越来越依赖 AI SRE 来理解系统、定位问题和提出方案，他们自身可能会逐渐与系统脱节。一旦发生重大事件，而 AI 又无法给出可靠判断，团队可能反而难以快速响应，因为他们已经不再真正熟悉自己正在维护的系统。

因此，工程师需要在两件事之间找到平衡：一方面，要持续理解系统运行状态和关键机制；另一方面，也要善用 AI 能力，加速问题定位和事件处理。

我的建议是：正如“凭感觉编程”并不适合企业级软件开发一样，“凭感觉排障”也同样危险。也就是说，SRE 不应盲目信任 AI SRE 的建议，更不能在未经审核的情况下直接应用修复方案。

最后想说

随着 LLM 辅助编码重塑软件工程，SRE 团队必须准备好应对更频繁、也更复杂的生产事件。与此同时，随着“氛围编程”（vibe coding）热度上升，开发者对 LLM 的依赖可能会进一步加深。可以预见，这一趋势还会继续加速，尤其是在一些公司已经开始招聘专门从事氛围编程的工程师之后。

幸运的是，对 SRE 团队来说，推动这些挑战出现的 AI 浪潮，也正在带来新的工具。团队不必简单抵制 AI 驱动的软件开发趋势，而是可以主动拥抱并合理集成这些工具，以满足新的可靠性要求。

真正重要的不是让 AI 取代可靠性工程，而是让 AI 成为可靠性工程的一部分。只有这样，团队才能在开发速度越来越快、系统复杂度越来越高的背景下，继续守住稳定性底线，并在没有顶级互联网公司级别 SRE 预算的情况下，尽可能接近“六个九”级别的可靠性目标。