嗨，HN，
我是一名全栈开发者（之前是iOS开发），刚刚推出了Nomad Tracker，这是一款原生iOS应用，旨在帮助数字游牧者跟踪在不同国家的实际停留时间，以便满足签证限制和税务居住要求。
主要理念：所有功能都在设备上运行。
无需注册账户，无需云同步，无需分析数据。
功能特点：
- 基于日历的按国家跟踪。
- 申根区90/180天及其他签证“跑道”。
- 财税居住天数统计及提醒。
- 可选的后台位置记录（节省电池，绝不覆盖手动输入的数据）。
- 仅通过元数据导入照片（不访问图像）。
- 设备内的“财税预言者”，使用苹果的基础模型询问关于您自己数据的问题。
我创建这个应用是因为其他应用功能有限，无法满足我的需求。这个应用注重视觉效果和用户体验，旨在使跟踪变得简单明了。
欢迎提问或讨论技术上的权衡。
返回首页
最新
新项目、重构、实验、初创企业或深夜编程——告诉我们这个月你正在构建或探索什么，以及原因。
大家好！<p>“Kiln”在您的本地机器上使用GitHub项目作为控制面板来协调Claude Code实例。<p><a href="https://kiln.bot" rel="nofollow">https://kiln.bot</a><p><a href="https://github.com/agentic-metallurgy/kiln" rel="nofollow">https://github.com/agentic-metallurgy/kiln</a><p>如果您在Gas Town规模的6-7阶段，您可能会打开3到15个终端窗口。屏幕空间不够，markdown文件堆积如山。虽然TUI和专用IDE旨在提供帮助，但它们也增加了管理的复杂性。<p>Kiln简单地轮询GitHub项目。当您将问题从一个列移动到另一个列时，Kiln会调用Claude Code CLI来运行相应的命令。<p>Claude创建工作树，研究代码库，制定并实施计划。并将其存储在GitHub Issues中。<p>这旨在保持简单，没有新东西：<p>- 使用您现有的Claude订阅（无需身份验证技巧，本地运行）<p>- 所有上下文和状态都在GitHub上（没有markdown混乱，没有本地数据库，易于恢复）<p>- 轮询而不是webhooks/事件（没有外部攻击面，能够在VPN后工作）<p>- 支持MCP和Claude能做的其他任何事情<p>这就是它的核心，它之所以有效，因为……这就是Claude :)<p>它还有一些其他小技巧，但我就不多说了。<p>附言：抱歉使用新账户，需要一个真实姓名的账户 :) 自2008年以来一直在潜水。
随着像OpenClaw这样的个人AI代理通过利用用户的私人数据变得越来越强大，隐私问题已成为一个根本性的瓶颈。<p>我们推出了HEVEC，这是一种基于同态加密的向量数据库，能够实现端到端的隐私保护，并支持大规模的实时搜索。<p>HEVEC被设计为明文向量数据库的可替代方案，支持大规模的实时加密搜索（在约187毫秒内处理100万个向量）。<p>关键点：
- 一个安全的、可替代明文向量数据库的方案
- 对数据和查询进行端到端的同态加密
- 大规模的实时加密搜索（在187毫秒内处理100万个向量）<p>随着个人AI代理变得更加个性化，数据的所有权必须归用户所有。<p>HEVEC通过隐私设计架构来强制执行这一点。<p>我们欢迎来自AI、系统和隐私社区的反馈。
嘿，HN！我上周参加了一个ATProto的聚会，作为一个对学术出版感到厌倦的半学术人士，我觉得有一个很酷的机会可以在Octopus（<a href="https://www.octopus.ac/" rel="nofollow">https://www.octopus.ac/</a>）的基础上进行开发，所以我在周末有点兴奋，构建了Octosphere。<p>希望你们中的一些人会觉得它有趣！博客文章在这里：<a href="https://andreasthinks.me/posts/octosphere/octosphere.html" rel="nofollow">https://andreasthinks.me/posts/octosphere/octosphere.html</a>
我已经是一个网络小说的读者多年了（在Royal Road上花了太多时间），我一直在思考一个问题：哪些大型语言模型（LLMs）真正能够创作出让人想要继续阅读的小说？这就是我创建Narrator的原因（<a href="https://narrator.sh/llm-leaderboard" rel="nofollow">https://narrator.sh/llm-leaderboard</a>)——一个让LLMs生成连载小说并根据真实读者的参与度进行排名的平台。
事实证明，这个问题的答案出乎意料地难以找到。创意写作并不是单一的能力，而是一个流程：头脑风暴 → 写作 → 记忆。你需要生成有趣的前提，用优美的文笔将其执行，并在长篇叙事中保持一致性。大多数基准测试都是孤立地测试这些能力，但读者体验的是一个整体。
当前的评估环境是支离破碎的：
像FictionLive的记忆基准测试使用选择题来检查模型是否能在长上下文中记住情节细节。这是有用的，但记忆只是良好小说所必需的条件，而不是充分条件。一个模型可能在回忆方面表现出色，但仍然写出无聊的故事。
来自Novelcrafter等工具的作者使用数据表明了作家们偏好的模型作为副驾驶。但这只衡量了人类与AI合作时的实用性，而不是产生引人入胜的独立作品。作者和读者的需求是不同的。
将LLM作为评判者是评估散文质量的最常见方法，但在创意作品中却 notoriously 不可靠。模型存在系统性偏见（偏好冗长的文风、某些结构），而“好写作”在某种程度上是主观的，这与“正确的代码”截然不同。
缺少的是一个从读者角度出发的定量基准——一种衡量真实人类是否真正享受这些模型所创作内容的工具。这正是Narrator所填补的空白：浏览量、阅读时间、评分、书签、评论、回访次数。可以把它看作是一个“AI Wattpad”，其中模型就是作者。
五个月前，我在这里分享了一个基于DSPy的早期版本（<a href="https://news.ycombinator.com/item?id=44903265">https://news.ycombinator.com/item?id=44903265</a>）。最大的教训是：一次性生成不适合长篇小说。模型会丢失情节线索、忘记角色，且章节之间的质量会下降。
重写：从一次性生成到持久的代理循环
当前版本通过一个写作工具对每个模型进行处理，保持章节之间的状态。在生成之前，代理会审查结构化的上下文：角色表、情节大纲、未解决的线索、世界构建笔记。在生成之后，它会更新这些文档以便于下一章使用。基本上，每个模型都获得一个贯穿整个故事的“作家笔记本”。
这带来了可衡量的差异——在一次性版本中挣扎的模型在获得自己笔记的情况下显著改善了一致性。
细粒度过滤而不是单一评分：
我们在前期对故事进行分类，包括语言、类型、标签和内容评级。我们不再只有一个“创意写作”排行榜，而是可以深入具体：哪个模型写的西班牙喜剧最好？哪个模型对男性主角的LitRPG故事处理得最好？哪个在浪漫与恐怖之间表现更佳？
答案并不总是符合你对一般基准的预期。有些模型在整体排名中处于中游，但在特定细分领域中却表现出色。
我为几个功能感到自豪：
故事分叉让读者可以以选择你自己的冒险（CYOA）的方式分支故事——如果你不喜欢情节的发展，可以分叉看看同一模型如何处理不同的情节。这创造了自然的A/B比较。
视觉化的LitRPG是我个人想要解决的问题。与其用一堆[STR: 15 → 16]的文本，不如将统计数据和技能树呈现为实际的用户界面元素。例如：<a href="https://narrator.sh/novel/beware-the-starter-pet/chapter/1" rel="nofollow">https://narrator.sh/novel/beware-the-starter-pet/chapter/1</a>
我在寻找的：
更多的读者来扩展参与数据。同时也想知道是否有其他人在进行长篇LLM生成时发现了更好的模式来保持章节之间的一致性——代理工具的方法有效，但我相信还有改进的空间。
4todo 让您通过多工作区的艾森豪威尔矩阵来管理优先事项。
区分不同的上下文，减少干扰，专注于重要的事情。