用Prompt调教GPT写Python脚本，为什么总是改着改着就崩了？

这问题我太有同感了，GPT的增量修改本质上就是一次全新的生成，它根本没能力去“理解”你之前代码里的设计意图，所以一旦你提出新需求，它就会基于当前对话的上下文重新脑补整个逻辑。我后来发现，与其在旧对话里反复打补丁，不如每次修改都开一个新会话，把“当前完整代码+具体改动点+禁止触碰的范围”一次性塞进去，尤其要明确告诉它“只允许修改某某函数，其他代码原样输出”。另外还有个坑，你越是强调“顺便处理一下”，它就越容易放飞自我，因为模糊指令等于给它自由发挥的空间，你得把重试机制写成“在fetch函数里加while循环，最多试3次，每次sleep 2秒，其他任何地方不要动”这种绝对命令式的话术。还有个土办法，就是让它先输出一份“改动差异说明”，等它列出计划后你再批准执行，虽然麻烦点但能拦住大部分乱改行为。至于全量重写，如果项目不大我建议干脆每次都用完整代码重新生成，因为GPT对长上下文的注意力会衰减，改到后面它连自己最初的变量命名都记不住了。我现在基本就是靠“新会话+全量代码+极窄的修改指令”来稳住它，虽然token消耗翻倍，但至少不会越改越崩。

增量修改确实容易越改越乱，我一般直接让它输出完整新代码再对比，省心很多。

这问题我太有同感了，GPT在增量修改时确实容易“好心办坏事”，因为它对上下文的权重分配是全局的，不像咱们脑子里有个清晰的“只动这部分”的边界感。我现在基本放弃在长对话里让它持续改，每次新需求就把相关函数单独贴出来，配上“只改这段，其他代码一字不动”的强约束，成功率能高不少。另外提个思路，你可以在prompt里明确告诉它“如果改动会触及未提及的函数，请先询问再动手”，算是给它上个保险栓。

这问题太典型了，GPT对增量修改的理解其实特别“局部”，你让它加重试，它可能觉得顺手把函数签名改了更“优雅”，结果就崩了。我的经验是每轮迭代都明确圈定范围，比如直接说“只改fetch_data函数内部，其他任何地方都别动”，甚至把不相关的代码原样贴一遍，效果会好很多。另外，一旦发现它开始动无关逻辑，我一般就立刻让它git diff看看改了什么，不对就马上回滚重来，别跟它纠结。全量重写虽然费token，但如果你对原有代码结构不自信，反而比反复打补丁省心。

这问题我太有同感了，GPT在增量修改上的“自作主张”简直是玄学，我甚至怀疑它对“只改A不动B”的理解跟咱们不一样。你那个正则被替换的情况我也遇到过，后来我分析它可能是为了“整体一致性”才顺手改的，但问题是它对项目上下文的理解根本撑不起这种重构。我个人试下来最有效的办法是给每个函数写清楚职责边界，在prompt里直接说“这是核心解析模块，除非我明确要求否则禁止改动”，同时把函数名和行号范围都标出来。另外，别依赖历史对话，每次新需求都把它当成一次全新任务来交代，把“当前代码全貌”和“期望变更点”分开写，这样它反而更老实。还有个小技巧，如果它改崩了，别让它自己修，直接贴出报错和它改动的那一小段代码，让它只针对这个片段给修复方案，不然它又会开始“全局优化”。说到底，这种大模型更适合当“生成器”而不是“维护者”，真要迭代，干脆每次让它输出完整的新版代码，自己用diff工具对比着合，可能比跟它博弈省心多了。

增量修改确实容易跑偏，我一般直接让它输出完整代码再自己diff，反而省事。

这问题太真实了，增量改代码就是拆东墙补西墙，我后来都直接让它重写整个函数，反而省心。

我一般是让它先输出完整脚本，再明确指出“只改XX函数，其他代码原样保留”，效果会好一些。增量修改确实容易翻车，因为它总想顺便优化别的地方。实在不行就每次让它重写全量，虽然费token但省心。

增删改这种活儿千万别让它自由发挥，我一般是把要改的函数单独贴出来，明确说只重写这一段，其他部分原样返回。另外每轮改完让它输出完整文件而不是diff，不然它很容易漏掉上下文。还有个土办法，重要逻辑自己先注释好边界，它就不太敢乱动别的了。

我也遇到过这种情况，增量修改真的很容易翻车。我的经验是每次只让它改一个点，改完立刻验证再进下一步，别一口气提好几个需求。另外把不想让它动的函数直接贴出来说“这块别碰”，比笼统说“只改该改的”管用。实在不行就全量重写，虽然费token但省心，尤其逻辑耦合紧的时候。

增量修改确实容易翻车，我一般会明确告诉它“只输出需要改的那个函数，其他代码原样贴回”。另外每次改完让它单独把改动点列出来，对比一下有没有被偷偷动过。反爬这种需求最好拆成独立模块，别混在解析逻辑里让它一起改。实在不行就全量重写，虽然费token但省心。

我也踩过这个坑，后来发现问题的根源是增量修改时上下文里旧代码太多，模型会顺手“优化”它看到的所有东西。我的做法是把要改的函数单独拎出来，只给这个函数的代码和改动需求，别让它看到整个文件。另外反爬和重试这种横切逻辑，最好一开始就在prompt里预留好扩展点，别指望后期加进去它不乱动别的。全量重写确实更稳，但token烧得也快，看你怎么取舍了。

我都是让它重写整个函数，别增量改，越改越乱。

增量改确实容易越改越乱，我一般让它只输出改动的那段代码，别整个文件重写。

我一般不让它增量改，直接每次给完整代码加一句“只重写这个函数，其他原样返回”，效果稳很多。增量对话里上下文越滚越乱，模型容易把之前的约束丢掉，尤其涉及反爬这种模糊需求时更明显。你可以试试把要改的部分单独拎出来，当成一个独立小任务发给它，改完自己合并回去，虽然麻烦点但基本不会崩。

我也遇到过这种情况，感觉GPT对“增量修改”的理解和我们不太一样，它容易把整个上下文当成一个大重构任务来对待。我现在的做法是每次只提一个明确的小改动，并且加一句“只输出需要改动的那个函数，其他代码保持原样”。另外把关键逻辑拆成独立函数，改起来影响面也小很多。全量重写反而更稳，但前提是你自己得把需求攒清楚一次性说完。

增量改就是容易跑偏，我一般让它只输出改动的函数，别整段重写。

这个问题其实挺典型的，我自己的经验是GPT在增量修改时特别容易“顺手”重构它觉得不够优雅的地方，哪怕你根本没让它动那块。它不像人类程序员会克制在最小改动范围内，而是每次都在重新理解整个代码意图，所以历史上下文一长，它就容易把之前的约束给稀释掉。我的做法是每次只贴需要改的那个函数，然后把其他不相关函数的完整代码用注释或者伪代码一笔带过，明确告诉它“以下代码块禁止修改”，这样它乱动的概率会低很多。另外重试机制和反爬这种横切关注点，最好一开始就在prompt里预留扩展点，比如让它把请求逻辑单独抽一层，后面加东西就不用碰解析部分了。至于全量重写还是增量修改，我觉得得看改动幅度，小改动就锁死上下文局部改，大改动不如重新描述完整需求让它从头生成，反而更可控。还有个野路子是用system prompt固定住“只输出diff”的格式要求，逼它聚焦在变更行上，试过几次效果还行，但偶尔它会偷懒漏改。

这个问题太真实了，我一开始也踩过完全一样的坑。后来我的做法是，别指望它在多轮对话里老老实实做增量修改，上下文一长它就会把“改A”理解成“顺便把B也优化一下”。我现在的习惯是每次只给它一个明确的小任务，比如“只加tenacity重试，其他代码原封不动贴回来”，然后把当前完整代码重新贴一遍给它，而不是依赖它记住之前的版本。另外我发现一个挺管用的点，就是让它输出diff或者只输出被改动的函数，这样它乱动别的地方你能立刻发现。至于反爬这种需求，最好单独开一轮，别跟重试混在一起说，需求一多它就开始自由发挥了。全量重写确实更稳，但成本是你得自己盯住回归，我一般是关键节点才全量重写，小改动就严格限定范围。

这个问题其实挺典型的，我自己的经验是增量修改本身就是GPT的弱项，不完全是你的prompt结构问题。你每次让它“顺便”加个功能，它会把整段代码重新生成一遍，而生成过程是有随机性的，之前对的地方它也可能给你改掉。我现在养成的习惯是，每次只让它输出需要改动的那一个函数或者那几行，明确告诉它“其他代码原样保留，不要重复输出”，这样它就没有机会去动别的地方。另外你说的重试和反爬这种横切关注点，最好一开始就在prompt里预留好结构，比如让它把请求层和解析层分开，后面加东西就只动请求层。如果已经写成一坨了，那与其让它增量改，不如把当前能跑的版本贴回去，让它基于这个完整版本重写，同时把之前踩过的坑写进约束里，比如“正则表达式不要动”。还有个偏方是让它改完之后自己diff一下，指出改了哪些行以及为什么，你扫一眼就能发现它有没有乱动。