用AI写React组件时，prompt怎么加业务逻辑才不跑偏？

我自己的经验是，先给伪代码比画状态流转图靠谱，AI对具体逻辑的还原度更高，尤其是联动清空这种，直接写“当部门变化时，重置日期和关键词”反而容易让它自由发挥。禁用useEffect这招我试过，但得说得特别死，比如“只准在事件处理函数里改状态”，不然它还是会偷偷加。另外，小步prompt确实容易丢上下文，我现在习惯把整个组件的props和state先列成表格，再让它基于这个表写，跑偏率低不少。

我一般会把业务规则写成“如果A，则B，并且C不能动”这种带条件的句子，比单纯描述场景管用。至于useEffect，我会明确说“别用，所有联动都写在setState的回调里”，但有时候它还是会绕回去，所以最后都得自己review一遍。状态流转图我觉得对复杂情况有帮助，但简单联动真没必要，反而拖慢速度。你试试把“禁用”换成“推荐用xx方式”，AI通常更听话。

说个坑，我之前让它写联动，结果它生成了一堆watch，后来我改成把每个状态依赖关系用箭头写出来，比如部门→日期，日期→关键词，然后再加一句“只用useMemo和事件触发，别碰副作用”，效果好了很多。伪代码我觉得要看情况，太细了AI容易照抄逻辑错误，太

这事儿我太有同感了，之前用AI写带联动逻辑的组件，也是被它那套useEffect监听大法整得头皮发麻。后来我试下来，最稳的其实是直接在prompt里丢一段极简的状态机描述，比如“部门变化时，重置日期和关键词”，再补一句“所有状态更新必须写在事件处理函数里，禁止用副作用”。光靠业务场景描述它真的会自由发挥，你得给它画个边界。另外伪代码得给，但别给完整实现，给个类似“onDeptChange = () => { setDateRange([]); setKeyword(''); }”的骨架，它就能顺着写，基本不跑偏。关于禁用模式，明确写“不要用useEffect做数据联动”非常管用，AI对这类硬性约束执行得比模糊要求好得多。不过还是得留个心眼，生成完得自己过一遍依赖关系，尤其是那种跨组件传参的，AI很容易漏掉重置时机。

直接贴状态流转图最稳，再补一句“禁用useEffect联动”，AI立马老实。

先贴状态流转图再给伪代码，双管齐下最稳，最好把禁用useEffect写进prompt里。

我试过把状态流转图画进prompt，效果比伪代码稳不少，因为AI对文字描述的状态依赖容易产生幻觉，画成图反而能约束它。禁用useEffect这条很关键，我会直接写“禁止用副作用处理派生状态”，然后给一个简单的reducer示例作为风格锚点。另外建议把联动规则单独列成“当A变化时B必须重置”这种清单，比描述场景靠谱得多。你试试把prompt拆成“状态定义+组件结构+联动规则”三段式，能少很多幺蛾子。

我试过把状态流转图直接写进prompt，AI确实能少犯点逻辑错，但代码还是偏啰嗦。后来我学聪明了，先让它写一版最朴素的实现，再追加一条“重构：去掉所有useEffect，用派生状态或事件回调代替”，效果比一开始就限制模式好很多。另外，伪代码比文字描述管用，尤其是那种“当A变化时重置B”的规则，直接写if (deptChanged) resetDate()，它反而不会乱发挥。

先给状态流转图再贴伪代码，还得明说禁用useEffect，不然它老自作聪明。

我自己的经验是，把状态流转直接写进prompt里比贴伪代码稳，比如“部门变化时重置日期和关键词”，但得用if条件句明确写死，AI就不会自己发挥useEffect了。另外我会在prompt末尾加一句“只修改组件内部逻辑，不要新增hooks或副作用”，基本能挡掉一大半冗余代码。禁用useEffect这招挺有效的，但其实也可以让它用派生状态或者key重置，关键还是得给它一个具体的输出约束，比如“所有联动都写在事件处理函数里”。

我试过最管用的办法是直接在prompt里贴状态流转表，比如“部门变化→清空日期→保留模糊搜索”，再补一句“禁止用useEffect做联动”。AI对显式约束比语义描述敏感得多，基本不会跑偏。伪代码也行，但别写太细，不然它容易照着你的代码风格硬套反而出bug。另外建议把“假逻辑”的典型特征也写进negative prompt里，比如“不要监听非依赖项”，实测能省不少返工时间。

我一般会把状态流转直接写成注释塞进代码块里，比如“部门变化时清空日期”，这样AI更容易理解约束而不是自由发挥。禁用useEffect这招挺有效的，我通常会明确让它用派生状态或者事件处理器里做联动，生成代码干净很多。不过小步prompt确实容易丢失全局上下文，我现在习惯把关键依赖关系写成一个简单的状态表，再配一段伪代码，效果比纯文字描述稳定不少。

说到这个我太有同感了，之前搞过一个类似的联动筛选，AI给我写了三个useEffect互相监听，跑起来直接死循环。后来我发现，光说“自动清空”这种业务描述确实不够，它根本分不清哪些状态是主动改的，哪些是被动联动的。我的土办法是直接在prompt里写死“只有部门变化时才触发清空，其他情况一律不动”，然后明确告诉它“禁止在useEffect里改state，所有联动逻辑都写在事件处理函数里”。这样虽然粗暴，但输出基本稳定，改起来也快。

至于状态流转图还是伪代码，我试下来觉得伪代码更实用，尤其是那种“if 部门变化 then 清空日期”的简单逻辑，直接贴给它，它就不会自由发挥了。但有个坑是，伪代码贴多了，AI容易照抄结构，反而忽略组件本身的层级关系，所以我会在最后加一句“保持原有props和state结构不变，只改函数内部实现”。另外，你提到禁用useEffect，我觉得这个思路对，但别完全禁，有些初始化场景还得用，不如说“除初始化外，禁止用useEffect做数据同步”，这样更精准。

还有个疑惑想问问，你拆小步prompt的时候，是每步都让AI重新读一遍上下文吗？我有时候拆太细，它反而忘了前面需求，得反复提醒，感觉比一次性写还费劲。

先把状态流转图画给AI看，再明确禁用useEffect做联动，我试过这样基本不跑偏。伪代码反而容易让它抄出冗余逻辑。

我自己的经验是先贴伪代码比描述业务场景管用，AI对状态流转的文字理解容易发散，但你给它一个if条件里写setState的骨架，它基本不会跑偏。另外像useEffect这种联动写法，我一般会在prompt里直接点名“不要在useEffect里处理派生状态，用事件回调或者useMemo”，不然它真的太爱用那一套了。不过拆小步这个方向我觉得没错，但别拆太碎，不然上下文丢了反而更乱，最好是先把核心状态关系图给它看，再让它补全UI细节。

我试过类似场景，最稳的办法是直接在prompt里给一段最小可复现的伪代码，把状态流转写死，比如“当selectedDept变化时，重置dateRange和keyword”。AI对代码比自然语言敏感得多，纯文字描述它容易自由发挥。禁用useEffect这个建议挺有效，我一般会加一句“不要用副作用处理派生状态”，它就会老实很多。另外小步prompt确实容易丢失上下文，建议把整个组件的props和state先列个表格给它。

我自己的经验是，把状态流转图直接写进prompt比伪代码管用，但别画得太细，AI容易把图里的分支理解成硬编码。比如你那个“选部门清空日期”，我会写清楚“部门变化是唯一触发源，日期范围初始值固定”，它就不太会乱加useEffect。至于禁用模式，我一般会加一句“不要用副作用处理派生状态”，比单纯说“别用useEffect”有效，因为AI有时会换个方式绕回来。另外我习惯在prompt末尾加个“如果逻辑需要跨状态联动，先列出所有触发条件再写代码”，这样它生成的东西基本能一次过。

我试过把状态流转图写进prompt，效果比伪代码稳，AI能理解依赖关系，但图别画太细，否则它容易过度设计。禁用useEffect这招挺管用，我一般直接写“禁止副作用，用派生状态”，它就会老实很多。另外小步prompt确实容易丢上下文，建议把核心联动规则单独拎出来重复强调两遍，比堆一堆描述强。

我试过把状态流转直接画成文字描述塞进prompt，比贴伪代码好使，但关键是得把“谁触发谁变化”的边界写死，不然AI还是会自由发挥。禁用useEffect这招挺有用的，我一般会加一句“所有联动逻辑必须写在事件处理函数里”，输出立马干净很多。不过小步prompt确实容易丢上下文，我现在习惯先给它一个总纲，再分步补充细节，比一次性全塞进去稳。

我试过类似场景，最稳的办法是直接给伪代码，把状态流转写死，比如“当部门变化时，清空日期范围”，AI反而能理解。别让它自由发挥useEffect，我一般会在prompt里加一句“禁止用副作用处理联动，改用派生状态或事件回调”，效果立竿见影。另外，拆小步是对的，但拆完每一步都要带上下文，不然它容易断片。

我一般会先在prompt里把状态依赖关系用箭头写清楚，像“部门变化→清空日期→重置页码”，再贴一段简化的状态机伪代码，这样AI生成逻辑时不容易自己脑补。禁用useEffect这个我试过，挺有用的，直接说“数据联动用事件处理函数，禁止在渲染阶段派生状态”，代码会干净很多。不过你拆小步prompt是对的，但每步最好让它先输出状态变更函数，再补UI层，别一次性喂太大。

先贴状态流转图再给伪代码，明确禁掉useEffect联动，我试过这招稳多了。