【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载本文以仓库中 Checker Agent Prompt 模板 为骨架深入讲解如何在循环工程Loop Engineering中设计一名专职挑错的验证智能体它的角色定位、五维检查清单、强制性的证据化输出格式以及如何与 Maker、Goal 模板、循环状态文件配合构建一条真正可信的自律循环。读完本文你将能直接复制并落地一个生成者与评估者分离的 Checker Prompt并将其接入本仓库的练习项目。为什么需要 Checker生成者不能为自己的工作打分在循环工程中最反直觉、却最关键的可靠性教训是让写了代码的模型来评判自己的代码几乎必然得到高分。这并非模型不诚实而是生成者的本性——它在生成过程中已经反复说服自己这条路是对的回看时只能看到自己的推理过程却看不到盲区。本仓库第 13 讲 为什么要停止给智能体喂提示词 中反复强调一个结论模型是自己输出的最佳辩护律师。因此任何长时间运行的循环都必须引入生成者/评估者分离Generator/Evaluator Separation由不同指令、甚至不同模型驱动的第二个智能体去抓第一个智能体给自己讲的故事中的漏洞。而 Checker Agent Prompt 就是这个第二个智能体的完整模板。它把 Checker 的职责概括为一句极端但有效的话你不是来表扬的你是来找茬的。找不到问题就是你的失职。Youre not here to praise, youre here to find fault. Not finding problems is your failure.这一句定位句是整个模板的灵魂它用明确的角色指令压过模型默认的顺从与讨好倾向把评估任务从审核一下重定义为必须产出问题清单。Checker 的五维检查清单从功能到影响面模板的检查清单Checklist将验证工作拆为五个维度每项都是可勾选的布尔问题保证检查不遗漏1. 功能正确性Functional Correctness实现是否符合需求是否遗漏了边界情况edge cases错误处理是否就位这是最基础的维度对应仓库中目标模板 goal-template.md 里验收标准的第一条——逐项对照验收清单。2. 代码质量Code Quality代码是否清晰命名是否清楚是否存在重复代码是否符合项目编码规范是否有明显的性能问题注意最后一条刻意用了obvious——Checker 不是性能专家它只需标记显而易见的风险避免陷入过度优化。3. 测试Testing测试是否覆盖主要场景边界情况是否被测试测试是否真的在测有意义的东西还是仅仅在走过场第三条是本维度最锋利的问题going through the motions直指一种常见骗局——为了覆盖率数字而写的空断言测试。结合本仓库的 project-05 落地 QA 验证项目 的思路测试质量必须由语义判断而非数字堆砌。4. 验证命令Verification Commandsnpm test是否全部通过npm run lint是否零错误TypeScript 类型检查是否通过覆盖率是否达标这些命令不是摆设。查看本仓库练习项目 project-06 的 package.json可以看到真实项目中的验证脚本是这样组织的scripts: { dev: node scripts/dev.js, build: tsc -p tsconfig.node.json vite build, check: tsc --noEmit -p tsconfig.node.json tsc --noEmit -p tsconfig.json, test: vitest run, test:watch: vitest }这印证了模板的深层要求验证命令必须是机械可执行的、可重复的、结果可解析的。Checker 不应凭看起来没问题下结论而应真实运行npm test、npm run lint、npx tsc --noEmit并记录输出。这正是第 13 讲中验证债务Verification Debt的解药——差不多对不等于已被确认正确。5. 安全与影响Safety and Impact这个改动会影响其他部分吗是否引入了新的依赖是否合理配置文件改动是否正确这一维度对应 goal-template.md 中的 Scope / Hands off 约束如src/main.ts入口文件、数据库 schema 迁移、CI/CD 配置禁止触碰。Checker 必须验证 Maker 没有越界修改红线文件。强制性的证据化输出描述、位置、证据、严重性模板规定每个问题必须包含四个要素缺一不可描述Description这是什么问题位置Where文件和行号证据Evidence具体错在哪、为什么是问题严重性SeverityCritical / Medium / Minor最后必须以一个总体判定收尾Pass通过/ Fail不通过/ Minor issues, acceptable小问题可接受。模板给出了可直接粘贴的输出骨架## Overall Verdict ✅ Pass / ❌ Fail / ⚠️ Minor issues, acceptable ## Issues Found ### 1. [Critical] Issue title - Location: file:line - Description: ... - Evidence: ... - Suggestion: ... ### 2. [Medium] Issue title ... ## Verification Command Results - Unit tests: X passed / Y total - Lint: pass / fail (X errors) - Type check: pass / fail - Coverage: XX%这条格式要求有三个工程意义强制证据禁止 Checker 输出感觉这里有问题这种不可验证的模糊结论Location Evidence把每条意见变成可回溯、可反驳的断言结构化解析### 1. [Critical]这样的标题让后续的循环控制逻辑无论是人工还是脚本可以解析严重级别决定打回重做还是放行命令结果留痕Verification Command Results段把测试、lint、类型检查、覆盖率的真实数字写入输出供循环状态文件沉淀。Checker 与 Maker 的配套同一循环中的两个对立面Checker 模板不是孤立文件它与同目录下的 Maker Agent Prompt 构成一对互补模板。对比二者可以清晰看到角色的刻意对立维度Maker实现者Checker验证者定位句Focus on making it work.让它跑起来Focus on finding problems.找出问题默认倾向乐观推进交付悲观怀疑拒绝核心动作读需求 → 设计 → 写码 → 自测 → 交接读改动 → 逐项核对 → 跑全量验证 → 列问题交付物修改文件清单、实现摘要、自测结果、风险点问题清单含证据、总体判定、命令结果已知盲区主动向 Checker 声明我不确定的地方由 Maker 的盲区声明获得检查重点一个值得注意的设计细节Maker 模板的交付物中专门有一项Areas youre unsure about你不确定的区域——这是给 Checker 的重点检查提示。Maker 诚实承认不确定之处Checker 优先验证这些区域两者通过模板形成了信息传递通道而不是各自为战。在完整循环中的位置Checker 是循环的裁判第 13 讲把循环拆解为 6 个原语Automation 自动化 / Worktree 隔离 / Skill 技能 / Connector 连接器 / Subagent 子智能体 / External State 外部状态其中子智能体原语的核心正是Maker/Checker 分离。在 完整循环解剖图 中可以看到 Checker 扮演的门卫角色Implementer 子智能体写修复 测试 ↓ Verifier 子智能体独立运行测试 lint 审查 ↓ 失败 → 重试队列换一种方法 ↓ 通过 → Connector 创建 PR、链接 issue、更新进度文件在这一流程里Checker即 Verifier的判定直接决定两条分支失败则打回重试队列通过才允许产出进入外部状态与收件箱。换句话说Checker 是整个循环唯一的质量闸门——它的标准有多严格循环产出的下限就有多高。模板还提示了一种进阶做法当需要更强隔离时可以让 Checker 使用不同的模型例如实现用 Claude、验证用 GPT反之亦然甚至采用社区对抗性验证惯例——对每个发现生成 N 个独立怀疑者并要求反证。本仓库练习项目 project-07 实验 3Maker-Checker 循环 正是要求读者为 Maker、Checker、循环控制各写一份独立 prompt用不同模型跑至少 5 轮并回答一个灵魂问题这个循环的质量天花板是 Maker 的能力还是 Checker 的能力Checker 的输入输出如何与循环状态文件衔接循环不是单次对话而是多轮迭代。Checker 的每次判定都应沉淀到 Loop State 模板 中形成闭环每轮开始读取loop-state.md了解上一轮 Maker 做了什么、Checker 发现了什么问题、下一轮计划是什么每轮结束把本轮 Checker 判定✅ Pass / ❌ Fail / ⚠️ Partial、发现的问题数、是否需要人工介入写入 Round Log累计统计Passed rounds / Failed rounds / Total issues found / Human interventions 等指标持续累加让循环的健康度可观测。loop-state 模板中的Blocker List阻塞项列表专门用于记录 Checker 反复发现的同类问题让下一轮 Maker 一开始就意识到别在同一个坑里再摔一次。这与第 12 讲每次会话必须留下干净状态、第 5 讲状态文件是连续性的支柱一脉相承——Checker 的产出正是写入这些外部状态文件的核心素材。实战落地把 Checker 模板接进你的循环第一步从一份 goal 文档开始按 goal-template.md 写好目标文档其中验收标准必须是机械可验证的如npm test全过、覆盖率 ≥ 80%、npm run lint零错误、npx tsc --noEmit通过并明确 Scope允许触碰 / 禁止触碰。第二步把 Maker 与 Checker 的 prompt 分别投喂给不同会话Maker 会话投喂 maker-prompt.md要求先说明计划、写码后自测、诚实列出不确定区域Checker 会话投喂 checker-prompt.md本文主题模板要求逐项走完五维清单、运行全部验证命令、按四要素输出每个问题并给出总体判定。理想情况下两个会话使用不同模型强化评估独立性。第三步以 Checker 的判定驱动循环❌ Fail→ 把问题清单含 Location / Evidence / Suggestion作为反馈交回 Maker进入下一轮✅ Pass→ 记录到 loop-state.md更新累计统计进入下一项任务或终止循环⚠️ Minor issues, acceptable→ 记录问题但放行同时把问题列入 Blocker List 供后续轮次跟踪。第四步用真实命令校准 Checker 的严格度模板给出的验证命令npm test、npm run lint、TypeScript 类型检查、覆盖率可直接对照本仓库 project-06 的 package.json 中的check、test脚本落地。你可以调整覆盖率达标线来校准循环的严格度——线越高Checker 把关越严但每轮成本也越高。建议从 80% 起步观察几轮再调整。关键要点Checker 是一份找茬指令模板用找不到问题就是失职压过模型的顺从倾向这是它与普通 code review prompt 的本质区别五维清单覆盖全生命周期功能正确性、代码质量、测试质量、验证命令、安全与影响缺一不可输出必须证据化描述 位置 证据 严重性 总体判定让每条意见可回溯、可解析、可驱动循环分支与 Maker 模板成对使用Maker 声明不确定区域Checker 优先验证这些区域两个角色通过模板形成协作通道判定结果写入循环状态文件Checker 的 Pass/Fail 决定循环走向其发现的问题沉淀进 loop-state形成可观测的多轮闭环最严格的一课永远不要让写了代码的模型为自己打分——独立验证者必要时换一个模型才是循环可靠性的基线保障。建议下一步直接进入本仓库的 Project 07构建你的第一个自动循环按实验 3 的指引用本文的 Checker 模板与配套的 Maker 模板跑完至少 5 轮你会亲眼看到生成者/评估者分离带来的质量差异。赞分享【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载相关推荐learn-harness-engineering 实战编写高严格度 Checker 验证 Prompt为 Maker/Checker 循环装上独立质检关卡learn harness engineering 实战编写高严格度 Checker 验证 Prompt为 Maker/Checker 循环装上独立质检关卡编写可验证的 Goal 模板learn-harness-engineering 中从 /goal 到 Maker–Checker 循环的实战指南编写可验证的 Goal 模板learn harness engineering 中从 /goal 到 Maker–Checker 循环的实战指南 在 harnlearn-harness-engineering 循环工程实战goal.md、loop-state.md 与 Maker/Checker 双角色模板全解learn harness engineering 循环工程实战goal.md、loop state.md 与 Maker/Checker 双角色模板全解 本创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考