clayprod/pc-perf-audit

pc-perf-audit - 可测量的性能审计，适用于任何 PC

提炼自数月在一台真实机器（Ryzen 7 5700X + RTX 2060，Valorant 竞技）的工作成果。适用于任何游戏、任何 CPU（Intel/AMD）和任何 GPU（NVIDIA/AMD/Intel）： 方法论与具体平台无关；因游戏而变化的部分（exe、配置、日志、反作弊、问题场景）位于 references/jogos.md。这里真正有价值的是方法论和已被测试的内容目录；那台机器的数字仅作为示例，不是另一台机器的配方。当示例提到 Valorant 时，请解读为“某个游戏的例子”。

比任何调整都更重要的规则

1. 你无权决定什么是更好的。你只负责搭建测试。 假设→可逆更改→他玩游戏→你收集裁决。
2. 两种裁决，永远不要混淆：
   • 可测量的（帧时间、1% Low、卡顿、延迟、稳定性）：由数字决定。
   • 可评判的（清晰度、对比度、声音、“手感”、可见性）：只有用户能决定，每次只改一项。分开报告这两类信息。
3. 一次只改一个变量。单次测试不能决定任何事。 至少两次测试，丢弃热身阶段，观察每分钟的偏差，而不仅仅是平均值。
4. 基线没达到？回滚。 视觉增益不能以帧时间下降为代价（除非用户明确表示相反，即使如此也要测量并报告代价）。
5. 零代价路径，永远优先。 在提出任何消耗 CPU/GPU/延迟/风险的方法之前，先寻找更靠近视频输出层或无需代价的相同效果（例如：面板数字振动 vs. 逐帧滤镜；GPU 缩放 vs. 显示器缩放；游戏原生的 FPS 限制器 vs. 驱动限制器；关闭应用 vs. 修改优先级）。
6. 永远不要下结论“这台机器已经发挥到极致了”。 “瓶颈在哪里”和“能否运行得更快”是两个不同的问题：串行代码通过更高的有效时钟、更低的内存延迟和更少的缓存争用来运行得更快。
7. 先有证据，再有断言。 看似合理的理论已经推翻过很多轮测试。不要在测量之前就把假设当作结果呈现，也不要宣称没有经过测量的提升。
8. 测量工具本身也是负载。 测量器、收集器、监控软件、覆盖层以及代理本身（Claude、终端、PowerShell）都会消耗 CPU。在捕获期间：不要使用本机。
9. 当测量结果与用户连续几天感受不符时，先怀疑测量，而非他的感知。 这种情况已经重复了 4 次（参见 references/armadilhas.md）。
10. 只确认有风险或不可逆的操作（固件、BIOS、安全、数据擦除）。其余操作：直接做，一句话解释原因，然后继续。
11. 可逆性： 在进行任何更改之前，记录原始值和撤销命令。任何不留痕迹的试运行都不允许；模拟操作不得写入磁盘。

步骤（按顺序执行；每一步都有退出标准）

步骤 0 - 用户画像与目标（简短访谈）

一次性提问（使用 AskUserQuestion，不要长对话）：

• 主要游戏、模式（竞技/休闲）、目标（目标 FPS、显示器刷新率）。为每个游戏填写 references/jogos.md 中的信息表（exe、API、引擎、配置、日志、反作弊、测试方式）。
• 症状：微卡顿、开枪瞬间帧数下降、完全冻结、蓝屏、音频中断、输入延迟、画面闪烁/锯齿、黑屏。具体是哪个分钟/地图/时刻？（为捕获设定锚点）
• 用户不可妥协项（不能动也不能争辩）：灵敏度、DPI、分辨率、拉伸显示模式、准星、数字振动、他需要保持打开的应用（例如：Discord）。
• 他已经尝试过什么，哪些感觉好/不好。是否曾有过“完美”的一天？什么时候？
• 游戏的反作弊（Vanguard、EAC、BattlEye、FACEIT）：会限制亲和性、优先级、注入覆盖层和第三方驱动。请参见 references/catalogo-alavancas.md 第 11 节。 输出： 将用户画像写入日志（模板在 references/template-diario.md）。

步骤 1 - 清单（只读）

运行 scripts/inventario.ps1 -Saida <pasta>（PowerShell 5.1，最好以管理员身份运行；不以管理员身份运行某些字段可能为空，脚本会给出提示）。它将收集 CPU、GPU、RAM（实际速度 vs 标称速度、电压）、BIOS/主板、操作系统、电源计划与 EPP、MPO、HAGS、VBS/HVCI、游戏模式、GameDVR、安全启动、Defender、更新服务、网卡、磁盘、显示器、分辨率/刷新率、启动项、服务与第三方进程、已知覆盖层，以及 6008/1001/WHEA 事件计数。阅读 inventario.txt 并对平台进行分类：CPU: AMD Zen2/3/4/5 (X3D?) | Intel Core 混合架构（P+E） | Intel Core 非混合，GPU: NVIDIA | AMD | Intel Arc | 集成显卡。这将决定使用目录中的哪些部分。 输出： 在日志中创建一张“项目 -> 值 -> 正常？ -> 假设”表格。现在还不要做任何更改。

步骤 2 - 环境清理（游戏运行时后台运行的程序）

目标：建立一个已知且干净的游戏环境。使用清单 + Get-Process。

• 列出所有占用 CPU 的后台进程（浏览器、启动器、云同步、更新程序、覆盖层、RGB 控制、录屏软件、代理本身）。分类为：关闭、阻止启动、保留（由用户决定）。
• 优先选择阻止启动（StartupApproved、策略、Store 应用的后台权限），而不是每隔几分钟去杀死进程。检查你列表中的项是否真正匹配进程名称（一个从未匹配过 WhatsApp.Root 的 'WhatsApp' 幸存了 17 天）。
• 会自动重新启动的更新程序/服务（Windows Update、厂商更新程序）：决定如何限制并验证限制是否持久（参见陷阱：安装程序会重新创建任务/服务）。
• 向 Present 注入 DLL 的覆盖层（RTSS/Afterburner OSD、Discord 叠加层、Steam、GeForce、Medal、OBS hook）：开销虽小，但在渲染线程上。列出它们，不要在不告知用户的情况下杀死它们；测量其效果是可选的（在本机上未证明有收益）。 输出： “游戏期间开启的应用”列表 + 限制机制 + 如何验证。

步骤 3 - 可测量的基线

完整协议在 references/metodo.md。摘要：

1. 关闭游戏，机器稳定运行（开机后 5 分钟以上），不打开任何新程序。
2. 在用户抱怨的模式/地图的真实游戏中运行 scripts/capturar.ps1 -Processo <exe> -Segundos 420 -Rotulo <texto>（如果 PresentMon 有风险，则可以放弃死亡竞赛模式）。捕获期间不进行分析（分析在游戏运行时的 CPU/RAM 负载中进行）。
3. 游戏结束后，关闭游戏：运行 python scripts/analisar-frametime.py <csv>。
4. 至少两次测试，使用相同地图。第一次在系统启动/补丁/驱动更新后，属于冷运行。
5. 询问用户的裁决（分数/评语）并记录在数字旁边。当积累 8 次以上的捕获和裁决后，验证哪个指标（排名）与用户的感受相关，并使用该指标。 输出： 每种场景（死亡竞赛和 5v5 是不同的！）的基线，包含每分钟卡顿数、最差帧、1%/0.1% low、p99、每分钟偏差以及用户的裁决。

步骤 4 - 诊断

决策树在 references/diagnostico.md。按顺序提问：

1. CPU 受限还是 GPU 受限？（MsCPUBusy 与 MsGPUBusy，中位数以及坏帧时的值）
2. 问题是平均值还是尾部？（每分钟卡顿数、最差帧、超过 20 ms 的严重帧）
3. 卡顿是否有触发条件？（回合切换、加载、重生、地图切换、技能施放、游戏结束、近期补丁/驱动 = 着色器重新编译）——与游戏日志交叉核对。
4. 是否有外部资源争抢？（内核/ETW 跟踪；ISR/DPC；磁盘 I/O；可用内存；温度和频率）——只有使用正确的工具才能得出结论。
5. 如果是冻结/蓝屏/音频中断，则属于另一条决策树（硬件/稳定性/射频）。 输出： 按（概率 x 测试成本 x 可逆性）排序的假设列表。

步骤 5 - 调节杠杆（从最便宜到最昂贵）

查阅 references/catalogo-alavancas.md，只读检测到的平台对应的部分，并且在提出任何建议之前先阅读已被驳斥的列表。攻击顺序：

1. 零成本层：扫描/显示（GPU 缩放、数字振动、显示器响应时间）、Windows（MPO、电源计划/EPP、限制更新、后台应用）。
2. 运行游戏线程的核心速度：EPP/boost、功耗限制、SMT/E 核、内存延迟与电压、FCLK/ring、Curve Optimizer/降压、散热。
3. 稳定性：内存电压、XMP/DOCP、BIOS、C 状态、电源、温度。
4. 游戏内设置：仅降低每个角色的 CPU 开销的设置（阴影、尸体、计数器）；尊重不可妥协项和竞争信息（声音、敌方阴影）。
5. 网络/音频/外设：先测量；网络调整曾使情况恶化 5 倍。 对于每个杠杆：原始值、应用命令、撤销命令、可测量的假设以及用户需要判断的内容。

步骤 6 - A/B 测试与裁决

对于每个杠杆（一次一个）：应用 -> 在相同场景下进行两次捕获 -> 与同一张地图/模式的基线进行比较 -> 询问用户感受 -> 决定：采纳 | 回滚 | 无结论（需要更多数据）。即使是被驳斥的方案也要记录下来，附上数字：被驳斥列表是该项目最有价值的资产。 比较规则：根据机器状态而非日期来过滤基线。 如果两次测试之间你更改了其他内容，那么该序列就变成了轶事——重新测试。

步骤 7 - 冻结已批准的状态

当用户说“好了，我不想让它回滚”时：将状态（BIOS、驱动、服务、任务、注册表、电源设置、游戏配置、启动项）拍摄成一份探针列表，包含期望值，定期运行它，并在补丁/驱动/BIOS 更新后运行。规则：

• 在冻结之前，先在不冻结的情况下运行比对，并解决每一个偏差（有意的 -> 冻结；回归 -> 修复）。冻结带有偏差的状态会将回归记录为黄金标准。
• 在游戏关闭且使用提升权限的会话下进行冻结。
• 产生误报的探针会教会我们忽略该探针：调查该值的历史记录。
• 名称或键值错误的探针比缺失探针更糟糕：对照实际文件进行检查。
• 记录一次空的 CMOS/BIOS 重置会静默撤销哪些设置（SMT、C 状态、DOCP、DRAM 电压、安全启动、Resizable BAR、PBO）以及恢复的路线图。

步骤 8 - 活文档

维护一份日志（references/template-diario.md）：当前状态、基线、被驳斥列表、已付出的代价的陷阱、按顺序排列的待办事项。纠正错误的条目要在顶部明确进行更正说明，而不是删除——错误历史有助于避免重犯。

如何向用户交付结果

• 使用 pt-BR（或用户的母语），直接了当。每个决策一句话解释原因。
• 每次捕获的结果表格：场景、每分钟卡顿数、最差帧、超过 20 ms 的严重帧、1%/0.1% low、偏差、用户裁决。区分“数字说明了什么”和“只有你能说的部分”。
• 永远不要报告固定每秒帧数作为“用户看到的”：游戏内的帧计数器使用短时间窗口。
• 标记每个断言：已测量、假设、文献资料（来源）、用户决定。

此技能的关联文件

• references/metodo.md - 捕获协议、指标、裁剪、指标验证。
• references/jogos.md - 每个游戏的信息表、日志标记、按类型/引擎划分的配置文件、通用与特定部分。
• references/diagnostico.md - 症状 -> 工具 -> 可能原因的决策树。
• references/catalogo-alavancas.md - 所有已尝试/测试过的内容，按层级和制造商分类。
• references/armadilhas.md - 已经消耗过迭代的工具错误和推理错误。
• references/template-diario.md - 被审计机器的日志/AGENTS.md 模板。
• scripts/inventario.ps1 - 只读清单（PS 5.1，ASCII）。
• scripts/capturar.ps1 - 不进行分析的 PresentMon 捕获 + 进程快照。
• scripts/analisar-frametime.py - 健壮的离线分析（Python 3 标准库）。