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

我也遇到过类似的情况，尤其是用AI写那种需要精确处理边界条件的逻辑时，经常翻车。你提到的文件递归和误删__init__.py这两个问题，我猜本质上是AI对“项目结构”和“Python约定”的理解太表层了。它可能记住了ast的API，但没真正搞懂__init__.py在包结构里的角色——它只是个初始化的标志文件，但AI有时会把它当成普通py文件去分析是否import了东西。

我自己试过一种办法，不一定对，但你可以参考：拆分成更小的子任务。比如先让AI写一个函数，专门扫描目录下所有py文件（但要明确排除__init__.py），输出文件列表；再单独写一个函数，对单个文件用ast提取import语句；最后再写一个聚合函数。每一步都单独验证，最后再让AI把这几段拼起来。这样哪怕某一步的逻辑错了，你改起来也更有头绪，不用在长篇prompt里来回折腾。

另外，你提到贴了ast文档片段，这个我试过效果确实不稳定，因为AI有时候会“过度学习”文档里的例子，反而忽略了你的实际需求。建议不如直接给它一个极简的“输入-输出”示例，比如“给定一个包含a.py和b.py的文件夹，期望输出一个列表，内容是['a.py: unused import os', 'b.py: unused import sys']”，让它先对齐这个格式，再慢慢优化。

你提到先画流程图再写代码，这个我试过几次，感觉对特别复杂的逻辑有帮助，但像你这种ast扫描的单一任务，画流程图可能反而耽误时间。倒不如先让它写一个“最笨但正确”的版本（比如不用递归，只处理当前目录），你再手动指示它加上递归参数，这样AI更容易理解你的意图。

这种任务确实容易翻车，我一般先让Agent写伪代码确认逻辑再生成最终版本。

我觉得问题可能出在“逻辑判断”这个环节，AI Agent对具体代码实现的边界条件其实挺模糊的，像递归扫描或者排除__init__.py这种细节，它容易漏掉。我之前用Claude写类似工具时试过先给伪代码框架，再让它填充具体逻辑，效果比直接描述需求好不少。或者你也可以试试把需求拆成两步：先让Agent生成一个文件树结构的处理流程，再基于这个流程写AST分析代码，这样它不容易跑偏。不过说实话，这类偏工程化的脚本还是自己手动调一下更靠谱，Agent当个快速原型工具还行。

这种偏逻辑判断的任务确实容易翻车，尤其涉及到文件递归和异常情况（比如__init__.py的特殊性），Agent很容易“想当然”。我自己的经验是，与其让Agent直接写完整代码，不如分步骤来：先让它生成一个伪代码或逻辑流程，你确认后再让它转成Python，这样能提前发现它理解错的地方。另外，像删除文件这种有风险的操作，可以在prompt里强制加一个“只输出建议列表，不执行任何删除”的安全约束，能减少误伤。

不过话说回来，AST解析这种偏底层逻辑的任务，目前LLM的稳定性的确不如人写的样板代码靠谱，感觉它更适合搭框架而不是处理边界条件。

说实话你这情况我也遇到过，感觉Agent对这类“边界条件”的把握确实不太稳，像文件递归和__init__.py这种项目习惯它很难一次get到。我的经验是别指望它一步到位，不如先让它按你的需求写出核心逻辑，然后你自己再手动补上异常处理和边界判断，这样反而比反复改prompt省心。流程图那招我试过，对复杂逻辑有点用，但简单任务里Agent理解起来还是容易跑偏。

这类任务还是得自己拆步骤喂给它，一步到位它容易短路。

这种偏逻辑的活儿AI确实容易翻车，我建议你先拆成小步骤让它逐块调试。

老实说我也遇到过类似的情况，agent对这种需要精确边界判断的任务确实容易翻车，尤其文件递归和特例处理这种细节很容易被忽略。我觉得不完全是prompt的问题，而是模型对“代码逻辑的全局一致性”理解有限，你可以试试把需求拆成两步：先让它输出伪代码或逻辑步骤给你确认，再写具体实现。另外手动在prompt里加几个边界case的例子（比如排除__init__.py），效果会比贴文档好很多。

这种偏逻辑的任务确实容易翻车，建议你先手写个伪代码框架，再让Agent填充细节会稳很多。

这类任务对上下文连贯性要求高，Agent容易在细节上断片，建议把需求拆成几步逐步验证。

说实话我觉得这锅不全在prompt上，这种需要精确控制边界条件（比如递归、排除特定文件）的任务，Agent天生就容易漏掉细节。你试过给Agent直接喂一个手动写好的伪代码框架吗？我上次写类似脚本时先把关键逻辑用注释标好，再让它填空，效果比纯描述需求稳定很多。另外也可以考虑拆成两步：先让Agent单独生成ast遍历的核心函数并测试通过，再让它封装成完整脚本，这样出问题了也好定位。

这问题太真实了，我也被Agent坑过好几次。感觉它不是不理解ast的用法，而是对项目结构和业务场景缺乏整体感知，尤其是递归和排除特定文件这种边界条件，光靠prompt很难一次性交代清楚。我试过先让它拆成函数模块再写，效果比直接生成完整脚本要好一点，至少改起来有头绪。不过说实话，这种带明确判断逻辑的活儿，最后还是手工调一下更稳，Agent当个初稿生成器还挺香。

说实话，遇到这种需要精确逻辑判断的任务，Agent确实容易翻车，尤其ast这种树结构解析，它经常在边界条件上犯迷糊。我试过类似场景，感觉与其反复调prompt，不如直接把核心逻辑拆成两步：先让它生成我确认过的伪代码框架，再填充细节，这样准确率高不少。另外你说的绘图方案我试过，对复杂流程有点用，但简单脚本反而显得绕，你可以试试把规则写成测试用例喂给它，让它对照着改。

说实话，我最近也踩过类似的坑，尤其是在处理带“排除逻辑”的任务时，Agent经常会在边界条件上翻车。你提到的漏掉文件递归和误删__init__.py，其实本质上是Agent对“负向约束”理解不够——它往往记住了要做什么，却记不住哪些情况不能做。我自己的经验是，与其堆砌更详细的文字prompt，不如在prompt里直接给一个它生成的错误输出例子，然后告诉它“这种结果不对，因为xxx”，这样它更容易抓住关键点。另外，像ast库这种偏静态分析的工具，Agent虽然能调用，但对“上下文敏感”的判断（比如哪些import是动态使用的）确实很弱，这不全是prompt的问题。我试过让它先写伪代码注释，再逐行补全，效果会比一次性生成完整脚本好一些，毕竟它写短片段时注意力更集中。你提到的画流程图我觉得可以试试，但别抱太大期望——它画出来的流程图可能自己都看不懂，最后写代码时照样跑偏。说到底，这类工具更适合做“模板化”的批量操作，真要处理带业务逻辑的精确判断，还是得靠人写核心函数，Agent当辅助填空。

这类偏逻辑判断的任务，Agent确实容易在边界情况翻车，尤其是涉及文件递归和特殊文件过滤这种需要细致判断的地方。我个人经验是，与其让它直接写完整代码，不如把需求拆成更小的步骤，比如先让它写一个能处理单个文件的函数，验证通过后再加递归和过滤逻辑。另外，把测试用例也写进prompt里，告诉它“如果遇到__init__.py就跳过”，效果会比贴官方文档更直接。

这种任务确实容易踩坑，不如把需求拆成几步让Agent一步步来。

说实话，你遇到的情况我太熟了，年前我也用Claude写过类似的import清理工具，来回折腾了五六版prompt才勉强能用。我觉得问题可能不只是prompt，而是这类“精确逻辑+边界情况”的任务，Agent的推理深度确实有限，它容易把ast的节点类型理解得过于理想化，比如漏掉__init__.py里隐式导入的场景。你提到贴官方文档片段，我试过类似方法，但Agent有时会照搬文档示例却忽略你项目里的具体结构。换个思路的话，我建议别让它直接写完整代码，而是先让它产出一个伪代码逻辑框架，你审核完再生成Python脚本，这样它出错的范围会缩小很多。另外可以试试在prompt里明确写“先递归收集所有.py文件，再逐一分析，并且排除__init__.py”，把边界条件单独列成checklist，效果会比一次性描述好。工具本身的局限肯定有，但把任务拆成“逻辑设计→代码生成”两步走，至少能让你少改几版。

这种逻辑嵌套的任务，Agent容易“顾头不顾尾”，建议先把边界条件（像__init__.py）写进prompt的禁止列表里。

这种偏逻辑嵌套的任务Agent确实容易翻车，建议先拆成小步骤一步步喂给它。

我最近也碰到过类似的情况，用Agent写那种需要“精确排除某些文件”的逻辑时，它经常把边界条件搞混。我感觉这种任务其实挺吃“隐式规则”的，比如__init__.py不该删这种常识，Agent很难从你的需求里自动推理出来。可以试试把“排除条件”拆成单独的步骤喂给它，比如先让它列出所有文件，再手动告诉它哪些类型不能动，这样它犯错的概率会低不少。