Skip to main content

在发布后清理功能开关

安排一次性的 Devin 会话，在发布稳定后移除功能开关及其对应的死代码。
AuthorCognition
CategoryAutomations
FeaturesSchedules
1

在发布功能开关时就安排清理任务

你刚刚在功能开关 enable_new_checkout 背后部署了新的结账流程。它已经在生产环境中开启，但你希望先监控一周，再彻底移除旧代码。与其创建一个你可能会忘记的工单，不如趁现在上下文还清晰，立刻安排一次性的 Devin 会话。打开计划创建页面，将类型设置为 One-time。选择监控窗口之后的日期（例如，下周五上午 9 点）。选择一个 Slack channel，这样当会话运行并且 PR 准备好时，你的团队会收到通知。然后粘贴你的提示词：
2

让提示词尽量详尽

功能开关可能藏在意想不到的地方——配置文件、测试夹具、注释、环境变量。你在提示词中提供的上下文越多，清理结果就越干净。请包括：
  • 功能开关的工作方式——它们在哪里定义、如何被检查（例如在 React 中通过 useFeatureFlag('name')，在后端服务中通过 isEnabled('name')）
  • 不要动什么——功能开关框架本身 vs. 某个特定开关（例如，“不要修改 src/lib/featureFlags/ —— 那是框架本身”）
  • 新旧代码分别在哪里——例如，“旧的结账流程在 src/pages/checkout/legacy/，新的流程在 src/pages/checkout/v2/”
  • 清理范围——引用该开关的注释、文档、.env 文件以及 CI 配置也都应一并清理
具备这种细节程度的提示词可以让 Devin 一次性追踪所有引用——无需后续再做补充清扫。
3

在 PR 提交后进行审查

当预定会话触发时，Devin 会遍历整个代码库中所有对该开关的使用，保留启用的代码路径，移除禁用路径和死代码，清理测试，并创建一个 PR。PR 准备好后，你会收到邮件通知。一个典型的 PR 看起来像这样：
Removed feature flag: enable_new_checkout

- Deleted flag from src/config/featureFlags.ts (1 file)
- Removed 12 conditional branches across 7 files
- Deleted src/pages/checkout/legacy/ (4 files, 380 lines)
- Updated 3 test files — removed flag mocking, deleted old-path tests
- All 1,204 tests passing
在合并之前，再次确认旧路径中的业务逻辑是否有需要保留的部分——错误处理、埋点事件或边界情况兜底有时会放在“disabled”分支中。