用AI编程工具写Python脚本，为啥生成的结果总是一半能用一半报错？

这问题我太有同感了，copilot对上下文的“记忆”其实很浅，你改需求它大概率只是局部替换，变量名那些就顾不上了。我的经验是每次改动都把完整函数代码重新贴给它，别让它依赖之前的对话。另外你真想迭代的话，不如让它先解释清楚现有逻辑再改，不然你越追它越跑偏。

这情况太典型了，Copilot对局部改动的上下文理解其实挺弱的，它更擅长按你最初那段完整需求生成整体代码。我后来习惯把改动需求单独写清楚，比如明确说“保留原函数结构，只把第X行统计方式换成median”，并且让它输出完整函数而不是片段，报错率能降不少。

另外变量名被改这个坑我也踩过，现在每次让它改动前都会在prompt里加一句“不要修改任何现有变量名和函数签名”，基本能杜绝。你如果做迭代，建议把每个版本的代码存个档，出问题了直接回滚再给新指令，别让它基于错误代码继续改，会越陷越深。

说到底这工具更像个“高级补全”，不是“结对程序员”，你得把每次修改当成小需求来提，别指望它能理解你整个项目的脉络。我自己用下来，复杂逻辑还是手写+让AI补测试用例最稳。

说实话你踩的坑我也全踩过，后来发现关键不是prompt写多细，而是每次改需求时得把改动的上下文完整贴给它，光说“把均值改中位数”它容易放飞自我。我现在都是让AI生成纯函数，数据清洗逻辑自己写主流程，它只负责填空那种小模块，迭代时直接替换函数体，变量名锁死，基本不乱跑。还有个别太依赖对话历史，开个新会话把当前代码全粘进去再提需求，比在旧对话里改来改去稳得多。

这情况太真实了，我基本每天都能遇到。Copilot和Cursor这类工具本质上是“概率性补全”，你改需求时它不会像人一样去理解上下文逻辑，而是重新从token分布里猜代码，变量名被改掉太正常了。我感觉问题不全在prompt，而是它们对“局部修改”的稳定性极差，尤其pandas这种链式操作，一旦中间某个变量名变了，后面全跟着崩。

我自己的经验是，别让它直接改现有函数，而是把新需求拆成独立小问题问，比如“用中位数填充某列，返回新DataFrame”，拿到结果后再自己手动粘贴进去，千万别让它自己整合。还有一招，每次生成后先跑个最小测试用例，报错就立刻回滚，别在错误代码基础上继续让它修，不然它会越修越离谱，甚至给你创造出不存在的列。

至于“迭代修改”，我反而觉得最靠谱的是让它写单行表达式或纯函数，不带外部状态的那种，稍微长一点的逻辑就自己把骨架搭好，只让它填关键几行。你越把它当“结对编程的实习生”而不是“全能代笔”，效率反而越高。另外，改需求时把旧代码整段删掉再重新生成，比让它改可能成功率更高，虽然听起来很蠢，但实测有效。

你试过给代码加类型注解或者用docstring把约束写死吗？我最近发现这么做能让它瞎编的概率低不少，像是给它的随机性加了道围栏。

改需求时最好把原函数贴回去让它只改那一行，不然它真会自由发挥。

我也遇到过这种情况，感觉不是prompt的问题，而是模型在多轮修改时会“失忆”，把之前定义的变量名和结构都搞混。我的经验是别在同一个对话里反复改需求，宁可新开一轮把完整上下文重新贴一遍，反而更稳。另外迭代时我会先把当前代码和报错一起丢给它，让它只改指定那几行，别让它自由发挥。说到底它更适合从零生成，修修补补还是得自己盯着点。

改需求时最好重开对话，别在原上下文里反复改，AI容易把旧变量名一起带偏。

这个我太有体会了，改需求的时候AI特别容易把之前能跑的代码带崩，变量名一改后面全乱套。我的做法是每次迭代前把当前能跑的版本存一下，让它只改指定那几行，别整个函数重写。另外中位数那个坑我也踩过，得明确告诉它用median()，不然它真会自作主张换逻辑。

这个问题我太有共鸣了，刚开始用Cursor的时候也踩过一模一样的坑。后来发现关键问题不在prompt写得多细，而是迭代修改的方式不对——你直接在原代码上让AI改，它会把上下文里所有变量名、逻辑都当成可重写的素材，改着改着就面目全非了。我现在的做法是每次改需求都新开一个对话，把原始数据结构和目标函数签名贴进去，只让它生成需要变的那一小段逻辑，而不是整段重写。另外Copilot和Cursor在这件事上表现确实不一样，Cursor的inline edit比chat模式稳很多，因为它能锁定你选中的代码范围。还有个小技巧是把你的DataFrame列名和dtype写成注释贴在文件顶部，AI每次读文件都会带上这些约束，乱改名的概率会低不少。说到底这类工具擅长的是从零生成和局部补全，不太适合当重构工具用，迭代还是得靠人自己控制改动边界。

迭代修改确实容易翻车，我一般让它重写整段而不是局部改，反而稳。

我也遇到过类似情况，感觉AI对“局部修改”这件事理解得特别差，你一改需求它就容易把上下文搞丢。后来我的做法是别在同一个对话里反复让它改，而是把新需求重新完整描述一遍，相当于重新生成。另外改完一定要自己盯一眼变量名和列名，别指望它记得住之前的结构。迭代场景下我现在更倾向让它写测试用例，我自己来改主逻辑，配合起来反而稳很多。

这问题太真实了，我也踩过同样的坑。关键是它没有上下文记忆，你改需求时它不会保留原来的变量结构，所以每次迭代都像在重新猜。我的做法是把函数拆小，一次只让它改一个点，并且把变量名和关键逻辑写死在prompt里。另外改完一定要自己跑一遍diff，别直接接受，不然它偷偷改掉别的地方你根本发现不了。

我一般不让AI直接改原来的代码，而是把新需求当独立函数重新生成，改完再自己手动合并进去。你那种“填充均值改中位数”的迭代，最容易触发它重写整段、顺手把变量名也换了。我的习惯是每次只让它输出一个函数，变量名和列名提前在prompt里固定死，它就不太敢乱动。另外生成完先跑一遍再改，别在没验证的代码上继续叠需求，不然报错会越滚越多。

我也遇到过同样的情况，感觉AI对“改需求”特别不敏感，尤其是涉及变量名和上下文的时候，它经常自己脑补一套新逻辑。后来我学乖了，每次只让它改一个点，改完马上跑测试，别攒着一起改。另外可以把原始代码和需求用注释标清楚，让它基于现有代码改，别重新生成。迭代场景下确实不如一次性脚本顺，但配合小步验证还是能用的。

迭代改需求时最好把变量名和上下文一起贴给它，不然它真会自作主张重命名。

这个问题我太有同感了，改需求的时候AI经常把上下文搞混，尤其是变量名它觉得“帮你优化”一下，结果全乱套。我后来学乖了，每次迭代前先把当前能跑的代码完整贴给它，明确说“只改这一处，其他别动”，命中率能高不少。另外像pandas这种，我干脆让它先写好函数签名和docstring，逻辑我自己填，反而更省心。

这个思路不错，收藏了。

我都是先让它生成整段逻辑再手动微调，迭代时把上下文清掉重写反而更稳。