最新

大家好，我是 Unlayer 的联合创始人 Adeel 和 Umair。我们让您可以在应用程序中添加内容创建功能，而无需自行构建完整的编辑器、渲染器、模板和导出堆栈。Unlayer 允许您在应用程序内以三种不同的方式创建电子邮件、网页和文档：通过代码、可视化方式或 AI。 演示视频：[https://www.youtube.com/watch?v=0HsDtNkdMpM](https://www.youtube.com/watch?v=0HsDtNkdMpM) 我们最初推出的是一个可嵌入的电子邮件编辑器，因为许多产品最终都需要它：CRM、营销工具、客户互动平台、市场、内部工具和垂直 SaaS 应用都会在某个时候遇到这个问题。起初，这似乎是一个小功能：“只需”添加一个拖放编辑器。但实际上，这会变成一个大麻烦。您将不得不处理电子邮件渲染、Outlook 的特殊性、响应式布局、模板、合并标签、图片上传、导出、权限、本地化、版本控制以及与核心产品无关的长尾边缘情况。 随着时间的推移，我们发现电子邮件之外也存在同样的问题。应用程序还需要登陆页面、发票、提案、报告、合同和 PDF。其中一些内容最好由最终用户通过可视化方式创建。一些内容最好由开发人员通过代码生成。越来越多的内容也由 AI 代理生成。许多团队最终需要所有这三种工作流程。这就是我们通过 Unlayer 一直努力的方向。 今天我们展示三个部分： (1) **Unlayer Elements**。这是我们的开源 React 组件库，用于通过代码创建电子邮件、页面和文档（仓库：[https://github.com/unlayer/elements](https://github.com/unlayer/elements)，更多信息请访问：[https://unlayer.com/elements](https://unlayer.com/elements)）。开发人员无需手动编写原始 HTML 模板，而是可以使用 React 组件来组合内容，重用页眉、页脚、CTA、发票行和品牌区块等部分，将模板保存在 Git 中，并将其渲染为生产输出。 我们看到的一个较新的用例是 AI 辅助内容创建。如果要求 AI 代理创建电子邮件、发票、报告或登陆页面，其输出通常是难以维护的原始 HTML 或 Markdown。通过 Elements，代理可以生成结构化的 React 组件。开发人员可以审查结果，进行重构，将其保存在 Git 中，如果以后有人需要编辑，仍然可以将设计传递给可视化构建器。 (2) **Visual Builder**。这是一个拖放编辑器（仓库：[https://github.com/unlayer/react-email-editor](https://github.com/unlayer/react-email-editor)，更多信息请访问：[https://unlayer.com/email-builder](https://unlayer.com/email-builder)），可以嵌入到应用程序中，让非技术用户创建或编辑内容。在演示中，我们展示了电子邮件构建器和构建器内的 AI 助手。目标不是取代开发人员的工作流程，而是当营销人员、管理员、客户或内部团队需要自己进行更改时，将其与可视化工作流程连接起来。 (3) **Document Builder**。这适用于结构化文档，如提案、报告、发票、合同和 PDF。我们看到许多团队为电子邮件模板、网页和文档生成构建了独立的系统，尽管底层原语是相似的：布局、内容块、变量、资产、预览、导出和权限。更多信息：[https://unlayer.com/document-builder](https://unlayer.com/document-builder) 技术挑战在于使这些工作流程共享一个通用基础。开发人员应该能够在代码中构建模板（当这有意义时）。最终用户应该能够在可视化方式下进行编辑（当这有意义时）。AI 代理应该能够生成结构化内容，而不是难以维护的杂乱代码。最终输出仍应被宿主应用程序使用。 我们通过向将此嵌入其产品的公司销售托管构建器、模板、导出和平台功能来盈利。Elements 是开源的。商业产品是围绕构建器、协作、存储、导出和生产用例的更广泛的托管平台。 我们是 W22 的一员，所以这是迟来的 Launch HN。当时，Unlayer 是一个可嵌入的电子邮件编辑器，我们认为还没有一个足够广泛的故事来吸引 HN。从那时起，该产品已扩展为更通用的内容创建层，包括电子邮件、页面、文档、API、开源开发人员项目和 AI 辅助工作流程。现在感觉是时候将其带到 HN 并征求反馈了。 我们非常希望听到 HN 的想法。这是一个很多人都有强烈意见的领域，因为他们之前被编辑器、电子邮件 HTML、文档编辑或“简单”的内容工作流程所困扰。我们很想听听哪些方面引起了您的共鸣，哪些听起来不对，以及您认为我们应该更深入地思考哪些问题！

各位 HN 的朋友们， 我们创建 Selzix (https://selzix.com) 的目的是为了消除社交优先品牌创建电商商店的阻力。

最近，我遇到过代理选择错误技能或工具的情况。这种情况往往发生在较长的推理链中间，令人沮丧的是，这意味着在发出纠正之前，大量的对话会污染上下文。 为了解决这些问题，我构建了 `drskill`：一个命令行工具，用于检查代理的技能和 MCP 配置中的冲突和安全问题。 除了发现可能导致代理出错的冲突外，还增加了安全警报。MCP 提供商是否因供应链攻击而悄悄添加了工具？在启动或 CI 过程中运行 `drskill` 将会标记这些更改。 `drskill` 在不访问 LLM 的情况下也能工作，但连接到 LLM 可以提供更好的冲突报告，并允许建议替代的、不冲突的描述符。 全局和本地都会维护一个账本，跟踪确认和偏好。 这类工具非常受益于贡献（你的配置和我大不相同！），所以如果你有兴趣，请提交 issue 或 PR。

雇主们正面临着日益增长的自动化人工智能提交、虚假申请和低质量垃圾邮件的浪潮。招聘人员和招聘经理在发布职位后几小时内收到数千份简历并不罕见。合格的候选人很容易被所有这些噪音淹没。 Permanym 在申请流程中引入了恰到好处的阻力，使得自动化滥用变得不切实际，同时又不会过多地阻碍合法申请人。作为一名曾经的招聘经理，增加招聘难度而不是减轻它的想法违背了我的一切本能，但目前的状况是不可持续的，并且会损害各方的信任。 核心理念是通过视频活体检测来确保申请提交时键盘后面是真人。此验证从开始到结束可在 30 秒内完成。您可以在此处体验：https://permanym.com/verify/jJAiul58nF7kJ5FS/ 无需集成 ATS。只需在您的申请说明中包含验证链接即可开始。然后通过电子邮件查找申请人，查看他们是否已通过验证。目前的主要好处是过滤垃圾邮件，但未来通过适当的 ATS 集成可以从源头阻止它。活体数据仅对招聘公司可见，且访问权限有时限。 我认为在更深入的 ATS 集成和附加信号方面存在许多机会，但我希望从解决最紧迫的问题开始：验证每份申请都来自真实的人。最终目标是通过排除不良行为者来帮助招聘过程的双方。如果这个目标引起您的共鸣，让我们聊聊！ 在此期间，我们非常感谢您提出的任何和所有反馈。

我是我朋友和我一起写的一篇论文的作者。我们之所以写这篇论文，是因为我们很好奇是否可以使用 MUD（一种起源于 20 世纪 70 年代的文本游戏）来评估大型语言模型（LLM）。在过去的几个月里，我们利用业余时间，仅用个人电脑和大约 99 美元的 API 积分完成了这项实验并撰写了论文。 我们的实验确实有一个有趣的排行榜，但更令人惊讶的是对每个大型语言模型的测量结果。我们在四个行为维度上对每个模型进行了评分，其中两个维度严重依赖于一个大型语言模型分类器。当我们移除这两个维度后，一个前沿模型下降了六个名次。当我们用第二个裁判来检查分类器时，它们之间的每模型一致性从 85% 到 22% 不等。聚合 Kappa 值（在探针检测上为 0.04）表明该工具存在噪声，但并未指明噪声影响了哪些模型。受影响最大的模型与分类器属于同一模型家族。这并非偏见的证据，只是我们记录的一项观察结果。 我们意识到大型语言模型作为裁判可能不可靠，虽然测试这一点并非我们最初的意图，但它最终成为了最有趣的发现。两个裁判之间的分歧是我们认为可以推广到其他基于裁判的基准测试的发现。 我们强调这只是一个概念验证，而不是一个经过验证的基准测试。我们在论文中准备了一个详尽的局限性部分，包括每个模型仅运行 50 次、顶尖模型之间置信区间重叠、没有人类评分者、环境规模小等。 我们所做的一切都是公开的，论文和数据采用 CC BY 4.0 许可，代码采用 MIT 许可。论文、对话记录、代码和完整的 API 账单导出可以在 [https://doi.org/10.5281/zenodo.21386663](https://doi.org/10.5281/zenodo.21386663) 找到。 如果您发现任何问题，请告知我们，这也是我们分享这些内容的原因。我们目前正在设计第二阶段，并希望使其尽可能健壮。我们正在考虑引入人类基线、多个裁判、更多目标、更大的环境等。