此处的每一项测验均基于同一套包含 197 个国家和地区的资料库，其中旗帜、首都、国土面积、人口和边界数据均来自同一来源。你可以选择一个大洲或较小的区域，问题将随之缩小范围。错误的选项并非随机产生，而是经过刻意设计的：例如关于乍得的问题会提供罗马尼亚作为干扰项；关于摩纳哥的问题则会提供印尼。排除法在这里并不奏效，这正是设计的初衷——因为这些正是人们在现实中最容易混淆的组合。一轮测验结束后，你会看到错题列表，每项条目都链接到一个关于该旗帜的页面，详述其配色、启用日期、比例，以及最常被混淆的旗帜。网站无需注册账号，也不会在服务器上保存分数记录。你对每一项的正确率记录仅保存在你自己的浏览器中，以便抽认卡模式能优先显示你最薄弱的项目，且没有任何数据会被发送至任何地方。
每日HackerNews RSS
Hacker News 社区近日测评了“Learn Flags Quiz”（flagquizzes.com），这是一款为地理爱好者打造的、无广告且极简的网页游戏。
用户普遍称赞该网站“令人上瘾”、“简洁”且“设计精良”，并提到它提供了多项选择和打字两种模式。其中，“魔鬼”难度等级——即将颜色或几何图案相似的旗帜归为一组——被认为是认真学习者的独特亮点。
然而，该网站在技术实现方面也收到了一些建设性反馈：
* **用户体验：** 许多用户建议优化随机化机制以避免内容重复，并建议增加“所有国家”模式以追踪整体进度。
* **视觉呈现：** 多位评论者指出，强制将所有旗帜设为统一的长宽比会扭曲其独特设计（如正方形旗帜或尼泊尔的非矩形旗帜）。此外，部分用户反馈地图上的小型岛国难以辨认，存在点击困难或显示不准确的问题。
* **数据质量：** 用户指出了若干细微错误，例如巴拉圭旗帜上的文本标注错误，以及某些图标渲染显示异常。
总体而言，该项目被视为一个极具吸引力且富有情怀的工具，许多用户鼓励开发者进一步完善随机化机制与视觉呈现。
该实验表明，为 27B 模型（Qwen3.8）在 262K token 上下文下构建最佳本地推理系统，需要采取整体方案，而非仅仅挑选“同类最佳”的单一组件。 作者使用 NVIDIA RTX PRO 4000 (Blackwell) 和 RTX 2000 Ada，成功在 24GB 显存内平衡了密集模型、多模态投影器和 MTP 推测解码。主要发现包括： * **量化策略：** 采用原生 NVFP4 处理大部分权重，并对敏感张量使用 Q5/Q6 的自定义 5.01 BPW 混合量化，其质量和吞吐量均优于标准量化方案。 * **MTP 校准：** “最佳”草稿模型（drafter）并非精度最高的那个，而是与目标量化模型最兼容的那个。提高草稿模型精度反而因接受率降低导致吞吐量下降了 26.6%。 * **内核优化：** 通过自定义 `llama.cpp` 构建（引入 Gated DeltaNet、Flash Attention 混排以及特定的 CUDA 图优化），性能较主分支提升了 21.97%。 * **基准测试：** 真正的性能必须在缓存填满的“远端”（12.61 tok/s）进行测量，而非在起始阶段。 该系统在生产环境达到 50.44 tok/s，证明了硬件感知量化与内核对齐的性能表现优于规模更大但优化不足的模型。
这篇 Hacker News 讨论聚焦于一篇关于如何在一块 24GB 显存的 GPU 上以 50 token/秒 (TPS) 的速度运行 256K 上下文长度的 Qwen 27B 模型的文章。
讨论串中揭示了几个争议点：
* **写作质量：** 用户强烈批评该文章具有明显的“AI 生成”语调，并指出当代 AI 生成的文本（以行话和“废话”为特征）变得越来越容易辨认，令读者感到厌烦。
* **技术质疑：** 许多评论者对基准测试结果表示怀疑。主要困惑点在于作者未能提供清晰、标准化的量化标签，因为文章使用的是一种自定义的混合“iMatrix”量化方式。
* **工具之争：** 参与者讨论了 `llama.cpp`（针对单流延迟优化）与 `vLLM`（针对并发和批处理优化）之间的性能差异。多位用户指出，并发问题或配置错误往往会导致硬件性能声明失效。
* **硬件现实：** 有经验的用户指出，达到 50 TPS 极大地依赖于内存带宽和特定的模型调优，一些用户认为，对于使用双 3090 显卡配置的用户来说，类似甚至更好的结果早已是常见配置。
总的来说，社区对缺乏方法论透明度且由炒作驱动的 LLM 基准测试感到疲惫。
Turbopuffer 在公共 SaaS、单租户以及 BYOC（自携云环境）中运行着超过 100 个数据库集群。为了在不侵入客户基础设施的前提下管理这些集群，他们构建了一套健壮的、基于 Agent 的控制平面。
Turbopuffer 没有使用 Terraform 等传统 IaC 工具（这些工具不适合即时数据库运维），而是在每个集群上运行一个**本地 Kubernetes Agent**。该 Agent 由单个自定义资源（CRD）驱动，执行状态机逻辑。Agent 通过轮询中央 API 获取任务并在本地处理操作，即便与控制平面的连接中断，也能确保系统稳定性。
主要特性包括：
* **操作解耦：** 控制平面通过基于 MySQL 的 API 维护状态，而本地集群负责执行并报告状态转换，确保集群自身始终是事实来源。
* **键盘驱动的 UI：** 工程师通过一个受 Linear 启发、响应迅速的自定义仪表盘来管理整个集群群组。
* **集群自动化：** 控制器以分批次的方式管理大规模部署，并能在触发监控报警时自动暂停。
* **集成可观测性：** 与日志、指标及 Slack 告警的无缝连接，简化了故障排查流程。
这种简洁统一的架构使 Turbopuffer 能够在多样化的云环境中扩展的同时，保持快速的部署速度。
这篇 Hacker News 讨论聚焦于数据库公司 Turbopuffer 的架构，该公司强调频繁且安全的部署。
讨论的一个重点是该团队尽管使用了现代化的云原生技术栈，却选择使用 MySQL 来处理其“控制平面”的状态。团队解释说，他们对 MySQL 的现有熟悉程度（通过 PlanetScale 实现）使其成为管理客户组织和 API 密钥等关系型数据的自然选择。使用关系模型使他们能够通过外键轻松地将控制平面操作与特定客户关联起来。
该帖还强调了 Turbopuffer 在“第二天”运维中使用 Kubernetes Operator，用户称赞这是一种罕见且成熟的实现方式。在可观测性方面，团队确认他们使用 OpenTelemetry 进行埋点，并采用“基于推送”的模型将指标从客户管理的集群发送到 Datadog。总的来说，这次对话展示了 Turbopuffer 如何在构建基于对象存储的高度复杂的数据库技术的同时，优先考虑运维的简洁性和熟悉度。
本文详细介绍了“Plush”的性能优化过程。Plush 是一门采用 Actor 架构的玩具编程语言。
最初，作者实现了一种依赖 `HashMap` 来追踪对象转发的复制式垃圾回收器（GC），旨在简化 Actor 之间的消息传递。然而，由于哈希映射带来的高内存开销、不可预测的缓存访问模式以及 Rust 中安全哈希计算的性能成本，该设计效率低下。GC 未能达到 20 毫秒内回收一百万个对象的目标，实际耗时为 117 毫秒。
通过将 `HashMap` 替换为使用转发指针的经典 Cheney 算法，GC 性能提升至 7 毫秒，超出了预期目标。为了进一步提高效率，作者利用 `mmap` 技术动态扩展内存缓冲区，且无需重置指针，从而解决了此前在消息大小和协调方面的限制。
这些改进显著提升了 Plush 的性能和内存效率。作者总结道，尽管哈希映射等现代数据结构非常有用，但在高性能内存管理方面，指针转发等底层技术仍然更胜一筹，这证明了经典算法在系统设计中具有持久的价值。
抱歉。
**Foreman** 是一款人工智能驱动的软件工厂，旨在实现端到端开发循环的自动化，让开发人员能够专注于高层决策。它直接与 GitHub 和 Linear 集成，利用四个专业的 AI 代理来处理任务的全生命周期：
1. **分类器 (Classifier)：** 任务分拣与验证。
2. **分析师 (Analyst)：** 规划任务并定义验收标准。
3. **执行者 (Implementer)：** 在隔离沙盒中进行代码编写。
4. **审核员 (Reviewer)：** 独立进行验证。
Foreman 维护一个“工厂大脑”来存储特定于仓库的知识，确保上下文在不同任务间得以保留。该系统具有高度互动性，可通过问题标签、@提及或本地 TUI 触发。当分配任务后，Foreman 会执行流水线、发布进度更新并提交一份经过审核的拉取请求草稿。它甚至能自行处理 CI 故障，并为人工审核人员提供导向摘要。
Foreman 专为通过 Vercel 进行无缝部署而设计，支持自定义设置命令和环境变量配置，以匹配您仓库的具体需求。通过在自动化繁琐工作的同时要求人工审批代码变更，Foreman 在不牺牲质量或监督的前提下，精简了开发流程。
```Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
Show HN: Eve 软件工厂 (github.com/vercel-labs)
10 分，flashbrew 发布于 1 天前 | 隐藏 | 过往 | 收藏 | 4 条评论
使用此免费开源模板在几分钟内构建软件工厂
帮助
theappsecguy 1 天前 | 下一条 [–]
Vercel 现在真是左一个右一个地往外倒垃圾……
回复
cactusplant7374 1 天前 | 上一条 [–]
我是真心发问：当 AI 智能体几分钟内就能创建 Dockerfile 并部署项目时，Vercel 的价值主张究竟是什么？
回复
isubkhankulov 1 天前 | 父评论 [–]
我不是 Vercel 用户，但我的感觉是，与传统云服务相比，它通常更易于使用。
回复
mapk 1 天前 | 根评论 | 父评论 [–]
我使用 Vercel，原因正是如此。它非常易于使用。
回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
```
正在检查您的浏览器...需要启用 JavaScript
抱歉。
如果您对科技环境中的侵入式 AI 功能感到困扰，通常可以通过特定设置将其禁用或限制。本指南为您提供了在常用平台上移除或关闭 AI 的路径：
* **浏览器：** 使用浏览器标志（如 `chrome://flags` 或 `edge://flags`）禁用 Gemini 或 Copilot 等 AI 组件。Firefox 提供内置的“AI 控制”功能以阻止相关增强。
* **操作系统：** 在 Windows 11 上，您可以在任务栏和记事本设置中卸载或关闭 Copilot。对于 macOS/iOS，可以通过系统设置禁用 Apple Intelligence。
* **应用与服务：** 许多工具允许您选择退出 AI 驱动的功能：
* **Adobe：** 在偏好设置中禁用生成式 AI。
* **Google Workspace：** 在 Gmail 和文档设置中关闭“智能功能”。
* **通讯应用：** 在 Slack、WhatsApp 和 Zoom 的设置菜单中管理 AI 摘要和回复功能。
* **Android：** 使用系统设置禁用 Gemini，或将其从电源键唤醒中移除。
如需了解跨设备和软件管理这些设置的详细分步说明，请访问完整指南：**[https://NoToAI.org](https://NoToAI.org)**。
这篇 Hacker News 讨论帖探讨了人们对“侵入式 AI”日益增长的不满。目前，各家公司正竞相将 AI 功能强行植入产品（如 Apple CarPlay、亚马逊搜索、Jira、Gmail 等），且往往会因此移除原有的非 AI 功能，或将其设为收费项目。
用户们对缺乏选择权以及软件的“垃圾化”（enshittification）感到恼火。许多人认为，AI 应当是用户按需调用的工具，而不应成为一种挥之不去、令人厌烦的存在，从而导致界面混乱、引发隐私担忧并干扰工作流。
参与者分享的关键要点与策略包括：
* **缓解措施：** 使用广告拦截器（如 uBlock Origin）来“清除”不想要的 AI 按钮和插件。
* **搜索调整：** 使用 URL 参数（例如 Google 的 `&udm=14`）来绕过 AI 搜索摘要。
* **更换产品：** 迁移到更注重隐私或界面更“清爽”的替代方案，例如 Linux、基于 Firefox 的浏览器或去谷歌化的 Android 系统（GrapheneOS）。
* **资源推荐：** 社区维护的 [NoToAI.org](https://NoToAI.org) 被重点推介，该网站是禁用此类功能的技巧中心。
这场讨论反映出人们对“供给驱动型”技术特性的抵制——这类特性往往优先考虑企业的“用户粘性”和投资人叙事，而非用户体验与个人掌控权。
Wiz Research 的自主“红队代理”（Red Agent）近期在 Snowflake 的一个 GitHub 代码库中发现并成功利用了一个关键的工作流注入漏洞。该漏洞允许未经身份验证的用户执行任意命令，是 GitHub Copilot Autofix 无意中引入的。该人工智能助手将一种安全的、专注于过滤的代码模式替换为了存在漏洞的直接字符串插值，凸显了 AI 编程工具可能绕过既定安全措施的问题。 在发现漏洞后，Wiz 的 AI 代理自主优化了漏洞利用载荷以避开 Bash 语法错误，并成功窃取了内部 Jira 凭据。Wiz 于 2026 年 6 月 23 日通过 Snowflake 的 HackerOne 项目负责任地披露了这一发现。Snowflake 对该漏洞进行了修复，重置了受影响的凭据，并确认在五天的暴露窗口期内没有第三方参与者利用过该漏洞。 此事件突显了行业内的两个关键转变：一是 AI 生成代码引发回归的风险，即自动化工具缺乏保持安全最佳实践的背景知识；二是随着安全工具日益自动化，“发现窗口”正在不断缩短。建议各组织对 AI 编写的代码进行与人类贡献代码同等严格的安全审查，并建立防护机制，防止结构化数据解析器被不安全的 Shell 命令插值所取代。
近期 Snowflake 的 Jira 集成中出现的一项安全漏洞，凸显了在缺乏适当验证的情况下使用 AI 辅助代码生成的重大风险。GitHub Copilot 辅助生成的“自动修复”（Autofix）建议，将不受信任的问题标题直接插入到 GitHub Action 的 Shell 命令中，从而引入了一个严重的命令注入缺陷。
此事件在 Hacker News 上引发了关于 AI、CI/CD 安全与现代开发实践交集的热烈讨论。主要结论包括：
* **“人在回路”（Human-in-the-Loop）的问题：** 虽然 AI 可以加速编码，但它也极大地降低了引入缺陷的成本。审查人员往往会对 AI 生成的代码“盖章放行”，从而忽略了经验丰富的开发人员本应一眼识别出的安全回归问题。
* **GitHub Actions 的脆弱性：** 评论者批评了 GitHub Actions 的设计，指出在 YAML 中嵌入 Shell 脚本极易导致注入错误。该平台倾向于“默认放行”（例如将空值视为真），从而产生了意想不到的安全漏洞。
* **工具至关重要：** 社区强调了使用静态分析工具（如 `zizmor` 或 `actionlint`）的必要性，以便在代码进入生产环境前捕获常见的安全配置错误。
* **“LGTM”（看起来没问题）文化：** 许多人认为，AI 工具的兴起加剧了忽视严格代码审查的倾向；他们强调，即使代码生成是“免费”的，其维护成本依然高昂。
DuckDB v2.0 代号“Cyanoptera”，计划于今年秋季发布。这是该项目历史上最重要的更新，自 v1.5 版本以来已累计超过 10,000 次提交。 **主要亮点包括：** * **服务器模式：** “quack”协议趋于成熟，使 DuckDB 能够作为客户端/服务器数据库运行。新增的 `CONNECT` 命令支持原生网络通信，以及向 PostgreSQL 和 MySQL 进行远程 SQL 推送。 * **性能与存储：** 引擎现已支持异步 I/O 以实现更快的网络存储访问；引入了具备缓冲管理索引的新存储格式，支持即时加载；并进行了重大的查询优化（例如递归 CTE 速度提升 40 倍）。 * **新功能：** 备受期待的 SQL 触发器、用于半结构化数据的高性能 `VARIANT` 类型，以及改进的可观测性工具。 * **可扩展性：** 基于 PEG 的全新可扩展 SQL 解析器，以及现代化且稳定的 C API，确保了扩展程序在未来版本中的兼容性。用户现在还可以托管并签署自己的自定义扩展仓库。 * **开发体验：** 增强的 SQL 语法，包括嵌套架构（Nested Schemas）、CTE 中的 DML 操作，以及改进的兼容模式。 为了实现这些基础性改进，DuckDB v2.0 引入了一些必要的破坏性变更，主要涉及默认存储格式。
Hacker News 社区对 DuckDB v2.0 的发布反响热烈。用户称赞该数据库作为“专注于 OLAP 的 SQLite”的独特地位，并强调了其速度、可移植性以及在消费级硬件上处理大数据集的能力。
讨论的主要内容包括：
* **使用场景扩展：** 尽管传统上被视为本地分析工具，但开发者正越来越多地将 DuckDB 用于生产环境，包括混合云湖仓架构，以及通过 WASM 实现的浏览器端仪表盘。
* **“Quack”协议：** Quack 协议的引入备受期待，它旨在提高并发性，助力 DuckDB 向更强大的客户端-服务器架构转型，未来有望与 ClickHouse 等专业数据仓库解决方案竞争。
* **开发体验 (DX) 与工具链：** 开发者非常认可该项目对开发体验的重视，例如 SQL 的“语法糖”（如 `QUALIFY`）及其与 Python、Polars 及多种文件格式的通用集成能力。
* **技术争论：** 尽管评价绝大多数是正面的，但用户也讨论了关于并发性、缺乏原生增量物化视图以及开发节奏过快等方面的挑战。
总体而言，社区认为 v2.0 是一个重要的里程碑，进一步巩固了 DuckDB 作为现代高性能数据工程基石的地位。
德国竞争监管机构联邦卡特尔局（Bundeskartellamt）已结束了对苹果公司“App 追踪透明度框架”（ATTF）长达数年的调查。监管机构此前主张，苹果公司对其自身服务施加的许可要求比第三方应用更为宽松，以此滥用市场支配地位；这种做法实质上阻碍了用户同意第三方追踪，从而偏袒了苹果自身的生态系统。 为了解决调查，苹果承诺将使其所有平台上的许可提示更加统一。该公司将重新设计这些提示，确保在布局、措辞和内容上保持中立，删除此前阻碍用户选择参与第三方追踪的元素。此外，苹果将简化其架构，给予应用发布者更多灵活性，以便将其隐私法披露信息与 ATTF 的要求相结合。 此项和解确保了苹果无法利用其“守门人”地位获取不公平的竞争优势，转而营造一个让用户能够针对个人数据做出中立且知情决策的环境。这些承诺的有效期为七年，并将由独立监督员进行监督，这是欧洲旨在监管大型数字平台数据共享行为的广泛举措的一部分。
德国联邦卡特尔局（Bundeskartellamt）近期与苹果公司就其“应用追踪透明度”（ATT）框架达成了一项协议。经过调查，监管机构认定苹果的个性化广告做法造成了竞争环境的不公平——具体而言，苹果对自己旗下的应用采用了更为宽松的征询提示，而要求第三方开发者必须使用更严格的ATT提示。
苹果已同意将其自身服务的征询提示与第三方发布商所使用的提示保持一致。此举旨在解决外界对于苹果作为“平台守门人”及其自身作为“应用竞争者”这一“双重身份”所引发的竞争担忧。
Hacker News 上的讨论引发了广泛争议：一些用户认为这是迈向公平竞争的必要一步；而另一些人则辩称，拉平竞争环境可能会无意中削弱整体的用户隐私保护。批评者认为，监管机构将市场竞争置于用户体验之上，可能会导致隐私标准出现“逐底竞争”。此外，许多参与者表达了怀疑，指出苹果有利用平台权力优待自家应用的先例，并呼吁为所有开发者提供更严格、更透明的API访问权限。