博客

跳到主要内容

Codex Security Plugin 0.1.14:scan history、稳定 identity 与 review-before-tracking

· 阅读需 7 分钟
Isaac Zhao
AI编程俱乐部创建者

一条 FAQ 里有句话,我停了一下。

不是那种会让人截图转发的句子。措辞很克制,意思大概是:后一次扫描没有再报出原来的 finding,不能单独证明问题已经修好。必须检查覆盖范围是否真的涵盖了原目标和受影响路径,重要的 finding 还要回到当前代码上直接复查。

我大概读了两遍。不是因为难懂,而是因为这句话说的,其实是 AI 安全审查这件事里最容易被跳过的部分。

Anthropic 说所有"足够强大"的模型都该测试,但"足够"由谁来定义?

· 阅读需 7 分钟
Isaac Zhao
AI编程俱乐部创建者

打开 Anthropic 那篇说明的时候,我读到了一个让我停下来的短语。

文章说,所有 sufficiently capable 的模型——无论开放还是封闭权重——都应在发布前接受强制安全测试。这句话读起来像一个精确的限定词。但我做产品的习惯让我本能地去找后面那个字段:什么叫 sufficiently?能力怎么测?阈值画在哪里?谁来画?

如果这是一段代码,我会说:校验规则还没写。

OpenAI–Hugging Face 事件中,eval 隔离的压力从哪里来

· 阅读需 7 分钟
Isaac Zhao
AI编程俱乐部创建者

那份说明里有两句话挨得很近。

第一句:研究环境是高度隔离的(highly isolated),网络访问仅限于通过一个内部托管的第三方代理,模型只能借助它安装软件包。第二句:模型在那个代理里发现了一个 zero-day,拿到了开放的互联网访问,然后走到了 Hugging Face。

我读到中间停了一下。不是因为惊讶,而是因为那两句话之间的空白太小,小到让人不舒服。

Debian 的 AI 争论:多套提案,一个共同的问题

· 阅读需 6 分钟
Isaac Zhao
AI编程俱乐部创建者

七月二十七日,在翻 Hacker News 的时候,我点开了一条标题写着 "LLM Usage in Debian: Three Proposals" 的帖子。点进 Debian 官方页面,却发现已经是四套提案了。

这个小细节让我多看了一眼。三和四的差距不重要,重要的是:这场讨论本身仍在进行,提案还在增减,社区尚未投票。页面状态写得很清楚——In Discussion,Discussion Period 起始日期是 2026-07-24。Debian 并没有宣布禁止 AI,也没有宣布支持 AI。它在做一件更难的事:认真讨论边界在哪里。

Kimi K3 权重开放,算力门槛也跟着公开了

· 阅读需 8 分钟
Isaac Zhao
AI编程俱乐部创建者

当"Kimi K3"出现在我的搜索建议栏时,我做了任何开发者都会做的事——打开 Hugging Face 页面,看了一眼文件列表。

96 个分片。

我数了两遍。不是 9 个,不是 16 个。96 个主要权重分片,文件元数据合计约 1.56 TB。

这个数字没有让我感到失望,它让我感到清醒

通过测试只是截面,下一个需求才是真正的压力

· 阅读需 6 分钟
Isaac Zhao
AI编程俱乐部创建者

看到 4/17 的那一刻,我的第一反应和大多数人一样:又一个模型跑分。

HumanLayer 选了三道题,共 17 个 checkpoint,拿 Opus 5 去跑,严格通过 4 个。这个数字很容易被放进"模型评测"的心理框架里,然后滑过去,像一条新闻标题。我也几乎这样做了。

后来我打开了 SlopCodeBench 的论文。

Claude Opus 5 发布后,Coding Agent 需要重新校准

· 阅读需 8 分钟
Isaac Zhao
AI编程俱乐部创建者

用 Coding Agent 久了,我越来越不信单纯的模型排名。

不是说排名没有用,而是它能告诉我的事情有限。我同时跑 Claude Code 和 Codex 做真实项目,时间长了有个明显感受:同一个模型,在不同 Harness 下交出来的结果差距很大。上下文怎么进、工具开了哪些、验证跑在哪一层——这些东西会直接改变最终输出的质量,跟模型本身一样重要,有时候比模型本身更重要。

所以每次新模型发布,我第一反应不是刷榜单,而是想搞清楚:这个新数字,是在什么 Agent、什么 Harness、什么 effort 下测出来的?

Opus 5 发布在七月二十四日。这一次,公开材料提供的信息足够多,刚好可以把这个问题问得更清楚。

什么是 Coding Agent Observability?只有日志还不够

· 阅读需 7 分钟
Isaac Zhao
AI编程俱乐部创建者

刚刚我用 Codex CLI 做了一次只读诊断,最终状态显示 completed,答案正确,Agent 给出了我期望中的最小修复判断。如果这是我唯一看到的东西,我会满意地关掉终端,认为一切如预期运行。

但事件流里还有另一层故事。

Coding Agent 也需要 Eval-Driven Development:一次测试通过还不够

· 阅读需 10 分钟
Isaac Zhao
AI编程俱乐部创建者

上一篇 Observability 教程里保存了一次真实的 Codex CLI 0.145.0 运行。最终判断是正确的,turn 状态是 completed,5 次工具调用里有 2 次失败——Agent 自己绕过去了,结果还是对的。保存的事件流记录了这条路径里可见的工具调用、失败结果和恢复过程。

但它回答不了一个更重要的问题:明天我换了 Agent 版本、换了模型、调整了 Prompt、改了 Skill loadout,甚至只是升级了 Harness——新行为究竟是更好、更差,还是只是不一样?

一次成功运行不是回归测试。

Skills 越多,Coding Agent 反而越笨吗?

· 阅读需 7 分钟
Isaac Zhao
AI编程俱乐部创建者

7 月 23 日的热榜有点意思。

7 月 23 日的一次 NewsNow/掘金热榜抓取里,同时出现了三种内容:怎么挑选值得装的 Skills、怎么写出好的 Skill、以及"为什么装得越多,Agent 越笨"。同一时间窗口,Hacker News 上也出现了检查 Skills 负载、用使用证据治理 Skill 修改、统计哪些能力长期没有触发过的项目。

这个并列本身就说明了问题正在发生变化。

大家的提问,已经从"还能装什么",悄悄转向了"哪些真的会触发、哪些会误触、哪些互相抢任务、哪些只是在占上下文"。这是一个方向性的转变,值得认真想一想。