本文整理自 QCon 北京 2026 闫文亮分享《AI赋能的 Feature Flag 全生命周期治理》，通过AI音视频总结工具Ai好记进行转录整理，以下为视频转文字整理后的会议笔记内容。

Feature Flag 好用，但用多了会积累隐形技术债，最后变成定时炸弹。快手主站技术部把标题起得很形象，让开关自我消亡，用 AI 来做 Feature Flag 的全生命周期治理。

这篇从陈年老故障讲到 AI 治理 Agent 从 demo 到落地，再到安全护栏和自愈机制，对做代码治理、做 AI 驱动工程的团队很有借鉴价值。

摘要

本文基于快手主站技术部在 QCon 北京 2026 的分享，系统阐述了Feature Flag（功能开关）从技术债积累到 AI 治理的全过程。主要内容包括：

1. 问题根源：Feature Flag 虽能降低发布风险，但过度使用会积累隐形技术债，导致维护成本飙升、计算与带宽浪费、隐藏稳定性风险。
2. 治理困境：加开关成本极低（一分钟写 if），删开关成本极高（需梳理逻辑、评估风险、测试发布），形成“只增不减”的死循环。
3. AI 治理演进：从运动式治理 → AI 开关治理 Agent → AINative 开关治理，让开关“自我消亡”。
4. 关键技术：
   • 多轮对话：基于 Session 存储上下文，通过追问修正错误。
   • 安全护栏：对 AI 修改结果进行正确性校验，防止错误代码上线。
   • 自净化与自愈：构建让 AI 觉得治理效率高的环境，实现持续自动化治理。
5. 核心价值：用 AI 打破“加开关容易删开关难”的循环，通过“AI 提效 + 安全护栏兜底”的思路，将治理准确率提升到业务可接受水平，最终实现开关的自动化生命周期管理。

本文对从事代码治理、AI 驱动工程的团队具有重要参考价值，展示了如何将 AI 能力系统化应用于技术债治理的实际路径。

从一个陈年老故障讲起

快手 APP 启动时会调用后端接口，某次升级新功能返回了不兼容字段，引发APP崩溃。

后端回滚代码，但崩溃发生在启动时还没拉到修正代码，APP 再次崩溃，形成死循环。当时安全模式不完善，唯一恢复方式只能是用户卸载重装，非常棘手。

这个故障带来的思考是，能不能发布新功能时更自信、更从容？于是引出了 Feature Flag，上线新功能的安全阀门，可以让少量用户先体验，观察监控没问题再逐步放量。

它既能降低线上风险、出问题快速回滚，更重要的把代码发布和功能发布解耦。

比如 A、B、C 三个需求一起上线，B 出问题，没开关就得连 C 一起回滚，有开关只需关 B。

在 AI Coding 时代，大家都不自己写代码了，发布 AI 代码更没底，开关就越发重要。

Feature Flag 的隐形技术债

快手生产代码上开关极多，几步之内就有一个，而且链路业务复杂，搜索里还夹杂本地生活、电商的开关，越积越多、职责不清。开关多会带来四个问题。

一是代码维护成本飙升。

新人接手要在开关堆里梳理逻辑，AI 时代大家和新人一样对代码不熟，AI 读代码也要查各种开关返回值。

二是计算成本浪费。

每次判断都要看开关走哪个分支，快手短视频主业务每秒调用开关次数高达 1500 亿次。

三是浪费带宽资源。

客户端也要用开关做功能发布，后端要下发大量开关值，每年带宽成本几百万。

四是隐藏的稳定性风险。

过期开关偶发拉不到推送值，走旧逻辑触发线上问题，业务里确实遇到过，推全上线的过期开关没下线旧逻辑，某天触发 bug，连夜排查很久。

为什么没人治理开关

核心是加开关和删开关的成本严重不对称。

加开关，一分钟写个 if 语句,解决上线风险、带来自信、发版解耦,顺手就加了。

删开关，要梳理上下游业务逻辑、评估下线风险、改代码、测试验证、发布上线，短则一小时长则更久,而且一点收益没有还要担风险。

加上离职交接「相信后人的智慧」，后人也不知道开关是干啥的、不敢下，跨部门合作开关职责不清没人敢动，就形成了越积越多、谁也不删的死循环。

快手某部门开关每年都有大几千的增长量。MIT 教授也有句话说，人工智能就像全新的信用卡，让人以前所未有的方式积累技术债，AI 普及后技术债会爆发式增长。

传统治理方式效果都有限。

1. 平台规范治理(设过期时间、审计看板)依赖业务自觉；
2. 工程脚本扫描删除遇到嵌套或复杂逻辑容易改错；
3. 专项治理行动(拉一群人开周会强推)有效但是一阵风，治理完几个月就反弹。

结果就是治理死循环，治理速度赶不上新增速度。直到 AI 出现才打破。外部大模型技术迭代、API 成本降低、代码理解和修改能力成熟，内部迫切需要安全高效的治理方式,时机刚好。

AI 治理 Agent 从 demo 到落地

演进分三个阶段，25 年前是运动式治理，25 上半年推出 AI 开关治理 Agent 帮业务提效减少人工介入，26 年至今做 AINative 开关治理，让开关自己去让自己下线。

起点很有意思，某次开发时系统弹出消息说名下有多少开关要治理，随手把需求发给一个 AI Coding 工具(文中称 SRE 的 Coding Agent)，它很快改完且格式逻辑正确。

既然 AI 能搞定单个开关，就想能否规模化，于是直接调大模型 API 做批量治理，很快搭了个 demo。

流程很简单，定位开关用到哪些代码文件，通过 Git OpenAPI 拉源码到本地，把源码和需求提示词交给大模型，改完返回后调 API 提远程 MR。

试用时遇到很多问题，把还在用的 import 语句删了、莫名改大小写。团队用传统的提示词调优方式,禁止删 import、加样本案例、加思维链模式(先思考再改)，让正确率提升到 70% 到 80%。

但在开关治理场景，业务不容许这个准确率，改错一个业务逻辑就是严重故障。

典型错误包括：

1. 方法名与开关名一样把整个方法删了
2. 逻辑改反(false 执行 A 改成 true 执行 A)
3. 开关名混淆(A、B 很像把 B也下线了)、无关代码被乱改

所以结论是，完全信任大模型等于被动等待故障,必须建立完善的安全护栏拦截错误。

多轮对话与安全护栏

受到用 AI 对话框的启发，第一遍回答不符预期就追问，基本能解决，这就是多轮对话。

团队基于 Session 实现多轮对话，因为大模型没记忆，把整个上下文对话存储下来，遇到错误就把历史对话和错误信息一起扔给模型让它修改。

检测 AI 是否有问题，则依赖安全护栏机制对修改结果做正确性校验，防止错误代码透出线上。

自净化与自愈

整个治理 Agent 还设计了自净化、自愈机制，这部分因转录内容所限，详细展开见原场次。

核心方向是让开关治理不只是提效，而是建立一套让 AI 觉得治理效率高的整体环境，最终实现开关自我消亡，从而持续化解技术债。

总结

快手这套 AI 赋能 Feature Flag 治理，核心是用 AI 打破"加开关容易删开关难"的死循环。

从 demo 到落地，关键不是让大模型改得更准，而是建立安全护栏和多轮对话机制兜底，把准确率拉高到业务可接受，再往 AINative 方向发展让治理自动化。

对做代码质量、做 AI 驱动工程的团队,这种"AI 提效 + 安全护栏兜底"的思路很有参考价值。

常见问题

1、Feature Flag 为什么需要治理?
因为加开关简单删开关难，会造成维护成本飙升、计算和带宽浪费、隐藏稳定性风险，积累成技术债甚至定时炸弹。

2、为什么人都不愿意删开关?
删开关要梳理上下游、评估风险、改代码、测试发布，收益为零还得担风险，加上离职交接和跨部门职责不清，就形成了谁也不删的死循环。

3、AI 治理开关怎么从 demo 到落地?
先定位开关代码文件，拉源码交给大模型改，提 MR。用提示词调优把正确率做到 70%-80%，再用安全护栏和多轮对话机制兜底到业务可接受。

4、AI 删除开关改错了怎么办?
不能完全信任大模型，靠完善的安全护栏拦截错误、多轮对话根据历史修正，防止错误代码透出线上，再往自净化自愈的 AINative 方向演进。

以上内容由 Ai好记 转录整理。
Ai好记是一款音视频转图文笔记的AI音视频转录总结工具，支持解析B站、抖音、小红书、小宇宙等平台链接及本地/网盘音视频文件，转录后自动视频转文字生成精华速览、思维导图和结构化笔记等内容形式，帮助你把几小时的视频内容变成可搜索、可复习的图文笔记。