By name: yy-optimize description: > 优化方案生成器。用于代码、架构、流程、文档等各类优化场景。 仅输出优化方案供用户选择，不直接执行改动；也不用于审核代码缺陷、定位 bug 根因或撰写新功能规格。
yy-optimize
描述
优化方案生成器，帮助用户在多种可行方案中做出最佳选择。
核心原则：务实优先，不为优化而优化。如果现状已经足够好，应直接告知用户无需优化。
使用场景
- 用户提到"优化"、"改进"、"提升"、"重构"
- 用户需要改进代码性能、架构设计、工作流程、文档结构等
- 用户希望获得多个可选方案进行对比
不应触发：
- 用户明确要求直接执行某个具体操作
- 用户只是询问概念性问题（如"什么是优化"）
- 用户要求修复具体 bug（应使用相关修复技能）
指令
步骤 1. 理解优化目标
- 分析用户提出的优化需求
- 识别优化对象的类型（代码、架构、流程、文档等）
- 明确优化的约束条件（时间、资源、兼容性等）
- 显式说明自己对优化目标的假设，存在多种理解时列出选项而非默默选其一
步骤 2. 分析现状
读取优化对象及其关联文件，识别问题与机会：
- 约束边界：提取语言、范围、兼容、授权、验证和交付等边界，判断哪些限制直接影响方案可行性
- 目标与验收标准：明确优化目标、成功标准、失败条件和回归要求
- 证据收集：优先收集可验证事实，区分表象、根因与影响范围
- 结构与依赖：识别模块分层、职责边界、前后依赖，判断改动的连锁影响
- 全链路闭环：检查入口、执行、状态变化、结果回传和消费环节是否完整衔接
步骤 3. 判断是否需要优化
对步骤 2 的每个发现进行分级筛选：
- 值得改：影响执行质量、存在逻辑矛盾、会导致错误判断
- 不值得改：仅是风格偏好、上下文中已足够清晰、改动收益极低
决策分支：
- 所有问题均为"不值得改"：告知用户"当前无需优化"，说明评估依据
- 存在"值得改"的问题：仅针对这些问题生成方案，继续下一步
- 禁止将"不值得改"的项包装为优化方案
步骤 4. 生成优化方案
根据实际可行的方案数量输出：
- 如果只有 1 个可行方案，就只输出 1 个
- 如果有 2 个可行方案，就输出 2 个
- 如果方案较多，选取最值得考虑的 3 个
- 禁止强行凑数，禁止为优化而优化
每个方案包含：
- 方案名称
- 核心思路
- 实施步骤
- 预期效果（附可验证的成功标准，如"测试通过"、"性能指标达到 X"）
- 潜在风险
- 适用场景
步骤 5. 输出方案供用户选择
以结构化格式输出方案，等待用户反馈。
步骤 6. 迭代完善
- 根据用户反馈调整方案
- 补充用户关心的细节
- 合并或拆分方案
步骤 7. 确认执行
- 用户明确确认后，才执行选定的优化方案
- 确认方式：用户说"执行方案 X"、"确认方案 X"、"就按方案 X 做"等
安全边界
- 不在未获用户明确确认的情况下执行任何优化方案
- 不删除用户未授权的代码或文件
- 不引入用户未同意的依赖或工具链
输出格式
无需优化的情况
## 优化分析
**优化目标**：[一句话描述]
**现状评估**：当前实现已经足够好，无明显优化空间。
**结论**：无需优化。
有优化方案的情况
## 优化分析
**优化目标**：[一句话描述]
**现状问题**：[列出主要问题]
---
## 方案一：[方案名称]（推荐）
**核心思路**：[一句话描述]
**实施步骤**：
1. [步骤一]
2. [步骤二]
3. [步骤三]
**预期效果**：
- [效果一]
- [效果二]
**潜在风险**：
- [风险一]
**适用场景**：[描述适合什么情况下选择此方案]
---
## 方案二：[方案名称]
[同上结构]
---
## 方案三：[方案名称]
[同上结构]
---
## 请选择方案
请告诉我您倾向哪个方案，或提出您的修改意见。
示例
输入
优化这个组件的渲染性能
输出
## 优化分析
**优化目标**：提升组件渲染性能
**现状问题**：
- 每次父组件更新都会触发重新渲染
- 列表项未使用 key 优化
- 存在不必要的计算属性
---
## 方案一：memo + useMemo 优化（推荐）
**核心思路**：使用 React.memo 和 useMemo 减少不必要的重渲染
**实施步骤**：
1. 使用 React.memo 包裹组件
2. 用 useMemo 缓存计算结果
3. 优化列表项 key
**预期效果**：
- 渲染次数减少 50%+
- CPU 占用降低
**潜在风险**：
- memo 对比本身有开销
- 需要测试边界情况
**适用场景**：组件渲染开销大、父组件频繁更新的情况
---
## 方案二：状态下沉
**核心思路**：将状态移到实际使用的子组件中
**实施步骤**：
1. 识别状态使用位置
2. 将状态下移到子组件
3. 减少父组件状态数量
**预期效果**：
- 缩小重渲染范围
- 代码更清晰
**潜在风险**：
- 可能需要调整组件结构
- 状态管理分散
**适用场景**：状态只在部分子组件中使用的情况
---
## 方案三：虚拟列表
**核心思路**：对长列表使用虚拟滚动
**实施步骤**：
1. 引入虚拟列表库
2. 改造列表渲染逻辑
3. 配置可视区域参数
**预期效果**：
- 大列表渲染性能显著提升
- 内存占用降低
**潜在风险**：
- 增加依赖
- 需要处理滚动行为差异
**适用场景**：列表项超过 100 条的情况
---
## 请选择方案
请告诉我您倾向哪个方案，或提出您的修改意见。