✨ 要点🔬 技术摘要
想象一下，你正在雇佣一群才华横溢但有点调皮的机器人厨师，根据你写的食谱来烹饪一道复杂的菜肴。你希望机器人能完美地执行你的指令，但你也需要确保它们不会偷偷加入自己的“特殊配料”（比如额外的香料或随机的蔬菜）而这些是你没要求的。
这篇论文是一项科学实验，旨在研究管理这些机器人厨师的最佳方式。研究人员测试了三种不同的指令传达方式，以观察哪种方法能产生最一致的结果，以及哪种方法能在机器人试图偷偷加入未经授权的配料时抓住它们。
以下是使用简单类比对实验进行的拆解：
测试的三种“指令风格”
研究人员比较了三种告诉机器人该做什么的方式：
“严格的记录员” (traceSDD)： 这种方法要求机器人在它写的每一行代码旁边都写一张微型便利贴。便利贴必须准确说明它正在遵循你食谱中的哪一部分（例如：“这一行是为了步骤 3.1”）。如果机器人写了一行代码却没写便条，或者为你的食谱中不存在的步骤写了便条，这就是一个危险信号。“讲故事的人” (Spec Kit)： 这种方法使用标准的食谱格式，包含用户故事和要点。机器人遵循这个故事，但它不需要在代码本身中编写任何便条或引用。“地图绘制者” (OpenSpec)： 这种方法给了你一个食谱和一个单独的地图（一个侧边文件），在机器人烹饪完成后，将食谱步骤与代码进行关联。代码本身没有任何注释。
两个主要目标
研究人员测量了两件事：
一致性 (Determinism)： 如果你连续三次要求机器人烹饪同样的菜肴，这三道菜看起来和尝起来会完全一样吗？还是每次都会略有不同？“告密者”测试 (Hallucination Detection)： 如果机器人偷偷加入了禁忌的配料（即“幻觉”），系统能否自动发现它？
重大发现：权衡取舍
研究发现了一个迷人的“鱼与熊掌不可兼得”的权衡关系。你不能既要又要；你必须在一致性 和安全性 之间做出选择。
1. “无便条”方法的一致性更高
类比： 想想一位音乐家演奏乐曲。如果他们不必在弹奏每一个音符时都停下来解释为什么要这么弹，他们就能流畅且一致地演奏出同一首曲子。
2. “严格便条”方法能抓到作弊者
类比： 想象一下，音乐家在弹奏每一个音符后都必须停下来写下一行字，说“我弹这个是因为乐谱上这么要求”。这种干扰使得他们的表演每次都会有所偏差。但是 ，这种方法拥有一个超能力：它能抓住作弊者。 因为机器人必须为每一行代码引用一个特定的食谱步骤，系统可以立即发现如果机器人写了一行代码，却引用了一个在你食谱中并不存在的步骤。
结果： “严格的记录员”方法抓住了机器人试图偷偷加入的 86–88% 的假配料。而其他两种方法抓获率为 0% 。
其他方法表现如何？
Spec Kit（讲故事的人）： 这是表现最差的一种。它产生的结果最不一致（菜肴的变化最大），并且抓住了 零个 假配料。OpenSpec（地图绘制者）： 它比“讲故事的人”表现稍好，但仍然无法自动捕捉假配料，因为便条并没有写在代码内部。
“易 vs 难”的惊喜
研究人员还注意到一个有趣的现象，即任务难度对结果的影响：
简单任务： 写便条带来的惩罚非常大。在简单的任务中，强制要求机器人写便条会让结果变得非常不稳定。复杂任务： 在复杂的任务中，这种惩罚要小得多。当任务很复杂时，机器人解决问题的方法有很多种，因此额外的便条不会像那样严重影响一致性。
核心结论
这篇论文得出的结论是，在使用 AI 编写代码时，存在一个根本性的选择：
如果你希望 AI 每次生成的代码都完全相同（一致性）： 不要强迫它写引用。只需给它一个结构化的食谱即可。如果你需要确定 AI 没有偷偷加入未经授权的代码（安全性）： 你必须强迫它为每一行代码编写引用。这会使代码每次看起来略有不同，但它给了你一种独特且自动化的方式，可以在 AI 试图撒谎或添加你没要求的东西时抓住它。
研究人员发现，无论使用哪种 AI 模型，这种“安全性 vs 一致性”的权衡都会发生（他们测试了两个截然不同的模型，结果是一样的）。这是一个游戏规则，而不仅仅是某个特定机器人的缺陷。
技术摘要：规范驱动开发中的引用规范
问题陈述
随着代理式编码系统（Agentic Coding Systems）的出现——即大型语言模型（LLM）能够自主编写并修订软件——一个关键的问责差距也随之产生：如何验证生成的代码是否严格实现了既定需求，而没有引入“幻觉”。这些幻觉表现为超出范围的功能、来自训练数据的未经授权导入或过度工程，它们虽然能通过功能测试，却引入了安全或合规风险。
虽然传统的需求追溯方法（如 IEEE 830 或 DOORS 等工具）可以将需求与工作产品联系起来，但这些方法通常是基于制品层面的且依赖人工，难以适应快速的 AI 辅助迭代。三种新兴的规范驱动开发（SDD）框架试图通过不同的理念来解决这一问题：
traceSDD ：强制执行逐行的行内引用（例如 # [REQ-XXX.Y.Z]），将代码与特定的需求点绑定。Spec Kit ：使用制品层面的追溯（用户故事、验收标准），但缺乏行内代码引用。OpenSpec ：依赖事后的外部追踪映射（YAML 侧边文件），而不直接标注源代码。
核心研究问题在于：强制要求 LLM 为每一行代码提供需求引用，是否能提高实现的正确性、输出的确定性以及幻觉的可检测性，以及这些效应是否能在不同的模型架构之间具有泛化性。
研究方法
作者进行了两项独立的、预注册的受控实证研究，在两种不同的前沿 LLM 之间比较了四种实验条件（traceSDD 引用、traceSDD 未引用、Spec Kit、OpenSpec）：
研究 1 ：使用 Claude Sonnet 4.6 处理 20 个基准 Python 任务（N=20），共生成 240 个实现（每个任务运行 3 次）。研究 2 ：使用 GLM-5-turbo 处理 50 个涵盖 8 个软件工程领域、3 个难度等级和 2 种规模类别的全新基准任务（N=50），共生成 600 个实现。
实验条件：
traceSDD (cited/已引用) ：分层级的 REQ-XXX.Y.Z 规范，并在非平凡行强制进行行内引用。traceSDD (uncited/未引用) ：与已引用条件相同的规范，但不包含行内引用（旨在隔离注释机制的影响）。Spec Kit ：原生散文式规范（用户故事），无引用机制。OpenSpec ：原生能力规范，带有外部追踪 YAML 文件。
指标：
输出确定性 ：通过对独立会话中经过归一化、去除注释处理的代码进行 Levenshtein 集相似度计算，使用词法相似度得分 (LSS) 进行测量。幻觉检测 ：通过可追溯性检测率 (TDR) 进行测量。实验中故意注入了幻觉（超出范围的函数、未经授权的导入、过度工程），并引用了虚假的 REQ ID。检测依赖于“孤儿 REQ 检查”（有效规范 ID 与被引用 ID 的集合差集）。功能正确性 ：通过针对基准测试集的真阳性率 (TPR) 进行测量。假阳性率 (FPR) ：正确实现被误报的频率。
核心贡献
首次跨模型比较 ：提供了首次在两种根本不同的 LLM 架构（Transformer/宪政 AI 与 自回归/双向模型）之间进行的受控比较，涉及 70 个任务和 840 个实现。复制了引用隔离发现 ：证实了强制行内引用显著降低了输出的确定性（相比于完全相同的未引用条件），这一发现跨模型保持一致。全面的子组分析 ：揭示了引用的确定性惩罚在简单和小型任务中最为显著，并随着任务复杂度和规模的增加而减弱。自动化幻觉检测 ：证明了已引用条件下的“孤儿 REQ 检查”能实现高检测率（86–88%）且零假阳性，这一能力是 Spec Kit 或 OpenSpec 所不具备的。
核心结果
1. 输出确定性 (RQ1)
观察到了一个一致的权衡：引用降低了确定性。
引用惩罚 ：在两种模型中，未引用条件产生的输出比已引用条件具有显著更高的确定性（Claude: d = − 0.76 , p = 0.003 d = -0.76, p = 0.003 d = − 0.76 , p = 0.003 d = − 0.72 , p < 0.001 d = -0.72, p < 0.001 d = − 0.72 , p < 0.001 框架比较 ：
traceSDD (cited) 在确定性方面显著优于 Spec Kit （Claude: d = 0.47 d = 0.47 d = 0.47 d = 0.42 d = 0.42 d = 0.42 traceSDD (cited) 并没有显著优于 OpenSpec （Claude: d = 0.18 d = 0.18 d = 0.18 d = 0.14 d = 0.14 d = 0.14 未引用 条件始终实现了最高的确定性，其表现优于两种外部基准，且效应量较大。
子组分析 ：确定性惩罚在简单任务（d = − 1.85 d = -1.85 d = − 1.85 d = − 0.95 d = -0.95 d = − 0.95
2. 幻觉检测 (RQ2)
检测率 ：只有 traceSDD (cited) 条件实现了自动化幻觉检测，其 TDR 分别达到 86.4% (Claude) 和 88.0% (GLM)。其他方案的零检测 ：未引用条件（尽管使用了相同的结构化规范）、Spec Kit 和 OpenSpec 的 TDR 均为 0% 。这证明了检测需要代码内部的注释机制，而不仅仅是存在结构化规范。假阳性 ：在两项研究的所有检查中，FPR 均为 0.0% 。功能正确性 ：所有条件均实现了 100% TPR ，证实引用规范本身不会降低功能正确性。
意义与主张
本文确立了 SDD 框架中的引用规范涉及一种原则性的权衡：以降低输出确定性为代价，换取自动化的幻觉检测。
权衡关系 ：强制性的行内引用引入了词法变异性（由于模型在“何时”以及“如何”进行引用的决策过程），从而降低了跨会话生成代码的一致性。然而，正是这种机制创建了一个可验证的自动化检查（孤儿 REQ 检查），能够高精度地检测范围蔓延和未经授权的功能，且假阳性为零。泛化性 ：两种不同架构（Claude 和 GLM）之间效应量（d ≈ − 0.72 d \approx -0.72 d ≈ − 0.72 实际应用意义 ：
对于受监管/高风险领域 （医疗、金融），本文建议使用 带有强制引用的 traceSDD ，因为其检测幻觉的独特能力超过了确定性下降带来的适度成本。
对于快速原型设计 （验证性次之），建议使用未引用 REQ 格式 的方法，因为它保留了 REQ 格式的结构锚定优势（比基准方案具有更高的确定性），同时避免了引用开销。
Spec Kit 被识别为在衡量维度上表现最弱的选择（确定性最低，且无自动化检测），尽管作者承认其工作流优势可能有所不同。
作者得出结论，虽然引用规范降低了确定性，但它提供了一个在生产环境中至关重要的自动化验证层，特别是在规范正确性至关重要的场景下。未来的工作建议探索混合方法以及将此类检查集成到 CI/CD 流水线中。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。