AI需求分类要稳定一致，靠的是分类结构本身的分工：类别层级决定每条需求归到哪一层、哪个父类，标签集合补充类别无法表达的横切属性，判定口径写明什么情况归入、什么情况不归入、冲突时谁优先。三者各管一件事，配合起来才能让不同人、不同时间、不同模型给出的分类结果可复现、可复核。本文解释三者的职责、配合链路，以及容易混淆的概念和常见误解。
要点总览（TL;DR）
- 类别层级负责主归属：每条需求只落一个主类别，父类路径明确，同级类别判定范围不重叠。
- 标签集合负责补充横切属性：来源、优先级、涉及模块、变更类型等用标签表达，不改变主类别。
- 判定口径负责裁决：为类别和关键标签写明判定条件、正反例与优先级，边界情况按规则处理。
- 三者配合形成可复现链路：先按口径匹配类别，再定唯一主类别，补充标签，冲突按优先级裁决，输出附判定依据。
- 层级深度、标签词表和判定口径需要同步维护，业务变化后及时补充条件和正反例，分类结果才能长期稳定。
直接答案：三者各管一件事，合起来才一致
AI需求分类不一致，常见原因不在模型能力，而在分类结构没有把“归属”“补充”“裁决”分开。类别层级负责主归属：每条需求在层级中只能落在一个主类别上，父类与子类的关系明确，避免同一需求被放进两个平行类别。标签集合负责补充：来源渠道、优先级、涉及模块、变更类型这类横切属性，用标签表达，不改变主类别。判定口径负责裁决：为每个类别和关键标签写明判定条件、正反例和优先级，遇到边界情况按规则处理，而不是靠临场判断。
三者配合后，分类结果具备两个特征。一是可复现：同一需求在不同时间、由不同执行者（人或AI）处理，按同一套层级、标签和口径应得到相同的主类别与标签组合。二是可复核：输出结果附带判定依据，复核者能对照口径检查归类是否成立，而不是只看到一个类别名称。
| 要素 | 作用对象 | 主要输出 | 一致性职责 |
|---|---|---|---|
| 类别层级 | 需求的主归属 | 唯一主类别及父类路径 | 保证同一需求落在同一位置 |
| 标签集合 | 横切属性 | 若干标签值 | 保证附加信息表达口径统一 |
| 判定口径 | 边界与冲突 | 判定条件、优先级、依据说明 | 保证同类情况得到同样结论 |
类别层级：定义需求的归属骨架与粒度
类别层级是把需求按业务或产品结构组织起来的树状分类结构，由层级深度、父子关系、同级互斥要求和粒度四个要素构成。层级深度指从根类别到叶子类别的层数；父子关系规定子类继承父类的业务含义；同级互斥要求同一父类下的子类别在判定上不重叠；粒度指叶子类别覆盖的需求范围大小。这四个要素共同决定分类的稳定性。
层级深度和粒度直接影响一致性。层级过浅，一个类别覆盖过多需求，边界模糊，AI只能凭语义猜测；层级过深，相邻叶子类别差异细微，人和AI都容易在相近类别间摇摆。较稳妥的做法是让叶子类别对应团队能够清楚描述、且能给出正反例的范围，深度以业务人员不查文档也能说出归属为准。
同级类别互斥与单一主归属是层级设计的关键约束。同一父类下的子类别应满足：一条需求最多归入其中一个；如果确实存在交叉，应通过调整类别定义或增加判定口径解决，而不是允许一条需求同时属于两个主类别。单一主归属让统计、排期和责任分配有唯一口径。需要说明的是，类别层级只表达归属骨架，来源、优先级这类横切属性不放在层级里，否则层级会因属性组合而膨胀。
- 层级深度：从根到叶的层数，按业务可辨识度确定。
- 父子关系：子类继承父类含义，父类不重复出现在叶子判定中。
- 同级互斥：同一父类下子类别判定范围不重叠。
- 粒度：叶子类别覆盖的需求范围，以能写出正反例为界。
- 单一主归属：每条需求只落一个主类别。
标签集合：承载类别之外的横切属性
标签集合是一组用于描述需求附加属性的标记，定位是补充类别层级无法表达的横切信息。一条需求的主类别回答“它属于哪类工作”，标签回答“它还有什么属性”。常见标签维度包括来源（用户反馈、内部提出、线上问题）、优先级（高、中、低）、涉及模块（登录、支付、报表）、变更类型（新增、优化、修复）等。这些维度可以同时作用于多个类别，因此不适合放进层级。
标签与类别是主次关系：标签不改变主归属。一条需求归入“支付流程优化”，同时打上“来源：用户反馈”和“优先级：高”，它的主类别仍是支付流程优化，标签只用于筛选、排序和统计。如果某个标签值实际上决定了需求该归哪一类，说明这个维度应上升为类别层级的一部分，而不是继续留在标签里。
标签集合的一致性风险主要来自两点：标签过多和口径不统一。标签维度无限扩张，会出现同义标签并存、同一属性多种写法；口径不统一，则不同人对“高优先级”的理解不同。处理方式是在受控词表与自由标签之间做取舍：用于统计和流转的关键维度采用受控词表，限定可选值；探索性、临时性的标记可以保留自由标签，但应定期收敛为受控值。受控词表需要指定维护人，新增标签值走同一入口。
判定口径：把分类规则写成可执行的判断条件
判定口径是针对类别和关键标签写明的判断规则，内容通常包括判定条件、正反例、优先级规则、冲突处理和复核方式。判定条件用可观察的特征描述“什么情况归入该类”，例如“需求的主要交付物是支付链路的稳定性改进，且不新增对外功能”。正例和反例各给一到两条，帮助执行者校准边界。优先级规则规定多个类别都看似成立时谁优先。冲突处理说明规则之间矛盾时以哪条为准。复核方式规定谁在什么节点检查分类结果。
判定条件的写法要避免形容词堆叠，尽量落到可核对的对象和动作上。“涉及用户体验”这类表述无法判定，“修改结算页面的金额展示逻辑”则可以核对。正反例的作用是把条件具体化：正例展示典型归入情形，反例展示看似相关但应归入其他类别的情形，两者成对出现才能收紧边界。
多类别冲突时的优先级规则需要事先约定，常见做法包括：更具体的类别优先于更宽泛的类别；业务主流程类别优先于支撑性类别；无法按前两条判断时，归入父类并标记待复核。优先级规则应写进口径文档，而不是留给执行者临场决定。人工复核与口径修订要衔接：复核中发现的边界争议，若属于口径缺失，应补充条件或正反例；若属于类别设计问题，则回到层级调整。口径文档保留修订记录，AI分类时引用当前有效版本。
三者如何配合：一条需求从输入到定类的完整链路
下面用一条演示需求走完分类链路，说明三个要素在每一步的作用。需求内容为：“结算页在弱网环境下偶发金额显示为旧值，用户反馈较多，希望尽快修复。”这是一条演示情景，用于说明链路，不代表真实案例。
- 输入与初判：需求进入分类环节，先按判定口径逐条比对类别层级中的叶子类别。口径中“缺陷修复”类条件为“现有功能在特定环境下表现异常，不新增功能范围”，该需求符合；同时“性能优化”类条件要求“以提升响应速度或吞吐为目标”，该需求主诉是显示错误，不满足。初判归入“缺陷修复”。
- 确定唯一主类别：在“缺陷修复”父类下，按同级互斥要求选择子类“前端显示缺陷”，而非“接口数据缺陷”，依据是口径正例中“页面展示值与实际值不一致”归入前端显示缺陷。主类别确定，父类路径为“缺陷修复 > 前端显示缺陷”。
- 补充标签：主类别确定后，按标签集合补充横切属性：来源为“用户反馈”，优先级为“高”，涉及模块为“结算页”，变更类型为“修复”。标签不改变主类别。
- 冲突裁决：若执行者认为该需求也应归入“性能优化”，按口径优先级规则“更具体的类别优先于更宽泛的类别”，前端显示缺陷比性能优化更具体，维持原主类别；性能相关判断作为备注记录，不另设主类别。
- 输出与复核：输出结果包含主类别、父类路径、标签组合和判定依据（引用的口径条款与正反例）。复核者对照口径检查，若发现口径未覆盖该情形，提交口径修订，而不是直接改分类结果。
这条链路中，类别层级提供可选位置和互斥约束，标签集合承载附加信息，判定口径在初判、子类选择、冲突裁决和复核四个节点提供依据。分类结果落到具体载体上时，需要工作项类型、字段和标签的配置支持。在ONES中，需求可以作为工作项承载，ONES Assistant能够理解项目、工作项、迭代和Wiki页面等工作上下文，并可将结果保存为工作项、Wiki页面等内容，便于分类结论与需求记录放在同一处；相关输出过程可追踪，具体追踪粒度以权限体系配置为前提。至于类别层级、受控标签词表在ONES中的具体配置方式，属于选型时需要核验的点。
相邻概念区别：分类体系、分类标准与分类结果
分类体系、分类标准和分类结果是三个层级不同的概念，混用会导致口径漂移。分类体系是结构与规则的整体，包含类别层级、标签集合和判定口径三部分；分类标准是判定口径中的具体条款，是分类体系里可引用的规则单元；分类结果是单条需求经过分类后得到的输出，包括主类别、标签和判定依据。三者是整体、条款与产物的关系。
| 概念 | 范围 | 典型内容 | 混用的后果 |
|---|---|---|---|
| 分类体系 | 整体结构与规则 | 类别层级、标签集合、判定口径 | 把单条结果当成体系，无法复用 |
| 分类标准 | 具体判定条款 | 判定条件、正反例、优先级 | 把条款当体系，遗漏标签与层级 |
| 分类结果 | 单条需求输出 | 主类别、标签、判定依据 | 用个例反推规则，造成口径漂移 |
标签体系与类别体系也常被混淆。类别体系回答主归属，具有互斥和单一主归属要求；标签体系回答属性描述，允许多值并存，不承担归属功能。把标签当类别用，会让统计口径失去唯一性；把类别当标签用，则会让层级失去骨架作用。区分这些概念的实际意义在于：修订时知道改的是体系、条款还是单条结果，避免用个别分类结果直接覆盖通用规则。
具体例子与常见误解
再看一条含歧义的需求：“希望登录支持手机号一键登录，同时优化登录失败提示。”这条需求同时包含新增能力和体验优化，容易在“新功能”和“体验优化”之间摇摆。按判定口径处理：先看主要交付物，若需求的核心价值是新增一种登录方式，归入“新功能 > 登录能力”；失败提示优化作为同一需求内的附带改进，用标签“变更类型：优化”记录，不拆出第二个主类别。若团队口径规定附带改进超过一定工作量需独立建项，则按该条款拆分，拆分后两条需求各自定类。裁决依据是口径中的“主要交付物优先”和拆分条件，而不是执行者的主观偏好。
常见误解有三类。其一，认为层级越深分类越准。层级加深会增加相邻类别的相似度，若口径没有同步细化，反而提高误判率；深度应与可写出的正反例匹配。其二，认为标签可以替代类别归属。标签多值并存，无法提供唯一主归属，用它替代类别会让统计和责任分配失去基准。其三，认为判定口径一次写定即可长期沿用。业务变化会产生新边界，口径需要在复核中持续补充条件和正反例，并保留修订记录，否则旧口径会与新需求脱节。
把这三类误解纠正后，一致性工作的重点就清楚了：维护好层级粒度与互斥、控制标签维度与词表、持续修订判定口径，三者同步演进，AI需求分类的结果才稳定可查。
常见问题
类别层级设计到几层比较合适？
层级深度以业务人员不查文档也能说出归属为准，叶子类别应能写出正反例。层级过浅会让一个类别覆盖过多需求，边界模糊；层级过深会让相邻叶子类别差异细微，人和AI都容易在相近类别间摇摆。深度增加时，判定口径要同步细化，否则误判率反而上升。
一条需求同时符合两个类别时怎么处理？
先按判定口径中的优先级规则裁决，常见顺序是更具体的类别优先于更宽泛的类别，业务主流程类别优先于支撑性类别。若前两条仍无法判断，归入父类并标记待复核，而不是允许一条需求同时属于两个主类别。复核中发现的边界争议，属于口径缺失的补充条件或正反例，属于类别设计问题的回到层级调整。
标签能不能直接当类别用？
不建议。标签允许多值并存，用于筛选、排序和统计，无法提供唯一主归属；类别具有互斥和单一主归属要求，承担统计、排期和责任分配的基准作用。如果某个标签值实际上决定了需求该归哪一类，说明这个维度应上升为类别层级的一部分。
判定口径写好后需要多久维护一次？
没有固定周期，触发维护的信号是复核中出现口径未覆盖的情形，或业务变化产生了新的边界。每次修订补充判定条件或正反例，并保留修订记录，AI分类时引用当前有效版本。口径长期不更新，会与新需求脱节，旧规则反而成为不一致的来源。
分类结果落到研发管理工具里，需要关注哪些配置？
需要关注工作项类型、字段和标签的配置能否承载主类别、父类路径和标签组合。在ONES中，需求可以作为工作项承载，ONES Assistant能够理解项目、工作项、迭代和Wiki页面等工作上下文，并可将结果保存为工作项、Wiki页面等内容，便于分类结论与需求记录放在同一处；相关输出过程可追踪，具体追踪粒度以权限体系配置为前提。类别层级和受控标签词表在工具中的具体配置方式，属于选型时需要核验的点。
