写给技术管理者的低代码手册系列文章（17）——第六部分：AI辅助开发技术与低代码的结合路径（第一章)

系列文章

写给技术管理者的低代码手册系列文章（1）——从软件工程视角理解低代码的价值、边界与演进路径

写给技术管理者的低代码手册系列文章（2）——第一部分：低代码诞生的背景【第一章】

写给技术管理者的低代码手册系列文章（3）——第一部分：低代码诞生的背景【第二章】

写给技术管理者的低代码手册系列文章（4）——第一部分：低代码诞生的背景【第三章】

写给技术管理者的低代码手册系列文章（5）——第二部分：低代码的概念、价值与发展现状（第一章）

写给技术管理者的低代码手册系列文章（6）——第二部分：低代码的概念、价值与发展现状（第二章）

写给技术管理者的低代码手册系列文章（7）——第二部分：低代码的概念、价值与发展现状（第三章）

写给技术管理者的低代码手册系列文章（8）——第二部分：低代码的概念、价值与发展现状（第四章）

写给技术管理者的低代码手册系列文章（9）——第二部分：低代码的概念、价值与发展现状（第五章）

写给技术管理者的低代码手册系列文章（10）——第三部分：低代码的技术原理与工程基础（第一章）

写给技术管理者的低代码手册系列文章（11）——第三部分：低代码的技术原理与工程基础（第二章）

写给技术管理者的低代码手册系列文章（12）——第三部分：低代码的技术原理与工程基础（第三章）

写给技术管理者的低代码手册系列文章（13）——第四部分：低代码的典型应用场景与价值呈现（第一章）

写给技术管理者的低代码手册系列文章（14）——第四部分：低代码的典型应用场景与价值呈现（第二章）

写给技术管理者的低代码手册系列文章（15）——第四部分：低代码的典型应用场景与价值呈现（第三章）

写给技术管理者的低代码手册系列文章（16）——第五部分：低代码应用的管理挑战

引言

软件开发领域存在一个持续了半个多世纪的梦想，那就是通过更好的工具替代开发者。这个梦想每隔十年左右就会以新的技术形态重现一次。

1970年代，COBOL的设计理念是“使语法可读性足够强，理解业务的人可以编写代码”，结果发现仍然需要专业程序员。1980年代，CASE工具（Computer Aided System Engineering，例如UML、E-R等）承诺通过图表生成代码，最终也未能兑现。1990年代，Visual Basic等可视化工具扩展了参与者范围，但并未消除对专业开发的需求。2010年代以后，低代码平台延续了同样的愿景。而当下，生成式AI被认为是最有能力实现这一目标的技术。

与过去不同的是，AI已经展现出了前所未有的代码生成能力，它能够理解自然语言、生成可运行的代码片段，甚至在某些场景下直接输出完整的应用原型。这一能力的飞跃，让人们重新审视一个问题，当AI已经能够写代码，软件开发是否正在走向全面自动化？这一问题进一步引出了对低代码技术的质疑，既然AI可以绕过设计器、模型与配置，直接输出可执行代码，那么低代码是否正在成为一种过渡性的技术？或者更激进地说，低代码是否只是“在AI辅助编程成熟之前，用来弥补开发效率不足的临时方案”？

本文试图从软件工程的基本原理出发，对上述判断给出一个更为冷静、也更具解释力的回答：AI辅助开发需要元数据驱动加可视化审查作为监管载体，而不能依赖传统的代码审查体系。而低代码恰好是一个不错的解决方案。

第一章 AI需要在人类的监管下构建企业软件

要回答上述问题，必须首先厘清一个基础判断，AI是否已经具备独立承担企业软件开发的能力？ 如果答案是肯定的，那么低代码确实可能成为过渡性技术；但如果答案是否定的，那么问题就变成了AI在企业软件开发中的真实位置是什么，以及需要什么样的工程体系来支撑它发挥作用？

1.1 企业软件的特殊性

在展开具体讨论之前，有必要先回顾企业软件区别于其他软件领域的几个基本特征。这些特征对后续的讨论非常重要。

• 业务复杂性远大于技术复杂性：企业软件的核心挑战通常不在于算法难度或性能极限，而在于业务规则的数量、关联性和不稳定性。一个包含基础功能的ERP系统可能包含数百张业务表、上千条业务规则、几十个审批流程，这些要素之间存在大量隐含的依赖关系。技术实现本身往往是数据的增删改查（CRUD）和流程编排的组合，真正困难的是准确理解和持续维护这些业务语义。
• 系统生命周期长，参与人员更替频繁：企业软件通常需要运行五年甚至更长时间，期间业务需求持续变化，开发和维护人员可能更换多轮。系统的可理解性和可维护性，往往比初始开发效率更为重要。
• 多角色协作是常态：企业软件的构建过程中，需求方代表、开发人员、测试人员、实施顾问、最终用户等多个角色需要在同一个系统上协作。不同角色对系统的理解方式和操作方式存在显著差异。
• 合规性与可审计性是刚性要求：在金融、医疗、政务等行业，系统行为的可追溯性、数据的完整性、操作的合规性，都是不可妥协的底线要求。而对于制造业或商务服务业来说，核心软件的质量问题可能为企业带来不容忽视的时间和成本损失，同样存在较强的合规与审计需求。

这些特征意味着，企业软件领域对“工程治理”的需求，比面向消费者的应用或工具型软件更为迫切。而这，正是软件工程这个学科诞生的原动力。

深入了解企业软件的工程治理水平如何决定软件的可维护性与质量，请移步：第三部分的第一章

1.2 确定性：解决概率性输出与工程确定性之间的根本矛盾

我们必须承认，AI在辅助开发领域具备非常强大的能力，可以将自然语言描述转换为代码文本。例如，当开发者描述创建一个订单详情页面，包含客户名称、订单金额和提交按钮时，大模型通常可以快速生成一段前端组件代码，甚至配套生成一个简单的后端接口。这种体验，很容易让人产生一种系统已经被写出来了的错觉。

图：AI辅助开发工具的运行界面

但是，软件工程的核心目标，并不是生成一个看起来能跑的结果，而是构建一个在给定约束条件下，行为可预测、结果可复现的系统。需求评审、设计建模、测试与上线，本质上都是在不断压缩不确定性。

而生成式AI的工作机制建立在概率性推断之上。即便输入保持一致，模型在不同上下文状态下生成的结果，也可能在架构、命名与实现路径上存在差异。这种不确定性在内容创作领域是优势，但在工程体系中就成为了天然的风险。

这并不意味着AI生成的代码本身不可靠，而是说它并不具备工程系统所要求的那种内生确定性。工程中的确定性，来源于显式规则、结构化约束与一致的解释机制，而非统计相似度。这正是为什么需要人类监管的第一个核心原因：必须有人来验证AI生成的内容是否符合工程确定性的要求。

为了帮助理解这一点，我们可以将AI辅助开发中的AI类比于一名的全栈程序员，小C，他的知识很全面，前后端代码的产出效率都很高。小C以“远程办公”的形式通过了公司的招聘后，就和其他开发者一样参与到开发工作中。唯一的不同，是小C没有和团队成员有任何形式的工作外交流，公司甚至无法通过合同对他进行约束。在这一背景下，公司该如何对他进行管理呢？会直接将企业软件的端到端工作（从业务需求到可执行的软件）交给小C来独立交付吗？我们的答案是否定的。我们大概率会将为小C配套同级评审的开发人员与测试人员，从代码和成果两个层面，对他的产出进行验证。

1.3 长期可演进性：避免长期迭代带来的系统劣化

更麻烦的是，真实的软件工程并非一次性完成，而是在长期迭代中逐步演进。每一次需求变更、架构调整或性能优化，都会对系统既有结构产生影响。AI的不确定性会放到这些影响，很可能会将其转换为三类严重的系统性风险：

1. 结构退化风险：以订单系统为例，当AI被要求增加预计交付日期字段时，可能将大额订单的判断阈值硬编码为1万元，而系统其他地方（如审批规则）使用10万元，导致概念分叉。三个月后再次调整规则，AI又引入新的VIP等级判断标准，与既有定义不一致。更麻烦的是，每一次AI生成代码，都会引入新的命名风格、新的数据获取方式、新的错误处理策略。随着迭代次数增加，系统逐渐演变为由大量来源不同、假设不一的代码片段拼接而成的集合体。局部功能可能持续增加，但整体结构却在不断退化，最终进入一种脆弱状态：新功能开发越来越慢，bug修复越来越难，没有人能够完整理解系统的工作机制。
2. 协作失效风险：继续上面的示例，该系统由三位开发者协作开发，他们都使用AI来加速编码。在开发WebAPI时，开发者A向AI描述需求时使用客户名称这个术语，AI生成的代码中属性命名为customerName。开发者B使用客户姓名，AI生成clientName。开发者C使用购买方，AI生成buyerName。三个属性在业务语义上指向同一个概念，但由于描述用词不同，AI生成了三种不同的命名。更严重的是，三位开发者开发的WebAPI可能被同一个系统调用，在某些边界条件下（如该系统没有做好必要的数据合法性检查），结果就会发生混乱。当企业要做数据治理后，要求统一所有WebAPI的客户名称命名规则时，开发团队需要找到系统中所有相关代码并统一修改。但由于命名和实现方式各异，搜索customerName无法找到clientName和buyerName，最终只能通过人工阅读大量代码，逐一排查，非常麻烦。
3. 影响分析失效风险：除了接口层面的属性名称，代码内部的命名混乱也会导致基于文本检索的影响分析功能失效。比如在系统某个模块中查询有哪些地方用到了客户名称，不论是采用customerName查找还是clientName，都无法获取到真实的影响范围。在进行重构时，既耗时又极易出错。

从工程角度看，问题的根源在于AI加速了实现的生成，但没有建立结构的约束。每一次AI生成代码，都是在无边界文本空间中进行概率推断，而不是在有明确语义的结构空间中进行规则填充。这就导致了AI的概率性输出带来的风险会在多轮迭代中不断累积，导致系统逐渐偏离原有设计意图。最终，系统大概率会呈现出一种每个局部都看似合理、整体却难以理解的状态，不得不通过人工重构来重新建立秩序。

这表明，AI辅助开发在企业软件开发领域的问题并不局限在单次生成是否正确，而在于是否具备在长期演进中自我约束与保持结构稳定的能力。这是为什么需要人类监管的第二个核心原因，必须有人对系统的长期演进负责，确保每一次变更都不会破坏既有的工程基础。