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

我最近也遇到这情况，polars和duckdb其实是好东西，但小脚本真没必要上，队友看到直接懵。你可以试试在提示词里写“只用标准库和pandas，别引入额外依赖”，然后每次生成完代码自己扫一眼import，有问题就让它改。另外建议直接把cursor的rules文件里加一条“优先使用常见库”，能省不少事。我上次一个脚本被它塞了三个库，后来全删了自己写，反而更快。

提示词里直接写“只用pandas和re，别引入其他库”就行，顺便让AI解释每步代码。

实话说polars和duckdb在数据处理上确实比pandas快不少，pyjanitor做数据清洗也挺好用，但这得看团队熟不熟，不然维护起来真能让人头大。你要是就想用pandas，提示词里直接写死“只用pandas和re，禁止引入其他库”，然后每次生成完扫一眼import部分，基本就能管住它。我自己试过在系统提示里加一句“优先使用标准库和常见第三方库”，效果还行，不过偶尔它还是会手痒。

说实话我太懂你这个感觉了，第一次用AI写代码的时候我也被它那股“炫技”劲儿整懵了。polars和duckdb其实都是好东西，尤其处理大CSV的时候性能确实比pandas强不少，但问题在于它们不是Python标准库，万一你们团队其他人没装或者不熟，那排查问题的时候真的想骂人。我自己后来学乖了，提示词里直接写死“只允许使用pandas和re，禁止引入其他第三方库”，效果立竿见影，它就不会再自作主张了。另外你还可以在后面加一句“如果必须用其他库，请先解释理由”，这样它至少会跟你商量一下，而不是闷头生成一堆依赖。至于维护坑队友这事，我觉得只要在代码里加个requirements.txt说明版本，其实问题不大，但前提是你自己得先搞清楚每个库是干嘛的，别稀里糊涂就签收了。我上次让它写个ETL，它给我整了个modin，我查了半天才发现是pandas的分布式替代品，最后果断让它改回去了。

在提示词里明确限定只用pandas和re，AI就不会乱发挥了，亲测有效。

说实话我也踩过这个坑，polars和duckdb性能确实比pandas强不少，但团队里其他人不熟就麻烦了。我现在的做法是在提示词里直接写死“只允许使用pandas和re，不要引入其他第三方库”，效果立竿见影。另外你可以试试在项目里加个requirements.txt，把允许的依赖列清楚，AI会参考项目上下文收敛很多。维护问题确实得提前想，不然队友review代码时看到陌生库心态会崩。

直接跟它说“只用pandas和re，别整花活”，不满意就多试几次，这玩意儿得调教。

新库倒不坑，但队友大概率不认识，维护确实头疼。

说实话polars和duckdb还真不是坑，处理大数据集的时候比pandas快不少，但你这场景就是个简单清洗，确实没必要上这些。想让AI老实点，可以在提示词里明确写“只允许使用pandas和re，不要引入其他第三方库”，或者加一句“保持依赖最小化”试试。另外建议跑通后把生成代码里没用的库手动删掉，顺便读一遍逻辑，这样队友也不会被吓到。

直接装，polars性能真香，但队友不熟就坑了，建议提示词里加“只用pandas和re”。

polars和duckdb其实挺靠谱的，尤其数据量上来之后性能比pandas强不少，但确实没必要为了个小脚本引入它们。你可以在提示词里明确写“只用pandas和re，不要引入其他第三方库”，或者直接加上“保持依赖最小化”的约束，它一般会听话。另外建议跑通后把没用到的import手动删掉，省得队友看到一堆陌生依赖心慌。

直接跟它说“只用pandas和re，别引入其他库”，再不行就在项目里锁死依赖，AI跑偏前你能拦住。

说实话这几个库都挺靠谱的，polars是pandas的现代替代品，duckdb处理CSV也确实快，但纯数据清洗真没必要上全套，维护时队友看到不认识的依赖确实会头大。想让Cursor别自由发挥，你可以在提示词里明确写“仅使用标准库和pandas完成，不要引入额外依赖”，或者直接说“保持最小依赖，所有操作基于现有环境”。另外如果它非要用新库，你可以补一句“如果必须用第三方库，请先说明理由并给出替代方案”，这样它就会收敛很多。

直接跟它说“只用pandas和re，别整花活”，再不行就在项目里锁死requirements，它就不会乱来了。

说实话polars和duckdb现在在数据处理圈子里挺火的，性能确实比pandas快不少，但如果你只是清洗个几万行的CSV，真没必要上这些，徒增维护成本。我自己的做法是在提示词里直接写“仅使用标准库和pandas，禁止引入其他第三方库”，再把项目依赖文件锁死，AI基本就不会乱来了。另外建议你跑通后自己过一遍代码，把不认识的库删掉换回pandas逻辑，毕竟队友看到一堆陌生依赖确实容易头大。

其实polars和duckdb都挺靠谱的，处理大CSV比pandas快不少，但你要是只做简单清洗确实没必要引入。我试过在提示词里加一句“只用标准库和pandas”，或者干脆把环境里装了哪些库直接贴给它，它就不敢乱来了。另外建议你跑通后把依赖锁进requirements.txt，队友那边至少能复现，不会太坑。

polars和duckdb其实都是性能很能打的库，尤其处理大CSV时比pandas快不少，但如果你项目就几万行数据，确实没必要引入这些额外依赖。想让它老实点，可以在提示词里直接写“只用pandas和re，不要引入其他第三方库”，或者把环境里的已安装包列表贴给它。维护角度讲，新库有学习成本，但duckdb这类文档挺全，坑队友倒不至于，关键看团队是否愿意接受新工具。

老实说polars和duckdb还真不是野路子，处理大数据量时比pandas快不少，但小项目里确实有点杀鸡用牛刀。你担心维护问题很对，队友要是没见过这些库，排查起来确实头疼。想让Cursor收敛点，可以在提示词里明确写“只用pandas和re完成，禁止引入其他第三方库”，或者直接说“保持依赖最小化”。我试过在项目里放个requirements.txt，然后让它基于这个文件写代码，效果会好很多。

这问题太真实了，我刚开始用Cursor的时候也踩过类似的坑。说句公道话，它给你生成polars和duckdb其实不算瞎搞，这俩在数据清洗领域确实比pandas快不少，尤其是处理大文件时能省好几倍时间，但问题是你项目里其他同事未必熟这些，维护成本一下就上去了。如果你就想走保守路线，提示词里最好明确写“只允许使用标准库和pandas，禁止引入任何第三方新依赖”，然后每次它生成完你还得检查一遍import，发现有陌生库就让它重写，多搞几次它就记住了。另外我自己的习惯是，把项目需求写得更死板一些，比如直接说“用pandas的read_csv和apply函数处理”，它就不太敢越界。至于那些库本身靠不靠谱，老实说polars和duckdb都挺成熟的，但单为一个小脚本引入它们确实没必要，万一哪天环境装不上或者API变了，你哭都来不及。还有个小技巧，你可以在Cursor的规则文件里全局加一条“优先使用常见库”，这样它默认就不会乱发挥了。说到底，AI只是工具，得你给它划好边界，不然它天天给你整花活。

直接让AI“只用pandas和re，别整花活”，它就会乖乖听话，亲测有效。

这问题我太有同感了，第一次用AI写数据处理脚本也被polars和duckdb砸了一脸。其实这些库本身都不错，polars处理大CSV比pandas快好几倍，duckdb甚至能直接跑SQL，但它们对新手来说就像突然被塞了一本外文教材。维护角度确实得谨慎，团队里如果没人熟悉这些库，后面改需求就是灾难现场，尤其pyjanitor这种小众到文档都不全的，出了问题连Stack Overflow都搜不到答案。我现在的做法是，在提示词里直接写死“仅使用pandas和re，禁止引入其他第三方库”，或者干脆在项目里建个requirements.txt白名单，AI生成后我手动删掉多余依赖。另外你也可以试试在Cursor的设置里把“自动安装依赖”关掉，这样它生成代码时会更保守。说白了，工具是死的，人是活的，别让AI的“炫技”绑架了你的项目复杂度。