副标题：什么时候应该用，什么时候不应该用
写到第七篇，我们的博客已经从一个简单的 .md 想法，演变成了一个拥有多作者系统、极致 SEO 和高性能的 v0.8 版本。
回头看这段旅程，文档驱动开发（Document-Driven Development）仿佛一把无坚不摧的利剑，帮我们斩断了需求蔓延的荆棘，劈开了 AI 幻觉的迷雾。
但是，作为一名负责任的技术写作者，我必须在这里按下一个暂停键。
文档驱动开发不是银弹。 它不是万能药，如果你在所有场景下都盲目使用它，它甚至可能变成你的毒药。
在这篇文章里，我们要把这把"利剑"放下，甚至还要用放大镜去检查上面的裂纹。我们要聊聊它的代价、边界，以及那些可能让你掉进坑里的陷阱。
凡事皆有代价
在软件工程里，从来没有"免费的午餐"，只有 Trade-off（权衡）。文档驱动开发也不例外，它向你索取的代价主要有三点：
-
时间成本：显而易见，写文档需要时间。在这个博客项目中，我粗略统计了一下，大约 20% 的时间花在写文档上，80% 的时间花在写代码和调试上。如果没有文档，我直接上手写，会不会更快？对于 v0.1 版本，绝对会。
-
认知成本：你需要强迫自己先思考、再动手。这对于习惯了"边做边想"（Vibe-coding）的开发者来说，是一种痛苦的思维逆行。就像是强迫一个习惯了自由奔跑的人去走正步。
-
维护成本：这是最隐蔽的代价。文档不是写完就结束了，它是有生命的。每次代码变了，文档必须跟着变。这种"同步纪律"一旦松懈，文档就会变成谎言。
何时不应该用文档驱动？
既然有代价，那就一定有"不划算"的时候。如果你处于以下几种场景，请毫不犹豫地抛弃文档驱动，直接动手写代码：
1. 探索性原型 (Prototyping)
假设你有一个疯狂的想法："我想做一个基于声音控制的俄罗斯方块"。你根本不知道这在技术上行不行得通，也不知道好不好玩。这时候，去写什么 spec.md 简直是浪费生命。你应该直接打开编辑器，写代码，试错，如果不行为立马删掉重来。
2. 一次性脚本
老板让你把数据库里所有用户的名字改成大写。这是一个只运行一次、运行完就扔的脚本。你不需要为它写一份 intent.md 来阐述"为什么我们要把名字大写"。
3. 极度熟悉的领域
如果你已经做过 10 个类似的博客系统，闭着眼睛都能背出数据库表结构。那么，你脑子里的"心智模型"已经足够清晰，不需要再外化为文档。或许保留一个简单的 intent.md 提醒自己别走偏就够了。