/x-audit-perf

name: x-audit-perf
description: |
  独立性能巡检 skill。不在 x-dev → x-verify-spec → x-qa-gate 主流程内，由用户手动触发或在大里程碑后调用。
  调子 agent 做全项目视角的性能审查：N² 嵌套、不必要循环、大对象拷贝、同步阻塞、数据库 N+1、缓存失效、不必要的 await。
  触发：用户说"性能巡检"、"audit perf"、"看看有没有性能问题"、"perf review"，或大版本发布前。

x-audit-perf · 性能巡检

x-audit-perf 是独立巡检 skill，**不在 x-dev → x-verify-spec → x-qa-gate 主流程内**。它由用户手动触发或大里程碑后调用，做全项目视角的性能审查。

为什么独立

性能问题通常需要**全局视角**才有意义——单个任务级别揪 N² 是过度工程，得看整个调用链；缓存失效要看跨服务流。塞进每个任务的 gate 是噪音，所以剥离出来。

流程

1. 用户触发（手动调用 / 大里程碑）。 2. dispatch 一个子 agent，prompt 包含本 SKILL.md 的检查清单 + 项目代码。 3. 子 agent 输出 audit-perf 报告。 4. 写到 `reports/audit/audit-perf-YYYYMMDD-HHmmss.md`。 5. 不自动触发 x-fix——由用户决定哪些问题进入 backlog。

子 agent dispatch

Agent({
  description: "Performance audit",
  subagent_type: "general-purpose",
  prompt: <本 SKILL.md 的"检查清单"段 + 项目代码 + 输出格式>
})

报告顶部必须填写 `Completed by model`。

检查清单

1. 算法复杂度

• 嵌套循环：O(n²) 以上是否必要？能否用 hash / index 降到 O(n)?
• 在循环内做 I/O / 重复扫描数据？
• 排序 / 查找算法选择是否合理？

2. 数据结构使用

• 用 list 做频繁查找（应该用 set / dict）？
• 大对象拷贝（应传引用 / 用 slice）？
• 频繁字符串拼接（应用 builder / join）？

3. I/O 模式

• 同步阻塞 I/O 在异步上下文中？
• 数据库 N+1（在循环里查数据库）？
• 文件 / 网络请求未批量化？

4. 缓存与状态

• 重复计算未缓存（纯函数 expensive call）？
• 缓存失效策略缺失或过激进？
• 内存泄漏（持有不必要的引用）？

5. 并发与并行

• 不必要的 await / lock 串行化？
• 临界区过大？
• 能并行的串行执行了？

输出

写入 `reports/audit/audit-perf-YYYYMMDD-HHmmss.md`，模板见 `templates/audit-perf-template.md`。

不在范围

• 单任务级别的 perf 审查（应在 x-qa-gate R2 boundary 里捎带 P1 即可）
• 微优化（编译器能搞定的事）
• 硬件相关（CPU 缓存、SIMD 等，不在 AI 评审范围）