1. 我是谁，遇到了什么问题
我是前端开发，日常工作用 Vue 写后台管理型页面、跟后端调接口。最近运营提了个小需求：给"用户列表"加一个新的筛选维度（按最近活跃时间排序）。本来是个小改，结果我发现"筛选条件 + 列表数据 + 分页 + loading 状态"这一整套逻辑，居然在三个页面各写了一份——
-
用户列表页：主列表，支持分页和多条件筛选。
-
搜索结果页：从全局搜索跳过来，筛选项比主列表少，且不分页。
-
订单详情页里的"关联用户"区块：只取列表的一部分，不分页，要固定带上外层项目 id。
这三份几乎是从同一个模板复制出来的，参数命名还不一致（有的叫 searchKeyword，有的叫 keyword）。改一个需求要三处各改一遍，还特别容易改漏、导致不同入口行为不一致。
更麻烦的是，我一度有点不敢动手：这三份细节差异不小，直接硬抽成 composable，怕用力过猛把原有分页和筛选行为改坏。
2. 我是怎么用 TraeCode 解决的
我主要用的 SOLO 模式，这一单我特别依赖 /plan 来"控场"，管住方向再动手：
-
第一步：先用
/plan把方案规划出来，确认后才让它执行。 我没有一上来就让它改代码，而是先让它去梳理这三个页面里这份重复逻辑有什么相同、有什么差异（结果发现：搜索结果页不分页、详情页关联区块要固定带上外层项目 id、搜索参数命名不统一）。基于此我让它先产出一份规划/计划：要不要抽、抽成什么 composable、参数怎么设计、分页筛选在每个入口上要不要保留、每处调用怎么替换、改动后怎么验证。我确认计划没问题之后，它才开始按计划执行。 -
第二步：按确认好的计划执行。 计划定稿后，它按
/plan里列好的步骤推进：把三份逻辑收敛成一个useUserListcomposable，返回统一的list / loading / params / fetchList，把差异做成配置项（比如paged: boolean、searchKeys: []），然后逐个替换三个页面。 -
第三步：替换 + 验收。 执行阶段里，它每替换一处就提醒我这处特殊点（搜索结果页去掉分页、详情页传入外层 id、loading 状态的替换位置），最后结合我本地接口，校验三处入口的筛选、排序、分页行为都没回退，还补了一条测试验证返回结构不变。
3. 成果展示
最终我在 /plan 定好方向、确认后才执行的前提下，把散落三份的请求逻辑收敛成一个 useUserList composable，三个页面统一调用、用参数区分差异，本地跑通、回归通过。
之后再改筛选相关需求，我只用改 composable 这一处，不用再追着三个页面补三遍；同事接手这个模块，看一个 composable 也比翻三份差不多的逻辑直观。
4. 效率对比
以前这种重复逻辑，我最怕改漏一处导致不同入口行为不一致，每次都要来回核对、逐个入口验证，大半天起步，还容易出现"改到一半发现方向不对"的返工；这次先用 /plan 把方向和改动范围确认清楚、再按计划动手，避免了中途返工，重构加回归半天搞定，还顺手把"以后每次改需求都省三遍"的成本降下来了——这是最值的地方。
5. 经验和技巧总结
-
有结构差异的重构任务，先
/plan让它出一版方案、确认后再执行，比我以前上来就直接改稳得多，基本不返工。 -
/plan出的计划里最好让 AI 写明"每处怎么改、怎么验证"，确认时心里更有底。 -
抽 composable 前让 TraeCode 先列清几处差异，能提前发现"原以为一样其实不一样"，避免抽完才发现逻辑被漏。