从设计转码到海外工程师：职业选择的“兴趣 × 能力 × 价值”
Aug 18, 2025
Date
Aug 18, 2025
Slug
design-to-swe-career
Author
Status
Published
Summary
Type
Post
Thumbnail
Tags
🤔 Thinking
2025 年参加她行的软件工程分享时，有朋友问我，软件工程师应该怎样规划职业路径，又该怎样面对年龄和 AI 带来的不确定性。
这些问题也让我重新回看自己的选择。从设计转到软件工程，再到新加坡读 AI 硕士、毕业后做业务研发，我并没有在一开始就想清楚每一步。更多时候，是先去尝试，再从具体的体验里判断：哪些事我喜欢，哪些事我做得好，哪些事值得继续投入。
刚工作一年多时，我在工程师在业务中的成长里写过对业务研发的疑惑。这次想从自己的经历出发，补充一些后来逐渐想清楚的事。
从喜欢设计，到发现自己更适合软件工程
大学最初选专业时，我读的是设计。学校的设计专业很强，我也喜欢设计，但真正开始学习后，才发现喜欢和擅长并不是一回事。和有美术背景的同学相比，我在想象力和创作表达上没有那么突出，成绩也不理想。
反倒是在数字媒体、硬件编程等课程里，我意外发现了自己对代码的兴趣。之后，我转到了软件工程专业。
从学校的优势专业转出去，当时也面对了一些不理解。但转专业之后，学习本身给了我很直接的反馈。我喜欢从零开始做一个软件，喜欢从系统设计到最终实现的过程，也喜欢看到自己的想法变成真正能运行、能使用的东西。
本科期间，我也经历过卷绩点、做科研、参加竞赛和实习，以及考虑保研还是出国。对我来说，这些尝试最大的作用，是让我逐渐知道自己在哪种环境里更有动力。面对科研时，我容易感到畏惧；在公司实习时，却更容易通过解决问题获得正反馈，建立自信。把想法落地成实际应用的那段时间，常常是我觉得过得最快、也最享受的。
本科毕业后，我去了新加坡读 AI 方向的授课型硕士。当时既有家人的建议，也有我自己对这个方向的兴趣。读完之后，我更确定，比起纯粹的研究，我更享受把技术用到实际业务中的过程。毕业后，我选择了开发岗位，在新加坡做客户端和前端相关的业务研发。
回头看，正是这些不同方向的体验，让我对自己的选择更有把握。
业务研发的价值，不能只用技术门槛衡量
刚入行时，我也受到过“技术鄙视链”的影响：算法比开发好，后端比前端难，基础架构又比业务研发更有技术含量。按照这套标准，我做的工作似乎没有那么值得期待。
我在早先那篇文章里写过这些担心：业务需求的技术挑战是不是不够？长期做一个细分模块，会不会缺少可迁移的能力？如果每天都在做需求，成长究竟发生在哪里？
工作之后，我逐渐发现，只用技术难度衡量岗位价值，实在是太单一了。
在我的工作体验里，业务团队不一定经常有机会研究某个底层技术问题，却需要持续判断，怎样的技术投入才能解决产品眼下的问题。我们离用户和业务反馈更近，也更容易看到需求背后的痛点。一个方案能不能支持后续迭代，改动会不会给其他模块带来风险，投入的时间是否值得，这些都需要工程师参与判断。
以前我用“造轮子”和“选轮子、组装轮子”来区分技术团队与业务团队。这个比喻并不完全准确，但它帮助我理解了两种工作的侧重点。前者可能更强调某项技术本身的深度，后者则要求我们了解不同方案的适用条件，再结合业务做取舍。
业务研发当然也需要技术深度。只是这份深度最终要落到具体问题里：为什么这样设计，解决了什么，又为此承担了哪些成本。
对于喜欢产品、愿意理解用户和业务的工程师来说，这是一条可以持续投入的路径。随着经验积累，也可以向 Tech Lead 或业务负责人的方向发展。但它是不是适合自己，仍然需要回到日常工作中去体会。
可迁移的能力，藏在具体工作的过程里
刚开始工作时，我很担心自己积累的只是某个业务的知识，离开团队后就没有用处了。
后来我才逐渐区分开：熟悉一个模块的细节，和具备处理一类问题的能力，并不是同一件事。具体业务可能会变，但理解需求、拆解问题、设计系统、识别风险，以及和不同角色沟通的经验，可以在新的环境里继续使用。
这也意味着，做完一个需求之后，我需要多问自己一步：这次到底积累了什么？是更熟悉了一套代码，还是对系统之间的依赖有了更清楚的认识？是按时交付了任务，还是学会了更早发现风险、让协作更顺畅？
成长有时并不会因为工作年限增加就自然发生。我需要先知道自己想补足什么，再主动寻找能练习这部分能力的事情。公司的任务和评价可以提供参考，但不能完全代替我对自身成长的判断。
面对 AI，我更关心怎样把它用进自己的工作
分享时，大家也很关心软件工程师会不会被 AI 取代。我没有一个关于未来岗位的确定答案，也不觉得现在就能列出一份永远不会被替代的能力清单。
对我更有帮助的问题是：AI 已经可以做什么？我怎样把它用到自己的工作里？在它提供帮助之后，还有哪些判断需要我自己完成？
比如技术调研时，AI 可以帮助整理几种方案及其优缺点。但把方案放到具体业务里，仍然需要核实它的前提：团队有没有维护能力，现有系统能不能兼容，业务是否真的需要这份扩展性，以及我们能接受多大的风险。
这些判断会随着工具发展继续变化。我想做的是，在使用工具的同时，加深自己对问题的理解，并对最后的选择负责。
这也让我不那么执着于寻找一个“不会被淘汰”的方向。比起不断被新名词推着走，我更想先弄清楚自己要解决什么问题，再决定哪些工具值得学、怎样学。
兴趣、能力和价值，需要放在一起看
如果回到刚入行的时候，我希望自己更早意识到，职业选择需要同时考虑兴趣、能力和价值。
兴趣是我愿不愿意持续花时间做这件事；能力是我能不能把它做好，以及是否愿意为此继续练习；价值则既包括这份工作有没有实际需求和合理回报，也包括我自己是否认可它。
这三个问题很难在选择之前全部回答清楚。对我来说，设计、软件工程、AI 课程和实习，都是逐渐认识自己的过程。先有一些体验，才知道哪些喜欢可以留在生活里，哪些喜欢适合作为每天投入的工作。
如果没有条件把所有方向都试一遍，也可以从已有积累出发，寻找和目标岗位的结合点。一次选择不必意味着推倒重来，过去学过的东西也未必只有在原来的专业里才有价值。
我私下是个喜欢宅着、玩游戏的人，但在做自己感兴趣的软件工程工作时，可以有很高的投入度。所以直到现在，我依然觉得兴趣很重要。它让我在遇到困难时，还愿意多花一点时间把问题想清楚。
当然，兴趣并不能消除工作中的所有消耗，专注也不意味着一直沿着原路走。我希望自己既能对一个方向有耐心，也能定期看看：现在做的事情，是否还在让我接近想成为的那种人。
我的职业选择没有一个特别戏剧化的转折。它更像是在一次次尝试和反馈里，慢慢确认自己适合什么，再为自己的判断负责。未来还会有新的变化，但至少现在，我更清楚自己为什么选择软件工程，也更知道该把精力放在哪里。