Zed Zeta 编辑预测评测样本详解以 vscode--add-interface-method.md 为例【免费下载链接】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本文以 crates/edit_prediction_cli/evals/vscode--add-interface-method.md 这一评测样本为核心完整讲解 Zed 编辑器编辑预测模型Zeta评测样本的 Markdown 格式规范——包括 front matter、Edit History、Cursor Position、Expected Patch 四个核心部分的语义与写法并结合 example_spec.rs、example.rs 等源码解析该格式如何被解析、校验并用于模型预测与打分。读完后你可以独立读懂并手写一个合法的 Zeta 编辑预测评测样本。一、文件定位这是 Zeta 编辑预测模型的评测样本Zed 内置的 Zeta 编辑预测edit prediction功能会在你编码时预测下一步编辑。围绕它仓库维护了一套评测evals体系模型针对给定编辑历史 当前缓冲区 光标位置预测一个补丁patch再与人工标注的期望补丁比对打分。该体系包含两层crates/edit_prediction/核心预测库定义了样本规格ExampleSpec、光标标记、diff 编解码等crates/edit_prediction_cli/评测命令行工具从源码结构看提供 predict、score、retrieve_context、distill 等子命令见 src/main.rs、src/predict.rs、src/score.rs 等模块文件其 evals/ 目录存放 19 个评测样本覆盖 VS Code、tree-sitter、Flask、Zed 自身等真实仓库的场景。vscode--add-interface-method.md正是其中取自 VS Code 仓库的一次真实编辑场景文件名遵循仓库名--场景描述的命名习惯对应 ExampleSpec::filename 中的文件名净化逻辑。二、样本整体结构front matter 与四个部分该文件完整结构如下按原文顺序包裹的 TOML front matter声明样本来自哪个仓库、哪个提交## Edit History一段 unified diff记录光标动作发生前的连续编辑历史## Cursor Position一个以文件路径为 fence info 的代码块内含[CURSOR_POSITION]光标标记## Expected Patch模型应当预测出的 diff 补丁。2.1 front matter锚定评测复现点文件开头是 repository_url https://github.com/microsoft/vscode revision b64eaf598008e2d600a81d846108f72cb37b48e2 它告诉评测工具本样本基于 microsoft/vscode 仓库的特定提交快照。解析时这段 front matter 被提取为FrontMatter定义于 example_spec.rs除repository_url、revision外还支持可选的tags与uncommitted_diff_requires_edit_history_rollback字段。配套地Example::repo_name 会从repository_url中解析出 owner 与仓库名同时支持git与http两种形式RepoName::worktree_path 则据此把样本映射到本地 git worktree 目录保证评测时能检出到完全一致的仓库状态。[CURSOR_POSITION]、|user_cursor|等常量定义在 crates/zeta_prompt/src/udiff.rs。2.2 Edit History编辑历史 diffEdit History部分是一个diff代码块记录了模型预测前开发者刚刚做的一系列编辑。本样本的历史共 4 个文件文件编辑内容src/vs/platform/window/electron-main/window.ts在ICodeWindow接口中新增onDidTriggerSystemContextMenu: Event{ x: number; y: number }只读属性src/vs/platform/windows/electron-main/window.ts在CodeWindow类中新增对应私有Emitter与只读事件成员src/vs/platform/windows/electron-main/windows.ts在IWindowsMainService接口中新增onDidTriggerSystemContextMenu: Event{ window: ICodeWindow; x: number; y: number }src/vs/platform/windows/electron-main/windowsMainService.ts在WindowsMainService实现类中新增对应的Emitter与只读事件成员这段历史的语义是开发者正在给系统右键菜单触发事件打通从窗口到窗口服务层的转发链路。接口先改、实现跟上这是编辑预测最需要续写的典型场景。解析侧Edit History代码块会被累积拼接进ExampleSpec.edit_history字段from_markdown 中 Section::EditHistory 分支。值得注意的是历史块之间还允许出现// User accepted prediction:这样的行级标记常量ACCEPTED_PREDICTION_MARKER见 example_spec.rs用于声明这一段编辑来自用户接受的模型预测解析器检测到标记后的下一个 diff 块会在其前面重新插入该标记行测试 test_from_markdown_accepted_prediction_marker 验证了这一往返行为。此外ExampleSpec还支持本样本未使用的可选部分见 to_markdownReasoning标注者推理说明、Uncommitted Diff未提交改动、Recently Opened Files/Recently Viewed Files最近打开/浏览文件列表每行路径\t光标偏移格式、Rejected Patch用于 DPO 的拒绝样本。2.3 Cursor Position光标位置的编码约定Cursor Position部分的写法## Cursor Position src/vs/platform/windows/test/electron-main/windowsFinder.test.ts function createTestCodeWindow(options: { lastFocusTime: number; openedFolderUri?: URI; openedWorkspace?: IWorkspaceIdentifier }): ICodeWindow { return new class implements ICodeWindow { onWillLoad: EventILoadEvent Event.None; onDidSignalReady: Eventvoid Event.None; // [CURSOR_POSITION] onDidClose: Eventvoid Event.None; onDidDestroy: Eventvoid Event.None; whenClosedOrLoaded: Promisevoid Promise.resolve(); id: number -1; 格式要点有三代码块的 fence info 字符串就是光标所在文件的路径。解析器据此填充spec.cursor_pathfrom_markdown 中 Section::CursorPosition 分支[CURSOR_POSITION]标记位于光标下一行其上方注释中的符号指明光标列^光标列就是^字符所在列向上指向光标光标位于该行第一个非空白字符处当光标列比注释前缀还靠左时set_cursor_excerpt会自动退化为这种格式。标记行本身不是文件内容cursor_excerpt 会从摘录中剔除整行标记行再用标记行上方一行的行首 标记列计算光标在摘录内的字节偏移返回(摘录文本, 光标偏移)供构建预测 prompt。本样本中// [CURSOR_POSITION]使用形式语义是光标位于下一行onDidClose: ...行首缩进之前——即开发者正准备在该处插入一行代码。这套^/标记与偏移计算的往返正确性由 test_cursor_excerpt_with_caret 覆盖含行尾、文件末尾无换行等边界而较新的内联标记|user_cursor|直接写在摘录文本中则由 test_cursor_excerpt_with_inline_marker 验证两种标记都优先于注释行形式被检测cursor_excerpt先查INLINE_CURSOR_MARKER。如果Cursor Position部分缺失或为空from_markdown会直接报错Missing cursor position codeblockexample_spec.rs——这是格式上的硬性要求。2.4 Expected Patch期望的模型输出## Expected Patch diff --- a/src/vs/platform/windows/test/electron-main/windowsFinder.test.ts b/src/vs/platform/windows/test/electron-main/windowsFinder.test.ts -7,60 7,61 import * as assert from assert; function createTestCodeWindow(options: { lastFocusTime: number; openedFolderUri?: URI; openedWorkspace?: IWorkspaceIdentifier }): ICodeWindow { return new class implements ICodeWindow { onWillLoad: EventILoadEvent Event.None; onDidTriggerSystemContextMenu: Event{ x: number; y: number } Event.None; onDidSignalReady: Eventvoid Event.None; onDidClose: Eventvoid Event.None; onDidDestroy: Eventvoid Event.None; whenClosedOrLoaded: Promisevoid Promise.resolve(); id: number -1; 期望补丁只有一处新增在测试用的匿名ICodeWindow实现中补上onDidTriggerSystemContextMenu: Event{ x: number; y: number } Event.None;与 Edit History 中接口新增的成员一一对应匿名类必须实现接口的全部成员否则类型检查失败。这构成了一个干净的单行插入任务类型签名来自历史 diff插入位置由光标锚定。Expected Patch部分允许出现多个 diff 代码块解析时依次推入spec.expected_patchesSection::ExpectedPatch 分支。若补丁中还内嵌了|user_cursor|标记expected_patches_with_cursor_positions 会把它拆成干净补丁 新文本中的光标偏移供打分时同时比较编辑内容与新光标落点编码/解码的幂等性由 test_encode_cursor_in_patch_is_idempotent 保证。三、从源码看这个 .md 是如何被消费的评测 CLI 读取样本的入口是 read_example_files它按扩展名分派.json/.jsonl直接反序列化为Example结构Example 在ExampleSpec基础上平铺了prompt、predictions、score、qa等运行时字段因此 JSON 形式的样本还能承载模型的预测结果与打分结果形成输入 输出 分数一体的评测记录.md走 parse_markdown_example →ExampleSpec::from_markdown得到一个尚未运行的纯规格样本predictions、score等字段为空其他扩展名直接 panic 报错。ExampleSpec的完整字段定义example_spec.rs还包括human_feedback、telemetry来自生产遥测的被拒预测来源信息、rating等说明这套 Markdown 格式不仅是本地手写样本的格式也是从真实编辑会话中导出、再回流评测的通用载体——to_markdown/from_markdown构成可往返的序列化对。from_markdown使用 pulldown_cmark 事件流解析H2 标题切换当前 sectionfenced code 块按当前 section 归属标题层级受严格约束H4 以下直接报错缩进代码块同样报错保证样本文件只能是受控格式。四、这个样本考察的预测能力把三部分合起来样本对模型提出的任务是从多文件编辑历史中抽象意图历史里 4 个文件都在做同一件事——为onDidTriggerSystemContextMenu事件逐层接口声明 → 实现类 → 服务接口 → 服务实现地补全成员识别遗漏点测试文件中的匿名ICodeWindow实现类是这次接口扩展的唯一漏改点在光标锚定的精确位置生成类型签名完全一致的插入行Event{ x: number; y: number }泛型参数必须与接口声明一致且默认值为Event.None与该测试文件中其他事件成员的写法保持一致。这类接口新增成员后同步补全所有实现的场景是编辑预测高价值用例之一仓库中同目录的 vscode--add-async-and-await.md、vscode--add-class-decorator.md、vscode--log-object-property.md 等样本考察了类似的多步续写能力可对照阅读。五、复现与运行要点样本解析与预测的关联通过repository_url revision完成评测工具按 RepoName::worktree_path 在统一 worktree 目录下检出对应仓库版本保证Edit History中 diff 的上下文路径与Cursor Position中的路径在快照内真实存在书写新样本时最小合法结构即front matter Edit History可为空写作(No edit history)语义 Cursor Position必须有路径 fence 与[CURSOR_POSITION]标记 Expected Patch其余部分按 ExampleSpec 字段 按需添加解析失败点集中在三处缺少Cursor Position代码块、标记行缺少^或cursor_excerpt报cursor position marker line must contain ^ or before [CURSOR_POSITION]、以及不合法的标题层级或缩进代码块编写样本时可据此自测格式。这套样本格式的设计取向值得借鉴用纯文本 Markdown 承载上下文快照 光标 期望编辑三元组既可人工评审、可 diff 协作又能被from_markdown严格解析回结构化规格使编辑预测的评测数据与代码库一起版本化管理。【免费下载链接】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），仅供参考