PayPal DE 面经 2026：SQL、Pipeline 和 Fraud Data

💡 核心要点 (Key Takeaways)

• PayPal DE 面试主轴是 SQL（fraud / 对账口径、金额精度、多币种时区）+ 数据工程 Coding（事件流去重、窗口聚合、对账匹配）+ Pipeline / Data Platform System Design（fraud data platform、transaction reconciliation、streaming + batch 双链路）+ BQ（PayPal Way values + 量化影响）；Fraud Data 是 PayPal DE 的招牌领域——支付业务的数据天然绑着风控（fraud）和清结算（reconciliation），SQL、coding、SD 题面几乎都落在这个语境里。
• 流程主线是 Recruiter Screen → OA / Online Assessment（部分岗位，HackerRank 限时 coding，NG / Intern 更多）→ Phone Screen（1 道 SQL + 1 道 coding）→ Onsite / VO 4 轮（1 SQL + 1 数据工程 Coding + 1 System Design + 1 BQ，每轮 45-60 分钟，部分团队排 5 轮）→ HM → Team Match；Risk & Fraud Data、Data Platform、Analytics Engineering 团队方向差异大，轮次结构以实际收到的邀请为准。
• SQL 轮第一考点是口径不是语法：先定义什么算 fraud confirmed（reported vs confirmed）、对账匹配键（transaction id + 金额 + 时间窗）、时间窗和时区 / business day 口径、金额用整数分而不是浮点，再 CTE 分层写（先 dedup、再 join、再 aggregate），最后主动讲验证方式（行数变化、NULL 占比、重复率、discrepancy 抽样）。
• SD 高频方向全是支付数据核心链路：fraud data platform（transaction event ingestion、实时 feature pipeline、offline 训练数据、training / serving skew）、transaction reconciliation pipeline（batch + streaming 双链路、backfill、discrepancy 处理流程）、数据仓库建模（事实表 / 维表、SCD、分区与 query cost）；数据质量监控（schema check、volume anomaly、null ratio）和 cost / 失败路径是必答项。
• PayPal DE 公开面经信号量偏小（少于 SWE，更少于四大 DE），按「年份 + 级别 + 团队方向」筛选、以 2-3 篇共识判断轮次结构；7 天保 SQL + BQ 下限，14 天补 Pipeline / Fraud Data SD 和 mock，30 天加深对账 / 风控数据背景和 follow-up 链。

这篇适合谁

这篇写给准备 PayPal Data Engineer（DE）面试的候选人，覆盖 Data Platform、Analytics Engineering 以及 Risk & Fraud 背后的数据方向，级别以社招中高级为主（大致对标 Google L4-L5 / Meta E4-E5，PayPal 内部有自己的级别体系，以 JD 和实际沟通为准），NG / Intern 的结构差异会在流程一节单独说明。文章基于 2026 年公开面经信号和 PayPal 公开的业务、产品与 Culture 材料整理，各团队、级别、地区的轮次结构会有出入，以实际收到的邀请为准。

一句话定位：PayPal DE = SQL（fraud / payment 指标口径、对账逻辑、金额精度）+ 数据工程 Coding（事件流去重、窗口聚合、对账匹配）+ Pipeline / Data Platform System Design（fraud data platform、transaction reconciliation pipeline、streaming + batch 双链路）+ BQ（PayPal Way values + 量化影响）。和大多数公司的 DE 最大的不同：支付业务的数据天然绑着风控（fraud）和清结算（reconciliation），SQL 题、coding 题、SD 题的题面几乎都落在「transaction event + fraud + reconciliation」这个语境里，「口径、对账、精度」三个词几乎每轮都会出现。PayPal 其他岗位的题型重心区分见 PayPal SWE 面经 2026；公司级全景（覆盖 SWE / MLE / DS / DE）见 PayPal 公司页，本篇只展开 DE 岗位的全流程。

• 适合准备 PayPal DE 社招中高级面试的候选人（大致对标 Google L4-L5 / Meta E4-E5，以 JD 为准），NG / Intern 的结构差异单独说明
• 主轴：SQL（fraud / 对账口径、金额精度）+ 数据工程 Coding + Pipeline / Data Platform System Design + PayPal Way BQ
• Fraud Data 是招牌领域：题面几乎都在 transaction event + fraud + reconciliation 语境里
• 投 DE 岗位就按 DE 准备：SQL 讲口径、pipeline 讲失败路径、SD 讲对账和成本，和 SWE / DS 的重心完全不同

面试流程：OA / Phone / VO / HM / Team Match 各轮是什么

PayPal DE 的主线流程是：投递 / 内推 → Recruiter Screen → OA / Online Assessment（部分岗位，NG / Intern 更多）→ Phone Screen → Onsite / VO（4 轮）→ HM → Team Match → offer。公开信号里有两个特点要提前知道：PayPal 没有全员统一 OA（部分社招岗位和 NG / Intern 会收到 HackerRank 式限时 coding）；onsite loop 多为 4 轮 × 45-60 分钟，DE 的常见结构是 1 SQL + 1 数据工程 Coding + 1 System Design（Pipeline / Data Platform，中高级必考）+ 1 BQ，部分团队会排 5 轮（多加 1 轮 coding）。各轮大致长这样：

• Recruiter Screen（30-45 分钟）：不考技术，聊动机、背景、级别期望和方向。DE 岗位这轮常被问「你端到端负责过什么数据链路」，要能一句话说清规模（数据量、事件量、SLA、下游消费方）和个人贡献，「做过数仓项目」这种颗粒度不够。同时会初步确认「为什么 PayPal、为什么支付行业」，这轮的答案会传到后面轮次。
• OA / Online Assessment（部分岗位，NG / Intern 更多，限时）：公开信号里多为 HackerRank 式限时 coding（1-3 道 medium，几小时作答窗口），考经典 DSA 和数据处理；个别团队有 take-home。NG / Intern 出现 OA 的比例更高。以实际收到的邀请为准。
• Phone Screen（45-60 分钟）：常见结构是 1 道 medium SQL（fraud / 对账口径、window function、金额精度是高频方向）+ 1 道 Python coding 或简历深挖穿插，部分团队是 1 coding + 1 SQL。考察的是无提示下能否先讲清 metric 口径、完成第一版并把复杂度讲清楚，follow-up 常见「数据量 10 倍怎么优化」「事件乱序 / 重复时口径怎么保证」这类约束变化。
• Onsite / VO（4 轮，每轮 45-60 分钟，通常一天面完；部分团队 5 轮）：常见结构是 1 轮 SQL（fraud / chargeback 指标口径 + 对账匹配 + 复杂 join）+ 1 轮数据工程 Coding（事件流去重、窗口聚合、对账匹配算法）+ 1 轮 System Design（Pipeline / Data Platform，高频方向是 fraud data platform 和 transaction reconciliation pipeline）+ 1 轮 BQ（PayPal Way values + 项目深挖）。语言通常以 Python / SQL 为主，跟目标团队走。
• HM（Hiring Manager Call）：VO 通过后，与 hiring manager 聊方向、level 和 comp，确认双向意向，不再考技术。
• Team Match：PayPal 数据方向里 Data Platform、Analytics Engineering、Risk & Fraud Data 团队分布广，匹配阶段会根据团队需求把你放进具体 team。这一轮重点是双向确认方向，聊之前值得了解目标团队的数据场景（比如是做 fraud feature pipeline 还是做 settlement 数据链路），能主动说出「我希望进做 XX 方向的团队」是加分项。PayPal 出结果通常 4-8 周，日程上留好余量。

题型雷达：SQL、Coding、System Design、ML Design、BQ 各占多少

按 DE 岗位把题型按出现频率排个雷达图，SQL 和 System Design（Pipeline / Data Platform）是两根主轴，Fraud Data 场景贯穿所有题型：

• SQL（最高频，phone 1 轮 + onsite 1 轮）：高频方向都是支付数据口径题——fraud / chargeback 指标（fraud rate、chargeback rate、误报率，口径要区分 reported vs confirmed）、transaction 对账查询（双流水匹配、discrepancy 分类）、金额聚合（整数分、多币种 FX、时区 / business day）。考点是「先口径、再查询、后验证」三步闭环：先定义事实表、维表、匹配键、时间窗和指标口径，再 CTE 分层写（先 dedup、再 join、再 aggregate），最后主动讲验证方式（行数变化、NULL 占比、重复率、discrepancy 抽样）。通用 SQL 练法可以看 DE SQL 与 Pipeline 准备，这里重点说 PayPal 场景怎么落。
• 数据工程 Coding（1 轮，Python 为主）：事件处理是主风格——streaming 事件去重与幂等写入（dedup key 设计、状态 TTL、at-least-once 消费）、事件窗口聚合（按维度算 fraud rate、迟到事件容忍窗口）、对账匹配算法（双流水匹配、discrepancy 输出）、经典 medium（sliding window、top-k、hash 聚合）。考点是第一版 medium，但 follow-up 会持续加约束——数据量 10 倍、流式输入、乱序 / 重复、金额精度——考的是你能不能把简单实现扩展成生产答案。
• System Design / Data Platform Design（最高区分度，1 轮，中高级必考）：高频方向是公司自己的数据场景——fraud data platform（transaction event ingestion、实时 feature pipeline、offline 训练数据、training / serving skew、数据质量）、transaction reconciliation pipeline（batch + streaming 双链路、backfill、discrepancy 处理流程、freshness SLA）、数据仓库 / lakehouse 建模（payment 事实表 / 维表、SCD、schema evolution、分区与 query cost）。考点是 source → ingestion → storage → transform → quality → serving → observability 的完整闭环，数据质量监控和 cost / 失败路径是必答项。标准回答结构可以看 DE Pipeline Design 公司题型地图，这里重点说 PayPal 场景怎么落。
• ML Design（低频，非主轴）：DE 岗位一般没有独立 ML Design 轮；投 Risk & Fraud 数据方向的候选人可能被带一道轻 ML 数据题（feature pipeline、训练数据质量、training / serving 一致性、offline / online 评估数据），但主轴仍是数据工程，和 MLE 岗位的准备不重合。
• BQ（1 轮 + 穿插每轮）：围绕 PayPal Way values（公开渠道常见表述是 We're all in on it / We do what's right / We're bold and ambitious / We're a global team / We win by thinking big，以官网最新为准）+ STAR + 量化影响。高频方向是跨团队推动、主动暴露坏消息（数据链路事故）、资源不足时自己找路、为什么 PayPal。准备 5-8 个 STAR 故事，每个有 measurable impact 且能接两层追问。
• OA（如果收到）：HackerRank 式限时 coding，1-3 道 medium DSA / 数据处理，考的是限时完成度和边界处理，不是深度；收到后按「先做完全部主解、再回来补边界和 follow-up」的顺序做。

高频题目：8 个代表题型和考点

以下是 2026 年公开面经信号里反复出现的题「类型」，只归纳题型和考点，不复刻任何人的具体原题：

• SQL：fraud / chargeback 指标（最高频）：给定 transaction 表和 fraud 标记表，按支付渠道 / 地区 / 时间计算 fraud rate 和 chargeback rate 趋势，定位异常渠道。考点：口径定义（fraud reported vs fraud confirmed、chargeback 的时点归属）、时间窗口、渠道维度、window function；follow-up 常追「口径从 reported 换成 confirmed 怎么改」，能现场重推口径是及格线。
• SQL：reconciliation 对账查询（高频）：给定我方账本流水和通道方（acquirer / card network）流水，做匹配并输出 discrepancy（金额不一致 / 状态不一致 / 单边缺失）。考点：匹配键设计（transaction id + 金额 + 时间窗）、状态映射、dedup、时区处理、discrepancy 分类输出；follow-up 追「日千万级流水怎么分批对、匹配键冲突怎么办」。
• SQL：transaction 聚合与金额精度（高频）：按商户 / 币种 / business day 聚合交易量与交易额，处理多币种和时区。考点：金额用整数分而不是浮点（避免精度误差）、多币种是否按 FX 折算、business day 的时区口径（商户当地 vs 结算方）、window function 做滚动聚合。
• Coding：streaming 事件去重与幂等写入（高频）：transaction event ingestion 去重，at-least-once 投递下的幂等消费。考点：dedup key 设计（event id vs 业务键）、顺序保证、状态 TTL、backpressure；follow-up「consumer 积压 10 倍怎么降级」「去重状态怎么持久化」。
• Coding：reconciliation 匹配算法（高频）：双流水匹配，找出匹配项和 discrepancy，处理乱序和重复。考点：匹配键与状态机设计、discrepancy 分类输出、复杂度论证（千万级流水的内存 / 时间）、两指针 vs hash 的选型；follow-up 固定追「金额不一致但同一笔（partial capture / refund）怎么归类」。
• System Design：fraud data platform（SD 最高频）：设计 fraud 数据平台：transaction event ingestion、实时 feature pipeline（风控打分特征）、offline 训练数据链路、feature store、数据质量监控。考点：实时链路与离线链路的口径一致性（training / serving skew 是必答项）、feature 延迟预算、数据质量（schema check、volume anomaly、null ratio、label 延迟）、模型迭代怎么评估（offline 与 online 指标分开看）；只罗列 Kafka + Spark + feature store 组件不讲失败路径是典型低分答法。
• System Design：transaction reconciliation pipeline（SD 高频）：设计交易对账数据链路：batch + streaming 双链路、增量对账、backfill、discrepancy 处理流程、freshness SLA。考点：双链路口径一致性（同一口径两种实现）、backfill 与实时数据冲突怎么收敛、discrepancy 的分类与下游（人工 review / 自动补偿）、数据质量监控和告警、cost（双链路冗余的计算成本）；这是最能区分「有没有真跑过支付数据链路」的题。
• System Design：payment 数据仓库 / lakehouse 建模（SD 中高频）：为 transaction × merchant × channel 规模设计数据模型：raw / staging / mart 分层、事实表 / 维表设计、SCD 处理、schema evolution、分区与 query cost。考点：指标版本化与 owner、成本控制（分区裁剪、冷热分层）、下游 BI / 风控消费的口径稳定性；追问常落在「上游 schema 变更怎么不炸下游」和「历史口径变更怎么做 backfill」。

公开面经信号怎么读

一亩三分地、Blind、LeetCode Discuss、Glassdoor 是 PayPal DE 面试信息最集中的公开来源。PayPal DE 的公开信号量偏小——明显少于 PayPal SWE，也少于四大公司的 DE——所以读法比内容更重要。几个原则：

按「年份 + 级别 + 团队方向」筛选。2026 年 Risk & Fraud Data 团队的信号和 2024 年 Data Platform 团队的信号可能完全不一样（语言、有没有 OA、SD 深度都在变），只看最近 2-3 篇。团队方向必须对得上——Data Platform 的信号（数仓建模、backfill）对风控数据岗位（实时 feature、training / serving 一致性）参考价值有限，反过来也一样，混着看会准备错方向。

找共识，不信个例。单篇面经说「VO 是 5 轮、还有一轮 take-home」不能当结论；两到三篇独立帖子都提到「4 轮、1 SQL + 1 coding + 1 SD + 1 BQ」「OA 只出现在部分岗位和 NG」，这个结构才可信。面经作者有幸存者偏差（过的人爱写，挂的人少写），整体难度感知会偏乐观。

提取「轮次结构 + 题型方向 + 挂点」，忽略剧情。每篇面经真正有用的信息密度就这三样：每轮考什么类型、面试官追问到什么深度、作者觉得自己过 / 挂在哪。故事细节、情绪、对面试官的评价都不需要带进你的准备里。

不搬运、不暗示合作。本站所有 PayPal DE 面经内容都只归纳公开信号，不复制任何候选人的逐字面经，也不代表与任何面经社区有合作或转载关系。你读到的公开帖子请以原作者发布的内容为准。

常见挂点：PayPal DE 独有的失分方式

把公开面经里的挂因和模拟面试复盘对照，PayPal DE 特有的失分点集中在这几个：

• SQL 口径不严谨：不先澄清 metric 口径就写查询（什么算 fraud confirmed、reported 和 confirmed 的区别、chargeback 归属哪个时点、时间窗口、时区、要不要过滤测试数据），被追问才发现口径对不上。口径是 PayPal DE SQL 轮的第一考点，query 只是第二步；「先口径、再查询、后验证」三步里缺一步都是减分项。
• 金额精度和时区处理缺失：金额用浮点、多币种不做 FX 折算说明、business day 不定义时区——支付数据的 edge case 比通用分析多一层，这是 PayPal 数据面试官明显在听的地方，不主动处理会被直接追问失分。
• Pipeline design 只罗列组件：fraud data platform 或 reconciliation pipeline 题把 Kafka、Spark、feature store 摆一遍，但讲不出失败路径——迟到事件、backfill 冲突、schema drift、质量报警、label 延迟。PayPal 的数据平台面试官会沿着失败路径追问，越能把失败说清楚，越像真正 owner 过生产链路的人。
• 漏掉对账闭环：数据链路只讲到「写入数仓」，不讲 reconciliation / discrepancy 处理 / backfill 怎么保证最终一致。公开信号里「对不上账怎么处理」「discrepancy 下游给谁」是 PayPal 数据面试官的高频追问，漏了等于没理解支付业务。
• 数据质量监控缺失：pipeline 里没有 schema check、volume anomaly、null ratio、referential integrity 这一层，或者只字不提 freshness SLA。支付数据的质量问题直接影响风控和财务，质量监控不是附加项。
• fraud 场景讲不出训练 / serving 一致性：fraud data platform 题只讲 batch 链路，讲不清实时 feature 和 offline 训练数据怎么保证同口径（training / serving skew）、label 延迟怎么处理。风控数据岗的面试官会把这一层当成「有没有真做过」的分水岭。
• 规模与 cost 含糊：深挖问数据量、事件量、SLA、成本时含糊带过，pipeline 题里不主动带规模数字和 cost 结构（双链路冗余、backfill 资源隔离、query cost），等于没说。
• BQ 故事空泛、「为什么 PayPal」不落地：故事没有具体事件、没有 measurable impact，或者「为什么 PayPal」答成「大公司、福利好」。PayPal 的口味是「具体 + 量化 + 对支付业务的真实理解」，数据岗最好能说出一个你观察到的支付 / 风控数据细节。

准备路线：7 天 / 14 天 / 30 天

按你距 VO 的天数选路线。三个版本的共同原则：SQL 口径和 pipeline 失败路径永远优先，对账闭环和金额精度是 PayPal 特色项，BQ 故事保下限，最后两天只留 mock 和状态调整，不学新东西。

• 7 天（保下限版）：D1 SQL：限时做 1 道 fraud / chargeback 指标题，强制「讲口径 → 写查询 → 验证结果」节奏，做完主动讲「reported 换 confirmed、多币种、时区」三个口径变化；D2 SQL：1 道 reconciliation 对账题（匹配键、discrepancy 分类）+ 1 道金额聚合题（整数分、FX、business day），练到假设 → 口径 → 实现 → 验证的节奏稳定；D3 System Design：白纸上完整讲一遍 fraud data platform（source → ingestion → 实时 feature → offline 训练数据 → quality → serving → observability，含 training / serving skew 和数据质量），录音回听；D4 数据工程 Coding：streaming 去重 + 对账匹配各 1 道，强制先讲 dedup key / 匹配键设计再动手；D5 BQ：按「跨团队推动、数据链路事故、资源不足自己找路、为什么 PayPal」各写 1 个 STAR 故事，口述录音回听；D6 完整 mock 1 场（SQL 1 轮 + 10 分钟 BQ，含两级 follow-up），录音复盘；D7 缓冲日，检查设备日程，早睡。
• 14 天（标准版）：在 7 天基础上——D8-D9 System Design：各做 1 道 transaction reconciliation pipeline 和 payment 数仓建模题，每道练到 50 分钟讲完，强制讲清双链路口径一致性、backfill 冲突收敛、discrepancy 下游和 cost；D10 数据工程 Coding 加深：重做 D4 两题，这次第一版就给出生产扩展方案（状态持久化、分布式去重、分批对账）；D11 重做 D1-D2 的 SQL 题，这次强制第一版就带验证方案（行数、NULL 占比、重复率、discrepancy 抽样）；D12 项目深挖：resume 上 2 个主项目各写三层答案（概述 2 分钟 → 规模与取舍 5 分钟 → 反思与结果 3 分钟），规模数字（数据量、事件量、SLA、cost）做速查表；D13-D14 BQ 故事库扩到 6-8 个，按 PayPal Way values 重新归类，英文口述各过一遍；D15 缓冲日。
• 30 天（系统版）：在 14 天基础上——D16-D19 支付 / 风控数据背景补课：reconciliation 模式（批次对、实时对、discrepancy 分类与补偿）、chargeback / settlement 流程基本边界、FX 与多币种处理、data quality 工程（schema check、volume anomaly、lineage）、feature pipeline 与 training / serving skew，每个概念能讲 2 分钟并能落到 SQL / SD 题里；D20-D22 专项 follow-up：给每道 SQL 题补口径变化追问（reported→confirmed、多币种、时区、乱序），给每道 SD 题补「backfill 冲突怎么收敛、对不上账怎么发现」两个必问题；D23-D26 连续 2-3 场完整 mock（找真人或录音），重点看 follow-up 接没接住、口径有没有先讲、对账 / 质量 / cost 有没有主动提到；D27-D29 按 mock 断片点补强，SD 把 fraud data platform / reconciliation pipeline / 数仓建模三道题各刷到 45 分钟讲完；D30 缓冲日。

FAQ：PayPal DE 面试 5 个高频问题

Q1：PayPal DE 面经怎么读？重点看什么？
公开面经（一亩三分地、Blind、LeetCode Discuss、Glassdoor 等社区）重点读三样：轮次结构（几轮、每轮什么类型）、题型方向（SQL 是 fraud / 对账口径题还是通用分析题、SD 是不是 fraud data / reconciliation）、挂点（作者觉得过 / 挂在哪）。注意 PayPal DE 的公开信号量偏小且团队方向差异大：只看年份 + 级别 + 团队对得上的最近 2-3 篇，以多篇共识为准。本篇的轮次结构、题型雷达和挂点就是按这个共识整理出来的。

Q2：PayPal DE 面试几轮？
社招通常是：Recruiter Screen（不考技术）→ OA / Online Assessment（部分岗位，HackerRank 限时 coding，NG / Intern 更多）→ Phone Screen（45-60 分钟，1 道 SQL + 1 道 coding 或简历深挖）→ Onsite / VO 4 轮（1 SQL + 1 数据工程 Coding + 1 System Design + 1 BQ，每轮 45-60 分钟，部分团队排 5 轮）→ HM → Team Match。轮次数量和结构因团队、级别、地区而异，具体以实际收到的邀请为准，PayPal 出结果通常 4-8 周。

Q3：PayPal DE 考什么？难度如何？
SQL 难度 medium 但口径要求高：fraud / chargeback 指标、reconciliation 匹配、金额精度（整数分）、多币种与时区是高频方向，「先口径、再查询、后验证」三步都算分；数据工程 Coding 是 medium，follow-up 会持续加约束（数据量 10 倍、乱序 / 重复、流式输入）；System Design 对标公司自己的数据场景（fraud data platform、transaction reconciliation pipeline、数仓建模），数据质量监控、training / serving 一致性、cost 和失败路径是必答项，中高级必考；BQ 围绕 PayPal Way values，要求 STAR + measurable impact。主轴是「能不能在支付语境下 owner 一条带对账和质量保障的数据链路」，不是算法竞赛深度。

• Q4：没有支付 / 风控背景能面 PayPal DE 吗？
  可以，但有背景更省力。公开信号里，没有支付背景的候选人过关靠面试前补两样东西：一是数据正确性语言——对账（reconciliation）、幂等写入、口径定义、金额精度，这几个概念要能在任何 SQL / SD 题里主动用出来；二是业务常识——transaction、settlement、chargeback、fraud confirmed 各是什么、为什么支付数据的质量直接影响风控和财务。时间够（14 天以上）按 30 天路线里 D16-D19 的支付 / 风控数据补课清单做；只有 7 天，至少把「对账、口径、金额精度、数据质量监控」四件套在 SQL 和 SD 语境里练到能脱口而出。
• Q5：PayPal DE 和 SWE / DS 岗位差别大吗？
  差别集中在题型主轴。DE 的主轴是 SQL（fraud / 对账口径）+ 数据工程 Coding + Pipeline / Data Platform System Design + PayPal Way BQ，本文就是按这个主轴展开的；SWE 的主轴是经典 DSA Coding（含 reconciliation / 幂等 API 等支付场景变体）+ 支付业务向 System Design（payment processing、remittance、fraud detection、wallet / ledger）+ BQ，看 PayPal SWE 面经 2026；DS 的主轴是 SQL + A/B 实验设计与显著性判断 + fraud / chargeback / risk 指标叙事，偏分析视角而不是 pipeline 视角。三个方向共享同一套流程框架（OA / Phone / VO / HM / Team Match）和 PayPal Way BQ 口味，但每轮的题型重心不同，投哪个岗位就按哪个岗位的主轴准备。