最新

嗨，HN！我正在开发一个名为 Dayflow 的 macOS 应用，它可以自动跟踪你实际在做什么（不仅仅是你打开了哪些应用程序）。 以下是它的功能： - 它创建了你一天的语义时间线； - 通过理解你屏幕上的内容（使用本地或云端的 VLM）来实现这一点； - 这使你可以准确看到你的时间花在哪里，而无需手动记录。 传统的时间追踪工具告诉你“在 Chrome 上花了 3 小时”，这并没有什么帮助。Dayflow 实际上可以理解你是在阅读文档、调试代码，还是在浏览 HN。你得到的不是“Chrome: 3 小时”，而是“审阅 PR 评论: 45 分钟”、“阅读关于 Rust 的 HN 线程: 20 分钟”、“调试认证流程: 1.5 小时”。 我曾是 Rewind 的早期用户，但很少使用其检索功能。我构建 Dayflow 是因为我看到了屏幕数据的其他有趣用途。我发现它帮助我在工作时保持专注——我每隔几个小时查看一次，确保我的时间花费符合我的初衷——如果没有，我会尝试调整方向。 关于隐私，你需要知道以下几点： - 100% 本地运行，使用 qwen2.5-vl-3b（约 4GB 模型） - 不上传云端，无需账户 - 完整源代码在 MIT 许可下可用（[https://github.com/JerryZLiu/Dayflow](https://github.com/JerryZLiu/Dayflow)） - 可选：自带 Gemini API 密钥以获得更好的质量（存储在钥匙串中，提供免费层的解决方案以防止在你的数据上进行训练） 技术栈相对简单，使用 SwiftUI 和本地 sqlite 数据库。利用原生 macOS API 进行高效的屏幕捕获。由于大多数本地运行 LLM 的人已经有了自己选择的工具（如 Ollama、LLMStudio 等），我决定不将 LLM 嵌入到 Dayflow 中。 迄今为止，最大的挑战是将 SOTA 视觉模型（如 Gemini 2.5 Pro）适配到小型本地模型。我的限制是它必须占用少于 4GB 的内存并具备视觉能力。我进行了大量评估，以确定 Qwen2.5VL-3B 是大小和质量的最佳平衡，但我仍然不得不接受质量上的相当大的折衷。我还在采样率和提示分块方面进行了创造性尝试，以应对 100 倍更小的上下文窗口。处理 15 分钟的片段需要大约 32 次本地 LLM 调用，而不是 2 次 Gemini 调用！ 接下来我正在做的事情： - 蒸馏：使用 Gemini 的高质量输出作为训练数据，教会本地模型所需的模式，希望能缩小质量差距。 - 自定义仪表板，你可以跟踪任何问题的答案，比如“我在 HN 上花了多长时间？”或“距离我今天的第一次深度工作会话还有多少小时？” 我很想听听你的想法，特别是如果你在生产力追踪方面遇到过困难，或者对这种工具有什么期望。

我开发了Artifex，这是一个Python库，用于创建特定任务的语言模型（LLM），专注于自然语言处理（NLP）和文本分类，而无需训练数据。目前，支持的模型仅包括意图分类和护栏模型，但我会根据用户反馈很快添加更多功能。 我之所以制作这个库，是因为通用的语言模型对于简单的文本分类任务来说显得过于复杂，而使用LLM API的成本也会迅速增加。另一方面，为特定任务微调一个LLM需要标注数据，而并不是每个人都有这些数据。 因此，我创建了一个库，可以在没有训练数据的情况下训练小型、特定任务的LLM。您只需描述模型的行为，模型就会在为此目的生成的合成数据上进行训练。 这些模型可以在本地（无需GPU）或小型服务器上运行，能够卸载简单任务，从而减少对第三方LLM API的依赖。 我欢迎任何反馈或新模型/任务的建议。这里是GitHub仓库链接： [https://github.com/tanaos/artifex](https://github.com/tanaos/artifex)

后端API往往会发展成大型的 orchestration 类，充满了重复的调用和手动的并发处理。<p>我一直在开发 Mosaic，这是一个 Kotlin 框架，它通过小的、请求范围内的“瓦片”来组合响应。每个瓦片在每个请求中运行一次，依赖关系自动解析，独立的瓦片可以并行执行，无需额外的样板代码。<p>目前还处于早期阶段（v0.2.0），但在缓存、并发和可测试性方面已经可以使用。期待听到大家对这种方法的反馈。<p>GitHub: <a href="https:&#x2F;&#x2F;github.com&#x2F;Nick-Abbott&#x2F;Mosaic" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Nick-Abbott&#x2F;Mosaic</a> Maven Central: org.buildmosaic:mosaic-core:0.2.0

嗨，HN， 我是epress的创始人。在经历了大量的工作后，我很高兴（也有点紧张）终于能与大家分享这个项目。 多年来，我一直感觉自己在日常使用的平台上像个数字租户。我的内容、我的社交图谱、我的在线身份——这些都存储在别人的服务器上，受制于他们的规则、算法和商业模式。我可能会被取消平台资格，我的数据可能会被出售，或者我依赖的API可能会突然被放在付费墙后面。 我研究了现有的去中心化替代方案。虽然许多项目都很出色，但我发现它们往往将信任从大公司转移到了服务器管理员（在联邦模型中），或者依赖于可能不可靠的自愿中继网络，最终可能会收取费用。对第三方基础设施的根本依赖依然存在。 epress是我对此问题的尝试，基于一个简单、几乎是怀旧的原则：**真正的拥有权需要自我托管。** 这是一个去中心化的社交网络，其中： * 你运行自己的节点：你的节点是你的主权领土。所有数据都由你掌控。 * 你的以太坊地址就是你的身份：我们使用EIP-4361（以太坊登录）进行身份验证。不再需要记住用户名和密码。 * 没有第三方依赖：没有中继、没有中心节点、没有联邦服务器。内容通过节点之间的轻量“通知-拉取”协议进行点对点分发。 * 所有内容都是可验证的：每一条公开内容都经过签名，并附带“来源证明”，这是一个加密收据，证明了谁在何时发布了什么。 这个项目深受早期互联网精神的启发，但采用现代技术使自我托管再次变得可行和易于访问。 现在仍处于早期阶段，前方还有很长的路要走。为了向大家展示这不仅仅是一个演示，代码现在已经开源，我们已经有实时节点等待你来关注。官方项目博客在 [https://epress.blog](https://epress.blog)，这是一个epress节点，你也可以查看我的个人节点 [https://garbin.blog](https://garbin.blog)。 我全天候在线，回答任何问题，更重要的是，倾听你的反馈和批评。对于设置过程中的实时支持或更直接的反馈，欢迎加入我们的Telegram群组：[https://t.me/+mZMgNSIVy1MwMmVl](https://t.me/+mZMgNSIVy1MwMmVl)。 白皮书（深入了解）：[https://github.com/epressworld/epress/blob/main/docs/en/WHITEPAPER.md](https://github.com/epressworld/epress/blob/main/docs/en/WHITEPAPER.md)。 视频演示：[https://youtu.be/BB1Zn3oFDVc](https://youtu.be/BB1Zn3oFDVc)。 感谢你花时间来了解这个项目。

你好， 我们在Kibana和Prometheus中有大量的日志和指标，因此每当客户数据源出现问题时，支持团队会要求我们检查发生了什么。由于问题可能不在我们这边，开发人员开始让非技术团队访问这些工具。让非技术人员构建Grafana仪表板并进行某种调试感觉有点奇怪，但即使他们的操作有些笨拙，他们似乎还是很享受能够看到系统的情况，而开发人员也不再需要负责调试每一个小问题。 这是我们业务特有的情况吗？还是你们也有类似的经历？如果是的话，你们是如何将这些数据展示给非技术人员的？