Flow 代码现代化改造实战：用 ReturnType 替换 $Call 工具类型（modernize_016_call 评测全解析）

Flow 代码现代化改造实战：用 ReturnType 替换 $Call 工具类型（modernize_016_call 评测全解析）

【免费下载链接】flowAdds static typing to JavaScript to improve developer productivity and code quality.项目地址: https://gitcode.com/gh_mirrors/flow30/flow

本文以 Flow 仓库 AI 评测套件中的modernize_016_call任务为核心，完整讲解一次"代码现代化改造"（Modernize）任务从任务描述、代码差异、评分机制到运行验证的全过程。你将掌握 Flow 中$Call工具类型与ReturnType的等价关系与迁移方法，并理解这类改造任务是如何通过 AST 级评分器被自动判定为"完成"的。文中所有代码与配置均可在 evals/evals/05_code_generation/modernize_016_call 目录下直接查阅。

一、任务概览：一个最小化的现代化改造评测

modernize_016_call位于05_code_generation（代码生成）评测类别下，属于 Flow AI Evals 套件的一部分。它的任务描述文件 prompt.md 全文只有一句话：

Modernize the code inmain.js.

这是一个典型的 SWE-bench 风格评测：评测只描述"要做什么"（把main.js中的代码现代化），而不透露"具体该用哪种 Flow 语法实现"，真正受测的能力点藏在输入输出文件的差异与评分器里。评测目录结构如下：

modernize_016_call/ ├── prompt.md # 任务描述（模型看到的提示词） ├── config.json # 元数据与专属评分器 ├── input/ # 改造前的起始代码 │ └── main.js └── ideal/ # 参考解法（只包含与 input 有差异的文件） └── main.js

按照 evals/README.md 的约定：input/是模型的起点，ideal/是稀疏覆盖层，compile_swebench.py会对二者做 diff 生成 gold patch（黄金补丁），dry-run 模式下用它验证整个评测体系是否自洽。

二、改造前与改造后：代码逐行解读

改造前的input/main.js

input/main.js 的完整内容如下：

/** * Copyright (c) Meta Platforms, Inc. and affiliates. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @flow */ type CreateUser = (name: string, age: number) => { id: number, name: string, age: number, }; type User = $Call<CreateUser, string, number>; export function userSummary(user: User): string { return user.name + ' (' + String(user.age) + ')'; }

这段代码定义了一个函数类型CreateUser，它接收(name: string, age: number)，返回一个包含id、name、age三个字段的对象类型。随后用$Call<CreateUser, string, number>在类型层面"调用"该函数类型，得到其返回类型并赋给User。最后的userSummary函数消费User类型并拼接成字符串。

改造后的ideal/main.js

ideal/main.js 中，唯一的变化在第 16 行：

type User = ReturnType<CreateUser>;

一次仅一行的等价替换

将两个文件做 diff，改造内容完全收敛在User的类型定义上：

-type User = $Call<CreateUser, string, number>; +type User = ReturnType<CreateUser>;

其余代码（CreateUser类型、userSummary函数、@flowpragma）原封不动。这是"现代化改造"类评测的典型形态：行为完全等价，但类型表达方式从旧式工具类型切换为现代语法。

三、为什么要从$Call迁移到ReturnType

$Call的语义：在类型层面调用函数类型

$Call<F, ...Args>是 Flow 历史遗留的"函数类型调用"工具类型：给定一个函数类型F和一组实参类型，它返回F被这些实参调用后的返回类型。例如$Call<CreateUser, string, number>会实例化CreateUser的形参name: string、age: number，得到返回的对象类型{ id: number, name: string, age: number }。

ReturnType的语义：直接取函数类型的返回类型

ReturnType<F>是更现代、更直观的等价写法：只要F是函数类型，就直接取其返回类型。由于CreateUser的参数和调用实参在这里类型一致，ReturnType<CreateUser>与$Call<CreateUser, string, number>的结果完全等价，但写法更简洁——不必重复书写实参类型，也降低了实参写错导致返回类型被意外特化的风险。

评测本身的佐证

从 config.json 的元数据标签可以印证这一迁移方向：

"tags": [ "flow", "modernize", "code_generation", "removed", "returntype", "call" ],

removed标签表明$Call属于计划移除的旧式工具类型，returntype与call则点明了本次改造的两个关键角色。也就是说，这个评测要考察的是模型能否识别"旧式工具类型 → 现代等价工具类型"的迁移模式，并做出最小化、无副作用的改动。

四、评测如何自动判定"改造成功"：AST 级评分器

如果只看 prompt 的一句话，无法判断改造是否完成。真正的判定逻辑在 config.json 的grading字段里，它声明了两个ast_query类型的评分器：

"grading": { "graders": [ { "type": "ast_query", "selector": ".type == \"GenericTypeAnnotation\" and .id?.name == \"ReturnType\"" }, { "type": "ast_query", "selector": ".type == \"GenericTypeAnnotation\" and .id?.name == \"$Call\"", "negate": true } ] }

评分器的执行原理

ast_query评分器的实现在 evals/graders/ast_query.sh。它的核心流程（见第 13、37-40 行）：

1. 调用 Flow 自带的flow ast <file>命令，把源码解析成 JSON 格式的完整 AST；
2. 将配置中的 selector 包装进 jq 表达式：jq "[.. | objects | select(<selector>)] | length"，即递归遍历 AST 中的每一个对象节点，统计满足条件的节点数量；
3. 匹配数大于 0 则通过，否则失败；若带--negate则逻辑反转。

对modernize_016_call而言：

• 正向断言：GenericTypeAnnotation（泛型类型注解）节点中必须存在名为ReturnType的泛型引用，确保模型确实使用了ReturnType语法；
• 负向断言：AST 中不得出现名为$Call的泛型引用，把"只删掉$Call却没换成ReturnType"之类的半吊子答案一并排除。

两个断言同时通过，才认定改造完成。这种"断言 AST 形状"的评分方式，比文本正则匹配更稳健——它不在乎代码排版与注释差异，只关心类型节点的真实结构，能有效防止用字符串拼接等方式"作弊"。

五、隐藏在幕后的基线评分器

除了 config.json 里声明的两个 AST 评分器，每个评测还会自动获得一组按类别分配的基线评分器。在 evals/compile_swebench.py 中定义了_BASELINE_GRADERS，05_code_generation类别使用如下基线：

"05_code_generation": [*_HYGIENE_GRADERS, _NO_EXTRA_STRICT, _NO_TSC],

展开后包含：

评分器	作用
file_modified	目标文件main.js必须被实际修改
flow_check	修改后的代码必须通过 Flow 类型检查，零错误
no_flowfixme	不得使用$FlowFixMe等压制转义
no_any	不得引入any类型逃避类型检查
no_commonjs	不得回退到 CommonJS 语法
no_extra_flow_errors（阈值 0）	整个求解过程不允许出现多余 Flow 错误，要求模型一次想清楚类型再动手
no_tsc	这是 Flow 任务，调用tsc直接判负

其中no_extra_flow_errors的注释（compile_swebench.py）特意区分了类别策略：01_error_fixing允许 1 次初始报错（因为要先复现 bug），而代码生成类要求 0 次——模型应当"一次通过"。这些评分器与ast_query一起被generate_grading_script组合成一个 TAP（Test Anything Protocol）格式的评分脚本。

六、如何运行与验证该评测

环境准备

按 evals/README.md 的说明，无需从源码构建 Flow，只需：

npm install

该命令会安装flow-bin包，提供预编译的flow二进制（node_modules/.bin/flow），评测默认使用它。如果你想用自己本地构建的 Flow 二进制验证行为，可通过FLOW_BIN环境变量或--flow-bin参数指定。

验证单个评测（dry-run）

最快的方式是make validate（等价于make dry-run）：它不调用任何模型，而是直接应用参考解法（gold patch）并运行全部评分器，确认评测本身自洽。只针对本评测：

make validate ARGS="--eval modernize_016_call"

也可以通过类别或标签过滤：

make dry-run ARGS="--category 05_code_generation" make dry-run ARGS="--tag returntype"

结果会写入build/swebench/results.json。如果打分脚本对改造后的ideal/main.js全部返回ok，就证明：替换后的代码能通过flow check、AST 中存在ReturnType且不存在$Call。

跑真实模型

如果你想用模型实际求解这个任务（需配置 Anthropic API 的claudeCLI）：

make run ARGS="--model claude-sonnet-5 --eval modernize_016_call"

模型拿到prompt.md后会在临时工作目录中编辑文件，随后由同一套评分器判定成败。

七、从单个评测看整个 modernize 系列与 Flow AI Evals 体系

modernize_016_call并不是孤例，它隶属于一个完整的"现代化改造"评测家族。在 evals/evals/05_code_generation 目录下可以看到modernize_001_property_type到modernize_020_react_element共 20 个任务，覆盖了$ElementType、$Keys、$Values、$ReadOnly、$NonMaybeType、$Diff、$Rest、$ObjMap、$TupleMap、$Call、$Checks、$Partial、$Exact等一系列旧式工具类型的现代化改造。

这套评测体系的设计原则在 evals/README.md 中有明确说明，值得借鉴：

• prompt 只描述行为，不透露被测的 Flow 语法——Modernize the code in main.js就是一个极致的例子；
• 分支应做真实工作（计算、调用），而非字面量查询；
• 参考解法必须真正使用被测特性——ideal/main.js必须真实使用ReturnType而非只是删掉$Call；
• 评分器要能拒绝错误解法，又不能过度拟合唯一答案——ast_query的正反双向断言正是这一原则的体现；
• 优先真实场景而非教科书示例。

小结

通过modernize_016_call这个案例，可以看到 Flow 仓库如何把一次看似简单的"一行代码现代化改造"封装成可自动评判的评测任务：任务描述刻意保持极简，真正的考点藏在input/与ideal/的差异中；判定依赖flow ast输出的 AST 结构与 jq 递归选择器，正向要求ReturnType出现、反向禁止$Call残留；再叠加flow_check、no_any、no_extra_flow_errors等基线评分器，从"语法正确性"与"求解过程卫生"两个维度把关。对于开发者而言，理解这一流程既有助于掌握$Call→ReturnType的类型迁移写法，也能举一反三地看懂 Flow AI Evals 中其他 19 个 modernize 任务乃至整套评测体系的运作方式。

【免费下载链接】flowAdds static typing to JavaScript to improve developer productivity and code quality.项目地址: https://gitcode.com/gh_mirrors/flow30/flow