<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:media="http://search.yahoo.com/mrss/" version="2.0"><channel><title>倾枫学</title><link>https://www.lxfzzw.com</link><atom:link href="https://www.lxfzzw.com/rss.xml" rel="self" type="application/rss+xml"/><description>人生旅途中总会遇到美好枫璟</description><generator>Halo v2.27.0</generator><language>zh-cn</language><image><url>https://www.lxfzzw.com/upload/logo.png</url><title>倾枫学</title><link>https://www.lxfzzw.com</link></image><lastBuildDate>Wed, 21 Oct 2026 05:24:14 GMT</lastBuildDate><item><title><![CDATA[ClickHouse 会放任你在大规模场景下犯错]]></title><link>https://www.lxfzzw.com/archives/matduggan-com-clickhouse-will-let-you-be-f01391e8</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=ClickHouse%20%E4%BC%9A%E6%94%BE%E4%BB%BB%E4%BD%A0%E5%9C%A8%E5%A4%A7%E8%A7%84%E6%A8%A1%E5%9C%BA%E6%99%AF%E4%B8%8B%E7%8A%AF%E9%94%99&amp;url=/archives/matduggan-com-clickhouse-will-let-you-be-f01391e8" width="1" height="1" alt="" style="opacity:0;">
<h1>ClickHouse 会放任你在大规模场景下犯错</h1>
<p><a href="https://matduggan.com/clickhouse-will-let-you-be-wrong-at-scale/">ClickHouse Will Let You Be Wrong at Scale</a> — matduggan.com · 9 小时前 · ⚙️ 工程</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F05-matduggan-com.png&amp;size=m" alt="ClickHouse 会放任你在大规模场景下犯错"></p>
<blockquote>
 <p>作者基于一次真实的生产级压测项目，复盘了 ClickHouse 在超出常规使用模式时的表现。背景设定相当严苛：目标是网络防火墙遥测数据，每天约 20 亿行来自多家厂商混合的 syslog 日志，在写入时解析成宽类型表，并设置 14 天的 TTL 自动过期。可视化层则要求在 Grafana 中同时完成两类任务——快速检索单条日志记录，以及在所有面板上叠加任意临时过滤条件后仍能保持流畅的即席分析。作者先给出了分层结论：走 OpenTelemetry 的标准路径时，几百个指标、每天几百万条日志和几千条链路追踪对 ClickHouse 来说毫无压力；但一旦进入自定义的复杂场景，引擎虽然极其强大，使用难度也陡然上升。整个项目的主旋律是「静默失败」：ClickHouse 像一个从不说你有错的同事，它不会报错，只会让你错得非常彻底——一条看起来正常的查询可能实际扫描了 84 倍于必要的行数；一个配置错误的过滤条件直接不生效；一个从未被路由命中的 projection 依然返回正确的结果，只是慢得多。作者坦承自己犯了大量错误，包括对难度的误判，写这篇复盘是为了给后来者踩坑警示，并且逐条认领这些错误。转折点出现在他真正理解了这个引擎的设计哲学之后：ClickHouse 永远不会主动告诉你做错了什么，你必须自己去发现错误，因此在使用任何功能之前，首先要建立验证习惯，而 system.query_log 表是最核心的排查工具。文章的核心结论是：工具的强大与易用是两回事，在非典型规模下，围绕工具建立自查和验证的工程纪律，比工具本身的性能参数更决定项目成败。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>这次压测的目标规模是每天约 20 亿行混合厂商的 syslog 防火墙日志，写入时解析为宽类型表并设置 14 天 TTL，同时要求 Grafana 仪表盘既能快速查询单条日志，又能在全部面板上叠加即席过滤器并保持响应速度，这是一个远超常规可观测性场景的严苛组合。</li>
 <li>标准 OpenTelemetry 路径下的 ClickHouse 表现轻松：几百个指标、每天几百万条日志、几千条追踪都不构成压力；但在自定义接入路径上，引擎的强大与易用性出现了严重脱节，复杂的写法和配置问题不会以报错形式出现，而是以性能劣化的形式潜伏下来。</li>
 <li>静默失败是整篇文章的核心教训：一条看似正常的查询可能比应有的扫描量多出 84 倍；配置错的过滤器会直接静默失效；从未被路由到的 projection 照样返回正确数值，只是查询速度大幅变慢——三种问题的共同点是没有报错，只有悄悄变差的结果。</li>
 <li>作者给出的方法论是把验证习惯放在一切工作之前：system.query_log 是排查查询行为的核心工具，被形容为你的朋友、酒保和恐怖片里那条可爱的狗；只有在理解了 ClickHouse 从不主动纠错这一前提后，他与这个系统的磨合才真正走上正轨。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 一次每日 20 亿行日志的真实压测复盘，把「强大但静默失败」这个选型盲区讲得足够具体，能给所有准备上 ClickHouse 的团队省下真金白银的踩坑成本。</p>
<p>✍️ <strong>小编看法</strong>: 小编看法：小编看法：这篇复盘的价值远超一篇 ClickHouse 踩坑记，它其实戳中了整个数据库选型文化里的一个盲区。我们习惯用官方基准测试和标准工作负载来评估引擎，但真实世界里真正决定成败的，恰恰是那些「非典型」路径——自定义解析、异构数据源、非常规查询模式。作者那句「ClickHouse 从不说你错」值得所有工程师刻在脑子里：低报错率不等于高正确率，一个把所有输入都吞下去的系统，反而把验证成本全部转移给了使用者。相比之下，传统数据库会因为你写了个烂执行计划而直接拒绝或者报警，这种「难伺候」其实是免费的护栏。我建议读者把这个教训泛化到任何列式存储和 OLAP 引擎上，包括那些新兴的分析型产品——性能参数只有在正确的数据布局下才成立，而数据布局是否正确，引擎自己不会告诉你。下一步值得观察的是两件事：一是 OpenTelemetry 标准路径与自定义路径之间的性能鸿沟会不会随着 ClickHouse 生态工具的成熟而收窄，这决定了它能否从「专家的引擎」变成「团队的默认选择」；二是团队层面如何制度化验证习惯，比如把 query_log 检查纳入代码评审和 CI 流程，而不是依赖某个资深工程师的个人直觉。如果你正准备把日志平台迁到 ClickHouse，这篇文章可能帮你省下几周的排查时间。</p>
<p>🏷️ ClickHouse, database, observability, performance</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/matduggan-com-clickhouse-will-let-you-be-f01391e8</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F05-matduggan-com.png&amp;size=m" type="image/jpeg" length="25744"/><category>工程</category><pubDate>Tue, 20 Oct 2026 23:04:38 GMT</pubDate></item><item><title><![CDATA[AI 最好能成，否则麻烦大了]]></title><link>https://www.lxfzzw.com/archives/wheresyoured-at-ai-had-better-work-out-b42e3ed5</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=AI%20%E6%9C%80%E5%A5%BD%E8%83%BD%E6%88%90%EF%BC%8C%E5%90%A6%E5%88%99%E9%BA%BB%E7%83%A6%E5%A4%A7%E4%BA%86&amp;url=/archives/wheresyoured-at-ai-had-better-work-out-b42e3ed5" width="1" height="1" alt="" style="opacity:0;">
<h1>AI 最好能成，否则麻烦大了</h1>
<p><a href="https://www.wheresyoured.at/ai-had-better-work-out/">AI Had Better Work Out</a> — wheresyoured.at · 6 小时前 · 💡 观点 / 杂谈</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F04-wheresyoured-at.png&amp;size=m" alt="AI 最好能成，否则麻烦大了"></p>
<blockquote>
 <p>围绕一个直白而尖锐的问题展开：如果大规模押注的人工智能最终无法产生与投入相匹配的回报，全球经济将面临什么样的后果。文章以 Apollo 全球管理公司首席经济学家 Torsten Slok 今年七月底接受《华盛顿邮报》采访时的警告作为切入点，他直言这轮 AI 热潮必须成功，否则整个体系都会出问题。作者随后试图把这种模糊的担忧量化成具体的数字：过去几个月他持续追踪 AI 泡沫的资金结构，发布过关于 AI 相关债务的两部分深度指南，分析过生成式 AI 对全球经济影响存疑的测算，并逐家拆解了英伟达和甲骨文这两家核心基础设施巨头，还论证了 OpenAI 最终会如何挤压甲骨文的生存空间，以及风险投资行业如何陷入自我毁灭的循环。他的核心判断可以浓缩为一句话：数百亿美元乃至数千亿美元级别的资本正被投入数据中心建设与算力采购，但这个行业目前能拿出来验证的，只是个位数亿美元的潜在收入，而且前提是数据中心真能按规划建成、OpenAI 和 Anthropic 真有能力持续支付算力账单。文章强调，这个行业习惯用理论上成立和假设性的推演来支撑现实中的巨额支出，而这些前提一旦落空，整个资金链条就会暴露出巨大的缺口。作者还预告了即将发布的针对黑石集团的分析，指出这家公司已经把自身命运几乎全部押在这轮 AI 泡沫上。文末附带的订阅信息显示，作者通过付费通讯持续输出对 AI 泡沫金融面的独立调查，并公开征集相关企业的内幕线索。最终结论是：这轮投入与回报之间隔着数量级的鸿沟，AI 必须真的「成」，而这个「成」的门槛被整个行业系统性地低估了。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>Apollo 全球管理公司首席经济学家 Torsten Slok 在七月底接受《华盛顿邮报》采访时发出罕见直白的警告：这轮 AI 必须成功，否则整个经济体系都会遇到大麻烦。作为管理巨额资产的投资机构首席经济学家，这类公开表态本身就说明华尔街内部对 AI 回报的担忧已经从私下讨论上升到了公开层面，而不再只是少数悲观者的边缘观点。</li>
 <li>作者对 AI 泡沫的判断被刻意简化：数千亿美元正在被投入，用来换取未来某一天或许存在的个位数亿美元级别的收入，而这一切的前提是数据中心能够真正规模化建成，且 OpenAI 和 Anthropic 有能力为它们的算力采购持续买单。理论上和假设中的行业前景被市场当成了已经兑现的现实，这正是泡沫最典型的特征。</li>
 <li>作者过去几个月通过付费通讯建立了一条系统性的调查线索，包括 AI 相关债务的两部分指南、对生成式 AI 拉动全球经济这一说法的质疑性测算、对英伟达和甲骨文的成对深度拆解，以及对 OpenAI 与甲骨文之间依赖关系的推演，预告中的下一站是黑石集团——一家把全部身家押在 AI 泡沫上的资产管理巨头。</li>
 <li>文章背后的商业模式值得注意：作者以每年 70 美元、每季度 18 美元或每月 7 美元的价格提供每周深度通讯，专注追踪 AI 泡沫的资金流向，并通过 Signal 公开征集关于 Anthropic、OpenAI、黑石等公司的内幕信息，形成一种独立财经调查的众包模式。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 它把弥漫市场的模糊焦虑换算成了可核验的资金数字，并点名了那些把身家押在泡沫上的机构，适合任何想看清这轮狂热背后账本的人。</p>
<p>✍️ <strong>小编看法</strong>: 小编看法：这轮讨论里最容易被忽略的一点是，Sloks 那句警告之所以重要，不在于他说了什么，而在于谁在说。Apollo 这样的固收巨头靠信用利差吃饭，他们开始公开担忧，意味着债券市场可能比股票市场更早对 AI 资本开支定价。过去我们看互联网泡沫，跌的是股票，这次不一样：钱大量来自债务融资、供应商融资和循环交易，一旦收入证伪，受伤的会是一整条债券和结构化产品的链条。另一个值得琢磨的细节是作者把问题简化成投入与产出的数量级对比，这种简化在传播上很有效，但也可能掩盖了结构性差异——基础设施投资本来就有前置投入、后置回报的特点，问题不在差距本身，而在融资结构是否能撑到回报兑现的那一天。我更关注的是接下来三个观察点：一是黑石这类资管巨头通过私募信贷间接承接 AI 数据中心风险敞口的规模到底有多大，这部分几乎不透明；二是甲骨文这类「先接单后融资」模式在信用市场的反应；三是如果 2026 年数据中心上架率不及预期，那些签了长期算力承诺的公司如何处理违约。对普通读者来说，这篇文章的价值不是给你一个涨跌预测，而是提醒你换一个视角：别只盯着模型能力演示，去盯着现金流和债务到期表，那边才是决定这轮周期走向的钟摆。</p>
<p>🏷️ AI bubble, economics, criticism</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/wheresyoured-at-ai-had-better-work-out-b42e3ed5</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F04-wheresyoured-at.png&amp;size=m" type="image/jpeg" length="105158"/><category>观点 / 杂谈</category><pubDate>Tue, 20 Oct 2026 23:04:36 GMT</pubDate></item><item><title><![CDATA[量子纠错大幅突破盈亏平衡点]]></title><link>https://www.lxfzzw.com/archives/arstechnica-com-quantum-error-correction-b8692dbc</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=%E9%87%8F%E5%AD%90%E7%BA%A0%E9%94%99%E5%A4%A7%E5%B9%85%E7%AA%81%E7%A0%B4%E7%9B%88%E4%BA%8F%E5%B9%B3%E8%A1%A1%E7%82%B9&amp;url=/archives/arstechnica-com-quantum-error-correction-b8692dbc" width="1" height="1" alt="" style="opacity:0;">
<h1>量子纠错大幅突破盈亏平衡点</h1>
<p><a href="https://arstechnica.com/science/2026/10/quantum-error-correction-goes-well-beyond-breakeven/">Quantum error correction goes well beyond breakeven</a> — arstechnica.com · 4 小时前 · 🤖 AI / ML</p>
<blockquote>
 <p>在量子计算硬件上运行复杂算法，最终必须依赖逻辑量子比特：将多个易出错的物理量子比特以特定方式编码组合，使错误能够被检测和纠正。这背后存在一个微妙的平衡问题——分配给每个逻辑量子比特的物理量子比特越多，纠错能力越强，但物理量子比特本身也会出错，加入越多反而抬高了错误发生的概率。如果底层硬件的错误率过高，扩大逻辑量子比特规模只会雪上加霜。好消息是，业界已有若干家公司证明其硬件错误率降到了临界线以下，实现了逻辑量子比特跨越盈亏平衡点的演示：增加物理量子比特数量确实能改善性能。但问题在于，此前这些演示中性能提升的幅度并不显著，若要把错误率压到足以运行复杂算法的水平，按现有改进速度推算，每个逻辑量子比特需要搭配的物理量子比特数量将多到完全不切实际。Quantinuum 于周一宣布了关键进展：其当前一代硬件能够将纠错的扩展性推进到远超盈亏平衡点的程度，逻辑量子比特每扩大一级规模，其部分性能指标就能提升超过 10 倍。这意味着量子纠错的扩展曲线从勉强越过门槛变成了陡峭上行，为未来以可行规模的硬件运行复杂量子算法打开了新的想象空间。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>量子纠错的基本原理是将多个物理量子比特组合编码为逻辑量子比特，使错误可被检测和纠正，但存在固有矛盾：物理量子比特越多纠错越强，可它们自身也会出错，若硬件错误率过高，扩大逻辑比特规模反而恶化整体表现。</li>
 <li>此前已有数家公司演示了跨越盈亏平衡点的逻辑量子比特，即增加物理量子比特确实能带来性能改善，但改进幅度不够陡峭，照此推算要把错误率降到可运行复杂算法的水平，所需物理量子比特数量将不切实际地庞大。</li>
 <li>Quantinuum 本周一宣布其现役硬件实现重大突破：逻辑量子比特每提升一级规模，部分性能指标改善幅度超过 10 倍，扩展性远超盈亏平衡点，证明其硬件错误率已低到让纠错的规模收益得以充分兑现。</li>
 <li>这一结果的实际意义在于改变了扩展曲线的斜率：纠错不再只是勉强过线，而是随规模增长快速放大收益，为在可行硬件规模内运行复杂量子算法提供了新的技术路线依据。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 量子纠错从勉强跨过门槛到实现每级超过 10 倍的性能跃升，这可能是判断实用化时间表的关键拐点数据。</p>
<p>✍️ <strong>小编看法</strong>: 量子计算领域最不缺的就是里程碑式新闻，但这次的结果值得区别对待。关键不在「突破了盈亏平衡点」这个说法——这在几年前就已经实现——而在提升的斜率：每扩大一级逻辑比特规模就有超过 10 倍的指标改善，这意味着纠错的收益曲线是陡峭上行的，而不是过去那种每加一堆物理比特只换来百分之几改善的勉强度日。行业多年来的隐忧是纠错开销大得让实用化遥遥无期，这条数据直接回应了这个担忧。需要冷静的地方也有几点：一是宣布来自 Quantinuum 自身，独立的第三方复现和论文细节还需要时间验证；二是离子阱路线本身在比特数量扩展上有物理瓶颈，10 倍的单级改善能否在更大规模上持续，才是真正的考验；三是「部分性能指标」的说法留有余地，具体是逻辑错误率还是保真度等指标，值得追看原始数据。对行业而言，这会加剧超导、离子阱、中性原子几条技术路线之间的竞争，投资和人才的流向可能因此调整。对普通读者来说，距离能跑实际应用的量子计算机仍然不近，但纠错从理论难题变成工程问题的转折点，正在眼前发生。接下来半年值得观察的是 Quantinuum 下一代的规模化数据，以及竞争对手是否会用类似的多级扩展实验来应答。</p>
<p>🏷️ quantum computing, error correction, logical qubits</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/arstechnica-com-quantum-error-correction-b8692dbc</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2Fcover-2026-10-21-ai-ml-02.png&amp;size=m" type="image/jpeg" length="51021"/><category>AI / ML</category><pubDate>Tue, 20 Oct 2026 23:04:34 GMT</pubDate></item><item><title><![CDATA[Meta Muse 分享会话链接致用户个人与商业机密泄露]]></title><link>https://www.lxfzzw.com/archives/arstechnica-com-meta-muse-exposes-users-a4ebc799</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=Meta%20Muse%20%E5%88%86%E4%BA%AB%E4%BC%9A%E8%AF%9D%E9%93%BE%E6%8E%A5%E8%87%B4%E7%94%A8%E6%88%B7%E4%B8%AA%E4%BA%BA%E4%B8%8E%E5%95%86%E4%B8%9A%E6%9C%BA%E5%AF%86%E6%B3%84%E9%9C%B2&amp;url=/archives/arstechnica-com-meta-muse-exposes-users-a4ebc799" width="1" height="1" alt="" style="opacity:0;">
<h1>Meta Muse 分享会话链接致用户个人与商业机密泄露</h1>
<p><a href="https://arstechnica.com/security/2026/10/meta-muse-exposes-users-personal-and-business-secrets-when-they-share-conversations/">Meta Muse exposes users' personal and business secrets when they share conversations</a> — arstechnica.com · 10 小时前 · 🔒 安全</p>
<blockquote>
 <p>Meta 新推出的通用智能体 Muse 存在严重的信息泄露问题：用户通过网页链接分享对话时，敏感信息可能被陌生人获取。安全研究机构 Claroc 的研究人员发现，Muse 分享链接的 URL 构造方式存在设计缺陷，导致链接可被系统性地枚举猜出。研究人员利用这一缺陷批量找出了 6800 个用户创建的分享链接，并抽查打开了其中数百个，发现的内容明显是用户无意公开的信息，涵盖个人隐私和商业机密。通常这类分享功能会生成包含长串随机字符的 URL，使其难以被猜测，从而把敏感内容限制在分享对象范围内。而 Muse 的 URL 设计决策恰恰破坏了这一保护机制。值得注意的是，Meta 首席执行官扎克伯格上个月还宣称 Muse「从底层设计就为隐私和安全而生」，与现实形成鲜明反差。在 Ars Technica 就该行为发出询问后，Meta 回应称正在暂停该分享功能，待公司审查并考虑修改后再做决定。这一事件再次说明，AI 对话中往往包含用户输入的最私密内容，而分享功能的链接安全若处理不当，很容易成为大规模泄露的入口，厂商在推出便利功能时对基础安全设计的把关至关重要。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>安全公司 Claroc 的研究人员发现，Meta 的通用智能体 Muse 在分享功能上存在关键设计缺陷：虽然分享链接表面上与常见服务一样采用难以猜测的长字符串 URL，但 URL 的构造方式使其可被系统性枚举，保护机制形同虚设。</li>
 <li>研究人员利用这一缺陷枚举出 6800 个 Muse 用户创建的分享链接，并打开了其中数百个进行核查，发现其中包含明显不打算公开的信息，既涉及用户的个人隐私，也涉及商业层面的机密内容，泄露面相当广。</li>
 <li>事件形成了刺眼的对比：Meta 首席执行官扎克伯格上个月公开表示 Muse 是「从底层设计就为隐私和安全而生」，但实际产品却在 URL 安全这个基础环节上失守，说明宣传口径与工程实现之间存在明显落差。</li>
 <li>在媒体 Ars Technica 就此行为向 Meta 求证后，Meta 承认问题并宣布暂停 Muse 的分享功能，表示将审查相关行为并考虑做出修改。用户在功能恢复前创建的存量分享链接风险如何处理，目前尚无明确说法。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 一次典型的低级安全设计失误酿成大规模隐私泄露，任何做分享功能或使用 AI 助手的人都该读读，引以为戒。</p>
<p>✍️ <strong>小编看法</strong>: 这个案例最有价值的地方在于它暴露的不是高级攻击，而是最基础的安全常识。不可猜测的 URL 长期以来只是「安全靠模糊」的弱保护，绝大多数成熟产品至少会配合访问鉴权或过期机制，Muse 连 URL 不可枚举这一层都没守住，实在说不上「为隐私而生」。更值得警惕的是 AI 对话的特殊性：用户与智能体的交流往往比网页浏览、图片分享私密得多，商业机密、个人困境、未公开的计划都可能被原样输入，一旦分享链接可被批量发现，泄露的就不是零散信息而是成规模的隐私档案。6800 个链接只是研究人员愿意枚举的量级，实际暴露面可能更大。对行业而言，这里有两条教训：一是新功能上线前的威胁建模不能省，尤其是把用户内容变成可访问 URL 的功能，几乎每个做分享的团队都该重新自查一遍；二是用户的信任一旦在产品早期被击穿，修复成本极高，Meta 暂停功能是必要动作，但存量链接如何失效、是否通知受影响用户，才是衡量其诚意的关键。下一步值得追踪的是 Claroc 是否披露完整技术细节、Meta 恢复功能时是否改用鉴权方案，以及监管机构是否会介入这类大规模隐私暴露事件。</p>
<p>🏷️ Meta, AI agent, privacy, data leak</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/arstechnica-com-meta-muse-exposes-users-a4ebc799</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2Fcover-2026-10-21-security-01.png&amp;size=m" type="image/jpeg" length="66560"/><category>安全</category><pubDate>Tue, 20 Oct 2026 23:04:32 GMT</pubDate></item><item><title><![CDATA[DeepSeek 开源推理框架：走向真正普惠的未来]]></title><link>https://www.lxfzzw.com/archives/woshipm-com-deepseek-a421aa1e</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=DeepSeek%20%E5%BC%80%E6%BA%90%E6%8E%A8%E7%90%86%E6%A1%86%E6%9E%B6%EF%BC%9A%E8%B5%B0%E5%90%91%E7%9C%9F%E6%AD%A3%E6%99%AE%E6%83%A0%E7%9A%84%E6%9C%AA%E6%9D%A5&amp;url=/archives/woshipm-com-deepseek-a421aa1e" width="1" height="1" alt="" style="opacity:0;">
<h1>DeepSeek 开源推理框架：走向真正普惠的未来</h1>
<p><a href="https://www.woshipm.com/share/6481490.html">DeepSeek 开源推理框架：走向真正普惠的未来</a> — woshipm.com · 12 小时前 · 🛠 工具 / 开源</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F01-woshipm-com-GGWA.png&amp;size=m" alt="DeepSeek 开源推理框架：走向真正普惠的未来"></p>
<blockquote>
 <p>大模型的能力上限由模型本身决定，但服务海量用户时的真实成本，往往取决于一个长期不为公众所知的中间层——推理框架。训练让模型学会本领，推理则让模型真正服务于人，推理框架统筹调度庞大算力集群的效率，直接决定了 AI 服务的算力开支与电力消耗。DeepSeek 宣布将内部推理框架 DeepInfer 全面开源，并同步放出生产级 Token 编解码组件 deepseek-recipe，与 DeepSeek 官方 API 的处理逻辑完整对齐，让社区能获得与官方部署一致的接口体验。DeepInfer 集成高性能算子与深度优化的推理引擎，支持分布式推理、推测解码、SWA Bounded Replay、结构化输出等能力，同时兼容英伟达 GPU 与华为昇腾两类硬件平台。基于这套框架，DeepSeek 已支撑 DeepSeek V4.1 Flash 的高吞吐、低延迟大规模线上推理服务，未来新模型的推理代码与优化也将持续在该仓库更新。这不是 DeepSeek 首次开源动作：此前公司已陆续开源多款大模型、TileLang 编译工具及推理算子库，推理框架的开放补齐了从模型、算子到部署的完整链条。DeepSeek 表示，希望借此帮助开发者与企业优化大规模推理的吞吐与延迟，高效构建私有化及公有云部署，降低算力成本、减少能源消耗，让智能以更低价格触达更广泛人群，实现真正意义上的大模型普惠，并承诺继续支持社区进行大规模部署优化。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>DeepSeek 将其内部推理框架 DeepInfer 全面开源，核心定位是解决大模型从训练走向大规模服务时的成本瓶颈：推理框架负责调度算力集群，其效率直接决定服务的算力开支与电力消耗。该框架已支撑 DeepSeek V4.1 Flash 的高吞吐、低延迟线上服务，后续新模型的推理代码和优化也将在同一仓库持续更新。</li>
 <li>DeepInfer 的技术能力覆盖了大规模部署的关键环节，包括高性能算子集成、分布式推理、推测解码、SWA Bounded Replay 与结构化输出等特性。硬件兼容性是突出亮点：框架同时支持英伟达平台与华为昇腾平台，为企业在不同算力生态下的私有化部署和公有云部署提供了选择空间。</li>
 <li>同步开源的 deepseek-recipe 是一套生产级 Token 编解码组件，其处理逻辑与 DeepSeek 官方 API 完全对齐，确保社区自行部署时的接口体验与官方服务保持一致。仓库地址为 github.com/deepseek-ai 下的 DeepInfer 与 deepseek-recipe 两个项目，另有知乎技术报告可供参考。</li>
 <li>此次开源是 DeepSeek 开放策略的延续与补全：此前公司已开源一系列大模型、TileLang 编译工具以及推理算子库，加上推理框架后形成了模型、算子、编译工具到部署框架的完整开源链路。官方引述「为善与众行之，为巧与众能之」，强调目标是帮助行业降低算力成本与能耗，推动智能以可负担的价格普及。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 推理框架是大模型成本竞争中被忽视的关键一层，DeepSeek 把生产级实现连同官方对齐的组件全部开放，对做部署的工程师和企业是难得的一手资料。</p>
<p>✍️ <strong>小编看法</strong>: 推理框架开源这件事的行业意义，可能比模型开源本身更大。过去两年开源社区的热点都在模型权重上，但真正决定一家公司 AI 服务盈亏的，是那个沉默的推理层：同样的模型，推理效率差几倍，意味着数百万美元级别的成本差距。DeepSeek 此前几次引发行业震动的降价，背后大概率就有这套框架的功劳，如今把它交出来，等于把「成本护城河」的一部分变成了公共基础设施。值得注意的细节是昇腾兼容。这意味着这套代码在编写时就考虑了非英伟达硬件，而这两类平台在算子与通信上的差异极大，能同时跑好说明抽象层做得扎实，对国内算力生态尤其重要。被忽略的代价也存在：开源框架不等于开箱即用，大规模推理调优依然依赖深厚的工程能力，中小团队拿了代码未必能复现官方的吞吐数字，社区生态和文档的成熟度将决定这次开源的实际影响。另一个值得观察的点是 vLLM、SGLang 等已有主流推理框架会如何反应，是吸收 DeepInfer 的技术、与之竞争，还是形成分工，未来一两个季度就能看出端倪。对读者而言，如果你的团队在做私有化部署，这大概率是今年最值得花时间评估的开源项目之一，尤其当你的硬件路线横跨英伟达与国产芯片时。</p>
<p>🏷️ DeepSeek, inference, open source</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/woshipm-com-deepseek-a421aa1e</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F01-woshipm-com-GGWA.png&amp;size=m" type="image/jpeg" length="75549"/><category>工具 / 开源</category><pubDate>Tue, 20 Oct 2026 23:04:30 GMT</pubDate></item><item><title><![CDATA[Cloudflare 推出面向 AI 代理的 CLI 工具，并将逐步淘汰 Wrangler]]></title><link>https://www.lxfzzw.com/archives/infoq-cn-cloudflare-ai-cli-wrangler-2a76aa52</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=Cloudflare%20%E6%8E%A8%E5%87%BA%E9%9D%A2%E5%90%91%20AI%20%E4%BB%A3%E7%90%86%E7%9A%84%20CLI%20%E5%B7%A5%E5%85%B7%EF%BC%8C%E5%B9%B6%E5%B0%86%E9%80%90%E6%AD%A5%E6%B7%98%E6%B1%B0%20Wrangler&amp;url=/archives/infoq-cn-cloudflare-ai-cli-wrangler-2a76aa52" width="1" height="1" alt="" style="opacity:0;">
<h1>Cloudflare 推出面向 AI 代理的 CLI 工具，并将逐步淘汰 Wrangler</h1>
<p><a href="https://www.infoq.cn/article/Ddda0DF68laqfoqa4Lju?utm_source=rss&amp;utm_medium=article">Cloudflare 推出面向 AI 代理的 CLI，并逐步停用 Wrangler</a> — infoq.cn · 11 小时前 · 🛠 工具 / 开源</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F05-infoq-cn-QyHB.jpg&amp;size=m" alt="Cloudflare 推出面向 AI 代理的 CLI 工具，并将逐步淘汰 Wrangler"></p>
<blockquote>
 <p>Cloudflare 宣布推出一款专为 AI 代理设计的新命令行工具，同时计划逐步停用开发者社区沿用多年的 Wrangler CLI。这一变化的核心背景是：随着越来越多开发工作由 AI 代理（如各类编码助手与自动化智能体）完成，传统为人类交互设计的命令行界面在机器调用场景下暴露出诸多不足。Wrangler 诞生于人类开发者的使用习惯，其输出信息冗长、交互式提示频繁、错误信息面向人类阅读而非机器解析，AI 代理在调用时常需反复试错才能拿到准确结果。新工具针对这一痛点重新设计：输出结构化、格式稳定、命令语义清晰，便于代理直接读取和判断执行结果，减少解析成本与误判概率。Cloudflare 表示，这不是简单的功能更名，而是围绕「以代理为主要调用方」这一前提重新审视整套开发工具链。同时，官方给出了过渡安排：Wrangler 将进入维护状态并逐步淘汰，现有功能会平滑迁移至新工具，官方文档与迁移指南将随之更新，以降低存量项目的切换成本。作者的核心结论是：开发工具的设计范式正在从「服务人类开发者」转向「同时服务人类与 AI 代理」，Cloudflare 的这一步是基础设施厂商对这一趋势的直接回应，未来会有更多平台跟进类似的工具链重构。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>Cloudflare 发布了一款面向 AI 代理的新命令行工具，用以替代长期使用的 Wrangler，并明确表示 Wrangler 将进入逐步淘汰流程。这次替换的动因并非功能缺失，而是使用主体的变化：大量开发任务现在由自动化代理执行，而 Wrangler 的交互式提示、冗长输出与面向人类的错误信息，让代理调用时解析困难、易出错。新工具从设计之初就把机器可读性放在首位，目标是让代理一次调用即可获得明确、可判定的结果。</li>
 <li>新工具的关键改进集中在输出与接口语义上：命令输出采用结构化格式，行为可预测、格式稳定，避免人类风格的自由文本；错误信息也按机器解析的需要组织，方便代理识别失败原因并自动修正。对人类开发者而言，这类设计同样友好——结构化输出便于脚本化和管道处理，工具的可组合性反而提升。官方承诺现有 Wrangler 的核心功能会平滑迁移，并提供迁移文档，减少存量项目升级带来的断裂。</li>
 <li>Cloudflare 将这次工具链更替定位为对开发范式迁移的战略性响应，而非一次普通版本迭代。官方指出，基础设施厂商需要正视「代理成为一等调用方」的现实：工具链不仅要服务敲命令的人类，还要服务批量发起调用的自动化程序。这意味着命令命名、参数设计、返回结构、权限模型都要重新审视。文中判断，这只是开始，后续会有更多云厂商跟进，将代理友好性纳入开发者体验的正式设计目标。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 如果你关心 AI 代理如何真正改变开发者工具链，这是基础设施大厂第一个实打实的落地动作，值得当成行业风向标来读。</p>
<p>✍️ <strong>小编看法</strong>: 这件事值得认真看待，因为它把一个长期被含糊谈论的趋势变成了明确的工程决策。过去大家嘴上说「AI 会改变开发方式」，但落地动作大多停留在补全代码、写注释这类表层。Cloudflare 直接把自家最核心的开发者入口工具判了「逐步淘汰」，等于承认了一件事：工具链的第一用户可能不再是人。被忽略的代价值得指出来。Wrangler 承载了多年积累的社区脚本、教程、CI 配置和肌肉记忆，淘汰过程必然带来真实的迁移成本，尤其是那些把 Wrangler 命令写死在流水线里的团队。官方承诺平滑迁移，但历史经验告诉我们，CLI 语义级别的替换几乎总有边角案例，智能体时代还会多一层风险：如果代理学习的训练数据仍以旧命令为主，过渡期内可能出现新旧混用导致的故障排查难题。另一个耐人寻味的机会窗口在于：谁先把「代理友好」做成标准，谁就掌握了下一代开发者体验的定义权。输出格式、错误码规范、权限委托模型，这些看似枯燥的细节一旦成为事实标准，后来者很难绕开。Cloudflare 这一手其实是在抢标准位。对读者的建议很直接：如果你的团队已经在用代理自动化部署流程，现在就该评估新工具的结构化输出能否减少你的解析胶水代码；如果你的流水线还重度依赖 Wrangler，把它列入迁移计划吧，别等维护停止才被动应对。接下来值得观察的是：其他主流云厂商（AWS、Vercel 等）是否会以类似方式重构 CLI，以及各家输出格式能否走向某种共识——如果每家都自造一套代理接口，混乱反而会加剧。</p>
<p>🏷️ Cloudflare, CLI, AI agents, Wrangler</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/infoq-cn-cloudflare-ai-cli-wrangler-2a76aa52</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F05-infoq-cn-QyHB.jpg&amp;size=m" type="image/jpeg" length="20273"/><category>工具 / 开源</category><pubDate>Mon, 19 Oct 2026 23:05:05 GMT</pubDate></item><item><title><![CDATA[广告技术的技术政治学：监控利于科技公司，情境利于出版商]]></title><link>https://www.lxfzzw.com/archives/pluralistic-net-pluralistic-the-technopo-6f1fa0a9</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=%E5%B9%BF%E5%91%8A%E6%8A%80%E6%9C%AF%E7%9A%84%E6%8A%80%E6%9C%AF%E6%94%BF%E6%B2%BB%E5%AD%A6%EF%BC%9A%E7%9B%91%E6%8E%A7%E5%88%A9%E4%BA%8E%E7%A7%91%E6%8A%80%E5%85%AC%E5%8F%B8%EF%BC%8C%E6%83%85%E5%A2%83%E5%88%A9%E4%BA%8E%E5%87%BA%E7%89%88%E5%95%86&amp;url=/archives/pluralistic-net-pluralistic-the-technopo-6f1fa0a9" width="1" height="1" alt="" style="opacity:0;">
<h1>广告技术的技术政治学：监控利于科技公司，情境利于出版商</h1>
<p><a href="https://pluralistic.net/2026/10/19/spying-v-context/">Pluralistic: The technopolitics of ad-tech (19 Oct 2026)</a> — pluralistic.net · 15 小时前 · 💡 观点 / 杂谈</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F04-pluralistic-net.jpg&amp;size=m" alt="广告技术的技术政治学：监控利于科技公司，情境利于出版商"></p>
<blockquote>
 <p>这篇文章借用了学者兰登·温纳的经典命题「人造物是否具有政治性」，把广告技术放到技术政治学的框架下审视。所谓技术政治学，指的是政治被预先写入技术本身的形态之中——技术并非中立的工具，其设计选择就体现了某种权力关系和利益分配。作者从温纳那篇开创性论文的三分法出发：第一类是设计者刻意嵌入政治意图的人造物，最具代表性的例子是罗伯特·摩西在长岛公园大道上修建的桥梁；据摩西的传记作者罗伯特·卡罗考证，摩西刻意规定桥梁净高必须低到市公交车无法通过，以此阻挡依赖公共交通的黑人群体前往他在长岛开发的海滩，这些桥梁至今已矗立超过一个世纪。文章的核心论点落在广告技术行业的对立结构上：以谷歌、Meta 为代表的监控型广告技术，靠跨站追踪用户、聚合海量行为数据来投放大规模精准广告，这种技术架构天然有利于掌握数据基础设施的大型平台；而出版商真正需要的广告能力，强调的是「情境」——即广告与内容页面的语境匹配，比如在烹饪文章旁投放厨具广告。情境广告不需要追踪个人，不需要第三方 Cookie，也不需要数据中间商，它把价值留在内容生产者一方。作者的结论是：广告技术的技术形态本身就是一场政治斗争，监控范式与情境范式之争决定了数字经济的利润流向，而现行广告技术的设计明显偏向科技巨头、挤压出版商，改变这一格局需要从技术架构层面重新选择，而非仅靠政策修补。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>文章引入兰登·温纳的经典论文「人造物是否具有政治性」作为理论框架，将技术分为三类政治形态，主张分析技术不能停留在「预期后果」与「非预期后果」的层面，而要进入政治经济学的维度。这一框架强调：技术的设计决定本身就承载了权力关系，谁被便利、谁被排斥，往往在图纸阶段就已注定。</li>
 <li>第一类例证是罗伯特·摩西的长岛桥梁：传记作者罗伯特·卡罗考证指出，摩西刻意把公园大道桥梁的净高设计得低于公交车通行高度，利用穷人与富人、黑人与白人出行方式的差异，把不依赖私家车的群体挡在长岛海滩之外。这些桥梁已存在超过一百年，证明嵌入式政治可以长期固化在基础设施中。</li>
 <li>作者用这一框架剖析广告技术：监控式广告技术依赖跨站追踪、个人数据聚合与实时竞价，其架构天然把数据和利润集中到掌握用户画像与投放通道的大型平台手中；出版商在这种结构里只能充当廉价流量供给方，议价能力持续弱化。</li>
 <li>与之相对的是情境广告路径：广告依据页面内容的语境进行匹配，而非针对个人身份投放。这条路线不需要跟踪用户跨站行为，不需要第三方 Cookie 与数据中介，也不触碰隐私争议，其经济效果是把广告收入留在内容生产与发布环节，因而对出版商和整个新闻生态更加有利。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 它跳出了「隐私与效率」的老套辩论，用桥梁净高的经典案例揭示广告技术架构本身就是一场关乎利润归属的政治设计，视角新颖且与每个内容从业者的生计相关。</p>
<p>✍️ <strong>小编看法</strong>: 把广告技术放进「技术政治学」的框架里讨论，是这篇文字最锋利的地方。行业辩论通常被框定为隐私 versus 商业效率，仿佛问题只在于合规和监管。但摩西桥梁的例子提醒我们：真正持久的不平等，是写进基础设施里的。桥梁的净高一旦浇筑完成，政治就凝固成了混凝土，百年难以更改；同样，一个建立在跨站追踪和实时竞价基础上的广告生态，即便日后出台再多隐私法规，其财富分配的结构——平台吃肉、出版商喝汤——已经固化。被忽略的代价在于新闻业本身。过去二十年地方媒体和独立出版物的崩塌，常被归咎于读者不愿付费或内容质量下降，但广告收入的分配机制难辞其咎：监控式广告把绝大部分程序化广告收入抽走，内容生产者只能分到残羹。情境广告的复兴之所以值得认真对待，是因为它不只是隐私友好，更是一种利润再分配的技术方案——它让广告价值重新流向创造语境的人，而不是拥有追踪器的公司。当然也要保持清醒：情境广告的匹配精度和市场规模能否真正支撑起严肃新闻的经济模型，仍需观察；大型平台对无 Cookie 时代的表面欢迎背后，是否藏着新的围栏策略，同样值得警惕。下一步可以盯两件事：一是浏览器和监管方对第三方追踪的封杀进度，二是出版商自发联盟在情境化、第一方数据方向上的商业化成色。</p>
<p>🏷️ ad-tech, privacy, surveillance, publishers</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/pluralistic-net-pluralistic-the-technopo-6f1fa0a9</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F04-pluralistic-net.jpg&amp;size=m" type="image/jpeg" length="229317"/><category>观点 / 杂谈</category><pubDate>Mon, 19 Oct 2026 23:05:03 GMT</pubDate></item><item><title><![CDATA[AI Coding 中组件库接入的三种路径与可直接复用的指令案例]]></title><link>https://www.lxfzzw.com/archives/woshipm-com-ai-coding-4a8164f7</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=AI%20Coding%20%E4%B8%AD%E7%BB%84%E4%BB%B6%E5%BA%93%E6%8E%A5%E5%85%A5%E7%9A%84%E4%B8%89%E7%A7%8D%E8%B7%AF%E5%BE%84%E4%B8%8E%E5%8F%AF%E7%9B%B4%E6%8E%A5%E5%A4%8D%E7%94%A8%E7%9A%84%E6%8C%87%E4%BB%A4%E6%A1%88%E4%BE%8B&amp;url=/archives/woshipm-com-ai-coding-4a8164f7" width="1" height="1" alt="" style="opacity:0;">
<h1>AI Coding 中组件库接入的三种路径与可直接复用的指令案例</h1>
<p><a href="https://www.woshipm.com/ai/6478928.html">AI Coding中组件库的接入技巧+保姆级指令案例！</a> — woshipm.com · 15 小时前 · ⚙️ 工程</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F03-woshipm-com-MIdL.jpg&amp;size=m" alt="AI Coding 中组件库接入的三种路径与可直接复用的指令案例"></p>
<blockquote>
 <p>AI IDE 已经成为前端开发和物料搭建的核心工具，但一个普遍痛点是：让 AI 准确调用团队组件库并不容易。作者结合大厂项目实践，梳理了 AI Coding 场景下组件库接入的三条路径——npm 包、MCP 与 Skills——并给出可直接复制修改的指令模板。第一条路径是 npm 包接入：npm 包相当于 AI 可直接使用的真实组件代码。作者指出一个常见误区——不装 npm 包时 AI 也能写出「AntD 风格」的页面，但那只是 AI 用手写 CSS 和 HTML 模仿出来的外观，与 AntD 组件代码毫无关系，缺少交互逻辑、无障碍支持和主题系统；只有安装组件库 npm 包后，AI 才真正调用组件的真实代码，产出自带完整交互逻辑与主题能力的有效代码。作者建议从零搭建的 Vibe Coding 项目在项目开始时即输入约束性 Prompt，明确技术栈、安装命令、引用方式，并规定所有组件优先从内部组件库引用、不得自行用 HTML/CSS 重写、不装 antd 或 shadcn/ui 等其他库、不确定 API 时先确认再写代码。第二条路径是 MCP 接入：MCP 相当于给 AI 开放外部工具连接接口，让 AI 能主动查询组件文档、示例代码、确认 API 是否有效，核心价值是解决 AI 靠记忆生成代码导致使用过时 API 的问题。但 MCP 的制作和维护需要研发人员投入，门槛较高，前提是组件库有对应的 MCP Server，例如 Ant Design 已有官方 MCP Server 可直接部署。接入后应在 Prompt 中声明 search_component、get_component、get_component_code、list_components 等可用工具，并强制要求 AI 写任何组件前必须先调用工具获取文档，不得凭记忆编写，不确定组件是否存在时先搜索。文章整体结论是：npm 包解决「用上真组件」，MCP 解决「用到新文档」，两条路径分别对准不同层面的准确性问题，团队应按组件库的维护能力选择组合方案。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>npm 包路径的核心价值在于让 AI 使用真实组件代码而非模仿外观：没有安装组件库 npm 包时，AI 写出的「AntD 风格」页面只是用手写 CSS 和 HTML 模仿视觉样式，与真实组件代码无关，缺少交互逻辑、无障碍支持和主题系统；安装后 AI 才能真正调用组件源码，产出结构真实有效的页面。作者给出的 Prompt 模板包含技术栈声明、npm install 安装命令、以及六条组件使用规则，例如所有组件优先从内部组件库引用、禁止安装 antd 与 shadcn/ui 等其他库、不确定 API 时先报组件名等开发者确认、样式不生效时检查入口文件是否需要引入样式。</li>
 <li>MCP 路径解决的是组件信息时效性问题：不接入 MCP 时 AI 只能靠训练记忆生成组件代码，容易使用已废弃或过时的 API；接入后 AI 可通过 search_component 搜索组件是否存在、get_component 获取详细文档与 Props、get_component_code 获取示例代码、list_components 列出全部可用组件。配套 Prompt 中的硬性规则是写任何组件前必须先调用 get_component 获取文档、不得凭记忆编写，不确定组件是否存在时必须先调用 search_component，把 AI 从「背文档」改为「查文档」。</li>
 <li>MCP 路径有明确的适用前提：MCP Server 通常需要研发人员制作和维护，管理与部署门槛较高，并非所有组件库都具备接入条件；目前 Ant Design 已提供官方 MCP Server，可直接部署应用。这意味着团队能否走 MCP 路线取决于自身研发投入，而 npm 包路线门槛更低、更适合作为起步方案，组件库维护能力强的团队可以两条路径并用。</li>
 <li>文章隐含的判断框架是三条路径对应三种准确性问题：npm 包保证 AI 用的是真实组件而非仿制品，MCP 保证用的是最新 API 而非过时记忆，Skills 则承载团队规范与使用约束。作者强调 Prompt 应在项目开始阶段就注入，而不是等问题出现后再补，并且提供了文中指令可复制后按团队实际情况微调使用的实操建议。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 它把「AI 用不好组件库」这个模糊抱怨拆成了 npm 包与 MCP 两条可落地的技术路径，还附带了拿来即用的指令模板，是少见的从踩坑经验直接到操作手册的实操文章。</p>
<p>✍️ <strong>小编看法</strong>: 这篇文章点破了一个很多团队踩过却没说透的坑：AI 写出「像」的页面和「对」的页面之间隔着整整一层工程 reality。视觉相似性是最容易骗人的，评审时肉眼几乎看不出区别，但没接组件库的页面在暗色模式、键盘导航、国际化这些场景下会成批露馅，而那时候重写的成本已经翻了几倍。我觉得文章最有价值的是把「准确性」拆成了两个不同的问题——调用真实性和信息新鲜度，前者靠 npm 包解决，后者靠 MCP 解决，很多团队只做了第一层就以为完事了，结果 AI 一边引用着你们的真组件，一边写着两年前已废弃的 API，这种混合错误反而更难排查。有几点延伸值得补充。第一，Prompt 里那句「不确定 API 时先确认再写代码」其实是整篇模板里性价比最高的一条，它把 AI 从强行猜测改成了主动提问，团队落地时应该把「确认环节」制度化，比如要求 AI 先输出组件与 Props 清单再动笔。第二，MCP 的维护成本被很多团队低估——组件库每次发版，MCP Server 的文档同步就是一笔持续投入，如果组件库迭代快而维护人手不足，MCP 会迅速腐烂成新的「过时信息源」，这比不接 MCP 更危险。第三，这条路径对设计系统的意义可能比组件库更大：物料、token、布局规范都可以沿同样思路灌给 AI，行业下一步值得观察的是组件库厂商会不会把 MCP Server 做成发行包的标准配件，就像当年的 TypeScript 类型定义一样成为默认标配。</p>
<p>🏷️ AI coding, component library, MCP, frontend</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/woshipm-com-ai-coding-4a8164f7</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F03-woshipm-com-MIdL.jpg&amp;size=m" type="image/jpeg" length="39173"/><category>工程</category><pubDate>Mon, 19 Oct 2026 23:05:01 GMT</pubDate></item><item><title><![CDATA[OpenCode 遭攻击：约 1.4% 用户 API 密钥可能外泄，处置要点全梳理]]></title><link>https://www.lxfzzw.com/archives/woshipm-com-opencode-openai-anthropic-ap-379451b8</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=OpenCode%20%E9%81%AD%E6%94%BB%E5%87%BB%EF%BC%9A%E7%BA%A6%201.4%25%20%E7%94%A8%E6%88%B7%20API%20%E5%AF%86%E9%92%A5%E5%8F%AF%E8%83%BD%E5%A4%96%E6%B3%84%EF%BC%8C%E5%A4%84%E7%BD%AE%E8%A6%81%E7%82%B9%E5%85%A8%E6%A2%B3%E7%90%86&amp;url=/archives/woshipm-com-opencode-openai-anthropic-ap-379451b8" width="1" height="1" alt="" style="opacity:0;">
<h1>OpenCode 遭攻击：约 1.4% 用户 API 密钥可能外泄，处置要点全梳理</h1>
<p><a href="https://www.woshipm.com/ai/6480379.html">OpenCode遭攻击：部分用户OpenAI、Anthropic等API密钥外泄</a> — woshipm.com · 13 小时前 · 🔒 安全</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F02-woshipm-com-tgqc.jpg&amp;size=m" alt="OpenCode 遭攻击：约 1.4% 用户 API 密钥可能外泄，处置要点全梳理"></p>
<blockquote>
 <p>AI 编程工具 OpenCode 披露了一起安全事件：处于停用流程中的旧系统遭到未授权访问，旧系统的访问控制失效，导致约 1.4% 的 OpenCode Console 用户工作区中保存的 OpenAI、Anthropic 等外部服务 API 密钥可能暴露。事件发生于当地时间 10 月 16 日，受影响用户随后通过邮件接到通知，相关团队正与 Anthropic、OpenAI 和谷歌协作处置，但攻击路径、受影响记录规模和密钥是否已被实际使用均未完整公开，披露中提到的「大规模蒸馏攻击」也不应被业务方当作自行推断攻击手法的依据。泄露的 API 密钥带来两类风险：一是直接费用损失，攻击者可以密钥持有者身份发起模型或云服务请求，账单先记到原账户，已有用户反馈出现数百美元级别的异常费用，也有项目因过度滥用被暂停；二是服务与数据风险，若密钥同时拥有文件、日志、工具调用或管理权限，影响会扩大到信息暴露与工作流中断。文章给出的处置原则是：只要某把密钥有机会被复制，就按已泄露处理，不要等确认滥用后再行动。前 30 分钟的关键动作分三步：先到各供应商控制台撤销或禁用可疑密钥，范围覆盖外部服务密钥、Agent 与 CI 等共享凭据、旧环境遗留密钥和高权限 Token，且不能只改本地 .env 或 SaaS 配置；再生成按环境、用途、权限拆分的新密钥，配独立限额、标签与最小权限，能启用项目级密钥、IP 白名单、速率限制的尽量启用；最后核对账单、请求日志与告警时间线，重点排查短时间内 Token 与并发突增、非业务时段或陌生地域调用、从未用过的接口等信号。文章还强调停用中的旧系统是风险最集中时期，应把下线拆成停止接入、凭据处置、数据清理、基础设施销毁等可验证阶段，每个阶段有明确验收信号。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>事件的基本盘：OpenCode 处于停用流程中的旧系统访问控制失效并遭未授权访问，影响范围约为 OpenCode Console 用户的 1.4%，潜在暴露的是这些用户工作区中保存的 OpenAI、Anthropic 等外部服务 API 密钥。事件发生于当地时间 10 月 16 日，受影响用户已收到邮件通知，团队正与三家模型供应商协作，但攻击路径、涉及记录规模和密钥实际使用情况尚未完整公开，已有用户报告数百美元级异常费用和项目被暂停的个案。</li>
 <li>应急处置的优先级是先撤销再重建：进入每个供应商控制台撤销与受影响工作区关联的密钥，覆盖外部服务密钥、Agent 与 CI 及代码审查机器人的共享凭据、旧环境遗留密钥、以及可创建新密钥或修改账单的高权限 Token；不能只修改本地 .env 或删除 SaaS 工具里的配置，因为只要供应商侧密钥仍有效，泄露副本就仍可被调用。新密钥应按环境、应用和用途拆分，各自设置独立限额、可追踪标签和最小权限，并优先启用项目级密钥、IP 白名单、速率限制等约束。</li>
 <li>密钥轮换只能阻断后续损失，已发生的调用需要靠账单与日志审计来还原：应按密钥、项目、模型、地区、时间段和调用量核对供应商日志，重点信号包括短时间内 Token 数与并发突增、非业务时段或陌生网络的调用、从未使用过的模型与接口类型、以及额度耗尽或风控提醒的触发时间点。把异常区间与事件通知时间、内部部署记录、密钥创建时间放在同一条时间线上，是后续申诉退款和安全复盘的证据基础。</li>
 <li>最容易被忽略的是旧系统风险：团队常以为下线中的系统不再有安全价值，实际上停用期流量已迁走、监控开始松动，但数据库、备份、环境变量、CI 变量、调试日志、容器镜像层和遗留管理员账号都还在。可靠的下线流程应拆成可验证的阶段——停止接入、凭据处置、数据清理、基础设施销毁，每一步都有验收信号，例如旧 Token 无法再认证通过、抽样扫描不再发现有效密钥等。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 一次真实发生且直接影响普通开发者的密钥泄露事件，给出了从撤销密钥到核对账单的可执行清单，对任何把 API 密钥交给第三方工具的团队都是一堂必修课。</p>
<p>✍️ <strong>小编看法</strong>: 这起事件的样本价值比它的规模更重要。1.4% 听起来不大，但它戳破了一个行业幻觉：大家默认 AI 编程工具的风险在「生成的代码有没有漏洞」，而这次出事的是工具本身作为凭据集散地的基础设施属性。想想现在一个开发者的密钥暴露面有多大——终端工具、浏览器扩展、SaaS 工作区、CI 变量，每个环节都在复制同一批高价值凭据，而大多数团队对密钥的管理水平还停留在共享一个 .env 文件的阶段。我认为有三个被普遍低估的点。第一，「按已泄露处理」的原则值得写进每个团队的应急预案：等你查清楚密钥有没有被用，攻击者早就跑完一轮账单了，止损和取证必须并行而不是串行。第二，费用类攻击的隐蔽性被低估了——异常账单几百美元，很多人第一反应是怀疑自己忘记关掉某个定时任务，而不是怀疑密钥泄露，等意识到时账单已经滚了几周，所以账单告警的阈值设置应该和密钥管理放在同一个安全清单里。第三，下线期的系统治理是个无底洞，文中那张分阶段退役表格值得抄进内部流程，尤其是「抽样扫描无有效密钥」这种可验证的验收信号，比「我们下线了」这种口头结论可靠得多。往大了看，随着 Agent 被授予越来越多的密钥和权限，行业迟早需要一套类似密钥托管与自动轮换的标配方案，也许这起事件会成为推动供应商把细粒度权限、每日上限做成默认配置的契机。读者接下来值得盯的是 OpenCode 后续的完整事故报告，特别是「蒸馏攻击」的真正含义。</p>
<p>🏷️ API key, data breach, security incident, OpenCode</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/woshipm-com-opencode-openai-anthropic-ap-379451b8</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F02-woshipm-com-tgqc.jpg&amp;size=m" type="image/jpeg" length="19018"/><category>安全</category><pubDate>Mon, 19 Oct 2026 23:04:59 GMT</pubDate></item><item><title><![CDATA[Claude Code 桌面版重大更新：嵌套会话、状态侧边栏与环境隔离]]></title><link>https://www.lxfzzw.com/archives/woshipm-com-claude-code-6088a0a0</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=Claude%20Code%20%E6%A1%8C%E9%9D%A2%E7%89%88%E9%87%8D%E5%A4%A7%E6%9B%B4%E6%96%B0%EF%BC%9A%E5%B5%8C%E5%A5%97%E4%BC%9A%E8%AF%9D%E3%80%81%E7%8A%B6%E6%80%81%E4%BE%A7%E8%BE%B9%E6%A0%8F%E4%B8%8E%E7%8E%AF%E5%A2%83%E9%9A%94%E7%A6%BB&amp;url=/archives/woshipm-com-claude-code-6088a0a0" width="1" height="1" alt="" style="opacity:0;">
<h1>Claude Code 桌面版重大更新：嵌套会话、状态侧边栏与环境隔离</h1>
<p><a href="https://www.woshipm.com/ai/6480382.html">Claude Code桌面版迎来重大更新</a> — woshipm.com · 15 小时前 · 🤖 AI / ML</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F01-woshipm-com.gif&amp;size=m" alt="Claude Code 桌面版重大更新：嵌套会话、状态侧边栏与环境隔离"></p>
<blockquote>
 <p>Anthropic 给 Claude Code 桌面版推送了一轮被团队成员形容为「几乎是一个 v2」的大更新，核心不再是让单个 Agent 跑得更快，而是解决多个 Agent 并行工作之后，人的注意力跟不上会话数量的管理问题。更新中最关键的能力是嵌套会话：当一项工作可以拆成若干独立子任务时，Claude 会主动为每个子任务创建子会话，让它们并行读代码、改文件、跑测试，完成后向父会话汇报进度。官方演示里，Claude 在修复商品网格布局抖动时顺带发现了三个后续问题——购物车缩略图未设置宽高、首屏以下图片未启用懒加载、结账表单缺少 label——开发者点击 Start all 后三个子会话同时开工。子会话的试错过程不会挤满主对话，任务卡住时也能进入对应子会话查看完整上下文。新侧边栏把会话按 Needs input、Working、Completed 三种状态分组，配合实时待办清单、回顾卡片、系统通知和 Cmd 点击分屏，让开发者一眼知道该处理哪个会话。新建会话界面新增「环境」功能，可把多个文件夹、SSH 主机或云端资源保存成命名配置，一套环境可同时纳入前端项目、支付 API 和设计系统等多个仓库并统一设置环境变量，支持 Local、Cloud、SSH、Remote Control 四种连接方式。针对多会话同时改同一仓库的冲突问题，每个文件夹可独立选分支并启用 Git worktree，默认创建在项目的 .claude/worktrees/ 目录下，实现文件修改隔离。文章还提到了 /btw、空闲压缩、主动跟进等细节，以及 .env 等被 .gitignore 忽略的文件不会自动出现在新 worktree、需要写入 .worktreeinclude 的坑。作者的结论是：Agent 编程工具的竞争焦点已经从模型输出质量转向多会话协作下的人类注意力管理，桌面端这轮更新正是在系统性地回收被并行任务打碎的开发者注意力。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>嵌套会话是本次更新最核心的新能力：当主任务可以拆分时，Claude 会主动创建多个子会话并行执行子任务，各自独立读代码、改文件、跑测试，再把结果汇报给父会话。官方演示中，Claude 在处理商品网格布局抖动时额外识别出缩略图缺宽高、图片未懒加载、结账表单缺 label 三个问题，一键 Start all 即可同时开工。这种结构既避免子任务的命令输出和试错过程污染主对话，也让卡住的任务可以单独进入子会话查看完整上下文继续处理。</li>
 <li>新侧边栏把多会话管理作为第一优先级，将所有会话划分为等待输入、执行中、已完成三种状态分组展示，解决了会话按时间顺序混杂时用户无法快速判断下一步该看哪里的痛点。会话内部提供随执行进度逐项勾选的待办清单，需要人工回应时用回顾卡片概括本轮改动，免去重读整段对话；此外还支持后台会话完成后的系统通知，以及按住 Cmd 点击会话实现左右分屏对照。</li>
 <li>「环境」功能允许用户把多个文件夹、一台 SSH 主机或云端资源保存为一套命名环境，支持本地、云端、SSH、远程控制四类连接方式，一套本地环境可同时纳入前端项目、支付 API、设计系统等多个仓库并统一配置环境变量，适合跨仓库开发与微服务联调。配合 Git worktree 隔离机制，多个会话修改同一仓库时各自在 .claude/worktrees/ 目录下的独立工作树中操作，避免文件互相覆盖。</li>
 <li>一个容易踩坑的细节是：.env 等被 .gitignore 忽略的文件不会自动复制到新建的 worktree 中，如果子会话依赖这些配置文件，必须将路径写入 .worktreeinclude 文件，否则新会话可能因缺少环境变量而运行失败。按照相关文档，Claude 还可以访问最近活跃的其他会话，执行列出、读取、发消息、重命名或归档等操作，会话之间开始具备协作能力而不再是孤立的聊天窗口。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 当所有人都在讨论模型能力时，这篇文章展示了 Agent 工具竞争的下一个战场——多会话并行下的人类注意力管理，对正在构建或选型 AI 编程工作流的团队有直接的落地参考价值。</p>
<p>✍️ <strong>小编看法</strong>: 这轮更新值得认真看一眼，因为它暴露了 Agent 编程工具真正的战场转移。过去大家比的是单次代码生成质量、上下文长度、模型聪明程度；现在 Anthropic 明显把力气花在了「人怎么管住一群 Agent」上。这是个信号：当并行执行成为常态，瓶颈不在算力也不在模型，而在开发者每天有限的注意力。一个开发者同时开五六个会话，如果每个会话都需要盯着看，效率提升其实是负数——多出来的会话只是多出来的焦虑。侧边栏的三态分组、待办清单、回顾卡片，本质上都是在降低「确认成本」，这类设计以前是给运维监控面板用的，现在被搬进了编程工具。有几个被低估的点值得展开。其一是嵌套会话带来的责任边界问题：子会话自己发现并启动的新任务，最终质量责任还在人这边，Start all 一键全开很爽，但三个子任务的验收标准是否清晰、测试覆盖是否足够，工具目前并没有强制约束，滥用的话可能批量产出「看起来完成了」的代码。其二是 worktree 隔离虽然优雅，但只解决了文件冲突，没解决语义冲突——两个会话各自改出一个能跑的版本，合并时照样可能打架，这块工具链还留白。其三是 .worktreeinclude 这种细节暴露了沙箱方案的固有成本：隔离越彻底，环境复刻的坑越多，团队落地时最好把 worktree 初始化纳入 CI 之外的本地脚本规范。对行业而言，下一步值得观察两点：一是 Cursor、Copilot Workspace 等竞品何时跟进类似的会话编排能力，二是有没有第三方做出跨工具的 Agent 任务看板——如果 Anthropic 把这层牢牢绑在自己桌面端，工具锁定效应会进一步加深。</p>
<p>🏷️ Claude Code, coding agent, parallel sessions, update</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/woshipm-com-claude-code-6088a0a0</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F01-woshipm-com.gif&amp;size=m" type="image/jpeg" length="5010244"/><category>AI / ML</category><pubDate>Mon, 19 Oct 2026 23:04:56 GMT</pubDate></item><item><title><![CDATA[没有议程、不急不躁、不离开旧金山：Benchmark 合伙人谈如何在狂热市场中做投资]]></title><link>https://www.lxfzzw.com/archives/techcrunch-com-no-agenda-no-rush-no-leav-cbe3a160</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=%E6%B2%A1%E6%9C%89%E8%AE%AE%E7%A8%8B%E3%80%81%E4%B8%8D%E6%80%A5%E4%B8%8D%E8%BA%81%E3%80%81%E4%B8%8D%E7%A6%BB%E5%BC%80%E6%97%A7%E9%87%91%E5%B1%B1%EF%BC%9ABenchmark%20%E5%90%88%E4%BC%99%E4%BA%BA%E8%B0%88%E5%A6%82%E4%BD%95%E5%9C%A8%E7%8B%82%E7%83%AD%E5%B8%82%E5%9C%BA%E4%B8%AD%E5%81%9A%E6%8A%95%E8%B5%84&amp;url=/archives/techcrunch-com-no-agenda-no-rush-no-leav-cbe3a160" width="1" height="1" alt="" style="opacity:0;">
<h1>没有议程、不急不躁、不离开旧金山：Benchmark 合伙人谈如何在狂热市场中做投资</h1>
<p><a href="https://techcrunch.com/2026/10/18/no-agenda-no-rush-no-leaving-san-francisco-benchmarks-partners-on-investing-in-a-frenzied-market/">No agenda, no rush, no leaving San Francisco: Benchmark’s partners on investing in a frenzied market</a> — techcrunch.com · 2 小时前 · 💡 观点 / 杂谈</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F05-techcrunch-com-JhPA.webp&amp;size=m" alt="没有议程、不急不躁、不离开旧金山：Benchmark 合伙人谈如何在狂热市场中做投资"></p>
<blockquote>
 <p>Benchmark 是硅谷历史最悠久、声望最高的早期投资机构之一，近期其基金规模有所扩大，合伙团队也经历了一些更替，目前留下五位合伙人。在 TechCrunch 大会上，这五位合伙人同台交流，谈到了他们在一个由热点驱动的狂热投资市场中的立场与策略。他们的态度可以概括为三点：不设固定投资议程、保持不急于出手的节奏、坚持留在旧金山本地开展业务。与许多同行大举扩张基金规模、追逐热门赛道的做法不同，Benchmark 依然强调小团队、共识决策和与创始人深度绑定的早期投资方式。尽管市场环境在技术浪潮推动下竞争激烈、估值飞涨，这家机构的合伙人 onstage 表现出的状态更像一群老朋友在聊天，而非照本宣科地宣讲投资理论——他们管理着硅谷最具传奇色彩的机构之一，却依然保持着小而紧密的运作方式。这场对话透露的核心信息是：在市场情绪高涨、人人都怕错过的时候，克制和纪律本身就是一种差异化策略，而 Benchmark 选择继续用它惯有的节奏和地理据点来应对这轮狂热。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>Benchmark 近期完成了基金规模扩张和合伙人更替，目前留下五位合伙人，但团队 onstage 的状态更像朋友聚会，保持着这家硅谷老牌机构一贯的小团队、紧密协作氛围，而非大机构常见的层级化运作。</li>
 <li>面对狂热的市场环境，这五位合伙人明确表达了三条原则：不预设投资议程、不急于追赶市场节奏、坚持留在旧金山开展投资工作，这与许多机构在热点周期中大举扩张、四处布点的做法形成鲜明对比。</li>
 <li>作为硅谷最具传奇色彩的早期投资机构之一，Benchmark 在估值飞涨、竞争白热化的背景下依然坚持克制的投资纪律，这场对话传递的核心观点是：在人人都怕错过的时刻，慢节奏和小规模本身就是一种竞争策略。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 在人人追逐风口的时代，了解一家刻意做小、做慢的顶级机构如何思考克制与纪律，对投资人、创业者乃至任何做决策的人都是一面镜子。</p>
<p>✍️ <strong>小编看法</strong>: Benchmark 这场对话最耐人寻味的地方，是它把「不做什么」当成策略来讲。在一个几乎所有机构都在膨胀的周期里——更大的基金、更多的合伙人、更广的地域覆盖——坚持小团队和慢节奏看似保守，实则是一种需要极大自信的选择。因为基金规模越大，就越需要投出更多大额支票才能维持回报倍数，机构的行为逻辑会不可避免地被资本规模改变；Benchmark 多年来刻意控制基金体量，等于主动放弃了管理费规模，换取的是决策自由和早期定价权。这种自律在狂热期最稀缺，也最难模仿。另外，「不离开旧金山」这句话在远程办公盛行的当下值得咀嚼：早期投资的本质是在创始人最脆弱、信息最不对称的阶段下注，线下密度带来的信息优势和信任建立，可能恰恰是远程协作无法替代的护城河。当然，也要看到这种模式的天花板——它依赖少数顶尖合伙人的个人判断力和声誉网络，无法复制也难以规模化，一旦核心人员流失，机构价值会迅速折损，近期的合伙人更替就是现实提醒。对普通读者和创业者来说，值得观察的下一步是：在这轮浪潮退去后，Benchmark 的组合表现是否依然跑赢那些重仓追热的同行；以及有没有新机构成功复制这种「小而精」模式，证明它在下一个周期依然成立。</p>
<p>🏷️ venture capital, Benchmark, startup funding, Silicon Valley</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/techcrunch-com-no-agenda-no-rush-no-leav-cbe3a160</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F05-techcrunch-com-JhPA.webp&amp;size=m" type="image/jpeg" length="49304"/><category>观点 / 杂谈</category><pubDate>Sun, 18 Oct 2026 23:04:21 GMT</pubDate></item><item><title><![CDATA[开源项目 Husk 2.0 发布：通过自研翻译层让 iPhone 运行 Android 游戏，已兼容超 150 款应用]]></title><link>https://www.lxfzzw.com/archives/ithome-com-husk-2-0-iphone-android-150-91a50781</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=%E5%BC%80%E6%BA%90%E9%A1%B9%E7%9B%AE%20Husk%202.0%20%E5%8F%91%E5%B8%83%EF%BC%9A%E9%80%9A%E8%BF%87%E8%87%AA%E7%A0%94%E7%BF%BB%E8%AF%91%E5%B1%82%E8%AE%A9%20iPhone%20%E8%BF%90%E8%A1%8C%20Android%20%E6%B8%B8%E6%88%8F%EF%BC%8C%E5%B7%B2%E5%85%BC%E5%AE%B9%E8%B6%85%20150%20%E6%AC%BE%E5%BA%94%E7%94%A8&amp;url=/archives/ithome-com-husk-2-0-iphone-android-150-91a50781" width="1" height="1" alt="" style="opacity:0;">
<h1>开源项目 Husk 2.0 发布：通过自研翻译层让 iPhone 运行 Android 游戏，已兼容超 150 款应用</h1>
<p><a href="https://www.ithome.com/1/014/576.htm">开源项目 Husk 2.0 公布：利用自研翻译层让苹果 iPhone 运行 Android 游戏，兼容超 150 款应用</a> — ithome.com · 11 小时前 · 🛠 工具 / 开源</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F04-ithome-com-SPHO.png&amp;size=m" alt="开源项目 Husk 2.0 发布：通过自研翻译层让 iPhone 运行 Android 游戏，已兼容超 150 款应用"></p>
<blockquote>
 <p>独立开发者 Leviidev 公布了开源项目 Husk 2.0，其核心思路不是在 iPhone 上模拟一台完整的 Android 设备，而是构建一个翻译层，让 Android 应用中的 64 位原生代码直接跑在苹果的处理器上。它与 QEMU 这类传统方案的差别在于：传统模拟器要启动整套系统、加载内核并运行各种系统服务，开销大、启动慢；Husk 则跳过了完整系统环境，把游戏的 DEX 字节码和 .so 动态库直接装载进一个普通的 iOS 应用进程里，由项目自身补齐游戏所需的 Android 运行环境。具体实现上，Husk 提供了 C 函数库和游戏需要调用的 Java 接口，图形方面通过 ANGLE 把 OpenGL ES 调用转换成苹果平台的图形接口，并用 MoltenVK 提供 Vulkan 支持，音频、触控和手柄输入也都在处理范围内。为了支撑这套流程，作者把 Android Runtime（ART）编译出 iOS 版本，将 Android 的 bionic 函数库接口映射到 iOS 系统层，还自研了 .so 动态库加载器。由于原生代码是在实体 CPU 上直接执行而非被模拟，省去了完整系统模拟的开销，部分游戏能在数秒内启动。兼容性方面，项目支持 iOS 16 及以上系统，不需要越狱，可导入 APK、XAPK、APKM、APKS 四种安装包格式，也能处理 Google Play 的分割安装包；引擎层面覆盖 Unity、Unreal Engine 4、Godot 3 和 Godot 4，同时兼容 cocos2d-x、SDL2 与 SDL3，经典作品《GTA：圣安地列斯》也能跑起来。目前兼容应用已超过 150 款。不过它并不适合普通用户：Husk 依赖即时编译能力，而 iOS 对 JIT 权限管控严格，通常要借助调试器等方式才能授予；启用后还需侧载部署，且同一时间只能运行一款应用，切换游戏必须完全关闭再重启。整体上这是一个面向爱好者的尝鲜项目，代码托管在 GitHub 上。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>Husk 2.0 的技术路线是翻译层而非模拟器：它不启动完整 Android 系统，而是把应用的 DEX 文件和 .so 动态库直接加载进普通 iOS 进程，自行提供 C 函数库、Java 接口等运行环境，因此原生代码可在实体 CPU 上直接执行，省掉系统模拟开销，部分游戏数秒内即可启动。</li>
 <li>图形与外设的适配是这套方案的关键环节：项目通过 ANGLE 把 OpenGL ES 调用转换为苹果平台的图形接口，借助 MoltenVK 补上 Vulkan 支持，同时处理了音频输出、触控操作和手柄输入；底层则由 iOS 版 Android Runtime（ART）、bionic 函数库接口映射和自研 .so 加载器三部分共同构成兼容层。</li>
 <li>兼容性数据相当亮眼：项目支持 iOS 16 及以上系统且无需越狱，已兼容超过 150 款应用，可导入 APK、XAPK、APKM、APKS 及 Google Play 分割安装包，引擎覆盖 Unity、Unreal Engine 4、Godot 3/4，还兼容 cocos2d-x、SDL2、SDL3，并能运行《GTA：圣安地列斯》这类经典作品。</li>
 <li>使用门槛依然不低：Husk 依赖 JIT 即时编译，而 iOS 对该权限限制严格，通常需要通过调试器等方式授予；之后还要以侧载方式部署，且一次只能运行一款应用，切换游戏需完全关闭并重启，目前只适合爱好者尝鲜，项目已在 GitHub 开源。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 它用一份开源代码证明了 iPhone 与 Android 应用之间的墙更多是策略而非技术问题，对关心跨平台、移动生态与苹果政策的读者都有启发。</p>
<p>✍️ <strong>小编看法</strong>: 这类项目的价值往往不在「能不能用」，而在它撕开了一道口子，让人们重新审视移动平台之间那堵墙究竟有多厚。Husk 证明了一件事：iOS 与 Android 应用之间的鸿沟，本质上更多是生态策略与权限壁垒，而非真正的技术不可逾越。把 ART 编译到 iOS、把 bionic 接口映射过去、用 ANGLE 和 MoltenVK 打通图形栈，这些工作单个看都不算革命性，但组合起来就构成了一份「跨平台兼容其实可行」的公开证明。被忽略的代价也很明显：JIT 权限要靠调试器授予，说明整个方案活在苹果政策允许的灰色地带里，一次系统更新或审核规则收紧就可能让部署路径失效；单一应用运行、切换需重启的体验，也注定它短期内只能是极客玩具而非日常工具。但它真正的长期意义可能在于三点：一是为跨平台游戏移植提供了低成本验证手段，开发者可以先用它测试 Android 版本在苹果芯片上的表现；二是给监管讨论提供了具体案例——当侧载在欧洲因数字市场法案逐步开放后，这类兼容层会不会成为新的应用分发形态；三是它展示了单人开发者依然能在系统级软件上做出令人惊讶的东西。接下来值得盯几个信号：兼容名单的扩张速度、苹果对 JIT 授权与侧载政策的态度变化，以及会不会有团队把这套思路产品化。如果欧盟侧载生态成熟，Husk 这类项目可能从玩具进化成真正的桥。</p>
<p>🏷️ translation layer, iOS, Android, open source</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/ithome-com-husk-2-0-iphone-android-150-91a50781</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F04-ithome-com-SPHO.png&amp;size=m" type="image/jpeg" length="148624"/><category>工具 / 开源</category><pubDate>Sun, 18 Oct 2026 23:04:19 GMT</pubDate></item><item><title><![CDATA[深入英特尔 8087 芯片内部：浮点加法与减法]]></title><link>https://www.lxfzzw.com/archives/righto-com-inside-the-intel-8087-chip-fl-d29dfe1f</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=%E6%B7%B1%E5%85%A5%E8%8B%B1%E7%89%B9%E5%B0%94%208087%20%E8%8A%AF%E7%89%87%E5%86%85%E9%83%A8%EF%BC%9A%E6%B5%AE%E7%82%B9%E5%8A%A0%E6%B3%95%E4%B8%8E%E5%87%8F%E6%B3%95&amp;url=/archives/righto-com-inside-the-intel-8087-chip-fl-d29dfe1f" width="1" height="1" alt="" style="opacity:0;">
<h1>深入英特尔 8087 芯片内部：浮点加法与减法</h1>
<p><a href="http://www.righto.com/2026/10/8087-addition-subtraction-microcode.html">Inside the Intel 8087 chip: floating-point addition and subtraction</a> — righto.com · 6 小时前 · ⚙️ 工程</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F03-righto-com-WrYV.jpg&amp;size=m" alt="深入英特尔 8087 芯片内部：浮点加法与减法"></p>
<blockquote>
 <p>知名芯片拆解博主 Ken Shirriff 在其博客 righto.com 发文，深入剖析了 1980 年英特尔推出的 8087 浮点协处理器如何实现浮点加法与减法运算。8087 是让 IBM PC 及其他系统浮点运算速度大幅提升的关键芯片，除了正切、平方根、对数这类高级运算，它最基础的工作就是加减法。与 8086 处理器相比，8087 把加法速度提高了近 100 倍，复杂运算的加速幅度更大。为了搞清芯片内部结构，作者用凿子打开芯片封装，在显微镜下拍摄出高分辨率裸片照片。从照片可以看到，裸片中央的大矩形区域是微码 ROM，存放着 1648 条控制芯片运行的微指令；裸片下半部分是数据通路，负责对 80 位数值执行浮点计算。进一步放大后，可以看清加减法所依赖的各个功能模块：位于中心的是整数加法器，一个操作数来自 B 寄存器，另一个来自临时寄存器或栈寄存器等部件，加法结果存入 sum 寄存器。数据通路中占据大量面积的是移位器，其电路设计允许数值在任意位数上快速左右移动，这是浮点运算对齐操作数的核心；配套的前导零计数电路则负责统计数值左侧零位或零字节的数量，以便移位器将其移除。文章还详细讲解了浮点加减法实现中针对无穷大等特殊值的大量特殊情况处理，通过微码与电路两个层面完整还原了这颗 45 年前芯片的运算原理。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>8087 于 1980 年推出，是 IBM PC 等系统的浮点协处理器，相比 8086 主处理器，它将加法运算加速了近 100 倍，正切、平方根、对数等复杂运算的提速幅度更为惊人。</li>
 <li>作者通过物理开盖加显微镜拍摄获得高分辨率裸片图像：中央的微码 ROM 存有 1648 条微指令，下半部分数据通路负责 80 位浮点数值的运算，两个区域共同构成芯片的控制与计算核心。</li>
 <li>加法运算的关键部件是位于数据通路中心的整数加法器：一个操作数由 B 寄存器提供，另一个来自临时寄存器或栈寄存器，计算结果写入 sum 寄存器，整条路径清晰可循。</li>
 <li>移位器占据裸片上可观面积，其电路支持数值按任意位数快速左右移动，用于浮点数的对阶操作；前导零电路负责统计数值左侧零位或零字节的数量，配合移位完成规格化处理。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 它把一颗 1980 年芯片的浮点加减法从裸片照片、微码到电路逐层拆开讲透，是理解现代浮点硬件设计逻辑不可多得的逆向工程范本。</p>
<p>✍️ <strong>小编看法</strong>: 在人人谈加速器集群的年代，回头看 45 年前一颗靠微码驱动的浮点协处理器，反而能看清一些今天被喧嚣掩盖的常识。首先，8087 把加法提速近 100 倍这件事提醒我们：所谓性能跃迁，往往来自把一种运算从软件模拟变成专用硬件路径，这个逻辑从 1980 年到今天的矩阵引擎从未改变，只是运算对象换了。其次，这篇文章最珍贵的是方法论——用凿子开盖、显微镜拍照、逐个模块逆向还原，这种把电路、微码和算法三层对应起来的功夫，在当下高度依赖官方文档的环境里几乎是失传的手艺。对今天的工程师而言，读懂移位器为什么占据大片裸片面积，比背诵任何性能口号都更有价值：浮点对阶和规格化对硬件面积的开销，直接解释了为什么现代处理器要设计 FMA 融合指令来绕开这些步骤。还有一个容易被忽略的历史细节：文章强调的针对无穷大等特殊值的大量分支处理，恰恰说明 IEEE 754 这类标准的真正成本不在正常路径，而在边界情况的完备性——今天很多自研加速器在特殊值处理上偷工减料，正是重蹈覆辙。下一步值得期待的是作者对这个系列后续文章的展开，比如乘除法与超越函数的微码实现，对照现代 GPU 上同样功能的电路规模，其演进幅度本身就是一部浓缩的硬件史。</p>
<p>🏷️ Intel 8087, floating-point, hardware, reverse engineering</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/righto-com-inside-the-intel-8087-chip-fl-d29dfe1f</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F03-righto-com-WrYV.jpg&amp;size=m" type="image/jpeg" length="210692"/><category>工程</category><pubDate>Sun, 18 Oct 2026 23:04:17 GMT</pubDate></item><item><title><![CDATA[Cloudflare 修复了容器服务中的跨租户数据泄露问题]]></title><link>https://www.lxfzzw.com/archives/infoq-cn-cloudflare-3fcad0b0</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=Cloudflare%20%E4%BF%AE%E5%A4%8D%E4%BA%86%E5%AE%B9%E5%99%A8%E6%9C%8D%E5%8A%A1%E4%B8%AD%E7%9A%84%E8%B7%A8%E7%A7%9F%E6%88%B7%E6%95%B0%E6%8D%AE%E6%B3%84%E9%9C%B2%E9%97%AE%E9%A2%98&amp;url=/archives/infoq-cn-cloudflare-3fcad0b0" width="1" height="1" alt="" style="opacity:0;">
<h1>Cloudflare 修复了容器服务中的跨租户数据泄露问题</h1>
<p><a href="https://www.infoq.cn/article/YmllSwKbZXY0bcVjjw70?utm_source=rss&amp;utm_medium=article">Cloudflare 修复了容器中的跨租户数据泄露问题</a> — infoq.cn · 7 小时前 · 🔒 安全</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F02-infoq-cn-gFzw.jpg&amp;size=m" alt="Cloudflare 修复了容器服务中的跨租户数据泄露问题"></p>
<blockquote>
 <p>Cloudflare 披露并修复了其容器产品中一个可能导致跨租户数据泄露的漏洞，事件再次把多租户隔离这一云基础设施的根基问题推到台前。此次问题源于容器实例在调度与运行过程中，某类资源边界未被严格遵守，使得一个租户的工作负载存在访问到属于其他租户数据的可能。Cloudflare 在发现后迅速采取了补救措施，包括修补相关隔离缺陷、开展审计以确认是否有证据表明数据被实际越权访问，并向客户通报了事件情况。文章回顾了容器多租户架构的隔离模型：容器依赖内核命名空间、控制组等机制实现进程、文件系统与网络资源的划分，但这种共享内核的方案在安全性上天然弱于虚拟机级别的硬件虚拟化隔离，一旦宿主机上的隔离层出现缺陷，攻击面就可能横跨多个客户。文章还对比了行业内常见的加固路线，例如将敏感工作负载放入独立虚拟机或微型虚拟机中运行、启用更强化的安全沙箱、对节点进行专有部署以及缩短资源复用周期等，并指出 Cloudflare 此前在 Workers 平台上采用 V8 隔离与后来引入的隔离强化方案，同样反映了在性能密度与隔离强度之间反复权衡的过程。文章的核心结论是：多租户共享基础设施的效率优势无法脱离严格的隔离设计而存在，任何隔离边界的疏漏都会被放大成全局性的信任危机，厂商必须以持续审计、纵深防御和快速响应机制来兜底，而客户在评估云服务时也应把隔离架构作为重要的选型指标。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>Cloudflare 确认其容器产品存在一个跨租户隔离缺陷，可能让某一租户的运行环境接触到其他租户的数据，公司在修复漏洞的同时进行了取证式审计，以判断泄露是否实际发生，并按合规要求向受影响客户履行了告知义务。</li>
 <li>技术根源在于容器方案与虚拟机方案的本质差异：容器共享宿主机内核，依靠命名空间和控制组做逻辑切分，隔离层一旦被绕过，同一物理节点上多个客户的工作负载便暴露在共同的攻击面之下，而虚拟机通过硬件虚拟化提供了更强的物理级边界。</li>
 <li>行业内的加固手段包括采用微型虚拟机形态的沙箱、为安全敏感客户分配独占节点、避免不同信任级别的负载混部，以及缩短资源在租户之间的复用间隔，这些方案共同的代价是资源密度下降与成本上升。</li>
 <li>Cloudflare 自身在 Workers 平台的演进也体现了同样的权衡：早期基于 V8 隔离追求极高的部署密度，随后引入更强的隔离形态来应对安全边界不足的质疑，说明隔离强度与性能密度之间不存在免费的午餐。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 它用一次真实的跨租户泄露事件，拆解了容器多租户隔离的技术根源与行业加固路线，是评估云服务隔离架构时少见的务实参考。</p>
<p>✍️ <strong>小编看法</strong>: 这类事件的价值不在于某一家厂商出了问题，而在于它把一个被营销话术长期掩盖的真相摆上了桌面：所谓多租户容器服务，本质上是在效率与安全之间做的一场持续赌博。共享内核带来的资源密度优势是真实可观的，它让容器服务能以远低于虚拟机方案的价格提供服务；但代价是整个信任模型建立在内核与运行时的隔离机制从不失误这一假设上，而历史反复证明这个假设靠不住。更值得玩味的是泄露是否实际发生的认定问题。厂商自证的审计结论往往缺乏第三方背书，客户拿到一封「未发现数据被访问」的通知信后，很难判断这是事实还是证据不足下的乐观推断。对合规敏感的行业来说，这种不确定性本身就是风险，也解释了为什么金融和医疗客户宁愿为独占节点支付数倍溢价。被忽略的还有一个机会窗口：这次事件应当促使更多团队认真评估自己到底需要哪种隔离强度——很多内部工具类负载完全可以接受共享沙箱的经济性，而真正涉及用户敏感数据的负载则应该默认走更强边界，混合策略远比一刀切更务实。对行业而言，接下来值得观察三点：一是各容器平台是否会陆续公开类似的隔离加固与第三方审计计划；二是微型虚拟机类沙箱的性能损耗能否被压缩到让默认配置发生迁移的程度；三是监管层面是否会要求多租户服务提供者对跨租户事件引入更严格的独立验证与披露标准。隔离架构的透明化，很可能成为下一轮云服务竞争的隐性分水岭。</p>
<p>🏷️ Cloudflare, containers, data leakage, multi-tenancy</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/infoq-cn-cloudflare-3fcad0b0</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F02-infoq-cn-gFzw.jpg&amp;size=m" type="image/jpeg" length="51413"/><category>安全</category><pubDate>Sun, 18 Oct 2026 23:04:15 GMT</pubDate></item><item><title><![CDATA[英伟达优化 Kimi K3 模型推理速度，提升 1.68 倍]]></title><link>https://www.lxfzzw.com/archives/ithome-com-kimi-k3-1-68-9500a13e</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=%E8%8B%B1%E4%BC%9F%E8%BE%BE%E4%BC%98%E5%8C%96%20Kimi%20K3%20%E6%A8%A1%E5%9E%8B%E6%8E%A8%E7%90%86%E9%80%9F%E5%BA%A6%EF%BC%8C%E6%8F%90%E5%8D%87%201.68%20%E5%80%8D&amp;url=/archives/ithome-com-kimi-k3-1-68-9500a13e" width="1" height="1" alt="" style="opacity:0;">
<h1>英伟达优化 Kimi K3 模型推理速度，提升 1.68 倍</h1>
<p><a href="https://www.ithome.com/1/014/595.htm">英伟达优化 Kimi K3 模型推理速度，提升 1.68 倍</a> — ithome.com · 9 小时前 · 🤖 AI / ML</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F01-ithome-com-FKVw.png&amp;size=m" alt="英伟达优化 Kimi K3 模型推理速度，提升 1.68 倍"></p>
<blockquote>
 <p>调研机构 SemiAnalysis 于 10 月 18 日发布报告指出，英伟达通过一项已合并至上游 vLLM 的优化，让参数规模达 2.8 万亿的 Kimi K3 实现了每用户每秒 423 个 Token 的推理速度。在相同的 GB300 NVL72 硬件环境下，这一成绩相比优化前提升了 1.68 倍，意味着无需更换或增加硬件，仅靠软件层面的改进就能把单位算力产出的推理吞吐量提高近七成。具体完成这项工作的是英伟达旗下 CentML 团队的工程师 Benjamin，其核心技术手段是大规模 Megakernel 融合：将解码阶段所需的多个计算步骤合并为一个整体内核，并使用 Cute DSL 编写针对英伟达最新硬件的解码专用内核。这个 Megakernel 的代码量达到 1.2 万行。值得一提的是，如此规模的底层内核代码在很大程度上代表了借助辅助工具生成复杂计算内核的发展方向——由工程师定义目标与结构，再通过高层领域专用语言描述并产出高度优化的硬件级实现。除了 Kimi K3 之外，英伟达团队还在为 vLLM 开发针对 DeepSeek V4.1 等其他热门开源大参数推理场景的优化，表明这类内核级加速工作正在成为一项持续性、可复用的工作，而非针对单一开源项目的一次性调优。整体来看，这则消息说明推理性能的竞争焦点正从硬件规格转向软件栈与内核实现效率，上游开源推理框架正在成为各家芯片厂商展现实力的主战场。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>SemiAnalysis 的测试显示，英伟达针对 vLLM 的上游优化使 2.8 万亿参数的 Kimi K3 在 GB300 NVL72 上达到 423 tok/s/user 的解码速度，与同硬件的基线相比性能提升 1.68 倍，即同等硬件投入下推理吞吐接近原先的 1.7 倍。</li>
 <li>该优化由英伟达 CentML 团队工程师 Benjamin 完成，核心思路是大规模 Megakernel 融合：把解码路径上的多个操作合并为单一内核，减少内存往返与调度开销，并针对英伟达新硬件编写解码专用内核。</li>
 <li>整个 Megakernel 使用 Cute DSL 编写，代码规模达 1.2 万行，这种借助领域专用语言描述、再产出底层高性能计算内核的方式，被视为高级计算内核开发的新范式。</li>
 <li>英伟达的优化工作以向上游 vLLM 贡献的形式落地，且不止于 Kimi K3，团队还在开发 DeepSeek V4.1 等其他开源权重推理场景的加速方案，说明这是面向整个开源推理生态的持续投入。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 在算力成本居高不下的当下，一次不改硬件就能带来 1.68 倍推理提速的上游优化，直接关系到每一个部署推理服务的团队的钱包，而其背后的内核开发范式变化更值得长期关注。</p>
<p>✍️ <strong>小编看法</strong>: 这则消息最值得玩味的地方，不在于 1.68 倍这个数字本身，而在于它揭示的竞争层级的迁移。前两年大家比拼的是芯片规格、显存带宽和互连拓扑，如今同样的 GB300 NVL72 板卡，能不能榨出近七成的额外性能，取决于有没有人愿意往内核里钻一万两千行代码。这意味着算力采购正在变成一场软件栈的选型：买了同样的硬件，用不同的推理框架和内核版本，成本可以差出一大截，这对中小部署方的启示非常直接——上线前先确认你的推理栈是否用上了最新的内核优化。另一个被不少人忽略的信号是 1.2 万行代码的内核配合 DSL 编写这件事。手写这种规模的底层内核在过去是极少数专家的专利，如今借助高层描述语言和辅助工具，工程团队可以更快地产出针对特定硬件和特定解码路径的深度优化版本，这实际上拉低了极致性能优化的门槛，也会加速优化迭代的节奏——今天是一家厂商放出的版本，明天可能就有开源社区跟进的变体。还有一个耐人寻味的细节：英伟达选择把优化直接贡献到 vLLM 上游，而不是做成自家闭源扩展，说明上游框架已经成为厂商争取开发者心智的阵地，谁的补丁被默认合并，谁就掌握了生态的话语权。接下来值得观察两点：一是这些优化在不同负载和上下文长度下的实际收益是否稳定；二是 DeepSeek V4.1 等后续优化何时落地，以及社区会不会很快给出对比复现的数据。</p>
<p>🏷️ NVIDIA, vLLM, inference, Kimi</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/ithome-com-kimi-k3-1-68-9500a13e</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F01-ithome-com-FKVw.png&amp;size=m" type="image/jpeg" length="496204"/><category>AI / ML</category><pubDate>Sun, 18 Oct 2026 23:04:12 GMT</pubDate></item><item><title><![CDATA[本周包管理动态：2026年10月17日]]></title><link>https://www.lxfzzw.com/archives/nesbitt-io-this-week-in-package-manageme-9db06c68</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=%E6%9C%AC%E5%91%A8%E5%8C%85%E7%AE%A1%E7%90%86%E5%8A%A8%E6%80%81%EF%BC%9A2026%E5%B9%B410%E6%9C%8817%E6%97%A5&amp;url=/archives/nesbitt-io-this-week-in-package-manageme-9db06c68" width="1" height="1" alt="" style="opacity:0;">
<h1>本周包管理动态：2026年10月17日</h1>
<p><a href="https://nesbitt.io/2026/10/17/this-week-in-package-management.html">This Week in Package Management: 17 October 2026</a> — nesbitt.io · 13 小时前 · 🛠 工具 / 开源</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F05-nesbitt-io.png&amp;size=m" alt="本周包管理动态：2026年10月17日"></p>
<blockquote>
 <p>这是一份周更的包管理生态新闻汇总，素材来自作者的包管理器OPML订阅源、其在Mastodon上的发文与转发，以及读者投稿。本期覆盖多个主流工具的版本更新。pnpm从12.12迭代到12.14，新增remoteCache设置，可通过pnpr服务器或任何兼容Turborepo Remote Cache API的服务共享带签名的任务结果与依赖构建产物；12.14还加入sideEffectsCache.exclude，用于排除那些构建依赖缓存键之外系统库的包；12.13新增pnpm profile与pnpm token两个命令，并提供storeIndexFormat: files设置，把原来的SQLite存储索引替换为每个包一个文件的方案，适配网络文件系统上共享存储的场景。mise从2026.10.8更新到2026.10.12，改为从自有主机mise-versions读取版本列表、标签与证明，不再调用api.github.com，安装github:工具的冷启动不再发出任何GitHub API请求，mise ls-remote python的耗时从961毫秒降至93毫秒；2026.10.9修复了不受信任的path:工具版本可能将目录加入PATH的信任绕过漏洞，2026.10.11修复远程任务文件中的信任问题。vlt发布1.4.0，在macOS上默认启用全局存储，通过node:ffi以写时复制的clonefile方式克隆包（要求Node 26.1及以上），热重装耗时从9.6秒降到3.1秒，另新增--save-types选项自动把匹配的@types包加入devDependencies，以及vlt outdated命令，其JSON输出包含每个更新对应的安装命令。.NET 11 RC2为dotnet nuget add source与update source新增--min-publish-age-hours参数，将minPublishAgeHours写入nuget.config，NuGet的package add与package update会应用该冷却期，浮动版本若所有匹配版本均被冷却期排除则以NU1020报错。pixi 0.82.0在全局清单中加入exclude-newer，支持日期或“7d”这类时长，并在平台声明中接受amdgpu = true或如“gfx90a”这样的具体GPU架构。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>pnpm在12.12至12.14三个版本中完成了一次面向构建缓存的基础设施升级：新增的remoteCache设置允许团队通过pnpr服务器或任何实现Turborepo Remote Cache API的服务，共享带签名的任务结果和依赖构建产物，12.14补充的sideEffectsCache.exclude解决了构建依赖缓存键之外系统库的包无法安全使用副作用缓存的问题，12.13的storeIndexFormat: files则把SQLite存储索引改为每包一文件，专门服务于网络文件系统共享存储的场景，同期还加入了pnpm profile和pnpm token命令。</li>
 <li>mise在2026.10.8至2026.10.12版本中做了一次去GitHub化的改造：版本列表、标签和证明改从自有的mise-versions主机读取，安装github:来源工具的冷启动不再发出任何GitHub API请求，mise ls-remote python的响应时间从961毫秒降到93毫秒，提升超过十倍。安全方面，2026.10.9修复了不受信任的path:工具版本可能把目录放进PATH的信任绕过问题，2026.10.11又修复了远程任务文件中的一处信任缺陷。</li>
 <li>vlt 1.4.0聚焦安装性能：在macOS上默认启用全局存储，借助node:ffi在Node 26.1及以上版本使用写时复制的clonefile来克隆包，warm reinstall的耗时从9.6秒缩短到3.1秒。功能上新增--save-types选项，可自动将匹配的@types类型包加入devDependencies，还提供vlt outdated命令，其JSON输出直接内嵌每个可用更新对应的安装命令，方便脚本化升级。</li>
 <li>.NET 11 RC2在NuGet供应链安全上迈出一小步：dotnet nuget add source和dotnet nuget update source新增--min-publish-age-hours参数，把minPublishAgeHours写入nuget.config，此后dotnet package add与package update都会应用这一发布冷却期，如果浮动版本的所有匹配包都在冷却期内，恢复操作会以NU1020错误失败。pixi 0.82.0则在全局清单中支持exclude-newer冻结依赖版本（接受日期或“7d”式时长），并允许平台声明指定amdgpu = true或“gfx90a”等具体GPU架构。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 它用一期汇总让你在一处看齐pnpm、mise、vlt、NuGet和pixi的最新动向，尤其适合需要判断供应链安全与构建缓存策略走向的开发者快速扫一遍生态变化。</p>
<p>✍️ <strong>小编看法</strong>: 把这一周的更新放在一起看，能读出包管理工具正在集体回答同一个问题：如何在不牺牲速度的前提下收紧供应链的信任边界。mise放弃api.github.com自建版本源，表面是性能优化，实质是把关键依赖从第三方限流和故障中收回，961毫秒到93毫秒只是副产品；.NET的minPublishAgeHours则是直接借鉴npm社区讨论多年的新包冷却期思路—— freshly published 的包可能被投毒，等待若干小时让恶意版本先暴露，是成本极低的防护。这暗示未来两年供应链防御会从审计工具下沉到包管理器默认行为里，读者应关注自己的CI是否及时跟进。pnpm的remoteCache共享签名构建产物和storeIndexFormat的文件化索引，指向另一个方向：包管理器正在成为构建基础设施本身，缓存不再只是本地加速手段，而是团队协作资产，这也意味着缓存投毒的风险面在扩大，签名机制是否足够严谨值得持续观察。vlt用macOS clonefile把重装提速三倍，说明底层文件系统能力仍是差异化竞争点。下一步值得盯的是mise的信任修复节奏——两周内连修两处信任相关漏洞，说明信任模型仍在收紧中，用远程任务文件的团队最好保持版本敏感。</p>
<p>🏷️ package management, pnpm, open source</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/nesbitt-io-this-week-in-package-manageme-9db06c68</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F05-nesbitt-io.png&amp;size=m" type="image/jpeg" length="408115"/><category>工具 / 开源</category><pubDate>Sat, 17 Oct 2026 23:04:21 GMT</pubDate></item><item><title><![CDATA[AI变现最好的时代，其实8年前就结束了]]></title><link>https://www.lxfzzw.com/archives/woshipm-com-ai-8-306d427a</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=AI%E5%8F%98%E7%8E%B0%E6%9C%80%E5%A5%BD%E7%9A%84%E6%97%B6%E4%BB%A3%EF%BC%8C%E5%85%B6%E5%AE%9E8%E5%B9%B4%E5%89%8D%E5%B0%B1%E7%BB%93%E6%9D%9F%E4%BA%86&amp;url=/archives/woshipm-com-ai-8-306d427a" width="1" height="1" alt="" style="opacity:0;">
<h1>AI变现最好的时代，其实8年前就结束了</h1>
<p><a href="https://www.woshipm.com/share/6479987.html">AI变现最好的时代，其实8年前就结束了</a> — woshipm.com · 15 小时前 · 💡 观点 / 杂谈</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F04-woshipm-com-boer.jpg&amp;size=m" alt="AI变现最好的时代，其实8年前就结束了"></p>
<blockquote>
 <p>一位有产品运营和AI音乐探索双重背景的作者，借中秋节听歌的偶然经历，引出对AI与专业壁垒关系的反思。作者在搜索歌曲作曲者时发现，作曲家施佳阳是中央音乐学院作曲系科班出身，曾为张信哲、费玉清等歌手制作专辑，还入围过奥斯卡动画长片提名的电影《梦回金沙城》配乐，但这样一个传统工业里站稳脚跟的学院派，早在2018年就创立了链声科技，推出名为YAME的智能作曲系统，通过输入节拍、速度、风格等标签即可算法生成编曲，并拿到天使轮融资，此后产品动向却杳无音讯。同一时间点，许嵩2018年专辑《寻宝游戏》中的《艺术家们》已经讽刺“诗词怀疑是软件生成的”“歌曲几十分钟赶完”。作者据此指出，AI并非凭空出现，2018年它就藏在行业门槛之内悄悄生长，当时会用专业工具的专家仍能靠信息差和稀缺性变现，那才是AI变现最好的时代。作者还回顾了自己的职业轨迹：2014年毕业后做互联网产品运营，凭借自学工具能力强、一人可完成多人协作任务而获得晋升，自认为那是能力，如今才看清不过是“工具套利者”赶上了时间窗口。到了2024年，Suno等消费级AI产品涌现，估值推高、付费用户以百万计、日生成歌曲以百万首计，技术门槛趋近于零。作者的结论是：金字塔尖的创作者凭个人品牌、版权与信任背书几乎不受冲击，受冲击最大的是靠“会用工具”筑起壁垒的中腰部从业者，工具普及后他们被迫跨界求生。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>作曲家施佳阳的履历呈现出一条被中断的创业线索：他是中央音乐学院作曲系科班出身，为张信哲、费玉清、林依晨等艺人制作过专辑，并为入围奥斯卡动画长片提名的电影《梦回金沙城》配乐，但2018年他创立链声科技、推出可通过输入节拍、速度、风格等标签生成编曲的YAME智能作曲系统并获天使轮融资之后，公开信息中再也找不到产品的后续踪迹，只留下2018年这个干净的时间戳。</li>
 <li>许嵩2018年专辑《寻宝游戏》中的歌曲《艺术家们》已经写出了对软件生成内容的讽刺，歌词质疑有些诗词是电脑软件生成、有些歌曲是几十分钟赶完没有任何细节值得一品。作者从2020年开始业余做翻唱、改词和说唱，探索AI音乐至今两年，因此听这首歌时感到的 不是刻薄俏皮而是当头棒喝，并与施佳阳的创业线索在同一个月内于脑中撞到一起。</li>
 <li>作者以自身经历解释中腰部从业者的处境：2014年毕业后从事互联网产品运营，最大的职场优势是自学互联网工具能力强，用几款SaaS和几套模板就能一人跑通需要小组协作的事，因此在产业互联网红利期搭上升职加薪的电梯。现在回头看，那并非不可替代的专业壁垒，而是一段“我会用、你不会用”的时间窗口，窗口开着时一人就是一支队伍，窗口关上时队伍里每个人都能替代你。</li>
 <li>2024年前后格局发生了根本变化：生成式AI技术成熟，Suno等大众消费级产品入场，资本驱动大规模推广，Suno估值一路推高、付费用户以百万计、每天生成的歌曲以百万首计，从未写过歌的人也能快速做出让自己满意的歌曲。金字塔尖的人依靠个人品牌、付费粉丝、版权积累和信任背书几乎不受影响，甚至把AI当作谈溢价的筹码，而靠工具形成壁垒的中腰部人群被迫跨界做短视频配乐、播客、培训班等自救。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 它用一段被遗忘的创业往事和个人职业反思，戳破了「AI红利刚刚开始」的幻觉，逼你重新审视自己的专业壁垒到底是能力还是时间窗口。</p>
<p>✍️ <strong>小编看法</strong>: 这篇文字最有价值的地方，是把「技术红利」这个词拆开给人看：红利的本质不是技术本身，而是技术扩散速度与你学会速度之间的差值。作者说自己是工具套利者，这个词很准——套利的利润永远来自信息差，而信息差注定会关闭。真正值得深思的是被忽略的那一面：2018年像施佳阳这样的人已经看到了方向，却没能把YAME做下去，这说明比「看见趋势」更难的是等到趋势兑现的那一天。早做的人往往死在市场还没准备好，晚做的人死在门槛已经消失，时间窗口的残酷就在于此。对读者而言，这里有个更实际的问题值得追问：当工具不再是秘密，剩下什么？作者的答案隐含在金字塔尖人群的构成里——品牌、版权、粉丝、信任，这些都不是工具，而是工具无法复制的关系资产。我认为行业的下一个分水岭不在「会不会用工具」，而在「能否把工具的产出沉淀为别人带不走的东西」：比如独特的审美判断、稳定的受众关系、可授权的作品库。下一步值得观察的是中腰部从业者的两极分化：一部分人会转向AI难以替代的现场、定制与人格化业务，另一部分会被迫接受议价能力持续下滑。另一个观察点是许嵩那样的创作者态度——他们对生成内容的警惕，可能恰恰会成为高端市场的定价依据。「人手」这两个字未来也许会像「手工」一样变成溢价标签。</p>
<p>🏷️ AI, creative industry, moat, Suno</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/woshipm-com-ai-8-306d427a</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F04-woshipm-com-boer.jpg&amp;size=m" type="image/jpeg" length="18598"/><category>观点 / 杂谈</category><pubDate>Sat, 17 Oct 2026 23:04:19 GMT</pubDate></item><item><title><![CDATA[留存率跌破 5%：为什么腾讯、钉钉都在悄悄砍掉「右侧 AI 抽屉」？]]></title><link>https://www.lxfzzw.com/archives/woshipm-com-5-ai-39717ba2</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=%E7%95%99%E5%AD%98%E7%8E%87%E8%B7%8C%E7%A0%B4%205%25%EF%BC%9A%E4%B8%BA%E4%BB%80%E4%B9%88%E8%85%BE%E8%AE%AF%E3%80%81%E9%92%89%E9%92%89%E9%83%BD%E5%9C%A8%E6%82%84%E6%82%84%E7%A0%8D%E6%8E%89%E3%80%8C%E5%8F%B3%E4%BE%A7%20AI%20%E6%8A%BD%E5%B1%89%E3%80%8D%EF%BC%9F&amp;url=/archives/woshipm-com-5-ai-39717ba2" width="1" height="1" alt="" style="opacity:0;">
<h1>留存率跌破 5%：为什么腾讯、钉钉都在悄悄砍掉「右侧 AI 抽屉」？</h1>
<p><a href="https://www.woshipm.com/share/6423032.html">留存率跌破 5%：为什么腾讯、钉钉都在悄悄砍掉“右侧 AI 抽屉”？</a> — woshipm.com · 16 小时前 · ⚙️ 工程</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F03-woshipm-com.png&amp;size=m" alt="留存率跌破 5%：为什么腾讯、钉钉都在悄悄砍掉「右侧 AI 抽屉」？"></p>
<blockquote>
 <p>过去一年半，国内几乎所有 SaaS、协作与后台工具团队都经历了一场整齐划一的改造：在界面右上角加入闪烁的 AI 图标，点击后右侧滑出占据约 30% 屏幕宽度的白色侧边抽屉，里面配置着对话记录、单行输入框和「帮我润色」「一键总结」「提炼待办」等预制提示词药丸。这套方案之所以流行，是因为它不动主界面原有业务代码，又能向管理层证明产品已拥抱 AI。但埋点数据揭穿了遮羞布：行业内绝大多数右侧 AI 抽屉上线第 30 天的次月留存率跌破 5%，部分垂直工具甚至徘徊在 1% 到 2%；八成以上用户好奇点过一两次预制按钮后就再未唤起。如今腾讯文档、钉钉、飞书乃至海外的 Office 365 都在迭代中给侧边栏降权、折叠甚至移出默认界面。文章归纳了右侧抽屉的三大致命伤：其一，视线像打乒乓球，用户主工作区在左侧，被迫在主画布与侧栏间横跳，还需把脑中业务逻辑翻译成提示词，停顿超过两秒心流即被切碎；其二，空间霸凌，1080P 宽度的笔记本上，侧边栏需 360 到 420 像素才能阅读长文本，主工作区被削掉近三分之一；其三，底层组件未打通，光标选区与当前状态无法传递，用户被迫在左右两侧反复复制粘贴，沦为「人肉搬运工」，体验三次即判死刑。作者指出微软 Copilot 在企业端同样遭遇反馈不佳，Excel 高频用户第一件事就是手动关闭侧栏，而行业正向打斜杠唤起、选中文本弹出微型悬浮条、表头智能填充等「呼之即来、选完即走」的局部插件式交互演进。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>数据层面，行业绝大多数右侧 AI 抽屉的次月留存率在第 30 天跌破 5%，部分垂直工具低至 1% 到 2%；超过八成用户在好奇心驱动下点过一两次预制 Prompt 按钮后，就再没有主动唤起过该功能入口，形成典型的「功能坟场」。</li>
 <li>右侧抽屉的三大人机工效学缺陷：视线被迫在左侧主工作区与右侧侧栏之间来回切换，加上需要把业务意图翻译成提示词的认知负担，一旦停顿超过两秒就打断工作心流；抽屉占掉 360 至 420 像素宽度，在 1080P 屏幕上压缩主工作区近三分之一，引发横向滚动、强制折行等问题。</li>
 <li>更深层的失败原因是技术割裂：抽屉与主画布往往是两个独立组件，底层未打通光标选区与文档当前状态，用户说出「把第二段改得更正式」却得到「请先粘贴内容」的回复，被迫在左右两侧反复复制粘贴，充当人肉搬运工，这种割裂感只需三次体验就让功能在用户心中死亡。</li>
 <li>行业转向已经清晰：微软把 Copilot 塞进 Word、Excel、PPT 右侧后企业端反馈不佳，Excel 高频用户进软件第一件事就是手动关闭侧栏；国内钉钉、腾讯文档、飞书则把全局 AI 入口打散，改为主推斜杠唤起、选中文本后光标下方弹出的微型悬浮条、多维表格表头的智能填充建议以及右键菜单收敛，AI 从独立视窗降格为随选随走的局部操作插件。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 它用真实的留存数据和工效学分析拆穿了过去一年半最流行的 AI 交互模板，给所有正在或准备照抄侧边栏方案的团队敲响了警钟。</p>
<p>✍️ <strong>小编看法</strong>: 这波 AI 抽屉退潮本质上是一次集体性的「交差工程」翻车，值得整个产品圈认真复盘。真正该问的问题不是「抽屉为什么失败」，而是「为什么明知是套模板，全行业还要排着队抄」。答案很残酷：在融资和汇报压力下，一个可视化、可截图、能写进 PPT 的 AI 入口，比默默打磨底层能力更容易兑现成估值叙事。于是产品经理的 PRD 里出现了死命令，工程团队选择不动主业务代码的最小侵入方案，所有人都心知肚明这是装饰，却没人愿意先戳破。被忽略的代价有三层：一是用户信任被透支，尝鲜即失望的体验让后续真正有价值的 AI 功能也背上污名；二是数据误导决策，团队盯着「唤起率」这种虚荣指标，只有次月留存这种冷数据才说实话；三是挤占了真正的交互创新窗口——上下文感知、无需唤起的静默增强，这些难做但正确的方向被模板方案挤出了排期。Cursor 和 Notion AI 跑出高留存恰好证明了差异：它们把能力缝进用户既有的操作路径，而不是另开一扇门。下一步值得观察的是「局部插件式 AI」能否沉淀出公认的设计规范，比如什么场景该用斜杠、什么场景该用悬浮条、什么场景该静默预填；如果这套规范成形，AI 交互才算真正从噱头阶段进入工程化阶段。对从业者而言，检验标准很简单：砍掉唤起动作后，用户还能不能感受到价值。</p>
<p>🏷️ AI-native, UX, SaaS, interaction-design</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/woshipm-com-5-ai-39717ba2</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F03-woshipm-com.png&amp;size=m" type="image/jpeg" length="614091"/><category>工程</category><pubDate>Sat, 17 Oct 2026 23:04:16 GMT</pubDate></item><item><title><![CDATA[各大网站正在对 AI 智能体关门]]></title><link>https://www.lxfzzw.com/archives/theverge-com-websites-are-closing-their-aa882cda</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=%E5%90%84%E5%A4%A7%E7%BD%91%E7%AB%99%E6%AD%A3%E5%9C%A8%E5%AF%B9%20AI%20%E6%99%BA%E8%83%BD%E4%BD%93%E5%85%B3%E9%97%A8&amp;url=/archives/theverge-com-websites-are-closing-their-aa882cda" width="1" height="1" alt="" style="opacity:0;">
<h1>各大网站正在对 AI 智能体关门</h1>
<p><a href="https://www.theverge.com/ai-artificial-intelligence/1013195/ai-agents-blocked-web">Websites are closing their doors to AI agents</a> — theverge.com · 10 小时前 · 🤖 AI / ML</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F02-theverge-com-FeQT.jpg&amp;size=m" alt="各大网站正在对 AI 智能体关门"></p>
<blockquote>
 <p>自主智能体是当前最热门的赛道：OpenAI、Meta、Google、Instinct 等公司纷纷宣称自家的智能体可以替用户上网办事，从预订餐厅、清理邮箱到购买新鞋无所不能。然而现实很快给出反例——最近几周，Meta 的 Muse、xAI 的 Grok、OpenAI 的 Dots 以及 Instinct 等服务的用户陆续报告，他们的智能体在访问主流网站时遭到拦截，无法完成任务。具体案例已经浮出水面：Yelp 向科技媒体 TechCrunch 证实，只有付费加入其数据授权计划的智能体才被允许访问；达美航空则直接阻止智能体代客订票。这暴露出智能体叙事与开放网络之间的根本张力：智能体厂商描绘的是自由穿行的自动化图景，而网站方眼中的却是抢走流量、绕过界面、白嫖数据且不带来任何广告或转化收益的机器流量。Yelp 的付费墙策略预示了一种可能的商业解法——数据授权谈判将成为智能体时代的新入口，谁付费谁通行；而达美的封堵则代表了另一种立场：核心交易环节不接受第三方自动化介入。当内容与服务平台陆续筑墙，智能体的「全网代办」承诺将被迫收缩到少数开放或达成协议的站点之内，代理互联网的边界之争才刚刚开始。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>多家主流智能体产品——包括 Meta 的 Muse、xAI 的 Grok、OpenAI 的 Dots 和 Instinct——的用户在近几周集中报告，智能体在执行订票、搜索商户信息等日常任务时被顶级网站拦截，号称「替你上网办一切事」的产品承诺在最基础的场景上遭遇现实壁垒。</li>
 <li>网站方的抵制已有明确的商业化路径：Yelp 明确表示只向付费加入其数据授权计划的智能体开放访问，这实质上把「智能体通行权」变成了一门可以定价出售的生意；而达美航空则选择直接封杀，禁止智能体代理购票，守住交易环节的收益与控制权。</li>
 <li>冲突的根源在于利益结构错位：智能体替用户完成任务，意味着用户不再浏览网页、不再看到广告、不再经过网站的官方界面，网站付出了内容与服务的成本却拿不到对应的回报，于是封堵或收费成为理性的自保动作。</li>
 <li>这一趋势预示着代理互联网正在分裂为两个阵营：愿意谈判授权的站点与坚持封堵的站点并存，智能体的能力边界将不再由技术决定，而由商业协议划定，厂商宣传中的「全网通用」正快速让位于「协议内可用」。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 它记录了智能体宏大叙事撞上商业现实墙的第一批实锤案例，谁付钱谁通行的新规则正在此刻成形。</p>
<p>✍️ <strong>小编看法</strong>: 这场围堵战其实是互联网历史上老剧本的重演，只是 stakes 更高。回想当年移动 App 时代，各家平台也是先筑墙再谈 API 授权，最终形成少数几个超级 App 主导的封闭生态。智能体大概率会走同样的路，而且速度更快，因为这一次网站方从一开始就看清了利害——机器流量不会带来广告曝光，不会产生品牌记忆，纯粹是「用了就走」的白嫖。Yelp 的付费授权模式尤其值得关注，它可能是未来「智能体经济」的原型：网站不再争夺用户注意力，而是争夺「被代理访问」的收费权。这里面藏着一个被低估的机会——如果出现类似支付清算层的中立协议标准，让智能体按任务完成量向网站 micro-payment 结算，或许能避免全网各自为政的授权乱局。但短期我更倾向于悲观：大厂智能体握有议价筹码，小厂商的智能体将首先被排除在外，最终「全网代办」只会是大玩家的特权。对普通用户来说，值得观察的信号是接下来半年有没有一家重量级网站公开签约授权某家智能体——那将是围墙倒塌的第一块砖；反之，如果达美式的封堵蔓延到电商、银行和政务站点，智能体叙事就得大幅缩水，重新回到「辅助工具」的定位。</p>
<p>🏷️ AI-agents, web, OpenAI, automation</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/theverge-com-websites-are-closing-their-aa882cda</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F02-theverge-com-FeQT.jpg&amp;size=m" type="image/jpeg" length="53074"/><category>AI / ML</category><pubDate>Sat, 17 Oct 2026 23:04:14 GMT</pubDate></item><item><title><![CDATA[以色列广告技术公司竟成了「雇佣间谍软件」的投放渠道：它们借道 Google、Facebook 等所有主流广告平台实现攻击]]></title><link>https://www.lxfzzw.com/archives/pluralistic-net-pluralistic-israeli-ad-t-702e0764</link><description><![CDATA[<img src="https://www.lxfzzw.com/plugins/feed/assets/telemetry.gif?title=%E4%BB%A5%E8%89%B2%E5%88%97%E5%B9%BF%E5%91%8A%E6%8A%80%E6%9C%AF%E5%85%AC%E5%8F%B8%E7%AB%9F%E6%88%90%E4%BA%86%E3%80%8C%E9%9B%87%E4%BD%A3%E9%97%B4%E8%B0%8D%E8%BD%AF%E4%BB%B6%E3%80%8D%E7%9A%84%E6%8A%95%E6%94%BE%E6%B8%A0%E9%81%93%EF%BC%9A%E5%AE%83%E4%BB%AC%E5%80%9F%E9%81%93%20Google%E3%80%81Facebook%20%E7%AD%89%E6%89%80%E6%9C%89%E4%B8%BB%E6%B5%81%E5%B9%BF%E5%91%8A%E5%B9%B3%E5%8F%B0%E5%AE%9E%E7%8E%B0%E6%94%BB%E5%87%BB&amp;url=/archives/pluralistic-net-pluralistic-israeli-ad-t-702e0764" width="1" height="1" alt="" style="opacity:0;">
<h1>以色列广告技术公司竟成了「雇佣间谍软件」的投放渠道：它们借道 Google、Facebook 等所有主流广告平台实现攻击</h1>
<p><a href="https://pluralistic.net/2026/10/17/mercenary-spyware/">Pluralistic: Israeli ad-tech company was a delivery system for "mercenary spyware" (17 Oct 2026)</a> — pluralistic.net · 12 小时前 · 🔒 安全</p>
<p><img src="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F01-pluralistic-net.jpg&amp;size=m" alt="以色列广告技术公司竟成了「雇佣间谍软件」的投放渠道：它们借道 Google、Facebook 等所有主流广告平台实现攻击"></p>
<blockquote>
 <p>多伦多大学公民实验室发布的调查报告《Exposing AdFection》揭示了一个令人不安的事实：一家以色列广告技术公司被改造成「雇佣间谍软件」的分发管道，攻击者利用 Google、Facebook 在内的全球主要程序化广告平台，对特定目标人物进行定位，并向其设备投送「零点击恶意软件」——受害者无需点击任何链接、无需任何操作，电脑和手机就会被完全接管。问题的根源在于程序化广告系统的结构性缺陷：各大科技巨头多年来搜集了几乎每一位互联网用户的详尽画像，并为每个人分配了唯一且持久的标识符，相当于给监控行为发放了「全民身份证号」。正是这套精准投放基础设施，让间谍软件运营商得以按名单「点名」投放，把广告竞价系统变成武器。文章作者 Cory Doctorow 引用 Doc Searls 的判断指出，超过半数网民已经安装广告拦截器，这堪称历史上规模最大的消费者抵制运动；但他的结论更激进：所有人都应当拦截所有程序化广告，因为整个广告技术栈的安全性糟糕到不设防就可能让任何人的数字设备被彻底攻陷。这篇文章把隐私议题从「被看广告」升级为「被入侵」的安全议题，说明广告生态的漏洞不再是假设性的风险，而是已被实战利用的攻击面。</p>
</blockquote>
<p><strong>核心信息</strong></p>
<ul>
 <li>公民实验室的最新调查报告《Exposing AdFection》查明，一家以色列广告技术公司充当了「雇佣间谍软件」的投放载体：攻击者通过主流程序化广告平台定位目标个体，并推送零点击恶意软件，使受害者的电脑与手机在毫无操作的情况下被完全控制，而 Google 和 Facebook 等巨头平台在整个链条中被劫持利用。</li>
 <li>程序化广告系统的核心资产——对几乎所有网民建立详尽监控档案、并分配唯一持久的追踪标识符——恰恰构成了攻击的基础设施。这种「为广告而生的精准定位能力」被间谍软件运营商反向利用，等于每个网民都随身携带一个可供瞄准的固定坐标。</li>
 <li>据 Doc Searls 的估计，超过一半的互联网用户已安装广告拦截器，被称为史上最大规模的消费者抵制运动。但作者认为这一防线仍远远不够：由于广告技术全链条安全性堪忧，唯一稳妥的做法是屏蔽所有程序化广告，否则任何设备都有被整体攻陷的可能。</li>
 <li>这篇评论将广告拦截从个人偏好问题重新定性为数字安全的必选项：当广告分发网络可以被第三方购买并武器化时，不装拦截器的代价不再只是忍受骚扰，而是承担被国家级或商业间谍行动选中的现实风险。</li>
</ul>
<p>💡 <strong>为什么值得读</strong>: 它把「装不装广告拦截器」从个人偏好问题升级成了数字安全的生死题，用一个已被证实的间谍软件投放案例给出了无可辩驳的答案。</p>
<p>✍️ <strong>小编看法</strong>: 这则报道最值得玩味的地方在于，它把长期以来被归类为「隐私偏好」的问题，硬生生拽回了「安全底线」的范畴。过去很多人不装拦截器，理由无非是嫌麻烦、想支持创作者，或者觉得「我又没什么值得偷的」。但当定位技术能精确到向名单上的具体个人投送零点击木马时，「看广告」和「被入侵」之间的界限已经彻底消失了。被忽视的代价其实一直存在：程序化广告的每次竞价、每次匹配，都是一次无人审查的数据交易，平台赚走了精准的钱，风险却由用户全盘承担。这次事件的价值在于，它提供了一个无法辩驳的实证案例——不是理论推演，而是真实发生的武器化利用。对行业而言，这意味着广告平台将面临远超隐私合规层面的压力：如果投放管道可以被用来发动定向攻击，监管机构很可能会以国家安全框架而非广告规则来审视它，那才是真正伤筋动骨的监管。对普通读者，我的建议很直接：把拦截器当作和杀毒软件同级的标配，而不是可选项。下一步值得追踪的是各大平台如何回应——是补齐投放方审查机制、限制跨站标识符的精确度，还是继续以「个别供应商违规」的说法切割责任。另外，公民实验室这类机构调查此类事件需要跨国协作和长时间取证，这类独立监督力量的存续本身也值得关注，因为它们是这套灰色生态里几乎唯一的外部纠错机制。</p>
<p>🏷️ spyware, ad-tech, privacy, surveillance</p>
<blockquote>
 <p>本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。</p>
</blockquote>
<hr>]]></description><guid isPermaLink="false">/archives/pluralistic-net-pluralistic-israeli-ad-t-702e0764</guid><dc:creator>枫景</dc:creator><enclosure url="https://www.lxfzzw.com/apis/api.storage.halo.run/v1alpha1/thumbnails/-/via-uri?uri=https%3A%2F%2Fwww.lxfzzw.com%2Fupload%2F01-pluralistic-net.jpg&amp;size=m" type="image/jpeg" length="135059"/><category>安全</category><pubDate>Sat, 17 Oct 2026 23:04:12 GMT</pubDate></item></channel></rss>