让开关自我消亡：AI 赋能的 Feature Flag 全生命周期治理
让开关自我消亡：AI 赋能的 Feature Flag 全生命周期治理
本文深入剖析快手在超大规模系统中面临的 Feature Flag 技术债困境，并展示如何借助 AI Agent、双引擎安全护栏和自进化机制，实现从人工治理到 AI Native 开关治理的范式升级。文章完整复盘了治理逻辑、工程落地与演进路径，为行业提供了可复用的实践参考。
一、Feature Flag 的价值与隐形技术债：从业务刚需到技术债陷阱
功能开关（Feature Flag）原本是为了解决“发布新功能顾虑重重”这一痛点。快手曾因后端接口返回不兼容字段导致客户端启动崩溃，回滚后因启动阶段无法拉取修正代码而陷入无限崩溃循环，最终只能引导用户卸载重装。一个标准答案便是 Feature Flag——将功能发布与代码部署解耦。若当时拥有完善的开关能力，新功能可先面向内部用户开放，监控确认无误后再逐步放量，这场大规模故障极可能避免。
更进一步，Feature Flag 允许三个需求同时上线时，仅关闭有问题的功能，不影响其余两个。在 AI Coding 时代，代码由 AI 生成，发布不确定性增大，Feature Flag 的价值更为凸显。
然而，开关太好用导致快手生产代码中堆积了海量 Feature Flag。以搜索业务为例，一段代码中可能包含搜索、本地生活、电商等多个开关，职责逐渐模糊。大量堆积的开关带来四方面问题：
- 代码维护成本飙升：新人需要梳理所有开关逻辑，判断哪些代码已废弃。AI Coding 时代，代码非亲手所写，每个人梳理时都像新人。AI 读取代码时还需查询开关系统返回值，成本更高。
- 浪费计算资源：每次调用都需要判断开关分支。快手短视频主业务每秒开关调用次数高达 155 亿次。
- 浪费带宽资源：客户端需要从后端拉取开关值，单接口下发数量过多。每年因开关下发产生的带宽成本高达数百万元。
- 隐藏稳定性风险：过期开关可能偶发性拉不到推全值，触发旧逻辑导致线上问题。真实案例中，一个推全数年的开关因小 Bug 未拉到值，团队排查良久才定位。
尽管危害明确，业务团队仍缺乏治理动力：加开关极易，一分钟写个 if 语句；删开关则需要梳理上下游、评估下线风险、修改代码、发布测试，耗时且风险高。组织上，离职人员留下的开关无人敢动，跨部门职责不清，债务越积越深。从快手某部门数据看，开关数量每年增长数千。
麻省理工学院教授曾预言：“人工智能就像一张全新的信用卡，让我们以前所未有的方式来积累技术债。”若 AI 生成代码成为常态，技术债将爆发式增长。过去尝试过的平台规范、自动化脚本、专项治理等手段，或依赖自觉性，或易出错，或治标不治本，形成“治而不绝”的死循环。直到 2024 年下半年，内外部条件成熟——大模型能力提升、API 成本下降、AI 基础设施持续投入——快手跨入 AI 治理新时代。
二、治理 Agent 的演进与工程落地：从 Demo 到生产级系统
回顾快手开关治理历程：2025 年前以运动式治理为主，效果差；2025 年上半年推出 AI 开关治理 Agent，极大减少人工介入；2026 年起构建 AI Native 开关治理，核心思想是“让开关自己下线”，而非让人全程治理。
2025 年上半年，一次偶然的 Cursor 体验激发了规模化治理的想法：既然 AI 能搞定单个开关的治理，何不批量调用大模型 API？我们快速搭建了 Demo：定位开关引用的文件，通过 Git API 拉取源代码，连同提示词交给大模型，修改完成后提起远程 MR。然而，这个“迫不及待”投入试用的 Demo 暴露出大量问题：AI 会误删 import 语句、莫名修改大小写、将方法名与开关名混淆（直接删除整个方法）、将逻辑改反、或修改无关代码。我们尝试在提示词中加入禁止项、样本案例、思维链等优化手段，在简单场景下正确率提升至 70%–80%。但开关治理场景中，业务绝不容忍哪怕一个错误——一个误删即构成严重线上故障。
于是，我们意识到不能完全信任大模型，必须构建完善的安全护栏。
2.1 第一道安全护栏：多轮对话与校验框架
借鉴 Andrej Karpathy 的“Vibe Coding”体验和多轮对话纠偏思想，我们实现了基于 Session 的多轮对话机制（大模型无记忆，需持久化存储上下文）。当校验失败时，将历史消息与错误信息一并返回给大模型，使其在已有基础上改进。同时，构建可扩展的校验框架，包含两类检测插件：
- 逻辑检查插件：检查是否误删无关开关、布尔逻辑是否改反、业务逻辑完整性、是否误删非开关相关代码。
- 编译检查插件：检查代码是否符合 Checkstyle、语法错误、流水线编译是否通过。
流程是：源代码和指令交给大模型 → 结果经第一道安全护栏校验 → 若未通过，将错误信息反馈给大模型继续迭代，直至所有检测通过。
2.2 第二道安全护栏：从人工兜底到确定性程序检测
安全护栏无法拦截所有 Bad Case，最初我们尝试用大模型替代人工 Review（三个大模型独立 Review，少数服从多数）。但问题在于：无法保证评测大模型的正确性，本质上是用概率解决概率，仍需要人工全部复核，未降低参与度。
受论文《程序辅助语言模型》启发——其核心思想是让大模型输出程序，再由解释器执行——我们联想到一个实践：让大模型先生成脚本，人工 Review 脚本，再由脚本执行，几乎不出错。我们将此思想应用于治理：AI 改完代码后，再使用 AST（抽象语法树）引擎将同一段代码重改一次。如果 AST 引擎改出的代码与 AI 改出的完全一致，则无需人工复核；不一致时再人工介入。
AST 引擎采用规则加有向图的架构：规则原子化（一条规则只做一件事，如 if 清理、删除字段、删除方法），由有向图驱动逐步执行，实现确定性的程序修改。
三、AI Native 治理范式：从“人治理开关”到“开关自我消亡”
AI 开关治理 Agent 的成功落地让我们意识到：真正的范式升级不是让人用 AI 辅助干活，而是构建一套让 AI 高效治理开关的整体环境。这意味着开关的创建、使用、下线全流程都应具备“自我消亡”的基因。例如，创建开关时自动关联业务上下文、设定预期下线时间；AI 定期扫描代码库，识别已推全或长时间未变的开关，主动发起下线流程；安全护栏与自动修复机制持续进化。
这一自进化系统中，AI 不仅处理开关，还持续学习新的 Bad Case 模式，更新校验规则，使得治理能力螺旋式提升。
关键要点
- Feature Flag 是双刃剑：在解决发布风险的同时，不加治理会累积为沉重的技术债，影响维护、性能、带宽和稳定性。
- 纯规则或纯大模型方案均有局限：规则易错漏，大模型不能完全信任，需通过多轮对话和强校验框架构建安全护栏。
- 引入确定性程序检测（AST 引擎）与 AI 生成代码对比，可大幅降低人工复核需求，实现安全与效率的平衡。
- AI Native 治理的核心是让开关“自我消亡”：从创建到下线全流程支持 AI 自动发现、自动评估、自动修改、自动验证，并持续自进化。
- 治理速度必须超越开关新增速度，否则债务只会滚雪球。AI 的介入彻底打破了这一死循环。
