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

这问题我太有同感了，尤其是用Agent改脚本的时候，它经常把之前定好的变量名或者函数签名给偷偷换了，搞得我git diff看得脑壳疼。后来我摸索下来，发现关键不是你prompt写得抽不抽象，而是得把“需求变更”和“上下文记忆”拆开来看——每次提新需求时，我会先把当前脚本的核心设计用三五行话总结一遍（比如“入口是process_file，错误处理在retry_decorator里，输出格式由FORMAT常量控制”），再追加你的修改点，这样它至少不会把老逻辑推翻。另外我强烈建议把脚本拆成几个小文件，每个文件单一职责，Agent改的时候影响面小很多，就算它“失忆”了，重写一个模块也比重写整个脚本省事。还有个土办法，就是让它每次改动前先输出“改动计划”让你确认，虽然多一步，但能避免它自嗨式重构。至于工具适不适合迭代开发，我觉得现阶段它们更像高级补全，真指望它记住所有历史决策不现实，所以关键是把“记忆”外置到你的项目结构里，而不是指望它的对话窗口。你试试把核心逻辑写成纯函数，副作用都隔离到main里，会发现容错率高很多。

这问题我太有同感了，之前用Agent写个数据清洗脚本也是，加个去重逻辑它能把前面的字段映射全给我重写了。后来我学乖了，把需求拆成特别小的步骤，每完成一步就让它把当前代码存到单独文件里，相当于给Agent做个checkpoint。另外我习惯在项目里放个requirements.md，每次改需求前先让它读一遍这个文档再动手，效果会好很多，你可以试试把关键设计决策都写进去。

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

这问题太真实了，我最近也被折磨过。后来发现与其让Agent记住全部上下文，不如把项目拆成小文件，每个脚本只干一件事，改需求时直接开新对话引用相关文件路径就行。另外把那些固定的设计决策写进项目里的CLAUDE.md或者README，每次让Agent先读一遍，比在对话里反复强调管用多了。

这问题我也踩过坑，现在习惯是把关键决策直接写进项目里的AGENTS.md或者TODO文件，每次改需求前先让Agent读一遍再动手。另外把需求拆成小步骤，别一口气全塞进去，能减少它“自由发挥”的概率。不过说实话，指望它完全记住上下文还是不太现实，版本控制该用还是得用。

这个痛点太真实了，我后来基本放弃让Agent记上下文，改成把需求拆成小函数，每个改动就针对那个函数提，让它别碰其他部分。另外你可以在项目里加个“设计说明.md”，把关键决策写进去，每次对话开头扔给它，比反复描述靠谱得多。

这问题太真实了，我最近也卡在这。后来发现把项目拆成独立小文件，每个文件开头写清职责和接口，改需求时只指定改哪个文件，Agent就不容易动到其他逻辑。另外建个CHANGELOG.md把每次改动的决策写进去，新对话直接让它先读这个文件再动手，效果好很多。你试试看？

试试把需求写进项目里的docs文件，每次让Agent先读再改，比纯对话靠谱多了。

这个我太有同感了，Cursor的Agent模式说白了就是个有短期记忆的自动补全，你每次改需求它其实是重新推理一遍，不是真记住你之前的设计。我现在做法是把关键决策写进项目根目录的CLAUDE.md或者docs里，每次开新对话先让它读一遍，比在对话里反复强调靠谱得多。另外小需求尽量合并成一次说完，别挤牙膏式提需求，它一重构起来真的能把人逼疯。

这问题太真实了，我也踩过同样的坑。后来发现把需求文档单独存成一个md文件，每次改需求就在那个文件里更新，然后让Agent先读文件再动手，比在对话里反复描述靠谱得多。另外我习惯让它把关键设计决策写在代码注释里，这样就算重写也能顺着思路走。说到底这工具还是更偏向一次性任务，真做迭代还是得靠版本控制兜底。

我也有同感，尤其是用Cursor改脚本的时候，Agent对上下文的理解更像是“临时记忆”，而不是真正维护一个设计文档。后来我习惯在项目里放一个CHANGELOG或者CONVENTIONS.md，每次改需求前先让它读一遍这个文件，再明确说“基于现有逻辑只改某处”，效果会好很多。另外你可以试试把大需求拆成小步骤，每次只提一个改动点，别一股脑全塞给它，不然它容易自作主张重构。说到底这工具目前更适合“从零生成”，迭代还是得靠我们自己把约束写清楚，不然版本对比真的会疯。

这问题太真实了，我最近也被折磨过。后来发现与其让agent全量改代码，不如把每次迭代的决策点直接写成注释或者单独的md文件，让它在动手前先读一下，相当于给它个“记忆外挂”。另外，像“保留现有逻辑，只新增xx功能”这种明确边界的话术，比单纯说“加个重试”要好使得多，它就不会自作主张重构了。不过说实话，这工具目前确实更适合从零写小脚本，连续迭代个四五轮之后，代码质量就开始玄学了，还是得靠版本管理兜底。

试试把项目规范和要求写进项目根目录的rules或CLAUDE.md里，每次都让它先读一遍再动手。

用规则文件和会话记忆锚点配合，比纯靠对话上下文靠谱多了，我现在基本都这么干。

这问题我太有同感了，之前用Claude写个数据处理脚本，中途想加个去重逻辑，结果它把整个文件结构给我重构了，差点没把我送走。后来我发现核心问题不在prompt抽象，而是你根本没给它一个“可迭代”的工程基础——你把它当成对话了，但它其实需要你把它当成一个“有短期记忆的结对程序员”。

我现在比较有效的做法是：不管脚本多小，先让Agent把功能拆成独立函数，并且明确告诉它“每次改动只准动对应函数，禁止重写其他部分”。另外，我会在项目根目录放一个“DEVLOG.md”，每次做完一个修改就强制让Agent把当时的决策、变量命名、边界条件写进去，下次开新会话第一句话就是“先读DEVLOG，再继续改”。

还有个土办法挺管用：把每次的prompt都附上“上一次你完成了X，现在只需要在Y函数里加Z”，而且要主动给出具体的函数名和行号，别让它自己找。说到底，这些工具本质是“无状态”的，你指望它记住不如自己帮它建个索引，不然你永远在跟它的“失忆”作斗争。

我也遇到过这个坑，后来发现关键是把每次修改当成独立任务，在prompt里明确说“基于当前代码，只做XX改动”，别让它自由发挥。另外，把核心设计思路写进项目里的AGENTS.md或docs文件，每次对话开头让它先读一遍，比反复描述上下文靠谱得多。说到底，Agent现在更像结对编程的实习生，你得主动把“记忆”外置成文档，不然它只会按概率瞎猜。

这问题我太有同感了，说白了就是Agent的上下文窗口跟我们的“项目记忆”根本不是一回事。你每次提需求，它确实带着之前的对话，但它对“代码结构”的理解是扁平的，没有优先级概念，所以一改就容易把老逻辑当成可优化的草稿重写。我试过最有效的办法是把关键设计决策写进一个独立的“开发笔记.md”文件里，每次改需求前先让它读这个文件，再明确说“只改XX函数，别动其他部分”，效果立竿见影。另外，如果你用的是Cursor，建议把核心脚本拆成多个小模块，每个模块单独开一个对话窗口去迭代，这样上下文干扰会小很多。说到底，这工具就是个强力的结对程序员，但你得当那个记得住全局的架构师，把约束条件反复喂给它，别指望它自己会“记住”什么。

这个问题的核心在于Agent的上下文窗口是“一次性”的，你每次新对话都等于让它失忆了。我试过把需求写进项目里的AGENTS.md或者docs/开发日志.md，每次改需求前先让它读那个文件，再结合代码现状提修改，效果会好很多。另外，像“加个错误重试”这种小改动，我会直接指定函数名和行号，让它只动局部，别让它自己发挥重构。说到底，这种工具更适合当结对编程的实习生，你得明确告诉它“只改这里，别碰其他”，版本对比的习惯还是得保留。

这个问题我太有共鸣了，Agent模式写脚本时确实经常出现“聊着聊着就失忆”的情况，尤其是需求一多，它就开始自由发挥，把之前定好的结构推倒重来。我后来发现一个比较管用的做法，是把关键设计决策单独写成一个简短的“约束文件”，比如用注释或者单独的 md 放在项目根目录，每次新需求都先让 Agent 读它，再动手改。另外 prompt 里尽量别只说“加个重试”，而是明确告诉它改哪个函数、保留哪些接口、输出格式保持什么不变，这样它乱动的概率会小很多。还有个土办法，就是每完成一个小功能就手动 commit 一次，Agent 改崩了直接回滚，比跟它反复拉扯省心。说到底这类工具目前更像一个手很快但记性一般的实习生，迭代开发不是不能做，但得靠外部记忆和版本控制来兜底，不能指望它自己记住全部上下文。