news 2026/9/7 9:44:01

Zed 编辑预测评估样本深度解读：以 terraform--add-comment.md 为例拆解 ep CLI 的示例格式与解析实现

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
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/zed

Zed 仓库中的 terraform--add-comment.md 是ep（edit 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_history（example_spec.rs），后续会参与构建模型的输入事件序列。

解析器对 Edit History 小节还内置了一个特殊约定：若某段 diff 代码块前出现文本// User accepted prediction:，解析时会把该标记串插入edit_history（example_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_position（example_spec.rs）。若两者缺失，from_markdown会直接报错Missing cursor position codeblock，即光标小节是样本的必填项。

光标标记行的核心语义由 cursor_excerpt 实现并文档化：

  • 标记行包含[CURSOR_POSITION]字符串（常量定义于 crates/zeta_prompt/src/udiff.rs：CURSOR_POSITION_MARKER = "[CURSOR_POSITION]"）；
  • ^形式：^字符所在列即光标列（向上指到上一行对应位置）；
  • <形式：本样本使用的形式，表示光标位于上一行第一个非空白字符处——即/所在列，与 Edit History 中+ /的插入位置严格对应；
  • 函数会剥离标记行，返回“纯摘录文本 + 光标在该摘录中的字节偏移”。

除这种“标记行”方案外，代码还支持行内标记<|user_cursor|>（INLINE_CURSOR_MARKER，udiff.rs），cursor_excerpt会优先查找它（example_spec.rs），其往返测试见 test_cursor_excerpt_with_inline_marker。

Expected Patch：五个等价期望补丁

## Expected Patch小节包含5 段 diff 代码块，每段都把/替换为一条完整的注释：

  1. // Filter action instances by the given action.
  2. // Filter action instances that belong to the given action
  3. // Iterate through all action instances and filter by the containing action
  4. // Iterate through all action instances and return those that belong to the given action
  5. // Collect all action instances that belong to the given action

这体现了评估样本的关键设计：“正确预测”不是唯一的字符串。解析器把 Expected Patch 小节下的每一段diff 块追加进spec.expected_patches: Vec<String>（example_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后，会包装进Example（example.rs），其字段构成了一条完整的评测数据流水线：

字段含义
spec从本文档解析出的规格（flattened 进 JSON）
prompt_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_markdown（example_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 构建评判 prompt（build_prompt），产出reverts_edits（预测是否撤销了用户有意做的编辑）与confidence（1–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），仅供参考

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/9/7 9:38:13

活塞环标记识别与安装全流程：从看懂标记到规范装配

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/9/7 9:35:50

离线语音合成方案：Java集成freeTTS实现内网环境语音播报

简介&#xff1a;freeTTS是一个基于Java的开源文本转语音系统&#xff0c;面向需要集成语音合成能力的Java开发者&#xff0c;常用于语音助手、教育软件、无障碍工具及车载导航等场景&#xff0c;也是理解语音合成原理的很好范例。这个java语音包共含103个文件&#xff0c;以Ja…

作者头像 李华
网站建设 2026/9/7 9:35:28

从源码拆解网约车系统：订单状态机、派单算法与高并发设计

简介&#xff1a;滴滴打车客户端Android源码包&#xff0c;面向移动应用开发者及网约车业务学习者&#xff0c;用于剖析实际出行类App的完整实现逻辑。资源共283个文件、约5MB&#xff0c;其中包含36个java、121个class、39个xml、66个png、8个jar及2个apk等&#xff0c;java/c…

作者头像 李华
网站建设 2026/9/7 9:35:17

Th1/Th2 双重应答标志物一体化检测方案全新落地，云克隆 Luminex 多因子试剂盒助力过敏性炎症与免疫平衡机制研究

Luminex靶标清单&#xff1a;CXCL1,IL1β,IL2,IL4,IL5,IL6,IP10,MCP1,MIP1αTh1/Th2 免疫平衡失衡是过敏性哮喘、特应性皮炎、过敏性鼻炎、寄生虫感染等一系列疾病发生发展的核心免疫学基础。IL-4、IL-5 是经典 Th2 效应因子&#xff0c;主导体液免疫应答、嗜酸性粒细胞活化募集…

作者头像 李华
网站建设 2026/9/7 9:35:17

论文AI检测率超标怎么办？2026年毕业党必看：改完直降80%！

最近身边好多同学都靠AI帮着写论文&#xff0c;可随之而来的烦恼也不少——知网、维普这些主流检测平台都上线了AIGC检测功能&#xff0c;毕业论文不光要过查重这一关&#xff0c;要是AIGC率超标&#xff0c;搞不好直接卡在审核环节&#xff01;别焦虑&#xff0c;我亲测有效的…

作者头像 李华
网站建设 2026/9/7 9:34:30

Marvell 88E6095交换芯片Linux驱动移植与调试实战

简介&#xff1a;Marvell 88e6095是一款常用于主板的千兆以太网控制芯片&#xff0c;本资源即为配套该芯片的驱动及DSDT_2.3c补丁整合包&#xff0c;适用于因系统兼容性或ACPI配置问题导致网络异常的用户&#xff0c;也可供驱动开发与嵌入式网络调试人员参考。压缩包共116个文件…

作者头像 李华