用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里有吗”，它往往会自己纠正过来。

这问题太真实了，我上个月用Cursor写Django REST接口也踩过一模一样的坑，它给我编了个serializer里根本不存在的source参数，排查了半天才发现是AI纯虚构的。我的经验是prompt里最好直接贴上你项目里已有的相关代码片段，比如你用的SQLAlchemy版本、已有的model定义，让它照猫画虎，别只丢一句“写个查询”。上下文给多少其实取决于你的项目结构，我一般会把涉及的那两三个文件的关键部分贴进去，大概两三百行以内它就能守住边界了。至于温度参数，Cursor本身没给你调，但你可以通过说“只用标准库”“不要引入新依赖”这类约束来压它的发散性。写接口文档再生成这个思路我觉得靠谱，我后来就是先用OpenAPI把路由和schema定死，再让AI往里填实现，幻觉少了一大半。另外它混Celery和APScheduler那种，你就明确说“用celery，broker是redis”，把技术栈锁死，它就不太敢乱串了。最关键的是别让它一次生成太大块，拆成小函数逐个生成，出错了也好定位。

有没有更详细的教程推荐？

先手写接口文档和类型注解，再让Cursor照着填，幻觉能少一大半。温度别调太低，不然它连正常补全都怂。

我一般会先把接口文档或者数据模型丢给它，哪怕只是注释写清楚字段和返回值，幻觉能少一大半。温度参数Cursor里好像没直接给，但你可以用.cursorrules文件把项目规范、常用库版本写进去，效果挺明显的。另外别让它一口气写太长逻辑，拆成小函数逐个生成，错了也好定位。Celery和APScheduler混用那种，直接在prompt里点名只用哪个库就行。

我一般会先把接口文档或者类型定义喂给它，哪怕只是注释写清楚入参出参，幻觉能少一大半。温度参数在Cursor里好像调不了，但可以在项目根目录放个.cursorrules文件，把技术栈和禁用库写进去，挺管用的。另外别指望它一次写对，让它先输出伪代码或者分步解释，确认思路对了再生成实现。Celery和APScheduler混用那种，直接在prompt里点名“只用Celery，别引入其他调度库”会好很多。

Cursor有时候确实会瞎编，我一般会先把接口定义和数据库模型贴给它，上下文给足就不太容易跑偏。温度参数在Cursor里好像调不了，但你可以换个思路，让它先列实现步骤你确认了再写代码。另外建议把常用的库版本写进.cursorrules里，能少踩很多坑。

我也是Cursor重度用户，这问题太真实了。我的经验是别指望它凭空写对库的API，你先把要用的ORM方法签名或者官方示例贴进上下文里，它基本就不会乱编了。温度参数在Cursor里其实可以调，但作用有限，关键还是给足约束。另外建议先让它只写接口和类型定义，你确认没问题再让它填实现，这样能省不少debug时间。

我一般会先让它把接口和模型定义写出来，确认没问题了再让它填具体实现，这样能少很多幻觉。温度参数Cursor里其实没直接给，但可以在prompt里加“严格基于fastapi和sqlalchemy官方API，不确定就说不确定”。另外建议开个小文件专门放依赖和版本，让它读那个当上下文，比它瞎猜强多了。

写得挺好，建议补充一些性能数据。

我也被Cursor坑过，捏造ORM方法这事太常见了。我的经验是先把接口文档或者函数签名写出来，哪怕就几行注释，让它照着填肉，幻觉能少一大半。温度参数Cursor里好像没直接暴露，但你可以用.cursorrules把项目用的库和版本固定下来，效果挺明显。另外生成完别急着信，先让它解释一遍调用了哪些方法，对不上的当场就能发现。