建立AI需求分类体系，起点是明确分类结果要服务哪些动作，再据此确定层级深度、标签粒度和判定口径。本文按搭建顺序展开：先写清用途与范围，再设计两到三层的层级结构、按维度拆分的标签表、可执行的判定规则，随后处理重叠与模糊、建立新增类别流程，最后用示例和验收清单检查体系是否可用。
要点总览（TL;DR）
- 分类体系从用途出发：先写清分类结果给谁用、用于分流还是统计，再决定层级和标签的取舍。
- 层级控制在两到三层，第一层选定一个主维度（业务域、需求类型或实现方式），其余维度交给标签表达。
- 标签按维度拆分并设数量上限，单条需求五到八个标签，区分必填与选填，定期合并同义取值。
- 判定口径为每个类别写明判定条件、反例和示例，规定主类唯一、辅标签可多，并约定冲突时的优先级。
- 新增类别走申请、试标、固化三步，试标验证可判定性后再纳入正式体系，并同步更新判定口径与变更记录。
先定用途：分类体系服务哪些动作
分类体系的第一份文档应当是一页纸的目标说明，写清三件事：分类结果给谁用、用来做什么、哪些内容不在本体系覆盖范围内。缺少这一步，团队容易先画出漂亮的层级树，上线后却发现没人按它分流，或者统计报表需要的维度根本没有采集。
不同用途对体系的要求差异明显。需求分流要求第一层能快速区分处理路径，层级宜浅、判定要快；优先级排序需要紧急度、影响范围等标签支撑，标签必须可判定；评审分组要求类别与评审专家的分工对应，类别边界要稳定；统计报表则要求类别在一段时间内保持稳定，频繁改名或合并会让趋势数据失真。搭建前把主要用途排个序，取前两三项作为设计约束，其余用途作为兼容目标。
目标说明建议包含以下字段，控制在一页以内：
- 体系名称与版本：例如“AI需求分类体系 v0.1”，便于后续变更追溯。
- 主要用途：按优先级列出，如“需求分流为主，季度统计为辅”。
- 使用角色：谁负责打标、谁复核、谁消费分类结果。
- 适用范围：覆盖哪些需求来源，例如产品需求、内部工具需求、客户定制需求。
- 不覆盖的内容：例如缺陷、纯运维工单，明确排除可减少边界争议。
这份说明的完成标志是：一位未参与设计的同事读完，能说出分类结果将被谁在什么环节使用，以及遇到范围外需求应转向哪里。
层级深度怎么定：两到三层的取舍
层级回答“这条需求属于哪一类”，是全体系的骨架。第一层的选择通常从三个维度中取一个：业务域（如推荐、搜索、内容审核）、需求类型（如新功能、体验优化、合规改造）、实现方式（如模型能力、数据建设、工程改造）。三者混用会让第一层失去互斥性，建议选定一个主维度，其余维度交给标签表达。
层数控制在两到三层。两层的结构是“大类—子类”，例如“模型能力—检索增强”“模型能力—推理优化”，适合需求量和团队规模有限、分类执行人较少的情况。三层在第二层仍无法区分判定时引入，例如“模型能力—检索增强—召回策略”，第三层只在该子类下需求数量多、处理路径明显不同时才值得设置。
| 层数 | 适用条件 | 代价 |
|---|---|---|
| 两层 | 需求类型集中，执行人少，分流路径清晰 | 细分统计能力有限，部分差异靠标签补 |
| 三层 | 第二层下需求量大且处理路径分化明显 | 判定时间增加，维护和培训成本上升 |
| 四层及以上 | 通常不建议 | 检索、统计口径难以稳定，执行人易选错层级 |
层级命名要满足两个条件：互斥，即任意一条需求最多落入一个末级类别；可判定，即名称本身能让人判断归属，避免“其他”“综合”“优化类”这类无法判定的名称。每个层级节点配一句定义和两个示例，定义写“包含什么”，示例写“典型需求长什么样”。层级结构草案的完成标志是：随机抽十条历史需求，两名执行人独立归类，末级类别一致率达到团队约定水平。
标签粒度怎么定：维度拆分与数量控制
层级表达唯一主类，标签负责横向补充信息。标签按维度组织，每个维度是一组互斥或可多选的取值，常见维度包括：来源（客户反馈、内部提出、数据分析发现）、影响对象（终端用户、运营人员、模型效果）、紧急度（阻断、高、常规）、技术域（数据、模型、工程、合规）。维度之间不重叠，同一维度内的取值要能明确选中一个或明确多选。
标签数量需要设上限。单条需求的标签总数建议控制在五到八个，其中必填维度两到三个（如来源、影响对象），选填维度按需补充。必填维度过多会拖慢录入，过少则统计时缺数据。标签维度表应包含维度名、取值列表、必填或选填、取值示例四列，作为执行人的对照依据。
| 维度 | 取值示例 | 必填性 | 说明 |
|---|---|---|---|
| 来源 | 客户反馈、内部提出、数据洞察 | 必填 | 单选，用于追溯需求产生渠道 |
| 影响对象 | 终端用户、运营、模型效果 | 必填 | 可多选，用于评估影响面 |
| 紧急度 | 阻断、高、常规 | 必填 | 单选，与优先级排序联动 |
| 技术域 | 数据、模型、工程、合规 | 选填 | 可多选，用于评审分组 |
标签命名要统一格式，同义词及时合并，例如“客户提出”和“客户反馈”保留一个，另一个作为别名记录在维度表中。标签膨胀的预警信号包括：同一维度取值超过十个、出现大量只被使用过一两次的标签、执行人开始自行创建标签。出现这些信号时启动清理：合并语义相近的取值，停用长期未使用的标签，清理结果记入变更记录。
判定口径怎么写：规则、优先级与边界示例
判定口径是让多人分类一致的核心文档。每个末级类别写三部分：判定条件，用可观察的需求特征描述，例如“涉及模型输入输出的格式或内容调整”；反例，说明哪些看似相关的需求不属于该类；归属示例，给一到两条真实需求编号。判定条件避免使用“重要”“复杂”这类主观词。
归属规则明确两条：主类唯一，每条需求只落一个末级类别；辅标签可多，按维度补充。冲突时的优先级顺序需要事先约定，常见做法是按“合规与安全类优先于功能类，功能类优先于体验优化类”排序，具体顺序由团队根据业务风险确定，并写入判定口径文档。
边界示例库是判定口径的配套资产。每当出现一次归类争议，就把需求原文摘要、争议点、最终归属和理由记入示例库，按类别索引。示例库每月或每迭代复核一次，高频争议场景应优先补充。判定口径文档的完成标志是：新加入的执行人只读文档和示例库，能对抽样需求做出与复核人一致的判断。
类别重叠与边界模糊怎么处理
重叠和模糊是体系运行中的常态问题，需要具体的处置动作而非笼统的沟通要求。识别重叠的方法是统计：一段时间内同一需求被不同执行人分到不同类别的频次，频次高的类别对即为重叠热点。统计口径可以按周或按迭代，数据来自归类记录中的修改痕迹或复核差异。
处置路径有三条，选择依据不同：两个类别语义高度接近、区分价值低，选择合并；一个类别内部需求差异大、处理路径明显不同，选择拆分并增设子类；两个类别确实都适用且都需要保留，增设交叉标签，在主类之外标记另一属性。每次处置后同步更新判定口径和示例库。
模糊需求的临时处理：先按最接近的类别归类，并在记录中标记“待复核”，由复核人在约定时限内确认或调整。定期抽样复核建议每月一次，抽取比例按团队约定，重点覆盖新增类别和高频争议类别。复核结果形成口径修订记录，修订后的规则对后续需求生效，历史数据是否回溯调整由统计用途决定。
新增类别怎么加：申请、试标与固化
新增类别是体系扩张的主要入口，需要准入流程。申请单包含四个字段：触发场景，描述什么需求促使提出新增；现有类别不适用的原因，说明为何无法归入已有类别；预计使用频次，给出近期的需求数量估计；建议的类别名称与定义。缺少频次估计的申请通常说明需求尚不构成独立类别，可先用标签过渡。
试标阶段在小范围内验证可判定性：选取十到二十条相关需求，由两到三名执行人独立归类，检查一致率和判定耗时。一致率低或执行人普遍需要反复讨论，说明定义不清，应修改定义后重试，而非直接固化。试标结论记录在申请单上，包含一致率、争议点和定义修订。
复核通过后固化：纳入正式层级或标签维度表，同步更新判定口径、示例库和培训材料，并在变更记录中登记生效日期。废弃与合并类别同样走变更记录：标注停用日期，说明历史需求的迁移方式，保留旧类别名称作为检索别名，避免历史报表断档。
角色分工与交付物清单
体系能否持续运行，取决于角色是否清晰。通常设三类角色：体系负责人，负责目标说明、层级与标签设计、变更审批；分类执行人，负责日常归类打标，按判定口径操作；复核人，负责抽样复核、争议裁决和示例库维护。小团队可由一人兼任负责人与复核人，但执行与复核应尽量分离，以保证一致率检查的有效性。
| 角色 | 输入 | 主要动作 | 输出 |
|---|---|---|---|
| 体系负责人 | 用途需求、变更申请、复核报告 | 设计层级与标签、审批变更、组织验收 | 目标说明、层级结构、变更记录 |
| 分类执行人 | 需求原文、判定口径、示例库 | 逐层判定主类、选择辅标签、标记待复核 | 归类结果与打标记录 |
| 复核人 | 归类记录、抽样清单 | 抽样复核、裁决争议、补充边界示例 | 复核报告、口径修订建议 |
交付物清单包括：目标说明、层级结构草案、标签维度表、判定口径文档、边界示例库、新增类别申请单与试标结论、变更记录、验收检查表。这些文档集中存放并版本化，执行人能在同一位置查到最新口径。
分类结果最终要落到需求工作项上才能被使用。在 ONES 中，需求以工作项形式承载，分类所需的类型、标签和自定义字段可以随工作项一起流转，评审、排期和统计都基于同一份数据。ONES Assistant 能理解项目、工作项、迭代和 Wiki 页面等工作上下文，围绕需求澄清提炼要点、待澄清问题与拆解建议，帮助团队在录入阶段就把需求信息补全，减少后续归类时的信息缺失。相关输出基于 ONES 权限体系执行，过程可追踪、结果可审计。
示例：一条AI需求的完整归类过程
以下为演示情景，用于说明判定过程，非真实案例。
需求原文摘要：“客服知识库问答的答案经常引用过期文档，希望系统在回答时优先使用最近三个月更新的内容，并在答案中标注引用文档的更新时间。”
第一步提取关键信息：涉及问答系统的检索与排序逻辑，涉及答案展示格式，影响对象是客服人员与终端用户，来源为运营反馈，紧急度为高。
第二步逐层判定。第一层在“模型能力”与“工程改造”之间，该需求核心是检索排序策略调整，归入“模型能力”。第二层在“检索增强”与“推理优化”之间，需求指向召回内容的时效性，归入“检索增强”。末级类别确定为“模型能力—检索增强—召回策略”。
第三步选择辅标签：来源选“内部提出”，影响对象选“运营”和“终端用户”，紧急度选“高”，技术域选“模型”和“数据”。
第四步处理边界情况：答案中标注更新时间涉及前端展示，与“工程改造”类别存在交叉。按优先级规则，核心处理路径在检索侧，主类保持“召回策略”，同时记录一条待复核项，由复核人确认是否需要增设“展示格式”交叉标签。该记录进入边界示例库，作为后续类似需求的判定参考。
完成检查：体系可用的验收项
体系是否可用，用一份检查表逐项核对，而不是凭感觉判断。以下各项全部通过或对未通过项有明确整改计划，即可认为体系进入可用状态。
| 检查项 | 通过标准 | 核对方式 |
|---|---|---|
| 层级互斥可判定 | 每个末级类别有定义和示例，无“其他”类兜底 | 逐节点检查层级结构草案 |
| 标签维度完整 | 必填维度齐全，单条需求标签数在上限内 | 抽查二十条需求的打标记录 |
| 多人标注一致率 | 独立标注一致率达到团队约定阈值 | 抽取样本由两人以上独立归类比对 |
| 边界示例覆盖 | 高频争议场景均有对应示例 | 对照复核报告检查示例库 |
| 新增流程已试运行 | 至少完成一次申请、试标、固化的完整流程 | 查看申请单与变更记录 |
| 口径与变更可查 | 判定口径为最新版本，变更记录含生效日期 | 核对文档版本与变更记录 |
一致率阈值由团队根据用途确定：用于统计报表的体系通常要求更高的一致性，用于初步分流的体系可适当放宽。验收通过后，体系进入运行阶段，按月度抽样复核和变更流程持续维护；用途或业务范围发生明显变化时，回到目标说明重新确认，再决定是否调整层级与标签。
常见问题
团队规模很小，还需要单独设复核人吗？
小团队可以由体系负责人兼任复核人，但执行与复核应尽量分开：日常归类由执行人完成，复核人定期抽样比对。若只有一人负责全部工作，至少保留独立标注环节，即隔一段时间由本人对已归类需求重新盲标一次，比对前后差异。这样做的目的是保留一致率检查的有效性，避免自己归类、自己复核导致口径偏差长期不被发现。
历史需求已经按旧口径分好类，新口径上线后要全部重新归类吗？
是否回溯取决于分类结果的用途。用于趋势统计的体系，历史数据口径不一致会让趋势失真，建议对统计区间内的历史需求做批量迁移，或在新口径生效处标注断点，报表按断点分段解读。用于日常分流的体系，历史需求通常不再流转，可保留原归类，仅对新需求应用新口径。无论哪种选择，都应在变更记录中写明生效日期与迁移方式，保留旧类别名称作为检索别名。
一致率应该定多少才算合格？
一致率阈值由团队根据用途确定，没有统一标准。用于统计报表的体系对一致性要求更高，因为类别漂移会直接影响数据可信度；用于初步分流的体系可适当放宽，因为后续评审环节还有人工校正机会。建议先测一次基线：抽取二十到三十条需求，由两名以上执行人独立归类，记录当前一致率，再据此设定略高于基线的目标值，按月度复核逐步提升。
一条需求同时涉及模型调整和工程改造，主类怎么定？
按判定口径中约定的优先级顺序处理。常见做法是以核心处理路径为准：需求的主要工作量与验收标准落在哪一侧，主类就归哪一侧，另一侧用技术域标签标记。若两侧工作量相当、无法判断主次，先按最接近的类别临时归类并标记待复核，由复核人裁决，裁决结果记入边界示例库。反复出现同类争议时，考虑增设交叉标签或在判定口径中补充该场景的判定条件。
分类体系建好后，多久需要整体调整一次？
没有固定周期，触发调整的信号比时间表更可靠。常见信号包括：新增类别申请明显增多、复核中高频争议集中在少数几个类别、业务范围发生变化导致第一层不再覆盖主要需求、统计报表显示某类别长期为空或持续膨胀。出现这些信号时，回到目标说明重新确认用途与范围，再决定调整层级还是标签。日常维护按月度抽样复核和变更记录执行，整体调整不必定期进行。
