工作十年小结：我曾经焦虑于“什么都会，但没有一项顶尖”
2022 年是，是我职业生涯里非常焦虑的一年。
那时我已经工作了六年。毕业以后，我先做了几个月传统运维，后来整个部门开始转型，逐步转向 SRE和DevOps，再后来换了工作，在新的工作中，由于项目的原因，又做了大约两年时间的 Web 全栈开发。
我带过一些项目，也带过规模不大的团队，但也不算真正意义上的管理层。
在技术上，我接触的东西很多，服务器、网络、容器、CI/CD、监控、云平台、Python、后端、前端。
但也正因为懂得多，我越来越难回答一个问题：与别人相比，我的优势是什么？我后面的职业路径是什么？
DevOps 和 Python 是我相对更深入的方向，但即使在这些领域，我也很难说自己是顶尖专家。至于其他技术，团队里几乎总能找到一个比我更专业的人。
有人比我更懂 Kubernetes，有人比我更懂前端，有人对数据库和中间件理解得更深，也有人在某个业务系统里积累了很多年。
如果把技术能力拆成一根根纵向的柱子，我似乎没有哪一根特别突出（DevOps 和 Python 应该算是还不错，但是估计也到不了行业顶尖的水平）。
那时的我，经常有一种说不清楚的危机感：
我好像什么都能做一点，但这种“什么都会一点”，究竟算不算真正的竞争力？我是不是应该考虑更加深入地去专研某一个方向？
这种焦虑并不完全来自技术。
当时我所在的团队原本比较稳定，但因为中美关系和公司战略调整，研发中心的重心准备逐渐迁往国外。很多事情突然变得不再确定。
组织会怎么调整，团队是否还会继续存在，我未来应该留在哪里，我这些年积累下来的经验到底有没有足够强的迁移能力，我都没有答案。
那时候，我已经不再是一个刚毕业、可以随便试错的年轻人了。但我也没有进入一个足够稳定、足够明确的位置。
我既不是某个领域公认的专家，也没有真正走上管理岗位。
我站在职业生涯的中间位置，向前看不清方向，向后看又觉得自己走了很多路，却没有形成一个足够鲜明的标签。
那些看起来有些“杂”的经历
后来再回头看，我发现自己以前对这几段职业经历的理解，其实是有问题的。
传统运维、SRE、DevOps 和 Web 全栈，看起来像几次方向变化，但它们并不是完全不相关的。
做传统运维的时候，我开始理解一个系统是怎么运行起来的。服务器、网络、进程、日志、部署，这些东西构成了软件运行所依赖的环境。
做 SRE 的时候，我开始关注系统如何长期稳定地运行。我需要考虑监控、告警、容量、可用性、故障恢复，以及线上事故发生以后，应该如何定位问题。
做 DevOps 的时候，我关注的是软件如何更高效、更可靠地交付。我开始理解研发流程、CI/CD、基础设施自动化，以及开发和运维之间的协作方式。
后来做 Web 全栈，我又补上了应用开发这一层。我开始更加直接地面对用户需求，理解前端、后端、API、数据库和产品功能之间的关系。
当时的我，总觉得自己在不断换方向。
但实际上，那些或主动或被动切换的岗位，是在一层一层地帮我补全对软件系统的理解。现在想想，我差不多经历了整个软件生命周期中所有的环节。
我不一定是每一层里最优秀的那个人，但我慢慢知道了这些环节是怎样连接在一起的。
我知道一个前端需求会如何影响后端接口，知道一个后端设计会如何影响数据库和缓存，也知道一个在本地运行良好的功能，到了生产环境以后，可能会遇到哪些稳定性、扩展性和可观测性问题。
我开始拥有一种完整的软件工程视角。
只是很长时间里，我没有意识到这是一种能力。
在一个高度分工的团队里，这种能力甚至不一定显得特别重要。
前端问题有前端专家，数据库问题有 DBA，平台问题有平台团队，线上故障有 SRE。组织越成熟，分工越细，一个人的价值就越容易通过某个专业方向来衡量。
在这样的体系里，广度有时反而容易成为一种尴尬。
你知道很多事情，但每一件事情似乎都有人比你做得更好。
ChatGPT 出现以后，很多东西开始改变
2022 年年底，ChatGPT 面世。
一开始，它更像是一个非常惊艳的新工具，可以回答问题、生成内容，也可以辅助写代码。
但随后的几个月里，更强的模型不断出现。再后来，Cursor 这样的 AI Coding 工具出现，模型开始真正进入软件开发流程。
我逐渐意识到，变化并不只是“写代码变快了”。真正重要的改变是技术能力的组织方式。
过去，一个人即使理解完整的软件架构，也很难独立完成一个复杂系统。因为从前端、后端、数据库到部署和监控，每一个环节都需要大量具体实现。
人的时间和精力是有限的。
你可能知道应该怎么做，但未必有时间把所有部分都做出来；你也可能理解某个方向的基本原理，但因为不熟悉具体框架和语法，实施成本依然很高。
AI 开始降低这种跨技术栈执行的成本。
它可以帮我快速理解一个陌生框架，可以生成基础代码，可以协助排查问题，也可以把我脑海中的架构设计更快地转化成可运行的实现。
而这时候，我过去那些看起来有些“杂”的经验，突然开始产生了新的价值。
因为我并不是单纯地让 AI 随机生成代码。
我知道一个系统大致应该如何拆分，知道前后端如何协作，知道什么时候需要缓存、消息队列或者异步任务，也知道系统上线之后应该如何部署、监控和排障。
AI 可以帮助我完成具体工作，但我可以判断它做得是否合理。
这两者结合起来以后，我发现自己能够做的事情比过去多了很多。
我不需要成为最优秀的前端工程师，才能完成一个可以使用的前端产品；也不需要熟记所有云平台配置，才能规划并部署一套完整的基础设施。
我只需要拥有足够的基础、足够完整的系统理解，以及判断一个方案是否正确的能力。
AI 会补足我在局部执行上的不足，而我过去积累的广度，则决定了我能不能把这些局部能力组合成一个完整系统。
那一刻，我第一次真正理解：
我过去的问题可能并不是“学得太杂”，而是当时的工具和组织方式，还无法充分放大我的这种能力结构。
AI 没有凭空创造我的能力，它重新定价了我的经验
当然，我并不想用今天的结果去美化过去的所有选择。
2022 年的焦虑是真实的。
在当时的技术环境和组织结构里，“广而不够深”确实可能是一种职业劣势。如果没有这一轮 AI 技术变化，我的能力结构未必能像今天这样得到放大。
所以我不能简单地说，我过去走的每一步都是正确的，只是当时没有被看见。
更准确地说，是新的技术范式重新定价了我的经验。
而我比较幸运，也比较主动地抓住了这个变化。
2023 年，LLM 开始快速发展的时候，我没有只把它当成一个聊天工具，而是开始持续关注它在开发和产品中的可能性，当时也做过几个小工具，比如利用 LLM 做预诊，帮助用户了解自己的症状，应该挂什么科室。还有一个是拍食物的配料表，然后分析配料表中的成分是否适合特定的人群食用，比如孕妇、幼儿等等。
到了 2024 年年初，Agent 逐渐成为一个重要方向，我也开始主动向 Agent 开发转型。2024年上半年我开始研究 AutoGen，并且制作了一些教程。
后来，我逐渐进入了现在的 Agent 开发岗位，也成为了 Tech Lead。
这对我来说，是一次很重要的职业转变。
它并不是因为我突然成为了某个模型或者框架的顶尖专家，而是因为 Agent 这个方向，刚好需要一种高度综合的工程能力。
一个真正能够上线的 Agent 系统，不只是调用一次大模型 API。
它需要处理工具调用、状态管理、上下文、Memory、异步任务、评测、可观测性、错误恢复、权限、部署和稳定性。
它既是一个 AI 问题，也是一个后端问题、架构问题和工程问题。
而我过去做过的 SRE、DevOps、Python 和 Web 开发，几乎都可以在这里重新连接起来。
以前，我的经历像是散落在不同地方的碎片。Agent 把这些碎片拼成了一张完整的图。
我开始重新理解什么是架构能力
过去，我可能会把架构能力理解成设计系统、画架构图，或者熟悉很多中间件。
但现在我越来越觉得，真正的架构能力并不是知道的技术越多越好，也不是设计得越复杂越好。
架构的本质是做判断。
面对一个模糊的需求，我需要判断它应该怎样被拆分；面对多个可行方案，我需要判断当前阶段应该选择哪一个；面对性能、成本、开发效率和稳定性之间的冲突，我需要做取舍。
我需要知道哪些复杂度是必要的，哪些复杂度可以推迟。
我也需要知道，一个在 Demo 阶段表现很好的 Agent，到了生产环境之后，为什么可能会因为延迟、幻觉、上下文膨胀、工具失败或者成本问题而无法使用。
AI 可以生成很多方案，但它不能替我承担选择方案之后的结果。
现在看来，我确实已经具备了相对完整的架构视角。
但是“懂很多技术”并不直接等同于“拥有很强的架构能力”。架构能力最终必须被结果验证。
我做出的关键决策，半年以后是否仍然成立？系统出现问题时，我是否真正考虑过它的故障原因？团队能否理解并维护这套设计？业务变化以后，架构是否还有演进空间？
这些问题，比我是否熟悉某个新框架更加重要。
AI 也可能掩盖我的短板
AI 放大了我的优势，但它也可能让我产生新的错觉。
因为有了 Coding Agent，我可以快速进入陌生技术栈，也可以在很短时间里完成过去需要很久才能完成的功能。
这种效率很容易让人误以为，自己已经真正掌握了所有相关领域。
但“能够生成代码”和“真正理解系统”仍然不是一回事。
AI 给出的方案有时看起来非常合理，甚至代码也能运行，但其中可能隐藏着并发、事务、安全、性能或者可维护性问题。
当一个系统还很小的时候，这些问题不容易暴露。一旦进入真实生产环境，最终仍然需要人的判断力兜底。
所以我不能因为 AI 降低了执行门槛，就放弃对底层能力的持续积累。
我不需要在所有领域都做到顶尖，但必须保留几根真正深入的能力支柱。
对我来说，这些支柱可能包括 Python 和后端工程、分布式系统与基础设施，以及 Agent 系统架构。
广度可以让我连接不同领域，但深度决定了我能不能识别那些看起来正确、实际上错误的答案。
如果所有人都拥有全栈能力，我还剩下什么
这是我最近一直在思考的问题。
今天，借助 AI，我可以完成过去需要多个角色共同完成的工作。但未来，越来越多优秀工程师都会拥有类似的能力。
当 AI 可以帮助所有人写前端、后端、测试和部署脚本时，“我能独立做出完整系统”本身，也可能不再稀缺。
那我的下一层不可替代性是什么？
我现在的答案是：
把一个模糊的 AI 产品问题，转化成一个可上线、可运营、可持续迭代的系统，并带领团队把它真正交付出来。
这已经不只是全栈执行能力。
它包含产品判断、架构判断和组织判断。
我需要知道用户真正的问题是什么，哪些地方适合使用 Agent，哪些地方普通工作流反而更可靠。
我需要在速度、成本、质量和稳定性之间做取舍，也需要让不同能力和背景的人能够围绕同一个目标协作。
最终，技术不是为了证明我懂多少，而是为了产生真实价值。
这也意味着，我下一阶段不能再只是不断追逐新的技术概念。
从 SRE 到 DevOps，从全栈到 LLM，再到 Agent，我已经证明了自己有较强的适应能力。
但适应变化并不是最终的护城河。
我还需要选择一个真正值得长期投入的问题，在上面连续积累几年。
它可能是 Agent 的 Memory 和 Context Engineering，可能是企业 Agent 的工具、权限和评测体系，也可能是长期陪伴式、多模态的 AI 产品。
只有通用能力，没有长期领域积累，我仍然很容易被下一轮技术变化重新推回原点。
通用架构能力决定了我的下限，而长期积累的领域认知，才可能决定我的上限。
我没有成为某个领域最顶尖的人
今天再回头看 2022 年，我依然能理解当时的自己为什么会焦虑。
那时的我想要找到一个明确的答案。
我希望自己能够成为某个领域最顶尖的人，或者获得一个足够清晰的职位和标签，从而证明这些年的积累没有白费。
但几年以后，我得到的答案并不是：
我终于在某一项技术上超过了所有人。
而是：
我终于找到了一种方式，把过去所有看似分散的经历连接了起来。
AI 没有凭空创造我的能力。
它只是让我过去积累的那些能力，第一次可以被同时调用。
传统运维让我理解系统如何运行，SRE 让我关注稳定性，DevOps 让我理解交付和基础设施，Web 开发让我接近用户和产品，Agent 则把这一切汇聚到了一个新的方向。
我曾经焦虑于自己什么都会，却没有一项顶尖。
现在我开始明白，职业竞争力并不一定来自某一项技能的绝对领先。
它也可以来自一种独特的能力组合：在几个关键领域拥有足够深度，同时能够理解完整系统，并在技术发生变化时，把过去的经验重新组合起来。
这并不意味着我已经找到了一个永远安全的位置。
AI 仍然在快速发展，我今天拥有的优势，也可能在几年以后变成基础能力。
但我不再像 2022 年那样，只是被动地等待环境给我一个确定的答案。
我开始知道自己应该继续积累什么，也开始知道，面对下一次变化时，我可以依靠的并不是某个具体框架，而是理解问题、做出判断和重新学习的能力。
从这个角度来说，那段焦虑并没有完全消失。
它只是慢慢变成了一种更清醒的动力。
我仍然会怀疑自己，也仍然会担心未来。但至少现在，我不再把“走过很多不同的路”看成一种缺陷。
因为正是这些路，让我拥有了今天看待完整系统的方式。
而我的下一段职业旅程，或许不再是寻找一个更锋利的技术标签，而是尝试成为这样的人：
面对一个复杂而模糊的问题，能够把它定义清楚、设计合理、可靠地交付出来，并最终让它产生真实价值。
写在最后
这篇文章的初稿来自我和 ChatGPT 的一次长谈。它 帮我整理了结构和表达，以及文章中大部分文字。但经历、判断和最终修改都来自我自己。有意思的是，这篇文章本身也印证了我想表达的主I：AI 没有替我经历这十年，只是帮我把那些一直说不清楚的经验，重新组织成了文字。