Claude 3.5 Sonnet写前端总改错文件，是我prompt姿势不对吗？

这问题我也踩过坑，后来发现把文件路径写进prompt还不够，得连关键函数名或者独特样式类名一起带上，比如“只动Button里那个primary variant的样式”，这样它跑偏概率会低很多。另外建议每次对话只让它改一个文件，改动前先让它用diff格式输出，确认了再落地，git能少受不少罪。其实这模型对跨文件上下文确实容易犯迷糊，把它当个需要紧盯的实习生就对了。

同感，这问题我踩过好几次坑。后来我学乖了，不再只写文件名，而是直接在代码块里贴出要改的那段原始代码，然后说“只动这个函数里的逻辑”，效果立竿见影。另外，你试试在改动前先让它用一句话复述一遍自己的任务，跑偏率能降不少。

把目标代码片段直接贴进prompt里，比只给文件路径管用得多，我试过有效。

我都是让它先找到对应行号再改，或者干脆把那段代码复制给它，基本不会跑偏。

我一般直接把文件路径和要改的行号一起贴进去，它跑偏的概率就低很多，你可以试试。

这问题我太有同感了，Claude对“文件边界”的感知确实比较弱，特别是当同名className在多个文件里出现时，它容易按全局语义去理解。我的笨办法是把目标代码段直接贴进prompt，然后说“只改这段，别动其他”，比只给路径管用得多。另外，如果你用Cursor或者VS Code插件，试试用“/codebase”或者选中代码再让AI改，它能更准地锁定上下文，git diff疯掉的情况会少很多。

这个我太有同感了，之前用Claude改一个多页面的Next项目也是这德行，明明指定了路径它还是给我来个全局替换。后来我琢磨出一个办法，就是每次让它改代码前，先把目标文件的核心代码段粘进prompt里，再明确说“基于这段代码做修改，其他文件一律不动”，效果会好很多。另外我发现它特别容易被同类className误导，所以现在写组件时都会特意用带前缀的类名，比如btn-primary这种，减少歧义。还有个小技巧，如果改动比较大，我会让它先输出diff格式的修改建议，而不是直接生成整个文件，这样我能控制它到底动了哪里。说到底，这工具对文件级别的上下文确实有短板，特别是当项目文件多了以后，它的注意力容易漂移，所以把范围缩得越小越具体，它就越老实。你试试把要改的代码块原样贴给它，而不是只给个文件路径，应该能少踩很多坑。

这个问题我也踩过坑，后来发现光写文件路径不够，得在prompt里强调“基于现有代码做增量修改，不要新增文件”，最好把目标组件的关键代码片段贴进去，再配上具体的修改描述，它会老实很多。另外试试让它先列个改动计划再动手，能减少不少随机行为。

试试把目标代码片段直接贴进prompt里，再强调“只改这段”，比只给文件路径管用多了。

我一般会让它先列出改动计划确认后再动手，能少一半回滚的麻烦。

这个问题我太有同感了，之前用Claude改一个多页面的老项目时，它也经常把同名class全给我换了，后来我发现单纯写“只改某文件”不够，得把目标代码段的具体特征贴进去，比如那段JSX的上一行注释或者某个独特的props组合，它才能锁死位置。另外我怀疑这跟它内部把整个对话历史都当上下文有关系，文件路径只是它“参考”的一部分，不是硬约束，所以它觉得全局替换更“符合逻辑”。我现在的土办法是，每次改完一个小地方就立刻复制新代码存到本地，然后跟它说“基于这个最新版本继续”，相当于给它一个实时的锚点。还有个技巧是，如果改动复杂，宁可我先把相关代码复制到新对话里让它重写，也别在长对话里反复改，上下文越长它越容易自作主张。你可以试试把Button.tsx的完整代码贴出来，在开头加一句“以下文件是唯一允许编辑的对象，其他文件一律视为只读”，比路径描述管用很多。

这问题我也踩过坑，后来发现关键不是强调“哪个文件”，而是直接把目标代码块贴进prompt里，让它基于现有内容改，而不是靠路径猜。另外你可以试试让它先描述一遍它理解的改动范围再动手，跑偏概率会小很多。还有个土办法，把不相关的文件在对话里标记为“只读”，能减少不少误操作。

这问题我也踩过坑，后来发现关键不是“只改哪个文件”，而是让它“别动其他任何文件”。我会在prompt里加一句“如果发现改动涉及其他文件，先停下来问我”，效果好了不少。另外你试试把目标代码段直接粘进对话里，让它基于片段改而不是靠记忆，跑偏概率会低很多。

这问题我也踩过坑，后来发现把文件路径写进prompt还不够，最好在代码块里把要改的那段原样贴出来，再明确说“只改这段，其他别动”。另外试试让它先列出改动计划再动手，能拦住大部分跑偏。还有个土办法，让它改完直接输出完整文件内容，你本地比对替换，虽然麻烦点但基本不会错。

这问题我也踩过坑，特别是项目里同名className多的时候，它真的会按“语义相似度”乱来。后来我干脆把目标文件路径放在prompt开头，再贴一段当前组件代码，并且明确说“只改这段代码块，其他文件一律不动”，跑偏率低了很多。另外可以试试让它先输出改动计划再动手，自己确认下范围，虽然多一步但比回滚省心。

你要是用的是编辑器插件，看看有没有“仅当前文件”的权限设置，有时候是工具默认给了全仓库的写权限，限制了会更稳。

这问题我也踩过坑，后来发现光说“只改Button.tsx”不够，得把目标代码段直接贴进prompt里，让它基于你给的具体内容改，而不是靠它自己回忆。另外可以试试让它先输出完整文件再让你替换，别让它做局部diff，这样跑偏概率会小很多。还有就是git提交前养成习惯先看一眼diff，别全盘接受AI的改动，尤其同名className这种坑，我都是靠全局搜索确认才放心。