限定ダウンロード！ Alibaba は AI をどのように活用してコードを記述しているのでしょうか?

[[315476]]

今年のアリババ経済フロントエンド委員会の4つの主要な技術方向の1つとして、フロントエンドのインテリジェント化の方向が言及されると、フロントエンドはAIと組み合わせて何ができるのか、どのように行うのか、将来フロントエンドに大きな影響を与えるかどうかなど、好奇心を抱かずにはいられない人もいるでしょう。この記事では、「設計案からの自動コード生成」シナリオを例に、背景分析、競合製品分析、問題の分解、技術的解決策など、さまざまな角度からこれらの問題に焦点を当て、関連する考え方とプロセスの実践について詳しく説明します。

背景分析

業界では機械学習のトレンドが本格化しており、「AIこそが未来の総意」という言葉が大手メディアでも頻繁に登場しています。単純で反復的な仕事は AI の影響を受ける可能性が高くなります。さらに、ホワイトカラーの仕事はブルーカラーの仕事よりも影響を受けやすい。これは、ブルーカラーの仕事ではロボットとソフトウェアおよびハードウェア関連技術の両方のブレークスルーが実現に必要になる可能性があるのに対し、ホワイトカラーの仕事では通常、ソフトウェア技術のブレークスルーのみで実現できるためである。 AIはフロントエンドの「ホワイトカラー」業務にどのような影響を与えるのでしょうか？

[[315477]]

2010年を振り返ると、ソフトウェアはほぼすべての業界を「飲み込み」、近年ソフトウェア業界に繁栄をもたらしましたが、2019年までにソフトウェア開発業界自体がAIに「飲み込まれ」つつあります。ご存知のとおり、DBA分野では質問するだけで特定の分野のSQL文を生成できるQuestion-to-SQLが登場しています。機械学習に基づくソースコード分析ツールであるTabNineは、コード生成を支援できます。デザイナー業界もP5 Bannerのインテリジェントデザイナー「Luban」をリリースしており、テスト分野でのインテリジェントな組み合わせも刺激的です。フロントエンド分野についてはどうでしょうか?

次に、私たち全員がよく知っているシナリオ、つまり設計図からのコードの自動生成（Design2Code、以下D2C）について触れなければなりません。アリババ経済フロントエンド委員会-フロントエンドインテリジェンスディレクションの現在の段階では、AIを使用してフロントエンド機能の効率とアップグレードを向上させ、単純な反復作業を排除し、フロントエンドエンジニアがより困難な作業内容に集中できるようにすることに重点が置かれています。

関連製品分析

2017 年、Pix2Code の画像からコードへの変換に関する論文が業界で白熱した議論を巻き起こし、設計プロトタイプから直接ソース コードを生成する方法が説明されました。その後、このアイデアをベースにしたScreenshot2Codeに似た作品がコミュニティ内で続々と登場。2018年には、Microsoft AI Labがスケッチからコードを作成するツールSketch2Codeをオープンソース化した。同年末には、デザイン案からフロントエンドのコードをインテリジェントに生成できる新参者Yotakoもその可能性を示した。機械学習が初めて、侮れない姿勢でフロントエンド開発者の視野に正式に入ったのである。

上記の分析に基づいて、次のようなインスピレーションを得ることができます。

1. ディープラーニングの現在の画像におけるターゲット検出機能は、より粒度の高い再利用可能なマテリアル認識（モジュール認識、基本コンポーネント認識、ビジネス コンポーネント認識）に適しています。
2. 画像から直接コードを生成する完全なエンドツーエンドモデルは非常に複雑で、生成されたコードはあまり使いやすくありません。生成されたコードの産業レベルの使いやすさを実現するには、より詳細な階層化分解とマルチレベルのサブネットワークモデルの連携が必要です。短期的には、設計案からコードを生成してD2Cシステムを構築できます。
3. モデルの認識能力が期待される精度を達成できない場合、設計案の人工ボトムルールプロトコルを使用できます。一方で、人工ルールプロトコルは、ユーザーが強力に介入して望ましい結果を得るのに役立ちます。他方、これらの人工ルールプロトコルは実際には高品質のサンプル注釈であり、モデルの認識精度を最適化するためのトレーニングサンプルとして使用できます。

問題の分解

設計ドラフトからコードを生成する目的は、AI がフロントエンドの機能的役割を支援して効率とアップグレードを向上させ、単純な反復作業コンテンツを排除できるようにすることです。まずは分析してみましょう。従来のフロントエンド開発者、特にCサイドの業務に携わる開発者の場合、一般的なワークフローと日々の業務内容は次のようになります。

「従来型」フロントエンドの一般的な開発ワークロードは、主にビューコード、ロジックコード、データジョイントデバッグ（Serveless製品の開発時に予想されるデータインターフェース開発も含む）の領域に集中しています。次に、それらを1つずつ分析します。

コードを表示

ビュー コードの開発には通常、ビジュアル ドラフトに基づいて HTML および CSS コードを記述することが含まれます。効率を上げるにはどうすればよいでしょうか。UI ビュー開発で反復的な作業に直面すると、コンポーネント化やモジュール化などのソリューションが自然に思い浮かび、素材をカプセル化して再利用します。このソリューションに基づいて、さまざまな UI ライブラリが蓄積され、さらに高度なビジュアル アセンブリの製品パッケージが構築されます。ただし、再利用された素材ではすべてのシナリオの問題を解決することはできません。パーソナライズされたサービスやパーソナライズされたビューが至る所で盛んになっています。問題そのものに立ち向かうために、使用可能な HTML および CSS コードを直接生成することは可能でしょうか?

これは、業界が常に解決しようとしている命題です。レイヤーの基本情報は、設計ツールのプラグインを開発することでエクスポートできます。ただし、ここでの主な難しさは、設計ドラフトに対する要件が高く、生成されたコードの保守性が低いことです。これが核心的な問題です。引き続き分析してみましょう。

★設計案には高い要求がある

デザイン案に対する要求が高ければデザイナーのコストが増加し、フロントエンドの作業負荷がデザイナーに移ることになり、プロモーションが非常に難しくなります。実現可能なアプローチの 1 つは、CV (Computer Vision) とレイヤー情報のエクスポート方法を組み合わせて、デザイン ドラフトの制約を取り除くことです。もちろん、デザイン ドラフトの最適な要件は、デザイナーを必要とせず、画像を直接エクスポートすることであり、これは私たちにとっても理想的なソリューションです。また、静止画像から適切なレイヤーをそれぞれ分離しようと試みてきましたが、現時点では実稼働環境での可用性はあまり高くありません (小さなターゲットの認識精度や複雑な背景抽出などの問題は解決中です)。結局のところ、デザイン ドラフトのメタデータは、画像から抽出して処理したメタデータよりもますます正確になっているためです。

★ 保守性の問題

生成されたコード構造は、一般的に保守性の課題に直面します。

• 合理的なレイアウトネスト: 絶対配置から相対配置、冗長ノードの削除、合理的なグループ化、ループ判断などを含む。
• 要素の適応: 要素のスケーラビリティ、要素の配置、要素の最大幅と高さの許容範囲。
• セマンティクス化: クラス名のマルチレベルセマンティクス化。
• スタイル CSS 表現: 背景色、角丸、線などは CV などの方法を使用して分析および抽出できます。できるだけ画像を使用せずに CSS を使用してスタイルを表現します。

…

これらの問題を細分化すると、さまざまなカテゴリに分類され、具体的に解決されます。解決策は無限にあるように思えますが、幸いなことに、これまでに見つかった主要な問題は基本的に解決されています。この部分の能力の実現は知能とは何の関係もなく、せいぜいレイアウトアルゴリズムに関連したエキスパートルール測定システムであるように思われる、と多くの人が疑問を抱いています。そうです。この段階では、この部分はルール システムに適しています。ユーザーにとって、レイアウト アルゴリズムは 100% に近い可用性が必要です。また、ここで関係する問題のほとんどは、無数の属性値の組み合わせであり、ルールを使用するとより制御しやすくなります。モデルを使用する必要がある場合、これは多重分類問題として定義できます。同時に、あらゆるディープラーニング モデルの適用には、まず明確な問題定義プロセスが必要であり、問​​題のルールを明確に定義することは必須のプロセスです。

ただし、ルールを解くのが難しい場合は、モデルを使用して問題の解決を支援することができます。たとえば、合理的なグループ化（以下に示す）やループ項目の判断の場合、実際にはさまざまな状況で誤判断が頻繁に発生し、アルゴリズムのルールを列挙することが難しいことがわかりました。これには、要素間の文脈的な意味認識が必要であり、これはモデルが現在解決している重要な問題でもあります。

合理的なグループ化の指示

ロジックコード

ロジック コードの開発には、主にデータ バインディング、アニメーション、ビジネス ロジック コードの記述が含まれます。一般的に、効率の面で改善できる部分は、基本コンポーネント、ビジネス コンポーネントなどに組み込むことができる再利用可能なアニメーションとビジネス ロジック コードにあります。

• インターフェースフィールドバインディング：実現可能性の観点から見ると、まだ高いです。ビジュアルドラフト内のテキストや画像がどの候補フィールドに属するかを判断することで実行できますが、インターフェースデータフィールドバインディングはビジネス指向が強すぎて汎用性があまりないため、コスト効率が良くありません。
• モーション効果：この部分の開発入力はインタラクティブドラフトであり、一般的なモーション効果の配信形式はさまざまです。アニメーションGIFデモンストレーション、テキスト説明、口頭などがあります。モーション効果コードの生成は、視覚的な形式での生成に適しています。直接インテリジェント生成には参照ベースがなく、入出力比率は短期範囲内ではありません。
• ビジネス ロジック: 開発のこの部分は主に PRD または PD によって説明されるロジックに基づいています。ロジック コードのこの部分をインテリジェントに生成する場合、欠落している入力が多すぎます。このサブフィールドでインテリジェンスが解決できる問題を確認する必要があります。

★ 論理コード生成についての考察

理想的な解決策は、もちろん、詩、絵画、音楽などの他の芸術分野と同様に履歴データを学習し、PRD テキスト入力に基づいて新しいロジック コードを直接生成することですが、生成されたコードはエラーなしで直接実行できるでしょうか?

現在、人工知能は急速に発展していますが、解決できる問題はまだ限られており、人工知能が得意とする問題の種類として問題を定義する必要があります。強化学習は戦略最適化問題に優れています。ディープラーニングは現在、コンピュータービジョンにおける分類問題やターゲット検出問題の解決に優れており、テキストにおけるNLP（自然言語処理）にも優れています。

ビジネス ロジック コードに関して、まず思い浮かぶのは、LSTM (Long Short-Term Memory) と NLP を使用して、履歴ソース コードの関数ブロックのコンテキスト分析を実行し、コード関数ブロックのセマンティクスを取得することです。VS Code のスマート コード リマインダーと TabNine は、同様のアイデアです。

さらに、問題の分析では (下の図に示すように)、ビジネス ロジック分野のインテリジェンスは、ビュー内のロジック ポイントの場所 (タイミング) を識別し、ビューに基づいて論理セマンティクスを推測するのにも役立つことがわかりました。

要約すると、現在のインテリジェンスの役立つポイントをまとめてみましょう。

• 頻繁に出現する機能ブロック（ロジックブロック）のセマンティクスは、過去のソースコードを解析することで推測されます。実際に得られるのは、コンポーネントライブラリや基本機能ブロックのセマンティクスです。これにより、コード編集時にコードブロックの推奨が可能になります。
• 再利用可能なロジックポイントの一部は、ビジュアルドラフトから推測できます。たとえば、ここのフィールドバインディングロジックなどです。フィールドは、テキストセマンティクスNLPに基づいて推測できます。一部の画像要素は、対応する画像フィールドへの限定された範囲内での画像分類に基づいて推測できます（下の例の雰囲気変更画像やロゴ画像など）。同時に、ここでのクーポン収集ロジックなど、再利用可能なビジネスロジックコンポーネントも識別できます。

したがって、この段階では、ビジネス ロジック生成で解決できる問題は比較的限られており、特に新しいロジック配置で新しいビジネス ロジック ポイントが出現し、これらの参照ベースがすべて PRD または PD の頭の中にある場合はなおさらです。したがって、ビジネス ロジックを生成するための現在の戦略は次のとおりです。

• フィールド バインディング: デザイン ドラフト内のテキストと画像、特にテキスト部分のセマンティック分類をインテリジェントに識別します。
• 再利用可能なビジネス ロジック ポイント: ビューに基づいてインテリジェントに識別され、ビューによって自由に組み立てられます。これには、小さくて美しいロジック ポイント (1 行の式、または通常はコンポーネントにカプセル化するには不十分な数行のコード)、基本コンポーネント、およびビジネス コンポーネントが含まれます。
• 再利用できない新しいビジネス ロジック: PRD では構造化された (視覚化された) コレクションが必要です。これは難しい作業であり、まだ試行中です。

まとめ

現在、HTML + CSS +一部のJS +一部のDATAをインテリジェントな方法で自動的に生成する主な分析は上記のとおりであり、これがDesign to Codeの主なプロセスです。内部プロジェクト名はD2Cと呼ばれ、以降の一連の記事ではこの略称を使用します。グループ内外のランディング製品の名前はimgcookです。近年、主流のデザインツール（Sketch、PS、XDなど）のサードパーティプラグイン開発機能が徐々に成熟し、ディープラーニングの急速な発展が人間の認識のトレンドをも上回っていることは、D2Cの誕生と継続的な進化を強力に後押ししています。

物体検出 2014-2019 論文

技術的ソリューション

上記のフロントエンドインテリジェンス開発の分析に基づいて、既存のD2Cインテリジェントテクノロジーシステムの機能概要を作成しました。これは主に次の3つの部分に分かれています。

認識力：つまり、設計図を認識する能力。設計ドラフトをインテリジェントに分析して、レイヤー、基本コンポーネント、ビジネス コンポーネント、レイアウト、セマンティクス、データ フィールド、ビジネス ロジックなどの多次元情報を取得します。インテリジェント認識が不正確な場合は、視覚的な手動介入によって補完および修正されます。これは、一方では低コストの介入を視覚化して、可用性の高いコードを生成するためです。他方では、これらの介入後のデータはラベル付けされたサンプルであり、これによってインテリジェント認識の精度が向上します。

表現力：主にデータ出力とエンジニアリング部品へのアクセスを担当

DSLを使用して標準構造化記述をSchema2Codeに適合させる

IDEプラグイン機能によるプロジェクトアクセス

アルゴリズムエンジニアリング：D2C に必要なインテリジェント機能をより適切にサポートするために、高頻度機能はサービス指向であり、主にデータの生成と処理、およびモデルサービス部分を含みます。

サンプル生成: 主にさまざまなチャネルからのサンプルデータを処理し、サンプルを生成します

モデルサービス: 主にモデルAPIカプセル化サービスとデータ返却を提供する

フロントエンドのインテリジェントD2C機能の概要と階層化

ソリューション全体では、同じデータ プロトコル仕様 (D2C スキーマ) セットを使用して各レイヤーの機能を接続し、識別を対応するフィールドにマッピングできること、および表現段階でコーディング エンジンやその他のソリューションを通じてコードを正しく生成できることを保証します。

インテリジェント認識技術の階層化

D2C プロジェクト全体において、中核となるのは、上記の認識機能部分のうち、機械知能認識部分です。このレイヤーは、次のように分類されます。以降の記事シリーズでは、これらの細分化されたレイヤーを中心とする内部実装原理について詳しく説明します。

• 材質認識層: 主に画像認識機能 (モジュール認識、原子モジュール認識、基本コンポーネント認識、ビジネスコンポーネント認識) を通じて画像内の材質を識別します。
• レイヤー処理レイヤー: 主に設計図や画像内のレイヤーを分離し、前のレイヤーの認識結果と組み合わせてレイヤーのメタ情報を整理します。
• レイヤー再処理レイヤー: レイヤー処理レイヤーのレイヤーデータをさらに正規化します。
• レイアウト アルゴリズム レイヤー: 2D の絶対配置レイヤー レイアウトを相対配置および Flex レイアウトに変換します。
• セマンティック レイヤー: レイヤーの多次元機能は、コードを生成するときにレイヤーをセマンティックに表現するために使用されます。
• フィールド バインディング レイヤー: レイヤー内の静的データをデータ インターフェイスと組み合わせて、インターフェイスの動的データ フィールド バインディング マッピングを実行します。
• ビジネス ロジック レイヤー: ビジネス ロジック識別と表現を通じて、構成されたビジネス ロジックのビジネス ロジック コード プロトコルを生成します。
• コード出力エンジン層: 各層でインテリジェントな処理を行った後、最終的にコードプロトコルを出力し、表現機能 (プロトコルからコードへのエンジン) を通じてさまざまな DSL コードを出力します。

D2C識別機能技術の階層化

技術的な問題点

もちろん、不完全な認識と低い認識精度は、D2C では常に共通の話題であり、私たちの中心的な技術的問題点でもあります。私たちは、この問題を引き起こす要因を次の観点から分析しようとしています。

1. 認識問題の定義が不正確: 問題の定義が不正確であることが、モデル認識の不正確さに影響を与える主な要因です。サンプルとモデルが主な要因であると多くの人が考えていますが、それ以前に、問題の初期定義に問題がある可能性があります。認識要求モデルが適切かどうか、適切である場合は、関連するルールを明確に定義する方法を判断する必要があります。
2. 高品質のデータセットサンプルの不足: 認識レイヤーにおけるさまざまな機械知能認識機能は、さまざまなサンプルに依存する必要があります。では、サンプルはフロントエンド開発シナリオをいくつカバーできるでしょうか? 各シナリオのサンプルデータの品質はどの程度でしょうか? データ標準は統一されていますか? 機能エンジニアリング処理は統一されていますか? サンプルに曖昧さはありますか? 相互運用性とは何ですか? これらは現在私たちが直面している問題です。
3. モデルの再現率が低く、誤判定が多い: 多くの場合、1 つのモデルですべての認識問題を解決しようと、さまざまなシナリオでさまざまな種類のサンプルをトレーニングとして積み重ねます。ただし、これにより、モデルの一部の分類の再現率が低くなることが多く、あいまいな分類に対して誤判定が発生します。

★問題の定義

ディープラーニングにおけるコンピュータビジョンモデルは、現在、分類やターゲット検出の問題を解決するのに適しています。ディープモデルを認識問題に使用するかどうかを判断する前提は、判断して理解できるかどうか、問題が曖昧かどうかなどです。人間が正確に判断できない場合、この認識問題は適していない可能性があります。

ディープラーニング分類が適切であると判断された場合、すべての分類を明確に定義し続ける必要があります。これらの分類は、厳密で排他的であり、完全に列挙可能である必要があります。例えば、画像の意味化という命題に取り組むとき、一般的な画像の ClassName の一般的な慣習的な名前は何でしょうか? 分析プロセスは、例えば次のようになります。

• ステップ 1: 関連するデザイン案をできるだけ多く見つけ、その中の画像タイプを 1 つずつ列挙します。
• ステップ 2: 画像の種類を適切に分類します。これは最も議論の多い領域です。定義が不十分であいまいな場合、モデルの精度に最も深刻な問題が発生します。
• ステップ 3: 各タイプの画像の特徴を分析して、これらの特徴が典型的なものであるかどうか、また最も重要な特徴ポイントであるかどうかを判断します。これは、後続のモデルの推論機能と一般化機能に関係します。
• ステップ 4: 各タイプの画像にデータ サンプル ソースがありますか? ない場合、自動的に作成できますか? データ サンプルが利用できない場合は、モデルの使用は適切ではありません。代わりにアルゴリズム ルールやその他の方法を使用して、まず効果を確認できます。

D2C プロジェクトには、このような問題が数多く存在します。問題の定義自体が非常に正確で、科学的な参照ベースを持っている必要があります。学ぶべき前例がないため、それ自体が困難です。まずは既知の経験で試してみて、ユーザー テストで問題が見つかったら修正するしかありません。これは、継続的な反復と改善を必要とする問題点です。

★サンプル品質

サンプル問題に関しては、データセットのこの部分について標準仕様を確立し、シナリオ別に多次元データセットを構築し、収集したデータを統一的に処理・提供し、標準化されたデータシステムを確立したいと考えています。

このシステムでは、統一されたサンプルデータ保存形式を使用し、さまざまな問題（分類、ターゲット検出）に対して統一されたサンプル評価ツールを提供して、各データセットの品質を評価します。特定のモデルについては、より優れた特徴エンジニアリング（正規化、エッジ増幅など）を採用して処理できます。また、将来的には、同様の問題のサンプルを循環させてさまざまなモデルで比較し、さまざまなモデルの精度と効率を評価できるようになることを期待しています。

データサンプルエンジニアリングシステム

★モデル

モデルの再現率と誤分類の問題に対処するために、シナリオを収束させて精度を向上させるように努めました。多くの場合、異なるシナリオのサンプルには特徴の類似点があったり、分類のいくつかのローカルな主要な特徴ポイントに影響を与えたりして、誤判定や再現率の低下を招きます。収束シナリオを通じてパターン認識を実行することで、モデルの精度を向上させたいと考えています。シナリオは、ワイヤレス C エンド マーケティング チャネル シナリオ、ミニプログラム シナリオ、PC ミッドエンドおよびバックエンド シナリオの 3 つに絞り込まれました。ここで紹介したいくつかのシナリオの設計パターンはそれぞれ特徴があり、シナリオごとに垂直認識モデルを設計することで、単一シーンの認識精度を効果的に向上させることができます。

D2Cシナリオ

プロセス思考

ディープモデルを使用しているため、より現実的な問題があります。モデルの一般化能力が不十分で、認識精度がユーザーを100％満足させることができません。将来的にこの認識できないサンプルデータのバッチを継続的に補充することに加えて、その前に何ができるでしょうか？

D2C の全体的な復元リンクでは、認識モデルについても、手動合意 > ルール戦略 > 機械学習 > ディープ モデルという方法論を順守しています。つまり、ディープ モデルの認識効果を他の手段でカバーできる一連のプロトコルまたはルールを設計し、モデル認識が不正確な場合でもユーザーが要求を完了できるようにします。たとえば、設計ドラフト内のループを識別する必要があるとします。

• 初期段階では、設計案のループ本体プロトコルを手動で合意することで、
• レイヤーのコンテキスト情報に応じて、いくつかのルールを使用して、それがループ本体であるかどうかを判断できます。
• 機械学習のレイヤー機能を使用することで、ルール戦略の上流戦略の最適化を図ることができます。
• ループ本体の正と負のサンプルをいくつか生成し、ディープモデルを通じて学習する

その中で、手動で合意された設計草案プロトコルの解析は最も優先度が高く、これにより、後続のプロセスが誤った認識によってブロックされたり妨害されたりすることがないようにすることもできます。

ビジネスランディング

2019 ダブルイレブン ローンチ

今年の双十一シナリオでは、当社のD2Cは、メイン会場、業界会場、マーケティングゲームプレイ会場、リスト会場など、TmallとTaobao会場の新しく追加されたモジュールをカバーし、ビューコードと一部のロジックコードの自動生成も行いました。統計範囲内では、D2Cコード生成が大きな割合を占めました。現在、コードを手動で変更する主な理由は、新しいビジネス ロジック、アニメーション、フィールド バインディングの推測エラー (フィールドの標準化が不十分)、ループの推測エラー、スタイルの適応変更などです。これらの問題も、今後徐々に改善する必要があります。

D2C コード生成ユーザーの変更

着陸全体の状況

2019年11月9日現在、弊社外部製品imgcookの利用状況データは以下の通りです。

• モジュールの数は 12,681 で、毎週約 540 の新しいモジュールが追加されます。
• ユーザー数は4,315人で、毎週約150人の新規ユーザーが追加されています。
• カスタム DSL: 合計 109 件

現在、以下のサービスをご利用いただけます。

• デザイン ドラフトのフルリンク復元: Sketch および PhotoShop プラグインを使用してワンクリックでデザイン ドラフト レイヤーをエクスポートし、カスタマイズされた DSL コードを生成します。
• 画像リンクの復元: ユーザーがカスタマイズされた画像やファイルをアップロードしたり、画像リンクを入力したりできるようにサポートし、カスタマイズされた DSL コードを直接復元して生成します。

その後の計画

設計草案の要件を引き続き引き下げ、設計草案 0 プロトコルを目指します。その中で、グループ化とループのインテリジェント認識の精度が向上し、視覚草案プロトコルにおける手動介入のコストが削減されます。

部品識別の精度が向上しました。現状では精度は72%に留まり、業務アプリケーションでの可用性は低いです。

ページ セグメント化機能の精度が向上したことにより、ページ レベルおよびアイテム レベルの復元機能の可用性が向上しました。

ミニプログラム、ミッドエンドおよびバックエンド システムなどの領域でのページ レベルの復元機能が改善され、複雑なフォーム、表、グラフの全体的な復元機能も向上しました。

静的イメージ生成コードリンクの可用性が向上し、実稼働環境で実際に使用できるようになりました。

アルゴリズム エンジニアリング製品が改善され、サンプル生成チャネルがより多様化し、サンプル セットがより豊富になりました。

D2C 機能はオープンソースです。

今後、私たちはフロントエンドインテリジェントD2Cプロジェクトを通じて、フロントエンドインテリジェントテクノロジーソリューションをより利用しやすくし、より競争力のあるサンプルとモデルを蓄積し、より正確で可用性の高いインテリジェントコード生成サービスを提供し、フロントエンドR＆Dの効率を効果的に向上させ、単純な反復作業を減らし、残業を減らして、より挑戦的な仕事内容に一緒に集中できるようにしたいと考えています。