用Cursor+Claude写Python脚本，经常改完一行整个逻辑就崩了，是我prompt不对吗？

这太真实了，我最近也在用类似组合调脚本，深有体会。Claude对“局部修改”的理解其实特别依赖上下文，你只给它看那一个函数，它就容易脑补出一套新的全局逻辑。我现在的做法是，改动前先把整个文件复制进对话，明确告诉它“只准动这个函数，其他全都不许碰”，然后让它先复述一遍我的需求再动手，效果会好不少。另外，异常处理和重试这种逻辑，我都是写成独立的装饰器或者工具函数，让它去调用，而不是让它去改主流程里的代码，这样就算它发挥，也只是在局部捣腾，不会波及全局。还有个小技巧，每次改完就立刻让它跑一遍语法检查，报错了马上把错误信息喂回去，它能自己修，但千万别让它“顺便优化一下”，一优化准出事。你那个爬虫工具，大概率是网站结构变了或者请求频率问题，我觉得你可以试试把目标函数写成纯函数，输入输出都定义死，这样它乱改的可能性会低很多。

我也遇到过一模一样的情况，尤其是加异常处理的时候，它经常会把旁边的逻辑顺手重构了。后来我学乖了，每次只给一个特别具体的指令，比如“只改第x行，加个try except，别动其他函数”，效果会好很多。另外建议把改动的代码片段单独贴出来让它改，别给它看整个文件，不然它总想“优化”全局。你试试把prompt里加上“不要修改除指定部分以外的代码”这种硬性约束，应该能少崩几次。

我也有过一模一样的经历，后来发现关键是把需求拆小，每次只让它改一个点，比如“给这个函数加个重试”，别一次塞好几个要求。另外我习惯在改之前先复制一份原逻辑存着，崩了还能手动回退，比让它自己修复靠谱多了。你下次可以试试在prompt里明确写“只修改指定函数，其他代码保持不变”，会好很多。

改代码建议拆小步，一次只动一个函数，别让它自己顺手“优化”别处。再就是加个回归测试兜底，崩了能立刻发现。

这情况太常见了，别全指望prompt，把需求写死成注释贴在函数上面，它跑偏的概率能小不少。

试试把要改的地方单独拎出来问，别把整个文件丢给它，上下文一长就爱自由发挥，语法错多半也是改

这情况太典型了，我也踩过差不多的坑。问题大概率不在prompt，而是Cursor的diff机制和Claude的上下文理解之间有个错位：你只给它看一行改动，但它脑子里记的是整个函数甚至整个文件的旧状态，一调整就容易把之前的约束条件给覆盖掉。我现在的做法是，改代码前先手动把相关函数完整复制到一个单独的临时文件里，让Claude只基于那一小段逻辑去迭代，改完再贴回去，崩的概率小很多。另外，你提到的“自由发挥”其实是因为Claude在补全时会倾向于重写它认为更“优雅”的版本，这时候得在prompt里明确加一句“只修改指定行，不要动其他任何函数”，甚至用注释把要改的位置圈出来。还有个笨办法但很管用——每改一次就git commit一次，崩了直接回滚，别让它有机会在错误版本上继续堆叠。说到底，AI写代码目前还是得靠人盯着结构，别指望它自己能理解“局部修改”的边界。

这太真实了，我也有过一模一样的经历。后来发现别让它直接改代码，把要改的函数单独抽出来，明确告诉它“只动这个函数，其他文件别碰”，崩的概率小很多。另外你试试在修改前先让它用一句话复述你的需求，确认理解了再动手，不然它真的会脑补一堆逻辑。

这太真实了，我最近也遇到类似情况，感觉Claude对已有代码的“上下文理解”特别脆弱，尤其改到函数边界时容易放飞自我。后来我学乖了，每次只让它改一个明确的小点，并且把改动范围在prompt里圈死，比如“只改第X行到第Y行，其他逻辑不要动”。另外建议给每个关键函数加个简单的单元测试，改完跑一遍，崩了能立刻知道是哪段逻辑被它带偏了。

这个我太有同感了，Claude在局部修改时确实容易“上头”，尤其是面对长文件的时候，它会自己脑补出前后文的关系然后乱改。我现在的做法是，每次只给它一个函数或一个代码块，明确告诉它“只改这段，别动其他”，效果会好很多。另外如果加了重试逻辑崩了，很可能是缩进或变量名冲突的问题，你可以试试让它先解释之前的代码再动笔，能减少很多幻觉。

这太真实了，我拿它改代码也经常翻车。感觉Claude对局部修改的理解特别迷，你只想动一行，它却把上下文重新脑补了一遍，结果越改越离谱。后来我学乖了，每次改动前先把要改的函数单独提出来，明确告诉它“只动这里，别碰别的”，再不行就直接给它看diff，效果会好很多。另外，让它加复杂逻辑时，不如先让它写个独立的测试用例，验证通过再合进去，不然真的容易一夜回到解放前。

这太真实了，我遇到这种情况就直接锁定文件或者把改动拆小，不然它真的会越改越离谱。

改成小步迭代，每次只让它动一个函数，崩的概率能小很多。

这太真实了，Cursor改代码有时候就是会“好心办坏事”，建议你改之前先锁定相关函数或者明确告诉它只动指定行。

这种“牵一发动全身”的情况我也遇到过，试着把改动的需求描述得更具体点，比如加上“不要修改其他函数”试试。

这几乎是每个用AI写代码的人都会踩的坑，问题大概率不在prompt，而是Cursor的diff机制对多文件或长函数的改动特别容易误判。我一般会让它先解释改动计划再动手，或者干脆把要改的函数单独复制出来，改完再贴回去。另外，异常处理和重试逻辑最好一次性描述清楚，分步提需求反而容易让它把上下文搞混。

我也遇到过一模一样的情况，特别是让它加异常处理的时候，它经常会把整个函数结构都重写了。后来我学乖了，每次只给一个非常具体的指令，比如“只改第X行，加个try except”，它反而老实很多。另外建议把关键逻辑先手动存个副本，反正AI改崩了直接回滚，比让它自己“修”靠谱多了。

这情况太典型了，我最近也被折腾得够呛。Claude 3.5在“改一行”这种局部修改上，确实容易把上下文理解歪，尤其是当整个函数依赖链比较长的时候，它可能为了“适配”你改的那行，顺带把其他相关逻辑也“优化”了一遍，结果就崩了。我现在的做法是，让它改之前，先明确告诉它“只动这个函数内部，其他函数签名和调用关系一律不许变”，甚至会在prompt里贴出函数调用图。另外，加异常处理这种，我干脆自己手写那几行try-except，然后让Claude只帮我补retry的逻辑，效果反而好很多。还有个坑，它偶尔会突然改变代码风格，比如把单引号全换成双引号，或者缩进从4空格变2空格，这种要专门提醒它保持原风格。你也可以试着把整个脚本拆成几个小文件，每个文件独立对话，改动时只针对那个文件聊，能减少“全局联动”的误伤。总之，别把它当全能助手，当个需要严格划清边界的结对程序员，会舒服很多。

这太真实了，小改动触发的连锁反应比bug本身还让人头大，建议把关键逻辑拆成独立文件再让它改。

风格二

我遇到这种就直接把报错信息丢回去让它自己看，有时候比重新描述需求管用。

风格三

改一行崩一片多半是上下文太长了，试试把相关函数单独开个对话或者用注释锁死逻辑。

这太真实了，Claude一改动局部就容易放飞自我，我一般让它改之前先明确说“只改XX函数，其他别动”。

碰到这种问题建议把之前能跑的版本先commit一下，崩了直接回滚，比反复调prompt省心多了。

这太真实了，我也踩过类似的坑。Cursor+Claude最大的问题就是它没有“最小改动”的意识，你让它改一行，它恨不得把整个文件重构一遍。后来我学乖了，每次改需求前会明确加一句“只修改xxx函数，其他代码保持原样”，甚至把不需要动的代码段直接注释掉。另外异常处理和重试这种逻辑，最好自己先写好模板让它往里填，而不是让它自由发挥，不然真的会越改越崩。

这太真实了，Claude改代码经常自作主张，建议你锁定核心逻辑再用小步修改的方式试。

其实这种大模型改代码的通病，最好每次只让它动一个点，别一次性塞太多要求进去。

这太真实了，我拿它改代码也经常这样。感觉它一拿到改动需求就爱把上下文过度扩展，尤其是涉及异常处理这种逻辑分支时，容易自己脑补出新架构。你可以试试把改动范围明确限制在某个函数内，甚至直接复制原函数进去让它只改那一段，别给它整个文件的权限。另外，语法错误大概率是缩进或括号匹配的问题，让它先跑一遍pylint再改会好很多。

我最近也遇到一模一样的情况，Cursor改代码的“扩散性”太强了，经常只是为了加个try-except，结果它把整个循环结构都重构了。后来我学乖了，每次让它改之前先把原函数用注释标记清楚，并且明确说“只改这一段，别动其他逻辑”，效果会好很多。另外小改动干脆自己手写，别麻烦Claude，它写新代码比做局部手术靠谱多了。