用AI写Python脚本，提示词怎么写才能一次跑通不用反复改？

我一般是直接把数据样例贴给它，比如CSV的前三行和期望输出长啥样，再让它写，这样比光描述“合并列A和B”准确多了。还有个小技巧，就是让它先分步写注释再补代码，比直接写逻辑容易一次过。不过说实话，小脚本还是得自己会改，AI跑通了逻辑，但边界情况比如表头带空格、空值这些，它经常考虑不到。

试试先给字段示例再加个断言，让它自己按数据形状跑一遍，比干写逻辑稳多了。

把输出列名和文件编码直接写死进提示词，我试过这样基本不用改第二遍。

把输入输出的样例直接贴给它，再让它按样例跑通，比光写需求稳得多。

我一般是先让它给伪代码确认逻辑，对了再生成，基本一次过。

我个人试下来，最稳的办法是把“输入长什么样”和“输出长什么样”各给一小段示例，比如直接贴两行CSV和想要的结果，代码逻辑基本就八九不离十了。另外别让它一次干完所有事，先让它读文件打个样，确认没问题了再让它加合并去重，拆成几步反而出错少。至于伪代码，对简单任务有点多余，但如果你自己都理不清步骤，那确实值得先让它列个流程。

说实话，你这个问题我太有共鸣了，之前用AI写脚本也经常被“少import”这种低级错误搞到崩溃。后来我发现，光把任务描述清楚是不够的，关键是得让AI明白它的“输出边界”——比如我习惯在提示词末尾加一句“只输出完整可运行的代码，不要注释，不要解释”，这能省掉很多它自作主张加进去的废话。你提到要不要写数据结构，我觉得非常有必要，尤其像CSV这种，你得告诉它“第一行是表头，列名分别是A和B”，不然它分分钟猜错你的数据格式。至于伪代码那步，我倒是觉得对多步骤任务挺有用的，可以让它先列个处理步骤，比如“读取→合并→去重→排序→保存”，你确认逻辑对了再让它生成代码，这样比直接生成靠谱得多。还有个土办法，就是让它把每一步的print结果都加上，跑一遍看中间输出，哪里不对改哪里，比盲猜快。另外错误处理这块，我一般不写进提示词，因为写了反而容易让它生成一堆try-except把代码搞复杂，不如让它默认按最简单的方式处理，真遇到问题再单独问。

说到“一次过”，其实还有个小技巧，就是给它一个明确的输入输出样例，比如“输入‘a.csv’内容如下，输出应该是这样”，它模仿样例的能力比理解抽象描述强太多了。我现在写数据处理脚本基本都这套路，虽然不敢说百分百一次跑通，但至少改个一两回就能用，比最初那种反复试错强多了。

我个人习惯是把输入输出格式写死，比如“读取a.csv，列名是xxx，合并后输出为b.csv，保留表头”，再补一句“如果某行有空值直接跳过”。这样比让AI自由发挥稳很多，尤其数据处理这种步骤明确的，伪代码其实没必要，反而容易让它跑偏。

另外我会在提示词末尾加一句“用pandas实现，不要用csv模块”，不然它有时候会给你写个低效的循环。还有个小技巧，如果逻辑稍微复杂点，可以先让它“分步写注释再补代码”，这样它自己会检查每一步对不对，出错率明显低。

不过我也有个疑问，你试过把示例输入和期望输出直接贴进提示词吗？我最近发现这个对“一次过”帮助特别大，比纯文字描述管用多了。

我一般会把输入输出样例直接贴进提示词里，比如给两行CSV数据，再标清楚合并后长啥样。这样AI对格式的理解比纯文字描述准得多，基本一次跑通。少import的问题也可以靠提示词里加一句“列出所有用到的库并检查是否缺失”来规避。伪代码那步我个人觉得没必要，小任务直接给样例最省事。

我自己的土办法是把“输入长啥样、输出长啥样”各贴一小段示例进去，AI对格式的理解比纯文字描述准得多。另外你那种多步骤的活，我习惯让它拆成三步写，每步print个中间结果出来对一眼，这样就算逻辑错了也知道错在哪一步。至于错误处理，除非数据里真有脏值，不然先别写，省得它发挥过度。

我最近也踩过这坑，后来发现把列名和具体的数据样例（哪怕两三行）直接贴进提示词里，AI对结构的理解会准很多。另外我习惯让它先输出“处理步骤注释”再写代码，相当于伪代码，跑偏概率确实低一些。不过说实话，一次跑通挺难的，我现在都默认做好小改的心理准备。

把输入输出的样例直接贴进提示词里，AI照着格式写基本一次过，比描述逻辑管用多了。

我个人试下来最管用的就是把你说的“直白描述”再拆细一层，比如明确告诉它“第A列是姓名，第B列是日期，合并后中间加个逗号，去重时保留第一次出现的行”。另外让它先跑个print输出前5行，确认数据结构后再动逻辑，比自己瞎猜省事多了。至于伪代码，我觉得小任务没必要，但让它把步骤写在注释里确实能减少漏import的情况。

说实话直白描述确实不够，Cursor对数据处理的隐式逻辑经常猜错。我的套路是把输入输出样例直接贴进去，比如"第一列是日期格式2024-01-01，第二列是姓名"，再明确说要保留哪几列、去重后按什么排序，这样它基本能一次写对。另外让它先写伪代码这步我试过，对复杂任务有用，但简单脚本反而显得啰嗦，不如直接给边界条件，比如"如果某列有空值就跳过该行"，命中率会高很多。

我自己的经验是别急着让它直接写完整代码，先让它列出处理步骤和数据样例，确认逻辑后再生成。另外提示词里一定要带上输入文件的表头和几行数据示例，不然它真的会瞎猜列名。还有个小技巧，把“去重”明确成“根据某列去重”还是“整行去重”，不然它默认给你全字段去重，结果就偏了。

说实话我觉得“一次过”这个目标本身可能就有点反AI的工作方式，我自己的经验是，与其追求完美提示词，不如把迭代成本降到最低。比如我会在提示词里明确写上“处理前检查列是否存在，缺失值直接删除”，这样至少能砍掉一半因为数据脏导致的报错。另外你提到让AI画伪代码，这个我试过，对小任务有点大材小用，反而容易把流程搞复杂。更实用的做法是直接给出输入输出的前几行示例，比如“a.csv第一行是标题，A列是日期格式B列是姓名”，这样它生成的代码会更贴近实际数据结构。还有个坑是很多人忘了告诉AI“最终保存的编码格式”，默认utf-8经常会遇到中文乱码，加一句“输出用utf-8-sig”能省很多事。至于错误处理，我觉得对数据处理脚本来说，与其让AI写一堆try-except，不如让它先跑通主流程，大不了报错了再单独补。说到底，把任务拆成“读文件→处理→保存”三个子命令，每个步骤单独验证，比指望一个提示词全搞定靠谱得多。

我试过把数据结构、列名和期望输出样例直接贴进prompt，比纯文字描述成功率高一截，尤其是让AI先打印中间结果再跑后续步骤。你说的伪代码那招也行，但我觉得对Cursor来说，更管用的是让它生成代码后加一句“请自查import和常见边界条件”，能省不少事。另外数据处理这种多步骤任务，我会拆成“读文件、处理、验证、保存”四段来写，每段单独给示例，基本一次过。你也试试把CSV的前几行样例放进去，比干巴巴描述“合并A和B列”强多了。

我自己的经验是别让AI一口气全写完，先告诉它“读CSV后用pandas，合并列用字符串拼接，去重按新列”，它写起来就没那么多歧义了。另外把输入输出样例贴进提示词里特别管用，比如给两行假数据说“我要这种效果”，它基本一次就能跑通。伪代码那步我觉得没必要，但明确指定库和函数名比让AI自由发挥稳得多。

说实话我觉得“一次跑通”这个目标本身就不太现实，我用了半年Cursor，能一次过的脚本大概只有三成。你的描述其实已经够直白了，但AI对“合并”的理解可能和你不一样，比如它不知道你是要拼接成一个新列还是保留两列，去重是看整行还是看合并后的值。我现在习惯在提示词里直接贴两三行示例数据，再写上“输入长这样，输出我想要那样”，比纯文字描述管用得多。至于要不要先画伪代码，我试过几次，对简单任务反而多余，不如让它直接生成，然后把报错信息原样贴回去让它自己改，这比反复改提示词效率高。另外，像缺少import这种问题，我会在提示词末尾加一句“请包含所有必要的库”，虽然听起来很蠢，但确实能减少一半的返工。说到底，AI写脚本就是个迭代过程，别指望一次过，把预期输出格式写清楚比什么都强。

直接把输入输出样例贴进提示词，比描述逻辑管用，AI照着格式写基本一次过。

我试过让它先列处理步骤再写码，多一步确认反而省了来回改的功夫。

说实话我试下来，直白描述确实容易翻车，尤其是多步骤任务，AI很容易漏掉中间环节。我的经验是别让它直接写代码，先让它用自然语言列一遍处理流程，比如“读取CSV，合并列生成新列，按新列去重，最后输出”，这样它能先理解逻辑，你再让它基于这个流程写，成功率高很多。另外提示词里最好带上数据样例，哪怕就两行，告诉它列名是啥、分隔符是什么，AI就不会瞎猜了。至于错误处理，我觉得对数据处理小脚本来说不用太纠结，但至少要指定输出文件的编码和是否带表头，不然容易在边界问题上翻车。还有个土办法，让它分两步走，先写核心逻辑跑通，再单独让它补异常处理和文件路径兼容，比一次要全部功能稳得多。说到底，AI写代码就像带新人，你把上下文交代清楚，它才不容易自由发挥。

我之前也卡在这块，后来发现把“输入长什么样、输出要什么格式”直接贴进提示词里，比描述逻辑有用得多。比如你那个CSV，给个两行示例数据，再写清“合并后列名是XX，去重要保留哪几列”，基本一次就能跑通。伪代码那步我倒没用过，但把错误处理比如“空值直接跳过”加进去，能少改好几轮。你可以试试把任务拆成两步，先让AI写个函数框架，再填细节，稳定性会高不少。