用AI编程工具写业务代码，总感觉生成的逻辑不太对，怎么调教？

说实话你说的这个场景我太有同感了，状态机那类逻辑AI基本只能靠猜，我后来干脆把核心状态的流转图直接画成注释丢给它，让它按图写分支，比描述需求靠谱不少。还有就是别让它一口气写完整个方法，拆成小函数一步步喂，每一步都盯着改，最后再缝合，效率反而高些。另外那种死循环和比较反了的问题，我一般会明确告诉它“用Spring的@Scheduled加分布式锁，并且对比当前时间减去超时阈值”，给它限定好实现方向，能少犯一半错。反正我现在的经验就是，CRUD和工具类随便用，但业务核心还是自己搭骨架，让AI填肉比较稳妥。

试试把状态机拆成小函数喂给它，一步一验证，别让它一口气憋大的。复杂流转还是自己写稳当。

说实话你这情况太典型了，AI写CRUD确实顺手，但遇到状态流转这种隐含时序的逻辑，它基本靠猜。我现在的做法是让它先写纯函数，把状态判断拆成一个个小方法，再自己拼装，别指望它一口气搞定整个流程。另外你可以试试把需求里的边界条件直接写成单测用例喂给它，比写注释管用，它跑挂几次自己就改对了。

说实话你遇到的这个死循环和比较符写反，我刚开始用Copilot时也踩过坑，后来基本摸清它的脾气了。这类工具本质是“概率性补全”，它擅长的是从海量代码里找相似模式，但真正的业务状态流转它根本看不见全貌，你给的那点注释对它来说就是提示词，不是领域知识。我的经验是，千万别让它直接生成完整方法，而是把复杂逻辑拆成一个个纯函数，比如“是否超时”单独抽出来，给它明确的输入输出和边界条件，它写对的概率会高很多。至于状态机这种，我基本放弃让它写了，宁可自己手撸，或者让它生成状态枚举和转换表的测试用例，反而能帮我发现漏掉的边界。另一个技巧是，让它先写伪代码或者步骤列表，你审核完逻辑再让它翻译成具体实现，相当于把“设计”和“编码”分开，它主要负责后者。还有个小坑，AI对时间比较的“当前时间”理解经常是固定的，你最好用Clock.now()这种依赖注入的方式写测试，不然它容易把系统时间和业务时间搞混。总的来说，它最适合干的还是DTO转换、分页查询、单元测试模板这类“形状固定”的活，有状态的核心业务逻辑，就当它是高级自动补全，别指望它背锅。

这个坑我也踩过。Cursor写简单CRUD确实爽，但一碰到状态流转就开始胡说八道，订单超时那个例子太真实了，我遇到过类似的时间比较写反，跑起来才发现逻辑完全拧了。后来我的做法是把复杂业务拆成小函数，一次只让它填一个纯逻辑片段，比如“给定订单状态和当前时间，返回是否该取消”，这样它出错率低很多。另外上下文很关键，光靠注释不够，最好把相关的实体类、枚举定义、甚至已有的类似方法贴给它看，它才能对齐你的命名和边界条件。状态机这块我觉得AI目前确实不太靠谱，不如自己画好状态图再让它按图翻译成代码。单元测试反而是它强项，你可以先让它写测试用例，用测试来倒逼它把逻辑写对。反正我现在是把它当高级代码补全用，核心业务判断还是自己来，省心。

复杂状态逻辑还是自己写靠谱，AI顶多帮你搭个骨架，关键判断得手动补。

我一般不让它直接写状态流转，先让它把状态枚举和事件表列出来，确认没歧义再生成代码。定时任务那个坑我也踩过，后来改成先写单测描述预期行为，再让它补实现，反着来成功率高不少。业务上下文光靠注释不够，把相关service方法签名和字段说明粘进prompt里会好很多。复杂判断还是自己搭骨架吧，AI填分支里的简单逻辑就行。

我一般把AI当高级代码补全用，复杂状态流转还是自己画完状态图再让它填骨架。订单超时这种最好把状态定义、触发条件、并发场景都塞进prompt里，光靠注释不够。另外建议让它先输出伪代码或者时序描述，你确认逻辑没问题再让它转成Java，比直接生成靠谱不少。