AI 时代的软件开发：从职业焦虑，到重新理解人的判断力

先说原文

这篇记录的触发点，是 Swill 的文章：《AI 时代的软件开发：这一代程序员的没落，还是新生产关系的诞生？》。

我不是想复述原文，也不准备把那篇文章搬运一遍。它更像一块石头，砸进了一个已经有点松动的地方：AI 对软件行业的影响，可能并不是“程序员会不会失业”这么简单。

更准确地说，它让我重新想了一遍三个问题：

1. 当 AI 能写越来越多代码之后，软件开发到底还剩下什么是人的价值？
2. 如果很多执行型工作被压缩，一个工程师应该把能力迁移到哪里？
3. 在复杂系统里，真正稀缺的到底是更快的产出，还是更稳定的判断？

这篇文章就是这次思考的整理。

不是没落或新生，而是同时发生

“AI 会不会让程序员没落”这个问题，问法本身有点太整齐了。

现实更可能是：一部分工作会明显贬值，另一部分能力会突然变贵；一部分人会感觉自己被时代推着往后退，另一部分人会第一次拥有过去只有团队和公司才有的生产力。

低层实现、重复编码、文档整理、需求搬运、样板代码生成，这些工作会越来越难单独构成护城河。不是因为它们不重要，而是因为它们的边际成本正在被 AI 压低。

但另一类工作反而更重要：

• 定义真正的问题
• 判断需求值不值得做
• 设计系统边界
• 识别安全和合规风险
• 验证 AI 生成结果是否可靠
• 在复杂业务里做取舍
• 编排多个工具、模型和 agent 的工作流

过去，一个工程师的价值常常被“能不能实现”来衡量。现在，“能不能判断什么该实现、如何验证、出了问题怎么收束”，正在变成更核心的能力。

这不是单纯的技术升级，而是角色内涵在换壳。

从写代码的人，到组织复杂系统的人

过去的软件开发有一个默认前提：人是主要生产者，工具只是辅助。IDE、框架、CI/CD、云平台，都是为了让工程师更高效地完成自己的工作。

AI 出现以后，这个关系开始倒过来。

越来越多时候，人不再是一行一行完成实现的人，而是：

• 给 AI 提供上下文的人
• 设定约束和边界的人
• 拆解任务并检查结果的人
• 决定是否接受输出的人
• 在系统跑偏时踩刹车的人

这让我想到一个很不舒服但很真实的变化：未来的软件开发者，可能不再以“写了多少代码”来证明自己，而是以“组织了多少可靠产出”来证明自己。

代码仍然重要。底层能力也仍然重要。一个完全不懂工程的人，很难长期驾驭 AI 生成的复杂系统。

但只会执行的人会变得危险。因为 AI 本身就是一个超级执行器。人如果还停留在“接任务、写代码、交付”的单线流程里，就会被拿来和机器比速度，而这是一个很吃亏的比较。

更好的位置，可能是做一个系统型的人：

• 知道业务目标和技术实现之间的张力
• 能把模糊问题变成可验证任务
• 能用工程治理控制复杂度
• 能让 AI workflow 变得可复现、可审计、可回滚
• 能看见工具没有看见的风险

换句话说，AI 时代更需要的不是“更像机器的人”，而是更会组织机器的人。

真正让我在意的是“判断力”

读完那篇文章后，我最强烈的感受不是焦虑，而是一个更深的提醒：在生产力暴涨的时代，判断力会被放大，失误也会被放大。

一个人过去写错一段代码，影响可能只是一个模块。

一个人现在用 AI 批量生成方案、改动系统、编排 agent、自动执行 workflow，错误可能会以更快速度扩散。

这也是为什么我越来越觉得，AI 时代的软件问题不只是“工程问题”，还是“行为问题”。

人在复杂系统里并不总是理性的。我们会被速度诱惑，会因为模型答得流畅就降低警惕，会在 deadline 下跳过验证，会把“看起来能跑”误认为“真的可靠”。

这跟很多高风险场景是相通的：

场景	真正危险的地方
工程变更	不是改代码，而是误判影响面
DevOps 操作	不是命令本身，而是缺少回滚意识
安全治理	不是漏洞存在，而是错误信任
AI agent	不是 agent 会执行，而是它可能执行错方向
团队协作	不是观点不同，而是情绪污染判断
高波动决策	不是波动本身，而是人在压力下偏离计划

所以我真正感兴趣的问题，逐渐从“怎么做一个功能”变成了：

人在复杂系统中，如何保持清醒、稳定判断，并避免失控？

这个问题比“AI 会不会替代程序员”更贴近我现在的感受。

深场景不是功能，而是长期行为

很多 AI 产品看起来很有用，但又很容易被大平台覆盖。

比如总结、翻译、写邮件、生成 PPT、写一段代码。这些都是功能场景，价值明确，但边界也很薄。只要大模型入口足够强，它们就会逐渐变成默认能力。

真正有价值的深场景，往往不是“帮我完成一个动作”，而是“陪我长期改善一种行为”。

它通常有几个特征：

• 高频出现
• 长期积累
• 情绪密度高
• 决策复杂
• 结果反馈滞后
• 人容易反复犯同一种错

比如，一个团队为什么总在相同协作节点上失控；一个工程系统为什么总在上线前暴露治理问题；一个人为什么明明知道计划，却在压力下做出相反动作。

这些问题不是一次聊天就能解决的。

因为真正的价值不在“回答”，而在：

• 长期上下文
• 过程记录
• 行为模式识别
• 及时提醒
• 复盘反馈
• 约束机制

这也是我对 AI 产品方向的一个新理解：不要急着把 AI 包成一个漂亮入口，而要先找到一个足够真实、足够长期、足够痛的行为场景。

不急着做产品，先成为观察者

人很容易把“开始做产品”理解成包装概念、整理视觉、搭建外壳、补齐后台、设计商业化路径。

这些当然都重要，但它们也很容易变成伪进展。

真正难的是：你是否真的理解那个场景里的人？你是否见过足够多真实样本？你是否知道用户在什么时刻偏离计划、在什么情绪下自我合理化、在什么压力下放弃原本的判断？

如果没有这些，产品就很容易变成一套漂亮但空心的功能。

所以我现在更相信一种慢一点的路径：

先记录，后总结；先观察，后抽象；先理解行为，再设计系统。

不是每天写流水账，而是记录关键行为事件：

• 什么时候做了决定
• 当时掌握了什么信息
• 真正驱动自己的原因是什么
• 有没有偏离原计划
• 偏离时用了什么理由说服自己
• 结果出来以后，自己是否还愿意承认当时的状态

这类记录一开始可能很粗糙，甚至有点不体面。因为它会暴露很多不想承认的东西：焦虑、贪心、不甘、侥幸、想证明自己、明知道不该做但还是做了。

但恰恰是这些部分，才是最有价值的数据。

系统不是从完美理性的人开始设计的。好的系统，应该承认人会疲惫、会冲动、会自我合理化，然后给这些时刻预留护栏。

AI 时代的稀缺能力，可能更像“自我治理”

如果说过去的工程能力更多是“把事情做出来”，那 AI 时代的工程能力会越来越接近“让事情可控地发生”。

这个差别很大。

“做出来”强调产出。

“可控地发生”强调边界、验证、节奏、风险和反馈。

未来很多人都能用 AI 做东西。真正拉开差距的，可能是这些能力：

• 能不能不被速度冲昏头
• 能不能在输出很顺的时候仍然保持怀疑
• 能不能为 AI workflow 设置检查点
• 能不能承认自己判断受情绪影响
• 能不能在复杂系统里留下可追溯的记录
• 能不能把一次失败变成下一次更好的约束

这听起来不像传统意义上的“编程能力”，但它会越来越像 AI 时代的核心工程能力。

因为 AI 放大的不只是生产力，也会放大人的盲区。

一个混乱的人，拿到更强的工具，可能只是更快地制造混乱。一个有判断、有边界、有复盘能力的人，才可能把 AI 变成真正的杠杆。

写在 2026 年 5 月 11 日

今天回头看，AI 时代的软件开发给我的触动，不是“我还要不要继续写代码”，而是“我应该把自己训练成什么样的人”。

答案暂时还不完整，但方向更清楚了一点：

我不想只做一个更快的执行者。

我更想成为一个能理解复杂系统、能组织 AI、能识别风险、也能观察人的行为偏差的人。

这条路可能没有那么直，也不像某个热门产品方向那样容易包装。但它更接近我现在真正关心的问题：

当工具越来越强，人如何不被自己的情绪、速度和幻觉带偏？

也许 AI 时代真正重要的能力，不是永远保持正确，而是在复杂系统里持续校准自己。

毕竟，AI 可以帮我们生成很多东西。

但它不会替我们承担判断的后果。