从传统后端到 AI 工程化：我的六年踩坑复盘

写这篇文章之前犹豫了很久——怕被说”凡尔赛”或者”成功学”。但想了想，简历上罗列的项目和文章里干巴巴的”问题 → 解决”，其实不能完整说明一个人是怎么走过来的。这篇文章试着把那些简历和文章里不会写的东西记下来，包括走错的弯路、推翻过的方案、深夜 debug 的崩溃时刻。

一个不太体面的起点

我 2020 年底入职腾讯无线大连研发中心的时候，简历上写的是”熟悉 Spring Boot、MyBatis”，实际上对大厂那套工程化流程是两眼一抹黑的。第一次 code review 被打回来 30 多个 comment，包括命名、异常处理、日志格式、单元测试覆盖率——每个我都觉得”不至于吧”。

那段时间最大的心理冲击不是技术本身，是发现自己之前在小公司积累的”工程化”标准，在大厂眼里根本不达标。这种感觉挺打击自信的，但反过来也让我开始认真对待”工程”这两个字。

2020 - 2022：腾讯，安全中心，做自动化测试和安全运营

这是我的第一个正经后端岗位，做了两个项目：

优测自动化测试平台：Golang（Beego）为主，混着 Java（Spring Boot）和 Python（uiautomator/Selenium）。我负责部分自动化测试能力 + 部署优化
腾讯 SOC 安全运营中心：Golang（Gin）为主，做工单模块后台。我独立负责这个模块的需求、设计、核心实现

这段经历教会我的事：

多语言混用是真正常态。一个项目里同时用 Go、Java、Python 是非常常见的，不要有”语言鄙视链”
接口设计能力比实现能力重要。工单模块的接口设计我改了 3 版，每次都被业务方吐槽”这字段为什么放这里”
企业级系统的”业务脏”是真实存在的。很多字段名和逻辑都是历史包袱硬凑出来的，新人接手时一定会有”这写的什么玩意儿”的感觉——别急着重构，先理解为什么这么写

我犯过的错：第一次做性能优化，我把一个查询改了用缓存，结果上线后第二天 P99 反而变高了——因为缓存 key 设计错了，导致缓存命中率只有 30%，大部分请求都”双查”了数据库。这个错误让我明白：性能优化必须看监控数据，不能拍脑袋。

2022.06 - 2023.06：品高软件，云架构产品部

离开腾讯后我去了一家做私有云的公司（广州市品高软件），参与品高云 Stack 超融合私有云平台从 0 到 1 的建设。

这段经历对我来说有点像**”回到基础”**。云平台底层不像业务系统那样试错成本低——你写错一个 libvirt 调用，可能直接把客户生产环境的虚拟机搞挂。所以这一年里我养成了一个习惯：每个 API 都要考虑幂等性、回滚路径、操作审计。这个习惯后来在所有后端项目里都帮了我大忙。

技术栈上深入了 KVM、QEMU、Libvirt、etcd、Ceph 这些”老牌基础设施”。最深的感受是：底层技术的学习曲线是陡的，但一旦掌握就是一辈子的能力——这些技术十年没变过，比前端那种”三年一大变”靠谱多了。

这段经历里我最大的反思：

当时我以为”做底层”很牛、很有技术含量。回过头看，底层只是”难”，不是”价值高”。真正有价值的是”用底层技术解决业务问题”。这一年让我对”做技术为了什么”有了更清醒的认识。

2023.06 - 现在：金建数字城市，基础研发部，架构师

这一段是我变化最大的阶段。入职时公司是二十多个 .NET 单体系统、各自为政，每个新项目都要重复造轮子。我的核心任务是：把整个公司的技术底座统一起来。

主导的事情包括：

Aone 统一集成平台：统一认证、RBAC、多租户、菜单集成、主数据同步、轨迹数据、文件管理、定时任务、消息通信
技术栈全面国产化：信创环境、Kingbase 数据库、国产化操作系统适配
云原生转型：从虚拟机部署迁移到 Docker + K8s/K3s
.NET 老系统接入：写适配层让 Spring Cloud 能调用老的 WebService（这部分工作量巨大但很少被外人看到）

最累的不是写代码，是和 20 多个团队沟通。每个团队都觉得自己系统最特殊、最不能改。我当时一度想做”大而全”，第一个版本做了 80 多个模块，结果 60% 没人用。后来砍到 30 多个核心模块，反而每个都做得更扎实。

我犯过的错（这次更大）：

一开始想”统一所有菜单”——结果发现每个业务系统的菜单结构差异巨大，强行统一会让所有人都觉得别扭
早期过度设计”多租户”——后来发现有些客户根本不需要多租户，过度设计反而引入了大量复杂度
国产数据库适配”想一次搞定”——实际上 Kingbase 和 MySQL 的 SQL 方言差异在 JOIN 顺序上做了大量 bug fix

这段经历教会我的事：

企业级平台最难的不是技术选型，而是”老系统怎么和平共处”。你用再新的技术栈，碰到二十多个跑了好几年的老系统，也得乖乖写适配器
“统一”这件事要克制。80 个模块 vs 30 个模块，后者更可能被用起来
架构的本质是组织问题。系统的边界往往反映了团队的边界，强行打破组织边界做技术统一基本都会失败

2024 年开始：AI 这条线

大约 2024 年中，我开始把一部分精力放到 AI 应用上。最早是好奇——大模型这么火，到底能干啥？

一开始我和很多人一样，调 API、跑 RAG 教程、用 Dify 搭 workflow，感觉”也就那样”——Demo 跑得通，但离生产差十万八千里。

转折点是公司真的需要”气量智能问数”这个功能：客户问”上个月这个区域的用户数”这种问题，每个项目都要定制开发。老板问我”能不能用 AI 搞定？”

我接了这个活，做了大概 3 个月，最后交付的是：

基于 Dify 编排的 AI 问数 Workflow
LangChain 封装动态 Schema 接入、字段查询、SQL 执行工具
业务表关系抽取 + 字段注释 + 同义词库
SQL 校验、执行、错误反馈、自动重试机制
权限控制（AI 只能查当前用户有权限的表和行）

这个项目让我第一次真正理解了**”企业级 AI 应用”和”Demo 级 AI 应用”的区别**。

Demo 和生产的真实差距：

Demo 里一句话问、模型答、看起来很美好
真实场景里要面对数据权限、业务语义、SQL 安全、错误重试、性能稳定性这一堆工程化问题
几百万 token 训练成本的模型，被一条 5 行的脏数据搞崩，是真实会发生的事

AI 时代我看到的几个误区：

“AI 让业务人员不用懂技术” —— 这是宣传话术。真实情况是”业务人员还是要懂业务、还是要能描述清楚问题”。我们的项目能做到的是”让 80% 的常规问数需求不用再提单”，剩下 20% 还是要人介入
“AI 工程师 = 会调 API” —— 这种人现在一抓一大把。真正稀缺的是”能用工程方法把 AI 稳定落地”的人
“大模型能解决一切” —— 在结构化数据查询、SQL 生成这种场景，AI 确实有用；但让它去做”复杂业务决策”还是不靠谱

关于成长方法论的一些真话

网上各种”AI 转型指南”很多，我自己也看过不少。说说我自己真正试过、觉得有用的：

“广度打底，深度聚焦”是空话。实际操作中你是被工作驱动的——当前工作需要什么，你就得学什么。所谓的”主动规划”在打工人身上基本是奢侈品
“输出倒逼输入”是真的。我写文章的每个字都会去查证、写 demo、跑一遍、踩一次坑。这比单纯看书快多了
“问题驱动学习”也是真的。但要注意——你解决的问题必须是有反馈的（线上问题、客户问题），不是自己造的题目
别迷信”技术品味”。工作里能用的技术就是好技术，”不优雅”但能跑、能在 3 天内上线，比”优雅”但要重写 2 个月强 100 倍

一些不那么好听的反思

写了这么多成长的东西，最后说几个不那么正面的：

年龄焦虑是真实存在的。我 30+ 了，AI 时代每天都有新东西出来，跟不上是常态。唯一的解法是承认”跟不上”是正常的，把精力放在”我能学什么”而不是”我学不会什么”上
“转型”不是单向的。我 6 年间从 Java → Go → 云原生 → AI，每次都是”在上一段积累上加一点新东西”，不是”扔掉旧的换新的”。所以别听那些”AI 时代后端开发要被淘汰”的说法——那是吓你的
个人技术品牌不是目的。我写博客、做项目，最初是给自己做笔记 + 找工作时有个东西可以展示。真不是为了”打造个人品牌”——那个听起来就累

给同样在转型路上的人

如果你是 Java/Go/云原生背景，最近在考虑要不要转 AI 方向，我的建议是：

别转行，延伸能力栈。你过去积累的工程素养不是负担，是你最硬的差异化壁垒
从自己的业务出发。在公司内部找有没有可以用 AI 改进的场景，做一个真实的小项目比刷 10 个教程有用
学 Dify + LangChain 这种工程化框架。别只盯着模型本身，模型的进化速度会远超你的学习速度，能”用好模型”比”训练模型”更稳定
保持学习习惯，但接受”学不完”的现实。AI 领域每周都有新论文，但 90% 不会进入生产

最后：别相信”30 天转型 AI 工程师”那种课程。能 30 天转的，也一定是被快速淘汰的。