会动手,不只是会回答的助手

不妨完整跟随一次真实的交互，因为“一个能行动而不只是回答的助手”这种抽象说辞，在你亲眼看到之前什么都说明不了。有人在悬浮于本站每个页面的 Ask-AI 按钮里输入“帮我做一个带连续打卡的习惯追踪应用”。下面是从这句话到一个正在运行的构建之间实际发生的事，以及我们选择在哪里把主动权重新交还给人类。

这句话

九个字，没有标点，没有菜单导航，甚至不知道构建器在哪个页面。这就是输入内容，而它和这个助手收到的大多数请求形状是一样的：不是一条命令，而是一个愿望。没有人会这样表达：“打开构建器，把项目命名为习惯追踪器，在提示框里填写关于连续打卡追踪的描述，然后把焦点设置到启动按钮上。”他们只是说出自己想要什么。这两种表达之间的差距——愿望 vs. 指令——就是这个功能的全部所在。

解析

不管这句话是用什么语言输入的，它都会用那种语言来处理——我们在整个产品中支持二十种语言，与本平台更广泛的多语言定位一致，助手并不是在固定的英文脚本上叠加一层翻译，而是直接用你输入的语言进行原生推理。就“带连续打卡的习惯追踪应用”这个具体例子而言，解析需要同时完成三件事：

• 识别这是一个构建请求，而不是一个问题
• 提取一个项目名称
• 提取足够的信息，使提示框不至于空白

只要有一步出错，用户就会落在一个和自己需求不符的构建器界面上，这比什么都不做还糟——现在他们得先发现这处不符，再去修正，然后重新开始。

预备界面

这一步在演示里很容易被低估，在实际使用中也很容易做错：它并不会直接启动构建。它只是打开构建器，项目名已填好，提示框内容已写好，运行只差一次点击。这是一个刻意设置的停顿点，而不是我们没时间做完而留下的捷径。打开一个页面并预填一份表单，即使做错了代价也很低——最坏情况，你只需修改文字或关闭标签页。所以助手会直接执行，不弹确认框，也不问“确定要跳转吗”。

那次仍属于你的点击

那一次仍属于你的点击

我们反复权衡后才定在这个位置，说实话两种极端做法都不算完全对。事事都要确认，你就等于把过去那种点三层菜单的体验又搬回来了，只是外面套了个聊天窗口，反而更糟。什么都不确认，早晚解析会在一个含糊的请求上猜错，替别人花钱启动一次谁都没要求的运行。就这个具体例子而言，这意味着：助手一步到位帮你打开填好的构建器，而真正花钱的那个按钮，仍然是一次真实、经过深思、由人来点击的操作。

背后的支撑体系

有一件事你在这个流程里任何地方都看不到,而这恰恰是它重要的原因:整个过程——导航、暂存的提示、最终的构建——都只在你的工作区内进行,不涉及任何其他人。无论请求怎么措辞,都无法说服助手跨越租户边界访问数据,因为它并不是坐落在权限系统之外的特殊聊天功能——从机制上讲,它只是平台上的另一个智能体,遵循着平台上其他所有智能体都要遵循的同一套按账户隔离的边界。不存在“聊天机器人能不能看到这个”这样单独需要回答的问题,因为在聊天功能出现之前,基础设施就已经给出了答案。

不会发生的事

把这个例子再往前推一步,你就会碰到助手在未经提示时愿意做的事的边界,而明确这条边界的具体位置很重要。它会为你打开构建器。除此之外:

• 它不会超出你已批准的额度进行消费
• 它不会以你的名义把完成的项目发布到任何地方
• 它不会执行任何超出你自己工作区沙盒、触及外部世界的操作

这整一类操作根本没有由助手驱动的路径——不是更严格的确认,而是压根没有路径。如果你想把某个项目公开,那仍然是需要你自己找到并按下的按钮,和以前一样。

为什么止步点设在这里,而不是设在“更保险”的地方

我们本可以让上面每一步都需要征得许可,并称之为谨慎。但我不认为那是谨慎——我认为那只是这个功能本该消除的繁琐操作的一个更慢的版本。一个只会告诉你构建按钮在哪里的聊天机器人,即便出错,影响范围也很小:浪费三十秒,你有点恼火,没有任何实质消耗。而一个暂存真实构建的助手,如果护栏没设对,出错的代价会高得多——这正是“消费前需确认”这条界限存在的真正原因,不是我们为了显得负责而加的一个保险措施,而是因为我们观察到失败模式会落在哪里,于是就把止步点精确地设在了那里。在那条界限之前的一切——读取你的句子、暂存屏幕、让你只差一步就能完成——都不需要任何许可,因为其中没有任何一步能伤害到你。