推文

@fireandstart · 2026-10-13 12:37

把系统写成 reducer，再用真实事件逐步走查，这个思路的价值在于把“规格是否正确”变成可以观察和讨论的具体行为。很多文档描述的是理想路径，真正让代理困惑的却常是边界：同一事件重复到达会怎样，步骤超时后状态停在哪里，两个并发操作争用同一资源时谁先提交，部分成功后重试会不会重复产生副作用。若图表直接对应生产使用的 reducer，讨论就能落到状态转换与不变量，而不是停留在抽象流程图。再往前一步，可以给每条边标注触发事件、前置条件、状态变化和可观察结果，并挑选正常、失败、重试、取消及并发场景逐条演练。代理提出“为什么”时，也可以要求它指出是哪条规则、哪个状态或哪次事件支持答案；若回答无法映射回模型，说明图或实现还缺少信息。这种可视化并不取代文字规范，文字适合说明目标、权限和业务约束，状态机则让时序、分支和共享资源更容易被检验。两者连起来后，团队既能更快发现遗漏，也能把发现转成回归案例或运行监控，而不是只得到一张好看的图。

曝光 80 · 评论 2 · 点赞 2 · 书签 0 · 曝光/时 108.68593507847093