“在亚马逊做 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_asciiFalse, indent2))这个脚本虽然简单但它代表了一种思维方式没有评测集就没有优化方向。大模型应用上线前最忌讳的就是“凭感觉调 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_urlhttp://localhost:8000/v1, api_keyEMPTY, # vLLM 本地服务在测试阶段不需要真实 key ) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[ {role: system, content: 你是一个专业的 AI 助手。}, {role: user, content: 用一句话解释什么是模型量化。}, ], temperature0.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{statuserror}[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%可能是审批滞留时间减少一半。你需要主动寻找这道翻译题。一个好的练习方法是每周找一个你负责的功能尝试用一句话说明“这个功能帮公司多赚了多少钱或者省了多少钱”。如果答不上来说明你和业务目标之间还有距离。这三条建议的共同点是它们不依赖任何公司提供的平台和资源。无论你在大厂还是小团队无论你服务哪个行业这些能力都能沉淀下来成为你真正的护城河。8. 总结AI 经验很重要但依赖公司平台的 AI 经验很脆弱回到标题“I built AI at Amazon, then got laid off”。这句话真正的分量不在于“被裁”这个结果而在于它揭示了一个行业规律AI 工程师的成长速度和公司业务周期的错位是普遍存在的。只要 AI 还是一个快速迭代的领域类似的故事就会继续发生。今天的亚马逊明天的某个明星创业公司后天的某个云厂商。你无法控制行业何时进入收缩期但你可以控制自己积累的能力是否跨平台、跨周期。在技术层面你需要构建可迁移的 AI 工程化能力评测体系、推理服务、Agent 工作流、成本监控、安全边界。在认知层面你需要理解企业 AI 投入的节奏把自己放在能产生直接业务价值的位置上。这样当变化到来时你失去的只是一个岗位而不是一套可以继续生长的能力体系。这套能力才是你下一份工作真正的起点。建议收藏备用。如果你正在经历岗位调整或者正在规划 AI 方向的学习路径欢迎在评论区聊聊你的想法。
大厂AI工程师被裁背后：可迁移的AI工程化能力才是护城河
“在亚马逊做 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_asciiFalse, indent2))这个脚本虽然简单但它代表了一种思维方式没有评测集就没有优化方向。大模型应用上线前最忌讳的就是“凭感觉调 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_urlhttp://localhost:8000/v1, api_keyEMPTY, # vLLM 本地服务在测试阶段不需要真实 key ) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[ {role: system, content: 你是一个专业的 AI 助手。}, {role: user, content: 用一句话解释什么是模型量化。}, ], temperature0.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{statuserror}[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%可能是审批滞留时间减少一半。你需要主动寻找这道翻译题。一个好的练习方法是每周找一个你负责的功能尝试用一句话说明“这个功能帮公司多赚了多少钱或者省了多少钱”。如果答不上来说明你和业务目标之间还有距离。这三条建议的共同点是它们不依赖任何公司提供的平台和资源。无论你在大厂还是小团队无论你服务哪个行业这些能力都能沉淀下来成为你真正的护城河。8. 总结AI 经验很重要但依赖公司平台的 AI 经验很脆弱回到标题“I built AI at Amazon, then got laid off”。这句话真正的分量不在于“被裁”这个结果而在于它揭示了一个行业规律AI 工程师的成长速度和公司业务周期的错位是普遍存在的。只要 AI 还是一个快速迭代的领域类似的故事就会继续发生。今天的亚马逊明天的某个明星创业公司后天的某个云厂商。你无法控制行业何时进入收缩期但你可以控制自己积累的能力是否跨平台、跨周期。在技术层面你需要构建可迁移的 AI 工程化能力评测体系、推理服务、Agent 工作流、成本监控、安全边界。在认知层面你需要理解企业 AI 投入的节奏把自己放在能产生直接业务价值的位置上。这样当变化到来时你失去的只是一个岗位而不是一套可以继续生长的能力体系。这套能力才是你下一份工作真正的起点。建议收藏备用。如果你正在经历岗位调整或者正在规划 AI 方向的学习路径欢迎在评论区聊聊你的想法。