简介：《软件项目范围说明书》是一份面向软件项目负责人、需求分析人员与开发团队的范围定义文档模板，用于在立项与需求阶段明确开发意图、应用目标、作用范围和用户约束，并理清目标软件与外部系统的关系。文档按引言、任务概述、需求规定、运行环境规定和数据要求组织，包含编写目的、背景说明、术语定义、用户特点、假定与约束、IPO功能表、性能与输入输出要求、故障处理、设备与支持软件接口，以及静态/动态数据的逻辑描述等内容，可作为项目立项说明和需求评审的撰写底稿。资源包为单个doc文件，约46KB，体量轻便，便于直接修改套用。已有1642人学习，适合需要规范项目范围描述、补全需求文档结构的开发者与项目管理人员参考。

1. 范围说明书的真正作用：为什么条款越细的项目反而越容易失控

见过一个反直觉的现象：一份软件项目范围说明书写到六十多页，功能条目列了三百多条，项目照样在第三个月失控。失控的方式不是需求变多了，而是没人能回答一个最基础的问题——「这条改动算不算超出范围」。功能列表再长，也只是清单；清单不构成边界。范围（scope）在工程语境里从来不是一个列表，而是四个互相咬合的边界：功能边界、质量边界、环境边界、数据边界。这份文档模板用「引言—任务概述—需求规定—运行环境—数据要求」五段式，本质上是在为这四个边界分别建立可判定的锚点。搞懂它的结构为什么长这样，比照着填完它有价值得多，因为它决定了后面每一次变更评审、每一轮验收、每一次线上故障归责，到底有没有一份能拿出来对质的东西。

2. 引言与任务概述：元信息层如何决定后面所有条款的解释权

一份范围说明书的开头两章看起来最"虚"，却是整份文档的解释权来源。同样一句「响应时间不超过 2 秒」，写在背景含混的文档里是句愿望，写在明确定义了用户规模、部署形态、接口关系的文档里才是条约束。原因很简单：任何需求条款的成立都依赖前提，而前提只在这一层被固定下来。后面三章的所有数字、所有断言，都要回到这一层去取语境。跳过这一层直接写功能表，等于把一堆没有定义域的公式抄在纸上。

2.1 编写目的与读者预设：文档的作用域从第一段就锁死

「编写目的」这一节常被当成客套话写，实际它是整份文档的作用域声明。它要回答两件事：这份文档约束谁，以及它不约束谁。前者决定条款的效力等级，后者决定哪些争议该去别的文档里找答案。

一份合格的范围说明书会明确区分三类读者：任务提出者关心目标与约束是否被完整承接；开发者关心条款是否足以推导出设计与测试用例；验收方关心每一条款能不能被判成通过或不通过。这三类读者对同一句描述的理解偏差，是项目后期扯皮的主要来源。编写目的一节把「预期读者」写清楚，等于提前把解释权的分配摆到台面上。

我一般会这么理解这一节的实际作用：它是文档的命名空间。把所有术语、缩写、外部引用都收拢在一个命名空间里，后面出现的每一个词才有确定指向。定义一节列出的专门术语和外文首字母组词，就是给这个命名空间填符号表。少了它，同一个词在文档不同位置指两件事，写到第四章数据要求时就会出现「文卷」到底是一个物理文件还是一个逻辑表这种低级但致命的歧义。

参考资料一节的价值也被严重低估。它要求列出文件标题、编号、发表日期、出版单位，还要说明获取来源。这四个字段不是形式主义：标题确定内容，编号确定版本，发表日期确定时效，出版单位确定权威性。缺任何一个，引用就可能指向一份已被废止的旧版规范。这里翻车的成本极高——设计阶段依据的是 A 版接口规范，实现阶段对方已经升到 B 版，联调当天才发现字段语义变了。

注意：定义与参考资料两节是这份文档里唯二「向后兼容」的部分，任何后续修订都不应该删改已有条目，只能追加。删改会让引用过旧版本的人失去追溯路径。

2.2 假定与约束：范围不是功能列表，是约束集合

任务概述里的「假定和约束」是整份文档中最容易被写成一句话敷衍过去、又在项目中期反复被翻出来引用的一节。它列的是经费限制、开发期限这类条件，但真正的机制价值在于：约束是范围的负向定义。

功能列表告诉你「要做什么」，约束告诉你「在什么条件下做」。同一组功能，在六个月工期和三个月工期下是两个完全不同的工程问题——后者会强制砍掉自研中间件、强制选择成熟框架、强制把某些非核心能力外购。如果约束没被写下来，做技术选型的人就无从判断自己是在合理妥协还是在偷工减料，评审时也无法区分「设计不当」和「受约束所迫」。

假定（assumption）比约束更危险，因为它默认成立、不写就消失。典型的假定包括：上游系统会按时提供接口、第三方服务的调用配额够用、用户侧网络环境达到某带宽下限。这些假定一旦被写进文档，就等于挂上了风险登记；一旦不写，它们会以「大家都以为是这样的」的形式潜伏在团队共识里，直到某天被现实击穿。

常见的实现思路是把这一节做成一张两列表：左侧是条目，右侧是「若不成立时的应对」。前者是声明，后者是预案。加上右列之后，这一节从静态描述变成了有触发条件的机制，评审时可以直接问「这条假定如果破了，我们怎么办」，答不上来的条目就是尚未想清楚的风险。这个做法不复杂，但能把一份文档从"记录"提升到"可用于决策"的层级。

2.3 用户特点为什么属于设计约束而不是市场描述

「用户的特点」要求列出最终用户的教育水平、技术专长、预期使用频度。很多人把它写成用户画像，写使用者是谁、在什么场景下用、有什么痛点。方向偏了：这一节的落点是约束，不是描述。

操作人员的技术专长直接决定交互设计的下限。如果一线操作人员是轮班制、培训时长不超过两小时、日常只做固定的三五个动作，那么任何需要多步配置、需要理解抽象概念的界面设计都是不可接受的，与功能是否强大无关。维护人员的技术专长则决定运维接口的形态：是提供图形化控制台，还是只提供命令行与配置文件；是要求能读懂日志格式，还是必须做到零日志排查。

预期使用频度是最容易被忽略的一项，它直接映射到性能预算的分配。低频使用的批量功能可以接受分钟级响应，高频使用的查询功能必须压到百毫秒级，两者的实现代价差一个数量级。如果不在这里把频度写清楚，性能条款就只能拍一个笼统的平均值，最终结果是高频路径被低频路径的平均数拖累。

这一节还隐含一个更硬的东西：使用频度乘以用户数，就是并发规模。并发规模再乘以单次操作的数据量，就是数据管理能力要求里的存储估算起点。这条推导链从第二章一直延伸到第五章，中间任何一环空缺，末尾的容量估算就是拍脑袋。我见过不少文档在这一节写「用户为公司内部员工」，到了第五章却要求估算五年数据增长，中间缺了人数、缺了频度，估算只能凭感觉，最后照着感觉买的存储，上线三个月就告急。

所以这一节的正确写法是量化：操作人员约多少人、平均每人每日操作多少次、峰值集中在哪个时段、维护人员具备哪类技能、是否具备阅读日志和配置的能力。量化之后，它就同时是交互设计的输入、性能预算的输入和容量估算的输入，一个条目服务三处下游，这才是它在文档结构里排在前面的理由。

3. 需求规定的 IPO 表：把自然语言压成可验证断言的机制

需求规定这一章是整份文档的重心，也是它区别于「需求清单」的关键。它要求用 IPO 表（输入、处理、输出）逐项定量定性叙述功能，同时明确应支持的终端数和并发用户数。这套写法的机制目的只有一个：让每一条功能都变成一个可以被判定的谓词——给定一组输入，经过确定的处理，产出可预期的输出，对或错没有争议。

3.1 三元组的判定力：写不出输入输出的条目还不是需求

IPO 表的强制结构看似笨拙，实际是一道过滤器。任何一条功能，如果写不出它的输入是什么、处理规则是什么、输出是什么，那它还不是需求，而是愿望或者方向。这个判断标准极其有效，因为它把模糊表述挡在了实现之前。

举个常见例子：「系统应支持灵活的用户权限管理」。这句话放进 IPO 表会立刻卡住——输入是什么？是角色定义、权限项、还是分配关系？处理是什么？是校验、合并、还是继承推导？输出是什么？是一张权限矩阵、还是一个判定结果？三个问题答不全，这条功能就没法被实现，更没法被测试。反过来，一旦答全了，测试用例几乎是自动生成的：给定期望的输入，比对输出即可。

并发的写法也值得单独说。文档要求说明应支持的终端数和并行操作用户数，这两个数不是同一件事。终端数是连接数上限，并行用户数是同时活跃的操作者数量，两者之间的比例决定了连接池、会话管理和锁粒度的一系列设计。只写「支持多用户并发」等于什么都没写，因为多用户可以是十个也可以是十万个，对应的架构完全不同。

这一节还有一个隐藏要求：逐项定量和定性。「定量」意味着凡是能加数字的地方都要加数字，「定性」意味着加不了数字的地方要给出可判定的分类标准。两者合起来，构成了验收测试的输入。这是这份文档在工程链条上的真正位置——它不是给开发看的说明书，它是给测试和验收看的判定依据。

提示：写 IPO 表时，处理一栏最容易写成实现细节。它应该写业务规则，而不是算法步骤。业务规则变了要改文档，算法换了不该改文档。

3.2 性能条款的三根支柱：精度、时间特性、灵活性的可度量写法

性能规定被拆成精度、时间特性、灵活性三块，这个拆分方式不直观，但对应三个完全不同的问题域。

精度处理的是「数值对不对」。它明确要求说明输入输出数据精度的要求，还特别提到传输过程中的精度。这个补充很关键：同一个数值在存储、计算、传输三个环节的精度损失可能不同，浮点截断、序列化舍入、单位换算都会引入偏差。文档要求把这些写清楚，等于要求在需求阶段就确定数值口径，避免后期出现「前端显示 100.00，后端存的是 99.996」这种对账噩梦。

时间特性处理的是「快不快」，而且拆成四类：响应时间、更新处理时间、数据转换和传送时间、解题时间。这四类的技术含义完全不同。响应时间约束的是交互路径，通常以百毫秒计；更新处理时间约束的是写入与一致性达成，涉及事务与索引维护；数据转换和传送时间约束的是批处理与接口链路，受带宽和序列化格式影响；解题时间约束的是计算密集任务的完成时长，直接决定是否需要异步化和任务队列。把它们混成一个笼统的「性能要求」，实现方就无从分配优化预算。

灵活性处理的是「变了以后扛不扛得住」，它列了五类变化：操作方式、运行环境、接口、精度和有效时限、计划或改进。这一块最有价值的一句话是「对于为了提供这些灵活性而进行的专门设计的部分应该加以标明」。这句话承认了一件工程事实：灵活性不是免费的，它需要在架构里预先留接缝，而接缝本身有成本。要求把这些专门设计标出来，等于要求文档作者明确说明哪些地方是刻意做松的。

这张表的第三列就是判定标准：凡是写不进第三列的表述，都不构成条款。灵活性尤其容易写空，因为「扩展性良好」听起来正确但不可验证；写成「操作方式变化时，新增一种输入方式不改动业务逻辑层」，就变成了一条可以被架构评审检查的约束。

3.3 数据管理能力与故障处理：被跳过却最能兜底的两节

数据管理能力要求说明需要管理的文卷和记录个数、表和文卷的规模，并按可预见的增长对存储要求做估算。这一节在文档评审中最常被标注「待补充」，然后在项目上线后以最惨烈的方式补上。

它的机制作用是给存储设计提供起点。记录条数决定索引策略，单表规模决定是否需要分区，增长率决定容量规划的时间窗口。没有这些数字，设计阶段的「要不要分库分表」就只能是拍脑袋，而拍脑袋的默认答案通常是「先不分」，等数据量上来再分——这时候迁移成本已经是当初的十倍以上。这一节的写法要落到「当前规模 + 年增长率 + 峰值系数」三个数上，粗一点没关系，缺了才致命。

故障处理要求列的是可能的软件、硬件故障，以及这些故障对各项性能产生的后果和处理要求。这一节的结构其实很接近失效模式分析：先枚举失效，再评估影响，最后定义处理动作。文档没有用 FMEA 这个术语，但要求的三段式是一致的。

这一节真正的价值在于逼出「降级方案」。纯功能描述里没有降级这个概念，因为功能默认是成功的。只有在故障处理一节，才会出现「数据库主节点不可用时，系统应支持只读模式运行，写操作返回明确错误码」这类表述。这类条款在设计阶段写下来，会直接影响到代码里的异常分支和运维侧的预案；不写，就等于默认所有组件永远在线，直到第一次真实故障把所有未定义行为暴露出来。

其他专门要求一节则留给安全保密、易用性、可维护性、可补充性、易读性、可靠性、运行环境可转换性这些横切关注点。它是一节兜底条款，把无法归入前五节的约束集中安置，避免它们散落在正文各处被漏掉。

4. 运行环境与数据契约：耦合点写不清，联调阶段必然返工

第四章和第五章处理的是两类契约：软件与运行环境的契约，软件与数据的契约。这两类契约的共同特点是，它们在设计阶段看起来是背景信息，在联调阶段才暴露出是接口定义。环境写错一个版本号，数据定义错一个值域，代价都是返工。

4.1 设备与支持软件清单：为什么要写成区间和下限

设备一节要求列出处理器型号及内存容量、外存容量与联机脱机状态及存储格式、输入输出设备的型号和数量、数据通信设备、功能键及其他专用硬件。这份清单看起来像采购单，实际是部署契约。

关键在于写法的精度。处理器型号写具体型号是危险的，因为硬件迭代速度远快于软件生命周期，写死一个型号会让文档在半年后失效。合理的写法是给下限加特征：最低核心数、最低主频区间、必须支持的指令集特性。这样既能保证性能估算有依据，又不会因为型号停产导致文档作废。

外存部分要区分联机和脱机、媒体和存储格式。这个区分的实际意义在于数据生命周期管理：联机存储支撑在线查询，脱机媒体支撑归档与恢复。如果不在这里写清楚哪些数据必须联机、哪些可以归档、归档的恢复时限是多少，后期的数据分层策略就没有依据，所有数据一律在线，存储成本线性膨胀。

支持软件一节列操作系统、编译或汇编程序、测试支持软件。这里最常见的错误是只写名称不写版本策略。名称确定生态，版本确定 ABI 兼容性。稳妥的写法是给出可接受版本区间加一个已验证版本，前者给升级留空间，后者给排障留基准。测试支持软件被单列出来是有道理的：它决定了自动化测试能不能在目标环境里跑起来，很多项目在临近交付时才发现目标环境不允许安装测试代理，整个回归链路被迫改成手工。

4.2 接口与控制信号：跨边界隐式假设如何显式化

接口一节要求说明与其他软件之间的接口、数据通信协议。控制一节要求说明控制该软件运行的方法、控制信号及其来源。这两节分开写，是因为它们约束的是两个不同方向的交互：接口是数据面的，控制是管理面的。

数据面接口最常见的缺失是只写协议不写语义。写明用哪种传输方式、哪种编码格式是必要的，但真正会导致事故的是语义层：「订单状态」字段在两个系统里取值含义是否一致、「时间戳」是本地时间还是带时区、「空值」用 null 还是空字符串表示。这些不会写在协议规范里，只会以隐式假设的形式存在于双方开发者的脑子里，然后在联调第一天的日志里集中爆炸。

管理面控制则更容易被整节跳过。控制信号来源决定了运维能不能在不改代码的前提下干预系统：是配置文件、是环境变量、是管理端口上的命令、还是外部调度系统下发的指令。如果这一节空缺，实际运行时的控制方式就会退化成「登机器改配置然后重启」，这个方式在单机时代可行，在集群环境下会立刻变成运维灾难。

我一般会这么理解这两节的关系：接口定义系统能听懂什么，控制定义系统能被怎么指挥。前者缺失导致数据错乱，后者缺失导致故障时刻无法干预。两者都属于「不写就默认不存在」的隐式约定，而隐式约定在跨团队协作中的存活率极低。

注意：控制信号的来源必须能追溯到具体组件，写成「由运维人员控制」不算定义。要写清楚是哪个系统、通过什么通道、以什么格式下发。

4.3 静态与动态数据的二分：一条划分直接决定存储架构

第五章开篇把数据分成静态数据和动态数据。静态数据是运行过程中主要作为参考、长期不变化的数据；动态数据包括运行中会变化的数据以及运行中输入输出的数据。这条二分看起来只是分类，实际它直接映射到两种截然不同的存储与治理策略。

静态数据的特征是读多写少、变更需要审批、通常需要版本化。典型形态是配置表、字典表、规则表。这类数据的正确做法是缓存加版本号，变更走发布流程而非直接改库。动态数据则相反，写频繁、变化不可预测、需要事务保证和索引支撑。把两类数据混在一张表里管理，结果是配置变更触发业务表锁，或者业务写入污染参考数据。

文档进一步把数据分成五组：静态数据、动态输入数据、动态输出数据、内部生成数据、数据约定。这个分组比二分更细，其中「内部生成数据」一组值得单独说——它是提供给用户或维护调试人员的数据，比如运行日志、审计记录、统计中间结果。这类数据既不是业务输入也不是业务输出，容易被漏掉，但它们往往占据了存储增长的大头。日志和审计数据的保留周期、清理策略、脱敏要求，都应该在这一组里定义。

「数据约定」一组要求逐条列出对进一步扩充或使用方面的限制，包括容量、文卷数、记录数、数据元个数的最大值，并特别强调对临界性限制要明确指出。这条要求背后的机制是：临界值不是普通参数，它是设计约束的硬边界。一个字段设计成最大 255 字符，和设计成最大 32 字符，对应的存储类型、索引大小、校验逻辑都不同。临界值不写明，实现方只能按最宽松的假设做，最终在真实数据面前崩掉。

4.4 数据采集的七个要素：ETL 设计的最小信息集

数据采集一节列出了七个要素：输入数据来源、输入媒体和硬件设备、接受者、输出数据的形式和设备、数据值的范围、量纲、更新和处理的频度。这七项构成了数据链路设计的最小信息集，缺任何一项，下游的采集实现就要靠猜。

来源决定责任边界：是单个操作员录入、是数据输入站批量导入、还是由外部数据服务提供。这直接决定采集端要不要做校验、要不要做去重、要不要做人工复核。媒体与硬件设备决定接入方式：手工录入、文件导入、接口推送、设备直连，四种方式的容错策略完全不同。

接受者与输出形式决定呈现层的设计。文档特别强调，无论接受者收到的是打印输出、屏幕字符、图形、警铃、电脉冲还是磁盘磁带，都要具体说明。这个列举看似老旧，但它传递的原则是对的：输出不只是界面，任何形式的数据交付都是输出，都要被定义。

值域与量纲是最容易被合并掉的两项。值域约束合法性，量纲约束可比性。数字型数据要给出度量单位、增量步长、零点定标；非数字量要给出每一种合法值的形式和含义。少了量纲定义，两个子系统用不同单位交换同一个物理量，产生的错误极其隐蔽——数值都在合法范围内，只是整体差了一个系数。

频度决定采集架构。文档要求，如果数据输入是随机的，应给出更新处理的频度的平均值或其他度量。这一条直指批处理与流处理的选型：日均一次和每秒十次，是两套完全不同的技术栈。频度不写，架构选型就没有依据。

预处理一节还要求给出适合应用的数据格式、预定的通信媒体和输入时间要求，并对需要模数转换的数据说明转换方法和转换因子。这一条把采集链路的边界划到了「数据进入系统之前」，明确了哪些转换由外部承担、哪些由系统内部完成，避免责任真空。

最后一节「影响」要求说明数据要求对设备、软件、用户、开发单位可能产生的影响，举的例子是「要求用户单位增设某个机构」。这一条把文档的视野从技术扩展到组织：如果采集方案要求用户侧新增岗位或改变现有流程，那它就不只是技术决策，而是组织决策。把它写进范围文档，等于提前告知所有相关方这项变更的完整代价。

5. 常见问题排查：五类翻车现场和它们的根因

5.1 功能表齐全但性能条款全空

现象：需求规定一章的功能条目写了上百条，精度、时间特性、灵活性三节各留一句「满足业务需求」。项目按期交付，验收阶段对方拿出一份并发压测报告，指出某核心查询在真实数据量下耗时超过十秒，判定不通过。

原因：性能条款空缺导致验收标准缺失，双方对「够快」的理解从未对齐。开发方按功能可用为目标实现，验收方按实际体验为目标判定，中间没有任何书面依据。

解决：把所有可量化的性能指标前置到需求阶段，按响应、更新、传送、计算四类分别给出数字，并注明测量条件——数据量级、并发数、硬件配置。测量条件不写，数字就没有意义。

5.2 假定与约束一栏留白

现象：任务概述里的假定和约束只写了「按计划推进」。项目中期第三方接口延期两个月，整个集成计划崩塌，复盘时发现所有人都默认对方会按时交付，但没有任何一份文档记录过这个前提。

原因：假定默认成立、无需言说，因此最容易被略过。而恰恰是这些未言说的前提，构成了计划的真实基础。

解决：把假定逐条列出，每条附上「若不成立时的应对」。这份清单同时可以当作风险登记表使用，评审时逐条确认，能把大部分隐性风险提前暴露。

5.3 数据规模估算缺失导致容量事故

现象：数据管理能力一节写「数据量随业务增长」，没有具体数字。系统上线四个月后主表突破千万行，查询开始超时，此时才发现索引设计和分区策略都没有预留扩展空间。

原因：缺少当前规模、增长率、峰值系数三个基础数字，存储设计只能按最小可用原则做。而最小可用在数据量增长面前没有任何缓冲。

解决：即使精度有限，也要给出量级估算，并明确写出估算依据——用户数乘以人均日操作次数乘以单条记录大小乘以保留周期。估算方法本身比估算结果更重要，因为它可以被复核和修正。

5.4 接口只写协议不写语义

现象：接口一节写清了通信方式和编码格式，联调第一天发现双方对同一个状态字段的取值理解不一致，一方认为 1 表示成功，另一方认为 1 表示处理中。字段没写错，含义错了。

原因：协议规范描述的是传输格式，不描述业务语义。语义对齐依赖人工沟通，而人工沟通的结论没有落到文档上。

解决：为每个跨边界字段建立数据字典，写明名称、类型、值域、每个取值的业务含义、空值语义、时间字段的时区约定。这份字典应该作为接口一节的附件，与协议定义同等级别维护。

5.5 参考资料不写版本导致依据失效

现象：设计阶段依据某份外部规范实现，交付前对方发布新版规范，字段定义变更。由于参考资料一节只写了标题没写版本和日期，无法确认当初依据的是哪一版，也无法追溯哪些实现需要同步调整。

原因：标题确定内容，但不确定版本。缺少版本和日期，引用就失去了时间锚点。

解决：所有外部引用一律记录标题、编号、版本、发表日期、获取来源五个字段，并在正文引用处标注对应的版本。规范升级时，通过版本号可以快速定位受影响的条款范围。

6. 设计取舍：这套五段式为什么故意保留「笨重」

五段式的结构在今天看来确实笨重。功能列表可以用看板管理，性能指标可以写进非功能需求清单，数据字典可以放在协作工具里，为什么还要用一份长文档把这些东西全串起来？

因为这份文档真正要解决的，不是信息记录问题，而是多方对同一组边界达成一致的问题。分散的清单各自可以很轻，但它们没有共同的语境。功能列表里的一条「支持批量导入」，脱离了引言里的用户特点、任务概述里的并发规模、数据要求里的值域定义，就是一句无法判定的话。五段式的取舍是把语境和条款绑在一起，代价是篇幅，收益是任何一条条款都可以沿着结构回溯到它的前提。

另一个经常被提出的疑问是：这套结构与迭代式开发是否冲突。答案是它约束的不是开发节奏，而是变更基线。迭代改变的是「什么时候做什么」，范围文档定义的是「做到什么程度算完成」。没有这份基线，每一次迭代的完成标准都只能重新协商，而协商成本会随着参与方增多而快速上升。

验证这份文档是否真的有效的办法，我常用一个：找三个没参与编写的人，分别扮演开发、测试、验收，让他们各自只读文档、不看其他材料，然后独立回答同一组问题——这个功能在什么情况下算做完、这个数值在什么范围内算合格、这条数据变了要通知谁。三个人答案一致，文档就是有效的；出现分歧的地方，就是条款还缺定义的地方。这个方法不需要任何工具，但能暴露绝大部分隐藏歧义。

我自己的血泪经验是：范围文档写得再吃力，也别在「假定和约束」「数据约定」这两节上偷懒。其他章节写得粗糙，最多是后期返工；这两节留白，等于把项目最贵的两类风险——前提失效和边界失控——完全交给运气。从那以后我每次接手一份范围文档，都会先把这两节单独拉出来过一遍，逐条问「如果不成立会怎样」，答不上来的当场补。希望帮到你。

本文还有配套的精品资源，点击获取