用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但省心，尤其逻辑耦合紧的时候。