让开关自我消亡：AI 赋能的Feature Flag 全生命周期治理

本文来自微信公众号： InfoQ ，作者：QCon，原文标题：《让开关自我消亡：AI 赋能的 Feature Flag 全生命周期治理》

本文整理自快手资深服务端架构师闫文亮在QCon全球软件开发大会2026北京站的分享《让开关自我消亡：AI赋能的Feature Flag全生命周期治理》。他在分享中对AI赋能开关全生命周期治理的完整实践进行了复盘，内容涵盖从治理困局、AI Agent的工程落地，到双引擎安全护栏、自进化机制，以及AI Native治理范式的演进全过程。

以下是演讲实录（经InfoQ进行不改变原意的编辑整理）。

1Feature Flag价值与隐形技术债：从业务刚需到技术债陷阱

快手APP在启动时会调用后端服务器的一个接口。有一次，这个接口因升级新功能返回了一个客户端不兼容的字段，造成APP崩溃。后端同学发现后立刻对代码进行了回滚，但由于崩溃发生在启动阶段的极早期，客户端此时还没有拉到修正后的代码，于是再次崩溃。启动即崩溃，再启动再崩溃，由此陷入无限循环。当时客户端的“安全气垫”和“安全模式”还远未完善，最终只能引导用户卸载重装。可以想象，如果你是这个需求的后端研发，心情会是怎样的——极度匆忙，连滚带爬。彼时大家必然在反复追问一个命题：怎样能让发布新功能更加自信，从从容容、游刃有余？

这个问题的一个标准答案，就是Feature Flag，即功能开关。它本质上是一种使功能发布与代码部署解耦的软件技术。理论上，如果当时拥有完善的开关能力，新功能可以被优先开放给内部用户，待监控确认无误后再逐步对外放量，这场大规模故障就很可能不会发生。

更进一步，Feature Flag可以将代码发布和功能发布完全解耦。设想一个场景：ABC三个需求一起上线，如果B出了问题，没有开关就只能把三个需求整体回滚，导致A和C被迫延期；而有了开关，仅需关闭B功能即可，A与C不受任何影响。正因如此，在如今AI Coding时代，大家已经不自己写代码了，全都是AI生成代码，在发布AI代码时心里可能更加没底，就愈发需要Feature Flag来帮助建立发布自信。

然而，也正因为开关太好用，快手的生产代码中存在着数量极为庞大的Feature Flag。毫不夸张地讲，代码几步之内就能发现一个开关。以快手搜索业务的一段代码为例，其中不仅包含着搜索自身的开关，还夹杂着本地生活的开关、电商的开关等等。原因是快手的业务链路极为复杂，搜索某个内容时可能会下发本地生活Feed或电商商品，各类开关因此越积越多，职责划分也逐渐模糊。

大量堆积的开关带来了四个维度的切肤之痛。首先是代码维护成本飙升：新人接手项目时，必须在一堆开关里仔细梳理逻辑，判断哪段代码有效、哪段已经废弃。在AI Coding时代，由于代码并非自己亲手所写，每个人在梳理开关和业务时都像新人一样，成本同样高昂。尤其当AI去阅读代码时，它需要去查询各个开关系统的返回值以确定走什么逻辑分支，这又进一步拉高了成本。第二是浪费计算资源：每一次调用、每一次逻辑判断，都意味着要判断开关到底走哪个分支，日积月累也是不小的损耗。我们查得快手短视频主业务（不包括上下游），每秒调用的开关次数就达155亿次。第三是浪费带宽资源：客户端同样需要使用开关进行功能发布，开关值需要后端服务下发，导致单个接口下发的开关数量极多，带宽成本惊人。快手每年仅因开关下发而产生的带宽成本就有几百万。第四是隐藏稳定性风险。过期开关会偶发性地拉不到已推全的值，导致走到旧逻辑，触发线上问题。真实的案例是，一个早几年就已经推全的开关，旧逻辑始终没有下线，开关被遗忘，旧逻辑也无人维护。某一天某个小Bug导致开关没有拉到值，异常立刻被触发，业务团队连夜排查了非常久才定位到根因。可以说，哪怕已经推全的开关，如果不加治理，就可能成为一颗随时引爆的定时炸弹。

既然危害如此明确，业务团队为什么仍然缺乏治理的动力？首先，加开关极其容易，一分钟写一个if语句就能解决极大问题——消除发布风险、赋予发布自信、实现部署与发布解耦。但删除一个开关，则需要梳理上下游业务、评估下线风险、修改代码、发布、测试，短则一个小时，长则更长。其次，心态上，加开关是顺手的事，而删开关毫无收益且要承担风险，业务同学自然不愿意主动去做。再次，组织上，离职人员交接时往往会留下“后人的智慧”：我创建的开关我不删，留给后人治理；后人一看，也不知道这个开关是干什么的，下线肯定有风险，干脆放着不动。再加上跨部门合作的开关职责不清，所有人都不敢动。债务越积越多，谁也不愿删除，形成了一个死循环。从快手某个部门的开关增长数据来看，基本上每年都有大几千的增长量。

尤其值得警惕的是，麻省理工学院的一位教授曾预言：“人工智能就像一张全新的信用卡，让我们以前所未有的方式来积累技术债。”人写代码速度有限，债务还有时间修复；如果未来代码都由AI来写，技术债将呈爆发式增长。如果当下不开始治理，后续的时间窗口可能都会错过。过去我们也尝试过多种传统治理手段，例如做平台规范治理，给开关设定下线时间，搭建审计看板，但这依赖于业务的自觉性，执行力度参差不齐；也可能写一些自动化脚本去删除开关，效率尚可，但一遇到代码开关嵌套或业务逻辑复杂的场景，基本就会改错；再熟悉不过的是搞专项治理行动，拉一群人大规模同步进度、强推治理，这种运动式治理确实立竿见影，但往往是一阵风过后不久就反弹，反弹之后再拉一群人再治理，治理完再反弹，形成一个“治而不绝”的治理死循环。治理速度远远跟不上开关新增速度。

直到AI的出现，才真正让我们看到了打破这一死循环的可能。2024年下半年，我们判断，用AI治理开关的内外部条件已经成熟。外部，大模型迭代极快，API成本持续下降，模型在代码理解与修改上的能力已经可靠；内部，我们对高效、安全且尽可能无需人工介入的治理方式有着迫切需求，加之公司AI基础设施持续投入，我们认为时机刚刚好。快手跨入了AI治理的新时代。

2治理Agent的演进与工程落地：从Demo到工程落地

回顾快手开关治理的整体历程：2025年之前，主要采用运动式治理，拉人推业务，效果差、效率低；2025年上半年，我们推出了AI开关治理Agent，帮助业务提效，极大减少人工介入；从2026年至今，我们正在构建AI Native开关治理，其核心思想已不再是人全程治理开关，而是“让开关自己下线”。AI Native强调的是，搭建一套让AI觉得治理效率高的整体环境，而不是让人感觉治理效率高的方式。

把时间拉回2025年上半年，当时我正在使用Cursor开发一个需求，与Cursor来回拉扯调试，反复沟通它都搞不明白的时候，系统弹出了一条消息，告知我名下有多少个开关需要治理。我随手就把这个需求丢给了Cursor，说“开关A已经百分百推全了，帮我把无用代码和开关下线掉”。Cursor很快就完成修改，而且格式和代码逻辑非常正确。这个体验让我们当即意识到：既然AI能搞定单个开关的治理，那能否规模化？不可能让每个人都装一个Cursor一个一个治理，于是我们直接调用大模型API，尝试做批量治理。

我们快速搭建了一个Demo，流程极其简单：第一步，定位到开关被哪些代码引用，找到这些文件之后，通过Git Open API把源代码拉到本地内存中；第二步，将源代码和要修改的需求（即提示词）交给大模型；第三步，大模型修改完后返回，再通过Git Open API提起一个远程MR，流程就此结束。然而，这个迫不及待投入试用的Demo立即暴露了大量问题。比如，AI会把还在使用的import语句直接删掉，也就是“减号两行”的问题；或者莫名其妙更改了大小写。当时提示词调优正火，我们也采取了非常传统的调优方式，例如在提示词中加入禁止项命令、提供样本案例、加入思维链提示，要求模型“先思考再修改，不要直接改，怕改错”。通过这些手段，AI修改开关代码的正确率得到了大幅度提升，在场景较为简单的情况下，正确率一度能达到70%-80%的水准。

但即便是百分之七八十，在开关治理场景中，业务是绝不能容忍的。因为只要改错一个业务逻辑，基本上就等同于一个非常严重的线上故障。我举几个触目惊心的例子：第一种，方法名与开关名完全相同，大模型误把方法当成了开关，直接将整个方法删掉，意味着整个功能模块全部失效。第二种，把逻辑改反，原来为false时执行A，改成了返回true时执行A，后果更严重。第三种，开关名混淆，开关A和开关B命名极其相似，我让AI下线A，结果它把B也一并下线。第四种，无关代码修改，完全不相干的逻辑，AI莫名其妙也要去动一下。当时我们就清醒地意识到，完全信任大模型，基本等于被动等待故障发生。绝不能指望大模型永远不出错，因此必须建立起一套足够完善的安全护栏，拦截所有错误，防止错误代码透传到线上。

OpenAI的联创Andrej Karpathy曾分享过一种Vibe Coding体验：他使用AI生成代码时，已经不再看结果，全盘接受AI生成的代码，一旦遇到报错信息，就原样复制粘贴过去，什么都不说，往往就能解决问题。我们在日常使用AI对话框时也有类似感受，当大模型第一次回答不符合预期时，采用追问的方式进行纠偏，常常也能解决。这种方式就是多轮对话。

基于这一思想，我们搭建了基于Session的多轮对话实现。大模型本身没有记忆，因此我们将整个上下文对话全部持久化存储。当遇到错误时，将历史消息连同错误信息一并再次提交给大模型，让它在既有上下文的基础上给出改进。那么，有了多轮对话之后，另一个关键问题随之而来：如何检测AI是否出错？我们必须构建一个极强的校验框架。

这个校验框架被设计为可扩展的，能支持全方位的检测插件来做Bad Case拦截。目前我们沉淀了两大类检测插件。第一类是逻辑检查插件，例如检查是否误删了无关开关，检查布尔逻辑是否被改反，检查业务逻辑是否完整，检查是否误删了非开关相关的代码等。第二类是编译检查类插件，包括代码是否符合Checkstyle规范，是否存在语法错误，流水线编译能否通过等等。

将强校验框架与多轮对话结合，第一道安全护栏就成型了。流程是：源代码和修改指令交给大模型后，输出结果首先经过第一道安全护栏的校验，包括语法检测、逻辑检测或编译检测等。如果安全护栏未通过，会把历史消息与错误信息再次返回给大模型，让大模型持续迭代修改，直至第一道安全护栏全部通过，我们才认为暂时没有问题。

然而，安全护栏本身是持续进化的，各类Bad Case必然还会存在，不可能百分之百拦截所有错误。于是我们设计了第二道安全护栏——最直接想到的就是人工兜底。因为在AI出现之前，代码本来就需要人工Review之后才能上线；有了AI后，我们在想能不能用大模型替代人工Review，反正大模型本来就是替人干活的。我们做了一个实验：用三个大模型去Review主大模型生成的代码，判断是否有错。三个模型互相独立、不共享上下文，采取少数服从多数的原则，两个或以上通过才视作通过。

但这里有一个很难回避的Bug：你怎么保证评测大模型就一定没问题？这本质上是用概率事件解决概率事件，Review结果无法保证百分之百正确率。既然无法保证，那还是需要百分之百的人工Review。打个比方，AI说“我改这段代码的正确率有99%，改一百个会错一个，但我不能告诉你是哪一个错了”，此时你是不是还得把一百个全部看一遍？这意味着人工参与度根本没有降低。

为了真正降低人工参与，我们调研到一篇论文《程序辅助语言模型》，其核心思想是利用大语言模型解读自然语言问题，并将推理步骤升华为生成程序，同时将解决步骤交由Python解释器继续执行。这让我想起之前一位同事的经历：他让大模型生成一百个字符串并按逗号拼接，大模型很快拼接完成，肉眼检查以为没问题，后来却发现少了两个字符串，肉眼极难查出。后来我告诉他，以后大模型干活的时候，不要让它直接出结果，而是让它写一段脚本，你先Review这个脚本，再让脚本去执行，这样几乎不会出错。我们将这个思想应用到了治理上：用确定性的程序检测替代人工兜底复核。

具体实现是，AI改完代码后，我们再让一个AST（抽象语法树）引擎把同一段代码再改一遍。如果AST引擎改出的代码与AI改出的代码完全一致，我们就认为没有问题，不需要人工复核；如果不一致，再人工介入。

AST引擎采用的是规则加有向图的架构。我们将规则原子化，一条规则只做一件事，例如只做if清理，或者只做删除字段、删除方法等。整个AST引擎由一个有向图驱动，逐步执行各个规则，最终达到修改代码的平衡状态。由此我们形成了大模型生成与AST校验的双引擎架构范式：大模型像一个勘探者，处理代码的模糊性，生成创新方案，解决硬编码无法覆盖的问题；而AST引擎是一个校验者，依靠程序规则确保零故障。

阶段性总结整体流程：拿到原始代码以及修改提示词之后，首先将提示词给到大模型，大模型修改完成后经过第一道安全护栏，即逻辑检测、编译检测等。第一道安全护栏通过后，继续交由AST引擎再改一遍。改完之后，将AST结果与AI结果做Diff，如果一致，我们就认为Review通过，人工不再介入；如果有差异，则走第二道安全护栏，即人工Review，直到通过为止。实践表明，AST引擎可以帮我们拦截非常庞大的Review成本。

这里可能产生两个核心疑问。第一个疑问是，AST引擎本身一定正确吗？没有人能保证自己写的代码百分之百正确。我们也有一些兜底方案，比如在流水线中沿用快手的准入条件，包括单元测试、集成测试、流量录制回放、Diff等。但这依然无法完全保证代码修改的正确率。最核心的思想是，我们为什么能用AST替代人工Review？并不是因为AST百分百正确，而是我们将业务治理的压力从业务侧转移到了平台侧。此前，推业务去治理，业务改代码有可能改错，责任全在业务；现在业务不用再自己改代码，AI去改代码，AST去Review。如果这一整套流程出了问题，责任归属平台。平台方不再只是一个提供提效工具的协助角色，而是与业务方站在一起、帮业务承担治理责任的同行者。这种责任转移极大提升了业务方配合治理的意愿。而且，AST引擎与AI引擎同时改错代码的概率，我个人认为几乎为零——一个不确定性的生成结果加上一个确定性的程序，两者同时错且错得一模一样，这个概率极低。同时，两个引擎可以互补互反哺：当AST认为AI改错时，可以反过来优化AI；反之亦然。

第二个疑问是，既然已经有了AST引擎，还需要AI引擎吗？结果是以AST引擎为最终上限，那AST是不是就意味着一定对？看这样一个例子：假设没有AI引擎，从原始代码到AST引擎改完代码，由于AST必然不能百分之百覆盖所有场景，有些复杂场景之下肯定会改错，而你又无法预知哪些场景不支持，于是依然需要百分之百人工Review。但如果加上AI引擎，只用AST的流程肯定还需要人工Review，而AI+AST的流程却可以将人工Review成本降到极低，因为只有在两个引擎发生分歧时才需要人介入。

3自我进化：人工到系统自升级

即便有了AI+AST双引擎，AST引擎和校验插件本身仍然是不完善的，它们会遗留一些未拦截住的Bad Case。当时我们维护这套系统的投入不到一个人力，人工维护成本极高，引发了一连串问题：效率低，每天要人工Review大量MR，导致Review积压排队；人力成本浪费，AI改对的绝大多数结果还需要人从中寻找错误的；滞后性强，AST引擎和校验插件的版本迭代速度因人力瓶颈而持续跟不上。我们开始认真思考，如何让AST和校验插件实现自进化，使人工参与度再进一步降低。

在自进化之前，我们可以先类比一下人类优化系统的方式：一定要让优化有据可依，要知道每一次修改到底是正确还是错误。这也正是业界常用的一种方法——搭建一套评测体系。我们的流程是：每次修改代码完成后，基于Trace将AI的提示词、Response以及AST引擎的结果和校验插件的结果，全部存入数据库；接下来，对全部结果进行人工打标，除了AST Review已经通过的Case之外，每一个Case都要做人工Review；然后建设看板，将打标结果可视化，并每日召开分析会议，识别哪些错了、为什么错，进而做出针对性优化，到底是优化AST引擎还是优化校验插件。优化完成后，再基于之前存储的所有历史信息进行评测回溯。评测回溯的结果非常明确：对了就是对了，错了就是错了，直接通过程序就能给出结论。

评测体系的底层是数据采集层。AST引擎Review通过的Case会自动进入评测集；人工Review通过的Case，也视为正确，自动进入评测集；但人工Review拒绝的Case，会进入一个重要Case评测集，其决策是：未来做评测回溯时，这些Case必须百分之百通过，也就是说，犯过的错误绝对不能再犯。评测集构建完毕后，进入上层标注环节，标注完成后走到评测执行层，这里会构建与线上隔离的评测用流水线与环境。最终数据流入分析层，进行链路分析及结果回溯。

如果能打通这一套链路，并让AI驱动整个系统自进化，就能形成一个正向飞轮：人工标注完成，系统自动优化→自动执行评测→评测通过后正确率提升→正确率提升后人工标注量减少→减少后继续反馈到这个回路，最终人工标注量趋近于零。

具体怎么进化？我们对之前打标的所有历史Case进行了回溯，基本上可以分为两类：第一类，人工复核后发现AI改错了，说明检测插件能力没有到位，未能把错误拦截住，这证明当前存在盲区，必须优化检测插件；第二类，人工标注是正确的，证明AI都改对了，但你居然还是让人去看了，这说明AST Review没有拦截住，需要优化AST引擎。

由此我们设计出一个双Agent专项升级体系。针对“人工标注正确”的场景，将此类Case交给AST能力升级Agent，由它分析为什么AST没有拦截住，为什么系统判断出错，然后自主完成修复（如优化AST引擎代码）。改完并部署后，自动触发评测，评测结果没有问题便上线。针对“人工标注错误”的场景，则交给检测插件升级Agent，由其定位为什么检测插件没有拦截住，进行插件代码补齐，同样自动评测后上线。

以AST引擎升级Agent的工作流为例，其步骤并非直接动手写代码。第一步是需求理解。有一个专门的需求理解Agent，它不需要做方案设计，也不出PRD，而是要准确理解“要干什么、怎么干”，并先生成一份文档。文档产出后需要人工Review，若存在问题则在反馈环路中持续修正，直至通过。第二步由另一个Agent负责技术方案编写，包括架构设计、核心思路与流程，同样需要人工Review。第三步是自动编写代码并进行智能化代码审查。全部审查通过后，触发部署流水线，将代码部署到隔离的评测环境中，进行自动评测，整个循环完成。

至此，我们可以完整地俯瞰治理系统的运转全景。整体流程分为上下两层：上层是完全无需人工参与的自动化链路。原始代码与修改指令交给大模型，大模型改完后由校验插件进行检测，通过后交给AST引擎再次修改，修改结果与之前结果做Diff，如果Diff一致，整个流程结束，无需人工介入。下层是带有人工参与但不断反哺上层的进化链路。如果AST Review拒绝，则进入人工Review。若人工Review拒绝，将Case交给检测插件优化Agent去升级校验插件；若人工Review通过，则交给AST引擎优化Agent去升级AST引擎。下层的人工参与持续反哺上层，使得人工介入比例越来越低，整个系统成为一个正向自我优化的循环。

当前我们正在全力推进的一项工作，是AI Native全生命周期治理。此前的工作仍集中于债务发生之后的“堵”，工作环节都堆在治理链的最后一个环节，非常片面。真正的AI Native意味着要覆盖开关的完整生命周期，从源头即参与。

我们正在搭建的系统围绕三个阶段展开。第一，智能创建。在需求研发阶段就让AI参与进来，根据需求场景判断该功能是否需要开关，开关的作用到底是什么，是用于放量还是用于功能降级等等，同时给开关打上分类标签。这样开关从一出生就具备了可治理的属性。第二，智能变更。让AI参与变更计划制定和放量节奏设计，并且自动巡检相关监控指标，一旦巡检到异常，立即执行变更阻断，防止风险扩大。第三，智能删除。基于创建时已积累的上下文信息，在开关全量放量结束、稳定性验证完成后，无需人工介入，系统自动下线开关。

整体治理架构自底向上分为五层：底层为AI基建层，包含大模型、会话存储及多轮对话等基础设施；其上是评测层；再上层是逻辑检测、代码检测、编译检测等安全护栏层；最上层是日常使用的MR工具层，例如提代码、拉代码等操作；右侧则是自进化的Agent，用以持续优化整套系统。

4总结与展望

截至目前，这套系统已经累计自动下线了1500个开关，删除六万多行代码，且实现了线上零故障。当前准确率在98%以上，仍有少量Case未能完全拦截，AST与AI引擎的拟合率也达到了80%以上，人工成本由此得到极致降低。

最后，我想延展一点思考。虽然我分享的只是一个非常窄的开关治理例子，但所有技术债的治理，只要存在确定性的答案，理论上都可以采用这种范式来执行。例如基础设施的升级，当RPC SDK版本太低需要统一升级时，或者代码里写死域名导致没有域名容灾能力需要治理时，都可以复用这套“不确定性探索+确定性校验+自进化闭环”的方法。此外还包括冷代码的治理，那些线上已经毫无流量却长期驻留在业务里的代码，同样可以采用自动化方式安全删除。最好的治理，是治理本身被遗忘；最好的系统，是系统自己照顾自己。