Full-automatic code programming method and system based on large model

Abstract

The invention relates to a full-automatic code programming method and system based on a large model. The full-automatic code programming method comprises the steps that 1, multi-modal requirements are collected, analyzed and expressed in a standardized mode; 2, automatically arranging a development environment; step 3, code candidate generation and quality inspection; 4, compiling / constructing and automatically executing; 5, performing structured evaluation and success judgment; 6, closed-loop error correction and self-optimization control are carried out; and 7, safety and compliance control. The method supports fusion analysis of texts, voices, images and videos, and automatically extracts program specifications and acceptance criteria. According to the method, automatic generation, compiling, execution, evaluation and error correction are achieved, and manual log interpretation and prompt word rewriting are not needed.

Description

TECHNICAL FIELD

[0001] The present application relates to a large model-based full-automatic code programming method and system, belonging to the field of software engineering and artificial intelligence. BACKGROUND

[0002] To reduce the development threshold, automatic code programming has formed multiple technical routes: domain-specific languages or model-driven engineering are customized for specific business scenarios, such as process orchestration, report, interface protocol or state machine description, which focuses on "modeling first, generating later", generating function code through preset structure or model, engineering landing controllable but poor adaptability to open demand and dynamic environment. Secondly, constraint-based program synthesis and search / evolutionary software engineering can solve and optimize in formalization or search space, with theoretical or coverage advantages, but are prone to search explosion and difficult to integrate with real engineering. Thirdly, natural language to code (NL2Code) and retrieval augmentation (RAG) based on deep learning can generate code through natural language and improve API usage correctness, but lack understanding of long-specification requirements and lack of automatic verification and error correction ability in real environment, making it difficult to apply; automatic program repair (APR) focuses on post-failure patch generation, making it difficult to implement complete requirements from scratch. Finally, large model interactive assistants and tool-enhanced agents form a "generate, execute, regenerate" closed loop, but feedback is mostly unstructured logs, the environment is not reproducible, and there is a lack of unified acceptance criteria for success determination. Exploration of multi-modal to code can extract intent from voice / screenshot / video, but it has not been deeply coupled with construction, testing and closed-loop error correction. Overall, existing solutions generally lack an end-to-end closed loop from multi-modal requirements, standardized representation, reproducible environment, automatic testing and metrics, structured backwash, and self-iterative optimization, making it difficult to produce executable programs that meet engineering quality and compliance requirements.

[0003] Existing code generation relies heavily on single-round mapping of natural language to code (NL2Code), which has the following problems: (1) Lack of end-to-end generation-compile-execute-evaluate-error correction closed loop, requiring manual reading of error information and rewriting of prompt words; (2) Lack of automatic arrangement and dependency resolution for target runtime environment, prone to failure due to SDK (Software Development Kit) version, permissions or dependency conflicts; (3) Success determination criteria are ambiguous, lacking automated testing and metrics evaluation mechanisms; (4) Error feedback is mostly unstructured long logs, which is not conducive to effective absorption and iteration of large models.

[0004] Therefore, there is an urgent need for a full-automatic programming method and system that supports multi-modal requirement analysis, automatically generates and executes code, and continuously optimizes error correction based on structured feedback. SUMMARY

[0005] To address the deficiencies of the prior art, the present application provides a full-automatic code programming method based on large models (Automatic Code Programming Driven by Large Models, ACPLM), which realizes full-process automation from multi-modal requirements to executable programs: automatic requirement analysis, automatic selection of language and tool chain, code generation, automatic compilation / deployment, automatic execution and evaluation, structured results back to large models for error correction, until the requirements are met or the termination condition is reached.

[0006] The present application also provides a full-automatic code programming system based on large models.

[0007] Terminology explanation: 1. Automatic Speech Recognition (ASR): the process of automatically converting acoustic signals (microphone-sampled speech waveforms) into readable text, usually involving acoustic modeling, language modeling, and decoding.

[0008] 2. Optical Character Recognition (OCR): a technology that detects and recognizes text from image / video frames, including text detection, layout analysis, and character / line recognition, and optionally extends to table structuring and formula recognition.

[0009] 3. Object or flow recognition: locate and classify target objects in images / videos, identify interface elements or chart types, convert visual objects into executable constraints related to requirements, and automatically transcribe user demonstration videos or GUI operations into executable function flows, and then into program use cases and acceptance items.

[0010] 4. Semantic summary: compress long-term or multi-modal input (text / speech / image / video) into concise expressions that retain key information, which can be extractive (extract key sentences / keywords) or generative (abstract summary / multi-modal subtitles and descriptions).

[0011] The technical solution of the present application is: A full-automatic code programming method based on large models, comprising: Step 1: Multi-modal requirement acquisition, analysis, and standardized representation; Step 2: Development environment automatic arrangement; Step 3: Code candidate generation and quality inspection; Step 4: Compile / build and automatically execute; Step 5: Structured evaluation and success determination; Step 6: Closed-loop error correction and self-optimization control; Step 7: Security and compliance control.

[0012] According to the present application, the specific implementation process of step 1 preferably includes: Step 1.1: Receive input; receive at least one of text, voice, image, or video; Step 1.2: Parsing and unified representation: perform automatic speech recognition (ASR) on voice, perform optical character recognition (OCR), object or flow recognition, and semantic summary on images or videos to obtain a unified text description; Step 1.3: Program specification graph construction: map the unified text description to a program specification graph (PSG) based on a large model and a domain vocabulary.

[0013] Further preferably, the program specification graph (PSG) is a visual intermediate representation of program specification, including a directed graph of four types of specific nodes and two types of relationship edges; wherein the node set includes a function node , a data pattern node , a constraint node , and a test intent node , i.e. ; the function node specifies the specific operation or core goal that the program needs to achieve, the data pattern node defines the structure, type, or format specification of the input / output data, the constraint node specifies the rules and boundary conditions that the program needs to comply with during execution, and the test intent node specifies the goal of verifying the specification; the edge set includes a dependency relationship edge and a constraint relationship edge , i.e. , both the dependency relationship edge and the constraint relationship edge are directed connections; the dependency relationship edge indicates the existence, readiness, or execution of the starting node, which is a necessary prerequisite for the ending node, and the constraint relationship edge indicates the rules of the starting node, which directly limits the behavior or result of the ending node.

[0014] According to the present application, the specific implementation process of step 2 preferably includes: Step 2.1: Automatically determine the target language, runtime required SDK / library version, and operating system image based on the program specification graph (PSG); implement environment orchestration through container technology to encapsulate the language, runtime, dependencies, and configurations into independent units to meet isolation requirements; Step 2.2: Automatically pull dependencies, prepare sample data, and simulate external APIs in the isolated sandbox / container; ​Step 2.3: Hash all the dependency version information and environment configuration parameters to generate an environment snapshot that uniquely identifies the current environment state, including dependency lock files, container fingerprints, and configuration hashes. The dependency lock file is an immutable manifest that determines all direct and transitive dependencies and their versions and sources after one-time parsing. The container fingerprint is used to uniquely identify the base image and its layers that carry the running environment. Specifically, define the running environment E = (L, R, D, C), where E represents the final isolated and reproducible running environment, L is the target programming language, R is the runtime environment corresponding to the target programming language, D is the set of dependencies required for program execution, and C is the environment configuration parameter. At the same time, define the environment snapshot to save various configurations of the running environment; where Hash() represents the hash function, Dv is the set of all dependency version information, Cfg is the set of specific values of the environment configuration parameters, and ∪ is the set union operation.

[0015] According to the preferred embodiment of the present application, the specific implementation process of step 3 includes: Step 3.1: Call the large language model LLM to translate the program specification graph PSG into a code framework and implementation, and generate multiple code candidates using diversified decoding. Step 3.2: Perform static analysis, including syntax, type, and complexity, and sort the code candidates based on heuristic scoring. The syntax, type, and complexity are reduced to feature vectors and weighted to form heuristic scoring , as shown below: ; Wherein, is the th positive quality indicator, is the th importance weight, is the severity of the th defect, is the penalty weight of the th item.

[0016] According to the preferred embodiment of the present application, the specific implementation process of step 4 includes: Step 4.1: Automatically compile or build each code candidate and capture compilation errors and warnings. Step 4.2: Automatically generate test artifacts based on the program specification graph PSG; including unit tests, property tests, boundary / random data, transformation rules, performance and resource constraint scripts. Step 4.3: Execute the test set and end-to-end acceptance use cases in a sandbox, record the run logs, functional correctness, return values, standard input / output, coverage, performance, resource occupation, and running safety.

[0017] According to the present application, the specific implementation process of step 5 preferably includes: Step 5.1: The running output includes: functional correctness, error category, minimum reproduction example, coverage gap, stack trace summary, abstract syntax tree positioning, and unsatisfied acceptance criteria, which are summarized into a log refiner for structured feedback; Step 5.2: Determine whether it is successful based on the acceptance criteria and threshold of PSG; if successful, output the product and solidify the environment snapshot.

[0018] According to the present application, the specific implementation process of step 6 preferably includes: Step 6.1: Closed-loop error correction: if the acceptance criteria are not met, convert the compilation / run logs, stack traces, and abstract syntax tree differences into structured feedback and history attempt summaries embedded in prompt words, and call the LLM again to generate patches and reconstruct new candidates for the solution; Step 6.2: Search strategy: use priority search or beam search and majority voting strategy to optimize within a limited number of iterations.

[0019] Step 6.3: Stopping rule: execute steps 6.1 to 6.2 in a loop until the success criterion is met, the acceptance criteria are met, or the upper limit of iterations is reached, i.e., terminate.

[0020] Further preferably, beam search and majority voting strategy are used to optimize within a limited number of iterations; including: Beam search sets a beam width K , the set of candidate solutions collected in each iteration is , the set of automatic verifiers is , each verifier v gives a score s to the candidate ; hard assertions are preferred , the continuous indicators are normalized to by monotonic mapping; Each verifier is assigned a trust weight , and satisfies ; the iterative process only focuses on the top- K candidate solutions to control the search size, combined with the preset maximum number of iterations T to form a limited constraint, and finally the support degree of all iteration candidate solutions is counted by the majority voting strategy Vote(s) : ; Where, the set of candidate solutions collected in all iterations is ; Subsequently, the first T iteration candidate solution set The solution with the highest support in the set is determined as the optimal solution Wherein, Argmax The index position of the maximum Vote(s) is selected; The memory cache stores error signatures and repair prompt templates in a targeted manner. Before generating a candidate solution or performing an operation each time, the cache is queried first to directly filter recorded error items, thereby avoiding repeated mistakes from the source.

[0021] According to the present application, the specific implementation process of step 7 includes: Step 7.1: Perform compliance checks on external dependencies and licenses, including API white lists, network / file system minimum permissions, sensitive information desensitization, and key agents; Step 7.2: Perform license and third-party compliance checks; Step 7.3: If non-compliant, block the output and give alternative implementation suggestions.

[0022] A computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the steps of the above-mentioned full-automatic code programming method based on a large model when executing the computer program.

[0023] A computer readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the steps of the above-mentioned full-automatic code programming method based on a large model.

[0024] A full-automatic code programming system based on a large model includes: A multi-modal analysis module configured to collect, analyze, and normalize multi-modal requirements; An environment arrangement module configured to automatically arrange a development environment; A code generation module configured to generate code candidates and perform quality inspection; A build and execution module configured to compile / build and automatically execute; An evaluation and determination module configured to perform structured evaluation and success determination; A closed-loop error correction and self-optimization control module configured to convert logs, stack traces, and AST differences into structured feedback; An optimization control module configured to perform closed-loop error correction and self-optimization control; A security and compliance module configured to perform security and compliance control.

[0025] ​​Compared with the prior art, the present application has at least the following advantages: 1. Full modal to code: support text, voice, image, video fusion analysis, automatic extraction of program specification and acceptance criteria; 2. End-to-end closed loop: automatic generation, compilation, execution, evaluation and error correction without manual intervention in log interpretation and prompt word rewriting; 3. Reproducible and portable: environment automatic arrangement and snapshot solidification to ensure consistent results across machines; 4. Strong robust error correction: converting compilation / running / semantic / performance problems into structured feedback for LLM to efficiently utilize, combined with beam search and majority voting to improve one-time success rate; 5. Quality and safety can be measured: coverage, performance and compliance checks are included in success determination, and output quality is controllable; 6. Scalable: incremental learning and error signature memory of knowledge base, the stronger the better. BRIEF DESCRIPTION OF DRAWINGS

[0026] Figure 1 A flow chart of a full-automatic code programming method based on a large model; Figure 2 A specific implementation flow chart of a full-automatic code programming method based on a large model; Figure 3 A schematic diagram of the effect of different modalities (success rate SR@10m / median TTAS). DETAILED DESCRIPTION

[0027] The present application will be further limited by the description of the specification, drawings and examples, but not limited thereto.

[0028] Example 1 A full-automatic code programming method based on a large model, as shown in Figure 1 , comprising: Step 1: multi-modal requirement acquisition, analysis and standardized representation; Step 2: automatic arrangement of development environment; Step 3: code candidate generation and quality inspection; Step 4: compilation / building and automatic execution; Step 5: structured evaluation and success determination; Step 6: closed-loop error correction and self-optimization control; Step 7: safety and compliance control.

[0029] Example 2 The full-automatic code programming method based on a large model according to example 1, the difference lies in: As shown in Figure 2 , the specific implementation process of step 1 comprises: Step 1.1: Receive input; receive at least one of text, speech, image, or video; Step 1.2: Parse and unify representation; perform automatic speech recognition (ASR) on speech, optical character recognition (OCR), object or flow recognition, and semantic summarization on image or video to obtain unified textual description; Step 1.3: Program specification graph construction; map unified textual description to program specification graph (PSG) based on large model and domain glossary. Specifically including:

[0030] First, normalize unified textual description (sentence segmentation, anaphora resolution, unit and time / path standardization); Subsequently, extract requirements using an intent, entity, and constraint three-layer semantic parsing framework, including intent layer extracting target functions and core operation verbs; entity layer identifying input / output data, target objects, external application programming interfaces (APIs) or files, and running environment elements; constraint layer analyzing boundary conditions, performance, security, compliance indicators, and interaction restrictions. Aligning parsing results with domain glossary or ontology to complete synonym normalization and ambiguity resolution (e.g., mapping "chart" to visualization object, and "batch processing" to concurrency or throughput threshold). On this basis, generate and fill in nodes according to predefined PSG patterns: function nodes, data, interface nodes, constraint nodes, test intent nodes, and environment dependency nodes, then generate edges according to semantic relationships and label relationship types. Then automatically complete acceptance criteria and default parameters according to explicit statements and empirical rules to form a structured PSG with attributes (including I / O types, parameter values, thresholds, fault tolerance, and rollback strategies), and attach confidence levels and clarification prompts to uncertain items.

[0031] Finally, the PSG serves as a direct and computable input for subsequent language, tool chain selection, code generation, test generation, and closed-loop error correction.

[0032] Program specification graph (PSG) is a visual intermediate representation of program specification, including a directed graph of four types of specific nodes and two types of relationship edges; among them, the node set includes function nodes , data pattern nodes , constraint nodes , and test intent nodes , namely Functional nodes clearly define the specific operations or core objectives that the program needs to achieve; data pattern nodes define the structure, type, or format specifications of input / output data; constraint nodes specify the rules and boundary conditions that the program must follow to run, execute functions, or use data; test intent nodes clearly define the goals to verify the achievement of the specifications; edge sets Including dependency edges With constraint relationship edge ,Right now Dependency edge With constraint relationship edge All are directed connections; dependency edges represent the existence, readiness, or execution of the starting node, which are necessary prerequisites for the ending node, while constraint edges represent the rules of the starting node, which directly restrict the behavior or result of the ending node.

[0033] The specific implementation process of step 2 includes: Step 2.1: Based on the program specification diagram PSG, automatically determine the required SDK / library versions and operating system images for the target language and runtime (such as Python / Java / JS); implement environment orchestration through container technology (such as Docker, Kubernetes), encapsulating the language, runtime, dependencies, and configuration into independent units to meet isolation requirements; specifically, environment orchestration is automatically completed by a closed-loop process of decision-making, building, and running: First, the system extracts functional objectives, peripheral platform constraints (such as GPU, target operating system, CPU architecture), performance and security thresholds, and license restrictions from PSG, and combines them with the built-in environment configuration (language × runtime × SDK version × base image × hardware availability) to form a constraint-solving problem; then, it performs a search with priority given to satisfiability, second-best performance, and weighted by ecosystem availability and compliance, to obtain the target language and runtime (e.g., Python 3.11 + CUDA 12.2, or Java 21 + Temurin JRE) and the corresponding operating system base image.

[0034] During the build phase, the system generates container blueprints in real time according to the solution: selects a streamlined base image, creates a non-root user, minimizes the system package, sets a read-only root file system, mounts a temporary write layer, injects environment variables and configuration files (such as SDK path, certificate, region and time zone) by PSG, precompiles local extension dependencies when necessary, and performs image size reduction and vulnerability scanning after completion. The system outputs the image, lock files and build trace as an environment snapshot.

[0035] During the runtime phase, the scheduler creates a one-time sandbox using Docker (container technology) or Kubernetes (container orchestration architecture). The container entry script is uniformly encapsulated, compiled, tested end-to-end, and acceptance metrics are collected. Test artifacts and logs are returned via volumes or auxiliary containers. If compilation or runtime fails, the system automatically adjusts the blueprint based on structured errors (dependency conflicts, incompatible application interfaces, missing libraries, insufficient permissions, etc.) (e.g., switching minor versions of the base image, replacing application interfaces, adding system packages or permission declarations) and triggers a rapid rebuild until a stable environment image that meets the PSG acceptance criteria is obtained. This encapsulates language, runtime, dependencies, and configuration into reproducible, traceable, and strongly isolated independent units.

[0036] Step 2.2: Automatically pull dependencies, prepare sample data, and simulate external APIs in an isolated sandbox / container; Specifically, upon receiving the PSG, the environment orchestrator first selects the minimum available base image, pulls and verifies the signature and software bill of materials from a trusted image repository, then creates a fully isolated namespace and controls quotas, enables a read-only root file system, opens a few writable mount points, configures a minimum set of capabilities, and distinguishes between build-time and runtime containers to reduce supply chain risks and narrow the attack surface. The dependency resolver determines the exact version based on the PSG or existing lock files, prioritizing the use of enterprise private proxy repositories and local read-only caches to improve reproducibility and pull speed. After installation, a dependency list and hash snapshot are generated, and vulnerability and license scans are performed, blocking non-compliance. Finally, an environment snapshot is generated for subsequent reproduction and rollback.

[0037] Secondly, sample data and test artifacts are automatically generated by the test generator. Based on the input patterns and acceptance criteria in the PSG, synthetic samples are generated, covering boundary, extreme, and random distributions. Units and end-to-end test scripts and resource quotas (timeout, CPU / memory limits) are generated simultaneously. Finally, external APIs are virtualized as services within the sandbox to achieve testability and controllability. Contract tests are prioritized based on existing open-source standards; if no contract exists, simulated endpoints are built using recording, playback, or rule-driven methods, injecting latency and error codes according to scenarios. Then, the target domain name is transparently mapped to a stub address via the container's DNS, ensuring smooth operation in the simulated environment without code modification.

[0038] Step 2.3: Perform hash operations on the specific version information and environment configuration parameters of all dependencies to generate an environment snapshot that uniquely identifies the current environment state. This includes the dependency lock file, container fingerprint, and configuration hash. The dependency lock file is an immutable list that is parsed once and used to determine the versions and sources of all direct and transitive dependencies. The container fingerprint is used to uniquely identify the base image and its layer that hosts the program. A stable fingerprint can be obtained by using hierarchical digest aggregation. Any change in any layer or package will cause a change in the fingerprint, thereby reflecting changes in the dependency environment in a timely manner to ensure the reproducibility of the program.

[0039] Specifically, the runtime environment is defined as E = (L, R, D, C), where E represents the final isolated and reproducible runtime environment, L is the target programming language (such as Python, Java, C++, etc.), R is the runtime environment corresponding to the target programming language (such as Python interpreter, JRE), D is the set of dependencies required for program execution (such as third-party libraries, tool components), and C is the environment configuration parameters (such as port, resource limits, path settings). At the same time, define environment snapshots This is used to store various configurations of the runtime environment; where Hash() represents a hash function (such as SHA-256), Dv is a collection of specific version information of all dependencies (such as requests 2.31.0, Spring Boot 3.2.0), Cfg is a collection of specific values ​​for environment configuration parameters, and ∪ is the union of sets. It is used to integrate dependency versions and configuration information into a unified input, ensuring that the hash result uniquely corresponds to the environment state, thereby achieving accurate environment reproduction.

[0040] The specific implementation process of step 3 includes: Step 3.1: Call the Large Language Model (LLM) to translate the Program Specification Graph (PSG) into a code framework and implementation, and use diverse decoding methods (such as temperature / Top-k / Top-p) to generate multiple code candidates; In implementation, the system first maps the PSG into structured generation instructions and embeds templated prompts to assemble them: the pre-system instructions limit the target language / runtime and security policy, the task paragraphs are expanded with key PSG fields, and the output paragraphs are strictly limited by syntax constraints and stop characters to only return code. Then, the LLM is called to adopt a two-stage generation approach: the first stage produces the project architecture and main file or function signature, and the second stage sequentially fills in the implementation details and test cases. To obtain diverse candidates, the system runs multiple decoding strategies in parallel: grid / step values ​​are taken for temperature, top-k, and top-p (e.g., T∈{0.2,0.5,0.8}, k∈{20,50}, p∈{0.8,0.95}), and different few-sample examples and prompt variations are combined. After generation, each candidate undergoes machine-readable post-processing: parsing into an abstract syntax tree to check syntactic integrity and import dependency consistency, and performing static analysis scoring. The metadata (decoding hyperparameters used, referenced knowledge fragments, and covered PSG entries) is sorted according to the comprehensive score to form multiple code candidates.

[0041] Step 3.2: Perform static analysis, including syntax, type, and complexity, and rank the code candidates based on heuristic scoring; Static analysis is triggered after each code candidate is generated: first, the source code is normalized (formatted, dependency resolution, entry point identification), then lexical / syntactic analysis is performed using the corresponding language front-end to construct an abstract syntax tree and symbol table; based on this, type analysis is performed: compile-time type checking is performed for statically typed languages, and type hints and convention-driven type inference and interface consistency checks are used for dynamic languages ​​to locate unbound symbols, nullability risks, and call signature mismatches; control flow / data flow analysis is performed in parallel to calculate maintainability indicators such as cyclomatic complexity, maximum nesting depth, number of paths, function / file size, and duplication rate; syntax, type, and complexity are reduced to feature vectors and weighted to form a heuristic score. As shown below: ; in, For the first A positive quality indicator, For the first Each importance weight, For the first The severity of the defect, For the first The penalty weights for each item are determined. Candidates are then sorted by score and filtered using a threshold. If necessary, minimum patch suggestions are generated or highly similar / high-risk candidates are directly eliminated to reduce failure costs in subsequent compilation and execution stages and improve the first-pass yield.

[0042] The specific implementation process of step 4 includes: Step 4.1: Automatically compile or build each code candidate, capturing compilation errors and warnings; Step 4.2: Automatically generate test artifacts based on the program specification diagram PSG; including unit tests, attribute tests, boundary / random data, metamorphic rules, performance and resource constraint scripts; Specifically, the system first unifies the functional nodes, data patterns (type, value range, distribution), constraints (correctness, security, performance, resources) and acceptance criteria in the PSG into an intermediate representation of the test plan, and determines the test framework and execution environment accordingly, and generates an executable test blueprint for each functional unit. Subsequently, the blueprint is instantiated into specific use cases and scripts: unit tests automatically construct simulations of inputs, stubs, and external dependencies based on function / interface signatures and examples and preconditions and postconditions provided by PSG; attribute tests translate explicit or derivable invariants in PSG into repeatable attribute assertions and use a controlled random generator to sample large-scale inputs according to type and constraints; boundary / random data derives minimum / maximum, null / missing, extreme length, illegal encoding, and other boundary points from data patterns and value ranges, and then expands them into random clusters using stratified or biased sampling to improve coverage and failure detection probability; transformation rules are derived from equivalent transformations and invariant relations of PSG (such as scaling, rearrangement, noise injection, format transformation), the system first runs the base example, then transforms the input and applies the corresponding invariant judgments or equality relations to the output, so that it can still automatically check for errors when there is no explicit best answer. The performance and resource constraint scripts are automatically generated from the budget thresholds and scenario loads in the PSG: the test driver wraps the code under test in an isolated sandbox, embeds timing and counting probes, memory / handle / thread monitors and I / O statistics, sets container-level quotas (CPU quota, memory limit, network / disk speed), and collects steady-state metrics according to repeated runs and warm-up strategies; the script finally provides a structured report with assertions of whether a violation has occurred, and outputs coverage, minimum reproducible input, and failure details for the closed-loop error correction module to backtrack. The entire process remains reproducible and is automatically linked in the generation, execution, and evaluation stages, forming a complete and scalable test artifact flow from PSG to unit / attribute / boundary-random / variant rules and performance resource scripts.

[0043] Step 4.3: Execute the test suite and end-to-end acceptance test cases in the sandbox, and record the running logs, functional correctness, return values, standard outputs / outputs, coverage, performance, resource usage, and operational safety.

[0044] Specifically, once the code enters the sandbox, it is uniformly started by the execution wrapper. The wrapper attaches probes at the process boundary: intercepting and buffering standard output and standard error streams, recording exit codes and uncaught exceptions; enabling coverage and call tracing (such as statement / branch / function granularity) at the language layer or bytecode layer, while registering high-precision timers and system-level samplers; enabling audit hooks for peripheral and network access, recording domain names, ports, and access directions and comparing them with a whitelist, triggering a violation and immediately interrupting and marking it as a security failure.

[0045] Test execution proceeds in two layers: unit and attribute boundary test cases are first run in batches within the same sandbox session to quickly identify compilation and semantic defects; then, an end-to-end acceptance flow is initiated as needed, replaying multi-step interactions or data pipelines that closely resemble user scenarios, and replacing real dependencies with service virtualization when necessary to ensure controllability. At the end of each test case, assertion results, return values, and key intermediate outputs are compared against acceptance criteria; simultaneously, coverage thresholds, performance, and resource constraints are used as conditions for judgment, and failure is declared if the criteria are not met.

[0046] The specific implementation process of step 5 includes: Step 5.1: Summarize the runtime output, including: functional correctness, error category, minimum reproducibility, coverage gap, stack trace summary, abstract syntax tree location, and unmet acceptance criteria, into a log refiner for structured feedback; Specifically, the log refiner first collects and aligns the compilation, testing, and runtime logs and coverage data on a unified timeline, performing noise reduction, anonymization, and context completion. To obtain the minimum reproducible test case, parameter reduction and replay verification are performed on the first failed test case to obtain the minimum input and steps that can reliably trigger the same error signature. Simultaneously, the system compares the current coverage with the threshold, identifies uncovered functions / branches, and generates a non-compliance list by comparing each acceptance criterion in the PSG. Finally, this information is organized into a structured feedback object, including error type and root cause, minimum reproducible code snippet, stack trace summary, abstract syntax tree location slice, coverage gap, unmet acceptance criteria, and remediation suggestions. This generates a large input model based on the exception type, after secondary anonymization and embedding of a prompt template, driving subsequent automatic repair and retries.

[0047] Step 5.2: Determine whether the process is successful based on the PSG's acceptance criteria and thresholds (e.g., all required assertions pass, coverage, latency, and security). If successful, output artifacts (code, binary, image, etc.) and solidify the environment snapshot.

[0048] Specifically, the system first compiles the acceptance criteria in the PSG into an executable inspection plan, that is, converting functional requirements into assertions and use cases, and converting coverage, latency, resources, and security into quantifiable thresholds. Then, candidate programs are built and run in an isolated sandbox, collecting assertion results, coverage, latency and resource peaks, file access traces, etc. If successful, artifacts (source code / binary / image / report) are output and archived, while an environment snapshot is fixed, including freezing dependencies and versions, and recording the image environment status; if unsuccessful, the evidence is refined into structured feedback (error category, abstract syntax tree location, items not reaching the threshold, and remediation suggestions) and fed back to the model for the next round of verification.

[0049] The specific implementation process of step 6 includes: Step 6.1: Closed-loop error correction: If the acceptance criteria are not met, the differences between the compilation / run log, stack trace and abstract syntax tree are transformed into structured feedback and historical attempt summaries with embedded prompt words, and LLM is called again to generate patches and new candidate refactoring schemes; When automated tests fail, the system first analyzes the compilation / runtime logs and stack traces, extracting the error type, triggering conditions, minimum reproducibility examples, and affected code locations and abstract syntax tree nodes. It then establishes a correspondence between these and unmet acceptance criteria in the PSG (Power-Only Group), forming structured feedback. Simultaneously, it generates a historical attempt summary, recording attempted fixes, failure signatures, and effective changes to avoid repeating the same mistakes. Subsequently, the system embeds this information into the LLM context (including problem statements, environment fingerprints, boundary conditions, etc.) with constraint hints, along with failed test cases / assertions, requiring the LLM to generate several candidate minimum fix patches or refactoring solutions. For each candidate, the system automatically applies the patch, rebuilds, and retests; if the requirements are still not met, it updates the failure signatures and memory cache, and continues iterating using bundle search, majority voting, or early stopping rules. This achieves a closed-loop self-optimization process from error, feedback, fix to verification until all acceptance assertions pass or the iteration limit is reached.

[0050] Step 6.2: Search Strategy: Employ priority search or bundle search combined with majority voting to find the optimal solution within a finite number of iterations. Support memory caching to avoid duplicate errors.

[0051] Specifically, after each round of automatic generation and testing, candidate solutions are scored, and the most promising solution is retained using either heuristic prioritization or bundle search. The system first calculates a priority score for each candidate based on metrics such as functional pass rate, coverage, performance, and security. When using priority search, the candidate with the highest score is always expanded first. Subsequently, when using bundle search, the top-scoring candidate is retained. KThe system iterates through multiple candidates in a finite number of iterations. To improve robustness, the system tests multiple independent candidates generated in the same round or several adjacent rounds and uses majority voting to determine the outcome: convergence is confirmed only when a majority of candidates simultaneously meet the acceptance criteria under independent environment snapshots, thus reducing the risk of misjudgment due to accidental success or environmental fluctuations. Simultaneously, a memory cache is maintained, extracting compilation errors, runtime anomalies, or unmet acceptance items into matchable error patterns. Targeted fixes are automatically injected in subsequent iterations, and candidates triggering known error patterns are either downgraded or directly excluded to avoid repeatedly exploring the same failure paths.

[0052] Step 6.3: Stop rule: Repeat steps 6.1 to 6.2 until a success determination is reached (such as the code improving test accuracy, meeting latency requirements, etc.), the acceptance criteria are met, or the iteration limit is reached, then terminate.

[0053] Optimization within a finite number of iterations is achieved using beam search and majority voting strategies; including: Setting the beam width in beam search K (The number of highest priority candidate solutions retained in each iteration), the set of candidate solutions collected in each iteration is: The set of automatic validators is Each validator v For candidates s Give a score A hard assertion is acceptable. Continuous metrics (such as latency and coverage) are normalized to monotonic values. ; Assign a trusted weight to each validator And satisfy The iterative process focuses only on Top- K A number of candidate solutions are used to control the search size, along with a preset maximum number of iterations. T To create finite constraints (avoiding overcomputation), the support of all iterative candidate solutions is finally calculated using a majority voting strategy. Vote(s) : ; The set of candidate solutions collected through all iterations is: ; Subsequently, the first T The set of candidate solutions after the next iteration The solution with the highest support is determined as the optimal solution. : ; in, Argmax To select the largest Vote(s) The index position; The memory cache stores error signatures (characteristic identifiers of failed operations) and repair prompt templates (templates for solutions that have been verified to be invalid). Before each candidate solution is generated or an operation is executed, the cache is queried to directly filter recorded error items, thus preventing repeated errors from the source.

[0054] The specific implementation process of step 7 includes: Step 7.1: Perform compliance checks on external dependencies and licenses, including API whitelisting, network / file system minimum permissions, sensitive information masking, and key proxying. First, limit available dependencies and callable external interfaces to a pre-approved set, locking versions and hashes. During the build and runtime phases, this is achieved through dependency resolvers and function calls respectively; any unauthorized imports or accesses are blocked and logged. Second, network / file system minimum permissions employ a default denial, on-demand permission strategy: only allow access to specified domains and ports, limiting outbound bandwidth / protocols; the file system operates in a read-only base layer and an isolated temporary writable zone, prohibiting the mounting of sensitive directories and the main directory. Third, sensitive information masking ensures that keys, passwords, tokens, and potentially sensitive personal / business data do not enter the main model context and logs, performing masking in prompts and logs. Finally, key proxying is implemented using logical identifiers and short-term credentials, injecting them into the minimum scope as needed during execution, retaining audit trails, and destroying them upon task completion. The above mechanisms work together to reduce attack surface and supply chain risks on the one hand, and transform unauthorized attempts into structured events that can be consumed by the feedback module on the other, thereby ensuring both security and compliance and not compromising the availability and reproducibility of closed-loop automation.

[0055] Step 7.2: Conduct license and third-party compliance checks; First, analyze the license type and source of each component and compare it with the built-in policy library. Simultaneously verify the availability and source of code snippets introduced by the large model and external resources, and assess whether obligations such as attribution, copyright notice retention, source code disclosure, and patent licensing are triggered.

[0056] Step 7.3: If non-compliance occurs, block the output and provide alternative implementation suggestions. The review results are output in the form of a machine-readable "compliance checklist," providing the required license documents, compliance annotations, and rectification suggestions. If high-risk items are found, the system will block the release and automatically try alternative solutions, such as rewriting code, replacing dependencies, or switching to a compatible version, or returning to the structured prompt-driven model for regeneration, until the preset compliance threshold is reached.

[0057] The evaluation settings for this embodiment are as follows: Task set: text requirements, speech-to-text requirements, image / interface screenshots, short video demonstrations; covering five categories: data processing, script tools, small web interfaces, visualization, and batch file processing.

[0058] Operating environment: Containerized sandbox (8 vCPU / 16GB RAM), with optional Python / Java / JS toolchains; minimum network permissions; dependency locking and environment snapshots enabled.

[0059] Iteration and hyperparameters: Maximum iterations = 6, bundle width = 3, majority voting enabled; Timeout and resource thresholds: 10 minutes per task / 2GB memory.

[0060] Comparison methods: B1 (single-round LLM generation + one-time execution), B2 (automatic execution + unstructured log backfeeding, no PSG and AST level positioning), ACPLM (the present invention's solution: PSG + environment snapshot + structured feedback + bundle search + voting).

[0061] The indicator is defined as follows: SR@10m: Success rate of meeting acceptance criteria within 10 minutes.

[0062] TTAS / 95 (Median / 95th percentile): Time-To-Acceptable-Solution, the time (in minutes) to meet the acceptance criteria.

[0063] FCPR: First-Compile Pass Rate.

[0064] Test pass rate or coverage: percentage of functional assertions that pass / statement coverage (when passing).

[0065] Peak resource: Peak memory usage (GB).

[0066] Reproducibility rate: The percentage of cases where the content can be successfully reproduced with a single replay across different hosts (based on environment snapshots).

[0067] Human intervention rate: The percentage of logs that require manual reading or modification of prompts (ideally 0%).

[0068] The overall results are shown in Table 1: Table 1

[0069] Experimental results show that, under the same time / iteration budget, SR is improved by 27–36 percentage points; the median TTAS is shortened by 11%, and the reproducibility rate increases from 52–64% to 73%, thanks to environmental snapshots and dependency locking; the manual intervention rate is reduced to 7%. Modal performance (success rate SR@10m / median TTAS) is as follows: Figure 3 As shown.

[0070] Experiments show that the proposed method is more significantly improved in multimodal scenarios, and PSG is particularly crucial for extracting acceptance criteria from visual / operational intentions.

[0071] The ablation experiments (removing a component item by item on the ACPLM baseline) are shown in Table 2: Table 2

[0072] The typical final execution result is recorded as follows: 1) CSV → Bar Chart: Language / Environment: Python 3.10 + pandas 2.2 + matplotlib, environment snapshot ID=sha256:… Iteration: 2 rounds (Round 1: Memory overflow → structured feedback prompts "block reading + dtype precision reduction") Final time: 1.9 minutes; peak memory usage: 0.7GB; coverage: 82%; all 12 assertions passed; deliverables: / artifacts / bar.png, requirements-lock.txt, test report.

[0073] 2) Video Operations → Batch Rename Script; Language / Environment: PowerShell; the sandbox only simulates the file system with minimal permissions.

[0074] Iteration: 3 rounds (Insufficient permissions in the first round; incorrect path matching in the second round; passed in the third round) Final time: 3.4 minutes; coverage: 75%; deliverables: rename.ps1 and user manual (automatically generated).

[0075] 3) AST Differential Repair TypeError: Initial error: TypeError: expected str, got bytes (locating AST opening mode inconsistency) Generate a minimal patch (4 lines of changes), passes second round; Final time: 1.2 minutes; coverage: 80%.

[0076] Example 3 A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the fully automated code programming method based on a large model as described in Embodiment 1 or 2.

[0077] Example 4 A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the fully automated code programming method based on a large model as described in Embodiment 1 or 2.

[0078] Example 5 A fully automated code programming system based on a large model, comprising: The multimodal parsing module is configured to: collect, parse, and normalize multimodal requirements. The environment orchestration module is configured as follows: automatic development environment orchestration; The code generation module is configured for: code candidate generation and quality inspection; The build and execution module is configured as: compile / build and auto-execute; The evaluation and judgment module is configured as: structured evaluation and success judgment; The closed-loop error correction and self-optimization control module is configured to convert the differences between logs, stack traces and AST (Abstract Syntax Tree) into structured feedback. The optimized control module is configured as: closed-loop error correction and self-optimization control; The security and compliance module is configured as: security and compliance control.

Claims

1. A large model-based full-automatic code programming method, characterized in that, Comprise: Step 1: Multimodal requirement acquisition, analysis and standardized representation; Step 2: Development environment automatic orchestration; Step 3: Code candidate generation and quality inspection; Step 4: Compilation / building and automatic execution; Step 5: Structured evaluation and success determination; Step 6: Closed-loop error correction and self-optimization control; Step 7: Security and compliance control.

2. The full-automatic code programming method based on a large model according to claim 1, characterized in that, The specific implementation process of step 1 includes: Step 1.1: Receive input; receive at least one of text, voice, image or video; Step 1.2: Analysis and unified representation: automatic speech recognition (ASR) for voice, optical character recognition (OCR), object or process recognition and semantic summary for images or videos, and unified text description; Step 1.3: Program specification graph construction: based on large models and domain word tables, map unified text description to program specification graph (PSG); Further preferably, the program specification graph PSG is a visualized intermediate representation of the program specification, comprising a directed graph of four types of specific nodes and two types of relationship edges; wherein the node set includes a function node , a data pattern node , a constraint node and a test intent node , i.e. ; the function node explicitly defines the specific operation or core target to be implemented by the program, the data pattern node defines the structure, type or format specification of the input / output data, the constraint node specifies the rules and boundary conditions to be obeyed by the program running, function execution or data usage, and the test intent node explicitly defines the target to be verified by the specification; and the edge set includes a dependency edge and a constraint edge , i.e. , both the dependency edge and the constraint edge are directed connections; the dependency edge indicates the existence, readiness or execution of the start node, which is a necessary prerequisite for the end node, and the constraint edge indicates the rule of the start node, which directly limits the behavior or result of the end node.

3. The full-automatic code programming method based on a large model according to claim 1, characterized in that, The specific implementation process of step 2 includes: Step 2.1: Automatically determine target language, runtime required SDK / library version and operating system image based on program specification graph (PSG); realize environment orchestration through container technology, encapsulate language, runtime, dependencies and configuration into independent units to meet isolation requirements; Step 2.2: Automatically pull dependencies, prepare sample data and simulate external APIs in isolated sandbox / container; Step 2.3: Hash operation on specific version information and environment configuration parameters of all dependencies to generate environment snapshot with unique identifier of current environment state, including dependency lock file, container fingerprint and configuration hash, wherein the dependency lock file is a one-time parsed immutable manifest used to determine the version and source of all direct and transitive dependencies; the container fingerprint is used to uniquely identify the base image and its level that carries the running; Specifically, define the running environment E = (L, R, D, C), where E represents the final built isolated reproducible running environment, L is the target programming language, R is the runtime environment corresponding to the target programming language, D is the set of dependencies required for program running, and C is the environment configuration parameter; Meanwhile, define the environment snapshot , which is used to save various configurations of the running environment; wherein Hash() represents a hash function, Dv is a set of specific version information of all dependencies, Cfg is a set of specific values of environment configuration parameters, and ∪ is a set union operation.

4. The full-automatic code programming method based on a large model according to claim 1, characterized in that, The specific implementation process of step 3 includes: Step 3.1: Call large language model (LLM) to translate program specification graph (PSG) into code framework and implementation, and generate multiple code candidates using diversified decoding; Step 3.2: Perform static analysis, including syntax, type, complexity, and sort code candidates based on heuristic scoring; Syntax, type, complexity are reduced to feature vectors and weighted to form a heuristic score As follows: ； in, For the first A positive quality indicator, For the first Each importance weight, For the first The severity of the defect, For the first The penalty weight of the item.

5. The full-automatic code programming method based on a large model according to claim 1, characterized in that, The specific implementation process of step 4 includes: Step 4.1: Automatically compile or build each code candidate to capture compilation errors and warnings; Step 4.2: Automatically generate test artifacts based on program specification graph (PSG); including unit testing, property testing, boundary / random data, transformation rules, performance and resource constraint scripts; Step 4.3: Execute test set and end-to-end acceptance test cases in sandbox, record running log, function correctness, return value, standard input / output, coverage, performance, resource occupation and running safety; Further preferably, the specific implementation process of step 5 includes: Step 5.1: The running output includes: functional correctness, error categories, minimal reproduction examples, coverage gaps, stack trace summaries, abstract syntax tree localization, and unmet acceptance criteria, which are summarized by the log refiner for structured feedback; Step 5.2: Determine success based on PSG acceptance criteria and threshold; if successful, output artifacts and solidify environment snapshot.

6. The full-automatic code programming method based on a large model according to claim 1, characterized in that, The specific implementation process of Step 6 includes: Step 6.1: Closed-loop error correction: if the acceptance criteria are not met, convert the compilation / run logs, stack traces, and abstract syntax tree differences into structured feedback and historical attempt summaries embedded in prompt words, and call the LLM again to generate patches and reconstruct new candidates for solutions; Step 6.2: Search strategy: use priority search or beam search and majority voting strategy to optimize within a limited number of iterations; Step 6.3: Stop rule: execute steps 6.1 to 6.2 in a loop until the success criterion is met, the acceptance criteria are met, or the iteration limit is reached, and then terminate; Further preferably, use beam search and majority voting strategy to optimize within a limited number of iterations; including: Setting beamwidth in beam search K , the set of candidate solutions collected iteratively is , the set of automatic verifiers is , each verifier v scores candidate s solutions ; hard assertions are desirable , the continuous indicators are normalized to ; Assigning a trust weight to each validator , and satisfying ; the iteration process only focuses on the top- K candidate solutions to control the search scale, coupled with the preset maximum iteration number T to form a limited constraint, and finally the support of all iteration candidate solutions is counted by the majority voting strategy Vote(s) : ； wherein the set of candidate solutions collected by all iterations is ; Subsequently, the first T set of candidate solutions after the second iteration solution with the highest support is determined as the optimal solution : ； wherein, Argmax is the index position of the largest Vote(s) is the index position of the largest Memory cache stores error signatures and repair prompt templates, and before generating candidate solutions or performing operations, it queries the cache first to directly filter recorded error items and avoid repeating mistakes from the source.

7. The full-automatic code programming method based on a large model according to claim 1, characterized in that, The specific implementation process of Step 7 includes: Step 7.1: Conduct compliance checks on external dependencies and licenses, including API whitelisting, network / file system minimum permissions, sensitive information desensitization, and key proxying; Step 7.2: Conduct license and third-party compliance checks; Step 7.3: If not compliant, block output and provide alternative implementation suggestions.

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, The processor executes the computer program to implement the steps of the large model-based fully automatic code programming method of any one of claims 1-7.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the large model-based fully automatic code programming method of any one of claims 1-7.

10. A large model-based full-automatic code programming system, characterized in that, Including: A multi-modal analysis module configured to: multi-modal requirement collection, analysis, and standardized representation; An environment orchestration module configured to: automatic development environment orchestration; A code generation module configured to: code candidate generation and quality inspection; A build and execution module configured to: compilation / building and automatic execution; An evaluation and determination module configured to: structured evaluation and success determination; A closed-loop error correction and self-optimization control module configured to: convert logs, stack traces, and AST differences into structured feedback; An optimization control module configured to: closed-loop error correction and self-optimization control; A security and compliance module configured to: security and compliance control.

Images