Method and system for generating subject data for vehicle interface component assembly

Abstract

The present application relates to the technical field of large language model, especially to the theme data generation method and system for vehicle-mounted interface component assembly, the present application proposes the following scheme, acquires structure constraint information and theme generation instruction and inputs theme generation model, generates vehicle-mounted theme token value set under the condition of keeping token level relationship and reference relationship unchanged; according to the mapping relationship between token and vehicle-mounted interface component, vehicle-mounted theme interface generation data is generated, and is pushed to the vehicle-mounted theme interface generation end to carry out theme style assembly. For abnormal token, the correction information is generated by determining the minimum correction propagation domain, so as to reduce the theme drift caused by full amount regeneration, improve the vehicle-mounted theme generation efficiency and interface consistency.

Description

Technical Field

[0001] This invention relates to the field of large language model technology, and in particular to a method and system for generating topic data for in-vehicle interface component assembly. Background Technology

[0002] With the development of smart cockpits, in-vehicle HMI interfaces are gradually shifting from fixed-style displays to multi-themed, personalized, and branded presentations. The visual effect of an in-vehicle themed interface is typically determined by a combination of factors, including color, font, spacing, rounded corners, shadows, transparency, and style variables under different component states. These style variables are usually managed in the design system using design tokens or meta-elements. Design tokens decouple the theme style from interface components, allowing in-vehicle interface components such as buttons, navigation bars, cards, pop-ups, and status prompts to achieve a unified visual presentation based on consistent theme variables.

[0003] In the current development process of in-vehicle themes, designers typically need to configure theme variables one by one in the design tools and further check the application effect of each variable in different interface components, different interaction states, and different display pages. Since a word may be referenced by multiple components, and a component may depend on multiple words at the same time, there are strong hierarchical and referential relationships between variables such as main color, text color, background color, font size, and spacing. Therefore, manual configuration is not only time-consuming, but also prone to problems such as related components not being adjusted synchronously after local modifications, inconsistent styles in different states, and insufficient contrast between some text and background.

[0004] While some AI-assisted interface design methods have emerged in the existing technology, these methods mostly focus on generating page-level visual drafts or interface layouts based on text descriptions. The generated results usually lack a stable connection with the existing in-vehicle theme's metastructure, component mapping relationships, and end-side assembly logic, making them difficult to directly use for the automatic generation of in-vehicle theme interfaces. On the other hand, existing theme update methods often require building a complete theme resource package first, and then distributing it to the in-vehicle terminal for display verification. In scenarios where the theme is frequently adjusted or multiple styles need to be previewed quickly, this can easily lead to a heavy generation chain, delayed end-side presentation, and high costs of repeated builds.

[0005] To address the above issues, this application presents a method and system for generating theme data for the assembly of vehicle interface components. Summary of the Invention

[0006] The technical problem this invention aims to solve is to address the shortcomings of existing technologies by providing a method and system for generating theme data for in-vehicle interface component assembly. This method acquires structural constraint information and theme generation instructions and inputs them into a theme generation model. While maintaining the hierarchical and referential relationships of lexical terms, it generates a set of in-vehicle theme lexical values. Based on the mapping relationship between lexical terms and in-vehicle interface components, it generates in-vehicle theme interface generation data and pushes it to the in-vehicle theme interface generation terminal for theme style assembly. For abnormal lexical terms, it generates correction information by determining the minimum correction propagation domain to reduce theme drift caused by full regeneration, thereby improving the efficiency of in-vehicle theme generation and interface consistency.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] A method for generating theme data for the assembly of in-vehicle interface components, the method comprising:

[0009] The acquired structural constraint information and topic generation instructions are input into a preset topic generation model so that the preset topic generation model generates a set of vehicle topic lexical values ​​corresponding to the target style while keeping the lexical hierarchy and citation relationships unchanged.

[0010] Based on the mapping relationship between the in-vehicle theme term value set and the in-vehicle interface components, the in-vehicle theme interface generation data is obtained;

[0011] The vehicle theme interface generation data is pushed to the vehicle theme interface generation terminal, so that the vehicle theme interface generation terminal can assemble the theme style of the corresponding vehicle interface components according to the vehicle theme interface generation data to generate the target vehicle theme interface.

[0012] The methods for obtaining the structural constraint information include:

[0013] Obtain the design token template data corresponding to the vehicle theme. The design token template data includes the lexical identifiers, lexical types, lexical hierarchical relationships, and reference relationships between multiple design tokens. The theme generation instruction is used to characterize the target style of the vehicle theme interface to be generated.

[0014] The lexical structure constraint information is determined based on the design token template data. The lexical structure constraint information is used to limit the structural position, value type, and reference dependency relationship of each lexical.

[0015] The topic generation model includes a constraint encoding network, a style semantic encoding network, a dependency propagation generation network, and a lexical value decoding network, wherein:

[0016] The constraint coding network is used to encode the lexical hierarchy relationship, value type, and reference dependency relationship in the structural constraint information to obtain lexical constraint features;

[0017] The style semantic coding network is used to semantically encode the style keywords, color tendencies and application scenarios in the theme generation instructions to obtain theme style features;

[0018] The dependency propagation generation network is used to determine the word generation order according to the word constraint features and the topic style features, and to generate derived word values ​​along the corresponding reference dependencies after generating the root word value.

[0019] The lexical value decoding network is used to decode the root lexical value and derived lexical value according to the value type of each lexical, and output the vehicle-mounted topic lexical value set.

[0020] The generation of the vehicle-mounted topic meta-value set corresponding to the target style includes:

[0021] The structural constraint information is input into the constraint coding network. The constraint coding network encodes the structural position, value type, reference input relationship, reference output relationship, and value constraint range of each word. The encoding results are then fused to obtain the word constraint features corresponding to each word.

[0022] The topic generation instruction is input into the style semantic encoding network. The style semantic encoding network extracts the style semantic features corresponding to the target style from the topic generation instruction, and generates topic style sub-features corresponding to color-related words, size-related words, and effect-related words, respectively, based on the style semantic features.

[0023] The lexical constraint features corresponding to each lexical and the topic style sub-features are input into the dependency propagation generation network. The dependency propagation generation network determines the root lexical that does not depend on the values ​​of other lexicals and the derived lexical that depends on the values ​​of other lexicals based on the reference input relationship and reference output relationship represented in the lexical constraint features. It also determines the lexical generation order from the root lexical to the derived lexical and generates the intermediate value features of the root lexical and the intermediate value features of the derived lexical.

[0024] The intermediate value features of the root word and the intermediate value features of the derived word are input into the word value decoding network. The word value decoding network performs type-based decoding on the intermediate value features of each word according to the value type and value constraint range of each word to obtain the word value corresponding to each word.

[0025] The methods for generating the intermediate value features include:

[0026] Based on the lexical constraint features corresponding to the root lexical and the topic style sub-features corresponding to the value type of the root lexical, intermediate value features of the root lexical are generated.

[0027] According to the word generation order, the intermediate value features of the generated word are propagated to the derived word with which it has a reference relationship, and the intermediate value features of the derived word are generated by combining the word constraint features corresponding to the derived word and the corresponding theme style sub-features.

[0028] The method further includes validating the set of vehicle-mounted topic terminology values, the validation including:

[0029] The set of vehicle-mounted topic lexical values ​​is subjected to lexical validity verification, which includes at least lexical value legality verification and lexical reference consistency verification.

[0030] When the vehicle-mounted topic lexical value set contains abnormal lexicals that fail the lexical validity check, correction information is generated based on the abnormal lexicals and the reasons for the failure of the check, and the correction information is fed back to the preset topic generation model so that the preset topic generation model can correct the abnormal lexicals and obtain a vehicle-mounted topic lexical value set that passes the check.

[0031] The methods for generating the correction information include:

[0032] Based on the validation results of the word validity check, identify the abnormal words that failed the validation and the reasons for the validation failure of the abnormal words.

[0033] Based on the lexical type, current value, and reason for failure of the verification of the abnormal lexical, determine the correction constraint corresponding to the abnormal lexical;

[0034] Based on the abnormal lexical terms, the reasons for the failed verification, and the correction constraints, correction information is generated.

[0035] The methods for generating the data for the in-vehicle theme interface include:

[0036] Obtain the preset mapping relationship between lexical elements and in-vehicle interface components. The mapping relationship includes lexical identifiers, component identifiers, and style attribute identifiers corresponding to the component identifiers.

[0037] Based on the identifiers of each term in the set of vehicle-mounted thematic term values, the target vehicle-mounted interface components and target style attributes corresponding to each term are determined in the mapping relationship.

[0038] Based on the lexical value corresponding to each lexical, the target vehicle interface component, and the target style attribute, a component style configuration item is generated. The component style configuration item is used to represent the corresponding style attribute of the corresponding lexical value to the corresponding vehicle interface component.

[0039] The in-vehicle theme interface generation data is obtained based on multiple component style configuration items.

[0040] The generation methods for the theme style assembly include:

[0041] The vehicle theme interface generator receives the vehicle theme interface generation data and parses it to obtain multiple component style configuration items;

[0042] Based on the component identifier in each component style configuration item, determine the vehicle interface component to be installed in the preset vehicle interface template;

[0043] Based on the style attribute identifier in the style configuration items of each component, the corresponding lexical value is written into the style attribute slot of the vehicle interface component to be assembled.

[0044] Based on the component hierarchy in the preset vehicle interface template, the vehicle interface components with completed style attributes are assembled to generate the target vehicle theme interface.

[0045] A theme data generation system for in-vehicle interface component assembly, the system comprising:

[0046] The topic lexical generation module is used to input the acquired structural constraint information and topic generation instructions into a preset topic generation model, so that the preset topic generation model generates a set of vehicle topic lexical values ​​corresponding to the target style while keeping the lexical hierarchy and reference relationship unchanged.

[0047] The interface data generation module is used to obtain vehicle theme interface generation data based on the mapping relationship between the vehicle theme term value set and the vehicle interface components.

[0048] The real-time push assembly module is used to push the vehicle theme interface generation data to the vehicle theme interface generation end, so that the vehicle theme interface generation end can assemble the theme style of the corresponding vehicle interface components according to the vehicle theme interface generation data and generate the target vehicle theme interface.

[0049] Compared with the prior art, the beneficial effects of the present invention are:

[0050] This invention maintains the stability of the hierarchical relationship, reference relationship, and component mapping relationship of vehicle theme terms, automatically generates vehicle theme interface generation data corresponding to the target style, and pushes it to the vehicle theme interface generation end to complete the assembly. This reduces manual item-by-item configuration and repeated construction of complete theme packages. At the same time, it limits the correction range of abnormal terms by limiting the minimum correction propagation domain, reduces the probability of verified terms being damaged a second time, and improves the efficiency, consistency and stability of vehicle theme interface generation. Attached Figure Description

[0051] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0052] Figure 1 An exemplary application scenario diagram provided for an embodiment of this application;

[0053] Figure 2 A system architecture diagram for generating the in-vehicle theme interface provided in the embodiments of this application;

[0054] Figure 3 A flowchart illustrating the method for generating theme data for assembling vehicle interface components provided in an embodiment of the present invention;

[0055] Figure 4 This is a schematic diagram of the design end provided in the embodiments of this application. Detailed Implementation

[0056] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0057] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0058] Example 1:

[0059] In in-vehicle human-machine interaction systems, the theme interface is not simply formed by piecing together a few static images or page templates, but rather by multiple interface components such as navigation bars, instrument cards, control buttons, status prompts, media controls, air conditioning controls, and pop-up components. These interface components typically maintain a relatively stable component structure across different vehicle platforms, screen sizes, and display modes. However, their visual appearance changes with the theme style. For example, the main color, background color, text color, font size hierarchy, component rounded corners, spacing density, shadow intensity, and state styles such as selected, disabled, and alert states all affect the final display effect of the in-vehicle theme interface. Therefore, in the development of in-vehicle themes, what often needs frequent adjustment is not the interface components themselves, but the design tokens used to drive the visual appearance of each component—the Design morphemes, which can also be understood as morphological theme style variables.

[0060] In practical engineering, OEMs or in-vehicle system suppliers typically establish a pre-defined in-vehicle HMI design framework. This framework includes relatively fixed component structures, page hierarchies, interaction states, and theme variable naming conventions. When generating a new theme, designers often need to configure numerous design tokens item by item based on the existing design framework. This includes adjusting values ​​for primary color, secondary color, background color, text color, font size, line height, spacing, rounded corners, and shadows, and further checking the mapping effects of these values ​​across multiple in-vehicle interface components. Since a design token is usually referenced by multiple interface components, and an interface component may depend on multiple design tokens simultaneously, a change in a primary color, font size, or spacing can affect the visual appearance of multiple interface areas such as buttons, cards, lists, navigation bars, and pop-ups.

[0061] It is understandable that generating an in-vehicle theme interface is not a simple color replacement problem, but a structured generation problem constrained by word hierarchy relationships, reference relationships, and component mapping relationships.

[0062] Existing theme development methods generally rely on designers manually configuring theme variables in design tools, or generating a complete theme package before deploying it to the vehicle's infotainment system for display verification. While this is acceptable for small-scale theme pre-set scenarios, it reveals significant shortcomings in scenarios where in-vehicle systems need to support theme generation for multiple styles, brands, and user preferences. On one hand, manually configuring design tokens item by item is time-consuming and makes it difficult to ensure hierarchical and referential consistency among all tokens. On the other hand, if each theme adjustment requires rebuilding the complete theme resource package and then deploying it to the vehicle or simulation end for verification, the theme generation chain becomes cumbersome, making it difficult to meet the needs of rapid generation and immediate application. Especially during in-vehicle HMI development, theme effects often require repeated joint debugging between the design end, the cloud-based build end, and the in-vehicle display end. Without a method that can directly generate interface styles from structured typologies and push them to the generation end in real time, the theme development process easily degenerates into a cycle of "manual adjustment - offline packaging - on-device verification - further modification."

[0063] Meanwhile, although existing AI-assisted design tools can generate interface pages of a certain form based on text descriptions, the page-level generation results are usually more inclined towards free-style visual design, and their output content is often difficult to directly embed into the existing design system of automotive HMIs. For automotive theme interfaces, the generated results not only need to conform to a certain target style, but also must maintain the original hierarchical relationship, referencing relationship, and component mapping relationship of the design tokens without disrupting them. For example, button highlight colors cannot be arbitrarily generated outside the main color system, text colors need to maintain readability with the background color, and font size changes may also affect related styles such as line height, spacing, and rounded corners. If only an interface mockup or a set of unstructured style values ​​is generated, the automotive theme interface generator still cannot reliably determine which components, states, and interface levels these style values ​​should be fitted to, and it is also difficult to guarantee the consistent display of the same theme across different automotive interfaces.

[0064] Based on the aforementioned engineering phenomena, the concept of this application embodiment is not to simply generate a new visual page using a model, but rather to utilize the relatively stable lexical structure in the in-vehicle theme design system as a generation constraint, limiting the theme generation process within the existing lexical hierarchy and referencing relationships. In other words, the structure of the in-vehicle theme is provided by the design token template, the style of the in-vehicle theme is provided by the theme generation instruction, and the preset theme generation model generates a set of in-vehicle theme lexical values ​​corresponding to the target style under the joint constraints of both.

[0065] Furthermore, this application's embodiments focus not only on the generation of lexical values ​​themselves, but also on how lexical values ​​are transformed into in-vehicle theme interface generation data and pushed to the in-vehicle theme interface generation end. For the in-vehicle theme generation chain, if only a set of lexical values ​​is obtained in the cloud or at the design end, and a mapping relationship cannot be established between them and in-vehicle interface components, then the lexical values ​​remain independent style variables and cannot directly form an in-vehicle theme interface. Therefore, this application's embodiments, after obtaining the set of in-vehicle theme lexical values, generate in-vehicle theme interface generation data that can be parsed by the in-vehicle theme interface generation end based on the mapping relationship between the set of in-vehicle theme lexical values ​​and in-vehicle interface components, and push this in-vehicle theme interface generation data to the in-vehicle theme interface generation end. This allows the in-vehicle theme interface generation end to assemble the theme style of the corresponding in-vehicle interface components according to the correspondence between component identifiers, style attributes, and lexical values, thereby generating the target in-vehicle theme interface.

[0066] It should be noted that the in-vehicle theme interface generation end described in this application embodiment can be a theme rendering module on the vehicle-mounted system, or a simulation generation end, a cloud-based theme building end, or a preview generation end on the design tool side used for in-vehicle HMI development and verification. Their common feature is that they can all receive in-vehicle theme interface generation data and complete theme style assembly according to preset component structures and style attribute slots. This application embodiment does not rely on a specific design tool, a specific vehicle platform, or a specific in-vehicle interface page as a prerequisite for implementation, but rather targets in-vehicle HMI application scenarios with a structured design token system, a componentized in-vehicle interface system, and dynamic theme style generation requirements.

[0067] Those skilled in the art will understand that, in scenarios where in-vehicle theme interfaces need to be quickly generated and applied to in-vehicle interface components, how to automatically generate a set of usable in-vehicle theme terminology values ​​based on the target style while maintaining the stability of the existing design token structure, reference relationships, and component mapping relationships, and transform these into interface generation data that the in-vehicle theme interface generator can receive and assemble in real time, thereby reducing the efficiency loss caused by manually configuring theme variables item by item and building complete theme packages offline, while improving the consistency of in-vehicle theme interfaces across multiple components, multiple states, and multiple display terminals.

[0068] refer to Figure 1 , Figure 1 This is an exemplary application scenario diagram provided for an embodiment of this application.

[0069] like Figure 1 As shown, the development and application of in-vehicle theme interfaces typically involves the designer's end, the cloud, and the in-vehicle end. The designer's end can be understood as the terminal environment where designers, in-vehicle HMI developers, or theme operators configure theme styles, input theme generation commands, and confirm theme effects. The cloud can be understood as the server-side environment used for theme generation, theme data management, theme resource conversion, and theme data distribution. The in-vehicle end can be understood as the in-vehicle HMI system, vehicle display system, or theme rendering environment installed in the vehicle for controlling the in-vehicle interface display. These three components together constitute a typical application chain for in-vehicle themes, from the formation of design intent and theme data generation to the presentation of the in-vehicle interface.

[0070] In application scenarios, designers typically don't directly write styles for every single interface component on the in-vehicle interface. Instead, they propose theme style requirements based on the existing in-vehicle HMI design system. For example, designers might want to generate in-vehicle themes with a sporty, tech-oriented, low-brightness nighttime, or brand-customized style. For in-vehicle theme interfaces, these style requirements are not ultimately applied to the in-vehicle interface as a single image or page, but need to be transformed into a series of theme style variables that can be recognized by the in-vehicle interface components, such as colors, font sizes, spacing, rounded corners, shadows, and status styles. In other words, the designer inputs a relatively abstract style intent, while the in-vehicle interface actually needs structured theme data that can be applied to specific interface components.

[0071] In practical engineering, the cloud typically handles the conversion of theme data between the designer's end and the vehicle's end. On one hand, the cloud needs to generate corresponding theme data based on the theme generation requirements provided by the designer; on the other hand, the cloud also needs to ensure that the generated theme data can be stably parsed and applied by the vehicle's end. Since the interface components of the vehicle's end often have fixed component structures, state types, and style slots—for example, button components have background color, text color, rounded corners, and pressed state styles; card components have background color, shadow, and margin styles; and navigation components have selected state colors and default state colors—the theme data generated by the cloud cannot be an unstructured visual result; it should be able to establish a clear mapping relationship with the component system of the vehicle's end.

[0072] Therefore, in Figure 1 In the application scenarios shown, a common technical challenge faced by those skilled in the art is that designers want to quickly obtain multiple theme styles, the cloud needs to convert these theme styles into structured theme data that can be used by in-vehicle devices, and the in-vehicle devices require that the received data can directly drive interface components to complete theme style assembly. If the method of manually configuring theme variables item by item, generating complete theme packages offline, and then sending them to the in-vehicle devices for verification is still adopted, then each theme style adjustment may involve the repeated configuration of a large number of style variables and the reconstruction of complete resource packages, which is difficult to meet the needs of rapid generation, instant delivery, and rapid presentation of in-vehicle themes on the device side.

[0073] Based on the above application scenarios, this application embodiment does not simply interpret the interaction between the designer's end, the cloud, and the vehicle end as ordinary data transmission, but further focuses on the structural stability and assemblability of vehicle-mounted theme data when it is transmitted between the three, referring to... Figure 2 , Figure 2 The system architecture diagram for generating the in-vehicle theme interface provided in the embodiments of this application.

[0074] like Figure 2As shown, the system specifically includes a lexical template parsing module, an AI large-scale model generation module, a lexical verification module, and a lexical output module. The lexical template parsing module can be set up in a cloud-based lexical template management service to receive in-vehicle theme design token template data uploaded or synchronized from the design end. This design token template data can originate from lexical definitions in design tools, design system configuration files, or existing in-vehicle theme resources. Its content typically includes lexical name, lexical type, current value, hierarchy, grouping information, and the reference relationships between lexical elements. For in-vehicle themes, these lexical elements are not isolated style parameters. For example, the primary color lexical element may be referenced by multiple semantic lexical elements such as button background color, selected state color, and emphasized text color. The base font size lexical element may also affect line height, paragraph spacing, or component size. Therefore, the lexical template parsing module does not merely perform format conversion on the template data; it further identifies the hierarchical organization and dependencies between lexical elements, transforming the theme variables, originally readable by designers, into structural constraint information that the theme generation model can understand and process.

[0075] In one feasible implementation, the lexical template parsing module can generate a lexical structure description file after parsing the design token template data. This lexical structure description file is used to characterize the structural boundaries of in-vehicle theme lexicals, rather than to define a specific theme style. That is, regardless of whether a sporty, technological, nighttime, or brand-customized style needs to be generated subsequently, the lexical structure description file can maintain the original hierarchical and referential relationships of lexicals within the in-vehicle HMI design system without disrupting them. Therefore, when generating theme lexical values, the AI ​​large model generation module will not arbitrarily generate a set of style data detached from the in-vehicle interface component system, but will stylize the values ​​of each lexical within the existing lexical structure, thus enabling the generated results to be recognized and assembled by the downstream in-vehicle theme interface generation end.

[0076] The AI ​​large-scale model generation module receives structural constraint information from the lexical template parsing module and theme generation instructions from the design end. Under the combined constraints of both, it generates a set of automotive theme lexical values ​​corresponding to the target style. Theme generation instructions can include style keywords, color preferences, usage scenarios, brand visual requirements, or display mode requirements. For example, designers can input theme generation intentions such as "dark tech style," "low brightness night mode," or "sporty high contrast style" through the design end. For the AI ​​large-scale model generation module, the theme generation instructions provide the style direction, while the structural constraint information provides the generation boundary. Only by combining the two can the generated result possess the target style without disrupting the lexical structure, referencing relationships, and component adaptation relationships in the original automotive HMI design system.

[0077] Furthermore, in the in-vehicle theme generation scenario, the AI ​​large-scale model generation module does not generate free visual drafts at the page level, but rather a set of lexical values ​​that can be consumed by the in-vehicle theme interface generation chain. Each lexical value in this set corresponds to a lexical identifier in the design token template, and still retains the hierarchical and referential relationships in the original template. For example, color lexicals can correspond to background color, foreground color, accent color, warning color, disabled color, etc.; size lexicals can correspond to font size, line height, spacing, rounded corners, etc.; effect lexicals can correspond to shadow, transparency, blur level, etc. In this way, the model generation result does not stop at the level of "generating an interface mockup", but directly forms structured theme data that can drive the style assembly of in-vehicle interface components.

[0078] The lexical validation module is used to automatically validate the set of lexical values ​​for in-vehicle themes output by the AI ​​large-scale model generation module. Since the in-vehicle theme interface is ultimately used in the vehicle's infotainment system, its theme style not only needs to conform to the target style but also needs to meet the requirements of readability, legality, and consistency of citations. Therefore, the lexical validation module can validate whether lexical values ​​are legal, whether lexical citations exist, whether citation types match, and whether color contrast meets display requirements. When a lexical value fails to meet the validation requirements, the lexical validation module can generate correction information based on the abnormal lexical and the reason for its failure, and feed this correction information back to the AI ​​large-scale model generation module, enabling the AI ​​large-scale model generation module to correct the abnormal lexical.

[0079] It's important to note that the lexical validation module doesn't replace the AI ​​model generation module in regenerating topics; rather, it provides deterministic constraints on the model's generated results. The AI ​​model generation module is better suited for handling style semantics, color coordination, and cross-lexical relationships, while the lexical validation module is better suited for handling value boundaries, citation consistency, and rule-based judgments. Working together, they avoid issues like invalid values, incorrect citation relationships, or unreadable parts caused by relying solely on model generation, and they also avoid the problems of monotonous topic styles and excessively high manual configuration costs associated with relying entirely on rule-based generation.

[0080] The lexical output module receives the validated set of vehicle-themed lexical values ​​and converts them into standardized output data that can be used by the downstream vehicle-themed interface generation chain. This standardized output data may include lexical identifiers, lexical types, lexical values, lexical levels, citation relationships, and mapping information between lexical identifiers and vehicle-themed interface components. For application scenarios requiring version management, the lexical output module can also store the validated set of vehicle-themed lexical values ​​in the lexical library version management unit for subsequent querying, rollback, reuse, or regeneration based on vehicle model, theme style, display mode, or release time.

[0081] exist Figure 2 In the architecture shown, standardized output should not be understood as a simple data saving action, but rather as the foundation for the in-vehicle theme interface generation chain to enter the downstream push and assembly stages. The set of in-vehicle theme lexical values ​​output by the lexical output module can be further used to generate in-vehicle theme interface generation data based on the mapping relationship between lexicals and in-vehicle interface components, and then pushed to the in-vehicle theme interface generation end. Upon receiving this in-vehicle theme interface generation data, the in-vehicle theme interface generation end can write the corresponding lexical values ​​into the style attributes of the corresponding in-vehicle interface components, thereby completing the generation of the target in-vehicle theme interface.

[0082] It should be pointed out that, Figure 2 The modules shown are merely illustrative of an exemplary architecture for the in-vehicle theme interface generation system in this application embodiment, and do not limit the modules to be deployed on different servers or different physical devices. For example, the lexical template parsing module, the AI ​​large model generation module, the lexical verification module, and the lexical output module can all be deployed in the cloud, or some parsing, verification, or output functions can be deployed on the design end or the in-vehicle theme interface generation end. As long as the system can generate an in-vehicle theme lexical value set based on structural constraint information and theme generation instructions, and convert the lexical value set into theme interface generation data that can be assembled by in-vehicle interface components, it can be considered to fall within the implementation scope of this application embodiment.

[0083] In some optional embodiments, this application provides a theme data generation system for in-vehicle interface component assembly, the system comprising:

[0084] The topic lexical generation module is used to input the acquired structural constraint information and topic generation instructions into a preset topic generation model, so that the preset topic generation model generates a set of vehicle topic lexical values ​​corresponding to the target style while keeping the lexical hierarchy and reference relationship unchanged.

[0085] The interface data generation module is used to obtain vehicle theme interface generation data based on the mapping relationship between the vehicle theme term value set and the vehicle interface components.

[0086] The real-time push assembly module is used to push the vehicle theme interface generation data to the vehicle theme interface generation end, so that the vehicle theme interface generation end can assemble the theme style of the corresponding vehicle interface components according to the vehicle theme interface generation data and generate the target vehicle theme interface.

[0087] Next, with reference to the accompanying drawings, the method for generating subject data for assembling vehicle interface components provided in this application will be further described. Figure 3 The methods shown include:

[0088] S1: Input the acquired structural constraint information and topic generation instructions into the preset topic generation model so that the preset topic generation model generates a set of vehicle topic lexical values ​​corresponding to the target style while keeping the lexical hierarchy and citation relationship unchanged.

[0089] In this embodiment, the structural constraint information can be derived from existing design token template data of the vehicle theme. This design token template data is typically maintained by the design team and describes the names, types, hierarchical positions, default values, and reference relationships of various terms in the vehicle theme. For example, color-related terms may include primary color, background color, text color, warning color, selected state color, etc.; size-related terms may include font size, line height, spacing, rounded corners, etc.; and effect-related terms may include shadow, transparency, blur level, etc. Those skilled in the art will understand that the source of the design token template data can be determined based on the actual development environment. For example, it can be exported from a design tool or parsed from an existing vehicle theme configuration file, as long as it can minimally represent the hierarchical relationships, value types, and reference relationships between terms. This application does not impose further limitations.

[0090] S2: Based on the mapping relationship between the in-vehicle theme term value set and the in-vehicle interface components, obtain the in-vehicle theme interface generation data;

[0091] In this embodiment, the mapping relationship may include lexical identifiers, component identifiers, style attribute identifiers, and component state identifiers. The component identifier is used to determine the target in-vehicle interface component where the lexical value acts; the style attribute identifier is used to determine the specific style location where the lexical value is written; and the component state identifier is used to distinguish different display states such as default state, selected state, disabled state, pressed state, and alert state. For example, the lexical "primary_color" can be mapped to the selected icon color in the navigation component, the default background color in the button component, and the on track color in the switch component; the lexical "radius_medium" can be mapped to the outer contour rounded corner in the card component and the container rounded corner in the pop-up component.

[0092] S3: Push the vehicle theme interface generation data to the vehicle theme interface generation terminal so that the vehicle theme interface generation terminal can assemble the theme style of the corresponding vehicle interface components according to the vehicle theme interface generation data and generate the target vehicle theme interface.

[0093] In this embodiment, the vehicle theme interface generator can be a vehicle infotainment system theme rendering terminal, or a simulation terminal, preview terminal, or theme building terminal during the vehicle HMI development process. After receiving the vehicle theme interface generation data, the vehicle theme interface generator can locate the corresponding vehicle interface component based on the component identifier, determine the style slot to be written based on the style attribute identifier, and write the corresponding metaword value into the corresponding style slot, thereby completing the theme style assembly. For example, the vehicle theme interface generator can write the background color metaword into the page container background attribute, the text color metaword into the text component color attribute, the rounded corner metaword into the corner attribute of the button or card, and the shadow metaword into the shadow attribute of the overlay or pop-up component.

[0094] refer to Figure 4 , Figure 4 This is a schematic diagram of the design end provided in the embodiments of this application.

[0095] It should be noted that, Figure 4 The design interface shown can include the Figma design tool and Figma plugins. The Figma design tool can be understood as a design tool for interface design and collaborative design, while the Figma plugin can be understood as an extension program running within the Figma design tool, used to read theme variables, component styles, and design tokens from the design file. Figure 4 Figma is used as an example of one implementation method for the design end, and it does not mean that the embodiments of this application can only rely on Figma for implementation; in other feasible methods, the design end can also use other design tools that can maintain the design system, theme variables or interface component styles, as long as they can provide design token template data corresponding to the vehicle theme.

[0096] In this embodiment, the design end does not directly generate the target in-vehicle theme interface, but rather provides the original structural foundation required for generating the in-vehicle theme. Specifically, in-vehicle HMI designers can pre-maintain the Design System corresponding to the in-vehicle theme in the Figma design tool. The design system typically includes atomic style variables such as color, font, font size, spacing, rounded corners, shadows, and transparency, and may also include style reference relationships for in-vehicle interface components such as buttons, cards, navigation bars, pop-ups, and status prompts. In this embodiment, the aforementioned atomic style variables can be called DesignTokens, which can also be called tokens. Design tokens are not simply display values, but rather the smallest structural unit used to carry the style rules of the in-vehicle theme. For example, "primary color," "background color," "title font size," "card rounded corners," and "pop-up shadows" can all be used as different types of design tokens.

[0097] Furthermore, the Figma plugin is used to extract design token template data from the current in-vehicle theme design system within the Figma design tool. The extracted content can include the token's lexical identifier, lexical type, current value, group, hierarchical path, and the reference relationships between lexical elements. The lexical identifier distinguishes different design tokens; for example, it can use variable names, style names, or normalized unique names from the design tool. The lexical type indicates whether the design token belongs to the color, font, size, rounded corner, shadow, or other effect category. The current value records the default or reference value of existing themes in the template. The group and hierarchical path represent the structural position of the design token within the design system. The reference relationship indicates whether a lexical is derived from or referenced by other lexical elements; for example, the button background color lexical can reference the main color lexical, and the card rounded corner lexical can reference the medium rounded corner lexical. Through this extraction process, the design team can organize the theme style information originally scattered in the design file into structured design token template data that can be subsequently parsed and processed.

[0098] In its implementation, the Figma plugin can read Variables, Styles, Components, and Variants from the Figma design tool. Variables can be understood as variables used to store reusable values ​​such as color and size; Styles can be understood as styles used to describe text styles, color styles, or effect styles; Components can be understood as components used to represent reusable interface units; and Variants can be understood as component variations used to represent style differences of the same component in different states or specifications. The Figma plugin can identify which variables belong to the in-vehicle theme terms and which component attributes reference the corresponding terms based on variable names, style binding relationships, and component reference information, and organize the identification results into design token template data. Temporary layers, annotation information, and non-theme-related visual materials can be excluded from the design token template data by the Figma plugin to avoid interference from non-theme style information in the subsequent generation process.

[0099] Furthermore, after the design token template data is extracted, it can be sent to the cloud-based lexical template management service via the Figma plugin. Upon receiving the design token template data, the cloud-based lexical template management service can further parse the hierarchical relationships, value types, and reference dependencies between design tokens, thereby forming structural constraint information. In other words, the design team is primarily responsible for extracting the original design token template data from the design files, while the structural constraint information can be further refined based on the template data.

[0100] It should be noted that the specific methods for parsing the hierarchical relationships, value types, and reference dependencies between design tokens can refer to the existing processing methods in the design token specification regarding token naming, grouping, type declarations, and alias references. For example, the hierarchical relationship can be determined based on the hierarchical separator, the grouping field, or the style path in the design token name; the value types such as color, font, size, rounded corners, and shadow can be determined based on the token value format or type declaration; and the reference dependencies can be determined based on the reference identifier, alias field, or component style binding relationship contained in the token value. The above parsing process belongs to the conventional data parsing processing in the structured management of design tokens. Those skilled in the art can adapt it according to the actual design tools, token formats, or configuration file organization methods used, as long as they can obtain the structural constraint information used to limit the position of lexical structures, value types, and reference dependencies. This application embodiment will not elaborate on this.

[0101] In this embodiment, the structural constraint information is not used to limit a specific style, but rather to limit the structural relationships that cannot be destroyed during the generation of the in-vehicle theme. For example, if the reference chain of "primary color - light shade - button selected state background color" has been defined in the design token template data, then when generating new technology or sports styles, the specific color values ​​of the above-mentioned words can be changed, but the reference relationships between the above-mentioned words should not be changed; if the proportional relationship of "base font size - line height - paragraph spacing" has been defined in the template, then when generating in-vehicle themes with different display densities, the font size and spacing values ​​can be adjusted, but the corresponding hierarchical and type relationships should be maintained.

[0102] Those skilled in the art will understand that when the Figma plugin extracts design token template data, specific fields can be adjusted according to the data organization method on the design side. For example, some design files may directly contain Design Token naming conventions, while others may only contain variable, style, and component binding relationships, requiring conversion into token identifiers and token reference relationships through naming rules or reference paths; some design files may already contain component state information, while others require inferring the default, selected, disabled, or pressed state based on the component variant name. As long as the token identifiers, token types, token hierarchy relationships, and reference relationships between tokens can be obtained at a minimum, a foundation can be provided for the subsequent generation of structural constraint information; this application embodiment does not impose further limitations.

[0103] Next, we will further elaborate on the technical aspects of the topic generation model in this application.

[0104] It should be noted that the topic generation model in this application can be specifically configured as an AI large language model, that is, an artificial intelligence generation model trained on a large-scale text corpus, structured data samples, and instruction response samples, capable of jointly understanding and generating natural language instructions and structured context. For this application, the AI ​​large language model is not used to directly generate an in-vehicle theme rendering, nor is it used to freely create a completely new in-vehicle interface page. Rather, it is used to generate the target values ​​corresponding to each word within the word range limited by structural constraints, based on the topic generation instructions.

[0105] In this embodiment, the AI ​​large language model can be a pre-trained language model with instruction understanding and structured text output capabilities, or it can be a language model that has been further fine-tuned using in-vehicle topic samples, design token samples, or topic configuration samples. The specific source of the model is not limited; it can be a general-purpose large language model deployed in the cloud, or a dedicated model trained for in-vehicle HMI topic generation tasks, as long as it can output lexical values ​​in a specified format based on structural constraint information and topic generation instructions.

[0106] In one example, the topic generation model includes a constraint encoding network, a style semantic encoding network, a dependency propagation generation network, and a lexical value decoding network. These networks can be integrated into different processing layers of the same large AI language model, or they can be formed by combining graph neural networks, semantic encoding networks, sequence generation networks, and multi-task decoding networks. To facilitate implementation by those skilled in the art, this embodiment further provides a feasible model construction method: the constraint encoding network uses a Graph Attention Network (GAT) or a Graph Convolutional Network (GCN); the style semantic encoding network uses a Transformer-based text encoding model, such as BERT, RoBERTa, Sentence-BERT, or a text encoding model trained on a Chinese design corpus; the dependency propagation generation network uses a Transformer Decoder with a cross-attention mechanism, i.e., a Transformer decoding network, and performs constraint generation based on the topological generation order of the lexical dependency graph; the lexical value decoding network uses a multi-task feedforward decoding network, which is a multilayer perceptron network with separate output branches for color, size, font, and effect lexical classes. The above models all belong to existing implementable neural network structures. The focus of this embodiment is to combine the above model structures according to the structural constraints, style semantics and reference dependencies of vehicle topic lexical units.

[0107] In this embodiment, a constraint coding network is used to process structural constraint information. The structural constraint information can first be converted into a lexical dependency graph, where each node corresponds to a lexical, and each edge corresponds to a reference relationship or hierarchical relationship between lexicals. Node features can be obtained by concatenating lexical identifier embeddings, lexical type embeddings, hierarchical position embeddings, value range embeddings, and current template value embeddings; edge features can be encoded by referencing direction, parent-child hierarchical relationship, derivation relationship, or component reference relationship. After inputting the above node features and edge features into GAT or GCN, the constraint coding network performs message passing between adjacent lexical nodes, ensuring that each lexical node not only contains its own type and position but also the structural information of upstream, downstream, and same-level lexicals with which it has a reference relationship. After several layers of graph convolution or graph attention propagation, the constraint coding network outputs the lexical constraint features corresponding to each lexical.

[0108] In this embodiment, a style semantic encoding network is used to process topic generation instructions. The topic generation instructions are first segmented and converted into a sequence of text tokens. Here, text tokens are text fragments in natural language processing, different from the lexical units in design tokens. After the text token sequence is input into a Transformer-based text encoding model, a self-attention mechanism is used to extract the semantic relationships between style keywords, color tendencies, application scenarios, and display modes, resulting in an overall style semantic vector. For example, "dark tech style, suitable for nighttime driving, brand main color leaning towards blue" can be encoded as style semantic features that simultaneously include low brightness tendency, cool color tendency, tech feel tendency, and nighttime readability tendency. Subsequently, the style semantic encoding network can use several linear mapping layers to decompose the overall style semantic features into color-related topic style sub-features, size-related topic style sub-features, font-related topic style sub-features, and effect-related topic style sub-features.

[0109] In this embodiment, the dependency propagation generative network is used to generate intermediate value features of root lexical units and derived lexical units based on lexical constraint features and theme style sub-features. Specifically, the lexical generation order can be determined first based on the lexical dependency graph. Lexical units that can be determined without depending on other lexical values, such as primary color lexical units, base font size lexical units, and base spacing lexical units, can be used as root lexical units; lexical units that need to be derived from other lexical units, such as primary color light level, primary color dark level, button selected state background color, text weakening color, line height, paragraph spacing, etc., can be used as derived lexical units. The dependency propagation generative network generates features according to a topological order from root lexicons to derived lexicons. When generating intermediate features for the root lexicons, the lexicon constraint features corresponding to the root lexicons are fused with the corresponding topic style sub-features, and then the intermediate features for the root lexicons are generated through the Transformer decoding layer. When generating intermediate features for derived lexicons, the generated intermediate features for upstream lexicons, the lexicon constraint features of the derived lexicons themselves, the corresponding topic style sub-features, and the reference edge features are all input into the Transformer decoding layer, ensuring that the intermediate features for derived lexicons are simultaneously constrained by the target style and upstream dependent lexicons. Through this process, the topic generation model embodies the generation logic of "first generating root lexicons such as primary color and base font size, then generating derived lexicons along the reference dependency chain."

[0110] In this embodiment, the token value decoding network is used to convert intermediate value features into specific token values. Since different types of tokens have different output formats, the token value decoding network can adopt a multi-task output structure. For color-related tokens, a color decoding branch can be set to decode intermediate value features into hue, saturation, and brightness parameters, and then convert them into HEX or RGB color values. For size-related tokens, a size decoding branch can be set to decode intermediate value features into positive size values, and add display units recognizable by the vehicle interface, such as px, dp, or sp. For font-related tokens, a font decoding branch can be set to output font size, font weight, or line height parameters. For shadow or effect-related tokens, an effect decoding branch can be set to output parameters such as offset, blur radius, diffusion radius, and transparency. Each output branch can be constrained during decoding, for example, color output is limited to a legal color gamut, size output is limited to positive numbers, and transparency output is limited to a preset range. Through typed decoding, the problem of unstable format caused by all tokens being freely generated in a uniform text format can be avoided.

[0111] In a training example, the topic generation model can be obtained using a combination of supervised training and constraint verification feedback training. Training samples can consist of historical in-vehicle topic data, manually designed design token templates, topic description text, and a set of approved lexical values. Each training sample can include structural constraint information, topic generation instructions, and a target in-vehicle topic lexical value set. The structural constraint information is obtained by parsing the design token template. The topic generation instructions can originate from the designer's style description of historical topics or be automatically generated based on topic names, topic tags, and color distribution. The target in-vehicle topic lexical value set consists of lexical values ​​from topics that have been manually confirmed or validated in online applications. During training, the structural constraint information is input into the constraint encoding network, and the topic generation instructions are input into the style semantic encoding network. The features output by both networks are fed into the dependency propagation generation network and the lexical value decoding network, ultimately outputting a predicted lexical value set, which is then compared with the target in-vehicle topic lexical value set.

[0112] During training, different loss terms can be set for different lexical types. Color-related lexical terms can use color space distance loss, such as calculating the distance between the predicted color and the target color in the Lab or HSV color space, to reduce cases where they are only similar in RGB values ​​but have significant visual differences. Size-related lexical terms can use mean absolute error or mean squared error loss to constrain font size, spacing, and rounded corner values ​​to be close to the target values. Lexical terms related to citation relationships can use dependency consistency loss to ensure that the changing trend of derived lexical terms relative to the root lexical term conforms to the dependency patterns in the training samples. Text format or output format can use format constraint loss to reduce the probability of generating illegal color values, missing units, or omitted fields. For style semantic encoding networks, style contrastive learning training can also be introduced to make the semantic features of topics under the same style label more similar, while maintaining the distinction between the semantic features of topics under different style labels, thereby improving the model's ability to recognize topic commands such as "tech style," "sports style," and "night mode."

[0113] In another training example, validation feedback training can be added after supervised training. Specifically, the predicted lexical value set output by the topic generation model is input into the lexical validation process. If there are abnormal lexical values, inconsistent citations, insufficient contrast, or non-compliant formats, a correction sample is constructed based on the abnormal lexical and the reason for the validation failure. The correction sample may include the original structural constraint information, the original topic generation instruction, the abnormal lexical identifier, the current value of the abnormal lexical, the reason for the validation failure, and the manually corrected target lexical value. Using the above correction sample, the dependency propagation generation network and the lexical value decoding network are further trained, enabling the topic generation model to learn to perform targeted correction of abnormal lexicals without changing the hierarchical and citation relationships of lexicals. After this training, the model can not only generate a complete lexical value set for the first time, but also perform more stable secondary generation of abnormal lexicals after receiving correction information.

[0114] In the actual reasoning process, structural constraint information is first converted into a lexical dependency graph and input into the constraint encoding network to obtain the lexical constraint features of each lexical. The topic generation instructions are input into the style semantic encoding network to obtain the topic style sub-features corresponding to the target style. The dependency propagation generation network determines the generation order of the root lexical and derived lexicals based on the lexical dependency graph, first generating the intermediate value features of the root lexical, and then propagating the intermediate value features of the generated lexicals to the derived lexicals along the reference relationship, gradually generating the intermediate value features of all derived lexicals. The lexical value decoding network converts the intermediate value features into lexical values ​​of the corresponding format according to the lexical type, finally forming the in-vehicle topic lexical value set. Thus, the data processing process inside the topic generation model can form a complete closed loop from structural constraints, style semantics, dependency propagation to typed decoding, so that the generated result not only conforms to the target style, but also maintains the lexical hierarchy and reference relationship in the design token template.

[0115] In practical implementation, before structural constraint information enters the constraint encoding network, it can be organized into a lexical dependency graph with lexical nodes and reference relationships and hierarchical relationships as edges. The initial node vector of each lexical node can be formed by concatenating multiple types of encoding: structural position can be encoded according to hierarchical path, for example, splitting "theme / color / primary / light" (i.e., theme, color, primary and secondary relationships, and brightness) into hierarchical sequences and superimposing hierarchical depth encoding; value type can be represented by type embedding, for example, color, size, font, rounded corner, and shadow classes correspond to different type vectors; reference input and reference output relationships can generate adjacency features based on the incoming and outgoing edges in the lexical dependency graph; the value constraint range can be normalized into numerical boundary features according to lexical type. Taking the size lexical as an example, if the template already has a reference value of 16px and no separate upper and lower limits are configured, 0.5 to 2 times the reference value can be taken as an exemplary value range, i.e., 8px to 32px; if the template has already configured minimum and maximum values, the template configuration is preferred. Color-related terms can be converted from hexadecimal color values ​​into three normalized components: hue, saturation, and brightness. Shadow-related terms can be decomposed into horizontal offset, vertical offset, blur radius, diffusion radius, and transparency components. After obtaining the above node vectors and edge relationships, the constraint coding network can use a graph attention layer to aggregate the information of adjacent terms, so that the constraint features of each term simultaneously carry its own type, its level, upstream reference source, and downstream influence range. The resulting term constraint features do not represent specific term values, but rather represent the structural boundaries and value boundaries that cannot be broken during generation.

[0116] After the theme generation instructions enter the style semantic encoding network, they are first converted into a sequence of text fragments, and then the semantic vector is extracted by the Transformer-based text encoder. For instructions such as "dark tech style," "sporty high-contrast style," and "brand blue low-brightness theme," the text encoder can capture the relationships between color tendency, brightness tendency, usage scenario, and style modifiers, respectively. Subsequently, several style projection branches can be set to map the overall semantic vector into theme style sub-features corresponding to different word types. For example, color-related theme style sub-features focus on expressing hue range, warm / cool tendency, brightness tendency, and saturation tendency; size-related theme style sub-features focus on expressing interface density, font size hierarchy, and white space tendency; effect-related theme style sub-features focus on expressing shadow strength, transparency level, and visual weight. If the theme generation instructions contain explicit color descriptions, such as "main color leaning towards blue," the reference hue range corresponding to blue can be used as additional input and incorporated into the color-related theme style sub-features; if no explicit color description is included, the text encoder generates a latent style vector based on the color distribution corresponding to similar style instructions in the training samples. Those skilled in the art can choose BERT, RoBERTa, or other Transformer text encoders based on the size of the training corpus and deployment resources, as long as they can stably convert topic generation instructions into stylistic semantic features that can participate in lexical generation.

[0117] When generating intermediate value features, the dependency propagation generative network can establish a generation queue according to the reference direction in the lexical dependency graph. Lexical elements such as primary color, base font size, and base spacing, which have no value dependencies, can enter the front of the queue. Lexical elements such as light color level, dark color level, button selected state color, line height, and paragraph spacing, which depend on upstream lexical elements, enter the subsequent positions after the corresponding upstream lexical elements have completed the generation of intermediate value features. The intermediate value features of the root lexical element can be obtained by fusing lexical constraint features and corresponding theme style sub-features through cross-attention. The intermediate value features of derived lexical elements further incorporate the intermediate value features of upstream lexical elements and reference edge type features, so that the derived results retain the association with the upstream lexical elements. For example, after the primary color lexical element is generated, the light color level lexical element can be superimposed with the "lightened derivation" edge feature on the primary color intermediate value features, the dark color level lexical element can be superimposed with the "deepened derivation" edge feature, and the button selected state background lexical element can be superimposed with the "component state mapping" edge feature. After receiving all intermediate value features, the lexical value decoding network enters different decoding branches according to type: the color branch outputs hue, saturation, and brightness, and converts them into hexadecimal color values ​​or RGB values ​​that can be recognized by the vehicle-mounted device; the size branch outputs positive numerical values ​​and combines them with unit fields to form px, dp, or sp formats; the effect branch outputs combined parameters such as offset, blur radius, and transparency. When the decoding result exceeds the value constraint range, boundary truncation or normalization inverse transformation can be used to fall back to the constraint range. For example, transparency is limited to between 0 and 1, and corner rounding values ​​are limited to the template configuration range. After the above processing, the target style is not directly written into the interface in the form of unstructured text, but is transformed layer by layer into vehicle-mounted theme lexical values ​​constrained by lexical structure, reference path, and value boundaries.

[0118] Next, we will further elaborate on the technical aspects of the verification method in this application.

[0119] In one example, the method further includes validating the set of vehicle-mounted topic meta-values, the validation including:

[0120] The set of vehicle-mounted topic lexical values ​​is subjected to lexical validity verification, which includes at least lexical value legality verification and lexical reference consistency verification.

[0121] When the vehicle-mounted topic lexical value set contains abnormal lexicals that fail the lexical validity check, correction information is generated based on the abnormal lexicals and the reasons for the failure of the check, and the correction information is fed back to the preset topic generation model so that the preset topic generation model can correct the abnormal lexicals and obtain a vehicle-mounted topic lexical value set that passes the check.

[0122] During the specific verification process, the set of vehicle-mounted thematic term values ​​can first be converted into a unified verification table. Each row in the verification table corresponds to a term and carries the term identifier, term type, current value, unit, level, referencing object, and referenced object. For color-related terms, it can first be determined whether they can be parsed into valid hexadecimal color values, RGB color values, or HSL color values. For example, hexadecimal color values ​​should meet the format requirements of #RRGGBB or #AARRGGBB, RGB channel values ​​should fall between 0 and 255, and the transparency channel value can be normalized to between 0 and 1. For size-related terms, we can determine whether they are positive numbers and set exemplary ranges based on in-vehicle interface display experience. For example, font size terms can be limited to 10sp to 48sp, spacing terms to 0dp to 128dp, and rounded corner terms to 0dp to 64dp. If the design token template already provides reference values, we can also generate a verification range according to the preset multiplier of the reference values. For example, when the base font size is 16sp, 8sp to 32sp can be used as the acceptable range for related terms. For shadow or effect-related terms, we can determine whether sub-parameters such as offset, blur radius, diffusion radius, and transparency are complete and within a valid range. For example, transparency values ​​can be limited to 0 to 1, and blur radius can be limited to non-negative numbers.

[0123] For color-related terms, readability can be further verified by combining the foreground and background color mapping relationship of the in-vehicle interface components.

[0124] For example, when there are paired relationships in the mapping, such as text color-background color, icon color-button background color, or warning text color-popup background color, the contrast ratio between the two can be calculated. During calculation, the color values ​​can first be converted to linear RGB values, then the foreground and background brightness can be obtained according to the relative brightness formula, and the contrast ratio can be obtained by adding 0.05 to the higher brightness value and dividing by adding 0.05 to the lower brightness value. For ordinary text, 4.5:1 can be used as an example passing threshold; for larger font sizes of title text or icon-type display objects, 3:1 can be used as an example passing threshold. The above thresholds can be adjusted according to automotive HMI display specifications, night mode requirements, or enterprise design specifications. For example, if a text color term is #777777 and the background color term is #FFFFFF, and the contrast ratio obtained after brightness conversion is lower than 4.5:1, then the text color term can be marked as having abnormal contrast; if the text color is only used for large titles, and the corresponding component style is marked as a large font scene, then a 3:1 threshold can be used for judgment.

[0125] Reference consistency checks can be performed based on reference dependencies in structural constraint information. Specifically, it can first check whether the target term pointed to by each referenced term exists, and then check whether the term types of the two referencing terms match. For example, color terms should not refer to size terms, and rounded corner terms should not refer to shadow terms. For derived terms, it can also check whether its upstream root term has generated a valid value. If there are missing nodes, inconsistent types, circular references, or out-of-bounds reference levels in the reference chain, the corresponding terms can be marked as reference aberration terms. When generating correction information, the aberration term identifier, current value, aberration type, expected value type, acceptable value range, and related reference objects can be organized into structured correction content. For example, for terms with incorrect color value formats, the correction information can instruct the generation model to output a valid color format; for terms with insufficient contrast, the correction information can instruct to increase the brightness difference between the foreground and background colors while maintaining the target style and reference relationship; for terms with missing reference objects, the correction information can instruct the generation model to restore the corresponding reference object or change to referencing a valid term of the same type.

[0126] In one example, the method for generating the correction information includes:

[0127] Based on the validation results of the word validity check, identify the abnormal words that failed the validation and the reasons for the validation failure of the abnormal words.

[0128] Based on the lexical type, current value, and reason for failure of the verification of the abnormal lexical, determine the correction constraint corresponding to the abnormal lexical;

[0129] Based on the abnormal lexical terms, the reasons for the failed verification, and the correction constraints, correction information is generated.

[0130] It is understood that the generation of correction information can refer to existing rule engine processing methods, structured prompt word construction methods, or JSON Schema-based data template encapsulation methods. This involves writing the abnormal lexical identifier, abnormal type, current value, expected value type, value constraint range, and reason for failure to the preset correction template, forming a structured correction instruction that can be recognized by the preset topic generation model. Those skilled in the art can generate correction information based on the input format of the topic generation model, using methods such as key-value pair field concatenation, natural language prompt word concatenation, or structured data object encapsulation. The goal is simply to enable the preset topic generation model to recognize the lexical to be corrected, the reason for correction, and the correction boundary. This application's embodiments do not elaborate on this aspect.

[0131] It should be noted that the specific method for correcting the in-vehicle topic lexical value set based on the correction information can also refer to existing technologies such as large language model instruction feedback correction, constraint prompt word regeneration, and structured output constraints. For example, the correction information can be used as additional context input to a preset topic generation model, allowing the preset topic generation model to regenerate the corresponding lexical values ​​based on abnormal lexicals, reasons for verification failure, and correction constraints. Those skilled in the art can implement the above feedback correction using natural language instructions, structured key-value pairs, function call parameters, or prompt word templates, depending on the interface of the preset topic generation model; this application embodiment will not elaborate on this.

[0132] However, it's important to note that existing large language model feedback correction methods are typically applied to correction scenarios involving plain text, code snippets, or single structured fields, with relatively independent correction targets. In contrast, the in-vehicle topic lexical value set in this application possesses unique characteristics, including hierarchical relationships, dependency relationships, and mapping relationships between in-vehicle interface components. Correcting an abnormal lexical may affect its downstream derived lexicals and the theme style assembly effects of multiple in-vehicle interface components. Therefore, in the specific correction process, it's not simply required that the pre-defined theme generation model regenerate the entire in-vehicle topic lexical value set. Instead, based on the abnormal lexical's position in the lexical dependency graph, the cause of the abnormality, and the affected scope, methods such as local correction, association propagation correction, or constraint enhancement correction can be employed.

[0133] In one optional implementation, a local correction method for abnormal lexical units can be used. Specifically, after identifying abnormal lexical units, lexical units that have passed verification and have no reference propagation relationship with the abnormal lexical units are marked as locked lexical units. The correction information carries the lexical unit identifier and current value of the locked lexical units, so that the preset topic generation model keeps the locked lexical units unchanged during the correction process and only outputs the corrected value corresponding to the abnormal lexical units. For example, if the value of a rounded corner lexical unit is negative or lacks a display unit, and the rounded corner lexical unit is not referenced by other lexical units, then only a valid positive size value and corresponding unit can be generated for the rounded corner lexical unit.

[0134] In another optional implementation, an association-based correction method can be used. Specifically, when an abnormal word element belongs to the root word element or is referenced by multiple derived words element, the range of downstream related words element corresponding to the abnormal word element can be determined according to the word element dependency graph, and the abnormal word element and its downstream related words element are collectively used as the set of words element to be corrected. For example, if the main color word element is marked as abnormal because the contrast is insufficient after combining with the background color, not only the main color word element itself can be corrected, but also the light color level, dark color level, button selected state background color, and other words element derived from the main color word element can be corrected simultaneously, so that the corrected derived words element still maintain a color system consistent with the main color word element.

[0135] In another optional implementation, a constraint enhancement correction method can be adopted. Specifically, the reasons for failing the validation can be converted into more explicit generation boundaries and written into the correction information, so that the preset topic generation model has a clear correction direction when regenerating. For abnormal value ranges, the minimum, maximum, and unit format allowed for the corresponding lexical can be written into the correction information; for abnormal citation consistency, the types of citationable candidate lexicals and candidate lexical identifiers can be written; for abnormal color contrast, the foreground lexicals, background lexicals, and target contrast requirements can be written, and the model can be instructed to increase the brightness difference or adjust the brightness level while maintaining the target style tendency.

[0136] In one example, the method for generating the data for the in-vehicle theme interface includes:

[0137] Obtain the preset mapping relationship between lexical elements and in-vehicle interface components. The mapping relationship includes lexical identifiers, component identifiers, and style attribute identifiers corresponding to the component identifiers.

[0138] Based on the identifiers of each term in the set of vehicle-mounted thematic term values, the target vehicle-mounted interface components and target style attributes corresponding to each term are determined in the mapping relationship.

[0139] Based on the lexical value corresponding to each lexical, the target vehicle interface component, and the target style attribute, a component style configuration item is generated. The component style configuration item is used to represent the corresponding style attribute of the corresponding lexical value to the corresponding vehicle interface component.

[0140] The in-vehicle theme interface generation data is obtained based on multiple component style configuration items.

[0141] In yet another example, the generation method of the theme style assemblies includes:

[0142] The vehicle theme interface generator receives the vehicle theme interface generation data and parses it to obtain multiple component style configuration items;

[0143] Based on the component identifier in each component style configuration item, determine the vehicle interface component to be installed in the preset vehicle interface template;

[0144] Based on the style attribute identifier in the style configuration items of each component, the corresponding lexical value is written into the style attribute slot of the vehicle interface component to be assembled.

[0145] Based on the component hierarchy in the preset vehicle interface template, the vehicle interface components with completed style attributes are assembled to generate the target vehicle theme interface.

[0146] It is understandable that the mapping relationship between lexical terms and in-vehicle interface components can be implemented by referring to the style binding table, resource index table, or theme variable mapping table in existing component-based interface development. For example, in common interface rendering frameworks, interface components such as buttons, cards, navigation bars, pop-ups, and text labels usually have style attribute slots that can be configured externally. Theme variables such as color, font size, rounded corners, spacing, and shadow can be written into the corresponding slots through component identifiers and attribute identifiers. In this embodiment, the above-mentioned mature style binding concept can be applied to the conversion process between in-vehicle theme lexical terms and in-vehicle interface components, and the set of in-vehicle theme lexical values ​​can be organized into component style configuration items. Component style configuration items can be expressed in a structured data form, such as containing fields such as page identifier, component identifier, component status identifier, style attribute identifier, lexical identifier, and lexical value. When the same lexical term applies to multiple components, it can be split into multiple component style configuration items according to the mapping relationship; when the same component depends on multiple lexical terms, multiple style attribute configuration items can be generated for the same component. The resulting in-vehicle theme interface generation data has essentially been transformed from word-level theme data into component-level assembly data. The in-vehicle theme interface generation end does not need to re-understand the word level and referencing logic; it only needs to parse according to the component identifier and style attribute identifier.

[0147] The theme style assembly process can be implemented by referring to existing technologies such as templated interface rendering, component tree rendering, and hot updating of theme resources. After receiving the vehicle theme interface generation data, the in-vehicle interface generator can parse the preset in-vehicle interface template into a component tree. Each node in the component tree corresponds to an in-vehicle interface component, and each node has reserved style attribute slots such as background color, text color, font size, margin, rounded corners, shadow, and transparency. When parsing the component style configuration items on the client side, the target node in the component tree can be located according to the component identifier, and then the meta-values ​​can be written into the corresponding slots of the target node according to the style attribute identifiers. If the component style configuration items include component state identifiers such as default state, selected state, disabled state, and pressed state, the corresponding meta-values ​​can be written into the style slots of the corresponding state. After writing is completed, the client side can combine and render according to the original component hierarchy of the in-vehicle interface template to form the target in-vehicle theme interface. Those skilled in the art can choose QML, HTML / CSS, Flutter, Android resource files or other component-based rendering methods to carry out the above assembly process according to the specific terminal rendering environment. As long as the theme style can be written according to the component identifier, attribute identifier and lexical value, and the interface components can generate the final display result according to the template hierarchy, the embodiments of this application do not impose further limitations on this.

[0148] Example 2:

[0149] Building upon the vehicle-themed lexical value set generated and lexical validity verified in Example 1, this application further provides a local correction method for anomalous lexical elements. The vehicle-themed lexical value set typically includes color, font size, spacing, rounded corners, shadow, transparency, and style lexical elements for different component states. Many of these lexical elements are not used in isolation but rather work together on the vehicle-themed interface through referencing, derivation, or component mapping relationships. For example, the primary color lexical element may simultaneously affect the selected state of the navigation bar, button background, on / off state of the switch, and the highlighted area of ​​the progress bar; the text color lexical element may simultaneously affect the title text, body text, pop-up text, and auxiliary prompt text; and the base font size lexical element may further affect line height, paragraph spacing, and component rounded corners. Therefore, although an anomalous lexical element may appear as a local anomaly in the verification results, its correction action may continue to spread along the lexical reference chain and component mapping chain.

[0150] If the complete set of in-vehicle theme lexical values ​​is directly re-inputted into the theme generation model for full correction after anomaly lexical is detected, it can easily cause value drift of lexical values ​​that have already passed verification. For example, if there is insufficient contrast between the button text color and the button background color, if the theme generation model readjusts the primary color lexical, it may cause normally functioning lexical values ​​such as the navigation bar highlight color, switch activation color, and progress bar color to change synchronously. If the entire set of text color lexical values ​​is readjusted, it may affect the visual hierarchy of warning prompts, driving assistance prompts, or status bar text. For in-vehicle theme interfaces, the above drift not only disrupts the overall consistency of the theme but may also affect the recognition stability of driving-related components, warning components, or currently displayed components. Therefore, this application embodiment does not interpret anomaly correction as a simple "regeneration," but first determines the range of lexical values ​​that must be affected by the anomaly correction, and then feeds back the limited correction information to the theme generation model.

[0151] In this embodiment, the aforementioned restricted lexical range can be referred to as the minimum correction propagation domain. The minimum correction propagation domain is used to characterize the set of lexical units that are allowed to be modified in order to eliminate the reasons for the failure of the verification corresponding to the abnormal lexical unit. Here, "minimum" does not require an exhaustive comparison of all lexical unit combinations, but rather refers to prioritizing the selection of a set of lexical units that have a lower impact on the verified lexical units, less disturbance to high-priority in-vehicle interface components, and less damage to the overall theme style within the candidate range that can eliminate the current anomaly.

[0152] In practice, abnormal tokens and their corresponding reasons for failure can be determined first based on the token validity verification results. Abnormal tokens may include tokens with invalid value formats, tokens exceeding the value range, tokens with non-existent reference objects, tokens with mismatched reference types, tokens with insufficient foreground-background contrast, or tokens whose proportional relationship with other tokens in the same group does not meet preset requirements. The reasons for failure can further characterize the nature of the abnormality, such as incorrect color format, out-of-bounds size values, broken reference chains, unreadable foreground-background combination, reversed spacing levels within the same group, and conflicting component state styles. Those skilled in the art will understand that abnormal types can be added or removed according to the vehicle theme verification rules, as long as they can minimally indicate why the corresponding tokens cannot be directly used to generate vehicle theme interfaces; this application does not impose further limitations.

[0153] To determine the propagation boundary of anomaly correction, a lexical dependency graph can be constructed based on the reference relationships between lexical values ​​in the in-vehicle topic lexical value set. Nodes in the lexical dependency graph correspond to in-vehicle topic lexical elements, and connections between nodes represent reference, derivation, or linkage relationships. For example, a primary color lexical element can be connected to primary color light level lexical elements, primary color dark level lexical elements, button selected state background lexical elements, and navigation highlight lexical elements; a base font size lexical element can be connected to title line height lexical elements, body text line height lexical elements, and paragraph spacing lexical elements; and a basic rounded corner lexical element can be connected to button rounded corner lexical elements, card rounded corner lexical elements, and pop-up rounded corner lexical elements. Through this lexical dependency graph, it is possible to determine whether the anomalous lexical element is upstream, midstream, or downstream of the reference chain, and also to determine which derived lexical elements might be affected after correcting a candidate lexical element.

[0154] In addition to the lexical dependency graph, a component action graph can be constructed based on the mapping relationship between the in-vehicle theme lexical value set and in-vehicle interface components. The component action graph represents which in-vehicle interface components the lexical values ​​are written to, which style attributes they affect, and which component states they correspond to. For example, the primary color lexical can be applied to the selected navigation bar icon, button background, progress bar highlighted area, and switch on / off state; the text color lexical can be applied to title text, body text, auxiliary explanatory text, and pop-up prompt text; and the warning color lexical can be applied to warning icons, fault prompt text, and dangerous operation confirmation buttons. The component action graph can also record the display priority of in-vehicle interface components. Driving-related prompt components, warning components, navigation guidance components, and core operation components on the currently displayed page can have higher display priority, while entertainment components, decorative components, or components on pages not currently displayed can have lower display priority.

[0155] After identifying the anomalous terms and the reasons for the validation failure, an initial correction candidate domain can be formed in the term dependency graph. For anomalous value formats or value ranges, the initial correction candidate domain can preferentially include the anomalous term itself; for missing reference objects or mismatched reference types, the initial correction candidate domain can include the anomalous term and its referenced input term; for anomalous foreground / background contrast, the initial correction candidate domain can include foreground color terms, background color terms, and their respective direct source terms; for anomalous proportions within the same group, the initial correction candidate domain can include level terms adjacent to the anomalous term in the same font size group, spacing group, or rounded corner group; for conflicting component state styles, the initial correction candidate domain can include state terms corresponding to the same component in the default, selected, disabled, or pressed states. Through this method, anomalous correction is limited from the outset to a candidate range directly technically related to the anomalous term.

[0156] Furthermore, the initial correction candidate domain can be mapped to the component action graph, and the initial correction candidate domain can be narrowed according to the actual component action scope of the candidate term. Specifically, the correction cost of the candidate term can be determined based on the number of components affected by the candidate term, the component display priority, the current visibility state of the component, and whether the candidate term has passed the prior validation. The more components affected by the candidate term, or the higher the priority components such as driving-related prompts, warning prompts, and navigation guidance, the higher its correction cost; the correction cost can be relatively low if the candidate term only affects low-priority components, components not displayed on the page, or local decorative attributes. For terms that have passed validation and are stably referenced by multiple components, the correction cost can also be increased to avoid repeated perturbation.

[0157] For example, there might be insufficient contrast between the button text color and the button background color, and the button background color is derived from the primary color terminology and further affects navigation highlights, switch on / off status, and progress bar highlight areas. In this case, directly modifying the primary color terminology would cause multiple components to change synchronously, resulting in high correction costs. If the button text color only affects ordinary button text and does not handle high-priority display tasks such as alarm prompts or navigation guidance, then the button text color terminology can be prioritized and included in the minimum correction propagation domain, with the primary color terminology used as the boundary reference terminology. This corrects local contrast anomalies in the button while avoiding large-scale rewriting of the primary color system. Conversely, if the button text color is also referenced by alarm prompt text, and the button background color only affects ordinary button backgrounds, then the button background color or its derived color levels can be corrected first to protect the visual stability of the alarm prompt text.

[0158] Based on the initial correction candidate domain and correction cost, correctable lexical units can be further divided into correctable lexical units, boundary-constrained lexical units, and locked lexical units. Correctable lexical units belong to the minimum correction propagation domain, allowing the topic generation model to output new lexical values; boundary-constrained lexical units have reference connections or style associations with correctable lexical units, but cannot be modified, serving only as reference context during model correction; locked lexical units have no necessary correction relationship with the current anomaly and have already passed verification, maintaining their original values ​​during the correction process. This division of lexical units into three categories transforms the anomaly correction process into a local generation process with boundary conditions, rather than an unconstrained global regeneration process.

[0159] Correction information can be generated jointly based on anomalous terms, reasons for validation failure, minimum correction propagation domain, boundary constraint terms, and locked terms. Correction information may include anomalous term identifiers, anomaly type, current anomaly value, a list of allowed correction terms, a list of prohibited modification terms, a list of boundary reference terms, target validation conditions, and output range requirements. For example, correction information could instruct the topic generation model: the current anomaly is insufficient contrast between the button text color and the button background color; correction of the button text color term and its directly derived terms is allowed; modification of the main color term, background color term, and warning color term is not allowed; the corrected button text color should maintain a consistent style with the ordinary text color group; and the output should only contain the new values ​​of allowed correction terms. Through this correction information, the content fed back to the topic generation model is no longer a generalized error message, but a structured instruction with correction boundaries, reference objects, and stability requirements.

[0160] After receiving correction information, the topic generation model generates new lexical values ​​only for correctable lexical units within the minimum correction propagation domain. For boundary-constrained lexical units, the model can read their values, types, and hierarchical relationships as correction references but does not output replacement values. For locked lexical units, the model maintains their original values ​​during the correction process. After the corrected lexical values ​​are generated, the correction results can be backfilled into the original in-vehicle topic lexical value set. During backfilling, only the values ​​of the corresponding lexical units within the minimum correction propagation domain are overwritten; lexical units outside the minimum correction propagation domain retain their original values. Therefore, abnormal correction results can be re-merged with the original in-vehicle topic lexical value set without forming a new full set of lexical values.

[0161] The refilled set of vehicle-side thematic lexical values ​​can be validated again. If the reasons for the validation failure corresponding to the abnormal lexical have been eliminated, and no new value validity exceptions, reference consistency exceptions, or component style conflicts have been introduced, then the refilled set of vehicle-side thematic lexical values ​​can be used as the set of valid lexical values. If exceptions still exist, the minimum correction propagation domain can be redefined based on the new abnormal lexical and the new reasons for validation failure. When redefining the minimum correction propagation domain, it is not necessary to directly expand to the complete lexical set. Instead, based on the minimum correction propagation domain of the previous round, a local expansion can be made according to the reference relationships of the newly added exceptions and the scope of component application, so that the correction process gradually converges.

[0162] In one optional implementation, the determination of the minimum correction propagation domain can also be combined with the current display state of the vehicle terminal. The vehicle terminal can return the current page identifier, the currently visible components, the current component status, or the current driving scenario identifier. If the abnormal term only affects the currently invisible page, a relatively lenient correction range can be allowed; if the abnormal term affects the currently displayed driving-related components, then terms that cause less disturbance to the currently visible area are preferentially selected as correctable terms. For example, during vehicle operation, terms related to navigation guidance, warning prompts, and driving assistance prompts can be assigned higher stability weights; when the vehicle is parked or in a development / debugging state, ordinary theme preview components can allow for a larger correction space.

[0163] After adopting the above method, the correction of in-vehicle theme lexicals is transformed from full regeneration to constrained local correction. Since the structural propagation relationships between lexicals have been determined using a lexical dependency graph before correction, and the actual display impact of lexicals in in-vehicle interface components has been determined using a component action graph, the correction process considers both the referencing logic between lexicals and the visual stability of the assembled edge components. For lexicals that have passed verification and are stably applied to multiple components, they can be locked to prevent further modification; for lexicals that have necessary stylistic associations with abnormal lexicals but are not suitable for modification, they can participate in the correction reference through boundary constraints. Therefore, while eliminating local anomalies, the style consistency of the entire in-vehicle theme and the visual hierarchy stability of components can be maintained as much as possible.

[0164] The aforementioned local correction method is particularly suitable for generating vehicle-mounted themes with multiple components, states, and multi-device displays. Since vehicle-mounted theme lexical units are typically reused by multiple components, simply correcting a single outlier may disrupt the style of the downstream reference chain, while simply regenerating the complete lexical set may disrupt the already stable theme structure. This application's embodiments limit the modifiable range of the model through a minimum correction propagation domain, creating a technical closed loop in the outlier correction process that is traceable, backfillable, and verifiable. This reduces irrelevant lexical drift during the theme generation model correction process, lowers the probability of validated lexical units being corrupted a second time, and improves the stability of the vehicle-mounted theme interface in real-time push and edge-mounted assembly scenarios.

[0165] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for generating theme data for the assembly of vehicle interface components, characterized in that, The method includes: The acquired structural constraint information and topic generation instructions are input into a preset topic generation model so that the preset topic generation model generates a set of vehicle topic lexical values ​​corresponding to the target style while keeping the lexical hierarchy and citation relationships unchanged. Based on the mapping relationship between the in-vehicle theme term value set and the in-vehicle interface components, the in-vehicle theme interface generation data is obtained; The vehicle theme interface generation data is pushed to the vehicle theme interface generation terminal, so that the vehicle theme interface generation terminal can assemble the theme style of the corresponding vehicle interface components according to the vehicle theme interface generation data to generate the target vehicle theme interface.

2. The method for generating theme data for vehicle interface component assembly according to claim 1, characterized in that, The methods for obtaining the structural constraint information include: Obtain the design token template data corresponding to the vehicle theme. The design token template data includes the lexical identifiers, lexical types, lexical hierarchical relationships, and reference relationships between multiple design tokens. The theme generation instruction is used to characterize the target style of the vehicle theme interface to be generated. The lexical structure constraint information is determined based on the design token template data. The lexical structure constraint information is used to limit the structural position, value type, and reference dependency relationship of each lexical.

3. The method for generating theme data for vehicle interface component assembly according to claim 1, characterized in that, The topic generation model includes a constraint encoding network, a style semantic encoding network, a dependency propagation generation network, and a lexical value decoding network, wherein: The constraint coding network is used to encode the lexical hierarchy relationship, value type, and reference dependency relationship in the structural constraint information to obtain lexical constraint features; The style semantic coding network is used to semantically encode the style keywords, color tendencies and application scenarios in the theme generation instructions to obtain theme style features; The dependency propagation generation network is used to determine the word generation order according to the word constraint features and the topic style features, and to generate derived word values ​​along the corresponding reference dependencies after generating the root word value. The lexical value decoding network is used to decode the root lexical value and derived lexical value according to the value type of each lexical, and output the vehicle-mounted topic lexical value set.

4. The method for generating theme data for vehicle interface component assembly according to claim 3, characterized in that, The generation of the vehicle-mounted topic meta-value set corresponding to the target style includes: The structural constraint information is input into the constraint coding network. The constraint coding network encodes the structural position, value type, reference input relationship, reference output relationship, and value constraint range of each word. The encoding results are then fused to obtain the word constraint features corresponding to each word. The topic generation instruction is input into the style semantic encoding network. The style semantic encoding network extracts the style semantic features corresponding to the target style from the topic generation instruction, and generates topic style sub-features corresponding to color-related words, size-related words, and effect-related words, respectively, based on the style semantic features. The lexical constraint features corresponding to each lexical and the topic style sub-features are input into the dependency propagation generation network. The dependency propagation generation network determines the root lexical that does not depend on the values ​​of other lexicals and the derived lexical that depends on the values ​​of other lexicals based on the reference input relationship and reference output relationship represented in the lexical constraint features. It also determines the lexical generation order from the root lexical to the derived lexical and generates the intermediate value features of the root lexical and the intermediate value features of the derived lexical. The intermediate value features of the root word and the intermediate value features of the derived word are input into the word value decoding network. The word value decoding network performs type-based decoding on the intermediate value features of each word according to the value type and value constraint range of each word to obtain the word value corresponding to each word.

5. The method for generating theme data for vehicle interface component assembly according to claim 4, characterized in that, The methods for generating the intermediate value features include: Based on the lexical constraint features corresponding to the root lexical and the topic style sub-features corresponding to the value type of the root lexical, intermediate value features of the root lexical are generated. According to the word generation order, the intermediate value features of the generated word are propagated to the derived word with which it has a reference relationship, and the intermediate value features of the derived word are generated by combining the word constraint features corresponding to the derived word and the corresponding theme style sub-features.

6. The method for generating theme data for vehicle interface component assembly according to claim 1, characterized in that, The method further includes validating the set of vehicle-mounted topic terminology values, the validation including: The set of vehicle-mounted topic lexical values ​​is subjected to lexical validity verification, which includes at least lexical value legality verification and lexical reference consistency verification. When the vehicle-mounted topic lexical value set contains abnormal lexicals that fail the lexical validity check, correction information is generated based on the abnormal lexicals and the reasons for the failure of the check, and the correction information is fed back to the preset topic generation model so that the preset topic generation model can correct the abnormal lexicals and obtain a vehicle-mounted topic lexical value set that passes the check.

7. The method for generating theme data for vehicle interface component assembly according to claim 6, characterized in that, The methods for generating the correction information include: Based on the validation results of the word validity check, identify the abnormal words that failed the validation and the reasons for the validation failure of the abnormal words. Based on the lexical type, current value, and reason for failure of the verification of the abnormal lexical, determine the correction constraint corresponding to the abnormal lexical; Based on the abnormal lexical terms, the reasons for the failed verification, and the correction constraints, correction information is generated.

8. The method for generating theme data for vehicle interface component assembly according to claim 1, characterized in that, The methods for generating the data for the in-vehicle theme interface include: Obtain the preset mapping relationship between lexical elements and in-vehicle interface components. The mapping relationship includes lexical identifiers, component identifiers, and style attribute identifiers corresponding to the component identifiers. Based on the identifiers of each term in the set of vehicle-mounted thematic term values, the target vehicle-mounted interface components and target style attributes corresponding to each term are determined in the mapping relationship. Based on the lexical value corresponding to each lexical, the target vehicle interface component, and the target style attribute, a component style configuration item is generated. The component style configuration item is used to represent the corresponding style attribute of the corresponding lexical value to the corresponding vehicle interface component. The in-vehicle theme interface generation data is obtained based on multiple component style configuration items.

9. The method for generating theme data for vehicle interface component assembly according to claim 8, characterized in that, The generation methods for the theme style assembly include: The vehicle theme interface generator receives the vehicle theme interface generation data and parses it to obtain multiple component style configuration items; Based on the component identifier in each component style configuration item, determine the vehicle interface component to be installed in the preset vehicle interface template; Based on the style attribute identifier in the style configuration items of each component, the corresponding lexical value is written into the style attribute slot of the vehicle interface component to be assembled. Based on the component hierarchy in the preset vehicle interface template, the vehicle interface components with completed style attributes are assembled to generate the target vehicle theme interface.

10. A theme data generation system for vehicle interface component assembly, used to implement the theme data generation method for vehicle interface component assembly as described in any one of claims 1-9, characterized in that, The system includes: The topic lexical generation module is used to input the acquired structural constraint information and topic generation instructions into a preset topic generation model, so that the preset topic generation model generates a set of vehicle topic lexical values ​​corresponding to the target style while keeping the lexical hierarchy and reference relationship unchanged. The interface data generation module is used to obtain vehicle theme interface generation data based on the mapping relationship between the vehicle theme term value set and the vehicle interface components. The real-time push assembly module is used to push the vehicle theme interface generation data to the vehicle theme interface generation end, so that the vehicle theme interface generation end can assemble the theme style of the corresponding vehicle interface components according to the vehicle theme interface generation data and generate the target vehicle theme interface.

Images