用Cursor写Python代码总出幻觉，是我prompt写得太烂吗？

说实话你这情况太典型了，PDF提取表格这种活儿本身格式就千奇百怪，Cursor生成代码时大概率是拿通用逻辑硬套，变量作用域和缩进这种细节它根本记不住。我试过把需求拆成“先读取PDF→再定位表格区域→最后清洗数据”三个小步骤，每一步单独让它写函数，最后自己拼装，成功率会高不少。另外它编造库函数这事，我怀疑是训练数据里混了太多不靠谱的教程，建议你看到不认识的库先查一下再跑，别直接信它。要是实在不稳，可以试试Claude的Artifacts或者直接把报错信息丢回去让它自己修，比反复改prompt省心。

说实话，多文件任务建议先把接口和数据结构定义清楚再让它写，比堆prompt管用多了。

说实话这情况太典型了，多文件协作任务对Cursor来说确实容易崩，尤其是它自己“脑补”API签名那部分，根本防不住。我后来学乖了，让它每一步输出前先列清楚要用的库和函数名，再让我确认，能砍掉一半幻觉。另外你试试把PDF表格的结构贴一段样例给它，比文字描述管用十倍。

别全让AI写，把函数签名和边界条件先定死，它会乖很多。PDF表格提取这种活儿，试试pymupdf四行代码就搞定。

说实话我觉得问题可能不在prompt，Cursor在生成这种需要多文件配合的脚本时确实容易自己脑补逻辑，变量作用域和缩进这些它经常搞混。我一般是让它先写个能跑的最小demo，确认没问题了再逐步加功能，别指望一次生成完整方案。另外你也可以试试让AI先画出数据流或者伪代码，再让它转成Python，比直接描述需求要稳很多。工具的话，Copilot chat在长任务上稍微靠谱点，但还是得自己盯着改。

说实话我觉得这锅不全在prompt，PDF提取表格这种活儿本身就涉及各种边界情况，模型再强也容易在细节上翻车。我自己的经验是先别让它一口气写完整脚本，而是把PDF解析、表格识别、数据清洗拆成独立函数，挨个验证再拼起来。另外你试试在关键逻辑后面直接让它补一段单元测试，能逼着它把变量和缩进理顺。工具的话，Copilot在补全上比Cursor稳一些，但复杂任务还是得靠人工兜底。

说实话你这个情况太典型了，我一开始用Cursor也这样，后来发现它本质是个概率模型，不是编译器，写长脚本时上下文一多就容易把变量名记混，尤其是跨文件协作的时候，它根本没法像人一样维护一个持久的内存状态。我现在的做法是让它一次只写一个函数，而且明确告诉它输入输出类型和边界条件，跑通了再让它整合，别指望它一口气给你整个模块。另外你提到编造库函数，这个我遇到过很多次，解决方法是先让它用标准库实现，或者直接指定版本号，比如写死pandas和pdfplumber的API，它就老实多了。至于prompt结构，我觉得不是越细越好，反而是把任务拆成一个个独立的验收单元，每个单元给个测试用例，这样它出错你能立刻定位，比写一大段描述管用。替代工具的话，如果你愿意折腾，GitHub Copilot的终端里跑测试反馈循环会稳一点，但说实话都是同一套底层模型，关键还是得学会“给AI当项目经理”，不然换啥工具都白搭。

说实话我也遇到过这情况，后来发现把需求拆成单个函数让它逐段实现，比一口气甩给它整个脚本靠谱得多。还有个小技巧：直接告诉它“先写伪代码再补全”，能减少不少幻觉。不过PDF表格提取这种活，格式稍微复杂点它就容易懵，我现在都是让它生成代码块，自己再手动改关键解析逻辑。感觉这工具更适合当加速器，不是完全甩手掌柜。

说实话这种多文件协作任务真别指望一次性生成，我都是让它先给骨架再逐块补逻辑，报错就贴回去让它自己修。

说实话这锅不全在prompt，AI写长代码本来就容易幻觉，拆成小函数让它逐个写反而靠谱得多。

说实话这锅真不全在prompt上，Cursor对多文件协作的理解还是太表面了，它经常把上下文里的“大概意思”当成“确切逻辑”，变量作用域和缩进这种细节特别容易崩。我试过把需求拆成单文件函数再让它逐个生成，成功率会高不少，但PDF表格提取这种活本身依赖的库（比如pdfplumber的边界情况）它确实容易瞎编。你要是图省事，可以试试Claude直接开项目模式，或者用GitHub Copilot的agent模式，至少变量名不一致的问题会少很多。另外，跑之前先让它用mypy检查一遍，能拦住不少低级错误。

说实话我觉得这锅不全在prompt上，Cursor对多文件协作的理解确实有限，尤其是涉及隐式依赖的时候，它很容易自己脑补出一些不存在的API。我自己的经验是，与其把需求写得很细，不如把每个函数接口、输入输出样例、异常处理逻辑直接贴进prompt里，让它照着填空，这样变量和缩进错误会少很多。另外你可以试试先把整个脚本的骨架手动搭出来，再让AI填核心逻辑，别让它从头生成完整文件，这种模式下幻觉率能降一半。工具方面我最近切到Claude Code配合小脚本跑测试，感觉比Cursor稳一点，但也没到省心的程度。

说实话你这情况太典型了，我用了大半年Cursor，感觉它写单文件小函数还行，一碰多文件协作或者依赖外部库的活儿，幻觉率直接翻倍。问题不一定全在你prompt，而是它训练数据里这种复杂业务代码的“正确样本”太少，它更擅长拼凑表面结构，而不是真理解变量作用域和库的真实API。我自己的经验是把任务拆成“伪代码步骤”喂给它，比如先让它只写PDF解析核心逻辑，跑通了再让它封装成函数，最后再让它接表格输出，一步一验，别指望一次生成完整脚本。另外你提到缩进错误，我怀疑是Composer模式上下文窗口太大会丢失早期代码细节，试试把它没改过的旧文件先丢进对话里“提醒”一下。替代工具的话，如果你愿意折腾，GitHub Copilot的agent模式其实更稳一点，但也没本质区别。最靠谱的还是让它生成后再用pylint或者pyright自动扫一遍逻辑错误，比自己肉眼查快很多。

说实话跟prompt关系不大，这种多文件协作任务Cursor本来就容易编，建议拆成单文件小步验证。

说实话这情况太常见了，我甚至怀疑Cursor在生成多文件项目时压根没做完整的符号表关联，变量作用域全靠猜。你试试把每个函数的输入输出类型和异常处理直接写进注释里，它抄代码时反而更守规矩。另外别迷信Composer，单文件窗口里把参考代码贴进去让它改，成功率会高不少。替代工具的话，Copilot在纯代码补全上更稳，但长流程逻辑还是得自己搭骨架。

这情况太真实了，复杂任务还是得把函数签名和依赖库提前写进上下文里，不然它真敢瞎编。

多文件协作建议直接上Claude加MCP，或者干脆自己搭个结构化骨架让它填逻辑，稳得多。

说实话我觉得问题可能不在prompt上，PDF表格提取这种任务本身就挺吃上下文的，Cursor一次要处理文件读取、格式解析、异常处理好几件事，它经常在中间步骤上“自圆其说”。我试过把需求拆成函数级别让AI逐个写，再自己拼装，出错率明显低很多。另外你提到的编造库函数，大概率是模型训练数据里没见过那个库的真实API，建议让它先输出依赖清单，你确认后再动手。如果你想要更稳，可以试试Claude的代码模式或者直接上GitHub Copilot加本地测试循环，感觉比Cursor更少幻觉。

说实话这情况太常见了，我试过让它写个稍微复杂点的数据处理流水线也是这德行。感觉本质不是prompt的问题，而是它压根没法在脑子里维护多文件之间的状态依赖，变量作用域一多就容易瞎编。我现在的土办法是逼它把所有逻辑塞进一个函数里，跑通了再手动拆，虽然丑但至少能少一半幻觉。另外你可以试试给它喂一个真实可运行的简化版示例，让它照着改，比纯文字描述靠谱得多。

这锅真不全在prompt，多文件任务还是得靠人盯着，不然它自己编个函数名你根本发现不了。

说实话我觉得这锅不全在prompt上，Cursor在生成多文件协作代码时本身就容易丢失上下文状态，尤其是你让它改A文件时它可能已经忘了B文件里的变量定义。我自己试过把项目结构、函数签名、依赖关系全写在prompt里，它该幻觉还是幻觉，反而越详细越容易让它编造出看似合理但根本不存在的接口。后来我学乖了，复杂任务先让它生成单文件的可运行原型，跑通了再让它拆模块，每次只改一个文件，出错概率明显降下来了。另外它编造库函数这事，我怀疑是训练数据里混入了太多不规范的教程代码，你可以在prompt里明确要求“只使用标准库或已安装的包，并列出具体版本”，能稍微约束一下。替代工具的话，Copilot在补全单函数时更稳，但多文件协调也一般；如果你愿意折腾，试试开源的Continue或Tabby，虽然没那么智能，但至少不会一本正经地胡说八道。最后想问下你用的是Cursor的哪个版本？我升级到最新版后幻觉问题好像轻微改善了一点，但也有可能是心理作用。