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

我最近也被这个坑过，后来发现把状态流转直接写进prompt里比贴伪代码管用，比如“部门变化时清空日期和搜索词”这种明确规则，AI就不太会自己脑补。禁用useEffect这个思路我试过，简单场景有效，但复杂联动反而容易让AI绕去写更乱的逻辑，不如给它一个具体的reducer示例。另外我习惯在prompt末尾加一句“只修改相关状态，不触碰其他数据”，能明显减少冗余代码。你试试把业务规则列成bullet point，比大段描述要稳。

这问题太真实了，我踩的坑比你还深。你那个“用户选部门后日期清空”的联动，本质是状态机转换，不是副作用，所以AI天生爱用useEffect纯属因为它见多了烂代码。我现在做法是先把props、内部state、派生值用一行行注释写清楚，再画个简单的表格描述状态流转，比如“部门变化→清空日期+重置页码”，然后明确告诉AI“禁止使用useEffect处理派生状态，用事件处理器里直接setState”。伪代码反而容易把AI带沟里，它会照着你的写法去补全，而不是理解意图。另外一定要在prompt里加一句“如果逻辑有分支，先列出所有可能场景再写代码”，这能逼它把边界条件想全。还有个技巧，给它一个“反例”提示，比如“不要用watch监听对象深比较，用显式的事件触发”。你试试把状态流转图写成表格，配合一句“所有状态变化必须由用户操作或异步回调触发”，输出稳定很多。

直接给伪代码最稳，状态流转画图AI根本看不懂，还得靠你盯逻辑。
另外必须禁用useEffect，不然它铁定给你整一堆监听，手动触发函数写清楚反而简单。

带状态依赖的联动逻辑，我试过最稳的方式是先把状态机画出来，哪怕用文字描述“部门变化时清空日期”这种具体动作，也比直接贴伪代码强。因为AI对伪代码的理解容易停留在表面，反而会自己脑补出多余的状态重置逻辑。至于useEffect，我基本都会在prompt里明确写“禁止用useEffect处理派生状态，改用事件回调里手动赋值”，这样能砍掉八成冗余代码。另外有个小技巧，把业务规则拆成“当X变化时，Y必须重置为默认值”这种一条条的清单，比大段描述场景更有效。不过我也遇到过AI把规则冲突的情况，比如两个条件同时触发时优先级没写清楚，它就会随机选一个。现在我会额外加一句“如果多个规则冲突，以清单顺序靠后的为准”，输出稳定不少。你那个多选联动日期范围的场景，建议把“清空”动作直接绑定在部门选项的onChange里，别指望AI自己推导依赖关系。

直接贴伪代码比画状态流转图管用，AI对具体逻辑的模仿能力远强于抽象理解。我一般会把联动规则写成if-else注释塞进prompt里，它能照着写对八成。另外明确禁止useEffect做联动是对的，我试过加一句“状态变化用事件回调触发，不要用副作用”，生成代码干净很多。不过小步prompt确实容易丢失上下文，建议每次只改一个依赖关系，测试通过再继续。

我自己的经验是，直接贴伪代码比画状态流转图好用得多，AI对具体逻辑的模仿能力比对抽象描述强。而且明确写一句“不要用useEffect处理派生状态”很有必要，否则它真能给你整出十来个监听器。但光说禁止不够，最好顺带给个替代方案，比如让它用事件回调里手动重置状态，这样它跑偏的概率小很多。另外小步prompt确实有效，但每步都得把上一步的代码粘回去，不然它容易失忆。

先给AI喂状态流转图，再补一句禁用useEffect，实测能砍掉80%的假联动。

先贴伪代码比状态流转图好用，但千万别贴完整实现，给个关键分支的骨架就行。我试过明确写“禁止用useEffect做派生状态”，AI会老实很多，改成计算属性或事件里直接set。另外把“清空日期”这种动作拆成独立函数命名，prompt里点一句“所有联动必须调用resetXXX”，比描述业务场景靠谱。不过小步prompt还是得配一个总纲，不然改着改着就忘了原始约束，尤其是多选和模糊搜索的优先级，得在每次子任务里重复强调。

我踩过类似的坑，现在基本是先把状态流转图用文字画出来，比如“部门变化→清空日期→重置页码”，再让AI按这个顺序写逻辑。禁用useEffect做联动这点特别关键，直接写明“数据变化时在事件处理函数里手动更新其他状态”，生成代码干净多了。伪代码建议别贴太细，给个关键分支的伪码就行，不然AI容易照搬结构反而忽略业务边界。

我觉得先贴状态流转图比伪代码管用，AI对图的理解比想象中好，但得用文字把每个状态的触发条件写死，比如“部门变化时清空日期”。禁用useEffect这事我试过，直接在prompt里写“禁止用副作用处理联动，改用派生状态”，效果立竿见影，代码干净很多。不过小步拆解还是得做，但别拆太碎，每次给一个完整闭环的功能点，否则它容易忘掉之前的约束。另外可以试试给它一个“反例”，把之前生成的垃圾代码贴进去，明确说“不要模仿这种写法”，有时候比正向描述更有效。

我一般是先给一段伪代码把状态流转写死，再让AI补UI细节，这样它基本不会自己发挥。另外禁掉useEffect那步太关键了，直接写“不准用副作用处理派生状态”，不然它老给你整些监听地狱。

这问题太真实了，我最近也在用AI写类似的状态联动筛选器，试了一圈下来感觉最稳的反而是“伪代码+明确约束”的组合。你光描述业务场景，AI确实容易脑补出一堆副作用，特别是它特别喜欢用useEffect去监听所有东西，明明很多联动在事件回调里直接setState就能解决。我现在写prompt会直接给它一个状态流转的骨架，比如“onDepartmentChange时清空dateRange，同时保留keyword”，再附上两行关键伪代码，它立刻就懂了我的意图。另外我还会在prompt末尾加一句“禁止使用useEffect处理用户触发的同步状态变更”，这个挺管用的，能砍掉八成冗余逻辑。不过有个新问题想请教，如果业务规则特别多，比如有五个筛选条件互相清空，这种复杂依赖你一般怎么组织prompt？是一次性全写出来让AI处理，还是拆成多个小组件分别写？我总担心拆太细反而增加组件间通信的成本。

先给状态流转图再补伪代码，同时明确写禁止useEffect做联动，实测能少一半垃圾代码。

我自己的经验是，状态流转图比伪代码好用，但得画得够细，比如直接写“部门变化时，日期范围重置为空数组”这种具体动作，AI反而能抓住要点。另外禁用useEffect这招挺有效的，我一般会在prompt里加一句“数据联动用事件或派生状态处理，别用副作用”，生成代码干净不少。不过小步prompt确实容易丢上下文，我后来是把关键依赖关系单独列成一个清单，每次粘进去，再让AI按步骤输出，稳定多了。你试试把“清空”这种词换成“重置为初始值”，有时候AI对业务语义的理解会偏差很大。

先给状态流转图再加伪代码，同时直接写死“禁止useEffect做联动”，实测能少一半返工。

我一般会把状态流转直接画成表格塞进prompt里，比如“部门变化时日期重置，日期变化时部门不清空”，AI理解起来比纯文字准得多。禁用useEffect这条我试过，明确写“用派生状态或事件回调处理联动”确实能砍掉一堆幽灵代码，但偶尔会矫枉过正，得在prompt里补一句“允许在提交时统一校验”。伪代码我觉得没必要，除非你连边界条件都懒得描述，不然AI容易照着你的逻辑硬抄反而更绕。

说实话我踩坑下来觉得直接贴伪代码最管用，尤其是状态依赖这种逻辑，AI对文字描述的歧义太大了。我一般会在prompt里明确写出“禁止用useEffect做数据联动，改用派生状态或事件里手动处理”，这样生成的代码干净很多。另外状态流转图可以画，但别指望AI一次看懂，不如把每个依赖关系拆成一条独立规则写清楚。

我试过类似情况，业务逻辑别全塞给prompt，先把状态流转图写清楚比啥都强，AI对“先A后B”的时序关系很敏感。禁用useEffect这招挺有用，我一般直接写“禁止用副作用处理数据联动”，然后让它用派生state或者reducer。另外你可以试试在prompt里给一个最小可运行的数据流示例，比贴伪代码管用，AI能照着样式推理。不过说实话，复杂联动最后还是得自己动手改，AI当个初稿生成器就行。

这个问题我太有感触了，之前用AI写类似联动筛选器的时候也踩过同样的坑。我的经验是，光写状态流转图不够，AI对“清空”这种动作的理解经常是直接重置整个state，而不是精准地只清日期字段，所以后来我干脆在prompt里把每个交互节点的“前置条件”和“副作用”用列表写死，比如“当部门变化时，重置dateRange为[]，但保留keyword”。至于禁用useEffect，我建议你直接写明“禁止用useEffect监听状态变化来触发联动，必须在事件处理函数里同步修改相关state”，这样它就会老实很多，不然十次里有八次给你搞出一堆依赖数组的鬼东西。另外我有个疑问，你试过把伪代码和自然语言混着写吗？我发现对Cursor来说，给一段简洁的伪代码框架（比如用注释标注关键逻辑），比纯粹描述业务场景要稳定得多，但伪代码别太详细，否则它容易照着结构抄，反而忽略边界情况。最后补充一点，如果组件特别复杂，我一般会让AI先生成一个纯UI版本，再单独用一轮对话专门加交互逻辑，这样它不会把样式和状态搅在一起，不知道你试过这个路子没？

伪代码最稳，再补一句“禁止useEffect联动”，状态流转直接写进类型定义里，AI基本不跑偏。