从二本到大厂：一个老广程序员的技术探索与实践之路
大家好，我是阿强，一个土生土长的广州老城区人，目前在一家一线大厂做Java后端开发。去年十月，我正式从一家本地小公司跳槽进了现在这家厂，月薪从15k涨到了22k——虽然在广州这个物价水平下，依旧要精打细算地过日子（天河租房3500，老婆刚怀孕，压力山大），但至少证明了，二本出身的我，也能靠技术逆袭。
今天想和大家聊聊一个老生常谈但又极其关键的话题：如何做技术探索与实践？
不是那种“看源码、刷LeetCode、读论文”的标准答案，而是我一路踩坑、掉头发、熬夜改bug后，真正摸出来的路子。尤其最近一年，我在技术选型上做了几次关键尝试，涉及 Spring Boot、通义千问、GPT-4o 这些工具，有些成功，有些翻车，但都让我成长了不少。
一、那个让我失眠的周五晚上
时间回到去年9月，还在前公司做“CRUD boy”的时候。那天是周五晚上9点，办公室只剩我一个人。项目又出问题了——我们用的老旧Spring Boot 2.3.x框架，配合一个自研的权限系统，每次上线都要手动回滚三次，测试环境和生产环境配置不一致，连日志都打不全。
我盯着屏幕，手边是已经凉透的肠粉（没错，加班吃肠粉是老广的倔强），心里特别烦。不是因为bug多，而是明明知道有更好的方案，却没人敢动。
领导说：“能跑就行，别折腾。”同事说：“你又不是架构师，操那么多心干嘛？”
但我心里清楚：如果一直这样，我可能永远只能拿15k，永远进不了大厂。
那晚回家，老婆看我脸色不对，问：“又加班？要不要煮碗云吞面？”
我摇摇头，坐在阳台抽了根烟，心想：技术这东西，你不主动探索，它就永远不会属于你。
二、第一次真正的技术探索：Spring Boot 升级实战
我决定从最熟悉的 Spring Boot 开始。当时我们用的是 2.3.12.RELEASE，而社区主流已经是 2.7.x 甚至 3.x。但升级不是简单改个版本号——依赖冲突、启动失败、JPA 变更、Actuator 路径变化……随便一个都能让你通宵。
我给自己定了个小目标：在不影响现有业务的前提下，把一个非核心模块升级到 Spring Boot 2.7.5，并引入新的健康检查和指标监控。
过程很痛苦。连续三周，我下班后留到9点，周末也泡在图书馆（对，老广程序员也爱去图书馆，不是只有咖啡馆）。我建了一个本地 Git 分支，一点点拆解依赖，用 mvn dependency:tree 看冲突，用 Postman 测试所有接口，甚至手动画了调用链图。
最崩溃的是，升级后 Redis 连接池突然报错，查了两天才发现是 Lettuce 的版本和 Spring Boot 内嵌的 Netty 不兼容。最后通过强制指定 spring-boot-starter-data-redis 的版本解决。
但结果是值得的。新模块上线后，启动速度提升了30%，内存占用降了15%，还集成了 Micrometer + Prometheus，老板第一次看到 Grafana 面板时，眼睛都亮了。
这次实践让我明白：技术探索不是“学新东西”，而是“用新东西解决旧问题”。
三、当 AI 工具开始走进我的开发流程
今年年初，我开始关注大模型。一开始只是好奇，后来发现它们真的能改变开发效率。
1. GPT-4o：写代码的“外挂大脑”
我最早用的是 GPT-4（通过某渠道），但今年5月 GPT-4o 发布后，我立刻切换了。为什么？速度快、上下文长、支持多模态（虽然我主要用文本），最关键的是——它能理解我“模糊的需求”。
比如上周，我要写一个 Excel 导出功能，包含合并单元格、样式定制。以前得翻 Apache POI 文档半小时，现在我直接问：
“用 Spring Boot + Apache POI 写一个导出方法，第一行是标题（合并A1:D1），第二行是列名，从第三行开始数据，标题背景色蓝色，字体加粗。”
GPT-4o 直接给我生成了完整代码，包括 @Service 注解、异常处理、文件流关闭。虽然有小 bug（比如没考虑空数据），但80% 的骨架都有了，我只需要微调。
当然，我也吃过亏。有一次让它写 Redis 分布式锁，它用了 SET key value NX EX，但没处理锁续期，导致线上服务卡死。从此我牢牢记住：AI 是助手，不是主力。你得懂原理，才能判断它对不对。
2. 通义千问：国产之光，适合中文场景
作为老广，我对“国产”有点天然好感。通义千问（Qwen）是我今年重点尝试的另一个工具。它的优势在哪？
- 中文理解极强：比如我问“Spring Boot 怎么处理跨域？”，它会直接给出
@CrossOrigin和全局配置两种方案，还附带 Nginx 配置示例。 - 代码生成更“接地气”：不像 GPT 有时会用一些冷门库，Qwen 更倾向推荐阿里系或国内常用方案（比如 Dubbo、Nacos）。
- 免费且响应快：我用的是 Qwen-Max，免费额度够日常使用，而且在国内访问飞快，不像 GPT 有时要等半天。
有一次，我让 Qwen 帮我分析一段慢 SQL：
SELECT * FROM order WHERE user_id = ? AND create_time > '2023-01-01' ORDER BY id DESC LIMIT 100;
它不仅指出缺少 (user_id, create_time) 的复合索引，还建议我改成 ORDER BY create_time DESC 以利用索引排序，避免 filesort。这种细节，很多初级 DBA 都会忽略。
但 Qwen 也有短板：英文文档理解不如 GPT，复杂算法题表现一般。所以我的策略是：中文场景用 Qwen，国际前沿技术用 GPT-4o。
四、技术选型对比：不是“哪个更好”，而是“哪个更适合”
很多人纠结“GPT-4o 和 通义千问哪个强？”，其实这就像问“Spring Boot 和 Django 哪个好”——没有绝对答案，只有场景适配。
我做了个简单对比表（基于我半年的使用体验）：
| 维度 | GPT-4o | 通义千问（Qwen-Max） |
|---|---|---|
| 中文理解 | 优秀 | 极强（更符合中文表达习惯） |
| 代码生成质量 | 高（尤其 Java/Python） | 高（偏爱国内技术栈） |
| 上下文长度 | 128K | 32K（Max版） |
| 响应速度 | 快（但需科学上网） | 极快（国内直连） |
| 免费额度 | 有限（需订阅） | 充足（阿里云账号即送） |
| 多模态支持 | 支持图片/语音 | 文本为主 |
所以我的结论是：
- 如果你在外企或做国际化项目，GPT-4o 是首选；
- 如果你在国内公司，用阿里云、Spring Cloud Alibaba，通义千问更顺手；
- 最好两个都用，交叉验证，避免被单一模型“带偏”。
五、从“用工具”到“建体系”：我的技术实践方法论
工具只是手段，真正的成长在于建立自己的技术探索体系。我总结了三点：
1. 小步快跑，快速验证
别一上来就想重构整个系统。像我升级 Spring Boot，只选一个非核心模块；用 AI 写代码，先从工具类、DTO 开始。最小可行实践（MVP） 是降低风险的关键。
2. 记录 + 复盘
我有个 Notion 笔记本，专门记录：
- 某次技术选型的决策原因
- AI 生成代码的错误点
- 性能压测数据对比 这些积累，面试时能说出“我为什么选这个方案”，比背八股文强一百倍。
3. 输出倒逼输入
我在公司内部做了两次分享：《Spring Boot 升级避坑指南》《如何用大模型提升开发效率》。准备过程逼我梳理逻辑，听众提问又暴露了我的知识盲区。教是最好的学。
六、写在最后：技术人的长期主义
有时候我会想，如果当年高考多考20分，进了985，是不是早就进大厂了？但转念一想，正是二本的“不被看好”，才让我更拼命地证明自己。
技术探索不是一蹴而就的事。它是在无数个加班的夜晚，在肠粉凉透的工位上，在老婆一句“要不要煮云吞面”的温柔里，一点点积累起来的。
现在我在大厂，依然每天学习。昨天还在研究 Spring Boot 3 的 GraalVM 原生镜像，今天用通义千问帮我写单元测试。我知道，技术没有终点，只有不断向前的路。
如果你也和我一样，普通学校出身，拿着不高的工资，住在老城区的出租屋里，但心里还有一团火——
别怕慢，别怕错，只要不停下，路就会越走越宽。
共勉。
—— 阿强，于广州荔湾，2024年6月
评论 0