FPGA编译加速实战：从13小时到5小时的优化路径

做了几年FPGA开发，不知道你有没有经历过这种绝望：早上上班点了综合，显示预计运行时间13小时，然后一整天都在焦虑中度过，改个代码要等半天才能看到结果。更狠的是，晚上临走前启动编译，以为第二天早上能好，结果早上打开CC一看，才跑到60%，而且卡在布局布线阶段死活过不去。

这种现象在越大的工程里越常见，尤其这两年AI加速器、视频处理、通信基带这类动辄几十万LUT的复杂设计多了起来，编译时间已经从过去的“等个午饭”变成了“等一整天”。很多人第一反应是换更强的服务器，第二反应是骂工具不好用，但实际项目中真正拉开差距的，往往是你怎么用工具、怎么拆设计、怎么定约束。

这篇文章就围绕“FPGA编译加速”这个话题，把我在几个大型项目里踩过的坑和攒下来的经验整理一遍。文章内容不只覆盖Vivado和Quartus这两大主流工具，也会涉及一些通用思路，比如怎么看时序报告、怎么拆层次、怎么用增量编译和多人协作流程，目标是帮你把十个小时级别的编译周期压到一个合理范围。

先说结论：同一个工程，13小时和5小时的差距，通常不是工具版本决定的，而是工程习惯、约束质量、以及你对设计层次的把控能力决定的。下面进入正题。

1. 编译到底慢在哪里：先搞清楚13个小时去哪了

加速的前提是知道时间花在哪儿。FPGA编译流程一般分四步：综合（Synthesis）、布局（Place）、布线（Route）、时序收敛（Timing Closure）。这四步不是平均分时间的，不同设计瓶颈差异很大，但大多数项目的耗时大头出现在布线和时序收敛。

1.1 综合阶段：别再小看逻辑优化

综合阶段是把RTL代码映射为LUT、FF、DSP、BRAM这些底层资源。很多人以为综合占比不大，实际上对于含有大量状态机、复杂运算逻辑或大规模参数化模块的工程，综合耗时可能占到总编译时间的10%~20%。

举个实际例子，我曾经做过一个8路视频缩放拼接的工程，代码里用了大量generate语句和复杂的地址计算逻辑，单次综合跑了差不多40分钟，而一次完整编译大概5小时，比例在13%左右。这个比例看着不高，但它的问题在于：综合时间很容易通过加代码规模“失控”，尤其是当你把很多可综合的for循环展开了成百上千次的时候。

综合阶段的优化思路集中在两点：一是减少不必要的冗余逻辑，二是善用综合属性或综合策略，但别指望综合阶段能带来“质的飞跃”，真正的大头在后面。

1.2 布局布线：编译耗时的真正大头

布局布线占据编译总时长的一半以上，通常能到60%~70%。布局做的是一件听起来简单但计算量巨大的事情：把综合出来的网表映射到FPGA物理的CLB、DSP、BRAM位置上，并且让关键路径满足时序约束。

布线更费时间。你可能听过一个比喻：布线就像在城市里规划交通，既要保证每条路都能通，又要避免拥堵，还要满足每条路径的时延要求。对于一个100万门的设计，布线器需要处理的连接点数量是几百万甚至上千万级，每一次尝试都是大量计算。

这也是为什么很多工程在布局布线阶段卡住，表面看着“进度条在走”，实际上工具在做大量迭代和路由尝试。如果时序约束本身不合理或者过于激进，布线器会反复尝试更多路径组合，耗时成倍上升。

1.3 时序收敛：14小时和5小时的真正分水岭

我在不少项目里观察到一个规律：布局布线本身的时间是相对可控的，真正导致编译时间失控的，是“布局布线完成之后，时序并不收敛，工具一遍又一遍地重试”。

一次不满足时序，工具会重新做布局、重新布线或者对局部做优化，这个过程可能重复多次。在极端情况下，一次完整编译的80%以上时间都花在了时序收敛的重试上。换句话说，13小时和5小时的差距，很多时候不是一步步慢出来的，而是在时序收敛环节中间反复跑了很多轮。

所以，想要压缩编译时间，单纯换机器是不够的。下面几个章节展开讲各种可行的手段，从工具命令到工程流程，再到代码层面的策略，我会标出每一条在实测中的收益。

2. 解包工具自带的三板斧：增量编译、多线程与策略调整

FPGA工具链本身提供了一些编译加速手段，它们的效果不是玄学，实测非常明显。这一节先讲最基础的几种，适合所有项目直接套用。

2.1 增量编译：改一行代码，不用重跑全流程

增量编译的原理很简单：工具会为每个阶段保存中间结果，当你只修改了小部分代码时，从上次的结果基础上继续，而不是从头再来。

在Vivado里，对应的概念是Incremental Compile，保存上一次综合和布局布线的checkpoint（一般是.runs/synth_1/xxx.dcp和.runs/impl_1/xxx.dcp），下次编译时给工具指定参考dcp文件，它能自动对比设计差异，只做局部重做。Quartus里对应的是增量编译分区（Incremental Compilation Partition），通过Logic Lock Region把设计分成多个分区，每个分区单独保持上一次的结果。

实测效果：在一个中等规模工程（约20万LUT）上，只改了一个模块内部几个状态机的跳转条件。完整编译需要4小时左右，开启增量编译之后，第二次编译只花了大约40分钟，时间压到了原来的1/6。增量编译在小改动场景下的收益就是这个量级，谁用谁知道。

2.2 多线程编译：白捡的CPU红利

综合、布局布线工具普遍支持多线程。Vivado和Quartus都在设置或Tcl命令层面提供线程数控制参数，设置方法我在下面给出具体命令。

Vivado中可以通过Tcl设置综合与实现阶段的线程数：

set_param general.maxThreads 8

Quartus中则是在Assignment Editor或QSF文件里设置：

set_global_assignment -name NUM_PARALLEL_PROCESSORS 8

这里需要特别提醒一个容易忽略的点：多线程的收益并不是线性的。实测下来，综合阶段的加速比相对稳定，从单线程到4线程大概能快2~3倍；但布局布线阶段，线程数从4加到8，收益很少，甚至可能出现“负优化”的情况，因为布线器的多线程需要处理较多线程同步开销。所以，线程数设置成8对综合阶段有用，布局布线阶段实际可能只用到4个线程的效能——最终总编译时长大约能压缩20%~30%，并不夸张，但有一些增益。

网上有些人说“多线程没用”，多半是只改了参数却忘了看工具是否真正生效（比如在分布式环境中线程数被限制，或者在综合脚本里被后面的命令覆盖了）。正确做法是设置完参数之后，先跑一个小工程对比一下时间，确认生效再推广。

2.3 实现策略（Implementation Strategy）：时间换空间的取舍

Vivado的Implementation默认使用性能优先的策略（PerformanceExplore等），这类策略会以更长的运行时间换取时序余量。如果项目当前处于功能调试阶段，时序压力不大，完全可以把策略切换成性能更低但更快的版本。

Vivado里可以指定的常用策略包括：

• Performance_Explore：默认偏高，慢。
• Performance_ExtraTimingOpt：进一步优化时序，更慢，通常不用。
• Flow_RuntimeOptimized：这个策略明显偏向运行时优化，适合追求快速出结果。
• Congestion_SpreadLogic：布局阶段尝试分散热点，运行时间中等，对拥塞类设计有帮助。

Quartus中也有类似概念，编译模式（Compilation Mode）可以选择“Normal”（普通）、“Fast Functional Test”（快速功能测试）、“Performance”（高性能）等模式。功能验证阶段可以选择Fast Functional Test，它会跳过大量布局布线优化，几分钟内得到网表级结果，主要用于功能仿真验证。

需要留意的是，RuntimeOptimized策略不会给你时序最好的结果，有些设计一旦时序很紧，换这个策略之后布局布线虽然跑完了，但时序不收敛，结果又得回到默认策略，来回折腾反而更慢。所以我一般只建议在两类场景下使用这种快策略：一是纯功能验证，二是时序余量很充足的设计（比如约束较松的demo工程）。

3. 从根源解决问题：为什么同样的工程，别人编译就是比你快

工具级手段用完之后，接下来要直面根源：工程本身的设计质量和约束质量。这是拉开5小时和13小时差距的关键所在。

3.1 时序约束质量：别把“紧约束”当成“认真约束”

时序约束是FPGA开发中老生常谈却又经常被搞砸的部分。约束质量差，不仅导致时序不收敛，还会直接拉长编译时间。

我遇到过最典型的场景：某模块的时钟约束比实际工作频率严格了百分之二三十。开发者的原意是“留点余量”，但布线器不知道这是“余量”，它只知道自己面对的约束非常紧，于是拼了命做各种优化尝试，把布局布线时间拉得非常长。

还有一个更常见的问题：主时钟约束忘了加，派生时钟也没有约束全。工具遇到未约束路径时，会用默认的“假路径”处理，某些路径放宽了，某些路径反而变得很紧，导致布线器在一些原本不该紧张的路径上浪费大量时间。

怎么检查自己的约束是不是“病态紧”？看综合或实现后的时序报告，重点统计三类信息：

如果WNS和TNS都显示路径非常紧张，但代码里的实际逻辑并不复杂，大概率是约束本身设置得不合理。这个时候不要急着改代码，先回到约束文件，把每一条约束重新审视一遍。

3.2 层次化设计：让综合器和布线的“脑力”用在刀刃上

工程规模的膨胀是编译变慢的底层原因之一。一个几十万LUT的模块揉平之后，综合器需要面对完整的逻辑网表，优化求解的复杂度非常高；布线器的布线图也变得极其复杂，难以做局部优化。

层次化设计在加速编译上能做两件事：

第一，把大模块拆成合理的子模块，每个子模块的大小和时钟域相对独立。Vivado中可以使用OOC（Out-of-Context）模式单独综合子模块，Quartus中使用Partition进行分区综合。子模块综合结果以db文件或dcp形式保存，只改动某一个子模块时，其他模块不用重新综合，能明显加快迭代速度。

第二，用好物理约束（Pblock / Logic Lock），告诉工具“这片逻辑应该放在哪个区域”。物理约束做得好，布局过程会快很多，因为工具不需要在全局范围内寻找最优位置。多人协作的项目里这一点尤其重要，把FPGA划分成若干区域，各团队固守自己的区域，整个工程的布局收敛速度和时序质量都会好很多。

3.3 代码层面的编译友好性：少写“让工具头疼”的代码

工具优化时最怕的是两类代码：一类是全连接路由，另一类是巨型组合逻辑。全连接路由意味着任意两个信号可能相互影响，布线器没法做局部裁剪。巨型组合逻辑则让综合器需要花大量时间去做逻辑化简和时序优化。

实践中常见的“坏代码”包括：

• 用一个大always块做所有模块的交叉互联；
• 组合逻辑链过长，状态机之间通过很长的data path相连；
• 使用不规范的循环变量进行巨型阵列计算，展开后逻辑规模爆炸。

这些坏习惯在编译时间上的影响可能不像功能错误那么直接，但会让工具在综合和布线上耗时数倍。代码写的清爽，约束写的干净，工具跑起来就会顺很多，这是底层逻辑。

4. 从流程上动刀：分布式编译、夜间编译和机器配置的取舍

工程级手段之外，还可以从流程和硬件层面挖掘空间。

4.1 分布式编译：多人协作的真正解药

一个大型FPGA工程，如果只有一个人编译，无论怎么优化工具参数，总量就摆在那。但如果是多人协作，分布式编译思路就很有价值了。

在理想情况下，每个工程师只在自己的子模块上独立综合、独立验证，然后把最终代码集成到主干工程时，才需要做一次完整编译。现代工具基本都支持这种模式：把顶层模块和各个子模块拆开，每个子模块单独约束到独立物理区域，然后通过模块级的checkpoint拼装出最终的比特流。

Vivado支持DCP级别的模块化综合，Quartus支持Exported Partition和Logic Lock分区。我做过最大的一个项目，FPGA是XC7VX690T级别，整片资源几乎用完，团队4个人同时开发。如果不拆模块，每轮集成完整编译8小时起步；拆成分区并行，每个人在自己分区内做局部实现，最后顶层拼装只花1~2小时，整个迭代节奏完全不一样。

有一点必须注意：分区接口的信号时序约束一定要严谨，否则拼装阶段会发现跨分区的路径大量不满足时序。这又得回到前面说的约束质量。

4.2 夜间编译与Linux服务器：时间管理是项目管理的暗线

我身边不少团队还在用Windows机器跑大工程，一到下午三点开始跑编译，等到晚饭回来还在布局。换到Linux服务器之后，体验完全不同——不是Linux本身有多神，而是服务器通常能配更高的CPU核数、更大的内存和更快的SSD。

内存大小经常被忽略。布线器在高峰期会占用大量内存，如果你经常看到工具因为内存不足而内存交换严重，编译时间会直线上升。Vivado和Quartus的官方建议配置一般都能找到，但实际项目中，一个中等偏大型的工程建议至少32GB内存起步，64GB以上更稳妥。

夜间编译是更简单直接的时间杠杆。白天写代码的时候顺手点一个后台编译，睡前看邮件或看编译日志确认是否报错，第二天早上起来直接看结果。这个方法不改变工具速度，但把“编译时间”从工作时间表中挪到了非工作时间，对研发节奏的影响非常大。

4.3 机器配置的边际效应：是不是核心越多越快？

我之前也被“核多=快”的思路带偏过，给编译服务器配了64核，结果一个工程从12小时降到8小时，之后就再加核也没有明显变化了。原因是综合和布局布线阶段，工具内部存在大量串行依赖，多线程并不能把每个阶段的耗时都压下去。

实测下来，16核、32GB内存、NVMe SSD是一个性价比很高的组合。再往上堆硬件，边际收益会迅速衰减。对一个FPGA团队来说，与其疯狂堆一台机器，不如买两三台中档机器做分布式分区，总体收益反而更明显。

5. 那些年我在编译加速上踩过的坑

前面讲的基本是“方法论”，这节专门说一下我在实际项目中反复踩过、花了不少冤枉时间去绕弯的坑。这些细节在工具文档里通常写着“建议”，但很多人不会真正意识到它们对编译时间的影响。

5.1 用了增量编译，接口改动却全量重跑

增量编译不是万能的，它对改动范围敏感。如果你只是改内部逻辑，收益非常明显。但一旦改了模块的端口列表、时钟结构、或全局约束，工具会判断“改动过大”，自动触发全量重做。这个机制也是合理的，不然增量结果会失真。

所以启动增量编译前，先确认改动的影响范围。如果改了接口或者时钟拓扑，不如直接跑完整编译，反而节省了“判断-放弃增量-重新全量”的时间。

5.2 “综合时序”满足不代表“实现后”一定满足

在Vivado和Quartus里，综合后都会给一个时序估计。很多工程师在综合阶段看到WNS为正就放行了，结果实现阶段跑到深夜还在收敛。工具的综合和实现是两套优化算法，综合阶段满足时序不代表布局布线之后一定满足。更稳妥的做法是在综合完成之后，快速跑第一步布局布线，再打开实现后的时序报告判断是否真的收敛，不要等全部走完才看结果。

5.3 总线接口改动引发的“牵一发动全身”

FPGA里总线接口的位宽、时序约定一旦变化，影响面不只是一个模块，而是所有挂在总线上的模块和约束。我曾经改了一次AXI接口的数据位宽，以为是个小改动，结果涉及DMA、DDR控制器、图像缓存等模块的时序和约束，导致那一轮编译比预期多了好几个小时。

类似这种总线级改动，建议第一步先用快速策略或功能验证模式跑一遍，确认功能能通，再启动完整实现，避免浪费昂贵的全流程时间。

5.4 太相信第三方IP的默认配置

第三方IP核（尤其是来自Xilinx/Intel官方之外来源的IP）默认配置不一定针对你的器件优化过。有些IP开着大量调试接口和log逻辑，默默消耗可观的逻辑资源，导致整个工程布局布线难度上升。集成IP后看一下资源报告，如果某个IP占了超出预期的LUT或FF，先检查它的配置，很多调试选项是可以关掉的。

6. 一个从13小时到5小时的完整实测案例

讲了这么多，用我之前做的一个项目把实施过程串一遍。这个项目是一个基于Kintex-7的4K视频采集与处理系统，资源占用约65%的LUT，完整编译时间起初在13小时左右，项目周期紧，每次集成验证都要等大半天，开发节奏非常煎熬。

6.1 启动加速前的编年史

项目最初的约束是上一个工程师留下的，综合后发现大量path的WNS在-1ns到-2ns之间，TNS到了-100ns以上，时钟约束是120MHz，但实际工程的运行频率需求只要100MHz。换句话说，约束本身就是“硬扛状态”。

初始编译流程：综合默认策略，实现默认PerformanceExplore策略，单线程，内存16GB的Windows工作站，每次集成完整编译13个小时起步。

6.2 加速方案落地清单

这一步不是单点突破，而是多管齐下：

第一，修正约束。把实际工作频率所需的100MHz约束明确写上，同时梳理主时钟、生成时钟、跨时钟域路径，给跨时钟域加上了set_false_path或set_max_delay约束。这一步的收益最大——第一次跑实现后，WNS变成了正数，TNS清零，布线器收敛时间大幅缩短。

第二，打开多线程。在综合和实现脚本里统一设置了set_param general.maxThreads 8，并在项目说明文档中写清楚验证过8线程比4线程有收益，高于8没有明显变化。

第三，切换实现策略。在功能验证阶段全部使用Flow_RuntimeOptimized，所有feature验证通过之后再跑一次Performance_Explore作为正式时序签核。

第四，拆分子模块做OOC综合。把图像缩放、色彩空间转换、DDR读写控制等几个相对独立的子模块切出去，各自单独综合，每次迭代只综合改动的模块。

第五，把编译从Windows工作站迁移到Linux服务器，配了16核、64GB内存、NVMe SSD。

6.3 实测数据：13小时到5小时

经过上述调整后，同一工程完整编译的时间从13小时降到了5小时左右。最直观的变化是：早上进公司之前点一次编译，中午之前就能拿到完整的bitstream和时序报告，整个团队的迭代节奏显著加快。

从各个阶段的耗时看：

综合阶段从1.5小时到40分钟，主要是多线程+OOC拆分的功劳；布局布线阶段大幅缩短，约束修正起了决定性作用，布线器不需要再做大量徒劳的时序收敛尝试。

6.4 这次优化给我的几点体会

如果只总结这次优化带来的教训，大概有三条：

第一，编译时间膨胀往往不是“CPU不够快”的体现，而是约束质量差导致的工具重复劳动。约束质量上花的每一分钟，都能在编译时间里赚回来。

第二，增量编译和OOC模式是“改小代码”场景下的加速核心，但它需要工程结构支持，指望靠一个按钮解决所有问题的想法不现实。

第三，先修约束、再调策略、最后再说硬件升级。顺序反了，往往花了大钱但效果一般。

7. 再深挖一层：时钟约束的“判断题”和“应用题”

约束是加速编译最该深挖的一层，这里单独展开说一下时钟约束的常见误区和正确处理方式。

7.1 主时钟约束：用对create_clock是基础

主时钟的来源通常是板级晶振或PLL输入。约束的规范写法是：

create_clock -period 10.000 -name clk_sys [get_ports clk_sys]

这里的-period写的是时钟周期，10ns对应100MHz。需要注意，如果设计里还有分频或倍频之后的时钟，Vivado和Quartus通常会自动推导出生成时钟，但你仍然建议显式用create_generated_clock把关系描述清楚，避免工具理解错域间关系。

7.2 跨时钟域约束：该设set_false_path就直接设

跨时钟域（CDC）路径是常见的问题来源。如果两端时钟是异步的，就需要在约束中声明这部分路径为false path，否则布线器会尝试让这些路径满足严格的建立/保持时间要求，导致大量不必要的优化尝试。

set_false_path -from [get_clocks clk_a] -to [get_clocks clk_b]

这里有一个容易搞混的点：如果两个时钟是同源（比如PLL出来的不同分频），它们之间是同步关系，不能用set_false_path直接一刀切，应该用的是set_max_delay配合同步器寄存器来做约束。

正确的CDC约束需要区分“真异步”和“伪异步”，从门级时序模型准确描述，否则也会导致工具白费力气。

7.3 输入输出约束：板级时序的互动

输入输出路径的约束也影响整体收敛。比如输入信号相对时钟的建立/保持时间、输出信号到片外的负载等，不正确约束可能导致片上布局布线器在IOB区域做大量无效尝试。这里常用的是set_input_delay和set_output_delay，它们告诉工具在芯片边界上信号的时序关系。

这部分内容不展开太多，核心思想是：约束不是“能跑就行”，而是你要在工具能理解的语义下，准确地告诉它哪些路径该优化、哪些路径不该管。把这道“判断题”做对，工具才不会把算力浪费在无效路径上。

8. 设备选型与升级时机：什么时候该考虑换FPGA，什么时候只该改流程

有些项目编译慢，本质是资源利用率太高，布线器几乎找不到合适的位置来安置逻辑。这类工程无论怎么调策略，编译时间也很难压到理想区间。

识别这种现象的方法很简单：看布局布线的拥塞报告（congestion report），如果热点区域的拥塞程度达到了80%以上，并且不管怎么调物理约束都在同一个位置爆红，那么考虑换更大一号的FPGA或重新划分资源，比继续折腾编译参数更有价值。

反过来，如果时序报告显示WNS很宽松，TNS也没有异常，纯属工程训练时间太长，这就是流程和工具配置问题，优先用前面说的方法解决，不需要升级硬件。

时机判断上，还有一个容易被忽略的信号：团队的迭代节奏。如果每天需要进行多次集成验证，每次编译耗时超过4小时，那么编译加速的优先级应该提升到和功能开发同等的高度。因为这种等待时间对项目进度的影响非常大，值得专门投入精力去优化。

9. 加速工具链之外：用好脚本和自动化

FPGA编译提速的另一个层面是自动化，这部分的收益不是“让单次编译变快”，而是“减少无谓编译的次数”。

9.1 用脚本守护每一次编译的起点

在项目里写一个编译脚本，统一完成如下动作：从版本控制拉取最新代码，检查最近一次提交修改了什么模块，根据改动范围决定是全量编译还是增量编译，并在编译完成后自动发邮件报告摘要。

这个脚本本身并不复杂，核心价值是让团队每次启动编译时，都按程序规定的最优方式执行，而不是依赖每个人对工具的理解程度。我见过不少团队，同一工程在不同成员手里编译时间差了一倍。一个模板脚本，能很自然地把大家的“手艺”拉齐。

9.2 自动化时序报告解析：别等全部跑完才看结果

Vivado和Quartus都支持在布局布线完成后自动汇报时序摘要。可以在脚本里加上一段逻辑：跑完布局布线第一阶段后自动解析WNS/TNS，如果发现是负数，立刻终止后阶段的优化，直接输出“时序有问题，请先看约束”的提示，而不是让它继续跑额外几个小时的优化重试。

这个流程上的小改动，能让团队每天省下大量的无效编译等待时间。

在日常项目中，我会把如上思路沉淀成一个“编译加速清单”，每次新项目启动时逐项检查：

• 约束文件是否已由资深工程师审查过，全部时钟路径都有明确约束；
• 综合策略和实现策略是否符合当前开发阶段（调试/验证/时序签核）；
• 增量编译、OOC分区和物理约束是否已经建立好；
• 线程数和机器配置是否匹配，是否有并行资源可用；
• 是否设置好自动脚本和时序摘要检查，避免无效等待。

这张清单在执行中不断更新，项目越复杂，价值越大。

10. 写在最后的实操补充：从13小时到5小时，你该从哪里动手

如果你现在正面临编译时间过长的困境，第一步应该打开上一次编译的log，找到“Total Time”和各阶段分项时间，看看卡在综合、布局布线还是时序收敛。这是所有加速动作的前提，没有数据支撑的优化都是盲调。

然后从下面这三个优先级开始动起：

第一优先级：检查时序约束。WNS和TNS是否正常？未约束路径是否为0？这里解决的往往是“布线器为什么反复重试”的根本问题，也是性价比最高的动作。

第二优先级：启用增量编译和多线程。这两个是工具设置层面的改动，不需要改代码和结构，几分钟内就能看到收益。

第三优先级：做OOC分区或增量分区。这个需要一点工程结构调整，但当你要长期在一个大工程上迭代时，这一步带来的收益会越来越大，投入完全值得。

完成这三步后，再根据团队情况考虑流程级优化、机器升级、脚本自动化。你会发现，13小时变成5小时不是奇迹，而是许多小优化叠加后的自然结果。

我自己的使用感受是，FPGA编译加速这件事，本质是一个工程管理的命题，而不是纯粹的软件调优命题。它考验的不是你会不会敲几条Tcl命令，而是你能不能看清整个迭代链路中每一环的时间消耗，并且愿意在“不紧急”的时候花时间去优化下一轮的等待时间。这需要一些耐心，但回报是实实在在的——每一次迭代时间缩短，都是整个团队一天的节奏变好。