Stalwart Labs 公开 AI 用法：调试提速与 Mythos 安全审计

邮件服务器与协议工具开发商 Stalwart Labs 近日发表长文，系统描述其团队在 2026 年如何把 AI 嵌入开发流程的哪些环节、又刻意把 AI 排除在哪些决策之外。文章同时披露了 Anthropic 旗下 Project Glasswing 预览模型 Mythos 在开源生态中挖出大量历史漏洞的细节，为当前业界关于「AI 写代码是否仍是 slop」的讨论提供了一个具体、可量化的反例。

从「写对函数」到「调度 Agent 群」

文章开篇指出，过去两年间开发者讨论的重心已经从「模型能否一次写出正确函数」转向「同一时间能跑多少互相隔离的 Agent、阅读速度何时取代打字速度成为瓶颈」。编辑器厂商已围绕这一变化重构产品形态，例如 Cursor 3 推出了用于管理 Agent 集群的全屏工作区，取代了原有的侧边聊天框；团队也已习惯让审阅、测试生成、安全扫描等专用 Agent 在各自的 git worktree 中并行运行。Stalwart Labs 认为，模型能力确实在严肃基准和日常体验两个层面同步提升，词汇也在同步收敛：他们对 Hacker News 与 Reddit 上千条帖子的分析显示，「slop」一词的含义已收窄为「能编译、能过测试、外观整洁，却缺乏整体意图与对所处系统认知的代码」——这比「机器写的代码」是更有用的定义，也恰好对应他们最在意的失败模式。

AI 缩短的，是定位 bug 的时间

团队强调，调试中真正昂贵的从来不是写补丁，而是定位问题。以前像「在特定操作序列下某 IMAP 客户端观察到重复 UID」这类报告，需要工程师花数小时添加埋点、在多个子系统间重建状态；理解清楚后，真正的修复往往只有十几行。拥有完整代码库上下文的 Agent 可以并行读取相关调用路径，把模糊症状收敛到几个候选位置，并给出通常接近正确的修改建议。人工环节仍然保留：阅读 diff、判断修复针对的是根因还是症状、补回归测试。文章指出，过去要消耗一下午的调查如今只需数分钟，因此团队可以把「开放 bug 数为零」维持在常态，这在他们 2024 年写过的「通往 Stalwart 1.0 之路」中还曾被视为里程碑，如今只是日常状态。

Mythos 在 OpenBSD 与 FFmpeg 中挖出历史漏洞

文章特别提到，2026 年 4 月 Anthropic 宣布 Project Glasswing 并预览了 Mythos 模型。该模型在 OSS-Fuzz 语料上跑出超过 23,000 个潜在漏洞，覆盖 1,000 多个开源项目；截至文章撰写时，已有约 1,700 个经外部复核确认，其中超过 1,000 个被评定为高危或严重级别。更引人注目的是具体发现：Mythos 在以严谨著称的 OpenBSD 中挖出一处存在 27 年的缺陷；在 FFmpeg 中找到一处存在 16 年、熬过约 500 万次模糊测试仍未触发的 bug。Stalwart Labs 也在自家代码上以同样思路做了 AI 辅助分析，发现的均是小问题并已修复；他们承认「没有大碍」只是证据，不是证明，因此把这次扫描与 2023、2025 两轮独立安全审计并列，而不是替代其中任何一轮。

基准交给 AI，决策留给人

文章后半段把视角切回自身产品。在 v1.0.0 开发分支上，团队用 AI 编写了大量性能基准——文中称「数百个」——直接消解了过去「搭测试框架就要半天」的概念验证税。如今几乎所有性能猜想都会先被实测，其中不少被证实有效。最直观的结果出现在内置全文检索存储上：对未运行外部 Elasticsearch 或 Meilisearch 的部署，v1.0.0 中的 FTS 查询相对 v0.16 分支最高提速 124 倍。这个数字是测量出来的，而非灵感：大量尝试中多数不奏效，活下来的方案都因为基准结果而被保留。文章明确划出分工——AI 写基准，人做优化与决策——并强调这一划分是有意为之，也直接引出他们对 AI 的边界设定：不把架构决策交给 AI，也不让 AI 写入或大幅修改既有大体量代码段。

综合而言，Stalwart Labs 给出的并非「全面拥抱 AI」的口号，而是一份带具体数字与失败案例的工作流清单：调试与基准编写的工时被显著压缩，安全审计多了一个角度，而架构判断仍由人主导。