Windows 小工具最先要设计的不是功能，而是边界

我做 Windows 小工具时，需求常常很小：降低某个进程的资源影响，或根据键盘状态显示一个训练提示。真正让我花时间的部分却不是窗口和按钮，而是系统权限、平台规则、误报、更新链路和用户预期。

我做的 ACEOptimizer 与 Emergency-Stop 解决的问题不同，但最后都收敛到同一种设计方法：先写清楚工具绝对不会做什么，再决定功能如何实现。

两个项目的时间线

我始终把 ACEOptimizer 的行为限定在 Windows 公开的进程优先级与 CPU 亲和性设置，不修改游戏文件、反作弊文件、驱动或系统服务。

我让 Emergency-Stop 只读取本机键盘输入并绘制透明置顶窗口，不读取游戏进程、不注入图形 API、不抓包、不模拟按键，也不执行宏。我把急停状态明确标成可调整的时间估算，不声称复刻未公开的游戏物理。

Windows 的进程对象有细分访问权。Microsoft 的进程安全文档明确建议只申请操作需要的最小权限，而不是默认请求 PROCESS_ALL_ACCESS。

这对小工具有直接意义：

更少的权限意味着更小的错误面、更少的安全软件疑虑，也更容易向用户解释工具行为。

SetPriorityClass 官方文档提醒，高优先级可能占用几乎全部 CPU，而单纯调整 CPU 调度优先级也不能解决磁盘和内存造成的系统响应问题。

因此，ACEOptimizer 的实现只能被描述为“改变特定进程的调度条件”，不能承诺所有机器都降低总体占用、提升帧率或完全没有副作用。CPU 拓扑、目标进程行为、系统版本和平台更新都会改变结果。

一个可信的系统工具应该把兼容性写成条件句，而不是营销结论。

Emergency-Stop 使用 Windows Raw Input 与按键状态轮询来提高键盘状态读取稳定性。Raw Input 是 Windows 为 HID 设备提供的公开输入路径，应用注册后通过窗口消息接收设备数据。

但“能够读取键盘”不等于“应该记录键盘”。训练覆盖层只需要当前移动键状态，不需要保存输入历史、上传数据或监听与功能无关的按键。数据最小化同样适用于本地工具。

对于与游戏、系统权限或覆盖层有关的软件，用户往往先问“它会不会做危险的事”。README 中的非目标清单比功能列表更能建立信任：

非目标不是法律护身符，也不能代替平台确认。它的工程作用是防止后续功能在“顺便实现”中越过最初边界。

桌面工具一旦提供自动更新，就获得了修改用户机器上可执行文件的能力。此时“从 GitHub 下载最新版本”远远不够。

ACEOptimizer 的后期提交把更新链拆成多个可验证条件：版本标签必须与项目版本一致，更新清单需要 Ed25519 签名，安装包在进入安装流程前需要验证，私钥不进入仓库，同版本不重复提示。

这套设计仍不等于操作系统级代码签名。仓库也明确说明二进制没有 Authenticode 签名，SmartScreen 可能警告。把未完成的信任层写出来，比隐藏警告更专业。

Emergency-Stop 无法读取游戏内部速度，也没有官方完整移动曲线。因此它用键位变化与可调时间窗估算 MOVE、STOP、BRAKE 和 READY。

这里最重要的产品决定不是把数字调得更像，而是把状态标为“训练提示”而非“真实物理状态”。用户可以在训练场校准，项目不把未知包装成精确模型。

这种诚实同样适用于性能优化、网络诊断和硬件监控：只要测量链缺少关键变量，就应该降低结论强度。

开发类似 Windows 工具前，可以先回答：

小工具不需要复杂架构，但需要清晰边界。越接近系统、游戏或自动更新，边界越应该成为第一等功能。