Copilot和Cursor都用过了，还是经常改出一堆bug，是我的姿势不对吗？

说实话你这个情况太真实了，我自己也是从“无脑信任”到“当它是个高级自动补全”过来的。核心问题在于AI对全局状态的理解永远是片面的，尤其订单这种有并发和事务的东西，它根本不知道你脑子里那套隐式约定。我现在的基本操作是把边界条件写进注释里，比如“这里可能被两个请求同时触发”或者“异常必须抛给上层”，它至少不会乱吞了，但复杂重构我还是自己搭骨架，让AI填肉。调教这东西真没玄学，就是拿它当个极其聪明但完全不懂业务的实习生，你得把需求拆到它不需要“理解”的程度才靠谱。

这类需要全局状态流转的改动，AI现在确实容易想当然，我都是让它出方案框架，细节自己填。

把大重构拆成十几个小步骤，每步都让AI写单测验证，比写注释管用多了。

这类全局重构还是得自己把控，AI当个高级补全工具用就行，别指望它理解业务。

你把状态机拆成纯函数喂给它，改起来会稳很多，但边界条件还是得自己盯。

全局理解这块AI确实短板，我一般只让它写单点函数，状态流转还是自己手撸靠谱。

这种全局重构的活儿AI确实容易露怯，你不如把并发和异常处理先写死成TODO再让它补。

说白了它就是个高级补全工具，别指望它懂业务，能帮你少敲点样板代码就值回票价了。

说实话你这个情况太典型了，我一开始也是这么被坑过来的。后来我发现关键不在于注释写得有多细，而是得把AI当刚入职的实习生用——你得把“不要做什么”和“必须保留什么约束”直接写进提示词里，比如“这段逻辑必须保持幂等”或者“别动异步回调的顺序”，光说“改订单流程”它当然会自由发挥。

还有个我试了挺管用的招：把改动的范围强行锁死。先跟它说清楚“只改这个函数内部，接口签名和外部调用一概不许动”，再让它先输出一份改动计划给你确认，而不是直接给代码。这能逼着它先展示它理解的全局状态长什么样，你一看就知道它有没有误解边界条件。

另外对于状态机或者并发这种重灾区，我基本不指望AI一次写对，但我会让它先写几个针对性的测试用例，比如模拟两个订单同时更新，然后我再跑测试看它自己写的断言能不能过。这比让它直接改代码要靠谱得多，也省得你花半小时人肉review它生成的异常吞噬逻辑。

说到底，现阶段AI对“全局心智模型”的理解确实很弱，尤其业务逻辑跨度大时它就是靠统计模式猜。我的经验是：让它干局部重构、加日志、写单元测试这类活效率很高；但涉及跨模块的状态流转，最好还是你先把关键路径在注释里画个简图，甚至用伪代码把状态迁移条件写死，再让它翻译成实现。

我自己现在的流程是：Copilot负责快速补全和写样板，Cursor负责多文件检索和改简单bug，但真正动核心业务逻辑前，我会先自己把流程图在脑子里过一遍，再分步骤喂给AI，改一步验证一步。你说拆小函数效果不稳定，可能因为拆的粒度还不够小，或者没告诉它每个小函数的前置条件和输出约束。

最后想问你一下，你试过让AI先解释它对你现有订单流程的理解吗？比如让它用自然语言复述一遍“当用户取消订单时，如果支付已发起但未回调，应该怎么处理”——很多时候它复述出来的逻辑就已经漏了状态，这时候你直接纠正它的描述，比改代码要高效得多。

这类全局状态流转AI现在真hold不住，我都是让它写单测把边界堵住，逻辑自己来。

AI适合当高级补全，别让它主导重构，把大改动拆成小步验证能稳很多。

说实话你这情况太典型了，我怀疑不是你的姿势问题，而是AI对“状态”这种东西压根没建立真正的心理模型。它擅长的是模式匹配，不是因果推理，所以重构有并发和异常处理的逻辑时，它很容易拿训练数据里的“常见写法”硬套，边界条件当然就丢了。我自己的经验是，别指望它一步到位，而是把它当成一个“超级自动补全器”——你先手动把关键的状态机、锁、异常分支用伪代码或者注释钉死，再让它填充具体实现，这样成功率会高不少。另外，拆小函数确实有用，但得拆到那种“单个函数只做一件无状态的事”才算数，不然它还是会自作聪明。还有一个野路子，就是故意在提示词里写“这里有个坑，之前有人忘了处理XX”，它反而会警惕起来。但说实话，涉及多个模块交互的大改动，现阶段我基本自己动手，只让它写测试用例来帮我验证边界，我觉得这样更靠谱。

这问题我也遇到过，后来发现把验收条件直接写进注释里比描述意图管用，但复杂重构还是得自己兜底。

这种带状态和并发的重构，AI确实容易翻车，因为它看不到你项目里那些隐式的约定和全局状态流转。我的经验是别让它直接改，先让它把现有逻辑逐行解释一遍，确认它真读懂了再动手，往往这时候它自己就能发现漏掉的边界。另外改完立刻让它生成针对并发和异常路径的测试用例，跑不过就说明它又在“自信”了。指望它独立搞定全局改动目前还不太现实，但当成一个需要反复对齐的结对伙伴，效率还是能提不少的。

这问题太真实了，我前段时间重构一个支付回调的状态机也是被坑得够呛。后来慢慢摸索出一个感觉还行的做法：别让AI直接改逻辑，先让它把现有代码的边界条件和状态流转给我列出来，我确认一遍再让它动手。因为AI缺的往往不是写代码能力，而是对你这个业务里"什么情况算异常"的默契。像并发状态这种，你可以在prompt里明确写出"这段代码运行在多线程环境下，任何状态变更前必须校验版本号，校验失败抛特定异常"，它才会当回事，不然它默认走happy path。另外我习惯让它一次只改一个函数，改完立刻跑测试，崩了马上回滚，别攒着一大坨再调。还有个偏方是让它先写测试再写实现，虽然它写的测试也未必靠谱，但至少能逼它把边界想一遍。全局理解那种大改动我现在基本不指望它一把过，都是自己拆好步骤当监工。

改业务逻辑别指望它一把过，先让它写测试用例把边界卡死，再改代码会稳很多。

改业务逻辑别让AI自由发挥，先让它把边界条件和状态迁移列出来，你确认完再写代码。

我现在的做法是让AI先别写代码，先让它把改动涉及的边界条件列出来，比如并发下订单状态怎么流转、异常在哪一层兜底，我确认完再让它动手。直接让它改逻辑，它确实容易挑最顺的那条路径写，边界全靠你自己补。另外重构订单这种带状态的，我一般会先写几个失败用例丢给它，让它照着用例改，比光靠注释稳不少。

这问题真不怪你，AI改业务逻辑就是容易翻车，尤其涉及状态机和并发的时候。我的经验是别让它直接改，先让它把现有逻辑和边界条件列出来，你确认没问题了再让它写。另外可以试试先写测试用例，把并发和异常场景喂给它，让它照着测试写实现，比空口描述靠谱多了。全局重构这种活，现阶段还是得自己把控核心逻辑，AI打下手比较稳。

这种带状态和并发的业务重构，我一般不让AI直接改主流程，而是让它先写测试用例把边界条件列出来。你描述再详细，它也很难脑补出你没说出口的约束，不如反过来用测试当“需求说明书”喂给它。另外Cursor里可以先用@Codebase让它把相关文件和调用链读一遍再动手，比单文件补全靠谱不少。全局理解的活现阶段还是得自己拆好步骤，AI适合当执行者而不是架构师。

这个真不是姿势问题，我折腾了半年多也有同感。现在AI写代码本质上是“局部模式匹配”，你让它补个函数、写个工具类很顺，但一旦涉及跨文件的状态流转和并发边界，它脑子里没有真正的运行时模型，全靠上下文猜。我后来摸索出一个办法：别让它直接改，先让它把改动点、影响范围、可能的边界情况列出来，你确认完再让它按你的思路写。这样虽然多一轮对话，但踩坑少很多。另外我习惯把关键约束写成测试用例先扔给它，让它照着测试写实现，比纯注释靠谱。Cursor的composer模式也建议配合rules文件，把项目里的异常处理规范、状态机约定写死进去，能减少不少“自信但错误”的输出。不过说到底，涉及核心业务逻辑的改动，我现在还是自己动手，AI顶多帮我看看有没有漏掉的case。指望它做全局重构，目前确实不太现实。

改业务逻辑还是得自己先理清状态机，AI补全单点还行，全局重构现阶段真指望不上。

AI擅长写孤立函数，全局状态流转还得自己盯，我一般只让它出草稿，边界和异常手动补。