M001：先跑起来：exec、activate、shims 与 trust

目标：建立 config → tools/env → command/task 心智模型，并能按场景选择 mise exec、mise run、activation 或 shims。

执行 python 时，普通 shell 通常只沿当前 PATH 找二进制。mise 在这之前增加了一层可审阅的解析过程：

所以，mise 不是单纯“下载另一个 Python”，而是在命令执行前建立项目上下文。[S02]

四种入口解决的问题不同：

入口	它做什么	适合什么	不应误解为
`mise exec -- CMD`	为一次命令构造 tools + env	仓库脚本、临时命令、自动化	必须先 activation 才能用
`mise run TASK`	在同一上下文运行仓库声明的 task	lint、test、build、CI	只是命令别名
`mise activate`	shell 每次显示 prompt 时更新 PATH/env	人在终端里频繁交互	安装器或 CI 前置步骤
shims	通过代理可执行文件按调用时解析环境	IDE、部分脚本和 CI	activation 的完整替代品

官方入门文档明确说明：mise exec 可直接工作；activation 主要改善交互 shell，shims 更适合 IDE、脚本和 CI，但不支持 activation 的全部 shell 特性。[S01]

这次先不修改 shell rc，也不信任陌生仓库。所有实验都放在临时目录。

mkdir -p /tmp/mise-course-lab
cd /tmp/mise-course-lab
pwd
ls -la

预期观察：pwd 指向 /tmp/mise-course-lab，目录中没有未知项目配置。这样可以把后面的结果与真实仓库隔离。

mise --version
mise doctor

预期观察：第一条打印 mise 版本；mise doctor 给出安装与 shell 集成诊断。警告不一定表示本课失败，但若命令不存在，应先修复 mise 安装或直接使用安装位置，例如 ~/.local/bin/mise，不要继续猜。

command -v python || true
python --version 2>&1 || true

把输出记为“mise 外”。系统没有 python 也没关系；这正好说明后面不能只看命令名。

mise exec python@3 -- python --version
mise exec python@3 -- python -c 'import sys; print(sys.executable)'

第一次可能下载工具，下载等待不计入练习时间。[S01] 预期观察：两条命令都成功；第二条路径通常位于 mise 的安装目录，而不是步骤 3 的系统路径。真实版本以你的输出为准，不要把课程示例写成证据。

用两句话完成下面模板：

mise 外的 python 路径/状态是：____。
mise exec 内的 python 路径是：____；差异说明 ____。

正确解释应提到：mise exec 为这一次子进程构造了工具环境；它没有要求你把 activation 永久写进 shell rc。

常见失败与下一步：

mise: command not found：先运行 command -v mise，确认安装路径是否在 PATH。
下载失败：保存完整错误；先区分网络、代理、证书和版本解析，不要反复改配置碰运气。
两个 Python 路径相同：不一定失败。系统 PATH 可能已经指向同一个 mise 安装；用 mise exec -- env | grep '^PATH=' 和 mise which python 继续确认来源。
出现 trust 提示：先停下并检查当前目录及父目录是否存在配置。配置可包含 env directives、hooks 或 tasks，不能为省一步而盲目信任。[S07]

不要凭“哪个命令短”选择。依次问四个问题：

这是人在持续交互，还是无人值守自动化？ 人在 shell 中反复输入命令，activation 能减少前缀；自动化需要显式入口。
仓库是否已有一个有名字的 task？ 有 test、check、build 等 task 时优先 mise run TASK；否则用 mise exec -- CMD。
调用者是否难以加 mise 前缀？ 某些 IDE 只会寻找 python/node，这时可考虑 shims。
行为是否依赖个人 shell rc？ 如果答案是“是”，脚本和 CI 的可复现性就不足。

场景	推荐选择	推理过程
interactive shell	`mise activate`	人会连续运行许多工具，自动更新 PATH 能减少重复输入；即使不 activation，仍可退回 `mise exec`
仓库脚本	`mise run check`；无 task 时 `mise exec -- ./script.sh`	入口跟仓库一起审阅，不依赖某位开发者的 rc；task 还能统一 tools/env
CI	`mise run ci` 或 `mise exec -- CMD`	每一步显式建立 mise 上下文，runner 是否加载个人 rc 不再影响结果
只接受裸命令的 IDE	shims	IDE 难以添加命令前缀；但要接受 shims 的功能边界

现在把表中的理由盖住，自己为前三个场景各写一句。理由必须出现“交互便利”“仓库契约”或“不依赖 shell rc”之一，而不只是“官方推荐”。

问题：为什么 activate 不是运行 mise 的前提？

作答后查看参考答案

mise exec 会为一次命令显式构造 tools/env 上下文，mise run 会在同一上下文运行 task；二者不依赖 shell 已经 activation。activation 解决的是交互体验，不是 mise 能否解析和执行。

纠错题：某 CI 脚本先 source ~/.zshrc，再直接运行 python test.py。最小改进是什么？

作答后查看参考答案

把入口改成仓库可见的 mise run test，或至少使用 mise exec -- python test.py。这样工具选择不再依赖 runner 的个人 rc。若 CI 只能使用裸命令，再明确配置 shims，而不是默认 shell 已 activation。

通过标准