Product Optimize

产品优化全流程

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

优化目标

$ARGUMENTS

---

第一阶段：发现问题

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

视觉与体验（前端项目适用）

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

数据与逻辑

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

代码质量

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

竞品参考

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

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

第二阶段：记录优化清单

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

# [目标名称] 优化清单

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

---

## 优化项列表

### 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 ..HEAD 展示代码量变化（净增/净减行数是有说服力的优化成果）
3. 输出总结表格：列出每项的类型、关键效果，便于用户回顾

---

核心原则

流程纪律

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

设计原则（适用于前端/UI 优化）

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

技术原则

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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: bitdezi
• Source: bitdezi/claude-skill-product-optimize
• License: MIT

Install and usage instructions live in the source repository linked above.