A design generation method for service opening demand and electronic equipment

Abstract

The application provides a design generation method for service opening demand, comprising the following steps: receiving service opening demand input, analyzing the service opening demand input into a structured segment; performing opening domain correlation judgment and term normalization on the structured segment, combining knowledge retrieval to generate a demand understanding result; retrieving relevant knowledge sources, converting into evidence references and assembling into evidence packages, binding the evidence packages to target fields of the demand understanding result, and performing evidence sufficiency verification on the target fields; after the demand understanding result passes the verification, generating a formal demand baseline; and generating a design product based on the formal demand baseline, wherein the design product comprises a design document, a rule draft, a template draft, and a configuration suggestion set for seven types of configuration modules. The scheme provided by the application can not be limited to a specific business example, a specific product, or a specific external platform, but is a general processing link for a business opening intelligent design state target system.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence, and in particular to a design generation method and electronic device for business activation requirements. Background Technology

[0002] Telecommunications operators typically need to handle multiple types of information when activating services, including product definitions, business processes, work order types, interface protocols, work order templates, rule configurations, dispatch relationships, test scenarios, and release materials. Traditional design-oriented processing relies heavily on manual methods: business personnel or designers read requirement forms, emails, official documents, forms, and interface documents, judge the scope of requirements and information gaps based on experience, and then manually write detailed designs, configuration pages, rule scripts, work order templates, test cases, and packaging instructions. This method has the following problems: 1. The input requirements are mostly in natural language and from multiple sources. Business semantics, process location, triggering conditions, affected modules, and cross-system boundaries are easily overlooked or misjudged.

[0003] 2. Design conclusions often lack field-level evidence linking them to the original data, making it difficult to trace subsequent reviews, debriefings, and dispute resolution.

[0004] 3. The lack of a unified state and unified object contract between the requirements understanding draft, formal baseline, design suggestions, configuration changes, test conclusions and packaging suggestions can easily lead to drafts being directly put into the formal chain, misuse of cross-task references, or inconsistencies in stage states.

[0005] 4. Existing automation tools are mostly focused on single-point capabilities, such as text summarization, automatic test case generation, communication service activation configuration, or general change approval. These tools usually cannot simultaneously solve the problems of data evidence, baseline freezing, configuration dependency sorting, gap blocking, manual confirmation, execution tokens, audit playback, and test packaging linkage in the business activation design state.

[0006] 5. If large models are simply allowed to generate configurations or call external tools directly, risks such as unfounded inferences, unauthorized writes, uncontrollable side effects, and unrepeatable results may occur.

[0007] Therefore, a new approach is urgently needed that can both leverage intelligent models to achieve bounded semantic understanding and generation, and control formal design results and external writing actions through deterministic rules, state machines, evidence binding, manual verification, and auditing mechanisms. Summary of the Invention

[0008] The purpose of this invention is to provide a design generation method and electronic device for business activation requirements, which is not limited to a specific business example, a product or an external platform, but is a general processing link for a business activation intelligent design state target system.

[0009] This application provides a design generation method for business activation requirements, including the following steps: receiving business activation requirement input and parsing the input into structured fragments; performing activation domain relevance judgment and terminology normalization on the structured fragments, and generating requirement understanding results by combining knowledge retrieval; retrieving relevant knowledge sources, converting them into evidence references and assembling them into evidence packages, binding the evidence packages to target fields of the requirement understanding results, and performing evidence sufficiency verification on the target fields; after the requirement understanding results pass the verification, generating a formal requirement baseline, which serves as the sole formal input for all subsequent stages; and generating design products based on the formal requirement baseline, the design products including design documents, rule drafts, template drafts, and configuration suggestion sets for seven types of configuration modules.

[0010] In one embodiment, the sufficiency verification of the target field includes: when the evidence for the target field is insufficient, generating a clarification item and blocking subsequent processes; supplementing data or clarifying issues for the clarification item; and performing partial recalculation of the affected target field.

[0011] In one embodiment, the method further includes: constructing a configuration dependency graph based on the configuration suggestion set, generating a change plan by sorting the dependencies; issuing a controlled execution token after the change plan is approved, requiring external write actions to verify the token's validity, and archiving the execution results as change execution results.

[0012] In one embodiment, the method further includes: generating a test scenario set and test data suggestions based on the requirement baseline, design artifacts, and change plan; generating coverage analysis and test conclusions after accessing the test results; and collecting a change list based on the test conclusions, design artifacts, and execution results to generate packaging scope, risk analysis, deployment suggestions, and rollback suggestions.

[0013] In one embodiment, the method further includes: creating a checkpoint snapshot at each critical node to record the entire operation trajectory, supporting task recovery and audit playback.

[0014] In one embodiment, the service activation requirement input includes one or more of the following: natural language description, requirement form, email, official document, form, interface protocol, product definition, process description, historical design data, configuration sample, and expert experience card.

[0015] In one embodiment, the requirement understanding result includes a requirement scope summary, modification type, work order type, triggering condition, dispatch object, order association split summary, cross-system impact, risk warning, and scope marker.

[0016] In one embodiment, the seven types of configuration modules include product configuration, product parameter configuration, work order configuration, work order template configuration, task configuration, process configuration, and dispatch rule configuration.

[0017] In one embodiment, the execution result includes an execution result identifier, a change plan identifier, an execution mode, a target system, an execution status, executed items, failed items, and evidence artifact references.

[0018] This application also provides an electronic device, which includes: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the above-described design generation method for service activation requirements.

[0019] The method provided in the above embodiments of this application, after receiving natural language requirements and attachments, first generates a structured understanding result of the binding evidence; after clarification and confirmation, it freezes the requirement baseline; then, based on the requirement baseline, it generates design documents, configuration suggestions, rule drafts, template drafts, and a change plan ordered by dependencies; after manual confirmation, it forms a unified execution result through controlled execution tokens or manual backfilling; finally, it generates self-test assets, coverage analysis, packaging scope, risk analysis, deployment suggestions, and rollback suggestions. This method is not limited to a specific business example, a specific product, or a specific external platform, but rather is a general processing link for business-oriented intelligent design-state target systems. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly described below.

[0021] Figure 1 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application; Figure 2 This is a flowchart illustrating a design generation method for business activation requirements provided in an embodiment of this application; Figure 3 This is a flowchart illustrating another design generation method for business activation requirements provided in this application embodiment. Detailed Implementation

[0022] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0023] Similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] Figure 1 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 100 can be used to execute the design and generation method for service activation requirements provided in an embodiment of this application. Figure 1 As shown, the electronic device 100 includes: one or more processors 102 and one or more memories 104 storing processor-executable instructions. The processors 102 are configured to execute the design generation method for service provisioning requirements provided in the following embodiments of this application.

[0025] The processor 102 may be a gateway, a smart terminal, or a device that includes a central processing unit (CPU), a graphics processing unit (GPU), or other forms of processing units with data processing capabilities and / or instruction execution capabilities. It can process data from other components in the electronic device 100 and control other components in the electronic device 100 to perform desired functions.

[0026] The memory 104 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 102 may execute the program instructions to implement the design and generation method for service provisioning requirements described below. Various application programs and various data may also be stored in the computer-readable storage medium, such as various data used and / or generated by the application programs.

[0027] In one embodiment, Figure 1 The illustrated electronic device 100 may further include an input device 106, an output device 108, and a data acquisition device 110, these components being interconnected via a bus system 112 and / or other forms of connection mechanisms (not shown). It should be noted that... Figure 1 The components and structure of the electronic device 100 shown are merely exemplary and not limiting; the electronic device 100 may also have other components and structures as needed.

[0028] The input device 106 can be a device used by a user to input commands, and may include one or more of a keyboard, mouse, microphone, and touchscreen. The output device 108 can output various information (e.g., images or sounds) to the outside (e.g., to a user), and may include one or more of a display, speaker, etc. The data acquisition device 110 can acquire service activation request inputs, etc., and store the acquired data in the memory 104 for use by other components.

[0029] In one embodiment, the components in the example electronic device 100, which implements the design generation method for service activation requirements of the present application, can be integrated or distributed. For example, the processor 102, memory 104, input device 106 and output device 108 can be integrated into one unit, while the data acquisition device 110 can be separated.

[0030] In one embodiment, the example electronic device 100 used to implement the design generation method for service activation requirements of the embodiments of this application can be implemented as a smart terminal such as a smartphone, tablet computer, desktop computer, server, vehicle equipment, etc.

[0031] Figure 2 This is a flowchart illustrating a design generation method for service activation requirements provided in this application embodiment. This method is used for intelligent design-state processing of communication service activation requirements and is executed by a design generation system for service activation requirements. Figure 2 In this method, steps 201-205 are included.

[0032] Step 201: Receive service activation request input and parse the service activation request input into structured fragments. The service activation request input includes one or more of the following: natural language description, request form, email, official document, form, interface protocol, product definition, process description, historical design data, configuration sample, and expert experience card.

[0033] Specifically, this step mainly completes task creation and multi-source data access. The system receives business activation requirement input, which includes one or more of the following: natural language description, requirement form, email, official document, form, interface protocol, product definition, process description, historical design data, configuration sample, and expert experience card. The Harness (a kind of intelligent agent support layer) master control layer creates TaskRun and generates TaskTraceContext, MaterialRef, and initial CheckpointSnapshot. Data only enters subsequent stages in the form of references to avoid domain modules directly manipulating the original file path or bypassing the master control state. In this step, the system calls the requirement source adapter or data parser according to the data type to split the input into ParsedMaterialFragment (parsed data fragment, i.e., structured fragment). Each fragment retains the source data, location hints, structured path, and normalized text as the candidate basis for subsequent evidence binding.

[0034] Step 202: Perform open-domain relevance judgment and terminology normalization on the structured fragments, and generate requirement understanding results by combining knowledge retrieval. The requirement understanding results include a requirement scope summary, modification type, work order form, triggering conditions, dispatch object, order association split summary, cross-system impact, risk warning, and scope markers.

[0035] Specifically, this step mainly completes requirement relevance judgment, terminology normalization, and structured understanding. The system performs open domain relevance judgment on ParsedMaterialFragment to identify whether the requirement involves products, work orders, processes, configurations, resources, dispatching, interfaces, or cross-system impacts. For relevant content, the system performs terminology normalization, alias recognition, abbreviation expansion, and historical terminology mapping, mapping the original terms to a unified business lexicon. Subsequently, the system combines the knowledge retrieval results to generate RequirementUnderstandingResult. This result includes at least a requirement scope summary, modification type, work order form, triggering conditions, dispatching object, affected configuration modules, order association split summary, cross-system impact, risk warning, and scope markers. Scope markers can include the official scope from the business editor, the scope reserved by the external platform, and content outside the scope. The model can be used for semantic understanding and candidate generation, but the final output must be converted into a structured object.

[0036] Step 203: Retrieve relevant knowledge sources, convert them into evidence references and assemble them into an evidence package, bind the evidence package to the target field of the requirement understanding result, and perform evidence sufficiency verification on the target field.

[0037] Specifically, this step mainly completes knowledge retrieval, evidence package assembly, and evidence sufficiency verification. The system constructs a RetrievalContext and a KnowledgeQuery, and retrieves knowledge sources such as ProductKnowledge, ProcessKnowledge, RulePattern, ConfigPattern, TestKnowledge, and KnowledgeCard based on the current stage, data scope, product scope, scenario scope, and target fields. The retrieved KnowledgeHit is not directly used as a formal conclusion, but is first converted into an EvidenceRef and then assembled into an EvidenceBundle.

[0038] The system binds EvidenceBundles to target fields in the structured understanding results, forming EvidenceBinding. For each key field, the system assesses the sufficiency of the evidence: if there is direct support from formal documentation or high-priority knowledge, it is marked as sufficient; if only examples or low-priority experience provide support, it is marked as partially sufficient and a risk warning is generated; if there is no reliable source or a conflict exists at the same priority level, an UnderstandingIssue or ClarificationItem is generated, and the process is blocked from entering the formal baseline. The key technical points of this step are: the evidence binding object explicitly points to the target field, rather than simply attaching reference text to the end of the document; conflicting evidence is retained as conflictRefs, not automatically selected by the model; and insufficient evidence is downgraded to a ClarificationItem or Gap Item.

[0039] In one embodiment, the sufficiency verification of the target field includes: when the evidence for the target field is insufficient, generating a clarification item and blocking subsequent processes; supplementing data or clarifying issues for the clarification item; and performing partial recalculation of the affected target field.

[0040] Specifically, this step primarily involves multiple rounds of clarification and partial reconstruction. When key fields are missing, conflicting, or have low confidence, the system generates a ClarificationItem, and Harness sets the task status to "pending supplementation" or "pending confirmation." After the user provides supplementary information or answers clarification questions, the system calls the reconstruction interface to perform partial recalculation on the affected fields, rather than rerunning the entire understanding result without boundaries. Unaffected and confirmed fields can continue to carry their evidence binding; fields explicitly modified by the user re-enter evidence binding and sufficiency verification. Through this step, the system can avoid two types of problems: first, incremental supplementation causes previously confirmed fields to be unnecessarily cleared; second, when a user explicitly modifies a field, the system silently continues to use the old value. This partial reconstruction mechanism allows multiple rounds of requirements understanding to proceed continuously while maintaining audit traceability.

[0041] Step 204: After the requirement understanding results are verified, a formal requirement baseline is generated, which serves as the sole formal input for all subsequent stages.

[0042] Specifically, this step mainly involves manual confirmation and freezing of the requirements baseline. Once the RequirementUnderstandingResult passes completeness and evidence sufficiency checks, Harness generates an ApprovalTicket. After reviewer confirmation, the system converts the understanding result into a formal input candidate, and the requirements baseline module performs strong validation of pre-requisite materials. After strong validation passes, the system freezes the RequirementBaselineRef and generates a formal standardized requirements document and document snapshot. Unconfirmed DRAFT (draft) understanding results cannot be used as formal input in the design, testing, or packaging phases. Frozen baselines include baselineId, baselineVersion, documentArtifactRef, and materialSnapshotRef for reference in subsequent phases. If the review is rejected or the materials are insufficient, the system retains the reason for rejection and reverts to the clarification or supplementary materials stage.

[0043] Step 205: Generate design deliverables based on the formal requirements baseline. These deliverables include design documents, rule drafts, template drafts, and a set of configuration suggestions for seven types of configuration modules. The seven types of configuration modules include product configuration, product parameter configuration, work order configuration, work order template configuration, task configuration, process configuration, and dispatch rule configuration.

[0044] Specifically, this step primarily generates design artifacts and configuration suggestions based on the formal baseline. The design and development module only consumes the frozen RequirementBaselineRef, formal document references, and knowledge scope. The system generates DetailedDesignArtifact, RuleDraft, TemplateDraft, and ConfigSuggestionSet. Configuration suggestions are generated for seven common business-related configuration modules, including product configuration, product parameter configuration, work order configuration, work order template configuration, task configuration, process configuration, and dispatch rule configuration. Each ConfigSuggestionItem contains the target configuration module, target object, target field, suggested value, source reference, confidence level, and review status. Configuration value sources are prioritized: formal requirement baseline takes precedence over formal documents, formal documents take precedence over confirmed configuration examples, confirmed configuration examples take precedence over expert experience, and manually supplemented input sources are recorded separately. In case of conflicts between high and low priorities, the former takes precedence and the conflict record is retained; in case of conflicts within the same priority range, a MappingGapItem is output, and no automatic selection is performed.

[0045] In one embodiment, the method further includes: constructing a configuration dependency graph based on the configuration suggestion set, generating change plans by sorting dependencies; issuing controlled execution tokens after the change plans are approved, requiring external write actions to verify token validity, and archiving execution results as change execution results. The execution results include an execution result identifier, a change plan identifier, an execution mode, a target system, an execution status, executed items, failed items, and evidence artifact references.

[0046] Specifically, this step mainly involves confirming the gate, the controlled execution token, and archiving the results. Once the ChangePlan meets the readiness check, Harness generates a change set confirmation. After approval, the ApprovalGate issues a ControlledExecutionToken. Write tools or CommandAdapters must verify the allowedAction, targetSystem, expireAt, and idempotencyKey of this token. Failure to verify results returns a blocking error, preventing external write operations. Execution results are uniformly archived as ChangeExecutionResult. This result can come from controlled execution or from manually entered results, but both are uniformly represented as executionResultId, changePlanId, executionMode, targetSystem, executionStatus, executedItems, failedItems, and evidenceArtifactRefs. With this unified result object, the self-testing, packaging, and auditing modules no longer need to be adapted to two sets of downstream contracts: one for automatic execution and one for manual backfilling.

[0047] In one embodiment, the method further includes: generating a test scenario set and test data suggestions based on the requirement baseline, design artifacts and change plan, and generating coverage analysis and test conclusions after accessing the test results.

[0048] Specifically, this step mainly involves generating self-test assets, integrating results, and performing coverage analysis. The self-test module receives the formal requirement baseline, formal design artifacts, ChangePlan, and optional ChangeExecutionResult, generating TestScenarioSet and TestDataSuggestionSet. Test scenarios must cover at least four dimensions: normal, change, regression, and anomaly. The system can generate TestExecutionPlan for automatic or semi-automatic execution, but any execution in a real test environment must be confirmed and token-controlled by Harness. After integrating test results, the system converts them into TestResultBundle and generates CoverageAnalysisResult and TestConclusionSummary based on design artifacts, change plans, and historical test knowledge. If test data is missing, key scenarios are not covered, or the cause of failure is unclear, a blocking risk or supplementary conclusion is output, and the process does not proceed to the packaging preparation stage.

[0049] In one embodiment, the method further includes: collecting a change list based on the test conclusions, design artifacts, and execution results, and generating a packaging scope, risk analysis, deployment recommendations, and rollback recommendations.

[0050] Specifically, this step mainly involves change collection, packaging scope analysis, and release preparation recommendations. The packaging module receives confirmed test conclusions, design artifacts, and execution results, and collects code changes, database configuration changes, and key document changes in read-only mode to form a ChangeInventory. Based on the requirement baseline, change evidence, and test conclusions, the system generates PackageScopeResult, PackageRiskAnalysis, DeploymentAdvice, RollbackAdvice, and ReleaseNoteDraft. If parallel requirement boundary conflicts, missing files, missing configurations, missing test conclusions, or release execution exceeding boundaries are found, the system marks PackageConclusionSummary as BLOCKED or NEEDS_SUPPLEMENT. This module only generates release preparation recommendations and does not directly execute production releases or automatic release requests.

[0051] In one embodiment, the method further includes: creating checkpoint snapshots at each critical node to record the entire operation trajectory, supporting task recovery and audit playback.

[0052] Specifically, this step mainly completes state governance, checkpointing, auditing, and recovery. At each stage, Harness maintains the state of TaskRun, StageRun, and StepExecution, and uniformly registers the stage outputs as ArtifactIndex. The system creates CheckpointSnapshots at key nodes such as task creation, stage completion, before confirmation, before and after external execution, test conclusion formation, and packaging conclusion formation. If a task is interrupted or resumed across days, RecoveryManager restores the context, state, and pending items based on the checkpoints. AuditTracer records model call summaries, tool call parameter summaries, state changes, manual confirmation, evidence binding, change plans, token issuance, execution results, and artifact change trajectories, supporting querying and playback by taskRunId, stageRunId, or traceId.

[0053] This invention is not simply a method for automatically configuring and enabling communication services, nor is it a general method for generating automatic tests or a general change approval system. Rather, it solidifies the multi-stage object chain of service activation design into an evidence-driven method. Its key points are: 1. Use EvidenceBinding to bind original data, knowledge matching, and business conclusions by field, first verify the sufficiency of evidence, and then proceed to confirmation and baseline freezing.

[0054] 2. Use RequirementBaselineRef as the only formal input during the design, self-testing, and packaging phases to prevent the direct downstream flow of understanding drafts, model outputs, or verbal conclusions.

[0055] 3. For each business, seven types of configuration modules are enabled, constructing ConfigSuggestionSet and ConfigDependencyEdge, and then generating ChangePlan to determine configuration dependencies and execution order before execution.

[0056] 4. Write operations must pass through ApprovalGate and ControlledExecutionToken to form a unified ChangeExecutionResult, thus being compatible with both controlled execution and manual backfilling.

[0057] 5. Integrate requirements understanding, design and development, self-testing assistance, and packaging assistance into the same controlled state machine and audit chain, so that the deliverables at each stage are traceable, recoverable, and replayable.

[0058] 6. The model is only responsible for semantic understanding, candidate generation, and draft generation. State progression, evidence sufficiency, execution authorization, idempotency, and auditing are controlled by deterministic mechanisms within the system.

[0059] In one embodiment, the requirement input data can come from ITSM (Information Technology Service Management), email system, document library, form, interface protocol library, knowledge base, chat portal, or manually uploaded directory. The data access method can be replaced with HTTPAPI (Application Programming Interface), message queue, local file adapter, or MCP (Model Context Protocol) adapter.

[0060] In one embodiment, knowledge retrieval can employ keyword retrieval, vector retrieval, hybrid retrieval, rule retrieval, or graph retrieval; as long as the retrieved items are converted into EvidenceRef and undergo evidence sufficiency verification before entering the formal conclusion, they constitute an equivalent implementation of the present invention.

[0061] In one embodiment, requirements understanding and design generation can invoke different large models, rule engines, template engines, or expert systems; the model runtime can be replaced with a private model, a public model gateway, or an offline inference service, but the constraints that the model does not directly advance the global state and does not directly execute external write actions must not be changed.

[0062] In one embodiment, the number and names of the seven types of configuration modules can be adjusted according to the specific operator system, such as adding interface configuration, resource configuration, channel configuration or external platform placeholder configuration; as long as source priority, gap identification, dependency sorting and change plan mechanism are adopted, they are all variations of the present invention.

[0063] In one embodiment, controlled execution can be real API writing, automated page writing, script execution, manual data entry and backfilling, or sandbox dry-run (trial run); the execution results can all be uniformly archived as ChangeExecutionResult or equivalent objects.

[0064] In one embodiment, the self-testing phase may only generate test suggestions or may integrate with an automated testing environment; the packaging phase may only generate release instructions or may extend pre-release checks. If actual release execution needs to be integrated, it should be treated as an independent, controlled execution chain, and still require confirmation, tokens, and auditing.

[0065] In one embodiment, manual confirmation can be achieved through approval forms, workflow platforms, electronic signatures, dual review, or work order status transitions; any auditable ApprovalTicket or equivalent confirmation object that can be generated before formal implementation can be used as an alternative.

[0066] In one embodiment, the system deployment form can be a monolithic application, a distributed microservice, a pluggable platform, or a cloud-native service; data storage can use relational databases, document databases, object storage, or knowledge bases, as long as the traceability relationship between tasks, stages, evidence, artifacts, and audit objects is maintained.

[0067] Figure 3 This is a flowchart illustrating another design generation method for service activation requirements provided in this application embodiment. Figure 3 The method includes steps S1-S11.

[0068] S1: Access multiple data sources, create tasks and reference data.

[0069] The system receives a service activation request form through the ITSM system interface. The request form includes a natural language description: "Add a 5G enterprise leased line product, supporting bandwidth-based billing; the work order will be dispatched to the local operations and maintenance department," along with product definition documentation, interface protocols, and historical configuration examples. The Harness control layer creates a TaskRun, generates a unique TaskTraceContext for end-to-end tracing, generates a MaterialRef for each attachment, and creates an initial CheckpointSnapshot. The system calls a PDF parser and an Excel parser to split the request form and attachments into multiple ParsedMaterialFragments. Each fragment records the source document name, page number, line number, and normalized text.

[0070] S2: Structured requirements understanding, terminology normalization and scope identification.

[0071] The system performs domain relevance checks on all ParsedMaterialFragments, filtering out irrelevant administrative explanations. Terminology is standardized for related content, mapping "5G enterprise leased line" to "5G enterprise access leased line" in a unified business thesaurus, and "local maintenance department" to "local maintenance team." Based on the knowledge retrieval results, a RequirementUnderstandingResult is generated, with the requirement scope summary as "Add a 5G enterprise access leased line product, configure bandwidth-based billing rules, and dispatch the work order to the local maintenance team," the modification type as "Add Product," and the affected configuration modules including product configuration, product parameter configuration, work order configuration, and dispatch rule configuration.

[0072] S3: Evidence assembly and verification, binding fields and sufficiency judgment.

[0073] The system constructs a KnowledgeQuery, retrieving product definitions for 5G enterprise leased lines from ProductKnowledge, process rules for work order dispatch from ProcessKnowledge, and configuration templates for bandwidth-based billing from ConfigPattern. The retrieved items are converted into EvidenceRefs, assembled into EvidenceBundles, and bound to the corresponding fields in RequirementUnderstandingResult. For example, the "bandwidth-based billing" field is bound to the EvidenceRef in paragraph 2 of page 3 of the product definition document, and the "dispatch to local operations and maintenance department" field is bound to the EvidenceRef in paragraph 1 of page 5 of the process rules document. The system determines that the evidence for all key fields is sufficient and no clarification items are generated.

[0074] S4: Clarify and partially rebuild, fill gaps and conflicts.

[0075] In this embodiment, all key fields have sufficient evidence and require no clarification; proceed directly to the next step.

[0076] Step S5: Baseline freeze, and after confirmation, formal input is generated.

[0077] Harness generates an ApprovalTicket and submits it to the business reviewer. After the reviewer confirms that the requirements are correctly understood, the system performs strong validation of the prerequisite documents to ensure that all necessary documents are complete. Subsequently, the RequirementBaselineRef is frozen, generating a formal standardized requirements document and document snapshot, with the baseline version number being V1.0.

[0078] S6: Design and configuration suggestions, generating drafts and suggestion sets.

[0079] The design and development module reads the frozen RequirementBaselineRef and generates DetailedDesignArtifact, which describes the business processes and configuration requirements of the 5G enterprise leased line product. Simultaneously, it generates a ConfigSuggestionSet, containing four types of suggestions: product configuration, product parameter configuration, work order configuration, and dispatch rule configuration. For example, the target field for the product configuration suggestion is "Product Name," the suggested value is "5G Enterprise Access Leased Line," the source reference is RequirementBaselineRef, and the confidence level is 100%. The target field for the product parameter configuration suggestion is "Billing Method," the suggested value is "Tiered Billing by Bandwidth," the source reference is the EvidenceRef from the product definition document, and the confidence level is 95%.

[0080] S7: Change plan, dependency sorting and pre-execution verification.

[0081] The system constructs a configuration dependency graph based on ConfigSuggestionSet, with the default dependency order being product configuration → product parameter configuration → work order configuration → dispatch rule configuration. Since there are no special dependencies in this embodiment, ChangePlan is generated directly according to the default order. ChangePlan includes baselineId, affectedModules (which are ["product configuration module", "work order configuration module", "rule configuration module"], orderedChanges (arranged in dependency order), executionPrechecks ("check target system connectivity"), and rollbackHints ("delete newly added configuration items in reverse order").

[0082] S8: Controlled execution / manual backfilling, tokens, idempotency, and result archiving.

[0083] Harness generates a changeset confirmation form and submits it to the configuration reviewer. Upon approval, ApprovalGate issues a ControlledExecutionToken with allowedAction set to "Configuration Write", targetSystem set to "Business Orchestration System", expireAt set to 24 hours later, and idempotencyKey set to the change plan ID. CommandAdapter verifies the token's validity and then calls the business orchestration system's API to execute the configuration write. Upon successful execution, the system generates a ChangeExecutionResult, recording executionResultId, changePlanId, executionMode set to "Auto Execution", executionStatus set to "Success", and executedItems set to all configuration items.

[0084] S9: Self-test analysis, scenarios, data, coverage, and conclusions.

[0085] The self-testing module receives the requirement baseline, design artifacts, and change plan, and generates a TestScenarioSet, including normal commissioning scenarios, bandwidth change scenarios, regression testing scenarios, and abnormal parameter scenarios. It also generates a TestDataSuggestionSet, suggesting the use of test accounts and test bandwidth values. After testers execute the tests, they enter the results into the system. The system converts this into a TestResultBundle, generating a CoverageAnalysisResult that shows all key scenarios have been covered, and the test conclusion is "Pass".

[0086] S10: Packaging and Release Preparation, Scope, Risks, Deployment, and Rollback.

[0087] The packaging module receives test results and collects configuration changes and design documents from the business orchestration system in read-only mode, forming a ChangeInventory. The system generates PackageScopeResult, determining the packaging scope to include newly added product configurations, parameter configurations, work order configurations, and dispatch rules; it generates PackageRiskAnalysis, assessing the risk level as "low"; it generates DeploymentAdvice, recommending deployment during off-peak hours; it generates RollbackAdvice, recommending deleting configuration items in reverse order; and it generates ReleaseNoteDraft, describing the content and impact of this release.

[0088] S11: End-to-end auditing and recovery, status, checkpoints, and replay.

[0089] Upon completion of each stage, Harness updates the TaskRun status and creates a CheckpointSnapshot. AuditTracer records the entire process from task creation to packaging completion, including model call summaries, tool call parameters, manual confirmation records, evidence binding relationships, change plan content, token issuance information, and execution results. Administrators can query and replay the entire process using the taskRunId.

[0090] The embodiments described above in this application, upon receiving natural language requirements and attachments, first generate a structured understanding result bound by evidence; after clarification and confirmation, freeze the requirement baseline; then, based on the requirement baseline, generate design documents, configuration suggestions, rule drafts, template drafts, and a change plan ordered by dependencies; after manual confirmation, form a unified execution result through controlled execution tokens or manual backfilling; finally, generate self-test assets, coverage analysis, packaging scope, risk analysis, deployment suggestions, and rollback suggestions in a linked manner. The above embodiments provide an evidence-driven intelligent design state generation method for business activation requirements, achieving at least the following technical effects: 1. Transform multi-source business activation data into structured, auditable, and traceable requirements understanding results, reducing omissions and misinterpretations caused by simple manual reading.

[0091] 2. Bind key understanding fields, configuration suggestions, test conclusions, and packaging suggestions to EvidenceRef or equivalent evidence references to avoid unfounded inferences entering the formal process.

[0092] 3. By freezing the requirements baseline, we prevent the draft understanding from flowing directly into the design, testing, and packaging stages, thereby improving the consistency of input at each stage.

[0093] 4. For common business configurations such as product configurations, product parameters, work order configurations, work order templates, task configurations, process configurations, and dispatch rule configurations, generate configuration suggestion sets and change plans organized by source priority and dependency relationships.

[0094] 5. Introduce a manual confirmation gate and controlled execution token before implementing the change plan, so that external writes, test executions or high-risk actions must be authorized, idempotent, and auditable.

[0095] 6. Continue to pass the design and development results to the self-testing and packaging modules to form test scenarios, coverage analysis, packaging scope, risk analysis, deployment suggestions, rollback suggestions, and release notes drafts, so as to avoid the separation of design, testing, and packaging.

[0096] 7. Supports task continuation across days, failure recovery, manual takeover, and audit playback, improving the stability and maintainability of the design-state processing chain.

[0097] The devices and methods disclosed in the several embodiments provided in this application can also be implemented in other ways. The device and method embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0098] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

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

Claims

1. A design generation method oriented towards business activation requirements, characterized in that, Includes the following steps: Receive service activation request input and parse the service activation request input into a structured fragment; The structured fragments are subjected to open-domain relevance judgment and terminology normalization, and combined with knowledge retrieval to generate requirements understanding results; Relevant knowledge sources are retrieved, converted into evidence references, and assembled into evidence packages. The evidence packages are then bound to target fields of the requirements understanding results, and the sufficiency of evidence is verified for the target fields. After the requirements understanding results are verified, a formal requirements baseline is generated, which serves as the sole formal input for all subsequent stages. Design artifacts are generated based on the formal requirements baseline. These artifacts include design documents, rule drafts, template drafts, and a set of configuration suggestions for seven types of configuration modules.

2. The design and generation method for service activation requirements according to claim 1, characterized in that, The sufficiency of evidence verification of the target field includes: When the evidence for the target field is insufficient, a clarification item is generated and subsequent processes are blocked; For the aforementioned clarification items, supplementary information or clarification of issues are provided, and the affected target fields are partially recalculated.

3. The design and generation method for service activation requirements according to claim 1, characterized in that, The method further includes: Based on the configuration suggestion set, a configuration dependency graph is constructed, and a change plan is generated by sorting the dependencies. Once the change plan is approved, a controlled execution token is issued. External write actions must verify the validity of the token, and the execution results are uniformly archived as change execution results.

4. The design and generation method for service activation requirements according to claim 3, characterized in that, The method further includes: Based on the aforementioned requirement baseline, design artifacts, and change plan, a test scenario set and test data suggestions are generated. After integrating the test results, coverage analysis and test conclusions are generated. Based on the test results, design artifacts, and execution results, a change list is collected, and a package scope, risk analysis, deployment recommendations, and rollback recommendations are generated.

5. The design and generation method for service activation requirements according to any one of claims 1-4, characterized in that, The method further includes: Create checkpoint snapshots at each critical node to record the entire operation trajectory, supporting task recovery and audit playback.

6. The design and generation method for service activation requirements according to claim 1, characterized in that, The input for service activation requirements includes one or more of the following: natural language description, requirement form, email, official document, form, interface protocol, product definition, process description, historical design data, configuration sample, and expert experience card.

7. The design and generation method for service activation requirements according to claim 1, characterized in that, The results of the requirement understanding include a summary of the requirement scope, modification type, work order type, triggering conditions, dispatch object, summary of order association splitting, cross-system impact, risk warning, and scope marking.

8. The design and generation method for service activation requirements according to claim 1, characterized in that, The seven types of configuration modules include product configuration, product parameter configuration, work order configuration, work order template configuration, task configuration, process configuration, and dispatch rule configuration.

9. The design and generation method for service activation requirements according to claim 3, characterized in that, The execution results include execution result identifier, change plan identifier, execution mode, target system, execution status, executed items, failed items, and evidence artifact references.

10. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store processor-executable instructions; The processor is configured to execute the design generation method for service activation requirements as described in any one of claims 1-9.

Images