用Cursor写Python项目，AI老给我生成一堆没见过的库，该不该直接装？

直接装吧，polars和duckdb都是成熟项目，性能比pandas强不少，坑队友倒不至于。

说实话我太懂你这个感受了，polars和duckdb现在确实挺火，但直接往项目里塞确实让人心里没底。我自己的经验是，AI有时候会默认你追求“最新最好”，但它根本不管你这个脚本是不是要丢给同事跑，或者部署在哪个老环境里。你怕坑队友这个担心完全在点子上，这种依赖拉满的代码，等过了三个月自己回来看都得懵。想让Cursor老实点，我建议你在提示词里直接写死“只用标准库和pandas”，最好再加一句“不要引入额外第三方依赖”，它一般就会收敛了。另外，如果它已经生成了那些库，你可以在文件开头注释里声明“本项目仅允许使用pandas和re”，然后让它重构，大部分时候它会乖乖改。其实换个角度想，如果项目只是自己跑着玩，polars性能确实比pandas强不少，但维护成本也是真高，你自己权衡下时间成本吧。

直接装没问题，polars和duckdb现在挺稳的，性能还比pandas好。提示词里加句“只用pandas和re，别引入其他库”就行。

说实话你这情况我也遇到过，polars和duckdb其实都是性能很强的库，尤其处理大CSV比pandas快好几倍，但问题是它们API风格差异挺大，队友接手确实容易懵。我现在的做法是直接跟Cursor说“只用标准库加pandas，不要引入其他第三方依赖”，然后把它生成的代码里多余import手动删掉，再让它重写一遍，这样基本能控制住。另外你可以在项目里建个requirements.txt或者pyproject.toml，把允许的依赖写死，AI有时候会默认你装了所有包，有这个文件它会收敛不少。维护角度讲，除非是单机一次性脚本，否则真不建议用一堆冷门库，pandas生态成熟，坑少，社区答案也多，换polars出问题排查成本高。你可以试试在提示词里加“保持代码简单，兼容Python 3.9+，只使用常见库”，然后每次生成后先问它“这个库是干嘛的，有没有替代方案”，逼它解释，慢慢它就学乖了。

说实话polars和duckdb还真不是野路子库，数据量大的时候性能比pandas强不少，但你这场景杀鸡用牛刀了。我一般会在提示词里直接写“只用pandas和标准库实现”，或者加一句“不要引入额外依赖”，效果立竿见影。另外真担心维护的话，可以把Cursor生成的代码过一遍，把不认识的库查一下文档，确认没乱用再提交，毕竟AI的“自由发挥”有时候也是它觉得性能更好。

说实话polars和duckdb还真不是坑，处理大csv比pandas快不少，但你要是团队协作还是得考虑大家熟不熟，别整成只有你能跑的代码。我一般会在提示词里加一句“只允许使用标准库和pandas”，它基本就老实了，偶尔还会蹦出别的，我就直接删掉再让它重写。

AI生成的新库未必不靠谱，但队友维护时大概率会骂娘，建议提示词里直接写死“仅用pandas和re”。

说实话polars和duckdb真不是坑，处理大数据集比pandas快好几倍，但小项目确实没必要。想让它老实点，提示词里直接写“只用pandas和re，不要引入其他依赖”就行，或者把“prefer standard library”加进去。另外建议看看生成的代码里有没有用到那些库的独特功能，如果只是简单过滤和合并，手动改回pandas也没多费事。

说实话我最近也踩过类似的坑，polars和duckdb其实性能确实比pandas强，但如果你队友不熟这些库，维护起来确实想骂人。我的办法是在提示词里直接写“只允许使用pandas和re处理，不要引入其他第三方库”，然后加上“保持代码风格与现有项目一致”。另外建议你装个pip-audit或者让Cursor解释每个库的用途，确实有用再留，不然就手动删掉重跑一遍。

直接告诉它“只用pandas和re，别引入其他库”，它一般就会老实了。

要是队友接手看到一堆生僻依赖，估计真想骂人，还是保守点好。

说实话polars和duckdb现在在数据处理圈子里挺火的，性能确实比pandas强不少，但你要是只做简单清洗，真没必要上这些，徒增队友学习成本。我一般会在提示词里直接写“只用标准库加pandas，不要引入额外依赖”，然后如果它又乱来，就补一句“请解释每个库的必要性”，它就会收敛很多。另外你可以在项目里加个requirements.txt锁定版本，这样就算AI抽风，队友装环境也不至于踩坑。

我之前也踩过这个坑，后来发现直接跟它说“只用标准库和pandas，别引入额外依赖”就能老实很多。polars那些确实性能好，但小脚本真没必要，维护起来队友看到一堆陌生库头都大。另外建议你让它把每一步处理逻辑注释清楚，这样就算换库也能自己改回来。

试试在prompt里加一句“只用标准库或pandas”，另外polars其实性能真不错，但团队项目确实得统一技术栈。

polars和duckdb确实靠谱但没必要，直接在提示词里写死“只用pandas和re处理”就行。

polars和duckdb其实不算小众，这两年数据处理圈还挺火的，性能确实比pandas强不少，尤其是大数据量场景。但问题在于你队友不一定熟悉，代码review时人家还得现学，维护成本确实上去了。我自己的经验是，AI生成代码时你要是没明确限制，它就会默认你追求最优解，而不是最稳妥方案。想让它老实点，提示词里直接写死“只用pandas和re，不要引入其他库”，再加一句“如果必须用其他库，请先解释原因”，它一般就会收敛了。另外，建议你让它把每步操作都注释清楚，这样就算它用了新库，你也能看懂逻辑，后续替换也方便。其实最省事的办法是，先让它写一版pandas的，跑通了你再手动优化，别一上来就接受它的“高级方案”。

说实话polars和duckdb都挺靠谱的，尤其在处理大文件时性能比pandas强不少，但如果你项目里其他人不熟，确实容易变成维护负担。我一般会在提示词里直接写“只用pandas和re，不要引入其他库”，然后如果它还是乱来，就补一句“保持依赖最小化”。其实AI有时候是觉得换个库能优化性能，但忽略了团队协作的现实，这个只能靠提示词约束了。

老实说polars和duckdb性能是真的猛，处理大CSV比pandas快好几倍，但如果你只是小脚本，确实没必要引入这些依赖。想让Cursor别乱来，就在提示词里写清楚“仅使用标准库和pandas”，再补一句“不要引入额外依赖”基本就能拦住它。不过我的经验是，偶尔让它用点新库反而能学点东西，只要它把代码逻辑注释清楚就行。维护坑队友这事，关键还是看你有没有时间把环境锁好，requirements.txt里固定版本号，队友也不至于太懵。

直接在提示词里写死“只用pandas和re，别引入其他库”就行，我试过很管用。新库确实好用但队友维护起来真会骂娘。

我最近也在折腾Cursor，遇到一模一样的情况。它好像特别偏爱那些“新潮”库，polars确实快，但duckdb这种重型武器用在几千行的清洗脚本上，属实有点大炮打蚊子。你担心的维护问题太真实了，尤其团队里其他人没接触过这些，到时候排查bug真的想骂人。

我现在的做法是，在提示词里直接写“仅使用Python标准库和pandas”，然后开头先强调“保持依赖最少化”，如果它再乱来，就补一句“解释为什么不用pandas实现，否则重写”。另外，把项目环境锁死很有用，比如在requirements.txt里只放你认可的库，AI会参考你已有的依赖来生成代码，这招比光靠提示词管用。

其实换个角度想，它生成这些库也是一种“信息投喂”，让你知道有更好的工具存在。但生产环境的代码不是技术演示，稳定和熟悉度优先。我一般会先让它跑通，再手动把不认识的库替换成pandas写法，顺便看看它到底用那些库解决了什么pandas做不到的问题——有时候确实能学到点东西。

对了，你检查过它生成的代码里polars和pandas混用的情况吗？我遇到过它前半段用pandas读数据，后半段突然转成polars，接口都变了，这种隐藏的坑比多几个依赖更烦人。

在提示词里直接写死“仅允许使用pandas和re”，它会听话很多，不然AI总想秀技术。