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

直接让它生成整个脚本确实容易翻车，我都是让它先给核心函数，再慢慢拼起来。

试试把PDF样本和预期输出直接贴给它，比文字描述管用多了。

说实话你遇到的情况太典型了，PDF表格提取这种活儿本身就带着“结构性陷阱”，AI很容易在没看到真实文件的情况下脑补字段和布局。我自己的经验是，与其把需求写细，不如直接给它一个最小可运行的骨架代码，哪怕只有读取PDF和打印前两行，让它在这个基础上改，幻觉会少一大半。另外你提到变量未定义和缩进错误，这多半是Composer在多文件切换时上下文丢失导致的，不是prompt的问题——它经常把A文件里的变量名套到B文件里。我建议你试试把任务拆成“先提取纯文本，再单独做表格结构识别”两步，每次只让它专注一步，别指望一次生成完整pipeline。至于更稳的工具，如果你不排斥写点胶水代码，可以试试把Cursor生成的逻辑丢给Claude或GPT-4o复查，用它们做“代码审查”比直接生成靠谱。还有个野路子，你可以在prompt里明确要求“所有函数必须带类型注解”，这能逼着它少编造不存在的库。总之别太纠结prompt措辞，这种任务本身更适合“分步调试+人工兜底”的流程，AI当个高级搜索用就行。

说实话我觉得问题可能不在prompt上，Composer处理这种需要跨文件理解的任务确实容易崩，它更像是个高级补全工具而不是架构师。你不如把PDF解析、表格提取、结果输出拆成三个独立函数让它逐个写，每完成一个就手动跑一下验证，别指望一次性生成完整脚本。另外变量未定义这问题多半是它上下文窗口太长导致注意力漂移，我一般会在关键代码段后面加注释提醒它保持状态。替代工具的话，试试Claude的Artifacts或者直接上GitHub Copilot的agent模式，至少它们对现有代码的感知会强一些。

说实话你这情况我太熟了，Cursor编造不存在的库函数这事儿我也踩过坑，后来发现它其实是在“合理猜测”API，尤其是处理PDF这种生态比较杂的领域，它训练数据里可能只有旧版pypdf或PyPDF2的用法。我觉得问题不一定全在prompt，而是Composer模式本身就更适合生成独立函数或小脚本，像“批量处理文件+表格提取”这种涉及多步骤、状态流转的任务，它很难一次性hold住。我的做法是让它一段段写，先让它给我生成文件遍历和PDF读取的核心逻辑，跑通了再让它加表格解析，最后再让它拼装成完整脚本，每一步都验证过再进下一步。另外你可以试试在prompt里直接指定“只使用已安装的库”，或者把requirements.txt的内容贴进去，能明显减少它胡编函数的情况。如果还是不稳，我建议你换个思路，用传统工具比如pdfplumber自己写个10行的小脚本，反而比跟AI斗智斗勇省时间，AI这时候更适合用来解释报错或者优化已有代码。

说实话你这情况我也踩过坑，后来发现Cursor对“隐式上下文”理解很差，比如PDF表格提取这种活，它默认你会自己处理依赖和异常分支，但实际跑起来就露馅。我现在的做法是先把文件结构、函数签名、期望的输入输出格式写成伪代码贴进去，再让它填空，比直接描述需求稳很多。另外如果你要处理的是那种带合并单元格的表格，建议直接上pdfplumber，别让AI自己猜库，它编造函数名这事我遇到太多次了。工具方面，Claude的Artifacts模式在单文件脚本上比Cursor靠谱，但多文件协作还是得靠你自己把模块边界定死，AI只能当高级补全器用。

说实话我觉得这锅不全在prompt上，Cursor对那种跨文件、状态多的任务确实容易犯迷糊，它更擅长单文件里的局部重构。我试过把PDF提取拆成“读文件-清洗表格-输出Excel”三个独立步骤让它逐步写，每步跑通了再拼起来，成功率能高不少。另外你检查下生成的代码有没有偷偷import它自己脑补的库，那个真的防不胜防。

说实话你这个问题我踩过一模一样的坑，后来发现别让Cursor一次干太多活，把PDF解析、表格提取、结果保存拆成三个独立函数让它逐个写，每个函数给个明确输入输出样例，出错率直接降一半。另外它编造不存在的库函数太常见了，最好先在prompt里让它列出将要使用的所有库和版本，你快速扫一眼再让它开工。如果还是不稳，试试Claude的Artifacts或者直接上GitHub Copilot的聊天模式，处理这种多步骤任务我觉得比Cursor更听话。

说实话PDF表格提取这种活真别全指望AI，自己先写好解析逻辑再让它补细节会稳很多。

多文件任务它确实容易晕，建议拆成单函数逐个验证，比一次生成一大坨靠谱。

说实话我觉得这不是你prompt的问题，Cursor在生成那种跨文件、带状态管理的脚本时本身就容易崩，尤其是PDF这种它训练数据里不太多的场景。我最近改用Claude的Projects模式，把项目结构和依赖明确写进上下文里，反而稳很多。你可以试试让它先输出一个伪代码框架，确认逻辑后再让补全细节，别指望一步到位。另外变量未定义这种其实多跑几次让它自己debug也能修，但别太信任它编的库函数，查一下文档最靠谱。

说实话我跟你情况差不多，后来发现问题多半不在prompt，而是Cursor对那种跨文件、带状态流转的任务确实容易掉链子。我现在的做法是先让它把整个流程拆成函数骨架，再逐个函数填实现，每填一个就立刻跑一遍测试，这样能拦住大部分幻觉。另外你可以试试把依赖的库版本和关键API直接贴进prompt里，别让它自己猜，它编造不存在的函数基本就是因为没吃到准确的上下文。

说实话我觉得这不全是prompt的锅，Cursor在处理需要跨文件理解的任务时确实容易“一本正经地胡说八道”，尤其是它自己脑补出来的函数名，你查一下文档就会发现根本不存在。我自己的经验是别让它一口气写完整个脚本，先让它拆成几个小函数，每个函数单独验证输入输出，跑通了再拼起来，这样出错时定位会快很多。另外你也可以试试把报错信息直接贴回去让它自己修，有时候比重新生成靠谱。

说实话这情况我也遇到过，后来发现把任务拆成单文件小函数一个个试，比一股脑全塞给它稳多了。

说实话我觉得这锅不全在prompt上，Cursor对多文件、长流程的任务确实容易在中间状态上犯迷糊，尤其PDF解析这种涉及库选型的活儿。你可以试试把大任务拆成几个独立的小函数让它逐个写，每个函数给一个可运行的最小示例，跑通了再让它们组合，我这么干之后成功率明显高不少。另外它编造库函数这毛病，你可以先用requirements.txt锁死版本，或者干脆让它先输出import列表再写逻辑，能少踩好多坑。

试试让Cursor先画个伪代码框架再填实现，能少一半幻觉，我最近都这么干。

说实话我觉得问题可能不在prompt上，PDF表格提取这种活儿本身就很吃库的版本和底层依赖，Cursor经常是根据训练记忆瞎猜API。你可以试试把pypdf、pdfplumber或者camelot的官方文档片段直接贴给它，让它基于真实代码改，别让它凭空写。另外Composer模式对多文件状态跟踪确实弱，我一般只让它写单文件函数，跑通了再手动拼。

说实话我觉着问题不一定全在prompt上，Cursor对那种需要跨文件理解上下文的任务确实容易翻车，尤其是PDF处理这种涉及第三方库的，它经常自己脑补接口。我现在的做法是先把关键依赖的文档片段贴给它，或者直接指定用pdfplumber还是pymupdf，这样至少不会瞎编函数。另外建议你让它先输出一个单文件的最小原型，跑通了再让它扩展到多文件，比一上来就全量生成稳得多。

说实话真不全是prompt的问题，这种多文件协作+PDF解析本来就容易让模型在上下文里迷失，它自己脑补函数名太常见了。建议你试试把任务拆成“读取PDF→提取表格→清洗数据→输出”四个独立函数，让它一个个生成，每个函数单独跑通再拼起来，比一次性塞给它稳得多。另外可以限定它只用pdfplumber或camelot这种明确指定的库，别让它自由发挥，能少踩很多坑。

别太迷信提示词，这种多步处理任务它本来就容易断片，建议把PDF转表格拆成单步小函数让它一步步写。

多文件协作还是得靠传统编辑器，AI给个参考就行，别指望它一次成型。

这锅不全在prompt，复杂任务本来就得边跑边改，别指望一次生成就能用。

建议把大任务拆成小函数逐个验证，比堆上下文管用多了。

说实话这真不全是prompt的锅，Cursor在生成多文件协作或者带状态流转的代码时，上下文窗口根本记不住那么多隐含约束，变量作用域和缩进它经常凭“直觉”补全。我建议你把“提取表格”拆成“读取PDF→定位表格区域→用pdfplumber提取→清洗输出”四个独立函数，每个函数单独让它生成再手动拼装，成功率会高很多。另外跑之前先用pylint扫一遍，很多低级错误能提前暴露，比自己瞎猜强。