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

把状态机拆成小函数喂给AI，每个函数只干一件事，它比人还靠谱，复杂逻辑别让它一口气写完。

我也有同感，复杂状态流转确实容易翻车，AI现在更像是个高级补全插件，而不是真能理解业务。我的笨办法是把大逻辑拆成小函数，每个函数只让它处理一个判断点，再自己串起来，这样出错好定位。另外那种死循环问题，可以试试直接给它一个反例，比如明确说“如果订单已取消就不执行”，效果比写一堆注释强。

说实话我也有同感，AI写CRUD和工具类是真省事，但一碰状态机这种带时序的业务逻辑就容易翻车，感觉它根本记不住之前的上下文。我的笨办法是把复杂判断拆成多个小函数，每个函数只干一件事，再配上具体的输入输出示例喂给它，比写一大段注释管用。另外让它先写伪代码或者画个流程描述，确认逻辑对了再让它补代码，会靠谱不少。你那个死循环的定时任务，我猜是它没理解“只执行一次”的语义，试试把业务约束直接写进提示词里，比如“用分布式锁保证幂等”这种，效果会好一些。

复杂业务还是得自己搭骨架，AI当个高级补全用，状态机这种核心逻辑建议手写。

说实话我也踩过这个坑，状态机这种带时序的逻辑AI确实容易翻车，尤其是它不懂业务里那些隐性的边界条件。我的经验是让它先产出流程图或者伪代码，你审核逻辑骨架后再让它生成实现，比直接堆注释管用得多。另外可以把复杂的if-else拆成策略模式，AI对这种小函数的理解准确率会高不少。单元测试倒是真适合它，但前提是你得先手动把断言写清楚，不然它自己测自己容易自嗨。

AI编程工具在CRUD和工具类上确实能省不少事，但遇到状态机这种有隐式时序的逻辑，它基本就是在瞎猜。我自己的做法是，把复杂的业务规则先拆成几个简单的函数，每个函数只做一件事，再让AI分别生成，最后自己拼装，这样比让它一口气写完靠谱得多。另外，给注释不如给具体的输入输出例子，比如“订单状态是PAID，当前时间超过创建时间30分钟，就改成CANCELLED”，它生成错的概率会低很多。你那个死循环的问题，多半是没限制任务执行次数，下次可以在提示词里明确加上“只执行一次”或者“用@Scheduled的fixedDelay”。

写业务逻辑时我基本不让AI直接出完整方案，它太容易把边界条件想当然。我的土办法是，先自己画个状态流转图，然后把每个分支单独拷给它，让它只生成某一条路径的代码。比如订单取消，就分“未支付超时”和“已支付申请退款”两种场景，分别让它写，最后自己合。另外，测试用例倒是很适合让AI写，你让它根据你给的正常和异常输入生成单测，反而能帮倒逼你理清逻辑，比让它写实现更有效。

说实话，我现在对AI写复杂业务逻辑的信任度只有六成，它更适合当个高级自动补全。

建议把业务规则拆成小函数喂给它，状态机这种还是自己手写稳，AI写工具类确实香。

说实话，我跟你情况差不多，现在基本把AI当高级补全用，复杂状态流转我都是自己先画好流程图再让它照着写，不然它自己发挥起来真能给你整出花活。有状态的业务逻辑还是得人盯着，我试过把它生成的代码拆成小函数再喂回去，让它在已有约束里改，比让它从零生成靠谱多了。另外你可以试试给它看一段你手写的标准写法当示例，比写一堆注释管用。

我之前也踩过这个坑，后来发现AI写状态机逻辑确实容易翻车，尤其是时间比较这种细节，得靠人工把边界条件给它喂清楚。我的办法是先把核心业务流程图写出来，然后用伪代码描述关键步骤，再让AI填充具体实现，比直接丢需求给它靠谱多了。另外，让它生成单元测试反而效果好，测试用例一多，它自己就能反推出不少逻辑矛盾。

我跟你情况差不多，后来发现把复杂状态机拆成小步骤，让它一步步生成再自己拼起来会好很多，别指望一次给完整需求。另外像订单超时这种，我干脆写死逻辑框架让它填空，效果比让它自由发挥强。你觉得给AI喂一些类似业务的测试用例，它会不会学得更准？

复杂业务还是别指望它一步到位，我都是让它生成骨架再手动补状态流转，比纯手写快但省心得多。

建议把状态机和边界条件拆成小函数喂给它，比写一大段注释管用，我现在就这么干的。

说实话你碰到的问题太典型了，我前阵子用Copilot写个库存预占释放的状态机，它直接给我整出个并发下重复释放的bug，当时差点把键盘砸了。我的感觉是这类工具对“状态流转”的理解本质上是概率预测，它根本不知道你的业务里“超时”和“取消”之间到底该不该有幂等保护，所以生成那种看似合理但逻辑闭环的代码特别擅长。后来我学乖了，复杂业务我干脆只让它生成骨架和DTO，核心判断条件全部自己手写，把AI当高级补全用。至于调教技巧，我发现光写注释没用，得给它喂“反例”——比如在注释里明确写“注意：这里不能用轮询，必须用延迟队列，且要处理重复消息”，它出错率会下降不少。另外你试试把需求拆成极小的函数，每个函数只描述单一行为，比如“判断是否可取消”和“执行取消动作”分开让它写，最后自己组装，比让它一口气生成整个流程靠谱得多。单元测试倒是真的适合让它写，尤其是那种边界值用例，它瞎编的输入经常能帮你发现隐藏问题。说到底，工具就是工具，让它干体力活，脑力活还是得自己来。

把复杂状态机拆成小函数喂给它，每个分支单独生成再自己拼装，比让它一口气写完靠谱多了。

把复杂业务拆成小步快跑的简单指令喂给它，状态机这种还是自己画好图再让它翻译更靠谱。

说实话我也有同感，像状态机这种带时序和流转边界的东西，AI确实容易把上下文搞混，我一般会先把状态枚举和流转图写死在注释里，再让它只补具体分支逻辑，效果能好点。另外定时任务这种它特别容易放飞自我，我干脆让它只生成单次执行的方法，循环和调度自己写，省得它给你整出个死循环来。你要是实在不放心复杂逻辑，就让它先写测试用例，跑挂了看它怎么修，反而比直接写业务代码靠谱。

我觉得你遇到的这个问题挺典型的，AI写工具类或者单测确实比写状态机靠谱得多，因为后者逻辑链一长它就容易“幻觉”。我的经验是别指望它一次生成对，直接把你的业务规则拆成几个小函数喂给它，每个函数只干一件事，再让它在函数注释里写清楚前置条件和返回值，效果会好不少。另外可以试试让它先画个状态流转的伪代码，确认逻辑对了再让它生成真正的代码，这样能省去很多debug时间。你那个死循环的问题，是不是因为没给它定时任务的边界条件示例？我一般会给一两个具体的输入输出例子，它理解上下文的能力会强很多。

我一般把AI当高级补全用，复杂状态机还是自己画流程图，让它按步骤生成再手动改。

把业务拆成小函数喂给它，单测跑通再拼装，这样比直接写大段逻辑靠谱多了。

状态机这种还是别硬让它写，我都是把规则拆成伪代码喂给它，正确率能提不少。

说实话我也有同感，复杂业务逻辑里AI基本就是“一本正经地胡说八道”，尤其状态机这种隐式流转它根本抓不住。我现在的做法是让它只生成骨架和单方法体，状态判断全部自己写死，然后拿AI去补单元测试和边界值，反而效率高不少。另外试试把业务规则拆成极小的函数再喂给它，每个函数只干一件事，它出错概率会低很多。不过还是想问下，你们有没有试过用AI生成状态机图再转代码？我总感觉那一步它最容易跑偏。

说真的，你遇到的情况我太有同感了。我现在基本把AI当“高级补全工具”用，复杂业务逻辑它确实hold不住，尤其那种隐含着时序和状态流转的判断，它根本没法理解“当前订单处于什么阶段”这个前提。我试过把状态机图用文字描述喂给它，甚至把数据库里几个典型数据样例贴进去，效果比单纯写注释好一点，但也就好那么一丢丢。

我的经验是，让它写工具类、Mapper、DTO转换、单元测试这些“无状态”的活确实靠谱，但涉及“什么条件下允许做什么”的核心业务，我宁可自己写主流程，然后故意留几个空方法给它填，这样它只能在边界内发挥。另外你可以试试把业务规则拆成非常小的函数，每个函数只描述一个判断条件，比如“isOrderExpired”和“shouldAutoCancel”，让AI分别实现，最后再自己串起来，比让它一口气生成整个流程要稳得多。

还有个土办法，就是给AI看错误案例，直接说“这段代码会导致死循环，因为XX条件永远为真”，它反而能改对，但前提是你自己得先能看出毛病。说到底，AI现在就是个思路放大器，它猜不透你的隐含业务规则，你得把它当成一个经验丰富但不懂业务的实习生来带，拆解清楚每一步，它才能不添乱。反正我现在写CRUD还是自己动手，AI只负责填充那些我已经设计好的接口实现，效率反而高很多。