成交
第 4 课：定位、功能优先级与可验收 PRD
当需求和对标都很多时，AI 会倾向于把所有想法塞进第一版，结果是页面多、数据假、表单不通。本节把证据变成定位、用户任务、功能边界和逐条可测试的验收标准，让 TRAE 有一份稳定的单一事实来源。
1. 这一节解决什么问题
当需求和对标都很多时，AI 会倾向于把所有想法塞进第一版，结果是页面多、数据假、表单不通。本节把证据变成定位、用户任务、功能边界和逐条可测试的验收标准，让 TRAE 有一份稳定的单一事实来源。
2. 学完要拿到什么结果
- 产品定位卡与主用户画像。
- Must/Should/Could/Won't 功能表。
- 一份完整 PRD。
- 网站页面结构表与内容责任人。
- 发布前必须由企业确认的事实清单。
3. 对应的开源对标及链接
- easy-vibe：写代码前确定需求：参考先向业务提问、再锁定核心功能的顺序。
- TRAE Spec 与 Plan 官方文档：复杂新项目可用
/spec生成大纲、任务和验收清单。 - Web Dev For Beginners lesson template：参考任务与量规分离的结构。
4. 完整图文课程正文
4.1 定位不是口号
定位句必须包含谁、场景、问题、结果和差异：为“需要从中国采购大蒜的海外批发买家”，在“筛选供应与准备询价”时，提供“可核验的品类、规格、包装、质量流程与结构化 RFQ”，区别于“只有宣传口号和通用联系表的企业官网”。
4.2 用户画像写任务，不写想象的人设
“35 岁、爱旅行”通常无助于页面决策。有效画像是：角色、触发事件、要完成的工作、必须知道的信息、风险、决策者、使用设备和成功标准。主用户只选一个：海外采购负责人；供应方业务是后台接收者，不与主用户争首页叙事。
4.3 MoSCoW 控制第一版
| 级别 | 判断问题 | 本项目例子 |
|---|---|---|
| Must | 缺少就无法形成询盘闭环吗 | 英文首页、产品详情、RFQ、联系方式、移动端、SEO |
| Should | 明显增强信任但可在闭环后完善吗 | 合作流程、质量控制说明、FAQ、中英文切换 |
| Could | 有价值但证据或资源不足吗 | PDF 目录下载、即时运费估算 |
| Won't | 本轮明确不做吗 | 在线支付、库存、账号、自动承诺交期 |
“Won't”是保护交付，不是永久拒绝。
4.4 把形容词改成验收
“页面高级”“SEO 做好”“表单可用”都不能验收。改写为：手机宽 375px 无横向滚动；首页 H1 只出现一次；每个产品详情有唯一标题和描述；必填字段为空时阻止提交并给出中文/英文错误；配置有效表单密钥后测试邮箱收到一封含产品、数量、目的港和同意隐私条款的邮件。
4.5 页面结构与证据责任
flowchart TD
H[中/英文首页] --> P[产品分类]
P --> D[产品详情]
H --> A[公司与产地供应]
H --> Q[质量控制]
H --> M[出口意向市场/合作流程]
D --> R[RFQ]
A --> R
Q --> R
F[FAQ] --> R
每个页面必须指定事实来源和确认人。没有确认人的商业声明不得在发布版取消“示例数据”标记。
5. 零基础用户能够执行的操作步骤
- 填写产品定位卡和用户画像表。
- 把第 2 课的前三个问题逐一转换为用户故事：作为谁，我想做什么，以便得到什么。
- 填写功能优先级表，每项写证据编号和不做后果。
- 复制PRD 模板，写背景、目标、非目标、路由、内容、功能、数据、风险和验收。
- 填写网站页面结构表与内容收集表。
- 为所有数字、资质、市场、交期和联系方式指定企业确认人；未确认项保持明确标签。
- 请一位不参与编写的人只看 PRD，复述第一版做什么、不做什么；复述不一致就修改。
- Git 提交：
docs: 确认产品范围与 PRD 验收标准。
6. 可直接复制给 TRAE 或其他 AI 的提示词
你是 B2B 网站产品经理。基于我提供的需求证据与对标表，生成可执行 PRD，不添加未提供的商业事实。
必须包含：主用户、触发场景、目标、非目标、用户故事、路由清单、中英文内容要求、功能优先级、RFQ 字段、SEO、可访问性、移动端、异常状态、数据与隐私、逐条可测试验收。
约束：
- 不做在线支付、账号、库存和自动报价；
- 企业名、产能、证书、市场、交期、客户案例未知时标“示例数据，发布前需企业确认”；
- 不显示虚构客户评价；
- 表单密钥只读环境变量；
- 每个 Must 功能必须引用证据编号。
先列出相互矛盾或缺失的信息，再输出 PRD。
7. 云南大蒜项目中的具体示范
主用户故事：作为第一次评估云南大蒜供应方的海外采购负责人，我希望先比较产品类型、尺寸方案、包装选择、质量控制和合作步骤，再用 RFQ 提交数量、目的港和时间要求，以便供应方给出可比较的人工报价。
关键页面路由：
| 路由 | 目的 | 关键内容 | 真实数据状态 |
|---|---|---|---|
/en、/zh | 建立价值与进入路径 | 品类、供应说明、流程、RFQ CTA | 品牌与供应数据为课程示例 |
/:lang/products | 比较品类 | 白蒜、紫皮蒜、去皮蒜 | 品类可展示；商业规格需确认 |
/:lang/products/:slug | 准备询价 | 规格、包装、存储、RFQ 预填 | 全部写拟议选项/需确认 |
/:lang/about | 了解主体与产地 | 企业、产地、种植和供应能力 | 不做真实主体声明 |
/:lang/quality | 理解质控 | 检查节点、证书展示规则 | 不放虚构证书 |
/:lang/markets | 确认合作方式 | 意向市场、合作流程、案例说明 | 不声称已出口 |
/:lang/faq | 消除常见疑问 | MOQ、样品、付款、物流的确认方式 | 不承诺具体数值 |
/:lang/contact | 提交 RFQ | 结构化字段、隐私同意、备选联系 | 配置后真实收信 |
8. 可填写模板
验收故事卡：
| 字段 | 内容 |
|---|---|
| 用户故事 | 作为…我希望…以便… |
| 证据编号 | |
| 前置条件 | |
| 操作 | |
| 可观察结果 | |
| 异常结果 | |
| 本轮不包含 |
完整填写示例见PRD 模板。
9. 常见错误
- PRD 只有功能名，没有用户动作、异常或验收。
- 同时为采购者、零售消费者、种植户和招商对象设计首页。
- 把演示用的规格或产能写成现实承诺。
- 要求“支持双语”，却没规定 URL、切换后对应页和元信息。
- “表单成功”只检查绿色提示，不检查邮箱实际收件。
10. 排错方法
范围不断扩大时，逐项问“没有它能否完成测试 RFQ”；能就降为 Should/Could。内容冲突时，PRD 只记录已确认事实和冲突责任人，不让 AI 选一个。验收无法判断时，把形容词换成可观察的页面、URL、邮件、HTTP 状态、截图或清单结果。
11. 完成标准
-
定位句含用户、场景、问题、结果和差异。
-
只有一个主用户，画像围绕任务与风险。
-
每个 Must 功能有需求证据和可测试验收。
-
PRD 写明非目标、异常、隐私和移动端。
-
页面内容都有来源/确认状态，没有虚构声明。
12. 本节成果如何进入下一节
下一节把 PRD、任务和验收放入 TRAE 项目上下文，建立项目规则与小步执行方法。PRD 将成为 AI 的事实边界；任何新建议先回到优先级表，不直接进入代码。
上一节：第 3 课：搜索、拆解与合法使用对标
下一节：第 5 课：TRAE IDE 安装、规则、上下文与小步开发