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

用规则文件把需求和约束写死，每次改需求时先让Agent读一遍再动手，能省不少事。

我一般把设计决策都记在项目里的CLAUDE.md，效果好很多。

这问题太真实了，我也被坑过好几回。后来我学乖了，干脆在项目根目录放个CLAUDE.md或者要求它每次改代码前先读一遍我自己写的“需求变更日志”，把每次改动的理由和决策点都记下来，效果好了不少。另外你试试把需求拆成“新增功能”和“修改逻辑”两类，明确告诉它哪部分不准动，不然Agent真会自作主张把结构重写了。说到底这工具更适合从零生成，迭代维护还是得靠人盯着，别指望它真有长期记忆。

我也遇到过这个坑，后来发现关键是把需求变更写进项目里的一个TODO或CHANGELOG文件，让Agent每次先读这个再动手。另外试着把“加个重试”这种需求说得更具体，比如“保留现有函数结构，只在请求部分增加重试逻辑”，它的改动范围会小很多。本质上这些工具还是偏会话式，不适合长线记忆，所以把设计决策沉淀到文件里比靠对话强。

这问题我太有同感了，Agent对“当前状态”的记忆基本就是个摆设。我的土办法是建一个项目专属的“需求变更日志”，每次改完需求就把关键决策和代码结构写进去，下次对话开头直接甩给它，比反复描述上下文省心多了。另外也可以试试把大任务拆成几个小脚本，让每个Agent只负责单一功能，这样改起来互不干扰，代码反而更稳。

这问题太真实了，我也被折磨过。后来发现一个能缓解的办法：把项目里关键的决策和代码结构写进一个单独的说明文档，每次改需求前先让Agent读一遍那个文件再动手，相当于给它搭个“记忆锚点”。另外，别指望它一次到位，我会把大改动拆成几步，每步确认完再继续，虽然慢点但至少不会乱改老代码。

这问题太真实了，我拿Agent写数据处理脚本也老遇到这情况。后来发现一个稍微管用的办法：把需求变更直接追加在项目里的一个“变更记录.md”里，每次改需求前先让它读一遍这个文件再动手。另外如果它开始乱改代码，我会让它先把新需求拆成小步骤，每步只动相关函数，别整段重写，稍微能控制一点。不过说实话，真要复杂逻辑迭代，还是得自己掌握关键代码结构，别全指望它记住。

这问题我太有同感了，Agent模式写一次性脚本还行，一涉及迭代就各种失忆。我的土办法是把关键决策写进项目里的AGENTS.md文件，每次改需求前先让它读一遍，再明确说只改某个函数，别动其他逻辑。另外，小步提交用git做版本管理比让AI自己记得靠谱多了，它重写就重写，大不了回滚。说到底，别指望它真能理解你的设计意图，把它当个手速极快的初级程序员，你自己得把好关。

这问题太真实了，我也被坑过好几回。后来发现一个笨办法：把当前脚本的关键逻辑和变量名单独存成一个design.md，每次改需求前先让Agent读一遍这个文件再动手，效果会好很多。另外，小步提交也很重要，每完成一个功能就git commit一下，万一改崩了还能回滚，别指望Agent自己记住，它就是个金鱼脑。

这问题我太有同感了，之前用Agent写个批处理脚本也是被改得头皮发麻。后来我发现核心不在于prompt写得多详细，而是你得把项目当成“持续对话”而不是“单次请求”——每次改需求前，先花半分钟把当前文件的关键结构和上次确定的逻辑用一句话复述给它，相当于给它一个锚点。另外强烈建议把那些“不要动”的代码段用注释标出来，比如“这段是核心算法，改输出格式时别碰”，Agent其实很吃这套显式约束。还有个土办法，就是每完成一个稳定版本就立刻commit，让git当你的记忆，万一它乱改你就直接回滚，比手动对比版本省心多了。至于工具适不适合迭代，我觉得它更像一个记性差但执行快的实习生，你得习惯性喂上下文，而不是指望它自己记住。你试试把需求拆成“新增功能”和“修改现有功能”两类，后者一定要附上对应的代码行号，效果会好很多。

这问题太真实了，我最近也被折腾得够呛。我的土办法是把设计决策写进项目根目录的AGENTS.md里，每次开新对话先让它读一遍，再强调“只改XX模块，别动其他部分”。另外就是明确告诉它“基于现有代码做增量修改”，别让它自由发挥，不然它老想“优化”你之前写的东西。至于版本对比，我干脆直接开个git分支，改坏了就回滚，比肉眼对比靠谱多了。

其实这问题核心不在prompt抽不抽象，而是Agent的上下文窗口本质上是个短期记忆，你每次新对话它就重置了。我一般会把“关键设计决策”单独写进一个CONVENTIONS.md文件里，每次开工前先让Agent读一遍，再开始改代码，效果会好很多。另外建议把大需求拆成小步骤，每完成一步就让它更新这个文件，而不是指望它自己记住。

这问题太真实了，我最近用Copilot写脚本也这德行。后来我学乖了，把每次改动的需求写成CHANGELOG一样贴在代码注释里，再让Agent基于注释改，效果好了不少。另外，让它每次只动一个函数，别让它自己发挥重构，能少很多幺蛾子。

这问题我太有同感了，之前用Agent写脚本也是被它“失忆”搞到崩溃。后来我发现一个土办法：把每次修改的完整设计决策和关键代码片段直接贴在项目根目录的CLAUDE.md或者一个命名为“迭代记录”的文档里，每次开始前先让它读一遍再动手，效果好很多。不过还有个疑问，你们试过让Agent自己维护那个文档吗？我总担心它为了省事会偷偷简化掉一些细节。

这问题我太有同感了，尤其是Agent模式刚出来那会儿，我几乎每天都要跟它重复一遍“咱们之前不是说了用pandas处理吗”。后来我试了个土办法，就是在项目里专门放一个“设计决策.md”文件，每次改需求前先让Agent读一遍这个文件，再开始动代码。效果确实好一些，但说实话还是得盯着，它有时候会自作主张“优化”掉你之前明确要求保留的逻辑。我觉得核心问题在于，这些工具本质上是无状态的，它每次都是基于你当前对话窗口里的内容来推理，而不是基于整个项目历史。所以我现在基本把长任务拆成几个短会话，每个会话只干一件事，并且在代码里写清楚注释和接口约定，把“上下文”固化在代码结构里，而不是指望它记住。另外，你提到的“加个错误重试”这种需求，我建议直接写成函数参数，而不是让Agent去改主流程。你试试看，能不能把“需求描述”变成“修改某个具体函数的输入输出”，这样它出错的概率会小很多。

这问题太真实了，我最近也被搞得很头疼。后来发现一个笨办法，就是把每次改动的关键决策写进一个单独的“需求变更记录”文件，每次对话开始先丢给它，再配合git diff看改动，能省点事。另外我感觉Agent更擅长理解单个明确任务，不太适合长线迭代，所以现在都拆成小步骤来跑，反而稳定多了。

试试把需求写进项目里的docs文件，每次让agent先读再改，能少丢不少上下文。

这问题我前两天也刚踩过坑，后来发现把设计决策直接写进项目里的AGENTS.md文件特别管用，每次改动前先让它读一遍再动手，比在对话里反复强调上下文靠谱多了。另外你试试把需求拆成小步骤，每次只让它改一个点，出错概率会低很多，不然它一重构确实容易把之前的逻辑带偏。

这问题太真实了，我也被坑过好几回。后来我摸索出一个土办法：把设计决策直接写进项目里的AGENTS.md文件，每次改需求前先让Agent读一遍这个文件，再开始动手，相当于给它一个“记忆锚点”。另外，小步提交也很重要，每次改动前先让Agent描述它打算怎么改，确认思路对了再让它写代码，能少走好多弯路。

这问题太真实了，我拿Agent改脚本也经常被它“失忆”整破防。后来发现光在对话里说不够，得把每次确认过的设计决策直接写成项目里的TODO或注释，下次让它先读文件再动手。另外试试把需求拆成小步提交，每次只让它改一个点，别指望它一口气把所有逻辑都串起来，比重新描述上下文省心多了。

这问题太真实了，我最近也被折磨过。后来发现最有效的办法是把项目里那些关键决策写进一个专门的“开发日志”文件，每次改需求前先让Agent读一下这个文件再动手，相当于给它一个外部记忆。另外就是每次只提一个非常具体的改动点，别把多个需求混在一起说，不然它很容易自作主张重构。还有个小技巧，如果它改了不该改的部分，直接说“恢复这个函数到上一版”往往比手动回滚快得多。