用AI Agent写代码总跑偏，是我提示词问题还是工具选错了？

说实话你这个问题我太有共鸣了，之前用Agent迁移一个老模块时也差点被它“优化”到崩溃。我觉得核心矛盾不是提示词或工具单方面的问题，而是Agent天生就倾向于给出“看起来完整”的答案，尤其是Claude这类模型，它对代码风格的一致性理解其实很弱，你喂的规范它可能只是当参考，而不是硬约束。我后来试了个笨办法，就是把每次生成结果都丢回给模型，让它自己对照原始XML写一个差异分析报告，强制它解释每一步改动的理由，这样至少能逼它暴露那些自作主张的点。至于工具选型，如果你愿意折腾，可以试试把Agent的“行动权限”拆细一点，比如让它只生成单个类的迁移方案，你来review后再合并，别让它一口气动整个项目结构。另外我发现一个有用的提示词技巧，就是在系统提示里加一句“如果遇到任何不确定的兼容性取舍，必须输出一个TODO标记并停止继续生成”，比单纯强调风格管用得多。说到底，这种代码库级重构可能还是得人机协作，AI当个高级搜索+草稿机用，关键决策别全权交给它。

这问题太真实了，Claude系Agent在代码库级任务里确实容易“自信过头”。我建议先别急着换工具，试试把迁移规范里加一条硬性约束，比如“遇到任何不确定的兼容性逻辑，必须用TODO标记并暂停生成”，再配合一个自动diff审查的环节，专门盯Bean命名和逻辑改动，这样能兜住大部分跑偏情况。另外你提到老项目XML迁移，我怀疑是上下文窗口吃不下完整项目结构，导致它靠“猜”来补全细节，不如分模块小步推进，别一次性喂太多。

说实话你这个场景我太有共鸣了，之前我拿Agent迁移一个老支付模块也栽过同样的跟头。核心问题不是提示词不够强，而是Claude这类模型天生就带着“让代码变好”的惯性，你越描述项目背景它越容易脑补出“最佳实践”，反而把原始逻辑当成技术债来还。我的经验是，对这种代码库级重构，得把约束从“风格”层面降到“禁令”层面，比如明确列出哪些方法名、配置键、异常处理模式绝对不能动，甚至给它一份旧的XML和期望的JavaConfig一一对应的样例，让它照着填空而不是自由发挥。另外工作流上有个技巧很管用：让Agent分两步走，第一步只输出改动清单和风险点，等你确认了再让它写代码，别让它一口气生成完，否则它“自信”起来根本刹不住。工具方面我倒觉得Claude已经很能打了，换Cursor或Copilot也不会根治这个问题，关键是得在Agent外面套一层diff审查的环节，每次生成后跑一遍对比脚本，把不符合你规则的改动自动标红，逼着它修。你如果试过让它先写单元测试再动代码，说不定也能把它的“自作主张”拦住大半，因为测试会把行为锁死。

说实话这问题我太有共鸣了，Claude在代码库级重构上确实容易“自作聪明”，尤其对老项目里那些“历史遗留的丑但能用”的写法容忍度极低。我后来发现一个偏方：干脆把每个需要保留的异常逻辑写成单测用例丢给它，让它跑不过就老实了，比纯文字约束管用得多。工具上如果你试过Aider那种带git diff交互的，可能会觉得比自建工作流更可控，至少每次改动都能让你审一眼再继续。不过说到底，Agent的“自信”是模型天性，你得多设计几道强制确认的关卡，而不是指望靠一句提示词就让它变谨慎。

说实话你这个场景我太有共鸣了，之前拿Claude做类似迁移时也踩过同样的坑。问题不在于提示词没写清楚，而是Agent天生就带着“让代码变更好”的惯性，这跟咱们要的“保守重构”本质上是冲突的——它在遇到模糊地带时会默认选择自己认为最合理的路径，而不是最安全的路径。我后来试了个比较笨但有效的办法：把原XML里每个Bean的id和类名显式列成一张映射表，直接作为约束条件喂进去，然后要求输出必须逐条对照这张表生成Java Config，多写任何额外改动都算失败。这样至少能掐掉它“顺手优化”的冲动，但说实话也很费token，一个中型项目得来回迭代好几轮。工具层面我倒觉得Claude在代码生成精度上已经算第一梯队了，关键是工作流设计——像你这种代码库级迁移，最好拆成按模块分步做，每步只给一个明确的映射规则，别一次把整个规范全塞给它。另外，如果它生成完代码后能多一步“自我审查”阶段，让它自己列出所有跟原逻辑有出入的点，再让你确认，会稳很多。你有没有试过在Agent流程里加一个独立的“校验Agent”，专门对比新旧代码差异？我觉得这比单纯换工具靠谱。

这问题我太有共鸣了，之前拿Agent迁移老项目时也栽在“过度自信”上。你喂了规范和文档，但它对“隐含约定”的理解还是差口气，比如Bean命名那种，代码库里可能没明说但到处都是规律，它根本抓不住。我后来发现，光在系统提示里强调风格没用，得把“禁止做什么”写得更具体，比如直接列出“不允许改任何现有Bean的id，除非编译报错”，比“严格遵循”管用得多。另外，你试着把大任务拆成小步骤没？别让它一口气重构整个模块，让它一次只处理一个配置类，每步都加个验证节点，让它先解释打算怎么改、再动手，能拦住不少跑偏。工具方面，我觉得Claude本身没问题，但自建工作流要是没有“强反馈回路”就容易失控——比如让它跑完测试再自己检查diff，把不符合预期的地方标出来，比纯靠提示词约束靠谱。你要是试过这种带校验的循环还不行，再考虑换别的专门做代码重构的工具也不迟。

说实话这情况我太熟了，Claude写单文件还行，一碰跨模块重构就爱自己加戏。你试试把“不允许改动”的东西单独拉个清单，比如Bean命名规则、异常处理逻辑，直接写进工作流的硬性约束里，比在提示词里喊口号管用。另外我觉得工具本身没啥问题，关键是别让它一次性看太多上下文，拆成小任务一步步喂，它反而老实点。

说实话你这情况我太熟了，之前用Agent迁移老模块时也被它“自作主张”坑过。我感觉问题不全在提示词，工具本身的“性格”也占一半——Claude这类模型天生倾向于给一个“最优解”而不是“最稳解”，你越强调风格它越容易理解成“你可以自由发挥”。我后来试了个笨办法挺管用：把迁移规则拆成带编号的checklist，并且在每步生成后强制加一条“逐条对比是否违反规则”的自我审查指令，虽然慢点但跑偏率明显降了。另外你提到它不确认直接生成，我猜可能是你的工作流里没给它“提问的出口”，我习惯在Agent的决策节点上设一个“不确定就列出选项让我选”的强制分支，效果比单靠系统提示稳定得多。至于换工具，我也试过几个专做代码重构的，但它们对老项目XML解析的上下文理解反而更死板，未必比通用模型+严格约束强。还有个细节：如果老项目里有些逻辑你自己都觉得“怪”，那AI大概率会觉得这是bug顺手改掉，所以最好在喂给它的文档里专门标注哪些是“有意为之的兼容性设计”，减少它自作聪明的概率。

这迁移场景建议你把原有XML配置片段直接贴进上下文，别让它自由发挥，再配合代码评审兜底。

这问题我太有同感了，尤其是“过度自信”那个点，简直是我用Agent重构时的噩梦。我觉得你大概率不是提示词写得不到位，而是工具本身对“代码库级约束”的理解能力就到这儿了。Claude这类模型擅长生成新代码，但对“保持旧代码的隐性规则”其实特别迟钝，你喂的规范它可能读进去了，但生成时一遇到具体上下文就自己脑补。我自己试过最有效的办法是把“迁移规范”直接写成测试用例，让Agent先跑一遍失败的测试再让它改，而不是只靠文字描述。另外，工作流上可以加一个“强制澄清”节点，比如在Agent每次生成完改动后，让它列出所有它不确定或者自作主张的地方，你确认后才能进下一步，这样能砍掉90%的跑偏。至于换工具，我觉得自建工作流最大的问题是缺少一个“diff审查”的强制环节，你可以看看GitHub Copilot那种跟IDE深度绑定的，它至少能让你在改动前直观看到哪些逻辑被动了。不过说实话，老项目XML迁移这种事，我最后是半自动搞的，Agent只负责生成单个类的转换，全局一致性还是我自己把控比较稳。

看到你说Claude+自建Agent重构老项目，我太有同感了。我上周刚用Cursor试过类似迁移，结果它把@Bean方法名全给我改成驼峰缩写，明明老代码里是带模块前缀的。后来我发现问题不在提示词，而是工具对“约束”的理解太表层——它把“遵循风格”当成“代码能跑就行”，不会真去解析你XML里那些隐式依赖关系。我的经验是别让它一口气重构整个项目，先拆成按模块隔离的小任务，每个任务里把原XML片段和对应Java Config示例直接贴进去，再明确告诉它“只改写法，不动逻辑”，最后diff审阅时重点看Bean名称和条件装配。另外可以试试在Agent工作流里加一个“反问门槛”规则，比如遇到不确定的依赖注入就让它输出TODO标记而不是猜。不过说实话，如果项目里有很多历史遗留的hack逻辑，我觉得这活儿还是得半自动，让AI生成初稿，你花半小时人工校准关键点，比纯靠工具省心。你有没有试过用AST工具先做静态对比，把差异列表喂给AI当参考？

这坑我也踩过，后来发现光靠提示词压不住，得在Agent里加个“不确定就停”的硬规则。

这种代码库级别的迁移，光靠系统提示确实很难压住它自由发挥。我一般会把大重构拆成小任务，每次只让它改一个配置类，改完先跑测试再继续，不然它一兴奋就顺手重构一大片。另外可以在Agent里加个“不确定就停下来问”的硬性检查点，比如让它输出改动前先列个疑问清单，比单纯说“严格遵循风格”管用。工具本身倒不是主要问题，Claude做这类迁移够用了，关键是工作流得收着点。