夜雨聆风7 月 29 日，我在重庆参加了第十届 CCF 未来计算机教育峰会（FCES 2026）。这届大会的主题是“未来教育：颠覆还是改良？”，而我所在的分论坛，讨论的是一个更加尖锐的问题：LLM 与 Agent 时代，编程课与软件工程课到底该怎么改？
我在论坛上做了一场题为《软件工程已死，产品工程当立》的报告。这个判断并非来自书斋中的推演，而是来自我离开高校、进入企业并亲自创业之后，正在经历的一场真实变化。
报告开头，我分享了我们公司一件在传统软件团队看来颇为“离经叛道”的事。这场变化已经持续一年了。
现在，公司的销售、运营、测试，都有自己写的代码运行在 AI 师傅平台上。他们不都是计算机专业出身。最初，我们还要求这些代码必须经过专业程序员评审；最近几个月，这道流程也取消了。只要作者自己用 AI 完成测试、人工确认结果，就可以上线。
结果并没有像很多人担心的那样失控。
系统的稳定性没有发生根本变化，客户满意度反而提高了。原因很简单：直面客户的人更懂客户真正要什么。过去，一个需求要经过沟通、排期、开发、联调和上线；现在，销售或运营发现问题后，借助 AI，个把小时就能完成修改。
这件事让我开始重新思考一个问题：
当写代码不再是一道高门槛，软件工程赖以成立的那些前提，还存在吗？
传统软件工程，首先是一套应对人“懒慢贵”的方法
传统软件工程的许多规范、流程和制度，都建立在一个共同前提上：代码主要由人来写。
而人写代码有三个天然限制：懒、慢、贵。
这里的“懒”不是道德评价，而是一个工程事实：人会疲惫，会回避重复劳动，会走捷径，也会犯错。
因为人懒、会犯错，我们引入代码评审、流程规范和层层检查，尽量把个人的不可靠变成组织的可靠；因为人慢，我们强调复用，希望一份代码不要重复开发；因为人贵，我们追求抽象和架构，希望尽可能摊薄成本。
这些方法曾经非常有效。它们不是凭空产生的，而是工业时代面对稀缺开发资源时形成的最优解。
但 AI 的出现，正在改变这些约束。
AI 改变这些约束，并不是因为它天生可靠、永远不会“偷懒”——它同样可能钻规则的空子。真正的变化在于，AI 可以持续工作，生成代码的边际成本很低，修改和重写的速度也远高于人类。当“代码必须由人一行行写出来”不再成立，许多为了节约人工、约束人工而设计的流程，就有必要重新审视。
这并不意味着软件工程突然失去了全部价值，而是说：我们不能继续把过去的手段，当成永远不变的目的。
写代码从来不是目的。解决问题，才是。
不再逐行读代码之后，我们靠什么建立信任？
过去，我们通过阅读代码建立信任：逻辑是否清楚，命名是否准确，结构是否优雅，是否符合团队规范。
但当 AI 一天生成的代码量，超过一个人几周甚至几个月的阅读能力时，继续依靠“把所有代码看懂”来保证质量，迟早会失效。
新的信任基础会越来越清晰：测试。
我自己的工作方式也发生了变化。Codex 写完代码后，我会让 Gemini 完成评审，再由 Codex 改；只有当它们给出的意见相互矛盾、无法自行收敛时，我才介入判断。最后验收的核心，不是我有没有逐行读完代码，而是结果是否满足要求，测试是否覆盖了真正的风险。
所以，人不再需要盯住每一行实现，却必须牢牢掌握三件事：
第一，什么才算正确；
第二，哪些风险不能被遗漏；
第三，测试本身是否可信。
过去，很多软件工程课程把大量时间花在编码和实现上，测试只是其中一个章节。到了 AI 时代，这个比例应该倒过来。未来的软件工程教育，甚至可以把一半时间用于训练测试思维：如何定义结果、识别边界、设计约束、验证系统。
实现可以交给 AI，正确性的定义不能一起外包。
应用软件的复杂性，正在迁移到智能体
AI 带来的变化不只是“写代码更快”。更深层的变化是：软件被谁使用，以及如何被使用。
过去的软件直接面向人，因此需要复杂的界面、菜单、表单、报表和操作流程。一个 ERP、CRM 或教学系统，要预先猜测不同用户可能提出的需求，再把它们固化成功能。
未来，越来越多的软件会先服务于智能体，再由智能体服务于人。
以我们正在做的 AI 师傅为例。传统做法是开发一套完整的数据分析后台，把各种图表和报表都提前做好。但我们做到一部分就停了下来，转而开放数据接口、提供 Skill。
老师不必学习一个复杂的后台。他只需要告诉自己的智能体：“帮我看看这门课里，学生最容易在哪些地方掉队。”智能体可以根据需要读取数据、生成分析、画出图表，再按照这位老师喜欢的方式呈现结果。
过去由软件承担的复杂性，迁移到了智能体。
软件本身则会变得更小、更原子化：做好数据存储、权限、安全和接口，把能力开放出来，等待智能体按需组合。
这还会释放大量过去无法被满足的个性化需求。
传统软件工程不喜欢个性化，因为为一个人开发一套功能，成本太高。但当 AI 可以几分钟生成一段只服务于一个人的程序，甚至这段程序只运行一次，个性化就不再是昂贵的例外，而会成为日常。
于是，一个看似矛盾的趋势出现了：
单个应用会越来越简单，软件的数量却会越来越多；职业程序员可能变少，软件开发者反而会无处不在。
软件工程没有消失，只是价值重心变了
说到这里，很容易得出一个过度简单的结论：软件工程没用了。
并不是。
首先，不同层级的软件，变化速度完全不同。
操作系统、数据库和关键基础设施影响范围广、运行周期长，单靠测试还不足以建立全部信任。它们仍然需要经验丰富的人做架构取舍，而且对人的能力要求可能比过去更高，只是需要的人数会更少。
其次，传统软件工程中的许多核心思想仍然有效。
例如模块抽象。今天设计一个 Skill，同样要判断它解决什么问题、边界在哪里、如何被其他能力组合。这仍然是模块化思维。
再如可维护性。代码可以重新生成，但不能保证每次生成都正确。过去我们维护源代码，未来可能更多地维护产品文档、提示词、测试用例和约束条件：它们需要版本管理，需要评审，也需要持续验证。
真正过时的，不是软件工程中的所有知识，而是把“写出好代码”当作核心生产力的思维。
从软件工程到产品工程
AI 时代，市场会比过去更快、更直接地检验一个软件是否有价值。
技术人员如果只关心功能对不对，却不理解用户为什么使用、愿不愿持续使用、是否愿意付费，那么他做出的产品，很可能不如一个懂用户、懂商业的人指挥 AI 做出的产品。
这也是为什么，我更愿意把未来的方向称为“产品工程”，而不只是“软件工程”。
软件工程关注如何把软件正确地造出来；产品工程还要追问：为什么造、为谁造、解决了什么问题、是否真的创造了价值。
如果要重新设计一套面向 AI 时代的软件人才培养体系，我认为至少要加强四类能力：
第一，测试与风险判断。 能够定义正确性，识别边界条件，并为最终结果负责。
第二，人性洞察与客户沟通。 未来，越来越多岗位会直接面对客户。理解人的真实动机，比理解一张需求单更重要。
第三，商业理解。 不只知道机器如何运行，也要知道业务如何运转、价值如何产生、市场为什么买单。
第四，与 AI 协作。 会拆解任务、表达意图、提供上下文、设置约束，并让多个 AI 共同完成复杂工作。
相应地，教学方式也必须变化。比起让学生完成一个虚构项目、最后由老师打分，更有效的方法是让他们进入真实世界，解决真实问题，由真实用户和市场反馈来检验结果。
项目制学习不应该只是教学形式上的点缀，而应当成为学习的主线。
最后
手写代码也许会像许多传统手艺一样，继续被一小部分人热爱。它不会彻底消失，甚至可能因为稀缺而拥有独特价值。
但对大多数人来说，手写代码将不再是进入软件世界的门票。
未来真正稀缺的，是在结果还不清晰时定义问题，在方案彼此冲突时做出取舍，在 AI 可以生成一切时判断什么值得被生成。
软件工程不会在 AI 时代消失。
它只是从管理代码、管理开发过程，走向定义结果、管理风险和创造产品价值。
而这场变化的终点，不是“人人都会写代码”。
是人人都有能力把一个真实问题，变成一个真正有用的产品。
