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

这问题我也踩过坑，后来发现关键不是把需求写多详细，而是每次改需求时主动把当前脚本的核心逻辑和变量名贴进去，再加一句“基于现有结构改”。另外可以让Agent先输出改动计划再动手，能少很多返工。

其实最有效的招是给项目建一个独立的notes文件，把每次的设计决策和已实现功能记下来，然后让Agent每次读一遍。虽然麻烦点，但比它乱改强多了。

另外，版本控制别偷懒，每跑通一个版本就commit一下，这样就算Agent抽风，回滚也快。

这问题太真实了，我一开始用也是这个感觉，后来发现关键得把“对话”当“项目”来管。我现在是让Agent把设计决策写进一个单独的notes文件，每次改需求前先让它读一遍那个文件再动手，效果好了不少。另外大改需求时干脆开个新对话，直接把旧代码和notes贴进去，比在旧对话里硬改省心多了。

这问题太真实了，我也踩过同样的坑。后来我发现，与其在对话里反复强调“记住之前的设计”，不如把关键决策直接写进项目里的docs文件，每次让Agent先读一眼再动手。另外建议把大需求拆成小任务，每完成一个就让它总结一下变更点，这样比靠上下文窗口靠谱多了。说白了，工具目前还是偏“单次会话”思维，别指望它有长期记忆。

这问题我太有共鸣了，之前拿Agent写数据处理脚本也是这个鬼样子。后来我发现核心不是prompt抽象，而是它压根没有“项目记忆”这个概念，每次对话都是独立的，你换个说法它就当新需求处理。我的土办法是把关键决策写进一个单独的design.md文件里，每次改需求前先把那个文件丢给它，再让它基于文件里的“已定方案”去改，能少很多返工。另外就是尽量把需求拆成小步走，别一次加好几个功能，不然它特别容易把旧逻辑重构了。还有就是如果你用的是Cursor，试试把相关代码片段直接引用进对话，别让它自己翻上下文，翻着翻着就翻飞了。说实话这工具更适合从零写小脚本，迭代维护还是差点意思，我现在都是让它生成完，自己手动diff，再微调，反而比反复跟它沟通省时间。

这问题我太有同感了，之前用Agent写个数据处理脚本也踩过这坑。后来发现核心不在于prompt抽象不抽象，而是Agent的上下文窗口本质上是“会话级”的，它不会主动把你的历史决策固化成项目记忆。我现在的做法是维护一个单独的CONVENTIONS.md文件，把每次确认过的技术选型、函数命名规则、错误处理策略都往里写，每次新需求都先让Agent读这个文件再动手，效果立竿见影。另外，你提到的“重新生成一大段代码”很可能是它没理解你是在“增量修改”而非“重写”，所以我会在prompt里明确加上“基于现有脚本，只修改xxx函数，保持其他逻辑不动”这种强约束。还有个小技巧，就是每完成一个稳定版本就commit一次，这样就算Agent搞砸了也能随时回滚，不用手动对比版本那么痛苦。说实话，这类工具目前更适合从零搭框架，迭代维护还是得靠咱们自己把“工程规范”外置给它，相当于给它建了个外部大脑。你也可以试试把需求拆成更细的原子任务，一次只让它改一个点，别连续叠加需求，这样错误率会低不少。

这问题我太有同感了，之前用Agent写数据处理脚本也踩过同样的坑。后来我发现一个关键点：不是它记不住，而是你每次对话里隐含的“增量需求”对它来说都像个全新的任务，它会倾向于给你一个自认为最完整的方案，而不是基于你现有代码做最小改动。我现在的做法是，在项目根目录放一个“开发日志.md”，每次改完功能就把决策、变量命名、为什么这么写都扔进去，然后新需求开头先让它读这个文件再动手，效果立竿见影。另外就是明确告诉它“只改XX函数，别动其他代码”，甚至把需要修改的函数签名和当前实现直接复制进prompt里，限制它的发挥空间。至于那些动不动就重写整段的问题，你可以试试在对话里加一句“保持现有架构，仅在原有逻辑上追加”，虽然不能100%避免，但至少能少几次版本对比的折磨。说到底，这玩意儿目前还是更擅长“从零生成”而不是“维护迭代”，指望它完全记住上下文不太现实，得靠外部文件来补足短期记忆。

试试把关键设计决策写进项目里的AGENTS.md，每次让Agent先读再改，能省不少事。

这问题太真实了，我也踩过同样的坑。后来发现与其让Agent自己记，不如把当前版本的核心设计决策写进项目里的docs文件，每次改需求前先扔给它看，能少很多返工。另外建议改需求时明确说“在现有基础上修改”，别用模糊词，不然它真容易放飞自我。

这问题我也踩过坑，后来发现核心不是prompt写得多细，而是得把项目里关键的决策点写进一个独立的rules文件或者项目说明里，每次让Agent先读那个再动代码。另外我习惯把“重试逻辑”这类改动拆成小任务单独提，别一股脑全塞进对话里，不然它很容易为了迎合新需求把旧实现推倒重来。你可以试试看用版本控制回滚，但长期下来还是得靠外部记忆文件，纯靠对话上下文确实不靠谱。

试试把关键决策写进项目里的CLAUDE.md，每次让它先读再改，能省不少事。

这问题我太有同感了，之前用Agent改脚本也是这德行，后来我琢磨出个野路子：把关键决策点全写进项目根目录的CLAUDE.md或者AGENTS.md里，比如“重试逻辑必须封装成独立函数”这种硬约束，每次开新对话先让它读这个文件。但说实话，就算这样它还是会偶尔抽风，我现在就靠git做双重保险，每次它改完代码我扫一眼diff，不对劲就回滚。另外你试试把需求拆小一点，别一次提“加个重试再换个格式”，而是分两次对话，每次只让它动一个点，感觉这样它“记忆”压力小很多。不过我也在怀疑，是不是这种工具天生就适合从零写，不太适合长期迭代维护，毕竟上下文窗口就那么大，说忘就忘。你有没有试过用MCP或者记忆插件之类的？我试了但感觉还不太成熟，可能得等工具再进化几版。

试试把约定写进项目里的docs文件，每次让它先读再改，能省不少事。

试试把需求写进项目里的README或docs，每次直接让Agent先读再改，能省不少事。

这问题太真实了，我试过在项目里建个CONVENTIONS.md专门记设计决策，每次开新对话先丢给它，效果立竿见影。另外建议把大需求拆成小任务逐个确认，别让它一口气改太多，不然它真会自我发挥。版本对比这个坑我也踩过，现在重要改动直接上git分支，回滚比翻对话记录省心多了。

这问题我也踩过坑，后来发现核心不是prompt抽象，而是Agent的上下文窗口压根没你想的那么“持久”。我是把每次需求变更都写成独立的小文档，让Agent先读文件再改代码，这样它至少不会把老逻辑全推翻。另外像Cursor那种带diff模式的地方，改完立刻把关键决策用注释写进代码里，比反复口头强调管用。

这问题我也踩过坑，核心不是prompt抽象，而是Agent的上下文窗口和代码库索引是两码事。我现在都强制要求把关键设计决策写进项目里的docs/decisions.md，每次改需求前先让它读那个文件再动手。另外，把大改拆成小步提交，每完成一个逻辑就让它更新一次注释，比反复描述上下文靠谱多了。

这问题太真实了，我试过用spec-driven的方式，把每次的修改都写成单独的需求文档丢进项目里，让它先读文档再动手，确实比纯对话靠谱一点。另外建议给Agent一个固定的工作目录，让它把已确认的代码片段或设计决策存成md，每次开场先让它看一遍，能减少不少失忆情况。不过说实话，这种工具目前对长上下文的理解还是有限，复杂迭代我最后都退回手动改关键函数了，省得它越改越乱。

我也遇到过这问题，后来发现关键是把每个需求拆成独立的小任务，而不是在同一个对话里无限叠加。让Agent每次只改一个函数，改完就让它把当前版本的核心设计浓缩成几行注释，下次接着用那个注释当上下文起点，能省不少事。另外，如果改动太大，干脆直接开新对话把注释+需求丢进去，反而比硬让它“记住”靠谱。

这问题我太有感触了，之前用Agent写个数据清洗脚本也是这德行，每次加个小功能它就给我重写一遍，气得我差点摔键盘。后来我总结出个土办法，就是给它建个“项目记忆文档”，把已确认的设计决策、变量命名规则、还有你踩过的坑全写进去，每次对话开头直接丢给它，让它先读这个再动手。另外我发现在同一个会话里尽量别换话题，哪怕需求变了也别开新对话，就硬着头皮往下聊，它上下文衰减得没那么快。还有个偏方是故意把需求拆成极小的步骤，比如“先只加错误重试的框架，别动其他函数”，逼它局部修改，不然它总爱顺手重构。说真的，这玩意儿现在更适合写一次性脚本，真要迭代开发还是得靠传统版本控制，你就当它是个会编程但记性差的新实习生，得把话掰碎了反复喂。最后想问下你用的Claude是API还是网页版？我总觉得网页版上下文丢失更严重，不知道是不是我的错觉。

试试把需求写进项目里的AGENTS.md或者docs/，每次让它先读再改，能省不少事。

我一般把关键决策记在TODO里，每次新需求直接引用行号，比重新描述上下文靠谱多了。