eval-driven-dev 技能 Step 5 实战运行 pixie test 并修复机制性问题【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本指南聚焦于 eval-driven-dev 技能工作流中的Step 5Run pixie test and Fix Mechanical Issues讲解如何使用 pixie-qa 评测框架端到端执行评估流水线从命令行启动测试、理解评估 harness 的内部执行顺序到系统性地分类并修复机制性问题mechanical issues最终让每个数据集条目都产出真实可用的评估分数。读完本文你将掌握pixie test的完整运行原理、并发安全陷阱的排查方法以及如何区分该在 Step 5 修的问题与必须留给 Step 6 分析的问题。一、Step 5 在整个工作流中的位置与目标eval-driven-dev 是一条完整的评估驱动开发流水线共 6 个步骤Step 1分析应用、确定入口点、定义评估标准产出pixie_qa/00-project-analysis.md、01-entry-point.md、02-eval-criteria.mdStep 2用wrap()对应用打点2a-instrumentation、实现 Runnable2b-implement-runnable、捕获参考 trace2c-capture-and-verify-traceStep 3定义评估器3-define-evaluatorsStep 4构建数据集4-build-datasetStep 5运行pixie test并修复机制性问题 ——本文主题Step 6分析评估结果、生成行动方案6-analyze-outcomesStep 5 的目标非常明确让整个流水线跑起来而不是评估结果好坏。它只修复你在前几步构建的东西——数据集dataset、Runnable、自定义评估器custom evaluators——中的机制性问题比如数据集格式错误、Runnable 无法运行、评估器报错等。这一步不评估应用输出质量也不修复应用本身的 bug。按 SKILL.md 的定义最终交付物是一个能产生真实分数的pixie test运行——不是方案、不是打点、不是数据集。Step 5 就是这个交付物的临门一脚。注意Step 5 的检查点Checkpoint要求pixie test完整跑通每个数据集条目都有评估器分数真实的EvaluationResult或PendingEvaluation且没有 setup 错误、导入失败、数据校验错误。一旦产出分数就立即进入 Step 6——不要在 Step 5 停下询问用户因为 pending 评估只有经过 Step 6 分析才会完成否则用户只能看到一堆未解释的原始分数。二、5a运行测试2.1 基本命令在项目根目录虚拟环境已激活的前提下执行uv run pixie testpixie test会自动加载.env文件后再运行测试因此你的环境变量如 LLM API Key会按预期注入。如果需要查看每个测试用例的分数和评估器推理过程使用详细输出模式uv run pixie test -v2.2 相关 CLI 命令速览根据 testing-api.md 的 CLI 命令表与测试流程相关的命令还包括命令说明pixie test [path] [-v] [--no-open]对数据集文件运行评估测试pixie dataset create name创建新的空数据集pixie dataset list列出所有数据集pixie dataset save name [--select MODE]将一个 span 保存到数据集pixie dataset validate [path]校验数据集 JSON 文件pixie analyze test_run_id生成分析与建议对应 Step 6在 Step 5 之前或排查阶段pixie dataset validate可以提前发现数据集 JSON 的格式问题减少进入测试环节后的返工。三、评估 harness 的执行流程运行原理当pixie test运行时评估 harness 按以下顺序处理对应 5-run-tests.md 中描述的 8 个环节解析 Runnable从数据集的runnable字段解析出目标类格式为filepath:ClassName例如pixie_qa/run_app.py:AppRunnable。构建实例并初始化调用Runnable.create()构造实例然后调用一次setup()用于初始化共享资源如 HTTP 客户端、数据库连接、测试服务器。并发运行所有数据集条目最多 4 个并行 a. 从条目读取input_data和eval_inputb. 用eval_input数据填充 wrap 输入注册表wrap input registry c. 初始化捕获注册表capture registry d. 将input_data校验为 Pydantic 模型并调用Runnable.run(args)e. 应用中wrap(purposeinput)调用返回注册表中的值而不是调用真实外部服务f.wrap(purposeoutput/state)调用捕获数据供评估使用 g. 由捕获数据构建Evaluableh. 运行评估器evaluators收尾最后调用一次Runnable.teardown()释放setup()中获取的资源。3.1 Runnable 生命周期与并发模型根据 wrap-api.md 中的pixie.Runnable协议定义class pixie.Runnable(Protocol[T]): classmethod def create(cls) - Runnable[Any]: ... async def setup(self) - None: ... async def run(self, args: T) - None: ... async def teardown(self) - None: ...生命周期要点create()—— 类方法构造并返回一个 runnable 实例setup()——async在第一次run()之前调用一次用于初始化共享资源可选默认是 no-oprun(args)——async为每个数据集条目并发调用最多 4 个并行args是由input_data构建并校验过的 Pydantic 模型在此调用应用的真实入口点teardown()——async在最后一次run()之后调用一次可选默认是 no-op。因为run()通过asyncio.gather并发调用你的实现必须并发安全。3.2 wrap 注册表在测试时的行为Step 5 的执行之所以能用测试数据替换外部依赖依赖的是wrap()在 eval 模式下的行为详见 wrap-api.mdpurposeinput在 eval 模式下返回注册表中的注入值。若data是 callable返回的包装器会忽略原函数、每次调用都返回注入值——从而阻止真实外部调用执行。purposeoutput/purposestate在 eval 模式下捕获输出/状态供构建Evaluable使用。这也是为什么在 2a-instrumentation 中强调对purposeinput的外部调用必须使用函数形式wrap(fetch_page, purposeinput, namefetched_page)(url)否则真实调用仍会执行导致测试变慢、不稳定、依赖外部服务可用性。3.3 并发安全必读的 Semaphore 模式由于条目并发运行Runnable 的run()方法必须并发安全。如果你看到sqlite3.OperationalError、database is locked或类似错误说明你的 Runnable 中共享了 SQLite 连接等可变状态需要在 Runnable 中加Semaphore(1)详见 Step 2 参考文档的并发安全章节。wrap-api.md 给出的标准做法class AppRunnable(pixie.Runnable[AppArgs]): _sem: asyncio.Semaphore classmethod def create(cls) - AppRunnable: inst cls() inst._sem asyncio.Semaphore(1) # serialise DB access return inst async def run(self, args: AppArgs) - None: async with self._sem: await call_app(args.message)常见并发陷阱来自 wrap-api.mdSQLite并发写入不安全——使用Semaphore(1)或aiosqlite并开启 WAL 模式全局可变状态在run()中修改的模块级 dict/list 需要保护限流 API加信号量以避免 429 错误。但注意只有当应用确实存在共享可变状态时才需要加信号量。如果应用使用按请求隔离的状态按唯一 ID 隔离或天然无状态并发调用自然是隔离的2b-implement-runnable。另外2b-implement-runnable.md 提醒不要在 runnable 文件中使用from __future__ import annotations——它会破坏 Pydantic 对嵌套模型的解析应改用带引号的返回类型- AppRunnable。四、5b只修复机制性问题这一阶段严格限定为修复你在前几步构建的东西——数据集、Runnable、自定义评估器。你修复的是阻止流水线运行的机制问题不是评估或改进应用的输出质量。4.1 属于机制性问题需要修复错误原因修复方式WrapRegistryMissError: namekey数据集条目缺少应用wrap(purposeinput, namekey)所期望的name对应的eval_input项在每个受影响的条目中向eval_input添加缺失的{name: key, value: ...}WrapTypeMismatchError反序列化后的类型与应用期望的类型不匹配修正数据集中的 valueRunnable 解析失败runnable路径或类名错误或类未实现Runnable协议修正数据集中的filepath:ClassName确保类有create()和run()方法导入错误runnable/evaluator 的模块路径或语法错误修正被引用的文件ModuleNotFoundError: pixie_qapixie_qa/目录缺少__init__.py运行pixie init重建TypeError: ... is not callable评估器名称指向不可调用的属性评估器必须是函数、类或可调用实例sqlite3.OperationalError并发的run()调用共享 SQLite 连接在 Runnable 中添加asyncio.Semaphore(1)见上文自定义评估器崩溃自定义评估器实现中的 bug修复评估器代码4.2 不属于机制性问题不要在此处修复应用产出错误/低质量输出→ 这是应用行为留待 Step 6 分析评估器分数偏低→ 这是质量信号留待 Step 6 分析应用内部的 LLM 调用失败→ 在 Step 6 中报告不要 mock 或绕过评估器分数在不同运行间波动→ LLM 非确定性的正常现象不是 bug这一修复边界的设计意图很关键Step 5 只保证管道通了至于分数高低、应用好坏必须在完整分析后才有意义。尤其要注意最后一点——LLM 评估天然带有非确定性分数波动不是你需要修的问题。4.3 迭代策略修复是循环过程修错误 → 重新运行 → 修下一个错误直到pixie test完整跑通、所有条目都产出真实评估分数。遇到意外错误参数名错误、导入失败、API 不匹配时不要靠猜——先阅读 wrap-api.md、evaluators.md 或 testing-api.md 获取权威 API 参考再动手修复。4.4 从源头减少机制性问题很多 Step 5 的报错其实可以在前序步骤预防eval_input缺失问题根据 4-build-dataset如果应用存在任何wrap(purposeinput)调用每个数据集条目都必须提供对应的eval_input值否则应用会在 eval 运行时发起真实外部调用。其 4c″ 节的数据集真实性审计硬门槛中就有eval_input完整性检查一项逐条核对每个 input wrap 是否都有对应条目。WrapTypeMismatchErroreval_input的值必须与wrap()调用返回的精确类型和格式匹配4-build-dataset 4b′ 节内容格式。以参考 trace 为模板复制数据形状而不是凭空构造。Runnable 解析失败数据集的runnable字段格式为pixie_qa/run_app.py:AppRunnable路径相对项目根目录且项目根目录会自动加入sys.path可直接用普通import引用项目模块wrap-api.md。五、输出结果目录结构pixie test成功运行后结果按条目存储到如下目录结构中{PIXIE_ROOT}/results/test_id/ meta.json # 测试运行元数据 dataset-{idx}/ metadata.json # 数据集名称、路径、runnable entry-{idx}/ config.json # 评估器、描述、期望 eval-input.jsonl # 提供给评估器的输入数据 eval-output.jsonl # 从应用捕获的输出数据 evaluations.jsonl # 评估结果已评分 待处理 pending trace.jsonl # LLM 调用 trace如已捕获各文件含义meta.json—— 本次测试运行的元数据时间、参数等dataset-{idx}/metadata.json—— 数据集名称、路径、runnable 引用entry-{idx}/config.json—— 该条目的评估器列表、描述description、期望expectationentry-{idx}/eval-input.jsonl—— 喂给评估器的输入数据entry-{idx}/eval-output.jsonl—— 运行应用时捕获的输出数据entry-{idx}/evaluations.jsonl——核心产物每条评估结果包含已评分的scored与待处理的pending例如 agent evaluator 产生的PendingEvaluationentry-{idx}/trace.jsonl—— LLM 调用 trace若已捕获。test_id会打印在控制台输出中。在 Step 6 你会引用这个目录按 SKILL.md 的硬性完成门槛Step 6 必须把evaluations.jsonl中每个status: pending条目替换为含score与reasoning的评分结果并为每个数据集目录生成analysis.md/analysis-summary.md、为测试运行根目录生成action-plan.md/action-plan-summary.md。六、与前后步骤的衔接循环规则来自 SKILL.md每次成功的pixie test都会创建具体的pixie_qa/results/test_id目录并开启一个新的分析周期。在修改应用代码、提示词、数据集、评估器或重跑pixie test之前必须先针对该结果目录完成 Step 6。不要跳过早期周期只分析最后一次运行。pixie test与pixie trace的关系测试阶段使用 eval 模式注册表注入输入、捕获输出而 trace 阶段运行真实依赖以捕获参考数据wrap-api.md 中wrap()在三种模式——no-op、tracing、eval——下的行为差异是理解整条流水线的钥匙。应用真实代码路径原则整个评估过程中应用的 LLM 调用必须走真实 LLM绝不 mock、stub 或拦截。如果项目自带测试套件中包含 LLM mock 模式那是项目自身单元测试用的不要移植到 eval Runnable 中SKILL.md。同理Step 5 遇到应用内部 LLM 调用失败也不能用 mock 绕过而应在 Step 6 报告。七、小结Step 5 是评估驱动开发流水线中从构建到验证的转换点。记住三条核心原则目标纯粹只修管道问题数据集格式、Runnable 可运行性、评估器可调用性不评质量、不改应用理解执行模型Runnable 生命周期create → setup → 并发 run → teardown、wrap 注册表注入、并发安全Semaphore是排查一切报错的基础产出明确pixie test完整跑通、所有条目有真实分数后立即进入 Step 6 分析——结果目录{PIXIE_ROOT}/results/test_id/是后续所有分析工作的数据基础。想深入 API 细节的读者可直接查阅 testing-api.md数据集 JSON 格式、评估器名称解析、Evaluable/Evaluation/ScoreThreshold类型、wrap-api.mdRunnable 协议、wrap()三种模式、错误类型与 evaluators.md内置评估器选择指南、自定义评估器工厂函数。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 eval-driven-dev 技能 Step 5 实战：运行 pixie test 并修复机制性问题
eval-driven-dev 技能 Step 5 实战运行 pixie test 并修复机制性问题【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本指南聚焦于 eval-driven-dev 技能工作流中的Step 5Run pixie test and Fix Mechanical Issues讲解如何使用 pixie-qa 评测框架端到端执行评估流水线从命令行启动测试、理解评估 harness 的内部执行顺序到系统性地分类并修复机制性问题mechanical issues最终让每个数据集条目都产出真实可用的评估分数。读完本文你将掌握pixie test的完整运行原理、并发安全陷阱的排查方法以及如何区分该在 Step 5 修的问题与必须留给 Step 6 分析的问题。一、Step 5 在整个工作流中的位置与目标eval-driven-dev 是一条完整的评估驱动开发流水线共 6 个步骤Step 1分析应用、确定入口点、定义评估标准产出pixie_qa/00-project-analysis.md、01-entry-point.md、02-eval-criteria.mdStep 2用wrap()对应用打点2a-instrumentation、实现 Runnable2b-implement-runnable、捕获参考 trace2c-capture-and-verify-traceStep 3定义评估器3-define-evaluatorsStep 4构建数据集4-build-datasetStep 5运行pixie test并修复机制性问题 ——本文主题Step 6分析评估结果、生成行动方案6-analyze-outcomesStep 5 的目标非常明确让整个流水线跑起来而不是评估结果好坏。它只修复你在前几步构建的东西——数据集dataset、Runnable、自定义评估器custom evaluators——中的机制性问题比如数据集格式错误、Runnable 无法运行、评估器报错等。这一步不评估应用输出质量也不修复应用本身的 bug。按 SKILL.md 的定义最终交付物是一个能产生真实分数的pixie test运行——不是方案、不是打点、不是数据集。Step 5 就是这个交付物的临门一脚。注意Step 5 的检查点Checkpoint要求pixie test完整跑通每个数据集条目都有评估器分数真实的EvaluationResult或PendingEvaluation且没有 setup 错误、导入失败、数据校验错误。一旦产出分数就立即进入 Step 6——不要在 Step 5 停下询问用户因为 pending 评估只有经过 Step 6 分析才会完成否则用户只能看到一堆未解释的原始分数。二、5a运行测试2.1 基本命令在项目根目录虚拟环境已激活的前提下执行uv run pixie testpixie test会自动加载.env文件后再运行测试因此你的环境变量如 LLM API Key会按预期注入。如果需要查看每个测试用例的分数和评估器推理过程使用详细输出模式uv run pixie test -v2.2 相关 CLI 命令速览根据 testing-api.md 的 CLI 命令表与测试流程相关的命令还包括命令说明pixie test [path] [-v] [--no-open]对数据集文件运行评估测试pixie dataset create name创建新的空数据集pixie dataset list列出所有数据集pixie dataset save name [--select MODE]将一个 span 保存到数据集pixie dataset validate [path]校验数据集 JSON 文件pixie analyze test_run_id生成分析与建议对应 Step 6在 Step 5 之前或排查阶段pixie dataset validate可以提前发现数据集 JSON 的格式问题减少进入测试环节后的返工。三、评估 harness 的执行流程运行原理当pixie test运行时评估 harness 按以下顺序处理对应 5-run-tests.md 中描述的 8 个环节解析 Runnable从数据集的runnable字段解析出目标类格式为filepath:ClassName例如pixie_qa/run_app.py:AppRunnable。构建实例并初始化调用Runnable.create()构造实例然后调用一次setup()用于初始化共享资源如 HTTP 客户端、数据库连接、测试服务器。并发运行所有数据集条目最多 4 个并行 a. 从条目读取input_data和eval_inputb. 用eval_input数据填充 wrap 输入注册表wrap input registry c. 初始化捕获注册表capture registry d. 将input_data校验为 Pydantic 模型并调用Runnable.run(args)e. 应用中wrap(purposeinput)调用返回注册表中的值而不是调用真实外部服务f.wrap(purposeoutput/state)调用捕获数据供评估使用 g. 由捕获数据构建Evaluableh. 运行评估器evaluators收尾最后调用一次Runnable.teardown()释放setup()中获取的资源。3.1 Runnable 生命周期与并发模型根据 wrap-api.md 中的pixie.Runnable协议定义class pixie.Runnable(Protocol[T]): classmethod def create(cls) - Runnable[Any]: ... async def setup(self) - None: ... async def run(self, args: T) - None: ... async def teardown(self) - None: ...生命周期要点create()—— 类方法构造并返回一个 runnable 实例setup()——async在第一次run()之前调用一次用于初始化共享资源可选默认是 no-oprun(args)——async为每个数据集条目并发调用最多 4 个并行args是由input_data构建并校验过的 Pydantic 模型在此调用应用的真实入口点teardown()——async在最后一次run()之后调用一次可选默认是 no-op。因为run()通过asyncio.gather并发调用你的实现必须并发安全。3.2 wrap 注册表在测试时的行为Step 5 的执行之所以能用测试数据替换外部依赖依赖的是wrap()在 eval 模式下的行为详见 wrap-api.mdpurposeinput在 eval 模式下返回注册表中的注入值。若data是 callable返回的包装器会忽略原函数、每次调用都返回注入值——从而阻止真实外部调用执行。purposeoutput/purposestate在 eval 模式下捕获输出/状态供构建Evaluable使用。这也是为什么在 2a-instrumentation 中强调对purposeinput的外部调用必须使用函数形式wrap(fetch_page, purposeinput, namefetched_page)(url)否则真实调用仍会执行导致测试变慢、不稳定、依赖外部服务可用性。3.3 并发安全必读的 Semaphore 模式由于条目并发运行Runnable 的run()方法必须并发安全。如果你看到sqlite3.OperationalError、database is locked或类似错误说明你的 Runnable 中共享了 SQLite 连接等可变状态需要在 Runnable 中加Semaphore(1)详见 Step 2 参考文档的并发安全章节。wrap-api.md 给出的标准做法class AppRunnable(pixie.Runnable[AppArgs]): _sem: asyncio.Semaphore classmethod def create(cls) - AppRunnable: inst cls() inst._sem asyncio.Semaphore(1) # serialise DB access return inst async def run(self, args: AppArgs) - None: async with self._sem: await call_app(args.message)常见并发陷阱来自 wrap-api.mdSQLite并发写入不安全——使用Semaphore(1)或aiosqlite并开启 WAL 模式全局可变状态在run()中修改的模块级 dict/list 需要保护限流 API加信号量以避免 429 错误。但注意只有当应用确实存在共享可变状态时才需要加信号量。如果应用使用按请求隔离的状态按唯一 ID 隔离或天然无状态并发调用自然是隔离的2b-implement-runnable。另外2b-implement-runnable.md 提醒不要在 runnable 文件中使用from __future__ import annotations——它会破坏 Pydantic 对嵌套模型的解析应改用带引号的返回类型- AppRunnable。四、5b只修复机制性问题这一阶段严格限定为修复你在前几步构建的东西——数据集、Runnable、自定义评估器。你修复的是阻止流水线运行的机制问题不是评估或改进应用的输出质量。4.1 属于机制性问题需要修复错误原因修复方式WrapRegistryMissError: namekey数据集条目缺少应用wrap(purposeinput, namekey)所期望的name对应的eval_input项在每个受影响的条目中向eval_input添加缺失的{name: key, value: ...}WrapTypeMismatchError反序列化后的类型与应用期望的类型不匹配修正数据集中的 valueRunnable 解析失败runnable路径或类名错误或类未实现Runnable协议修正数据集中的filepath:ClassName确保类有create()和run()方法导入错误runnable/evaluator 的模块路径或语法错误修正被引用的文件ModuleNotFoundError: pixie_qapixie_qa/目录缺少__init__.py运行pixie init重建TypeError: ... is not callable评估器名称指向不可调用的属性评估器必须是函数、类或可调用实例sqlite3.OperationalError并发的run()调用共享 SQLite 连接在 Runnable 中添加asyncio.Semaphore(1)见上文自定义评估器崩溃自定义评估器实现中的 bug修复评估器代码4.2 不属于机制性问题不要在此处修复应用产出错误/低质量输出→ 这是应用行为留待 Step 6 分析评估器分数偏低→ 这是质量信号留待 Step 6 分析应用内部的 LLM 调用失败→ 在 Step 6 中报告不要 mock 或绕过评估器分数在不同运行间波动→ LLM 非确定性的正常现象不是 bug这一修复边界的设计意图很关键Step 5 只保证管道通了至于分数高低、应用好坏必须在完整分析后才有意义。尤其要注意最后一点——LLM 评估天然带有非确定性分数波动不是你需要修的问题。4.3 迭代策略修复是循环过程修错误 → 重新运行 → 修下一个错误直到pixie test完整跑通、所有条目都产出真实评估分数。遇到意外错误参数名错误、导入失败、API 不匹配时不要靠猜——先阅读 wrap-api.md、evaluators.md 或 testing-api.md 获取权威 API 参考再动手修复。4.4 从源头减少机制性问题很多 Step 5 的报错其实可以在前序步骤预防eval_input缺失问题根据 4-build-dataset如果应用存在任何wrap(purposeinput)调用每个数据集条目都必须提供对应的eval_input值否则应用会在 eval 运行时发起真实外部调用。其 4c″ 节的数据集真实性审计硬门槛中就有eval_input完整性检查一项逐条核对每个 input wrap 是否都有对应条目。WrapTypeMismatchErroreval_input的值必须与wrap()调用返回的精确类型和格式匹配4-build-dataset 4b′ 节内容格式。以参考 trace 为模板复制数据形状而不是凭空构造。Runnable 解析失败数据集的runnable字段格式为pixie_qa/run_app.py:AppRunnable路径相对项目根目录且项目根目录会自动加入sys.path可直接用普通import引用项目模块wrap-api.md。五、输出结果目录结构pixie test成功运行后结果按条目存储到如下目录结构中{PIXIE_ROOT}/results/test_id/ meta.json # 测试运行元数据 dataset-{idx}/ metadata.json # 数据集名称、路径、runnable entry-{idx}/ config.json # 评估器、描述、期望 eval-input.jsonl # 提供给评估器的输入数据 eval-output.jsonl # 从应用捕获的输出数据 evaluations.jsonl # 评估结果已评分 待处理 pending trace.jsonl # LLM 调用 trace如已捕获各文件含义meta.json—— 本次测试运行的元数据时间、参数等dataset-{idx}/metadata.json—— 数据集名称、路径、runnable 引用entry-{idx}/config.json—— 该条目的评估器列表、描述description、期望expectationentry-{idx}/eval-input.jsonl—— 喂给评估器的输入数据entry-{idx}/eval-output.jsonl—— 运行应用时捕获的输出数据entry-{idx}/evaluations.jsonl——核心产物每条评估结果包含已评分的scored与待处理的pending例如 agent evaluator 产生的PendingEvaluationentry-{idx}/trace.jsonl—— LLM 调用 trace若已捕获。test_id会打印在控制台输出中。在 Step 6 你会引用这个目录按 SKILL.md 的硬性完成门槛Step 6 必须把evaluations.jsonl中每个status: pending条目替换为含score与reasoning的评分结果并为每个数据集目录生成analysis.md/analysis-summary.md、为测试运行根目录生成action-plan.md/action-plan-summary.md。六、与前后步骤的衔接循环规则来自 SKILL.md每次成功的pixie test都会创建具体的pixie_qa/results/test_id目录并开启一个新的分析周期。在修改应用代码、提示词、数据集、评估器或重跑pixie test之前必须先针对该结果目录完成 Step 6。不要跳过早期周期只分析最后一次运行。pixie test与pixie trace的关系测试阶段使用 eval 模式注册表注入输入、捕获输出而 trace 阶段运行真实依赖以捕获参考数据wrap-api.md 中wrap()在三种模式——no-op、tracing、eval——下的行为差异是理解整条流水线的钥匙。应用真实代码路径原则整个评估过程中应用的 LLM 调用必须走真实 LLM绝不 mock、stub 或拦截。如果项目自带测试套件中包含 LLM mock 模式那是项目自身单元测试用的不要移植到 eval Runnable 中SKILL.md。同理Step 5 遇到应用内部 LLM 调用失败也不能用 mock 绕过而应在 Step 6 报告。七、小结Step 5 是评估驱动开发流水线中从构建到验证的转换点。记住三条核心原则目标纯粹只修管道问题数据集格式、Runnable 可运行性、评估器可调用性不评质量、不改应用理解执行模型Runnable 生命周期create → setup → 并发 run → teardown、wrap 注册表注入、并发安全Semaphore是排查一切报错的基础产出明确pixie test完整跑通、所有条目有真实分数后立即进入 Step 6 分析——结果目录{PIXIE_ROOT}/results/test_id/是后续所有分析工作的数据基础。想深入 API 细节的读者可直接查阅 testing-api.md数据集 JSON 格式、评估器名称解析、Evaluable/Evaluation/ScoreThreshold类型、wrap-api.mdRunnable 协议、wrap()三种模式、错误类型与 evaluators.md内置评估器选择指南、自定义评估器工厂函数。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考