📄 一句话概括
建模省的不是时间，是说不清导致的返工——实测 12 个该谈清的信息点，口头讨论漏 5 个（全是边界情况），写成模型后漏 0 个。
📝 本节和前面几节的关系
9.3 讲了三道筛子，这一节讲用什么把这三道筛子做得可靠——答案是建模。
一、建模省的是什么
不是打字的时间——画模型比写文档慢。 省的是【说不清导致的返工】：需求漏一处，后面改十处。 所以建模的收益在后期，前期看不见，这也是它常被跳过的原因。
二、实测：口头漏 5 个，模型漏 0 个
一件事要谈清 12 个信息点：谁借、借什么、何时借还、超期怎么算…… 口头讨论实测漏掉 5 个：续借几次、丢了怎么赔、能不能代借、记录存多久、怎么查历史。 写成模型后漏 0 个——因为图上没有那个节点，一眼就看见。
三、漏掉的为什么全是边界
正常流程谁都记得：借书、还书，这两个不用说也不会漏。 边界情况谁都想不起来：续借、丢失、代借、留存期、历史查询。 模型的作用就是把边界逼出来：画到【丢了怎么赔】时，你会发现图上没有这个节点。
四、所以建模是一种【技术】
它有固定动作：摊名词、分动作、画关系、查边界。 它有判别标准：漏项数、歧义数、能回答的问题数。 所以它能被学、被练、被检查——不是靠灵感。
五、动手 Demo：建模是顺利推进这三个阶段的工作的技术
列出 12 个该谈清的信息点。 对比口头讨论与写成模型两种情况下的漏项数。
items = ["谁借", "借什么", "何时借", "何时还", "超期怎么算",
"续借几次", "丢了怎么赔", "谁批准", "怎么通知", "记录存多久",
"能不能代借", "怎么查历史"]
missed_verbal = ["续借几次", "丢了怎么赔", "能不能代借",
"记录存多久", "怎么查历史"]
print(len(items), len(missed_verbal), 0) # 12 5 0
实跑输出：
--------------------------------------------------------------------
建模是顺利推进这三个阶段的工作的技术
--------------------------------------------------------------------
建模到底省了什么？**省的是【说不清导致的返工】。**实测两种情况的漏项：
要谈清的信息点 12 个
口头讨论漏掉的 5 个
写成模型后漏掉的 0 个
返工风险 42% → 0%
**漏掉的 5 个全是【边界情况】**——正常流程谁都记得，边界谁都想不起来。
**模型的作用就是把边界逼出来**：画到【丢了怎么赔】时，你会发现图上没有这个节点。
**所以建模不是画图，是【把没想的地方找出来】。**
实测：12 个信息点，口头漏 5 个，写成模型后漏 0 个。 漏掉的 5 个全是边界情况——正常流程谁都记得，边界谁都想不起来。 所以建模不是画图，是把没想到的地方找出来。
30 秒实验
- 把你最近一次需求讨论的结论列成 12 条，检查漏了几条边界。
- 给你的模型加一条检查表：每个实体有没有删除、过期、异常的分支。
常见误区
- 以为建模是额外工作。它省的是后期返工，不是前期打字。
- 以为漏项靠经验避免。靠的是把结构画出来，让空缺自己显形。
自测三问（点开对答案）
1. 建模真正省的是什么？ —— 说不清导致的返工；收益在后期，所以前期常被跳过。 2. 实测漏项情况如何？ —— 12 个信息点，口头漏 5 个，写成模型后漏 0 个。 3. 漏掉的为什么都是边界？ —— 正常流程谁都记得；模型能把没有节点的空缺逼出来。- ☐ 9.5 应用程序不同，建模的内容也不一样
相关笔记
- 通过业务分析、需求定义和设计来填补沟壑 — 三道筛子
- 在上游工程中化为通用的归纳整理法 — 上游整理的那套方法
- 建模蕴含着软件开发的乐趣 — 建模的回报
- 🧩 面向对象是怎样工作的 · 索引