Claude发现libheif漏洞并打通真实RCE

三个人用 Claude 审计图片解码链路，先找到 libheif 的堆越界读写，再串上 SSO 配置问题；更扎眼的是，旧模型没打通的利用链，升级后几小时内就跑通了。另一边，AI 写出的按钮在本地漂漂亮亮，上线后却因为一个加载动画产生布局偏移。能力涨得很快，工程欠账也来得更快。今天聊六条线，从供应链安全、前端防御式代码，一直讲到 Agent 测试、预览环境、上下文和推理成本。

一、AI 代码审计已经能挖真实漏洞，团队该怎么接住

先说结论，Claude 发现 libheif 漏洞这件事，真正值得盯的不是「AI 会不会取代安全研究员」，而是模型已经能参与完整的漏洞研究链路。

Hacktron AI 团队让 Claude 分析 Discourse Docker 镜像和已安装的 libheif，找到了未被下游回补的内存破坏问题。HEIC 文件会从 Discourse 进入 ImageMagick，再交给 libheif 解码，这条路径并不冷门，iPhone 截图就会经过它。上游修复早已存在，但没有被标记为安全问题，也没有 CVE，下游发行版自然缺少明确的升级信号。libheif HEIC 供应链研究里最刺眼的细节，是 Opus 4.8 生成的利用只能在关闭 ASLR 时工作，而新模型在数小时内推进到真实配置下的 RCE。

模型升级不只会提高代码补全质量，也可能直接改变漏洞是否可利用。

但这事不能读成「给 Agent 一个仓库，它就能自动交安全报告」。研究团队提供了目标范围、运行环境、验证基础设施和人工判断。模型负责扩大搜索速度，并没有替团队承担授权边界和结论责任。

同一天另一个信号来自 Meta Muse。一个未文档化设置允许本地代码把转录请求重定向到攻击者端点，进一步借用 Agent 已有权限拍照、写文件。Meta 已经发布补丁，并强调攻击需要本地代码先在用户账户下运行，因此它不是远程接管。Meta Muse 零日漏洞提醒我们的，是 Agent 的权限组合会放大一个看起来普通的本地配置缺陷。云端转录、可被其他应用控制的隐藏设置、长期登录态，单看每一项似乎都能解释，连起来就危险了。

回到前端和全栈团队，图片上传、文档预览、音视频转码通常都包在库后面，业务代码根本看不到真实解析链。只扫 package.json 还不够，容器里的系统包、ImageMagick 委托的解码器、网关后的 SSO 配置都得进资产清单。

你要是也在接文件上传，今天可以挑 HEIC、AVIF、SVG 和 PDF 四条链路，从入口一直追到最终解析库，核对实际版本、进程权限和补丁来源。再拿一个非生产镜像交给代码 Agent 做只读审计，看它能否指出调用链和缺失补丁。先评估发现率，别一上来开放生产权限。

二、AI 写的 CSS 为什么本地正常，上线就开始抖

大概率你也遇到过。让 AI 编程助手生成一个卡片、弹窗或者表单，它给出的 TypeScript 和 Tailwind 很整齐，示例数据也正常。换成长用户名、小屏设备和加载状态，问题才一个个冒出来。

AI 生成 CSS 的五类生产问题提到一个很典型的按钮。正常状态显示 Save Changes，加载状态换成 16px 的 Spinner，按钮宽度立刻收缩，旁边的控件也跟着移动。模型写对了状态切换，却没守住视觉尺寸。

下面这段不是为了炫 Tailwind，而是把按钮宽度从内容变化里解耦出来。

function SaveButton({ isLoading, onClick }) {
  return (
    <button
      disabled={isLoading}
      onClick={onClick}
      className="relative min-w-32 px-4 py-2 rounded-md bg-blue-600 text-white"
    >
      <span className={isLoading ? "invisible" : "visible"}>
        Save Changes
      </span>

      {isLoading && (
        <span className="absolute inset-0 grid place-items-center">
          <Spinner className="size-4 animate-spin" />
        </span>
      )}
    </button>
  );
}

最容易翻车的是 invisible，换成条件删除后，原始文字不再占位，布局抖动又回来了。

这里有个坑。把这些问题全归咎于模型也不公平，人写组件时一样会拿假数据验证。AI 只是把产出速度提上去了，导致防御式 CSS、异常数据和无障碍检查更容易被跳过。长文本需要 min-w-0、截断或换行策略，禁用按钮需要考虑 tooltip 的触发节点，小屏不能只靠桌面断点往下压。

Cloudflare 推出的 Worker Previews正好补上另一半。每个 Git 分支可以拥有隔离的代码、配置、URL、状态和可观测性，Durable Objects 与 Containers 也能按 Preview 隔离。Agent 改完 UI 或接口，不必只靠本地截图宣称「完成」，它可以部署到接近生产的环境，再由浏览器测试真实行为。

生成代码只是半程，能在类生产环境里复现边界条件才算交付。

当然，Worker Previews 适合 Cloudflare 技术栈，不是所有团队都该迁过去。要看的不是产品名字，而是每个分支是否有稳定 URL、隔离状态、接近生产的身份认证，以及可以回查的错误和调用链。

今天就能做一个很小的测试。选一个 AI 生成过的组件，喂入 80 个字符的用户名、慢接口、空数据和 320px 视口，录下布局偏移。再给 PR 建一个独立预览地址，看看问题能不能在合并前被看见。

三、Agent 的测试都绿了，为什么我还是不敢合并

我一开始也是这么想的，只要给 Agent 足够多的单元测试，它改代码就会更可靠。问题是，如果 Agent 同时能改实现、测试、fixture 和 skip 配置，绿色 CI 只能证明它写出了一套自洽叙事。

评估 Agent 补丁前先清点测试面给了一个很实用的方向。不要只看退出码，还要比较测试节点、断言数量、属性测试预算、fixture 内容和跳过项。评分用的 witness pack 应放在 Agent 无法改写的位置，否则它可以通过删除失败节点、缩小样本数或清空 fixture 来「修复」问题。

Python AI Agent 上线检查则把问题往运行时推进了一步。Agent 在生产里常见的失败不是函数直接抛错，而是模型把 JSON 变成 Markdown、工具成功返回垃圾数据，或者多步推理在后半程漂移。精确字符串断言很脆，应该检查可解析性、必需字段、敏感信息和任务属性。

虽然原文用的是 Python，落到前端服务一样可以用 JavaScript 做行为检查。下面这段验证的是返回结构，不是某一句固定回答。

function validateAgentResult(raw) {
  let data;

  try {
    data = JSON.parse(raw);
  } catch {
    return { ok: false, reason: "response_is_not_json" };
  }

  const required = ["answer", "sources", "confidence"];
  const missing = required.filter((key) => !(key in data));

  if (missing.length) {
    return { ok: false, reason: "missing_fields", missing };
  }

  if (!Array.isArray(data.sources) || data.sources.length === 0) {
    return { ok: false, reason: "sources_are_empty" };
  }

  return { ok: true, data };
}

最容易漏的是只校验 JSON 可解析，却不限制字段和数据类型，结果垃圾数据照样一路进入业务系统。

顺着上面聊，输入输出护栏也该放进测试面。LLM Guardrails 实战建议在调用模型前检查提示词注入、异常编码和越权工具请求，调用后检查密钥、内部指令和格式。规则匹配能挡住一部分明显攻击，但别把几个正则当成完整防线，改写、分词和多轮上下文都可能绕过去。

要我选，我会从最近 20 个真实任务里抽出一组固定样本，另存基线测试节点、断言数量和 fixture 哈希，再让 Agent 修改代码。评分时既跑 PR 内测试，也跑它碰不到的验证集。这样至少能分清「修好了」和「把报警器拆了」。

四、四个 Agent 同时写代码，为什么状态文件比模型更重要

一个 Agent 像同事，四个 Agent 更像并发系统。谁在做什么、读到了哪个版本、下一步交给谁，都会变成一致性问题。

四 Agent 并行实践把任务分成两条 research lane 和两条 implementation lane。研究通道只读代码并产出结论，实现通道一次只做一个任务。每条通道由单独写入者维护状态文件，编排层跨通道读取，避免多个 Agent 同时改共享计划。

这个设计看起来朴素，却解决了两个硬问题。研究过程可能消耗十几万 token，把所有探索记录塞给实现 Agent，会把有效需求埋进噪声；多个实现分支同时推进，又会把节省下来的时间还给合并冲突。原文里的经验是两个实现通道通常还能干净合并，三个开始频繁付出冲突成本。这个数量来自作者自己的项目，不是所有仓库的固定答案。

状态记录不用写成小说，保持机器可读就够了。

export const laneState = {
  lane: "impl-1",
  task: "add rate limiting to login route",
  branch: "feat/rate-limit",
  done: [
    "middleware scaffold",
    "429 response contract tests"
  ],
  inFlight: "wire redis-backed counter",
  blockedBy: null,
  next: "run integration test against preview",
  updatedAtCommit: "a13f9c2" // 用提交定位状态，别写模糊的「最新版」
};

最容易翻车的是 updatedAtCommit 缺失。状态文件写得再清楚，如果不知道它对应哪次提交，接手者仍可能在错误版本上继续。

说实话，多 Agent 的麻烦通常不是模型不够聪明，而是共享写入面太多。计划、依赖文件、数据库迁移和公共类型定义，任何一个都能成为冲突热点。AI 规格驱动开发反思又从另一侧给了提醒。作者为 Agent 搭了一整套分析师、架构师、产品经理和开发者流程，四周后积累了 1,782 个文件、约 16MB 流程内容，却没有产品代码。规划太少会让 PR 变成人质谈判，规划太多也会把交付挤没。

所以状态文件应该服务于交接，而不是复制一家公司。今天可以把一个小需求拆成只读研究和单分支实现，让两个 Agent 分开处理，只交接任务边界、相关文件、验收条件和提交号。记录协调耗时与冲突次数，跑完再决定要不要增加通道。

五、AI 编程两小时后变笨，到底该不该压缩上下文

长会话里最难察觉的不是 token 变多，而是模型开始推翻自己一小时前做的决定。你继续补充说明，它继续道歉和修补，窗口里同时留下错误版本、纠正意见和新实现，后续每一步都要从这堆历史里找主线。

vibe coding 会话质量崩塌分析把这种现象归到上下文管理。文中提到的 60% 是具体社区经验，不是一个跨模型通用的故障阈值。不同模型、工具回传量和仓库规模都会改变拐点，所以别设置成「到 60% 自动清空」这种机械规则。

Claude Code 长任务压缩经验给出的思路更稳。不要在「经常压缩」和「永不压缩」之间站队，而是在任务边界判断下一步还需要哪些原始细节。上下文占用、累计 token 用量和订阅额度也不是同一个指标，100 万上下文不代表可以免费重复处理 100 万 token。

该保存的是决定和证据，不是每一轮争论。

计划写进仓库，再开一个干净会话执行，通常比让同一个会话一路从调查撑到实现更清楚。不过这里也有边界。一个两小时内能完成的小修复，强行拆成研究、评审、实现、复盘四个会话，交接成本可能比上下文污染还高。前面那篇规格驱动开发的反例已经说明，流程本身也会吞掉产出。

还有个很现实的跨设备问题。用 Git 同步 Claude Code 和 Codex 会话尝试把本地会话放进私有仓库，再通过路径改写恢复。它解决了会话困在单台机器上的麻烦，也暴露出转录文件会携带工作目录、分支和工具版本。我的读法是，这个方案适合研究，不适合直接把所有会话自动推到远端。日志里可能有源代码、密钥、客户数据和工具返回值，至少得先做字段审计与加密。

今天真要判断何时开新会话，可以挑一个中等任务，在研究结束时写一页短计划，只保留目标、相关文件、已排除方案、验收命令和当前提交。新会话只读这份计划开始实现，再比较返工轮数与 token 用量，别只凭「感觉更聪明了」。

六、模型越来越便宜，为什么账单还是降不下来

便宜模型当然重要，但生产成本通常不是模型单价乘一次请求那么简单。一个用户动作可能触发检索、重排、工具调用、重试和 Agent 循环，真正烧钱的是调用结构。

生产环境降低 LLM 成本的七种方法把模型路由、上下文压缩、结果缓存和 RAG 优化放在一起看。简单分类与抽取走小模型，复杂推理再上大模型；检索质量差时不要直接把 top-k 加到 50，而是先做元数据过滤、重排和上下文压缩。这个思路比「统一换成最便宜模型」可靠，因为质量、延迟和重试率会反过来吃掉单价优势。

缓存也没想象中省心。Prompt 缓存失效分析指出，缓存依赖稳定前缀，而不是语义上「看起来一样」。时间戳、trace ID、JSON 键顺序、工具定义顺序和动态策略，只要被插到前缀前面，就可能造成缓存未命中。界面上看到的 Prompt 没变化，实际 payload 可能每次都不同。

这里可以给请求做一个稳定前缀，把动态信息放到末端。

function buildAgentRequest({ task, traceId, now }) {
  const stableTools = [...TOOLS].sort((a, b) =>
    a.name.localeCompare(b.name)
  );

  return {
    system: STATIC_SYSTEM_PROMPT,
    tools: stableTools, // 顺序稳定，避免同一组工具产生不同前缀
    messages: [
      { role: "user", content: task },
      {
        role: "developer",
        content: JSON.stringify({ traceId, now })
      }
    ]
  };
}

最容易翻车的是中间件又把 traceId 塞回系统指令顶部，那会把前面的稳定设计全部抵消。

模型侧也有几个诱人的数字。NVIDIA 的 SoL-Pi在 51 个 EdgeBench 任务上报告 token 流量降低 44.7% 至 49.0%，API 成本下降约 33%，并保持接近原版 Pi 的得分。这个结果针对特定 harness、模型和任务集，不能直接换算成你们仓库能省三分之一，不过它至少证明优化工具回传、上下文和动作融合，可能比单纯换模型更有效。

小米发布的 MiMo-V2.6-Pro给出了每百万 token 输入 3 元、输出 6 元的 Pro 定价，并宣称科研任务周期从约一个月缩短到 2 至 3 天。这个案例来自特定材料研究流程，还有专家与计算工具参与，不能顺手扩写成所有科研都能提速 10 倍。另一个「300 万美元预训练成本登顶开源权重榜」的说法来自二手摘要，缺少完整训练口径和榜单条件，我对这个数持保留意见。

那个「5 美元每月运行 Qwen2.5 72B 和 H100」的部署方案，我更不买账。Qwen2.5 72B 部署文章同时声称 H100、固定低月费和 500 多并发请求，但摘录里没有足够的计费条件与压测口径。72B 的 4-bit 权重、KV Cache 和并发显存也不能只用「最低 32GB」一句带过。这条可以当部署路线参考，别拿它做预算依据。

要评估 AI 办公提效和 AI 编程成本，今天可以导出 50 次真实请求，按模型调用数、输入输出 token、缓存命中、重试次数和最终验收结果分组。先修最贵的调用链，再拿小模型或开源模型跑同一批任务。价格低不低，得和验收通过率一起看。

总结

今天已经能确认的事实很具体。AI 参与发现了真实的图片解码漏洞，Meta 修复了 Muse 的本地权限问题；Cloudflare 给分支提供了隔离 Preview；多 Agent、长上下文、Prompt 缓存和 Agent 测试都有了可落地的工程方法。它们不再只是模型发布会里的能力描述。

我的判断是，接下来团队之间拉开差距的，不是谁先把最强模型接进 IDE，而是谁把权限、预览、测试基线、状态交接和成本观测接在模型周围。程序员真正需要补的，是一套能证明 Agent 没乱改、没漏测、没越权的交付链。

还没被证明的部分也不少。模型升级对漏洞利用能力能否稳定复现，SoL-Pi 的节省幅度能否迁移到业务仓库，MiMo 的科研表现能否覆盖普通研发，以及那些夸张的低价自托管方案是否算清了 GPU、存储和并发成本，都需要独立测试。

这期 AI 热点最值得带走的一句话很短。

别只测模型会不会写，开始测它写完以后，系统还剩多少可信度。

参考

一、AI 代码审计已经能挖真实漏洞，团队该怎么接住

先说结论，Claude 发现 libheif 漏洞这件事，真正值得盯的不是「AI 会不会取代安全研究员」，而是模型已经能参与完整的漏洞研究链路。

模型升级不只会提高代码补全质量，也可能直接改变漏洞是否可利用。

二、AI 写的 CSS 为什么本地正常，上线就开始抖

下面这段不是为了炫 Tailwind，而是把按钮宽度从内容变化里解耦出来。

function SaveButton({ isLoading, onClick }) {
  return (
    <button
      disabled={isLoading}
      onClick={onClick}
      className="relative min-w-32 px-4 py-2 rounded-md bg-blue-600 text-white"
    >
      <span className={isLoading ? "invisible" : "visible"}>
        Save Changes
      </span>

      {isLoading && (
        <span className="absolute inset-0 grid place-items-center">
          <Spinner className="size-4 animate-spin" />
        </span>
      )}
    </button>
  );
}

最容易翻车的是 invisible，换成条件删除后，原始文字不再占位，布局抖动又回来了。

生成代码只是半程，能在类生产环境里复现边界条件才算交付。

三、Agent 的测试都绿了，为什么我还是不敢合并

虽然原文用的是 Python，落到前端服务一样可以用 JavaScript 做行为检查。下面这段验证的是返回结构，不是某一句固定回答。

function validateAgentResult(raw) {
  let data;

  try {
    data = JSON.parse(raw);
  } catch {
    return { ok: false, reason: "response_is_not_json" };
  }

  const required = ["answer", "sources", "confidence"];
  const missing = required.filter((key) => !(key in data));

  if (missing.length) {
    return { ok: false, reason: "missing_fields", missing };
  }

  if (!Array.isArray(data.sources) || data.sources.length === 0) {
    return { ok: false, reason: "sources_are_empty" };
  }

  return { ok: true, data };
}

最容易漏的是只校验 JSON 可解析，却不限制字段和数据类型，结果垃圾数据照样一路进入业务系统。

四、四个 Agent 同时写代码，为什么状态文件比模型更重要

一个 Agent 像同事，四个 Agent 更像并发系统。谁在做什么、读到了哪个版本、下一步交给谁，都会变成一致性问题。

状态记录不用写成小说，保持机器可读就够了。

export const laneState = {
  lane: "impl-1",
  task: "add rate limiting to login route",
  branch: "feat/rate-limit",
  done: [
    "middleware scaffold",
    "429 response contract tests"
  ],
  inFlight: "wire redis-backed counter",
  blockedBy: null,
  next: "run integration test against preview",
  updatedAtCommit: "a13f9c2" // 用提交定位状态，别写模糊的「最新版」
};

最容易翻车的是 updatedAtCommit 缺失。状态文件写得再清楚，如果不知道它对应哪次提交，接手者仍可能在错误版本上继续。

五、AI 编程两小时后变笨，到底该不该压缩上下文

该保存的是决定和证据，不是每一轮争论。

六、模型越来越便宜，为什么账单还是降不下来

这里可以给请求做一个稳定前缀，把动态信息放到末端。

function buildAgentRequest({ task, traceId, now }) {
  const stableTools = [...TOOLS].sort((a, b) =>
    a.name.localeCompare(b.name)
  );

  return {
    system: STATIC_SYSTEM_PROMPT,
    tools: stableTools, // 顺序稳定，避免同一组工具产生不同前缀
    messages: [
      { role: "user", content: task },
      {
        role: "developer",
        content: JSON.stringify({ traceId, now })
      }
    ]
  };
}

最容易翻车的是中间件又把 traceId 塞回系统指令顶部，那会把前面的稳定设计全部抵消。

总结

这期 AI 热点最值得带走的一句话很短。

别只测模型会不会写，开始测它写完以后，系统还剩多少可信度。

AI雷达日报

今日看点

一、AI 代码审计已经能挖真实漏洞，团队该怎么接住

二、AI 写的 CSS 为什么本地正常，上线就开始抖

三、Agent 的测试都绿了，为什么我还是不敢合并

四、四个 Agent 同时写代码，为什么状态文件比模型更重要

五、AI 编程两小时后变笨，到底该不该压缩上下文

六、模型越来越便宜，为什么账单还是降不下来

总结

参考

AI雷达日报

今日看点

一、AI 代码审计已经能挖真实漏洞，团队该怎么接住

二、AI 写的 CSS 为什么本地正常，上线就开始抖

三、Agent 的测试都绿了，为什么我还是不敢合并

四、四个 Agent 同时写代码，为什么状态文件比模型更重要

五、AI 编程两小时后变笨，到底该不该压缩上下文

六、模型越来越便宜，为什么账单还是降不下来

总结

参考