10 月 25 日 · 周日
从 96 条内容中筛出 15 条 · 点击条目展开背景、讨论与观点
BuilderXAI 观点 · 今日
今天有两条主线。第一条是“便宜的能力和贵的理解”：陶哲轩嫌 AI 证明没人读得懂，Dan Luu 主张趁成本下降去做大项目，两边说的其实是同一个缺口，产出变便宜了，验证和消化还是贵。第二条是本地模型的工程细节：编排框架、MoE 专家卸载、1–2 bit 量化，再加上一篇提醒 KLD 不能拿来排名的帖子。最值得看的是 GVS5H 和 KLD 那篇，前者说明 harness 带来的提升可能比换模型还大，后者告诉你怎么判断这类数字可不可信。
1 陶哲轩：AI把优美数学变成“有毒废料” 8
据《观察家报》专访，菲尔兹奖得主陶哲轩批评OpenAI公开了722个未解数学问题的答案，称这些材料是“有毒废料”。他认为，这些难题主要被用作训练和基准测试材料，生成的证明虽然结果可观，但不讲究优雅，也不便于他人理解。他还称OpenAI曾为Navier-Stokes问题投入大量算力并暂停了部分注册，但OpenAI否认暂停注册，并表示既未扣留也未仓促发布成果，同时承诺投入500万美元帮助数学界检验和理解AI产生的成果。以上多为陶哲轩的观点及报道内容，尚未经独立核实。
背景
2026年9月8日，OpenAI宣称其内部前沿大语言模型解决了千禧年大奖难题之一的Navier–Stokes问题，并证明存在导致有限时间爆破的初始条件，同时发布了论文和Lean形式化证明。随后，NYU的Tristan Buckmaster与Anthropic的Levent Alpöge称他们此前已先解决了一个相关版本，OpenAI因此面临署名争议。据《纽约时报》报道，Tao在10月6日成果发布前就已把这批即将公开的结果称为“有毒废料”（toxic waste）。
对研究者的影响
对数学研究者和AI评测人员而言，公开难题正被用作基准，生成的证明往往缺乏打磨，需要专家逐一审查才能确认其价值。陶哲轩还指出，前沿数学研究越来越依赖能否获得大型AI模型，研究者之间的资源差距可能因此扩大，这一判断目前仍属其个人看法。
社区讨论
评论区分歧明显。一方观点认为批评是“移动球门”：从“AI不会做数学”到“不够优雅”，并预测AI很快能生成优美证明。另一方（如评论者eteran）认为，数学的目的在于理解而非解题本身，用AI解决大量问题对领域推进作用有限，企业更像是在营销；也有评论回应，数学的应用价值并不依赖每个人都理解它，理解并非唯一目标。核心争议在于AI成果是否算作数学进展，以及数学价值应如何衡量。
BuilderXAI 观点行业
陶哲轩批评的不是 AI 会不会做数学，而是验证成本被转嫁给了数学界。一份证明发出来，作者一方只付了算力钱，读懂、检查、提炼思想的成本却落在审稿人和研究生身上。这和早期的计算机辅助证明很像，四色定理当年也被嫌“不可理解”，后来靠形式化才被接受。这次有 Lean 证明兜底，正确性问题小一些，但“为什么成立”依然没人讲。OpenAI 投 500 万美元帮数学界消化成果，等于默认了这个外部成本。对 builder 的启示是：AI 产出越便宜，可解释、可审阅的那一层就越值钱，做证明解读、代码审阅这类工具的人有生意。
参考链接（3）
2 Codex CLI 更新：提示词预设、企业 MCP 登录与长会话恢复修复 8
OpenAI Codex 与 ChatGPT 负责人 Thibault Sottiaux 在 2026 年 10 月 24 日发布了第 19 天的小更新。主要变化包括：dots 的通话连接明显加快；在 Codex 和 work 中途切换推理设置后，缓存不再失效；Codex CLI 新增可复用的提示词预设、可在对话内直接设置的模型与权限选项，以及企业 MCP 登录。CLI 还修复了恢复长会话时的失败问题，并新增 Windows 企业代理认证。他同时称 CLI 自 DevDay 以来使用量增长了 2 倍，但这一数据来自厂商自述，原文未提供统计口径。
背景：提示词缓存与对话中途的推理切换
提示词缓存（prompt caching）指模型服务复用已处理过的对话前缀，以降低延迟和成本，前缀一旦改变，对应缓存通常随之失效。原帖提到的问题是，在 Codex 中途修改推理设置或推理内容，会使这段缓存失效；此次更新的变化在于，对话中途的此类切换不再使缓存失效。Codex CLI 是 OpenAI 的命令行编程代理工具，帖子中提到的 CLI 更新也属于这一产品。
对开发者的影响
在企业网络或 Windows 公司代理环境中使用 Codex CLI 的开发者，现在可以通过企业 MCP 登录和代理认证接入工具。依赖长会话的用户，恢复会话失败的问题已被修复。原文未量化缓存修复带来的成本或延迟变化，相关收益需要实际测试确认。
BuilderXAI 观点技术
看着是常规小更新，真正值钱的是中途改推理设置不再让缓存失效。
- 细节：长会话里前缀缓存一旦失效，整段上下文都要按全价重算。以前中途调高 reasoning 就要付这笔钱，现在可以按需切换。
- 对比：Claude Code 那边切模型同样会影响缓存命中。两家都在把“会话状态可控”做成卖点。
- 企业 MCP 登录和 Windows 代理认证面向的是大公司内网，CLI 正在从个人玩具变成可以采购的工具。
- 上手：升级 CLI 后试试提示词预设，把常用的 review、重构指令存下来复用。缓存收益原文没量化，自己对比账单才有数。
3 GVS5H：编排式 Qwen3.8-27B 在 LiveCodeBench 上接近 Fable 5 7
该项目提出一种免训练的“账本式零样本自编排”方法：同一模型的多个全新实例通过共享文件系统（包含计划、笔记和当前解答）分解问题并协作。作者在最新的 100 道 LiveCodeBench 难题上测试了十一个开源和闭源模型，称增益最高可达 25.6 个百分点。其中，编排后的 Qwen3.8 Flash Next 达到 93.0% pass@1，高于 Fable 5 的 90.4%，成本约为其 9%；本地部署的开源权重 Qwen3.8-27B 则从 66.8% 提升至 92.4%。这些结果来自作者的论文与仓库，尚未经独立复现，且并非所有模型都有提升，部分模型持平或变差。
前置背景
GVS5H 是一篇发布于 2026 年 8 月下旬的 arXiv 论文（2608.26480v2）提出的方法，属于免训练的零样本自编排（zero-shot self-orchestration）。其核心做法是让同一模型的多个全新实例分别承担分解问题等角色，并通过共享文件系统中的计划、笔记和当前解答进行协调，而不是依赖更大的专有模型。
社区讨论
批评者认为，所用基准 LiveCodeBench 发布于 2025 年初且已接近饱和，缺少与更新模型（如 Opus 5.5、Fable 5.1 等）的比较，也没有评估真实智能体任务的能力，因此结论未必能推广。有人怀疑方法是否过拟合了这些题目。另一些评论者则认为，本地部署的硬件一次性投入加电费，成本优势明显，对自托管场景有吸引力。还有开发者分享了使用 Claude Code 子智能体的实际体验，反映出异步启动与轮询长时间任务时可靠性不足的问题，但这一经验与本文的基准结论没有直接关系。
BuilderXAI 观点技术
核心信号是：harness 带来的提升可以大过换模型。27B 从 66.8% 涨到 92.4%，这个幅度已经超过不少代际升级。
- 机制：多个全新实例共享一个文件“账本”（计划、笔记、当前解答），每个实例都从干净的上下文开始，不会被前面的错误思路拖累。原理和 Claude Code 的子代理加 TODO 文件相近。
- 局限：LiveCodeBench 是单题算法题，自带清晰的判题标准，最适合这种反复迭代。换到真实代码库的多文件任务，效果未必能保持。部分模型持平或变差，说明它吃模型本身的指令遵循能力。
- 成本：调用次数会成倍增加，本地跑主要花的是时间，用 API 跑要先算 token 账。
- 难度：中等。最短路径是 clone 仓库，用本地 27B 跑几道自己的题对照基线。
参考链接（2）
4 Dan Luu：我们应当更有野心地构建软件 7
Dan Luu 在文章中主张，开发者应当更有野心地构建软件，并以 Michael Malis 的 pgrust 项目为例。pgrust 是一个 Postgres 的重写项目，作者称其测试充分，已借此发现 Postgres 中多个真实缺陷（如 SP-GiST 数值错误、JSONPath 格式缓存错误、pgcrypto 与内存安全问题），其主要卖点是性能优化，部分优化未来可能被移植到 Postgres 或 ClickHouse 等项目。Luu 还以自己的经验说明，借助更快的 SOTA 模型，ripgrep 分支、正则引擎、Rust 编译加速和文件系统 I/O 优化等“能用级”项目的成本已大幅降低。需要注意的是，这些主要是作者的个人经验和主张，文中并未给出 pgrust 的独立第三方测评结果。
背景
pgrust 是一个实验性项目，目标是用 Rust 重写 PostgreSQL，并尽量贴近 PostgreSQL 18.6 的行为兼容性，其定位不是简单的玩具式克隆。据第三方文章介绍，作者大量使用 AI 编程代理来翻译 PostgreSQL 约百万行的 C 代码库，并称其通过了全部回归测试。但另一篇分析文章以“并不完全如此”为题，对这一说法的范围提出了质疑。
社区讨论
评论区存在明显分歧。支持者认为，AI 工具让过去被视为不现实的工程（如新编译器、新游戏引擎）变得可行，问题在于许多人仍按“前AI时代”的成本模型思考；有评论者分享了自己每个新模型发布后尝试一个月级别的挑战项目的经历，并指出AI能快速做出MVP，但产品权衡和后续集成依然困难。质疑者则认为，Luu 所举的例子（如为个人工作流定制的 ripgrep 分支）算不上真正有野心，真正的野心应体现在要解决的问题类型和创造的价值上。另有评论者强调，大量 AI 生成的低质量项目充斥，使人们对此类项目普遍存疑，这也是讨论的背景。
BuilderXAI 观点行业
我站 Luu 这边，但要补一句：变便宜的是写出来，不是维护下去。pgrust 有说服力，靠的不是代码量，而是 Postgres 现成的回归测试当裁判，还反过来挖出了上游的真缺陷。这给出了一个可复制的条件：有现成测试集或参考实现的领域（重写、移植、性能优化），野心最划算。没有判题标准的产品，AI 依旧只能帮你快速做出 MVP，评论里说的产品权衡和集成难题照样存在。对独立开发者的建议是，挑一个“有测试可以对照”的大目标，不要挑一个只能靠感觉评判的大目标。
参考链接（3）
5 Claude 据称拦截智能电视逆向工具 REA，社区就公开还是保密争论 7
Reddit r/LocalLLaMA 的一则帖子称，名为 REA（Reserve Engineer Anything）的逆向工程工具在发布一天后被 Claude 拦截，该工具的目标是分析智能电视的数据收集行为。帖子引用了一条 X 推文作为依据，但正文本身没有提供工具细节或拦截的具体机制。标题中提到的 OpenAI 相关说法，在所提供的材料中没有任何佐证。因此，这一事件目前只能视为单方面、未经核实的说法。
背景：REA 逆向工程工具
REA（Reverse Engineer Anything）是 GitHub 上 morluto/rea 项目的名称，可让 AI 智能体调用工具检查原生二进制文件、JavaScript 与 Electron 应用、.NET 程序集及网站。项目页面称分析在本地运行，结果会附带支撑每个结论的证据与局限性。其官网提供 Claude Code 和 Codex 集成的安装教程与命令行用法，但来源中并未提及它专门针对智能电视。
对开发者的影响
如果该说法属实，从事安全研究或逆向工程的开发者在使用 Claude 处理此类任务时可能遇到拒绝，需要预期模型的安全策略会限制这类请求。不过，由于目前证据只有一条推文和帖子标题，具体拦截范围和原因尚无法确认。
社区观点
讨论的核心分歧在于研究成果应当公开还是低调进行。一方（如 MotokoAGI、deltamoney）认为应先悄悄完成逆向工程、再分享，以免大公司迅速封堵，并指出过度张扬会损害可信度与社区协作。另一方（如 Frank_JWilson）则主张信息必须普及，否则无法对抗大公司。rageling 指出目前只有一个品牌的电视被逆向，而且只有两家前沿模型提供商具备足够能力完成此类工作，因此认为需要为主流电视品牌都准备好方案，同时他也认为三星并非唯一存在问题的厂商。以上均为个人观点，并非已证实的事实。
参考链接（2）
6 Meta字节级小模型：起步落后，外推显示训练后或反超token模型 7
Meta的这篇论文（arXiv 2609.12303）训练了约1B参数的小模型，比较直接读取原始字节的模型与读取token的模型，并用Llama 3 8B做蒸馏。论文实测显示，训练量较少时token模型明显领先，训练量增加后token模型的效果趋于平缓，而字节模型仍在提升。研究者把曲线外推后预测，字节模型最终会以几个百分点的优势超过Llama 3.2 1B和Gemma 3 1B，并且达到同等效果所需文本量约少6倍。需要注意的是，“超过”是外推的预测结果而非实测结果，实际运行中token模型仍然领先。此外，逐字节处理每段文本的步数约为token的5倍，计算成本更高，且结论目前只在小模型上验证。
背景：字节级模型与分词之争
目前大多数语言模型以子词（token）为基本输入单位，而小模型常通过蒸馏从同一分词方式的大模型中学习能力。论文《Breaking the Token Ceiling》（arXiv:2609.12303，来自 Meta FAIR 与华盛顿大学）的核心问题是：经过蒸馏的字节级模型与 token 模型，随算力和数据增加时，其扩展规律是否相似。
对开发者的影响
目前的证据还不足以支持在小模型上改用字节级方案。对于正在为手机或笔记本部署小模型的开发者来说，现阶段仍应以token方案为主，字节级方案可作为关注的研究方向。
社区讨论
社区中有较强的怀疑声音。有评论认为字节级分词并不新鲜，过去被弃用主要是因为训练耗时更长，并推测Meta是因为算力更充裕才重新尝试。也有评论认为token已经能完整承载语义，字节级只在拼写上有优势，而拼写并不影响核心能力。另一方面，有评论提出可以在嵌入中加入单独的拼写编码以兼顾两者，也有人提到H-Net等相关工作。针对“字节级在所有重要任务上都不会更差”的说法，有评论反驳称论文摘要并不支持这一结论。核心分歧在于字节级方案除拼写外是否带来实质收益，这些观点均属于社区意见，尚未得到证实。
BuilderXAI 观点技术看不清
实测里 token 模型仍然领先，“反超”只存在于外推曲线上。外推能不能兑现，要看更大规模的训练，而推理时步数约多 5 倍的代价是实打实的。部署小模型的人现在不用动，等 Meta 放出更大规模的实测结果再说。
参考链接（2）
7 8 GB显存运行262K上下文Qwen编码模型的llama.cpp配置 7
一篇 r/LocalLLaMA 帖子分享了在 8 GB 显存显卡上用 llama.cpp 运行 262K 上下文编码模型的方法。该模型是 ISTA DASLab 发布的 3.5 BPW Coder 变体，采用 GSQ RCO 量化并删除了一半专家，帖子强调它不是 1-bit 量化。做法是用正则表达式选择性地把大部分 MoE 专家卸载到内存、最小的专家留在显存中，并建议把模型放在高速 SSD 上，所需资源约为 8 GB 显存加 24 GB 内存。作者自测提示词处理（PP）约 104 t/s、文本生成约 8 t/s；标题中的 70 t/s 指代不清，评论称改用 --load-mode none 后 PP 从约 70 提升到约 104 t/s，这些均为用户自测数据，未经独立验证。
背景
这类模型采用混合专家（MoE）架构，总参数很大，但每个token只激活一小部分专家，因此可以把大部分专家权重留在内存中，只将常用部分放入显存。ISTA-DASLab的Coder版本移除了一半专家，并将保留权重量化到3.5 BPW（tool-1-1、tool-1-2）。该模型页面给出的1.89 bits是按原始模型参数量摊薄后的有效比特数，并不代表单个权重只用1.89位存储；其GGUF文件约58.4 GB，而BF16版本约354 GB（tool-1-3）。
对本地部署的影响
对只有 8 GB 显存的本地用户来说，这是一个可尝试的长上下文编码方案，但前提是有足够内存和快速存储。帖子承认 CUDA 后端在 8 GB 显存下可能无法运行，建议改用 Vulkan 后端；总内存约 32 GB 时也可运行，但需要缩小上下文。部署前应核对模型文件名与来源，因为帖子中的模型名称前后不一致。
社区讨论
评论区主要围绕参数调优展开。jonathanx37 表示，把 --load-mode mmap 改为 none 可使提示词处理提升约 50%，但会增加内存压力，并提供了更适合 8 GB 显存的精简启动参数。giant3 认为 --dry-multiplier 比 repeat 或 presence penalty 更好，因为它只在模型开始重复时介入，不会过度限制思考过程；原作者同意这一看法，但称这只是预防性设置，并表示在其他 Qwen 模型上有效。目前讨论样本较少，各项结论主要基于作者个人经验，尚无独立测试。
BuilderXAI 观点技术
这是一份能直接抄的穷人长上下文配置，但要算清楚代价。
- 机制：MoE 每个 token 只激活少数专家，用 llama.cpp 的张量覆盖正则（
-ot）把大部分专家放到内存，显存只放注意力层和 KV cache。 - 成本：8 GB 显存加约 24 GB 内存，外加快速 SSD。生成约 8 t/s，跑交互式补全偏慢，适合丢给 agent 后台慢慢跑。
- 坑：删了一半专家再做 3.5 BPW 量化，代码质量损失没有独立评测。8 GB 卡上 CUDA 可能跑不起来，要换 Vulkan。
- 上手：先照帖子配置跑通，再试评论里的
--load-mode none（提示词处理更快，但更吃内存）和--dry-multiplier。下载前核对模型文件名，帖子里前后写得不一致。
参考链接（3）
8 ISTA 发布 DeepSeek-V4.1-Flash-1017 的 GSQ-RCO GGUF 量化版本 7
ISTA 深度算法与系统实验室发布了 DeepSeek-V4.1-Flash-1017 的三个 GGUF 量化版本，分别为 IQ1_M（1.75 bpw，即每权重平均比特数）、IQ2_XXS（2.00 bpw）和 IQ2_XS（2.25 bpw），主干文件大小为 120.7 至 155.2 GB，另附一个所有版本共用、可内存映射的 110.6 GB Engram 查找表文件。作者称这些版本可通过 Strata 在单张 12 GB 显存的 NVIDIA GPU 上运行，但 llama.cpp 目前尚不支持 DeepSeek-V4.1，因此这些 GGUF 暂时无法在 llama.cpp 中使用。质量结果均为作者自行报告，在 reasoning effort 50 下测得：IQ2_XXS 在 AIME25、GPQA-Diamond 和 LiveCodeBench v6 上与基座模型持平，IQ1_M 的任务平均分保留了基座的 98.7%，IQ2_XS 的结果尚待公布。
背景
DeepSeek-V4.1-Flash 的许可证据称为 MIT，这使离线部署成为可行选择，但这一说法来自第三方视频摘要，尚未经官方原文核实。Strata 是由 Niko1221 开发的开源本地推理引擎，目标是在消费级游戏电脑上运行大型混合专家（MoE）模型，本次发布的量化模型正是面向这一引擎，而非 llama.cpp。
对使用者的影响
如果你的目标是在消费级显卡上本地运行这一大型 MoE 模型，目前可行的路径是 Strata，而不是 llama.cpp 生态；若你依赖 llama.cpp，需要等待其支持 DeepSeek-V4.1 后再使用。另外，主干文件仍有 120.7 至 155.2 GB，即便 Engram 文件可以保留在磁盘上，内存与存储容量仍是实际门槛。
社区讨论
讨论的核心分歧在于基准分数能否证明质量没有明显下降。多位评论者认为，该发布只展示了接近饱和的 90% 以上分数，缺少 KLD 或困惑度等数据，因此无法反映真实退化程度，也有人指出研究团队若内部已有这些数据，理应公开。另一些评论者则认为 KLD 本身容易产生误导，不应依赖单一数字，若必须使用，应基于基座模型生成的数据计算，并对提示词 token 赋零权重。另有用户询问 112 GB 总内存（48 GB 显存加 64 GB 内存）能否运行 120 GB 的 IQ1_M，回复指出仅主干就短缺约 8 GB，尚未计入上下文和其他开销。
BuilderXAI 观点技术
能在 12 GB 卡上跑是真的，但总存储门槛约 230–270 GB（主干 120–155 GB 加上 110 GB 的 Engram 表），这才是真正的门槛。
- 对比：这次不走 llama.cpp 生态，依赖 Strata 一个引擎，工具链和社区支持都要另起炉灶。
- 质量：只给了 AIME、GPQA 这类接近饱和的分数，评论要 KLD 的要求是合理的。1.75 bpw 保留 98.7% 的说法需要看长对话和代码任务才能信。
- 难度：硬核。内存不够 128 GB 的基本别试，评论里 112 GB 的配置连主干都装不下。
- 上手：想玩就用 Strata 加 IQ2_XXS。依赖 llama.cpp 的话，等它支持 V4.1 再说。
参考链接（2）
9 KLD 被误解了：适合诊断量化偏差，但不能直接排名模型质量 7
这篇 r/LocalLLaMA 帖子认为，KL 散度（KLD）是比较量化模型的有用诊断工具，但不应被当作能对所有量化模型进行质量排名的通用指标。作者指出两类常见问题：一是用维基百科等通用文本计算 KLD，与模型实际推理时的上下文分布不符，更合理的做法是用基础模型生成文本，并忽略提示词部分的 token；二是若用量化校准数据或分布相似的数据评估，或在评估数据上微调量化缩放参数，KLD 数值会被明显美化。作者还强调，KLD 高低并不直接等同于任务表现，该文属于观点性质，未提供新的实测数据。
背景：KL 散度与 Heretic 工具
KL 散度（KLD）衡量两个概率分布之间的差异，在量化评估中，通常是把同一段文本分别输入原始模型和量化模型，逐 token 比较两者 logits 对应的分布，再对所有 token 取平均。社区中的 Heretic 工具也把 KLD 作为优化目标之一：它会同时最小化拒答次数与修改后模型相对原始模型的 KL 散度，以在去除审查的同时尽量保留原模型的行为（[tool-1-2]）。这种用法使 KLD 被广泛视为衡量模型“偏离原模型程度”的指标，也是帖子讨论其适用范围的背景（[tool-1-1]）。
影响
对于比较或选择量化版本的用户而言，不应只看单一 KLD 数字：应使用相同的输入、避开量化校准数据，并结合具体任务的测试来验证模型是否满足需求。
社区讨论
社区总体认同该文的提醒，但对 KLD 的可信度存在分歧。jacek2023 称赞该帖质量较高；AmielaTunerani_18 认为不同评估数据集之间的方差可能大于模型间的微小 KLD 差距，因此不应过度解读小幅差异。-p-e-w- 反驳称，只要对所有模型使用相同输入自行计算，KLD 就是比较量化方案的最佳指标之一，且比任务型基准更全面；zerofata 则主张不应只依赖 KLD，应结合人工测试；LagOps91 认为所有指标都有缺陷，但 KLD 比困惑度（perplexity）更有用、更稳定，并追问若不用 KLD，还应采用什么替代方案。
BuilderXAI 观点技术
这篇正好可以拿来检验今天另外两条量化新闻，结论很实用：KLD 是体检，不是考试排名。
- 关键做法：用基座模型自己生成的文本算 KLD，提示词部分的 token 权重设为 0，并且避开校准集，否则数字会被美化。
- 和 -p-e-w- 的说法不矛盾：同一批输入、自己算，KLD 用来比较同一模型的不同量化版本很好用；跨模型、跨数据集比较才会失效。
- 实操：选量化版本时，先用 KLD 排除明显退化的，再用 20–50 条自己真实场景的提示词人工对比。没有现成工具的话，llama.cpp 的 perplexity 工具支持保存基座 logits 再算 KLD。
参考链接（2）
10 Anthropic 安全负责人声明引争议：AI 发现的旧漏洞与提前泄露 7
r/ClaudeAI 上的一个帖子讨论了一份据称出自 Anthropic 安全负责人的声明，但帖子正文为空，无法核实声明的原文措辞。根据评论区的说法，相关漏洞自 2012 年起就存在，这次是 AI 找到并利用了它，而漏洞细节在补丁发布之前就已泄露。讨论的焦点是 Anthropic 的表态是否自相矛盾。
背景：AI 发现漏洞的规模与实际利用率
据 TheUnum 的报道，Anthropic 曾借助 AI 发现数百个漏洞，相关工作与 Project Glasswing 有关。安全研究人员 Patrick Garrity（VulnCheck）指出，与 Anthropic 或 Project Glasswing 相关的漏洞中，在真实环境中被利用的比例不到 0.5%。这一背景有助于理解 Reddit 讨论中的争议焦点：AI 发现漏洞的数量已相当可观，但多数漏洞并未被实际利用，而责任应如何划分仍有分歧。
社区讨论
批评者认为 Anthropic 一边宣称 AI 有安全风险，一边又让自家 AI 去找并利用漏洞，还在补丁发布前泄露了细节，因此把它比作明知醉驾仍上路，然后怪别人没拦住。另一些用户则认为，漏洞已存在十多年，AI 只是发现者，而提前泄露是人为失误，不应归咎于 AI。还有评论指出，这件事之所以上了头条，只是因为当时没有可用补丁，而大多数人本来就不会及时安装安全更新。这些都是评论者的观点，帖子本身没有提供可核实的一手材料。
11 Claude Code 十天打造滑板下坡游戏 Cruising Bones 进入内测 7
开发者在 Reddit 分享了其使用 Claude Code、Claude AI、Magnific、Tripo 和 BabylonJS 引擎制作的下坡滑板游戏 Cruising Bones，目前处于 Alpha 内测阶段，可在 cruisingbones.com 免费试玩。美术素材是开发者让 Claude 在浏览器中登录 Magnific 和 Tripo 账号后生成的，参考对象是开发者已 3D 打印的骷髅滑板手形象，前后大约用了两天完成美术与游戏氛围设计。此后开发者每次测试都把需要改进或新增的内容列给 Claude 迭代，本次第 3 版更新在 10 月 14 日启动后约十天完成，新增了剧情与菜单调整、三名 Rattler 角色、多个赛道的新障碍，以及木板残骸保留在路面上等改动。
背景
该游戏《Cruising Bones》于10月14日开始开发，本次为第三次更新，目前处于Alpha阶段并可在网页上免费游玩。开发者使用BabylonJS（一个运行于浏览器中的JavaScript 3D游戏引擎）构建游戏，美术资源则借助Magnific和Tripo等工具，以开发者自己3D打印的骷髅滑板手模型为原型生成。
社区讨论
评论区整体评价正面，多数人认为游戏风格鲜明，十天的开发成果令人印象深刻，有评论称其“令人上瘾”。主要批评集中在操控和画面上：有玩家认为转向灵敏度偏高，弯道中速度会莫名下降，并建议按住空格键来改善转向；另有人指出远景不够清晰，游戏看起来不像真正的下坡。开发者表示会调查转向问题，并在考虑提升远景可见度。还有评论者建议参考真实的下坡长板视频，指出骑手在弯道中几乎贴近地面，这可以作为操控与镜头的参照。
BuilderXAI 观点技术
最值得学的不是十天做出一个游戏，而是让 Claude 直接在浏览器里操作 Magnific 和 Tripo 来生成素材，把美术流水线也交给了 agent。
- 难度：入门到中等。BabylonJS 是纯网页技术栈，Claude 对它很熟，最快能出效果。
- 短板正好出在评论里说的手感上：转向灵敏度、弯道减速、远景可见度。这类东西 agent 没法自己玩来验证，只能靠人反复测试后列清单。
- 上手：参考他的迭代方式，每轮自己试玩后写一份改进清单交给 Claude。物理参数单独放进配置文件，调手感时就不用每次都改代码。
12 ScreenPlink：用 Claude Code 开发的开源激光干复射击游戏 7
开发者 vkorost 用 Claude Code 在约两周内开发了开源（Apache-2.0）激光干复射击游戏 ScreenPlink。玩家用红色激光训练枪射击显示器作为靶子，显示器旁的网络摄像头观察屏幕，程序据此计算命中的像素位置、显示弹孔并使靶子倒下，并提供九种训练项目、15 个带环数的靶面以及双人同屏模式。作者称几乎全部代码由 Claude Code 编写，并通过让 Claude 调用项目内置的 MCP 服务器读取摄像头画面和检测数据来调试。文中的可靠性数据（如 326 项变异测试全部被捕获、约 84% 至 89% 的扣扳机被检测为有效射击）均为作者自述，尚未经过独立验证。
背景
经典光枪游戏（如任天堂的《Duck Hunt》）通常依靠枪管内的光电二极管感知屏幕亮度变化来判定命中。ScreenPlink 则换了思路：它用一个放在显示器旁的摄像头观察屏幕本身，并在显示器上绘制弹孔，让激光训练器的光点位置可以被识别。该项目被媒体形容为让人联想到《Duck Hunt》等经典光枪游戏的设计，但其检测原理与这些游戏并不相同。
对用户的影响
想尝试该项目的用户需要 Windows 系统、哑光（防眩光）显示器、支持 60 fps 的网络摄像头和红色激光训练器，光泽屏幕和电视无法使用。发布包内附 CLAUDE.md 和 .mcp.json，用户可在 Claude Code 中打开解压后的目录，让 Claude 自动完成摄像头选择、应用启动等配置。
社区讨论
评论区主要围绕两点展开。有人问如何把这类爱好变现，作者表示自己也不知道答案；另有人指出任天堂二十年前就做过类似产品，作者回应称任天堂的方案并非开源，需要购买其专用软件和硬件。另一位评论者补充说，《打鸭子》（Duck Hunt）依靠枪管内光电二极管感应屏幕亮度变化来判定命中，与本项目通过摄像头识别屏幕坐标的原理并不相同。
BuilderXAI 观点技术
亮点在调试方式：项目内置 MCP 服务器，让 Claude 自己读取摄像头画面和检测数据。硬件和视觉类项目最难的就是 agent 看不到现场，这招把它补上了。
- 难度：中等，门槛在硬件：哑光屏、60 fps 摄像头、红色激光训练器，光面屏和电视用不了。
- 可靠性：约 84%–89% 的扣扳机被检测为有效射击，用于训练还可以，用于计分比赛偏低。
- 上手：只想学方法的话，看它的
CLAUDE.md和.mcp.json怎么写，把“给 agent 装传感器”这个思路搬到自己的硬件项目里。
参考链接（2）
13 Claude Code 开发者 Thariq 宣布离开 Anthropic 7
Claude Code 开发者 Thariq（X 账号 @trq212）于 2026 年 10 月 24 日在 X 上发帖宣布，自己已离开 Anthropic。他表示在 Anthropic 工作一年多，参与了 Claude Code 的开发并见证其规模增长，目前计划先休息一段时间，再投入新的事情。帖子没有透露他的下一步去向，也没有提及 Claude Code 的产品路线或相关负责人的交接安排。
背景
Claude Code 是 Anthropic 推出的命令行编程智能体工具，可在终端中协助开发者阅读代码、修改代码并执行命令。这条动态是作者本人的离职公告，原文没有提及产品路线、团队交接或接任安排。
BuilderXAI 观点行业
单个人离职不代表产品要变，但 Thariq 是 Claude Code 对外沟通最活跃的面孔之一，用户感知到的“产品温度”会受影响。更大的背景是：编程 agent 的核心团队都不大，做过这类产品从零到规模化的人现在是稀缺资源，创业和挖角都会盯着他们。对用户来说，短期该看的是 Claude Code 的更新节奏和公开沟通有没有变慢。
14 Goose 语言：无堆、无垃圾回收的内存安全系统语言 6
Goose 是作者 Aardappel 开发的内存安全系统语言，不使用堆分配器、垃圾回收、引用计数或析构函数。所有动态值都放在编译器静态分配的数据栈上，作用域结束时即释放内存。项目页面称，在其仓库的十六项基准测试中，Goose 速度约为惯用 C++ 的 3.3 倍、约为最佳安全 Rust 的 1.12 倍，且内存占用更少，这些数字是项目方自报的结果。
背景
Goose的内存模型接近区域式（region-based）内存管理：数据不逐个释放，而是按作用域整体回收，作用域结束时数据栈顶回退即完成释放。据GitHub仓库介绍，该语言没有堆分配器、垃圾回收器，也不需要生命周期标注，内存由编译器静态分配到若干数据栈上。评论区有用户（ebiederm）回忆ML语言系统曾走过类似的regions路线，但认为在不少程序中内存占用过高而被视为死路，这属于个人记忆，本文未作核实。
对开发者的影响
Goose 的适用范围有明确限制：程序需要在编译期确定可增长内存区域的数量，而且由于没有垃圾回收，数据栈在运行中只能增长，旧数据不再使用时内存也不会自动回收，因此需要谨慎控制内存占用。性能数据来自作者自己的基准测试，采用前应在自身工作负载上验证。
社区讨论
讨论大致分为几种观点。提问者 malisper 质疑固定数量的数据栈如何表示任意数量、可动态增删的字符串（例如值为字符串的哈希表），这是对该语言表达能力最直接的疑问。pradn 认为面向受限用途的语言是可以接受的，只要能静态指定可增长内存区域的数量即可使用，但提醒在无垃圾回收的情况下栈可能持续膨胀；ebiederm 则指出 ML 语言曾走过类似的“区域（regions）”路线，但认为在内存占用较大的程序上行不通。另有 bobbydigitales 转引 John Carmack 的评价，称其直接内存映射和网络数据处理能力有助于避免解析开销，这是一位知名开发者的正面意见，但并非独立的基准结果。
BuilderXAI 观点技术
Goose 本质上是把 arena 和 region 分配做进了语言本身。C++ 游戏和网络代码里早就有人手写 arena，Goose 把它变成了默认规则，再加上安全保证。
- 强项：解析二进制、处理网络包、批处理这类“读进来、处理完、整块扔掉”的负载，Carmack 夸的也是这一点。
- 弱项：长期运行、数据动态增删的服务（比如 malisper 问的字符串哈希表）。没有回收机制，栈只会增长，ML 的 regions 路线当年就卡在这里。
- 性能数字是作者自测的，比 C++ 快 3.3 倍更多说明测试用的 C++ 写法不够好。
- 上手：想看清它的边界，挑一个解析器类的小工具用 Goose 重写，比读文档更快。
15 Show HN「Steal My Bitcoin」：PHP RCE 漏洞的比特币挑战站 6
这是一个 Show HN 挑战站点，作者在服务器上藏了价值约 502 美元的比特币钱包私钥，并称该私钥可由 PHP 用户账户通过 print-flag 程序访问，目的是测试能否利用近期的 PHP 远程代码执行（RCE）漏洞。站点使用的 PHP 版本早于 PHP2SHELL 相关 CVE 发布，评论中引用的页面文本称挑战开放约 0.65 小时时尚无成功入侵。这些奖金和进展信息来自页面文本与评论引用，尚未独立核实。
背景
PHP2Shell 是一组高危漏洞，编号为 CVE-2026-109618 和 CVE-2026-109619，涉及 PHP 5.4 至 8.5 版本中的内存安全缺陷，可能让攻击者远程执行代码并控制网站主机。PHP 于 2026 年 10 月 21 日发布了针对这两个漏洞的安全更新，两者的 CVSS v4.0 评分均为 9.2。
对运维者的影响
如果你在运行较旧的 PHP 版本，是否受 PHP2SHELL 影响取决于具体部署方式。一位评论者称，该挑战使用 CLI 服务、1 MiB 上限、静态页面和较高内存限制，这些配置会排除两个 CVE 的利用条件。这一说法来自评论者的判断，正式的受影响范围仍应以官方公告和自身环境测试为准。
社区讨论
有评论者认为，挑战在数小时后仍未被攻破，说明网上关于 AI 代理大规模自主入侵网站的说法被夸大了。另一位评论者则指出，该配置本身不易受 PHP2SHELL 影响，因此这个挑战更适合收集可利用场景的概念验证，而不能证明漏洞的普遍可利用性。作者 dguido 称团队已有可用的 RCE，但因担心在补丁窗口期内泄露细节而不愿演示；另一位用户则报告让几个 AI 代理尝试破解，部分模型把它当作公开挑战处理，另一个模型则因属于网络安全请求而拒绝。核心分歧在于：该漏洞在实际部署中是否可被利用，以及 AI 代理是否真的正在大规模入侵网站。