Equipment black and white list management method and device, storage medium and electronic equipment

Abstract

The invention relates to an equipment black and white list management method and device, a storage medium and electronic equipment. The method comprises the following steps: receiving feedback information input by a user, and identifying a feedback identifier, an equipment problem type and a user appeal in the feedback information; obtaining business data of the target equipment from a business background according to the feedback identifier, and inputting the feedback information and the business data into a target large model, so that the target large model executes semantic understanding and rule reasoning according to the feedback information and the business data in combination with a business knowledge base, and generates a black and white list change suggestion; processing the original blacklist and whitelist of the target device based on the blacklist and whitelist change suggestion, and generating a new blacklist and whitelist meeting user demands; and uploading the new black and white list to a cloud storage platform, and feeding back a processing result of the downloading link containing the new black and white list to the user. The technical problems that equipment capability identification depends on manual editing of black and white lists, the process is tedious and inefficient, and errors are prone to occurring are solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, storage medium, and electronic device for managing device blacklists and whitelists. Background Technology

[0002] With the large-scale access of devices and the continuous expansion of business capabilities, establishing device blacklists and whitelists has become an important technical means to ensure system stability and user experience. By differentiating device capabilities and managing them in the form of blacklists and whitelists, the system can automatically distinguish between compatible devices and devices with performance or functional problems, enabling dynamic on / off switching of capabilities. This avoids issues such as stuttering, image quality degradation, and functional abnormalities caused by capability incompatibility. For example, in a TV playback scenario, depending on whether a device supports 8K video playback, a whitelist can be used to enable high-definition capabilities, providing the best viewing experience for high-performance devices; while for devices that do not support this capability, a blacklist can be used to disable the relevant switch, preventing abnormalities caused by overload operation.

[0003] However, a prominent problem exists in existing R&D and testing processes: due to the large number of device models and the complexity of hardware capabilities, R&D teams often struggle to accurately and promptly confirm the specific capabilities supported by a particular device in the early stages. This forces testers to manually create or adjust blacklists and whitelists for each device. Current processes typically require testers to first export the device's JSON capability file from the management platform, and then manually check and edit each capability parameter, such as whether 8K playback is supported. This manual judgment and input method is not only cumbersome and inefficient, but also prone to errors due to formatting issues, omissions, or misjudgments, thus affecting the overall quality of the testing process and even the stability of subsequent online functions. Summary of the Invention

[0004] This application provides a method, apparatus, storage medium, and electronic device for managing device blacklists and whitelists, in order to solve the technical problem that device capability identification relies on manual editing of blacklists and whitelists, which is cumbersome, inefficient, and prone to errors.

[0005] Firstly, this application provides a method for managing device blacklists and whitelists, comprising: receiving feedback information input by a user, and identifying the feedback identifier, device problem type, and user request in the feedback information; obtaining business data of the target device from the business backend based on the feedback identifier, and inputting the feedback information and the business data into a target big data model, so that the target big data model, based on the feedback information and the business data, and in conjunction with a business knowledge base, performs semantic understanding and rule reasoning to generate a blacklist / whitelist change suggestion; processing the original blacklist / whitelist of the target device based on the blacklist / whitelist change suggestion to generate a new blacklist / whitelist that meets the user request; uploading the new blacklist / whitelist to a cloud storage platform, and providing the processing result, including a download link for the new blacklist / whitelist, to the user.

[0006] Secondly, this application provides a device for managing device blacklists and whitelists, comprising: an identification module for receiving feedback information input by a user and identifying the feedback identifier, device problem type, and user request in the feedback information; a first processing module for obtaining business data of the target device from the business backend based on the feedback identifier, and inputting the feedback information and the business data into a target big data model, so that the target big data model, based on the feedback information and the business data, and in conjunction with a business knowledge base, performs semantic understanding and rule reasoning to generate a blacklist / whitelist change suggestion; a second processing module for processing the original blacklist / whitelist of the target device based on the blacklist / whitelist change suggestion to generate a new blacklist / whitelist that meets the user request; and a feedback module for uploading the new blacklist / whitelist to a cloud storage platform and providing the user with a download link for the new blacklist / whitelist.

[0007] As an optional example, the above apparatus further includes: a creation module for creating a chatbot for receiving feedback information input by the user before receiving such feedback information input by the user.

[0008] As an optional example, the above-mentioned device further includes: a first construction module, used to construct a prompt template for reasoning in the target large model before inputting the above-mentioned feedback information and the above-mentioned business data into the target large model, wherein the prompt template includes a description of business rules, device information format, constraints for generating blacklists and whitelists, and output structure requirements.

[0009] As an optional example, the above-mentioned device further includes: a second construction module, used to construct a tabular business knowledge base before inputting the above-mentioned feedback information and business data into the target large model, wherein the business knowledge base includes device information, business rules, functional configuration descriptions, specific positioning capabilities, and access control policies.

[0010] As an optional example, the first processing module includes: an extraction unit for extracting key factual information from the feedback information and business data, wherein the key factual information includes device identifier, device model, firmware version, function switch status, and error information; a retrieval unit for retrieving business rules, function configuration descriptions, specific positioning capabilities, and access control policies related to the key factual information from the business knowledge base, and obtaining retrieval results; an analysis unit for performing semantic understanding and rule reasoning based on the prompt template, the key factual information, and the retrieval results to analyze the access status, function availability, and abnormal situations of the target device, and obtaining analysis results; and a generation unit for generating the blacklist / whitelist change suggestions based on the analysis results, wherein the blacklist / whitelist change suggestions include at least one of adding, modifying, and deleting entries.

[0011] As an optional example, the second processing module mentioned above includes: a processing unit, used to add, modify or delete entries in the original blacklist or whitelist according to the blacklist / whitelist change suggestions, and generate a new blacklist or whitelist in a structured format.

[0012] As an optional example, the feedback module includes: an upload unit for uploading the new blacklist and whitelist to the cloud storage platform so that the cloud storage platform generates a download link for the new blacklist and whitelist; and a feedback unit for feeding back the processing result containing the download link to the user via the chatbot.

[0013] Thirdly, this application provides a storage medium storing a computer program, wherein the computer program is executed by a processor to perform the aforementioned device blacklist / whitelist management method.

[0014] Fourthly, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the aforementioned device blacklist / whitelist management method through the computer program.

[0015] The technical solutions provided in this application have the following advantages compared with the prior art: This application employs a method that receives user-input feedback information and identifies the feedback identifier, device problem type, and user request within the feedback information; retrieves business data of the target device from the business backend based on the feedback identifier, and inputs the feedback information and business data into a target big data model. The target big data model, based on the feedback information and business data, and in conjunction with a business knowledge base, performs semantic understanding and rule-based reasoning to generate blacklist / whitelist change suggestions. Based on these suggestions, the original blacklist / whitelist of the target device is processed to generate a new blacklist / whitelist that meets the user's request. The new blacklist / whitelist is then uploaded to a cloud storage platform, and the processing result, including a download link for the new blacklist / whitelist, is fed back to the user. This method automatically generates blacklist / whitelist change suggestions by receiving and parsing user feedback information, combining it with device business data from the business backend, inputting both into a big data model, and incorporating a business knowledge base to perform semantic understanding and rule-based reasoning. Based on these suggestions, the original blacklist / whitelist is automatically updated to generate a new blacklist / whitelist that meets the user's request, which is then uploaded to a cloud storage platform for user download and application. This enables intelligent and automated configuration of device capability switches, improves the accuracy of device capability judgment, standardizes the updating of blacklists and whitelists, and enhances the efficiency and stability of the overall R&D and testing process. It also solves the technical problem that device capability identification relies on manual editing of blacklists and whitelists, which is cumbersome, inefficient, and prone to errors. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0019] Figure 1 This is a flowchart of an optional device blacklist / whitelist management method according to an embodiment of this application; Figure 2 This is an overall structural diagram of an optional device blacklist / whitelist management method according to an embodiment of this application; Figure 3This is a result illustration of an optional device blacklist / whitelist management method according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an optional device blacklist / whitelist management device according to an embodiment of this application; Figure 5 This is a schematic diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0022] According to a first aspect of the embodiments of this application, a method for managing device blacklists and whitelists is provided, optionally, as follows: Figure 1 As shown, the above method includes: S102 receives feedback information input by the user and identifies the feedback identifier, device problem type, and user request in the feedback information; S104: Obtain business data of the target device from the business backend based on the feedback identifier, and input the feedback information and business data into the target big model so that the target big model can perform semantic understanding and rule reasoning based on the feedback information and business data, combined with the business knowledge base, to generate blacklist and whitelist change suggestions. S106, Based on the blacklist / whitelist change suggestions, process the original blacklist / whitelist of the target device to generate a new blacklist / whitelist that meets the user's requirements; S108 uploads the new blacklist and whitelist to the cloud storage platform and provides the user with the processing results, including download links for the new blacklist and whitelist.

[0023] Optionally, this embodiment provides an automated method for generating blacklists and whitelists for multi-model device capability management, aiming to solve the problems of traditional device capability switches relying on manual editing, low efficiency, error-proneness, and difficulty in adapting to complex differences in device capabilities. By introducing large-scale model semantic understanding, rule reasoning, and business knowledge base mechanisms, intelligent generation, automatic revision, and online release of device blacklists and whitelists are achieved, significantly improving the efficiency and accuracy of the R&D and testing phases. Figure 2 As shown in the overall structure diagram, the system adopts a multi-layered collaborative architecture of "chatbot + custom service + business backend + large model knowledge base" to achieve automatic identification, intelligent analysis, and result return of device blacklist and whitelist issues. It mainly includes the following parts: First, the front end consists of a chatbot component, used to receive feedback information submitted by testers (e.g., feedback ID 14061, "Device 8K playback capability is disabled, test whitelist needs to be configured"). The chatbot performs natural language parsing, identifying feedback identifiers, question types, and user requests by performing intent recognition and key information extraction on user input.

[0024] Secondly, the chatbot sends the parsed structured information to the custom business service. As the core of business processing, the custom service can access the backend device capability management system, including the blacklist / whitelist control backend and device capability database, thereby obtaining the corresponding device's business data and current network configuration. Furthermore, the custom service integrates a large model processing module, which can input user feedback and business data into the large model.

[0025] Furthermore, the large model, based on an integrated business knowledge base (containing device information, capability rules, business process descriptions, historical cases, etc.), performs semantic understanding, rule reasoning, and capability judgment to generate blacklist / whitelist adjustment suggestions or capability on / off configuration schemes. The knowledge base plays a role in enhancing the credibility of reasoning and ensuring business consistency throughout this process.

[0026] Subsequently, based on the analysis results generated by the large model, the custom service generates, modifies, or verifies blacklist and whitelist files, and calls the backend permission check or configuration interface as needed to ensure that the results comply with business rules and device capability models.

[0027] Finally, based on the processing results returned by the custom service, the chatbot sends a complete solution back to the user, such as whitelist configuration methods, explanations of capability switches, and links to new blacklist and whitelist files that can be downloaded directly, enabling the user to quickly complete the testing and verification tasks.

[0028] The specific implementation process includes the following steps: First, the chatbot receives user-input feedback and performs semantic structured recognition on the feedback content. This feedback typically includes the device model, a description of the problem, the user's request, and the expected test results. Using a text parsing module, the chatbot identifies the feedback identifier (to uniquely identify the device), the device problem type (e.g., malfunction, inability to enable a feature, playback failure), and the user's request (enabling a feature, disabling a feature, adjusting performance parameters, etc.), transforming it into structured input that can be further processed and transmitted to the custom business service.

[0029] Subsequently, the custom business service automatically retrieves the target device's business data from the business backend based on the feedback identifier. This business data includes, but is not limited to: basic device information, hardware capability parameters, system version, playback capability records, historical blacklists and whitelists, problem reporting records, and compatibility test results. This data forms the factual basis for determining device capabilities. The feedback information and business data are then input into a pre-defined large-scale model processing module.

[0030] To improve the inference accuracy of the large-scale model, a business knowledge base oriented towards device capabilities was further constructed. This knowledge base can be managed using a tabular or graph structure and includes device attributes, capability tags, function rules, historical problem patterns, explanations of common compatibility issues, capability on / off dependencies, and device function-problem mapping relationships. After receiving feedback information and device business data, the large-scale model, combined with pre-summarized rules and cases in the knowledge base, performs semantic understanding, logical reasoning, and capability judgment to generate change suggestions for updating blacklists and whitelists. These suggestions typically include: the capability items that the target device should enable / disable, whether to include it in the whitelist or blacklist, the corresponding reasons for the change, and risk warnings.

[0031] Based on the blacklist / whitelist change suggestions generated by the large model, a custom business service automates the processing of the original blacklist / whitelist files for devices. Processing methods include, but are not limited to: adding capability items according to the recommended strategy, modifying the on / off status of existing capabilities, and deleting no longer applicable capability rules. The system ensures that the final generated blacklist / whitelist strictly meets user requirements while maintaining consistency with device capability specifications, thereby avoiding formatting errors, parameter omissions, or judgment biases that are prone to occur during traditional manual editing. After the new blacklist / whitelist is generated, the custom business service performs format validation, field validity checks, and usability verification to ensure that the blacklist / whitelist files can be correctly used by the business end.

[0032] After generating the new blacklist and whitelist, the custom business service uploads them to the cloud storage platform, enabling centralized management, unified distribution, and version tracking of the blacklists and whitelists. Upon successful upload, the custom business service generates a corresponding download link, such as... Figure 3As shown in the result display diagram, the processing result containing the download link will be fed back to the user through a chatbot, enabling the user to easily download and apply the new blacklist / whitelist file in the background system or testing platform.

[0033] Optionally, in this embodiment, by introducing large-scale model reasoning and business knowledge base technologies, intelligent generation and automated maintenance of device blacklists and whitelists can be achieved. This can significantly reduce manual operation costs, lower editing error rates, and improve the accuracy and consistency of device capability judgment. This method can handle management scenarios involving massive numbers of devices of various models with significant capability differences, improve the configuration efficiency of device capability switches, accelerate the testing and verification process, and thus enhance the overall system stability and user experience. Simultaneously, the cloud-based blacklist and whitelist management method enhances version controllability and distribution efficiency.

[0034] As an optional example, the above method may also include the following before receiving user input feedback: Create a chatbot to receive feedback information from user input.

[0035] Optionally, in this embodiment, to achieve efficient access and intelligent processing of user feedback, a chatbot is created to receive feedback information, serving as the entry point for user interaction with the backend business system. This chatbot supports natural language input and can receive real-time feedback from testers regarding device capabilities, functional abnormalities, or business requirements. It also structures the user input, transforming it into the data format required for subsequent analysis.

[0036] During operation, when a user submits feedback to the chatbot (such as feedback number, device performance, functional requests, etc.), the chatbot first performs intent recognition and semantic analysis on the feedback content to extract the feedback identifier, device problem type, and the user's desired processing goal. The extracted structured information is then passed to a custom backend service for further querying the device's actual business status.

[0037] As an optional example, the above methods may also include the following before inputting feedback information and business data into the target large model: Construct a prompt template for inference of the target large model. The prompt template includes a description of business rules, device information format, constraints for generating blacklists and whitelists, and output structure requirements.

[0038] Optionally, in this embodiment, a prompt template for the target large model inference is constructed to ensure that the large model can generate stable and reliable output results under clear business boundaries and format requirements when performing inference calculations. This prompt template serves as a constraint and guidance framework for the large model, encompassing several core components. First, the prompt template includes business rule descriptions to clarify the business logic that needs to be followed during device capability management, such as the dependencies between different device capabilities, the enabling or disabling conditions of specific function switches, and the restrictions on capability changes in test scenarios. By solidifying these business logics in the form of rule text in the template, the large model can avoid deviating from actual business specifications during inference, thereby ensuring the legality and rationality of the inference results. Second, the template defines a device information format to standardize the input data structure received by the large model. This format may include field descriptions such as device model, firmware version, current capability status, platform identifier, and feedback source, enabling the large model to perform semantic understanding based on a unified structure when parsing input content, reducing inference ambiguity caused by inconsistent input formats. Furthermore, the prompt template includes constraints for generating blacklists and whitelists, such as which capabilities can be adjusted, which capabilities need to maintain consistency, whether there are mutually exclusive relationships between different capability adjustments, and the fields that blacklist and whitelist entries must include. By strictly defining these generation constraints, it ensures that the capability change suggestions generated by the large model meet system executability requirements, preventing issues such as accidentally enabling prohibited business items or missing format fields. Finally, the template clearly defines the output structure requirements of the large model, including output fields, data format, content organization, and the expression of the change reasons, ensuring that the model's returned results can be directly parsed by downstream services and used for blacklist and whitelist generation. With a standardized output structure, the backend system no longer needs to perform complex parsing or secondary structuring of the results, reducing the probability of errors. In summary, the prompt template not only provides contextual information and business boundaries for the large model but also provides dual specifications for input and output formats, thus ensuring the controllability and consistency of the entire inference process.

[0039] As an optional example, the above methods may also include the following before inputting feedback information and business data into the target large model: Construct a tabular business knowledge base, which includes device information, business rules, functional configuration descriptions, specific positioning capabilities, and access control policies.

[0040] Optionally, in this embodiment, a tabular business knowledge base is constructed to provide structured and searchable business background support for the large model. As the core information carrier, the business knowledge base covers multi-dimensional business information required in the device management system, enabling the large model to generate accurate and reliable blacklist / whitelist change suggestions based on a clear business context during the reasoning process. The business knowledge base first contains device information, used to record the basic attributes and capabilities of various devices. For example, the hardware decoding capabilities, operating system versions, performance levels, screen resolution support ranges, and playback capability limitations of different device models. By structurally storing device capabilities, the knowledge base can provide baseline information on device capabilities for the large model, enabling the model to quickly identify the hardware or software limitations of target devices when analyzing user feedback, thereby accurately determining whether they possess specific functional capabilities, such as whether they support 8K playback. In addition, the knowledge base also stores business rules, including capability on / off dependencies, testing strategy specifications, limitations of different platforms, and logical constraints between blacklist / whitelist parameters. For example, some functions can only be enabled on specific system versions or higher, or the activation of certain capabilities requires meeting minimum performance standards. This type of rule information is clearly presented in tabular form, enabling the large model to automatically adhere to business constraints when generating capability adjustment results, avoiding decisions that violate business specifications. Simultaneously, the knowledge base includes functional configuration descriptions, recording the detailed meaning, configurable parameters, functional purpose, and typical adaptation scenarios for each capability item. For example, it records the configuration fields, optional states, and applicable device range for the "8K playback capability switch," allowing the large model to understand the business logic behind the capability items and thus more accurately generate processing strategies based on feedback. The knowledge base also includes specific capability location descriptions to assist the model in identifying the root cause of problems. For example, it identifies potential hardware bottlenecks, system limitations, or compatibility issues that may arise when different devices experience playback anomalies, helping the model automatically extract the source of problems such as missing device capabilities or configuration conflicts from the feedback. Finally, the knowledge base includes access control policies to define the permitted scope of capability changes for different roles or test scenarios. For example, some test tickets have the permission to modify capability switches, while some scenarios only allow viewing capability status without performing changes. By incorporating access control policies, the large model can automatically determine whether the corresponding capability can be adjusted during inference and provide suggested solutions that comply with permissions in the returned results. By organizing and storing the above information in tabular form, the business knowledge base not only boasts high readability and a clear structure, but also facilitates subsequent system expansion and maintenance. Large models can quickly locate relevant entries when accessing the knowledge base through methods such as vector retrieval, enabling efficient knowledge-enhanced reasoning.

[0041] As an optional example, feedback information and business data are input into the target large model, enabling the target large model to perform semantic understanding and rule-based reasoning based on the feedback information and business data, combined with a business knowledge base, to generate blacklist and whitelist change suggestions, including: Key fact information is extracted from feedback information and business data. This key fact information includes device identification, device model, firmware version, function switch status, and error information. Retrieve business rules, functional configuration descriptions, specific positioning capabilities, and access control strategies related to key factual information from the business knowledge base to obtain search results; Based on the prompt template, key factual information, and search results, semantic understanding and rule reasoning are performed to analyze the permission status, functional availability, and abnormal situations of the target device, and to obtain the analysis results. Based on the analysis results, suggestions for changing the blacklist and whitelist are generated, which include adding, modifying, or deleting entries.

[0042] Optionally, in this embodiment, after the custom business service inputs feedback information and business data into the target big model, it utilizes the big model's language understanding and rule reasoning capabilities, combined with the structured support provided by the business knowledge base, to complete an intelligent analysis of the target device's capability status, thereby automatically generating device blacklist / whitelist change suggestions. This process first includes extracting key factual information from the feedback information and business data to clarify the basic attributes and functional performance of the device involved in the current feedback. Key factual information typically covers device identification, device model, firmware version, function switch status, error messages, and the device's actual performance in the current operation. For example, when a user reports "Device with ID 14061 failed to play 8K video," the custom business service will automatically identify the device's unique identifier, test scenario, failure performance, and current application configuration from the feedback. After extracting the key factual information, the custom business service further retrieves business rules and configuration backgrounds related to the aforementioned key factual fields from the business knowledge base. By using vector matching or keyword retrieval, the system can automatically locate entries related to the current device's capabilities, such as "8K playback capability is only enabled on devices with certain resolutions" or "devices with firmware versions below a certain threshold cannot enable high-bitrate playback capability," and use this as background information for inference. After obtaining the prompt template, key factual information, and knowledge base retrieval results, the big data model performs semantic understanding and rule-based inference according to the preset prompt structure. Based on this, the big data model can infer elements such as the target device's permission status (whether the capability switch can be adjusted), functional availability (whether the device meets the conditions for enabling the function), and the source of the anomaly (possible reasons for the problem). For example, the big data model may conclude that the device belongs to a series of models that do not support 8K playback, so the capability should be disabled in the blacklist and whitelist; or, based on the permission policy, it may determine that the current user has the permission to modify the capability switch, and a new configuration should be automatically generated to meet the user's needs. Finally, the custom business service constructs blacklist and whitelist change suggestions based on the analysis results generated by the big data model. The change suggestions will specify the specific operations to be performed on the original blacklist and whitelist files, including adding a capability entry, modifying the capability status of an existing entry, or deleting configuration items that are no longer applicable. All recommendations strictly adhere to business rules and device capability limitations to ensure that the generated blacklists and whitelists meet user needs while maintaining the overall consistency and security of the business system.

[0043] As an optional example, processing the original blacklist and whitelist of the target device based on blacklist / whitelist change recommendations to generate a new blacklist / whitelist that meets user requirements includes: Based on the recommendations for changing the blacklist and whitelist, entries in the original blacklist and whitelist are added, modified, or deleted to generate a new blacklist and whitelist in a structured format.

[0044] Optionally, in this embodiment, after receiving suggestions for changing the blacklist and whitelist, the custom business service processes the original blacklist and whitelist of the target device based on these suggestions to generate a new blacklist and whitelist that meets the user's requirements. First, the custom business service parses each operation instruction in the change suggestion to determine whether it adds, modifies, or deletes entries from the original blacklist and whitelist. Adding an entry typically involves adding a new capability or device identifier to the blacklist or whitelist, ensuring that the newly added device or capability status can be recognized and executed by the system. Modifying an entry updates the status of existing entries, such as adjusting the on / off state of a function switch to match the capability requirements raised in user feedback. Deleting an entry removes entries that are no longer applicable or incorrect, avoiding redundant or conflicting information in subsequent scheduling or device management. In the specific processing, a structured data format is used to represent the new blacklist and whitelist, such as JSON, XML, or other parsable key-value pairs. Each entry contains fields such as device identifier, capability, current status, reason for change, and scope of effect, making the generated blacklist and whitelist easy for downstream systems to automatically parse and execute, and also easy for testers or operations teams to view, verify, and debug. The generated results are also subject to consistency checks to ensure that newly added or modified entries do not violate business rules, conflict with permission policies, or align with the actual support scope of the device capabilities. Furthermore, the processing workflow automatically records change history and log information, including operation time, change source, trigger feedback number, and involved devices and capabilities, facilitating subsequent traceability and auditing. This approach enables dynamic updates and automated maintenance of blacklists and whitelists, making device capability management more refined and controllable.

[0045] As an optional example, uploading the new blacklist and whitelist to a cloud storage platform and providing the user with a download link containing the new blacklist and whitelist as feedback on the processing results includes: Upload the new blacklist and whitelist to the cloud storage platform so that the cloud storage platform can generate download links for the new blacklist and whitelist; The chatbot will send the processing results, including the download link, back to the user.

[0046] Optionally, in this embodiment, after generating a new blacklist and whitelist for the target device, the custom business service will automatically execute a file upload and user feedback process to ensure that the latest capability configuration can be delivered to the user quickly and securely. First, the custom business service uploads the newly generated blacklist and whitelist file to the cloud storage platform. During the upload process, a structured storage method can be selected, such as using JSON or XML format, to save the file completely to the cloud storage path. The cloud storage platform automatically generates a unique download link for the file, pointing to the latest version of the blacklist and whitelist file, and can set access control according to permission policies to ensure that only authorized users or systems can access and download the file. Subsequently, the processing result is fed back to the user via a chatbot. The feedback includes a prompt indicating that the operation is complete and a download link for the new blacklist and whitelist, enabling the user to directly obtain the latest file for testing, verification, or business operations. The chatbot can add explanations based on the user's access permissions or role, such as the scope of file effectiveness, a summary of changes, or precautions, enhancing the understandability and operability of the information. Furthermore, the chatbot can record the user's download behavior and operation logs, forming a complete interaction history for subsequent tracking, auditing, or anomaly handling. By seamlessly integrating the file upload and download link feedback process with a chatbot, end-to-end automated distribution of blacklists and whitelists is achieved, eliminating reliance on manual sending or file retrieval, thereby improving operational efficiency and user experience. Simultaneously, combined with the version control and access control functions of the cloud storage platform, every change to the blacklist and whitelist is ensured to be traceable and verifiable, meeting business specifications and security requirements.

[0047] Optionally, users can easily and quickly configure the features they need through interaction with a chatbot, without requiring complex operations or in-depth technical expertise. This convenient method significantly enhances the user experience. Users simply need to communicate with the chatbot using natural language, describing their functional requirements or making specific requests. The chatbot can intelligently recognize the user's intent and accurately complete the corresponding configuration tasks. This method is not only simple to operate but also helps users reduce tedious manual processing steps, significantly saving considerable time and human resources. Compared to the inefficient operations of traditional methods such as gradually adjusting parameters in the background and manually entering configuration data, AI chat-based configuration enables real-time response and efficient processing. Furthermore, it does not require users to have in-depth technical backgrounds, making feature design and development more user-friendly and easier to learn. In short, through the configuration function of AI chatbot, users can complete the design and development of complex functions in a more intelligent, faster, and more convenient way, significantly shortening project implementation time, releasing more team productivity, achieving business goals at the fastest speed, and bringing comprehensive efficiency improvements and optimized user experience.

[0048] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0049] According to another aspect of the embodiments of this application, a device for managing device blacklists and whitelists is also provided, such as... Figure 4 As shown, it includes: The identification module 402 is used to receive feedback information input by the user and identify the feedback identifier, device problem type and user request in the feedback information; The first processing module 404 is used to obtain the business data of the target device from the business backend according to the feedback identifier, and input the feedback information and business data into the target big model, so that the target big model can perform semantic understanding and rule reasoning based on the feedback information and business data, combined with the business knowledge base, to generate blacklist and whitelist change suggestions. The second processing module 406 is used to process the original blacklist and whitelist of the target device based on the blacklist and whitelist change suggestions, and generate a new blacklist and whitelist that meets the user's requirements. Feedback module 408 is used to upload the new blacklist and whitelist to the cloud storage platform and provide the user with the processing results, which include download links for the new blacklist and whitelist.

[0050] It should be noted that the identification module 402 in this embodiment can be used to execute step S102 in this application embodiment, the first processing module 404 in this embodiment can be used to execute step S104 in this application embodiment, the second processing module 406 in this embodiment can be used to execute step S106 in this application embodiment, and the feedback module 408 in this embodiment can be used to execute step S108 in this application embodiment.

[0051] As an optional example, the above-described apparatus further includes: Create a module to build a chatbot that receives user input feedback information before it receives user input feedback information.

[0052] As an optional example, the above-described apparatus further includes: The first construction module is used to build a prompt template for the inference of the target large model before inputting feedback information and business data into the target large model. The prompt template includes business rule descriptions, device information formats, constraints for generating blacklists and whitelists, and output structure requirements.

[0053] As an optional example, the above-described apparatus further includes: The second construction module is used to build a tabular business knowledge base before inputting feedback information and business data into the target large model. The business knowledge base includes device information, business rules, functional configuration instructions, specific positioning capabilities, and access control policies.

[0054] As an optional example, the first processing module includes: The extraction unit is used to extract key fact information from feedback information and business data. The key fact information includes device identification, device model, firmware version, function switch status, and error information. The retrieval unit is used to retrieve business rules, functional configuration instructions, specific positioning capabilities, and access control strategies related to key factual information from the business knowledge base and obtain retrieval results. The analysis unit is used to perform semantic understanding and rule reasoning based on prompt templates, key factual information and search results to analyze the permission status, functional availability and abnormal situations of the target device and obtain analysis results. The generation unit is used to generate blacklist / whitelist change suggestions based on the analysis results. These suggestions include adding, modifying, or deleting entries.

[0055] As an optional example, the second processing module includes: The processing unit is used to add, modify, or delete entries in the original blacklist and whitelist based on the blacklist and whitelist change suggestions, and generate a new blacklist and whitelist in a structured format.

[0056] As an optional example, the feedback module includes: The upload unit is used to upload the new blacklist and whitelist to the cloud storage platform so that the cloud storage platform can generate download links for the new blacklist and whitelist. The feedback unit is used to send the processing results, including the download link, to the user via a chatbot.

[0057] For other examples of this embodiment, please refer to the examples above, which will not be repeated here.

[0058] Figure 5 This is a schematic diagram of an optional electronic device according to an embodiment of this application, such as... Figure 5 As shown, it includes a processor 502, a communication interface 504, a memory 506, and a communication bus 508. The processor 502, communication interface 504, and memory 506 communicate with each other via the communication bus 508. Memory 506 is used to store computer programs; When processor 502 executes a computer program stored in memory 506, it performs the following steps: Receive user feedback information and identify feedback identifiers, device problem types, and user requests in the feedback information; Based on the feedback identifier, the business data of the target device is obtained from the business backend, and the feedback information and business data are input into the target big model. The target big model then uses the feedback information and business data, combined with the business knowledge base, to perform semantic understanding and rule reasoning to generate blacklist and whitelist change suggestions. Based on the blacklist / whitelist change recommendations, the original blacklist / whitelist of the target device is processed to generate a new blacklist / whitelist that meets the user's requirements; The new blacklists and whitelists will be uploaded to the cloud storage platform, and the processing results, including download links for the new blacklists and whitelists, will be fed back to the users.

[0059] Optionally, in this embodiment, the communication bus can be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The symbol is represented by a single thick line, but this does not indicate that there is only one bus or one type of bus. The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0060] The memory may include RAM, or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0061] As an example, the memory 506 described above may include, but is not limited to, the identification module 402, the first processing module 404, the second processing module 406, and the feedback module 408 from the device blacklist / whitelist management device described above. Furthermore, it may include, but is not limited to, other module units from the device blacklist / whitelist management device described above, which will not be elaborated upon in this example.

[0062] The processor mentioned above can be a general-purpose processor, including but not limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0063] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0064] Those skilled in the art will understand that Figure 5 The structure shown is for illustrative purposes only. The devices implementing the above-mentioned device blacklist and whitelist management method can be terminal devices, such as smartphones (e.g., Android phones, iOS phones), tablets, PDAs, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 5 This does not limit the structure of the aforementioned electronic devices. For example, the electronic device may also include components that are more... Figure 5 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 5 The different configurations shown.

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

[0066] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, which, when executed by a processor, performs the steps in the above-described device blacklist / whitelist management method.

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

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

[0069] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

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

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

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

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

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

Claims

1. A method for managing device blacklists and whitelists, characterized in that, include: Receive feedback information input by the user, and identify the feedback identifier, device problem type, and user request in the feedback information; Based on the feedback identifier, the business data of the target device is obtained from the business backend, and the feedback information and the business data are input into the target big model, so that the target big model, based on the feedback information and the business data, combined with the business knowledge base, performs semantic understanding and rule reasoning to generate blacklist and whitelist change suggestions. Based on the proposed blacklist / whitelist change, the original blacklist / whitelist of the target device is processed to generate a new blacklist / whitelist that meets the user's requirements; The new blacklist and whitelist are uploaded to the cloud storage platform, and the processing result, which includes a download link for the new blacklist and whitelist, is fed back to the user.

2. The method according to claim 1, characterized in that, Before receiving user input feedback, the method further includes: Create a chatbot to receive feedback information from the user's input.

3. The method according to claim 1, characterized in that, Before inputting the feedback information and the business data into the target large model, the method further includes: Construct a prompt template for inference of the target large model, wherein the prompt template includes a description of business rules, device information format, constraints for generating blacklists and whitelists, and output structure requirements.

4. The method according to claim 1, characterized in that, Before inputting the feedback information and the business data into the target large model, the method further includes: Construct a business knowledge base in tabular form, wherein the business knowledge base includes device information, business rules, function configuration descriptions, specific positioning capabilities, and access control policies.

5. The method according to claim 3, characterized in that, The feedback information and the business data are input into the target large model, so that the target large model, based on the feedback information and the business data, and in conjunction with the business knowledge base, performs semantic understanding and rule reasoning to generate blacklist / whitelist change suggestions, including: Key fact information is extracted from the feedback information and the business data, including device identifier, device model, firmware version, function switch status, and error information. Retrieve business rules, functional configuration descriptions, specific positioning capabilities, and access control strategies related to the key fact information from the business knowledge base to obtain search results; Based on the prompt template, the key factual information, and the search results, semantic understanding and rule reasoning are performed to analyze the permission status, functional availability, and abnormal situations of the target device, and to obtain the analysis results. The blacklist and whitelist change suggestions are generated based on the analysis results, wherein the blacklist and whitelist change suggestions include adding, modifying or deleting entries.

6. The method according to claim 1, characterized in that, Based on the proposed blacklist / whitelist change, the original blacklist / whitelist of the target device is processed to generate a new blacklist / whitelist that meets the user's requirements, including: Based on the proposed changes to the blacklist and whitelist, entries in the original blacklist and whitelist are added, modified, or deleted to generate a new blacklist and whitelist in a structured format.

7. The method according to claim 2, characterized in that, Uploading the new blacklist and whitelist to the cloud storage platform and providing the user with the processing result, which includes a download link for the new blacklist and whitelist, includes: The new blacklist and whitelist are uploaded to the cloud storage platform so that the cloud storage platform generates download links for the new blacklist and whitelist; The chatbot then sends the processing result, including the download link, back to the user.

8. A device for managing device blacklists and whitelists, characterized in that, include: The identification module is used to receive feedback information input by the user and identify the feedback identifier, device problem type, and user request in the feedback information; The first processing module is used to obtain the business data of the target device from the business backend according to the feedback identifier, and input the feedback information and the business data into the target big model, so that the target big model, based on the feedback information and the business data, combined with the business knowledge base, performs semantic understanding and rule reasoning to generate blacklist and whitelist change suggestions. The second processing module is used to process the original blacklist and whitelist of the target device based on the blacklist and whitelist change suggestions, and generate a new blacklist and whitelist that meets the user's requirements. The feedback module is used to upload the new blacklist and whitelist to the cloud storage platform and provide the user with the processing result containing the download link of the new blacklist and whitelist.

9. A computer-readable storage medium storing a computer program, characterized in that, The computer program is executed by the processor to perform the method described in any one of claims 1 to 7.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method described in any one of claims 1 to 7 through the computer program.

Images