💻 computer science

Where Did the Variability Go? From Vibe Coding to Product Lines by Regeneration

本文提出了“通过再生实现变异性”（Variability by Regeneration, VbR），这是一种新颖的软件产品线方法，其中大语言模型（LLM）充当推导引擎，根据声明式规范在生成时生成专用的、无死代码的二进制文件，从而在 AI 驱动的“氛围编程”（vibe coding）时代，有效地将变异性管理从代码本身转向规范。

原作者： Xhevahire Tërnava

发布于 2026-06-19

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Xhevahire Tërnava

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

以下是使用简单语言和日常类比对论文《变异性去哪了？》（Where Did the Variability Go?）进行的解释。

核心问题：无法更改的“魔法”代码

想象你雇佣了一位才华横溢的大厨（AI）来为你做饭。你告诉他：“我想要一份辣味意面。”他立刻为你端上了一盘完美、热气腾腾的辣味意面。

现在，想象你想改变主意说：“其实，我想吃微辣的。”在传统的烹饪方式中，你只需要要求大厨调整一下调料即可。但在这种新的烹饪风格（称为**“氛围编程/Vibe Coding”**）中，大厨不仅仅是调整调料，而是根据你的新需求，直接把第一盘菜扔掉，重新从头开始做一份全新的菜。

问题在于，第一盘辣味意面现在对你来说毫无用处。你无法把它变成微辣意面。它是一个“单一用途”的产物。如果你想要不同版本的软件，你每次都必须要求 AI 生成一个全新的文件。

发现：那些“选项”去哪了？

研究人员观察了 10 个以这种方式创建的软件项目。他们发现了一个令人惊讶的现象：“选项”消失了。

在传统的软件开发中，代码就像一把瑞士军刀。它内置了刀片、螺丝刀和开瓶器。你只需拨动开关（一个设置）即可使用你需要的工具。代码包含了所有工具，即使是你现在并不使用的工具。

但在“氛围编程”中，AI 并不是在制造一把瑞士军刀。它在制造一个单一用途的工具。

如果你要求一把刀，AI 就造一把刀。
如果你要求一个螺丝刀，AI 就造一个螺丝刀。
“刀”的版本里面没有任何螺丝刀的零件，而“螺丝刀”的版本里也没有任何刀的零件。

研究人员称之为**“近乎零变异性”**。关于软件“是什么”的所有决策，都在 AI 编写代码的那一瞬间就做定了。一旦代码写好，它就被冻结了。不再有可以拨动的开关。

解决方案：“通过再生实现变异性”（VbR）

与其试图强迫 AI 去构建一个庞大、复杂的瑞士军刀（这会让代码变得混乱且难以理解），作者提出了一种处理此问题的新方法，称为通过再生实现变异性（Variability by Regeneration, VbR）。

这就像是定制西装店与百货商店的区别。

传统方式（百货商店）： 你买了一件西装，上面缝着多余的面料、不需要的纽扣以及你永远不会用到的口袋，只为了以后可以进行“配置”。它很沉重，充满了冗余的重量。
VbR 方式（定制西装店）： 你拥有一份主蓝图（规格说明书）。
1. 你告诉店里：“我需要一套参加婚礼的西装。”
2. AI（裁缝）查看蓝图，并立即为你缝制一套完美的、轻便的西装，专门用于那场婚礼。它没有任何多余的面料。
3. 稍后，你说：“我需要一套参加海滩派对的西装。”
4. AI 并不会尝试裁剪那件婚礼西装。它再次查看蓝图，并为你缝制一套全新的、完美的海滩派对西装。

在这个系统中，“变异性”（拥有不同西装的能力）并不存在于衣服本身，而是存在于蓝图中。

实际操作是如何运作的

论文通过一个经典的计算机工具 wc（用于统计文件中的单词数量）展示了这一点。

蓝图： 开发人员编写一个简单的文件（一个 YAML 文件），列出了所有可能的特征：“统计行数”、“统计单词”、“统计字符”等。
生成： 当用户想要特定版本（例如，“我只想统计行数”）时，AI 会读取蓝图，识别该请求，并生成一个极其微小、运行极快的程序，该程序仅执行那项任务。
调度器（服务员）： 由于 AI 制作了三个不同的程序（一个统计行，一个统计单词，一个统计全部），计算机如何知道运行哪一个？
- 研究人员构建了一个“服务员”（调度器）。
- 你输入一个命令。服务员查看你的命令，检查菜单（清单），然后立即运行与你请求相匹配的特定程序。
- 对你（用户）而言，你从未见过这些不同的程序。你只看到一个行为会神奇变化的工具。

为什么这很重要

作者认为，我们不应该试图通过强迫 AI 在代码中加入“开关”来修复“氛围编程”，因为这违背了这项新技术的初衷。

相反，我们应该接受代码应该是可丢弃且具有特定用途的。

旧方式： 保留一个巨大的、混乱的代码文件，并将所有选项隐藏在其中。
新方式 (VbR)： 保留一份干净的规格说明文件（规则），并在每次需要不同版本时，让 AI 生成一个新鲜、完美、“无死代码”的程序。

总结

论文声称，在 AI 编程时代，我们失去了“微调”单个程序的能力。相反，AI 会为每一个需求创建一个新的程序。作者建议我们通过将规则（规格说明）视为永久的主体，并将代码视为每当规则改变时就会重新生成的临时且完美的产品，来拥抱这一变化。这不是为了修复代码，而是为了在需要时再生出最合适的代码。

技术摘要：变异性去哪了？从“氛围编程”到产品线 —— 由 Regeneration 撰写

1. 问题陈述

本文探讨了由“氛围编程”（vibe coding）引起的一种基础性的软件工程范式转变。氛围编程是一种新兴范式，其中大语言模型（LLM）根据自然语言提示词生成整个程序。传统的软件产品线（SPL）工程依赖于制品内变异性（in-artifact variability）——即在代码中嵌入显式机制（如 #ifdef、特性模型、运行时标志），以支持配置和演进；而氛围编程似乎消除了这些机制。

作者识别出了一个“变异性缺口”：

观察结果： 在氛围编码的系统中，变lı性决策实际上是在生成时（即 LLM 生成源代码的那一刻）被“冻结”的。
后果： 生成的制品表现出近乎为零的制品内变异性。没有预处理器保护，极少有命令行界面（CLI）选项，也没有运行时配置点。
风险： 由于缺乏显式的变异机制，适配一个氛围编码的系统需要为每一个新配置从头开始重新生成整个代码库。这会导致工业规模的“克隆并拥有”（clone-and-own）反模式，破坏了旨在通过共享资产系统化管理变异性的 SPL 工程核心原则。

2. 研究方法

本文采用了一种结合探索性实证分析与新工程范式正式提案的混合方法。

探索性分析

作者对来自 GitHub 的 10 个氛围编码 C/C++ 项目进行了分析，涵盖七个领域，规模从 201 行到 14,077 行代码（LoC）不等。

对比： 这些项目与 x264（一个长期存在的、经过传统工程设计的可配置 C 系统，规模为 70,964 LoC）进行了对比。
指标： 研究测量了用于设计变异性的 CLI 选项和预处理器变量的存在情况。
发现：
- x264： 暴露了 184 个 CLI 选项和 117 个不同的预处理器变量，分布在 2,201 个条件编译指令中。
- 氛围编码项目： 总共仅暴露了 45 个 CLI 选项（中位数为 0；10 个项目中共有 6 个完全没有选项）并仅引用了 27 个预处理器变量。至关重要的是，氛围编码项目中的变量均不代表设计的变异性，而是偶然性的（例如平台检查、数学常量）。
- 结论： 在氛围编码中，从规范到运行时的绑定时间（binding times）流水线坍缩为了单一的生成时。

提议的解决方案：基于再生的变异性 (Variability by Regeneration, VbR)

作者并非试图强迫 LLM 输出传统的变异机制（例如教它们编写 #ifdef），而是提议拥抱输出的零变异特性。他们引入了基于再生的变异性 (VbR)，这是一种将变异性完全在代码制品之外进行管理的程序线方法。

该框架由三个正式组成部分组成：

规范 (Specification, $S$ )： 一个定义了以下内容的声明式文件（如 YAML）：
- 一组特征 ( $F$ )，包含类型和约束。
- 一组变体配置 ( $V$ )，每个配置都是一个将值分配给特征的部分函数。
- 每个变体中每个特征的绑定时间注解（例如，在生成时绑定某个特征与在运行时绑定）。
生成函数 (Generation Function, $G$ )： 一个由 LLM 驱动的过程，它接收规范和特定的变体配置，以合成代码制品 ( $A_j$ $A_{j}$ )。
- 零死代码： 被排除的特征不会生成任何代码。
- 可追溯性： 生成器产生注解（例如 @feature），将代码位置链接回规范。
- 无资产库： 与经典 SPL 不同，不存在预先存在的代码库；代码是为每个变体从头合成的。
变体调度器 (Variant Dispatcher, $D$ )： 一种将用户请求路由到正确预编译二进制文件的机制。
- 它使用一个清单（manifest），将使用模式（例如特定的 CLI 标志或输入模式）映射到相应的二进制文件。
- 用户通过单个命令（例如 wc）进行交互，而调度器会透明地选择合适的变体（例如 wc-minimal、wc-standard）。

正式属性

论文定义了三个用于生成流水线的“契约”，这些契约通过静态检查和测试门禁而非仅仅信任 LLM 来强制执行：

属性 1（零死代码）： 如果某个特征在配置中被排除，则它不得出现在生成的制品中。
属性 2（追溯完整性）： 每个包含的特征必须有一个对应的代码位置，且每个代码位置必须映射到一个指定的特征。
属性 3（绑定时间灵活性）： 绑定时间（生成、编译、链接、运行时）是根据规范进行声明的设计决策，而非实现机制的后果。

案例研究：`wc` 产品族

作者在 Unix wc（字数统计）工具上实例化了 VbR：

规范： 定义了 6 个特征（例如 count_lines、longest_line）和 3 个变体（wc-minimal、wc-standard、wc-analytics）。
生成： 使用 LLM (Claude Opus 4) 生成了三个不同的 C 文件。
- wc-minimal：11 行，0 个变异点，固定为 stdin。
- wc-standard：75 行，3 个运行时变异点（标志 -l、-w、-c）。
- wc-analytics：107 行，递归处理，JSON 输出。
调度： 一个 Shell 脚本解析用户输入并执行匹配的二进制文件。例如，管道输入（echo "hello" | wc）路由到 minimal 二进制文件，而使用标志（wc -l -w）则路由到 standard 二进制文件。

3. 结果与局限性

结果： wc 演示成功展示了一个产品族可以通过单个规范文件进行维护，且变体可以按需再生。演进（例如添加 longest_line 特征）仅需编辑规范，即可触发受影响变体的针对性再生。
局限性：
- 非确定性： LLM 输出并非形式化正确的；可能会引入 Bug 或不安全的惯用法。
- 代码复用： VbR 牺牲了变体间的代码复用。两个具有相同特征的变体可能具有不同的实现，这意味着 Bug 修复不会自动传播。
- 可扩展性： 评估仅限于一个小型产品族。扩展到数十个变体并衡量生成成本仍是开放性问题。
- 验证： 目前，验证 VbR 属性（零死代码、可追溯性）是手动的；在生产环境中使用需要实现自动化。

4. 意义与主张

该论文声称提出了第一个专门为 AI 生成软件设计的程序线方法。其主要意义在于，它将氛围编码中变异性的“损失”重新定义为一个新的工程机遇，而不是一个需要修复的缺陷。

绑定时间的转移： 作者认为，在 AI 驱动的开发中，生成时已成为一个主导的绑定时间，在源代码存在之前就解决了变异性决策。
关注点分离： VbR 主张，在 AI 生成的软件中，变异性属于规范，而非代码。
新的衍生模型： 它与经典 SPL（从共享资产库中选择并组合）形成对比，提出了一种产品是通过规范合成的模型，其中 LLM 充当衍生引擎。

作者总结道，随着氛围编码变得日益普遍，工程重点必须从管理制品内部的变异性，转向管理产生制品的规范和再生流水线。