在软件工程的演进史上，从瀑布模型到敏捷开发，每一次范式转变都源于工具与方法的创新。今天，我们正站在一个新的拐点：AI大模型（如GPT系列或其后继者）正悄然渗透到软件研发的各个环节，将我们带入“软件工程3.0”时代。

最近在AiDD峰会（北京）的闭门会上，许多大厂（腾讯、华为、百度、京东、中兴等）专家坐在一起，进行了一次深度对话，引起了我的思考：在接下来的2-3年内，大模型究竟会如何改变软件研发的格局？是单纯的效率提升，还是对人类工程师角色的根本颠覆？对话中，专家们从“Vibe Coding”（一种直观、意图驱动的编程风格）到AI Agent的潜力，再到人类对架构的掌控，展开了热烈辩论。今天想基于专家们的洞见，探讨AI的潜在影响，并剖析其中机遇与隐忧。最终，我们会发现，AI并非取代人类，而是迫使我们重新定义“软件工程”的边界——从代码细节到业务主导权的博弈。

当前景观：AI从“抄代码”到“意图解读”的跃升

对话中，一位专家直言：“大模型擅长抄代码吧”，这虽然对大模型存在一些偏见，但也是对AI当前能力的比较准确的刻画。我们经常说，大模型学过的（之前训练过这类数据的），大模型没问题，大模型没学过的，它就不会（其实，我们人类何尝不是？）。也就是说，大模型的创新能力有限（我们也不能说，大模型没有创新能力）。今天，大模型（如Claude 4 think或Gemini 2.5 pro等）已能基于提示词生成比较完整的代码函数或应用程序。如果扩展到大规模程序开发或在庞大的遗留代码上进行增量开发，大模型的能力就显得捉襟见肘，因为大模型缺乏长期记忆、缺乏经验积累和深度思维，难以完成这类长周期的复杂性工作。换言之，AI的操作还停留在战术层面：填充函数、修复bug、优化循环。但在战略层面——如系统架构的设计与演化——人类仍把控主导权。

一个生动实例来自对话：一位工程师尝试用AI“vibe coding（氛围编程）”构建一个对话Agent。只需不到10个交互回合，模型就生成了代码，但结果是生成的代码量太大，这位工程师就很可能没有时间去理解代码，最终就放弃维护这些代码，说明AI生成的软件，维护是一个问题。这暴露了AI的局限：它能快速产出，但缺乏对软件长期演化路径的掌控。编程不是难事，程序员是初级，工程师是中级，系统分析员（架构师）才是高级专家，懂业务架构和技术架构，构建业务到系统（物理世界到数字世界）的映射，这是最重要的，也是问题解决的本质，所以得由我们人类专家掌控。

展望2-3年内，随着模型如Claude 4、DeepSeek V3、Grok-4或其他大模型的迭代，AI的“意图解读”能力将大幅提升。有的专家预测，一年之内，能写企业级代码的Agent就能开发出来。想象一下，一个AI Agent能基于自然语言描述（如“构建一个支持实时协作的绘图工具”）生成初具架构的代码，然后迭代优化。这不是科幻——已有原型如Dify或LangChain的Agent框架在实验中证明了其可行性。但是，正如我们实践所得到的警示，软件设计不能完全跟着大模型跑，否则风险会失控，缺乏设计的代码越来越难维护，甚至软件开发方向会出现重大偏差。

未来变革：知识平权与复杂性的双刃剑

问题的核心在于：AI是否能“学会”业务和架构知识？

我相信，不只是代码，业务和架构等方面的知识慢慢也会被大模型学会。这个，我自己有比较多的实践与体会，大模型是懂结构的，可以分析软件架构、可以帮我们设计系统组件图（部署图）、类图等，在《软件工程3.0》图书中就有实例。未来，不只是知识平权，软件研发都会平权。这意味着，2-3年内，AI可能通过进一步的数据海量训练和fine-tuning，再辅以基于动态更新的知识库的知识检索，AI能够很好地掌握特定领域的设计模式——从微服务架构到领域驱动设计（DDD）。仅仅掌握软件的设计模式还是不够的，我们要帮助LLM如何根据业务的发展（包括访问量增大、业务服务的增多等）来优化架构，并通过知识库存储这样变化的过程，记录关键的更新（更新的原因和所做的更新），随时可以让大模型进行总结、提炼，将隐性知识转化为显性知识，在知识库中更新。随着大模型能力提升，多智能体的运用以及配套的工程能力跟上，这类问题总是能解决的，例如在AiDD峰会（北京站），中兴通讯的专家就分享了：“通过知识流水线实现端到端低成本构建知识库，包括内容类语料、代码脚本类语料通过流水线构建成RAG知识库的解决方案及落地实践”。许多企业级软件是逐渐生长出的“有机体”，充斥着历史债务和独有的复杂性。虽然目前来看，AI在此类系统中表现欠佳，因为它缺乏“教导”——我们尚未系统地将这些独特性输入模型。未来我们会慢慢通过知识库、通过fine-tuning等来“教导”大模型，帮助它掌握相关的内容，找到有效的方法来处理这种复杂性。

其实，再复杂的系统都是可以分解的，一旦分解到规模相对比较小的组件，大模型就能很好完成这些组件的实现。今天，也有真实的案例证明了这点，大模型能够复刻当年Rational Rose的建模能力，可以生成包括菜单、按钮和布局设计等各项内容。一位资深的架构师都感慨：“大模型的构建能力很强，肯定比我强。”

许多时候，我们没有表达清楚问题，大模型不知道要干什么，而不是不会干。我们自己也在探索中，很难讲清楚要构建成怎样的软件，所以大模型因此也无能为力，我们总是感觉软件的研发过程要靠我们（人类工程师）来掌控的。大多数情况下，AI充当了高效的“工匠”，但人类是“建筑师”——决定整体蓝图、评估权衡，并确保系统演化方向与业务对齐。2-3年内，如果AI Agent能集成实时反馈循环（如结合可观测性工具），它或许能处理更多“独特性”，但人类仍需“教导”模型，通过提示工程（上下文工程）、知识库或自定义数据集注入企业专有知识。

另一个层面是责任归属。AI生成的代码若出错，谁负责？在法律和伦理框架下，这将推动新规范的诞生。例如，未来软件开发可能像航空业一样，引入“AI飞行员”模式：人类监督AI，但最终责任在人。这也引出“Vibe Coding”的争议。对话中，有人质疑其价值，从产业角度看，认为不需要用Vibe Coding 来普及 AI 支持的软件开发。但现实中，它已在流行：工程师描述“vibe”（如“创建一个简洁的 mermaid 图表编辑器”），再结合Spec-driven实践，AI能输出靠谱的代码。2-3年内，Vibe Coding或许能成为主流，尤其对初创团队，降低入门门槛，实现“研发平权”。

隐忧与机遇：人类主导权的博弈

对话中，一位专家引用Geoffrey Hinton的观点：“人类的思考方式和大模型很可能是一致的，而且它学东西，没有人类生物学上的约束。”这暗示AI可能在认知上超越人类，这样现实世界和数字世界的接口，我们是否要交出去？隐忧显而易见：如果AI接管设计，软件形态会趋于扁平化？类似于我们提倡的微服务架构、Serverless架构？AI是不是也有偏好，会喜欢“扁平化”的软件？那样管理这些“扁平化”软件的工作会很重，我们不得不依赖大模型来帮我们管理？最终会不会连这管理的权限都交出去？如果那样，风险会显著增大，进入失控状态？而且我们乐于讨论和实现自主开发、自主测试，这样多智能体实现自主研发的时刻会来得更快，失控的局面会不会很快就来？幸运的事，我们可以管住多智能体。不管智能体如何自动、自主工作，但控制权还是在我们手中，无需担忧。只是，如果我们没有正确实现AI Agent，AI Agent在运行中偏离轨道，生成安全隐患代码、引入更多安全漏洞，安全风险依旧会存在。所以，对代码的分析、检测和验证，什么时候都不能缺位。

机遇同样巨大。2-3年内，代码可能越来越不值钱，能生产代码的大模型、多智能体的机制变得越来越值钱。工程师从编码奴隶转为指挥家，聚焦创新。例如，在软件开发中，AI可生成合规代码，而人类确保软件架构简单、支持持续演化。这将催生新角色，如“AI软件导师”，负责“教”模型解决复杂问题。

结语：从辅助到共生的软件新时代

在2-3年内，AI大模型不会完全取代人类工程师，而是重塑开发范式：从“编码密集”转向“意图主导”。不管AI怎么能干，主导权应掌握在我们人类手中，通过指引AI的方向，确保责任与创新并存。AI是强大工具，但人类是舵手。展望未来，我们需拥抱这一变革：投资于AI教育、强化可观测性，并辩证看待“知识平权、研发平权”。否则，我们可能错失机遇，让软件工程从艺术沦为算法的附庸。专家们的对话提醒我们：技术进步不止于速度，更在于智慧的平衡。在我们感叹大模型+智能体“太惊艳”之时，我们依旧保持清醒。

在软件工程的演进史上，从瀑布模型到敏捷开发，每一次范式转变都源于工具与方法的创新。今天，我们正站在一个新的拐