X 英文热点选题简报¶
今日优先看¶
- 十月安全事件潮："把这篇发给你的家人"（对应卡片 1）
现在值得做：@juampitech（10-22 06:56，帖龄 26.1h，24—48 小时，50.4 万浏览、4.8K 赞、802 转、173 回复、2.1K 收藏、272 引用）把十月的事件列成一张十五行清单：Railway 客户机密外泄、LiteLLM 恶意 PyPI 与 Docker 包、Zeabur 基础设施被入侵、OpenCode 的 AI API 密钥泄露、OVHcloud CLI 官方二进制被植入后门、Rank Math PRO 官方插件带木马、TeamUpdraft 客户数据被攻破、ConnectWise 云备份身份被攻破、Tensorlake 的 npm 包被感染、SubQuery 的 npm 包被植入后门、GhostAction 的 GitHub 仓库被写入恶意工作流、PHP 严重 RCE、Node.js 修补安全问题、eMudhra 证书机构密钥被攻破、Tailscale 受 eMudhra 事件波及，结尾是"到这个地步，最大的安全风险也许不是我们写的代码，而是我们信任的代码"。真正把这件事推出技术圈的是 @mattshumer_（10-23 04:04，帖龄 4.9h，24 小时内，32.7 万浏览、1.0K 赞、173 转、37 回复、2.4K 收藏、39 引用）的长文，以及他的分享帖 @mattshumer_（10-23 04:13，帖龄 4.8h，24 小时内，16.9 万浏览、955 赞、130 转、43 回复、1.4K 收藏、13 引用）："科技圈现在都在为安全恐慌，圈外几乎没人知道出事了。我写这篇是为了让你不用自己去跟家人解释，直接发给他们。"两条帖子的收藏都远高于点赞，说明它们被当作"转发工具"保存。
最好补充：可核实的一手材料已经有两份。Railway 官方披露（10-21）写明未授权方可能访问了加密的环境变量并解密了其中一部分，Railway 把这轮攻击描述为"一系列以攻击平台来渗透 AI 推理服务商的行动之一"，建议用户轮换全部环境变量并暂停部署。微软安全博客（10-21）写的是：代号 Storm-0940 的攻击者使用一个名为 ARTEX 的 Agent 化渗透测试框架攻击了数百个组织，部分案例不到 3 小时就拿到特权访问，微软评估 ConnectWise 被攻破也是它所为。Matt Shumer 的长文原文（10-22）给普通人的建议很具体：这几周别在陌生网站输密码和卡号；更新手机、电脑、浏览器、路由器，但绝不安装网页弹窗或短信链接里的"更新"；拔掉不用的智能设备、删掉不用的 App；任何来电短信索要密码或验证码都是诈骗，挂断后打银行卡背面的电话；银行账号密码不要交给任何人，包括 AI 助手；开两步验证、用密码管理器；备少量现金和食物饮水；不要恐慌取款。需要标注的是，文中引用的 Cloudflare CEO"2 小时内数十万次利用尝试"、Amazon"披露前 4 天已被利用"、Cisco"约一半服务器老到无法打补丁"，都是他文中的转述，本报未核实；Axios 关于大银行发现客户账户内有未授权 AI Agent 的说法同样是他转述，也标未核实。
形式与状态：独立原创帖或长帖，把"已核实事件"和"转述说法"分开放。这一条是后续：10-22 中文选题写过"一夜安全补丁潮"汇总（PHP、Node.js、nginx 等），10-23 日报写过 LiteLLM 投毒，增量在于 Railway 的官方披露、微软把 ConnectWise 事件和 Agent 化攻击框架联系起来，以及一份给圈外人的防护清单。可起草，两份官方材料已核。
- Vercel：长期静态密钥该死了（对应卡片 3）
现在值得做：@cramforce（10-23 06:30，帖龄 2.5h，24 小时内，2.3 万浏览、454 赞、45 转、39 回复、218 收藏、14 引用）说这篇帖子写了有一阵，但因为这周的安全事件必须提前发："长期存在的静态凭据必须死。我们再也不想轮换 API key 了。"他给了三个动作：要求 Vercel Marketplace 上的厂商支持 OIDC；发布 shadcn 组件，让别人更容易做出 OIDC 配置界面；扩展自家平台的 OIDC 支持。结尾那句可以直接当题目："上一代人把 web 从 HTTP 推到了 HTTPS，跨过 API key 是我们这一代的事。"动机与本周事件直接挂钩，所以它和卡片 1、2 是同一波讨论里的"解决方案"侧。
最好补充：Vercel 官方博客（10-22，作者 Malte Ubl）给出的数字是：调查 1000 多家 SaaS 厂商，只有 8.4% 支持安全认证方式。发布物是一套 OIDC UI，基于 shadcn/ui 组件库，包含信任策略配置表单和服务端 token 校验，支持 Vercel、GitHub、GitLab、Google、Bitbucket、AWS、Azure 以及自定义 issuer；Vercel 的 Blob、AI Gateway、Sandbox 已经可以在不存长期密钥的情况下访问；OIDC federation 从 2024 年就已经 GA。另有一条更早的落地样本：Amazon S3 接入 Vercel Marketplace（10-14）当时已经用短期 OIDC 凭证。关于 Marketplace 的时间表，搜索结果摘要提到：仍在用长期密钥的条目 11 月 30 日起会显示"Not secure"，2027 年 1 月未达标的厂商下架——这一条只来自搜索摘要，写作时要标"据官方博客摘要"，或者直接写"时间表以原文为准"。
形式与状态：独立原创帖，把"API key"换成"短期身份令牌"讲给中文开发者。可写的解释路径是：长期密钥的问题是它一旦泄露就一直有效，且散落在各家的环境变量里；OIDC 让服务之间用短期、可验证的身份令牌互相访问，泄露的令牌到期就失效。这与 10-23 中文选题写过的 1Password for Agents 是同一个方向：Agent 时代，凭据不该长期存在。可起草，官方博客与 changelog 均已核。
- Mollick："AI 能做 17 周的工作"——数字需要校准（对应卡片 6）
现在值得做：@emollick（10-23 01:36，帖龄 7.4h，24 小时内，3.2 万浏览、523 赞、56 转、113 回复、156 收藏、19 引用）把三个数字并排放在一起：2024 年第一本 AI 书出版时，最好的 AI 能以 50% 的成功率完成 4 分钟的人类工作；今年交《Co-Existence》稿子时是 17 小时；两天前书出版时是 17 周。三个数字的排比很适合截图传播，也正因为如此，口径问题值得单独写一篇。
最好补充：他的 Substack 原文（10-20）把来源讲清楚了：17 小时是 METR 截至 2026 年 4 月的测量，之后 METR 表示已经无法再测；"17 周"来自"其他研究提示可能达到"的估计，不是同一口径的测量。帖子把估计值和两个测量值并列，读起来像是三个同质的观测，这是这条最需要校准的地方。反方数据也有：robertwiblin（10-22 18:54，帖龄 14.1h，24 小时内，8600 浏览、107 赞、6 转、5 回复、50 收藏、0 引用）写"OpenAI 和 Google 似乎发现，它们的 AI 有 80% 的概率完成一项需要员工 15 分钟的 AI 研发任务"，并说这比它们在通用软件工程和网络安全任务上的时间跨度落后 14 个月，引用的是 Toby Ord 的文章（未核实）。这里 80% 与 50% 是不同成功率下的对照，不能直接比较。
形式与状态：独立原创帖，主题是"时间跨度指标怎么读"。三个可讲的维度：成功率口径（50%、80% 还是别的）、来源是测量还是估计、任务领域（通用软件工程、网络安全、AI 研发各不相同）。这一条是后续：10-21 英文选题写过 Mollick 的新书《Co-Existence》，增量是"17 周"这个数字的口径问题。可起草，Substack 原文已核。
候选话题¶
1. 十月安全事件潮："把这篇发给你的家人"（后续）¶
原帖与热度：见「今日优先看」第 1 条。@juampitech（10-22 06:56，帖龄 26.1h，24—48 小时，50.4 万浏览、4.8K 赞、802 转、173 回复、2.1K 收藏、272 引用）；@mattshumer_（10-23 04:04，帖龄 4.9h，24 小时内，32.7 万浏览、1.0K 赞、173 转、37 回复、2.4K 收藏、39 引用）；@mattshumer_（10-23 04:13，帖龄 4.8h，24 小时内，16.9 万浏览、955 赞、130 转、43 回复、1.4K 收藏、13 引用）；@emollick（10-22 08:22，帖龄 24.6h，24—48 小时，14.0 万浏览、1.9K 赞、182 转、134 回复、450 收藏、20 引用）；@rileybrown（10-23 03:20，帖龄 5.6h，24 小时内，7.5 万浏览、244 赞、7 转、81 回复、181 收藏、3 引用）；汇总帖 @heybeluga（10-23 02:31，帖龄 6.5h，24 小时内，2.1 万浏览、55 赞、8 转、12 回复、2 收藏、0 引用）。一手来源：Railway 官方披露、微软安全博客、Shumer 长文。
内容与关注点：三组帖子的互动结构不一样，指向也不同。juampitech 那条是 50.4 万浏览配 4.8K 赞、272 条引用，属于"清单式转发"；Shumer 两条是收藏高于点赞（2.4K 对 1.0K、1.4K 对 955），典型的"存起来准备转给别人"；emollick 的 14.0 万浏览配 1.9K 赞，是在给这件事定性——"攻防都在以非人速度加速，撞上需要人去反应的系统"。rileybrown 那条最像读者需求的原声：请求有人"列一份所有普通人都该做什么的清单，基于眼下这些漏洞和网络安全的状态"。heybeluga 的汇总帖则在纠一个传播中的误解：不是一次巨大的入侵，而是"一堆严重漏洞、被污染的软件和暴露的凭据叠在一起"，其中 PHP 漏洞让一些政府和公司先把网站下线再打补丁。
为什么值得做（可写角度）：中文圈目前的讨论基本停在开发者视角（换 key、打补丁），而 Shumer 和 rileybrown 指向的是另一个受众：不懂技术、但需要知道该做什么的人。可写一份分层清单：给家人的（不点链接里的"更新"、不在陌生站输卡号、验证码不给任何人、开两步验证）；给独立开发者的（假设自己已暴露，轮换、留证、查日志）；给团队的（合同与合规义务不因供应商还在调查而暂停，见卡片 2）。写作上要把"已核实"和"他文中的转述"用不同措辞分开，这是本篇最有价值的部分——读者正在拿这类清单去指导真实行为。
时效与核验：24 小时内。Railway 披露（访问加密环境变量、部分被解密、建议轮换全部环境变量与暂停部署）、微软对 Storm-0940 与 ARTEX 的描述（数百个组织、部分不到 3 小时拿到特权访问、ConnectWise 事件同源）均已核验；Cloudflare、Amazon、Cisco、Axios 四处数字均为 Shumer 文中转述，本报未核实，须标"未核实"。按要求不写任何国别或地缘政治表述。
2. 云平台出事后，开发者第一时间做什么（后续）¶
原帖与热度：@DassieSpivack（10-22 12:58，帖龄 20.0h，24 小时内，23.3 万浏览、1.4K 赞、98 转、26 回复、3.0K 收藏、21 引用）以"前网络保险理赔员"的身份写了一份流程；@denk_tweets（10-22 23:11，帖龄 9.8h，24 小时内，6.3 万浏览、253 赞、12 转、130 回复、104 收藏、19 引用）补了另一半现实。
内容与关注点：收藏 3.0K 对赞 1.4K，说明这是一份被存下来照做的清单，而不是围观帖。她的核心判断有三条：供应商一披露，就当作自己已经暴露，立刻去轮换所有密钥，"哪怕你在约会、在孩子的毕业典礼上"；把每一步都带时间戳记下来，包括暂时轮换不了的东西和尝试的时间，理由是"如果将来变成理赔，你能一分钟一分钟地证明自己该做的都做了，就能活下来"；不要等供应商调查结束再通知自己的客户，因为合同与法律义务不会因为供应商还在查而暂停，错过一个截止日期是很贵的教训。denk_tweets 那条是同一件事的另一面："恭喜你 vibe coding 出了自己的软件，你现在也是安全负责人了"——他说昨天 Railway 出事后，成千上万的 vibe coder 和公司花了一整天轮换所有 API key、密码、token，然后还得审计整个技术栈。回复 130 条远超转发 12 条，说明它主要被拿来吐槽和争论。
为什么值得做（可写角度）：把她的经验翻译成"出事后 24 小时"的四步：轮换（全部，不是"可能泄露的那几个"）、记录（时间戳，含失败与延迟）、查（调用日志与账单异常，看有没有人在用你的密钥干活）、告知（先看合同与适用法律要求的时限，再动手写通知）。可写的一个反直觉点是"写得越少越安全"的直觉是错的——她的原话是"你会想尽量少留书面记录，我懂这种本能，要做相反的事"。这条与 Railway 官方建议（轮换全部环境变量）一致，可互相印证。
时效与核验：24 小时内。作者身份为自称，未独立核实；流程建议属专业经验，不是可验证事实，写作时应标"她的说法/经验"。与 Railway 官方建议的一致性已核；denk_tweets 的"成千上万"是修辞性描述，不引用为数字。
3. Vercel：长期静态密钥该死了¶
原帖与热度：见「今日优先看」第 2 条。@cramforce（10-23 06:30，帖龄 2.5h，24 小时内，2.3 万浏览、454 赞、45 转、39 回复、218 收藏、14 引用）。一手来源：Vercel 官方博客（10-22，作者 Malte Ubl）、Amazon S3 接入 Marketplace 的 changelog（10-14）。
内容与关注点：这里的"8%"是一个可传播的行业数字：1000 多家云与 SaaS 厂商里，只有 8.4% 支持安全的替代认证方式。帖子的结构也很清楚：先用数字说明现状有多糟，再给三个自家承诺（要求 Marketplace 厂商支持 OIDC、放出 shadcn 组件、扩展自家平台支持），最后用 HTTP 到 HTTPS 的历史类比把"跨过 API key"讲成一代人的事。这个类比本身就是可写点：HTTPS 的普及靠的不是"大家都更小心了"，而是默认值、证书工具链和平台强制。
为什么值得做（可写角度）：给中文开发者写"为什么短期令牌比 API key 安全"的入门版，关键是讲清失效窗口：长期密钥泄露后一直有效，短期令牌到期即失效，能被滥用的时间窗口有限。再补一层产品判断：Vercel 的做法是"平台先用强制手段把生态推过去"（Marketplace 准入 + 组件降低接入成本），这比发一篇倡议有效。也可以写反面：8.4% 说明生态惯性极大，任何单个平台的强制都很慢。
时效与核验：24 小时内。8.4%、shadcn 组件、支持的 issuer 列表、Blob/AI Gateway/Sandbox 已可不存长期密钥、OIDC federation 自 2024 年 GA，均已从官方博客核验；Marketplace 11 月 30 日显示"Not secure"、2027 年 1 月下架的时间表只见于搜索摘要，须标"据官方博客摘要"或注明"以原文为准"。
4. 让 Codex 用电脑帮你做安全自查（Mollick 的提示词）¶
原帖与热度：@emollick（10-23 04:06，帖龄 4.9h，24 小时内，3.2 万浏览、403 赞、22 转、37 回复、380 收藏、3 引用）："给带电脑操作的 Codex 一个很有用的提示词。"配图原文（已看图）："Given recent IT security news, can you please audit my various accounts and what I've got installed on the computer and let me know the actions I need to take?"收藏 380 几乎追平赞 403。
内容与关注点：收藏接近点赞，是"准备照着用"的信号。这条的价值在于把卡片 1 的焦虑变成了一个可执行动作：让 Agent 盘点"装了哪些软件、有哪些账号、要做什么"，正好对上 Shumer 清单里"更新软件、删不用的 App、开两步验证"那几项——人自己盘点很慢，Agent 很快。张力也在同一处：Shumer 的文章明确说不要把银行账号密码交给 AI 助手。
为什么值得做（可写角度）：适合写"哪些自查可以交给 Agent，哪些不行"。可以交出去的：列出已安装软件与版本、找出久未更新的、列出登录过哪些服务、生成一份待办清单。不能交出去的：银行与邮箱主密码、验证码、身份证件照片。可给一个中文版提示词模板，把范围写死在提示里（只读盘点、不改设置、不登录新网站、输出清单而不是替你操作），再配一条批准机制：涉及改设置、装软件、输密码的每一步都要人点头，这一点与 10-23 中文选题写过的 1Password for Agents 的逐次批准是同一思路。可写角度还包括"Agent 自查的盲区"：它看到的只是这台电脑，看不到手机、路由器、纸质备份，也看不到账号在别处的登录记录。
时效与核验：24 小时内。提示词原文已看图核对；帖子本身只是推荐，没有给出实测结果，不能写"实测有效"。
5. Composio Firewall：给 Agent 加运行时边界¶
原帖与热度：@KaranVaidya6（10-22 23:25，帖龄 9.6h，24 小时内，2.6 万浏览、86 赞、28 转、22 回复、46 收藏、10 引用）发布 Composio Firewall，称其为"给 Agent 的运行时边界"。
内容与关注点：他的论证结构是"传统软件的边界在构建时设定，Agent 的边界必须在运行时设定并执行"。产品描述是：Agent 的每一个动作都用一个叫 Jev 的东西加上 Composio 基于真实使用数据调过的小模型来评估，同时检查 Agent 发出的动作和返回给 Agent 的信息（即两个方向都拦），目的是验证 Agent 是否遵守用户意图和开发者、用户设定的边界，并提供防提示注入等攻击的安全层；现已对所有 Composio 开发者开放。这条属于厂商自述，效果未独立验证，帖子本身也没给基准或案例。
为什么值得做（可写角度）：适合作为"Agent 权限三层：凭据、动作、数据"框架里的一个例子，和卡片 3（凭据）、卡片 4（谁来做自查）串成一条线：凭据层解决"Agent 拿什么身份"，动作层解决"它能做什么"，数据层解决"它能看到什么"。可写的判断标准比产品介绍有用：边界是在运行时拦，还是在构建时写死；拦截是基于规则、基于模型判定，还是两者结合；误拦与漏拦各自怎么处理。写到产品能力时明确标"厂商自述"。
时效与核验：24 小时内。全部内容来自创始人自述，未独立核实，无第三方评测；"数百万用户和开发者已在用 Composio"同属自述，不引用为行业数据。价值观察，先观察。
6. Mollick："AI 能做 17 周的工作"——数字需要校准（后续）¶
原帖与热度：见「今日优先看」第 3 条。@emollick（10-23 01:36，帖龄 7.4h，24 小时内，3.2 万浏览、523 赞、56 转、113 回复、156 收藏、19 引用）；反方数据 @robertwiblin（10-22 18:54，帖龄 14.1h，24 小时内，8600 浏览、107 赞、6 转、5 回复、50 收藏、0 引用）。一手来源：One Useful Thing（10-20）。
内容与关注点：113 条回复对 56 条转发，说明这条被拿去争论的多、被当结论转的少。可核的部分是引用链：Substack 里 17 小时明确对应 METR 截至 2026 年 4 月的测量，并说明 METR 之后表示无法再测；"17 周"是"其他研究提示可能达到"的估计。也就是说，帖子里三个数字里，两个是测量、一个是估计，而排比句式抹掉了这个区别。robertwiblin 那条给的是另一种校准：OpenAI 和 Google 的 AI 在 AI 研发任务上以 80% 成功率能完成员工 15 分钟的任务，比通用软件工程和网络安全任务的时间跨度落后 14 个月——同一件事换任务领域，结论的乐观程度会变。
为什么值得做（可写角度）：写成"怎么读时间跨度"的科普，比争论"AI 是不是要超过人"有用。三个必须问的问题：成功率是多少（50% 和 80% 是两条完全不同的曲线）；这是测量还是外推（METR 自己说测不了了，这就是信息）；任务领域是什么（写代码、找漏洞、做 AI 研发，难度曲线不平行）。最后可以给读者一句实用结论：看到"AI 能完成 X 小时工作"时，先找括号里的成功率，找不到就不要转。
时效与核验：24 小时内，后续（10-21 英文选题写过新书《Co-Existence》，本条只取口径问题）。17 小时、17 周各自的来源已从 Substack 原文核验；robertwiblin 引用的 Toby Ord 文章未核实，须标"他引述"；两处成功率口径不同，不可并列表述为"提升"。
7. 民调：57% 美国人认为 AI 对社会有害，但一半人说对自己有好处（后续）¶
原帖与热度：@disclosetv（10-22 20:27，帖龄 12.5h，24 小时内，6.2 万浏览、582 赞、50 转、39 回复、45 收藏、32 引用）："57% 的美国人认为 AI 对社会有害，但一半人说对自己个人有好处——新民调。"一手来源：ABC News 报道（10-21）。
内容与关注点：这条的新闻点不是"57%"，而是两个数字的落差：对社会 57% 说有害、42% 说有益；对自己个人则是 50% 有益、49% 有害。年龄分层更清楚：30 岁以下 65% 认为对社会有害，30—39 岁 59%，40 岁以上 53%——越年轻越悲观。另有两条与本周事件直接相撞的数据：73% 认为 AI 入侵安全计算机系统的风险高；65% 认为会消灭很多工作。数据中心则是另一个独立的不满来源：三分之二反对在美国新建，若建在自己社区，反对升到 72%。
为什么值得做（可写角度）：可以写"抽象的 AI 与具体的 AI"这个落差：同一个受访者，可以说这项技术对社会有害，同时承认它对自己有用。这个结构在中文读者里同样存在，讨论时容易互相误读——一方在谈系统风险，一方在谈工具体验。可写的第二层是 73% 那个数字：本周的十五起事件清单正好是它的现实注脚，两者并读比单独引用任何一个都有说服力。数据处理上要交代清楚口径：ABC/华盛顿邮报/Ipsos，10 月 9—13 日，2,545 名成年人，误差 ±2 点。按要求不写党派分布和任何政治人物相关内容。
时效与核验：24 小时内，后续（10-21 英文选题写过"年轻人讨厌 AI"，增量是大样本民调数据，以及 73% 担心 AI 入侵系统与本周安全事件的呼应）。全部百分比、样本量、日期、误差范围已从 ABC 报道核验；"一半人说对自己有好处"与 50% 的四舍五入一致。
8. Claude Duet 上手：没有人格化的个人 Agent，以及一个开源替代（后续）¶
原帖与热度：@AlexFinn（10-22 03:33，帖龄 29.4h，24—48 小时，18.5 万浏览、1.5K 赞、68 转、123 回复、595 收藏、8 引用）在发布前就押了一注；首批真实体验 @rileybrown（10-23 06:23，帖龄 2.6h，24 小时内，8989 浏览、161 赞、32 回复、11 收藏、0 引用）；开源复刻 @matchaman11（10-22 14:14，帖龄 18.7h，24 小时内，4.2 万浏览、324 赞、23 转、29 回复、353 收藏、15 引用）；集成方 @canva（10-22 06:19，帖龄 26.7h，24—48 小时，1.1 万浏览、151 赞、22 转、29 回复、34 收藏、1 引用）；旁观 @MatthewBerman（10-22 03:25，帖龄 29.6h，24—48 小时，2.4 万浏览、443 赞、12 转、20 回复、48 收藏、0 引用）。
内容与关注点：AlexFinn 那条虽然是发布前的预期，但论证值得引用：他认为个人 Agent 这个外壳之争比模型之争更重要，因为"人们正把邮件、日历、短信、财务全都交给个人 Agent"，赢家拿到的数据能用来训练更好的模型。rileybrown 的第一印象正好补上产品侧的一句评价："第一个没有脸、不拟人化的个人 Agent，比一队 Agent 更不压迫。"matchaman11 的 Open-Duet 主打三点：开源可自托管、执行前需批准、能连个人应用（仓库未核实，未实测）。canva 的集成说明给了一条细节：Duet 发送任何东西前会先问。MatthewBerman 的"又一个个人 Agent"是这一波里最轻的一句，也提示同质化。
为什么值得做（可写角度）：值得写的是"人格化与否"这个设计选择，而不是功能清单。给 Agent 一张脸和名字，用户会自然把它当同事，容忍度更高，也更容易过度授权；不给脸，用户更容易把它当工具，检查得更勤。这与本周的权限讨论是同一条线：谁的边界更清楚，谁更适合处理邮件和钱。第二个角度是开源复刻的速度——Duet 刚发布，社区版本已经出现，可写"自托管个人 Agent 值不值得"：可控性换来的代价是维护、连接器适配和安全责任都在自己身上。
时效与核验：24 小时内（体验与开源替代），AlexFinn 那条 24—48 小时。这一条是后续：10-22 日报写过 Duet 发布，增量是首批真实体验与开源复刻。Open-Duet 的仓库未核实、未实测，须标"发布方自述"；canva 是集成方自述；rileybrown 的"没有人格化"是他的观察，不是官方定位。
9. Codex 用户：问题不是额度，是模型（后续）¶
原帖与热度：@StefanoGPT（10-22 15:13，帖龄 17.8h，24 小时内，14.4 万浏览、1.7K 赞、34 转、120 回复、75 收藏、12 引用）；对照样本 @SKatalystAI（10-23 05:57，帖龄 3.0h，24 小时内，1.0 万浏览、90 赞、1 转、42 回复、7 收藏、0 引用）。
内容与关注点：StefanoGPT 做了 28 天实验，结论是"Codex 最大的问题不是用量限制（重置那么多次基本已经解决了），而是模型"；他说试过 Opus 5.5 之后，很难再信任 Astra。这是个人体验，没有统一评测，也没给任务集。SKatalystAI 那条提供了另一种荒诞感：为了在免费重置过期前把额度用完，他开了 30 多个 Agent、跨 3 个项目，跑视频生成、审计、功能开发，最后周额度只用了 82%，免费重置先过期了。
为什么值得做（可写角度）：讨论重心正在从"额度够不够"移到"模型值不值得信任"，这个转向本身值得写。可写"换模型的真实成本"：不是订阅费，而是你已经围绕某个模型的脾气建立的工作流——它习惯怎么写计划、什么时候会撒谎、要不要人复核。也可写一个反面提醒：StefanoGPT 的"很难再信任"是体感判断，缺少任务集和评分，读者不该把它当成模型对比结论；SKatalystAI 的 82% 则说明额度焦虑在头部用户那里已经反转成"用不完"。
时效与核验：24 小时内。这一条是后续：10-23 中文选题写过 Codex 额度重置，增量是讨论从额度转向模型信任。两条均为个人体验，无统一评测方法；"Opus 5.5 比 Astra 更可信"不能写成结论。
10. swyx：Opus 5.5 是最好的工作量估算模型¶
原帖与热度：@swyx（10-22 22:56，帖龄 10.1h，24 小时内，1.8 万浏览、231 赞、8 转、171 回复、84 收藏、6 引用）："Opus 5.5 是我用过最好的工作量估算模型"，并说这种校准随着我们把越来越多工作委派出去而越来越重要——"别告诉我这要 2 到 3 个工作日（人类的速度），对你这个热情、不知疲倦的……"（帖文在此处截断）。
内容与关注点：171 条回复对 8 条转发，是典型的"引来一堆人分享自己经验"的帖子。配图（已看）是他让模型"做合理估计"后得到的输出：一张分组表格，每组给出数量、预计完成时间与依据（例如重试成功率约 80%、部署 45 分钟），再加一列上限和一份风险列表。价值不在"哪个模型估得准"，而在"让模型估时的时候要求它给出依据和风险"这个格式。
为什么值得做（可写角度）：可直接做成提示词模板：让 Agent 先按自己的速度估时，不要按人类的工作日；要求按任务组列出数量、耗时、依据、上限、风险五列；要求把不确定性写成区间而不是单点。再补一句使用提醒：估算的依据要可核（重试成功率、部署耗时这类数字应该来自项目本身，不是模型的印象），否则得到的是自信的编造。这条与卡片 9 可以合看：一边是"模型值不值得信任"，一边是"怎么让模型的输出可检查"。
时效与核验：24 小时内。属个人使用体验，无评测；配图内容已看图核对；帖文截断处按原意转述，不补全。
11. AEO 实验：AI 引用的网站中位 DR 是 86¶
原帖与热度：@tibo_maker（10-21 17:30，帖龄 39.5h，24—48 小时，1.5 万浏览、152 赞、7 转、66 回复、249 收藏、6 引用）：他向 ChatGPT、Perplexity、Gemini、Claude 提同一组问题，统计它们引用的 1,329 个来源，结论是被引用站点的中位 DR（域名权重）是 86。
内容与关注点：数字结构比结论更有用：只有 7% 的引用来自 DR 30 以下的站点；73% 的来源是博客类内容（清单、文章、对比），产品和落地页 7%，论坛和社交只有 3%；ChatGPT 是例外，只有 18% 是博客内容，63% 是原始来源，比如价格页或文档。他的解释是"AI 引用事实的来源地"，所以一篇重复别人统计数字的文章，本身没有可被引用的东西；另一个观察是被引页面里很多带有计算器、图表、表格或模板——因为点进去的人已经读过 AI 的摘要，是去"做点什么"，不是去"读"。末尾是他自家产品 Outrank 的推广，以及他据此重写了 280 篇文章里 275 篇的操作。
为什么值得做（可写角度）：对做 Substack 和 X 内容的人，这篇的可用结论是两条：一是"被 AI 引用"很大程度取决于站点已有的权威（DR 高、被链多），新站短期做不到，但可以争取被那些被反复引用的清单页收录；二是原创数据与可交互的页面更容易被引用，因为模型需要一个"事实的出处"。写作时必须交代利益关系：作者做 SEO 相关产品，实验方法未公开原始数据，属自测。
时效与核验：24—48 小时。属放宽门槛条目：1.5 万浏览、152 赞，高于放宽线，理由是内容创作者实操价值。所有百分比与 1,329 这个样本量来自作者自述，未公开原始数据；DR 86 是样本中位数，不是门槛值，写作时不要写成"要 DR 86 才会被引用"。
12. Gemini 4 Carbon：竞技场里的新 checkpoint（先观察）¶
原帖与热度：@NovaXCode（10-21 19:55，帖龄 37.1h，24—48 小时，1.4 万浏览、462 赞、5 转、42 回复、15 收藏、3 引用）："Gemini 4 Argon 过去一小时就能烧完我的周额度，新的 Gemini 4 Carbon 夸张到可能十分钟就烧完。"测试帖 @pankajkumar_dev（10-22 21:33，帖龄 11.4h，24 小时内，1.3 万浏览、113 赞、6 转、13 回复、23 收藏、1 引用）。
内容与关注点：pankajkumar_dev 的记录比较具体：Google 在 LMArena 上放了两个 checkpoint，两个他都测了；Carbon 现在 3D 相当好，也更能理解怎么做游戏；但他认为 Opus 5.5 和 Astra 在 3D 上仍然更好；Carbon 比 Argon、Opus 等更慢，他认为应该修；前端能力一般，感觉团队更专注 3D。NovaXCode 那条的"十分钟烧完额度"是玩笑式的用量吐槽，但侧面说明这是个更重的模型。
为什么值得做（可写角度）：现在只能写"社区在竞技场里发现了什么"，不能写"Google 发布了什么"。可写的观察角度：匿名竞技场 checkpoint 的传播路径——先由少数测试者发现，再靠用量吐槽出圈，官方确认往往滞后；以及"能力方向"的猜测（3D 与游戏更强，前端一般，速度变慢）本身就是一个模型定位的信号，但只是个人印象。
时效与核验：24—48 小时。均为匿名竞技场测试的个人印象，Google 未官方确认模型存在或命名，两条都不能写成发布消息；"慢"与"前端一般"是单人测试，无条件与样本说明。先观察。
覆盖缺口：关注名单中的 sama、ylecun、rasbt 三组在本窗口检索为 0 条，未单独补查，本期这三条线上的英文讨论可能缺失。