## RunPrompt：一个简单的提示运行器 RunPrompt 是一个 Python 脚本，用于轻松执行 `.prompt` 文件，并与大型语言模型 (LLM) 交互。它简化了与 Anthropic、OpenAI、Google AI 和 OpenRouter 等提供商的交互。 使用方法：下载并使脚本可执行，然后创建 `.prompt` 文件，定义 `model` 和提示内容。输入通过 `STDIN`（使用 `{{STDIN}}`）或作为 JSON 提供。RunPrompt 支持使用输出模式（定义 `name: type? description`）进行结构化数据提取，并支持在提示之间进行管道传输以进行链式操作。 配置灵活：API 密钥通过环境变量设置（例如 `ANTHROPIC_API_KEY`），前置信息值可以通过命令行参数（`--name "Alice"`）或以 `RUNPROMPT_` 前缀的环境变量覆盖。详细模式 (`-v`) 显示请求/响应详细信息，用于调试。 模型指定为 `provider/model-name`（例如 `anthropic/claude-sonnet-4-20250514`）。示例提示和进一步的文档可在项目的测试文件夹中找到。
每日HackerNews RSS
展示 HN：Runprompt – 从命令行运行 .prompt 文件
Show HN: Runprompt – run .prompt files from the command line
15 小时前
## Runprompt：将LLM提示作为命令行工具
Runprompt是一个新的单文件Python脚本，使用户能够直接从命令行执行LLM提示。它受Google的Dotprompt格式启发，允许进行模板化、结构化输出（如JSON模式）以及提示链——本质上将提示视为一流的可管道化程序。
主要特性包括零依赖（仅使用Python标准库）、支持多种LLM提供商（Anthropic、OpenAI、Google AI、OpenRouter）以及注重简洁性。用户可以自动化诸如数据提取、报告生成以及构建基本代理工作流等任务，而无需复杂的框架。
社区反馈积极，用户称赞其符合人体工程学的设计以及与现有shell管道的集成。讨论集中在潜在的增强功能上，例如JSON模式验证、缓存机制以及对其他LLM端点和文件格式（如`.prompty`）的支持。创建者欢迎反馈和贡献。
## Google TPU：深度剖析摘要 本报告详细介绍了谷歌的张量处理单元 (TPU)，这是一种定制的 ASIC，对谷歌的人工智能战略至关重要。TPU诞生于2013年，意识到使用CPU/GPU扩展人工智能工作负载成本将高得难以承受，因此TPU专为TensorFlow神经网络设计，优先考虑高效的矩阵乘法。 与通用并行处理器GPU不同，TPU采用“收缩阵列”架构，最大限度地减少数据移动并最大限度地提高计算效率。最新的TPUv7 (Ironwood) 版本比以前的版本 (v5p的459 TFLOPS) 实现了显著的性能飞跃 (4,614 TFLOPS)，拥有192GB的内存和7,370 GB/s的带宽。性能基准测试表明，对于特定工作负载，TPU比Nvidia GPU具有更好的性价比和能效，有时每美元的性能甚至高出1.4倍。 尽管具有这些优势，更广泛的TPU采用受到Nvidia成熟的CUDA生态系统以及JAX/TensorFlow的学习曲线的阻碍。然而，TPU对于谷歌来说越来越重要，为在由Nvidia定价主导的商品化云市场中获得更高的利润率提供了一条途径。 谷歌的TPU项目在超大规模厂商中是无与伦比的，其持续发展预计将在未来十年内为GCP提供重大的竞争优势。虽然确切的生产数量未公开，但谷歌正在积极扩展TPU容量并优化其软件堆栈，为未来可能对外提供TPU做好准备。
这个Hacker News讨论的核心是谷歌在人工智能竞赛中，由于其张量处理器（TPU）相对于英伟达图形处理器（GPU）的潜在长期优势。链接的文章认为谷歌处于有利地位，引发了关于英伟达适应能力的争论。
许多评论者认为英伟达始终能够克服挑战，尽管其开发流程缓慢（3-4年）。他们指出英伟达的自我资助和现有的“张量核心”证明其已经在向更专业化的人工智能芯片发展。然而，人们担心英伟达过度专业化可能会蚕食其盈利的通用GPU市场。
讨论强调了改变像英伟达这样大型组织（围绕GPU生产建立）的难度。一些人认为英伟达保持通用芯片的策略是明智的，预计未来计算需求难以预测。另一些人指出，机器学习库中切换后端容易，即使使用TPU也能最大程度地减少供应商锁定。 此外，还简要提到了JAX框架中对苹果芯片的支持。
## 驾驭你的40岁：魅力的力量 独立开发者拓也最近41岁了，他反思了40岁生活的意外现实。他注意到人们对他的看法发生了变化——一种日语中被称为“看禄”（kanroku）的“存在感”，但他意识到这仅仅意味着*看起来更老了*。 他应对这个新阶段的策略？**魅力**：热情、平易近人且有意的友好。他认为微笑可以消除令人望而生畏的“老家伙”形象，而谦逊可以防止人们因成就而感到害怕。他以荒木飞吕彦（《JOJO的奇妙冒险》的作者）等人为例子，他们是保持平易近人的成功人士。 拓也强调*对比*的力量——真诚的微笑来自一个可能看起来严肃的人，会更有影响力。他认为这在与自己领域外的人（比如孩子幼儿园的“妈妈朋友”）互动时尤其重要，因为彼此的共同理解有限。最终，他希望保持谦逊，向年轻一代学习，并通过持续实践魅力来打破年龄和经验带来的障碍。
一个黑客新闻的讨论围绕着一篇题为“别做一个可怕的老头：我40多岁的生存策略与魅力”的文章展开。 这篇文章由一位41岁的人撰写，引发了关于在40多岁这个年龄段如此年轻时提供建议的有效性的争论。
评论者表达了不同的反应，从质疑作者的观点到与衰老的焦虑产生共鸣——特别是，一位用户分享了脱发带来的出乎意料的强烈情感影响。 另一些人则开玩笑地将“生存策略”总结为仅仅是富有，而另一个人则提出了“流水”的哲学方法。
此外，还出现了一场关于黑客新闻算法以及为什么这篇文章获得关注的元讨论，一位评论员认为它与论坛中对衰老和人际关系感兴趣的人群产生了共鸣。
克里特舰队网站致力于混凝土船和相关战争时期基础设施的历史。它充当百科全书和博客，重点介绍一战和二战期间使用的混凝土船只，涵盖英国和美国的参与情况。 该网站提供有关混凝土船只建造的信息、视频以及来自两次世界大战的大量照片库。它还深入研究相关主题，例如二战期间建造的人工港口—— Mulberry 港。 除了混凝土船只，该网站还探索一战时期的美国内河船以及其他相关历史主题。它是对这一独特的航海和军事历史感兴趣的研究人员和爱好者的资源。该网站版权归克里特舰队所有，保留所有权利，并使用 Cookie 进行网站分析。
一个黑客新闻的讨论强调了停泊在布里斯托尔港口的混凝土浮桥（thecretefleet.com）的故事。这些用混凝土建造的驳船有着令人惊讶的历史，与二战有关。
二战期间，布里斯托尔的城堡公园遭到严重轰炸。与其丢弃废墟，不如将其运往美国，作为返回的军需品船只的压舱物。这些废墟随后被用作填埋物，在纽约创建了布里斯托尔盆地——一场跨大西洋的战时废墟贸易！
评论者对这个鲜为人知的事实和项目背后的深入研究表示着迷。一位评论员，一位前港口工人，指出他/她在附近生活和工作多年，却从未意识到这些驳船的故事，而其他人则讨论了布里斯托尔港口沿岸不断变化的科技环境。
(Empty input provided. There is nothing to translate.)
C64 Burrow.BAS
17 小时前
## 开源许可与人工智能模型的未来走向
人工智能模型在大量公开代码（包括开源项目）上训练的兴起，在2021年引发了关于许可传播的争论——具体来说，像GPL这样的copyleft许可是否会延伸到模型本身，从而要求其开源发布。尽管最初备受关注，但“在GPL代码上训练必然导致GPL许可的模型”这一观点已逐渐失去主流支持，尽管尚未被明确驳斥。
目前，两起关键诉讼——*Doe v. GitHub* (Copilot) 和 *GEMA v. OpenAI* 维持着这一问题的活跃度。*Doe v. GitHub* 指控Copilot的输出缺乏适当的署名，从而违反了开源许可协议，而 *GEMA v. OpenAI* 则有争议地认为模型内部的“记忆”构成了版权复制。
尽管面临这些法律挑战，反对许可传播的论点正在增加。这些论点包括对版权法的解读（模型不是直接的“衍生作品”），将多个许可应用于单个模型的非实用性，以及严格执行可能扼杀人工智能发展的担忧。像OSI这样的组织倡导透明度和开放模型开发，*不*要求完全公开训练数据，而FSF则对数据自由持更强硬立场。
最终，法律环境仍然不明朗。虽然没有法院强制要求人工智能模型遵守GPL协议，但这个问题尚未解决。未来取决于正在进行的诉讼、不断演变的法律解读，以及持续的社区讨论，以平衡软件自由和人工智能时代独特的挑战。争论的重点不是人工智能*是否应该*尊重许可，而是*如何*以实用和有益的方式确保这种尊重。
## Docker 增强：超越基础 尽管 Docker 已经是一个成熟的工具，但它提供了许多未充分利用的功能，可以显著提高可靠性和开发速度。以下是十个经常被忽视的功能概述： **效率与安全：** 使用 **多阶段构建** 创建更小、更干净的生产镜像，并使用 **BuildKit 缓存挂载** 显著加快构建速度。通过 `RUN --mount=type=secret` 在构建时注入密钥，而不是将它们嵌入到层中，以确保密钥安全。 **工作流与编排：** 使用 **Compose 配置** 在单个文件中定义本地、预发布和生产配置，简化环境管理。 **Buildx bake** 简化了多架构构建（如 ARM64 和 amd64）。通过 **健康检查** 和 Compose 中的依赖感知来提高启动稳定性。 **可观察性与调试：** 利用 **Docker Scout** 获得即时 CVE 反馈和 SBOM 导出，用于安全扫描。使用 `--init`、`--cap-drop` 和 `tmpfs` 实现生产级别的容器安全性。使用 `--network container` 访问容器网络，以在本地调试生产环境的对等性。最后，流式传输 **Docker 事件** 以监控容器健康状况并检测不稳定情况。 即使实施其中一些功能，也能带来更精简、更安全的容器以及更强大的开发流程。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Docker 你容易忘记的强大功能 (oneuptime.com)
23 分，由 ndhandala 发表于 13 小时前 | 隐藏 | 过去 | 收藏 | 1 条评论
jchw 发表于 12 小时前 [–]
> 将缓存挂载视为共享卷：永远不要将密钥写入其中，并在依赖项更改时使用 --build-arg CACHE_BUST=$(date +%s) 定期使它们失效。
有点扫兴。如果构建工具更好，就不需要这样了。
回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## 技术性通缩：初创公司视角 经济学将通缩定义为物价下跌，通常被认为是有害的，因为它会抑制消费并可能引发经济衰退。作者将此与初创公司领域正在发生“技术性通缩”的情况进行类比：构建软件变得越来越容易和便宜。 这得益于人工智能的快速发展——更简单的模型、人工智能辅助编码以及更快的开发速度——导致了一种“观望”的态度。为什么*现在*就构建，如果六个月后会更快更便宜呢？这类似于经济通缩，尽管有潜在的好处，但也会延迟投资。 虽然抢占市场先机并非总是至关重要，但技术进步的加速现在*进一步*有利于后入者，使他们能够从竞争对手的错误中学习。作者以DoorDash和Lyft为例进行了说明。 这种“技术性通缩”将重点从构建转移到其他领域，例如分销、销售和深入的客户理解——这些优势并非仅通过更快的开发就能轻易复制。作者认为，未来可能更青睐那些优先拓展客户并利用可随意丢弃、快速构建的软件的公司，而不是仅仅专注于产品开发。
## 技术通缩与初创公司：摘要
最近Hacker News上出现了一场关于“技术通缩”的讨论——由于人工智能工具，软件开发的成本迅速降低且日益容易。虽然看似积极，但评论员们争论这是否有利于初创公司或大型企业。
一个主要担忧是，人工智能编码并不能自动解决客户获取问题。成熟公司可以轻松复制小型初创公司构建的功能，利用现有的客户群。一些人认为人工智能代表的是“维持性”而非“颠覆性”创新，有利于拥有资源的现有企业，例如谷歌。
对话强调了价值的转变：随着编码成本下降，支持、稳健性和基础设施变得至关重要。构建可靠的系统和提供卓越的支持被视为新的机遇。然而，基础设施提供商面临着日益复杂的挑战，尽管模型成本更低，但仍需吸收波动性。
许多人认为真正的优势不是开发速度，而是驾驭日益复杂性的能力。人们对仅仅依赖人工智能生成的代码持怀疑态度，强调人工监督和质量控制的重要性。甚至有人建议推迟构建任何东西，因为技术进步的速度很快，而另一些人则认为实践学习仍然至关重要。最终，这场讨论质疑当前环境是否有利于创建初创公司。
这段文字探讨了寻找最接近给定整数 *m* 的调和数 (Hn)。调和数是 1 到 *n* 的倒数之和，对于 *n* 大于 1 的情况，很少是整数。
该方法包含两个关键部分：准确计算 Hn 和有效地找到最佳 *n*。对于较小的 *n*，直接求和有效。然而，对于较大的 *n*，使用欧拉-马斯刻罗尼常数 (γ) 的渐近近似更有效，并避免了浮点误差。
为了快速估计 *n*，使用公式 *n* ≈ exp(*m* - γ) 作为起点。然后，代码通过迭代检查 *n* 的相邻值来完善此猜测，以确定最接近 *m* 的调和数。代码处理整数和实数输入 *m*，并通过例如寻找最接近 10 的调和数和 20 的平方根的例子，展示了其多功能性。
这次Hacker News讨论围绕着John Cook的博客文章，内容是寻找最接近整数的调和数。用户们讨论了计算调和数的问题，特别是当*n*的值很大时。
一个关键点是，直接求和调和级数随着*n*的增加会变得缓慢，并且容易出现浮点数误差。虽然缓存之前的项有所帮助，但即使是适度的和（比如100）所需的项数也会变得非常巨大。像反向求和（从1/n开始）这样的替代方案提供了稳定性，但也很慢，并且由于浮点数表示，对于非常大的*n*也存在局限性。
减轻浮点数不精确性的解决方案包括使用更高精度的存储、长整数（尽管它们也有局限性）、使用范围进行模糊比较以及BigDecimal（速度慢且占用大量内存）。 讨论还涉及一个相关的数学问题：调和数与整数之间的距离，结论是这个差值没有非零的下界。