进度管理如何做好实际进度？研发团队最佳实践与操作步骤

去年第三季度，我以外部顾问的身份介入了一家约 140 人规模的 SaaS 研发团队。他们在季度初立项了一个包含 6 个核心模块的大版本，原计划 10 周上线。到了第 8 周，项目周会上各个小组汇报的进度都还是"大概 80%"，看起来一切正常。结果第 10 周真正收口的时候，负责人在复盘会上说了一句话让我印象极深："我们不是最后两周才开始延期，是第一天起就不知道真实进度在哪。"最终这个版本拖到第 14 周才上线，延期 40%，而更刺痛管理层的不是延期本身，是直到第 12 周他们才第一次意识到问题的真实大小。

这件事集中暴露了一个几乎所有研发团队都会遇到、但很少有人正面回答的问题：进度管理里最难的从来不是"排计划"，而是"搞清楚现在到底做到哪了"。计划进度可以拍脑袋，可以照抄模板，但实际进度是一个需要被持续采集、校准、暴露的状态量。这篇文章不打算重复"甘特图很重要""要加强沟通"这类正确但没用的话，而是把实际进度的定义、失真的根因、同步机制的设计、可落地的操作步骤以及不同规模团队该怎么取舍，一次讲透。

如果你正带着一个 10 到 100 人的研发团队，并且被"进度说不清"反复折磨，这篇内容可以直接对照执行。

一、先给结论：实际进度管理本质是一套信息机制，不是一个数字

先把核心结论摆在前面，后面所有内容都是围绕这几条展开的。

第一，实际进度不是"完成百分比"这一个数字，而是"任务完成状态 + 剩余工作量估算 + 置信区间"三者构成的复合状态。当你只问一个人"做到哪了"，他给你的永远是感知进度，而不是实际进度。感知进度会系统性地乐观，越靠近截止日期越乐观，这是人性的默认设置，不是态度问题。

第二，研发场景下进度失真的主要来源不在执行层，而在定义层。任务颗粒度定义不清、"完成"没有统一标准、变更没有回流到基线，这三个问题贡献了我在多个团队观察到的绝大部分进度偏差。执行层慢只是表象，定义层糊才是根因。

第三，做好实际进度的关键动作是把"进度同步"嵌入到已有的研发节奏里，而不是额外增加一套管理仪式。很多团队失败的原因不是方法不对，而是把进度管理做成了一件需要专门花时间应付的事，于是两三个迭代之后就自然消亡了。

下面这张图用一组示意数据说明"定义层改进"和"执行层加人"两种做法在进度可见性上的效果差异。数据来自我对四个类似规模研发团队的观察推演，属于情景模拟，用来说明机制设计对进度透明度的杠杆作用，而非精确统计。

二、真实场景：为什么"做到哪了"这个问题这么难回答

要理解实际进度为什么难管，先要承认一件事：研发工作的性质和传统工程、制造有本质区别，把工程领域的进度管理方法直接搬过来，必然水土不服。这一节先讲清楚研发场景的特殊性，再讲它如何导致进度失真。

1. 研发工作的三个特殊属性直接决定了进度难测量

第一个属性是需求的不确定性。制造业的产品规格在开工前基本冻结，而研发的需求在开发过程中持续演化。一个"用户中心改版"的需求，可能在第二个迭代就变成"用户中心改版 + 权限体系重构"，工作量翻了一倍，但进度基线还是原来的。

第二个属性是技术探索的不可分割性。写业务代码可以按功能拆解，但"把接口响应时间从 800ms 优化到 200ms""让这套服务支持多租户隔离"这类任务，在真正做完之前，没人知道要花三天还是两周。它的进度不是线性的，可能卡在 90% 很久然后突然完成，也可能一开始顺风顺水最后一脚踩坑。

第三个属性是创造性工作的完成度模糊。一个页面"开发完成"和"可以上线"之间，隔着自测、联调、代码评审、测试用例、灰度验证一堆环节。每一个环节都能说"基本完成了"，组合起来就变成了"看起来 90%，实际可能只有 60%"。

2. 一个典型场景：周会上的"大概 70%"

我见过太多这样的场景。周三进度会，产品经理问后端负责人："订单模块这周能提测吗？"对方回答："问题不大，主要逻辑都通了，大概 70% 吧，下周应该能提测。"产品经理点点头，会议继续。

两周后，订单模块还没提测。追责的时候，后端负责人也很委屈，他说的是"主要逻辑通了"，剩下的是"接口幂等没做、订单超时补偿没做、和风控的联调卡在对方排期"。这些在他心里不算"核心逻辑"，所以没有算进那 70% 里。

这不是撒谎，这是"完成标准定义不一致"导致的系统性偏差。所有人都在诚实地汇报，但每个人脑子里的分母不一样，于是加总出来的进度就是一个没有意义的数字。

3. 偏差发现得太晚，是造成延期损失最大的因素

我在前面提到的那家 SaaS 团队，延期 4 周，但真正的成本损失集中在最后 3 周，因为最后阶段需要临时协调测试资源、加班、砍需求，这些动作的成本远高于在项目中期就调整方案。

换句话说，进度管理的价值不在"避免延期"，而在"尽早知道会不会延期"。一个项目如果真的会延期 4 周，第 3 周发现和第 12 周发现，损失完全不同。前者可以砍需求、调资源、改预期，后者只能硬扛。

三、拆解误区：研发团队在进度管理上最容易踩的五个坑

这一节把我在多个团队反复看到的错误做法集中列出来，每个坑配一个研发场景，方便你对号入座。需要说明的是，以下属于常见实践观察总结，不是研究结论，具体适用性还需结合你团队的情况判断。

1. 误区一：任务颗粒度太粗，导致进度只能靠感觉

"开发登录模块"这种任务，在任务列表上挂三周，你永远不知道它到底是 30% 还是 80%。颗粒度太粗的任务，进度上报就变成了纯主观判断，而主观判断在长周期任务上会不断漂移。

可操作的分辨标准是：一个任务的完成状态能否在 1 到 3 天内发生一次可验证的变化。如果不能，它就太粗了，需要继续拆。注意这里的关键词是"可验证"，不是"主观感觉有了进展"。

2. 误区二：进度靠人汇报，没有系统记录

很多团队的进度只存在于每天早会上的一句话，没有落到任何可追溯的载体上。结果是：一周后再问同一件事，你无法回答"和上周相比，它是前进了还是停滞了"，因为你根本没有基线可对比。

我坚持的一个原则是：凡是不能在系统里被看到状态变化的任务，就等于没有进度管理。这里的"系统"不一定非要是某款软件，一张持续更新的看板、一份每迭代维护的任务表都算，关键是它必须可追溯、可对比。

3. 误区三：需求变更没有回流到进度基线

这是我在中大型团队见得最多、杀伤力也最大的一个坑。需求加了、逻辑改了、第三方接口变了，但进度基线还是立项那天的那份。于是表面上进度没变，实际上分母已经膨胀了 30%。

变更不是不能有，而是每一次变更都必须评估对进度的影响，并显式更新基线。变更不可怕，隐形变更才可怕，因为它让所有进度数字都变成了自欺欺人。

4. 误区四：没有区分"完成"和"真正完成"

研发的"完成"是一个阶梯：写完代码是完成、通过自测是完成、通过联调是完成、通过测试是完成、通过灰度是可上线。如果你的任务状态里只有一个"完成"，那就一定会出现"所有人都说完成了，但版本发不出去"的尴尬。

解决办法是把"完成"拆成有明确验收标准的几个状态节点，让每个节点对应一个客观可验证的产出。这部分会在第五节的 Definition of Done 里给具体做法。

5. 误区五：进度信息不透明，导致信息只在个别人手里

当进度信息只掌握在项目经理或某一个负责人手里，其他人都不知道真实情况时，会出现两种后果：一种是他成为瓶颈，所有进度查询都要靠他；另一种是他下意识地过滤坏消息，让上层看到的是被优化过的版本。

健康的状态是：任何一个项目成员都能通过看板或任务系统，在 1 分钟内看到整体进度和风险项。进度透明不是为了监控，而是为了让信息自由流动，让问题更早暴露。

四、专业判断逻辑：为什么机制设计比工具和加班更关键

讲完误区，接下来讲判断逻辑。这一节是全文的思维主干，也是后面具体步骤的依据。

1. 判断逻辑一：进度是"状态 + 估算 + 置信度"的复合体

一个合格的进度信息至少包含三层含义。状态回答"现在处于哪个节点"，估算回答"还剩多少工作量"，置信度回答"这个估算有多可信"。

只给状态不给估算，你无法判断剩余时间；只给估算不给置信度，你无法判断风险。一个团队说"下周能上线"，和说"下周能上线，但风控联调存在不确定性，有 30% 概率延后 3 天"，后者的信息价值是前者的数倍，因为它给了管理者提前介入的窗口。

2. 判断逻辑二：实际进度的失真主要发生在定义层，而非执行层

这是我反复强调的一个判断。大部分团队在发现进度失真后，第一反应是"执行力不行"，于是加压、加班、开会。但真正的问题往往在于任务定义、完成标准、变更管理这三件最基础的事没做到位。

我通常会让团队做一个简单的自检：随便挑 5 个进行中的任务，问三个问题，完成标准是什么？现在处于哪个节点的哪个位置？剩余工作量估算是多少？如果说不出清楚，那问题就在定义层，不在执行层。这时候加班是治标不治本的。

3. 判断逻辑三：进度同步必须嵌入现有节奏，不能额外增加仪式

敏捷团队已经有站会、迭代评审、回顾会。如果进度管理再单独加一套周会、日报，它必然在两三个迭代后名存实亡，因为人的时间和注意力是有限的。

正确做法是把进度同步动作"寄生"在已有的节奏里：站会同步任务状态变化，迭代评审同步偏差和基线更新，回顾会同步机制本身的优化。这样进度管理不占用额外时间，才有可持续性。

4. 判断逻辑四：机制先于工具，但工具决定机制能否规模化

很多内容一上来就推荐工具，我反而建议反过来：先把机制想清楚，再选工具。因为没有机制，再好的工具也只是被用来画一张没人看的甘特图。

但当团队规模超过一定程度后，工具的作用会迅速上升。机制决定 10 人以下团队能不能跑起来，工具决定 50 人以上团队能不能跑得动。人肉同步在 10 人以内可行，超过这个规模必然崩，因为信息量按平方增长。

五、具体案例与数据观察：一套真实落地过的三层同步机制

接下来讲案例。这里我以 PingCode 为例，因为我在前面提到的那家 SaaS 团队做机制改造时，用的正是这套平台，能够拿到相对真实的落地过程。需要提前说明，我不是在推荐任何单一工具，而是用这个案例说明"机制 + 工具"组合起来是什么样子。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，同时支持 Jira 平滑迁移，是国产替代场景下常被考虑的选择。

1. 案例背景：从"人肉跟进"到机制化管理的改造

这家团队约 140 人，分 8 个研发小组，每条业务线一个小组，迭代周期为两周。改造前的痛点是：迭代中期完全看不到真实进度，所有进度靠小组长口头上报给 PMO，PMO 汇总后又只能给出一个模糊的整体百分比。上一个版本延期 40%。

改造的核心动作不是换工具，而是把进度同步拆成三层机制，然后把三层机制落到系统里。改造周期约 6 周，中间经历了两个迭代的磨合，第三个迭代起机制基本稳定。

2. 三层同步机制：任务层、迭代层、项目层

任务层解决"每个最小可交付单元现在到哪了"。核心动作是统一完成标准、把任务拆到 1 到 3 天粒度、每个任务显式标注所处的完成节点。这一层的输出是系统里可实时查看的任务状态看板。

迭代层解决"这个迭代按当前的节奏能不能按期交付"。核心动作是用燃尽图和累积流图跟踪剩余工作量趋势，每日站会只同步状态变化和阻塞项，迭代评审时校准偏差。这一层的输出是迭代健康度和偏差预警。

项目层解决"整体里程碑是否处于安全区间"。核心动作是里程碑校准、跨组依赖追踪、偏差预警。这一层的输出是项目级风险清单和基线更新记录。

三层机制不是三套会议，而是三层信息颗粒度，都沉淀在同一个系统里，任何一层的人都能向上看到汇总、向下看到细节。

3. 改造前后的数据观察

这里给一组改造前后的对比数据。这是该团队在改造前一个迭代和改造后第三个迭代的实际观测值，样本不大，属于单团队观察，用来说明方向性改善而非普遍结论。

这组数据里我特别想强调的是"需求变更回流基线比例"这一项。改造前只有约 30% 的变更被显式记录下来，改造后提升到约 92%，也就是说过去看起来"进度没变"的项目，很多是因为分母根本没更新。当变更被真正记录下来之后，进度数字反而变得更"难看"了，因为它诚实地反映了工作量膨胀。这是好事，早期难看比晚期失控要好。

4. 工具在其中的作用：不是答案，是把机制规模化的载体

回到工具这个话题。这家团队最终把三层机制落在了 PingCode 上，原因不是我要求他们必须用某个工具，而是他们自己算了一笔账：8 个小组、每条业务线 2 到 3 个并行项目、每周上百个任务状态更新，靠表格和人肉汇总已经撑不住。

他们选择这个平台的核心考量有几条。第一是私有化部署能力，他们有数据合规要求；第二是支持从 Jira 平滑迁移，因为他们原有资产都在 Jira 上，不想做数据搬家；第三是这套平台的颗粒度可以同时承载任务、迭代、项目三层视角，不需要在三四个工具之间来回切换。我在这里提这些维度，不是让你照单选择，而是提醒你：当你选工具时，真正该问的是"你的机制需要工具承担什么"，而不是"哪个工具功能最多"。

这里可以给一段伪代码，说明一个任务从"开发中"到"可上线"应该经历哪些状态节点，以及每个节点如何被系统记录。

任务状态流转示例（研发场景）：
TODO -> 未开始

IN_PROGRESS -> 开发中

DEV_DONE -> 开发完成（代码提交并通过自测）

IN_REVIEW -> 代码评审中

REVIEW_APPROVED -> 评审通过

IN_INTEGRATION -> 联调中

INTEGRATION_DONE -> 联调完成

IN_TESTING -> 测试中

TEST_PASSED -> 测试通过

READY_TO_RELEASE -> 可灰度 / 可上线

每个状态变更必须记录：

变更时间

变更人

备注（为什么变更，是否有阻塞）

剩余工作量估算（人天）

这段状态流转的关键在于每个节点都有客观可验证的产出，而不是靠主观判断。当任务状态和剩余工作量都沉淀在系统里，燃尽图和累积流图就能自动生成，迭代健康度也就有了数据基础。

六、操作步骤：从今天就能开始落地的六个动作

前面讲了道理和案例，这一节给具体步骤。每个步骤都会说明"做什么、谁来做、输出什么、容易错在哪"，你照着做就能开始。

1. 步骤一：统一"完成"的定义（Definition of Done）

做什么：让团队一起写出本团队版本的完成定义，明确一个任务从"开始"到"真正完成"要经过哪几个节点，每个节点的验收标准是什么。

谁来做：技术负责人牵头，各组 Tech Lead 参与，产品经理旁听保证验收口径一致。

输出什么：一份不超过一页的完成标准文档，贴在团队看板上，新成员入职必读。

容易错在哪：做得太复杂，列了二十个节点，没人记得住。建议控制在 5 到 8 个节点以内，每个节点的判定标准一句话能说清。

2. 步骤二：把任务拆到 1 到 3 天粒度

做什么：把每个进行中的任务拆到 1 到 3 天可以完成，超过 3 天的任务必须继续拆。

谁来做：任务负责人自己拆，Tech Lead 抽查质量。

输出什么：任务列表上不再有挂超过 3 天还状态未变的任务。

容易错在哪：为了拆而拆，拆成一堆没有意义的碎任务。判断标准不是"拆了几个"，而是"每个子任务是否有独立可验证的完成状态"。

3. 步骤三：建立每日 15 分钟进度同步机制

做什么：每日站会控制在 15 分钟以内，每个人只回答三个问题，昨天完成了什么、今天要做什么、有什么阻塞。注意只同步状态变化和阻塞，不汇报细节。

谁来做：各组 Tech Lead 主持，Scrum Master 或 PMO 观察节奏。

输出什么：站会结束后，任务看板上的状态变化已经全部更新。

容易错在哪：站会开成了进度汇报会，一个人讲十分钟。控制时间的关键不是打断，而是把细节讨论移到会后单独拉人。

4. 步骤四：用可视化看板暴露偏差

做什么：把任务状态、剩余工作量、迭代燃尽图做成所有成员可见的看板，任何人都能在 1 分钟内看到整体进度和风险项。

谁来做：PMO 或项目负责人搭建，各迭代负责团队维护。

输出什么：一个常驻的看板，随迭代进度实时更新。

容易错在哪：建了看板但没人看。解决办法是让看板成为站会、评审会的默认参照物，会议一开就投屏。

5. 步骤五：每周做一次进度校准与基线更新

做什么：每周固定 30 到 45 分钟，把当前的实际进展和原基线做一次比对，明确偏差大小和原因，必要时更新基线。

谁来做：PMO 或项目负责人主持，各组负责人参加。

输出什么：一份本周进度校准记录，包含偏差说明和基线更新说明。

容易错在哪：校准变成追责。要让团队明白，校准的目的是早发现早调整，而不是找人背锅。

6. 步骤六：变更必须记录并评估影响

做什么：任何需求、范围、技术方案的变更，都必须显式记录，并评估对进度基线的影响，决定是否更新基线。

谁来做：变更发起人负责记录，项目负责人负责评估影响。

输出什么：一份变更台账，记录每次变更的内容、时间、评估结论。

容易错在哪：把"小变更"当成不需要记录。恰恰是小变更累积起来造成了最大的偏差，所以无论大小都要记录。

七、不同情况下的行动建议：按团队规模分层

方法不能一刀切。10 人团队和 150 人团队适用的做法差别很大，这一节按规模给分层建议。

1. 10 人以下团队：轻机制 + 高透明

这个规模最大的优势是沟通成本低，最大的风险是"全在脑子里"。建议只做三件事：统一完成定义、每日 15 分钟站会、一张所有人能看到的任务看板。

不建议引入重型工具和复杂流程，因为管理开销会超过收益。如果非要用工具，用最轻量的看板即可，重点是把状态可视化，而不是功能齐全。

2. 10 到 50 人团队：机制为主，工具为辅

这个规模是机制建设的最佳窗口期，也是大多数研发团队所在区间。建议把第六节的六个步骤完整落地一遍，工具选择上优先考虑支持任务、迭代、项目三层视角的系统，避免在多个工具之间切换。

关键动作是把进度同步嵌入迭代节奏，站会同步状态、迭代评审校准偏差、回顾会优化机制本身。这个规模如果还能把人肉同步跑顺，就说明机制设计得好；如果已经开始吃力，就是上工具的时机。

3. 50 到 150 人团队：工具承载机制，避免人肉汇总

到了这个规模，人肉汇总进度会迅速成为瓶颈。我见过太多 PMO 每天花两三个小时做表格汇总，产出还是一个滞后两三天的快照，没有任何预警价值。

这个阶段的建议是把机制显式落到系统里，让数据自动汇聚。选择平台时重点关注几点：能否承载多层视角、是否支持私有化部署、能否与现有工具链集成、是否有足够细的权限体系。前面提到的 PingCode 就是这类场景下常见的候选，它能同时覆盖任务、迭代、项目三层，并且支持从 Jira 平滑迁移，适合正在做工具国产化替换的中大型团队参考。

4. 150 人以上：机制、工具、治理三层并重

这个规模已经不是单一的进度管理问题，而是研发治理问题。除了机制和工具，还需要有跨组的依赖管理、定期的度量复盘、明确的变更决策机制。

建议设置专职的 PMO 或研发效能角色，负责机制维护、数据治理和跨组协调，而不是让每个组各自为战。

八、不同情况下的取舍：机制与工具、速度与规范、透明与心理安全

有了建议，还需要讲取舍。因为真实决策里，几乎每一个选择都是 A 和 B 之间的权衡，而不是"哪个更好"。

1. 取舍一：机制优先还是工具优先

答案取决于团队规模。10 人以下，机制优先，工具可以非常轻。50 人以上，工具和机制同等重要，因为机制离开工具就无法规模化承载。中间的团队，可以先机制后工具，但不要拖太久，否则机制会因为手工维护成本过高而自然消亡。

判断标准很简单：如果维护这套机制每周占用的管理时间超过团队总工时的 5%，就该考虑上工具了。

2. 取舍二：速度优先还是规范优先

很多初创团队担心"规范会拖慢速度"，所以宁愿人肉跟。这在早期是合理的，但要在心里设定一个规模阈值。当团队超过 20 到 30 人，或者并行项目超过 5 个，人肉跟进的边际成本会陡增，规范反而成了加速器。

我的建议是：规范不是一次铺满，而是跟着痛感走。哪块疼得厉害就先规范哪块，进度失真最严重就先做完成定义和变更记录，协作阻塞最严重就先做每日同步。

3. 取舍三：进度透明和心理安全的平衡

进度透明会暴露问题，而问题暴露后如果引发追责，团队就会本能地隐瞒，透明度反而下降。这是所有进度管理机制都会遇到的张力。

解法是明确区分"报告偏差"和"隐瞒偏差"的处理方式：报告了偏差并主动寻求帮助的人应当被支持，隐瞒偏差导致问题在后期集中爆发的人需要承担后果。这条规则要在团队里反复讲清楚，因为它决定了你的机制能不能长期活着。

九、常见问题与避坑指南

最后回答几个在实操中最常被问到的问题，每个问题我都给出判断框架而不是万能答案。

1. 团队抵触每日同步怎么办？

先分清是抵触"每日"还是抵触"同步"。抗拒每日站会的团队，往往是因为站会开得太长、太啰嗦、没有价值感。先尝试把站会压缩到 15 分钟，只同步状态和阻塞，把细节讨论移出站会，看抵触是否缓解。

如果团队抵触的是"同步"本身，那往往是心理安全问题，需要从追责文化入手，而不是从流程入手。

2. 远程 / 分布式团队怎么管进度？

远程团队比同地团队更依赖系统化记录，因为信息无法靠走廊聊天自然流动。远程场景下几乎所有进度同步都必须异步化：状态更新由本人异步完成，站会可以是文字异步同步，周会保留视频同步用于校准和决策。

远程团队对看板的依赖度更高，因为看板代替了物理白板，成为唯一的信息汇聚点。

3. 进度总是"前松后紧"怎么破？

前松后紧通常不是执行问题，而是估算问题。研发任务的难度往往在后期集中爆发，导致早期看起来一路顺风。解决办法是在任务中识别高风险任务，提前安排探索性开发或技术预研，把不确定性前置消化，而不是让它在后期集中释放。

另一个技巧是把"最后一步的完成标准"在任务开始时就明确写清楚，让所有人都提前知道最后那几步有多难。

4. 小团队一定要用工具吗？

不一定。10 人以下、项目不复杂的团队，一张物理白板或一份文档就够。但要注意两点：一是任务颗粒度和完成定义仍然要清晰，否则看板也只是好看；二是要有规模阈值意识，一旦超过阈值就上工具，不要因为早期的"人肉跑得动"而错过切换窗口。

5. 进度数据和绩效挂钩，会不会让数据失真？

会。一旦进度数据被直接用于绩效考评，它就不再是真实信息，而变成被管理的游戏对象。建议把进度数据用于机制改进和风险预警，绩效评估另立体系，避免二者直接挂钩。

6. 引入新工具后一段时间团队用得越来越少怎么办？

通常是三个原因之一：机制没跟上、工具学习成本过高、缺少强制参照物。解决顺序是先检查机制，再检查工具是否过于复杂，最后确认看板是否真的成了会议默认参照。多数团队的问题出在第一点，工具只是形式，机制才是内容。

十、总结：让进度信息流动起来，比让某个人盯住进度更重要

回到一开始那家 SaaS 团队的案例。他们后来复盘时最大的收获不是"用了哪个工具"，而是意识到：过去所有延期都不是最后两周才发生的，而是从第一天起就在积累，只是没有人建立一套机制让这些积累被看见。

所以这篇文章如果有唯一一个核心观点，那就是：进度管理的终点不是"管住某个人"，而是"让进度信息在整个团队里自由流动"。当每个人都能实时看到真实状态、每个偏差都能被早发现、每次变更都能被显式记录，进度就不再依赖某个人的盯梢，而变成组织的一种能力。

如果你今天就想开始，我建议只做一件事：把团队里现在进行中的任务，随机挑 5 个，问三个问题，完成标准是什么、现在处于哪个节点、剩余工作量估算是多少。如果这三个问题有一半答不上来，那你的改进起点就已经找到了，就是从"统一完成定义"开始。

先把定义做清楚，再把同步嵌进节奏，最后再考虑工具和规模化。按照这个顺序走，你会发现实际进度这件事，从来没有想象中那么玄，它只是需要被认真对待。