第二章：需求分析与原型设计
说实话，很多开发同学拿到PRD的第一反应是——直接翻到功能列表，然后开始写代码。我年轻时也这么干过，结果呢？做了三版，产品经理说“不对，我要的是那个感觉”。嗯，那个“感觉”到底是什么？没人说得清。
这一章，我们就来聊聊怎么读懂PRD、怎么画原型、怎么写用户故事。说白了，就是让你和产品经理之间，少一点“我以为”，多一点“我们确认过”。
2.1 读懂PRD：不只是看功能列表
PRD（产品需求文档）是产品经理的“剧本”。但很多PRD写得像天书——逻辑跳跃、术语混乱、甚至前后矛盾。我见过最离谱的一份PRD，功能描述里写着“类似微信朋友圈”，但没说具体哪些功能要、哪些不要。
怎么破？我的习惯是三步走：
- 先看背景和目标——为什么做这个功能？解决什么问题？
- 再看用户角色——谁在用？管理员、普通用户、还是游客？
- 最后看功能细节——每个按钮、每个状态、每个异常怎么处理。
你想想看，如果连“为什么要做”都没搞懂，你写出来的代码大概率要返工。我在项目中遇到过好几次，开发到一半产品经理说“这个需求取消了”，就是因为前期没对齐目标。
核心要点：PRD不是圣经，它是沟通的起点。读不懂的地方，一定要追问。别怕显得自己“不懂”，怕的是上线后才发现理解错了。
2.2 低保真原型：用Axure/Figma快速验证
原型设计分两种：低保真和高保真。我们全栈工程师重点关注低保真——说白了，就是画个框、放个按钮、连个跳转。不需要配色，不需要图标，甚至不需要对齐像素。
为什么？因为快。你花三天画一个高保真原型，产品经理说“改一下”，你心态就崩了。低保真原型，半小时搞定，改起来也快。
2.2.1 用Axure画原型
Axure是老牌工具，功能强大，但学习曲线略陡。我个人习惯用它做复杂的交互逻辑，比如条件判断、动态面板、中继器。举个例子：
// 这不是代码，是Axure的交互逻辑描述
条件：用户点击“登录”按钮
如果：用户名和密码都不为空
则：跳转到首页
否则：显示错误提示“请填写完整信息”你看，这种逻辑在Axure里用“交互面板”就能配出来，不需要写一行代码。但要注意，别把原型做得太复杂——它只是用来沟通的，不是用来交付的。
2.2.2 用Figma画原型
Figma最近很火，我团队现在基本都用它。优点是协作方便、组件复用、实时预览。缺点嘛，交互能力比Axure弱一些，但做低保真完全够用。
我的建议是：
- 用Figma的“组件”功能，把按钮、输入框、弹窗做成可复用的组件
- 用“自动布局”功能，让原型自适应不同屏幕尺寸
- 用“原型”模式，添加简单的页面跳转和悬停效果
小技巧：画原型时，别纠结“这个按钮是蓝色还是灰色”。用黑白灰就够了，重点是把页面结构和交互流程讲清楚。颜色的事，交给UI设计师。
2.3 用户故事：从“我要”到“我能”
用户故事是敏捷开发里的核心概念。格式很简单：
作为 [用户角色]
我想要 [功能]
以便 [实现价值]举个例子：
作为 普通用户
我想要 在忘记密码时能通过邮箱重置
以便 我不用联系客服就能找回账号你看，这个用户故事把“谁、做什么、为什么”都说清楚了。但光有用户故事还不够，你还需要验收标准——也就是“怎么做才算做完”。
2.3.1 验收标准怎么写
验收标准（Acceptance Criteria）是用户故事的“完成定义”。我一般用Given-When-Then格式：
Given 用户在登录页面
When 用户点击“忘记密码”链接
Then 系统跳转到密码重置页面
And 用户输入注册邮箱后，收到重置邮件这样写的好处是：测试人员可以直接拿它写测试用例，开发人员也能明确知道“做到什么程度算完”。
避坑指南：我曾经遇到过团队把用户故事写成了“技术任务”——比如“实现密码加密存储”。这不是用户故事，这是技术实现。用户故事一定要从用户视角出发，而不是从开发视角。
2.4 从原型到代码：一个实战案例
光说不练假把式。我们来看一个真实的案例：
需求：用户可以在个人中心修改头像。
PRD描述：“用户点击头像区域，弹出拍照或从相册选择的选项，选择后裁剪并上传。”
低保真原型：
+------------------+
| 个人中心 |
| [头像] | ← 点击这里
| 用户名: 张三 |
| 手机号: 138xxxx |
+------------------+
点击头像后弹出：
+------------------+
| 选择头像来源 |
| [拍照] [相册] |
+------------------+用户故事：
作为 已登录用户
我想要 修改我的头像
以便 我的个人资料看起来更个性化
验收标准：
1. 用户点击头像区域，弹出选择来源的弹窗
2. 选择“拍照”则打开相机（仅移动端）
3. 选择“相册”则打开文件选择器
4. 选择图片后进入裁剪页面，支持缩放和拖动
5. 裁剪完成后上传，上传过程中显示进度
6. 上传成功后，头像立即更新
7. 上传失败时，显示错误提示，不改变原头像你看，从PRD到原型到用户故事，每一步都在细化。等你拿到这些材料，写代码的时候心里就有底了——不会出现“这个弹窗要不要加关闭按钮”这种问题。
总结一下：需求分析不是产品经理一个人的事。作为全栈工程师，你要主动参与、主动提问、主动验证。别等到代码写完了才发现“哦，原来需求理解错了”。那时候改代码的成本，可比改原型高多了。
好，这一章就聊到这里。下一章我们会进入技术选型——怎么选前端框架、后端语言、数据库，以及为什么我推荐某些组合。嗯，到时候再细聊。