估算AI需求分析的人工复核工作量，可以用一个基础公式起步：总复核工时＝复核对象量×单件复核工时×覆盖比例×(1＋返工系数)，再按需求分析、业务确认、测试评审等角色拆分。估算前要先界定哪些AI产出进入复核、覆盖哪个阶段、按什么周期统计；抽样还是全量，则取决于AI输出错误流到下游的代价。ONES可承载需求条目与复核记录，便于后续取数校准。
要点总览（TL;DR）
- 复核工作量可用“复核对象量×单件复核工时×覆盖比例×(1+返工系数)”起步，再按需求分析、业务确认、测试评审等角色拆分工时与预算。
- 抽样与全量不是二选一：低风险需求按比例抽样，高风险、对外交付或合规相关需求走全量，混合策略通常比统一口径更省工时。
- 角色分工按维度切分，需求分析负责初筛与一致性，业务方确认业务正确性，测试与开发分别复核可测性与可实现性，后一环节只关注本维度问题。
- 判断复核成本是否合理，看三个信号：复核投入占需求阶段总投入的比例、单条需求复核工时是否稳定、漏检问题在下游造成的返工是否被压低。
- 估算参数按迭代或季度用实测值替换假设值，连续两个周期稳定后口径即可用于预算。
复核范围与时间跨度怎么界定
复核工作量估算最容易失真的地方，是把范围放得太宽。AI在需求阶段能做的事情很多，包括会议转录整理、用户反馈归纳、PRD草稿生成、需求条目拆解、用户故事与验收条件撰写。本文只讨论其中“理解与整理类产出”的人工复核，也就是AI生成或整理的需求条目、用户故事、验收条件、待澄清问题清单。这些产出的共同点是：它们会直接进入研发流程，错误会向下游传递，因此需要人工判断。
范围界定建议用一张表固定下来，每次估算沿用同一口径，避免不同迭代之间无法比较。
| 界定维度 | 纳入复核 | 不纳入本文复核工时 |
|---|---|---|
| 复核对象 | AI生成的需求条目、用户故事、验收条件、待澄清问题清单 | AI文档成稿、报告排版、会议纪要润色 |
| 需求阶段 | 需求整理完成到进入开发排期之前的确认环节 | 常规需求澄清访谈、业务调研本身 |
| 统计周期 | 按单个需求迭代统计，或按季度、项目周期汇总 | 跨周期的历史需求回溯 |
| 排除项 | — | 文档成稿类工作、日常需求沟通 |
时间跨度的选择影响估算用途。按单个迭代统计，适合判断当前复核投入是否稳定、单件工时是否漂移；按季度统计，适合做预算和人力规划，因为可以平滑个别复杂需求带来的波动；按项目周期统计，适合对外交付类项目，此时全量复核更常见，周期内总工时更能反映真实负担。三种口径可以并存，但同一份预算里不要混用。
复核工作量包含哪些成本和资源项
复核投入不只是“看一遍”的工时。把它拆成四类成本项，才能避免预算漏项，也便于后续按角色归集。
| 成本项 | 计量单位 | 主要承担角色 |
|---|---|---|
| 初筛与一致性核对工时 | 人时/条 | 需求分析 |
| 业务正确性确认工时 | 人时/条 | 业务方 |
| 可测性与可实现性复核工时 | 人时/条 | 测试、开发 |
| 评审会议时长 | 人时（时长×参与人数） | 上述角色共同 |
| 问题改写与再确认工时 | 人时/条 | 需求分析牵头，业务方配合 |
| 复核记录与模板维护 | 人时/迭代 | 需求分析或流程负责人 |
会议成本常被低估。一场一小时的评审会，六人参加就是六人时，如果每个迭代开两场，这部分投入可能接近甚至超过逐条阅读的工时。因此估算时要么把会议折算进单件复核工时，要么单列，但不能两边都算或都不算。
返工成本指复核发现问题后，改写条目、补充信息、再次找业务方确认所花的时间。它与返工系数直接相关，在计算模型中作为放大项处理。工具与流程成本包括复核记录表、抽样清单、检查模板的维护投入，通常按迭代或季度计一笔固定工时，不随条目数线性增长。
估算口径与假设怎么设定
口径不统一，算出来的数字就无法复算。建议在估算表开头固定以下假设，并注明哪些是团队实测值、哪些是暂定假设。
| 口径项 | 设定方式 | 注意事项 |
|---|---|---|
| 工时单位 | 人时为主，汇总时换算人天（按团队实际工作小时折算） | 按角色分别计量，不混算 |
| 覆盖比例 | 抽样复核填抽样比例，全量复核填100% | 抽样比例需说明抽取规则 |
| 返工系数 | 复核后需改写条目数÷复核条目数 | 初期可用假设值，运行两个迭代后替换为实测值 |
| 金额口径 | 如需折算费用，注明币种、是否含税费、按什么周期计 | 示例金额一律标注为假设，不作为报价 |
返工系数是最需要谨慎对待的参数。它反映AI输出中被人工判定需要修改的比例，受需求复杂度、提示词质量、模板成熟度影响。团队在第一个迭代往往没有历史数据，可以先按经验假设一个区间，例如10%至30%，并在估算表中明确标注“假设值，待实测校准”。覆盖比例同理，抽样复核时要说清是按条目随机抽、按模块抽还是按风险等级抽，不同抽法对漏检风险的影响不同。
复核工作量的计算模型与预算框架
基础公式为：总复核工时＝复核对象量×单件复核工时×覆盖比例×(1＋返工系数)。这个公式给出的是总工时，实际预算还要按角色拆分，因为不同角色的工时单价和可用时间不同。
按角色拆分的做法是：先确定每个角色参与复核的条目范围，再乘以该角色的单件工时。例如需求分析角色对全部条目做初筛，业务方只确认业务规则相关条目，测试与开发只复核验收条件与可实现性部分。各角色工时相加，得到总工时；再乘以对应角色的工时成本，得到预算金额。
下面是一个演示算例，所有数值均为假设，仅用于说明计算方法。假设某迭代AI生成需求条目200条，需求分析单件复核工时0.2人时，覆盖比例100%；业务方单件0.15人时，覆盖其中60%的条目；测试与开发单件0.1人时，覆盖80%的条目；返工系数取20%。则需求分析工时为200×0.2×1×1.2＝48人时；业务方为200×0.15×0.6×1.2＝21.6人时；测试与开发为200×0.1×0.8×1.2＝19.2人时；合计约88.8人时。若再计入每迭代两次评审会、每次6人1小时，增加12人时，总计约100.8人时。
抽样与全量的对比可以用同一组参数演示。若上例改为抽样复核，抽样比例30%，其余参数不变，则三类角色工时分别约为14.4、6.5、5.8人时，合计约26.7人时，加上会议成本后约38.7人时。全量复核的工时约为抽样的2.6倍。这个倍数关系会随抽样比例变化，团队可以据此快速判断不同策略的量级差异。需要强调的是，抽样节省的工时是否值得，取决于漏检问题在下游造成的返工代价，这一点在下一节展开。
抽样复核与全量复核怎么取舍
两种策略的差别不只是工时，还有风险分布。抽样复核把风险集中在未被抽中的条目上，全量复核把成本摊在每一条上。选择时按需求的风险等级分层处理，通常比二选一更实用。
| 对比维度 | 抽样复核 | 全量复核 |
|---|---|---|
| 适用条件 | 需求模式稳定、AI输出历史准确率较高、下游返工代价可控 | 对外交付、合规相关、跨系统集成、高风险核心流程 |
| 抽样比例设定 | 可按条目随机抽，或按模块、按风险等级分层抽，初期比例可设高一些再逐步下调 | 不适用 |
| 工时量级 | 约为全量的抽样比例倍数 | 基准量级 |
| 主要风险 | 漏检条目在开发或测试阶段暴露，返工成本更高 | 低风险条目也投入复核工时，存在过度投入 |
混合策略的做法是：先给需求打风险标签，高风险与对外交付类走全量复核，中风险按较高比例抽样，低风险按较低比例抽样并配合下游测试兜底。这样既控制总工时，又把复核资源集中在错误代价高的地方。判断抽样比例是否合适，可以观察一个指标：抽样复核后，下游阶段发现的需求类缺陷数量是否保持在可接受范围。如果漏检缺陷明显上升，说明比例偏低或抽样规则没有覆盖高风险条目。
复核角色如何分工
复核工作量膨胀的常见原因是多人重复看同一条内容。明确每个角色只看自己负责的维度，是控制工时的关键。
| 角色 | 复核职责 | 复核维度 | 工时占比参考 |
|---|---|---|---|
| 需求分析 | 初筛、条目完整性、前后一致性核对 | 结构、表述、与已有需求的关系 | 通常最高，覆盖全部条目 |
| 业务方 | 业务规则、优先级、边界条件确认 | 业务正确性 | 中等，只覆盖业务相关条目 |
| 测试 | 验收条件是否可验证、场景是否覆盖 | 可测性 | 较低，聚焦验收条件 |
| 开发 | 技术可行性、依赖与约束识别 | 可实现性 | 较低，聚焦技术风险条目 |
避免重复复核的机制可以落在流程上：需求分析初筛通过后，条目才进入业务确认；业务确认完成的条目才进入测试与开发复核。每一环节记录复核结论与问题类型，后一环节只关注本维度问题，发现前序维度的问题时退回而不是自行修改。这样每个角色的工时可以独立统计，也便于定位哪一环节是工时主要消耗点。
在工具承载上，ONES的需求条目与工作项可以作为复核台账，复核结论、问题类型、返工记录随条目留存；ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能基于项目与知识上下文回答需求相关问题，输出过程可追踪、结果可审计，便于把复核动作与需求状态变化对应起来。复核记录字段与抽样配置的具体形式，建议在选型时结合团队流程向厂商确认。
哪些因素会让复核成本波动
同样的公式，不同团队算出的单件工时可能相差数倍。识别敏感因素，有助于判断估算区间该放宽还是收紧。
- AI输出质量：输出越贴近团队的需求模板与术语习惯，单件复核工时越低；输出结构混乱时，复核者需要先整理再判断，工时上升明显。
- 需求复杂度：涉及多系统交互、复杂业务规则的需求，单件复核工时可能是简单需求的数倍，估算时宜按复杂度分层取不同单件工时。
- 需求变更频率：迭代内需求频繁变更，返工系数上升，复核工时随之放大，因为已复核内容需要重新确认。
- 复核人员熟练度：熟悉业务与AI输出特点的复核者，判断更快、误判更少；新人复核工时偏高，且容易产生二次复核。
- 模板成熟度：检查清单与需求模板越成熟，复核越接近逐项核对，工时更稳定、更可预测。
- 下游缺陷代价：缺陷代价越高，覆盖比例越倾向于调高，复核工时相应增加，这是主动选择而非浪费。
这些因素中，需求复杂度与下游缺陷代价影响最大，建议在估算表中按需求分层设置参数，而不是全团队用同一个单件工时。
复核数据从哪里取、怎么记录
估算要能复算和迭代，前提是每次复核都留下结构化记录。取数来源主要有三处：复核记录表、评审纪要、需求条目台账。三者按需求条目编号关联，就能还原每条需求的复核路径与耗时。
| 必录字段 | 用途 |
|---|---|
| 复核对象量（按角色分别记） | 计算覆盖比例与总工时 |
| 单件复核工时 | 校准单件工时参数 |
| 覆盖比例与抽样规则 | 区分抽样与全量，评估漏检风险 |
| 发现问题数与问题类型 | 计算返工系数，定位高发问题 |
| 返工工时 | 验证返工系数假设是否合理 |
| 下游阶段需求类缺陷数 | 判断漏检情况与覆盖比例是否足够 |
校准节奏建议按迭代或季度进行：每个迭代结束后，用实测的单件工时和返工系数替换估算表中的假设值；每季度回顾一次覆盖比例与漏检缺陷的关系，决定是否调整抽样策略。参数连续两个周期保持稳定，说明估算口径已经可用。
判断复核成本是否合理，可以看三个信号：一是复核投入占需求阶段总投入的比例是否在团队可接受范围内，比例过高说明复核范围或单件工时需要优化；二是单条需求复核工时是否稳定，波动过大往往意味着分层参数没有设好；三是漏检问题在后续阶段造成的返工工时是否被有效压低，如果下游返工持续偏高，说明覆盖比例或抽样规则需要上调。三个信号结合看，比单看总工时更能说明复核投入是否花在了该花的地方。
常见问题
团队第一次做复核估算，没有历史数据怎么办？
先用假设值起步，但要在估算表里明确标注哪些是假设。单件复核工时可以参考团队过去人工评审类似条目的经验，返工系数先取一个区间（例如10%至30%），覆盖比例按当前策略填写。运行一到两个迭代后，用复核记录中的实测单件工时和返工系数替换假设值，再对比估算与实际的偏差。第一次估算的用途是建立基线，不必追求准确。
抽样复核后下游缺陷上升，应该直接改成全量吗？
先判断缺陷集中在哪类需求上。如果漏检集中在高风险或跨系统条目，说明抽样规则没有覆盖重点，调整分层规则、提高高风险层比例即可，不必整体改为全量。如果漏检分散在各层且比例明显上升，说明当前抽样比例偏低，可先上调比例观察一个迭代。全量复核是成本最高的选项，适合对外交付、合规相关或下游返工代价明显高于复核工时的场景。
评审会议工时应该算进单件复核工时还是单列？
两种做法都可以，关键是全团队统一且不重复计算。单列的好处是会议成本可见，便于判断会议是否过多；折算进单件工时的好处是公式更简洁。如果会议按迭代固定召开、参与人数稳定，建议单列一笔固定工时；如果会议按条目临时召集，折算进单件工时更贴近实际。无论哪种方式，都要在估算口径表中写明。
复核记录应该由谁维护，记录粒度要多细？
通常由需求分析角色牵头维护，因为初筛环节覆盖全部条目。记录粒度以能复算为准：按角色记录复核对象量、单件工时、覆盖比例、发现问题数与返工工时，下游阶段的需求类缺陷数可按迭代汇总。粒度过细会增加记录负担，反而推高复核成本；粒度过粗则无法校准参数。建议先按迭代记录，稳定后再考虑是否需要按需求分层细化。
ONES 能承载复核记录和工时统计吗？
ONES 的需求条目与工作项可以作为复核台账，复核结论、问题类型与返工记录随条目留存。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能基于项目与知识上下文回答需求相关问题，输出过程可追踪、结果可审计。复核记录字段、抽样比例配置与复核工时统计的具体形式，现有资料未逐一说明，建议在选型时结合团队流程向厂商确认。
