职业成长 on 姚玉亮的网络日志

我的 AI 时代后端工程师成长路线

Wed, 19 Aug 2026 10:30:00 +0800

问题背景

最近有几个刚工作两三年的后端朋友问我：AI 这么火，传统后端是不是要被淘汰了？要不要转算法？我自己这两年从宠物医疗 SaaS 走到企业级 AI 数据平台，又在业余时间开源了 alchemy-furnace，刚好完整经历了从"写 CRUD"到"做 AI 系统"的转变。这些路不一定适合每个人，但都是我真走过的。

第一阶段：把后端基本功打穿

AI 应用的后端依然是后端。模型推理只是其中一环，你还要处理认证、计费、并发、数据管道、可观测性、发布回滚。这些东西 LLM 帮不了你多少。

我在某 SaaS 公司那两年半，扎扎实实干了几件"不性感"的事：把宠物医疗 SaaS 系统从 fasthttp C/S 迁到 go-zero B/S，用 gRPC + Jaeger 做微服务拆分和链路追踪，对接 AI 影像判读接口。那时候没有 LLM 帮我写代码，gRPC 拦截器、服务注册发现、MySQL 分表、Redis 分布式锁，全是一行行啃文档啃出来的。

我的建议是：如果你工作不满三年，别急着追 AI，先把下面这些东西练到肌肉记忆：

一门主力语言到能读源码的程度（我是 Go，Gin、go-zero、Gorm、Wire 这些要知道它们怎么实现的）
MySQL 索引和事务、Redis 常用数据结构、MQ 的投递语义
一次完整的微服务拆分 + 链路追踪落地经验
容器化部署和基本的 Linux 排障

这些是你日后做任何系统的地基，AI 只会放大基本功的差距，不会抹平它。

第二阶段：主动靠近 AI 工程化

2023 年底我加入新团队，本来是做统一支付平台和统一认证中心这种传统后端项目，但我主动接了数据治理服务和数据集管理服务里和 AI 相关的部分。这是我职业路径上最关键的一个选择。

我的做法不是去学训模型（那是算法工程师的赛道，后端硬转性价比很低），而是切入模型和业务之间的工程层：

数据管道：S3 预签名上传、PDF 解析、Temporal Worker 数据质量规则引擎、MySQL + StarRocks 数仓、OpenAlex 数据同步。这些是典型的后端技能，但服务于 AI 数据。
向量和检索：文档解析后的向量化、知识图谱构建、向量库选型。不需要你懂反向传播，但要懂高并发、批处理、内存控制。
LLM 网关：知识库问答服务里做统一 LLM 适配层，屏蔽 OpenAI、Azure、VLLM、HuggingFace 的差异，做多模型路由、限流、降级、token 计费。这是后端最能发挥价值的地方。
Agent 和工作流：多轮对话、light_rag、MCP 工具调用、多步任务编排。这层需要理解 LLM 的能力边界，但工程骨架依然是状态管理、超时、重试、可观测性。

这个阶段我最大的体会是：AI 工程化的核心难点不是调模型，而是让模型在一个不可靠的世界里可靠地工作。超时、幻觉、上下文溢出、供应商限流，这些问题的解法全是后端老功夫。

第三阶段：用全栈能力闭环一个产品

只会写后端，在 AI 时代会有明显的瓶颈。AI 应用的交互形态变化太快，等前端排期你就慢了半拍。我从 2025 年开始刻意练全栈，用 Claude Code 和 Cursor 独立交付前端页面。

alchemy-furnace 是第一次完整闭环：Go（Gin + GORM）做网关和多供应商适配，Python（FastAPI）做合成引擎（Promptbreeder 变异算子 + 血统追溯），Next.js 做前端，一个人三周搞定。这个项目在 GitHub 拿到 46 star 不是因为代码多牛，而是它证明了一个后端工程师借助 AI 工具可以独立交付完整产品。

我总结的 Vibe Coding 心法是：

后端契约定死再做前端（你的优势就在这）
TypeScript strict 全开，类型从 OpenAPI 生成
UI 选 shadcn/ui 这种源码可控的库，AI 生成质量高
小步快跑，每生成一块就在浏览器验证，别攒着

第四阶段：建立技术判断力

工具和框架会一直换，真正拉开差距的是判断力。这几年我刻意训练自己几件事：

选型时看权衡而不是看热度。Go 和 Python 混部选 gRPC 还是 HTTP？Temporal 还是裸 goroutine？RAG 还是 Agent？每个问题都没有标准答案，要能说出在你的场景下为什么这么选。
踩坑后写下来。我保持写博客的习惯，不是为了当博主，而是把每次排障和架构决策的思路固化下来，下次遇到类似问题能快速调用。
读优秀源码。go-zero、Gorm、Wire、eino、Temporal 的 Go SDK，读下来比看十篇架构文章有用。
做开源。alchemy-furnace 逼我把代码写得陌生人能看懂、把文档写明白，这个过程对工程能力的提升比上班写业务代码快得多。

踩坑与提醒

别被"全栈"骗了。什么都懂一点但没有一项能打穿，不如先在后端深扎。全栈是放大器，基本功为零的时候放大的是零。
别迷信新框架。今天这个 Agent 框架明天那个 RAG 库，大部分过半年就没人维护了。理解底层原理（状态机、流式、序列化、并发控制）比记住 API 重要。
别丢掉对业务的理解。我在某 SaaS 公司学到的最重要的东西不是 go-zero，而是理解医院和医生怎么用系统。脱离业务的架构是自嗨。
照顾好身体。这行是长跑，不是冲刺。

小结

AI 时代的后端工程师不是要被淘汰，而是要往上走一层：从"实现需求"变成"把模型能力工程化、产品化"。路径说起来朴素：基本功打穿，主动靠近 AI 工程化，练全栈闭环，建立判断力。我自己也还在这条路上，希望两年后回头看，这篇文章里的判断依然站得住脚。

两年八个月后端架构演进：从 SaaS 到 AI 数据平台

Tue, 19 Dec 2023 10:30:00 +0800

把这两年的技术栈摊开看，进进出出的东西不少：go-zero、Wire、Temporal、Hertz、eino……每次变化，都不是我追着潮流去的，是业务把新问题拍在面前，接住，才有下一步。

从宠物医疗 SaaS 到中台，再到 AI 数据平台，两年八个月，大概走了三段路。

先给飞行中的飞机换发动机

2021 年 4 月我加入一家 SaaS 公司，接手的第一个大项目，是把宠物医疗 SaaS 从 fasthttp C/S 架构迁到 go-zero B/S。老系统是个迭代了很多年的单体，所有医院共用一套代码、一个数据库，发版靠手动 FTP，回滚基本靠运气。

迁移动作是先按业务域拆服务：医生端、医院管理、HIS 对接、AI 影像判读各自独立，服务间用 gRPC，Jaeger 做链路追踪。go-zero 的工具链帮了大忙，.api 文件直接生成路由和代码骨架，团队上手很快。同期还做了经营数据分析平台，加上 C 端顾客小程序和 B 端管理小程序，后端用同一套微服务撑住多端。

那阵子最大的收获其实不在某个技术点上。数据双写、灰度切流、老接口兼容，这些活儿教科书不教，但每天都在做。说白了，就是学着在不停机的前提下，给飞行中的飞机换发动机。

中台教会我的，是边界

2023 年 12 月，我加入一家科技公司，一开始主导统一支付平台和统一认证中心。这两个项目和 SaaS 时代最大的区别在于：它们不是单一产品，是要给多条业务线复用的中台。

统一支付平台做了三端分离支付、订单状态机、RSA/SHA 签名的 OpenAPI、动态计费引擎和对账导出。状态机是核心。一笔订单从创建到回调成功，可能经历十几次状态跃迁，任何一个分支没覆盖到，就是资损。我的做法是用显式状态机表加幂等键，把每条跃迁写死，不给隐式状态留活路；对账用 Excelize 导出，再和渠道逐笔比对。

统一认证中心是另一种复杂度：OAuth2/OIDC、RSA 签发 JWT、SSO、多应用 AppID/AppSecret、AppRole 团队隔离、RBAC，还要支持可插拔 Provider（腾讯云 SMS/SES/Captcha），以及微信、企微、飞书登录。我用 Wire 做依赖注入，Service/DAO 分层，最后的效果是新增一种登录方式，只需要实现一个 Provider 接口。

这个阶段，我的架构审美从"能拆就拆"转向了"该合就合"。中台的价值其实在复用，但过度抽象会把所有业务方绑死。

边界划在哪里，比用什么框架重要得多。

核心矛盾换成了长流程

从数据治理服务开始，工作的性质又变了。S3 预签名上传、PDF 解析、Temporal Worker 数据质量规则引擎、MySQL 加 StarRocks 数仓、OpenAlex 学术数据同步。这套东西的核心矛盾，不再是"高并发业务"，而是"长流程数据管道"。

Temporal 把我从手写状态机和重试里解放出来：Activity 失败自动重试，Workflow 状态持久化，比 go-zero 时代裸写 goroutine 加补偿逻辑稳太多。后来做数据集管理服务，Hertz 做接入，eino 和 pond 跑高并发的文档解析、向量化、知识图谱构建，存储用 GaussDB 和 MongoDB。那是我第一次认真处理 GPU/CPU 混合调度和大文件内存控制，好在 pond 的 worker pool 把并发度压在了下游能承受的范围内。

再往后是知识库问答服务，做企业级 LLM 知识库问答，问题又换了一茬：多轮对话、light_rag、MCP 工具调用、多模型路由。统一 LLM 适配层把 OpenAI、Azure、VLLM、HuggingFace 的差异屏蔽掉，业务侧只认一个 ChatCompletion 接口。我看着它从一个能跑的 DEMO，长成能接公司多个业务线的平台，中间踩的坑比前两年加起来还多。

没变的是这几件事

技术栈从 go-zero 扩到 Hertz、eino、Temporal，架构从微服务扩到数据管道和 AI 平台。但有几件事，从头到尾没变：

可观测性要先于功能。没有日志、指标、trace 的系统，跑得再快也不敢上线。
状态和边界是复杂度的根源。订单状态机、Temporal Workflow、Agent 多步任务，本质都是在管理状态跃迁。
选型服务于场景。gRPC 还是 HTTP、Temporal 还是裸 goroutine、RAG 还是 Agent，答案永远在具体场景里。
发布和回滚能力是底线。KubeSphere 容器化让发布效率提升约 80%，故障回滚在 5 分钟内，这比任何架构炫技都实在。

我没有刻意追过技术潮流，只是被业务推着走，遇到什么问题就解什么问题。回头看，真正的成长是面对一个全新领域时，能快速抓住核心矛盾，再用工程化的方式把它落地。

这条路还在继续。

封面图：M McBey / Flickr · CC BY 2.0