bitdezi 产品优化全流程
对目标进行系统性优化，流程：发现问题 → 记录清单 → 依赖分析 → 逐项（讨论 → 实施 → 验收 → 提交）。
优化目标
$ARGUMENTS
第一阶段：发现问题
以全新视角审视目标代码，假装第一次看到这段代码
阅读目标文件及其依赖的完整代码，理解当前实现
从以下维度识别优化点（根据项目类型选择适用维度）：
视觉与体验（前端项目适用）
- 视觉层级：颜色、字号、间距的层级是否过多或混乱？
- 信息架构：信息排列顺序是否符合用户关注优先级？有无冗余重复？
- 组件一致性：与项目内其他页面/组件的风格是否统一？
- 响应式：不同屏幕尺寸下的表现是否合理？
数据与逻辑
- 数据准确性：展示的数据是否真实可靠？不准的数据应弱化或移除
- 边界情况：空状态、错误状态、极端值是否处理得当？
- 一致性：同类逻辑在不同位置是否保持一致？
代码质量
- 是否有反模式或不符合框架最佳实践的写法？
- 是否有硬编码的值应该提取为配置/变量？
- 是否有可以复用已有工具函数而没有复用的地方？
竞品参考
- 同类产品在相同场景下的设计是怎样的？
- 竞品方案背后的设计逻辑是什么？（理解逻辑而非照抄）
整理为结构化列表，向用户展示并征求意见
第二阶段：记录优化清单
在项目中创建优化清单文档。创建前先确认目标目录是否被 .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
第五阶段：收尾总结
全部优化项完成后：
- 更新清单文档：确保所有状态为 ✅，附简要完成说明
- 统计改动量：运行
git diff --stat <起始commit>..HEAD展示代码量变化（净增/净减行数是有说服力的优化成果） - 输出总结表格：列出每项的类型、关键效果，便于用户回顾
核心原则
流程纪律
- 先提交再开始下一项 — 不同优化项的改动绝不混在一个 commit 中
- 先讨论再动手 — 尤其是 UI/UX 变化，必须与用户对齐方案后再写代码
- 新发现正式入清单 — 过程中发现的新问题必须作为编号条目追加，不用"备注""后续"等非正式标记
- 依赖分析先于执行 — 避免做完后发现白做（如优化了即将被删除的组件）
设计原则（适用于前端/UI 优化）
- 视觉层级宜少不宜多，2 级通常优于 3 级
- 减少容器装饰（边框、阴影、背景），让内容成为视觉主角
- 同一信息不要在页面上重复出现
- 展示不准确的数据比不展示更糟
- 信息排列遵循用户决策优先级 — 用户最需要的信息放最前面
- 参考竞品时理解设计背后的逻辑，不要表面照抄
技术原则
- 优先复用项目中已有的工具函数和组件
- 使用语义化变量/token 替代硬编码值
- 新代码的处理逻辑应与项目中同类场景保持一致
- 遵循项目所用框架的最佳实践和惯用模式