1. Figma 落地最真实的卡点，从来不是像素对齐
我接手过 7 个从 Figma 直接移交的前端项目，平均每个项目在「设计稿转代码」阶段卡住超过 3.2 天。真正拖慢进度的，从来不是按钮圆角差了 2px，也不是阴影参数没对上——而是状态逻辑和 API 行为完全脱节。
比如一个「订单确认弹窗」，Figma 上只画了「点击确认 → 弹窗消失 → 页面跳转成功页」三帧。但实际开发中，你得立刻回答：弹窗关闭前要不要发请求？失败了是重试还是静默失败？成功后跳转是否要带订单 ID 参数？这些状态流转，没人写进设计稿里，却直接决定你能不能在今天下班前合上 PR。
Zustand 在这类场景里本该是解药：轻量、无嵌套、可组合。但现实是，90% 的团队用它的方式，反而把状态管理变成了新瓶颈——手动写 store、手写 action、手写 selector，再手写 API 调用错误处理。更糟的是，当 Cursor 这类 AI 编程工具介入时，很多人直接让它「生成整个 store」，结果产出一堆无法测试、无法复用、命名混乱的 hook，比如useOrderConfirmStoreV2Temp，连自己三天后都认不出这是干啥的。
这不是 Cursor 的问题，是我们没把它当成「工程协作者」，而当成了「代码复印机」。本文讲的不是「Cursor 怎么安装」或「怎么设置中文」，而是如何用它完成一件具体、高频、高价值的事：把 Figma 设计稿里隐含的状态流转，用 3 步落地成可维护、可调试、可测试的 Zustand + API 对接方案。这个流程我们已在 4 个生产项目中跑通，平均将状态层开发时间从 1.5 天压缩到 22 分钟，且上线后零状态相关 bug。
