LifeOS Vitals 技能 DeepDiagnosis 工作流macOS 全子系统深度系统诊断实战指南【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS当常规快速检查HealthCheck已经无法解释这台 Mac 为什么越来越慢时就需要进入更深一层的系统性排查。本文聚焦 LifeOS 仓库中 Vitals 技能的 DeepDiagnosis 工作流讲解如何在 CPU、内存、GPU、热管理、磁盘、启动加载等全部子系统上做一次全量扫描并借助 Interpretation.md 的判定阈值把原始数据翻译成按严重程度排序的结论清单和逐项审批的修复方案。读完本文你将掌握 DeepDiagnosis 的完整执行路径、底层只读探测工具 Vitals.ts 的每个子命令原理以及需要 sudo 的可选功耗测量环节的正确用法。DeepDiagnosis 的定位什么时候该做深度诊断Vitals 技能见 SKILL.md将 macOS 性能诊断拆成三个递进的工作流工作流触发场景覆盖范围HealthCheckhows my system、check my mac、system health一屏速览1 秒出结果FindCulpritmac is slow、whats eating CPU/GPU/memory、fans loud实时定位单一元凶进程DeepDiagnosisfull diagnosis、deep check、慢性/反复性变慢全部子系统全量扫描DeepDiagnosis 专门面向快速检查不够用的场景慢性卡顿chronic slowness、反复出现的风扇噪音recurring fan noise、随时间推移逐渐劣化的使用体感degraded-over-time feel。与 FindCulprit 抓此刻谁在偷跑不同DeepDiagnosis 回答的是整个系统长期处于什么状态、哪些子系统在拖后腿、启动加载中有没有一直在失败的 Agent。执行前的语音播报通知与 Vitals 技能的其他工作流一致DeepDiagnosis 启动时先向本地通知服务默认监听localhost:31337发送一条语音播报同时输出文本提示curl -s -X POST http://localhost:31337/notify \ -H Content-Type: application/json \ -d {message: Running the DeepDiagnosis workflow in the Vitals skill for a full system diagnosis} \ /dev/null 21 Running **DeepDiagnosis** in **Vitals**...该命令异步发送后台执行不阻塞诊断流程本身 /dev/null 21保证通知失败也不会污染终端输出。理想终态一份完整、可判定、可审批的诊断报告DeepDiagnosis 的理想状态定义了诊断产出物应有的样子这也是后续每一步操作的对齐标准全子系统覆盖CPU、内存、GPU、热管理thermal、磁盘、启动加载startup load一个都不能少逐项对照阈值每项读数都必须对照 Interpretation.md 中的阈值给出健康/待查判定而不是丢出一堆原始数字排序后的发现清单按严重程度从重到轻排列worst first每一条发现都要附带证据逐项审批的修复方案产出修复计划后由操作者operator逐项确认后才执行技能本身绝不擅自改动系统启动项发现要区分失败与众多只有非零退出码的失败 Agent 才算发现findingAgent 数量多本身不构成问题。这一先证据、后结论、再审批的形态是 Vitals 技能只读、只建议、不执行契约见 SKILL.md 中 read-only by contract的延续。核心工具与命令full 全量扫描 startup 启动项审计DeepDiagnosis 的两条主命令均来自 Vitals.ts以bun直接执行无需 sudo无 root 依赖bun ~/.claude/skills/Vitals/Tools/Vitals.ts full --top 15 # everything, no sudo (~4s) bun ~/.claude/skills/Vitals/Tools/Vitals.ts startup # launchd agent auditfull 子命令四秒内完成全部子系统采样从源码 Vitals.ts 的full分支可以看到它依次串联执行四个采集段case full: sectionCheck(); P(); sectionHogs(); P(); sectionGpu(); P(); sectionStartup(); break;即check快照→hogs实时进程→gpuGPU 利用率→startup启动项审计四段全量输出。各段对应的底层采集器与原理如下① check 段 —— 系统快照1s负载读取sysctl vm.loadavg得到 1/5/15 分钟负载并除以hw.ncpu计算每核负载load_per_core_1m见 Vitals.ts这是解读负载的唯一正确口径内存vm_stat分页统计 kern.memorystatus_vm_pressure_level压力等级1 正常 / 2 警告 / 4 严重vm.swapusage交换用量与 swapins/swapouts 计数见 Vitals.ts热管理pmset -g therm解析CPU_Speed_Limit100 表示未降频与Scheduler_Limit再以pmset -g batt识别电源来源见 Vitals.ts磁盘df -h / /System/Volumes/Data统计容量mdutil -s /探测 Spotlight 索引状态见 Vitals.ts进程快照ps -Areo pid,pcpu,pmem,rss,comm分别按 CPU 和 RSS 排序输出 Top 列表见 Vitals.ts。源码注释明确指出ps -m在现代 macOS 上的内存排序不可靠因此排序在代码内完成。② hogs 段 —— 实时进程探针~3s调用top -l 2 -n ... -o cpu -stats pid,cpu,power,mem,command只解析第二个样本见 Vitals.ts。原因在 SKILL.md 的 Gotchas 中有明确警告top的第一个样本是自启动以来的累计值必须用第二样本才能得到实时 CPU 占比输出实时 CPU Top 与实时能量 Top 两份列表能量按 top 的power分数相对值在代码内重排。③ gpu 段 —— GPU 利用率无需 sudo通过ioreg -r -d 1 -w 0 -c IOAccelerator读取Device Utilization %与Renderer Utilization %见 Vitals.ts在 Apple Silicon 上无 sudo 即可读取若系统不暴露这些计数器工具会显式输出available: false的降级提示给出改用sudo powermetrics ... --samplers gpu_power的建议绝不静默留空。④ startup 段 —— launchd 用户 Agent 审计解析launchctl list输出统计用户 Agent 总数、正在运行数并筛出非零 last exit 的失败 Agent-状态列且退出码非 0见 Vitals.ts这正是 DeepDiagnosis 中区分失败 Agent 与众多 Agent这一判定标准的实现依据failed_last_exit数组只收录真正失败的项数量多不作为 finding。--top 与 --json 参数--top 15控制各进程列表的长度默认 10见 Vitals.ts。若需要结构化输出供脚本或后续自动化消费可追加--json此时工具只输出JSON.stringify(out, null, 2)的完整采集结果不打印人类可读段落。判定阈值把读数翻译成诊断DeepDiagnosis 报告中的每一项判定都依据 Interpretation.md 的阈值表信号健康需调查原因每核负载1m 0.7持续 1.0绝对负载离开核心数毫无意义内存压力等级normalwarning / criticalmacOS 真正的内存信号是压力等级已用百分比无意义空闲内存会被刻意用于缓存Swap 用量 swapouts接近 0、缓慢增长使用中持续增长swapouts 实时攀升 真实内存短缺CPU_Speed_Limit100或未报告 100机器被物理降速降频期间的性能抱怨属于热问题而非软件问题GPU 设备利用率空闲桌面 60%无 GPU 应用运行时 90%指向 WindowServer 压力或失控的 GPU 消费者磁盘容量 85% 90%APFS 在接近满盘时变慢且不稳定同时Interpretation.md 还维护了一张已知进程表避免误伤系统守护进程kernel_task高占用通常是热管理在钉核降温而非失控进程绝不可 killWindowServer高占用指向多窗口/多空间/录屏/高刷外接屏mds_stores/mdworker是 Spotlight 索引可先用mdutil -s /确认通常自行结束。这些别追鬼的条目正是 DeepDiagnosis 把看起来吓人的正常读数从发现清单中剔除的依据。可选 sudo 环节功耗与热细节需操作者明确同意DeepDiagnosis 中唯一需要提权的是功耗细节采集且必须事先征得操作者同意被拒绝则干净地跳过——这是可选项不是必须项sudo powermetrics -n 1 -i 2000 --samplers tasks,cpu_power,gpu_power,thermal sudo sfltool dumpbtm # login items background task management inventorypowermetrics是每进程能耗影响、CPU 频率/驻留状态、精确 GPU 功耗与热压力细节的唯一来源。DeepDiagnosis 工作流明确要求Ask before using; skip cleanly if declinedsfltool dumpbtm补充launchctl list覆盖不到的登录项与后台任务管理清单Vitals.ts 的 startup 段输出中也会提示这一补充手段结合 Vitals.ts 可看到GPU 无 sudo 读取失败时的官方建议正是回退到sudo powermetrics -n 1 -i 1000 --samplers gpu_power。Gotchas执行 DeepDiagnosis 必须避开的四个坑工作流本身与 SKILL.md 的 Gotchas 共同总结了以下关键注意事项powermetrics不带-n会永远运行必须传-n 1或-n 2取一次沉降样本。这是脚本挂死的常见原因Apple Silicon 上cpu_power按簇报告E 核能效核钉满而 P 核性能核空闲通常意味着后台 QoS 任务在跑而非用户可见负载——解读功耗数据时务必区分簇归属top首个样本是垃圾数据自启动累计值永远使用第二样本源码中-l 2的第二样本解析逻辑不可优化掉不要对正常但吓人的读数报警高已用内存、kernel_task高 CPU、大量 Agent 数量在 DeepDiagnosis 中都要按 Interpretation.md 的规则显式去旗标de-flag而不是当成问题上报。证据要求一个结论需要两类证据DeepDiagnosis 继承了 Vitals 技能的双重证据诊断规范Interpretation.md § Diagnosis shape一条元凶结论必须同时具备进程自身数据来自hogs的实时 CPU%/power/RSS和佐证系统信号降频状态、压力等级、GPU%、swapouts。单张ps快照只会过度放大某一瞬间的尖峰hogs的第二样本才是确认探针。相应地修复建议kill pid、launchctl bootout、Spotlight 排除目录、应用设置调整始终是推荐给操作者、由操作者审批执行技能本身从不擅自改动系统状态——这也是整个 SKILL.md 所声明的只读契约。与同技能其他工作流的衔接DeepDiagnosis 不是孤立流程而是 Vitals 技能诊断体系的最深层若 HealthCheck 的一屏速览check子命令1s无 sudo发现异常会建议升级到 FindCulprit 而非硬凑报告FindCulprithogscheckgpu解决此刻谁在偷跑**DeepDiagnosisfullstartup 可选 sudo 功耗段**解决系统长期为什么慢产出全子系统画像、排序后的证据化发现清单与逐项审批的修复计划。三者共享同一套 Vitals.ts 只读工具和 Interpretation.md 判定标准构成从快查到深诊的完整梯度。在 LifeOS 的语境下这套工作流的意义正在于把 macOS 系统状态从不可见的黑盒变成读数—阈值—证据—审批的结构化诊断链路让 AI Agent 既能看懂机器又始终把修改系统的决定权交还给操作者。【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LifeOS Vitals 技能 DeepDiagnosis 工作流：macOS 全子系统深度系统诊断实战指南
LifeOS Vitals 技能 DeepDiagnosis 工作流macOS 全子系统深度系统诊断实战指南【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS当常规快速检查HealthCheck已经无法解释这台 Mac 为什么越来越慢时就需要进入更深一层的系统性排查。本文聚焦 LifeOS 仓库中 Vitals 技能的 DeepDiagnosis 工作流讲解如何在 CPU、内存、GPU、热管理、磁盘、启动加载等全部子系统上做一次全量扫描并借助 Interpretation.md 的判定阈值把原始数据翻译成按严重程度排序的结论清单和逐项审批的修复方案。读完本文你将掌握 DeepDiagnosis 的完整执行路径、底层只读探测工具 Vitals.ts 的每个子命令原理以及需要 sudo 的可选功耗测量环节的正确用法。DeepDiagnosis 的定位什么时候该做深度诊断Vitals 技能见 SKILL.md将 macOS 性能诊断拆成三个递进的工作流工作流触发场景覆盖范围HealthCheckhows my system、check my mac、system health一屏速览1 秒出结果FindCulpritmac is slow、whats eating CPU/GPU/memory、fans loud实时定位单一元凶进程DeepDiagnosisfull diagnosis、deep check、慢性/反复性变慢全部子系统全量扫描DeepDiagnosis 专门面向快速检查不够用的场景慢性卡顿chronic slowness、反复出现的风扇噪音recurring fan noise、随时间推移逐渐劣化的使用体感degraded-over-time feel。与 FindCulprit 抓此刻谁在偷跑不同DeepDiagnosis 回答的是整个系统长期处于什么状态、哪些子系统在拖后腿、启动加载中有没有一直在失败的 Agent。执行前的语音播报通知与 Vitals 技能的其他工作流一致DeepDiagnosis 启动时先向本地通知服务默认监听localhost:31337发送一条语音播报同时输出文本提示curl -s -X POST http://localhost:31337/notify \ -H Content-Type: application/json \ -d {message: Running the DeepDiagnosis workflow in the Vitals skill for a full system diagnosis} \ /dev/null 21 Running **DeepDiagnosis** in **Vitals**...该命令异步发送后台执行不阻塞诊断流程本身 /dev/null 21保证通知失败也不会污染终端输出。理想终态一份完整、可判定、可审批的诊断报告DeepDiagnosis 的理想状态定义了诊断产出物应有的样子这也是后续每一步操作的对齐标准全子系统覆盖CPU、内存、GPU、热管理thermal、磁盘、启动加载startup load一个都不能少逐项对照阈值每项读数都必须对照 Interpretation.md 中的阈值给出健康/待查判定而不是丢出一堆原始数字排序后的发现清单按严重程度从重到轻排列worst first每一条发现都要附带证据逐项审批的修复方案产出修复计划后由操作者operator逐项确认后才执行技能本身绝不擅自改动系统启动项发现要区分失败与众多只有非零退出码的失败 Agent 才算发现findingAgent 数量多本身不构成问题。这一先证据、后结论、再审批的形态是 Vitals 技能只读、只建议、不执行契约见 SKILL.md 中 read-only by contract的延续。核心工具与命令full 全量扫描 startup 启动项审计DeepDiagnosis 的两条主命令均来自 Vitals.ts以bun直接执行无需 sudo无 root 依赖bun ~/.claude/skills/Vitals/Tools/Vitals.ts full --top 15 # everything, no sudo (~4s) bun ~/.claude/skills/Vitals/Tools/Vitals.ts startup # launchd agent auditfull 子命令四秒内完成全部子系统采样从源码 Vitals.ts 的full分支可以看到它依次串联执行四个采集段case full: sectionCheck(); P(); sectionHogs(); P(); sectionGpu(); P(); sectionStartup(); break;即check快照→hogs实时进程→gpuGPU 利用率→startup启动项审计四段全量输出。各段对应的底层采集器与原理如下① check 段 —— 系统快照1s负载读取sysctl vm.loadavg得到 1/5/15 分钟负载并除以hw.ncpu计算每核负载load_per_core_1m见 Vitals.ts这是解读负载的唯一正确口径内存vm_stat分页统计 kern.memorystatus_vm_pressure_level压力等级1 正常 / 2 警告 / 4 严重vm.swapusage交换用量与 swapins/swapouts 计数见 Vitals.ts热管理pmset -g therm解析CPU_Speed_Limit100 表示未降频与Scheduler_Limit再以pmset -g batt识别电源来源见 Vitals.ts磁盘df -h / /System/Volumes/Data统计容量mdutil -s /探测 Spotlight 索引状态见 Vitals.ts进程快照ps -Areo pid,pcpu,pmem,rss,comm分别按 CPU 和 RSS 排序输出 Top 列表见 Vitals.ts。源码注释明确指出ps -m在现代 macOS 上的内存排序不可靠因此排序在代码内完成。② hogs 段 —— 实时进程探针~3s调用top -l 2 -n ... -o cpu -stats pid,cpu,power,mem,command只解析第二个样本见 Vitals.ts。原因在 SKILL.md 的 Gotchas 中有明确警告top的第一个样本是自启动以来的累计值必须用第二样本才能得到实时 CPU 占比输出实时 CPU Top 与实时能量 Top 两份列表能量按 top 的power分数相对值在代码内重排。③ gpu 段 —— GPU 利用率无需 sudo通过ioreg -r -d 1 -w 0 -c IOAccelerator读取Device Utilization %与Renderer Utilization %见 Vitals.ts在 Apple Silicon 上无 sudo 即可读取若系统不暴露这些计数器工具会显式输出available: false的降级提示给出改用sudo powermetrics ... --samplers gpu_power的建议绝不静默留空。④ startup 段 —— launchd 用户 Agent 审计解析launchctl list输出统计用户 Agent 总数、正在运行数并筛出非零 last exit 的失败 Agent-状态列且退出码非 0见 Vitals.ts这正是 DeepDiagnosis 中区分失败 Agent 与众多 Agent这一判定标准的实现依据failed_last_exit数组只收录真正失败的项数量多不作为 finding。--top 与 --json 参数--top 15控制各进程列表的长度默认 10见 Vitals.ts。若需要结构化输出供脚本或后续自动化消费可追加--json此时工具只输出JSON.stringify(out, null, 2)的完整采集结果不打印人类可读段落。判定阈值把读数翻译成诊断DeepDiagnosis 报告中的每一项判定都依据 Interpretation.md 的阈值表信号健康需调查原因每核负载1m 0.7持续 1.0绝对负载离开核心数毫无意义内存压力等级normalwarning / criticalmacOS 真正的内存信号是压力等级已用百分比无意义空闲内存会被刻意用于缓存Swap 用量 swapouts接近 0、缓慢增长使用中持续增长swapouts 实时攀升 真实内存短缺CPU_Speed_Limit100或未报告 100机器被物理降速降频期间的性能抱怨属于热问题而非软件问题GPU 设备利用率空闲桌面 60%无 GPU 应用运行时 90%指向 WindowServer 压力或失控的 GPU 消费者磁盘容量 85% 90%APFS 在接近满盘时变慢且不稳定同时Interpretation.md 还维护了一张已知进程表避免误伤系统守护进程kernel_task高占用通常是热管理在钉核降温而非失控进程绝不可 killWindowServer高占用指向多窗口/多空间/录屏/高刷外接屏mds_stores/mdworker是 Spotlight 索引可先用mdutil -s /确认通常自行结束。这些别追鬼的条目正是 DeepDiagnosis 把看起来吓人的正常读数从发现清单中剔除的依据。可选 sudo 环节功耗与热细节需操作者明确同意DeepDiagnosis 中唯一需要提权的是功耗细节采集且必须事先征得操作者同意被拒绝则干净地跳过——这是可选项不是必须项sudo powermetrics -n 1 -i 2000 --samplers tasks,cpu_power,gpu_power,thermal sudo sfltool dumpbtm # login items background task management inventorypowermetrics是每进程能耗影响、CPU 频率/驻留状态、精确 GPU 功耗与热压力细节的唯一来源。DeepDiagnosis 工作流明确要求Ask before using; skip cleanly if declinedsfltool dumpbtm补充launchctl list覆盖不到的登录项与后台任务管理清单Vitals.ts 的 startup 段输出中也会提示这一补充手段结合 Vitals.ts 可看到GPU 无 sudo 读取失败时的官方建议正是回退到sudo powermetrics -n 1 -i 1000 --samplers gpu_power。Gotchas执行 DeepDiagnosis 必须避开的四个坑工作流本身与 SKILL.md 的 Gotchas 共同总结了以下关键注意事项powermetrics不带-n会永远运行必须传-n 1或-n 2取一次沉降样本。这是脚本挂死的常见原因Apple Silicon 上cpu_power按簇报告E 核能效核钉满而 P 核性能核空闲通常意味着后台 QoS 任务在跑而非用户可见负载——解读功耗数据时务必区分簇归属top首个样本是垃圾数据自启动累计值永远使用第二样本源码中-l 2的第二样本解析逻辑不可优化掉不要对正常但吓人的读数报警高已用内存、kernel_task高 CPU、大量 Agent 数量在 DeepDiagnosis 中都要按 Interpretation.md 的规则显式去旗标de-flag而不是当成问题上报。证据要求一个结论需要两类证据DeepDiagnosis 继承了 Vitals 技能的双重证据诊断规范Interpretation.md § Diagnosis shape一条元凶结论必须同时具备进程自身数据来自hogs的实时 CPU%/power/RSS和佐证系统信号降频状态、压力等级、GPU%、swapouts。单张ps快照只会过度放大某一瞬间的尖峰hogs的第二样本才是确认探针。相应地修复建议kill pid、launchctl bootout、Spotlight 排除目录、应用设置调整始终是推荐给操作者、由操作者审批执行技能本身从不擅自改动系统状态——这也是整个 SKILL.md 所声明的只读契约。与同技能其他工作流的衔接DeepDiagnosis 不是孤立流程而是 Vitals 技能诊断体系的最深层若 HealthCheck 的一屏速览check子命令1s无 sudo发现异常会建议升级到 FindCulprit 而非硬凑报告FindCulprithogscheckgpu解决此刻谁在偷跑**DeepDiagnosisfullstartup 可选 sudo 功耗段**解决系统长期为什么慢产出全子系统画像、排序后的证据化发现清单与逐项审批的修复计划。三者共享同一套 Vitals.ts 只读工具和 Interpretation.md 判定标准构成从快查到深诊的完整梯度。在 LifeOS 的语境下这套工作流的意义正在于把 macOS 系统状态从不可见的黑盒变成读数—阈值—证据—审批的结构化诊断链路让 AI Agent 既能看懂机器又始终把修改系统的决定权交还给操作者。【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考