企业官网建设流程全解析

干验证这一行十几年，踩过最大的坑往往不是代码写不出来，而是项目开工前没把“要验什么”想清楚。SoC 模块验证尤其如此——今天手机、汽车、IoT 设备里的芯片几乎全是 SoC，模块数量动辄几十上百，每个模块挂在总线上，中断、时钟、复位、寄存器配置、低功耗状态转换全都要照顾到。如果上来就闷头写 UVM 环境，大概率要走弯路。这篇想认真聊聊一份真正能落地的 SoC 模块验证规格说明（Verification Specification Template）该怎么写：它到底解决什么问题、包含哪些硬性模块、怎么写才不流于形式，以及适合哪些人来参考。文中的模板骨架和踩坑记录，都是我在真实项目里反复迭代过的。

1. 为什么说模块验证规格说明是整个验证流程的“地基”

1.1 那些“裸奔”的验证项目，最后都怎么了

我见过不少验证团队，拿到模块设计文档就开始写 testbench，甚至还有人连设计文档都懒得细读，直接对着 RTL 端口猜功能。表面上看效率很高——别人还在写文档，你已经跑起了仿真。但等你进入覆盖率分析阶段，问题就全冒出来了：功能覆盖点东一个西一个，没有和测试用例对应；某个边界条件可能测了十遍，另一个关键场景从来没触发过；设计改了一版接口，验证环境跟着大改，却没人记得当初哪些用例是针对旧接口写的。

我从前接手过一个 DMA 控制器的模块验证，前一位同事搭了一套完整的 UVM 环境，跑得挺顺，回归也一直是绿的。但交付前 QA 问了一句：AXI 总线的 outstanding 传输和 DMA 描述符异常这两个场景的组合，你们验证过吗？现场一片安静。翻遍环境，发现场景列表确实是凭感觉写的，没有任何一份文档能证明“这个模块的功能都被覆盖到了”。最后加班补测试，项目延期两周。所以我现在定了个规矩：动手搭环境之前，先写验证规格说明，验证规格没说清楚的部分，测试用例里不许出现。

SoC 的模块验证比普通 IP 验证更尴尬。模块本身只是 SoC 里的一个零件，真正的风险往往发生在模块之间的交互上。你的模块对中断、时钟门控、低功耗状态的处理方式，决定了它挂到子系统里会不会成为“拖后腿”的那个。没有规格说明，这些交互场景非常容易被遗忘，而一旦遗忘，代价往往要等到 SoC 集成阶段才集中爆发，那时候定位和修改的成本已经高得吓人。

1.2 验证规格说明到底在解决什么问题

验证规格说明不是“计划文档”，它是验证团队和设计团队、架构团队之间的一份契约。它回答四个核心问题：验什么（scope）、怎么验（approach）、验到什么程度算完（criteria），以及谁对验证结论负责（ownership）。这四个问题说不清楚，后面所有投入都可能白费。

第一，它强制你把模块功能点拆成可验证的清单。人的大脑不适合记住几十上百个功能点，但一张表格可以。第二，它让验证环境的设计有了依据。UVM 环境里每个 agent、每个 scoreboard 该验什么、该长什么样，都是从规格说明的功能点推导出来的，而不是拍脑袋想出来的。第三，它是交接的核心资产。SoC 项目动辄几百人协作，模块验证工程师中途换人是常态，一份写清楚的规格说明能让新人三天上手，否则三周都未必能进入状态。

我经常跟团队说一句话：验证规格说明写得越细，后面的代码反而写得越少。因为你在文档阶段已经把场景、边界、优先级都过滤了一遍，写测试用例基本就是填空。反过来，规格写得含糊，代码阶段一定会反复返工，省在文档上的时间，最后都会加倍还给调试和补测。

1.3 这份模板适合谁、在哪个阶段介入

如果你是刚入行的验证工程师，可以从这份模板学习“验证思维”——不是急着调仿真器，而是先学会把“验什么”翻译成“怎么写用例”。如果你是有经验的 DV 工程师，这份模板能帮你躲开文档盲区：版本管理、评审记录、范围豁免，这些细节决定了文档在项目末期还能不能当证据用。如果你是验证负责人或项目 leader，这份模板就是你组织评审、分配任务、确认签核标准的抓手。

从阶段上看，理想的介入点是模块设计规格（Module Design Specification）冻结前后，最晚不要晚于 testbench 开始搭建之前。太早写，模块功能都没定，写了也是废纸；太晚写，规格说明就失去了指导作用，只能沦为项目末期补的“形式文档”。我自己的经验是：设计 specs 一到手，先花一两天把功能树和验证范围的初稿拉出来，等 RTL 接口稳定后再细化。这样既能赶上工程节奏，又不会让文档从一开始就脱离实际，两头都不耽误。

2. 核心结构：一份能直接落地的模板骨架

2.1 文档头与版本管理——别小看这一页

先说最容易被忽视的部分。我见过太多规格说明，正文写得不错，但文档头只有一句话加一个作者名。等到项目后期，设计改了三轮，评审意见撒了一地，谁也说不清当前这版到底对应哪个 RTL 版本。所以文档头必须包含：文档编号、项目名称、模块名称、作者、评审人、批准人、版本号、修订日期和修订内容。这些信息看起来琐碎，但每一栏都在将来的某个评审节点上救过我的命。

修订历史尤其重要。哪怕是你一个人维护的文档，两个月后回来看，如果没有修订记录，你根本不知道上一版改了哪些内容、为什么改、是否已经同步给设计团队。这在设计变更频繁的 SoC 项目里几乎是致命伤，所以我一直要求团队把修订记录当成核心内容来维护，而不是顺手写两笔了事。

下面是我常用的版本记录表格样式：

这个表里的关键是“修订内容”一定要具体，比如“更新接口表”“新增 P1 用例”，而不是写“修改格式”“更新排版”。否则这个表就没有追溯价值，填得再勤也只是一堆没有信息量的流水账。

2.2 模块概述、接口与时钟复位——先讲清楚 DUT

模块概述这一节，不是抄设计文档的摘要，而是站在验证视角来描述：这个模块负责什么、行为边界在哪里、有哪些关键接口和配置项。举个例子，如果你验的是一颗 GPIO 控制器，概述里要写清楚支持多少路 IO、每个 IO 可配置的方向、上下拉、中断模式，以及它挂在哪个总线上、由哪个时钟域驱动。这些信息决定了验证环境的规模和复杂度，也直接影响测试用例的裁剪。

接口信息建议用一张表列全：接口名、方向、协议类型、时钟域、位宽，以及和 SoC 互联的关键信号别名。SoC 里的模块几乎都挂在 AXI、AHB 或 APB 上，还有自己的控制信号和中断输出。接口没列清楚，后面写 agent 基本就是猜，猜出来的 agent 协议行为跟真实总线不完全一致，后续集成阶段肯定出幺蛾子。

时钟和复位是 SoC 模块验证里最容易出事故的环节。规格说明需要明确：模块有哪几个时钟域、时钟频率和来源（PLL 分频还是外部直供）、是否有门控时钟、复位源有几路、复位释放后的行为顺序是什么。很多同学只惦记功能验证，忘了验证复位行为和时钟域交叉（CDC），结果模块在 SoC 集成时因为复位或跨时钟域问题翻车。这些内容必须在规格里留足位置，宁可多写也不要漏写，因为在芯片级联调阶段，这些问题一旦暴露就是大改。

寄存器列表也一样，不要复制整页寄存器表格进来，只列出和验证强相关的配置项：控制寄存器每个 bit 的作用、状态寄存器的置位和清除机制、中断使能与状态。这些信息对写寄存器模型（RAL）和断言都至关重要，缺一个后面补起来都很痛苦。而且记录这些配置项的价值不仅在于实现寄存器模型，更重要的是让验证工程师在评审时能确认“我对寄存器的理解跟设计一致”。

2.3 验证范围划分：测什么、不测什么

很多规格说明死在“范围不清”上。范围写得模棱两可，最终结论一定被挑战：你说验证完了，凭什么？所以我的做法是分成 In Scope 和 Out of Scope 两栏。

In Scope 写明本模块验证会覆盖的功能域，比如：接口协议符合性、数据通路功能、寄存器读写、中断产生与清除、错误处理与恢复、可配置参数覆盖、复位与低功耗相关行为。Out of Scope 则要写得非常具体：模拟和混合信号行为（由 AMS 团队负责）、DFT 逻辑、时序收敛与功耗分析、系统级软件交互（属于 SoC 集成验证阶段）。如果是和芯片启动相关的模块，比如 boot ROM 控制器，还要特别写清楚启动序列的验证责任边界——本模块验证到哪一步，哪些留给 SoC 级软件验证，这一步不写清，后面扯皮是必然的。

Out of Scope 写清楚还有一个额外的好处：防止验证范围无限膨胀。做验证的人都有体会，项目后期总有人提“顺便把这个也验一下”。如果规格说明里已经明确写了哪些内容不在范围，你可以有理有据地说“这个需要在 SoC 顶层验证，模块级环境覆盖不到”。这不是推卸责任，而是保护验证边界，避免模块级验证变成什么都想管、什么都管不透的四不像，最终丢了真正的重点。

2.4 验证环境架构说明——给后续评审留一张地图

环境架构这一节，强烈建议用一张框图加一段文字描述。框图不要求画得多精美，但一定要表达清楚：DUT 周围有哪些 agent（比如 AXI master agent、APB slave agent、时钟和复位 agent），哪些是主动激励（driver/sequencer），哪些只做被动监听（monitor），参考模型（reference model）和记分板（scoreboard）怎么和 DUT 做数据比对。这样的一份描述，相当于给整个验证环境画了一张“地图”，评审时大家才能对着同一个图说话。

然后逐个组件写清楚职责。比如参考模型：它是用行为级代码模拟 DUT 的预期行为，还是用一个简化的响应模型？比对策略是逐周期对齐（cycle-accurate），还是逐事务比较（transaction compare）？这两种方式的适用场景完全不同，写清楚就能避免实现阶段大量返工。还有寄存器模型（RAL）的使用方式、虚序列（virtual sequence）的调度策略、覆盖率在哪里采集，都应该在这一节说明。不要觉得这些细节“到时候再说”，环境搭起来之后再说，成本差十倍。

这些内容会让规格说明比“标准模板”长出一截，但正是这一截，决定了你的验证环境是不是真正可复用的。在 SoC 项目里，模块级验证环境最好能通过层级化复用（hierarchical reuse）直接挂到 SoC 级别环境里。如果架构说明里没有提前规划，后面想复用基本没戏，等于整个模块验证环境重新写一遍，这不光是浪费人力，还会因为两套环境不一致带来额外的对齐成本。

3. 从功能点到测试用例：验证计划怎么写得有可执行性

3.1 功能点拆解：从一个功能树开始

写测试计划之前，强烈建议先做一件事：把模块功能拆成功能树。根节点是模块，下一层是功能大类，再下一层是具体的功能点和边界条件。这一步做好了，后面所有测试用例和覆盖点都是树的叶子，逻辑关系清清楚楚，评审的时候也能顺着树从头到尾捋一遍，看有没有漏分支。

以 UART 模块为例：功能大类包括发送通路、接收通路、波特率配置、FIFO 管理、中断管理、错误检测。每个大类再往下拆：发送通路里，有起始位、数据位、校验位、停止位的组合，不同数据位宽（5 到 8 bit），FIFO 空和满时的暂停行为；接收通路的边界条件包括溢出错误（overrun）、奇偶校验错误、帧错误、断线检测。这些叶子节点就是后续测试用例的原型。

功能点拆解的颗粒度，我的经验是两个标准：拆到能写出唯一的测试用例为止；拆到能对应唯一的覆盖点为止。如果发现一个功能点下面还要写三个测试用例才能覆盖不同场景，那说明拆得还不够细，需要继续往下拆。反过来，如果两颗“功能点”其实只能写同一个测试用例，它们就是重复的，合并掉，别让功能树里堆一堆没区分度的名字。

3.2 测试用例表：优先级、场景、预期结果的组合

测试用例不是“写一个发送数据的 test”这么简单，而是把每个功能点翻译成具体场景：激励怎么产生、配置怎么设置、预期行为是什么。表格列建议这样设计：用例 ID、关联功能点 ID、用例名称、场景描述、激励要点、配置项、预期结果、优先级、覆盖点映射。实际填表的时候，前面几列花不了多少时间，真正费时间的是“场景描述”和“预期结果”这两列，它们才是测试用例的灵魂。

下表是精简后的样式，实际使用时可继续扩展激励要点、配置项、预期结果、覆盖点映射等列：

优先级尤其重要。P0 是冒烟测试和主干功能，必须最先跑；P1 是主要功能，回归必跑；P2 是边界和异常场景，资源够就该都跑；P3 是 corner case 和压力场景，按资源斟酌。如果不把优先级定义写清楚，最后必然出现所有人把每个用例都当 P0 对待的尴尬局面——回归时间失控，谁也不敢删用例，每天被漫长的回归跑批拖死，正经的调试时间反而被挤占。

3.3 覆盖率计划：功能覆盖点与交叉覆盖的定义

覆盖率计划是验证规格说明里最有含金量的部分。很多团队的覆盖率是测试写完之后“顺便”加的，结果就是覆盖率报告很漂亮，但证明不了什么——点加了一堆，跟功能点完全对不上。我的做法是在写测试用例的同时就把功能覆盖点（Functional Coverage Point）定义出来，每个覆盖点绑定一个或多个功能点，保证“测了什么一定有对应的覆盖点，覆盖到了什么一定有理有据”。

还应该设计交叉覆盖（cross coverage）。还是用 UART 举例：波特率（9600、115200、921600）× 数据位宽（5、6、7、8）× 校验模式（无、奇、偶）就是一个典型的 cross 定义。它保证你不只是在一个默认配置下测功能，而是真正覆盖了配置组合空间。这类 cross 定义数量不用贪多，挑真正影响行为的组合维度就好，否则覆盖率收集和报告分析的时间会成倍增长，跑完根本来不及仔细看。

这一节也可以把代码覆盖率的收集需求写进去：跑哪些用例需要开启行、分支、条件、FSM 覆盖率收集，哪些模块内部的冗余分支可以申请排除（exclusion）。提前和设计团队协商 exclusion 清单，比事后解释快得多。覆盖率收集本身不是目的，它是验证完整度的度量手段，收集开关开得越晚，越容易发现关键场景没跑到，到时候补测的窗口已经所剩无几。

3.4 断言与形式化验证计划

断言（SVA）的规划也应该在规格阶段完成，而不是等 RTL 写完了再临时加。先想清楚协议里哪些规则必须用断言盯着：握手信号不能乱拉、状态机不允许跑进非法状态、FIFO 的读写指针不能越界、中断产生后必须保持到被清除等等。把这些规则列成一张断言清单，标注预计位置：是内联在 RTL 里、用 bind 方式挂到模块上，还是在接口 agent 里用协议检查器（protocol checker）实现。原先没规划过的断言，基本都会在加的时候跟原有代码纠缠不清。

这里要提醒一句：断言不是装饰品，它最大的价值是帮你定位 bug 发生的精确时间点。一条放对位置的断言，可以把调试时间从几天压缩到几小时。我见过一条断言在回归里抓住一个只会在特定 burst 长度下出现的时序错误，要是没有它，那个 bug 可能要等 SoC 集成后才会被下游模块暴露出来，到了那一步，定位范围是整个芯片，想死的心都有。

形式化验证（FPV）适合验证那些状态空间小但逻辑关系严格的控制逻辑：仲裁器、状态机、FIFO 控制、总线接口的时序规则。规格说明里可以标出哪些功能点计划用形式化方式覆盖，哪些用动态仿真。提前写清楚，后面选择验证方法时就不会瞎折腾，也能更合理地分配人力——形式化工程师和仿真工程师各自领任务，而不是等到半路才互相扯皮“这个该你验”。

4. 实操过程：从模块需求到一份可评审的验证规格

4.1 第一步：通读设计文档，建立功能树

拿到模块设计文档后，第一件事不是读代码，而是用思维导图或表格把模块功能树画出来。边读边记，看到任何一个“支持某种模式”“产生某种中断”“在某种条件下表现某行为”的表述，都丢进功能树。认真读完一整份设计文档，功能树基本就有影了。这个习惯我坚持了很多年，几乎没有一次白费功夫。

这里有个细节：设计文档里经常出现“该模块与 DPRAM 交互实现数据缓存”这类描述。不要照抄，你要追问的是：验证这个交互，需要模拟 DPRAM 的哪些行为？是真实时序还是简化模型？这些决策属于验证策略，不属于设计文档范畴，要靠你自己判断并写进规格说明。我记得第一次处理这类问题时，我照搬了完整 DPRAM 时序模型，结果仿真速度慢得难以接受，后来改成行为级简化模型，速度和精度都达到了理想平衡。

如果设计文档还不完整，怎么办？我建议主动约设计工程师聊半小时，把疑问点列出来。验证工程师经常犯的错是闷头猜，猜对了算运气，猜错了整个环境白搭。问清楚一句话，胜过回来改三天代码。别不好意思问，验证阶段不问清楚，到了项目末期才暴露问题，那才叫真正的尴尬。

4.2 第二步：画验证环境框图，明确组件职责

功能树有了，下一步画验证环境框图。这个图可以先画在纸上或白板上，边画边想：这个功能点谁来激励？谁来检测结果？参考模型需要模型化哪些行为？覆盖点放在哪个组件里采集？这些问题在画图的过程中会自然浮现，比闷头写代码时发现缺组件再补，效率高太多了。

拿一个挂在 APB 总线上、内含配置寄存器和数据通路的模块举例：APB agent 负责时序激励和协议检查；配置寄存器统一由 RAL 模型管理；DUT 的输出通过 monitor 送到 scoreboard；参考模型读 RAL 里的配置值，生成预期响应。这张图画完之后，环境的可复用性一眼就能看出来。如果一个组件职责过多，别硬塞，拆成两个更小的组件，后续代码实现会轻松得多，调试时定位问题也更直接。

框图画好之后，建议顺手把环境组件清单和职责列表写进规格文档。这一步只花半小时，但能让你在代码评审时少费很多口舌——别人不用追着问“这个 agent 是干嘛的”。评审过太多环境代码，最大的痛点就是组件职责边界模糊，谁都能改一下、谁都不清楚改动的副作用，有了一份职责清单，至少能收敛住这种混乱。

4.3 第三步：逐点填写测试计划表

环境框图确认后，回到功能树，开始逐点填写测试计划表。这一步别图快，一天填不完就分两天。填的过程中你会自然发现很多功能点之间的组合关系，这些组合往往就是 cross coverage 的来源。很多人把测试计划当成写完了代码之后补的表，这个顺序反了——先有计划再有代码，代码才不会变成一团乱麻。

填表时我有个习惯：把每个用例的“预期结果”写得特别具体。比如“发送 100 字节，校验正确，产生发送完成中断，状态寄存器里的 FIFO 计数归零”。预期结果写得含糊，scoreboard 就写得含糊，覆盖率也就会含糊。从规格层面把预期结果定清楚，代码实现的顺畅程度会超出你预期。这句话我跟团队复述过很多次，每个把预期结果写满的人在实现阶段都回来谢过我。

填完测试计划，建议顺手做一次自查：每个功能树叶子是否都至少对应一个用例？每个 P0 用例是否都有对应的覆盖点？有没有两个用例实际上测的是同一个场景？这三问跑一遍，测试计划的主体框架就立住了，后面再怎么细化都是锦上添花。

4.4 第四步：评审与迭代——规格说明不是一次性文档

验证规格说明写出来不是给柜子看的，一定要设计评审。评审至少要拉三类人：设计工程师、验证同事、以及一个没有参与本模块验证的“第三方验证专家”。设计工程师帮你确认功能理解没有偏差；验证同事帮你找用例漏洞；第三方专家负责提“如果发生这个情况，你测过吗”这类发散性问题。评审会上被问倒不可怕，可怕的是没人问、没人提意见，那才是最大的风险信号。

评审之后，规格说明进入受控迭代：设计文档每更新一版，第一件事就是同步检查验证规格说明里哪些内容要跟着更新。很多团队的规格说明 V1.0 之后就没动过，这是最危险的。文档和代码不一致，比没有文档更糟，因为它制造了虚假的安全感。我自己的习惯是在文档里标注“本文档对应设计规格 V0.9 / RTL tag r20240315”，每次回归前都核对一次，防止规格说明和实际验证对象悄悄脱钩。

5. 常见问题与坑：我踩过的那些雷

5.1 把验证规格写成了设计文档的复述

最常见的失败模式。开篇就是模块架构、内部寄存器逐字段解释、电路原理……写了十几页，看不到一条测试用例。记住：验证规格的读者是验证工程师，要写的是 DUT 对外可观察的行为，以及你打算如何验证这些行为的计划，不是 RTL 实现细节。内部细枝末节的逻辑，属于设计文档的职责，验证规格写多了只会稀释重点。

判断自己有没有写偏，标准很简单：把你的验证规格文档发给设计工程师，如果他们读完之后觉得“没有任何新信息”，那你一定是写偏了。如果他们读完之后能说出“原来你是这么理解这个模块的”，那才是切题。验证规格说明的价值在于暴露验证视角的思考，而不是复读设计视角的内容，这个区别决定了文档是“工具”还是“废纸”。

5.2 覆盖率计划与测试用例脱节

另一个大坑：覆盖点定义在规格里，但跑完覆盖率之后没人去核对哪些覆盖点对应哪些测试。到签核评审，覆盖率报告显示 98%，经理一问“这个 98% 是靠哪些测试达成的？是否覆盖了所有配置组合？”答不上来，那这份报告就失去了信任。覆盖率数字本身没有意义，它能追溯回具体的激励场景才有意义。

我建议每个覆盖点都绑定用例 ID 列，并且每周回归后导出一份覆盖-用例映射报告，贴在验证周报里。这样做一方面督促测试用例和覆盖点同步补齐，另一方面也让签核评审有据可查。覆盖率不是用来刷数字的，是拿来证明“验证声称的完整性”的。如果覆盖率报告说不清来源，那这份报告反而会成为评审的质疑焦点，得不偿失。

5.3 签核标准含糊

什么叫验证完成？我见过最烂的答案是“测试都通过了，回归绿了”。这不算标准。一份合格的验证规格要写清楚量化标准，比如说：代码覆盖率（语句、分支、条件、FSM）达到 95% 以上，且未覆盖部分有明确、合理的排除理由；功能覆盖点 100% 命中；所有 P0/P1 用例通过；无未关闭的 CR，或者所有 CR 都有明确 waive 理由；断言无违反，或已逐条记录 waive。把这些标准写进规格，签核评审才有章可循。

这里有个经验：标准不要定得太激进。功能覆盖点 100% 是有意义的，但代码覆盖率非要 99% 可能让团队把时间耗在几个不可达的 corner 上。合理设定目标值，并且明确豁免流程，比追求好看的数字重要得多。签核标准的意义在于“大家事先约定好什么算完成”，而不是事后跟评审委员会讨价还价，那场面我见过太多次，谁都不舒服。

5.4 文档不维护、不更新

前面提过，这里单独拎出来再强调一次：验证规格的生命周期应该延续到模块验证结束，而不是只在项目开始的时候写一次。RTL 每改一版、新增一个 feature，文档都要有对应的修订。我自己的做法是在修订记录里写明“本版基于 RTL tag X 验证，对应设计规格版本 V0.9”，这样一旦出问题，回溯起来特别快。这个“关键版本对齐”的习惯能省下大量返工排查时间。

我见过一个项目，模块在 RTL freeze 前改了三次接口，验证规格却一直停留在最早那版。最后的直接后果是：验证环境里的 agent 已经按新接口改了，测试用例也加了，但规格文档里写的还是旧的接口协议。交付评审时，别人照着文档去检查代码，发现处处对不上，质疑声一片。这种低级错误，完全可以通过定期维护来避免，付出的只是一点维护时间，换来的却是文档的可信度。

下面把常见问题整理成速查表，方便团队内部快速对照：

6. 模板之外：验证规格的思维方式不会过时

6.1 新模块类型带来的验证规格扩展

这几年 SoC 里越来越多的人开始关注开源验证资源和验证方法学的变化。开源的仿真工具、UVM 的参考实现、各类协议 VIP 的开源替代品，都在降低验证入门的门槛。同时，像 AI 加速器、安全子系统这类新模块逐渐成为 SoC 的主角，它们的验证往往还要额外关注算子数值精度、安全隔离、性能指标等，验证规格需要扩展的内容也更多了，单一的功能树模型已经不足以覆盖所有维度。

以 AI 加速器为例，除了传统的数据通路和寄存器验证，你还要在规格里定义精度比对策略：参考模型用什么数据格式、容差范围是多少、多精度模式如何切换。性能验证也要写清楚：目标吞吐率、时延上限、在哪种负载下测量。这些内容放到老一套验证规格模板里没有现成位置，需要你主动扩展。我的做法是在原有模板上加一个“专项验证计划”小节，专门容纳这些跨功能树的验证需求。

6.2 一点个人建议

不管工具怎么变、模块怎么换，验证规格说明的思维方式不会过时：先拆功能，再定范围，后写用例，用覆盖率度量完整度。这本质上是一种把“我要保证质量”这个抽象目标，拆解成“可执行、可度量、可追溯”的具体动作的方法。拿到任何陌生模块，第一反应仍然应该是先写验证规格，把功能和策略讲清楚，再谈下一步。

我个人在实际项目里的习惯是：每开一个模块验证，先把这份规格说明模板复制出来，哪怕只花半天填完初稿，哪怕接下来又要改，也一定要把这件事放在写代码之前。每当项目进入尾声、面对交付评审的时候，我都庆幸当初有这份文档——它让我面对“你验证得怎么样”这个问题时，能清楚地拿出证据，而不是支支吾吾说“应该都验过了”。验证这一行，讲证据，靠细节，这份规格说明就是证据本身。