当代码生成建议使用已弃用的 Pandas API 时 — 案例研究
Source: Dev.to
介绍
我们使用代码生成助手来搭建 ETL 流水线，它生成了紧凑、易读的用于连接和重塑数据的转换代码。表面上看输出很不错：符合惯用的链式写法、合理的列名，甚至还有注释。然而，其中一个建议的调用使用了 DataFrame.as_matrix() 和一个旧的滚动 API；这两者在最近的 Pandas 版本中已被弃用，且在现代发行版中已被彻底移除。直到我尝试升级环境并且 CI 开始报错时才注意到这个问题。这种失败模式很微妙，因为生成的代码在我们固定的环境中能够正确执行，并且在小样本输入上返回了合理的结果。模型的输出表现得像一位称职的同行评审：简洁、自信且具备上下文感——这让它使用过时 API 的行为不那么引人怀疑。为了阅读背景资料并追踪库的变化，我们在 crompt.ai 上保留了一份通用参考，但生成的代码片段仍然在我们的审查过程中漏了过去。
它在开发过程中是如何显现的
最直接的信号来自 CI 流水线的升级：我们尝试从 Pandas 0.25.x 升级到 1.2.x，测试开始因 AttributeError 和 ImportError 而失败，这些错误追溯到生成的辅助模块。由于我们的单元测试体积小且侧重逻辑，它们在旧运行时仍能本地通过，所以第一个线索来自依赖升级的运行，而不是业务逻辑测试的失败。
追踪错误发现生成的辅助函数调用了 as_matrix() 和 pd.rolling_mean()。使用我们内部的深度研究步骤——一个以验证为导向的工具——快速查证后确认这些调用已被弃用并被移除。模型并没有捏造库符号，而是建议了一个在目标运行时已过时的真实方法。
为什么容易被忽视
- 固定的依赖 – 代码在开发者环境中运行并产生了预期的输出，因为我们锁定了旧版本。
- 弃用警告优先级低 – 它们只会以日志信息出现，在快速迭代时很容易被忽略。
- 模型的自信语气 – 建议没有任何关于 API 已不再推荐使用的提示。
我们的单元测试使用的是极小的合成数据集，未能触及边缘情况或与新版 Pandas 实现相关的性能特性。当运行时更换后，库的期望与生成代码之间的不匹配才显现出来，但这仅在升级尝试时出现——而不是在功能开发期间。
小模型行为如何叠加成更大的问题
单独来看这些都是小毛病：
- 在旧代码上训练导致推荐过时的惯用法。
- 模型不标注建议的时间戳。
- 它倾向于在没有保留余地的情况下断言正确性。
当这些因素结合在一起时，一个有用的脚手架会演变成技术债务。自信且过时的建议被最小化编辑后合并，随后在多个模块和测试中传播，导致在升级依赖时影响范围扩大。我们在多轮调试时依赖聊天界面进行迭代，这对定位原因很有帮助，但不适合作为兼容性验证手段。
实践经验
- 在 CI 中使用最新的库版本运行生成的代码。
- 添加 linter 规则或 grep 检查已知的弃用符号。
- 将模型输出视为草稿，需对照权威文档进行验证。
小模型行为——自信、对新鲜度保持沉默以及复用旧惯用法——往往在它们叠加成升级失败之前不易被发现。