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

说实话，我也遇到过这个问题，感觉不是姿势不对，而是业务逻辑里那些隐含的领域规则和边界条件，AI很难从prompt里完整理解。我现在写复杂校验时会先手撸一个骨架，把异常处理和关键参数占位符写好，再让AI补细节，这样改起来省事不少。另外试试把业务拆成小函数让AI逐个生成，比一次性塞大段prompt靠谱得多。

老实说我也踩过这个坑，后来发现写业务逻辑时得把异常分支和边界条件当成必须约束写进prompt里，比如“所有输入为空时返回友好提示”，“状态机流转中如果遇到未定义状态直接抛自定义异常”，AI才会认真对待。另外可以试试先让它输出伪代码框架，你确认了逻辑再补细节，不然它总爱自作主张写完整但跑不起来的代码。

这确实不是你的问题，我也有同感。Cursor和Copilot在写独立模块或算法时表现惊艳，但一碰到业务逻辑，尤其是涉及复杂状态机和表单校验这种需要全局视角的地方，它们很容易“断片”。我觉得核心原因在于，业务逻辑往往依赖大量隐性的上下文和边界规则，比如某个字段在A状态下必填、在B状态下只读，这种“规则链”AI很难单靠prompt一次理解透。我的做法是把业务拆成更小的单元，先让AI写核心的校验函数或状态转换函数，异常处理和硬编码参数我会在写prompt时直接给几个反面例子，比如“注意用户ID不要写死，要用props传进来的”，或者“记得捕获网络请求失败的情况”。另外，对于多状态流转，我一般会先画个状态图或表格，然后让AI基于这个结构生成代码，比纯文字描述效果好很多。你试过给AI喂一个“伪代码”或“业务规则列表”吗？就是把需求按“if...then...”的格式列出来，效果会好不少。

同感，业务逻辑里那些隐式的边界条件和状态流转，AI确实容易漏掉，感觉它更擅长写“标准答案”而不是处理“现实约束”。我现在的做法是把大的业务场景拆成小函数，每个函数只让AI负责一个明确的小逻辑，比如就写“校验某个字段的格式”，然后自己手动组装和补异常。另外提示词里直接给几个具体的异常例子，比光说“考虑各种情况”有用得多。

确实，业务逻辑里的隐性规则AI很难理解，我一般会把完整的状态流转图写进prompt里。

确实，业务逻辑里那些隐藏的边界条件和异常路径AI经常忽略，得靠人反复喂上下文才行。

确实，业务逻辑的上下文太复杂了，AI容易忽略边界情况，得把异常和状态流转写进prompt里才行。

说实话你这个问题太真实了，我一开始也这样，后来发现写业务逻辑真不能光靠它自己编。我现在的做法是把接口定义、状态机流转图、甚至异常枚举先贴进去，让它按规则填空，而不是自由发挥，这样生成的质量会高很多。另外复杂表单校验我习惯让它只写核心逻辑，边界条件自己补，省得它脑补出各种bug。

其实你遇到的这个问题挺普遍的，我现在写业务逻辑基本把它当高级自动补全用，先手动搭好if-else骨架和状态机结构，再让AI填充具体条件判断和参数校验，这样它跑偏的概率会小很多。另外异常处理和硬编码这种坑，我会在prompt里加一句“请显式处理所有边缘情况并用常量代替魔法数字”，效果会好一截。不过说实话，复杂业务场景下还是得自己兜底，它更适合做第一版草稿。

说实话你这感觉我太懂了，工具类确实一把梭，但业务逻辑里那些边界条件和异常流转，AI经常漏得一塌糊涂。我现在的做法是拆细prompt，比如先让它写某个状态下的校验骨架，再手动补try-catch和硬编码参数，最后让AI帮我做单元测试补漏。另外你试试在prompt里直接写“请严格遵循以下异常处理规范”并把你的代码片段贴进去，效果比空说要好不少。

说实话，我也有同感，这些工具在业务场景下确实容易“偷懒”。我的经验是把大段的业务规则拆成小函数或伪代码，让AI一步步填空，而不是直接让它写完整流程。另外异常处理和边界条件我会在prompt里明确写“请包含try-catch和参数校验”，效果会好不少。

业务逻辑的隐形知识太多，AI很难理解上下文，可以试着先把判断条件拆成小函数再让AI填。

确实，业务逻辑里那些隐含的边界条件和异常场景，AI经常抓不住，感觉得把需求拆成极细的步骤才靠谱。

确实是这样，业务逻辑里那些隐含的上下文和边界条件，光靠一两句prompt很难说清楚。我现在的做法是把需求拆成更细的步骤，比如先让AI生成骨架，再手动补异常和状态分支，最后用测试用例反向约束它。还有就是别指望一次性搞定，把它当成一个需要反复review的初级同事，效率会高很多。

说实话我也遇到过这个问题，后来摸索出的套路是把业务逻辑拆成小块来写，比如先单独让AI处理表单校验规则，再让它根据校验结果生成状态流转代码，每一步都明确告诉它“这里需要加异常处理”或者“这个参数从配置中心读取”，这样改起来就少很多。另外把公司业务里常见的边界case写进prompt里当约束条件，比笼统说“写个完整业务”效果好不少。

深有同感，业务逻辑这块确实不是prompt能完全解决的。我感觉问题在于AI对业务上下文的理解太浅了，像表单校验这种，它不知道你数据库里字段长度限制、不知道下游接口的返回值结构，自然就爱写死参数。我现在写复杂业务时会先用自然语言把边界条件、异常分支、甚至具体到哪个枚举值要兜底都写进prompt里，相当于替它补全上下文。另外有个小技巧，别让AI一口气生成完整函数，而是先让它输出伪代码骨架，确认状态流转逻辑没问题再填充细节，这样改起来快很多。还有，我一般会给它看两三个之前写好的类似业务代码片段当few-shot，效果比单纯描述需求强不少。不过说实话，遇到那种需要全局变量联动或者跨模块调用的状态机，我还是更倾向于手写主逻辑，只让AI帮我补异常处理和日志，这样性价比最高。

说实话我也踩过这个坑，后来琢磨出一点门道——写业务逻辑时，不如先别急着让AI直接生成完整代码，而是把“业务流程拆成小步骤”喂给它。比如表单校验，我会先让它写一个校验规则的结构体或配置表，再单独让它补异常分支，硬编码参数的问题我习惯用“请把xxx参数提取成常量或配置项”来收尾。还有，多状态流转我试过用状态机描述文本加伪代码注释让AI理解，效果比直接甩需求好不少。另外我发现Cursor的Composer在上下文理解上比Copilot稍强点，但都需要我开头多花30秒写清楚边界条件。你试试把需求拆成“先做什么，再做什么，不允许做什么”三段式prompt，可能比写长篇描述管用。

确实有同感，业务逻辑里那些隐性的边界条件和异常分支，AI很容易漏掉。我现在的做法是把复杂业务拆成小块，先写好单元测试和核心规则的口语描述，再让AI一步步补代码，最后自己手动合拢异常处理和日志，比让它一口气生成靠谱得多。

确实，工具类还行，业务逻辑复杂了AI就容易翻车，得把业务规则拆成小块喂给它。

说到业务逻辑确实是这样，我试过把整个校验流程拆成小函数一步步喂给AI，再明确要求它补全异常和参数校验，效果会比直接扔一段需求描述好很多。另外感觉这类工具更适合做“代码填空”和“逻辑补全”，复杂的状态流转我通常会先手写关键节点的伪代码结构，再让AI填充细节，这样改起来省事不少。