如何实现代码自动生成？_设置输入数据和输出数据自动生成代码-CSDN博客

本文链接：https://blog.csdn.net/m0_72758098/article/details/137683522

本文讨论了如何通过机器学习和自然语言处理技术，从大量的训练样本中学习需求的标准化表达，实现从P2C（人到代码）到D2C（设计到代码）的转变，以降低NLP分析难度并提升自动化出码的效率。作者强调了运营在这一过程中的关键角色，以及中文编排和DSL设计在简化逻辑表达中的作用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

**获取大量自然语言意图分析的训练样本：**对于pd的同一个需求可以用一千个不同的句子来表达，同样一个需求表达也可以对应一千种实现方式。要想将自然语言的需求描述同实际产品表达进行准确关联需要对大量的样本数据进行学些
**将所有自然语言逻辑使用统一的DSL描述：**如开篇提到的3d打印，统一化的设计稿是实现转换的基石，因此一套描述需求的标准化DSL是必不可少的。

推导

既要让pd 录入需求时能录入的舒服，又得要求能按需出码，似乎两者是矛盾的，但是困难也都不可能是一朝就能解决掉的。

所以我们打算分步骤实现目标，首先我认为短时间对需求的结构化信息分析还很难达到从局部到整体的突破，文本的灵活性也会带来诸多问题，比如模块信息的增删改造成的信息错位，因此我们觉得第一步要从以P2C为核心出码的逻辑变为以D2C（即Design2Code - imgcook），因为视觉是产出是最终产出物比较接近终态的一个阶段，通过视觉我们将会更容易分析缺失部分的内容，然后结合P2C内容从中寻找补全的关键信息，比如一个视图是否是ScrollView 单从视觉上很难辨认，需要结合从prd 中获取的信息，甚至prd 中没有详细描述时还需要跟俊产品属性进行分析，例如这是一个音乐播放器的界面，那么其中应该包含什么功能组成，哪些功能组成一定会是ScrollView，这就需要一些知识依赖的输入，而这些宝贵数据资产都是需要脚踏实地不断积累的。

我觉的D2C和P2C的结合一定是1+1>2的，对于D2C视觉出码有了知识依赖做背景，对于视觉稿的整体判断及组成可以有了很好的依据，另外P2C也能够基于准确的视觉做精准的逻辑补充。因此以视觉稿为主导出码，以prd为辅助出码的思想浮出水面。

即我们第一阶段重修了目标：将原本的 AutoCode 目标先降低为 NoCode = 通用逻辑组件 + ProCode(AI)目标。

这个过程通俗来讲就是 通用组件 + 配置信息 的模式，配置信息即 ProCode 的部分，该部分即为需要 AI 自动产出的内容。因此想要完成自动出码，就需要对 ProCode 的部分进行样本制造和监督学习。

我们来总结一下我们的三步走计划：

需求的结构化收集（为了降低NLP的分析难度）
创造结构化需求到标准逻辑表达的样本（为机器学习ProCode部分提供充足样本）
通过机器学习对样本进行学习，以达到AutoCode的目标（长期目标）

即我们需建立要两个平台，我们称之为P2C 的 2.0 代和 1.0 代。P2C 1.0 负责打标需求数据，并为 2.0的智能出码提供庞大准确的数据。而 P2C 2.0则主要进行需求的结构化收集并与1.0 的样本进行关联学习，训练出码模型，最终达到创作和自动完成需求的目的。

两个平台所代表的关键词分别是：

P2C1.0：精确收集，精确产出
P2C2.0: 开放收集，创新产出

那么精确收集样本就成为我们 P2C 1.0 的主要工作方向。

打标样本一定要从实践出发，并能在该阶段帮助需求真实的进行产出，即我们提供的打标平台能真实的完成业务需求，因此我们决定开发一个可视化编排的平台，通过该平台来收集样本数据，并且可以顺手把需求也消化掉。

那么问题来了，这么多的样本打标的工作到底由谁来完成呢？

我们通过调研发现运营的角色在可视化编排方向上，是有着非常高契合度的。为什么呢？其一，运营都具备模块搭建的能力。其二，很多运营的需求都不一定有机会能够落地，主要原因是开发资源不足导致的，这也是多年来存在的业务与技术矛盾，前端这十年来一直朝着工程化、规范化、模块化的方向发展，本意是为了更有效的重用业务能力以达到解放生产力，而产品却一直在朝着丰富化、精细化的方式来运作，各个业务方不再是单单为了满足功能诉求而更讲求的是用户心智。最终致使现在对一个个性化需求的提出往往是用一个标准化方案来落地的。当业务方为资源不足妥协时，其业务整体感官也会越来越平庸化、趋同化，最终导致产品对用户的心智弱化。

因此对于运营的诉求是希望能将创新和业务思考带入到自己的产品中，而不是简单的拆解为一个个的标准实现。如何拉大与竞争对手的运营差异、交互差异、创新差异、视觉差异才是对于运营真正的核心价值。

在AI 的介绍篇中我们讲了对于复杂的逻辑关系我们依然可以采用抽象的组件化来实现，而这部分实现对比传统搭建体系的组件颗粒度更细，传统搭建一般是对模块的自定义配置，而在我们的编排体系里最小的组件应该是原子化的不可再被拆解的，比如一个Image 组件，而对组件的配置可以是一段编排好的逻辑实现，因此它能有着同代码一样的绝对灵活性。

拆解

在前面3D打印的内容中我们提到，自动化统一化生产的前提一定是要有一个标准化的表达做支撑的，这个中间 DSL该如何设计才能承载住全量的需求内容呢？另外通过什么样的方式可以让运营能接受和理解这部分的逻辑编排？

首先我们解决的问题一定是有边界的是处在一个业务领域的，并在这个业务域下进行分析。因此我们分析了一下我们最常见的业务形态-模块。而据统计“相同业务能力，不同技术实现”的模块在整个天马体系中的占比非常的高，单单拿通用商品坑来看就有上千个，而这些模块大部分都是相同的逻辑实现，也有很多是处于不同时期的技术产品。
一个模块在前端的开发设计里，大概可以分为4部分，通用组件，通用Action，视觉代码，驱动逻辑。
我们可以看到视觉和通用组件以及Action都是已经有了的，变动周期比较低。而驱动逻辑部分是是业务中的主要实现逻辑，如何让这部分逻辑能让运营进行产出呢？
首先我们将这部分能力进行一个拆解，我们得出一个初步的结构，就是由运算符 + 表达式 + 基础action + pipeline 组成的表达结构，这个表达也可以组成一个新的action，再加上trigger，整体就完成一个workflow的能力了。

new Expression = Variable + Operator + Expression + Pipeline

new Action = Expression + Action

Workflow = Action + Expression + Trigger

业务模块的四个部分中，驱动逻辑就是我们主要核心产出的内容，根据我们的经验这部分ProCode 大部分都是表达式 Expression 内容。因此我们只要能让运营能够自主的完成 ProCode 部分的编排即可高级定制需求的产出物。

让运营完成所有的ProCode 也显然是不现实的，但是对于IFTTT 这种简单的逻辑表达，只要将这部分内容的表达可以使用更接近自然语言的表达方式，自然会降低整个的理解难度。

验证

为了验证我们的拆解过程，我们把pmod 分组下的9千多个仓库进行一个拆解分析，发现平均每个模块都有逻辑表达 52.6 个，函数表达 37.55 个， if 语句 35.5 个，这三大部分实现是符合我们的拆解预期的。这部分的逻辑大部分都是可以用IFTTT 的模型套用。

而一个复杂的模块，光有IFTTT 是不够的，逻辑的表达是具有很强的依赖上下文结构的，但是为了降低整体的复杂度，我们需要对逻辑进行拍平表述，对拍平后的逻辑我设计了一套 StateLink的工作流管理库，这里就不详细介绍了。

最后我们通过一个 When + Then + Trigger 三元素的DSL就能描述我们所有的业务逻辑部分了。这个DSL也为我们2.0 版的出码提前做好了准备，同时也能应对因技术升级而导致模块需要重新开发的尴尬。

为了让运营能够用得懂用的轻松，我们采取了中文编排的方式，即首先根据选取的视觉对象进行一些具象的操作表达。

为什么我们决定采用中文编排呢？中文编排是怎样一个编排方案呢？

我们将pd需求的一句可以拆分为上图这样的表达，对于使用者只需要顺着决策树表达自己的意图即可，类似于输入法，当我们输入一句话的时候，输入法通过预测词可以表达所有的表达意图，比如输入“我”，那么一定能够枚举“我们”、“我的”、“我…”等词并可以一直预测下去，而每个词的预测都是一个有限的枚举，同样pd在描述一个需求时我们也可以根据语法和目的预测出所有的可能项。

现状

我们将常用的逻辑表达拆解为中文关键词，通过关键词关系可以让运营通过编排一句话的形式来表达事物的逻辑关系。

我们目前已初步完成了第一个版本的运营逻辑编排平台，通过该平台可以先让运营能够进来满足一些简单的需求。

运营主要通过可视化的方式对元素上的逻辑进行中文关键词表达的编排

案例

“爆款来了”会场中的6个模块，由运营自行编排发布上线。

未来

虽然人工智能目前还有很多的不足和局限性，但随着深度学习的不断进化，我相信从需求理解到需求实现全过程的自动化会离我们越来越近。

我相信未来不仅可以实现从需求到代码的智能生产，也将会从智能生产覆盖到智能视觉、智能测试、智能运营的全链路智能场景。

就像我们的大厨，一开始是需要人工切菜人工炒菜，后来是人工按菜谱备料再由机器辅助炒菜，再然后是直接输入菜谱机器就能自动根据菜谱备料和炒菜，而未来只要描述想吃什么口味就能自动做出符合用户的菜。

P2C的未来就是将过程描述简化为目标描述，一个需求只需要表达诉求和目标而不再需要描述详细的生产过程及规则，只需简单的几句话我们就能够知道用户想要什么该产生什么样的交付物了，这就是我们未来的“智能大厨”。

频道与D2C智能 F(x) 团队

我们是阿里巴巴-淘系技术部-频道与D2C智能 F(x) 团队，致力于前端智能化领域的探索和实践，赋能淘宝、天猫、聚划算等日常与大促（如双 11 ）业务，是淘系前端智能化实践的领路人，也是阿里经济体前端委员会智能化方向的核心团队。目前团队有较多高校和海外背景的技术小二，专业领域涉及前端、算法、全栈等。我们在 D2C（Design to Code）领域开放了 Imgcook平台，在逐步释放阿里生态的前端生产力；我们也与 Google 的 tensorflow 团队保持长线合作，基于 tfjs-node 之上，开源了我们的前端算法工程框架 Pipcook，在引领前端行业向智能化时代迈进。

既然最后打算放个招聘贴，那么对于你一定想知道的是关于老板的故事，那么我就简单放上一些和老板相关的近期活动吧：