Zero-code worksheet dynamic generation method based on natural language and related equipment

Abstract

The invention provides a natural language-based zero-code worksheet dynamic generation method and related equipment, and the method comprises the steps: carrying out the semantic recognition of the content setting information and name of a table inputted by a user, so as to judge the industry to which a worksheet to be generated belongs; according to the method and the system, the corresponding worksheet structure template is extracted from the pre-constructed industry knowledge base, the worksheet structure template is optimized and adjusted in combination with the table content setting information input by the user, the worksheet structure meeting the requirements of the user can be generated, a high-quality worksheet can be generated through AI technologies such as deep learning and natural language processing, and the user experience is improved. According to the method, the diversified requirements of users are met, the worksheets meeting the requirements of the users are automatically generated, the time and energy of manually defining fields and sheet structures by the users are reduced, the error rate of manual operation is reduced, the accuracy and consistency of the worksheets are improved, and the working efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of information processing technology, and in particular to a method and related equipment for dynamic generation of zero-code worksheets based on natural language. Background Technology

[0002] With the development of low-code or no-code technologies, existing no-code platforms generally possess visual operation capabilities. They provide graphical user interfaces that allow users to create applications by dragging and dropping components and configuring parameters, eliminating the need for writing underlying code and significantly lowering the technical barrier to application development. These platforms are widely used in enterprise office and data management scenarios. In the development of data management applications, worksheets serve as the core data carrier, and the construction of their table structure is a crucial step. However, current no-code platforms still rely on a manual configuration-dominated approach for worksheet generation. Users must manually design table structures, set field attributes, and define inter-table relationships through the platform's configuration interface. This approach has significant technical bottlenecks, limiting the platform's usability, adaptability, and intelligence. It is highly complex and has a significant technical barrier. Existing solutions require users to have basic knowledge of table structure design and manually complete operations such as field naming, data type selection, mandatory field settings, uniqueness constraint configuration, and defining inter-table relationships. For users without a technical background, this configuration involves fundamental database design logic, presenting a high learning curve and operational barrier, and can easily lead to subsequent data management chaos due to improper configuration. Furthermore, existing technologies lack flexibility in industry adaptation, have limited template reusability, lack intelligent generation capabilities, and are insufficiently adaptable to professional scenarios. Current technical solutions only support basic field generation based on simple text commands and cannot generate complex and professional field combinations and related logics in combination with industry characteristics and specific use cases. Therefore, they fail to truly achieve intelligent cost reduction and efficiency improvement. Summary of the Invention

[0003] This application aims to at least address one of the aforementioned technical deficiencies. In view of this, this application provides a method and related equipment for dynamically generating worksheets using no-code based on natural language, which addresses the technical deficiencies of the limited functionality of dynamically generating tables in existing no-code platforms.

[0004] A method for dynamically generating worksheets using no-code based on natural language, the method comprising: determining the attribute parameters of the target worksheet to be processed, wherein the attribute parameters of the target worksheet include the name, content setting information, and image data of the target worksheet to be generated; performing multi-dimensional cross-modal semantic fusion analysis on the attribute parameters of the target worksheet to determine the structured requirement information of the target worksheet corresponding to user needs; performing similarity matching analysis between the structured requirement information of the target worksheet and a preset dynamic industry knowledge graph, and calculating the matching degree between the structured requirement information of the target worksheet and each subgraph in the preset dynamic industry knowledge graph; determining at least one candidate industry subgraph corresponding to the structured requirement information of the target worksheet based on the matching degree between the structured requirement information of the target worksheet and each subgraph in the preset dynamic industry knowledge graph; and based on the determined... For each of the candidate industry subgraphs, an initial worksheet structure template is instantiated to obtain the target worksheet structure template. The target worksheet structure template includes the field definitions of each worksheet, the connection logic between the worksheet and the external data source, and cross-table reference formulas based on a preset dynamic industry knowledge graph relationship. The target worksheet structure template is presented to the user, and all user operations on the target worksheet structure template are captured. All user operations on the target worksheet structure template are dynamically analyzed, and the target worksheet structure template is dynamically optimized until the final target worksheet structure determined by the user is generated. After the user confirms the final target worksheet structure, the final target worksheet structure is presented to the user again, and the external data source corresponding to the target worksheet structure is automatically configured to generate a dynamic worksheet corresponding to the user's needs and displayed to the user.

[0005] Preferably, the step of performing multi-dimensional cross-modal semantic fusion analysis on the attribute parameters of the target table to determine the target worksheet structured requirement information corresponding to the user's needs includes: performing multi-dimensional cross-modal semantic fusion analysis on the attribute parameters of the target table to obtain the semantic analysis results of the target table; and determining the target worksheet structured requirement information corresponding to the user's needs based on the semantic analysis results of the target table.

[0006] Preferably, the step of performing multi-dimensional cross-modal semantic fusion analysis on the attribute parameters of the target table to obtain the semantic analysis result of the target table includes: performing deep semantic parsing on the name and content setting information of the worksheet to be generated, which are included in the attribute parameters of the target table, and extracting the business entities, intents, and logical constraints between fields of the worksheet to be generated as the text semantic analysis result of the target table; using a preset worksheet visual analysis model, analyzing the image data included in the attribute parameters of the target table, and extracting the header structure, data area, and table style features included in the attribute parameters of the target table as the text visual analysis result of the target table, wherein the preset worksheet visual analysis model is trained using the image data included in the attribute parameters of the target table as training samples, and using the header structure, data area, and table style features included in the image data included in the attribute parameters of the target table as sample labels; and aligning and fusing the text semantic analysis result of the target table with the text visual analysis result of the target table to generate the semantic analysis result of the target table.

[0007] Preferably, the preset worksheet visual analysis target table's attribute parameters include image data. The process of extracting the header structure, data area, and table style features included in the target table's attribute parameters includes: performing target detection and OCR recognition processing on the image data included in the target table's attribute parameters; jointly encoding the recognized text information with the control position information in the image data included in the target table's attribute parameters to determine the table's physical structure and logical hierarchy included in the target table's attribute parameters; and extracting the header structure, data area, and table style features included in the target table's attribute parameters based on the table's physical structure and logical hierarchy included in the target table's attribute parameters.

[0008] Preferably, the method further includes: crawling authoritative information from various industries in real time; extracting industry entity relationship information from the crawled authoritative information using a preset training language analysis model and constructing industry entity triples; and incorporating the industry entity triples into the original dynamic industry knowledge graph to update the preset dynamic industry knowledge graph in real time.

[0009] Preferably, incorporating the industry entity triples into the existing dynamic industry knowledge graph includes: mapping the entities and relations in the industry entity triples to the continuous vector space corresponding to the dynamic industry knowledge graph; finding the nearest subgraph to the structured requirement representation corresponding to the industry entity triples in the vector space and embedding it into the entities and relations in the industry entity triples.

[0010] Preferably, the method further includes: while generating the target worksheet structure finally determined by the user, generating a data lineage report corresponding to the target worksheet structure, wherein the data lineage report includes the source, calculation logic and the basis node in the dynamic industry knowledge graph of each field of the target worksheet structure.

[0011] A no-code worksheet dynamic generation system based on natural language is provided, applied to any of the aforementioned no-code worksheet dynamic generation methods based on natural language. The system includes: a multimodal input interface module, a cross-modal semantic fusion analysis module, a dynamic industry knowledge graph module, a graph neural network matching and processing module, a dynamic template generation module, an interaction optimization module, and a deployment module. The cross-modal semantic fusion analysis module includes a text analysis submodule, a visual analysis submodule, and a multimodal fusion submodule. The multimodal input interface module receives and processes user input data, determines the attribute parameters of the target table to be processed, and transmits them to the cross-modal semantic fusion analysis module. The attribute parameters of the target table include... The generated target worksheet includes its name, content settings, image data, and document data. User input methods include natural language text input, image input, document upload input, and voice input. The text analysis submodule uses a Transformer-based pre-trained language model to perform deep semantic parsing on the target table's attribute parameters, including the name and content settings of the worksheet to be generated. This includes named entity recognition, relation extraction, and intent classification. A multi-head attention mechanism is used to capture long-distance dependencies. The business entities, intents, and logical constraints between fields of the worksheet to be generated are extracted as the text semantic analysis results of the target table and transmitted to the multimodal fusion submodule. The visual analysis submodule utilizes preset... The worksheet visual analysis model analyzes the image data included in the attribute parameters of the target table, extracts the header structure, data areas, and table style features included in the attribute parameters of the target table as the text visual analysis result of the target table, and transmits it to the multimodal fusion submodule. The preset worksheet visual analysis model is trained using the image data included in the attribute parameters of the target table as training samples, and the header structure, data areas, and table style features contained in the image data included in the attribute parameters of the target table as sample labels. The multimodal fusion submodule, based on a cross-attention multimodal fusion mechanism, uses a dynamic weight allocation algorithm to combine the text semantic analysis result of the target table with the text visual analysis result of the target table. Alignment and fusion processing is performed to generate target worksheet structured requirement information corresponding to user needs and transmit it to the graph neural network matching processing module. The graph neural network matching processing module is responsible for performing similarity matching analysis between the target worksheet structured requirement information and the preset dynamic industry knowledge graph, and calculating the matching degree between the target worksheet structured requirement information and each subgraph in the preset dynamic industry knowledge graph and transmitting it to the dynamic industry knowledge graph module. The dynamic industry knowledge graph module determines at least one candidate industry subgraph corresponding to the target worksheet structured requirement information based on the matching degree between the target worksheet structured requirement information and each subgraph in the preset dynamic industry knowledge graph and transmits it to the dynamic template generation module.The dynamic industry knowledge graph module includes a knowledge acquisition submodule, a knowledge storage submodule, and a knowledge update submodule. The knowledge acquisition submodule is responsible for establishing an automated knowledge extraction pipeline, continuously extracting knowledge from multiple sources such as industry websites, standard document libraries, and API documentation; it employs a BERT-based relational joint extraction model to extract industry entity triples. The knowledge storage submodule uses a graph database to store industry knowledge, supporting complex graph queries and reasoning. The schema layer of the knowledge graph includes multiple dimensions such as industry ontology, data objects, business rules, and calculation formulas. The knowledge update submodule implements a time-decay-based knowledge freshness evaluation mechanism, automatically updating outdated knowledge periodically to ensure the timeliness of the dynamic industry knowledge graph. The dynamic template generation module instantiates an initial template based on the determined candidate industry subgraphs. The system generates a target worksheet structure template, which is then transmitted to the interaction optimization module. This target worksheet structure template includes the definitions of each field in the worksheet, the connection logic between the worksheet and the external data source, and cross-sheet reference formulas based on a preset dynamic industry knowledge graph. The interaction optimization module presents the target worksheet structure template to the user and captures all user operations within it. It dynamically analyzes all user operations on the target worksheet structure template and dynamically optimizes it until the final target worksheet structure is generated and transmitted to the deployment module. After the user confirms the final target worksheet structure, the deployment module presents it to the user again, automatically configures the corresponding external data source, generates a dynamic worksheet that matches the user's needs, and displays it to the user.

[0012] A natural language-based zero-code worksheet dynamic generation device includes one or more processors and a memory; the memory stores computer-readable instructions, which, when executed by one or more processors, implement the steps of the natural language-based zero-code worksheet dynamic generation method as described above.

[0013] A readable storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the natural language-based zero-code worksheet dynamic generation method as described in any of the foregoing descriptions.

[0014] As can be seen from the above description, this application can determine the attribute parameters of the target table to be processed. These attribute parameters include the name, content settings, and image data of the target worksheet to be generated. This allows for multi-dimensional cross-modal semantic fusion analysis of the target table's attribute parameters to determine the structured requirement information of the target worksheet corresponding to user needs. Furthermore, the structured requirement information of the target worksheet is compared with a preset dynamic industry knowledge graph for similarity matching analysis, and the matching degree between the structured requirement information of the target worksheet and each subgraph in the preset dynamic industry knowledge graph is calculated. Based on the matching degree between the structured requirement information of the target worksheet and each subgraph in the preset dynamic industry knowledge graph, at least one candidate industry subgraph corresponding to the structured requirement information of the target worksheet is determined. This allows for the instantiation of an initial worksheet based on the determined candidate industry subgraphs. A table structure template is created, resulting in a target worksheet structure template. This template includes the definitions of each field in the worksheet, the connection logic between the worksheet and the external data source, and cross-table reference formulas based on a preset dynamic industry knowledge graph. Since the target worksheet structure template needs to meet user requirements, it is presented to the user while capturing all user actions within it. These actions are dynamically analyzed and optimized until the final target worksheet structure is generated. After the user confirms the final target worksheet structure, it is presented again, and the corresponding external data source is automatically configured to generate a dynamic worksheet that matches the user's needs and is then displayed to the user.

[0015] Therefore, this application uses semantic recognition of the user-input table content settings and names to determine the industry of the worksheet to be generated. It then extracts the corresponding worksheet structure template from a pre-built industry knowledge base and optimizes the worksheet structure template based on the user-input table content settings. This generates a worksheet structure that meets the user's needs. Through deep learning and natural language processing technologies, it can generate high-quality worksheets that meet diverse user needs. It automatically generates worksheets that meet user requirements, reducing the time and effort users spend manually defining fields and table structures, reducing the error rate of manual operations, improving the accuracy and consistency of worksheets, and increasing work efficiency. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort. Figure 1 A flowchart illustrating a method for dynamically generating worksheets using no-code based on natural language, provided in this application; Figure 2 This is a schematic diagram of a zero-code worksheet dynamic generation system architecture based on natural language, as an example of this application. Figure 3 This is a hardware structure block diagram of a zero-code worksheet dynamic generation device based on natural language disclosed in this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] Given that most current no-code worksheet dynamic generation solutions based on natural language struggle to adapt to complex and ever-changing business needs, this applicant has developed a no-code worksheet dynamic generation solution based on natural language. This method performs semantic recognition on the user-input table content settings and names to determine the industry of the desired worksheet. It then extracts the corresponding worksheet structure template from a pre-built industry knowledge base and optimizes the template based on the user-input table content settings. This generates a worksheet structure that meets the user's requirements. Through AI technologies such as deep learning and natural language processing, the system can generate high-quality worksheets that meet diverse user needs. It automatically generates worksheets that meet user requirements, reducing the time and effort users spend manually defining fields and table structures, decreasing the error rate of manual operations, improving the accuracy and consistency of worksheets, and increasing work efficiency.

[0019] The methods provided in this application can be used in numerous general-purpose or special-purpose computing device environments or configurations. Examples include personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, and distributed computing environments including any of the above devices. This application provides a zero-code worksheet dynamic generation method based on natural language. This method can be applied to various management systems and to various computer terminals or smart terminals. The executing entity can be the processor or server of the computer terminal or smart terminal.

[0020] The following is combined with Figure 1 This paper introduces the process of the zero-code worksheet dynamic generation method based on natural language, as provided in the embodiments of this application. Figure 1 As shown, the process may include the following steps: Step S101: Determine the attribute parameters of the target table to be processed.

[0021] Specifically, to ensure that tables are "usable, accurate, and adaptable to needs," the attribute parameters of the target table to be processed can be determined when automatically generating worksheets (such as Excel, Google Sheets, or structured tables generated by code). These attribute parameters include the name of the target worksheet to be generated, content settings, and image data. These attribute parameters are the "design blueprint" of the table, directly determining whether the table can correctly hold data, support subsequent processing (such as calculation, analysis, and visualization), and whether it conforms to the user or system's usage scenario. Skipping this step and directly generating the table can easily lead to problems such as "data cannot be entered," "formatting errors," and "functional malfunctions" (for example, setting a cell that should store dates as text format leads to incorrect date sorting; setting a cell that should store values ​​as character format leads to errors in summation formulas). The core issue in avoiding "tables unable to hold data" is the need to clearly define the "storage rules" of the data. The essence of a table is a "container of structured data," and the attribute parameters directly define the "capacity, shape, and material" of this "container"—that is, in what form and under what rules the data can be stored. Failure to clearly define the parameters will result in data incompatibility with the table, making it unusable. The core attribute parameters that need to be determined and their corresponding functions are shown in Table 1 below: Table 1

[0022] Clearly defining the "functional rules" of a table is crucial to ensuring that the table supports subsequent processing. Automatically generated worksheets are often not "statically stored" but need to support subsequent operations (such as formula calculations, data filtering, sorting, and linking with other tables). The attribute parameters directly determine whether these functions can work properly, avoiding the embarrassment of "tables that cannot be used after generation".

[0023] Typical scenarios and dependent attribute parameters are as follows: 1. Formula calculation requirements: If the table needs to automatically calculate "Employee monthly salary = Hourly wage × Working hours", it is necessary to determine in advance that the data types of the "Hourly wage" and "Working hours" columns are "numeric" (instead of text), otherwise the formula cannot be recognized; if it is necessary to retain 2 decimal places, it is necessary to set the cell format of the "Monthly salary" column to "Numeric (2 decimal places)" to avoid the calculation result showing as "5200.3333".

[0024] 2. Data filtering and sorting requirements: If it is necessary to filter "New employees in 2024" by "Date of employment", it is necessary to determine in advance that the data type of the "Date of employment" column is "date" (instead of text), otherwise it cannot be accurately filtered by "year" and "month" during filtering (the text format of "2024-05-01" will be sorted as a string instead of in chronological order).

[0025] 3. Cross-table linkage requirements. If the "Employee performance table" needs to link the "Employee information table" through the "Employee ID" to obtain the "Department" information (such as the VLOOKUP function), it is necessary to determine in advance that the data types of the "Employee ID" columns in the two tables are the same (both text or both numeric), and the "Employee ID" is a unique value (no duplicates), otherwise the linkage will return an error value (#N / A).

[0026] Defining the "adaptation rules" of the table can adapt to the personalized needs of "different usage scenarios". In different scenarios, the "users" and "usage purposes" of the table are different, and the requirements for the table are also completely different. The attribute parameters need to match the scenario requirements to avoid "general tables not meeting specific scenarios". Common scenarios and corresponding attribute parameters are shown in Table 2 below: Table 2

[0027] Attribute parameters are the "design blueprint" for "automatically generating worksheets". The process of determining attribute parameters is to "transform vague requirements into clear technical rules", starting from "I need an employee table" and refining it to "the employee table needs 6 columns, namely text-type employee ID (unique), text-type name (non-empty), date-type date of employment, text-type department, numeric-type salary (retaining 2 decimal places), and boolean-type whether转正". Only by clarifying these rules can the automatically generated table "accurately match the requirements", neither having data storage problems nor supporting subsequent calculations, analyses, and linkages, ultimately achieving the goal of "ready to use upon generation". Conversely, skipping this step, the generated table is likely to be a "semi-finished product" and requires a large amount of manual adjustment to be usable, losing the efficiency significance of "automatically generating".

[0028] Step S102: Perform multi-dimensional cross-modal semantic fusion analysis on the attribute parameters of the target table to determine the structured requirement information of the target worksheet corresponding to the user's needs.

[0029] Specifically, user needs are often not directly expressed through explicit instructions (such as "I want a 3-column, numeric table"), but are hidden within multimodal information such as natural language descriptions, reference documents, data samples, and usage scenarios. To address the problem of "basic parameters failing to accurately match deep user needs," after determining the basic attribute parameters of the target table (such as the number of columns, data type, and format constraints), further multi-dimensional cross-modal semantic fusion analysis is conducted. This analysis identifies the structured requirements of the target worksheet that correspond to the user's needs. Only by "integrating and interpreting" this scattered and ambiguous information can the basic attribute parameters be transformed into structured requirements that "fully match the user's actual use," avoiding the deviation of "the table parameters are correct but it cannot be used."

[0030] In practice, users rarely use "table design language" to make requests. Instead, they express their needs through unstructured information such as natural language (e.g., "Make me a table to record customer follow-ups, showing the time and results of each communication, and distinguishing whether the customer is interested"), reference images (e.g., "Similar to this Excel table I sent, but with a contract amount column"), and data examples (e.g., "I have several rows of customer data here; please create a table in this format"). This information doesn't directly correspond to attribute parameters like "column definitions" or "data constraints." Basic parameters (e.g., "column name = communication time, data type = date") only define the "technical rules of the table" but don't answer questions like "What is this column used for? Does it need to be linked with other columns? Does it need to support specific analytical scenarios?" These "purpose-level" questions are the key to determining whether a table is "easy to use."

[0031] Therefore, multi-dimensional cross-modal semantic fusion analysis integrates information from multiple sources and types to transform technical parameters into business applications, ultimately determining precise structured requirements. It resolves ambiguity and vagueness in requirements, moving from literal understanding to precise semantic interpretation. Users' needs expressed through natural language or a single modality often contain ambiguities or missing information, which cannot be covered by basic parameter definitions alone. Multi-dimensional cross-modal fusion eliminates ambiguity through cross-verification of multiple pieces of information, accurately pinpointing the user's true intent.

[0032] User requests are typically in natural language, such as, "Please create a table to record product sales, calculating how much each product sold and how much profit was made." However, relying solely on basic parameters has limitations. If only the literal information is extracted, basic parameters might be defined as: Column Name = Product Name (text), Sales Volume (value), Profit (value). But this parameter design has significant ambiguity: Is "Profit" "Profit per Item" or "Total Profit"? If the user actually needs "Total Profit = Profit per Item × Sales Volume," defining only a "Profit" column would require manual calculation, violating the requirement of "automatic recording." Should "Product Name" differentiate by "Model Number"? If the user later needs to filter by "Product Model Number," a single "Product Name" column might not be sufficient (e.g., "iPhone 15" and "iPhone 15 Pro" need to be counted separately). By combining user-provided "data examples" (such as "Product Model: iPhone 15 Pro, Unit Price: 8999, Cost: 6000, Sales Volume: 10") and "Usage Scenario Descriptions" (such as "I need to calculate the total profit for each model weekly to facilitate commission calculation"), the following information can be clarified through integrated analysis: 1. The columns for "Unit Price (Value)" and "Cost (Value)" need to be added. The "Total Profit" column needs to be pre-formulated (=(Unit Price - Cost) × Sales Volume), instead of being manually entered. 2. The "Product Name" field needs to be split into two columns: "Product Category (Text)" and "Product Model (Text)," and filtering and statistics by "Model" should be supported. 3. A "Statistical Week (Text / Date)" column needs to be added to adapt to the "Weekly Statistics" scenario.

[0033] By integrating "natural language requirements + data examples + scenario descriptions", ambiguity of basic parameters is eliminated, making the table design perfectly aligned with the user's core objective of "statistical commission".

[0034] User requirements are often scattered across multiple modalities (e.g., "natural language description + reference table / image + target system requirements"). Information from different modalities may be complementary, conflicting, or repetitive, necessitating "semantic alignment" through fusion analysis. This involves mapping information from different sources to a unified "table-structured dimension" (e.g., column definitions, association rules, functional constraints) to avoid information omissions or contradictions. Key fusion dimensions and their functions are shown in Table 3. Table 3

[0035] It is evident that information from a single modality can only support some attribute parameters. Only through cross-modal fusion analysis of "natural language + reference objects + data + system constraints" can scattered information be "assembled into complete structured requirements," ensuring that the table not only has "correct parameters" but also adapts to users' operating habits, data characteristics, and external system requirements.

[0036] User needs can be categorized into "explicit needs" and "implicit needs." Explicit needs can be met through basic parameters, but if implicit needs are not identified, the table will require significant modifications after a period of use due to "functionality deficiencies." Multi-dimensional cross-modal fusion analysis can predict these potential needs through "scenario association" and "semantic reasoning," making structured design more "forward-looking."

[0037] For example, a user's explicit requirement (natural language + reference table): "Please create an employee attendance sheet to record daily attendance, including lateness and early departures." Basic parameter design: Column name = Employee Name (text), Date (date), Attendance Status (dropdown options: Attended / Late / Early / Absent). Problem: This only satisfies the "recording" requirement but doesn't consider the user's subsequent "attendance statistics" needs. If the user needs to calculate "number of late arrivals" and "attendance rate" weekly, manual filtering and statistics are required, which is extremely inefficient.

[0038] Further cross-modal fusion to uncover latent needs can be achieved as follows: 1. Based on the "user identity" (assuming it is HR): HR's work on attendance sheets involves not only recording, but also calculating "monthly attendance rate" and "deductions for lateness," which is an implicit requirement; 2. Verify from the "Remarks in the Reference Table" (e.g., a handwritten note in the reference table saying "50 yuan will be deducted for each late arrival") that the user does indeed have a need for "deduction calculation"; 3. Supplementing from "industry norms" (corporate attendance records often need to be linked to "work calendars" to exclude holidays): Avoid including holidays in "absences".

[0039] Final structured requirements optimization: Added a "Workday Mark (Boolean)" column: automatically associates with holiday data (non-working days are marked as "No" by default and are not included in attendance statistics); Added a "Monthly Late Arrivals (Number)" column: with a preset COUNTIF formula (=COUNTIF(Monthly Attendance Status Column, "Late")), automatically calculated; Added a "Late Arrival Deduction (Number)" column: with a preset formula (=Monthly Late Arrivals × 50), automatically calculated; Added a "Monthly Attendance Rate (Percentage)" column: with a preset formula (=(Monthly Attendance Days - Absent Days) / Monthly Expected Attendance Days), automatically generated.

[0040] At this point, the table not only satisfies the explicit need of "recording attendance," but also anticipates the implicit need of "statistics and calculation," truly achieving "meeting what users think of and covering what users haven't mentioned."

[0041] Therefore, cross-modal semantic fusion serves as a precise bridge between requirements and forms, transforming users' vague multimodal needs into clear, structured rules; integrating fragmented information into complete form designs; and extending surface-level functional requirements to potential application scenarios. This analysis ensures that the generated worksheets not only have correct technical parameters but also accurately match users' actual business needs, operational habits, and future requirements, truly achieving the goal of "automatically generated, usable, and easy to use." Conversely, skipping this step and generating forms solely based on basic parameters will likely result in users receiving forms that are "not what they wanted," requiring repeated modifications and ultimately reducing efficiency.

[0042] Step S103: Perform similarity matching analysis between the structured requirement information of the target worksheet and the preset dynamic industry knowledge graph, and calculate the matching degree between the structured requirement information of the target worksheet and each subgraph in the preset dynamic industry knowledge graph.

[0043] Specifically, to ensure that the generated worksheets accurately meet user needs while deeply conforming to industry standards and practical logic, and to avoid ineffective designs that "meet superficial user requirements but are detached from industry realities," the automatic worksheet generation process performs similarity matching analysis between the target worksheet's structured requirements and a pre-defined dynamic industry knowledge graph. It also calculates the matching degree between the target worksheet's structured requirements and each subgraph in the pre-defined dynamic industry knowledge graph, thus calibrating "vague user requirements" into "precise, industry-usable requirements." Generally, user-proposed worksheet requirements often suffer from "superficiality and ambiguity." For example, a user might only say "I need an e-commerce inventory table," but not specify that it should include "SKU codes, batch numbers, near-expiration warning thresholds, and inventory turnover rate fields," while these details are precisely the core elements of e-commerce inventory management. The dynamic industry knowledge graph stores structured knowledge validated through industry practice (e.g., the "inventory management subgraph" in e-commerce includes the relationships between "products-inventory-supply chain," required fields, and data format specifications; the "expense reimbursement subgraph" in finance includes the constraint logic of "reimbursement category-approval process-invoice type"). Through similarity matching, the user's "fuzzy requirements" can be aligned with the corresponding "industry standard subgraph" in the knowledge graph: if the user's requirements match the "e-commerce inventory subgraph" by 90%, then the required industry fields not mentioned by the user (such as "near-expiration warning days") can be automatically filled in, calibrating the "table the user wants" into a "table usable in the industry," avoiding omissions in requirements or logical deviations.

[0044] It also helps ensure the "industry compliance" and "practice adaptability" of worksheets. Different industries have strict specifications or default practices for the structure, fields, and logic of worksheets. If the worksheets are generated solely based on user requirements, it is easy to produce incorrect designs that "do not comply with industry rules." For example, a "salary table" in the finance field must include fields such as "pre-tax salary, special additional deductions, and social security and housing provident fund base," and the calculation logic must comply with relevant regulations. A "production plan table" in the manufacturing industry must be linked to "work order number, material BOM list, and equipment capacity data," otherwise it cannot be connected to the subsequent production execution system.

[0045] The pre-defined dynamic industry knowledge graph is a structured accumulation of public industry rules, business logic, and data standards (each "subgraph" corresponds to a specific scenario). Through matching degree calculation, the "industry subgraphs" most relevant to user needs can be selected. Based on the constraint logic of the subgraphs, the compliance of user needs can be verified (e.g., if the user does not mention "special additional deductions," it will be automatically added to ensure compliance with tax law requirements). This allows the generated worksheets to directly connect with existing industry processes (e.g., compatibility with the data formats of ERP systems and financial software), avoiding the problem of "tables being generated but unusable." Without relying on the industry knowledge graph, each worksheet generation requires "interpreting user needs from scratch + manually designing the structure," which is extremely inefficient. The knowledge graph provides "predefined industry templates and logic," achieving "automatic completion and optimization" through matching analysis, reducing manual intervention. For example, if the user's needs match the "retail industry sales report subgraph" with an 85% match, the system can directly generate the basic structure based on the "field template" of that subgraph, without requiring the user to list the fields one by one. It can also intelligently optimize logic; the subgraphs of the knowledge graph not only contain "fields" but also "relationships between fields." After matching, these industry-standard calculation logics can be automatically embedded without requiring users to manually set formulas. It can also quickly locate core needs. When user needs are complex, the matching degree between the needs and the "cross-border e-commerce inventory sub-graph" and "cross-border logistics sub-graph" can be calculated, and the sub-graph logic with higher matching degree can be prioritized to quickly locate the core scenario and avoid the interpretation of needs.

[0046] Generally, industry rules and business scenarios are not fixed, and the core characteristic of a "dynamic industry knowledge graph" is its "real-time updateability." Through "matching analysis between requirements and dynamic subgraphs," it can be ensured that the generated worksheets keep up with the latest industry changes. If user requirements match the "updated subgraph," the new industry requirements will be automatically incorporated. If user requirements have a high degree of matching with the old subgraph but a low degree of matching with the new subgraph, a message can be displayed stating "the current requirements may not conform to the latest industry standards," and optimization suggestions can be provided to avoid generating "outdated and invalid" worksheets.

[0047] User needs are the "starting point," industry knowledge graphs are the "benchmark," and similarity matching and matching degree calculation are the "bridge." This ensures that the automatically generated worksheets not only "meet the needs that users have expressed" but also "cover the needs that users haven't mentioned but that the industry needs." At the same time, compliance, practicality, and timeliness are taken into account, ultimately achieving the intelligent goal of "being generated and usable immediately."

[0048] Step S104: Based on the matching degree between the structured requirement information of the target worksheet and each subgraph in the preset dynamic industry knowledge graph, determine at least one candidate industry subgraph corresponding to the structured requirement information of the target worksheet.

[0049] Specifically, the pre-defined dynamic industry knowledge graph is a "knowledge collection" covering multiple scenarios and sub-fields. For example, a "retail industry knowledge graph" may contain multiple subgraphs such as "store sales subgraph," "online e-commerce subgraph," "membership management subgraph," and "inventory weekly subgraph," each corresponding to knowledge (fields, logic, specifications) for a specific business scenario. User needs are often single or clearly defined sub-scenarios. Directly calling all subgraphs of the entire industry knowledge graph would lead to "knowledge overload," making it impossible to determine whether to use "sales fields" or "inventory fields," or whether to embed "year-on-year sales calculation logic" or "member points rules." By "filtering candidate subgraphs based on matching degree," "precise support can be locked from generalized knowledge." If the user's needs match the "store sales subgraph" by 92% (far higher than the 30% match with the "inventory weekly subgraph"), then "the candidate subgraph is clearly the store sales subgraph," focusing the core basis for subsequent design on key knowledge such as "sales date, store number, category, sales amount, and year-on-year / month-on-month calculation logic" of this subgraph, avoiding confusion in knowledge calls. Therefore, in the process of automatically generating worksheets, at least one candidate industry subgraph corresponding to the structured requirements of the target worksheet can be determined based on the matching degree between the structured requirements information of the target worksheet and each subgraph in the preset dynamic industry knowledge graph.

[0050] By selecting the most relevant industry knowledge carriers (subgraphs) based on matching scores, a precise, compliant, and implementable basis is provided for the structured design of subsequent worksheets, avoiding aimless knowledge invocation or incorrect scenario adaptation. "Generalized industry knowledge" can be focused on "precise demand support," ensuring a high relevance between "candidate subgraphs" and the demand, avoiding directional errors. One of the core risks of automatically generating worksheets is "scenario mismatch." For example, if a user requests a "financial expense reimbursement form," but a "human resources attendance form" is generated, the root cause is the failure to select a subgraph that matches the demand. "Determining candidate subgraphs based on matching scores" eliminates low-relevance subgraphs. Through matching score calculations, subgraphs with low relevance to the demand can be directly filtered out, avoiding the use of knowledge from incorrect scenarios to design worksheets. When the demand's matching score with a particular subgraph is significantly higher than other subgraphs, it can be directly identified as a "core candidate subgraph," ensuring that all subsequent designs (field selection, formula logic, format specifications) revolve around the business scenario corresponding to that subgraph, avoiding directional deviations from the outset. For example, if a user's requirement is to "generate a logistics cost accounting table for cross-border e-commerce", the matching degree calculation will determine whether the "cross-border logistics cost sub-map" has a matching degree of 88% or the "domestic e-commerce sales sub-map" has a matching degree of 25%. The candidate sub-map will then be locked as the former. Subsequently, fields specific to cross-border e-commerce, such as "international freight, tariffs, customs clearance fees, and logistics time delay costs", will be automatically introduced instead of irrelevant fields such as "express delivery fees and delivery areas" for domestic e-commerce.

[0051] Not all user needs are "single-scenario". Some needs may involve "integration across sub-scenarios", such as a user wanting to "generate an e-commerce operation table that links inventory and sales". This need involves both "inventory management" (requiring inventory quantity and safety stock threshold) and "sales analysis" (requiring sales revenue and best-selling categories), which a single subgraph cannot fully support. In this case, "determining multiple candidate subgraphs based on matching degree" becomes crucial: the system can calculate the matching degree between the need and each subgraph, and filter out "multiple subgraphs with high matching degree" (such as "e-commerce inventory subgraph" matching degree of 80% and "e-commerce sales subgraph" matching degree of 75%), and determine both as "candidate subgraphs". When generating the worksheet later, the core knowledge of the two subgraphs can be integrated (such as taking "SKU, current inventory, and safety stock" from the inventory subgraph and "monthly sales volume and sales trend" from the sales subgraph, and embedding linkage logic such as "inventory warning = current inventory - safety stock" and "replenishment suggestion = monthly sales volume - current inventory"). If candidate sub-graphs are not filtered by matching degree, it is impossible to determine which two sub-graphs to merge (the "inventory sub-graph" and "logistics sub-graph" may be merged incorrectly), resulting in the generated table failing to meet the core requirement of "inventory-sales linkage".

[0052] Identifying candidate industry subplots can also provide a "practical basis" for subsequent "worksheet structure design". Once candidate industry subgraphs are determined, all subsequent design actions, such as "field selection, formula setting, format specification, and compliance verification," must be based on the knowledge of these candidate subgraphs. Candidate subgraphs serve as the "intermediate bridge" between "requirements" and "specific table structures," and "determining candidate subgraphs based on matching degree" provides "precise positioning" for this bridge. Candidate subgraphs contain "industry-required fields," such as "financial reimbursement subgraph" which includes "reimbursement person, department, reimbursement category, amount, invoice number, and approval status." If the user's requirements do not mention "invoice number," it can be automatically completed based on the candidate subgraph. Candidate subgraphs also contain "business logic between fields," such as "retail sales subgraph" which includes "average order value = sales amount / number of transactions," and this calculation formula can be automatically embedded based on the candidate subgraph without requiring manual setting by the user. Furthermore, candidate subgraphs contain "industry compliance requirements," such as "salary subgraph" which includes "individual income tax deductions and social security / housing provident fund fields." The system can verify whether the user's requirements have omitted any compliant fields based on the candidate subgraph, ensuring that the table complies with industry rules. Without identifying candidate subgraphs, subsequent design will lack a basis for decision-making. It will be impossible to determine which fields to add or what logic to embed, resulting in a table that is merely a collection of scattered fields mentioned by the user, rather than a logical, compliant, and usable structured worksheet. Only by clearly defining candidate subgraphs can abstract user needs and generalized industry knowledge be transformed into concrete table design solutions. This ensures that the generated worksheet meets both user needs and industry practices, avoiding aimless trial and error or incorrect scenario adaptation.

[0053] Step S105: Based on the determined candidate industry subgraphs, instantiate an initial worksheet structure template to obtain the target worksheet structure template.

[0054] Specifically, in the process of automatically generating worksheets, in order to transform the "abstract industry knowledge" (such as field definitions, logical relationships, and compliance rules) in the candidate subgraphs into "concrete table structures" (such as column names, data types, formula locations, and formatting specifications), a "skeleton" is built for the final, directly usable worksheet. Based on each determined candidate industry subgraph, an initial worksheet structure template can be instantiated to obtain the target worksheet structure template. The target worksheet structure template can include the field definitions of each worksheet, the connection logic between the worksheet and external data sources, and cross-table reference formulas based on preset dynamic industry knowledge graph relationships. The candidate industry subgraphs are "structured knowledge carriers," not "directly usable table templates." For example, the "Cross-border E-commerce Logistics Cost Sub-graph" stores "knowledge descriptions" such as "Fields: International Freight (Definition: Basic costs incurred in cross-border transportation, Data type: Numeric), Customs Duties (Definition: Import taxes and fees levied by customs, Calculation logic: Goods value × Customs duty rate), Compliance Rules: Must include the 'Customs Declaration Number' field for traceability." This information is "abstract and non-visualized" and cannot be directly used by users for data entry or analysis. However, "Instantiating the Initial Template" can map the abstract knowledge elements in the sub-graph to specific structural components of the table. For example, the "field definition" of a subgraph can correspond to the "column name + data type" of a table (e.g., "international freight" can correspond to the column name "international freight (yuan)" and the data type "numeric (rounded to 2 decimal places)" in the table); the "calculation logic" of a subgraph can correspond to the "formula cell" of a table (e.g., "tariff = goods value × tariff rate" corresponds to embedding the formula "=C2*D2" in the corresponding cell of the "tariff" column, where column C is "goods value" and column D is "tariff rate"); the "compliance rules" of a subgraph can correspond to the "required column label" of a table (e.g., "must include customs declaration number" corresponds to labeling "required" next to the "customs declaration number" column and setting data validity checks). Without this transformation, the knowledge of candidate subgraphs remains at the "theoretical level" and cannot be transformed into a table format that users can perceive and use.

[0055] Based on the identified candidate industry subgraphs, an initial worksheet structure template is instantiated to ensure 100% alignment between the "table structure" and the "candidate subgraph knowledge," avoiding any omissions. Candidate subgraphs are "precise demand support" selected through matching criteria; every knowledge element (field, logic, rule) they contain is strongly related to user needs. For example, in the "financial expense reimbursement subgraph," the "reimbursement category (limited options: travel expenses / office expenses / entertainment expenses), approval status (pending approval / approved / rejected), and amount verification (total amount = sum of all detailed amounts)" are all core elements that the "expense reimbursement form" must possess. The process of "instantiating the initial template" is a process of "implementing knowledge element by element," traversing all knowledge nodes of the candidate subgraphs to ensure that each node corresponds to the table structure, avoiding the omission of key information. For example, if a subgraph contains "reimbursement category options must be limited," a drop-down menu will be automatically set for the "reimbursement category" column during instantiation, instead of allowing users to input freely. If a subgraph contains "total amount validation logic," a summation formula will be automatically embedded in the last row of the "total amount" column during instantiation, and "data validity" will be set (a reminder will pop up if the total amount is not equal to the sum of details). Conversely, if instantiation is skipped and the table is generated directly, problems such as "missing key fields" and "logic not implemented" may occur, resulting in a table that does not meet industry knowledge requirements and cannot meet the actual needs of users.

[0056] As mentioned earlier, some user needs require the collaborative support of multiple candidate subgraphs (for example, an "e-commerce operation table linking inventory and sales" requires the support of both an "e-commerce inventory subgraph" and an "e-commerce sales subgraph"). In this case, "instantiating the initial template" can integrate the knowledge elements of multiple subgraphs into a single table template, avoiding the problem of "fragmented subgraph knowledge." The specific integration logic includes the following: 1. Field deduplication and priority sorting: If two sub-graphs contain the same field (e.g., "SKU number" exists in both the inventory sub-graph and the sales sub-graph), deduplication will be automatically performed during instantiation, retaining only one "SKU number" column, and the field definition of the "sub-graph with higher matching degree to the requirements" will be used as the standard (e.g., if the definition of "SKU" in the inventory sub-graph includes the "inventory location" attribute, while the sales sub-graph only includes "product name", then the definition of the inventory sub-graph will be used as the standard, and a "inventory location" note will be added next to the "SKU number" column).

[0057] 2. Logical association and linkage design: If two subgraphs have business associations (such as the "current inventory" of the inventory subgraph and the "monthly sales" of the sales subgraph needing to be linked to calculate the "inventory available days"), the association field (such as the "inventory available days" column) will be automatically added during instantiation, and the linkage formula ("=B2 / C2", where column B is "current inventory" and column C is "monthly sales") will be embedded.

[0058] 3. Standardized Formatting and Partitioning: To avoid table clutter caused by the fusion of knowledge from multiple subgraphs, the fields are partitioned by "business module" during instantiation (e.g., the left side of the table is the "Inventory Module" field: SKU, Current Inventory, Safety Stock; the right side is the "Sales Module" field: Monthly Sales, Sales Amount, Best-Selling Level), and borders and background colors are used to distinguish them, improving readability.

[0059] Without fusion-type instantiation, the knowledge from multiple subgraphs will become "two independent table fragments," failing to form a complete demand support for "inventory-sales linkage." Users will still need to manually piece together the tables, thus losing the meaning of "automatic generation."

[0060] Based on the identified candidate industry subgraphs, an initial worksheet structure template is instantiated to generate an "adjustable initial template," leaving ample room for subsequent "personalized adaptation." "Instantiating the initial template" does not generate a "final, unchangeable table," but rather a "structured initial skeleton" (i.e., the target worksheet structure template). This template contains the core knowledge of the candidate subgraphs (ensuring compliance and usability) while also preserving space for "personalized adjustments" (meeting specific user needs).

[0061] For example, a user's requirement is to "generate a monthly sales table for retail stores," with the candidate sub-graph being "Store Sales Sub-graph." The initial template obtained after instantiation includes core columns such as "Store Number, Date, Category, Sales Amount, and Year-on-Year Growth Rate." If the user additionally requests to "add a 'Store Manager's Name' column" (a personalized requirement not included in the sub-graph), since the initial template already has a framework of "field columns + data types," only a "Store Manager's Name" column (data type "text") needs to be inserted into the template, without needing to redesign the entire table structure. If the user requests to "change the number of decimal places in the 'Year-on-Year Growth Rate' column from 2 to 1," this can also be adjusted in the template's "Data Format Settings," without affecting other core logic. This "skeleton first, then adjustments" approach avoids the inefficiency of "designing a table from scratch" while flexibly adapting to users' personalized needs, balancing "standardization (industry knowledge)" and "personalization (user-specific requirements)."

[0062] Based on the identified candidate industry subplots, instantiating an initial worksheet structure template provides an "executable structural basis" for "final worksheet generation." Subsequent processes require filling data (e.g., extracting data from the user's data source and filling corresponding columns), formatting (e.g., setting header background color, adjusting column width), and generating the final file (e.g., Excel, Google Sheets) based on the "target worksheet structure template." The "target worksheet structure template" is the "sole basis" for these operations. For example, when filling data, it needs to know that "the 'transportation fee' field in the data source corresponds to the 'international freight (RMB)' column in the template," otherwise, the problem of "incorrectly filled columns" will occur. When formatting, the system needs to know that "the 'approval status' column needs to be color-coded (pending approval = yellow, approved = green)," otherwise automated formatting cannot be achieved. When generating the file, the system needs to know that "the table contains 10 columns, the default column width is 15 characters, and the header font is bold 12pt" to generate a file that conforms to the user's reading habits. Without this template, the subsequent processes of "data filling, format rendering, and file generation" will lose their direction and will be unable to form a final usable worksheet.

[0063] Step S106: Present the target worksheet structure template to the user and capture all user operations on the target worksheet structure template.

[0064] Specifically, after generating the target worksheet structure template, to better meet user needs, the target worksheet structure template can be presented to the user, and all user operations within the target worksheet structure template can be captured. This helps to solve the problem that "the system's self-judgment may deviate from the user's actual usage habits and implicit needs." The "system-designed template" can be transformed into a "user-approved and usable template," ensuring that the final generated worksheet not only "conforms to industry rules" but also "fits the user's operating habits, scenario details, and unexpressed needs."

[0065] Although templates may be tailored to user needs as closely as possible through steps such as "cross-modal semantic fusion," "industry knowledge graph matching," and "template instantiation," two core bias risks still exist. For example, while algorithms interpret users' multimodal needs (such as natural language and reference examples), they may overlook users' "unspoken but default habits" (such as users' habit of placing the "customer name" column on the far left of the table instead of the system's default "customer ID" column). Secondly, while the subgraphs of the industry knowledge graph are "general specifications," users' specific scenarios may have "special adjustments" (such as the industry subgraph defaulting to retaining two decimal places for "reimbursement amount," but the user's company requires one decimal place, or additional notes on "whether expedited reimbursement is required").

[0066] Presenting templates to users and capturing their actions empowers them to be the ultimate decision-makers. Through user adjustments (such as dragging and dropping column order, adding or deleting fields, and modifying formatting), the system's misunderstandings are corrected, calibrating the "general template" into a "user-specific, usable template." For example, the system-generated "Customer Follow-up Table" defaults to including "Follow-up Date, Customer Name, and Communication Content." Users can add a "Next Follow-up Time" column, addressing an unforeseen implicit need, ensuring the final template truly matches the user's actual usage scenario. Secondly, self-generated templates may appear to meet requirements but are actually unusable. For instance, a user might need a "Table for recording employee overtime." A template generated based on the "Human Resources Attendance Sub-graph" includes "Employee ID, Overtime Date, and Overtime Hours," but the user actually needs to calculate overtime hours by "Department," which is missing from the template. If the final table is generated directly, users will discard it due to the "missing key fields," negating the purpose of automatic generation.

[0067] Presenting the template to users allows them to visually check its "field completeness" (whether any key information is missing), "logical rationality" (whether the formulas conform to actual calculation habits, such as whether "total overtime hours" is calculated in "hours" instead of "minutes"), and "format compatibility" (whether the date format is the user's commonly used "YYYY / MM / DD" instead of the system default "YYYY-MM-DD"). By capturing the user's "modification operations" (such as adding a "department" column, adjusting formula units, and modifying date formats), deviations in the template can be directly verified and corrected. These operations provide "direct feedback" from users on whether the template meets their needs, which is more accurate than algorithmic prediction. Different users have significantly different operating habits and scenario details. Even for the same requirement (such as an "e-commerce inventory table"), different users may have different requirements. For example, e-commerce operator A is used to putting the "SKU code" in the first column for easy and quick searching; e-commerce operator B is used to putting the "inventory warning status" (red / yellow / green) in the first column to prioritize out-of-stock items; finance users may need to add an "inventory amount" column (=inventory quantity × unit price) to the "inventory table," while operations users may not need this calculated field. These "personalized requirements" cannot be fully predicted by industry knowledge graphs or algorithms. Industry subgraphs can only provide "general fields" but cannot cover details such as "column order preferences, personalized fields, and formatting habits." By capturing user actions (such as dragging columns to adjust their order, inserting new columns, deleting unnecessary columns, and modifying cell format), the system can retain users' personalized settings (e.g., remembering the user's preferred column order and automatically using it when generating similar tables later); it can also add personalized fields not covered by industry templates (e.g., a user-added "inventory amount" column, for which the system can automatically embed matching formulas); and it can adjust "general formats to user-favorited formats" (e.g., changing the date format to a style commonly used by the user). This ensures that the final generated template is no longer a "uniform industry-wide version" but a "personalized version tailored to the user's individual habits," significantly improving the user experience and efficiency. If the "template presentation and operation capture" steps are skipped and the final worksheet is generated directly, users will need to modify it in the "table with already filled data" after discovering discrepancies, which will incur higher costs. If new fields need to be added, columns must be manually inserted and the positions of existing data adjusted, which may lead to data misalignment; if formulas need to be modified, formulas in all data rows must be adjusted one by one to avoid calculation errors in some cells; if column order needs to be adjusted, the linkage with other tables may be disrupted. In the "template stage," user actions are captured, and the cost of modification is extremely low. There is no actual data in the template stage, so adding / deleting columns, adjusting the order, or modifying formulas will not affect the data. The template structure can be "optimized once" based on user actions, and the optimized structure can be directly used when filling in data later, avoiding the trouble of double modification of "data + structure".For example, if a user finds that the "supplier" column is missing during the template stage, they can simply insert a new column. If the column is inserted after the final table is generated, the "inventory quantity" and "unit price" columns, which already have 100 rows of data, need to be manually shifted to the right, which is very easy to make mistakes. Modifications during the template stage can completely avoid this risk.

[0068] Furthermore, capturing user actions on templates not only optimizes the current template but also provides crucial data for subsequent system iterations. It can statistically analyze common modification operations by users with similar needs, allowing these high-frequency personalized requirements to be integrated into subgraphs of the industry knowledge graph, reducing future modification costs for users. It can also record user preferences for format and logic, automatically adapting these preferences when generating similar templates, improving the accuracy of algorithm predictions. This allows the ability to automatically generate worksheets to evolve from simply meeting general needs to precisely matching the habitual needs of specific user groups, forming a closed loop of "generation-feedback-optimization."

[0069] The generated target worksheet structure template is a "semi-finished product" based on algorithms and industry knowledge. Presenting it to the user and capturing their actions is a crucial step in refining it into a "finished product" that meets their individual needs. This process verifies and corrects any misunderstandings the system may have about the requirements; it supplements personalized needs not covered by industry templates; it reduces subsequent modification costs; and it improves the usability of the final table. This ensures that the automatically generated worksheet is not only "technically compliant and logically correct" but also "fits the user's operating habits and real-world scenarios," truly achieving the goal of "readily usable and easy to use," and avoiding the awkward situation where "the system believes it meets the requirements, but the user cannot use it."

[0070] Step S107: Dynamically analyze all user operations on the target worksheet structure template, dynamically optimize the target worksheet structure template, until the final target worksheet structure determined by the user is generated.

[0071] Specifically, to address the discrepancy between "machine prediction" and "actual user needs," and to ensure the final output perfectly matches the user's personalized and scenario-based requirements, the entire process from "requirement analysis to generating the final worksheet structure" dynamically analyzes all user operations on the target worksheet structure template, dynamically optimizing the template until the user's final target worksheet structure is generated. This compensates for the inherent discrepancy between "machine cognition" and "actual user needs." Generally, the initial template generated by the machine through "structured requirement information + industry knowledge graph matching" is a "predictive output" based on standardized data and general industry rules. However, user needs often contain "hidden details" or "personalized preferences" that are difficult for machines to capture. These details cannot be fully covered by preliminary semantic analysis and graph matching. For example, in the e-commerce industry, the initial template generated by the machine based on the "order management" subgraph may include common fields such as "order number, product ID, and payment amount," but a user may actually need to add an additional "customer membership level" field or delete the "logistics tracking number" field. These personalized needs cannot be fully captured by machine prediction alone. For example, user preferences for table formats and the logic of interaction between fields are "implicit needs" that are difficult to cover in the early stages of structured analysis.

[0072] Dynamically analyzing user actions (such as adding / deleting fields, adjusting formatting, and modifying formulas) allows machines to "passively learn" the user's true needs, transforming "standardized predictions" into "personalized adaptations" through template optimization. Initial templates only address the "framework for meeting basic user needs," but fail to solve the core issues of "ease of use and usability." Ultimately, users don't need "a logically sound structure," but rather "a tool that can be directly implemented." Without dynamic optimization: Suppose the initial template's "Customer Information" column includes "Name, Phone Number, Address," but the user's actual business requires filtering customers by "Region," yet no separate "Region" field is set in the template. In this case, although the template "conforms to the industry's general structure," it cannot meet the user's actual operational needs (such as filtering and statistics), ultimately becoming an "invalid structure." By capturing user actions (such as manually inserting a "Region" column or adding a summation formula to the "Amount" column), the template structure can be adjusted in real time (such as fixing the position of the "Region" column or retaining the summation formula by default). This ensures that the final structure not only "meets the requirements" but also "directly supports the user's business operations" (such as filtering regional customers and automatically calculating the total amount), truly achieving "ready to use immediately".

[0073] The initial "structured requirements analysis → graph matching → initial template generation" process is a "one-way derivation" process without "real user verification." If the "dynamic optimization" is skipped and the final structure is determined directly, minor deviations in the early stages may be amplified, resulting in a complete disconnect between the final output and the user's needs. For example, if the user's requirement is "to generate a table for 'monthly sales analysis'," the machine might match the "daily sales report" subgraph based on the industry graph (causing minor deviations due to some overlapping fields between "daily report" and "monthly analysis"). The initial template would include fields such as "daily sales revenue" and "daily sales volume." Without dynamic optimization, the user would have to manually change the "daily" field to "monthly" and add "monthly year-on-year / monthly comparison" fields, resulting in extremely high operational costs. However, through dynamic analysis, the machine can capture the user's modifications and optimize the template to include fields such as "monthly sales revenue," "monthly sales volume," and "year-on-year growth rate," correcting the previous subgraph matching deviations and forming a closed loop. Dynamic optimization involves "involving users in the structural design process." Through real-time verification and adjustment, deviations in the initial derivation process are corrected in a timely manner, avoiding misalignment of requirements caused by "one-way derivation" and ensuring the consistency between the final structure and user needs.

[0074] Furthermore, not all users possess "structured design capabilities." Most users only know "what functions they need," but not "how to implement those functions through a table structure." By analyzing user actions, the system can proactively help users refine the structural details. For example, when a user repeatedly selects the "sales volume" column to calculate the percentage, the machine can automatically add a "sales volume percentage" column to the template and pre-set the formula "(sales volume of a certain product / total sales volume) × 100%", lowering the operational threshold for users (eliminating the need to manually enter the formula). User actions are "the most direct signal of needs." For example, if a user repeatedly adjusts the format of the "date" column, it indicates that the initial template format settings do not conform to user habits. The machine can optimize and set the "date format" as the default, making the final structure more in line with user habits and improving the "accuracy" of meeting needs.

[0075] Step S108: After the user confirms the final target worksheet structure, the final target worksheet structure is presented to the user again, and the external data source corresponding to the target worksheet structure is automatically configured to generate a dynamic worksheet that corresponds to the user's needs and display it to the user.

[0076] Specifically, to address the issue of "the structure remaining merely an 'empty template,' unable to directly support data and business applications," and to ensure "structural accuracy, data responsiveness, and immediate effectiveness upon use" through "secondary presentation + automatic configuration," a truly usable dynamic tool is delivered to the user. After the user confirms the final target worksheet structure, it is presented again, and the corresponding external data source is automatically configured to generate a dynamic worksheet that matches the user's needs. This completes the closed loop of "structure confirmation → data activation," transforming the template from an "empty shell" into a "usable tool." The "final worksheet structure" confirmed by the user is a "static template without data," while the user's core need is to "manage / analyze actual data using tables." If the process only stops at the "structure confirmation" stage, the table cannot carry any business value, losing the core meaning of "automatic generation." Secondly, by automatically configuring the external data source, the "static structure" can be filled into a "dynamic worksheet containing real data," while ensuring precise alignment of data and structure fields. For example, if the user confirms an "E-commerce Order Analysis Table" (columns: order number, product name, order time, payment amount, logistics status), it can automatically connect to the user's "e-commerce backend database" (external data source), extract order data from "September 1st to September 30th, 2024," match and populate the data according to the structure columns, and generate a dynamic table containing real order data. Only then does the table transform from an "empty template" into a "tool that can be used to analyze September order trends," truly meeting the user's business needs.

[0077] In addition, even if the user has confirmed the "final structure" of the worksheet, there may still be two hidden risks: First, the confirmed worksheet structure may not match the data source's fields. For example, the user-confirmed structure might include a "Customer Mobile Number" column, but the external data source might name this field "Contact Phone Number." Directly filling in this field would result in "empty data" or "incorrect column entry." Second, users may have a "memory bias" regarding the confirmed worksheet structure. For instance, after confirming the structure, a user might forget the "design purpose of a certain column," leading to discrepancies later. Re-presenting the structure and automatically configuring the data source allows users to confirm before filling in the data that the "column names, data types, and constraints" are consistent with their expectations (e.g., the "Customer Mobile Number" column does exist and its data type is "text"). This avoids the need to modify the structure after filling in the data due to "memory bias." Third, automatically detecting the matching relationship between the "structure columns" and the "data source fields," and prompting the user to confirm whether the data source field "Contact Phone Number" corresponds to the "Customer Mobile Number" column, allows the user to confirm before filling in the data, preventing invalid tables due to "data mismatch."

[0078] For example, if the user confirms a structure with a "Product Category" column, and the corresponding field in the data source is "Category Name", the mapping prompt during secondary presentation allows the user to confirm the correspondence between "Category Name → Product Category", ensuring that the data in the "Product Category" column is accurate after being filled, rather than being empty.

[0079] Users typically interact with spreadsheets not by "viewing static data once," but by "continuously tracking data changes" (e.g., e-commerce operations need to check order data daily, HR needs to update employee attendance data weekly). If the generated spreadsheet is a "static spreadsheet" (which is not updated after data is filled), users have to manually repeat the steps of "extracting data → copying and pasting → adjusting formatting," which is extremely inefficient.

[0080] The core value of "dynamic worksheets" lies in "data linkage and real-time updates." When automatically configuring the data source, the system establishes a "dynamic association" between the "worksheet structure" and the "external data source" (e.g., through API interfaces, database connections, or scheduled file synchronization), rather than simply copying data once. After the user confirms the final target worksheet structure, the system presents it to the user again, automatically configures the corresponding external data source, generates a dynamic worksheet that matches the user's needs, and displays it to the user. Subsequent times when the user opens the worksheet, it automatically retrieves the latest data from the external data source, eliminating the need for manual user intervention.

[0081] For example, the user-generated "Daily Sales Report for Stores" is configured with a dynamic link to the "POS System Database". Every day at midnight, it automatically extracts the previous day's sales data and updates it to the table. Users can open the table the next day to view the latest daily report without having to manually import data. This truly achieves the goal of "tables serving business efficiency".

[0082] "Generate and display immediately" lowers the user threshold and achieves "seamless delivery from requirements to tools." Users' ultimate goal is to "quickly obtain a usable table," not to "participate in a complex configuration process." If users had to manually operate "connecting to the data source → selecting the data range → filling in data → setting update rules" after "structure confirmation," it would significantly increase the barrier to entry and defeat the purpose of "automatic generation." "Automatic configuration of the data source and direct display after generation" is "seamless delivery." The entire process of "data source connection, field mapping, data filling, and dynamic association settings" is automated, requiring no technical expertise from users (such as database connections or API configuration). The generated dynamic worksheet is displayed directly, allowing users to immediately perform operations such as "filtering, sorting, calculation, and visualization," achieving a zero-transition from "requirement confirmation to tool usability." For example, after HR users confirm the structure of the "employee salary table," the system automatically connects to the "salary management system," extracts all employees' "basic salary, performance bonus, and deductions" data, fills the table, calculates the "net salary," and directly displays the complete salary table. HR does not need to manually import data or perform calculations; it can be used for salary verification immediately, significantly reducing operational costs.

[0083] After the user confirms the final target worksheet structure, the system presents it to the user again, automatically configures the corresponding external data source, generates a dynamic worksheet that matches the user's needs, and displays it to the user. This provides a "data foundation" for subsequent "table function expansion." Users may later need to "expand the functionality" of the table (such as adding data visualization charts, setting data alerts, or linking with other tables), and the realization of these functions depends on the table already containing real data and being "dynamically linked to the data source." For example, if a user wants to add a "monthly sales trend chart" to the "order analysis table," if the table is dynamically linked to the data source, the chart can be automatically generated based on real-time data, and the chart will update synchronously with data updates. If the user wants to set an "inventory alert" (highlighting the current inventory in red when it is lower than the safety stock), the system can automatically trigger the alert rule based on the dynamic data in the table, without requiring manual monitoring by the user. If the data source is not automatically configured and only a static structure is generated, users will need to manually fill in the data and set the functions when expanding functionality later, which is extremely inefficient. The "dynamic worksheet," by establishing a "data foundation" in advance, facilitates subsequent function expansion, giving the table "continuous iteration value."

[0084] After the user confirms the final target worksheet structure, the final target worksheet structure is presented to the user again, and the corresponding external data source is automatically configured. A dynamic worksheet corresponding to the user's needs is generated and displayed to the user, ensuring "structure and data source matching" and avoiding data mismatch. This transforms the table from a "static template" into a "dynamically updated business tool," adapting to continuous use scenarios. Seamless delivery of usable tables lowers the user's barrier to entry and truly achieves the goal of "automatically generated and usable." Starting from the user's vague needs, through semantic analysis, graph matching, template instantiation, and user adjustments, the final result is a dynamic worksheet that is "structurally accurate, data real-time, and directly usable for business," fully meeting the user's core requirements.

[0085] As described above, this application uses semantic recognition of the user-input table content settings and names to determine the industry of the worksheet to be generated. It then extracts the corresponding worksheet structure template from a pre-built industry knowledge base and optimizes the template based on the user-input table content settings. This generates a worksheet structure that meets the user's needs. Through AI technologies such as deep learning and natural language processing, the system can generate high-quality worksheets that meet diverse user needs. It automatically generates worksheets that meet user requirements, reducing the time and effort users spend manually defining fields and table structures, reducing the error rate of manual operations, improving the accuracy and consistency of worksheets, and increasing work efficiency.

[0086] As described above, this application can perform multi-dimensional cross-modal semantic fusion analysis on the attribute parameters of the target table to determine the structured requirement information of the target worksheet corresponding to user needs. The process will be described below, and may include the following: Step S201: Perform deep semantic analysis on the attribute parameters of the target table, including the name and content settings of the worksheet to be generated, and extract the business entities, intents, and logical constraints between fields of the worksheet to be generated as the text semantic analysis result of the target table.

[0087] Specifically, in the "multi-dimensional cross-modal semantic fusion analysis", vague and unstructured user needs are transformed into precise and feasible structured needs information. The attribute parameters of the target table, including the name and content settings of the worksheet to be generated, can be deeply semantically analyzed. The business entities, intents, and logical constraints between fields of the worksheet to be generated are extracted as the text semantic analysis results of the target table, so as to lay the foundation for "precise alignment" for subsequent matching of industry subgraphs and generation of worksheet structure.

[0088] User requests for forms are often abstract, colloquial, or fragmented, with "worksheet name" and "content settings" being the most direct "textual carriers" of these requirements. Deep semantic analysis extracts "business entities" to find concrete business anchors for these vague requests. These entities directly correspond to core objects in the actual business scenario, preventing the generated worksheets from deviating from the user's real business context.

[0089] Users create tables to achieve specific goals, and "intent" is a precise distillation of those core goals. Skipping intent parsing might result in a table that "has a structure but no functionality." For example, in a "customer table," if the user's implicit intent is to "screen high-value customers for follow-up," the table needs to include filterable fields such as "spending amount" and "repurchase rate." If the intent is to "record basic customer contact information," then only basic fields like "name," "phone number," and "address" are needed. By parsing the "content setting information" (such as the user's added requirement to "distinguish between new and old customers and view spending over the last 3 months"), the core intents of "filtering and categorizing" and "time range statistics" can be extracted. This ensures that the subsequently generated table structure directly supports the user's operational goals, rather than simply piling up fields.

[0090] The core value of a worksheet lies not only in "containing the required fields," but also in the logical relationships and constraints between those fields. Without logical constraints, a table will suffer from data inconsistencies, calculation errors, and other problems, rendering it useless.

[0091] For example, the "content settings" in the user requirements include "the order form needs to automatically calculate the total price, and shipping information cannot be filled in for unpaid orders." Two key logical constraints can be extracted through semantic parsing: 1. Calculation constraint: The "Total Price" field is derived from the "Unit Price" and "Quantity" fields (not manually entered); 2. Status Constraint: The "Shipping Date" field requires the "Order Status" to be "Paid" (precondition constraint).

[0092] These constraints are directly translated into "logical rules" for the subsequent worksheet structure (such as formulas and data validation rules in Excel), ensuring the accuracy of the table data and the standardization of operations, and avoiding redundant work for users to manually adjust the logic later.

[0093] "Multi-dimensional cross-modal semantic fusion analysis" typically combines multi-modal information such as text (e.g., user textual requirements), speech (e.g., user voice descriptions), and even visual sketches (e.g., user-drawn table frames). The "textual semantic analysis results" (entities, intents, constraints) serve as the "common semantic language" for all modal information. By parsing textual attribute parameters, the "business entities (complaints, processing progress)," "intents (tracking complaint processing status)," and "constraints (unprocessed status highlighted in red)" can act as "translators," converting the "highlighted" information in speech into "conditional formatting rules," aligning fields in hand-drawn sketches with entities, and ultimately achieving "semantic unification" of multi-modal information. This avoids ambiguity or conflict between different modalities, ensuring that the resulting "target worksheet structured requirement information" is complete and consistent.

[0094] Step S202: Using a preset worksheet visual analysis model, analyze the image data included in the attribute parameters of the target table, and extract the header structure, data area and table style features included in the attribute parameters of the target table as the text visual analysis result of the target table.

[0095] Specifically, to supplement the "visual and spatial needs" that text semantic analysis cannot cover, and to ensure that the final generated worksheet not only "functionally matches business needs" but also "fits user habits in terms of form," while achieving a complete fusion of "text + visual" multimodal information, a preset worksheet visual analysis model can be used to analyze the image data included in the attribute parameters of the target table during the process of determining the structured requirements information of the target worksheet. The model extracts the header structure, data areas, and table style features included in the attribute parameters of the target table as the text visual analysis results of the target table. Specifically, the preset worksheet visual analysis model is trained using the image data included in the attribute parameters of the target table as training samples, and the header structure, data areas, and table style features contained in the image data included in the attribute parameters of the target table as sample labels.

[0096] As described above, the attribute parameters of the target table can include image data. For example, it can also include user-input files (which can be documents, image data, or video data). Users' needs for tables are often expressed not only through text but also through implicit structural expectations conveyed through images, such as hand-drawn table sketches, screenshots of reference tables, or even diagrams marked "This needs to be divided into two columns" or "This part needs to have cells merged." These needs cannot be obtained through text semantic parsing and must rely on visual analysis. For example, a user provides a screenshot of a "competitor's sales report" as a reference, with the text only stating "We need to make a similar table." In this case, visual analysis can accurately extract the table header structure: "Product Category (merged into 2 rows) → Monthly Sales (divided into columns 1-12) → Annual Total (right-aligned)"; data area: "Sales data area is below the header, each row corresponds to one product, and values ​​are retained to one decimal place"; style features: "The header background color is blue, data rows are alternately colored, and the total row is bold." If visual analysis is skipped and tables are generated solely based on the text "similar to competitor tables", problems such as disordered header hierarchy (e.g., unmerged cells) and inconsistent data formats (e.g., retaining integers) may occur, resulting in a significant deviation from user expectations.

[0097] A table's "usability" depends not only on the completeness of its fields but also on their spatial arrangement logic—that is, "which fields are grouped together, how many levels the header has, and how the data area and summary area are divided." This spatial logic directly impacts user browsing efficiency, while text semantic analysis (such as extracting entities like "customer," "order," and "remarks") cannot determine "how entities should be visually ordered." Visual analysis can solve this problem by extracting the spatial features of the "header structure" and "data area": ​​Header hierarchy: Identifying "multi-level headers" (such as "annual sales" divided into "Q1-Q4," and "Q1" further divided into "January-March") avoids information confusion caused by "flat headers"; Area division: Identifying the spatial boundaries between the "data area" and "summary area" ensures a visual hierarchy in the table; Field sorting: Identifying the visual habit of "highly frequently accessed fields on the left" (such as customer name and order number) and "auxiliary fields on the right" (such as remarks) avoids generating an inefficient structure where "important fields are on the right and require horizontal scrolling to find." For example, visual analysis reveals that in the reference image provided by the user, "Customer ID" and "Customer Name" are always on the far left and separated from "Order Information" in the middle by a vertical line. This spatial logic can be directly converted into the layout rules of the target table, improving the user's browsing efficiency in subsequent use.

[0098] The "style features" of tables (such as color, font, cell format, and borders) may seem like mere "aesthetic requirements," but they are actually strongly correlated with the usage scenario and user habits, even affecting the readability and professionalism of the data. Text semantic analysis cannot obtain this style information; it must be extracted and implemented through visual analysis. Secondly, different business scenarios have default specifications for table styles. For example, financial statements typically require "dark headers, light data areas, right-aligned amount fields with thousands separators," while project progress tables may require "green row markers for completed tasks and yellow row markers for incomplete tasks." Visual analysis can extract these scenario-specific styles from user-provided image data, ensuring that the generated tables conform to industry or company standards, eliminating the need for users to manually adjust the format later. Some users have fixed style habits. Visual analysis can identify these personalized features; for example, if it discovers from a user's hand-drawn sketch that "all headers are marked with circles for 'boldness,'" it can automatically apply the "bold header" style when generating the template, improving user comfort and acceptance.

[0099] As mentioned earlier, "multi-dimensional cross-modal semantic fusion" requires integrating multi-modal information such as text (e.g., names, content settings) and visual information (e.g., image data). The "text-visual analysis results" (header, data area, style) serve as a crucial bridge connecting textual semantics and visual requirements, preventing conflicts or omissions between the two modalities. If the text description states "must contain 10 fields," but the visual image only displays 8 fields with two clearly merged columns, the visual analysis can indicate "the number of text fields does not match the image layout," prioritizing the user's visual expectation (8 columns, including merged cells) or further confirming the requirements. Text parsing extracts the intent of "statistical monthly sales" and the logical constraint of "order amount = unit price × quantity," while visual analysis supplements the visual rules of "monthly sales are listed in columns 3-14 of the header" and "order amount column is right-aligned and highlighted in red." After fusion, the generated target worksheet's structured requirement information includes both "functional logic" (text) and "visual form" (visual), ensuring that the subsequently generated template is a complete solution with both "function" and "form" matching.

[0100] The process of extracting the header structure, data area, and table style features of the target table from its attribute parameters, which include image data, can be as follows: First, perform target detection and OCR recognition processing on the image data included in the target table's attribute parameters; then, jointly encode the recognized text information with the control position information in the image data included in the target table's attribute parameters to determine the table's physical structure and logical hierarchy; finally, based on the table's physical structure and logical hierarchy, extract the header structure, data area, and table style features from the target table's attribute parameters.

[0101] Specifically, to accurately extract the "physical form" and "logical relationships" of tables from unstructured image data, ensuring that the extracted header structure, data areas, and style features conform to both visual presentation and the table's business logic, the image data is processed using a pre-defined worksheet visual analysis model. The process involves "object detection and OCR recognition → joint encoding → feature extraction." Image data (such as table screenshots or hand-drawn sketches) is a collection of pixels containing a large amount of irrelevant information, while the system requires "the table's effective content" (such as text, lines, and cell positions). Object detection and OCR recognition are fundamental to "removing irrelevant information from images and extracting core content." Object detection uses a model to locate the physical boundaries of "table areas" in an image, such as the outer borders of the table and cell separators, eliminating interfering elements such as backgrounds and watermarks, and clearly identifying "which pixels belong to the table itself." OCR recognition can convert "image-based text" (such as "customer name" and "amount" in a screenshot) within the table area into "editable text information," solving the problem of "not being able to directly read image text."

[0102] The core characteristics of a table lie in the unity of its "physical form" (such as cell position, size, and arrangement) and "logical hierarchy" (such as the "hierarchical relationship between table headers and data" and the "parent-child relationship of multi-level table headers"). "Joint encoding" (text information + control position information) establishes a mapping between "physical position" and "logical relationship." Text information (OCR results) provides "content semantics," while control position information (cell coordinates, size, and relative position obtained from object detection) provides "spatial constraints." Through joint encoding, logical relationships can be inferred based on spatial constraints. Relying solely on text information may disrupt the table's logical structure. Extracting header structure, data areas, and style features depends on an accurate understanding of the table's "physical structure" and "logical hierarchy." "Feature extraction based on physical structure and logical hierarchy" aims to avoid misjudgments caused by "relying solely on visual appearance," ensuring that the extracted results conform to both visual presentation and business logic. Header structure extraction can be based on logical hierarchy (determined through joint encoding), distinguishing between "multi-level table headers" (such as "year → quarter → month") and "ordinary rows," avoiding misjudging the "first row of the data area" as a header. For example, if a line of text (such as "Total") is located at the end of the data area and the font is bold (style feature), combined with the logical hierarchy, it can be determined that it is a "summary row" rather than a header. Data area extraction can be based on physical structure (cell position and range), which can accurately divide the "start and end rows / columns of the data area" (such as "rows 1 to 50 below the header are the data area"), and combined with the logical hierarchy, confirm the "correspondence between the data area and the header" (such as "the data in column 3 corresponds to the 'Amount' header"). If only location information is relied upon, "blank areas of merged cells" may be misjudged as data areas, resulting in incorrect ranges. Style feature extraction can combine physical structure (such as cell color pixel values, border line thickness) and logical hierarchy (such as the semantics of "header row" and "summary row"), which can accurately extract "contextual styles" (such as "the background color of the header row is blue" and "the font of the summary row is bold"), avoiding misjudging "accidental stains" as "background colors" or confusing "header styles" with "data styles".

[0103] Step S203: Align and fuse the text semantic analysis results of the target table with the text visual analysis results of the target table to generate the semantic analysis results of the target table.

[0104] Specifically, in order to solve the problem of the disconnect between "textual requirements" and "visual requirements", the scattered single-modal information is transformed into a unified semantic solution that is "functionally complete, structurally reasonable and visually matched". This ensures that the final target worksheet can accurately meet the user's business logic and fit their visual usage habits. The text semantic analysis results of the target table and the text visual analysis results of the target table can be aligned and merged to generate the semantic analysis results of the target table.

[0105] Text semantic analysis and visual analysis extract information from different dimensions. Without alignment and fusion, contradictions may arise between "business logic" and "visual form," rendering the generated tables unusable. One of the core functions of alignment and fusion is to identify and resolve such conflicts, ensuring logical consistency between the two. Text semantic analysis extracts the requirement to include "quarterly sales" and "monthly sales," but visual analysis reveals that in the user-provided reference image, the "monthly sales" column is merged below "quarterly sales" (the visual form is "quarterly as the first-level header, monthly as the second-level header"). Without fusion, two errors may occur: generating two independent columns based on the text (disrupting the visual hierarchy); and generating multi-level headers based on the visual hierarchy, but omitting the "quarterly and monthly summary logic" (disrupting business logic). During fusion, the "textual field associations" are aligned with the "visual hierarchical structure," determining that "quarterly sales" is the first-level header, "January-March" is the second-level header, and "quarterly sales = sum of January-March sales" (embedding the textual logical constraints into the visual hierarchy), thus resolving the conflict.

[0106] Secondly, both text semantic analysis and visual analysis have their own "information blind spots." Text can clearly identify "what fields are needed and the logic between them," but it cannot specify "how the fields are arranged or what they look like." Visual analysis can clearly identify "how the fields are arranged and what they look like," but it cannot specify "why the fields exist or the logical relationships between them." Alignment and fusion use the advantages of one modality to fill the gaps in another, forming a complete requirement profile. Visual analysis supplements the "layout gaps" in text: Text semantic analysis extracts four business entities—"customer, order number, amount, and date"—but does not specify "the column order of these four fields." Visual analysis, by extracting the "column order of customer → order number → date → amount in the reference image," can supplement this information, avoiding the counterintuitive layout of "amount on the far left and customer on the far right," thus improving user convenience. Visual analysis identifies "two rows of 'subtotal' and 'total'" in the reference image, but does not indicate the calculation logic. At this point, the logical constraints extracted by text semantic analysis, such as "subtotal = sum of all customer order amounts" and "total = sum of all subtotals," can supplement the "calculation rules" that cannot be conveyed visually. This ensures that the generated "subtotal / total" rows are not empty rows, but functional rows that can be automatically calculated. For example, if a user only provides a screenshot of an "inventory table" (visual information: three columns, "product name," "inventory quantity," and "warning value," with rows where "inventory quantity < warning value" highlighted in red), without explaining the "highlighting rule" in text, during fusion, if the text semantic analysis fails to extract the logical constraints, it can be combined with the visual "highlighting feature" to deduce the "conditional formatting logic of 'highlighting when inventory quantity < warning value'," supplementing the missing rule information in the text.

[0107] The final generated "target table semantic analysis result" needs to simultaneously satisfy "machine-understandable" and "user-perceptible" requirements. It needs to clearly define structured information such as "fields, logic, and data sources," and users need to clearly understand visual information such as "what the table looks like and how to use it." Alignment and fusion can transform scattered textual and visual information into a unified semantic solution that is "executed by machines and recognized by users."

[0108] For the system, the fusion result clearly defines the mapping relationship between "business entities → visual positions" (e.g., "customer name" corresponds to "column 1, left-aligned, bold header") and the association rules between "logical constraints → visual presentation" (e.g., "order amount > 1000" corresponds to "cell background color is light blue"). This structured semantic information is the core basis for subsequent "automatic configuration of data sources" and "generation of dynamic worksheets"—the machine can accurately know "which field corresponds to which data source field" and "which logic needs to be implemented through formatting or formulas," avoiding execution deviations. For users, the fusion result presents the "visual effect after the business requirements are implemented" (e.g., "includes customer and order information, customer column on the left, amount column right-aligned, and items over 1000 yuan highlighted in blue"). Users can perceive in advance whether "the final table meets expectations" through the fusion semantic description, reducing subsequent adjustment costs. For example, after fusion, the user is informed that "the table will contain all the order fields you need, arranged in the column order of the reference image, and items over 1000 yuan will be highlighted in blue," allowing the user to directly confirm "whether it meets the requirements" without waiting for the generated template to be modified. If the alignment and fusion step is skipped and templates are generated directly based on a single text or visual modality, problems such as "complete fields but chaotic layout" or "good layout but missing logic" may arise later, requiring repeated iterations and adjustments. Alignment and fusion, by integrating bimodal information in advance, can significantly reduce subsequent optimization costs and improve the accuracy of the first-time matching. For example, without fusion, if a template "containing all fields but with a random layout" is generated first based on text, users may report "incorrect column order and poor formatting," requiring secondary visual adjustments; if a template "good layout but missing key logic" is generated first based on visuals, users may report "no subtotal row and no automatic calculation of amounts," requiring secondary addition of logic. However, the template generated after fusion simultaneously includes "correct fields, reasonable layout, complete logic, and matching styles," eliminating the need for users to repeatedly request "layout adjustments" or "logic additions," reducing iterations and improving efficiency.

[0109] Step S204: Based on the semantic analysis results of the target table, determine the structured requirement information of the target worksheet corresponding to the user's needs.

[0110] Specifically, the problem of "semantic analysis results not being able to directly guide worksheet generation" arises because semantic analysis results represent "a complete interpretation of user needs," while structured requirement information is "the transformation of this interpretation into standardized, machine-executable table design rules." Therefore, after aligning and fusing the textual and visual semantics of the target table, the structured requirement information of the target worksheet corresponding to user needs can be further determined based on the semantic analysis results of the target table, thus transforming "unstructured semantic interpretation" into "structured design rules." The semantic analysis results of the target table (after text + visual fusion) are "a natural language / descriptive interpretation of user needs," containing information such as business entities, intents, logical constraints, and visual features. However, this information is "dispersed and non-standardized" and cannot be directly used by machines to generate worksheets (machines require explicit rules such as "field definitions, format parameters, and logical formulas"). For example, semantic analysis results might be described as: "Record customer order information, including customer name, purchased items, unit price, and quantity purchased; automatically calculate the total amount; highlight items exceeding 1000 yuan in blue; place the customer name on the far left; and use SimSun font." Such descriptions are easy for humans to understand, but lack clear execution standards for machines. "Determining the structured requirements of the target worksheet" involves transforming these descriptive interpretations into standardized rules that can be executed by the machine.

[0111] Only through this "structured transformation" can the machine clearly define "how many columns to generate, what type of each column is, how to write the formulas, and how to set the format," laying an "executable" foundation for the subsequent generation of worksheet templates. Structured requirement information is equivalent to a "implementation manual" for requirement interpretation. It transforms every information point in the semantic analysis results (whether it is business logic or visual preference) into "unique and clear design rules," ensuring that the machine-generated tables "neither omit any requirement points in the semantics nor add extra designs that are not in the semantics," achieving precise alignment of "interpretation is design."

[0112] As mentioned earlier, the subsequent process requires "matching structured requirement information with the dynamic industry knowledge graph to determine candidate subgraphs" and "instantiating an initial template based on the candidate subgraphs." Both of these steps require "standardized structured requirement information" as a "matching benchmark," otherwise efficient and accurate matching cannot be achieved. For "industry knowledge graph matching," the subgraphs in the knowledge graph store "standardized field definitions and logical rules." Only when the structured requirement information also adopts a standardized format of "field name + data type + logical constraints" can it be "accurately compared" with the knowledge nodes in the subgraph, avoiding "matching failures" due to inconsistent formats (e.g., the semantic description "can automatically calculate the total amount" cannot be compared with the rule "order amount = unit price × quantity" in the subgraph). For "template instantiation," the instantiation process requires "clear field order, format parameters, and formula logic" to generate a specific table structure (e.g., an Excel template). If based solely on semantic analysis results (such as "total amount on the right"), instantiation cannot determine "whether the right column is the 5th or 6th column" or "the column width." However, structured requirements explicitly state "order amount is in the 5th column, column width 15 characters," allowing instantiation to be generated directly according to the rules without additional checks. Structured requirements are not only a "machine execution standard" but also a "clear basis for user confirmation of requirements." Compared to abstract semantic analysis results (such as "contains order-related fields, format meets expectations"), structured requirements are presented to users in a "list-based, standardized" format (such as "field list, formula rules, format parameters"), allowing users to intuitively judge "whether it fully meets their needs," avoiding significant adjustments required after generation due to "misunderstandings."

[0113] For example, users can use structured requirements information to confirm whether all necessary fields are included (e.g., confirming the presence of a "Customer Type" column and that it's a dropdown option); whether the logical rules are correct (e.g., confirming the formula for "Order Amount" is "Unit Price × Quantity," not "Unit Price + Quantity"); and whether the visual format meets expectations (e.g., confirming that "Amounts exceeding 1000 RMB should have a blue background, not blue font"). If users find discrepancies (e.g., "Customer Type should include a 'Potential Customer' option"), they can directly make "precise adjustments" based on the structured requirements information (changing the "Dropdown Option" from "New Customer / Existing Customer" to "New Customer / Existing Customer / Potential Customer") without needing to re-examine the semantic analysis results, significantly reducing communication and adjustment costs.

[0114] In practical applications, this application can also crawl authoritative information from various industries in real time; and use a preset training language analysis model to extract industry entity relationship information from the crawled authoritative information and construct industry entity triples; then map the entities and relationships in the industry entity triples to the continuous vector space corresponding to the dynamic industry knowledge graph; so that the nearest subgraph to the structured requirement representation corresponding to the industry entity triples can be found in the vector space and the entities and relationships in the industry entity triples can be embedded to update the preset dynamic industry knowledge graph in real time.

[0115] In practical applications, this application can also generate a data lineage report corresponding to the target worksheet structure while generating the target worksheet structure that the user has finally determined. The data lineage report includes the source, calculation logic, and the basis node of each field in the target worksheet structure in the dynamic industry knowledge graph.

[0116] Specifically, to upgrade from "structure delivery" to "end-to-end traceable value delivery," a corresponding data lineage report is generated simultaneously when the target worksheet structure is generated. This addresses both the question of "how to use" the table and the key questions of "where the data comes from, where it goes, and how it changes," providing core support for subsequent data use, maintenance, and risk management. The "synchronous delivery" of the data lineage report (which records the data flow path, processing rules, and relationships from the "source" to the "target worksheet") and the target worksheet structure essentially endows the worksheet with "interpretability" and "manageability," helping to lower the barrier to data use: allowing "users" to quickly understand the meaning of the data. The target worksheet structure only presents "what fields are available and what their types are" (e.g., the "order amount" field is numeric), but it cannot answer "is this 'order amount' a direct reference to the 'amount' in the original order table, or is it the result of calculation after adding 'coupon deduction'?" Data lineage reports can directly supplement this kind of key information: for example, clarifying that "target table.order amount = source table A.original amount - source table B.coupon amount", and indicating the storage location of the source table (e.g., "database DB_01.table order_raw"). This helps users (especially non-technical personnel) quickly grasp the "business meaning" of the fields and avoid erroneous analysis caused by "misunderstanding the data source" (such as mistakenly using "calculated amount" as "original amount").

[0117] When data anomalies occur in a target worksheet, the worksheet structure alone is insufficient to determine the source of the problem—is it due to errors in the source data itself or incorrect processing rules? A data lineage report provides a "full-chain traceability path," helping technical personnel quickly narrow down the investigation scope and avoid the inefficiency of "blindly investigating the entire chain." Furthermore, current data compliance requirements explicitly mandate "traceability of data processing activities," especially for fields involving personal information. The synchronously generated lineage report directly records the source and processing of each field in the target worksheet. This enables rapid response to compliance audits and timely identification of "risks in the transfer of sensitive data." The data lineage report serves as a "maintenance manual," simplifying subsequent maintenance and iterations, reducing the cost of table modifications. Modifications only require expansion based on existing lineage relationships, while simultaneously checking whether the modification affects downstream processes, preventing cascading problems caused by "a single change affecting the entire system."

[0118] The generation of a data lineage report needs to revolve around the "fields of the target worksheet". The process of generating a data lineage report corresponding to the structure of the target worksheet can be as follows: 1. You can first collect the "full-link data metadata" of the target worksheet. Generating a lineage report requires obtaining the "relationship information between the target table and upstream data." This necessitates collecting two types of core metadata to ensure no omissions. First, extract the target worksheet structure metadata from the final worksheet structure, including "field name, field type, field description, and primary / foreign key." Second, extract upstream data link metadata: tracing the "data source" of the target table fields requires collecting three types of information: Source data table information: the name of the upstream table corresponding to the field, its storage location, and the name of the source field; Data processing rule information: Records the "processing logic" of fields from the source to the target table, including calculation rules, transformation rules, and filtering rules; Data flow chain information: If an "intermediate processing table" exists, the complete chain must be recorded and the processing tools for each step must be marked.

[0119] In practice, table structure metadata can be obtained through data dictionaries (such as Hive Metastore and MySQL Information Schema); processing rules and workflow can be obtained through ETL tool logs (such as DataWorks and Flink task logs); if unstructured data (such as Excel source files) is involved, the "data source description document" provided by the business personnel needs to be manually supplemented.

[0120] 2. Parse "field-level lineage relationships" and establish a mapping model. Based on the collected metadata, the one-to-one / one-to-many lineage relationship between "target table fields and upstream data" can be clarified through a combination of technical analysis and business verification, avoiding parsing errors. For example, a "lineage analysis tool" can be used to automatically identify field mapping relationships and perform reverse parsing based on "data processing scripts / task configurations." Open-source tools (such as Apache Atlas and DataHub) can automatically parse the lineage of SQL scripts and ETL tasks; commercial tools (such as Informatica DataGovernance and IBM InfoSphere) support the integration of lineage from multiple data sources. Secondly, technical analysis may contain "semantic biases," requiring confirmation from business personnel. This can involve checking the "business rationality of processing rules" and supplementing "business-level lineage explanations."

[0121] 3. Structured output of lineage reports, clearly presenting dimensions. Transforming the parsed lineage relationships into a structured report that is "understandable to humans and recognizable by machines" requires including five core presentation dimensions to ensure the information is complete and clear. In practice, the data lineage report can generate two versions: one is a "visual report" (such as HTML / PDF format, including flowcharts) for business personnel to view; the other is a "structured file" (such as JSON format, facilitating subsequent integration with the data governance platform) for machines to access.

[0122] 4. Verify the consistency between the synchronous verification report and the target worksheet. After generating the report, a final verification step is required to ensure that the lineage report and the target worksheet structure are "completely matched," avoiding "omitted fields or incorrect rules." For example, check whether each field in the target worksheet has a corresponding entry in the lineage report; if any omissions are found, they need to be supplemented. "Sample data verification" can also be used to confirm the correctness of the processing rules. Furthermore, it can be confirmed that the "data flow chain" in the report is consistent with the execution chain of the actual ETL task. In practice, automated scripts (such as Python) can be written to compare the "target table field list" and the "report field list"; and data quality tools (such as Great Expectations) can be used to verify the accuracy of the processing rules.

[0123] For example, the specific implementation process of this application can be as follows: The system can receive the name and content settings of the worksheet A to be generated; then, through an LLM model, semantic analysis is performed on the name and content settings of worksheet A to extract key entity information and semantic relationship information; industry information for worksheet A is generated based on the key entity information and semantic relationship information; the industry information is matched with industries in a pre-built industry knowledge base to obtain the industry to which worksheet A belongs; wherein, an industry knowledge base covering multiple industries can be pre-built, storing the worksheet structure template, field names, data types, and relationships corresponding to each industry; the key entity information and semantic relationship information are matched with the corresponding industries in the industry knowledge base, and the industry with the highest matching degree is taken as the industry to which worksheet A belongs. The structure template of worksheet A is then determined based on the industry to which worksheet A belongs; the structure template of worksheet A is adjusted based on the content settings to generate worksheet structure A. For example, field names, data types, and relationships are determined based on the content settings; the structure template of worksheet A is adjusted based on the field names, data types, and relationships to generate worksheet structure A. After generating worksheet structure A, a streaming output method can be used to output the component information of each form component in worksheet structure A one by one. Then, based on the component information of all form components, the worksheet structure is rendered to generate the interface of worksheet A. The component information of worksheet structure A includes: component name, component type, validation logic, default value, and prompt information. After generating the interface of worksheet A, user feedback information can also be received. Semantic analysis of the feedback information is performed through the LLM model to obtain modification intent information. This allows worksheet structure A to be adjusted according to the modification intent information, and the worksheet interface is re-rendered based on the adjusted worksheet structure A2.

[0124] The following is combined with Figure 2 This application introduces an optional system architecture for dynamic production on a no-code platform. This system can be applied to the aforementioned natural language-based no-code worksheet dynamic generation method, such as... Figure 2As shown, the system architecture may include: a multimodal input interface module, a cross-modal semantic fusion analysis module, a dynamic industry knowledge graph module, a graph neural network matching and processing module, a dynamic template generation module, an interaction optimization module, and a deployment module; wherein, the cross-modal semantic fusion analysis module includes a text analysis submodule, a visual analysis submodule, and a multimodal fusion submodule. The multimodal input interface module can receive and process user input data, determine the attribute parameters of the target table to be processed, and transmit them to the cross-modal semantic fusion analysis module, wherein the attribute parameters of the target table include the name of the target worksheet to be generated, content setting information, image data, and document data; user input methods include natural language text input, image input, document upload input, and voice input. The text analysis submodule employs a Transformer-based pre-trained language model to perform deep semantic analysis on the target table's attribute parameters, including the name and content settings of the worksheet to be generated. This includes functions such as named entity recognition, relation extraction, and intent classification. It can also use a multi-head attention mechanism to capture long-distance dependencies. The submodule extracts the business entities, intents, and logical constraints between fields of the worksheet to be generated as the text semantic analysis results, and transmits all analysis results to the multimodal fusion submodule. The visual analysis submodule utilizes a pre-defined worksheet visual analysis model to analyze the image data included in the target table's attribute parameters. It extracts the header structure, data areas, and table style features included in the target table's attribute parameters as the text visual analysis results, which are then transmitted to the multimodal fusion submodule. In practice, the pre-defined worksheet visual analysis model can be trained using the image data included in the target table's attribute parameters as training samples, and the header structure, data areas, and table style features contained in the image data as sample labels. The multimodal fusion submodule, based on a cross-attention multimodal fusion mechanism, aligns and fuses the textual semantic analysis results and visual textual analysis results of the target table using a dynamic weight allocation algorithm. This generates structured requirement information for the target worksheet corresponding to the user's needs and transmits it to the graph neural network matching processing module. This structured requirement information represents the relevant information of the worksheet the user desires. Therefore, the graph neural network matching processing module is responsible for performing similarity matching analysis between the structured requirement information of the target worksheet and a pre-defined dynamic industry knowledge graph. It also calculates the matching degree between the structured requirement information of the target worksheet and each subgraph in the pre-defined dynamic industry knowledge graph and transmits this information to the dynamic industry knowledge graph module.The dynamic industry knowledge graph module can determine at least one candidate industry subgraph corresponding to the structured requirements of the target worksheet based on the matching degree between the structured requirements information of the target worksheet and the subgraphs in the preset dynamic industry knowledge graph, and transmit it to the dynamic template generation module. To dynamically update the industry knowledge graph, the module can also include a knowledge acquisition submodule, a knowledge storage submodule, and a knowledge update submodule. The knowledge acquisition submodule is responsible for establishing an automated knowledge extraction pipeline, continuously extracting knowledge from multiple sources such as various industry websites, standard document libraries, and API documents; it can use a BERT-based relational joint extraction model to extract industry entity triples. The knowledge storage submodule is responsible for storing various industry knowledge using a graph database, supporting complex graph queries and reasoning. The schema layer of the knowledge graph includes multiple dimensions such as industry ontology, data objects, business rules, and calculation formulas. The knowledge update submodule is responsible for implementing a time-decay-based knowledge freshness evaluation mechanism, automatically updating outdated knowledge periodically to ensure the timeliness of the dynamic industry knowledge graph. In the field of information extraction in Natural Language Processing (NLP), "relation extraction" is one of the core tasks. Its goal is to extract structured triples of "entity pairs + relation types" (such as `<Xiaoming, lives in, Beijing>`, `<Apple Inc., founder, Steve Jobs>`) from unstructured text. Traditional relation extraction follows a two-step pipeline model, while "joint extraction" was developed to address the shortcomings of this pipeline model, as shown in Table 4. Table 4

[0125] BERT (Bidirectional Encoder Representations from Transformers) is a pre-trained language model that captures the contextual semantic information of text through bidirectional Transformers (such as the different meanings of "apple" in "eat apples" and "Apple Inc."). In joint relation extraction, BERT acts as a "semantic encoder," converting the raw text into vector representations (i.e., "word embeddings") containing rich contextual information, providing high-quality semantic input for subsequent "entity recognition" and "relation judgment." Compared to traditional word embeddings (such as Word2Vec and GloVe, which only provide static, context-free vectors), BERT's advantage lies in the fact that the vectors of the same word differ in different contexts, better reflecting the ambiguity of natural language; it can also capture long-distance dependencies (such as the association between "he" and "company" and "Xiaoming" and "Company A" in the sentence "Xiaoming joined Company A in 2020, and he is now the product manager of the company").

[0126] The overall process of the BERT relation joint extraction model can be summarized as "BERT encoding → joint decoding (entity + relation)", where "joint decoding" is the core technology. The mainstream ideas are divided into two categories: "multi-task learning with parameter sharing" and "unified label modeling". Multi-task learning with parameter sharing mainly regards "entity extraction" and "relation judgment" as two sub-tasks, shares the encoder parameters of BERT, and at the same time optimizes them through two independent decoders (such as CRF, fully connected layer) respectively. Finally, triples are obtained through "entity pair matching". The specific process is as follows: 1. BERT encoding: Input the text (such as "A founded B company"), and output the context vectors of each token (such as the vectors of "A", "founded", "ed", "B", "company").

[0127] 2. Entity extraction sub-task: After the BERT output layer, connect a CRF (conditional random field) layer (a classic layer for processing sequence labeling, which can capture the boundary constraints of entities. For example, after "B-person", only "I-person" or "O" can follow), and complete entity annotation (such as "A" is annotated as "B-person → I-person → I-person", "B company" is annotated as "B-organization → I-organization → I-organization → I-organization").

[0128] 3. Relation judgment sub-task: After the BERT output layer, connect a fully connected layer, input the "vector of the entity pair" (usually take the average or maximum value of the entity token vectors), and judge the relation type of the entity pair (such as the relation between `<A, B company>` is "founder", `<B company, A>` is "founded by", and if there is no relation, it is marked as "NA").

[0129] 4. Triple generation: Combine the extracted entities in pairs, filter out the entity pairs with "NA" relations, and finally obtain valid triples (such as `<A, founder, B company>`).

[0130] Unified label modeling does not split the "entity" and "relation" tasks, but designs a unified label system, binds the "entity position" and "relation type", and directly outputs triples through a single generator (such as sequence labeling, pointer network). This idea realizes "joint" more thoroughly. A typical representative is TPLinker (Token Pair Linking), and its core design is as follows: Label definition: Represent the "entity pair" as a "token pair" (such as the i-th token and the j-th token in the text), and the label contains two types of information: 1. Entity type: Mark whether a token pair constitutes the "start - end point of an entity" (e.g., `<1,3>` indicates that the 1st token to the 3rd token is an entity of the "person" category, corresponding to "Jobs"). 2. Relationship type: Mark whether a token pair constitutes the "start point of the head entity - start point of the tail entity" (e.g., `<1,7>` indicates that the 1st token is the start point of the head entity of the "founder" relationship, and the 7th token is the start point of the tail entity, corresponding to "A → B Company").

[0131] After BERT encoding, a classifier is used to predict the labels of all token pairs, and then according to the label rules, the "head entity - relationship - tail entity" triples are spliced. It completely avoids redundant combinations of entity pairs (such as traversing all entity pairs in multi - task learning with parameter sharing), directly locates the entity boundaries corresponding to valid relationships, and has higher efficiency and accuracy.

[0132] Taking the commonly used "BERT + CRF + relationship classification" architecture as an example, intuitively understand the model structure: Input text: [CLS] A founded B Company [SEP] ([CLS] is the sentence - level vector marker of BERT, and [SEP] is the separator); BERT encoder: Output the context vector of each token (including the vector of [CLS]). Branch 1: Entity extraction (CRF layer), entity annotation result: O B - person I - person I - person O O O B - organization I - organization I - organization I - organization O; Extracted entities: person (A), organization (B Company).

[0133] Branch 2: Relationship classification (fully - connected layer), input entity pair vectors (vector of A, vector of B Company); Relationship prediction result: founder (not NA).

[0134] Final triple: <A, founder, B Company>; The BERT relationship joint extraction model has stronger semantic understanding compared with traditional pipeline models or non - BERT joint models. BERT's bidirectional context encoding solves the problems of "semantic ambiguity" and "long - distance dependence" in traditional models. For example, it can accurately identify that "C" is an "organization" entity in both "C released a new mobile phone" and "Xiaoming works at C". There is less error propagation. The joint extraction mode avoids the chain reaction of "wrong entity extraction leading to wrong relationships in the pipeline". For example, even if the entity boundary is slightly deviated, the semantic information of the relationship judgment can reverse - correct the entity annotation. It has better generalization ability. BERT's pre - training - fine - tuning mode (pre - training on general corpora and fine - tuning on specific relationship datasets) enables it to still perform well in small - sample scenarios. For example, with only a small amount of data on the "partner" relationship, it can accurately extract similar relationships.

[0135] The dynamic template generation module is responsible for instantiating an initial worksheet structure template based on the determined candidate industry subgraphs, obtaining the target worksheet structure template, and transmitting it to the interaction optimization module. The target worksheet structure template includes the definitions of each field in the worksheet, the connection logic between the worksheet and the external data source, and cross-table reference formulas based on a preset dynamic industry knowledge graph. The interaction optimization module presents the target worksheet structure template to the user and captures all user operations within the target worksheet structure template. It dynamically analyzes all user operations within the target worksheet structure template, dynamically optimizes the target worksheet structure template, and generates the final target worksheet structure determined by the user, which is then transmitted to the deployment module. After the user confirms the final target worksheet structure, the deployment module presents the final target worksheet structure to the user again, automatically configures the external data source corresponding to the target worksheet structure, generates a dynamic worksheet corresponding to the user's needs, and displays it to the user. The specific processing flow of each module in the above-mentioned natural language-based zero-code dynamic worksheet generation system can be found in the previous section on natural language-based zero-code dynamic worksheet generation methods, and will not be repeated here.

[0136] This application's no-code platform table dynamic generation device can be applied to no-code worksheet dynamic generation devices based on natural language, such as terminals: mobile phones, computers, etc. Optionally, Figure 3 The hardware structure block diagram of the zero-code worksheet dynamic generation device based on natural language is shown, with reference to... Figure 3The hardware structure of a natural language-based zero-code worksheet dynamic generation device may include: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4. In this application, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4. Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement this application; memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device; wherein, the memory stores a program, which the processor can call, the program used to implement the various processing flows in the aforementioned terminal-based natural language-based zero-code worksheet dynamic generation scheme. This application also provides a readable storage medium that stores a program suitable for processor execution, the program used to implement the various processing flows in the aforementioned terminal-based natural language-based zero-code worksheet dynamic generation scheme.

[0137] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. The various embodiments described in this specification are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. The various embodiments can be combined with each other. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for dynamically generating worksheets using zero-code based on natural language, characterized in that, The method includes: Determine the attribute parameters of the target table to be processed, wherein the attribute parameters of the target table include the name of the target worksheet to be generated, content setting information, and image data; Multi-dimensional cross-modal semantic fusion analysis is performed on the attribute parameters of the target table to determine the structured requirement information of the target worksheet corresponding to the user's needs; The structured requirement information of the target worksheet is matched with the preset dynamic industry knowledge graph for similarity analysis, and the matching degree between the structured requirement information of the target worksheet and each subgraph in the preset dynamic industry knowledge graph is calculated. Based on the matching degree between the structured requirement information of the target worksheet and each subgraph in the preset dynamic industry knowledge graph, at least one candidate industry subgraph corresponding to the structured requirement information of the target worksheet is determined. Based on the determined candidate industry subgraphs, an initial worksheet structure template is instantiated to obtain a target worksheet structure template, wherein the target worksheet structure template includes the field definitions of each worksheet, the connection logic between the worksheet and the external data source, and the cross-table reference formula based on the preset dynamic industry knowledge graph relationship. Present the target worksheet structure template to the user and capture all user operations on the target worksheet structure template; Dynamically analyze all user operations on the target worksheet structure template, dynamically optimize the target worksheet structure template, until the final target worksheet structure determined by the user is generated; After the user confirms the final target worksheet structure, the final target worksheet structure is presented to the user again, and the external data source corresponding to the target worksheet structure is automatically configured to generate a dynamic worksheet that corresponds to the user's needs and display it to the user.

2. The method according to claim 1, characterized in that, The step of performing multi-dimensional cross-modal semantic fusion analysis on the attribute parameters of the target table to determine the structured requirement information of the target worksheet corresponding to user needs includes: Multi-dimensional cross-modal semantic fusion analysis is performed on the attribute parameters of the target table to obtain the semantic analysis results of the target table; Based on the semantic analysis results of the target table, the structured requirement information of the target worksheet corresponding to the user's needs is determined.

3. The method according to claim 2, characterized in that, The step of performing multi-dimensional cross-modal semantic fusion analysis on the attribute parameters of the target table to obtain the semantic analysis results of the target table includes: The attribute parameters of the target table, including the name and content settings of the worksheet to be generated, are subjected to deep semantic analysis. The business entities, intents, and logical constraints between fields of the worksheet to be generated are extracted as the text semantic analysis results of the target table. Using a pre-defined worksheet visual analysis model, the image data included in the attribute parameters of the target table is analyzed, and the header structure, data area, and table style features included in the attribute parameters of the target table are extracted as the text visual analysis result of the target table. The pre-defined worksheet visual analysis model is trained by using the image data included in the attribute parameters of the target table as training samples and the header structure, data area, and table style features included in the image data included in the attribute parameters of the target table as sample labels. The semantic analysis results of the target table are aligned and fused with the visual analysis results of the target table to generate the semantic analysis results of the target table.

4. The method according to claim 3, characterized in that, The process of visually analyzing the target table's attribute parameters, which include image data, and extracting the header structure, data areas, and table style features from the target table's attribute parameters includes: The image data included in the attribute parameters of the target table is subjected to target detection and OCR recognition processing; The identified text information is jointly encoded with the control position information in the image data included in the attribute parameters of the target table to determine the table's physical structure and logical hierarchy included in the attribute parameters of the target table. Based on the attribute parameters of the target table, which include the table's physical structure and logical hierarchy, the header structure, data area, and table style features included in the attribute parameters of the target table are extracted.

5. The method according to claim 1, characterized in that, The method also includes: Real-time crawling of authoritative information from various industries; Using a pre-set training language analysis model, industry entity relationship information is extracted from authoritative information from various industries and industry triples are constructed. The industry entity triples are incorporated into the existing dynamic industry knowledge graph to update the preset dynamic industry knowledge graph in real time.

6. The method according to claim 5, characterized in that, The process of incorporating the industry entity triples into the existing dynamic industry knowledge graph includes: Map the entities and relations in the industry entity triples to the continuous vector space corresponding to the dynamic industry knowledge graph; Find the nearest subgraph in the vector space that corresponds to the structured requirement representation of the industry entity triple and embed the entities and relations in the industry entity triple.

7. The method according to claim 1, characterized in that, The method further includes: while generating the target worksheet structure finally determined by the user, generating a data lineage report corresponding to the target worksheet structure, wherein the data lineage report includes the source, calculation logic and the basis node of each field of the target worksheet structure in the dynamic industry knowledge graph.

8. A zero-code worksheet dynamic generation system based on natural language, characterized in that, The system, applicable to the zero-code worksheet dynamic generation method based on natural language as described in any one of claims 1-7, comprises: a multimodal input interface module, a cross-modal semantic fusion analysis module, a dynamic industry knowledge graph module, a graph neural network matching processing module, a dynamic template generation module, an interaction optimization module, and a deployment module; wherein the cross-modal semantic fusion analysis module includes a text analysis submodule, a visual analysis submodule, and a multimodal fusion submodule; The multimodal input interface module receives and processes user input data, determines the attribute parameters of the target table to be processed, and transmits them to the cross-modal semantic fusion analysis module. The text analysis submodule uses a Transformer-based pre-trained language model to perform deep semantic parsing on the attribute parameters of the target table, including the name and content settings of the worksheet to be generated; it uses a multi-head attention mechanism to capture long-distance dependencies; it extracts the business entities, intents, and logical constraints between fields of the worksheet to be generated as the text semantic analysis results of the target table, and transmits them to the multimodal fusion submodule. The visual analysis submodule uses a preset worksheet visual analysis model to analyze the image data included in the attribute parameters of the target table, extracts the header structure, data area and table style features included in the attribute parameters of the target table as the text visual analysis result of the target table and transmits it to the multimodal fusion submodule. The multimodal fusion submodule is based on the cross-attention multimodal fusion mechanism. It uses a dynamic weight allocation algorithm to align and fuse the text semantic analysis results of the target table with the text visual analysis results of the target table, generate target worksheet structured requirement information corresponding to user needs, and transmit it to the graph neural network matching processing module. The graph neural network matching processing module is responsible for performing similarity matching analysis between the structured requirement information of the target worksheet and the preset dynamic industry knowledge graph, and calculating the matching degree between the structured requirement information of the target worksheet and each subgraph in the preset dynamic industry knowledge graph and transmitting it to the dynamic industry knowledge graph module. The dynamic industry knowledge graph module determines at least one candidate industry subgraph corresponding to the structured requirements of the target worksheet based on the matching degree between the target worksheet's structured requirements information and each subgraph in the preset dynamic industry knowledge graph, and transmits it to the dynamic template generation module. The dynamic industry knowledge graph module also includes a knowledge acquisition submodule, a knowledge storage submodule, and a knowledge update submodule. The knowledge acquisition submodule is responsible for establishing an automated knowledge extraction pipeline, continuously extracting knowledge from multiple sources such as various industry websites, standard document libraries, and API documents; it uses a BERT-based relational joint extraction model to extract industry entity triples. The knowledge storage submodule is responsible for storing various industry knowledge using a graph database, supporting complex graph queries and reasoning. The knowledge update submodule is responsible for implementing a time-decay-based knowledge freshness evaluation mechanism, automatically updating outdated knowledge periodically to ensure the timeliness of the dynamic industry knowledge graph. The dynamic template generation module is responsible for instantiating an initial worksheet structure template based on each of the determined candidate industry subgraphs, obtaining the target worksheet structure template, and transmitting it to the interaction optimization module. The interaction optimization module presents the target worksheet structure template to the user and captures all user operations on the target worksheet structure template; it dynamically analyzes all user operations on the target worksheet structure template and dynamically optimizes the target worksheet structure template until the final target worksheet structure determined by the user is generated and transmitted to the deployment module. After the user confirms the final target worksheet structure, the deployment module presents the final target worksheet structure to the user again, automatically configures the external data source corresponding to the target worksheet structure, generates a dynamic worksheet that corresponds to the user's needs, and displays it to the user.

9. A zero-code worksheet dynamic generation device based on natural language, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions, which, when executed by the one or more processors, implement the steps of the natural language-based zero-code worksheet dynamic generation method as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that: The readable storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to implement the steps of the natural language-based zero-code worksheet dynamic generation method as described in any one of claims 1 to 7.

Images