收到裁员通知那天，我正盯着一行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(f"task={task.id} status=success result={result.metrics}") save_result(task.id, result) except Exception as exc: logger.error(f"task={task.id} status=failed 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从想法变成稳定服务的工作流。平台会变，公司会变，模型会换，但这套工作流只要持续打磨，就能在下一个环境下继续发挥作用。这大概是我被裁之后，最有价值的一个认知。
 _视觉语言导航介绍)
