人工智能浪潮下，传统码农还能走多远？
单从简历来看，我算不上一个"特别容易焦虑"的程序员。
本科在山东大学读的软件工程，随后赴新加坡国立大学攻读智能系统硕士。硕士结业后，我进入携程从事软件开发两年半，之后又跳槽支付宝，担任高级软件开发工程师，干了大概两年。
近几年，我的工作始终聚焦于一个颇为垂直却极其关键的领域：支付、结算、清分、账务与资金体系。
如今，我依旧在 Web3 赛道深耕，所从事的依然与资金流、清结算、交易链路息息相关。
按理说，这样的履历称得上稳健：科班出身，大厂历练，兼具金融支付领域的业务沉淀。
但近一年来，我愈发强烈地察觉到一件事：
人工智能时代降临后，软件工程师过往的职业安全感，正在被重新估值。
这种感受并非凭空而来。
它源于诸多极其具体的时刻。
比如从前写一个接口，得先研读需求文档，再建表、编写 DTO、Controller、Service、Mapper，补充单元测试，修复联调问题。
现在你把上下文和表结构丢给 AI，它很快就能产出个八九不离十的版本。
又比如从前 SQL 写得慢些、测试覆盖率低些、文档粗糙些，大家会觉得这属于开发工作的常态。
但如今 AI 能帮你优化 SQL、补全测试用例、生成接口文档，甚至将异常日志解释得如同一位耐心的同事。
这些变化起初令人畅快：
太好了，终于不用写那么多重复代码了。
但畅快过后，另一个疑问便浮现出来：
倘若这些事 AI 都能干，那我未来的价值究竟在何处？
身边不少开发朋友也在讨论类似的困惑：
AI 都能写代码了，传统 Java 开发往后还有出路吗？
这个问题绝非危言耸听。
过去我们认为，后端工程师的核心竞争力在于：精通 Spring、MyBatis、Redis、MQ、分布式事务，能按期交付需求，能定位线上故障，能扛住高并发。
但现在，AI 正在迅速接管其中相当一部分工作。
因此我最近一直在思考：
软件工程师是否真的没有机会了？
我目前的阶段性结论是：
软件工程师并非没有机会，而是机会正在转移阵地。
未来值钱的，未必是"代码写得最溜的人"。
而是：
最懂业务痛点，并能借助 AI 将业务问题系统化解决的人。
这也是我最近开始认真思索转型，并尝试打造"资金流异常分析 Agent"的缘由。
我觉得很多开发伙伴的焦虑，其实并非杞人忧天。
倘若一个人的核心价值在于：
那这类工作的价值，确实会被 AI 持续挤压。
举个很寻常的例子。
产品说要新增一个"订单备注"字段。
以前这可能意味着：
这种需求当然也要认真对待，但本质上它并不难，难的是细节繁琐、链路冗长、容易遗漏。
过去这类工作需要开发耗费时间一点点补齐。
但现在，有了 AI 之后，只要上下文给得足够清晰，它能非常迅速地帮你生成大部分代码。
你真正要做的，变成了校验：
这时候你会发现，单纯"写代码"这件事的价值在缩水，而"判断这个改动在系统中是否安全"的价值在攀升。
再比如一个普通列表查询需求。
以前开发的工作是编写查询接口、分页、筛选条件、排序、权限控制。
现在 AI 可以帮你快速生成接口骨架，甚至连常见的分页查询都能代劳。
如果你的价值仅停留在：
我能把这个接口写出来。
那确实会越来越岌岌可危。
因为 AI 能写，外包能写，新人照着模板也能写。
企业自然会重新评估这类工作的价值。
这不是说开发工程师即将消失，而是"普通业务代码生产力"正在变得越来越廉价。
以前企业需要大量人力来堆代码量。
以后企业可能更需要少数人来定义问题、拆解系统、审核 AI 输出、把控质量。
所以，真正可怕的不是 AI 会写代码。
真正可怕的是：
我们的价值仅仅停留在"写代码"这一层。
这也是众多传统 Java 开发工程师焦虑的根源。
不是大家突然懈怠了，而是原有的能力模型正在被重构。
我倒觉得，AI 时代会让另一类工程师愈发值钱。
什么样的人？
不是单纯会背八股文的人。
也不是只会使唤 AI 写代码的人。
而是：
懂系统、懂业务、懂数据，并且能用 AI 改造工作流的人。
这里我举一个更贴近后端日常的例子。
线上有个订单状态异常。
用户明明支付成功了，但订单页仍显示"处理中"。
这时候你让 AI 帮你写代码，它可能很快。
但真正的问题不在于写代码。
真正的问题在于：
这些判断，AI 并非完全帮不上忙，但它必须建立在真实上下文的基础之上。
如果一个工程师不理解系统，只是把日志贴给 AI，然后问"怎么修"，那很容易得到一个看似合理、实则隐患重重的答案。
尤其在资金系统中，这种风险更为突出。
比如一笔款项没有到账，你不能简单地说：
那就重新发起一次转账吧。
因为你还要判断：
这类判断，背后是业务经验，不只是代码功底。
AI 可以帮你写一段代码，但它很难凭空知晓：
这段代码在真实资金链路里会不会造成资金损失。
这就是业务工程师的价值所在。
在 AI 时代，普通代码会越来越便宜，但复杂业务判断会越来越关键。
很多开发朋友会觉得：
那我是不是应该立刻去学大型模型、学训练、学推理框架？
未必。
如果你原本就有算法、模型、Infra 背景，当然可以往更底层深耕。
但对大多数传统开发工程师而言，更现实的一条路径或许是：
不要抛弃原有的业务，而是让 AI 放大你原有的业务经验。
你过去几年做过的订单、支付、库存、营销、物流、财务、风控、结算、对账，其实都不是无用的积累。
恰恰相反，这些经验可能会成为你在 AI 时代的护城河。
因为模型大家都能用。
但对业务现场的理解，并非人人都有。
我现在越来越觉得，传统开发工程师接下来会分化成两类。
一类是继续停留在"业务代码执行者"。
另一类是升级成"业务问题解决者"。
如果画成图，大概是这样：
图注：AI 时代，后端工程师的价值分化愈发明显：一类继续停留在"业务代码执行者"，另一类则升级为"业务问题解决者"。
第一条路，是继续只做业务代码。
这种路径短期看来最熟悉，也最"安全"：
这条路以前没问题，因为企业确实需要大量人力来完成这些工作。
但现在情况不同了。
比如测试提了一个空指针 bug，AI 可以很快帮你定位可能的原因。
比如要补一个接口文档，AI 可以根据代码自动生成。
比如一个简单接口要改字段，AI 可以快速给出修改点。
这些不是说 AI 完全替代你，而是说它会压缩你在重复性事务上的时间。
如果一个人长期只做这类事情，他的不可替代性会越来越弱。
第二条路，是懂业务，并用 AI 重构工作流。
举个例子，同样是处理线上问题。
第一类工程师的做法是：
出问题了，我去查日志、看数据库、问上下游、手动拼链路。
第二类工程师会进一步思考：
这类问题是不是频繁出现？ 每次排查是不是都要查同样的表？ 判断异常是不是有固定规则？ 能不能做一个工具，把这些排查步骤自动化？ 能不能让 AI 根据证据自动生成排查报告？
这时候，你做的就不只是开发。
你是在将业务经验产品化。
这类能力，在 AI 时代反而更有价值。
因为 AI 越强，越需要有人告诉它：
什么是正确的问题，什么是可靠的判断，什么是不能逾越的边界。
我自己的背景，是支付清结算和资金系统。
这个方向听起来可能有点"传统"，没有大模型、AIGC、智能体这些词那么时髦。
但我越做越觉得，这里面有很多 AI 可以发挥的空间。
比如在资金系统里，经常会遇到类似问题：
商户说钱没到账，到底卡在哪一环节？
这不是简单查一个订单状态就能回答的。
一笔资金可能经历：
每一环节都有自己的状态机、流水表、金额字段、失败原因和补偿逻辑。
以前排查一个类似问题，流程可能是这样的：
客服说："商户反馈钱没到账。"
值班同事先问订单号。
然后开始查支付订单，发现支付成功。
再查支付流水，看看有没有触发清分。
再查清分表，确认清分是否成功。
再查结算单，看有没有生成结算账单。
再查划账流水，看是否扣减成功、入账成功。
如果是走账务路径，还要继续查账务订单和账户流水。
查到最后，可能才发现：
原来不是支付失败，也不是清分失败，而是账务入账还卡在"处理中"。
这类排查，老手可能 10 分钟就能定位。
新人可能半小时还不知道下一张表该查什么。
更麻烦的是，很多时候问题不在于"查不到"，而在于"不知道查到的状态意味着什么"。
比如：
这些判断都依赖经验。
这就是我认为 AI 可以切入的地方。
所以我最近在设计一个项目：
资金流异常分析 Agent。
它的目标不是让 AI 自动补偿、自动划账、自动修改资金。
那太危险了。
我的想法是：
输入一个订单号或支付流水号，系统自动还原资金经过的路径，用规则判断异常，生成证据链，最后让 LLM 把结果整理成一份人类能读懂的排查报告。
这里最关键的设计原则是：
规则负责判断，LLM 负责表达。
也就是说：
这就是我理解的 AI 落地方式：
不是把所有事情都丢给大模型，而是让 AI 进入一个清晰、可控、可审计的业务流程。
对我来说，这个项目不只是一个工具，也不是为了蹭 AI 热度。
它更像是我对自己职业方向的一次重新定义。
过去我可能会说：
我是一个做清结算系统的后端工程师。
但未来我更希望自己变成：
一个懂资金系统，并且能用 AI Agent 重构排查、对账和稳定性工作流的工程师。
这两句话看起来差不多，但内涵截然不同。
前者是岗位描述。
后者是能力定位。
如果你也是一名传统开发工程师，最近也在焦虑，我觉得可以先从几个方向入手。
很多人学习 AI，还停留在提示词层面：
这些当然有用，但还不够。
举个例子。
如果你只是让 AI 帮你写 SQL，那你只是省了一次写 SQL 的时间。
但如果你把一个常见排查流程做成工具：
那你节省的就不是一次时间，而是整个团队未来无数次类似排查的时间。
这就是"用 AI" 和 "让 AI 融入工作流" 的区别。
前者是个人效率工具。
后者是团队系统能力。
所以更重要的是问自己：
我每天重复做的工作，有哪些可以被流程化？ 哪些可以拆成"数据输入 → 规则判断 → AI 表达"？ 哪些可以从一次性提问，变成一个稳定工具？
比如：
AI 真正有价值的地方，不是帮你回答一次问题，而是持续接入一个工作流。
不要一看到 AI 火爆，就立刻抛掉自己过去的业务积累。
很多时候，你过去几年积累的业务经验，恰恰是你在 AI 时代最大的优势。
如果你做支付，就钻研支付、清结算、对账、风控。
如果你做电商，就钻研订单、库存、履约、营销、供应链。
如果你做物流，就钻研调度、计费、路线、运力、结算。
如果你做金融，就钻研账务、估值、风控、合规。
如果你做企业系统，就钻研审批流、权限、数据治理、组织协同。
我见过一些朋友，一看到 AI 火爆，就觉得自己原来的业务不值钱了，想立刻转去做"纯 AI"。
但问题是，纯 AI 赛道也很卷。
而且很多人进去之后会发现，自己既没有模型背景，也没有 Infra 经验，最后只能停留在调 API、套壳、写 Demo。
这不一定比原来的业务开发更有壁垒。
更好的方式可能是：
回到你最熟悉的业务里，找一个足够痛、足够重复、足够依赖经验的问题，然后用 AI 去改造它。
比如支付工程师可以做对账异常分析。
电商工程师可以做库存异常诊断。
物流工程师可以做路线调度分析。
客服系统工程师可以做工单自动归因。
财务系统工程师可以做费用差异解释。
这些方向也许没有"训练大模型"听起来酷炫，但更容易真正落地。
未来真正有壁垒的，可能不是：
我会用某个 AI 工具。
因为工具大家都能学。
更有壁垒的是：
我懂一个复杂业务，并且知道如何用 AI 把这个业务里的问题系统化解决。
AI 时代，业务经验不是包袱。
真正的问题是：你有没有把业务经验沉淀成系统能力。
很多人一想到 AI 项目，就想做一个完整平台：
结果越想越大，最后迟迟无法启动。
这就像很多人一开始健身，就给自己安排了每天两小时训练、严格饮食、每天记录体脂、每周调整计划。
听起来很专业，但很难坚持。
真正更容易开始的方式是：
今天先去楼下跑 10 分钟。
做 AI 项目也是一样。
不要一开始就做平台。
先做一个小闭环。
比如我的资金流异常分析 Agent，第一版不需要覆盖所有场景。
只要能做到：
这就已经有价值。
先跑通，再扩展。
不要一开始就追求完整，要先让它能解决一个真实问题。
一个能解决真实问题的小工具，远比一个停留在文档里的大平台有价值。
过去很多工程师不喜欢输出，觉得代码写好就行。
我以前也会觉得：
写文章有什么用？真正的能力不是体现在代码和项目里吗？
但现在我的想法有些变化。
AI 时代，公开表达会越来越重要。
因为你写出来的东西，不只是文章，也是你的思考资产。
你可以写：
不一定要写得很宏大，也不一定要追求爆款。
持续记录本身，就会形成积累。
你写得越多，就越容易沉淀出自己的方法论。
你沉淀得越清楚，就越容易让别人知道：
原来你在这个方向上是有长期思考和实践的。
这件事对职业发展、个人品牌、甚至未来提供服务，都会有帮助。
而且写作还有一个隐藏好处：
你以为你是在给别人讲清楚，其实你是在逼自己想清楚。
很多问题在脑子里是模糊的。
一写出来，就知道哪里没想明白。
最后这一点，我也经常提醒自己。
AI 确实会改变很多岗位。
传统开发工程师的舒适区，也确实正在被打破。
但焦虑本身不会带来机会，行动才会。
我也会焦虑。
看到 AI 写代码越来越快，会焦虑。
看到很多人在转 AI，会焦虑。
看到一些年轻人很早入局、薪资涨得很快，也会焦虑。
但后来我发现，焦虑最消耗人的地方，不是它让你难受，而是它让你原地打转。
你每天想：
我要不要转 AI？ Java 还能不能做？ 后端还有没有前途？ 我是不是落后了？
想一晚上，第二天什么都没变。
所以我现在更愿意把问题换成：
如果答案是可以，那就先做起来。
哪怕第一版很粗糙，也比停留在焦虑里强。
很多时候，行动不是因为你已经完全想清楚了。
而是你开始行动之后，才会慢慢想清楚。
图注：AI 时代的转型，不一定是抛掉原来的业务重新来过，更现实的方式是：从已有业务经验出发，找到一个可以被 AI 放大的问题。
我现在越来越相信一件事：
AI 时代，软件工程师不是没有机会了，而是不能只把自己定义成"写代码的人"。
未来更有机会的人，可能是这样的：
这不是说每个开发工程师都要去做大模型。
也不是说每个人都要去创业。
而是说，我们需要重新理解自己的价值。
过去，我们的价值更多来自：
我能把需求写成代码。
未来，我们的价值可能更多来自：
我能把业务问题变成系统能力。
这两者之间的差别，会越来越大。
所以我现在给自己的方向是：
不做一个只会完成需求的工程师，而是做一个能把业务经验沉淀成 AI 工作流的人。
这条路不一定容易。
但它至少比单纯焦虑更具体。
所以，回到标题的问题：
AI 时代，传统开发工程师还有机会吗？
我的答案是：
有。 但机会不在于继续做一个"只会写业务代码"的人。 机会在于成为一个"懂业务、懂系统，并能用 AI 重构工作流"的人。
我自己目前选择的切入点，是从最熟悉的支付清结算系统出发，尝试做一个"资金流异常分析 Agent"。
下一篇，我会具体聊聊：
一笔钱在支付清结算系统里到底是怎么流动的？ 为什么资金异常排查很难？ 以及我为什么认为这个方向适合用 AI Agent 来做？
如果你也是软件开发工程师，也正在思考 AI 时代的职业方向，欢迎一起交流。
希望我们不是被 AI 推着走，而是主动用 AI 重新定义自己的工作。