文档驱动开发（Documentation-Driven Development）的核心思想：在写代码之前先写文档，强迫你在实现之前把思路想清楚。Claude Code 让这个流程变得轻量。
为什么先写文档：
代码是思维的结晶，但写代码时容易被"能工作"的诱惑吸引，而忽略了"是否设计合理"。文档没法跑，所以它逼你考虑： - 这个函数的调用方是谁？他们需要什么？ - 边界条件是什么？ - 失败时的行为是什么？
用 Claude Code 实现 DDD 流程：
第一步：写接口注释
claude "我要实现一个用户通知偏好系统。
帮我写 Go 接口的文档注释（godoc 格式）：
- NotificationPreferences 接口
- SetPreference、GetPreference、ListPreferences 方法
- 每个方法的参数说明、返回值说明、错误条件
- 一个使用示例
不要写实现，只写文档。"
第二步：基于文档写测试
claude "基于上面的接口文档，
写测试用例（只有函数名和注释，不写实现）：
- 测试函数的名字描述场景（TestSetPreference_WhenInvalidChannel_ReturnsError）
- 注释说明每个测试要验证什么
这些测试会引导我写实现。"
第三步：实现代码
claude "现在实现这个接口。
约束：
1. 所有文档注释里提到的行为必须被实现
2. 所有测试用例必须能通过
3. 不要添加文档里没提到的功能"
第四步：验证文档和实现的一致性
claude "对比接口文档和实现：
1. 文档里说的行为，实现都有覆盖吗？
2. 实现里有没有文档没提到的行为？（可能是遗漏的说明）
3. 错误条件和文档一致吗？"
README 驱动开发（README-Driven Development）：
Jeff Atwood 推广过一个更轻量的版本——先写 README，在 README 里描述你的库/工具怎么用，然后实现它：
claude "我要做一个命令行工具，可以批量压缩图片。
先帮我写 README 的使用示例部分：
- 安装方式
- 基础用法
- 常用选项
- 示例输出
写完后我来决定要实现哪些功能。"
DDD 最适合的场景：
- 公共 API 设计（别人会依赖这个接口）
- 复杂业务逻辑（规则需要在实现前就清晰）
- 长期维护的核心模块
不适合的场景： - 快速原型（验证想法比设计文档更重要） - 一次性脚本（文档开销不值得）
文档驱动开发不是为了写文档而写文档，而是把"想清楚再实现"这件事强制化。Claude Code 让这个过程的摩擦降到最低。