在我看来，敏捷团队往往把完成度当成唯一的度量指标，却忽略了“为什么”这件事。把心智模型验证塞进 Definition of Done（DoD），就像给完成度装上一个检查器，让团队在交付前先确认自己的思考框架是否跟需求一致。

先说说什么是心智模型。心理学家大卫·巴克利把它定义为“人们用来理解世界的内部表征”。举个例子，想象你在做一份用户故事：『用户可以在 App 上快速预约洗车』。如果团队心里只把这件事看作“单纯的 UI 交互”，就可能忽略后台订单调度、支付安全、与洗车点的同步等隐含的业务模型。

为什么要把它塞进 DoD？因为敏捷的核心是快速反馈。如果在 Sprint 结束前不验证模型，问题往往会在后期的 Demo、测试或上线后才被发现，成本骤升。就像某知名电商在一次订单高并发测试中，发现后台业务模型与前端模型不匹配，导致订单丢失，最终损失数十万元。那次事故后，团队把“模型一致性检查”写进 DoD，后续几乎没有再出现类似问题。

如何落地？我把过程拆成三步：
1️⃣ 先把模型验证的标准写进 DoD 里，例如：\“所有业务流程已在模型图中得到确认\”；
2️⃣ 在每个故事的 Acceptance Criteria 前加一条：\“模型图已更新并通过同伴评审\”；
3️⃣ 在 Sprint Review 时，让模型图与最终实现做一次快速对照，确认无误后才算完成。

下面给你一个真实案例：
Spotify 的“Squad”团队在 2019 年上线新的流媒体推荐算法前，把模型验证塞进 DoD。每个故事都需要先在 UML 或 Mermaid 图里绘制数据流，然后由技术负责人和产品负责人一起评审。结果在上线后，推荐精准度提升 12%，同时 bug 率下降 8%。这证明，模型验证不只是形式，确实能提升交付质量。

典型的模型验证清单（可直接拷贝进 DoD）：

• 业务流程已在可视化模型中完整描述
• 模型与需求规格书对齐，无遗漏
• 所有数据依赖已在模型中标注
• 模型已通过同伴评审并获得批准

收益是显而易见的：
• 降低返工成本，提升团队信心；
• 加强跨职能沟通，消除误解；
• 为技术债务留出“预防”窗口，减少后期技术剖析。

当然，别忘了，模型验证不是万能药。过度的形式主义会拖慢迭代速度，尤其在早期 MVP 阶段。关键是找到平衡点：模型验证的粒度要与产品的复杂度相匹配。

你在团队里有没有遇到过因为模型误差导致的痛点？如果有，把模型验证放进 DoD，或许能让那次痛苦变成一次成长。你准备好把心智模型也变成“完成度”的一部分了吗？