为什么需要"五页纸"
客户要方案，团队很容易直接打开文档写功能清单。我们早年也这样——拿到需求当天就开写，写了三十页，客户看了说"这不是我要的"。问题在于，方案写得太快，往往是在替客户回答"他要什么"，而不是先确认"他怕什么"。
后来我们立了规矩：动手写对外方案前，内部先用五页纸把事想清楚。五页不多，但强迫团队在动笔前先对齐底层假设，避免方案华丽、地基虚空。
五页分别写什么
第一页：客户到底在怕什么。
不是需求清单，是需求背后的东西——他怕停线、怕审计过不了、怕被某家供应商绑死、怕系统上了之后没人维护。这一页要写具体场景，不能写"客户希望系统稳定"这种正确的废话。我们内部验收标准是：如果这一页能直接念给客户听、且客户点头，才算过关。
第二页：哪些必须自己掌控。
核心数据、权限模型、审计留痕，列清楚哪些不能外包、不能云化、不能交给第三方默认配置。很多项目后期被动，根子在第一页没划清边界——客户以为你全包，你以为边界外的他自理，上线那天才吵架。这一页就是提前把"我的"和"你的"画在纸上。
第三页：最小可上线闭环。
先交付哪一块，就能让客户"用起来"，而不是一次性全上。我们坚持一个原则：任何超过三个月才能看到价值的方案，都要拆出一个月内能用的那块。客户越早摸到真实系统，越早从"评估方"变成"共建方"，后面的变更反而更可控。
第四页：三年后会变成什么样。
架构怎么演进，不写愿景写约束——哪些技术债现在借、什么时候还，哪些集成点未来会加，数据量三年涨到多少量级架构还撑得住。客户要的不是你画大饼，是确认"今天的选择不会堵死明天的路"。
第五页：如果失败，断在哪。
预先标出风险点和回退方案，比承诺"万无一失"更可信。这一页我们甚至会在对外方案里保留一部分——客户看到你连失败都想过了，反而更敢把项目交给你。
一个对照
| 写法 | 直接写方案 | 先过五页纸 |
|---|---|---|
| 客户感受 | 功能很全 | 你懂我的顾虑 |
| 内部对齐 | 会后反复改 | 一页一确认 |
| 报价依据 | 拍脑袋 | 按闭环拆 |
| 返工概率 | 高 | 低 |
最后一行是我们统计出来的——凡是严格走完五页纸的项目，需求变更导致的返工明显少，因为假设在动笔前就戳破了。
落地提示
五页纸不是给客户看的，是给团队自己对齐的。它最大的价值，是把"我们以为客户要什么"提前戳破。我们也见过有人把五页纸写成对外方案的精简版，那反而失去了对内坦诚的意义——对内那页"客户在怕什么"，往往比对外文案直白得多。
方案的可信，不来自页数多，来自每一页都回答了一个真问题。
金兰信息——先想清楚，再写漂亮。