---

name: code-review-refactor description: 对现有 Nuxt 4 + Vue3 + Vuetify3 代码进行 Code Review，并给出“可落地”的重构/复用方案（逻辑抽取、CSS 去重、页面 JSON 驱动复用）。

Code Review & Refactor 规范 Skill

当用户提出“代码很乱 / 需要 Code Review / 重构不够规范 / 提取可复用逻辑 / CSS 太多 / 页面重复应该 JSON 驱动”等诉求时，使用本 Skill。

0. 使用范围（When to Use）

• 用户明确说要 Code Review
• 或用户反馈：组件/页面冗长、CSS 重复、相似页面太多、缺少抽取到 utils/composables/services、缺少可复用结构
• 或发现你在修改时重复造轮子（应优先提取/复用）

1. 重构总原则（必须遵守）

1. 行为优先（Behavior First）：重构仅做结构优化，不改变既有功能、接口与用户交互语义。
2. 小步可验证：每次改动都应能局部验证；先提取再替换，避免“一次大改导致难排查”。
3. 优先抽取可复用逻辑：
   • 纯函数与可复用算法：app/utils/
   • 与组件生命周期/状态联动的逻辑：app/composables/
   • API 请求/数据转换：app/services/
4. 优先组件化重复 UI：
   • 动作按钮组、筛选条、分页条、表格工具栏等重复结构 -> 公共组件
   • 相似页面 -> 用“配置/JSON + 事件绑定”做驱动，而不是拷贝复制页面
5. CSS 去重：
   • 多处重复的 CSS -> 提取为组件内共用 class，或提取公共样式（同风格、同作用域规则）
   • 只为“一个小变量”复制 CSS 的 -> 合并成同一个 class + 参数化/状态类

2. Code Review 检查清单（Checklists）

2.1 逻辑抽取（Logic Extraction）

在 review 时，逐段检查是否存在以下情况：

1. 一个组件里出现多次相同的处理逻辑（如 parse/safeParse/格式化/渲染拼装）。
2. 多个页面存在相同的业务流程（如同一类 SSE 流式组装、同一类 markdown/eCharts 渲染触发）。
3. 与页面无关的纯逻辑没有被移到 utils 或 composables。

输出要求：

• 指出“重复点”与“提取位置建议”（utils/composables/services 哪个更合适）
• 给出新的接口/函数签名建议（至少用参数名与返回类型描述）

2.2 组件拆分（Componentization）

• 组件文件是否超过合理规模（建议阈值：500 行内易维护，复杂组件建议拆子组件）
• 是否存在“混杂多职责”（例如：渲染 + 请求 + 状态 + 事件处理全部写在一个组件）

输出要求：

• 提出“拆分方案”：哪些子组件/哪些 composables
• 标明拆分后组件仍保持同样的 Props/事件语义

2.3 CSS 去重（CSS De-duplication）

检查：

1. 不同组件/页面有大量相同 CSS（尤其是 markdown-body、code block、card spacing、按钮样式等）。
2. 相同选择器重复定义或只差少量颜色/间距。

输出要求：

• 优先给出“提取成一个 class”方案
• 或建议做“公共样式组件/公共 wrapper 组件”（如果是 UI 结构层面的重复）

2.4 JSON 驱动的页面复用（Config-Driven Pages）

当你发现多个管理页面“按钮数量不同、内容通过 JSON 稍有差异”，建议使用 JSON 驱动：

• 页面结构拆为通用骨架：
  • 顶部标题区
  • 操作按钮组（来自配置）
  • 表格/列表区（列定义来自配置）
  • 弹窗/抽屉（表单字段来自配置）
• 事件由页面注入（例如：onAction(actionKey, payload) 或通过映射表）

输出要求：

• 提出一个“最小通用配置 schema”（字段列表 + 示例）
• 指出每个页面需要补充的差异化配置项

2.5 TypeScript 与安全护栏

检查是否存在：

• arr[i] 取值后未做 TS 收窄导致 T | undefined 警告
• SSE/流式数据拼接在 TS 层面不安全

输出要求：

• 给出 TS 收窄的推荐写法（局部变量 + if 守卫 / type guard）

3. 推荐的输出格式（必须用）

当用户说开始 Code Review 时，你的回答应使用以下结构（按序）：

1. ## 最关键问题（按严重度从高到低）
   • 每条用一句话概括 + 标明影响范围（渲染/性能/可维护性/正确性）
2. ## 重构/复用建议（可落地）
   • 对每条建议写：提取目标（utils/composables/services/组件/CSS）、原因、预计收益
3. ## JSON 驱动复用方案（如果存在重复页面）
   • 给出配置 schema（字段列表）+ 示例（可以是伪 JSON）
4. ## 验证与回归（Test Plan）
   • 给出最少的手动验证清单（UI 是否一致、功能是否不变、关键交互是否回归）

4. 允许与禁止

允许：

• 提取公共逻辑、拆子组件、创建新 util/composable/services
• CSS 合并、抽取公共 class、增加必要 wrapper 组件 禁止：
• 仅为“看起来更漂亮”而改变现有交互语义或数据结构
• 大而全的重写（除非用户明确要求并且能接受高风险）