最小可用文档（MVD）常被误解成"先写一份简陋的手册"。它真正的定义是：只覆盖最高频路径与最高频失败场景的文档集合。判断一份文档是否达到最小可用，标准不是篇幅，而是新用户在最常见的卡点上能否不求助任何人就自行解决。这决定了取舍逻辑——不是把完整手册删减，而是先确定必须覆盖的最小集合。

先选覆盖范围，再谈写法

范围选择依据两个维度：发生频次与失败代价。落地上先写三条最高频路径，配三个最高频失败场景。路径是用户真正会走的顺序——首次了解、进入使用、完成核心操作、遇到问题寻找出口；失败场景则取那些发生率高、用户自己无法绕过的环节。这个组合能覆盖绝大多数自助需求，剩下的长尾问题可以等真实反馈出现后再补。

另有一类内容适合做成固定清单，而不是写进正文：边界输入。长文本、特殊字符、空列表、弱网等条件在小规模测试中很难自然触发，把它们列成核对项，每次新功能交付前逐条过一遍，比依赖记忆可靠。

让 AI 出初稿，核对权留在自己手里

基于功能列表与界面说明生成初稿，是个合理的起点，但生成之后必须做两件事：逐条核对内容是否符合产品现状，因为模型容易按通用产品逻辑补出产品里并不存在的功能；标出它没写、而你实际遇到过的问题。AI 的价值在于扩大覆盖面，不在于判断这份文档够不够发。

错误提示应当被当作文档的一部分来审。合格标准是用户看完之后知道发生了什么、能否自己解决、下一步做什么。常见缺陷集中在三处：只显示错误码、把技术栈信息暴露给用户、以及"操作失败"这类零信息量文案。

把版本迭代当成维护方式

MVD 不是一次性交付物。每发一版，把这一轮实际暴露的问题补进清单，覆盖范围就更贴合产品本身。真正要改的往往不是功能，而是那些从未被写下来的默认假设。