AI 基建工程师入职前 90 天清单：从模型部署到监控的全流程
一句话总结
AI基建工程师的前90天不是一场技术 onboarding，而是一次组织信任资本的原始积累。你能在第90天独立推动一个模型从staging到production的完整部署，不是因为你懂Kubernetes或Triton，而是因为你在第1周就看清了谁控制GPU配额、谁对延迟数字过敏、以及谁的 sign-off 能让你的PR在周五下午被合并。大多数人把前90天当作"学习期"，结果在第91天发现自己仍在等一个永远不会来的审批；
少数人把它当作"影响力投资期"，在第45天就已经成为某个关键服务的事实 owner。这篇文章的判断是：入职顺序比技术深度更重要，关系地图比架构文档更优先，而"先赢一次小的"比"先学一遍全的"更能决定你在AI infra团队里的长期位置。
适合谁看
这篇文章写给三类人，但核心是一类人：即将或刚刚进入AI基础设施团队，却还没想明白"基建"二字在组织里真正含义的技术从业者。
第一类是刚拿到offer的senior software engineer，从传统后端团队转岗AI infra。他们通常带着多年分布式系统的经验，自信能搞定任何"技术挑战"，却在入职三周后发现，模型部署不是代码问题——是政治问题。
他们习惯用latency SLA和throughput QPS说话，却发现AI团队里还有一批听不懂这些、但控制着预算和headcount的人。
第二类是从ML engineer转型AI infra的候选人。他们能调通模型，却搞不定把模型塞进生产环境所需的工程化工作。他们常犯一个错误：以为"模型能跑"等于"任务完成"。不是模型能跑，而是模型能在峰值流量下以predictable cost运行，能在版本回滚时三十秒内切换，能让下游团队不因为你的上线而oncall——这些才是AI基建的考核标准。
第三类是new grad或early career engineer，第一次进入所谓"平台团队"。他们最容易被"基建"的光环迷惑，以为自己在做最硬核的技术，却看不清平台团队的本质是服务团队——你的用户是research scientist、是MLE、是product engineer，他们不是你的下属，不会自动采纳你的方案。
如果你2024年的base在180K-220K美元区间，RSU在150K-400K范围，bonus target 15%-20%，这篇文章的价值在于帮你避免一种常见的昂贵失误：用技术能力换取了错误的信任对象，导致第一年结束时发现自己做了很多事，但 none of it mattered for promotion。
为什么"先跑通一个模型"是错误的第一目标
大多数AI基建工程师收到laptop后的第一个冲动是：搭环境，跑个demo model，证明自己能行。这个冲动在组织行为学上可以理解，但在策略上是自杀性的。
2023年某季度末，一位新入职的L5 engineer在第二周就提交了一个完整的Triton推理服务配置，自动扩缩容策略、KV cache优化、batching参数一应俱全。他在debrief会议上展示时，infra director问了一个问题："这个服务上线后，Research团队的哪几个模型会迁移过来？"他答不上来。
会议结束后，他的PR被标记为"needs more stakeholder review"，在queue里躺了六周。六周后，另一位同期入职的engineer——那个第一周只做了三件事的人：加了三个slack channel、约了五个stakeholder coffee chat、整理了一份"当前生产模型清单及owner"——已经推动了一个更小的模型迁移，并获得了那个infra director的公开表扬。
不是技术深度不重要，而是技术深度在没有嵌入组织上下文之前是隐形的。你的Triton配置再优雅，如果解决的是一个没有被承认的问题，它就不会被承认。那位L5 engineer的错误在于把"展示能力"等同于"建立信任"，而实际上这两者在组织里的兑换汇率极低。
正确的第一目标应该是绘制"权力与痛点地图"。不是组织架构图上的reporting line，而是谁在实际操作中控制着你需要的资源。GPU quota在谁手里？通常是某个跨部门的infrastructure PM或finance BP。模型上线审批需要谁的+1？
可能是ML platform的tech lead，也可能是security团队的某个senior engineer，取决于你们公司的separation of duty设计。延迟预算（latency budget）由谁设定？如果是广告模型，可能是revenue team的PM；如果是推荐模型，可能是user engagement team的DS。
这张地图的绘制方法不是发一封"introduce myself"的邮件，而是提出一个具体的、低风险的请求。比如："我想理解当前model A的上线流程，能否给我15分钟 walk through一下你上次审批时关注的点？"这个请求的价值在于：它让对方成为专家，让你成为学习者——即使你在技术上完全不需要这次讲解。
组织心理学家Amy Edmondson的研究反复证明，早期主动展示"可被指导"姿态的新人，比早期展示"我已就绪"姿态的新人，在12个月后的绩效评估中显著更高。不是因为你更弱，而是因为你更早地嵌入了组织的知识网络。
> 📖 延伸阅读：PerplexityPM晋升时间线和评审标准深度解读2026
模型部署：不是推代码，而是设计契约
AI基建工程师对"部署"的理解需要一次根本性的重构。不是把模型文件从A处复制到B处，而是在模型生产者（research/MLE）和模型消费者（下游服务）之间建立一套可持续的契约。
这个契约包含至少五个维度：接口契约（输入输出schema、版本协议）、性能契约（p99延迟、吞吐上限、错误率阈值）、运维契约（oncall轮换、升级窗口、回滚SLA）、成本契约（GPU小时定价、预算归属、超支告警）、以及信任契约（A/B test准入标准、模型漂移检测、 fairness audit触发条件）。
大多数工程师只关注前两个，结果在第6个月发现自己在凌晨三点被叫起来处理一个"模型输出格式变了"的incident，而责任完全说不明白。
一个具体的insider场景：某hiring committee在讨论一位L6 AI infra candidate时，bar raiser提出异议："他描述了如何优化一个LLM serving的latency，但当我问'如果model owner想要加一个新feature，这个feature导致输入schema变化，你的系统怎么处理'，他的回答是'让他们提前通知我'。这不是infra engineer的思维，这是ticket taker的思维。
"HC最终no hire。这个case的启示是：AI基建的核心竞争力不是优化单点，而是设计一个让多方能持续协作的系统。
具体到前30天的部署工作，正确的做法是选择"最小可契约化模型"——不是一个demo，而是一个真实的、有下游依赖的、但复杂度可控的模型。可能是某个推荐系统的排序模型，或某个内容审核的classification模型。关键标准是：它有明确的model owner，你能叫出名字；它有现有的部署流程，你能对比改进；它的失败模式是已知的，你能设计监控。
在这个过程中，你需要产出三份文档，不是一份。第一份是"部署运行手册"（Runbook），给oncall engineer看的，解决"出了事怎么办"。第二份是"模型服务契约"（Model Serving Contract），给model owner看的，解决"我能承诺什么、你需要承诺什么"。
第三份是"架构决策记录"（ADR），给未来的自己和代码审查者看的，解决"当初为什么这样设计"。大多数工程师只写第一份，因为后两份"太费时间"或"没人要求"。但前90天的文档投资回报率极高：它们是你向组织证明"这个人做事有章法"的 cheapest signal。
监控体系：不是仪表盘，而是叙事能力
AI领域的监控与传统服务的监控有一个根本差异：传统服务的"正常"是确定的，AI服务的"正常"是统计性的。一个API的p99延迟超过100ms就是故障；一个分类模型的AUC从0.92降到0.90可能只是波动，也可能是灾难——区分这两者需要叙事能力，不是阈值设置能力。
不是监控的metric越多越好，而是你能讲出一个关于"这个模型此刻健康状态"的连贯故事。这个故事的要素包括：数据流健康（输入分布是否漂移）、模型行为健康（输出分布是否异常）、系统健康（资源使用是否可持续）、以及业务健康（下游指标是否在预期范围内）。
四者缺一不可，且需要交叉验证。只看系统健康，你会错过模型 silent failure——输入数据漂移导致模型输出系统性偏差，但一切工程指标正常。
一位senior staff engineer在debrief中分享过他的"新人工厂"：让new hire在第三周接手一个已知存在监控盲区的服务，要求不是"修复它"，而是"在两周内给我一份报告，说明如果这个问题导致生产事故，我们会在多久后知道、通过什么渠道知道、谁会被叫醒"。
这个设计的精妙之处在于：它不测试你是否能写出完美的PromQL，而是测试你能否在信息不完整的情况下，定义"足够好"的监控并为之辩护。
前60天的监控建设应该聚焦一个核心模型，穷尽三类监控的建立。第一类是实时告警（Alerting）：基于阈值，触发oncall响应。第二类是趋势分析（Trending）：基于时间序列，支持容量规划和性能退化追踪。
第三类是审计追踪（Auditing）：基于日志，支持事后调查和合规要求。大多数团队在第一类上过度投资，在第二类上投资不足，在第三类上完全缺席——直到某天需要解释"为什么这个模型在三周前开始歧视某个用户群体"时，才发现没有数据。
一个具体的操作是：在建立任何dashboard之前，先写一份"监控需求文档"（Monitoring Requirements Doc），明确三个问题：这个监控要解决谁的什么决策？数据源的刷新频率和可信度如何？误报和漏报的相对成本是什么？这份文档的存在本身，就能让你在后续的review中区别于那些只会在Grafana上拖拖拽拽的同行。
> 📖 延伸阅读：[](https://sirjohnnymai.com/zh/blog/zh-use_case-baidu-ai-pm-career-growth-strategies)
跨团队协作：不是"推动 adoption"，而是成为"默认选择"
AI基建团队有一个常见的存在性焦虑：我们做了东西，没人用。于是前90天的目标被设定为"推动X个模型迁移到我的平台"或"让Y个团队采用我的serving框架"。这个目标本身是 self-defeating 的。
不是推动adoption，而是成为默认选择。这两者的区别在于：前者是你去找用户，后者是用户来找你。实现后者的路径不是更好的marketing，而是更深的嵌入——让你的平台成为对方工作流中不可切割的部分。
一个成功的案例来自某头部AI公司的serving platform团队。他们新入职的一位engineer没有急于推广自己的新框架，而是花了三周时间成为某个高 visibility model 的"部署搭档"——不是替对方做，而是对方每次部署时都在场，记录痛点，快速迭代工具。三个月后，这个model team的其他成员开始主动使用他的工具；
六个月后，adjacent team的tech lead在planning时默认"我们应该用那个平台"。这个engineer在前90天没有完成任何"推广"动作，但完成了所有必要的信任建设。
另一个需要警惕的陷阱是"平台团队的幻觉"：以为自己的用户是单一的、理性的、会主动反馈的。实际上，你的用户是忙碌的、有各自KPI的、倾向于 workaround 而非升级的。他们不是你的产品经理，不会替你写PRD。
你需要主动成为他们的"嵌入式资源"——不是去开会，而是去他们的oncall rotation里体验 pain；不是读他们的文档，而是读他们的slack频道里真实的抱怨。
在组织架构上，AI基建工程师需要识别三类关键盟友。第一类是"早期采纳者"（early adopter）：通常是技术好奇心强、对现有流程不满的个体，他们愿意尝新，能提供真实反馈。第二类是"守门人"（gatekeeper）：控制着你的平台进入生产环境所需的审批权，可能是security、legal或compliance的代表。
第三类是"叙事放大者"（amplifier）：在组织中有广泛影响力的人，可能是senior staff engineer或director，他们的公开认可能大幅降低你的推广成本。前90天的社交投资应该按5:3:2的比例分配给这三类人，而不是平均撒网。
常见错误
错误一：把"搭建本地开发环境"当作第一周的核心成就
BAD版本：第一周结束时，新人在standup上说"我本地能跑通模型了，docker compose up一切正常"。manager点头，但infra director在随后的1:1中问："你理解我们的staging到production的promotion流程了吗？
"新人沉默。第四周，他提交的第一个production PR因为缺少security review sign-off被退回，重新排队又花了两周。
GOOD版本：第一周结束时，新人说"我跟着昨天的oncall处理了一个staging的alert，整理了当前从代码提交到production部署的12个步骤，发现其中有3个步骤的文档和实际流程不一致，我已经提交了更新建议"。manager在slack频道里@了platform lead。
第二周，这位新人被邀请参加infra roadmap的draft review。
判断差异：前者在证明"我能做"，后者在证明"我能在这个组织里做成"。本地环境是消耗品，组织知识才是资产。
错误二：在监控上追求"完备性"而非"可操作性"
BAD版本：新人在第30天展示了一个包含47个panel的Grafana dashboard，覆盖从GPU temperature到kernel launch latency的每一项指标。当被问"如果模型服务质量下降，你首先看哪个panel"时，他花了两分钟才找到正确的那个。
更糟的是，这些panel的告警阈值是默认的，每周产生200+条alert，团队已经养成了"忽略所有来自新人dashboard的告警"的习惯。
GOOD版本：新人在第30天展示了一个包含5个panel的精简dashboard，外加一份"告警响应决策树"文档。每个panel对应一个明确的业务场景（如"高峰期p99 latency恶化"），每个场景有预定义的排查步骤和升级路径。alert每周触发少于5次，全部为 actionable。
判断差异：监控的价值不在于信息总量，而在于决策速度。47个panel是技术人员的自我满足，5个panel加决策树才是infra engineer的产品思维。
错误三：回避"政治性"对话，幻想技术 meritocracy
BAD版本：一位新人在两个月后发现，自己优化的serving框架虽然性能更优，但某个senior engineer的 legacy system 仍然是某个关键业务的默认路径。他决定"用数据说话"，在all hands上展示了性能对比。
结果那位senior engineer公开质疑他的benchmark方法，会后多个team lead收到邮件暗示"这个新人在没有context的情况下criticize现有系统"。新人的项目被搁置，他在第90天review时被评为"needs improvement in collaboration"。
GOOD版本：同样的场景，这位新人在展示数据前，先约那位senior engineer的1:1，开场是："我在理解当前系统时对你的设计有几个问题，特别是X和Y两点，我想确认我的理解是否正确。"在确认对方是"合作者"而非"对手"后，他才逐步引入自己的优化方案，并明确将credit分配给"基于XX的现有设计"。最终方案以联合authorship的形式呈现。
判断差异：技术组织不是meritocracy的实验室，而是人际网络的竞技场。不是不展示数据，而是展示数据的顺序和方式决定了数据能否被看见。
准备清单
- 第1周：完成" Build, Buy, or Partner 决策文档模板（PM面试手册里有完整的B2B采购决策实战复盘可以参考）——用于理解你的平台在组织技术栈中的定位，不要假设任何东西都需要自建。
- 第1周：约五位关键人物的coffee chat，不是自我介绍，而是请对方描述"上次我的岗位让你失望的一次经历"，记录并分类为流程gap、沟通gap或权限gap。
- 第2周：选定一个"最小可契约化模型"，与model owner确认当前部署的五个痛点，按"解决所需时间"和"对对方的影响程度"二维排序，优先处理高影响、短时间的组合。
- 第2周：阅读过去90天内所有P1/P2 incident的postmortem，提取共因模式，准备一份"我能预防什么"的简短分析，在team meeting上分享。
- 第3-4周：完成一份Monitoring Requirements Doc，覆盖一个核心模型的三类监控（告警、趋势、审计），邀请model owner和oncall engineer review，不是求批准，而是求"你会在什么情况下忽略这个告警"。
- 第4-6周：推动第一个小型部署上线，必须有明确的回滚计划和oncall交接文档，上线后24小时内主动发送"一切正常/发现X问题已处理"的更新邮件。
- 第6-8周：识别并深度engagement一位早期采纳者，成为其"部署搭档"，记录其工作流中的三个friction point，选择其中一个在两周内prototype解决方案。
- 第8-12周：完成一份"平台采用障碍"分析报告，基于至少三次用户访谈，区分"我们还没做"和"他们不知道我们能做"两类问题，向manager争取resource时的核心论据。
FAQ
Q: 如果我入职时发现团队还没有成熟的模型部署流程，这是机会还是陷阱？
这是高回报但高风险的场景，判断取决于两个信号。信号一：你的hiring manager是否有意愿和政治资本支持"从无到有"的建设——不是口头上的"我们需要这个"，而是能指出具体的预算审批人和时间线。信号二：你的scope是否被清晰定义为"建立这个流程"，还是你只是"先做着看"，同时承担多个方向的不确定工作。2023年某AI unicorn的案例：一位新入职的L5被承诺"建立我们的ML platform"，但入职后发现该方向在CTO层面有竞争提案，他的工作三个月后因为组织重组被搁置。
他的同期，另一位加入已有成熟流程但明确需要"下一代架构"的engineer，反而在90天内完成了可量化的交付。判断不是"从无到有更sexy"，而是"有清晰边界的建设比无边界的创业更适合前90天的信任积累"。如果你确认两个信号都为正，那么这确实是快速建立domain ownership的机会；如果任一信号为负，你需要在30天内与manager重新negotiate scope，否则第90天的review将缺乏评估依据。
Q: AI基建工程师的promotion路径与传统infra engineer有何不同？前90天如何为此布局？
核心差异在于：传统infra的promotion依赖于规模（served QPS、节省的cost、支持的team数），AI infra的promotion increasingly 依赖于"模型到业务价值"的转化证明。不是"我让这个模型跑得更快"，而是"这个模型的latency优化带来了X%的revenue提升"或"我的平台让model deployment time从两周降低到两天，因此Y个新模型得以上线"。前90天的布局要点是：在第一个项目中就建立"业务影响追踪"的习惯。
不是上线后就转向下一个项目，而是与下游的PM或DS约定metric review的节奏，确保你的技术工作能被翻译成业务语言。一位L6 promote到L7的案例中，candidate的核心成就是"建立了模型性能与下游广告收入的数据管道"，这个管道本身的技术复杂度不高，但它让model optimization与business outcome的连接变得可见、可量化。前90天就开始问"我们如何measure这个部署的成功"，即使答案不完美，这个问题本身就会改变你在组织中的定位。
Q: 面对"研究优先"与"工程稳健"的永恒张力，AI基建工程师应如何站位？
这不是一个需要"解决"的问题，而是一个需要"管理"的动态平衡。判断不是站在任何一边，而是成为双方都能接受的"翻译者"和"仲裁机制设计者"。具体而言，前90天你需要做三件事。第一，建立"research readiness checklist"：不是阻止research团队实验，而是让实验的risks被显式评估和接受。这个checklist要由你和research representative共同制定，而不是infra单方面impose。
第二，设计"渐进式生产化"路径：不是"staging直接到production"，而是"shadow mode → canary → partial rollout → full rollout"，每个stage有明确的exit criteria和rollback trigger。第三，培养与research团队关键人物的私人信任：不是通过正式会议，而是通过帮助他们解决具体的、紧迫的问题——一个debug session、一次紧急的profiling支持、一份清晰的latency bottleneck分析。一位senior director的观察是："最好的AI infra engineers不是那些说'不'最坚决的人，而是那些能让research团队觉得'这个人帮我更快达到了目标'的人。"前90天就开始建设这种认知，会在你未来需要说"不"的时候，拥有更多的信用余额。
面试流程深度拆解（补充参考）
如果你仍在准备进入AI基建领域，理解目标公司的面试设计能反向指导你的前90天准备。典型流程为4-6轮，总时长4-8周。
第一轮：Recruiter Screen（30分钟）。考察点不是技术，而是你的motivation与team fit是否自洽。关键信号：你能清晰解释"为什么AI infra而不是MLE或传统backend"，并且这个解释与该公司的实际业务挑战对齐。常见失败模式：候选人给出generic的"我对AI感兴趣"，无法区分infra与ML research的差异。
第二轮：Technical Phone Screen（45-60分钟）。通常为live coding或system design，重点考察分布式系统基础与AI场景的结合。
典型题目：设计一个模型serving系统，支持auto-scaling和A/B testing。考察重点不是你知道多少框架，而是你在latency vs throughput vs cost之间的tradeoff决策过程。
第三轮：Onsite/Virtual Onsite（4-5轮，每轮45-60分钟）。
包含：System Design（深度考察，可能涉及multi-model serving或federated learning infra）、Coding（LeetCode medium-hard，但可能加入"优化这个inference pipeline"的变体）、ML Knowledge（不是让你训练模型，而是理解model serialization formats、quantization impact on serving、batch inference optimization等）、Behavioral（重点考察cross-functional collaboration，特别是与research团队的冲突处理）、以及Hiring Manager面试（考察scope clarity和growth alignment）。
第四轮：Hiring Committee Review。HC由跨部门senior engineer组成，不是你的未来同事。他们评估的是bar consistency——你的表现在公司整体标准中处于什么位置。
关键材料：面试官的feedback、你的packet（包含背景调查和可能的take-home assignment结果）。HC不直接决定是否hire，而是向hiring manager提供recommendation。
第五轮（部分公司）：VP/ Director面试。对于L6及以上，这是standard。考察点：你是否能 articulate 一个technical vision，并展示influence without authority的能力。准备一个具体的例子：你如何说服一个团队采用你的方案，尽管你没有直接管理权。
薪资参考（硅谷2024年，senior level）：base 180K-220K，RSU 4年vest总计200K-400K（取决于公司stage和negotiation），bonus 15%-20% of base。总包（TC）中位约在300K-450K。Staff level（L6+）base 220K-250K，RSU 400K-700K，bonus 20%-25%，TC可达500K-800K。
negotiation空间通常在RSU和sign-on bonus，base受band限制较严。掌握competing offer是有效的谈判筹码，但表达方式至关重要——不是"X公司给了我更多"，而是"基于我对这个scope的理解和我能带来的价值，我期望的TC组合是..."。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。