最新

云端人工智能的定价是按令牌计费的。你的工作流程越有用，成本就越高。我构建了一种双模型编排模式，将80%的工作分配给一个免费的本地模型（Ollama上的Qwen3 8B，支持GPU加速），仅将合成/判断阶段发送到云API。 一个包含50项研究的工作流程成本为0.15-0.40美元，而全云方案则为8-15美元。在重要的输出质量上，两者相同。 技术栈：RTX 5080笔记本，使用Docker的Ollama（支持GPU直通），PostgreSQL，Redis，以及用于最后20%的Claude API。 工作模式：本地扫描 → 本地评分 → 本地去重 → 通过云合成。四个阶段中，有三个是免费的。 遇到的问题：Qwen3通过/api/generate的思考令牌（应使用/api/chat），Docker绑定仅支持IPv4，而Windows将localhost解析为IPv6，以及消费级显卡的GPU内存限制。 欢迎在评论中分享架构细节。

我发现了一种工作流程，使Claude成为全栈网页开发中大部分工作的绝佳助手。然而，我认为界面开发和用户体验是限制生产力潜力的最重要因素。我很想听听大家是否有相关经验，或者找到过好的解决方法？

嗨，HN， 我构建了 llm-use：一个轻量级的 Python 工具包，用于高效的多 LLM 代理工作流程。 核心模式：使用强大的模型（Claude/GPT-4o/大本地模型）进行规划和综合；使用廉价/本地的工作者处理并行子任务（研究、抓取、总结、提取等）。 功能： • 混合使用 Anthropic、OpenAI、Ollama 和 llama.cpp • 智能路由器：优先使用廉价/本地工作者，仅在必要时升级（基于学习和启发式） • 并行工作者（–max-workers） • 实时抓取 + 缓存（BS4 或 Playwright） • 离线优先（完全支持 Ollama） • 成本跟踪（云端费用，0 本地费用） • TUI 聊天 + MCP 服务器模式 • 本地会话日志 快速示例（混合模式）： ```bash python3 cli.py exec \ --orchestrator anthropic:claude-3-7-sonnet-20250219 \ --worker ollama:llama3.1:8b \ --enable-scrape \ --task "总结 6 个关于后量子密码学的最新来源" ``` 或路由版本： ```bash python3 cli.py exec \ --router ollama:llama3.1:8b \ --orchestrator openai:o1 \ --worker gpt-4o-mini \ --task "解释最近的 macOS 安全更新" ``` 采用 MIT 许可证，依赖最小，可嵌入。 仓库链接： [https://github.com/llm-use/llm-use](https://github.com/llm-use/llm-use) 欢迎反馈： • 您认为有用的路由启发式 • 关于代理成本/本地与云的痛点 • 缺失的集成？ 谢谢！

对于每个视频，你通过在一个二维平面上投点来猜测其他人的反应：Y轴代表与内容的共鸣程度，X轴代表对这种共鸣的确定性。<p>你的猜测越接近人群不断演变的共识（该共识本身是基于其他人的猜测），你的得分就越高。这些得分会汇总成你的直觉水平——一个可以用来比较内容消费者的指标。<p>这个想法是将当前社交媒体的被动滚动状态转变为一个预测游戏，让用户通过预测能力而非仅仅内容创作来竞争社会资本。

嗨，HN， 我是一名位于格鲁吉亚第比利斯的独立开发者，过去几个月一直在构建SnapAPI。它是一个REST API，提供四项功能：截图、PDF生成、视频录制和从网页中提取结构化数据。 *我为什么要构建它：* 我在一个需要链接预览的项目上工作。我尝试自托管Playwright——它可以工作，但管理浏览器上下文、内存泄漏、Cookie横幅和崩溃恢复的工作量出乎我的意料，原本应该是一个简单的任务。现有的API（如ScreenshotOne和Urlbox）虽然可靠，但价格昂贵且分散——你需要为截图和数据提取分别使用不同的服务。 *架构：* - *Fastify* 处理API层。由于其模式验证功能（我将其作为请求验证的唯一真实来源）和在负载下约2倍的吞吐量差异，我选择了它而不是Express。 - *Playwright* 而非Puppeteer。对于这个用例，跨浏览器支持并不重要，但Playwright的`browser.newContext()`隔离和内置的自动等待在捕获页面时更可靠。 - *BullMQ + Redis* 用于作业队列。截图请求进入队列，单独的工作进程处理它们。这将API与繁重的渲染工作解耦，并让我可以设置每个请求的超时而不阻塞事件循环。 - *LRU缓存*（内存+Redis）使用内容哈希键。相同的URL + 相同的选项 = 缓存命中。仅此一项在繁忙的日子里处理了约40%的请求。 - *S3兼容存储* 用于结果交付。截图上传到对象存储，API返回一个预签名的URL。文件在24小时后自动过期。 - *Cookie横幅阻止* 使用@ghostery/adblocker-playwright及自定义过滤列表。虽然不完美（没有什么是完美的），但它能捕捉到约90%的GDPR弹窗。对于剩下的，我注入自定义JS以检测并关闭常见的同意框架（如OneTrust、CookieBot等）。 整个系统运行在阿姆斯特丹的一台4核/8GB的VPS上。Playwright是瓶颈——每个浏览器上下文使用约80-120MB——因此我将并发渲染限制在6个，并将其余请求排队。在正常负载下（目前约500-1000个请求/天），95百分位延迟约为3秒，适用于全页面截图。 *与现有服务的不同之处：* - 将截图、PDF、视频和数据提取结合在一个API中（大多数服务仅提供截图） - AVIF输出格式（比PNG小50-80%，在其他地方不广泛支持） - `extract`端点返回干净的Markdown、纯文本或结构化元数据——对RAG/LLM预处理管道非常有用 - 起价为每月9美元，而不是29-99美元 *我仍在探索的内容：* - 视频录制（浏览会话的MP4）是最新的功能，也是最不优化的。捕获后FFmpeg编码增加了2-5秒的开销。 - 超过一台服务器的扩展。Playwright的集群效果不佳——我可能需要使用负载均衡器将请求路由到渲染节点。到目前为止还没有需要这样做。 - 9美元的价格点是否可持续。每个截图的计算成本约为0.001美元，但根据页面复杂性会有很大差异。 免费套餐：每月100个请求，无需信用卡。我并不是想进行诱饵和转换——免费套餐确实对侧项目和测试非常有用。 文档： [https://snapapi.pics/docs.html](https://snapapi.pics/docs.html) 欢迎讨论架构、Playwright的奇特之处或运行截图API的经济性。我在浏览器自动化的边缘案例方面学到了很多意想不到的知识。

去年，我开发了一款安卓应用，可以屏蔽短视频（Reels）和短片（Shorts），同时保留“健康”的功能，比如故事（Stories）和私信（DMs）。我并不想完全屏蔽整个应用，只想给朋友发消息，查看他们的动态，而不想在短视频上浪费一个小时。这是安卓版本的HN帖子：<a href="https://news.ycombinator.com/item?id=44923520">https://news.ycombinator.com/item?id=44923520</a> 当人们询问是否有iOS版本时，我认为这不可能。苹果的限制要严格得多，不允许那种级别的应用访问。 但最终我采用了不同的方法构建了iOS应用。在iOS上，它使用的是Web应用。虽然体验与原生应用不完全相同，但效果出乎意料地好。 我还将其与iOS快捷指令结合，自动将原生应用重定向到Web应用，这样我可以保留Instagram以接收通知，但在点击时会直接进入没有短视频和任何动态的Web应用。 我很好奇你对此的看法，特别是关于iOS上Web应用的方法。

我创建了一个招聘平台，旨在帮助半导体设计专业的学生（以及更资深的半导体从业者）找到下一个实习机会（或工作）。我们目前有几百个职位发布，并且每天都在增加。