# Product Optimize

> 产品优化全流程 — 以全新视角审视目标页面/组件/模块，系统性发现可优化点，逐项讨论、实施、验收、提交。适用于 UI/UX 优化、信息架构调整、代码质量改进、性能优化等场景。

- Skill: `bitdezi/product-optimize` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add bitdezi/product-optimize`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bitdezi/product-optimize/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: bitdezi (https://skillmd.com/u/bitdezi)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/bitdezi/product-optimize

---


# 产品优化全流程

对目标进行系统性优化，流程：发现问题 → 记录清单 → 依赖分析 → 逐项（讨论 → 实施 → 验收 → 提交）。

## 优化目标

$ARGUMENTS

---

## 第一阶段：发现问题

1. **以全新视角审视目标代码**，假装第一次看到这段代码
2. 阅读目标文件及其依赖的完整代码，理解当前实现
3. 从以下维度识别优化点（根据项目类型选择适用维度）：

   **视觉与体验**（前端项目适用）
   - 视觉层级：颜色、字号、间距的层级是否过多或混乱？
   - 信息架构：信息排列顺序是否符合用户关注优先级？有无冗余重复？
   - 组件一致性：与项目内其他页面/组件的风格是否统一？
   - 响应式：不同屏幕尺寸下的表现是否合理？

   **数据与逻辑**
   - 数据准确性：展示的数据是否真实可靠？不准的数据应弱化或移除
   - 边界情况：空状态、错误状态、极端值是否处理得当？
   - 一致性：同类逻辑在不同位置是否保持一致？

   **代码质量**
   - 是否有反模式或不符合框架最佳实践的写法？
   - 是否有硬编码的值应该提取为配置/变量？
   - 是否有可以复用已有工具函数而没有复用的地方？

   **竞品参考**
   - 同类产品在相同场景下的设计是怎样的？
   - 竞品方案背后的设计逻辑是什么？（理解逻辑而非照抄）

4. 整理为结构化列表，向用户展示并征求意见

## 第二阶段：记录优化清单

在项目中创建优化清单文档。**创建前先确认目标目录是否被 .gitignore 忽略**，如被忽略则选择其他可提交的目录，或告知用户清单将仅作本地参考。格式：

```markdown
# [目标名称] 优化清单

> 目标：[优化目标描述]
> 文件：[主要文件路径]
> 关联：[相关文件/组件/模块]

---

## 优化项列表

### 1. [问题简述]
- **现状**：[当前的具体问题]
- **目标**：[期望达到的效果]
- **状态**：⬜ 待开始

### 2. ...
```

**规范**：
- 每项必须有：现状、目标、状态
- 状态：⬜ 待开始 / 🔄 进行中 / ✅ 已完成
- 过程中发现的新问题，**必须作为正式编号的新条目追加**，不要用"后续""备注"等非结构化方式标记

## 第三阶段：依赖分析

在开始实施前，分析优化项之间的依赖关系并调整执行顺序：

- **前置依赖**：如果 A 的结论决定 B 是否需要做，先讨论 A
  - 示例：若决定删除某组件，则无需优化该组件的样式
- **强耦合项**：多个项涉及同一区域，应一起讨论方案。如果改动范围清晰且不可分割，可以合并为一个 commit；否则分别实施
  - 示例：布局调整 + 容器样式 + 信息排序 往往相互影响
- **独立项**：无依赖的小改动可以快速推进

向用户展示依赖关系和建议的执行顺序，确认后开始。

## 第四阶段：逐项优化循环

对每个优化项重复以下步骤：

### 4.1 提出方案
- 清晰描述当前问题（可辅以表格、代码片段）
- 给出具体修改方案，如有多个可选方案则列出供用户选择
- UI 相关变化可用 ASCII 示意图预览布局
- 如存在与竞品的对比，展示差异

### 4.2 讨论确认
- **等待用户明确确认后再动手**
- 用户可能提出新想法、参考截图、或否定方案，需灵活调整
- 讨论中发现的新优化点 → 正式追加到清单

### 4.3 实施修改
- 严格限制在当前优化项范围内，不顺手改其他东西
- 改完后告知用户具体改了什么

### 4.4 用户验收
- 提示用户查看效果（前端项目提示刷新页面，后端项目提示运行测试等）
- **验收是高频产出新发现的时刻**：用户实际看到效果后往往会发现遗漏或提出新想法。主动询问"还有哪些地方需要调整？"
- 等待用户反馈，根据反馈迭代调整。如果用户提出的调整属于当前项的范围，立即修改；如果是新问题，追加到清单
- 用户确认通过后进入下一步

### 4.5 提交 Git
- **每个优化项单独一个 commit**，不混合多项改动
- 提交前检查是否有上一轮遗留的未提交改动（如有，先单独提交）
- commit message 遵循项目现有的提交规范

### 4.6 更新清单 → 进入下一项
- 更新文档中的状态为 ✅，附简要完成说明
- 自动开始下一个优化项的 4.1

## 第五阶段：收尾总结

全部优化项完成后：

1. **更新清单文档**：确保所有状态为 ✅，附简要完成说明
2. **统计改动量**：运行 `git diff --stat <起始commit>..HEAD` 展示代码量变化（净增/净减行数是有说服力的优化成果）
3. **输出总结表格**：列出每项的类型、关键效果，便于用户回顾

---

## 核心原则

### 流程纪律
- **先提交再开始下一项** — 不同优化项的改动绝不混在一个 commit 中
- **先讨论再动手** — 尤其是 UI/UX 变化，必须与用户对齐方案后再写代码
- **新发现正式入清单** — 过程中发现的新问题必须作为编号条目追加，不用"备注""后续"等非正式标记
- **依赖分析先于执行** — 避免做完后发现白做（如优化了即将被删除的组件）

### 设计原则（适用于前端/UI 优化）
- 视觉层级宜少不宜多，2 级通常优于 3 级
- 减少容器装饰（边框、阴影、背景），让内容成为视觉主角
- 同一信息不要在页面上重复出现
- 展示不准确的数据比不展示更糟
- 信息排列遵循用户决策优先级 — 用户最需要的信息放最前面
- 参考竞品时理解设计背后的逻辑，不要表面照抄

### 技术原则
- 优先复用项目中已有的工具函数和组件
- 使用语义化变量/token 替代硬编码值
- 新代码的处理逻辑应与项目中同类场景保持一致
- 遵循项目所用框架的最佳实践和惯用模式