写在前面：一个有点反直觉的结论

生成式 AI 刚出现的时候，很多人第一反应是：“终于可以让 AI 帮我写需求文档、写 PRD 了。”

但真正花了好几年时间、从最早的模型一路实践到今天的人，得出的结论恰恰相反——

AI 时代真正稀缺的，不是"写文档的能力"，而是"决定做什么的能力"。

需求定义这件事，正在从一道"整理与归档"的工序，变成一道"决断"的工序。下面我顺着探索的脉络，把这条认知是怎么一步步长出来的讲清楚。

---

路线图：一张表看懂全貌

阶段	在做的事	学到的东西
起步期	用早期大模型把邮件 / IM 文本自动生成业务流程图	事前信息（术语表、前提）的整理，直接决定生成精度
探索期	用 Cursor + Markdown 做需求定义	代码本身就是最好的上下文
试点期	在部分团队试点对话式 AI	知识沉淀比急着推广更重要
深化期	需求定义全流程引入 AI	从"单次 prompt"升级为"一套机制"
定型期	骨架交给代码，需求交给 prompt	把"骨架"和"需求"显式拆开
突破期	构建"零天交付"方法论	需求定义从"写文档"变成"切范围"
至今	重新理解需求定义的本质	它正从"整理的工序"变成"决断的工序"

可以看到，越往后，话题就越不只是"需求定义"，而是延伸到整个开发流程的形态。

---

起步期｜让 AI 读懂"聊天记录"画流程图

最早的尝试，大概要追溯到好几年前。当时的想法很朴素：业务沟通的信息大量散落在邮件和 IM 里，能不能直接喂给大模型 API（用的还是相当早期的版本），自动生成业务流程图？

理想很丰满，现实很骨感。模型根本分不清哪些是有效需求、哪些是闲聊和跑题的内容，生成出来的流程图常常驴唇不对马嘴。

真正让它"能用"的转折点是：先把术语表、关键角色、基础业务假设定义清楚，再让模型生成。 哪怕只是补充一些定性的背景信息，把它塞进上下文里，生成质量也会有质的飞跃。

这段经历给我留下的执念一直保留到今天——事前信息（上下文）的质量，是一切的起点。 后来在工程上演化出的各种"规则（Rule）"机制，源头就在这里。

---

探索期｜用 Cursor + Markdown，从代码里"反查"需求

后来 Cursor 出现，我立刻开始用它做需求定义。模型仍是相对早期的版本，但关键变化是：参考上下文（术语表、需求信息）可以直接从代码里取。

这带来一个非常实际的好处：当系统需要做增量功能（enhancement）时，生成需求文档变得异常顺手。因为代码本身就承载了最准确的现状信息，比靠人手一条条回忆和书写要快得多，也更不容易和实现脱节。

那个阶段我反复提醒自己的一句话是：把"代码库"正确地取出来，再把必要信息罗列进 Markdown。

学到的东西：用好代码库非常关键。 这也直接通向后来的"代码索引"思路。

---

试点期｜小范围试点，先沉淀、再推广

走到这一步，生成式 AI 的潜力已经看得很清楚了，于是开始在部分团队试点。

但我没有急着全公司铺开。原因有两个：

• "对话式 AI + 把上下文整理好再喂进去"这套打法，本身还在反复试错、还没形成稳定的组织化方法；
• 那时候团队内部对 AI 持怀疑态度的人不少，贸然全员推行风险太大。

所以选择了谨慎前进——先在小范围里跑通。

这个阶段我提了一个自造的概念叫 “Project as Code”：把项目里的所有信息，尽量都用 Markdown 或代码来表达，然后持续往里沉淀。正是这套"用代码统一管理项目信息"的做法，成了后来"从代码库反查生成需求"的地基。

学到的东西：

• 先让"布道者"角色的成员把使用经验攒起来；
• 比起急着推广，更重要的是先把知识沉淀下来（代码化）。

---

深化期｜从"单次 prompt"到"一套机制"

把前面攒下来的经验当作地基，我们正式进入"需求定义全流程用 AI"的阶段。同时并行推三条路线：

1. 从代码库反查、自动生成文档。 以现有代码为起点，生成规格说明和业务流程文档——比人手撰写更快，也更不容易和实现产生偏差。
2. 先用 UI 生成 AI 做原型，再反推需求文档。 用 v0 这类工具先把界面原型做出来对齐认知，再据此固化需求。“先给客户看能动的东西”，能尽早消灭认知偏差。
3. 在售前阶段就开始做需求定义。 从商务洽谈阶段就把需求定义的轮子转起来，在签约之前就把需求的"分辨率"一口气拉高。

学到的东西：真正提升生产力的关键，不是某条神级 prompt，而是把上下文、代码库、沉淀的经验整合成一套"机制"，嵌进需求定义流程里。

---

定型期｜"骨架是代码，需求是 prompt"

不断实践之后，下一个要正面回答的问题变成了：“开发本身到底该怎么推进？”——也就是要把方法论定型，让需求定义到实现这整条链路能被整个团队稳定地跑下来。

绕不开的一个核心问题是：怎样才能让任何人都得到一致的产出？

我在这个过程里确立的核心理念是：“骨架交给代码上下文，需求交给 prompt”。

比起那种从零开始、纯靠自然语言指令去生成的完全 “Vibe Coding”，以一份骨架代码（基础代码）为底座，生成代码的质量更稳，团队成员的学习效率也更高。 骨架从既有代码里读取，需求用 prompt 传入——前面几年的所有积累，在这里收束成了一个清晰的形态。

开发流程本身也进化成了我称之为 “AI 驱动敏捷” 的混合模式：

• 节奏上：像敏捷一样分阶段推进；
• 单点开发上：像"重设计的高速瀑布"，把设计做厚。

核心目的，是把"需求 / 规格还很模糊就开始生成代码"导致的返工风险降到最低——所以要刻意把需求定义和设计阶段做得更重。

学到的东西：让代码承载"骨架"，团队才能腾出精力专注在"需求"上。

---

突破期｜"零天交付"——从一个能跑的系统开始谈需求

再往前一步，是一套叫 “零天交付（0 日导入）” 的方法论。

它的做法很反常规：项目一启动，就先把基础代码部署到测试环境，然后以"系统已经在跑了"为前提，和客户一起做需求定义与设计。

• 文档？不过是在"基础代码版本的模板"上做差分修改。
• 例会上尽量直接演示能跑的东西，边看边对齐认知。
• 需求定义被重新理解为"切范围（切 Issue）"的工作，把任务拆细到"一次开发能在 1 小时内完成"的粒度。

而且，这种"切范围"的活儿，最好由业务侧的人来承担。

这里最关键的转变是：需求定义的主角，从"写文档"变成了"切对范围"。 AI 把开发提得越快，上游"做什么、以什么粒度做"的定义能力，就越成为整条链路的瓶颈。

学到的东西：AI 让开发越快，瓶颈就越往上游移动。 需求定义的角色，从"文档撰写"变成了"范围设计"。

---

走到今天：需求定义，正在从"整理"变成"决断"

把这套方法磨了好几年之后，我越来越清楚地意识到一件事：需求定义这道工序的"意义"本身，已经变了。

当 AI 已经能高速完成整理和文档化，留给人的核心只剩下一件事：决定要做什么。 需求定义因此从"整理的工序"，悄悄变成了"决断的工序"。

有意思的是，哪怕今天的开发流程已经以 Claude Code 这类编码 Agent 为中心，需求定义和概要设计阶段里的信息整理、共识达成，仍然很难完全交给它们搞定。 原因在于：Markdown 的可视性、审批流程（指令历史）的可视化等等，和传统瀑布式流程里那些"硬性要求"并不完全兼容。换句话说，"决断"这一环，目前依然牢牢地长在人这一侧。

而且，这个"决断"不再是少数专家的专利。业务负责人、经营者、企业内部 IT——所有人都被推到了"定义要做什么"的位置上。

需求定义与设计，正在变成一道**需要被"民主化"**的工序。
既然如此，挡在这条路前面的障碍，就都值得被一一拆掉。

我越来越相信：工具，应该像空气一样存在。 让用户感觉不到成本，也感觉不到被锁定，从而把全部注意力放在"要做什么"的决断上。

这些年走下来，最终答案不是"我们要更努力地堆机制、堆经验"，而是——把那些机制和经验当作"已经讨论完的过去"，腾出一片能让人专注于真正价值创造的土壤。

这一段的体会，也正是整篇文章的结论：

• 生成式 AI 该做的，不是"生成文档"，而是"建立一套能收集正确上下文、切出正确范围的机制"；
• 需求定义，已经从"整理的工序"变成了"决断的工序"。

---

总结：那条贯穿始终的线

回头看，每个阶段学到的东西其实是一条连续的线：

• 上下文是一切的起点。 想从夹杂闲聊的文本里榨出精度，术语表、前提、业务假设的整理不可或缺（后来的"规则"概念）。
• 代码库才是最好的上下文。 与其靠人手回忆书写，不如从既有代码里反查，更快也更准（后来的代码索引，以及"骨架是代码上下文"）。
• 知识靠沉淀，而非靠推广。 在怀疑的氛围里，以布道者为中心、把经验攒成 prompt 集，才真正起了作用。
• AI 越快，瓶颈越往上游走。 开发被提速之后，需求定义的角色从"文档撰写"转为"范围设计"。

不要把生成式 AI 当成一个"魔法盒子"去期待。真正要做的，是想清楚：怎样把正确的上下文喂给它，怎样建立一套能切出正确范围的机制。

但更重要的是——讨论"机制"的阶段，其实早就结束了。现在最关键的，是专注于"到底要做什么"。 多年的实证下来，我觉得，结论就到这里为止。

---

一点个人补充

读完这段复盘，最打动我的不是某个具体工具，而是那条认知曲线本身：我们总以为 AI 会替我们"做事"，但它真正逼着我们升级的，是"判断"。

文档可以自动生成，原型可以一键产出，代码可以批量铺开——当这些都不再稀缺，人的价值就被压缩、也被提纯到了最核心的那一点：在无数可能性里，决定"做什么、不做什么"。

这件事，没有任何工具能替你完成。