Zed 编辑预测评测样本解析从 tree-sitter 元组转 struct 定义示例看epeval 文件格式【免费下载链接】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 仓库中的评测样本 tree-sitter--tuple-to-struct-definition.md 为主体完整拆解 Zed 编辑预测Edit Prediction评测样本的 Markdown 格式规范front matter 元数据、Edit History 编辑历史、Cursor Position 光标标记语法、以及多解 Expected Patch 的设计意图并结合 crates/edit_prediction/src/example_spec.rs 与 crates/edit_prediction_cli/src/main.rs 的源码说明这些字段如何被解析、加载最终驱动ep命令完成预测与评分流水线。读完后你将能够独立编写、校验和运行这类评测样本。样本定位epCLI 的评测输入该文件位于 crates/edit_prediction_cli/evals/ 目录下。edit_prediction_cli是 Zed 内部用于开发、评测和迭代编辑预测模型即 Zeta 系列的命令行工具其可执行入口名为ep定义见 crates/edit_prediction_cli/Cargo.toml[[bin]] name ep path src/main.rsevals/目录下共收录 19 个样本命名遵循仓库名--任务名.md的约定例如flask--add-import-statement.md、zed--add-eprintln.md。其中围绕 tree-sitter 仓库的一组样本tree-sitter--tuple-to-struct-definition、tree-sitter--tuple-to-struct-destructuring、tree-sitter--tuple-to-struct-field-access、tree-sitter--tuple-to-struct-for-loop、tree-sitter--tuple-to-struct-literal、tree-sitter--if-let-to-match共同描述了一个真实的重构场景把Vec(PathBuf, OnceCellLanguage, OptionVecPathBuf)这类匿名元组改造为具名结构体LanguageEntry。本文聚焦其中的定义元——即模型需要在正确位置补出LanguageEntry的 struct 定义。Front matter仓库与版本锚点样本文件以分隔的 TOML 块开头完整内容为 repository_url gitgithub.com:tree-sitter/tree-sitter revision 24007727d42b4caceda3095ac685c463fae1ba1a 这两个字段把样本钉死在一个确定的上游代码状态上repository_url指定被测仓库revision指定精确的 commit。ep工具加载样本时会按仓库与 revision 创建 git worktreeep load-project子命令见 main.rs 中 Command 枚举从而还原出与真实用户编辑现场一致的缓冲区内容。解析侧对应的是 example_spec.rs 中的FrontMatter结构除repository_url、revision外还支持tags与uncommitted_diff_requires_edit_history_rollback两个可选字段。注意本样本的 front matter 只包含必需的两项其余字段均可缺省。Edit History让模型看见的重构上下文## Edit History小节记录光标编辑发生之前、编辑器内已发生的连续编辑即用户会话中的真实编辑流以 unified diff 的形式给出--- a/tree-sitter/crates/loader/src/loader.rs b/tree-sitter/crates/loader/src/loader.rs -604,7 604,7 pub struct Loader { pub parser_lib_path: PathBuf, - languages_by_id: Vec(PathBuf, OnceCellLanguage, OptionVecPathBuf), languages_by_id: VecLanguageEntry, language_configurations: VecLanguageConfigurationstatic, language_configuration_ids_by_file_type: HashMapString, Vecusize, language_configuration_in_current_path: Optionusize, --- a/tree-sitter/crates/loader/src/loader.rs b/tree-sitter/crates/loader/src/loader.rs -621,6 621,8 wasm_store: MutexOptiontree_sitter::WasmStore, } str pub struct CompileConfiga { pub src_path: a Path, pub header_paths: Veca Path,这段历史包含两个语义要点第一个 hunk显示用户已把Loader::languages_by_id的类型从匿名三元组改为VecLanguageEntry——此时LanguageEntry尚未定义编译器视角下是一个悬空类型引用第二个 hunk显示用户在pub struct CompileConfiga上方敲入了一行孤立的str——这正是一次被截获的中途输入用户正在补写struct LanguageEntry { ... }只输出了str前缀编辑预测即被触发。这个构造非常贴近真实使用场景预测模型不是凭空补全而是基于用户刚刚把元组替换成了具名类型 正在敲struct关键字这两个信号推断下一步应当产出一段完整的 struct 定义。这也解释了样本名为tuple-to-struct-definition的由来。Cursor Position光标片段的标记语法## Cursor Position小节用一个围栏代码块描述编辑发生瞬间的文件上下文。代码块的 info string反引号后的语言标注位是光标所在文件的相对路径块内是文件片段其中一行标记指示精确的行列位置tree-sitter/crates/loader/src/loader.rs sanitize_build: bool, force_rebuild: bool, #[cfg(feature wasm)] wasm_store: MutexOptiontree_sitter::WasmStore, } str // ^[CURSOR_POSITION] pub struct CompileConfiga { pub src_path: a Path, pub header_paths: Veca Path, pub parser_path: PathBuf, pub scanner_path: OptionPathBuf, pub external_files: Optiona [PathBuf], 解析逻辑在 ExampleSpec::cursor_excerpt 中标记规则有两条^形式光标位于标记行的上一行列位置等于^在标记行中的字符下标。本例中// ^[CURSOR_POSITION]的^位于第 3 列对应上一行str末尾第 3 列即光标停在用户刚敲完的str之后形式当光标列小于注释前缀长度时用表示光标位于该行第一个非空白字符处行内标记|user_cursor|直接内嵌在文本流中不占用独立标记行解析时优先于上述两种形式同文件中的cursor_excerpt首段实现。片段本身在构建 prompt 前会经过cursor_excerpt()剥除标记行还原为纯文件内容 光标字节偏移因此标记只是人类可读的序列化形式。Expected Patch四个并行的可接受解## Expected Patch小节是评分基准。该样本给出了4 个围栏 diff 块每一个都是一种算对的预测输出。四者共同的骨架是把触发行的-str替换为LanguageEntry定义解法一推荐字段名external_files--- a/tree-sitter/crates/loader/src/loader.rs b/tree-sitter/crates/loader/src/loader.rs -621,6 621,8 wasm_store: MutexOptiontree_sitter::WasmStore, } -str struct LanguageEntry { path: PathBuf, language: OnceCellLanguage, external_files: OptionVecPathBuf, } pub struct CompileConfiga { pub src_path: a Path, pub header_paths: Veca Path,解法二字段名dependencies--- a/tree-sitter/crates/loader/src/loader.rs b/tree-sitter/crates/loader/src/loader.rs -621,6 621,8 wasm_store: MutexOptiontree_sitter::WasmStore, } -str struct LanguageEntry { path: PathBuf, language: OnceCellLanguage, dependencies: OptionVecPathBuf, } pub struct CompileConfiga { pub src_path: a Path, pub header_paths: Veca Path,解法三字段名extra_files--- a/tree-sitter/crates/loader/src/loader.rs b/tree-sitter/crates/loader/src/loader.rs -621,6 621,8 wasm_store: MutexOptiontree_sitter::WasmStore, } -str struct LanguageEntry { path: PathBuf, language: OnceCellLanguage, extra_files: OptionVecPathBuf, } pub struct CompileConfiga { pub src_path: a Path, pub header_paths: Veca Path,解法四元组结构体写法零字段名歧义--- a/tree-sitter/crates/loader/src/loader.rs b/tree-sitter/crates/loader/src/loader.rs -621,6 621,8 wasm_store: MutexOptiontree_sitter::WasmStore, } -str struct LanguageEntry(PathBuf, OnceCellLanguage, OptionVecPathBuf); pub struct CompileConfiga { pub src_path: a Path, pub header_paths: Veca Path,多解设计是这个 eval 格式的刻意特性ExampleSpec::expected_patches的类型是VecString解析器会把## Expected Patch下的每个代码块依次 push 进去from_markdown 中 ExpectedPatch 分支。从评分侧的源码结构看一次预测输出只需命中其中任一可接受补丁即通过——因为第三个字段该叫什么在编辑现场是不可唯一判定的external_files贴合 tree-sitter 源码中外部扫描器文件的语义而dependencies、extra_files、匿名元组写法同样自洽。若只收录单一答案会把大量语义正确的预测误判为失败稀释评测信号。这种一个编辑现场、多个等价解的标注方式对于评估模型的泛化补全能力比单答案精确匹配更合理。对比同族的 tree-sitter--tuple-to-struct-destructuring.md 可以看到同一重构的对偶样本那边假设 struct 定义已经存在要求模型把let (path, language, externals) self.languages_by_id[id]改写为结构体解构。两个样本共享同一revision分别考察定义与使用两侧——这是评测集按真实 PR 的多步编辑拆分的典型做法。源码视角从 Markdown 到Example对象样本从文件到可运行对象的完整链路是入口分发。read_example_files 按扩展名分派.json直接反序列化.jsonl逐行反序列化.md走parse_markdown_example-表示 stdin。Markdown 解析。ExampleSpec::from_markdown 先用pulldown_cmark定位包裹的 front matterTOML 反序列化为FrontMatter再按 H2 标题切换到对应解析状态机UncommittedDiff、EditHistory、CursorPosition、ExpectedPatch、RejectedPatch等H1 标题作为样本名缺省时由文件名主干兜底example.rs 中 name 的默认化逻辑。光标还原。CursorPosition分支记录代码块 info string 为cursor_path、块文本为cursor_position本例中即tree-sitter/crates/loader/src/loader.rs与含// ^[CURSOR_POSITION]的片段。组装 Example。parse_markdown_example 将ExampleSpec包装进Example附带空的predictions与score列表等待后续流水线填充。ExampleSpec的完整字段集还包括本样本未使用的部分reasoning标注者对意图的说明、uncommitted_diff工作区未提交改动、recently_opened_files/recently_viewed_files近期文件列表支持路径\t偏移的行内光标记录、rejected_patchDPO 负例等均见 ExampleSpec 定义。此外Edit History 中还支持// User accepted prediction:行内标记用于在编辑流中标记该次编辑是用户接受的预测结果解析测试用例本样本未使用。如何运行这个样本ep的子命令覆盖了样本的完整生命周期Command 枚举read读取/规范化、load-project按 front matter 建 worktree 加载文件、context收集相关上下文、format-prompt生成模型 prompt、predict调用预测提供方、parse-output把原始输出解析为 unified diff、score对比实际与期望补丁打分、eval聚合评分。针对本样本的典型用法命令形式取自 main.rs 的 INPUTS_HELP# 读取并校验 evals 目录下的 Markdown 样本 ep read crates/edit_prediction_cli/evals/tree-sitter--tuple-to-struct-definition.md -o out.jsonl # 按名称过滤单个样本运行评测 ep eval crates/edit_prediction_cli/evals/tree-sitter--tuple-to-struct-definition.md --name tree-sitter--tuple-to-struct-definition # 以 Markdown 形式写回每个样本一个 .md 文件便于人工复核预测结果 ep predict examples.jsonl --markdown -o out_dir/全局参数--limit、--offset、--name、--repo、--max-duplicates、--failed等可用于裁剪与去重样本集EpArgs 定义。运行load-project需要能够访问 front matter 中声明的repository_url本例为 tree-sitter 的 SSH 地址并检出到revision指定的 commit这是样本可复现性的前提若环境无法克隆该仓库样本只能做格式层面的读取与校验。小结这份看似只有百余行的样本文件完整体现了 Zed 编辑预测评测的四个设计点版本锚定front matter 锁定仓库与 commit、意图可溯Edit History 呈现触发编辑之前的用户动作序列、位置精确^[CURSOR_POSITION]/[CURSOR_POSITION]/|user_cursor|三种标记覆盖不同缩进与行内场景由cursor_excerpt()统一还原为字节偏移、多解宽容expected_patches向量承载多个语义等价的可接受补丁。围绕 tuple-to-struct 重构拆分的六个同族样本进一步说明评测集以一个真实 PR 的多个编辑点为粒度组织既考察定义补全也考察使用侧改写构成对编辑预测模型较完整的回归面。【免费下载链接】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），仅供参考