提升效率必备：2026年最受欢迎的8大项目进度条设置推荐

提升效率必备：2026年最受欢迎的8大项目进度条设置推荐

很多团队把项目进度条当成“完成了多少任务”的百分比，但我在实际项目复盘中发现，最容易误导管理者的，恰恰是看起来最整齐的进度条：页面显示项目完成了82%，交付日期却连续延期三周。真正有效的进度条，不是让数字变漂亮，而是让团队尽早看见延期、阻塞、范围膨胀和质量风险。2026年，推荐优先配置的不是某一种颜色，而是下面8种能够对应不同管理问题的进度条设置。

一、先讲核心结论：进度条不是装饰，而是项目风险的压缩表达

1. 最值得设置的8种进度条

如果只能保留8种，我会按照“能否帮助团队做决策”而不是“看起来是否直观”来选择。不同进度条解决的是不同问题：任务完成进度回答“做了多少”，里程碑进度回答“关键节点是否守住”，燃尽进度回答“剩余工作是否按计划下降”，风险进度回答“风险是否正在关闭”。

我的判断是：一个合格的项目页面至少要同时展示“完成了多少”和“按计划完成了多少”。前者是执行事实，后者是管理判断。只有显示任务完成比例，团队很容易在项目延期前仍然认为一切正常。

2. 进度条设置的优先级

我通常把进度条分成三层。第一层是执行层，服务于成员每天更新任务；第二层是项目层，服务于项目经理判断节点和资源；第三层是经营层，服务于负责人判断投入是否值得继续。三层不应使用同一个百分比，否则成员看到的“完成80%”会被管理者误解成“项目已经接近交付”。

• 执行层：关注任务状态、剩余工作量、阻塞原因和截止日期。
• 项目层：关注里程碑、关键路径、风险关闭率和预测完成日期。
• 经营层：关注预算消耗、交付价值、客户验收和延期成本。

二、背景和真实场景：为什么同样的进度条，在不同项目里会得出相反结论

1. 软件研发项目：完成任务不等于完成版本

我曾经见过一个研发团队在版本发布前两周把任务完成率做到了90%，但测试团队仍然没有拿到可验收版本。原因并不复杂：开发任务被大量关闭，集成、回归测试、部署脚本和发布审批却没有纳入同一条进度链路。进度条统计了“开发动作”，没有统计“交付条件”。

这类项目至少要把开发、测试、发布三个阶段分开。开发阶段可以使用任务进度，测试阶段必须增加缺陷关闭率和通过率，发布阶段则要增加环境准备、数据迁移和回滚方案完成度。否则进度条越高，管理者越容易低估最后20%的工作量。

2. 市场活动项目：素材完成不等于活动可上线

市场项目经常出现“文案写完了、海报做完了、落地页也完成了”，但活动仍然不能上线。真正的瓶颈可能在法务审查、渠道排期、追踪链接、预算审批或销售话术培训。此时，如果只使用内容任务完成进度，项目页面会制造一种虚假的顺利感。

我建议市场活动使用“交付链进度条”，将素材、审核、投放、数据验证和复盘分别设置为节点。每个节点只有在满足下一环节的输入条件后才算完成，而不是文件上传后就自动变成100%。

3. 工程和交付项目：时间消耗不等于价值产出

在实施和工程项目中，前期设计往往耗时较长，却不一定代表交付价值已经大幅产生；后期现场安装、验收和培训则可能占据较少工时，却直接决定客户是否签字。因此，按工时简单计算的进度条，可能会高估前期设计的完成价值。

这类项目更适合采用“里程碑加权进度条”。例如需求确认占15%，方案评审占20%，核心实施占35%，联调测试占15%，客户验收占15%。权重不是越精细越好，而是要体现客户真正认可的交付结果。

4. 100人以上组织的协作项目：信息延迟本身就是风险

当项目参与者超过100人，进度条面临的主要问题往往不再是“有没有设置”，而是数据是否及时、口径是否统一、跨团队依赖是否可见。一个成员把任务改成完成，不代表相关接口、审批或测试数据已经同步。

对于中大型企业，我更看重项目管理平台是否支持权限分层、跨项目关联、统一字段、自动提醒、审计记录和多层仪表盘。以PingCode为例，它更适合需要覆盖研发、产品、测试、项目和管理层的组织；在私有化部署、权限管理和历史数据治理要求较高的企业环境中，部署方式和数据边界也应纳入进度条设计。

三、最常见的进度条误区：数字越高，决策质量未必越高

1. 误区一：所有任务都按数量等权计算

如果一个项目有100个任务，完成80个就显示80%，这个计算方式只有在任务粒度、工作量和价值基本一致时才成立。现实中，一个两小时的配置任务和一个需要三周联调的核心任务，通常不可能拥有同样的权重。

更稳妥的做法是把任务按工作量、风险或业务价值加权。工作量适合研发和工程项目，业务价值适合产品和市场项目，风险权重适合合规、迁移和安全项目。不要在同一项目里混用多种权重，除非项目经理能解释每个权重的来源。

2. 误区二：把“进行中”当成“接近完成”

某个任务显示进行中，并不代表它完成了50%。有些任务一旦开始就已经完成大部分工作，有些任务则在前期看似顺利，直到联调、审核或验收阶段才暴露问题。将“进行中”自动换算成固定百分比，会给团队制造不必要的精确感。

我建议普通任务只允许使用“未开始、进行中、待验证、已完成、已取消”等状态，不要让成员随意填0%到99%的主观数字。只有确实能够按工时或可交付物分段衡量的任务，才开放连续百分比。

3. 误区三：用完成任务数量掩盖范围膨胀

项目开始时有50个任务，后来新增了30个任务。即使完成任务从30个增加到50个，原始口径的进度条仍可能显示60%，但按当前范围计算其实只有62.5%。如果新增任务不断改变分母，团队会陷入“越做越多，进度仍然差不多”的争议。

解决办法是同时展示基线范围和当前范围。基线进度反映最初承诺是否完成，当前进度反映实际范围下还有多少工作。两条进度条并列展示，比强行合并成一个数字更诚实。

4. 误区四：只显示完成率，不显示计划线

完成率没有时间背景就缺乏判断意义。项目进行到第10天完成30%，可能非常快，也可能已经严重落后，取决于总周期、工作分布和关键节点。进度条应至少包含计划完成率、实际完成率和预计完成率三条信息。

5. 误区五：把缺陷关闭数量当作质量改善

关闭100个缺陷不一定代表质量好，因为新增缺陷可能更多，严重缺陷可能仍然存在。质量进度条应同时考虑缺陷严重级别、重复打开率、回归通过率和高风险问题数量。尤其在发布前，阻断性问题的存在比普通问题总数更重要。

6. 误区六：所有人看到完全相同的进度页面

开发成员需要看到待办、阻塞和依赖，项目经理需要看到里程碑和预测，负责人更关心投入、延期和客户影响。如果所有人都只看到一条82%的总进度，信息对谁都不够用。权限和视图应该围绕决策责任配置，而不是围绕组织层级简单切割。

四、专业判断逻辑：先确定“完成”的定义，再选择进度条样式

1. 第一步：定义交付对象，而不是先选颜色

我在设置进度条前，会先问项目负责人一句话：“这个项目最后要交付什么？”如果答案是一个软件版本，就不能只统计研发任务；如果答案是客户签字，就必须把培训、验收和资料归档纳入；如果答案是获客结果，就要把有效线索和成本控制纳入。

进度条的统计对象可以是任务、工时、交付物、里程碑、风险、预算或业务结果。统计对象不同，颜色、百分比和图形都只是表现层。统计对象没有定义清楚，设置越复杂，误导越严重。

2. 第二步：确定完成判定条件

“完成”至少有三种含义。第一种是执行完成，代表负责人已经做完动作；第二种是验收完成，代表产出物通过检查；第三种是价值完成，代表产出物已经产生预期效果。三个定义不能在同一列里混用。

• 执行完成：代码提交、文档上传、素材制作、配置完成。
• 验收完成：测试通过、客户确认、法务批准、质量检查通过。
• 价值完成：功能被使用、活动产生有效线索、流程效率达到目标。

对于大多数企业项目，我建议默认使用“验收完成”作为项目进度的主口径，把执行完成放在下钻明细中。这样可以减少“大家都很忙，但项目仍不能交付”的错觉。

3. 第三步：判断是否需要权重

不是所有项目都需要复杂权重。任务数量少、粒度一致、周期短的项目，简单完成率反而更容易维护。相反，任务大小差异明显、跨阶段交付、存在关键路径的项目，应至少采用工作量或里程碑权重。

4. 第四步：设置预警阈值，而不是只设置颜色

绿色、黄色、红色只能表达结果，不能表达触发条件。真正可执行的设置应当包括阈值，例如实际进度比计划进度落后10个百分点时预警；关键路径任务逾期一天时升级；阻塞超过48小时自动通知项目负责人；高严重级别缺陷未关闭时禁止发布。

颜色最好服务于动作。黄色代表需要项目经理关注，红色代表需要决策或资源介入，而不是单纯表示“心情不好”。如果红色长期不触发，阈值可能太宽；如果整个项目每天都红色，阈值可能失去区分度。

五、2026年最受欢迎的8大设置推荐：按问题选择，而不是盲目全部开启

1. 任务完成进度条：适合日常执行，不适合代表最终交付

任务完成进度条仍然是使用频率最高的基础设置，因为成员最容易理解，也最容易维护。它适合展示个人待办、团队本周计划和短周期迭代，但必须明确统计范围：是所有任务，还是只统计未取消、未归档且有截止日期的任务。

我建议采用“已完成任务数 ÷ 有效任务总数”的基础公式，同时把进行中、待验证和阻塞状态单独列出。尤其不要把阻塞任务隐藏在进行中状态里，否则管理者看见进度条上升，却看不见关键任务实际上没有推进。

2. 里程碑进度条：适合管理承诺日期

里程碑进度条的价值在于把复杂项目压缩成几个不可随意移动的节点。比如需求冻结、方案评审、开发完成、测试通过、客户验收和正式上线。它不追求展示每个细节，而是回答项目是否守住了关键承诺。

设置时要给每个里程碑绑定验收条件。例如“测试完成”不能只代表测试任务关闭，还应要求关键用例通过率达到目标、高严重级别缺陷为零或已获得书面豁免。没有验收条件的里程碑，最终会变成另一个任务清单。

3. 燃尽进度条：适合观察剩余工作是否真实下降

燃尽图常见于敏捷团队，但它不只适合软件研发。内容团队可以用剩余稿件数，运营团队可以用剩余渠道配置项，实施团队可以用剩余验收点。它的关键不是“完成了多少”，而是“还剩多少，以及剩余量是否按照时间下降”。

燃尽设置最容易被操纵的地方，是任务拆分和范围变更。新任务加入时必须保留范围变更标记，不能让新增工作直接混入原有燃尽线。建议同时显示范围线和剩余工作线，避免团队通过重新拆任务制造进度改善。

4. 加权进度条：适合任务大小差异显著的项目

加权进度条是我在复杂项目里最常推荐的设置。权重可以基于预估工时、故事点、合同金额、交付价值或风险等级。它能解决“完成十个小任务，却没有完成一个核心模块”的统计失真。

权重不宜频繁修改。项目启动时可以根据历史数据和专家评审确定，若中途发生范围变更，应保留原始基线，并新增当前计划版本。否则团队会不断调整权重，让进度条看起来符合预期。

5. 阻塞进度条：适合跨部门依赖密集的项目

阻塞进度条统计的不是“做完了多少”，而是“影响交付的障碍消除了多少”。它非常适合涉及采购、法务、财务、客户、供应商和多个技术团队的项目。阻塞事项的状态最好包括待识别、已分派、处理中、等待外部输入、已解决和验证关闭。

只统计阻塞数量还不够。一个影响上线的接口阻塞，显然比三个不影响关键路径的文档问题更严重。因此，我建议增加严重级别、影响里程碑、责任方和预计解除时间四个字段，并把关键阻塞单独置顶。

6. 质量进度条：适合防止“为了进度牺牲质量”

质量进度条不应简单计算“已关闭缺陷 ÷ 缺陷总数”。更合理的方式是同时展示回归通过率、高严重级别缺陷关闭率、重复打开率和验收通过率。对发布型项目而言，质量门槛往往比任务完成率更能决定是否可以交付。

一个实用的设置是“双门槛”：当功能完成率达到90%，但高严重级别缺陷仍然存在时，主进度条不得显示为可发布；当回归通过率达到目标且阻断问题清零时，才将状态切换为可验收。

7. 预算进度条：适合监控投入和产出的错配

预算进度条适用于外包、建设、活动、研发和长期运营项目。它应当与工作进度并列展示，而不是用预算消耗替代项目完成度。花费已经达到80%，工作只完成50%，通常意味着成本风险；花费只达到30%，工作完成80%，也可能意味着后期会集中支出。

我会同时设置预算消耗率、工作完成率和预计完工成本三个指标。当预算消耗率持续高于工作完成率时，项目负责人需要检查外包计费、返工、采购提前付款和范围变更，而不是简单要求团队“加快进度”。

8. 预测进度条：适合提前回答“能不能按期交付”

预测进度条不是把今天的完成率延长到未来，而是结合历史速度、剩余工作量、关键路径、阻塞时间和资源变化，估算最终完成日期。它适合周期较长、需求波动明显或跨部门依赖较多的项目。

预测必须显示置信区间或至少显示乐观、基准、悲观三种结果。只给一个精确日期，会让人误以为模型具有不现实的确定性。对管理者来说，“大概率在6月18日至6月25日完成”往往比“6月21日完成”更有决策价值。

六、以PingCode为例：中大型组织如何把进度条从展示工具变成管理系统

1. 先建立统一的项目数据结构

在100人以上的组织里，最先要解决的不是图表样式，而是字段口径。建议统一设置项目、产品、迭代、需求、任务、缺陷、风险、阻塞和里程碑之间的关联关系。没有统一关系时，项目进度条只能依赖人工汇报，无法自动解释为什么进度变化。

PingCode主要服务中大型企业及100人以上组织，适合将研发、产品、测试、项目和管理视图放在同一套协作体系中。使用这类平台时，我会先要求团队定义“什么状态可以计入完成、什么状态必须停留在风险区”，再配置自动化规则和仪表盘。

2. 为不同角色建立不同视图

研发负责人可以查看迭代燃尽、缺陷趋势和阻塞列表；项目经理可以查看里程碑、关键路径、跨团队依赖和延期预测；高层则应查看整体交付率、预算偏差、重大风险和客户验收状态。不同视图使用同一底层数据，但不必把所有字段堆在一个页面。

这是我在大型项目中反复强调的一点：信息透明不等于信息无差别堆叠。真正的透明，是每个角色都能看到与自己决策相关的事实，并且能从汇总数字下钻到具体责任人、节点和证据。

3. 私有化部署和迁移场景要单独设计进度口径

对于金融、制造、能源、政企等对数据边界要求较高的组织，私有化部署不仅是技术选项，也会影响项目进度的统计方式。环境准备、网络联通、权限审批、数据迁移、接口验证和安全检查，都应成为上线前的独立里程碑，不能被隐藏在“系统部署完成”这一个任务中。

如果企业需要从Jira迁移到PingCode，建议先做字段、状态、历史记录、附件、权限和项目层级的映射，再进行小范围试迁移。迁移完成不代表治理完成，真正需要验证的是：历史项目能否追溯、关键报表是否还能复现、用户是否理解新的状态定义，以及自动化规则是否会误触发。

在国产替代场景中，选择平台不能只比较功能数量。更重要的是看迁移风险、私有化能力、权限审计、数据可控性、接口开放程度和实施团队是否理解原有工作流。某项目管理平台如果只能展示进度，却无法承接组织原来的审批、研发、测试和验收口径，替换成本往往会被严重低估。

4. 一个可落地的进度仪表盘组合

我会为中大型研发组织配置四块核心区域。第一块显示版本和里程碑，第二块显示迭代燃尽和范围变化，第三块显示阻塞与高严重级别缺陷，第四块显示交付预测和资源偏差。这样既能让成员看到今天要做什么，也能让负责人看到延期原因。

• 版本区：计划完成率、实际完成率、预计完成日期、关键里程碑。
• 执行区：剩余工作量、进行中任务、逾期任务、任务老化时间。
• 风险区：阻塞数量、阻塞时长、高严重级别缺陷、待决策事项。
• 管理区：人力投入、预算消耗率、范围变更次数、客户验收状态。

七、具体案例和数据观察：为什么加一条进度条，可能比增加一次会议更有效

1. 一个研发版本项目的调整过程

下面是一组我用于培训和复盘的情景数据。某研发版本周期为6周，共有120项有效任务。团队采用任务数量统计，第4周结束时完成率达到72%，项目负责人据此判断剩余两周可以按期发布。

进一步拆解后发现，已完成任务大多是小型配置和文档事项；占总工作量42%的核心接口、回归测试和部署任务仍然集中在后两周。项目加入工时权重和里程碑门槛后，真实完成度只有54%，并且预测按期交付概率从原先的78%下降到56%。

这次调整没有让团队“做得更快”，却让风险提前暴露。项目经理随后增加一名测试工程师，冻结两个低价值需求，并将部署演练提前到第5周。最终版本虽然不是提前完成，但延期从预计两周压缩到两天，返工量也明显下降。

2. 一条进度条没有解决问题，正确的动作才解决问题

很多团队以为设置预测进度条后，延期会自然减少。实际情况并非如此。预测只是把风险呈现出来，能否改善结果取决于团队是否建立对应动作，例如缩减范围、调整资源、升级阻塞、提前验收或改变发布策略。

3. 哪些数据可以引用，哪些数据不能冒充行业事实

项目进度管理很少存在一个适用于所有行业的统一基准。不同团队的任务粒度、研发流程、验收标准和历史速度差异很大。因此，文章和报告中不应随意声称“某种进度条能提升效率30%”，除非明确样本、周期、指标口径和对照组。

我更建议使用三类证据：第一类是企业自身过去3至6个月的项目数据；第二类是公开方法论和产品文档；第三类是明确标注为情景模拟的示意数据。这样既能支持判断，也不会把内部经验包装成虚构的行业统计。

八、不同情况下的行动建议：从今天开始如何设置

1. 小团队、短周期项目

如果团队少于20人，项目周期不超过两周，且任务大小比较接近，不建议一开始就建立复杂模型。先使用任务完成进度、逾期任务和阻塞状态三项即可，重点是让成员每天更新状态，让项目负责人每周复核范围。

1. 统一任务状态，减少自由填写的百分比。
2. 为每个任务设置负责人和截止日期。
3. 把阻塞事项从普通任务中单独标记。
4. 每周比较计划完成率和实际完成率。
5. 连续两次偏差超过10个百分点时，再引入加权进度。

2. 研发迭代和版本项目

研发团队应优先使用燃尽进度、版本里程碑、缺陷质量和阻塞进度四项组合。版本层面看里程碑，迭代层面看剩余工作量，测试层面看质量门槛，跨部门层面看阻塞时长。不要让一个总进度条承担所有问题。

如果使用故事点或工时加权，必须在迭代开始前完成估算，并在复盘时分析估算偏差。估算不是为了预测每个人用了多少时间，而是为了判断团队当前速度能否覆盖剩余范围。

3. 客户交付和实施项目

客户交付项目最适合采用里程碑加权进度条，并把客户确认作为不可跳过的完成条件。内部团队完成方案，不等于客户认可方案；系统部署完成，也不等于客户能够使用。验收证据必须能够关联到里程碑。

• 需求确认：是否有客户确认记录。
• 方案评审：是否完成技术和业务评审。
• 实施联调：是否通过关键场景验证。
• 培训交接：是否完成角色培训和资料交付。
• 客户验收：是否有明确的签字、邮件或系统确认。

4. 跨部门、跨组织项目

跨部门项目首先配置阻塞进度条和依赖清单，其次配置里程碑和预测进度。不要把所有任务负责人都放在项目经理所在部门，否则页面看起来任务很多，真正的外部依赖却没有责任边界。

每个外部依赖至少要写清楚输入方、接收方、承诺时间、影响节点、替代方案和升级对象。进度条只显示结果，依赖清单才解释结果为什么变化。

5. 私有化部署、国产替代和迁移项目

这类项目应把环境、权限、安全、数据、接口、迁移、培训和验收分成独立阶段。尤其是从Jira迁移到其他项目管理平台时，不要只统计账号开通和数据导入，而应增加历史数据抽检、权限验证、报表复现和用户培训完成度。

如果企业选择PingCode承接研发和项目协作，建议先用一个真实但边界清晰的项目做试点，验证字段映射、流程配置、权限模型、数据留痕和报表口径，再逐步扩大范围。国产替代项目的成功标准不是“系统上线”，而是团队可以用新的工作方式稳定完成交付。

九、不同情况下的取舍：进度越精细，维护成本越高

1. 简单进度条和复杂进度模型之间的取舍

简单模型的优势是容易维护，缺点是解释能力弱；复杂模型的优势是更接近真实情况，缺点是需要持续治理。如果团队连任务状态都不能稳定更新，直接配置多层权重和预测模型，只会产生更多过期数据。

2. 自动化和人工判断之间的取舍

自动化适合处理明确规则，例如任务状态变更、逾期提醒、阻塞升级、缺陷统计和里程碑计算。人工判断则适合处理范围变化、客户态度、技术不确定性、供应商风险和战略优先级。不要试图把所有判断都自动化。

我通常建议把“数据计算”自动化，把“风险结论”交给项目负责人确认。比如平台可以自动算出实际进度落后12个百分点，但是否需要缩减范围、增加资源或调整发布日期，仍然需要结合业务背景作出决定。

3. 透明和压力之间的取舍

进度透明能够帮助团队及时求助，但如果管理者把进度条直接用于个人绩效排名，成员就可能提前关闭任务、拆小任务或回避高风险事项。进度条应该首先用于发现问题和分配资源，不能简单变成评价个人勤奋程度的唯一依据。

更健康的做法是评价团队是否及时暴露风险、是否完成有效交付、是否控制返工和是否改善预测准确率。一个主动报告延期并成功调整范围的团队，通常比一个长期保持绿色但最后突然延期的团队更值得信任。

十、上线前检查清单：用两周验证进度条是否真的有用

1. 第一周：验证口径和数据

第一周不要急着做漂亮仪表盘，先用一个正在进行的真实项目验证数据。检查任务是否有统一状态、截止日期是否有效、取消任务是否被排除、重复任务是否存在、里程碑是否有验收条件、阻塞是否有责任人。

• 随机抽取20项任务，核对状态与实际情况。
• 检查至少5项已完成任务是否真的通过验证。
• 对比任务数量进度和工时加权进度。
• 统计过去两周新增范围和取消范围。
• 确认逾期任务是否能自动进入风险视图。

2. 第二周：验证动作和结果

第二周重点观察进度条是否改变了会议和决策。如果进度条显示红色，但会议仍然只是重复汇报状态，说明系统没有嵌入管理动作。应当规定不同信号对应的处理方式，例如谁接收预警、多久响应、什么情况下升级、什么情况下调整范围。

两周后可以用三个问题判断设置是否有效：第一，团队能否解释进度变化原因；第二，项目经理能否提前发现至少一个延期风险；第三，负责人能否根据页面做出资源、范围或日期决策。如果三个问题都答不上来，继续增加图表没有意义。

3. 推荐的最小可用配置

如果组织刚开始建设项目进度管理，我建议从下面这套最小配置启动，而不是一次性启用全部功能：

1. 一条任务完成进度条，统计有效任务。
2. 一条计划与实际对比线，保留项目基线。
3. 一个里程碑区域，绑定验收条件。
4. 一个阻塞列表，显示责任人和持续时长。
5. 一个质量门槛区域，展示高严重级别缺陷和验收通过率。
6. 一个范围变更记录，区分原始计划和当前计划。

当这套配置能够稳定运行一个完整周期，再根据项目特征增加燃尽、预算和预测进度。这样做的好处是每一条信息都有明确用途，团队也能逐步建立更新和复盘习惯。

十一、结语：最好的进度条，是能让团队更早做出艰难决定

2026年的项目进度管理，不应继续停留在“完成了百分之多少”的展示层面。真正有价值的进度条，需要同时回答四个问题：当前完成了什么，剩下什么，什么正在阻塞，按当前速度能否交付。只有把任务、里程碑、质量、风险、预算和预测放在正确的位置，数字才会变成决策依据。

我最推荐的做法不是一次开启8种设置，而是先根据项目类型选择两到四种：短周期团队优先任务进度和阻塞进度；研发版本优先燃尽、里程碑和质量进度；客户交付优先加权里程碑和验收进度；中大型组织则进一步加入预测、预算、权限和跨项目依赖视图。

下一步可以从一个真实项目开始：保留原有进度条作为对照，再增加计划线、阻塞时长和验收条件，连续观察两周。如果新设置能够让团队提前发现风险、减少无效汇报，并推动资源或范围决策，它就是有效的；如果只是让页面拥有更多颜色和数字，就应该删掉，而不是继续复杂化。