华为 AI 研发体系案例

所属： 应用层。本页边界： 研发数据、代码上下文、工具和 Agent 怎样形成案例中的工程闭环。

#核心案例关系

研发任务 → 模型与工具轨迹 → 测试/环境反馈 → 按失败原因回流到对应技术层。

这是一条案例中的反馈链，不是数学公式；反馈只有经过外部验证和错误归因后，才适合作为改进数据。

#符号说明

后文的条件概率用于说明归因边界，不表示这些变量相互独立。

#技术要点

• 案例中的数据飞轮对应数据治理层。
• CodeAgent 对应工具调用、状态和验证循环。
• 知识工程对应 RAG/上下文构建。
• 材料的效果主张应与独立实验结果区分。

#原理与演进

#将所附架构图还原为技术因果链

#研发场景中的一次闭环

1. 代码、设计文档和故障记录经过权限控制后成为检索证据。
2. 用户提出研发任务；模型检索上下文并生成候选修改或解释。
3. 工具运行静态检查、测试或仿真，给出外部可观察结果。
4. 错误样例回流为改进数据；是否训练权重，取决于问题是知识缺口、工具问题还是模型行为问题。

判别边界： 架构图说明模块关系，不足以证明某具体产品具备全部能力或达到某指标；需要独立实验和可复现数据支持效果主张。

#1. 这是案例映射，不是另一套技术原理

图中“基础设施、数据治理、训练推理、模型资产、模型增强、服务、应用、横切体系”与总览一一对应。本页只讨论研发任务如何穿过这些层；公式、算法推导仍由各层页面维护，以免同一知识反复写出不一致版本。

研发资料中的“代码、文档、缺陷单、测试结果”来源与时间各不相同。代码仓库当前版本与故障发生时版本若不一致，检索可能给出过时解释；因此知识库索引必须绑定代码版本、分支、提交、权限和文档时间。

#2. 一个代码问题的证据闭环

用户问题 → 仓库/文档权限过滤 → 代码检索与依赖定位 → 模型生成假设 → 工具运行测试/静态检查 → 根据真实结果修正 → 输出带证据的结论。

这个闭环的关键不是“模型能写代码”，而是每一步有不同的证据强度。检索命中只是候选，模型解释是假设，测试通过是对部分行为的验证；测试覆盖不全时仍不能证明所有路径正确。

#3. 研发数据飞轮的条件

任务轨迹可生成改进样本，但“成功轨迹”若未经验证直接入 SFT，会把偶然正确或伪通过写进模型。可将失败分为：检索漏召回、上下文选择错、工具参数错、代码推理错、测试不足、权限限制。不同原因对应不同层改进，不一定都需要微调。

形式化地，观测到成功率 $P(S)$ 并不能直接归因于模型权重 $W$；实际是 $P(S\mid W,D,R,T,E)$，其中 $D$ 是数据、$R$ 检索、$T$ 工具、$E$ 执行环境。要声称某一环节带来增益，需控制其余条件并做消融。

#4. 图中各模块不是独立流水线

训练后的模型版本影响检索重排与工具选择；工具失败样例会回流到数据层；服务层延迟决定 Agent 允许多少步；安全权限限制可用证据；评测需要固定仓库版本与测试环境。各机制的定义与推导以所属模块为准，本页只解释这些跨层反馈。

本案例的最小评价集合：任务完成率、测试通过率、人工复核通过率、代码变更范围、检索引用正确率、token/时间成本、权限事件。所附架构材料若未提供可复现的分母、任务集与对照组，应只视为架构主张，而非效果证据。