Cursor和Copilot都用过了，感觉还是写业务逻辑不够顺，是我的姿势不对吗？

业务逻辑得靠你喂上下文，光靠prompt细没用。我一般先写接口和状态图，再让AI填实现，省心不少。

业务逻辑确实不是这类工具的强项，我也有同感。我的做法是先把状态流转画成文字版的伪代码，把异常分支和边界条件都列清楚，再让AI往里面填实现，这样它就不容易漏。另外关键参数我一般会显式写在prompt里，比如"超时时间从配置读，不要写死"，比让它自己猜靠谱。表单校验这种我干脆自己写规则表，AI只负责生成重复的校验代码。

我跟你感觉差不多，写业务逻辑时AI确实不太灵，尤其是那种需要跟现有代码风格和内部约定对齐的地方，它根本不知道我们项目里那些隐式的规则。我之前试过把整个模块的上下文都喂给它，包括数据库schema和几个类似的已有实现，效果会好一些，但prompt就得写得很长。后来我的做法是先把业务逻辑拆成小函数，每个函数只负责一个明确的状态转换或校验步骤，再让AI去填具体实现，这样它出错的空间就小很多。异常处理和边界条件我基本不指望它主动加，都是自己补，或者专门在prompt里列出要处理的异常类型。硬编码参数的问题也挺常见，我一般会先把配置项抽成常量或者从上下文里传进去，再让AI填中间的逻辑。说到底这玩意还是更适合有明确输入输出的场景，业务逻辑那种模糊地带太多，人自己都没想清楚的话，AI更不可能帮你理清楚。

我后来发现关键是别让AI自由发挥，先把业务规则拆成小步骤，每步给它明确的输入输出和边界条件。比如表单校验，我会先写个注释列出所有校验项和报错文案，再让它填代码，这样异常处理基本不会漏。多状态流转也是，先画个状态机表格贴给它，比直接说“实现状态流转”靠谱多了。感觉AI写业务代码需要你当架构师，它当打字员，不然它默认走最短路径就很容易硬编码。

我也有同感，业务逻辑这块确实不太一样。工具类和算法题边界清晰，AI见过大量类似模式，生成出来基本能跑。但业务代码往往依赖你们系统里那些没写在文档里的隐性规则，比如某个状态字段为什么不能直接从A跳到C，这种上下文AI根本猜不到。

我的做法是先把业务约束拆成一段类似注释的说明塞进prompt，比如"这个字段更新前必须校验用户是否有权限，异常统一抛BizException"，让它按这个骨架填。但即便这样，它还是会自作主张硬编码一些东西，所以我现在基本只让它生成结构框架和重复的CRUD，核心判断逻辑自己写。

另外多状态流转这种，我会先画个状态机或者列出所有合法转移，把这张表喂给它，效果比纯描述好很多。感觉这类工具更像是加速器而不是代驾，业务理解那部分还是得自己兜底，不然改bug的时间比写还长。

同感，业务逻辑这块AI确实容易翻车。我现在的做法是先把状态流转画成伪代码或者写个详细的注释块，把每个分支、异常情况都列出来，再让AI去填充实现，这样它就不会自己瞎猜了。表单校验那种更麻烦，因为涉及产品规则和历史包袱，我一般只让AI生成校验函数骨架，具体规则自己往里填。还有个坑是AI特别喜欢硬编码，比如时间、阈值、枚举值，你得在prompt里明确说“所有常量抽到配置或枚举里”，不然它默认就写死。多状态流转我试过让它先输出状态机表格再写代码，效果比直接让它写实现好不少。另外别指望一次生成到位，我基本是拆成小函数逐个让AI补，然后自己串起来。说到底它擅长的是有明确输入输出的局部逻辑，全局业务上下文还得靠自己喂。

同感，业务逻辑这块AI确实容易翻车，尤其是状态机、权限判断这种牵扯上下文的地方。我现在是把大段业务拆成小函数，每个函数只给AI描述清楚输入输出和边界条件，让它填中间那段，比直接丢一整块需求靠谱很多。另外异常处理和参数校验我基本都自己来，让AI写反而容易漏。说到底业务代码里的“为什么这么写”它根本不知道，只能靠我们把约束喂够。

业务逻辑得自己先理清状态再让AI填，不然它只能瞎猜。