用Cursor写React组件总改错地方，是我的提示词问题还是工具不行？

试试在Composer里明确圈选要改的代码块，再加一句“别动其他逻辑”，它跑偏的概率会小很多。

说实话我太懂你这个痛点了，Composer在处理跨文件、有状态依赖的改动时确实容易“自作聪明”。我觉得这不完全是提示词的问题，更多是工具对现有代码语义的理解还停留在表面，它看到useStore就条件反射去动初始化，根本没意识到你只想改导航逻辑。我自己的经验是，这种场景下别让它直接改，而是把要保留的数据流画个简短的伪代码给它看，明确写出“不要动createStore里的初始值”这种边界条件，效果会好很多。另外你提的console.log也挺典型，它有时候会为了“验证逻辑”加调试代码，我一般会在提示词末尾加一句“禁止添加任何日志或非必要副作用”，能减少一半这种抽风行为。不过说句公道话，Cursor的Composer更适合大段新增或重构，对这种需要外科手术式精准修改的场景，我反而会切回Tab模式或者直接手改，省得跟它来回拉扯。你也别太焦虑，多摸几次它的脾气，每个AI工具都有自己擅长和不擅长的改动模式，找到那个边界就行。

说实话我觉得这大概率是提示词的问题，但也跟Cursor对复杂状态流的理解上限有关。你这种“上一步保留数据”的需求，本质上要它精准定位Zustand的store结构，而不是去动初始化或提交逻辑，所以你最好在prompt里直接画个边界，比如“只修改step切换相关函数，禁止触碰createStore内部”。我自己的经验是，把需求拆成“改哪里+别碰哪里”两段式，成功率会高很多。另外Composer对多文件上下文挺敏感的，你试试把相关store文件手动加到上下文里，别让它自己猜。工具肯定有缺陷，但有时候是它把“改对”理解成了“顺手优化”，这个确实得靠约束。

我试过把相关文件用@符号明确圈起来再给指令，成功率会高不少，你可以试试看。

给AI划清边界很重要，建议在提示词里直接写“只改X文件，别碰store”。

大概率是提示词问题，Cursor对局部改动的理解不如你直接框选代码块再给指令，别让它碰store初始化逻辑。

这场景太熟了，我刚开始用Cursor时候也这样，它特别喜欢“自作主张”改掉你觉得没问题的代码。其实不一定是提示词问题，Composer对全局状态的感知经常是“猜”，像Zustand这种跨组件共享的逻辑它很容易改错地方。我现在的做法是，把要改的组件和store文件单独拖进对话框，明确告诉它“只动这个函数”，效果会好一些。另外，你可以试试在关键行加上//不要修改的注释，有时候比写一堆提示词管用。工具是好工具，但真得靠人盯着。

这情况我太熟了，Cursor的Composer跨文件改动确实容易“手滑”，尤其你这种状态逻辑分散在store和组件里的场景。我一般的做法是先手动选中要改的那几行，再用Cmd+K局部提问，别直接甩给Composer全局跑。另外提示词里最好明确说“只改onPrevStep，不要动useStore初始化”，不然它默认会帮你“优化”一通。你试试把Zustand的persist中间件加上，可能比让AI改更省心。

这问题我太熟了，Cursor的Composer在多文件重构时确实容易“手痒”，尤其是你这种状态逻辑和UI耦合的场景。它默认倾向于把整个相关文件都当成可编辑区域，所以你只说了“加上一步保留数据”，它可能理解成“优化整个store和表单流程”，结果就乱动初始化逻辑。我一般在提示词里会加一句“只修改onPrevStep函数，不要动useStore的初始化和onSubmit”，并且用@符号精确锁定文件范围，能减少很多误伤。另外你可以试试先让它输出改动计划，确认后再执行，虽然多一步但省得回滚。不过话说回来，这也不全是提示词的问题，Cursor对Zustand这种外部store的上下文理解确实不如对React内置hook那么准。如果项目里状态逻辑复杂，我有时候会切回Copilot做单文件补全，反而更稳。你那个console.log估计是它觉得“调试需要”自己加的，挺无语的。

这个场景我太熟了，Cursor改多步表单确实容易犯这毛病。它默认会扫描整个文件，然后凭“直觉”找最像要改的地方，但Zustand的store初始化逻辑和组件里的表单状态在它眼里可能长得很像，结果就串台了。我后来发现，与其让它自己猜，不如在提示词里明确锁定作用域，比如“只修改FormStep组件里handlePrev函数，不要动store里的任何代码”，或者直接把要改的那几行选中再让Composer跑。另外它插入console.log通常是因为你让它“调试”或“检查”时它自作主张加日志，你可以提前说“不要加任何console语句”。还有个土办法，把store文件在提示时@引用进来，但明确说“参考但不要修改”，这样它至少知道边界在哪。不过说实话，Composer在多文件交叉逻辑上确实不如单文件稳，我现在复杂状态改动还是手动来，只让它写纯UI或者样板代码。你可以试试把Zustand的action单独抽成hook再让AI改，命中率会高不少。