AI 不断地覆盖到我们生活的方方面面，你会发现大部分应用界面都有 AI 入口。但是，更多的用户依然使用传统页面，打开 AI 聊天要么是尝鲜，要么是有人“请客”
那么，为什么我们不会去使用 AI 入口？为什么怒砸 30 亿“请客”却成了小丑？
AI 非常适合即时聊天类，你发文字，它回复文字。只回复文字的样式排版不好看，所以它会天然与 Markdown 结合
但如果想把它跟业务结合，现在普遍的形式是，预设一些业务场景专用组件。用咖啡小程序举例子，用户说“点杯咖啡”、“查看优惠”等，AI 会返回一个特定组件，我称之为“预制组件”，这就会让 AI 的能力被大幅度削弱
大家可以尝试说一句“我想修改手机号”，我试过绝大多数的应用都没法直接达成我的预期，而是搬出文档，指导我进入哪个常规页面去修改
五年内的前端会变成什么？
我们为什么不把“预制组件”变成“现炒组件”呢？
如 Demo 所示，把应该要渲染什么组件，交还给 AI 来决定。准确的说应该是，让 AI 来生成基于精准用户意图的组件
那么，大家的疑问是：为什么我不直接说“把昵称修改成 imba久期”呢？
这其实是不冲突的，作为应用开发者，我只需要把“应用的能力”封装起来并提供给 AI，那么 AI 判断到用户意图已经明确了，就可以直接调用应用能力完成修改。但如果用户意图并不明确，那么 AI 还可以自行调用生成特定组件来让用户自己操作
本质上来说就是把用户原本需要深入几层页面找的功能，直接端了上来
我认为，从现在到未来的 AI 超级入口之间，还有一步必须要走的就是原子化组件，将组件拆成最小单元，交给 AI 来基于用户意图进行组合
这套组件是一个空壳，没有任何逻辑和样式，但它可以去附着任何逻辑和样式，这也会交由 AI 来决定。那么到了最关键的点，就是如何让 AI 去实现任意交互逻辑和样式呢？
终于来到了最近我在做的一个项目，读音与 Trigger [ˈtrɪɡər] 一致
它借鉴了《魔兽争霸 Ⅲ》地图编辑器的触发器概念，通过事件、条件、动作三种元素来实现任意交互逻辑。老粉都知道，我最早是做魔兽地图编辑器教程视频的，为了情怀我还实现了一个 Web 交互触发器 Demo
简单来说它的作用就是，定义“按钮点击事件”、“修改昵称动作”、“修改性别动作”等基于业务逻辑的最小单元，并可以在 Runtime 阶段自由组合
有多自由呢？
点开来看
也就是当事件“左侧轮播切换”触发时，将右侧轮播切换到第几张呢，是获取的左侧轮播的索引值，这样就实现了轮播联动
大家可以尝试把左右调换，此时就成了右侧轮播切换时，带动左侧轮播同步
| 层 | 对应项目 | 职责 | 协议格式 |
|---|---|---|---|
| 组件框架（骨骼） | @triggerix-ai/component、triggerix-ai-component-native、未来的 atom component | UI 结构：有哪些组件、如何组合 | JSON Schema |
| Triggerix（肌肉） | triggerix/*、triggerix-editor-*、triggerix-collective.github.io | 交互行为：事件、条件、动作 | ECA trigger schema |
| Shinix（皮肤） | （规划中） | 视觉表现：颜色、间距、动画、布局 | Style schema |
三层完全独立，都用 JSON Schema 表达，并通过统一的 Runtime 解析与执行
当前还是 Demo 阶段，有兴趣的话欢迎参与，一起实现 AI 时代下该有的前端界面
Github 组织：https://github.com/triggerix-collective
评论区域将在可见后加载…
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。