功能已全量上线，Goose 可以把清理旧开关的做法存成 recipe

功能已经全量上线，临时开关却还留在代码里：配置一处、判断几处、测试又分新旧两条路径。清理这种代码，难点不在删掉一个字符串，而在让新行为成为默认，同时把相关遗留部分一起收好。Goose 的官方 recipe 库，恰好有一份针对这件事的样例。

recipe 是可重复使用的任务文件，把说明、提示、参数、工具和设置放在一起。与其每次重新告诉代理“先找定义、再查引用、别顺手提交别的文件”，不如把确认过的做法留成可编辑材料。

从开关名，走到一组代码变化

官方 Clean Up Feature Flag 样例有两个主要输入：必填的 feature_flag_key，以及默认当前目录的 repo_dir。它的前提也很明确：功能已全量上线且稳定，开关始终走启用路径。

流程先建立新分支，找包裹该 key 的常量或对象，再沿引用继续搜索。随后分别处理定义、使用位置、测试与配置：删除定义和相关导入，把分支判断改成保留新行为，调整禁用状态测试及剩余测试，移除开关配置。

这个顺序体现了样例最有用的判断：旧逻辑消失以后，新逻辑应该继续存在。只把每个包含开关名的行删掉，很可能连实际功能也一起删掉；围绕定义、调用、测试分别处理，才能看懂清理想留下什么。

样例要求重新全文搜索，确认引用与导入已被处理，再检查因此失去用途的变量、函数和死代码。它还明确提交时只加入与这项清理有关的文件，避免一个工作目录里别的修改被一起带走。

这些都是代理会执行的任务要求，不是已经证明样例在任何仓库都能成功。实际采用时，开关是否还有灰度、回滚或审计用途，需要团队先确认；项目测试也应覆盖保留下来的默认行为。

原文件还包含提交、推送和打开比较页的收尾步骤。若团队只希望代理准备本地改动，就应在 recipe 中删除或改写相应部分，而不是因为它来自官方库就照单运行。

recipe 教程说明，它可以作为 YAML 或 JSON 文件维护，通过参数替换换一组任务输入；extensions 则决定需要哪些工具。这份清理样例使用 Developer 扩展，承担仓库与代码操作。

因此，下一次换一个开关名，可以沿用同样的处理顺序，并把团队自己的验证命令补进文件。文件进入版本管理后，别人也能看见这套做法如何演变。共享 recipe 不会把创建者原会话的数据和状态一起共享，接收者运行的是自己的任务。

当前 Goose 仓库已在 AAIF 名下，代码采用 Apache-2.0；模型与扩展仍需各自准备。我会先从这一份具体样例开始改，而不是先搭一张很大的自动化图：输入是明确开关，产物是能审阅的清理分支，反复需要的步骤也有了可维护的落脚点。