检查历史实验开关的引用与清理条件

这个场景能帮你做什么

开关存在很久，不代表已经无用。WorkBuddy 可以结合配置导出与代码引用检查它是否仍承担灰度、回退或业务控制，形成清理候选及前提。

开始前需要准备什么

提供开关全名、所属应用、类型和值、线上与预发配置、导出日期、涉及仓库及业务批准的退役意见。明确运行时是否可覆盖，不能只给变量名就清理。

具体怎么做

第一步：建立开关身份和环境表

将同名不同应用、不同环境分开，记录类型、默认值、真实配置和更新时间。默认值不等于当前线上值。

第二步：展开引用与值的语义

列定义、直接与间接读取、包装函数和动态调用。分别理解布尔、字符串、集合和对象，不把任意非空值都当真，不因字面相似替换其他开关。

第三步：检查退役条件

核实是否仍用于灰度、应急回退、特殊客户或版本兼容。环境差异、未知覆盖和业务未批准的项目保持保留或待确认。

第四步：给候选修改与验证

仅对已确认目标提出替换值与引用清理建议，注明影响和回归。不能安全移除的明确说明原因，不为“代码干净”强行删除。

可以直接交给 WorkBuddy 的完整要求

只读附件开关配置和授权代码，按完整身份查定义、直接/间接引用及环境差异。
记录类型、默认值、实际配置与日期，检查灰度、回退、兼容和动态覆盖用途。
按已批准结论分可清理/待确认/保留，每项附依据、候选替换与验证。未知真实值不清理，不改配置平台、不删除用户未提交内容。

完成后会得到什么

一份引用表、环境差异和退役前提，以及可以交代码评审的修改候选。

结果应该怎么检查

核对值类型、真假条件与空值，检查对象返回和默认分支。选择关键调用验证行为，语法通过不能证明清理正确。

遇到这些情况怎么处理

配置仍变化时延后清理。仓库外引用不可见时列覆盖限制。预发与线上不同则先确认目标，不能用一个环境的值替全部环境。

哪些必须人工决定

业务和平台人员确认退役，开发评审行为与回归，发布人员执行。AI 不知道未提供的线上状态，也不能自行停用控制能力。