企业官网建设流程全解析

简介：软件项目立项书标准模板，是项目启动阶段的核心文档，面向项目经理、产品负责人及项目干系人，用于清晰定义项目目标、范围、预算与风险，规范立项评审与后续执行。资源包内共1个Word文档文件，压缩后大小83KB，下载解压即可直接编辑使用。该模板已有1576人学习下载。模板结构完整，涵盖项目名称与版本、拟制/审核/批准日期、修订历史记录、目录、引言、项目概述、项目目标、规定与约束、工作范围、应交付成果、项目验收方式、项目团队组织与人员分工等关键章节，并预留填写位置，实际项目中可按需替换项目信息与时间节点，参照目录层级即可快速调整篇幅，还可依据团队规范修改字体与样式。适合需要快速编写规范立项文档的软件项目团队参考。

1. 立项书的价值不在字数而在“敢签字”：一次评审会最多给你二十分钟

软件项目立项书写得好不好，和你写作文的水平没有太大关系。它的本质是一份“花公司钱、占公司人、用公司时间”的决策文档：系统的范围、业务价值、技术路线、成本测算、里程碑和风险预案都写在里面，目标是让评审委员会在二十分钟内判断“这项目可以启动”。我见过不少技术细节写得极漂亮的立项书，反而在成本明细和里程碑上翻车，因为评委问的不是“功能有多炫”，而是“钱怎么算的、周期怎么保证的”。这篇笔记按我实际评审和撰写立项书的经验展开，覆盖决策逻辑、WBS拆分、成本脚本、软著与资质条款、常见坑和敏感性分析，新手能照步骤走，老手也能补上自己漏掉的校验手段。

2. 立项书不是文档而是预算争夺工具：六大必答问题与评审视角

开门见山：一份立项书说到底是回答六个问题——做什么、为什么做、怎么做、花多少钱、做多久、万一出事怎么办。很多团队把精力花在“怎么做”上，写了三十页技术方案，把另外五个问题压缩到两页，结果评审会上被追问到一句话都答不上来。原因很简单：评审委员并不都是技术人员，他们关心的是投入产出和可交付性。我一般建议动笔之前先以评审身份把六个问题各写一段答案，答不上来的地方就是立项书里要补的数据。

2.1 立项书在项目生命周期里的位置：写不好会拖累排期与验收

立项书不是项目启动之后才写的文档，它处在需求评审和开发排期之间，承担两层功能。对内，它是项目资源的正式申请单据，人力、服务器、第三方软件授权、测试环境都靠它向预算委员会要；对外，它是项目验收和结项时的基准，后续的变更申请、范围蔓延控制、延期追责都拿立项书做锚点。立项书一旦写模糊，比如“开发周期约六个月”这种话，轻则验收时被甲方逐字抠合同，重则内部考核时扯皮到年底。

常见做法是把立项书拆成两份材料：一份一页纸摘要，用于评审会前给委员快速扫读；一份完整版，包含详细测算和风险预案。摘要页只需要写清楚三件事：项目要解决什么业务问题、总预算多少、什么时候交付。评审委员如果连摘要都没看懂，详细版写得再周密也没有意义。完整版写了六十页、摘要页只有一段“本项目将建设一套系统平台”的立项书，等于没写。

立项书在生命周期里还有一个隐性的作用：绑定时点。软件著作权申请、第三方软件采购、硬件到货周期都挂在里程碑上，立项书排期一旦拍脑袋，后面所有环节都会被连锁拖累。比如承诺三个月后提交软著申请材料，但代码还没进测试，材料就只能从没验证过的界面截图里凑。这就是典型的排期没考虑资产申报时点导致的返工。这类问题在项目启动半年后才暴露，那时预算和人力都已投进去，几乎没有后悔药可吃。

2.2 评审委员只看三样东西：总预算、里程碑、风险表

我参与过多次立项评审，也旁听过不少被拒项目，总结下来评审委员的阅读习惯高度一致：先翻总预算，再翻里程碑，最后翻风险表。其余部分比如业务背景、技术方案，扫一眼标题就过。总预算被挑战的典型说辞是“这个数字怎么来的”，答不出测算过程，委员就有理由怀疑所有数字都不靠谱。里程碑被挑战的典型说辞是“为什么这么赶”或“为什么这么松”，对应的是排期缺少依据。

风险表被挑战的方式最隐蔽：委员不会质疑你列的风险本身，而是问“这些风险发生了怎么办”。很多立项书的风险表写“存在技术风险”，没有应对预案，这种写法等于没写。评审委员要看到的是每个风险都有触发条件、有影响范围、有回退方案，哪怕是“协调商务延长试运行期”这种非技术应对也算数。把这三块写扎实，评审会至少不会在硬问题上卡你。

这里有个容易被忽略的细节：预算表里要单独列一笔“不可预见费”，常见比例是总预算的5%到10%。不要觉得这笔钱不好申请，恰恰相反，没有这笔钱的项目一旦遇到第三方软件授权涨价或关键人员离职，就没有任何缓冲，只能打变更报告，在评审委员那里更减分。我在预算里都会留这笔，并在测算说明里写“用于应对人员变动与采购价格波动”，基本没被驳回过。

2.3 立项书的标准结构：一节对应一个决策问题

常见问题是章节和六个问题没对齐：业务背景写八页，成本测算一页带过。我推荐一节对应一个问题，评审想看哪块就能直接翻到哪块：

范围清单里最容易被忽视的是“明确不做什么”。立项时把边界划清楚，评审委员反而更信任你，因为“什么都做”的方案看起来就是一个黑匣子，没人知道投入从哪到头在哪。我一般会在范围章节末尾单独列一小段“本期不做”清单，比如“本期不含移动端、不做历史数据迁移、暂不开放第三方API”，这一小段在评审会上几乎每次都挡住范围蔓延类问题。

技术方案章节也要控制长度，不要写成产品说明书。评审想看的是技术路线选择的依据和约束条件，不是每个模块的功能列表。写完这一章，你应该能回答三个问题：技术栈选型的理由是什么、系统边界划在哪、外部依赖有哪些。答不上来的那条，就是立项书里最虚的部分，也是评审会上最可能被抽问的部分。

3. 把立项书写成可执行方案：素材清单、WBS拆分与成本测算脚本

立项书在评审委员眼里不是文学创作，而是可审计的计划。我最常用的方法是：先像做需求调研一样采集素材，再拆WBS到能估算的任务包，最后用脚本把成本算清楚。这样写出来的预算表，每一行都能回查到来源，而不是拍脑袋。

3.1 先采集素材再动笔：访谈对象、现场记录与差异清单

动笔之前至少做三轮调研，否则立项书里全是空话。第一轮访谈业务方，搞清楚现状流程和痛点，提纲围绕“现在怎么做、哪里最痛、希望新系统解决什么”展开；第二轮访谈技术团队，确认现有系统边界、可复用组件、运维能力，很多立项书翻车就是因为没确认现有系统里已经有一半功能可以复用；第三轮访谈财务或采购，确认硬件采购流程和第三方软件授权费用，这块直接决定预算表里的采购行。

我一般会在现场记录里固定三个字段：日期、受访人、结论摘要。结论摘要必须写明“谁在什么条件下确认了什么”，例如“运维负责人确认现有服务器剩余资源可以支撑试运行”。这个习惯的价值在评审会上会体现出来：当委员质疑预算里的服务器采购时，你能直接引用这条记录说明为什么不需要买新机器。没有记录支撑的立项书，数据都显得像临时编的。

素材采集之后还要做一次“差异清单”：现状能力、目标能力、缺口能力三列，立项书里的工作范围其实就是缺口那一列。很多团队把现状和目标写到一起，导致评审委员分不清哪些是已有功能哪些是新建功能，预算自然显得虚高。我习惯把差异清单放在立项书附件里，正文只引用缺口的汇总数字，委员要看明细时再翻附件。

3.2 把需求拆成两周以内的任务包：WBS拆分粒度与估算三值

WBS拆分是成本测算的前提。拆到什么粒度才合适？我个人的标准是：单个任务包的工作量不超过两周，最好控制在一周左右。粒度太粗没法估算，比如“完成数据迁移”这种包，不同团队做起来能从三天到三个月不等；粒度太细则管理成本过高，没必要把每个类的方法都拆成一个任务。任务包建议按“可交付物”命名，例如“编写数据迁移脚本并执行全量迁移”，而不是“做数据迁移”。

估算时不建议用单一值。常见做法是给每个任务包三个数：乐观工时、一般工时、悲观工时，然后按加权公式（乐观 + 4×一般 + 悲观）/ 6 算出期望工时。这个公式不需要精确到天，它的作用是逼着评估者把不确定性和风险在数字上体现出来。比如“对接第三方支付接口”乐观3天、一般5天、悲观12天，期望就是5.8天，这个5.8远比拍脑袋的“5天”抗得住追问。

拆完WBS之后要把每个任务包汇总到阶段维度，这样看得出哪些阶段特别重。我见过不少立项书把全部工作量压在开发阶段，测试和试运行只留两周，这种排期十有八九在验收时翻车。测试和试运行至少要占整个项目周期的30%，如果WBS汇总下来低于这个比例，说明阶段安排不合理，需要调整任务包归属或补充测试任务。

3.3 成本测算脚本：人力单价、人月数与总预算自动核算

人力成本占软件项目预算的大头，计算公式是：人力成本 = Σ(岗位单价 × 工作量人月数)。人月数口径要统一，常见口径是“一个人工作22个工作日为一个人月”。下面这个脚本是我常用的测算方式，输入每个岗位的人数和月数，自动汇总人力成本，叠加采购成本和不可预见费，输出一张可直接贴进立项书的预算明细表。

# 立项书成本测算脚本：按岗位汇总人力成本并叠加采购与不可预见费 # 使用前提：WBS 已按任务包估算出工时，并按岗位归类 from collections import defaultdict # 岗位单价（元/人月），按公司实际薪酬福利折算，非到手工资 unit_price = { "项目经理": 30000, "开发工程师": 25000, "测试工程师": 22000, "UI设计师": 20000, "运维工程师": 23000, } # 每个岗位投入的人月数，来源是 WBS 汇总，不是拍脑袋 man_month = { "项目经理": 4.0, "开发工程师": 12.0, "测试工程师": 6.0, "UI设计师": 2.0, "运维工程师": 1.5, } # 采购成本：硬件、第三方软件授权、云资源等 procurement = { "云服务器（一年）": 30000, "数据库同步软件授权": 45000, "双机热备软件授权": 28000, "测试手机与设备": 12000, } labor_cost = defaultdict(float) for role, months in man_month.items(): labor_cost[role] = unit_price[role] * months total_labor = sum(labor_cost.values()) total_procurement = sum(procurement.values()) subtotal = total_labor + total_procurement # 不可预见费：按常见 5%~10% 预留，比例写入测算说明 reserve_ratio = 0.08 reserve = subtotal * reserve_ratio total_budget = subtotal + reserve print("=== 人力成本明细 ===") for role, cost in labor_cost.items(): print(f"{role}: {cost:,.0f} 元") print(f"人力成本小计: {total_labor:,.0f} 元") print(f"采购成本小计: {total_procurement:,.0f} 元") print(f"不可预见费({reserve_ratio:.0%}): {reserve:,.0f} 元") print(f"项目总预算: {total_budget:,.0f} 元")

脚本逻辑不复杂，重点是口径：单价注释里写明“按公司实际薪酬福利折算，非到手工资”，这是评审委员最爱追问的地方。常见误用是把招聘网站上的月薪直接当单价，但项目人力成本包含五险一金、办公分摊、管理成本，通常要到税前工资的1.3到1.5倍。如果公司财务有统一折算系数，以财务口径为准。参数调整时只改unit_price和man_month两个字典就行，采购项按实际报价增删，不要直接改公式。

预算表建议至少拆到三类：人力成本、采购成本、不可预见费。人力成本对应WBS任务包，采购成本对应每一项硬件或第三方软件授权，不可预见费对应风险应对。这个结构在评审会上非常抗问，因为每一类都能回查到自己的依据，而不是一个孤零零的总数。脚本跑完后要人工复核一遍总数和明细是否能对上，避免粘贴时手误。

3.4 软件架构图要画到部署视角：给评审看的是边界不是类图

“软件架构图”这一节是技术团队最愿意写、也最容易写过头的地方。我见过的翻车案例是画了满满一张UML类图，评审委员看了五分钟也没找到系统边界在哪。立项书里的架构图用途不是指导编码，而是让非技术评委看清三件事：系统部署在哪、与哪些外部系统有接口、数据流向哪里。画到部署视角就够了，画到类视角属于职业惯性，反而模糊了重点。

我一般建议画两张图：一张系统上下文图，画系统、用户、外部系统三者之间的关系，用方框和箭头表示，不出现任何内部模块；一张部署架构图，画服务器、中间件、数据库的部署关系和网络分区。原则是“一张图讲一件事”，如果一张图里又要讲微服务拆分又要讲容灾切换，信息量过大，评审委员反而记不住。和架构图配套的是一段约束说明，写明“必须使用公司统一认证”“数据不得出内网”等硬约束。

架构图里最容易漏的是数据边界。比如系统需要从外部采集交易数据，评审委员就会追问数据存在哪、谁有权限访问、保留多久。这些不是架构图本身画的，而是架构图旁边要配的文字说明。我习惯在每张图下面写三条以内的边界描述，超过三条就说明图太复杂或范围没收敛。架构图位置放在技术方案章节开头，后面跟选型理由，顺序不能反，否则评委先看选型理由再看图，容易对不上。

部署架构涉及硬件采购时，要和成本测算章节联动。比如图里画了两台服务器做双机热备，成本表里就必须有对应采购项，图与费用不一致是立项书最常见的低级错误。我写完架构图后会把部署相关的采购项单独列一遍，和成本表逐项比对，确认每一台设备都能在预算里找到对应的一行。

4. 立项书里的资质、知识产权与技术选型条款：软著和软考证书为什么影响预算

这一章很多人会忽略，但它直接影响立项书的可信度和预算的完整性。评审委员里总有人会翻到知识产权和人员资质部分，问“公司有没有对应的软件著作权”“团队有没有相关的证书资质”。这些细节平时不起眼，在立项评审和后续招投标阶段却可能是硬门槛。

4.1 软件著作权在立项书里的三重身份：验收指标、资产登记与排期陷阱

软件著作权在立项书里至少要写三个位置。第一是验收指标，把“取得软件著作权登记证书”列为正式验收条件之一，这是软件项目最常见的资产产出；第二是资产登记，说明项目交付后形成的软著归属权，避免后续商业化时出现产权纠纷；第三是里程碑关联，软著申请的时点要和开发排期对齐。常见误区是把软著当成项目结束后的善后工作，实际上软著申请要等代码和文档齐备后才能提交，从材料准备到拿到登记证书通常要3到4个月，这个周期必须留出窗口。

软著材料准备的核心是三样：源代码文档、用户手册或操作说明、软件著作权登记申请表。源代码文档一般要求按前后各连续60页整理，不足60页的提交全部源码；用户手册要覆盖主要功能界面和操作流程，这些材料在开发中期就可以开始攒，不用等代码冻结。我在排期里一般这样处理：主体功能进入测试后启动材料整理，测试稳定后提交申请，证书收件时点放在试运行阶段。这样软著周期和项目周期并行，而不是串行，能省下两到三个月。

软著还有一个容易被忽视的作用：它和公司资质挂钩，很多招投标和补贴申报要求企业拥有若干项软著。立项书写明软著计划，等于同时给公司沉淀资质资产，这类项目在预算审批时更容易得到商务或管理层支持。我在立项书的“项目目标”一节里会加一句“形成公司自有知识产权的软件资产”，这句话不花一分钱，但对审批通过率有实际帮助。

4.2 软件设计师证书与立项预算的隐性关系：招投标与人员资质

这部分水比较深，但对特定类型项目影响很大。如果立项书对应的项目未来要走招投标流程，或客户方明确要求实施团队具备相应资质，人员证书就会变成硬性条件。软考软件设计师属于中级资格，在很多信息系统集成项目里既是企业资质评分的依据，也是项目经理和技术负责人岗位的任职要求。立项书里不仅要写团队人数，还要写关键岗位的资质匹配情况，否则项目到了投标阶段才发现资质不满足，只能重新调整团队或补充认证，预算和时间都会超。

我在人力预算中会专门留一项“资质认证与培训费”，用于支持团队成员考取相关证书或参加继续教育。这笔钱数额不大，常见预算在几千到一两万，但它传递的信号是“团队有能力持续满足项目资质要求”。评审委员看到这笔预算通常不会追问太多，因为它是合理且可控的支出。反过来说，如果项目明确要求软件设计师中级资质而你预算里没有任何相关安排，评委问一句“持证人员在项目里的角色是什么”就可能卡壳。

这里要提醒一个容易混淆的点：软考证书和软著是两码事。软著是登记知识产权的证书，由版权登记部门受理；软考证书是个人技术资格的考试认证，由工信和人事考试体系管理。立项书里把两者分开写，人员资质部分放证书，知识产权部分放软著，不要把两件事搅在一起。评审委员常年看立项书，概念混淆会直接拉低对整个文档专业度的评价。

4.3 技术选型条款怎么写：自研、外购与开源的决策矩阵

技术选型是立项书里最容易写成长篇大论的部分。我的经验是控制在三页以内，核心是一张决策矩阵表：每个关键组件一行，列出自研、外购、开源三种路线的成本、周期、风险和结论。评审委员不会替你选型，但他们需要在十分钟内看懂你为什么这么选。决策矩阵的作用是把选型逻辑从“我觉得”变成“有依据”。

表格里的数字要和成本测算章节完全一致，这是选型表和预算表联动的基本要求。选型理由部分每行写两到三句：成本、交付周期、运维能力、风险四个维度里选最关键的说明，不用面面俱到。比如数据库同步选外购，理由是“自研周期过长，开源方案不支持增量同步，外购成本在预算范围内”，三句话就足够。

技术选型里还有一类条款容易被漏：第三方软件的授权模式和续费成本。比如外购一个中间件，买的是永久授权还是年度订阅，对后续年度的运维预算影响很大。立项书里如果是年度订阅模式，要在“后续年度成本”里写明，不能只算当年预算。评审委员对这类持续支出非常敏感，主动写清楚反而显得考虑周全。如果选开源方案，要说明版本策略和社区活跃度，避免选了无人维护的冷门项目。

5. 立项书避坑实录：评审会上最容易被挑战的五类写法

这一章是血泪经验，列了五个在评审会上出现频率最高的问题，每条按“现象、原因、解决”展开。写完立项书拿这五个问题当镜子，对一遍再提交。

5.1 成本表只有总数没有测算依据

现象：预算表里只有“人力成本80万、采购成本20万、总计100万”，没有任何明细；评审委员问“80万怎么构成的”，答不上来。原因：写立项书时先定了总额再倒推明细，或者干脆没有做WBS拆分，预算数字是拍出来的。解决：先拆WBS再估工时，哪怕估算粗糙，也要让每一行成本能回查到对应的任务包或采购项；成本测算脚本跑出来的明细直接作为附件附上。数字合理与否可以讨论，但“没有依据”没有讨论空间。

更具体地说，我见过最典型的翻车现场是：评审委员拿笔指着预算表问“开发工程师12个人月怎么算出来的”，项目负责人支支吾吾说“大概需要这么多人”，委员当场就把立项书退了回去。反过来，如果负责人能翻到WBS表，指出“数据迁移模块3个人月、接口对接2.5个人月、报表模块2个人月”，即使总数完全一样，结论也完全不同。预算不怕被挑战，怕的是挑战之后拿不出支撑材料。

5.2 里程碑全压在最后一个季度

现象：排期表里前两个季度只有“需求调研”“开发中”这种模糊描述，全部验收节点集中在第四季度，中间没有任何可检查的交付物。原因：写排期时只把项目结束日期当唯一硬节点，没有按可交付物拆中间里程碑。解决：把里程碑拆成四类——可测试版本完成、内部验收通过、试运行启动、正式上线，每个阶段都要有可验证的交付物和对应的验收人。比如“可测试版本完成”的交付物是测试报告和缺陷清单，“内部验收通过”的交付物是验收记录和遗留问题清单。

中间节点越多，评审委员越放心，因为项目进度可观测，而不是隔半年才能发现延期。我有个习惯：每个里程碑都绑定一个“进不来怎么办”的判断标准，比如试运行启动的条件是“P1级缺陷清零且P2级缺陷小于10个”，写清楚这个，评审委员就不用担心节点形同虚设。

5.3 风险表只写技术风险不写商务与人力风险

现象：风险表里列了“算法准确率不足”“系统并发性能不够”这类纯技术风险，但没有一条提到供应商延迟交付、关键人员离职、需求蔓延。原因：写风险时只从开发视角出发，没有模拟评审委员的视角。解决：按“技术、商务、人力、合规”四类补齐风险登记册，每条风险写触发条件、影响、应对措施和责任人。

我常用的风险登记册格式是四列：风险描述、触发信号、影响范围、应对预案。以“关键开发人员离职”为例，触发信号是“核心模块负责人提出离职或连续两周产出明显下降”，影响范围是“数据迁移模块延期两到四周”，应对预案是“核心模块实行代码互相Review、关键文档及时归档、预留外部招聘缓冲期”。这些内容不需要写得多高级，但要让评审委员看到你想过。只有技术风险的风险表，在评委眼里等于没做过风险分析。

5.4 技术方案写成功能清单，评审看不懂边界

现象：技术方案章节里大段描写“系统支持某某功能、某某模块”，读起来像PRD，评审委员看完不知道系统边界和外部依赖在哪。原因：把立项书当成了产品说明文档在写，没有意识到评审需要的是决策依据。解决：把功能清单移到需求规格说明书或附件里，正文只保留系统边界、集成关系、技术选型理由和约束条件。写完检查一句：如果删掉这一段不影响评审判断，这段就不该放在立项书正文里。

另外还有一个常见的变体：把技术方案写成产品宣传语，比如“系统采用先进的微服务架构，具备高可用性和扩展性”。这类话在评审会上没有任何用处，因为不可验证。要写就写具体的判断依据，比如“采用微服务拆分是因为订单模块需要独立扩容，且团队已有两个项目的微服务落地经验”，有场景、有依据，委员才知道你的选型是思考过的。架构图在这里起到辅助作用，画到部署视角，配合边界描述，一段话说清楚。

5.5 验收标准全是套话，无法度量

现象：验收标准写“系统运行稳定可靠”“用户体验良好”，评审委员问“什么叫稳定可靠”时无法给出量化口径。原因：从通用模板里抄了验收标准，没有结合项目特征定制。解决：把验收标准改成可验证的量化指标，例如“试运行期内无P1级故障，平均响应时间低于两秒，订单处理成功率不低于99.9%”。每条量化指标要从可观测、可记录、可复核三个维度检查：指标有没有对应的日志、监控报表、测试报告。

我一般会把验收指标和里程碑绑定：试运行启动时验收“P1级缺陷清零”，上线时验收“订单处理成功率不低于99.9%”，结项时验收“软著申请已提交”。写不出量化指标的验收项，说明需求还没想清楚，不如不写。注意不要写“系统上线后运行稳定”这类无法证伪的话，评委想的是“怎么证明”，写不出证明方法的指标就是空话。

提示：写完立项书后，拿这五条对着检查一遍。如果某一条说中了，说明文档里有对应短板，这是好事，补上就能少一次评审会被追问的尴尬。

6. 立项书的自测清单与敏感性分析：预算不翻车的两个手段

立项书写完先别急着提交。我习惯做两件事：敏感性分析和反问自测。两个手段加起来不到半天，但能避免绝大多数评审会上的被动场面。

敏感性分析的做法是把预算里的关键变量浮动一下，看总预算变化多大。核心变量是人力单价和工期，因为这两项占预算比重最大、也最容易被挑战。下表是常见的敏感性分析维度：

做完敏感性分析之后，预算谈判时心里就有底：委员压价时你知道哪些支出可以压缩、哪些是刚性成本不能动。比如人力单价是市场行情决定，压缩空间有限；非核心功能砍掉则能直接减少人月数。没有这层分析，现场被压价时只能随口让步，容易踩到质量红线。

反问自测我一般准备一份十问清单，拿立项书逐条回答：总预算每一分钱能不能说到出处；里程碑每一个节点有没有可验证的交付物；风险表里每一条风险有没有责任人；软著申请窗口是否已排进里程碑；技术选型表里的数字和成本表是否一致；验收标准有没有量化口径；不做什么有没有单独写一节；现有系统可复用部分是否已确认；有证的同事有没有写进关键岗位；敏感性分析有没有跑过。十个问题有一个答不上来，就回对应章节补。

我自己的习惯是每份立项书提交前放一个晚上，第二天以完全陌生的评审者身份重读一遍摘要页，能完整复述出“做什么、花多少钱、什么时候交付”就算过关。复述不出来就继续改，这是最笨也最有效的方法。希望这篇笔记能帮你把立项书写到让评委敢签字的那一版。

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