最新

Hi HN， 我是一名全栈开发者（之前是 iOS 开发者），刚刚发布了 Nomad Tracker，这是一款原生 iOS 应用，旨在帮助数字游民追踪在不同国家的实际停留时间，以满足签证限制和税务居留要求。 核心理念：所有数据都在设备端运行。 无需账户，无云端同步，无数据分析。 功能： - 基于日历的国家/地区停留时间追踪。 - 申根签证 90/180 天和其他签证的“停留期”计算。 - 税务居留天数统计和提醒。 - 可选的后台位置记录（省电，绝不覆盖手动输入的数据）。 - 仅使用元数据导入照片（不访问图像内容）。 - 使用苹果基础模型，在设备端提供“税务先知”功能，可以就您自己的数据提问。 我开发这款应用是因为其他同类应用感觉限制太多，无法满足我的需求。这款应用注重视觉效果，以用户为中心，旨在让追踪变得简单明了。 欢迎提问或讨论技术权衡。

Hi HN， 我一直在开发一个名为 Whilst 的小型写作工具。 它是一个网页写作空间，旨在让你专注于写作本身。人们用它来写日记、发照片、写文章，以及搭建简单的个人主页。 你只需一个电子邮件地址即可开始写作。 它是免费使用的。 链接：<a href="https:&#x2F;&#x2F;whilst.app" rel="nofollow">https:&#x2F;&#x2F;whilst.app</a> 欢迎提问！

新项目、重构、实验、创业，或者深夜的编程小玩意——告诉我们你这个月在构建或探索什么，以及原因。

大家好！ “Kiln” 在你的本地机器上编排 Claude Code 实例，使用 GitHub 项目作为其控制面板。 <p><a href="https:&#x2F;&#x2F;kiln.bot" rel="nofollow">https:&#x2F;&#x2F;kiln.bot</a></p> <p><a href="https:&#x2F;&#x2F;github.com&#x2F;agentic-metallurgy&#x2F;kiln" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;agentic-metallurgy&#x2F;kiln</a></p> 如果你在“Gas Town”规模的第 6-7 阶段左右，你可能已经打开了 3-15 个终端窗口。你的屏幕空间不够用，而且 Markdown 文件堆积如山。虽然有 TUI 和专门的 IDE 可以提供帮助，但它们却增加了需要管理的东西。 Kiln 只是简单地轮询 GitHub 项目。当你将问题从一列移动到另一列时，Kiln 会调用 Claude Code CLI 来运行相应的 /command。 Claude 创建工作树，研究代码库，创建并执行计划。将其存储在 GitHub Issues 中。 它的设计很简单，没有什么新东西： - 使用你现有的 Claude 订阅（没有身份验证技巧，在本地运行） - 所有上下文和状态都在 GitHub 上（没有 Markdown 混乱，没有本地数据库，易于恢复） - 轮询而不是 Webhook/事件（没有外部攻击面，在 VPN 后面工作） - 支持 MCP 和 Claude 可以做的任何事情 这就是它的核心，并且它有效，因为……它只是 Claude :) 它还有一些其他的技巧，但我会简短地介绍一下。 ps：对不起，用了新账号，需要一个真实的名字 :) 从 2008 年就开始潜水了。

随着像 OpenClaw 这样的个人 AI 助手通过利用用户的私密数据变得越来越强大，隐私已成为一个根本性的瓶颈。<p>我们发布了 HEVEC，这是一个基于同态加密构建的向量数据库，实现了端到端的隐私保护，并支持大规模实时搜索。<p>HEVEC 被设计成明文向量数据库的即插即用替代方案，并支持大规模实时加密搜索（100 万个向量，约 187 毫秒）。<p>要点： - 安全的、即插即用的明文向量数据库替代方案 - 针对数据和查询的端到端同态加密 - 大规模实时加密搜索（100 万个向量，187 毫秒）<p>随着个人 AI 助手变得高度个性化，数据所有权必须归用户所有。<p>HEVEC 通过隐私设计架构来实现这一点。<p>我们欢迎来自 AI、系统和隐私社区的反馈。

嘿，HN！我上周参加了一个 ATProto 聚会，作为一个对学术出版深恶痛绝的、身心俱疲的半个学者，我觉得这可能是一个基于 Octopus（<a href="https://www.octopus.ac/" rel="nofollow">https://www.octopus.ac/</a>）构建一些有趣东西的机会，所以我周末有点兴奋，并构建了 Octosphere。 希望你们中的一些人觉得它有趣！博客文章在这里：<a href="https://andreasthinks.me/posts/octosphere/octosphere.html" rel="nofollow">https://andreasthinks.me/posts/octosphere/octosphere.html</a>

我多年来一直是网络小说读者（在 Royal Road 上花费了太多时间），并且一直遇到同样的问题：哪些 LLM 真正创作出人们想一直阅读的小说？这就是我构建 Narrator（<https://narrator.sh/llm-leaderboard）的原因——一个 LLM 生成连载小说并根据真实读者参与度进行排名的平台。 事实证明，这个问题出乎意料地难以回答。创意写作并非单一能力，而是一个流程：头脑风暴 → 写作 → 记忆。你需要生成有趣的设定，用优美的文笔来执行它们，并在长篇叙事中保持一致性。大多数基准测试分别测试这些方面，但读者会将它们作为一个整体来体验。 目前的评估格局是分散的： 像 FictionLive 的测试这样的记忆力基准测试使用多项选择题来检查模型是否记住了长篇上下文中的情节细节。这很有用，但记忆力是写好小说的必要条件，而不是充分条件。一个模型可以轻松通过回忆测试，但仍然写出无聊的故事。 来自 Novelcrafter 等工具的作者端使用数据表明，作家更喜欢哪些模型作为副驾驶。但这衡量的是对人机协作有用的东西，而不是产生引人入胜的独立输出。作者和读者有不同的需求。 LLM 作为评判者是评估写作质量最常见的方法，但它在创意作品方面是出了名的不可靠。模型存在系统性偏差（偏爱冗长的文笔、某些结构），而“好的写作”在某种程度上是主观的，这与“正确的代码”不同。 缺少的是一个读者端的定量基准——衡量真实人类是否真的喜欢阅读这些模型产生的内容。这正是 Narrator 填补的空白：浏览量、阅读时间、评分、书签、评论、回访。可以把它想象成一个“AI 版 Wattpad”，其中模型是作者。 我 5 个月前在这里分享了一个基于 DSPy 的早期版本（<https://news.ycombinator.com/item?id=44903265）。最大的教训是：单次生成不适用于长篇小说。模型会丢失情节线索，忘记角色，并且质量会随着章节的推移而下降。 重写：从单次生成到持久的代理循环 当前版本通过一个写作工具运行每个模型，该工具在各章节中保持状态。在生成之前，代理会查看结构化的上下文：人物设定、情节大纲、未解决的线索、世界构建笔记。在生成之后，它会更新这些工件以用于下一章。本质上，每个模型都获得了一个“作家的笔记本”，该笔记本贯穿整个故事。 这带来了可衡量的差异——在单次生成版本中难以保持一致性的模型，在能够访问自己的笔记后，有了显著的改进。 细粒度过滤而不是单一分数： 我们预先按语言、类型、标签和内容分级对故事进行分类。我们没有一个“创意写作”排行榜，而是可以深入研究具体内容：哪个模型写得最好的西班牙喜剧？哪个模型最擅长处理以男性为主角的 LitRPG 故事？哪个模型在浪漫与恐怖方面表现出色？ 答案并不总是你从一般基准测试中期望的那样。一些整体排名中等的模型在特定领域占据主导地位。 我引以为豪的几个功能： 故事分叉允许读者以 CYOA（选择你自己的冒险）风格分支故事——如果你不喜欢情节的发展方向，可以分叉它，看看同一个模型如何处理这种分歧。创建自然的 A/B 比较。 视觉 LitRPG 是一个我个人想解决的问题。统计数据和技能树呈现为实际的 UI 元素，而不是一堆 [STR: 15 → 16] 文本。示例：<https://narrator.sh/novel/beware-the-starter-pet/chapter/1> 我正在寻找： 更多的读者来构建参与度数据。也很好奇是否有其他人在研究长篇 LLM 生成方面的人发现了更好的模式来保持各章节之间的一致性——代理工具方法有效，但我相信会有改进。