用GPT-3做pandas代码协作者：零样本prompt工程实践

1. 项目概述：当GPT-3坐进数据科学工位，它真能替你写pandas代码吗？

“Errors using inadequate data are much less than those using no data at all”——查尔斯·巴贝奇这句老话，放在今天AI驱动的数据分析场景里，意外地有了新解。我试过用GPT-3写pandas代码整整117天，从最初对着空白notebook发呆，到后来能用三句话让模型生成带异常处理、内存优化和链式操作的完整清洗脚本。这不是在教AI做数据科学家，而是在训练一个高度定制化的、永不疲倦的“代码协作者”。它不替代你判断业务逻辑是否合理，但能瞬间把“把用户表里近30天注册且未下单的高净值客户筛选出来，按城市聚合统计平均消费额，并剔除异常值”这种自然语言描述，翻译成可执行、可调试、甚至带注释的pandas链式表达式。关键词直击核心： Towards AI - Medium 这个来源不是随便贴的标签，它代表一种真实存在的技术实践路径——不是实验室里的Demo，而是已在Medium技术社区被反复验证、可复现、有上下文约束的轻量级AI辅助工作流。适合谁？刚转行的数据新人，被重复性清洗任务压得喘不过气的中级分析师，或是想快速验证某个分析思路是否可行的产品经理。它不要求你懂Transformer架构，但要求你清楚pandas的 .groupby() 和 .agg() 之间差哪几行代码；它不承诺全自动建模，但能让你把原本花2小时写的探索性代码压缩到5分钟内完成初稿。关键在于：这个“数据科学家在养成”的过程，不是AI单方面输出，而是人机之间持续校准prompt、迭代反馈、建立信任的过程。我后面会拆解每一个卡点——比如为什么“请筛选出销售额大于1000的订单”会生成错误的布尔索引，而加上“注意：sales列可能包含空值和字符串类型”后结果就完全正确。这不是玄学，是可拆解、可复制、可踩坑的经验。

2. 整体设计与思路拆解：为什么选GPT-3做pandas协作者，而不是重训一个专用模型？

2.1 核心思路：用大模型的泛化能力，绕过小模型的标注困境

很多人第一反应是：“既然要自动写pandas代码，为什么不直接训练一个专门的代码生成模型？”我试过。去年用CodeX的开源变体微调了一个pandas专用模型，数据集是Kaggle上所有带pandas代码的notebook，花了两周时间清洗、对齐、去重，最后训出来的模型在测试集上准确率只有68%。问题出在哪？不是模型不行，而是pandas的使用场景太碎片化。同一个“去重”需求，在电商场景下可能是 df.drop_duplicates(subset=['user_id', 'order_time'], keep='last') ，在金融风控里却可能是 df.sort_values('update_time').drop_duplicates(subset=['account_id'], keep='first') 。你很难穷举所有业务约束条件去构造训练样本。而GPT-3的优势恰恰在于它的“零样本泛化”——它没见过“银行流水去重”，但它见过“按时间戳保留最新记录”这类通用表述，也见过大量Python代码结构。我的设计思路很朴素：不把它当黑盒代码生成器，而是当一个“超级语法翻译器”，输入是带业务语义的自然语言指令，输出是符合pandas最佳实践的代码片段。这背后有三个硬性约束必须满足：第一，输出代码必须能直接粘贴进Jupyter运行，不能有语法错误；第二，代码要体现pandas的惯用法（比如优先用向量化操作而非for循环）；第三，必须能处理现实数据中的脏数据（空值、类型混杂、列名含空格等）。这些不是靠模型参数决定的，而是靠prompt工程层层加固的。

2.2 方案选型：为什么是GPT-3而非其他大模型？

当时对比了四个选项：GPT-3（text-davinci-003）、Codex（code-davinci-002）、Claude-1和开源的StarCoder。最终锁定GPT-3，理由非常实际：第一，它的上下文窗口足够容纳完整的prompt模板+3个高质量示例+当前数据集的列名和前5行样本，这对生成精准代码至关重要；第二，它的输出稳定性在长代码块上明显优于Codex——Codex经常在生成 .merge() 时漏掉 how= 参数，而GPT-3在明确提示“必须指定how参数”后，错误率低于0.5%；第三，它的温度（temperature）控制更细腻，设为0.3时既能保证代码一致性，又不会僵化到拒绝合理变体。举个具体例子：当输入“计算每个城市的订单总数和平均金额”时，Codex固定输出 df.groupby('city')['amount'].agg(['count', 'mean']) ，而GPT-3在温度0.3下会根据上下文智能选择：如果数据量超百万行，它倾向用 df.groupby('city').agg({'amount': ['count', 'mean']}) 以避免列名歧义；如果 city 列有大量空值，它会主动加 .dropna() 。这种“条件反射式”的适应性，是专用模型短期内难以企及的。当然，GPT-3也有硬伤：对pandas 2.0的新API（如 pd.array() ）支持滞后，且无法访问你的本地数据schema。所以我的方案里，所有数据信息都通过prompt显式注入，而不是依赖模型记忆。

2.3 架构分层：三层prompt设计，像搭积木一样构建可靠性

我把整个系统拆成三个逻辑层，每层解决一类问题，层层递进：

• 基础层（Context Layer） ：定义角色和边界。开头固定写：“你是一个资深pandas工程师，专精于高效、内存友好的数据分析。你只输出可执行的Python代码，不解释、不注释、不加print语句。所有代码必须兼容pandas 1.5+，使用链式操作优先。” 这句话看似简单，实测能过滤掉70%的无效输出（