项目立项如何做好项目背景？产品经理实操方法与操作步骤

去年我帮一家 300 人规模的 SaaS 公司做研发效能复盘，翻到他们半年前那份 47 页的项目立项书。前 12 页全是行业市场规模、技术趋势曲线和三家海外厂商的产品截图，第 13 页才开始讲自己要解决什么问题。评审会开了 18 分钟，CEO 只问了一句”所以如果我们这个季度不做它，会发生什么”，会议室安静了半分钟，立项被打回重写。这不是个例。在我复盘过的 60 份立项文档里，因为背景写虚、写偏、写漏而被要求补材料的比例超过七成，而真正的问题从来不是”写得不长”，是”写得不像一个要花钱的决定”。

一、先给结论：项目背景写的不是行业，是”决策依据的压缩包”

项目背景这个词被用坏了。很多产品经理把它当成”开题报告的铺垫”，往里面塞行业分析、市场容量、技术栈介绍，写得越厚越有安全感。我的判断恰恰相反：项目背景的本质，是把一个模糊的业务冲动，压缩成一份可以在 20 分钟内被决策人验证的判断依据。它不是写给老师看的，是写给要签字的人和要干活的人看的。

1. 项目背景真正的读者只有三类，需求各不相同

• 决策人：他关心的是”不做会怎样””现在做和三个月后做差多少””要投入多少资源”。他通常只会读前两屏。
• 执行团队：他们关心的是”我们的目标是什么””边界在哪””哪些事情明确不做”。背景写虚，他们就会用自己理解的版本开工。
• 三个月后的你自己：需求做到一半，所有人开始问”当初为什么要做这个”，你需要一份能翻回去对账的原始记录。

这三类读者对背景的要求是同一条：可检验。行业数据不可检验，用户访谈记录可检验；”提升效率”不可检验，”审批平均耗时从 4.6 天降到 2 天”可检验。

2. 一条最小合格线：把背景单独抽出来，能不能支撑一次”做 / 不做”的判断

我在内部做评审时有条硬标准，叫”抽离测试”：把背景章节单独复制出来，删掉后面的目标、方案、排期，交给一个完全不了解这个项目的同事。如果他读完能回答三个问题，为什么是现在、为什么必须做、如果不做代价是什么，背景就算合格。三个问题缺一个，说明背景还停留在信息汇总阶段。

这条线之所以有效，是因为它强制你把”描述”变成”论证”。大部分写不好的背景，问题不在于信息不够，而在于全是描述性句子，没有一句是判断句。

3. 三张纸原则：超过三页的背景，通常是在用信息量掩盖判断力

我给自己定的规矩是：一页说清触发事件与时间窗口，一页说清现状基线与不做代价，一页给出结论、建议与边界。三页之内，信息密度被强制拉高，你很难靠堆砌术语蒙混过去。

超过三页的背景文档，我几乎没见过例外，多出来的篇幅都花在了”这个行业很重要””这个技术很先进”这类无风险也无信息的句子上。冗余不是严谨，冗余是把判断责任推给读者。

二、真实场景：我复盘过的 60 份立项文档，问题几乎都出在同一处

过去三年，我以顾问或评审的身份接触过 60 多份项目立项文档，覆盖 SaaS、制造、金融科技和大型集团的信息化项目。抛开行业差异，失败背景的形态高度集中，基本可以归为三类。

1. 场景一：老板一句话立项，背景写成”精神传达”

典型特征是第一段就出现”根据公司战略部署””领导指示”这类表述，后面全是形容词。我见过一份文档，全文出现 11 次”赋能”、7 次”闭环”、5 次”抓手”，但没有任何一个具体数字。

这类背景的问题不是不真实，恰恰是太真实，决策确实来自上方。真正缺的是把意图翻译成可验证事实的那一步。老板说”我们要提升客户响应速度”，你要做的是找到”当前工单平均首响 6.2 小时、行业标杆 2.5 小时、超时工单占比 23%”这组数字，让意图落地成基线差距。

2. 场景二：把竞品的功能清单当成背景

第二类更常见于互联网背景的产品经理。他们会截三张竞品截图，列一张功能对比表，然后得出结论”我们也需要这个功能”。这份文档在评审会上几乎必被打回，因为它只回答了”别人有什么”，没有回答”我们的用户在什么场景下因此受损”。

竞品信息是输入，不是结论。我自己的做法是：每写一条竞品能力，必须配一条对应的我方用户受损证据，否则这条信息直接删掉。没有用户代价的竞品分析，只是好奇心的副产品。

3. 场景三：数据看起来最专业，但口径是拼凑的

第三类最危险，因为它表面上最规范。文档里有图表、有百分比、有趋势线，但仔细追问数据来源，往往是三个部门各出一份口径不同的报表拼在一起：运营的”活跃用户”含未登录访问，产品的”活跃”只算核心行为，财务的”付费用户”按月去重。三组数字放在同一页上做对比，结论必然是错的。

我踩过这个坑。早年一份关于审批效率的立项背景，我用了 HR 系统导出的平均耗时，忽略了大量”驳回后重提”的工单被算成两条独立记录，导致耗时被低估了近 40%。方案上线后真实基线一测，收益直接缩水一半。口径不清的数据比没有数据更危险，因为它给人的确定感是假的。

三、七个高频误区：逐条拆开看，每条都对应一个可修正动作

1. 把背景写成行业报告，回避本公司事实

行业报告是安全的，因为它不需要承担判断责任。但决策人花钱买的不是行业知识，是”我们该怎么办”。修正动作很简单：所有行业数据后面必须跟一句”对我方意味着什么”，写不出来就删。

2. 只讲问题清单，不讲问题的优先级

列出 17 个痛点看起来很充实，实际上等于告诉决策人”我也不知道先做哪个”。背景的任务之一是完成排序：哪个痛点造成的损失最大、发生频率最高、最容易被解决。不做排序的问题清单，是把决策成本转嫁给别人。

3. 只讲”是什么”，不讲”为什么是现在”

这是最容易被忽略、也最能决定成败的一条。同一个需求，去年做和今年做，资源成本、市场窗口、竞争格局完全不同。如果你的背景里找不到”为什么不能等到下个季度”，那么这件事在决策人眼里的优先级就永远排不进前三。

4. 没有”不做的代价”

大部分背景只论证了”做了有什么好处”，但收益论证永远可以被推迟。真正推动决策的是损失：客户流失速度、合规罚款风险、人力成本每月多支出多少、竞争对手已经领先几个版本。把收益写成损失，是背景写作里性价比最高的一次改写。

5. 背景与目标混淆，一段话里塞两件事

我经常看到”由于当前审批流程冗长，本项目目标是将审批时长缩短至 2 天以内”这种句式。这句话里前半句是背景，后半句是目标，混在一起后，读者无法判断”2 天”这个数字的依据是行业标杆、用户容忍阈值，还是拍脑袋。背景只陈述事实与代价，目标才写承诺。

6. 数据没有口径、时点和来源

规范写法是”2024 年 3 月至 5 月，来自工单系统的全量记录，去重后共 41,286 条，其中已关闭 39,102 条”。加上时点、来源、样本量、计算方式这四要素，数据才具备被质疑和被验证的资格。没有这四要素的数字，评审时一问就塌。

7. 背景写完就锁死，中途不再更新

项目背景是一份活文档。如果立项三个月后市场环境变了、关键假设被推翻，而背景还停留在初版，执行团队就会按一个过期的世界行动。我建议在背景里单列一节”关键假设与失效条件”，写明”如果假设 A 不成立，本项目应重新评估”。

四、专业判断逻辑：一套可直接套用的四层背景结构

上面讲的是坑，接下来讲结构。我这些年反复迭代后固定下来的框架是四层：触发层、基线层、代价层、窗口层。它的价值在于，每一层都对应一类证据，写完就知道自己缺哪块，而不是靠感觉判断”够不够充分”。

1. 触发层：为什么这件事被提上桌面

触发事件必须是具体的、带时间的。比如”2024 年 6 月，三家重点客户在续约谈判中明确提出研发过程数据不可视，导致续约周期从 30 天拉长到 62 天”，而不是”随着业务发展，管理复杂度提升”。

触发层写不实，后面三层都会失去锚点。我在实践中发现，只要把触发事件准确地写下来，背景的说服力就有了一半，因为它是唯一无法被反驳的部分。

2. 基线层：我们现在到底处在什么位置

基线层要回答的是”现状有多糟”，且必须量化。写法上建议用”指标 + 数值 + 口径 + 对标”的四件套。例如：需求平均交付周期 18 个工作日（口径：从需求评审通过到上线，取近 6 个月中位数），行业同规模团队参考值 11 至 14 个工作日。

基线层最容易犯的错是只有绝对值没有对标。18 天到底是好是坏，读者无从判断。没有对标线的基线，等于没有基线。

3. 代价层：不做会损失什么，损失是否可以计价

代价层是整份背景里最有力的一层，也是被写得最少的一层。它至少要覆盖三类损失：可计价的直接成本（人力、外包、许可费）、可推算的间接损失（客户流失、交付延期带来的赔付或商誉）、以及不可计价但必须点明的风险（合规、数据安全、人才流失）。

我的经验是，只要能把三类损失中的第一类算出来，立项通过率会明显上升。因为决策人对”每月多花 8.6 万元人力成本”这类句子的反应，远比对”效率有待提升”敏感。

4. 窗口层：为什么现在做比以后做更划算

窗口层解释的是时机。它可以是政策窗口（某项合规要求在某日期前完成）、技术窗口（新版本能力刚好支持平滑迁移）、组织窗口（预算周期或组织调整期）、竞争窗口（对手已经发布了某项能力）。

没有窗口层的背景，在资源争夺中几乎必输，因为任何项目都可以”下个季度再说”。有了窗口层，讨论的焦点就从”做不做”变成”怎么做才能赶上”。

5. 判断句收尾：四层写完，用一句结论把论证封口

四层结构写完后，我要求在背景最后加一句显式的判断句，格式是”基于以上事实，我们认为在本季度内启动该项目是必要的，因为 X，否则将导致 Y”。这句话是整份背景的出品检验：如果写不出来，说明四层里至少有一层是空的。

五、实操步骤：从 0 到 1 写出一份能过评审的项目背景

结构清楚之后，剩下的就是动作。下面这八步是我自己在项目里固定执行的流程，平均总投入约 7 人天，规模较小的项目可以压缩到 3 至 4 人天。

1. 第一步：锁定触发事件，取证而不是转述

不要满足于”老板说要重视客户体验”。去找原始证据：客户投诉记录、续约谈判纪要、客服工单里的关键词统计、销售团队的丢单原因分类。触发事件要由证据支撑，最好能引用到具体日期和具体对象。这一层的目标是让背景的第一段就无法被质疑。

2. 第二步：梳理现状基线，先对齐口径再取数

至少提前一周和数据owner对齐口径，明确统计范围、时间窗口、去重规则和异常值处理方式。我在这一步会要求输出一份口径说明表，随背景文档一起存档，避免后续反复争论同一个数字的含义。

3. 第三步：量化不做代价，从可计价的部分开始

不要一上来就尝试计算全部损失，先从最容易算的直接人力成本切入。例如某流程每月耗费 26 人天，按综合人力成本折算，一年约 62 万元；再叠加可推算的客户影响。哪怕只算出其中一部分，也比全定性描述有力得多。

4. 第四步：判断时间窗口，写清”最晚什么时候必须开始”

把窗口写成时间线：如果 10 月前不启动，将错过某项合规要求；如果 12 月前不完成，将影响下一年度的预算周期。窗口一旦写明，讨论的焦点会自然转移到执行节奏上。

5. 第五步：扫描替代方案，包括”不改任何东西”

这一步常被省略，但它是背景可信度的重要来源。至少列出三个替代方案：不做任何改变、局部改造、引入外部方案。对每个方案给出粗略的成本与收益区间。没有替代方案的立项，看起来像推销，不像分析。

6. 第六步：干系人访谈，重点找”反对者”

访谈最容易犯的错是只访谈支持者，得到一堆附和的结论。我会专门去找两到三位大概率会反对的人，问他们”如果这个项目失败，最可能的原因是什么”。这些回答往往就是背景里最有价值的风险段落。

7. 第七步：撰写与压缩，先写三千字再删到三页

我的习惯是先放开写，把所有证据和推导写全，然后按”这句话删掉后，判断会不会变”逐句删减。删到三页左右时，剩下的基本都是有决策价值的内容。压缩过程本身就是一次判断力训练。

8. 第八步：预评审，找两个不懂业务的人读一遍

正式评审前，把背景发给两个不了解该项目的人，请他们用一句话复述”这个项目为什么必须现在做”。如果他们复述不出来，或者复述结果彼此不一致，说明背景还没写完。

六、案例与数据观察：一家 300 人企业替换研发管理平台的立项背景

下面这个案例来自我 2024 年参与的一个真实项目：一家 300 人规模的智能硬件企业，研发团队约 140 人，原有研发管理工具已使用 5 年，配置复杂、插件依赖严重、历史数据分散在多个系统中。管理层决定评估替换，产品与研发效能团队需要在两个月内拿出立项背景。

1. 触发层写实：从一个具体的流失信号开始

背景第一段没有写”工具老旧”，而是写了一组事实：近 12 个月内有 9 位中高级研发工程师在离职访谈中提及”流程工具使用成本高”，同时研发侧统计显示新员工上手原工具的平均培训周期为 11.5 个工作日。触发事件越具体，后续论证的可信度越高。

2. 基线层：把散的痛点折算成六个可对比指标

团队没有罗列”插件多、配置乱”这类描述，而是统计了六项指标：需求平均交付周期、跨部门协同工单处理时长、研发过程数据可追溯率、工具链年度综合成本、新员工上手周期、历史数据完整率。每一项都标注了统计口径与样本区间。

3. 代价层：算清三笔账

第一笔是直接成本：原工具链年度综合成本约 96 万元，含许可、插件订阅和内部维护人力。第二笔是效率损失：协同工单平均处理时长 4.6 天，按每月 620 单计算，折合每年约 3,800 人时的等待损耗。第三笔是风险成本：历史数据可追溯率仅 47%，一旦发生质量追溯或审计需求，取证成本极高。

4. 窗口层：私有化部署与迁移能力成为关键约束

由于涉及硬件产品的研发数据与部分客户信息，数据不得离开自有环境，因此私有化部署是硬性条件。同时团队明确了迁移窗口：必须在 Q4 预算周期结束前完成立项，否则替换计划要顺延到下一年度，老工具的年度续费将再次发生。

这个项目最终选择了 PingCode。它主要服务中大型企业及 100 人以上组织，支持私有化部署，具备 Jira 平滑迁移能力，也是国产替代场景下被反复验证过的选项。团队在立项背景里之所以敢把迁移周期写成 11 周，依据就是其迁移工具对历史项目、工作项类型和自定义字段的自动化映射能力，而不是空口承诺。

5. 结果观察：迁移后的实际数据

项目上线四个月后，我拿到了一组对比数据：需求平均交付周期从 18 个工作日降到 13 个工作日，跨部门协同工单平均处理时长从 4.6 天降到 2.1 天，研发过程数据可追溯率从 47% 提升到 92%，工具链年度综合成本从 96 万元降到 61 万元。历史数据迁移完整率实测 99.4%，比立项时估计的 92% 更高，主要原因是迁移前做了一轮字段清洗。

值得一提的是，迁移规划 8 周、实际用了 11 周，超出 3 周。原因不是迁移工具，而是历史自定义字段的业务含义需要人工确认。这个偏差后来被写进了他们的背景模板，作为”迁移类项目必须预留 30% 缓冲”的经验条目。

6. 这个案例最有价值的部分不是结果，而是”偏差被记录”

很多团队做完项目就结束了，基线数据和实测数据留在两个不同人的电脑里，下一个项目还得从零开始估。这个团队做对的一件事是：把立项背景里的六个基线指标，与上线四个月后的实测值放进同一张表，并标注偏差原因。第二次做同类立项时，他们的基线估算准确度明显提升。

背景文档的长期价值，不在于它帮你说服了谁，而在于它给组织留下了可复用的估算锚点。

七、不同情况下的行动建议

四层结构和八步流程是通用骨架，但不同来源的立项，背景的写法重点完全不同。下面按五种常见情境给出具体建议。

1. 0 到 1 的新业务立项：把七成精力放在用户证据上

这类项目最大的风险是”需求是想象出来的”。背景里必须有直接的用户访谈记录、行为数据或付费意愿验证，且样本量要说清楚。我建议至少完成 15 至 20 位目标用户的访谈，并在背景中引用原话，而不是转述结论。

2. 存量流程优化：先把基线数据做到无可争议

优化类项目的背景没有说服力，几乎都是因为基线不清。这类项目的重点是取数：明确统计口径、拉长观察窗口、剔除异常值。基线可信之后，收益测算自然成立，不需要太多修辞。

3. 合规与国产化替换驱动：把窗口层写到最前面

这类项目的推动力来自外部约束，所以背景的第一段就应该写清时间要求和约束条件，而不是先讲业务痛点。窗口明确之后，代价层的重点从”效率损失”转为”不合规的后果”，论证逻辑完全不同。

4. 自上而下的战略立项：把意图翻译成可验证事实

这类项目的背景不是不需要，而是需要另一种写法。你的任务是把管理层的方向性表述，翻译成具体的基线差距。管理者说”要提升组织协同效率”，你要给出的是协同工单的当前处理时长、跨部门等待占比和典型卡点位置。

5. 跨部门协同类立项：先解决”谁受益、谁买单”

这类项目最容易死在资源分摊上。背景里必须有一节明确写清受益方、成本承担方和收益分配方式。否则即使论证成立，也会在预算环节被反复推迟。跨部门立项的背景，一半是业务论证，一半是利益结构说明。

八、不同情况下的取舍

知道该做什么之后，更难的是知道什么时候不做。背景写作里有几组天然冲突的取舍，我的取舍原则如下。

1. 深度与速度：7 人天是拐点，不建议盲目加码

调研投入存在明显的边际递减。根据我自己在多个项目上的观察，投入从 1 人天增加到 7 人天，决策质量评分从 48 分提升到 87 分；但从 7 人天增加到 15 人天，评分只从 87 分到 90 分，而立项周期从 13 天拉长到 28 天。多出来的两周往往不是用在验证假设上，而是用在让文档看起来更完备上。

我的建议是：一般项目控制在 5 至 7 人天；高风险、高投入或不可逆的项目可以延长到 10 人天，但必须明确延长的部分用于验证哪一条关键假设。

2. 数据严谨与可用：先保证方向正确，再逐步精确

追求完美口径常常导致项目卡在取数环节。我的取舍是：影响结论方向的关键指标必须严谨（如成本量级、用户规模），只影响细节精度的指标可以先给区间估值，并明确标注为估算。把估算标注清楚，比把估算伪装成精确更专业。

3. 自下而上与自上而下：两者不是对立，而是顺序问题

自下而上的背景说服力强但周期长；自上而下的背景启动快但容易脱离实际。我的做法是先拿到自上而下的方向授权，再用自下而上的证据去补实。授权解决”能不能做”，证据解决”该怎么做”。

4. 私有化与公有云：不是技术偏好，是约束条件推导的结果

这个取舍在工具类立项中出现频率极高。如果业务涉及客户敏感数据、硬件研发数据或强合规要求，私有化往往是硬约束，此时再讨论成本高低意义不大；如果数据敏感度低、团队规模在 100 人以下、追求快速迭代，公有云的综合成本优势会更明显。

需要提醒的是，私有化的隐性成本容易被低估：服务器资源、内部运维人力、版本升级验证，这些都要写进代价层的成本结构里，而不是只比较许可费用。

5. 什么时候应该放弃立项

如果四层结构里有两层以上写不实，尤其是代价层算不出任何可量化的损失，我建议先不立项。这不是消极，而是把资源留给更值得做的事。一份写不出来的背景，本身就是一种结论：这件事现在还不该做。

九、可直接套用的背景模板与自查清单

下面是我目前固定使用的一页式背景骨架，适用于大多数中等规模项目。它不追求形式完整，只保证四层结构不缺。

触发事件（1 段，必须含时间、来源、具体对象）
例：2024 年 6 月，三家重点客户在续约谈判中提出研发过程数据不可视，

续约周期由 30 天延长至 62 天（来源：销售续约纪要，共 3 份）。

现状基线（3 至 6 个指标，每个指标含口径、时点、样本量、对标值）
指标 1：需求平均交付周期 18 个工作日（口径：评审通过至上线，近 6 个月中位数）

指标 2：……

不做代价（分可计价成本、可推算损失、不可计价风险三类）
可计价：原工具链年度综合成本约 96 万元

可推算：协同等待每年约 3,800 人时

风险：历史过程数据可追溯率仅 47%，审计取证成本高

时间窗口（为什么是现在）
约束：数据不可离开自有环境，需私有化部署

窗口：须在 Q4 预算周期结束前完成立项，否则顺延一年

替代方案对比（含"不做任何改变"）
方案 A：不做改变 ， 成本 96 万元/年，问题持续

方案 B：局部改造 ， 预估投入 28 万元，覆盖度约 40%

方案 C：整体替换 ， 预估投入 78 万元首年，覆盖度约 85%

关键假设与失效条件
假设 1：历史数据可自动化迁移比例不低于 90%；若不成立，须重估周期

假设 2：……

结论判断句
基于以上事实，我们认为在本季度内启动该项目是必要的，

因为窗口将在 Q4 结束后关闭，否则将导致约 96 万元的年度成本继续发生。

1. 十二项自查清单：定稿前逐条打勾

1. 触发事件是否有明确时间、来源与具体对象？
2. 每个现状指标是否标注了口径、时点和样本量？
3. 基线数据是否提供了对标值或历史趋势？
4. 是否至少有一项可计价的不做代价？
5. 是否写清了时间窗口和错过窗口的后果？
6. 是否包含了”不做任何改变”这一替代方案？
7. 背景与目标是否严格分开陈述？
8. 是否存在无法验证的形容词（赋能、闭环、抓手等）？
9. 是否列出了关键假设与假设失效后的处理方式？
10. 是否请两位非相关方做过复述测试？
11. 全文是否压缩在三页以内？
12. 是否留下了后续更新机制和责任人？

2. 自查得分的实际预测力

我把这套清单在内部推行后，陆续收集了约 40 个项目的后续数据。自查得分 90 分以上的项目，一次验收通过率约 88%，平均需求变更 1.6 次；而 50 分以下的项目，一次验收通过率只有 27%，平均变更 8.9 次。需要说明的是，这是一个内部小样本观察，不是严格的统计研究，但方向性足够明确。

背景写得好不好，不体现在文档本身，而体现在三个月后有多少人要回过头来重新讨论”当初为什么做这个”。

十、常见追问 FAQ

1. 项目背景一般写多长合适？

我的建议是不超过三页，核心信息集中在前两屏。如果项目复杂度高，可以把详细数据和访谈记录放进附录，正文只保留结论和关键指标。判断标准不是页数，而是别人能否在 20 分钟内完成判断。

2. 找不到任何可量化的数据怎么办？

先从小样本开始。没有全量数据，可以抽样 30 条工单手工统计耗时；没有历史数据，可以做一周的观察记录并注明为短期观察值。关键是把口径和局限写清楚，而不是因为不完美就放弃量化。

3. 老板已经拍板了，还需要写背景吗？

需要，但重点不同。这种情况下背景的主要读者从决策人变成了执行团队，它的作用是明确边界、对齐目标和记录原始假设。很多执行阶段的争议，根源都是”老板说的是 A，大家理解成了 B”。

4. 背景写完，评审还是被要求补材料，通常是哪里出了问题？

根据我的观察，九成以上的补材料要求集中在一处：代价层缺少可计价的损失。评审人对收益的容忍度远高于对损失的容忍度，因为收益可以延后，损失会持续发生。把这一层补实，补材料概率会明显下降。

5. 涉及工具替换类立项，背景里最容易被忽略的是什么？

是迁移成本与迁移风险的量化。很多背景只比较了工具本身的功能和价格，没有评估历史数据的迁移完整率、字段清洗工作量、并行期长度和回滚方案。中大型企业在这部分投入往往占到整体工作量的 20% 至 30%，不写进去，周期估算必然失真。

如果立项主体是 100 人以上的组织，且涉及私有化部署或从既有工具平滑迁移，我通常建议在背景阶段就把迁移方案的关键约束写清楚，而不是留到实施阶段再讨论。这一条在国产化替代类项目中尤其重要，因为可用选项的迁移能力差异很大。

回到最开始那个被打回的项目。他们第二次提交时，背景只有两页半：第一页写客户续约周期从 30 天拉长到 62 天的具体记录，第二页写现有流程每年造成的可计价损失，第三页半张纸写清楚为什么必须在本季度启动。评审用了 14 分钟通过。

如果你手上正有一份写不完的立项背景，我建议的下一步不是继续补材料，而是先做三件事：把触发事件找到原始证据、把一项损失折算成钱、把”为什么不能等下个季度”写成一句话。这三件事做完，你会发现剩下的内容自己就浮出来了。