1. DeepSeek开放搜索与抓取接口，分别按成功请求收费 (DeepSeek search and fetch – $0.75 per 1000 successful requests)
DeepSeek 开放搜索和网页抓取两个独立接口，让智能体及检索增强应用访问实时信息。搜索由自研引擎支持，返回标题、网址、摘要及可选正文；抓取负责读取指定网页，返回 Markdown 内容。两者沿用现有密钥，应用仍需自行组织后续处理。
两种接口各自按每千次成功请求零点七五美元计价，不按文本长度或返回结果条数收费；一次搜索再抓取一个页面，是两次独立请求。计费还要求返回 HTTP 200 且有实际结果：搜索必须得到非空结果数组，抓取必须取得页面内容。失败、搜索无结果和超时均不收费，增加搜索返回条数也不改变单次价格。官方另注明，经 DeepSeek 接口在 Claude Code 等指定开发工具中进行的服务器端工具调用目前免费，自北京时间十一月一日零时开始按请求收费，不能将这项安排扩大成所有直连接口均免费。抓取仍受目标站点可用性与访问规则限制，并不保证任意网页都能读到。
原文链接：https://api-docs.deepseek.com/guides/search/
论坛讨论链接：https://news.ycombinator.com/item?id=50138531
HN 讨论的是托管搜索究竟值不值得付费。一位自托管工具作者说，个人使用可以用聚合搜索或抓取工具，省去搜索服务的费用和密钥。回复者认为，组织更愿意为稳定延迟、数据处理约定和抓取可靠性付费：聊天场景对等待时间敏感，深度研究又可能连续发起十余次搜索和上百次抓取，偶发失败会累积。他以自己的平台客户为例，说部分客户宁愿提高成本来换质量。另一人随即质疑其中的保密论点，认为若目标是保护公司知识产权，直接把请求交给外部服务未必优于本地部署。评论没有据此证明某家服务已满足企业保密要求。
2. Sphinx：Git 推送前先回答 AI 代码测验 (Show HN: Sphinx – A hook that quizzes you on your AI’s code before shipping)
Sphinx 是为智能体辅助开发设计的 Git 钩子：向受保护分支推送代码时，它先暂停操作，再根据本次代码差异提问，检查提交者是否理解改动的行为。官网展示的流程中，一个没有看过编程对话的评审模型读取差异，追问出错场景；答错后说明原因、换个情境继续，答对才让推送进行。示例围绕支付事件去重：如果先保存事件编号，再执行扣款，扣款失败后的重试可能因看到编号而跳过，留下漏扣款的问题。网站明确说明，这段问答只是演示，真实问题来自实际改动。工具可接入现有编程智能体，也可使用 OpenRouter 或兼容 OpenAI 的模型接口，并支持普通 Git。它还提供允许直接放行的跳过命令，同时记录每次跳过，因此问答本身不构成代码正确或安全的保证。项目采用 MIT 许可，安装要求包括 Node 22.19 以上，以及 macOS、Linux 或 WSL。
原文链接：https://sphinx-six-theta.vercel.app/
论坛讨论链接：https://news.ycombinator.com/item?id=50137950
几位 HN 用户把问题归结为，任务完成了，自己却没有学会。一位用户说，不断描述目标、反复催模型修改虽然耗费精力，却未必带来亲手编程时积累的技能。有人因此主张继续手写代码，以保持对实现的理解；也有人认为，建立系统运行和边界条件的心智模型才是主要工作，单纯减少敲代码并不能替代这部分学习。另有用户承认，使用智能体常像反复试探答案，但不确定是工具限制还是自己的方法有问题。还有人建议，把理解检查放到请求他人评审之前，在创建或更新 PR 时触发，以减少审查者接收未被提交者理解的改动。
3. Pele：把 Mermaid 图表变成可换主题的 SVG (Pele – Mermaid diagrams as themeable SVG)
Pele 是一个把 Mermaid 文本图表渲染为 SVG 的开源库，为 Obsidian 开发，希望加快绘图并融入笔记应用的主题。使用者仍编写图表文本，再调用渲染接口取得 SVG，插入自己的页面；颜色和字体则通过 CSS 变量控制。颜色改变时无需重新生成图表，因此切换明暗主题可以直接调整显示样式。官网称支持 Mermaid 12.1.0 内置的所有图表类型，但这不意味着完全复刻原有布局：项目还主张在小屏幕上调整图表布局，而非只把整张图缩小。性能方面，官网列出的压缩后体积为 230 kB，对照 Mermaid.js 的 1.6 MB；它没有直接依赖，并给出 0.05—0.3 毫秒的渲染时间，宣称最高快约五百倍。首页没有交代这组比较的完整测试条件，不能据此保证任意复杂图都达到同样倍数。项目以 MIT 许可开放，提供示例、在线试验场、接口与兼容性说明，便于开发者比较自己的图表效果。
原文链接：https://pele.run/
论坛讨论链接：https://news.ycombinator.com/item?id=50132193
HN 评论的重点是布局质量，而不只是换主题。有用户抱怨，Mermaid 在复杂图中常产生难读的排列，作者回应称，Pele 只沿用语法，不照搬布局，并建议使用例子和试验场的对比模式。一些读者认为新布局明显更清楚，也有人试了几张图却看不出重大差异，要求解释系统性的改进；另有用户希望增加视觉差异比较，让图表改动比源码差异更直观。讨论还提到，图布局本身是难题，有人分享其他布局引擎和约束方法的使用经验。这些反馈表明，某些示例更美观的观感，仍需要结合具体图的复杂程度来判断。
4. 软件越容易造，越需要统一的产品判断 (Someone behind the software)
Linear的Karri Saarinen认为，好的软件会带着创作者的经验和判断，即使用户不知道开发者是谁，也能从产品感受到他们关心什么。他反对把软件制作仅看成收集需求、添加功能和核对指标的工厂流程：面对相似客户、使用相同技术，两支团队仍可能做出很不同的产品。作者所说的直觉来自与客户交流、犯错和持续修正，并不是随意凭个人喜好决定。Linear上线前广泛了解不同公司的工作方式，就是用外部经验完善自身视角。一个功能单独看可以运行良好，却仍可能破坏整体体验；因此需要有人决定哪些事不做，以及功能可用之后还要怎样打磨。他观察到，许多产品不断增加技术能力，却很少重新处理核心问题，并猜测独立使用智能体生产改动的组织方式，可能让各自合理的功能拼成缺少统一方向的整体。这是他对工作方式的反思，并非已证明智能体必然造成混乱。作者希望，写软件门槛下降后，团队能有更多空间深入理解问题，持续塑造彼此协调的答案。
原文链接：https://karrisaarinen.com/posts/someone-behind-the-software/
论坛讨论链接：https://news.ycombinator.com/item?id=50142573
HN先讨论直觉能否跨越开发者与用户的距离。有评论者认为，Linear团队也是自己产品的客户，日常就能用它管理开发，许多判断因此更容易做对；其他团队若不是目标用户，就应准备经常犯错，让组织和架构便于调整。回复指出，即使内部大量使用产品，也不可能覆盖所有功能，例如员工很少反复体验新人引导，或使用企业单点登录集成。另一组评论借《人月神话》讨论创作的完成：用户使用软件时才与创作者的想法相遇，但开发者可能永远觉得产品尚未完成。随后有人澄清，这里可以区分一次创作行为的完成，与产品长期演进的结束。
5. Java 密封类型：穷尽匹配为何仍会运行时报错 (Java sealed classes and exhaustive pattern matching)
Neil Madden 在四月的一篇文章中提醒，Java 密封类型带来的穷尽检查，有一个容易忽略的编译边界。密封类或接口可以限定允许哪些子类型，因此编译器能检查 switch 是否覆盖所有情况：覆盖完整就不必写默认分支，漏掉一种则编译失败。问题出现在库和调用者分别编译时。作者先定义两种子类型，再新增第三种；如果库与调用者一起重新编译，调用者遗漏新分支的问题会当场暴露。但若只更新库，保留旧调用者的字节码，程序碰到新类型时仍可能抛出 MatchException。也就是说，类型系统并不会在不重新编译的情况下，自动替旧代码补齐新情况。作者据此认为，密封类型更适合组件内部：内部通常一起编译，能充分利用穷尽检查；作为公共接口暴露时，扩展子类型会影响使用方的兼容性，遵循语义化版本规则的库需要把这类变化视为重大版本变更。文章当时还以预览中的 PEM 编码接口为例提出设计担忧。
原文链接：https://neilmadden.blog/2026/04/24/java-sealed-classes-and-exhaustive-pattern-matching/
论坛讨论链接：https://news.ycombinator.com/item?id=50141579
HN 中有参与者补充了文章之后的变化：针对当时 PEM 接口的问题，JDK 27 版本已在允许的子类型中加入非公开类型，让外部应用无法靠枚举全部子类写出穷尽分支，给未来扩展留下空间。作者回复表示认可这项修正。其他评论者则争论，是否应一律加默认分支来应付未来变化：有人觉得这是必要防线，另一人反驳，这会削弱新增情况时由编译器提醒的优势。也有人认为，库接口需要保留扩展余地，并不说明密封类型的总体设计错误。讨论区因此区分了组件内部追求完整覆盖，与公共库持续演进的不同需求。
6. RepRapMicron：用常见材料探索微米制造 (RepRapMicron)
RepRapMicron 的项目维基介绍了一台面向微米级制造的开源平台，希望像桌面三维打印机那样，用容易取得的材料制作精密设备。它借鉴 OpenFlexure 显微镜平台的柔性结构，再发展出适合加工的版本；当前推荐的是 PIKA，旧 MAUS 版本已弃用，不能把旧版构建资料直接当作最新设计。
按维基说明，PIKA 在边长约八毫米的立方工作区内，重复定位约一微米，位置准确度为十微米或更好。前者描述反复回到同一目标时的接近程度，不能替代实际位置准确度。平台用细探针转移紫外固化树脂，已沉积最小约四微米的液滴，也用光纤探针固化九微米宽的树脂线；展示的小船测试模型尺寸约半毫米、层高四微米。探针还可用于接触测高和刻蚀，轴控制能采用常见步进电机与串口数控指令。作者将其定位为继续探索材料、沉积和微型机构的平台，仍需确定哪些形状能打印、如何处理悬垂等问题，进一步缩小制造设备也是目标，而非已经完成的能力。
原文链接：https://github.com/VikOlliver/RepRapMicron/wiki
论坛讨论链接：https://news.ycombinator.com/item?id=50141076
HN 评论把这类项目放进精密工具发展的历史中看待。一位评论者联想到分度仪、螺纹车床和镗床：早先难以复制的一次性技巧，后来变成能稳定制造零件的工具。他的兴奋点是，三维打印、桌面数控设备和可编程控制系统正让爱好者获得更丰富的制造能力，这不是对该机器原子级加工能力的验证。另一人分享购买二手打印机后，用建模和暂停打印、插入金属件再继续的方式维修家中物品。随后话题转向软件，有程序员认为，用变量、函数和循环描述几何形状比操作图形界面更直观。讨论主要表达对个人制造工具的期待，并未提供平台精度的独立测量。
7. 开源微操纵台：50纳米步进不等于50纳米精度 (Open MicroManipulator – A sub-micrometer 3D motion control plattform)
Open Micro-Manipulator 是一套开源电动三轴微操纵平台，面向光学对准、电子元件探测和显微观察。它把常见步进电机、微型球关节与并联机构结合起来，用闭环控制跟踪运动；磁编码器的“磁性齿轮”方案把角度读数分辨率提高三十倍，使平台能够实现低至五十纳米的步进。
项目随即强调，分辨率不等于准确度，绝对定位准确度明显更差，因此不能把最小步进宣传成五十纳米定位误差。设备通过串口数控指令接入其他系统，也提供带实时摄像头画面的图形界面和 Python 接口，用于回零、移动及校准。新版四点零硬件修正了回零自碰撞、连杆长度难以保持一致和球关节摩擦等问题，不过物料清单仍未更新。机械模型使用 FreeCAD，零件可以机加工，也可以三维打印；后者需要面对塑料受热造成的漂移。固件支持六自由度位姿规划，为未来六足平台扩展留出空间，但当前展示的机械装置仍是三轴平台，不能据此说六自由度硬件已经完成。
原文链接：https://github.com/0x23/MicroManipulatorStepper
论坛讨论链接：https://news.ycombinator.com/item?id=50140001
HN 讨论围绕扩展能力和真实使用条件展开。有人问是否有六自由度版本，并提出增加电机、改变连杆布局的设想；他希望先看到可用工作空间、刚度和精度的估计，再投入自己的设计工作，也认可现有橡皮筋预紧球关节方案的简单。其他评论者推荐作者的构建视频，并把它与另一个微米制造项目联系起来。关于温度，有人追问这种尺度下如何处理热变化；回复者查到视频说明，电机升温会让塑料零件产生位置偏移。这提醒读者，闭环控制和很细的相对移动并不自动消除结构热漂移。已收集的评论没有提供整机绝对定位误差的实测表。
8. 美国议员拟推游戏所有权与停服离线保护 (NY announces game ownership bill requiring ownership rather than licensing)
来自纽约州的美国联邦众议员里奇·托雷斯，10月15日宣布将提出保护游戏购买者权利的立法计划。这是联邦层面的倡议，官方公告只说明了将提出的计划，并未声称草案已经提交或通过。计划希望由联邦贸易委员会制定规则，让消费者购买游戏后获得所有权，而不只是可能被撤回的游玩许可，并要求带在线功能的游戏在关闭服务器前提供离线模式。托雷斯还主张保护转让和转售权，但公告没有给出数字版本转售机制等完整条文。他以《NBA 2K25》为例：按公告所列计划，游戏将于10月30日从数字商店下架，12月31日关闭在线服务器，距离发行仅约两年。报道也提到《飙酷车神》停服后无法游玩的争议，说明依赖厂商服务器的单人内容同样可能失效。公告设想的解决路径是在停服前留下离线玩法，而非已经承诺永久运营原服务器；规则的适用范围、具体所有权及执行方式，仍需正式立法文本和后续程序明确。
论坛讨论链接：https://news.ycombinator.com/item?id=50136536
HN首先纠正新闻状态：这是纽约州选出的联邦众议员推动的倡议；另有人指出，官方说的是宣布将提出，并非已经提交。后续讨论转向更广泛的游戏保存。有评论者主张明确保护为保留可玩性而进行的模拟器开发、逆向工程和自建服务器，也有人希望缩短版权期限，让老游戏更早进入公有领域。另一项建议是预先托管无数字版权限制的版本，以免版权到期后仍被技术锁挡住。回复围绕现有例外、条约和财产权限制发生争论。这些属于评论者提出的改革方向及法律见解，并非该倡议已经包含的条款，也不能据此认定当前法律一概允许或禁止这些保存行为。
9. 用户称Namecheap核验逾期后停用其全部域名 (Namecheap just seized and disabled all my domains)
一位使用 Namecheap 十二年的用户在 Reddit 发帖称，自己外出期间错过了要求七十二小时内完成身份核验的邮件，回来后发现全部域名被停用、账户被锁。他转述的通知将原因称为例行账户资料准确性检查，但未说明为何选中其账户。用户表示，补交材料二十四小时后，仍没有得到恢复时间。停用还影响了依赖这些域名的公司邮箱，让用于接收处理进展的渠道本身也无法工作。
据其描述，在线客服不断把问题转交只能通过邮件联系的风险管理团队；他花了约四小时才让客服加入另一个联系邮箱，又质疑这一变更没有充分核验身份。为让部分客户继续在线，他已另付费用寻找主机，并考虑更换主机名称。这里能确认的是用户公开陈述及其摘录的通知，原帖没有提供足以独立判断全部处理过程的材料，也没有针对这一账户的公司回应。标题所说的“扣押”是发帖者用语，不能据此认定域名所有权已经转移；核心投诉是核验期限、服务中断与恢复沟通之间的冲突。
论坛讨论链接：https://news.ycombinator.com/item?id=50142866
HN 评论者贴出多条过去的停用、账户交接和域名交易争议链接，试图把这次投诉放进更长的服务记录中，但这些链接本身不能证明本案经过。一位用户说，自己的域名曾因平台错误被暂停，计划迁出；回复者却查看公开注册资料后认为，该域名仍有隐私保护设置，可能不符合相应注册局规则。这使讨论出现两种解释：平台处理失当，或具体域名的合规要求尚未解决。随后话题转向迁往哪家注册商，有人提到 Porkbun、Cloudflare、INWX 和 Hover，并分享界面与使用体验；这些是个人推荐，不能当作可靠性排名。
10. 影评：霍姆斯纪录片如何左右观众判断 (The Elizabeth Holmes documentary “You Can See Everything” is deceiving)
一篇关于伊丽莎白·霍姆斯纪录片《You Can See Everything》的影评，把焦点放在讲故事的人如何影响观众。作者称赞影片的叙事能力：镜头角度、特写、剪辑和信息揭示顺序不断改变人物形象，观众的情绪也随之转向。例如，同一个人不眨眼的特写可能显得阴森，镜头拉远，看到她抱着孩子，又让人意识到她的母亲身份。作者认为，导演不只是讲述欺骗，还让观众亲自经历印象被塑造的过程。标题中的“欺骗”，指的是作者感受到的叙事操控，也是她赞叹影片的原因。文章也追问导演是否可靠：他曾与霍姆斯夫妇同住一个月，亲近关系会不会影响呈现？作为背景，霍姆斯创办了血液检测公司Theranos，后来在四项投资人相关犯罪上被定罪，四项患者相关指控获无罪；两类结论不能混为一谈。作者希望观众分辨案件事实与影像造成的好恶，并意识到自己可能先形成情绪印象，再寻找支持它的理由，而非始终先权衡证据。
原文链接：https://www.readtheprofile.com/p/elizabeth-holmes-documentary-you-can-see-everything
论坛讨论链接：https://news.ycombinator.com/item?id=50137620
HN的两条评论分歧在于，这种叙事设计是否让人看到新东西。一位评论者把影片看作导演Nathan Fielder早期纪录喜剧和《彩排》的延伸：真实人物知道自己正在被拍摄，也知道观众原先如何看她，因此会主动经营形象；影片同时展示人物和导演各自构造故事的过程。他认为，这种层层相互影响仍能透露真实的一面。回复者则不认同其中有多大新意，认为霍姆斯的欺诈案早已被新闻和《坏血》详尽记录，这更像围绕昔日名人的真人秀。前者认为多层叙事仍能显露人物，后者则认为这种形式没有增加对案件的理解，反映的是对作品价值的分歧。