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

说实话我觉得你这个场景可能两方面都有点问题，Claude在代码生成上确实偏“创造性”，对老项目的约束力不如专门的代码库级工具。我试过类似迁移，后来换成让Agent先输出一个完整的“差异清单”再动手改，把“不要问问题”改成“先列出所有你觉得需要偏离原设计的点”，这样能逼它暴露犹豫，而不是直接乱写。另外，如果项目里Bean命名被改，大概率是上下文里缺少风格约束的“负面示例”，你可以把之前改错的代码片段直接喂回去，告诉它“这类情况必须保持原样”，比写抽象规则管用。还有个小技巧，把迁移拆成小步提交，每步跑完测试再继续，至少能控制它跑偏的范围。

老项目重构还是得靠约束强的工具，试试Aider或者Cursor的agent模式，规则写死能少跑偏。

说实话这情况我太熟了，之前用Agent迁移一个老模块时也这样，后来发现根子不在提示词，而是你给的“迁移规范”本身太像人类看的文档了，AI会把规则当参考而不是硬约束。我的做法是把关键约束直接写进一个独立的CONSTRAINTS.md文件里，然后在工作流里把它设成不可被后续对话覆盖的“系统级上下文”，这样比反复强调“严格遵循”管用得多。另外，“过度自信”这个问题其实可以靠给Agent加一个不确定就抛异常的开关来解决，让它遇到命名冲突或逻辑删减时主动中断并追问，而不是闷头生成，这个在Claude的tool use里是可以实现的。工具的话，我觉得你换不换不是重点，因为自建工作流本身可塑性最强，倒是可以试试在每次生成后自动跑一遍diff，用脚本检查Bean命名和XML里原有的id做比对，有差异就强制回滚——把AI当实习生管，别当架构师用。最后想问下，你喂给它的项目结构文档是纯文本还是有带注释的代码示例？我怀疑它“自作主张”是因为例子太少，导致它只能靠“合理猜测”来补全细节。

这问题我熟，老项目迁移建议换成Aider或者Cursor的agent模式，对代码库上下文控制更细，能锁死改动范围。

说实话你这个问题我太有同感了，之前我用Agent重构一个支付模块的时候也差点被它气死，明明喂了详细的规范文档，它还是能给你整出些“创新性”的Bean命名。我觉得你遇到的本质上是Agent在长上下文里的“意图漂移”，它开头还记得你的约束，但越到后面越容易把注意力放在局部代码生成上，而忘了全局一致性。就我的经验来说，提示词工程能解决一部分问题，但别指望它能彻底搞定，除非你用非常强制的结构化输出，比如让它每个文件都先写一段“本文件遵循的规则清单”再动手，否则它还是会放飞自我。

工具方面我建议你试试看那些有“静态分析”能力的Agent，比如Cursor或者Aider配合ESLint/Checkstyle这类检查器，它们能在生成后自动跑一遍规则，不符合的就直接打回重写，这样比纯靠对话约束靠谱得多。另外我还有个土办法，就是每次让它改一个文件前，你把原文件里几个关键方法的签名和注释直接粘给它，让它先“复述”一遍再改，这样能强行把它的注意力拉回你的风格上。最后想说，兼容性风险那块，你可以在工作流里加一道“人工审批节点”，让Agent把改动里所有涉及删除或重命名的部分单独列出来，你确认后才允许它继续，这比事后翻代码找问题省心多了。

说实话你这个问题我踩过一模一样的坑，核心不是提示词，而是Agent的“目标感”太强了。它天生就倾向于“完成重构”而不是“保持原样”，所以你得把约束条件变成硬性检查，比如让它在每个文件改完后自动diff对比逻辑差异。

我后来换了个思路，把迁移规范拆成子任务，每个Bean单独一个Agent处理，并且强制它先输出“改动风险清单”再动代码，敢自作主张就回滚。工具的话，试试Cursor或者Aider那种带git感知的，至少能让你看清楚每一步改了啥。

另外有个小技巧，别把整个项目文档喂进去，信息太多它反而会抓不住重点，只给当前模块的上下文反而更稳。我猜你那个“过度自信”是模型温度调太高了，调低点会好很多。

这问题我太有同感了，Claude在代码库级重构上确实容易“自由发挥”，尤其老项目里那些隐式约定它根本抓不住。你试试把迁移规范压缩成一条条硬性检查清单，比如“禁止改bean名”“必须保留兼容性注释”，让它每改一步先对照清单自检，比单靠系统提示管用。工具的话，Cursor或Aider对项目上下文的理解更细，但本质上还是得靠你把“边界”定义死——AI一旦觉得有“优化空间”就会手痒，这毛病得靠约束喂出来。

老项目重构还是把约束写成代码规范文件喂给它，光靠系统提示确实压不住它的“创作欲”。

说实话你这个场景我太有同感了，之前我用Agent迁移一个老项目的依赖注入方式，也遇到过它把命名风格“优化”得面目全非的情况。我觉得问题不全在提示词，更大程度上是工具对“代码库级重构”的理解还不够深，尤其是当你的项目有隐性约定时，它很难从文档里真正吸收那些“不可言说”的规则。你可以试试把迁移规范拆成更细的checklist，比如每条规则对应一个具体的代码示例和反例，然后让Agent在每一步都对照这些示例输出，而不是只给一个宏观的“遵循风格”指令。另外，工作流上可以考虑加一个“确认闸门”，比如强制它在改动某个Bean命名前先输出一个变更清单，让你确认后再继续，这样能逼它暴露不确定性。至于工具，Claude本身能力是够的，但自建工作流如果缺少对项目历史的感知，换哪个模型都可能跑偏，关键是得给它一个“有限动作空间”。我最近试了在Agent里加一个“只允许修改指定文件”的约束，配合一个自动diff回滚机制，效果比单纯改提示词稳定得多，你可以试试。

说实话这种老项目迁移场景我踩过类似的坑，Claude在代码生成上确实容易“脑补”，尤其面对Spring XML这种隐式规约时。建议你试试把关键Bean定义直接写成代码片段塞进上下文，而不是只给文档，让它照着填空而不是自由发挥。另外工具上可以看看Aider或Cursor的Agent模式，它们对仓库上下文的管理更严格，能减少这种自作主张的情况。还有个小技巧，在提示词里加一条“遇到不确定的地方必须输出TODO注释并停止”，比单纯强调风格管用得多。

说实话这情况我也踩过坑，Claude确实容易在重构时“发挥过头”。后来我改用两步走：先让它只输出迁移计划，明确列出改动点，批准后再动代码，效果好了不少。另外工具上可以试试Aider或者Cursor的agent模式，它们对项目结构的感知更准，不太会乱改命名。还有个土办法，把关键Bean的名字和逻辑写进一个单独的“禁止改动清单”文档，每次对话都带上，比在系统提示里抽象强调“保持风格”管用多了。

试试先把每个Bean的改动拆成独立小任务，一次只让它改一个，跑通再下一个，约束效果立竿见影。

我觉得是工具问题，这种老项目重构得用专门做代码迁移的，Claude还是偏生成新代码。

说实话这问题我太有同感了，之前用类似工具做过一个老模块改造，也是被它那套“自作聪明”整得没脾气。后来我发现光靠提示词压不住它，干脆把每次要改的XML片段和对应Java Config结构直接贴进上下文，还限定它“只翻译、别重构”，效果比写一堆规范强多了。你那个Bean命名被改的问题，我猜是Agent从你文档里提取了隐含规则，不如试试禁用它的长期记忆，每次对话都只基于当前输入生成。工具方面我觉得Claude本身没太大毛病，关键是别让它一次性看太多文件，拆成小任务一个个过，它反而老实很多。

这问题我熟，老项目重构建议把关键Bean定义直接写成few-shot示例喂进去，比强调风格管用。

工具换不换另说，但“过度自信”是真无解，得靠你把验收步骤拆细，分步让它确认。

说实话你这情况我也踩过坑，Claude写小段代码还行，一放到老项目里就爱自由发挥。后来我试了把迁移规范拆成几个独立的小任务，每个任务只给对应模块的代码片段，别一次性全塞给它，跑偏概率低很多。另外你可以试试在提示词里加一句“禁止修改未明确指出的部分”，比强调风格管用。工具的话，我觉得不是换不换的问题，而是这种大重构最好分步盯着改，别指望一次搞定。

这种老项目迁移我太有同感了，Agent对“优化”的执念真的拦不住。你试试把每个Bean的原始定义和依赖关系单独拆成小任务喂给它，别让它一次看全量文档，上下文越聚焦它越容易克制住发挥欲。另外工具倒是其次，关键是在工作流里加一道“只输出diff不直接改文件”的强制步骤，让它先说明改动理由，你点头了再落地。我上次用类似办法管住过它乱改命名的问题，你可以试试。

说实话你这个场景我太有共鸣了，老项目重构最怕的就是AI“自作聪明”。我觉得问题不全在提示词，Claude本身的性格就是偏向“合理猜测”而不是“保守确认”，你喂再多规范它也会在细节上自由发挥，这跟工具选型关系不大。我自己试过用Cursor加特定规则文件，效果其实也差不多，关键还是得在流程上设卡子。比如你可以试试把迁移拆成小批次，每次只让它改一个模块，然后强制它输出“改动清单+风险点”再让你确认，别让它一口气生成完整代码。另外有个土办法挺管用，就是在系统提示里加一句“如果遇到不确定的地方，必须用TODO标记并停止生成”，配合代码评审的步骤，能逼它暴露犹豫点。其实我觉得这种代码库级重构，现阶段AI更适合当辅助，你心里得有完整的迁移地图，它只是帮你执行机械部分，别指望它自己把握兼容性的边界。

说实话这情况我太熟了，Claude写单点功能挺强，但做代码库级重构确实容易放飞自我。你试试把每个Bean的原始定义和对应新配置写成逐条对照的checklist喂给它，比笼统的规范文档管用得多。还有就是别让它一口气重构完，拆成几十个小任务逐个确认，跑偏了也好定位。工具我倒觉得不用换，主要得靠工作流把它的自由度锁死。

这题我熟，老项目迁移别指望一次喂完，把迁移规范拆成小任务分步盯，比换工具管用。

试过给Claude加个“先列改动清单再动手”的强制步骤，跑偏率能降一半，你可以试试。

说实话你这个场景我太有共鸣了，Claude写单文件代码确实强，但一涉及跨文件约束就特别容易放飞自我。我感觉问题不一定全在提示词，Agent工作流里缺少一个“校验闭环”是挺致命的，比如让它每改完一个模块就强制对照原项目跑一遍diff，把改动点列出来让你确认，比单纯强调风格管用得多。工具方面我倒觉得不用急着换，试试把迁移规范拆成更细的、可验证的checklist喂给系统，而不是一段笼统的“保持原有风格”，它会老实很多。另外我好奇你喂的文档里有没有包含具体的反例，比如“不能把xxx改成xxx”，这招对我这边的模型挺有效的。