收到裁员通知那天我正盯着一行AI服务的推理超时日志。报错还没滚完会议邀请已经弹了出来“10分钟后HR同步。”那两年我在亚马逊做的是AI相关工程不是外界想象中那种每天训练大模型的工作。更多时间我花在数据管线、评估脚本、部署配置和监控告警上。被裁之后我把这段经历重新拆了一遍得到一个现在看起来很清楚的判断大厂AI工程师的护城河多数时候不是某个模型能力而是把AI放进复杂系统里稳定运行的工程能力。下面想把这套能力讲透包括它为什么容易被误判、被裁之后怎么重新审视、以及如果重新出发应该优先搭建什么。1. 在大厂做AI和你想象的可能不是一回事1.1 模型只占日常工作的很小一部分如果只看招聘JD“AI工程师”听起来像每天都在调模型、跑实验、和论文打交道。真正工作一段时间后你会发现模型选择往往很快被定下来。要么直接用平台已经封装好的模型服务要么调用第三方API再或者基于开源模型做一次快速适配。真正耗时间的反而是数据、评估和线上稳定性。举个常见例子。某个内部功能要做文本意图识别开始之前要弄清楚线上到底有哪些历史问法数据从哪个表来标签体系怎么定长尾意图怎么处理。这些问题模型基本不参与。你需要先把数据清洗干净再设计评估集选好评估指标然后才轮到模型服务。我参与过的AI功能时间分配大致是数据处理和清洗占三成评估和bad case分析占三成模型调用和参数调整占两成部署、监控、文档再占两成。这个比例不一定准确但它能说明一个问题模型不是全部。很多新人进入大厂AI岗位会失望因为真正写模型代码的时间没有想象中多。这不是坏事。反而是这份“不性感”的工作决定了AI功能能不能长期跑下去。1.2 平台越完善个人角色就越像流水线上的一个焊点在大厂里AI平台建设通常已经非常成熟。训练平台、推理平台、数据平台、特征平台、评测平台、A/B实验平台每一层都有专门团队在维护。个人加入后往往只负责其中一小段流程。平台稳定时这个角色按流程操作就行平台变更或组织调整时这个角色就需要重新证明价值。这也是为什么裁员时很多看起来技术很强的人同样会被裁。不是他们能力不行而是能力高度绑定在内部平台上。你熟悉的是某套内部任务队列、某个内部模型网关、某套内部评测工具。一旦离开这些经验需要翻译成通用能力才能变现。我见过一些人在大厂时所有操作都依赖内部工具离开后第一周连最基础的模型调用都迟迟搭不起来。不是因为不会写代码而是过去几年习惯了平台帮他处理环境、权限、日志、重试这些事。平台能力不等于个人能力。这句话在职场上经常被提但只有真正断掉平台支持时体会才最深。1.3 “我在某家公司做过AI”这句话的分量正在变弱几年前说“我在头部大厂做过AI”会让人觉得你接触过大规模系统、见过复杂场景。现在这句话的保护力越来越有限。原因是AI工具正在快速模块化调用模型已经变得非常便宜。大家更关心的是你解决过什么问题怎么验证的遇到线上故障怎么排查。如果你只是在大厂内部平台里“点按钮”或“写胶水代码”出去之后可迁移的东西很少。相反如果你能解释一个AI服务从需求到上线需要哪些步骤每一步可能出现什么问题如何通过日志定位问题这些能力反而越来越值钱。前者叫“使用过平台”后者叫“具备工程实践能力”。被裁之后这句话的分量会以很直接的方式反映在面试结果里。2. 单次跑通和稳定运行之间隔着一条很深的工程河2.1 Demo能跑不代表生产可用我见过不少内部AI项目演示时效果不错一上生产就翻车。翻车原因很少是模型本身答错而是输入字段变了、上游数据没对齐、并发一高就超时、输出格式不稳定。有一次排查一个文本生成服务的卡顿最后发现是上游系统把用户昵称字段从字符串改成了数组。我们的代码里没有做类型校验直接拿数组去做长度判断导致整个请求链路进入死循环。这个问题和模型能力没有任何关系。但它让服务整整不可用了两小时。这类问题背后其实是一个共通的误解把模型调用当作AI服务的主体。实际上模型调用只是链路里的中间环节。真正需要设计的是外面的壳。一个最简单的服务也要处理输入校验、输出校验、超时、重试、降级、日志。单次跑通只能说明流程没有断不能说明它能稳定工作。下面是一个很常见的服务结构示例不是完整实现但能看出模型调用外面要包多少东西def handle_request(payload): if not validate_input(payload): return {error: invalid_input, code: 400} try: result model_client.generate(payload) if not validate_output(result): raise ValueError(output check failed) return {data: result} except TimeoutError: return fallback_response(payload) except Exception as exc: log_exception(exc) return {error: service_unavailable, code: 503}这里最容易被忽略的是validate_output。很多人会认真做输入校验却很少检查模型生成的输出是不是符合预期结构。结果就是模型偶尔返回一个空列表或者多了一对括号下游解析就崩了。2.2 生产级AI服务至少要盯住四个环节以文本类AI服务为例最容易出问题的不是模型偶尔答错而是以下四个环节环节常见问题最低要求输入校验缺字段、类型不对、编码异常、文本过长定义清晰schema入口统一校验输出校验空结果、格式错误、长度失控、字段缺失结构校验、范围检查、长度限制异常处理上游超时、模型请求失败、并发打满超时设置、有限重试、降级、兜底监控与日志线上问题难以复现、反馈滞后记录输入输出、耗时、错误类型、样本采样每一个环节都很小但叠加起来就是工程和Demo的差距。输入校验不只是“非空判断”。要考虑到文本编码、特殊字符、字段类型、长度上限。比如用户拿一个几万字的文档过来你的模型上下文装不下是直接截断还是提示超限需要提前决策。输出校验也不只是简单检查非空要检查是否符合约定的JSON结构、是否包含非法字段、长度是否合理。如果模型生成的内容要直接展示在页面上还可能要过滤危险内容或敏感字段这里需要有明确的内容安全策略。异常处理要特别小心重试。不是所有失败都适合重试。模型返回上下文超限、输入不合法时重试多少次都是浪费。超时重试要配合退避策略防止集中重试把下游打挂。降级方案有时比模型本身更重要模型服务不可用是返回固定文案还是走一个简单规则模型都需要提前设计。监控与日志是很多个人项目最不重视的部分。开发时觉得不需要上线后才发现完全不知道线上发生了什么。不需要一开始就上很重的监控体系至少要做到每一条请求进来能记录输入摘要、模型耗时、输出状态码、错误类型。这样即使出了问题也能从日志还原现场。2.3 一套通用排查链路别一上来就调模型AI服务本质上是一条链路排查问题时要一层一层找。我的习惯是固定顺序先看现象是报错、卡住、无输出、输出错误还是只是变慢再查输入样本格式、字段、编码、大小、上下文是否超限再看环境依赖版本、权限、端口、资源占用是否正常再看参数并发数、batch大小、超时时间、temperature、max_tokens是否合理最后看工具边界当前模型版本、框架版本、API限制、场景是否匹配这个顺序的核心是先确定问题出在哪一层再决定改哪里。很多人遇到模型输出不对第一时间就去调Prompt或temperature结果发现是输入文本里混入了乱码。遇到服务变慢第一时间加机器结果发现是上游数据库连接池被占满。先看现象是为了把问题归类。是“连不上”还是“响应慢”还是“结果错误”背后的排查路径完全不同。再查输入是因为AI服务的失败往往由输入触发。输入没问题再怀疑环境环境没问题再看参数和模型边界。用这个顺序能省掉大量盲目试错。3. 被裁之后我重新梳理了AI工程师的可迁移能力3.1 模型和框架会过时问题定义能力不会被裁后的那几周我把过去几年用过的模型、框架、Prompt技巧列了一张表发现大多数东西都已经过时或者正在被新工具替代。两三年以前很流行的Prompt写法现在很多框架已经内置了。某个模型的调用参数换个模型可能就完全不同。框架API更是半年一小变、一年一大变。但有一些东西没有变。比如把一个模糊需求拆成可判定的输入输出。老板说“做一个智能客服”你需要先回答几个问题模型负责哪些问题人工负责哪些问题判断标准是什么模型答错怎么兜底多轮上下文怎么管理。再比如知道当前模型适不适合这个场景。不是所有任务都适合用大模型有些固定规则用代码处理更便宜更稳定。还比如设计一套评估方案。在项目开始前就定义“什么样的输出算好”而不是等上线后再凭感觉判断。这些能力不会因为模型换代而失效。它们来自一次次项目复盘、一个个bad case分析、一次次和业务方对齐预期的过程。它们不像某个框架API那样可以直接背但一旦形成就能迁移到任何AI岗位。3.2 真正能带走的是“把流程固化下来”的能力大厂里流程固化通常由内部平台完成。平台会帮你管理数据、模型版本、任务调度和监控。离开后这些都需要自己用代码重新搭起来。这部分能力是在大厂日常工作中最容易被忽视的。我在复盘时给自己定了一个原则不能只积累“当时在某个平台里跑通过”的经验要能在一台普通电脑上重新搭出最小流程。于是我把一次典型的AI任务拆成固定目录experiments/ data/ raw/ processed/ prompts/ system.md configs/ model_config.yaml eval/ metrics.py logs/ run_001.log这个结构本身不复杂但它强制你考虑几件重要的事原始数据放哪里处理后的数据放哪里Prompt文本和代码分离模型配置可修改评估脚本独立运行日志留存可追溯。每换一个项目都能复用这个骨架。这件事看起来简单却是很多人不愿意做的。因为写处理脚本比写一个能跑出结果的notebook麻烦维护目录结构比临时堆文件麻烦。但它决定了一个经验能不能被反复使用。被裁之后没有内部平台帮你兜底这种“把流程固化下来”的能力就变得格外重要。3.3 个人项目和可展示产出才是新的信用支撑在大厂工作很多产出藏在内部系统里不能展示也不能给别人看。面试时说“我搭建过某套评估系统”对方只能从简历上的字面意思去推测。被裁之后没有内部系统权限这些产出就彻底无法证明。所以要重新建立可验证的资产。代码仓库、技术博客、可复现的Demo、开源的小工具这些东西不一定复杂但能证明你能从零到一完成一个完整任务。重点是展示“完整闭环”你定义了一个什么问题做了什么设计决策写了哪些代码怎么评估结果遇到了什么错误怎么排查出来的。这一整套思考过程比一个看起来很厉害的项目名称有说服力得多。很多在职的人觉得工作忙没有时间做个人项目。我的建议是哪怕每个月只花一个周末也要维护一个“带得走”的东西。因为公司给你的平台支持、权限、资源和内部信誉一旦离开就会全部清零。只有个人工作流里沉淀下来的东西会跟着你走。4. 从“大厂AI工程师”到“独立技术人”的再出发路线4.1 先选择一个足够小的场景跑通闭环被裁之后最重要的不是马上接很多项目而是先把一个最小场景跑通。这个场景需要足够小小到一天之内能完成第一版但又足够完整能覆盖AI工程的基本环节。我的建议是选一个文本处理任务。比如“每天抓取几个RSS源的关键文章用模型生成一份结构化摘要保存成Markdown文件”。这个场景输入输出清晰模型只需要做一次生成不需要复杂的多轮交互。流程可以这样定确定输入一个RSS源列表或一个文本文件。确定输出一份固定格式的Markdown摘要文件。模型API负责生成总结。脚本里加上输入校验、失败重试、输出格式检查。每天定时运行保留日志。不要一上来就搭多Agent系统。多Agent会引入太多变量上下文怎么传递、任务怎么拆分、失败怎么恢复、成本怎么控制。这些问题在最小场景里很难学明白。先把单次调用做成一个可靠的服务再考虑复杂编排。4.2 工具链选择能少则少但不代表没有现在AI工具生态很丰富很容易让人陷入“选框架”而不是“做任务”的状态。我的建议是固定一套最小工具链先把流程跑通再根据实际需要调整。常见的组合大致是组件作用常见选择模型调用生成文本、处理任务各家大模型API或本地部署开源模型流程编排把多步任务串起来LangGraph、Semantic Kernel、Spring AI 等向量检索需要语义检索时使用Chroma、Milvus、FAISS 等日志与监控记录运行情况结构化日志到文件后续可接数据库或观察平台这里没有写具体版本因为AI工具更新太快直接照搬版本号很容易过时。落地前要确认依赖版本和兼容性。在“流程编排”上我的建议更保守一些。如果只是做单任务加工直接写一个Python脚本就够了不需要引入框架。只有当任务需要多步编排、条件分支、人工审核、重试队列时再引入编排框架。工具数量越少排查问题越容易。先跑通再优化不是一句空话。4.3 单任务跑通之后再做批量化和规范化单任务跑通只说明流程在一条样例上是通的。要真正证明流程可重复需要做批量和异常演练。批量化的核心是让每个任务都有独立的ID每个任务的状态和错误都能被记录失败任务能重试结束后有一份汇总报告。一个常见的批处理骨架长这样for task in tasks: try: result run_single_task(task) logger.info(ftask{task.id} statussuccess result{result.metrics}) save_result(task.id, result) except Exception as exc: logger.error(ftask{task.id} statusfailed error{exc}) retry_count task.retry_count 1 if retry_count max_retry: queue_retry(task, retry_count)这个骨架很简单但它把运行状态、结果和失败原因都记录了下来。批量执行时最怕的不是失败而是失败后你不知道哪些任务成功、哪些失败、失败原因是什么。有了日志和重试机制即使某个任务失败你也能在汇总报告里一眼看到问题。批量化之后是规范化。规范化指的是每次实验都能回答“我用了哪个模型版本、哪个Prompt版本、哪个数据集、评估结果是多少”。不需要一次做得非常重但至少要把这几个维度记录下来。这样后续修改Prompt或参数时才能对比前后效果。否则你会发现项目一改结果好坏全靠感觉根本无法判断是哪里变了导致的效果变化。5. 写在最后AI岗位的价值是让人和工具协作得更顺5.1 别用一次裁员否定掉整个积累裁员发生的时候很容易冒出“我做了几年AI最后却保不住自己的工作”这种想法。但冷静下来看这更像一次环境切换造成的能力错配而不是能力归零。大厂里的AI岗位往往依赖平台、依赖组织分工、依赖特定业务场景离开之后这些依赖全部失效但底层的方法论还在。AI领域变化非常快今天熟悉的大模型明天可能就被新的替代今天流行的框架后天可能就不维护了。真正能穿越周期的是面对一个不确定问题时不慌不乱的能力你能把它拆成问题定义、数据准备、模型选型、评估验证、部署监控、异常排查这些环节然后一步步推进。这个能力在大厂里能做离开大厂换一个环境同样能做。5.2 接下来最值得做的三件事如果你也处在类似阶段或者你还在职但担心将来会遇到同样的问题我最真实的建议是这三件事第一写一份“场景能力说明书”。不要按时间线写“某年某月在某公司做了什么”而是按场景写“我处理过什么类型的问题用了什么方法怎么验证遇到了什么坑。”这样的描述能帮助你把隐性经验显性化也能在面试或合作时快速说明自己擅长什么。第二搭一个最小AI工程闭环。选一个很小但真实的场景把数据、Prompt、模型调用、输出校验、日志、批量执行串起来。跑通之后把这个目录结构固定下来作为以后做新任务的模板。第三把一次排查经验写成文档。不用写成很长的教程哪怕只是记录一次“线上服务超时是怎么定位到输入类型错误”的过程也是在训练自己的排查思维。写出来的过程会逼你补上很多之前忽略的细节。最后我想说在亚马逊做AI的那段经历真正留给我的不是某个模型也不是某个内部平台的使用技巧而是一套把AI从想法变成稳定服务的工作流。平台会变公司会变模型会换但这套工作流只要持续打磨就能在下一个环境下继续发挥作用。这大概是我被裁之后最有价值的一个认知。