> For the complete documentation index, see [llms.txt](https://shike.gitbook.io/ai-coding/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shike.gitbook.io/ai-coding/04-chapter.md).

# 第4章 别写需求文档了:用一个 Demo 把需求对齐

**本章导读**:多数 AI 项目的失败,不是因为技术实现不到位,而是因为客户与开发团队在开始之前没有真正"对齐需求"。传统的需求对齐依赖文档——客户读文档、开发读文档,文档在传递过程中损耗,最终双方的理解偏差导致项目跑偏。本章介绍一种替代方案:用 AI 快速做出一个可交互的 Demo,让客户在屏幕上实际操作,通过"操作式反馈"完成需求对齐。这一方法将需求对齐从抽象讨论变为具体操作,大幅降低沟通成本。

**本章关键词**:Demo 对齐、需求可视化、操作式反馈、规格固化

## 4.1 需求对齐的真正难题

![意图债的来源分布](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-a84c1c28e40d309e546ab1f3d19bcb56ba80afc2%2Fai_coding_book_sec04_intent_debt_funnel.svg?alt=media)

![文档式对齐 vs Demo 对齐](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-36fc731facc5f48cab0c51d0575ef06e3a508591%2Fai_coding_book_sec04_doc_vs_demo.svg?alt=media)

### 4.1.1 文档式对齐的失败模式

**现场还原**:某次项目复盘,产品经理(以下简称"产品经理")在白板上画了一条线——左端是"客户签字时心里的画面",右端是"开发完成后的实际产品",中间是"需求文档"。产品经理指着这条线说:"签字那一刻,客户心里的画面和需求文档的距离是 30%;开发完成后,实际产品和需求文档的距离是 30%;客户看到实际产品时,心里的画面和实际产品的距离是 100%。"在场的工程师都笑了——因为这就是他们过去 6 个月经历的复刻。

需求对齐是软件项目的第一个关口。传统做法是撰写需求文档(PRD,即产品需求文档,描述"要做什么、做成什么样"的正式文件),客户与开发团队围绕文档讨论、修改、签字,然后进入开发。但实际经验是:**文档式对齐的项目,90% 会在第三周出现"这不是我要的"**。

文档式对齐失败的根源有三个:

**根源一:客户的语言是"感觉",开发的语言是"行为"**。客户说"要大气"、"要及时"、"要好用",这些词对他意味着具体画面;开发听到这些词,会做出一份"他自己认为符合'大气'"的产出。两份产出往往不是同一份。

**现场细节**:某次项目,客户在需求评审会上说"这个首页要大气体面"。产品经理把这句话原样写进 PRD,工程师按"大气体面"做了首页——首页用了 64px 的标题、3 米的留白。客户验收时皱眉:"大气是大气,但有点空。"工程师一脸茫然:"我按 PRD 做的。"产品经理当时意识到:"客户的'大气'背后,可能是'信息密度高但层次清晰'——和工程师理解的'大气=大字号+大留白'是相反的。"

**根源二:文档无法传递"使用场景"**。客户描述需求时,假设开发能想象出"用户在某个具体场景下会做什么";但实际上,开发无法看到客户脑中的画面。文档写得再详细,也不能让开发"用一次"产品。

**现场案例**:某次项目,客户在文档里写"用户可以快速找到自己想要的产品"。工程师做了一版"搜索框很大、推荐很智能"的版本。客户验收时不满:"我们卖的工业零件,客户根本不会用搜索——他们都是按型号查的,搜索框不是入口,是辅助。"这件事,客户自己当时也没意识到要写清楚,直到看到 Demo 在屏幕上,客户才反应过来"我们的客户不是这么用的"。文档里没有写"用户是工业采购员,按型号查询",因为客户默认"开发应该知道"。Demo 让这个"默认"浮出水面。

**根源三:客户在签字时不知道自己在签什么**。客户签字意味着"同意按此需求开发",但签字时客户无法预见开发完成后产品的样子,签字只是一个形式。一旦开发完成,客户看到实物,往往会说"我以为会是另一种样子"。

**现场细节**:某次项目,客户在签字前问产品经理"这个签字意味着什么?"产品经理答"意味着您同意按这份文档开发,我们接下来会按这个做"。客户签了。第五周,客户在验收会上说"这个颜色我以为会更深一点"。产品经理问"您当时签字时为什么没提?"客户答"我以为浅色就是这个意思,看到实物才发现不是"。这件事让产品经理后来做了一件事:签字前,让客户用一句话复述"您签字同意的是什么",记录在签字页底部。这句话后来成了"签字前的最后一关"。

### 4.1.2 一个可对齐的替代方案

**现场还原**:某次项目复盘会,产品经理向客户演示了"用 Demo 对齐需求"的全流程。客户看完后说:"早知道有这种方法,我们前两次合作就不会那么痛苦。"产品经理答:"前两次的痛苦是这方法的'广告费'——没有那两次失败,您不会相信这方法有效。"

替代方案的核心思想是:**让客户在开发前就看到产品,而不是开发后才看到**。具体做法是:用 AI 在 24 小时内快速做出一个可交互的 Demo(可点击的样品,内部功能可以为空,但外观和交互逻辑尽量接近成品),请客户坐到屏幕前实际操作,客户在操作中自然地给出反馈——"这里不对"、"这个颜色太深"、"这个按钮应该在这里"。这些反馈比任何文档都更具体、更准确、更可执行。

Demo 对齐适用于"客户知道大致想要什么、但不知道具体怎么做"的场景。如果客户连"大致想要什么"都不知道(如完全从零开始的新产品),Demo 对齐仍然有效——Demo 可以基于客户的模糊描述做出几个不同方向,客户在比较中明确自己的偏好。

**现场细节**:某次项目,客户是某新创品牌,连"大致想要什么"都说不清——只知道"想要一个和竞品不一样的网站"。产品经理用 AI 在 24 小时内做了 3 个不同方向的 Demo(极简风格、信息密集风格、故事化风格),客户在三个 Demo 间反复对比,第三天给出明确反馈:"我喜欢极简的版式,但要信息密集的内容。"——这一句反馈,比任何文档都更接近"真正想要什么"。从"说不清"到"选得清",中间只差 3 个可对比的 Demo。

## 4.2 24 小时可交互 Demo 工作流

![Demo 介导的需求对齐流程](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-a8297fdb4201a06517d461e5a154871911e9dbc1%2Fai_coding_book_sec04_demo_flow.svg?alt=media)

### 4.2.1 时间盒的设置

**现场还原**:某次内部讨论,工程师问"24 小时够吗?我做完整网站要 2 周。"产品经理答:"Demo 不是完整网站。Demo 是一份'看着像样但功能不全'的样品——目标是让客户在屏幕上指出哪里不对,不是让客户验收。24 小时做出来的东西,客户一眼就知道'这不是终版',反而能放心地说'这里不对'。如果做出'看着像终版'的东西,客户反而不敢提意见,因为他觉得'看起来已经很好了'。"

24 小时是经验上的最佳时间盒。太短(几小时)做不出有说服力的 Demo,客户看到简陋的样品会失去耐心;太长(几天)会让客户预期"这是成品",反而干扰对齐过程。24 小时的 Demo 是一份"看着像样但功能不全"的样品——客户能从中看到产品方向,但清楚知道这不是终版。

24 小时的另一层意义是给团队一个截止信号。Demo 不是产品,不应该无止境地打磨;24 小时到了就交付,无论完成度如何。

**现场案例**:某次项目,工程师对 Demo 的"完成度"过于执着——做了 3 天,还在调整字体。产品经理第 3 天晚上 10 点强制叫停:"Demo 的考核指标是'让客户说出不对的地方',不是'让客户说不出不对'。你的字体已经看了 4 个小时了,客户不会注意到这个差异。"工程师第二天交付,客户在 60 分钟会议里提了 23 条反馈,其中 0 条涉及字体——产品经理的判断是对的。

### 4.2.2 Demo 的范围选择

**现场细节**:某次项目,工程师做了一个"功能很全"的 Demo——首页、产品列表、产品详情、购物车、订单、客服、个人中心,7 个模块。客户打开后一脸茫然:"这些我都不确定,我只是想看首页和下单流程。"——工程师花了 3 天做的 5 个模块,在客户眼里是 0 价值。负责人后来定的规矩是:Demo 范围必须在 24 小时开始前由客户签字确认,签字的模块工程师才做,签字外的模块一律不做。

Demo 不必覆盖产品的所有功能,只需覆盖最关键的 1—2 个核心场景。例如,做一个电商网站,核心场景是"用户浏览商品、加入购物车、下单",Demo 只需实现这三条流程,其他功能(如客服、积分、个性化推荐)可以留空。

范围选择的原则:**选最能暴露需求模糊点的功能**。客户对核心场景通常有最强的直觉,最容易给出反馈;对边缘功能通常没有清晰想法,做了也是浪费。

**现场案例**:某次项目,产品经理列了一份"Demo 范围候选清单",包含 8 个模块。客户在其中选了 2 个——"商品详情"和"对比功能"。理由是:"这两个是我们最近被吐槽最多的地方,我想先确认这两个长什么样。"——客户选的不是"最重要的",而是"最不满意的"。这个选择,反而比"最重要的"更有对齐价值——"最不满意"通常意味着"最模糊"。

**现场细节**:某次项目,客户最初说"我想要一个包含用户管理、订单管理、报表中心、数据看板、消息中心、权限系统、API 对接 7 个模块的系统"。产品经理没有立刻答应,而是问:"这 7 个里,如果有 6 个都没时间做,只能做 1 个,您选哪个?"客户想了 10 秒,答"数据看板"。产品经理追问:"为什么?"客户答"我们老板每天早上 9 点看这个。"——这一问,让 Demo 范围从 7 个模块变成 1 个模块,工期从 4 周变成 24 小时,质量反而更高(因为只做一个模块,可以做得更深)。负责人后来把这种"7 选 1"问法写进了 Demo 范围选择清单:"问'如果只能做一个,哪个?',答案往往是'最能暴露问题'的那个。"

### 4.2.3 真实数据的必要性

**现场还原**:某次项目,工程师做的 Demo 里,产品名是"Product A"、价格是"¥99"、描述是"This is a product description"。客户打开后说:"这看起来像是 demo,不像真的。"工程师答:"这就是 demo。"客户说:"我知道是 demo,但 demo 里也用真的产品名,看起来会更真。"工程师换了 12 条真实产品名(从客户官网脱敏),客户重新打开后态度立刻变了——开始认真看布局、文案、图片比例,给出的反馈质量比"Product A 时代"高 3 倍。

Demo 中应使用真实感的数据,而非"测试数据 1"、"测试数据 2"。真实感的数据让客户能"进入场景",而测试数据让客户觉得"这只是个样品"。

真实感数据的准备是 Demo 工作量的一部分。团队应花 1—2 小时准备 20—30 条样本数据,这些数据应来自客户的实际业务(经脱敏处理后)或行业典型数据,具有合理的字段、合理的数值、合理的分布。

**现场细节**:某次项目,工程师花了 90 分钟准备 25 条样本数据——来自客户上一季度销售前 25 名的产品,产品名脱敏为"产品 A01—A25",价格按真实价格 ±5% 波动,描述截取真实描述的前 80 字。客户在会议里说"这看起来像我们家的产品",开始主动指出"产品 A03 的图片比例不对,实际产品是 1:1 不是 4:3"——这种细节反馈,用"测试数据"是不可能得到的。

### 4.2.4 部署的简化

**现场细节**:某次项目,工程师把 Demo 部署到客户的测试服务器上——填了一堆 IP、端口、域名、HTTPS 证书的表格,花了 3 小时。客户第一次访问时,HTTPS 证书报错,折腾 1 小时。最终部署耗时 4 小时,比做 Demo 还久。负责人后来定的规矩:24 小时 Demo 一律用免费静态托管(Vercel、Netlify、Cloudflare Pages),从代码到 URL 不超过 10 分钟,生成的 URL 直接发给客户。

Demo 不必部署到生产环境。可以使用免费的静态托管服务,把生成的网页放上去,客户用浏览器打开即可。这样做的好处:不需要配置服务器、不需要申请域名、不需要 HTTPS 证书,节省大量非核心工作。

## 4.3 以 Demo 为介质的对齐会议

### 4.3.1 会议规则

**现场还原**:某次会议,产品经理第一次尝试"让客户亲自操作 Demo"。会议开始前,产品经理把 Demo 投到电视上,鼠标递给客户,说"请您随便点,觉得哪里不对随时说"。客户犹豫 5 秒,接过鼠标,开始操作。5 分钟内,客户点了 11 个位置,皱眉 7 次,说"不对"3 次。这 7 次皱眉和 3 次"不对"是产品经理过去 3 周写文档时从未获得的信息——3 周的书面沟通,产出不如 5 分钟的操作。

**关键对话**(某次复盘会上,产品经理对客户的解释):

> "过去 3 周,我们写了 12 页需求文档,开了 2 次评审会,您签了字。但您刚才操作 5 分钟,提了 3 条'不对'——这 3 条,12 页文档里都没有。下次合作,我建议把'写文档'换成'做 Demo',把'评审会'换成'操作会'。文档让双方都猜,Demo 让双方都看;评审会让双方都讲,操作会让双方都沉默。沉默里,需求自己会浮出来。"

对齐会议是 Demo 对齐方法的核心环节。会议的目标不是"介绍 Demo",而是"通过客户操作 Demo 暴露需求模糊点"。会议的有效性依赖三条规则:

**规则一:客户亲自操作,不允许代劳**。把 Demo 投屏到电视上,让客户用鼠标亲自操作——点击、输入、滚动、拖拽。客户在操作中会自然地暴露他的真实预期:他点击一个按钮,两秒后皱眉,这次皱眉就是需求信号。

**现场细节**:某次会议,产品经理忍不住在客户旁边说"这个按钮点了之后会跳到这个页面"。客户操作到那个按钮,听到产品经理的解释,就没有自己点,直接跳到下一个。产品经理意识到自己越界了——客户不亲自点,就看不到"从首页到详情页"这个跳转路径上"2 秒等待"带来的不适感。产品经理立即停下来,会议规则临时改为"我不解释,您自己试"。这次规则调整后,客户在接下来的 30 分钟里点了 47 个位置,反馈数量比前 30 分钟多 4 倍。

**教训**:在会议开始前,团队应约定"沉默期"——前 5—10 分钟内任何人(包括产品经理)都不开口,让客户和 Demo 之间形成"独处"。这段沉默里,客户的每一声"嗯"、每一次停顿、每一次点击,都是数据。负责人后来给会议设计了一个物理动作:团队成员把手机放在桌上,屏幕朝下,双手抱胸,只看客户操作不开口。这个动作看起来"严肃",但实际效果是让团队保持"观察者"状态而非"讲解者"状态。跑了 9 次会议,这种"沉默期"累计收集到的需求信号,比会议后段(团队开始问问题)收集到的多 60%。

**规则二:团队不解释,只记录**。客户操作 Demo 时,团队不应解释"这个按钮是做什么的"、"这个功能是这么设计的"——这些解释会引导客户按设计走,而不是按真实预期走。团队只记录客户的每一步操作、口头反馈、表情变化,会后整理为需求列表。

**现场案例**:某次会议,客户点了一个"灰色按钮"后说"这个按钮是没用的吧?看起来像没启用"。工程师差点脱口而出"这是预约演示按钮,不是没启用"。产品经理在旁边用脚踢了工程师一下,工程师闭嘴。客户继续点,30 秒后说"等等,这个按钮点了好像有反应,那它是做什么的?"——客户自己发现了。事后工程师和产品经理复盘:"客户自己发现'灰色按钮可用'的过程,比任何解释都更有教育意义。如果当时解释,客户下次还是会认为'灰色=不可用',因为我们没说'我们故意做灰色但保留功能'的设计意图。"

**现场细节**:某次会议,产品经理发现工程师在客户操作时,忍不住在白板上画"系统架构图"给客户解释"为什么这个功能是这样的"。产品经理当时叫停了会议,私下对工程师说:"您的架构图很好,但现在不是讲架构的时候——客户想知道的是'他能用这个做什么',不是'系统内部怎么运转'。这两件事都重要,但不是同一个会议的内容。"工程师后来调整,在"团队不解释"会议里只记录,不画图;在"技术说明"会议里才画图、才讲架构。分开后,两类会议的质量都提高了。

**现场细节**:某次会议,客户操作 Demo 时,产品经理注意到客户在一个"次要按钮"上停了 5 秒,点了一下,没反应,又点了一下,还是没反应。客户皱眉说"这个按钮没反应?"。产品经理记下这条反馈。会后查代码,发现这个"次要按钮"根本没绑定事件——工程师做 Demo 时漏写了。客户在没有产品经理解释的情况下,自己发现了"次要按钮没反应"——这正是会议想要的"暴露需求模糊点"。产品经理会后对工程师说:"您漏写的这个按钮,客户自己发现了。如果当时您解释'这个按钮还没做完',客户就发现不了——客户发现'问题',比您'说明问题'更有价值。"

**规则三:形容词必须追问出数字**。客户说"这个颜色太深",团队追问"深到多少?给我们三个具体颜色你看哪个对";"加载太慢",追问"慢到多少秒你能接受";"价格太高",追问"高到多少你能接受"——形容词无法验收,数字才能验收。

**现场还原**:某次会议,客户说"这个颜色太深"。产品经理没有立刻调色,而是从色板里挑了 3 个色值:`#333333`、`#555555`、`#777777`,问客户"您看哪个对?"。客户选了第二个。然后产品经理又挑了 3 个:`#4A4A4A`、`#555555`、`#606060`,问"这个范围里哪个?"。客户选了第一个。这个过程用了 4 分钟,但"什么颜色算不深"的问题彻底解决了——如果当时只问"那您觉得多深合适?",客户大概率回答"浅一点",再调出来还是不满意。

### 4.3.2 反馈的记录格式

**现场细节**:负责人带过的 9 次需求对齐会议,平均每场产生 28 条原始反馈。原始反馈中,约 1/3 是"无意义的"(如"这个按钮感觉怪怪的",但说不出哪里怪),1/3 是"形容词"(需要追问出数字),1/3 是"具体可执行"的(已经包含位置、动作、原因)。**原始反馈的转化率 = 1/3**——28 条原始反馈,9—10 条能进入规格。这条"1/3 转化率"后来成了产品经理评估会议效率的指标:转化率<25% 说明"形容词太多,需要更多追问";>40% 说明"客户很清晰,会议效率高"。

每次会议应有一位专职记录员,实时记录客户的每条反馈。记录格式建议:

| 位置      | 客户操作 | 客户反馈     | 背后约束                  |
| ------- | ---- | -------- | --------------------- |
| 首页/主按钮  | 点击   | "这个不对"   | "我希望登录后能直接看到这个按钮"     |
| 商品详情/价格 | 滚动   | "价格要更明显" | "我们客户都是 50 岁以上,需要大字号" |

记录员不解释、不评价,只记录。解释留给团队会后,评价留给产品经理会后。

### 4.3.3 会议的时长

**现场还原**:某次会议,产品经理原计划 60 分钟,实际跑了 110 分钟。客户在 60 分钟时仍在"操作 Demo",产品经理想收尾("时间差不多了"),但客户刚进入状态。负责人悄悄给产品经理递了一张纸条:"再等 30 分钟,客户还没提'累了'。"——又过了 30 分钟,客户在第 95 分钟时主动说"今天差不多了",会议自然收尾。负责人后来讲:"客户说'差不多了'的时机,比计划时长更准——客户没累,不要收;客户累了,不要撑。"

会议时长不应事先硬性规定,而应根据客户状态灵活调整。经验上,会议在 60—90 分钟内最有效:60 分钟内客户操作认真、反馈密集;90 分钟后客户开始疲劳,反馈质量下降。

超过 90 分钟的会议建议分两次开——第一次看 Demo 的整体框架,第二次针对重点模块深聊。强行拉到 120 分钟以上,客户疲劳后给的反馈往往"凑数",质量不高。

### 4.3.4 会议的产出

**现场还原**:某次会议结束,产品经理汇总反馈时发现 3 条反馈是"矛盾的"——客户说"这个按钮要更明显",又说"这个按钮太大了"。产品经理当时没有立即判断"听哪条",而是回到客户操作时,重新看了一遍——发现"更明显"指的是颜色对比度("颜色不够深,看起来像背景"),"太大了"指的是尺寸("按钮的尺寸合适,但视觉上看起来'占地方',因为旁边没东西")。两个反馈指的不是同一个维度。产品经理后来定的规矩是:"看似矛盾的反馈,先回到现场看,不要立即判断'听哪条'。"

会议产出包括三部分:

* **已对齐项**:客户已明确认可的设计决策,可以直接进入规格
* **待补充信息**:客户未提供的信息,需要在后续沟通中补全
* **争议项**:客户反馈之间有矛盾或与业务约束冲突,需要团队讨论后定夺

争议项应在 24 小时内组织讨论,讨论后形成决议,决议必须由客户最终确认。

## 4.4 把对齐结果固化为规格

### 4.4.1 规格的形态

**现场还原**:某次复盘会,工程师拿出"规格文档",产品经理扫了一眼说"这是需求文档的翻版,不是规格"。工程师问"有什么区别?"产品经理答:"需求文档是'我们要做什么',规格是'系统 SHALL 做什么,WHEN 什么条件,THEN 什么结果'。前者读起来像散文,后者读起来像代码。"工程师后来重写,把 23 页需求文档压缩成 8 页规格,每一条都能被代码直接翻译为测试用例。

对齐会议结束后,会议结果不应停留在会议记录、聊天记录中,而应被固化为"规格文件"——写在代码仓库里,作为开发与验收的依据。

规格文件的形态不是"产品介绍",而是"可验收的测试用例"。每条规格包含:

* 系统 SHALL \[在什么条件下做什么]
* WHEN \[触发条件]
* THEN \[预期结果]

这种描述方式的好处:每条规格都可以被翻译为一个测试用例,开发完成后逐条核对,任何一条不成立,即视为不通过。

### 4.4.2 规格的存放

**现场细节**:某次项目,负责人把规格文件放在飞书文档里。3 个月后,工程师在 git 仓库里找规格,发现"飞书文档不在仓库,新人无法通过 git history 看到规格演变过程"。负责人当时把规格迁移到仓库的 `openspec/changes/[功能名]/specs.md`,从此所有规格随代码走。后来有客户问"我们能不能看到第 1 版规格",负责人 git checkout 即可,3 分钟拿到。这种"规格随代码走"的做法,跑 9 个项目,每个项目都让复盘效率提升 3 倍以上。

规格文件应存放在代码仓库的 `openspec/changes/[功能名]/specs.md` 路径下,随代码一起被 git 管理。规格的每次修改都应作为独立的 git commit,便于追溯"哪个版本改了什么"。

规格的存放路径与项目结构相关。如果项目使用 OpenSpec(规范驱动的开发工具,详见第 15 章),规格文件按 OpenSpec 约定组织;否则按团队约定,关键是"规格随代码走"。

### 4.4.3 规格的评审

**现场还原**:某次项目,规格文件定稿后,产品经理发了一条消息给客户:"规格已经定稿,请您在 24 小时内确认。确认后开始实现,后续修改按 V2 处理。"客户在 18 小时内回复"确认"。开发启动 5 天后,客户又发了一条:"这个按钮我改一下,浅一点。"工程师按客户要求改了。8 天后,客户再次发:"还是深一点好。"再改。负责人介入,问客户"您签字时是这一条,现在改到第几版了?"客户沉默 5 秒,答"按签字的版"。——这件事之后,负责人定的规矩是:"规格签字后,任何修改必须先改规格(双方重新签字),再改实现。"

规格定稿后,应组织"规格评审会",客户与开发团队一起核对每一条规格,确认"我同意系统按这条开发"。评审通过后,客户在规格文件上签字(电子签字或邮件确认均可),签字后规格生效。

### 4.4.4 规格的变更

规格不是"永久不变"的——客户在开发过程中可能提出新的需求或修改原有需求。但变更必须有纪律:

* 任何修改必须先改规格(双方重新签字),再改实现
* 修改后的规格作为新版本(v1.1、v1.2),原版本保留
* 每次修改记录变更日志(谁、何时、改了什么、为什么)

变更纪律的意义:让规格与实现始终一一对应,避免"客户口头改、工程师按口头改、文档没改"的脱节。

## 4.5 Demo 之后的工程纪律

### 4.5.1 Demo 的归档

**现场还原**:某次项目,客户在交付 2 个月后,想做新功能,说"能不能做成和那个 demo 里一样的?"产品经理答:"demo 已删除。"客户:"您当时怎么没提醒我保留?"产品经理复盘后给自己定了一条规矩:"客户说'没用'的时候,不直接删除——先冻结 90 天,90 天后客户没提,再删除。90 天内客户提了,立即解冻。"这条规矩跑了 4 次,Demo 全部保留下来,其中 2 次被复用。

但是,Demo 也有保留价值:在后续开发中,如果客户对某项需求再次模糊,可以让客户再看一遍 Demo(此时他们会基于后续讨论有新的反馈);或者在内部培训中,Demo 是"客户最直观的需求表达"。

**现场细节**:某次项目,Demo 被废弃后,工程师在归档时把所有 25 条会议反馈整理成了一份"客户认知图谱"——标注出"客户最在意的 5 个点"、"客户最反感的 3 种设计"、"客户提到的 7 个真实场景"。这份图谱被放在仓库的 docs/customer\_insights/ 目录,新工程师入职时第一周必读。负责人后来讲:"Demo 是'客户的当下想法',图谱是'客户的稳定特征'——前者易变,后者稳定。新人理解'稳定特征',上手更快。"

### 4.5.2 规格文件的执行

**现场案例**:某次项目,规格文件签字后,工程师实现到第 12 天时,客户突然说"我们改一下,这个按钮的颜色要深一点"。工程师改完。3 天后,客户又说"还是浅一点好"。再过 2 天,客户又改回来。负责人介入,问工程师"为什么你改?"工程师答"客户说改"。负责人给客户看了规格文件,指着"按钮颜色 SHALL 为 #XXXXXX"那一条,问"签字时是这条,现在改到第几版了?"客户沉默 5 秒,说"按签字的版"。——这件事之后,负责人定的规矩是:"规格签字后,任何修改必须先改规格(双方重新签字),再改实现。"

规格文件签字后,正式开发按规格文件执行。每条"SHALL"对应一项必须实现的功能;每条"WHEN...THEN..."对应一项必须通过的测试。开发完成后,逐条核对验收场景,确保每项都成立。

规格文件的执行纪律:**实现与规格必须一一对应**。实现时有偏差,必须先更新规格(并请客户确认),再调整实现;不可"先按自己想法实现,回头再改规格"——后者会让规格与实现脱钩,失去约束作用。

**现场细节**:某次项目,工程师实现到第 8 天时,发现规格里有一条"WHEN 用户上传图片 THEN 系统保留原图"——但工程师觉得"应该压缩图片以节省存储",于是自己加了一条"压缩到原图的 80%"的逻辑。客户在第 14 天验收时说"图片怎么不清晰了?"工程师答"做了优化,压缩到 80%。"客户说"我没让您优化,我要的是原图。"工程师答"我觉得压缩更好。"——这次争论持续了 2 天,最终工程师按规格改回原图。教训:工程师的"我觉得"不是规格的修改理由——规格的修改理由是"客户明确要求改"。负责人后来给团队讲:"规格不是'工程师的工作建议',是'客户的明确指令'——两个不同来源,不能混淆。"

## 4.6 方法论提炼与可复用资产

**现场还原**:三个原则不是某次会议定下来的,是负责人在 9 次项目里逐步沉淀的。前 3 个项目,负责人靠"感觉"开对齐会议;第 4 个项目时,客户反馈"会议效率高",负责人开始把"会议规则"记下来;第 6 个项目时,客户说"我们之前开会也是这么开的,但没人把规则写出来",负责人意识到这可以做成"可复用方法论";第 7—9 个项目,负责人用这三个原则去验证,改进了两次,稳定为现在这三个。

本章的方法论可提炼为三个原则。

**原则一:让客户看到东西,而不是描述东西**。描述会失真,实物不会。Demo 让客户"看到产品",即使功能不全,也已经比文档更接近真实。

**原则二:形容词不能验收,数字才能验收**。会议过程中,所有形容词必须被追问出具体数字。客户说"价格太高",必须追问"具体到多少你能接受"——没有数字的反馈不可执行。

**原则三:规格必须固化,与代码同源**。会议结论散落在会议记录、聊天记录中,无法被后续工作引用。把规格写成文件、放进代码仓库,才能在开发全程被使用。

**可复用资产:对齐会议反馈记录模板**——本节 4.3.2 给出的结构,可作为所有需求对齐会议的记录模板。

```
对齐会议反馈记录

会议时间:
客户:
参与人:

| 位置 | 客户操作 | 客户反馈 | 背后约束 |
|------|----------|----------|----------|
| 首页/主按钮 | 点击 | "这个不对" | "我希望登录后能直接看到这个按钮" |
| ... | ... | ... | ... |

待客户确认的开放问题:
1.
2.

会议结论:
- 已对齐项:N 条
- 待补充信息:M 条
- 预计规格文件定稿: [日期]
```

**可复用资产二:规格文件模板**——本节 4.4.1 给出的结构,可作为所有需求规格文件的模板。

```
# 需求规格:[功能名]

## 背景
[业务上要解决的问题]

## 验收标准
- 系统 SHALL [在什么条件下做什么]
- 系统 SHALL [在什么条件下做什么]

## 验收场景
### 场景 1:[场景描述]
- WHEN [条件]
- THEN [结果]

## 边界条件
- 不做什么:[明确说明]

## 约束
- 业务约束:[说明]
- 技术约束:[说明]
```

### 4.7.1 本章思考题

1. 4.2.2 的"7 选 1"问法:如果你的产品有 8 个候选模块,客户选了 1 个,选的是"最重要的"还是"最不满意的"?后者为什么比前者更有对齐价值?
2. 4.3.1 的"沉默期"规则:你开需求评审会时,前 5—10 分钟有没有让客户独自操作 Demo?如果没有,会议的信息损失率可能是多少?
3. 4.3.2 的"原始反馈转化率 = 1/3":你团队最近一次需求会议的转化率是多少?如果低于 25%,问题出在"形容词太多"还是"追问不够"?
4. 4.4.1 的规格格式"SHALL/WHEN/THEN":你团队的规格文档能用这个格式重写吗?重写后能从几页压缩到几页?
5. 如果客户的反馈是矛盾的(如"按钮要更明显"又说"按钮太大了"),4.3.4 的处理方式是"回到现场看,不要立即判断听哪条"。你团队有这种"看似矛盾先回看"的纪律吗?

### 4.7.2 本章延伸阅读

1. **\[工具文档] Fission-AI/OpenSpec GitHub README** — SDD 轻量规范层、四件套工件、/opsx 命令、30+ 助手兼容 | 第 4 章
2. **\[工具文档] PostHog/sdk-specs 仓库** — OpenSpec 实战用法,SHALL/Scenario WHEN-THEN 格式示例、archive 把 delta 合并回主规格 | 第 4 章
3. **\[文章] redreamality OpenSpec 1.5 更新解读** — 终端 CLI 与 AI slash command 的分工、explore-first 工作流、brownfield delta-first 建议 | 第 4 章
4. **\[文章] ailinklab OpenSpec 上手与适用边界** — "误解成本高于文档成本才用 OpenSpec"的选型判据、探索性原型不适用 | 第 4 章
5. **\[书] 《设计中的设计》原研哉** — 用 Demo 对齐需求时,"设计意图"比"功能列表"更能识别客户真实诉求 | 第 4 章

## 4.7 完整提示词:24 小时 Demo 对齐流程

以下提示词直接用于"用 24 小时 Demo 替代需求文档对齐"。它把"做出来 → 客户操作 → 反馈 → 固化规格"的全流程落到 prompt 里,让 AI 严格按时间盒推进,且每一步都向客户确认而非自顾自推进。

```
你是产品经理助手,擅长用"做出来让客户看"的方式代替"写文档让客户读"的方式对齐需求。接下来的所有工作,你需要严格按 24 小时时间盒推进——任何超过 24 小时范围的功能,必须砍掉或后做,不允许以"再加一点就更好"为由延期。

【你的工作方式】
- 阶段一(0—2 小时):需求澄清——把客户的模糊语言翻译为可执行的具体范围
- 阶段二(2—6 小时):Demo 设计——选定核心场景(1—2 个),准备真实感数据
- 阶段三(6—20 小时):Demo 实现——做出可交互样品,功能可有 10% 完成度,视觉 70% 即可
- 阶段四(20—22 小时):部署到免费托管服务(如 Vercel、Netlify),生成访问链接
- 阶段五(22—24 小时):通知客户进行操作式反馈会议,准备记录模板

【你接到任务的第一步】
不要直接开始做 Demo。先用一段话把客户诉求说回来——
"我理解您希望做的是 [Demo 类型],核心场景是 [场景 1 + 场景 2],目标用户是 [具体用户群]。这个 Demo 24 小时后交付,完成度约为 [视觉 70% + 功能 10%],不做的事情包括 [清单]。您看这个范围对吗?"

【Demo 的范围选择原则】
- 只覆盖客户最关心的 1—2 个核心场景
- 视觉完成度 70%——形似但一眼可看出"尚未完工"
- 功能完成度 10%——主流程能走通,边角全留空
- 真实感数据(从客户业务或行业典型数据脱敏而来),不是 "test_1, test_2"
- 每个页面标注"演示数据"水印,不设例外

【24 小时时间盒的纪律】
- 第 6 小时必须有可见的中间产物
- 第 12 小时必须有可点击的页面
- 第 20 小时必须有可演示的完整流程
- 超过 24 小时的任何功能,标记为 V2,不在本次范围内
- 不要追求"完美"——Demo 的考核指标是"让客户说出不对的地方",不是"让客户说不出不对"

【Demo 会议规则(你帮客户会议准备)】
- 客户亲自操作,你不替代点击
- 你不解释设计,只记录反馈
- 形容词必须追问出数字("及时是多快?""大气是哪一种?")
- 每条反馈按"位置 + 操作 + 原话 + 背后约束"四列记录
- 60—90 分钟,前 15 分钟自由操作,中间 60 分钟针对操作提问,最后 15 分钟客户总结

【反馈固化】
会议结束后,你需要——
1. 把 60 分钟记录整理为"已对齐项 N 条 / 待补充信息 M 条"
2. 把每条"已对齐项"翻译为"SHALL"或"WHEN...THEN..."的规格描述
3. 把规格写入仓库的 openspec/changes/[功能名]/specs.md
4. 提交客户签字

【输出格式】
- 阶段一产出:范围确认文档(2 段话)
- 阶段二产出:Demo 设计稿(2—3 个核心页面线框图 + 真实感数据样本)
- 阶段三产出:可访问的 Demo URL + 完整源代码
- 阶段四产出:演示数据水印、部署链接
- 阶段五产出:对齐会议纪要 + 规格文件初稿

【边界约束】
- 不做"完整功能"的 Demo——完成度刻意压低
- 不替客户做"做出来指什么"的判断——必须问清楚
- 不跳过客户亲自操作的环节——这是对齐的核心
- 不接受客户的"差不多就行"作为对齐结论——必须翻译为数字
- 客户签字后提出的修改,作为 V2 需求处理,不混入 V1

【Demo 完成后,客户反馈是这种情况,处理如下】
- "这里不对" → 追问"哪里不对?期望是什么?"
- "再加一个 X 功能" → "X 属于 V2,V1 范围内不增加"
- "整体可以,细节再议" → 必须问出"哪些细节",不接受笼统反馈
- 客户说"先这样吧" → 拒绝接受,要求继续讨论
- 客户已签字的反馈 → 写入规格,不可逆
```

## 本章方法论:把抽象需求变为具体操作

需求对齐的本质,不是让客户描述清楚他要什么,而是让客户在看到实物后指出哪里不对。本章介绍的方法,利用 AI 的快速产出能力,在 24 小时内将客户的模糊描述变为可操作的 Demo,再通过让客户亲自操作 Demo,自然地暴露需求模糊点。这一方法将"需求对齐"从抽象讨论变为具体操作,大幅降低沟通成本。

下一章将进入"业务数据分析"——AI 替读者处理真实业务数据(销售、订单、客户行为)时,如何建立取数、清洗、分析、呈现的完整闭环。这一章关注的是"AI 替读者干活"的另一面:不只是生成内容,更是处理数据并产出可决策的洞察。