【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载本文基于 learn-harness-engineering 课程第 10 讲为什么端到端测试改变结果的配套示例review-feedback-to-rule.md讲解如何把反复出现的代码审查意见转化为 harness 中可自动执行、agent 可读懂的规则。读完本文你将掌握审查反馈提升Review Feedback Promotion的完整落地方法从一条 review 评论出发拆解出 lint/导入检查与修复指导两个构件并借助仓库内真实的check-architecture.sh、分层架构文档与端到端测试示例在 harness 中建立自动修正的反馈闭环。从一个真实的 Review 反馈开始第 10 讲配套代码示例review-feedback-to-rule.md记录了一条典型的、反复出现的审查意见以及它被提升为 harness 规则后的产物审查意见Review 评论不要在 renderer 里使用文件系统工具请使用 preload 桥。提升后的 harness 规则包含两个部分添加一条 lint 规则或导入检查禁止在 renderer 代码中使用fs添加一段修复说明remédiation文本解释 preload 边界应当如何使用。这条示例虽短却浓缩了 harness 工程中一个极其重要的机制把靠人反复提醒的审查意见转变成每次提交自动拦截的机器检查。它与第 10 讲讲稿正文见index.md中的审查反馈提升概念一一对应也是讲稿中第二个流程图的直接落地。为什么人肉 Review在 agent 工作流中必然失效在传统开发中代码审查由资深工程师执行意见可以被口头传递。但在 AI 编码 agent 的工作流中这条路径有两个结构性缺陷agent 会复制仓库中的既有模式。正如讲稿引用的 OpenAI 经验agent 会复制仓库中已有的模式即使这些模式是不均匀或次优的。如果架构边界只写在文档里agent 每次会话都会引入新的偏差而不会主动查阅文档。review 反馈是一次性的、不可复用的。每次新会话都是一个新的上下文上一次 review 中给出的教训不会自动传承。没有机器检查兜底同一个renderer 直接 import fs的错误会在不同会话中反复出现。因此讲稿给出的判断是架构约束必须是第一天就建立的早期前置条件而不是等团队规模变大后再考虑的事情。而把审查反馈提升为规则正是把人的判断沉淀为机器的检查让 harness 随着每次 review 自动变强——这正是review-feedback-to-rule.md示例所演示的动作。提升规则的两个构件可执行检查 修复指导从示例可以看出一条 review 反馈提升为规则需要同时产出两个构件缺一不可构件作用示例可执行检查让违规行为在提交/CI 时立刻失败lint 规则或导入检查禁止 renderer 中出现fs修复指导文本告诉 agent 正确做法是什么解释 preload 边界文件访问必须移到 preload仅做检查、不给修复指导agent 只会看到一行模糊的报错无法自主修正仅写文档、不做检查则又回到了写在纸上等人来看的老路。两者结合才能把架构规则变成自动修正的闭环。讲稿中用了一个生动的比喻合唱指挥不会只说你唱错了而是会说你这里快了半拍听中音部的节奏在第 32 小节进。同理面向 agent 的错误消息必须包含修复指令。仓库源码印证真实的分层边界与检查脚本这条规则在仓库中有完整的真实实现。第 5 个实战项目projects/project-05/README.md的 starter 中架构边界由三份文件共同定义docs/ARCHITECTURE.md定义四层分层架构Renderer → Preload → Main Process → Services → Persistence明确每层的职责与禁止事项scripts/check-architecture.sh把架构约束翻译成可执行检查AGENTS.md要求 agent 在提交前运行检查并把check-architecture.sh 零违规列为完成的定义之一。check-architecture.sh正是审查反馈提升思想的机械执行版本它检查三类边界违规# 检查 1renderer 不得 import Node.js 核心模块fs/path/os/child_process RENDERER_FILES$(find src/renderer -name *.ts -o -name *.tsx 2/dev/null || true) if [ -n $RENDERER_FILES ]; then while IFS read -r file; do if grep -qE import.*\b(fs|path|os|child_process)\b $file 2/dev/null; then echo VIOLATION: $file imports Node.js core module VIOLATIONS$((VIOLATIONS 1)) fi done $RENDERER_FILES fi # 检查 2services 不得 import Electron IPC # 检查 3services/main 不得 import React脚本以退出码区分结果exit 0表示全部通过exit 1表示存在违规从而可以被 CI、pre-commit hook 或 agent 的验证流程直接调用。这与讲稿中的命令示例一脉相承# 检查渲染进程是否直接调用 Node.js API grep -r require(fs) src/renderer/ exit 1 || echo OK: no direct fs access in renderer注意其中的差异讲稿示例用一条grep完成检查仓库实现则用findgrep -qE的正则匹配能同时覆盖import ... from fs与ipcMain、BrowserWindow等更多违规形态。这说明从一条 review 反馈到规则是一个可以逐步加强、持续迭代的过程——每发现一种新的违规形态就往检查里加一个模式。而ARCHITECTURE.md中对应的边界约束是Renderer 层不得importfs、path、os、child_process等 Node.js 核心模块不得直接访问 Electron API所有数据访问必须经由 preload 桥window.knowledgeBasePreload 层不得包含业务逻辑仅通过contextBridge.exposeInMainWorld暴露类型化 APIServices 层不得import Electron 或 React所有文件系统访问必须经过PersistenceService。这些约束与第 10 讲配套的architecture-rules.md完全一致后者以四条规则形式总结了 Electron 应用的架构边界renderer 不能直接访问文件系统、preload 是 renderer 与 main 之间的唯一桥、数据抓取与索引逻辑位于 service 模块而非 UI 组件、日志必须结构化且从服务边界输出。设计面向 agent 的错误消息三要素检查脚本负责发现违规但让 agent 能自主修正靠的是错误消息本身。讲稿给出了面向 agent 的错误消息三要素——什么出了问题、为什么、怎么修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()对照示例中的规则产物添加一段修复说明文本正是这条消息里的FIX部分。消息中同时给出违规位置src/renderer/App.tsx:12、违规原因渲染进程出于安全原因无权访问 Node.js API、以及具体修法把文件操作移到src/preload/file-ops.ts通过window.api.readFile()调用。这正是 OpenAI 在 Codex 工程实践中强调的原则为 agent 写的错误消息必须包含修复指导把测试失败变成自我修正的反馈循环。把反馈提升固化进验证层级要防止 agent 在单测通过后过早宣布完成讲稿建议在 harness 的验证流程中显式定义验证层级## 验证层级 - 层级 1: 单元测试 (必须通过) - 层级 2: 集成测试 (必须通过) - 层级 3: 端到端测试 (涉及跨组件修改时必须通过) - 跳过任何必须层级的任务 未完成跳过任何必须层级 未完成是关键条款它把跑完整流程从可选项变成完成的前置条件直接对抗 agent 倾向于只跑最快测试就宣告完成的习惯。与之呼应AGENTS.md中的 Definition of Done 明确列出目标行为已实现、必需的验证确实运行过、证据已记录在最终总结中、scripts/check-architecture.sh零违规通过。审查反馈提升的五步流程结合示例与讲稿把一条 review 反馈提升为 harness 永久防线的完整流程如下识别重复问题在代码审查中发现某类错误反复出现如renderer 直接 import fs提炼检查规则把它变成可执行的 lint 或导入检查grep、find grep -qE、eslint 插件均可编写修复指导在报错消息中加入FIX指令告诉 agent 正确路径与调用方式加入 harness把检查接入 CI 或 pre-commit 验证流程使每次提交自动执行持续加强下个会话若出现新违规形态扩展检查模式harness 自动变强。正如讲稿所说每次发现重复问题就加一条规则一个月后 harness 会比月初强得多每个被捕获的缺陷类别都变成一条永久防线。端到端测试让提升后的规则真正改变结果review 反馈提升与端到端测试是同一枚硬币的两面。第 10 讲讲稿的核心论点是单元测试对组件边界缺陷系统性盲视——接口不匹配、状态传播错误、资源生命周期问题、环境依赖这四类缺陷单测因隔离设计几乎必然漏掉只有端到端测试能证明系统级缺陷不存在。配套的e2e-runner.ts用三个用例演示了这一现象npx tsx可直接运行导入文档并提问、删除文档并验证移除、多用户并发访问。每个用例中所有步骤的单元测试都标记为PASS但端到端模拟的真实行为却因维度不匹配、索引残留、用户隔离缺失而失败——最终输出False confidence count: 3 of 3即单元测试全部通过而端到端全部失败。讲稿给出的实战案例同样印证在一个 Electron 文件导出功能中端到端测试捕获了接口不匹配、状态传播、资源泄漏、权限问题、错误传播共 5 个缺陷单元测试一个都没发现代价仅是测试时间从 2 秒增加到 15 秒——在 agent 工作流中完全可接受。因此审查反馈提升的最终目标不只是有检查而是让检查与端到端验证协同规则负责在编码阶段拦截已知违规端到端测试负责在系统层面捕获未知的组件交互缺陷。两者共同构成 harness 中从预防到验证的完整防线。概念速查审查反馈提升Review Feedback Promotion把反复出现的代码审查意见转化为自动化检查每次发现重复问题就加一条规则harness 自动变强架构边界执行规则把架构文档中的规则如渲染进程不能直接访问文件系统变成可执行、自动化的检查从写在纸上变成跑在 CI 里面向 agent 的错误消息失败信息不只说出了什么问题还要包含WHY与FIX让 agent 能够自主完成修正组件边界缺陷组件 A、B 各自单测通过但交互产生错误行为是端到端测试最擅长捕获的问题类型测试充分性梯度单元测试可检测缺陷 ≤ 集成测试 ≤ 端到端测试每往上一层检测能力增强。关键要点一条 review 反馈提升为规则需要可执行检查 修复指导两个构件同时落地缺一不可架构规则必须可执行每次提交自动检查而不是写进文档等人来看错误消息要面向 agent 设计用ERROR/WHY/FIX三要素把测试失败变成自我修正闭环端到端测试不仅检测缺陷还改变 agent 的编码行为迫使其考虑组件交互、尊重架构边界、处理错误路径仓库中check-architecture.sh、ARCHITECTURE.md与AGENTS.md构成了这套机制的可运行参考实现可直接在项目 5 的 starter 中bash scripts/check-architecture.sh验证其行为。赞分享【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载相关推荐learn-harness-engineering 实战把 Review 反馈升级为自动化 Harness 规则Review Feedback Promotionlearn harness engineering 实战把 Review 反馈升级为自动化 Harness 规则Review Feedback Promot审查反馈提升把一条重复评审意见固化为 harness 自动化规则——learn-harness-engineering 架构约束执行实战审查反馈提升把一条重复评审意见固化为 harness 自动化规则——learn harness engineering 架构约束执行实战 导读在 Agent保存RDD到文件reference-apps大数据导出实战教程保存RDD到文件reference apps大数据导出实战教程 Apache Spark 是大数据处理的核心引擎而 reference apps 正是 Da上一篇终极指南30分钟用OpCore-Simplify完成OpenCore EFI自动化配置下一篇Pandoc 全解析通用标记转换器的格式矩阵、Reader/Writer 模块化架构与源码级实现创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考