Artificial intelligence application scenario demand matching method and system applied to market promotion platform

Abstract

The application provides an artificial intelligence application scene demand matching method and system applied to a market promotion platform, and relates to the technical field of computers. First, user demand description is subjected to dynamic scene deduction to generate demand scene deduction knowledge blocks, and then promotion resources are subjected to scene-based capability mapping to generate a resource scene mapping set. Next, a scene cooperative adaptation scheme is generated by performing a cooperative adaptation operation on the two. Based on the scene cooperative adaptation scheme, promotion resources are screened to form an adaptation resource list. Finally, user actual application data is collected to adjust the knowledge blocks, the mapping set and the adaptation scheme. The application can accurately, comprehensively and dynamically match artificial intelligence application scene demand and promotion resources, and improve market promotion effect and efficiency.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a method and system for matching the needs of artificial intelligence application scenarios in a marketing platform. Background Technology

[0002] In today's digital business environment, marketing platforms play a crucial role, aiming to accurately match various promotional resources with users who have the needs, thereby achieving efficient business promotion. With the rapid development of artificial intelligence technology, users' demands for AI application scenarios are becoming increasingly diverse and complex.

[0003] Currently, marketing platforms face numerous challenges in addressing users' needs for AI application scenarios. On one hand, user requests are often vague and broad, lacking clear descriptions of specific functions and technical implementations, making it difficult for platforms to accurately grasp users' true needs. On the other hand, while marketing platforms offer a wide variety of promotional resources, they lack effective classification and integration mechanisms, making it difficult to quickly find resources that match user needs. Furthermore, existing matching methods are mostly based on simple keyword matching or static rule matching, failing to consider the dynamic changes in user needs and the synergistic relationships between promotional resources. This results in inaccurate and incomplete matching results, failing to meet the actual needs of users and the market, and impacting the effectiveness and efficiency of marketing efforts. Summary of the Invention

[0004] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a method for matching the needs of artificial intelligence application scenarios applied to a marketing platform, the method comprising: Dynamic scenario deduction is performed on the user-initiated description of artificial intelligence application scenario requirements, generating requirement scenario deduction knowledge blocks. The requirement scenario deduction knowledge blocks include the functional module requirements, technical execution paths, operating platform requirements, interaction execution sequences, and extended requirement directions of the artificial intelligence application scenario requirements. The promotional resources of the marketing platform are mapped to specific scenarios to generate a resource scenario mapping set. The resource scenario mapping set includes the functional implementation form of the promotional resources, the scope of scenario adaptation, the linkage execution path and the capability expansion boundary. Perform a collaborative adaptation operation on the knowledge block of the demand scenario deduction and the resource scenario mapping set to generate a scenario collaborative adaptation scheme. The scenario collaborative adaptation scheme includes the docking nodes of the knowledge block and the set, the execution order and the collaborative operation process. Based on the scenario collaboration adaptation scheme, promotional resources in the marketing platform that can undertake the docking nodes and collaborative operation processes are selected to form a list of scenario demand adaptation resources. Collect actual application data of users' use of the promotional resources in the resource list that adapts to the scenario requirements, and adjust the knowledge block dimension of the requirement scenario deduction knowledge block, the mapping attribute of the resource scenario mapping set, and the collaborative logic of the scenario collaborative adaptation scheme based on the actual application data.

[0005] Furthermore, embodiments of the present invention also provide an artificial intelligence application scenario demand matching system applied to a marketing platform, comprising: A processor; a machine-readable storage medium for storing machine-executable instructions of the processor; wherein the processor is configured to execute the aforementioned artificial intelligence application scenario demand matching method applied to a marketing platform by executing the machine-executable instructions.

[0006] Based on the above, dynamic scenario deduction is performed on user-initiated AI application scenario requirements, generating requirement scenario deduction knowledge blocks containing detailed information. Then, scenario-based capability mapping is performed on the promotional resources of the marketing platform, generating a resource scenario mapping set. This clarifies the functional characteristics and applicable scenarios of the promotional resources, making the resource information more structured and clear. Collaborative adaptation operations are performed on the requirement scenario deduction knowledge blocks and the resource scenario mapping set to generate scenario collaborative adaptation schemes. This fully considers the collaborative relationship between user needs and promotional resources. Based on the scenario collaborative adaptation schemes, promotional resources are selected to form a list of scenario requirement-adapted resources, providing users with accurate promotional resource recommendations. By collecting actual user application data and adjusting the requirement scenario deduction knowledge blocks, resource scenario mapping sets, and scenario collaborative adaptation schemes accordingly, dynamic optimization of the matching process is achieved. This allows the matching results to be continuously adjusted and improved as user needs and the market environment change, significantly improving the accuracy, comprehensiveness, and adaptability of AI application scenario requirement matching on the marketing platform, and effectively improving the effectiveness and efficiency of marketing promotion. Attached Figure Description

[0007] Figure 1 This is a schematic diagram of the execution flow of the artificial intelligence application scenario demand matching method for marketing platforms provided in this embodiment of the invention.

[0008] Figure 2 This is a schematic diagram of exemplary hardware and software components of an artificial intelligence application scenario demand matching system for a marketing platform provided in an embodiment of the present invention. Detailed Implementation

[0009] Figure 1 This is a flowchart illustrating an artificial intelligence application scenario demand matching method for a marketing platform, provided by an embodiment of the present invention. A detailed description follows.

[0010] Step S110: Perform dynamic scenario deduction on the user-initiated artificial intelligence application scenario requirement description to generate requirement scenario deduction knowledge blocks. The requirement scenario deduction knowledge blocks include the functional module requirements, technical execution paths, operating carrier requirements, interaction execution sequences, and extended requirement directions of the artificial intelligence application scenario requirements.

[0011] This embodiment takes the urban emergency safety management technology scenario in the process of smart city construction as an example. When the urban emergency management department submits a requirement description for an "intelligent early warning and response system for urban flooding disasters" through a market promotion platform, the dynamic scenario simulation process is triggered. This requirement description includes core demands such as event monitoring, risk assessment, and resource scheduling. For example, "the system needs to monitor water level changes at flood-prone points in real time during heavy rainfall, predict the flood risk level within the next two hours, generate an emergency drainage equipment scheduling plan, and support information exchange between the command center and on-site personnel." The dynamic scenario simulation constructs a scenario state transition model to simulate the system's functional response logic under different rainfall intensities and durations, thereby outlining the functional module system, clarifying the technical implementation path of each module, limiting the hardware configuration and software environment of the operating platform, planning the user-system interaction process, and predicting potential functional expansion needs. During the simulation, it is necessary to ensure that the data flow logic between each functional module conforms to emergency management business specifications, and that the technical execution path meets real-time and reliability requirements.

[0012] Step S111: Receive the description of the artificial intelligence application scenario requirements submitted by the user through the interaction port of the marketing platform. The description of the artificial intelligence application scenario requirements is a complete text of the user's request for the application of artificial intelligence technology in a specified promotion scenario.

[0013] The marketing platform has a dedicated interface for submitting requirements. This interface uses an encrypted transmission protocol and integrates user authentication and access control mechanisms. Users from urban emergency management departments submit requirement descriptions through this interface, including elements such as the scenario background, core functional requirements, performance indicators, and data source descriptions. For example, the submitted text might include: "The application scenario is urban flooding disaster emergency response, requiring real-time monitoring of water levels at flood-prone points (sampling frequency not lower than the set value), prediction of flood risk levels (divided into five levels), intelligent scheduling of emergency drainage equipment (response time not exceeding the set duration), and multi-terminal information interaction (supporting command center and mobile terminals). Data sources include municipal drainage network sensors, weather stations, and water level monitoring terminals." After receiving this text, the platform stores it in the "Original User Requirement Table" of the distributed database and generates a unique requirement number for subsequent full-process tracking.

[0014] Step S112: Extract relevant statements related to function implementation from the description of the requirements for the artificial intelligence application scenario, and form a set of function implementation-related statements. The set of function implementation-related statements includes various functional expectations of users for artificial intelligence applications.

[0015] A Transformer-based text semantic understanding model is used to process the requirement description text. This model is pre-trained in a general domain and then fine-tuned using annotated corpus from the emergency management domain. The model identifies functional keywords and related expressions in the text, such as extracting expressions like "real-time monitoring of water levels at flood-prone areas," "prediction of urban flooding risk levels," "intelligent scheduling of emergency drainage equipment," and "multi-terminal information interaction" from the requirement description. After deduplication, these expressions are grouped according to semantic relevance to form a set of expressions related to functional implementation. This set uses a JSON array data structure, with each element containing "expression content," "semantic weight," and "associated functional domain" fields. The semantic weight is calculated using word vector cosine similarity, and the associated functional domain is determined through matching with a domain ontology library.

[0016] Step S113: Based on the set of function implementation related statements, multiple function module implementation requirements are obtained. Each function module implementation requirement corresponds to an independent function execution step, and each function module implementation requirement includes specific function achievement goals.

[0017] For each statement in the set of statements related to function implementation, dependency parsing is performed. Natural language processing tools are used to extract the verb-object structure and modifiers, identifying the functional action, target object, and constraints. For example, "real-time monitoring of water levels at flood-prone areas" is broken down into the action "monitoring," the object "water levels at flood-prone areas," and the constraint "real-time." Quantitative indicators are added based on domain knowledge to form the "implementation requirements for the real-time monitoring of water levels at flood-prone areas functional module." Its functional goal is to "periodically collect water level data from all flood-prone areas in the city, with the data update interval not exceeding a set value and the data accuracy rate not lower than a set percentage." All statements are broken down according to this rule to form a list of functional module implementation requirements. Each requirement includes five attributes: "module identifier," "functional action description," "target object description," "set of quantitative indicators," and "functional priority." The functional priority is calculated by weighting semantic weight and domain importance coefficient.

[0018] Step S114: Retrieve the technical implementation forms corresponding to the implementation requirements of each functional module in the field of artificial intelligence technology, and generate the technical execution path corresponding to the implementation requirements of each functional module based on the technical implementation forms. The technical execution path includes continuous technical operation steps.

[0019] Step S1141: Extract the core technology categories in the field of artificial intelligence technology that can support the implementation of various functional modules, and form an artificial intelligence core technology catalog. The artificial intelligence core technology catalog includes the functional support scope and application forms of various technologies.

[0020] By leveraging knowledge graph construction technology, a structured catalog of core AI technologies is created by integrating the AI ​​technology classification system with emergency management application cases. This catalog includes attributes such as technology category, sub-items, functional support scope, application form, and maturity level. For example, the technology category "Time Series Data Prediction Technology" includes sub-items such as "Recurrent Neural Network Model" and "Temporal Convolutional Network Model," its functional support scope covers "Water Level Change Prediction" and "Rainfall Prediction," its application forms include "Model API Services" and "Localized Deployment Packages," and its maturity level is determined through the number of application cases and their effectiveness. During the catalog construction process, it is essential to ensure that the technology category classification conforms to international standards and industry specifications, and that the descriptions of functional support scopes have clear scenario-specific relevance.

[0021] Step S1142: Compare the implementation requirements of each functional module with the core technology categories in the core technology catalog of artificial intelligence to determine the target core technology that can support the implementation of the functional module.

[0022] A semantic network-based matching algorithm is employed to calculate semantic similarity between the "functional action description" and "target object description" of the functional module's implementation requirements and the "functional support scope" of the core technology category. First, lexical analysis and entity linking are performed on both texts, mapping them to concept nodes in the domain ontology. Then, semantic similarity is determined by calculating the path length and association strength between concept nodes. For example, the semantic similarity between "waterlogging risk level prediction functional module" and "time series data prediction technology" exceeds a set threshold; therefore, time series data prediction technology is identified as the target core technology. In cases with multiple potential technology categories, the optimal target core technology is determined by a weighted score based on technology maturity level and scenario adaptability.

[0023] Step S1143: Collect mature application examples of the target core technology, extract the functional achievement methods and operation sequence of the target core technology in the examples, and form technical application reference content.

[0024] Application cases of the target core technologies were retrieved from technical literature databases and patent databases, and examples with complete technology implementation processes were selected. For example, for time series data prediction technology, the case of "urban water level prediction system" was selected, and its operational steps such as data acquisition, data preprocessing, feature engineering, model training, and predictive inference were extracted and organized into technical application reference content according to time sequence and logical relationships. This content is stored using a directed acyclic graph data structure, where nodes represent operational steps, edges represent dependencies between steps, and each node includes attributes such as "step name," "input data specifications," "output data specifications," and "key technical parameters." During the extraction process, the completeness and traceability of the operational steps must be ensured, and the source literature of key technical parameters must be marked.

[0025] Step S1144: Extract the application environment constraints of the marketing platform, which are the constraints of the marketing platform in terms of hardware configuration, software environment and data transmission.

[0026] Extract application environment constraints from the system configuration documents and operating environment descriptions of the marketing platform. Hardware configuration includes server architecture (e.g., distributed cluster), computing resources (e.g., number of CPU cores, memory capacity), storage resources (e.g., storage type, capacity), and network configuration (e.g., bandwidth, latency). Software environment includes operating system type, database system version, AI framework version, and middleware specifications. Data transmission includes transmission protocol, encryption standard, data compression method, and transmission rate requirements. Organize these conditions into a structured constraint set, stored in XML format. Each constraint item includes attributes such as "constraint type," "constraint value," and "constraint level" (e.g., required, optional). During the extraction process, confirm the latest configuration parameters with the platform's technical department to ensure the accuracy of the constraints.

[0027] Step S1145: Compare the operational steps in the technical application reference content with the application environment constraints of the marketing platform, identify and remove operational steps in the technical application reference content that are incompatible with the application environment constraints.

[0028] A compatibility assessment matrix is ​​constructed. Rows represent operational steps within the technical application reference content, columns represent application environment constraints, and element values ​​indicate the degree to which the steps meet the conditions (e.g., fully met, partially met, not met). A rule engine compares the resource requirements of each operational step with the platform constraints. For example, if an operational step requires GPU computing power higher than the platform configuration, it is considered unmet. For unmet operational steps, attempts are first made to adapt them through parameter adjustments or alternative algorithms. If adaptation fails, they are removed. For example, the "parallel training step based on a specific GPU model" is removed due to platform GPU model incompatibility and replaced with a "distributed training step based on CPU," and the dependencies between steps are updated.

[0029] Step S1146: Decompose the technical application reference content after removing incompatible operation links into multiple consecutive technical operation steps. Each technical operation step corresponds to a specific technical execution action, and each technical operation step includes specific input content and output results.

[0030] The processed technical application reference content is broken down into process steps, and detailed flowcharts are drawn using business process modeling notation specifications. Each operation is decomposed into atomic technical operation steps. For example, the "data preprocessing step" is broken down into "data format conversion step" (input: raw sensor data; output: standardized format data), "missing value handling step" (input: standardized format data; output: completed data), and "data smoothing step" (input: completed data; output: smoothed time series data). Each step includes attributes such as "step number," "action description," "input data structure," "output data structure," and "execution logic description." The data structure must clearly specify the field names, data types, and value ranges, and the execution logic description must describe the specific processing rules and algorithm selection criteria.

[0031] Step S1147: Analyze the correspondence between each technical operation step and the sub-goals of the functional module's implementation requirements, and determine the execution purpose of each technical operation step.

[0032] A mapping model is established between technical operation steps and functional module sub-goals, and the correspondence is determined through domain knowledge graphs and rule-based reasoning. Functional module sub-goals are obtained through hierarchical decomposition of functional achievement objectives. For example, the sub-goals of the "Flood Risk Level Prediction Functional Module" include "Data Quality Improvement," "Prediction Model Optimization," and "Result Visualization." Technical operation steps are associated with sub-goals through semantic matching. For example, the "Missing Value Handling Step" corresponds to the "Data Quality Improvement" sub-goal, with the execution purpose of "reducing the impact of missing data on the accuracy of the prediction model"; the "Model Hyperparameter Tuning Step" corresponds to the "Prediction Model Optimization" sub-goal, with the execution purpose of "improving the model's adaptability to different rainfall scenarios." The execution purpose is added as metadata to the attributes of the technical operation steps for subsequent path optimization.

[0033] Step S1148: Determine the conditions required to start each technical operation step, wherein the conditions required to start the technical operation step are the prerequisite technical states and data input requirements that must be met.

[0034] The preconditions for each technical operation step are identified using cause-effect graph analysis and process dependency analysis. Preconditions include data input requirements (such as data integrity, format compliance, and timestamp validity) and pre-existing technical status (such as the completion status of preceding steps, resource usage, and system status codes). For example, the activation conditions for the "data smoothing processing step" are: "Missing value processing step completed (status marked as successful)", "Input data contains more than a set number of valid samples", and "System memory usage is below a set threshold". These activation conditions are stored as logical expressions, such as "(Preceding step status = successful) AND (sample count ≥ threshold A) AND (memory usage ≤ threshold B)", and associated with the corresponding technical operation steps.

[0035] Step S1149: Integrate the inherent execution logic between the technical operation steps, and arrange the technical operation steps according to the execution rules of the target core technology and the progressive relationship of the achievement of functional module requirements.

[0036] Based on the dependencies between technical operation steps and the order in which functional module sub-goals are achieved, a directed graph model of the technical execution path is constructed. First, the order of steps is determined according to preconditions; for example, the "data acquisition step" must be executed before the "data preprocessing step." Then, the step order is adjusted based on the typical execution flow of the core target technology (e.g., the machine learning flow of data → features → model → inference). Finally, the path structure is optimized based on the progressive relationship of achieving functional module sub-goals (e.g., data preparation first, then model training, and finally prediction application). During the arrangement process, a topological sorting algorithm is used to eliminate circular dependencies, ensuring the directed acyclic nature of the path. Simultaneously, critical path analysis identifies bottleneck steps that affect overall execution efficiency.

[0037] Step S11410: Integrate the target core technology, continuous technical operation steps, execution purpose, start-up conditions and execution logic between steps to form a technical execution path corresponding to the realization requirements of each functional module. The technical execution path is used to describe the entire technical process of realizing the functional module.

[0038] The above elements are integrated into a structured technical execution path document, stored in JSON format, containing fields such as "Technical Path ID," "Target Core Technology," "Operation Step Sequence," "Path Dependencies," and "Performance Indicator Requirements." The "Operation Step Sequence" contains detailed information on all technical operation steps in execution order; the "Path Dependencies" describe the interaction logic with other functional module technical paths; and the "Performance Indicator Requirements" specify constraints such as execution time, resource consumption, and accuracy of the overall path. For example, the "Flood Risk Level Prediction Technology Execution Path" includes time-series data prediction technology, 12 consecutive operation steps, dependencies with the data acquisition path, and a prediction accuracy no less than a set value. During the integration process, the feasibility and efficiency of the path need to be verified using process simulation tools to ensure that the technical execution path meets the functional module implementation requirements.

[0039] Step S115: Extract relevant expressions related to the application environment from the description of the requirements for the artificial intelligence application scenario, and form a set of application environment-related expressions. The set of application environment-related expressions includes various requirements of users for the operating environment of artificial intelligence applications.

[0040] A text classification model is used to identify themes in the requirement description text, filtering out expressions related to the application environment. For example, expressions such as "the system needs to operate 24 / 7," "supports data transmission in complex network environments," "adapts to different climate conditions in different urban areas," and "possesses electromagnetic interference protection capabilities" are extracted from the requirement description. These expressions are then categorized according to environment type (e.g., physical environment, network environment, security environment) to form a set of application environment-related expressions. This set uses a list structure, with each element containing "environment type," "expression content," and "importance level" fields. The importance level is calculated using a term frequency-inverse document frequency algorithm and used for prioritizing subsequent environmental requirements.

[0041] Step S116: Based on the set of application environment-related descriptions, determine the type of operating carrier and the operating environment limitations for the requirements of artificial intelligence application scenarios. The type of operating carrier is the category of hardware or software platform that carries the artificial intelligence application, and the operating environment limitations are the environmental conditions required for the execution of the artificial intelligence application functions.

[0042] Semantic parsing is performed on the set of descriptions related to the application environment to extract key information related to hardware and software. Regarding the type of operating platform, the hardware platform category is determined based on functional requirements. For example, the data acquisition layer uses IoT sensor nodes, the data processing layer uses edge computing gateways and cloud server clusters, and the application interaction layer uses command center workstations and mobile terminals. Software platform categories include operating systems (such as embedded real-time operating systems and server operating systems), database systems (such as time-series databases and relational databases), and middleware (such as message queues and service registration centers). Operating environment constraints include physical environment (such as temperature range, humidity range, and dustproof level), network environment (such as network bandwidth, communication protocols, and routing policies), security environment (such as access control policies, data encryption standards, and intrusion detection mechanisms), and power environment (such as power supply method and backup power configuration). During the determination process, industry standards (such as GB / T2887-2011 "General Specifications for Computer Sites") should be referenced to ensure the rationality and feasibility of the environmental constraints.

[0043] Step S117: Extract relevant expressions involving user operations from the description of the requirements of the artificial intelligence application scenario to form a set of user operation-related expressions. The set of user operation-related expressions includes various operation descriptions of user interaction with the artificial intelligence application.

[0044] By employing named entity recognition and event extraction technologies, user operation-related statements are extracted from the requirement description text. For example, statements such as "commanders issue dispatch instructions via touchscreen," "the system automatically pushes early warning information to mobile devices," "supports voice control for querying device status," and "provides data export and report generation functions" are extracted. These statements are then categorized by operation type (e.g., input, output, control, and query operations) to form a set of user operation-related statements. This set uses a dictionary structure, with the key being the operation type and the value being a list containing specific operation descriptions. Each operation description includes sub-items such as "user role," "operation object," "operation method," and "expected feedback," used for constructing subsequent interaction execution sequences.

[0045] Step S118: Generate an interactive execution sequence for the requirements of artificial intelligence application scenarios based on the set of user operation-related expressions, wherein the interactive execution sequence includes the connection order between user operations and artificial intelligence application responses.

[0046] An interactive execution sequence is constructed using a state machine model, abstracting user operations and system responses into state transition events. First, an initial state (e.g., system ready) and a final state (e.g., operation completed) are defined. Then, state transition rules are designed based on the sequence and dependencies of the operations. For example, the "flood warning interaction sequence" includes: user logs into the system (state: not logged in → logged in) → selects a warning area (state: logged in → area selected) → triggers warning analysis (state: area selected → analysis in progress) → the system displays the warning results (state: analysis in progress → results displayed) → user confirms the warning information (state: results displayed → operation completed). Each state transition includes elements such as a triggering event (user operation or system event), a preceding state, a following state, an execution action, and a response content. The sequence is visualized using a UML state diagram, and an executable process definition file (e.g., a BPMN file) is generated.

[0047] Step S119: Based on the functional module implementation requirements and the interaction execution sequence, deduce the extended requirement direction, which is the additional functional requirements and scenario expansion requirements in addition to the core functional requirements.

[0048] By analyzing the correlation between functional module requirements and interaction execution sequences using association rule mining algorithms, potential functional expansion points can be identified. For example, in the "emergency drainage equipment scheduling" module, users frequently query the current location and status of equipment, leading to the derivation of an additional functional requirement for "real-time equipment location and status monitoring." Similarly, from multi-department collaborative interaction scenarios, an additional functional requirement for "cross-departmental data sharing and access control" can be derived. Scenario expansion requirements are derived by analyzing the adaptability of core functions under different emergency situations (such as rainstorms, floods, and typhoons), for example, extending the urban flooding early warning function to the "urban geological disaster monitoring" scenario. Extended requirements should include "requirement description," "relevance to core functions," and "implementation difficulty assessment," and should be prioritized using a priority matrix.

[0049] Step S1110: Integrate the functional module implementation requirements, technical execution paths, operating platform requirements, interactive execution sequences, and extended requirement directions to generate a requirement scenario deduction knowledge block. Each component in the requirement scenario deduction knowledge block contains a corresponding technical description and execution specification.

[0050] Construct an ontology model for knowledge blocks that deduce demand scenarios, using each component as a core concept of the ontology and defining the attribute relationships between concepts (e.g., "functional module implementation requirements" includes "technical execution path"). The technical description must detail the technical principles, implementation methods, and key parameters of each component, such as the input / output interface definitions of functional modules, the step-by-step sequence diagram of the technical execution path, and the hardware configuration list of the runtime environment. Execution specifications include operational process specifications (e.g., data acquisition frequency, model update cycle), quality control specifications (e.g., data accuracy standards, system response time requirements), and security management specifications (e.g., user permission allocation, data backup strategies). Knowledge blocks are stored in RDF format, supporting semantic querying and reasoning, and generating visual documents (e.g., architecture design diagrams, process sequence diagrams) to ensure that technical personnel can accurately understand and apply them.

[0051] Step S120: Perform scenario-based capability mapping on the promotion resources of the marketing platform to generate a resource scenario mapping set. The resource scenario mapping set includes the functional implementation form of the promotion resources, the scope of scenario adaptation, the linkage execution path, and the capability expansion boundary.

[0052] In urban emergency safety management scenarios, the promotional resources of the marketing platform include hardware equipment (such as water level sensors and video surveillance cameras), software systems (such as data acquisition platforms and predictive analysis software), algorithm models (such as water level prediction models and risk assessment models), and data services (such as meteorological data APIs and geographic information services). The scenario-based capability mapping process includes: first, functional analysis of each promotional resource to determine its core functions and technical characteristics; then, considering the needs of urban emergency safety management scenarios, evaluating the resource's functional implementation (such as sensor installation methods and software deployment modes); next, analyzing the resource's adaptability to different emergency scenarios (such as flooding, fire, and earthquakes) to determine the scenario adaptability range; then, designing the linkage execution path between the resource and other related resources (such as the data flow path of sensor data → data platform → analysis model → decision support system); and finally, based on the resource's technical architecture and scalability, clarifying the capability expansion boundaries (such as the upper limit of the number of sensors supported for access and the data scale that the model can process). The mapping results are stored according to resource type, forming a resource scenario mapping set. Each resource entry includes "resource identifier", "function implementation form description", "scenario adaptation scope list", "linkage execution path diagram", and "capability expansion boundary parameters".

[0053] Step S130: Perform a collaborative adaptation operation on the demand scenario deduction knowledge block and the resource scenario mapping set to generate a scenario collaborative adaptation scheme. The scenario collaborative adaptation scheme includes the docking nodes of the knowledge block and the set, the execution order, and the collaborative operation process.

[0054] The collaborative adaptation process first establishes a mapping relationship between requirements and resources. A semantic matching algorithm matches the functional module implementation needs in the requirement scenario derivation knowledge block with the promotional resources in the resource scenario mapping set, identifying potential interface nodes. Next, the logical dependencies and temporal relationships between interface nodes are analyzed to determine the execution order; for example, data acquisition resources must be executed before data analysis resources. Then, the collaborative operation process is designed, defining the data interaction methods between nodes (e.g., synchronous calls, asynchronous messages), communication protocols (e.g., HTTP, MQTT), data formats (e.g., JSON, Protobuf), and exception handling mechanisms (e.g., retry strategies, degradation schemes). Finally, the feasibility of the collaborative adaptation scheme is verified through process simulation, optimizing resource allocation and scheduling strategies between nodes to ensure the overall efficiency and reliability of the process. The generated scenario collaborative adaptation scheme includes an interface node list, execution sequence diagram, collaborative operation flowchart, resource configuration parameters, etc.

[0055] Step S131: Extract the implementation requirements and technical execution paths of all functional modules in the demand scenario deduction knowledge block, and organize them into a demand-side functional execution directory according to functional categories.

[0056] The functional modules are extracted from the knowledge blocks derived from the demand scenarios, including "module identifiers," "functional action descriptions," "target object descriptions," and corresponding technical execution paths. These are then categorized by function (e.g., data acquisition, data analysis, decision support, interactive display). Each function category contains multiple functional modules, and each module entry includes "basic module information," "technical execution path summary," "performance requirements," and "dependent module list." For example, the data acquisition category includes modules such as "flood-prone area water level monitoring" and "meteorological data acquisition." The technical execution path summary for each module describes the key steps and core technologies. The demand-side functional execution directory is organized hierarchically, supporting queries and filtering by function category, priority, and dependencies.

[0057] Step S132: Extract all functional implementation forms and linkage execution paths from the resource scenario mapping set, and organize them into a resource-side function undertaking directory according to capability category.

[0058] The resource scenario mapping set extracts the "functional implementation form description," "linkage execution path diagram," and "capability expansion boundary parameters" of the promotional resources, and categorizes them according to capability types (such as sensing capabilities, computing capabilities, storage capabilities, and interaction capabilities). Each capability category contains multiple resource entries, and each entry includes "basic resource information," "functional implementation form details," "linkage execution path description," and "capability indicator parameters." For example, the sensing capability category includes resources such as "ultrasonic water level sensor" and "video surveillance camera," with the functional implementation form details describing the sensor's installation method, data acquisition frequency, etc. The resource-side function acceptance directory adopts a hierarchical structure corresponding to the demand-side function execution directory, facilitating matching and comparison between the two parties. It also indicates the resource's availability status (such as in stock, reserved, under maintenance) and service terms (such as rental period and technical support scope).

[0059] Step S133: Compare the implementation requirements of each functional module in the demand-side function execution catalog with the functional implementation form in the resource-side function undertaking catalog one by one, and determine the corresponding functional docking nodes. Each functional docking node includes the functional requirements of the demand side and the capability support of the resource side.

[0060] A bidirectional matching algorithm is employed to compare the "functional action descriptions," "target object descriptions," and "performance indicator requirements" of the functional modules on the demand side with the "functional implementation details" and "capability indicator parameters" of the functional implementation form on the resource side across multiple dimensions. The comparison dimensions include functional matching degree (semantic similarity), performance matching degree (indicator compliance rate), and interface matching degree (data format compatibility). For example, if the functional matching degree of the "real-time water level monitoring module for flood-prone areas" and the "ultrasonic water level sensor" are set, and their performance matching degree (data acquisition frequency, accuracy) meets the requirements, and their interface matching degree (support for the MQTT protocol) conforms to the standard, then they are determined to be functional interface nodes. Each functional interface node generates an interface relationship table, containing "requirement module ID," "resource ID," "matching dimension score," "details of demand-side functional requirements," "details of resource-side capability support," and "interface adaptation instructions," serving as the basic unit for collaborative adaptation.

[0061] Step S134: Extract the interactive execution sequence of the demand scenario deduction knowledge block and the linkage execution path of the resource scenario mapping set, and determine the connection order of all functional docking nodes. The connection order is determined by the logical relationship between the demand execution process and the resource response process.

[0062] For example, step S1341: parse the interactive execution sequence of the demand scenario deduction knowledge block, extract the alternating arrangement pattern of user operation steps and artificial intelligence application response steps in the interactive execution sequence, and mark the user operation steps as demand-side triggering events and the artificial intelligence application response steps as demand-side state transition events according to the alternating arrangement pattern, forming a demand-side execution state sequence.

[0063] The UML state diagram of the interactive execution sequence is analyzed to identify user operation steps (e.g., "selecting a warning area") and system response steps (e.g., "displaying the warning result"), and arranged chronologically to form an event sequence. Based on the step type, user operation steps are marked as demand-side triggered events (e.g., E1: area selection triggered), and system response steps are marked as demand-side state transition events (e.g., S1: area selected state). The demand-side execution state sequence is represented in the form of event-state pairs, for example, [(E1, S0→S1), (E2, S1→S2), ...], where S0 is the initial state, and S1 and S2 are intermediate states. The sequence must label the triggering conditions, associated functional modules, and expected system state for each event.

[0064] Step S1342: Analyze the linkage execution path of the resource scene mapping set, extract the sequential triggering rules of the promotion resource function start-up step and function output step in the linkage execution path, and mark the promotion resource function start-up step as a resource-side trigger instruction and the function output step as a resource-side state ready event according to the sequential triggering rules, forming a resource-side response state sequence.

[0065] The linkage execution path diagram is analyzed to identify the functional startup steps (e.g., "sensor data acquisition startup") and functional output steps (e.g., "data processing completion output") of the promoted resources, and arranged according to causal relationships to form an instruction-event sequence. The functional startup steps are marked as resource-side trigger instructions (e.g., C1: acquisition instruction), and the functional output steps are marked as resource-side state ready events (e.g., R1: data ready state). The resource-side response state sequence is represented in the form of instruction-event pairs, for example, [(C1, R0→R1), (C2, R1→R2), ...], where R0 is the initial state of the resource, and R1 and R2 are the ready states of the resource. The sequence must label the sender of each instruction, the receiving resource, the execution parameters, and the output data content of each event.

[0066] Step S1343: Perform timeline alignment operation on the demand-side execution state sequence and the resource-side response state sequence, with the start time of the demand-side triggering event as the reference point.

[0067] Using the start time of the first demand-side triggered event in the demand-side execution state sequence as the time origin (t=0), a demand-side timeline is constructed based on the event duration and interval. Simultaneously, based on the association between resource-side triggered instructions and demand-side triggered events in the resource-side response state sequence (e.g., a resource instruction is triggered by a demand event), the resource-side sequence is mapped to the demand-side timeline, achieving timeline alignment. Resource response latency must be considered during alignment, and the timestamps of resource-side events are adjusted by adding time offsets. For example, if demand-side triggered event E1 occurs at t=10s, resource-side triggered instruction C1 is triggered by E1, and the resource response latency is 5s, then the execution time of C1 is t=15s. After alignment, a unified event sequence is formed on a unified timeline.

[0068] Step S1344: In the time-aligned sequence, identify the matching relationship between the resource-side ready event in the resource-side response state sequence and the activation conditions of the subsequent demand-side triggering event in the demand-side execution state sequence. Based on the matching relationship, determine the subsequent demand-side triggering event served by each resource-side ready event, and bind the resource-side ready event and the demand-side triggering event it serves as a coordination point.

[0069] Analyze the timeline-aligned joint event sequence to extract the activation conditions of demand-side triggered events (e.g., "requires regional water level data") and the output data of resource-side ready events (e.g., "regional water level data is ready"). Through semantic matching and data requirement matching, determine whether the resource-side ready event satisfies the activation conditions of subsequent demand-side triggered events. If so, bind the two as a coordination point. For example, if the resource-side ready event R1 (water level data ready) satisfies the activation condition of the demand-side triggered event E2 (risk assessment triggered), then bind the coordination point (R1, E2). Each coordination point records information such as resource event ID, demand event ID, data matching item, and time difference.

[0070] Step S1345: For each coordination point, analyze the preceding demand-side state transition event on which the resource-side triggering instruction that generates the resource-side state ready event depends. Locate the preceding demand-side state transition event in the demand-side execution state sequence and determine which demand-side triggering event caused the preceding demand-side state transition event.

[0071] For the collaboration point (Ri, Ej), trace the generation source of the resource-side state ready event Ri, that is, the corresponding resource-side trigger instruction Ci. Analyze the trigger condition of Ci, and determine the pre-requisite demand-side state transition event Sx it depends on (such as the "area selected" state). Locate Sx in the execution state sequence on the demand side, and find the demand-side trigger event Ex that causes Sx (such as the "select warning area" event). Thus, an event dependency chain is established: Ex→Sx→Ci→Ri→Ej, that is, the demand-side trigger event Ex causes the state transition event Sx, Sx triggers the resource-side instruction Ci, Ri is generated after Ci is executed, and Ri satisfies the start condition of Ej.

[0072] Step S1346: Arrange the demand-side trigger event that causes the pre-requisite demand-side state transition event, the pre-requisite demand-side state transition event, the resource-side trigger instruction, the resource-side state ready event, and the demand-side trigger event served by the resource-side state ready event into an event dependency chain according to the time dependency relationship.

[0073] According to the sequence aligned on the time axis, the above events are arranged into an event dependency chain in the order of occurrence time. For example, the event dependency chain is: Ex (t1)→Sx (t2)→Ci (t3)→Ri (t4)→Ej (t5), where t1<t2<t3<t4<t5. Each event in the chain needs to be marked with its type, timestamp, associated functional module / resource and data flow direction, to clearly show the causal relationship and time sequence of events on the demand side and the resource side.

[0074] Step S1347: In the event dependency chain, extract the functional implementation form corresponding to the resource-side trigger instruction, and the functional module implementation requirement corresponding to the demand-side trigger event served by the resource-side state ready event.

[0075] Extract the functional implementation form (such as "data collection function of ultrasonic water level sensor") from the promotion resource associated with the resource-side trigger instruction Ci; extract the functional module implementation requirement (such as "waterlogging risk level prediction functional module") from the functional module associated with the demand-side trigger event Ej. Take the two as key attributes of the event dependency chain, and establish a corresponding relationship between the functional implementation form and the functional module implementation requirement.

[0076] Step S1348: Pair the functional implementation form with the functional module implementation requirement, and the pairing result forms a front-rear dependency relationship of a functional docking node, wherein the front-rear dependency relationship includes the pre-event chain required by the functional docking node.

[0077] The implementation form of functions is paired with the requirements of functional modules to form the dependencies between functional docking nodes. For example, the "data acquisition function of ultrasonic water level sensor" is paired with the "urban flood risk level prediction function module". The dependency relationship is as follows: the activation of this function docking node depends on the preceding event chain Ex→Sx→Ci→Ri. That is, the risk level prediction function module can only be activated after the preceding events such as area selection, sensor acquisition command issuance, and data readiness are completed. The dependencies need to be stored in a structured form, including fields such as "Docking Node ID", "Preceding Event Chain", and "Dependency Conditions".

[0078] Step S1349: Repeat the process of extracting the event dependency chain and matching the dependencies of the functional docking nodes for all collaboration points to generate a set of dependencies of all functional docking nodes.

[0079] Traverse all collaboration points, extract event dependency chains according to the steps above, and pair the preceding and following dependencies of functional docking nodes to form a set of preceding and following dependencies. This set contains the dependency information of all functional docking nodes, which is used to determine the subsequent connection order.

[0080] Step S13410: Based on the chain of preceding events required for each functional docking node in the set of preceding and following dependencies, sort all functional docking nodes topologically according to the order in which the events occur; the result of the topological sorting generates an execution order list of functional docking nodes, in which the preceding events required for the start-up conditions of any functional docking node in the execution order list have been triggered during the execution of the nodes preceding it.

[0081] A directed graph of functional nodes is constructed based on a set of dependencies. Nodes represent functional nodes, and directed edges represent dependencies between nodes (e.g., A→B means B depends on A). A topological sorting algorithm (such as Kahn's algorithm) is used to sort the directed graph, generating a list of the execution order of the functional nodes. During the sorting process, it must be ensured that all preceding dependent nodes of each node appear before it; for example, data acquisition nodes are placed before data analysis nodes, and data analysis nodes are placed before decision support nodes.

[0082] Step S13411: Verify the feasibility of the execution order list. The verification process involves simulating the sequential startup of functional docking nodes according to the execution order list, checking whether the startup conditions of each functional docking node can be met. If the startup conditions of a functional docking node cannot be met, the preceding event chain of that functional docking node is traced back, the triggering timing of the corresponding resource-side triggering instruction in the resource-side response state sequence or the waiting time of the corresponding demand-side triggering event in the demand-side execution state sequence is adjusted, and the topology is re-sorted to generate a revised execution order list.

[0083] Construct an execution simulation model to simulate the startup process of functional docking nodes according to the execution order list. For each node, check whether all events in its preceding event chain have been completed and whether the startup conditions are met (e.g., whether data is ready and resources are available). If a node's startup conditions are not met (e.g., preceding data is not ready), backtrack its preceding event chain, analyze the cause of delay (e.g., slow resource response), and adjust the triggering timing of relevant resource-side triggering instructions (e.g., issuing instructions earlier) or the waiting time of demand-side triggering events (e.g., extending the waiting time). After adjustment, re-sort the topology until the startup conditions of all nodes are met, generating the final execution order list.

[0084] Step S13412: Determine the connection order of all functional docking nodes from the verified or revised execution order list.

[0085] The execution order list, verified through simulation, serves as the connection order for functional integration nodes. This order clearly defines the execution sequence of each node. The connection order is stored in list form, containing information such as node ID, execution sequence number, a list of preceding node IDs, and estimated execution time.

[0086] Step S135: Extract the technical execution path, operating platform requirements, and scenario adaptation range corresponding to the implementation requirements of each functional module, integrate them into the corresponding functional docking nodes, and form the execution conditions and operation standards of each functional docking node.

[0087] Extract the technical execution path (such as step sequence and core algorithm) and runtime requirements (such as hardware configuration and software environment) for the functional modules to achieve their objectives from the knowledge blocks derived from the demand scenarios. Extract the scenario adaptability range (such as applicable scenario type and environmental constraints) for the functional implementation form from the resource scenario mapping set. Integrate the above information into the corresponding functional docking nodes to form execution conditions and operational standards. Execution conditions include the conditions required to start the technical execution path (such as data input requirements and resource configuration requirements) and the environmental limitations of the runtime (such as temperature and humidity range). Operational standards include the performance indicators of the technical execution path (such as execution time and accuracy) and the scenario adaptability requirements of the functional implementation form (such as monitoring range and response speed). The execution conditions and operational standards of each functional docking node need to be quantitatively described, for example, "Execution conditions: input data sampling frequency ≥ set value, CPU utilization ≤ set value; Operational standards: data processing latency ≤ set duration, prediction accuracy ≥ set ratio."

[0088] Step S136: Analyze the operational relationships between all functional docking nodes and generate a collaborative operation process between nodes. The collaborative operation process includes the information transmission format between nodes, response trigger signals, and result feedback paths.

[0089] Step S1361: Extract the input data format and output data format of each functional interface node, and determine the data interaction requirements between nodes. The data interaction requirements include the content requirements and format requirements for data transmission.

[0090] Analyze the technical execution path of each functional interface node to determine its input data format (e.g., data type, structure, dimensions) and output data format (e.g., data format, precision, range). For example, the output data format of the "data acquisition node" is "time-series water level data, JSON format, including timestamp, location coordinates, and water level value fields," and the input data format of the "data analysis node" must match this. Based on the input and output data formats, determine the data interaction requirements between nodes: content requirements include data fields, data volume, and update frequency; format requirements include data encoding method, protocol type, and compression algorithm. Data interaction requirements are defined in the form of an interface specification document to ensure consistency of data transmission between nodes.

[0091] Step S1362: Determine the data transmission format between nodes based on data interaction requirements. The data transmission format is the specific implementation method of transmitting data from one functional interface node to another functional interface node.

[0092] Based on the content and format requirements of the data interaction needs, and considering the deployment location of the nodes (e.g., local, cloud) and the network environment, the data transmission format is determined. Transmission formats include synchronous transmission (e.g., REST API calls) and asynchronous transmission (e.g., message queues), real-time transmission (e.g., WebSocket) and batch transmission (e.g., FTP), and wired transmission (e.g., Ethernet) and wireless transmission (e.g., 5G). For example, small-volume real-time transmission between nearby nodes uses the WebSocket protocol, while large-volume batch transmission between distant nodes uses the FTP protocol. The transmission format must specify parameters such as the transmission protocol, interface address, port number, and timeout settings.

[0093] Step S1363: Extract the feature signal generated by each functional docking node after completing its own function execution, and use the feature signal as the start trigger signal for the next functional docking node.

[0094] After a functional node completes its function execution, it generates a characteristic signal based on the execution result. For example, a "successful execution signal" (status code: 0000) is generated upon successful completion, and a "failed execution signal" (status code: 1001) is generated upon an exception, containing the error code and description information. This characteristic signal serves as the trigger signal for the next node. For instance, after the "data acquisition node" successfully acquires data, it generates a "data ready signal," triggering the start of the "data analysis node." The trigger signal must include information such as signal type, generation time, and associated data identifier, and is transmitted via the event bus.

[0095] Step S1364: Execute the verification process for the start trigger signal, and confirm the transmission accuracy and execution reliability of the start trigger signal through a preset technical detection sequence.

[0096] After the trigger signal is generated, it must undergo a verification process to ensure its accuracy and reliability. The verification process includes signal format verification (such as checksum verification), content integrity checks (such as verification of required fields), and sender authentication (such as digital signature verification). For example, a cyclic redundancy check algorithm is used to verify the integrity of the signal data, and a public-key cryptography system is used to verify the sender's identity. If verification fails, a signal retransmission mechanism is triggered (such as a maximum set number of retransmissions), and an error log is logged. The verification process is executed by a separate signal verification module to ensure the quality of the trigger signal.

[0097] Step S1365: Plan the result feedback path between nodes, wherein the result feedback path is the specific path by which the subsequent functional docking node transmits the execution result to the previous functional docking node or the request initiating end.

[0098] Based on business needs, plan the feedback path, determining the feedback direction (e.g., one-way or two-way feedback), timing (e.g., real-time or phased feedback), and content (e.g., execution status, result data, and anomaly information). For example, the "data analysis node" feeds back analysis results to the "decision support node" in real time, while simultaneously feeding back the execution status to the "data acquisition node." The feedback path needs to define the transmission protocol, feedback interface, and data format to ensure that feedback information can be accurately and promptly delivered to the target node.

[0099] Step S1366: Adjust the data transmission format of the result feedback path to make the data transmission format of the feedback data consistent with the data transmission format between nodes.

[0100] To ensure data transmission consistency and compatibility, the data transmission format of the result feedback path must be consistent with that of the main data transmission between nodes. For example, if the main data transmission uses a REST API call in JSON format, the feedback data should also use the same format and protocol. If the feedback data volume is large, the same compression algorithm and chunked transmission strategy as the main data transmission can be used. Compatibility testing is required during the adjustment process to ensure that the feedback data can be correctly parsed by the receiving nodes.

[0101] Step S1367: Determine the time node for result feedback. The time node is the specific moment when the result feedback is initiated immediately after the next functional docking node completes its own function execution.

[0102] Based on the time characteristics of function execution and business requirements, determine the time nodes for result feedback. For scenarios with high real-time requirements, adopt a "feedback immediately upon completion" mechanism; for non-real-time scenarios, a "timed batch feedback" mechanism can be used. For example, the "emergency dispatch node" needs to provide feedback immediately after generating the dispatch plan, while the "log recording node" can provide batch feedback of log data once per hour. The triggering conditions (such as the execution status code changing to "completed") and delay thresholds (such as the delay after execution completion not exceeding the set duration) must be clearly defined for each time node.

[0103] Step S1368: Construct a sequence of corresponding processing steps based on possible abnormal data interaction states between nodes. The abnormal data interaction states include data transmission interruption, data format error, data loss, and data transmission delay.

[0104] For example, step S1368-1: Extract possible abnormal data interaction states between functional docking nodes, including data transmission interruption, data format error, data loss and data transmission delay.

[0105] Failure Mode and Effects Analysis (FMEA) is used to identify potential abnormal states during data interaction between nodes. These include: data transmission interruption (unexpected connection loss during transmission); data format error (data received does not conform to interface specifications); data loss (partial data not received); and data transmission delay (transmission time exceeding a set threshold). Each abnormal state is categorized and coded (e.g., E01: transmission interruption, E02: format error), and its characteristics and potential impacts are described.

[0106] Step S1368-2: For data transmission interruption status, construct a data retransmission step sequence, which includes specific steps for interruption detection, interruption location, data fragment identification, and retransmission.

[0107] The data retransmission sequence includes: interruption detection (detecting connection interruption via heartbeat timeout mechanism) → interruption location (recording the offset of transmitted data) → data fragment identification (determining untransmitted data fragments based on offset) → retransmission (establishing a new connection and transmitting the incomplete fragments) → integrity verification (the receiver verifies data integrity). Each step includes execution conditions, operation logic, and timeout handling mechanisms. For example, the interruption detection step sends a heartbeat packet every set time interval; if no response is received after a set number of consecutive steps, it is determined to be an interruption.

[0108] Step S1368-3: For data format error states, construct a data format correction step sequence, which includes specific steps for format verification, error location identification, application of format conversion rules, and verification of corrected data.

[0109] The data format correction steps include: format validation (performing JSONSchema validation on the received data) → error location identification (locating fields or values ​​that do not meet the format requirements) → application of format conversion rules (converting data types or formats according to preset rules, such as converting string numbers to numeric types) → validation of corrected data (re-executing format validation). If the correction fails, the sender is returned with details of the format error, requesting a resend of the correctly formatted data.

[0110] Step S1368-4: For data loss, construct a data recovery step sequence, which includes specific steps for identifying lost data, retrieving backup data, verifying data integrity, and supplementing missing parts.

[0111] The data recovery sequence includes: identifying missing data blocks (detecting missing data blocks using data sequence numbers) → retrieving backup data (retrieving backups of the corresponding data blocks from local cache or standby storage) → verifying data integrity (verifying the hash value of the backup data) → filling in missing parts (inserting the backup data into the correct position). If the backup data is unavailable, a request is made to the sender to retransmit the lost data blocks.

[0112] Step S1368-5: For the data transmission delay status, construct a delay response step sequence, which includes specific steps for delay detection, priority adjustment, transmission channel switching, and delay data processing.

[0113] The delay handling sequence includes: delay detection (monitoring data transmission time and comparing it with a set threshold) → priority adjustment (marking delayed data as high priority) → transmission channel switching (switching to a backup high-speed transmission channel) → delayed data processing (prioritizing delayed data upon receipt to compensate for the time difference). Delay events are also recorded for subsequent analysis of transmission bottlenecks.

[0114] Step S1368-6: Analyze the possible causes of abnormal data interaction states, including network fluctuations, interface incompatibility, excessive resource consumption, and signal interference, and construct corresponding troubleshooting steps for each cause.

[0115] To address network fluctuations, the troubleshooting steps include: detecting network bandwidth fluctuations, checking router and switch logs, and testing network packet loss rate. For interface incompatibility, the steps include: checking interface version numbers, comparing the sender and receiver interface documentation, and verifying data field mapping relationships. For excessive resource consumption, the steps include: monitoring CPU and memory usage, checking process scheduling, and analyzing data transmission queue length. For signal interference (in wireless transmission scenarios), the steps include: detecting signal strength, scanning for interference sources, and adjusting the transmission frequency. Each troubleshooting step must clearly define the operating tools, detection indicators, and judgment criteria.

[0116] Step S1368-7: Based on the results of the troubleshooting steps, construct targeted problem-solving operations, which include network parameter adjustment, interface adaptation optimization, resource allocation adjustment, and application of anti-interference measures.

[0117] Based on the investigation results, take the following corrective actions: Adjust the TCP window size and enable QoS flow control when there are network fluctuations; update the interface driver and adjust data field mapping rules when interfaces are incompatible; optimize process priority and increase server resources when resource consumption is excessive; use frequency hopping technology and increase signal transmission power when there is signal interference. Each corrective action must include specific parameter adjustment values, operational steps, and verification methods.

[0118] Step S1368-8: Determine the start time of the processing step sequence, wherein the start time is the instant when the abnormal state of data interaction is detected.

[0119] The real-time monitoring module continuously monitors the data interaction status. Once an abnormal state is detected (such as a data format error), the corresponding processing steps are immediately triggered. The start time is accurate to the millisecond, and the timestamp of the abnormal occurrence is recorded for subsequent problem tracing and performance analysis.

[0120] Step S1368-9: Plan the information notification path during the execution of the processing step sequence, which is used to transmit information about the occurrence of anomalies and the processing progress to relevant functional docking nodes and the request initiating end.

[0121] The information notification path includes internal notifications (at relevant function integration nodes) and external notifications (at the request initiator). Internal notifications send exception codes and processing status via the event bus; external notifications display exception information (such as "Data transmission interrupted, attempting to retransmit") to users through the platform message center. The notification content includes the exception type, occurrence time, processing progress, and estimated recovery time, ensuring that relevant parties are informed of the situation in a timely manner.

[0122] Step S1368-10: Construct an interactive recovery step sequence after the execution of the processing step sequence. The interactive recovery step sequence includes specific steps for verifying the abnormal handling result, resetting the transmission status, and synchronizing the functional docking nodes. Integrate all processing step sequences, troubleshooting steps, problem-solving operations, start times, information notification paths, and interactive recovery step sequences to generate the corresponding processing step sequence.

[0123] The interaction recovery step sequence includes: anomaly handling result verification (checking whether the anomaly has been resolved, such as whether the retransmitted data is complete) → transmission status reset (restoring the node interaction status to normal) → functional node synchronization (notifying relevant nodes to resume normal interaction). Integrating the above processing step sequence, troubleshooting steps, problem-solving operations, startup time, information notification path, and interaction recovery step sequence forms a complete anomaly handling process. Each anomaly state corresponds to a processing step sequence, stored in the anomaly handling rule base.

[0124] Step S1369: Determine the execution entity of the processing step sequence, wherein the execution entity is the functional docking node responsible for executing the data interaction exception handling steps.

[0125] The executing entity is determined based on the anomaly type and node responsibilities: data transmission-related anomalies are handled by the transmission control node; data format-related anomalies are handled by the data parsing node; and resource-related anomalies are handled by the resource management node. The executing entity must possess the corresponding processing capabilities (such as a data retransmission module or format conversion tool) and have permission to operate the relevant resources. The executing entity information includes the node ID, a list of processing capabilities, and the permission level, and is stored in the node management directory.

[0126] Step S13610: Integrate data transmission format, start trigger signal, verification process, result feedback path, feedback time node, processing step sequence and execution subject to form a collaborative operation process between nodes. The collaborative operation process is used to define the interaction process between functional docking nodes.

[0127] The above elements are integrated into a collaborative operation process model, and a flowchart is drawn using the BPMN 2.0 specification to clearly define the data flow, control flow, and exception handling paths between nodes. The process model includes elements such as activities (node ​​operations), gateways (conditional judgments), events (triggering and termination), and swimlanes (executing entities), labeling the inputs and outputs, execution rules, and exception handling relationships for each activity. The collaborative operation process needs to be verified for its correctness and efficiency using process simulation tools to ensure smooth and reliable interaction between nodes.

[0128] Step S137: Based on the functional docking nodes, connection sequence, execution conditions, operation standards and collaborative operation process, generate an initial collaborative adaptation association structure, which includes the basic docking logic of requirements and resources.

[0129] The functional interface nodes are arranged in a sequential order, and a network of connections between requirements and resources is constructed by combining execution conditions and operational standards. The initial collaborative adaptation connection structure adopts a directed graph data structure, where nodes represent functional interface nodes and edges represent the collaborative operation process between nodes (including data transmission methods, trigger signals, etc.). The graph also needs to label the execution conditions (such as resource configuration requirements) and operational standards (such as performance indicators) of the nodes, forming the basic interface logic between requirements and resources. This structure must satisfy the matching relationship between the functional execution directory on the requirement side and the functional acceptance directory on the resource side.

[0130] Step S138: Extract the extended requirement direction of the requirement scenario deduction knowledge block and the capability extension boundary of the resource scenario mapping set, supplement the extended function docking nodes and extended collaborative operation process, and integrate them into the initial collaborative adaptation association structure.

[0131] Extract extended requirement directions (such as additional functional requirements and scenario expansion requirements) from the knowledge blocks derived from the requirement scenarios. Extract the capability expansion boundaries of promotional resources (such as the maximum number of supported access devices and scalable algorithm modules) from the resource scenario mapping set. Add extended function docking nodes (such as "device location monitoring nodes") according to the extended requirement directions, and design extended collaborative operation processes (such as data interaction paths between new nodes and existing nodes) according to the resource capability expansion boundaries. Integrate the extended function docking nodes and extended collaborative operation processes into the initial collaborative adaptation association structure, update the dependencies and execution order between nodes, and ensure that the expanded structure can meet the extended requirements.

[0132] Step S139: Adjust the node connection process, information transmission format and response trigger signal in the initial collaborative adaptation association structure.

[0133] Based on the integration of extended functionality nodes and actual business needs, the initial collaborative adaptation structure was adjusted: the node connection process was optimized, eliminating redundant steps (such as merging similar data preprocessing steps); the information transmission format was adjusted, adopting a more efficient protocol (such as replacing HTTP with gRPC); and the response trigger signals were optimized, shortening signal transmission latency (such as adopting an event-driven architecture). Performance testing was conducted during the adjustment process, comparing metrics such as process execution time and resource utilization before and after the adjustment to ensure that the adjusted structure was superior.

[0134] Step S1310: Integrate and optimize the functional docking nodes, connection sequence, execution conditions, operation standards, collaborative operation process, extended functional docking nodes and extended collaborative operation process to form a scenario collaborative adaptation scheme. The scenario collaborative adaptation scheme is used to present the entire interaction process between the demand scenario deduction knowledge block and the resource scenario mapping set.

[0135] Integrate the above optimized elements into a scenario collaborative adaptation solution, which includes a solution overview, a list of function docking nodes, a connection sequence timing diagram, a collaborative operation flowchart, execution conditions and standard descriptions, extended requirement expansion descriptions, and other contents. The solution shall adopt a combination of visual charts (such as architecture diagrams, timing diagrams, flowcharts) and text descriptions to clearly present the entire interaction process between requirements and resources, including data flow direction, control logic, exception handling, expansion mechanisms, and the like. The solution shall pass expert review and simulation verification to ensure its technical feasibility and business applicability.

[0136] Step S140: Screen promotion resources in the market promotion platform that can undertake the docking nodes and the collaborative operation process based on the scenario collaborative adaptation solution, so as to form a scenario requirement adaptation resource list.

[0137] Screen in the promotion resource library of the market promotion platform according to the function docking node requirements (such as function, performance, interface) and the collaborative operation process requirements (such as data transmission, linkage execution) in the scenario collaborative adaptation solution. First, screen out candidate resources according to the function implementation form and capability indicators of the function docking nodes; then verify whether the candidate resources meet the requirements of the collaborative operation process (such as interface compatibility, data transmission performance); then evaluate the availability and cost of the resources; finally, sort the resources by priority to form the scenario requirement adaptation resource list. The list includes basic resource information, function docking node matching status, collaborative operation process adaptability assessment, resource cost and availability status, and other contents.

[0138] Step S141: Parse all function docking nodes and extended function docking nodes in the scenario collaborative adaptation solution, extract the function support type and capability support requirement of each node, and form a node support requirement set.

[0139] Parse the function docking nodes and extended function docking nodes in the scenario collaborative adaptation solution, and extract the function support type (such as data collection, data analysis, decision support) and capability support requirement (such as performance indicator, interface specification, resource configuration) of each node. The function support type is determined according to the role of the node in the collaborative process, and the capability support requirement includes technical parameters (such as data collection frequency, model inference latency), interface requirements (such as communication protocol, data format), and environmental requirements (such as operating temperature, power supply mode). The above information is organized into the node support requirement set, and each node entry includes fields such as "Node ID", "Function Support Type", "Capability Support Requirement Details", and "Priority", which are used as the matching basis for resource screening.

[0140] Step S142: Extract the function implementation form and capability expansion boundary of all promotion resources in the market promotion platform, and organize them by resource category to form a platform resource capability catalog.

[0141] Information on all promotional resources is extracted from the resource management system of the marketing platform, including the functional implementation form (e.g., "intelligent water level sensor, supports 4G transmission, IP68 protection level") and capability expansion boundaries (e.g., "supports up to 1000 concurrent connections, expandable to include AI analysis modules"). Resources are categorized and organized by type (e.g., hardware devices, software systems, algorithm models, data services) to form a platform resource capability catalog. Each resource entry includes "Resource ID," "Resource Name," "Description of Functional Implementation Form," "Capability Indicator Parameters," "Capability Expansion Boundary Description," "Supplier Information," and "Pricing Information." The catalog supports searching and filtering by functional support type, capability indicators, and other dimensions.

[0142] Step S143: Compare each promotional resource in the platform resource capability catalog with the corresponding requirements in the node support requirement set, and select candidate promotional resources that can meet the functional support type and capability support requirements of a single functional docking node.

[0143] A multi-dimensional matching algorithm is employed to semantically match the functional implementation form of promotional resources with the functional support type of nodes, and numerically match the capability index parameters of resources with the capability support requirements of nodes. For example, if a node requires "data collection frequency ≥ set value", and the resource's collection frequency is the set value + 1, then the numerical match passes. For each functional interface node, all promotional resources that meet the matching conditions are selected as candidate promotional resources. The matching results include fields such as "node ID", "resource ID", "functional matching degree", "capability matching degree", and "overall score". The overall score is calculated by weighting the functional matching degree and the capability matching degree.

[0144] Step S144: Based on the connection sequence and collaborative operation process of the scenario collaborative adaptation scheme, the candidate promotion resources are combined according to the connection relationship of the functional docking nodes to form multiple resource combination configurations. Each resource combination configuration contains multiple promotion resources that can cover all functional docking nodes.

[0145] Based on the connection sequence of the scenario-based collaborative adaptation scheme, candidate promotion resources belonging to different functional integration nodes are combined. For example, if node 1 has candidate resources A and B, and node 2 has candidate resources C and D, then the combination configurations include (A, C), (A, D), (B, C), (B, D), etc. Each resource combination configuration must cover all functional integration nodes, and the collaborative operation processes between resources must be compatible (e.g., interface matching, consistent data format). During the combination process, conflicting resource combinations (e.g., two resources occupying the same port) must be excluded, generating multiple valid resource combination configurations.

[0146] Step S145: Simulate the execution environment of the scenario collaborative adaptation scheme, configure and deploy each resource combination to the simulation environment, and start the function execution of the promotion resources in the order of connection.

[0147] Step S1451: Build a simulation verification environment that is consistent with the actual operating environment of the marketing platform. The simulation verification environment is consistent with the configuration of the marketing platform in terms of hardware configuration, software version, network bandwidth and data processing capabilities.

[0148] The simulation verification environment is built using virtualization technology, with hardware configurations (such as CPU core count, memory capacity, and GPU model) identical to the market promotion platform. The software environment includes the same versions of the operating system, database, middleware, and AI framework. The network environment is configured using a network simulator with the same bandwidth, latency, and packet loss rate as the actual platform. Data processing capabilities are simulated through resource constraints (such as CPU utilization limits and memory allocation). After the environment is set up, benchmark tests are conducted to ensure that its performance indicators deviate from the actual platform within the set range.

[0149] Step S1452: Deploy all promotional resources in each resource combination configuration to the simulation verification environment according to the requirements of the scenario collaborative adaptation scheme, and establish data interaction interfaces between promotional resources.

[0150] Based on the collaborative operation process in the scenario-based collaborative adaptation solution, deploy promotion resources in a simulated verification environment (e.g., install hardware drivers, deploy software services, load algorithm models). Configure network parameters for the resources (e.g., IP address, port number) and establish data interaction interfaces between resources (e.g., configure API gateway, message queue). After deployment, conduct connectivity tests to ensure that resources can communicate normally and that the interface call success rate reaches or exceeds the set value.

[0151] Step S1453: Start the function execution of promotional resources according to the connection sequence of the scenario collaboration adaptation scheme, and simultaneously start the data recording component to record the interaction process between promotional resources.

[0152] The promotional resources for each functional node are launched sequentially according to the connection order list, and the launch status of the resources (such as process status and service port) is monitored during the launch process. A data logging component is launched simultaneously to record the interaction process between resources, including data transmission time, data content, interface call logs, and resource status changes. The data logging component adopts a distributed log collection architecture to ensure the completeness and accuracy of the records.

[0153] Step S146: Record the interaction process data between promotional resources in each resource combination configuration. The interaction process data includes data transmission time, data format matching records, and function execution connection records.

[0154] Step S1461: Record the initiation and reception times of each data transmission process to form a data transmission time record.

[0155] The data recording component records the initiation time (accurate to milliseconds) when data transmission is initiated and the reception time when data reception is completed. It calculates the transmission time (reception time - initiation time) to form a data transmission time record, which includes fields such as "transmission ID", "source resource ID", "target resource ID", "initiation time", "reception time", and "transmission time".

[0156] Step S1462: Verify the compatibility of the transmitted data format with the preset format and record the data format compatibility record.

[0157] Perform format validation on the received data to verify whether it conforms to the format requirements defined in the interface specification (such as JSONSchema validation, XMLDTD validation). Record the validation results, including "transmission ID", "data format validation result" (pass / fail) and "error details" (such as missing fields, type errors), forming a data format compliance record.

[0158] Step S1463: Monitor the connection status of the promotion resource function execution and record the function execution connection record.

[0159] Monitor the status transitions of the promotion resource function execution (e.g., "Ready → Executing → Completed"), check whether the execution order of the functions meets the requirements of the connection sequence, and whether there are any interruptions or reversals in the execution order. Record information such as "Node ID", "Execution Start Time", "Execution End Time", "Execution Status", and "Execution Status of Preceding Nodes" to form a function execution connection record.

[0160] Step S1464: Integrate data transmission time records, data format matching records, and function execution connection records to form the interaction process data for each resource combination configuration.

[0161] The three types of records mentioned above are linked and integrated based on transmission ID or node ID to form interaction process data. This data is stored in a relational database and includes a transmission details table, a format validation table, and an execution connection table, linked via foreign keys. The interaction process data must support querying and statistics based on resource combination configuration ID, time range, and other dimensions.

[0162] Step S147: Based on the interaction process data, select resource combinations and configurations that meet the preset time standards for data transmission, have a perfect data format, and have continuous function execution.

[0163] Step S1471: Set data transmission time standards, data format compatibility standards, and functional continuity standards.

[0164] The data transmission time standard is "transmission time ≤ set threshold"; the data format compliance standard is "all format verification results pass"; the functional continuity standard is "all nodes execute in the connection sequence without interruption or sequence error". These standard values ​​are determined based on the performance requirements and business needs of the scenario-based collaborative adaptation solution. For example, the data transmission time threshold is set to meet 95% of transmission scenarios.

[0165] Step S1472: Compare the interaction process data of each resource combination configuration with the set standards, filter out the resource combination configurations that have data transmission that meets the preset time standards, data format that is completely compatible, and function execution that is continuous, and form a list of resource combinations that meet the standards.

[0166] Statistical analysis is performed on the interaction process data for each resource combination configuration: the average and maximum data transmission time are calculated to check if they meet the time standards; all data format matching records are checked to ensure they pass; and the execution sequence of function records is verified to meet the requirements. Resource combination configurations that simultaneously meet all three standards are selected to form a list of compliant resource combinations, including fields such as "Combination Configuration ID," "List of Included Resources," "Compliance Status of Each Standard," and "Overall Score."

[0167] Step S148: Verify the promotional resources in the selected resource combination configuration to confirm whether they can undertake the extended function docking nodes and extended collaborative operation process.

[0168] For resource combinations that meet the standards, further examine whether the promotional resources have the capability to support extended function integration nodes (e.g., whether the resource's capability expansion boundaries meet the extension requirements) and whether they support extended collaborative operation processes (e.g., whether they have the ability to add new interfaces and expand data processing capabilities). For example, if the extended function integration node requires resources to support edge computing, check whether the resources have an edge computing module or can be extended to access this module. The confirmation result includes fields such as "whether extended functions are supported," "whether extended processes are supported," and "description of missing capabilities." Only resource combinations that pass the confirmation will proceed to the next step.

[0169] Step S149: Extract the resource combination configuration that can fully support all functional docking nodes, extended functional docking nodes, collaborative operation processes and extended collaborative operation processes, and distinguish the main promotion resources and auxiliary promotion resources in each resource combination configuration.

[0170] From the confirmed resource combination configurations, extract the configurations that can fully support all nodes and processes. Based on the role of resources in the collaborative process, distinguish between primary promotion resources (such as core algorithm models and key hardware equipment) and auxiliary promotion resources (such as data storage services and network transmission components). Primary promotion resources are crucial for implementing core functions, while auxiliary promotion resources are necessary conditions for supporting the operation of primary resources. The distinction results are recorded in the resource combination configuration details for subsequent priority ranking.

[0171] Step S1410: Arrange and integrate all promotional resources according to the functional support priority of the main promotional resources, and supplement the application nodes and execution roles of each promotional resource in the scenario collaboration adaptation scheme to form a scenario requirement adaptation resource list. The scenario requirement adaptation resource list includes the promotional resource name, application node, execution role and collaboration relationship description.

[0172] The resource combinations are sorted according to the functional support priority of the main promotional resources (determined by the module priority in the demand-side function execution catalog). The promotional resources in each configuration are integrated, supplementing their application nodes (corresponding to function interface node IDs) and execution roles (e.g., "execution resources for data acquisition nodes," "support resources for decision support nodes") in the scenario collaboration adaptation solution. Collaboration relationship descriptions illustrate how resources interact with other resources (e.g., "providing raw data to data analysis resources," "receiving and executing scheduling instructions"). Finally, a scenario demand adaptation resource list is formed, presented in tabular form, including resource ID, name, type, application node, execution role, collaboration relationship, priority, supplier, and price information, facilitating user selection and evaluation.

[0173] Step S150: Collect actual application data of users for the promotional resources in the resource list that adapts to the scenario requirements, and adjust the knowledge block dimension of the requirement scenario deduction knowledge block, the mapping attribute of the resource scenario mapping set, and the collaborative logic of the scenario collaborative adaptation scheme based on the actual application data.

[0174] During the process of adapting promotional resources in the resource list to actual user usage scenarios, application data (such as resource usage frequency, function execution efficiency, and user operation records) is collected in real time using data collection tools. This application data is analyzed to identify changes in actual user needs (such as high usage frequency of certain functional modules), resource performance bottlenecks (such as resource response latency), and collaborative process issues (such as poor node connection). Based on the analysis results, the knowledge block dimensions of the demand scenario deduction knowledge block are adjusted (such as increasing the description weight of high-frequency functional modules), the mapping attributes of the resource scenario mapping set are adjusted (such as updating resource capability indicators), and the collaborative logic of the scenario collaborative adaptation scheme is adjusted (such as optimizing the node connection order), achieving dynamic adaptation and continuous optimization of needs and resources.

[0175] Step S151: Deploy a data acquisition component to record in real time the user's operation behavior during the process of promoting resources in the resource list that adapts to usage scenario requirements. The operation behavior record includes the function execution instructions triggered by the user, the order of operations, and the duration of each operation.

[0176] A data acquisition component is deployed in the user interaction interface and function execution module of the promotional resources. This component employs a lightweight design to avoid impacting resource performance. It collects user actions, including triggered function execution commands (such as "start water level prediction" and "generate scheduling plan"), the order of operations (such as selecting a region before performing analysis), and the duration of each operation (such as the time from command issuance to completion). Operation behavior records are stored in a structured log format, containing fields such as "User ID," "Resource ID," "Operation Timestamp," "Function Command," "Operation Sequence Number," "Duration," and "Operation Result," and are stored in the user behavior database.

[0177] Step S152: Collect the running status record of the promotional resources in response to user operation behavior. The running status record includes the function execution result of the promotional resources, the instruction response time and resource usage.

[0178] The operational status of promotional resources is collected through a resource monitoring interface. Function execution results include success / failure status, output data identifiers, and result accuracy (such as the accuracy of a prediction model). Command response time refers to the time from receiving a user command to returning the execution result. Resource usage includes CPU utilization, memory usage, and network bandwidth consumption. Operational status records are stored in time series and include fields such as "Resource ID," "Monitoring Timestamp," "Function Execution Result Details," "Command Response Time," and "Resource Usage Metrics," used for analyzing resource performance and stability.

[0179] Step S153: Integrate the operation behavior record with the running status record to form a set of actual application data. Each piece of data in the set of actual application data contains a corresponding time stamp and application scenario identifier.

[0180] Operation records and operational status records are linked and integrated using timestamps and resource IDs to form a real-world application dataset. Each data entry includes a timestamp (accurate to the second), an application scenario identifier (e.g., "flood warning scenario" or "resource scheduling scenario"), user operation information, and resource operational status information. Data cleaning is performed during the integration process to remove duplicate data and outliers (e.g., data with significantly excessive processing time) to ensure data quality. The real-world application dataset is stored in a columnar database, supporting efficient time-series queries and aggregation analysis.

[0181] Step S154: Extract user feedback records on function execution results from the actual application data set, analyze the function module implementation requests where the frequency of user triggering function execution commands reaches the preset judgment standard, and form a target function request list.

[0182] Records containing user feedback (such as user ratings and feedback opinions in operation results) are selected from the actual application data set and analyzed in conjunction with the trigger frequency of function execution commands. The trigger frequency of commands corresponding to the fulfillment requirements of each functional module is calculated, and functional modules whose frequency reaches a preset judgment standard (such as being higher than a set multiple of the average frequency) are included in the target functional requirement list. The list includes fields such as "functional module ID", "trigger frequency", "user feedback rating", and "functional importance assessment". The functional importance assessment is calculated by weighting the frequency and feedback rating.

[0183] Step S155: Based on the target functional requirement list, adjust the knowledge block dimension ratio of the requirement scenario deduction knowledge block, supplement the technical description details of the implementation requirements of each functional module in the target functional requirement list, and explore the potential functional requirements that users have not yet determined to express and transform them into new functional module implementation requirements.

[0184] Step S1551: Calculate the trigger frequency of each functional module implementation request in the target functional request list in the actual application data set, and form a frequency statistics result.

[0185] The function execution instructions in the actual application dataset are grouped according to the functional module requirements. The total number of triggers, the average daily number of triggers, and the number of triggers during peak periods for each module are counted to form frequency statistics. For example, the average daily number of triggers for the "waterlogging risk level prediction module" is a set value, with peak periods concentrated during rainfall.

[0186] Step S1552: Based on the frequency statistics results, adjust the proportion of knowledge block dimensions for each functional module in the knowledge block of the demand scenario deduction. For functional modules whose trigger frequency reaches the preset judgment standard, increase the description length in the knowledge block.

[0187] The knowledge blocks for demand scenario deduction adopt a modular structure. The length of the description of each functional module's requirements (such as the number of document pages and fields) is related to its importance. Based on frequency statistics, the proportion of high-frequency functional modules is increased, for example, from the original 10% to 15%. The increased length is used to supplement technical details and application cases. During the adjustment process, it is necessary to maintain the overall structural balance of the knowledge blocks and avoid any module having an excessively high proportion.

[0188] Step S1553: Extract the technical execution path corresponding to the implementation requirements of each functional module in the target functional requirement list, and analyze the key operation links and core parameter settings in the technical execution path.

[0189] Extract the technical execution path of the target functional module from the knowledge blocks derived from the demand scenario, and identify the key operational steps (such as data preprocessing and model inference) and core parameters (such as model learning rate and data sampling frequency). Analyze the performance of these steps and parameters in actual applications, such as whether the execution time of key operational steps is within an acceptable range, and whether the core parameters need to be adjusted to optimize performance.

[0190] Step S1554: Supplement the technical description details of key operation steps, including the execution steps, input data requirements, and output data standards for each key operation step.

[0191] Add detailed technical descriptions to key operational steps. For example, for the "data preprocessing step," specify the preprocessing steps (e.g., outlier handling using the IQR method, normalization using the Z-Score method), input data requirements (e.g., sampling frequency ≥ set value, data missing rate ≤ set value), and output data standards (e.g., data format is CSV, fields include timestamps and measured values). The descriptions must be precise down to the specific methods and judgment criteria used to ensure that technical personnel can accurately reproduce the operation.

[0192] Step S1555: Refine the technical description of the core parameter settings, and supplement the value range and adjustment method of the core parameters.

[0193] The core parameter settings should be refined, clearly defining the parameter value range (e.g., the learning rate range is a set interval), default values, and adjustment criteria (e.g., adjusting the batch size based on the amount of data). For example, for "prediction model learning rate," add "the initial learning rate is set to a set value, decays by a set percentage after each set training epoch, and stops adjusting when the validation loss no longer decreases." Also explain the impact of parameter adjustments on functional performance (e.g., an excessively high learning rate may cause the model to fail to converge).

[0194] Step S1556: Analyze the order in which users perform operations to fulfill their requests for each functional module in the target functional request list, extract the differences between the actual operation order and the interaction execution sequence, and form an operation difference record.

[0195] By comparing the operation sequence in the user's actual operation behavior record with the interaction execution sequence in the demand scenario deduction knowledge block, discrepancies are identified. For example, the interaction execution sequence requires "selecting a region before executing the prediction," while in actual user operation, there are cases where "the prediction is executed directly without selecting a region." Record information such as the type of difference (e.g., reversed order, omitted steps), frequency of occurrence, and user role to form an operation difference record.

[0196] Step S1557: Based on the operation difference records, infer the user's operation habit preferences and explore the potential functional demands that the user did not express during the operation.

[0197] Analyze operation difference records to deduce user operation habits and preferences, such as users' tendency to simplify operation steps and frequently use keyboard shortcuts. Combine these preferences to uncover potential functional requests, such as "supporting one-click execution prediction function" and "adding a quick selection function for frequently used areas." Potential functional requests need to be verified through user behavior data (e.g., the frequency of a simplified operation gradually increases) to ensure their authenticity and necessity.

[0198] Step S1558: Transform potential functional requirements into new functional module implementation requirements, and match the corresponding technical execution path, runtime carrier type, and runtime environment constraints for the new functional module implementation requirements.

[0199] Transform potential functional requirements into structured functional module implementation requirements, including fields such as "module name," "functional action description," "target object description," and "quantitative indicators." Match new modules with technical execution paths (e.g., reusing existing technologies or introducing new technologies), runtime carrier types (e.g., whether existing hardware supports them), and runtime environment limitations (e.g., whether additional software dependencies are required). For example, the technical execution path of the "one-click prediction function" module could be based on an existing prediction module, adding a step to automatically obtain default region parameters.

[0200] Step S1559: Analyze the logical relationship between the new functional module implementation requirements and the existing elements in the knowledge block of the requirement scenario deduction, and determine the position of the new functional module implementation requirements in the knowledge block.

[0201] By analyzing the logical relationships (such as inclusion and dependency relationships) between new functional modules and existing modules using a knowledge graph, their position within the knowledge block for demand scenario deduction is determined. For example, the "one-click prediction function" depends on both the "region selection module" and the "predictive analysis module," and should be placed after them as a combined functional module. Simultaneously, the directory structure and index of the knowledge block are updated to ensure that the new module can be correctly retrieved and referenced.

[0202] Step S15510: Integrate the new functional module implementation requirements and corresponding technical execution paths, operating carrier types, and operating environment limitations into the knowledge block of the demand scenario deduction, and reorganize the overall logical structure of the knowledge block so that the new content is connected with the original content.

[0203] Add detailed information about the new functional modules (technical execution path, runtime requirements, etc.) to the requirement scenario deduction knowledge block, and update the dependencies and interaction logic between modules. Reorganize the chapter structure of the knowledge block to ensure smooth transitions between new and existing content (e.g., adding references to the new module in relevant module descriptions). After integration, perform consistency checks on the knowledge blocks to ensure logical inconsistencies and no information duplication.

[0204] Step S156: Integrate the new functional module implementation requirements and corresponding technical execution paths and operating carrier requirements into the demand scenario deduction knowledge block, and adjust the logical relationships between the components in the demand scenario deduction knowledge block.

[0205] For example, step S1561: Extract the association combination of user operation behavior records and running status records from the actual application data set, analyze the corresponding pattern characteristics of repeated operation patterns and function execution results in the association combination, and identify the functional expectations in the user operation behavior records that are not expressed in the functional module implementation requirements but can be deduced from the operation patterns, based on the corresponding pattern characteristics, to form a potential functional expectation description.

[0206] A correlation analysis was performed on user operation behavior records and operation status records in the actual application dataset. A sequence pattern mining algorithm was used to identify recurring operation patterns (such as "select area → adjust parameters → execute prediction → view results → export report"). The correspondence between these operation patterns and function execution results (such as report export success rate and result viewing time) was analyzed to identify functional expectations that were not explicitly stated by users but were reflected in the operation patterns, such as "quickly generate standardized reports" and "support multi-format export of result data." These expectations were then compiled into potential functional expectation descriptions, including fields such as "operation pattern description," "corresponding result characteristics," and "expected functional content."

[0207] Step S1562: Transform the potential functional expectation description into the corresponding functional target statement, and specify the attribution or parallel relationship between each functional target statement and the functional module implementation requirements.

[0208] The descriptions of potential functional expectations are processed using natural language processing to transform them into structured functional target statements, such as "The system should support exporting prediction results to Excel and PDF formats." Based on the content of the functional target statements, their relationship with the implementation requirements of existing functional modules is determined: a hierarchical relationship (e.g., belonging to a sub-function of the "Results Display Module") or a parallel relationship (e.g., the "Report Generation Module" parallel to the "Predictive Analysis Module"). The relationship is specified using a combination of domain expert knowledge and semantic matching algorithms.

[0209] Step S1563: For each functional target statement, retrieve mature technical implementation methods in the field of artificial intelligence technology, and decompose the mature technical implementation methods into a sequence of technical action units that can be executed sequentially.

[0210] Mature technologies that enable functional objectives, such as "report generation," can be found by searching technical literature and patent databases. For example, a template engine can be used to implement these technologies. The retrieved technical implementation methods are then broken down into a sequence of technical action units, such as "template selection → data filling → format rendering → file generation → download interface provision." Each technical action unit includes information such as the action name, input and output data, and dependent technical components.

[0211] Step S1564: For each functional target statement, analyze the hardware platform conditions and software environment conditions on which its function execution depends, and form runtime constraint statements.

[0212] Analyze the sequence of technical action units corresponding to the functional objective statements to determine the required hardware platform conditions (such as CPU processing power and memory capacity) and software environment conditions (such as operating system version and dependent library versions). For example, the "report generation function" may require server memory ≥ a set value and support for a Java environment. Organize the above conditions into runtime constraint statements, such as "The runtime environment must have at least the set value of memory and support Python 3.8 and above".

[0213] Step S1565: Integrate the functional target statement, the sequence of technical action units, and the constraint statement of the operating vehicle to form a set of supporting associations for the realization of the new functional module requirements.

[0214] The functional objective statements, technical action unit sequences, and runtime constraint statements are integrated into a supporting set, serving as a complete description of the implementation requirements of the new functional module. This supporting set is stored in a JSON structure and includes fields such as "functional objective," "technical action sequence," "runtime constraint," and "performance indicators," ensuring the completeness of the new module's implementation details.

[0215] Step S1566: In the knowledge block of the demand scenario deduction, locate the knowledge block area where the original functional module implementation requirements are located and have a subordinate or parallel relationship with the new functional module implementation requirements.

[0216] Based on the hierarchical or parallel relationship between the new functional module and the existing modules, the target area is located within the structure of the knowledge block derived from the requirement scenario. For example, a new module with a hierarchical relationship is located in a sub-chapter of the existing module, while a new module with a parallel relationship is located in a sibling chapter of the existing module. The location process is achieved through the knowledge block's directory index and semantic retrieval.

[0217] Step S1567: Insert the functional target statements from the associated set into the located knowledge block area to form new functional targets within the knowledge block area.

[0218] Insert the functional objective statement into the designated knowledge block area as a new functional objective. The insertion location must conform to the chapter logic of the knowledge block; for example, add the new objective to the "Functional Objectives" section of an existing module. Simultaneously update the knowledge block's table of contents and cross-references to ensure the new content can be navigated correctly.

[0219] Step S1568: Compare the sequence of technical action units in the matching association set with the existing technical execution paths in the demand scenario deduction knowledge block to determine the insertion position or parallel trigger position of the sequence of technical action units in the existing technical execution paths.

[0220] By comparing the sequence of technical action units with the steps of existing technical execution paths, overlapping or related steps are identified, and the insertion position of the new sequence (e.g., after a certain step) or its parallel triggering position (e.g., executed simultaneously with a certain step) is determined. For example, the "data filling" action of the new sequence can be inserted after the "data processing" step in the existing path. After determining the position, the step order and dependencies of the technical execution path are updated.

[0221] Step S1569: Compare the runtime constraint statements in the associated set with the existing runtime requirements in the demand scenario deduction knowledge block to determine the supplementary or corrective content of the runtime constraint statements for the existing runtime requirements.

[0222] Compare the runtime constraint statements with existing runtime requirements to identify new conditions that need to be added (such as new software dependencies) or existing conditions that need to be modified (such as increased memory capacity requirements). For example, if the original requirement is "Memory ≥ Setpoint 1", and the new constraint requirement is "Memory ≥ Setpoint 2" (Setpoint 2 > Setpoint 1), then it should be modified to "Memory ≥ Setpoint 2". The reasons for any additions or modifications must be recorded (e.g., performance analysis based on actual application data).

[0223] Step S15610: Based on the newly added functional objectives, the insertion position or parallel trigger position of the technical action unit sequence, and the supplementary or corrected content of the running carrier constraint statement, generate a logical structure modification instruction for the knowledge block area.

[0224] Based on the above analysis results, structured logical structure modification instructions are generated, including information such as modification type (e.g., insertion, update, deletion), target location, modification content, and related effects. For example, "In the technical execution path of the 'data processing module,' insert the 'data filling' technical action unit after step 3," and "Update 'memory ≥ set value 1' in the runtime requirements to 'memory ≥ set value 2'."

[0225] Step S15611: Execute the logical structure modification instruction to establish a logical connection channel between the new functional objectives and the implementation requirements of the original functional modules within the knowledge block area.

[0226] Adjust the content of the knowledge block area according to the modification instructions, and establish logical connection channels (such as reference relationships and dependencies) between the new functional goals and the original modules. For example, add "This module contains the newly added 'One-Click Execution' sub-function; see the new functional module for details" to the description of the original module. The connection channels must conform to the ontology model of the knowledge block to ensure logical consistency.

[0227] Step S15612: Based on the insertion position or parallel trigger position of the technical action unit sequence, adjust the step connection order and data transmission interface of the technical execution path of adjacent parts of the knowledge block area.

[0228] Based on the insertion or parallel position of the technical action unit sequence, adjust the connection order of adjacent steps (e.g., step A → new step → step B), and update the data transmission interface (e.g., the output of step A becomes the input of the new step, and the output of the new step becomes the input of step B). Ensure that the adjusted technical execution path is smooth and that data transmission is uninterrupted.

[0229] Step S15613: Based on the supplementary or corrected content of the runtime constraint statement, update the specific description entries of the runtime requirements in the associated part of the knowledge block area.

[0230] Update the runtime constraint statements to the runtime requirements section of the knowledge block with supplementary or corrected content, replacing the original description entries. For example, update "Operating System: Windows Server 2016" to "Operating System: Windows Server 2016 or Linux CentOS 7.0 and above". After updating, check whether related parts (such as steps in the technical execution path that depend on this runtime environment) need to be adjusted synchronously.

[0231] Step S15614: Verify the logical consistency between the newly added functional objectives, adjusted technical execution paths, and updated runtime requirements within the updated knowledge block area; coordinate and correct any conflicting logical connection channels, step sequence, or specific description items; reintegrate the coordinated and corrected knowledge block area content into the required scenario deduction knowledge block; and simultaneously adjust the interactive execution sequences and extended requirement directions in the required scenario deduction knowledge block that reference the updated content.

[0232] The updated knowledge block area undergoes logical consistency verification to check whether the new functional goals match the technical execution path, whether the steps of the technical execution path are logically connected, and whether the requirements of the runtime environment meet the needs of the technical execution path. If conflicts exist (e.g., the memory required by the technical execution path exceeds the runtime environment requirements), coordination and correction are performed (e.g., increasing the memory requirements of the runtime environment). After correction, the content of the knowledge block area is reintegrated into the requirement scenario deduction knowledge block, and the interaction execution sequence (e.g., the operation steps for adding new functions) and the direction of extended requirements (e.g., removing implemented extended requirements) are updated simultaneously.

[0233] Step S157: Analyze the running status records in the actual application data set, extract the adjustment information of promotion resources in terms of functional implementation form and scenario adaptation scope, update the mapping attributes of the resource scenario mapping set, and update the technical description of functional implementation form and the definition of scenario adaptation scope.

[0234] Perform performance analysis on the operational status records to identify changes in the functional implementation of promoted resources in actual applications (e.g., actual sensor acquisition frequency is lower than the nominal value) and deviations in scenario adaptation range (e.g., increased equipment failure rate in high-temperature environments). Extract this adjustment information and update the mapping attributes of the corresponding resources in the resource scenario mapping set: supplement the technical description of the functional implementation with actual performance data (e.g., "actual acquisition frequency is the set value"); and correct environmental constraints in the definition of the scenario adaptation range (e.g., "operating temperature range adjusted to the set interval"). The update process must be accompanied by data support (e.g., statistical results from operational status records) to ensure the rationality of the adjustments.

[0235] Step S158: Based on the instruction response time and interaction process data of the promotion resources, identify the connection sequence that differs from the preset execution sequence and the collaborative operation process nodes that deviate from the preset interaction standard in the scenario collaborative adaptation scheme.

[0236] Analyze the command response time of promotional resources (e.g., a node's response time exceeds a preset threshold) and interaction process data (e.g., data transmission delay, format errors). Identify differences between the actual execution sequence and the preset execution sequence in the collaborative adaptation scheme (e.g., reversed node execution order), as well as nodes that deviate from preset standards in the collaborative operation process (e.g., data transmission success rate is lower than the set value). For example, the preset sequence is node A→node B→node C, but the actual execution sequence is node A→node C→node B, or the data transmission success rate of node B is only the set value. Record these anomalies, including information such as "abnormal node ID," "deviation type," "frequency of occurrence," and "scope of impact."

[0237] Step S159: Adjust the node connection order in the scenario collaboration adaptation scheme, optimize the information transmission form and response trigger signal in the collaborative operation process, and supplement new functional docking nodes and collaborative operation processes to adapt to the adjusted demand scenario deduction knowledge block and resource scenario mapping set.

[0238] Based on the identified anomalies, adjust the node connection order (e.g., reschedule nodes with frequent delays to off-peak hours); optimize information transmission methods (e.g., change easily lost HTTP transmission to TCP transmission); and adjust the threshold of response trigger signals (e.g., extend the timeout waiting time). Simultaneously, for the newly added functional modules and updated resource attributes of the resource scenario mapping set in the knowledge block derived from the demand scenario, supplement new functional docking nodes (e.g., "report generation node") and collaborative operation processes (e.g., data interaction paths between new and existing nodes) to ensure that the collaborative adaptation scheme remains consistent with the updated knowledge block and resource set.

[0239] Step S1510: Integrate all the adjusted content, update the demand scenario deduction knowledge block, the resource scenario mapping set, and the scenario collaborative adaptation scheme, and maintain the adaptation correspondence and logical association between the demand scenario deduction knowledge block, the resource scenario mapping set, and the scenario collaborative adaptation scheme.

[0240] All the above adjustments (knowledge block dimension adjustments, resource mapping attribute updates, collaboration scheme optimizations, etc.) will be integrated to update the structure and content of the requirement scenario deduction knowledge block, the resource information of the resource scenario mapping set, and the process and nodes of the scenario collaboration adaptation scheme. During the update process, it is necessary to ensure the adaptation and correspondence between the three (e.g., the functional modules of the knowledge block and the resources of the resource set can be correctly connected, and the collaboration scheme can reflect the latest knowledge block and resource information) and logical connections (e.g., the technical execution path of the knowledge block is consistent with the operation process of the collaboration scheme). After integration, a comprehensive verification will be conducted to ensure that the adjusted three elements can work collaboratively and meet the actual application needs of users.

[0241] Based on the same inventive concept, please refer to Figure 2 This paper shows a schematic block diagram of the structure of an artificial intelligence application scenario demand matching system 100 for performing the above-described artificial intelligence application scenario demand matching method for a marketing platform, provided in an embodiment of this application. The artificial intelligence application scenario demand matching system 100 for a marketing platform may include a communication unit 110, a machine-readable storage medium 120, and a processor 130.

[0242] In this embodiment, the machine-readable storage medium 120 can also be integrated into the processor 130 and can communicate and interact with external systems through the communication unit 110. The machine-readable storage medium 120 stores machine-executable instructions for executing the scheme of this application, and the processor 130 executes the machine-executable instructions stored in the machine-readable storage medium 120 to implement the artificial intelligence application scenario demand matching method for a marketing platform provided in the aforementioned method embodiments.

[0243] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A method for matching the application scenarios of artificial intelligence in a marketing platform, characterized in that, The method includes: Dynamic scenario deduction is performed on the user-initiated description of artificial intelligence application scenario requirements, generating requirement scenario deduction knowledge blocks. The requirement scenario deduction knowledge blocks include the functional module requirements, technical execution paths, operating platform requirements, interaction execution sequences, and extended requirement directions of the artificial intelligence application scenario requirements. The promotional resources of the marketing platform are mapped to specific scenarios to generate a resource scenario mapping set. The resource scenario mapping set includes the functional implementation form of the promotional resources, the scope of scenario adaptation, the linkage execution path and the capability expansion boundary. Perform a collaborative adaptation operation on the knowledge block of the demand scenario deduction and the resource scenario mapping set to generate a scenario collaborative adaptation scheme. The scenario collaborative adaptation scheme includes the docking nodes of the knowledge block and the set, the execution order and the collaborative operation process. Based on the scenario collaboration adaptation scheme, promotional resources in the marketing platform that can undertake the docking nodes and collaborative operation processes are selected to form a list of scenario demand adaptation resources. Collect actual application data of users' use of the promotional resources in the resource list that adapts to the scenario requirements, and adjust the knowledge block dimension of the requirement scenario deduction knowledge block, the mapping attribute of the resource scenario mapping set, and the collaborative logic of the scenario collaborative adaptation scheme based on the actual application data. The process of collecting actual application data of users to the promotional resources in the resource list adapted to the scenario requirements, and adjusting the knowledge block dimension of the requirement scenario deduction knowledge block, the mapping attributes of the resource scenario mapping set, and the collaborative logic of the scenario collaborative adaptation scheme based on the actual application data includes: Deploy a data collection component to record in real time the user's operation behavior during the process of promoting resources in the resource list that adapts to usage scenario requirements. The operation behavior record includes the function execution instructions triggered by the user, the order of operations, and the duration of each operation. Collect the operational status records of promotional resources in response to user operations. The operational status records include the function execution results of the promotional resources, the instruction response time, and the resource usage. The operation behavior records and the running status records are integrated to form a set of actual application data. Each piece of data in the set of actual application data contains a corresponding time stamp and application scenario identifier. Extract user feedback records on function execution results from the actual application data set, analyze the function module implementation requirements that the frequency of user triggering function execution commands reaches the preset judgment standard, and form a target function requirement list; Based on the target functional requirements list, adjust the knowledge block dimension ratio of the knowledge block in the demand scenario deduction knowledge block, supplement the technical description details of the implementation requirements of each functional module in the target functional requirements list, and explore the potential functional requirements that users have not yet determined to express and transform them into new functional module implementation requirements. The new functional module implementation requirements, corresponding technical execution paths, and operating platform requirements are integrated into the demand scenario deduction knowledge block, and the logical relationships between the components in the demand scenario deduction knowledge block are adjusted. Analyze the running status records in the actual application data set, extract the adjustment information of promotion resources in terms of functional implementation form and scenario adaptation scope, update the mapping attributes of the resource scenario mapping set, and update the technical description of functional implementation form and the definition of scenario adaptation scope. Based on the instruction response time and interaction process data of promotional resources, identify the connection sequence that differs from the preset execution sequence and the collaborative operation process nodes that deviate from the preset interaction standard in the scenario collaborative adaptation scheme. Adjust the node connection order in the scenario collaboration adaptation scheme, optimize the information transmission form and response trigger signal in the collaborative operation process, and add new functional docking nodes and collaborative operation processes to adapt to the adjusted demand scenario deduction knowledge block and resource scenario mapping set. Integrate all adjustments, update the required scenario deduction knowledge block, the resource scenario mapping set, and the scenario collaborative adaptation scheme, and maintain the adaptation correspondence and logical association between the required scenario deduction knowledge block, the resource scenario mapping set, and the scenario collaborative adaptation scheme.

2. The artificial intelligence application scenario demand matching method applied to a marketing platform according to claim 1, characterized in that, The process of performing dynamic scenario deduction on user-initiated AI application scenario requirements generates requirement scenario deduction knowledge blocks, including: Receive user's description of artificial intelligence application scenario requirements submitted through the interactive port of the marketing platform. The description of artificial intelligence application scenario requirements is a complete text of the user's request for the application of artificial intelligence technology in a specified promotion scenario. Extract relevant statements related to function implementation from the description of the requirements for the artificial intelligence application scenario, and form a set of function implementation-related statements. The set of function implementation-related statements includes various functional expectations of users for artificial intelligence applications. Based on the set of function implementation-related statements, multiple function module implementation requirements are obtained. Each function module implementation requirement corresponds to an independent function execution step, and each function module implementation requirement includes specific function achievement goals. Retrieve the technical implementation forms corresponding to the implementation requirements of each functional module in the field of artificial intelligence technology, and generate the technical execution path corresponding to the implementation requirements of each functional module based on the technical implementation forms. The technical execution path includes continuous technical operation steps. Extract relevant expressions related to the application environment from the description of the requirements for the artificial intelligence application scenarios to form a set of application environment-related expressions. The set of application environment-related expressions includes various requirements of users for the operating environment of artificial intelligence applications. Based on the set of descriptions related to the application environment, the type of operating carrier and the limitation of the operating environment required for artificial intelligence application scenarios are determined. The type of operating carrier is the category of hardware or software platform that carries artificial intelligence applications, and the limitation of the operating environment is the environmental conditions required for the execution of artificial intelligence application functions. Extract relevant expressions related to user operations from the description of the requirements of the artificial intelligence application scenario to form a set of user operation-related expressions. The set of user operation-related expressions includes various operation descriptions of user interaction with artificial intelligence applications. An interactive execution sequence for artificial intelligence application scenarios is generated based on a set of user operation-related expressions. The interactive execution sequence includes the connection order between user operations and artificial intelligence application responses. Based on the functional module implementation requirements and the interaction execution sequence, the extended requirement direction is deduced. The extended requirement direction is the additional functional requirements and scenario expansion requirements in addition to the core functional requirements. By integrating the functional modules to realize the requirements, technical execution paths, operating carrier types, operating environment limitations, interactive execution sequences, and extended requirement directions, a requirement scenario deduction knowledge block is generated. Each component in the requirement scenario deduction knowledge block contains a corresponding technical description and execution specification.

3. The artificial intelligence application scenario demand matching method applied to a marketing platform according to claim 1, characterized in that, The step of performing a collaborative adaptation operation on the knowledge block derived from the demand scenario and the resource scenario mapping set to generate a scenario collaborative adaptation scheme includes: Extract the implementation requirements and technical execution paths of all functional modules in the aforementioned demand scenario deduction knowledge block, and organize them into a demand-side functional execution directory according to functional categories; Extract all functional implementation forms and linkage execution paths from the resource scenario mapping set, and organize them into a resource-side function undertaking directory according to capability categories; Compare the implementation requirements of each functional module in the demand-side function execution catalog with the functional implementation form in the resource-side function undertaking catalog one by one to determine the corresponding functional docking nodes. Each functional docking node includes the functional requirements of the demand side and the capability support of the resource side. Extract the interactive execution sequence of the knowledge block of the demand scenario deduction and the linkage execution path of the resource scenario mapping set, and determine the connection order of all functional docking nodes. The connection order is determined by the logical relationship between the demand execution process and the resource response process. Extract the technical execution path, operating platform requirements, and scenario adaptation range corresponding to the implementation requirements of each functional module, integrate them into the corresponding functional docking nodes, and form the execution conditions and operation standards of each functional docking node. Analyze the operational relationships between all functional nodes and generate a collaborative operation process between nodes. The collaborative operation process includes the information transmission format, response trigger signals and result feedback paths between nodes. Based on functional docking nodes, connection sequence, execution conditions, operation standards and collaborative operation processes, an initial collaborative adaptation association structure is generated, which includes the basic docking logic of requirements and resources. Extract the extended demand direction of the demand scenario deduction knowledge block and the capability extension boundary of the resource scenario mapping set, supplement the extended function docking nodes and extended collaborative operation process, and integrate them into the initial collaborative adaptation association structure. Adjust the node connection process, information transmission format, and response trigger signals in the initial collaborative adaptation association structure; The integrated and optimized functional docking nodes, connection sequence, execution conditions, operation standards, collaborative operation process, extended functional docking nodes, and extended collaborative operation process form a scenario collaborative adaptation scheme. The scenario collaborative adaptation scheme is used to present the entire interaction process between the demand scenario deduction knowledge block and the resource scenario mapping set.

4. The artificial intelligence application scenario demand matching method applied to a marketing platform according to claim 1, characterized in that, The aforementioned scenario-based collaborative adaptation solution is used to select promotional resources from the marketing platform that can undertake the docking nodes and collaborative operation processes, forming a scenario-demand-adaptive resource list, including: Analyze all functional interface nodes and extended functional interface nodes in the scenario collaborative adaptation scheme, extract the functional support type and capability support requirements of each node, and form a set of node support requirements. Extract the functional implementation forms and capability expansion boundaries of all promotional resources in the marketing platform, and organize them into a platform resource capability catalog according to resource categories; Compare each promotional resource in the platform's resource capability catalog with the corresponding requirements in the node support requirement set, and select candidate promotional resources that can meet the functional support type and capability support requirements of a single functional docking node. Based on the connection sequence and collaborative operation process of the scenario collaborative adaptation scheme, candidate promotion resources are combined according to the connection relationship of functional docking nodes to form multiple resource combination configurations. Each resource combination configuration contains multiple promotion resources that can cover all functional docking nodes. Simulate the execution environment of the scenario collaborative adaptation scheme, configure and deploy each resource combination to the simulated environment, and start the function execution of the promotion resources in the order of connection; Record the interaction process data between promotional resources in each resource combination configuration. The interaction process data includes data transmission time, data format matching records, and function execution connection records. Based on the data from the interaction process, resource combinations are selected that ensure data transmission meets preset time standards, data formats are fully compatible, and function execution is seamless. Verify the promotional resources in the selected resource combinations to confirm whether they can undertake the extended function docking nodes and extended collaborative operation processes; Extract resource combinations that can fully support all functional docking nodes, extended functional docking nodes, collaborative operation processes, and extended collaborative operation processes, and distinguish between the main promotional resources and auxiliary promotional resources in each resource combination configuration; All promotional resources are integrated according to the functional support priority of the main promotional resources. The application nodes and execution roles of each promotional resource in the scenario collaboration adaptation solution are supplemented to form a scenario requirement adaptation resource list. The scenario requirement adaptation resource list includes the promotional resource name, application node, execution role and collaboration relationship description.

5. The artificial intelligence application scenario demand matching method applied to a marketing platform according to claim 2, characterized in that, The method retrieves the technical implementation forms corresponding to the implementation requirements of each functional module in the field of artificial intelligence technology, and generates the technical execution path corresponding to the implementation requirements of each functional module based on the technical implementation forms, including: Extract the core technology categories in the field of artificial intelligence technology that can support the implementation of various functional modules, and form an artificial intelligence core technology catalog. The artificial intelligence core technology catalog includes the functional support scope and application forms of various technologies. Compare the implementation requirements of each functional module with the core technology categories in the core technology catalog of artificial intelligence to determine the target core technologies that can support the implementation of the functional module. Collect mature application examples of the target core technologies, extract the functional implementation methods and operational sequence of the target core technologies in the examples, and form reference content for technology applications; Extract the application environment constraints of the marketing platform, which are the constraints of the marketing platform in terms of hardware configuration, software environment and data transmission. Compare the operational steps in the technical application reference content with the application environment constraints of the marketing platform, identify and remove operational steps in the technical application reference content that are incompatible with the application environment constraints; The technical application reference content after removing incompatible operation links is broken down into multiple consecutive technical operation steps. Each technical operation step corresponds to a specific technical execution action, and each technical operation step includes specific input content and output results. Analyze the correspondence between each technical operation step and the sub-goals of the functional module's implementation requirements, and determine the execution purpose of each technical operation step; Determine the conditions required to initiate each technical operation step, wherein the conditions required to initiate the technical operation step are the prerequisite technical states and data input requirements that must be met to initiate the technical operation step; The inherent execution logic between the integrated technical operation steps is arranged according to the execution rules of the target core technology and the progressive relationship of the achievement of functional module requirements; By integrating the core target technologies, continuous technical operation steps, execution objectives, activation requirements, and execution logic between steps, a technical execution path is formed corresponding to the realization requirements of each functional module. The technical execution path is used to describe the entire technical process of realizing the functional module.

6. The artificial intelligence application scenario demand matching method applied to a marketing platform according to claim 3, characterized in that, The analysis examines the operational relationships between all functional nodes and generates a collaborative operational process between the nodes, including: Extract the input and output data formats of each functional interface node to determine the data interaction requirements between nodes. The data interaction requirements include the content and format requirements for data transmission. The data transmission format between nodes is determined based on data interaction requirements. The data transmission format is the specific implementation method of transmitting data from one functional interface node to another functional interface node. Extract the feature signal generated by each functional docking node after it completes its own function execution, and use the feature signal as the start trigger signal for the next functional docking node; The verification process for the start-up trigger signal is executed, and the accuracy of the transmission and the reliability of the execution of the start-up trigger signal are confirmed through a preset technical detection sequence. The result feedback path between planning nodes is the specific path by which the subsequent functional docking node transmits the execution result to the previous functional docking node or the request initiating end. Adjust the data transmission format of the result feedback path to make the transmission format of the feedback data consistent with the data transmission format between nodes; Determine the time node for result feedback, which is the specific moment when the result feedback is initiated immediately after the next functional interface node completes its own function execution; A sequence of corresponding processing steps is constructed based on the possible abnormal data interaction states between nodes. The abnormal data interaction states include data transmission interruption, data format error, data loss, and data transmission delay. The executing entity of the processing step sequence is determined, and the executing entity is the functional interface node responsible for executing the data interaction exception handling steps; By integrating data transmission methods, start-up trigger signals, verification processes, result feedback paths, feedback time nodes, processing step sequences, and execution entities, a collaborative operation process between nodes is formed. This collaborative operation process is used to define the interaction process between functional docking nodes.

7. The artificial intelligence application scenario demand matching method applied to a marketing platform according to claim 4, characterized in that, The process of recording the interaction data between promotional resources in each resource combination configuration is used to filter resource combination configurations that have data transmission conforming to preset time standards, perfectly matching data formats, and continuous functional execution based on the interaction data. This includes: A simulation verification environment consistent with the actual operating environment of the marketing platform is established. The simulation verification environment conforms to the configuration of the marketing platform in terms of hardware configuration, software version, network bandwidth and data processing capabilities. Deploy all promotional resources in each resource combination configuration to the simulation verification environment according to the requirements of the scenario collaborative adaptation scheme, and establish data interaction interfaces between promotional resources. The promotional resources are launched according to the connection sequence of the scenario-based collaborative adaptation scheme, and the data recording component is launched simultaneously to record the interaction process between the promotional resources. Record the initiation and reception times of each data transmission process to form a data transmission time record; Verify that the format of the transmitted data matches the preset format, and record the data format matching record; Monitor the seamless execution of promotional resource functions and record the seamless execution records; Integrate data transmission time records, data format compatibility records, and function execution connection records to form the interaction process data for each resource combination configuration; Set standards for data transmission time, data format compatibility, and functional continuity. By comparing the interaction process data of each resource combination configuration with the set standards, resource combination configurations that meet the preset time standards for data transmission, have a perfect data format, and have continuous functional execution are selected, and the selected resource combination configurations are formed into a list of resource combinations that meet the standards.

8. The artificial intelligence application scenario demand matching method applied to a marketing platform according to claim 1, characterized in that, The adjustment of the knowledge block dimension ratio of the knowledge block in the demand scenario deduction knowledge block based on the target functional demand list, and the supplementation of technical description details of the implementation requirements of each functional module in the target functional demand list, including: The frequency of triggering of each functional module implementation requirement in the target functional requirement list in the actual application data set is calculated to form a frequency statistics result. Based on the frequency statistics results, the proportion of knowledge block dimensions for each functional module in the knowledge block of the demand scenario deduction knowledge block is adjusted, and the description of the functional module that triggers the frequency to reach the preset judgment standard is increased in the knowledge block. Extract the technical execution path corresponding to the implementation requirements of each functional module in the list of target functional requirements, and analyze the key operation links and core parameter settings in the technical execution path; Supplement the technical description details of key operational steps, including the execution steps, input data requirements, and output data standards for each key operational step; Detail the technical description of the core parameter settings, and supplement the value range and adjustment method of the core parameters; Analyze the order in which users perform operations to fulfill their requests for each functional module in the list of target functional requests, extract the differences between the actual user operation order and the interaction execution sequence, and form an operation difference record; Based on the operation difference records, we can infer users' operation habits and preferences, and explore potential functional needs that users have not clearly expressed during the operation process. Transform potential functional requirements into new functional module implementation requirements, and match the corresponding technical execution path, runtime carrier type and runtime environment constraints for the new functional module implementation requirements; Analyze the logical relationship between the new functional module implementation requirements and the existing elements in the knowledge block of the required scenario, and determine the position of the new functional module implementation requirements in the knowledge block; The new functional modules' implementation requirements, corresponding technical execution paths, operating platform types, and operating environment limitations are integrated into the knowledge blocks of the demand scenario deduction, and the overall logical structure of the knowledge blocks is reorganized to ensure the connection and coherence between the new content and the original content.

9. An artificial intelligence application scenario demand matching system applied to a marketing platform, characterized in that, include: processor; A machine-readable storage medium for storing machine-executable instructions of the processor; The processor is configured to execute the artificial intelligence application scenario demand matching method for a marketing platform as described in any one of claims 1 to 8 by executing the machine-executable instructions.

Images