在 AI 时代，我们重新挖掘了前端开发的提效方向，从去哪儿网的三大业务场景：机酒主流程业务、营销业务、后台服务三大业务场景，提出了 D2C 方案和基于 AI 生成后台代码的方案。

D2C 方案中，我们着重解决了代码的可用性，包括固定宽度、布局精准划分、代码语义化等方面进行了代码健壮性和可维护性的提升，业务需求出码率达到 36%。

基于 AI 生成代码的方案中，需求文档和接口 API 组成的 Prompt，依赖 GPT 生成页面渲染和业务逻辑代码，重点解决了 Prompt 的高效生成以及复杂页面代码的有效生成，业务需求代码出码率达到了 55%。

在不久前举办的 QCon 全球软件开发大会 上，去哪儿网前端技术总监姚佳梅带来了精彩的专题演讲“去哪儿网前端代码自动生成技术实践”，围绕去哪儿网三大业务场景的前端代码生成的方案，涵盖了代码生成中的难点和解决思路、AI 的应用和业务的应用提效等，希望能给大家带来一些帮助和思考。

从传统的 Web 开发到移动应用、小程序、IoT、乃至新兴的 AR/VR，大前端技术不仅需要适应越来越多样化的需求场景，还面临着如何更高效地利用现有资源、提升用户体验等挑战。2025 年 4 月 10 - 12 日，QCon 全球软件开发大会将在北京召开，淘天集团 1688 终端架构负责人曹立成出品的【越挫越勇的大前端】专题已上线，如果你有相关技术实践案例想要分享，欢迎通过以下链接提交演讲申请：https://jsj.top/f/tUOLpz

内容亮点

• 设计稿生成代码在传统算法方案的基础上加入 AI 应用

• 区分 C 端和 B 端两种场景方案，覆盖业务范围更广，有实际应用效果

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

我将从我们的实际业务开发角度出发，探讨我们是如何利用大型模型在大前端领域实现代码生成，以提高开发效率。我目前负责的是去哪儿网国际机票的前端业务，同时也涉足低代码和营销业务领域。我的工作重点之一就是从业务角度出发，辅助前端开发提效，包括代码生成技术的应用。

今天，我将围绕《去哪儿网前端代码自动生成技术实践》这一主题，展开我的演讲，内容分为四个部分，首先，阐述一下我们的研发现状以及目标达成情况，接着，将分别从 C 端和 B 端的角度探讨我们的解决方案，以及在实践过程中遇到的问题。最后，将分享一下我们的未来规划。

我们 C 端的业务场景主要分为两大块：主流程业务和营销活动。

主流程业务涵盖了用户在使用我们的系统购买机票、酒店等各类产品时所接触的所有页面。这些页面的 UI 复杂度极高，开发过程中，从 UI 编写到最终验收，需要不断地调整细节，这个过程既繁琐又耗时。其次，C 端业务涉及的客户端类型多样，包括 APP 端、小程序、PC 端和 H5 等。这些不同的客户端都需要我们去适配和开发，进一步增加了工作的复杂性。

营销活动的页面的 UI 复杂度也很高，并且很多页面涉及到复杂交互设计，如秒杀、砍价等。在开发这些营销活动时，我们遇到的痛点主要有两个：一是时间紧迫，比如五一、十一等节日活动，节前必须上线；二是活动量巨大，尽管我们已有低代码平台来解决部分问题，但活动形式的不断更新，使得我们的开发工作量依然巨大。

B 端业务主要指的是我们公司内部使用的各类后台管理系统。这些页面以大量的表单和表格为特征，信息密度极高，内容丰富。随着公司业务的增长，人力资源变得紧张，大量的需求积压。因此，我们开展这项代码生成工作的首要目标是提升前端开发效率。

在前端开发流程中，无论是 C 端还是 B 端，我们都是从需求 PRD（产品需求文档）开始的。对于 C 端，我们通常会有 UI 设计稿，这为我们的开发流程提供了视觉参考。在 C 端开发中，我们首先编写渲染代码，包括布局和样式。渲染代码的开发时间与逻辑代码的开发时间大致相当，各占一半。

B 端在大多数情况下，是依赖于需求文档和原型稿进行开发。在 B 端开发中，我们可以使用现有的 UI 框架来实现样式，因此在渲染上花费的时间会比逻辑代码少，逻辑代码的开发时间会占据更大的比例。

在引入 AI 技术重塑我们的开发流程之后，我们的工作方式发生了显著变化。过去，我们是从零开始编写代码，但现在，我们首先获取必要的物料，比如 UI 设计稿和需求文档。接着，我们会进行代码生成，基于这些生成的代码，进行后续的开发工作。我们会对生成的代码进行检查，确保功能没有遗漏，并且确定是否有 AI 无法生成的部分，这些部分就需要我们进行二次开发。

C 端代码生成出码率是 36%，B 端的出码率达到了 55%。出码率是指需求中被应用的自动生成的代码行数占需求上线总代码行数的比例。例如，一个 C 端需求上线了 1000 行代码，其中有 360 行是智能生成的。

C 端以一个页面为例，这个页面包含了与后端的交互接口数据以及用户点击和不同状态的交互逻辑。如果从头开始开发，这样的页面通常需要 1 到 2 天的时间。然而，通过我们的 AI 代码生成系统，这个页面的开发可以在短短一个小时内完成。我们的系统首先要求上传 UI 设计稿。上传后，系统大约几秒就能生成渲染代码，同时提供实时预览效果。UI 设计稿在左侧展示，而右侧则是实时预览的效果。这样，我们就能直观地看到生成的渲染代码与设计稿的匹配程度。接下来，我们结合产品需求文档生成一个可交互的 Checklist，这个 Checklist 帮助我们对需求点进行详细分析，梳理成一个完善的结构，为后续的代码生成打下基础。这份 Checklist 的数据会传递给 GPT，由它来生成逻辑代码。这部分代码包括页面与后端的交互以及页面本身的交互逻辑，比如点击某个按钮后的行为，或者页面的埋点信息等，基本上页面的大部分交互逻辑都能通过 AI 生成。

B 端的案例页面包含了表单、表格，以及一个树形结构和搜索框，页面的另一侧是节点的详细内容。如果从头开始开发，这样的页面同样需要 1 到 2 天的时间，而我们的 AI 代码生成系统也能在一个小时内完成开发。我们在一个系统中新建页面，然后将页面的所有模块进行拆分。针对每个模块编写提示词，并将这些提示词发送给 GPT 以生成代码。这个过程支持多轮对话，如果生成的代码不够好或者有功能遗漏，我们可以继续与 GPT 对话，指导它进行修正。所有模块生成后，会跳转到我们的在线编辑页面，左侧是编辑区，右侧是实时预览区。GPT 生成的实时预览页面的初版整体可用性已经非常高，所有的操作，比如点击查询后表单的显示，以及表格的生成，都是从真实后端接口数据中获取的，而不是一个静态的页面。

在 C 端业务场景中，我们对代码生成的要求主要有两个方面。首先，由于 UI 设计稿的样式复杂，我们需要高还原度的代码以确保代码的可用性。其次，考虑到主流程业务的更新迭代，我们对生成的代码质量有较高要求。为了进一步提升效率，我们还希望生成业务和交互逻辑代码。

在技术方案选型上，我们首先考虑了从设计稿到渲染代码的 D2C 方案。业界已经有很多成熟且优秀的 D2C 方案，我们进行了调研和试验，这些方案的 UI 还原度普遍在 90% 以上。然而，仅仅有高还原度是不够的，我们还需要考虑到代码的布局合理性、避免固定宽度以及语义化等问题。这些代码在简单图文场景下或许足够，但对于需要后续更新迭代的主流程代码来说还不能满足需求。此外，大多数优秀产品不开源，这意味着我们无法基于它们进行优化。

考虑到 AI 技术的流行趋势，我们也探索了现有的大模型是否能够从设计稿生成高 UI 还原度的代码。我们尝试了多个案例，并不断优化提示词，但效果大同小异。在对 UI 还原度要求极高的场景下，仅提供设计稿生成的效果往往达不到我们的要求，许多细节模块可能缺失。同时，在业务需求上线前，我们缺乏对 UI 稿有效的脱敏手段，无法将其直接提供给外部。

我们进行了其他方向的探索。一方面，我们针对 D2C 方案中语义化不足的问题，在大模型中进行了尝试，效果非常好。另一方面，我们利用大模型对自然语言处理的优势，根据文字描述生成交互逻辑代码。最终，我们选择了一个综合方案：自研一套 D2C 方案，重点解决布局不合理、固定宽度等问题，并结合 AI 优化渲染代码，同时利用 AI 根据需求文档生成逻辑代码。这样的方案既满足了我们对 UI 还原度和代码质量的要求，也提高了开发效率，并且能够适应后续需求的更新迭代。

我们的代码生成架构是一个自上而下的流程，它包括用户输入、中间生成、以及最终的目标代码输出。用户输入部分，我们目前支持 Sketch 和 Figma 这两种 UI 设计软件的稿件，以及需求产品文档。

从用户输入的 UI 稿件到中间的 D2C 描述及渲染代码的生成，整个过程是一个典型的 D2C 转换。我们首先获取 UI 稿件，然后对其中大量的图层数据进行解析，生成我们所需的 DSL 结构。在这个结构基础上，我们进行布局和样式的生成，最终得到包含布局和样式的 DSL。之后，我们将这个 DSL 翻译成目标代码，目前我们支持的目标代码包括 React Native、Shark（自研的跨端营销活动框架）、Taro 以及 ArkUI。在获得渲染代码之后，我们利用 GPT 进行语义化处理，以及代码组件的拆分和列表数据的循环。完成这些步骤后，我们再结合需求 PRD 和本地 SDK 代码库依赖 GPT 进行逻辑代码的生成。所有代码生成完毕后，开发会进入检查和补充开发环节。需求经过测试上线后，就会触发出码率的自动计算。

本次分享，我将重点介绍 D2C 过程中遇到的难点以及解决方案，同时展示 AI 如何提升代码质量，如何实现从 PRD 到代码的转换。

在 D2C 的过程中，我们遇到了以下几个难点，

1. 布局切割不合理。例如，当前这个例子我们期望的布局是 5 组，其中图片和标题应该是一组，并且能够用 list 数据循环渲染出来。但是 D2C 可能将它们分割成不同的部分，图片和文字被分离，或者因为宽度和间距的原因，图片被分成两组。这样的结构对于前端开发来说是不可接受的。

2. 大量的 Absolute 定位问题。由于图层交叉，D2C 可能会产生大量的绝对定位，这会导致后续布局难以编写。

3. 固定宽度问题也是一个挑战。D2C 生成的模块是固定宽度，这在不同分辨率的屏幕上可能会导致内容被截断或者铺满整个屏幕。

4. Class 类名不语义化的问题。D2C 算法生成的类名，如 view0、view1、view2、text0、text1 等，缺乏有效含义。

针对这些问题，我们采取了以下解决方案：

我们使用了业界常用的投影算法，依据侧投影进行水平和垂直两个方向的切割。结合投影算法和一些算法规则，解决了大部分的布局切割不正确的问题。下面主要讲解三类应用最多的算法和方法：

1、间距聚类，我们引入了 K-Means 聚类算法，在这个例子中，将水平切割产生的模块的间距作为输入值，输出不被切开的间距，从而保持图片和文本作为一个整体。

2、切割方向的选择：我们采用了轴向布局验证算法，选择切割方向的交叉轴方向，查看所有节点的对齐方式是否一致，选择不对齐节点数最少的方向进行切割。

3、识别组件辅助精准进行切割，我们识别出实际的组件，进行布局的合理生成。例如在这个例子中，我们识别出 Toast 组件并将其移除，然后针对剩余的组件进行是否为列表的识别。识别为列表的判断依据包含：从 DSL 判断子元素的相似度、是否等距以及面积是否相等。如果识别为列表，直接按照列表生成布局。

在 Absolute 布局的优化时，我们面对的主要问题是图层交叉导致的绝对布局问题。我们分析三个典型的案例，并为每个案例制定了相应的解决方案。

1. 紧凑文本。从视觉上看，设计稿中的文本并不交叉，但如果我们查看图层的实际高度，就会发现存在细微的交叉。如果整个页面都使用 Absolute 布局，代码的健壮性会非常差，稍微长一点的字段就会遮盖后面的内容。针对这种情况，我们的处理方式是调整行高，使得文本从交叉变为不交叉，从而能够正常地进行布局切割。在完成正常布局后，再在属性上还原行高。

2. 去除干扰元素。 例如，一个浮标组件本身使用 Absolute 布局是没有问题的，但由于图层交叉，使得下面的元素也变成了 Absolute 布局，这影响了我们的代码。在这种情况下，我们会先移除浮标，让下面的元素正常参与布局，然后再以 Absolute 布局将其还原回来。

3. 背景交叉问题。这个例子中，由于背景图层是渐变色，与下面的入住信息模块产生了交叉。我们通过拉伸背景图，将其从交叉关系转变为父子关系，这样就能进行正常布局计算。

在前端开发中，固定宽度的问题常常导致兼容性问题，尤其是在不同分辨率的屏幕上。如果给元素设置了固定宽度，实际业务数据中的几个额外字符可能会导致内容换行或挤压旁边的元素。即使我们生成了代码，这种固定宽度的问题也可能使得代码无法使用，进而影响我们的出码率。

为了解决固定宽度的问题，我们采用了弹性布局的方法。原本的布局生成依赖于元素宽度固定值和 Margin 来维持元素间的间距，但这并不是我们想要的结果，因为实际开发中我们不希望有过多的 Margin 或元素宽度固定值。因此，我们结合元素本身的信息、它与兄弟节点和父节点的位置关系，计算在 Flex 布局下应该使用的属性。也会根据一些条件判断元素的宽度是否确实需要保留。

我们也对算法生成的样式代码进行了优化，包括提取公共样式和删除冗余样式，以减少代码中的重复和冗余。

在拿到渲染代码后，我们利用 GPT 进行了一系列 AI 辅助的代码优化。这些优化主要包括两个部分：语义化和代码结构优化。

在编写 class name 时，开发者通常会选择像 main-container、ticket-section 这样具有描述性的名称。而 D2C 算法生成的可能是 view008 这样的无意义标识符。GPT 帮助我们将这些无意义的标识符转换成更易于理解和接受的语义化名称。实现这一过程，我们输入了一个简化的 DSL，并通过编写提示词让 GPT 生成新旧类名的映射。在获得新的类名后，我们会进行校验，确保没有重名或遗漏处理的类名，然后将这些回填到渲染代码中。最终的语义化结果比较符合开发者命名习惯。

D2C 生成的代码在实际应用中还需要进一步的组件拆分。例如，一段代码可能需要被拆分成一个 Tab 组件和一个列表循环。GPT 在这方面也提供了帮助，它不仅帮助我们进行组件拆分，还识别出了列表（list）和列表项（list item）。GPT 生成的代码能够根据 map 数据结构直接进行循环，并将业务数据与后端数据结合填充进去。与原始代码相比，GPT 优化后的代码整体可用性大大提高。

我们开发了一个 UI 还原度 DIFF 工具，旨在帮助开发人员更高效地检查和修正代码的 UI 还原度。这个工具的推出基于两个主要考虑：首先，开发人员需要一个方法来验证我们的 UI 还原度是否达到了预期；其次，由于生成的代码并非 100% 还原，开发人员在需要进行修正时，手动比对会非常耗时。这个 DIFF 工具提供了一个整体的还原度数值，这个数值是基于像素维度的对比得出的。此外，工具中还有一条可以拖拉的线条，通过拖动这条线，我们可以看到重影部分，这些重影是我们生成的渲染效果与 UI 设计稿效果的叠加。通过观察这些重影，我们可以判断出哪些元素没有对齐。点击这些元素后，开发人员可以精确地知道每个元素偏差了多少像素，宽度少了多少像素，这样也可能快速对样式进行修正。

在渲染代码生成之后，我们需要让这份代码具有交互性和逻辑性，使其能够动态地响应用户操作。这就是我们的 P2C（PRD to Code）部分所要解决的问题。让我们来看一下整体的生成流程。

首先，页面的所有交互行为和业务逻辑都源自于需求 PRD。我们首先对 PRD 进行解析，然后利用 GPT 梳理优化生成一份结构化的数据后，导入到 Checklist 中。这份 Checklist 数据将在本地知识库代码中检索出会用到的代码 SDK。结合刚刚生成的渲染代码以及接口数据，构建整个 prompt，进行数据脱敏后，让 GPT 进行代码生成。

在整个过程中，我们分析了两个主要的难点。第一个难点是如何有效地处理需求 PRD，提取信息并将其结构化。PRD 的功能描述是否完整是一个挑战。第二个难点是如何从需求 PRD 匹配到现有的私有代码库的 SDK。由于 SDK 数量众多，可能多达几百个，如果全部提供给 GPT，将会造成 token 的大量浪费。SDK 举例：登录校验、接口调用封装、分享、埋点等。

我们的需求 PRD 生成 Checklist 的过程开始于 Wiki 平台，我们会读取 Wiki 上的文档，从上到下解析整个文档，提取出我们需要的内容。由于我们的需求 PRD 遵循一定的格式，我们可以准确地提取出所需的部分。提取出来后，我们会将其格式化为我们自己制定的格式，并进行数据脱敏。

接下来，我们需要编写 prompt，引导 GPT 产出一份 Checklist 所需的数据。这个 prompt 过程实际上也是一个 COT 过程，我们要求 GPT 进行步骤拆解，构造出多层级结构，并确保每个步骤都是独立且完整的。根据我们的需求，GPT 会生成包含模块名、case 名、步骤和结果的格式化数据。

得到的这份结构化数据随后被输入到我们的 Checklist 系统中，生成一个可交互的结构。这个可交互的结构允许开发人员手动进行修正，比如通过拖拽调整条目的位置，或者编辑补充缺失的内容。这个界面的设计是为了提高后续代码生成的准确性，而且这份 Checklist 也能用于后续的测试用例生成。

这里是 RAG 的应用，它主要分为三个核心部分。

首先是知识库存储。由于 SDK 的数量较大，每个 SDK 都包含描述其功能的文本和示例代码。为了解决分块时 SDK 被截断的问题，我们将 SDK 的描述单独分块并进行向量化存储。

其次，如何从需求 PRD 中精准匹配到需要调用的 SDK。由于 Checklist 中包含了大量的业务描述，这些描述对于 SDK 的匹配很多干扰项。因此，我们让 GPT 对 checklist 的数据进行拆解和任务识别，识别出类似于接口调用、环境判断和埋点等功能点，将需求文档转化为与 SDK 更匹配的功能描述，形成 query list。然后，我们用每个 query 去向量数据库中匹配，找出最相关的 TOP5 结果。

最后，由于 TOP5 结果对后续代码生成仍有干扰，我们引入了 BGE Reranker large model 进行进一步排序，获取最匹配的结果。所有 query 完成这一步后，我们再让 GPT 帮助我们进行去重和匹配度确认，最终输出一个相关度较高的 query 和 sdk 集合。

将这份集合与前面的需求 Checklist 数据、渲染代码以及后端接口 API 数据结合起来，我们就可以进行整个逻辑代码的生成。GPT 生成的结果包括私有 SDK 引用、接口调用、交互行为（如 Tab 切换、点击后的页面跳转等），以及渲染部分。

在 C 端的应用效果方面，我们可以看到出码率的计算结果有所不同，这取决于各类业务场景。一些场景的出码率较高，这些通常包括样式规整的页面，比如列表循环等。这些页面的结构和样式较为标准化，因此更容易被自动化工具识别和生成。

相对而言，出码率较低的场景可能涉及到复杂的图表、隐藏的业务逻辑，或者动画。例如，一些页面可能包含复杂的动画效果，如“拍一拍”按钮的动态效果，或者轮播图等。这些动画效果目前不在我们的代码生成范围内，因此这些页面的出码率相对较低。

从系统架构图可以看出，我们选择了利用 AI 技术来进行代码生成。我们构建了一整套系统，这套系统不仅包括代码生成，还涉及到从项目维度对代码进行管理，包括项目中包含的页面以及这些页面的所有代码。

我们的系统覆盖了项目的整个生命周期，从代码生成到项目的整体发布，包括 Beta 测试、部署、线上部署，以及图片的 CDN 上传和代码的回滚等一整套解决方案。这些功能都在我们的系统中得到了集成和管理。篇幅有限，这里主要关注代码生成这一部分。

在 B 端代码生成，比如生成这样一个包含表单和表格的页面，我们提示词是如何编写的呢。

首先，我们会编写一些系统预设，这些预设包括设定角色为资深前端开发工程师，使用的框架可能是 Ant Design V4、Mobx 等。我们还会设定一些限制，比如生成注释的要求、生成文件要求、代码格式规范，以及 workflows 的输入输出规范。这些预设可以根据需求做调整。

用户 prompt 部分，是我们对需求的描述。以这个案例为例，我们首先进行业务抽象，然后结合接口信息用 Markdown 格式描述整个功能模块。例如，如果页面中有一个表单，我们就直接描述它是一个表单，并详细说明表单的元素，如角色名称的 key 和类型是什么。如果有一个按钮，我们描述按钮的点击交互，点击后调用的接口是什么，接口的地址、参数和返回数据是什么。拿到接口数据后，我们如何渲染表格，表格是否需要分页，列名是什么，对应的字段又是什么。

实际的需求应用过程中，我们会遇到下面这些问题。

1. 提示词编写成本高。如果让一个新同学去编写提示词，他可能不知道应该使用什么格式或者方式来正确描述需求，导致提示词的编写成本很高。提示词的质量与最终代码生成的质量密切相关。因此，我们需要解决提示词编写成本的问题。

2. 无法使用私有代码库。B 端系统需要使用我们自己的业务代码库，我们需要让 GPT 在生成的代码中使用这些代码库。

3. 复杂页面生成代码质量差。我们需要找到一种有效方式来描述功能复杂的页面，以便 GPT 能够准确地生成所需的代码。

为了提升提示词编写的效率，我们提供了两种方案。

第一种方案是根据接口 API 自动生成提示词，主要针对表单和表格这两种场景。我们会提供一份提示词的示例作为上下文，并结合用户输入的接口信息来自动生成提示词。选择表单和表格是因为请求参数往往来源于表单数据，而返回数据中的 list 结构通常用于渲染表格，所以我们可以根据接口信息自动生成相应的提示词。开发人员只需将自动生成的提示词与自己的需求进行比对，如有需要，进行增删改，这样的修改成本相比从头开始写可以降低至少 60%。

第二种方案是提供一些常见的提示词模板。这些模板适用于复杂的表单、表格、树形结构、图表等场景。开发人员可以直接使用这些模板，并根据具体需求进行一些修改。提示词模板也能给开发编写提示词带来极大提效。

在我们的业务场景中，私有组件库的应用采用了 few-shot prompting 的方案。我们会向用户提供一个代码库列表，用户选择代码库后，我们会将所选代码库的示例作为提示词的上下文提供给 GPT，以便 GPT 能够根据这些信息生成代码。采用这种方法主要是因为目前在我们的 B 端业务场景中，代码库的组件数不多，如果后续代码组件数量非常多，我们也会考虑使用 RAG 方案。

在处理复杂页面的代码生成时，我们采取了一种化繁为简的策略。比如这个页面，包含 6 个功能模块和 4 个后端接口。如果在一个 prompt 中描述这 6 个模块的内容、模块间的调用关系以及与接口的交互，prompt 会非常长，这样长的 prompt 给到 GPT，生成的代码质量并不理想。为了解决这个问题，我们的解决方案是将页面拆分成单独的模块，通过编排的交互方式，描述模块间的引用关系，然后对每个模块单独进行代码生成。这种方法比整体生成的质量要高很多，因为我们更精细地控制每个模块的生成过程。

我们开发的编排界面是实现组件编排的核心工具。在这个过程中，需要人工手动拆分模块，识别并定义模块间的调用关系。我们会先对子模块进行代码生成，然后将子模块的代码作为上下文，结合父组件的提示词来生成父组件的代码。这种逐个模块的代码生成方法确保了每个模块的代码都是高质量的。

在所有模块的代码生成完成后，我们会进入在线页面编辑器，这里包含了所有模块的文件，每个文件都已经完成了拆分。左侧是在线编辑器，右侧是实时预览沙箱。这个例子里面的页面在 GPT 生成代码后，无需任何修改即可运行，可用度非常高。在这个页面上，我们对比需求 PRD，检查功能是否有遗漏，或者是否有业务逻辑偏差。功能补充完整后，我们可以提交代码进行 Beta 发布和测试，并在测试完成后直接在系统上进行线上发布。

从 2 月到现在，我们 B 端的出码率整体呈上升趋势，已经有 100 多个页面上线，代码量达到几万行。出码率的提升得益于我们对提示词的优化、交互的优化，以及大模型的升级。

代码生成的持续发展上，主要包含以下三个方面：

1. 制定 UI 标准范式。开发与 UI 设计的协同工作对于生成高质量代码至关重要。

2. 逻辑代码生成方面，我们之前讨论的主要是营销活动的逻辑代码。对于主流程，由于其历史业务逻辑较为复杂，我们仍在开发和探索过程中。

3. C2C（Code to Code），包含老旧系统重构和多端代码生成。

系统的智能化提升，主要包含下面两点：

1. 我们将持续优化系统，提升系统的自动化能力以及交互模式，使其更加智能，降低对人工操作的依赖。

2. 多模态智能生成的应用。在 C 端，我们比较期待随着大模型的发展，后续支持用 UI 设计稿直接生成还原度高且质量高的代码。对于 B 端，目前除了提示词外，还支持根据原型图生成页面，我们期待未来可以通过语音等多模态输入直接生成页面，实现更高效、更智能的代码生成，从而进一步提升开发效率。

姚佳梅，在去哪儿网工作了 11 年，目前担任前端开发技术总监，主要负责国际机票前端开发业务、营销业务和一些公司基建项目。在公司期间，参与了公司营销和中后台低代码平台、Serverless 平台的建设、前端统一 UI 组件库建设、多端统一代码方案建设、国际机票 APP 端用户性能提升等项目，目前负责大前端代码生成项目，结合传统算法和 AI，打造了代码生成一体化平台，着力于公司前端开发的提效工作。

在 AI 大模型技术如汹涌浪潮席卷软件开发领域的当下，变革与机遇交织，挑战与突破共生。2025 年 4 月 10 - 12 日，QCon 全球软件开发大会将在北京召开，以 “智能融合，引领未来” 为年度主题，汇聚各领域的技术先行者以及创新实践者，为行业发展拨云见日。现在报名可以享受 8 折优惠，单张门票立省 1360 元，详情可联系票务经理 18514549229 咨询。