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

全局理解确实还不行，我都是让它写单点逻辑再自己拼装，别指望一步到位。

这类状态机还是得自己画清楚再喂给它，当高级补全工具用就对了。

说实话你这情况太正常了，我之前重构一个异步任务队列也是被它坑惨了，后来发现关键不是把注释写多细，而是得把状态机、异常分支这些约束直接写成单元测试塞给它看。AI对全局上下文的理解还是弱，它更像高级补全而不是架构师，所以复杂逻辑我基本只让它生成纯函数或者数据转换部分，带状态流的还是自己画清楚再让它填肉。你试试把“不要吞异常”这种硬规则写进项目里的AGENTS.md，再配合每次改完强制跑diff review，效果会稳定不少。

说实话你这个问题我太有同感了，Copilot和Cursor我换着用半年了，感觉它们对“局部补全”很在行，但一碰全局状态流转就露馅，尤其订单这种带并发和回滚的，AI根本意识不到边界条件的存在。
我现在的做法是让它只生成纯函数和独立模块，凡涉及状态变更的核心逻辑必须自己手写，AI只当高级自动补全用。
另外你试过把改动的验收标准直接写进注释里吗？比如明确“这里必须抛异常”或者“并发时用乐观锁”，比单纯描述意图管用很多。
说到底，我觉得现阶段AI更适合当结对编程的“实习生”，能快速出草稿，但代码审查和架构决策还是得靠人，别指望它理解业务全貌。
你要是找到更系统的调教方法，记得回来分享啊，我这边还在跟各种隐性bug搏斗中。

全局理解这块AI确实还弱，尤其状态机这种得靠人肉盯。

我一般是让它生成骨架，边界条件自己补，别指望一步到位。

这问题太真实了，全局状态流转AI根本理解不了，我最后都是让它写单点函数，自己拼流程。

说实话我也遇到过一模一样的情况，后来发现核心问题不是姿势，而是得把AI当成一个特别聪明但没上下文的实习生。我的做法是先把改动涉及的状态流转和边界条件用注释写清楚，甚至把对应的测试用例先贴给它，这样它生成代码时至少会照着约束走。但涉及全局状态管理的重构，我基本还是自己动手，让AI只做局部替换或者帮我写单元测试，指望它一步到位确实不现实。

另外你试试把任务拆到“一个函数只做一件事”的粒度，然后每个函数单独让AI生成，再自己拼起来，成功率会高很多，但确实累人。说到底现阶段AI更像高级补全工具，别对它做架构级决策抱太大期望，你越依赖它，它越容易给你挖坑。

说实话你这情况太典型了，我一开始也以为是自己prompt写得不够好，后来发现AI在“局部正确”和“全局一致”之间就是有天然短板。像订单状态机这种牵一发动全身的逻辑，它根本没在“理解”，只是在做概率拼接，边界条件当然经常被吃掉。我的经验是别让它直接重构，而是把大改动拆成“先加测试-再改小步-每步跑通”的流程，AI只负责填具体实现，决策权留在自己手里。另外，你可以试试把关键约束直接写进代码注释里，比如“此函数必须处理并发重复提交”，有时候比在对话里反复强调管用。但说真的，如果业务复杂度上去了，AI现阶段真不如你手写稳，它更像是强力的自动补全，而不是能hold住全局的架构师。我也在等这些工具进化，但短期内还是把它当高级助手用，别当合伙人。

说实话这问题我也踩过坑，后来发现关键是把“改代码”拆成“先让它理解现状，再让它动刀”。我现在的做法是先把相关状态流和边界条件直接贴进对话，甚至画个简单的伪代码流程，然后再让它基于这个上下文改，不然它真就靠猜。另外并发和异常这种，基本还是得自己把关，AI现阶段更像高级补全工具，指望它做全局设计确实不现实。你可以试试让它先写个改动方案，你确认了再动手，比直接生成代码稳很多。

说真的，你这情况太典型了，我也踩过同样的坑。后来发现关键不是把注释写多细，而是得把“状态机”或者“边界条件”直接写进提示词里，比如明确告诉它“这个函数可能被并发调用，需要加锁”，效果会好很多。另外，我习惯让AI先给我出个重构方案大纲，确认逻辑没问题再让它写代码，别一上来就动手改，能少很多返工。

说实话你这情况太典型了，我也踩过同样的坑。现在我的做法是让AI只负责“写不负责“想”，比如把状态机转换条件、异常处理这些硬约束直接写进提示词里，或者干脆给它一个错误用例让它先解释再改。另外可以试试让AI分步骤输出，每步都要求它列出会受影响的调用方，这样能逼它多想想全局。反正纯靠自然语言描述让它理解业务，目前确实不太靠谱，得把它当个高级补全工具用。

这类全局重构AI确实容易翻车，我一般让它出草案，边界条件自己兜底改。

改成“先让AI拆解子任务，再人工审核状态流转”，体感会好很多。

说实话你这情况太常见了，我怀疑问题不在姿势，在于AI本质上是“概率补全机”，对全局状态流转的理解就是弱。我自己的经验是，让它改代码前，先把关键的边界条件直接写在注释里，甚至把错误样例贴进去，比写“详细需求”管用得多。另外，重构这种活儿我基本只让它产出单点函数，然后自己手动拼装，一旦涉及跨模块状态同步，AI现阶段确实不太靠谱。所以别太怀疑自己，这工具当个高级自动补全用就行，指望它扛架构思维还早着呢。

学到了，感谢分享！

说实话你这情况太常见了，我也折腾过一阵子。后来发现关键不是把需求写多细，而是让AI先输出改动方案和风险点，确认边界条件没问题再让它写代码，比直接让它生成靠谱很多。

另外我自己的经验是，涉及状态管理和并发这种，干脆先手动把骨架搭好，只让AI填具体逻辑分支，别指望它自己hold住全局。它更像一个超强的补全工具，而不是架构师。

你要是试过把订单流程拆成纯函数，每个函数只输入输出明确的数据，再让AI改单个函数，效果会稳定不少。说白了，全局理解这块现阶段真得靠人兜底，AI负责把体力活干利索就行。

AI写业务逻辑就像个实习生，给足上下文才能少翻车，全局重构还是得自己把控关键状态。

这类改动建议把边界条件和并发场景直接写进注释里，AI能理解的上下文其实比你想的少得多。

这类全局状态流转AI根本理解不了，你拆小函数反而让它更放飞自我，还是得靠人盯关键路径。

我是觉得现在AI顶多帮你写写胶水代码，订单这种核心逻辑不如自己手写半小时来得踏实。

这类全局状态流转AI确实还理解不了，我都是让它写单点函数，重构自己来。

说白了AI就是个高级补全，别指望它帮你hold住整个订单状态机，拆小步自己盯边界吧。

说实话你这个问题我太有同感了，Copilot补全小工具还行，一到重构状态机这种活，它经常给我编一个根本不存在的变量出来，然后我还得花半小时帮它擦屁股。我后来发现关键不是写多详细的注释，而是把改动的边界条件拆成一个个明确的小断言，让它每一步都只能往一个方向走，不然AI就是会自己脑补。另外你可以试试把旧的完整代码贴进去，明确告诉它“只改这部分，其他别动”，比让它自由发挥稳定不少。目前这类全局理解的活确实还得靠人兜底，AI顶多算个能跑的实习生，别指望它当架构师。

说实话你这个问题我太懂了，之前我也被坑过好几回。后来我发现一个窍门：别让AI直接改整个流程，而是把重构拆成“状态机定义”、“事件分发”、“异常处理”这种独立小步骤，每一步都让它写个带测试的版本再合并。另外，像并发和边界条件这种，我会在prompt里明确给反例，比如“如果用户连续点两次提交按钮会怎样”，这样它踩坑的概率会低很多。目前看，AI更适合做局部修改或生成样板代码，全局性的架构决策还是得自己把关，别太指望它一步到位。

这问题我太有同感了。我之前也是被“AI补全快”迷惑，结果一重构核心模块就翻车，尤其那种跨文件的状态流转，它真能给你编出一个看起来逻辑闭环但实际完全没跑通的状态机。后来我总结出一个土办法，就是别让AI直接改整个函数，而是把重构拆成“读-写-验证”三步，先让它用自然语言描述它理解的当前逻辑，我确认对了再让它动手改某一个小分支，改完立刻跑针对性测试。这样确实稳很多，但代价是时间成本不低，感觉更适合当高级补全工具，而不是“架构师”。另外我怀疑模型对“业务约束”的理解上限就在那，你注释写得再细，它也可能把“用户已登录”这个前置条件当成废话忽略掉。所以现在我的心态是，简单机械的改动放心交给它，但凡牵扯到并发、事务、权限这类“隐式上下文”的，还是自己写骨架更靠谱，AI只用来填充和查漏。你试试把任务拆到半小时内能验证的粒度，可能比写长篇注释有用得多。