衡量意图在智能合约智能体合成中何处丢失

1. 问题与价值

这篇论文的贡献类型是「知道」为主、「做到」为辅：核心工作是测量与诊断——系统性地检验「智能合约合成中意图在哪里丢失」这一问题的评测工具本身是否有效，并据此定位信息丢失发生在流水线的哪个阶段；顺带提出一个改进后的流水线作为测量结论的验证载体。

它解决的问题是：LLM 智能体可以把自然语言描述变成能编译的代码，但「代码是否按作者意图行为」极少被用经过验证的工具测量。在智能合约场景中这个问题尤其尖锐，因为合约持有并转移资金、部署后不可修补、失败代价高昂。现有评测常用 LLM 裁判、静态分析、编译通过率等代理指标，但这些指标测的不是「意图符合度」，而且模型即使不读需求描述也能靠通用惯例写出看起来合理的合约，评测可能把「懂惯例」误当成「懂需求」。

受益者与受益方式：需要部署合约的 Web3 应用开发者、需要评估代码生成智能体的研究者、以及构建合约生成流水线的工程师。开发者获得一个能暴露「生成合约漏掉了哪些必需函数、哪些行为与原始实现不一致」的评测方法；研究者获得关于「评测工具必须用植入错误验证、必须有无描述对照、必须精确重放」的方法论结论；工程师获得关于「信息应在生成前获取、生成后的安全改写会破坏需求行为」的流水线设计依据。

评测规模锚点：语料来自 FSM-SCG 的 21,976 个合约，过滤后开发实验用 100 个合约，规模复现用 500 个持有合约；每个合约生成 60 条随机交易序列、每条 8 步；参考模型覆盖 GPT-5.4、Claude Sonnet 5、Gemini 3.5 Flash 三个模型家族。

主结果反差：改进后的「先提问再生成」流水线在 500 个持有合约上达到 72.9% 的交易级保真度，对比一次性生成为 53.9%、原七阶段流水线为 39.3%。更关键的反差在于评测工具本身：LLM 裁判在植入错误上抓到 65.0% 但误报 80%，而一个只从函数名写出的参考模型能抓到 87.5%——说明常规基准奖励的主要是模型已知的惯例，而非对描述的理解。

2. 已有工作的不足

在本文之前，智能合约代码生成评测的最好做法大致分几条路线。测试基准路线如 SolEval、SolBench 测函数补全，SolContractEval 重放历史交易，SolBehave 对再生成合约与原始合约做差分模糊测试。这些工作把「与参考实现的行为一致」作为正确性标准，方向是对的，但它们的贡献是基准本身，没有系统研究评分规则和评测工具本身的有效性——例如共享接口评分会不会隐藏遗漏、适配重放会不会放过签名不匹配、LLM 裁判的误报率有多高。

LLM 裁判与审计路线中，已有工作知道 LLM 裁判有偏，LLM 审计器在智能合约上呈现高召回低精度，稳健系统会把最终裁决交给非 LLM 检查器。但本文之前，没有一个受控研究去量化「LLM 裁判在植入错误上的抓取率与误报率」「LLM 测试器的抓取率」「静态分析器对意图类错误的抓取率」，也没有把这些工具与「只给函数名的无描述对照」放在同一把尺子下比较。

澄清式提问与用户模拟路线中，ClarifyGPT 和 TiCoder 会向用户提问，但评估依赖人工评价；模拟用户被越来越多地用于评估交互系统，但其有效性存疑。本文之前，没有人做受控研究去分离「信息」与「流水线架构」的贡献——即同样给足信息时，复杂流水线是否真的比一次性生成更好，还是只是因为它拿到了更多信息。

需要明确的是：本文之前学界不知道的具体事实——比如 LLM 裁判误报 80%、参考模型从函数名就能抓 87.5% 的植入错误、安全改写损失 12.8 点保真度——这些是本文的发现，不是立项时的背景共识。立项前成立的设计限制是：评测工具普遍没有经过植入错误验证；评测没有控制模型「不读描述就知道什么」；评分规则可能通过共享接口或适配重放隐藏遗漏；澄清式提问的收益没有被从流水线复杂度中分离出来。

3. 重建作者的思考路径

如果面对「如何评测智能合约合成流水线」这个问题，我大概会这样推：

先想到的是：既然合约有原始实现，那就把生成合约和原始合约在相同交易上重放，看行为是否一致。这看起来直接，但马上撞上第一个矛盾——什么算「行为一致」？如果只比较双方都实现了的函数，那生成合约漏掉一个关键函数反而不会被扣分；如果调用时适配各自签名，那参数类型错了也测不出来。所以必须固定接口、精确重放、把「没实现」和「没暴露值变化」都算失败。

接着会想：用什么当裁判？LLM 裁判最省事，但怎么知道它测得准？这里出现第二个分叉——裁判本身需要被验证。自然的做法是植入已知错误，看裁判能不能抓到，同时看它在没错误的合约上误报多少。这一步做完会发现 LLM 裁判误报高得离谱，于是转向可执行参考模型。

然后会撞上第三个矛盾：参考模型写得再好，它也是从描述写的。如果模型不读描述、只从函数名就能写出大部分正确行为，那评测奖励的到底是「理解描述」还是「懂 Solidity 惯例」？于是需要一个无描述对照——只给函数名写参考模型，看它抓多少。结果发现抓取率只比有描述低 6.8 个点，这说明常规基准的大部分分数是惯例贡献的。

到这里，测量工具的问题基本清楚了，但还有一个更根本的问题：信息在哪里丢的？是生成前描述不够，还是生成后的审计、修复、验证环节没做好？这需要做一个因子比较——同样的信息给不同架构，同样的架构给不同信息。结果会发现：信息加在生成前，三个模型家族都涨 19 到 23 点；生成后的阶段最多加约 1 点，安全改写反而扣 12.8 点。

与论文实际路径的差异：论文是从自己早前的七阶段流水线出发，先质疑那个流水线的评测方式（LLM 评分裁判和 LLM 安全门），再反过来用新工具定位信息丢失。我上面的路径是从「怎么测」推到「怎么改」，而论文实际是「先有一个现成流水线，发现它的评测不可信，然后重建评测，再用新评测去拆解流水线」。另一个差异是：论文把「模拟客户端」作为核心实验装置，而我一开始不会想到用 GPT-5.4 读原始合约来模拟作者回答——这个设计是论文的巧妙之处，它把「澄清式提问能恢复多少隐藏实现」变成了可测的量。

4. 核心 intuition

核心直觉可以用「开卷考试 vs 闭卷考试」来类比。一个学生（生成器）拿到一份模糊的考试说明（短描述），他可以靠平时积累的套路（模型预训练中学到的 Solidity 惯例）写出看起来合理的答案，但题目里没写清楚的要求——谁有权限、什么情况必须失败、金额上限是多少——他只能猜。另一个学生（参考模型裁判）也拿到同样的模糊说明，他同样会猜错，而且猜错的方向往往和第一个学生一样，因为他们是同一套套路训练出来的。所以「让第二个学生给第一个学生打分」不可靠：他们共享同一套盲区。

论文的机制对应是：生成器和参考模型都从同一份短描述出发，都会把「描述没说的权限」按惯例补成 owner-only，于是参考模型不会把生成合约的保守性检查判为错误——它自己也写了同样的检查。这就是为什么参考模型在植入错误上抓取率很高（94.3%），但在真实生成缺陷上只站在原始合约一边 31.6%：植入错误是「描述说了但做错了」，真实缺陷大多是「描述没说但做错了」，而描述没说的地方，参考模型和生成器犯的是同一个错。

这个类比也解释了为什么「生成前问几个问题」有效：它相当于在考试前让学生去问出题人几个关键问题，把「描述没说」的部分变成「描述说了」，于是生成器和裁判的共享盲区被打破。而生成后的安全改写之所以有害，是因为它相当于考完试后让另一个学生按「安全规范」改答案，结果把原本答对但不符合规范的部分也改掉了。

5. 方法 pipeline 举例

以论文附录 G 的 NFT key 合约为例，走一遍完整流程。

输入：一个 NFT key 合约的短描述，约 140 词，由 Gemini 2.5 Flash 从原始合约写出。描述说「管理员改变销售状态、把地址加入 gold list」，但原始合约实际上没有特权角色——任何账户都可以做这些操作。

第一步，一次性生成：GPT-5.4-mini 拿到短描述，按惯例实现了 owner-only 的销售状态切换和 gold list 管理。这一步的中间结果是：生成合约把「改变销售状态」和「加入 gold list」都限制为只有部署者能调用。

第二步，原七阶段流水线：解析器把描述转成 schema，生成器写 Solidity，LLM 审计器评级，严重度 medium 以上触发一次修复，然后加 ABI、MCP 和评分器。中间结果：它同样实现了 owner-only 的惯例读法，最终交易级保真度 22.4%。

第三步，提问式流水线：模拟客户端（GPT-5.4 读原始合约）回答十个清单问题。关键的是第 6 个问题「哪些操作限制给特定账户或角色」，答案是「没有操作限制给特权角色；任何账户都可以把地址加入 gold list、改变销售状态，并且只有自己的地址在 silver 或 gold list 上且销售开启时才能 mint」。这一步的中间结果是：生成器拿到这个答案后，不再添加 owner-only 限制。

第四步，生成与编译修复：生成器用「描述 + 问答记录」写合约，编译失败则修复。中间结果：合约实现了所有必需函数，行为与原始合约在可观察值上一致。

第五步，参考模型与差分检查：独立的 GPT-5.4 从「描述 + 问答记录 + ABI」写一个 Python 参考模型，与生成合约在 EVM 上跑差分。中间结果：如果出现分歧，把分歧点以盲选 A/B 形式给模拟客户端裁决。

第六步，精确重放评分：60 条序列、每条 8 步，用原始合约的签名和参数类型调用，比较结果和值变化。中间结果：提问式流水线的合约在每一个可观察结果和值上都与原始合约一致，但 22% 的步骤改变了一个它没有暴露的值，所以精确评分只给 77.6%，而不是 100%。对比一次性生成 41.8%、原流水线 22.4%。

这个例子同时展示了论文的两个核心论点：描述错误（说「管理员」但实际没有管理员）会被提问纠正；精确重放会惩罚「值变化不可观察」的遗漏，即使行为看起来全对。

6. 核心数学推导

论文的核心度量是交易级保真度（transaction-level fidelity）。原文公式在提取中部分损坏，但根据附录 C 的文字描述可以重建其定义逻辑。

设 S_c 为原始合约 c 在重放中产生的全部合约特定步骤——原始合约每个会改状态的函数各算一类，回退的步骤也在内，而且第一步出现分歧之后，后续步骤仍各自单独计分。这里不按「原始合约是否执行成功」筛分母：回退与回退一致同样算正确。对每个步骤 s ∈ S，用原始合约的签名、参数类型和附加以太值调用生成合约 g。若 g 没有该签名，该步骤无法执行，记为失败；若以太发给非 payable 函数，回退，记为失败。

一个步骤 s 对 g 正确，当且仅当两个条件同时成立。条件一：结果匹配，即 g(s) = c(s)，包括成功与回退的结果。条件二：若双方都成功，则对每一个观察值 o，其变化量相等，即 Δg(s, o) = Δc(s, o)，其中 o 遍历原始合约上可观察的至多 39 个 getter 和以太余额。若原始合约上某个值有非零变化但在 g 上不可观察，该步骤记为未验证，未验证步骤不计入正确。

交易级保真度定义为：对每个合约计算正确步骤数除以 S 的大小，得到该合约的正确步骤占比，然后对所有合约取平均。用公式写就是：

Fidelity = (1/∣C∣) · Σ_{c∈C} ( ∣{s∈S_c : g_c(s)=c(s) 且 ∀o, Δg_c(s,o)=Δc(s,o)}∣ / ∣S_c∣ )

其中 C 是合约集合，S_c 是合约 c 的全部合约特定步骤集（含回退步骤），g_c 是对应生成合约。这个公式在算的是：平均而言，生成合约在原始合约的全部合约特定步骤中（含回退步骤），有多大比例在结果和所有可观察值变化上都与原始合约一致。它把「函数缺失」「签名不匹配」「结果错误」「值变化错误」「值变化不可观察」全部计入失败，只把「结果和值变化都完全匹配」的步骤算正确。

另一个关键度量是严格侧选（strict side-picking）用于植入错误实验。对突变体 m 和暴露交易集 T_m，预言机 O 收集两个计数：s⁺_O(m) 是 O 与原始合约 c 一致的步数，s⁻_O(m) 是 O 与突变体 m 一致的步数。突变体被严格抓住当且仅当 s⁺_O(m) > s⁻_O(m)。这个公式在算的是：预言机在暴露交易上是否更频繁地站在原始合约一边而非突变体一边。它排除了「预言机两边都不同意」的硬币翻转式通过。

7. 实验设计

数据集：FSM-SCG 语料 21,976 个合约，过滤掉占位符标记（35.1%）、仅注释函数体（27.8%）、少于 40 行、编译失败、部署失败、无合约特定规则的合约。开发实验用 100 个，规模复现用 500 个持有合约。每个合约配一份约 140 词的短描述和一份约 1,700 词的完整需求文档，均由 Gemini 2.5 Flash 从原始合约写出。

基线：一次性生成（GPT-5.4-mini 直接拿短描述写合约）；原七阶段流水线（解析、生成、LLM 审计、严重度门控修复、ABI 代理、MCP 代理、LLM 评分）；提问式流水线（清单提问、生成、独立规则书、差分检查、盲选客户端裁决、只报告不改写的 Slither 安全报告）。参考模型覆盖 GPT-5.4、Claude Sonnet 5、Gemini 3.5 Flash 三个家族。

指标：交易级保真度（主指标）；通过所有采样测试的合约占比；能构建的合约占比；必需函数实现率；原始值变化可观察率；严格抓取率（植入错误实验）；误报率。

消融：信息维度——短描述、短描述加访谈答案、短描述加清单答案、完整文档；架构维度——一次性生成、原流水线、提问式流水线在相同信息下的对比；阶段维度——提取器、批评者、评审者、集成、规则书修复、客户端裁决各自的效果；问题预算——清单顺序、最佳优先顺序、自适应选择、自适应停止、自由追问。

实验能否支撑结论：主结论「信息在生成前丢失、生成后阶段作用很小」有因子比较支撑——同样信息下原流水线比一次性生成低 21.0 点，验证和裁决无答案时无效果（+0.1），有答案时仅 +0.5。安全改写有害有 94 个合约的前后对比和 341 个行为变化的 LLM 分类支撑。评测工具无效有植入错误审计支撑。

缺什么：没有人类作者参与，所有描述和答案都由 LLM 从原始合约生成，所以测的是「实现保真度」而非「作者意图」；安全分类标签来自 LLM 未人工验证；流水线的验证阶段在参考模型运行器修复前运行且未重跑，其 0.7 点收益是临时的；区间省略了生成间变异；36 个判据未做多重性校正。

8. take-aways

1. LLM 裁判不可信：读代码的 LLM 裁判在植入错误上抓到 65.0%，但误报 80%；要求可执行证明后抓取率降到 30%，误报降到 40%。用它当意图代理没有证据支撑——与三个人类评分者的聚合相关仅 r=0.15，区间 [-0.53, 0.71]。

1. 无描述对照暴露惯例捷径：只从函数名写出的参考模型能抓 87.5% 的植入错误，有完整描述只抓到 94.3%，差距仅 6.8 点。常规基准奖励的大部分是模型已知的 Solidity 惯例，不是对描述的理解。

1. 信息加在生成前，收益跨模型家族稳定：清单答案在 GPT-5.4-mini 上把保真度从 55.6% 提到 76.0%，在 Claude Sonnet 5 上从 56.1% 提到 75.1%（+19.0），在 Gemini 3.5 Flash 上从 51.8% 提到 74.5%（+22.7）。生成后的阶段最多加约 1 点。

1. 安全改写破坏需求行为：以完整需求为输入时，生成后保真度 95.3%，原流水线的审计-修复循环把 86 个合约改写后保真度降到 82.5%，损失 12.8 点；通过所有测试的合约占比从 62% 跌到 23%。341 个选出的行为变化中 80% 破坏了明确陈述的需求。

1. 三到五个好问题恢复大部分收益：按单问题价值排序，三个问题达到 68.2%、恢复十问题收益的约 62%，五个问题达到 70.7%、恢复约 74%。最有价值的问题是角色权限、失败条件和「任何不寻常之处」——正是描述审计发现最多矛盾的地方。

9. 最脆弱的假设

最脆弱的假设是：模拟客户端（GPT-5.4 读原始合约回答问题）是真实人类作者的可信代理。论文的整个「提问有效」结论都建立在这个模拟器上——清单答案的收益、问题排序、自适应代理的表现，全部来自这个模拟客户端的回答。

这个假设一倒，结论会崩在三个层面。第一，模拟客户端读的是原始合约，而保真度也是对照原始合约评分的，所以提问收益测的是「问题能从隐藏实现中恢复多少信息」，这是乐观上界——真实作者可能不确定、可能前后矛盾、可能主动提供更多信息，也可能答错。第二，描述和答案都从同一个原始合约生成，模拟器可能「泄露答案」——论文自己引用了用户模拟文献中的这个风险，并用「审计描述、按有无矛盾分组」做了检查，在 24 个无矛盾描述上清单收益仍有 +24.9 点，说明收益不完全依赖矛盾修正，但 24 个合约的样本量不足以区分两个子组（+6.1，区间 [-5.7, 18.3]）。第三，审计本身也是 LLM 判断，没有人工验证。

论文给出的证据：明确把模拟客户端标注为「乐观估计」而非「对人类作者的测量」；在局限性中承认没有人类参与；把「与人类作者的研究」列为未来工作第一项。这些是诚实的边界声明，但没有消除假设本身——如果真实人类作者的回答质量显著低于 GPT-5.4 读代码的回答，提问式流水线的实际收益会大幅缩水。

10. 一周最小复现

目标：复现「清单提问提升生成合约保真度」这一核心结论，以及「LLM 裁判误报率高」这一评测工具结论。

数据准备（第 1 天）：从论文发布的资源库取 20 个开发合约（有短描述、完整需求、清单答案和原始合约）。不需要重新生成描述，直接用发布的短描述和清单答案。确认本地有 Solidity 0.8.20 编译器和 py-evm。

评测工具审计（第 2 天）：取 5 个合约，手动植入 3 类错误——删掉一个 modifier、翻转一个比较、删掉一个 require。用 GPT-4 级别的模型当 LLM 裁判，让它读突变体和原始合约判断哪个对。记录抓取率和误报率。预期：抓取率不会超过 70%，误报率会很高。这一步验证「LLM 裁判不可信」。

生成对比（第 3-4 天）：用同一个生成模型（可用 GPT-4o-mini 或本地 7B 模型）跑两个条件——条件 A 只给短描述，条件 B 给短描述加清单答案。每个条件对 20 个合约各生成一次。编译失败的做一次编译修复。预期：条件 B 的保真度比条件 A 高 15 到 25 点。

精确重放评分（第 5 天）：对每个生成合约和原始合约，跑 30 条序列、每条 8 步（论文用 60 条，一周内可减半）。用原始合约的签名调用，比较结果和 getter 值变化。计算交易级保真度。这一步的关键是不要用共享接口评分——固定用原始合约的接口，缺失函数算失败。

预期指标：条件 A 保真度约 50-55%，条件 B 约 70-75%，差距约 20 点。如果差距小于 10 点，说明生成模型对清单答案的利用能力弱于论文的 GPT-5.4-mini，或者本地模型没有足够的 Solidity 先验。

资源：20 个合约、两个条件、每个条件一次生成，加上评分，24GB 显卡足够跑本地 7B 模型；如果用 API，token 成本在几十美元量级。不需要跑原七阶段流水线——那是论文的基线，不是核心结论的必要条件。

11. 反例设计

要推翻论文的核心主张「信息在生成前获取比生成后的任何阶段都重要」，设计如下实验。

实验：取 50 个合约，全部给完整需求文档（约 1,700 词，包含所有规则的精确值）。条件 A 是「生成前获取信息」——生成器直接拿完整文档写合约。条件 B 是「生成后恢复信息」——生成器只拿短描述写合约，然后运行一个强修复循环：用完整文档写一个参考模型，对生成合约和参考模型做差分，把每个分歧点反馈给生成器做针对性修复，最多迭代 5 轮。两个条件用同一个生成模型。

判据：如果条件 B 的最终保真度达到条件 A 的 95% 以上（即差距不超过 5 点），则论文的「生成后阶段最多加约 1 点」结论被推翻——它说明生成后的验证-修复循环在足够强的参考模型和足够多的迭代下，可以恢复大部分信息损失。论文自己的数据是：规则书引导的修复在完整需求下无效果（-0.2），但那是一轮修复且参考模型从同一份完整需求写出。如果多轮迭代、每轮把分歧点作为额外信息注入，效果可能不同。

为什么这个反例有杀伤力：论文的因子比较只测了「一次性生成 vs 原流水线 vs 提问式流水线」，没有测「强修复循环 vs 生成前信息」。如果强修复循环能追平生成前信息，那论文的实践建议「把信息放在生成前」就不再是唯一最优策略，而只是「在它测试的弱修复循环下」的结论。论文的参考模型在真实缺陷上只站原始合约一边 31.6%，但如果修复循环把「参考模型与生成合约的分歧」作为问题发给客户端裁决，而不是直接按参考模型改，信息恢复率可能大幅提高——论文的客户端裁决只加了 0.7 点，但那是在验证阶段运行器修复前跑的，且只跑了两轮。

12. 落地判断

能否用于「抢占式 GPU 自托管 27B 模型做多智能体脚手架」：能，但要分两层用。

评测层：论文的精确重放评分器可以直接用于你的场景。如果你的 27B 模型生成 Solidity 合约，你需要准备：原始合约或可信参考实现、一组交易序列、一个 EVM 运行环境。评分时固定用参考实现的接口，缺失函数算失败，值变化不可观察不计分。这一步不需要大模型，纯确定性计算，成本几乎为零。最大的价值是暴露你的 27B 模型在哪些合约上漏掉了必需函数——论文显示即使最好的流水线也只实现 85% 的必需函数。

生成层：论文的「清单提问」可以直接嵌入你的多智能体脚手架。在生成前，用一个 agent 向用户（或你的任务描述）问 10 个固定问题——权限、失败条件、金额上限、时间窗口、状态机、冻结列表、余额变化、费用、价格、「任何不寻常之处」。论文显示 3 到 5 个问题恢复 60-75% 的收益，最有价值的是权限和失败条件。27B 模型可能无法像 GPT-5.4 那样高质量地回答这些问题，但提问本身把「描述没说」变成「描述说了」，对任何规模的生成模型都有帮助。

成本量级：论文的提问式流水线每个合约约 3.8 次模型调用，中位墙钟时间 107 秒。27B 自托管模型在单张 24GB 卡上跑一次推理约几秒到几十秒，10 个清单问题加一次生成加一次参考模型，总推理时间在分钟级，token 成本为零（自托管）。500 个合约的规模，单卡一周可以跑完生成和评分。

最大的坑：不要在你的 27B 模型上复现论文的「安全审计-修复循环」。论文显示这个循环损失 12.8 点保真度，80% 的改写破坏了明确需求。如果你的脚手架里有安全 agent，让它报告发现但不改写代码，把每个发现转成给用户的问题。另一个坑是参考模型——27B 模型写的参考模型在真实缺陷上可能比 GPT-5.4 更不可靠，所以参考模型的分歧只能当「警报」发给用户裁决，不能当「错误」直接修复。