用Cursor写Python后端，AI总给我“幻觉”代码，怎么调教它更靠谱？

这问题太真实了，我上周也被它编了个根本不存在的SQLAlchemy方法，查了半天文档才确认是AI在瞎掰。我的经验是别让它直接写数据库操作，先把表结构和查询逻辑用伪代码写死在prompt里，它自由发挥的空间就小很多。另外temperature参数在Cursor里其实有，但藏得比较深，你可以在设置里找找AI相关选项，调到0.2左右会老实不少。接口文档建议先写个简略版，至少把输入输出字段定义清楚，不然它真的会给你整出花来。

这题我熟，之前也被AI编过不存在的库函数坑惨了。我的办法是让它先输出伪代码或接口签名，确认逻辑对了再让它补全，能省不少事。另外你可以在prompt里直接贴一小段你项目里真实存在的代码作为风格参考，它模仿起来会老实很多。温度参数那个估计悬，Cursor没开放这选项，但你可以多试几次生成，选个最靠谱的版本。

这问题太真实了，我拿Cursor写Go也经常被它一本正经地编库函数。我的土办法是把项目里现成的类似代码片段直接粘prompt里当范例，再明确告诉它“只准用这些依赖”，幻觉能少一半。温度参数那个我试过，但总觉得不如给它画个边界管用，比如让它先列实现步骤再写码。你试试把接口文档拆成小段喂进去，别一次给太多，它反而容易飘。

写清楚函数签名和用哪个库的哪个版本，它就不瞎编了，温度调低点也有用。

幻觉这事儿真不能全怪Cursor，它本质就是个概率续写器，你给的信息越模糊，它越容易往训练集里最常见的模式上靠。ORM方法捏造这种，多半是因为它见过太多SQLAlchemy和Tortoise混着写的代码，模型把不同库的API缝合了。我自己的经验是，项目里先建一个schema或者models文件，把真实的表结构和已有的方法签名写进去，然后在composer里用@引用这个文件，它生成时就会优先对齐你已有的代码，幻觉能少一大半。温度参数Cursor没直接暴露，但你可以通过让它“先只输出伪代码再确认”来降创意，相当于手动降温。至于要不要先写接口文档，我觉得比文档更管用的是先写类型注解和函数签名，让AI填空而不是让它从零构思。另外记得开项目级的.cursorrules，把“禁止使用不存在的库方法，不确定就留TODO”写进去，亲测有效。

先让它读你项目里的现有代码，照着已有写法生成，比空口描述管用多了。

我也被Cursor坑过，它特别爱编不存在的库方法。后来我学乖了，写之前先扔给它一份自己项目的目录结构和依赖版本，再让它写，幻觉能少一半。温度参数在Cursor里改不了，但你可以要求它“只使用我提供的库和方法，不许自己发明”。接口文档最好先写，让它按docstring生成，不然它真敢乱搭异步框架。

我最近也在用Cursor搞FastAPI，踩的坑跟你几乎一模一样。它确实容易凭空捏造ORM方法，尤其是SQLAlchemy 2.0和1.x语法混着来的时候，简直是灾难现场。我的经验是，别指望一次prompt就能让它写对，得把任务拆碎，比如先让它只写model定义，确认没问题再写查询逻辑，最后单独写路由。上下文给太多反而容易让它抓错重点，一般把相关的文件用@引用进去就够了，不用把整个项目都塞给它。温度参数Cursor好像没直接暴露出来，但你可以通过让它“只使用当前文件里已导入的库和方法”来约束它，这招挺管用。另外强烈建议先写接口文档或者类型注解，再让它填充实现，这样它自由发挥的空间会小很多。还有个小技巧，遇到它瞎编方法时，直接把它编的那个方法名贴回去问“这个在SQLAlchemy里有吗”，它往往会自己纠正过来。