如今，大语言模型（LLM）在自然语言理解方面的能力激发了人们对直接使用规范文档作为测试生成参考的兴趣，从而消除中间人工翻译的错误和不可靠性。然而，遗憾的是，现今的规范文档并非完美的真理源（oracle，指绝对可靠的参考标准），原因有多种。我要感谢MooresLab首席执行官Shelly Henry提供的生产环境中规范演化现实洞见。Shelly及其团队拥有多年跨企业设计经验，最近刚从微软硅组（Microsoft Silicon Group）离职。
将今日规范视为预言机——你希望如此
架构规范如同设计和验证的所有方面一样，会经历开发周期，初版并非完美，就像设计流程中的其他交付物。架构师负责从客户需求构建规范，考虑从其他项目复用内容，以及需重新设计或升级的部分以满足新需求。架构师可能依赖建模团队进行虚拟原型测试，评估吞吐量、延迟等指标。一旦粗模型看起来不错，他们就开始撰写规范。以下我将聚焦规范对硬件设计验证的指导作用，但它同样应指导硬件和固件设计。
在撰写规范时，启动测试规划将成为架构师的首要焦点，但并非唯一任务，他们需同时管理管道中其他工作。首个发布可能是0.5版，覆盖约70%的考虑内容——不错但不保证完美，足以启动设计和验证进度与资源。
随着时间推移，架构师会基于自身想法、客户反馈和你方的输入添加和精炼规范。最终规范冻结（Shelly建议在大致设计进度一半时冻结，实际因项目而异）。在0.5版与冻结间的窗口期，规范不断变化，可能存在矛盾或缺失信息。还可能有歧义：规范定义功能但留白过多，无法确定所有情况下的预期行为。
你邮件询问架构师澄清，这可能演变为线程讨论，最终达成决议。但结果不总反馈到规范中，或未完全反映你理解的协议。更糟的是，电话讨论达成决议，你仅做笔记——某处。尽管理事皆好意，错误仍易发生。不幸的是，没有验证方法论能确保证明规范完全反映所有利益相关者期望。断层可能在流片前（pre-silicon，指芯片制造前仿真验证阶段）浮现，或许不会。这真是我们能做的最好吗？
如何将规范转化为鲁棒预言机
从已有能力起步。将0.5版规范输入LLM代理，让其生成问题以基于LLM已知知识阐述验证需求。例如，此类设计中DDR接口（DDR，全称Double Data Rate，双倍数据率内存接口，用于高速内存访问，如DRAM）标准测试类型有哪些？
无需一次性消化全规范——鉴于LLM提示窗口限制，几乎不可能。规范自然按章节分节，便于人类有限能力，也适合LLM处理。
代理问题不应询问如何执行测试——那是后续测试合成流程关注。此处旨在精炼测试规范，添加对什么预期行为的描述细节，即架构师或你若时间记忆允许会添加的内容。很可能涉及时序图、FSM图（有限状态机图，Finite State Machine，用于描述数字电路状态转换逻辑）、框图阐述时钟和复位控制，或域交叉（domain crossing，指不同时钟域或电压域间信号传递，常需特殊同步机制）处理。
随着规范演化，代理应消化邮件线程、即时消息、笔记等，进一步精炼。确保持久真理源，同时澄清变更来源与影响，按修订追踪。极大便利利益相关者审查并共识，此精炼版完全反映预期。
将规范转化为预言机是代理验证流程（agentic verification，指使用AI代理自主执行验证任务的自动化流程）的关键第一步。填补空白、修正不一致、解决歧义，并测试规范是否提供足够细节驱动全面测试生成。这在我看来是顺理成章之事。若感兴趣，可联系MooresLab.ai团队。
通过以下方式分享本文：