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

把业务规则拆成小函数喂给AI，让它只补逻辑别自由发挥，异常处理自己兜底。

给AI喂具体的业务规则和边界条件，比让它自由发挥靠谱，异常处理直接写进提示词里。

说实话你这个问题问到点子上了，我自己的体感是这俩工具在业务逻辑上确实像“偏科生”。它们本质上是基于你给的上下文做模式匹配，而业务逻辑最要命的就是隐含约束和边界条件，这些恰恰是训练数据里最稀缺的，所以AI一遇到复杂状态流转就容易给你整出“看起来对、跑起来炸”的代码。

我现在的笨办法是把大任务拆成极小的单元，比如一个表单校验，我先让它只写某个字段的规则，明确告诉它“这个字段允许空值但长度不能超过20，并且要兼容全角半角”，这样它犯傻的概率会低很多。另外我发现给AI“负面例子”特别管用，比如直接说“不要用全局变量，不要吞异常，参数必须显式传”，比笼统说“写健壮点”强十倍。

还有个坑是它特别喜欢自作主张帮你重构，明明你只想加个if判断，它能把整个函数给你重写了，最后你还得花时间diff。所以我现在开Agent模式前都会先锁死文件，或者只给它粘贴相关代码片段，而不是让它自由读整个项目。

说到底，我觉得这些工具更像是“高级补全”，不是“业务架构师”。真要处理那种多状态流转，我宁愿自己画个状态机图再让AI照着写，反而比它自由发挥靠谱。你试试把业务规则拆成明确的前置条件和后置条件喂给它，会不会好点？

把业务规则拆成小函数喂给它，再加几个边界case当例子，比写一大段prompt管用多了。

你试试先画状态流转图，把每个分支的异常情况单独问，别让它一口气生成整个逻辑。

说实话你这体验太真实了，业务逻辑里那些边界条件和状态流转，AI根本抓不住隐含规则，它只会按最常规的路径写。我现在基本把AI当高级自动补全用，先自己把接口、异常分支、关键参数都定死，再让它填方法体，这样改起来快得多。另外prompt里直接甩给它你项目的报错日志或者具体业务规则片段，比抽象描述管用十倍。你试试把它当结对编程的实习生，而不是解题大师，心态会平和很多。

说实话我也踩过这个坑，后来发现写业务逻辑时得把“约束条件”喂得特别细，比如枚举值范围、异常分支、甚至表结构字段都得写进prompt里，不然它真敢给你硬编码。另外我习惯让它先给伪代码框架，我再自己填细节，改起来比直接改生成代码快多了。你试试把需求拆成小步骤，一步步问，别一次让它写整个函数。

说实话你这个感觉太真实了，我一开始也以为是自己prompt写得不行，后来发现这类工具对“局部正确性”很擅长，但对“全局约束”基本是瞎的。业务逻辑最麻烦的就是一堆隐式规则，比如某个字段在状态A下必须非空、在状态B下要忽略，这种上下文散落在好几个文件里，你光靠对话描述，它根本记不住。我现在的做法是先把核心判断逻辑拆成纯函数，然后给AI喂一个“最小可运行示例”，让它只补分支，不碰整体流程，这样改起来快很多。另外异常处理这块我基本放弃让它自动加了，它默认你所有输入都是合法的，你不如自己在入口写个统一拦截，省得跟它纠缠。还有一点，硬编码参数这个问题，我试过在prompt里强调“所有魔法数字必须提成常量”，但效果不稳定，后来干脆在代码审查阶段自己扫一遍，反而更省心。说到底，这些工具更适合当高级自动补全，真要它理解业务规则，还是得靠你把规则拆成它看得懂的小块。你可以试试把表单校验拆成一步步的“如果……否则……”结构，它生成的质量会明显上一个档次。

把业务规则拆成小函数再喂给AI，比让它一口气写完整流程靠谱得多，异常处理自己补反而更快。

试试把状态流转画成表格式的prompt喂进去，比纯文字描述效果好，参数约束也写清楚。

说实话你遇到的情况我太懂了，Copilot和Cursor写算法题或者独立函数确实一把好手，但一进到业务逻辑就露怯。我后来琢磨着，核心问题在于它们对“全局状态”和“隐含约束”的理解太弱，你光在prompt里写“校验表单”它根本不知道你的校验规则跟后端字段、历史数据、甚至权限体系都有关联。

我现在基本不指望AI直接生成完整业务代码，而是把它当“高级补全”用。比如先把整个业务方法的结构、if-else分支、异常类型都列出来，再让它填每个分支里的具体逻辑，这样它犯错的空间就小很多。另外你提到的硬编码问题，我习惯在prompt里强制要求它“所有参数必须从配置类或上下文对象读取”，并且让它先输出变量声明再写逻辑，不然它真的会给你塞一堆魔法数字。

还有个偏方，就是故意把需求拆碎，一次只让它处理一个状态流转，比如“只写从PENDING到CONFIRMED的转换，其他分支留空”，这样比让它一口气处理所有状态靠谱得多。说到底，这类工具现在还是“单点聪明，全局犯傻”，你得自己当架构师，它当码农。

业务逻辑本质是约束和例外，你不如把异常场景列成清单喂给AI，让它照着写反而靠谱。

说实话你这感受太真实了，我一开始也是这感觉，后来发现问题的核心不在prompt细不细，而是这俩工具默认的“完成标准”根本就不是生产级代码。它们训练数据里业务逻辑的“正确答案”往往是简化版，异常分支和边界条件都被当噪音滤掉了，所以你拿它写表单校验，它给你的是“理想路径”上的代码，而不是“真实世界”里的代码。

我自己摸索的土办法是，别让它直接生成整个函数，而是把业务规则拆成一条条明确的约束，比如“这个字段当且仅当A且B时必填，否则跳过”，然后逼它逐条实现。再有就是主动让它“先写伪代码，标注出所有可能的异常点”，这样它至少会考虑throw什么异常，而不是默默吞掉。

另外我怀疑一个更根本的问题——这类工具其实是在模仿“常见写法”，但业务逻辑恰恰是最反“常见”的，每个公司状态流转和校验规则都带自己的历史包袱。所以我现在把AI当结对编程的实习生用，让它出第一版然后我大改，心态上反而好了很多。

想问下你平时会让它先输出一个“思考过程”或者“测试用例清单”再动手写吗？我试过几次，感觉对减少硬编码有点帮助，但还不稳定。

业务逻辑的隐含约束太多，AI根本猜不到，得把状态流转和异常分支写进prompt里，不然它净给你整些理想化代码。

把业务规则拆成小函数再喂给AI，比让它一口气写完整流程靠谱得多，异常处理自己补反而快。

我一般先把状态机画出来，让AI只填每个分支的具体逻辑，硬编码参数直接写注释里当约束，效果能好不少。

说实话你这个问题问到点子上了，我也有同感。AI写那种上下文封闭的工具函数确实很强，但业务逻辑本质是约束多、状态杂，它压根没理解你的领域规则。我现在的做法是先把业务规则拆成伪代码或者注释写清楚，再让它按步骤实现，比直接甩需求靠谱得多。

另外就是别指望它一次成型，异常处理和边界条件我都是自己兜底补的，AI给的代码当个初稿用就行。你试试把关键参数用常量或者枚举定义好再让它填，硬编码的情况会少很多。

说实话你这感觉太正常了，我拿Copilot写带状态机的业务代码也是一样，它经常漏掉边界情况或者把配置给我写死。后来我学乖了，不指望它一口气写成，而是先让它把流程骨架列出来，再逐段提示异常分支和参数来源，这样改起来反而比从零写快不少。另外把项目里的类型定义和常量文件拖进上下文，它跑偏的概率会小很多，你可以试试。

把业务规则拆成小函数喂给它，比让它一口气写完靠谱多了，异常处理自己补反而快。

我一般先写伪代码定好边界，再让AI填实现，硬编码参数这种问题会少很多。

说实话你这感觉太正常了，我到现在也是这状态。AI写纯逻辑片段确实一把好手，但业务代码最麻烦的不是“怎么写”，而是“有哪些隐含约束”——比如某个字段在状态A下必填、在状态B下要忽略，或者老接口的兼容逻辑根本没写在需求文档里。我试过把整个业务背景、字段表格、异常场景全塞进prompt，结果它反而开始自由发挥，生成一堆我根本没用过的工具类。后来我放弃让AI一步到位了，改成让它先给我列个代码骨架，把异常分支和硬编码的地方标成TODO，我再自己填。这样至少省了打注释和搭结构的时间。另外我怀疑这类工具的训练数据里，高质量业务代码本来就少，LeetCode和开源库的代码倒是多得不行，所以它们天生就偏“算法思维”。你试试把大段上下文直接拖进对话，然后明确告诉它“不要重构，不要加设计模式，按我现有代码风格写”，可能会顺一点。

说实话我也有同感，业务逻辑这玩意儿AI最大的问题是它压根不懂你项目里的上下文和潜规则。我现在的做法是把表单校验的规则、状态流转的边界条件直接粘进prompt，让它先列个检查清单再写代码，效果比让它自由发挥强不少。另外异常处理这种我基本都是自己补，别指望它一次到位，就当它是个高级补全工具用。

把复杂业务拆成小步骤喂给它，比一次给个大需求靠谱得多，异常处理和边界条件也得自己盯着补。

多状态流转这种，我都是先画好流程图再让AI照着写，不然它容易自己脑补逻辑。

说实话你这感觉太正常了，Copilot和Cursor本质是“接话狂魔”，不是“业务架构师”。它们擅长把单点逻辑补全，但复杂表单校验这种需要全局状态流转的活，你得先把边界条件和异常分支拆成小函数喂给它们，不然它只能瞎猜。我现在写业务代码基本把AI当高级自动补全用，自己先定好函数签名和关键判断，让它填中间的逻辑，最后再手动检查硬编码和错误处理，效率反而高不少。