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

我试下来感觉AI写工具类确实比业务逻辑靠谱多了，你那个订单超时的case太典型了，它根本没法理解“状态”这回事。我的土办法是先把状态机画成常量+枚举，让AI照着填条件，别让它自由发挥。另外像时间比较这种，直接给它一个明确的测试用例，让它跑一遍报错了自己改，比注释管用。你现在用的是什么模型？感觉GPT-4和Claude在这种场景下差别还挺大的。

我也有同感，Copilot写CRUD确实顺手，但一碰到状态机这种带时序的逻辑就翻车。我现在的做法是先自己把业务状态流转画成伪代码或表格，再让AI照着填实现，比让它直接生成整个流程靠谱得多。另外你可以试试把边界条件写清楚，比如“订单创建超过30分钟且未支付才触发取消”，它生成死循环和比较写反，多半是上下文里没给足约束。至于工具类测试，它确实比业务逻辑强太多了，我现在基本只让它干这些活。

AI生成业务逻辑就是碰运气，复杂状态机还是自己手写靠谱，顶多让它补补测试用例。

状态机这种还是别指望AI了，我都是先画好流转图再让它照着写，准确率高不少。

我跟你碰到过一模一样的问题，后来发现让AI写复杂业务逻辑前，最好先把状态机或者条件分支画成伪代码塞给它，比写注释管用多了。另外它生成定时任务时特别喜欢自己加循环，我都是明确告诉它“只负责生成单次执行的方法，调度交给人类”。现在基本只让它写CRUD和单测，复杂流程还是自己手写靠谱，AI当个高级补全工具用就行。

这种状态机逻辑还是自己写靠谱，AI写出来你敢信？我都是让它生成个大概框架，细节自己补。

AI写CRUD还行，复杂业务真得手写，你可以把完整状态流转图直接贴给它试试，比注释管用。

试试把复杂逻辑拆成多个小函数再喂给它，状态机这类还是手写靠谱，AI写工具类和测试是真省时间。

状态机这种还是自己写吧，AI只配干体力活，把伪代码写详细点它才能少脑补。

说实话我也踩过这个坑，后来发现别指望它一次性写对复杂状态流，得把业务拆成小步骤喂给它，比如先让它写状态枚举和转换表，再单独生成定时任务的触发条件，最后自己拼起来。另外我试过在注释里直接贴一段伪代码逻辑，比描述需求管用得多，它好像更擅长照着具体步骤翻译。不过像订单超时这种涉及时间边界的，我最后还是会手写核心判断，AI写的只能当参考。你试试把if-else改成规则表或者策略模式，它生成的质量会明显高一些，因为不用它自己“想”业务了。

说实话，复杂状态流转这块我也踩过不少坑，AI现在更像是个高级补全插件，不是领域专家。我现在的做法是让它只生成单个方法的骨架，状态机本身自己先画好流程图喂给它，再配合强类型枚举约束，出错率能降不少。另外，试试把业务规则拆成独立的小函数让它逐个实现，别指望一次性生成完整链条，最后单元测试还得自己补上，毕竟它自己写的测试大概率跟错误逻辑同构。

说真的，你这个情况我太熟了，AI写CRUD和工具类确实一把好手，但一到有状态流转的业务逻辑就暴露原型了。我觉得核心问题不是它适不适合，而是我们怎么把它当“高级自动补全”而不是“架构师”来用。像订单超时这种逻辑，我现在的做法是先自己把状态机画清楚，把每个分支的边界条件写死成伪代码，再丢给它让它翻译成具体实现，而不是让它从零“创作”。另外你提到注释效果一般，我试过把需求拆成小函数，每个函数只干一件事，再配合单元测试去约束它的输出，这样它“自作聪明”的空间就小很多。还有个歪招，就是故意让它写两个版本的实现，然后你对比着挑错，反而能逼自己把逻辑理得更清楚。说到底，这类工具更适合做你的“结对编程实习生”，你得先有清晰的设计，它才能帮你落地，不然就是互相折磨。

说实话你遇到的这个问题太典型了，我甚至怀疑咱们用的是同一个AI。我觉得AI写CRUD和工具类确实靠谱，因为它本质上是模式匹配，但状态机这种带时序和副作用的逻辑，它基本就是在瞎猜，毕竟它没见过你项目的真实数据流。我自己试过把业务规则拆成独立的策略类，然后让AI只补全单个方法，比让它一口气写完整个流程成功率高很多。另外你说的死循环定时任务，我怀疑是它把“超时扫描”和“订单状态更新”耦合在一起了，你不如明确告诉它“只查状态为待支付的订单，且用当前时间减去创建时间大于30分钟”这种具体条件。还有一个歪招，就是故意给它一段有明显错误的代码，让它“修复”，它反而会认真分析逻辑而不是自由发挥。最后想问你一句，你给它喂过你们项目的异常处理规范或者性能约束吗？我感觉它对业务约束的理解，全靠你提示词里那点上下文，喂得越细它越靠谱。

我一般让它写纯函数和测试，业务状态机还是自己手写靠谱，AI容易把边界条件搞混。

说实话我也踩过类似的坑，尤其是状态机这种带时序的逻辑，AI根本把握不住全局。我的做法是让它只生成单个分支的伪代码，自己负责把状态流转的骨架搭好，它填肉我搭骨，效率反而高不少。

另外你可以试试把业务规则拆成单元测试丢给它，让它先跑红再改代码，比写注释管用多了。现在我就把AI当高级自动补全用，复杂判断还是自己手写，心态放平就好。

说实话，我之前也遇到过类似情况，后来发现关键是把业务规则拆成小函数喂给它，别让它一口气生成整个状态机。你可以试试先写死几个典型的场景测试用例，让AI照着测试去补逻辑，比给注释管用多了。另外，像订单超时这种带时间依赖的，我基本不指望AI写对，自己手写核心判断，让它补外围的辅助代码，这样配合下来效率反而高不少。

说实话你这情况太典型了，我刚开始用Copilot写状态机的时候也差点被它绕进去，它特别容易把复杂分支简化成自己以为的逻辑，尤其是对时间边界和幂等性处理，感觉它脑子里只有“能跑就行”这个概念。我的经验是，这类有状态的业务逻辑你真不能指望它一步到位，更适合把它当个高级自动补全，你先把状态流转的骨架和关键分支用伪代码或者清晰的注释钉死，然后让它填具体实现，这样它瞎编的空间就小很多。另外你提到订单超时这种，我建议你干脆别让它写定时任务，直接给它喂一个现成的调度框架模板，比如用xxl-job配好，只让它生成执行器里面的判断部分，这样至少不会给你整出死循环。还有个技巧是给它看类似业务场景的测试用例，比如把已有的几个状态切换的测试方法直接贴进去，说“照着这个风格写”，它理解上下文的准确率会明显高。至于工具类、单元测试这些，确实更适合它，因为边界清晰、输入输出明确，它反而能发挥优势。我觉得你可以试着把那些复杂的if-else拆成策略模式，再让AI去填每个策略类，它每次只需要处理一个简单分支，出错率就低多了。反正别跟它客气，你得把它当成一个记忆力超好但没什么常识的实习生，把约束条件反复给它看，最后自己review的时候重点盯边界和异常流就行。

跟你情况差不多，后来我学乖了，把复杂业务拆成小步骤让AI写，每步都配上明确的状态转换条件，比让它一口气生成整个流程靠谱得多。还有个办法就是让它先写测试用例，把边界条件列清楚，再反推实现，逻辑错误能少一半。不过说真的，状态机这种核心逻辑我还是倾向自己写，AI顶多帮我生成状态枚举和框架，关键判断改起来太费劲。

试试把状态机拆成小步骤喂给它，一次只生成一个状态的判断，比让它一口气写完靠谱多了。

说实话我觉得AI写这种有状态的业务逻辑确实不太行，它很难理解你脑子里那个完整的流程闭环。我现在基本让它写工具类、DTO转换和单元测试，业务判断还是自己手写，毕竟状态机这种玩意儿上下文太隐晦了。

不过有个小技巧你可以试试：别光给注释，直接把伪代码或者流程图扔给它，让它按你的步骤翻译成代码，而不是让它自己“发挥”。另外，把复杂的if-else拆成多个小函数分开生成，再自己组合，出错率会低很多。

想问问你用的是哪个模型版本？我试过Claude写业务逻辑比GPT-4强一些，但偶尔也会在边界条件上翻车，感觉调教成本有时候比自己写还高。

说实话你说的这个情况我太有感触了，上个月我用Copilot写个库存扣减的补偿逻辑，它直接给我套了个递归，我review的时候差点没背过气去。我的经验是，AI写CRUD、DTO转换、单元测试这些“无状态”的活儿确实省心，但一碰订单状态机这种带时序和副作用的业务，它理解不了“当前状态”和“前置条件”这种隐式约束。现在我的做法是把复杂业务拆成一个个纯函数，每个函数只处理一步状态流转，然后注释里明确写出输入输出约束和不允许出现的分支，再让AI去填充，效果比让它直接生成整个方法体好得多。另外，你可以试试在Prompt里给它“反例”，比如明确写“不要用while循环，不要比较时间戳大于当前时间”，它跑偏的概率会小很多。说到底，这种工具更像是高级补全，不是架构师，你心里得有个明确的边界，哪些能放手，哪些必须自己盯死。