用 $eval 做评测
让仿真用户在真实产品上完整使用一遍，保留轨迹作为证据，并据此决定下一步做什么。
为什么要用仿真用户#
一个产品做出来之后，早期最需要了解的问题其实都比较粗：哪一步没人能走完、哪句话没人看懂、哪个按钮没人找到。这些问题在一次仿真运行中就会暴露，用时以分钟计而不是以周计，而且是在投入尚未沉没之前。
Mirasim 中的评测是一项需要显式调用的能力，不是常开的自动审查。需要证据时调用 `$eval`，仿真在本机运行。
产物截图、轨迹、命令和报告都保存在这里，并绑定到产出它们的那一端。无法追溯到具体某次运行的结论，一律视为没有结论。（该控件不在当前这一屏上）
这块面板上的按钮可以直接点，点着看看。
执行一次评测#
这套流程对「什么算有效信号」有明确要求，而且步骤顺序有讲究。
- 锁定版本，明确本次要决定什么
锁定被测的具体版本，并写明不同结果会让你做出什么不同的选择。一次不会改变任何决定的评测，只是一份无人阅读的报告。
- 构建相互独立的画像与自然的场景
与挑选真实测试用户的方式一致：缺乏耐心的新用户、跳过引导的熟手、正在寻找理由离开的怀疑者。每人带一件他确实可能会做的事，而不是一份需要照着走的脚本。
- 给每个用户真实的入口
一份干净的上下文，加上真实的产品：一个浏览器、一台手机、一个命令行、一次对话，或者一份已渲染的产物。证据是运行时的操作与观察结果；阅读源码不计入用户证据。
- 先阅读证据，再做决定
截图、命令、轨迹和产物都会保留，观察到的事实与推断出的判断分开记录。之后再决定：保留该改动、回退，或者换一批预留用例重新验证。
阅读结果#
阅读一次运行的结果有推荐顺序，从最有用的部分开始。
- 用户实际卡在哪里：也就是这次运行中断的那个操作或观察点。轨迹已保留，可以完整回看一遍。
- 哪些是观察到的，哪些是推断出的：两者有意分开记录，前者可以直接采信，后者可以讨论。
- 下一步该做什么：每一个观察到的问题都直接转化为下一轮循环中的一项开发任务。
跑过的记录留在应用里：按 ⌘K 搜「Eval 记录」就能打开已记录的模拟运行列表，上周那一轮搜一下就能找到，不必记住它存在哪个目录。
这一页有错或缺了什么？ 告诉我们