豆包需严格按四步输出状态建模方案：①拆解用户行为；②列出状态变更；③给出Zustand store结构；④指出易错点。触发前须确认【当前项目约束】，且输入必须含组件名、已知状态变量、技术栈版本。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你想让豆包每次都能稳定输出符合 React 或 Vue 项目实际需求的状态管理设计思路，而不是泛泛而谈“用 useState 就行”或堆砌概念术语，就得把提示词固化为可触发、可复用、带上下文锚点的工作流。
先筛出真正该交给豆包处理的状态管理任务
只对结构清晰、有明确输入输出边界的状态问题启用工作流：比如“从 Figma 页面标注中提取 5 个交互组件，推导其状态字段与流转逻辑”，而不是“帮我设计整个后台系统的状态”。前者输入是标注文本+截图描述，输出是字段表+状态图文字版；后者无边界、无锚点，豆包必然发散。
检查你手头的任务是否满足三个硬条件：【必须提供具体组件名称】（如“订单筛选弹窗”）、【必须给出当前已知状态变量名】（如“loading、error、selectedTab”）、【必须限定技术栈版本】（如“React 18 + Zustand 4.4”）。缺一不可，否则豆包会默认用最简方案应付。
用豆包自定义指令搭出固定触发入口
方法一：创建“前端状态建模”指令
进入豆包主界面→点击右上角“+”→选择“创建新指令”→命名为“前端状态建模”→在描述栏粘贴以下内容：
你是一位有 4 年中后台前端开发经验的架构协作者，专注 React / Vue 状态治理。当用户输入“状态建模：[组件名]”时，请严格按以下顺序执行：① 拆解该组件用户可见行为（点击/输入/加载/错误等）；② 列出每个行为触发的状态变更（含来源字段、目标值、副作用）；③ 输出 Zustand store 结构建议（含 action 名称、state 字段类型、selector 示例）；④ 补充 1 条该场景下易踩的坑（如“不要在异步 action 中直接 setState”）。
保存后，在聊天框输入“状态建模：用户权限配置抽屉”，豆包就会自动走完四步输出。
方法二：快捷短语绑定（适合高频小任务）
在豆包设置中开启“快捷短语”，新增一条：“sm-props”，对应展开文本为：“请基于以下 props 接口，反推组件内部应维护哪些本地状态？哪些应提升至父级？哪些需从 store 订阅？接口：”。这个短语一触发，你就直接粘贴 TypeScript Props 定义，不用再打一遍说明。
给提示词注入真实工程上下文
第一步：在指令描述末尾强制添加【上下文锁】字段
在“前端状态建模”指令的描述底部，空一行后写：【当前项目约束】：Monorepo 结构；UI 库为 Ant Design v5；状态库统一用 Zustand；禁止使用 Context API 做跨层级状态共享；所有 store 必须导出 useStore hook。
第二步：要求豆包每次输出前先确认上下文
在指令逻辑中加入一句：“输出前先用一句话确认你已读取并遵守【当前项目约束】”。这能拦住豆包擅自切换技术方案——比如它想推荐 Jotai，就会被自己卡住，转而适配 Zustand。
第三步：用真实代码片段替代抽象描述
不要写“用户点击按钮后状态变化”，要贴一段真实代码：const [open, setOpen] = useState(false); // 当前控制抽屉显隐。豆包看到真实 useState 调用，才会意识到这是“已有局部状态”，进而判断哪些该保留、哪些该迁移。
批量生成状态文档的自动化衔接
步骤一：在飞书多维表格建一张“状态设计待办表”，字段包括【组件名】、【Props 接口】、【所属模块】、【状态建模完成时间】。
步骤二：配置飞书机器人自动化规则：当【组件名】不为空且【状态建模完成时间】为空时，自动拼接 prompt → “状态建模：{组件名}。Props 接口：{Props 接口}。” → 发送至豆包 AI 接口 → 将返回结果填入新字段【豆包输出】。
步骤三：人工校验【豆包输出】后，在表格中手动填写【状态建模完成时间】，触发下一流程：自动生成 Confluence 文档草稿。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
