企业官网建设流程全解析

简介：IPD产品开发各阶段文档清单及过程要求是一份面向产品经理、研发、测试、质量及供应链人员的流程规范参考，适合正在推行或优化IPD流程的团队。资源包内含1个PDF文件，大小仅47KB，但对概念、计划、开发、试生产、量产各阶段都给出了明确的文档地图。概念与计划阶段涉及产品需求说明书、客户需求调研记录、系统设计说明书、总体测试策略等，强调涵盖功能、性能、可靠性、兼容性等多维需求；开发阶段涵盖软硬件技术规格、PCB原理图、结构设计图、自测报告及转测试说明，逐项指定责任角色与评审参与方；试生产与量产阶段则包括版本计划、Beta测试、用户资料、营销资料、BOM清单、元器件规格与检验标准、包装设计、制程工艺流程图等交付物，并细化到新引进器件需单独输出规格描述文档和质量检验标准。已有1156人学习下载，可帮助团队对齐IPD各阶段交付物标准，建立可控的评审机制。

1. 这份IPD文档清单，先解决研发管理最烦的三个问题

一份名为“IPD产品开发各阶段文档清单及过程要求”的文档，在很多公司里要么被当成行政负担，要么被当成万能解药。实际做研发流程的人看它，应该抓住三个价值：第一，把产品开发从“拍脑袋推进”变成“按阶段验收”；第二，把评审从“会议室吵架”变成“对着清单和证据逐条确认”；第三，把人员流动带来的信息断层用文档基线接住。

它适合正在推IPD体系、要搭新产品开发流程的研发负责人、项目管理和质量工程师，也适合想在开发周期里减少返工的产品经理。下面我把这套清单背后的逻辑、每个阶段要交什么、以及落地时最容易翻车的地方拆开讲。

2. 先看骨架：IPD六个阶段和两类评审决定文档怎么分布

2.1 从概念到生命周期：IPD阶段划分与文档流向

IPD（集成产品开发）的标准做法是把产品开发切成六个阶段：概念、计划、开发、验证、发布、生命周期。每个阶段有明确的入口和出口条件，文档清单就是这些条件最直接的物化形式。概念阶段要证明“值不值得做”，计划阶段要证明“能不能做、怎么做”，开发阶段要证明“做得对不对”，验证阶段要证明“是否达到上市标准”，发布阶段要证明“是否可以交给市场和量产体系”，生命周期阶段则管产品退市前的变更和末端维护。

举个真实的例子，某通信设备团队在没引入IPD之前，硬件开发到一半才发现需求理解有偏差，改一次结构件要两个星期。引入IPD之后，概念阶段的Charter文档把目标市场、产品定位、关键需求写成白纸黑字，计划阶段的系统设计规格把硬件、软件、结构之间的接口定死，后面开发阶段基本是照着文档执行。这就是阶段划分的价值：把错误尽量留在“纸上谈兵”的阶段，而不是留在开模和量产阶段。

文档流向是一条清晰的链条：概念阶段的产出是计划阶段的输入，计划阶段的产出是开发阶段的输入，每一步都有前一阶段评审通过后的基线版本做支撑。很多刚接触IPD的人以为文档清单只是“行政要求”，其实它解决的是信息传递问题。一份能追溯的需求文档，比十次“我上次不是说过了吗”的口头沟通都管用。

用表格看最直观：

| 阶段 | 核心文档产出 | 进入下一阶段的门槛 | | 概念 | 项目任务书、初始产品需求、初步业务计划 | CDCP决策评审通过 | | 计划 | 正式业务计划、系统设计规格、产品需求规格 | PDCP决策评审通过，TR2/TR3达成 | | 开发 | 详细设计文档、模块测试记录、样机报告 | TR4A/TR5技术评审达成 | | 验证 | 系统测试报告、β测试报告、可靠性报告 | TR6技术评审达成 | | 发布 | ADCP材料、发布清单、量产BOM、说明书 | ADCP决策评审通过 | | 生命周期 | 工程变更单、停产计划、经验教训库 | LCP评审通过 |

表格里的“门槛”是过程要求里最硬的信息。很多项目延期，不是因为工程师干活慢，而是因为到了评审点才发现该交的文档没交、该做的测试没做。文档清单把“门槛”提前写清楚，团队就能按时间倒排，在评审点之前把证据备齐。

2.2 DCP和TR不能图省事合并：文档在两类评审里的角色与顺序

DCP和TR是IPD过程要求里的两条线。DCP是业务决策评审，回答“这笔钱该不该继续投”；TR是技术评审，回答“技术风险清没清干净，能不能进入下一个技术阶段”。文档在两个体系里的角色完全不同：DCP评审材料是业务计划、财务模型、风险与机会分析；TR评审材料是需求规格、系统设计、测试计划、测试报告。

两者数量也不一样。一个完整的产品开发周期中，DCP一般三到四次：概念决策评审（CDCP）、计划决策评审（PDCP）、可获得性决策评审（ADCP），生命周期阶段可能还有生命周期决策评审（LCP）。而TR从TR1排到TR6，覆盖从需求到发布的整个技术链路。文档在这两套评审里各有一份“齐套检查单”，缺一条都过不去。

TR的顺序和关注重点如下表：

| 技术评审 | 时机 | 必须齐套的文档 | | TR1 | 概念阶段 | 初始产品需求、市场调研、竞争分析 | | TR2 | 计划阶段早期 | 产品需求规格、系统设计规格、测试策略 | | TR3 | 计划阶段中期 | 概要设计、模块划分、关键接口定义 | | TR4/TR4A | 开发阶段 | 详细设计、单元测试记录、样机试制报告 | | TR5 | 开发与验证交界 | 集成测试报告、缺陷收敛数据 | | TR6 | 验证阶段末 | 系统测试报告、β测试报告、发布候选评估 |

过程要求里有一条常被忽视：TR必须先于DCP，而且TR结论要随DCP材料一起提交。也就是说，计划阶段的业务决策，必须带着技术可行性结论。如果没有TR2/TR3通过，PDCP就等于在赌技术方案没问题。常见做法是先开技术评审，形成《技术评审报告》，再把结论页附到DCP材料里，DCP决策层看的是“技术风险已收敛到可接受范围”这个结论，而不是去看TR会议纪要。

还有一个实操细节：TR和DCP的会议记录模板要分开。TR记录用“问题-责任人-期限”三栏，DCP记录用“决策结论-附带条件-资源授权”三栏。很多团队把两份记录混在一个“评审记录模板”里，后期审计时完全分不清哪个决定是技术层面的、哪个是业务层面的。这属于过程要求里“评审留痕”的典型翻车点。

注意：文档齐套不是“有文档就行”，是“文档版本受控、内容经过评审、与上一阶段基线一致”。否则评审现场拿出来的材料，和审计时看到的那份不是一回事。

3. 逐阶段拆文档清单：从Charter到经验教训库，每个阶段交什么

3.1 概念阶段：Charter和初步业务计划，把“想清楚”变成文档

概念阶段是整个链条上最短但最要命的阶段。文档清单上通常只有四类：项目任务书（Charter）、初始产品需求、初步业务计划、竞争者与市场分析。Charter一般由产品经理牵头，研发代表、市场代表、财务代表参与，核心内容要回答四个问题：做给谁、解决什么问题、和谁竞争、凭什么能赢。很多团队在这里犯的错是把Charter写成“想法汇总”，但IPD过程要求里Charter必须落到可验证的假设，比如目标市场份额、定价区间、上市时间窗口。

实际项目里，Charter写得好不好，判据很简单：把“目标客户是谁”和“核心卖点是什么”这两段拿去给三个没参与的人读，看他们能不能复述出同一句话。如果能，说明定义清晰；如果各自理解不同，说明任务书还不具备做决策的基础。我见过最夸张的一份Charter，目标市场写了“全球”，目标客户写了“行业客户”，定价区间“待定”——这种材料递到CDCP，决策层根本没法拍板。

初始产品需求在这个阶段不需要完整细化到每条功能，但要覆盖“关键业务场景”和“关键非功能需求”。方式可以是用户访谈记录、现场调研纪要，甚至竞品拆解结果。初步业务计划用来估算投入产出，精度不要求到金额分毫不差，但要有量级、有假设、有敏感因素说明。

概念阶段过程要求，核心是三条：CDCP评审前，Charter必须经过产品规划团队预审，预审意见随材料提交；需求条目必须带来源标签，每条能追溯到客户、市场或内部策略；初步业务计划里的财务数据至少经过财务代表确认。做到这三条，才能避免概念评审变成“领导拍脑袋”。文档数量不多，但每份都要能经得起追问。

3.2 计划阶段：系统设计和业务计划是开发前的最后一道防线

计划阶段是文档最密集的阶段。核心交付物包括：产品需求规格（PRD）、系统设计规格（SDS）、正式业务计划、端到端项目计划、测试策略与测试计划、物料与供应策略。系统设计规格是这一段的重头戏，它把“需求”翻译成“技术架构”：硬件框图、软件模块划分、关键接口定义、可靠性分配、安全性设计。系统设计是一门“翻译”工作，翻译错了后面全错。

PRD在这个阶段必须达到“可测试”的程度。每条需求要有唯一编号、优先级、验收标准。没法验收的需求不要写进PRD，不然TR评审和后面的测试计划都无从谈起。我建议PRD用表格组织，ID、需求描述、优先级、验收标准、来源五列。这样TR2评审时，评审委员可以一条条过，而不是在一大段散文里找重点。

正式业务计划是第二个重头戏。除了概念阶段的初步计划，还要加入：研发投入成本明细、产品生命周期收益预测、投资回收期、风险及应对计划、退出条件。特别注意“退出条件”这一条，它解决的是沉没成本问题——如果产品阶段验证证明市场不及预期，是靠什么条件触发止损。

计划阶段的过程要求里，最值得记的是：PDCP的评审门槛是TR2和TR3双通过。TR2检查“系统设计完不完整、需求有没有遗漏”，TR3检查“概要设计能不能落地到模块和分工”。如果TR2没过就冲PDCP，大概率结果是业务计划通过了，开发阶段又回头改需求，返工成本远超省下的那点评审时间。

这个阶段还要把“端到端项目计划”文档做到可执行，不是一张甘特图就完了。它要包含人力计划、关键依赖、里程碑、风险储备。过程要求上，项目计划在PDCP后就要基线化，后续变更必须走项目变更审批，防止开发过程中“范围蔓延”却没有记录。

3.3 开发阶段：详细设计文档和测试记录是过程质量的第一手证据

开发阶段容易出现“做完才算完”的心态，但IPD过程要求恰恰要求“边做边留痕”。这个阶段的文档清单包括：详细设计文档（软件、硬件、结构分册）、模块单元测试报告、集成测试报告、样品试制报告、工程变更记录。

详细设计文档要细到什么程度？标准是“换一个没参与过设计的工程师，拿到文档能继续开发”。这个标准很多人觉得苛刻，但真实项目里人员流动率极高，没有这一条，一个核心开发离职整个模块就成黑匣子。注意，详细设计不是把代码注释抄一遍，而是要写清楚模块职责、输入输出接口、状态机、异常处理路径、关键算法选型理由。我一般要求开发人员在设计文档里至少留一张模块数据流图，这张图比文字更能暴露理解偏差。

模块单元测试报告要包含测试环境、用例、结果和缺陷记录。不要求写得像论文一样漂亮，但必须让TR评审委员能判断“这个模块到底测没测够”。常见问题是只写用例数和通过率，不写覆盖范围。比如一个协议栈模块，没测异常报文，通过率100%也不能说明问题。所以单元测试报告里一定要有一栏“未覆盖说明”。

集成测试报告重点是接口测试：软硬件接口、模块间通信、电源时序、异常恢复。样机试制报告的看点不是“样机点亮了”，而是试制中发现的问题清单、根因分析、整改状态。把问题写透，TR4A评审才能给出有效结论。

过程要求里有一条常被审计点：每次工程变更（ECR/ECO）必须同步更新关联设计文档的版本。这条写进流程后，文档滞后问题才能从机制上解决。实操做法是把“关联文档更新情况”列在ECR表单里，QA在关闭ECR前检查关联文档版本是否已升级，没升级不关闭。

3.4 验证与发布阶段：测试报告、发布清单和经验教训库

验证阶段进入“用证据说话”的阶段。文档清单包括：系统测试报告、可靠性测试报告（老化、环境、EMC）、β测试报告、性能测试报告、缺陷统计分析报告。系统测试报告要把PRD里每条需求对应到测试用例和结果，做到“需求-用例-结果”三列对齐。这种对齐表格在评审会上非常有用，能一眼看出哪些需求没覆盖。

缺陷统计分析报告是验证阶段容易被低估的文档。它不光统计缺陷数量，还要分析缺陷密度、趋势、遗留风险。评审委员看这份报告，判断的不是“有没有bug”，而是“bug的收敛趋势是否符合发布要求”。如果连续两轮测试缺陷没有明显收敛，TR6就不该给“有条件通过”。

发布阶段的文档转向“上市准备”：可获得性决策评审（ADCP）材料、产品发布清单、量产BOM清单、产品说明书、认证证书、客服与技术支持准备材料、培训材料。ADCP材料必须包含订单承诺与供货能力，因为发布不是研发自己的事，是把整个公司的供应链、服务、销售拉到一个节奏上。这里最常见的问题是“研发觉得能发布了，但服务部门还没准备好备件”。ADCP材料里加一页“服务准备度检查表”，就能提前暴露这种断层。

过程要求上，TR6是ADCP的前置技术评审。TR6检查候选版本的测试结论、缺陷收敛趋势、已知问题及规避措施，结论达到“可发布”后才能把材料提交ADCP。验证阶段结束后，还有一份常被忽视的文档：经验教训库。它记录了本产品开发过程中哪些环节问题高发、纠正措施是什么。经验教训库的价值不在写，而在下次立项评审时必须回看——否则就是写给别人看的废纸。

这个阶段的文档汇总如下：

| 阶段 | 必须文档 | 评审关口 | | 概念 | Charter、初始产品需求、初步业务计划、竞争分析 | CDCP | | 计划 | PRD、SDS、正式业务计划、端到端项目计划、测试计划、物料策略 | PDCP（TR2/TR3通过） | | 开发 | 详细设计文档、单元测试报告、集成测试报告、样机试制报告、ECR记录 | TR4A/TR5 | | 验证 | 系统测试报告、可靠性报告、β测试报告、缺陷统计分析 | TR6 | | 发布 | ADCP材料、发布清单、量产BOM、说明书、认证、培训材料 | ADCP | | 生命周期 | 工程变更单、停产计划、经验教训库 | LCP |

4. 落地一套可用流程：文档矩阵、模板裁剪、版本基线与评审Checklist

4.1 从PDF到可执行：把清单拆成文档矩阵和模板目录

拿到一份“IPD产品开发各阶段文档清单及过程要求.pdf”之后，第一步不是给全员培训PPT，而是把PDF里的清单转成可操作的四样东西：文档矩阵、统一目录、模板骨架、评审要素表。

文档矩阵是最重要的。用表格或在线文档维护，至少包含这些列：阶段、文档编号、文档名称、责任角色、评审点、状态。阶段要落到六个IPD阶段之一；文档编号与模板文件前缀对应，比如PRD-01、SDS-02；责任角色不要写部门，要写角色名，比如PDT经理、系统工程师、开发代表、测试代表，否则后面推诿时找不到人。评审点写明“在哪个TR或DCP前必须完成”，状态区分草稿、受控、归档三种。

建立矩阵后，创建统一目录树。常见做法是：

docs/ 00_Templates/ 01_Concept/ 02_Plan/ 03_Development/ 04_Qualification/ 05_Launch/ 06_Lifecycle/

每个阶段目录下放对应文档模板。这里要强调一下：目录树不是拿来好看的，它是后续归档、检索、审计的地基。没有统一目录，文档散落在各人网盘里，文档清单再完整也白搭。

做模板是第三件事。模板不要直接复制网上流传的几百页版本，要根据自己团队的实际情况裁剪。我的裁剪原则只有一条：这份文档的读者是谁，他们需要用这份文档做什么决策，就保留与决策相关的章节，没有读者、不做决策的章节一律删掉。比如内部预研项目的Charter，可以不用填复杂的财务模型，但“技术风险与可行性结论”必须填。

评审要素表是第四样东西，它把每份文档的“质量标准”写成检查项。比如PRD评审要素包括：需求可达性、编号是否唯一、验收标准是否明确、是否包含非功能需求。评审要素表做出来之后，评审会才有依据，而不是靠评审委员的个人感觉。四样东西齐了，PDF才真正变成流程，而不是挂在共享盘上的一份参考资料。

4.2 文档命名、版本与基线：让文档能追溯而不是躺在网盘

文件名规则直接决定归档能不能用。我建议的命名规则是：产品代号-阶段代号-文档类型-版本号.扩展名。几个真实例子：

PH9-02-PRD-v2.3.docx ENV-03-SDS-v1.0.docx CPE-04-QTP-v0.6.docx

阶段代号用01到06，对应六个IPD阶段；文档类型用英文缩写，PRD、SDS、QTP、TTR都是常见缩写；版本号用三位规则：v0.x表示草稿，v1.0表示第一次评审冻结，v1.x和v2.0表示变更后的受控版本。文档评审通过后，状态从“草稿”改为“受控”，状态变更在文档头记录，写明修改人、修改日期和变更理由。

文档基线的含义是“一组处于同一版本的文档集合”，代表项目在某个时间点的完整状态。实现上常用两种方式：一是版本管理工具打tag，用标签把本次评审涉及的所有文档版本钉住；二是手工归档，在评审通过后把文档复制到带日期的基线目录。第一种更可靠，因为tag可以指回任意历史版本，手工复制容易出错。

过程要求上，基线变更必须走CCB（变更控制委员会）审批。CCB一般由PDT经理、系统工程师、QA、市场代表组成。不要嫌这个流程重，没有CCB，就会出现开发顺手改文档、技术支持拿错版本去给客户做指导的情况。这里最典型的翻车是：没有CCB的团队，工程师改了一版需求文档，直接放在共享盘上覆盖了原文件，后来审计发现变更无记录。有了CCB，变更有记录，配置管理才真正闭环。

注意：版本管理工具里的文档目录，要和实际发布目录保持一致。文档被复制到多个地方，是最容易产生“版本分叉”的根源。

4.3 用检查单卡评审：评审物料包和结论分级

为了保证TR评审不流于形式，我一般会让QA在评审会前准备好“评审物料包”。它包含四部分：本阶段要求齐套的文档清单，每份带版本号；每份文档对应的评审检查要点；本场评审需要决策的问题清单；上轮评审遗留项的整改证据。

物料包的好处是把评审会从“听汇报”变成“对证据”。主持人按物料包顺序推进，先看文档齐套性，再看每个决策项的证据，最后形成结论。而不是让每个模块负责人上来讲PPT，讲完就散会。

评审结论建议分三档：

| 结论 | 判定条件 | 后续动作 | | 无条件通过 | 所有P0项满足，P1项不阻碍进入下阶段 | 基线冻结 | | 有条件通过 | P0项满足，P1项有明确计划且不阻碍进入下阶段 | 设整改期限，带条件进入下阶段 | | 打回重审 | 存在P0项不满足 | 必须整改后重新评审 |

P0、P1、P2的分级在评审要素表里提前定义好。P0是不满足就不能进入下一阶段；P1是可以在本阶段内整改；P2是建议改进。如果一份文档的P0项没过，评审结论只能是“打回重审”，不要为了赶项目进度而降级成“有条件通过”。这个口子一开，后面所有评审都会照着钻空子。

“有条件通过”是最高频的评审结论，也是最有风险的一种。落地时关键在于“条件是否可验证”。条件必须写成“在什么时间点，由谁提交什么证据”，而不是“尽快改进”。我见过太多评审结论写“尽快补充测试”，结果三个星期没人管。要让过程要求落地，评审结论本身就得分得出责任和时限。

5. 避坑：IPD文档体系落地最常见的5个翻车现场，以及怎么救

5.1 文档写完了没人看，评审走过场

现象：评审会成了“念PPT”，评审委员没提前读文档，问的问题集中在格式、错别字、字号上，真正该抠的技术决策反而没人提。原因：评审的输入不是文档，而是汇报PPT，文档只是“存档”用的；评审委员也没有义务提前阅读。解决：评审前48小时发出物料包，要求评审委员在检查单上预填意见；没有预填意见的不计入评审有效票。如果连续两次评审出现“预填意见少于三个”，要考虑评审委员人选是否需要调整，或者检查单设计是否太泛。

5.2 模板过于复杂，一线工程师不愿填

现象：一份文档模板30页，一半是“公司愿景、团队概况”等与开发无关内容，工程师抵触，填写质量差。原因：模板设计没有按文档读者裁剪，照搬了大公司模板，没考虑自己团队的实际规模。解决：按“谁读、读什么、用来做什么决策”重新设计模板，把“公司背景”这类冗余章节删掉；用字段化checklist代替长文本。模板改完后让一个没参与模板设计的人试填，看ta是否能明确每一步该填什么，填不出来就继续简化。

5.3 文档与产品脱节，发布后没人维护

现象：开发阶段的详细设计文档与最终实现不一致，版本已经变了，文档还停在v1.0。外场问题排查时，照着文档查线序，最终实现早就换了连接器。原因：没有把文档更新纳入变更流程，也没有在发布前做“文档与实物一致性”检查。解决：把“设计文档与代码、样机一致性核对”作为TR5/TR6的硬性检查项；每次ECR变更必须同步更新关联文档清单，QA在关闭ECR前核对版本。血的教训：一个外场问题排查到晚上，后来说硬件连接器脚位定义在v1.1改过，文档还停在v1.0，排查方向全错了。文档滞后，就是把一个小问题放大成通宵。

5.4 把TR和DCP混成一锅粥，评审层级混乱

现象：技术评审和业务决策评审放在同一场会上开，技术问题侵入业务决策，或者业务风险被技术噪音掩盖。原因：评审目标不同、参与者不同、输出不同，组织者为了省会议时间强行合并。解决：分开组织和记录。TR输出“技术风险清单和整改项”，DCP输出“go/no-go决策和业务条件”。会议记录分两个模板，结论分开写。如果确实需要连续评审，先开TR，隔天再开DCP，不要让技术专家和决策层在同一张桌子上面面相觑。

5.5 全流程一次性推，组织消化不良

现象：新团队直接按完整IPD文档体系推，文档量大、周期变长、士气下降，甚至传出“IPD就是文档化”的负面评价。原因：流程成熟度不够，文化还没建立，一上来就要求所有文档齐套，一线被压垮。解决：按“最小可行流程”裁剪，先跑通计划、开发、验证三个阶段的文档闭环，再逐步补概念阶段和生命周期阶段。每个季度只加一两个文档要求，让团队逐步适应，别指望三个月推完全套。

6. 让文档清单真正生效：最小可行流程与三个月的验证方法

6.1 从“全流程重文档”改成“按项目分类裁剪”

落地IPD文档体系，头三个月先别追求全量。先把项目分成三类，每类定义不同的文档要求。这个过程本身，就是对PDF里过程要求的二次解读。

| 项目类型 | 必须文档 | 可裁剪内容 | | A类：新平台/新产品开发 | 全部文档，一个不少 | 不裁剪 | | B类：现有产品改进型 | PRD、SDS、测试报告、发布清单 | 概念阶段合并为Charter摘要 | | C类：小需求/维护 | 需求记录、测试结果、变更记录 | 不要求业务计划和生命周期文档 |

这样做的好处是让团队把精力放在真正有风险的交付物上。C类项目如果也要求几十页文档，一线只会用“敷衍”来反馈制度。

6.2 用两个指标验证文档体系是否有效

三个月后别问“大家觉得流程怎么样”，要看数据。两个指标最直接。第一个是文档评审驳回率，指因为文档缺失或质量不合格被打回的比例。这个指标高，说明清单量和团队能力不匹配，要么裁剪模板，要么补培训。第二个是文档返工率，指因为需求或设计文档不清导致开发返工的工作量占比。这个指标代表文档质量对项目成本的直接影响。这两个指标如果三个月内没有下降趋势，说明文档体系只是在“造文件”，没在“造价值”。

6.3 我现在的习惯：文档先于评审，评审记录跟着基线走

我现在负责产品开发流程时，有个坚持了很久的习惯：方案文档必须比代码早一个评审周期。先写设计文档，评审通过，再写代码；代码写完，回到文档上核对一遍有没有偏差，有偏差先改文档再提测。这样文档不是事后补的作业，而是开发过程的一部分。

评审记录我也跟着基线走。每次TR或DCP通过之后，把结论、遗留问题、责任人作为一条记录挂到基线的tag下面。后来项目换人、审计追溯、查“当初为什么这么定”，翻基线记录比找聊天记录靠谱得多。IPD产品开发各阶段文档清单和过程要求，本质是把研发的每一次关键决策留下可追溯的证据。流程重不重，取决于怎么裁剪；流程有没有用，取决于证据有没有被真正用起来。希望帮到你。

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