给软件开发者准备的优质简报，每日阅读 10分钟。
An update on residential proxies and the scraper situation
LWN 报道住宅代理爬虫攻击升级及网站防御现状
- 爬虫攻击主要通过"住宅代理"发起：数百万个独立 IP 在数小时内各发起两三次请求，伪装成普通浏览器用户（通常不抓取图片和 CSS），且每个地址只用一次，使封禁 IP 毫无意义。
- 代理运营者分两类：一类通过恶意软件控制被入侵设备（如被 Google 取缔的 IPIDEA，以及近期被曝光的流媒体设备僵尸网络）；另一类如 Bright Data 以"免费 VPN"或付费 SDK 为幌子，公开将用户设备纳入代理网络——这些网络还能访问设备所在内网资源，风险远超爬虫本身。
- 主流大模型公司自行爬取时会标明身份并遵守 robots.txt，流量并非最大威胁；真正付费使用住宅代理的隐藏客户身份不明，可能包括秘密开发模型的企业、政府机构乃至犯罪组织，作者将其比作一场"军备竞赛"。
- LWN 近期遭遇迄今最严重的爬虫攻击，但凭借未公开的防御措施（未采用 Anubis，因其拖慢真实用户且已有被绕过的迹象），多数读者毫无察觉，攻击期间响应速度甚至优于平时。
- Google 联合 FBI 于 7 月 2 日关闭 NetNut 代理网络，暂时缓解攻击，但作者认为此类平静难以持久，并指出各大应用商店对代理类应用为何能轻易上架保持沉默，呼吁对大模型公司建立最低伦理标准，否则开放互联网将被迫退入防御高墙之内。
Prefer strict tables in SQLite
为什么作者推荐在 SQLite 中使用严格表（STRICT tables）
- 严格表可防止类型不匹配错误：在表定义末尾添加
STRICT后，SQLite 会拒绝向列中插入错误类型的数据（如把文本存入 INTEGER 列），但能无损转换的值（如字符串'123'转为整数）仍被接受，同样的校验也适用于 UPDATE 操作。 - 严格表能拦截无效的列类型声明：默认情况下 SQLite 会接受
GARBAGE、DATETIME、JSON、UUID等并不存在的类型，而严格表只允许INT、INTEGER、REAL、TEXT、BLOB和ANY六种类型，且必须显式声明列类型。 ANY类型保留了灵活性：如果某列确实需要存储任意类型的数据，可以使用ANY类型，即使在严格表中也能插入整数、文本、浮点数或二进制数据。- 现有表无法直接转为严格表：没有
ALTER语句可以修改现有表为严格表，只能通过新建严格表、复制数据、删除旧表并重命名的方式迁移，且若旧数据中存在类型错误会导致迁移失败，需要先清洗数据。 - SQLite 官方开发者持不同观点：SQLite 官方文档《灵活类型的好处》认为动态类型有其优势（如纯键值存储、导入混乱的 CSV 时保留原始数据），作者虽承认这些合理场景，但仍基于自身遇到的类型相关 bug 经历坚持偏好严格表。
- 版本与性能注意事项：严格表需要 SQLite 3.37.0（2021 年 11 月发布）及以上版本，且旧版本无法读取包含严格表的数据库；理论上严格表因额外类型检查会稍慢，但作者实测插入数百万行数据未发现明显性能差异，磁盘文件大小也相同。
Nvidia, CoreWeave, and Nebius: Inside the Circular Financing of the GPU Boom
英伟达、CoreWeave与Nebius：剖析GPU热潮中的循环融资模式与风险
- 新兴云服务商的核心优势在于快速部署与高利用率：CoreWeave和Nebius凭借与英伟达的深度合作，能率先交付最新一代GPU（如H100、Vera Rubin），并通过专有软件（如CoreWeave Kubernetes Service）将GPU集群的模型FLOPS利用率（MFU）提升至50%以上，显著高于行业30%-40%的典型水平，从而帮助客户快速获得并高效使用算力。
- 超大规模客户的巨额承诺与当前收入形成鲜明对比：微软与Meta对这两家新兴云服务商的承诺总额已超1220亿美元，若计入与OpenAI和Anthropic的交易则可能超过1450亿美元，但CoreWeave和Nebius 2026年的预计收入仅分别为126亿和34亿美元，显示承诺规模远超现有营收。
- 将资本支出转化为运营费用是超大规模客户的关键财务动机：通过长期租赁算力，微软和Meta得以将本应计入资产负债表的巨额资本开支转为按年分摊的运营费用，从而避免其本就紧张的自由现金流因大规模新建数据中心而进一步恶化。
- 新兴云服务商自身面临严重的资金缺口与债务压力：两者资本开支远超经营现金流，主要依靠发行债务融资而非股权。例如，CoreWeave的季度自由现金流为负，且2026年面临显著的融资缺口；Nebius虽现金流状况稍好，同样需要持续融资以支撑其扩张目标。
- 英伟达通过投资、供应与兜底承诺构成了“循环融资”核心：英伟达不仅向CoreWeave和Nebius进行股权投资，后者又将巨额资金用于采购英伟达GPU；同时，英伟达还为CoreWeave提供了高达数十亿美元的未售GPU算力回购担保，形成了一个紧密的、相互依存的资金与产品闭环。
- 上升的利率环境直接侵蚀新兴云服务商的盈利能力：其广泛使用的GPU抵押贷款（如CoreWeave的DDTL）利率与美国国债收益率挂钩，随着利率上行，其利息支出占收入比例已超过25%且持续攀升，对尚未盈利的公司构成严峻的利润压力。
What xAI's Grok build CLI sends to xAI: A wire-level analysis
xAI Grok Build CLI（grok 0.2.93）网络流量分析：实际向 xAI 发送的内容
- 机密文件原文外泄：Grok 读取的文件（包括
.env机密文件）会未经任何脱敏地原文发送——既出现在模型请求体POST /v1/responses中，又被打包进session_state档案经POST /v1/storage上传并被接受（HTTP 200）。 - 整个仓库被整体上传：无论模型是否读取，Grok 都会将全部受控文件连同完整 Git 历史打包为 git bundle 上传；在 12 GB 仓库上实测上传 5.10 GiB（全部 200，无失败），而模型通道仅传输 192 KB，约 27,800 倍差距证明上传的是整个代码库而非读取内容。
- 上传目的地为 GCS 且默认开启：数据被持久化到 Google Cloud Storage 桶
grok-code-session-traces（二进制常量与metadata.json中的gs://路径可验证），该机制在 CLI 安装与快速入门文档中未披露，且默认启用。 - "Improve the model" 开关无效：关闭该选项后整个仓库仍被上传，服务器
/v1/settings仍返回trace_upload_enabled: true；唯一的非 200 响应是模型调用配额（402/429），与代码上传无关——退出仅影响训练，不阻止代码离开本机。 - 证据边界与诚实声明：作者通过 mitmproxy 抓包、金丝雀标记文件及 SHA-256 证据附录证明了传输、接受与存储，但明确未证明 xAI 用这些数据训练模型；所有测试均使用虚假机密，结论仅针对 grok 0.2.93 版本。
Show HN: Ant – A JavaScript runtime and ecosystem
Ant：从零构建的轻量级 JavaScript 运行时
- 轻量便携，引擎自研：Ant 是从零构建的高性能 JavaScript 运行时，二进制文件仅约 8.6 MB，无需 50 MB 下载或工具链配置；其引擎 Ant Silver 为手工打造，并非 V8、JSC 或 SpiderMonkey 的封装
- 冷启动与安装速度领先：在导入 Hono、注册两个路由并退出的测试中，Ant 仅需 5.4 ms，快于 Bun（12.8 ms）、Deno（24.8 ms）和 Node（31.1 ms）；安装包速度比 npm 快达 40 倍，且无需额外工具
- 零配置开发体验：直接运行 TypeScript 文件（
ant app.ts），无需 tsconfig、打包器或 dist 目录；通过默认导出 fetch 处理器即可启动服务器，Hono 等真实框架无需适配器即可运行 - 硬件级沙箱隔离：内置基于 VM 的沙箱（每个沙箱是独立的 KVM / Hypervisor.framework 虚拟机），支持只读文件系统挂载、默认拒绝所有网络、仅开放指定端口，可安全运行不可信的 JavaScript 代码
- 开放的包注册表：配套 ants.land 注册表，采用 npm 协议，支持 ant、npm、yarn、pnpm、bun 等包管理器，包可通过 esm.ants.land 直接在浏览器中使用
- 生态兼容与平台支持：compat-table 达 100%，符合 WinterTC 标准，可运行 Hono、Elysia、TypeScript、React、Rolldown、Wasm 等生态，支持 macOS 和 Linux 的 arm64 与 x86_64 平台
Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k
Claude Code与OpenCode的Token消耗效率核心对比
- 固定系统开销悬殊：对于最简单的任务，Claude Code在发送用户提示前，已产生约33,000 token的固定载荷（包括系统提示、工具定义和注入的脚手架），而OpenCode仅需约7,000 token。此差异主要源于工具定义数量与复杂度。
- 缓存稳定性差异巨大：OpenCode的请求前缀在多次运行中保持字节级一致，实现了高效的缓存利用。相比之下，Claude Code的前缀在会话内及会话间频繁变化，导致其缓存写入量是OpenCode的5.9至54倍，而缓存写入按溢价计费。
- 生产配置显著放大基数：添加一个72KB的项目指令文件（如AGENTS.md），会使每次请求的基础开销平均增加约20,000 token。附加多个MCP服务器会进一步增加工具定义大小，使初始请求载荷深度达到75,000至85,000 token。
- 子代理导致成本急剧攀升：将任务分派给并行子代理执行时，成本会大幅增加。一个直接执行需121,000 token的任务，通过子代理执行可能消耗513,000 token（约4.2倍），因每个子代理都有独立的启动开销，且其完整记录会被父代理吸收。
- 多步任务中存在效率优势：在涉及多次工具调用的复杂任务中，Claude Code通过将多个工具调用批处理到单个请求中，其总输入Token可能低于需要多次串行请求、每次都重发固定基础开销的OpenCode。
- 精准测量是成本管理的基础：通过在API边界部署代理来记录准确的请求载荷与用量，是理解系统实际发送内容、优化成本、延迟与上下文预算的关键，对于受监管的生产环境尤为重要。
UPI: Anatomy of a Payment Transaction
UPI支付架构详解：从扫码到入账的完整旅程
- 用户感知的五个瞬间与隐藏的中继过程：用户仅体验到扫码、确认收款人姓名与金额、输入密码、看到支付成功标识以及收款方手机收到通知这五个瞬间，而在这背后，支付指令在应用、担保银行、NPCI中央交换机和交易双方银行之间完成了一次完整的传递与验证。
- 关键参与方及其核心职能：支付应用是收集用户意图并加密密码的前端界面，但它本身不处理资金；担保银行为应用提供接入支付网络的通道、签发UPI地址并验证密码；NPCI作为中央交换机负责路由请求，并遵循“先扣款、后到账”的固定顺序协调交易。
- 系统规模与市场结构：UPI已成为全球最大的实时支付系统，2026年6月交易量超过2272亿笔。应用市场由PhonePe和Google Pay形成双寡头格局，占据约五分之四的交易量；而银行在收付款两端的角色出现分化，Yes Bank因作为众多商户应用的担保银行，在收款端占据主导地位。
- 支付失败的类型与趋势：支付失败分为业务拒绝（如密码错误、余额不足）和技术拒绝（系统故障）。近年来技术拒绝率已显著下降至极低水平，系统可靠性不断提升，而业务拒绝率有所上升，表明大多数失败源于用户侧而非系统故障。
- “待定”交易的处理与保障机制：当资金已扣但到账状态未及时确认时，交易进入“待定”状态。此时系统会启动自动对账流程，并在规定时限内（转账通常一天内）完成资金确认或原路退回，若延迟退回银行将受到处罚，以此保障用户资金安全。
How to read more books
如何通过系统性方法实现大量阅读
- 彻底优化空闲时间用途：将阅读变为所有非专注时段的默认活动，通过移除手机中的社交媒体与流媒体应用来消除屏幕干扰，并利用通勤、烹饪、用餐、遛狗等一切碎片化时间阅读。
- 坚持随身携带书籍：为抓住所有潜在阅读机会，应始终随身携带一本书。电子书阅读器因其便携、海量存储及护眼背光成为理想选择，但作者也建议交替阅读电子书与纸质平装书以丰富体验。
- 灵活管理阅读选择与心态：可同时阅读多本不同题材的书籍以保持新鲜感；广泛涉猎各类作品，遵循“读所爱，直至爱上阅读”的原则。更重要的是，不必害怕中途放弃一本书——时机未到的书不妨日后重读，若感到枯燥则果断合上。
- 建立目标与反思机制：设定合理的阅读目标并通过工具（如Goodreads阅读挑战）追踪进度，但应以深度理解而非数量堆砌为追求。撰写读书笔记或评论有助于深化记忆与思考。
- 积极寻找优质读物：通过关注可靠的书评平台（如Goodreads）和YouTube书评频道来发现下一本好书，并建立一个持续更新的待读书单。
- 坚决摒弃阅读捷径：避免依赖速读、摘要或有声书等方式。这些被营销为“高效”的手段无法替代对文本的全神贯注与深度处理，且阅读本质上比听书更快。
Old and new apps, via modern coding agents
陶哲轩借助 AI 编码代理复活旧应用并开发新可视化工具
- 陶哲轩自 1999 年起用 Java 1.0 编写了复分析、线性代数课程及数学对象（如蜂巢结构、Besicovitch 集）的可视化 Applet，但因网页标准不再支持该版本 Java 而全部失效；近日他借助现代 AI 助手将旧网页数据迁移至更易维护的仓库，并在数小时内把约二十多个旧 Applet 全部移植为 JavaScript，部分还获得图形升级（如 Besicovitch 集从单色变为彩色），其中包括他与 Allen Knutson 于 1999 年合作编写、当年手工编码尤为棘手的蜂巢 Applet。
- 在移植过程中，陶哲轩仅发现一处轻微 bug（某个复分析 Applet 拖拽事件在主框外出现异常行为），而 AI 代理反而找出了原始代码中两个他此前未察觉的错误，代码质量总体持平；由于这些 Applet 只是辅助性可视化工具而非数学论证的关键部分，此类 bug 的下行风险较低。
- 移植过程十分顺利，促使他进一步开发新应用：1999 年他曾构想一个"闵可夫斯基空间中的 Inkscape"式狭义相对论可视化工具，当时因代码复杂度被迫放弃，如今通过与 AI 代理数小时的"氛围编码"对话，终于实现了当年愿景并上线"alpha"版本，公开征集反馈。
- 在发表 Gilbreath 猜想论文博文后，他同样让 AI 代理为该猜想编写了配套交互式可视化工具，数小时内完成；他表示未来可能将此类交互式可视化作为论文的补充材料，因其非论文核心，使用 LLM 生成可视化的下行风险可以接受。
- 在评论中，陶哲轩回应了关于如何避免应用再次过时的问题，认为如今跨语言移植的成本已降至接近零，只要有足够上下文（形式化规格或配套说明）且任务基于标准概念，LLM 就能胜任转换工作；他同时强调，编程经验与领域专业知识（如狭义相对论）对于从 AI 获得有用代码、做出高层设计决策、发现与诊断问题仍然不可或缺——"氛围编码"自动化的是底层语法与实现，而新手程序员仍需亲手练习底层工作才能掌握高层抽象。
I love LLMs, I hate hype
我爱大语言模型，但我讨厌炒作
- 作者自2007-2014年从事黑客工作后，整个职业生涯都投入AI领域，对GPT-5.6、自动驾驶、视频生成模型和编程代理等新进展感到由衷兴奋，甚至用本地GLM-5.2配合opencode搭建Linux环境，感叹"Linux桌面之年"终于到来
- 作者反对两种炒作：一是"窗口正在关闭""永远落后"等负面恐慌叙事，认为其目的是让人自我怀疑并搬去糟糕的旧金山；二是从"高级自动补全"跳跃到"AI将统治整个光锥"的末日论，他愿赌上全部身家断言这不会发生
- 作者认为前沿实验室的估值站不住脚——AI确实会创造巨大价值，但这些公司无法捕获它；反开源论调的本质是对商品化的恐惧，因为AI的进步主要源于摩尔定律和计算技术的整体发展，而非这些公司的功劳
- 作者修正了此前对模型编程能力的批评：编程本身正在改变，他引用Linus Torvalds的话称代理让编程效率提升10倍（编译器则是1000倍），虽然数字夸张，但他确实从中获得了提升
- 作者提醒使用AI编程需警惕认知疲劳，所有"氛围编程"产物仍是垃圾（所谓的生产力提升并未带来神奇的新软件），但模型就像查找替换、Stack Overflow一样实用
- 结论：AI是计算机革命的延续，作者深爱计算机
Don't you mean extinct?
从《侏罗纪公园》到 LLM：程序员如何在技术变革中避免"灭绝"
- 1993 年《侏罗纪公园》用 CGI 取代了传统的 go-motion 技术，让定格动画大师 Phil Tippett 一度感到"被淘汰"（"I feel extinct"），但他随后担任"恐龙总监"，与 ILM 共同开发 Dinosaur Input Device（DID），并于 1994 年凭该片赢得奥斯卡最佳视觉效果奖，其工作室此后又参与了《星河战队》等 75 部影片。
- 作者借 Tippett 的故事回应程序员对 AI 取代职业的焦虑，主张避免"灭绝"的最佳方式是进化——主动学习 LLM 的原理与用法；正如 John Carmack 所言，"编码"从来不是价值来源，解决问题才是核心技能，传统编程要求的严谨与精确仍是可迁移的宝贵素质。
- 推荐的学习资源包括 Andrej Karpathy 的 YouTube 频道（约 25 小时视频）和 Sebastian Raschka 的《Build a Large Language Model (From Scratch)》一书，并建议借助 LLM 阅读 llama-cpp、ollama、vLLM 等开源项目及研究论文来追赶前沿。
- 用 LLM 写代码时仍需把控质量：完全"氛围编程"虽可产出千倍代码却可能留下难以理解的烂摊子，因此作者坚持迭代 PR 直至达到手写水准，并将风格偏好写入
GEMINI.md/CLAUDE.md供代理模仿；同时警告同时驱动多个代理带来的"上下文切换"会导致精神疲劳甚至倦怠。 - LLM 时代的代码审查标准更高：提交信息应遵循七条规范、PR 应拆小、必须附带测试、可拒绝不必要的依赖（如让 LLM 直接写 Levenshtein 距离函数）；小团队借助 LLM 能完成更多工作，作者本人就借此复活了 Silpheed 视频格式逆向等搁置项目，并强调找到学习动力才是持续进化的关键。
Mesh LLM: distributed AI computing on iroh
Mesh LLM：基于 iroh 的分布式大模型推理平台
- 核心理念与功能：旨在打破由大厂商垄断、成本高昂且缺乏控制权的传统AI推理模式。它将用户已有的多台设备（笔记本电脑、GPU工作站、服务器等）聚合为一个统一的计算网格，对外暴露为兼容 OpenAI 标准的 API，实现对大型模型的分布式运行和访问。
- 无中心化的网络基础：系统基于 iroh 库构建，每个节点以公钥作为唯一身份，利用 iroh 的 NAT 穿透和 QUIC 协议在任何网络环境下建立直接、认证的连接，无需中心服务器。为保障全球连通性，Mesh LLM 在不同区域部署了两个 iroh 中继服务器作为备用路径。
- 核心技术突破：通过名为"Skippy"的分片模式，将超大模型（如 235B 参数的混合专家模型）按层范围切分为多个阶段，分布到多台设备上以流水线方式协同运行。激活值在节点间传递，使单台性能有限的设备也能共同推理巨型模型。
- 灵活的架构与生态：采用插件化设计，插件通过清单文件声明能力，运行时动态加载、路由调用并暴露能力。内置包含 40 多个模型的目录，从 5 亿参数的轻量级模型到 235B 巨型模型不等。整个系统利用 QUIC 的 ALPN 协商和自定义流类型高效处理对等通信、推理请求和分片数据传输。
- 用户体验与前景：用户仅需安装约 18 MB 的轻量客户端，即可加入公共网格或配置私有部署，并通过本地地址
localhost:9337/v1无缝对接现有的 OpenAI 客户端工具链。项目计划基于 iroh 的 Swift SDK 推出移动端应用并支持 ACP（代理标准），持续强化点对点、无锁定的开放生态方向。
We scaled PgBouncer to 4x throughput
ClickHouse 托管 Postgres 中 PgBouncer 多进程扩展方案
- PgBouncer 是单线程进程，无论机器有多少核心，单个进程只能占用一个 CPU 核心；在 16 vCPU 的机器上，其余 15 个核心闲置，连接池会先于 Postgres 成为吞吐量瓶颈。
- ClickHouse Managed Postgres 按可用核心数部署 PgBouncer 进程舰队，所有进程通过
so_reuseport绑定同一端口，由内核在进程间负载均衡传入连接，客户端仍只连接单一端点，这也是 PgBouncer 官方文档推荐的多核利用方式。 - 由于取消请求（cancel request）通过携带 cancel key 的新连接发送，内核可能将其分配给错误的进程；进程间的 peering 机制会将取消请求转发给真正持有该会话的进程，确保取消功能在整个舰队中正常工作。
- 连接池运行于事务模式（transaction mode），事务提交后立即归还服务器连接；同时
max_client_conn和max_db_connections配额按进程数均分，既避免超额占用 Postgres，又能提升整体连接上限。 - 在相同 AWS EC2 环境（c7i.4xlarge、相同 Postgres 与 pgbench 负载）下实测：单进程峰值约 87k TPS，负载升至 256 客户端时反而降至约 77k TPS，整机 CPU 利用率不足 10%；16 进程舰队则持续攀升至约 336k TPS（约 4 倍），CPU 利用率达 50%–60%，仍有富余。
- 低并发时单进程甚至略快，差距恰恰出现在真正重要的高并发场景；该多进程舰队配置已在所有 ClickHouse Managed Postgres 实例中默认启用。
Ghostel.el: Terminal emulator powered by libghostty
Ghostel：基于 libghostty-vt 的 Emacs 终端模拟器
- 双层架构：Zig 编写的原生动态模块负责终端状态、渲染和本地 PTY I/O（后台线程读取，不阻塞 Emacs 主线程），Elisp 管理键位映射、缓冲区、命令及 TRAMP 远程进程集成；原生模块首次使用时自动下载，无需工具链。
- 五种 eat.el 风格输入模式：默认的半字符模式（大部分按键直达终端）、字符模式（全部按键转发，
M-RET退出）、Emacs 模式（只读但终端实时运行）、复制模式（冻结输出便于精确选取）和行模式（本地编辑整行后按RET一次性发送），并支持鼠标拖拽、标记激活时自动切换保护选区。 - 现代 VT 功能：依托 Ghostty 的 VT 引擎，支持 Kitty 键盘与图形协议（内联图片）、五种下划线样式及彩色下划线、OSC 8 超链接、OSC 4/10/11 颜色查询、同步输出（DEC 2026）、OSC 9/777 桌面通知与 OSC 9;4 进度报告，以及密码提示检测（经
read-passwd安全输入，不进入按键记录）。 - 自动 Shell 集成与远程支持：无需修改配置文件即可为 bash、zsh、fish、nushell 注入目录追踪（OSC 7）、提示符导航（OSC 133）和
ghostel_cmd（从 shell 调用白名单 Elisp 函数）；TRAMP 远程终端可自动部署xterm-ghosttyterminfo 与集成脚本。 - 性能领先：在跨模拟器基准测试（Apple M4 Max、Emacs 32.0.50）中纯 ASCII 吞吐约 75 MB/s，约为 vterm 的 4 倍、eat 的 12 倍；原生 PTY 路径吸收 10 MB 输出仅需约 110 ms 且全程不冻结 Emacs，键入回显绕过定时器实现低延迟。