第3章：前置输入物的分析与结构化

3.1 适用场景

本章适用于以下两类典型场景：

• 项目启动期：在完成初步需求收集与技术选型后，需将零散的需求描述、架构草图、历史人力数据与当前团队配置整合为统一的估算输入物。
• 估算复审期：当项目范围发生变更（如增加新模型、调整接口协议）时，需要重新校验输入物的完整性与一致性，避免因输入失真导致估算偏差超过±30%

3.2 前置条件

1. 项目需求文档：已通过至少一次非正式评审，包含功能需求、非功能需求（性能、延迟、准确率）以及验收标准。
2. 技术架构草稿：已经过架构师确认的初版系统分层图（数据层、模型层、服务层）、关键组件（数据管道、模型推理引擎、API网关）以及候选技术栈。
3. 历史数据：至少包含3个同类AI项目的实际资源投入记录（人天、GPU小时、存储量、标注成本）。
4. 人力配置信息：当前团队角色矩阵（算法工程师/后端工程师/数据标注员/项目经理）、可用工时、技能等级。

3.3 操作步骤

按以下四步完成前置输入物的分析与结构化：

1. 拆解需求文档：按功能模块将需求拆分为原子估算单元（一个原子单元对应一个可独立交付的AI能力，如“中文情感分类”“PDF表格提取”），每个单元标记复杂度等级（L1-L5）与数据依赖（标注数据量/合成数据策略）。
2. 映射架构草稿：将技术架构草稿中的每一层（数据处理→模型训练→模型部署→监控反馈）与步骤1的原子单元对应，标记出各层的吞吐瓶颈（如推理QPS上限、训练数据IOPS）。
3. 匹配历史数据：从历史数据库中检索与当前原子单元相似度>80%的历史任务，提取其人天/GPU小时/标注人时三元组，并记录偏差系数（如同一任务在Pytorch与TensorFlow间的算力消耗差异）。
4. 校准人力配置：根据当前团队角色技能矩阵与可用工时，对历史三元组进行人力效率系数调整（例如资深工程师效率系数1.0，初级工程师取0.6）。

{
  "unit_id": "NLP-003",
  "name": "中文情感分类",
  "complexity": "L3",
  "data_strategy": "标注+合成",
  "estimated_data_volume": 50000,
  "architecture_layer": "model_training",
  "bottleneck": "GPU_memory_24GB",
  "history_ref": [
    {"task": "情感分类_v2", "person_days": 45, "gpu_hours": 480, "label_hours": 600},
    {"task": "情感分类_v1", "person_days": 72, "gpu_hours": 720, "label_hours": 900}
  ],
  "efficiency_coefficient": 0.85
}

3.4 输入输出物

3.5 责任边界

• 项目经理（PM）：负责组织需求拆解会议，确认原子估算单元划分符合WBS原则，并审核效率系数的合理性。
• 技术负责人（TL）：负责从技术架构草稿中提取层间依赖关系与吞吐指标，并归档到映射矩阵。
• 数据负责人（DL）：负责从历史数据中检索同类任务并计算偏差系数，需在输出文档中注明数据来源版本。
• HRBP：提供当前团队成员的技能等级与可用工时占比，并更新效率系数表中的默认值。

3.6 记录材料

本章需产出的记录文件（均保存于项目共享目录下）：

1. 原子估算单元清单（Excel/JSON格式）：包含单元ID、名称、复杂度、数据依赖、优先级。
2. 分层-单元映射矩阵（Mermaid图表或表格）：展示技术架构层与原子单元的对应关系及层间数据流。
3. 历史数据相似性匹配表（CSV）：记录历史项目ID、相似度得分、三元组原始值与偏差系数。
4. 效率系数调整矩阵（JSON/YAML）：按角色和技能等级列出调整因子，需HRBP签字确认。

3.7 异常处理

3.8 验收标准

1. 完整性：原子估算单元清单覆盖需求文档中所有功能点，每个单元均有复杂度标记与关联的架构层ID。
2. 一致性：分层-单元映射矩阵中的层间数据流方向与架构草稿完全一致，且吞吐瓶颈指标有实测或权威基准来源。
3. 可追溯性：历史数据相似性匹配表中每一条记录都能追溯到原始项目ID与数据版本，偏差系数计算过程可复现。
4. 审批通过：PM、TL、HRBP三方在效率系数调整矩阵上签字（或电子签章）确认。