用Cursor写Python脚本，prompt怎么调才能让AI少犯低级逻辑错误？

我跟你的感觉完全一样，刚开始用Cursor写脚本时也是图省事直接扔一句“写个批量改名脚本”，结果跑出来各种小bug，改得心累。后来我发现prompt里最管用的其实是把“输入输出样例”和“边界条件”写清楚，比如文件名带空格怎么办、路径是相对还是绝对，AI一旦有具体例子参考，逻辑错误明显少很多。再就是加一句“请添加必要的异常处理和日志输出”，这样它会主动考虑文件不存在、权限不足这些情况，循环里忘记更新变量这种低级错误也更容易被它自己检查出来。还有个技巧是让它在生成前先写伪代码或逻辑步骤，你可以说“先列出实现思路，再写代码”，这样AI会强迫自己梳理流程，比直接蹦代码靠谱多了。另外我个人经验是，对于数据处理类脚本，最好在prompt里明确“目标环境是Python 3.x，使用标准库为主”，不然它可能给你整出些花里胡哨的第三方依赖。最后想说，别追求一次完美，让它先跑一遍，然后把报错信息贴回去问“这段报错了，帮我修一下”，其实比反复调prompt更省时间。

确实，笼统的prompt容易让AI放飞自我。我的经验是先把输入输出样本写进prompt，比如直接给一行CSV数据，再明确说“路径从命令行参数读”，这样它就不敢瞎写死路径了。另外加一句“每个函数都要处理异常并返回错误信息”，能逼它把逻辑梳理清楚。对了，循环里忘更新变量这种，可以在prompt里单独列一条“注意循环变量的递增或边界条件”，实测能减少挺多低级bug。

把输入输出格式和边界情况直接写进prompt里，比如“文件不存在就报错跳过”，AI能少犯一半糊涂。

我的经验是，prompt里光写“实现xxx功能”确实容易翻车，尤其是涉及循环和文件路径这种细节。我现在基本会强制要求AI先描述一遍逻辑流程，再让它写代码，相当于让它在动手前把思路理清楚，这样低级错误会少很多。另外，像“输入文件路径用相对路径，且用pathlib处理”和“循环里每一步都打印调试信息”这种约束，我会直接写进prompt里，就算代码啰嗦点，也比跑一半报错强。还有个小技巧，就是让AI自己列出三个容易出错的边界情况，比如空文件、重复文件名、编码不一致，然后针对每个情况写处理逻辑，这比单纯说“要异常处理”管用得多。不过说实话，一次生成就完美跑通挺难的，我现在反而习惯了让它生成后，我再丢一个报错信息回去，让它自己改，一来一回反而比反复调prompt效率高。

确实，prompt太笼统AI就只能靠猜了。我一般会把输入输出样例直接贴进去，比如CSV长什么样、重命名规则是什么，再明确要求用pathlib处理路径，别写死。再就是加一句“每一步操作都打印日志”，这样逻辑错了能快速定位。另外让它把函数拆小，一个功能一个函数，别全塞main里，改起来也省事。

prompt确实太宽了，AI不知道你的“跑通”标准是什么。我一般会强制加三段：输入长啥样（列名、编码）、输出必须长啥样（文件名规则、返回格式）、还有边界条件（比如空文件、重复文件怎么处理）。另外让它把每一步逻辑先注释出来再写代码，这种低级错误会少很多。

试试在prompt里把输入输出样例贴出来，再让它写异常处理和边界情况，基本一次就能跑通。

确实，光说“写个脚本”AI很容易放飞自我。我一般会强制它在prompt里先声明输入输出格式，比如“读取data文件夹下所有csv，输出一个合并后的表”，再补一句“路径用相对路径，不要硬编码”，这样能少踩好多坑。另外让它“每一步打印日志”也是个好办法，逻辑断点一眼就能看出来，比回头debug省事多了。

太笼统确实是核心问题，我刚开始用的时候也这样。你试试把“写个脚本”换成“写一个Python函数，输入是某路径下的所有csv文件，输出是合并后的DataFrame，要求跳过空文件”，这样AI至少知道边界在哪。另外我习惯在prompt里直接给一段样例输入和期望输出，哪怕就三行数据，比你说一百句“注意逻辑”都管用。还有个坑是它老喜欢把路径写死，我现在都会加一句“所有路径必须作为命令行参数传入，不要硬编码”，这句话基本能杜绝大部分低级错误。异常处理也得点名，比如“文件不存在时打印错误并跳过，不要中断整个流程”，不然它默认就裸奔。最后，生成完别急着跑，先让它自己解释一遍逻辑，或者让它输出几个关键变量的中间值，这比反复改prompt效率高多了。对了，你用的模型版本是3.5还是4？我感觉4在循环边界上的理解好不少，但偶尔还是会在嵌套推导式里犯晕。

试下把“写一个脚本”换成“写一个函数，输入是CSV路径，输出是清洗后的DataFrame”，再明确告诉它文件路径用Path对象别写死，循环里手动维护状态的地方直接让它用enumerate或者列表推导式。我一般还会加一句“处理异常时打印错误信息但别中断整个流程”，这样能避免它自己脑补一堆没用的try except。另外让它先列伪代码再写实现，比直接要代码稳很多，你可以试试。

确实，目标写得太粗AI就容易自由发挥。我一般会强制加一段“输入输出示例”，比如给它一个两行的CSV样例和期望输出，它逻辑就清晰很多。还有就是把异常处理和边界条件单独写一句，比如“文件不存在时打印错误并跳过”，比笼统说“要健壮”管用。另外，循环里那种低级错误，你干脆让它把每次迭代的变量变化print出来，一眼就能看出问题。总之就是把“写脚本”改成“按这个输入，做这几步，输出那种格式”，错误率能降一大截。

确实太笼统了，你光说功能，AI默认就按最省事的写法来。我一般会在prompt里明确“输入数据长什么样、输出文件长什么样”，再补一句“路径用参数传，别硬编码”，这样它至少不会把路写死。另外你提一嘴“处理前检查文件是否存在，出错时打印日志”，逻辑漏洞会少很多，循环变量这种多让它用enumerate或者推导式，反而比手写下标稳。

我试过一阵子，感觉最大的坑就是把需求说得太“像人话”，AI容易自由发挥。我会在prompt里明确写“输入是来自命令行参数还是硬编码路径”，“输出格式是打印还是写文件”，再补一句“每一步循环里变量要重新赋值”，基本能拦住大部分低级错误。另外我习惯让它先列个步骤清单再写代码，逻辑顺很多，最后让它自己跑个边界case（比如空文件）看看，比反复改省事。

把输入输出格式和边界条件写进prompt，比如“文件不存在就报错跳过”，一次过率能高不少。

太笼统确实是问题，我现在的做法是开头先甩出输入输出样例，再补一句“路径用相对路径，文件不存在要报错”，这样它至少不会把逻辑跑飞。另外可以试着把步骤拆开问，比如先让它写核心函数，再补外层循环和异常处理，比一次性给个大需求稳很多。还有个小技巧，让它“用最直观的写法，别做优化”，反而能少点自作聪明。

把输入输出样例直接贴进prompt里，再让它写异常处理和边界条件，能少踩好多坑。

确实，prompt太笼统的话，AI就是纯靠猜，路径写死、循环变量不更新这种坑我刚开始也踩了不少。我的习惯是先把输入和输出的具体格式用一两行伪代码写清楚，比如“输入是CSV，列名有date和amount，输出是过滤掉空值后的新文件”，这样它至少不会在边界条件上自由发挥。另外我会强制要求它把所有可能变化的参数都提成函数参数或者脚本开头的常量，这样就算逻辑有瑕疵，我改起来也快。异常处理这块我一般会加一句“每个文件操作都要try-except并打印具体错误”，不然它经常假装成功。还有个小技巧是让它先写个对单个文件能跑通的版本，再让我手动套循环，比让它一步到位靠谱很多。对了，你试过在prompt里加“不要使用绝对路径，用os.path.join拼接”这种负面约束吗？感觉对这类工具脚本特别有效。

你这个问题太真实了，我刚开始用的时候也这样。后来发现prompt里必须把输入输出样例给出来，比如“输入是这种格式的CSV，输出要包含哪几列”，AI一旦有了具体参照，逻辑就稳很多。

另外可以加一句“每一步操作都要print日志”，这样它写代码时就会下意识考虑流程的可追踪性，很多低级错误自己就暴露了。还有个小技巧，直接告诉它“文件路径用argparse传入，不要硬编码”，这比让它自己发挥要靠谱得多。

我一般还会补一句“如果遇到文件不存在或格式错误，要给出中文提示并跳过”，把异常处理也圈进要求里。这样改下来，基本两三轮内就能跑通，比一开始那种一句话prompt省心太多了。

确实太笼统了，你光说功能，AI就只能猜。我一般会强制要求它先列伪代码或者分步骤逻辑，再写实现，这样循环和变量更新它自己就理清了。

另外把输入输出样例直接怼给它，比如CSV的表头、期望的返回格式，再补一句“路径参数化，别写死”，低级错误能少一大半。异常处理也得点名，让它必须加try-except和日志，不然它默认裸奔。

还有就是让它先跑一遍“边界测试”，比如空文件、文件名带空格，它自己就会去修逻辑了。我试下来，多花十秒钟写约束，比改半小时bug强太多。

我试过一阵子，感觉prompt里必须把输入输出的边界说清楚，比如“传入一个文件夹路径，返回一个dict，key是原文件名，value是新文件名”，这样它就不会自作主张去硬编码路径了。另外一定要加一句“处理前先检查文件是否存在，异常时打印错误并跳过”，这种约束比单纯说“要健壮”管用得多。循环变量那个问题，我习惯在prompt最后补一句“请确保循环内每次迭代都更新状态变量”，虽然有点笨但确实能减少低级失误。还有就是让它先写个伪代码框架再填充细节，比直接要完整代码靠谱。