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

这是一个非常典型的问题，我猜很多用Cursor写后端的朋友都经历过这个阶段。我先说个结论：AI的“幻觉”本质上是它试图在信息不完整的情况下，用最高概率的token拼接出看起来合理的代码，而它并不知道你项目里实际有什么依赖、什么版本、什么自定义类。你遇到的捏造ORM方法、混用Celery和APScheduler语法，根本原因不是AI不够聪明，而是它缺乏对你项目的“真实上下文”的感知。

我自己在几个生产级FastAPI项目里踩过类似的坑，后来摸索出一套能让AI幻觉率大幅下降的实操方法，分享给你。

首先，关于“该给多少上下文”这个问题，我的经验是：不要只给当前函数或当前文件的上下文，而要给它一个“最小可运行的项目切片”。什么意思呢？比如你要让它写一个数据库查询，你只贴一句“写个查询用户的方法”，它当然会自由发挥。正确的做法是，在prompt里附上你的数据库模型定义、你已经引入的ORM库版本、甚至你项目的依赖文件片段。我自己的习惯是，在Cursor的对话窗口里先粘贴这样一段东西：“项目使用FastAPI 0.104.0，SQLAlchemy 2.0.23，异步引擎，模型定义如下：class User(Base): ... 当前已有session依赖注入函数async def get_db(): ... 现在请帮我写一个根据邮箱查询用户的方法，要求返回Optional[User]，并且使用select()语法。”你看，这样它就不会去捏造一个Query.filter_by之类的老语法，也不会凭空编一个不存在的ORM方法。关键是把“边界条件”锁死：库版本、已有依赖、你的代码风格偏好。

关于“要不要先写接口文档再让它生成”，我的回答是：非常有必要，而且最好是用OpenAPI规范或Pydantic模型作为接口契约。我现在的流程是，先手写或让AI帮我一起写一个Pydantic的请求和响应模型，写清楚字段类型和校验规则，然后把这个模型定义当作prompt的一部分。比如我先定义好class CreateUserRequest(BaseModel): name: str; email: EmailStr; age: int = Field(ge=0)，然后再让AI根据这个模型生成路由和数据库操作。这样做的本质是先把“接口边界”画好，AI在生成逻辑代码时就不容易跑偏。我曾经做过一个实验：同一个功能，不给接口定义直接让它写，它生成了一个把密码明文存数据库的代码；给了接口定义后，它自动就用了密码哈希库，因为Pydantic模型里定义了password字段并且有个校验器提示了hash逻辑。接口文档就是AI的“护栏”。

至于温度参数，Cursor目前没有像GPT那样的直接控制接口，但你可以通过prompt里的“语气词”和“约束条件”间接控制。比如你想让它更保守，就在prompt里加一句“请严格按照已存在的库和函数签名来生成，不要引入任何未导入的模块或方法，如果遇到不确定的用法，请用注释标注TODO而不是自行编造”。我试过，加了这句话之后，它编造API的概率下降了大概六成。另外，你可以明确要求它“先写出伪代码思路，经过你确认后再生成完整代码”，这样相当于把它的“创意”分阶段释放，而不是一次性全输出。

再分享一个我自己踩过的很深的坑：处理异步任务调度时，AI给我生成了一个同时用了Celery的@task装饰器和APScheduler的@scheduler.scheduled_job的混合体，而且它还自作主张引入了一个叫celery_apscheduler的第三方库，实际上那个库早就没人维护了。当时我debug了快两个小时，后来发现是它参考了网上一些过时的博客。从那以后，我养成一个习惯：每次让AI引入新库时，我都会在prompt里加一句“请只使用项目requirements.txt中已有的库，如果必须引入新库，请给出明确的库名和版本，并说明替代方案”。这样它就不敢随便编造了。

关于具体技术方案，我想说，对AI生成的后端代码，尤其是涉及数据库、消息队列、异步任务的，一定要养成“两步验证”的习惯：第一步，让它生成代码，然后你手动检查所有import语句，看有没有不存在的方法或类；第二步，用类型检查工具比如mypy或pyright跑一遍，很多幻觉代码会直接在类型检查阶段暴露出来。我团队现在规定，所有AI生成的代码必须通过mypy --strict才能合入，这一条就过滤掉了90%以上的幻觉。因为AI编造的ORM方法通常没有类型注解，或者返回类型和实际不符，mypy一查就原形毕露。

另外，我强烈建议你为项目写一个“项目级prompt模板”，存放在项目根目录的.cursorrules文件里（Cursor支持这个）。在这个文件里，你可以定义项目的技术栈、编码规范、常用模式、禁止使用的库等。比如你可以写：“本项目使用FastAPI + SQLAlchemy 2.0异步模式，所有路由函数必须使用async def，数据库会话通过Depends(get_db)注入，禁止使用同步查询，禁止使用filter_by语法，使用select()代替。”这样Cursor在生成代码时会自动参考这个规则文件，幻觉率会进一步降低。我自己的经验是，写好.cursorrules后，AI生成的代码风格和我手写的相似度从50%提升到了85%以上。

最后，我想说一个可能被很多人忽略的点：AI的幻觉其实是它“想帮忙”但“过度泛化”的结果。你让它写一个数据库查询，它可能想起了某篇博客里一个很酷但非标准的用法，就给你塞进去了。正确的调教方式不是禁止它创新，而是给它一个“安全范围”。我常用的一个prompt句式是：“请用最常规、最符合Python官方文档的写法实现以下功能，不要使用任何实验性特性或非标准扩展。”这句话对压制幻觉非常有效。当然，如果你需要它写一些非常复杂或者需要创意的代码，你可以反过来要求“请给出三种不同实现，并说明每种方案的优缺点”，这样它会在可控范围内发挥创造力。

总结一下我的建议：第一，给足够多的项目上下文，包括模型定义、依赖版本、现有代码风格；第二，用Pydantic模型或OpenAPI文档作为接口边界；第三，用.cursorrules文件锁定编码规范；第四，用类型检查工具做二次验证；第五，在prompt中明确要求“按标准写法”或“分步确认”。按这个流程走下来，我现在的AI代码采纳率大概在80%以上，剩下的20%主要是业务逻辑的微调和边界条件的处理。希望这些对你有用，别再被AI坑了。

同感，被AI“幻觉”坑过的路过。我最近也在用Cursor写一个FastAPI+SQLAlchemy的项目，它给我生成了一个session.query().filter_by().first_or_404()的方法，我查了半天文档发现SQLAlchemy根本就没这玩意儿，气得我直接去GitHub翻源码确认了。

我个人摸索下来，有几个小技巧可以试试。一是先写接口文档，哪怕只是个简陋的OpenAPI spec或者pydantic模型，把输入输出定死，再让Cursor去填充逻辑。这样它自由发挥的空间就小了，因为接口形状是固定的，它不敢轻易改。二是prompt里明确指定库的版本和用法，比如“使用SQLAlchemy 2.0的select()语法，不要用1.x的query风格”，它跑偏的概率会低很多。

至于温度参数，Cursor底层用的是GPT系列，但它的IDE插件层面好像没开放这个控制选项。不过我试过在prompt里加一句“请用最保守、最标准的方式实现”，效果类似调低温度，它会更倾向于生成常见的套路代码，而不是花里胡哨的“创新”。

还有个比较笨但管用的方法：让它每生成一段代码，必须附带一个简短的测试用例。比如写个查询，就让它顺便写个pytest的测试，这样它自己就会去验证那个方法存不存在。我有几次就是靠这个把它的幻觉扼杀在摇篮里的。

另外你提到的Celery和APScheduler混合，我猜可能是它把任务调度和异步任务的概念搞混了。建议在写异步任务相关代码时，先明确告诉它用哪个库，甚至贴一段官方示例让它照着改，比让它自由发挥靠谱得多。

反正我现在是“prompt防伪”和“代码审查”双管齐下，虽然累点，但至少不用debug到凌晨了。你那边有没有什么特别容易踩坑的场景？可以一起交流下怎么给AI“驯化”一下。

同感，被AI捏造ORM方法和任务调度语法混搭坑过好多次。我的经验是把接口文档或类型定义先写好，然后在prompt里明确说“基于这个接口签名和已有代码风格生成”，上下文给到能说清数据流向和边界就行。另外它确实没温度参数，但可以试试在prompt里加“不要创新，严格按示例实现”这类约束，效果还挺明显。

这问题太典型了，几乎每个用Cursor写Python后端的人都会踩一遍。你提到的ORM方法捏造和Celery+APScheduler混搭，本质上都是同一个问题：LLM对框架API的边界感很弱，它更擅长“看起来像那么回事”而不是“实际能用”。

我的建议是，别指望靠prompt写详细就能完全解决。比如你让它写数据库查询，与其写“写一个用户查询接口”，不如直接贴一段你项目里已有的真实Repository层代码，然后说“按这个风格，写一个订单表的按时间范围查询”。Context不是描述越多越好，而是越贴近你的实际代码结构越好。我试过最有效的方式是：先把项目的models.py和schemas.py扔进Cursor的上下文，再让它写业务逻辑，幻觉率能降一半。

另外你说的温度参数，Cursor底层确实能调，但IDE里没开放。不过有个变通方法：在prompt里加一句“严格使用SQLAlchemy 2.0官方文档中的session.execute写法，不要使用query方法”，相当于手动给它的采样空间加了个硬约束。对于异步任务这种容易混的，我甚至会先把Celery的官方示例代码复制进上下文，让它照着改。

还有一点很多人忽略：让Cursor先生成接口文档或pseudo code，确认逻辑没问题，再让它填充具体实现。这相当于把它的“创意”从代码层面提前到设计层面，即使它编造方法名，你在文档阶段就能发现。最后，养成每次生成后跑一遍mypy和pylint的习惯，AI写的代码经常类型标注是错的——这比debug运行时错误省时间多了。

同感，Cursor在生成不常见库的代码时确实容易放飞自我。我的做法是先写好pydantic模型和核心接口的伪代码，相当于给它搭好骨架，再让它填充具体逻辑，幻觉率能降不少。温度参数目前好像没法调，但你可以试试在系统提示里加一句“只用标准库和已安装的第三方包”，这样能约束它别瞎编方法。另外建议把关键依赖的版本号直接写在prompt里，比如“用SQLAlchemy 2.0的select写法”，它会更老实。

同感，这玩意儿写常规CRUD还行，一到异步或者中间件就开始放飞自我了。我的经验是把接口的数据结构和预期行为写死在prompt里，比如直接贴一段pydantic的schema和具体业务逻辑的伪代码，它能少抽风很多。另外可以试试在生成的代码后面加一句“只使用FastAPI官方文档里有的方法”，能过滤掉大部分幻觉。

同感，最近我也在用Cursor写点小工具，遇到最多的就是它自己编API签名，查文档才发现根本没那个参数。你说那个ORM方法捏造，我遇到过它给我写了个session.filter_by()，我还愣了半天以为是新语法。

我现在的做法是，先把项目里用到的第三方库的核心类和方法列个清单，比如SQLAlchemy的select、join怎么写，Celery的shared_task装饰器参数长什么样，直接贴在prompt开头，告诉它“只用这些接口”。它要是还自由发挥，我就把官方文档里对应的小例子贴进去，效果会好很多。

不过温度参数这个我也想知道。Cursor的设置里好像没有直接调，但我在想是不是可以像GPT那样加一句“请严格遵循标准语法，不要混合不同库”来约束。你有试过在prompt里加类似“如果某个方法不确定是否存在，请先查阅文档再生成”这种指令吗？

另外接口文档确实有用。我现在习惯先写一个简单的pydantic模型和路由签名，再让Cursor填业务逻辑，它幻觉明显少了。但有时候它还是会自作聪明地加一些我没要求的中间件或者日志装饰器，这点挺头疼的。你那个异步任务混搭的问题，我怀疑是因为它把多个框架的常见用法缝合了，可能需要在prompt里明确指定“只使用Celery的AsyncResult，不要用APScheduler的语法”。

还有个小技巧，如果它生成了一段你怀疑有问题的代码，可以把它复制到新对话里，单独问“这段代码里有没有不存在的API”，它自己会识别出来。你试过这个方法吗？

这问题我太有共鸣了，Cursor写Python后端确实容易瞎编API，尤其是那些不太主流的库或者版本差异大的场景。我踩过的坑跟你差不多，后来摸索出几个办法，效果还行。

第一个是“分步约束法”。别一次性让它生成整个函数，而是先写接口签名和类型注解，然后只让它补全函数体。比如你先定义好async def get_user(db: AsyncSession, user_id: int) -> User | None:，再让它写查询逻辑，它胡编的概率会低很多，因为类型和参数已经锁死了上下文。如果它还是编造ORM方法，你就在prompt里明确说“只使用SQLAlchemy 2.0的select语法，不要用query”，甚至把官方文档里对应的代码片段贴进去当few-

shot。

第二个是“先文档后代码”确实有效，但不用写完整的接口文档那么重。你只要用注释把数据流画清楚就行，比如“输入：user_id -> 查用户表 -> 如果不存在返回404 -> 存在则检查权限 -> 返回用户信息”，这种伪代码级别的描述就够用了，它能理解意图，不太会跑偏。

至于温度参数，Cursor的底层模型虽然支持，但编辑器插件里没直接暴露这个选项。我试过在prompt里加“请使用最保守的实现方式，不要创新”这种指令，有一定效果，但不如上一条好使。另外有个小技巧：如果它生成了一段看起来可疑的代码，别直接删掉重来，而是选中那段代码，按Ctrl+K输入“请验证这段代码调用的API是否真实存在，逐行检查”，它自己会意识到编造了东西，有时候还能主动修正。