AI 原型先行做需求定义：在写规格书之前先对齐认知

需求定义最常见的失败不是文档写得太少，而是文字本身承载不了画面。同一句「列表页可以筛选」，需求方想的是顶部搜索框，设计想的是左侧筛选面板，实现的人先放一个下拉框交差——三方都以为已经达成一致，直到验收测试才发现各想各的。AI 原型先行的做法是把顺序倒过来：先让 AI 编码工具生成一个能点、能跳转的界面原型，把它当作讨论的共同参照物，等认知对齐之后再补文字规格。本文整理这套流程的完整操作步骤、可直接复用的提示词、容易暴露的偏差类型，以及它不适用的场景。适合正在做业务系统或新服务立项、需求方自己也说不清要什么的人阅读。

准备工作

工具与账号

核心工具是一个能读写文件、能执行命令的 AI 编码代理（agent 型工具），例如 Claude Code 这类可以在项目目录里直接创建和修改文件的工具。也可以使用其他具备同等能力的编码助手，思路完全一致。使用前需要：

该工具的账号与可用的模型额度，具体套餐、价格与额度上限以官网当前信息为准。
本地已安装运行时环境（Node.js 或 Python 任一即可），用于起一个本地静态服务器预览原型。
一个现代浏览器，用于打开生成的原型文件。

材料准备

不需要写规格书。需要的是把前期访谈、会议记录、零散需求整理成一页纸的要点清单，控制在 A4 一页左右，包含三类信息：

谁在用：使用者的角色，例如销售、客服主管、仓库管理员。
想达成什么：这个角色要完成的目标，用一句话说清。
现在卡在哪：当前流程里最痛的环节。

这一阶段不要列功能清单。功能一旦先列出来，原型就会退化成「功能的展示板」，讨论会围绕「这个按钮放哪」而不是「这个流程对不对」展开，反而丢掉最有价值的信息。

心理准备

需要提前和所有参与者说明一件事：这份原型是一次性消耗品，用完即弃，不会进入生产代码。这句话要在第一次演示之前就说出口，而不是等有人问「是不是快做完了」再解释。

操作步骤

步骤一：只准备一页要点清单

把访谈笔记压缩成一页要点，格式不限，但必须包含角色、目标、现状三类信息。示例：

- 角色：销售代表
- 目标：当天出门前确认访问顺序，回公司后补录结果
- 现状：访问计划散在聊天记录里，结果靠手写再录入，经常漏
- 已知约束：手机和电脑都要能用

注意这里没有出现「需要一个列表页」「需要筛选功能」这类描述。功能是原型生成之后讨论出来的产物，不是输入。

步骤二：明确「一次性」并生成原型

第一次下指令时，必须把「不追求生产质量」写进提示词。可复用的提示词模板：

请根据下面的要点，生成一个界面原型。

- 目的：销售代表确认当天访问计划，并录入访问结果
- 约束：不需要后端。数据以假数据形式写在代码内部
- 前提：这是一次性原型，目的是确认外观和页面跳转
- 不确定的地方不要自行决定，在界面上用「待确认」标记出来

输出为单个 HTML 文件。

要点：
（此处粘贴步骤一的一页清单）

这段提示词里最关键的一句是「不确定的地方不要自行决定，用待确认标记出来」。AI 天然倾向于把空白补全成看起来合理的样子，如果放任它补，那些补出来的内容会伪装成需求混进讨论。让它把补全的地方显式标出来，这些标记就自动变成了一份提问清单。

要求输出单个 HTML 文件有两个好处：一是分享成本极低，发一个文件对方双击就能打开；二是不涉及构建流程，不会让人误以为这是正式工程。

步骤三：让需求方本人操作

屏幕共享演示是不够的。必须把文件发给需求方，让他自己点。需要记录三类信号：

他问「这个按钮点了会怎样」的位置——说明该处的行为在原型里没有表达清楚。
他按了非预期顺序操作的位置——说明实际流程和设计假设不一致。
他说「啊对了，还有一件事」的位置——这是价值最高的信号，文字阶段想不起来的业务规则，往往在看着界面的一瞬间被回忆起来。

操作过程中的原话要记下来，不要只记结论。原话里包含的判断依据，是后面写规格时最难得的材料。

步骤四：把意见作为增量指令回给 AI

收集到的意见不要整理成正式文档再转述，直接在对话里作为追加指令发回去：

请反映以下修改：
1. 访问结果改为「成交 / 放弃 / 再访」三选一
2. 只有选择「放弃」时，原因输入框才设为必填
3. 列表初始排序改为按日期，而不是按负责人

请列出所有改动的位置。

要求它列出改动位置，是为了在下一轮确认时能快速定位，避免改了哪里自己都不知道。这个来回通常要跑几轮，每一轮都很短，有时当场改完就能再确认一次。

步骤五：从原型反推文字规格

认知对齐之后，才轮到文字登场。此时写规格的方式是看着原型写：逐屏列出字段、输入校验、状态迁移。因为答案已经在手边，写出来的文字精度会明显高于凭空起草。

顺序颠倒了一下，但文字规格并没有被取消，只是从「讨论的起点」变成了「结论的载体」。

一个完整示例

下面走一遍最小可用的完整流程，场景是销售访问管理。

1. 输入要点

- 角色：销售代表
- 目标：出门前确认当天访问顺序，回公司后补录结果
- 现状：计划散在聊天记录，结果手写后录入，经常漏
- 约束：手机和电脑都要能用

2. 生成原型

用步骤二的提示词模板，把上面的要点粘进去。工具会在当前目录生成一个 HTML 文件，例如 mock.html。用本地静态服务器打开：

python3 -m http.server 8000
# 然后在浏览器访问 http://localhost:8000/mock.html

如果只是自己看，直接双击文件用浏览器打开也可以。原型里应当能看到：一个当天的访问列表、每条记录的结果录入入口、以及若干处「待确认」标记。

3. 需求方操作并记录

把文件发过去，让他自己点。假设记录到以下内容：

「这个『完成』点了之后还能改吗？」——状态迁移未定义。
他先点了列表里的第二条，而不是第一条——默认排序假设错误。
「对了，如果客户临时取消，这条记录要留痕。」——文字阶段没提到的业务规则。

4. 回传修改

请反映以下修改：
1. 结果录入后 24 小时内可修改，超过后只读
2. 列表默认按访问时间正序排列
3. 增加「客户取消」状态，取消的记录保留在列表中并标记

请列出所有改动的位置。

改完再确认一轮，通常两到三轮之后，界面上的「待确认」标记会全部被消解成明确决定。

5. 反推规格

此时再写文字规格，内容大致是：列表页字段（客户名、访问时间、状态、结果）、结果录入页的三种状态与必填规则、24 小时可编辑窗口、取消记录的留痕要求。每一条都能对应到原型上某个具体界面，不存在「读的人各自想象」的空间。

原型容易暴露的几类认知偏差

下面这些偏差在纯文字评审里几乎不会被发现，因为写的人不觉得自己写错了，读的人也不觉得自己理解错了。

偏差类型	典型表现
用词偏差	「客户」指的是法人还是个人，双方默认不同
粒度偏差	一方想一屏搞定，另一方想象的是分步向导
权限偏差	谁能编辑、谁只能查看，从未被明确讨论
状态偏差	「完成」之后还能不能撤销
优先级偏差	需求方真正会用的其实只有两个功能

用词和权限这类问题，理论上文字也能写清楚。之所以仍然会漏，是因为写的人认为这些是「理所当然」的常识。当界面上摆着具体的假数据——具体的客户名、具体的金额、具体的日期——这些「理所当然」会立刻变成看得见的具体内容，违和感也就随之浮现。

注意事项

原型不擅长的场景

这套方法不是万能的，以下情况用文字先行更安全：

几乎没有界面的项目：批处理、数据集成、API 设计为主的项目，没有东西可以展示。
非功能需求为主的项目：性能、可用性、安全性无法通过原型确认。
合同上以规格书为交付物的项目：只有原型，事后很难界定「范围到哪里为止」。
法规与审计要求较重的领域：判断依据必须以文字留档。

常见失败模式

原型做得太精致，被误认为「已经快做完了」。对策是在一开始就口头说明这是一次性原型，并且在界面上直接标注数据为假数据。
外观讨论过热，业务规则的确认被挤到一边。需要有人主动把话题拉回流程和规则。
AI 自行补全的规格未经确认就被当成结论。这正是「待确认」标记存在的意义，每一处标记都必须有人给出答复。
把原型代码直接拿去生产用，背上质量债。原型以假数据为前提，没有考虑设计和测试。

需要提前定好的两条规则

原型和规格书同时存在时，一定会出现「以哪个为准」的争执。开工前先约定：

达成一致之后，以规格书为准，原型降级为参考资料。
原型的代码原则上不进入生产环境。

原型和文档不是替代关系，而是分工关系：原型负责对齐看得见的部分，文档负责承载看不见的部分。

需求方偏好文字的情况

有些需求方习惯用文字做逻辑推演，会觉得原型「不够严肃」。这种情况下把原型和一份简短说明并排呈现，接受度会明显提高。不要试图用原型取代文字，那只会引发不必要的抵触。

易变信息

本文提到的工具能力、模型额度、套餐价格等均可能变化，实际使用前请以各工具官网当前信息为准。