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

说白了这就是上下文窗口被撑爆了，你每次对话历史里的代码和描述都在占token，Agent只能抓最末尾的指令，前面的设计思路早被截断了。我一般会把核心需求、技术选型和关键约束写进项目里的AGENTS.md或者docs文件，每次开新对话先让它读一遍，比在聊天里反复扯皮管用。另外改需求时尽量用“保持原有架构，只增加XX功能”这种明确指令，别让它自由发挥，不然它真会给你重写一遍。

这问题我也踩过坑，核心不是prompt抽象，而是工具本身没状态管理。我现在都是把关键设计决策单独写进一个requirements.md，每次改需求前先让Agent读一遍再动手，效果立竿见影。另外别让Agent大改，尽量用“在XX函数里加个参数”这种指令，它能少犯迷糊。

这问题我太有同感了，之前用Claude写个数据清洗脚本也是这德行，加个去重逻辑它能把整个函数结构重排一遍。后来我琢磨出个土办法，就是让Agent把每次改动的关键决策写成注释塞在代码头部，相当于给它自己留个“设计备忘录”，下次对话时先丢一句“继续之前XX文件的逻辑，注意看顶部注释”。另外我还会把需求拆成特别细的小步骤，一次只让它改一个点，改完立刻验收锁定，别攒一堆需求一次性提，它一重构准翻车。不过说实话，这本质还是上下文窗口的锅，长对话里注意力一分散，优先级就乱了，你要是项目逻辑复杂，与其硬靠Agent记，不如自己在外部维护个精简版的CHANGELOG，每次对话前丢给它，比啥都管用。你试过用规则文件或者.tooluse之类的约束文件没？我最近在试，感觉能稍微治一下它“手贱”改旧代码的毛病。

这问题我太有同感了，Agent对“追加需求”的理解确实不如“从零生成”稳定。我的土办法是把每次确认过的关键决策单独存成一个设计备忘，下次对话开头直接贴给它，比反复描述上下文省事得多。

另外你可以试试在项目里放一个rules文件，把固定逻辑和变量命名都写死，让Agent每次改动前先读一遍。我实测这样能少改掉不少旧代码，但遇到它突然“灵光一闪”重构的情况还是得靠版本控制兜底。

试试把需求写进项目里的docs文档，每次让Agent先读一遍再改，效果会好很多。

这问题太真实了，我最近用Copilot写个小工具也这样，改个参数它能把整个函数结构都重写了。后来我学乖了，每次迭代前先把关键设计决策写成一行注释钉在代码顶部，比如“重试逻辑只包网络请求别动解析”，然后再提需求，效果好很多。另外Cursor的Rules文件其实可以放这些约束，让Agent每次自动加载，比在对话里反复强调靠谱。

试试把需求写进项目里的TODO或设计文档，每次让Agent先读再改，能省不少事。

把关键决策写进项目里的CLAUDE.md或者TODO文件，每次让它先读那个再改，能少很多失忆。

或者干脆把改需求的指令写成独立小文件，让它只动该动的部分，别让它自己发挥。

说实话这问题我太有共鸣了，之前用Agent写数据处理脚本的时候也是被这个“失忆”折磨得够呛。后来我琢磨出一个笨办法：把每次改需求时的关键决策点，直接以注释形式写进代码里，比如“这里故意用pandas不用openpyxl，因为后续要处理大数据量”，下次Agent再乱改的时候，我就在prompt里甩给它一句“先读文件头部的设计注释再动手”。另外我发现，与其每次用对话式描述需求，不如单独维护一个requirements.md，把功能迭代的版本历史、当前选择的技术方案、以及哪些代码块是“锁定不要动”的都写清楚，然后每次让Agent先读这个文件再开始改，效果比在对话里反复强调好很多。但说实话，这本质上还是因为Agent的上下文窗口是有限的，它不像人脑有长期记忆，所以我觉得最靠谱的解法是把项目拆小，每个脚本只负责单一职责，这样每次要改的逻辑面就窄了，它“失忆”造成的破坏力也小。不知道你有没有试过在Cursor里用rules文件固定一些全局规范？我试过把“禁止重写已存在的函数”“只能增改指定模块”写进去，能稍微约束一点，但还是不能完全根治，同求大佬分享更硬核的工程化方案。

试试把需求和当前代码一起贴进对话，或者直接用项目级记忆功能，比纯聊天靠谱多了。

这问题太真实了，我最近用Copilot也这样，改个字段名它能把我整个函数结构都推翻了重写。后来我试了个办法，每次改需求前先把当前脚本的关键逻辑用一两行注释钉在文件顶部，比如“核心是pandas处理，别动异常捕获那段”，再让Agent做增量修改，效果好了不少。另外你试试把需求拆成特别小的步骤，一次只让它动一个函数，别指望它自己理解全局，目前这些工具的记忆真的就靠你反复喂上下文了。

这问题我也踩过坑，核心不是prompt写得抽象，而是Agent的上下文窗口本质上是“临时记忆”，你每次对话它都在重新理解需求。我现在做法是把关键决策和代码结构写进项目里的AGENTS.md文件，每次改需求前先让它读一遍这个文件，再明确说“基于现有代码只改XX部分”，效果会好很多。另外我习惯把大需求拆成小步骤，每完成一步就让它总结一下当前状态，相当于给它做“存档”。你试试看，至少能减少乱改逻辑的概率。

试试把项目说明和关键决策写进项目根目录的CLAUDE.md，每次开新对话直接让它先读那个文件。

这问题我太有同感了，跟Agent协作最怕的就是它“选择性失忆”。后来我摸索了个笨办法：把每次改动的需求、决策原因、最终代码版本都记在一个单独的CONVENTIONS.md文件里，每次对话开头先丢给它，再让它基于这个文件改，效果好了不少。

另外也建议把大需求拆成小步骤，每完成一步就让它总结一下当前状态，别一口气全丢进去。你试试把需求说得更具体，比如“在现有重试逻辑上加指数退避，别动其他部分”，它跑偏的概率会小很多。说到底，这类工具目前更像高级结对程序员，还不是真正懂你心意的伙伴，得靠你主动管着点它的“记忆”。

这问题我太有感触了，之前用Agent写个数据处理脚本也这样，改个字段名它能给我把整个函数结构都重构了，气得我直接回滚。后来我发现核心不是prompt写得细不细，而是你得把“需求变更”和“系统重构”这两件事在对话里明确区分开——比如每次只描述增量改动，前面加一句“保持现有逻辑不变，只在xxx函数里加个重试”。不过说实话，这工具目前确实更像“快速原型生成器”，而不是“团队协作者”，它的上下文窗口和注意力机制决定了它天生容易“喜新厌旧”。我现在的土办法是开两个对话，一个专门记录设计决策和接口约定，另一个才用来改代码，改完把关键结论手动同步回去，虽然麻烦但至少不会乱。另外你试试在项目里放一个AGENTS.md文件，把已经确认过的约束写成规范，每次开新对话先让它读一遍，比纯靠聊天记忆靠谱得多。这玩意儿说到底还是得你自己当“项目经理”去管理它的记忆，指望它自动记住所有上下文，至少现阶段不太现实。

这问题我也踩过坑，核心不是prompt抽象，而是Agent压根没有“项目记忆”的概念。我现在习惯把每次确认过的设计决策单独写进一个docs文件，改需求时先丢给它“按这个文档改”，比反复口述上下文靠谱多了。另外建议把大改动拆成小步骤，每完成一步就让它输出当前完整代码，这样即使它抽风改坏了，你也能快速回滚到上一个可用版本。

试试把设计决策写成独立的docs文件，每次让agent先读再改，比对话上下文靠谱多了。

试试把关键决策写进项目里的CLAUDE.md，每次让它先读这个再动手，比在对话里反复强调靠谱多了。

这问题我太有同感了，跟Agent协作最怕的就是它“选择性失忆”。我之前用Claude写个数据清洗脚本，加了三次过滤条件，结果第四次让它调整排序，它直接把前面所有逻辑全推翻了，气得我差点回退到Git。后来我琢磨出个土办法：每个需求改动前，先把当前完整代码和设计意图用中文写进新的prompt里，相当于给它喂一个“记忆快照”，再让它基于这个快照去改，而不是让它自由发挥。还有个坑是别用“加个功能”这种模糊指令，最好明确说“在现有代码的XX函数里，不改变原有返回值结构的前提下，增加一个重试参数，默认3次”。不过说真的，这类工具更适合从零生成原型，真到了迭代维护阶段，还是得靠人能看懂的设计文档和版本控制，不然光靠对话流管理上下文，迟早得疯。另外你可以试试在项目里放一个CONVENTIONS.md文件，把关键决策和代码风格写进去，每次让Agent先读那个文件再动手，效果比纯聊天强不少。

这问题我太有同感了，之前用Agent改个数据处理脚本也是这德行，加个过滤条件都能把前面封装的函数拆了重写。后来我发现核心不在于prompt抽不抽象，而是工具本身对“项目状态”的理解太弱了——它每次对话其实都在重新推理，你所谓的“之前设计”对它来说只是聊天记录里的几行字，权重远低于它现场生成的代码。我试过把设计决策写进一个单独的CONVENTIONS.md文件，每次对话开头强制让它先读一遍，再把关键约束用注释钉在相关函数旁边，这样它改的时候至少会顺着注释走。但说实话，遇到要动架构的改动，我还是会手动把要改的函数单独抽出来喂给它，改完再合并回去，不然它一兴奋就把其他模块牵连了。另外你提到版本对比，我现在基本用git做细粒度提交，每次让Agent改前先commit，改完diff一眼就能看出它动了啥，不爽就revert。这工具当结对编程的实习生用还行，真当长期记忆的同事使，目前还是太勉强了。