文/任向晖/明道云创始人
一句话，就能搭出一个企业应用
昨天，我们发布了HAP非常重要的一个版本，虽然依然编排为12.3这样一个不起眼的版本号，它把HAP真正带入了生成式AI的技术时代。
从这个版本起，用户终于可以用自然语言指挥agent（在HAP，这个agent的名字叫做Mingo）自动完成应用搭建。用户可以从一句话开始，通过多轮对话来完善需求表达，也可以直接上传写完的应用需求。Mingo都会根据用户需求自动生成整个HAP应用。
拖拉拽成为过去式，可靠性却没有打折
即使是第一版的表现，也足以让专业用户开始立刻改变使用习惯。我们曾经引以为傲的零代码拖拉拽可能要成为过去式了。如果通过对话就能够搭建和改进应用，那用户很难有动力再去学习手工搭建。不过，我们多年积累的产品架构也没有白做。无论是AI还是人类搭建，最终应用还是在HAP的应用平台Runtime上实现和运行。这不仅保护了现有用户的应用资产，也让HAP的AI应用搭建提供了普通vibe coding难以达成的高可靠性。只要应用能够被正确搭建，它就一定能够正确运行，这是APaaS历来的优势。
它还大大加快了应用实现的速度。在实际测试中，搭建一个中等复杂度的企业应用（大约10-15个业务对象），Mingo连同计划和搭建总共用时大概在10分钟左右。如果采用AI Coding的方案，10分钟恐怕只是第一轮计划所需要的时间。
真正的难题：换了一套全新的经验体系
这个版本花了我们更长的时间，整个迭代超过了两个月。倒不仅仅因为这个版本的特性量大，更多的是因为设计和开发AI特性时依靠全然不同的经验体系。我们很难照搬过往的经验，把清晰的用户故事作为假设，把问题解决作为明确的产出标准。AI特性的设计开发充满了不确定性。
就以AI搭建应用这个核心功能来说，我们不确定一个着手开始搭建应用的用户对于需求的清晰程度到底有多高，也不确定他是否已经做了相关的知识准备。更麻烦的是，我们无法确定用户对于AI搭建效果的期望值。如果用户需求表达不清晰，用户是更希望通过对话来事先澄清，还是先实现第一版看看再确认？
功能的实现程度也的确无法再用过去的明确标准来衡量。AI搭建应用的产出可能都没有一个唯一正确的答案。实现得很细致可以被解释为功能强大，也可以被解释为越俎代庖；实现得很粗略可以被解释为能力绵弱，也可以被解释为富有弹性。
在企业应用的架构思想上，过去我们有非常多的积累，也有被验证过的方法论。但是在AI搭建的背景下，在这些方法论指导下的Skill约束到底是必要的驾驭缰绳，还是不必要的画蛇添足？
这种变化使得我们在产品设计评审的时候容易陷入长时间的争执和反复。任何一个争执都需要靠真实的实验来消除，而每一个实验通常也要基于一些假设才能开始。
像一群运动员，换了一个星球赛跑
于是我们蹒跚了两个多月，终于把这个版本送到到用户手上。我真的是诚惶诚恐等待着用户们的反馈。这的确不是出于谦逊，而是内心真实的感受。这几个月，我感觉自己换了一个行当一样，熟悉的东西不再熟悉，简单的事情不再简单。说得更形象一点，有点像一个在地球上的短跑运动员去了月球赛跑。感觉好像身体轻了很多，但是要跑得快，可能不仅仅是迈大步那么简单。我们这个行业（企业软件）在这几个月就像这群换了一个星球的运动员，一个个张牙舞爪地用奇怪的姿势往前跑。每个人都非常兴奋，每个人都从未跑完过一个赛程。
但在这个不安之外，我更多抱有的是感慨，感慨在职业生涯中能够遇上这样的技术跃进。几年前，明道云开发出零代码应用平台这个产品的时候，我是绝然没有想到有一天应用能够被自动搭建，更没有想到，AI能够帮助开发这样的平台。我一度相信只要拖拉拽就能构建企业应用已经是效率的天花板，没想到AI还能把这个天花板往上再顶了一万米，连拖拉拽都不用自己动手了。
我只是感慨，不是哀叹
注意，我只是感慨，不是哀叹。我很确信AI没有摧毁和替代所有知识劳动的企图心，它是一个助推火箭，提升所有值得提升的，摧毁所有不值得提升的。反正，今天我们被它送到月球上去做产品了。一开始有点晕而已，只要适应了新的环境，我相信我们能够给用户带来更为强大的产品。
为了保住一点心理确定感，在发布前，我逮住一位产品经理打磨一个动画的帧率，因为我觉得它还不够合理。像极了一个产品老登最后的倔强。
