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

直接装吧，这些库其实挺稳的，pandas反而容易成为性能瓶颈。

看到你这个问题我太有同感了，刚开始用Cursor那会儿我也被它塞过一堆骚操作库，什么“polars”确实快但生态小，万一团队里别人没用过就尴尬了。我的经验是，如果你明确想用pandas，可以在提示词里加一句“只使用Python标准库和pandas，不要引入其他第三方依赖”，这样它通常会收敛很多。不过说真的，“duckdb”处理大CSV其实挺香的，偶尔试试新库也不是坏事，前提是你要先在项目文档里注明这些依赖的用途，免得队友挖坑。另外，“pyjanitor”本质上是pandas的清洁插件，但完全可以用pandas自带的方法替代，没必要为了省两行代码多一个依赖。我自己的做法是：先让AI自由发挥看效果，如果代码跑通且性能不错，我会手动把不熟悉的库替换成pandas原生实现，顺便学习一下新思路。维护性上，如果你项目是单人用或者临时脚本，大胆装就行了，但如果是团队协作，最好在代码里写清楚每个库的必要性，或者干脆锁住版本。

说实话我也被Cursor坑过类似的，它特别喜欢给你整活推新库，polars和duckdb我后来查了下确实性能比pandas强，但小脚本真没必要上这么重的依赖。你担心维护问题是对的，团队里如果有人没装这些库，光环境配置就能吵半天，更别说代码可读性了。我自己试下来，提示词里明确写“只使用标准库和pandas”会好很多，最好再加一句“禁止引入第三方库”，不然它还是会自作聪明。另外你可以把每个步骤拆开问，比如先让它写读取CSV的代码，再单独写清洗逻辑，这样它就不容易跑偏。不过话说回来，pyjanitor这种库做数据清洗确实方便，但得看团队是否愿意接受新工具。如果你项目以后要给别人维护，还是老老实实pandas最省心，最多加个numpy。

说实话我最近也遇到同样的问题，Cursor太喜欢炫技了。polars和duckdb其实都是性能很强的库，但小项目真没必要硬上。我试过在提示词里明确写“仅使用pandas和re，不要引入第三方库”，基本能管住它。另外建议你主动把依赖写进requirements.txt里，这样它就不会自由发挥了。

说实话我也有过类似的经历，刚开始用Cursor的时候确实被它推荐的库惊到了。不过后来我发现，它生成那些库其实是因为它觉得那些工具在特定场景下比pandas更高效，比如polars处理大数据集确实快很多，duckdb做分析查询也很方便。但如果你只是写个简单的数据清洗脚本，完全没必要引入这么多依赖，后续维护确实容易让队友懵圈。建议你在提示词里直接说“只使用Python标准库和pandas，不要引入其他第三方库”，或者把需求拆得更细一点，比如“用pandas的read_csv读取文件，用fillna处理缺失值”，这样它就不会自由发挥了。另外，如果你担心依赖管理，可以试试在项目里建个requirements.txt，让AI只写pandas和re，它基本会听话的。

说实话看到你这情况我特别理解，我刚开始用Cursor也遇到过类似问题，它特别喜欢推荐些冷门库，可能觉得这样显得自己很懂行。不过你说这几个其实不算坑，polars在处理大数据集时性能比pandas强不少，duckdb做数据聚合查询也很香，但问题是你这只是个简单的CSV清洗脚本，确实没必要上这么重的依赖。

我现在的做法是，写提示词时直接加上限制条件，比如“只使用Python标准库和pandas完成需求，不要引入其他第三方依赖”，或者更具体点“请使用pandas的read_csv和正则表达式实现，不推荐任何额外库”。如果它还是乱生成，你就在对话里强调一次“请严格遵守前面的限制”，它会调整的。

至于坑队友这个事，如果项目是团队用的，最好还是统一技术栈，突然冒出个polars可能别人还得学。但如果是自己玩的玩具项目，试试新库倒也没啥，说不定会发现新大陆。不过建议你在README里注明用了哪些库以及为什么选它们，免得以后回头看自己都懵。

说实话我也遇到过类似的情况，Cursor有时候确实会“炫技”式地引入一些冷门库，像polars和duckdb其实本身性能不错，但小项目里突然堆这么多依赖确实容易让队友懵圈。我个人的习惯是，如果只是数据清洗这种常规任务，直接在提示词里写清楚“只用pandas和内置模块，不要额外安装任何第三方库”，然后加上“代码要可读性强，适合团队维护”，这样它基本就不会跑偏了。另外，你也可以先跑一遍代码，如果发现它引了不认识的库，立刻在对话里补一句“把xx替换成pandas实现”，它会当场重构，效果还挺好的。至于那些库靠不靠谱，像duckdb在分析场景下确实很快，但如果你团队没人用过，维护成本就上来了，我一般会在项目初期就定好技术栈，直接在提示词里写“遵循团队现有库清单”。还有一个偷懒的办法，就是先用Cursor生成核心逻辑，自己手动把依赖替换成熟悉的库，这样既利用了AI的效率，又不会埋雷。

我最近也在试Cursor，它确实爱推一些冷门但性能更好的库，像polars处理大数据集比pandas快不少，但项目小的话真没必要加进来。想让AI老实点，我会在提示词里加一句“只用标准库和pandas，不要引入外部依赖”，另外把项目根目录的requirements文件提前写好也是个办法。至于duckdb和pyjanitor，前者做分析型查询挺强，后者是数据清洗的扩展包，维护上只要队友熟悉生态倒不算大坑，但如果团队都习惯pandas，还是别图新鲜了。

直接装吧，这些库挺靠谱的，不过怕坑队友可以在代码开头加个注释说明下用途。

说实话polars和duckdb在数据处理这块确实比pandas快不少，尤其文件大的时候优势很明显，不过项目里突然塞一堆新库确实会让队友头疼。我一般会在提示词里加一句“只使用标准库和pandas”，或者先手动把依赖限制写在requirements里再让它写代码。另外你可以试试让Cursor先生成pandas版本，跑通后再手动优化，这样至少不会上来就整一堆陌生的东西。

哈哈，同感，我刚用Cursor那会儿也被这毛病整过，它特别喜欢炫技给你塞一堆新库。不过说实话，像polars和duckdb在处理大一点的CSV时确实比pandas快不少，尤其是内存占用这块，pyjanitor做数据清洗也挺顺手的，如果你这个脚本只是自己用或者一次性任务，装了就装了，问题不大。但如果是团队项目，那确实得小心，队友看到duckdb这种冷门依赖大概率会一脸懵，维护起来也麻烦。我的做法是在提示词里直接加一句“只使用Python标准库和pandas，不要引入额外依赖”，如果它还不听话，就补一句“每一步都要解释为什么需要这个库”，这样它就不敢瞎发挥了。另外建议你在prompt里写清楚数据量级，比如“处理1万行以下的小文件”，AI一般就会老实选pandas了。

说实话我也有过类似的经历，Cursor有时候确实爱推荐一些新潮库，但像polars和duckdb其实性能比pandas好不少，尤其处理大文件时优势明显。不过如果只是简单数据清洗，直接装确实会让依赖变臃肿，队友接手可能懵逼。你可以试试在提示词里明确说“只用标准库和pandas，不要引入其他第三方包”，或者把禁止的库名直接列出来。我自己的习惯是先让AI按我的思路写一遍，再问它“有没有更轻量的替代方案”，这样既不会偏离方向，又能学到新东西。

这情况我也遇到过，Cursor确实喜欢用些新库来炫技。polars和duckdb其实性能不错，但小项目真没必要加进来，徒增依赖。我的做法是在prompt开头直接写“只允许使用pandas和re，不要引入其他第三方库”，效果还行。另外建议你跑通后手动删掉多余库的引用，毕竟队友看到pyjanitor这种冷门库估计得懵。

说实话我也有同感，Cursor有时候确实爱炫技，给出一堆小众但性能不错的库。polars和duckdb其实挺靠谱的，处理大数据比pandas快不少，但如果你只是小项目、队友不熟，强行上确实容易埋坑。我一般会在提示词里加一句“只使用标准库和pandas完成”，或者直接说“不要引入额外依赖”，效果会好很多。另外也可以先在需求里把技术栈限定死，比如明确写“基于pandas+re实现”，它就老实了。

直接告诉他“只用pandas和标准库”，或者把依赖写进requirements.txt里锁死，AI就不会乱发挥了。

说实话我也有过类似的经历，polars在处理超大CSV时确实比pandas快不少，但小项目硬塞一堆库反而增加维护成本。建议你直接在提示词里写“仅使用pandas和re完成，不要引入额外依赖”，这样能限制它自由发挥。不过话说回来，pyjanitor这种库其实挺适合数据清洗的，你可以先小范围试试水，真觉得好用再跟队友商量。

说实话我也有过类似的困惑，后来发现直接加一句“只用标准库加pandas”之类的约束，它能收敛很多。不过话说回来，polars和duckdb其实性能不错，小项目试试也没关系，真怕坑队友就在requirements里注明版本和用途。你可以在系统提示词里写“优先用常见库，避免引入不必要的新依赖”，这样它就不敢随便放飞了。

说实话我刚开始用Cursor也遇到这问题，感觉AI特别喜欢炫技，动不动就给你塞一堆新库。不过你提到的这几个倒真不是乱七八糟的东西，polars和duckdb在数据圈这两年挺火的，处理大文件比pandas快不少，pyjanitor也是数据清洗的实用工具。但问题在于，如果你的项目就是小脚本，团队其他人不一定熟悉这些，维护成本确实会高——我之前有个脚本扔给同事，他第一反应就是“这啥玩意”，还得现学。

想让它老老实实用pandas其实不难，提示词里直接加限定就行，比如“只使用pandas和标准库，不要引入任何第三方库”，或者更狠一点“仅用pandas完成所有操作，禁止import其他包”。我试过几次，明确说“保持依赖最小化”或者“用最常用的库”，AI就会收敛很多。另外你可以在Cursor的设置里把“允许自动安装包”关掉，这样它就不会擅自pip install了。

其实我觉得偶尔接触新库也不是坏事，像polars处理500万行以上的CSV确实快，但如果你只是为了快速交付或者团队统一，那就得强硬点。我现在的做法是：个人项目随便它发挥，公司项目一律加死限制，甚至会在提示词里写“假设对方只有pandas基础”。你试过在描述需求时直接强调“兼容性优先”吗？效果挺明显的。

说实话我也遇到过这情况，polars和duckdb处理大数据确实比pandas快，但小项目真没必要硬上。我一般是开头直接写“strictly use pandas only”或者“keep dependencies minimal”，然后描述需求时主动提一句“不要引入额外库”，这样它就不会放飞自我了。另外如果你担心维护，可以在提示词里加一句“优先用标准库和pandas实现”，效果挺明显的。

说实话我刚开始用AI写代码也遇到过一模一样的情况，后来发现这其实是提示词颗粒度的问题。你想让它只用pandas，就得在需求描述里直接锁死技术栈，比如“请仅使用pandas和re完成，不要引入其他第三方库”，最好再补一句“如果必须用新库，先解释理由”。另外你说的那几个库其实不算冷门，polars和duckdb在数据处理圈子里口碑挺好的，性能确实比pandas强，但前提是你和队友都熟悉，否则维护成本确实高。我个人建议小脚本就老老实实pandas，别给未来埋雷，除非你愿意花时间把新库的坑都踩一遍。还有个土办法，就是装个虚拟环境单独跑AI生成的代码，依赖全丢进去，测试通过再合并，这样既不怕它乱装东西，也不耽误你体验新工具。