——不求完美，但求有用
系列导读：这是《老项目如何引入文档驱动》系列的第 3 篇。前两篇我们聊了为什么需要文档驱动，以及如何用 AI 理解代码。现在，真正的挑战来了——如何把理解转化为文档？更重要的是，第一份文档该写什么？
小张的困境：文档写到一半就放弃了
小张是我们团队的一名工程师。
上周，他用 AI 分析完支付回调的代码，信心满满地决定：“我要把这些整理成文档！”
结果呢？
他花了整整 3 个晚上，写了 20 页，还没写完一半。
每写一段，他都要纠结：
“这个方法要不要详细说明？”
“这个配置项要不要记录？”
“这段历史演进要不要写？”
第四天，他崩溃了。
他放弃了。
这就是很多人写文档时遇到的困境：想写得完美，结果一点都写不出来。
你可能会说：“那就简单写写不就行了？”
但问题是：简单到什么程度？写什么？不写什么？
这就是这篇文章要解决的问题。
我们不追求完美的文档，而是追求“刚好够用”的文档。
这就是 MVD(Minimum Viable Documentation，最小可行文档）。
一、什么是 MVD？为什么要从“最小”开始？
MVD 的定义
MVD 不是缩水的文档，而是只包含核心信息的文档。
它回答三个最关键的问题：
-
是什么（What）：这段代码是干什么的？核心流程是什么？
-
为什么（Why）：为什么这样设计？关键决策是什么？
-
怎么用（How - 关键部分）：遇到问题怎么办？有什么坑要注意？
不回答的问题：
-
每个方法的详细实现
-
所有的配置项说明
-
完整的历史演进
-
详尽的数据库设计
这些都很重要，但不是第一优先级。
为什么要从“最小”开始？
1. 降低启动成本
写一份完美的文档需要 20-40 小时。你很难一次性投入这么多时间。
但写一份 MVD 只需要 4-6 小时。这个投入是可接受的。
2. 快速验证价值
MVD 写完就能用，你能立即看到效果：
-
新人能不能通过这份文档理解代码？
-
自己 3 个月后回来能不能快速上手？
如果答案是“能”，你就成功了。
如果答案是“不能”，你只浪费了 6 小时，而不是 40 小时。
3. 避免完美主义陷阱
很多人写文档失败，不是因为能力不够，而是因为追求完美。
MVD 的理念是：先有，再好，最后才完美。
第一份文档不需要完美，只需要有用。
对独立开发者来说，MVD 更重要
如果你是独立开发者，同时维护多个项目，MVD 对你的价值更大：
你可能今天在客户 A 的项目，下周切换到客户 B 的项目。
如果没有 MVD:
回来时要花 1-2 天“回忆”当时的设计。
如果有 MVD:
5-10 分钟就能进入状态。
防止知识遗忘：
3 个月后，连自己的代码都看不懂？有了 MVD，关键决策和设计思路都记录在案，随时可以回忆起来。
这就是 MVD 的价值。