Claude Code Harness 验证链设计：worker-report 与 review-result 证据包如何闭环

Claude Code Harness 验证链设计worker-report 与 review-result 证据包如何闭环【免费下载链接】claude-code-harnessClaude Code Dedicated Development Harness - Achieving High-Quality Development Through an Autonomous Plan→Work→Review Cycle项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-harnessClaude Code Harness 是一款围绕 Claude Code 打造的开发脚手架Harness核心是让 AI 自主完成 Plan → Work → Review 的开发循环。而决定这个循环可信度的正是它内置的验证链verification chainWorker 完成编码后产出worker-report自审报告Reviewer 产出review-result评审结论两者作为证据包evidence pack在 Accept 验收环节被机械读取最终让能不能 ship的判定有据可查而不是靠 AI 口头声称完成了。本文面向新手和普通用户用尽量少的代码讲清楚这份证据包长什么样、在哪里落地、又是如何首尾相接形成闭环的。为什么需要证据包先说痛点。让 AI 写代码最容易出现的信任危机是做了体日语里叫やった体环节没有证据包时的表现有验证链之后Worker 交付只在对话里口头说都改好了没有任何落盘记录自审 5 项全部带证据后写入worker-report.json文件Reviewer 评审浏览器验证环境不足时静默降级结论依然是绿色未验证项显式记入pending_validations失败要可见Accept 验收LLM 凭记忆重新申报一遍结果脚本机械读取 4 类产物缺哪项、pending 哪项都写进验收记录一句话验证机构配线了不等于生效了。项目用一条可机械校验的验证链把入口、中间、出口三个环节全部接上详见 CHANGELOG.md 中 Phase 134 的验证链配线修理章节。入口worker-report 如何落地为文件Worker 的执行契约定义在 agents/worker.md其中 CLAUDE.md 第 97 行也有摘要Worker 交付时必须提交worker-report.v1并自审 5 条规则dry-violation-none—— 没有违反只读dry约束plans-cc-markers-untouched—— 没有擅自改写 Plans.md 的任务标记all-declared-symbols-called—— 声明的符号都有被调用dod-items-verified-with-evidence—— DoD 项逐条验证no-existing-test-regression—— 既有测试无回归关键设计是每一条规则必须给出verified: boolean加上evidence字段比如 grep 执行结果、测试日志路径不允许只写我确认没问题。而且只有当 5 项全部verified: true且 evidence 非空时Worker 才在 commit 前把报告写入.claude/state/review/task-id.worker-report.json任何一项是verified: false就不落盘直接打回修改最多 2 次 amend超出后升级人工。这份文件就是证据包的第一块拼图Worker 的自我证明从对话里搬进了磁盘上。中间write-review-result.sh 如何规范化评审结论评审侧的核心脚本是 scripts/write-review-result.sh。它的工作是把五花八门的评审输出静态评审、浏览器实测、companion 判定统一归一化为review-result.v1结构默认写到.claude/state/review-result.json。它做了三件对闭环至关重要的事① 合并双路 verdict。静态评审与浏览器实测各有一个结论脚本用combine_verdict规则合并任一方REQUEST_CHANGES即整体REQUEST_CHANGES只有双 APPROVE 才是 APPROVE。② 强制拦截。只要 gaps 里存在 critical/high/major 级别的问题即使 verdict 字段写的是 APPROVE也会被强制改写成REQUEST_CHANGES脚本 write-review-result.sh 第 218-222 行。评审结论不可能带病放行。③ fail-visible未验证项必须可见。当浏览器评审实际是PENDING_BROWSER/SKIPPED/DOWNGRADE_TO_STATIC这类退场标记或者 runtime 评审上报 SKIPPED 时脚本会在结果中追加pending_validations: [ { layer: browser, reason: browser verdict is PENDING_BROWSER } ]这意味着没跑成的验证不再是沉默的绿而是写在证据包里的显式欠账。同时只有 verdict 为 APPROVE 时才会刷新旧版兼容文件.claude/state/review-approved.json供 commit guard 读取放行。出口accept-collect-evidence.sh 机械收集 4 类产物验收端由 scripts/accept-collect-evidence.sh 收口。它接收一个 task-id以只读方式读取 4 类产物输出归一化的accept-evidence.v1产物路径来源新鲜度策略worker-report.claude/state/review/task-id.worker-report.jsonWorker 自审文件名含 task-id天然对应review-result.claude/state/review-result.jsonReviewer 判定 pending_validations单例文件仅当其中task.id与入参一致才采信防止误用上一次评审的旧结论runtime-review.claude/state/review/task-id.runtime-review.jsonruntime profile 执行结果文件名含 task-idbrowser-result.claude/state/review/task-id.browser-result.jsonbrowser profile 执行结果含录屏视频文件名含 task-id两个细节让这套机制对旧项目依然友好缺失不报错worker-report 缺失的旧任务不会让脚本崩掉而是返回present: false 原因说明脚本头部注释即声明了该行为验收判定硬约束skills/harness-accept/SKILL.md 规定验收只能引用产物不得新造主张。产物缺失或落在pending_validations里的验收项一律passed: false并写入unverified_caveats只要 pending 项 ≥ 1 条验收建议就不可能是 ship只能 wait。也就是说验收绿灯必须由磁盘上的四类 JSON 共同支撑AI 想再申报一遍已经没有意义。配线自检check-verification-chain-wiring.sh 防止链条断裂 验证链还有一个验证的验证环节scripts/ci/check-verification-chain-wiring.sh 用 5 个静态检查点确认配线没有断scope leash 是否被 guardrail 模块真实 importwrite-review-result.sh是否真的会产出pending_validations字段harness-accept的 SKILL.md 是否真的调用了accept-collect-evidence.shrisk_flags 到评审 profile 的升级表security-sensitive / contenteditable="false">【免费下载链接】claude-code-harnessClaude Code Dedicated Development Harness - Achieving High-Quality Development Through an Autonomous Plan→Work→Review Cycle项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考