从 FAST26 SPECFS 看新时代 infra 开发者工作范式

本文是博主读 FAST26 Sharpen the Spec, Cut the Code: A Case for Generative File System with SYSSPEC (Awarded Best Paper) 后的一些主观感想。

1 团子观点

私认为这篇论文最重要的贡献不是 SPECFS 这个文件系统本身——一个 FUSE 层面的内存文件系统离实际生产还有距离。

真正有价值的是两件事：

1. 用严肃的学术实验证明了 LLM Coding 已经可以重度参与 infra 级别的系统开发
2. 给出了一套明确的 Spec 驱动的 agent 编排方法论，回答 "怎样编排 LLM 才能产出可靠的系统代码"

到 2026 年，LLM Coding 的争议点早已经从 "要不要用，能不能用" 转向了 "如何更高工程质量地用"。这篇文章在方法论层面给出了一组答案，这些答案和博主作为 Cursor / Claude Code 重度用户的一线体感高度吻合。

2 论文做了什么

简单梳理核心内容，详细可参考原文。

2.1 Ext4 的 20 年演进：82% 的提交都在功能修复

论文分析了 Ext4 从 Linux 2.6.19 到 6.15 的全部 3,157 次提交。

以 fast-commit 功能为例，初始实现只用了 9 次提交，后续为了修 bug 和维护搞了 80 次提交。功能开发和后续维护的比例是 1:9。

这组数据标明：文件系统开发中绝大部分精力花在了维护和修 bug 上，而这些重复性强、模式固定的工作也许是 LLM 发挥得最好的场景。

2.2 SYSSPEC：用 Spec 替代自然语言提示

论文的核心思路是，不用自然语言 prompt 去让 LLM 写文件系统。比如强调 "避免竞态条件"，LLM 大概率还是会写出竞态条件来。

SYSSPEC 引入了一套借鉴形式化方法的规格 (spec) 语言，包含三部分：

• 功能规格：用 Hoare 逻辑（前置/后置条件 + 不变式）描述每个模块的行为
• 模块化规格：用 Rely-Guarantee 条件定义模块间接口依赖
• 并发规格：单独描述锁协议和并发行为

然后由 LLM agent 工具链将这套规格翻译成 C 代码。

2.3 关键实验数据

消融实验结果如下（使用 DeepSeek-V3.1）：

有两个关键发现：

第一，光描述功能是不够的。没有模块化规格，LLM 生成的代码接口对不上，准确率仅有 40%。加上 Rely-Guarantee 接口约束后，无并发模块的准确率为 100%。

第二，并发必须单独处理。即使功能和模块化规格都齐了，线程安全模块的准确率仍然是 0%。加上独立的并发规格，配合 "先生成顺序逻辑、再叠加并发控制" 的两阶段生成，并发模块的准确率达到 100%。

3 更进一步：模型和工具都进化太快了

3.1 模型能力的代际差异

论文用的模型是 Gemini-2.5-Pro 和 DeepSeek-V3.1。以论文提交时间看，这确实是当时的旗舰。但到了 2026 年 3 月，Claude Opus 4.6、Gemini 3.1 Pro 的推理和编码能力已经远远不在同一水平。

论文中需要靠两阶段生成才能搞定的并发模块，换到最新旗舰模型上，中等复杂度的场景不拆成两步，也许大概率能拿到正确结果。编排的精细度应当随模型能力适当放粗——过度拆解反而引入不必要的上下文切换开销。

论文也意识到了这一点——"模块大小约束随 LLM 能力和上下文窗口的提升而演进"——不过具体怎么动态调整，文中没有展开。博主认为开发者需要根据自身的工作流和模型能力自行调整。

3.2 应用层工具的进化

论文从零搭建了 SpecCompiler、SpecValidator、SpecAssistant 三个 agent 组成工具链。但 2026 年的 Cursor 和 Claude Code 已经在编码场景做了大量工程优化，很多等价能力是内建的。

博主将论文工具链和当前主流 LLM Coding 工具做了个映射：

如果在 Cursor + Claude Code 上重做这个实验，把 Spec 写成项目中的 Rule 文件或 Skill 文件，让工具的 agent 编排层自动加载执行，效果大概率会更好——上下文管理、工具调度和错误重试这些脏活，工具层已经干了。

4 宝贵的洞见

模型会换代，工具会迭代，但论文里有几个洞见是非常有价值的（至少在当前的旗舰模型能力下）。

4.1 关注分离：不要让 LLM 同时想太多事

消融实验的递进过程说明了一件事：LLM 的可靠性当前看来不是靠更强的模型硬撑的，而是靠更好的任务分解换来的。

先生成顺序逻辑，再叠加并发控制——本质上就是把一个 LLM 难以同时兼顾的复合问题，拆成两个它各自能处理好的子问题。

这一点和博主日常的体感完全一致。让 LLM 同时考虑数据结构设计、错误处理、并发安全和性能优化，产出通常不太行。但分步走——先把核心逻辑跑通测试、再单独处理并发、再单独抠性能——每一步的质量都高得多。

不要让 LLM 同时思考太多维度的问题。 这算是博主当前阶段最核心的编排感受了。看来人类当前阶段仍然至少扮演一个编排者的角色。

4.2 Spec 是什么：结构化的设计意图

仔细看 SYSSPEC 的规格语言，它并不是 Coq 或 TLA+ 那种纯数学形式化语言，而是一种结构化的自然语言，辅以类型标注和 Hoare 逻辑的组织框架。

纯自然语言太模糊，纯形式化语言门槛太高。论文选的这个甜点，和博主在实际项目中摸索出来的 Spec 工作流不谋而合：

1. 用结构化的 markdown 描述模块的前置条件（调用前系统该处于什么状态）
2. 描述后置条件（调用后系统该变成什么状态、返回什么）
3. 列出不变式（整个过程中什么条件必须始终成立）
4. 如果是性能敏感路径，显式写清算法选择和理由

这四样东西写清楚，比跟 LLM 说 "帮我写一个高性能的并发安全的读写模块" 效果好得多得多。

这也迫使开发者一定要想好所有的情况、异常、静态条件才能开工，必须开发者将大量精力放在设计上。

换句话说，对于 infra 这种高可靠性要求的软件开发，你得知道自己想要什么，也要知道原理和技术路径。

道理很简单，架构师可能不会深入到代码边界，但必须对整个软件的架构划分、技术风格路线和质量牢牢把控。一线的开发工程师也被迫在更高层次思考。

4.3 DAG 结构化补丁 = 变更的拓扑排序

论文的 DAG-structured spec patch 是个实用的设计：

• 叶节点：自包含的变更，不依赖其他补丁
• 中间节点：构建在子节点保证之上的更高层逻辑
• 根节点：保持对外接口语义不变的最终集成点

这就是一套变更传播的拓扑排序。实际用 LLM Coding 工具处理跨多文件、多模块的重构时，有效的做法也是如此——先改底层数据结构（叶节点），再改依赖它的中间层，最后动对外接口（根节点），并且根节点的对外保证不变。

不按这个顺序来，LLM 很容易搞出一堆接口不兼容的半成品。越改越难改，最终不可维护。

5 新时代 infra 开发者的工作范式

论文标题 "Sharpen the Spec, Cut the Code"（磨好规格，代码自出）其实已经指出了。结合博主作为 Cursor 和 Claude Code 重度使用者的一线经验，纯主观聊聊现阶段 infra 开发者的角色变化。

5.1 人类开发者已经事实上从事无巨细的底层编码，转换到了编排者的角色

具体而言，决定模块边界在哪里、接口契约是什么、并发模型怎么选、数据结构怎么组织——这些 "what" 和 "why" 的决策，仍然且只能由人来做。论文证明了一点：只要这些设计意图被精确地写成 Spec，LLM 在 "how" 层面的执行力已经足以交付生产级别的文件系统模块。

5.2 人类仍然要编排 LLM agent 去建立完善的质量控制体系

LLM 生成的代码不是写完就完了——回归测试、Lint 检查、代码审查、性能基准——这套质量门禁仍然需要人来定义和把关。论文中 SpecValidator 的设计本质上就是一套自动化的 code review + CI 管线，最终负责整个代码库的整体质量和演进方向。

论文有一句话说得好：

The path forward is not to replace developers with LLMs, but to elevate their role by changing how they express design.

说白了：LLM 只有知道你想要什么才能帮忙写代码，我们想怎么更好地表达设计意图。 Spec 写得越精确，生成的代码质量越高，后续维护成本越低。这在博主的日常实践中反复得到验证，也是这篇论文给 infra 开发者最实在的启发。

5.3 人类被迫学点管理学

开发者被迫向高层编排者迁移，竟然变成了 “管理团队”。有一些 “社会学 agent 编排” 工作貌似意外地很有用。比如

• 通过重复 3 遍 prompt 增强模型的能力 - Prompt Repetition Improves Non-Reasoning LLMs
• 使用 "PUA" 指令提高 LLM agent 解决问题的能力 - https://github.com/tanweai/pua

6 小结

新时代，来临力。FAST 这篇论文证明了 LLM Coding 已经从 “能不能用” 转向了 “如何用好” 的问题。我们期待看到模型能力的上升，和新的 SOTA 的工作流程的演进。

博主最近对工作流的一些其他探索，供参考：

• 一位分布式系统开发者的 LLM Agent 技术生产实战
• BMad Method: 原理剖析、实战与主观评价