1. 合盖之后，AI 工具还在偷偷耗你的电？
电脑合盖后第二天电量掉了一半，打开任务管理器才发现某个 AI 工具还在后台欢快地跑着——这种情况我遇到过太多次了。很多人以为笔记本合盖就等于“关机”，实际上大部分机器默认只是进入睡眠（Sleep），而睡眠究竟省不省电、能不能真正睡死，取决于系统里一套叫做“睡眠断言”（Sleep Assertion）的机制。今天这篇就走一遍完整排查流程，搞清楚谁在你合盖后还在偷电、怎么定位、怎么处理。
这套内容适合谁看？只要你笔记本合盖后掉电明显、背包里发烫、或者开了本地 AI 工具之后电池续航大幅缩水，都值得花十分钟对照操作一遍。我实测过的机器涵盖 ThinkPad、MacBook Pro 和几台 Windows 游戏本，处理思路基本通用，底层原理也都一样。
很多人对“AI 工具偷电”的第一反应是关掉软件，但事情没那么简单。AI 工具之所以会成为偷电大户，不是因为它们算力大，而是因为它们会主动向操作系统提交“别睡”的申请，也就是睡眠断言。CPU、网卡、显卡、USB 设备、后台服务、浏览器标签页，都可能把自己变成一个“不睡眠断言”的持有者，结果就是你的电脑看着像睡了，实际还在满负荷待命。搞清楚这条链路，是解决一切合盖耗电问题的前提。
2. 睡眠断言到底是什么？先把它讲透
2.1 一句话版本：进程和设备在跟系统“请假”
理解睡眠断言，可以把它想象成公司下班后的加班审批：系统本来想锁门断电，但总有人交一份“我还在干活，先别关空调和灯光”的申请，系统就得继续供电供电。Windows 里这份申请叫 Power Request，内核层面的官方叫法就是 Sleep Assertion，持有断言的进程或驱动，可以阻止系统进入低功耗状态。
具体到 API 层面，一个进程调用SetThreadExecutionState并传入ES_CONTINUOUS | ES_SYSTEM_REQUIRED，就相当于告诉电源管理器“请保持 CPU 运行”；传ES_DISPLAY_REQUIRED，则要求屏幕保持点亮。这种调用不需要管理员权限，所以很多常驻软件都会悄悄申请。设备驱动也有自己的断言，比如网卡收到 WoL（网络唤醒）数据包、USB 控制器检测到设备活动，都会形成一层硬件级别的“别睡”理由。
理解这层机制后，很多现象就能解释通了：合盖后电脑没关机，但系统认为“有进程需要 CPU，睡眠会被推迟”。延迟一小时、两小时，甚至一整晚都不睡，第二天电池自然见底。
2.2 现代笔记本的“伪睡眠”陷阱：S0ix 和 Modern Standby
老电脑的睡眠很好理解：进入 S3 状态后，CPU 完全停止执行指令，内存数据靠微弱电流维持，整机功耗可以压到 1W 以下。但最近十多年，Intel 和微软主推了一整套叫 Modern Standby 的新方案，对应 ACPI 规范里的 S0ix 状态。它的特点是：进入睡眠后系统并未真正停止运行，后台依然可以收邮件、同步云盘，甚至升级系统。
这种“连接待机”的设计在手机上是优点，搬到笔记本上就变成了双刃剑。硬件层面，Platform AoAc（Always On, Always Connected）平台要求 CPU 在低功耗状态之间频繁切换，任何一个驱动没写好，都可能让 CPU 在 C0（活跃）和低功耗状态之间反复横跳。表现在用户体验上，就是合盖后电脑还热着、风扇偶尔转、第二天电池掉 20% 甚至更多。我的个人纪录是一台轻薄本合盖 8 小时掉了 45% 电量，后来才发现是某个后台下载服务每小时提交一次网络请求，网卡和 CPU 高频联动，整台机器几乎没真正躺平过。
最坑的是，很多电脑出厂默认就把 Modern Standby 开启了，你在“电源选项”里看到的“睡眠”，未必是传统意义上的 S3 挂起。这也是为什么同样合盖，有的人一夜只掉 2%，有的人掉 15%——不是电池质量问题，而是底层状态完全不同。
2.3 为什么 AI 工具尤其爱干这种“偷电”的活儿
普通软件很少给系统提交睡眠断言，但 AI 工具恰恰相反。我实际排查过几类工具，发现它们持有断言的动机各有不同：
- 网页版 AI 工具（Kimi、DeepSeek、ChatGPT 这类）：浏览器标签页为了保持会话状态，会定时发心跳请求、轮询结果接口，这些网络活动会破坏 CPU 的睡眠状态，即便标签页在后台被“冻结”，定时器依然可能触发唤醒。
- 本地 AI 服务（Ollama、LM Studio、Diffusion 类）：这类工具通常常驻内存监听端口，等待推理请求。只要模型加载在显存或内存里，GPU 和内存就无法进入深度节能状态。一个 7B 参数模型大概要吃 4GB 到 8GB 内存，显存占用更大，你想省电基本没戏。
- AI 编程插件（比如 Cursor、Copilot 这类 IDE 扩展）：为了后台做索引、语义分析、代码补全，会保持网络连接和文件监听服务，这些服务最容易在“合盖后继续待命”的状态下消耗 CPU。
- 各类 AI 助手小工具：很多做成常驻托盘，定时请求、自动更新、云端同步，少则每分钟一次网络握手，多则持续占用 10% 到 20% CPU。
理解了这些场景之后，定位和解决就有方向了。千万别想着“把所有 AI 工具卸载”就完事，那等于因噎废食。下面第三、四章就是完整的排查和修复路径。
3. 手把手排查：谁在霸占你的睡眠权？
3.1 powercfg 三连：把系统的睡眠状态查个底朝天
排查电源问题，Windows 自带工具powercfg是绕不开的一环。三条命令就能建立初步判断，建议按顺序执行：
powercfg /a这条命令会列出当前系统支持的所有睡眠状态。注意看输出的结尾部分：如果显示“待机（S3）”而又有“S0 低电量待机”，说明系统走的是 Modern Standby，这时候合盖耗电大的概率就很高。如果只有 S3 没有 S0，恭喜你，你用的还是传统方案，问题面会小很多。
接着执行：
powercfg /requests这条命令直接返回当前正在申请“不睡眠”的进程和服务，字段包括DISPLAY、SYSTEM、AWAYMODE、EXECUTION等。我在这步抓到过好几次真凶，比如 Chrome.exe 持有了SYSTEM请求，理由是“后台媒体会话”，还有 Ollama 的service.exe持有SYSTEM请求，原因写的是“正在等待推理请求”。
最后执行：
powercfg /sleepstudy/sleepstudy生成一个诊断报告，用浏览器打开 HTML 文件即可查看。里面记录了过去一周每一次睡眠的功耗趋势、睡眠阶段占比、被谁唤醒，还有一个关键指标“Firmware Residency Percentage”——这个百分比越高说明固件状态越稳定，越低说明系统频繁在处理事务、睡眠质量越差。我在一台旧游戏本上跑过一次，发现固件常驻率只有 58%，意味着接近一半时间系统在干活，功耗自然压不住。
3.2 睡眠报告怎么看？抓出耗电元凶的实战记录
睡眠报告打开后是一排时间轴卡片，每张卡片代表一次睡眠周期，绿色越深表示睡眠质量越好，黄色/橙色说明中间有大量“活跃”阶段。点开卡片能看到睡眠期间各硬件组件的功耗贡献：CPU、显卡、网络、存储、USB 外设分别占了多久的活跃时间。
我随手抓一个真实案例给你参考：
- 某晚 22:10 合盖，次日 7:11 开盖，总睡眠时间约 9 小时。
- 报告显示总能耗约 25Wh，其中网络模块活跃时长 4.7 小时，占比超过 50%。
- 睡眠阶段中，“Low Power State”只占了 52%，剩下的时间都在执行“Run-Time D3”或“S0 活跃”。
- 唤醒数据显示，WLAN 和 USB 控制器多次被标记为“唤醒源”。
结合powercfg /requests一并看，基本可以确定：某个网络相关进程一直在唤醒网卡，网卡又联动 CPU 处理协议栈，整个链路反复触达活跃状态。那次真凶是某云盘同步软件，但换成 AI 工具也是同样的逻辑。
3.3 事件管理器兜底排查：看是谁把系统“喊醒”的
powercfg /lastwake可以查看最近一次唤醒系统的设备或程序，但很多时候系统并不是真正被唤醒，而是在睡眠边缘反复试探，这时候事件日志反而更准。打开“事件查看器”，展开“系统”日志，筛选来源为Kernel-Power的事件，重点看事件 ID 506（系统进入了睡眠）、507（系统被唤醒）、1（不确定状态）、107（对系统睡眠进行干预）。
实战小技巧：事件 ID 107 记录的是“系统固件/驱动阻止了睡眠”，如果某一时刻持续出现 107，说明有驱动持有睡眠断言。那时的事件日志里会出现进程名或驱动名，直接按图索骥去查对应软件即可。这比从一大堆常驻软件里挨个排除高效得多。
4. 对症下药：让 AI 工具和睡眠模式和平共处
4.1 三种常见“偷电”AI 场景及处理方案
第一类是不起眼的常驻托盘式 AI 工具。这些工具为了“提升响应速度”会常驻后台，有的还自带自动更新。解决思路很直接：打开软件设置，关闭开机自启、关闭后台保活、关闭自动更新；如果软件没有这些选项，就到任务计划程序里把对应的启动触发器禁用。我用得比较稳的做法是“用到再开”，配合系统代理或浏览器扩展，把常用 AI 工具收敛到浏览器标签页里，这样断网或合盖后就能自然挂起。
第二类是用 Docker 或 WSL 跑本地 AI 服务。WSL2 有一个很隐蔽的坑：虚拟主机的 CPU 占用虽然不高，但它维持着 Hyper-V 虚拟化栈，合盖后虚拟机可能没有立刻暂停。如果你在 WSL2 里跑 Ollama 或者其他模型服务，记得在 Windows 上执行wsl --shutdown，或在合盖前主动停掉模型进程。Docker Desktop 也是同理，在“Settings-Resources”里把“Keep Docker running in background”关掉。
第三类是本地 GPU 推理工具（比如 ComfyUI、SD WebUI、Ollama 多场景）。模型加载到显存之后，GPU 处于 Partitioned Mode 时会持续消耗电力。如果你实在需要保持模型待命，把 Nvidia 控制面板的“电源管理模式”设置为“优选最大性能”反而可能比自动模式更省电，因为自动模式会让 GPU 频繁升降频，单次峰值功耗更高。不过更好的方案还是不用时主动卸载模型，Ollama 可以执行ollama stop 模型名，SD WebUI 可以在设置里加一个“空闲超时自动退出”。
4.2 用电源选项和组策略重构睡眠逻辑
系统层面的修复，目标很明确：逼着电脑在合盖后进入真正的深度睡眠，减少 Modern Standby 干预。
如果你用的电脑支持 Modern Standby，且你希望传统 S3 睡眠回归，可以在注册表层面做一个调整。打开HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power，新建一个 DWORD 值，命名为PlatformAoAcOverride，值为0，重启后大概率能回归 S3。但这一步有前提：你的 BIOS 支持 S3，且主板厂商没有把 S3 禁用。部分新机型 BIOS 里根本没有 S3 选项，强行改注册表会导致无法睡眠，只能回滚。
这里要暂停一下，我强烈建议先查 BIOS。开机进 BIOS，找“Sleep State”或“Power Management”，如果里面有 S3，那优先在 BIOS 层面选 S3；如果连这个选项都没有，再去折腾注册表。
如果不想动注册表，最简单的处理是：电源选项里把“合上盖子”这个动作从“睡眠”改成“休眠”。休眠（S4）会把内存内容完整写入硬盘然后断电，合盖一整夜掉电量基本为零。代价是唤醒速度慢一些，从 SSD 上恢复大概需要十几秒，换来的是绝对的省电和安全。这是目前我遇到“合盖耗电”问题时最爱用的一招，没有任何副作用。
4.3 设备驱动和 USB 外设才是下半场的关键
合盖后设备能不能真正进入低功耗，设备驱动层面至关重要。打开设备管理器，展开“网络适配器”，找到你的无线网卡，进属性里的“电源管理”，把“允许此设备唤醒计算机”勾选取消——这一步能拦掉很大一部分“被网络唤醒”的问题。但注意，部分网卡驱动里还有“WoWLAN 卸载”之类的选项，也最好一并关掉。
USB 设备也是睡眠杀手。无线鼠标接收器、外接键盘、USB 麦克风、甚至充电中的手机，都可能成为“唤醒源”。在设备管理器里逐一把“允许此设备唤醒计算机”取消勾选，或者直接拔掉这些设备再合盖，对比掉电变化，就能判断哪个硬件在捣乱。蓝牙设备同理，在“蓝牙”适配器设置里把电源管理也改掉。这套流程跑完，剩下的才轮到软件层面。
还有一个容易被忽略的点：BIOS 里的“ErP”或“Deep Sleep”选项。现代主板开启 ErP 后，关机状态下 USB 供电会被切断，从根源上杜绝 USB 设备在系统睡眠时的干扰。部分机器的 BIOS 里虽然叫法不同，但功能都是类似的，建议在 BIOS 的电源菜单里找找看。
4.4 既要功能又要省电：前后台分离的折中策略
很多时候，我们在合盖后还是希望 AI 工具保持在线，比如下载一个大模型、等待某个推理任务完成。这时候就不适合直接切换成休眠或关机，而是需要做前后台分离。
我的做法是：把重负载任务丢到一台不常用的机器上，或者保持电源通电时合盖，任务跑完再断电。如果你只有一台机器，那就用 Windows 的Planner任务计划设置“AC 供电时保持唤醒，电池供电时允许睡眠”。这个策略可以在电源设置里实现：把“使用电池”和“接通电源”两种状态下的“系统休眠”阈值分开设置，接通电源时合盖不睡，用电池时合盖立刻睡。这样既能保留 AI 工具的在线服务能力，又不影响移动场景的续航。
另外一个比较实用的工具是powercfg /requestsoverride。它能针对某个具体的进程或驱动，强制覆盖它的睡眠断言请求。比如：
powercfg /requestsoverride process Ollama.exe SYSTEM这行命令的意思是：即使 Ollama.exe 要求保持 SYSTEM 状态运行，系统也直接忽略。这样模型服务可以保留，但系统可以在空闲时真正入睡。需要注意，这个命令对部分驱动级断言无效，但对用户态进程非常好用，堪称“AI 工具偷电”场景的杀手锏。
5. 实操心得与避坑指南
5.1 我试过的三个反面教材（希望你避开）
先说个踩了最久的坑：一上来就在设备管理器里把所有 USB 的“允许此设备唤醒计算机”全部关掉。这样做确实能降低唤醒频率，但会让一部分外设的功能失灵，比如键盘背光驱动、部分 USB 麦克风的即插即用，还有蓝牙鼠标的唤醒灵敏度。正确做法是一个一个关，关完合盖测试一晚，记录掉电情况，再决定保留谁。
第二个坑是把“睡眠”改成“休眠”后，发现合盖开盖的体验变差了不少，因为每次开盖都得卡几秒加载。后来我调整成“合盖操作：电池状态休眠、电源状态睡眠”，这样插电时还能享受几秒唤醒的便利，纯电池出门时又不用担心电被偷光。
第三个坑是关于事件查看器的。我第一次排查时盯着 Kernel-Power 事件 ID 107 看了一晚上，结果发现那代表的是“驱动正在尝试阻止睡眠”，其中很多是正常的（比如显卡驱动加载时会有短暂阻止），并不代表实际的持续耗电。真正有价值的指标是睡眠报告里的功耗占比，以及powercfg /requests里长时间存在的进程，而不是单一事件。
5.2 给 AI 重度用户的最终建议
如果你跟我一样，桌面上开着好几个 K线图、聊天框、AI 文档工具，同时本地还跑着模型服务，那我的建议是：重新理解“合盖”这件事的本质。它只是给操作系统发了一个“用户离开”的信号，系统会尽力省电，但所有“尽力”都有边界。最好的省电手段，永远是主动管理：合盖前花十秒钟看一眼任务栏，把不需要的 AI 工具退出；需要保留的任务，要么插电运行，要么丢到云服务器上。
对于本地模型服务，建议给常用模型写一个一键启停脚本。需要时打开，不需要时直接ollama stop，比任何电源策略都有效。再配合powercfg /requestsoverride把常驻进程的断言覆盖掉，基本能做到“合盖后电量掉得跟关机差不多”。
最后分享一个我自己的习惯：主力笔记本合盖操作统一改为休眠，插电时合盖默认维持一段时间的 Modern Standby，用电池时合盖直接休眠。这样既兼顾了随时唤醒的便捷，又不会被后台的 AI 工具偷走电量。笔记本是拿来用的，不是拿来给进程当暖手宝的。把睡眠断言搞清楚之后，你会发现续航焦虑也跟着消失了大半——因为你知道合盖之后的每一毫安时都流向了哪里。
