夜雨聆风如果只看履历，我其实不算是一个“很容易焦虑”的开发工程师。
本科毕业于山东大学软件工程专业，后来去新加坡国立大学读了智能系统硕士。硕士毕业后，我加入携程做了两年半的软件开发，之后又去了支付宝，担任高级软件开发工程师，继续做了两年左右。
过去几年，我的工作主要集中在一个相对垂直但又非常核心的方向：支付、结算、清分、账务和资金系统。
现在，我继续深耕在 Web3 领域，做的事情也仍然和资金流、清结算、交易链路有关。
按理说，这样的经历看起来还算稳定：有计算机背景，有大厂经历，也有金融支付相关的业务积累。
但最近这一年，我越来越明显地感觉到一件事：
AI 时代来了以后，软件开发工程师原来的职业安全感，正在被重新定价。
这个感受不是突然冒出来的。
它来自很多很具体的瞬间。
比如以前写一个接口，需要先看需求文档，再建表、写 DTO、写 Controller、写 Service、写 Mapper、补单测、改联调问题。
现在你把上下文和表结构给 AI，它很快就能生成一个七七八八的版本。
再比如以前一个 SQL 写得慢一点、单测补得少一点、文档写得糙一点，大家会觉得这是开发工作的一部分。
但现在 AI 可以帮你优化 SQL、补测试用例、生成接口说明，甚至把异常日志解释得像一个耐心的同事。
这些变化刚开始会让人觉得很爽：
太好了，终于不用写那么多重复代码了。
但爽完之后，另一个问题就来了：
如果这些事情 AI 都能做，那我未来的价值到底在哪里？
我身边很多开发同学也在聊类似的问题：
AI 都已经能写代码了，传统 Java 开发以后还有机会吗？
这个问题并不夸张。
以前我们觉得，一个后端工程师的核心竞争力是：熟悉 Spring、MyBatis、Redis、MQ、分布式事务，能按时把需求做出来，能排查线上问题，能撑住高并发。
但现在，AI 正在快速接管其中一部分工作。
所以我最近一直在想：
软件工程师是不是没有机会了？
我目前的阶段性答案是：
软件工程师不是没有机会了，而是机会正在换位置。
未来值钱的，不一定是“最会写代码的人”。
而是：
最懂业务问题，并且能用 AI 把业务问题系统化解决的人。
这也是我最近开始认真思考转型，并尝试做一个“资金流异常分析 Agent”的原因。
一、先承认一个现实：只会写业务代码，会越来越危险
我觉得很多开发同学的焦虑，其实不是空穴来风。
如果一个人的主要工作价值是：
接需求； 写 CRUD； 调接口； 改字段； 写简单 SQL； 写重复性的业务代码； 按产品文档把页面、接口、流程串起来；
那这类工作的价值，确实会被 AI 持续压缩。
举个很普通的例子。
产品说要新增一个“订单备注”字段。
以前这可能意味着：
表里加字段； DTO 加字段； 入参出参加字段； 后台页面展示； 导出 Excel 加一列； 联调一下前端； 补几个简单测试。
这种需求当然也要认真做，但本质上它并不难，难的是细节多、链路长、容易漏。
过去这类工作需要开发花时间一点点补齐。
但现在，有了 AI 之后，只要上下文给得足够清楚，它可以非常快地帮你生成大部分代码。
你真正要做的，变成了检查：
字段有没有加全； 是否影响历史数据； 是否需要兼容老接口； 是否有权限控制； 是否影响导出性能； 是否会破坏原来的业务逻辑。
这时候你会发现，单纯“写代码”这件事的价值在下降，而“判断这个改动在系统里是否安全”的价值在上升。
再比如一个普通列表查询需求。
以前开发的工作是写查询接口、分页、筛选条件、排序、权限。
现在 AI 可以帮你快速生成接口骨架，甚至连常见的分页查询都能写出来。
如果你的价值只停留在：
我能把这个接口写出来。
那确实会越来越危险。
因为 AI 也能写，外包能写，新人照着模板也能写。
公司自然会重新评估这类工作的价值。
这不是说开发工程师马上会消失，而是说“普通业务代码生产力”正在变得越来越便宜。
以前公司需要很多人来堆代码量。
以后公司可能更需要少数人来定义问题、拆解系统、检查 AI 输出、把控质量。
所以，真正危险的不是 AI 会写代码。
真正危险的是：
我们的价值只停留在“写代码”这一层。
这也是很多传统 Java 开发工程师焦虑的根源。
不是大家突然不努力了，而是原来的能力模型正在被重估。
二、但这不代表开发工程师没有机会了
我反而觉得，AI 时代会让另一类工程师变得更值钱。
什么样的人？
不是单纯会背八股的人。
也不是只会调 AI 写代码的人。
而是：
懂系统、懂业务、懂数据，并且能用 AI 改造工作流的人。
这里我举一个更贴近后端日常的例子。
线上有个订单状态异常。
用户明明支付成功了，但是订单页还是显示“处理中”。
这时候你让 AI 帮你写代码，它可能很快。
但真正的问题不是写代码。
真正的问题是：
支付系统到底有没有成功？ 订单系统有没有收到回调？ MQ 消息有没有丢？ 消息有没有重复消费？ 订单状态机是不是卡在了中间态？ 有没有补偿任务？ 补偿任务有没有执行失败？ 如果手动改状态，会不会导致重复发货或重复入账？
这些判断，AI 不是完全不能帮忙，但它必须站在真实上下文之上。
如果一个工程师不理解系统，只是把日志贴给 AI，然后问“怎么修”，那很容易得到一个看起来合理、实际很危险的答案。
尤其在资金系统里，这种风险更明显。
比如一笔钱没有到账，你不能简单说：
那就重新发起一次划账吧。
因为你还要判断：
上一次划账到底有没有扣款成功？ 目标账户有没有入账失败？ 是否存在幂等键？ 是否可能重复入账？ 是否需要人工对账？ 是否需要冻结后续操作？ 是否有补偿流水？
这类判断，背后是业务经验，不只是代码能力。
AI 可以帮你写一段代码，但它很难凭空知道：
这段代码在真实资金链路里会不会造成资损。
这就是业务工程师的价值。
在 AI 时代，普通代码会越来越便宜，但复杂业务判断会越来越重要。
很多开发同学会觉得：
那我是不是应该马上去学大模型、学训练、学推理框架？
不一定。
如果你本来就有算法、模型、Infra 背景，当然可以往更底层走。
但对大多数传统开发工程师来说，更现实的一条路可能是：
不要抛掉原来的业务，而是用 AI 放大原来的业务经验。
你过去几年做过的订单、支付、库存、营销、物流、财务、风控、结算、对账，其实都不是废掉的经验。
恰恰相反，这些经验可能会变成你在 AI 时代的护城河。
因为模型大家都能用。
但业务现场的理解，不是每个人都有。
三、AI 时代，后端工程师正在走向两条路
我现在越来越觉得，传统开发工程师接下来会分化成两类。
一类是继续停留在“业务代码执行者”。
另一类是升级成“业务问题解决者”。
如果画成图，大概是这样：
【此处插入图 1：AI 时代，后端工程师的两条路】
图注：AI 时代，后端工程师的价值分化越来越明显：一类继续停留在“业务代码执行者”，另一类则升级为“业务问题解决者”。
第一条路，是继续只做业务代码。
这种路径短期看起来最熟悉，也最安全：
产品给需求； 我来写接口； 测试提 bug； 我来修； 上线出问题； 我来查日志。
这条路以前没问题，因为公司确实需要大量人力去完成这些工作。
但现在不一样了。
比如测试提了一个空指针 bug，AI 可以很快帮你定位可能的原因。
比如要补一个接口文档，AI 可以根据代码生成。
比如一个简单接口要改字段，AI 可以快速给出修改点。
这些不是说 AI 完全取代你，而是说它会压缩你在重复性事务上的时间。
如果一个人长期只做这类事情，他的不可替代性会越来越弱。
第二条路，是懂业务，并用 AI 重构工作流。
举个例子，同样是处理线上问题。
第一类工程师的做法是：
出问题了，我去查日志、看数据库、问上下游、手动拼链路。
第二类工程师会进一步想：
这类问题是不是经常出现？每次排查是不是都要查同几张表？判断异常是不是有固定规则？能不能做一个工具，把这些排查步骤自动化？能不能让 AI 根据证据自动生成排查报告？
这时候，你做的就不只是开发。
你是在把业务经验产品化。
这类能力，在 AI 时代反而更有价值。
因为 AI 越强，越需要有人告诉它：
什么是正确的问题，什么是可靠的判断，什么是不能越过的边界。
四、我自己的选择：从支付清结算切入
我自己的背景，是支付清结算和资金系统。
这个方向听起来可能有点“传统”，没有大模型、AIGC、智能体这些词那么性感。
但我越做越觉得，这里面有很多 AI 可以放大的地方。
比如在资金系统里，经常会遇到类似问题：
商户说钱没到账，到底卡在哪一段？
这不是简单查一个订单状态就能回答的。
一笔资金可能经历：
支付； 清分； 结算； 划账； 账务； 账户余额变动。
每一段都有自己的状态机、流水表、金额字段、失败原因和补偿逻辑。
以前排查一个类似问题，可能是这样的：
客服说：“商户反馈钱没到账。”
值班同学先问订单号。
然后开始查支付订单，发现支付成功。
再查支付流水，看看有没有触发清分。
再查清分表，确认清分是否成功。
再查结算单，看有没有生成结算账单。
再查划账流水，看是否扣减成功、入账成功。
如果是走账务路径，还要继续查账务订单和账户流水。
查到最后，可能才发现：
原来不是支付失败，也不是清分失败，而是账务入账还停在处理中。
这类排查，老同学可能 10 分钟能定位。
新人可能半小时还不知道下一张表该查什么。
更麻烦的是，很多时候问题不在“查不到”，而在“不知道查到的状态代表什么”。
比如：
这个状态是失败，还是处理中？ 这个处理中多久算正常？ 这个失败会不会自动重试？ 这个成功是否真的代表到账？ 这个金额差异是手续费，还是异常？
这些判断都依赖经验。
这就是我认为 AI 可以切入的地方。
所以我最近在设计一个项目：
资金流异常分析 Agent。
它的目标不是让 AI 自动补偿、自动划账、自动改资金。
那太危险了。
我的想法是：
输入一个订单号或支付流水号，系统自动还原资金经过的路径，用规则判断异常，生成证据链，最后让 LLM 把结果整理成一份人能看懂的排查报告。
这里最关键的设计原则是：
规则负责判断，LLM 负责表达。
也就是说：
资金是否异常，交给确定性的规则引擎； 结论依据是什么，必须有证据链； LLM 只负责把机器结果翻译成清晰的报告； 最终处理仍然由人确认。
这就是我理解的 AI 落地方式：
不是把所有事情都丢给大模型，而是让 AI 进入一个清晰、可控、可审计的业务流程。
对我来说，这个项目不只是一个工具，也不是为了蹭 AI 热点。
它更像是我对自己职业方向的一次重新定义。
过去我可能会说：
我是一个做清结算系统的后端工程师。
但未来我更希望自己变成：
一个懂资金系统，并且能用 AI Agent 重构排查、对账和稳定性工作流的工程师。
这两句话看起来差不多，但含义完全不同。
前者是岗位描述。
后者是能力定位。
五、传统开发工程师现在可以做什么？
如果你也是一名传统开发工程师，最近也在焦虑，我觉得可以先从几个方向开始。
1. 不要只学“怎么问 AI”，要学“怎么让 AI 进入工作流”
很多人学习 AI，还停留在 prompt 层面：
帮我写代码； 帮我优化 SQL； 帮我写单测； 帮我生成周报； 帮我解释报错。
这些当然有用，但还不够。
举个例子。
如果你只是让 AI 帮你写 SQL，那你只是省了一次写 SQL 的时间。
但如果你把一个常见排查流程做成工具：
输入订单号； 自动查相关表； 自动判断状态； 自动输出异常原因； 自动生成排查报告；
那你节省的就不是一次时间，而是整个团队未来无数次类似排查的时间。
这就是“用 AI” 和 “让 AI 进入工作流” 的区别。
前者是个人效率工具。
后者是团队系统能力。
图注：真正能拉开差距的，不是“会不会问 AI”，而是能不能把 AI 变成稳定工作流的一部分。
所以更重要的是问自己：
我每天重复做的工作，有哪些可以被流程化？哪些可以拆成“数据输入 → 规则判断 → AI 表达”？哪些可以从一次性提问，变成一个稳定工具？
比如：
线上问题排查； 日志分析； SQL 生成； 接口文档生成； 测试用例生成； 事故复盘； 数据对账； 业务规则校验。
AI 真正有价值的地方，不是帮你回答一次问题，而是持续接入一个工作流。
2. 找到自己的业务护城河
不要一看到 AI 火，就立刻抛掉自己过去的业务积累。
很多时候，你过去几年积累的业务经验，恰恰是你在 AI 时代最大的优势。
如果你做支付，就研究支付、清结算、对账、风控。
如果你做电商，就研究订单、库存、履约、营销、供应链。
如果你做物流，就研究调度、计费、路线、运力、结算。
如果你做金融，就研究账务、估值、风控、合规。
如果你做企业系统，就研究审批流、权限、数据治理、组织协同。
我见过一些同学，一看到 AI 火，就觉得自己原来的业务不值钱了，想立刻换去做“纯 AI”。
但问题是，纯 AI 赛道也很卷。
而且很多人进去之后会发现，自己既没有模型背景，也没有 Infra 经验，最后只能停留在调 API、套壳、写 Demo。
这不一定比原来的业务开发更有壁垒。
更好的方式可能是：
回到你最熟悉的业务里，找一个足够痛、足够重复、足够依赖经验的问题，然后用 AI 去改造它。
比如支付工程师可以做对账异常分析。
电商工程师可以做库存异常诊断。
物流工程师可以做路线调度分析。
客服系统工程师可以做工单自动归因。
财务系统工程师可以做费用差异解释。
这些方向也许没有“训练大模型”听起来酷，但更容易真正落地。
未来真正有壁垒的，可能不是：
我会用某个 AI 工具。
因为工具大家都能学。
更有壁垒的是：
我懂一个复杂业务，并且知道如何用 AI 把这个业务里的问题系统化解决。
AI 时代，业务经验不是包袱。
真正的问题是：你有没有把业务经验沉淀成系统能力。
3. 从一个小工具开始，不要一上来做大平台
很多人一想到 AI 项目，就想做一个完整平台：
多 Agent； RAG； 知识库； 工作流编排； 权限系统； 可视化大屏； 自动修复； 告警联动； 企业级插件市场。
结果越想越大，最后迟迟没有开始。
这就像很多人一开始健身，就给自己安排了每天两小时训练、严格饮食、每天记录体脂、每周调整计划。
听起来很专业，但很难坚持。
真正更容易开始的方式是：
今天先去楼下跑 10 分钟。
做 AI 项目也是一样。
不要一开始就做平台。
先做一个小闭环。
比如我的资金流异常分析 Agent，第一版不需要覆盖所有场景。
只要能做到：
输入一个订单号↓还原资金路径↓命中几条核心异常规则↓输出证据链↓生成排查报告
这就已经有价值。
先跑通，再扩展。
不要一开始就追求完整，要先让它能解决一个真实问题。
一个能解决真实问题的小工具，远比一个停留在文档里的大平台有价值。
4. 把自己的经验写出来
过去很多工程师不喜欢输出，觉得代码写好就行。
我以前也会觉得：
写文章有什么用？真正的能力不是体现在代码和项目里吗？
但现在我的想法有点变化。
AI 时代，公开表达会越来越重要。
因为你写出来的东西，不只是文章，也是你的思考资产。
你可以写：
一个线上问题是怎么排查的； 一个系统设计为什么这么做； 一个 AI 工具如何接入业务； 一个 Agent 项目从 0 到 1 的过程； 一个传统后端如何转型 AI 工程化； 一个业务场景为什么不能简单交给大模型。
不一定要写得很宏大，也不一定要追求爆款。
持续记录本身，就会形成积累。
你写得越多，就越容易沉淀出自己的方法论。
你沉淀得越清楚，就越容易让别人知道：
原来你在这个方向上是有长期思考和实践的。
这件事对职业发展、个人品牌、甚至未来提供服务，都会有帮助。
而且写作还有一个隐藏好处：
你以为你是在给别人讲清楚，其实你是在逼自己想清楚。
很多问题在脑子里是模糊的。
一写出来，就知道哪里没想明白。
5. 不要焦虑到失去行动力
最后这一点，我也经常提醒自己。
AI 确实会改变很多岗位。
传统开发工程师的舒适区，也确实正在被打破。
但焦虑本身不会带来机会，行动才会。
我也会焦虑。
看到 AI 写代码越来越快，会焦虑。
看到很多人在转 AI，会焦虑。
看到一些年轻人很早入局、薪资涨得很快，也会焦虑。
但后来我发现，焦虑最消耗人的地方，不是它让你难受，而是它让你原地打转。
你每天想：
我要不要转 AI？Java 还能不能做？后端还有没有前途？我是不是落后了？
想一晚上，第二天什么都没变。
所以我现在更愿意把问题换成：
我所在的业务里，最复杂、最依赖经验的问题是什么？ 这个问题能不能被拆成“数据输入 → 规则判断 → AI 表达”的流程？ 我能不能用 1 到 2 周做一个最小 Demo？
如果答案是可以，那就先做起来。
哪怕第一版很粗糙，也比停留在焦虑里强。
很多时候，行动不是因为你已经完全想清楚了。
而是你开始行动之后，才会慢慢想清楚。
图注：AI 时代的转型，不一定是抛掉原来的业务重新来过，更现实的方式是：从已有业务经验出发，找到一个可以被 AI 放大的问题。
六、我的阶段性判断
我现在越来越相信一件事：
AI 时代，软件工程师不是没有机会了，而是不能只把自己定义成“写代码的人”。
未来更有机会的人，可能是这样的：
懂业务； 懂系统； 懂数据； 懂 AI 工程化； 能把复杂经验产品化； 能把重复流程自动化； 能把个人能力沉淀成工具。
这不是说每个开发工程师都要去做大模型。
也不是说每个人都要去创业。
而是说，我们需要重新理解自己的价值。
过去，我们的价值更多来自：
我能把需求写成代码。
未来，我们的价值可能更多来自：
我能把业务问题变成系统能力。
这两者之间的差别，会越来越大。
所以我现在给自己的方向是：
不做一个只会完成需求的工程师，而是做一个能把业务经验沉淀成 AI 工作流的人。
这条路不一定容易。
但它至少比单纯焦虑更具体。
最后
所以，回到标题的问题：
AI 时代，传统开发工程师还有机会吗？
我的答案是：
有。但机会不在于继续做一个“只会写业务代码”的人。机会在于成为一个“懂业务、懂系统，并能用 AI 重构工作流”的人。
我自己目前选择的切入点，是从最熟悉的支付清结算系统出发，尝试做一个“资金流异常分析 Agent”。
下一篇，我会具体聊聊：
一笔钱在支付清结算系统里到底是怎么流动的？为什么资金异常排查很难？以及我为什么认为这个方向适合用 AI Agent 来做？
如果你也是软件开发工程师，也正在思考 AI 时代的职业方向，欢迎一起交流。
希望我们不是被 AI 推着走，而是主动用 AI 重新定义自己的工作。
