Windows 上别直接相信 python 命令：给本地校验补一个跨平台入口
最近整理 Codex Skill 命名时，最后一步需要跑一遍 quick_validate.py。这个校验脚本本身很简单：读 SKILL.md，检查 frontmatter、必填字段和命名规则。但在 Windows 机器上，事情卡在了更靠前的位置：python / python3 命令并不一定是真的 Python。
有些 Windows 设备打开了 Microsoft Store 的 App Execution Alias。终端里输入 python 时，命令可能会落到商店占位符上，而不是一个可执行的 Python 解释器。于是你以为自己在跑校验，实际连脚本都没启动。另一个常见情况是机器上有 Python，但没有装 PyYAML，脚本仍然会在 import 阶段失败。
这种问题不适合靠每次手动记忆解决。
手动修可以，但不够稳定
对一台具体设备来说，修法并不复杂：
py -3 --version
python --version
python3 --version如果 python / python3 指向商店占位符，可以在 Windows 设置里的 App Execution Aliases 关掉 Python 相关别名，或者安装正式 Python 后把它放到 PATH 里。也可以直接用 py -3，它通常比 python 更适合 Windows。
但这些都是“修机器”。我真正想要的是“修入口”：仓库里写下一个稳定命令，让新设备、旧设备、Codex 环境和普通终端都尽量走同一条路。
给校验包一层 Node 入口
这次我在 codex-home 里加了一个入口：
node tools/validate-skills.mjs [skill-dir ...]不传参数时，它会校验 skills/ 下全部自定义 Skill；传参数时，只校验指定目录。
它做的事很克制：
- 按顺序寻找
--python、PYTHON、CODEX_PYTHON、Codex bundled Python、Windowspy -3、python3、python。 - 每个候选都会先跑一段最小探针：
import sys; print(sys.executable)。 - 如果候选是 Microsoft Store 占位符，探针会失败，然后继续试下一个。
- 如果 Python 可用但缺
PyYAML，就把PyYAML安装到系统临时目录下的专用依赖目录。 - 真正的校验规则仍然交给原来的
skills/skill-creator/scripts/quick_validate.py。
也就是说，Node 不接管校验逻辑，只负责把“找得到一个能跑校验的 Python”这件事做稳。
为什么不是重写成 JS
把 quick_validate.py 重写成 JS 当然也能绕开 Python 问题，但那会把已有校验逻辑复制一份，后面规则变化时容易两边不一致。
更好的边界是：Python 脚本继续作为规则源，Node 包装器只处理跨平台启动问题。这样后续要改 Skill 校验规则，仍然只需要改一个地方；要处理 Windows、macOS、Linux 的解释器差异，则在包装器里消化。
这个仓库本来已经用 Node 做 setup-codex-home.mjs，所以再用一个 Node 脚本做跨平台入口也顺手。对使用者来说，记住一个命令就够了：
node tools/validate-skills.mjs skills/comment-wrap在 Windows 上，它可以选中 Codex bundled Python，再把 PyYAML 放进 %TEMP%：
python: Codex bundled Python (<home>/.cache/codex-runtimes/...)
pyyaml: <temp>/codex-home-skill-validator/...
[OK] skills\comment-wrap文档也要跟着换入口
工具加完之后，我把维护说明里原来的：
python3 skills/skill-creator/scripts/quick_validate.py <skill-dir>换成了：
node tools/validate-skills.mjs <skill-dir>comment-wrap 的自测命令也一起换掉。这样后面改 Skill 时，不会再被文档带回 python3 那条不稳定路径。
这类问题的经验
Windows 上的 python 命令不等于“可用 Python”。它可能是启动器，可能是 PATH 里的某个解释器，也可能只是商店占位符。对一次性本地操作来说，发现了再手动修也可以；但对仓库维护命令来说，最好不要把这种设备状态暴露给每次执行的人。
我的判断是：凡是“仓库要求经常跑、而且依赖解释器和第三方包”的命令，都应该有一个稳定入口。这个入口不一定要很复杂，但至少要明确解释器来源、依赖准备位置和失败信息。环境差异被工具吸收掉，人的注意力才可以留给真正的校验结果。