用AI写代码总翻车，是我提示词不对还是工具选错了？

试试先别让它一次写完，拆成小函数一步步验证，表头那些固定数据直接写死在prompt里当常量。

这种活AI真不擅长，表头语义它根本理解不了，不如直接写正则或pandas固定逻辑。

试试把示例输出格式也写死进提示词，或者用Aider让它自己跑测试反馈，比Cursor稳点。

我也遇到过类似情况，数据处理这块AI确实容易想当然，尤其列名和路径这种上下文强依赖的东西。我后来改了个思路，不让它直接写完整脚本，而是先让它生成一个只读表头和前几行的代码，我跑完把真实输出贴回去再让它接着写。这样它就不会瞎猜了，改起来也快很多。Cursor里可以试试用.cursorrules把项目约定写死，或者干脆用pandas的read_excel加参数那几行手动写，剩下的交给它补。

这种表格处理任务确实容易翻车，不是你的问题。AI对列名和路径特别爱自作主张，你贴了表头它也可能忽略，因为训练数据里这类脚本太多了，它倾向于套模板。我的经验是把任务拆碎，先让它只写读文件的几行，确认列名对了再逐步加逻辑，别指望一次生成完整脚本。另外可以试试用pandas的列索引代替列名，反而更稳。

数据处理这块AI确实容易瞎猜，我一般自己写好表头和路径再让它填逻辑，省心不少。

这其实不是提示词的问题，也不是工具选错的问题，而是数据处理这类任务本身就对AI不太友好。你想想，Excel表格处理看着简单，但里面全是隐性知识，比如列名的语义、空值怎么处理、日期格式是哪种，这些你自己心里门儿清，但AI完全靠猜。你贴表头给它看，它确实看到了，但它没法像人一样去理解每列数据的业务含义，所以猜错列名太正常了。Cursor和Copilot本质上都是代码补全工具，它们擅长的是写函数、补逻辑、生成样板代码，而不是帮你做数据探索和字段映射。我自己也踩过这个坑，后来发现更靠谱的用法是让AI写处理框架，比如读文件、遍历行、写输出这些，但字段映射和业务逻辑自己手动补。还有一个思路是用pandas的describe先跑一遍数据，把统计结果喂给AI，它猜列名的准确率会高不少。至于硬编码路径，这是AI的通病，它默认给你一个能跑的示例，你得在提示里明确说用参数或配置文件。所以别怀疑自己被忽悠了，AI编程确实有用，但得用在它擅长的环节，数据处理这种脏活累活还是人机配合更稳。

数据处理确实容易翻车，我一般先让它搭框架，具体列名和路径自己填，反而更快。

数据处理确实容易翻车，我一般先手动写好表头和路径再让AI填逻辑，省心不少。

数据处理确实容易翻车，AI对列名和路径这类“约定”特别爱自作主张。我的经验是别让它直接写完整脚本，先让它输出一个只读表头和打印列名的片段，确认对了再往下加逻辑。另外Cursor里可以把报错直接贴回去让它改，比重新描述需求省事。这场景不是AI不擅长，是它缺上下文还特爱脑补，你得把“猜”的空间堵死。

我也用Cursor处理过Excel，感觉这类任务确实容易翻车，尤其是列名和路径这种细节。我的经验是别让它一次写完整脚本，先让它只读表头并打印出来，确认对了再写处理逻辑。另外可以在.cursorrules里把“禁止硬编码路径”写死，比在对话里强调管用。数据处理不是AI不擅长，是它对上下文里的隐含约束太容易自作主张。