Zed 编辑预测评估样本深度解读以 terraform--add-comment.md 为例拆解 ep CLI 的示例格式与解析实现【免费下载链接】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/zedZed 仓库中的 terraform--add-comment.md 是epedit prediction CLI工具的一个 Markdown 评估样本用于评测编辑预测模型在“用户刚输入注释起始符/”这一场景下能否自动生成一条合理的 Go 注释。读完本文你将掌握 Zed 编辑预测评估样本的完整字段结构front matter、Edit History、Cursor Position、Expected Patch、[CURSOR_POSITION]光标标记的两种编码形式以及epCLI 从 Markdown 解析样本到执行预测、打分、QA 评审的源码级调用链能够独立编写和校验此类评估样本。样本在仓库中的位置该样本位于 crates/edit_prediction_cli/evals/ 目录下与 flask、tree-sitter、vscode、zed 等来自不同开源仓库的样本并列。Cargo.toml 声明了二进制入口[[bin]] name ep path src/main.rs即该 crate 编译出的可执行命令名为ep。evals 目录中的每个.md文件都会被 read_example_files 按扩展名分派解析.json走 JSON 反序列化、.jsonl按行解析、.md则调用parse_markdown_example最终统一装入 Example 结构体。文件名去掉扩展名会作为样本的name回退值因此terraform--add-comment既是文件名也是该样本在运行输出、过滤参数如--name中使用的标识。Front Matter锁定仓库与修订版本样本开头是一段 TOML front matter repository_url https://github.com/hashicorp/terraform revision a3dc571150a7651a1a4a8b302342d26089c97795 原文 front matter 中 revision 为a3dc571150a7651a1a4a8b302342d26089c97795的完整 40 位提交哈希。这两项的作用是把评估环境钉死在 Terraform 仓库的某个精确提交上保证评测可复现。解析逻辑在 ExampleSpec::from_markdown 中if let Some(rest) input.strip_prefix(\n) let Some((front_matter, rest)) rest.split_once(\n) { if let Ok(data) toml::from_str::FrontMatter_(front_matter) { spec.repository_url data.repository_url.into_owned(); spec.revision data.revision.into_owned(); ... } }FrontMatter除repository_url与revision外还支持tags与uncommitted_diff_requires_edit_history_rollback两个可选字段见 example_spec.rs。样本中未提供时取默认空值。解析后repository_url还会被 Example::repo_name 拆解为owner/name用于在本地 worktree 目录WORKTREES_DIR/owner/name中检出对应修订的代码供上下文检索与项目加载使用。Edit History用户的编辑序列## Edit History小节记录了模型需要“看到”的用户历史编辑本样本中为一段 unified diff--- a/internal/actions/actions.go b/internal/actions/actions.go -63,6 63,7 a.mu.Lock() defer a.mu.Unlock() / result : []addrs.AbsActionInstance{} for _, data : range a.actionInstances.Elements() { if data.Key.ContainingAction().Equal(addr) {语义是用户在GetActionInstanceKeys方法体内、result声明之前输入了一个单独的/——这是输入// 注释的第一个字符。这正是评估目标给定“用户刚敲下/”这一信号预测引擎应能预测出完整的行注释。该小节文本最终存入ExampleSpec::edit_historyexample_spec.rs后续会参与构建模型的输入事件序列。解析器对 Edit History 小节还内置了一个特殊约定若某段 diff 代码块前出现文本// User accepted prediction:解析时会把该标记串插入edit_historyexample_spec.rs用以区分“用户手工编辑”和“用户接受了某次预测”两类事件。本样本未使用该标记其单元测试见 test_from_markdown_accepted_prediction_marker。Cursor Position光标位置与[CURSOR_POSITION]标记## Cursor Position小节的代码块用代码块的 info string 表示文件路径块体是文件摘录内容加一行光标标记internal/actions/actions.go defer a.mu.Unlock() data, ok : a.actionInstances.GetOk(addr) if !ok { return nil, false } return data, true } func (a *Actions) GetActionInstanceKeys(addr addrs.AbsAction) []addrs.AbsActionInstance { a.mu.Lock() defer a.mu.Unlock() / // [CURSOR_POSITION] result : []addrs.AbsActionInstance{} ... 解析时info stringinternal/actions/actions.go被写入spec.cursor_path块体写入spec.cursor_positionexample_spec.rs。若两者缺失from_markdown会直接报错Missing cursor position codeblock即光标小节是样本的必填项。光标标记行的核心语义由 cursor_excerpt 实现并文档化标记行包含[CURSOR_POSITION]字符串常量定义于 crates/zeta_prompt/src/udiff.rsCURSOR_POSITION_MARKER [CURSOR_POSITION]^形式^字符所在列即光标列向上指到上一行对应位置形式本样本使用的形式表示光标位于上一行第一个非空白字符处——即/所在列与 Edit History 中 /的插入位置严格对应函数会剥离标记行返回“纯摘录文本 光标在该摘录中的字节偏移”。除这种“标记行”方案外代码还支持行内标记|user_cursor|INLINE_CURSOR_MARKERudiff.rscursor_excerpt会优先查找它example_spec.rs其往返测试见 test_cursor_excerpt_with_inline_marker。Expected Patch五个等价期望补丁## Expected Patch小节包含5 段 diff 代码块每段都把/替换为一条完整的注释// Filter action instances by the given action.// Filter action instances that belong to the given action// Iterate through all action instances and filter by the containing action// Iterate through all action instances and return those that belong to the given action// Collect all action instances that belong to the given action这体现了评估样本的关键设计“正确预测”不是唯一的字符串。解析器把 Expected Patch 小节下的每一段diff 块追加进spec.expected_patches: VecStringexample_spec.rs打分阶段ep score会把模型实际输出的 patch 与其中任一期望匹配即视为命中——这既容忍措辞差异也避免单一标准答案带来的过拟合式评分。从源码结构看期望补丁还可内嵌光标位置expected_patches_with_cursor_positions 通过extract_cursor_from_patch从补丁的 added 行中提取内联|user_cursor|标记encode_cursor_in_patch反向写入且该编码是幂等的test_encode_cursor_in_patch_is_idempotent。本样本的期望补丁未包含该标记表示只评估编辑内容、不评估预测后的光标落点。解析与执行ep CLI 的调用链样本被解析为ExampleSpec后会包装进Exampleexample.rs其字段构成了一条完整的评测数据流水线字段含义spec从本文档解析出的规格flattened 进 JSONprompt_inputs上下文检索ep context后填充的 Zeta2 提示输入prompt实际发给预测模型的输入与期望输出predictions模型真实预测ep predict产物含actual_patch、logprob 等score预测与期望补丁的匹配打分ep score产物qaLLM 评审结果ep qa产物命令行入口是 main.rs 中的EpArgs提供--name按样本名过滤本样本即terraform--add-comment、--repo按仓库过滤本样本即https://github.com/hashicorp/terraform、--limit、--markdown以 Markdown 目录形式输出每个样本一个.md等全局参数。其中--markdown输出方向与本文档正好互为镜像ExampleSpec::to_markdownexample_spec.rs按固定小节顺序Reasoning、Uncommitted Diff、Recently Opened/Viewed Files、Edit History、Cursor Position、Expected Patch、Rejected Patch把Example重新序列化回这种 Markdown 格式。质量评审环节值得单独说明ep qa命令qa.rs会用 LLM 作为评审基于{edit_history}、{cursor_excerpt}与模型实际 patch 的 word diff 构建评判 promptbuild_prompt产出reverts_edits预测是否撤销了用户有意做的编辑与confidence1–5 的接受可能性评分。对terraform--add-comment这类“补全注释”任务QA 评审能够捕捉“预测把用户已输入的/删掉重写”这类与纯文本匹配无关的质量问题。小结从单个样本看 Zed 编辑预测的评估方法可复现性TOML front matter 锁定仓库与提交哈希配合本地 worktree 检出机制保证评测环境一致信号建模Edit History Cursor Position 完整刻画了“历史编辑序列 当前光标”这一预测输入的核心信号^//|user_cursor|三种标记形式覆盖了不同缩进与行内光标场景宽容评分expected_patches的多补丁设计让“注释措辞不同但语义等价”的预测都能通过多层质检score做确定性匹配qa做 LLM 语义评审两者互补。若要复现或扩展这类评估可在仓库中查看 evals 目录 下的其他样本如 zed--add-eprintln.md、flask--add-test-function.md对照字段写法并参考 example_spec.rs 的from_markdown/to_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），仅供参考
Zed 编辑预测评估样本深度解读：以 terraform--add-comment.md 为例拆解 ep CLI 的示例格式与解析实现
Zed 编辑预测评估样本深度解读以 terraform--add-comment.md 为例拆解 ep CLI 的示例格式与解析实现【免费下载链接】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/zedZed 仓库中的 terraform--add-comment.md 是epedit prediction CLI工具的一个 Markdown 评估样本用于评测编辑预测模型在“用户刚输入注释起始符/”这一场景下能否自动生成一条合理的 Go 注释。读完本文你将掌握 Zed 编辑预测评估样本的完整字段结构front matter、Edit History、Cursor Position、Expected Patch、[CURSOR_POSITION]光标标记的两种编码形式以及epCLI 从 Markdown 解析样本到执行预测、打分、QA 评审的源码级调用链能够独立编写和校验此类评估样本。样本在仓库中的位置该样本位于 crates/edit_prediction_cli/evals/ 目录下与 flask、tree-sitter、vscode、zed 等来自不同开源仓库的样本并列。Cargo.toml 声明了二进制入口[[bin]] name ep path src/main.rs即该 crate 编译出的可执行命令名为ep。evals 目录中的每个.md文件都会被 read_example_files 按扩展名分派解析.json走 JSON 反序列化、.jsonl按行解析、.md则调用parse_markdown_example最终统一装入 Example 结构体。文件名去掉扩展名会作为样本的name回退值因此terraform--add-comment既是文件名也是该样本在运行输出、过滤参数如--name中使用的标识。Front Matter锁定仓库与修订版本样本开头是一段 TOML front matter repository_url https://github.com/hashicorp/terraform revision a3dc571150a7651a1a4a8b302342d26089c97795 原文 front matter 中 revision 为a3dc571150a7651a1a4a8b302342d26089c97795的完整 40 位提交哈希。这两项的作用是把评估环境钉死在 Terraform 仓库的某个精确提交上保证评测可复现。解析逻辑在 ExampleSpec::from_markdown 中if let Some(rest) input.strip_prefix(\n) let Some((front_matter, rest)) rest.split_once(\n) { if let Ok(data) toml::from_str::FrontMatter_(front_matter) { spec.repository_url data.repository_url.into_owned(); spec.revision data.revision.into_owned(); ... } }FrontMatter除repository_url与revision外还支持tags与uncommitted_diff_requires_edit_history_rollback两个可选字段见 example_spec.rs。样本中未提供时取默认空值。解析后repository_url还会被 Example::repo_name 拆解为owner/name用于在本地 worktree 目录WORKTREES_DIR/owner/name中检出对应修订的代码供上下文检索与项目加载使用。Edit History用户的编辑序列## Edit History小节记录了模型需要“看到”的用户历史编辑本样本中为一段 unified diff--- a/internal/actions/actions.go b/internal/actions/actions.go -63,6 63,7 a.mu.Lock() defer a.mu.Unlock() / result : []addrs.AbsActionInstance{} for _, data : range a.actionInstances.Elements() { if data.Key.ContainingAction().Equal(addr) {语义是用户在GetActionInstanceKeys方法体内、result声明之前输入了一个单独的/——这是输入// 注释的第一个字符。这正是评估目标给定“用户刚敲下/”这一信号预测引擎应能预测出完整的行注释。该小节文本最终存入ExampleSpec::edit_historyexample_spec.rs后续会参与构建模型的输入事件序列。解析器对 Edit History 小节还内置了一个特殊约定若某段 diff 代码块前出现文本// User accepted prediction:解析时会把该标记串插入edit_historyexample_spec.rs用以区分“用户手工编辑”和“用户接受了某次预测”两类事件。本样本未使用该标记其单元测试见 test_from_markdown_accepted_prediction_marker。Cursor Position光标位置与[CURSOR_POSITION]标记## Cursor Position小节的代码块用代码块的 info string 表示文件路径块体是文件摘录内容加一行光标标记internal/actions/actions.go defer a.mu.Unlock() data, ok : a.actionInstances.GetOk(addr) if !ok { return nil, false } return data, true } func (a *Actions) GetActionInstanceKeys(addr addrs.AbsAction) []addrs.AbsActionInstance { a.mu.Lock() defer a.mu.Unlock() / // [CURSOR_POSITION] result : []addrs.AbsActionInstance{} ... 解析时info stringinternal/actions/actions.go被写入spec.cursor_path块体写入spec.cursor_positionexample_spec.rs。若两者缺失from_markdown会直接报错Missing cursor position codeblock即光标小节是样本的必填项。光标标记行的核心语义由 cursor_excerpt 实现并文档化标记行包含[CURSOR_POSITION]字符串常量定义于 crates/zeta_prompt/src/udiff.rsCURSOR_POSITION_MARKER [CURSOR_POSITION]^形式^字符所在列即光标列向上指到上一行对应位置形式本样本使用的形式表示光标位于上一行第一个非空白字符处——即/所在列与 Edit History 中 /的插入位置严格对应函数会剥离标记行返回“纯摘录文本 光标在该摘录中的字节偏移”。除这种“标记行”方案外代码还支持行内标记|user_cursor|INLINE_CURSOR_MARKERudiff.rscursor_excerpt会优先查找它example_spec.rs其往返测试见 test_cursor_excerpt_with_inline_marker。Expected Patch五个等价期望补丁## Expected Patch小节包含5 段 diff 代码块每段都把/替换为一条完整的注释// Filter action instances by the given action.// Filter action instances that belong to the given action// Iterate through all action instances and filter by the containing action// Iterate through all action instances and return those that belong to the given action// Collect all action instances that belong to the given action这体现了评估样本的关键设计“正确预测”不是唯一的字符串。解析器把 Expected Patch 小节下的每一段diff 块追加进spec.expected_patches: VecStringexample_spec.rs打分阶段ep score会把模型实际输出的 patch 与其中任一期望匹配即视为命中——这既容忍措辞差异也避免单一标准答案带来的过拟合式评分。从源码结构看期望补丁还可内嵌光标位置expected_patches_with_cursor_positions 通过extract_cursor_from_patch从补丁的 added 行中提取内联|user_cursor|标记encode_cursor_in_patch反向写入且该编码是幂等的test_encode_cursor_in_patch_is_idempotent。本样本的期望补丁未包含该标记表示只评估编辑内容、不评估预测后的光标落点。解析与执行ep CLI 的调用链样本被解析为ExampleSpec后会包装进Exampleexample.rs其字段构成了一条完整的评测数据流水线字段含义spec从本文档解析出的规格flattened 进 JSONprompt_inputs上下文检索ep context后填充的 Zeta2 提示输入prompt实际发给预测模型的输入与期望输出predictions模型真实预测ep predict产物含actual_patch、logprob 等score预测与期望补丁的匹配打分ep score产物qaLLM 评审结果ep qa产物命令行入口是 main.rs 中的EpArgs提供--name按样本名过滤本样本即terraform--add-comment、--repo按仓库过滤本样本即https://github.com/hashicorp/terraform、--limit、--markdown以 Markdown 目录形式输出每个样本一个.md等全局参数。其中--markdown输出方向与本文档正好互为镜像ExampleSpec::to_markdownexample_spec.rs按固定小节顺序Reasoning、Uncommitted Diff、Recently Opened/Viewed Files、Edit History、Cursor Position、Expected Patch、Rejected Patch把Example重新序列化回这种 Markdown 格式。质量评审环节值得单独说明ep qa命令qa.rs会用 LLM 作为评审基于{edit_history}、{cursor_excerpt}与模型实际 patch 的 word diff 构建评判 promptbuild_prompt产出reverts_edits预测是否撤销了用户有意做的编辑与confidence1–5 的接受可能性评分。对terraform--add-comment这类“补全注释”任务QA 评审能够捕捉“预测把用户已输入的/删掉重写”这类与纯文本匹配无关的质量问题。小结从单个样本看 Zed 编辑预测的评估方法可复现性TOML front matter 锁定仓库与提交哈希配合本地 worktree 检出机制保证评测环境一致信号建模Edit History Cursor Position 完整刻画了“历史编辑序列 当前光标”这一预测输入的核心信号^//|user_cursor|三种标记形式覆盖了不同缩进与行内光标场景宽容评分expected_patches的多补丁设计让“注释措辞不同但语义等价”的预测都能通过多层质检score做确定性匹配qa做 LLM 语义评审两者互补。若要复现或扩展这类评估可在仓库中查看 evals 目录 下的其他样本如 zed--add-eprintln.md、flask--add-test-function.md对照字段写法并参考 example_spec.rs 的from_markdown/to_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），仅供参考
