用AI Agent写代码，怎么总在复杂逻辑上翻车？求调教方法

复杂逻辑还是得靠人肉拆解状态机，把关键分支喂给它当约束，别让它自由发挥。

你试试让它先写伪代码再生成实现，比直接写靠谱不少。

这问题太真实了，Agent写CRUD是真爽，但一到状态机那种多分支流转就原形毕露。我试过把每一步的输入输出和前置条件直接写成伪代码塞进prompt，比单纯描述需求管用不少，但本质上它还是缺“全局推演”能力。建议你别指望它一次性想全，而是让它先列出所有可能路径和边界条件，你再逐个确认，相当于帮它装个外置大脑。另外这场景确实适合先把规则拆成数据表或配置，让Agent只做映射，别让它自由发挥逻辑。

我最近也踩过这个坑，状态机那部分它直接给我跳了两个分支，debug到怀疑人生。后来我发现，光靠注释不够，得把期望的输入输出样例直接喂给它，比如“用户A走这个分支，用户B走那个分支”，它反而能收敛不少。

另外还是要给它“做减法”，别让它一口气处理整条链，拆成几个独立小步骤，每步都验证结果再继续。复杂逻辑还是得自己画个流程图，Agent更适合当辅助，别真当主力。

我现在就把它当高级自动补全，遇到关键判断点就手动写死，或者用测试用例逼它补全边界，效果比纯prompt强多了。

这问题我太有同感了，Agent写CRUD确实溜，但一到状态机这种带时序的逻辑就露怯，本质上是它没在脑内把“所有可能路径”走一遍。我现在的土办法是，把关键分支和边界条件直接写成“伪代码+断言”塞进prompt里，让它先输出每一步的输入输出预期，再动笔写。另外别指望一次搞定，让它写个带详细日志的版本，你跑一遍把报错喂回去，比干调提示词管用。复杂业务真不能全托管，它更适合当个高级结对程序员，你盯着设计，它负责搬运。

试试把业务规则直接写成测试用例喂给它，让它按测试反推实现，比注释管用多了。

复杂状态机我一般让Agent先画流程图再写码，不然它真敢跳步。

这问题太真实了，我拿Agent写状态机也翻过车，后来发现它其实擅长“生成”但不擅长“验证”。我的土办法是让它先输出伪代码或者流程图，确认逻辑分支都覆盖了再让它落地，比直接写代码靠谱很多。另外给Agent喂具体反例特别管用，比如“如果订单已经取消还能不能退款”，它会把边界条件想得更细。复杂逻辑真的别指望一步到位，拆成多轮对话逐步确认反而效率更高，你试试把需求描述成“当A且B时做C，否则做D”这种绝对逻辑，比散文式prompt有效多了。

复杂逻辑还是得自己先把状态流转画清楚，让Agent只填代码别自作主张。

试试把状态机画成表格塞给它，让它按表填代码，比纯文字提示词靠谱得多。

复杂逻辑还是得自己先把边界条件列清楚，Agent只能当执行者，不能当架构师。

这问题我太有同感了，Agent写CRUD确实溜，一到状态机这种多分支逻辑就开始自由发挥。我试过最有效的一招是让它先写伪代码或者画个流程图，把每个分支条件和异常路径明确列出来，确认完逻辑再让它生成代码。另外别太迷信一次性生成，复杂逻辑拆成几个步骤单独问，每次只让它处理一个状态转换，出错率会低很多。还有个小技巧，把边界情况直接写成测试用例丢给它，有时候比注释管用。

这问题太真实了，Agent写CRUD确实跟喝水一样顺，但一到状态机这种多步逻辑就原形毕露。我试过的最有用的一招是逼它先写伪代码或流程图，明确每个分支的条件和返回值，再让它翻译成代码，相当于把思考过程前置。另外别指望它自己补边界情况，你得把异常路径当成显式需求写进去，比如“如果订单已取消且退款中，禁止再次触发发货”。最后建议复杂逻辑别用Agent一把梭，让它生成单测用例来反推实现，比直接改代码有效得多。

说实话你这情况太典型了，Agent写复杂逻辑时就是容易“自信地瞎编”。我试过最管用的办法是让它先输出伪代码或状态转换表，你确认逻辑闭环了再让它生成正式代码，比直接写省心得多。还有就是别在注释里写需求，单独用一段自然语言描述完整流程，特别要强调“每个分支必须列出前置条件和异常处理”。另外这类场景真别全指望Agent，它更适合做执行者，你当架构师把关键路径拆好，它做填空反而更稳。

同感，复杂逻辑下Agent容易“自我脑补”确实头疼。我试下来有个小技巧：把状态机或权限链路直接画成伪代码表格，每一步列好前置条件和异常分支，再让Agent按表生成，比纯文字描述管用。另外别指望一步到位，让它先输出核心流程，你再手动补边界情况，最后让它写测试用例反推逻辑漏洞，这样能筛掉不少幻觉。

说实话这问题太真实了，Agent写CRUD确实顺手，但一到状态机这种多步逻辑就开始给你表演“自信地犯错”。我现在的做法是让它先输出伪代码或者决策树，确认逻辑分支完整了再让它生成具体实现，比直接写代码靠谱得多。另外边界情况别指望它自己想到，你得把异常分支当需求一样明确写进prompt里，比如“库存不足时回滚并记录日志”，不然它真能给你忽略掉。

这问题我太有同感了，Agent写CRUD确实顺手，但一到状态机这种多分支逻辑就开始放飞自我。我现在的土办法是逼它先输出伪代码或者决策表，明确每个分支的条件和动作，再让它生成实现，相当于给它戴个“思考框架”。另外建议把边界情况直接写成单元测试用例丢给它，让它以通过测试为目标，比单纯描述需求靠谱得多。

说实话你这情况我太懂了，Agent写CRUD和脚本确实跟开了挂似的，但一到状态机那种带隐含流转条件的东西，它就像个记性不好的实习生，写着写着就把前置校验给吞了。我后来发现一个稍微管用的办法，就是别让它“实现功能”，而是逼它“先写设计草稿”，比如在prompt里明确要求它输出每一步的状态转移表或者决策树，把边界条件列成清单，它写代码的时候反而会老实一点。另外，我试过把权限校验拆成独立的“规则文件”让它单独维护，而不是混在业务逻辑里生成，出错率会低不少。不过说真的，复杂逻辑我建议你还是自己把核心骨架搭好，让Agent去填肉，而不是让它从头造轮子——它现阶段更像是个高级自动补全，不是真正的架构师。你要是试过把它生成的代码再喂回去让它自查边界，效果可能也会好一些，但得盯着，不然它可能一本正经地编个假场景糊弄你。

这问题太真实了，Agent写CRUD确实利索，但一到状态机这种多步逻辑就原形毕露。我自己的经验是别指望它一步到位，把核心业务规则拆成独立的小函数，每个函数里只放一条明确的判断条件，比在注释里写一大段描述管用得多。另外，你可以试试在prompt里故意加几个边界例子，比如“订单已取消但支付成功”这种，逼它考虑分支。不过说实话，复杂逻辑我还是建议自己先搭好骨架，让Agent填肉，纯靠它设计流程真容易翻车。

这题我太有同感了，Agent写CRUD确实溜，但一碰状态机这种带“时序”和“约束”的逻辑就原形毕露。我试下来最有效的办法是别让它直接写实现，而是先逼它用自然语言把每一步的触发条件和异常分支列成清单，你审核通过再让它转代码，等于帮它装了个思考的脚手架。另外如果逻辑真的绕，我建议还是拆成几个独立的小Agent各管一段，中间用明确的接口数据对接，别指望一个Agent从头到尾扛下来，它一“上下文迷失”就开始编。你可以试试在prompt里加一句“每次判断前先列出所有可能的状态组合”，这招对我这边至少能减少一半的幻觉。

说实话，这问题我最近也踩坑了，Agent对状态流转和边界条件的推导确实弱，它更擅长“顺着写”而不是“逆向校验”。我的做法是把关键分支直接写成伪代码或者表格塞进prompt里，让它照着填逻辑而不是自由发挥。另外复杂业务我基本会让它先输出设计步骤，我确认后再写码，不然它真的会一本正经地漏掉else。你试试把“如果...否则...”的约束条件单独列出来，比纯描述需求管用多了。

复杂逻辑还是得自己先把状态流转图画清楚，再让Agent照着填代码，别指望它自己推理。

你把边界条件直接写进测试用例里喂给它，比在注释里喊破喉咙管用多了。

说实话你遇到的这个情况太典型了，Agent写CRUD和脚本确实快，但一碰状态机或者权限链这种需要全局视角的逻辑，它就会“偷懒”地走最短路径，把中间条件给吞了。我试过的最有效的方式，是别让它直接写代码，而是先强制它用自然语言把整个流程的判定树或者状态转换表列出来，你确认完逻辑再让它翻译成代码，相当于把“思考过程”前置了。另外，对于边界情况，我习惯在prompt里明确给它“反例清单”，比如“如果订单已取消但支付回调来了怎么办”，它比泛泛地说“注意边界”管用得多。还有个小技巧是让它自己给自己写测试用例，特别是异常分支的测试，它为了跑通测试会不得不把条件补全。不过说真的，如果逻辑复杂到需要跨五个以上模块协调，我建议还是自己搭好骨架，让Agent填肉，别指望它能独立扛起整个状态机——它不是不聪明，是缺乏对业务上下文的“敬畏感”。