最新

我意识到，相比当下 Hacker News 上的热门内容，我对 Hacker News 历史上的热门内容更感兴趣。<p>为了更好地追踪我已阅读过的帖子，我开发了一个小型 Web 应用，它会按受欢迎程度显示所有帖子，并允许我勾选已读或保存以备后用。

在一些大型行业中，迁移出 VMware 的紧迫性似乎比进行生成式 AI 还要高。<p>其他人也有这种感觉吗？如果是，你们认为人们有哪些选择可以保留服务器但又摆脱 VMware？都是 RedHat 吗？

嘿，HN — 我是 David，我开发了 Photerra，旨在解决我一直遇到的一个问题：规划旅行意味着要同时处理几十个浏览器标签页、Google 表格，以及大家都在看的那些千篇一律的“十大”列表。<p>Photerra 将带有地理位置信息的照片转化为地图上的地点，你可以将这些地点组织成旅行，与朋友分享，并直接预订——所有这些都在一个流程中完成。<p>核心理念：带有 GPS 信息的照片 → 地图上的实际地点 → 拖拽到旅行的每一天 → 分享 → 预订。<p>Photerra 的与众不同之处： • 真实的地点，不仅仅是兴趣点——你的照片有 EXIF GPS 数据，所以你添加的是确切的地点（步道上的实际位置，而不仅仅是“优胜美地”——不需要地址） • 端到端流程——发现 → 规划 → 协调 → 预订，无需在 5 个应用程序之间切换 • 基于照片的数据——社区地点来自真实的照片，而不是抓取的列表，因此你可以找到更多小众地点 • 适用于日常漫游——不仅仅是大型旅行。保存本地地点，一键在地图或 Uber 中打开<p>试用一下：iOS 和 Android 应用程序已上线（链接在评论中）。我已经为旧金山、波特兰、洛杉矶、圣地亚哥、夏威夷、费城、优胜美地和墨西哥城添加了内容。<p>技术：React Native + RN-Maps 用于移动端；NestJS + TypeORM/MySQL + AWS 用于后端。<p>我希望得到的反馈： • 照片→地点→旅行的流程在首次使用时是否直观？ • 缺少什么才能让它真正成为你旅行的完整解决方案？ • 在身份验证、地图或分享方面有任何摩擦吗？<p>请直言不讳——这很有帮助。很乐意回答问题！<p>— David（单人，首次创业者）

嘿，HN！ 上周，Joe Barrow 发布了 CommonForms [1]，这是一套用于自动检测 PDF 文件中表单字段的开放模型。 他使用一个包含 55000 份文档的数据集训练了两个模型，FFDNet-S 和 FFDNet-L。你可以在 arXiv 论文 [2] 中阅读更多关于他的方法。 作为一直在寻找可靠模型来自动检测表单字段（PDF 表单填写中最后一个难题之一）的人，我对这些模型的质量印象深刻。我想给它们应有的关注和传播，所以我创建了一个完全基于浏览器的实现，可以处理检测和字段添加。 我的实现依赖于他的模型以及 onnx runtime web + 一些后处理。我计划在未来几天发布一个小的浏览器库来封装它，以便更容易地部署到任何地方（目前你必须 fork / 复制我的代码）。 很乐意回答关于基于浏览器的实现的任何问题！ 关于模型本身的问题应该直接向 Joe 提问，我相信他也在 HN 上 [3]。 [1] <a href="https:&#x2F;&#x2F;github.com&#x2F;jbarrow&#x2F;commonforms" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jbarrow&#x2F;commonforms</a> [2] <a href="https:&#x2F;&#x2F;arxiv.org&#x2F;abs&#x2F;2509.16506" rel="nofollow">https:&#x2F;&#x2F;arxiv.org&#x2F;abs&#x2F;2509.16506</a> [3] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;user?id=jbarrow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;user?id=jbarrow</a>

我开发 Moonfish 是因为我通勤时间很长，而且一直想听一些关于冷门话题的播客，但这类播客一直没有出现。<p>它就像 OpenAI 深度研究和 Google NotebookLM 的结合体——它在网络上搜索资料来源，整合信息，然后创建由两位 AI 主持人主持的对话式播客。<p>它非常灵活。你首先创建一个节目，然后向其中添加剧集。在节目级别设置语调（“用初学者能理解的方式解释”或“用 xxx 语言创建播客”），然后提示单个剧集。<p>创建一集大约需要 3-5 分钟，目前每集时长约为 15 分钟（我正在努力将其延长到一小时 :)）<p>其底层由三个主要代理组成——一个代理搜索并收集资料来源，另一个代理构建叙事结构，第三个代理编写自然的对话。该架构简单但非常有效，并且随着新模型的发布具有可扩展性。<p>iOS 应用：<a href="https:&#x2F;&#x2F;apps.apple.com&#x2F;us&#x2F;app&#x2F;moonfish-ai&#x2F;id6748574770">https:&#x2F;&#x2F;apps.apple.com&#x2F;us&#x2F;app&#x2F;moonfish-ai&#x2F;id6748574770</a> 很想听听大家的反馈！

您好， 我正在为我未来的 GH 服务开发一个入职流程。我认为如果用户在 AI 聊天的帮助下充实他们的入职回复，将有助于提高入职回答的质量。但是，AI 聊天没有集成到 Web 应用程序的任何其他部分，这意味着我必须专门为入职流程构建整个聊天界面——这似乎非常浪费时间。 我考虑过，不如允许用户将代理/系统提示复制到他们选择的 LLM 聊天应用程序中，然后在代理确定其质量足够高时再完成入职流程。 这时，我很惊讶地发现，没有用于 LLM 的 `mailto://` 类型的 URI 方案。或者至少我不知道有。 我考虑过类似这样的方案： ``` llm://[最小模型生成]?subject=....&prompt=......&schema=[base64 编码的模式输出] ``` 例如： ``` # 完整链接示例在链接的 gist [0] 中 llm://>2024?subject=Yocto.is%20Onboarding%20Helper%20Agent&prompt=... ``` 第一部分也可以选择一个特定的模型 例如： ``` # 特定模型 llm://gemini-2.5-pro?... # 特定提供商，最小模型 llm://>=gemini-2.5-pro?... # 特定提供商，大于模型 llm://>gemini-2.5-pro?... ``` 谢谢 等等。 [0]: https://gist.github.com/smashah/f6192d7af114ca059b3a47b33ec1df18