用Cursor写Python后端，AI总把依赖写错，是我prompt不对吗？

说实话我跟你遇到的情况一模一样，FastAPI项目里它给我写过Pydantic v1的orm_mode，我人都麻了。后来我试了下在项目根目录放一个AGENTS.md文件，把关键依赖版本和易错点写进去，比在prompt里反复强调管用得多，Cursor好像会优先读这个文件。但你也别指望它能完全记住，特别是跨会话的时候，它还是会偶尔抽风。我的经验是，让它写业务逻辑和接口骨架挺省事，但涉及到依赖调用、版本兼容这种细节，就当它是个新手同事，写完必须自己过一遍。其实你可以在prompt里加一句“请严格参考项目内现有代码的import风格和库版本”，会比单纯说“用新版”有效。但说到底，AI对生态的更新有滞后，尤其Pydantic这种大版本breaking change，它训练数据里新旧混着，出错的概率天然就高。我现在基本是把它写的依赖代码当成初稿，自己用pip index versions查一遍再改，虽然麻烦点，但比反复调教prompt省心。

说实话，这问题我太有感触了，最近用Cursor写Go也是这个德行，版本依赖这块它就像个健忘症患者。我觉得真不是prompt写得不细的问题，模型对“当前最新稳定版”这种时间敏感信息的训练数据天然滞后，你就算在系统提示里写死版本号，它该幻觉还是幻觉，顶多那次对话里能记住。我现在基本放弃让AI管依赖了，自己手动改比跟它掰扯效率高多了，尤其是Pydantic v2这种破坏性变更，它脑子里全是老教程的影子。不过有个小技巧你可以试试，把pyproject.toml里关键包的版本号直接复制粘贴到当前对话的上下文里，然后明确说“基于这个版本写代码”，比注释管用，但也就管用几个回合。说到底，AI适合帮你写业务逻辑和结构，依赖版本这种精细活，还是人肉盯最靠谱，别指望它替你省这一步。

这问题太真实了，我最近也被坑过好几回。感觉Cursor对语法和API的“记忆”明显滞后，尤其Pydantic v2刚出那阵子，它写出来的模型配置简直没法看。后来我干脆把核心依赖的版本号直接写进系统提示词里，比如“pydantic==2.7.0，用model_config写法”，效果会好一丢丢。但说实话，依赖这东西还是得自己盯，AI能帮你搭框架，细节真不能全信，不然跑起来全是报错，排查更费劲。

说实话这问题我太有共鸣了，Cursor在依赖版本这块儿确实是个重灾区，尤其是FastAPI这种生态更新快的，它训练数据里旧代码的权重太高了，Pydantic v1和v2的语法差异它经常搞混。我试过在pyproject.toml里写死版本号，也试过在对话里反复强调“用当前最新稳定版”，但它有时候还是给我塞个过时写法，感觉它更像是在“模仿”常见代码模式，而不是真的去理解你项目里的约束条件。后来我干脆换个思路，不再指望它写依赖相关的代码，而是让它专注业务逻辑部分，依赖我自己手写，或者用uv这类工具自动解析，这样反而省心很多。你那个系统提示里强制指定版本号的办法我也试过，效果有一点，但别指望完全解决，它偶尔还是会“失忆”。我的建议是，AI生成的依赖代码就当个参考草稿，别直接信，自己跑一遍测试比啥都强，毕竟版本兼容这种坑，它踩了不心疼，咱踩了得加班。

别指望AI记版本，直接把它当结对编程的实习生，依赖写完自己过一遍最稳。

我都是让Cursor只写逻辑，依赖全手动加，这样反而省心。

我试过类似的情况，后来发现直接让Cursor读pyproject.toml里的依赖版本再写代码会好一点，但也就好一点。它训练数据里老版本代码太多了，尤其Pydantic v1和v2的语法差异，它经常混着来。我现在的做法是让AI只写业务逻辑，涉及依赖调用的地方自己改，或者干脆用官方文档当上下文喂给它。说到底版本这东西它真不擅长，别太指望prompt能根治。

我也踩过这个坑，后来试过在系统提示里写“必须使用pydantic v2语法”或者“httpx 0.28的接口”，效果时好时坏，感觉它有时候会忽略。现在比较靠谱的办法是，把报错信息直接丢给它让它修，比让它从头写强多了。另外建议把依赖锁定文件也贴进上下文，至少能减少一些低级错误。

说实话这真不是你prompt的问题，Cursor对依赖版本的理解就是很弱，它训练数据里老版本代码太多，喂pyproject也没用。我现在基本把它当高级补全用，涉及第三方库的调用一律自己查文档，让它写业务逻辑和算法部分就挺稳的。你要是真想省事，可以在系统提示里明确写“所有依赖以pyproject.toml为准，不要自行推荐版本”，能稍微改善一点，但别指望根治。最后建议还是开个虚拟环境跑一遍测试，AI写的依赖真的不能直接信。

这问题太真实了，我最近也被折磨过。其实不是prompt不够细，是模型训练数据里老版本代码占比太高，你就算写“用最新版”它也可能凭惯性输出。我现在基本把pyproject.toml里的版本号直接复制进对话开头，然后让它先读一遍再动手，效果会好一些。但说实话，依赖这东西还是自己核对一遍最稳，AI写的代码逻辑能省时间，第三方库版本就别指望它了。

版本这事真别指望AI，我都是让它写逻辑，依赖自己锁，pyproject里钉死版本号才靠谱。

AI对版本敏感度确实差，你把关键依赖写成约束放系统提示里能好点，但最终还是得人肉核对。

我都是让AI写逻辑，依赖自己加，版本坑太多了，它顾不过来的。

手动改吧，AI对版本细节真不行，我试过把版本号写进prompt照样翻车。

版本细节真别指望AI，我都是让它写逻辑自己锁依赖，不然光修pydantic v2的报错就够喝一壶。

说实话这问题我碰过太多次了，后来干脆把pyproject.toml里的关键依赖版本直接写进系统提示里，比如“必须用pydantic>=2.0的Field语法”，效果会好一点，但偶尔还是会抽风。依赖版本这事儿AI确实拿捏不准，尤其是它训练数据里新旧混杂，所以我现在基本把AI当个快速原型工具，写完依赖和模型定义自己会再过一遍，别太指望它一次到位。

这问题我太有同感了，之前用Cursor写个SQLAlchemy的异步会话，它给我整出个已经废弃的create_async_engine用法，跑起来直接报错。我觉得核心问题不在prompt，而是这工具对版本演进的跟踪确实有滞后性，它训练数据里可能旧版代码占比太高了，你就算在系统提示里写“用Pydantic v2”，它有时候还是会把validator写成v1的装饰器风格。我试过把pyproject.toml的内容直接贴进对话上下文，效果稍微好一点，但它还是会有自己的“惯性思维”，尤其是遇到那些API变动大的库，比如httpx的Client调用方式，它总爱写老一套。现在我的做法是把它当个半自动工具，让它出框架和业务逻辑，所有第三方库的导入和调用方式我基本都自己核对官方文档，或者干脆用IDE的自动补全来确认。你要是追求效率，可以在项目里配一个.mdc文件或者单独写个技术栈说明，每次对话开头强制让它先读一遍，但说实话，真省不了多少事，最后还得靠人眼扫一遍依赖相关的代码。反正别指望它把版本细节全搞对，这玩意儿目前就是个高级拼写检查器，不是真正的专家系统。

说实话我试过在系统提示里写死版本号，效果也就那样，最后还是自己改依赖最靠谱。

这问题我太有同感了，之前用Cursor写个异步爬虫，它给我生成httpx.AsyncClient的调用方式还是老版本的，跑起来直接报错。我觉得真不全是prompt的锅，这种代码生成模型对版本演进的感知天生就滞后，你就算在pyproject里写死版本号，它该幻觉还是幻觉，顶多概率低一点。我自己试下来最靠谱的办法是，让AI先读一遍项目里的依赖文件，再让它基于现有环境写代码，或者在生成后马上用类型检查工具过一遍，别指望它一次写对。至于Pydantic v2那个坑，我干脆直接在系统提示里贴了一段当前版本的核心语法示例，效果比干巴巴写“用v2”强得多。但说真的，依赖这块还是别太信任AI，我最后基本都是把生成代码里的import和模型定义手动核对一遍，反正它写的框架逻辑能用，细节就当它是个实习生，得检查作业。

说实话这问题我也踩过坑，pydantic v2刚出那阵子cursor写出来的全是v1的Optional和validator，后来我直接在项目根目录放了个AGENTS.md，把关键依赖版本和常见坑写进去，效果好不少。不过依赖这玩意儿确实不能全指望它，我一般让它写逻辑，装库和版本核对都自己来，毕竟它训练数据里老版本占比太大了。你试试在系统提示里明确写“使用pydantic v2语法，httpx>=0.28”，它会收敛很多，但最后跑测试还得自己盯。

这问题我太有同感了，cursor对版本的理解基本停留在训练数据里最热门的那个时代。我在项目里试过在pyproject.toml写死版本，也把fastapi的依赖注释写得很清楚，它照样给你生成pydantic v1的model_config写法，最后还得靠mypy和运行报错来兜底。个人感觉不如把关键依赖的版本和语法习惯直接写进rules文件，或者干脆让它生成代码后自己统一过一遍import和类型标注，AI写框架逻辑还行，依赖这种牵一发动全身的细节真别指望它。

说实话，我试过把版本号直接放进prompt里，比如明确写“用httpx 0.27的接口”，结果它偶尔还是会混进旧参数，感觉它内部对版本差异的感知很模糊。我现在基本策略是让它写主体逻辑，所有涉及第三方库调用的地方都自己核对官方文档，尤其像pydantic这种v1和v2差别巨大的，纯靠AI太容易翻车。你要是找到让它稳定识别版本的方法，记得回来分享下。

我也踩过这个坑，后来发现光在pyproject.toml写版本没用，cursor读上下文的能力没那么细。我的土办法是开一个单独的文件，把当前项目用到的核心库版本和对应API注意事项都列出来，然后每次对话开头就@这个文件，相当于给它一个“

这事儿我太有同感了，Cursor对依赖版本的理解基本靠训练数据里的“主流印象”，pyproject.toml它大概率只是扫一眼，不会真去解析约束。我现在的做法是干脆放弃让它写依赖导入，只让它写业务逻辑，最后自己统一跑一遍mypy和ruff，错误率能降不少。你可以在对话里直接甩一句“所有第三方库必须用当前项目锁定的版本”，但说实话，还是手动改最稳。

手动锁版本吧，AI对依赖更新跟不上很正常，prompt写得再细也架不住它记混。

别指望它记版本，直接让Cursor参考你pyproject里的约束，写错就改，比调prompt省事。

说实话这问题我太有共鸣了，cursor写业务逻辑还行，一到依赖版本就翻车，尤其是pydantic v1/v2和httpx这种API变化大的库，它训练数据里新旧版本混着来，光靠pyproject.toml它根本不会主动去parse。我试过在系统提示里加“严格使用pydantic v2语法”这种话，有一定效果但也不是100%靠谱，偶尔还是会犯病。后来我干脆把它当成一个“高级补全器”，写完依赖相关的代码必须自己过一遍官方文档，特别是迁移指南，这比调prompt省心多了。其实你想想，模型对版本号的“理解”本质上是概率分布，它没法真正验证某个版本存在不存在，所以这种细粒度问题它天生就弱。我现在的做法是让它先写逻辑，然后我自己统一修依赖，或者干脆让cursor自己用“读取文件”的方式先看看pyproject再动手，但效果也就那样。反正别全信，尤其别让它自动装包，手动锁版本才是真靠谱。