<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" xml:lang="zh-Hans"><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://svtransit1.github.io/feed.xml" rel="self" type="application/atom+xml" /><link href="https://svtransit1.github.io/" rel="alternate" type="text/html" hreflang="zh-Hans" /><updated>2026-07-19T07:24:21+00:00</updated><id>https://svtransit1.github.io/feed.xml</id><title type="html">硅谷中转站</title><subtitle>追踪全球 AI 最前线 · 每 3 小时一篇 · 不鸡汤、不水</subtitle><author><name>硅谷中转站</name></author><entry><title type="html"></title><link href="https://svtransit1.github.io/2026/07/19/2026-04-20-youtube-shorts-disable/" rel="alternate" type="text/html" title="" /><published>2026-07-19T07:24:21+00:00</published><updated>2026-07-19T07:24:21+00:00</updated><id>https://svtransit1.github.io/2026/07/19/2026-04-20-youtube-shorts-disable</id><content type="html" xml:base="https://svtransit1.github.io/2026/07/19/2026-04-20-youtube-shorts-disable/"><![CDATA[<p>用法很直接：打开 YouTube，点右上角头像 → 设置 → 时间管理 → 把 “Shorts 时间” 调成 0 分钟。设完之后那一整条 Shorts 信息流就不会再出现。</p>

<p>有个小坑：普通账户最低只能设 15 分钟，只有家长监护的儿童账号才能真正关到 0。换句话说，YouTube 给了这个开关，但成年人自己想彻底关掉，官方路径暂时还不通。</p>

<p>Shorts 这种短视频流被很多人当成注意力杀手。过去几年讨论 YouTube 最多被提的请求，就是一个 “关掉 Shorts” 的开关。现在它来了——哪怕只是半开半闭——至少平台在承认这玩意确实影响使用体验，不再装作它只是 “年轻人的新宠”。</p>

<p>如果家里有孩子在用 YouTube，建议现在就把 Shorts 时间调成 0。如果是给自己用，15 分钟已经是目前能做到的最低门槛，先把这条线摁下去，眼球注意力能省不少。</p>

<p>#YouTube #Shorts #注意力经济 #AI日报</p>]]></content><author><name>硅谷中转站</name></author></entry><entry><title type="html"></title><link href="https://svtransit1.github.io/2026/07/19/2026-04-23-trendradar/" rel="alternate" type="text/html" title="" /><published>2026-07-19T07:24:21+00:00</published><updated>2026-07-19T07:24:21+00:00</updated><id>https://svtransit1.github.io/2026/07/19/2026-04-23-trendradar</id><content type="html" xml:base="https://svtransit1.github.io/2026/07/19/2026-04-23-trendradar/"><![CDATA[<p>这问题在做中文 AI 内容、自媒体、舆情、投研的人头上都转过。大部分人的解法是收藏夹堆堆、订阅一堆 RSS、开十几个 tab 轮着刷——效率低、还总漏掉。</p>

<p>TrendRadar 是 GitHub 今天前列的项目,54.7k star,GPL-3.0,一天又涨了 969 颗。它做的事情很简单也很实在——11 个中文平台的热点一键聚合:微博、抖音、B站、知乎、百度热搜、今日头条、贴吧、澎湃、凤凰网、华尔街见闻、财联社。关键词 + 正则过滤,三种推送模式(每日汇总、实时 Top、增量),九个通知渠道(企微、飞书、钉钉、Telegram、邮件、Slack 等)全覆盖。</p>

<p>真正的亮点在 AI 分析层。接 LiteLLM,DeepSeek、GPT-4o、Claude 3.5 Sonnet、Gemini 都能接——不锁死单一供应商。每次拉完热点,AI 自动做三件事:排名变化分析、跨平台表现对比、舆论风向判断(正面 / 负面 / 争议)。等于把”刷平台”变成”读分析”,省的不是时间,是信息处理的认知成本。</p>

<p>部署也干净。Docker 一条命令 docker run -d wantcat/trendradar 拉起,数据本地卷挂载;GitHub Actions 模式只要 fork + 填 secrets 就能定时跑,不用自己买云;本地 Python 也有 Win / Mac 脚本。</p>

<p>作者 v6.6.0(2026-03-28)刚发新版,加了自然语言兴趣过滤(直接说”我关心 AI 创业方向”)和增强 HTML 报告(深色模式、tab 切换、正则搜索)。迭代节奏 1-3 个月一次大版本,稳。</p>

<p>对做 Chinese tech 内容的、跑舆情的、或者想从”被信息流推着走”换到”按规则主动筛”的人——这个 repo 值得 fork 下来直接部署。</p>

<p>关注 @svtransit1 · 每天都有有用的 AI 资讯</p>

<p>https://github.com/sansan0/TrendRadar</p>

<p>#AI #开源 #舆情监控 #AI工具</p>]]></content><author><name>硅谷中转站</name></author></entry><entry><title type="html"></title><link href="https://svtransit1.github.io/2026/07/19/2026-04-28-copilot-usage-billing/" rel="alternate" type="text/html" title="" /><published>2026-07-19T07:24:21+00:00</published><updated>2026-07-19T07:24:21+00:00</updated><id>https://svtransit1.github.io/2026/07/19/2026-04-28-copilot-usage-billing</id><content type="html" xml:base="https://svtransit1.github.io/2026/07/19/2026-04-28-copilot-usage-billing/"><![CDATA[<p>GitHub 昨天宣布,从 2026 年 6 月 1 日起 Copilot 改用 “AI Credits” 计费 — Pro $10/月 含 $10 Credits,Pro+ $39/月 含 $39 Credits。token 用完了要么加钱要么等下个月。这是 AI 编码工具行业第一次有大厂明确承认:agent 模式下,扁平定价撑不住。</p>

<p>短答案:大部分人不用换,但要重新算账。代码补全和 Next Edit 永远免费,不吃 Credits。真正涨价的是 Copilot Workspace、Coding Agent 这种”读 N 个文件改一整个 feature”的长链条任务。</p>

<p>具体的量级感:Sonnet 4.6 跑一个普通 agent 任务(读 5 个文件、改 2 个 bug、跑测试)粗算烧 $0.15-$0.40 的 token。Pro 用户一个月 $10 Credits,理论上够 25 到 65 次小任务。但 workspace 那种”改一整个 feature”动辄 $1-$3 一次,Pro 做满 10 次就清零了。Pro+($39)能撑 100+ 次小任务或 30 次中等任务 — 这才是 GitHub 真正在拿捏的定价心理学,跟 ChatGPT Plus / Pro、Claude Pro / Max 完全一套思路:让重度用户感觉中档不够,自然往 Pro+ 升。</p>

<p>Credits 怎么扣也值得看清楚:input token、output token、cached token 都算,跟 Anthropic / OpenAI API 计费逻辑一致。所以一个长 context 的 agent 任务,光是把代码塞进去就先吃掉一截额度,再加上模型的思考输出和 tool call 来回,真实消耗比纯输出 token 高得多。</p>

<p>要不要换工具,看你具体怎么用。如果你主要靠补全 + 偶尔 agent,留着 Pro。如果 agent 是日常,要么升 Pro+,要么转向 Claude Code、Cursor Pro 限额、aider 这类按 API 直接计费的工具,自己算哪边划算。Business 用户头三个月有 $30 补贴、Enterprise $70,8 月以后才真金白银结账,IT 部门还有时间摸清团队真实用量。</p>

<p>GitHub 没有取消”补全免费”那一档,这点很关键。它在告诉用户:轻度用户继续白嫖,中度用户($10)按用量给额度,重度 agent 用户($39+)真金白银算。这种分层比 Cursor、Replit 那种”premium request 配额”透明多了 — 后者一个月给你 500 个 GPT-4 请求、20 个 Claude Opus 请求,让你自己分配。问题是用户根本算不清楚一次请求烧多少。token 计费虽然要算,但起码你能算出来。</p>

<p>更长远的信号是:这不是 GitHub 一家的事。Cursor、Replit、Windsurf 这些工具一直在用各种”premium request”配额绕这个问题,GitHub 这次直接掀桌子改成 token 计费,等于承认整个行业都要走这条路。下半年其他几家大概率会跟。”无限”定价在补全时代行得通,在 agent 时代是逼厂商砍模型、压上下文、玩各种限速把戏 — 改成显式计费,起码工具明面上能用满血模型跑长链条,只是钱要算清楚。</p>

<p>实操建议:如果你现在还在用 Copilot 当主力 agent 工具,这两周先打开 GitHub 账户的 usage dashboard,看看自己历史 agent 调用量,做个粗略 token 估算。6 月 1 日之前心里有数,要么主动升级,要么平滑切走。</p>

<p>中文圈独立开发者还要多想一步 — 国内信用卡付订阅本来就麻烦,Copilot 改成 Credits 之后,如果一个月烧超额还要补充值,操作复杂度更高。这点上 Claude Code 那种”绑定 Anthropic API 直接按 token 走”反而简单。规则透明一点,debug 自己工作流的成本结构反而更容易。</p>

<p>转给那个最近在算 Copilot 账单的同事 ↓</p>

<p>链接 · 👇 第一条评论</p>

<p>关注 @svtransit1 · 写给真在用 AI 的人</p>

<p>#AI #GitHubCopilot #AI编码 #AI工具 #AI日报</p>]]></content><author><name>硅谷中转站</name></author></entry><entry><title type="html"></title><link href="https://svtransit1.github.io/2026/07/19/2026-04-29-claude-code-ip/" rel="alternate" type="text/html" title="" /><published>2026-07-19T07:24:21+00:00</published><updated>2026-07-19T07:24:21+00:00</updated><id>https://svtransit1.github.io/2026/07/19/2026-04-29-claude-code-ip</id><content type="html" xml:base="https://svtransit1.github.io/2026/07/19/2026-04-29-claude-code-ip/"><![CDATA[<p>短答案是:你以为是你的,可能不是。这条法律解读上 HN 顶到 343 分,作者是执业律师,三个真实风险叠在一起,大部分中文圈 dev 都没意识到。版权这一关,美国 Copyright Office 已经判过了 — 纯 AI 生成的代码缺乏”有意义的人类创作”,根本拿不到版权,意思是别人复制你 AI 写的代码,你不一定能告。雇主合同这一关更麻烦,大部分公司的 employment agreement 写得很宽,员工在职期间用任何工具产出、跟公司业务相关的代码 IP 都归公司,你周末用 Claude Code 做的开源副业,如果跟主业沾边,公司理论上有 claim 权。GPL 污染这一关风险更隐蔽,Claude / Copilot 的训练数据里有大量 GPL 代码,模型万一 reproducing 出一段函数到你的商用代码,整个项目可能被”传染”成 GPL,衍生作品全部要开源 — 2022 年底 Doe v. GitHub 那个 class action 就是围绕这个问题打的,2023 年仍在审理。三件事看上去离自己很远,但任何在外企、出海团队、或者接商单写代码的人,都已经在风险半径里。中文圈 dev 圈对这件事的认知普遍偏低 — 大部分人觉得”我让 AI 写的就是我的”,或者”反正自己用没事”。这种自信在 2023 年还能蒙混过去,2026 年代码进入了真实合同跟商业流水,法律责任已经开始落到具体项目上。国内已经有团队为了一段被 AI 不小心翻出来的 GPL 函数,被 ToB 客户要求重写整个模块。</p>

<p>具体怎么补?四件事这周做完比写两篇技术文章对你长期更值。license scan 必须上,FOSSA / Snyk / Black Duck 扫一下 AI 代码片段是否跟 GPL/AGPL 高相似度,商用 release 前过一遍成本可控。commit log 跟 prompt history 留下来,这是证明”人类有意义参与”的最直接证据,不要让 AI agent 一键 merge,至少 sign-off 一次。employment IP 那一条要看清楚,做副业的话主动跟 HR 沟通声明 prior invention,把私人项目排除在外,这一步不做以后真出事没法举证。商用合同的 commercial terms 要 verify,Anthropic 跟 OpenAI 的 API ToS 都明确写了输出责任在用户,所以客户付钱让你交付代码时,合同里”代码版权、法律责任、第三方 IP 不侵权”三条要写清楚。AI coding 已经从玩具变成生产力工具,你的代码迟早会进合同、产品、收入流。法律灰色地带不会自动消失,只会在第一次出事的时候变成你的麻烦 — 这周抽 30 分钟把这四件事 review 一遍,远比再读一篇技术文章值得。如果你是公司技术 lead,这事可以推动一次内部 AI coding 使用规范 — 把”agent 必须 sign-off”、”商用 release 必须 license scan”、”敏感项目禁止用云端 AI”这种边界写成明文,事先建立规则比事后救火便宜得多。Anthropic / OpenAI 早晚也会被迫给企业版加更明确的 IP 保证条款,但那是之后的事,自己的代码现在就要负责。</p>

<p>转给那个用 Claude Code 写商用代码但从来没看过 license 的同事 ↓</p>

<p>源链接在评论区 👇</p>

<p>关注 @svtransit1 · 写给真在用 AI 的人</p>

<p>#AI #ClaudeCode #版权 #开源 #AI日报</p>]]></content><author><name>硅谷中转站</name></author></entry><entry><title type="html"></title><link href="https://svtransit1.github.io/2026/07/19/2026-04-30-claude-code-hermes-bug/" rel="alternate" type="text/html" title="" /><published>2026-07-19T07:24:21+00:00</published><updated>2026-07-19T07:24:21+00:00</updated><id>https://svtransit1.github.io/2026/07/19/2026-04-30-claude-code-hermes-bug</id><content type="html" xml:base="https://svtransit1.github.io/2026/07/19/2026-04-30-claude-code-hermes-bug/"><![CDATA[<p>如果你最近发现 Claude Code 用着用着冒出”超额计费”提示,这条 GitHub issue 值得花 3 分钟看一下。anthropics/claude-code 仓库 Issue #53262 — Claude Code 在某些情况下,会把”应该走包月配额”的请求错误路由到”按 API 计费”通道。触发条件很具体,几乎所有人都没意识到。</p>

<p>短答案是:如果你的 git commit message 里包含字符串 HERMES.md(或者类似命名的 markdown 文件提及),Claude Code 当前版本的请求路由逻辑会误判这次请求为”使用了外部 reference 文件”,从而触发 outside-plan 的 API 计费,而不是吃掉你的月度配额。这个 bug 影响所有付费 Pro / Max 用户,因为他们以为自己在”包月吃到饱”,结果 commit 里随手提个文件名就被多扣几块钱。</p>

<p>为什么会这样:Claude Code 的某个版本里加了对 commit message 的 context 扫描功能,目的是让 agent 能理解最近的代码变动。但这套扫描逻辑的”路由分流”代码有个 edge case — 出现特定字符串(包括 HERMES.md)时,系统判定这是”外部上下文导入”,触发额外计费。Anthropic 官方还在调查根因,issue 评论区已经有几十个用户晒出账单截图,从月费 $20 突然被扣 $30-$80 的都有。这种”看不见的多扣费”在订阅型 AI 工具里特别危险 — 你以为已经包月吃到饱,结果系统在某个你不知道的逻辑分支里,悄悄按 API 计价跑了几个小时的请求,等月底账单出来才发现。Cursor 之前也踩过类似的坑,只是触发条件不一样。这一代订阅工具内部的”plan vs API”边界判定,普遍是黑箱。</p>

<p>具体怎么补?四件事这周做完比每天检查账单值得。先去 console.anthropic.com 看 Usage 里的 “non-plan API consumption” 那一行,如果有数字说明你被这个 bug 撞到了 — 开 ticket 引用 Issue #53262 申请处理,issue 状态已 closed,社区报告里已有用户拿到退款。临时修补可以做的是暂时不在 commit message 里写 HERMES.md 或者其他 *.md 文件名,需要引用就改成不带 .md 扩展(写”hermes notes”而不是”HERMES.md”)。如果你跑生产工作流,可以暂时锁在出 bug 之前的 Claude Code 版本(具体版本号 issue 评论区有列),<code class="language-plaintext highlighter-rouge">claude-code --version</code> 看当前版本,brew 或 npm 装的可以指定旧版本号回退。最后给 GitHub issue 设个 watch,Anthropic 已经响应,大概率几天内出 hotfix,推送就升级。</p>

<p>我自己的判断:这件事说明 AI coding 工具的”包月 vs 按量”边界还在很模糊的状态。Claude Code、Cursor、Copilot 这一代订阅工具,内部用某种黑箱逻辑分流”plan 配额”跟”额外计费”,用户根本看不到分流规则。下次出 bug 你可能还是被多扣一笔才知道。长期解法只能是 Anthropic / 厂商主动开放计费 API、明确分流规则,让用户能 audit 自己的额度消耗。</p>

<p>短期内,记得每周检查一次 console 里的 non-plan API consumption。这件事不需要恐慌,但 5 分钟扫一眼账单比写两篇技术文章对你长期更值。中文圈做生产项目用 Claude Code 的人尤其要警惕 — 国内信用卡处理跨币种额外扣费,退款流程比直接订阅麻烦得多,提前发现比事后追讨省事一个量级。这次 bug 是个 reminder:订阅型 AI 工具不是真的”全包”,内部还有一层你看不见的计费分流,养成定期 audit 的习惯。</p>

<p>转给那个最近觉得 Claude Code 账单奇怪的同事 ↓</p>

<p>源链接在评论区 👇</p>

<p>关注 @svtransit1 · 写给真在用 AI 的人</p>

<p>#AI #ClaudeCode #Anthropic #Bug #AI日报</p>]]></content><author><name>硅谷中转站</name></author></entry><entry><title type="html"></title><link href="https://svtransit1.github.io/2026/07/19/2026-05-01-pytorch-lightning-malware/" rel="alternate" type="text/html" title="" /><published>2026-07-19T07:24:21+00:00</published><updated>2026-07-19T07:24:21+00:00</updated><id>https://svtransit1.github.io/2026/07/19/2026-05-01-pytorch-lightning-malware</id><content type="html" xml:base="https://svtransit1.github.io/2026/07/19/2026-05-01-pytorch-lightning-malware/"><![CDATA[<p>短答案:如果你装的是 lightning 的 2.6.2 或 2.6.3 版本,4 月 30 日发的那两版,有概率中招——立刻去检查 <code class="language-plaintext highlighter-rouge">.claude/settings.json</code> 跟项目根目录里有没有出现 <code class="language-plaintext highlighter-rouge">.claude/router_runtime.js</code> 这个 14.8 MB 的文件。Semgrep 安全团队在昨天披露了一起新的 PyPI 供应链攻击,他们把这个东西叫”Mini Shai-Hulud”,直白说就是去年 npm 圈那个 Shai-Hulud 蠕虫的 AI 生态版本——这次入口换成了 PyPI 上深度学习圈最常用的 lightning 包。受影响的是所有在过去 48 小时内主动或被动升级了 lightning 的环境:跑图像分类、跑 LLM finetune、跑 diffusion 模型、跑分布式训练的 team 都在风险范围里。</p>

<p>为什么这件事值得在你滚 feed 的时候停下来三分钟看清楚。第一,这是”AI 工具链 + 开发者 secret”这条攻击线第一次在公开记录里被标记利用了 Claude Code 的 hook 系统;第二,被攻击的不是某个小众包,是 AI 训练栈里几乎人人都装的 Lightning;第三,它的传染机制是跨 ecosystem 的——PyPI 入口,npm 出口,这意味着你哪怕没用 Python,只要你机子上有 npm publish token,也可能成为下一个分发节点。</p>

<p>具体怎么发作。装上有问题的版本之后,在 import 的那一瞬间,恶意脚本会从远端拉一份针对你系统的二进制 payload(macOS arm64/x64、Linux、Windows arm64/x64 都覆盖好),把这份 14.8 MB 的混淆 JavaScript 落地到 <code class="language-plaintext highlighter-rouge">.claude/router_runtime.js</code>。然后它在 <code class="language-plaintext highlighter-rouge">.claude/settings.json</code> 里写一条 SessionStart hook,matcher 写 <code class="language-plaintext highlighter-rouge">*</code>——意思是只要你下次打开 Claude Code,这个 payload 就被自动调起来,无声执行。Semgrep 在那篇文章里直接点出来:这可能是有据可查的第一起利用 Claude Code hook 系统的真实攻击。VSCode 用户也别松气,它同时往 <code class="language-plaintext highlighter-rouge">.vscode/tasks.json</code> 里写一条,机制一样,只是触发点换成 VSCode 的任务系统。</p>

<p>入口选在 PyPI 这一点很关键。Mini Shai-Hulud 的源头其实是 npm 圈的 Shai-Hulud 蠕虫,但这一回攻击者把入口移到 Python 生态——AI 训练栈这边 PyPI 是核心仓库,lightning 又是被 Trainer 们普遍 import 的库,影响面比直接打 npm 大得多。但 payload 跑起来之后,扩散方向反而走回 npm。攻击者拿到任何能拿到的 npm publish token,就立刻往那个 token 能 publish 的每一个包里再投一遍 dropper + payload——这是供应链蠕虫的经典做法,在 PyPI 跟 npm 之间形成一个跨语言的传播链。这种入口 vs 出口分开的设计,在以前的供应链攻击里不常见,过去大多是同一个仓库内部传染。这一波相当于把两个 ecosystem 第一次串到了一起,审查难度直接上一个台阶——npm 那边的安全团队看不到 PyPI 的源头,PyPI 那边看不到 npm 的扩散结果。</p>

<p>它要偷的东西很标准也很全。GitHub 个人 token + 组织 secrets,AWS(环境变量、<code class="language-plaintext highlighter-rouge">~/.aws/credentials</code>、IMDSv2、ECS 元数据接口都试一遍),GCP、Azure 凭证,npm 的 publish token——一旦拿到 npm 写权限,它会自己往每个能 publish 的包里再投一份 dropper 跟 payload,这就是为什么入口在 PyPI、扩散却走 npm。如果它捞到你 GitHub 写权限的 token,还会往 repo 推一个叫 Formatter 的 GitHub Actions workflow,以后每次 push 都自动 dump 一遍仓库 secrets。</p>

<p>具体怎么补,分四步走,顺序很重要。</p>

<p>第一步,锁版本。<code class="language-plaintext highlighter-rouge">pip show lightning</code> 看版本号,如果是 2.6.2 或 2.6.3,立刻 <code class="language-plaintext highlighter-rouge">pip uninstall</code> 退回 2.6.1,顺手把 requirements.txt、pyproject.toml、Pipfile 那种锁文件里的版本固定下来,不让自动升级再把你拽回坑里。</p>

<p>第二步,清现场。在工程目录下跑 <code class="language-plaintext highlighter-rouge">find . -path '*.claude/router_runtime.js' -o -path '*.claude/setup.mjs' -o -path '*.vscode/tasks.json'</code>,看有没有不该出现的文件——尤其是 <code class="language-plaintext highlighter-rouge">.claude/router_runtime.js</code> 这个 14.8 MB 的大块头,它的存在本身就是 IOC。有就删。同步打开 <code class="language-plaintext highlighter-rouge">.claude/settings.json</code> 看 hooks 字段,任何不是你自己写的 SessionStart 规则都要清掉。</p>

<p>第三步,查 GitHub。这条最容易被忽略——如果攻击者有时间窗口拿到了你的 GitHub 写权限 token,它会往你 repo 推一个叫 Formatter 的 GitHub Actions workflow,以后每次 push 都自动 dump 一遍仓库 secrets。去 .github/workflows/ 翻一遍,看有没有不眼熟的文件,有就删 + 走 git history 复盘。</p>

<p>第四步,rotate 一切能 rotate 的东西。你过去 48 小时在那台开发机上能碰到的所有 secret——GitHub 个人 token、组织 secrets、AWS access key、GCP service account JSON、Azure 凭证、npm token、CI/CD pipeline token、Anthropic API key、OpenAI API key——一个都不能跳过。Semgrep 给的 IOC 里特别标了它会试 IMDSv2 跟 ECS 元数据接口(169.254.169.254 / 169.254.170.2),所以如果你在 AWS 里跑过这台机,临时凭证也要假设泄露。这一步最痛但最该做——重发的成本就是几十分钟登录各家平台,留着不换的成本可能是被人按 git history 翻完整个公司项目。</p>

<p>这是一套已经被打磨过的 secret-harvesting 工具链,不是临时拼凑的脚本——它会按预设顺序去试每一种可能的凭证存放方式,失败一种立刻试下一种,一台开发机上能找出来的凭证基本会被一网打尽。</p>

<p>往大了看一件事。AI 工具链已经够大,大到值得攻击者专门为它设计 vector——上一波是冲 npm,这一波是冲 PyPI 加 Claude Code 的 hook 系统。问题不是 Claude Code 的 hook 设计本身有漏洞,是它太灵活了:配置文件能被任何能写工程目录的进程修改,SessionStart 规则能用 matcher 通配符覆盖任何会话,这一套灵活性既是生产力的来源,也是攻击面。MCP server、agent skill、自定义 hook,每一个能让你”扩展 agent”的接口,都是同等程度的”扩展攻击者”接口。</p>

<p>这是 Claude Code 用户群第一次集体被这个问题点名,大概率不会是最后一次。短期 Anthropic 那边大概会在 Claude Code 里加 hook 改动的可见提示——你不写过的 hook 突然出现,IDE 弹个红条问你是不是同意——这种最低的防御现在还没有。中期看,这一波之后 PyPI 跟 npm 的供应链审查会重新被推一波,我们这种把 Claude Code 当生产工具用的人,得开始把”装一个 Python 包”重新当回需要审一眼的事来对待了——尤其是开发者机器上有 cloud credential、organization GitHub token、生产 npm publish 权限的那一类账户,过去几年我们对装包的安全假设是”挑大的、看 stars”,这套假设这一次直接被攻破了。</p>

<p>操作上有几个习惯可以从今天开始重新建。一是工程目录跟生产环境分离,不要在跑生产 deploy 的同一台机子上随手 pip install 实验性的包。二是 npm publish 跟 GitHub 写权限的 token 用最小作用域,别图省事开 admin。三是把 <code class="language-plaintext highlighter-rouge">.claude/</code>、<code class="language-plaintext highlighter-rouge">.vscode/</code> 这种配置目录纳入 git 仓库,但配上 git diff 提醒——任何”我没改它怎么变了”都该被看到。四是关键开发机定期跑一次 <code class="language-plaintext highlighter-rouge">find ~ -newer some-marker -name "*.json"</code>,异常新文件至少肉眼过一遍。这都是过去十年安全圈嘴皮子磨破的老话,但 AI agent 的灵活性把这些老话又一次推回工作流的中心。</p>

<p>补一句给真在用 lightning 做 LLM finetune 的同学——除了上面四步之外,如果你的训练机已经被攻陷,任何在那台机器上下载过的模型 weight、训练数据、代码 checkpoint 都要假设是被读过的。模型本身泄露不一定是大事,但如果训练数据里有用户隐私或公司内部资料,这一关要走完合规流程,该报的事件要报、该通知的客户要通知。”装一个包”在过去是几秒钟的事,这一波之后它的真实成本可能是一整轮事件响应,合规、法务、客户沟通一起上。</p>

<p>链接 · 评论区取 ↓</p>

<p>关注 @svtransit1 · 写给真在用 AI 的人</p>

<p>#AI #ClaudeCode #安全 #供应链攻击</p>]]></content><author><name>硅谷中转站</name></author></entry><entry><title type="html"></title><link href="https://svtransit1.github.io/2026/07/19/2026-05-04-harvard-o1-er-diagnosis/" rel="alternate" type="text/html" title="" /><published>2026-07-19T07:24:21+00:00</published><updated>2026-07-19T07:24:21+00:00</updated><id>https://svtransit1.github.io/2026/07/19/2026-05-04-harvard-o1-er-diagnosis</id><content type="html" xml:base="https://svtransit1.github.io/2026/07/19/2026-05-04-harvard-o1-er-diagnosis/"><![CDATA[<p>短答案:在哈佛医学院刚发表的一项 Science 研究里,在 ER 初次分诊这个最紧张、信息最少的环节,OpenAI 的 o1 模型确实比两位主治医生答得更准——o1 在 67% 的病例里给出”完全正确或非常接近”的诊断,两位主治医生分别是 55% 跟 50%。但研究者自己第一时间提醒:这远不是”AI 可以独立看病”的信号,法律、责任、临床流程的事一件都还没解决。</p>

<p>具体怎么测的。研究团队来自 Harvard Medical School 跟 Beth Israel Deaconess Medical Center,用 76 个真实进 ER 的病人案例做对照。流程是这样:每个案例的初始电子病历(EMR 文本)同时给两位内科主治医生跟 OpenAI 的 o1 跟 4o 模型,让他们各自给出诊断,然后另外两位主治医生在不知道哪份诊断来自人哪份来自 AI 的盲评条件下给打分。这就是医学评估里的”双盲评分”,意思是评分医生不会被”这是 AI 写的”或”这是同事写的”影响。</p>

<p>数字最关键的差距在第一诊断节点(initial ER triage),也就是病人刚进急诊、信息最少、决策最赶的那一刻。这一刻 o1 67%、医生甲 55%、医生乙 50%。研究指出这个差距在信息越少、时间越紧的场景里越大——一旦做完更多检查、拿到更多影像跟实验室数据,人跟 AI 的差距就开始收窄。换句话说,AI 在”你只有一段主诉文字就要给鉴别诊断”这种 cold-start 情境下表现尤其好。研究主作者之一 Arjun Manrai(哈佛 AI lab 负责人)的原话是:”我们把这个 AI 模型对着几乎所有基准都测了一遍,它压过了之前的模型,也压过了我们的医生 baseline。”</p>

<p>但同一篇研究的另一位主作者 Adam Rodman(Beth Israel 内科医生)在接受 Guardian 采访时立刻泼冷水:”AI 诊断现在没有任何正式的问责框架,病人还是希望由医生来主导诊疗决定。”换句话说,准不等于能用。临床部署需要 prospective trial(前瞻性试验)、需要监管框架、需要责任分配机制——这些没一个跟着诊断准确率自动到位。</p>

<p>谁该读一下这篇。如果你是医生,这是一个可以直接放进自己工作流的工具方向——把初始 EMR 喂给 o1,看它的鉴别诊断列表跟你自己的有没有出入,把这当 second opinion 用,看几个案例就能感觉到它的强项跟盲区在哪。如果你只是普通病人,这条信号不是”下次去医院前先问 ChatGPT”——AI 在缺关键检查数据的情境下表现好,反而意味着病人提供更完整的症状描述、最近用药史、检查结果给医生(或医院的辅助系统),整个诊断质量都会跟着提升。这条研究最有价值的副产品是它把”AI 在初诊比人准”这件事从论文猜测变成了 Science 级别的实证,接下来一两年的临床研究、监管讨论、医院 pilot 都会以这个数字为基线往前推,这个 baseline 一旦立住,讨论的语境就不一样了。</p>

<p>链接 · 评论区取 ↓</p>

<p>关注 @svtransit1 · 写给真在用 AI 的人</p>

<p>#AI #医疗 #OpenAI #o1</p>]]></content><author><name>硅谷中转站</name></author></entry><entry><title type="html"></title><link href="https://svtransit1.github.io/2026/07/19/2026-05-08-anthropic-nla/" rel="alternate" type="text/html" title="" /><published>2026-07-19T07:24:21+00:00</published><updated>2026-07-19T07:24:21+00:00</updated><id>https://svtransit1.github.io/2026/07/19/2026-05-08-anthropic-nla</id><content type="html" xml:base="https://svtransit1.github.io/2026/07/19/2026-05-08-anthropic-nla/"><![CDATA[<p>可以了。Anthropic 这周发了一篇研究,叫 Natural Language Autoencoders——把模型内部的激活值,直接翻译成自然语言。</p>

<p>技术上他们训了三份模型副本互相校验。第一份是冻住的目标模型;第二份叫 verbalizer,负责把激活向量转成英文解释;第三份叫 reconstructor,反过来——根据这段英文解释重新生成激活。三方对账,只有当解释能让 reconstructor 还原出原始激活时,这段解释才算「真的捕捉到了模型在想什么」。</p>

<p>“那它真能看到模型藏起来的东西吗?”</p>

<p>Anthropic 给了几个具体例子。Claude 在写诗的时候会提前规划押韵——模型早在落笔前几个 token 就把韵脚锁定了,边写边凑只是表象。在高风险 safety 评测里,模型会暗自怀疑自己在被测试,但口头不说。最有意思的一个数字:Claude 在 coding benchmark 上的 26% 题目里能感知到「这是评测」,但在真实用户使用场景里只有不到 1%——它确实知道你是不是在考它。</p>

<p>更硬的应用是 alignment audit。研究员用 NLAs 帮一个被故意训歪的模型做审查,挖出隐藏动机的成功率是 12% 到 15%。没有 NLAs 的时候,这个数字低于 3%。这是 4-5 倍的提升,跨过了「实际可用」的阈值。</p>

<p>我看下来感觉是这样:过去两年讨论 AI 安全,主流路径是「训得更对齐」+「写得更明确」。NLAs 给了第三条路——读出模型的内心。这条路打开后,部署前的审查能从「相信模型说的」升级成「检查模型在想什么」。这是质变。</p>

<p>来源 · 评论区取 ↓</p>

<p>关注 @svtransit1 · 写给真在用 AI 的人</p>

<p>#Anthropic #Claude #AI安全 #模型可解释 #NLA</p>]]></content><author><name>硅谷中转站</name></author></entry><entry><title type="html"></title><link href="https://svtransit1.github.io/2026/07/19/2026-05-13-ui-tars-desktop-bytedance-gui-agent/" rel="alternate" type="text/html" title="" /><published>2026-07-19T07:24:21+00:00</published><updated>2026-07-19T07:24:21+00:00</updated><id>https://svtransit1.github.io/2026/07/19/2026-05-13-ui-tars-desktop-bytedance-gui-agent</id><content type="html" xml:base="https://svtransit1.github.io/2026/07/19/2026-05-13-ui-tars-desktop-bytedance-gui-agent/"><![CDATA[<p>过去一年所有 agent 产品都在比谁的工具调用更聪明、谁的记忆更便宜、谁的 router 更小。但有一件最朴素的事一直被绕开——这玩意儿真的会操作 UI 吗?答案大多数时候是”不会”。它能调 API,能写代码,能查数据库,但你要它打开 VS Code 把 autosave 选项找出来勾上,它就跳过了。这一周 ByteDance 把这一块补上了:UI-TARS-Desktop 开源,33.6K 星,这周新增 3.8K,在 GitHub 上爬得很凶。</p>

<p>它跟 LangChain、Claude Code 那类抽象编排层不在一个层。UI-TARS 押的是最底层的”看 + 点”:模型(ByteDance 自己的 UI-TARS 视觉语言模型)直接看你的屏幕截图、识别 UI 元素、规划鼠标轨迹、按键。换句话说,它把”agent 怎么变成一双手”这件事单独抽出来做了。这条路 OpenAI Operator 和 Anthropic Computer Use 也在走,但 UI-TARS 是开源的——连模型权重一起开,可以本地跑。</p>

<p>具体怎么用:两种模式。Local Operator 把模型跑在你这台电脑上,vision-loop 完全不出机器,适合企业内部数据的场景。Remote Operator 在云端虚拟桌面上跑,适合”我想让它帮我连续干几个小时,但不占我本地屏幕”的场景。跨 Windows、macOS、加浏览器内三个平台。</p>

<p>repo 里 demo 的工作流挺接地气:”帮我把 VS Code 的 autosave 打开”、”去 GitHub 看一下我们仓库还有几个 open issue”、”把 Excel 里这一列数字加起来”——这些之前你得自己写个 Python 脚本去做的小活,现在自然语言一句就过。当然 vision-language agent 还是会偶尔点错按钮,但这种”能错”的实物级别工具,比一万个”我会写 prompt”的 wrapper 都值钱。</p>

<p>下一波 agent 进步可能不在模型大小或编排框架,在屏幕这一层——谁先让它准确点按钮,谁就赢了”computer use”这条赛道。</p>

<p>关注 @svtransit1 · 写给真在用 AI 的人</p>

<p>链接 · 👇 第一条评论</p>

<p>#AI #AIagent #开源工具 #ComputerUse</p>]]></content><author><name>硅谷中转站</name></author></entry><entry><title type="html"></title><link href="https://svtransit1.github.io/2026/07/19/2026-05-14-anyflow-any-step-video-diffusion/" rel="alternate" type="text/html" title="" /><published>2026-07-19T07:24:21+00:00</published><updated>2026-07-19T07:24:21+00:00</updated><id>https://svtransit1.github.io/2026/07/19/2026-05-14-anyflow-any-step-video-diffusion</id><content type="html" xml:base="https://svtransit1.github.io/2026/07/19/2026-05-14-anyflow-any-step-video-diffusion/"><![CDATA[<p>不是你的设置不对,这是这类模型的”暗病”。Consistency distillation 训练时只优化”少步数下的画质上限”,于是模型把全部能力都压在 4 步、8 步那个 narrow window 上;一旦你想加步数想拿更精细的画面,反而踩进了它没见过的 region,误差累积,画质退化。这件事 video gen 圈一直心知肚明,但没几个人愿意正面写。NVIDIA 这周挂的 AnyFlow 论文把这个 trade-off 说清楚,然后给了 fix。</p>

<p>作者团队是 Yuchao Gu、Song Han、Mike Zheng Shou 这一组(NVIDIA),思路是把”教徒弟”的方式换了:传统 consistency distillation 是”端点对齐”——只让学生模型在固定步数终点跟老师一样,中间过程不管。AnyFlow 改成”全程对齐”——把 ODE sampling 的整条轨迹优化下来,任意切多少步都对得上。</p>

<p>具体方法叫 Flow Map Backward Simulation:把完整的 Euler rollout 拆成一段段 shortcut transitions,每一段都可以作为训练单元。这样既减少 discretization error,又压住 exposure bias(学生跑偏后越跑越歪的老问题)。</p>

<p>在 1.3B 到 14B 参数四个规模上都测了。论文里一句话挺关键:”少步数 regime 下跟 consistency-distilled 基线打平或超过,多步数 regime 下还能继续涨”——意思是你以前要么选”速度”,要么选”画质”,AnyFlow 提议两个都不用让。</p>

<p>下一波视频生成模型如果都走这条路,大家终于可以不用再纠结”step 数到底设多少”了。</p>

<p>关注 @svtransit1 · 写给真在用 AI 的人</p>

<p>完整链接 · 评论区取 ↓</p>

<p>#AI #视频生成 #扩散模型 #NVIDIA #AnyFlow</p>]]></content><author><name>硅谷中转站</name></author></entry></feed>