摘要

企业数字化程度的一个核心体现就是业务团队与技术团队的融合程度。业务团队与技术团队的沟通越紧密，越理解对方的语言，企业的数字化创新潜力就越大。为解决业务和技术的沟通问题，我们过去发明了许多工具和方法，比如敏捷开发、DDD、业务中台。但问题仍然显著存在，因为技术团队和业务团队仍然讲着两套不同的语言。

随着低代码和GPT技术的发展，本文提出了新的解题思路：

1. 低代码让业务团队和技术团队使用「同一套语言」，极大降低信息损失，提高沟通效率，进而提高项目实施成功概率。

2. 基于 GPT 技术的「需求引导助手」可以帮助业务团队更完整和精准地描述需求。

3. 基于「同一套语言」和「高质量的需求描述」，人类做完高阶的设计后，GPT 可自动生成低代码，让大范围的自动代码生成成为可能！

这次，或许是质的飞跃！

注：本文的部分结论来资源前序文章，如有需要，请跳转阅读。

1. 《GPT 无法代替有经验的开发者，但能节省其10%的编码时间》

2. 《关于Github Copilot节省编程时间，为什么我是10%，Github CEO 是46%？》

3. 《Mendix 10新版发布，推出聊天机器人和嵌入式人工智能模型》

企业数字化程度的四个阶段

衡量企业的数字化程度有很多角度，从技术团队与业务团队的融合度角度，我们可以把企业的数字化程度分为4个阶段：技术支撑、技术与业务合作、技术引领差异、以技术为核心。下面详述：

1. 技术支撑。技术人员和业务人员互相不了解对方，沟通也很少。技术只在一些基础的业务职能上体现价值，比如会计、工资单、库存管理等。技术不能为企业带来核心竞争力。

2. 技术与业务合作。业务需求变得复杂，技术人员和业务人员需要深度沟通才能将需求梳理清楚。这个阶段，BA（业务分析师）或PD（产品设计师）的角色诞生了。BA 或 PD 有一定的业务知识，负责在需求分析阶段与业务人员敲定系统需求，但业务人员仍然在“技术黑盒子”之外。

3. 技术引领差异。技术从后台（Accounting）走到前台（Customer Interaction），开始与业务融为一体，有些公司因技术原因而产生了差异化竞争力。技术和业务之间的边界变得模糊，一些业务部门也招聘了一些技术人员。

4. 以技术为核心。第四个阶段是目前最理想的阶段，这个阶段的企业有如下特性：

5. 领导人理解技术对业务的关键性，相信依靠技术能实现用户体验的创新，并努力尝试。

6. Measure Of Success 变成客户价值，而非成本和效率。

7. 团队不断做实验和学习，不断评估、挑选和放大好的实验成果。

从上面的四个阶段，我们可以看出来企业的数字化程度，或者说数字化能给企业带来的价值的多少，非常依赖于技术团队和业务团队的沟通的顺畅度。

团队协作的核心是「沟通」

在继续深入之前，我们先插播一节历史课，来说明「沟通」对于团队目标达成的重要性。

1. 在原始部落时期，面对面沟通是主要方式。这种方式限制了沟通范围，导致团队规模通常不超过100人。因为口头传递信息会导致严重的信息丢失，损失率高达70%。经过两层传递，信息只剩下9%。在这个时期，人类改造世界的能力一般，能战胜比自身体型更大的动物，能制造简单工具，仅此而已。

2. 后来文字的发明降低了信息损失，因为信息可以永久存储，不会模糊。文字沟通也不会出现级联性的信息损失。通过文字，人类取得了巨大成就，扩大了管理疆域和人口数量，建造了伟大的建筑。然而，古代书信传递速度慢，限制了中央对地方的管控。

3. 无线电和网络通信技术的发展可让信息传递瞬间完成，加强了组织内的沟通密切性。这促进了人类改造世界的能力，例如建造跨海大桥、高速公路、高铁、飞机和太空站等。

以上历史告诉我们，组织形态的发展、团队目标的达成和对世界的改造都极大地依赖于沟通技术的发展。

软件开发的「沟通」困境

通过插播的历史课，我们知道，对于任何团队来说，「沟通」对于团队目标达成都至关重要。虽然现代通信技术的发展，企业IM、远程会议、共享协作文档等工具诞生，大大提高了企业内部沟通效率。但在企业数字化过程中，「沟通」效率的问题不仅在于沟通媒介这种底层的问题，还在于更高层级的问题。主要体现在两个方面：

1. 业务团队与技术团队专业背景和知识结构有巨大差异。现在社会职业分工很细，每一个职业都经过数十年的学习成长，所以不可能在一次谈话中完全相互理解。

2. 业务团队从提出需求到见到成品有巨大的时间延迟。技术团队的输入是软件需求，直接输出物是代码，最终输出物是应用程序。这个从软件需求到最终的应用程序的转换过程有很大的时间延迟。延迟越大，沟通越趋于单向吸收，而非双向确认。

因为这些沟通问题的存在，我们通常会出现下图这种奇怪的现象。业务团队心目中所想的需求（下文称为理想需求）是画一张刘德华头像（一个优质真人影星），而描述出来的需求却是少儿涂鸦；根据这个需求描述，技术团队最终完成的是流川枫头像（一个漫画体育明星）。

我们先看第一步，从「理想需求」到「描述的需求」的过程。业务团队把理想需求描述出来时，发生了严重的信息损失。有点像图片被压缩了。为什么会这样呢？主要有两个原因：

1. 一是业务知识被业务人员无意丢失。业务团队对业务知识了然于心，认为这些知识是众人皆知的常识。不太能站在非业务人员的角度，去考虑考虑非业务人员有哪些知识盲区。

2. 二是业务人员对必要的技术知识的缺失。业务团队通常缺乏必要的软件基础知识，不知道一个精准的需求描述有哪些要求。就像一个非美术专业生，你让他去画一张人物头像素描，他能想到的永远是那些最明显最突出的特征，头是椭圆的，眼睛有两个，嘴巴比鼻孔大等。他不知道一个头像素描有多少细节，也不知道比例、明暗、光线反射、透视这些专业技巧。

接下来我们看第二步，从「描述的需求」到「实现的应用」。技术团队从一张有严重信息损失的涂鸦，创建了一个帅气的漫画头像。显然，从涂鸦到漫画头像，技术团队增加了很多信息（细节）。有点像图片又被解压缩了。那么这些增加的信息从哪里来呢？主要有以下几个方面：

1. 技术人员对业务知识有部份了解。

2. 技术人员对一个完整应用的基本构成有专业经验。

3. 技术人员在开发时不停地与业务人员沟通确认细节。

这两个过程合并起来，像把1000*1000像素的图片先压缩成200*200像素，然后再放大到800*800像素。信息失真是显然的。

为了解决这个问题，通常的做法是：找一个既懂业务又懂技术的人来作为桥梁。我们通常把这个职位叫做 BA（业务分析师） 或 PD（产品设计师）。这样又带来的新的问题：

1. 信息传递链条加长，信息损失或漂移严重。

2. 增加额外的人力成本。

3. 对人的能力要求很高。

软件行业过去在解决「沟通」问题上的尝试

在软件开发70年的历史中，前辈们想过各种办法来尝试解决业务团队和技术团队的沟通问题。都带来一些效果，但没解决根本问题。

1. 敏捷开发：提倡快速迭代，通过让技术团队快速地产出小的、业务团队可以理解的应用版本，来让业务团队快速确认应用产出效果，达到双向沟通的目的。其次，敏捷开发提倡业务人员和技术人员的频繁互动，来快速纠正之前的沟通误差。

2. 领域驱动设计（DDD）：宗旨是同一个团队，同一套语言。希望通过规范业务团队和技术团队的术语表，且利用约定的形式描述需求和编码实施指导原则，来让业务需求的描述更加精准，且被严格落实。

3. 业务中台：通过对业务能力的封装和抽象，让业务团队去思考如何组装这些业务能力。好比开发人员做好一些积木块，技术团队去组装这些积木块。

以上三种方法，分别从不同的角度来改进沟通。敏捷开发从沟通频率的角度来改进，领域驱动从规范需求描述的角度来改进，业务中台从代码的组织形态的角度来改进。但他们都没摆脱一个根本问题：业务人员和技术人员仍然使用两套语言。一套是需求描述语言，以「自然语言+专业术语定义+图表」的形式承载；另一套是编程语言，用代码来承载。这带来一个显著问题，即业务团队和技术团队的沟通是单向的。

为什么说是单向的呢？因为，技术团队能理解自然语言，但无法完全理解自然语言中专业术语背后的专业知识；业务团队就更糟糕了，甚至完全无法理解编程语言。这为信息的双向确认造成重大阻碍。如果没有信息的双向确认，沟通损失就没法被快速发现和消除。早期的误差会蔓延到后续工序，且被一次次放大，最终导致交付失真。

低代码统一「沟通」语言，大大减少沟通损失

低代码的出现，为解决业务和技术间的沟通问题带来全新的思路。业务和技术可以共用同一套语言，低代码语言！

低代码语言，是一门编程语言，计算机可理解、可执行。同时，它又不会将业务人员排除在门外。它良好的可读性，让业务人员不用经过培训（或者只通过简单的培训）即可完全理解。

那么，他是怎么办到的呢？

常见的数字化应用都分为三个部份，数据（Model/Data）、视图（View）、逻辑（Control/Logic），我们简称为MVC。

第一，数据部份，低代码用图形化的 ER 图形式来操作和表现。这种 ER 图和 Excel 的表头设计很类似，业务人员很容易理解。

第二，视图部份，低代码用所见即所得的编辑器来操作和表现。就像绘制产品原型图一样，非常直观。

第三，逻辑部份，低代码用类似业务流程图的形式来操作和表现。既能精准的描述业务逻辑流程，也能让业务人员理解。

拥有了这一套语言体系作为基础，业务人员和技术人员就可以真正使用同一套语言，随时进行双向确认，极大增加沟通效率。

GPT帮助业务人员完成高质量业务描述

但有了这一套低代码语言工具，业务人员就能完整描述业务需求了吗？还是不能。

回顾「软件开发的沟通困境」章节，从「理想需求」到「描述的需求」之间的信息损失有两个原因：一是业务知识被业务人员无意丢失，二是业务人员对必要的技术知识的缺失。优秀的需求描述语言，能解决第一点，让业务人员把无意丢失的业务知识通过低代码描述出来，但无法解决第二点。

要解决第二点，需要另一个工具来补充业务人员的技术知识，我们暂且把它叫做「需求引导助手」。而 GPT 技术的爆发，让这个助手的实现成为可能。

我仅列举几个典型用户故事，来描述这个需求引导助手是怎么帮助业务人员写出完整的需求说明书的：

1. 当业务人员在写「需求背景-业务痛点」章节时，需求引导助手会检查是否包含必要元素（谁，做什么事，遇到什么困难，带来什么后果），及时给出提醒，以帮助业务人员思考完整，进而写出更容易理解的业务痛点。

2. 当业务人员在写「需求背景-解决方案」章节时，需求引导助手先给出示例，并检查业务人员写的内容是否包含必要元素（谁，在什么环节，通过什么方式解决上述业务痛点）。

3. 当业务人员在写「需求背景-业务价值」章节时，需求引导助手会给出几个常见的价值选项让用户去选，比如，创造新收入项、提高现有产品/服务的收入、提高工作效率、减少支出等，以帮助业务人员思考。同时，当用户写出的价值不是直接业务价值时，该助手还会继续追问业务人员「是否可以继续转换成直接业务价值」？

4. 当业务人员在写「用户故事」时，该助手会根据需求背景描述和模型已知的项目经验自动生成一批用户故事，让用户去挑选和修改，这可以大大降低业务人员的工作时间，并弥补业务人员思考遗漏之处。当然，该助手还能检查业务人员写的用户故事是否包含必要元素（角色、功能、价值），是否统一了业务术语等。

基于篇幅原因，不便列举更多例子。如有兴趣，欢迎见文章末尾联系方式与我交流。

通过需求引导助手的帮忙，业务人员的技术知识可以被很好地补充，可以写出更精确和完整的需求说明。假设业务人员完成了高质量的「需求背景」和「用户故事」描述，那么助手还能继续前进，生成关键页面的定义和关键实体的定义。经过人工的调整后，还能继续生成业务流程图、技术需求说明等。

总之，只要这个助手能按照固定的路径，每一步都能帮助业务人员生成高质量的描述，这个需求描述就会非常完整、精确、利于技术人员理解。

基于「高质量需求描述」，GPT可大范围自动生成代码

大范围的代码自动生成的前提条件之一，是需求的高质量描述。前序文章描绘了一个美好的路径，通过「低代码语言」和「需求引导助手」来帮助业务人员高质量地描述需求。

但这仍然不够。因为在代码生成领域， GPT 缺乏宏观综合思考能力，无法设计技术方案，只能做细节填充。就好比写作文，GPT 只能做完形填空，不能做全文构思。并且这个现状在十年内被解决的可能性都很低。这个观点我在前序文章中都有论证，请阅读《GPT 无法代替有经验的开发者，但能节省其10%~15%的编码时间》和《关于Github Copilot节省编程时间，为什么我是10%，Github CEO 是46%？》。

那么如何解决这个问题呢？答案是，人类设计高阶技术方案，细节之处留空，让 GPT 去填空。

我通过三个例子来让大家直观感受一下：

第一个例子，数据设计。假设业务人员已经完成高质量业务描述，代码自动生成工具可以自动生成实体，以及构建实体间关系。假设业务人员已经知道确定所有实体名称，代码自动生成工具还可以完善每个实体属性。这些对于目前的 GPT 技术来讲，都不是难事。

以下图为例，在一个培训机构的管理系统中，假设业务人员完成了完整的精确的需求描述（包括用户故事），则 GPT 可以根据需求描述来生成下述实体定义。

第二个例子，视图设计。假设业务人员已经知道应用有哪些页面，每个页面的主要功能以及跳转关系，则可以让代码生成工具自动实现页面内功能。如果面对复杂页面（非标准功能页面），业务人员可以自行确定页面基本布局，以及把页面分块，再描述清楚每块儿内的功能以及块儿之间的联动关系，剩下的「空」可以让 GPT 来填写。

以下图为例，假设业务人员划分好页面结构，并描述每个块儿的功能，如下图。则后续的任务可交给 GPT，它可根据业务人员设计的结构和功能描述来自动生成响应的界面以及交互动作。

第三个例子，逻辑设计。业务人员可以利用流程图工具，借助自然语言来描述整个业务流程，然后代码生成工具自动生成表示逻辑的低代码。

以下图为例，在一个培训机构的管理系统中，有一个用户故事：当老师请假时，希望可以把该老师的所有课程延期到老师请假回来之后。此时，业务人员把业务规则以流程图的形式绘制出来，则 GPT 即可根据流程图来生成对应的低代码。

以上三个例子，都是人类设计高阶方案，细节之处留空让 GPT 来填写的典型例子。而低代码这种语言，同时拥有了自然语言（所有人类可理解）和机器语言的优势（机器可理解），让这个过程更加无缝集成。

Mendix 的展望

作为 Mendix 的雇员，我当然希望上述愿景都能在 Mendix 未来的版本中实现。从外部公开的信息来看，我感觉 Mendix 已经在这个方向发力了，只是尚未高调公布。以下是我判断的依据：

1. Mendix 的 AI 部门更加壮大了，新的 AI 产品经理 Amir Piltan 频繁发声，这是 Mendix 重视的信号。详情请见这篇新闻（https://www.mendix.com/author/amir-piltan/）。

2. Mendix 已经在公开文章中透露相关计划，提供编程对话助手和自动代码生成。请参考文章《Mendix 10新版发布，推出聊天机器人和嵌入式人工智能模型》。

注：以上推测只代表个人观点，不代表 Mendix 企业观点。

后记

这是一只软件开发的科幻爽片，我只从宏观的理论层面证明了这种方法的可行性，以及这种方法给软件开发过程带来的巨大方便和改进。显然，我还没来得及亲自去落地这一件事。所以很多边角的场景，我并没有完全考虑。非常欢迎大家跟我交流探讨这件事，质疑我、反驳我是补充我思考遗漏点的最佳方式。

我从事软件行业 12 年时间，亲身体会过这些软件开发的痛点。它们严重影响着项目的交付，也影响着企业数字化进程。所以如果有人有类似的想法，愿意去做落地尝试，我非常愿意深度交流。希望通过合作，彻底改变整个软件开发的生产模式！

引用

1. 《GPT 无法代替有经验的开发者，但能节省其10%~15%的编码时间》

2. 《关于Github Copilot节省编程时间，为什么我是10%，Github CEO 是46%？》

3. 《Mendix 10新版发布，推出聊天机器人和嵌入式人工智能模型》

4. 《Posts by Amir Piltan》（https://www.mendix.com/author/amir-piltan/）

关于作者

您好，本人现就职于西门子工业软件，担任数字化转型高级咨询顾问。成功领导 10 多个世界 500 强企业的数字化转型项目，涉及政府、零售、金融、汽车制造、生物医药等多个行业，创造巨大商业价值。

一定不要羞涩与我沟通任何与「数字化转型」有关的问题。您的问题是我创作的源泉，您的关注是我前进的动力。也欢迎加微信私聊，ID：zjh1943，添加时请注明姓名、行业、问题。