技能（Skill）：回顾表现

目的 (Purpose)

仅审查性能问题的代码。不要定义范围（差异与代码库）或执行安全/架构/语言框架约定分析；这些由其他原子技能处理。以标准格式发出结果列表以进行聚合。重点关注算法复杂性、查询效率、I/O 和网络成本、内存行为、争用和并发瓶颈、缓存策略以及可测量的回归风险。

核心目标（Core Objective）

首要目标：生成一个以性能为中心的结果列表，涵盖给定代码范围的复杂性热点、查询效率、I/O 成本、内存行为、并发争用、缓存和回归风险。

成功标准（必须满足所有要求）：

✅ 仅性能范围：仅审查性能维度；未执行范围选择、安全性、架构或语言/框架风格审查
✅ 评估所有八个类别：在相关的情况下评估复杂性、数据库/查询效率、I/O/网络成本、内存/分配、并发/争用、缓存/重用、面向负载的行为和可观察性
✅ 符合调查结果格式：每个调查结果包括位置、类别（“cognitive表现”）、严重性、标题、描述和可选建议
✅ 准确分配的严重性：影响生产的问题标记为“严重”；可扩展性风险标记为“重大”；本地化优化标记为“次要”/“建议”
✅ 可操作的输出：每个发现都有具体的位置参考和具体的修复或改进建议，除非提供测量证据，否则不要求基准数字

验收测试：输出是否包含涵盖所有相关维度的性能结果列表，以及基于证据的严重性评级和可操作的、位置参考的建议？

范围边界（范围边界）

本技能负责：

算法复杂度热点（O(n²)+、嵌套循环、重复扫描）
数据库/查询效率（N+1、缺少分页、广泛选择）
I/O 和网络成本（闲聊、缺少批处理、关键路径阻塞）
内存和分配行为（流失、大对象保留、无限增长）
并发和争用（锁争用、goroutine 饥饿、队列背压）
缓存策略（热路径上缺少缓存、失效风险、踩踏风险）
面向负载的行为（缺少限制/防护、昂贵的默认值）
性能的可观察性（缺少指标/跟踪热路径）

本技能不负责：

范围选择（决定要分析哪些文件/路径）——范围由调用者提供
安全审查——使用“review-security”
架构审查——使用“review-architecture”
特定于语言/框架的约定 - 使用 review-dotnet、review-java、review-go 等。
全面的 SQL 性能分析 — 使用 review-sql
全面精心策划的审核——使用“审核代码”

转交点：当所有性能结果发布后，移交给“审查代码”编排器进行聚合，或直接交付给用户进行以性能为中心的审查会议。

使用场景（用例）

精心安排的审查：当 review-code 运行范围 -> 语言 -> 框架 -> 库 -> cognitive时，用作cognitive步骤。
以性能为中心的审查：当用户只想在合并或发布之前检查性能维度时。
回归预防：验证更改不会引入明显的延迟、吞吐量或内存回归。

何时使用：当任务包含绩效审核时。范围和代码范围由调用者或用户确定。

行为（行为）

该技能的范围

分析：给定代码范围中的性能维度（调用者提供的文件或差异）。不决定范围；接受代码范围作为输入。
不要：执行范围选择、安全审查、架构审查或语言/框架风格审查。只关注性能。

审查清单（仅限性能维度）

复杂性热点：检测不必要的 O(n^2)+ 行为、重复扫描、大型集合上的嵌套循环以及可避免的重新计算。
数据库和查询效率：N+1 访问模式、缺少分页、广泛选择、低效联接/过滤器以及查询频率放大。
I/O 和网络成本：频繁的远程调用、缺少批处理、关键路径上的阻塞调用、无限制的重试/超时以及不良的退避行为。
内存和分配：过多的分配/搅动、大对象保留、不必要的副本、无限增长和可避免的缓冲。
并发和争用：锁争用、序列化关键部分、线程/goroutine 饥饿、队列背压和超额订阅风险。
缓存和重用：热读路径上缺少缓存机会、失效正确性风险、踩踏风险和低价值缓存层。
面向负载的行为：缺少限制/防护（批量大小、页面大小、并发上限）、昂贵的默认值以及负载下缺乏降级策略。
性能可观察性：缺少围绕热路径的指标/跟踪，从而妨碍回归检测和容量规划。

严重性指导

关键：可能会对生产产生明显影响（例如无界循环/增长、热路径中重复昂贵的 I/O、灾难性查询模式）。
主要：现实流量/数据增长带来的强烈回归或可扩展性风险。
次要/建议：本地化或影响较低的优化机会。

语气和参考

专业和技术：参考特定位置（文件：行或查询/块）。
发出包含位置、类别、严重性、标题、描述、建议的调查结果。

输入与输出 (Input & Output)

输入（输入）

代码范围：用户或范围技能已选择的文件或目录（或差异）。该技能不决定范围；它仅检查所提供的代码的性能。

输出（输出）

以附录：输出合同中定义的格式发出零个或多个结果。
此技能的类别是cognitive表现。

限制（限制）

硬边界（Hard Boundaries）

不要执行范围选择、安全性、架构或语言/框架风格审查。保持在性能范围内。
不要在没有具体地点或可行建议的情况下给出结论。
不要声称基准数字，除非在输入中提供了测量证据。

技能边界 (Skill Boundaries)

不要做这些（其他技能可以处理它们）：

不要选择或定义代码范围 - 范围由调用者或“审查代码”确定
不要执行安全性、架构或语言/框架审查——使用各自的原子技能
不要执行全面的 SQL 性能分析 — 使用 review-sql
不要运行或执行代码来测量性能 - 使用“run-automated-tests”进行测试执行

何时停止并交接：

当所有性能结果发布后，将其移交给“审核代码”以在精心策划的审核中进行聚合
当用户需要全面审查（范围+语言+cognitive）时，重定向到“审查代码”
当 SQL 性能问题占主导地位时，建议还运行“review-sql”以获得更深入的 SQL 覆盖

自检（Self-Check）

核心成功标准

仅性能范围：仅审查性能维度；未执行范围选择、安全性、架构或语言/框架风格审查
评估所有八个类别：在相关的情况下评估复杂性、数据库/查询效率、I/O/网络成本、内存/分配、并发/争用、缓存/重用、面向负载的行为和可观察性
符合调查结果格式：每个调查结果包括位置、类别（“cognitive表现”）、严重性、标题、描述和可选建议
准确分配的严重性：影响生产的问题标记为“严重”；可扩展性风险标记为“重大”；本地化优化标记为“次要”/“建议”
可行的输出：每个发现都有具体的位置参考和具体的修复或改进建议，除非提供了测量证据，否则不会声称基准数字

流程质量检查

是否仅审查了性能维度（没有范围/安全/架构/风格）？
是否涵盖了相关的复杂性、查询效率、I/O、内存、并发、缓存和加载行为？
每个发现是否都包含位置、类别=cognitive性能、严重性、标题、描述和可选建议？
高影响回归风险是否与次要优化明确区分开来？

验收测试

输出是否包含涵盖所有相关维度的绩效结果列表，以及基于证据的严重性评级和可操作的、位置参考的建议？

示例（示例）

示例 1：N+1 查询模式

输入：循环通过每次迭代一个查询来获取每个父级的子记录。
预期：针对 N+1 行为发出主要/关键发现；建议批量查询或连接策略。类别=cognitive表现。

示例 2：热路径分配流失

输入：请求处理程序重复分配大型临时缓冲区并多次序列化有效负载。
预期：发布关于分配压力和延迟影响的主要发现；建议重用/池化或单遍转换。类别=cognitive表现。

边缘情况：小格式差异中没有明显的性能风险

输入：差异仅包括注释/重命名，没有行为变化。
预期：不发出任何发现或一条建议级别的注释；不要发明优化工作。类别仍然是任何发出的发现的cognitive表现。

附录：输出合约

每项调查结果必须遵循标准调查结果格式：

元素	要求
位置	`path/to/file.ext`（可选行或范围，或查询/块标识符）。
类别	“cognitive表现”。
严重性	`关键` \| `主要` \| `次要` \| `建议`。
标题	简短的一行摘要。
描述	1-3句话。
建议	具体修复或改进（可选）。

示例：

- **Location**: `service/orders/handler.go:118`
- **Category**: cognitive-performance
- **Severity**: major
- **Title**: Per-item remote call inside request loop
- **Description**: The handler performs one downstream call per item, creating linear remote round-trips and latency growth.
- **Suggestion**: Batch requests or prefetch related data once per request; add timeout and bulk size guards.

review-performance