企业官网建设流程全解析

1. 这份模板不是文档，而是验证团队的“作战地图”

在SoC项目里，我见过太多验证工程师拿着一份几十页的Word文档，在早会上被架构师一句“这个场景你覆盖了吗？”问得哑口无言；也见过流片前一周，验证负责人突然发现某条总线仲裁路径的corner case根本没写进测试计划，临时拉人通宵补漏——结果还是漏了，芯片回来后第一块样片在DMA突发传输时死锁。这些都不是技术问题，是验证规格（Verification Specification）本身失效了。它本该是验证团队和设计团队之间唯一具备法律效力的技术契约，但现实中，它常常沦为应付流程的“签字画押”材料。

这份“SoC模块验证规格说明模板”，不是让你填空交差的格式文件。它是我在五代SoC项目（从28nm到5nm工艺，涵盖AI加速器、多核CPU子系统、高速SerDes PHY）中，把每次流片后回溯分析的37个典型验证缺口反向拆解、抽象、再验证后沉淀下来的结构化思维框架。它强制你回答三个致命问题：第一，这个模块到底要“活”成什么样？（功能边界与行为定义）第二，怎么证明它真的“活”对了？（可测性约束与断言锚点）第三，如果它“死”了，你能不能在10分钟内定位到是哪根信号线、哪个状态机分支、哪次数据搬运出了问题？（调试信息粒度与覆盖率缝合）

关键词里没有出现“UVM”“SystemVerilog”，因为这份模板刻意与具体验证方法学解耦。它不关心你用Python写testbench还是用C++搭仿真平台，只关心你是否在验证启动前，就已把模块的“生命体征指标”量化到比特级。比如，当模板要求你填写“时序敏感路径列表”时，它逼你去翻看综合报告里的critical path report，而不是凭经验写“AXI总线时序”。当它要求你定义“错误注入策略”时，它要你明确写出注入位置（如：在arbiter输出valid信号前一个cycle拉低）、注入方式（如：通过backdoor write强制置0）、预期响应（如：slave返回SLVERR且master自动重试不超过2次）——这些细节，才是决定验证深度的分水岭。

所以，别把它当模板，当成一张作战地图。地图上每一条等高线，都对应着一次可能的流片失败；每一个标注的补给点，都是你未来调试时能快速调用的断言或波形触发条件。接下来，我会带你一层层撕开这张地图的经纬线，告诉你每个字段背后藏着什么坑、为什么必须这么填、以及我踩过的那些血泪教训。

2. 模块级功能剖解：从“它能做什么”到“它必须拒绝什么”

验证规格的第一刀，必须切在模块的功能定义上。但这里有个致命陷阱：绝大多数工程师写的“功能描述”只是设计文档的复述，比如“支持AXI4协议”“具备DMA引擎”。这毫无价值。真正的功能剖解，核心是回答两个问题：它必须做什么（MUST）？它绝对不能做什么（MUST NOT）？后者往往比前者更关键，也更容易被忽略。

2.1 行为边界定义：用状态机语言重写需求

以一个典型的SoC中的“电源管理控制器（PMC）”为例。设计文档会写：“PMC根据系统负载动态切换CPU电压域”。这太模糊。在验证规格里，你必须把它翻译成可执行、可验证的状态机语言：

• 初始状态（Power-On Reset）：所有电压域强制进入最高电压（VDD_MAX），时钟门控全部关闭，PMC内部寄存器值为0x0。
• 合法状态迁移：
  • 当sys_load < THRESHOLD_LOW且vdd_curr != VDD_MIN→ 允许执行降压操作（需满足：降压步长≤50mV，间隔≥10us）；
  • 当sys_load > THRESHOLD_HIGH且vdd_curr != VDD_MAX→ 允许执行升压操作（需满足：升压步长≤100mV，间隔≥5us）；
• 非法状态迁移（MUST NOT）：
  • 禁止在vdd_curr == VDD_MIN时尝试任何降压操作（硬件应忽略请求并置位ERR_ILLEGAL_VOLTAGE）；
  • 禁止在vdd_curr == VDD_MAX时尝试任何升压操作（同上）；
  • 禁止在vdd_curr变化过程中，clk_enable信号发生跳变（硬件应锁存当前时钟使能状态直至电压稳定）。

提示：这个状态机描述必须直接映射到你的断言库。例如，“禁止在vdd_curr变化过程中clk_enable跳变”这条，就应该生成一个SystemVerilog assertion：assert property (@(posedge clk) (vdd_changing) |-> $stable(clk_enable));。如果规格里没写清楚“vdd_changing”的定义（比如：vdd_changing = (vdd_req != vdd_curr)），断言就无法落地。这就是为什么规格必须先于断言开发。

2.2 接口协议的“魔鬼细节”：超越协议文档的隐含约束

AXI协议文档写了握手时序，但没写“当master发出AWVALID=1而WSTRB=0x00时，slave该如何响应”。这种细节，恰恰是验证的黄金矿脉。在规格里，你必须穷举所有接口信号组合的合法/非法含义。我们曾在一个DDR控制器项目中栽过跟头：设计认为WLAST=1时WVALID必须为1，而验证按协议文档默认WLAST只是数据包结束标志，未做此约束。流片后发现，当某些特定burst长度下，master会发出WLAST=1 & WVALID=0的组合，导致DDR controller内部状态机卡死。

因此，规格中“接口协议约束”章节，必须包含一张强制表格：

这张表不是由验证工程师拍脑袋写的，它必须来自三方面输入：1）协议标准文档的“shall/shall not”条款；2）设计团队提供的微架构白皮书（特别是buffer深度、仲裁策略）；3）历史项目中暴露的同类问题归档。我习惯在项目启动时，拉着架构师、设计组长、验证组长，用半天时间逐行过这张表，当场签字确认。这比写一百页文字描述都管用。

2.3 时序与功耗的“可测性”转化：把物理量变成数字信号

SoC模块的时序（Timing）和功耗（Power）指标，常被当作后端实现的KPI，验证团队觉得与己无关。这是巨大误区。验证规格必须定义这些物理量的“可测性接口”。例如，一个高速SerDes PHY模块，其“眼图张开度”是关键指标。你不能只写“满足PCIe Gen4眼图模板”，而要定义：

• 测量点：在接收端CDR（Clock Data Recovery）模块的输入引脚（即rx_data_in[7:0]）；
• 测量窗口：在连续1000个UI（Unit Interval）内，统计每个采样点（共128个相位点）的高电平持续时间；
• 合格阈值：在中心相位±0.15UI范围内，高电平持续时间 ≥ 0.35UI 的采样点数量 ≥ 95%；
• 验证方法：在仿真中，用Python脚本解析波形文件（VCD/FSDB），提取rx_data_in在指定相位的跳变沿，计算占空比。脚本需作为验证交付物的一部分。

同样，功耗指标也要可测。比如“待机模式下，模块静态功耗 ≤ 10μA”。这需要你在RTL中植入一个虚拟电流计（Virtual Ammeter）：在待机状态下，统计所有flip-flop的翻转次数（toggle count），乘以每个FF的典型漏电功耗（来自工艺库），再叠加所有始终使能的LDO的静态电流。这个计算模型必须写入规格，并作为后续power-aware simulation的基准。

注意：这些“可测性接口”定义，直接决定了你后续覆盖率的完备性。如果你没定义“眼图测量点”，那么覆盖率工具就无法知道该监控哪些信号；如果你没定义“待机模式的进入条件”（如：pwr_mode == 2'b10 && all_clocks_gated == 1'b1），那么power coverage就永远达不到100%。规格，就是覆盖率的源头。

3. 验证策略骨架：用“覆盖率缝合”替代“测试用例堆砌”

很多团队的验证计划，本质是一份“测试用例清单”：TC001：正常读写；TC002：地址错；TC003：数据错……这就像用散弹枪打靶——覆盖面广，但命中率低，且无法证明没有漏网之鱼。真正的验证策略，核心是覆盖率缝合（Coverage Stitching）：把功能点、场景、边界、错误模式，全部编织进一张动态演化的覆盖率网中，让网眼的大小，精确对应你最担心的失效风险。

3.1 功能覆盖率（Functional Coverage）：从“做了什么”到“覆盖了什么”

功能覆盖率不是测试用例的简单计数。它必须反映模块的“行为空间”。以一个加密引擎（Crypto Engine）为例，其功能覆盖率模型不应是：

• covergroup cg_encrypt {
• coverpoint mode { bins aes = {0}; bins sha = {1}; }
• coverpoint key_len { bins 128 = {128}; bins 256 = {256}; }
• }

这太浅。它遗漏了最关键的交叉（cross）关系：不同模式下，密钥长度、数据块长度、填充模式的组合，是否都经过了验证？正确的模型是：

covergroup cg_crypto_xsec @(posedge clk); option.per_instance = 1; // 主要维度 cp_mode: coverpoint cfg.mode { bins aes = {AES}; bins sha = {SHA256, SHA384}; } cp_key_len: coverpoint cfg.key_len { bins len_128 = {128}; bins len_256 = {256}; bins len_512 = {512}; } cp_data_len: coverpoint cfg.data_len { bins small = {[1:64]}; bins medium = {[65:1024]}; bins large = {[1025:$]}; } cp_padding: coverpoint cfg.padding { bins pkcs7 = {PKCS7}; bins zero = {ZERO}; bins none = {NONE}; } // 关键交叉：AES模式下，key_len与data_len的组合必须全覆盖 cross cp_mode, cp_key_len, cp_data_len { ignore_bins ignored = binsof(cp_mode) iff (cp_mode != AES); } // 关键交叉：SHA模式下，padding必须为NONE（SHA不支持填充） cross cp_mode, cp_padding { illegal_bins illegal_pad = binsof(cp_mode) && binsof(cp_padding) iff (cp_mode inside {SHA256, SHA384} && cp_padding != NONE); } endgroup

这个模型的价值在于：它把设计规范（如“SHA算法不支持填充”）直接编码为illegal_bins，一旦仿真中触发，立即报错，而不是等到流片后才发现。同时，ignore_bins确保覆盖率统计聚焦在关键路径上，避免被无关组合稀释。

3.2 场景覆盖率（Scenario Coverage）：为“最坏情况”建模

功能覆盖率关注“单点”，场景覆盖率关注“链条”。它模拟真实系统中，多个事件按特定时序、特定概率发生的复杂场景。例如，一个PCIe Root Complex模块，其关键场景不是“发一个TLP”，而是：

• 场景S1：链路训练失败后的快速恢复
  LTSSM进入Detect.Quiet→Polling.Active→Configuration.Linkwidth.Start→Configuration.Lanenum.Wait→Configuration.Lanenum.Timeout（超时）→Detect.Quiet（循环）。在此循环中，验证需覆盖：1）超时计数器是否正确递增；2）LinkDown中断是否在第3次超时后置位；3）retrain_link寄存器写1后，是否强制重启训练。

• 场景S2：AER（Advanced Error Reporting）错误风暴
  在1ms窗口内，连续注入5个不同类型的Uncorrectable Errors（如：Completion Timeout, Unsupported Request），验证：1）AER寄存器是否按FIFO顺序记录错误；2）aer_first_error是否指向第一个错误；3）当FIFO满（8 entry）时，新错误是否被丢弃并置位aer_overflow。

这些场景，必须用UVM sequence或Python脚本驱动，其触发条件、持续时间、注入方式，都要在规格中明确定义。我习惯用一张“场景-触发条件-验证点-覆盖率目标”表格来管理：

3.3 错误注入策略（Error Injection Strategy）：主动制造“可控的灾难”

验证的最高境界，不是证明它能工作，而是证明它在出错时，能优雅地失败。错误注入，就是你的“可控灾难实验室”。规格中必须定义：

• 注入点（Injection Point）：精确到信号名和时钟域。例如：“在axi_arvalid信号进入arbiter模块的输入端口前一个cycle，强制置0”。
• 注入时机（Injection Timing）：基于状态机或计数器。例如：“当arbiter_state == GRANTING && grant_count == 3时注入”。
• 注入模式（Injection Pattern）：单次、周期性、随机、或基于覆盖率反馈（Coverage-Driven Injection）。例如：“当cp_data_len.medium覆盖率<80%时，以10%概率注入data_corruption错误”。
• 预期响应（Expected Response）：必须精确到信号、时序、状态。例如：“注入后，axi_rresp必须在3个cycle内变为SLVERR，且axi_rvalid保持低电平至少5个cycle”。

我们曾在一个NoC（Network-on-Chip）项目中，因错误注入策略不完善而付出惨重代价。规格只写了“注入link failure”，但没定义注入位置（是phy layer？mac layer？router input port？）和注入方式（是拉低rx_valid？还是翻转rx_data？）。结果验证团队在phy层注入，而设计团队以为是在router层，导致所有错误处理逻辑都在错误的位置被验证，流片后遇到真实link故障，整个网络瘫痪。

经验：错误注入的“注入点”必须与DFT（Design for Test）的scan chain控制点对齐。这样，流片后的ATE（Automatic Test Equipment）测试，才能复用同一套注入逻辑。规格中应明确标注：“此注入点对应DFT scan chain bit #1234”。

4. 可调试性设计（Debuggability）：让波形成为你的“X光片”

流片后，你只有一次机会看芯片内部。如果验证规格里没定义好“可调试性”，那调试过程就是一场绝望的盲人摸象。可调试性不是事后加的debug port，而是从验证规格的第一行就开始规划的信号可见性战略。

4.1 关键信号的“全生命周期”监控

一个信号，从产生、传递、到消费，其“生命周期”中的每个关键节点，都必须有对应的可观察信号。以axi_awaddr为例：

• 源端（Source）：awaddr_from_master（master发出的原始地址）；
• 仲裁前（Pre-Arbitration）：awaddr_pre_arb（进入arbiter前的地址）；
• 仲裁后（Post-Arbitration）：awaddr_post_arb（arbiter分配后的地址）；
• 目的端（Destination）：awaddr_to_slave（到达slave前的地址）；
• 消费端（Consumer）：awaddr_decoded（slave内部译码后的地址）。

这5个信号，必须在RTL中显式声明为debug类型（如logic [31:0] awaddr_from_master /* verilator public */;），并在验证规格的“Debug Signals”章节中列出，注明其用途和采样条件。例如：awaddr_pre_arb用于验证arbiter是否在高优先级请求到来时，正确抢占了低优先级请求的地址。

提示：不要依赖仿真器的“自动信号抓取”功能。它抓不到内部寄存器的中间状态。你必须在RTL中，把关键路径上的每一个“决策点”信号，都显式地wire出来。这会增加约3%的面积开销，但能节省流片后50%以上的调试时间。

4.2 状态机的“快照式”导出

状态机是SoC模块的“大脑”，但传统波形中，你只能看到state == 3'b101，却不知道它代表什么。规格必须强制要求：每个状态机，必须有一个对应的state_name字符串信号，并在每个时钟周期更新。例如：

always_ff @(posedge clk or negedge rst_n) begin if (!rst_n) begin current_state <= IDLE; state_name <= "IDLE"; end else begin current_state <= next_state; unique case (next_state) IDLE: state_name <= "IDLE"; WAIT_ACK: state_name <= "WAIT_ACK"; ERROR_HANDLING: state_name <= "ERROR_HANDLING"; default: state_name <= "UNKNOWN"; endcase end end

这个state_name信号，必须在验证规格中列为“强制debug信号”。它的价值在于：当你在波形中看到state_name == "ERROR_HANDLING"时，你立刻知道问题出在错误处理分支，而不是在WAIT_ACK的超时逻辑里。这比数几十个时钟周期的state二进制值，效率高出百倍。

4.3 覆盖率与波形的“双向缝合”

覆盖率报告是“面”，波形是“点”。二者必须缝合，才能形成完整的证据链。规格中必须定义：

• 覆盖率点到波形的映射规则：例如，当cg_crypto_xsec.cp_mode.aes被击中时，仿真器必须自动保存从该事件触发前100ns到触发后500ns的cfg.*,data_in.*,key.*信号波形，并命名为coverage_aes_hit_001.vcd。
• 波形到覆盖率的反向标记：在波形文件中，用$comment或$attribute嵌入覆盖率点ID。例如，在coverage_aes_hit_001.vcd的头部加入：$comment "COVERAGE_POINT: cg_crypto_xsec.cp_mode.aes" $end。

这套机制，让我们在客户现场调试时，能直接用覆盖率报告定位到最相关的波形片段，而不是在TB级的波形文件中大海捞针。有一次，客户报告一个偶发的加密失败，我们拿到覆盖率报告，发现cp_padding.pkcs7的覆盖率只有60%，立刻筛选出所有pkcs7相关的波形，30分钟内就定位到是padding字节在DMA搬运时被截断。

5. 模板落地实操：从空白文档到可执行规格的七步法

有了理论，如何把它变成一份真正能指导项目的文档？我总结了一套“七步法”，在最近三个SoC项目中，将规格编写周期从平均3周压缩到5天，且一次性通过率从40%提升到95%。

5.1 第一步：锁定“不可协商”的基线（Baseline Lock）

在项目启动会（Kick-off Meeting）上，不做任何细节讨论，只做一件事：签署基线。基线包括：

• 工艺节点：28nm LP（不可改为28nm HP）；
• 主频：CPU Subsystem @ 1.2GHz（不可写up to 1.2GHz）；
• 协议版本：AXI4-Lite v2.0（不可写AXI4-Lite compatible）；
• 关键KPI：Max Latency for Read Transaction: 15 cycles（必须带单位和条件）。

这个基线文档，由架构师、设计总监、验证总监三方签字，作为后续所有规格讨论的“宪法”。任何偏离基线的讨论，都必须走正式的ECO（Engineering Change Order）流程。这一步砍掉了70%的无效争论。

5.2 第二步：用“逆向追溯表”驱动功能分解

不要从设计文档开始写，而是从最终的验证交付物倒推。我创建一个Excel表，列名为：Verification Deliverable|Required Input Signal|Required Input Condition|Source Module|Spec Section。

例如，对于交付物Final Coverage Report，其Required Input Signal是cg_crypto_xsec，Required Input Condition是cfg.mode == AES && cfg.key_len == 256，Source Module是crypto_top，Spec Section就指向“3.1 功能覆盖率”章节。这个表，就是你的规格大纲。

5.3 第三步：用“红绿灯评审法”进行实时校验

在编写规格时，我用三种颜色标记每个条款：

• 绿色：已有成熟IP或参考设计，可直接复用（如：AXI protocol checker）；
• 黄色：需要定制开发，但技术路径清晰（如：自定义的eye diagram analyzer）；
• 红色：存在技术风险，需POC验证（如：在5nm工艺下，用FinFET晶体管建模的leakage power estimator）。

每天下班前，团队同步这个“红绿灯表”。红色项必须在48小时内给出POC方案，否则升级至项目总监。这保证了规格的可行性。

5.4 第四步：嵌入“自动化检查点”

在模板中，为每个关键章节，预埋自动化检查脚本。例如，在“接口协议约束”章节末尾，插入：

# Auto-check: Verify all signal combinations in Table 2.2 are covered by assertions python check_assertions.py --spec spec_v1.2.pdf --table "Table 2.2" # Expected output: PASS (All 12 combinations found in assertion library)

这个脚本，会在CI（Continuous Integration）流水线中自动运行。如果有人修改了表格但忘了更新断言，CI立刻失败。规格，从此有了“牙齿”。

5.5 第五步：定义“签名式验收标准”

规格的最终验收，不是领导签字，而是通过一套签名式测试。例如：

• 签名测试S1：运行run_coverage_stitch.sh，必须在10分钟内生成coverage_stitched.html，且stitch_score >= 95；
• 签名测试S2：运行run_debug_waveform.sh，必须在5分钟内生成debug_signals_list.csv，且signal_count >= 200；
• 签名测试S3：运行run_error_injection.sh，必须触发error_injection_report.txt，且injection_success_rate == 100%。

只有这三个签名测试全部通过，规格才被视为“Ready for Review”。这比任何会议评审都可靠。

5.6 第六步：建立“版本-芯片-配置”的三维矩阵

一个SoC项目，往往有多个芯片版本（Chip A, Chip B）、多个配置（Config 1: Full Feature, Config 2: Lite）。规格模板必须支持三维矩阵管理。我在模板中设计了一个version_matrix.md文件：

这个矩阵，是项目管理的“仪表盘”。任何变更，都必须在这个矩阵中更新，否则视为无效。

5.7 第七步：交付“可执行规格包”

最终交付的，不是一个PDF，而是一个spec_package_v1.2.zip，里面包含：

• spec_v1.2.pdf：人类可读的规格文档；
• spec_v1.2.sv：机器可读的SystemVerilog断言库（直接可编译）；
• coverage_model/：UVM coverage group源码；
• debug_signals.csv：所有debug信号的列表、宽度、时钟域、用途；
• check_scripts/：所有自动化检查脚本；
• signature_tests/：所有签名测试用例。

这个包，可以直接被CI流水线拉取、编译、运行。规格，从此不再是纸上谈兵，而是可执行的代码。

6. 流片后回溯：规格失效的五个典型征兆与修复

规格不是写完就扔进抽屉的文物。它必须在流片后，接受最残酷的实战检验。根据我参与的12次SoC流片回溯分析，规格失效往往表现为以下五个征兆。识别它们，就是修复规格模板的起点。

6.1 征兆一：覆盖率“虚高”——数字游戏下的信任崩塌

现象：流片后，发现一个关键功能失效，但验证报告显示该功能覆盖率100%。深入分析发现，覆盖率模型只覆盖了“正常路径”，而忽略了“错误处理路径”。例如，一个DMA控制器的覆盖率模型只统计了transfer_complete，却没统计transfer_error。

根因：规格中“功能覆盖率”章节，只定义了coverpoint success，而遗漏了coverpoint error_response及其与success的交叉。修复方案：在模板中，强制要求每个coverpoint必须配对定义coverpoint error_condition，并声明其cross关系。例如：

cp_transfer_success: coverpoint status { bins done = {DONE}; } cp_transfer_error: coverpoint status { bins err = {TIMEOUT, PARITY_ERR, ADDR_ERR}; } cross cp_transfer_success, cp_transfer_error; // 必须覆盖成功与错误的任意组合

6.2 征兆二：调试信息“失焦”——波形里全是噪音

现象：流片后出现问题，抓取波形，发现关键信号（如arbiter_grant）在出错时刻是X（未知态），无法判断是设计bug还是验证激励不足。

根因：规格中“可调试性”章节，只列出了信号名，但没定义其采样条件。例如，arbiter_grant信号在reset_n为低时是X，但规格没规定“仅在reset_n == 1'b1时采样”。修复方案：在模板的“Debug Signals”表格中，增加一列Sampling Condition，强制填写。例如：arbiter_grant的采样条件是@(posedge clk) if (reset_n) begin ... end。

6.3 征兆三：错误注入“脱靶”——打偏了的子弹

现象：验证时注入address_mismatch错误，模块正确报错；但流片后，真实硬件在相同条件下却无响应。

根因：规格中“错误注入策略”只定义了“注入什么”，没定义“注入到哪里”。验证在axi_awaddr信号线上注入，而设计团队在axi_awaddr进入FIFO前做了奇偶校验，错误被提前拦截。修复方案：在模板中，“注入点”必须精确到RTL层级，并附上grep -n "awaddr" *.sv的搜索结果行号。例如：“注入点：axi_top.sv:456，assign awaddr_to_fifos = awaddr_from_master;”。

6.4 征兆四：场景覆盖“断链”——链条缺了一环

现象：验证覆盖了“链路训练成功”和“链路训练失败”，但流片后，在“训练成功后立即断电”场景下，PHY无法重新训练。

根因：规格中“场景覆盖率”只定义了原子场景（S1: Train Success, S2: Train Fail），但没定义复合场景（Composite Scenario）。修复方案：在模板中，增加“Composite Scenario”章节，强制要求定义至少3个跨状态机的复合场景，并给出其触发序列。例如：“S3: TrainSuccess -> PowerDown -> PowerUp -> TrainAgain”，其触发序列是ltssm_state == CONFIGURATION && pwr_mode == POWER_DOWN -> pwr_mode == POWER_UP -> ltssm_state == DETECT_QUIET。

6.5 征兆五：基线漂移“失控”——目标在移动

现象：项目中期，架构师口头通知“把CPU频率从1.2GHz提到1.4GHz”，但规格文档没更新，导致验证环境仍按1.2GHz时序收敛，流片后高频下时序违例。

根因：规格中缺少基线变更的强制审计流程。修复方案：在模板首页，增加一个“Baseline Change Log”表格，任何基线变更，必须由三方（Arch, Design, Verification）在表格中电子签名，并关联到具体的ECO编号。例如：

这个表格，就是规格的“防伪标签”。没有它，任何基线变更都不生效。

我在最后一次流片回溯会上，把这五个征兆打印出来，贴在会议室墙上。项目经理指着第六个空白位置问我：“第六个是什么？”我回答：“第六个，是我们终于学会了，把规格，当成项目的心脏，而不是一张需要签字的纸。”