一、百度三年：在业务淬炼中建立技术深度
2020 年我以校招生身份加入百度 MEG（移动生态事业群），被分配到广告投放系统团队。坦率地说，入职第一年我写过不少"烂代码"——Spring Bean 循环依赖、大事务、缺乏异常处理的定时任务……但这些错误恰恰是我最好的老师。
百度对我影响最深的一件事是代码审查文化。在百度，每一个 MR（Merge Request）都需要经过至少两位资深工程师的评审，评审标准极其严格——不仅是功能正确性，还包括异常处理是否完备、日志是否规范、并发场景是否考虑、性能是否有隐患。我曾因为一个 MR 被 review 了 17 轮，当时觉得痛苦，但现在回头看，这种近乎苛刻的代码评审是建立工程素养的最快途径。
入职第二年，我独立负责了广告预算检查模块的重构。这个模块原本是一个 3000 行的 God Class，我花了两个月的时间将其拆分为 12 个职责清晰的 Service 类，引入了策略模式处理不同广告主的预算规则。重构后模块的单元测试覆盖率从 15% 提升到 85%，线上故障率降低了 90%。这次重构让我第一次真正理解了设计模式不是书上的理论，而是解决实际问题的工具。
第三年，我获得了百度 MEG 最佳新人奖。回看这段经历，我认为能在百度快速成长的关键因素有三个：
- 主动承担有挑战性的任务：不要等待分配，主动去认领那些"别人不想做"或"没人敢做"的需求。
- 善用源码阅读建立深度：遇到框架层面的问题不要只看文档，直接读源码。我对 Spring 事务管理、MyBatis 插件机制、Netty 事件循环模型的深度理解，都来自于阅读源码。
- 保持技术输出：每周写一篇技术笔记，不仅巩固了知识，还让我在团队中建立了技术影响力。
二、架构思维的养成：从"能跑"到"跑得好"
从百度到蚂蚁的过渡期，我面临的最大转变是思维模式的升级。在百度的前两年，我的关注点是"把功能做出来"；到了第三年，我开始关注"做得好不好"；到了蚂蚁之后，我需要思考的是"为什么这样做"以及"未来三年会怎样"。
架构思维的养成，我总结了几个关键的转折点：
第一个转折：经历一次严重的线上事故。那是在百度第二年，我负责的预算检查模块因为一个边界条件没有处理好，导致某大客户在凌晨广告投放超出了日预算限制，直接造成约 50 万的损失。事后复盘，我深刻认识到：在金融和广告这种涉及资金流的系统中，正确性永远比性能重要。从那以后，我在写任何代码之前都会先思考：这个操作失败会怎样？回滚逻辑对不对？幂等性保证了吗？
第二个转折：主导分账分成引擎的设计。这是我在百度期间参与的最复杂的系统设计。面对日均数亿笔的分成计算、跨多个业务线的资金流转、复杂的分成规则引擎，我第一次需要从全局视角思考系统架构——如何做服务拆分、如何保证数据一致性、如何设计可扩展的规则引擎、如何做灰度发布。这个项目让我完成了从"执行者"到"设计者"的角色转变。
第三个转折：加入蚂蚁后的视野拓展。蚂蚁的技术体系与百度有很大不同——更强的金融合规要求、更复杂的分布式事务场景、更严格的容灾标准。在蚂蚁，我接触到了大规模的分布式系统设计模式，包括 TCC 分布式事务、Saga 编排、多活容灾等，这些经验极大丰富了我的架构工具箱。
三、AI 时代的转型：拥抱变化而非恐惧变化
2024 年，大模型技术的爆发给整个技术行业带来了巨大的冲击。作为一名后端工程师，我最初也有过焦虑：AI 会取代我的工作吗？但这种焦虑很快就转化为行动——我开始系统性地学习 LLM 相关技术，从 Transformer 架构到 Prompt Engineering，从 RAG 到 Agent 框架。
我的策略是将 AI 能力嫁接到已有的业务经验上，而不是从零开始转行做算法。具体来说：
- MCP + 对账系统：将我对商户对账业务的理解与 MCP 协议结合，构建了 AI 驱动的智能对账系统。
- Agent 编排：利用 AI Agent 的推理能力增强传统规则引擎，处理长尾异常场景。
- 工程化落地：把 AI 模型的调用封装为标准的 RPC 服务，做好限流、熔断、监控，让 AI 能力像普通微服务一样稳定可靠地运行。
回顾六年的技术成长之路，我最深的感悟是：技术人的核心竞争力不是某项具体的技术栈，而是快速学习和深度思考的能力。框架会过时，语言会迭代，但理解问题本质、系统性解决问题的能力是持久增值的。
给年轻工程师的建议：不要急于追风口，先在自己的领域做到足够深。只有当你对某个领域有了足够的深度，你才能在遇到新技术时，快速判断它在你的领域中的价值和应用场景。深度的积累需要时间，但这份积累会让你在未来的任何技术变革中都有清晰的判断力和快速的上手能力。