要低代码，不要低能力，低代码工具能否成为企业增效神器？

在经济形势复杂，市场竞争激烈的当前环境中，众多企业都面临着 IT 预算下降、大型项目暂停或延后的局面。但企业信息化建设与降本增效的需求依旧迫切，因而很多管理层都将目光投向了项目投入较低的低代码产品，希望这类工具能够适应紧缩的 IT 预算，以合理的成本获得令人满意的收效。

基于上述背景，IDC 预计中国低代码工具的市场规模将在 2027 年突破 100.4 亿人民币，年复合增长率达 32.3%，增势令人瞩目。而从产品供应侧看，中国低代码厂商数量众多，呈多元化发展，包括独立低代码厂商、企业应用软件商、SaaS 厂商、云平台厂商等供应方都加入了这一赛道，令市场呈现一片繁荣景象。但与此同时，低代码工具在实践中也暴露出了许多问题，诸如产品烟囱化、使用门槛不够低、业务效果不尽人意等，给低代码市场的前景蒙上了一层阴影。如何让低代码工具真正发挥实效，为企业带来可观的投资回报率，是研发厂商面临的主要挑战。

在一众国产厂商中，飞书开发低代码产品的经历可谓“厚积薄发”。2023 年 3 月，飞书发布了低代码平台共创版；之后经过近两年的打磨与上百家客户深度共创，在刚刚过去的 2024 年飞书未来无限发布会上，这款行业能力最完备的低代码产品终于正式发布。本期《极客有约》，我们邀请到了飞书低代码平台负责人周洲做客直播间，围绕飞书打造的低代码平台展开话题。飞书为何在当前时点，切入低代码赛道飞书精心打造的低代码平台，又能为行业带来哪些不一样的新鲜空气？在实践中，飞书低代码平台帮助企业获得了怎样的收益，积累了哪些值得参考的经验？本次访谈将一一深入探讨。

周洲：当前市场上许多低代码产品与企业需求的匹配度并不理想，市场迫切需要更符合需求的工具来服务客户。飞书始终从用户的角度出发，致力于研发产品，旨在加速组织的进化，提升工作效率。飞书的 People、飞书文档和飞书项目等产品均围绕这一目标进行设计。飞书的低代码平台也经过了长时间的开发，之所以之前没有推出，是因为飞书希望更深入地了解客户的问题，以确保产品更加成熟。尽管推出时间相对较晚，但从市场角度来看，当前的时机仍然非常适合。

周洲：Gartner 的全球调研显示，受访企业中约有一半的企业已经采用了低代码技术。然而，在国内，可能只有大约一半的企业听说过低代码，实际使用低代码技术的企业比例较小，深度用户更是稀缺，整体处于相对早期的发展阶段。由于低代码市场尚未成熟，客户对这类工具的预期较为模糊。许多客户一方面希望低代码平台的门槛较低，使得 IT 和业务人员都能轻松上手，另一方面又希望它能够解决企业较为核心和复杂的需求。国内低代码厂商的产品大致可以分为两类。一类是门槛较低的产品，但处理的业务相对简单；另一类能够解决深度挑战的产品，其设计通常基于厂商成熟的企业服务平台，以 aPaaS 的形式交付给企业。然而，这类产品往往设计复杂，使用起来也并不容易。

周洲：飞书的使命是助力组织及其成员提升创造力和效率。最初，飞书通过办公协同功能进入市场，但并未将其业务局限于此领域。在服务客户的过程中，飞书不仅提供产品，还扩展了服务形态，例如最近流行的飞书效率顾问服务。飞书的业务涵盖四个主要方向：组织、协同、项目和业务构建，这些方向围绕企业运作的核心要素展开。飞书的低代码平台主要服务于企业 IT 人员，同时也触及具备开发意识的业务人员。飞书的目标是帮助客户的 IT 或业务人员构建复杂的业务系统，加速企业的数字化转型进程。

周洲：低代码产品的本质是将研发的各种环节抽象成一些服务，再通过可视化、配置化等方式提供给用户，从而减少重复工作、提升效率。所以低代码产品抽象和包装的水平决定了最终的效率或能力的上限，是主要的差异点。

我们与友商的一点不同之处在于我们会花更多时间来打磨产品，而非专注于交付或定制工作上。当初我们要在字节内部解决上万人组织的办公协同挑战，于是尝试了市面上很多工具，结果都不能满足需求，因此才做了飞书这款产品。

飞书低代码的缘起与之相似，我们最早希望将它打造成一个基座，希望基于它能够承载非常复杂的、上万人能够使用的系统。其他厂商不会像我们一样从一开始就要构建这么完备的状态。项目立项后组织内部提出了更高的需求，就是希望这个平台能够支撑字节内部上万名研发工程师未来的研发模式升级，至少作为他们高效开发的首选。此外，包括 HR 团队、其他 IT 部门也有使用这个平台的需求，最后这个平台就要做到门槛又低，能力又非常强大。

目前字节内部在飞书低代码平台上开发的应用有上万款，其中上千款处于活跃状态。平台每天新增的数据有 6000 多万条，有超过 2000 万流程跑在它上面，可以说这个平台在字节内部的应用还是比较深入的。

周洲：我们有两种解决方案。首先，对于希望构建独立或轻量级系统的用户，我们提供了一种类似云数据库的服务。用户可以在界面上指定需要生成的对象，我们最近还尝试利用 AI 技术来辅助解决问题。例如，如果用户需要创建一个 CRM 系统，飞书低代码平台将帮助他们生成客户、线索和商机等对象，使用户在构建界面或使用流程时能够直接访问这些数据。由于这是一个云数据库，我们采用了如 Serveless DB 等较新的技术，这样开发工程师，尤其是前端工程师，就不需要担心如何建立表、创建索引、扩展和缩容等问题。

第二种，其次，对于企业中已经存在的大量场景，我们通过集成的方式，使得搭建的平台能够访问以前系统的 API 和数据库，用户可以继续复用这些资源。飞书在两年前推出了飞书集成平台，这是一款 iPaaS 产品，我们的低代码平台中的集成能力都是由这个平台提供的。这意味着我们有一款经过两年多打磨的产品，具备与企业数据交互和连接的能力，可以很好地处理集成需求。

在系统集成方面，我们投入了大量精力，从数据到页面组件再到服务，全面考虑了集成的各个方面。由于字节内部拥有众多现有系统，低代码平台的使用自然涉及到与这些系统的交互。两年前，我们构建了一个集成平台，旨在连接企业内部的各个系统，并将这一能力整合到低代码平台上。

例如，在开发新页面时，考虑到旧系统界面可能不够现代化，且许多系统缺乏移动端支持，如果这些系统能提供数据库连接或 API 接口，我们便能在低代码平台上迅速构建新的界面。近期，我们还在探索一种新方法，用户只需上传类似 Figma 的图片，并告知平台原始数据的位置，平台便能利用 AI 技术帮助用户完成许多前置工作，从而加速新界面的创建。

周洲：在低代码平台的使用上，程序员和业务人员的门槛有所不同。程序员可以轻松上手我们的平台，因为他们具备开发和工程思维，能够理解系统中数据、界面、流程及其协作关系。而业务人员则需要具备一定的开发和工程思维，大致了解系统运作的流程，包括数据处理、界面展示和流程管理等方面。例如，搭建一个系统时，业务人员需要知道系统由数据页面和逻辑构成。满足这些条件的用户都可以成为我们的目标受众，但他们的能力差异可能会影响他们在平台上构建的项目复杂度。飞书低代码平台在设计上区分了不同层次，底层构建为 PaaS 能力，使得专业开发者可以通过平台提供的原子级能力，甚至结合自己的扩展，开发出复杂的系统。与市场上其他产品不同，我们还增加了一层中间件，简化了用户开发应用时的固定操作，如界面设计等，使用户能够通过简单的操作快速生成界面，并在后续对结果进行调整，这使得平台对程序员和业务人员都更加友好。

最重要的是，我们平台还有一个主张是帮助程序员成长为全栈工程师。通常情况下，前端开发者可能对数据服务、容器服务和运维后台等技术不够熟悉，而我们通过提供 Serverless 云函数和云数据库等工具，能够有效解决这些运维问题，使他们能够开发出完整的系统。对于后端工程师而言，我们提供的可视化页面搭建功能，使他们能够自行构建服务，并通过 API 暴露数据，进而丰富我们的平台界面和其他内容。

我们致力于让工程师能够灵活地使用我们的产品，并在设计时尽量符合开发人员常用的开发范式，从而降低用户的认知成本。用户只需理解 MVC（模型 - 视图 - 控制器）这样的基本模型，无需掌握过多的复杂知识或学习额外的内容，即可成为全栈工程师。

周洲：我们有一个客户，刚开始接触飞书低代码平台是无心插柳。当时他们有一件任务需要处理，急需一个系统来收集和处理用户的一些信息，因为机缘巧合我们就推荐了这个产品给他。结果他们基本上能做到新提的需求当晚、第二天就能上线，相对他们传统的开发流程有很大的体验提升，很好地解决了这个任务的挑战。于是他们就成为了我们的用户，开始慢慢将企业内的很多运营场景迁移到飞书低代码平台上。

我们之前同这家公司的 CIO 沟通时，他亲自讲了一些体验。他们以前做了一个 IT 规划，计划在 2026 年完成企业连锁店铺的一系列运营系统的建设。结果在飞书低代码平台的支持下，他们在 2024 年提前完成了目标。现在他们经过深度使用已经变成了我们的推广大使，会帮助我们同其他客户沟通，介绍他们的经验。

还有一个案例，我们有一个客户是业务人员，他向他们的研发团队提出了一个需求，研发说一年后才能上线。结果他觉得一年时间需求早过时了，就没让研发接活。后来他通过飞书的服务团队了解到飞书低代码平台，我们就进场了解了他的需求开始实现，到最终上线推广只用了两个月时间。后来我们有一些小的闭门会他也会来分享经验。其实像他们这样原本研发周期较长的情况可能有很多原因，会涉及资源、排期等问题，而且研发团队的工程师也各有所长，并不都是全栈工程师。而我们希望企业不会因为缺少某种人才而卡在某个节点，通过飞书低代码平台，企业的需求就可以顺利推进，不需要等待专门人才到岗。

还有一点，很多时候研发周期较长是因为需求不够清晰，因为业务人员不是很懂技术，很难将需求翻译成技术语言；技术人员也不懂业务，也很难理解业务所说的要求。这中间就需要产品经理做非常细的需求梳理，而等产品几个月后上线，业务人员发现成品和预想的有区别，于是又要等几个月修改，前后加起来半年就过去了。

低代码有个好处，我们有个客户说他们自己搬着电脑去前线业务人员那里，让业务讲需求，之后他们就在旁边可能花两三天时间给业务人员做一个原型试用，马上就能判断哪些点符合业务逻辑，哪些点有问题，反馈非常迅速。原型确认后，开发人员就可以回到本部门认真打磨细节，过两三周再出一个版本，快速迭代。虽然每次都不是完美的版本，但业务人员不需要漫长的等待，也更容易控制预期。

我们现在希望技术和业务人员像在一张圆桌上面一样共同讨论和实现大的业务目标，这样就能把业务人员的想法同技术人员的能力很好地结合在一起。

周洲：很多时候企业培训员工后发现效果不及预期，原因也是类似的。有时企业需要让员工亲自下到一线实践，才能获得所需的能力。所以技术人员不懂业务时，不是说让他们去天天同业务人员工作在一起就能解决问题，因为前者缺少的是熟悉业务，能够以大家都理解的方式协作的人员的帮助。反过来一样，业务人员也很难通过几天的培训就对技术有深刻的理解。我认为有了飞书低代码平台这样的工具，它能逐渐潜移默化地让大家重新思考和理解很多事物，将被动式学习转化为主动式学习，进而让组织发生变化。

周洲：AI 有两个视角能够与低代码结合来帮助企业。一种是通过 AI 的方式让大家更快、更好地构建系统，帮助开发者更快交付；第二个视角是，AI 能力可以提供给开发者，让开发者通过这些能力更好地输出到业务线，让业务同学使用 AI 产品解决日常工作中面临的问题。

我们在这两个方向都做了一些工作，第二个视角的优先级会高一些，因为开发者的规模还是有限的，而且通过赋能开发者来赋能业务的路径相对来说还是有些长。所以我们去年开始优先解决业务的问题。去年我们做了飞书智能伙伴搭建平台等产品，想让 AI 进入用户的日常办公场景来解决业务问题。

我们有个解法，比如说在低代码系统里搭建一个界面时，我们在界面上挂载 AI 的能力，类似于 Copilot 的形式。用户看到一张数据报表，旁边就会有 AI 助手，点一下就能帮他解读背后的逻辑。比如飞书的 CRM 系统，当用户准备拜访某个客户，点开客户的详情页时，就可以一键生成客户的拜访文档。AI 会基于客户的行业数据、之前拜访时的诉求或反馈来生成这个文档的初稿，方便业务人员来润色完善。

又比如每天销售主管要查看大量客户拜访信息，花费很长时间。我们的 AI 就可以把各个客户的进展总结成一句话推给主管，有问题的信息点进去可以查看详情，这样就能大大节省时间。飞书通过这样的方式让 AI 同业务深度结合，让业务人员能够获得 AI 的好处。

开发侧我们也做了很多工作。AI 很擅长写代码，所以我们去年做低代码平台时就听到了一种声音，说未来 AI 是否会替代低代码平台。但我们跑了一年再看，发现 AI 能解决的问题还是有限的，在限定集里它做得还行，但在特别复杂的场景里它还是有很多约束或者局限。比如你让它帮你在一个几十万行的工程体系里做一些代码工作，你要做的事情就会非常多，而且它的准确性没有到那么高的程度。所以业界基于 AI 搭建的，用交互方式编程的产品大都是玩具级别，声量很大，但离投产还很远。

但我觉得低代码是一个很好的切入点，因为在低代码场景里我们经常面对片段式的代码，你不需要面对十几万行或者几十万行的工程，而 AI 在生成片段式代码时效果还可以。我们的系统天然是云产品，所以用户的代码写完后它可以直接调试来看效果。所以在低代码平台里融合 AI 的能力反而更合理，比单独做一个对话式开发工具要好。AI 与低代码一样是工具，是助力器，它们可以强强联合，不用考虑谁替代谁。

还有一点，AI 生成的裸代码要拿来修改，对开发人员还是有一定门槛的。而低代码的好处是它生成的是界面和系统，可以通过可视化的方式来修改。所以如果 AI 和低代码能很好地结合，先由前者生成可配置、可交互的及格原型，用户再通过后者来可视化地修改它，这样就能充分利用两者的优势。

周洲：好的工具肯定能成就更好的组织，所以企业应该给员工配备更好的工具，但前提是成本可控。因为有一些工具不是今天买了后立刻就能给企业带来变化，它成熟是有过程的。企业需要采购后逐渐使用，有了自己的理解再深入、升级。但企业自己的管理者要首先去使用像 AI 这样的工具，然后才能引导组织开始拥抱新的技术。

一个案例是，我们有个同事在三个月前使用我们的 AI 工具创建了一个 AI 数字人 PMO，然后将那个数字人放入我们的群里，结果产生了大量干扰信息，被我们抗议了。但他自己还是在持续去迭代这个产品，只是挪到了一些小的场景里，小范围试用。过了两个月，有一天我进到一个产品内测群，看大家发了一个问题，然后群里有一个机器人识别了那个问题。大家通常反馈问题都是截图，那个机器人识别了那张图，提炼了图片上的问题，帮用户写了产品 Bug 提交的标题，填好了内容，这样用户就可以一键提交了。

他们还展示了另一个案例：在飞书内部讨论问题的群中可以自动汇总大家的聊天内容，并定时输出讨论总结。所以这类技术都是迭代的过程，你不能指望它一开始就很好，但经过一段时间后它可能就并非吴下阿蒙了。所以企业引入低代码平台这样的新技术时也要有耐心，要等待一段时间才能看到比较大的变化。很多企业管理者会容易高估或者低估新技术的影响，要么希望新技术立刻见效，要么就觉得新技术还不成熟，那就直接放弃，这都是不合理的。

周洲：低代码的发展也是同整个行业的技术发展相关联的。近年来，云原生、Serverless 等技术逐渐成熟，大多数低代码平台都是基于云来解决问题。而未来随着 AI 发展，低代码技术也应该与 AI 深度融合，让 AI 越来越好用。至于结合后的产品是否会有全新的形态，这并不是现在需要考虑或担忧的，我们只要让它自然革新就好。