工具笔记
让 AI 重构保存状态：一次提交只有一个状态
用可辨识联合约束提交过程。
资料核验2026.11.12 · TypeScript · 建议开启 strict 模式
表单同时出现「正在保存」和「保存成功」，因为一个分支更新了成功标志，忘了把 loading 清掉。单次提交只有一个当前状态，可以直接把它写进类型。
让助手从这一步开始
给助手一张允许的状态表，要求用 status 表达 idle、saving、saved、failed。只有 saved 带记录 ID，只有 failed 带错误。请它指出重复点击和旧请求晚回分别怎么处理。
让每种状态只带自己的数据
用共同的 status 区分 idle、saving、saved 和 failed。成功分支才带记录 ID，失败分支才带消息。渲染时按 status 切换，编译器会跟着收窄。若用 never 做穷尽检查，后来增加离线状态时，没处理的分支能在编译阶段暴露。
用一次成功保存和一次失败保存验收。再试在请求尚未完成时重复点击，观察当前状态与界面是否一致。
如果允许两个请求并发，另加请求身份，避免先发后回的旧结果覆盖新状态。
把问题变成可重跑的样例
最小演练是「输入草稿 → 保存中 → 失败 → 重试 → 成功」。逐步记下按钮可用性、消息和草稿值。最后加入一个从未处理的状态，检查渲染分支能否在编译阶段暴露遗漏。
核对这几项输出
- 提交时只显示保存中。
- 成功后展示记录信息。
- 失败后保留草稿和重试入口。增加新状态时，相关渲染分支应该能由类型检查提醒。
怎么判断改动能不能收
可辨识联合解决单个状态对象同时带两组矛盾属性的问题。多个并发请求的先后顺序还需请求 ID 或取消机制。把这两层分别验收，不要靠状态类型推断网络行为。
若任务需要从多个组件触发保存，额外把用户动作和状态变化分别列出来。组件不必知道所有服务细节，但要约定一次保存失败后何时允许重试。用同一次请求 ID 将消息、按钮和草稿关联起来，便于定位晚回的问题。
