AI需求分类体系由三部分构成：类别层级、标签集合和判定口径。类别层级回答一条需求“放在哪”，标签集合回答它“还带什么信息”，判定口径回答“凭什么这样分”。三者配合，才能让不同人、不同批次以及AI给出的分类结果保持一致、可以复核。下面依次说明各部分的结构、设计要点和协作方式，并划清它与需求分析、文档成稿的边界。
要点总览（TL;DR）
- AI需求分类体系由类别层级、标签集合和判定口径三部分构成，分别回答需求放在哪、还带什么信息、凭什么这样分。
- 类别层级按业务域、需求类型、子类型组织，同级类别尽量互斥，层级深度以团队能稳定说清为准。
- 标签集合补充来源、优先级、涉及系统、变更影响等跨类别属性，需要控制维度数量并固定取值写法。
- 判定口径用判断依据、边界规则、冲突处理和正反例约束人和AI的分类行为，并做版本管理。
- 分类结果不一致时，先核对口径版本，再检查类别边界，最后判断是否需要补充示例或调整层级。
AI需求分类体系由哪三部分构成
把AI引入需求分类，常见的误区是只准备一份类别清单就交给模型。清单能解决“有哪些类”，却解决不了“这条需求为什么归到这一类”“同类需求之间还差什么信息”。完整的分类体系需要三个部分共同支撑。
| 组成部分 | 回答的问题 | 主要产出 |
|---|---|---|
| 类别层级 | 这条需求放在哪 | 业务域、需求类型、子类型组成的归属树 |
| 标签集合 | 它还带什么信息 | 来源、优先级、涉及系统、变更影响等属性维度 |
| 判定口径 | 凭什么这样分 | 判断依据、边界规则、冲突处理与示例 |
三者的关系可以理解为：类别层级确定归属，一条需求在树上有且只有一个位置；标签集合补充跨类别的属性，让需求在归属之外还能被检索和筛选；判定口径则把前两者的使用方式写成可执行的规则，约束人和AI做出同样的判断。缺少类别层级，需求无法归位；缺少标签集合，同类需求之间的差异被抹平；缺少判定口径，分类结果随执行者的理解漂移。
类别层级：把需求放到正确的位置
类别层级通常按三个层次组织：业务域、需求类型、子类型。业务域对应需求服务的业务范围，例如交易、会员、内容；需求类型区分需求的性质，例如新增功能、体验优化、合规调整；子类型在类型之下做更细的划分。层级的作用是让每条需求有唯一归属，便于按范围统计、分派和追踪。
层级深度需要与团队规模匹配。团队较小、需求来源单一时，两层往往够用；业务线多、需求量大时，三层可以帮助区分范围，但继续加深会让归类成本上升，也容易让执行者在相邻层级之间犹豫。一个实用的判断标准是：新增一层，是否能让某一类需求的负责人或处理流程明显不同。如果答案是否定的，这一层更适合用标签表达。
同级类别应尽量互斥。若“支付优化”和“交易体验”并列存在，同一条需求就可能有两个合理归属，分类结果随之不稳定。设计时可以检查每个同级类别是否有清晰的边界描述，并确认典型需求只落入其中一个。类别命名也有讲究：名称应指向业务对象或需求性质，避免使用“其他”“综合”“ miscellaneous”这类兜底词承担过多需求，否则层级会逐渐失去区分能力。颗粒度上，类别过粗会让大量需求挤在同一节点，过细则增加判断负担，通常以团队能稳定说清每个类别的含义为准。
标签集合：补充类别之外的属性信息
标签与类别的分工在于：类别是归属，标签是属性。一条需求只能属于一个类别节点，但可以同时带有多个标签。标签的价值在于跨类别检索与筛选，例如按来源区分需求来自用户反馈、内部提出还是合规要求，按优先级区分处理顺序，按涉及系统标记受影响的模块，按变更影响标记是否需要回归验证。
标签集合应覆盖哪些维度，可以从团队实际要回答的问题倒推。常见维度包括：
- 来源：用户反馈、销售反馈、内部规划、合规要求等；
- 优先级：用于排序和资源分配；
- 涉及系统或模块：用于评估影响范围和协作方；
- 变更影响：是否影响既有功能、数据或接口；
- 处理状态相关的辅助标记：如待澄清、待评审。
标签数量需要收敛。每个维度给出有限的取值，并明确单选还是多选，避免同一维度出现近义标签。可以定期统计标签使用情况，合并长期只被使用一两次的标签，删除无人使用的标签。标签滥用会让分类失效：当一条需求被打上十几个标签，筛选结果不再有区分度；当同一含义出现多个写法，检索会漏掉一部分需求。控制维度数量、固定取值写法，是保持标签可用的基本做法。
判定口径：让分类结果可复现
判定口径是把分类从个人经验变成团队规则的部分。它至少包含三类内容：判断依据，说明某类需求应满足什么特征；边界规则，说明两个相邻类别之间如何区分；冲突处理，说明一条需求同时符合多个类别或标签时按什么顺序取舍。
典型写法包括判定说明、正反例和优先级顺序。判定说明用一段话描述类别的适用条件；正反例各给一两条，帮助执行者校准颗粒度；优先级顺序用于处理歧义，例如当需求既涉及体验优化又涉及合规调整时，规定以合规类优先归类。对于由AI参与分类的场景，判定口径同时充当提示与校验依据：把类别定义、边界规则和示例提供给模型，再对输出结果按同一口径做检查，可以减少模型在相邻类别之间的随意选择。
口径需要版本管理。业务变化后类别含义可能调整，标签取值可能增删，判定规则也会修订。每次更新应记录变更内容、生效时间和影响范围，并保留旧版本以便回溯历史分类。没有版本记录，早期需求和新需求会按不同规则归类，统计结果难以比较。
三部分如何配合保证分类一致
一条需求进入分类流程后，三部分按固定顺序发挥作用。第一步，依据类别层级确定归属：先判断业务域，再判断需求类型，最后落到子类型。第二步，补充标签：按来源、优先级、涉及系统、变更影响等维度打标，标签不改变归属，只增加检索维度。第三步，用判定口径处理歧义：当归属在相邻类别之间摇摆，或标签取值存在多种理解时，按边界规则和优先级顺序做出选择。
流程中应设置复核与抽样检查。复核可以由需求负责人或分类维护者完成，重点检查新出现的需求形态是否被现有类别覆盖、标签是否按约定取值。抽样检查则定期从已分类需求中抽取样本，核对类别与标签是否符合判定口径。当发现分类结果不一致时，回溯路径是：先确认执行者使用的口径版本是否一致，再检查类别边界描述是否清晰，最后判断是否需要补充示例或调整层级。把问题定位到具体环节，比反复强调“分类要准确”更能改善结果。
分类结果最终要落到可管理的载体上。在ONES中，需求可以作为工作项承载，类别与标签对应到工作项的字段和标记，状态流转记录处理进展；ONES Assistant可理解项目、工作项、迭代和Wiki页面等工作上下文，并基于相关数据回答问题、执行后续操作，输出过程可追踪、结果可审计。这样，分类体系产出的归属和属性能够进入日常的需求管理流程，而不是停留在表格里。
具体例子：一条需求如何被分类
以下为演示情景。假设收到一条需求：“结算页增加发票信息填写入口，支持个人和企业抬头。”按类别层级，业务域归入“交易”，需求类型归入“新增功能”，子类型归入“结算流程”。按标签集合，来源标记为“用户反馈”，优先级标记为“中”，涉及系统标记为“结算页”和“发票服务”，变更影响标记为“影响既有结算流程”。判定依据是：该需求在结算页新增可操作入口，属于功能新增而非体验优化；涉及两个系统，需要在标签中同时体现，便于后续协作方识别。
这个例子对应几个常见误解。其一，把标签当类别：如果因为需求涉及“发票”就新建一个“发票”类别，类别树会随业务细节不断膨胀，而“发票”更适合作为涉及系统的标签。其二，层级过深：为一条需求临时增加第四层子类型，会让同类需求在后续归类时缺少参照。其三，口径只写在个人经验里：如果“新增入口”与“优化入口”的区分只存在于某位成员的理解中，换人或交给AI处理时就容易分错。
当AI给出错误分类时，纠正方式应回到判定口径：指出它违反了哪条边界规则，补充一个正例或反例，并确认该规则已写入当前版本的口径文档。若错误反复出现，说明类别定义或示例不足，需要修订口径，而不是逐条手工改结果。
与需求分析、文档成稿的边界
AI需求分类体系关注的是归类与检索：把需求放到正确位置、补充可筛选的属性、让判断过程可复现。需求分析与澄清关注的是需求内容本身，包括背景、目标、用户场景、验收条件和待澄清问题。两者相邻但职责不同：分类体系可以在需求进入分析之前提供结构，也可以在分析之后帮助归档，它不判断需求是否合理，也不替代需求评审。
AI文档成稿属于文档与报告生成范畴，处理的是把已有信息组织成PRD、会议纪要或报告。分类体系产出的类别和标签可以作为文档组织的线索，但文档的完整性、表达质量不在分类体系的范围内。明确这条边界，可以避免把分类规则写成写作规范，也可以避免用文档模板代替分类口径。分类体系是整理需求的前置结构，评审、澄清和成稿仍需按各自流程完成。
常见问题
团队刚开始建分类体系，三部分应该先做哪一部分？
通常从类别层级入手，先确定业务域和需求类型这两层，让需求有基本归属；随后补充少量高频标签，例如来源和优先级；判定口径可以在前两者稳定后逐步积累，把已经出现过的歧义写成边界规则和正反例。三部分不必一次做全，但每新增一类或一个标签，都应同步记录判断依据，避免口径只留在个人经验里。
一条需求同时符合两个类别时怎么处理？
这通常说明同级类别之间存在重叠。短期可以按判定口径中的优先级顺序取舍，例如合规类需求优先归入合规类别；长期应检查两个类别的边界描述，确认是否有一个类别可以合并或下沉为标签。若重叠反复出现，说明类别设计需要调整，仅靠逐条裁决会让分类结果持续不稳定。
标签数量多少算合适？
没有统一数量标准，判断依据是每个标签是否对应团队实际会用来筛选的问题。常见做法是每个维度给出有限取值，并明确单选还是多选。当一条需求被打上十几个标签、筛选结果失去区分度，或同一含义出现多种写法时，就说明标签需要收敛：合并近义标签、删除长期无人使用的标签、固定取值写法。
AI分类结果和人工判断不一致时，应该改AI还是改口径？
先判断不一致的原因。如果AI违反了已写明的边界规则，属于执行偏差，可以补充正反例或调整提示内容；如果人和AI对同一条规则的理解不同，说明口径本身表述不清，应修订判定口径并记录版本。逐条手工修改结果只能解决单次问题，反复出现的分歧需要回到规则层面处理。
分类体系建好后，需求分析流程需要跟着改吗？
分类体系提供的是归类和检索结构，需求分析仍按原有流程处理背景、目标、用户场景和验收条件。两者可以衔接：分类结果帮助分析人员快速找到同类历史需求，分析完成后也可据此归档。分类体系不判断需求是否合理，也不替代需求评审，流程调整应聚焦在归类、打标和复核环节的职责分工上。
