数据字段怎么写
数据字段是产品需求的底层骨架。无论你在做一个电商后台、一个 AI 写作工具，还是一个 SaaS 管理平台，最终所有功能都会落到一张表上：哪个字段、什么类型、能不能为空、默认值是什么、跟其他字段什么关系。把这些写清楚了，开发才能动手，测试才有标准，验收才有依据。
很多产品经理在写 PRD 时，功能描述、交互流程、页面原型都画得很细，但一到数据字段部分就含糊带过，甚至只写「这里需要展示用户信息」这样一句话。结果开发阶段频繁返工——每个人对「用户信息」的理解不一样，做出来的东西自然也不一样。
这篇文章面向零基础读者，从数据模型的基本概念讲起，一步步带你掌握字段定义的标准格式、关系类型、数据字典模板，以及如何在需求文档里把数据字段写清楚。
为什么小白也要懂数据字段
你可能觉得数据字段是开发的事，产品经理只要画好原型就够了。但实际工作中，你会遇到这些场景：
- 和开发对齐需求时，开发问你「这个字段是单选还是多选？最大长度多少？允不允许为空？」你答不上来，需求就卡住了。
- 评审 PRD 时，开发拿着你的文档说「这里写了要展示用户信息，但具体哪些字段没写」，你临时想不全面，评审效率大打折扣。
- 做数据后台时，运营说「我需要看用户的付费状态」，你需要把这个需求翻译成「订单表里的 status 字段 + 用户表里的 paid_at 字段」，如果你不懂字段，就没法和数据团队沟通。
- 设计 AI 产品时，你需要定义 Prompt 的输入输出结构、定义 AI 生成的内容要存哪些字段、定义审核状态怎么流转——这些全是数据字段。
懂数据字段不需要你会写 SQL，也不需要你会建数据库表。你需要的是：知道有哪些概念、知道怎么描述一个字段、知道字段之间是什么关系。有了这些基础，你就能在需求文档里写出开发能直接用的数据规格，沟通效率会有质的提升。
数据模型基础概念
在写数据字段之前，先理解三个基础概念：实体（Entity）、属性（Attribute）和关系（Relationship）。
实体（Entity）
实体就是你要描述的「东西」。在 AI 产品出海场景中，常见的实体有：
- 用户（User）：注册和使用产品的人
- 剧本（Script）：用户创建的漫画剧本
- 分镜（Storyboard）：剧本中的每一页分镜
- 订单（Order）：用户付费订阅或购买的记录
- 角色（Character）：剧本中出现的漫画角色
实体不是数据库表，你可以把它理解为「一类事物的抽象」。当你在需求文档里写「我们需要支持用户上传头像」时，「用户」就是一个实体，「头像」是这个实体的一个属性。
属性（Attribute）
属性是实体身上需要记录的「信息项」。以「用户」实体为例：
- 用户名（username）
- 邮箱（email）
- 头像地址（avatar_url）
- 注册时间（created_at）
- 订阅状态（subscription_status）
每个属性最终会落地为一个数据字段。在需求文档中，你不需要用「属性」这个词，直接说「字段」就好，开发会理解你的意思。
三层数据模型
数据模型有三个层次，产品经理主要关注第一层就够了：
| 层次 | 关注什么 | 谁用 | 你需要懂多少 |
|---|---|---|---|
| 概念模型（Conceptual） | 有哪些实体、实体之间什么关系 | 产品经理、业务方 | 必须掌握 |
| 逻辑模型（Logical） | 字段名、类型、主外键 | 产品经理 + 开发 | 了解字段定义格式即可 |
| 物理模型（Physical） | 索引、分区、存储引擎 | 开发、DBA | 知道概念就行 |
概念模型回答「有什么」，逻辑模型回答「怎么定义」，物理模型回答「怎么实现」。你写需求文档时，写到逻辑模型这一层就够了——定义清楚字段名、类型、约束，开发就能建表。
字段定义的标准格式
一个字段在需求文档中至少要包含以下信息：
| 信息项 | 说明 | 示例 |
|---|---|---|
| 字段名 | 字段的英文标识，用 snake_case 格式 | subscription_status |
| 显示名称 | 界面上展示给用户的名称 | 订阅状态 |
| 数据类型 | 字段存储的数据种类 | 枚举（enum） |
| 是否必填 | 创建或更新时是否必须提供 | 是 |
| 默认值 | 未提供时的默认取值 | free |
| 取值范围 | 可选值的枚举列表或数值区间 | free / starter / pro / enterprise |
| 业务说明 | 这个字段在业务上是什么意思、怎么使用 | 用户当前的订阅等级，影响功能权限 |
补充几点容易忽略的细节：
字段命名用英文 snake_case（小写字母加下划线），不要用中文。字段名是给开发看的标识符，中文只在「显示名称」里用。如果团队习惯用 camelCase 也可以，但要统一。
数据类型不需要你写得很专业，用开发能理解的常见类型就好。下面是产品经理常用的数据类型对照：
| 数据类型 | 适用场景 | 示例 |
|---|---|---|
| 字符串（string） | 名称、标题、描述等文本内容 | 剧本标题：我的第一本漫画 |
| 整数（integer） | 计数、序号、ID | 分镜页码：1、2、3 |
| 浮点数（decimal） | 金额、比例等需要小数的数值 | 订单金额：9.99 |
| 布尔值（boolean） | 是/否、开/关两种状态 | 是否公开：true / false |
| 枚举（enum） | 固定选项列表，比如状态、类型 | 订阅状态：free / pro |
| 日期（date） | 只需要日期，不需要时间 | 注册日期：2026-07-01 |
| 时间戳（datetime） | 需要精确到具体时间的场景 | 最后登录：2026-07-01 14:30:00 |
| 文本（text） | 长文本，比如正文、备注 | 剧本内容：可能上千字 |
| JSON | 结构不固定的灵活数据 | AI 生成参数：{ "style": "manga", "ratio": "16:9" } |
是否必填和默认值要一起看。如果一个字段是必填的，那默认值就没有意义。如果一个字段不是必填的，那就要写清楚不提供时的行为——是用默认值，还是留空（null）。
取值范围在枚举类型时特别重要。不要只写「状态」两个字就结束，要把所有可能的状态值列出来。如果有些状态你还没想清楚，至少写上当前已知的，并标注「后续可能扩展」。
字段之间的关系
现实世界中的事物不是孤立的，数据字段之间也是。理解字段关系，能帮你把需求写得更完整。
一对一（One-to-One）
一个实体对应另一个实体的唯一一条记录。比如：
- 一个用户对应一个订阅记录
- 一个剧本对应一个封面图片
在需求文档中，你不需要画 ER 图，只要写清楚「用户表和订阅表通过 user_id 关联，一个用户只能有一条活跃的订阅记录」就行。
一对多（One-to-Many）
这是最常见的关系。一个实体可以有多条关联记录。比如：
- 一个用户可以创建多个剧本
- 一个剧本可以包含多个分镜
- 一个分镜可以有多条 AI 生成的图片
写需求文档时，要说清楚「多」的那一端最多能有多少条。一个用户可以创建「无限个」剧本？还是最多 100 个？这个限制直接影响产品设计和技术实现。
多对多（Many-to-Many）
双方都可以有多个对应关系。比如：
- 一个剧本可以有多个角色，一个角色也可以出现在多个剧本中
- 一个用户可以有多个标签，一个标签下也可以有多个用户
多对多关系通常需要一个中间表来管理。你在需求文档中只需要描述业务语义：「一个角色可以属于多个剧本，一个剧本也可以包含多个角色」，开发会知道需要建中间表。
关系类型对照
| 关系类型 | 业务含义 | 需求文档中的写法 | 典型例子 |
|---|---|---|---|
| 一对一 | A 对应唯一的 B | 用 user_id 关联，一条记录只能对应一条 | 用户 ↔ 订阅 |
| 一对多 | A 对应多个 B | A 的列表页展示 B，需要说明数量限制 | 用户 → 剧本 |
| 多对多 | A 和 B 互相多对多 | 需要中间关系表，说明关联属性 | 剧本 ↔ 角色 |
| 自引用 | A 关联自身 | 父子关系、树形结构 | 分类 → 子分类 |
数据字典模板
数据字典（Data Dictionary）是对所有字段的集中描述。它是需求文档的组成部分，也可以单独维护为一个文档。
下面是一个可以直接套用的模板，以「剧本（Script）」实体为例：
实体名称：script（剧本）
说明：用户创建的漫画剧本，是平台的核心创作单元。
| 字段名 | 显示名称 | 数据类型 | 必填 | 默认值 | 取值范围 | 业务说明 |
|---|---|---|---|---|---|---|
id | 剧本 ID | string (UUID) | 是 | 自动生成 | — | 全局唯一标识 |
user_id | 创建者 ID | string (UUID) | 是 | — | — | 关联用户表 |
title | 剧本标题 | string | 是 | — | 1-200 字符 | 展示在列表和详情页 |
description | 剧本简介 | text | 否 | null | 最多 2000 字符 | 展示在详情页和分享页 |
status | 剧本状态 | enum | 是 | draft | draft / published / archived | 控制是否对外可见 |
genre | 题材类型 | enum | 否 | null | romance / action / fantasy / scifi / comedy / horror | 用于分类和推荐 |
cover_url | 封面图片地址 | string (URL) | 否 | null | — | 列表页缩略图 |
page_count | 分镜总页数 | integer | 是 | 0 | 0-500 | 创建时为空，添加分镜后自动更新 |
is_public | 是否公开 | boolean | 是 | false | true / false | false 时仅创建者可见 |
ai_model | AI 生成模型 | string | 否 | null | — | 记录使用的 AI 模型，用于溯源 |
created_at | 创建时间 | datetime | 是 | 当前时间 | — | 按创建时间排序 |
updated_at | 更新时间 | datetime | 是 | 当前时间 | — | 每次修改自动更新 |
这个模板可以直接放进 Notion、飞书文档或者 Confluence 中维护。建议每个核心实体一个表格，在 PRD 中通过链接引用，避免信息散落。
实战案例
案例一：AI 漫画角色的数据字段设计
假设你正在做一个 AI 漫画平台，需要设计「漫画角色（Character）」的字段。
先想清楚业务问题：
- 角色需要哪些基本信息？名字、描述、头像
- 角色由谁创建？需要关联用户
- 角色属于哪个剧本？一个角色可以出现在多个剧本中
- 角色的外观怎么描述？需要给 AI 用的提示词
- 角色有版本概念吗？需要记录 AI 生成的历史版本吗？
基于这些问题，字段定义如下：
| 字段名 | 显示名称 | 数据类型 | 必填 | 默认值 | 取值范围 | 业务说明 |
|---|---|---|---|---|---|---|
id | 角色 ID | string (UUID) | 是 | 自动生成 | — | 全局唯一 |
user_id | 创建者 ID | string (UUID) | 是 | — | — | 关联用户表 |
name | 角色名称 | string | 是 | — | 1-50 字符 | 在分镜中引用时的显示名 |
description | 角色描述 | text | 否 | null | 最多 1000 字符 | 角色的背景故事和性格 |
visual_prompt | 外观提示词 | text | 是 | — | 1-500 字符 | 传给 AI 图像生成的提示词 |
avatar_url | 角色头像 | string (URL) | 否 | null | — | 角色的默认头像 |
status | 角色状态 | enum | 是 | active | active / archived | 归档后不可在分镜中引用 |
created_at | 创建时间 | datetime | 是 | 当前时间 | — | — |
updated_at | 更新时间 | datetime | 是 | 当前时间 | — | — |
注意 visual_prompt 字段。这是一个 AI 产品特有的字段类型——它不是简单的描述文本，而是有特定格式要求的提示词。在业务说明中需要补充格式规范，比如「使用英文，包含外貌、服装、风格关键词，用逗号分隔」。
角色和剧本是多对多关系，需要一张中间表 script_characters：
| 字段名 | 显示名称 | 数据类型 | 必填 | 默认值 | 取值范围 | 业务说明 |
|---|---|---|---|---|---|---|
id | 关联 ID | string (UUID) | 是 | 自动生成 | — | — |
script_id | 剧本 ID | string (UUID) | 是 | — | — | 关联剧本表 |
character_id | 角色 ID | string (UUID) | 是 | — | — | 关联角色表 |
role_type | 角色类型 | enum | 是 | supporting | main / supporting / cameo | 在剧本中的戏份 |
created_at | 关联时间 | datetime | 是 | 当前时间 | — | — |
案例二：出海订阅付费的数据字段设计
AI 产品出海几乎绕不开订阅付费。假设你的产品有四种订阅等级：免费版、入门版、专业版、企业版，需要设计订单表的字段。
业务问题：
- 订单关联谁？用户
- 订单金额怎么存？用小数还是整数？（涉及不同币种）
- 支付方式有哪些？Stripe、PayPal？
- 订单状态怎么流转？待支付 → 已支付 → 已取消？
- 退款怎么处理？需要单独记录吗？
字段定义：
| 字段名 | 显示名称 | 数据类型 | 必填 | 默认值 | 取值范围 | 业务说明 |
|---|---|---|---|---|---|---|
id | 订单 ID | string (UUID) | 是 | 自动生成 | — | 全局唯一，对客展示用短 ID |
user_id | 用户 ID | string (UUID) | 是 | — | — | 关联用户表 |
plan | 订阅方案 | enum | 是 | — | free / starter / pro / enterprise | 购买的方案等级 |
amount | 订单金额（分） | integer | 是 | — | > 0 | 以最小货币单位存储，避免浮点精度问题 |
currency | 币种 | enum | 是 | USD | USD / EUR / GBP / JPY | 出海多币种支持 |
payment_method | 支付方式 | enum | 是 | — | stripe / paypal / apple_pay | 记录支付渠道 |
payment_id | 第三方支付流水号 | string | 否 | null | — | Stripe 或 PayPal 返回的交易 ID |
status | 订单状态 | enum | 是 | pending | pending / paid / failed / cancelled / refunded | 状态流转见流程图 |
paid_at | 支付成功时间 | datetime | 否 | null | — | 仅在 status 为 paid 时有值 |
expires_at | 到期时间 | datetime | 是 | — | — | 订阅过期时间 |
auto_renew | 是否自动续费 | boolean | 是 | true | true / false | 用户可随时关闭 |
created_at | 创建时间 | datetime | 是 | 当前时间 | — | — |
注意 amount 字段。金额不要存 9.99 这样的浮点数，而是存 999（以分为单位）。这是支付领域的通用做法，可以避免浮点数精度导致的对账错误。
数据字段设计流程
下面用 Mermaid 流程图展示从需求到字段定义的完整过程：
关键节点说明：
- 明确业务场景：不要上来就写字段，先搞清楚这个模块要解决什么业务问题。
- 识别核心实体：从业务流程中提取关键对象——用户、订单、内容、配置等。
- 列出属性：针对每个实体，问自己「这个对象需要记录哪些信息？」
- 确定类型和约束：每个属性用什么类型存储、是否必填、默认值是什么。
- 梳理关系：实体之间怎么关联，一对一、一对多还是多对多。
- 编写数据字典：把以上内容整理成表格。
- 与开发评审：这一步不能省，开发会帮你发现遗漏和不合理的地方。
数据字段检查清单
写完数据字段后，用以下清单逐项检查：
- 每个字段都有明确的字段名（英文 snake_case）和显示名称（中文）
- 每个字段都标注了数据类型，且类型选择合理
- 枚举类型字段列出了所有可能的取值，不留「其他」这种模糊选项
- 每个字段都标注了是否必填（Required / Optional）
- 非必填字段标注了默认值或明确说明「允许为空（null）」
- 字符串类字段标注了最大长度限制
- 金额类字段使用整数存储（最小货币单位），避免浮点数
- 时间类字段统一使用 UTC 时间戳，避免时区问题
- 实体之间的关系已梳理清楚，一对一、一对多、多对多都标注了
- 关联字段（如 user_id、script_id）标注了关联的目标表
- 字段命名风格统一（snake_case 或 camelCase，不要混用）
- 敏感字段（密码、token 等）标注了加密要求，且不出现在数据字典中
- 数据字典已与开发团队评审确认
- 字段定义覆盖了 CRUD 全场景——创建时哪些必填、更新时哪些可改、删除时的级联规则
常见错误与避坑
错误一：只写「状态」，不写取值范围
不要写 status: 状态 就结束了。必须写明 status: draft / published / archived。不写取值范围，开发只能自己猜，猜出来的结果大概率和你想要的不一样。
错误二：字段命名不统一
同一个概念在不同表里叫不同名字——用户表叫 created_time，订单表叫 create_at，剧本表叫 gmt_created。统一命名是团队协作的基础，建议在项目规范文档里定义好命名约定。
错误三：忽略字段级联关系
用户被删除了，他创建的剧本怎么办？分镜怎么办？订单怎么办？字段定义时要考虑级联规则——是级联删除、置空还是软删除。这个问题不在字段表里写，也要在业务规则里写。
错误四：出海产品忽略多语言和时区
做多语言产品时，展示类字段（标题、描述）需要考虑多语言支持。是存一份内容用多语言字段，还是每个语言存一份？时区问题更常见——用户在不同时区看到的「今天」不是同一天，时间展示要统一用 UTC 存储、前端转换。
参考资料
- 数据产品经理基础技能：数据需求说明文档怎么写？ — 人人都是产品经理，系统讲解数据需求文档的结构和写法
- 怎样写好 B 端产品需求文档 — 知乎专栏，B 端需求文档中字段定义的规范说明
- Data Dictionary: Components, Examples, Implementation — Atlan，数据字典的组成要素和实际案例
- Data Dictionary Examples & Templates — OvalEdge，数据字典模板和最佳实践
- How to Data Model Without Getting Too Technical — Bridging the Gap，面向非技术人员的数据建模指南
- Data Modeling Dos and Don'ts — XTIVIA，数据建模的常见误区和正确做法
- What is a PRD? - Agile - Atlassian — Atlassian，PRD 编写指南，数据需求在其中的定位
- 软件开发需求文档怎么写 — 红山科技，需求文档中数据字段的规范写法