重构不是把代码重写一遍，而是先看清耦合，再动刀。
假设你有一个跑了半年的页面，每次加需求都要改五六个文件，改完还容易坏。这时候让 Agent 直接“重构一下”，大概率会越改越乱。
问题不在 Agent 不够聪明，而在顺序错了。先别急着拆文件，用 grilling 把现有架构的耦合点、边界假设和隐藏依赖逼出来，让 Agent 和你对“乱在哪”达成共识。
共识之后，用 webapp-testing 跑通关键路径，建立行为基线。没有这条基线，后面每一步拆分都无法判断有没有改坏。
接着才是拆分与约束：用组合模式理清组件职责，用性能规范守住数据流，用设计规范防止风格碎片，再让 monorepo 构建管线约束模块引用。每一步小改动都配合规范提交，让过程可回溯。
重构完不是结束。用部署指标确认没有性能倒退，再把这次的方法固化成可复用的 Skill，下次遇到同类问题就不用从头摸索。
在动手重构前，连续追问现有架构的耦合点、边界假设和隐藏依赖，把“越改越乱”的根因逼出来
用 Playwright 跑通现有页面关键路径，为重构建立可回归的行为基线
把纠缠在一起的大组件拆成可组合的小单元，明确父子职责与插槽边界
在拆分组件和调整数据流时对照性能规范，避免重构引入新的渲染与依赖问题
在模块边界确定后重新梳理界面层级与视觉一致性，防止拆分后出现风格碎片
把拆分出的模块纳入 monorepo 构建管线，用任务依赖和缓存约束模块间引用关系
每完成一步小重构就生成规范提交，让架构调整过程可回溯、可回滚
重构完成后对照部署指标检查包体积与运行成本，确认架构调整没有带来性能倒退
把本次识别耦合、拆模块、写测试的流程固化成可复用的重构 Skill，供后续项目沿用
在重构过程中按需检索并安装缺失的专项能力，补齐当前工作流没有覆盖的环节