Agent-HTML: 让AI生成的HTML像积木一样编辑和交互

开发调优
, ,
1

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

  • 我的帖子已经打上 开源推广 标签： 是
  • 我的开源项目完整开源，无未开源部分： 是
  • 我的开源项目已链接认可 LINUX DO 社区： 是
  • 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
  • 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

组件作为积木在页面可直接交互
block

更新日志

5/27:组件积木化，加入交互组件
5/24:优化视觉表达，优化agent语法
5/20:支持更丰富组件

丰富组件

agent生成面板，在页面做交互反馈

看板

支持表格及嵌入图片

表格及嵌入图片

支持丰富数据图表
图表

Agent交互

本地agent交互，哪里有问题直接问

agent交互

个性化主题

theme

HTML取代Md的优点可以见佬友的这个贴

纯 HTML 虽然是 LLM 擅长的东西，实际还是会遇到几个问题：

  • tokens 效率低，消耗大
  • 注意力漂移，临时样式参数会影响 LLM 对内容本身的重心
  • 风格漂移，换一个 session 后风格和偏好就会变化，很不稳定
  • 对模型要求更高，不仅要关注内容，还要同时处理结构、排版和样式

借助之前的一些开发经验，我尝试直接基于 shadcn 标准组件做一套原子积木标准件。

agent 不需要再生成任意 HTML/CSS，而是专注于用标准规格的积木去搭建这个"城堡"。同时也支持自定义主题和积木样式，实现风格化。

这样可以降低认知负担，不仅能减少 token 消耗，也能让模型在推理时把更多注意力放在内容结构上。

三色图

不可能三角
不可能三角549×428 128 KB

相同渲染下Tokens差异：

HTML Agent-HTML Save
Tokens 3,456 1,286 62.8%
Characters 8,131 2,623 67.7%

开发路线：

  • 排版 layout 积木化，适配自由排版风格
  • app 开发ing
  • 标准化动作组件，解析识别动作组件意图，从 request-response 走向 interact-interact
  • 实现实时预览，嵌入claude code/codex，实现交互式开发
  • 更好的html交互skill
  • 个性化组件配置及组件市场生态
  • 云端服务
73 个赞
AI编程的新思路： 从 UI 倒推 PRD， 让 PRD 可视化
用mcp让ai输出可交互html是可行的
2

看不懂怎么用思，但是感觉很NB，html真是未来交互的趋势吗？只是A/工程师的一篇帖子，是不是有些奉为圭臬了

1 个赞
3

相比于MD自由度更高，会是下一个载体，但是不是最终形态还不知道

4

觉得很厉害，不知道 hermes 接的 TG 用这个行不行哦

1 个赞
5

好想法,感觉前景非常光明. html太冗余了.

2 个赞
6

感谢开源！看着好有意思，赶紧尝试一下:face_savoring_food:

3 个赞
7

没太看懂其实，是想的 让ai通过html展示想法，进而一步步确认的意思吗？还是？

2 个赞
8

传统llm写html需要写一堆样式参数或者噪声，但是其实可以锁定样式以后让agent直接用标准积木写页面；结构化组件以后还在探索组件交互，只需要在页面上操作按钮,选项或者拖拽就能传达意图，就不需要费心打字和llm说半天需求

9

感觉不错啊佬友这个项目很有前途啊

1 个赞
10

如果普及了，将更废token 的缺点，或者分散注意力的缺点都解决了，html 肯定是对用户更友好的，可交互的文章回复，还是挺好看的吧

3 个赞
11

大佬，这个既然可以这样，可以运用到IDE里面吗，用来做写代码的对话框可行吗

1 个赞
12

目前我也想到的是这个交互，不需要看代码，直接鼠标操作agent生成的html做交互决策

2 个赞
13

挺有意思的工作，如果是奔着token saving和人机交互优化的层面去，是否还有更优方案呢，比如组件化? 一点不成熟的想法

1 个赞
14

对，其实程序员更多是需要在对话框就能看到渲染，目前只能做到一些简单的表格

2 个赞
15

现在框架就是组件化，用已经有共识的原子组件库作底座，这样也能解析交互时的动作行为

1 个赞
16

很适合我这样表达能力一般的用户。

1 个赞
17

对的，md只能渲染一些非常简单的结构

1 个赞
18

哈哈大家都一样，很多时候根本不知道怎么描述，直接让agent生成选项做选择题，不要做填空题

19

最近高强度在用 agent + obsidian 时，就感觉 markdown 的不便捷，初看这个项目就感觉很有意思，于是刚才和 AI 共读了一下佬友的项目，也提炼了一些问题和佬们探讨一下：

1.关于“积木”切多细

我读下来感觉最难的可能不是工程，而是这套积木到底切多细才合适。
类比化学：元素 → 分子 → 化合物 → 物质。

看 roadmap 里你按 archetype 一组一组扩，思路很清楚。但有个判断标准我没看明白——你现在切积木，是按"长什么样"切的，还是按"表达什么意图"切的？比如 <card status="warning"> 和一个独立的 <warning>，最后选了前者，背后的取舍是什么？

再加新组件并不难，但怎么保证它们之间不重叠、又能拼出真实场景，这个标准是什么？很想听听佬的想法。

2.项目定位

AI 说了一句有意思的定位，分享一下：

“ Agent-HTML 想做的事，本质是：找出"信息表达"这个领域里的"元素周期表"。 一份周报、一篇研究、一次评审、一份合同—— 看似不同，但它们的"元素"可能是一样的：标题、状态块、对比、警告、折叠的细节、可切换的视角。如果真能找出这些元素，并且证明它们正交且完备，那这套系统就不再是"模板"或"组件库"，而是信息表达的元理论。 ”

我个人感觉有点像在定义一套 AI Html 设计的 harness 方案，那这里的规则可能是最重要部分，原始的积木如何设计、积木搭建规则如何设计、AI 与这套规则的交互逻辑在哪

3.Customize 积木

佬，感觉你定义的 50 块官方积木挺不错的。我想到 HTML Web Components 的思路——核心保持封闭、稳定、不变；但开放一个 namespace 机制，让外部开发者用 acme:xxx 这种带前缀的方式自己注册积木？如：acme:contract-clause

这样或许可以在核心组件稳定的前提下，构建一个比较不错的 自定义资源库。

12 个赞
20

一些不成熟的想法，和佬交流一下hh

1 个赞