Document data determination method and apparatus, storage medium, and program product

Abstract

The application discloses a kind of determination methods, device, storage medium and program product of document data. It is related to artificial intelligence and financial technology field, the method comprises: data acquisition is carried out to the data associated with electronic payment function, obtain first data set, wherein the first data set includes: source code data and configuration file for realizing electronic payment function;Data extraction and format conversion are carried out to the first data set, obtain second data set;Determine target prompt word based on the second data set and preset project specification file;The target prompt word is input into target model, obtain first project document, wherein the first project document includes;Interface document of the electronic payment function, wherein the model type of the target model includes: large language model. Through the present application, the interface document of the related art is manually maintained fast payment function, and the problem of high data loss degree of interface document is solved.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and financial technology, and more specifically, to a method, apparatus, storage medium, and program product for determining document data. Background Technology

[0002] With the rapid development of electronic payment services in financial institutions, quick payment has become one of the most commonly used transaction methods in the Internet scenario. However, the interface specifications of quick payment are frequently changed, involving many aspects such as message format, business functions, parameter verification, and third-party channel protocols.

[0003] In related technologies, project documentation (including interface documentation) is mainly maintained through manual summarization. This involves manually writing field descriptions, comparing historical versions, and inferring logic from code. Most projects rely on developers manually editing interface descriptions, code comments, and integration guidelines, then manually reading the code to understand the business logic, and finally writing interface specifications. Due to the long system lifespan (up to ten years), frequent developer turnover, and large project size, some business project documentation is missing or outdated, resulting in low usability. For example, requirement changes are usually prioritized for deployment, leading to delays in document updates. Frequent changes to business logic, interfaces, and fields often cause document updates to lag behind code updates, resulting in inconsistencies or missed changes. This leads to incomplete information for subsequent feature maintainers, impacting system stability. Code details, variable configurations, and the corresponding logic between business requirements and code often only exist in the developers' experience, making knowledge difficult to transfer after staff leave or change roles, and hindering the completion of project documentation.

[0004] There is currently no effective solution to the problem of high data incompleteness in the interface documentation of the quick payment function, which is manually maintained in related technologies. Summary of the Invention

[0005] The main objective of this application is to provide a method, apparatus, storage medium, and program product for determining document data, in order to solve the problem of high data loss in the interface documents of the quick payment function that are manually maintained in the related art.

[0006] To achieve the above objectives, according to one aspect of this application, a method for determining document data is provided. The method includes: collecting data associated with an electronic payment function to obtain a first dataset, wherein the first dataset includes source code data and configuration files for implementing the electronic payment function; extracting data and converting the format of the first dataset to obtain a second dataset; determining target prompt words based on the second dataset and a preset project specification file, wherein the preset project specification file includes N constraints, where N is a positive integer; inputting the target prompt words into a target model to obtain a first project document, wherein the first project document includes the interface document of the electronic payment function, wherein the model type of the target model includes a large language model.

[0007] Further, based on the second dataset and the preset project specification document, the target prompt word is determined, including: obtaining a preset prompt word template, and adding the second dataset and N constraints to the preset prompt word template to obtain an initial prompt word; adjusting the initial prompt word through a target language model to obtain the target prompt word, wherein the target language model includes a large language model.

[0008] Furthermore, the N constraints include at least one of the following: structural constraints, linguistic constraints, anonymization constraints, and thought chain constraints, wherein the structural constraints are used to constrain the document structure of the document generated by the target model, the linguistic constraints are used to constrain the document content used in the document generated by the target model, the anonymization constraints are used to constrain the target model to anonymize specified sensitive information during the document generation process, and the thought chain constraints are used to constrain the analysis process of the target model.

[0009] Further, data collection is performed on the data associated with the electronic payment function to obtain a first dataset, including: scanning the version control system of the electronic payment function at a preset period to see if there is a target commit record, wherein the target commit record includes: updated code commit records, and the code commit records include: commit records of source code used to implement the electronic payment function; if the target commit record is found in the version control system, data associated with the target commit record is collected to obtain the first dataset.

[0010] Furthermore, after inputting the target prompt word into the target model to obtain the first project document, the method further includes: obtaining historical project documents, wherein the historical project documents include: interface documents of the electronic payment function generated during historical time periods; comparing the first project document and the historical project documents to obtain a comparison result; and marking the first project document based on the comparison result to obtain the target project document.

[0011] Further, based on the comparison result, the first project document is marked to obtain a target project document, including: based on the comparison result, determining that the first project document has changed content compared with the historical project document, and obtaining the target changed content; marking the target changed content in the first project document to obtain a second project document; adding anchor points to the second project document based on the target submission record to obtain the target project document.

[0012] Further, data extraction and format conversion are performed on the first dataset to obtain a second dataset, including: extracting source code data from the first dataset to obtain a first extraction result, wherein the first extraction result includes at least one of the following: input and output parameters of the interface associated with the electronic payment function, code call chain in the source code data, exception handling logic of the source code data, and version information of the source code data; extracting configuration files from the first dataset to obtain a second extraction result, wherein the second extraction result includes: Uniform Resource Locator (URL); and converting the data format of the data in the first extraction result and the second extraction result to obtain the second dataset.

[0013] To achieve the above objectives, according to another aspect of this application, a document data determination apparatus is provided. The apparatus includes: a collection unit for collecting data associated with an electronic payment function to obtain a first dataset, wherein the first dataset includes source code data and configuration files for implementing the electronic payment function; a first processing unit for extracting data and converting the format of the first dataset to obtain a second dataset; a determination unit for determining target prompt words based on the second dataset and a preset project specification file, wherein the preset project specification file includes N constraints, where N is a positive integer; and a second processing unit for inputting the target prompt words into a target model to obtain a first project document, wherein the first project document includes the interface document of the electronic payment function, wherein the model type of the target model includes a large language model.

[0014] Further, the determining unit includes: a processing subunit, used to obtain a preset prompt word template and add the second dataset and N constraints to the preset prompt word template to obtain an initial prompt word; and an adjusting subunit, used to adjust the initial prompt word through a target language model to obtain the target prompt word, wherein the target language model includes a large language model.

[0015] Furthermore, the N constraints include at least one of the following: structural constraints, linguistic constraints, anonymization constraints, and thought chain constraints, wherein the structural constraints are used to constrain the document structure of the document generated by the target model, the linguistic constraints are used to constrain the document content used in the document generated by the target model, the anonymization constraints are used to constrain the target model to anonymize specified sensitive information during the document generation process, and the thought chain constraints are used to constrain the analysis process of the target model.

[0016] Furthermore, the acquisition unit includes: a scanning subunit, used to scan the version control system of the electronic payment function at a preset period to see if there is a target commit record, wherein the target commit record includes: an updated code commit record, and the code commit record includes: a commit record of source code used to implement the electronic payment function; and an acquisition subunit, used to acquire data associated with the target commit record when the target commit record is detected in the version control system, to obtain the first dataset.

[0017] Furthermore, the document data determination device further includes: an acquisition unit, configured to acquire historical project documents after inputting the target prompt words into the target model to obtain a first project document, wherein the historical project documents include: interface documents of the electronic payment function generated during a historical time period; a comparison unit, configured to compare the first project document and the historical project documents to obtain a comparison result; and a marking unit, configured to mark the first project document based on the comparison result to obtain a target project document.

[0018] Further, the marking unit includes: a determining subunit, used to determine, based on the comparison result, the content that has changed between the first project document and the historical project document, to obtain the target changed content; a marking subunit, used to mark the target changed content in the first project document, to obtain the second project document; and an adding subunit, used to add anchor points to the second project document based on the target submission record, to obtain the target project document.

[0019] Further, the first processing unit includes: a first extraction subunit, used to extract source code data from the first dataset to obtain a first extraction result, wherein the first extraction result includes at least one of the following: input and output parameters of the interface associated with the electronic payment function, code call chain in the source code data, exception handling logic of the source code data, and version information of the source code data; a second extraction subunit, used to extract configuration files from the first dataset to obtain a second extraction result, wherein the second extraction result includes: a Uniform Resource Locator (URL); and a conversion subunit, used to convert the data format of the data in the first extraction result and the second extraction result to obtain the second dataset.

[0020] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is executed, it controls the device where the computer-readable storage medium is located to perform the method for determining document data.

[0021] According to another aspect of this application, an electronic device is provided, comprising: a memory storing an executable program; and a processor for running the program, wherein the program executes the method for determining document data during runtime.

[0022] According to another aspect of this application, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the document data determination method.

[0023] In this application, the following method is adopted: data collection is performed on the data associated with the electronic payment function to obtain a first dataset, wherein the first dataset includes: source code data and configuration files for implementing the electronic payment function; data extraction and format conversion are performed on the first dataset to obtain a second dataset; based on the second dataset and a preset project specification file, target prompt words are determined, wherein the preset project specification file includes: N constraints, where N is a positive integer; the target prompt words are input into a target model to obtain a first project document, wherein the first project document includes: the interface document of the electronic payment function, wherein the model type of the target model includes: a large language model. This solves the technical problem of high data omission in the interface document of the quick payment function due to manual maintenance in related technologies. In this application, the project document of the electronic payment function is generated by combining a large language model with the project specification file, avoiding the situation in related technologies where manual updating of the interface document is delayed and results in a high degree of data omission in the interface document, thereby achieving the technical effect of improving the data comprehensiveness in the interface document. Attached Figure Description

[0024] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0025] Figure 1 A hardware block diagram of a computer terminal for implementing a method for determining document data is shown.

[0026] Figure 2 This is a flowchart of a method for determining document data according to an embodiment of this application;

[0027] Figure 3 This is a flowchart illustrating the determination of document data based on embodiments of this application;

[0028] Figure 4 This is a schematic diagram of a document data determination device according to an embodiment of this application;

[0029] Figure 5 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] It should be noted that the method and apparatus for determining document data in this application can be used in the field of fintech for maintaining interface documents for electronic payment functions, and can also be used in any field other than fintech for maintaining interface documents for electronic payment functions. This application does not limit the application field of the method and apparatus for determining document data.

[0033] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0034] Deep learning refers to a learning method that utilizes multi-layered neural network structures and trains parameters based on a large amount of sample data to enable the model to extract features and infer associations. The large language model in this application is built based on deep learning.

[0035] Large language models refer to deep learning models that acquire natural language understanding and generation capabilities through training on massive corpora. Their powerful semantic understanding capabilities enable them to be used for tasks such as document parsing, code semantic abstraction, knowledge summarization, and document generation.

[0036] Quick payment: refers to a simplified and convenient online payment method launched by banks in cooperation with third-party payment institutions. By initially signing up and binding a bank card, subsequent payments can be made without being redirected to the bank's page or repeatedly entering bank card information, greatly improving payment efficiency and user experience.

[0037] Document data assets: refer to a collection of data that is stored and preserved in a structured or semi-structured manner, including system interface descriptions, code logic, version change records, business processes, parameter specifications, etc., and can be reused for a long time, auditable, and automatically updated.

[0038] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, analysis, interface data, and document data, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant laws and standards, have taken necessary security measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse. For example, this system has interfaces with relevant users or organizations, providing users with corresponding operation entry points for users to choose to agree to or refuse automated decision results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0039] Example 1

[0040] According to an embodiment of this application, a method embodiment for determining document data is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0041] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a method for determining document data is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0042] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0043] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the document data determination method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned document data determination method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0044] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0045] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0046] Under the aforementioned operating environment, this application provides the following: Figure 2 The method for determining document data is shown. Figure 2 This is a flowchart of a method for determining document data according to Embodiment 1 of this application.

[0047] Step S201: Collect data related to the electronic payment function to obtain the first dataset, wherein the first dataset includes: source code data and configuration files used to implement the electronic payment function.

[0048] The aforementioned electronic payment function may include: quick payment. The aforementioned source code data may refer to the program code files implementing the electronic payment function, including interface definitions, business logic, exception handling, etc. The aforementioned configuration file may include key parameters such as timeout, number of retries, and third-party interface URLs (Uniform Resource Locators). The aforementioned first dataset may also include: electronic payment function associated log files. Analyzing the log files can extract high-frequency error codes, abnormal scenarios, and debugging keywords.

[0049] In this embodiment, code modules directly related to electronic payment functions within the financial institution's internal R&D system can be located. Their source code files and associated configuration files are read through an access mechanism with authentication, ensuring that the collected content fully covers all technical aspects of the business implementation. It should be noted that the above data collection process strictly adheres to corporate security standards and is conducted in an isolated environment to prevent the leakage of sensitive information.

[0050] Step S202: Extract data and convert the format of the first dataset to obtain the second dataset.

[0051] In this embodiment, the application source code in the first dataset can be parsed to extract interface input and output parameters, method logic call chains, parameter configurations, and exception handling processes. Combined with existing interface documentation and message specifications, the format and field descriptions are standardized. System configuration, log keywords, version difference information, and other elements can also be extracted. Furthermore, key parameters such as timeout duration, retries, and third-party interface URLs can be extracted from system configuration files. The system connects to the production and maintenance platform within financial institutions, analyzes log files, and extracts high-frequency error codes, abnormal scenarios, and debugging keywords. This further ensures the integrity of the interface elements.

[0052] By extracting and converting data from the first dataset, the problems of inconsistent code style and high difficulty in maintaining project documentation in related technologies are avoided.

[0053] Step S203: Based on the second dataset and the preset project specification file, determine the target prompt words. The preset project specification file includes N constraints, where N is a positive integer.

[0054] The aforementioned project specification file may include multiple constraints, which can be used to constrain the output expression of the large language model. In this embodiment, the target prompt words can be generated by fusing the preset project specification file with the second dataset.

[0055] Step S204: Input the target prompt words into the target model to obtain the first project document, wherein the first project document includes the interface document for the electronic payment function, and the model type of the target model includes: a large language model.

[0056] The aforementioned first project document may include, but is not limited to: the code logic of the electronic payment function, the relevant documents, the function description, the code version change record, the flowchart, the error code, the upstream and downstream call paths, and other information.

[0057] In this embodiment, target prompt words can be input into the large language model to guide the large language model to analyze according to a preset thought chain (e.g., first analyze the interface - then associate the code - then extract the logic - finally generate the project document) to obtain the first project document.

[0058] By automatically generating project documentation using the target model, the problems of high maintenance costs, significant differences in coding styles among different developers, high reading difficulty, inconsistent field descriptions, missing process descriptions, and incomplete error codes found in related technologies are avoided.

[0059] In an alternative example, the target model may also include: a machine learning model, including: a purely supervised fine-tuning model, or an end-to-end generative model based on large-scale samples.

[0060] Through the above steps, in this embodiment, a project document for the electronic payment function is generated by combining a large language model with the project specification document. This avoids the problem of manual updates to interface documents in related technologies, which can lead to delays and high data omissions in the interface documents. This effectively improves the comprehensiveness of the data in the interface documents. Furthermore, it solves the technical problem of high data loss in the interface documents of the quick payment function, which are manually maintained in related technologies.

[0061] Optionally, in the document data determination method provided in this application embodiment, the target prompt word is determined based on the second dataset and the preset project specification document, including: obtaining a preset prompt word template, and adding the second dataset and N constraints to the preset prompt word template to obtain the initial prompt word; adjusting the initial prompt word through a target language model to obtain the target prompt word, wherein the target language model includes: a large language model.

[0062] The aforementioned preset prompt template can incorporate a thought chain reasoning framework and standard chapter structure. In this embodiment, the preset prompt template is loaded first, and then the data from the second dataset (e.g., structured content such as interface semantics, parameter rules, and dependency relationships) is precisely filled in according to the placeholders in the preset prompt template. Simultaneously, N constraints are embedded into the prompts in the form of instructions, such as adding "must cover all exception capture branches, marking business and system exceptions" in the "output error code" step. This generates initial prompts, achieving a preliminary fusion of semantics and rules. Then, the initial prompts can be input into the target language model. The target language model optimizes the language expression semantically without changing the N constraints, for example, by adjusting word order to improve logical coherence, simplifying redundant expressions, enhancing terminology consistency, and automatically completing implicit logical connections. Through multiple iterations, the target language model ensures that the prompts strictly adhere to the preset project specification document while possessing the executability and reasoning guidance of natural language, ultimately outputting target prompts that are highly adaptable to financial scenarios and can stably generate high-quality documents.

[0063] For example, a large language model can be used, based on the results collected from multiple data sources (i.e., the second dataset): code context, existing interface documents, system configuration, log printing, source code version commit records, etc., and combined with project specification documents, to use the large language model for multi-stage reasoning, continuously modifying prompt words, and repeatedly modifying the expression of business project documents until it meets expectations.

[0064] In the prompt word writing part, a thought chain strategy can be introduced to guide the model not to directly output the final answer, but to imitate the process of human step-by-step reasoning, which can significantly improve the performance of large language models on tasks that require multi-step reasoning.

[0065] Here are some examples of model prompts:

[0066] "You are a professional system architect and patent writing assistant for a financial institution. Based on the provided source code, the history of the quick payment version control system, and related configuration information, please follow the following strict thought process steps to generate a comprehensive, structured technical document that can be used for document asset accumulation for the relevant interface modules of the financial institution's electronic payment business (quick payment, signing, direct debit, etc.)."

[0067] Mind Chain Execution Steps:

[0068] Step 1: Identify the target interface and core entities:

[0069] Action: Scan the provided codebase to locate all APIs (Application Programming Interfaces) that fall under the "Quick Business" category.

[0070] Output: List the interface name, HTTP (Hypertext Transfer Protocol) method, full path, and associated service / module. Clearly identify the core business entities analyzed in the project documentation.

[0071] Step 2: Parse the input data source:

[0072] Action: For each core interface selected in Step 1, analyze its input parameters (Request Body, Query, Path, Header). Request can refer to the body data sent with the request header in the HTTP request. Query can refer to key-value pairs appended to the URL path, used to pass non-sensitive, optional, or pagination-related information for caching and debugging. Path can refer to a dynamic variable in the fixed path portion of the URL, used to uniquely identify the resource location. Header: can refer to HTTP request header fields.

[0073] Output: List each field in tabular form. This includes, but is not limited to, the field's meaning, business meaning, source, validation rules (not empty, format, range), and sensitive information markers (indicating whether it is sensitive data of a certain level).

[0074] Step 3: Trace the code logic and deconstruct its functions:

[0075] Action: Delve into the code corresponding to the interface and draw the method call chain.

[0076] Output: The output should be a flowchart in a specified format, including basic method call relationships and logic chains.

[0077] It is also necessary to mark key processing nodes and identify core business processes. Design patterns and algorithms should also be included, indicating the patterns used (e.g., factory pattern for routing, strategy pattern for risk control) or key algorithms (e.g., encryption algorithm, token generation algorithm).

[0078] Step 4: Inferring the Output Structure and Anomaly Overview:

[0079] Actions: Analyze the returned objects, exception handling (try-catch), and error throwing in the code.

[0080] Output: Successful response structure: describes the structure of the data field. A complete set of exception scenarios, including but not limited to: Business exceptions: such as token expiration, insufficient balance, exceeding limits, protocol non-existent. System exceptions: such as database connection timeout, downstream service (clearing, risk control, account manipulation) unavailable, network timeout.

[0081] Step 5: Synthesize versionable asset documentation:

[0082] Action: Integrate the output of all preceding steps and generate a document according to a standardized template.

[0083] The following required sections of the document must be included:

[0084] (1) Document metadata: document ID, version number, corresponding code commit version record, and generation date.

[0085] (2) Functional Overview: Briefly describe the business purpose of this interface / module. Input and output parameter specifications.

[0086] (3) Detailed explanation of code logic: Based on step 3, the core process is described using natural language and flowcharts.

[0087] (4) List of files involved: List the core code files, configuration files, and SQL file paths.

[0088] (5) Version change record of the quick payment version control system: digital fingerprint, author, time and brief description of the code changes associated with the n most recent important commits of this module.

[0089] (6) Flowchart: Draw a sequence diagram or flowchart, including core components and external dependencies.

[0090] (7) Error Code Reference Table: Systematically lists all possible error codes, error messages, triggering reasons and handling suggestions.

[0091] (8) Upstream and downstream dependency graph: Upstream callers include which internal services or external channels call this interface. Downstream dependencies include which internal services (risk control, account, billing) and external systems (SMS gateway) this interface depends on.

[0092] (9) Configuration item description: related timeout time, limit, switch and other configuration parameters and their meanings.

[0093] (10) Performance and security considerations: Analyze potential bottlenecks and security measures (encryption, desensitization, and prevention of replay attacks).

[0094] Now, please begin your work. Proceed through steps 1 through 5 to ultimately generate document assets that can be retained.

[0095] Optionally, in the document data determination method provided in the embodiments of this application, the N constraints include at least one of the following: structural constraints, language constraints, desensitization constraints, and thought chain constraints. The structural constraints are used to constrain the document structure of the document generated by the target model, the language constraints are used to constrain the document content used in the document generated by the target model, the desensitization constraints are used to constrain the target model to desensitize specified sensitive information during the document generation process, and the thought chain constraints are used to constrain the analysis process of the target model.

[0096] For example, the N constraints in the pre-defined project specification file may include: generation structure specification (corresponding to structural constraints), language specification specification (corresponding to language constraints), desensitization compliance specification (corresponding to desensitization constraints), and reasoning link specification (corresponding to thought chain constraints).

[0097] The generated structure specification may include: the document must include interface description, field definition, error scenarios, business process, etc.; the language specification may include: adopt the tone of formal technical documentation and avoid colloquial expressions; the anonymization compliance specification may include: not outputting sensitive content such as real accounts and keys; the inference chain specification may include: generating through a thinking chain strategy of "first analyze the interface - then associate the code - then extract the logic - finally generate the document".

[0098] By using N constraints, the output expression of a large language model can be standardized in complex scenarios, so as to generate "controllable, reliable, and auditable" project documents that meet the engineering documentation requirements of financial institutions.

[0099] Optionally, in the document data determination method provided in this application embodiment, data collection is performed on the data associated with the electronic payment function to obtain a first dataset, including: scanning the version control system of the electronic payment function for whether there is a target commit record according to a preset period, wherein the target commit record includes: updated code commit record, and the code commit record includes: commit record of source code used to implement the electronic payment function; if the target commit record is found in the version control system, data associated with the target commit record is collected to obtain the first dataset.

[0100] The aforementioned preset cycle can refer to a pre-configured timed scanning frequency (such as every 15 minutes, or every morning), used to automatically trigger the project document update process, ensuring that documents and code changes are synchronized and avoiding delays caused by manual intervention. A version control system can refer to a system used to manage the historical changes of source code. It can be a distributed control system; in this embodiment, it can refer to a quick payment version control system, used to store all code commit records, branches, tags, and change differences. The target commit record can refer to the changed code commit records related to the "electronic payment function" in the version control system, including the addition, modification, or deletion of source code files implementing payment logic (such as signing, deduction, and reconciliation). Source code can refer to the programming code files that implement the quick payment function.

[0101] In this embodiment, the version control system can be actively polled at preset intervals, and target submission records can be filtered by keywords (such as "quick payment") or paths. For each submission record, the functional module to which it belongs can be automatically identified based on the path of the changed file. If it belongs to the core module of electronic payment, data collection can be triggered: the latest source code of the changed file is pulled, and combined with the context of the submission, the interface changes, parameter additions and deletions, verification logic adjustments, exception handling modifications, etc. are extracted. The configuration changes, log additions, SQL modifications, and other data associated with this submission record are integrated to form a "first dataset" to achieve an automated closed loop of "code moves, documentation moves accordingly", completely eliminating the risk of "code is online, documentation is not updated".

[0102] It's important to note that the first output project document can include the target commit records related to this business. When the code or project document is updated, the relevant changes can be automatically located, and a comparison report can be generated again. Each time a project document is generated, the latest code commit records in the electronic payment version control system of the current code repository can be recorded as the anchor point for this project document version. A list of file changes for that commit is also saved. When there are new commits in the code repository, the electronic payment version control system is scanned at set intervals through periodic polling, triggering project document updates. The "added fields / deleted fields / logic changes" sections can also be highlighted, enabling automatic scrolling of project document versions and forming a knowledge asset repository. New personnel can quickly understand the system logic without relying on the transfer of historical experience, effectively solving the knowledge gap caused by personnel changes.

[0103] Optionally, in the document data determination method provided in the embodiments of this application, after inputting the target prompt words into the target model to obtain the first project document, the method further includes: obtaining historical project documents, wherein the historical project documents include: interface documents of electronic payment functions generated in historical time periods; comparing the first project document and the historical project documents to obtain a comparison result; and marking the first project document based on the comparison result to obtain the target project document.

[0104] For example, historical project documents refer to the interface technical documents for electronic payment functions that were automatically generated and archived before the current point in time. Each document is bound to a unique commit record and version number, forming a traceable knowledge asset repository. The first project document mentioned above refers to the interface document newly generated by the large language model based on the latest code changes (target commit record) and target prompt words, representing the latest version in the current code state. The comparison results above can be used through structured comparison algorithms to quantify and qualitatively analyze the differences between the first project document and historical project documents in dimensions such as fields, processes, error codes, dependencies, and configurations, including changes such as additions, deletions, and modifications.

[0105] The target project document mentioned above can refer to the first project document after the difference mark, whose content is fully updated, and the change points are marked in a visual format (such as green highlighting of additions, red deletions, and yellow modification) to facilitate review and auditing.

[0106] In this embodiment, after generating the first project document, the previous version of the historical project document associated with the electronic payment function can be retrieved from the document asset library. Then, a structured comparison engine can be used to compare the contents of the two documents item by item, such as the "interface field table," "error code list," "flowchart nodes," and "configuration items," to identify differences. For example, if the first project document adds a field that is not present in the historical project document, it is marked as "added," and the change identifier is embedded in the first project document using color labels, annotations, and revision modes to form the target project document.

[0107] In this embodiment, the first project document is marked according to the differences between the historical project document and the first project document, so that the final target project document not only includes complete interface information, but also more intuitively presents "which parts have changed", reducing the understanding cost for operation and maintenance, testing and new members, and realizing sustainable document asset management that is "change-aware and knowledge-evolvable".

[0108] Optionally, in the document data determination method provided in the embodiments of this application, marking the first project document based on the comparison result to obtain the target project document includes: determining, based on the comparison result, the content that has changed between the first project document and the historical project document, and obtaining the target changed content; marking the target changed content in the first project document to obtain the second project document; and adding anchor points to the second project document based on the target submission record to obtain the target project document.

[0109] The target changes refer to the specific changes identified in the first project document compared to the historical project document, such as adding fields, deleting parameters, modifying error code descriptions, adjusting process nodes, or updating configuration items. The second project document refers to the intermediate document based on the first project document, after applying visual or structured markup (such as highlighting, strikethrough, comments, and revision mode) to the target changes, in order to improve readability and auditability.

[0110] Anchors can serve as precise mappings between project documentation content and source code versions, ensuring that documentation is traceable, rollbackable, and associated with specific change contexts.

[0111] In this embodiment, all target changes can be extracted based on the comparison results to form a structured change list. Markers are automatically inserted at the corresponding positions in the first project document. For example, newly added content is marked with a green background, deleted content is marked with a strikethrough and retains its original value, and modified content is displayed side by side in the form of "original → new". Changes to flowchart nodes are highlighted with borders simultaneously, resulting in the second project document.

[0112] Then, the source code version information from the target commit record can be written into the "Document Metadata" field of the second project document, and associated with metadata such as change list, generation time, and author to form the final "Target Project Document".

[0113] The target project documentation not only carries updated interface information, but also achieves "visible changes, traceable versions, and traceable responsibilities" through a dual mechanism of "tags + anchors". It allows for quick understanding of "what was changed, why it was changed, and based on which commit", solving the problem in related technologies where project documentation lacks traceable change records and cannot locate the history of interface field changes, and building an evolving and auditable interface documentation asset system.

[0114] Optionally, in the document data determination method provided in this application embodiment, data extraction and format conversion are performed on the first dataset to obtain the second dataset, including: extracting source code data from the first dataset to obtain a first extraction result, wherein the first extraction result includes at least one of the following: input and output parameters of the interface associated with the electronic payment function, code call chain in the source code data, exception handling logic of the source code data, and version information of the source code data; extracting configuration files from the first dataset to obtain a second extraction result, wherein the second extraction result includes: Uniform Resource Locator; and converting the data format of the data in the first extraction result and the second extraction result to obtain the second dataset.

[0115] In this embodiment, the input and output parameters of the interface can be extracted from the source code data, including key semantic information such as parameter name, data type, whether it is required, value range, and verification rules; the function call relationship in the source code data is analyzed simultaneously to reconstruct the code call chain in the quick payment business process, clarifying the complete flow path of the interface from the entry point to the core logic and then to external dependencies; the exception handling mechanism is identified, and exception types, triggering conditions, error codes, and coping strategies are extracted to construct a system fault tolerance knowledge graph; at the same time, the version information of code changes is bound, such as submission number, time, and submitter, to ensure that each extracted content is traceable and retrospective, thereby obtaining the first extraction result.

[0116] In this embodiment, the configuration files in the first dataset are extracted to extract the key external addresses required for the operation of the electronic payment function, such as Uniform Resource Locators (URLs), access paths for payment gateways, risk control services, SMS platforms, etc., to obtain the second extraction result, ensuring that the system dependencies are clear and complete.

[0117] Afterwards, the first and second extraction results can be converted into a unified format to obtain the second dataset, forming a "knowledge package" that can be accurately understood by large models.

[0118] An optional step for data extraction and format conversion of the first dataset is as follows:

[0119] 1.1 Source Code Integration and Extraction: Integrate with the quick payment version control system, adding context, including code files, root folder, commit history, and commit changes. Filter the source code data extraction interface definition. Extract the field names, types, and validation rules (such as NOT NULL checks and regular expression matching) of the interface's input and output parameters.

[0120] 1.2 Extraction of method logic calls: Analyze the method logic call chain to identify core business processes (such as payment → risk control → third-party channel call → result processing).

[0121] 1.3 Abnormal Data Extraction: Extract the abnormal handling logic, including the abnormal type, triggering conditions and handling methods (such as retry, logging, and returning error codes).

[0122] Version 1.4 Information Extraction: For each commit record, generate a list of code changes and save the commit log information (committer, time, title, and remarks) as anchor points for subsequent document asset iteration updates.

[0123] 1.5 Integration of Existing Documentation and Message Specifications: This involves connecting to the metadata and resource management platform within financial institutions, parsing existing interface documentation and message specifications for the quick payment application, and extracting field descriptions, business rules, and sample data. The extracted source code results are compared with the document content to standardize terminology and formatting.

[0124] 1.6 Supplementary Data Extraction: Connect with the financial institution's internal variable configuration center to extract key parameters such as timeout duration, retry count, and third-party interface URLs from system configuration files. Connect with the financial institution's internal production operations platform to analyze log files and extract frequently occurring error codes, abnormal scenarios, and debugging keywords.

[0125] In this embodiment, the extraction from raw code to structured data not only improves the completeness and accuracy of information extraction, but also ensures the standardization of the input content of the large language model, laying a solid data foundation for the subsequent generation of consistent, reliable, and auditable project documents, and improving the maintenance efficiency of project documents.

[0126] Figure 3 This is a flowchart of the determination based on the document data provided in the embodiments of this application, such as... Figure 3 As shown, this includes: multi-source data collection and organization, generation of project specification documents, automatic generation of project documents based on a large model, and continuous iteration and document asset accumulation. By collecting multi-source data, parsing code information, constructing project specifications, and combining them with a thought chain reasoning strategy, the system achieves automatic generation, continuous completion, and long-term accumulation of interface documents, reducing maintenance costs and improving R&D efficiency and knowledge transferability.

[0127] In this embodiment, by combining a large language model with a thought chain, intelligent and standardized project document generation is achieved, thereby improving the efficiency of project document generation and reducing maintenance costs. The combination of project specifications and the thought chain ensures that the project documents output by the large language model are consistent, standardized, and traceable. The large language model facilitates the structured accumulation of code knowledge, preventing gaps in system understanding due to personnel turnover; it also addresses the issues of missing, outdated, and unusable code project documents caused by long system time spans and large project scales. The document data determination method provided in this embodiment is applicable to high-frequency business change scenarios in quick payment, automatically synchronizing document updates based on code commit records. This forms a long-term knowledge asset library for financial institutions, providing scalability for new business development.

[0128] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0129] Example 2

[0130] This application also provides a document data determination apparatus. It should be noted that the document data determination apparatus of this application can be used to execute the document data determination method provided in this application. The document data determination apparatus provided in this application will be described below.

[0131] According to embodiments of this application, an apparatus for implementing the above-described method for determining document data is also provided, such as... Figure 4 As shown, the device includes: a data acquisition unit 41, a first processing unit 42, a determination unit 43, and a second processing unit 44.

[0132] The acquisition unit 41 is used to acquire data related to the electronic payment function to obtain a first dataset, which includes source code data and configuration files used to implement the electronic payment function.

[0133] The first processing unit 42 is used to extract data and convert the format of the first dataset to obtain the second dataset;

[0134] The determination unit 43 is used to determine target prompt words based on the second dataset and the preset project specification file, wherein the preset project specification file includes: N constraints, where N is a positive integer;

[0135] The second processing unit 44 is used to input the target prompt words into the target model to obtain the first project document, wherein the first project document includes the interface document of the electronic payment function, and the model type of the target model includes the large language model.

[0136] In the document data determination device provided in this application embodiment, the acquisition unit 41 can acquire data associated with the electronic payment function to obtain a first dataset, wherein the first dataset includes source code data and configuration files for implementing the electronic payment function. The first processing unit 42 extracts data and converts the format of the first dataset to obtain a second dataset. The determination unit 43 determines target prompt words based on the second dataset and a preset project specification file, wherein the preset project specification file includes N constraints, where N is a positive integer. The second processing unit 44 inputs the target prompt words into the target model to obtain a first project document, wherein the first project document includes the interface document of the electronic payment function, and the model type of the target model includes a large language model. This solves the technical problem of high data omission in the interface document of the quick payment function due to manual maintenance in related technologies. In this embodiment, the project document of the electronic payment function is generated by combining the large language model with the project specification file, avoiding the lag in manual updating of the interface document in related technologies, which leads to a high degree of data omission in the interface document, thereby achieving the technical effect of improving the data comprehensiveness in the interface document.

[0137] Optionally, in the document data determination device provided in the embodiments of this application, the determination unit includes: a processing subunit, used to obtain a preset prompt word template and add a second dataset and N constraints to the preset prompt word template to obtain an initial prompt word; and an adjustment subunit, used to adjust the initial prompt word through a target language model to obtain a target prompt word, wherein the target language model includes: a large language model.

[0138] Optionally, in the document data determination device provided in the embodiments of this application, the N constraints include at least one of the following: structural constraints, language constraints, desensitization constraints, and thought chain constraints, wherein the structural constraints are used to constrain the document structure of the document generated by the target model, the language constraints are used to constrain the document content used in the document generated by the target model, the desensitization constraints are used to constrain the target model to desensitize specified sensitive information during the document generation process, and the thought chain constraints are used to constrain the analysis process of the target model.

[0139] Optionally, in the document data determination device provided in the embodiments of this application, the collection unit includes: a scanning subunit, used to scan the version control system for electronic payment function to see if there is a target commit record, wherein the target commit record includes: an updated code commit record, and the code commit record includes: a commit record of source code used to implement the electronic payment function; and a collection subunit, used to collect data associated with the target commit record when the version control system is found to exist, to obtain a first dataset.

[0140] Optionally, in the document data determination device provided in the embodiments of this application, the document data determination device further includes: an acquisition unit, used to acquire historical project documents after inputting target prompt words into the target model to obtain a first project document, wherein the historical project documents include: interface documents of electronic payment functions generated in historical time periods; a comparison unit, used to compare the first project document and the historical project documents to obtain a comparison result; and a marking unit, used to mark the first project document based on the comparison result to obtain a target project document.

[0141] Optionally, in the document data determination device provided in the embodiments of this application, the marking unit includes: a determination subunit, used to determine, based on the comparison result, the content of the first project document that has changed compared with the historical project document, to obtain the target changed content; a marking subunit, used to mark the target changed content in the first project document, to obtain the second project document; and an adding subunit, used to add anchor points to the second project document based on the target submission record, to obtain the target project document.

[0142] Optionally, in the document data determination device provided in the embodiments of this application, the first processing unit includes: a first extraction subunit, used to extract source code data from the first dataset to obtain a first extraction result, wherein the first extraction result includes at least one of the following: input and output parameters of the interface associated with the electronic payment function, code call chain in the source code data, exception handling logic of the source code data, and version information of the source code data; a second extraction subunit, used to extract data from the configuration files in the first dataset to obtain a second extraction result, wherein the second extraction result includes: a Uniform Resource Locator; and a conversion subunit, used to convert the data format of the data in the first extraction result and the second extraction result to obtain a second dataset.

[0143] It should be noted that the acquisition unit 41, the first processing unit 42, the determination unit 43, and the second processing unit 44 mentioned above correspond to steps S201 to S204 in Embodiment 1. Each unit and the corresponding step implement the same instance and application scenario, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of the device and run in the computer terminal 10 provided in Embodiment 1.

[0144] Example 3

[0145] Embodiments of this application may provide an electronic device. Figure 5This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 5 As shown, the electronic device may include: one or more ( Figure 5 (Only one is shown) processor 502, memory 504, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0146] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0147] The processor can access information and applications stored in the memory via a transmission device to perform the following steps: Data acquisition of data associated with the electronic payment function to obtain a first dataset, wherein the first dataset includes source code data and configuration files for implementing the electronic payment function; data extraction and format conversion of the first dataset to obtain a second dataset; determination of target prompt words based on the second dataset and a preset project specification file, wherein the preset project specification file includes N constraints, where N is a positive integer; inputting the target prompt words into the target model to obtain a first project document, wherein the first project document includes an interface document for the electronic payment function, wherein the model type of the target model includes a large language model.

[0148] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: Based on the second dataset and the preset project specification file, determine the target prompt word, including: obtaining the preset prompt word template and adding the second dataset and N constraints to the preset prompt word template to obtain the initial prompt word; adjusting the initial prompt word through the target language model to obtain the target prompt word, wherein the target language model includes: a large language model.

[0149] The processor can also call the information and application programs stored in the memory through the transmission device to perform the following steps: N constraints include at least one of the following: structural constraints, language constraints, desensitization constraints, and thought chain constraints, wherein the structural constraints are used to constrain the document structure of the document generated by the target model, the language constraints are used to constrain the document content used in the document generated by the target model, the desensitization constraints are used to constrain the target model to desensitize specified sensitive information during the document generation process, and the thought chain constraints are used to constrain the analysis process of the target model.

[0150] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: collect data associated with the electronic payment function to obtain a first dataset, including: scanning the version control system of the electronic payment function at a preset period to see if there is a target commit record, wherein the target commit record includes: updated code commit record, and the code commit record includes: commit record of the source code used to implement the electronic payment function; if the target commit record is found in the version control system, collect the data associated with the target commit record to obtain the first dataset.

[0151] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: after inputting the target prompt words into the target model to obtain the first project document, it further includes: obtaining historical project documents, wherein the historical project documents include: interface documents of electronic payment functions generated in historical time periods; comparing the first project document and the historical project documents to obtain a comparison result; and marking the first project document based on the comparison result to obtain the target project document.

[0152] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: marking the first project document based on the comparison result to obtain the target project document, including: determining the content that has changed between the first project document and the historical project document based on the comparison result, and obtaining the target changed content; marking the target changed content in the first project document to obtain the second project document; adding anchor points to the second project document based on the target submission record to obtain the target project document.

[0153] The processor can also invoke information and applications stored in the memory via a transmission device to perform the following steps: extracting and converting data from the first dataset to obtain a second dataset, including: extracting source code data from the first dataset to obtain a first extraction result, wherein the first extraction result includes at least one of the following: input and output parameters of the interface associated with the electronic payment function, code call chain in the source code data, exception handling logic in the source code data, and version information of the source code data; extracting data from the configuration files in the first dataset to obtain a second extraction result, wherein the second extraction result includes: a Uniform Resource Locator (URL); and converting the data format of the data in the first extraction result and the second extraction result to obtain the second dataset.

[0154] By adopting the embodiments of this application, a project document for electronic payment function is generated by combining a large language model with the project specification document. This avoids the problem of manual updating of interface documents in related technologies, which leads to lag and a high degree of data omission in the interface documents. This achieves the technical effect of improving the comprehensiveness of data in the interface documents.

[0155] Those skilled in the art will understand that Figure 5 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 5 This does not limit the structure of the aforementioned electronic device. For example, the electronic device may also include components that are more... Figure 5 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 5 The different configurations shown.

[0156] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0157] Example 4

[0158] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the method for determining document data provided in Embodiment 1.

[0159] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0160] This application also provides a computer program product that, when executed on a data processing device, is adapted to perform method steps for determining document data.

[0161] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0162] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0163] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0164] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0165] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0166] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0167] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for determining document data, characterized in that, include: Data is collected from the data associated with the electronic payment function to obtain a first dataset, wherein the first dataset includes: source code data and configuration files used to implement the electronic payment function; Data extraction and format conversion are performed on the first dataset to obtain the second dataset; Based on the second dataset and the preset project specification file, target prompt words are determined, wherein the preset project specification file includes: N constraints, where N is a positive integer; The target prompt words are input into the target model to obtain a first project document, wherein the first project document includes the interface document of the electronic payment function, and the model type of the target model includes: a large language model.

2. The determination method according to claim 1, characterized in that, Based on the second dataset and the preset project specification file, target prompt words are determined, including: Obtain a preset prompt word template, and add the second dataset and N constraints to the preset prompt word template to obtain the initial prompt words; The initial prompt word is adjusted using a target language model to obtain the target prompt word, wherein the target language model includes a large language model.

3. The determination method according to claim 1, characterized in that, The N constraints include at least one of the following: structural constraints, linguistic constraints, anonymization constraints, and thought chain constraints, wherein the structural constraints are used to constrain the document structure of the document generated by the target model, the linguistic constraints are used to constrain the document content used in the document generated by the target model, the anonymization constraints are used to constrain the target model to anonymize specified sensitive information during the document generation process, and the thought chain constraints are used to constrain the analysis process of the target model.

4. The determination method according to claim 1, characterized in that, Data was collected from the data associated with the electronic payment function to obtain the first dataset, which includes: The version control system of the electronic payment function is scanned periodically to check whether there are target commit records. The target commit records include updated code commit records, which include commit records of source code used to implement the electronic payment function. If the target commit record is found in the version control system, the data associated with the target commit record is collected to obtain the first dataset.

5. The determination method according to claim 4, characterized in that, After inputting the target prompt words into the target model to obtain the first project document, the process also includes: Obtain historical project documents, wherein the historical project documents include: interface documents for the electronic payment function generated during historical time periods; The first project document and the historical project document are compared to obtain the comparison results. Based on the comparison results, the first project document is marked to obtain the target project document.

6. The determination method according to claim 5, characterized in that, Based on the comparison results, the first project document is marked to obtain the target project document, including: Based on the comparison results, it is determined that the first project document has changed content compared with the historical project document, and the target changed content is obtained; Mark the target changes in the first project document to obtain the second project document; Anchor points are added to the second project document based on the target submission record to obtain the target project document.

7. The determination method according to claim 1, characterized in that, Data extraction and format conversion are performed on the first dataset to obtain the second dataset, which includes: The source code data in the first dataset is extracted to obtain a first extraction result, wherein the first extraction result includes at least one of the following: input and output parameters of the interface associated with the electronic payment function, code call chain in the source code data, exception handling logic of the source code data, and version information of the source code data; Data is extracted from the configuration files in the first dataset to obtain a second extraction result, wherein the second extraction result includes: Uniform Resource Locator; The data formats of the data in the first extraction result and the second extraction result are converted to obtain the second dataset.

8. A device for determining document data, characterized in that, include: The data acquisition unit is used to collect data related to the electronic payment function to obtain a first dataset, wherein the first dataset includes: source code data and configuration files used to implement the electronic payment function; The first processing unit is used to extract data and convert the format of the first dataset to obtain the second dataset; The determining unit is used to determine target prompt words based on the second dataset and the preset project specification file, wherein the preset project specification file includes: N constraints, where N is a positive integer; The second processing unit is used to input the target prompt words into the target model to obtain a first project document, wherein the first project document includes the interface document of the electronic payment function, and wherein the model type of the target model includes a large language model.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the computer-readable storage medium is located to perform the document data determination method according to any one of claims 1 to 7.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the method for determining document data as described in any one of claims 1 to 7.

Images