# C端 Widget 产品需求定义规范

版本：v0.12
状态：已确认的 Widget 产品需求输出规范

## 修订记录

| 日期 | 版本 | 变更类型 | 变更摘要 |
| --- | --- | --- | --- |
| 2026-07-30 | v0.1 | 初始创建 | 建立 Widget 定义与执行方案初稿。 |
| 2026-07-30 | v0.2 | 重大 | 明确部分 Widget 的对象边界。 |
| 2026-07-30 | v0.3 | 重大 | 补充费用与贷款试算的范围讨论。 |
| 2026-07-30 | v0.4 | 重大 | 补充定义、可见性、版本和原型状态要求。 |
| 2026-07-30 | v0.5 | 重大 | 调整优先级判定口径。 |
| 2026-07-30 | v0.6 | 重大：文档重构 | 删除优先级、分期、清单、迁移计划、截图结论及单项 Widget 决策。 |
| 2026-07-30 | v0.7 | 重大 | 补充用户价值、配置、状态、依赖与验收要求。 |
| 2026-07-30 | v0.8 | 重大 | 补充标识、内容责任与引用一致性要求。 |
| 2026-08-02 | v0.9 | 重大：逐项评审后重构 | 按确认结果重构为 Widget 产品需求输出规范；只保留 Widget 定义与单项 PRD 固定结构，移除注册状态、实例、版本快照、标识映射及其他实现导向内容。 |
| 2026-08-04 | v0.10 | 重大：项目内容来源协同规则补充 | 明确 A端维护项目内容来源字典；每个 Widget 仅引用可使用的来源分类及选择规则，供 A端生成实例页面时列出并勾选对应项目数据。 |
| 2026-08-04 | v0.11 | 重大：内容对象归属修订 | 取消 A端全局来源字典；每个 Widget 直接由开发提供可配置内容对象与组合规则，A/B 只读使用，不得自行扩大。 |
| 2026-08-09 | v0.12 | 重大：展示内容来源收敛 | 建立 Widget 顾客可见内容白名单规则；禁止页面、原型、设计或 AI 依据通用槽位、旧页面和演示需要自行增加展示内容。 |

## 1. 文档目的与适用范围

本文件规定后续每一个 C端 Widget 产品需求应如何定义和输出。它用于确保不同 Widget 的需求文档具有一致的产品结构，并足以指导设计、原型、开发和测试。

本文件只定义“如何编写 Widget 产品需求”，不定义：

- Widget 开发清单、优先级、排期或 MVP 范围；
- 页面引用关系、页面顺序、路由、入口与返回；
- 某个具体 Widget 的功能结论、数据内容、交互方案或验收结果；
- A/B端的管理表字段、实例存储、注册流程、版本快照或其他实现方案；
- 接口、数据库字段、API URL、密钥、技术架构、性能、埋点或通信机制；
- 截图分析、历史资料结论和设计系统的具体视觉规格。

需求文档的版本、文档状态和修订记录，统一遵循项目通用产品文档规范，不在本文件另行定义。

## 2. 什么是 Widget

Widget 是面向顾客的独立业务能力。它围绕一个明确的顾客任务形成完整体验，并可作为一种能力被管理和使用。

一个对象可定义为 Widget，应同时满足：

1. 顾客任务明确：顾客能在其中完成浏览、理解、选择、体验、计算或提交等业务任务。
2. 需求目的明确：能说明顾客为什么需要该能力。
3. 内容或业务输入明确：有确定的业务内容、数据对象、配置或外部内容作为输入。
4. 体验与状态明确：能定义正常使用、内容缺失或不可用时的顾客体验。
5. 不依赖页面结构成立：即使当前只在一个页面使用，只要具有独立任务和规则，仍可定义为 Widget。

### 2.1 Widget 与相邻对象的边界

| 对象 | 定义 | 是否属于 Widget |
| --- | --- | --- |
| Widget | 围绕一个顾客业务任务，定义内容、规则、交互和状态的能力。 | 是。 |
| 页面 | 承载和组织顾客访问的内容与能力。 | 否。 |
| 通用组件 | 多个 Widget 或页面复用的局部界面或交互。 | 否。 |
| 数据对象/内容资产 | Widget 消费的业务内容、素材或关联信息。 | 否。 |
| 外部应用 | 自身拥有独立业务和交互的外部系统。 | 否；如需在 C端使用，只定义 C端承载它的业务能力。 |

“有独立 URL”“可嵌入”“有按钮”均不能单独作为 Widget 的判断依据。

## 3. 单项 Widget PRD 固定结构

每个 Widget 必须单独建立一份 Markdown 产品需求文档，并按以下六部分定义。信息尚未确认时必须写“待产品确认”，不得以截图、旧页面或实现假设补齐。

### 3.1 基本信息

| 内容 | 定义要求 |
| --- | --- |
| Widget 名称 | 使用业务名称，不使用页面名称。 |
| Widget 唯一标识 | 全局唯一的业务标识；不使用历史编号代替，不规定技术实现格式。 |
| 分类 | 从统一 Widget 分类中选择，仅用于理解和检索，不决定功能。 |
| 一句话简介 | 用一句自然语言说明该 Widget 帮助顾客完成什么。 |
| 封面图 | 用于 A/B端识别 Widget 类型；必须与具体项目无关。 |
| 设计图 | 仅在复杂能力需要辅助理解时提供；可以使用示例数据，但必须明确标注“设计示意”，不得作为项目真实内容。 |

历史编号如有需要，仅保留在开发清单或归档映射中，不作为单项 Widget PRD 的标准字段。

### 3.2 目标与边界

| 内容 | 要回答的问题 |
| --- | --- |
| 目标顾客 | 谁会使用该 Widget，处于什么业务或购房阶段。 |
| 需求目的 | 顾客为什么需要这项能力，需要解决什么业务问题。 |
| 适用场景 | 在哪些项目内容或顾客任务中适用。 |
| 用户任务与完成状态 | 顾客在其中完成什么操作；完成后获得什么信息、判断、选择或提交反馈。 |

未在需求中定义的能力默认不做；不设置固定的“不做清单”章节。必要限制应写在对应的数据、权限或交互规则中。

### 3.3 内容与数据

| 内容 | 要回答的问题 |
| --- | --- |
| 展示内容 | 顾客能看到哪些业务内容、对象和关联入口。 |
| 内容来源 | 内容属于哪些业务对象、项目内容或外部内容。 |
| 可配置内容对象与组合规则 | 如需读取或选择项目内容，明确可使用的业务对象、必选性、选择数量和组合方式；由开发随 Widget 能力定义提供，A/B 不得自行扩大。 |
| 内容选择方式 | 内容由当前项目自动带入、由配置人员选择，还是由顾客输入条件后产生。 |
| 必需与可选内容 | 缺少哪些内容时能力无法成立；哪些内容缺失时仍可继续展示。 |
| 内容可见与有效条件 | 内容是否必须已发布、与当前项目关联、允许展示或满足特定顾客条件。 |

本部分只定义业务内容及其使用条件，不写接口、数据库字段或技术数据结构。页面是否允许顾客访问、是否要求登录，由页面和权限规则定义；Widget 只说明哪些内容可被自身使用。A端只读取当前项目中符合该 Widget 能力定义的候选内容，不维护全局来源分类或素材类型字典。

#### 顾客可见内容白名单规则

1. Widget 可见内容必须在单项 PRD 中具有明确的内容名称、来源、必需性或显示条件；没有定义的字段、标题、说明、标签、事实、卖点和入口一律不展示。
2. 调用通用组件只获得该组件的呈现与交互能力，不自动获得“摘要、标签、元信息、提示文案”等内容字段。Widget 需要使用这些槽位时，仍须在自身 PRD 中逐项定义来源。
3. 页面标题、栏目标题和操作文案仅在单项 PRD 或正式共享规则明确时显示。设计稿、原型和 AI 不得增加营销口号、英文副标题、章节编号、实现说明、评审说明或技术词作为顾客内容。
4. 可选内容缺失或无效时隐藏该内容及其标签、分隔符和留白；不得使用 AI 生成、演示文案、其他项目内容、旧页面内容或跨语言内容补齐。
5. 原型允许使用代表值验证已定义字段和状态，但代表值必须与字段一一对应，不得反向成为新增需求或项目事实。

### 3.4 使用与配置

| 内容 | 要回答的问题 |
| --- | --- |
| 是否需要配置 | 使用该 Widget 时是否需要人工选择内容或设置；还是自动带入项目数据。 |
| 内容配置 | 可选择哪些内容、单选还是多选、是否允许排序。 |
| 多来源组合 | 多项来源是否必须同时选择，或满足哪一种明确组合即可成立。 |
| 展示/行为配置 | 哪些顾客侧表现允许调整，例如展示模式或默认内容；不写视觉像素参数。 |
| 固定规则 | 哪些行为不允许人工修改，例如自动计算、自动生成或固定的业务判断。 |
| 默认与无效配置处理 | 未配置、配置不完整、选择失效内容或配置非法时，如何处理。 |

本部分不定义配置页面的界面、字段存储方式或页面引用关系。

### 3.5 C端 UI 与交互

| 内容 | 要回答的问题 |
| --- | --- |
| UI 内容结构 | 顾客依次看到哪些信息；哪些是主内容、辅助内容和操作区。 |
| 默认展示 | 第一次打开时默认显示什么内容、选中状态或初始结果。 |
| 核心交互 | 顾客能执行哪些主要操作。 |
| 交互结果 | 每个主要操作后，内容、选中状态、提示或下一步如何变化。 |
| 状态与降级 | 无内容、可选内容缺失、加载、失败、无权限或外部不可用时，顾客看到什么、能否重试或退出。 |
| 响应式与设计系统 | 手机与桌面在内容顺序、控件位置、操作方式上的差异；使用哪些 VISTA C 组件，缺失时标记“待设计系统补充”。 |

本部分定义顾客可见的体验结果，不写视觉像素、程序错误、网络协议、日志或具体实现方案。

### 3.6 验收与待确认

| 内容 | 要回答的问题 |
| --- | --- |
| 核心用户用例 | 顾客在何种条件下使用，完成哪些关键动作，最终获得什么结果或进入什么下一步。 |
| 验收标准 | 如何判断需求已实现，覆盖关键业务结果、配置结果、交互结果、内容缺失与失败结果。 |
| 待确认事项 | 仅记录会影响功能范围、内容、配置、权限、交互或验收的未决问题；没有则不写“无”。 |

## 4. 质量要求

每份 Widget PRD 应同时满足以下要求：

1. 能清楚说明为什么它是 Widget，而不是页面、通用组件、数据对象或外部应用。
2. 能说明顾客目标、内容来源、配置规则和 C端体验，且章节之间不相互矛盾。
3. 未定义的能力和顾客可见内容不得被自动补充；已确认、建议、待确认和历史线索必须明确区分。
4. 不复制页面关系、A/B端管理字段、技术实现或其他 Widget 的详细规则。
5. 在不补充业务假设的前提下，足以生成覆盖已定义内容、配置、主要交互与状态的 C端原型。