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

说实话你这个体感太真实了，我拿Cursor写业务代码也踩过同样的坑。后来我发现问题出在“上下文颗粒度”上——你给AI的指令如果是“帮我写个表单校验”，它默认会按通用逻辑来，自然就漏掉业务里那些隐性的边界条件。我的做法是先把异常分支、硬编码参数这些约束直接用注释写在代码里，比如// 这里必须从配置中心读取，不要写死，然后再让AI去补全，效果会好很多。

另外我怀疑这类工具的训练数据里，LeetCode风格的算法题和通用框架代码占比太高，而真实业务里那种又脏又乱的规则逻辑，它们其实学得并不好。所以我现在基本把AI当高级自动补全用，像状态机这种核心流转，我会自己先把状态枚举和转移条件列成表格，再让AI按我的表去生成代码，这样它至少不会自己发明新状态。

还有个小技巧，就是让AI先写测试用例，再写实现。你让它针对表单校验先列五个边界场景，它就会被迫考虑空值、类型错误、异步校验失败这些，比直接写代码要靠谱得多。你下次可以试试把复杂业务拆成多个小函数，每个函数单独让AI写，别让它一口气生成一大段，错误率会明显下降。

说实话，我也有同感，业务逻辑这块AI确实容易翻车。我后来发现，不是prompt多细的问题，而是这类工具默认会往“最优雅”的方向写，但业务代码要的是“最防御性”的写法。我现在都是先给AI一个具体到字段级别的骨架，比如把每个校验规则、每个异常分支都写成注释，让它按注释填空，比让它自由发挥靠谱多了。还有个小技巧是，故意在prompt里加一句“参考项目中已有的xxxService的写法”，它就能模仿现有代码风格，而不是自己发明一套。至于硬编码参数，我干脆在输入前就把那些常量替换成占位符，让它填变量名，不然它总会自作聪明写个默认值。另外多状态流转这种，我建议直接画个状态机让它跟着走，别指望它自己推理出所有边界，它擅长的是续写，不是设计。说到底，这些工具更像高级补全，离“理解业务”还差得远，你得把自己当项目经理，把它当实习生。

说实话你这体验我太懂了，AI写算法题跟写业务代码完全是两码事。我现在的做法是把大需求拆成十几个小函数，每个函数只描述输入输出和边界条件，让它一次只干一件事，反而比让它一口气写完整个流程靠谱。另外异常处理和硬编码这种，我干脆直接在prompt里加一句“所有参数必须显式定义，禁止魔法数字，每个分支都要考虑null和空值”，效果立竿见影。

说实话你这个感觉太真实了，业务逻辑里那些边界情况和状态流转，AI根本抓不住上下文，我试过把整个文件丢给它让它改，结果它倒是挺客气，直接把我原本的校验逻辑给重构没了。后来我学乖了，干脆把具体的异常场景和参数来源直接写进prompt里，比如“这个字段用户可能传空，而且后端会返回特定错误码”，它就靠谱多了，你试试把问题描述拆成“输入、输出、不允许发生什么”三个部分。

说实话你这个问题我太有同感了。我之前也拿Copilot刷过一阵子算法题，确实爽，但一回到项目里写那种带状态机的审批流，它就经常给我整出些“看似合理但一跑就炸”的代码，比如漏了事务边界或者把枚举值写死。后来我慢慢发现，这类工具对业务逻辑的“理解”其实停留在语法层面，它根本不知道你数据库里那张表的数据长什么样，也不知道你们团队对异常处理有什么约定。我的做法是，把大段业务需求拆成很小的函数，每个函数只干一件事，然后在注释里把输入输出、边界条件、甚至依赖的外部服务都写清楚，再让AI补全函数体——这样它出错的范围就小多了。另外，你提到的硬编码问题，我习惯在prompt里明确要求“所有参数必须来自配置或方法入参，不许写常量”，虽然它偶尔还是会犯，但至少能省掉一半的返工。说到底，这工具更像是给你搭了个骨架，血肉还得自己填，别指望它直接给你能上线的代码。

说真的，你这个问题我太有同感了。我后来发现关键是别让AI直接生成一整个函数，而是把业务规则拆成一条条明确的“如果发生A，就做B，否则抛异常”喂给它，它给的代码基本就能直接用了。另外，像硬编码参数这种，我都是先在prompt里声明“所有常量必须抽出来，用配置文件或枚举”，不然它真的会图省事。你试试把校验规则写成表格或者伪代码给它，效果比描述大段需求好很多。

说实话你这个问题问到点子上了，我也踩过同样的坑。后来我发现写业务逻辑时得把“上下文”喂得更狠一点，比如直接把相关的接口定义、状态枚举甚至数据库表结构贴进去，光靠描述需求它确实容易自由发挥。另外我习惯让它先给一版带TODO的骨架，再逐段细化，而不是一次性生成完整方法，这样能少改很多硬编码和异常处理。你可以试试把复杂校验拆成小函数让AI逐个写，比让它一口气搞定靠谱多了。

说实话你这个问题问到点子上了，我自己的体感是这俩工具在“确定性”场景和“探索性”场景下完全是两个物种。业务逻辑难搞，真不是单纯prompt的事，因为表单校验、状态流转这种玩意儿最坑的地方在于“上下文隐式约束”——比如某个字段在某个状态下必须联动另一个字段，这种规则往往散落在老代码或PRD里，AI根本看不到，它只能根据你给的那段代码去猜，猜出来的自然就缺胳膊少腿。

我现在的做法是把“大需求拆成小步骤”，比如先让它只生成数据校验的核心规则，然后我手动把异常处理和硬编码参数用常量或配置类替换掉，再让它跑单元测试来反推逻辑漏洞。说白了，你得把AI当实习生用，给它画清楚边界，而不是让它背整块业务锅。另外，强烈建议你试试在prompt里直接贴一段你项目里现有的类似业务代码当few-shot例子，比干巴巴描述需求管用十倍。

还有个歪招，就是让它先写伪代码或者状态流转表，你确认了逻辑分支再让它补实现，这样能避免它一股脑输出一大坨没法看的代码。最后想问下，你用的哪个版本？我最近发现Cursor的特定模型对中文业务描述的理解差异还挺大的，有时候换个模型效果直接不一样。

说实话你这感觉太正常了，我拿Copilot写业务逻辑也经常被它坑，它老爱把状态机简化成if-else，异常还全吞了。后来我学乖了，与其写prompt不如直接给它贴一小段当前项目的代码风格，让它照着仿写，再明确指定“必须处理空指针和边界值”，效果会好很多。另外复杂业务我干脆把大函数拆成几个小步骤，一步步喂给它，别指望一口气生成完，这样返工率能降一半。

把复杂业务拆成小步骤让它一步步写，比一次性给大需求靠谱得多，异常处理得自己盯着补。

说实话你这感觉太正常了，我也踩过这坑。后来发现这类工具写业务逻辑时得把“约束条件”全塞进prompt里，比如异常分支、边界值、状态机图，甚至直接贴一段你项目的旧代码当参考，不然它真敢给你写出一堆魔法数字。另外别指望它一次性给全，我都是让它先出骨架，再自己补细节，AI负责生成，你负责教它“做人”。

说实话你这感觉太正常了，我拿Copilot写表单校验也经常得手动补一堆边界条件。后来我学聪明了，把报错信息格式、必填字段规则这些直接写进注释里，比prompt管用多了。另外业务逻辑这种强依赖上下文的活儿，我一般把相关函数签名和几个典型调用例子丢给它，再让它写，比光描述需求靠谱不少，你可以试试。不过也别太指望它一次成型，当个高级补全工具用反而省心。

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

让AI先列状态流转的伪代码，你确认逻辑后再让它生成，硬编码和漏异常的情况能少一半。

说实话我也踩过这个坑，后来发现关键是把业务约束拆成小步骤喂给AI，比如让它先列校验规则再生成代码，比一次性描述完整流程靠谱得多。另外我习惯在prompt里明确“所有分支都要考虑异常和默认值”，这样至少硬编码的情况会少一些。工具确实更擅长处理局部逻辑，但全局状态流转还是得自己把控，不然改起来比手写还累。

说实话我也有同感，业务逻辑这玩意儿真不是prompt写得细就能解决的。我试过把校验规则、状态流转条件全塞进去，结果它给我生成一坨又长又绕的if-else，还不如自己手写来得清爽。后来我摸索出的办法是，干脆把业务拆成小块，比如一个表单校验就专门问它“这个规则怎么用zod写”，别让它一口气生成整个流程。还有，你提到的硬编码参数和异常处理，我会在prompt里明确加上“所有外部输入都要校验，错误要抛自定义异常”这种约束，但说实话，每次还得自己过一遍改，效率提升有限。我甚至怀疑这些工具的训练数据里业务代码占比太少，全是算法题和开源框架的套路，所以一到需要业务上下文的地方就露馅。现在我的用法是，只让它写纯函数、工具类，或者帮我重构已有的烂代码，真正核心的流程控制还是自己来。你试试把大需求拆成“点状”的小问题去问，可能比让它一次写完整个模块靠谱点。另外，多状态流转这种，我建议你先自己画好状态机图，再让AI按图填充逻辑，别指望它自己设计决策路径。

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

业务逻辑还是得自己搭骨架，AI填肉，异常和状态流转这种隐性的东西它真学不会。

说实话你这个感觉我太懂了，工具类代码AI确实顺手，但业务逻辑里那些隐含规则和边界情况它根本猜不到。我后来是把大段需求拆成小步骤，每个函数都明确告诉它输入输出和异常分支，再让它自己补全，比一次性塞整段描述靠谱得多。另外像表单校验这种，我干脆先手写一版最核心的规则，再让AI照着这个风格扩展，它就不容易跑偏了。感觉不是姿势不对，是这类工具天生适合“局部优化”，全局业务还得自己把控。

说实话我觉得问题不在姿势，在于业务逻辑本身的信息密度太高了，AI根本没法从对话里完整理解你项目里的那些隐性约束。我的做法是先把异常分支和边界条件写进prompt里，甚至直接给它一段伪代码框架，让它只负责填空。另外别指望一次生成，让它先给个粗糙版本，你review一遍再让它改，反而比反复引导省时间。

这问题太真实了，我拿AI写业务逻辑也踩过一样的坑。后来发现关键是把大需求拆成小函数喂给它，比如先让它生成校验规则，再单独跑状态流转，别指望一次全生成完。另外得在prompt里明确写上“考虑所有异常分支，参数不许硬编码”这类约束，不然它真给你省事儿。工具本身没问题，但业务代码的上下文太碎了，AI很难自己脑补完整，得靠咱们当脚手架。

说实话我也觉得它们写业务逻辑时像在裸奔，异常处理和边界条件全靠人肉补。我的土办法是把项目里的类似模块当few-shot例子贴给它，再让它照着改，效果比光描述需求强不少。还有一个点，别让AI直接写完整方法，让它输出伪代码或者步骤列表，你确认思路后再让它细化，这样能少改很多烂摊子。感觉这玩意儿就是个高级自动补全，别太指望它替你背锅。

我跟你反过来，现在遇到复杂表单直接开两个窗口，一个问思路一个写代码，最后自己拼。说实话AI写业务逻辑最大的问题是它不懂你的数据流，字段之间的联动关系全靠猜，所以我会先把核心状态机画出来贴给它，让它只填充每个节点的判断逻辑。另外记得让它写完后自己列一份边界条件清单，你照着检查，比自己硬看代码效率高多了。反正这东西得当

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

确实，AI写业务像半成品，得多给几个正反例约束，还得自己兜底边界条件。