跟做 ASE 现场的 AFS-UI Demo
这次运行生成的 AFS 说明页。图中用路径和 provider 解释资源如何被访问；示意路径不代表这台机器实际挂载了所有这些后端。以下产品截图采自 ARC 2.0.0-beta.65 的本地运行，2026 年 10 月 12 日。
今天在慕尼黑 ASE 2026 的 Harness4GenUI workshop，我用 ChatGPT for Work 做了一次 live demo。现场很顺利，也有不少人对这个过程感兴趣：给 AI 一个 ARC 的链接，让它自己了解 AFS 和 AFS-UI，然后把它理解的东西做成我们能看的界面。官方 workshop 页面也列出了这次 AFS-UI 演示。
我想展示的是，prompt 可以很短，工作的上下文不能是空的。 我没有在对话里教它组件的属性，也没有逐个告诉它按钮怎么实现。那些说明应该由它工作的环境提供。
下面把 10 月 11 日的准备演示和 12 日的现场续做串成一个可以跟做的 tutorial。prompt 是按原始对话整理的可复制版本，不是逐字 transcript。截图来自实际运行结果；你的标题、排版、示例数据甚至页面数量都可能不同。复现的是工作过程和可验证的交互，不是复制每个像素。
开始前：给 agent 一个可以工作的地方
我用的是 ChatGPT for Work，刻意没有把现场入口换成 Claude Code 或 Codex 这样的专门 coding 工具。这里需要的是一个能够用工具干活的对话环境：能访问网页，能在你允许的工作目录里运行 ARC、写入产物，也能打开浏览器检查结果。只有一个不能调用工具的普通文字聊天窗口，做不到这一整套过程。
最短的本机路径是：打开 ChatGPT 桌面 app 并登录，在输入框上方选择 Work，打开或选择一个空的 demo 文件夹，把这次任务放在该文件夹里运行。在可用时选择本地电脑访问，完成文件和浏览器权限授权。界面入口随版本和工作区策略而异，可以对照 ChatGPT 桌面 app 官方指南和 Work 入门说明。若你的账号没有本地工具入口，先不要继续：请使用能够访问该目录的 Work 环境，或有等价工具权限的其它 agent。打开 ARC 的入口页，按照页面提供的官方安装方式安装 ARC，也可以让具有本地工具权限的 agent 完成。若安装或连接需要你授权，就在这一步完成。让它报告实际安装版本和连接到的实例，不要把首页上的版本文字当成运行结果。
整理后的第一条 prompt：
https://arc.arcblock.io
这是 ARC 的入口。请在这个空的项目目录里从头准备一个
AFS 和 AFS-UI 的 live demo，使用实际安装的 ARC。
先查看你有哪些工具和说明，报告安装版本。这里的阶段性结果是一个能运行的 ARC 环境，还不是成品网页。让 agent 展示版本、确认实例能访问，然后继续。也可以直接补一句：“请启动本地 ARC，读取根路径说明，并告诉我实例地址；若无法访问，先指出缺少的权限。”能够回读运行时的说明，才算准备完成。我的这次 demo 用的是 2.0.0-beta.65，重做时以你实际安装的版本为准。
AFS 是 Agentic File System，把资源放到共同的路径和操作方式下。ARC 是承载这些能力的运行时。AFS-UI 是它的界面子系统；AUP 用结构化描述写出表格、输入框、按钮以及它们的动作。provider 则是把某种资源接入共同路径的连接层，例如把本地文件接到一个可读取的路径。先把名字分清，后面就容易看懂了。
第一步：让它解释自己发现的东西
昨天安装好 ARC 之后，我没有把 AFS 的规格贴给它。我要求它从自己能找到的说明里了解概念，再做出面向观众的解释。
用刚安装的 ARC 创建一个 blocklet，并把它展示成网站。
你自己从 ARC 的说明和运行时里了解 AFS 和 AFS-UI。
用 ARC 的 Web Device 做一个页面解释 AFS，另一个页面解释 AFS-UI。
我不会给你详细规格。请把你查到的内容和来源告诉观众。blocklet 可以先理解为交给 ARC 运行的应用包。它让页面、资源和说明有一个可以继续工作的归属。
预期结果是能打开的说明页，解释资源如何通过路径和 provider 被访问，也解释界面为什么能成为这个空间的一部分。它不需要长得像上面的截图，但应该能指出事实来源，而不是只写一段漂亮介绍。这次的说明网页由 ARC 的 Web Device 渲染；接下来的交互示例用原生 AUP。两种形式都用到了 ARC，具体承担的工作不同。
第二步：从说明走到能点的 demo
我接着收窄了范围：不要再造一个 agent。请把学到的界面能力做成几个常见 UI。
不要创建一个新的 agent。做几个 AFS-UI 示例页面：
一个可以切换显示数据的 dashboard，一个有实时预览的表单，
一个可以改变状态的任务页面。请用原生 AUP 节点，
不是把普通 HTML 仿制成看起来一样的页面。用示例数据，让观众能直接操作。
Dashboard 用表格和动作节点组织数据。“This week”和“This month”是可以点击的控件；项目是示例数据。
点一下月份按钮，表格里的内容应该跟着改变。这里需要亲手检查，不能以“agent 说完成了”为验收。
同一页面切换到本月数据。这个操作更新了显示标签和表格行，没有要求模型重新生成一张屏幕。
请让 agent 再确认：“展示这个示例的 AUP 节点树，指出表格、按钮和事件绑定。”能看到对应的结构和响应，比单看外观更能确认实现形式。
表单也值得试：输入一个名字，看看预览是否同步改变。任务页则检查 Ready、In progress、Done 之间的变化。这些 demo 展示的是当前界面的状态，没有接上真实项目数据库，也不意味着刷新后记录仍然保存。想继续做成实际应用，可以再提出持久化需求。
第三步：追问“你怎么知道的”，再做比较
昨天的演示里，我追问了一句：我没有教你 AFS-UI，你怎么会用？这个问题可以直接交给 agent 展示。
加一个比较页面，用幻灯片解释：你如何从 ARC 的说明学会
构建这些界面？这和直接生成 HTML 有什么不同？
再查阅 MCP Apps / MCP-UI、A2UI 和 AG-UI 的官方资料，
比较它们解决的问题，给出来源，不要替任何一种方案夸大优势。
昨天生成的比较页从“安装、发现、阅读、构建、验证”开始。比较页面本身使用 Web Device；它与原生 AUP demo 不是同一种页面实现。
不必把比较结论背下来。HTML 给浏览器完整的页面表达能力；AFS-UI 则把可检查的界面结构放进已有的操作空间。其他协议关注的边界各有不同，读者跟做时应让 agent 核实最新官方资料。
这次我能查到它使用了 ARC 的命令说明和内置 booklet，也读取了运行时的根说明、能力索引和 UI 规格。这些由 agent 在连接到的 ARC 实例里查看，读者不需要手工输入。explain / 是询问根路径含义的操作，/.knowledge 是能力索引，/dev/ui/spec 是界面描述的规格路径。它还查看 input、table 等组件的属性。这是获取新上下文、试用并验证，不是现场重新训练模型，也不是证明模型以前完全没接触过相关概念。昨天的探索还读过网页和本地资料。
第四步：让 AI 留下它自己的过程记录
昨天我又让它加了一篇 blog。最开始想让它用我的口吻，随后改成由 AI 讲述自己的工作过程。跟做时可以直接使用澄清后的版本：
另外加一篇过程 blog。用 AI 自己的第一人称，说明我给了什么，
你读到了什么，做出了什么，以及哪些交互已经检查过。
不要冒充我，也不要把阅读资料说成模型训练。
这是准备演示留下的过程记录，讲述发现和检查的方法。它是当时对话的产物，不是独立的产品规格，也需要人审核。
这一页能让观众检查短 prompt 后面究竟发生了什么。真正值得留下的不是 AI 对自己的赞美，而是它查过什么、做过哪些检查，以及哪些地方仍属于示例。
第五步：把说明、demo 和 slides 分成不同 URL
今天面对观众，我从同一个 ARC 链接出发，让它呈现自己发现的 AFS 和 AFS-UI，再要求增加 slides。今天的目录已经有昨天的安装和产物，因此这是续做，不是第二次空目录实验。
请根据你了解的 AFS 和 AFS-UI，用原生 AUP deck 创建一个 slideshow 页面，
用一页一个要点的方式向观众解释。
网页、交互 demo、slides 分别使用独立 URL。
不要覆盖现有页面。给我可以分别打开的链接，并逐个验证。
今天新增的 slides 使用 AUP deck，按主题解释 AFS、provider 和界面节点。它是讲解材料，dashboard 则让人亲手操作，两者各有自己的地址。
我的现场确实追加了“请使用不同 URL”这条要求，因为只把当前屏幕替换成 slides，观众就很难回到原来的网页。教程把它提前写进 prompt。得到链接后，把网页、dashboard 和 slides 各开一个标签页，分别检查。
地址里的 localhost 表示页面运行在你的机器上。端口和域名可能由实例配置决定，不必照抄截图里的数字。请使用 agent 返回并验证过的地址；让其他人的设备访问，还需要另外安排部署或共享。
第六步：现场搜索 workshop，再把新信息做成界面
这一步是今天现场临时增加的任务。我让它去查我们正在参加的 conference 和 workshop，然后把查到的内容做成一个新的 AFS-UI 页面。
我正在 ASE 2026 的 Harness4GenUI workshop 做 live demo。
请搜索这个会议和 workshop，优先读官方页面。
用 AFS-UI 建一个新的页面，呈现你核实的会议信息和日程，
保留来源链接，标明查询日期。不要覆盖刚才的网页、demo 或 slides。
新页面把官方资料整理成表格，并保留出处。主题按钮会更新解释文字。这是查询时的资料快照，不是自动更新的会议日程。
这次它找到了 ASE 2026 的官方站点和 Harness4GenUI 页面，还查到了我的 keynote 和 AFS-UI demo 的安排。可以点击出处，核对日期、地点和时间。搜索拿回内容，AUP 提供有结构的呈现，ARC 把它运行起来。这比再做一张通用的项目表格更接近现场的问题：眼前刚得到的信息，能否马上变成我们能检查和操作的界面？
为什么几句话能做出来
我给出的主要是任务的意图：解释给谁听、演示什么行为、要保留哪些页面。agent 自己完成查资料和组装界面的细节。少写 prompt，并不表示它少做了工作，也不表示没有前提。
这里的 harness 是一个支持界面生成与使用的工作环境。它向 agent 提供可发现的资源，并说明工具接受哪些输入、返回什么结果，提供 UI 组件的说明与渲染器，并让人检查结果。模型负责提出界面描述；事件和运行时负责让界面继续响应。按钮按下去后，不必为了改变一个标签再问模型一次。
这个演示也产生了页面源码，当然有软件工程的工作。但我关心的验收对象是屏幕：观众能否看懂、能否点击、界面是否按约定改变，以及新内容能否继续进入同一个空间。这就是此处的 harness for Generative UI。它给变化的界面一个可以运行和检验的基础。
AFS-UI 的接口不要求使用某一家模型。Claude、Grok 或其他有相应工具能力和访问权限的 agent，也可以沿着这些契约工作，目标是类似的结果。这两天展示的是 ChatGPT for Work 的过程，不是跨模型效果一致的测试。更换 agent 时，能否连接你的环境、读取说明并执行操作，比它是否能生成一段 HTML 更关键。
我在《不要把项目送进 Agent 工厂，把 Agent 请进自己的 Realm》里写过：项目需要有自己的上下文和工作边界，agent 是被请进来干活的帮助者。这次就是一个很小的例子。昨天留下的说明页和示例没有随聊天结束消失，今天可以继续增加 slides 和 workshop 信息。
第一次跟做，可以先完成说明页和一个按钮交互，再逐步加页面。保留可访问的来源，也保留运行结果。短 prompt 的作用是把意图说清；空间里的说明、工具和运行时，让这份意图有地方落下去。换一个帮助者时，我希望继续在这个地方工作，而不是把整个项目重新讲一遍。