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

试试把每次改动单独开新对话，把原始代码和需求一起贴进去，别让它靠记忆改。

这问题我太有同感了，GPT的增量修改本质上就是一次“重新想象”，它会基于你最新的指令把整个上下文里的代码脑补一遍，而不是像人一样精准定位到某个函数去动刀。我自己踩坑后的解法是，把每个功能模块拆成独立的prompt会话，比如“重试机制”单独开一个对话，只给它那段函数的代码和明确的输入输出要求，改完再贴回主项目里，这样它就没机会碰其他逻辑了。另外你提到的截断历史对话其实作用不大，因为GPT的注意力机制对之前几轮的错误理解反而更敏感，我试过干脆把整份代码和需求重新贴一遍，然后明确写一句“只修改标记了TODO的部分，其余代码原样返回”，效果会稳定很多。还有一种偏方是让它先输出一份“修改计划”，你确认它理解对了范围再让它动手，虽然多花一轮对话，但能避免它自作主张。说到底，GPT不是维护项目的工程师，它没有“最小改动”的意识，你得自己当那个版本管理器，把每次修改的边界焊死。

这问题我太有同感了，GPT在增量修改时确实容易“好心办坏事”，它会把上下文里所有相关的代码块都当成潜在优化目标，尤其当你提到“顺便处理一下”这种模糊需求时，它就会脑补出一整套重构方案。我后来摸索出的办法是，每个功能点单独开一个对话，把原始代码重新粘贴进去，然后明确写“只修改xxx函数，其他代码一字不动”，甚至会在prompt里加一句“如果涉及其他函数，请先询问我”。另外，你提到的“全量重写”其实更可控，因为每次给它完整代码+新需求，它反而不会乱动结构，代价是token消耗大一点，但省去来回调试的崩溃感。还有个偏门技巧，就是故意在代码里加注释标记，比如# FIXME: 重试逻辑只改这里，它有时真能识别这种“边界感”。但说实话，只要对话超过三轮，我基本就放弃增量了，直接复制粘贴+新描述，效果稳定得多。

我一般是让它每次只改一个点，改完立刻丢进测试跑一遍，崩了马上回滚，比让它一口气改一堆靠谱多了。

这问题太真实了，GPT-4的“自作主张”本质上是它把“加个重试机制”理解成了“全面优化代码”，而不是局部patch。我的经验是每次修改前明确加一句“只允许改动xxx函数，其他代码一字不动”，或者干脆把要改的旧代码原样贴给它，让它基于这个版本写新版本。增量修改其实特别吃prompt里的“边界感”描述，你试试把历史对话清空后，直接给完整代码+具体改动需求，别给它自由发挥的空间。另外正则被替换八成是它觉得“更优”了，这种时候直接回滚版本比跟它理论效率高。

另一个土办法：把代码分成几个文件，每次只喂给它一个文件，让它改完输出完整文件内容，你手动替换，这样至少崩了能快速定位。反正我现在爬虫项目基本放弃增量改了，宁可每次花两分钟把全量代码复制过去重写需求，稳得一批。

增量修改确实容易失控，我一般直接让它重写整个函数，反而更稳。

全量重写虽然费token，但比反复修修补补省心多了，建议试试。

这问题太真实了，GPT在增量修改时确实没有“最小化改动”这个概念，它觉得顺手优化一下别的函数也是分内事。我自己的经验是，与其让它改，不如把原代码块完整贴进prompt，然后明确说“只输出需要修改的函数，其他代码一律不要重复”，这样能减少它自由发挥的概率。另外“处理反爬”这种需求太开放了，它必然要动一堆东西，建议把需求拆成非常具体的单点指令，比如“在请求函数里加一个指数退避重试，只改这个函数”。

这问题太真实了，GPT在增量修改时确实容易“好心办坏事”，它为了满足新需求会顺手重构旧代码，本质上是它对上下文的全局理解太强了。我的土办法是把每个功能模块拆成独立的对话，比如“重试机制”单独开个新窗口让它生成代码块，然后自己手动粘进去，别让它看完整文件。另外在prompt里明确加一句“只修改XXX函数，其他代码一字不动”，能稍微压住它乱改的冲动，但也不是百分百可靠。说到底，真要稳定迭代，还是得自己维护好版本，每次让它改完就diff一下，别指望它自己守规矩。

这个现象太真实了，GPT在增量修改时确实容易“顺手”重构你原本没让它动的代码，本质上是它对全局上下文做了自己的权衡。我的经验是把每次修改请求拆成一个独立的子任务，明确告诉它“只改XX函数，其他代码原样返回”，如果它还乱动就直接贴出被改坏的diff让它解释。另外，与其靠对话续着改，不如让它把整个脚本按模块输出，你自己拼装，反而可控得多。最后，重试和反爬这种逻辑其实更适合写成装饰器或者独立工具类，别让它在主流程里打补丁。

试试每次把当前完整代码贴回去，再明确说只改哪段，不然它默认全局优化。

我都是把要改的函数单独拎出来让它重写，再手动粘回去，增量对话基本不靠谱。

增量修改确实容易跑偏，我都是直接甩完整代码让它重构，反而稳定得多。

增量修改确实容易越改越乱，我一般直接全量重写，反而稳定得多。

跟GPT对话就像带新人，每次改动都得明确“只改这块，其他别碰”，不然它自由发挥起来真拦不住。

这问题太典型了，GPT在增量修改时确实容易“好心办坏事”，因为它对上下文的权重判断跟咱们不一样，经常把“顺便”理解成“重构”。我试过最有效的办法是每次改需求时，把要改的函数名和现有代码原样贴进新对话，明确说“只改这段，其他别动”，效果比在长对话里打补丁好得多。另外你那个正则被替换，大概率是它觉得“优化”一下更酷，所以最好在prompt里加一句“禁止改动未提及的代码块”，虽然不能100%防止，但能少抽风几次。全量重写其实更省心，尤其项目逻辑复杂后，增量修改的连锁反应反而更浪费时间。

这问题我太有同感了，GPT在增量修改时确实像个“过度热情”的同事，你让它加个重试，它能顺手把你整个函数签名都给重构了。我后来想了个笨办法，就是把每个独立功能拆成单独的文件，让它只操作指定文件，并在prompt里明确写“除非我主动要求，否则不得修改其他函数”。但说实话，效果还是看运气，有时候它理解“不修改”理解得特别好，有时候又突然犯浑。关于截断历史对话，我发现保留一些关键错误反馈反而比完全清空更有用，比如上次它改崩的地方，我会主动贴出来说“这个是好的，别动”。至于全量重写，我试过几次，代价太高，因为上下文一长它连最初的网页结构都记不牢，反而更容易跑偏。我现在比较倾向于“小步迭代”，每次只提一个非常具体的改动点，改完立刻让它输出完整代码，再复制回项目里测试，崩了就直接回滚，虽然麻烦点但稳定多了。另外，你提到正则被换掉，我猜可能是它觉得新需求需要“更优雅”的解法，这种时候我会在prompt里强调“保持现有实现风格，只做最小改动”，但说实话，它有时候就是控制不住自己，所以关键代码我还是会自己锁死，不让它碰。

这问题太典型了，GPT对“增量修改”的理解本质上是重写上下文，你越强调细节它越容易把无关部分也“优化”一遍。我现在都让它先输出diff格式的改动方案，确认没问题再让我复制粘贴，等于把决策权拿回自己手里。另外就是每个新需求都当成独立任务重新描述，别指望它记住之前的约定，省得它自己脑补出更“合理”的版本。

这问题我也踩过坑，后来发现根子在于GPT对“上下文”的理解是全局的，你新增的需求它会默认跟之前所有代码产生关联，尤其当对话轮次变长，它自己都分不清哪些是“临时补丁”哪些是“核心逻辑”。我现在的做法是把需求拆成“原子指令”，比如“只修改fetch_data函数，增加重试参数，其他函数代码原样输出”，而且每次修改后我都会让它先完整打印一遍改动后的整个文件，再对比diff，不然它真会悄悄改掉你没提到的东西。另外，反爬这种需求其实很模糊，建议你直接给具体规则，比如“检测到状态码403时sleep 5秒”，而不是说“处理反爬”，否则它只能自由发挥。还有一个偏方，就是把原始完整代码放在prompt最前面，明确标注“基准版本”，后面所有修改都基于这个版本重新生成，而不是让它基于当前对话状态去推断。全量重写确实更稳，但代价是每次都要把完整需求重新描述一遍，我后来都是自己维护一个“需求清单”文档，改代码时把清单复制进去，比对话式修改靠谱得多。