最新

我原以为这是一个讽刺的说法，用来形容那些依赖生成式人工智能来构建事物的人，当事情出错时，他们除了写更多提示词之外无能为力。<p>但我刚看到一个二十多岁的人在炫耀他如何将其与粘土结合，创造个性化的应用程序。

嗨，HN， 我是Kiet，Onlook团队的另一位成员。我们正在开发一个开源的[Onlook](https://github.com/onlook-dev/onlook)可视化编辑器，允许您在无限画布上实时编辑和创建React应用。 我们几乎在一年前以本地优先的Electron应用形式推出了Onlook。自那时以来，“提示生成”工具迅速崛起，但没有一个工具能够让您以可视化的方式进行设计和迭代。我们通过采用以视觉为主、AI驱动的方法解决了这个问题，您可以像在设计工具中一样提示、样式化和直接操作应用中的元素。 两个月前，我们决定放弃Electron，并将所有内容重写为浏览器应用。我们希望消除下载数百MB并设置开发环境的麻烦，只为使用这个应用。我在这里写了更多关于我们如何做到的内容，但以下是整个迁移过程中的一些经验教训： 1. 尽管大部分React UI代码可以重用，但将Electron的单页面应用体验映射到带路由的Next.js应用在状态管理方面并非易事。 2. 我们之前将大部分数据作为大型JSON对象存储在本地。将其迁移到远程数据库需要进行重大重构，转变为表格和更多的加载状态。之前我们不需要过多考虑查询和加载时间。 3. 浏览器中的iframe比Electron的webview施加了更多限制。解决这个问题需要我们直接向用户项目中注入代码，以便进行跨iframe通信。 4. 在Web应用中保持API密钥的安全性比在Electron应用中容易得多。在Electron中，我们留在客户端的每个密钥都可以被静态访问。因此，我们必须将任何需要API密钥的SDK代理到服务器调用。在Web应用中，我们只需将密钥保留在服务器上。 5. 在Electron中推送发布包可能需要1小时以上的时间。而且某些用户可能永远不会更新。如果我们在自动更新程序本身中有一个bug，某些用户可能会“被困”在旧版本中，我们不得不通过电子邮件联系他们进行更新。尽管这仍然比通过应用商店的移动应用要好，但用户体验仍然很差。 Onlook的Web版是如何工作的？ 我们首先连接到一个远程“沙箱”。可视化编辑组件通过iframe进行。我们将iframe中的HTML元素映射到代码中的位置。然后，当进行编辑时，我们在iframe上模拟更改，并同时编辑代码。这样，视觉变化总是感觉瞬时。 虽然我们仍在完善体验，但您已经可以： - 选择元素并提示更改 - 通过样式UI更新TailwindCSS类 - 绘制新的div和元素 - 在多个屏幕尺寸上预览 - 通过浏览器内的IDE编辑代码 我们希望让任何人都能轻松创建、样式化和编辑代码库。我们仍在将桌面应用中的功能迁移过来——图层、字体、托管、git等。一旦完成，我们计划添加对后端功能的支持，例如身份验证、数据库和API调用。 特别感谢70多位为Onlook体验做出贡献的开发者！我认为在设计和开发工作流程中仍有许多问题需要解决，而我认为技术几乎已经到位。 您可以从我们的代码库（链接在此帖子中）克隆项目并运行，或者在[https://beta.onlook.com](https://beta.onlook.com)上免费试用。 我很想听听您的想法，以及我们接下来应该朝哪个方向发展 :) [1] [https://news.ycombinator.com/item?id=41390449](https://news.ycombinator.com/item?id=41390449) [2] [https://news.ycombinator.com/item?id=40904862](https://news.ycombinator.com/item?id=40904862) [3] [https://docs.onlook.com/docs/developer/electron-to-web-migration](https://docs.onlook.com/docs/developer/electron-to-web-migration) [4] 目前，沙箱是通过CodeSandbox实现的，但我们计划增加支持连接到本地运行的服务器。

请访问以下链接： [https://xcancel.com/keenanisalive/status/1925225500659658999](https://xcancel.com/keenanisalive/status/1925225500659658999)

也许这样做是为了鼓励软件工程师理解人工智能编写的代码？