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

说实话，这锅不全在prompt上，Cursor在生成多文件协作或者长流程代码时，本身对上下文的管理就很弱，它容易“自信地”忘记前面定义过的变量。我试过最有效的办法是让它先输出伪代码或数据结构，确认逻辑对了再让它补全，比直接要完整脚本稳得多。另外，你提到的编造库函数，大概率是它训练数据里没见过那个库，建议你先自己把import和关键调用写死，只让它填中间逻辑。要是还不行，可以换个思路用Claude或Gemini试那个任务，不同模型对长文档的“记忆”差别挺明显，我的经验是别死磕一个工具。

试试把报错信息直接甩给它，让它自己修，比反复描述需求管用多了。

说实话你这情况我太熟了，之前用Cursor写个数据清洗脚本也这样，代码表面看着贼完整，一跑就现原形。我觉得问题不一定全在prompt上，Composer处理多文件协作的时候，上下文窗口一长它就容易“忘事”，尤其是跨文件引用变量和函数定义的时候，幻觉概率直接翻倍。你可以试试把任务拆成单文件、单功能的粒度，让它先各自生成再手动粘合，别指望它一口气搞定整个流程。另外它编造不存在的库函数这个，大概率是训练数据里见过类似的API但记混了，这种时候你直接把报错信息丢回去让它自己修，往往比重新描述需求更管用。至于替代工具，如果你能接受命令行，Claude的代码能力在长上下文场景下明显更稳，就是得自己搭环境。最后想说，别太迷信prompt技巧，这类工具本质是概率生成，复杂业务逻辑还是得自己理清框架再让它填肉。

说实话我觉得这锅不全在prompt上，PDF提取表格这种任务牵扯到版面解析和格式兼容，本来就是LLM最容易编造细节的场景，我试过用别的工具也经常在边界情况翻车。倒是建议你把需求拆成“先转成文本再提取”这种明确小步骤，并且把输入输出的样例直接贴给它，比描述一堆抽象规则管用。另外如果代码逻辑老出错，不如让它先写伪代码框架，你再手动填关键函数，这样至少能控制住变量作用域的问题。真要稳的话，可以试试结合正则或者pandas的现成模板，把AI当辅助而不是主力。

说实话你这情况我也踩过，后来发现问题不在prompt详细程度，而是Cursor对跨文件状态跟踪就是弱，尤其涉及PDF这种带二进制流的库，它经常拿训练集里的假API硬凑。我现在都是让它先写单文件纯函数，跑通后再手动拼装，或者干脆用Claude写核心解析逻辑，再丢回Cursor改样式。

拆太细反而容易丢上下文，我一般先让它跑通最小demo再逐步加功能，比一次性喂大需求稳多了。