Framer 3.0 的巧思：把 AI 放进画布，也把它关进分支

引言：AI 网页工具最难的不是生成首页

Framer 3.0 在 2026 年 6 月 16 日发布，官方把这一版概括为 Agents、Branching、Community 和全新设计，其中 Agents 被放进画布，可以设计页面、协同迭代、做断点、加动效、建组件、写代码、连接 CMS、查看站点分析和整理样式。1

这次更新有意思的地方，不是 Framer 也做了一个聊天框。Framer 官方在发布文里写得很直白：AI 生成网站经常卡在从 demo 到 production 的路上，因为真正上线还要处理响应式、内容结构、SEO、可访问性、一致性、协作和持续维护。2

Framer 3.0 的两个关键设计，都在回应同一个问题：AI 很会做大动作，但网页产品的上线决策需要细节控制。Framer 没有把 AI 做成一个独立的「生成站点」入口，而是把 AI 塞回设计画布；同时又用分支把 AI 的大改动隔离起来。一个负责让 AI 贴近真实工作对象，一个负责让团队敢于让 AI 动手。

巧思一：Agent 不在旁边聊天，而是在画布里接手局部工作

多数 AI 建站产品的默认姿势，是先让用户描述一个站点，再吐出一份完整结果。这个流程演示效果好，但用户真正要改的时候会碰到两个麻烦：一是提示词很难描述当前页面里的具体层级、样式和组件关系；二是生成结果常常像一份外部稿件，还要再搬回设计系统里整理。

Framer 3.0 反过来处理。官方介绍说，Framer Agents 可以看见并编辑团队已经在用的画布、组件、CMS 内容、样式、SEO 设置和发布流程；团队可以检查每一次修改、继续手动细调，再决定什么内容可以发布。2 设计重点不是「AI 多会写」，而是「AI 改出来的东西仍然是 Framer 原生对象」。

Framer Agents 的文件与提示词上下文界面 — Framer Agents 页面展示了把 DESIGN.md、CSV、图片等文件作为提示上下文的界面；这类输入让 AI 不只听抽象口令，也能按具体素材改页面。3

这个细节的产品判断很克制：让用户少「解释」，多「指给 AI 看」。Framer Agents 页面展示了几种上下文入口：用户可以选中画布上的 layers 加入 chat context，可以用 @ 提及页面、CMS collections、styles 或 assets，也可以上传图片、文件或 URL 作为 reference。3 这些入口看起来只是小功能，但它们把提示词从「请做一个更高级的页面」拉回到「按这个文件改按钮、间距和图标」。

这也是 Framer 3.0 和纯代码 agent 的差别。代码 agent 习惯围绕文件、diff 和终端组织工作；设计师判断页面时，更常用的是位置、层级、留白、组件状态和断点。Framer 把 agent 放进画布，就是承认这些判断发生在视觉对象上，而不是发生在一段抽象需求里。

这个选择也有代价。AI 越贴近原有画布，越会继承原项目的结构质量。样式命名混乱、组件边界含糊、CMS 建模随意，都会让 agent 的输出更难控。Framer 在另一篇定价说明里把 agent 的工作拆成 Design、Write、Organize、Analyze、Localize 等类别，并用 AI credits 计量；同一篇说明还写到，生成完整页面会比小文本修改消耗更多 credits。4 这相当于把「让 AI 大扫除」的成本显性化：用户可以用 agent 加速，但前提是愿意为大范围改动付出审核和调用成本。

巧思二：Branching 不是协作功能的补丁，而是 AI 功能的安全壳

Framer 3.0 的第二个巧思，是把 Branching 和 Agents 绑在一起发布。官方说 Branching 让团队可以在不影响生产环境的情况下试验，具体包括创建隔离分支、审查和比较改动、协作、合并通过的工作，再选择发布时间。2

这一步解决的不是模型能力问题，而是组织心理问题。让 AI 写一段文案，失败了可以删掉；让 AI 「把全站做成响应式」或「整理所有样式」，失败成本就高很多。网页团队最怕的不是 AI 改不出来，而是改出来以后没人知道它动了哪里，或者它在上线站点里留下一个难发现的小错。

Framer Branching 的分支与变更面板 — Framer 的发布图展示了 Branches 和 Changes 并排的界面，右下角的 Apply to Main 暗示分支改动需要被确认后再进入主线。2

所以 Branching 的设计价值，是把 AI 从「直接改生产文件的人」变成「提交方案的人」。Framer 的协作页把这个边界讲得更具体：Branches 让团队在项目副本上工作并保持原项目干净，Agent edits 可以自动进入 branch；每个 branch 还有 staging URL，可以先给团队或客户看，准备好再推到 production。5

这个流程还有一个容易被忽略的好处：它让非技术角色也能借用 Git 的心智模型，但不需要真的理解 Git。设计师看到的是 branch list、changes、preview、merge to main；背后的原则是版本隔离和合并审查。Framer 没有把这些词包装成「智能协作」，而是直接把高风险 AI 操作放进熟悉的上线闸门里。

外部 Agent 的处理更能看出这层设计。Framer 的 External Agents 页面写明，Claude Code、Codex、Cursor、Gemini CLI 等工具可以连接到 Framer 项目上下文；同页 FAQ 还说明，外部 agent 不能直接编辑 live site，改动发生在 Framer editor 的 canvas 中，只有用户选择发布或指示 agent 发布时才会上线。6 也就是说，Framer 允许外部 AI 进来，但先把它关进可回滚、可审查的产品边界。

结尾收束：好的 AI 入口，不急着把人挤出去

Framer 3.0 的设计判断可以压缩成一句话：AI 要贴着作品本身工作，但不能绕过人的发布判断。Canvas-native agent 让 AI 读得到真实页面语境，Branching 让团队敢于让 AI 做大改动。这两个设计合在一起，才比一个更强的提示框更有产品含义。

对做 AI 产品的人来说，Framer 3.0 的可迁移原则不是「给所有功能加 agent」。更准确的原则是：先找到用户真正做判断的工作对象，把 AI 放到那个对象旁边；再为 AI 的不确定性设计一个可检查、可撤回、可比较的缓冲层。少了前者，AI 只是另一个聊天窗口；少了后者，AI 越能干，团队越不敢用。