2025-11-06 23:07:05
MacOS 极简音乐播放器，有点像早期的 Vox
https://github.com/jaywcjlove/musicer
GitHub
GitHub - jaywcjlove/musicer: Musicer is a mini and convenient local music player, lightweight and practical, specially designed…Musicer is a mini and convenient local music player, lightweight and practical, specially designed for playing local audio, supports a variety of common audio formats, enjoy your music anytime, any...
2025-11-05 16:04:23
一个新的 TypeScript Web Framework
https://elysiajs.com/
Elysiajs
Elysia - Ergonomic Framework for HumansElysia is an ergonomic framework for Humans. With end-to-end type safety and great developer experience. Elysia is familiar, fast, and has first-class TypeScript support with well-thought integration between services whether it's tRPC, Swagger or WebSocket.…
2025-11-05 12:19:28
“凭借盗版软件的肆虐” 今日最佳
https://mp.weixin.qq.com/s/-8cDeIsyjuZa3FzCMBfPNQ
2025-11-05 11:33:45
一直以来都觉得，除非你对 LLM 请求所需的上下文和调用流程有非常清晰思考，并且希望它严格按照你的设想运作，否则就不要使用 API 客户端，而应该去用 App（例如 Gemini 和 ChatGPT）。
App 针对通用问题的调优和 edge case 的处理能力，是 API 客户端无法匹敌的。
比如一个最简单的场景：搜索概念并进行讲解。如果使用 API 客户端，你可能会遇到：
- Search 或 Fetch 工具调用失败（例如，返回结果过长）。
- 获取的信息太多，导致 Token 长度超出 LLM API 的限制。
- 缺少 RAG 技术的筛选或重排，导致结果不精确。
- 速度慢且不稳定。而在 App 中，请求一旦发出，后台任务便会保证对话持续运行，即使关闭 App 也不影响最终结果。
所以总的来说，对于一般的问题回答，使用 API 客户端不仅需要花费大量时间配置、调试，而且仍然难以保证稳定、快速地获得好结果。使用 App 才是最好的选择。
而对于那些需要控制执行过程、数据，以及使用自定义工具的特定需求，API 客户端才能发挥其优势。
2025-11-05 09:37:56
看到这行绷不住了。开发 Python 十多年，我也没敢在正式项目里深度使用 async，现在也还是 gunicorn 或 uwsgi 跑多 worker 模式。坏处是性能确实一般，好处是无论开发过程还是运行都非常稳。 https://blog.yakkomajuri.com/blog/python-to-node
HN 关于这篇文章的讨论里有人在安利 Elixir, 说实话有点心动哦，而且我记得 fly.io 就是用 Elixir 开发的，还有一些社区的核心人物在那边（有点像 Basecamp 和 RoR 的关系）。所以 Elixir 作为一个有商业公司作为背景的语言，发展也比较与时俱进，没有道理在做异步架构项目选型的时候被忽略掉。
https://news.ycombinator.com/item?id=45801803
2025-11-05 08:57:29
Anthropic 最近应该是吃太饱了，又开始送这种带限定条件的 credits，你有本事把 Max plan 的限制放宽呀
