一、硬件、散热与文档处理：故障判断要有传感器，输出质量也受软件默认策略影响
前段时间疑似遇到 13900K 热降解问题，近三个月设备频繁蓝屏死机，使用 CODEX 分析报告也给出相似结论，当时基本判断为热降解板上钉钉，并已联系售后处理。但随后发现水冷温度计提示水冷头温度达到 90℃，又没有明显负载，于是开始怀疑并非 13900K 问题；进入 BIOS 排查，温度仍未降低，严重怀疑水冷故障。所以近三个月使用体验过山车：从 Intel 傻逼，到 Intel 牛逼。前者是曾经的旗舰型号遇到难以理解的严重问题；后者是它扛着水冷故障高强度使用三个月，几乎没有关机。过程中还发现水冷液疑似泄漏，主板散热鳍片和 4090 显卡背板均有水渍沾染。此处运气极好，如果泄漏口再偏 1cm，就会溅射到显卡电路上，避免了超级损失。结论：水冷不可靠，散热监控必须前置。
LibreHardware Monitor 可以把系统状态参数暴露给 8085 端口，随后使用 Ubuntu 设备读取参数，做图形化配置，形成硬件监控界面；再使用 Tailscale 内网穿透，最终效果是远程了解 13900K 运行状态，并设定警报温度。目的很直接：避免散热问题无法及时发现。
Word 中图片的文件大小，不只取决于原图本身，也跟图片插入后在纸张中占据的物理面积有关。当前提是 Word 图像压缩选项保持默认设置时，如果先把页面改成横向，再贴入横向图片，图片在纸面上可占据的面积更大，Word 保存时保留的精度也更高，结果就是图片更清晰，文件也更大。这里的关键不是“横向一定更好”，而是 Word 的默认压缩策略会根据页面中的显示尺寸影响最终保存质量。
二、双系统、共享盘与同步：解耦不是两个客户端一起抢同一份数据
两块硬盘的机器可以把 Win11 和 Ubuntu 都装在第一块硬盘，第二块硬盘作为公共数据盘。真正的解耦重点不是在同一块系统盘上强行创建两个 EFI 分区，而是让两个系统各自只管理自己的系统分区，把共享数据放到第二块硬盘。现代 UEFI 架构下，Windows 和 Ubuntu 的引导文件通常分别放在同一个 EFI 分区里的 EFI/Microsoft 和 EFI/ubuntu 文件夹，文件系统层面天然隔离。过去“Windows 更新把 Linux 引导弄丢”的恐惧更多来自 Legacy BIOS 和 MBR 时代；现在更常见的是主板 NVRAM 启动顺序被改了，进 BIOS 把 ubuntu 启动项调回来即可。
UEFI 模式下重新安装 Windows 或 Ubuntu，原则只有一个：只格式化本系统自己的分区，不格式化 EFI 分区，也不碰另一个系统的分区。重装 Windows 时，安装程序通常会把 Windows Boot Manager 设为第一启动项，Ubuntu 数据和引导文件未必受损，只是 GRUB 隐形了。恢复方式可以先进 BIOS 调整启动顺序；也可以在 Windows 管理员终端中用 bcdedit /set {bootmgr} path \EFI\ubuntu\grubx64.efi 指回 GRUB；如果 NVRAM 启动项丢失，再用 Ubuntu U 盘进入试用模式，用 efibootmgr 重新注册。反过来重装 Ubuntu 时，安装器里要选手动分区，格式化原来的 Ubuntu 根分区，把现有 FAT32 EFI 分区挂为 EFI 系统分区但不要格式化；GRUB 装回含 EFI 的物理硬盘，之后通常会通过 os-prober 扫描出 Windows Boot Manager。
把 Windows 和 Ubuntu 下的坚果云本地同步路径同时指向第二块硬盘上的同一个 NTFS 文件夹，技术上能强行做，实际不值得做。同步软件本地有自己的缓存和元数据数据库，两个系统的客户端会分别记忆文件状态；Windows 改完文件后，Ubuntu 客户端再扫描同一目录，可能无法判断这是另一个系统的正常修改，还是需要从云端覆盖，结果容易产生冲突文件、重复上传和长时间重新哈希。Windows 与 Linux 对 NTFS 时间戳、权限映射、文件锁和 inotify 实时监控的处理也不同，微小时间差、ACL 污染或事件监听失效都会放大同步混乱。更稳的策略是单客户端接管：只让 Windows 坚果云管理第二硬盘同步目录，Ubuntu 里不运行坚果云，直接读写那块公共数据盘；切回 Windows 后由一个客户端扫描并上传变化，一静一动，边界清楚。
如果目标只是同时获得 Windows 坚果云客户端和 Linux 工作环境，Windows + WSL 2 比双系统来回重启更干净。同步压力交给 Windows 原生坚果云客户端，数据放在例如 D:\NutsSync 的第二硬盘目录；WSL 通过 /mnt/d/NutsSync 直接读写这份数据。Linux 侧写入后，Windows 文件监视器捕捉变化并上传；云端更新后，Windows 下载到 D 盘，WSL 直接读取。为减少权限问题，可以在 /etc/wsl.conf 中为自动挂载加入 metadata,umask=22,fmask=111，然后 wsl --shutdown 重启 WSL，并用 ln -s /mnt/d/NutsSync ~/NutsSync 建一个短路径。限制也要清楚：WSL 2 访问自身 ext4 虚拟盘很快，跨到 Windows 盘要经过虚拟化边界和 9P 文件系统转换。写论文、改代码、处理 PDF/Office 和小规模脚本没问题；大规模编译、成千上万小图片训练、高频写入数据库不适合直接放同步盘。重任务先放在 WSL 原生 ~/projects/ 跑，结束后再把结果复制到 ~/NutsSync/，让 Windows 坚果云收尾上传。
大约 2004-2006 年 Windows 98/XP 时代，双系统切换常见方案不是今天的 UEFI 启动项，而是 Legacy BIOS + MBR 下修改“活动分区”。BIOS 启动时读取硬盘 MBR，找到被标记为 Active 的主分区，再把控制权交给那个分区里的系统。所以当年有软件可以在 Windows 里选择另一个系统分区，右键切换或点击激活，重启后就进入另一个系统。典型工具是 PartitionMagic/PQMagic 附带的 PQBoot 和 BootMagic：PQBoot 的 pqboot32.exe 会列出系统分区，选中目标后把它设为活动分区，并可能把当前分区设为隐藏；BootMagic 则是同公司图形化多重启动管理器，也是靠隐藏和激活分区实现隔离。现在回忆这类方案，关键词不是“神秘双系统软件”，而是 Active Partition、Hidden Partition、MBR。
三、移动平台与 Ubuntu：新硬件上省电不是系统口号，是调度、驱动和后台唤醒
搭载 Intel Core Ultra X7 358H 这类新异构移动平台的设备，Windows 11 的续航通常会明显优于 Ubuntu。原因不只是“Windows 优化好”这句空话，而是调度器、图形驱动、电源状态和整机厂商调校共同作用。358H 是 P 核、E 核、LP-E 核共存的平台，Windows 11 与 Intel Thread Director 配合更深，轻负载时更容易把任务压到低功耗核心，让主干核心进入深度休眠。Ubuntu 虽然持续改进大小核调度，但面对这种三级异构结构时，任务下放和突发负载控制往往没那么激进。Arc B390 核显在 Windows 下的视频硬解、界面渲染和空闲电源状态也更容易吃到厂商级调优；Ubuntu 在多显示器、高刷新率、浏览器硬解和 S0ix 现代待机场景中，更容易因为驱动或 PCIe 设备阻塞而进不了最深省电状态。止损办法不是幻想默认设置自动完美，而是主动换用 TLP 或 auto-cpufreq，电池模式限制睿频和 governor；拔电时暂停 Docker、Ollama、WebDAV 同步等高频唤醒服务，尽量让 CPU 进入 C8/C10 之类深度 C-states。
四、AI Agent 工程：术语会膨胀，能落地的是记忆、观测和验证
Claude 和这帮 AI 圈子的人太 TM 能造词了。Loop 才多久，又来了一个 Tag。RAG、Prompt、MCP、Agent、Context Washing、Harness、Loop、Verify Gate、Tag，一个词接一个词冒出来。真正有用的处理方式不是追着新词跑，而是把它们还原成工程环节：检索、提示、工具协议、智能体、上下文清洗、运行框架、循环执行、验证门和标签管理。术语可以变，问题没变：输入怎么来，状态怎么存，工具怎么调，结果怎么验，失败怎么复现。
Karpathy 真的是活雷锋。Loop 需要的 Agent 记忆管理和监控器，开源生态里已经有可以直接对照的组件。Zep Graphiti 是 Temporal Knowledge Graph，用于从对话、文档或结构化数据中抽取实体和关系，处理事实随时间变化的问题，并支持向量、全文和图遍历的混合检索，适合作为 Agent 长期记忆和状态管理层。Comet Opik 是 LLM observability 与 evaluation 平台，用来追踪、评估和监控 Agent/LLM 应用，能记录每一步调用，把失败 trace 转成回归测试，也支持 LLM-as-Judge。Loop 不是“让模型自己循环”这么简单，至少要有记忆层、观测层、评估层和失败回放机制，否则循环越多，越只是把不可控放大。
