当 Codegen 建议使用已弃用的 Pandas API 时——警示性故事
Source: Dev.to
过时 API 如何进入生产环境
我在使用代码生成模型搭建一个小型 ETL，将 CSV 文件规范化为标准的 DataFrame。模型生成的代码简洁，我依赖它来省去手动输入——它生成了预期的列、转换步骤以及一些看起来很惯用的单行代码。我甚至把生成的代码片段链接到我们的仓库并运行了已有的单元测试，全部通过。
为了快速迭代，我使用 crompt.ai 作为开发助理，并把它的输出当作合理的起点。问题出现在 CI 镜像的依赖升级后。一个下游作业在聚合多个文件时，对某些输入产生了错误的行选择。追溯后发现是生成的代码中使用了已废弃的索引器 .ix 和一个已被移除的辅助函数，而这些在不同 pandas 版本中的行为不同。
在本地，使用旧版固定的 pandas，测试通过；在 CI 中，更新后的 pandas 实现使选择语义发生了足够的变化，导致聚合键被破坏。
为什么模型会建议使用旧 API
模型往往会映射它们训练时的语料库：旧的示例、Stack Overflow 代码片段以及博客文章。在本例中，生成器建议在索引选择块中使用 .ix，并使用了在 pandas 1.x 中已被删除的旧滚动辅助函数。代码简洁且能运行，所以看起来很安全。在一次快速调试会话中，我在聊天界面与模型迭代出替代的选择策略，但我并没有明确询问 API 是否已废弃或兼容性问题。
模型的建议包含了一种索引选择惯用法，它可以根据索引类型返回 基于位置 或 基于标签 的选择。这种模糊性导致了间歇性的错误选择，仅在输入文件包含类似整数的标签而不是简单的单调递增索引时出现——而我们的测试夹具并未覆盖这种情况。
为什么它很微妙且容易被忽视
导致该 bug 通过初步审查的原因有三点交叉：
- Linters 和类型检查器 在运行时不会标记已废弃的用法，只要符号仍然存在于环境中。
- 单元测试 只验证了形状和少量数值，并未检查混合索引类型下的选择语义。
- 代码生成 不会为建议附带 API 的历史上下文：除非被明确要求检查，否则它不会提示“自 pandas 0.20 起已废弃”。
当我随后使用深度研究方式查阅文档时，版本说明明确指出了不兼容性。这些细小的行为相互叠加：模型倾向于使用简洁、旧的惯用法 + 缺少版本元数据 + 稀疏的测试 = 一个脆弱的管道——它在工作时正常，出问题时却不易察觉。由于生成的改动只涉及一个小的辅助函数，审阅者认为风险低，代码审查时就被放行了。
实际的缓解措施和经验教训
- 把模型输出当作可编辑的草稿，而非权威代码。
- 添加 CI 作业，在多个受支持的 pandas 版本矩阵上运行测试套件。
- 扩展测试，加入能够暴露不同索引类型和数据类型的边界案例。
- 接受生成代码时，明确询问（或自行查阅）所建议的 API 是否已废弃，以及在何种 pandas 版本中行为发生了变化。
- 使用自动化搜索工具查找已废弃的符号，固定依赖版本，并编写小型集成测试来验证选择语义；这些措施能在早期捕获大多数此类问题。
更广泛的教训是：生成代码可以加速日常工作，但也会放大生态不匹配（训练数据的年代与运行时环境之间的差异）。验证和有针对性的测试仍然是最廉价且有效的防护措施。