前段时间，一个 Electron 项目让我开始认真想这个问题。
项目跨多个仓库，有不少历史约束，技术栈也不是我最熟悉的。按过去的开发方式，我原本预期要花几个月。大量借助 AI 后，大约一个月，我把主要工作推进了下来。
这不是一次严格的效率对照。原来的工期是经验估计，主要工作推进下来，也不等于整个项目已经交付。但有一个变化很具体：面对陌生的技术栈，我已经可以借助 AI 完成不少过去需要先花时间学习、再逐步实现的工作。
有一次，模型连续生成了几千行代码，项目真的跑了起来。对一个做了多年开发的人来说，这件事的冲击，比排行榜上的分数直接得多。
同一个模型，也犯过一个让我记住的错误。
修改一个 UI 插件时，它找到了运行时加载的文件。改完以后，页面效果完全符合要求，看起来任务已经完成。可它改的是生成产物，真正应该提交的源码没有动。下一次重新生成，这些修改就可能被覆盖。
页面是对的，改动却没有落到能长期保留的位置。只看运行结果，很容易漏掉这个问题。
这两件事放在一起，让我很难接受一个简单的答案。AI 已经能替我做很多事，它也还会犯错。可我既不能因为一次成功就断言程序员要消失，也不能因为一次失误就认定自己的经验永远安全。
我真正想弄清楚的是：已经入行的人，面对这样的变化，接下来该怎么选？
找一个永远安全的方向，可能会让人一直等下去
我考虑过不少答案：做 Agent、往架构走、深耕一个行业、研究验证和可靠性，或者干脆做自己的产品。
每条路都有道理。代码生成便宜了，检查结果是否可靠可能更重要；工具越来越通用，理解真实业务可能更有价值；开发成本降低，一个人也更容易把产品做出来。
可如果继续追问：这项能力会不会也被 AI 自动化？这些答案又都没法让我完全放心。
拿验证来说。今天我们还要花很多时间检查 AI 的结果，但检查本身也在变成自动化的对象。2026 年 2 月，OpenAI 公开的一项内部工程实践就描述了这种变化：团队让 Codex 生成代码，也逐步让它参与测试、审查和修复，工程师则投入更多精力设计环境和反馈机制。这是一个特定团队的经验，不能代表所有公司的现状，但它足以提醒我，工作边界还会继续移动。[1]
这并不意味着验证、架构或领域知识不值得学。它们在解决今天的问题，也可能在很长一段时间里继续有价值。只是我很难再把其中任何一个，当成一份保证十年安全的职业承诺。
如果一定要等到某个方向被证明不会受影响，我可能会一直等下去。
变化已经发生，速度和后果仍然难判断
我已经做了六年开发，也开始承担一些小组负责人的工作。在我的工作环境里，AI 已经很常见，公司也开始尝试知识库、Agent 和相关流程。但招聘仍在继续，团队并没有突然因为用了 AI 就大幅缩小。
这些都是身边的观察，代表不了整个行业。它们让我意识到，模型能力、个人工作方式、组织流程和岗位需求，未必会在同一时间发生变化。
一个人把代码写快了，公司可能选择少招人，也可能选择做更多过去没资源做的事。最后发生哪一种，还取决于业务需求、成本和组织选择。仅凭一次开发体验，很难推到就业结论。
研究里的结果也没有那么整齐。METR 在 2025 年初的一项随机实验中发现，经验丰富的开源开发者在熟悉的项目上使用当时的 AI 工具，完成任务的时间反而增加了约 19%。这个结果有明确的工具、人员和任务范围，不能概括所有 AI 开发。[2]
到了 2026 年 2 月的后续报告，METR 认为开发者可能已经获得更多提速，但新实验遇到了选择偏差：一些人不愿参加需要禁用 AI 的任务，同时运行多个 Agent 也让工时更难计量。研究者因此强调，这批数据不足以可靠估计提速幅度。[2]
这组变化对我很有提醒。早期研究里的变慢，不能成为今天拒绝 AI 的理由；后来出现的提速信号，也不能直接换算成公司会减少多少岗位。
我需要承认变化，同时承认自己还不知道它会怎样落到具体岗位上。职业决定仍然得做，但没必要假装手里已经有完整答案。
先看一个决定错了以后，能不能改
对已经工作多年的人来说，转型有真实成本。收入、工程经验、行业知识、同事的信任，都是这些年积累下来的东西。它们未必永远值钱，但只要还在发挥作用，就值得认真对待。
如果只是因为看到一个模型很强，就大幅降薪进入陌生领域，后来发现变化比预期慢，损失已经发生。反过来，如果因为当前工作还不错，就完全不调整做事方式，等到岗位真的变化时再准备，也可能来不及。
我现在更愿意先问：这个决定错了以后，代价有多大？
在真实任务里试用 AI，做一个小工具，接触一个新领域，通常都可以从有限投入开始。试过发现不适合，至少知道了原因，还能调整。
裸辞、举债创业、大幅降薪转行，涉及的成本就不同了。它们也可能是值得做的选择，但需要更具体的依据：新方向有没有真实需求，自己是否已经接触过，有没有足够的缓冲，失败之后怎么办。
这不是一道对所有人都相同的题。家庭高度依赖当前收入的人，和负担较轻、已经拿到新机会的人，承受风险的条件显然不同。
我想做的是，让投入的大小跟证据的多少相称。 对不熟悉的新方向，先用一个小尝试换一点真实反馈，再决定要不要继续。
给尝试一个明确的问题
不过，“继续工作，同时探索”也很容易变成一句安慰自己的话。
追模型、换工具、收藏教程、研究框架，每天都能让人觉得自己在跟上变化。可如果几个月下来，只是知道了更多名字，真实工作并没有改善，这种忙碌就需要重新看待。
我觉得一个有用的尝试，至少应该能说清楚：我想验证什么，准备投入多少，最后看什么结果。
比如，想知道自己是否适合往 AI 工程方向走，可以选一个真实、重复发生的任务，尝试把它做得更省事。关心的不只是演示能不能跑，还包括返工多少、结果是否可靠、别人能不能接着用。
想做产品，可以先找一个具体的人和一个具体的问题。做出功能只是开始，还要看对方是否愿意使用、是否再次回来，以及遇到什么麻烦。付费意愿可以是信号，但不能拿自己的开发热情替代用户需求。
想写内容，也可以先围绕自己做过的事情持续写几篇。观察哪些地方读者没看懂、哪些经验帮到了人、有没有形成新的交流。早期反馈少，不必立刻下结论；但也要给复盘留一个时间点，看看投入到底带来了什么。
这些是我理解的验证办法，不是我已经做成的结果。它们的共同点是，最后能留下比“这个方向看起来很有前途”更具体的信息。
同一阶段也不宜开太多条线。主业之外的时间有限，先把一个问题试到有反馈，通常比同时启动五个项目更能帮助下一次选择。
也要写下什么时候改变主意
推到这里，我发现一个值得警惕的地方：这些想法，和我原本就在做的事情很接近。
继续留在软件行业，在工作里用 AI，写文章，做自己的项目。到底是这些做法确实合适，还是我绕了一圈，只是在给现状找理由？
这个问题没法靠“我想得很认真”来回答。一个策略如果只能解释为什么继续，却说不出什么时候应该停，就很难被检验。
所以，如果我暂时选择留在软件行业，就应该继续观察同类岗位的需求、自己能力的市场反馈，以及工作内容是否真的在变化。一次招聘波动未必说明什么，持续出现的信号则值得认真对待。
如果另一个方向已经带来了具体机会，有人愿意使用我的成果、提供合作或岗位，而我也了解了其中的代价，就有理由重新分配时间。不能因为最初决定“先不转型”，就一直拒绝新证据。
对自己的项目也是一样。如果长期只有开发，没有接触用户，就应该先补上验证需求这一步；如果写内容一直重复已有观点，没有留下自己的观察，就该调整选题和写法。
停止一个没有进展的尝试，不等于否定这段时间。知道哪条路暂时走不通，本来就是尝试能够提供的信息。困难在于，愿不愿意据此改变安排。
我目前的选择
至少在当前的信息下，我仍然倾向于留在软件行业。手上的经验和工作还在产生价值，我不想因为焦虑就先把它们放下。
同时，我会继续把 AI 用进真实开发。既看它替我省下了哪些工作，也看时间最后花在了哪里：是澄清需求、处理历史约束，还是检查结果、修复返工。这些具体变化，比给自己换一个新职业标签更有参考价值。
主业之外，我也想继续做自己的东西，但需要控制同时推进的数量，给每个尝试留出获得反馈的机会。有依据再增加投入，长期没有进展就调整。
我仍然不知道十年以后程序员会变成什么样。现在写下的选择，也可能需要随着现实变化而修改。
但至少，下一步不必等到那个答案出现。把今天的工作做好，认真试一个可能的新方向，再根据结果决定下一步，我已经有事情可以开始做了。
参考来源