AI · 软件工程重心迁移
代码消失了，不等于软件工程消失
作者：云飞 · 2026-05-07
今天听了 Louis Knight-Webb（Vibe Kanban 创始人）分享的软件工程如何转变为规划与审查模式，很有感触。
有兴趣可以去 B 站看原视频： https://www.bilibili.com/video/BV1w1RYBPE4m/?spm_id_from=333.337.search-card.all.click&vd_source=386ba3e74af5b5a7f8ce70daf9dd6d62
这次让我触动最大的一句话是：
代码消失了，不等于软件工程消失。
这句话很重要。
因为最近一两年，随着 AI 编程工具和大模型能力快速增强，很多人开始讲“写代码的人要失业了”。
这个判断有一半是对的。
如果只是说，过去大量靠手写代码完成的工作，未来会被 AI 大幅压缩，我认同。
但如果进一步说，代码不重要了，所以软件工程也不重要了，我觉得这个判断就偏了。
代码只是软件工程里最显眼、最容易被看见的一部分。
真正的软件工程，从来不只是把代码敲出来。
这次为什么不一样
早期我们也用过 Copilot 和 Cursor。
Copilot 更像代码补全工具，Cursor 已经很强，但早期模型在编码侧还不够稳定。那时候它们更多是程序员的增强工具，能帮你快一点，但很难真正把一个完整任务交给它。
后来 Claude Code 和更强的编码模型同步加强，事情开始发生变化。
过去一个 AI 工具可能补一段代码就要人接手，现在它可以围绕一个需求跑更久，产出更多，甚至把一个小项目的雏形直接搭出来。
从 Copilot 到 Cursor，再到 Claude Code，AI 在人工介入前能独立走得更远。
从 Copilot，到 Cursor，再到 Claude Code，变化不是简单的“更聪明了一点”。
真正的变化是：
AI 在人工介入前可以独立走得更远了。
这就让“口喷代码”从一个玩笑，慢慢变成现实。
你说一句需求，它真的能开始写。
你再补几句约束，它真的能继续改。
如果只是一个简单网页、小工具、小程序原型，很多过去需要开发人员完成的工作，现在普通人也能摸到门槛了。
普通人开始跨过编码门槛
以前写代码这件事，对普通人来说门槛非常高。
你要装环境，要懂语言，要知道框架，要会报错，要懂怎么运行。
现在不一样了。
通过 OpenClaw（小龙虾）这类产品，普通人甚至可以通过飞书、QQ 等 IM 工具提出需求，让 AI 去做网站、做应用。
我自己也做过类似尝试。
比如，我直接说：
“你给我做一个电商网页，主要包括首页、浏览、登录、订单等。”
通过 IM 直接提出需求，普通人开始跨过编码入口。
AI 会先追问关键点，比如要纯前端静态站，还是要 Node 后端；页面风格偏京东、淘宝，还是简洁品牌官网。
我回复以后，它就开始生成。
AI 不只是回答，还会把页面、路由和项目文件组织出来。
最后确实能跑出一个电商网站原型。
有商品浏览，有搜索，有购物车，有订单详情。
一个简单电商网站原型，已经能快速跑起来。
页面能跑起来是一回事，订单、交易和系统责任是另一回事。
这件事放在以前，对一个基本不会代码的人来说，是很难想象的。
我自己从 2025 年 10 月开始全面进入 AI，用 Claude Code 进行编程。
我基本代码 0 基础，以前最多也就是用 VB 给老婆写过一个 Excel 处理的小工具。
但现在，我确实可以通过 AI 做出一些以前开发才能做的东西。
所以我理解为什么自媒体上会有很多人说：写代码的要失业了。
因为从表面看，代码真的越来越不像门槛了。
但软件工程不是写代码这么简单
我从 2007 年开始做产品经理，主要负责传统 ERP 的成本管理和生产制造模块。
传统软件开发是什么样？
产品定义阶段、需求阶段、概要需求、详细需求、架构设计阶段、开发阶段、测试阶段、发版阶段。
以前是半年一个小版本，一年一个大版本。
大部分时间确实在代码开发阶段。
这就需要很多代码开发人员支撑，也诞生了很多代码外包企业。
那时候产品经理更多做的是需求工作和测试验证工作。
但是回头看，软件工程从来不是只有“开发阶段”。
代码开发只是中间那一段。
前面有需求判断、边界定义、架构设计。
后面有测试验证、上线发布、异常处理、持续维护。
AI 现在压缩的，是写代码这段时间。
但它没有自动消灭前后的责任。
需求有没有说清楚？
边界有没有拆明白？
这个功能能不能上线？
数据错了谁负责？
权限错了怎么办？
订单状态异常怎么回滚？
这些问题，不会因为 AI 能写代码就消失。
甚至恰恰相反，当 AI 写代码越来越快以后，这些问题会更快地暴露出来。
人的时间会从写代码，转到规划和审查
Louis Knight-Webb 的分享里，有一张图我觉得很关键。
写代码占比下降，规划和审查占比上升，这是 AI 编程带来的结构变化。
从 2021 到 2025，写代码的占比在下降，Planning 和 Reviewing 的占比在上升。
这就是我理解的变化。
不是软件工程消失了，而是软件工程里的时间结构变了。
过去，人花很多时间写代码。
未来，人可能花更多时间做计划、审查和验证。
换句话说，AI 把人从“代码生产者”往“工程审查者”和“系统负责人”方向推。
这对很多人来说，反而更难。
因为写代码至少有明确动作。
但计划和审查需要判断。
你要知道什么是对的，什么是错的。
你要知道一个功能只是 demo，还是可以上线。
你要知道 AI 生成的东西，是“看起来能跑”，还是“真的可靠”。
不同项目，不能用同一种 AI 编程方法
Louis Knight-Webb 推崇两种 AI 编程方法。
一种是人工深度参与计划和审查，AI 负责编写。
另一种是简单方案，AI 边做，人工边调整。
不同工作类型，需要不同的 vibe engineering 模式。
这张图说得很清楚。
你的 vibe engineering 模式，取决于你做的工作类型。
如果是前端新功能，尤其是偏交互、偏原型的东西，可以 review-heavy。
也就是先让 AI 快速做出来，人不断看、不断改、不断 QA。
review-heavy 适合前端原型和快速迭代，但会带来更多来回调整。
这种方式的好处是快。
计划不用写得特别重，AI 产出也快，适合一些一下子很难想清楚、需要看着原型迭代的项目。
我现在做的项目就偏前端交互。
比如利用 AI 生图、生视频能力进行长视频制作。由于视频模型限制，最长 15 分钟；价格上，Sora 2 按次大约几毛钱，国内很多模型按秒计费。
这种项目很难一开始就全部规划清楚。
所以我采用的是 AI 写、人工改的持续开发方式：先做一个简单计划，让 AI 编完以后，看原型不合适，就继续修改，直到完成。
但如果是强后端、重构、迁移，情况就不一样。
plan-heavy 更适合强后端、重构、迁移等高风险工程任务。
这类项目必须 plan-heavy。
你要花很多时间做计划文档、规格说明、边界盘问。
这样 AI 执行时间可以更长，后面 review 的压力反而会小一些。
原因很简单。
强后端、重构、迁移这些事情，错了不是界面难看一点，而是数据、权限、状态、兼容性都会出问题。
这不是“边做边改”就能兜住的。
OpenClaw 能降低门槛，但不能替你负责
所以综合来看，AI 确实降低了所有人编程的门槛。
通过 OpenClaw（小龙虾）这种平台，对于简单网页、小程序、门户、原型类应用，普通人已经可以做以前开发做的一部分活。
这是真变化。
但这里一定要加一句边界：
能生成，不等于能负责。
一个电商网站页面能跑起来，不等于它真的能支撑交易。
商品浏览、购物车、订单详情，看起来很快。
但再往下就是登录、权限、库存、支付、发货、退款、数据一致性、异常回滚。
这些事情不是写几行代码的问题，而是系统责任问题。
这也是我一直说的：不要把 AI Agent 或 OpenClaw 当成万能工具。
它很适合帮普通人跨过第一道门槛，让你能把想法变成一个看得见、摸得着的原型。
但真正进入企业级、交易级、复杂业务级场景时，软件工程还在那里。
只是它不再主要表现为“谁写了多少代码”。
它表现为：谁能把需求拆清楚，谁能把边界说清楚，谁能判断 AI 输出有没有问题，谁能对最终系统负责。
未来危险的不是不会写代码，而是不会审查
所以我不太愿意简单说“程序员要失业了”。
更准确地说，是一部分只靠重复写代码获得价值的人，会越来越危险。
但懂业务、懂系统、懂边界、懂审查的人，反而会更重要。
产品经理也一样。
以前产品经理可能主要写需求、跟开发沟通、验收测试。
未来产品经理如果能直接用 AI 做原型、做应用、做验证，那价值会更大。
但前提是，你不能只会“口喷需求”。
你还要知道需求有没有说清楚，AI 理解有没有偏，生成结果能不能用，哪些地方只是 demo，哪些地方必须重新设计。
这就是 AI 时代的软件工程能力。
不是人人都要变成传统程序员。
而是越来越多人都要具备一点软件工程判断。
因为当代码生成越来越便宜，真正稀缺的就不是代码本身，而是判断。
代码会越来越轻，责任会越来越重
回到最开始那句话：
代码消失了，不等于软件工程消失。
我甚至觉得，代码越轻，软件工程越重要。
以前代码慢，人还有时间在开发周期里暴露问题。
现在 AI 太快了，一个模糊需求很快就能变成一堆看似可运行的东西。
如果前面的计划不清楚，后面的审查跟不上，问题只会更快、更大地堆出来。
所以未来真正要升级的，不只是工具。
普通人要升级的是需求表达能力。
产品经理要升级的是系统拆解和验收能力。
程序员要升级的是架构判断和 AI 审查能力。
企业要升级的是流程、责任和工程治理能力。
AI 会让写代码这件事变轻。
但它不会替我们承担软件系统的后果。
代码可以越来越少。
工程不能越来越少。
