用Prompt写Python脚本老是在小细节上翻车，怎么调才稳？

我试过把样例数据直接贴进Prompt里，确实管用，尤其是日期和空值这种格式，它看到实际样本就不容易瞎猜了。另外我会让它先写个伪代码框架，确认逻辑对了再要完整代码，这样能少改一半毛病。还有个土办法是让它每一步都print一下中间结果，跑挂了也好定位是哪一步出的问题。

贴样例进去确实管用，尤其日期格式这种，你给它两行真实数据，它就知道该用哪个解析规则了。再就是别指望一步到位，先让它把逻辑框架写出来，你确认没问题了再让它补细节，不然它自己容易跑偏。还有个土办法，让它每步操作都加个print，跑一遍看中间结果，哪个环节错了直接指给它改，比最后debug省事多了。

这问题我太熟了，光说需求不贴样例，模型全靠猜，翻车概率肯定高。我现在的做法是先把CSV前几行直接粘进Prompt，再让它写代码，日期格式和列名它自己会对着调整。另外建议拆成两步走，先让它把处理逻辑用自然语言列出来，你确认没问题了再让它出代码，这样比一步到位稳得多。聚合那步容易乱索引的话，干脆在Prompt里加一句“重置索引并保留分组列”，基本能避开这个坑。

贴样例数据进去能少踩一半坑，再让它分步跑，先确认逻辑再出代码，别一次性梭哈。

说实话你这个问题我太有共鸣了，之前我也这么干过，后来发现关键不是把需求写得多全，而是让它“看见”数据长什么样。你光说“日期列转datetime”，但GPT根本不知道你的日期是20240101还是01/02/2024还是带时区的字符串，它只能瞎猜，猜错了你就得返工。所以把CSV的前五行样例直接贴进Prompt里，比写十句描述都管用，它看到真实格式后生成的正则和parse逻辑会准很多。另外我强烈建议你让它分两步走，第一步只让它描述处理逻辑和每一步的输出结构，确认没问题了再让它写代码，这样比直接生成一坨代码好改得多。还有个土办法，就是让它每步操作后print一下shape和dtypes，这样跑挂了你能立刻定位是清洗环节还是聚合环节出的岔子。最后就是别指望一次搞定，把报错信息原样贴回去让它自己修，比你自己猜它的思路要快，但记得限制它只改出错的那一行，不然它可能顺手把别的逻辑也重构了。

光给需求不行，把CSV前几行和报错信息直接甩进去，它自己就能调对大半。

说实话你这情况太典型了，我一开始也这样，后来发现关键不是把需求写得多详细，而是得把“边界条件”喂给它。比如你说日期列转datetime，但GPT根本不知道你的日期是“2024/1/5”还是“01-05-2024”，它只能猜，一猜就容易翻车。所以把样例数据贴进去真的很有必要，哪怕就贴三五行，它能从格式反推解析逻辑，比纯文字描述准得多。

另外我建议你分两步走，先让它写一个伪代码流程，你确认逻辑没问题了再让它出具体实现。这样至少能把“设计错误”和“语法细节”分开排查，不然它把聚合逻辑和索引重置混在一起出错，你根本分不清是思路问题还是代码问题。还有个土办法，就是让它每步操作后print一下shape和head，这样你能在中间结果里一眼看出哪里歪了，比最后报错再回头找快多了。

我自己的经验是，凡是涉及pandas的活儿，干脆直接告诉它“用method chaining风格写”，这样它不容易在中间变量上搞乱索引，而且你review起来也清晰。最后如果你已经试过这些还老翻车，那就别硬调了，让它把逻辑讲清楚，你自己动手改那几行，反而比来回对话省时间。

说实话你这个情况太典型了，我一开始用AI写脚本也天天在小坑里栽跟头。后来我发现关键不是把需求写得多详细，而是得把“数据长什么样”告诉它，光说“日期列”它根本不知道你那是2024/01/01还是01-JAN-24，贴两行真实样例比写十句描述管用得多。再一个就是别指望一次生成就能跑，我现在的习惯是让它先输出处理逻辑的伪代码，确认思路对了再让它写具体实现，这样至少不会在聚合索引这种地方翻车。还有个土办法，就是让它每步操作后面加print看中间结果，跑错了能立刻定位是哪一步出的问题，改起来快很多。另外你提到“按月份聚合”，这词儿其实挺模糊的，是要sum还是mean？要不要保留其他列？这些不写清楚它肯定自由发挥。反正我的感觉是，跟AI打交道就得当它在做代码审查，你把边界条件和预期输出都摆出来，它反而能给你写出更稳的版本。你要是愿意，可以把你那个CSV的列名和几行数据脱敏后发出来，我帮你看看怎么调Prompt。

说实话你这个问题太典型了，我一开始也是这么翻车的。核心问题不是Prompt写得不够清楚，而是你把“业务目标”直接丢给了模型，但模型对数据里的实际脏情况一无所知，比如CSV里的日期到底是2024/1/1还是2024-01-01，空值是空白字符串还是NaN，这些细节它全靠猜。所以贴样例绝对是个好办法，但别贴整份文件，截取前五到十行，把有代表性的异常也混进去，比如某行日期是“2024年1月”，某列空值是“N/A”，模型看到真实样本后，生成的代码匹配度会高很多。另外我强烈建议分两步走：先让它输出处理逻辑的伪代码或步骤清单，你确认没问题了再让它写具体实现，这样能把逻辑错误和语法错误隔离开，排查起来快得多。还有一个我常用的土办法，就是在Prompt里强制要求它“每一步操作后打印DataFrame的shape和前两行”，这样你跑一遍就知道它在哪一步把索引搞乱了，而不是最后报错才一脸懵。最后，如果你发现它反复在日期格式上出错，不如直接告诉它“用pd.to_datetime(..., errors='coerce')，并先检查列里的唯一值”，这比让它自己猜要稳得多。反正我的经验是，把AI当成一个刚入职的实习生，你得给它看数据样例、明确操作顺序、还要它汇报中间结果，它才能干得像样。

我还真遇到过一模一样的坑，后来发现把样例数据贴进去确实管用，但别贴太多，三五行带各种边界情况的就够。另外我习惯让它分两步走，先让它描述处理逻辑，确认没问题再让它写代码，这样它自己都不容易绕晕。还有个土办法，就是让它每步操作后打印一下shape和dtypes，翻车了能直接定位到是哪一步的问题。

我试过几次也是这德行，后来发现直接把样例数据（哪怕几行假的）塞进prompt里，再让它按字段名写代码，翻车率能降一半。另外别让它一步到位，先让它列个处理步骤，你确认了再让它写具体实现，这样逻辑错了容易看出来。聚合索引乱的话，你可以在prompt里明确要求reset_index或者指定keep columns，不然它老按默认来。

贴样例绝对管用，再让它先写伪代码确认逻辑，最后再出完整代码，能少踩一半坑。

贴个样例数据进去真能避不少坑，再让它分步写，别一次梭哈。

我之前也老栽在这上面，后来发现光说需求不够，得把CSV的前几行样例直接贴进去，再让它按你给的格式写，不然它自己脑补的数据结构跟实际对不上。另外建议别让它一口气出完整代码，先让它列个处理步骤，你确认没问题了再要代码，这样它逻辑跑偏的概率小很多。还有个小技巧，让它每一步都加个print看看中间结果，出错一眼就能定位，不用整段瞎猜。

贴样例数据进去真的管用，我都是让它先跑通再改格式，分步来稳很多。

贴样例进去确实管用，再让它先跑个前几行数据给你看看，别直接上全量。

贴个两三行样例数据进去，再让它先打印中间结果，翻车率能降一半。

这事儿我太有同感了，GPT写代码就跟面试一样，你光说“做个数据清洗”它当然给你个理想化答案，但真实数据里全是坑。我现在的做法是，把CSV的前三行直接粘进Prompt里，再附上你想要的输出长什么样，比如日期是“2024-01-01”还是“01/01/2024”，它立马就老实多了。另外你说分步骤出逻辑再出代码，这招确实有效，但别让它一次性输出全部，先让它用伪代码描述步骤，你确认逻辑对了再让它写具体实现，能省掉一半返工。还有个小技巧，就是让它每步都加print看中间结果，这样它自己调试的时候就知道卡在哪，但你要在Prompt里明确要求“每一步都打印shape和dtypes”，不然它默认就跳过检查了。至于聚合乱索引，你可以直接告诉它“reset_index(drop=True)”或者保留某个列做groupby，这种细节你不点破它真猜不到。说到底，别把它当全能工程师，就当个手脚麻利的实习生，你交代得越像给实习生交代的，它翻车概率就越低。

我自己的经验是，光靠一段笼统的Prompt确实容易在边界条件上翻车，尤其是日期格式和索引重置这种，模型根本不知道你的CSV长啥样。你试着把前几行数据直接贴进去，再告诉它哪一列是日期、具体是什么格式，比如“2024-01-05”还是“2024/1/5”，它生成正则或者parse的逻辑就会准很多。另外别指望一次到位，我习惯让它先输出处理步骤的伪代码，确认逻辑顺序没问题了再让它写实现，这样至少聚合前你知道索引要不要reset。还有一个特别实用的技巧，就是明确告诉它“每一步操作后打印shape和前两行”，这样你跑完能立刻定位是哪一步出了问题，而不是对着报错瞎猜。其实说到底，这种小活儿不如自己写，但如果你非要调，就把Prompt当成给新同事的交接说明——越琐碎越好，连“空值包含NaN和空字符串”这种废话都要写清楚。我试过最稳的方式是让它生成代码的同时，强制要求加assert检查，比如断言日期列没有NaT，聚合后索引是唯一的，这样翻车概率会小很多。

我之前也老栽在这上面，后来发现光描述逻辑真不够，必须把CSV的前几行样例直接贴进Prompt里，尤其日期格式长啥样，让它照着样例写，翻车率能降不少。另外别指望一步到位，先让它用伪代码列步骤，你确认逻辑没问题再让它生成代码，这样小细节出错的位置一眼就能看出来。还有一招，就是让它把中间结果打印出来，跑一遍看哪步不对，比反复改Prompt高效多了。