Skill file full life cycle management method for digital humanities code generation

Abstract

The application provides a skill file full life cycle management method for digital humanities code generation, belonging to the technical field of intelligent code generation. A digital humanities research task and a corresponding candidate corpus set are obtained, and a structured skill file containing task rules, method constraints and code templates is called or newly created according to the task characteristics. Analysis code is generated and executed based on the research task and the skill file, and feedback data containing analysis results and execution logs are obtained. Subsequently, corresponding quantitative verification evaluation data are generated from three dimensions of evidence matching, method adaptation and code execution. A three-gate mechanism is set, and only when the three types of verification data all reach the preset threshold, the skill file is allowed to be updated, otherwise the update is prohibited, realizing the standardized calling, checking and iterative control of the skill file in the digital humanities scene, and solving the problems of lack of humanities evidence constraint, non-standard research method and disordered skill file iteration in the traditional code generation technology.

Description

Technical Field

[0001] This invention belongs to the field of intelligent code generation technology, specifically relating to a method for managing the entire lifecycle of skill files for digital humanities code generation. Background Technology

[0002] Digital humanities research requires the use of computational methods to organize heterogeneous materials from multiple sources, such as historical documents, local chronicles, archives, and letters, into analyzable, interpretable, and traceable knowledge structures. Research conclusions are then generated through analytical scripts, statistical models, and other means. Unlike general code generation tasks, digital humanities analysis code generation not only requires runnable code but also demands that conclusions be supported by evidence, that methods conform to research paradigms, and that effective skills be accumulated through multiple rounds of tasks.

[0003] Existing technologies for generating code for digital humanities analytics typically employ a closed-loop process: "task input—context retrieval—code generation—code execution—code correction based on execution results." Some systems also incorporate memory and reflection mechanisms, storing the results of this round, or in the form of a natural language summary, in a memory cache after successful code execution for subsequent tasks.

[0004] However, existing technologies have at least the following problems in practical applications: Existing systems primarily use successful code execution as the criterion for retaining and reusing experience. When analyzing successful code execution, the system tends to directly retain the generation rules and output results of this round, or add the natural language reflection summary to the skill library. However, in the context of digital humanities research, successful code execution does not necessarily mean credible research conclusions—engineerably executable code may employ research methods unsuitable for the current task (e.g., using topic clustering instead of version difference analysis for version evolution issues), and its output conclusions may lack sufficient historical evidence, or even contain inherent contradictions among the cited evidence. If the system uses successful execution as the only gating condition for skill retention, these low-quality, methodologically mismatched, or insufficiently evidenced generation experiences will be continuously solidified into the skill file, causing subsequent tasks to amplify errors when calling the skill file, resulting in systemic pollution of the skill file.

[0005] Therefore, there is an urgent need for a technical solution that can jointly control the updating of skills documents from multiple dimensions of authenticity, so as to avoid the continuous accumulation and spread of erroneous experience in skills documents due to judgments based on a single engineering dimension. Summary of the Invention

[0006] In view of the above-mentioned defects or deficiencies in the existing technology, a method for full lifecycle management of skills files for digital humanities code generation is provided, which is implemented by the processor executing program instructions stored in memory, including the following steps: Obtain digital humanities research tasks and corresponding candidate corpus sets; Based on the characteristics of the research task, a matching skill file is retrieved from the skill file library, or a new skill file is generated; the skill file is a structured data file that contains task rules, method constraints, and code templates for constraining code generation. Based on the research task and the skill file, generate analysis code and execute the analysis code to obtain feedback data containing analysis results and execution logs; The following data processing procedure is performed by a computer to generate assessment data for controlling the updates of the skill files: Based on the matching results of the analysis with the evidence in the candidate corpus set, evidence matching verification result data is generated; Based on the consistency between the actual analysis method recorded in the execution log and the method constraints in the skill file, method adaptation verification result data is generated; Based on the execution success status and test results recorded in the execution log, generate code execution verification result data; If the evidence matching verification result data, method adaptation verification result data, and code execution verification result data all reach their respective preset threshold values, then updating the skill file based on the feedback data is allowed; otherwise, updating is prohibited.

[0007] According to the technical solution provided in this application, the process of generating evidence matching and verification result data includes the following steps: The analysis results are parsed into structured conclusion objects containing the methods used and source information; From the candidate corpus set, retrieve candidate evidence that matches the structured conclusion object; For each candidate piece of evidence, its support direction is determined based on its consistency with the structured conclusion object in the dimensions of object, time, and space. The support direction includes support or opposition. Based on the weights of all evidence deemed to support a particular direction, generate evidence support data. Based on the source type of the evidence cited by the structured conclusion object, a preset source classification table is queried to generate source credibility data; Based on the proportion of structured conclusion objects that have verifiable traceability structures, conclusion traceability data is generated; Based on the evidence support data, source credibility data, and conclusion traceability data, the evidence matching and verification result data is generated.

[0008] According to the technical solution provided in this application, the generation method adapts to the verification result data, including the following steps: Determine the task category of the research task and the analysis method actually invoked by the analysis code; Query the preset mapping table between task categories and allowed analysis method sets, determine whether the analysis method actually called exists in the allowed analysis method set corresponding to the current task category, and generate task matching data accordingly; Check whether the analysis method actually invoked meets the preset method implementation rules recorded in the skill file, and generate rule compliance data accordingly; Based on the task matching degree data and rule compliance degree data, the method adaptation verification result data is generated.

[0009] According to the technical solution provided in this application, the process of generating code execution verification result data includes the following steps: Based on the code execution status in the execution log, determine whether the execution was successful or failed, and generate execution success data; Based on the preset test rule set in the skill file, verify whether the analysis results meet the expected field output requirements, and use the proportion of rules that pass as the test pass rate data; Check whether the external libraries or interfaces that the analysis code depends on are valid, and generate dependency validity data; Based on the consistency of the output of the analysis code when it is run multiple times under the same conditions, runtime stability data is generated. Based on the execution success rate data, test pass rate data, dependency validity data, and runtime stability data, the code execution verification result data is generated.

[0010] According to the technical solution provided in this application, the generation of evidence support data includes the following steps: Obtain all evidence that is determined to support the direction, and form a set of supporting evidence; The evidence in the supporting evidence set is compared pairwise to determine whether there are contradictory pairs between the evidence; the contradictory pair between the evidence is defined as: the difference between the recorded values ​​of the two pieces of evidence on the same attribute dimension involved in the structured conclusion object exceeds a preset tolerance threshold; the attribute dimension includes time attribute, spatial attribute, quantity attribute, person attribute and event type attribute; If there are contradictory pairs of evidence, a contradiction marker signal is generated. The contradiction marker signal is used to trigger a downgrade or rejection of the evidence support data in subsequent gating decisions.

[0011] According to the technical solution provided in this application, the contradiction marker signal triggers a downgrade or rejection of the evidence support data in subsequent gating decisions, including the following steps: When there are contradictory pairs of evidence, extract the contradictory attribute dimensions and the source types of the evidence from both sides of the contradiction from each contradictory pair to generate a contradictory structure description object; The object describing the contradiction structure is compared with the task category of the current research task to determine whether the contradiction falls within the scope of the contradiction associated with the task category, i.e., the triggering range of the discovery rule. If so, the object describing the contradictory structure will be added to the feedback data as a new discovery in this round of analysis, and the new discovery will be written to the analysis log field of the skill file when updates are allowed. If not, the evidence support data will be reduced according to the preset reduction rules.

[0012] According to the technical solution provided in this application, the step of determining whether a contradiction falls within the scope of the contradiction discovery rule associated with the task category includes the following steps: Read the task category of the current research task; Query the preset task category-conversion attribute mapping table to obtain a list of conversion attribute dimensions corresponding to the current task category; the task category-conversion attribute mapping table is a data structure in which each task category is associated with at least one attribute dimension, indicating that when a conflict occurs in these attribute dimensions, the conflict should be converted into a discovery rather than a deduction item; Read the contradictory attribute dimensions from the contradictory structure description object; If the contradictory attribute dimension exists in the list of transformation attribute dimensions, then the contradiction is determined to fall within the trigger range; otherwise, it is determined not to fall within the range.

[0013] According to the technical solution provided in this application, the task category-conversion attribute mapping table is constructed through the following steps: Retrieve all historical records of successfully updated skill files to form a set of historical successful tasks; each task record includes the task category, records of contradictory evidence during execution, and whether the task ultimately triggered a new discovery. For each task category, the distribution of attribute dimensions of contradictory evidence pairs that have appeared in all historical successful tasks under that category is statistically analyzed. For each attribute dimension, calculate its transformation confidence, which is: under this task category, when the contradiction between evidences involves this attribute dimension, the ratio of the number of tasks in which the contradiction is finally transformed into a new discovery to the number of tasks in which the contradiction is finally deducted points according to the preset downgrade rule; Attribute dimensions whose conversion confidence exceeds the preset conversion threshold are added to the conversion attribute dimension list corresponding to the task category.

[0014] According to the technical solution provided in this application, when any of the evidence matching verification result data, method adaptation verification result data, or code execution verification result data fails to reach its preset threshold, the following steps are performed: Retain the currently used skill file and prohibit writing the feedback data from this round into the skill file; Determine the failure type based on the data type of the verification result that did not meet the requirements; When the failure type is that the method adaptation verification result data does not meet the standard, an alternative analysis method is selected from the method constraints recorded in the skill file, or an alternative skill file that matches the task category of the current task and whose historical method adaptation verification result data meets the standard is retrieved from the skill file library. The analysis code is then regenerated and executed based on the alternative analysis method or the alternative skill file.

[0015] According to the technical solution provided in this application, after determining the failure type based on the data type of the unqualified verification result, the method further includes the following steps: When the failure type is that the evidence matching verification result data does not meet the standard, supplement the evidence in the candidate corpus set, or increase the traceability requirements of the structured conclusion object and regenerate the analysis code and execute it. When the failure type is that the code execution verification result data does not meet the standard, the analysis code is regenerated and executed after repairing the dependency environment or supplementing the test rules based on the dependency validity data or the test pass rate data.

[0016] Compared with the prior art, the beneficial effects of this application are as follows: I. Preventing Erroneous Experiences from Being Written into Skill Files, Improving the Quality of Skill Accumulation. Using skill.md as a unified intermediate skill artifact, after code execution, it not only checks whether the code ran successfully, but also generates evaluation data from three dimensions: evidence matching verification, method adaptation verification, and code execution verification, setting threshold values ​​for each. Only when the evaluation data in all three dimensions reaches the threshold is updating the skill file based on feedback data allowed; otherwise, updating is prohibited. This multi-dimensional joint gating mechanism fundamentally changes the existing single-judgment logic of "code runs and is retained," effectively filtering out results that are successful in engineering but lack academic evidence support, or that have inappropriate method selection, or unstable code quality, significantly reducing the probability of erroneous rules and low-quality feedback being written into skill files.

[0017] Second, to avoid the risk of method mismatch and ensure the academic correctness of the research paradigm. In method adaptation verification, a pre-defined mapping table between task categories and the set of allowed analysis methods is used to explicitly determine whether the currently invoked analysis method is suitable for the current task category (e.g., version change tasks must use text difference comparison or collation note parsing, rather than topic clustering), and to check whether the analysis method meets the pre-defined method implementation rules recorded in skill.md. This mechanism ensures that only analysis code with correct method selection and compliant implementation can have its execution experience solidified into the skill file, preventing inappropriate methods from being reused for a long time.

[0018] Third, enhance the academic traceability and evidentiary reliability of conclusions. In evidence matching and verification, the academic quality of the analysis results is comprehensively evaluated from three sub-dimensions: evidence support, source credibility, and conclusion traceability, rather than simply counting the number of cited references. The system parses the analysis results into structured conclusion objects, verifies whether the conclusions can be traced back to specific historical fragments through evidence mapping and source tracing, and assesses the quality of citations based on the tiered credibility of the source type. This ensures that the conclusions written into the skills document have clear sources of evidence and verifiable traceability paths. Attached Figure Description

[0019] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A flowchart outlining the steps of the skill document lifecycle management method for digital humanities code generation provided in this application. Detailed Implementation

[0020] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0022] Example 1 As mentioned in the background section, this application proposes a method for managing the entire lifecycle of skill files for digital humanities code generation. This method is implemented by the processor executing program instructions stored in memory, such as... Figure 1 As shown, it includes the following steps: S1. Obtain digital humanities research tasks and corresponding candidate corpus sets; S2. Based on the characteristics of the research task, retrieve a matching skill file from the skill file library or generate a new skill file; the skill file is a structured data file that contains task rules, method constraints, and code templates for constraining code generation. S3. Generate analysis code based on the research task and the skill file, and execute the analysis code to obtain feedback data containing analysis results and execution logs; S4. The computer performs the following data processing procedure to generate evaluation data for controlling the updating of the skill file: S41. Based on the analysis results and the matching of evidence in the candidate corpus set, generate evidence matching verification result data; S42. Based on the consistency between the actual analysis method recorded in the execution log and the method constraints in the skill file, generate method adaptation verification result data; S43. Generate code execution verification result data based on the execution success status and test results recorded in the execution log; S44. If the evidence matching verification result data, method adaptation verification result data, and code execution verification result data all reach their respective preset threshold values, then updating the skill file based on the feedback data is allowed; otherwise, updating is prohibited.

[0023] Specifically, digital humanities research refers to a research paradigm that uses computational methods to organize multi-source materials such as historical documents, local chronicles, archives, letters, ancient book versions, and research papers into analyzable, interpretable, and traceable knowledge structures. The full lifecycle management of skills documents covers the complete stages of skills document generation, retrieval, verification, updating, and obsolescence.

[0024] This method first acquires the digital humanities research task and its corresponding candidate corpus set. The digital humanities research task is input into the system in structured data form, containing at least the following fields: research object field, used to describe the core entity or theme of the research focus; task category field, used to identify the type of task, such as version evolution, event relationship analysis, idea dissemination analysis, etc.; time range field, used to limit the start and end years of the research focus; spatial range field, used to limit the geographical area of ​​the research focus; and corpus type field, used to specify the type of corpus required, such as local gazetteers, archives, letters, etc. The candidate corpus set is a collection of original materials related to the current research task, stored in the system's corpus. Each corpus record in the corpus contains at least the text content field, source type field, time label field, and spatial label field. The source type field can contain values ​​such as original archives, original local gazetteer texts, original statistical tables, academic papers, and secondary reprinted materials.

[0025] After acquiring a research task, the system retrieves a matching skill file from the skill file repository or generates a new skill file based on the task's characteristics. The skill file repository is the system's persistent data storage space for all skill files, and can be implemented using a relational database, document database, or file system. A skill file is a structured data file containing task rules, method constraints, and code templates to constrain code generation. Task rules define the applicable task categories and input / output specifications for the skill; method constraints contain a list of allowed analysis methods and preset method implementation rules; and code templates provide the basic framework for generating analysis code, including populated variables and logical placeholders. Skill files can be in structured text formats such as Markdown, YAML, or JSON. When calling a matching skill file, the system performs the following steps: extracting the task category, time range, spatial range, and corpus type of the current research task to form a task feature vector; traversing each candidate skill file in the skill file library, reading the task identifier field and applicable condition field of each skill file; calculating the matching degree between the candidate skill file and the current task feature vector, taking into account the consistency of task categories, the degree of overlap of time ranges, the inclusion relationship of spatial ranges, and the intersection of corpus types; selecting the skill file with the highest matching degree as the currently used skill file. If there is no skill file in the skill file library that meets the preset matching threshold, the system generates a new skill file. The generation process is as follows: based on the task category of the current task, querying the list of allowed analysis methods and the default method implementation rules corresponding to that category from the preset method rule library; determining the input field requirements and output field requirements based on the corpus type; selecting the corresponding code template based on the task category; writing the above information into the corresponding fields of the new skill file, and recording the time range and spatial range of the current task as the associated time range and associated spatial range of the new skill file.

[0026] Based on the research task and acquired skill files, the system generates and executes analysis code to obtain feedback data including analysis results and execution logs. The system inputs the code template from the skill files, the input field requirements from the task rules, and the dependency requirements into the code generation module. The code generation module reads the placeholder positions in the code template, fills in the specific parameter values ​​from the task rules into the corresponding placeholders, and generates complete executable analysis code. The analysis code can be in the form of a Python script, an R script, or a program written in another programming language. The system then calls the executor module to execute the analysis code. The executor module is the interpreter or compilation runtime environment corresponding to the target programming language. During execution, the executor module records the running status and output information. After execution, the system obtains the analysis results and execution logs. The analysis results include the code output conclusion text, statistical indicator data, chart data, and traceability information. The execution logs include the code running status (indicators of normal exit or abnormal interruption), exception stack information, exit code, execution time for each step, and dependency call records.

[0027] The system then performs three data processing steps to generate assessment data for controlling skill file updates.

[0028] First, based on the matching results between the analysis results and the evidence in the candidate corpus, evidence matching verification result data is generated. Evidence refers to specific corpus fragments in the candidate corpus that can provide support for the conclusion or serve as a counter-reference. Evidence matching verification result data is a quantitative indicator used to comprehensively evaluate the sufficiency of evidence support, the reliability of sources, and the traceability of conclusions in the analysis results.

[0029] Second, based on the consistency between the actual analysis methods recorded in the execution log and the method constraints in the skill file, method adaptation verification result data is generated. The actual analysis method refers to the algorithm or model actually called by the analysis code during execution; its name is recorded in the method record field of the execution log. Method constraints refer to the list of allowed analysis methods and preset method implementation rules recorded in the skill file. The method adaptation verification result data is a quantitative indicator used to comprehensively evaluate whether the method selection is correct and whether the method implementation is compliant.

[0030] Third, based on the execution success status and test results recorded in the execution log, code execution verification result data is generated. The execution success status is a binary identifier recorded in the execution log, indicating whether the code ran normally to completion. The test results are records of pass / fail statuses obtained after verifying each analysis result according to the preset test rule set in the skill file. The code execution verification result data is a quantitative indicator used to comprehensively evaluate code executability, output standardization, dependency validity, and operational stability.

[0031] Finally, the system performs a joint gating judgment. The threshold values ​​are pre-configured threshold parameters, with each of the evidence matching verification results, method adaptation verification results, and code execution verification results corresponding to an independent threshold value. The system compares the verification results of each of the three dimensions with their respective threshold values ​​one by one. When the verification results of all three dimensions are greater than or equal to their respective preset threshold values, the update condition is met, and the system writes the code generation rules, method validity information, and verification scores from the feedback data of this round into the corresponding fields of the current skill file. The code generation rules in the feedback data include the code template and parameter configuration actually used in this round; the method validity information includes the name and task matching degree of the method actually used in this round; and the verification scores include the specific scores for the three dimensions. During writing, a partial field update method is used, only overwriting the changed fields in the skill file while retaining the original content of the unchanged fields. When the verification result data of any of the three dimensions is less than its preset threshold value, the update condition is not met, and the system prohibits any write operations to the current skill file.

[0032] The technical principle of this implementation lies in upgrading the update control of skill files from the existing single judgment of "whether the code runs successfully" to a joint gating system encompassing three dimensions of authenticity: evidence matching, method adaptation, and code execution. Only when the analysis results meet preset credibility standards in terms of academic evidence, research methods, and engineering quality is the experience gained from the current task allowed to be incorporated into the skill file. The technical benefits are: significantly reducing the probability of erroneous rules, low-quality methods, and conclusions with insufficient evidence being written into the skill file, avoiding skill file contamination caused by a single engineering dimension judgment, thereby improving the reliability of skill accumulation in multiple task rounds and the stability of subsequent code generation.

[0033] In a preferred embodiment, generating evidence matching verification result data includes the following steps: The analysis results are parsed into structured conclusion objects containing the methods used and source information; From the candidate corpus set, retrieve candidate evidence that matches the structured conclusion object; For each candidate piece of evidence, its support direction is determined based on its consistency with the structured conclusion object in the dimensions of object, time, and space. The support direction includes support or opposition. Based on the weights of all evidence deemed to support a particular direction, generate evidence support data. Based on the source type of the evidence cited by the structured conclusion object, a preset source classification table is queried to generate source credibility data; Based on the proportion of structured conclusion objects that have verifiable traceability structures, conclusion traceability data is generated; Based on the evidence support data, source credibility data, and conclusion traceability data, the evidence matching and verification result data is generated.

[0034] Specifically, firstly, the system parses the analysis results into structured conclusion objects containing the methods used and source information. The analysis results are output by the executor module and are typically in natural language text, JSON data, or a mixture of both, and cannot be directly used for quantitative calculations. The structured conclusion object extracts each independent conclusion from the analysis results into a data structure with fixed fields, and its parsing process is completed by the conclusion structure parsing module. The specific parsing steps are as follows: First, conclusion segmentation. The system reads the text content of the analysis results and segments the results into several independent conclusion fragments based on line breaks, number markers, or conclusion text identifiers. Second, field extraction. For each conclusion fragment, the system uses regular expression matching or key-value pair parsing to extract the values ​​of fields such as conclusion text, task category, and actual method used. If the analysis results themselves are in JSON format and already contain these fields, the corresponding key values ​​are read directly. Third, source chain extraction. The system extracts source information from each conclusion fragment. Source tracing information refers to the citation data attached to the conclusion that points to the original corpus. The system locates and extracts source tracing information by recognizing specific citation marker formats (such as square bracket citation numbers, doc_id key-value pairs, or trace arrays). If there are no citation markers in the conclusion fragment, the source tracing information record for that conclusion is empty. The fourth step is object construction. The system creates a structured conclusion object instance for each conclusion, fills the extracted conclusion text into the claim_text field, the task category into the task_type field, the actual method used into the method_used field, the source tracing information into the trace field, and assigns a unique conclusion identifier claim_id to the object.

[0035] Secondly, the system retrieves candidate evidence matching the structured conclusion object from the candidate corpus set. The retrieval process is executed by the evidence mapping module, with the following steps: First, constructing retrieval conditions. The system reads the values ​​of fields such as subject, relation, object, time, and location from the structured conclusion object and uses these values ​​as search keywords. If these fields are not explicitly contained in the structured conclusion object, the system automatically extracts the subject name, time description, and location description from the conclusion text as alternative keywords using named entity recognition technology. Second, executing the retrieval. The system uses the constructed keywords to perform matching queries in the text content field, time label field, and spatial label field of the candidate corpus set. Retrieval methods include exact keyword matching based on inverted indexes and fuzzy matching based on semantic vector similarity. Exact matching is used to recall corpora containing the same entity name or time description, while fuzzy matching is used to recall corpora with similar semantics but different descriptions. Third, processing the results. The system merges the retrieval results from the two matching methods, removes duplicate corpus records, and uses the deduplicated corpus fragments as the candidate evidence set for the conclusion.

[0036] Then, for each candidate piece of evidence, the system determines its supporting direction based on its consistency with the structured conclusion object in the object, time, and space dimensions. Supporting directions are divided into two types: supporting and opposing. Supporting evidence refers to evidence whose recorded content is consistent with the direction of the conclusion statement and can strengthen the credibility of the conclusion. Opposing evidence refers to evidence whose recorded content is opposite to the direction of the conclusion statement and may weaken the credibility of the conclusion. The judgment process adopts a joint mechanism of rule-based screening and relationship judgment. The specific steps are as follows: First, rule screening. The system reads the time and space annotation values ​​of the candidate evidence and compares them with the time and space values ​​in the structured conclusion object. In the time dimension, the system determines whether the time annotation value of the candidate evidence falls within the range of the current task's set time window. If it does, the time consistency of the evidence is marked as passed; if it deviates from the time window by more than the preset tolerance (e.g., ±5 years), it is marked as time inconsistent and excluded. In the space dimension, the system determines whether the space annotation value of the candidate evidence is consistent with the spatial value of the conclusion. The system pre-maintains a mapping table of ancient and modern place names, establishing a correspondence between ancient place names (e.g., Gusu, Wujun) and modern place names (e.g., Suzhou). The system first queries the mapping table, converting the spatial annotation values ​​of candidate evidence and the spatial values ​​of the conclusion into standard geographic identifiers before performing a comparison. If the standard geographic identifiers match, spatial consistency is marked as passed; otherwise, it is excluded. At the object dimension, the system determines whether the subject name recorded in the candidate evidence matches the subject name in the conclusion. If the subject names are completely identical, object consistency is marked as passed; if the subject names are different but have a pre-defined relationship (such as different titles for the same person), the system queries the person's alias mapping table to confirm whether it is considered consistent. Candidate evidence that simultaneously meets the three conditions of object consistency, temporal consistency, and spatial consistency proceeds to the next step of relationship determination. The second step is relationship determination. Candidate evidence that has passed the rule-based screening is input into the relationship determination module. The relationship determination module reads the text content of the candidate evidence and the conclusion text of the conclusion, and uses a pre-trained natural language inference model or a rule-based relationship direction analyzer to determine whether the content recorded in the candidate evidence and the statement of the conclusion have a supporting or opposing relationship. The relationship determination module outputs a supporting direction label for each candidate piece of evidence, with a value of supporting or opposing. Meanwhile, the relationship determination module also outputs a support relationship strength score, which is between 0 and 1, indicating the degree of connection between the evidence and the conclusion.

[0037] Next, the system generates evidence support data based on the weights of all evidence deemed supportive. The system first calculates a comprehensive weight for each piece of supporting evidence. The weight of a single piece of evidence is calculated as a weighted sum of three components: the source credibility component multiplied by a first weighting coefficient, plus the matching degree component multiplied by a second weighting coefficient, and plus the relationship strength component multiplied by a third weighting coefficient. The matching degree component is calculated and recorded by the evidence mapping module during retrieval, representing the degree of matching between the evidence and the conclusion at the keyword level. The relationship strength component is output by the relationship determination module. The sum of the three weighting coefficients is 1, preferably set to 0.4 for the first weighting coefficient, 0.3 for the second, and 0.3 for the third. The system calculates the total weight of all supporting evidence as the total weight of supporting evidence. If no supporting evidence exists, the total weight of supporting evidence is recorded as 0. The system also performs the same weighted sum of the weights of all opposing evidence as the total weight of opposing evidence. The formula for calculating evidence support data is: the total weight of supporting evidence divided by the sum of the total weight of supporting evidence and the total weight of opposing evidence, plus a smoothing term. The smoothing term is a very small positive number used to prevent the denominator from being zero. Essentially, the formula represents the weighting of supporting evidence out of all directed evidence.

[0038] Simultaneously, the system queries a pre-defined source classification table based on the source type of the evidence cited by the structured conclusion object to generate source credibility data. The pre-defined source classification table is pre-maintained configuration data using a key-value pair structure. The key is the source type name, and the value is the credibility benchmark value for that source type. The credibility benchmark value ranges from 0 to 1, with higher values ​​indicating more reliable sources. For example, the credibility benchmark value for original archival documents can be set to 0.95, for original local gazetteers to 0.90, for original statistical tables to 0.88, for collation notes to 0.85, for research papers to 0.85, and for secondary reprinted materials to 0.60. The system performs the following calculation steps: iterates through all evidence bound to the current conclusion, reading the source type field of each piece of evidence; for each piece of evidence, it queries the source classification table using the source type field value as the key to obtain the corresponding credibility benchmark value; it sums the credibility benchmark values ​​of all evidence and divides by the total number of evidence pieces to obtain the arithmetic mean, which is the source credibility data.

[0039] Furthermore, the system generates conclusion traceability data based on the proportion of structured conclusion objects with verifiable traceability structures. A verifiable traceability structure refers to a structured conclusion object where the `trace` field is not empty, and at least one traceability record can be actually located by the system. The system performs the following verification steps: Iterate through all structured conclusion objects output in this round. For each conclusion object, check if a `trace` field exists; if not, mark it as untraceable. If a `trace` field exists and `trace` is a non-empty array, check if at least one record in the `trace` array contains both a valid `doc_id` field and a `segment_id` field. If no such record exists, mark it as untraceable. If it exists, further verification is performed: a precise query is performed in the database using the `doc_id` value to determine if a record with that document identifier exists. If not, mark it as untraceable. If it exists, the system uses the `segment_id` value to locate the specific paragraph, table item, or text fragment within the document record, determining if the `segment_id` can be parsed into a valid location identifier and located to the specific content. If successful, the conclusion is marked as traceable. The system counts the number of conclusions marked as traceable, divides this number by the total number of conclusions in this round, and adds a smoothing term to obtain the conclusion traceability data. This data reflects the proportion of conclusions in this round of analysis that can be traced back to specific fragments of the original literature.

[0040] Finally, the system generates evidence matching verification result data by weighted summation based on evidence support data, source credibility data, and conclusion traceability data. The fusion weights of the three components can be preset and configured, with preferred settings of evidence support weight at 0.4, source credibility weight at 0.3, and conclusion traceability weight at 0.3.

[0041] In a preferred embodiment, the generation method adapts to the verification result data and includes the following steps: Determine the task category of the research task and the analysis method actually invoked by the analysis code; Query the preset mapping table between task categories and allowed analysis method sets, determine whether the analysis method actually called exists in the allowed analysis method set corresponding to the current task category, and generate task matching data accordingly; Check whether the analysis method actually invoked meets the preset method implementation rules recorded in the skill file, and generate rule compliance data accordingly; Based on the task matching degree data and rule compliance degree data, the method adaptation verification result data is generated.

[0042] Specifically, first, the system determines the task category of the research task and the analysis method actually invoked by the analysis code. The task category is a label used by the system to classify digital humanities research tasks. The system reads the value of the task category field from the structured data of the research task to obtain the task category of the current task. The analysis method actually invoked refers to the analysis algorithm or model actually used by the analysis code during execution. The system reads the name of the analysis method actually invoked from the method record field of the execution log. If the method name is not explicitly recorded in the execution log, the system obtains it from the method selection record in the code generation chain.

[0043] Secondly, the system queries a pre-defined mapping table between task categories and sets of allowed analysis methods to determine if the actually invoked analysis method exists in the set of allowed analysis methods corresponding to the current task category, and generates task matching data accordingly. The mapping table is a pre-built and maintained data structure, which can be stored as a database table, a JSON configuration file, or a key-value pair mapping. Each record in the mapping table contains a task category name and a list of allowed analysis methods corresponding to that task category. The list of allowed analysis methods is an array, where each element is the name string of an analysis method. The mapping table is constructed based on methodological norms in the digital humanities field. For example, when the task category is version evolution, the list of allowed analysis methods includes textual difference comparison, collation note parsing, and version chain reconstruction. When the task category is event relationship analysis, the list of allowed analysis methods includes event network analysis, temporal relationship analysis, and co-occurrence relationship analysis. When the task category is concept dissemination analysis, the list of allowed analysis methods includes dissemination path analysis, citation chain analysis, and concept diffusion analysis. The system performs the following matching judgment: using the task category of the current task as the key, it queries the mapping table for the corresponding list of allowed analysis methods. Iterate through the list, comparing each method name in the list with the name of the actual analyzed method being called. If a matching method name is found, assign a value of 1 to the task matching score. If no matching method name is found after the iteration, assign a value of 0 to the task matching score.

[0044] Then, the system checks whether the actual called analysis method meets the preset method implementation rules recorded in the skill file, and generates rule compliance data accordingly. The preset method implementation rules are part of the method constraint field in the skill file, stored as a list of rule entries. Each rule entry is an independently verifiable judgment condition. Rule entries must include at least the following types: structured source tracing output rules, requiring each conclusion in the analysis results to include a trace field that is a non-empty array; source mapping output rules, requiring each conclusion in the analysis results to include at least a doc_id field and a source_type field in its trace record; field dependency rules, requiring the analysis code to read and process all input fields specified in the skill file when processing input data, without omission; template call rules, requiring the structure of the analysis code to match the structure of the code template in the skill file, and that key code blocks in the template be actually called; and method restriction rules, explicitly listing the names of analysis methods prohibited in the current task, requiring that the actual method used is not in this prohibited list. The system performs the following line-by-line verification: iterates through the list of preset method implementation rules, and for each rule, calls the corresponding verification function according to its type. For structured source tracing output rules and source mapping output rules, the validation function reads each structured conclusion object in the analysis results and checks whether it meets the conditions defined in the rule. For field dependency rules, the validation function reads the input field usage records in the execution log and checks whether all specified input fields have been accessed. For template invocation rules, the validation function reads the code execution path records in the execution log and checks whether all key code blocks of the template have been executed. For method restriction rules, the validation function compares the name of the analysis method actually called with the name in the prohibited list one by one to confirm that there are no matches. Each rule that passes the validation is recorded as passed, and that which fails the validation is recorded as violated. The number of violated rules and the total number of rules are counted. The rule compliance data is calculated using the formula: 1 minus the number of violated rules divided by the sum of the total number of rules and the smoothing term. When no rules are violated, the rule compliance data is close to 1; when there are many violated rules, the rule compliance data decreases accordingly.

[0045] Finally, the system generates method adaptation verification result data based on task matching data and rule compliance data through weighted summation. The fusion weights satisfy the condition that the sum of the two weight coefficients is 1. Preferably, the task matching weight coefficient and the rule compliance weight coefficient are both set to 0.5. That is, the method adaptation verification result data equals the task matching data multiplied by 0.5 plus the rule compliance data multiplied by 0.5.

[0046] In a preferred embodiment, generating code execution verification result data includes the following steps: Based on the code execution status in the execution log, determine whether the execution was successful or failed, and generate execution success data; Based on the preset test rule set in the skill file, verify whether the analysis results meet the expected field output requirements, and use the proportion of rules that pass as the test pass rate data; Check whether the external libraries or interfaces that the analysis code depends on are valid, and generate dependency validity data; Based on the consistency of the output of the analysis code when it is run multiple times under the same conditions, runtime stability data is generated. Based on the execution success rate data, test pass rate data, dependency validity data, and runtime stability data, the code execution verification result data is generated.

[0047] First, the system determines whether the execution was successful or failed based on the code execution status in the execution log, generating execution success data. The code execution status field in the execution log is automatically written by the executor module when the code execution ends. The system reads the value of this field. If the value of this field is a normal exit indicator (e.g., exit code 0 or status indicator "success"), the execution success data is assigned a value of 1. If the value of this field is an abnormal exit indicator (e.g., exit code non-zero or status indicator "failure" or "error"), or if the execution log contains stack traces of uncaught exceptions, the execution success data is assigned a value of 0. This determination only concerns whether the code ran normally to the end and does not involve evaluating the correctness of the output results.

[0048] Secondly, the system verifies whether the analysis results meet the expected field output requirements based on the pre-set test rule set in the skill file, and uses the proportion of rules that pass as the test pass rate data. The test rule field in the skill file stores the test rule set, which is a list of rule entries. Each test rule includes a rule type and rule parameters. The rule type determines the execution method of the verification, and the rule parameters provide the specific conditions required for verification. The types of test rules include at least: field existence verification rules, whose rule parameter is the field name; the system checks whether the analysis results contain a field with that name; field integrity verification rules, whose rule parameters are the field name and minimum fill rate; the system checks whether the proportion of non-null values ​​for that field in all records of the analysis results meets the minimum fill rate requirement; traceability output verification rules, whose rule parameter is a list of required traceability fields (such as doc_id, segment_id); the system checks whether each record in the trace array of the analysis results contains all fields in the list; and critical logic verification rules, whose rule parameter is an assertion condition expression; the system substitutes the corresponding variable values ​​from the analysis results into the assertion condition expression and judges whether the expression evaluation result is true. The system performs the following rule-by-rule verification: It iterates through each rule in the test rule set, reading its rule type and parameters; it calls the corresponding verification function based on the rule type; the verification function returns a pass or fail result. The number of pass rules is counted and divided by the sum of the total number of test rules and the smoothing term to obtain the test pass rate.

[0049] Then, the system checks and analyzes whether the external libraries or interfaces that the code depends on are valid, generating dependency validity data. The dependency requirement field in the skill file stores a dependency list, which is a list where each record contains the dependency name and version requirement. The system performs the following steps by calling the dependency checking module: Reading all records in the dependency list. For each record, querying the code execution environment to see if the dependency with that name has been installed. If not installed, the dependency is marked as invalid. If installed, reading the actual version number of the dependency and comparing it with the version requirement recorded in the list. The comparison rule is to check if the actual version number is within the compatibility range specified by the version requirement. If not within the compatibility range, the dependency is marked as invalid. If within the compatibility range, checking if there are any deprecated function calls in the dependency (by querying a preset list of deprecated functions). If deprecated calls exist, the dependency is marked as invalid. If none of the above three conditions are met, the dependency is marked as valid. The number of dependencies marked as invalid is counted, and the dependency validity data is calculated using the formula: 1 minus the number of invalid dependencies divided by the sum of the total number of dependencies and smoothing items.

[0050] Furthermore, the system generates operational stability data based on the consistency of output from multiple runs of the analysis code under identical conditions. Identical conditions refer to identical input data content, identical skill file versions, and identical dependency environment configurations. The system performs the following steps: For the same research task, using the same skill file and identical input data, the analysis code is repeatedly executed multiple times, ideally five times. After each execution, a set of key output results is extracted from the analysis results. Key output results refer to quantitative indicators that represent the core output of the code, including at least: values ​​of key conclusion fields, numerical values ​​of key statistical indicators, and a list of the top few positions in the ranking of key nodes. The system constructs an output set from the key output results obtained from multiple executions. For numerical key outputs, the variance of the output in each execution is calculated. The variance is calculated as the average of the sum of squares of the differences between the value of each execution and the mean of multiple executions. For ranking-type key outputs, the fluctuation range of the ranking position in each execution is calculated. Then, the system uses the variance or fluctuation range as input and substitutes it into the operational stability calculation formula. The operational stability calculation formula uses an exponential decay function: with the natural constant e as the base, and the variance multiplied by a negative adjustment coefficient as the exponent, the calculated value is the operational stability data. The adjustment coefficient is a positive number, used to control the rate at which the variance decays the stability score. When the variance is 0, the operational stability data is 1, indicating that all outputs are completely consistent. The larger the variance, the closer the operational stability data is to 0, indicating that the output is more unstable.

[0051] Finally, the system generates code execution verification result data by weighted summation based on execution success rate data, test pass rate data, dependency validity data, and runtime stability data. The sum of the fusion weight coefficients for the four dimensions is 1. Ideally, the four dimensions are equally weighted, i.e., each weight coefficient is 0.25. The calculation formula for the code execution verification result data is: execution success rate data multiplied by the first weight coefficient, plus test pass rate data multiplied by the second weight coefficient, plus dependency validity data multiplied by the third weight coefficient, plus runtime stability data multiplied by the fourth weight coefficient.

[0052] In a preferred embodiment, generating evidence support data includes the following steps: Obtain all evidence that is determined to support the direction, and form a set of supporting evidence; The evidence in the supporting evidence set is compared pairwise to determine whether there are contradictory pairs between the evidence; the contradictory pair between the evidence is defined as: the difference between the recorded values ​​of the two pieces of evidence on the same attribute dimension involved in the structured conclusion object exceeds a preset tolerance threshold; the attribute dimension includes time attribute, spatial attribute, quantity attribute, person attribute and event type attribute; If there are contradictory pairs of evidence, a contradiction marker signal is generated. The contradiction marker signal is used to trigger a downgrade or rejection of the evidence support data in subsequent gating decisions.

[0053] First, the system acquires all evidence deemed to support a particular direction, forming a supporting evidence set. During the direction-of-support determination process, the relationship determination module has labeled each candidate piece of evidence with a supporting direction tag, with values ​​indicating support or opposition. The system iterates through all candidate evidence associated with the current structured conclusion object, filtering out evidence records labeled as supporting, and aggregating these evidence records into a supporting evidence set. Each evidence record contains the following fields: evidence identifier (uniquely identifying the evidence), evidence text content, source type, source credibility score, matching score with the conclusion, supporting relationship strength score, comprehensive weight value, and specific values ​​recorded for the evidence in terms of time, space, quantity, person, and event type attributes. These attribute values ​​are structured information extracted from the candidate corpus during the evidence mapping stage. The recorded value of the time attribute is the year or period in which the event described by the evidence occurred; the recorded value of the spatial attribute is the name of the geographical location involved in the evidence; the recorded value of the quantity attribute is quantifiable information appearing in the evidence (such as population size, grain price, migration distance, etc.); the recorded value of the person attribute is the name or identity of the main person mentioned in the evidence; and the recorded value of the event type attribute is the category label of the event described by the evidence.

[0054] Secondly, the system performs pairwise comparisons of the evidence in the supporting evidence set to determine whether any contradictory pairs exist. Pairwise comparison refers to performing contradiction checks on each unique pair of evidence in the supporting evidence set. For a supporting evidence set containing N pieces of evidence, the system generates C(N,2) evidence pair combinations. For each evidence pair, the system performs the following contradiction detection steps: First, determine the attribute dimensions for contradiction detection. The system reads the list of attribute dimensions involved in the current structured conclusion object. This list is automatically generated by the task parsing phase based on the content of the research task, recording the attribute dimension types upon which the conclusion depends in its formation, including at least one or more of the following: time attribute, spatial attribute, quantity attribute, person attribute, and event type attribute. Second, for each attribute dimension in the list, the system reads the recorded values ​​of the two pieces of evidence on that attribute dimension. If either piece of evidence has no recorded value on that attribute dimension, the attribute dimension is skipped, and no contradiction judgment is performed. If both pieces of evidence have recorded values ​​on that attribute dimension, the process proceeds to the third step. Third, calculate the difference between the recorded values ​​of the two pieces of evidence on that attribute dimension. For the time attribute, the difference is calculated as the absolute value of the difference between the years recorded by the two pieces of evidence. For spatial attributes, the discrepancy assessment first requires converting the spatial records of the two pieces of evidence into standard geographic identifiers using an ancient and modern place name merging mapping table. If the standard geographic identifiers differ, a discrepancy is considered to exist. For quantitative attributes, the discrepancy is calculated by dividing the absolute value of the difference between the recorded values ​​of the two pieces of evidence by the mean of the recorded values, yielding the relative deviation. For personal attributes, the discrepancy assessment checks whether the personal names recorded in the two pieces of evidence are the same (considering alias mapping). For event type attributes, the discrepancy assessment checks whether the event category labels recorded in the two pieces of evidence are consistent. The fourth step involves comparing the calculated discrepancy with a preset tolerance threshold. The preset tolerance threshold is the upper limit of allowable deviation pre-configured by the system for different attribute dimensions. For time attributes, the tolerance threshold can be set to 5 years, meaning that a difference of more than 5 years between the recorded years of the two pieces of evidence is considered a contradiction. For quantitative attributes, the tolerance threshold can be set to 0.2, meaning that a relative deviation of more than 20% between the quantitative records of the two pieces of evidence is considered a contradiction. For personal and event type attributes, the tolerance threshold is 0, meaning that inconsistency between the recorded values ​​of the two pieces of evidence is considered a contradiction. If the difference exceeds the tolerance threshold of the corresponding attribute dimension, the evidence pair is determined to constitute a contradictory pair of evidence on that attribute dimension. An evidence pair may constitute a contradictory pair on multiple attribute dimensions simultaneously.

[0055] The data structure for contradictory evidence pairs should include at least the following fields: contradiction identifier, evidence identifier of the first piece of evidence, evidence identifier of the second piece of evidence, contradiction attribute dimension, recorded value of the first piece of evidence in that attribute dimension, recorded value of the second piece of evidence in that attribute dimension, and difference magnitude.

[0056] Finally, if the system detects at least one contradictory pair of evidence, it generates a contradiction marker signal. The contradiction marker signal is an internal system status indicator used to trigger a downgrade or rejection of the evidence support data in subsequent gating decisions. The generation process of the contradiction marker signal is as follows: the system creates a contradiction marker record containing a list of all contradictory pairs of evidence detected in this round, the total number of contradictory pairs, and the number of pieces of evidence involving the contradiction. This contradiction marker record is appended to the feedback data structure of the current task and transmitted along with the feedback data to the subsequent gating decision module.

[0057] In a preferred embodiment, the contradiction marker signal triggers a downgrade or rejection of the evidence support data in subsequent gating decisions, including the following steps: When there are contradictory pairs of evidence, extract the contradictory attribute dimensions and the source types of the evidence from both sides of the contradiction from each contradictory pair to generate a contradictory structure description object; The object describing the contradiction structure is compared with the task category of the current research task to determine whether the contradiction falls within the scope of the contradiction associated with the task category, i.e., the triggering range of the discovery rule. If so, the object describing the contradictory structure will be added to the feedback data as a new discovery in this round of analysis, and the new discovery will be written to the analysis log field of the skill file when updates are allowed. If not, the evidence support data will be reduced according to the preset reduction rules.

[0058] First, when a contradiction marker signal is generated, indicating that at least one pair of contradictory evidence exists in the supporting evidence set of this round of analysis, the system initiates the contradiction handling process. The first step of the contradiction handling process is to extract the contradiction attribute dimension and the source type of the evidence from both sides of the contradiction from each contradiction pair, generating a contradiction structure description object. The contradiction structure description object is a data structure that aggregates and standardizes key information scattered across multiple contradiction pairs. Its generation process is as follows: The system traverses all pairs of contradictory evidence recorded in the contradiction marker signal. For each contradiction pair, the system reads the value of its contradiction attribute dimension field and the value of the source type field of the evidence from both sides of the contradiction. The system merges contradiction pairs with the same contradiction attribute dimension and counts the number of contradiction pairs appearing under each contradiction attribute dimension. The system removes duplicates of the source type of the evidence from both sides of the contradiction to form a source type list. The finally generated contradiction structure description object contains the following fields: contradiction attribute dimension (a list of attribute dimensions involved in all contradictions detected in this round), the number of contradiction pairs corresponding to each attribute dimension, the list of source types of evidence involved in the contradiction, the total number of contradiction pairs, and the total number of pieces of evidence involved in the contradiction.

[0059] Secondly, the system compares the object describing the contradiction structure with the task category of the current research task to determine whether the contradiction falls within the trigger range of the contradiction discovery rule associated with the task category. The contradiction discovery rule is a set of pre-defined judgment logics. Its core idea is that the core research object of some digital humanities research tasks is itself based on attribute differences. For such tasks, contradictions between supporting evidence regarding the attributes of the core research object are not errors that require deduction, but rather discoveries that may reveal important research clues. The judgment process is executed by the contradiction transformation judgment module. The system reads the task category of the current research task and simultaneously reads the list of contradiction attribute dimensions recorded in the object describing the contradiction structure. The system uses the task category and each contradiction attribute dimension as input parameters and calls the judgment function of the contradiction discovery rule. The judgment function returns a boolean value indicating whether the contradiction attribute dimension falls within the trigger range. If the judgment result of at least one contradiction attribute dimension in the object describing the contradiction structure is yes, then the entire contradiction is judged to fall within the trigger range of the contradiction discovery rule.

[0060] Then, the system executes the processing in two separate steps based on the judgment result.

[0061] In the first stage of processing, when a conflict is determined to fall within the trigger range of the conflict discovery rule, the system treats the conflict structure description object as a new discovery item in this round of analysis. A new discovery item refers to valuable information additionally identified by the system during this round of code execution, beyond the user's expected task output. The system encapsulates the conflict structure description object into a new discovery item record and appends it to the new discovery item list in the feedback data. In subsequent update gating decisions, if the feedback data in this round is allowed to be written to the skill file, the new discovery item is written to the analysis log field of the skill file. Upon writing, the system appends a record to the analysis log field, which includes a timestamp, task category, conflict attribute dimension, source information of evidence from both sides of the conflict, and the specific magnitude of the conflict's differences.

[0062] The second approach involves reducing the evidence support level data according to a preset downgrade rule when the conflict is determined not to fall within the trigger range of the conflict detection rule. This preset downgrade rule defines the specific method for deducting from the evidence support level data based on the severity of the conflict. The downgrade rule can be implemented using a proportional deduction method. The system first calculates a conflict severity factor, which comprehensively considers the number of conflict pairs and the magnitude of their differences. For example, the severity factor can be calculated as the ratio of the number of conflict pairs to a preset baseline number, multiplied by the ratio of the average magnitude of the differences among all conflict pairs to a preset maximum tolerance range. The system multiplies the calculated severity factor by the current value of the evidence support level data to obtain the deduction amount. The system then updates the evidence support level data to the current value minus the deduction amount. If the evidence support level data is less than 0 after the deduction, it is set to 0.

[0063] In a preferred embodiment, determining whether a contradiction falls within the triggering range of a discovery rule associated with the task category includes the following steps: Read the task category of the current research task; Query the preset task category-conversion attribute mapping table to obtain a list of conversion attribute dimensions corresponding to the current task category; the task category-conversion attribute mapping table is a data structure in which each task category is associated with at least one attribute dimension, indicating that when a conflict occurs in these attribute dimensions, the conflict should be converted into a discovery rather than a deduction item; Read the contradictory attribute dimensions from the contradictory structure description object; If the contradictory attribute dimension exists in the list of transformation attribute dimensions, then the contradiction is determined to fall within the trigger range; otherwise, it is determined not to fall within the range.

[0064] First, the system reads the task category of the current research task. The task category is stored in the structured data of the research task and is extracted and recorded by the system during the task parsing phase. The system directly reads the value of the task category field from the task data structure to obtain a string-based task category identifier, such as version evolution, event relationship analysis, idea dissemination analysis, or correspondence network analysis.

[0065] Secondly, the system queries a pre-defined task category and transformation attribute mapping table to obtain a list of transformation attribute dimensions corresponding to the current task category. The task category and transformation attribute mapping table is a pre-built and maintained data structure, which can be stored as a database table, a JSON configuration file, or a structured file organized in key-value pairs. The mapping table has two columns: the first column is the task category name, with a string data type; the second column is the list of transformation attribute dimensions, with a string array data type. Each element in the list of transformation attribute dimensions is the name of an attribute dimension, indicating that when a contradiction between supporting evidence occurs in that attribute dimension, the contradiction should be transformed into a discovery rather than a deduction. For example, the mapping table may contain the following records: When the task category is version evolution, the list of transformation attribute dimensions includes text content, word differences, and paragraph additions / deletions. This is based on the fact that the core object of version evolution research is the textual changes between different versions; therefore, contradictions in the text content dimension are the key differences that need to be discovered. When the task category is administrative evolution, the list of transformation attribute dimensions includes spatial scope and affiliation. This is based on the fact that contradictory records of the same jurisdiction in administrative archives at different levels or periods may reveal the time nodes and trajectory of administrative division adjustments. When the task category is event relationship analysis, the list of transformation attribute dimensions includes the event subject and event relationships. This is based on the different perspectives and informational differences in historical records regarding the same event, which may reveal complex aspects of the event or the information dissemination path. When the task category is demographic analysis, the list of transformation attribute dimensions is an empty array. This is based on the fact that the core objective of this task category is to obtain accurate quantitative indicators; contradictions in quantitative attributes are data quality issues that need to be corrected and should not be considered discoveries. The system uses the task category of the current task as the query key and performs an exact match query in the mapping table to obtain the list of transformation attribute dimensions corresponding to that key. If there is no record for the current task category in the mapping table, an empty list is returned as the default value.

[0066] Then, the system reads the contradictory attribute dimensions from the contradictory structure description object. The contradictory structure description object is a data structure in which the contradictory attribute dimension field records a list of attribute dimensions involved in all contradictory pairs of evidence in this round. The system iterates through this list and performs the following judgment on each contradictory attribute dimension in the list.

[0067] Finally, the system checks each contradictory attribute dimension to see if it exists in the list of transformed attribute dimensions. The method is exact string matching: the name of the current contradictory attribute dimension is compared with each element in the list of transformed attribute dimensions. If a matching element exists, the contradictory attribute dimension is considered to fall within the trigger range. If no match is found after traversing all elements in the list of transformed attribute dimensions, the contradictory attribute dimension is considered not to fall within the trigger range. The system then considers all the results of the contradictory attribute dimensions: if at least one contradictory attribute dimension falls within the trigger range, the overall result is considered positive.

[0068] In a preferred embodiment, the task category-conversion attribute mapping table is constructed through the following steps: Retrieve all historical records of successfully updated skill files to form a set of historical successful tasks; each task record includes the task category, records of contradictory evidence during execution, and whether the task ultimately triggered a new discovery. For each task category, the distribution of attribute dimensions of contradictory evidence pairs that have appeared in all historical successful tasks under that category is statistically analyzed. For each attribute dimension, calculate its transformation confidence, which is: under this task category, when the contradiction between evidences involves this attribute dimension, the ratio of the number of tasks in which the contradiction is finally transformed into a new discovery to the number of tasks in which the contradiction is finally deducted points according to the preset downgrade rule; Attribute dimensions whose conversion confidence exceeds the preset conversion threshold are added to the conversion attribute dimension list corresponding to the task category.

[0069] First, the system retrieves all historical records of successfully updated skill files, forming a historical successful task set. These records are stored in the system's task log database or in the skill file's update history field. Each task record contains at least the following fields: task identifier, task category, records of contradictory evidence pairs generated during the task's execution, and whether the task ultimately triggered a new discovery. The contradictory evidence pair record is a list structure, where each element records the name of the contradictory attribute dimension involved in the contradictory pair. Whether a new discovery was triggered is a boolean field, recording whether the contradictory marker signal was converted into a new discovery and written to the skill file's analysis log field after the task's execution judgment. The system iterates through all records in the task log database, filtering out records where the skill file update status is successful and the updated content has been written to the skill file, aggregating these records to form the historical successful task set. The size of this set grows continuously with system usage.

[0070] Secondly, for each task category, the system statistically analyzes the attribute dimension distribution of contradictory evidence pairs that have appeared in all historical successful tasks within that category. The system performs the following grouping statistics: iterates through all task records in the historical successful task set, using the task category field value as the grouping key, and divides the task records into their respective task category groups. For each task category group, it iterates through the list of contradictory evidence pairs for all task records within that group, extracting the value of the contradictory attribute dimension field for each contradictory evidence pair. The system maintains an attribute dimension counter mapping table, using the attribute dimension name as the key and the occurrence count as the value. Each time a contradictory attribute dimension is encountered, the system increments the corresponding count value in the mapping table by 1. After the statistics are completed, the total number of times each attribute dimension is involved in a contradictory event is obtained for each task category.

[0071] Then, for each attribute dimension under each task category, the system calculates its transformation confidence score. The transformation confidence score measures the reliability of a contradiction being ultimately determined as a valuable discovery when it involves that attribute dimension within that task category. The calculation process is as follows: The system iterates through all task records belonging to that task category in the historical successful task set and counts two values. The first value is the number of tasks where a contradiction is transformed into a discovery: counting the number of tasks within that task category where the contradiction between pieces of evidence contains that attribute dimension and the triggering new discovery field of the task record is "yes". The second value is the number of tasks where a contradiction is penalized: counting the number of tasks within that task category where the contradiction between pieces of evidence contains that attribute dimension and the triggering new discovery field of the task record is "no". The transformation confidence score is calculated as: the number of tasks where a contradiction is transformed into a discovery divided by the number of tasks where a contradiction is penalized. The higher this ratio, the more frequently contradictions involving that attribute dimension have been adopted as valuable discoveries in the past within that task category, and the higher the confidence score of their transformation into discoveries. If the denominator is 0 (i.e., never deducted points), the transformation confidence score is directly assigned a preset maximum value. If the numerator is 0 (i.e., never transformed into discovery), the transformation confidence score is 0.

[0072] Finally, the system adds attribute dimensions with conversion confidence exceeding a preset conversion threshold to the conversion attribute dimension list corresponding to that task category. The preset conversion threshold is a pre-configured decision threshold used to filter attribute dimensions with sufficiently high confidence. For example, the conversion threshold can be set to 1.0, meaning that an attribute dimension is only included in the conversion attribute dimension list if the number of conversions to "discovery" exceeds the number of deductions. For each task category, the system iterates through all attribute dimensions under that category whose conversion confidence has been calculated. The names of attribute dimensions with conversion confidence greater than the conversion threshold are collected into a list, which is used as the value of the conversion attribute dimension list field in the corresponding record of that task category in the mapping table. As the set of historical successful tasks accumulates, the system can periodically or incrementally recalculate the conversion confidence of each attribute dimension after each successful update and dynamically update the conversion attribute dimension list corresponding to each task category in the mapping table, continuously improving the accuracy of the mapping table with system use.

[0073] In a preferred embodiment, when any one of the evidence matching verification result data, method adaptation verification result data, or code execution verification result data fails to reach its preset threshold, the following steps are performed: Retain the currently used skill file and prohibit writing the feedback data from this round into the skill file; Determine the failure type based on the data type of the verification result that did not meet the requirements; When the failure type is that the method adaptation verification result data does not meet the standard, an alternative analysis method is selected from the method constraints recorded in the skill file, or an alternative skill file that matches the task category of the current task and whose historical method adaptation verification result data meets the standard is retrieved from the skill file library. The analysis code is then regenerated and executed based on the alternative analysis method or the alternative skill file.

[0074] First, when any of the evidence matching verification result data, method adaptation verification result data, or code execution verification result data fails to reach its preset threshold in the joint gating judgment, the system enters the failure handling process. The first step of the failure handling process is to preserve the currently used skill file unchanged and prohibit writing the feedback data of this round to the skill file. The system implements this control by setting a write prohibition flag. The write prohibition flag is a Boolean variable. When the joint gating judgment is passed, the flag is set to false, allowing the write operation to be performed. When the judgment fails, the system sets the flag to true. When the skill file update module detects that the write prohibition flag is true, it skips all field write operations, keeping the original content of each field in the skill file unchanged. At the same time, the system stores the feedback data of this round in the form of temporary records in the system memory or temporary storage area, retaining the execution logs, analysis results, and verification scores contained therein for failure cause analysis and subsequent handling, but does not write it to any persistent fields of the skill file.

[0075] Secondly, the system determines the failure type based on the data type of the verification results that did not meet the standards. The system checks the verification result data for each of the three dimensions against its corresponding threshold value. If the evidence matching verification result data is less than its preset threshold value, the failure type is marked as evidence matching failure. If the method adaptation verification result data is less than its preset threshold value, the failure type is marked as method adaptation failure. If the code execution verification result data is less than its preset threshold value, the failure type is marked as code execution failure. If multiple dimensions of verification result data fail simultaneously, the system marks the failure type as the highest priority failure type, in the order of evidence matching failure, method adaptation failure, and code execution failure. This priority order is based on the following: evidence matching failure reflects a fundamental flaw in the academic authenticity of the conclusion and should be addressed first. Method adaptation failure reflects problems in method selection or implementation and is the next highest priority. Code execution failure reflects engineering quality problems and is the next lowest priority.

[0076] Then, the system executes the corresponding closed-loop handling measures based on the failure type.

[0077] When the failure type is "method adaptation verification result data not meeting the standard," the system selects an alternative analysis method from the method constraints recorded in the current skill file, or retrieves an alternative skill file from the skill file library that matches the task category of the current task and whose historical method adaptation verification result data meets the standard. The system then regenerates and executes the analysis code based on the alternative analysis method or the alternative skill file. The method constraints store a list of allowed analysis methods, containing all analysis method names allowed in the current skill file. The system reads all method names from this list. If there are other methods in the allowed analysis method list that are different from the currently invoked analysis method, the system selects an alternative analysis method. The selection rule is as follows: if the method constraints in the skill file also record method priority ranking information, the highest-ranking method that is different from the currently invoked method is selected in descending order of priority. If no priority is recorded, the first method different from the currently invoked method is selected according to the order in the list. If there are no other available methods in the allowed analysis method list, i.e., the list only contains the currently invoked method, the system then performs a search for an alternative skill file. The process of retrieving alternative skill files is as follows: The system uses the task category of the current task as the query condition and searches the skill file library for all skill files that match the task category. In the query results, the system reads the historical verification record field of each skill file, filters out skill files whose historical method adaptation verification results are greater than or equal to the method adaptation threshold, sorts them in descending order of historical total verification score, and selects the highest-ranked skill file as the alternative skill file. If no alternative skill file matching the criteria is found, the system generates a new skill file as the alternative based on the task category of the current task. After determining the alternative analysis method or alternative skill file, the system inputs the current research task and the alternative analysis method (or alternative skill file) into the code generation module, regenerates the analysis code, and calls the executor module to execute the code. The new feedback data obtained after execution re-enters the evaluation data generation and gating decision process.

[0078] In a preferred embodiment, after determining the failure type based on the data type of the unqualified verification result, the method further includes the following steps: When the failure type is that the evidence matching verification result data does not meet the standard, supplement the evidence in the candidate corpus set, or increase the traceability requirements of the structured conclusion object and regenerate the analysis code and execute it. When the failure type is that the code execution verification result data does not meet the standard, the analysis code is regenerated and executed after repairing the dependency environment or supplementing the test rules based on the dependency validity data or the test pass rate data.

[0079] Specifically, when the failure type is that the evidence matching verification result data does not meet the standards, the system performs at least one of the following two measures. The first measure is to supplement the evidence retrieval in the candidate corpus set. The system reads the list of structured conclusion objects from the feedback data of the failed task in this round. For each structured conclusion object, the system extracts the values ​​of its subject field, time field, and space field as keywords for supplementary retrieval. The scope of supplementary retrieval is not limited to the candidate corpus set initially provided by the task, but extends to a wider range of external data sources connected to the system, including but not limited to other corpora within the system not included in the initial candidate corpus set, external archive open databases, and academic paper databases. The system uses the supplementary retrieval keywords to perform the same retrieval operation in the extended data sources as the retrieval process, adding the newly matched corpus records to the candidate corpus set. After expanding the candidate corpus set, the system re-executes the entire process of generating evidence matching verification result data based on the expanded candidate corpus set, and performs joint gating judgment again based on the new evidence matching verification result data. The second measure is to increase the traceability requirements of structured conclusion objects. The system reads the conclusion records that have been determined to be untraceable in the analysis results of this round and removes them from the analysis results. The system then adjusts the parameter configuration of the code generation module, changing the source tracing output requirement from optional to mandatory. This means the generated analysis code must include a complete structured source tracing chain for each conclusion; otherwise, code generation fails. The system regenerates the analysis code using the adjusted configuration and executes it. The new analysis results obtained after execution then re-enter the evaluation data generation and gating decision process.

[0080] When the failure type is "code execution verification result data not meeting the standard," the system executes corresponding remedial measures based on the specific sub-dimension that failed to meet the standard among the four sub-dimensions of the code execution verification result data. The system first reads the sub-dimension scores of the code execution verification result data generated in this round, including execution success rate data, test pass rate data, dependency validity data, and runtime stability data, and compares them one by one with their corresponding sub-threshold values ​​to determine the sub-dimension that failed. If the execution success rate data fails to meet the standard (i.e., code execution failed), the system reads the exception stack information and error log from the execution log, appends the error information as a remedial prompt to the input of the code generation module, requiring the code generation module to correct syntax or logical errors in the code according to the error type and then regenerate the analysis code. If the test pass rate data fails to meet the standard, the system reads the failed rule entries from the test rule set, appends the specific conditions of the failed rules as remedial constraints to the input of the code generation module, requiring the regenerated code to meet the verification conditions of these failed rules. If the dependency validity data fails to meet the standard, the system reads the invalid dependency list output by the dependency check module, and for each invalid dependency, performs a remedial operation based on its failure reason. For uninstalled dependencies, the system automatically invokes the package manager to execute the installation command. For incompatible dependencies, the system attempts to adjust the dependency version to a compatible version. For dependencies with deprecated calls, the system records the names of deprecated functions in the constraints of the code generation module, requiring that these functions be avoided when regenerating code. After the repair is complete, the system re-executes dependency checks to confirm that the dependency validity data meets the standards. If the runtime stability data does not meet the standards, the system reads the difference information of the output from multiple runs to locate the key variable with the largest output fluctuation. The system passes the stability requirement of this variable as a constraint to the code generation module, requiring that deterministic guarantees be added to the calculation logic of this variable when regenerating code, such as setting a fixed random number seed or adjusting the code logic of the external state of the dependency. After the repair is complete, the system re-executes the analysis code based on the repaired code or environment to obtain new feedback data, and then re-enters the evaluation data generation and gating judgment process.

[0081] Example 2 Building upon Example 1, this example uses skill.md as a unified intermediate artifact in the digital humanities code generation process. skill.md simultaneously carries: task rules; method constraints; code templates; input requirements; dependency requirements; test rules; execution feedback; callback results; and historical update information. Upon receiving a digital humanities task, the system generates a new skill.md or calls an existing skill.md, and then generates analysis code based on the skill.md. After the analysis code is executed, the system obtains the analysis results, runtime logs, test results, dependency check results, and feedback callback results, and calculates: academic authenticity score; methodological authenticity score; and engineering authenticity score, respectively. Then, based on the joint gating result of the three types of scores, the system decides: whether to update the current skill.md; whether to retain the method configuration corresponding to the current skill.md; and whether to switch to an alternative skill.md or alternative method to regenerate the code. Therefore, this application does not simply write experience back to the memory bank, but rather unifies skill generation, code generation, and feedback updates into the structured artifact skill.md, and controls its updates through a triple authenticity joint control. In this application, skill.md is a structured skill description file used to record task constraints, method rules, code generation rules, execution requirements, and feedback results related to the current digital humanities task, and serves as an intermediate artifact for subsequent code generation, method invocation, and skill updates. skill.md can be implemented using Markdown, YAML, JSON, key-value pairs, or other structured text formats. In a preferred embodiment, Markdown is used as the structured description file format. The fields of skill.md include, in one embodiment, at least one or more of the following fields: task identifier; task category; research object; time range; spatial range; evidence requirements; method constraint; candidate method; code template; input field requirements; output field requirements; dependency environment requirements; testing rule field; execution feedback field; error callback field; authenticity score field; skill update time field; and skill version field. In one embodiment, this application includes the following modules: a task input module; a skill.md generation and invocation module; a code generation module; an execution result acquisition module; a triple verification module; an update gating module; a skill.md update module; and an alternative skill switching module.

[0082] In this embodiment, the method includes the following steps: S1' Obtains digital humanities research tasks and candidate corpora.

[0083] S2' generates a new skill.md based on the research task or calls an existing skill.md that matches the current task, and generates analysis code to be executed according to the task rules, method constraints, code templates and execution requirements recorded in the skill.md. After executing the analysis code, it obtains analysis results, running logs, test results, dependency check results and feedback callback results.

[0084] S3' calculates the academic truth score based on the analysis results and evidence mapping relationship.

[0085] S4' calculates the true method score based on the matching relationship between the research task, the method constraints in skill.md, and the actual analysis method used.

[0086] S5' calculates the true project score based on the running logs, test results, dependency check results, and stability data from multiple executions.

[0087] S6' calculates the total authenticity score based on the academic authenticity score, methodological authenticity score, and engineering authenticity score.

[0088] S7' determines whether to allow updating skill.md based on the total authenticity score and the sub-authenticity scores.

[0089] S8' determines, based on the total authenticity score and the sub-authenticity scores, whether to retain the method configuration corresponding to the current skill.md, or switch to an alternative skill.md or alternative method to regenerate the code.

[0090] In a preferred embodiment, step S2' further includes: S21' parses the research task and extracts task features, which include: research object; task category; time range; spatial range; corpus type; and output target type.

[0091]

[0092] in: Indicates the first The research task input; Indicates the research subject; Indicates the task category; Indicates a time range; Indicates spatial range; Indicates the type of corpus; Indicates the output target type.

[0093] S22' generates a new skill.md file based on the task characteristics or retrieves skill content matching the current task from an existing skill.md library. In one implementation, the existing skill.md library is assumed to be:

[0094] in: This represents the set of candidate `skill.md` files; Indicates the first The `skill.md` file. Current task and the... The matching degree of each `skill.md` can be expressed as:

[0095] in: This indicates the degree of match between `skill.md` and the current task; Indicates the task matching score; Representation method constraint matching score; This indicates the historical validity score of the `skill.md` file; This represents the corresponding weighting coefficient.

[0096] Preferably, the `skill.md` file with the highest matching degree is selected as the invocation target:

[0097] in: This indicates the `skill.md` file that the current task will ultimately call.

[0098] If no existing `skill.md` meets the preset matching threshold, a new `skill.md` is generated, which can be represented as: =

[0099] in: This refers to the newly generated `skill.md`; This represents the function generated by `skill.md`; Indicates the characteristics of the current candidate evidence; This represents a set of predefined rules or a set of research paradigm constraints.

[0100] S23' inputs the task rules, method constraints, code templates, input field requirements, and dependency requirements from skill.md into the code generation module to generate the analysis code to be executed corresponding to the current digital humanities task.

[0101] In one implementation, the `skill.md` can be represented as:

[0102] in: Indicates task rules; Representation method constraints; Indicates a code template; Indicates the input field requirements; Indicates dependency requirements; This indicates historical feedback information.

[0103] The analysis code to be executed can be represented as: =

[0104] in: This indicates the analysis code to be executed generated by the current task; This represents the code generation function; Indicates the current research task; This represents the currently invoked or generated `skill.md` file; This indicates the features of candidate evidence or corpus.

[0105] Furthermore, it can also be written as:

[0106] in: Represents the task vector; This represents the structured vector representation of `skill.md`. This represents the feature vector of evidence.

[0107] S24 executes the analysis code and obtains: analysis results; runtime logs; test results; dependency check results; and feedback callback results.

[0108] In one implementation, the code execution process can be represented as follows: , , ,

[0109] in: Indicate the analysis results; This represents the runtime log; Indicates the test results; This indicates a dependency on the check results; This indicates the function to execute the code.

[0110] The feedback callback result can be further represented as:

[0111] in: This indicates the feedback callback result; This indicates the function that generates the feedback callback.

[0112] S25' inputs the analysis results, runtime logs, test results, dependency check results, and feedback callback results into the triple verification module to determine whether to update skill.md subsequently.

[0113] In one implementation, the input to the triple verification module can be uniformly represented as: ={ , , , , , , } in: This represents the input set of the triple verification module; Indicate the analysis results; This represents the runtime log; Indicates the test results; This indicates a dependency on the check results; This indicates the feedback callback result; This refers to the current `skill.md` file; Indicates the current task.

[0114] Then the following can be calculated separately: =

[0115] =

[0116] =

[0117] in: Indicates the true academic score; The method of representation is the true score; The actual score of the project corresponds to the evidence matching verification result data, method adaptation verification result data, and code execution verification result data in Example 1, respectively. , , These represent the corresponding verification functions.

[0118] The total authenticity score is expressed as:

[0119] Therefore, the update control of `skill.md` can be represented as:

[0120] And decide whether to update based on the gating results:

[0121] Triple verification: Academic authenticity is used to determine whether the analysis results are supported by evidence and have traceable sources. In one implementation, the academic authenticity score can be expressed as:

[0122] in, Academic true score Evidence support level Source credibility : The traceability of the conclusions; : Corresponding weighting coefficient. Used to determine whether the results of digital humanities analysis have sufficient evidence, reliable source mapping, and traceability of conclusions. It is the core academic gate control basis for updating `skill.md`.

[0123] The method is actually used to determine whether the currently used analytical method conforms to the research paradigm and methodological constraints of the current digital humanities task.

[0124] In one implementation, the true score of the method can be expressed as:

[0125] in, The method's true comprehensive score; : The matching score between the method and the current task category; The score for the degree of conformity between the method and the preset constraint rules in skill.md; These are the weight coefficients for task matching degree and rule compliance degree, respectively, satisfying the weight constraints: .

[0126] Engineering accuracy is used to determine whether the analysis code is executable, testable, and reproducible. In one implementation, the engineering accuracy score can be expressed as:

[0127] in: This indicates the actual score of the project; Indicates the success rate of execution; Indicates the test pass rate; Indicates the validity of the dependency interface; Indicates stability during repeated runs; For the corresponding weights.

[0128] Overall authenticity and skill.md update gate: In one implementation, the total authenticity score is represented as:

[0129] Where: (T) represents the total authenticity score; These are weight parameters; These represent scores for academic authenticity, methodological authenticity, and engineering authenticity, respectively.

[0130] The gating function in skill.md is represented as follows:

[0131] in: Indicates whether skill.md is allowed to be updated; Indicates the overall truth threshold; These represent the thresholds for academic truth, methodological truth, and engineering truth, respectively. When... When this happens, the current code generation rules, execution feedback, and callback results can be written to skill.md; when... At that time, the current skill.md will not be updated.

[0132] In one implementation, an update to skill.md can be represented as:

[0133] in: Indicates the current state of skill.md; This indicates the result of the current feedback callback. This refers to the updated skill.md.

[0134] To avoid retaining low-quality skills in the long term, in one implementation, a control function can also be defined to call the skill.md file:

[0135] In other words, a skill.md will only be used preferentially in subsequent tasks if the skill it corresponds to has historically met the requirements in both academic and methodological truth.

[0136] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for managing the entire lifecycle of skill files for digital humanities code generation, implemented by a processor executing program instructions stored in memory, characterized in that: Includes the following steps: Obtain digital humanities research tasks and corresponding candidate corpora; Based on the characteristics of the research task, a matching skill file is retrieved from the skill file library, or a new skill file is generated; the skill file is a structured data file that contains task rules, method constraints, and code templates for constraining code generation. Based on the research task and the skill file, generate analysis code and execute the analysis code to obtain feedback data containing analysis results and execution logs; The following data processing procedure is performed by a computer to generate assessment data for controlling the updates of the skill files: Based on the matching results of the analysis with the evidence in the candidate corpus set, evidence matching verification result data is generated; Based on the consistency between the actual analysis method recorded in the execution log and the method constraints in the skill file, method adaptation verification result data is generated; Based on the execution success status and test results recorded in the execution log, generate code execution verification result data; If the evidence matching verification result data, method adaptation verification result data, and code execution verification result data all reach their respective preset threshold values, then updating the skill file based on the feedback data is allowed; otherwise, updating is prohibited.

2. The method for full lifecycle management of skill files for digital humanities code generation according to claim 1, characterized in that, The process of generating evidence matching and verification result data includes the following steps: The analysis results are parsed into structured conclusion objects containing the methods used and source information; From the candidate corpus set, retrieve candidate evidence that matches the structured conclusion object; For each candidate piece of evidence, its support direction is determined based on its consistency with the structured conclusion object in the dimensions of object, time, and space. The support direction includes support or opposition. Based on the weights of all evidence deemed to support a particular direction, generate evidence support data. Based on the source type of the evidence cited by the structured conclusion object, a preset source classification table is queried to generate source credibility data; Based on the proportion of structured conclusion objects that have verifiable traceability structures, conclusion traceability data is generated. Based on the evidence support data, source credibility data, and conclusion traceability data, the evidence matching and verification result data is generated.

3. The method for full lifecycle management of skill files for digital humanities code generation according to claim 1, characterized in that, The generation method adapts to the verification result data and includes the following steps: Determine the task category of the research task and the analysis method actually invoked by the analysis code; Query the preset mapping table between task categories and allowed analysis method sets, determine whether the analysis method actually called exists in the allowed analysis method set corresponding to the current task category, and generate task matching data accordingly; Check whether the analysis method actually invoked meets the preset method implementation rules recorded in the skill file, and generate rule compliance data accordingly; Based on the task matching degree data and rule compliance degree data, the method adaptation verification result data is generated.

4. The method for full lifecycle management of skill files for digital humanities code generation according to claim 1, characterized in that, The process of generating code execution verification result data includes the following steps: Based on the code execution status in the execution log, determine whether the execution was successful or failed, and generate execution success data; Based on the preset test rule set in the skill file, verify whether the analysis results meet the expected field output requirements, and use the proportion of rules that pass as the test pass rate data; Check whether the external libraries or interfaces that the analysis code depends on are valid, and generate dependency validity data; Based on the consistency of the output of the analysis code when it is run multiple times under the same conditions, runtime stability data is generated. Based on the execution success rate data, test pass rate data, dependency validity data, and runtime stability data, the code execution verification result data is generated.

5. The method for full lifecycle management of skill files for digital humanities code generation according to claim 2, characterized in that, The process of generating evidence support data includes the following steps: Obtain all evidence that is determined to support the direction, and form a set of supporting evidence; The evidence in the supporting evidence set is compared pairwise to determine whether there are contradictory pairs between the evidence; the contradictory pair between the evidence is defined as: the difference between the recorded values ​​of the two pieces of evidence on the same attribute dimension involved in the structured conclusion object exceeds a preset tolerance threshold; the attribute dimension includes time attribute, spatial attribute, quantity attribute, person attribute and event type attribute; If there are contradictory pairs of evidence, a contradiction marker signal is generated. The contradiction marker signal is used to trigger a downgrade or rejection of the evidence support data in subsequent gating decisions.

6. The method for full lifecycle management of skill files for digital humanities code generation according to claim 5, characterized in that, The contradiction marker signal triggers a downgrade or rejection of the evidence support data in subsequent gating decisions, including the following steps: When there are contradictory pairs of evidence, extract the contradictory attribute dimensions and the source types of the evidence from both sides of the contradiction from each contradictory pair to generate a contradictory structure description object; The object describing the contradiction structure is compared with the task category of the current research task to determine whether the contradiction falls within the scope of the contradiction associated with the task category, i.e., the triggering range of the discovery rule. If so, the object describing the contradictory structure will be added to the feedback data as a new discovery in this round of analysis, and the new discovery will be written to the analysis log field of the skill file when updates are allowed. If not, the evidence support data will be reduced according to the preset reduction rules.

7. The method for full lifecycle management of skill files for digital humanities code generation according to claim 6, characterized in that, The process of determining whether a contradiction falls within the scope of the contradiction discovery rule associated with the task category includes the following steps: Read the task category of the current research task; Query the preset task category-conversion attribute mapping table to obtain a list of conversion attribute dimensions corresponding to the current task category; the task category-conversion attribute mapping table is a data structure in which each task category is associated with at least one attribute dimension, indicating that when a conflict occurs in these attribute dimensions, the conflict should be converted into a discovery rather than a deduction item; Read the contradictory attribute dimensions from the contradictory structure description object; If the contradictory attribute dimension exists in the list of transformation attribute dimensions, then the contradiction is determined to fall within the trigger range; otherwise, it is determined not to fall within the range.

8. The method for full lifecycle management of skill files for digital humanities code generation according to claim 7, characterized in that, The task category-conversion attribute mapping table is constructed through the following steps: Retrieve all historical records of successfully updated skill files to form a set of historical successful tasks; each task record includes the task category, records of contradictory evidence during execution, and whether the task ultimately triggered a new discovery. For each task category, the distribution of attribute dimensions of contradictory evidence pairs that have appeared in all historical successful tasks under that category is statistically analyzed. For each attribute dimension, calculate its transformation confidence, which is: under this task category, when the contradiction between evidences involves this attribute dimension, the ratio of the number of tasks in which the contradiction is finally transformed into a new discovery to the number of tasks in which the contradiction is finally deducted points according to the preset downgrade rule; Attribute dimensions whose conversion confidence exceeds the preset conversion threshold are added to the conversion attribute dimension list corresponding to the task category.

9. The method for full lifecycle management of skill files for digital humanities code generation according to claim 4, characterized in that, When any of the evidence matching verification result data, method adaptation verification result data, or code execution verification result data fails to reach its preset threshold, the following steps are performed: Retain the currently used skill file and prohibit writing the feedback data from this round into the skill file; Determine the failure type based on the data type of the verification result that did not meet the requirements; When the failure type is that the method adaptation verification result data does not meet the standard, an alternative analysis method is selected from the method constraints recorded in the skill file, or an alternative skill file that matches the task category of the current task and whose historical method adaptation verification result data meets the standard is retrieved from the skill file library. The analysis code is then regenerated and executed based on the alternative analysis method or the alternative skill file.

10. The method for full lifecycle management of skill files for digital humanities code generation according to claim 9, characterized in that, After determining the failure type based on the data type of the unqualified verification result, the process also includes the following steps: When the failure type is that the evidence matching verification result data does not meet the standard, supplement the evidence in the candidate corpus set, or increase the traceability requirements of the structured conclusion object and regenerate the analysis code and execute it. When the failure type is that the code execution verification result data does not meet the standard, the analysis code is regenerated and executed after repairing the dependency environment or supplementing the test rules based on the dependency validity data or the test pass rate data.

Images