设计计算、校验、联动与自动动作
本章目标：把适合自动完成的业务规则设计成可理解、可测试的动作，同时知道哪些决定不应被盲目自动化。
1. 自动化的目标不是“尽量不让人参与”
适合自动化的工作通常具备以下特点：
- 规则清楚；
- 输入可获得；
- 结果可验证；
- 重复频繁；
- 人工处理容易遗漏或算错。
例如：
- 数量 × 单价得到行金额；
- 汇总所有行金额；
- 选择物品后带出规格；
- 提交前检查必填内容；
- 审批通过后通知行政。
不适合直接自动化的工作：
- 规则仍在争议中；
- 需要综合经验判断；
- 错误后果很高且没有人工复核；
- 缺少可靠输入；
- 异常占比很高。
2. 区分四种常见设计手段
2.1 默认值
新建时预先填入常见内容，例如申请日期默认当天。
2.2 计算
根据当前数据持续得到一个结果，例如行金额和总金额。
2.3 校验
判断当前输入是否允许保存或进入下一阶段，例如数量必须大于零。
2.4 动作
在某个事件发生时执行一组操作，例如点击“选择物品”后带出规格和预计价格，再重新计算金额。
选择最简单、最贴合业务含义的方式。简单的金额计算不需要设计成复杂动作流；需要多步查询、判断和反馈时，才适合动作。
3. 用“事件—条件—动作—结果”描述自动化
每条动作设计都写四部分：
| 部分 | 采购案例 |
|---|---|
| 事件 | 用户修改明细数量或预计单价 |
| 条件 | 数量和单价都有有效数字 |
| 动作 | 重新计算当前行金额，再汇总申请总额 |
| 结果 | 页面显示新金额；流程判断使用最新总额 |
还要补充失败处理：
如果数量或单价无效，不计算新金额，并在对应位置提示原因。
4. 设计触发时机
常见时机：
新建时
适合默认值、初始化和首次带出。
字段变化时
适合联动、即时计算和输入提示。
用户点击按钮时
适合明确由用户发起、可能需要确认的操作。
保存前
适合影响数据完整性的最终检查。
保存后
适合依赖“已经保存成功”这一事实的后续处理。
进入查看或修改时
适合根据当前状态准备展示，但不要无故修改业务内容。
触发时机决定用户体验和业务正确性。需要保存成功后才成立的事情，不能提前在保存前宣布完成。
5. 计算规则要写清精度和顺序
采购金额示例：
- 行金额 = 数量 × 预计单价；
- 每行金额保留两位小数；
- 总金额 = 所有有效行金额之和；
- 删除明细行后重新汇总；
- 金额变化后，提交时按最新总金额选择审批路线；
- 总金额不允许人工修改。
必须确认：
- 是先对每行取两位小数再汇总，还是汇总后统一取两位；
- 空行是否参与；
- 负数是否允许；
- 修改审批中的金额是否需要重新提交。
这些看似细小，却会直接影响审批和统计。
6. 数据带出和查询要考虑“没有、一个、多个”
例如按物品名称查询规格和参考价格：
- 没有匹配：提示用户没有找到，不要静默填空；
- 正好一个：可以带出；
- 多个匹配：让用户选择，不要随意取第一条；
- 来源信息缺失：说明缺失项，并决定是否允许继续；
- 来源后来变化：已保存申请是否保留当时值，需要业务确认。
任何“自动取数”都应设计这三种数量结果。
7. 自动动作必须可解释
用户应该知道：
- 为什么这个值发生变化；
- 信息来自哪里；
- 是否可以修改；
- 何时会重新计算；
- 操作失败后发生了什么。
例如物品价格自动带出后，可以清楚标识为参考价格；若允许人工调整，应说明调整原因是否必填。
黑盒式自动化会让用户不信任应用，并在外部重新计算。
8. 防止重复执行
用户可能因为页面没有及时反馈而连续点击两次，或者在失败后重试。
业务设计应明确：
- 重复点击“提交”不能创建两个审批；
- 重复点击“生成编号”不能得到两个正式编号；
- 同一通知是否允许重复发送；
- 同一外部业务是否允许重复创建；
- 重试时如何识别已经成功的结果。
可以用业务语言写成不变量：
同一项采购申请在一次提交过程中，只能形成一条有效审批路线。
9. 设计执行顺序
采购提交前可能依次需要：
- 检查明细是否完整；
- 重新计算行金额；
- 汇总总金额；
- 检查高金额说明；
- 保存申请；
- 提交审批；
- 告知用户提交结果。
顺序错误可能导致：
- 用旧金额选择流程；
- 保存失败却已经发出通知；
- 审批已经创建，申请内容却没有保存；
- 用户看到成功，实际只完成了一半。
动作设计器的执行顺序和分支操作可参考动作系统概述、触发器与事件与执行顺序。
10. 设计失败和补救
每个重要动作问：
- 哪一步可能失败；
- 失败后已经完成了什么；
- 是否可以安全重试；
- 用户看到什么；
- 谁可以处理；
- 是否需要记录供排查。
示例：
| 失败 | 用户提示 | 业务状态 | 下一步 |
|---|---|---|---|
| 明细不完整 | 指出具体行和字段 | 保持草稿 | 修改后重提 |
| 找不到审批人 | 说明无法提交 | 保持草稿 | 联系应用管理员 |
| 通知发送失败 | 不把审批说成失败 | 已进入审批 | 系统重试或人工查看待办 |
| 带出价格失败 | 说明未找到价格 | 表单仍可编辑 | 人工填写或更换物品 |
不同失败不能都显示同一个“操作失败”。
11. 动作设计表
| 编号 | 名称 | 事件 | 条件 | 动作 | 成功结果 | 失败处理 | 规则来源 |
|---|---|---|---|---|---|---|---|
| A-01 | 计算行金额 | 数量/单价变化 | 两者有效 | 数量×单价 | 显示两位小数金额 | 指出无效输入 | BR-01 |
| A-02 | 汇总总额 | 行金额或行变化 | 有有效明细 | 汇总金额 | 更新总额 | 无明细时为空 | BR-02 |
| A-03 | 提交前检查 | 点击提交 | 当前为草稿/退回 | 检查明细和说明 | 允许继续提交 | 聚合显示问题 | BR-03~05 |
12. 逐条测试动作
每条动作至少测试：
- 正常输入；
- 空值；
- 边界值；
- 错误输入；
- 多行变化；
- 删除和重新添加；
- 连续触发；
- 重复点击；
- 保存后重新打开；
- 不同业务状态。
不要只看页面上的临时变化，还要确认保存和重新打开后的业务结果。
13. 常见错误
- 为了炫技把简单计算做成复杂动作；
- 事件发生时机选择错误；
- 自动带出只考虑“找到一条”；
- 结果变化但用户不知道原因；
- 多个动作修改同一字段，优先级不清；
- 保存失败后仍然发送成功通知；
- 重复点击产生重复业务结果；
- 自动化了仍需人工判断的高风险决定。
14. 本章完成标准
- [ ] 每条自动化都有明确事件、条件、动作和结果；
- [ ] 已区分默认、计算、校验和动作；
- [ ] 计算精度、顺序和空值含义明确；
- [ ] 查询带出考虑了零条、一条和多条结果；
- [ ] 重复执行不会产生重复业务结果；
- [ ] 重要失败有可理解的提示和补救方式；
- [ ] 每条动作都能由业务场景验证。
下一步
动作处理单张表单内部及其周边的自动工作；需要多人依次作出业务决定时，应设计流程。下一章学习设计真正可运行的审批流程。