当前位置：首页 > news >正文

大厂AI工程师被裁背后：可迁移的AI工程化能力才是护城河

news 2026/8/30 11:03:27

“在亚马逊做 AI，然后被裁员。”这句标题在 2024 到 2025 年的大模型行业里，几乎成了一种时代样本。它之所以能引起共鸣，不是因为它讲述了一个人的遭遇，而是因为它把一个很残酷的事实摆到了所有 AI 工程师面前：你服务的技术方向正在高速增长，并不意味着你的岗位是安全的。

这篇文章想分析的不是“亚马逊值不值得去”，也不是“大厂裁员有多冷血”。我想拆解的是更技术、也更值得思考的问题：一位深度参与 AI 系统建设的工程师，为什么会在 AI 最受重视的时期失去工作？他平时攒下的那些模型训练、推理优化、特征工程经验，到底哪些能带走，哪些只是公司平台的专属技能？

如果你正在做 AI 应用开发、模型部署、Agent 工程，或者准备进入这个方向，这篇文章值得看完。

1. 为什么“在亚马逊做 AI 然后被裁员”值得认真拆解

先说一个容易被情绪掩盖的事实：在大模型时代，AI 工程师的岗位风险不是来自“AI 不够强”，而是来自“AI 技术栈迭代太快”。

传统的软件工程师，Java 写十年、Spring 框架写五年，经验是增值的。但 AI 工程师不一样。三年前你会训练 BERT 微调模型，两年前你会搭 Stable Diffusion 推理服务，一年前你会写 LangChain 应用，今天你得会设计多 Agent 协作系统。技术栈的保质期越来越短，而公司内部的业务优先级变化比技术栈更快。

亚马逊的 AI 团队大致可以分成三类：

团队类型	主要工作	典型岗位
基础平台团队	机器学习平台、训练集群、推理基础设施	ML Platform Engineer、Infra Engineer
业务算法团队	推荐、搜索、供应链预测、广告排序	Applied Scientist、ML Engineer
大模型应用团队	LLM 应用、内部 Copilot、Agent 系统	Applied AI Engineer、LLM Engineer

这三类岗位在组织结构调整中，被调整的优先级完全不同。平台团队容易被合并，业务算法团队容易被重新定位，大模型应用团队则要根据业务 ROI 重新证明价值。所以“AI 团队被裁”并不是一个整体事件，而是组织在重新为每个技术岗位定价。

这个定价逻辑，才是这篇标题真正值得分析的地方。

从材料来看，亚马逊本身从未停止在 AI 上的投入，AWS 的 Bedrock、SageMaker、Trainium 芯片都在持续扩展。但“公司重点投入 AI”和“某个团队安全”是两回事。当一个公司的 AI 战略从探索期进入成本核算期，所有岗位都会回到同一个问题：你做的系统，到底帮公司省了多少钱，或者多赚了多少钱？

很多 AI 工程师的困境在于，他们擅长回答“模型效果提升了几个点”，却不擅长回答“这个提升值多少钱”。在业务上升期，这个问题不重要；在组织收缩期，这个问题决定去留。

2. 大厂 AI 工程师平时到底在做什么

要理解这个标题背后的技术逻辑，你得先知道大厂 AI 工程师的日常工作边界。很多人以为在亚马逊做 AI 就是训练大模型、调 Prompt、发论文，真实情况要复杂得多。

第一类：机器学习平台工程师。这类工程师负责搭建模型训练和部署的基础设施。工作内容包括 GPU 集群调度、数据管道、模型注册中心、在线推理服务。在亚马逊内部，这通常意味着使用 SageMaker 或自研的 ML 平台，为业务团队提供“模型训练和部署的能力”。这类岗位的技术深度很高，但与公司内部平台绑定极深。你会的不是通用的 Kubernetes 和 vLLM，而是“如何用公司内部框架完成任务”。

第二类：业务算法工程师。负责推荐系统、搜索排序、广告竞价、供应链需求预测。这类工作非常依赖业务数据和业务指标。你在亚马逊学会的“如何优化次日送达预测准确率”，换一家电商公司可能有一半经验能用，换一个行业可能就归零。这里有价值的是特征工程、实验评估、AB 测试的思维，而不是具体模型。

第三类：大模型应用工程师。这类岗位是近两年新增最多的。工作内容很杂：把开源模型接入内部知识库、设计 RAG 流程、写 Agent 工具调用逻辑、做模型效果评测、优化 Prompt。这类工作看起来最“AI”，但技术门槛在快速降低。因为模型能力越来越强，工具链越来越成熟，原来需要工程师调三天的东西，现在一个开源框架就解决了。

这三类岗位有一个共同点：大部分时间花在数据处理、工程对接、效果验证和线上监控上，而不是“发明新算法”。这也是为什么大厂的 AI 工程师离开平台后，经常会发现自己“什么都会一点，但能带走的不多”。

3. 大模型时代的岗位迁移：从训练模型到组装能力

“在亚马逊做 AI 然后被裁员”这个标题，如果放在五年前，故事的重点会是“做 AI”——那时候会训练模型的人稀缺，被裁了也能很快找到下家。但放在今天，重点是“在亚马逊”——大模型时代，模型训练的技术壁垒正在被开源社区和云厂商快速抹平。

我们看三代 AI 工程师的技术栈变化：

代际	核心技术	主要任务	稀缺能力
传统 ML 时代	Python、Scikit-learn、XGBoost、SQL	特征工程、模型训练、上线	特征理解、业务建模
深度学习时代	PyTorch、TensorFlow、GPU 集群	模型结构设计、分布式训练	算法创新、调参经验
大模型时代	HuggingFace、vLLM、LangChain、向量数据库	模型选型、RAG、Agent 编排、评测	系统设计、工程集成、成本控制

这个变化意味着什么？

以前，AI 工程师的核心价值是“把模型训练出来”。今天，开源社区已经把模型训练的能力普惠化了。你可以用 Llama、Qwen、DeepSeek 等开源模型快速获得一个基础能力，也可以直接调用云厂商的 API。真正决定一个 AI 系统好坏的，变成了三个问题：

数据怎么来、怎么清洗、怎么评估？这决定了模型能力的上限。
模型怎么部署、怎么压测、怎么降本？这决定了系统能不能上线。
Agent 怎么设计、怎么容错、怎么兜底？这决定了用户愿不愿意用。

这三个问题，都属于“AI 工程化”的范畴，而不是“AI 算法研究”的范畴。所以更准确的判断是：大模型时代，AI 工程师正在从“造模型的人”变成“组装 AI 系统的人”。那些只能造模型、不会组装系统的人，岗位风险最高。

我知道很多算法工程师对“组装”这个词有抵触。但从岗位供给来看，市场需要的是能端到端交付 AI 应用的人。你可以不做大模型预训练，但你不能不会部署模型；你可以不写复杂的模型结构，但你不能不会设计评测集。

4. 被裁后真正值钱的能力：AI 工程化五件套

如果我们把“在亚马逊做 AI”当作一个案例来复盘，就会发现：真正能跨公司、跨行业带走的，不是你在某个大厂内部平台上的操作经验，而是一套稳定的 AI 工程化能力。这套能力可以拆成五个部分，我称为“AI 工程化五件套”。

4.1 数据构建与评测体系

很多 AI 工程师对数据的理解停留在 SQL 查询和 pandas 处理。但在大模型时代，数据工作的核心是建立一套属于你业务的评测集。

你可以从零开始构建一个模型效果评估脚本，将不同模型的输出结果进行结构化对比：

# 文件路径：eval_pipeline.py """ 一个轻量的大模型评测脚本示例。 核心目标：用同一批测试样本，对比不同模型或不同 Prompt 的效果。 """ import json from typing import List, Dict # 模拟一批评测样本，真实项目中建议至少准备 200 条以上 EVAL_SAMPLES = [ { "query": "帮我总结这份会议纪要里的待办事项", "context": "会议讨论了 Q3 的产品规划，确定 9 月前完成用户画像模块，10 月上线推荐策略 v2，由算法团队和平台团队配合。", "labels": ["9月前完成用户画像模块", "10月上线推荐策略 v2", "算法团队和平台团队配合"], }, { "query": "把下面这段话改写成更专业的邮件语气", "context": "那个需求还没做完，因为后端接口一直没给，我们这边很被动。", "labels": ["需求存在延期风险，主要原因是后端接口未按时提供", "需要明确新的交付时间并同步进展"], }, ] def evaluate_response(prediction: str, labels: List[str]) -> Dict: """单条样本的评估逻辑，这里用关键词命中做示例。 真实业务中，可以替换为大模型裁判或人工评估。 """ hit_count = 0 for label in labels: if label.lower() in prediction.lower(): hit_count += 1 hit_rate = hit_count / len(labels) if labels else 0.0 return {"hit_rate": hit_rate} def run_evaluation(model_predict_func) -> Dict: """跑完整评估集。model_predict_func 是你封装好的模型调用函数。""" total_rate = 0.0 result_list = [] for sample in EVAL_SAMPLES: prediction = model_predict_func(sample["query"], sample["context"]) result = evaluate_response(prediction, sample["labels"]) result_list.append({ "query": sample["query"], "prediction": prediction, "hit_rate": result["hit_rate"], }) total_rate += result["hit_rate"] avg_rate = total_rate / len(EVAL_SAMPLES) return {"avg_hit_rate": avg_rate, "details": result_list} # 假设你有一个模型调用函数 def dummy_predict(query: str, context: str) -> str: """这里替换成真实的模型调用即可，比如 OpenAI / 开源模型 / 内部服务。""" return "9月前完成用户画像模块，10月上线推荐策略 v2。" if __name__ == "__main__": result = run_evaluation(dummy_predict) print(json.dumps(result, ensure_ascii=False, indent=2))

这个脚本虽然简单，但它代表了一种思维方式：没有评测集，就没有优化方向。大模型应用上线前，最忌讳的就是“凭感觉调 Prompt”。你在亚马逊做 AI 时可能用的是内部评测平台，但离开之后，你依然可以用这套思路自己搭建评测流程。

4.2 模型服务与推理优化

第二个核心能力是把模型变成稳定、低延迟、可扩展的在线服务。大厂内部通常有专门的基础设施团队处理这个问题，但如果你只会调用内部平台的部署按钮，离开大厂后会很被动。

一个通用的方案是使用 vLLM 这类推理加速框架部署开源模型：

# 启动一个 OpenAI 兼容的模型服务 # 需要提前安装: pip install vllm # 以 Qwen2.5-7B-Instruct 为例，实际模型名请按 HuggingFace 仓库填写 vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85

启动之后，你可以用标准的 OpenAI SDK 进行调用：

# 文件路径：client_test.py from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", api_key="EMPTY", # vLLM 本地服务在测试阶段不需要真实 key ) resp = client.chat.completions.create( model="Qwen/Qwen2.5-7B-Instruct", messages=[ {"role": "system", "content": "你是一个专业的 AI 助手。"}, {"role": "user", "content": "用一句话解释什么是模型量化。"}, ], temperature=0.7, ) print(resp.choices[0].message.content)

这里真正值得学习的是推理优化的思维。模型部署不是“能跑就行”，而是要考虑并发、延迟、吞吐、显存占用、成本五个维度。在大模型应用里，没有优化过的推理服务，token 成本可能相差数倍。你可以用vllm serve快速启动，也可以借助 Rust 推理框架提升吞吐场景下的性能表现。这些技能不依赖任何一家公司内部平台，出了大厂同样能用。

4.3 Agent 工作流与工具调用设计

第三个能力是设计复杂的 Agent 工作流。很多人一上来就写很复杂的 ReAct 循环，结果发现错误率很高。真正的工程做法是：从最简单的流程开始，逐步加工具、加人机协同确认机制。

用户提问 -> 意图识别（可以是大模型，也可以是规则） -> 工具调用（搜索、查库、读文件） -> 结果校验（关键动作必须人工确认） -> 生成回复

意图识别：判断用户是不是要执行敏感操作。
工具调用：把用户问题转为具体 API 参数。
结果校验：高风险的步骤必须加一层用户确认，比如“你要删除这份订单吗？”
生成回复：将工具结果组织成自然语言。

这套流程看起来不复杂，但它是 Agent 工程的核心。大模型负责理解意图和生成回应，工程代码负责保证可靠性和安全性。

4.4 成本与稳定性度量

第四个能力是成本分析和稳定性保障。在亚马逊做 AI，你可能不太关心单次推理的成本，因为公司有预算。但离开大厂，AI 应用的成本直接决定产品能不能活。一个常见的问题是灾难性遗忘，可以通过日志监控及时发现和修正。

一个自建推理服务，可以用 Prometheus 采集 Tokens 和延迟指标，再配合告警规则：

# 文件路径：prometheus/alerts.yml groups: - name: llm_service_alerts rules: - alert: HighLatency expr: 'histogram_quantile(0.95, sum(rate(llm_request_duration_seconds_bucket[5m])) by (le)) > 5' for: 5m labels: severity: warning annotations: summary: "LLM service p95 latency above 5s" - alert: HighErrorRate expr: 'sum(rate(llm_requests_total{status="error"}[5m])) / sum(rate(llm_requests_total[5m])) > 0.05' for: 5m labels: severity: critical annotations: summary: "LLM service error rate above 5%"

4.5 安全与合规边界

最后一个能力，也是最容易被忽视的：AI 应用的安全边界。大模型应用涉及用户输入、工具调用、数据权限，任何一个环节都可能成为安全漏洞。

我从实践中总结了几条必须守住的底线：

工具调用必须做权限校验：用户不能通过自然语言让 Agent 越权执行操作。
外部输入要做 Prompt 注入防护：不能把用户输入直接拼接进 System Prompt。
敏感数据不能进上下文：日志、评测集、训练数据里如果有个人信息，必须脱敏。
高危操作要人工确认：删除、转账、发送消息，都要设计二次确认。

这些原则不分公司、不分行业，是 AI 工程师的基本职业素养。在亚马逊做 AI 时，这些规则可能已经内化在公司的 review 流程里；离开后，你需要自己建立这套意识。

5. 从大厂出来，最容易踩的三个坑

讨论完可迁移的能力，我想再谈三个常见的认知误区。这不是站在高处说教，而是很多人在转型期真实会遇到的问题。

第一个坑：把自己的经验绑定在特定工具上。“我用过亚马逊的 Bedrock”“我会用 SageMaker”——这些在简历上可以写，但不要当成核心竞争力。云平台 API 是商品，今天能用 AWS，明天就能用阿里云或火山引擎。真正值钱的是你理解模型 API 背后的原理：Token 计费方式、上下文长度限制、温度参数的影响、输出格式控制手段。把这些抽象出来，换一个平台只是改几行代码的事。

第二个坑：盲目追逐最新模型，忽视业务落地。看到新模型发布了就急着接入，看到新的 Agent 框架火了就重写系统。这种“追新”的习惯在大厂有资源支持，但在资源有限的环境里很致命。正确做法是给新模型建立评测集对比，而不是凭感觉替换。

第三个坑：只做效果，不做成本。在有些公司，算法工程师只需要关注效果指标；但在大多数场景里，成本才是决定系统能不能活下去的关键。AI 应用的成本来自三块：模型推理成本、数据存储成本、人工标注和审查成本。你在设计系统的时候，就要把这几个变量考虑进去。能用小模型解决的就不用大模型，能离线计算的就不在线推理，能用缓存的就别反复调用。

6. 被裁之后的组织视角：为什么 AI 团队反而被调整

回到标题中的事件本身。我们不妨从公司的角度想一个问题：为什么一家在 AI 上投入巨大的公司，会调整 AI 岗位？

这背后有一个经常被忽略的组织规律：企业的 AI 投入遵循明显的周期性，而不是线性增长。

第一波是“叙事期”。公司需要 AI 故事来支撑估值和品牌形象，这个阶段大量招人，敢花钱，做各种 Demo 和概念验证。

第二波是“平台期”。公司开始挑选哪些 AI 项目值得继续投入，哪些只是“技术看起来很酷但业务价值不明”。这个阶段，大量的内部工具、实验性项目会被砍掉。

第三波是“变现期”。公司要求每个 AI 系统都要回答投入产出比。不能降本、不能增收的项目，不管技术多先进，都会被调整。

很多 AI 工程师在“平台期”被裁，不是因为他们技术不行，而是因为他们做的项目在第二波被选型淘汰了。这与个人能力关系不大，更多是组织对投入节奏的控制。

对个人来说，这个视角有一个实际用途：评估一个 AI 岗位是否安全，不能只看它在做什么，还要看它处于公司 AI 战略的哪个阶段。

更进一步说，AI 工程师要把自己放在“变现期”来设计职业规划。不要只做“研究型”的项目，尽量参与能直接关联业务指标的系统。你的简历上不应该只写“做了某某模型”，而应该写“通过优化某某链路，让线上转化率提升了多少个点”。

7. 给 AI 工程师的护城河建议：三条实践路径

最后聊一聊“怎么办”。如果你当前就在做 AI 相关的工作，或者准备入行，下面这三条建议是更稳妥的长期思路。

第一条：建立个人评测集和基准库。不要只依赖公司的评测平台。你可以根据自己的方向，积累一份私有评测集，定期给新模型、新方案跑分。这样你就能形成独立判断，知道哪个模型适合你的业务。这份评测集就是你离开任何平台都能带走的个人资产。具体做法是，每周挑选 5 到 10 个典型业务问题，记录表现最好的模型和配置，持续积累。

第二条：拥有一个端到端的个人项目。不要在简历上只写“参与了公司的 XX 平台开发”。花时间搭建一个完整的 AI 应用：包括数据采集、离线评估、在线部署、指标监控、成本归因。规模可以很小，但环节要完整。例如，用 vLLM 部署一个开源模型，配合向量数据库做一个 RAG 检索应用，再加一层使用量监控和成本估算。做完这个闭环之后，你对 AI 工程的理解会和只看文档时完全不同。这个项目还能让你在面试时展示真实的工程能力。

第三条：刻意训练业务翻译能力。这是很多 AI 工程师的短板，也是区分高价值工程师和可替代工程师的关键。所谓“业务翻译能力”，就是把技术指标翻译成业务语言。模型召回率提升 5%，在业务上意味着什么？可能是推荐点击率提升 2%，可能是客服转人工率下降 10%，可能是审批滞留时间减少一半。你需要主动寻找这道翻译题。一个好的练习方法是：每周找一个你负责的功能，尝试用一句话说明“这个功能帮公司多赚了多少钱，或者省了多少钱”。如果答不上来，说明你和业务目标之间还有距离。

这三条建议的共同点是：它们不依赖任何公司提供的平台和资源。无论你在大厂还是小团队，无论你服务哪个行业，这些能力都能沉淀下来，成为你真正的护城河。