临时功能开关越来越多，AI能判断哪些该删除、保留或补监控吗？

一次发布复盘中，研发团队数出了几十个仍在生产配置里的功能开关。有些早已全量开启，有些负责人已经离职，还有几个名字相似却控制着不同代码路径。没有人敢删，因为没人能证明开关不再承担回滚职责。

清理功能开关不是搜索变量名后批量删除。AI可以跨仓库找定义、引用和相关变更，删除顺序、监控阈值和生产操作仍要经过代码评审。

先建立开关身份证

每个开关记录唯一键、用途类型、创建时间、负责人、目标环境、当前状态、启用比例、关联需求或事故、到期日和预期清理方式。名称相似不能合并，配置平台与代码默认值也要分别记录。

不同类型的退出条件不一样

仅凭当前全部开启不能判定可删。还要检查默认值、缓存、移动端旧版本、离线任务和不同区域环境。

删除前先找反向依赖

• 源码、配置、基础设施和文档中的引用
• 监控、告警和操作手册是否依赖该开关
• 数据结构或接口是否仍保留两条行为路径
• 测试是否覆盖固定后的唯一结果
• 出现异常时用什么手段替代原回滚能力

按批次删除并保留观察窗口

先在低风险环境固定状态并运行测试，再删除代码分支、配置和无效监控。每批只处理职责相近的一组开关，部署后观察业务指标和错误信号。发现未知消费者时停止扩大，恢复配置并补资产记录。

先挑三种功能开关检查退出条件

选一个已全量发布开关、一个运维止损开关和一个无人认领开关，检查是否能通过代码、配置、监控和负责人证据得到不同结论。先确认字段能对应、规则能区分边界项，再扩大到完整范围。首轮测试的目标是发现漏项和误判方向，不追求一次给完所有结论。

角色：平台工程师或研发负责人。
触发：发布过程中不断新增功能开关，部分已经全量开启却仍留在代码和配置中。
资料：功能开关清单、代码引用、环境配置、启用比例、负责人、监控与事故记录。
判断：哪些开关可删除、哪些仍需保留、哪些缺少负责人或回滚监控。
交付：开关生命周期清单、删除批次、风险依赖和验证结果。
要求：每条结论标出证据位置、资料版本、未知项和需要谁确认，只生成建议与复核记录。

开关清单要让代码评审直接接手

最终应交付开关生命周期清单、删除批次、风险依赖和验证结果。每个结论都保留输入版本、原始位置、人工修改和批准状态，接手人可以从异常行继续，而不是重新读完整资料。

发现未知消费者就停止清理

• 关键资料缺少版本、时间范围或唯一编号
• 不同来源给出冲突事实，且没有已授权的基准
• 动作会直接触发付款、合同、权限、生产、人事或对外承诺
• 继续处理可能导致误删仍承担回滚职责的开关造成事故，或长期保留形成不可测试的配置分支

停止自动处理后，保留已经完成的证据整理和影响范围，标出阻塞项、接管人和期望回复时间。不要清空结果，也不要用模型猜测填补缺口。

仓库检索与事故证据怎样互相校验

Github Skill负责跨仓库查找开关定义、引用、配置、Issue、PR和负责人线索；incident-response负责把事故记录、回滚职责、监控与替代控制整理为移除风险。两项能力接力使用，前一步的输出要成为后一步可复核的输入。

Skill 不会自动删除代码、改生产配置或批准回滚方案。动态配置、旧客户端和运行时消费者需要研发与运维实测。