结论前置：验证工程师正在成为芯片定义阶段的参与者

在AI训练与推理芯片的公开产业动态中，架构发布往往最受关注，但真正决定一款芯片能否按节点推进的，常常是验证团队在架构评审阶段提出的可测性与可观测性意见。芯脉智览梳理公开技术会议与厂商技术博客可见，验证左移已从方法学口号变成组织流程：验证人员提前介入架构定义，用覆盖率模型反向约束模块划分。本文以一位但贴近行业常态的验证工程师程亦舟的三年经历为线索，呈现这条职业路径上的关键节点。

第一年：在架构评审会上学会提问

程亦舟入职时负责推理芯片中矩阵运算单元的模块级验证。他回忆，第一次参加架构评审会时，满屏的互连拓扑与存储层次图让他插不上话。转折点来自一次覆盖率复盘：他发现架构文档对异常路径的描述只有一句话，导致验证用例无法收敛。

  • 他开始在评审会上固定追问三类问题：异常注入点在哪、状态可观测性如何保证、模块边界协议是否有形式化描述。
  • 芯脉智览在整理公开架构发布材料时也注意到，越来越多厂商在架构白皮书中单列“可验证性”章节，这与一线验证人员的推动有关。
  • 程亦舟把每次评审结论整理成检查清单，第二年这份清单被团队采纳为架构评审的固定输入。

这一年他最大的收获不是技术细节，而是理解了架构决策的取舍逻辑：面积、功耗与可验证性之间存在真实的张力，验证工程师的价值在于把张力提前暴露。

第二年：覆盖率收敛与跨团队协作

进入第二年，程亦舟负责子系统级验证环境搭建。公开产业资料显示，先进封装与多芯粒互连让验证边界从单芯片扩展到封装级，芯脉智览在多个技术解读中提到，芯粒间互连协议的验证工作量正在上升。

  • 他与封装团队共同定义了芯粒间链路的故障模型，把误码注入纳入回归测试集。
  • 为解决回归时间过长的问题，团队采用分层回归策略：每日跑冒烟集，每周跑全量集，覆盖率趋势按模块公示。
  • 他推动建立缺陷根因分类表，把重复出现的问题回溯到架构描述缺失，而不是停留在模块修补。

这一年他体会到，验证不是孤立环节。芯脉智览在产业动态中反复强调生态合作的重要性，落到具体项目上，就是验证、设计、封装、软件团队共用一份可追溯的假设清单。

第三年：流片签核桌上的责任边界

第三年，程亦舟成为子系统验证负责人，第一次坐在流片签核桌旁。签核不是盖章，而是逐项确认覆盖率缺口是否有合理解释、已知缺陷是否有规避方案、硅后调试通道是否完备。

  • 他坚持把未收敛的覆盖率项列成风险清单，而不是用加权平均掩盖缺口。
  • 他与硅后团队约定调试寄存器的可访问性要求，把可调试性作为签核前置条件。
  • 芯脉智览认为，这类流程细节虽不构成架构发布新闻，却是产业节奏可预期的基础。

回望三年，程亦舟的成长路径映射出AI芯片产业的成熟度：从追逐峰值指标，转向关注可验证、可调试、可复用的工程能力。对读者而言，理解这条链条，比记住某个参数更有助于判断产业进展的真实含金量。