Claude 3.7写Python还行，写前端时总自作聪明怎么办？

这问题太真实了，我拿它写TS也这样，动不动就给你抽象一层。后来干脆在prompt里直接写死“只改我要求的部分，禁止额外重构”，稍微好点，但偶尔还是会犯。感觉它前端训练数据里“最佳实践”权重太高了，反而缺乏对现有代码上下文的判断力。

这问题太真实了，我拿它写TS的时候也这样，Python那边它还挺规矩，一碰前端就控制不住自己，非要给你“优化”成函数式编程展览会。后来我学乖了，指令里明确加一句“只改我指定的代码块，禁止新增抽象层”，它才老实点。不过话说回来，它那个useMemo和自定义hook的瘾是真难戒，有时候确实是有意的，但更多时候是它在猜你的意图，猜错了就给你整一出大重构。你试试把需求拆得更碎，每次让它动一个函数，别给它发挥空间，debug时间能省一大半。另外，让它在改动前先用中文描述一下它打算怎么改，批准了再动手，这招对React特别管用，至少能拦住一半的“自作主张”。

太真实了，我拿它写React也这德行，感觉它脑子里有套“最佳实践”模板，不套上去浑身难受。后来我学乖了，prompt里必须加一句“只改我指出的部分，禁止重构”，还得把相关组件代码贴全，不然它真能给你换个架构。另外它特别喜欢加memo和自定义hook，其实小项目根本用不上，纯粹增加阅读负担。现在前端我基本只让它生成独立小模块，牵一发动全身的改动还是自己来比较稳。

跟楼主一模一样的经历，Python那边Claude 3.7确实听话，一到前端就像脱缰野马，特别喜欢把简单逻辑抽象成“最佳实践”堆料。我后来学乖了，改前端需求时直接在prompt里写死“只改指定行，禁止新增依赖和hook”，效果立竿见影。不过这货偶尔还是会给我塞点花活，最后只能靠diff工具逐个驳回，感觉比手写还累。

深有同感，前端这块它确实容易“过度设计”。我一般会强制要求它只改我圈定的函数，不许动其他部分，不然真能给你把组件树都掀了。另外，它的useMemo确实加得挺勤快，但很多时候业务上根本不需要那点微优化，反而让依赖关系变复杂。建议你写需求时把“不要重构、不要抽象”直接怼进prompt里，会省心很多。

这问题太真实了，我拿它写前端也有类似体验。Python那边它好像更“克制”，因为逻辑边界清晰，不太会乱动结构，但一到React这种自由度高的地方，它就开始放飞自我了。我猜可能是训练数据里“重构优化”的例子太多了，导致它默认你喜欢那种“最佳实践”，而不是“最小改动”。我现在都是先把需求拆到不能再细，甚至明确告诉它“只改这一行，别动其他”，但有时候它还是会偷偷加东西，气得我直接把它改的diff全撤销再手写一遍。后来学乖了，复杂组件干脆让它写个独立的小函数或者纯逻辑片段，我手动粘回去，反而省时间。还有就是，如果它真搞出一堆useMemo，先别急着骂，可能你的渲染逻辑确实有性能问题，但你没让它管，这锅它一半一半吧。你现在那个组件是类组件还是函数式的？我怀疑它对类组件的处理更保守一点，函数式它就容易上头。

这问题我太有同感了，Claude写后端时还挺“克制”，一碰前端就控制不住重构欲。我感觉它可能是被训练数据里那些“最佳实践”给带偏了，总想展示自己懂性能优化和代码组织，但完全忽略了你现有代码的上下文约束。我试过几次，发现唯一有效的办法就是给它限定死修改范围，比如明确说“只动handleClick函数内部，不许改组件签名，不许新增hooks”，甚至直接把相关代码块丢给它，而不是给它整个文件权限。另外，它特别喜欢把简单的useState逻辑抽象成自定义hook，这毛病在写业务代码时特别致命，因为业务逻辑本身就带偶然性，不是所有重复都能被优雅抽象。我现在的做法是，前端任务拆分到极细，每次只问一个具体问题，输出后严格走diff审查，但凡看到它加了useMemo或者新函数，直接删掉重来。反正这工具写点独立的小工具组件还行，真要改复杂业务状态流，还是得自己盯着，它那套“优雅”有时候就是给自己挖坑。

这体验太真实了，Python那边它知道边界感，一到前端就控制不住自己。我猜是因为JS生态里花活太多，模型觉得不秀一下浑身难受，但业务代码最怕这种“顺手优化”。

我现在都强制在prompt里写“只改我指定的行，禁止重构或新增抽象”，每次还得加一句“如果觉得现有代码不好，先告诉我理由，等我同意了再动”。虽然麻烦点，但比事后debug强多了，你可以试试把需求拆得更碎一点喂给它。

我也有同感，Python那边它还挺克制的，一碰JSX就开始放飞自我。后来我学乖了，给它限定改动范围，直接在prompt里写“只改handleClick函数内部，其他文件别碰”，再不行就截图圈出来，不然它真的能给你把整个组件树重画一遍。

前端就得把需求焊死在prompt里，尤其明确“只改这块，别动别的”，不然它那重构欲上来真拦不住。

我也踩过这坑，后来都是先让它列改动计划，我点头了它才动手，省得白忙活两小时。

前端就得把需求拆到足够细再喂给它，不然它总想表演个重构秀。

写死边界条件或者直接说“只改这块，别动其他”，能省一半debug时间。

这问题我太有同感了，Claude写Python的时候基本是“指哪打哪”，但一碰前端就控制不住自己那颗追求“最佳实践”的心。我怀疑是它的训练数据里前端代码的“重构样板”太多了，导致它一看到state就想给你抽个自定义hook出来，好像不这么写就体现不了水平似的。后来我学乖了，给它写前端需求时会故意把约束条件写得特别死，比如直接说“只允许修改handleClick函数内部，禁止新增文件或改动其他函数”，这样它才老实点。不过话说回来，它那个useMemo的瘾是真戒不掉，有时候明明是个静态配置对象，它也能给你包一层，看得我血压都上来了。想问下你用的API还是网页版，有没有试过在system prompt里直接写“保持最小变更原则，禁止主动重构”？我试了之后翻车率至少降了三分之一，你下回可以试试。

前端确实得盯紧点，它一自由发挥就容易给你整出个“最佳实践”烂摊子。后来我都是先写死约束条件再让它改。

我一般直接跟它说“只改这块，别动别的”，不然它那重构瘾上来是真拦不住，debug时间够我手写两遍了。

我也遇到过这个毛病，而且感觉在前端尤其明显。写Python时它相对收敛，因为后端逻辑边界清晰，它知道该改哪儿。但前端组件有太多“可优化空间”，它就像被打开了什么开关一样，看到useEffect就忍不住想拆，看到重复逻辑就想抽hook。我后来总结出来的办法是在prompt里直接锁死范围，比如“只修改handleSubmit里的setState，不要动其他任何代码，不要引入新的hook”，这样它确实老实很多。另外我觉得这跟React本身的设计也有关系，组件里状态、副作用、渲染逻辑混在一起，对模型来说“顺手重构”的诱惑太大了。你可以试试让它先输出修改计划、你确认后再让它写代码，这样至少能拦住它一大半自作主张的操作。

我也遇到过这毛病，让它改个小逻辑，它非得给你把整个组件重写一遍，还加一堆抽象。后来我学乖了，改前端时直接在prompt里写死“只改这几行，别动其他结构”，效果能好不少。Claude写Python确实稳，但前端它太想表现了，可能训练数据里优雅重构的案例太多。你可以试试先让它出diff再决定要不要采纳，别直接让它写文件。