电脑远程关机
概述
把「关掉这台电脑」变成一个可被远程触发的确定性动作。默认延时执行、可随时取消，因此适合通过手机远程下达——手滑或改主意都还来得及。
这个 Skill 是「手机远程关机」方案的执行端：手机 App 通过 WorkBuddy 多端协同把指令送到桌面端，桌面端 Agent 调用本 Skill 落地。手机端不需要安装任何东西。
适用范围（重要）
本技能只支持 WorkBuddy，其他软件暂不支持。
| 说明 | |
|---|---|
| ✅ 支持 | WorkBuddy 桌面端（Windows 10 / 11）+ WorkBuddy 手机端 App（iOS / Android / 鸿蒙）。既可在手机 App「连接电脑」后远程下达，也可直接在桌面端本地下达。 |
| ❌ 不支持 | 与其他 AI 助手 / 办公软件之间的跨端操作（如豆包工作、千问办公、ChatGPT Work 等）。这些产品各有独立的技能体系与跨端通道，与本技能互不兼容——无法安装生效、无法运行、也无法借用其通道。 |
| ❌ 不支持 | macOS / Linux（执行器依赖 Windows 自带命令）。 |
原因：本技能由 WorkBuddy 桌面端 Agent 触发，指令经 WorkBuddy 官方多端协同通道送达；换成其他客户端，触发端与通道都不存在。要在其他产品上实现同样效果，需按其各自的技能规范另行开发，与本技能无关。
三条硬规则
- 默认延时 60 秒，不要用 0。 只有用户明确说了"立刻 / 马上 / 现在就关"才缩短，且不低于 15 秒。延时是唯一的反悔窗口，也是取消机制生效的前提。
- 先下达关机，再回复用户；回复要立刻发出去。 延时结束后电脑断电，来不及再解释。排完关机不要接着做别的耗时工作。
- 调用脚本走 PowerShell 绝对路径，不要依赖 Bash。 Windows 上的 Bash 环境可能缺少 coreutils（
dirname、head、grep），中文路径还可能出编码问题。
意图映射
| 用户说法 | Action | Delay |
|---|---|---|
| 关机、关闭电脑、关电脑、帮我关一下 | shutdown |
60 |
| 立刻关机、马上关、现在就关 | shutdown |
15 |
| N 分钟后关机 | shutdown |
N × 60 |
| 重启、重新启动、重启一下 | restart |
60 |
| 休眠、保存状态后断电 | hibernate |
— |
| 睡眠、待机 | sleep |
— |
| 锁屏、锁一下屏幕 | lock |
— |
| 取消关机、别关了、算了、等一下 | cancel |
— |
| 还有多久关、关机了吗、现在什么状态 | status |
— |
不要把非电源意图当成关机。 "关掉这个网页""关闭这个文件""关掉微信""把窗口关掉"都是在说别的东西——这类请求不要触发本 Skill。判断依据是：用户说要关闭的对象是不是这台电脑本身。
执行方式
powershell -NoProfile -ExecutionPolicy Bypass -File "$env:USERPROFILE\.workbuddy\skills\pc-remote-shutdown\scripts\power.ps1" -Action shutdown -Delay 60
参数说明：-Action 见上表；-Delay 延时秒数（默认 60）；-Comment 关机原因文字（会显示在 Windows 的关机提示里）；-DryRun 演习模式，只打印命令不执行。
退出码：0 成功；1 执行失败；2 没有排队的关机（仅 cancel 会返回）。
脚本自动处理了几件容易出错的事：下达新关机前会先中止旧的排队项（避免叠加）；取消成功或本来就是空的时候会清掉状态文件；状态文件放在 %LOCALAPPDATA%\pc-remote-shutdown\pending.json，并且会自动判断是否已过期。
-Action status 只能看到由本 Skill 下达的关机。别的程序发起的关机它查不到——不要把它当成 Windows 的全局关机状态查询。
回复模板
远程场景下手机上只有一屏，回复要短、要让人一眼知道下一步能做什么。
- 下达成功：
已收到，电脑将在 60 秒后关机 ⏳ 想反悔现在就回我一句"取消关机"。 - 取消成功：
已取消，电脑继续开着 👍 - 取消失败（本来就是空的）：
现在没有排队的关机，电脑本来就没打算关。 - 查询：
当前没有排队的关机。/有一条排队中的关机，约剩 42 秒。
下达成功后顺带提一句：如果同一轮对话里还有别的任务在跑（正在生成报告、正在下载等），先提醒用户"注意到还有任务在运行，确定要关吗"，等用户确认或等任务结束再关。
安全边界
- 电脑睡眠或关机时，手机连不上，也就关不了机。 这是原理决定的，不是配置问题。不要承诺"能远程把电脑开机"——远程开机是 Wake-on-LAN，另一件事。
- 不需要二次确认。 用户人不在电脑前，来回确认反而误事；60 秒延时已经承担了兜底职责。但如果用户说的是"立刻关机"，回复里要明确点出"没有反悔时间了"。
- 不要主动发起关机。 只有在用户明确表达关机意图时才执行；不要因为"任务做完了"就自行关机。
- 已保存的工作不受影响；未保存的文档会丢失。这是 Windows 关机的正常行为，下达前不需要额外检查，但用户如果问起要如实说明。
常见问题
先查本机到底支持哪些电源状态
执行 powercfg /a。输出里会明确列出哪些状态不可用。常见情况：虚拟机和部分品牌机固件不支持 S1/S2/S3 待机，也就是"睡眠"在这台机器上根本用不了；休眠则通常是"尚未启用"，执行 powercfg /hibernate on 即可开启。在下达 sleep / hibernate 之前先看一眼，比失败之后再解释要省事。
手机发了指令，电脑没反应
按顺序排查：① 桌面端侧边栏底部「连接移动端」面板里，「允许移动端连接此设备」是否打开；②「保持唤醒状态，以便远程访问」是否打开（或 系统设置 → 通用 → 允许锁屏运行）；③ App 与桌面端是否同一账号登录；④ 电脑是否处于睡眠状态（睡眠时连不上，需在电源计划里把"睡眠"设为"从不"）。
返回码 1116
表示当前没有排队的关机。这不是错误，回复用户"本来就没有要关的"即可。
演习模式（-DryRun）曾经会误删状态文件 —— 已于 v1.0.0 修复
旧版在 shutdown / restart 分支里，只要检测到已排队任务就执行 Clear-PendingState，而这一步没有受 -DryRun 保护。于是号称"零副作用"的演习会删掉真实的 pending.json，导致随后 -Action status 误报"没有排队的关机"，-Action cancel 也失去可视化依据（shutdown /a 本身仍能取消）。
修复：三处会改动状态的位置——shutdown 分支、restart 分支、Get-PendingState 内的过期清理——全部加 if (-not $isDrill) 保护。
改完这个脚本后，除 BOM 外还要复核一件事：-DryRun 必须全程零副作用（种一个未来时间的 pending.json，跑一次 -DryRun，确认文件仍在）。
脚本报出一大堆语法错误
文件编码丢失了 UTF-8 BOM。Windows PowerShell 5.1 在没有 BOM 时按系统 ANSI 码页读取 .ps1，中文会被解码成乱码，进而引发几十个「语法错误」。修复：把文件重新保存为带 BOM 的 UTF-8（前 3 字节为 EF BB BF）。用编辑器改过这个脚本之后，务必复查一次 BOM。
调用之后，WorkBuddy 的会话整个中断了
脚本里被设成了 $ErrorActionPreference = 'Stop'。shutdown.exe 失败时会把说明写进 stderr，而 2>&1 合并进来的 stderr 在 Stop 语义下会被当作终止性错误向上抛出，连调用方一起打断。这个脚本必须保持 Continue，且 Invoke-Native 内部会再次隔离，不要改动这个设计。
下达成功、电脑却没关（最常见的"假故障"，2026-09-22 实测踩坑）
先查事件日志，一眼分清两种情况：
Get-WinEvent -LogName System -MaxEvents 3000 |
Where-Object { $_.Id -in @(1074,1075) } | Sort-Object TimeCreated
- 只有 1074（「启动了计算机…的关机」）、后面既无 1075 也无 6006 → 关机正常执行或仍在倒计时
- 1074 之后紧跟着 1075（「终止了计算机…上的上一个重新启动/关机请求」）→ 有东西执行了
shutdown /a，把关机取消了
⚠️ 排查时绝对不要用 shutdown /a 去「查」有没有排队关机。 /a 是 abort（取消），不是查询——敲下去就真的取消掉排队中的关机，还会留下一条 1075。
实测就是这样踩的坑：下达成功（事件 1074，注释 Remote power command from WorkBuddy），5 秒后因为把 (shutdown /a) 当成「状态探测」跑了一句，关机被自己取消（事件 1075），用户等到的执行时刻自然什么都没发生。同一时间窗内 1074 与 1075 成对出现，就是自伤的铁证。
要查状态只有两条路：-Action status（读本技能状态文件），或读事件日志 1074/1075；两者都不要碰 /a。
另注意 -Action status 读的是 pending.json（本技能自己的记录），它无法感知外部取消——所以「status 说有排队」不等于「Windows 一定有关机」。若状态文件明显过期（executeAt 早于当前时间），说明那次关机要么已执行、要么中途被取消，应以上面的 1074/1075 为准。
关机没有生效
检查是否有组策略或安全软件限制关机权限，以及是否有程序阻止关机（Windows 会弹出"以下程序正在阻止关机"）。
已验证的实测结果
在 Windows 10 上完整跑通过一遍：六个动作的 -DryRun 演习、状态文件的写入/读取/过期自动清理、以及真实闭环——下达 900 秒延时关机（exit 0）→ 查询到排队中 → 取消（exit 0）→ 复查为空 → 再次取消返回 1116（exit 2）。
v1.0.0 发布前复查：真实关机闭环再次走通（shutdown /s /t 60 → Windows 事件日志 1074 记录发起者为 shutdown.exe 且带注释文字 → 系统按标准序列关机：1074 → 7002 注销通知 → 6006 事件日志停止）。同时定位并修复上述 -DryRun 误删状态文件的缺陷，修复后用"种 pending.json → 跑 -DryRun → 复检仍存在"完成回归验证。
v1.0.1 追加：复盘一次"下达成功却没关机"的误判（事件 1074 之后 5 秒紧跟 1075，即被 shutdown /a 取消），把 1074/1075 判读法与「禁止用 /a 探测」写进排障章节；并把执行器默认注释与实测事件日志对齐。本版为文档与注释修订，执行逻辑与 v1.0.0 完全一致。
权限与依赖
- 系统权限：需当前用户具备关机权限（默认用户均有）。
- 外部依赖：仅调用 Windows 自带程序——
shutdown.exe、rundll32.exe、System.Windows.Forms.SetSuspendState。不联网、不下载、不安装任何第三方组件。 - 平台：仅 Windows。PowerShell 5.1（Windows 10/11 自带）即可运行，无需额外安装。
- 客户端：仅 WorkBuddy（桌面端 + 手机端 App）。其他 AI 助手 / 办公软件不在支持范围内——即便能加载本技能文件，也未经验证、不提供支持。
- 写入位置：仅写
%LOCALAPPDATA%\pc-remote-shutdown\pending.json这一个状态文件，用于支持status/cancel。
Resources
scripts/power.ps1— 确定性执行器，封装关机/重启/休眠/睡眠/锁屏/取消/查询references/mobile-setup.md— WorkBuddy 多端协同的完整配置步骤、前置条件与排障CHANGELOG.md— 版本变更记录LICENSE.md— MIT 许可证
