本节要解决的事:修改计划条件,会改变依赖它的判断;已经发生的订单不会因为计划里的金额变了而自动消失。
从 500 改到 300,别把所有东西都推倒
原预算 500。供应商 A 报价 420、B 报价 280;两家规格和库存都符合,A 到货更快。系统因此选 A,并生成待确认草稿。用户随后说“预算改成 300”。A 的报价仍可能是有效的真实观察,但“A 可行”的判断已经失效,基于它生成的草稿也需要更新。
朴素做法只把页面上的预算数字替换掉,继续保留“推荐 A”与旧审批按钮。另一个极端是删除全部材料重新查一遍。正确处理应沿依赖关系传播:预算影响可行性,可行性影响选择,选择影响草稿与批准。若报价仍在有效期且未被新信息否定,可以保留,避免不必要工作。
状态要记录事实和判断各自的依据
可以把预算标为 v2=300,保留报价来源与时间。每个派生结论记录使用了哪版约束:A 可行使用 v1,故需重算;B 280 不超过 300,可以进入新候选。新的草稿应明确基于 v2;之前针对 A 420 的确认不能自动移用到别的供应商、数量或金额。
这不是要求每个小应用都实现复杂数据库。即使是一份可审查表格,也应区分原始观察、推导结果和已经执行动作。问题在于信息能否追溯和失效,而不是用了哪种框架名。
相同预算变化,发生时点不同
先做预测,再逐步展开。这里是固定规则的教学回放,不是真实模型测评。
教学构造场景 · 按下方规则逐步回放;不调用真实模型,不代表实际成功率。
预算从 500 降到 300;A 420、B 280;订单尚未提交。
- 1. 更新约束
建立有效预算 300。
- 2. 重算选择
A 超额 120;B 余量 20,候选改为 B。
- 3. 更新产物
撤下旧 A 草稿的执行入口,形成 B 草稿等待适当确认。
建立有效预算 300。
先预测,再核对结果与原因
可以重算,尚无订单副作用变化影响计划和候选,不需要假装撤销未发生的订单。
把新状态传给下一节点
工作流节点不能只读启动时的一份旧副本。提交前应检查当前有效状态及版本,如果用户在查询期间改变约束,旧结果可作为事实返回,但不能让旧决策直接越过执行关口。这和上节并行有关:较晚返回的工作者可能仍基于旧预算,需要被协调者重新解释。
哪些变化值得使结果失效
预算变低通常影响金额可行性;收货日期变早影响交付选择;用户只修改页面标题,通常不影响库存事实。失效范围应由真实依赖决定,不能因为任何文字变动就整条重跑。过宽会浪费成本,过窄会继续使用旧结论。
再比较可逆草稿和不可保证可逆的外部动作。草稿可以重新生成,但订单可能已经进入发货,退款可能需要条件或费用。此时应把当前状态、可采取动作和剩余限制说清楚,不承诺“已撤回”除非有对应执行证据。用户新请求可能授权处理,但具体不可逆动作仍需遵守会话中已明确的范围。
还有一个容易遗漏的边界:新约束可能没有任何可行方案。如果 A 420、B 380,而预算改成 300,正确结论是当前两家都不满足,下一步需搜索替代或说明取舍。不能为了维持“完成”状态,悄悄沿用旧预算或把总价拆成看起来更小的部分。
理解检查
问题一:预算改变,为什么不必删除 A 的 420 报价? 因为它是环境观察,预算不决定供应商报价。需要改变的是关于可行性和推荐的判断;若报价本身过期,则是另一个刷新理由。
问题二:旧批准同意花 420,为什么不能自动购买 B 的 280? 因为批准可能针对具体供应商、商品和条件,不能只按金额较低推断可以替换。应按原授权含义判断,必要时让新候选重新确认。
问题三:从计划中删掉已提交订单那一行,是否恢复到了未下单状态? 不会。外部环境不会被文档编辑倒转。需要查询真实订单并通过相应取消流程处理,记录任何无法撤销的结果。
下一问
这些依赖和检查点看起来很像固定工作流。下一节把固定节点和模型循环叠在同一张流程上,看看它们怎样组合,分别负责什么。