A portal platform-based customer collaborative development method and device

Abstract

The application discloses a kind of based on portal platform's customer collaborative development method and device, comprising: in response to the demand information submitted by customer, generate the visual demand card containing function description, data structure and business type;Demand card is extracted to generate demand feature vector, input knowledge base vector database and carry out cosine similarity matching, if there is similar degree target knowledge item reaching threshold, after compliance verification, reuse its interface resource and jump sand box, otherwise automatically generate interface definition, SDK example code, API document and simulation service;Provide sandbox environment for customer development with security isolation, and execute security verification and resource isolation to plug-in;Call automated test engine and test using simulation service, generate test report;After test, demand card, interface definition, implementation code and test report are archived to knowledge base, while feature vector is extracted and updated to vector database and triggers index reconstruction, form reusable knowledge item.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a client collaborative development method and apparatus based on a portal platform, used to bridge the computational logic of client-defined code with the platform's backend report generation service. Background Technology

[0002] With the increasing prevalence of enterprise software delivery and customer customization needs, achieving efficient, transparent, and secure customer collaborative development has become a challenge. Existing customer co-development models typically rely on traditional offline communication and manual transmission, such as exchanging requirements, interface definitions, and code snippets via email, instant messaging tools, or file sharing. In this model, information from the requirements, design, development, and testing stages is fragmented, lacking a unified medium and automated linkage mechanism, resulting in high communication costs, chaotic version management, and a high risk of misunderstandings. Customers often only participate at the requirements-raising stage, making it difficult to delve into the subsequent technical implementation and verification processes. This not only makes it difficult to accurately implement customer needs but also prolongs the feedback cycle and slows down the overall delivery schedule.

[0003] Furthermore, both AI-based code generation solutions and open collaborative development platforms only implement a linear development process of "requirement input - code generation - test delivery." They merely archive and store the knowledge assets generated during development, failing to achieve deep integration of accumulated reusable knowledge with the entire process of front-end requirement input, mid-end interface generation, and back-end testing and verification. Especially in collaborative development scenarios between clients and platforms, clients lack awareness of the reusable assets accumulated on the platform, easily leading to issues such as redundant development, incompatible interface definitions, and the inability to reuse development results across projects. Simultaneously, the accumulated knowledge assets cannot be used to optimize the accuracy and efficiency of requirement parsing and interface generation, failing to form a self-optimizing collaborative development loop, further increasing the communication costs and development cycle for clients. Summary of the Invention

[0004] This specification provides a client collaborative development method and apparatus based on a portal platform to solve at least one of the technical problems mentioned above.

[0005] According to a first aspect of the present invention, a client collaborative development method based on a portal platform is provided, applied to a developer portal platform, the method comprising: In response to the requirements submitted by the customer through the developer portal, a visual requirement card containing a unique identifier is generated. The requirement card includes at least a functional description, data structure, and business type. The function description, data structure, and business type in the visualized requirement card are used to extract features to generate requirement feature vectors. These vectors are then input into the knowledge base vector database for cosine similarity matching. If there is a target knowledge item with a similarity greater than or equal to a preset similarity threshold, it is pushed to the client and its interface-related resources are reused after compliance verification, and the process is redirected to the sandbox environment. If the requirements are not met, the subsequent interface generation steps are executed. Based on the business type and data structure in the requirement card, the automated interface generation algorithm is invoked to automatically generate interface definitions and simultaneously generate corresponding software development kit (SDK) sample code, application programming interface (API) documentation, and API simulation services. Provide a secure and isolated sandbox environment for customers to develop functions based on the interface definition and SDK sample code, and receive implementation code submitted in the form of plugins; wherein, security verification and resource isolation are performed on the plugins; Based on the interface definition, the automated testing engine is invoked and the API simulation service is used to test the implementation code, generating a test report containing test coverage and performance metrics. If the test passes, the requirement card, interface definition, implementation code, and test report will be automatically associated and archived to the knowledge base. At the same time, the requirement feature vector, interface feature vector, and code feature vector corresponding to the archived content will be extracted, updated to the knowledge base vector database, and the vector index will be rebuilt in real time to form reusable knowledge items.

[0006] In some alternative implementations, generating a visual requirement card containing a unique identifier includes: Analyze the requirements information to extract the functional description, data structure, and business type; Based on the extracted functional description, data structure, and business type, a requirement card with a unique number is generated. The requirement card includes at least the number, the functional description, the data structure, the business type, and status information used to characterize the process status. The functional description employs natural language semantic cleaning and standardization processing, and the data structure undergoes field normalization mapping for the standardized extraction of subsequent requirement feature vectors.

[0007] In some optional implementations, the automated interface generation algorithm is invoked to automatically generate interface definitions and simultaneously generate corresponding Software Development Kit (SDK) sample code, Application Programming Interface (API) documentation, and API simulation services, including: Based on the business type, select the corresponding interface template from the pre-set interface template library; For each field in the data structure, the parameter type is automatically derived based on its field type, and corresponding data validation rules are generated. Based on the interface template and the derivation results of each field, a complete interface definition is generated; Based on the complete interface definition, the corresponding SDK sample code, API documentation, and API simulation service are automatically generated.

[0008] In some alternative implementations, after generating the complete interface definition, the method further includes: Based on the interface definition and the data structure in the requirement card, calculate the consistency parameter between the interface definition and the data structure in the requirement card. The consistency parameter is the percentage of the number of matching fields between the two and the total number of fields. If the consistency parameter is greater than or equal to a preset threshold, the interface definition verification is deemed successful, and the subsequent steps of providing a sandbox environment are triggered.

[0009] In some optional implementations, performing security verification and resource isolation on the plugin includes: Parse the plugin to obtain its set of interface binding relationships and list of dependencies; Based on the set of interface binding relationships and the set of authorized access interfaces in the sandbox environment, verify whether the set of interface binding relationships is a subset of the set of authorized access interfaces in the sandbox environment; Based on the dependency list and the predefined security dependency whitelist, verify whether all dependencies in the dependency list are within the predefined security dependency whitelist; If all the above verifications pass, the plugin will be loaded and run in a resource-constrained independent container.

[0010] In some alternative implementations, the step of invoking the automated testing engine and using the API mock service to test the implementation code includes: Load the corresponding test case set according to the interface definition; Using the API simulation service, execute the test case set in the sandbox environment and record the response status and response time of each test case; Based on the execution results of the test case set, calculate the test coverage. Calculate the average response time based on the recorded response times; If the test coverage is not lower than a preset coverage threshold and the average response time is not higher than a preset performance threshold, then the test is considered passed.

[0011] In some alternative implementations, the formation of reusable knowledge items includes: A unique knowledge item identifier is generated based on the interface definition and the version information of the implementation code; Using the knowledge item identifier as an index, and based on the requirement card number, interface definition, code version, test report, and reusable identifier, the requirement card number, interface definition, code version, test report, and reusable identifier are associated and stored to form a structured knowledge item; Extract the requirement feature vector, interface feature vector, and code feature vector corresponding to the knowledge item. After binding the feature vector with the knowledge item identifier, incrementally update it to the knowledge base vector database to complete the real-time synchronization of the vector index.

[0012] According to a second aspect of the present invention, a client collaborative development method based on a portal platform is provided, applied to a client accessing a developer portal platform, the method comprising: Submit requirement information to the developer portal platform and receive a visual requirement card generated and displayed by the platform based on the requirement information. The requirement card contains a unique identifier and includes at least a functional description, data structure, and business type. The system receives target knowledge items pushed by the platform that match the requirement card. These target knowledge items are obtained by the platform through cosine similarity matching between the requirement feature vector and the knowledge base vector database, and the similarity is greater than or equal to a preset threshold. After confirming that the target knowledge item has passed the platform's compliance verification, its interface-related resources are reused. If the platform does not push any target knowledge items that meet the conditions, the system receives the interface definition and corresponding software development kit (SDK) sample code automatically generated by the platform. Based on the interface-related resources or interface definitions and SDK sample code, functional development is carried out in the secure and isolated sandbox environment provided by the platform; The implementation code obtained from the feature development is submitted to the sandbox environment in the form of a plugin, so that the platform can perform security verification and resource isolation on the plugin; Trigger or confirm the automated testing of the implementation code by the platform based on the interface definition and using API simulation services, and obtain a test report containing test coverage and performance metrics; If the test passes, delivery is confirmed, so that the platform automatically links and archives the requirement card, interface definition, implementation code and test report to the knowledge base, and extracts the corresponding feature vector to update the knowledge base vector database to form reusable knowledge items.

[0013] According to a third aspect of the present invention, a client collaborative development apparatus based on a portal platform is provided, applied to a developer portal platform, the apparatus comprising: The requirement card generation module is used to generate a visual requirement card containing a unique identifier in response to the requirement information submitted by the customer through the developer portal. The requirement card includes at least a functional description, data structure and business type. The vector matching and reuse module is used to extract features from the functional descriptions, data structures, and business types in the visualized requirement cards to generate requirement feature vectors, which are then input into the knowledge base vector database for cosine similarity matching. If there are target knowledge items with a similarity greater than or equal to a preset threshold, they are pushed to the client and compliance verification is performed. If the verification is successful, the client can reuse its interface-related resources. If the verification is unsuccessful, the automatic interface generation process is triggered. The interface automatic generation module is used to automatically generate interface definitions based on the business type and data structure in the requirement card by calling the automated interface generation algorithm, and simultaneously generate the corresponding software development kit (SDK) sample code, application programming interface (API) documentation, and API simulation service. The sandbox environment management module provides a secure and isolated sandbox environment for customers to develop functions based on the interface definitions and SDK sample code, and receives implementation code submitted in the form of plugins; wherein, security verification and resource isolation are performed on the plugins; An automated test scheduling module is used to call an automated test engine based on the interface definition and use the API simulation service to test the implementation code, generating a test report containing test coverage and performance metrics. The knowledge accumulation and vector update module is used to automatically link and archive the requirement card, interface definition, implementation code and test report to the knowledge base if the test passes. At the same time, it extracts the requirement feature vector, interface feature vector and code feature vector corresponding to the archived content and updates it to the knowledge base vector database to form reusable knowledge items.

[0014] According to a fourth aspect of the present invention, a client collaborative development apparatus based on a portal platform is provided, applied to a client accessing a developer portal platform, the apparatus comprising: The requirement submission module is used to submit requirement information to the developer portal platform and receive a visual requirement card generated and displayed by the platform based on the requirement information. The requirement card contains a unique identifier and includes at least a functional description, data structure and business type. The knowledge item reuse module is used to receive target knowledge items pushed by the platform. The target knowledge items are obtained by the platform through cosine similarity matching between the demand feature vector and the knowledge base vector database, and the similarity is greater than or equal to a preset threshold. After confirming that the target knowledge item has passed the platform's compliance verification, its interface-related resources are reused. If the platform does not push target knowledge items that meet the conditions, the module receives the interface definition and corresponding SDK sample code automatically generated by the platform. The development execution module is used to develop functions and generate implementation code in a secure and isolated sandbox environment provided by the platform, based on the interface-related resources or interface definitions and SDK sample code. The plugin submission module is used to submit the implementation code obtained from the function development to the sandbox environment in the form of a plugin, so that the platform can perform security verification and resource isolation on the plugin; The test interaction module is used to trigger or confirm the platform's automated testing of the implementation code and obtain a test report containing test coverage and performance metrics. The delivery confirmation module is used to confirm delivery if the test passes, so that the platform can automatically link and archive the requirement card, interface definition, implementation code and test report to the knowledge base to form reusable knowledge items.

[0015] The technical solution of this application embodiment has the following beneficial effects: This technical solution responds to customer needs and generates visual requirement cards through a developer portal platform. Based on these cards, it automatically generates interface definitions and related resources, provides an integrated sandbox environment for development and testing, and finally automatically archives the results to form knowledge assets. This integrated customer collaborative development method can replace the traditional discrete development process that relies on offline communication, manual design, fragmented environments, and separate testing. It integrates multiple stages such as requirement proposal, solution design, development implementation, verification testing, and knowledge accumulation into an automated and traceable end-to-end process, thereby improving the efficiency and speed of customer collaboration, reducing communication costs and information discrepancies, and enabling the structured accumulation and efficient reuse of development assets.

[0016] This technical solution significantly reduces the rate of repetitive development in collaborative development with clients. Through semantic-level vector similarity matching, it accurately identifies existing knowledge items that match client needs. Clients can directly reuse mature interfaces, code, and supporting resources without starting from scratch, shortening the requirement implementation cycle. Simultaneously, it resolves the semantic ambiguity issue in clients' natural language requirement descriptions. Compared to traditional keyword matching, cosine similarity matching based on feature vectors achieves deeper semantic alignment, significantly improving matching accuracy, especially suitable for client input scenarios without technical expertise. Furthermore, it achieves a self-growing and self-optimizing closed loop for the knowledge base. Each archived knowledge item synchronously updates the vector database index, continuously improving the accuracy of subsequent requirement matching, allowing the platform's collaborative development capabilities to iterate with business accumulation. At the same time, through compliance verification, it ensures that reused knowledge items are fully aligned with the data structure and business type of client needs, guaranteeing the security and compatibility of reused interfaces and effectively reducing rework rates in subsequent testing and delivery. Attached Figure Description

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

[0018] Figure 1 A flowchart illustrating a client collaborative development method based on a portal platform, applicable to a developer portal platform, provided in this application embodiment; Figure 2 A flowchart illustrating a portal-based client collaborative development method for a client accessing a developer portal platform, provided in an embodiment of this application. Figure 3 A complete flowchart of the client collaborative development method based on a portal platform provided for the technical solution of this application; Figure 4 For corresponding Figure 1 A schematic diagram of a client collaborative development device based on a portal platform; Figure 5 For corresponding Figure 2 A schematic diagram of a client collaborative development device based on a portal platform. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of one or more embodiments of this specification clearer, the technical solutions of one or more embodiments of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of one or more embodiments of this specification.

[0020] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another.

[0021] This application provides a client collaborative development method and apparatus based on a portal platform, applicable to a developer portal platform. Figure 1 A flowchart of the client collaborative development method based on a portal platform provided in the embodiments of this application is shown below. Figure 1 As shown, the method may include the following steps: Step 102: In response to the requirement information submitted by the customer through the developer portal, generate a visual requirement card containing a unique identifier. The requirement card includes at least a functional description, data structure, and business type.

[0022] In this embodiment, when a client submits requirements through the developer portal, the portal platform can first respond to the submitted information. The client fills out a requirements form on the portal front end, which may include business background, a detailed description of the function, the required data structure, and the expected output format. After submission, the information is received and processed, and a requirements card is generated. This transforms the client's unstructured natural language description into a identifiable and processable standardized data object, providing a clear and consistent input basis for subsequent collaborative development.

[0023] Subsequently, a visual requirement card containing a unique identifier is generated based on the parsed information. The generation process of this visual requirement card is briefly described below. The card generation begins by parsing the requirement information to extract key elements such as functional descriptions, data structures, and business types. Each card can be assigned a unique number, such as an identifier represented by "N," and the extracted elements are associated with the number to form a structured card data model. This visual requirement card can at least include a number, functional description, data structure, and business type, and may also include extended fields such as title, priority, and status information for tracking the development process. Furthermore, the card can be presented to the client and development team with intuitive interface elements to ensure that both parties have a consistent understanding of the requirements.

[0024] Step 104: Extract features from the functional descriptions, data structures, and business types in the visualized requirement card to generate requirement feature vectors, and input them into the knowledge base vector database for cosine similarity matching; if there are target knowledge items with similarity greater than or equal to the preset similarity threshold, push them to the client and reuse their interface-related resources after compliance verification, and jump to the sandbox environment step; if they do not meet the standard, execute the subsequent interface generation step.

[0025] In this embodiment, after generating the visual requirement card, the portal platform does not directly enter the automatic interface generation process. Instead, it first performs intelligent semantic parsing and reuse prediction on the requirement card. Specifically, the platform extracts features from the functional description, data structure, and business type in the requirement card in multiple dimensions to generate a standardized requirement feature vector that can represent the core semantics of the requirement. This feature vector is used as query input and sent to a pre-built knowledge base vector database to perform cosine similarity matching calculation. This vector database stores the feature vectors corresponding to all archived knowledge items in the platform's history. By calculating the cosine value of the angle between the current requirement feature vector and the feature vectors of each historical knowledge item, the degree of semantic similarity between the two can be quantitatively evaluated. The platform can pre-set a similarity threshold. Only when the calculated similarity value reaches or exceeds the threshold is it considered that there is a reusable knowledge item that highly matches the current requirement.

[0026] Subsequently, different processing branches are triggered based on the matching results. If a match is successful, meaning there is a target knowledge item with a similarity greater than or equal to a preset threshold, the platform will push the target knowledge item to the client and automatically initiate a compliance verification process. Compliance verification ensures that the data structure, business type, and related test metrics of the knowledge item are fully aligned with the current customer requirements, avoiding compatibility issues caused by improper reuse. After successful verification, the customer can directly reuse the complete set of resources corresponding to the knowledge item, including interface definitions, SDK sample code, and API simulation services. The platform will then directly jump to the sandbox environment steps, eliminating the need to re-execute the interface generation process, thus significantly shortening the development cycle. Conversely, if no target knowledge item meets the similarity threshold, it is determined that the current requirement cannot reuse existing assets. The platform will continue with the subsequent automated interface generation steps according to the original process, customizing the interface definition and related resources for the new requirement.

[0027] In some optional implementations, the specific implementation process of feature extraction, similarity matching, compliance verification, and branch jump in step 104 above may include: Step 104a: Generation of the demand feature vector, specifically including: After generating the visual requirement card, the developer portal platform performs feature extraction and standardization on the core information within the requirement card. The specific process is as follows: For the functional description text in the requirement card, a pre-trained natural language processing model (such as BERT) is used for semantic encoding to extract semantic feature vectors with a preset semantic dimension (such as 768 dimensions); For the data structure in the requirement card, structured features such as field names, field types, and constraint rules are extracted and mapped to fixed-dimensional structured feature vectors; For the business type in the requirement card, a one-hot encoding method is used to generate a business classification feature vector; The above semantic feature vectors, structured feature vectors, and business classification feature vectors are concatenated and normalized to finally generate a standardized requirement feature vector with a preset standardized dimension (such as 1024 dimensions) to ensure that the feature vector dimensions corresponding to different requirements are consistent and to meet the comparison requirements of subsequent similarity matching.

[0028] Step 104b: Construction of the knowledge base vector database and similarity matching, specifically including: The developer portal platform includes a pre-built knowledge base vector database, which can be built using Milvus or FAISS. This database stores requirement feature vectors, interface feature vectors, and code feature vectors corresponding to all archived knowledge items. Each feature vector is bound to a unique identifier for its corresponding knowledge item, ensuring a one-to-one correspondence between vectors and knowledge items. The platform uses cosine similarity calculation to perform similarity calculations between the generated standardized requirement feature vectors and the requirement feature vectors of each knowledge item in the knowledge base vector database. The calculation formula is as follows: Where A is the standardized requirement feature vector corresponding to the current requirement, and B is the requirement feature vector corresponding to a certain archived knowledge item in the knowledge base vector database. The value range of the similarity calculation result is [0,1]. The higher the value of the calculation result, the higher the degree of matching between the current requirement and the knowledge item. The platform presets a similarity threshold (e.g., 0.85). When the similarity calculation result is greater than or equal to the preset threshold, the knowledge item is determined to be a target knowledge item that matches the current requirement. The platform pushes the target knowledge items to the client in descending order of similarity score. When the highest value of the similarity calculation result is less than the preset threshold, it is determined that there is no reusable target knowledge item, triggering the subsequent automated interface generation process (i.e., step 106).

[0029] Step 104c: Compliance verification of the target knowledge item, specifically including: For target knowledge items pushed to the client by the platform, the developer portal automatically performs compliance checks to ensure that the reused knowledge items are consistent with the current customer requirements and to guarantee the security and compatibility of the reused interfaces. Specific check rules are as follows: Data structure consistency check: comparing the data structure fields of the target knowledge item with those of the current requirement card. This field matching rate must not be lower than a preset field matching rate threshold (e.g., 95%); Business type compatibility check: confirming that the business type of the target knowledge item and the business type of the current requirement card belong to the same category; Availability check: confirming that the test coverage in the test report corresponding to the target knowledge item is not lower than a preset coverage threshold, and the average response time is not higher than a preset performance threshold. After all three checks pass, the client can choose to directly reuse the complete set of interface resources corresponding to the target knowledge item. The developer portal directly jumps to the steps provided in the sandbox environment (i.e., step 108), without repeating the automated interface generation process.

[0030] Step 104d: Incremental update of the vector database during archiving, specifically including: Once the implementation code developed by the customer passes the platform's automated testing and is archived, the developer portal platform simultaneously performs an incremental update operation on the knowledge base vector database. The specific process is as follows: According to the feature extraction rules in step 104a above, the requirement feature vector, interface feature vector, and code feature vector corresponding to the archived content are extracted; the above three types of feature vectors are bound to the unique identifier of the knowledge item generated this time and written into the knowledge base vector database; the vector database's vector index is triggered to rebuild in real time, completing the self-optimization update of the knowledge base, ensuring that the newly added knowledge item can be retrieved by the subsequent requirement matching process, and realizing the continuous iteration of the knowledge base.

[0031] Step 106: Based on the business type and data structure in the requirement card, call the automated interface generation algorithm to automatically generate interface definitions, and simultaneously generate the corresponding software development kit (SDK) sample code, application programming interface (API) documentation, and API simulation service.

[0032] In this embodiment, after generating the visual requirement card, the portal platform invokes a built-in automated interface generation algorithm based on the business type and data structure specified in the card. Specifically, the algorithm first selects a corresponding basic interface template from a pre-set interface template library as a framework based on the business type. Subsequently, the algorithm parses each field contained in the data structure one by one, automatically deriving the corresponding parameter type in the interface based on the field type of each field, and simultaneously generating corresponding data validation rules. For example, for string type fields, it derives length limits and regular expression matching rules, and for integer type fields, it derives their numerical range. Based on the selected interface template and the derivation results of each field, the algorithm automatically assembles and outputs a complete interface definition, which can specify the interface path, request method, parameter list, and its constraints. Following this, the generated complete interface is defined as a unified input source, and the portal platform simultaneously triggers the automatic construction of multiple related resources, including: (1) generating software development kit (SDK) sample code for multiple programming languages ​​to assist developers in quickly accessing the platform; (2) generating application programming interface (API) documentation that describes the interface functions, parameters and calling methods in detail; and (3) providing API simulation services that can simulate interface behavior for early functional integration and testing verification, thereby forming a set of standardized technical deliverables that are aligned with the original requirements and can be directly used in the subsequent development stage.

[0033] Step 108: Provide a secure and isolated sandbox environment for customers to develop functions based on the interface definition and SDK sample code, and receive implementation code submitted in the form of plugins; wherein, security verification and resource isolation are performed on the plugins.

[0034] In this embodiment, the portal platform provides a secure, isolated sandbox environment for feature development. This environment can exist as a virtualized, isolated runtime container and can include built-in access control rules for read / write interfaces, database access, plugin uploads, and API call simulation services. This allows customers to develop and debug based on the generated interface definitions and SDK sample code. Customers submit their completed feature code as a plugin. The plugin structure can include metadata, main code, a dependency list, and interface bindings. Upon receiving the plugin, the platform performs security verification. By parsing the plugin's interface bindings, it ensures that the plugin does not exceed the interface access scope authorized by the sandbox environment and verifies the dependency list to confirm that all dependencies are within the predefined security dependency whitelist. After successful verification, the plugin is loaded and run in a resource-constrained independent container, thereby achieving resource isolation.

[0035] Step 110: Based on the interface definition, call the automated testing engine and use the API simulation service to test the implementation code, and generate a test report containing test coverage and performance metrics.

[0036] In this embodiment, based on the defined interface, an automated testing engine is invoked to execute the testing process. The engine first loads a set of pre-defined test cases corresponding to the interface definition. During testing, the previously synchronously generated API simulation service is used to drive and execute these test cases in a secure, isolated sandbox environment, while simultaneously recording the response status and specific response time of each test case. Based on the execution results of all test cases, test coverage is automatically calculated. This coverage can be characterized by the percentage of successfully executed test cases to the total number of test cases. Simultaneously, the average response time, a performance metric, can be calculated based on the recorded response time data.

[0037] Step 112: If the test passes, the requirement card, interface definition, implementation code and test report will be automatically associated and archived to the knowledge base. At the same time, the requirement feature vector, interface feature vector and code feature vector corresponding to the archived content will be extracted, updated to the knowledge base vector database, and the vector index will be rebuilt in real time to form reusable knowledge items.

[0038] In this embodiment, when both test coverage and performance metrics meet preset thresholds, i.e., the test is deemed passed, the portal platform automatically associates and archives all deliverables generated during the collaborative development process. Specifically, the generated visual requirement cards and their unique numbers, the confirmed interface definitions, the customer-developed and verified implementation code and its version, and the test report containing detailed metrics such as test coverage and average response time are automatically collected and associated, and then archived as a whole to the knowledge base for persistent storage. Simultaneously, the platform can automatically extract the requirement feature vectors corresponding to the requirement cards, the interface feature vectors corresponding to the interface definitions, and the code feature vectors corresponding to the implementation code from the archived content. The requirement feature vectors can be generated according to the aforementioned feature extraction rules, the interface feature vectors can be obtained by parsing the structured information of the interface definitions, and the code feature vectors can be obtained by analyzing the abstract syntax tree of the implementation code. The platform binds the above three types of feature vectors to the unique identifiers of the knowledge items generated in this archive and writes them incrementally into the pre-built knowledge base vector database. After the writing is completed, the platform automatically triggers a real-time reconstruction operation of the vector index in the vector database, updating the index structure to include the newly added feature vectors. This ensures that the newly added knowledge items can be quickly and accurately retrieved in subsequent requirement matching processes. After archiving, this information collectively constitutes a structured and reusable knowledge item. At the same time, the knowledge base vector database completes self-optimization updates, forming a continuously iterative collaborative development knowledge loop.

[0039] Building upon the preceding content, the following explanation clarifies the meaning of the term "developer portal platform" mentioned earlier. This developer portal platform can be considered a centralized online access and collaboration environment for software developers or partners. It can be built by enterprises or service providers, and its purpose is to provide API interface documentation, software development kits (SDKs), code examples, test sandboxes, management consoles, and technical support resources through a standardized portal interface. This enables external developers to securely and independently access the platform's capabilities, thereby achieving ecosystem co-construction and business collaboration.

[0040] This technical solution responds to customer needs and generates visual requirement cards through a developer portal platform. Based on these cards, it automatically generates interface definitions and related resources, provides an integrated sandbox environment for development and testing, and finally automatically archives the results to form knowledge assets. This integrated customer collaborative development method can replace the traditional discrete development process that relies on offline communication, manual design, fragmented environments, and separate testing. It integrates multiple stages such as requirement proposal, solution design, development implementation, verification testing, and knowledge accumulation into an automated and traceable end-to-end process, thereby improving the efficiency and speed of customer collaboration, reducing communication costs and information discrepancies, and enabling the structured accumulation and efficient reuse of development assets.

[0041] Based on the technical solutions described above, this specification also provides some specific implementation schemes, which are described below.

[0042] In an optional embodiment, generating a visual requirement card containing a unique identifier may include: Analyze the requirements information to extract the functional description, data structure, and business type; Based on the extracted functional description, data structure, and business type, a requirement card with a unique number is generated. The requirement card includes at least the number, the functional description, the data structure, the business type, and status information representing the process status. The functional description undergoes natural language semantic cleaning and standardization, and the data structure undergoes field normalization mapping for subsequent standardized extraction of requirement feature vectors.

[0043] In this technical solution, the portal platform receives the client's submitted requirements and parses them to extract elements that support the subsequent collaborative development process. These elements include a clear functional description, a data structure defining fields and their types, and the specific business type to which the requirement belongs. The functional description must fully reflect the specific function and operational logic of the required software. To facilitate subsequent vectorized matching, the platform performs natural language semantic cleaning and standardization on the functional description text, such as removing stop words, performing lexical restoration, and standardizing terminology to reduce ambiguity. The data structure must clearly define the names of all data fields involved, their data types (e.g., strings, integers, dates), and their constraints. The platform normalizes the field names in the data structure, for example, mapping synonymous fields (e.g., "user ID", "userId", "user_id") to standard field identifiers, and mapping different but semantically similar data types to a unified type system. This eliminates matching interference caused by differences in field naming or inconsistent type representations, laying a data foundation for the standardized extraction of subsequent requirement feature vectors. The business type is used to accurately categorize the specific business scope to which the requirement belongs (e.g., order processing in the e-commerce field, transaction record inquiry in the financial field, employee information maintenance in the enterprise management field, etc.).

[0044] After extracting the above elements, a structured requirement card with a globally unique ID is generated. This requirement card can be constructed using a structured data model and includes information that at least covers the assigned unique ID, a parsed and confirmed functional description, a clearly defined data structure, the business type, and a status information that dynamically represents the stage of the requirement throughout the collaborative development process. The status information can be marked with different values ​​such as "Pending Design," "Under Design," "Under Development," "Under Testing," or "Delivered," depending on the progress of the process. This allows the requirement card to not only statically record the requirement content but also dynamically reflect and track its development lifecycle. After the semantic cleaning, standardization processing, and field normalization mapping described above, the core information in the requirement card has a unified format and computability, and can be directly used for the standardized extraction of subsequent requirement feature vectors. This ensures the comparability of vectors generated from different requirements and improves the accuracy of cosine similarity matching.

[0045] In an optional embodiment, the step of calling the automated interface generation algorithm to automatically generate interface definitions and simultaneously generate corresponding software development kit (SDK) sample code, application programming interface (API) documentation, and API simulation services may include: Based on the business type, select the corresponding interface template from the pre-set interface template library; For each field in the data structure, the parameter type is automatically derived based on its field type, and corresponding data validation rules are generated. Based on the interface template and the derivation results of each field, a complete interface definition is generated; Based on the complete interface definition, the corresponding SDK sample code, API documentation, and API simulation service are automatically generated.

[0046] In this embodiment, the portal platform maintains a pre-built interface template library. This library stores standardized interface frameworks categorized according to different business types (e.g., order processing, data querying, report generation, etc.). Based on this, the automated interface generation algorithm first automatically selects the most suitable interface template from the library as the skeleton for subsequent generation, based on the business type specified in the requirement card. After selecting a template, the algorithm then processes the data structure defined in the requirement card, iterating through each field. For each field, the algorithm automatically derives the parameter type to be used in the interface definition based on its declared field type (e.g., string, integer, date, etc.) and simultaneously generates corresponding data validation rules. For example, for string fields, the algorithm may automatically generate validation rules for length limits and specific regular expression matching; for integer fields, it automatically generates validation rules for numerical ranges.

[0047] After selecting the interface template and deriving all fields, the algorithm integrates the framework of the selected template with the specific parameter types and validation rules derived from each field to assemble a complete interface definition. This interface definition can specify the interface access path, request method (such as GET or POST), the names, types, constraints, and necessary security policies of all input and output parameters. Based on this, the portal platform simultaneously triggers the automated construction of multiple related development resources. This creation process has been described in step 104 above and will not be repeated here.

[0048] In an optional embodiment, after generating the complete interface definition, the method may further include: Based on the interface definition and the data structure in the requirement card, calculate the consistency parameter between the interface definition and the data structure in the requirement card. The consistency parameter is the percentage of the number of matching fields between the two and the total number of fields. If the consistency parameter is greater than or equal to a preset threshold, the interface definition verification is deemed successful, and the subsequent steps of providing a sandbox environment are triggered.

[0049] In this embodiment, after generating a complete interface definition, the portal platform calculates a consistency parameter between the interface definition and the data structure contained in the original requirement card. Specifically, this can be achieved by comparing the parameter fields included in the interface definition with the fields defined in the requirement card data structure. More specifically, it involves counting the number of fields that completely match between the two, dividing this number by the total number of fields in the data structure, and finally representing the consistency parameter as a percentage.

[0050] The calculated consistency parameter is then compared with a preset threshold. If the consistency parameter is greater than or equal to the preset threshold (e.g., 95%), it is determined that the automatically generated interface definition can accurately reflect the data structure of the original requirements, and the interface definition verification is passed.

[0051] In an optional embodiment, performing security verification and resource isolation on the plugin may include: Parse the plugin to obtain its set of interface binding relationships and list of dependencies; Based on the set of interface binding relationships and the set of authorized access interfaces in the sandbox environment, verify whether the set of interface binding relationships is a subset of the set of authorized access interfaces in the sandbox environment; Based on the dependency list and the predefined security dependency whitelist, verify whether all dependencies in the dependency list are within the predefined security dependency whitelist; If all the above verifications pass, the plugin will be loaded and run in a resource-constrained independent container.

[0052] In this embodiment, after the portal platform receives the implementation code submitted by the client in the form of a plugin, it first parses the plugin package, extracts the set of interface binding relationships that the plugin declares it needs to access, and the list of dependencies of the third-party components or libraries on which its implementation functions depend.

[0053] After parsing, the platform performs security verification. Specifically, it first compares the set of interface bindings declared by the plugin with the set of explicitly authorized access interfaces pre-defined in the current sandbox environment, verifying whether the former is a subset of the latter, to prevent the plugin from accessing unauthorized system interfaces. Secondly, it checks the plugin's dependency list against the platform's predefined security dependency whitelist, ensuring that each dependency is within the whitelist's allowed range, thus preventing the introduction of external components with security vulnerabilities or malicious code. Only when both of these verifications pass will the platform load and run the plugin in a newly created, strictly resource-limited (e.g., limited CPU core count and memory limits) independent container to achieve resource isolation and security control.

[0054] In an optional embodiment, the step of calling the automated testing engine and using the API simulation service to test the implementation code may include: Load the corresponding test case set according to the interface definition; Using the API simulation service, execute the test case set in the sandbox environment and record the response status and response time of each test case; Based on the execution results of the test case set, calculate the test coverage. Calculate the average response time based on the recorded response times; If the test coverage is not lower than a preset coverage threshold and the average response time is not higher than a preset performance threshold, then the test is considered passed.

[0055] In this embodiment, the automated testing engine automatically loads a set of pre-defined test cases that match the established interface definition from the associated test case library. Then, within the provided secure, isolated sandbox environment, it calls the previously synchronously generated API simulation service to simulate the real interface backend and drives the execution of these test cases. During execution, the engine records the response status (e.g., HTTP status code) of each test case and the complete response time from sending the request to receiving the response.

[0056] After the test execution is complete, based on the execution results of all test cases, the engine automatically calculates the test coverage rate, which is quantified by the percentage of test cases that were successfully executed (or asserted to pass) out of the total number of test cases. Simultaneously, based on all recorded response time data, the average response time is calculated to evaluate the interface's performance. Finally, the automated testing engine only determines that a round of testing has passed if the calculated test coverage rate is not lower than a preset coverage threshold and the average response time is not higher than a preset performance threshold.

[0057] In optional embodiments, the formation of reusable knowledge items may include: A unique knowledge item identifier is generated based on the interface definition and the version information of the implementation code; Using the knowledge item identifier as an index, and based on the requirement card number, interface definition, code version, test report, and reusability identifier, the requirement card number, interface definition, code version, test report, and reusability identifier are associated and stored to form a structured knowledge item; the requirement feature vector, interface feature vector, and code feature vector corresponding to the knowledge item are extracted, and after the feature vectors are bound to the knowledge item identifier, they are incrementally updated to the knowledge base vector database to complete the real-time synchronization of the vector index.

[0058] After the test is passed, this embodiment creates a unique identifier for reusable knowledge items. Specifically, the portal platform can take the final interface definition determined in this development cycle and the version information of the implementation code submitted by the customer (such as the commit hash or version number of the code repository) as input, process them through a specific algorithm (such as a hash function), and generate a globally unique knowledge item identifier.

[0059] Subsequently, the platform uses the generated unique knowledge item identifier as an index to perform structured archiving. Specifically, all digital assets generated during this collaborative development process can be linked and integrated. These assets may include: the unique number of the original visual requirement card, the verified complete interface definition, the specific version information of the implementation code, test reports containing detailed test coverage and performance metrics (such as average response time), and a Boolean identifier (i.e., a reusable identifier) ​​to clearly indicate whether the asset is open for reuse in future projects. These elements are logically linked and persistently stored as a structured whole data object in the knowledge base, thus forming a complete, searchable, and reusable knowledge item, providing a standardized foundation for solution reference and code reuse in subsequent projects.

[0060] Building upon the above, the platform can further extract the corresponding requirement feature vector, interface feature vector, and code feature vector for each knowledge item. The requirement feature vector is generated according to the aforementioned feature extraction rules (including semantic encoding of functional descriptions, field normalization mapping of data structures, and one-hot encoding of business types). The interface feature vector is obtained by parsing the method signature, parameter types, and return value structure in the interface definition. The code feature vector is generated by analyzing the abstract syntax tree of the implementation code, extracting features such as function call relationships, control flow graphs, and code complexity. The platform binds these three types of feature vectors to the unique identifier of the knowledge item and incrementally writes them into the pre-built knowledge base vector database. After writing, the platform automatically triggers real-time synchronization of the vector database's vector index, updating the index structure to include the newly added feature vectors, ensuring that the newly added knowledge item can be quickly and accurately retrieved in subsequent requirement matching processes. Through this process, the knowledge base vector database achieves self-optimizing closed-loop iteration, with each knowledge accumulation synchronously enhancing the platform's ability to match future requirements.

[0061] In some optional implementations, after standardizing and extracting the demand feature vector, the process may further include: Obtain the historical demand feature vector corresponding to each successfully matched target knowledge item in the historical matching record, and perform a dimension-by-dimensional difference calculation between the historical demand feature vector and the demand feature vector generated this time to generate a difference vector. Based on the dispersion of each dimension in the difference vector, a weight correction factor for each dimension is calculated, and the weight correction factor is negatively correlated with the dispersion. The weight correction factor is applied to the corresponding dimension of the demand feature vector to generate a dynamically weighted demand feature vector, and the dynamically weighted demand feature vector is used to replace the original demand feature vector to perform cosine similarity matching. The weight correction factor is incrementally updated after each successful match and client confirmation of reuse, based on the deviation between the actual similarity of the match and the preset similarity threshold.

[0062] In this embodiment, after generating a standardized demand feature vector, the portal platform further utilizes historical matching records to adaptively weight and optimize the current demand feature vector. Specifically, the platform can retrieve historical demand feature vectors corresponding to each successfully matched target knowledge item from the database. Then, it performs a dimensional difference calculation between these historical demand feature vectors and the currently generated demand feature vector. That is, for each dimension of the vector, it calculates the deviation between the current dimension value and the mean of that dimension across all historical successful matching records, combining the deviations of all dimensions to generate a difference vector. This difference vector reflects the degree of deviation between the current demand feature vector and historical successful matching patterns across each dimension.

[0063] Then, based on the dispersion (e.g., standard deviation or variance) of each dimension in the difference vector, the platform can calculate a weight correction factor for each dimension. This weight correction factor is negatively correlated with the dispersion; that is, the larger the dispersion, the stronger the volatility of the dimension in the current demand and the lower its historical reference value, thus assigning a smaller weight correction factor. Conversely, the smaller the dispersion, the more stable the dimension's features and the higher its discriminative power, thus assigning a larger weight correction factor. The platform multiplies the calculated weight correction factor dimension by dimension onto the corresponding dimension of the original demand feature vector to generate a dynamically weighted demand feature vector. This dynamically weighted demand feature vector is then used to replace the original demand feature vector for cosine similarity matching. Furthermore, after each successful match and client confirmation of reuse, the platform incrementally updates the weight correction factor based on the deviation between the actual similarity of this match and a preset similarity threshold: if the actual similarity is significantly higher than the threshold, the correction factor for the corresponding dimension is appropriately increased to strengthen its contribution; if the actual similarity is close to the lower limit of the threshold, the correction factor is appropriately decreased to avoid overfitting. Through this mechanism, the platform can dynamically optimize feature weights based on historical feedback, continuously improving the accuracy and robustness of demand matching.

[0064] In some optional implementations, the step of inputting the demand feature vector into a pre-built knowledge base vector database for cosine similarity matching may include: The first level of matching includes: using a graph-based approximate nearest neighbor search algorithm, constructing a graph index structure based on demand feature vectors in the knowledge base vector database, performing a greedy search with the current demand feature vector as the query point, and recalling the candidate knowledge items with the highest similarity ranking and a preset number of coarse matches; The second-level matching includes: extracting the interface feature vector and code feature vector corresponding to each candidate knowledge item from the preset number of candidate knowledge items, and performing joint similarity calculation with the current demand feature vector. The joint similarity calculation formula is: Sim_joint=α·Sim_demand+β·Sim_interface+γ·Sim_code. Where α, β, and γ are preset weight coefficients, and α+β+γ=1; Sim_demand is the cosine similarity of the demand feature vector; Sim_interface is the cosine similarity of the interface feature vector; and Sim_code is the cosine similarity of the code feature vector. The candidate knowledge items are reordered based on the joint similarity calculation results, and the knowledge item with the highest joint similarity after reordering and greater than or equal to a preset similarity threshold is output as the target knowledge item.

[0065] In this embodiment, when performing cosine similarity matching on the demand feature vectors, the portal platform adopts a two-level hierarchical matching strategy to balance retrieval efficiency and matching accuracy. The first-level matching uses a graph-based approximate nearest neighbor search algorithm. Specifically, the platform constructs a graph index structure (e.g., a hierarchical navigable small-world graph) based on the demand feature vectors of all archived knowledge items in a pre-built knowledge base vector database. Using the currently generated demand feature vector as the query point, a greedy search is performed starting from an entry node in the graph index: in each iteration, the similarity between all neighbor nodes of the current node and the query point is evaluated, and the node with the highest similarity is moved to the neighbor node. This process is repeated until no better node can be found, thereby recalling the top 50 or 100 candidate knowledge items with the highest similarity ranking. This first-level matching significantly narrows the retrieval scope through the approximate search of the graph index, avoiding exhaustive similarity calculations across the entire database and significantly improving matching efficiency.

[0066] The second-level matching process further refines and re-ranks the candidate knowledge items recalled in the first-level recall. Specifically, the platform extracts the interface feature vector and code feature vector corresponding to each candidate knowledge item, and calculates the joint similarity between these two vectors and the current requirement feature vector. The formula for calculating the joint similarity is: Sim_joint = α·Sim_demand + β·Sim_interface + γ·Sim_code, where α, β, and γ are preset weight coefficients, and their sum is 1. More specifically, Sim_demand is the cosine similarity between the current requirement feature vector and the candidate knowledge item requirement feature vector; Sim_interface is the cosine similarity between the current requirement feature vector and the candidate knowledge item interface feature vector (reflecting the degree of matching of the interface structure); and Sim_code is the cosine similarity between the current requirement feature vector and the candidate knowledge item code feature vector (reflecting the degree of matching of the code logic). After calculating the joint similarity of each candidate knowledge item, the platform reorders all candidate knowledge items in descending order based on the score. The knowledge item with the highest joint similarity after reordering and a score greater than or equal to a preset similarity threshold (e.g., 0.85) is then used as the final target knowledge item for matching. By introducing interface feature vectors and code feature vectors for multi-dimensional joint evaluation, this solution can further verify the compatibility of the interface structure and the reusability of the code logic based on requirement semantic matching, thereby improving the accuracy and reliability of knowledge item reuse.

[0067] In some optional implementations, the compliance verification may further include: Extract the dependency graph of the implementation code corresponding to the target knowledge item. The dependency graph uses nodes to represent dependent components and directed edges to represent the dependency relationships and version constraints between components. Extract the set of pre-defined dependent components in the current sandbox environment and construct an environment dependency graph; Performing dependency conflict prediction includes: traversing each node in the target knowledge item dependency graph and determining whether the node exists in the environment dependency graph; if it exists, further comparing whether the version constraint expression satisfies the preset semantic version compatibility rule; if it does not exist, marking the node as an external missing dependency; If there is at least one missing external dependency node in the target knowledge item dependency graph, or if the version constraint of at least one node does not meet the preset semantic version compatibility rules with the current version of the corresponding component in the environment dependency graph, a dependency compatibility warning will be generated, and the compliance verification of the target knowledge item will be judged as failing, preventing reuse.

[0068] In this embodiment, during the compliance verification process, the portal platform can further perform dependency compatibility analysis. Specifically, the platform extracts the dependency graph of the implementation code corresponding to the target knowledge item. This dependency graph uses nodes to represent the various dependent components (such as third-party libraries, middleware, or system modules) required for code execution, and directed edges to represent the dependency relationships and version constraints between components (e.g., "Component A depends on Component B at a version no lower than 1.2.0"). More specifically, the platform can recursively traverse all direct or indirect dependencies by parsing the package management configuration files (such as package.json, requirements.txt, or pom.xml) and import statements in the implementation code to construct a complete directed dependency graph. Simultaneously, the platform extracts the set of pre-installed dependent components and their version information in the current sandbox environment to construct an environment dependency graph. This environment dependency graph reflects all components installed and available in the customer's sandbox environment and their precise version numbers.

[0069] Then, the platform performs dependency conflict prediction, which may include: traversing each node (i.e., each dependent component) in the target knowledge item dependency graph and determining whether the node exists in the environment dependency graph. If the node exists in the environment dependency graph, it further compares the version constraint expression of the target knowledge item for that component (e.g., ">=2.0.0", "~1.3.5", or "2.x") with the current version of that component in the environment dependency graph to see if it meets the preset semantic version compatibility rules (e.g., the major version number is the same, the minor version number is not lower than the constraint requirement, etc.). If the node does not exist in the environment dependency graph, it is marked as an external missing dependency. Finally, if at least one node in the target knowledge item dependency graph is marked as an external missing dependency, or if at least one node's version constraint does not meet the preset semantic version compatibility rules with the current version of the corresponding component in the environment dependency graph, the platform generates a dependency compatibility warning and determines that the compliance check of the target knowledge item fails, preventing the client from reusing the knowledge item. Through the deep validation of the above dependency levels, this solution can effectively prevent runtime errors caused by missing dependencies or version conflicts, and ensure the stability and security of customers when reusing knowledge items in a sandbox environment.

[0070] Corresponding to the foregoing technical solutions, this application also provides a client-side collaborative development method based on a portal platform, applicable to clients accessing the developer portal platform, such as... Figure 2 As shown, the method may include: Step 202: Submit requirement information to the developer portal platform and receive a visual requirement card generated and displayed by the platform based on the requirement information. The requirement card contains a unique identifier and includes at least a functional description, data structure, and business type. Step 204: Receive the target knowledge item pushed by the platform that matches the requirement card. The target knowledge item is obtained by the platform through cosine similarity matching between the requirement feature vector and the knowledge base vector database, and the similarity is greater than or equal to a preset threshold. After confirming that the target knowledge item has passed the platform's compliance verification, reuse its interface-related resources. If the platform does not push a target knowledge item that meets the conditions, receive the interface definition and corresponding software development kit (SDK) sample code automatically generated by the platform. Step 206: Based on the interface-related resources or interface definitions and SDK sample code, perform functional development in the secure and isolated sandbox environment provided by the platform; Step 208: Submit the implementation code obtained from the function development to the sandbox environment in the form of a plugin, so that the platform can perform security verification and resource isolation on the plugin; Step 210: Trigger or confirm the automated test performed by the platform based on the interface definition and using the API simulation service to execute the implementation code, and obtain a test report containing test coverage and performance metrics; Step 212: If the test passes, confirm delivery so that the platform automatically links and archives the requirement card, interface definition, implementation code and test report to the knowledge base, and extracts the corresponding feature vector to update the knowledge base vector database to form reusable knowledge items.

[0071] Building upon the foregoing content, a complete implementation of the technical solution of this application is also provided, involving multi-stage interactions between the client / developer, portal frontend, collaboration platform, and resource backend. See Appendix. Figure 3 , Figure 3 A complete flowchart of the portal platform-based customer collaborative development method provided for the technical solution of this application is shown below. Figure 3 The complete embodiment will now be described.

[0072] The process begins with the client / developer submitting a requirement request through the portal frontend (Step 1). Upon receiving the request, the portal frontend sends an instruction to the collaboration platform to create a requirement card (Step 2). The collaboration platform generates a requirement card with a unique number and converts it into a visual format (Step 3). Subsequently, it drives the resource backend to automatically generate initial interface definitions, SDK sample code, and API simulation services based on the card content (Step 4). After completing the initial asset generation, the resource backend persistently stores the requirement card and related interface configuration information (Step 5) and returns the generated requirement card and interface resources to the portal frontend through the collaboration platform (Step 6), finally presenting it to the client / developer and completing the requirement deployment phase.

[0073] The second stage is the solution design process. Specifically, the client / developer initiates a collaborative design request through the portal frontend based on the initial solution (Step 7). The collaboration platform coordinates the design process and drives the resource backend to generate formal interface definitions, SDKs, API simulation services, and supporting documentation (Step 8). The resource backend updates and stores the formal interface assets (Step 9) and returns the finalized interface definitions to the collaboration platform (Step 10), which is then synchronized to the client / developer by the portal frontend to complete the refinement and confirmation of the solution. The third stage is the development and implementation process. Specifically, the client / developer applies for a sandbox development environment through the portal frontend (Step 11). After receiving the application, the collaboration platform instructs the resource backend to create a secure and isolated sandbox environment (Step 12). After the resource backend is created, it returns the access entry information of the sandbox environment to the portal frontend through the collaboration platform (Step 13). After obtaining the access, the client / developer develops functions in the sandbox environment and uploads the development results as plugins (Step 14). The resource backend performs security verification and resource isolation operations on the uploaded plugins (step 15), and returns the verification results and debugging output to the client / developer via the collaboration platform and portal frontend (step 16), supporting their development and debugging. The fourth stage is the verification testing process. Specifically, the client / developer submits test instructions through the portal frontend (step 17). The collaboration platform schedules the automated testing engine to drive the resource backend to execute test cases (step 18). After the resource backend runs the tests, it generates a test report containing test coverage and performance indicators (step 19), and returns the test results to the client / developer via the collaboration platform and portal frontend (step 20) for them to evaluate the quality of the function implementation. The fifth stage is the delivery and archiving process. Specifically, after the client / developer confirms that the test results meet expectations, they initiate delivery confirmation through the portal frontend (step 21). The collaboration platform then triggers the archiving process, instructing the resource backend to associate and integrate all assets generated in this process, such as requirement cards, interface definitions, implementation code, and test reports, to form structured reusable knowledge items and store them (step 22). After the resource backend completes the storage of knowledge items (step 23), it sends a completion notification to the collaboration platform. Finally, the portal frontend provides feedback to the client / developer on the completion of delivery (step 24), thus realizing the accumulation of all assets and the closed loop of the process.

[0074] Based on the preceding text Figure 1 In addition to the technical solutions described above, this invention also provides a client collaborative development device based on a portal platform, applicable to developer portal platforms, such as... Figure 4 As shown, the device, from a macroscopic perspective, may include the following modules: The requirement card generation module 402 is used to generate a visual requirement card containing a unique identifier in response to the requirement information submitted by the customer through the developer portal. The requirement card includes at least a functional description, data structure and business type. The vector matching and reuse module 404 is used to extract features from the functional descriptions, data structures, and business types in the visualized requirement cards to generate requirement feature vectors, and input them into the knowledge base vector database for cosine similarity matching; if there are target knowledge items with similarity greater than or equal to a preset threshold, they are pushed to the client and compliance verification is performed. If the verification is successful, the client can reuse its interface-related resources; if it does not meet the standard, the automatic interface generation process is triggered. The interface automatic generation module 406 is used to automatically generate interface definitions by calling an automated interface generation algorithm based on the business type and data structure in the requirement card, and simultaneously generate corresponding software development kit (SDK) sample code, application programming interface (API) documentation, and API simulation services. The sandbox environment management module 408 is used to provide a secure and isolated sandbox environment for customers to develop functions based on the interface definition and SDK sample code, and to receive implementation code submitted in the form of plugins; wherein, security verification and resource isolation are performed on the plugins; The automated test scheduling module 410 is used to call the automated test engine based on the interface definition and use the API simulation service to test the implementation code, and generate a test report containing test coverage and performance indicators. The knowledge accumulation and vector update module 412 is used to automatically associate and archive the requirement card, interface definition, implementation code and test report to the knowledge base if the test passes. At the same time, it extracts the requirement feature vector, interface feature vector and code feature vector corresponding to the archived content and updates them to the knowledge base vector database to form reusable knowledge items.

[0075] Similarly, based on the preceding text Figure 2 In addition to the technical solutions described above, this invention also provides a client-side collaborative development device based on a portal platform, applied to clients accessing the developer portal platform, such as... Figure 5 As shown, the device, from a macroscopic perspective, may include the following modules: The requirement submission module 502 is used to submit requirement information to the developer portal platform and receive a visual requirement card generated and displayed by the platform based on the requirement information. The requirement card contains a unique identifier and includes at least a functional description, data structure and business type. The knowledge item reuse module 504 is used to receive target knowledge items pushed by the platform. The target knowledge items are obtained by the platform through cosine similarity matching between the demand feature vector and the knowledge base vector database, and the similarity is greater than or equal to a preset threshold. After confirming that the target knowledge item has passed the platform's compliance verification, its interface-related resources are reused. If the platform does not push target knowledge items that meet the conditions, the module receives the interface definition and corresponding SDK sample code automatically generated by the platform. The development execution module 506 is used to develop functions and generate implementation code in a secure and isolated sandbox environment provided by the platform, based on the interface-related resources or interface definitions and SDK sample code. The plugin submission module 508 is used to submit the implementation code obtained from the function development to the sandbox environment in the form of a plugin, so that the platform can perform security verification and resource isolation on the plugin; The test interaction module 510 is used to trigger or confirm the platform's automated testing of the implementation code and obtain a test report containing test coverage and performance metrics. The delivery confirmation module 512 is used to confirm delivery if the test passes, so that the platform will automatically associate and archive the requirement card, interface definition, implementation code and test report to the knowledge base to form reusable knowledge items.

[0076] It should be noted that the above modules are only for illustrating the technical solution of this application from a macro perspective. In the actual design of the technical solution of this application, the functional modules can be developed in other module division forms.

[0077] Those skilled in the art will understand that the modules in the apparatus of the embodiments can be distributed in the apparatus of the embodiments as described in the embodiments, or they can be located in one or more devices different from this embodiment with corresponding changes. The modules of the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0078] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A portal platform-based customer collaborative development method applied to a developer portal platform, characterized in that, The method includes: In response to the requirements submitted by the customer through the developer portal, a visual requirement card containing a unique identifier is generated. The requirement card includes at least a functional description, data structure, and business type. The function description, data structure, and business type in the visualized requirement card are used to extract features to generate requirement feature vectors. These vectors are then input into the knowledge base vector database for cosine similarity matching. If there is a target knowledge item with a similarity greater than or equal to a preset similarity threshold, it is pushed to the client and its interface-related resources are reused after compliance verification, and the process is redirected to the sandbox environment. If the requirements are not met, the subsequent interface generation steps are executed. Based on the business type and data structure in the requirement card, the automated interface generation algorithm is invoked to automatically generate interface definitions and simultaneously generate corresponding software development kit (SDK) sample code, application programming interface (API) documentation, and API simulation services. Provide a secure and isolated sandbox environment for customers to develop functions based on the interface definition and SDK sample code, and receive implementation code submitted in the form of plugins; wherein, security verification and resource isolation are performed on the plugins; Based on the interface definition, the automated testing engine is invoked and the API simulation service is used to test the implementation code, generating a test report containing test coverage and performance metrics. If the test passes, the requirement card, interface definition, implementation code, and test report will be automatically associated and archived to the knowledge base. At the same time, the requirement feature vector, interface feature vector, and code feature vector corresponding to the archived content will be extracted, updated to the knowledge base vector database, and the vector index will be rebuilt in real time to form reusable knowledge items.

2. The portal platform based customer co-development method of claim 1, wherein, The generation of a visual requirement card containing a unique identifier includes: Analyze the requirements information to extract the functional description, data structure, and business type; Based on the extracted functional description, data structure, and business type, a requirement card with a unique number is generated. The requirement card includes at least the number, the functional description, the data structure, the business type, and status information used to characterize the process status. The functional description employs natural language semantic cleaning and standardization processing, and the data structure undergoes field normalization mapping for the standardized extraction of subsequent requirement feature vectors.

3. The client collaborative development method based on a portal platform as described in claim 1, characterized in that, The automated interface generation algorithm automatically generates interface definitions and simultaneously generates corresponding Software Development Kit (SDK) sample code, Application Programming Interface (API) documentation, and API simulation services, including: Based on the business type, select the corresponding interface template from the pre-set interface template library; For each field in the data structure, the parameter type is automatically derived based on its field type, and corresponding data validation rules are generated. Based on the interface template and the derivation results of each field, a complete interface definition is generated; Based on the complete interface definition, the corresponding SDK sample code, API documentation, and API simulation service are automatically generated.

4. The client collaborative development method based on a portal platform as described in claim 3, characterized in that, After generating the complete interface definition, the method further includes: Based on the interface definition and the data structure in the requirement card, calculate the consistency parameter between the interface definition and the data structure in the requirement card. The consistency parameter is the percentage of the number of matching fields between the two and the total number of fields. If the consistency parameter is greater than or equal to a preset threshold, the interface definition verification is deemed successful, and the subsequent steps of providing a sandbox environment are triggered.

5. The client collaborative development method based on a portal platform as described in claim 1, characterized in that, The security verification and resource isolation performed on the plugin include: Parse the plugin to obtain its set of interface binding relationships and list of dependencies; Based on the set of interface binding relationships and the set of authorized access interfaces in the sandbox environment, verify whether the set of interface binding relationships is a subset of the set of authorized access interfaces in the sandbox environment; Based on the dependency list and the predefined security dependency whitelist, verify whether all dependencies in the dependency list are within the predefined security dependency whitelist; If all the above verifications pass, the plugin will be loaded and run in a resource-constrained independent container.

6. The client collaborative development method based on a portal platform as described in claim 1, characterized in that, The step of calling the automated testing engine and using the API simulation service to test the implementation code includes: Load the corresponding test case set according to the interface definition; Using the API simulation service, execute the test case set in the sandbox environment and record the response status and response time of each test case; Based on the execution results of the test case set, calculate the test coverage. Calculate the average response time based on the recorded response times; If the test coverage is not lower than a preset coverage threshold and the average response time is not higher than a preset performance threshold, then the test is considered passed.

7. The client collaborative development method based on a portal platform as described in claim 1, characterized in that, The formation of reusable knowledge items includes: A unique knowledge item identifier is generated based on the interface definition and the version information of the implementation code; Using the knowledge item identifier as an index, and based on the requirement card number, interface definition, code version, test report, and reusable identifier, the requirement card number, interface definition, code version, test report, and reusable identifier are associated and stored to form a structured knowledge item; Extract the requirement feature vector, interface feature vector, and code feature vector corresponding to the knowledge item. After binding the feature vector with the knowledge item identifier, incrementally update it to the knowledge base vector database to complete the real-time synchronization of the vector index.

8. A client collaborative development method based on a portal platform, characterized in that, The method, applied to a client accessing a developer portal platform, includes: Submit requirement information to the developer portal platform and receive a visual requirement card generated and displayed by the platform based on the requirement information. The requirement card contains a unique identifier and includes at least a functional description, data structure, and business type. The system receives target knowledge items pushed by the platform that match the requirement card. These target knowledge items are obtained by the platform through cosine similarity matching between the requirement feature vector and the knowledge base vector database, and the similarity is greater than or equal to a preset threshold. After confirming that the target knowledge item has passed the platform's compliance verification, its interface-related resources are reused. If the platform does not push any target knowledge items that meet the conditions, the system receives the interface definition and corresponding software development kit (SDK) sample code automatically generated by the platform. Based on the interface-related resources or interface definitions and SDK sample code, functional development is carried out in the secure and isolated sandbox environment provided by the platform; The implementation code obtained from the feature development is submitted to the sandbox environment in the form of a plugin, so that the platform can perform security verification and resource isolation on the plugin; Trigger or confirm the automated testing of the implementation code by the platform based on the interface definition and using API simulation services, and obtain a test report containing test coverage and performance metrics; If the test passes, delivery is confirmed, so that the platform automatically links and archives the requirement card, interface definition, implementation code and test report to the knowledge base, and extracts the corresponding feature vector to update the knowledge base vector database to form reusable knowledge items.

9. A client collaborative development device based on a portal platform, applied to a developer portal platform, characterized in that, The device includes: The requirement card generation module is used to generate a visual requirement card containing a unique identifier in response to the requirement information submitted by the customer through the developer portal. The requirement card includes at least a functional description, data structure and business type. The vector matching and reuse module is used to extract features from the functional descriptions, data structures, and business types in the visualized requirement cards to generate requirement feature vectors, which are then input into the knowledge base vector database for cosine similarity matching. If there are target knowledge items with a similarity greater than or equal to a preset threshold, they are pushed to the client and compliance verification is performed. If the verification is successful, the client can reuse its interface-related resources. If the verification is unsuccessful, the automatic interface generation process is triggered. The interface automatic generation module is used to automatically generate interface definitions based on the business type and data structure in the requirement card by calling the automated interface generation algorithm, and simultaneously generate the corresponding software development kit (SDK) sample code, application programming interface (API) documentation, and API simulation service. The sandbox environment management module provides a secure and isolated sandbox environment for customers to develop functions based on the interface definitions and SDK sample code, and receives implementation code submitted in the form of plugins; wherein, security verification and resource isolation are performed on the plugins; An automated test scheduling module is used to call an automated test engine based on the interface definition and use the API simulation service to test the implementation code, generating a test report containing test coverage and performance metrics. The knowledge accumulation and vector update module is used to automatically link and archive the requirement card, interface definition, implementation code and test report to the knowledge base if the test passes. At the same time, it extracts the requirement feature vector, interface feature vector and code feature vector corresponding to the archived content and updates it to the knowledge base vector database to form reusable knowledge items.

10. A client collaborative development device based on a portal platform, characterized in that, A client device for accessing the developer portal platform, comprising: The requirement submission module is used to submit requirement information to the developer portal platform and receive a visual requirement card generated and displayed by the platform based on the requirement information. The requirement card contains a unique identifier and includes at least a functional description, data structure and business type. The knowledge item reuse module is used to receive target knowledge items pushed by the platform. The target knowledge items are obtained by the platform through cosine similarity matching between the demand feature vector and the knowledge base vector database, and the similarity is greater than or equal to a preset threshold. After confirming that the target knowledge item has passed the platform's compliance verification, its interface-related resources are reused. If the platform does not push target knowledge items that meet the conditions, the module receives the interface definition and corresponding SDK sample code automatically generated by the platform. The development execution module is used to develop functions and generate implementation code in a secure and isolated sandbox environment provided by the platform, based on the interface-related resources or interface definitions and SDK sample code. The plugin submission module is used to submit the implementation code obtained from the function development to the sandbox environment in the form of a plugin, so that the platform can perform security verification and resource isolation on the plugin; The test interaction module is used to trigger or confirm the platform's automated testing of the implementation code and obtain a test report containing test coverage and performance metrics. The delivery confirmation module is used to confirm delivery if the test passes, so that the platform can automatically link and archive the requirement card, interface definition, implementation code and test report to the knowledge base to form reusable knowledge items.

Images