展示 HN:Canopy – 针对 macOS/AkkPit 的 A2UI 实现,使用 Go 语言开发
我几个月前偶然发现了<a href="https://a2ui.org" rel="nofollow">https://a2ui.org</a>,决定将其作为一个副项目进行实现。
Canopy 可以将 JSONL 文件渲染为功能性和互动性的原生 GUI。
以下是一个“你好,世界”的示例:
```json
example.jsonl
{"type":"createSurface","surfaceId":"main","title":"Tasks"}
{"type":"updateDataModel","surfaceId":"main","ops":[{"op":"replace","path":"/tasks","value":[{"title":"Ship demo","done":false}]}]}
{"type":"updateComponents","surfaceId":"main","components":[{"componentId":"root","type":"Column","children":["title"]},{"componentId":"title","type":"Text","props":{"content":{"path":"/tasks/0/title"}}}]}
```
将 JSONL 转换为 GUI 渲染器是其中的一部分,Canopy 可以直接与您的 LLM 提供商连接,并通过这些增量 JSONL 让 LLM 构建应用程序。
Canopy 在“反向控制模式”下支持 --claude 或 --codex 运行,启动 Claude/Codex,并将 Canopy 作为 MCP 服务器和适当的提示。
MCP 还提供了一个“截图”工具,以便 LLM 实际上可以“看到”它所构建的内容,并且显然可以与应用程序本身进行交互以进行测试。
自述文件中的图像是真实示例。
除了基本的原生组件,如输入框、滚动条、布局等,Canopy 还可以进行 - FFI 函数调用 - 自行截图 - 音频/视频捕获 - API 调用。
对于“演示”应用程序来说,它的表现还不错,但我注意到生成的应用程序中存在不同类型的“行为问题”,主要是在更复杂的应用程序的状态管理方面,这个问题会加剧。我尝试了一个“像素编辑器到 ICO 导出”的项目,编辑器部分运行良好(但用户体验几乎为零),而导出完全不工作。此时我无法得到一个可用的“SQLite 浏览器”。
但我相信这些都是提示问题/工具问题,可以通过更好的抽象(包、可重用组件)来解决。
<a href="https://github.com/artpar/canopy" rel="nofollow">https://github.com/artpar/canopy</a>
执行命令:go build -o canopy
查看原文
I came across <a href="https://a2ui.org/" rel="nofollow">https://a2ui.org/</a> a couple of months ago and decided to do an implementation as a side project<p>canopy renders jsonl files as functional and interactive native GUI<p>Here is a hello world example<p>```example.jsonl<p>{"type":"createSurface","surfaceId":"main","title":"Tasks"}<p>{"type":"updateDataModel","surfaceId":"main","ops":[ {"op":"replace","path":"/tasks","value":[{"title":"Ship demo","done":false}]}]}<p>{"type":"updateComponents","surfaceId":"main","components":[ {"componentId":"root","type":"Column","children":["title"]}, {"componentId":"title","type":"Text","props":{"content":{"path":"/tasks/0/title"}}} ]}<p>```<p>jsonl to gui renderer is one part, canopy can connect with your llm provider directly and let the llm build the app thru these incremental jsonl.<p>canopy supports --claude or --codex at run in "reverse controlled mode", starts claude/codex with canopy as an MCP server and appropriate prompt.<p>the mcp also exposes a "screenshot" tool for itself so the LLM can actually "see" whats its build. and it can obviously interact with the app itself to test it.<p>the images in the readme are real examples.<p>apart from the basic native components like input field, scroll, layouts etc, canopy can do - ffi function calls - take its own screenshot - audio/video capture - api calls<p>for "demo" apps it works okay, i notice different kind of "behavioral issues" in the generated apps though, mostly in terms of state management for more complex apps, the issue gets multiplied. i tried a "pixel editor to ico export", the editor part worked fine (0 ergonomics for the user though), the export did not work at all. i coulnt get to a usable "sqlite browser" at this point.<p>but i am sure these are prompt problems/tooling that can be fixed with better abstractions (packages, reusable components)<p><a href="https://github.com/artpar/canopy" rel="nofollow">https://github.com/artpar/canopy</a><p>go build -o canopy