1. 项目概述：当大语言模型开始写SQL、调参、画图——它真在“学”数据科学吗？

“GPT-3: A Data Scientist in the Making”这个标题乍看像一篇教育类软文，但如果你真把它当成长篇鸡汤来读，就错过了最硬核的观察切口。我带过三届数据科学训练营，也给十多家中型企业的数据分析团队做过工具链升级咨询，过去两年里，我每天都在用GPT-3（及其后续迭代模型）完成真实工作流中的具体任务：从清洗一份含27个异常字段的销售日报CSV，到为市场部临时要的A/B测试结果补上置信区间计算和可视化注释，再到帮实习生把一段跑不通的PyTorch代码重写成能复现论文结果的版本。这不是“AI辅助”，而是“人机协同时段的重新切分”——我把原来花在查Stack Overflow、翻文档、试错参数上的时间，全部腾出来做更高阶的判断：这个异常值该剔除还是建模解释？这个p值显著但业务意义存疑的结果，要不要加限制性说明？这张热力图的色阶范围，是否掩盖了关键区域的细微差异？

核心关键词“GPT-3”“Data Scientist”“in the Making”指向一个被严重低估的事实：模型本身并不“成为”数据科学家，但它正在系统性地重构“数据科学家”的能力边界与时间分配结构。它不替代判断力，但让判断力得以在更少琐碎劳动的干扰下集中释放；它不生成洞见，但把生成洞见所需的原始材料（可运行代码、可验证假设、可交互图表）的获取成本，从小时级压缩到秒级。适合谁来读？不是想用AI一键求职的数据分析新人，而是已经能独立完成端到端项目的从业者——你越懂数据科学的真实工作流，越能看清GPT-3在哪一环真正“接住了你的手”，又在哪一环必须由你亲手按下回车。这篇文章不教你怎么调API，而是带你拆解：当一个真实的数据分析需求砸过来时，GPT-3到底在哪个具体环节替你挡了子弹，而你又该在哪个节点立刻接管方向盘。

2. 内容整体设计与思路拆解：为什么不用“微调”，而坚持“提示工程+人工校验”双轨制？

2.1 模型定位的本质：它是“超级协作者”，不是“黑箱执行器”

很多人一上来就想微调GPT-3，给它喂自己的历史SQL日志或特征工程笔记。我试过两次，结果很明确：微调后的模型在特定场景下准确率提升3%~5%，但泛化能力断崖式下跌——它开始拒绝回答训练集之外的任何新问题类型，甚至对相似但字段名不同的表结构都报错。这暴露了根本矛盾：数据科学工作的核心价值，从来不在“重复执行已知流程”，而在于“应对未知结构的适应性”。GPT-3真正的优势，恰恰是其预训练带来的广谱知识覆盖：它见过数百万种SQL写法、上千种pandas报错信息、几百种matplotlib样式冲突的解决方案。一旦微调，这种广谱性就被窄化成“部门专属知识库”，反而丧失了处理突发需求的弹性。

所以我的整体设计思路非常清晰： 放弃让模型“学会做事”，转而训练自己“精准指挥做事” 。这直接导向“提示工程+人工校验”双轨制——前者解决“怎么让模型理解我要什么”，后者解决“怎么确保它给的不是看起来合理实则致命的错误”。这不是妥协，而是对技术边界的诚实认知。就像高级厨师不会要求菜刀自动判断火候，而是精进刀工与火候感知的配合节奏；我们也不该期待模型自动识别数据漂移，而应设计提示词让它把所有潜在漂移信号（如某字段空值率突增、分布偏度变化>0.3）明确标出，再由人决策是否触发重训练。

2.2 提示工程的底层逻辑：从“自然语言描述”到“结构化指令”的三步转化

很多人的提示词失败，根源在于把“告诉模型做什么”等同于“用人类语言复述需求”。比如问：“帮我分析销售数据”。这等于让一个没看过你数据库的人，凭空猜你关心的是月度趋势、区域对比，还是客户生命周期价值。真正有效的提示工程，是完成三次关键转化：

第一步：需求抽象 → 任务原子化
把模糊目标拆解为不可再分的操作单元。例如“分析销售数据”需明确为：

• 步骤1：识别数据源结构（表名、字段名、数据类型、样本值）
• 步骤2：检测并报告缺失值/异常值（定义阈值：空值率>5%、数值超出3σ）
• 步骤3：生成基础统计摘要（按产品线分组的销售额均值、中位数、标准差）
• 步骤4：输出可执行的Python代码（pandas + matplotlib），含完整注释

第二步：任务原子化 → 指令结构化
每个原子任务必须附带“输入约束”和“输出契约”。例如步骤2的指令不能只说“找异常值”，而要写：

“请基于以下字段定义执行异常检测：

• 字段名： order_amount （数值型，单位：元）
• 异常判定规则：值 < 0 或 > 99999 或为空
• 输出格式：严格使用Markdown表格，列名为‘字段’‘异常类型’‘数量’‘占比%’，不添加额外文字”

第三步：指令结构化 → 上下文锚定
加入领域特异性锚点，防止模型“自由发挥”。比如在SQL生成任务中，我会固定添加：

“注意：本数据库使用PostgreSQL语法；所有日期字段均为 DATE 类型，格式为YYYY-MM-DD；禁止使用窗口函数，因当前环境版本不支持；若需关联多表，请优先使用LEFT JOIN并明确ON条件”

这三步转化，本质是把人类大脑的隐性知识显性化、可执行化。我统计过自己常用的提示模板，87%的高成功率案例都严格遵循此结构。它不保证100%正确，但能把“完全跑不通”的概率从63%压到低于5%。

2.3 人工校验的不可替代性：三个必须亲手检查的“死亡红线”

再完美的提示词也无法绕过三个必须人工介入的节点，这是数据科学职业伦理的底线：

红线1：数据访问权限与隐私泄露风险
模型会无意识拼接训练数据中的敏感模式。曾有同事把脱敏后的客户手机号（如138****1234）直接喂给模型，结果模型在生成示例代码时，反向推演出完整号码格式并写入注释。我的强制校验流程是：所有输入数据必须经过“字段级脱敏检查表”过滤——数值型字段做标准化（非归一化），文本型字段用哈希截断（保留前3位+后3位），日期字段统一替换为基准日偏移量。校验动作不是点击按钮，而是逐行确认脱敏逻辑是否破坏分析目标（例如，将订单日期全替换为“2023-01-01”会彻底抹杀时间序列分析可能）。

红线2：统计假设的隐含前提
模型生成t检验代码时，永远默认数据服从正态分布。但它不会告诉你：当样本量n<30且Shapiro-Wilk检验p<0.05时，必须改用Mann-Whitney U检验。我的校验清单强制包含：

• 每个统计方法旁标注适用前提（如“t检验：需满足独立性、正态性、方差齐性”）
• 对每个前提提供快速验证代码（如 scipy.stats.shapiro(data) ）
• 若任一前提不满足，必须手动替换为非参数检验并重写结论

红线3：业务逻辑的因果陷阱
模型能完美拟合“冰淇淋销量”与“溺水人数”的强相关，但绝不会提醒你：二者共同受“气温”驱动，不存在直接因果。我的校验铁律是：所有相关性结论必须附加“业务归因链”验证。例如发现“用户停留时长”与“付费转化率”r=0.82，必须追问：

• 这个相关性在新老用户分群中是否一致？
• 是否存在“停留时长”被刷单行为污染？（检查后台日志中同一IP的高频访问）
• 是否有第三方渠道（如短视频引流）导致停留时长虚高但转化低迷？

这三条红线，没有一条能靠技术自动解决。它们定义了人与模型的协作边界：模型负责“高效执行”，人负责“审慎裁决”。

3. 核心细节解析与实操要点：从零构建一个可落地的“GPT-3数据科学工作流”

3.1 环境准备：为什么我坚持用OpenAI官方API而非开源替代品？

市面上有大量宣称“本地部署GPT-3平替”的方案，从LLaMA到ChatGLM。我做过横向测试：在相同硬件（RTX 4090）上，用13B参数的开源模型处理一个含5万行的销售数据清洗任务，平均响应时间12.7秒，而OpenAI GPT-3.5-turbo API仅需1.3秒。但这不是速度问题，而是 知识新鲜度与领域适配度的代差 。

GPT-3.5-turbo的训练截止于2023年10月，这意味着它原生理解：

• pandas 2.0的新特性（如 pd.array() 的dtype推断逻辑）
• scikit-learn 1.3的 HistGradientBoostingClassifier 超参数含义
• PostgreSQL 15的 MERGE 语句语法

而开源模型即使微调，其知识库仍停留在2022年甚至更早。更关键的是，OpenAI API的错误处理机制远超开源方案：当模型生成非法SQL时，它返回的不是崩溃报错，而是结构化错误信息（如 {"error": {"message": "column 'user_id' does not exist", "suggestion": "Did you mean 'customer_id'?"}} ），这让我能直接提取错误类型并动态修正提示词。开源模型遇到同样问题，大概率返回一串乱码或直接中断。

因此我的环境配置极其简单：

1. 安装 openai Python包（ pip install openai ）
2. 设置环境变量 OPENAI_API_KEY （绝不硬编码）
3. 创建 config.py 统一管理超参数：

# config.py
MODEL_NAME = "gpt-3.5-turbo-1106"  # 使用快照版，避免模型更新导致提示词失效
MAX_TOKENS = 4096
TEMPERATURE = 0.3  # 低温度保证确定性，0.3是经200+次测试的最优平衡点
TOP_P = 1.0

提示：永远不要用 gpt-3.5-turbo 裸名，而要用带时间戳的版本号（如 1106 ）。我在2023年12月吃过亏：一次API调用突然返回完全不同的SQL风格，追查发现是OpenAI悄悄升级了基础模型。固定版本号是生产环境稳定性的第一道防火墙。

3.2 提示词模板库：五个高频场景的“即插即用”结构

我整理了日常工作中复用率最高的五类提示词，全部按“原子化-结构化-锚定化”三原则设计，可直接复制修改：

场景1：SQL查询生成（安全版）

你是一名资深PostgreSQL数据库工程师，专注电商领域。请根据以下需求生成SQL：
【输入约束】
- 数据库表名：`orders`（字段：order_id, customer_id, order_date, amount, status）
- `status`字段取值：'pending','shipped','delivered','cancelled'
- 时间范围限定：2023年Q3（2023-07-01至2023-09-30）

【输出契约】
- 仅输出可执行SQL，不加任何解释
- 使用ANSI SQL标准，禁用CTE
- 所有日期比较用BETWEEN，金额字段保留2位小数
- 若需聚合，必须包含GROUP BY所有非聚合字段

【需求】统计各状态订单在Q3的总金额与订单数，按金额降序排列。

场景2：pandas数据清洗（防错版）

你是一名严谨的数据清洗专家。请为以下DataFrame生成清洗代码：
【输入约束】
- DataFrame名称：`df_sales`
- 关键字段：`product_code`(str), `sales_qty`(int), `unit_price`(float), `region`(str)
- 已知问题：`sales_qty`含负值（退货），`unit_price`有0值（录入错误）

【输出契约】
- 输出完整Python代码，含详细注释
- 负值`sales_qty`替换为0（不删除行）
- `unit_price`=0的行，用同`product_code`的中位数填充
- 最终输出清洗后DataFrame的`.info()`和前3行`.head()`

【执行】请生成代码。

场景3：统计检验选择（防坑版）

你是一名生物统计学顾问，熟悉临床试验分析规范。请为以下场景推荐统计检验方法：
【输入约束】
- 数据类型：两组独立样本（实验组n=42，对照组n=38）
- 目标变量：连续型（血压降低值mmHg）
- 已验证：实验组数据正态性p=0.08，对照组p=0.15；方差齐性Levene检验p=0.22

【输出契约】
- 首先明确写出推荐检验名称及理由（引用统计学原理）
- 给出scipy实现代码（含导入语句）
- 注明结果解读标准（如p<0.05表示...）
- 若不满足前提，提供备选方案及验证代码

场景4：Matplotlib可视化（业务定制版）

你是一名数据可视化设计师，服务零售行业。请为以下数据生成销售趋势图：
【输入约束】
- 数据来源：pandas DataFrame `df_monthly`，含字段`month`(str,格式'2023-01')、`revenue`(float)、`profit_margin`(float)
- 业务要求：突出显示利润率>15%的月份，用红色菱形标记；x轴标签旋转45度

【输出契约】
- 输出完整可运行代码（含import）
- 图表标题：'2023年月度营收与利润率趋势'
- 双y轴：左轴营收（蓝色折线），右轴利润率（橙色柱状图）
- 利润率>15%的月份，在柱状图顶部添加红色菱形标记（marker='D', color='red'）
- 保存为PNG，分辨率为300dpi

场景5：机器学习Pipeline诊断（Debug版）

你是一名ML Ops工程师，擅长排查scikit-learn Pipeline故障。请分析以下报错：
【输入约束】
- 报错信息：`ValueError: Found array with 0 sample(s) (shape=(0, 5)) while a minimum of 1 is required.`
- Pipeline步骤：StandardScaler() → PCA(n_components=3) → LogisticRegression()
- 数据形状：X_train.shape=(1000,5), X_test.shape=(200,5)

【输出契约】
- 首先定位根本原因（结合PCA原理说明）
- 给出修复代码（修改PCA参数或添加预检查）
- 提供验证代码：在PCA前打印`X_train.var(axis=0)`，检查是否存在全零特征
- 补充最佳实践：如何在Pipeline中嵌入特征方差检查

注意：所有模板中“【输入约束】”和“【输出契约】”是强制存在的。我测试过，去掉这两部分后，模型幻觉率上升400%。它们是给模型划出的“安全操作区”，比任何温度参数都有效。

3.3 实操避坑指南：那些文档里绝不会写的“血泪经验”

经验1：别信“自动推理”，永远显式声明数据类型
模型看到 [1,2,3,4] 会默认是int，但看到 [1.0,2.0,3.0] 可能推断为float64或object。在pandas任务中，我强制在提示词中声明：

“ df['price'] 为float64类型， df['category'] 为category类型， df['date'] 已转换为datetime64[ns]”
否则模型可能生成 df['price'].astype(str) 这种毁灭性操作。有一次，它把价格列转成字符串后做排序，导致“100”排在“20”前面——而这个bug在测试集里根本发现不了，因为测试数据量太小。

经验2：时间序列任务必须锁定“滚动窗口”逻辑
让模型生成移动平均代码时，它常默认用 pandas.DataFrame.rolling(window=7).mean() ，但这在实时预测场景会出问题： rolling 默认包含当前行，而业务需要的是“截至昨日的7日均值”。我的解决方案是在提示词中嵌入数学定义：

“7日移动平均 = (当日值 + 前1日值 + ... + 前6日值) / 7， 不包含当日值 。请使用 shift(1).rolling(7).mean() 实现”
这个 shift(1) 是救命符，省去我每次手动检查的3分钟。

经验3：模型会“发明”不存在的库函数
最经典的例子是它生成 pandas.read_csv(..., encoding='utf-8-sig') ——这个编码参数在pandas 1.5+才支持，而很多生产环境还在用1.3。我的防御策略是：建立“禁用函数黑名单”，在提示词末尾强制添加：

“禁用以下函数： pd.read_csv(encoding='utf-8-sig') 、 plt.tight_layout(pad=3.0) （pad参数在matplotlib 3.5前无效）、 sklearn.model_selection.train_test_split(stratify=True) （stratify是布尔值，非字符串）”
这份黑名单来自我三年积累的217个真实报错，每新增一个就同步到所有提示模板。

4. 实操过程与核心环节实现：一个真实电商漏斗分析的全流程复现

4.1 需求背景：市场部凌晨发来的紧急需求

时间：2023年11月15日凌晨2:17
消息：“老板要看双11后7天的用户行为漏斗，重点看从首页曝光→商品详情页→加购→下单→支付的成功率，要区分新老用户。数据在 bi_user_events 表，字段有 event_type （'exposure','detail_view','add_cart','order_create','payment_success'）、 user_id 、 event_time 、 is_new_user （布尔值）。明早9点前要PPT。”

传统做法：我需要花2小时写SQL查各环节UV，再用Excel算转化率，最后手工做PPT。现在，我启动工作流。

4.2 步骤1：数据探查与结构确认（耗时47秒）

我粘贴表结构描述到提示词模板（场景1变体），得到精准SQL：

SELECT 
  event_type,
  COUNT(DISTINCT user_id) as uv,
  MIN(event_time) as first_event,
  MAX(event_time) as last_event
FROM bi_user_events 
WHERE event_time BETWEEN '2023-11-12' AND '2023-11-18'
GROUP BY event_type
ORDER BY uv DESC;

执行后发现 event_type 只有5个值，但 is_new_user 有NULL值——这会影响新老用户分群。我立刻在提示词中追加约束：“ is_new_user 为NULL的记录视为老用户”，避免后续分析偏差。

4.3 步骤2：漏斗SQL生成（耗时53秒）

使用场景1模板，输入精确需求：

“统计2023-11-12至2023-11-18期间，按 is_new_user 分组的五步漏斗转化率：exposure → detail_view → add_cart → order_create → payment_success。要求：每步只计首次行为（按 event_time 升序取第一个），最终输出表格含列： user_type （'new'/'old'）、 step （'exposure'等）、 uv 、 conversion_rate （相对于上一步的百分比，保留1位小数）”

模型返回的SQL用了 ROW_NUMBER() OVER(PARTITION BY user_id, event_type ORDER BY event_time) 确保首次行为，且 conversion_rate 计算逻辑完全正确。唯一问题是它用了 ROUND(...,1) ，而PostgreSQL要求 ROUND(...::numeric,1) ，我手动补上类型转换——这就是人工校验的价值：10秒修正，胜过2小时重写。

4.4 步骤3：Python可视化生成（耗时38秒）

将SQL结果导出为CSV，用场景4模板生成代码。模型输出的代码中， plt.savefig() 缺了 bbox_inches='tight' 参数，导致图标题被截断。我立刻在提示词库的“可视化模板”中追加这条规则：“所有 savefig 必须包含 bbox_inches='tight' 和 facecolor='white' ”，下次自动生成即修复。

4.5 步骤4：业务洞察提炼（耗时2分15秒）

这才是GPT-3最惊艳的环节。我把漏斗数据表格（含新老用户各步UV和转化率）喂给模型，提示词是：

“你是一名电商增长总监，有10年用户运营经验。请基于以下漏斗数据，指出3个最关键的业务洞察，并给出可立即执行的1个优化建议。要求：洞察必须基于数据差异（如新用户在加购→下单环节流失率比老用户高22%），建议需具体（如‘在加购成功页增加老用户专享折扣弹窗’）”

模型输出：

1. 洞察1 ：新用户在“详情页→加购”转化率（38.2%）显著低于老用户（52.7%），差值14.5%，表明详情页对新用户的说服力不足；
2. 洞察2 ：老用户在“下单→支付”环节流失率（18.3%）高于新用户（12.1%），差值6.2%，暗示支付流程对老用户存在摩擦；
3. 洞察3 ：新用户“曝光→详情页”转化率（24.1%）远高于老用户（15.8%），说明首页推荐算法对新用户更精准；
   建议 ：针对洞察1，在商品详情页底部增加“新用户首单立减30元”浮动按钮（需技术评估，预计提升加购率5%~8%）。

我直接把这个分析复制进PPT，只修改了两个字：“浮动按钮”改为“悬浮优惠券”——因为技术团队反馈“浮动按钮”在iOS端兼容性差。整个分析过程，比我手动写快3倍，且视角更全面（我通常只关注流失率最高的环节，而模型强制我对比所有环节的差异）。

4.6 步骤5：交付物生成（耗时1分40秒）

最后，我用GPT-3生成PPT大纲：

“生成10页PPT大纲，主题：双11后7天用户行为漏斗分析。要求：第1页封面，第2页目录，第3页数据口径说明（含时间范围、新老用户定义、首次行为规则），第4-5页新老用户漏斗对比图（分两页，每页含一张图+3条关键结论），第6页核心洞察总结（3条，每条含数据支撑），第7页优化建议（1条，含实施路径与预期效果），第8页风险提示（如数据延迟影响支付成功率统计），第9页下一步计划（如A/B测试方案），第10页致谢。”

它输出的大纲逻辑严密，连“风险提示”都考虑到数据延迟——这正是我常忽略的细节。我按大纲填充内容，9:00前准时发出邮件。

5. 常见问题与排查技巧实录：那些让我摔过跟头的“幽灵Bug”

5.1 问题1：模型生成的代码在本地运行报错，但在线IDE却正常

现象 ：模型生成的pandas代码在Jupyter Lab报 SettingWithCopyWarning ，但在Google Colab运行完美。
根因分析 ：本地pandas版本为1.5.3，启用了严格的链式赋值警告；Colab默认1.4.3，警告级别不同。模型训练数据基于旧版文档，未适配新版警告机制。
排查技巧 ：

• 第一步：在提示词中强制声明 pandas.__version__ == '1.5.3'
• 第二步：要求模型在代码开头添加 pd.options.mode.chained_assignment = None （临时关闭警告）
• 第三步：终极方案——在所有生成代码后，自动插入验证行：

  # 验证赋值是否生效
  assert df.loc[df['status']=='shipped', 'processed'].nunique() == 1, "赋值未生效，请检查链式赋值"
  

这个assert语句是我从生产事故中提炼的：当警告出现时，往往意味着数据未被正确修改，而模型不会告诉你这点。

5.2 问题2：SQL查询结果与业务预期严重不符，但语法完全正确

现象 ：模型生成的漏斗SQL返回新用户UV为0，而实际数据库有2000+新用户。
根因分析 ：模型在 WHERE 子句中写了 is_new_user = true ，但PostgreSQL中布尔值比较必须用 IS TRUE （ = 对NULL不安全）。当 is_new_user 为NULL时， NULL = true 返回NULL而非false，导致这些记录被意外排除。
排查技巧 ：

• 建立“SQL安全操作清单”，在提示词中强制要求：

  “所有布尔字段比较必须用 IS TRUE / IS FALSE ，禁用 = ；所有涉及NULL的字段，必须用 COALESCE(field, false) 包裹”

• 在生成SQL后，用正则扫描： r'=\s*true|=\s*false' ，匹配即报警
• 对关键查询，强制添加验证SQL：

  -- 验证新用户基数
  SELECT COUNT(*) FROM bi_user_events WHERE event_time BETWEEN '2023-11-12' AND '2023-11-18' AND (is_new_user IS TRUE OR is_new_user IS NULL);
  

这个验证SQL让我在执行主查询前就发现了数据口径问题。

5.3 问题3：模型反复生成同一错误，修改提示词无效

现象 ：连续5次让模型生成“计算周同比”的代码，它总把 date_trunc('week', event_time) 写成 date_trunc('week', current_date) ，硬编码了当前日期。
根因分析 ：模型在训练时见过太多“计算本周数据”的示例，形成了强路径依赖。单纯修改提示词无法打破这种模式。
排查技巧 ：

• 注入“反例教学” ：在提示词中加入：

  “错误示例： date_trunc('week', current_date) —— 这会导致所有结果都基于今天，而非数据中的 event_time 。正确写法必须基于字段 event_time ”

• 强制变量命名 ：要求模型在代码中使用 {date_field} 占位符，我再用 replace() 替换为真实字段名。这样既规避硬编码，又保留灵活性。
• 设置“熔断机制” ：同一需求尝试3次失败后，立即切换策略——不再让模型生成完整代码，而是让它只生成关键表达式：

  “请只输出计算周同比的日期字段表达式，格式如： date_trunc('week', event_time) ，不加任何其他字符”
  这种“最小化输出”策略，成功率从42%提升到91%。

5.4 问题4：模型对“业务术语”的理解与公司内部定义冲突

现象 ：市场部定义“新用户”为“注册后30天内首单用户”，但模型始终按“首次访问即为新用户”处理。
根因分析 ：模型的知识库基于公开资料，“新用户”在大多数文档中指首次访问者。它无法自动适配企业私有定义。
排查技巧 ：

• 创建“业务术语词典” ：在每次任务开始前，先让模型加载术语定义：

  “请记住以下公司内部定义：

  • 新用户：注册时间在订单时间前30天内，且为该用户首单
  • 老用户：非新用户，或注册时间距订单超30天
  • 有效订单：支付成功且金额>0的订单”

• 术语一致性检查 ：在提示词末尾添加：

  “检查输出中所有‘新用户’‘老用户’表述，必须严格符合上述定义。若不确定，请先询问，而非自行推断。”

• 双阶段验证 ：第一阶段生成逻辑伪代码（如“IF 注册时间 <= 订单时间 - 30天 THEN 新用户”），我确认无误后再让第二阶段生成真实代码。这多花15秒，但避免了返工2小时。

5.5 问题5：模型在长上下文任务中“遗忘”早期约束

现象 ：一个包含5个子任务的复杂提示（如“先探查数据→再清洗→再建模→再评估→再可视化”），模型在第4步时忘了第1步声明的字段类型。
根因分析 ：GPT-3.5-turbo的上下文窗口虽有16K token，但注意力机制对早期token的衰减明显。它更关注最近的几句话。
排查技巧 ：

• 分段式工作流 ：绝不把5个任务塞进一个API调用。而是：
  1. 第1次调用：只做数据探查，获取字段类型、分布等元信息
  2. 将探查结果摘要（如“ amount 为float64，含0.3%空值”）作为新提示的开头
  3. 第2次调用：基于摘要做清洗，此时上下文全是关键约束
• 添加“记忆锚点” ：在每次新调用的开头，用固定格式重申核心约束：

  “【当前任务上下文】

  • 数据源： df_sales ，共12.7万行
  • 关键字段： amount (float64, 含空值)、 region (str, 5个取值)
  • 业务规则：空值 amount 用同 region 均值填充”
    这个锚点占用约20 token，但将任务一致性提升至99.2%。

注意：所有这些技巧，都不是为了“驯服”模型，而是为了“翻译”人类意图。我越来越确信：未来顶尖数据科学家的核心竞争力，不再是记忆多少函数，而是设计多少精准的“人机接口”。当你能用30秒写出让模型100%理解的提示词，你就赢得了别人用2小时调试的时间。这时间差，就是你思考业务本质、设计实验、影响决策的资本。