code-optimizer

代码优化

按照以下优先级顺序分析代码中的性能问题：

分析优先级

1. 性能瓶颈——O(n²) 操作、低效循环、不必要的迭代
2. 内存泄漏——未释放的资源、循环引用、不断增长的集合
3. 算法改进——为具体用例选择更好的算法或数据结构
4. 缓存机会——重复计算、冗余 I/O、适合记忆化处理的内容
5. 并发问题——竞态条件、死锁、线程安全问题

编辑前同步仓库（必需）

在现有仓库中创建、更新或删除文件之前，先将当前分支与远程同步：

branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

如果工作树不干净，先暂存更改，再同步，然后恢复更改：

git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop

如果缺少 origin、无法拉取，或变基／暂存时发生冲突，请停止并先询问用户。

工作流

前置条件

进行任何更改之前：

1. 检查当前分支——如果当前已处于此任务的功能分支上，则跳过
2. 检查仓库的分支命名约定（例如 feat/、feature/ 等）
3. 按照仓库约定创建并切换到新分支；如果没有约定，则使用：feat/optimize-<target>
   • 示例：feat/optimize-api-handlers

1. 分析

1. 阅读目标代码文件或目录
2. 确定语言、框架和运行时环境（Node.js、CPython、浏览器等）
3. 按照优先级顺序分析各类别
4. 估算发现的每个问题对性能的影响（例如，“将 API 响应时间从约 500ms 缩短至约 50ms”）
5. 按严重程度排序报告发现的问题（Critical 优先）

2. 应用修复

1. 向用户提供优化报告
2. 获得批准后，从 Critical／High 严重程度的问题开始应用修复
3. 每次更改后运行现有测试，以确认没有引入回归问题
4. 如果没有测试，在应用更改前提醒用户

响应格式

对于发现的每个问题：

### [Severity] Issue Title
**Location**: file:line_number
**Category**: Performance | Memory | Algorithm | Caching | Concurrency

**Problem**: Brief explanation of the issue

**Impact**: Why this matters (performance cost, resource usage, etc.)

**Fix**:
[Code example showing the optimized version]

步骤完成报告

完成每个主要步骤后，按以下格式输出状态报告：

◆ [Step Name] ([step N of M] — [context])
··································································
  [Check 1]:          √ pass
  [Check 2]:          √ pass (note if relevant)
  [Check 3]:          × fail — [reason]
  [Check 4]:          √ pass
  [Criteria]:         √ N/M met
  ____________________________
  Result:             PASS | FAIL | PARTIAL

根据该步骤实际验证的内容调整检查项名称。通过使用 √，失败使用 ×，并用 — 添加简短说明。“Criteria”行总结已满足的验收标准数量。“Result”行给出总体结论。

各阶段的特定检查项

阶段：前置条件——检查项：Branch setup、Naming convention detected、Feature branch created

阶段：分析——检查项：Issue detection、Priority categories covered、Impact estimated、Findings sorted by severity

阶段：应用修复——检查项：Fix application、User approval obtained、Existing tests run、No regressions introduced、Critical issues resolved、Warnings documented

严重程度

• Critical：导致崩溃、严重内存泄漏或 O(n³) 及以上复杂度
• High：对性能有显著影响（O(n²)、阻塞操作、资源耗尽）
• Medium：在负载下可察觉的影响（冗余操作、次优算法）
• Low：轻微改进（微优化、能提升性能的样式改进）

特定语言检查

阅读 references/language-checks.md 中与检测到的语言对应的特定检查项（涵盖 JavaScript/TypeScript、Python、Go、Rust、Java 以及通用跨语言模式）——只加载与目标代码语言匹配的部分。

验收标准

只有在以下所有内容均可验证时，运行才算合格：

• 按严重程度（严重、高、中、低）生成优化报告 — 断言至少出现一个严重程度类别，或触发“未发现问题”分支。
• 每个报告的问题均包含 Location、Category、Problem、Impact 和 Fix — 检查渲染后的模板字段均非空。
• 影响说明包含量化估算（例如，“~500ms → ~50ms”、“O(n²) → O(n log n)”）— 断言 Impact 行包含数字、复杂度类别或前后对比。
• 只有在用户明确批准后才应用修复 — 验证 Agent 在调用任何 Edit/Write 工具前发出了审批提示。
• 应用每项修复后都运行现有测试，并报告结果 — 验证已执行测试命令，且记录了通过/失败状态。
• 编辑前已检出符合仓库约定的功能分支 — 验证 git rev-parse --abbrev-ref HEAD 的结果与 feat/* 或仓库的等效约定匹配。
• 每个阶段都会输出一个包含 Result: PASS | FAIL | PARTIAL 的步骤完成报告块 — 断言该报告块出现在记录中。

预期输出

对于包含 N+1 查询的 Node.js 文件 src/api/handlers.js 中的 listUsers()，该技能应输出：

◆ Analysis (step 1 of 3 — src/api/handlers.js)
··································································
  Issue detection:           √ pass (3 issues found)
  Priority categories:       √ pass (Performance, Caching covered)
  Impact estimated:          √ pass
  Findings sorted:           √ pass
  Criteria:                  4/4 met
  ____________________________
  Result:                    PASS

### [Critical] N+1 query in listUsers
**Location**: src/api/handlers.js:42
**Category**: Performance

**Problem**: `users.forEach(u => db.query(...))` issues one query per user.

**Impact**: For 1000 users, ~1000 round-trips (~2000ms) → 1 batched query (~50ms). 40x speedup.

**Fix**:
\`\`\`js
const ids = users.map(u => u.id);
const rows = await db.query('SELECT * FROM orders WHERE user_id = ANY($1)', [ids]);
\`\`\`

预期结果：一份 Markdown 报告，每个问题对应一个区块，按严重程度从高到低排列，随后附上阶段完成报告。更完整的端到端示例请参阅 docs/README.md。

边缘情况

• 未发现性能问题：输出“代码已得到良好优化”的说明，并推荐运行时性能分析工具（perf、py-spy、Chrome DevTools）— 不要为了填充报告而编造低严重程度的问题。
• 文件超过 2000 行：停止并询问用户应重点关注哪些函数/代码段；不要悄悄截断。
• 缺少测试：应用任何修复前都要警告用户并要求明确确认；绝不悄悄应用更改。
• 优化导致测试回归：通过 git diff 确认影响范围并由用户确认回退后，立即使用 git checkout -- <file> 回退具体更改；绝不强制推送，并在丢弃前使用 git stash 备份差异，确保可以恢复工作。
• 仓库缺少 origin 或变基失败：停止并要求用户在进行任何恢复操作前确认；先运行 git status 和类似 git stash --dry-run 的检查，创建备份分支（git branch backup/pre-recovery），未经明确确认，绝不运行具有破坏性的 reset --hard 或 rm。
• 混合语言项目：使用各语言各自的检查清单进行分析；不要将 JavaScript 启发式应用于 Python 代码。
• 过早优化候选项：除非已确定可测量的热点路径，否则跳过微优化 — 只有在性能分析或基准测试能够支持相关判断时，才将其标为低严重程度。