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

说实话你这个问题问到点子上了，业务逻辑最大的坑就是隐含约束太多，AI根本不知道你们项目的上下文。我一般会把相关的几个函数或者状态枚举直接贴进prompt里，让它基于真实代码改而不是凭空生成，效果会好不少。

另外我习惯让它先写伪代码或者列步骤，确认逻辑流没问题再让它填实现，这样能省掉大半返工。异常处理和硬编码这种，你得明确告诉它“参考这个文件里的错误码规范”或者“不允许出现魔法数字”，不然它真的一直给你默认值。

说实话你这个感觉太真实了，我最近也是从刷题场景切到业务代码时被狠狠教育了一轮。我觉得问题不全在prompt，而是这些模型对“业务上下文”的感知天生就弱，它们训练数据里算法和工具代码占比太高，真到了表单校验这种需要结合具体字段、权限、后端接口约束的场景，AI大概率是在拼凑常见模式而不是理解你的业务规则。我现在的做法是，先把整个业务流程拆成几个小步骤，每一步单独让AI生成，并且明确告诉它“这里必须处理null和空字符串”、“这个状态流转要枚举所有非法路径”，相当于把需求文档里最关键的边界条件直接喂给它。还有个大坑就是硬编码，我一般会在prompt里加一句“所有参数必须从配置或上层传入”，否则它真的会给你写死个数字。另外异常处理我基本不指望AI，生成完代码我会自己过一遍try-catch和资源释放，就当它是个高级补全工具，别指望它能理解“这个接口超时了要降级”这种隐含逻辑。不过说回来，写那种纯helper函数或者DTO转换，它确实能省不少事，所以我现在是“算法题用AI，业务逻辑自己搭骨架，AI填肉”，这样效率反而高一些。

把业务规则拆成小函数再喂给AI，比让它一口气写完整流程靠谱得多。

试试把异常场景列成清单让AI逐条补，比让它自由发挥强。

说实话你这感觉太正常了，我拿Copilot写业务逻辑也经常被它“自作聪明”坑到。后来发现关键是把大需求拆成小函数，每个函数只给一个明确输入输出，再强制它补上边界条件，效果会好很多。另外异常处理这种，我都是直接在prompt里写“必须考虑所有失败路径”，不然它真就给你糊一版能跑的。工具确实适合算法题，但业务代码得靠你当“产品经理”去约束它。

把业务规则拆成小函数喂给AI，让它只补逻辑别自己发挥，异常处理自己再扫一遍就行。

你试试把表单校验拆成单个规则逐条问，别让它一次写完整段，效果会好很多。

说实话我也有同感，业务逻辑这东西AI真不是拿来即用的。我现在的做法是先把状态流转和异常分支画成伪代码或者表格丢给它，让它照着填空，而不是让它自己发挥，这样至少不会漏掉边界情况。另外你提到硬编码参数，我怀疑是上下文窗口不够，它没记住你项目里的配置常量，所以我现在会把关键变量名和约束直接写进system prompt里，效果会好不少。但即便如此，复杂表单校验那种牵一发动全身的逻辑，我最后还是要自己逐行过一遍，AI更像是一个高级补全工具，而不是能替你兜底的架构师。我甚至觉得，这类工具在业务代码上的瓶颈不是prompt技巧，而是它们对“隐性业务规则”的理解天然缺失，那些规则往往在需求文档之外。所以我现在只在写单元测试和重复性DTO转换时依赖AI，核心流程还是自己写，省下的时间其实有限。你要是找到了更好的调教姿势，记得回来分享一下，我也挺好奇的。

我跟你感觉挺像的，一开始也怀疑是不是自己不会用。后来发现，这种工具写业务逻辑确实得换个思路，你把它当成一个需要你带路的实习生，而不是全知全能的资深同事。像表单校验这种，我现在的做法是先把我自己定的、比较绕的规则用注释写死，再让它填代码，它就不太容易瞎发挥。另外，它老忘异常处理，我就干脆在prompt里加一句“所有外部输入都假设可能为null或空串”，效果立竿见影。硬编码参数这个，我试过把配置项的名字直接写在需求里，让它引用，能好不少。但说实在的，多状态流转这种，我自己画个状态机图，再让它对着图生成，比让它自己琢磨靠谱多了。我觉得不是姿势不对，是这类工具对“全局一致性”的理解还太弱，你把它拆解成一个个小步骤喂给它，它反而能给出不错的结果。

说实话我也踩过这个坑，后来发现写业务逻辑真不能指望AI一把梭。我的办法是先自己把状态流转和异常分支画个草图，再把关键约束直接写进prompt里，比如“这里必须有try-catch，金额参数不能硬编码”。另外，别让它一口气生成整个函数，拆成小步骤让它填空，改起来反而快。

说实话你这个问题问到点子上了，我也有类似的感觉。工具类、算法片段确实一生成一个准，但业务逻辑那种又臭又长的表单校验，AI经常给我漏掉边界情况，比如某个字段在特定状态下才必填，它直接给我写死成非空判断。我觉得核心问题不是prompt细不细，而是业务逻辑的“隐含规则”它根本没法从你的只言片语里推断出来，你得把状态流转的完整矩阵喂给它，它才能给你写出像样的东西。我现在一般会把相关的接口文档、数据库字段说明甚至前后端联调时的吐槽都贴进去，然后让它先列处理流程再写代码，比直接让它写有效得多。另外异常处理那块，我基本默认它不会主动加，会在prompt里明确要求“所有外部调用必须try-catch并返回统一错误码”，不然它真的敢给你裸奔。还有硬编码参数这个问题，我最近试了个办法，就是让它先定义常量或配置项，再写逻辑，稍微好一点，但还是得自己扫一遍。关键是你得把它当成一个特别聪明但特别健忘的实习生，每次都得把上下文说全，不能指望它记住前面聊了啥。反正我现在写复杂业务前，会先花十分钟把状态机和异常路径画出来，再让AI填肉，效率反而比纯靠它高。

业务逻辑的隐性约束太多，AI根本不懂上下文，你得把边界条件和异常流全写进prompt里，跟喂孩子似的。

我一般把核心规则拆成小函数让AI填实现，状态流转直接画个表给它，比纯描述强多了。

说实话你这感觉太正常了，业务逻辑本来就是AI最不擅长的领域。工具类代码是“输入输出明确”的封闭问题，但表单校验和多状态流转是“隐性需求密集”的开放问题，AI根本看不到你项目里那些约定俗成的边界条件。我试过把异常处理、参数校验、权限判断这些要求全写进prompt，结果它倒是记住了，但代码冗余得离谱，反而比我自己写更费劲。

后来我琢磨出的办法是：把业务逻辑拆成“骨架”和“血肉”两部分。先用自然语言把流程、状态节点、每个分支的触发条件列清楚，让AI只负责生成这个骨架的伪代码或空函数，然后我自己填血肉——那些具体的校验规则、数据库字段映射、外部接口调用。这样AI给的代码结构清晰，我改起来也不累，而且它不会在细节上自作主张。

另外我发现，与其让AI“写”业务，不如让它“补”业务。比如我先写一个粗糙但能跑的版本，然后让它帮我找bug、补边界case、优化异常处理，这个模式比直接让它从零生成靠谱得多。说到底，这些工具更像是“高级代码搜索引擎”加“自动补全plus”，不是真正理解业务含义的同事。你让它刷LeetCode当然爽，因为那些题目的需求本身就定义得和数学题一样精确。

业务逻辑的坑在于隐含规则太多，AI压根不懂上下文，我都是把异常分支和边界条件直接写进prompt里当约束喂给它。

你试试把校验规则拆成一条条给AI逐步生成，别让它一口气写完整个状态机，效果会好很多。

说实话你这个问题问到点子上了。我自己的感受是，这类工具对“有明确边界”的代码确实强，但业务逻辑本质是“一堆隐式规则和异常分支”的集合，AI靠猜肯定漏。我后来学乖了，不直接让它写整个函数，而是把状态流转拆成一张表格或者if-else的伪代码结构喂给它，让它只负责把每个分支填实，这样它漏异常的概率会低很多。另外，对于硬编码参数这种，我习惯在prompt里明确标注“所有关键值必须提成常量”，或者干脆写完让它自己review一遍再给我，效果比反复改快多了。

说实话你这个困惑挺典型的，我一开始也这样，后来发现根子不在prompt细不细，而是工具理解“业务约束”的能力太弱了。算法题和工具类本质是“输入输出明确、边界清晰”，但业务逻辑的坑全藏在那些隐性规则里，比如某个字段在A状态下不能改、某个操作必须带审计日志，这些你要是没提前写进上下文，AI大概率给你生成一个“看起来对但实际跑不通”的版本。我的做法是先把接口定义、状态机枚举、甚至异常码表直接粘进对话里，然后明确告诉它“只实现这个分支，别自己发挥”，同时强制要求每一步都写上try-catch和参数校验，相当于给它画个框。另外别让它一口气写整个流程，拆成小函数一步步来，每步都跑测试再继续，这样它就算硬编码你也能马上发现。还有个小技巧，把之前踩过的坑或者代码规范写成一条“铁律”放在prompt开头，比如“所有金额必须用分存储”，比在结尾补充有效得多。说实话，这些工具现阶段更像是“高级结对程序员”，你得不断review它的输出，指望它独立写完复杂业务还得再等几年。

说实话你这个问题我太有同感了，之前我也以为是自己prompt写得不到位，后来发现是思路没转换过来。像表单校验和状态流转这种，核心逻辑往往藏在业务规则里，AI根本不知道你项目里的上下文，你给它的信息再细，它也容易在边界条件上自作主张，硬编码参数这事儿我遇到太多次了。我的经验是别让它直接生成完整业务函数，而是把大流程拆成十几个小步骤，每个步骤用自然语言描述清楚输入输出和异常场景，这样它反而能写出更贴合你预期的代码。而且你写完还得自己过一遍关键分支，AI工具本质是个超级补全，不是业务分析器，它对“规则引擎”这类需要全局状态的东西天然不敏感。我现在比较靠得住的做法是，先把业务规则抽象成配置或数据表，再让AI只负责写解析和执行的壳子，这样它犯错的概率小很多。另外试试把异常处理直接写进prompt里，比如“所有数据库操作必须try-catch并记录日志”，比让它自己领悟靠谱。所以不是你姿势不对，是这类工具在纯逻辑探索上确实比业务落地强，得把它当结对编程的实习生使，而不是外包主力。

不是姿势问题，是这类工具本质上就擅长局部生成，不擅长理解你系统里的状态机。我的做法是先自己把状态流转和异常分支用注释写清楚，再让它按注释填逻辑，别指望它凭空猜业务规则。表单校验这种硬骨头，我一般拆成小函数一个个喂，附上两三个已有用例当参考，它就不太会乱硬编码了。刷题和写业务完全是两回事，前者边界清晰，后者你得先当架构师把约束讲明白。

业务逻辑得先喂背景和约束，光靠prompt不够，我一般是先写注释再让它补全。

业务逻辑得靠你把需求拆碎了喂它，别指望一句话生成，我都是先写注释再让它填代码。