合盖一晚上，第二天打开笔记本，电量掉了四成，机身还热得能煎鸡蛋。这种场景你只要遇到过一回，就会开始怀疑一切：我不是合盖了吗？电脑不是应该睡了吗？凭什么一晚上过去，AI 工具还在后台悄悄烧我的电？答案不在“AI 工具”本身，而藏在一个叫睡眠断言（Sleep Assertion）的系统机制里。这篇文章我会从睡眠断言的原理讲起，用 Windows 和 macOS 上现成的排查命令，一步步带你定位到底是谁在阻止电脑入睡、为什么 AI 工具特别容易干这事，最后给出一套可落地的电源优化方案。内容对普通用户、开发者、运维都适用，尤其适合那些电脑里常年挂着大模型客户端、训练脚本、会议纪要工具的人。
1. 合盖不是关机：两种睡眠模式在背后打架
1.1 从 S3 到 S0：你的电脑睡眠模式可能和你想的不一样
先说一个很多人会忽略的事实：你按了合盖，系统收到的指令是“请求进入睡眠”，但这个请求不一定被真正执行。现代笔记本上存在两套完全不同的睡眠机制，你的机器默认跑哪一套，直接决定了会不会出现“合盖后在偷电”的问题。
传统上，Windows 电脑用的一直是 S3 睡眠，也叫“挂起到内存”。S3 状态下，CPU 和绝大多数设备都断电，只有内存保持供电，用来维持当前系统状态。因为几乎没什么硬件在工作，整机功耗可以降到 1 瓦以下，甚至接近 0。这种睡眠很纯粹：睡着了就是真睡着了，不会吭声，一晚上下来电池几乎不缩水。
但大概从 Windows 8 开始，微软为了对标手机待机体验，大力推行 Modern Standby，也就是 S0 低功耗待机。这种模式下系统并没有真正“暂停”，CPU 仍然可以低频率运行，网络可以保持连接，通知推送、后台下载、邮件同步都能在合盖后继续。听起来很方便，代价就是功耗高得多，而且对硬件驱动、固件的要求极高。一旦某个驱动不给力，或者平台策略设计得鲁莽，合盖后的耗电速度会非常离谱。
可以这样理解：S3 是让整个屋子断电，只剩一盏应急灯；S0 是关了大灯，但暖气、冰箱、Wi-Fi 都还开着，只是调低了功率。后者当然舒服，但电费单不会骗人。
你在自己的设备上可以用一条命令确认当前睡眠模式：打开终端（Windows 下是管理员权限的 PowerShell 或 CMD），输入powercfg /a。如果输出里出现“S0 低电量待机”或者“Modern Standby”字样，而 S3 状态不可用，说明你手上拿的就是 S0 设备。这就是很多人合盖后掉电的底层原因——机器压根没真正“睡死”。
1.2 睡眠断言到底是什么：系统里的“拒绝入睡投票机制”
那为什么系统拿到合盖请求后，还敢继续运行？这就涉及睡眠断言（Sleep Assertion）这个核心概念。
操作系统在进入睡眠前会做一次“全系统评估”，看看当前有没有任何进程、驱动、固件组件声明了自己正在处理重要任务，暂时不能断电。每一条这样的声明，就是一条断言。任何一个有效断言存在，系统就会礼貌地推迟睡眠，直到这个任务结束，或者系统强制执行某些策略。
用一个宿舍类比：晚上到了熄灯时间，舍管阿姨来断电。但每个舍友都有权举一块“别断电，我在赶需求”的牌子。只要还有一个人举着牌子，阿姨就不能拉闸。睡眠断言就是这么一块牌子，只不过举牌子的人可能是某个应用进程、后台服务、显卡驱动、网卡驱动，甚至 BIOS 固件。
对软件开发者来说，Windows 上最常用的举牌子方式是SetThreadExecutionState这个 API，或者更精细的PowerCreateRequest/PowerSetRequest组合。调用之后，系统就会把这条调用记录为一个电源请求，可以被工具查询到。macOS 端的机制类似，系统称之为“断言”（Assertions），由pmset管理。不管是哪个系统，意图都是同一个：哪怕屏幕上没有窗口，后台的进程也有办法告诉内核“我还在干活，别睡”。
AI 工具之所以在各种“偷电元凶”里格外扎眼，核心技术原因就在这里。训练脚本、大模型推理、语音转写、实时字幕、AI 会议纪要这类任务，本质上都是长时间高负载的持续计算。开发者为了避免任务中途因为睡眠而中断，几乎都会主动添加断言；有些桌面端 AI 工具即使平时闲置，也会因为网络心跳连接、模型热加载、后台检查更新而默认不释放断言。于是你合盖后，它就在你看不见的地方，继续举着“别断电”的牌子。
看穿了这套机制，排查思路就清晰了：不是靠猜，而是直接问系统“现在谁举着牌子”。
2. Windows 用户怎么揪出发出睡眠断言的元凶
2.1 先跑这三个命令看清楚系统睡眠状态
Windows 自带了一套完整的电源排查工具，都是命令行方式，普通用户用起来也不难。下面这三个命令先用起来，任何一个都能给你明确的线索。
第一个是powercfg /a，用来确认你的机器到底支持哪些睡眠状态。刚才已经说过，如果显示 S0 低功耗待机而不支持 S3，那这台机器从硬件到系统都是按 Modern Standby 设计，后续的排查重点就不是“要不要现代待机”，而是“谁能在这个待机模式下继续活动”。
第二个是powercfg /requests，这是最直接命中目标的一条命令。它会把当前所有正在被系统记录的活动电源请求列出来，并且显示发起方类别，比如显示、系统、驱动等。运行之后你会看到类似这样的输出：
显示: [PROCESS] \Device\HarddiskVolume3\Program Files\xxxAI\xxxAI.exe 正在显示请求... 系统: [DRIVER] \Driver\xxNetwtw 无线网卡正在保持连接...看到这样的结果，基本就实锤了：某一个 AI 客户端正在通过进程请求阻止睡眠。我们稍后专门讲怎么解读这些行。
第三个是powercfg /sleepstudy，它会生成一份 HTML 格式的睡眠研究报告。注意这个命令不会立刻给你结论，它依赖系统过去一段时间记录的睡眠会话数据。运行后会在当前目录生成一个sleepstudy-report.html，打开后能看到机器每次睡眠的时间线、睡眠中哪些硬件活跃、电量消耗曲线、以及退出睡眠的原因。这个报告对定位“明明设置了睡眠但睡眠期间还在耗电”的问题非常有帮助。
三个命令配合起来，基本覆盖了“能不能睡、谁不让睡、睡了之后在干嘛”这三个层面的问题。
2.2 AI 工具为什么最爱“举牌反对入睡”
在实际排查中，我见过最多的电源请求类型就是 AI 类进程，原因不复杂，但值得展开聊聊。
拿本地大模型工具举例，比如 Ollama、LM Studio、Stable Diffusion WebUI，这类应用一旦从模型仓库加载模型到显存，进程就处于一个“随时准备响应推理请求”的状态。为了保证请求来了能马上处理不被睡眠打断，它们在设计上就会调用系统电源请求 API。你要是开着这类工具合盖，系统大概率会收到持续有效的电源请求。
还有一种更隐蔽的情况：浏览器里跑 AI 页面。现在很多 AI 对话网页、生成图片网站、AI 实时字幕插件，内部会用 WebSocket 保持与服务器的长连接，有些还会尝试用 WebGPU 在浏览器本地跑小模型。浏览器在检测到页面有网络活动或媒体播放时，会认为当前会话仍然是活跃的，于是主动声明“不要进入睡眠”。你明明只开了一个 AI 页面没在操作，合盖后电量照样哗哗掉，原因之一就在这。
另外，AI 语音相关工具也特别容易踩中“媒体请求”这一层。比如 AI 会议纪要助手，它在后台监听麦克风或播放提示音，系统会把它当成“正在播放音频”，进而阻止进入睡眠。这一类可以用powercfg /requests里的显示类请求看出来，某些情况下也会出现在“音频”相关分类里。
本质上，这不是 AI 工具“有意偷电”，而是它们为了防止任务中断而主动保持系统唤醒。问题是，很多用户在睡前只是合盖，并没有把进程退出。于是这块“不许睡”的牌子就一直挂着。
2.3 用 powercfg 请求列表锁定具体偷电进程
用powercfg /requests锁定元凶，最关键的是会看输出里的分类和进程路径。一条典型的 AI 工具请求长这样：
系统: [PROCESS] \Device\HarddiskVolume3\Users\你的用户名\AppData\Local\Programs\PyTorch\python.exe 由于 AI 训练任务正在运行而请求系统不支持睡眠看到这样的输出，事情就很明确：一个 Python 进程，路径里带 PyTorch，正在声明系统不能睡。这种情况要么是你在后台跑了训练或推理任务，要么是某个工具内置了 Python 运行时，一直在空转但仍持有请求。
除了/requests，专家模式下我还会配合powercfg /energy做一轮动态跟踪。powercfg /energy会在 60 秒内采集系统功耗相关事件，然后生成一份 HTML 报告，里面能列出 CPU 使用率异常的进程、高功耗的驱动组件、以及电源策略错误。虽然报告里的错误项很多是“建议性”的，但如果你发现某个 AI 相关的服务进程频繁出现在高 CPU 或高能耗列表里，那它基本上就是合盖耗电的重要嫌疑人了。
还有一条容易踩的坑：powercfg /requests显示“当前没有活动电源请求”，但机器还是死活不肯睡。这种情况通常不在进程层面了，而是驱动、固件或 Modern Standby 策略在发断言，命令抓不到，需要通过sleepstudy报告和事件查看器进一步追查。这部分在第五大节里我会专门讲。
3. macOS 用户也一样：pmset 断言排查实录
3.1 pmset 常见排查命令一览
macOS 上的机制和 Windows 类似，但名字更直白——系统里管这些叫“断言”（Assertions）。常用的排查工具是pmset，同样是终端命令。
最核心的一条是pmset -g assertions，运行后会列出当前系统上所有正在生效的电源断言，包括断言类型、发起进程、以及创建时间。你可能会看到类似这样的信息：
PreventUserIdleSystemSleep - 1 "Anaconda" "jupyter kernel" created by python: 25-11-19 09:41:13 +0800 "Ollama" "model loaded" created by ollama: 25-11-19 09:41:18 +0800这一行行字已经写得很明白：Jupyter 内核和 Ollama 分别注册了一条“防止用户闲置睡眠”的断言。只要有这类断言存在，你合盖后系统就不敢自动睡。
第二条常用命令是pmset -g log，用来查看系统历史上与睡眠相关的日志。因为pmset -g assertions只能看到当前状态，如果问题只在合盖后的某个时间点出现，你需要结合日志来确认断言的创建和释放时间。日常排查我会用过滤方式看重点：
pmset -g log | grep -E "Assertion|Sleep" | tail -50第三条是pmset -g custom，用来查看当前电源计划。macOS 的电源计划分为电池、接电源、还有不同内建策略，custom会列出各模式下的睡眠时间设置。有些人为了不让 mac 睡眠，设置过sleep 0（永不睡眠），或者安装了防休眠类工具，合盖后自然就一晚上不睡了。这种配置问题在这个命令下一目了然。
pmset -g live可以看当前正在生效的电源策略；顺便一提，macOS 有个用来临时阻止睡眠的命令caffeinate，它本身就是一种断言。排查时如果怀疑某个工具用了类似机制，可以用这个命令模拟和测试，但日常使用别一直开着它。
3.2 典型 AI 工具持有断言的场景和应对
macOS 上的 AI 工具持有断言，最常见集中在三类：本地模型运行时、数据科学套件、浏览器/会议类工具。
本地模型运行时是重灾区。Ollama、LM Studio、llama.cpp 这类工具，只要在“加载模型”状态，就会创建类似PreventUserIdleSystemSleep的断言，保证推理过程不被打断。很多人换了新 Mac 后喜欢常驻一个 Ollama 服务在菜单栏，平时觉得没在跑，其实模型已经加载到内存里，你合盖后它照样举着牌子。训练或小批量推理类脚本更不用提，Python 进程一跑就是一整晚。
数据科学套件里，Anaconda 自带的 Jupyter Notebook/JupyterLab 属于“隐形大户”。你只是开着一个.ipynb页面没执行任何代码，Jupyter 内核仍然可能因为 websocket 连接而持有断言。特别是装了 jupyter_contrib_nbextensions 这种插件之后，它的自动保存、自动补全功能都会默认保持网络服务活跃。
应对这些场景，我的策略分三层。第一层是退出：合盖前直接把 Ollama、LM Studio、Jupyter 服务结束掉，这种最彻底。第二层是配置：把工具里的“开机自启”“后台常驻”“自动加载模型”关掉。第三层才是系统级设置：检查pmset -g custom里的休眠时间，确实需要合盖睡觉的话，确保系统睡眠策略是正常而不是sleep 0。
还有一个 macOS 特有的细节：如果你外接了显示器和键鼠，系统会认为你处于“桌面模式”，此时合盖不会触发睡眠，除非拔掉外接设备或者手动设置合盖行为。AI 工具若恰好在外接屏场景下常驻，会放大“合盖不睡”的问题，排查时别忽略硬件拓扑的影响。
4. 从根源上优化：让 AI 工具合盖后乖乖闭嘴
4.1 Windows 的电源计划和合盖动作配置
定位到元凶之后，就该做根治了。Windows 上第一步是调整电源计划，把合盖动作明确设置为“睡眠”或“休眠”，而不是“不采取任何操作”。很多人合盖后电脑继续烧电，其实就是电源计划里这栏被改成了“不操作”。
打开控制面板 -> 电源选项 -> 选择关闭盖子的功能，里面有“用电池”和“接通电源”两个场景，分别设置合盖动作为“睡眠”。如果你设备是 S0 低功耗待机，也可以试试“休眠”——休眠会把内存镜像写到磁盘，然后彻底断电，合盖后完全不耗电。不过要注意，休眠恢复会比睡眠慢一些，且占用磁盘空间，内存多大基本就需要多大。
命令行同样可以控制，管理员权限终端下执行：
# 电池状态合盖动作为睡眠(2)，接通电源合盖动作为睡眠(2) powercfg /setdcvalueindex SCHEME_CURRENT SUB_BUTTONS LIDACTION 2 powercfg /setacvalueindex SCHEME_CURRENT SUB_BUTTONS LIDACTION 2 powercfg /setactive SCHEME_CURRENTLIDACTION 后面的数字，2 是睡眠，3 是休眠，0 是不做任何操作。想禁用一直睡眠功能的用户，可以设成 3 用休眠兜底。
4.2 禁用唤醒定时器与不必要的设备唤醒
很多 AI 工具和服务为了“准点干活”，会在系统里注册唤醒定时器。合盖后本来睡得好好的，定时器一到，系统瞬间唤醒开始执行任务，执行完又睡，睡一会儿又被唤醒——这样的循环既费电又发热。要避免这种情况，操作如下。
首先在控制面板 -> 电源选项 -> 更改计划设置 -> 更改高级电源设置里，找到“睡眠 -> 允许唤醒定时器”，设置为“禁用”。命令行对应的是：
powercfg /setacvalueindex SCHEME_CURRENT SUB_SLEEP RTCWAKE 0 powercfg /setdcvalueindex SCHEME_CURRENT SUB_SLEEP RTCWAKE 0 powercfg /setacvalueindex SCHEME_CURRENT SUB_SLEEP WAKE_TIMER 0 powercfg /setdcvalueindex SCHEME_CURRENT SUB_SLEEP WAKE_TIMER 0 powercfg /setactive SCHEME_CURRENT同时，去设备管理器挨个检查硬件：网卡、鼠标、键盘、蓝牙接收器，右键属性 -> 电源管理，把“允许此设备唤醒计算机”的勾选全部取消。尤其是无线网卡，很多 AI 客户端的实时同步依赖网络心跳，网卡只要允许唤醒，系统就可能因为网络活动被反复拉起。对笔记本这种整机断电场景，这些外设唤醒基本用不上，关掉没毛病。
还有一个容易被忽略的坑：部分 OEM 笔记本自带“智能互联”类功能，比如在 Intel/AMD 平台用于待机时保持网络连接的固件策略。这类开关通常在 BIOS 或厂商预装的电源软件里，如果你在系统层面关了所有电源请求还是掉电严重，进一次 BIOS，把类似的“网络唤醒”“Smart Connect”“现代待机增强”选项关掉。
4.3 从使用习惯上减少 AI 工具的后台空闲任务
到了这一步，纯粹的系统设置已经做到位了，接下来是使用习惯的问题。我自己的经验是：睡眠断言的“举牌”行为，很多能在源头避免。
第一，AI 推理尽量放到服务器或云端。本地跑大模型虽然新鲜，但一个加载了 7B 以上模型的工具，合盖后不让你睡是它保护任务的本能，不是 bug。你在办公时候用没问题，出门合盖前把它退掉，或者直接不在本地跑，改用远程 API。对普通用户最省心的方案，是不在主力笔记本上常驻本地大模型运行时。
第二，浏览器里的 AI 页面用完即关。浏览器为了体验，会在页面持有音视频或网络连接时阻止系统睡眠，哪怕那个页面已经在后台挂了一小时你都没看它。AI 聊天、AI 绘图这类标签页，看完就关，比什么设置都管用。
第三，常驻型 AI 工具要挑着装。市面上很多 AI 助手、AI 会议纪要、AI 实时翻译工具，一装就常驻开机启动，并且默认保持网络长连接。这类工具从产品设计上就需要后台运行，和“省电”天然冲突。我自己的态度是：按需启动，用完退出，绝不全部交给系统后台。
5. 常见问题与排查技巧速查
5.1 明明没请求却不睡，电源请求排查也没发现问题
这大概是所有排查里最让人崩溃的情况：powercfg /requests干干净净，pmset 断言也只有一个系统默认的，但合盖就是睡不过去，或者睡几分钟后又自己醒了。
根据我踩过的坑，这类问题的原因大多是这几个。一是 Modern Standby 平台兼容性问题，有些 AMD、Intel 新平台对 S0 待机的驱动要求极高，显卡、网卡、NVMe 驱动稍微落后一版，就会导致无法正确进入低功耗状态；二是厂商的“后台更新”机制，比如 Windows Update 的“在待机状态下下载更新”策略，或者杀毒软件的计划扫描，这些组件不一定注册为对外的电源请求，但会在后台调度任务；三是外设唤醒，USB 接收器、摄像头、蓝牙设备轮番触发唤醒，看起来像是“没睡多久自己醒了”。
排查方向：先用powercfg /sleepstudy生成报告，看每次睡眠会话里的“唤醒原因”。然后到事件查看器 -> Windows 日志 -> 系统下，筛选 Kernel-Power 来源，重点看事件 ID 42（正在进入睡眠）、107（正在恢复睡眠）、506（系统在睡眠状态下恢复了）。
如果确认是 Modern Standby 平台问题，最有效的兜底是：更新 BIOS 到最新版本，更新 Intel/AMD 芯片组驱动，更新显卡驱动。如果依然不行，那就接受现实，把合盖动作设为“休眠”或干脆关机。对 S0 设备来说，与其熬夜和固件搏斗，不如让系统彻底断电。
5.2 设置之后还是掉电厉害怎么办
有的人改完所有设置，合盖一晚上还是掉了十几个百分点的电。这种情况我建议去查电量消耗轨迹，而不是继续凝视电源请求。
Windows 上可以看“设置 -> 系统 -> 电源和电池 -> 电池使用情况”，里面会按应用列出耗电排序。如果有某个 AI 进程名列前茅，那你需要回到第 2.3 节，继续回到/requests和/energy去看它到底为什么还在跑。一个容易被忽视的细节是：你只是关闭了主窗口，但托盘区、服务里可能还挂着几十个关联进程，AI 工具全家桶尤其容易这样。
macOS 上可以看“电池 -> 使用记录”，同样能按 App 维度看出耗电分布。通常排查到这里，问题的答案已经不在“睡眠机制”本身，而是软件行为习惯。
如果这两步都查不出来，那我建议你做一个对照实验：合盖前把所有第三方软件，尤其 AI 相关进程全部退出，关掉网络，再合盖一晚上。如果掉电明显改善，说明问题就是某个前台软件或网络唤醒；如果掉电依然严重，那基本锁定是硬件/固件层问题，这个时候优先考虑更新 BIOS 和驱动，并检查是否有 BIOS 里的“待机时 USB 供电”“局域网唤醒”之类的开关残留。
5.3 几个平时用得上的小技巧
最后分享几个我日常排查中验证过的小工具和方法，能省不少事。
第一个是powercfg /lastwake。合盖后第二天发现电脑自己醒了，运行这个命令能告诉你“上次是什么原因唤醒了系统”。配合powercfg /waketimers，能列出所有注册的唤醒定时器和时间点。很多 AI 工具的“每日任务”就是通过这种定时器在半夜拉活，看这两个命令基本能一锤定音。
第二个是善用快捷休眠。如果你不想每次都在菜单里点半天，可以直接在桌面创建休眠快捷方式：右键新建快捷键，输入rundll32.exe powrprof.dll,SetSuspendState 0,1,0，以后双击即可秒睡。不过注意某些系统因为启用了混合睡眠，这条快捷键可能不会执行休眠而是睡眠，需要先在电源选项里关掉“允许混合睡眠”。
第三个是 macOS 上的caffeinate小命令。比如你想测试某个场景下系统是否因为断言而拒绝睡眠，可以用caffeinate -u -t 300让自己明确创建一段断言，然后对比系统行为。查问题时，这比反复瞎猜靠谱得多。
根据我自己的经验，最靠谱的组合拳永远是：合盖前关闭常驻型 AI 工具、把合盖动作设为休眠、禁用不必要的唤醒定时器。这套流程下来，笔记本合盖一晚掉电基本能控制在 3% 以内，甚至更多时候是 1% 都不到。说到底，睡眠断言的机制本来是为了让后台任务不被粗暴打断，你只要让那些真正需要后台跑的任务别在“不该跑的时候跑”，电脑自然就会乖乖睡踏实。
