前端状态机 + AI 生成：用显式转移代替散落 Boolean

背景

前端逻辑里最常见的 entropic 形态是一堆布尔：isLoading、isError、isEmpty、isSubmitting……它们可以组合出非法态（同时 loading 又 error），而散落的 setState 很难审查。显式状态机（有限状态 + 允许的事件转移）把非法组合从类型与测试层面排除。

当用 AI 生成表单流、向导或异步按钮逻辑时，若只给散文需求，模型很容易继续堆布尔。给它一张状态表与转移表，生成结果通常更可测、更易 Diff。

要点

1. 状态是互斥的：idle | loading | success | error，而不是四个独立 bool。
2. 事件触发转移：SUBMIT / RESOLVE / REJECT / RESET；未声明的转移直接拒绝。
3. 副作用挂在转移上：请求只在进入 loading 时发起，避免重复 fire。
4. 可测试：对每个合法转移写表驱动测试；AI 改代码时以转移表为契约。

状态机不必上重型库；小型手写 reducer 或轻量 XState 式描述都能工作。关键是 显式。

怎么做

1. 先画表：列出状态、事件、下一状态、守卫条件（例如未填完不能 SUBMIT）。
2. 把表放进 Spec：Markdown 或 JSON；Agent 实现时必须对齐，禁止私自加布尔捷径。
3. UI 映射：每个状态对应明确视图（骨架屏 / 成功 / 错误重试），减少条件渲染嵌套。
4. 测试：给定 (state, event) 期望 next；对非法事件断言不变或抛错。
5. 评审 Diff：看转移表是否被悄悄扩大；扩大必须更新测试与文案。

idle --SUBMIT--> loading --RESOLVE--> success
                    |--REJECT--> error --RETRY--> loading
success|error --RESET--> idle

AI 生成时，要求输出「状态枚举 + reducer + 测试表」三件套，比只要一个组件文件更不容易回归。

和本站工具

• JSON：维护机器可读转移表。
• Markdown：写人读状态说明。
• Diff：对比生成前后的状态定义。
• 正则：校验路由或表单字段模式。

入口：Tools 首页。

与设计系统协作时，把每个状态对应的文案与空态插画 id 写进转移表旁注，避免开发与设计各说各话。无障碍方面，loading 与 error 需要可感知的状态公告（aria-live），这些要求也可当作转移上的副作用清单，让 AI 生成时不漏。

对于服务端组件与客户端岛屿混合的架构，状态机通常落在客户端交互岛内；服务端负责初始数据。规格里写清「哪些状态只存在于浏览器」，可减少 AI 把服务器变量当成客户端布尔乱传的问题。评审时盯住：是否引入了无法从转移表推导的隐式状态——有则打回。

落地时可先从一条最痛的用户流试点（例如结账或登录），状态机跑通后再推广到次要页面。试点阶段强制代码评审对照转移表，形成团队肌肉记忆。若使用 TypeScript，用联合类型表达状态，让非法字段组合在编译期失败——这对 AI 生成代码是一层便宜的护栏。补充测试时优先覆盖「错误后重试」与「成功后重置」，这两类转移最容易被布尔写法写漏。

小结

用显式状态机约束 AI 生成的前端异步流，能显著减少非法组合与「改绿测试」。先表格、后代码、测试钉死转移——这是可复用的工程模式，不依赖某个框架品牌。