【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载端到端测试E2E是 AI 编码智能体coding agent验证体系中唯一能证明系统级缺陷不存在的环节单元测试全部通过组件边界缺陷却可能一个都抓不到。本篇以 learn-harness-engineering 仓库中《강의 10. 엔드투엔드 테스트만이 진정한 검증이다》含配套代码示例与评审反馈转规则示例为骨架结合 projects/project-05/ 的 Electron 知识库应用源码讲清四件事单元测试为什么系统性盲视组件边界缺陷、E2E 如何改变智能体的编码行为、如何把架构约束与反复出现的评审意见自动化成可执行的检查以及怎样编写面向智能体的修复式错误消息。读完你将得到一套可复制的分层验证与规则固化方案。一、问题场景五个组件边界缺陷单元测试一个都没抓到课程给出了一个极具代表性的场景让智能体为 Electron 应用实现文件导出功能。智能体依次完成了渲染进程组件、preload 脚本、服务层逻辑并为每个组件编写了单元测试——全部通过。智能体宣布完成。然而当真实用户点击导出按钮时文件路径格式错误渲染进程传相对路径preload 期待绝对路径进度条不更新导出进度没有通过 IPC 传回 UI大文件导出时内存泄漏文件句柄未释放打包环境下的权限差异服务层异常没有传播到 UI 层。共五个跨组件边界缺陷单元测试零检出。这不是巧合而是单元测试隔离设计哲学的必然结果——正如课程中合唱排练的比喻每个声部戴着头戴耳机单独练习时都很完美合到一起就有人快半拍、伴奏低半音。仓库配套的 e2e-runner.ts 用最小实现把这种现象量化了出来三个真实场景导入文档并提问、删除文档并验证移除、多用户并发访问下每个步骤的单元测试都标记为unitTestPasses: true但流水线实际行为actualBehavior却是partial或fails——例如索引器与检索器的 embedding 维度不匹配导致检索结果为空、索引清理超时留下孤儿 chunk、检索缺少用户级隔离导致跨用户结果串扰。运行npx tsx docs/ko/lectures/lecture-10-why-end-to-end-testing-changes-results/code/e2e-runner.ts后输出会明确显示False confidence count: 3 of 3即三组测试全部是单元测试通过但 E2E 失败直观证明了仅靠单元测试会产生虚假信心false confidence。二、单元测试的四个系统性盲点课程将单元测试的盲区归纳为四类每类都有清晰的成因接口不一致Interface Mismatch渲染进程传给 preload 的是相对路径preload 期待绝对路径。由于单测各自用 mock双方各自正确只有真实流程跑起来才会暴露。对应源码中的表现就是 preload.ts 通过contextBridge暴露类型化 API若渲染侧直接拼路径、绕过该桥接层单测永远发现不了签名错配。状态传播错误State Propagation Errors数据库迁移改了表结构但 ORM 缓存层还持有旧 schema 的缓存项。单测每次提供全新 mock 环境自然暴露不了跨层状态不一致。资源生命周期问题Resource Lifecycle Issues文件句柄、数据库连接、网络 socket 的获取与释放分散在多个组件。单测为每个测试独立创建、销毁资源测不出资源竞争与泄漏。环境依赖Environment Dependency代码在一切被 mock 的测试环境中正确却在真实环境因配置差异、网络延迟或服务不可用而失败。课程的结论是单测是 Google 测试金字塔的底座但止步于单测就会系统性地错过组件交互问题。对 AI 编码智能体而言危害更甚——智能体倾向于只跑最快的测试就宣告完成。三、E2E 不只改变结果更改变智能体的行为这是课程最容易被忽略的洞察当智能体知道自己提交的成果会被 E2E 检验时它的编码行为本身会提前改变主动考虑组件交互写代码时会想这个接口如何与上游衔接而不是只盯着单个函数。遵守架构边界在存在架构约束的系统中E2E 强制智能体遵循边界规则如同乐谱上标了渐强记号就必须照做。处理错误路径E2E 通常包含失败场景迫使智能体考虑异常处理——排练时模拟麦克风突然没声真上台就不慌。课程中的 mermaid 图清晰地对比了两种验证视角单元测试只在隔离的部件层面分别检查 Renderer / Preload / ServiceE2E 则让Renderer 按钮点击 → Preload 桥 → 服务层 → 文件系统/OS → 真实导出文件整条链路真实贯通。四、验证分层把 E2E 明示为完成的前置条件课程给出了直接可用的验证层级模板建议写进 harness智能体运行框架的指令文件## 검증 계층 구조验证层级结构 - 레벨 1: 단위 테스트단위 테스트必须通过 - 레벨 2: 통합 테스트통합 테스트必须通过 - 레벨 3: 엔드투엔드 테스트E2E 테스트跨组件变更时必须通过 - 필수 레벨 건너뛰기 완료 아님跳过必检层级 未完成关键原则凡涉及跨组件变更的任务E2E 通过是完成的前提条件。这与仓库中 Project 05 的Definition of Done完全同构——gen-eval/AGENTS.md 明确要求the required verification actually ran要求的验证真实跑过且scripts/check-architecture.sh零违规才算完成并禁止只是加了代码就标记功能完成。五、架构规则自动化从文档上写着到CI 里跑着E2E 的前提是清晰可执行的系统边界。课程引用 OpenAI 的工程实践强调对智能体生成的代码库而言架构约束不是团队壮大后才考虑的事而是第一天就要确立的初始前提。原因是智能体倾向于复制仓库里的既有模式模式若不均匀智能体每个会话都会引入更多偏差。仓库中的落地示例是 check-architecture.sh它把 ARCHITECTURE.md 声明的分层边界变成了机器可执行的检查检查 1src/renderer中不允许出现fs|path|os|child_process等 Node.js 核心模块 importgrep -qE import.*\b(fs|path|os|child_process)\b检查 2src/services不允许 importelectron也不允许出现ipcMain|ipcRenderer|BrowserWindow标识检查 3src/services与src/main不允许 import React。任何违规都会累计到VIOLATIONS计数最终以非零退出码exit 1让 CI 失败。这正好把课程中的基础 grep 命令升级为完整的边界守卫# 렌더 프로세스가 Node.js API를 직접 호출하는지 검사检查渲染进程是否直接调用 Node.js API grep -r require(fs) src/renderer/ exit 1 || echo OK: no direct fs access in renderer架构文档 ARCHITECTURE.md 进一步定义了四层职责Renderer仅通过window.knowledgeBase访问数据禁止核心模块与 Electron API、Preload仅经contextBridge.exposeInMainWorld暴露类型化 API只做通道映射、Main仅做请求路由委托服务层、Services承载全部业务逻辑文件系统访问一律走PersistenceService。这种强制不变量、不微观管理实现的做法正是课程强调的核心原则——例如规定数据在边界处被解析但不指定用哪个库。六、评审反馈转规则让 harness 逐月自动变强课程配图文件 review-feedback-to-rule.md 浓缩了本节主题——一条反复出现的评审意见被晋升为 harness 规则评审意见不要在渲染器中直接调用文件系统工具请使用 preload 桥。晋升后的规则增加 lint 或 import 规则禁止渲染进程代码中使用fs增加说明 preload 边界的修复提示文本。这就是课程定义的评审反馈晋升Review Feedback Promotion每当代码评审发现一种新型智能体错误就把它转成自动化检查。一个月后harness 会比一个月前显著更强——像合唱团的排练笔记每次排练记录下来的问题下次排练前就会被自动拦截。配套的 mermaid 流程图展示了完整闭环Review(评审反馈: 渲染器不能直接 import fs) → Rule(增加 fs import 检查) → Message(错误消息告知智能体把文件访问移到 preload) → Harness(把检查加入 harness) → Stronger(下次立即失败)在 Project 05 的 evaluator-rubric.md 中可以看到同一模式在评审→修订维度的实证初始评分 2.8/5平铺列表、无气泡、基础时间戳经两轮修订后升至 3.3/5气泡样式、引用计数徽章、空状态、120 字符截断每轮修订都留下明确的证据记录——这正是把评审反馈固化为可复现的规则在数据上的体现。七、面向智能体的错误消息不只是报错而是给出修复指令课程引用 OpenAI 的强调为智能体编写的错误消息必须包含修复指引。不要说渲染器直接访问了文件系统而要说ERROR: Found direct import of fs in src/renderer/App.tsx:12 WHY: Renderer process has no access to Node.js APIs for security FIX: Move file operations to src/preload/file-ops.ts and call via window.api.readFile()消息三要素什么错了WHAT、为什么WHY、怎么改FIX。这才把测试失败变成自修复反馈回路——如同指挥家不说你错了而是说你这里快了半拍听一下中提琴的节奏第 32 小节进。仓库源码完整体现了这条原则的架构形态。分层职责由 preload.ts 承担——渲染进程不碰任何 Node 模块一切文件与索引操作都通过contextBridge暴露的window.knowledgeBase类型化 APIdocuments.list/import/get/delete、indexing.start/status/chunks、qa.ask/history走 IPC。当智能体违反边界时check-architecture.sh 输出的VIOLATION: file imports Node.js core module会明确指出违规文件和具体 import配合WHY与FIX消息智能体就能自动把调用迁到正确层级。八、成本与收益15 秒的代价换来系统级保障课程给出了关键的成本数据在该案例中5 个缺陷全部由 E2E 抓住、单测一个没抓到而代价只是测试时间从 2 秒增加到 15 秒——在智能体工作流中完全可以接受。课程总结了五条核心结论单元测试对组件边界缺陷是系统性盲视的——隔离设计本身决定了它测不出交互问题E2E 不仅能抓缺陷还会改变智能体的编码行为——让它更关注集成与边界架构规则必须可执行——不是写进等人来读的文档而是在每次提交时被自动检查错误消息要为智能体而设计——包含如何修复的具体步骤形成自修复回路评审反馈晋升自动强化 harness——每一类被抓到的缺陷都成为永久防线。配套的演练建议见课程原文末尾연습 문제选择一个涉及至少三个组件的修改先只跑单测记录结果再跑 E2E 对比多抓到的缺陷类型挑一条架构约束改造成带智能体友好消息的可执行检查并集成进 harness从评审历史中找反复出现的意见类型用评审反馈晋升流程固化为自动检查对比晋升前后的问题频率。这套方法在 projects/project-05/ 的starter与solution三种变体single-role / gen-eval / plan-gen-eval中均可直接实操验证。赞分享【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载相关推荐将 Review 反馈提升为 Harness 规则learn-harness-engineering 中端到端验证驱动的审查反馈闭环将 Review 反馈提升为 Harness 规则learn harness engineering 中端到端验证驱动的审查反馈闭环 本文基于 learn hlearn-harness-engineeringElectron 架构规则的 Harness 落地——从约束文档到可执行的端到端验证learn harness engineeringElectron 架构规则的 Harness 落地——从约束文档到可执行的端到端验证 本教程对应 第 10learn-harness-engineering 第十讲实战只有端到端测试才算真正验证——从 e2e-runner 到可执行架构规则的 Agent 验证闭环learn harness engineering 第十讲实战只有端到端测试才算真正验证——从 e2e runner 到可执行架构规则的 Agent 验证闭环上一篇华硕笔记本终极性能控制指南G-Helper免费开源工具完整教程下一篇3分钟掌握Pixelle-VideoAI全自动短视频创作终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考