本文整理自 QCon 北京 2026 闫文亮分享《AI赋能的 Feature Flag 全生命周期治理》通过AI音视频总结工具Ai好记进行转录整理以下为视频转文字整理后的会议笔记内容。Feature Flag 好用但用多了会积累隐形技术债最后变成定时炸弹。快手主站技术部把标题起得很形象让开关自我消亡用 AI 来做 Feature Flag 的全生命周期治理。这篇从陈年老故障讲到 AI 治理 Agent 从 demo 到落地再到安全护栏和自愈机制对做代码治理、做 AI 驱动工程的团队很有借鉴价值。摘要本文基于快手主站技术部在 QCon 北京 2026 的分享系统阐述了Feature Flag功能开关从技术债积累到 AI 治理的全过程。主要内容包括问题根源Feature Flag 虽能降低发布风险但过度使用会积累隐形技术债导致维护成本飙升、计算与带宽浪费、隐藏稳定性风险。治理困境加开关成本极低一分钟写 if删开关成本极高需梳理逻辑、评估风险、测试发布形成“只增不减”的死循环。AI 治理演进从运动式治理 → AI 开关治理 Agent → AINative 开关治理让开关“自我消亡”。关键技术多轮对话基于 Session 存储上下文通过追问修正错误。安全护栏对 AI 修改结果进行正确性校验防止错误代码上线。自净化与自愈构建让 AI 觉得治理效率高的环境实现持续自动化治理。核心价值用 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 普及后技术债会爆发式增长。传统治理方式效果都有限。平台规范治理(设过期时间、审计看板)依赖业务自觉工程脚本扫描删除遇到嵌套或复杂逻辑容易改错专项治理行动(拉一群人开周会强推)有效但是一阵风治理完几个月就反弹。结果就是治理死循环治理速度赶不上新增速度。直到 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%。但在开关治理场景业务不容许这个准确率改错一个业务逻辑就是严重故障。典型错误包括方法名与开关名一样把整个方法删了逻辑改反(false 执行 A 改成 true 执行 A)开关名混淆(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站、抖音、小红书、小宇宙等平台链接及本地/网盘音视频文件转录后自动视频转文字生成精华速览、思维导图和结构化笔记等内容形式帮助你把几小时的视频内容变成可搜索、可复习的图文笔记。
)
