AI需求分类的具体做法，是先把分类维度定义成可判定的字段与取值，再让AI按字段逐条打标并给出判定依据，最后由人做抽样复核与冲突裁决。落地顺序为：确定分类目的与维度、编写判定规则与示例、准备需求样本与提示词、批量分类并输出结构化结果、抽样复核与规则迭代、把分类结果接入需求池与评审流程。本文按这套顺序展开，适用于产品、研发、测试共同参与的需求整理场景。
要点总览（TL;DR）
- 先写分类目的说明：谁使用、用来做什么、需要几个维度、本次处理哪些需求，后续规则设计与复核标准都以此为准。
- 把维度做成可判定字段：取值互斥、有书面判定规则、边界情况有明确归属，维度数量控制在三到五个。
- 流程分五步：整理样本、编写提示词、小批量试跑、批量分类、抽样复核与冲突裁决，每步都有输入、动作、输出和完成标志。
- 规则定义与结果复核建议由不同的人承担，维度表、提示词和复核记录都要版本化留存。
- 分类结果写入需求池字段并进入评审流程才算落地，验收时重点看取值覆盖、抽样一致率和依据可追溯性。
先定分类目的：AI需求分类要回答哪些问题
分类本身不产生价值，分类结果被谁使用、用来做什么决定才产生价值。动手设计维度之前，先写一份简短的目的说明，把使用方、用途、维度数量和输入范围固定下来，后续的规则设计和复核标准都以此为准。
使用方不同，需要的分类粒度差别很大。产品负责人关心需求类型和业务域，用来判断该由谁承接；研发负责人关心影响对象和技术复杂度，用来评估排期；测试关心变更范围，用来确定回归范围；管理层关心来源渠道和紧急程度，用来观察需求分布。把使用方列清楚，可以避免设计出一堆没人看的字段。
用途决定维度数量。如果只用于分派负责人，两到三个维度通常够用；如果要支撑优先级排序和统计报表，维度会增加到五到六个，但每个维度都要有明确的判定规则。维度越多，AI判定的歧义越大，人工复核成本也越高。
输入范围同样要提前写明：需求来自哪些渠道（客户反馈、销售转达、内部提出、线上问题），本次处理多少条，是否包含历史积压需求。历史需求往往描述不规范、字段缺失，混入本次分类会拉低整体一致性，建议单独标注或分批处理。
完成这一步的交付物是一份分类目的说明，包含四项内容：使用方清单、每个使用方对应的用途、本次采用的维度数量、输入范围（来源、条数、是否含历史需求）。这份说明在后续出现分歧时是裁决依据。
设计分类维度与取值：把模糊标签变成可判定字段
AI分类效果差，多数时候问题出在维度定义上，而非模型能力。“重要”“紧急”“体验优化”这类标签，人看了都要猜，AI只能给出看似合理但无法复核的结果。可判定的维度需要满足三个条件：取值互斥、有书面判定规则、边界情况有明确归属。
常见维度可以从以下几个方向选取，按本次目的取舍，不必全部采用：
| 维度名 | 取值示例 | 判定规则要点 | 边界说明 |
|---|---|---|---|
| 需求类型 | 新功能 / 功能优化 / 缺陷修复 / 合规要求 | 按“是否新增能力、是否修正既有行为、是否由外部规范驱动”判定 | 既新增能力又修正缺陷的，按主要交付物归类，并在依据中注明 |
| 业务域 | 按产品模块或业务线划分 | 按需求描述中涉及的功能入口或数据对象归属 | 跨模块需求归入主模块，其余模块写入关联字段 |
| 影响对象 | 前端交互 / 后端服务 / 数据 / 权限 | 按需求改动涉及的系统层次判定 | 涉及多层时列出全部，不强行单选 |
| 紧急程度 | 高 / 中 / 低 | 按是否阻断线上业务、是否有明确时间承诺判定 | 无时间承诺且不影响线上的一律为中或低 |
| 来源渠道 | 客户 / 销售 / 内部 / 线上问题 | 按需求提出方的身份判定 | 客户经销售转达的，记为客户来源并注明转达方 |
取值设计有两个常见错误。一是取值重叠，比如“优化”和“改进”同时存在，AI只能在两者间随机选择；二是留一个笼统的“其他”，导致大量样本被塞进去，分类失去意义。解决办法是：每个维度先穷举取值，再检查任意两条需求能否同时落入两个取值，能则合并或补充判定规则；“其他”只作为兜底，占比超过一成就要回头补充取值。
维度数量控制在三到五个，是多数团队能长期维护的范围。每增加一个维度，就要多写一份判定规则、多一轮复核、多一次规则迭代。维度与字段的对应关系也要写清楚：哪个维度落到需求条目的哪个字段，字段是单选还是多选，是否允许为空。这份对应表是后续接入需求池的依据。
完成这一步的交付物是一张分类维度表，每行包含维度名、取值列表、判定规则、边界说明、对应字段与填写方式。
操作步骤：从需求样本到分类结果的完整流程
流程分五步，每步都有明确的输入、动作、输出和完成标志。建议第一次跑通全流程时控制在一百条以内，规则稳定后再扩大批量。
步骤一：整理需求样本。输入是各渠道收集的原始需求，动作是统一条目格式，每条至少包含编号、标题、描述、提出方、提出时间五个字段，描述过短的补充背景。输出是一份格式统一的需求清单。完成标志是清单中每条需求都能独立阅读，不依赖外部上下文。
步骤二：编写提示词。输入是维度表和需求清单，动作是写一段包含五部分内容的提示词：角色说明（你是一名需求分析助手）、维度定义（逐条列出维度、取值和判定规则）、判定要求（先读描述再判定，依据不足时标注“待确认”而非猜测）、输出格式（每条需求输出编号、各维度取值、判定依据、置信说明）、不确定处理（信息不足时说明缺什么信息）。输出是一份可复用的提示词文本。完成标志是提示词能被另一位同事直接使用并得到结构一致的输出。
步骤三：小批量试跑。输入是提示词和十到二十条代表性需求，动作是运行并逐条检查输出结构是否完整、判定是否符合规则、依据是否指向描述中的具体内容。输出是试跑结果和问题清单。完成标志是输出格式稳定，且试跑样本中没有出现规则未覆盖的情况，或已补充规则。
步骤四：批量分类。输入是全量需求清单和定稿提示词，动作是分批运行，每批保留AI给出的判定依据和置信说明，不删除原始输出。输出是结构化的分类结果表。完成标志是全部需求都有分类记录，无遗漏条目。
步骤五：抽样复核与冲突裁决。输入是分类结果表，动作是按比例抽样（初次建议不低于两成），由复核者逐条比对判定依据与需求描述，记录误判、规则缺口和争议条目，争议条目提交需求负责人裁决。输出是复核记录和修订后的分类结果。完成标志是抽样一致率达到约定标准，且所有争议条目已有结论。
分类结果最终要落到团队日常使用的需求池里，才能被分派、排期和统计。ONES 的需求管理场景中，需求以工作项形式承载，ONES Assistant 可以理解项目、工作项和 Wiki 页面等真实工作上下文，基于项目数据和团队知识回答问题并执行后续操作，也能围绕用户反馈洞察、PRD 质量检查等环节提炼要点与待澄清问题。把分类结果写回工作项字段、再进入评审流程时，这套上下文能力可以减少反复补充背景的沟通成本。字段自定义与批量写入的具体配置方式，建议在选型时结合实际版本核验。
角色分工与交付物：谁定义规则、谁复核、谁使用结果
分类流程涉及四类角色，职责不清时最容易出现“规则没人改、误判没人认”的情况。下表给出职责与交付物的对应关系。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 需求负责人（产品角色） | 确定分类目的，定义维度与判定规则，裁决争议条目 | 分类目的说明、维度表、裁决记录 | 向执行者交付定稿维度表；接收争议清单 |
| AI使用执行者 | 整理样本、编写与调优提示词、批量运行、维护输出记录 | 需求清单、提示词文本、分类结果表 | 向复核者交付结果表；向负责人反馈规则缺口 |
| 复核者 | 抽样检查、记录误判类型与规则缺口 | 复核记录、一致率统计 | 向负责人提交争议条目；向执行者提交修订建议 |
| 结果使用方 | 按分类结果分派负责人、安排排期、统计分布 | 分派记录、统计口径说明 | 向负责人反馈字段是否够用 |
小团队中一人可以兼任多个角色，但定义规则和复核结果建议由不同的人承担，否则规则缺陷很难被发现。每次规则修订都要记录版本、修订人和修订原因，下一轮分类直接沿用最新版本。
示例：一批需求如何完成AI分类
以下为演示情景，用于说明方法，不代表真实客户案例。假设某团队收集了二十条需求，本次目的为“分派负责人并统计来源分布”，采用三个维度：需求类型、业务域、来源渠道。
示例需求条目：编号 R-017，标题“导出报表时筛选条件不生效”，描述“在订单报表页选择时间范围后导出，导出文件仍为全部数据”，提出方为某客户，经销售转达。
按维度表判定：需求类型为缺陷修复，依据是“既有功能行为与预期不符”；业务域为报表模块，依据是描述中涉及的功能入口；来源渠道为客户，依据是提出方身份，并注明经销售转达。
AI输出结构示例：编号 R-017；需求类型=缺陷修复；业务域=报表模块；来源渠道=客户（销售转达）；判定依据=描述中“筛选条件不生效、导出仍为全部数据”表明既有功能未按预期工作；置信说明=高，描述完整。
复核中发现的问题：另一条需求 R-009 描述为“希望报表支持自定义字段”，被判定为功能优化，但按规则应属于新功能，因为该能力此前不存在。原因是判定规则只写了“修正既有行为为优化”，没有写“新增此前不存在的能力为新功能”。修订方式是在需求类型维度中补充这条正向规则，并增加一个反例说明。
修订后重跑，R-009 判定为新功能，同批中另外两条类似描述的需求也得到纠正。这次修订同时暴露了“其他”取值占比偏高的问题，团队据此补充了两个业务域取值，重跑后“其他”占比明显下降。
完成检查：分类结果可用性的验收项
分类跑完后，用下面这份清单逐项核对，全部通过再接入正式流程。
- 维度取值覆盖全部样本，无遗漏条目；“其他”占比控制在可接受范围，超出则补充取值或规则。
- 抽样复核已完成，一致率达到团队约定标准，主要误判类型已记录并对应到规则修订。
- 每条分类结果都带有判定依据，依据指向需求描述中的具体内容，可被第三人复核。
- 争议条目已全部裁决，裁决结论写入规则或备注。
- 分类结果已写入需求池对应字段，并进入评审或分派流程，使用方确认字段够用。
- 维度表、提示词、复核记录均已版本化留存，标注版本号与修订时间。
不达标时的返工路径按问题类型区分：取值覆盖不足，回到维度设计补充取值；一致率偏低，先看误判是否集中在某一维度，集中则修订该维度规则，分散则检查提示词中的判定要求是否清晰；依据不可追溯，调整输出格式要求，强制每条结果附带描述引用；结果未接入流程，与使用方确认字段映射后补做写入。返工后重新抽样，通过再进入下一批。
常见问题
需求描述很短、信息不全时，AI分类该怎么处理？
在提示词里明确要求：依据不足时标注“待确认”并说明缺什么信息，不要求AI猜测。分类结果表中保留这一状态，由需求负责人补充背景后重跑该条。如果待确认条目占比很高，说明需求收集环节的字段要求需要收紧，可以在需求清单模板中把描述、提出方、期望结果设为必填。
分类维度应该一次设计到位，还是边跑边加？
建议先按当前目的设计最小可用的一组维度，跑完一批并复核后再决定是否增加。每增加一个维度，都要同步补充判定规则、更新提示词、重新试跑并扩大复核比例。一次性设计过多维度，常见结果是规则之间互相冲突，复核成本上升而分类结果的使用方并没有增加。
抽样复核发现一致率不达标，应该先改规则还是先改提示词？
先看误判的分布。误判集中在某一个维度，通常是该维度的判定规则有缺口或取值重叠，应修订维度表；误判分散在多个维度且类型杂乱，通常是提示词中的判定要求不够清晰，或输出格式没有强制附带依据，应先调整提示词。两类问题同时存在时，先修规则再调提示词，避免在错误的判定标准上反复优化表达。
分类结果怎么和现有的需求评审流程衔接？
把每个维度映射到需求条目上的具体字段，分类完成后写回字段，评审时按字段筛选和分派。衔接前先与结果使用方确认字段是否够用、单选多选是否符合习惯、空值如何处理。在 ONES 中，需求以工作项形式承载，分类结果可以写回工作项字段并进入评审；字段自定义与批量写入的具体配置方式，建议结合实际版本核验。
历史积压需求要不要一起分类？
可以分，但建议单独一批处理。历史需求常见描述不规范、字段缺失、提出人已离职等情况，与新增需求混在一起会拉低整体一致率，也不利于定位问题。单独处理时可以适当放宽判定要求，把信息不足的条目标为待补充，先完成可判定部分的分类，再决定是否投入人力补齐历史信息。
