浏览器里的 sandbox 正在变成 CLI 产品的新 onboarding 层

先试再装本地环境

CLI 产品这两年最明显的界面变化之一，是“本地安装”不再总是第一个真正有意义的步骤。浏览器 sandbox、引导式终端演示和网页内命令界面，越来越多地让用户在真正配置本地环境之前，先体验一遍工作流。

这是一种很大的 onboarding 变化。过去 CLI 产品往往先要求用户付出信任，再慢慢展示价值。你得先安装、认证、配置，然后才知道它到底能做什么。而浏览器 sandbox 则把顺序倒过来了，让第一次接触的成本显著下降。

为什么浏览器层有效

浏览器层的价值，并不在于它能完美模拟一台本地机器，而在于它缩短了说明闭环。

只要几分钟，用户通常就能先看见几件关键的事:

1. 命令长什么样。
2. 输出会是什么形式。
3. 哪些动作是自动化的，哪些还是手动的。
4. 这个产品到底和自己的工作流有没有关系。

这已经足够把很多人从“模糊好奇”推进到“知道下一步该干嘛”。从 onboarding 的角度看，sandbox 不需要替代真实环境，它只需要建立信心和方向感。

sandbox 的边界在哪里

浏览器里的命令界面当然也有非常明显的边界。它往往会把认证复杂度、真实文件系统、本地 shell 差异、网络限制，以及接进真实项目时的混乱都先抹平。

所以，sandbox 更应该被理解为演示层，而不是产品的全部真相。它能更快回答“这玩意大概是什么感觉”，但很少能单独回答“放到我的机器和我的真实工作流里会是什么体验”。

真正的问题出现在团队把这两层混为一谈的时候。一个很流畅的浏览器体验，完全可能掩盖掉后面仍然存在的大量配置和复杂性。

为什么这对内容结构重要

这个模式之所以值得写，是因为它改变了产品真正的入口位置。如果浏览器 sandbox 成了多数用户第一次看到的命令界面，那么它就应该获得过去只给安装流程和文档页的那种编辑关注。

对 cli.news 这样的站点来说，问题不只是“某个产品有没有 sandbox”，而是“这个 sandbox 在整体体验里扮演什么角色”:

1. 它只是演示吗？
2. 它是认真可用的学习界面吗？
3. 它是不是主要 onboarding 路径？
4. 它能不能顺畅接到本地安装、文档和更深层工作流？

随着浏览器 sandbox 越来越普遍，很多用户的第一段 CLI 体验，会先发生在浏览器标签页里，而不是终端应用里。这是一种结构变化，不只是 UI 选择。