本文作者：泊舟（@bozhou_ai）。版权归作者所有，未经授权禁止转载。
四十年前，技术圈已经预言过一次程序员会消失。
当时最火的东西叫 Smalltalk。它让化学工程师、结构工程师这些不以编程为职业的人，也能自己做软件。很多人相信，编程很快会简单到不再需要那么多专业程序员。
结果他们真的做出了软件。
但 Kent Beck 打开代码一看，里面经常是一团无法维护的东西。能跑，却没人敢改。
四十年后，Vibe Coding 正在把同一套剧情快进一遍。
所以，当 Dario Amodei 说编程会先消失，接着整个软件工程也会消失时，Kent Beck 的回答非常不客气：说这种话的人，并不理解软件工程。
AI 也许真的会让我们越来越少亲手写代码。但它消灭不了软件工程，反而会让普通人更早碰到软件工程的问题。
一. AI 能写出代码，不等于它完成了软件
现在用 Claude Code、Codex 或 Cursor 做一个小工具，速度确实很快。
你告诉它：帮我做一个记账网站，要有登录、分类、图表和数据导出。它可以自己创建项目、安装依赖、写前端、接数据库。顺利的话，半小时后页面就能跑起来。
以前这一步可能需要几天，甚至更久。
但页面能打开之后，问题才刚刚开始。
金额算错了怎么办？两个设备同时修改一条记录怎么办？用户输错数据怎么办？数据库升级会不会把旧数据弄丢？API Key 有没有暴露？上线以后突然打不开，该去哪里找原因？
AI 很容易告诉你：已经完成。
但是，完成到底是谁定义的？
代码一天能多出几千行，但我们对它的理解不会跟着一起增长。你不知道它为什么这么设计，不知道哪些地方最容易坏，也不知道下一次改需求会不会牵一发而动全身。
这也是我最近重写自己 AI Coding 工作流的原因。
以前我给 AI 一个需求，看它把功能做出来，测试能过，扫一眼改动就准备合并。现在我会先让它找盲区、写计划，完成以后再交解释报告，甚至反过来给我出一套测验。
测验答不上来，我就不合并。
看起来慢了一点，但至少我还知道自己在做什么。
这部分工作，就已经不只是编程了。
二. 软件工程不是写更多代码
软件工程有很多正式定义，IEEE、SWEBOK 能列出需求、架构、开发、测试、运维、安全、维护等一长串知识领域。
普通人不用先背这些。
我的理解是，软件工程就是：把一个模糊的想法，变成一个可以长期运行、不断修改，而且有人愿意为结果负责的软件。
编程解决的是怎么把一个功能写出来。
软件工程还要回答另外几类问题：
- 我们到底在解决谁的问题，做到什么程度才算完成？
- 系统应该怎么拆，数据放在哪里，各部分怎么连接？
- 怎么证明结果是对的，旧功能没有被改坏？
- 上线以后怎么观察，出错以后怎么恢复？
- 半年后换一个人接手，他能不能继续改？
- 如果软件造成损失，最后由谁判断、谁承担责任？
你会发现，这些问题里很少有一个能靠多写几行代码解决。
很多时候，代码反而是最容易的部分。
需求没想清楚，AI 会更快地把错误需求做出来。系统没设计好，AI 会更快地堆出技术债。没有测试和日志，AI 生成得越多，你越不知道哪里出了问题。
AI 让生成变便宜了。
判断和验证变贵了。
三. 当年的预测，为什么只对了一半
这段历史最值得看的地方，不是当年的预测错了。
它其实说对了一半。
当时确实有化学工程师、结构工程师、液压工程师用 Smalltalk 做出了自己的程序。从使用者的角度看，这些软件很惊艳。他们终于不用先写一千页需求，再等几年都拿不到想要的东西。
但是打开代码看，里面往往是一团无法维护的东西。能用，却很难修改，也很难继续演化。
四十年后，AI 把这个过程又加速了一遍。
以前一个非程序员可能要学几个月，才能做出第一版软件。现在一句自然语言就能让页面跑起来。门槛确实降低了，而且降得非常快。
但软件一旦开始被真实的人使用，旧问题一个都没有消失：数据会错，需求会变，依赖会升级，服务器会挂，账号会被攻击，维护的人会换。
AI 能帮你处理这些问题，却不能让这些问题不存在。
四. 普通人还要不要学编程
要学。
不过学习目标应该变了。
过去学编程，很多人从语法开始：变量怎么写，循环怎么写，函数怎么写，再刷一堆算法题。这个路径没有错，但对今天只是想用 AI 做网站、工具和自动化的普通人来说，未必还要从这里起步。
我的建议是，先让自己具备几种最小的工程能力。
第一，能把需求写清楚。
不要只对 Codex 说帮我做一个记账软件。你至少要说清楚谁在用、最重要的场景是什么、哪些数据要保存、做到什么算完成。
提示词写得长不等于需求写得清楚。能不能给出明确边界和验收标准，差别很大。
第二，能看懂软件的基本结构。
你不一定要熟练手写每一行代码，但至少要知道前端、后端、数据库、API 分别负责什么。也要能看懂文件、函数、变量、依赖和环境变量这些基础概念。
AI 说它改了数据库，你要知道这跟只改页面颜色不是一个风险等级。
第三，能做最基本的技术选型。
AI 可以一次给你推荐五六套方案，但你至少要知道，它为什么前端选 React，后端选 Python，数据库选 PostgreSQL。不同语言、框架和数据库没有一个永远正确的答案，最后还是要看项目规模、开发成本、部署难度、团队熟悉度和以后怎么维护。
新手不用把所有语言都学一遍，但应该有一套相对稳妥的默认选择，也要知道什么情况下需要换方案。一个自己使用的小工具，和一个给几千人使用的在线产品，不应该套同一套架构。
技术选型这块，一两段肯定讲不清楚。下一期我会专门整理一份给 AI 编程新手的选择方案，前端、后端、数据库和架构分别应该怎么选。
第四，学会验证，不要只会相信。
功能正常时怎么测试，输入错误时会发生什么，旧功能有没有被影响，页面刷新以后数据还在不在，这些都应该变成可以检查的结果。
以后真正拉开差距的，可能不是谁更会写 Prompt，而是谁更会给 AI 建一套机器可以执行的检查标准。
第五，学会处理失败。
会看报错，会找日志，会复现问题，会用 Git 保存版本，也知道改坏以后怎么回退。
Git 在 AI 时代不是程序员用来炫技的命令。它更像后悔药。AI 改得越快，你越需要知道它改了什么，以及怎么退回上一个还能用的版本。
第六，至少完整经历一次上线和维护。
不要永远停在本地能打开。把一个小项目部署出去，给真实的人用一段时间，然后再改一次需求。
你会很快遇到权限、配置、备份、升级、兼容性和成本。这些麻烦很烦，但它们会让你真正理解，为什么一个能运行的 Demo 和一个能长期使用的软件，中间差了那么多东西。
五. AI 时代，会编程的标准变了
我不知道编程会不会真的完全消失，现在也没人能给出一个靠谱的时间表。
但是手动敲代码在整个软件开发里的占比，大概率还会继续下降。很多样板代码、界面、测试、重构和修复，都会逐渐交给 Agent。
这不等于普通人以后不需要懂代码。
计算器普及以后，我们不用再手算每一笔复杂乘法，但你仍然要知道应该算什么，也要能判断结果是不是离谱。AI 编程也差不多。
未来的代码可能大部分不是你写的，但你至少要能回答：
- 它解决了什么问题？
- 我怎么知道它做对了？
- 出错以后怎么找到原因？
- 下一次修改，怎样避免把原来的功能弄坏？
- 我愿不愿意让真实用户依赖它？
如果这些问题都回答不了，生成再多代码，也只是生成了一堆自己不敢负责的东西。
所以我更愿意把 AI 时代的编程理解成一件新事情：
过去，会编程是你能把想法写成代码。
现在，会编程是你能带着 AI，把想法做成可信的软件。
软件工程不会因为 AI 消失。
AI 越会写代码，我们越早需要学会软件工程。
