用AI Agent写Python脚本，每次改需求都要重新描述上下文，怎么破？

这问题我也踩过坑，后来发现关键是别让Agent自己“放飞”，得把需求拆成小步走，每改一次就让它在原代码上打补丁而不是重写，比如明确说“保留现有函数，只加retry逻辑”。另外我习惯在文件开头放一个注释块，写清楚当前版本的设计决策和待办，每次对话先甩给它，比反复描述上下文省事多了。说到底这工具更像结对编程的实习生，你不钉死边界它就自由发挥。

这问题太真实了，我也被坑过好几回。后来发现一个笨办法：把每个阶段的完整代码和关键决策直接粘进对话里，让Agent基于“你给的版本”改，而不是让它自己回忆，能少很多幺蛾子。另外，试着把需求拆成特别小的步骤，一次只改一个点，比一股脑提一堆要求靠谱得多。本质上它还是靠上下文窗口吃饭的，别指望它有真正的长期记忆。

这问题太真实了，我试过让Claude加个字段，结果它把整个函数签名都改了。后来我学乖了，每次改需求前先明确说“只动xxx函数，其他别碰”，再把它之前写的代码直接粘进对话里当参考，比描述上下文管用得多。说到底还是得把关键决策点写进一个单独的设计说明文件，每次让Agent先读那个再动手，不然它真能给你重写个新版本出来。

这问题我也踩过坑，后来发现核心不是prompt抽象，而是你得把关键决策固化到项目文件里，比如专门建个docs/design.md，每次改需求前先让它读一遍再动手。另外可以试试在对话里明确说“只改xx函数，别动其他逻辑”，配合git diff做检查，能少很多返工。Agent其实没记忆，全靠你帮它“外置”上下文。

我现在的做法是让Agent每完成一个阶段就输出一份简短的CHANGELOG，把设计取舍和代码结构写进去，下次开新对话直接把这个文件丢给它。比在聊天记录里翻强多了，而且还能顺便当项目文档用。另外别指望它记住，每次开始前花两分钟把约束条件列清楚，比事后对比版本省事。

其实这问题本质是会话窗口的上下文长度有限，你可以在每次提需求时主动总结一下之前的关键决定，比如“保留上次的异常处理逻辑，只加个重试机制”。我一般还会让它先描述改动计划，确认后再写代码，这样它不会擅自重构。还有个小技巧，把核心函数单独放一个文件，用import引用，改的时候影响面小很多。

这问题太真实了，我试过用agent写个多步骤处理的脚本，改到第三轮它直接把前面的数据清洗逻辑给吞了。后来我学乖了，把每次确认好的关键决策单独存成一个design.md，每次改需求前先甩给它看，再明确说“只改这里，别的别动”，效果好很多。另外建议把任务拆小，别让它一口气干太多事，每完成一个独立功能就锁定版本，不然它真会给你“创造性”地重写。

这问题我太有同感了，之前用Agent写数据处理脚本也差点被它“失忆”逼疯。后来我琢磨出一个土办法，就是把所有需求变更写进一个单独的CHANGELOG.md，每次对话开头直接丢给它，并明确说“严格按这个文件改，别动其他逻辑”。另外，如果改动大，我会干脆让它把核心函数拆成独立模块，这样它重写时至少不会把底层封装全毁了。不过说实话，Agent现在的上下文窗口再大，也扛不住长对话里你那些隐性的设计偏好，所以别指望它“记住”，得靠你自己把关键决策固化进注释或文档里。还有个偏方，就是每次改完就让它输出一个“变更摘要”，下次开场先让它读摘要再动手，比重新描述有效得多。总之这工具适合做一次性任务，迭代还是得自己兜底，别太信任它的“记忆”。

这问题我也踩过坑，后来发现核心不是prompt写得多细，而是得把项目拆成独立的小脚本，让每个Agent只干一件具体的事。改需求时直接开新对话，把旧代码路径和改动点甩给它，比让它“记住”上下文靠谱多了。另外像重试、日志这种通用逻辑，不如自己封装成函数，每次让Agent直接调用，省得它发挥。

这问题我也踩过坑，核心不是prompt抽象，而是Agent本身没有持久记忆。我现在的做法是把关键决策写进一个单独的CONVENTIONS.md，每次改需求时先让它读这个文件再动手，效果立竿见影。另外你可以试试把每个功能点拆成独立脚本，用主程序调用，这样改一个模块就不会牵连其他逻辑了。

这问题我太有同感了，之前用Agent改脚本也老被它“失忆”整破防。后来我发现核心不是prompt抽象，而是你把它当成了“对话伙伴”，其实它更像一个“无状态的重写引擎”——每次输入默认你给的是全新需求，所以它宁可推倒重来也不敢漏掉逻辑。我的土办法是把关键决策写进一个单独的“设计备忘录”文件，每次改需求前先粘贴给Agent，再明确说“基于这个文档里的方案，只改XX部分”，同时给它看具体函数名和行号，别让它自己发挥。另外，强烈建议把重复性修改（比如加重试、改格式）做成独立的小函数，让Agent只动那一个入口，减少它触碰全局的机会。说到底，这工具目前更适合“从零生成”而不是“持续维护”，你要么接受每次花时间校对，要么就学会用文件当外部记忆——别指望它真能记住对话历史，那只是营销话术罢了。

这问题太真实了，我一开始也这样，后来发现核心是别让Agent自由发挥，得把项目约束固化下来。我现在习惯在项目根目录放个AGENTS.md或者CLAUDE.md，把技术栈、关键逻辑、甚至你踩过的坑都写进去，每次开新会话先让它读这个文件，再聊需求。另外改小需求时，我基本不用“加个重试”这种模糊指令，而是直接告诉它“在现有的fetch_data函数里，给requests.get调用包一层retry装饰器”，范围锁死了它就不会乱动别的地方。说到底，这类工具更像是结对编程的实习生，你指望它记住所有上下文，不如把记忆外置成文档来得靠谱。

试试把需求变更写成单独的CHANGELOG文件，每次直接丢给Agent，比重新描述上下文省事多了。

这问题太真实了，建议用项目记忆功能或者维护一个设计决策文档，不然Agent真跟金鱼一样。

说白了这不是你prompt抽象的问题，是Agent的上下文管理机制有硬伤。我也遇到过，尤其是脚本逻辑一长，它经常把之前的约束条件当成临时建议给丢了。我的土办法是搞一个独立的“需求变更日志”文件，每次改需求前先让它读一遍这个文件，再动手改代码，相当于给它找个外部记忆体。另一个坑是别让它“重写整个文件”，尽量用“只修改某个函数”这种明确指令，配合git diff来盯变化，不然它真能给你把之前调好的边界条件全冲掉。其实这类工具更适合从零生成原型，迭代维护还是得靠你自己把关键决策点写成注释，或者干脆把代码拆成小模块，每个模块单独开对话。说到底，现阶段别指望它真理解“设计意图”，把它当个记忆力只有十分钟的实习生就行了。

试试把关键决策写进项目里的AGENTS.md，每次让它先读再改，比口头说上下文靠谱多了。

建议把需求拆成小任务逐步确认，一次性说太多它真记不住，还容易自由发挥。

试试把需求和约束写进项目里的规则文件，每次让它先读再改，比纯靠对话上下文靠谱多了。

试试把项目规范写进rules或单独存个设计文档，每次对话开头直接甩给它，比反复描述上下文省事多了。

试试把需求和历史决策写进项目里的docs文档，每次让agent先读一遍再改，比纯对话上下文靠谱多了。

我一般把关键设计约束直接怼在代码注释里，agent改的时候能少犯浑，你可以试试。

这问题太真实了，我感觉核心矛盾在于Agent的上下文窗口是“临时记忆”而不是“项目记忆”。你每次对话其实都在一个新会话里，它只能靠你贴代码或者重新描述来猜，自然容易跑偏。我的土办法是把关键设计决策写进项目里的一个“开发日志.md”，每次改需求前先让它读这个文件再动手，效果立竿见影。另外，你试试把那些“不要动”的代码块用注释标出来，比如“这段是核心逻辑，改动前必须确认”，Agent在生成时会更谨慎。还有个小技巧，如果它改坏了，直接说“回退到上一版”，别自己手动对比，省时间。说实话，这类工具更适合从零写脚本，迭代维护还是得靠版本控制兜底，别太指望它“记住”，把它当个高级补全器可能心态会好很多。

建议把需求变更直接写进项目里的docs文档，每次让它先读文档再改代码，比靠对话记忆靠谱多了。

试试用规则文件约束它，把设计决策和接口约定都写进去，每次改需求前让它先读一遍，比反复描述上下文省心。

我最近也踩过这个坑，后来发现把需求拆成小块，每改一次就单独开个新对话，然后把之前的关键决策直接粘进去，比让它自己记靠谱多了。另外你可以试试在项目里放一个docs文件，每次让它先读一遍再动手，相当于给它个外部记忆。不过说实话，真要做复杂迭代，还是得自己把代码结构理清楚，别全指望Agent。

这问题太真实了，我最近也被Agent模式整得头疼。我的土办法是让Agent每次改完代码先输出一段“设计摘要”，下次对话开头直接粘贴给它，相当于手动帮它巩固记忆。另外，把需求拆成独立小脚本，别一个文件堆所有功能，改起来就不容易误伤其他逻辑。