# Code Review Refactor

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

- Skill: `spring-ai-alibaba/code-review-refactor` (Agent Skill)
- Install (CLI): `npx skillmds@latest add spring-ai-alibaba/code-review-refactor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/spring-ai-alibaba/code-review-refactor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: spring-ai-alibaba (https://skillmd.com/u/spring-ai-alibaba)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/spring-ai-alibaba/code-review-refactor

---


# 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 组件
禁止：
- 仅为“看起来更漂亮”而改变现有交互语义或数据结构
- 大而全的重写（除非用户明确要求并且能接受高风险）