企业官网建设流程全解析

每年大型技术会议开下来，我都会有一种“风向标被强制刷新”的感觉。这次GTC‘26我在会场里泡了整整三天，最大的冲击不是某个新架构刷了多少榜单，而是“端到端”这个词，彻底从一个概念热词变成了整个自动驾驶行业的默认语境。两年前大家还在争论端到端靠不靠谱、能不能量产，今年几乎所有展台和技术talk都在讨论另一个问题：端到端已经在路上了，但主线到底是什么——是模型结构，是数据流水线，还是安全兜底的工程体系？这篇文章不打算复述任何官方新闻稿，纯粹以一个算法工程师的视角，聊聊我在会场上看到的端到端时代自动驾驶的真正主线，以及我们自己项目里踩过的坑、趟过的路。

1. GTC两天的观感：端到端不再是口号，而是语境本身

1.1 会场里最明显的三个信号

先说这次GTC给我留下最深印象的三个信号，它们拼在一起，基本就是端到端时代自动驾驶的骨架。

第一个信号：架构选型的重心已经从“感知精度”转移到了“整体行为优化”。前两年逛展，听到的高频词是BEV、Occupancy、mAP、NDS，大家比的是谁感知得更“全”、更“准”。今年完全不同，几乎所有人都在聊“planning performance”“驾驶行为质量”“交互博弈”。这意味着行业已经从“把世界看明白”阶段，进入了“把车开好”阶段。感知不再是终极目标，而是服务于最终驾驶行为的一个内部环节。

第二个信号：世界模型（World Model）从一个学术奢侈品，变成了头部玩家口中的基础设施。会场上有好几场talk都在讲怎么用世界模型做场景生成、未来状态预测、闭环评测。这不是发论文式的前瞻讨论，而是带着大量工程细节的落地分享：怎么压缩潜空间、怎么控制场景编辑、怎么评估生成场景的真实性。很明显，世界模型的工程化速度比我预想的要快得多。

第三个信号：车端算力的路线图进一步清晰。新一代车载计算平台的AI算力规划明显在往更高量级走，大模型上车不再是一个“勉强能跑”的演示，而是被写进产品定义里的设计目标。配合车端内存带宽、算子库生态的升级，车端跑多模态Transformer加规划头，已经从“能不能”变成了“怎么跑得更快更省”。

这三个信号叠在一起，让我有一种很强烈的感觉：端到端不再是某个团队的炫技项目，它已经成了行业默认的演进方向。大家真正的分歧不在于“要不要做”，而在于“用什么路线做”。

1.2 展台上看的不是模型，是数据流水线

今年看展台，我有一个特别明显的感受：真正拉开差距的，不是单点模型的效果，而是数据流水线的成熟度。

几乎每一家做自动驾驶的公司，展台上都有一张“数据闭环”的图：采集车在路上跑，数据回传，云端挖掘难例，自动标注，训练模型，仿真验证，再通过影子模式收集新的corner case。图长得都差不多，环形箭头转得都很丝滑。但我在展台跟一线工程师聊下来，发现里面的工程细节差距巨大。

有的团队号称“数据闭环”，实际上还是人工在筛数据，每天回传几万条clips，标注团队加班加点标框，模型迭代周期以周为单位。有的团队已经把挖掘、标注、训练、评测全部自动化串起来，模型一天可以迭代好几个版本，关键指标自动看板，异常自动告警。这两种团队之间的战斗力差距，不是同一个数量级的。

所以我在会场里跟朋友感叹：端到端时代，自动驾驶的护城河正在从“算法创新”转向“数据工程的系统能力”。模型结构你可以抄，训练框架你可以用开源的，但一套高效运转的数据飞轮，是必须靠团队自己一砖一瓦搭起来的。

1.3 一个算法工程师在GTC怎么“逛”才有收获

很多人觉得参加这种大会就是听听keynote、看看展台、领点周边。我自己跑了几年，总结了一套比较有用的逛法。

主会场的发布会我反而不是很追，真正有价值的是那些workshop和技术talk。这些session里讲的内容往往更具体，会直接给一些训练细节、模型结构选型的对比实验、踩坑总结。这些才是能带回团队直接落地的东西。我看demo的时候也习惯问一个问题：“你们最难处理的场景是什么？”而不是“你们效果多好”。问前者，对方通常会聊出一些真实的边界问题；问后者，得到的往往是一个准备好的标准话术。

还有一个很重要的心得：跟一线工程师聊天，比看PPT有用十倍。PPT上都是成功案例，聊天里才有失败经验。今年我在某个展台前跟一位做仿真系统的老哥聊了二十多分钟，他分享的三个关于场景生成质量的坑，直接解释了我们团队最近遇到的类似问题。这种收获，是坐在keynote底下听两个小时都换不来的。

2. 端到端的技术路线演进：为什么是现在？

2.1 模块化架构的舒适区与天花板

要理解端到端为什么成了主线，得先回头看模块化架构为什么走到了瓶颈。

传统自动驾驶架构是典型的流水线：感知模块先识别障碍物、车道线，预测模块再估计其他交通参与者的未来轨迹，规划模块基于这些结果搜索一条安全轨迹，最后由控制模块执行。这种架构的优势非常明显：每个模块可以独立开发、调试、测试，出问题能快速定位到具体环节。在自动驾驶早期，这几乎是唯一可行的工程路线。

但这个架构的天花板也很清晰。最大的问题在于模块间的信息传递是有损的。感知模块输出的“完美”世界模型，不一定包含下游规划真正需要的全部信息。比如，感知模块可能给了你一个很精准的障碍物框，但规划模块真正需要的是这个障碍物的“行为意图”——它是想并线还是在犹豫？这种高层语义信息，很难用一个边界框完整表达。

另外，长尾场景的规则写不完。今天补一个“前方车辆压线”的处理逻辑，明天又冒出来一个“行人站在两车夹缝里”的情况。规则驱动的系统，本质上是在跟无穷无尽的长尾场景玩打地鼠游戏。

我用一个生活化的类比：模块化架构就像大公司里的跨部门协作，感知部、预测部、规划部各司其职，每个部门都觉得自己做得很好，但最终决策质量取决于部门之间的“交接文档”写得好不好。而端到端架构，更像一个“全栈负责人”——他从头到尾看一遍问题，自己做全局决策，避免了部门间信息损耗。

2.2 端到端架构的几种典型流派

这次GTC逛下来，我把目前主流的端到端路线归纳成三种流派，它们之间不是替代关系，更像是在不同量产约束下的不同解法。

第一种是直接监督式端到端，也叫模仿学习路线。传感器数据直接输入神经网络，输出轨迹甚至是控制量，训练数据来自人类驾驶员的示范。这种路线结构最简单，上限也很高，但问题在于它对数据质量和覆盖度的要求极其苛刻——模型本质上是在“模仿”训练数据里的驾驶行为，遇到没见过的场景容易一脸懵。

第二种是带中间表示的端到端，这是目前量产项目里最务实的一条路。模型内部仍然会生成一些可解释的中间表示，比如occupancy网格、目标级状态、语义地图等，但这些中间表示不再是手工设计的“最终产品”，而是作为规划任务的辅助监督信号存在。

第三种是世界模型驱动式端到端。模型不仅学习“如何驾驶”，还在内部学习“世界如何演化”。它可以在潜空间里预测未来几秒的场景状态，再基于预测结果规划当前动作。这种路线从原理上讲最优雅，但工程复杂度也最高，目前还处于从demo向量产爬坡的阶段。

三种流派的对比，我整理了一个简单的表：

从展台上的交流看，头部玩家们嘴上都在聊世界模型，但实际量产上车的，多数还是第二种路线的变体。这个“嘴上说一套、手里做另一套”的现象，恰恰反映了工程现实：端到端要落地，必须在“全局优化”和“可控可解释”之间找一个平衡点。

2.3 评价体系的重构：从指标好看，到行为可靠

模块化时代，我们评价一个系统，习惯看一堆感知指标：检测mAP多少、车道线准确性多少、占用网格IOU多少。这些指标有一个共同特点：它们衡量的都是“中间结果”，而不是“最终驾驶质量”。

端到端时代，评价体系发生了根本性转变。行业开始关心“这个系统到底会不会开车”——不是看它识别了多少障碍物，而是看它在真实交通里做出的行为是否安全、合理、舒适。这带来了一系列新的评价维度：驾驶相似度（模型驾驶行为与人类驾驶员的接近程度）、接管率（安全员介入的频率）、碰撞率（仿真环境下的碰撞统计）、舒适性指标（加速度变化率、横向冲击度）等。

这些指标从学术角度很好定义，但从工程角度非常难标准化。什么叫“像人一样开车”？不同司机风格差异极大。什么叫“舒适”？有人喜欢激进一点，有人喜欢稳一点。我目前看到比较务实的方式是：用统计分布替代单点值，用多维度加权综合评分，并且在测试场景上做分层——常规场景看舒适，拥堵场景看博弈能力，极端场景看安全兜底。这套评价体系还在快速演进中，远没到收敛的时候。

3. 数据、仿真与算力：端到端时代真正的主线之争

3.1 数据闭环：决定模型能力的隐形天花板

逛完GTC，我最想说的一句话是：端到端模型的性能天花板，很大程度上由数据闭环决定，而不是由网络结构决定。

数据闭环的起点是采集和回传。量产车队每天在路上跑，会产生海量的传感器数据，但不可能全部传回云端，成本太高。所以第一步要做一个“筛选器”——在车上或云端做粗筛，只回传那些“有价值”的数据：路线复杂度高的、天气恶劣的、出现过近距交互的。

回传之后，核心工作变成难例挖掘。这是数据闭环里最吃功夫的环节。我们总不能把几百万clips全部送去人工标注，得有一套自动判断“这个场景对当前模型是否有挑战”的机制。常见的做法是用当前版本的模型跑一遍回传数据，找那些模型预测结果和人类驾驶行为差异大的片段，或者是模型自身的置信度很低、但实际没有发生事故的片段。这些片段就是下一轮训练最有价值的“错题本”。

然后是标注环节。端到端模型最贵的标注不是画框，而是给“行为”做标注。比如一个场景里，人类的驾驶决策是什么？为什么要在这个时间点变道而不是下一个？这类标注的自动化程度直接影响数据效率。

最后是影子模式。模型在量产车上实时运行，但不直接控制车辆，它的输出和人类驾驶员的操作被对比记录。一旦发现模型输出和行为有显著偏离，这段数据就被打上标记回传。这相当于让千万个免费司机帮我们测试模型，是数据飞轮里最精妙的一环。

数据飞轮的核心逻辑很简单：数据越多 → 难例越多 → 模型越强 → 覆盖场景越广 → 能收集到的数据质量越高。但工程细节极其复杂，每一步的效率差一点，整个轮子的转速就会差很多。

3.2 世界模型与生成式仿真：把长尾问题在虚拟世界先暴露

长尾场景是自动驾驶永远的痛点。一个极端场景可能一年也遇不到几次，但你不可能等到真实道路上去撞见它再修模型。这就是仿真和世界模型的价值所在。

世界模型在自动驾驶里的用途，目前看有三个层次。

第一个层次是场景生成器。我给一个基础场景的种子，世界模型自动演化出合理的、多样的交通流——旁边的车什么时候变道、行人什么时候过马路、前面那辆车什么时候刹车，这些交互动态都能被模型生成。生成的关键是“合理”，不能让车突然鬼畜。这个用途已经比较成熟了。

第二个层次是未来状态预测器。模型看完过去几秒的传感器数据，在潜空间里“想象”出未来几秒的世界状态。规划模块基于这些“想象”来决策。这就是世界模型最优雅的地方，模型不再只学“怎么开车”，还在学“这个世界是怎么运转的”。

第三个层次是闭环评测环境。传统仿真里，测试场景是人工预设的脚本，车在场景里跑一圈，记录指标。世界模型则可以把真实采集的场景作为初始条件，然后在虚拟世界里继续演化，生成没有上限的、多样化的测试交通流。这样我们可以在仿真里跑出几百万公里的虚拟里程，提前暴露实际道路上的长尾问题。

另外一个值得一提的方向是生成式仿真。用神经渲染技术重建真实路口的场景，然后往里插入虚拟障碍物、修改天气和光照，生成大量“看起来完全真实”的新场景。这种方案的好处是场景的几何和语义保真度极高，模型在这种虚拟环境下训练，行为和真实世界的迁移度会好很多。

我个人的判断是，世界模型和生成式仿真，是端到端时代数据问题的另一条腿。真实数据的采集受限于车队规模和地理范围，而虚拟数据可以无限生成。未来的算法团队，一半的精力在挖真实数据，另一半的精力会在造虚拟数据。

3.3 算力账单：训练端到端模型到底要多大的盘子

端到端模型不是免费的午餐，它对算力的需求是惊人的。我在会上跟几个朋友算了笔账，最后大家得出一个共识：端到端的军备竞赛，一半拼模型结构，一半拼算力基建。

先说训练侧。假设一个量产团队的场景库已经积累到了百万clip级别，每个clip按10秒、8路摄像头、10Hz采样来算，一个clip就是800张图像。百万clip的原始数据量就是8亿帧图像。这还没算上增广和重采样。模型端如果是多模态Transformer加规划头，参数量轻松上亿甚至到十亿级。在这种规模下，单卡训练一个epoch的时间是不可接受的。实际训练几乎必然要上大规模训练集群，配合数据并行、模型并行、混合精度等各种策略。一次全量训练跑下来，算力账单是几百万量级的成本，这还不算挖数据、重放数据、反复调loss的版本迭代。所以你现在去看头部玩家的算力储备，那已经是超大规模集群的配置了，这不是炫富，是被数据逼出来的。

再说车端推理。端到端模型上车，面临几个硬约束。第一个是实时性——从传感器数据进来到轨迹输出，整个推理链路通常要求在几十毫秒内完成，否则控制跟不上。第二个是功耗和散热——车规级计算平台的功耗预算是有限的，你不能在上面跑一个和云端一样大的模型。第三个是内存带宽——多路相机的数据吞吐非常大，模型结构设计必须兼顾访存效率。

所以车端部署一般要做三件事：模型结构选型（选一个实时性和精度均衡的backbone）、知识蒸馏（用一个在云端训练的大模型“教”一个车端小模型）、量化压缩（从FP32降到INT8，但要注意量化对敏感算子的影响）。

这块我多说一句：很多人以为车端部署就是把云端模型“压缩一下”,其实远没那么简单。车端模型是带着“先天限制”设计的——从一开始就要考虑算力预算、延迟预算、内存带宽。模型结构设计、蒸馏方案、量化策略这三者必须一起做，才能得到一个既快又准的车端端到端模型。

4. 从Demo到量产：算法工程师心里那道坎

4.1 可解释性：不是要不要，而是怎么分层

端到端模型被诟病最多的一点就是“黑盒”——神经网络内部发生了什么，没人说得清。这个问题在量产场景里不是学术洁癖，而是实打实的工程需求：出事故了，得能排查原因；过审核，得能证明系统是安全的。

但从工程实践看，量产端到端系统并不是一个纯粹的“黑盒”，而是分层的。设计得当的端到端系统，会在网络内部保留一些可解释的中间输出——比如occupancy状态、目标级轨迹预测、风险场图等。这些中间输出既可以作为规划模块的辅助信号，更重要的，它们是给安全团队和排查人员看的“监控探针”。

如果网路内部发生了异常，我们可以通过这些中间输出来定位问题：是感知环节对某个障碍物漏检了？还是预测环节对旁边车辆的意图判断错了？还是规划环节在某个约束条件下生成了激进轨迹？这个“分层可解释”的设计，是端到端系统能拿到量产门票的关键前提之一。

我在实际项目中体会很深的一点是：中间表示的设计，是你给系统装的一扇“观察窗”。窗口装得好不好，直接决定了出了问题你是“两眼一抹黑”还是“按图索骥”。所以设计端到端架构时，千万不要觉得“反正都是黑盒，随便搞个隐向量就行”——一定要在关键位置留下可解释的语义输出，别等出了问题才后悔。

4.2 安全兜底：主模型之外的冗余设计

端到端模型的输出是一个概率分布，它天生就不具备“绝对可靠”的属性。所以在真正的量产系统里，端到端主模型只是整个安全体系的一部分，而不是全部。

我理解的安全架构是一个“多层防线”结构。最外层是端到端主模型，它负责绝大部分驾驶场景。第二层是一个规则化的安全监控层，实时检查主模型的输出是否触碰安全边界——比如是否跟前方障碍物距离过近、是否超出了可行驶区域、是否检测到了模型自身的不确定状态。一旦触发边界，系统就进入最小风险策略（MSS），自动执行减速、靠边停车等保守动作。第三层是驾驶员监控，确保随时有人能接管。

这个设计思路我经常用一个类比来解释：端到端模型像一个实习司机，深度学习给了它处理复杂场景的“肌肉记忆”，但旁边必须坐一个真正的教练员。教练员不会干涉你的正常驾驶，但只要你操作越界，他立刻踩刹车或者抢方向盘。关键在于，教练员的介入逻辑要极其严格且保守——宁可误判多介入，也不能漏判。

这里有一个经常被忽略的工程点：监控层和主模型的接口设计。监控层需要的信息，跟主模型的内部表示不一定完全对齐。如果监控层用的是独立的感知信号，那就存在两套感知系统之间的时间同步和空间对齐问题，这个接口的鲁棒性必须花大力气打磨。

4.3 测试评价：如何证明端到端系统“足够好”

这是端到端时代最难回答的一个问题，也是我在GTC展台上被问到最多、最没法一句话说清的问题：你凭什么证明这个系统是安全的？

传统模块化架构的验证相对简单：感知模块有标注数据集可以测精度，规划模块有场景库可以测决策质量。但端到端系统是一个整体，它跨越了感知到控制的整个链路，验证方式必须升级。

目前的行业实践，基本是三种测试方式的组合。第一种是离线路测数据回放：把采集到的真实场景数据喂给模型，比较模型输出和人类驾驶行为，得到驾驶相似度、安全问题数等指标。这种方式的优点是快速、低成本、可复现，缺点是不能完全反映交互效应——模型是在“看录像”而不是“真的在路上开”。第二种是闭环仿真测试：让模型在虚拟环境里真实地开车，周围交通参与者也会对模型的行为做出反应。这种方式能测出交互能力和长尾场景处理能力，但存在仿真与真实世界的迁移差距。第三种是开放道路实测：在有安全员的条件下让系统真实驾驶，积累接管率和安全问题统计。这是最终的验证手段，但成本高、周期长。

这些测试方式背后，还有一个更深层的问题：显著性不够。接管率这类指标要想达到统计学上的置信度，需要跑几百万公里的实测。我们自己算过一笔账：100辆车每天跑8小时，平均时速30公里，一天就是2.4万公里，跑一个月大概72万公里。要积累到“数千万公里无致命事故”级别的统计置信度，光靠路测是遥遥无期的。这也是为什么整个行业如此依赖仿真和世界模型——虚拟环境里可以无成本地跑几千万公里，关键是让虚拟测试环境和真实世界的分布足够接近。

SOTIF（预期功能安全，ISO 21448国际标准）的方法论在端到端时代价值很大，它的核心思想是把安全问题当作“已知不安全场景”和“未知不安全场景”的组合来处理。对已知场景，用仿真和路测来验证系统“不会做错”；对未知场景，用数据挖掘和生成式仿真来“尽量多地发现”。这个思路，是目前端到端验证体系最实用的指导框架。

5. 几个技术细节：亲手拆一个端到端pipeline的实操经验

5.1 数据管线里最容易被低估的坑

端到端项目的成败，很多时候在数据管线阶段就已经决定了，而且这里藏着大量“不看不知道、一看吓一跳”的坑。

第一个坑是时间戳对齐。多路相机、惯导、毫米波雷达各自的时钟源不一样，如果时间同步做不好，模型输入端的数据就是“错位”的。比如右摄像头看到的是10毫秒前的画面，左摄像头看到的是5毫秒后的画面，在低速场景下可能无所谓，但在高速变道场景里，几厘米到十几厘米的空间误差就出来了。这个误差会让端到端模型学到一些奇怪的偏置。

第二个坑是传感器标定漂移。车辆长期运营，相机外参是会慢慢漂移的。如果标定参数没有及时更新，模型输入的BEV特征和真实世界之间的对应关系就会逐渐错位。上过量的车越多，这个漂移问题越严重。量产端到端系统的背后，必须有一套自动标定和健康监测机制，否则模型性能会随着车队里程的增加而悄悄劣化。

第三个坑是训练/评测数据泄漏（data leakage）。这个坑我反复踩过。最典型的情况是：训练集和验证集来自同一条路线的相邻时段，模型几乎等于做过“开卷考试”，验证指标虚高得离谱。后面我们强制要求按“路段分组”来做数据切分——同一条路的白天、黑夜、雨天数据必须进同一组，绝不允许跨组分到训练集和验证集。这么一改，验证指标的含金量马上就不同了。

第四个坑是场景重复度过高。你想覆盖长尾，但真实数据天然呈长尾分布——90%的数据都是直路跟车、红绿灯起步这种平凡场景。如果不做难例挖掘直接训练，模型会被平凡场景淹没，对角落里真正重要的corner case反而视而不见。所以训练数据的采样策略和难例挖掘同等重要。

5.2 训练与评估的实操细节

说完了数据坑，再聊训练环节的几个实操细节。

端到端模型的训练，我建议走两阶段法。第一阶段先把可解释中间表示（比如occupancy和轨迹预测头）在标注数据上预训练好，第二阶段再把整个网络联合起来做端到端微调。这样做的原因有两个：一是中间表示如果一开始就是乱的，下游规划头很难学到有效信息；二是分阶段训练能让训练过程更稳定，loss曲线不会一开始就发散。

Loss的设计是个调和功夫。我常用的组合是：模仿损失（模型输出与人类轨迹的差异）+ 碰撞损失（模型输出轨迹与障碍物发生重叠的程度）+ 舒适性损失（加速度、曲率的突变程度）+ 约束损失（可行驶区域边界、交规约束）。这几个loss项要加权重配比，权重不是保险起见的学问，而是对驾驶哲学的刻画——你想要一个激进但少接管的系统，还是一个保守但略显笨拙的系统，权重配比完全不同。

评估环节，我自己的流程是“三连”：离线路测回放看一致性，闭环仿真看安全性，真实路测看接管率。三个维度缺一不可。离线路测能快速反馈迭代，但容易高估模型能力；闭环仿真更接近真实交互，但仿真环境本身可能有偏置；真实路测最可信，但反馈周期长、成本高。三者的迭代节奏要错开：每天跑离线路测，每周跑闭环仿真，每月做真实路测复盘。

5.3 车端部署的硬件问题

最后聊聊上车这件事。端到端模型在车端部署时，我遇到最多的三类问题：显存天花板、延迟达标难、量化精度损失。

显存天花板主要来自多路相机的输入处理。8路摄像头如果都按原始分辨率输进backbone，显存瞬间爆掉。工程上常用的手段是降低输入分辨率、控制时序帧数、用在线方式做多帧融合而不是把十几帧一次性塞进去。这些都是模型结构层面就要做的决策——不是在部署时才想办法，而是在设计阶段就必须对算力和显存有数。

延迟达标难主要卡在Transformer结构的自注意力计算上。自注意力的计算复杂度是序列长度的平方，输入token数一多，延迟就上来了。车端的常见解法包括：限制注意力机制的空间范围（局部注意力）、用更高效的算子实现（FlashAttention等技术的车端适配是另一个话题）、把模型中的某些模块替换成延迟更低的变体。这个优化过程和云端有很大差异，因为车端没有那么多算力可以挥霍。

量化精度损失，尤其是INT8量化，对端到端模型的伤害比模块化时代更明显——因为误差会在多层网络之间累积传播，最终影响到规划的稳定性。我的建议是：量化感知训练（QAT）优先于训练后量化（PTQ），虽然训练成本高一些，但对端到端这种长链路模型的精度保持有显著优势。

上车的部署问题，本质上是对模型设计的约束回溯。如果你等到模型训练完才思考“怎么让它跑在车规级芯片上”，那大概率要返工。正确的方式是，在做模型结构选型的第一天，就把车端算力预算、延迟预算、显存预算三个数字列在纸上，让模型设计在这些约束下进行。

这几年的实际项目做下来，我体会最深的一点是：端到端时代，算法工程师的能力模型也在重构——你不再只是那个“刷精度”的模型调参选手，而是得同时懂数据流水线、会设计评测体系、理解车规级硬件的“系统工程师”。如果你正准备转向这个方向，我最大的建议是：把“端到端模型”当一个系统看待，而不是当一个网络结构看待。模型只是这个系统里的一环，它的上下游——数据怎么来、怎么训、怎么评测、怎么兜底——才真正决定了这个系统能不能上路。另一个小技巧分享给大家：每次项目复盘的时候，多问问自己“如果数据流在这里断掉，问题会以什么形式出现？”这个思路帮我提前规避过至少两位数的事故和上线延期。