谁在用 AI 改变软件开发？AI 编程正在催生一种全新的软件开发者

他们未必熟悉代码语法，却懂业务、会测试、能挑错，也能把软件交付出来。真正移动的不是专业底线，而是实现门槛。

拥有 30 多年编程经验的开发者 Lars Jansen 在 X 上发帖，提出一个观察：AI 编程正在催生一种全新的软件开发者。

这条帖文很快引来大量争论，也出现了许多“这说的就是我”的回复。Jansen 随后结合自己的编程经验和这些回复写成了这篇观点长文。它不是一份具有统计代表性的行业调查，而是在追问一个已经发生的变化：

回复让 Jansen 注意到，这批人不是计算机专业的学生，也不是想靠 AI 冒充资深工程师的新人。他们是长期生活在具体问题里的领域专家：律师、设计师、电影从业者、电商人士和企业主。

他们过去缺的通常不是想法，而是把想法变成软件的能力。律所从业者可能比外部开发者更熟悉自己的工作流程；建筑从业者知道十个项目之间需要追踪哪些信息；仓库管理者清楚昂贵旧系统只要多一个界面，就能替每个人每天省下半小时；设计师也能准确描述图像工作流应该怎样运转。

但知道“我需要什么软件”，并不等于能够把它造出来。过去要跨过这道墙，通常需要程序员、开发团队和足够的预算，或者花数年时间自己学习编程。领域知识再深，如果缺少实现能力，软件仍只能停留在想法里。

AI 正在降低这道门槛。回复者谈到的并不只是个人玩具：有人为自己的工作搭建内部系统，有人用自建工具替代昂贵的软件订阅，也有人在没有传统开发背景的情况下交付了全栈系统。

这与照着教程做一个待办应用并不相同。他们也许写不出模型生成的每个函数，甚至不熟悉所用语言的一半语法，但他们清楚软件应该怎样工作。结果不对时，他们能够指出问题、测试差异、反复修改，并把实现一步步推向真正需要的状态。

会使用 AI 编程工具，并不会自动让人成为作者所说的新开发者。真正的分水岭，是判断权留在人手里，还是一起交给了模型。

以一个库存工具为例，只看表单能否提交，只验证了最顺利的一条路径。保留判断权的人还会检查重复提交会不会重复入库、库存更新与操作记录之间发生中断后能否恢复、多人同时修改库存时怎样处理，以及这些失败情况有没有测试覆盖。

两类人都在使用 AI 写代码，但做的不是同一层面的工作。前者把技术判断外包给模型，后者把模型当作实现工具，自己负责定向、质疑、测试和最终验收。能不能亲手写出全部代码，不再是唯一分界；能不能发现实现已经跑偏，才是更关键的区别。

这也是“氛围编程”（Vibe Coding）正在失去区分度的原因。这个词既被用来形容全天使用 Claude 或 Codex 的资深开发者，也被用来形容不了解数据库、只会不断接受模型输出的初学者，还包括认真测试自己工具的非程序员。把三类人放进同一个标签，并不能帮助我们判断他们实际具备什么能力。

有人认为，这种能力其实就是技术产品经理或架构师的工作：定义行为、理解用户、测试结果、发现边界问题。这个判断说对了一部分，但少了过去流程中的最后一层。传统产品经理把需求交给工程团队后，仍要有人将它变成运行中的软件；现在，同一个懂产品和业务的人可能通过自然语言调度实现层，自己完成从需求到部署的闭环。称呼并不是重点，新增的交付能力才是。

把判断权留在自己手里，并不等于已经具备生产环境需要的全部经验。资深开发者提出的质疑并非没有依据，因为真正的软件工程远不只是让正常流程在本地跑通。

安全、可维护性、身份验证、竞态条件、重试、数据库索引、速率限制、后台任务、CI/CD 和部署，都藏在界面截图看不到的地方。数据库宕机时会怎样？两名用户同时执行同一个操作时会怎样？如果模型写出一段表面合理、实际却存在危险错误的代码，使用者能否识别？

Jansen 写了 30 多年代码，不会因为模型能轻松生成 500 行 Go，就认为软件从此变得简单。

这不是反对 AI 的理由，却是不能忽略的真实代价。

更困难的问题通常出现在第二版。第一版能够运行两年以后，代码可能已经被修改 400 次；新需求开始与旧假设冲突；系统需要迁移数百万行数据；依赖库停止维护；新的模型甚至可能建议拆掉上一个模型推荐的设计。

软件会积累历史，而大量复杂度正是由历史产生的。在不破坏人们已经依赖的 15 项功能的前提下修改线上系统，远比在白纸上新建应用困难。资深工程师见过这些问题怎样发生，知道某些看似笨拙的约定为什么存在，也知道一行无辜的修改可能毁掉某个人的周末。这种由生产事故留下的判断力，无法只靠一段提示词获得。

理解这群人会改变什么，必须先区分软件的风险。如果把他们想成取代资深团队、维护一家银行运行 18 年的交易系统，当然不现实。金融、医疗、基础设施、安全敏感系统和大型分布式应用，一旦出错可能伤害用户或造成巨大损失，深度技术理解在这里不是可选项。

但大量软件并不是支付网络、Netflix 或飞机控制系统。它们是表单、数据库、工作流、报表、CRUD、API、通知、业务规则和定时任务。对这些普通软件来说，关键不是能否满足最高等级的架构标准，而是能否可靠地解决它存在的那个问题。

新开发者最先改变的，是过去因为经济上不划算而根本不会被开发的长尾软件。作者举了一个简单的账：专业团队可能为一款定制工具报价 5 万美元，但这个问题对需求者只值 5000 美元。按照过去的商业逻辑，这个项目不会发生。

如果最了解问题的人可以用几个周末做出一个足够好用的版本，这笔账就变了。原文列出的范围很广：内部工具、工作流应用、后台系统、专业计算器、库存工具、WordPress 实用程序、数据导入器、报表看板、垂直行业系统、个人工具、社区应用、小型 SaaS、家庭菜谱系统、工坊里的追踪器，以及只对 300 个人有意义的小应用。

“专业程序员一个小时就能重写”并不是有力的反驳。也许他们确实能，但过去并没有人去写；现在，领域专家把它做出来了。

这批长尾软件不会全部成功。有些质量很差，有些六周后就会被放弃，还有些可能意外把数据库暴露到互联网上。做出一个“看起来已经完成”的应用，比理解它下面的一切更容易。但其中也会出现真正有用的工具，因为有时最好的软件不是来自最熟悉编程语言细节的人，而是来自最了解问题的人。

当领域专家开始亲自构建这些工具，学习编程的顺序也可能随之改变。

传统路径通常是先学习变量、函数、循环、数据结构、一门语言和某个框架，然后才逐渐进入更大的项目，遇到架构问题。AI 让另一条路径成为可能：先做真正关心的应用，项目遇到什么问题，再去学习解决它需要的知识。

这些概念不再是“未来也许会用到”的课本章节，而是眼前项目无法继续的具体原因。Jansen 说，自己在真正需要某个知识时学得更好；回复中也有人描述了类似经历：通过追问模型、阅读解释、检查代码、破坏实现再修好它，在构建软件的过程中学习架构。

过去，想把一个想法变成软件，首先需要知道如何写出它。现在，一部分人可以把实现交给模型，但自己仍要理解到足以完成这些工作：

开始构建所需的技术知识可能减少了，但技术判断变得更重要。能够完成并发布软件，本来就是一项独立能力；许多技术出色的人同样有装满未完成项目的文件夹，AI 并没有替任何人取消最后这段路。

软件开发一直在提高抽象层级。开发者使用框架，而不是自己编写 HTTP 服务器；使用 PostgreSQL，而不是自己实现数据库引擎；参考 Stack Overflow，也不会因此失去开发者身份。AI 可能只是同一方向上跨度更大的一步，它让人可以通过语言接触过去必须亲手完成的实现层。

所以，AI 创造的并不是一种全新的人。具有产品直觉、领域知识、流程理解、逻辑思维和测试能力的人一直存在，过去缺的是把这些能力变成代码的通道。现在他们能够从另一扇门进入，质疑模型、验证结果、不断修改，最后把一个真正可用的应用放到服务器上。