A code modification method and system based on webpage framing and running state tracing

Abstract

The application discloses a code modification method and system based on webpage frame selection and running state tracing, and specifically comprises the following steps: determining a source code entity to be modified according to a modification request input by a user, combining a tracing relationship and a calling relationship of an associated source code entity; sending the modification request, the source code entity to be modified and a code context to a code generation agent to generate a code patch; applying the code patch to an isolated preview environment, re-rendering a target display area and obtaining a patch verification result; when the patch verification result meets a preset consistency condition, submitting the code patch to a code editor and positioning the source code entity to be modified, otherwise, adjusting the code patch or rolling back according to the patch verification result. The application realizes full-process automation from front-end visual problem discovery to accurate source code modification, and improves the development efficiency and code maintenance reliability in a complex webpage application scenario.

Description

Technical Field

[0001] This invention relates to the field of web page development technology, and in particular to a method and system for modifying code based on web page selection and runtime source tracing. Background Technology

[0002] In the process of web front-end development, developers usually need to modify the code based on the page's presentation. The typical workflow is as follows: first, observe the page for display errors or visual elements that need adjustment in the browser; then, manually switch to the code editor and use the element inspection function in the browser's developer tools to obtain the selector or DOM path information of the target element; and then, use methods such as filename retrieval and global text search to find potentially related components, style files, or script files in the project code.

[0003] However, in modern front-end projects, due to the widespread adoption of component-based architecture, style inheritance and cascading, the translation and packaging of source code by build tools, data-driven dynamic rendering, and server-side rendering, the final target element displayed in the browser and its source code location are often not a simple one-to-one correspondence. Instead, they involve component definitions, template logic, style rules, and event handlers scattered across multiple source files. This makes the process of manually locating relevant source code entities time-consuming, heavily reliant on the developer's personal experience, and prone to errors, leading to unintended modifications and increased debugging costs.

[0004] On the other hand, some existing visual editing solutions typically only allow synchronous editing within the editor on preset configuration files or fixed page templates, limiting their editing capabilities to specific frameworks and predefined structures. While other tools can collect DOM paths, coordinates, and style information of web page elements, they are mostly used for automated testing or user behavior analysis scenarios. They lack the ability to trace back the runtime elements of a rendered web page to multiple source code files, and they cannot automatically generate code modification results based on developers' intentions expressed in natural language, nor can they verify and roll back the modification results in a secure environment. Summary of the Invention

[0005] The purpose of this invention is to provide a code modification method and system based on webpage selection and runtime source tracing. This method can accurately and efficiently associate runtime elements with multiple related source code entities based on the intuitive operation of developers directly selecting target areas on a browser page. Furthermore, by leveraging natural language-driven modification intentions, it can complete code generation, verification, and secure submission, thereby solving at least one of the aforementioned problems in the prior art.

[0006] In a first aspect, the present invention provides a code modification method based on webpage selection and runtime source tracing, the method specifically including: In response to the user selecting a target display area on the browser page, obtain the corresponding target DOM node; Based on the target DOM node, extract the node's location, style, interaction, and construct mapping relationships to form runtime association information; Based on runtime association information, the associated source code entities are identified, and the source relationship between the target DOM node and the associated source code entities is established. Based on the user's modification request, and combined with the tracing relationship and the calling relationship of related source code entities, the source code entity to be modified is determined; Send the modification request, the source code entity to be modified, and the code context to the code generation agent to generate a code patch; Apply the code patch to the isolated preview environment, re-render the target display area, and obtain the patch verification results; When the patch verification result meets the preset consistency conditions, the code patch is submitted to the code editor and the source code entity to be modified is located; otherwise, the code patch is adjusted or rolled back according to the patch verification result.

[0007] Secondly, this invention provides a code modification system based on webpage selection and runtime source tracing, the system specifically comprising: The node acquisition module is used to retrieve the corresponding target DOM node in response to the user selecting a target display area on the browser page. The information association module is used to extract node location, style, interaction, and construct mapping relationships based on the target DOM node to form runtime association information; The relationship tracing module is used to determine the associated source code entities based on runtime association information and establish the tracing relationship between the target DOM node and the associated source code entities; The modification request module is used to determine the source code entity to be modified based on the user's modification request, combined with the tracing relationship and the calling relationship of the associated source code entity; The patch generation module is used to send modification requests, source code entities to be modified, and code context to the code generation agent to generate code patches. The patch verification module is used to apply code patches to the isolated preview environment, re-render the target display area, and obtain the patch verification results. The patch adjustment module is used to submit the code patch to the code editor and locate the source code entity to be modified when the patch verification result meets the preset consistency conditions; otherwise, the code patch is adjusted or rolled back according to the patch verification result.

[0008] Thirdly, the present invention provides a computer device, including: a memory and a processor, and a computer program stored in the memory, wherein when the computer program is executed on the processor, it implements the code modification method based on web page selection and runtime tracing as described in any of the above methods.

[0009] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when run by a processor, implements the code modification method based on webpage selection and runtime tracing as described in any of the above methods.

[0010] Compared with the prior art, the present invention has at least one of the following technical effects: 1. Based on the intuitive operation of developers directly selecting the target area on the browser page, runtime elements can be accurately and efficiently associated with multiple related source code entities, and with the help of natural language-driven modification intent, code generation, verification and secure submission can be completed.

[0011] 2. By organically integrating browser runtime page selection, multi-dimensional runtime tracing, natural language-driven code generation, and security verification and rollback, the entire process from front-end visual problem discovery to precise source code modification is automated, improving development efficiency and code maintenance reliability in complex web application scenarios.

[0012] 3. By extracting the positioning, style, interaction, and construction mapping relationships of target DOM nodes, runtime association information is formed. Based on this, multiple source code entities, such as component definitions, style definitions, and event handling functions, are matched in the source code index to establish a structured tracing relationship. This method can penetrate complex layers such as component nesting, style inheritance, and construction transformations, accurately associating runtime elements in the browser with code entities scattered across multiple source files, significantly improving positioning accuracy and fundamentally solving the problem of errors that are prone to occur during manual retrieval.

[0013] 4. Users can directly select the target display area as the modification entry point on the browser page. By parsing the natural language modification request and combining the tracing relationship and the call relationship of the source code entity, the system automatically determines the source code entity to be modified. Developers do not need to know the complete code structure and file division in advance; they can transform intuitive visual modification intentions into precise modification targets for specific code locations, significantly reducing the operational threshold and shortening the time from discovering a problem to determining the modification location.

[0014] 5. By sending modification requests, the source code entities to be modified, and their code context to the code generation agent, code patches can be automatically generated, directly translating the developer's natural language intent into context-appropriate code modifications. This method eliminates the need for manual code writing and adjustment, reduces syntax or logical errors caused by oversight, and improves the efficiency and quality of code modification.

[0015] 6. Before officially committing code patches to the source code files, apply the patches in an isolated preview environment and re-render the target display area. Verify the changes based on build status, page status, and content comparison results. Only commit to the code editor if the preset consistency conditions are met; otherwise, adjust the patches or perform a rollback based on the verification results. This mechanism ensures that every modification to the source code is tested against actual runtime effects, effectively preventing destructive modifications from being introduced into the project codebase and protecting the security of the development environment and code assets. Attached Figure Description

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

[0017] Figure 1 This is a flowchart illustrating a code modification method based on webpage selection and runtime source tracing according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the target DOM node acquisition structure provided in an embodiment of the present invention; Figure 3 This is a flowchart of patch submission, adjustment, and rollback state transition provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a code modification system based on webpage selection and runtime source tracing according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0018] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0019] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0020] In this application embodiment, the entity executing the process includes a terminal device. This terminal device includes, but is not limited to, devices capable of executing the methods disclosed in this application, such as servers, computers, smartphones, and tablets. Figure 1 A flowchart illustrating a code modification method based on webpage selection and runtime source tracing according to an embodiment of the present invention is shown below in detail: S101, responding to the user selecting the target display area on the browser page, obtains the corresponding target DOM node; S102, based on the target DOM node, extract the node location, style, interaction and build mapping relationship to form runtime association information; S103, Based on runtime association information, determine the associated source code entity and establish the tracing relationship between the target DOM node and the associated source code entity; S104. Based on the user's input modification request, and combining the tracing relationship and the calling relationship of the associated source code entities, determine the source code entity to be modified; S105, send the modification request, the source code entity to be modified, and the code context to the code generation agent to generate a code patch; S106, apply the code patch to the isolated preview environment, re-render the target display area, and obtain the patch verification result; S107: When the patch verification result meets the preset consistency conditions, submit the code patch to the code editor and locate the source code entity to be modified; otherwise, adjust the code patch or roll back according to the patch verification result.

[0021] The method provided in this embodiment is mainly applied in web front-end development scenarios and can be implemented collaboratively by browser plugins, development servers, code editor extensions, and code generation proxies. Developers directly select the page display area to be modified in the browser and input modification requests in natural language. The system assists developers in locating and modifying code through runtime information collection, source code tracing, patch generation, and isolation verification.

[0022] In this embodiment, after observing the page area that needs adjustment in the browser, the user can select the target display area by dragging the mouse. The system responds to the user's selection operation, records the position information of the selected area in the browser viewport, and matches the selected area with the rendering positions of various DOM nodes on the page. Specifically, the system can obtain candidate DOM nodes located within or overlapping with the selected area, and determine the target DOM node that best matches the user's selection intention by combining factors such as the overlap ratio between the candidate DOM nodes and the selected area, the visible rendering area of ​​the node, the node hierarchy, and whether the node has interactive attributes. In this way, the user can directly determine the runtime object that needs to be traced from the page display area without manually copying the selector or DOM path.

[0023] After identifying the target DOM node, the system further collects relevant information about that node in the page's runtime state. This runtime association information may include node location information, style association information, interaction association information, and construction mapping information.

[0024] The node location information can include the target DOM node's tag attributes, node identifier, class name, hierarchical path, and relationships with adjacent nodes, describing the target DOM node's position within the current page structure. Style association information can include the effective style rules applied to the target DOM node, style sources, style resource identifiers, and cascading relationships, identifying which style rules determine the target node's display effect. Interaction association information can include the event types bound to or propagated on the target DOM node and its ancestor nodes, event handling identifiers, and event propagation relationships, identifying code entry points related to user interaction behavior.

[0025] Meanwhile, in projects using modern front-end build tools, runtime page resources are typically generated by transcribing and packaging the source code. Therefore, the system can also query build artifact mapping information based on the component identifier, style resource identifier, or event handler identifier corresponding to the target DOM node, obtaining the mapping relationship between build resources and source code files. Through the associated storage of the above information, runtime association information oriented towards the target DOM node is formed.

[0026] After obtaining runtime association information, the system searches for the corresponding source code file in the project source code index based on the build resource identifier and source file location information. Furthermore, the system can match the component definition, template structure, or rendering logic of the target DOM node based on node location information to determine the source code entities related to page structure rendering; match the corresponding style definition based on style association information to determine the source code entities related to visual presentation; and match event handling functions or call entry points based on interaction association information to determine the source code entities related to interactive behavior.

[0027] Source code entities can be components, template fragments, style rules, functions, methods, configuration items, or other code units that can be located and modified. The system generates association records between the target DOM node and each source code entity. These association records can include the target DOM node identifier, source code entity identifier, source code file location, code fragment location, association type, and association confidence. The association type indicates whether the association is a rendering association, a style association, or an interaction association. This allows for the construction of a tracing relationship between the target DOM node and multiple source code entities, enabling runtime elements in the browser to be linked back to the project's source code.

[0028] After establishing the source relationship, users can input modification requests in natural language, such as adjusting text content, changing colors or spacing, adding clickable actions, or modifying button states. The system parses the modification requests, identifies the object to be modified, the content to be modified, and the scope of the modification, and determines the corresponding target association type based on the object to be modified. For example, when the modification request points to page layout, text structure, or component display content, the system prioritizes source code entities associated with rendering; when the modification request points to color, font, margins, or alignment, the system prioritizes source code entities associated with style; and when the modification request points to actions such as clicks, redirects, pop-ups, or form submissions, the system prioritizes source code entities associated with interaction.

[0029] Subsequently, the system uses the target DOM node as the starting object and, based on the aforementioned tracing relationship, obtains relevant candidate source code entities. It further analyzes the call relationships between these candidate source code entities, such as the caller entity, the called entity, and its component information. Combining the scope requirements of the modification request, the system determines the potentially affected code range within the call relationships. Finally, based on the matching degree between the candidate source code entities and the object to be modified, the strength of their association with the target DOM node, and the scope of influence, the system determines the final source code entity to be modified. This process reduces the probability of mislocation and erroneous modification.

[0030] After identifying the source code entity to be modified, the system obtains the target code fragment corresponding to that entity and extracts its associated code context. The code context may include the parent code structure of the target code fragment, definitions of referenced code, related calling code, and necessary project constraint information. Subsequently, the system encapsulates the modification request, the source code entity to be modified, the target code fragment, and the code context into a code generation task and sends it to the code generation agent.

[0031] The code generation agent generates candidate modification code based on the modification request and code context. After receiving the candidate modification code, the system compares it with the original target code snippet to form a code patch that can be applied to the project code. This code patch is not directly written to the developer's workspace, but enters the subsequent isolation verification stage to ensure the security and controllability of the modification results.

[0032] The system creates an isolated preview environment and loads a copy of the project code corresponding to the source code entity to be modified, along with its runtime dependencies, into this environment. Subsequently, the code patch is applied to the project code in the isolated preview environment, and a project build and page launch are performed to obtain the build and launch statuses.

[0033] When both the build and page launch states indicate success, the system reloads the target page according to the page state corresponding to the target DOM node, thereby re-rendering the target display area. The page state can include the target page path, routing parameters, necessary data states, scroll position, or pre-interaction states. After re-rendering, the system obtains the updated DOM node corresponding to the original target DOM node and extracts its display content, style attributes, and interaction response results.

[0034] The system compares the extracted results with the expected modifications corresponding to the modification request to obtain the content comparison results. The patch verification results can include the project build results, page execution results, and content comparison results, used to determine whether the code patch has achieved the expected effect and whether it has introduced unexpected page anomalies.

[0035] The system determines whether a code patch meets preset consistency conditions based on the patch verification results. These preset consistency conditions may include successful project build, successful page launch, display content or interactive effects in the target display area conforming to the modification request, and no significant unexpected changes.

[0036] When a code patch meets preset consistency conditions, the system writes the patch to the source code file corresponding to the entity being modified in the code editor. Based on the file path and code location of the entity being modified, the system automatically locates and displays the modified location in the code editor. This allows developers to directly view the changes and further confirm or edit them as needed.

[0037] When a code patch fails to meet preset consistency conditions, the system extracts adjustment criteria from the patch verification results, such as build failure information, page startup exception information, or content comparison difference information, and adjusts the code patch based on these criteria. The adjusted code patch can then be re-entered into the isolated preview environment for verification. If the adjusted code patch still fails to meet the preset consistency conditions, and the number of adjustments reaches a preset limit, the system reverts the applied code patch and restores the original source code corresponding to the entity to be modified, thereby preventing erroneous modifications from affecting the developers' actual project code.

[0038] Through the above embodiments, this application can establish an association between the target display area in the browser page and the components, styles, and interaction logic in the project source code, and automatically determine the source code entities to be modified, generate code patches, and perform isolation verification based on the user's natural language modification request. Compared with the traditional method that relies on manual retrieval and location, this application can improve the efficiency of front-end code location and modification, reduce the risk of accidental modification, and enhance the security of the code modification process through isolation preview and rollback mechanisms.

[0039] In some embodiments, step S101 above, which involves obtaining the corresponding target DOM node in response to a user selecting a target display area on a browser page, specifically includes: In response to mouse press events on the browser page, record the starting position of the selection box; In response to mouse movement events, a selection area is generated based on the starting position of the selection box and the current mouse position; In response to a mouse release event, retrieve candidate DOM nodes that are located within or intersect with the selected area. The node priority is determined based on the overlap ratio between each candidate DOM node and the selected area, the visible rendering area, the node level, and the interactive attributes. Candidate DOM nodes whose node priority meets the preset conditions are determined as the target DOM nodes corresponding to the target display area.

[0040] In this embodiment, when a user wants to modify a display element or display area on a browser page, they can trigger a selection box mode on the browser page. In selection box mode, the system listens for the user's mouse operations on the page. When a mouse press event is detected on the browser page, the system records the position of the mouse in the page coordinate system or viewport coordinate system at the time of the press, and uses this position as the starting position of the selection box. The starting position of the selection box can include a horizontal position and a vertical position, used to determine a boundary point of the selection area.

[0041] Subsequently, as the user holds down the mouse button and moves it, the system responds to mouse movement events, continuously acquiring the current mouse position and generating a selection area based on the initial selection position and the current mouse position. This selection area can dynamically change as the mouse moves and is displayed on the browser page as a semi-transparent rectangle, dashed border, or other visual representation, allowing the user to confirm the selected area. The boundaries of the selection area can be determined jointly by the initial selection position and the current mouse position, without requiring the user to drag in a fixed direction, thus accommodating different dragging methods such as from top left to bottom right, bottom right to top left, etc.

[0042] When a mouse release event is detected, the system assumes the user has selected the target display area. At this point, based on the final selected area, the system iterates through the DOM nodes currently being rendered in the browser page, retrieving candidate DOM nodes that are either within or intersect with the selected area. "Within the selected area" means the entire visible boundary of the DOM node falls within the selected area; "intersects with the selected area" means the visible boundary of the DOM node at least partially overlaps with the selected area. By simultaneously retrieving nodes that are completely within the selected area and those that partially intersect, the system avoids missing the true target node when the user's selection boundary is slightly off.

[0043] To avoid misidentifying numerous parent containers, background layers, or irrelevant decorative nodes on the page as target DOM nodes, this embodiment further determines the node priority of candidate DOM nodes based on multiple factors. Specifically, the system can comprehensively determine the node priority based on the overlap ratio between each candidate DOM node and the selected area, the visible rendering area, the node level, and interactive attributes.

[0044] The overlap ratio characterizes the degree of overlap between the display area of ​​the candidate DOM node and the user's selected area. Generally, the higher the overlap between the candidate DOM node and the selected area, the more likely the candidate DOM node is the page element the user wants to select. The visible rendering area characterizes the actual visible display area of ​​the candidate DOM node on the page. For invisible, too small, or severely obscured nodes, their node priority can be reduced to decrease the chance of hidden or auxiliary nodes being mistakenly selected.

[0045] Node hierarchy represents the depth of a candidate DOM node in the DOM tree and its parent-child relationships with other candidate nodes. In a real webpage, the area selected by the user may simultaneously cover a parent container and its child elements. If the parent container is large but the user's actual intention is to point to a specific child element, the priority of the more specific child node, which is closer to the visual content, can be increased based on the node hierarchy. If the selected area covers a complete component area, the corresponding parent container can be retained as a candidate target by combining the overlap ratio and the visible rendering area. Therefore, node hierarchy is not an isolated factor, but rather works in conjunction with the overlap ratio and the visible rendering area to determine the user's true selection intention.

[0046] Interactive attributes characterize whether candidate DOM nodes possess attributes or behaviors related to user actions. These include whether they are bound to click events, input events, navigation actions, form submission actions, or whether they belong to interactive elements such as buttons, input boxes, or links. When the target display area selected by the user involves interactive objects such as buttons, links, or input controls, candidate DOM nodes with interactive attributes are generally more in line with the user's modification intent, and therefore their node priority can be increased. Conversely, for nodes that only serve as layout backgrounds or wrapping containers, their priority can be reduced depending on the specific circumstances.

[0047] After determining the node priority of each candidate DOM node, the system identifies the candidate DOM node whose priority meets preset conditions as the target DOM node corresponding to the target display area. The preset conditions can be the highest node priority, a node priority exceeding a preset threshold, or the highest priority within the same level or component. If multiple candidate DOM nodes meet the preset conditions, the system can designate the highest-priority node as the primary target DOM node and save the remaining nodes as associated target nodes for subsequent source tracing analysis; alternatively, the system can determine the final target DOM node from multiple candidate nodes based on user confirmation.

[0048] Through the above processing, this embodiment can transform the user's intuitive selection operation on the browser page into a target DOM node with a clear DOM identity. Compared to simply relying on the user to manually copy the selector or using browser developer tools to search for elements layer by layer, this embodiment can reduce the complexity of operations and improve the accuracy of target DOM node identification by factors such as overlap ratio, visible rendering area, node level, and interactive attributes.

[0049] Combination Figure 2As shown, the left side is the browser page, displaying multiple candidate DOM nodes, including candidate DOM node A, candidate DOM node B, and candidate DOM node C. The user drags within the browser page to create a selection area as shown by the dotted line. This selection area has varying degrees of positional relationship with candidate DOM nodes A, B, and C: candidate DOM node A only partially overlaps with the selection area, candidate DOM node B also partially intersects with the selection area, and candidate DOM node C largely falls within the selection area.

[0050] After the mouse is released, the system retrieves candidate DOM nodes located within or intersecting the selected area, and inputs these candidate DOM nodes into the input field. Figure 2 The node priority determination process is shown on the right. The dashed box on the right lists several factors used to determine node priority, including overlap ratio, visible rendering area, node level, and interaction attributes. After comprehensively judging the above factors, the system determines the node priority of each candidate DOM node.

[0051] Figure 2 The "Target DOM Node" in the lower right corner represents the final node obtained after node priority judgment. In other words, candidate DOM nodes A, B, and C are not directly identified as target nodes simply because they intersect with the selected area. Instead, they are selected based on factors such as overlap with the selected area, page visibility, the node's hierarchical position in the DOM tree, and whether it possesses interactive attributes. This allows for more accurate identification of the target DOM node corresponding to the user-selected display area, providing a foundation for subsequent extraction of runtime association information and establishment of code source tracing relationships.

[0052] In some embodiments, step S102 above, which involves extracting node location, style, interaction, and constructing mapping relationships based on the target DOM node to form runtime association information, specifically includes: Read the node attributes and node hierarchy of the target DOM node, and generate node positioning information based on the node attributes and node hierarchy. Based on the target DOM node, obtain the effective style rules and corresponding style resource identifiers, and associate the style rules and style resource identifiers with the node positioning information to obtain style association information; Based on the target DOM node and its ancestor nodes, the event type, event handling identifier, and event propagation relationship are obtained. The event handling identifier is associated with the node location information to obtain the interaction association information. Based on the component identifier, style resource identifier, and event handling identifier corresponding to the target DOM node, query the build artifact mapping information to obtain the build resource identifier and source file location information; Node location information, style association information, interaction association information, construction resource identifiers, and source file location information are associated and stored to form runtime association information.

[0053] In this embodiment, the system first reads the node attributes and node hierarchy of the target DOM node, and generates node positioning information based on these attributes and hierarchy. The node attributes may include node tag type, node identifier, class name, data attributes, accessibility attributes, text summary, and other attribute information that can assist in identifying the node. The node hierarchy may include the relative relationships between the target DOM node and its parent, child, and sibling nodes, as well as the path information of the target DOM node in the current page's DOM tree. The node positioning information generated through node attributes and node hierarchy can be used to uniquely or nearly uniquely describe the target DOM node in the page's runtime state, avoiding the problem of unstable positioning caused by relying solely on a single selector.

[0054] Subsequently, the system obtains the effective style rules and corresponding style resource identifiers based on the target DOM node, and associates the style rules and style resource identifiers with the node location information to obtain style association information. Here, the effective style rules refer to the style rules that affect the target DOM node during the actual page rendering process. These can come from component-local styles, global styles, inherited styles, inline styles, or third-party style libraries. Style resource identifiers are used to characterize the source of the style rule in runtime resources, such as style file identifiers, built style module identifiers, style block identifiers, or the resource location of the style rule. By associating the effective style rules with the node location information, the system can clearly identify which style rules jointly determine the display effect of the target DOM node, providing a basis for subsequent location of the style source code entity.

[0055] Next, the system obtains the event type, event handling identifier, and event propagation relationship based on the target DOM node and its ancestor nodes, and associates the event handling identifier with the node location information to obtain interaction association information. Since in modern web pages, interactive events are not necessarily directly bound to the target DOM node itself, but may also be bound to its parent node or a higher-level ancestor node through event delegation, this embodiment not only collects the event information of the target DOM node itself, but also collects the relevant event information on its ancestor nodes. The event type can include click, input, focus change, form submission, mouse hover, etc.; the event handling identifier can be the identifier of the event handling function, the identifier of the processor allocated by the framework runtime, the listener identifier, or other processing identifiers that can be associated with the build artifacts; the event propagation relationship is used to characterize the processing path that may be triggered during the propagation of the event from the target DOM node to the ancestor node. In this way, even if the page adopts an event delegation or component framework encapsulation mechanism, the runtime relationship between the target DOM node and the interaction logic can be preserved relatively completely.

[0056] Then, based on the component identifier, style resource identifier, and event handling identifier corresponding to the target DOM node, the system queries the build artifact mapping information to obtain the build resource identifier and source file location information. The component identifier can be an identifier provided by the runtime framework for a component instance, component node, or template fragment, or it can be an identifier determined through DOM attributes, debugging information, or information exposed by the framework's development mode. The build artifact mapping information records the correspondence between the built script resources, style resources, template resources, and source code files, such as the build resource name, module identifier, source file path, row and column positions in the source file, or code fragment range. By querying the build artifact mapping information, the system can establish a connection between the runtime identifiers collected in the browser and the original source code locations in the project.

[0057] It should be noted that in some projects, build artifact mapping information may originate from mapping files generated by the build tool, module mapping tables maintained by the development server, debug mapping information exposed during framework runtime, or correspondence information between component identifiers and source file locations injected additionally during the project compilation phase. This embodiment does not limit the specific source of build artifact mapping information, as long as it can support reverse lookup of source file location information from runtime resources or runtime identifiers.

[0058] Finally, the system associates and stores node location information, style association information, interaction association information, build resource identifiers, and source file location information to form runtime association information. This association storage can be based on the target DOM node as the primary index, or it can be centered on the node location information, saving style, interaction, and build mapping results as association fields or records. The runtime association information should at least characterize the target DOM node's position in the page structure, the source of the style affecting its display effect, its related interaction processing path, and the corresponding build resources and source file locations.

[0059] Through the above embodiments, this application not only obtains the basic DOM positioning information of the target DOM node, but also further collects its style source, interaction relationship, and construction mapping relationship, enabling runtime elements in the browser page to have a contextual basis traceable to the source code. Compared with the method of only recording DOM paths or page coordinates, the runtime association information formed by this embodiment is more complete and can adapt to complex front-end engineering scenarios such as componentization, style cascading, event delegation, and build packaging, thereby providing a reliable basis for subsequently determining the associated source code entities.

[0060] In some embodiments, step S103 above, determining the associated source code entity based on runtime association information, specifically includes: Based on the build resource identifier and source file location information in the runtime association information, the corresponding source code file is queried in the source code index; Based on node location information, the component definition, template definition and rendering logic of the target DOM node are matched in the source code file to determine the source code entity associated with rendering. Based on style association information, the style definition corresponding to the effective style rule is matched in the source code file to determine the source code entity associated with the style; Based on the interaction association information, match the event handling function or call entry point corresponding to the event handling identifier to determine the source code entity of the interaction association.

[0061] In this embodiment, the system pre-establishes or maintains a source code index. The source code index may include the file paths, component names, template fragments, style definitions, function definitions, import / export relationships, and the location information of source files after build mapping for each source code file in the project. The source code index can be generated and updated when the project starts, builds, or when files are changed to ensure consistency with the current project code state.

[0062] When identifying associated source code entities, the system first queries the source code index for the corresponding source code file based on the build resource identifier and source file location information in the runtime association information. The build resource identifier can correspond to script resources, style resources, or module resources loaded during browser runtime; the source file location information can point to the source code file path before construction and its approximate location within the file. Through this query process, the system limits the runtime resources related to the target DOM node to one or more candidate source code files, thereby narrowing the subsequent matching scope and avoiding blind searching throughout the entire project.

[0063] Subsequently, based on node location information, the system matches the component definitions, template definitions, and rendering logic that generate the target DOM node in the candidate source code files to determine the source code entity associated with rendering. The node location information may include the target DOM node's tag type, class name, node identifier, data attributes, text summary, parent-child hierarchy, and sibling node relationships. The system can use this information to compare with the component structure, template tags, conditional rendering fragments, loop rendering fragments, or data binding expressions in the source code files to identify the source code location that generated the target DOM node. If the target DOM node is directly rendered by a component, then the component definition or its template fragment can be identified as the source code entity associated with rendering; if the target DOM node is generated by conditional logic, list rendering, or dynamic components, then the corresponding rendering logic, data mapping logic, or template definition can also be identified as the source code entity associated with rendering.

[0064] Next, based on style association information, the system matches the style definitions corresponding to the effective style rules in the source code file to determine the source code entity associated with the style. The style association information may include the actual effective style rule of the target DOM node, the style selector, the style source, the style resource identifier, and the cascading relationship. The system locates the style area within the candidate style file or component based on the style resource identifier, and determines the corresponding style definition in the source code based on the selector, attribute content, scope, and matching relationship of the effective style rule with the target DOM node. In cases where multiple style rules jointly affect the display effect of the target DOM node, the system can record each style definition separately and mark the association strength based on factors such as whether it directly hits the target DOM node, whether it is overridden by other styles, and whether it comes from inheritance. Thus, the system can not only find the style code that directly affects the target DOM node, but also identify the global styles or parent styles that affect the final display effect of the node.

[0065] Then, based on the interaction association information, the system matches the event handling function or call entry point corresponding to the event handling identifier to determine the source code entity associated with the interaction. The interaction association information may include the event type, event handling identifier, and event propagation relationship. Since page interactions may be directly bound to the target DOM node or bound to its ancestor node using event delegation, the system not only searches for the event handling function corresponding to the target DOM node itself during matching, but also searches for the call entry point in the parent component, ancestor node, or common event dispatch module based on the event propagation relationship. If the event handling identifier can be directly mapped to a function definition, then that function definition can be used as the source code entity associated with the interaction; if the event handling identifier corresponds to a callback entry point or intermediate call chain encapsulated by the framework, the system can further search along the call relationship for the function, method, or processing module that actually executes the business logic, and use it as the source code entity associated with the interaction.

[0066] In this embodiment, the source code entity can be a component definition, template fragment, rendering function, style rule, event handling function, method entry point, or other code unit that can be located and modified. After determining the source code entities associated with rendering, style, and interaction, the system can record the file path, code location, entity type, association type, and degree of association with the target DOM node for each source code entity. If the same target DOM node corresponds to multiple source code entities, the system can save them separately according to the association type or sort them according to the degree of association, so as to select the actual source code entity to be modified according to the user's modification request later.

[0067] Through the above implementation methods, the system can trace the target DOM node back to the rendering code responsible for page structure generation, the style code responsible for visual presentation, and the interaction code responsible for user behavior response based on runtime association information. Compared with finding the source code solely through DOM selectors or text keywords, this embodiment combines construction mapping, node positioning, style application results, and event handling relationships for multi-dimensional matching, which can more accurately determine the source code entities related to the target DOM node. It is suitable for complex front-end project scenarios such as component-based development, style cascading, dynamic rendering, and event delegation.

[0068] In some embodiments, step S103 above, establishing the source relationship between the target DOM node and the associated source code entity, specifically includes: Generate association records between the target DOM node and each source code entity. The association records include the target DOM node identifier, source code entity identifier, source code file location, code snippet location, association type, and association confidence. The association type is used to characterize the rendering association, style association, or interaction association between the target DOM node and each source code entity.

[0069] A source graph is constructed using the target DOM node as the starting node, each source code entity as the associated node, and associated records as connecting edges to establish the source relationship from the target DOM node to each source code entity.

[0070] In this embodiment, the system generates association records for the target DOM node and its identified source code entities. These association records describe the correspondence between the target DOM node and a single source code entity. Each association record may include the target DOM node identifier, source code entity identifier, source code file location, code snippet location, association type, and association confidence level.

[0071] The target DOM node identifier uniquely or relatively uniquely identifies the target DOM node in the browser page and can be determined by node location information, node path, node attributes, or runtime-generated node identifiers. The source code entity identifier identifies the source code unit associated with the target DOM node, such as a component definition, template fragment, rendering function, style rule, or event handler function. The source code file location indicates the source code file where the source code entity resides, such as a file path or module path. The code snippet location further indicates the specific location of the source code entity within the source code file, such as the start and end line positions, start and end column positions, or code block range. By simultaneously recording the source code file location and the code snippet location, subsequent tools can directly locate the code snippet to be viewed or modified.

[0072] Association types characterize the relationship between a target DOM node and a source code entity. Specifically, when a source code entity is used to generate the tag structure, component structure, template fragment, or rendering logic of the target DOM node, the association type can be rendering association; when a source code entity is used to define style rules, selectors, or style variables that act on the target DOM node, the association type can be style association; and when a source code entity is used to respond to interactive events on the target DOM node or its event propagation path, the association type can be interaction association. By setting association types, the system can distinguish how different code entities affect the target DOM node, avoiding the mixing of structural code, style code, and interactive code.

[0073] Association confidence is used to characterize the reliability of the matching results between the target DOM node and the source code entity. Association confidence can be determined based on the matching source and matching strength. For example, source code entities directly located by constructing mapping information typically have high confidence; source code entities indirectly matched through node attributes, text content, or selectors may have relatively low confidence; for style association, confidence can be adjusted based on factors such as whether the style rule actually takes effect, whether it directly hits the target DOM node, and whether it is overridden by other rules; for interaction association, confidence can be adjusted based on factors such as whether the event handling identifier directly corresponds to a function definition, whether event delegation exists, and whether it involves multiple levels of call entry points. Setting association confidence is beneficial for sorting and filtering results when multiple candidate source code entities exist.

[0074] After generating the aforementioned association records, the system constructs a source graph using the target DOM node as the starting node, each source code entity as an association node, and the association records as connecting edges. Specifically, the target DOM node in the source graph acts as a running node, representing the page element selected and confirmed by the user in the browser page; each source code entity acts as a source code node, representing the source code unit related to that page element; and the connecting edges represent the rendering, styling, or interaction relationships between the target DOM node and the source code entity, carrying information such as the association type, source code location, code snippet location, and association confidence from the association records.

[0075] In one alternative implementation, the same target DOM node can be connected to multiple source code entities simultaneously. For example, a target DOM node can be connected to a component template fragment via a rendering-related edge, to a component style definition via a style-related edge, and to a click event handler function via an interaction-related edge. When multiple style rules or event handler functions act on the target DOM node, multiple connection edges can be retained in the source graph and grouped or sorted according to the association type and association confidence. This allows the user or subsequent processing modules to clearly understand which code generated the target DOM node, which styles influenced it, and which interaction logic processed it.

[0076] In another alternative implementation, the source graph can be further extended. For example, connections can be established between source code entities based on call relationships, component inclusion relationships, style import relationships, or module dependencies to form a multi-level source path from the target DOM node to source code files, functions, style rules, and component dependencies. However, in the basic implementation of this embodiment, at least a source relationship is included, with the target DOM node as the starting node, each source code entity as an associated node, and associated records as connecting edges.

[0077] Through the above embodiments, the system organizes the scattered matching results into a structured source graph, rather than simply returning a few file paths or code locations. This source graph can intuitively express the correspondence and association types between target DOM nodes and various source code entities, and reflects the reliability of the results through association confidence, thereby facilitating subsequent code location, determination of modification scope, automated rewriting, or manual confirmation. Compared with simple text retrieval or single mapping methods, the source relationship established in this embodiment is clearer and more stable, and can adapt to front-end engineering scenarios where a page element is simultaneously affected by rendering code, style code, and interaction code.

[0078] In some embodiments, step S104 above, determining the source code entity to be modified based on the user-inputted modification request, combined with the tracing relationship and the calling relationship of the associated source code entities, specifically includes: Parse the user's edit request to obtain the object to be modified and the scope of modification; The target association type is determined based on the object being modified, and the target association type includes at least one of rendering association, style association, and interaction association. Starting with the target DOM node, retrieve the associated source code entities corresponding to the target's associated type based on the source tracing relationship, forming candidate source code entities; Obtain the calling entity, called entity, and component information of each candidate source code entity, and establish the calling relationship between the candidate source code entities; Determine the scope of impact that matches the modification request within the call relationship based on the scope of the modification. The source code entities to be modified are determined based on the degree of matching between each candidate source code entity and the object to be modified, the strength of the association with the target DOM node, and the scope of influence.

[0079] In this embodiment, the system first parses the user's input modification request to obtain the modification object and the scope of modification. The modification request can be a natural language description, a structured instruction, or a modification task generated by the interactive interface. The modification object represents the content that the user wants to change, such as modifying button text, adjusting colors, adding click behavior, hiding an element, or modifying component display conditions. The modification scope represents the boundary of the user's expected modification impact, such as modifying only the current target DOM node, modifying the same element within the current component, modifying similar elements on the same page, or modifying all instances of a globally reusable component. By identifying the modification object and the modification scope, it can be preliminarily determined whether the modification should be applied primarily to structural code, style code, or interactive code.

[0080] Subsequently, the system determines the corresponding target association type based on the object being modified. The target association type includes at least one of rendering association, style association, and interaction association. For example, when the object being modified involves element text, node addition / deletion, component structure, conditional display, or list content, the target association type can be determined to include rendering association; when the object being modified involves color, font size, spacing, border, layout, or show / hide effects, the target association type can be determined to include style association; when the object being modified involves actions such as clicking, inputting, submitting, redirecting, validating, or requesting data, the target association type can be determined to include interaction association. For modification requests involving multiple aspects simultaneously, such as "change the button to red and click to open a pop-up window," the system can simultaneously determine style association and interaction association as target association types.

[0081] After determining the target association type, the system uses the target DOM node as the starting node and, based on the aforementioned source tracing relationship, obtains the associated source code entities corresponding to the target association type, forming candidate source code entities. Specifically, the system can search the source code node connected to the target DOM node in the source tracing graph and whose association type matches the target association type, and read its file location, code snippet location, entity type, and association confidence. In cases where multiple associated source code entities exist under the same target association type, the system can include all of them in the candidate range for further filtering based on subsequent call relationships and modification scope.

[0082] Next, the system obtains the caller entity, called entity, and component information for each candidate source code entity, establishing the call relationship between the candidate source code entities. The caller entity can be an upstream code unit that calls a candidate function, references a candidate component, imports a candidate style, or uses a candidate template fragment; the called entity can be a function, sub-component, style variable, public utility method, or state management module called internally by the candidate source code entity; the component information is used to characterize the component, page, module, or public library where the candidate source code entity resides. The call relationship can be obtained through source code indexing, abstract syntax analysis results, module dependency information, component tree information, style import relationships, or framework routing relationships. By establishing the call relationship, the system can determine whether modifying a candidate source code entity might affect the current node, the current component, instances of similar components, or reusable logic throughout the entire project.

[0083] The system then determines the scope of impact matching the modification request within the call relationship based on the scope of the modification. If the scope of the modification only affects the current target DOM node, the system prioritizes source code entities located in the current component instance, current template fragment, or local styles, avoiding common functions or global styles shared by multiple components. If the scope of the modification affects similar elements within the current component, the system can select reused rendering fragments, component style definitions, or component methods within that component. If the scope of the modification affects all reused instances, the system can select common components, common styles, or common interaction handling functions referenced by multiple callers. By mapping the user-specified or inferred scope of modification to the boundaries of impact in the call relationship, the risk of unexpected page changes due to modifications to shared code can be reduced.

[0084] Finally, the system determines the source code entity to be modified based on the matching degree between each candidate source code entity and the object to be modified, the strength of its association with the target DOM node, and the scope of its influence. The matching degree can be determined based on the correspondence between the entity type of the candidate source code entity and the object to be modified. For example, style definitions have a high matching degree with color modifications, event handling functions have a high matching degree with click behavior modifications, and template fragments have a high matching degree with text or node structure modifications. The association strength can be derived from the association confidence in the source code relationship, or it can be determined by combining factors such as whether the candidate source code entity directly affects the target DOM node, whether it undergoes intermediate calls, or whether it belongs to event delegation or style inheritance. The scope of influence is used to determine whether modifying the candidate source code entity conforms to the code scope that the user wants to affect. After considering the above factors, the system determines one or more candidate source code entities that best match the modification request as the source code entity to be modified.

[0085] In one alternative implementation, when multiple candidate source code entities meet the conditions, the system can sort them according to their matching degree, correlation strength, and scope of influence, and provide the sorting results to the subsequent automatic modification module or user confirmation module. For candidate source code entities that pose a risk, such as global styles, common components, or processing functions reused across multiple pages, the system can mark their potential scope of influence for confirmation before implementing modifications.

[0086] Through the above embodiments, this application does not simply map the target DOM node to a certain source file and then modify it directly. Instead, it combines the user's modification intent, the tracing relationship, and the calling relationship between source code entities to determine the source code entity that is truly suitable for modification. This approach can more accurately control the modification location and the scope of the modification in complex scenarios such as component reuse, common styles, event delegation, and multi-level function calls, thereby improving the accuracy and security of code modification.

[0087] In some embodiments, step S105 above, which involves sending the modification request, the source code entity to be modified, and the code context to the code generation agent to generate a code patch, specifically includes: Obtain the target code fragment corresponding to the source code entity to be modified, and extract the parent code structure, referenced code definitions and associated calling code of the target code fragment to form a code context; Parse the modification request to obtain the modification content and modification constraints; The target code snippet, code context, modifications, and modification constraints are encapsulated into a code generation task and sent to the code generation agent; Receive candidate modified code returned by the code generation agent, and generate code patches based on the differences between the candidate modified code and the target code snippet.

[0088] In this embodiment, the system first obtains the target code fragment corresponding to the source code entity to be modified. The target code fragment can be a component template fragment, rendering logic, style definition, event handling function, method body, or other code unit to be modified. Based on the source code file location and code fragment location of the source code entity to be modified, the system extracts the target code fragment from the source code file to ensure that the subsequent generation process revolves around a clearly defined modification object.

[0089] To avoid semantic incompleteness caused by the code generation agent modifying isolated code snippets, the system also extracts the target code snippet's parent code structure, referencing code definitions, and associated calling code to form a code context. The parent code structure can include the component, class, function, style scope, or module structure to which the target code snippet belongs, indicating the code environment in which the target code snippet exists. The referencing code definitions can include the definition location and meaning of variables, properties, methods, components, style variables, imported modules, or state fields used in the target code snippet. The associated calling code can include code that calls the target function, code that references the target component, code that triggers the target event, or related code further called by the target code snippet. By providing this code context, the code generation agent can determine how the modified content should be embedded into the existing project structure and maintain consistency in naming, data sources, calling methods, and style scopes as much as possible.

[0090] Subsequently, the system parses the user's modification request to obtain the modification content and modification constraints. The modification content represents the specific changes the user wishes to achieve, such as modifying text, adjusting colors, changing layout, adding validation, supplementing click logic, or adding conditional displays. The modification constraints restrict the way and boundaries of code generation, such as not modifying common components, not changing existing interfaces, only modifying the current file, maintaining the existing style naming conventions, not introducing new third-party dependencies, or maintaining the original interaction flow. Restrictions determined from the aforementioned scope of impact can also be provided to the code generation agent as modification constraints.

[0091] Next, the system encapsulates the target code snippet, code context, modification content, and modification constraints into a code generation task and sends it to the code generation agent. The code generation task may include information about the file to be modified, the location of the target code snippet, the original code content, relevant contextual descriptions, the user's modification intent, modification boundaries, and the expected output format. The code generation agent can be a local code generation module, a remote intelligent generation service, or an automated modification module integrated into the development environment. By providing the code generation agent with explicit target snippets and context, rather than just providing natural language modification requests, the system enables the code generation agent to generate candidate modified code that better fits the project structure and scope of modification.

[0092] After receiving candidate modified code from the code generation agent, the system generates a code patch based on the differences between the candidate modified code and the target code segment. The candidate modified code can be a complete replacement of the target code segment, or a modified segment containing partial additions, deletions, and modifications. The system compares the candidate modified code with the original target code segment to determine the added, deleted, and changed content, and generates a code patch that can be applied to the source code file. The code patch can record the file to be modified, the location to be modified, the original code content, the modified code content, and the difference information, for subsequent patch application, preview, rollback, or manual confirmation.

[0093] In one optional implementation, if the code generation agent returns multiple candidate modified code, the system can filter or sort the multiple candidate results based on factors such as modification constraints, code context consistency, whether it exceeds the scope of the target code segment, and whether it changes interfaces that should not be changed, and select the candidate modified code that meets the conditions to generate a code patch. If the candidate modified code involves content outside the target code segment, the system can determine whether the modification is necessary by combining the aforementioned code context and modification constraints; if it exceeds the allowed scope, the system can reject the candidate result or require the code generation agent to regenerate.

[0094] Through the above embodiments, this application, when generating code patches, does not directly hand over user natural language requests to a code generation agent for free modification. Instead, it first identifies specific source code entities to be modified, extracts their related code context and modification constraints, and then generates a structured code generation task. This improves the matching degree between candidate modified code and the project's existing code, reduces the risk of accidentally modifying irrelevant code, omitting dependencies, or breaking call relationships, and makes the final code patch auditable, applicable, and rollbackable.

[0095] In some embodiments, step S106 above, which involves applying the code patch to the isolated preview environment, re-rendering the target display area, and obtaining the patch verification result, specifically includes: Create an isolated preview environment and load the project code and runtime dependencies corresponding to the source code entity to be modified into the isolated preview environment; Apply the code patch to the project code in the isolated preview environment, and perform a project build and page launch to obtain the build status and page launch status; When both the build status and the page launch status indicate successful execution, the target page is reloaded according to the page status corresponding to the target DOM node in order to re-render the target display area; Get the updated DOM node corresponding to the target DOM node after re-rendering, extract the display content, style attributes and interactive response results of the updated DOM node, and compare them with the expected modified content corresponding to the modification request to obtain the content comparison results; Patch verification results are generated based on the build status, page startup status, and content comparison results.

[0096] In this embodiment, the system first creates an isolated preview environment and loads the project code and runtime dependencies corresponding to the source code entity to be modified into this environment. The isolated preview environment can be an independent temporary working directory, a container environment, a sandbox runtime environment, or other execution environment isolated from the original project workspace. The loaded project code can include the complete code of the project containing the source code entity to be modified or the minimum code set required to build the target page; runtime dependencies can include project dependency packages, build tools, environment variables, static resources, configuration files, and local service configurations required for page execution. Performing subsequent operations through the isolated preview environment avoids directly applying code patches to the original project, reducing the risk of verification failures impacting the current development state.

[0097] Subsequently, the system applies the code patch to the project code in the isolated preview environment and executes the project build and page launch, obtaining the build status and page launch status. The build status indicates whether the project code after patch application can pass the build process, such as compilation, packaging, or type checking; the page launch status indicates whether the built page or development service can start normally and provide external access. If syntax errors, missing dependencies, type mismatches, or resource reference errors occur during the build process, the build status can indicate failure; if the page service fails to start, the route is inaccessible, or runtime initialization is abnormal, the page launch status can indicate failure. By recording the build status and page launch status separately, static build problems and runtime startup problems caused by code patches can be distinguished.

[0098] When both the build status and page startup status indicate successful execution, the system reloads the target page according to the page state corresponding to the target DOM node to re-render the target display area. The page state may include the target page's access address, routing parameters, query parameters, login status, user operation path, page scroll position, filter conditions, form input values, simulated interface data, or other state information affecting the presentation of the target DOM node. By reloading the target page according to this page state, the display scenario of the target DOM node when the user made the modification request can be reproduced as closely as possible, ensuring that the patch verification results are consistent with the actual modification target. The target display area can be the target DOM node itself, or a partial page area or component display area containing the target DOM node.

[0099] After the page is re-rendered, the system retrieves the updated DOM node corresponding to the original target DOM node. Since code patches may cause changes to the DOM structure, attributes, or node positions, the system can relocate the corresponding node in the updated page based on the original target DOM node's node identifier, node path, stable attributes, text characteristics, component instance information, or the aforementioned source-tracing relationships. After obtaining the updated DOM node, the system extracts its display content, style attributes, and interaction response results. Display content may include text, image addresses, visibility, node structure, or form values; style attributes may include actual effective styles such as color, font size, size, margins, borders, layout, and display status; interaction response results may include page changes after clicks, inputs, hovers, submissions, event triggering results, prompts, redirects, or API call results.

[0100] The system compares the displayed content, style attributes, and interactive response results with the expected modifications corresponding to the modification request to obtain a content comparison result. For example, when the modification request is to modify the text, the system compares whether the actual text of the updated DOM node matches the expectation; when the modification request is to adjust the color or layout, the system compares whether the actual applied style matches the expectation; when the modification request is to add a pop-up or redirect behavior, the system triggers the corresponding interaction and compares whether the response result matches the expectation. If the modification request involves content, style, and interaction simultaneously, the system can generate multiple sub-item comparison results and summarize them into a content comparison result.

[0101] Finally, the system generates a patch verification result based on the build status, page launch status, and content comparison results. The patch verification result can include whether the patch passed verification, build status information, page launch status information, the actual result after re-rendering the target display area, the comparison conclusion with the expected modified content, and the reason for failure. If the build status or page launch status fails, the patch verification result can directly indicate that the verification failed and record the corresponding error information; if both the build and page launch are successful, but the content comparison result does not meet expectations, the patch verification result can indicate that the page effect does not meet the modification request; if the build, launch, and content comparison all meet the requirements, the patch verification result can indicate that the code patch verification passed.

[0102] Through the above embodiments, this application introduces an isolated preview environment to build, run, and verify the page effect of the patch before its formal application. This method can not only discover syntax, dependency, or runtime errors, but also compare the content, style, and interaction of the re-rendered target display area based on the actual page state corresponding to the target DOM node, thereby improving the reliability of automatic code modification results and reducing the risk of erroneous patches entering the real project code.

[0103] In some embodiments, step S107 above, where the code patch is submitted to the code editor and the source code entity to be modified is located when the patch verification result meets the preset consistency condition, and the code patch is adjusted or rolled back according to the patch verification result, specifically includes: Based on the build status, page startup status, and content comparison results, determine whether the code patch meets the preset consistency conditions; When the code patch meets the preset consistency conditions, the code patch is written to the source code file corresponding to the source code entity to be modified, and the source code entity to be modified is located in the code editor based on the file path and code location of the source code entity to be modified. When a code patch does not meet the preset consistency conditions, extract the basis for patch adjustment from the patch verification results, and adjust the code patch based on the patch adjustment basis. If the adjusted code patch still does not meet the preset consistency conditions, and the number of adjustments reaches the preset number, the applied code patch is revoked, and the original source code corresponding to the source code entity to be modified is restored.

[0104] In this embodiment, the system first determines whether the code patch meets preset consistency conditions based on the build status, page launch status, and content comparison results in the patch verification results. The preset consistency conditions may include: a successful project build status, a successful page launch status, and the target display area after re-rendering being consistent with or meeting preset matching requirements for the expected modification content corresponding to the modification request. The content comparison results may include at least one of the following: display content comparison results, style attribute comparison results, and interaction response comparison results. For example, if the modification request is "change the button text to submit," the actual displayed text of the updated DOM node should be consistent with "submit"; if the modification request is "pop up a prompt box after clicking," a corresponding prompt box should be generated after triggering the click operation. Only when the build, operation, and page effect all meet the requirements are the code patch considered to meet the preset consistency conditions.

[0105] When a code patch meets preset consistency conditions, the system writes the patch to the source code file corresponding to the entity being modified. Specifically, the system applies the patch to the source code file of the user's current project based on the file path, original code location, original code content, and modified code content recorded in the patch. To avoid accidentally writing to the wrong location, the system can double-check before writing whether the original code content at the corresponding location in the source code file is consistent with the target code segment when the patch was generated; if they are consistent, the writing is performed; if they are inconsistent, the system can prompt that the source file has changed or regenerate the patch.

[0106] After the code patch is written, the system locates the source code entity to be modified in the code editor based on its file path and code location. This location can include opening the corresponding source code file, jumping to the row and column where the source code entity is located, selecting or highlighting the modified code snippet, or displaying the patch changes in the editor's sidebar. In this way, users can intuitively see the automatically modified code location and results, facilitating further review, confirmation, or continued editing.

[0107] When a code patch fails to meet preset consistency conditions, the system extracts patch adjustment criteria from the patch verification results. These criteria may include build error information, page launch anomaly information, content comparison discrepancies, style inconsistencies, interaction response failures, and information regarding the incorrect positioning of target DOM nodes. For example, if a build failure is due to an undefined variable, this error information can serve as a patch adjustment criterion; if the page launches but the button color does not meet expectations, the difference between the actual and expected color values ​​can serve as a patch adjustment criterion; if an interactive operation does not produce the expected response, information regarding failed event triggering or inconsistent response results can serve as a patch adjustment criterion.

[0108] The system adjusts the code patch based on the aforementioned patch adjustment criteria. Adjustment methods may include: resending the patch adjustment criteria, the original modification request, the original target code snippet, and related code context to the code generation agent to generate corrected candidate modification code; or the system correcting local content in the patch according to preset rules. The adjusted code patch can be reapplied to the isolated preview environment, and a build, page launch, and content comparison can be re-executed to obtain new patch verification results. Through this closed-loop adjustment process, when a patch fails to meet expectations, verification feedback can be used to gradually correct the patch, rather than directly submitting the erroneous patch to the user project.

[0109] In one implementation, the system also records the number of times the code patch has been adjusted. When the adjusted code patch still does not meet the preset consistency conditions, the system determines whether the number of adjustments has reached the preset number. If the number of adjustments has not reached the preset number, the system can continue to extract the basis for patch adjustments based on the latest patch verification results and adjust the code patch again. If the number of adjustments reaches the preset number, it indicates that the automatic correction process has failed to obtain a reliable patch within the allowed range. At this time, the system revoks the code patch that has been applied to the isolated preview environment or temporary workspace and restores the original source code corresponding to the source code entity to be modified. For cases where the patch has not yet been written to the user's actual source code file, the rollback can be to discard the temporary patch and restore the original code in the isolated environment; for cases where the patch has been written but subsequent verification failed, the rollback can restore the corresponding source code file to its pre-modification state based on the original code content in the patch record.

[0110] It should be noted that the preset number of adjustments can be determined based on the project type, the complexity of the modification, or user configuration. For example, for simple text or style modifications, fewer adjustments can be set; for modifications involving multiple interactive logics or multiple linked files, a relatively larger number of adjustments can be set. By setting an upper limit on the number of adjustments, the system can avoid repeatedly generating and verifying without obtaining effective patches, thus preventing resource waste or impacting the user experience.

[0111] Through the above embodiments, this application introduces a consistency condition check before patch submission, and adjusts the patch based on the verification results when the conditions are not met, and performs a rollback if multiple adjustments still fail. This approach ensures that automatically generated code patches undergo verification at the build, run, and page effect levels before entering the real code editing environment, reducing the risk of erroneous patches being submitted. Simultaneously, by automatically locating the source code entity to be modified after successful submission, it improves the efficiency and controllability of user review of the modification results.

[0112] Combination Figure 3 As shown, this process takes "patch verification result" as input and first enters "consistency condition judgment". This judgment node is used to determine whether the patch meets the preset consistency conditions based on the build status, page startup status and content comparison results.

[0113] When the judgment result is "satisfied", the process enters "submit to code editor", which means writing the code patch to the source code file corresponding to the source code entity to be modified; then it enters "locate source code entity to be modified", which means opening and locating the corresponding code location in the code editor according to the file path and code location, so that the user can view the modification result.

[0114] When the judgment result is "not satisfied," the process proceeds to "extract patch adjustment basis," extracting information such as build errors, startup exceptions, content differences, style differences, or interaction response differences from the patch verification results. Then, it proceeds to "adjust patch," correcting the code patch according to the stated adjustment basis. After correction, the process proceeds to "re-verify consistency conditions," where the adjusted patch is re-verified and judged.

[0115] If the result of the second evaluation is "satisfied," the process proceeds to the submission and location steps, allowing the adjusted patch to be submitted to the code editor and the source code entity to be modified to be located. If the result of the second evaluation is still "unsatisfied," the process proceeds to determine whether the "adjustment count has reached the preset number." If the preset number has not been reached, the process returns to the "adjust patch" step to continue correction; if the preset number has been reached, the process proceeds to "rollback," reversing the applied code patch and restoring the original source code corresponding to the source code entity to be modified. Thus, Figure 3 It demonstrates the closed-loop control process of patch submission, automatic adjustment, and failure rollback.

[0116] Reference Figure 4 An embodiment of the present invention provides a code modification system 4 based on webpage selection and runtime source tracing, the system specifically comprising: The node acquisition module 401 is used to acquire the corresponding target DOM node in response to the user selecting a target display area on the browser page. The information association module 402 is used to extract node location, style, interaction and build mapping relationship based on the target DOM node to form runtime association information; The relationship tracing module 403 is used to determine the associated source code entities based on runtime association information and establish the tracing relationship between the target DOM node and the associated source code entities; Modify Request Module 404 is used to determine the source code entity to be modified based on the user's input modification request, combined with the tracing relationship and the calling relationship of the associated source code entity; The patch generation module 405 is used to send the modification request, the source code entity to be modified, and the code context to the code generation agent to generate a code patch. Patch verification module 406 is used to apply code patches to the isolated preview environment, re-render the target display area, and obtain patch verification results. The patch adjustment module 407 is used to submit the code patch to the code editor and locate the source code entity to be modified when the patch verification result meets the preset consistency conditions; otherwise, it adjusts the code patch or rolls it back according to the patch verification result.

[0117] It is understandable that, such as Figure 1 The content shown in the code modification method embodiment based on webpage selection and runtime source tracing is applicable to the code modification system embodiment based on webpage selection and runtime source tracing. The specific functions implemented in the code modification system embodiment based on webpage selection and runtime source tracing are the same as those shown in the example. Figure 1 The code modification method based on webpage selection and runtime source tracing shown is the same as the embodiment, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the code modification method based on webpage selection and runtime tracing shown in the embodiment are also the same.

[0118] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0119] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0120] Reference Figure 5 The present invention also provides a computer device 5, including: a memory 502 and a processor 501, and a computer program 503 stored in the memory 502. When the computer program 503 is executed on the processor 501, it implements the code modification method based on web page selection and runtime tracing as described in any of the above methods.

[0121] The computer device 5 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 5 may include, but is not limited to, a processor 501 and a memory 502. Those skilled in the art will understand that... Figure 5 The computer device 5 is merely an example and does not constitute a limitation on the computer device 5. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0122] The processor 501 can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0123] In some embodiments, the memory 502 may be an internal storage unit of the computer device 5, such as a hard disk or memory of the computer device 5. In other embodiments, the memory 502 may be an external storage device of the computer device 5, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 5. Further, the memory 502 may include both internal and external storage units of the computer device 5. The memory 502 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 502 can also be used to temporarily store data that has been output or will be output.

[0124] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the code modification method based on webpage selection and runtime tracing as described in any of the above methods.

[0125] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0126] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0127] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

Claims

1. A code modification method based on webpage selection and runtime source tracing, characterized in that, The method specifically includes: In response to the user selecting a target display area on the browser page, obtain the corresponding target DOM node; Based on the target DOM node, extract the node's location, style, interaction, and construct mapping relationships to form runtime association information; Based on runtime association information, the associated source code entities are identified, and the source relationship between the target DOM node and the associated source code entities is established. Based on the user's modification request, and combined with the tracing relationship and the calling relationship of related source code entities, the source code entity to be modified is determined; Send the modification request, the source code entity to be modified, and the code context to the code generation agent to generate a code patch; Apply the code patch to the isolated preview environment, re-render the target display area, and obtain the patch verification results; When the patch verification result meets the preset consistency conditions, the code patch is submitted to the code editor and the source code entity to be modified is located; otherwise, the code patch is adjusted or rolled back according to the patch verification result.

2. The method according to claim 1, characterized in that, The response to the user selecting a target display area on the browser page and obtaining the corresponding target DOM node specifically includes: In response to mouse press events on the browser page, record the starting position of the selection box; In response to mouse movement events, a selection area is generated based on the starting position of the selection box and the current mouse position; In response to a mouse release event, retrieve candidate DOM nodes that are located within or intersect with the selected area. The node priority is determined based on the overlap ratio between each candidate DOM node and the selected area, the visible rendering area, the node level, and the interactive attributes. Candidate DOM nodes whose node priority meets the preset conditions are determined as the target DOM nodes corresponding to the target display area.

3. The method according to claim 1, characterized in that, The process of extracting node location, style, interaction, and constructing mapping relationships based on target DOM nodes to form runtime association information specifically includes: Read the node attributes and node hierarchy of the target DOM node, and generate node positioning information based on the node attributes and node hierarchy. Based on the target DOM node, obtain the effective style rules and corresponding style resource identifiers, and associate the style rules and style resource identifiers with the node positioning information to obtain style association information; Based on the target DOM node and its ancestor nodes, the event type, event handling identifier, and event propagation relationship are obtained. The event handling identifier is associated with the node location information to obtain the interaction association information. Based on the component identifier, style resource identifier, and event handling identifier corresponding to the target DOM node, query the build artifact mapping information to obtain the build resource identifier and source file location information; Node location information, style association information, interaction association information, construction resource identifiers, and source file location information are associated and stored to form runtime association information.

4. The method according to claim 3, characterized in that, The determination of associated source code entities based on runtime association information specifically includes: Based on the build resource identifier and source file location information in the runtime association information, the corresponding source code file is queried in the source code index; Based on node location information, the component definition, template definition and rendering logic of the target DOM node are matched in the source code file to determine the source code entity associated with rendering. Based on style association information, the style definition corresponding to the effective style rule is matched in the source code file to determine the source code entity associated with the style; Based on the interaction association information, match the event handling function or call entry point corresponding to the event handling identifier to determine the source code entity of the interaction association.

5. The method according to claim 4, characterized in that, The establishment of the source code relationship between the target DOM node and the associated source code entity specifically includes: Generate association records between the target DOM node and each source code entity. The association records include the target DOM node identifier, source code entity identifier, source code file location, code snippet location, association type, and association confidence. The association type is used to characterize the rendering association, style association, or interaction association between the target DOM node and each source code entity. A source graph is constructed using the target DOM node as the starting node, each source code entity as the associated node, and associated records as connecting edges to establish the source relationship from the target DOM node to each source code entity.

6. The method according to claim 1, characterized in that, The step of determining the source code entity to be modified based on the user's input modification request, combined with the tracing relationship and the calling relationship of the associated source code entities, specifically includes: Parse the user's edit request to obtain the object to be modified and the scope of modification; The target association type is determined based on the object being modified, and the target association type includes at least one of rendering association, style association, and interaction association. Starting with the target DOM node, retrieve the associated source code entities corresponding to the target's associated type based on the source tracing relationship, forming candidate source code entities; Obtain the calling entity, called entity, and component information of each candidate source code entity, and establish the calling relationship between the candidate source code entities; Determine the scope of impact that matches the modification request within the call relationship based on the scope of the modification. The source code entities to be modified are determined based on the degree of matching between each candidate source code entity and the object to be modified, the strength of the association with the target DOM node, and the scope of influence.

7. The method according to claim 1, characterized in that, The step of sending the modification request, the source code entity to be modified, and the code context to the code generation agent to generate a code patch specifically includes: Obtain the target code fragment corresponding to the source code entity to be modified, and extract the parent code structure, referenced code definitions and associated calling code of the target code fragment to form a code context; Parse the modification request to obtain the modification content and modification constraints; The target code snippet, code context, modifications, and modification constraints are encapsulated into a code generation task and sent to the code generation agent; Receive candidate modified code returned by the code generation agent, and generate code patches based on the differences between the candidate modified code and the target code snippet.

8. The method according to claim 1, characterized in that, The process of applying the code patch to the isolated preview environment, re-rendering the target display area, and obtaining the patch verification result specifically includes: Create an isolated preview environment and load the project code and runtime dependencies corresponding to the source code entity to be modified into the isolated preview environment; Apply the code patch to the project code in the isolated preview environment, and perform a project build and page launch to obtain the build status and page launch status; When both the build status and the page launch status indicate successful execution, the target page is reloaded according to the page status corresponding to the target DOM node in order to re-render the target display area; Get the updated DOM node corresponding to the target DOM node after re-rendering, extract the display content, style attributes and interactive response results of the updated DOM node, and compare them with the expected modified content corresponding to the modification request to obtain the content comparison results; Patch verification results are generated based on the build status, page startup status, and content comparison results.

9. The method according to claim 8, characterized in that, When the patch verification result meets the preset consistency conditions, the code patch is submitted to the code editor and the source code entity to be modified is located; otherwise, the code patch is adjusted or rolled back according to the patch verification result. Specifically, this includes: Based on the build status, page startup status, and content comparison results, determine whether the code patch meets the preset consistency conditions; When the code patch meets the preset consistency conditions, the code patch is written to the source code file corresponding to the source code entity to be modified, and the source code entity to be modified is located in the code editor based on the file path and code location of the source code entity to be modified. When a code patch does not meet the preset consistency conditions, extract the basis for patch adjustment from the patch verification results, and adjust the code patch based on the patch adjustment basis. If the adjusted code patch still does not meet the preset consistency conditions, and the number of adjustments reaches the preset number, the applied code patch is revoked, and the original source code corresponding to the source code entity to be modified is restored.

10. A code modification system based on webpage selection and runtime source tracing, characterized in that, The system specifically includes: The node acquisition module is used to retrieve the corresponding target DOM node in response to the user selecting a target display area on the browser page. The information association module is used to extract node location, style, interaction, and construct mapping relationships based on the target DOM node to form runtime association information; The relationship tracing module is used to determine the associated source code entities based on runtime association information and establish the tracing relationship between the target DOM node and the associated source code entities; The modification request module is used to determine the source code entity to be modified based on the user's modification request, combined with the tracing relationship and the calling relationship of the associated source code entity; The patch generation module is used to send modification requests, source code entities to be modified, and code context to the code generation agent to generate code patches. The patch verification module is used to apply code patches to the isolated preview environment, re-render the target display area, and obtain the patch verification results. The patch adjustment module is used to submit the code patch to the code editor and locate the source code entity to be modified when the patch verification result meets the preset consistency conditions; otherwise, the code patch is adjusted or rolled back according to the patch verification result.

Images