第4章 用户需求编码：逐条标注需求类型、频次、情感倾向、优先级初判

适用场景

• 已完成用户访谈数据清洗与原始需求提取，获得无序的原始需求条目列表。
• 需要将定性访谈内容转化为结构化编码数据，支撑后续量化分析与版本排期。
• 团队中产品经理、业务分析师或需求工程师进行协作编码时使用。

前置条件

• 已产出《需求原始条目清单》（第3章输出物），每一条包含需求描述、提及用户角色、访谈来源。
• 已确定编码维度及规范：需求类型、频次、情感倾向、优先级初判。
• 编码工具（Excel / Airtable / 专用需求管理平台）已就绪，或准备好统一编码模板。

操作步骤

1. 逐条读取需求条目：按清单顺序，每次只处理一条需求，避免跳读或混读。
2. 标注需求类型：根据内容判断归属类型（功能需求 / 非功能需求 / 体验需求 / 运营需求），填入对应类别字段。
3. 统计提及频次：在该条需求的访谈记录中统计被不同用户提及的次数（若为群体访谈，按“不同用户分组”计数），填入数值。
4. 标注情感倾向：分析用户表述时的语气、用词与上下文，判定为“积极”、“中性”或“消极”。
5. 初判优先级：结合类型、频次、情感倾向以及业务目标，给出初步优先级（P0 ~ P3），并记录理由。
6. 交叉复核：每完成10条，由另一位编码者抽检2条，确保编码一致性≥90%，否则需讨论对齐标准。

输入输出物

责任边界

记录材料

推荐使用以下JSON结构存储每条编码结果，便于后续数据处理：

{
  "reqId": "REQ-004",
  "description": "微信支付集成",
  "type": "功能需求",
  "frequency": 8,
  "sentiment": "积极",
  "priority": "P0",
  "priorityReason": "支付基础能力，频次高，用户强烈要求"
}

异常处理

• 需求描述模糊：回听访谈录音或回访用户，确认意图后编码；仍无法确定的，标记为“待确认”，单独列出发起澄清。
• 情感倾向无法判断：默认为“中性”，并在备注说明。
• 频次统计跨场景重复：同一用户在不同场景下提及同一需求，只计1次；不同用户即使表述相同也应累计。
• 编码争议：由产品经理仲裁，仲裁纪要写入编码批注。

验收标准

1. 所有原始需求条目的编码覆盖率达到100%。
2. 交叉复核一致率 ≥ 90%（争议条目不超过10%）。
3. 每条需求的优先级初判均附有可追溯的理由（text字段或备注）。
4. 编码表格式与输出物定义一致，无字段遗漏。