整理软件分组实验推全或下线的代码修改范围

这个场景能帮你做什么

产品已决定将某项 A/B 实验推全或下线后，需要准确保留目标逻辑，避免误改其他实验和业务限制。WorkBuddy 可以阅读代码与导出配置，整理修改范围和回归建议。

开始前需要准备什么

提供已批准决定、准确实验 key、分组与变量、要保留的目标组、代码版本和相关配置。推全是保留指定逻辑，下线可能恢复原逻辑，不能由 AI 猜测。先保留开发者未提交的修改。

具体怎么做

第一步：核对目标和当前状态

列实验身份、适用模块、原分组和最终目标，检查批准记录与配置是否一致。状态不清时只定位，不起草删除范围。

第二步：定位定义和引用

按准确 key 查定义、调用、包装与间接引用，记录每处属于哪个业务路径。不能沿共享实验工具扩散到其他实验；动态 key 或仓库外调用标覆盖缺口。

第三步：区分实验条件与业务约束

逐处分辨分桶判断与客户端版本、场景或权限等独立限制。只针对批准的实验逻辑提出保留、替换或移除建议，共用工具与无关约束保持。

第四步：交付可审阅范围

输出文件、符号、现状、目标、拟改内容及保护项，补各原分组、空值、边界和共享调用的回归。代码变更与平台配置变更分别列出。

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

依据附件已批准实验决定，分析指定key推全/下线的代码范围，只读代码与导出配置。
列全部可见定义与引用，说明原分支、目标逻辑、拟改和不改内容。保护其他实验、共享工具、版本和业务场景限制。
缺目标组、动态引用或配置冲突标待确认。输出修改范围及回归场景，不删除未提交代码、不自动提交、改平台或发布。

完成后会得到什么

一份逐位置的修改建议、覆盖缺口和回归清单。开发者可以逐处确认目标分支，而非执行整仓搜索替换。

结果应该怎么检查

对照每个原组的行为和目标，核对共享逻辑、返回值与业务限制。检查客户端版本等条件有没有被误当实验判断删掉。

遇到这些情况怎么处理

目标组缺失、运行时覆盖或多仓调用时先补证据。代码与配置不同步时由负责人核实真实状态，不能仅按本地常量推定线上行为。

哪些必须人工决定

产品批准实验处理，研发评审代码，平台负责人确认配置和发布。AI 整理范围，不自行结束实验或推全。