AI需求分类体系的设计，核心是两个相互制约的决策：类别层级要分几层，标签要切多细。层级过深会让录入和维护成本上升，标签过细会让不同人打出不同结果。本文按“用途倒推层数、按可判定可行动定标签、用统一口径保证一致性、用固定流程维护体系”的顺序，给出判断依据、操作步骤和配套产物，适用于正在用AI辅助整理需求的研发团队。
要点总览（TL;DR）
- 层级深度按分类结果的下游用途倒推：只用于检索和统计时两层通常够用；需要支撑评审分工、版本规划和跨团队交接时用三层；第四层一般交给标签承担。
- 标签粒度以“可稳定判定、可对应动作”为标准，每个标签要有名称、定义、正例、反例、所属维度和维护人，并按使用频率与判定一致性定期清理。
- 类别重叠时采用主类唯一加辅助标签的方式，主类决定评审和排期路径，辅助标签记录其他属性，组合规则写进口径文档。
- 边界模糊的条目进入待定池，由固定角色按约定周期裁决，裁决结论回写为口径文档的正反例；新增类别走申请、试运行、转正或撤销的流程。
- 验收时重点看三件事：抽样无法归类的比例、两名执行者独立分类的主类一致率、待定池是否清空或有明确处理计划。
先定层级深度：从需求用途倒推层数
层级深度由分类结果的下游用途决定。分类体系服务于检索、统计、评审分工还是跨团队交接，直接决定需要几层。追求“一次分到位”的完整体系，往往在运行三个月后因为无人维护而失真。
判断层数可以按以下步骤操作：
- 列出分类结果的下游用途，例如需求检索、数量统计、评审排期、版本规划、跨团队交接、合规归档。
- 识别每个用途中需要区分的决策点。例如“评审排期”需要知道需求属于哪个业务域、由哪类角色评审；“版本规划”需要知道需求类型和功能对象。
- 把决策点映射到层数：一个决策点对应一层，同一层内回答同一个问题。
- 检查是否有决策点无法用三层表达，若有，优先考虑用标签承担，而非增加第四层。
两层、三层、四层的典型适用条件与代价如下：
| 层数 | 典型适用条件 | 主要代价 |
|---|---|---|
| 两层 | 分类结果主要用于检索和数量统计，团队规模小，需求流转路径单一 | 难以支撑精细的评审分工和版本规划，跨团队交接时信息不足 |
| 三层 | 需要支撑评审分工、版本规划和跨团队交接，需求来源和类型较多样 | 录入和维护成本上升，需要明确的判定口径和责任人 |
| 四层 | 需求量大且存在稳定的细分场景，前三层无法区分关键决策点 | 层级记忆负担重，判定一致性难以保证，通常可用标签替代 |
每层应回答一个明确的问题。常见安排是：第一层回答“属于哪个业务域”，第二层回答“属于哪类需求”，第三层回答“涉及哪个功能对象或模块”。层数确定后，输出一份层级结构表，作为后续标签设计和判定口径的基础。
| 层号 | 每层名称 | 回答的问题 | 适用条件 | 维护责任人 |
|---|---|---|---|---|
| L1 | 业务域 | 需求服务于哪块业务 | 所有体系必备 | 产品负责人 |
| L2 | 需求类型 | 是新增、优化、缺陷修复还是合规调整 | 需要区分处理路径时 | 需求管理负责人 |
| L3 | 功能对象 | 涉及哪个模块或功能点 | 需要支撑评审分工和版本规划时 | 各模块负责人 |
标签粒度怎么切：定义、判定与数量控制
标签粒度的标准是“可稳定判定、可对应动作”。一个标签如果两个人看同一条需求会给出不同判断，说明粒度过细或定义不清；如果一个标签打上之后没有任何后续动作，说明它没有存在必要。
每个标签应包含以下字段，形成可维护的标签字典：
| 字段 | 填写要求 |
|---|---|
| 标签名 | 简短、无歧义，避免使用内部缩写 |
| 定义 | 一句话说明什么情况下打这个标签 |
| 正例 | 一条典型需求描述，说明应打此标签 |
| 反例 | 一条容易误判的需求描述，说明不应打此标签 |
| 所属维度 | 来源、优先级、变更影响、合规相关等 |
| 维护人 | 对该标签定义负责的角色 |
| 状态 | 试运行、正式、停用 |
标签维度与类别层级承担不同职责。层级回答“这是什么”，维度回答“它还有什么属性”。例如“来源”维度下的“客户反馈”“内部提出”“监管要求”，与类别层级中的“需求类型”不重复，前者描述提出方，后者描述变更性质。维度划分应控制在四到六个，每个维度下的标签数量按实际使用频率控制。
标签数量需要定期清理。可按两个指标判断：使用频率，即近一个季度被打上的次数；判定一致性，即抽检时不同人给出相同标签的比例。使用频率低且一致性差的标签，优先合并或停用。粒度过细的典型表现是标签名之间差异需要靠解释才能说清，调整方向是合并为上位标签并在定义中说明细分场景；粒度过粗的典型表现是一个标签覆盖了处理方式完全不同的需求，调整方向是拆分为两个可独立判定的标签。
判定口径：让不同人打出同一个类别
判定口径的作用是让分类执行者、AI分类结果和人工复核之间保持一致。口径文档应包含四部分内容：优先判定顺序、主类唯一原则、辅助标签使用规则、待定池流程。
优先判定顺序解决“一条需求同时符合多个类别”的问题。例如先判断是否属于合规相关需求，再判断业务域，最后判断需求类型。顺序一旦确定，所有执行者按同一顺序判定。
类别重叠时采用主类唯一加辅助标签的方式。每条需求只能有一个主类，主类决定它进入哪条评审和排期路径；其他相关类别以辅助标签形式记录，并在口径文档中写明组合规则，例如“主类为支付域、辅助标签为合规相关时，评审需增加合规角色”。
边界模糊的条目进入待定池，由固定角色定期裁决。待定池需要明确三件事：谁裁决、多久裁决一次、裁决结果如何回写。常见做法是每周由需求管理负责人裁决一次，裁决结论同步更新到口径文档的正反例中，避免同类问题反复出现。
AI辅助分类时，把类别定义和正反例作为分类输入，让AI按同一口径给出建议类别和置信说明，再由人工抽检校正。抽检比例可按需求量和一致性水平调整，初期可全量复核，稳定后降低比例。判定口径文档需要版本记录，每次修改注明变更内容、生效时间和影响范围。
新增、合并与退役类别：体系的持续维护
类别体系需要固定的变更流程，否则会出现两类问题：类别无限膨胀，或者业务变化后类别长期失真。
新增类别的触发条件是现有类别无法覆盖的需求反复出现。申请材料应包括：近一个季度内无法归类的需求数量、这些需求的共同特征、现有类别为何无法覆盖的说明。新增类别先进入试运行，观察期内检查判定一致性，一致性达到约定水平后转正，未达到则撤销或调整定义。
类别合并的判断依据是两个类别的需求在处理路径上已无实质差异，或判定时经常互相误判。类别退役的判断依据是该类别近两个季度使用频率持续下降，且其覆盖的需求可归入其他类别。合并和退役都需要处理历史数据迁移，明确旧类别下的需求如何映射到新类别，并保留映射记录以便追溯。
变更记录与通知机制保证使用方同步。每次变更应记录变更类型、生效时间、影响范围和迁移方式，并通过固定渠道通知分类执行者和使用方。定期复审建议每季度一次，检查项包括：各类别使用频率、判定一致性抽检结果、待定池积压情况、是否有长期未使用的类别。
角色分工与各阶段交付物
分类体系的运行涉及四类角色，职责和产出需要提前明确。
| 角色 | 职责 | 主要交付物 |
|---|---|---|
| 体系设计者 | 确定层级结构、标签维度和判定口径，组织变更评审 | 层级结构表、标签字典、判定口径说明 |
| 分类执行者 | 按口径为需求打主类和标签，提交边界模糊条目 | 已分类需求记录、待定条目 |
| 裁决者 | 裁决待定池条目，维护口径文档的正反例 | 裁决记录、口径文档更新 |
| 使用方 | 按分类结果进行检索、统计、评审排期和版本规划，反馈类别不适用的情况 | 使用反馈、新增类别申请 |
各角色在层级设计、标签维护、待定裁决和变更评审中的动作需要形成交接闭环。例如分类执行者提交待定条目后，裁决者在约定时限内给出结论，结论回写到口径文档，再由体系设计者在下次复审时检查是否需要调整类别。交付物通过共享文档或需求管理工具中的字段和状态承载，保证使用方随时可查。
小团队可以合并角色。例如体系设计者兼任裁决者，分类执行者由需求提出人兼任。合并后仍需保留待定池和变更记录，避免口径随个人判断漂移。
分类结果最终要落到需求工作项的字段和状态上，才能被检索、统计和评审流程使用。ONES 的需求工作项和字段配置可以承载主类、标签和状态；ONES Assistant 能理解项目、工作项和迭代等上下文，围绕需求澄清提炼待澄清问题与拆解建议，并基于 ONES 权限体系执行任务，输出过程可追踪。把类别定义和正反例作为输入交给 AI 给出分类建议、再由人工抽检，是与上述口径配套的用法。
一个示例：三层类别加四维标签的落地写法
以下示例设定为一个通用研发团队场景：需求来源包括客户反馈、内部提出和监管要求，需求需要支撑评审分工和版本规划。示例仅用于说明写法，不代表特定企业事实。
三层类别示例如下：
| 层号 | 类别 | 定义 |
|---|---|---|
| L1 | 交易域 | 涉及下单、支付、退款等交易流程的需求 |
| L2 | 优化 | 不改变核心流程、以提升体验或效率为目标的需求 |
| L3 | 支付结果页 | 涉及支付完成后结果展示与状态提示的功能点 |
标签维度可设为来源、优先级、变更影响、合规相关四个维度。代表性标签包括：来源维度下的“客户反馈”“监管要求”；变更影响维度下的“影响存量数据”“仅影响新流程”；合规相关维度下的“涉及个人信息”。每个标签按标签字典字段填写定义、正例、反例和维护人。
两条边界模糊需求按口径处理的过程如下：
- 需求A：客户反馈支付结果页加载慢，同时涉及个人信息展示调整。按优先判定顺序先判断合规相关，打上“涉及个人信息”辅助标签；主类判定为交易域—优化—支付结果页；评审时按组合规则增加合规角色。
- 需求B：监管要求调整退款状态提示文案，现有类别中“交易域—优化”与“交易域—新增”均可解释。该条目进入待定池，由裁决者按“是否改变核心流程”判定为优化，并将该案例补充为口径文档正例。
示例可迁移的规律是：层级回答稳定问题，标签回答变化属性，判定口径处理交叉情况。适用边界在于，需求来源单一、流转路径简单的团队可以缩减到两层，标签维度也可相应减少。
完成检查：体系是否可用的验收项
分类体系投入运行前，可按以下清单逐项核对。每项给出通过标准，未通过的项目需要明确整改责任人和时间。
| 检查项 | 通过标准 |
|---|---|
| 层级与标签覆盖 | 抽取近一个季度的需求样本，无法归类的比例低于约定阈值，通常设为5%以内 |
| 抽样判定一致性 | 两名执行者独立分类同一批样本，主类一致率达到约定水平，通常设为90%以上 |
| 待定池状态 | 待定池已清空，或每条待定条目有明确裁决人和处理时限 |
| 变更流程与责任人 | 新增、合并、退役流程已文档化，各角色责任人已确认 |
| 与需求管理工具对齐 | 层级和标签已落到需求工作项的字段与状态上，检索和统计可按字段执行 |
验收通过后，体系进入运行阶段，按季度复审使用频率、一致性和待定池情况。验收标准中的阈值应结合团队需求量调整，需求量小的团队可适当放宽一致性要求，但需保留抽检和裁决机制。
常见问题
团队需求来源单一、流转路径简单，能不能只用两层类别？
可以。两层适合分类结果主要用于检索和数量统计、团队规模小、需求流转路径单一的情况。此时需要接受一个代价：跨团队交接和精细评审分工时信息不足。如果后续出现评审排期或版本规划的需求，再评估是否增加第三层，并把新增层级的判定口径和责任人一并确定。
一条需求同时符合两个类别，应该怎么记？
按口径文档的优先判定顺序先判一次，确定唯一主类；其他相关类别以辅助标签记录。主类决定这条需求进入哪条评审和排期路径，辅助标签用于补充属性。组合规则要写清楚，例如主类为支付域、辅助标签为合规相关时，评审需增加合规角色。这样既避免一条需求挂两个主类，也保留了交叉信息。
AI给出的分类建议和人工判断不一致时，以谁为准？
以口径文档为准，不以某一方为准。做法是把类别定义和正反例作为分类输入交给AI，让它给出建议类别和置信说明，再由人工抽检校正。初期可以全量复核，一致性稳定后降低抽检比例。出现分歧的案例，如果口径文档没有覆盖，就补充为正例或反例，让下一次判断有依据。
新增类别试运行多久合适，什么情况下应该撤销？
观察期长度按需求出现频率定，常见做法是一个季度。观察期内检查两件事：新类别是否被稳定使用，以及不同执行者判定是否一致。如果使用频率持续偏低，或判定一致性达不到约定水平，就撤销该类别或调整定义后重新试运行。撤销时要把已归入该类别的需求映射回现有类别，并保留映射记录。
分类体系上线后，怎么和需求管理工具里的字段对应起来？
层级和标签最终要落到需求工作项的字段与状态上，检索和统计才能按字段执行。落地时逐项核对：每层类别是否对应一个字段或字段层级，标签是否作为独立字段或标签字段维护，待定状态是否有对应的工作流状态。ONES 的需求工作项和字段配置可以承载主类、标签和状态，ONES Assistant 能理解项目、工作项和迭代等上下文，围绕需求澄清提炼待澄清问题与拆解建议，并基于 ONES 权限体系执行任务，输出过程可追踪。具体字段配置方式与限制以产品实际使用为准。
