AI重命名漏掉字符串引用的隐蔽故障

看起来很安全的重命名

你让 Agent 把 process_payment 重命名为 settle_payment。它遍历代码库，更新所有 import，重命名函数定义，更新 docstring，然后提交了一份整洁的 PR。diff 涉及 14 个文件，每一处改动都是干净利落的重命名，linter 通过，单元测试也通过。

CI 没有发现任何问题。两天后，一个每小时运行一次的定时任务悄无声息地停止了工作。cron 配置里仍然写着 handler = 'jobs.process_payment'。dispatcher 按名称查找这个字符串，什么也没找到，随后吞掉了查找错误。

为什么静态重命名会漏掉它

重命名工具只会改写那些能被解析为符号的标识符。在它看来，藏在字符串里的引用不是符号，而是数据。

函数名可能以字符串形式残留的地方，比大多数人想象的要多：

• 通过点分路径解析 handler 的 cron 任务配置和任务运行器
• 将 URL 路径映射到 view 名称的路由表
• 按名称查找 factory 的 DI 容器和 service locator
• 引用 callback 名称的 feature flag 配置
• 事件 handler 或插件系统中的动态分发
• Agent 看不到的独立 e2e 测试套件中的测试名称
• 打印旧名称的文档字符串和错误消息（只是展示问题，但会让人困惑）

Agent 用 grep 搜索 process_payment 时，会找到 import 所在的行，却找不到 cron.yaml 里的字符串。原因可能是这个文件不在你指定给它的目录里，也可能是文件采用 YAML 格式，而重命名工具把它当成了不透明的数据。

一个成本很低、却能抓住遗漏的检查

在 Agent 宣布重命名完成之前，让它多做一件事：

重命名后，用 grep 搜索整个 repo，包括 yaml、json、toml 和所有配置目录，查找仍以字符串字面量形式出现的旧名称。列出每一处命中，并说明它应该更新、为向后兼容而保留，还是删除。

只需在 prompt 里加上这一步，就能找出 cron 配置项、路由表和 DI 注册中的遗漏。它还能发现旧名称被有意保留为公开别名的情况——这时，Agent 应该明确说明，而不是悄悄把它删掉。

还有第二项检查，成本甚至更低：重命名后，实际运行应用的启动流程。大多数 dispatcher 和路由注册错误，会在应用启动的那一刻以 "module not found" 或 "handler not registered" 的形式暴露出来，远早于 cron 任务触发。如果 Agent 能运行 npm start（或对应的启动命令），并贴出启动日志，缺失的引用五秒内就能现形。

Review 时该看什么

当一份重命名 PR 摆到你面前时，你要问的不是“所有 import 都更新了吗？”，而是：

• Agent 的 grep 是否覆盖了配置文件和字符串，而不只是代码？
• 重命名后，应用是否成功启动？
• 是否存在需要为现有调用方保留的公开别名？

一份只修改了 .py 或 .ts 文件、又没有提供启动日志的重命名，并没有经过验证。它只是完成了静态改写。运行时引用，恰恰就是静态分析看不到的那些引用。

API 重命名也存在同样的漏洞

Agent 重命名 API 字段或路由路径时，也会出现同样的问题：它们更新 controller、请求类型，以及 README 中的 OpenAPI 片段，却不检查生产环境的客户端——移动应用、浏览器扩展或第三方集成——是否仍在发送旧名称。

我们在 Powerduck 最终采用的本地检查措施，是在重命名后，针对实际运行的 endpoint 重新执行 spec。生产环境中仍能正常使用的旧客户端 payload，要么让检查失败（很好，你在发布前就发现了问题），要么确认旧别名仍然被接受（也很好，你知道向后兼容是有意保留的）。无论哪种结果，存在于代码库之外的字符串引用，都不会再成为 review 时的意外。

明天就可以做出的改变

下次 Agent 提交重命名 PR 时，在点击 approve 之前，先让它提供启动日志和字符串 grep 的命中结果。重命名本身大概率是正确的。真正导致运行时故障的，是那个没人要求 Agent 去查找的引用。

如需进一步采取行动，你可以考虑屏蔽此人和／或举报滥用行为。