用AI Agent写Python脚本，总改不对逻辑，是我prompt没写好还是工具本身局限？

这情况我也遇到过，别全怪prompt。你让Agent处理“删除未使用import”这种带风险判断的活儿，它其实很难把握边界，比如__init__.py这种特殊情况，模型脑子里没有工程经验的。我上次让它重构一个函数，它倒是能跑，但边界条件全靠我一遍遍喂错误案例才改对。你可以试试把“保留哪些文件”和“忽略哪些模式”直接写成黑名单塞进需求里，比让它自己理解强。流程图那步我感觉对简单脚本有点绕，但如果你把ast解析的每个步骤拆成伪代码给它，效果可能更稳。

这问题我太有同感了，Agent写这种带边界条件的逻辑确实容易翻车。你提到漏递归和误删__init__.py，其实本质是它没把“项目结构”和“特例文件”当成硬约束，而是当成了普通描述。我后来学乖了，会先在prompt里明确写“用os.walk但跳过__init__.py”，甚至直接给它一个最小可运行的伪代码骨架，让它只填细节。比起画流程图，我觉得给反例更有效，比如“如果遇到__init__.py就跳过，别删”。另外，这类任务我通常会让它先输出测试用例，再写实现，能逼它把边界想清楚。

这问题我太有同感了，Agent写这种带边界条件的逻辑确实容易翻车，尤其是“递归扫描”和“排除特殊文件”这种隐含规则，它经常顾头不顾腚。我自己的经验是，与其反复磨prompt，不如直接给它喂一个最小可运行的测试用例，让它先跑通再改，比描述一百遍需求都管用。至于画流程图，对简单脚本可能有点过度设计，但对这种多步骤判断任务，让Agent先列个伪代码步骤，再逐条实现，确实能减少它“自由发挥”的空间。工具本身肯定有局限，但很多时候是我们没把“不能做什么”写清楚，试试在需求里直接加一句“禁止修改任何__init__.py”这种硬性约束，效果立竿见影。

说实话你这个场景我太有共鸣了，之前我让Agent写类似的代码分析工具也翻过车，后来发现它其实是在“猜”你的意图，而不是真正“理解”项目结构。像递归扫描和忽略__init__.py这种边界条件，对模型来说属于隐性知识，你如果不显式写进prompt里，它大概率会漏。我觉得这不完全是prompt的锅，agent本身对代码库的全局感知就很弱，它更擅长生成独立函数，而不是处理文件系统这种有状态的操作。你试试把需求拆成两步：先让它生成一个只负责单文件分析的纯函数，你再自己写个os.walk循环去调用它，这样逻辑分离后它的成功率会高很多。至于画流程图，我试过有点用，但别指望它能一步到位，更实际的做法是让它输出每一步的决策注释，然后你逐行审查，把边界条件直接写成“如果遇到X就跳过”这种硬规则。另外你贴ast文档这个思路没问题，但模型容易过拟合文档里的示例，反而忽略你项目的特殊性，不如给它一两个你项目里的真实文件作为few-shot样例。

说实话我也踩过类似的坑，Agent对“删除建议”这种带安全边界的操作特别容易放飞自我。你光贴文档没用，它理解不了隐性的项目约定，比如__init__.py那种特殊文件。我后来是把约束条件直接写成测试用例丢给它，让它先跑红再改，比反复磨prompt靠谱得多。另外那种“先画流程图再写代码”的建议，我觉得对它帮助不大，反而会让它想太多绕晕，不如把任务拆成“只扫描+输出报告”和“实际执行删除”两步，让它专注一步。

这种逻辑严密的任务，AI很容易在小细节上翻车，建议先让它输出伪代码你再审一遍。

我试过把需求拆成好几个小函数分步生成，比一次性给全要稳得多。

这问题我太有同感了，之前让Agent写个批量重命名的脚本，也是反复改prompt，最后发现它总是抓不住边界情况。我觉得逻辑判断类的任务，Agent更像是帮你搭框架，细节还得自己兜底，比如递归和忽略特定文件这种，它很容易想当然。你让它画流程图估计也悬，因为问题不在理解流程，而是它生成代码时容易“过度自信”地简化逻辑。我的办法是拆分任务，让它先写核心的ast遍历逻辑，我再手动补上文件过滤和递归，这样反而比让它一步到位稳定得多。

说实话我觉得这问题一半一半吧，你需求描述得挺清楚了，但Agent对“删除建议”这种偏保守的操作天生就缺个安全边界，它容易把逻辑简化成“能用就行”。我试过让它写类似重构脚本，后来发现得在prompt里强制加“必须显示所有被影响的行号”和“禁止修改任何文件，只输出报告”这种硬约束才稳一点。流程图那招我觉得没必要，反而容易让它更糊涂，不如直接给它一两个带陷阱的测试用例，让它跑完自己对照预期输出，比改prompt管用多了。

这问题我太有同感了，最近拿Agent改个数据处理脚本也这德行，小逻辑它绕半天。你贴文档它不一定真读，其实核心是它缺少对代码运行时状态的感知，光看代码很难发现__init__.py这种边界情况。我后来是逼它先写单测再写实现，让它自己跑测试暴露问题，你试试把prompt从“给我代码”改成“给我一个能验证正确性的方案”，可能会稳很多。

说实话这类任务我也踩过坑，Agent对“删除”这种不可逆操作天生就保守，加上ast的遍历细节它确实容易想当然。我后来是让它先输出一个待删除列表的JSON，我人工确认后再执行，相当于加了个安全阀。你可以试试把需求拆成两步：先让Agent写个只扫描不删除的版本，跑通后再让它加删除逻辑，这样出错的概率会低很多。另外，流程图那个思路我觉得可行，至少能让它把边界条件（比如跳过__init__.py）在动手前明确列出来，比反复改prompt效率高。

说实话我觉得这问题一半一半吧。Agent对“精确逻辑”的把握确实弱，尤其是像ast这种需要理解语法树节点关系的场景，它容易在边界条件上犯迷糊，比如你提到的递归和__init__.py特判，这其实是典型的“知道规则但不会在所有地方应用规则”。我自己试过类似任务，后来发现与其反复改prompt，不如把需求拆成更小的步骤，比如先让它单独写一个“遍历文件”的函数，再单独写“分析import”的函数，最后再拼接，每一步你都给个测试用例去验证，这样比一次性输出完整脚本要稳得多。流程图那个思路我倒觉得未必有用，因为它是生成代码能力的问题，不是理解流程的问题，你画了图它该漏还是会漏。不过我也挺好奇，你有没有试过在prompt里明确给它几个“反例”，比如直接告诉它“不要碰__init__.py，不要递归进.venv目录”，有时候给负面约束比正面描述要有效。工具肯定有局限，但我觉得这种任务它还是能干的，就是得多花点“调教”的耐心，别指望一次成型。

说实话我觉得这问题的根源在于Agent对“项目上下文”的理解太弱了，它更像在拼凑代码而不是真正推理文件依赖关系。我自己试过类似任务，后来是把需求拆成三步：先让它列出所有py文件，再单独写ast分析函数，最后合并结果，每步都验证输出，这样成功率明显高。画流程图那招我也试过，有点用但别指望它一次搞定，关键还是得靠你手动喂“边界案例”给它，比如明确说排除__init__.py和特定目录。工具局限肯定存在，但多试几次你会摸到它的脾气。

说实话这问题我最近也踩了不少坑，感觉Agent对“删除”这种有副作用操作特别容易放飞自我，它更擅长生成代码而不是做严谨的静态分析。你试试把需求拆成两步：先让它只输出分析结果到JSON，确认无误后再单独让它写删除逻辑，别指望一次搞定。还有个小技巧，把“忽略__init__.py”直接写成测试用例塞进prompt里，比描述规则管用得多。

说实话我觉得这问题不完全怪prompt，你描述得已经够细了，但Agent本质上是概率生成，它没法像人一样把“删除未使用import”背后那些隐含规则全推理清楚。比如__init__.py这种特殊情况，除非你明确写“排除所有__init__.py”，否则它根本不会主动想到。我试过类似任务，后来发现最有效的办法不是让它一次写对，而是先让它生成一个最简版本，然后我手动指出来哪几个边界case没处理，再让它针对性地补逻辑，这样迭代两三轮就稳了。至于画流程图那个思路，我觉得对复杂任务可能有用，但对这种小脚本反而有点绕，Agent理解文字描述已经够用了，关键还是得把每个“不要做什么”写死。另外你也可以考虑换个工具，比如直接用Pyflakes或者Vulture这类现成库，何必非得让AI从零造轮子呢，它写出来的ast遍历代码八成还没这些库成熟。

这种任务其实更适合让Agent先跑通最小用例再迭代，光改prompt确实容易翻车。

我试过类似场景，把需求拆成“先扫描再分析再输出”三个小步骤让Agent分步执行，成功率会高不少。

这题我太有感触了，之前用Agent处理类似的代码分析任务也翻过车。我觉得这属于典型的“逻辑组合爆炸”问题，Agent能理解单点规则，但很难像人一样全局统筹递归、边界条件这些隐式约束。你贴官方文档反而可能让它更教条，不如直接给它一个包含__init__.py的最小测试目录，让它跑完看结果自己纠错。流程图那招我试过，效果一般，更管用的是把需求拆成“先扫描→再过滤→最后输出”三步，每步单独验证。另外也可以考虑换个思路，用现成的vulture或autoflake库，让Agent去调API而不是从零写逻辑，成功率会高很多。

这种偏逻辑的活儿，Agent确实容易翻车，建议你让它先写个最小可跑的版本，再一步步加条件，别指望一次到位。

这问题我太有同感了，我拿Agent写数据处理脚本时也老在边界条件上翻车。我觉得核心问题不在于prompt写得够不够细，而是Agent对“项目上下文”的理解是碎片化的——它知道ast怎么用，但很难把握你项目里哪些文件该递归、哪些是生成文件该跳过，这种隐含规则你描述得再清楚，它也可能在某次重构里突然丢掉。你说贴官方文档片段，我也试过，效果时好时坏，感觉它更像在“拼凑”答案而不是“推导”逻辑。不过画流程图这个思路我倒觉得值得试试，不是让Agent画，而是你自己画，把每个判断分支和异常情况都标出来，再照着图写prompt，这样它能更聚焦在决策树上，而不是自由发挥。另外还有个土办法，就是让它先输出伪代码或测试用例，你确认逻辑骨架没问题了再让它填实现，比直接生成完整脚本要稳得多。工具确实有局限，尤其对“否定性”逻辑（比如排除__init__.py）特别容易忽略，但换个交互方式，比如拆成多轮对话逐步验证，确实能改善很多。

说实话我觉得这问题挺典型的，不是prompt写不好，是这类任务本身就卡在“边界条件”上。你想想，ast分析这种活儿，人类写的时候也得反复想递归、排除文件、保护特殊文件这些细节，Agent只是把常见路径走了一遍，但你的项目里恰好有它没见过的例外情况。我倒觉得你贴官方文档这个思路对，但可能更有效的是给它喂一个“反例”：比如明确告诉它“上次你漏了递归，这次必须处理os.walk”，再配合一个你手写的期望输出样例，让它照着格式对齐。流程图那个方案我不太看好，它画图时逻辑清晰，但转成代码一样会把约束丢在细节里。另外提醒下，就算Agent写出来了，你也得自己准备几个带嵌套目录和__init__.py的测试项目去跑，它自己不会主动验证这些边界。我试过类似场景，最后是把任务拆成两步：先让它生成纯ast遍历的独立函数，再让它写基于这个函数的删除建议脚本，分开调试反而比一次成型稳定很多。工具确实有局限，但有时候是我们把“让它写完整工具”和“让它补全某段逻辑”混在一起了，后者它明显更靠谱。

这问题我最近也踩过坑，写一次性脚本还行，但涉及边界条件比如递归遍历或者排除特定文件，Agent确实容易顾此失彼。你贴官方文档这招我试过，效果看运气，它有时候会“过度理解”然后自己发挥。我后来改成让它先输出伪代码逻辑，我确认每一步再让它生成，成功率明显高些。另外像这种删除操作，我干脆让它只产出报告，具体删不删我自己来，反而省心。