尧图网页设计 
Zed 编辑预测评测样例evals格式深度解析从 hello-world 改名样例看epCLI 的数据规范【免费下载链接】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本文以 hello-world--rename-accepted-group-by.md 这一评测样例文件为主线完整拆解 Zed 编辑预测Edit Prediction / Zeta评测数据的 Markdown 格式TOML front matter、Edit History 中的用户接受预测标记、[CURSOR_POSITION]光标注释的列定位语义以及 Expected Patch 的游标编码方式并结合 example_spec.rs 与 example.rs 的解析实现说明如何用 edit_prediction_cli 的ep命令驱动这条评测链路。读完后你可以独立编写、阅读和运行 Zed 的编辑预测评测样例。1. 这个样例文件在仓库中的位置与作用该文件位于 crates/edit_prediction_cli/evals/ 目录下是 Zed 编辑预测模型的评测样例之一。同一目录中还有来自 flask、tree-sitter、vscode、zed 等仓库的样例如 flask--rename-accepted-prediction.md、tree-sitter--tuple-to-struct-definition.md命名遵循仓库名--场景描述.md的约定。文件名本身就是样例名解析入口read_example_filesexample.rs在读入.md文件后若spec.name为空就直接取文件主名去掉扩展名的部分作为样例名md { let mut example parse_markdown_example(content).unwrap(); if example.spec.name.is_empty() { example.spec.name filename; } examples.push(example); }也就是说hello-world--rename-accepted-group-by这个文件名精确表达了该样例测试的语义在 hello-world 仓库中用户先接受了一次自动补全随后对补全出的函数做改名模型应当能预测出连带修改函数体内引用的完整重命名。2. 样例全文结构front matter、编辑历史、光标与期望补丁下面逐段解析该样例文件的真实内容与仓库文件完全一致。2.1 TOML front matter锚定到确定性的仓库状态 repository_url https://github.com/octocat/hello-world revision 7fd1a60b01f91b314f59955a4e4d4e80d8edf11d front matter 用定界内部是 TOML。解析器ExampleSpec::from_markdownexample_spec.rs会先strip_prefix(\n)取出 front matter 并用toml::from_str::FrontMatter反序列化可识别的字段包括字段含义repository_url样例所锚定的仓库地址。从源码结构看repo_name()example.rs会同时解析gitgithub.com:owner/repo.git与https://github.com/owner/repo.git两种形式并据此推导 worktree 缓存路径owner/reporevision固定到某个提交哈希保证评测可复现tags可选标签数组可选字段省略时为空uncommitted_diff_requires_edit_history_rollback可选布尔值控制加载Uncommitted Diff章节时是否需要回滚编辑历史可选字段省略时为 false该样例只使用了repository_url与revision两个必填字段。2.2 Edit History三段 diff 讲述手写 → 接受预测 → 改名的完整故事样例的## Edit History章节包含三段diff代码块其中第二段前有一行特殊注释--- a/README b/README -1,1 1,6 -Hello World! function filterByStatus(items, status) { return items.filter(item item.status status); } function groupBy // User accepted prediction:--- a/README b/README -4,3 4,9 -function groupBy function groupByStatus(items) { return items.reduce((groups, item) { const key item.status; (groups[key] groups[key] || []).push(item); return groups; }, {}); }--- a/README b/README -4,4 4,4 -function groupByStatus(items) { function groupByCat(items) { return items.reduce((groups, item) {三段 diff 的语义分别是手写编辑用户把 README 的Hello World!替换为 JavaScript 代码并手敲了function groupBy未写完被接受的自动补全// User accepted prediction:注释标记的 diff表示模型补全了groupByStatus的完整实现且用户接受了这次预测——这正是样例名中rename-accepted的来源后续改名用户把接受的补全改名为groupByCat一个被截断的名字触发本次评测模型此时应预测出把名字补全为groupByCategory、并同步修改函数体内item.status→item.category的编辑。// User accepted prediction:这一行不是给人看的普通注释而是解析协议的一部分。from_markdown中定义了常量const ACCEPTED_PREDICTION_MARKER: str // User accepted prediction:;example_spec.rs。解析时如果某个 diff 代码块之前紧跟该行文本解析器会把该行标记重新拼回edit_history字符串中example_spec.rs保证序列化/反序列化往返一致。同文件内的测试test_from_markdown_accepted_prediction_markerexample_spec.rs验证了三段 diff 均被保留、标记恰好出现一次、且只出现在第二段之前。2.3 Cursor Position#...^[CURSOR_POSITION]注释标记光标README function filterByStatus(items, status) { return items.filter(item item.status status); } function groupByCat(items) { # ^[CURSOR_POSITION] return items.reduce((groups, item) { const key item.status; (groups[key] groups[key] || []).push(item); return groups; }, {}); }Cursor Position 章节的代码块**信息串info string就是光标所在文件路径**这里是 README块内容是光标所在文件的节选。解析逻辑见 [example_spec.rs](https://link.gitcode.com/i/fc6b88b3a6aef362cd369f3179c433fd#L393-L396)cursor_path 取代码块 info stringcursor_position 取块内全文。 光标位置用一条注释行表达其解析规则[example_spec.rs](https://link.gitcode.com/i/fc6b88b3a6aef362cd369f3179c433fd#L417-L473) 的 cursor_excerpt 文档注释与实现为 - 注释行必须包含 [CURSOR_POSITION]常量 CURSOR_POSITION_MARKER定义于 [udiff.rs](https://link.gitcode.com/i/e59b52bed422861287f61c0e75c650c6)位于光标所在行的**下一行** - ^光标列 ^ 字符在该行的列位置指向上方的光标 - 光标列 该行第一个非空白字符所在列用于注释前缀较长、^ 会越界到注释符内部的情况 - 此外还支持内联标记 |user_cursor|常量 INLINE_CURSOR_MARKER同样定义于 [udiff.rs](https://link.gitcode.com/i/e59b52bed422861287f61c0e75c650c6)直接写在光标字节偏移处例如 let x |user_cursor|42;解析时直接剥掉标记并返回其偏移量。 在本样例中# 后的 ^ 指向 function groupByCat(items) { 中 Cat 之后的位置——即用户刚敲完 Cat、等待模型把名字补全为 Category 的时刻。测试 test_cursor_excerpt_with_caret[example_spec.rs](https://link.gitcode.com/i/fc6b88b3a6aef362cd369f3179c433fd#L521-L657)覆盖了 ^ 与 两种形式在行首、行中、行尾及文件末尾无换行的往返一致性。 注意解析器强制要求该章节存在缺失会直接报错 rust if spec.cursor_path.as_ref() Path::new() || spec.cursor_position.is_empty() { anyhow::bail!(Missing cursor position codeblock); }example_spec.rs2.4 Expected Patch期望补丁里也编码了光标--- a/README b/README -5,7 5,7 -function groupByCat(items) { function groupByCategory(items) { # ^[CURSOR_POSITION] return items.reduce((groups, item) { - const key item.status; const key item.category; (groups[key] groups[key] || []).push(item); return groups; }, {});这是评测的标准答案模型应当输出的 unified diff。两个要点期望补丁包含连带修改item.status→item.category这正是改名的正确预测与只改名不改引用的分界线也是该样例的评测价值所在补丁中同样有一行#...^[CURSOR_POSITION]标记说明编辑完成后光标应落在哪里groupByCategory的Category末尾。ExampleSpec提供expected_patches_with_cursor_positions/set_expected_patches_with_cursor_positionsexample_spec.rs成对地提取/写回光标偏移底层由extract_cursor_from_patch/encode_cursor_in_patch实现。源码注释说明在样例的序列化表示中编辑后的光标位置用新增 diff 行内的内联标记表达偏移量是相对 hunk 起点、在新文本中的字节偏移。此外ExampleSpec还支持一个可选的## Rejected Patch章节example_spec.rs用于保存用户拒绝的预测对应训练中的 DPO 负样本rejected_patch字段。本样例未使用该章节——它考察的是正向预测而非拒绝场景。3. 解析链路从.md文件到内存中的Example把样例格式与解析实现对照起来整条链路如下CLI 读入read_example_filesexample.rs按扩展名分派——.md走parse_markdown_example.json走 serde 直接反序列化Example.jsonl逐行反序列化输入为-时从 stdin 读取。Markdown 解析ExampleSpec::from_markdownexample_spec.rs基于pulldown_cmark事件流识别 H1样例名与七种 H2 章节标题大小写不敏感Uncommitted Diff、Recently Opened Files、Recently Viewed Files、Edit History、Cursor Position、Expected Patch、Rejected Patch并处理 accepted-prediction 标记的回写。本样例使用了其中Edit History、Cursor Position、Expected Patch三个章节。内存结构Exampleexample.rsExampleSpec打平内嵌prompt_inputsZeta2 提示输入prompt模型输入/期望输出含 DPO 用的rejected_outputpredictions实际预测列表含actual_patch、actual_cursor、logprob 等scoreqa结果。前四个运行时字段在磁盘样例文件中不存在由预测/评分流程填充。ExampleSpec的完整字段列表example_spec.rs还包括tags、reasoning、uncommitted_diff、recently_opened_files、recently_viewed_files、telemetry来自生产遥测的拒绝预测元数据request_id、rejection_reason等、human_feedback与rating覆盖了遥测捕获、用户评分等多种样例来源。4. 如何运行这个样例评测样例由 edit_prediction_cli 提供的ep命令驱动二进制名在 Cargo.toml 中定义为ep。4.1 命令与全局参数ep使用 clap 定义全局参数main.rs包括--max-parallelism默认 10、--group-by-repo同一仓库的样例集中处理、--limit/--offset--name按样例名过滤正好可以单独选中hello-world--rename-accepted-group-by--repo按仓库 URL 过滤输入inputs支持普通文件路径.md/.json/.jsonl以及captured-after:/rejected-after:/settled-after:/rated-after:等从 Snowflake 拉取遥测样例的特殊说明符见 main.rs 的INPUTS_HELP-o/--output、--in-place、--failfast、--failedkeep/skip/skip-no-files--markdown/-m输出为 Markdown 而非 JSONL每个样例写入一个.md文件——即evals/目录中这类文件的读写是同构的。子命令包含predict、score、qa、distill、pull-examples、synthesize、split-commit等--provider可选 Mercury、Zeta1、Zeta2、Baseten、Teacher 系列及 Repairmain.rs。4.2 针对本样例的最小用法对应当前仓库结构运行编辑预测评测的典型形式是把样例文件作为输入传给ep的子命令例如# 对该样例跑一次编辑预测 cargo run -p edit_prediction_cli -- predict \ crates/edit_prediction_cli/evals/hello-world--rename-accepted-group-by.md # 用 --name 在整批样例中按名过滤 cargo run -p edit_prediction_cli -- score --name hello-world--rename-accepted-group-by \ crates/edit_prediction_cli/evals/ # 结果以 Markdown 形式写回-o 指定目录 cargo run -p edit_prediction_cli -- predict --markdown \ -o /tmp/ep-out \ crates/edit_prediction_cli/evals/hello-world--rename-accepted-group-by.md其中score子命令复用PredictArgsmain.rs用于把模型输出与Expected Patch对照打分synthesize子命令的默认输出目录即crates/edit_prediction_cli/evals-generatedmain.rs用于从真实仓库提交中批量合成同类样例。另外仓库还提供了一个独立的单元测试评测脚本 script/run-unit-evals通过cargo nextest run --workspace --features unit-eval -E test(::eval_)运行带unit-evalfeature 的eval_前缀单元测试run-unit-evals它面向的是各 crate 内嵌的单元级评测与evals/目录这批 Markdown 样例分属两条评测通道。5. 小结这个样例教给模型的到底是什么把各要素串起来hello-world--rename-accepted-group-by构造了一条最小但完整的上下文 → 行为评测链上下文由 Edit History 给出先有手写编辑再有一次已被接受的预测// User accepted prediction:标记说明模型此前给出的groupByStatus实现已成为当前文件状态的一部分触发点由 Cursor Position 精确定位到groupByCat这个名字的中间——用户改名的意图刚刚暴露标准答案由 Expected Patch 给出不仅把名字补全为groupByCategory还连带把函数体内item.status改为item.category并在补丁中标注编辑完成后的光标位置。从源码结构看epCLI 的评分与 QA 流程score、qa子命令及 score.rs、qa.rs正是围绕实际补丁 vsexpected_patches这类字段展开的而rejected_patch字段则为负样本DPO预留了同一格式通道。掌握本文介绍的 front matter、四个 H2 章节、光标注释^//|user_cursor|三种形式与 accepted-prediction 标记即可在该目录下编写新的评测样例并用 example_spec.rs 中的往返测试方法验证其可解析性。关键文件索引文件作用crates/edit_prediction_cli/evals/hello-world--rename-accepted-group-by.md本文剖析的评测样例crates/edit_prediction/src/example_spec.rsExampleSpec定义、Markdown 解析、光标标记语义与往返测试crates/edit_prediction_cli/src/example.rsExample结构、多格式文件读入、仓库名解析crates/edit_prediction_cli/src/main.rsepCLI 参数、子命令与 provider 定义crates/zeta_prompt/src/udiff.rs[CURSOR_POSITION]与\|user_cursor\|常量及补丁光标编解码script/run-unit-evals单元级评测的 nextest 运行脚本【免费下载链接】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），仅供参考 Zed 编辑预测评测样例（evals）格式深度解析：从 hello-world 改名样例看 `ep` CLI 的数据规范
Zed 编辑预测评测样例evals格式深度解析从 hello-world 改名样例看epCLI 的数据规范【免费下载链接】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本文以 hello-world--rename-accepted-group-by.md 这一评测样例文件为主线完整拆解 Zed 编辑预测Edit Prediction / Zeta评测数据的 Markdown 格式TOML front matter、Edit History 中的用户接受预测标记、[CURSOR_POSITION]光标注释的列定位语义以及 Expected Patch 的游标编码方式并结合 example_spec.rs 与 example.rs 的解析实现说明如何用 edit_prediction_cli 的ep命令驱动这条评测链路。读完后你可以独立编写、阅读和运行 Zed 的编辑预测评测样例。1. 这个样例文件在仓库中的位置与作用该文件位于 crates/edit_prediction_cli/evals/ 目录下是 Zed 编辑预测模型的评测样例之一。同一目录中还有来自 flask、tree-sitter、vscode、zed 等仓库的样例如 flask--rename-accepted-prediction.md、tree-sitter--tuple-to-struct-definition.md命名遵循仓库名--场景描述.md的约定。文件名本身就是样例名解析入口read_example_filesexample.rs在读入.md文件后若spec.name为空就直接取文件主名去掉扩展名的部分作为样例名md { let mut example parse_markdown_example(content).unwrap(); if example.spec.name.is_empty() { example.spec.name filename; } examples.push(example); }也就是说hello-world--rename-accepted-group-by这个文件名精确表达了该样例测试的语义在 hello-world 仓库中用户先接受了一次自动补全随后对补全出的函数做改名模型应当能预测出连带修改函数体内引用的完整重命名。2. 样例全文结构front matter、编辑历史、光标与期望补丁下面逐段解析该样例文件的真实内容与仓库文件完全一致。2.1 TOML front matter锚定到确定性的仓库状态 repository_url https://github.com/octocat/hello-world revision 7fd1a60b01f91b314f59955a4e4d4e80d8edf11d front matter 用定界内部是 TOML。解析器ExampleSpec::from_markdownexample_spec.rs会先strip_prefix(\n)取出 front matter 并用toml::from_str::FrontMatter反序列化可识别的字段包括字段含义repository_url样例所锚定的仓库地址。从源码结构看repo_name()example.rs会同时解析gitgithub.com:owner/repo.git与https://github.com/owner/repo.git两种形式并据此推导 worktree 缓存路径owner/reporevision固定到某个提交哈希保证评测可复现tags可选标签数组可选字段省略时为空uncommitted_diff_requires_edit_history_rollback可选布尔值控制加载Uncommitted Diff章节时是否需要回滚编辑历史可选字段省略时为 false该样例只使用了repository_url与revision两个必填字段。2.2 Edit History三段 diff 讲述手写 → 接受预测 → 改名的完整故事样例的## Edit History章节包含三段diff代码块其中第二段前有一行特殊注释--- a/README b/README -1,1 1,6 -Hello World! function filterByStatus(items, status) { return items.filter(item item.status status); } function groupBy // User accepted prediction:--- a/README b/README -4,3 4,9 -function groupBy function groupByStatus(items) { return items.reduce((groups, item) { const key item.status; (groups[key] groups[key] || []).push(item); return groups; }, {}); }--- a/README b/README -4,4 4,4 -function groupByStatus(items) { function groupByCat(items) { return items.reduce((groups, item) {三段 diff 的语义分别是手写编辑用户把 README 的Hello World!替换为 JavaScript 代码并手敲了function groupBy未写完被接受的自动补全// User accepted prediction:注释标记的 diff表示模型补全了groupByStatus的完整实现且用户接受了这次预测——这正是样例名中rename-accepted的来源后续改名用户把接受的补全改名为groupByCat一个被截断的名字触发本次评测模型此时应预测出把名字补全为groupByCategory、并同步修改函数体内item.status→item.category的编辑。// User accepted prediction:这一行不是给人看的普通注释而是解析协议的一部分。from_markdown中定义了常量const ACCEPTED_PREDICTION_MARKER: str // User accepted prediction:;example_spec.rs。解析时如果某个 diff 代码块之前紧跟该行文本解析器会把该行标记重新拼回edit_history字符串中example_spec.rs保证序列化/反序列化往返一致。同文件内的测试test_from_markdown_accepted_prediction_markerexample_spec.rs验证了三段 diff 均被保留、标记恰好出现一次、且只出现在第二段之前。2.3 Cursor Position#...^[CURSOR_POSITION]注释标记光标README function filterByStatus(items, status) { return items.filter(item item.status status); } function groupByCat(items) { # ^[CURSOR_POSITION] return items.reduce((groups, item) { const key item.status; (groups[key] groups[key] || []).push(item); return groups; }, {}); }Cursor Position 章节的代码块**信息串info string就是光标所在文件路径**这里是 README块内容是光标所在文件的节选。解析逻辑见 [example_spec.rs](https://link.gitcode.com/i/fc6b88b3a6aef362cd369f3179c433fd#L393-L396)cursor_path 取代码块 info stringcursor_position 取块内全文。 光标位置用一条注释行表达其解析规则[example_spec.rs](https://link.gitcode.com/i/fc6b88b3a6aef362cd369f3179c433fd#L417-L473) 的 cursor_excerpt 文档注释与实现为 - 注释行必须包含 [CURSOR_POSITION]常量 CURSOR_POSITION_MARKER定义于 [udiff.rs](https://link.gitcode.com/i/e59b52bed422861287f61c0e75c650c6)位于光标所在行的**下一行** - ^光标列 ^ 字符在该行的列位置指向上方的光标 - 光标列 该行第一个非空白字符所在列用于注释前缀较长、^ 会越界到注释符内部的情况 - 此外还支持内联标记 |user_cursor|常量 INLINE_CURSOR_MARKER同样定义于 [udiff.rs](https://link.gitcode.com/i/e59b52bed422861287f61c0e75c650c6)直接写在光标字节偏移处例如 let x |user_cursor|42;解析时直接剥掉标记并返回其偏移量。 在本样例中# 后的 ^ 指向 function groupByCat(items) { 中 Cat 之后的位置——即用户刚敲完 Cat、等待模型把名字补全为 Category 的时刻。测试 test_cursor_excerpt_with_caret[example_spec.rs](https://link.gitcode.com/i/fc6b88b3a6aef362cd369f3179c433fd#L521-L657)覆盖了 ^ 与 两种形式在行首、行中、行尾及文件末尾无换行的往返一致性。 注意解析器强制要求该章节存在缺失会直接报错 rust if spec.cursor_path.as_ref() Path::new() || spec.cursor_position.is_empty() { anyhow::bail!(Missing cursor position codeblock); }example_spec.rs2.4 Expected Patch期望补丁里也编码了光标--- a/README b/README -5,7 5,7 -function groupByCat(items) { function groupByCategory(items) { # ^[CURSOR_POSITION] return items.reduce((groups, item) { - const key item.status; const key item.category; (groups[key] groups[key] || []).push(item); return groups; }, {});这是评测的标准答案模型应当输出的 unified diff。两个要点期望补丁包含连带修改item.status→item.category这正是改名的正确预测与只改名不改引用的分界线也是该样例的评测价值所在补丁中同样有一行#...^[CURSOR_POSITION]标记说明编辑完成后光标应落在哪里groupByCategory的Category末尾。ExampleSpec提供expected_patches_with_cursor_positions/set_expected_patches_with_cursor_positionsexample_spec.rs成对地提取/写回光标偏移底层由extract_cursor_from_patch/encode_cursor_in_patch实现。源码注释说明在样例的序列化表示中编辑后的光标位置用新增 diff 行内的内联标记表达偏移量是相对 hunk 起点、在新文本中的字节偏移。此外ExampleSpec还支持一个可选的## Rejected Patch章节example_spec.rs用于保存用户拒绝的预测对应训练中的 DPO 负样本rejected_patch字段。本样例未使用该章节——它考察的是正向预测而非拒绝场景。3. 解析链路从.md文件到内存中的Example把样例格式与解析实现对照起来整条链路如下CLI 读入read_example_filesexample.rs按扩展名分派——.md走parse_markdown_example.json走 serde 直接反序列化Example.jsonl逐行反序列化输入为-时从 stdin 读取。Markdown 解析ExampleSpec::from_markdownexample_spec.rs基于pulldown_cmark事件流识别 H1样例名与七种 H2 章节标题大小写不敏感Uncommitted Diff、Recently Opened Files、Recently Viewed Files、Edit History、Cursor Position、Expected Patch、Rejected Patch并处理 accepted-prediction 标记的回写。本样例使用了其中Edit History、Cursor Position、Expected Patch三个章节。内存结构Exampleexample.rsExampleSpec打平内嵌prompt_inputsZeta2 提示输入prompt模型输入/期望输出含 DPO 用的rejected_outputpredictions实际预测列表含actual_patch、actual_cursor、logprob 等scoreqa结果。前四个运行时字段在磁盘样例文件中不存在由预测/评分流程填充。ExampleSpec的完整字段列表example_spec.rs还包括tags、reasoning、uncommitted_diff、recently_opened_files、recently_viewed_files、telemetry来自生产遥测的拒绝预测元数据request_id、rejection_reason等、human_feedback与rating覆盖了遥测捕获、用户评分等多种样例来源。4. 如何运行这个样例评测样例由 edit_prediction_cli 提供的ep命令驱动二进制名在 Cargo.toml 中定义为ep。4.1 命令与全局参数ep使用 clap 定义全局参数main.rs包括--max-parallelism默认 10、--group-by-repo同一仓库的样例集中处理、--limit/--offset--name按样例名过滤正好可以单独选中hello-world--rename-accepted-group-by--repo按仓库 URL 过滤输入inputs支持普通文件路径.md/.json/.jsonl以及captured-after:/rejected-after:/settled-after:/rated-after:等从 Snowflake 拉取遥测样例的特殊说明符见 main.rs 的INPUTS_HELP-o/--output、--in-place、--failfast、--failedkeep/skip/skip-no-files--markdown/-m输出为 Markdown 而非 JSONL每个样例写入一个.md文件——即evals/目录中这类文件的读写是同构的。子命令包含predict、score、qa、distill、pull-examples、synthesize、split-commit等--provider可选 Mercury、Zeta1、Zeta2、Baseten、Teacher 系列及 Repairmain.rs。4.2 针对本样例的最小用法对应当前仓库结构运行编辑预测评测的典型形式是把样例文件作为输入传给ep的子命令例如# 对该样例跑一次编辑预测 cargo run -p edit_prediction_cli -- predict \ crates/edit_prediction_cli/evals/hello-world--rename-accepted-group-by.md # 用 --name 在整批样例中按名过滤 cargo run -p edit_prediction_cli -- score --name hello-world--rename-accepted-group-by \ crates/edit_prediction_cli/evals/ # 结果以 Markdown 形式写回-o 指定目录 cargo run -p edit_prediction_cli -- predict --markdown \ -o /tmp/ep-out \ crates/edit_prediction_cli/evals/hello-world--rename-accepted-group-by.md其中score子命令复用PredictArgsmain.rs用于把模型输出与Expected Patch对照打分synthesize子命令的默认输出目录即crates/edit_prediction_cli/evals-generatedmain.rs用于从真实仓库提交中批量合成同类样例。另外仓库还提供了一个独立的单元测试评测脚本 script/run-unit-evals通过cargo nextest run --workspace --features unit-eval -E test(::eval_)运行带unit-evalfeature 的eval_前缀单元测试run-unit-evals它面向的是各 crate 内嵌的单元级评测与evals/目录这批 Markdown 样例分属两条评测通道。5. 小结这个样例教给模型的到底是什么把各要素串起来hello-world--rename-accepted-group-by构造了一条最小但完整的上下文 → 行为评测链上下文由 Edit History 给出先有手写编辑再有一次已被接受的预测// User accepted prediction:标记说明模型此前给出的groupByStatus实现已成为当前文件状态的一部分触发点由 Cursor Position 精确定位到groupByCat这个名字的中间——用户改名的意图刚刚暴露标准答案由 Expected Patch 给出不仅把名字补全为groupByCategory还连带把函数体内item.status改为item.category并在补丁中标注编辑完成后的光标位置。从源码结构看epCLI 的评分与 QA 流程score、qa子命令及 score.rs、qa.rs正是围绕实际补丁 vsexpected_patches这类字段展开的而rejected_patch字段则为负样本DPO预留了同一格式通道。掌握本文介绍的 front matter、四个 H2 章节、光标注释^//|user_cursor|三种形式与 accepted-prediction 标记即可在该目录下编写新的评测样例并用 example_spec.rs 中的往返测试方法验证其可解析性。关键文件索引文件作用crates/edit_prediction_cli/evals/hello-world--rename-accepted-group-by.md本文剖析的评测样例crates/edit_prediction/src/example_spec.rsExampleSpec定义、Markdown 解析、光标标记语义与往返测试crates/edit_prediction_cli/src/example.rsExample结构、多格式文件读入、仓库名解析crates/edit_prediction_cli/src/main.rsepCLI 参数、子命令与 provider 定义crates/zeta_prompt/src/udiff.rs[CURSOR_POSITION]与\|user_cursor\|常量及补丁光标编解码script/run-unit-evals单元级评测的 nextest 运行脚本【免费下载链接】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），仅供参考