技能介绍

为什么 flag 会变成债务

功能开关（feature flag）本该是控制发布风险的临时手段，但大多数团队把它当成随手写下的 if (FLAG_FOO)，没有分类、没有负责人、没有清理计划。结果是代码库里堆积着无人认领的开关：死分支、过时的默认值、从未被测试覆盖的代码路径，以及没人知道如何关闭的危险开关。这些不是比喻，而是可量化的债务——每个未清理的 flag 都在扩大爆炸半径。

技能如何工作

这个技能把 flag 当作完整的生命周期来管理，而不是一次性的条件判断。

首先定义四种 flag 类型：Release（隐藏未完成功能）、Experiment（A/B 测试）、Operational（熔断器与 kill switch）、Permission（按用户或套餐授权）。不同类型有不同的生命周期和负责人，误分类本身就是债务的来源。

然后提供三个纯标准库 Python 工具：

flag_debt_scanner.py：扫描超过指定天数且使用频率过低的 flag，输出候选清理清单，支持 JSON 格式供 CI 集成
rollout_planner.py：根据人口规模、目标百分比与策略生成分阶段发布计划，支持 ring、linear、log、cohort 四种策略，并给出每阶段的中止条件与验证步骤
kill_switch_audit.py：交叉验证代码中的 flag 与文档，确保每个 flag 都有熔断路径、负责人和监控面板，可作为合并前的卡点

此外还包含 provider 选择指南（LaunchDarkly、GrowthBook、Statsig、Unleash、Flipt 或自建）、四个完整工作流，以及反模式清单——比如把长期权限判断写成永久的 Release flag，或者让 A/B 测试无限期跑下去却不收敛。

适用边界

Operational 和 Permission 类型的 flag 按设计就是长期存在的，不应出现在债务扫描列表中，只有 Release 和 Experiment 需要定期清理。如果 flag 总数少于 50 且不需要定向投放，自建方案（配置文件或环境变量）可能比引入第三方服务更合适。