AI 越强，需求管理越重要

《AI时代漫游指南》第 28 章记载：「当人类终于可以用自然语言编程时，他们遇到了一个古老的问题——自然语言本身就是模糊的。」

你有没有这样的经历：

对 Claude 说”加个暗色模式”，它刷刷写了 200 行代码。

你一看——颜色是改了，但不跟随系统设置，不记住偏好，只改了首页没改其他页面。

你说的每个字它都懂了。但你想要的，它只猜对了三分之一。

这不是 AI 的问题。这是「需求」的问题。

🚀 Vibe Coding：说人话就能写代码

2025 年，Andrej Karpathy 提出了 Vibe Coding 这个概念——你不用写代码，只需要描述你要什么，AI 来实现。

Claude Code、Cursor、Windsurf……这些工具让”说人话写软件”变成了现实。

但用了几个月后，你会发现一件事：

写代码变简单了，但做对的东西反而更难了。

❓ 需求文档不是多余了吗？

传统软件开发：

人写需求 → 人写设计 → 人写代码 → 人写测试

Vibe Coding：

人说需求 → AI 理解 → AI 写设计+代码+测试

中间环节全部被 AI 接管了。

于是很多人觉得：需求文档可以不写了吧？

这是一个危险的误解。

编者注：这就像说”有了导航就不用知道目的地”。AI 是你的司机，但你得告诉它去哪。你说”随便开开”，它真的会随便开。

💡 核心价值一：意图对齐

你说”加个暗色模式”，Claude 可能理解为六种完全不同的实现 👇

这不是 Claude 笨，是自然语言天生有歧义。

需求文档的作用，是迫使你在动手前想清楚到底要什么。

四行话，省掉三轮返工：

✅ 支持手动切换 + 跟随系统设置
✅ 偏好存储到 localStorage
✅ 全站所有页面生效
✅ 切换时有 300ms 过渡动画

🧠 核心价值二：跨会话记忆

这是很多人忽略的关键问题。

Claude 没有跨会话记忆。

每次新对话，它都是一张白纸。你上周花了两小时讨论的架构决策、踩过的坑、放弃的方案——全部归零。

需求文档就是记忆的外化：

📌 决策上下文：为什么选方案 A 不选 B？ 📌 失败记录：哪些方案试过但行不通？ 📌 进度追踪：当前做到哪了？

编者注：人类发明文字是为了跨越时间传递信息。需求文档对 AI 的作用一模一样——跨越会话传递记忆。只不过这次，健忘的不是后代，是你的 AI 助手。

我自己的项目里，每次新开一个 Claude 会话，第一件事就是把 CLAUDE.md 喂给它。

没有它，Claude 每次都像新来的实习生。

有了它，像是干了三个月的老员工。

✅ 核心价值三：质量验收

当 AI 写完代码，你怎么判断它做对了？

❌ 没有需求文档：
   "代码没语法错误，测试通过" → PASS
   但可能做的东西完全不对

✅ 有需求文档：
   "要求3种主题，只实现了2种" → FAIL
   "要求记住偏好，没有持久化" → FAIL
   → 精准定位差距

当你用一个 Claude 写代码、另一个 Claude 做 QA 时，需求文档就是它们之间的**“合同”**。

📚 50 年前的智慧，今天更好用

需求管理不是什么新问题。软件工程 50 年历史里，前辈们早就为”怎么把需求说清楚”操碎了心。

这些方法论在 Vibe Coding 时代反而焕发了第二春——因为 AI 比人类更需要明确的指令。

① 用户故事（User Story）

一句话模板：

作为 [角色]，我想要 [功能]，以便 [价值]

三个槽位，强迫你回答三个问题——谁在用、要什么、为什么。Claude 拿到这三个信息，比你说”加个功能”靠谱十倍。

好用户故事还有个 INVEST 原则（6 个标准）：

• Independent — 一个 prompt 解决一件事，别堆需求
• Negotiable — 给 AI 留实现空间，别规定用什么库
• Valuable — 别让 AI 做用户看不到的重构
• Estimable — 太大就拆，一次对话做不完就拆
• Small — 一个 prompt 一个功能
• Testable — 给 AI 明确的验收标准

编者注：INVEST 原则发明于 2003 年，本意是教人类写好需求。20 年后发现，它更像是给 AI 写的 prompt 工程指南。历史总是押韵的。

② 验收标准（Given-When-Then）

Given 用户在设置页面
When  点击"暗色模式"开关
Then  全站切换为暗色主题，且刷新后保持

这就是测试用例的自然语言版本。Claude 看到这个格式，能直接生成对应的测试代码。需求和测试，一步到位。

③ JTBD（Jobs to Be Done）

用户买电钻不是想要电钻，是想要墙上有个洞。

传统需求：加个暗色模式
JTBD 视角：用户晚上看文章眼睛疼

当你告诉 Claude “用户晚上看文章眼睛疼”，它可能不止给你暗色模式——还会建议降低对比度、调整字号。

说清楚问题，比规定方案更好。

④ MoSCoW 优先级

其中最被低估的是 Won’t have。

Claude 最大的毛病之一是”做太多”。你说加个表单，它顺手加了验证、动画、国际化 🤦

Won’t have 就是给 AI 画红线——明确说”不做什么”，和说”做什么”一样重要。

🛠️ 实操：20 行搞定需求文档

别被”需求文档”这四个字吓到。不是写 PRD，不需要画流程图。

只需要三样东西 👇

① 用户故事（一句话）

作为博客读者，我想要暗色模式，
以便晚上看文章不刺眼。

② 验收标准（怎么算做完）

✅ 支持手动切换和跟随系统
✅ 偏好持久化
✅ 全站生效
✅ 过渡动画 ≤ 300ms

③ 边界说明（什么不做）

❌ 不需要日落自动切换
❌ 不需要自定义主题色
❌ 不需要每个页面单独设置

三个部分，加起来不超过 20 行。

写一次，省十次返工。

🎯 一个反直觉的结论

AI 越强，需求管理越重要。

传统开发中，程序员会自动补全需求的模糊地带——靠经验、靠常识、靠走过去问一句”你这个是什么意思”。

AI 不会走过来问你。

你不说的，它就自己决定。而且它的”自己决定”有时候很离谱。

这不是 AI 的缺陷，这是工具的特性。

锤子不会问你”你确定要钉这里吗？“——但好的需求文档会。

「AI 时代最稀缺的能力，不是写代码，是说清楚你到底想要什么。」 — 《AI时代漫游指南》第 28 章

---

🔗 关注「AI时代漫游指南」，一起用 AI 提升效率。

觉得有用？点个在看 👇 让更多人少走弯路。