ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

解析 Zed 编辑预测评测样例:从 vscode--add-class-decorator 看懂 Edit History、Cursor Position 与 Expected Patch 的完整机制

2026/9/7 16:19:17 拓冰建站 浏览量
解析 Zed 编辑预测评测样例:从 vscode--add-class-decorator 看懂 Edit History、Cursor Position 与 Expected Patch 的完整机制 解析 Zed 编辑预测评测样例从 vscode--add-class-decorator 看懂 Edit History、Cursor Position 与 Expected Patch 的完整机制【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zed这篇指南以 Zed 编辑预测Edit Prediction / Zeta评测管线中的一个真实样例文件crates/edit_prediction_cli/evals/vscode--add-class-decorator.md为主体逐行拆解它的 TOML 前置元数据、三段编辑历史、光标定位标记与期望补丁四个组成部分并结合edit_prediction_cli、edit_prediction、edit_prediction_metrics等 crate 的源码说明ep命令行工具如何解析该样例、加载 VS Code 源码仓库的 git worktree、调用模型做预测最终计算 delta_chr_f、光标距离等评分指标。读完后你将掌握如何读懂乃至手写一份编辑预测评测样例以及如何用ep子命令对单个样例完成“预测—解析—打分”的完整闭环。一、这个文件是什么Zed 编辑预测的评测样例在 Zed 仓库中edit_prediction_cli是驱动编辑预测模型评估的 CLI 工具 crate其可执行命令名在 main.rs 中通过 clap 声明为ep。而evals/目录是内置评测数据集的存放位置其中的 vscode--add-class-decorator.md 是其中一个样例与 flask--add-test-function.md、tree-sitter--tuple-to-struct-field-access.md、zed--add-eprintln.md 等 18 个样例并列。文件名遵循“源仓库--编辑意图”的命名约定这个样例取材于微软 VS Code 仓库的某个历史提交编辑意图是“为类添加装饰器class decorator”。一个评测样例在内存中的完整形态由 example.rs 中的Example结构体定义约第 22 行它内嵌一个ExampleSpec样例规格即本文档的主体内容并附加运行期产物——prompt_inputs、prompt、predictions模型预测、score评分、qaLLM 评审结果等。本文档的 Markdown 文件只承载ExampleSpec部分其余字段在预测、打分流程中被逐步填充。二、样例文件的逐段解析下面完整还原 vscode--add-class-decorator.md 的结构。该文件由三部分构成TOML 前置元数据front matter、## Edit History代码块、## Cursor Position代码块和## Expected Patch代码块。2.1 前置元数据锁定源仓库与修订版本 repository_url https://github.com/microsoft/vscode revision 6f6e26fcdf0a7ca5084e0da284cd7a5b2d41ae4d \n包裹的 TOML 块是样例的 front matter。解析它的字段定义在 example_spec.rs 的FrontMatter结构体约第 118 行支持repository_url、revision、tags以及uncommitted_diff_requires_edit_history_rollback四个键其中前两个是本样例用到的必填信息repository_url样例所取自的源代码仓库本例为 microsoft/vscode。评测管线执行load-project步骤时会据此准备仓库并在 load_project.rs 的setup_worktree函数约第 261 行中把revision检出一个 git worktree——源码里可见git worktree prune、git worktree add -f 路径 分支、git reset --hard HEAD、git checkout revision等调用确保预测输入与当时开发者的真实代码环境逐字节一致revision精确到 commit 的完整 SHA。锁定版本意味着“Edit History 能干净地应用、Cursor Position 的文件内容可复现”这是整个评测可重复性的根基。worktree 的落盘位置由 example.rs 中RepoName::worktree_path()约第 208 行决定按“WORKTREES_DIR/owner/repo”组织例如本例会落在以microsoft/vscode命名的目录下。需要指出本样例的 front matter 没有声明tags或回滚标记——这些都是可选字段ExampleSpecexample_spec.rs 第 25 行起中除repository_url、revision外的多数字段均带#[serde(default)]或skip_serializing_if允许按需省略。2.2 Edit History铺垫“模式”的三段历史编辑## Edit History代码块记录的是“预测时刻之前、用户刚刚做过的编辑序列”它是编辑预测模型的核心理由模型要判断的正是“用户下一步大概率还做什么”。本样例的 Edit History 是一个三 hunk 的 unified diff全部作用于 VS Code 的 API 类型定义文件src/vs/workbench/api/common/extHostTypes.tsHunk 1约第 18 行处定义 ES5 类兼容工具函数--- a/src/vs/workbench/api/common/extHostTypes.ts b/src/vs/workbench/api/common/extHostTypes.ts -18,6 18,14 import type * as vscode from vscode; function es5ClassCompat(target: Function): any { ///ts-expect-error function _() { return Reflect.construct(target, arguments, this.constructor); } Object.defineProperty(_, name, Object.getOwnPropertyDescriptor(target, name)!); Object.setPrototypeOf(_, target); Object.setPrototypeOf(_.prototype, target.prototype); return _; } es5ClassCompat export class Disposable {Hunk 2约第 50 行处给Position类挂上装饰器 -50,6 58,7 export class Disposable { } } es5ClassCompat export class Position { static Min(...positions: Position[]): Position {Hunk 3约第 220 行处给Range类挂上同样的装饰器 -220,6 229,7 export class Position { } } es5ClassCompat export class Range { static isRange(thing: any): thing is vscode.Range {从编辑序列的结构看开发者在做一次典型的“重复性机械编辑”先写一个工具函数es5ClassCompat通过Reflect.construct、原型链复制等手段把 TypeScript class 包装成 ES5 兼容形态随后连续对Disposable、Position、Range三个类逐一添加es5ClassCompat装饰器。这正是编辑预测最擅长也最需要被评测的**复制型编辑copy edit**场景——模式已经重复三次用户明显还要继续往后续类上套。2.3 Cursor Position文件路径 光标行内标记## Cursor Position代码块的围栏语言标记本身就是光标所在文件的路径块内内容是文件片段的摘录excerpt其中嵌入光标标记src/vs/workbench/api/common/extHostTypes.ts Prepend 3 } export class TextEdit { // [CURSOR_POSITION] static isTextEdit(thing: any): thing is TextEdit { if (thing instanceof TextEdit) { return true; 两个细节值得注意围栏 info-string 即cursor_path。example_spec.rs 的to_markdown()约第 220-227 行明确以## Cursor Position标题加“以cursor_path为语言的代码块”写出该段from_markdown()反向解析时同样据此还原cursor_path与cursor_position两个字段。[CURSOR_POSITION]是标准光标标记。常量定义在 udiff.rs 第 88 行CURSOR_POSITION_MARKER [CURSOR_POSITION]另有行内标记INLINE_CURSOR_MARKER |user_cursor|用于行内光标。标记所在的空行位于export class TextEdit {与static isTextEdit之间——正是“下一个该加装饰器的位置”。把 2.2 与 2.3 合起来看这道题的完整语义是用户在TextEdit类定义处停下前文已对三个同类做过es5ClassCompat预测模型应当补上第四处。2.4 Expected Patch期望的预测输出--- a/src/vs/workbench/api/common/extHostTypes.ts b/src/vs/workbench/api/common/extHostTypes.ts -475,6 485,7 export enum EnvironmentVariableMutatorType { Prepend 3 } es5ClassCompat export class TextEdit { static isTextEdit(thing: any): thing is TextEdit {## Expected Patch是一个单 hunk 的 diff在export class TextEdit {前插入一行es5ClassCompat。这个补丁即“标准答案”ExampleSpec中对应expected_patches: VecString字段支持多段期望补丁本样例只有一段也没有## Rejected Patch该可选段用于存放被用户拒绝的错误预测常见于 DPO 训练数据。值得一提的是 hunk 头中的行号差异期望补丁的 -475,6 485,7 与 Edit History 的 -18,6 18,14 等行号相互独立——前者是补丁在原始文件中的绝对位置TextEdit 类位于 475 行附近后者是编辑发生时的位置。评测时score流程会用prepare_expected_patchesscore.rs 第 77 行调用把期望补丁应用到光标摘录文本上校验其可应用性因此 hunk 必须与revision处的真实文件内容严格对齐。三、样例如何被解析Markdown 到 ExampleSpecep读取输入时按扩展名分派example.rs 的read_example_files()第 215 行起支持.json单个Example、.jsonl每行一个、.md调用parse_markdown_example以及-表示 stdin本样例属于.md分支。若 spec 未显式命名样例名默认取文件主干名即vscode--add-class-decorator。Markdown 解析器ExampleSpec::from_markdown()位于 example_spec.rs 第 258 行起基于 pulldown_cmark 的事件流工作其识别的 H2 标题常量第 71-79 行为H2 标题映射字段本样例是否出现Reasoningreasoning否可选Uncommitted Diffuncommitted_diff否可选Recently Opened Files/Recently Viewed Filesrecently_opened_files/recently_viewed_files否可选Edit Historyedit_history是Cursor Positioncursor_pathcursor_position是Expected Patchexpected_patches是Rejected Patchrejected_patch否可选由此可以确认本样例刻意只保留“编辑历史 光标 期望补丁”这一最精简闭环没有附带未提交改动、最近打开文件等环境信息——模型仅凭编辑序列中的模式重复就能作答属于对“复制型编辑能力”的纯能力测试。解析器还内置了// User accepted prediction:特殊标记第 79 行ACCEPTED_PREDICTION_MARKER用于标注“该次编辑实际是模型预测被接受”的情形本样例未使用。to_markdown()与from_markdown()互为逆操作to_markdown见第 145 行起意味着评测管线随时可以把 JSONL 数据集转成本文这种单样例 Markdown 文件——ep的全局参数--markdown正是用于“按样例逐条输出 .md”main.rs 第 111-114 行evals/目录里的样例很可能就是这么生成的。四、从样例到分数ep 评测管线main.rs 第 217 行起的Command枚举列出了ep的全部子命令与本样例直接相关的处理链路是read → load-project → context → format-prompt → predict → parse-output → score → evalread把 .md/.json/.jsonl或 Snowflake 时间戳来源见INPUTS_HELP读入为Example列表可-o输出 JSONLload-project为每个样例创建 git worktree 并加载文件内容对应 2.1 节所述的setup_worktree流程注意 load_project.rs 第 269 行注释明确警告“多个 CLI 进程并发会损坏 worktree”跑批量评测时不宜多进程共享同一 worktree 根context收集预测上下文--type可重复/逗号分隔如--typeall,oracle-file缺省为 LSPContextArgs默认逻辑见 main.rs 第 141-149 行format-prompt为指定--provider渲染提示词字符串predict调用预测提供方--provider、--repetitions、--cache-only、--wait等参数见 main.rs 第 350 行起的PredictArgsparse-output把模型原始输出actual_output解析为 unified diffactual_patchscore计算得分。score.rs 的run_scoring()第 24 行起先保证已有预测再取prompt_inputs.cursor_excerpt作为原始文本用prepare_expected_patches校验期望补丁可应用对 teacher 类 provider 还会先从提示词中提取可编辑区域做坐标对齐随后对每条预测调用score_prediction并把 Edit History 作为“反转上下文”reversal_context一并参与评分eval在 predict score 之上做聚合支持--context-only只统计上下文覆盖率--related-context-limit缺省为EVAL_RELATED_CONTEXT_TOKENS_LIMIT 4000score.rs 第 22 行。最终每条预测得到一个PredictionScore字段定义在 prediction_score.rs 第 24 行起对本样例最有判别力的几项包括delta_chr_f及 tp/fp/fn、precision、recall、beta 变体预测补丁相对期望补丁在字符级别的 F 分数是“es5ClassCompat 这一行是否猜对”的核心指标exact_lines_tp/fp/fn逐行精确匹配的混淆计数cursor_distance与cursor_exact_match模型给出的编辑后光标位置与期望的偏差本例期望光标停在装饰器行附近braces_disbalance、inserted_tokens、deleted_tokens等辅助质量信号。此外ep还提供一批对维护此类数据集有用的全局参数main.rs 第 71-115 行--name按样例名过滤、--repo按仓库过滤、--limit/--offset分页、--max-parallelism默认 10、--group-by-repo同一仓库的样例集中处理对本例就是“所有 vscode-- 前缀样例共享 worktree 逻辑”、--failed keep|skip控制失败样例是否留在输出中。数据集侧还有split按 repository_url 分层切分、filter-languages按 cursor_path 扩展名过滤、synthesize/split-commit从 git 提交自动合成新样例等子命令与evals/目录的维护直接配套。五、实操跑通这个样例在当前仓库只读的前提下可以在具备 Rust 工具链与网络访问的环境ep需从repository_url检出 VS Code 源码属于仓库外部操作按以下方式使用该样例文件# 1. 仅解析把 Markdown 样例读成 JSONL验证格式与 front matter 正确 ep read crates/edit_prediction_cli/evals/vscode--add-class-decorator.md -o /tmp/example.jsonl # 2. 完整评测该样例需要配置模型提供方凭据provider 见 --provider 可选值 ep eval crates/edit_prediction_cli/evals/vscode--add-class-decorator.md --name vscode--add-class-decorator --provider providereval会串联 load-project检出6f6e26f…这个 commit 的 VS Code worktree、上下文收集、预测、解析与打分最后输出该样例的PredictionScore。若想只看数据集本身而不调模型ep read配合--markdown输出即可逐条核对样例内容--max-duplicates还能按光标位置去重避免同位置样例重复计入分数。六、小结这个样例教会我们什么vscode--add-class-decorator.md虽只有 70 余行却是一个编辑预测评测样例的“最小完备”形态完整体现了三层信息数据契约层front matter 锁定repository_urlrevision让历史编辑与文件内容可精确复现Markdown 各 H2 段落与ExampleSpec字段一一对应可被from_markdown/to_markdown无损往返任务语义层Edit History 里的三段es5ClassCompat构成重复模式Cursor Position 标记出TextEdit类定义后的空行Expected Patch 给出唯一的单行期望补丁——这是一道标准的复制型编辑copy edit考题评测闭环层ep管线的read → load-project → … → score将样例变成可执行的基准测试用 delta_chr_f、光标匹配等量化指标裁决模型表现。理解了这个样例的每一段也就理解了 Zed 编辑预测评测集的组织方式每一个evals/*.md都是“可复现的真实编辑时刻 一份标准答案”而ep工具链则是把它们变成可度量、可回归的评测手段。【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zed创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考