Page generation method and system based on large language model, device, equipment, storage medium and program product
Patent Information
- Application Number
- CN202610904848.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-22
- Publication Date
- 2026-09-25
AI Technical Summary
[0012]应当理解,本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征,也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
Smart Images

Figure CN122816629A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of artificial intelligence, specifically to a page generation method and system, apparatus, electronic device, computer-readable storage medium, and computer program product based on a large language model. Background Technology
[0002] With the rapid development of digital marketing, businesses need to quickly build promotional landing pages using simple natural language descriptions to reduce the costs of traditional manual drag-and-drop or code-writing website building. Therefore, leveraging the natural language understanding and generation capabilities of large language models to achieve intelligent and rapid website building from natural language requirements to target pages has become an important development trend.
[0003] The methods described in this section are not necessarily methods that had been previously conceived or adopted. Unless otherwise specified, no method described in this section should be assumed to be prior art simply because it is included in this section. Similarly, unless otherwise specified, the issues mentioned in this section should not be considered to be accepted in any prior art. Summary of the Invention
[0004] This disclosure provides a method, system, apparatus, electronic device, computer-readable storage medium, and computer program product for generating pages based on a large language model.
[0005] According to one aspect of this disclosure, a page generation method based on a large language model is provided, comprising: obtaining a page generation request in natural language form input by a user; generating structured simplified page configuration data through a large language model based on the page generation request, a large model-driven page protocol, and a preset page component directory, wherein the simplified page configuration data includes one or more simplified page components, wherein the large model-driven page protocol constrains the data format of the simplified page configuration data, and the preset page component directory constrains the component type, component fields, and value range of field attributes of one or more simplified page components; completing the component style, component coordinates, and component interaction logic of one or more simplified page components through a deterministic transformation procedure based on the simplified page configuration data and preset component templates to generate complete page configuration data conforming to the rendering standards of a page renderer; and rendering the page based on the complete page configuration data through a page renderer.
[0006] According to another aspect of this disclosure, a page generation system based on a large language model is provided, comprising: a user layer configured to acquire a page generation request in natural language form input by a user; a generation layer configured to generate structured simplified page configuration data based on the page generation request, a large model-driven page protocol, and a preset page component directory, using a large language model, wherein the simplified page configuration data includes one or more simplified page components, wherein the large model-driven page protocol constrains the data format of the simplified page configuration data, and the preset page component directory constrains the component type, component fields, and value range of field attributes of one or more simplified page components; a conversion layer configured to complete the component style, component coordinates, and component interaction logic of one or more simplified page components through a deterministic conversion procedure based on the simplified page configuration data and preset component templates, so as to generate complete page configuration data conforming to the rendering standard of a page renderer; and an output layer configured to render a page based on the complete page configuration data using a page renderer.
[0007] According to another aspect of this disclosure, a page generation apparatus based on a large language model is provided, comprising: a receiving module configured to receive a page generation request in natural language form input by a user; a generation module configured to generate structured simplified page configuration data based on the page generation request, a large model-driven page protocol, and a preset page component directory, using a large language model, wherein the simplified page configuration data includes one or more simplified page components, wherein the large model-driven page protocol constrains the data format of the simplified page configuration data, and the preset page component directory constrains the component type, component fields, and value range of field attribute values of the one or more simplified page components; a conversion module configured to complete the component style, component coordinates, and component interaction logic of the one or more simplified page components through a deterministic conversion procedure based on the simplified page configuration data and a preset component template, so as to generate complete page configuration data conforming to the rendering standard of a page renderer; and an output module configured to render a page based on the complete page configuration data using a page renderer.
[0008] According to another aspect of this disclosure, a method is provided to be executed at a user device. The method includes: providing a first graphical user interface to obtain a page generation request input by a user; generating structured simplified page configuration data through a large language model based on the page generation request, a large model-driven page protocol, and a preset page component directory, the simplified page configuration data including one or more simplified page components, wherein the large model-driven page protocol constrains the data format of the simplified page configuration data, and the preset page component directory constrains the component type, component fields, and value range of field attribute values of the one or more simplified page components; completing the component style, component coordinates, and component interaction logic of the one or more simplified page components through a deterministic transformation procedure based on the simplified page configuration data and preset component templates to generate complete page configuration data conforming to the rendering standard of a page renderer; displaying a page rendered by a page renderer in a page preview window of the first graphical user interface based on the complete page configuration data; providing a second graphical user interface in response to obtaining an edit request input by a user, wherein the second graphical user interface includes a visual component editor to enable the user to edit components included in the complete page configuration data; and rendering the modifications in the page corresponding to the component editing input in real time in the visual component editor in response to the user's component editing input.
[0009] According to another aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program that, when executed by the at least one processor, implements the method described above.
[0010] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing a computer program, wherein the computer program implements the method described above when executed by a processor.
[0011] According to another aspect of this disclosure, a computer program product is provided, comprising a computer program, wherein the computer program, when executed by a processor, implements the method described above.
[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description
[0013] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of the claims. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.
[0014] Figure 1 An exemplary flowchart of a page generation method based on a large language model according to an embodiment of the present disclosure is shown.
[0015] Figure 2 An exemplary flowchart is shown of a method for determining the types of available components through intent analysis and generation strategy according to embodiments of the present disclosure.
[0016] Figure 3 An exemplary flowchart is shown of a method for completing page configuration data using a deterministic transformation procedure according to an embodiment of the present disclosure.
[0017] Figure 4 An exemplary flowchart of a method for generating an ordered list of subcomponents according to embodiments of the present disclosure is shown.
[0018] Figure 5 An exemplary flowchart of a method for determining component coordinates according to embodiments of the present disclosure is shown.
[0019] Figure 6 An exemplary block diagram of a page generation system based on a large language model according to an embodiment of the present disclosure is shown.
[0020] Figure 7 An exemplary block diagram of a page generation apparatus based on a large language model according to an embodiment of the present disclosure is shown.
[0021] Figure 8A An exemplary user interface graphic is shown, generated based on a large language model of a page according to an embodiment of this disclosure.
[0022] Figure 8B An exemplary user interface graphic is shown, generated based on a large language model of a page according to an embodiment of this disclosure.
[0023] Figure 9 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of the present disclosure is shown. Detailed Implementation
[0024] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.
[0025] In this disclosure, unless otherwise stated, the use of terms such as "first," "second," etc., to describe various elements is not intended to limit the positional, temporal, or importance relationships of these elements; such terms are merely used to distinguish one element from another. In some examples, the first element and the second element may refer to the same instance of that element, while in other cases, based on the context, they may refer to different instances.
[0026] The terminology used in the description of the various examples in this disclosure is for the purpose of describing particular examples only and is not intended to be limiting. Unless the context explicitly indicates otherwise, an element may be one or more unless the number of elements is specifically limited. Furthermore, the term "and / or" as used in this disclosure covers any one of the listed items and all possible combinations thereof.
[0027] It should be noted that, in any part of this disclosure involving the collection, storage, use, transmission, and processing of data, each stage strictly adheres to the laws, regulations, industry standards, and regulatory requirements of the data source, usage location, and relevant countries and regions to ensure the legality and compliance of data activities. In the collection stage, the purpose, method, and scope of collection are clearly communicated to the data subject in a prominent manner. Collection is conducted only after obtaining the data subject's legal authorization, ensuring that the collection process follows the "minimum necessary" principle and does not exceed the scope of data collection. In the storage stage, storage periods are limited, and data is promptly deleted or anonymized / encrypted after the storage purpose is achieved. In the usage stage, a strict data security protection mechanism is implemented, using field-level desensitization technology and processing the original data according to preset desensitization rules. For different types of data, multiple desensitization strategies, such as data generalization, data anonymization, and data encryption, are employed to effectively mitigate the risk of sensitive information leakage and ensure that all data used is securely processed and desensitized, comprehensively protecting the rights and interests of data subjects and data security. In the transmission and processing stages, the confidentiality and security of data are ensured during transmission and processing.
[0028] In technologies that automatically generate interactive user pages using large language models (large models), the common practice is to have the large model directly output the complete business data required for the underlying rendering of the website building platform, such as complex proprietary JSON formats. However, the complete page data structure of a website building platform is extremely complex, typically containing more than 30 business fields per component, with multiple levels of nesting and complex inter-component references. Directly requiring the large model to output this type of data has serious limitations. On the one hand, the large model is prone to creating illusions, often fabricating component types not supported by the website building platform or invalid attribute values; on the other hand, the output format of the large model lacks idempotency and stability, often resulting in missing required fields and disordered nesting levels. These defects often lead to the final generated page data failing to load and render correctly in a visual page editor, significantly reducing the validity and usability of large model-based website building.
[0029] To address the aforementioned technical issues, this disclosure provides a page generation method based on a large language model. It constrains the generated data format of the large language model through a standardized large model-driven page protocol, and strictly restricts the component types, component fields, and field attribute value ranges of the page components generated by the large language model through a closed, pre-defined page component directory. The large language model only generates simplified page configuration data including the core fields and field attribute values required by the page components. This disclosure ensures that the final generated complete page configuration data can be directly loaded and rendered by the website building platform's page renderer by using deterministic program code to complete the simplified page configuration data generated by the large language model.
[0030] Through the aforementioned technical means, this disclosure effectively suppresses the illusion of large models and significantly improves the legality of generated page configuration data. Instead of allowing large models to directly generate complex underlying business configuration data, this disclosure uses a preset page component directory as a whitelist constraint to limit the output space of large models. Large models only need to output simplified page configuration data within a limited set of components and attribute values, effectively reducing the output complexity of large models and further preventing the generation of components and invalid attribute values out of thin air.
[0031] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.
[0032] Figure 1 An exemplary flowchart of a page generation method 100 based on a large language model according to an embodiment of the present disclosure is shown.
[0033] In step S102, the page generation request in natural language form input by the user is obtained.
[0034] In step S104, based on the page generation request, the large model-driven page protocol, and the preset page component directory, structured simplified page configuration data is generated through the large language model. The simplified page configuration data includes one or more simplified page components.
[0035] In step S106, based on simplified page configuration data and preset component templates, a deterministic transformation procedure is used to complete the component styles, component coordinates, and component interaction logic of one or more simplified page components to generate complete page configuration data that conforms to the rendering standards of the page renderer.
[0036] In step S108, the page is rendered based on the complete page configuration data using the page renderer.
[0037] This paper utilizes a large model to drive page protocol standardization, which standardizes the format and content of page configuration data generated by a large language model based on natural language page requirements. During the generation process, a preset page component directory strictly constrains the component types, fields, and attribute value ranges of page components in the configuration data. This effectively limits the output space of the large language model to a legal whitelist, significantly reducing output complexity and suppressing the illusion of the large model creating illegal components or attribute values out of thin air. Furthermore, this disclosure generates simplified page configuration data based on the large model. Then, using preset component templates, a deterministic transformation procedure completes the component styles, coordinates, and interaction logic of each component to generate complete page configuration data that conforms to the rendering standards of the page renderer. This decouples the unstable semantic generation of the large language model from the underlying complex business code layout logic, enabling the page renderer to render pages based on deterministic complete page configuration data. This ensures that each generated complete page configuration data possesses good structural stability and format idempotency, thus solving the problem that traditional large models directly generating complex nested data easily leads to loading errors. This allows users to generate pages that meet their needs, are highly stable, and can be freely edited with minimal learning cost.
[0038] Specific examples of this disclosure will be described in detail below.
[0039] In step S102, the page generation request in natural language form input by the user is obtained.
[0040] In some embodiments, user input can be acquired through a user interface on an electronic device (such as a personal computer, tablet, or other terminal device). For example, the system can provide a first graphical user interface on the terminal device, which can be an interactive window of an AI-powered website building page or application. This first graphical user interface may include a natural language input box, where the user can input their page generation requirements using text input methods such as keyboard typing, copying and pasting, and submit the request by clicking a control such as "Generate Page".
[0041] In other embodiments, a voice command from the user can be received via a voice acquisition device and converted into natural language text using speech recognition technology, thereby obtaining a page generation request in the natural language form. This disclosure does not limit the specific interaction method for obtaining user input.
[0042] User-inputted page generation requests in natural language are typically unlimited and open-ended. Therefore, in some embodiments, a validity check can be performed on the page generation requests to determine whether they contain valid request information.
[0043] Specifically, when the system receives user input, it first determines whether the input is empty or contains only blank characters. If the input is empty or contains only blank characters, the system determines that the input does not contain valid requirement information and directly intercepts the request, avoiding a call request to the large language model, thus preventing wasted computing power and invalid results. If the input contains valid characters, it is submitted to the backend along with the generated requirements for further processing.
[0044] In some examples, for requests that pass the validity check, the system can also mark them as fast mode, indicating that the page skeleton will be returned first in subsequent generation. For example, placeholders will be used for image positions first, and they will be filled asynchronously later to improve the user experience.
[0045] User-inputted page generation requests typically contain somewhat vague descriptions of routine business operations. These requests may include intent information such as the industry the user expects the page to belong to, the page's theme, conversion goals, or specific content requested.
[0046] In some examples, a page generation request can be a simple description with a single objective and clear requirements, such as "create an enrollment page for education and training" or "create a brand showcase page".
[0047] In other examples, the page generation request can also be a complex description containing a clear conversion intent, multiple data combination requirements, or specific material requirements, such as "Make an enrollment page for education and training, which requires a form to collect student information" or "Make an education page that includes student review data, real course images, and a countdown timer for a limited-time offer."
[0048] Because users' page generation requests vary in depth, using the same generation path for both simple and complex requests will make it difficult to balance generation speed and accuracy. For example, using a complex path for all requests will slow down the generation of simple pages, while using a simple path for all requests will fail to meet the specific material or data requirements of complex pages.
[0049] Therefore, in some embodiments, in response to the page generation request passing the validity check, the complexity of the page generation request can be determined by the large language model; and based on the complexity determination result, it can be determined whether the prompt word template used by the large language model to generate simplified page configuration data includes external tool interfaces for obtaining page component materials and cases that conform to the page generation request.
[0050] Specifically, complexity assessment can be performed by a large language model, but to reduce the unpredictability of the model's output, the range of possible outputs in this step can be strictly limited. The system can use fixed complexity analysis prompts, such as explicitly stating the criteria and examples for "simple" or "complex," and minimize the randomness parameters of the large language model to ensure consistent and stable assessment results for the same input. Furthermore, the system can use structured output constraints to force the large language model to return results only for predefined fields.
[0051] In some examples, the output of the large language model can be limited to only three items: complexity level, reasoning, and a list of required tools, and cannot return freely chosen explanatory text. Furthermore, the list of required tools output by the large language model can be restricted to selection from a pre-defined set of external tools (e.g., case retrieval, image retrieval, copywriting generation, data querying, design validation, etc.).
[0052] Based on the complexity level in the structured results returned by the large language model, the system will perform different generation link forks.
[0053] In some examples, two different generation paths can be included: simple paths and complex paths.
[0054] Specifically, if the complexity assessment indicates a simple level, meaning the page generation request has a clear requirement, a single objective, and does not require multiple data acquisition steps, the system will route the request to a simple generation path. Under this path, the prompt word template used for large model generation does not include external tool call interfaces, and the system directly enters the rapid component generation chain, thus ensuring extremely fast response speed and highly deterministic generation results.
[0055] If the complexity assessment indicates a high level of complexity—meaning the page generation request involves multiple data combinations, specifies particular materials, or requires multiple steps of reasoning—the system will route the request to the tool-assisted generation path. Under this path, the prompt word templates used for large model generation will include external tool interfaces for a list of tools that meet the output requirements of the large language model. Within a controlled scope, the system will invoke appropriate retrieval and generation tools to obtain page component materials and relevant page examples, thereby assisting the large model in generating page content with a more complex structure and specific requirements.
[0056] By assessing complexity, the system can accurately identify the depth of user needs and perform process routing. This allows simple needs to skip unnecessary external tool calls and generate page structures directly with extremely high speed and certainty, reducing user waiting time and improving the user experience. Meanwhile, complex needs can be addressed by introducing appropriate external tool interfaces to assist in generation, thus achieving a balance between page generation speed and the accuracy and richness of the generated content.
[0057] In step S104, based on the page generation request, the large model-driven page protocol, and the preset page component directory, structured simplified page configuration data is generated through the large language model. The simplified page configuration data includes one or more simplified page components.
[0058] In some embodiments, the system can assemble a prompt word by combining the user-input page generation request with the format requirements of a large model-driven page protocol (such as a lightweight standardized intermediate protocol) and a preset page component directory (i.e., a closed list of components that are explicitly declared as usable by the large model). After receiving the prompt word, the large language model can output structured, simplified page configuration data that is formatted, flattened, and contains only a small amount of key information.
[0059] In order to further converge open user page generation requirements into a defined page structure, in some embodiments, intent analysis can be performed on the page generation request and a generation strategy can be determined before formally generating simplified page configuration data.
[0060] Figure 2 An exemplary flowchart of a method 200 for determining the types of available components through intent analysis and generation strategy according to embodiments of the present disclosure is shown.
[0061] In step S202, the intent of the page generation request can be extracted using a large language model.
[0062] In step S204, the large language model can be constrained by prompt words to output structured page intent analysis information based on intent fields and intent options within a preset range.
[0063] In step S206, a page generation strategy can be determined based on preset mapping rules and page intent analysis information. The page generation strategy includes page layout constraints, page component function constraints, and page component content scope constraints.
[0064] In step S208, based on the page generation strategy, a list of available component types for generating simplified page configuration data for large models can be determined from the component type constraints of the preset page component directory.
[0065] In some embodiments, the system extracts the intent of the page generation request and constrains the large language model to output structured page intent analysis information based on a preset range of intent fields and intent options through prompt words. In the intent analysis portion of steps S202 and S204, since the question of what kind of page to generate is still open-ended, to further narrow it down, the system can drive the large language model to complete intent extraction through prompt words and force the large language model to return only a few predefined intent information items through structured output constraints. In this step, the large language model no longer outputs open text, but rather a small number of options with a closed selection range.
[0066] In some examples, the predefined intent fields may include: the page's industry, conversion mode, whether a form is required, whether a download link is required, and core keywords. Each intent field corresponds to a limited number of intent options. For example, the options for "industry" can be limited to education and training, automotive, media and content, retail, lifestyle services, catering services, utility software, or others; the options for "conversion mode" can be limited to form data collection, app download, or a combination of interactive methods; "whether a form is required" and "whether a download link is required" are either yes or no; and "core keywords" are limited to extracting 2-5 words.
[0067] For example, if a user enters "I need to create an education and training registration page and collect student information via a form," the intent analysis information extracted by the large model will be strictly limited to: Industry = Education and Training, Conversion Mode = Form Data Collection, Form Required = Yes, Download Link Required = No, Core Keywords = [Registration, Student, Training]. This controlled intent extraction precisely converges the user's open natural language description into a limited set of structured options.
[0068] In some embodiments, the system can select a page generation strategy based on preset mapping rules and the page intent analysis information generated in steps S202 and S204. Once the intent information is determined, the final selected strategy is not freely determined by the large language model, but rather routed according to fixed priority mapping rules. This shifts the decision-making power of the strategy from the large language model back to the system's fixed rules, ensuring that the same intent always receives the same generation strategy, thereby eliminating the randomness inherent in the large model itself.
[0069] In some embodiments, strategies may include form-based data entry strategies, application download strategies, and composite interaction strategies.
[0070] Form-based contact management strategies can be used for scenarios such as registration, consultation, and appointment. In some examples, the page layout constraints and component functionality constraints of form-based contact management strategies may include: requiring that the number of form items not exceed a preset number (e.g., no more than 3 items), requiring that the first screen must include the core benefits and a call-to-action button, and configuring a trust endorsement component.
[0071] App download strategies can be used to promote applications or mini-programs. In some examples, the page layout constraints and component functionality constraints of app download strategies may include: requiring the download button or QR code to be in a prominent position on the first screen, and configuring a download entry component fixed at the bottom of the page.
[0072] Composite interaction strategies can be used in high-value industries such as automotive. In some examples, the page layout constraints and component functionality constraints of composite interaction strategies are more comprehensive, requiring complex page structures that include large image displays, video components, product configuration options, and form reservations.
[0073] In some examples, the preset priority mapping rules based on the above three strategies can be as follows: Priority 1: Determine whether the intent analysis information explicitly states "download entry point required". If so, adopt the "application download strategy".
[0074] Priority 2: If no download entry is required, determine whether there is already a "clear conversion mode". If so, directly adopt the strategy corresponding to the conversion mode (e.g., if it is clearly "form data collection" in the previous example, then adopt the "form data collection strategy").
[0075] Priority 3: If none of these conditions are met, then allocation will be made based on industry type characteristics. For example, education and training, retail, and lifestyle services will be mapped to the "form-based lead generation strategy"; the automotive industry will be mapped to the "composite interaction strategy"; and software tools, catering, and media will be mapped to the "application download strategy".
[0076] Based on the system's preset page generation strategy, each strategy can correspond to a set of structural guidelines and a set of material retrieval ranges to jointly constitute page layout constraints, page component functional constraints, and page component content range constraints.
[0077] In some embodiments, the required component combinations for the strategy can be filtered from a preset page component catalog to determine a list of available component types for subsequently constraining the large language model to generate simplified page configuration data. In some examples, the list of available component types includes constraints on the available component types and the corresponding component fields and field attribute values.
[0078] By selecting a strategy for routing using fixed mapping rules, open user inputs can be categorized into limited page target types. Then, the subsequent page generation process is constrained by the corresponding strategy combination rules. This restricts the input content of the large language model, preventing the large model from diverging in the infinite semantic space and significantly improving the reliability of page generation.
[0079] In some embodiments, the system can assemble prompt words from page generation requests or, as described above, the structural guidance and material retrieval scope corresponding to the page generation strategy determined by intent analysis, combined with the large model-driven page protocol format rules and preset page component directories, in order to constrain the output of structured and simplified page configuration data by the large language model.
[0080] Specifically, large model-driven page protocols can be, for example, the A2UI (Agent to UI) protocol proposed by Google, or other derivative and similar protocols. Large model-driven page protocols allow agents or large language models to securely send standardized streaming protocols containing rich user interfaces across trust boundaries. They provide a declarative, standard communication language between AI and front-end applications.
[0081] In the embodiments disclosed herein, by applying a large model-driven page protocol, the system strictly constrains the structured, simplified page configuration data output by the large language model to be in a declarative JSON format. This format requires the large model to output the page structure as a flat list of components, rather than directly generating complex front-end executable code such as front-end engines like React and Vue, thereby ensuring cross-platform compatibility while avoiding security risks such as code injection.
[0082] It should be understood that the page data structure upon which the final page renderer relies is typically a complex Domain Specific Language (DSL). In the page generation scenario disclosed herein, DSL refers to the JSON format used by the website building platform to describe its pages. The page renderer (such as a visual component editor or browser rendering engine) needs a complete business DSL containing a wealth of internal information, including unique component identifiers, status flags, multi-layered event structures, and precise size and layout coordinates, to correctly load, display, and support secondary editing by the user. Therefore, typically, each component that the page renderer needs to render may contain more than 30 fields.
[0083] In this context, allowing a large language model to directly generate such a low-level DSL would present serious illusion and stability issues. On one hand, when dealing with extremely long and deeply nested data structures, large language models are prone to structural errors and missing required fields. On the other hand, due to the unrestricted nature of large language models, they can easily fabricate component types or invalid attribute values that don't exist in the website building platform's DSL specification. Furthermore, under the same input, large models cannot guarantee consistency in the output content generated each time. If such non-idempotent output is directly parsed by the page renderer, it will cause the page to crash or fail to render.
[0084] Therefore, simply relying on the format specification of the large model to drive the page protocol cannot ensure that the output of the large model meets expectations. To solve this problem, this disclosure introduces comprehensive mandatory constraints during the process of sending the request to the large model (input side), during the generation of the large model (output), and after the large model is output (output side). These constraints include introducing a preset page component directory to limit the output range of the large model.
[0085] The default page component directory is a clearly defined closed list of available components. By injecting this directory into the prompt words, the system strictly limits the generation space of a large language model from the input side.
[0086] In some embodiments, the preset page component directory constraints may include at least the following eight basic component types: image component, text component, button component, form component, download component, video component, vertical container component, and horizontal container component. In some examples, the large model is required to allow the selection and combination of components only within this directory.
[0087] In some examples, the default page component catalog matches the list of available component types. In other examples, the list of available component types is a subset of the default page component catalog, depending on the page generation strategy.
[0088] Furthermore, this preset page component directory not only restricts component types but also limits the allowed component fields and the range of field attribute values for each component. For example, for button components, the directory restricts the large model to providing only a limited number of core fields, such as button text, size, positioning, and click action. Moreover, field attribute values are strictly limited; for example, size is only allowed to be "large" or "small," and positioning is only allowed to be "normal," "fixed to top," or "fixed to bottom." If the large model selects a certain interaction behavior (e.g., click action type "open form"), the system also requires the large model to have the corresponding information (e.g., form number, form title, etc.) provided through conditional constraints.
[0089] Based on the above constraints, the simplified page configuration data generated by the large language model is equivalent to a controlled page outline. In this outline, all simplified page components exist in a flat list format. Container components (such as vertical or horizontal container components) express the layout hierarchy and containment relationship only through reference fields containing unique identifiers of child components (such as the `children` array), without deep physical nesting within the JSON. For each simplified page component, it only contains, for example, 3-6 core semantic and intent information items (such as "This is a button, the text is 'Free Trial', the size is 'Large', fixed at the bottom"), while completely stripping away all complex business logic regarding precise rendering and alignment.
[0090] As an exemplary implementation, the specific structure and content of the prompt words used to constrain the large language model can be as follows:
[0091] It should be understood that the above-described prompt word constraint structure is only a partial basic example of the input to the large language model. In actual implementation, in order to achieve more accurate page generation that better suits specific business scenarios, the prompt words received by the large language model are not limited to the basic format and rule constraints in the above examples, but may also include other rich contextual information determined by the system in the preprocessing steps. This disclosure does not limit this.
[0092] Although strict constraints are imposed on the input side through a large model-driven page protocol and a pre-defined page component directory, the inherent probabilistic generation characteristics of large language models mean that prompt words can guide the model's generation tendencies, making it impossible to absolutely guarantee the complete legality of the output content. The simplified page configuration data generated by the large model may still contain issues such as spelling errors, missing required fields, or attribute values exceeding the allowed range. Therefore, legality validation of the large model's output data is necessary to ensure its validity.
[0093] In some embodiments, the simplified page configuration data can be validated based on the data format defined by the available component type constraints, component field constraints, field attribute value constraints, condition association constraints, and large model-driven page protocol constraints in the preset page component directory definition.
[0094] In some examples, data format validation tools (such as Zod Schema, a TypeScript-preferred schema declaration and validation library) can be used to perform strict structure validation on the JSON data output by large models.
[0095] It should be understood that this disclosure is not limited to the use of Zod Schema. In some examples, other data validation tools or libraries such as JSON Schema, Yup, and Joi may be used, or custom validation scripts may be used to achieve the same data verification and interception logic.
[0096] In some embodiments, the legality verification specifically includes: verifying the data format and structural integrity of the simplified page configuration data; for each simplified page component in the simplified page configuration data, verifying whether the component type, component fields, and field attribute values of the simplified page component exceed the range and number limits of the available component type constraints, component field constraints, and field attribute value constraints; and verifying whether the component fields and field attribute values related to the component interaction logic of the simplified page component are complete based on conditional association constraints.
[0097] The following detailed explanation of the above-mentioned legality verification steps, in conjunction with embodiments of this disclosure, is provided.
[0098] The system first checks whether the simplified page configuration data output by the large language model meets the overall structural requirements based on the specification of the large model-driven page protocol. For example, it checks whether the JSON data contains the necessary top-level fields (such as the version number in the protocol format, the identifier of the updated page, etc.) and whether the component list (such as the `components` field) is a non-empty array. Simultaneously, it can also check whether page-level information (such as page name, browser title, background color, etc.) conforms to the specification. In some examples, the validity check also includes checking the number of component fields.
[0099] Then, the system performs component-by-component type, field, and value range validation. For each simplified page component in the component list, the system matches the corresponding validation rules according to its declared component type and performs item-by-item verification.
[0100] For component type validation, the system blocks component types not listed in the preset page component directory or the list of available component types. For example, the component type must be one of the eight allowed types specified in the preset page component directory. If the large language model creates a type such as "Carousel" or "Modal" that is not in the directory, the component validation will fail and it will be blocked.
[0101] For valid component types, the system checks whether any required component fields are missing or exceed the constraints. For example, if the component type is an image component, it must include three fields: image URL, width, and height. If the component type is a button component, it must include fields such as button text and size. In some examples, the system may also check whether the number of component fields exceeds the constraints.
[0102] The system then checks whether the attribute values of each field exceed the range and number limits. For example, for the size field of the button component, only values "large" or "small" are allowed. If the large model outputs "medium" or "xl", the validation fails. For the component's positioning method (position), only values "normal", "fixed-top", or "fixed-bottom" are allowed. Other positioning methods that the page renderer cannot recognize are not allowed.
[0103] For conditional constraint validation, this check primarily examines the completeness of component interaction logic. In other words, after a component selects a certain behavior or condition, the corresponding information must be complete. For components with clickable interactions, such as buttons, the system requires that after the large language model selects a behavior type, it must provide the corresponding complete logical fields. For example, when a button's click behavior (action.type) is set to "form" (open form), either the form ID (formId) or the form title (formTitle) field must be provided; when set to "link" (link redirection), the redirect URL (url) field must be provided; and when set to "weixin" (redirect to WeChat), the mini-program ID and page path must be provided. This avoids incomplete behavior configurations, such as selecting "open form" but lacking specific form information, or selecting an illegal behavior type outside the list. Validation will fail if the necessary fields or field attribute values for the component's interaction logic are missing.
[0104] In some embodiments, in response to a failure of the validity check, the verification error information is used as context information to re-input the large language model to trigger the large language model to regenerate the simplified page configuration data, until the simplified page configuration data passes the validity check or the number of times regeneration is triggered exceeds a preset retry threshold.
[0105] Specifically, if any item fails the rule check during the aforementioned validity verification process, the system can intercept the generated data to prevent erroneous data from being passed to subsequent completion and rendering steps. Simultaneously, the system can record specific and precise verification error information, clearly indicating the specific invalid or missing components and fields. For example, the error message could specify that "the button component with ID 'btn-1' provided an invalid size attribute value 'medium'." The system feeds these specific verification error messages as contextual prompts to the large language model, guiding it to recognize any illusions or formatting deviations in its previous output and regenerate valid, simplified page configuration data based on the error correction requirements.
[0106] To prevent large language models from getting stuck in an infinite retry loop due to repeated inability to understand constraints, which would lead to wasted computing power and user timeouts, the system introduces a preset retry threshold, for example, the threshold can be set to 3 times.
[0107] If the large language model successfully generates simplified page configuration data that passes the validity check within the threshold number of attempts, the page generation process can proceed normally to the deterministic completion step.
[0108] If the large language model fails to generate multiple times consecutively, and the number of times it triggers regeneration exceeds the preset retry threshold, it may mean that the large language model cannot reasonably fit the current user needs into the preset page component directory constraints. For example, the user's original request may have logical contradictions or be beyond the scope of support.
[0109] In some embodiments, the system may interrupt the current large model generation link, actively cut off the session, and return the corresponding prompt information on the user interface to guide the user to modify and re-enter their natural language page generation request.
[0110] Through the above-mentioned legality verification, the system can effectively intercept illegal components, illegal information items, illegal values, and incomplete conditional information, thereby ensuring that the simplified page configuration data that passes all verification rules enters the subsequent process and preventing the subsequent process from failing due to illegal input.
[0111] Furthermore, by combining precise error feedback with a limited number of retries, the system can ensure that the large language model outputs valid structured data while maintaining good response efficiency, resource consumption, and robustness.
[0112] In step S106, based on simplified page configuration data and preset component templates, a deterministic transformation procedure is used to complete the component styles, component coordinates, and component interaction logic of one or more simplified page components to generate complete page configuration data that conforms to the rendering standards of the page renderer.
[0113] As mentioned earlier, website building platforms typically render front-end pages based on complex declarative descriptions of Domain-Specific Languages (DSLs). Although this disclosure has structured and converged the user's natural language requirements on the input side, strictly constrained the large language model through a preset page component directory during the generation process, and performed valid format checks on the data content after output, it is still difficult to achieve the desired effect if the large language model is directly required to generate complete DSL data containing a large number of business fields (e.g., more than 30 fields per component), multiple levels of nesting, and mutual references at once. When processing such data containing a large amount of underlying business logic, the large model is prone to problems such as missing required fields and disordered nesting levels. Most importantly, it cannot ensure the idempotency of the output results, that is, for the same requirement, the format details generated by the large model may be different each time.
[0114] Therefore, this disclosure provides a method where a large language model outputs only a simplified format containing the core semantic fields of the page configuration (e.g., A2UI large model-driven page protocol JSON data with only 3-6 fields per component), and then a deterministic transformation program (Transformer) completes the simplified format. "Deterministic" as used herein means that the same input will always produce the exact same output result; there is no randomness in the entire transformation process, and no probabilistic inference or predictive generation from the large language model is introduced.
[0115] In some embodiments, the deterministic conversion procedure can be implemented as a set of pre-written pure function code, a conversion script based on a mapping dictionary, or a component instantiation object generator built using the Factory Pattern. These implementations, according to fixed code rules, automatically map, assemble, and extend abstract, simplified fields into multi-layered, nested private data formats that the underlying website building platform can directly recognize. Provided that the output is deterministic, this disclosure does not limit the specific implementation of the deterministic conversion procedure.
[0116] Figure 3 An exemplary flowchart of a method 300 for completing page configuration data by a deterministic transformation procedure according to an embodiment of the present disclosure is shown.
[0117] In step S302, for the complete page component corresponding to the simplified page component, a unique identifier and component name conforming to the page renderer rendering standard are generated.
[0118] In step S304, based on the component type, component fields, and field attribute values of the simplified page component, the component style identifier is determined by the style calculator of the deterministic transformation program. The component style identifier is used by the page renderer to render the style of the complete page component.
[0119] In step S306, based on the child component reference field when the component type of the simplified page component is a layout component, an ordered child component list is generated, and the component coordinates of the complete page component are determined by combining the ordered child component list and the height field in the component field.
[0120] In step S308, based on the component type and according to the preset component template, the component fields and field attribute values required for the component interaction logic are filled into the complete page component.
[0121] By utilizing a deterministic transformation procedure, this disclosure implements a decoupled architecture where the large model handles semantic intent expression, while the deterministic program code handles business implementation. This architecture ensures high consistency and validity of the format, eliminates rendering crashes caused by missing underlying business fields, and allows the output to be directly loaded and edited by the page editor of the website building platform, including the page renderer. Simultaneously, this architecture significantly reduces the burden on the large model, reducing field complexity by approximately 80% or more, thereby substantially reducing the occupation of the large model's context window and the probability of errors.
[0122] In some embodiments, simplified page configuration data generated by a large language model can be translated into a data format recognizable by a deterministic translation program using a format translation function, according to the standard of the large model-driven page protocol.
[0123] Therefore, by introducing an adapter, including a format translation function, between the large model output and the deterministic converter, a highly reusable multi-protocol adaptation architecture is achieved. The deterministic converter can focus solely on component types and component self-fields and attribute values, freeing it from dependence on specific AI vendor protocols. When it is necessary to integrate new generation protocols from other AI vendors, only a low-cost format translation function needs to be written to interface with the deterministic converter, allowing all complex business conversion rules to be reused, thus achieving flexible plug-and-play system architecture.
[0124] The conversion steps of the above-described deterministic conversion procedure will be explained in detail below with reference to embodiments of this disclosure.
[0125] During the deterministic transformation process, the deterministic transformation program completes and assembles data based on simplified page configuration data and preset component templates.
[0126] Pre-defined component templates refer to the standard data structure skeletons predefined for each type of business component (e.g., images, buttons, forms, etc.). This skeleton contains all the multi-level nested structures required by the underlying website building platform DSL, as well as default state fields that are necessary for the business but do not need to be concerned when generating large models (e.g., component activation state active: false, error state hasError: false, rotation angle rotate: 0, etc.).
[0127] In some embodiments, preset component templates can be stored in the system's local configuration file, code constant library, or a unified component resource database in the backend. During runtime, the deterministic transformation program can, based on the component type of the simplified page component being processed (e.g., a "Button" component), invoke the storage structure of preset component templates, such as the configuration center or memory dictionary, to extract the corresponding preset component template as the structural and content basis for data completion.
[0128] In step S302, for the complete page component corresponding to the simplified page component, a unique identifier and component name conforming to the page renderer rendering standard are generated.
[0129] When generating simplified page configuration data, the large language model can be prompted to assign a simple identifier to each simplified page component (e.g., "id": "btn-1", "id": "img-1"). Its main function is to represent layout hierarchy by referencing each other through numbers in the flattened list output by the large model (e.g., children: ["img-1", "btn-1"]). However, these simple identifiers generated by the large model are usually local auto-incrementing strings and do not conform to the standard of the page renderer DSL. To ensure the uniqueness of global components, support subsequent persistent database storage, and precise positioning in the editor, the page renderer of the website building platform typically requires globally unique identifiers (e.g., standard UUID format, such as "22127c84-dc5d-4b43-bfa9-091d7f8dac30").
[0130] Therefore, the deterministic conversion process can generate unique identifiers (UUIDs) for complete page components based on simplified IDs generated by the large language model, or discard simplified IDs altogether, using the system's built-in ID generation algorithm. It also updates all relevant parent-child reference mappings synchronously during the conversion process. Furthermore, the deterministic conversion process sets standard internal component names for components based on their type and variant forms (e.g., setting the name to "image-normal" or "button-large") to meet the readability and retrieval specifications of the page editor, including the page renderer.
[0131] In step S304, based on the component type, component fields, and field attribute values of the simplified page component, the component style identifier is determined by the style calculator of the deterministic transformation program. The component style identifier is used by the page renderer to render the style of the complete page component.
[0132] When outputting simplified page configuration data, the large language model generates only a few semantic style fields (such as button size: "large" or "small", and positioning style: "normal" or "fixed-bottom"). The large model does not need, and cannot accurately know, the specific internal identifiers used by the website building platform to control rendering styles, i.e., component style identifiers. In some examples, component style identifiers are represented by `styleId`. A deterministic transformation program can include a style calculator, which can accurately map the semantic output of the large model to platform-recognizable style identifiers.
[0133] Taking the button component as an example, the website building platform can pre-define various visual variations and layout styles for buttons. The style calculator can have a built-in explicit decision tree or selection logic. For example, when it reads the simplified page component's input size: "large" and position: "normal", the style calculator will automatically map it to the component style identifier styleId: "button-large". If the input attribute value is position: "fixed-bottom", it may be mapped to the style identifier of a large button fixed at the bottom of the page (e.g., styleId: "button-large-fixed-bottom"). Thus, based on only a few semantic fields provided by the large model, the deterministic transformation program can automatically complete the selection of complex style branches and the construction of component style identifiers.
[0134] Furthermore, on the page rendering platform, the determined component style identifier (styleId) can directly drive the rendering of page components. In some embodiments, the page renderer can maintain the correspondence between various styleIds and specific CSS style sheets or rendering properties in an internal style library. For example, when the page renderer reads styleId: "button-large" in the complete page configuration data, it can automatically extract and apply the precise pixel values and design specifications bound to that style from the style library (such as automatically filling the font size fontSize=16, rounded corner borderRadius=4, specified background color backgroundColor: "#FF6B35", and breathing animation animation: "breath", etc.). Through this mechanism, not only is the burden of generating complex CSS or style properties for large models reduced, but the final rendered page is also effectively guaranteed to be visually completely consistent with the platform's design specifications and graphical user interface consistency.
[0135] In step S306, based on the child component reference field when the component type of the simplified page component is a layout component, an ordered child component list is generated, and the component coordinates of the complete page component are determined by combining the ordered child component list and the height field in the component field.
[0136] As mentioned earlier, based on the constraints of the large model-driven page protocol, one or more simplified page components in the simplified page configuration data are arranged in a flat list format. In front-end rendering, the layout structure of a page is usually expressed through deeply nested JSON objects (for example, a root container nests multiple horizontal containers, and the horizontal containers nest images and text). This deep physical nesting requires extremely high structural rigor, and large language models are prone to hierarchical errors or bracket closure errors during generation. In the simplified page configuration disclosed in this paper, all components are "flattened" and stored in the same one-dimensional array (flat list). Container components (such as vertical layout components Column or horizontal layout components Row) only refer to their internal child components by numbering through the internal "child component reference field" (e.g., children: ["img-1", "btn-1"]), thereby expressing the logical relationship between components and avoiding direct nesting of the complete component structure.
[0137] The following is an example JSON data of simplified page configuration data generated via a large language model according to embodiments of this disclosure.
[0138] { "version": "v0.9", "updateComponents": { "surfaceId": "page", "components": [ { "id": "page_root", "component": "Column", "children": ["block_hero"], "background": "#ffffff", "gap": 0}, { "id": "block_hero", "component": "Column", "children": ["hero_img","cta_btn"], "background": "#ffffff", "gap": 10}, { "id": "hero_img", "component": "Image", "url": "placeholder.png", "width": 375, "height": 667}, { "id": "cta_btn", "component": "Button", "text": "Learn More", "size": "large", "position": "fixed-bottom", "action": { "type": "link","url": ""}} ] }, "metadata": { "name": "Page Name", "title": "Browser Title", "backgroundColor": "#ffffff"} }
[0139] When restoring the page layout for the page renderer to load, it is necessary to first generate an ordered list of child components, re-parse this flat relationship based on numbered references into a page structure with nested and ordered relationships, and calculate the precise coordinates of each component that actually needs to be rendered.
[0140] It should be understood that the rendering engine (page renderer) of a website building platform typically requires each component to have precise pixel-level positioning information (e.g., how many pixels away from the top of the page, and specific values for width and height). In the embodiments of this disclosure, the large language model does not directly generate these coordinates. Because current large models excel at semantic understanding but lack precise mathematical calculation and spatial layout understanding capabilities, forcing the large model to output specific Y-coordinate values could easily cause components to overlap on the page or exceed screen boundaries. Therefore, the large model only needs to output the existence and logical order of components, while precise coordinate calculations are derived by a deterministic transformation program based on the component height.
[0141] Figure 4 An exemplary flowchart of a method 400 for generating an ordered list of subcomponents according to an embodiment of the present disclosure is shown.
[0142] In step S402, a page component mapping table corresponding to one or more simplified page components in the simplified page configuration data is established based on the unique identifier of the simplified page component.
[0143] Specifically, since the components output by the large model are in a one-dimensional array, the system first traverses the array, using the simplified ID (e.g., "img-1") of each simplified page component's large model output as the key and the complete data object of that component as the value, storing it in a lookup table such as a mapping table or dictionary. In this way, when a specific sub-component needs to be found in any subsequent step, it can be retrieved directly from the mapping table by ID in O(1) time complexity, without repeatedly traversing the entire array, greatly improving parsing efficiency.
[0144] In step S404, the simplified page components in the simplified page configuration data are traversed to perform the following steps for each of the simplified page components.
[0145] In some embodiments, the traversal begins with the logical root node (e.g., a vertical layout component Column whose identifier is designated "page_root"), identifies all the "leaf components" that actually need to be rendered on the page, and records their arrangement order from top to bottom and from left to right on the page.
[0146] In step S406a, in response to determining that the component type is a container component, the component type of the sub-component is determined through the page component mapping table based on the unique identifier of the sub-component reference field in the container component.
[0147] In some embodiments, container components (or layout components) include vertical container components and horizontal container components, and leaf components are components whose component type is outside of container components.
[0148] The deterministic procedure reads the list of child component IDs listed in the children field of the container component, and retrieves the actual data structure and component type of these child components through the mapping table established in step S402.
[0149] In step S406b, in response to the child component being a leaf component, the child component is added to the ordered child component list.
[0150] Leaf components are the basic components that are actually used for content display and interaction and do not contain any other child components (such as Image, Text, and Button components in the default page component directory). When the currently traversed component is determined to be a leaf component, the deterministic conversion program adds it to the ordered child component list in the order it is read. The order in this list represents the actual arrangement position of the component in the page content area.
[0151] In step S406c, in response to the child component being a container component, the child components of the child component are recursively expanded to determine the component type of the child components of the child component, until the child components of the child component are leaf components.
[0152] If the child component found through the mapping table is still a container component (e.g., nested within a Row or Column), the system will continue to call the recursive algorithm, expand the `children` field of the inner container component, and repeat the above judgment process until all branches of the recursion tree reach the leaf components. At this point, all leaf components are added to the ordered child component list according to their order in the simplified page configuration data.
[0153] Using the method described above 400, the deterministic transformation program converts the flat and disordered component data output by the large language model into an ordered list of sub-components arranged from top to bottom according to the actual rendering order of the page.
[0154] Figure 5 An exemplary flowchart of a method 500 for determining component coordinates according to an embodiment of the present disclosure is shown.
[0155] After generating the ordered list of child components, it is necessary to assign specific coordinates to the components actually rendered on the page. In the business scenario of a website landing page, some components are relatively positioned components (or ordinary components) that are arranged sequentially as the page scrolls, while others are fixed-position components that need to remain fixed at the top or bottom of the screen (such as sticky navigation bars or sticky buttons). Fixed-position components do not change position as the page content scrolls. Because the positioning rules for these two types of components are different, in some embodiments, fixed-position components and relatively positioned components can be separated and their coordinates calculated separately.
[0156] In step S502, the ordered sub-component list is traversed, and a fixed-position component list and a relative-position component list are generated based on the position field in the component field.
[0157] Specifically, the deterministic transformation process iterates through each leaf component in the previously generated list of ordered child components and examines the position field (e.g., the position field) in its component fields that indicates the component's location.
[0158] If the location field has a fixed attribute, such as fixed at the top (e.g., fixed-top) or fixed at the bottom (e.g., fixed-bottom), the deterministic transformation procedure can extract the component from the original list and add it to the list of fixed-location components.
[0159] If the position field's attribute value is a non-fixed attribute, such as "normal" or no position field specified, it indicates that the component belongs to a relative position component (or a regular component) that scrolls with the page flow. The deterministic conversion process can then add it to the relative position component list. During this process, the order of relative position components in the relative position component list remains consistent with their order in the original ordered child component list. Through separation operations based on the component's fixed attributes, fixed components will no longer participate in the subsequent vertical coordinate accumulation calculation of regular content, avoiding interference with the normal page flow layout.
[0160] In step S504, the component coordinates of each fixed-position component in the fixed-position component list are determined based on the attribute value of the position field in the component field.
[0161] Because the coordinates of a fixed-position component are relative to the device screen (page viewport), they do not need to rely on the sum of the heights of other components. The deterministic transformation procedure can directly set the fixed coordinates based on the attribute value of its position field. For example, if the attribute value is "fixed-top," its Y-coordinate (vertical coordinate) is directly set to 0 (i.e., the top of the screen). If the attribute value is "fixed-bottom," its Y-coordinate is set to the preset screen height minus the button's own height (for example, if the simulated screen height is 667 pixels and the button height is 60 pixels, the Y-coordinate is directly fixed at 607 pixels).
[0162] In step S506, based on the attribute values or preset spacing of the height field and component spacing field in the component field, the height and spacing of each relative position component in the relative position component list are calculated from top to bottom to determine the component coordinates of each relative position component.
[0163] In some examples, the deterministic transformation procedure sets the initial cumulative Y-coordinate to 0 (i.e., the top of the page). In other examples, the deterministic transformation procedure sets the initial cumulative Y-coordinate to the height of a fixed-position component at the top. The deterministic transformation procedure then iterates through each relatively-positioned component in the list of relatively-positioned components in sequence, executing the following logic: First, determine the current component's height by checking if the component's simplified configuration data includes a height field. For example, a large model might have specified a height of 500 pixels when generating an Image component, in which case that height is used directly. If the component (e.g., a Text component or a Button component) does not specify a height, the system will call the system's default height corresponding to that component type from the preset component template (e.g., setting the default height of a Text component to 50 pixels and the default height of a Button component to 44 pixels).
[0164] Then, record the Y coordinate of the current component, that is, assign the current cumulative Y coordinate to the component as its absolute vertical physical coordinate on the page.
[0165] Finally, the actual height of the current component is added to the cumulative Y-coordinate (i.e., the new cumulative Y-coordinate = the old cumulative Y-coordinate + the current component height). Additionally, if the parent container component of these components (e.g., a vertical container like Column) specifies a gap field property value, or if the system has configured a preset gap for this type of component, the conversion process will also add this gap value to the cumulative Y-coordinate, thus leaving blank space for the next component to be arranged.
[0166] Through this top-down cumulative calculation, the precise layout coordinates (including left, top, width, height, etc.) required by the page renderer are all calculated and completed by a deterministic program. The large language model does not need to output or calculate any complex pixel-level positioning information, thus avoiding page component overlap or layout errors caused by the weak mathematical calculation capabilities of the large model.
[0167] In step S308, based on the component type and according to the preset component template, the component fields and field attribute values required for the component interaction logic are filled into the complete page component.
[0168] Specifically, after generating globally unique identifiers, matching styles, and calculating the specific coordinates of components on the page, the deterministic transformation process also needs to further expand and populate the few semantic fields contained in the simplified page components into the multi-layered nested structure and complex component interaction logic events necessary for the underlying page renderer.
[0169] In some embodiments, the deterministic conversion process includes a component-type-based independent component converter. When converting simplified page components, it invokes the independent component converter corresponding to the component type. For each component type, the deterministic conversion process invokes a dedicated converter to perform the conversion according to specific conversion rules for that component type, thereby achieving decoupling of the conversion logic and high scalability. When a new component is added to the preset page component directory, only a separate component converter needs to be built for that new component type.
[0170] In some examples, the standalone component converters include, but are not limited to, image component converters, button component converters, text component converters, form component converters, download component converters, and video component converters. Examples of the specific conversion logic for each standalone component converter, in conjunction with embodiments of this disclosure, are as follows: - Image Component Converter: The converter can combine the flat image address field (e.g., url) output by the large model into a multi-level nested path in the business specification (e.g., data.content.image), and can automatically complete the image's click interaction behavior structure (e.g., a complete underlying data skeleton containing multiple behaviors such as jump links and form pop-ups).
[0171] - Button Component Converter: In addition to determining the style identifier as described above, this converter is primarily responsible for mapping the component's interaction logic. For example, it maps the simple behavioral intent (action.type) output by the large model to the platform's underlying event type (e.g., mapping "link" to a linkEvent, "form" to a pop-up formEvent, "scheme" to a Deep Link's schemeEvent, "weixin" to wxEvent, etc.), and completes complex parameter fields such as underlying routes and pop-up IDs based on the behavior type.
[0172] - Text Component Converter: This converter can wrap the plain text output by a large model into a rich text object structure required by the underlying rendering engine, and automatically completes the default parameters such as font size, color, alignment and line height.
[0173] - Form Component Converter: This converter can automatically complete the default form collection item configuration of the website building platform (such as automatically configuring default collection fields such as "name" and "phone number") based on simple titles and theme colors, and fill in the default prompt logic for successful submission.
[0174] - Download Component Converter: This converter can automatically expand and complete the underlying download link data structure, including independent configurations for different system operating environments such as iOS and Android, based on simplified data.
[0175] - Video Component Converter: This converter automatically completes the full configuration structure of the video player based on the video ID, including underlying attributes such as whether to autoplay, whether to loop, and cover image configuration.
[0176] In some embodiments, the independent component converter can be responsible for the deep structural assembly of components, the completion of functional logic (such as the event response configuration mentioned above), and the integration and filling of style data. The relatively complex global calculation of component coordinates in the aforementioned steps (such as distinguishing between relative / fixed positions, accumulating the vertical Y-coordinate, etc.) can be uniformly completed by a deterministic conversion program, such as a central scheduling module. When the independent component converter executes, it only needs to directly write the precise coordinate data calculated by the central scheduling module into the data structure corresponding to the component (such as a data.layout object).
[0177] After processing by the aforementioned deterministic transformation procedure, the simplified page configuration data output by the large model is assembled into complete page configuration data. The complete page configuration data is a collection of complete page components. In embodiments of this disclosure, the number of component fields and attribute values corresponding to each page component in the complete page configuration data is greater than the number of component fields and attribute values in the corresponding simplified page component. In some examples, the number of component fields and attribute values in the simplified page component is constrained by the page protocol driven by the large model.
[0178] For example, a simplified page component that originally contained only 3-6 descriptive fields can be transformed and completed into a full page component containing 20 to 30 or more business-required fields, including a unique identifier, the component's internal name, various business default state markers (such as active state and error state), a multi-level event behavior structure, and precise layout size information.
[0179] Taking the image component as an example, for an image component, the output of the large model can be a description that only includes three fields: url (address), width, and height. { "component": "Image", "url": "placeholder-001", "width": 375, "height": 500}.
[0180] After being transformed by a deterministic transformation procedure, the simplified image component description is converted into the complete image component as follows: { "id": "22127c84-dc5d-4b43-bfa9-091d7f8dac30", "name": "image-normal", "active": false, "fixed": "", "position": true, "hasError": false, "data": { "content": { "image": "placeholder-001", "link": { "type": "linkEvent", "behavior": { "url": "", "scheme": "", "formId": "", "form": { "useTitle": 1, "title": "", "successMessage": "Submission successful!"}, "ios": { "scheme": "", "id": "", "url": ""}, "android": { "scheme": "", "id": "", "url": ""} } } }, "layout": { "left": 0, "top": 0, "width": 375, "height": 500, "rotate": 0, "resizeWidth": 1, "resizeHeight": 1, "aspectRatio": 1} } }
[0181] These complete page components, such as the complete image component example mentioned above, are aggregated and assembled to form a strictly formatted complete page configuration data. This complete page configuration data is typically a domain-specific language (DSL, such as a deeply nested JSON object containing dozens or even hundreds of parameters) directly supported by the website building platform's rendering engine (page renderer). Because this complete page configuration data is completely independent of the free generation of a large language model, but is deterministically converted from a valid template by fixed code, it possesses extremely high format stability and idempotency, fully conforming to the rendering standards of the page renderer. This ensures that the page renderer can smoothly load the complete page configuration data ultimately generated based on the user's natural language page generation request.
[0182] In step S108, the page is rendered based on the complete page configuration data using the page renderer.
[0183] Specifically, a page renderer is a rendering engine in a website building platform or front-end application responsible for transforming underlying DSL data into a visual interface. The embodiments disclosed herein do not limit the carrier and form of the page renderer for rendering complete page configuration data.
[0184] In some embodiments, the page renderer can be embedded in the browser of an electronic device, or integrated into a mobile application or desktop client. In a graphical user interface (such as an AI-powered website building platform), the page renderer can be represented as a real-time page preview window (e.g., simulating a 375×667 pixel mobile phone screen skeleton). Since the complete page configuration data at this point already contains component coordinates, style identifiers, and valid nested structures, the page renderer can directly read, load, and render the page based on the complete page configuration data.
[0185] To reduce user response time and allow for a quick view of the initial page generation results, some implementations employ a two-stage asynchronous rendering strategy: first, the skeleton is rendered, then the content is filled in. Specifically, in response to the completion of the complete page configuration data conversion, the page renderer can first render the page's skeleton structure based on pre-calculated component coordinates, asynchronously waiting for the acquisition of materials for each component in the complete page configuration data. During this time, the positions of components that rely on external materials, such as images, are temporarily displayed using loading animations or placeholders. Subsequently, the system asynchronously calls external image generation services or material interfaces. Once the actual materials are acquired, the page renderer dynamically replaces the placeholders and updates the view. This approach provides users with intuitive visual feedback within 2-3 seconds, and even if asynchronous material generation fails, it does not affect the overall legitimacy and usability of the page structure.
[0186] In some embodiments, the materials required by the component can be text, images, videos, or other content that meets the user's page generation requirements. These materials can be pre-stored or generated by calling other large models or intelligent agents.
[0187] In some embodiments, the scope of content generation and retrieval can be constrained based on the page generation strategy.
[0188] Furthermore, since this disclosure generates complete page configuration data that fully conforms to the underlying system standards (i.e., standard DSL), rather than unchangeable static images or hard-coded data that is difficult to maintain (such as raw HTML / CSS code directly generated by AI), it naturally possesses a high degree of editability.
[0189] In some embodiments, a page editor including a page renderer can read and render complete page configuration data; and in response to receiving component editing input from a user, modify the complete page configuration data and render the modified complete page configuration data in real time.
[0190] Specifically, the front-end system can write the complete page configuration data (such as a complete JSON object) output by the deterministic transformation program to the browser's local storage or a cloud database. Then, upon receiving editing instructions from the user, the system can display or redirect to a page editor user interface for component-level editing. This page editor user interface includes a low-code or no-code visual component editor, which can integrate a page renderer. The editor reads the complete page configuration data from storage and reflects the user's edits on a real-time rendering canvas or window.
[0191] In some embodiments, the component editing that users can input in the visual component editor includes: content replacement (for example, a user can click on a text component and directly modify the promotional text in the property panel, or click on an AI-generated placeholder image, upload and replace it with a local real product promotional image), style adjustment (for example, a user can select a button component and change its preset background color from blue to the brand's exclusive theme color, or adjust its rounded corner size), layout adjustment (for example, a user can drag and drop the mouse to directly change the arrangement order of multiple components in a horizontal container on the canvas, or adjust the spacing between components), and interaction logic adjustment (for example, a user can modify the click behavior of a button, such as changing the "jump to the official website" link behavior to "pop up a contact form" and configuring specific form items).
[0192] Whenever a user makes the above component editing input, the visual component editor will update the corresponding complete page configuration data in real time at the underlying level (such as updating a field in JSON), and trigger the page renderer to redraw in real time based on the modified data, so that the user can see the modification effect immediately.
[0193] Through the method 100 and related specific steps shown in the embodiments of this disclosure, this disclosure implements a system architecture that decouples the nondeterministic semantic generation capability of a large language model from the deterministic business logic of the underlying page rendering.
[0194] This disclosure, during the generation phase, uses a large model-driven page protocol and a preset page component directory to strictly constrain the output format and available content space of the large language model with a closed component list, limiting its output to simplified page configuration data with a flat structure and concise fields. This significantly reduces the cognitive burden of the large language model when processing complex nested data and effectively suppresses the illusion that the large language model may fabricate illegal components out of thin air, omit required fields, or output out-of-bounds attribute values.
[0195] Furthermore, this disclosure introduces a deterministic transformation procedure and preset component templates to automatically and deterministically expand the brief semantic intent output by the large model into complete page configuration data containing complete component styles, precise coordinates, and complex interaction logic. This overcomes the technical defects of traditional technologies that are prone to data structure disorder and loading errors when directly relying on large models to generate complex underlying business code, and ensures that the output results have extremely high format idempotency and structural stability.
[0196] Furthermore, this disclosure implements end-to-end controlled processing from user input to final page rendering. This includes structured convergence of the input large model content, format and content constraints and legality checks on the output content of the large model, and deterministic completion of the legal content output by the large model. This ensures the legality and idempotency of the data content and format throughout the entire process, making the final generated complete page configuration data fully compatible with existing page renderers and visual website building systems. This design significantly reduces the user's learning cost and page building time, while ensuring that the generated page fully supports fine-grained modification and long-term maintenance in the visual component editor.
[0197] Figure 6 An exemplary block diagram of a page generation system based on a large language model according to embodiments of the present disclosure is shown. It can be utilized... Figure 6 The system shown is used to perform the combination Figure 1 Method 100 is described.
[0198] like Figure 6 As shown, the page generation system 600 includes: User layer 601 is configured to receive page generation requests in natural language form from user input; Generation layer 602 is configured to generate structured simplified page configuration data through a large language model based on page generation request, large model-driven page protocol and preset page component directory. The simplified page configuration data includes one or more simplified page components. The large model-driven page protocol constrains the data format of the simplified page configuration data, and the preset page component directory constrains the component type, component fields and the value range of field attribute values of one or more simplified page components. Transformation layer 603 is configured to, based on simplified page configuration data and preset component templates, use a deterministic transformation procedure to complete the component styles, component coordinates, and component interaction logic of one or more simplified page components, thereby generating complete page configuration data that conforms to the rendering standards of the page renderer; and Output layer 604 is configured to render the page based on the complete page configuration data via the page renderer.
[0199] It should be understood that Figure 6 The various layers of the system 600 shown can be connected to a reference. Figure 1 Method 100 described Figure 2 Method 200 described Figure 3 Method 300 described Figure 4 Method 400 described and Figure 5 The steps in Method 500 are described in detail here, and will not be repeated.
[0200] Figure 7 An exemplary block diagram of a page generation apparatus based on a large language model according to embodiments of the present disclosure is shown. It can be utilized... Figure 7 The device shown is used to perform the combination. Figure 1 Method 100 is described.
[0201] like Figure 7 As shown, the device 700 includes: The receiving module 702 is configured to receive a page generation request in natural language form input by the user; The generation module 704 is configured to generate structured simplified page configuration data based on the page generation request, the large model-driven page protocol, and the preset page component directory, through the large language model. The simplified page configuration data includes one or more simplified page components. The large model-driven page protocol constrains the data format of the simplified page configuration data, and the preset page component directory constrains the component type, component fields, and the value range of field attribute values of one or more simplified page components. Conversion module 706 is configured to, based on simplified page configuration data and preset component templates, use a deterministic conversion procedure to complete the component styles, component coordinates, and component interaction logic of one or more simplified page components, thereby generating complete page configuration data that conforms to the rendering standards of the page renderer; and Output module 708 is configured to render a page based on the complete page configuration data using the page renderer.
[0202] In some embodiments, the receiving module 702 performs a validity check on the page generation request to determine whether the page generation request includes valid requirement information.
[0203] In some embodiments, the receiving module 702 responds to the page generation request by passing a validity check and performs a complexity judgment on the page generation request using a large language model; based on the complexity judgment result, it determines whether the prompt word template used by the large language model to generate simplified page configuration data includes external tool interfaces for obtaining page component materials and cases that conform to the page generation request.
[0204] In some embodiments, the conversion module 706 translates the simplified page configuration data generated by the large language model into a data format that the deterministic conversion program can recognize, according to the standard of the large model-driven page protocol, through a format translation function.
[0205] In some embodiments, the generation module 704 extracts the intent of the page generation request through a large language model; constrains the large language model with prompt words to output structured page intent analysis information based on intent fields and intent options within a preset range; determines a page generation strategy based on preset mapping rules and the page intent analysis information, wherein the page generation strategy includes page layout constraints, page component function constraints, and page component content range constraints; and determines a list of available component types for generating simplified page configuration data from the component type constraints of a preset page component directory based on the page generation strategy.
[0206] In some embodiments, the generation module 704 performs data validity verification on the simplified page configuration data based on the data format defined by the available component type constraints, component field constraints, field attribute value constraints, condition association constraints, and large model-driven page protocol constraints in the preset page component directory definition.
[0207] In some embodiments, the generation module 704 verifies the data format and structural integrity of the simplified page configuration data; for each simplified page component in the simplified page configuration data, it verifies whether the component type, component fields, and field attribute values of the simplified page component exceed the value range of the available component type constraints, component field constraints, and field attribute value constraints; and based on conditional association constraints, it verifies whether the component fields and field attribute values of the simplified page component related to the component interaction logic are complete.
[0208] In some embodiments, in response to a failure of the validity check, the generation module 704 inputs the verification error information as context information back into the large language model to trigger the large language model to regenerate the simplified page configuration data, until the simplified page configuration data passes the validity check or the number of times regeneration is triggered exceeds a preset retry threshold.
[0209] In some embodiments, the conversion module 706, based on simplified page configuration data and preset component templates, completes the component styles, component coordinates, and component interaction logic of one or more simplified page components through a deterministic conversion procedure. This includes performing the following steps for each simplified page component through the deterministic conversion procedure: For the complete page component corresponding to the simplified page component, generating a unique identifier and component name that conforms to the rendering standard of the page renderer; Based on the component type, component fields, and field attribute values of the simplified page component, determining the component style identifier through the style calculation function of the deterministic conversion procedure, the component style identifier being used by the page renderer to render the style of the complete page component; Based on the child component reference field when the component type of the simplified page component is a container component, generating an ordered list of child components, and combining the ordered list of child components and the height field in the component fields to determine the component coordinates of the complete page component; Based on the component type, and according to the preset component template, filling in the component fields and field attribute values required for the component interaction logic in the complete page component.
[0210] In some embodiments, the conversion module 706 generates an ordered list of sub-components by: establishing a page component mapping table corresponding to one or more simplified page components in the simplified page configuration data based on the unique identifier of the simplified page component; traversing the simplified page components in the simplified page configuration data to perform the following steps for each simplified page component: in response to determining that the component type is a container component, determining the component type of the sub-component through the page component mapping table based on the unique identifier of the sub-component reference field in the container component; in response to the sub-component being a leaf component, adding the sub-component to the ordered list of sub-components; in response to the sub-component being a container component, recursively expanding the sub-components of the sub-component to determine the component type of the sub-component of the sub-component, until the sub-component of the sub-component is a leaf component, wherein the container component includes vertical container components and horizontal container components, and the leaf component is a component whose component type is not a container component.
[0211] In some embodiments, the conversion module 706, by combining the ordered sub-component list and the height field in the component field, determines the component coordinates of the complete page components by: traversing the ordered sub-component list and generating a fixed-position component list and a relative-position component list based on the position field in the component field, wherein the relative-position components in the relative-position component list are arranged in the same order as the relative-position components in the ordered sub-component list; determining the component coordinates of each fixed-position component in the fixed-position component list based on the attribute value of the position field in the component field; and performing a top-down cumulative calculation of the height and spacing of each relative-position component in the relative-position component list based on the attribute values of the height field and the component spacing field in the component field or a preset spacing, to determine the component coordinates of each relative-position component.
[0212] In some embodiments, the conversion module 706 includes a component-type-based independent component converter to invoke the independent component converter corresponding to the component type when converting simplified page components.
[0213] In some embodiments, the independent component converters in the conversion module 706 include image component converters, button component converters, text component converters, form component converters, download component converters, and video component converters.
[0214] In some embodiments, the preset page component directory constraints in the generation module 704 include available component types such as image components, text components, button components, form components, download components, video components, vertical container components, and horizontal container components.
[0215] In some embodiments, the structured simplified page configuration data is in JSON format.
[0216] In some embodiments, the number of component fields and field attribute values corresponding to each page component in the complete page configuration data is greater than the number of component fields and field attribute values in the corresponding simplified page component. The number of component fields and field attribute values in the simplified page component is constrained by the large model-driven page protocol.
[0217] In some embodiments, in response to the completion of the conversion of the complete page configuration data, the output module 708 first renders the page skeleton based on the component coordinates, while asynchronously waiting for the material of each component in the complete page configuration data to be obtained.
[0218] In some embodiments, the output module 708 reads and renders complete page configuration data through a page editor including a page renderer; in response to receiving component editing input from the user, it modifies the complete page configuration data and renders the modified complete page configuration data in real time.
[0219] It should be understood that Figure 7 The various modules or units of the apparatus 700 shown can be used with reference to Figure 1 Method 100 described Figure 2 Method 200 described Figure 3 Method 300 described Figure 4 Method 400 described and Figure 5 The steps in method 500 described correspond to each other. Therefore, the operations, features, and advantages described above for methods 100, 200, 300, 400, and 500 also apply to apparatus 700 and its included modules and units. For the sake of brevity, some operations, features, and advantages will not be repeated here.
[0220] Furthermore, it should be understood that in the exemplary embodiments of this disclosure, Figure 7 The division of the various modules or units in the system 700 shown is merely a logical functional division for the convenience of description. In the actual physical device or software code implementation, this disclosure does not limit the boundaries of these modules or units, and their functions may overlap, intersect, or be highly integrated. Two or more independently described modules in the illustration can be merged into a single comprehensive entity module to jointly perform the aforementioned multiple operations, and a single module in the illustration can also be further split or decoupled into multiple sub-modules for performing finer-grained operations according to business needs.
[0221] According to another aspect of this disclosure, a method executed at a user device is also provided, the method comprising: providing a first graphical user interface to obtain a page generation request input by a user; generating structured simplified page configuration data through a large language model based on the page generation request, a large model-driven page protocol, and a preset page component directory, the simplified page configuration data including one or more simplified page components, wherein the large model-driven page protocol constrains the data format of the simplified page configuration data, and the preset page component directory constrains the component type, component fields, and value range of field attribute values of the one or more simplified page components; completing the component style, component coordinates, and component interaction logic of the one or more simplified page components through a deterministic transformation procedure based on the simplified page configuration data and preset component templates to generate complete page configuration data conforming to the rendering standard of a page renderer; displaying a page rendered by a page renderer in a page preview window of the first graphical user interface based on the complete page configuration data; providing a second graphical user interface in response to obtaining an edit request input by a user, wherein the second graphical user interface includes a visual component editor to enable the user to edit components included in the complete page configuration data; and rendering the modifications in the page corresponding to the component editing input in real time in the visual component editor in response to the user's component editing input.
[0222] Figure 8A and Figure 8B An exemplary user interface graphic is shown, generated based on a large language model of a page according to an embodiment of this disclosure.
[0223] like Figure 8AAs shown, in the initial stage, the system provides a first graphical user interface 801 (e.g., an AI intelligent website building workbench interface) on the user's device to obtain the page generation request input by the user. This first graphical user interface 801 can be divided into two main working areas, left and right. The left area is the request input and status control area, which includes a natural language input box 804. The user can input unstructured page generation requests (e.g., "Generate a promotional page for store A's application, requiring one image and one button" as shown in the illustration) in the natural language input box 804 through text typing or speech transcription. Subsequently, the user can submit the request by clicking the "Generate Page" button 805.
[0224] Upon receiving the page generation request, the system generates structured simplified page configuration data based on the request, the large model-driven page protocol, and the preset page component directory, using a large language model. This simplified page configuration data includes one or more simplified page components. As mentioned earlier, the large model-driven page protocol constrains the data format of the simplified page configuration data, and the preset page component directory strictly constrains the component types, component fields, and the range of field attribute values for these one or more simplified page components. Next, based on this simplified page configuration data and the preset component template, the system uses a deterministic transformation procedure to complete the component styles, component coordinates, and component interaction logic of one or more simplified page components, thereby generating complete page configuration data that conforms to the rendering standards of the underlying page renderer.
[0225] After completing the data generation and deterministic completion in the background, the system displays the page rendered in real time by the page renderer in the page preview window 802 on the right side of the first graphical user interface 801, based on the complete page configuration data. For example... Figure 8A As shown, the page preview window 802 typically simulates the screen ratio and borders of a real mobile device (such as a mobile phone). Since the complete page configuration data already contains precise coordinates and style identifiers, the page renderer can render the component architecture here. At this stage, the system can adopt an asynchronous strategy of skeleton first and then filling in, for example, prioritizing the rendering of image placeholders, text components (such as "Shop A"), and button components with relative positions (such as the "Click to Enter" button), and rendering fixed-position components (such as the "Download Now" sticky button 803 fixed at the bottom of the page) in the separated fixed coordinate area. At the same time, the first graphical user interface 801 may also include a metadata information panel 806 to display the status information of the currently generated page to the user (such as page name, number of modules, number of components, etc.).
[0226] At this point, users can visually review the initial draft of the page rendered by the page renderer in the page preview window 802. If users wish to make further personalized modifications or publish the page, they can click the "Open in Editor" button 807 to send an editing request to the system.
[0227] like Figure 8B As shown, in response to an editing request that receives user input, the system provides a second graphical user interface (GUI) on the user's device. It should be understood that the second GUI may be a route jump, pop-up overlay, or view switch based on the first GUI. The second GUI provides a fully functional visual component editor, allowing the user to freely edit all page components included in the complete page configuration data.
[0228] exist Figure 8B In the second graphical user interface shown, in addition to the centrally located, real-time rendered page preview window 802 and the bottom-click button 803, the interface extends to include a low-code / no-code component editing workspace. For example, a component panel 808 can be provided on the left, listing all draggable and addable components (which maintains strong consistency with the preset page component directory). A corresponding style and content configuration panel 809 can pop up in the middle or on the side (for example, for uploading custom images, modifying text, or configuring events), and a property and layer management panel 810 can be included on the right for users to perform more granular page structure adjustments and layer hierarchy management. In the property and layer management panel 810, users can modify the style, content, and interaction logic of components by directly editing the CSS / HTML code or the corresponding component field attribute values in the JSON declarative data.
[0229] In response to user component editing input (e.g., dragging a new component into the component panel 808, replacing a real store promotional image in the style and content configuration panel 809, or changing the background color of a button or clicking a link in the attribute and layer management panel 810), the visual component editor updates the corresponding complete page configuration data in real time at the underlying level. Simultaneously, the system redraws and renders the page in real time in the visual component editor (page preview window 802) to reflect the changes made to the component editing input, thus providing the user with immediate visual feedback.
[0230] According to another aspect of this disclosure, an electronic device is also provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program that, when executed by the at least one processor, implements the method described above.
[0231] According to another aspect of this disclosure, a computer-readable storage medium storing a computer program is also provided, wherein the computer program implements the method described above when executed by a processor.
[0232] According to another aspect of this disclosure, a computer program product is also provided, comprising a computer program, wherein the computer program, when executed by a processor, implements the method described above.
[0233] See Figure 9 The present invention describes a structural block diagram of an electronic device 900 that can serve as a server or client of the present disclosure, which is an example of a hardware device that can be applied to various aspects of the present disclosure. The electronic device can be different types of computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or claimed herein.
[0234] like Figure 9 As shown, the electronic device 900 may include at least one processor 901, working memory 902, input unit 904, display unit 905, speaker 906, storage unit 907, communication unit 908, and other output units 909 that are capable of communicating with each other via system bus 903.
[0235] Processor 901 may be a single processing unit or multiple processing units, and all processing units may include single or multiple computing units or multiple cores. Processor 901 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operating instructions. Processor 901 may be configured to acquire and execute computer-readable instructions stored in working memory 902, storage unit 907, or other computer-readable media, such as program code of operating system 902a, program code of application program 902b, etc.
[0236] Working memory 902 and storage unit 907 are examples of computer-readable storage media for storing instructions that are executed by processor 901 to perform the various functions described above. Working memory 902 may include both volatile and non-volatile memory (e.g., RAM, ROM, etc.). Furthermore, storage unit 907 may include hard disk drives, solid-state drives, removable media including external and removable drives, memory cards, flash memory, floppy disks, optical disks (e.g., CDs, DVDs), storage arrays, network-attached storage, storage area networks, etc. Working memory 902 and storage unit 907 may be collectively referred to herein as memory or computer-readable storage media, and may be non-transitory media capable of storing computer-readable, processor-executable program instructions as computer program code, which may be executed by processor 901 as a specific machine configured to perform the operations and functions described in the examples herein.
[0237] Input unit 906 can be any type of device capable of inputting information to electronic device 900. Input unit 906 can receive input digital or character information and generate key signal input related to user settings and / or function control of electronic device, and can include, but is not limited to, a mouse, keyboard, touch screen, trackpad, trackball, joystick, microphone and / or remote control. Output unit can be any type of device capable of presenting information, and can include, but is not limited to, display unit 905, speaker 906 and other output units 909. Other output units 909 can include, but are not limited to, video / audio output terminals, vibrators and / or printers. Communication unit 908 allows electronic device 900 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and can include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers and / or chipsets, such as Bluetooth™ devices, 802.11 devices, WiFi devices, WiMax devices, cellular communication devices and / or the like.
[0238] The application program 902b in the working memory 902 can be loaded to execute the various methods and processes described above, for example... Figure 1Boxes 102-110 in the diagram. For example, in some embodiments, the multi-agent-based resource matching method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 907. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 900 via storage unit 907 and / or communication unit 908. When the computer program is loaded and executed by processor 901, one or more steps of the multi-agent-based resource matching method described above can be performed. Alternatively, in other embodiments, processor 901 can be configured to perform the multi-agent-based resource matching method by any other suitable means (e.g., by means of firmware).
[0239] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0240] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0241] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0242] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0243] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.
[0244] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.
[0245] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.
[0246] While embodiments or examples of this disclosure have been described with reference to the accompanying drawings, it should be understood that the methods, systems, and devices described above are merely exemplary embodiments or examples, and the scope of the invention is not limited by these embodiments or examples, but only by the claims and their equivalents. Various elements in the embodiments or examples may be omitted or replaced by their equivalents. Furthermore, the steps may be performed in a different order than that described in this disclosure. Further, various elements in the embodiments or examples may be combined in various ways. Importantly, as the technology evolves, many elements described herein can be replaced by equivalents that appear after this disclosure.
Claims
1. A page generation method based on a large language model, comprising: Obtain the page generation request in natural language form from the user's input; Based on the page generation request, the large model-driven page protocol, and the preset page component directory, structured simplified page configuration data is generated through the large language model. The simplified page configuration data includes one or more simplified page components. The large model-driven page protocol constrains the data format of the simplified page configuration data, and the preset page component directory constrains the component type, component fields, and value range of the field attribute values of the one or more simplified page components. Based on the simplified page configuration data and preset component templates, a deterministic transformation procedure is used to complete the component styles, component coordinates, and component interaction logic of one or more simplified page components, thereby generating complete page configuration data that conforms to the rendering standards of the page renderer; and The page is rendered using the page renderer based on the complete page configuration data.
2. The page generation method based on a large language model according to claim 1, wherein, The method further includes: The page generation request is validated to determine whether it includes valid requirement information.
3. The page generation method based on a large language model according to claim 2, the method further includes: In response to the page generation request passing the validity check, the complexity of the page generation request is determined by the large language model. Based on the complexity assessment result, determine whether the prompt word template used by the large language model to generate the simplified page configuration data includes external tool interfaces for obtaining page component materials and cases that conform to the page generation request.
4. The page generation method based on a large language model according to claim 1, wherein, The method further includes: According to the standard of the large model-driven page protocol, the simplified page configuration data generated by the large language model is translated into a data format that the deterministic conversion program can recognize through a format translation function.
5. The page generation method based on a large language model according to claim 1, wherein, The method further includes: The intent of the page generation request is extracted using the large language model. The large language model is constrained by prompt words to output structured page intent analysis information based on intent fields and intent options within a preset range; Based on preset mapping rules, a page generation strategy is determined according to the page intent analysis information. This page generation strategy includes page layout constraints, page component functional constraints, and page component content scope constraints. Based on the page generation strategy, a list of available component types for generating the simplified page configuration data from the component type constraints of the preset page component directory is determined.
6. The page generation method based on a large language model according to claim 1, wherein, The method further includes: Based on the data format of the available component type constraints, component field constraints, field attribute value constraints, and condition association constraints defined in the preset page component directory, and the large model-driven page protocol constraints, the simplified page configuration data is validated for data validity.
7. The page generation method based on a large language model according to claim 6, wherein, The legality verification includes: Verify the data format and structural integrity of the simplified page configuration data; For each simplified page component in the simplified page configuration data, verify whether the component type, component fields, and field attribute values of the simplified page component exceed the value range of the available component type constraint, the component field constraint, and the field attribute value constraint; and Based on the aforementioned conditional association constraints, verify whether the component fields and field attribute values related to the component interaction logic of the simplified page component are complete.
8. The page generation method based on a large language model according to claim 7, wherein, The method further includes: In response to a failure of the validity check, the error information is used as context information and re-inputted into the large language model to trigger the large language model to regenerate the simplified page configuration data, until the simplified page configuration data passes the validity check or the number of times the regeneration is triggered exceeds a preset retry threshold.
9. The page generation method based on a large language model according to claim 1, wherein, The step of completing the component style, component coordinates, and component interaction logic of one or more simplified page components through a deterministic transformation procedure based on simplified page configuration data and preset component templates includes performing the following steps for each simplified page component through a deterministic transformation procedure: For each complete page component corresponding to the simplified page component, a unique identifier and component name conforming to the page renderer rendering standard are generated; Based on the component type, component fields, and field attribute values of the simplified page component, the component style identifier is determined by the style calculation function of the deterministic conversion program. The component style identifier is used by the page renderer to render the style of the complete page component. Based on the child component reference field when the component type of the simplified page component is a container component, an ordered list of child components is generated. The component coordinates of the complete page component are determined by combining the ordered list of child components and the height field in the component field. Based on the component type, and according to the preset component template, the component fields and field attribute values required for the component interaction logic are filled into the complete page component.
10. The page generation method based on a large language model according to claim 9, wherein, The simplified page configuration data, in which one or more simplified page components are arranged in a flat list format, and the generation of an ordered sub-component list based on the sub-component reference field when the component type of the simplified page component is a container component, includes: Based on the unique identifier of the simplified page component, establish a page component mapping table corresponding to one or more simplified page components in the simplified page configuration data; Iterate through the simplified page components in the simplified page configuration data to perform the following steps for each simplified page component: In response to determining that the component type is a container component, the component type of the sub-component is determined through the page component mapping table based on the unique identifier of the sub-component reference field in the container component; In response to the fact that the child component is a leaf component, the child component is added to the ordered child component list; In response to the fact that the sub-component is a container component, the sub-components of the sub-component are recursively expanded to determine the component type of the sub-components of the sub-components, until the sub-components of the sub-components are leaf components, wherein the container component includes vertical container components and horizontal container components, and the leaf component is a component whose component type is outside the container component.
11. The page generation method based on a large language model according to claim 10, wherein, Determining the component coordinates of the complete page component by combining the ordered list of sub-components and the height field in the component fields includes: Traverse the ordered sub-component list and generate a fixed-position component list and a relative-position component list based on the position field in the component field, wherein the relative-position components in the relative-position component list are arranged in the same order as the relative-position components in the ordered sub-component list; Based on the attribute value of the position field in the component field, determine the component coordinates of each fixed-position component in the fixed-position component list; Based on the attribute values or preset spacing of the height field and component spacing field in the component field, the height and spacing of each relative position component in the relative position component list are cumulatively calculated from top to bottom to determine the component coordinates of each relative position component.
12. The page generation method based on a large language model according to claim 9, wherein, The deterministic conversion procedure includes an independent component converter based on the component type, which, when converting the simplified page component, invokes the independent component converter corresponding to the component type based on the component type.
13. The page generation method based on a large language model according to claim 12, wherein, The independent component converters include image component converters, button component converters, text component converters, form component converters, download component converters, and video component converters.
14. The page generation method based on a large language model according to claim 1, wherein, The preset page component directory restricts the available component types to include image components, text components, button components, form components, download components, video components, vertical container components, and horizontal container components.
15. The page generation method based on a large language model according to claim 1, wherein, The structured, simplified page configuration data is in JSON format.
16. The page generation method based on a large language model according to claim 1, wherein, The number of component fields and field attribute values corresponding to each page component in the complete page configuration data is greater than the number of component fields and field attribute values in the corresponding simplified page component. The number of component fields and field attribute values in the simplified page component is constrained by the large model-driven page protocol.
17. The page generation method based on a large language model according to claim 1, wherein, The method further includes: In response to the completion of the conversion of the complete page configuration data, the page renderer first renders the page skeleton based on the component coordinates, while asynchronously waiting for the acquisition of materials for each component in the complete page configuration data.
18. The page generation method based on a large language model according to claim 1, wherein, The step of rendering the page based on the complete page configuration data using the page renderer includes: The complete page configuration data is read and rendered by a page editor that includes the page renderer; In response to receiving the user's component editing input, the complete page configuration data is modified and the modified complete page configuration data is rendered in real time.
19. A page generation system based on a large language model, comprising: The user layer is configured to receive page generation requests in natural language form from user input; The generation layer is configured to generate structured simplified page configuration data through a large language model based on the page generation request, the large model-driven page protocol, and a preset page component directory. The simplified page configuration data includes one or more simplified page components. The large model-driven page protocol constrains the data format of the simplified page configuration data, and the preset page component directory constrains the component type, component fields, and value range of the field attribute values of the one or more simplified page components. A conversion layer, configured to, based on the simplified page configuration data and preset component templates, use a deterministic conversion procedure to complete the component styles, component coordinates, and component interaction logic of one or more simplified page components, thereby generating complete page configuration data that conforms to the rendering standards of the page renderer; and An output layer, configured to render a page based on the complete page configuration data via the page renderer.
20. A page generation device based on a large language model, comprising: A receiving module, configured to receive a page generation request in natural language form input by the user; The generation module is configured to generate structured simplified page configuration data through a large language model based on the page generation request, the large model-driven page protocol, and a preset page component directory. The simplified page configuration data includes one or more simplified page components. The large model-driven page protocol constrains the data format of the simplified page configuration data, and the preset page component directory constrains the component type, component fields, and value range of the field attribute values of the one or more simplified page components. A conversion module, configured to, based on the simplified page configuration data and preset component templates, use a deterministic conversion procedure to complete the component styles, component coordinates, and component interaction logic of one or more simplified page components, thereby generating complete page configuration data that conforms to the rendering standards of the page renderer; and An output module, configured to render a page based on the complete page configuration data using the page renderer.
21. A method performed at a user equipment, the method comprising: Provide a first graphical user interface to obtain the page generation request input by the user; Based on the page generation request, the large model-driven page protocol, and the preset page component directory, structured simplified page configuration data is generated through the large language model. The simplified page configuration data includes one or more simplified page components. The large model-driven page protocol constrains the data format of the simplified page configuration data, and the preset page component directory constrains the component type, component fields, and value range of the field attribute values of the one or more simplified page components. Based on the simplified page configuration data and preset component templates, a deterministic transformation procedure is used to complete the component styles, component coordinates, and component interaction logic of one or more simplified page components to generate complete page configuration data that conforms to the rendering standards of the page renderer. Based on the complete page configuration data, the page rendered by the page renderer is displayed in the page preview window of the first graphical user interface; In response to an edit request obtained from the user input, a second graphical user interface is provided, wherein the second graphical user interface includes a visual component editor to enable the user to edit components included in the full page configuration data; and In response to the user's component editing input, the modification corresponding to the component editing input is rendered in real time in the visual component editor.
22. An electronic device, comprising: At least one processor; as well as A memory that is communicatively connected to the at least one processor; in The memory stores a computer program that, when executed by the at least one processor, implements the method according to any one of claims 1-18.
23. A non-transitory computer-readable storage medium storing a computer program, wherein, The computer program, when executed by a processor, implements the method according to any one of claims 1-18.
24. A computer program product comprising a computer program, wherein, The computer program, when executed by a processor, implements the method according to any one of claims 1-18.