Method, system and electronic device for generating an embedded component

Abstract

Embodiments of the present specification provide a method and system for generating an embedded component and an electronic device. The method comprises: obtaining a predefined interface specification of a target platform; obtaining context information, wherein the context information at least includes user intention information determined based on user input, and platform constraint information obtained based on the target platform regardless of the user input; based on the predefined interface specification and the context information, dynamically assembling a generation prompt, and guiding a large language model to output code conforming to the predefined interface specification by injecting the predefined interface specification as a constraint condition into the generation prompt; inputting the generation prompt into the large language model to obtain generated code conforming to the predefined interface specification and the context information; and outputting the generated code as an embedded component suitable for embedding the target platform.

Description

Technical Field

[0001] This specification relates to the field of computer software technology, specifically to a method, system, and electronic device for generating embedded components. Background Technology

[0002] As enterprises deepen their digital transformation, large organizations often run multiple business systems and data platforms. To flexibly integrate and display data across different business scenarios, these platforms typically provide embedded component frameworks. These frameworks allow third-party developers to embed custom functional components into the platform's standard pages for operation and interaction, following predefined interface specifications. These predefined interface specifications are technical agreement documents established by the platform, clearly defining the technical contract between components and the platform regarding data interaction, lifecycle management, event communication, and rendering methods. Adherence to these interface specifications is a prerequisite for any external component to be successfully embedded and function correctly on the target platform.

[0003] In recent years, artificial intelligence technologies, represented by Large Language Models (LLMs), have made significant progress. Existing general-purpose AI code generation tools based on large language models can quickly generate program code such as front-end pages and interactive components based on users' natural language descriptions, greatly lowering the barrier to software development. However, these general-purpose AI code generation tools are primarily designed for building independent applications or pages, and the component code they generate is usually self-contained and does not depend on a specific host platform's runtime environment. When enterprise users want to embed AI-generated component code into their internal business platforms, they face a significant technical obstacle: the code generated by general-purpose AI tools does not conform to the predefined interface specifications of the target platform. The data acquisition methods, lifecycle callback functions, and rendering entry formats of the component code are inconsistent with the platform's requirements, making it impossible for the platform to recognize the code as a compliant embedded component, thus hindering direct loading and execution.

[0004] While general-purpose AI code generation tools can functionally satisfy users' natural language descriptions, from an engineering integration perspective, the data acquisition methods, lifecycle callback function signatures, and rendering entry formats of the generated component code often differ from the formats required by the target platform. This results in the code being unable to be correctly recognized and loaded by the platform. Because platform interface specifications describe the platform's technical conventions for embedded components in areas such as data interaction, lifecycle management, and rendering methods, and general-purpose AI generation tools are not constrained by these technical conventions during code generation, their output code deviates structurally from the platform specifications. Consequently, the generated code typically requires manual modification and adaptation to become an embedded component that meets platform requirements. This makes it difficult for AI-assisted code generation results to leverage their efficiency advantages in enterprise-level platform component development scenarios. Summary of the Invention

[0005] This specification provides an embedded component generation method, system, and electronic device, aiming to solve the technical problem in the prior art where component code generated by large language models cannot automatically comply with the predefined interface specifications of the target platform, making it difficult for AI-generated code to be directly deployed as a compliant embedded component to an enterprise platform.

[0006] According to a first aspect of the embodiments of this specification, a method for generating an embedded component is provided, comprising: Obtain the predefined interface specification of the target platform, wherein the target platform involves at least one extension point, the extension point is used to receive components embedded in the target platform, and the predefined interface specification describes the interface required by each of the at least one extension point; Obtain context information, wherein the context information includes at least user intent information determined based on user input, and platform constraint information obtained based on the target platform and unrelated to the user input. The user intent information represents the functional requirements for the embedded component, and the platform constraint information represents the integration constraints imposed by the target platform on the embedded component. Based on the predefined interface specification and the context information, prompts are dynamically assembled and generated. By injecting the predefined interface specification as a constraint into the generated prompts, the large language model is guided to output code that conforms to the predefined interface specification. The generated prompts are input into a large language model to obtain generated code that conforms to the predefined interface specifications and the context information; The generated code is output as an embedded component suitable for embedding into the target platform.

[0007] According to a second aspect of the embodiments of this specification, an embedded component generation system is provided, comprising: An interface specification acquisition module is used to acquire a predefined interface specification of a target platform, wherein the target platform involves at least one extension point, the extension point is used to receive components embedded in the target platform, and the predefined interface specification describes the interface required by each of the at least one extension point. A context acquisition module is used to acquire context information, wherein the context information includes at least user intent information determined based on user input, and platform constraint information obtained based on the target platform and unrelated to the user input. The user intent information represents the functional requirements for the embedded component, and the platform constraint information represents the integration constraints imposed by the target platform on the embedded component. The prompt assembly module is used to dynamically assemble and generate prompts based on the predefined interface specification and the context information. By injecting the predefined interface specification as a constraint condition into the generated prompts, the large language model is guided to output code that conforms to the predefined interface specification. The code generation module is used to input the generation prompts into the large language model to obtain generated code that conforms to the predefined interface specification and the context information; The code output module is used to output the generated code as an embedded component suitable for embedding into the target platform.

[0008] According to a third aspect of the embodiments of this specification, an electronic device is provided, including a processor and a memory, wherein the memory stores computer program instructions, and the processor is configured to execute the computer program instructions stored in the memory to implement the method for generating an embedded component according to the first aspect of this specification.

[0009] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer program instructions thereon, which, when executed by a processor, implement the method for generating an embedded component according to the first aspect of this specification.

[0010] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including computer program instructions that, when executed by a processor, implement the method for generating an embedded component according to a first aspect of this specification.

[0011] This embodiment of the specification injects the predefined interface specifications of the target platform as constraints into the prompt text during the assembly stage of prompt generation. This ensures that the large language model is explicitly limited by the platform's technical contract when generating code, thereby outputting component code that is consistent with the target platform's specifications at the interface level. This eliminates the technical gap between the generated results and platform specifications in general AI code generation solutions. Since the platform interface specifications and the context information of the component to be generated are uniformly converted into prompt text that the large language model can parse, the process of manually reading and understanding the specification document and manually adapting the interface format is automated. This reduces compliance errors caused by human misunderstanding and improves the technical reliability of the component code meeting integration requirements on the first generation. Furthermore, since the conversion between predefined interface specifications and generated prompts can be achieved through general text assembly rules, this method does not depend on the specific implementation of a particular platform or large language model. It can adapt to the interface specification systems of different platforms and has good scalability. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of a system architecture provided in the embodiments of this specification.

[0013] Figure 2 This is a schematic diagram of the logical architecture of an intelligent annotation capability generation platform provided in the embodiments of this specification.

[0014] Figure 3 This is a general flowchart of a method for generating an embedded component provided in the embodiments of this specification.

[0015] Figure 4 This is a schematic diagram of a data structure for a predefined interface specification provided in the embodiments of this specification.

[0016] Figure 5 This is a schematic diagram illustrating the composition of context information provided in the embodiments of this specification.

[0017] Figure 6 This is a schematic diagram of a structure in which context information is organized according to independent context layers, as provided in the embodiments of this specification.

[0018] Figure 7 This is a schematic diagram of a dynamic assembly process for generating prompts, provided in an embodiment of this specification.

[0019] Figure 8 This is a schematic diagram of a large language model code generation and streaming finite state machine parsing process provided in the embodiments of this specification.

[0020] Figure 9 This is a schematic diagram of a component code output and rendering distribution process provided in the embodiments of this specification.

[0021] Figure 10 This is a schematic diagram of a finite state machine error recovery process provided in the embodiments of this specification.

[0022] Figure 11 This is a schematic diagram of an automatic verification and feedback iterative processing flow provided in the embodiments of this specification.

[0023] Figure 12 This is an application diagram of a data annotation template scenario provided in the embodiments of this specification.

[0024] Figure 13 This is a schematic diagram of the interface layout of a data annotation template provided in the embodiments of this specification on the target platform display page.

[0025] Figure 14 This is a schematic diagram of the module structure of an embedded component generation device provided in the embodiments of this specification.

[0026] Figure 15 This is a schematic diagram of the hardware structure of an electronic device provided in the embodiments of this specification. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments in this specification. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative effort are within the scope of protection of this specification.

[0028] As enterprises deepen their digital transformation, large organizations often run multiple business systems and data platforms. To flexibly integrate and display data across different business scenarios, these platforms typically provide embedded component frameworks, allowing third-party developers to embed custom functional components into the platform's standard pages for operation and interaction, according to predefined interface specifications. Before detailing specific implementation methods, this document will first provide a standardized explanation of the key terms and abbreviations used.

[0029] LLM (Large Language Model): refers to a neural network language model based on the Transformer architecture and pre-trained on a large-scale text corpus. It can generate coherent natural language text or program code in an autoregressive manner based on the input text prompts.

[0030] FSM (Finite State Machine): refers to an abstract computational model with a finite number of states. In this specification, it is used to perform real-time parsing of incremental text streamed from a large language model, and to identify the structural boundaries of predefined markup language tags through state transition rules.

[0031] AST (Abstract Syntax Tree): refers to the tree-structured representation of program source code, where each node corresponds to a syntactic structure unit in the source code. In this specification, it is used to verify the syntactic correctness of component code generated by a large language model.

[0032] Prompt: Refers to the natural language text instruction input to the large language model, used to guide the large language model to generate target content according to specified constraints and semantic requirements. In this specification, "generated prompt" specifically refers to structured prompt text that includes predefined interface specification constraints after dynamic assembly.

[0033] Embedded components refer to software functional units that can be embedded into the host environment of a target platform and perform data interaction, lifecycle management, or message processing according to the predefined interface specifications of the target platform. Unlike standalone applications, embedded components rely on the runtime environment provided by the host platform to operate.

[0034] Predefined interface specifications: These are technical agreement documents pre-defined and publicly disclosed by the target platform. They clearly define the technical contract between embedded components and the platform regarding data interaction formats, lifecycle callback function signatures, event communication protocols, and rendering entry methods. Adherence to these predefined interface specifications is a prerequisite for external components to be correctly recognized, loaded, and run by the target platform. In non-UI extension point scenarios, the rendering entry method is correspondingly replaced by interface definitions such as message serialization formats or data transmission protocols.

[0035] Contextual information: refers to the general term for various auxiliary information used to assist in the construction and generation of prompts during the process of generating embedded components, in addition to the natural language description directly input by the user. This includes, but is not limited to, user intent information, data feature information, layout structure information, and platform constraint information.

[0036] Dynamic assembly: refers to the process of generating prompt text in real time according to a preset assembly strategy based on the predefined interface specifications and various context information obtained each time an embedded component is generated, rather than using a fixed prompt template.

[0037] Extension point: refers to a predefined standardized logical slot in the target platform used to receive and accommodate embedded components. This slot can be represented as a display area in the user interface or as a logical node in the backend processing pipeline.

[0038] Figure 1 The system architecture to which this specification applies is illustrated. The system includes a user terminal 101, a target platform 102, an embedded component generation service 103, a large language model service 104, and a platform interface specification repository 105. The user terminal 101 serves as the carrier of human-computer interaction, receiving natural language function requirements input by the user and displaying a preview of the final generated embedded component. The target platform 102 is the host environment carrying business logic, and its user interface includes at least one standardized extension point for receiving external functional modules. The embedded component generation service 103 is the core processing node, deployed in a cloud or edge server cluster, responsible for coordinating interface specification acquisition, context information collection, and generation prompt assembly. The large language model service 104 provides low-level code reasoning capabilities, receiving processed prompts and returning component code. The platform interface specification repository 105 is used to persistently store historical interface definition files and metadata tags of the target platform, providing data support for the generation service in offline or network-isolated scenarios. All the above entities communicate securely through the enterprise's internal network.

[0039] It needs to be further explained that, Figure 1 This only illustrates the macroscopic interaction relationships of the top-level entities. In actual engineering deployments, the internal processing chain of the embedded component generation service 103 is much more complex. Figure 2 A more detailed schematic diagram of the service at the logical architecture level is shown below. Figure 2 As shown, the logical architecture is divided from top to bottom into an input and protocol layer, a generation layer, and an integration and output layer, supported by an underlying infrastructure layer. The input and protocol layer is responsible for receiving user queries and dataset metadata, and performing intent extraction and structure parsing through a query parser and a dataset information processor; this layer also has a built-in extension point protocol framework (e.g., covering...). Figure 13The standard slots in areas A to E (shown), interface specifications, and type safety systems provide strict contract boundaries for subsequent generation. The generation layer is the core computing unit, including an input processing module (further subdivided into a user query parser, dataset information processor, and metadata extractor), a layout prediction engine (containing a prediction algorithm model, dataset field analyzer, and layout structure generator, which calculates the optimal interface topology through formulas), an AI generation engine (integrating an LLM interface, a Prompt dynamic assembler, and a context injection mechanism), a context-aware module (containing a requirement context builder, data context processor, template context manager, and platform context integrator), a multi-context-aware system (adopting a file system-level RAG solution, providing precise retrieval interfaces such as get_config_template and get_component_template, as well as a document tag parser), and a streaming parser (with a built-in XML tag parser, state machine parsing engine, incremental accumulation, and error recovery mechanism). The integration and output layer is responsible for delivering the generated artifacts to the host environment. This includes a code verification and dependency analysis module (with a built-in AST analyzer, syntax checker, and dependency verification engine), an online build system (covering a cloud-based build pipeline, dependency installation manager, and code packaging toolchain), and a version control system (supporting integrated code review platforms, version branch management, and multi-round dialogue version trees). Finally, it completes interface rendering and previewing through the host environment integration and interaction mechanism (including platform front-end development framework integration, dynamic extension point registration mechanism, and resource loading and rendering engine). The infrastructure layer provides general runtime support such as the underlying framework, dependency management, storage, and network components. This four-layer architecture achieves fully automated workflow from requirement input to compliant output. Modules are decoupled through a standardized data bus, supporting independent evolution and elastic scaling. Data transmission between layers can be implemented using gRPC or message middleware; the specific protocol selection can be configured at the engineering level based on the cluster network topology and latency metrics.

[0040] The above architecture clarifies the functional boundaries and data flow of each participating entity. To illustrate the specific flow process of this method in the system, the generation steps of the embedded component will be elaborated below in conjunction with the overall flowchart. Figure 3 The overall flow of the embedded component generation method provided in this specification is illustrated. This method can be executed by the aforementioned embedded component generation service 103, and specifically includes the following steps.

[0041] Step 301: Obtain the predefined interface specifications of the target platform.

[0042] A predefined interface specification is a technical contract document pre-defined by the target platform to ensure that embedded components can be correctly identified, loaded, and run. This specification clearly defines the interface requirements between the embedded component and the target platform at the technical level, including data interaction formats, lifecycle callback function signatures, event communication protocols, and rendering entry methods. Specifically, the target platform's user interface contains at least one extension point, each corresponding to a standardized area or function slot in the interface. The predefined interface specification describes the interfaces required by each extension point, including the names, types, and formats of the data fields received by the extension point, the function signatures of the lifecycle callback methods to be implemented by the extension point, and the rendering output formats supported by the extension point.

[0043] It should be further clarified that the predefined interface specifications described in this specification can be understood as an extension point protocol mechanism. In actual engineering deployments, the front-end architecture of the target platform often adopts a modular or micro-frontend design, and its interface topology and the number of extension point slots are not fixed. To adapt to such dynamic evolution environments, this specification does not limit the interface specifications to a specific number of physical areas, but rather abstracts them into a set of technical contracts describing the data interaction boundaries between extension points and external components. For example, the predefined interface specifications can be carried in a structured metadata file (e.g., a platform-customized JSON protocol description file or a YAML contract file). Before the system executes the component generation task, the contract parsing engine reads and traverses the metadata file, extracts the declared extension point identifiers, and maps them one by one to the corresponding data field structure definitions, lifecycle hook function signatures, and event communication routing rules. After parsing, the system loads these discrete technical constraints into the contract object model in memory for direct use by the subsequent prompt word assembly and code verification modules. This metadata-driven contract extraction mechanism enables the generation service to adaptively identify extension points with arbitrary layouts, without requiring modification of the underlying adaptation logic due to platform front-end architecture upgrades or business area reorganizations.

[0044] In one specific implementation, the predefined interface specifications can be obtained by calling the online query interface provided by the target platform. Figure 4 A schematic diagram of the data structure of the predefined interface specification is shown. The embedded component generation service 103 initiates an interface query request to the target platform 102. The platform returns a structured response containing an extension point identifier 401, data interface field definitions 402, lifecycle callback function signatures 403, event communication protocol definitions 404, and rendering entry format specifications 405. The system parses this response body and converts it into an internally operable object model. This real-time retrieval method ensures that the generated component code remains strictly consistent with the current running version of the target platform, avoiding interface incompatibility issues caused by version iterations.

[0045] In another embodiment, considering the strict network isolation policies in some enterprise intranet environments, the target platform may not expose online query interfaces. In this case, predefined interface specifications can be obtained from a pre-deployed platform interface specification repository 105. This repository stores configuration files that are periodically synchronized by the platform administrator; the file format can be JSON, YAML, or XML. The embedded component generation service 103 loads the latest specification files from the repository during the initialization phase or according to a preset scheduled task cycle and maintains their version status in a local cache. When the local cache expires or a version update notification is received, the service will re-fetch the files and refresh the internal data structure. This method can still provide a stable supply of specifications in offline or weak network environments, ensuring the continuity of generation tasks.

[0046] It's important to note that the target platform doesn't necessarily have a graphical user interface. In a typical application scenario, the target platform acts as a message processing pipeline for a microservice cluster, with its extension points being predefined logical slots on this pipeline—such as message filtering nodes, data transformation nodes, or audit log interception nodes. In this scenario, the predefined interface specification doesn't describe the rendering format of UI controls, but rather the message input / output protocol required by the extension point. Specifically, the interface specification can define the message body structure received by the extension point (such as a binary payload conforming to a specific Protobuf Schema), the response body format that the extension point must return after processing (such as an Avro record containing specific fields), and the metadata transmission specifications that the extension point must follow during processing (such as the requirement to transparently transmit the TraceId and SpanId fields in the message header). Figure 4The data structure shown remains applicable in this scenario: the extension point identifier 401 corresponds to the logical slot name on the pipeline (e.g., "filter-node-03"), the data interface field definition 402 corresponds to the field schema definition of input and output messages, the lifecycle callback function signature 403 corresponds to the pipeline's initialization and destruction callbacks—e.g., "call onInit(config) when the pipeline starts" and "call onDestroy() when the pipeline closes"—the event communication protocol definition 404 corresponds to the asynchronous communication specification between the extension point and the pipeline—e.g., exception events must be reported and handled through a specified Message Queue Topic—and the rendering entry format specification 405 can be replaced with the serialization format specification of the extension point's return result in this pure backend scenario—e.g., the return result must be a JSON serialized string and must contain three top-level fields: statusCode, body, and errorMessage. As can be seen from this definition, the "extension point" described in this solution is a technical abstraction. As long as the target platform defines the interface specifications that the component must adhere to when accessing it, regardless of whether the access point is ultimately reflected in the user interface or the backend processing pipeline, it falls within the protection framework of this solution. This generalization ensures that the solution is applicable to platforms with different technology stacks.

[0047] After obtaining the interface specifications, the system has the underlying contractual constraints for generating code. However, technical contracts alone are insufficient for a large language model to understand specific business requirements and operating environments; the model may still generate structurally compliant code that deviates from expected functionality. Therefore, it is necessary to further introduce multi-dimensional business and environmental information as a basis for decision-making.

[0048] Step 302: Obtain the context information associated with the component to be generated.

[0049] Contextual information refers to all auxiliary information used to assist in constructing and generating prompts, excluding the natural language function descriptions directly input by the user. This information describes the technical environment and business scenario of the component to be generated from different dimensions, providing the large language model with multi-dimensional and complete information required for generation decisions. Contextual information includes at least user intent information determined based on user input, and platform constraint information unrelated to user input and obtained based on the target platform. Figure 5 A schematic diagram illustrating the composition of contextual information is shown.

[0050] User intent information represents the functional requirements of a component, and is a natural language description directly input by the user through user terminal 101. In actual interaction, the embedded component generation service 103 provides a dual-modal input interface of natural language input box and structured form. Users can directly enter free text of functional requirements, and the system extracts core functional keywords through a built-in lightweight intent classification model. If the user selects the structured form, the system automatically concatenates the selected component type, interaction mode, required fields, and other options into a standardized intent description statement, thereby reducing the uncertainty of natural language input and improving the accuracy of subsequent prompt assembly.

[0051] Platform constraint information represents the integration restrictions imposed by the target platform on embedded components. This information is unrelated to the user's specific input but is objectively determined by the target platform's technical architecture and operating environment. Given that enterprise-level target platforms typically have a large number of independent constraint documents, a full traversal would lead to severe processing delays. This embodiment introduces a precise retrieval architecture based on tag indexing for this scenario. Under this architecture, the target platform can be associated with multiple constraint documents. Obtaining the platform constraint information can include: acquiring the metadata tags of each constraint document; building an index based on the metadata tags; receiving retrieval requests carrying tag information through a retrieval interface; performing tag matching in the index to select constraint documents relevant to the current task from the multiple constraint documents; and extracting platform constraint information from the selected constraint documents. Through this mechanism, the system can complete constraint filtering with extremely low time complexity. Specifically, metadata tags are pre-labeled classification identifiers for each constraint document. During service initialization, the system traverses all associated documents, extracts header tags, and builds an inverted index. When the assembly module initiates a retrieval request based on task characteristics, the indexing module directly performs precise matching in the inverted structure, quickly locking in highly relevant documents and extracting applicable clauses. This design optimizes document queries from linear scanning to hash-level lookups, significantly improving the response speed of context assembly.

[0052] The file system-level index built based on document metadata tags can be implemented using a multi-context-aware system. This system abandons semantic similarity retrieval based on vector embedding, instead employing a retrieval strategy that parses platform document tag metadata to build a precise index, and returns complete document fragments through tag matching. It should be noted that "multi-context-aware system" or "file system-level RAG" are merely engineering architecture names for this retrieval mechanism; its technical essence remains a file system-level index construction and retrieval method based on tag matching. This application does not limit the index storage medium; relational database tables, inverted index files, or in-memory hash tables can all be used as equivalent implementations.

[0053] To address the issues of differing naming conventions and the misuse of synonyms when tagging constraint documents by different business teams, a single exact match channel might miss some detections in certain edge scenarios. Therefore, the system further incorporates fuzzy semantic matching capabilities. In actual deployment, the aforementioned retrieval interface can include both exact match and fuzzy match interfaces. When the tag information matches the metadata tag, an exact match can be performed through the exact match interface; when the tag information is semantically related to the metadata tag but inconsistent in expression, a fuzzy match can be performed through the fuzzy match interface. This dual-channel strategy ensures rapid return of core constraints and effective recall of edge semantic terms.

[0054] After clarifying the integration boundaries of the technology platform, the generation process also needs to define the specific structure of the data to be processed; otherwise, the model cannot generate the correct data binding and validation logic. Addressing the common pain point of unknown data source structures, this embodiment supplements key context through automated parsing. Specifically, this context information may also include data feature information, which can be obtained by parsing the structured field information of the dataset associated with the component. This information indicates the field type and semantics of the data that the component needs to process. The embedded component generation service 103 can directly extract attributes such as field name, data type, length limit, enumeration value range, and required status through the platform metadata interface or uploaded sample files. The system will perform semantic inference based on field naming conventions; for example, it will automatically map fields containing monetary semantics to input controls with thousands separator formatting, and class semantic fields to dropdown selectors. These structured data features, as a strong type hint injection model, effectively avoid common type conflict errors in data reading and format conversion stages after code generation.

[0055] The parsing of data structures provides a content carrier for components, but the spatial arrangement of components in the user interface of the target platform still relies on further automated decisions. If the layout is entirely left to the free design of a large language model, the randomness of the model can easily lead to overlapping elements or unbalanced white space on different screen sizes. Therefore, after acquiring data features, the system introduces a deterministic layout engine. The core logic of this engine is that the context information can also include layout structure information. This layout structure information can be obtained by analyzing the task semantic description and structured field information indicated by the user intent information through a layout prediction algorithm. This information is used to indicate the spatial arrangement of at least one expansion point and the correspondence between each field and each expansion point. Figure 7In the dynamic assembly process of the generated prompts shown, layout prediction runs as an independent preprocessing step. Its internal execution mechanism strictly follows a process that analyzes the task semantic description and structured field information through a layout prediction algorithm to obtain layout structure information. This process includes: identifying field types and performing semantic analysis on the structured field information to determine the data type and semantic role of each field; calculating the matching degree between each field and each expansion point based on the task type and the data type and semantic role of each field; and determining the layout structure information based on the matching degree and preset spatial constraints. The algorithm first assigns a semantic role label to each field, then calculates the adaptation weight between the field and each expansion point slot using the platform's predefined interface template library. After the weight calculation is completed, the algorithm applies spatial constraint rules for topological sorting, ultimately outputting a layout structure that includes activation status, arrangement order, and binding list. This mechanism transforms interface design from relying on human experience to rule-driven automated calculation, significantly reducing the computational burden and uncertainty of the model in spatial logical reasoning. The specific weight coefficients for the matching degree calculation can be obtained through supervised learning fine-tuning of historical platform layout logs to adapt to the visual preferences of different business lines.

[0056] At this point, the system has collected four key types of information: intent, constraints, data characteristics, and layout structure. In actual operation, this information is often maintained independently by different microservice modules, and their update frequencies vary significantly. User intent changes in real time with each interaction, platform constraints update slowly with version iterations, and data characteristics change with dataset switching. Coupled with these four types of information in the same data object, it is highly likely to cause state overwriting or cache consistency issues. To completely decouple high-frequency changing data from low-frequency static data, this embodiment implements a layered isolation design at the architectural level. That is, user intent information, data characteristic information, layout structure information, and platform constraint information can belong to four independent context layers, and the data acquisition and updates of each context layer can be independent of each other. Figure 6As shown, four types of information are clearly divided into the user intent layer 601, platform constraint layer 602, data feature layer 603, and layout structure layer 604. Each layer is equipped with independent memory space, cache eviction policy, and invalidation callback mechanism. In specific engineering implementations, these four layers can also be represented as the requirement layer, data layer, template layer, and platform layer. Specifically, the user intent layer 601 corresponds to the requirement layer and is used to carry functional requirement descriptions; the platform constraint layer 602 corresponds to the platform layer and is used to carry interface specifications and component whitelists; the data feature layer 603 corresponds to the data layer and is used to carry data structure parsing results; and the layout structure layer 604 corresponds to the template layer and is used to carry interface skeleton prediction results. Each layer independently acquires and injects generation prompts in parallel to avoid semantic cross-interference. During the prompt assembly stage, the module only concurrently pulls the latest snapshot from each independent layer for assembly according to the actual needs of the current request. This architecture ensures that changes in information in any dimension only trigger partial refreshes, without blocking or polluting the overall generation pipeline, thus providing excellent throughput and fault tolerance resilience in high-concurrency call scenarios.

[0057] As can be seen, although there are significant differences in the specific content of the interface specifications between UI extension points and non-UI extension points (the former defines rendering function signatures and control binding rules, while the latter defines message schemas and transmission protocols), they share the exact same sequence of steps and architectural design at the overall logical level of the embedded component generation method. The prompt assembly module does not need to switch internal logic branches when handling these two types of scenarios; the difference only lies in the specific text content of the generated prompts—for UI scenarios, the prompts include constraint descriptions such as "rendering entry format" and "control binding relationships"; for non-UI scenarios, the prompts include constraint descriptions such as "message body schema" and "transmission protocol requirements." This scenario-independent method design is a key technical advantage that distinguishes this solution from existing code generation tools that are only customized for a single type of platform.

[0058] After completing the collection and hierarchical decoupling of multi-dimensional contextual information, the system possesses all the data elements to support high-quality code reasoning for large language models. At this point, it is necessary to transform the heterogeneous structured data and platform contracts into natural language instruction sequences that the model can understand, thus entering the prompt text construction phase.

[0059] Step 303: Dynamically assemble and generate prompts based on predefined interface specifications and context information.

[0060] During the dynamic assembly and generation of prompts, the assembly strategy adopted by the prompt assembly module can be selected based on the complexity of the predefined interface specifications and the richness of the context information. In one specific implementation, the system adopts a constraint injection strategy based on template partitioning. Under this strategy, the prompt assembly module maintains a basic prompt skeleton template, which includes multiple logical blocks such as a functional target description area, an interface specification constraint area, a data feature description area, and a platform restriction declaration area. During assembly, the system directly fills the interface specification constraint area with the content text of the predefined interface specifications obtained in step 301, fills the functional target description area with the user intent information obtained in step 302, fills the data feature description area with the data feature information, and fills the platform constraint declaration area with the platform constraint information. The information in each block is logically isolated by predefined separators, and the final generated prompt is a natural language instruction text with clearly defined blocks and directly readable constraints. The advantage of this strategy lies in its reasoning friendliness—the large language model can directly retrieve constraint paragraphs associated with explicit keywords such as interface format requirements and data field constraints in the prompt text, generating code that conforms to the specifications without multi-hop reasoning.

[0061] In another different embodiment, the system employs a semantic reconstruction-based instruction conversion strategy. Under this strategy, the prompt assembly module does not simply insert the original interface specification text as an independent block into the prompt template. Instead, it first performs semantic parsing on the text content of the predefined interface specification, extracting the technical constraint elements—including the function signatures that must be implemented, the parameter passing protocols that must be followed, and the return value formats that must be compatible—and then transforms these constraint elements into a series of specific behavioral instructions, which are then embedded into the statements describing the function. For example, instead of simply pasting the original description in a predefined interface specification that "components must export a function named onReceive, which takes a parameter object with payload and metadata properties and returns a response object with status and result properties," the system will transform it into an instruction: "Define an exported function onReceive in the generated component code that takes a parameter object with payload and metadata properties as input and ensures that the function returns a response object with status and result properties as the standard response format for each message delivery." This strategy transforms the declarative description of the interface specification into a behavioral instruction for the model, making the generated prompts read like a specific programming task assigned to a developer. This is particularly suitable for scenarios where the interface specification contains a large number of conditional, selective, or combinatory clauses—semantic refactoring can directly embed such conditional logic into the step description of the task, inducing the model to generate code that fully covers all branch conditions.

[0062] The two assembly strategies mentioned above are not mutually exclusive. The prompt assembly module can be applied separately to different parts of the same generated prompt, or it can be automatically selected or combined based on the textual features of the predefined interface specification and the inference characteristics of the current large language model. For example, for simple and clear enumeration constraints in the interface specification (such as "allowed status codes include only 200, 400, and 500"), template partitioning injection can achieve stable results; while for interactive logic constraints involving multi-field collaborative processing (such as "when there are multiple related fields in the input data, the model needs to first select and extract the required fields, and then consume these selected fields in sequence to generate a response"), the semantic reconstruction strategy can better guide the model to accurately realize the sequential processing and consumption of multiple fields. This optional assembly mechanism upgrades the prompt generation process from passively copying the original interface specification text to actively adapting and transforming it according to the structural characteristics of the specification content. Without changing the external interface form in step 303, it improves the consistency of code generation and specification compliance accuracy of interface specifications of different complexities on various large language models.

[0063] After generating the basic prompt text through the above assembly process, the engineering constraints of the large language model's context window length must also be considered. When the total length of the four types of context information and interface specifications exceeds the model's optimal inference threshold, the prompt assembly module initiates a priority sorting mechanism. Platform constraint information and predefined interface specifications, as an unalterable technical foundation, are always retained in their complete form; user intent information undergoes keyword extraction and core semantic condensation; data feature information and layout structure information are extracted using a summary injection method, retaining only the field name list, type identifier, and extension point mapping topology, omitting redundant business descriptions and historical examples. This flexible assembly mechanism effectively controls the token consumption of the prompt text while ensuring that core constraints are not lost, reducing call latency and generation costs.

[0064] Generating prompts is the core control instruction driving the autoregressive inference of a large language model, and its content quality directly determines the standard compliance and functional completeness of the output code. Dynamic assembly refers to abandoning the traditional static splicing mode of fixed templates and calculating and combining the optimal prompt text in real time based on the interface specification version, context information snapshot, and model capability characteristics obtained for the current task. In a specific implementation, the prompt assembly module maintains basic prompt skeletons for different task types. The system first converts the predefined interface specification obtained in step 301 into a strongly constrained instruction segment, explicitly listing the number of extension points, data interface field signatures, lifecycle callback method definitions, and rendering output format requirements. Subsequently, the system injects the four layers of context information obtained in step 302 into the business description paragraph of the prompt skeleton in sequence. For example, user intent information is transformed into functional goal statements, platform constraint information into a list of disabled functions and runtime environment declarations, data characteristic information into input / output data structure examples, and layout structure information into a description of the logical configuration relationships of each extension point. In UI extension point scenarios, the logical configuration relationships are reflected in spatial arrangement coordinates and field binding relationships; in non-UI extension point scenarios, the logical configuration relationships are reflected in the topological order and data flow mapping relationships on the message processing chain. Each information segment is logically isolated using predefined delimiters, ultimately generating a complete prompt text that is clearly structured, well-constrained, and semantically coherent.

[0065] In another embodiment, considering the engineering reality that the context window length of a large language model has an upper limit, the system adopts a dynamic compression and on-demand injection strategy. When the total length of the four types of context information and interface specifications exceeds the optimal inference threshold of the model, the prompt assembly module will initiate a priority sorting mechanism. Platform constraint information and predefined interface specifications, as an unalterable technical foundation, are always retained in their complete form. User intent information undergoes keyword extraction and core semantic condensation. Data feature information and layout structure information are injected using a summary method, retaining only the field name list, type identifier, and extension point mapping topology, omitting redundant business descriptions and historical examples. This flexible assembly mechanism effectively controls the token consumption of prompt text while ensuring that core constraints are not lost, reducing call latency and generation costs.

[0066] In summary, by injecting predefined interface specifications as constraints into the generation prompts, these prompts can guide large language models to output code that conforms to the predefined interface specifications, thereby eliminating the anomaly of incompatibility between the generated results and platform specifications in general AI code generation schemes.

[0067] Once the prompt text is assembled, the system sends it to the large language model service for code reasoning, entering the generation and real-time parsing stage.

[0068] Step 304: Input the generated prompts into the large language model to obtain generated code that conforms to the predefined interface specifications and context information.

[0069] After receiving the generation hints, the large language model service 104 predicts and outputs the target component code token by token based on an autoregressive decoding mechanism. Because the hints are rigorously injected with predefined interface specifications, contractual constraints, and multi-dimensional contextual information, the model's generation decision space is effectively limited to a subset of code that conforms to the platform architecture. Specifically, when generating code, the model automatically follows the function export signatures, parameter passing protocols, lifecycle callback mount points, and rendering return formats declared in the hints. Compared to unconstrained general code generation, the code output by this method can be directly recognized by the target platform's component loader without requiring manual secondary adaptation. Figure 8 The process flow of large language model code generation and streaming finite state machine parsing is illustrated. After receiving a request, the large language model service 104 immediately starts the inference engine and returns the generated code snippets segment by segment to the embedded component generation service 103 in the form of a data stream.

[0070] As the complexity of code generation tasks increases, users' demand for real-time feedback on code generation is growing stronger. The traditional model of waiting for the complete output of the model before returning the result all at once results in a long delay of the first byte, and the user interface remains blank during the generation process, resulting in a poor user experience. To balance low-latency response and interface structure integrity, this embodiment modifies the output link into a streaming manner. The core mechanism of the modification is that the large language model can output generated code in a streaming manner. This method may also include: using a finite state machine to parse the incremental text of the streaming output in real time, so as to gradually identify predefined markup language tags in the incremental text during the streaming output process. Streaming transmission breaks down the complete generation task into continuously arriving text blocks, significantly reducing user waiting time. Specifically, the predefined markup language tags can be implemented using XML tag format, for example... <itagartifact>Used to wrap all code blocks <itagaction>Used to wrap a single block of code. A finite state machine completes state transitions and error recovery by recognizing the start symbol, content body, and closure symbol of such tags. This application does not limit the specific syntax standard of the markup language; JSON streams, YAML streams, custom binary tags, or plain text blocks with special delimiters can all be used as alternative implementations of predefined structured tags, as long as they possess boundary characteristics and type identifiers that can be recognized by the state machine.

[0071] In some cases, incremental text may arrive as fragmented pieces with incomplete structures. Direct rendering could result in broken tags or unclosed scripts appearing on the interface. To address this, the system introduces a real-time parsing mechanism based on a finite state machine. This state machine maintains a tag stack and the current parsing state in memory, performing strict state transitions character by character as the streaming text is processed. When a start tag is detected, it is pushed onto the stack; when an end tag is detected, it is compared with the top element of the stack. If a match is found, the top element is popped from the stack, and the complete tag pair and its internal text are passed upwards as an independent parsing unit. Figure 8 The data flow path is shown in detail, ensuring users can see a correctly structured partial preview early in the generation process. The specific state transition matrix of the state machine can be pre-compiled according to the syntax specification of the target markup language to maximize parsing throughput.

[0072] After the streaming parser completes tag boundary identification, the system faces the challenge of mapping the parsing results to the host interface in real time. If all parsing units are stacked in a single panel, users will find it difficult to intuitively verify whether the extended point mapping meets business expectations. Therefore, after the parser identifies a complete tag unit, the system further executes a split-rendering logic. Specifically, the execution strategy involves distributing the parsed content to the corresponding rendering area for real-time visualization rendering based on the type of the identified predefined markup language tag. For example... Figure 9 As shown, the finite state machine parser 901 passes the extracted parsing unit and its carried tag type identifier to the rendering dispatcher 902. The dispatcher 902 internally maintains a static mapping table between tag types and platform rendering areas. When the parser identifies a tag corresponding to the main content display area, the dispatcher routes the code snippet to the main rendering panel 903; when it identifies a tag in the tag selection area, it routes it to the independent panel 904. This mechanism of rendering based on extension point type allows users to see a preview of the partitioned layout that matches the final page layout during the code generation process. Even if the model is still generating subsequent interaction scripts, the already reached interface structure code can be rendered independently in the corresponding area, greatly enhancing the transparency and controllability of the generation chain.

[0073] Although finite state machines can parse standard tags using deterministic rules, large language models may still output non-standard text such as unclosed tags and disordered nesting due to probabilistic randomness or network truncation during autoregressive sampling. If the state machine directly interrupts parsing, it will cause the entire streaming rendering chain to collapse, severely impacting high-availability delivery. To endow the system with self-healing capabilities, this embodiment incorporates fault-tolerant recovery logic into the parser. Its core design is that the finite state machine can contain at least one error state and a corresponding error recovery path; during real-time parsing, when a tag mismatch or format error is detected in a predefined markup language tag, the finite state machine can enter the error state and perform state rollback, tag completion, or skip operations along the error recovery path. Figure 10 As shown, when the state machine triggers an exception detection condition, it immediately switches from the normal parsing state 1001 to the error state 1003, and processes the exception according to its type. If it's a tag mismatch, state rollback 1004 is executed, which involves validating the abnormal text and feeding the validation result back to the large language model to trigger it to regenerate the code. If the stream is unexpectedly interrupted, causing the stack to be non-empty, tag completion 1005 is executed, automatically reversing the order to generate closed tags to repair incomplete units. If it's a non-fatal format defect, skip operation 1006 is executed, resetting the context and continuing to parse subsequent normal text. The parallel existence of these three recovery paths ensures the continuity of the parsing chain in most abnormal scenarios.

[0074] The introduction of streaming parsing and rendering distribution mechanisms transforms the code generation process from a black-box waiting environment into a transparent and interactive pipeline. After obtaining the initial generated code output, the system still needs to rigorously control its quality before it can proceed to the final output stage. Figure 11 The process flow of automatic verification and feedback iteration is illustrated. After obtaining the generated code, the code verification module 1101 immediately performs abstract syntax tree construction and static rule scanning. If the verification passes, it directly proceeds to the output stage. If the verification fails, the feedback iteration module 1104 organizes the specific error locations, missing callback signatures, or illegal dependency references into structured correction instructions, appends them to the original prompt to form a correction generation prompt 1105, and re-enters it into the large language model. This closed loop can set a maximum retry threshold to ensure that the delivered code meets enterprise-level quality access control standards. The automatic verification rule set can be updated periodically based on platform security specifications and front-end performance baselines. The verification engine supports dual-track verification of static scanning and dynamic sandbox execution to improve interception accuracy.

[0075] The aforementioned automated verification process based on abstract syntax trees can be implemented in a specific runtime environment by calling toolchains such as the BabelAST analyzer, syntax checker, and dependency verification engine. The specific tool names, such as Babel, are merely illustrative examples of abstract syntax tree parsing technology and do not limit the verification algorithm used. Those skilled in the art can replace the corresponding AST parsing kernel according to the target language ecosystem (such as JavaParser for Java, the ast module for Python, and syn crate for Rust).

[0076] After completing streaming parsing, quality verification, and possible iterative corrections, the system obtains a code version that is structurally complete, highly compliant with specifications, and free of syntax errors. At this point, the output needs to be finalized and standardized to enable direct deployment to the host environment.

[0077] Step 305: Output the generated code as an embedded component suitable for embedding into the target platform.

[0078] The code output module performs deep cleaning and formatting on the raw text stream returned by the large language model, stripping away auxiliary descriptions, annotation markers, or control characters left over from streaming, extracting pure component source code. To adapt to the integration protocols of different target platforms, the output module supports multiple encapsulation forms. In one specific implementation, the generated code is packaged into an independent application programming interface (API) library module. This module strictly adheres to the export specifications required by the target platform, exposing standardized initialization entry functions. The platform can dynamically load this module to mount component instances at specified extension points. In another different implementation, considering that some platforms use declarative configuration management, the generated code is organized into a composite configuration object containing interface templates, style rules, interaction logic, and metadata information. After reading this configuration object, the target platform's built-in rendering engine directly consumes its structural description, without requiring additional code compilation steps on the client side. This multi-format compatible output strategy significantly improves the portability and plug-and-play characteristics of the generated components across different technology stack platforms. The specific encapsulation format can be dynamically determined by the target platform version identifier or user-preset deployment preference parameters.

[0079] The descriptions of the above steps have demonstrated the applicability of this solution to different types of extension points through two dimensions of embodiments: the message processing pipeline implementation in non-UI extension point scenarios (see the corresponding paragraphs in steps 301 to 303) and the interface layout implementation in UI extension point scenarios (see the layout prediction algorithm description in step 302). The following uses a high-value vertical field like a data annotation platform as an example to further illustrate the end-to-end ergonomic performance of this solution in complex UI extension point scenarios. Taking a data annotation platform as an example, the embedded component in this specification can be a data annotation template. The aforementioned at least one extension point can correspond to at least one annotation area in the data annotation template, which can be used to receive user input for annotation of the corresponding data field; user intent information can include the data field to be annotated and the annotation type. In this typical scenario, the user inputs a text sentiment classification annotation template through user terminal 101. The field to be annotated is the dialogue content, and the annotation type is the intent information of a three-category sentiment label. Based on this intent, combined with predefined interface specifications and dataset features, the system automatically completes layout prediction and constraint retrieval. After the large language model generates code, it is streamed, rendered, and distributed, and the target platform 102 interface presents a clearly structured annotation workbench in real time. Figure 12 The overall interaction chain for this typical application scenario is shown. For example... Figure 12 As shown, user terminal 1201 sends the annotation requirement to embedded component generation service 1202. After the service completes code generation and verification, it sends the annotation template to the target platform annotation workbench 1203. The workbench automatically parses the template structure and dynamically divides the interface into multiple functional blocks: the main content display area 1204 renders the raw data items to be annotated; the label selection area 1205 provides interactive controls matching the task type for users to perform annotation operations; and the operation control area 1206 contains submit and skip buttons to trigger the data feedback process. The entire chain achieves a seamless connection from natural language description to a runnable annotation interface, allowing users to directly engage in production work without writing any front-end code. Figure 13 The diagram further illustrates the interface layout of the aforementioned data annotation template on the target platform's display page. For example... Figure 13 As shown, this template interface strictly follows the extension point protocol (i.e., predefined interface specifications) and is divided into five functional areas. Area A is the data display area, located on the left side of the interface, corresponding to the platform's predefined main content display extension point, responsible for real-time rendering of the original dialogue text to be labeled. Area B is the labeling operation area, located in the center of the interface, corresponding to the interactive selection extension point, dynamically generating clickable label buttons that match the sentiment classification task, used to receive user labeling input. Area C is the labeling result preview area, corresponding to the auxiliary preview extension point, real-time mapping and highlighting the currently selected sentiment label value. Area D is the operation control area, located at the bottom of the interface, providing submit and skip controls to trigger the platform's data feedback process. Area E is the metadata display area, corresponding to the top information extension point, displaying the data number and task progress. It should be noted that this interface layout is not manually coded by front-end engineers, but is entirely automatically calculated and generated by the layout prediction algorithm of this specification embodiment based on field semantics and spatial constraints, and dynamically projected into each extension point slot through a streaming rendering mechanism. The delivery cycle from intent description to usable template has been shortened from the traditional weeks to minutes, completely solving the industry pain points of delayed response to long-tail annotation requirements and high custom development costs.

[0080] Corresponding to the method embodiments, this specification also provides an apparatus for generating embedded components. This apparatus can serve as a logical function mapping of the core execution entity in the aforementioned method flow and can be deployed in a cloud server cluster or edge computing node. Figure 14 A schematic diagram of the module structure of the generation device is shown.

[0081] like Figure 14 As shown, the generation device 1400 includes: an interface specification acquisition unit 1401, used to acquire a predefined interface specification of a target platform, the target platform involving at least one extension point, the extension point being used to receive components embedded in the target platform, and the predefined interface specification describing the interface required by each of the at least one extension point.

[0082] The context acquisition unit 1402 is used to acquire context information, which includes at least user intent information determined based on user input, and platform constraint information obtained based on the target platform and independent of the user input. The user intent information represents the functional requirements for the embedded component, and the platform constraint information represents the integration constraints imposed by the target platform on the embedded component.

[0083] The prompt assembly unit 1403 is used to dynamically assemble and generate prompts based on the predefined interface specification and the context information. By injecting the predefined interface specification as a constraint condition into the generated prompts, the large language model is guided to output code that conforms to the predefined interface specification.

[0084] The code generation unit 1404 is used to input the generation prompts into the large language model to obtain generated code that conforms to the predefined interface specification and the context information.

[0085] The code output unit 1405 is used to output the generated code as an embedded component suitable for embedding into the target platform.

[0086] Optionally, the context information also includes data feature information, which is obtained by parsing the structured field information of the dataset associated with the embedded component, and is used to indicate the field type and field semantics of the data that the embedded component needs to process.

[0087] Optionally, the extension point corresponds to the display area in the user interface of the target platform; the context information also includes layout structure information, which is obtained by analyzing the task semantic description indicated by the user intent information and the structured field information through a layout prediction algorithm, and is used to indicate the spatial arrangement of the at least one extension point and the correspondence between each field and each extension point.

[0088] Optionally, the user intent information, the data feature information, the layout structure information, and the platform constraint information belong to four independent context layers, and the data acquisition and updating of each context layer are independent of each other.

[0089] Optionally, the step of analyzing the task semantic description and the structured field information using a layout prediction algorithm to obtain the layout structure information includes: The structured field information is subjected to field type identification and field semantic analysis to determine the data type and semantic role of each field; Based on the task type and the data type and semantic role of each field, calculate the matching degree between each field and each extension point; The layout structure information is determined based on the matching degree and the preset spatial constraints.

[0090] Optionally, the target platform is associated with multiple constraint documents, and the acquisition of the platform constraint information includes: Obtain the metadata tags of each of the multiple constraint documents; An index is constructed based on the aforementioned metadata tags; The system receives retrieval requests carrying tag information through a retrieval interface, performs tag matching in the index, and selects constraint documents related to the current generation task from the plurality of constraint documents. Extract the platform constraint information from the selected constraint document.

[0091] Optionally, the retrieval interface includes an exact matching interface and a fuzzy matching interface; wherein, performing tag matching in the index includes: When the tag information matches the metadata tag, a precise match is performed through the precise match interface; When the tag information is semantically related to the metadata tag but the expression is inconsistent, fuzzy matching is performed through the fuzzy matching interface.

[0092] Optionally, the generation device 1400 further includes a streaming parsing unit 1406, which is used to parse the incremental text of the streaming output in real time through a finite state machine when the large language model outputs the generated code in a streaming manner, so as to gradually identify predefined markup language tags.

[0093] Optionally, the device also includes a rendering distribution unit 1407, which distributes the parsed content to the corresponding rendering area for real-time visualization rendering based on the identified tag type.

[0094] Optionally, the device also includes a template adaptation unit 1408 for adjusting the description information of the extension points in the generated prompts based on the structured field information of the dataset.

[0095] Optionally, the finite state machine includes at least one error state and a corresponding error recovery path; During the real-time parsing process, when a mismatch or format error is detected in the predefined markup language tags, the finite state machine enters the error state and performs state rollback, tag completion, or skip operations along the error recovery path.

[0096] Optionally, the device also includes a code verification unit 1409, which is used to automatically verify the generated code and feed back the verification result to the large language model to trigger iterative regeneration when the verification fails.

[0097] Optionally, the embedded component is a data annotation template; The at least one extension point corresponds to at least one annotation area in the data annotation template, and the annotation area is used to receive user annotation input for the corresponding data field; The user intent information includes the data fields to be labeled and the labeling type.

[0098] It should be noted that the specific functional implementation, data interaction logic, and technical effects of each unit in the generation device 1400 provided in this embodiment are highly consistent with the descriptions in the foregoing method embodiments, and will not be repeated here. Those skilled in the art will understand that the aforementioned units can be software functional modules running on a processor, fixed hardware logic circuits, or a hardware-software collaborative implementation. The division is merely for the purpose of clearly describing the technical solutions in this specification and does not constitute a limitation on the actual physical architecture.

[0099] Corresponding to the above-described methods and apparatus embodiments, this specification also provides an electronic device. This electronic device can serve as a physical carrier for carrying the aforementioned embedded component generation service. Figure 15 A schematic diagram of the hardware structure of the electronic device is shown.

[0100] like Figure 15 As shown, the electronic device 1500 includes at least one processor 1501 and a memory 1502 communicatively connected to the at least one processor 1501. The memory 1502 stores computer program instructions executable by the at least one processor 1501, which, when executed by the processor, enable the processor to perform the embedded component generation method described in any of the foregoing embodiments.

[0101] The processor 1501 can be a central processing unit, a graphics processing unit, a dedicated neural network processor, or a general-purpose microcontroller unit with complex logic operation capabilities. The memory 1502 can include volatile random access memory and non-volatile solid-state storage media for persistently storing interface specification files, context caches, large language model interaction logs, and generated component code artifacts. Optionally, the electronic device also includes a communication interface 1503 for low-latency data interaction with the target platform, user terminals, and large language model service via an enterprise intranet or encrypted tunnel. Optionally, the device also includes an input / output interface 1504 for receiving configuration commands from the local administrator or displaying a system operation monitoring panel. This electronic device can be deployed independently as a high-performance computing server or as an elastic computing node in a distributed microservice cluster, horizontally scaling according to actual business throughput.

[0102] Corresponding to the above embodiments, this specification also provides a computer-readable storage medium. This medium stores computer program instructions, which, when executed by a processor, implement the embedded component generation method described in any of the above embodiments. The computer-readable storage medium includes, but is not limited to, logical data blocks in a magnetic disk, optical disk, read-only memory, random access memory, cloud storage volume, or distributed file system.

[0103] Corresponding to the above embodiments, this specification also provides a computer program product. This program product includes a set of program instructions that can be directly loaded and executed by a processor. When the instruction set is executed in a computing device, it implements the embedded component generation method described in any of the above embodiments. The computer program product can be distributed, delivered, and activated online in the form of a container image, software installation package, microservice deployment package, or Software as a Service interface.

[0104] In summary, the embodiments in this specification dynamically inject the predefined interface specifications of the target platform as strong constraints into the generation prompts of the large language model, completely reversing the technical defects of traditional AI code generation tools that blindly output code without adhering to platform contracts. Combining multi-dimensional context awareness, automated layout prediction, streaming finite state machine parsing and rendering, and a closed-loop quality verification mechanism, this specification achieves fully automated delivery from natural language intent description to compliant and operable embedded components. This solution not only eliminates the high communication and debugging costs associated with manual interface specification adaptation but also ensures system stability under high concurrency environments through layered decoupling and fault-tolerant design. Those skilled in the art, based on an understanding of the core concepts of this specification, can make equivalent substitutions or adaptive adjustments to the execution order of specific implementation steps, the physical deployment topology of modules, the prompt assembly strategy, and the state transition rules of the parsing state machine. As long as their technical means do not depart from the protection intent of this specification, they should fall within the patent protection scope of this specification.

[0105] What those skilled in the art will understand is: In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0106] In this specification, "a," "an," and "the" do not specifically refer to the singular, but may also include the plural.

[0107] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0108] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0109] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0110] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples.

[0111] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.< / itagaction> < / itagartifact>

Claims

1. A method for generating an embedded component, comprising: Obtain the predefined interface specification of the target platform, wherein the target platform involves at least one extension point, the extension point is used to receive components embedded in the target platform, and the predefined interface specification describes the interface required by each of the at least one extension point; Obtain context information, wherein the context information includes at least user intent information determined based on user input, and platform constraint information obtained based on the target platform and unrelated to the user input. The user intent information represents the functional requirements for the embedded component, and the platform constraint information represents the integration constraints imposed by the target platform on the embedded component. Based on the predefined interface specification and the context information, prompts are dynamically assembled and generated. By injecting the predefined interface specification as a constraint into the generated prompts, the large language model is guided to output code that conforms to the predefined interface specification. The generated prompts are input into a large language model to obtain generated code that conforms to the predefined interface specifications and the context information; The generated code is output as an embedded component suitable for embedding into the target platform.

2. The method according to claim 1, wherein, The context information also includes data feature information, which is obtained by parsing the structured field information of the dataset associated with the embedded component, and is used to indicate the field type and field semantics of the data that the embedded component needs to process.

3. The method according to claim 2, wherein, The extension point corresponds to the display area in the user interface of the target platform; the context information also includes layout structure information, which is obtained by analyzing the task semantic description indicated by the user intent information and the structured field information through a layout prediction algorithm, and is used to indicate the spatial arrangement of the at least one extension point and the correspondence between each field and each extension point.

4. The method according to claim 3, wherein, The user intent information, the data feature information, the layout structure information, and the platform constraint information belong to four independent context layers, and the data acquisition and updating of each context layer are independent of each other.

5. The method according to claim 3, wherein, The step of analyzing the task semantic description and the structured field information using a layout prediction algorithm to obtain the layout structure information includes: The structured field information is subjected to field type identification and field semantic analysis to determine the data type and semantic role of each field; Based on the task type and the data type and semantic role of each field, calculate the matching degree between each field and each extension point; The layout structure information is determined based on the matching degree and the preset spatial constraints.

6. The method according to claim 1, wherein, The target platform is associated with multiple constraint documents, and the acquisition of the platform constraint information includes: Obtain the metadata tags of each of the multiple constraint documents; An index is constructed based on the aforementioned metadata tags; The system receives retrieval requests carrying tag information through a retrieval interface, performs tag matching in the index, and selects constraint documents related to the current generation task from the plurality of constraint documents. Extract the platform constraint information from the selected constraint document.

7. The method according to claim 6, wherein, The retrieval interface includes an exact matching interface and a fuzzy matching interface; wherein, performing tag matching in the index includes: When the tag information matches the metadata tag, a precise match is performed through the precise match interface; When the tag information is semantically related to the metadata tag but the expression is inconsistent, fuzzy matching is performed through the fuzzy matching interface.

8. The method according to claim 1, wherein, The large language model outputs the generated code in a streaming manner, and the method further includes: The incremental text of the streaming output is parsed in real time using a finite state machine to progressively identify predefined markup language tags in the incremental text during the streaming output process.

9. The method according to claim 8, wherein, The method further includes: Based on the identified types of the predefined markup language tags, the parsed content is distributed to the corresponding rendering areas for real-time visualization rendering.

10. The method according to claim 8, wherein, The finite state machine includes at least one error state and a corresponding error recovery path; During the real-time parsing process, when a mismatch or format error is detected in the predefined markup language tags, the finite state machine enters the error state and performs state rollback, tag completion, or skip operations along the error recovery path.

11. The method according to claim 1, wherein, After obtaining the generated code, the method further includes: Perform automatic verification on the generated code; When the generated code is detected to be inconsistent with the preset quality standard, the verification result is fed back to the large language model, triggering the large language model to iteratively regenerate based on the verification result.

12. The method according to claim 1, wherein, The embedded component is a data annotation template; The at least one extension point corresponds to at least one annotation area in the data annotation template, and the annotation area is used to receive user annotation input for the corresponding data field; The user intent information includes the data fields to be labeled and the labeling type.

13. A system for generating embedded components, comprising: An interface specification acquisition module is used to acquire a predefined interface specification of a target platform, wherein the target platform involves at least one extension point, the extension point is used to receive components embedded in the target platform, and the predefined interface specification describes the interface required by each of the at least one extension point. A context acquisition module is used to acquire context information, wherein the context information includes at least user intent information determined based on user input, and platform constraint information obtained based on the target platform and unrelated to the user input. The user intent information represents the functional requirements for the embedded component, and the platform constraint information represents the integration constraints imposed by the target platform on the embedded component. The prompt assembly module is used to dynamically assemble and generate prompts based on the predefined interface specification and the context information. By injecting the predefined interface specification as a constraint condition into the generated prompts, the large language model is guided to output code that conforms to the predefined interface specification. The code generation module is used to input the generation prompts into the large language model to obtain generated code that conforms to the predefined interface specification and the context information; The code output module is used to output the generated code as an embedded component suitable for embedding into the target platform.

14. An electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 12.

15. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method according to any one of claims 1 to 12.

16. A computer program product comprising a computer program or instructions which, when executed by a processor, implement the method of any one of claims 1 to 12.

Images