删掉安装步骤后，我们才发现它撑起了整个设计

CloudPal 的第一个版本有一个安装步骤。它很小，一周就能写完，之后几乎不再被想起。但删掉它花了三周，并且比我们做过的任何事情都更彻底地改变了设计。这篇文章要讲的是，那个安装步骤到底在支撑什么——因为“无需安装”听起来像是一个打包决策，实际上却是一个架构决策。

机器通常不是你的

删掉安装步骤的理由普通得令人尴尬。需要生成文档的人，往往并不坐在自己的电脑前。他们用的是借来的笔记本、自己没有管理员权限的工作机、酒店商务中心的电脑，或者合作伙伴的桌子。而手头的任务通常有截止日期——这正是你最不想做安装决策的时刻。

如果你曾在别人的机器前犹豫过，你就知道那种犹豫的形状。它其实无关磁盘空间。安装是在向一台不属于你的电脑索取一部分控制权，而这个索取附带了一连串承诺：一个你现在要负责的后台进程、一个你无法审计的权限、一个你将来得记得卸载的东西。

我们本可以把安装程序做得更安静。但我们转而问：它到底是为了什么？诚实的答案是：为了方便我们，而不是用户。于是我们把它拿掉了，然后用接下来的三周时间，发现它周围悄悄长出了多少东西。

没有本地进程，标签页就不能拥有任何东西

第一个倒塌的支柱是进程归属。有安装的时候，关闭窗口后仍有东西在机器上运行，心智模型很舒服：工作在本地，窗口只是它的一个视图。去掉安装后，浏览器标签页成了用户侧唯一的存在——而标签页是糟糕的所有者。它会被关闭，会在合上笔记本时被挂起，会被复制，会随时重新加载。

所以运行不能活在标签页里。这不是偏好，而是一个要么早早接受、要么痛苦改造的约束。由此引出一串不再可选的设计决策：

• 服务器必须是“发生了什么”的唯一权威。 不是“服务器与客户端同步”，而是客户端不报告它无法证明的事情，运行的记录来自真正执行运行的那一侧。
• 每个请求都必须可以安全地发送两次。 刷新页面会重发请求，不确定是否成功的人会再按一次按钮。如果重试的请求会产生第二份输出，你就造出了一个惩罚急躁的产品——而急躁的用户占很大比例。
• 重连是一等状态，而不是错误。 从“合上笔记本”到“在火车上打开”之间的空档，不是需要道歉的故障模式，而是正常路径，界面有义务如实告诉用户他不在时发生了什么。

不舒服的地方在于，这三条说起来便宜，守起来昂贵。诱人的捷径是让客户端缓存状态、稍后对账，这在两台设备意见一致时很美，一旦不一致，合并逻辑就成了产品本身。

幂等性是这里“每个请求都必须可以安全地发送两次”背后的工程原则。一个操作是幂等的，意味着执行一次和执行多次的效果相同——比如“把文档标题设为X”是幂等的，而“在文档末尾追加一段话”不是。在无安装架构下，网络重试、页面刷新、用户重复点击都会导致同一请求被多次送达，因此服务器端必须为每个写操作设计去重机制，常见做法包括客户端生成唯一请求ID、服务端记录已处理ID、或把操作建模为带版本号的状态覆盖而非增量追加。幂等性不是可选的优化，而是分布式系统中保证数据一致性的基础约束。

产物不能住在路径里

第二个崩塌的是命名。在机器上，文档就是一个路径：~/Documents/brief-final-v2.docx。路径就是身份。这也是一个只在同一台电脑上才成立的谎言。

一旦机器不在循环里，“它在哪”就不能再指一个文件夹。它必须意味着某种能跨越不同设备、不同浏览器、清空的缓存、甚至一份新工作的东西。在实践中，它必须是账户——这就拖出了基于路径的系统从不需要回答、也没人喜欢回答的问题：

• 有人在再也不会见到的机器上编辑了文档，会发生什么？
• 两个人打开同一个东西、都改了一段，谁的版本才是“那个”版本？
• 下个月有人要同样的东西，是新文档还是旧文档的修订？两者都说得通，但只能有一个是默认。

我们的答案刻意无聊：你得到的是一个住在你账户里的文档，有自己的历史，在任何浏览器里看起来都一样。无聊就是目标。一个行为取决于你手里是哪台机器的产物，是伪装成功能的支持负担。

路径作为身份是本地文件系统的一个隐含假设：文件的唯一标识就是它在目录树中的位置。但路径身份非常脆弱——重命名、移动、删除都会改变身份，而跨设备时根本不存在统一的路径空间。迁移到账户后，产物需要一个与位置无关的稳定标识符（如UUID），并附带元数据（创建者、时间戳、版本历史）。这本质上是从“文件系统模型”转向“数据库模型”：每个产物是一条记录，路径退化为可选的展示属性。代价是需要自己实现版本控制、冲突检测和访问权限，这些在本地文件系统里由操作系统免费提供。

你永远不会看到的权限对话框

去掉安装程序，也去掉了操作系统请用户信任我们的那个时刻。这是真实的便利，同时附带一项义务，我们花了一阵子才把它说清楚。

安装也是一次权限授予。应用可以碰硬盘、读它指向的文件夹、在后台运行。我们放弃了这些。所以我们没有在机器上的立足点，也绝不能表现得好像有——不在文案里，不在产品暗示的承诺里，也不在我们希望拥有的功能列表里。

这就是 CloudPal 生成文档、而不是整理你已有文件的原因。这不是谦虚，也不是等待路线图的临时状态。读取别人已有的文件，恰恰需要那个我们刚删掉的本地立足点。对这个功能说“不”，才让“无需安装”成为实际的主张而不是口号。

最小权限原则是安全工程中的经典准则：一个系统只应拥有完成其功能所必需的最小权限。删除安装程序意味着CloudPal主动放弃了本地文件系统读写、后台进程驻留、系统级通知等权限。这不仅是产品选择，更是安全承诺——没有权限就没有权限被滥用的风险。但这也意味着产品能力边界被永久划定：任何需要读取用户已有文件的功能都无法实现，除非重新引入安装。这种“以能力换信任”的取舍在面向非技术用户的工具中尤其重要，因为权限对话框对普通用户而言往往是盲签。

你还顺带删掉了设置对话框

安装通常附带一个放配置的地方：偏好设置面板、项目文件夹、配置文件、API key 输入框。拿掉安装，这些全都没了。听起来像是简化，实际上是一个约束。

因为如果没有配置界面，那么用户需要告诉我们的一切，都必须塞进他打出的那句话里。这个门槛比看起来高得多。让一个人描述他想要什么，对已经懂行的人是不错的接口；但对更常见的情况——他知道成品该长什么样，却没有词汇描述中间步骤——这是糟糕的接口。有设置面板，你递给他一张表单，让表单去思考；没有面板，产品必须自己思考，并且愿意在同一段对话里简短地问一两次，而不是塞进一个没人会填完的向导。

于是我们有了一个内部规则，听起来比实际有用：任何只能通过往表单里加字段来配置的功能，都是我们还没做完的功能。 它要么能装进对话，要么就先不发布。这就是为什么 CloudPal 给你的第一样东西是结果而不是设置界面——不是为了演示好看，而是因为我们再也没有地方藏配置了。

对话式配置与表单式配置的根本区别在于：表单把结构化的决策负担转移给用户（选择选项、填写字段），而对话要求产品自己从自然语言中推断意图。后者对产品的NLU能力要求更高，但用户体验更轻。然而，对话式配置的局限在于可发现性——用户不知道产品能配置什么，因为没有一个可见的选项列表。这要求产品在对话中主动引导，而非被动等待指令。CloudPal的规则“只能通过加表单字段配置的功能就是没做完的功能”实质上是在强制团队把配置逻辑内化为产品智能，而不是外化为用户劳动。

我们放弃了什么

把它说成一场干净的胜利是不诚实的。有三件事变差了，值得点名，因为读到这里的开发者自己也会想到。

本地速度。 本可以利用快速本地机器和已有本地语料完成的工作，现在必须在我们机器上、仅凭对话里说的内容来生产。这是一个真实的天花板。

离线。 没有安装就没有本地运行时，没有 wifi 的飞机上无法工作。连接就是产品。

私有上下文。 如果你的材料放在无法粘贴的地方，那今天这个工具不适合那项任务。我们宁愿说出来，也不愿暗示相反、然后在截止日期前让人失望。

这些是代价。换来的是：它在你碰巧面对的那台机器上就能用，而且离开是免费的——关闭标签页，那台电脑上不会留下我们的任何东西，因为从来就没有东西在那里。

一个五分钟的测试

这件事很容易验证，所以我喜欢它。用一台不是你的电脑，或者一个你不在意的浏览器配置。打开 CloudPal，登录，要一个真实的东西，然后在它完成之前关掉窗口。稍后换一台机器回来，看看你要的东西是否还在你离开的地方，并且如实说明了发生了什么。

如果这能成立，你学到的东西比任何功能列表都有用：工作不在窗口里发生，结果也不属于那台电脑。

我们怎么处理这件事

CloudPal 在我们的机器上运行长任务，可以按计划执行，并交回一份完成的文档——无需安装，不向你的电脑索取任何东西，不读取你已有的文件。你用一句话说出你想要什么、什么时候要，输出是一份可以转发的文档，而不是一个需要你重新拼装的答案。

目前处于有限预览阶段。新账户获得一美元额度，足够跑一次真实任务，每日新增账户数量有上限。

如果你想以工程师的标准评判它，我会问的问题不是它是否聪明，而是：在运行中途关闭标签页，然后去看看它能否告诉你，你不在看的时候它做了什么。 一个只在你注视时才存在的 agent，只是一个多走了几步的聊天窗口。