Form generation method, system, device, storage medium and program product

Abstract

Embodiments of the present application provide a form generation method, system, device, storage medium and program product, the method comprising: in response to a user consultation session sent by a front end, determining a consultation scenario, and obtaining a form template corresponding to the consultation scenario. The form template includes identification information of a plurality of interface components and field attribute information corresponding to each of the plurality of interface components. The form template is sent to the front end, so that the front end obtains the plurality of interface components from a component library according to the identification information and renders the plurality of interface components according to the field attribute information corresponding to each of the plurality of interface components to obtain a target form. Through the above scheme, the back end only needs to identify the consultation scenario and issue the form template corresponding to the consultation scenario, and the front end can directly reuse the corresponding plurality of interface components in the component library based on the form template to dynamically render the target form. In this way, the form generation operations of the front end and the back end can be decoupled, and the form corresponding to the user consultation scenario can be generated flexibly without coupling.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a form generation method, system, device, storage medium, and program product. Background Technology

[0002] In current customer service systems, when processing user inquiries, users often need to fill out predefined forms to collect key information related to their inquiry intent, thereby improving service efficiency. For example, when a user initiates an inquiry session with customer service, a corresponding form is generated for the user to fill in the required information.

[0003] Currently, these forms are mostly generated using hard-coding. Specifically, each consultation scenario requires the separate development of a corresponding front-end interface and back-end processing logic, and the form structure is hardcoded into the front-end and back-end code respectively. This results in a high degree of coupling between the front-end and back-end. Therefore, if the form format needs to be adjusted or a new consultation scenario needs to be added, the front-end and back-end code must be modified simultaneously and re-integrated for testing. This approach has poor flexibility and is difficult to adapt to diverse consultation scenarios and rapidly changing form requirements. Summary of the Invention

[0004] This application provides a form generation method, system, device, storage medium, and program product to decouple the form generation operations of the front end and the back end, thereby achieving uncoupled and flexible generation of forms corresponding to user consultation scenarios.

[0005] In a first aspect, embodiments of this application provide a form generation method applied to a backend, the method comprising: In response to user inquiry sessions sent from the front end, determine the inquiry scenario; Obtain a form template corresponding to the consultation scenario. The form template includes identification information of multiple interface components and field attribute information corresponding to each of the multiple interface components. The form template is sent to the front end, so that the front end can obtain the multiple interface components from the component library according to the identification information and render the multiple interface components according to the field attribute information corresponding to each of the multiple interface components to obtain the target form.

[0006] Secondly, embodiments of this application provide a form generation device applied to a backend, the device comprising: The determination module is used to determine the consultation scenario in response to user consultation sessions sent from the front end; The acquisition module is used to acquire a form template corresponding to the consultation scenario. The form template includes identification information of multiple interface components and field attribute information corresponding to each of the multiple interface components. The sending module is used to send the form template to the front end, so that the front end can obtain the multiple interface components from the component library according to the identification information and render the multiple interface components according to the field attribute information corresponding to each of the multiple interface components to obtain the target form.

[0007] Thirdly, embodiments of this application provide an electronic device, including: a memory, a processor, and a communication interface; wherein, the memory stores a computer program, and when the computer program is executed by the processor, the processor can at least implement the form generation method as described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor of an electronic device, enables the processor to at least implement the form generation method as described in the first aspect.

[0009] Fifthly, embodiments of this application provide a computer program product, including: a computer program or instructions that, when executed by a processor of an electronic device, enable the processor to at least implement the form generation method as described in the first aspect.

[0010] Sixthly, embodiments of this application provide a form generation method applied to a front-end, the method comprising: The user consultation session is sent to the backend so that the backend can determine the consultation scenario and the form template corresponding to the consultation scenario. The form template includes the identification information of multiple interface components and the field attribute information corresponding to each of the multiple interface components. Receive the form template; The plurality of interface components are obtained from the component library based on the identification information, and the plurality of interface components are rendered according to the field attribute information corresponding to each of the plurality of interface components to obtain the target form.

[0011] Seventhly, embodiments of this application provide a form generation apparatus applied to a front-end, the apparatus comprising: The sending module is used to send the user consultation session to the backend so that the backend can determine the consultation scenario and the form template corresponding to the consultation scenario. The form template includes the identification information of multiple interface components and the field attribute information corresponding to each of the multiple interface components. A receiving module is used to receive the form template; The rendering module is used to obtain the plurality of interface components from the component library according to the identification information, and to render the plurality of interface components according to the field attribute information corresponding to each of the plurality of interface components to obtain the target form.

[0012] Eighthly, embodiments of this application provide an electronic device, including: a memory, a processor, and a communication interface; wherein, the memory stores a computer program, and when the computer program is executed by the processor, the processor can at least implement the form generation method as described in the sixth aspect.

[0013] In a ninth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor of an electronic device, enables the processor to at least implement the form generation method as described in the sixth aspect.

[0014] In a tenth aspect, embodiments of this application provide a computer program product, including: a computer program or instructions that, when executed by a processor of an electronic device, enable the processor to at least implement the form generation method as described in the sixth aspect.

[0015] Eleventhly, embodiments of this application provide a form generation system, including a front-end and a back-end; The backend is used to respond to user consultation sessions sent by the frontend, determine the consultation scenario, and obtain a form template corresponding to the consultation scenario. The form template includes identification information of multiple interface components and field attribute information corresponding to each of the multiple interface components. The front end is used to receive the form template, obtain the multiple interface components from the component library according to the identification information, and render the multiple interface components according to the field attribute information corresponding to each of the multiple interface components to obtain the target form.

[0016] In the form generation scheme provided in this application embodiment, form templates corresponding to various consultation scenarios are pre-configured in the backend. Each form template specifies the identification information of multiple interface components it contains and the field attribute information corresponding to each of the multiple interface components. In this way, the frontend no longer needs to hard-code the form logic related to the consultation scenario. The form template is parsed and the components are rendered according to a unified rendering logic to generate a target form that matches the current consultation scenario, thus achieving decoupling between the frontend and the backend.

[0017] In practice, after the frontend receives a user consultation session, it sends the session to the backend. The backend responds to the frontend's consultation session by determining the corresponding consultation scenario. Then, the backend retrieves the form template corresponding to that scenario. This template includes identifiers for multiple UI components and their respective field attributes. The backend then sends the form template to the frontend. The frontend retrieves multiple UI components from the component library based on their identifiers and renders them according to their respective field attributes to obtain the target form.

[0018] In the above solution, the backend only needs to identify the consultation scenario and issue the form template corresponding to the consultation scenario. The frontend can directly parse the form template and reuse and render these interface components from the component library according to the identification information of multiple interface components in the form template to dynamically generate the target form. This can decouple the form generation operations of the frontend and the backend, improve the flexibility and response efficiency of form generation, and adapt to diverse consultation scenarios. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of a form generation system provided in an embodiment of this application; Figure 2 This is an application diagram of a form generation system provided in an embodiment of this application; Figure 3 This is an application diagram illustrating another form generation system provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating the application of a form generation method provided in an embodiment of this application; Figure 5a A schematic diagram illustrating how to obtain the work order identifier corresponding to a work order record instance, as provided in an embodiment of this application; Figure 5b A schematic diagram illustrating an embodiment of this application for obtaining a form template; Figure 5c This is a schematic diagram illustrating the generation of a work order according to an embodiment of this application. Figure 6 A flowchart for rendering a target form provided in an embodiment of this application; Figure 7aA schematic diagram of a front-end application interface provided in an embodiment of this application; Figure 7b A schematic diagram of a target form provided in an embodiment of this application; Figure 8 A flowchart illustrating a form generation method provided in this application embodiment; Figure 9 A flowchart illustrating another form generation method provided in this application embodiment; Figure 10 This is a schematic diagram of the structure of a form generation device provided in an embodiment of this application; Figure 11 To and Figure 10 A schematic diagram of the electronic device corresponding to the form generation device provided in the illustrated embodiment; Figure 12 This is a schematic diagram of another form generation device provided in an embodiment of this application; Figure 13 To and Figure 12 The illustrated embodiment provides a schematic diagram of the electronic device corresponding to the form generation device. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] It should be noted that, in the cases involving user information in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0023] Furthermore, the timing of the steps in the following method embodiments is merely an example and not a strict limitation.

[0024] The following is an explanation of some terms used in the embodiments of this application.

[0025] Data Schema: A JSON format is used to describe the data structure. In this embodiment, a Schema is used to define the configuration information for each field in the form.

[0026] Form Template: Used to describe the structure of a form. In this embodiment, the form template is configured via a schema and stored in a database.

[0027] User Work Order Record Identifier (userWorkOrderId): An identifier used to uniquely associate a form with its corresponding user work order.

[0028] In customer service scenarios, users often need to fill out predefined forms to collect key information related to their consultation intent. Currently, these forms are mostly generated using hard-coding. Specifically, each consultation scenario requires the separate development of a corresponding front-end interface and back-end processing logic, with the form structure hard-coded into both the front-end and back-end code. This results in high coupling between the front-end and back-end. Whenever a new consultation scenario is added or the form format needs to be adjusted, both the front-end and back-end code must be modified synchronously, and multiple integration tests are required before deployment. This approach is inefficient, costly to maintain, and lacks flexibility, making it difficult to adapt to diverse consultation scenarios and rapidly changing form requirements.

[0029] To address the aforementioned technical issues, this application provides a novel form generation solution. In this solution, the backend pre-configures form templates corresponding to various consultation scenarios. Each form template specifies the identification information of its multiple interface components and the corresponding field attribute information of each component. This eliminates the need for the frontend to hard-code form logic related to the consultation scenario. By parsing the form templates issued by the backend according to a unified rendering logic, the frontend can reuse and render the corresponding multiple interface components from the component library to generate a target form that matches the current consultation scenario. This decouples the form generation operations of the frontend and backend, improving the flexibility and response efficiency of form generation.

[0030] It should be noted that, in the embodiments of this application, the backend sending a "form template" to the frontend should be understood as sending the relevant descriptive information (including but not limited to identifiers and various attributes) of the interface components contained in the form template to the frontend.

[0031] The form generation technical solutions provided in the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0032] The form generation method provided in this application embodiment can be applied to, for example, Figure 1 The form generation system shown includes a front-end and a back-end.

[0033] The backend is primarily used to pre-configure corresponding form templates for various consultation scenarios. In practical applications, developers can configure separate form templates for each consultation scenario on the backend according to actual service requirements and store the configured form templates in the database. This allows the backend to retrieve the form template corresponding to the current consultation scenario from the database when performing form generation tasks later. For example, there might be one form template for logistics exceptions and another for refunds.

[0034] Each form template describes the multiple fields that users need to fill in for the corresponding consultation scenario, as well as the interface component information used for each field. The interface component information includes the component type, validation information, labels displayed on the component, and field identifiers, etc.

[0035] Specifically, each form template specifies the identification information of its multiple UI components and the field attribute information for each component. The identification information clarifies which front-end UI components should be used. The field attribute information may include the field identifier in the form, the text label displayed next to the field, the data type of the field, whether the field is required, the default value during field initialization, rich text hints, placeholder text, input validation rules, etc.

[0036] In this way, form structure and user interaction logic are abstracted into configurable data. This means that when the structure of a particular form needs modification, only the corresponding form template needs to be changed; the form structure can be flexibly modified without changing the code. Similarly, when a new form for a consultation scenario needs to be added, a form template for that scenario can be configured, and the addition of a new consultation scenario form can be flexibly supported without modifying the code, improving form generation efficiency and form adjustment response efficiency.

[0037] Furthermore, security designs can be implemented for each form template. For example, rich text fields contained in the form template can be sanitized using a sanitization library (DOMPurify), the validity of the form structure configuration (Schema) can be checked during compilation for fully statically typed superset languages ​​(TypeScript type definitions), and friendly prompts can be provided for unknown component types so as not to affect the normal rendering of other fields.

[0038] In addition, to achieve unified management of form structures and collaborative processing of form generation tasks between the front-end and back-end, in an optional embodiment, a standardized schema protocol specification can be designed to configure these form templates. This schema protocol specification defines the identification information of multiple UI components required for form generation, as well as the corresponding field attribute information for each UI component. Furthermore, this schema protocol specification can also define a unified validation rule protocol and supported component types. The unified validation rule protocol standardizes the validation logic for each field, ensuring consistent behavior during parsing and validation execution.

[0039] In other words, using this Schema protocol specification not only standardizes how the backend organizes the various data in the form template, but also provides the frontend with a set of parsable data standards. Based on this Schema protocol specification, the frontend can automatically parse any form template that conforms to the specification. In this way, the frontend no longer needs to hardcode the form logic related to the consultation scenario. It only needs to parse the form template issued by the backend, and can reuse and render multiple corresponding interface components from the component library to generate the target form that matches the current consultation scenario, thus achieving decoupling between the frontend and the backend.

[0040] After configuring the form templates for each of the above consultation scenarios, the backend can also identify the consultation intent corresponding to the user's consultation session and determine the consultation scenario corresponding to the consultation intent when processing form generation operations in the future, so as to send the template form corresponding to the consultation scenario to the frontend.

[0041] The front-end is primarily used to dynamically render multiple UI components that match the current consultation scenario to obtain the target form. Specifically, in practical applications, after receiving the form template from the back-end, the front-end parses the template according to a unified rendering logic to extract the identifiers and field attributes of the multiple UI components contained within. Based on the identifiers, it selects corresponding UI components from a general component library and dynamically renders these components based on their corresponding field attributes to generate the target form. When rendering these multiple UI components, the front-end can use a dynamic rendering engine. Without relying on hard-coded component structures, it automatically parses the form configuration information from the template at runtime and dynamically renders the multiple UI components based on this configuration information.

[0042] Specifically, in one optional embodiment, after the front end receives the form template sent by the back end, it calls the dynamic rendering engine to find the corresponding component implementation code from the component mapping table according to the identification information of each interface component, runs the component implementation code, and initializes the interface component in combination with the field attribute information of each interface component to complete the rendering.

[0043] The component mapping table stores the identifiers of each UI component and their corresponding implementation code. When a form needs to be rendered, the front-end retrieves and loads the corresponding UI component from the component mapping table based on the identifiers configured in the form template. This component mapping table rendering method separates the identifiers of UI components from their corresponding implementation code, allowing a single set of rendering code to adapt to all consultation scenarios.

[0044] Furthermore, when a form needs to be extended with new interface components, it is only necessary to register the component mapping relationship corresponding to the new interface component in the component mapping table. There is no need to modify the core logic of form rendering, which conforms to the Open / Closed Principle (OCP) in software engineering, making the form generation system more flexible and easier to maintain.

[0045] Using the above method, the front-end can parse any form template conforming to the schema protocol without additional hardcoding of the specific form structure, dynamically rendering multiple interface components corresponding to various consultation scenarios. This enables flexible and efficient rendering of forms for different consultation scenarios, achieving dynamic form capabilities that are ready to go upon configuration. In other words, the front-end can complete the parsing of form templates and the rendering of multiple interface components according to a unified rendering logic. The front-end doesn't care what content should be displayed on specific interface components; it directly renders them. Furthermore, the component mapping table decouples the front-end from specific component implementations; regardless of the implementation method of a component, the front-end doesn't care and uses the same rendering logic.

[0046] In summary, by abstracting the form structure and interaction logic into configurable form templates that conform to a unified schema protocol specification, this system achieves complete decoupling between the front-end and back-end in the form generation process. Furthermore, during form generation, the back-end only focuses on identifying the consultation scenario and distributing the form template, while the front-end only parses the form template and renders the corresponding multiple UI components. Therefore, it can flexibly support adding or adjusting forms corresponding to consultation scenarios without modifying the code, improving the system's form generation scalability and response efficiency.

[0047] The above describes the functions and implementation principles of each component in the form generation system. Next, we will discuss the specific implementation process of dynamically generating forms using this system.

[0048] In practical applications, when a user wants to consult customer service about a certain issue, they can send a user consultation session to customer service through the front-end interface. After receiving the user consultation session, the front-end forwards it to the back-end. Upon receiving the user consultation session from the front-end, the back-end responds to the session and determines the consultation scenario.

[0049] In the specific implementation process, one possible way for the backend to determine the consultation scenario is to respond to the user consultation session sent by the frontend, identify the consultation intent corresponding to the user consultation session, and determine the consultation scenario corresponding to the consultation intent.

[0050] Among these methods, a large language model can be used to identify the consultation intent corresponding to a user's consultation session; keyword matching can also be combined to identify the consultation intent corresponding to a user's consultation session; or a pre-set matching rule can be used to identify the consultation intent corresponding to a user's consultation session; or a pre-trained intent classifier can be used to identify the consultation intent corresponding to a user's consultation session.

[0051] Once a consultation intent is identified, a pre-defined scenario mapping table is used to determine the corresponding consultation scenario. This scenario mapping table stores the mapping relationship between consultation intents and their corresponding consultation scenarios. For example, if the identified consultation intent is to inquire about refund progress, the matched consultation scenario would be an e-commerce after-sales service scenario.

[0052] However, in practical applications, not every user consultation session needs to use a form to collect key information related to the consultation intent. After identifying the consultation intent, it is possible to further determine whether the consultation intent has a pre-set consultation scenario associated with it, so as to determine whether it is necessary to use a form to collect key information related to the consultation intent.

[0053] For pre-defined consultation scenarios where there is no need to use forms to collect key information (i.e., the consultation intent is unrelated), a large language model or a pre-trained conversation response model is used to engage in intelligent dialogue with the user to provide relevant solutions to the user's consultation conversation. For pre-defined consultation scenarios where there is a need to use forms to collect key information (i.e., the consultation intent is related), subsequent form generation operations are performed.

[0054] When it is determined that subsequent form generation operations should continue, the form template corresponding to the consultation scenario is first obtained. This form template includes identification information for multiple interface components and field attribute information for each component. Furthermore, the identification information can be the identifier for each interface component.

[0055] Since the pre-configured form templates for each consultation scenario are stored in the database, once the backend determines the consultation scenario corresponding to the consultation intent, it can directly retrieve the corresponding form template from the database and send the form template to the frontend.

[0056] The front-end receives the form template and retrieves multiple UI components from the component library based on the identifiers of the various UI components included in the template. It then renders these UI components according to their respective field attributes to obtain the template form. The component library stores various general-purpose UI components, such as single-line input boxes, multi-line text fields, radio button groups, dropdown selectors, image upload controls, and date range spaces.

[0057] The front-end receives a form template corresponding to the consultation scenario and parses it to extract the identifiers of multiple UI components and their respective field attributes. After obtaining the identifiers, it searches the component mapping table for the UI components corresponding to those identifiers.

[0058] That is, by parsing, the field attribute information corresponding to each of the multiple interface components is obtained, which is used as input parameters for the multiple interface components, and then transmitted to the corresponding interface components to render the interface components based on the field attribute information.

[0059] In summary, in this embodiment, the backend only needs to identify the consultation scenario and issue a form template corresponding to the consultation scenario. The frontend can directly parse the form template and reuse and render these interface components from the component library according to the identification information of multiple interface components in the form template to dynamically generate the target form. This can decouple the form generation operations of the frontend and the backend, improve the flexibility and response efficiency of form generation, and adapt to diverse consultation scenarios.

[0060] In addition, after the target form is generated on the front end, it can also be displayed on the front-end interface, so that users can fill in the specific content of each field in the target form on the front-end interface to collect key information related to the user's consultation intent.

[0061] The target form itself is merely a carrier of information; its core value lies in transforming the specific content corresponding to each field entered by the user into an executable service request to resolve the user's inquiry. If it only remains at the data collection level without subsequent processing, it will be unable to provide substantive service to the user, thus impacting the user experience.

[0062] Specifically, the service requests corresponding to different inquiry intentions vary significantly. For example, if the identified inquiry intention is a password reset, then security verification and account operations need to be triggered; if the identified inquiry intention is a refund progress inquiry, then the e-commerce system needs to be accessed to check the corresponding refund progress. These service requests involve different processing logics and different processing systems. Therefore, after the user enters information in the target form corresponding to the front-end interface, the service flow processing is executed.

[0063] Specifically, the front-end can also respond to user input in the target form, generate a work order, and send it to the back-end. The back-end then receives the work order from the front-end and, based on its type, forwards it to the corresponding processing system. A work order is a traceable and assignable task entity generated from the target form, and each processing system can perform corresponding service processing based on the work order. The processing system refers to the back-end service platform capable of receiving work orders and executing corresponding service processing; specifically, this processing system includes downstream systems associated with the form generation system, such as the intelligent customer service system, the operations system (GOC), and the form system.

[0064] Furthermore, after receiving the work order, the backend can parse it to identify its type and then accurately distribute it to the corresponding processing system according to the preset routing rules. This enables automated flow and efficient handling of service requests, ensuring that user-initiated service requests receive a rapid response.

[0065] As described above, by integrating user intent recognition, dynamic form generation, corresponding work order generation, and work order forwarding to the appropriate processing system, the backend at the dialogue layer can accurately identify user inquiries and precisely match the corresponding form template. At the form layer, the frontend dynamically renders the target form based on the template for user input. At the work order layer, the backend converts the user-inputted target form into a work order and synchronizes it to the corresponding processing system. This achieves end-to-end automated processing from user inquiries to work order creation, enabling rapid response to user requests and providing corresponding services without manual intervention.

[0066] Furthermore, in practical applications, users often express themselves unclearly or have multiple potential consultation intentions, leading to a certain degree of uncertainty in intent recognition. Therefore, to improve the accuracy of intent recognition and avoid generating unnecessary target forms due to misjudgment, thus affecting user experience, in one optional embodiment, after determining the consultation intent, the user can be asked to confirm it before proceeding with the subsequent form generation operation.

[0067] The following is combined with Figure 2The specific implementation process is explained in detail.

[0068] The frontend receives user consultation sessions and forwards them to the backend. Upon receiving the consultation sessions from the frontend, the backend responds by identifying the consultation intent and determining the corresponding consultation scenario.

[0069] The backend then sends the inquiry intent to the frontend. The frontend receives the inquiry intent from the backend and displays a confirmation interaction component containing the inquiry intent, allowing the user to confirm whether to trigger the corresponding interaction based on this confirmation interaction component.

[0070] Next, the backend retrieves the form template corresponding to the consultation scenario based on the confirmation interaction instruction information sent by the frontend based on the user's operation on the confirmation interaction component, and sends the form template to the frontend. The frontend retrieves multiple interface components from the component library based on the identification information, and renders multiple interface components according to the field attribute information corresponding to each of the multiple interface components to obtain the target form.

[0071] In another optional embodiment, after the backend obtains the form template corresponding to the consultation scenario, it can also generate a work order identifier corresponding to the form template and send the work order identifier to the frontend.

[0072] The following is combined with Figure 3 The specific implementation process is explained in detail.

[0073] In specific implementation, such as Figure 3 As shown, the front-end receives user consultation sessions and sends them to the back-end. After receiving the user consultation sessions from the front-end, the back-end responds by identifying the consultation intent corresponding to the user consultation session and determining the consultation scenario corresponding to the consultation intent.

[0074] Then, the backend locates the form template corresponding to the consultation scenario, generates a work order identifier corresponding to the form template, and sends the work order identifier and the consultation intent to the frontend. Alternatively, the backend can first create a work order instance corresponding to the form template, generate a work order identifier for that work order instance, and send the work order identifier to the frontend.

[0075] The front-end receives the consultation intent and work order identifier from the back-end, displays a confirmation interaction component containing the consultation intent, and associates the work order identifier with the corresponding interface redirect link. After the interface redirect link, the front-end displays the interface corresponding to the target form, allowing the user to trigger the confirmation operation on that interface. The interface corresponding to the interface redirect link is used to render the target form.

[0076] When a user triggers a confirmation action on the confirmation interaction component on this interface, the front end responds to the user's action on the confirmation interaction component by sending a confirmation interaction instruction message containing a work order identifier to the back end.

[0077] Then, the backend, based on the work order identifier contained in the confirmation interaction instruction information, queries the corresponding form template to determine the form template and sends it to the frontend. In practice, the relevant information of multiple UI components in the form template (the identifiers of the multiple UI components and the corresponding field attribute information) can also be directly sent to the frontend. Finally, the frontend receives the form template sent by the backend, parses it, extracts identification information and field attribute information corresponding to multiple UI components, and retrieves multiple UI components from the component library based on the identification information. Then, it renders these UI components according to their respective field attribute information to obtain the target form. Specifically, based on the identification information, it searches for the component implementation code corresponding to these UI components in the component library, runs the component implementation code, and passes the field attribute information corresponding to each UI component as attribute parameters to the respective component implementation code, rendering the multiple UI components to obtain the target form.

[0078] Furthermore, during the dynamic form generation process, each interface component not only handles data input but also ensures that the collected information conforms to a unified validation protocol. To this end, corresponding input validation rules can be configured for the fields in the form template. After the user enters information into the target form, the front-end can also validate the user's input based on preset input validation information.

[0079] Specifically, when the target UI component's corresponding field attribute information includes input validation information, the front-end can also respond to the target information entered by the user in the target UI component during form generation, and validate the target information based on the input validation information. Once validation is successful, multiple UI components are rendered according to their respective field attribute information to obtain the target form. The target UI component is any one of the multiple UI components.

[0080] In summary, in this embodiment, the backend sends the consultation intent to the frontend, so that the frontend displays a confirmation interaction component containing the consultation intent, thereby further confirming the user's consultation intent, improving the accuracy of intent recognition, avoiding the generation of unnecessary target forms due to misjudgment, and improving the user experience.

[0081] To facilitate understanding of the specific implementation process of form generation in the above embodiments, the following will combine... Figure 4-6 This will illustrate the form generation process in a specific application scenario.

[0082] In specific implementation, such as Figure 4 As shown, when a user needs to consult customer service about a certain issue, they can send a user consultation session to customer service through the front-end interface. After receiving the user consultation session, the front-end forwards it to the back-end. The back-end responds to the user consultation session sent by the front-end by performing intent recognition to determine the consultation intent.

[0083] Next, the backend determines whether the consultation intent matches a preset consultation intent. If the consultation intent does not match a preset consultation intent, the backend uses a model to perform end-to-end interaction with the user. For example, the model generates common questions corresponding to the user's consultation intent and sends the generated common questions to the frontend so that the frontend can display the corresponding common questions. Alternatively, the model generates suggestions corresponding to the user's consultation intent and sends the generated suggestions to the frontend so that the frontend can display the corresponding suggestions.

[0084] If the consultation intent matches a preset consultation intent, the backend determines the consultation scenario corresponding to the consultation intent and retrieves the form template corresponding to that consultation scenario by looking up the scenario mapping table. The following section combines... Figures 5a-5b This section explains the specific process of obtaining the form template corresponding to this consultation scenario.

[0085] like Figure 5a As shown, when a user initiates a consultation request, the system identifies the consultation intent corresponding to the user's consultation session and calls the database interface to retrieve custom card data. This card data includes form template identification information obtained based on the consultation intent. Then, based on the form template identification information, the system queries the corresponding form configuration information from the form template table in the database. This form configuration information includes the component type and field attribute information for each field. After successfully retrieving the form configuration information, a new work order record instance associated with this form configuration information is created and added to the work order record table to return the work order identifier corresponding to the created work order record instance, ensuring that subsequent form status and user interactions can be persistently tracked.

[0086] Among them, the work order record instance is an empty work order that needs to be filled in. In this way, when the user triggers the confirmation interaction instruction information for the confirmation interaction component, the backend can find the form template based on the work order identifier and send it to the frontend. Then the frontend executes the rendering process based on the form template.

[0087] Specifically, such as Figure 5bAs shown, the system calls the query work order form structure interface. Based on the work order identifier, it queries the work order record table for the work order record instance corresponding to that identifier. Based on the work order record instance, it queries the form configuration information from the form template table, parses the form configuration information to determine the form template corresponding to the current inquiry, and then sends the form template to the front end for rendering.

[0088] In practice, after obtaining the form template corresponding to the consultation scenario, the backend sends the form template to the frontend, allowing the frontend to parse the form template based on the Schema protocol specification to obtain the identification information of multiple interface components included in the form template, as well as the field information corresponding to each interface component. Then, the frontend retrieves multiple interface components from the component library based on the parsed identification information and renders multiple interface components according to their respective field attribute information to obtain the target form.

[0089] The front-end can render and display the target form using form cards. In practice, the form card is sent to the user, and the target form is displayed on the corresponding page. The user can then input information into the displayed form to collect key information related to their inquiry intent. The following section will combine... Figure 6 The specific implementation process of using form cards to render and display the target form.

[0090] like Figure 6 As shown, when a user clicks a form card displayed in the session interface, it opens the associated H5 page. The corresponding redirect link on this page carries the user's work order record identifier (work order identifier), which serves as the unique identifier for this form session. When the front-end loads the page, it calls the work order form initialization service interface, passing in the user's work order record identifier. It then queries the corresponding work order record, finds the associated consultation scenario, and retrieves the form template corresponding to that consultation scenario, returning the form configuration information configured in that template. The rendering engine iterates through the form configuration information and, based on the identifier of each field in the form configuration information, searches for the corresponding UI component in the component mapping table. It then injects the field identifier, field tag, current value, validation rules, and other field attribute information as props, enabling dynamic rendering of the UI component.

[0091] Specifically, when rendering each UI component, validation rules (required fields, length limits, etc.) can be automatically bound based on a rule array, providing real-time validation feedback during user input. Furthermore, after the user completes the form, validation is performed uniformly. Once validation passes, the form data is serialized, and the work order creation interface is called to submit it to the backend, completing the work order creation.

[0092] In other words, after a user inputs information into the target form displayed in the form card, the front-end responds by generating a corresponding work order and sending it to the back-end. Specifically, for example... Figure 5c As shown, when a user fills in the corresponding information in the target form, the front-end generates a corresponding third-party work order based on the information entered. The back-end receives the third-party work order from the front-end and determines its type. Then, based on the type of the third-party work order, the back-end sends it to the processing system corresponding to that type.

[0093] After generating a third-party work order, it can be synchronized to the corresponding work order system based on its type. Ultimately, work orders from different processing systems can be aggregated into the workbench, creating corresponding local work orders. Third-party work orders are then bound to local work orders, and the status of each local work order is updated. The updated work order status is stored in the work order record table, enabling centralized management and tracking of third-party work orders.

[0094] By integrating user intent recognition, dynamic form generation, corresponding work order generation, and work order forwarding to the relevant processing system, end-to-end automated processing from user inquiries to work order creation is achieved. This allows for rapid response to user requests and provision of corresponding services without manual intervention.

[0095] The specific implementation process and the specific technical effects achieved in the embodiments of this application can be referred to the content of the above embodiments, and will not be repeated here.

[0096] The above situation is illustrated below with reference to Figure 7, which is a schematic diagram of a front-end application interface provided in an embodiment of this application.

[0097] like Figure 7a As shown, the user enters an order card stating "I want to inquire about this order" on the front-end interface. After receiving the order card, the front-end sends it to the back-end. The back-end recognizes the order card and uses the intelligent customer service response model to generate the response text "Are you picking up the package?" based on the order card. This response text is then sent to the front-end so that it can be displayed on the front-end interface to further confirm the user's inquiry intent.

[0098] Then, the user enters the conversation text "Official logistics hasn't picked up the goods" in the front-end interface. After receiving the conversation text, the front-end sends it to the back-end. Based on the conversation text and the order card, the back-end identifies the user's inquiry intent as "inquiry about delayed logistics pickup," determining the corresponding inquiry scenario as "logistics exception handling." Next, based on this inquiry scenario, the back-end locates the form template corresponding to the scenario and generates a work order identifier based on that template. The work order identifier is then bound to the form template.

[0099] The consultation intent and work order identifier are sent to the front end. The front end generates a confirmation interaction card, which displays a confirmation interaction component containing the consultation intent and the user's pending confirmation information. The corresponding interface jump link for this confirmation interaction card is associated with the work order identifier.

[0100] When a user triggers a confirmation action on the confirmation interaction component on the front-end interface, the front-end sends a confirmation interaction instruction to the back-end. The back-end, based on the work order identifier contained in the confirmation interaction instruction, determines the form template and sends it to the front-end. The front-end parses the form template, obtaining the identifier information of multiple interface components and their corresponding field attribute information. Based on the identifier information, it retrieves multiple interface components from the component library and renders them according to their respective field attribute information to obtain the issue collection form, such as... Figure 7b As shown.

[0101] The question collection form includes information such as the logistics company, tracking number, contact information, problem description / request, and an image upload button. Users can fill in the relevant information on the form to collect key information related to their inquiry intent.

[0102] The form generation process provided in this application will be described in detail below from the perspective of each component unit of the form generation system as the executing entity.

[0103] Figure 8 A flowchart of a form generation method provided in this application embodiment is shown below. Figure 8 As shown, this method is applied to the backend, and the method can specifically include the following steps: 801. Respond to the user inquiry session sent by the front end and determine the inquiry scenario.

[0104] 802. Obtain the form template corresponding to the consultation scenario. The form template includes the identification information of multiple interface components and the field attribute information corresponding to each of the multiple interface components.

[0105] 803. Send the form template to the front end so that the front end can obtain multiple interface components from the component library based on the identification information and render the multiple interface components according to the field attribute information of each of the multiple interface components to obtain the target form.

[0106] When the backend performs form generation, it first responds to the user inquiry session sent by the frontend and determines the inquiry scenario that matches the session. It then retrieves the form template corresponding to that scenario. The form template includes identifiers for multiple UI components and their respective field attributes. Finally, the backend sends the form template to the frontend, enabling it to retrieve multiple UI components from the component library based on the identifiers and render them according to their respective field attributes to obtain the target form.

[0107] In an optional embodiment, the method further includes: receiving a work order sent by the front end. The work order is generated by the front end based on user input information in a target form. Depending on the type of the work order, it is sent to the processing system corresponding to that type.

[0108] In an optional embodiment, the specific implementation process of determining the consultation scenario in response to a user consultation session sent by the front end can be as follows: in response to a user consultation session sent by the front end, identify the consultation intent corresponding to the user consultation session, and determine the consultation scenario corresponding to the consultation intent.

[0109] Optionally, the method further includes: sending a consultation intent to the front end, causing the front end to display a confirmation interaction component containing the consultation intent. Then, based on confirmation interaction instruction information sent by the front end based on the user's operation on the confirmation interaction component, a form template is sent to the front end.

[0110] In one optional embodiment, after obtaining the form template corresponding to the consultation scenario, the method further includes: generating a work order identifier corresponding to the form template, and sending the work order identifier to the front end, so that the front end associates the work order identifier with the interface jump link corresponding to the confirmation interaction component. The interface corresponding to the interface jump link is used to render the target form.

[0111] In one optional embodiment, the specific implementation process of sending the form template to the front end based on the confirmation interaction instruction information sent by the front end based on the user's operation on the confirmation interaction component can be as follows: determine the form template according to the work order identifier contained in the confirmation interaction instruction information, and send the form template to the front end.

[0112] The relevant technical content involved in the embodiments of this application can be referred to the specific content of the above embodiments.

[0113] In summary, the backend only needs to identify the consultation scenario and issue the form template corresponding to that scenario. The frontend can directly parse the form template and reuse and render these interface components from the component library based on the identification information of multiple interface components in the form template to dynamically generate the target form. This decouples the form generation operations of the frontend and backend, improves the flexibility and response efficiency of form generation, and adapts to diverse consultation scenarios.

[0114] Figure 9 A flowchart of another form generation method provided in the embodiments of this application is shown below. Figure 9 As shown, this method is applied to the front end, and it can specifically include the following steps: 901. Send the user's consultation session to the backend so that the backend can determine the consultation scenario and the form template corresponding to the consultation scenario. The form template includes the identification information of multiple interface components and the field attribute information corresponding to each of the multiple interface components.

[0115] 902. Receive form template.

[0116] 903. Obtain multiple interface components from the component library based on the identification information, and render the multiple interface components according to the field attribute information corresponding to each of the multiple interface components to obtain the target form.

[0117] When the front-end performs form generation, it first sends the user's inquiry session to the back-end so that the back-end can determine the inquiry scenario and the corresponding form template. Then, it receives the form template sent by the back-end and parses it to extract the identification information of multiple interface components and the field attribute information of each component.

[0118] Next, multiple UI components are retrieved from the component library based on the identification information, and the multiple UI components are rendered according to the field attribute information corresponding to each of the multiple UI components to obtain the target form.

[0119] In an optional embodiment, the method further includes: generating a work order in response to a user's information input operation in a target form, and sending the work order to a backend.

[0120] In another optional embodiment, the method further includes: receiving a consultation intent sent by the backend and displaying a confirmation interaction component containing the consultation intent. The consultation intent is obtained by the backend through intent recognition based on the user's consultation session.

[0121] In an optional embodiment, the method further includes: receiving a work order identifier corresponding to the form template sent by the backend, and associating the work order identifier with the interface jump link corresponding to the confirmation interaction component. The interface corresponding to the interface jump link is used to render the target form. In response to the user's operation on the confirmation interaction component, a confirmation interaction instruction message containing the work order identifier is sent to the backend, so that the backend determines the form template based on the work order identifier and sends the form template to the frontend.

[0122] Optionally, the field attribute information corresponding to the target interface component includes input validation information, wherein the target interface component is any one of multiple interface components. Based on this, the method further includes: in response to target information input by the user in the target interface component, validating the target information based on the input validation information.

[0123] The relevant technical content involved in the embodiments of this application can be referred to the specific content of the above embodiments.

[0124] In summary, in this embodiment, the backend only needs to identify the consultation scenario and issue a form template corresponding to the consultation scenario. The frontend can directly parse the form template and reuse and render these interface components from the component library according to the identification information of multiple interface components in the form template to dynamically generate the target form. This can decouple the form generation operations of the frontend and the backend, improve the flexibility and response efficiency of form generation, and adapt to diverse consultation scenarios.

[0125] The form generation apparatus of one or more embodiments of this application will be described in detail below. Those skilled in the art will understand that these apparatuses can all be configured using commercially available hardware components through the steps taught in this solution.

[0126] Figure 10 This is a schematic diagram of the structure of a form generation device provided in an embodiment of this application, as shown below. Figure 10 As shown, the device is applied to the backend. Specifically, the device includes: a determination module 11, an acquisition module 12, and a sending module 13.

[0127] Module 11 is used to determine the consultation scenario in response to user consultation sessions sent from the front end.

[0128] The acquisition module 12 is used to acquire a form template corresponding to the consultation scenario. The form template includes identification information of multiple interface components and field attribute information corresponding to each of the multiple interface components.

[0129] The sending module 13 is used to send the form template to the front end, so that the front end can obtain the multiple interface components from the component library according to the identification information and render the multiple interface components according to the field attribute information corresponding to each of the multiple interface components to obtain the target form.

[0130] In an optional embodiment, the sending module 13 is further configured to: receive a work order sent by the front end. The work order is generated by the front end based on user input information in a target form. Depending on the type of the work order, the work order is sent to the processing system corresponding to that type.

[0131] In an optional embodiment, the determining module 11 is specifically used to: in response to a user consultation session sent by the front end, identify the consultation intent corresponding to the user consultation session, and determine the consultation scenario corresponding to the consultation intent.

[0132] Optionally, the determining module 11 is further configured to: send the consultation intent to the front end, so that the front end displays a confirmation interaction component containing the consultation intent; and send a form template to the front end based on the confirmation interaction instruction information sent by the front end based on the user's operation on the confirmation interaction component.

[0133] In an optional embodiment, after obtaining the form template corresponding to the consultation scenario, the obtaining module 12 is further configured to: generate a work order identifier corresponding to the form template, and send the work order identifier to the front end, so that the front end associates the work order identifier with the interface jump link corresponding to the confirmation interaction component. The interface corresponding to the interface jump link is used to render the target form.

[0134] In an optional embodiment, the sending module 13 is specifically used to: determine a form template based on the work order identifier contained in the confirmation interaction instruction information, so as to send the form template to the front end. Figure 8 The device shown can perform the steps described in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0135] In one possible design, the above Figure 10 The structure of the form generation device shown can be implemented as an electronic device, such as... Figure 11 As shown, the electronic device may include: a memory 21, a processor 22, and a communication interface 23. The memory 21 stores a computer program, which, when executed by the processor 22, enables the processor 22 to at least implement the form generation method executed by the backend as described in the preceding embodiments.

[0136] The aforementioned memory 21 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0137] Figure 12 This is a schematic diagram of another form generation device provided in an embodiment of this application, as shown below. Figure 12 As shown, the device is applied to the front end. Specifically, the device includes: a sending module 31, a receiving module 32, and a rendering module 33.

[0138] The sending module 31 is used to send the user consultation session to the backend so that the backend can determine the consultation scenario and the form template corresponding to the consultation scenario. The form template includes the identification information of multiple interface components and the field attribute information corresponding to each of the multiple interface components.

[0139] The receiving module 32 is used to receive the form template.

[0140] The rendering module 33 is used to obtain the plurality of interface components from the component library according to the identification information, and to render the plurality of interface components according to the field attribute information corresponding to each of the plurality of interface components to obtain the target form.

[0141] In an optional embodiment, the rendering module 33 is further configured to: generate a work order in response to the user's information input operation in the target form, and send the work order to the backend.

[0142] In another optional embodiment, the sending module 31 is further configured to: receive a consultation intent sent by the backend, and display a confirmation interaction component containing the consultation intent. The consultation intent is obtained by the backend through intent recognition based on the user's consultation session.

[0143] In an optional embodiment, the rendering module 33 is further configured to: receive a work order identifier corresponding to the form template sent by the backend, and associate the work order identifier with the interface jump link corresponding to the confirmation interaction component. The interface corresponding to the interface jump link is used to render the target form.

[0144] In an optional embodiment, the sending module 31 is further configured to: in response to the user's operation on the confirmation interaction component, send confirmation interaction instruction information containing a work order identifier to the backend, so that the backend determines the form template according to the work order identifier and sends the form template to the frontend.

[0145] Optionally, the field attribute information corresponding to the target interface component includes input verification information, wherein the target interface component is any one of multiple interface components. Based on this, the rendering module 33 is further configured to: in response to target information input by the user in the target interface component, verify the target information according to the input verification information.

[0146] Figure 12 The device shown can perform the steps described in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0147] In one possible design, the above Figure 12 The structure of the form generation device shown can be implemented as an electronic device, such as... Figure 13 As shown, the electronic device may include: a memory 41, a processor 42, and a communication interface 43. The memory 41 stores a computer program, which, when executed by the processor 42, enables the processor 42 to at least implement the form generation method executed by the backend as described in the previous embodiment.

[0148] The aforementioned memory 41 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0149] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, digital video disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium.

[0150] Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above method embodiments.

[0151] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0152] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of a necessary general-purpose hardware platform, or by a combination of hardware and software. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a computer product. This application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0153] Finally, it should be noted that 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 process, method, article, or apparatus. Without further limitation, 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 that element.

[0154] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A form generation method characterized by, Applied to the backend, the method includes: In response to user inquiry sessions sent from the front end, determine the inquiry scenario; Obtain a form template corresponding to the consultation scenario. The form template includes identification information of multiple interface components and field attribute information corresponding to each of the multiple interface components. The form template is sent to the front end, so that the front end can obtain the multiple interface components from the component library according to the identification information and render the multiple interface components according to the field attribute information corresponding to each of the multiple interface components to obtain the target form.

2. The method according to claim 1, characterized in that, The method further includes: Receive work orders sent by the front end, wherein the work orders are generated by the front end based on the user's input information in the target form; Based on the type of the work order, the work order is sent to the processing system corresponding to that type.

3. The method according to claim 1, characterized in that, The response to the user inquiry session sent by the front end determines the inquiry scenario, including: In response to a user consultation session sent from the front end, the consultation intent corresponding to the user consultation session is identified; Determine the consultation scenario corresponding to the consultation intent.

4. The method according to claim 3, characterized in that, The method further includes: The consultation intent is sent to the front end, so that the front end displays a confirmation interaction component containing the consultation intent; Sending the form template to the front end includes: The form template is sent to the front end based on the confirmation interaction instruction information sent by the front end based on the user's operation on the confirmation interaction component.

5. The method according to claim 4, characterized in that, After obtaining the form template corresponding to the consultation scenario, the method further includes: Generate a work order identifier corresponding to the form template; The work order identifier is sent to the front end so that the front end associates the work order identifier with the interface jump link corresponding to the confirmation interaction component. The interface corresponding to the interface jump link is used to render the target form. Sending the form template to the front end based on the confirmation interaction instruction information sent by the front end based on the user's operation on the confirmation interaction component includes: Based on the work order identifier contained in the confirmation interaction instruction information, the form template is determined and sent to the front end.

6. A form generation method, characterized in that, Applied to the front end, the method includes: The user consultation session is sent to the backend so that the backend can determine the consultation scenario and the form template corresponding to the consultation scenario. The form template includes the identification information of multiple interface components and the field attribute information corresponding to each of the multiple interface components. Receive the form template; The plurality of interface components are obtained from the component library based on the identification information, and the plurality of interface components are rendered according to the field attribute information corresponding to each of the plurality of interface components to obtain the target form.

7. The method according to claim 6, characterized in that, The method further includes: In response to the user's information input operation in the target form, a work order is generated and sent to the backend.

8. The method according to claim 6, characterized in that, The method further includes: The system receives the consultation intent sent by the backend, which is obtained by the backend through intent recognition based on the user's consultation session. Displays a confirmation interaction component that includes the stated consultation intent.

9. The method according to claim 8, characterized in that, The method further includes: Receive the work order identifier sent by the backend that corresponds to the form template; The work order identifier is associated with the interface jump link corresponding to the confirmation interaction component, and the interface corresponding to the interface jump link is used to render the target form. In response to the user's operation on the confirmation interaction component, a confirmation interaction instruction message containing the work order identifier is sent to the backend, so that the backend determines the form template based on the work order identifier and sends the form template to the frontend.

10. The method according to claim 6, characterized in that, The field attribute information corresponding to the target interface component includes: input verification information; the target interface component is any one of the plurality of interface components; The method further includes: In response to the target information entered by the user in the target interface component, the target information is verified according to the input verification information.

11. A form generation system, characterized in that, Including front-end and back-end; The backend is used to respond to user consultation sessions sent by the frontend, determine the consultation scenario, and obtain a form template corresponding to the consultation scenario. The form template includes identification information of multiple interface components and field attribute information corresponding to each of the multiple interface components. The front end is used to receive the form template, obtain the multiple interface components from the component library according to the identification information, and render the multiple interface components according to the field attribute information corresponding to each of the multiple interface components to obtain the target form.

12. An electronic device, characterized in that, include: The device includes a memory, a processor, and a communication interface; wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the form generation method as described in any one of claims 1 to 6 or 7 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor of an electronic device, causes the processor to perform the form generation method as claimed in any one of claims 1 to 6 or 7 to 10.

14. A computer program product, characterized in that, include: A computer program or instruction that, when executed by a processor of an electronic device, causes the processor to perform the form generation method as claimed in any one of claims 1 to 6 or 7 to 10.

Images