get-shit-done 的 /gsd:eval-reviewAI 阶段评估覆盖度的事后审计与 EVAL-REVIEW 修复计划【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done导读/gsd:eval-review是 get-shit-doneGSD为 Claude Code 提供的 AI 阶段评估审计命令在/gsd:execute-phase完成某个 AI 阶段的实现之后它会对该阶段的**评估覆盖度evaluation coverage**进行回溯式审计核对AI-SPEC.md中规划的评估策略是否真正落地并产出一份带评分、判定结论、差距清单与修复计划的EVAL-REVIEW.md。读完本文你将掌握该命令的输入状态判定逻辑、审计 Agent 的评分模型维度覆盖 × 基础设施加权公式、四档判定标准以及如何基于审计结果驱动下一阶段的迭代。一、命令概览它解决什么问题/gsd:eval-review的定位在 commands/gsd/eval-review.md 中定义得很明确对已执行的 AI 阶段completed AI phase进行回溯式评估覆盖度审计检查AI-SPEC.md中的评估策略是否真的被实现了最终产出EVAL-REVIEW.md修复计划。它由命令入口的allowed-tools约束为 Read、Write、Bash、Glob、Grep、Agent 与 AskUserQuestion且声明requires: [phase]即只能在阶段执行之后使用接受可选参数[phase number]缺省时作用于最近一个已完成阶段。该命令与/gsd:ui-review、/gsd:validate-phase遵循同一模式workflow 的 purpose 部分明确说明 Mirrors the pattern of /gsd:ui-review and /gsd:validate-phase是 GSD 阶段门禁体系的一部分实现 → 审计 → 修复 → 再验证。核心工作流文件为 get-shit-done/workflows/eval-review.md评分框架依赖 get-shit-done/references/ai-evals.md实际执行审计的则是子 Agentgsd-eval-auditoragents/gsd-eval-auditor.md。二、执行上下文与前置产物命令 frontmatter 通过execution_context声明其依赖工作流 get-shit-done/workflows/eval-review.md —— 编排整个审计流程参考文档 get-shit-done/references/ai-evals.md —— 提供评分框架评估维度、测量方式、护栏与飞轮决策等。这套审计体系与上游的/gsd:ai-integration-phasecommands/gsd/ai-integration-phase.md形成闭环该命令编排gsd-framework-selector → gsd-ai-researcher → gsd-domain-researcher → gsd-eval-planner的流水线其中gsd-eval-planneragents/gsd-eval-planner.md负责把评估策略写入AI-SPEC.md的 Section 5Evaluation Strategy、Section 6Guardrails、Section 7Production Monitoring。eval-review审计的正是这些规划是否被后续的 execute 阶段真正实现。三、工作流逐步拆解3.1 Step 0初始化与 Banner流程首先通过 GSD SDK 查询阶段信息INIT$(gsd-sdk query init.phase-op ${PHASE_ARG}) if [[ $INIT file:* ]]; then INIT$(cat ${INIT#file:}); fi解析出phase_dir、phase_number、phase_name、phase_slug、padded_phase、commit_docs等字段再解析审计模型AUDITOR_MODEL$(gsd-sdk query resolve-model gsd-eval-auditor 2/dev/null | jq -r .model 2/dev/null || true)随后显示审计横幅标识当前阶段号与名称。3.2 Step 1输入状态检测三种状态工作流根据阶段目录中的文件判断审计起点SUMMARY_FILES$(ls ${PHASE_DIR}/*-SUMMARY.md 2/dev/null) AI_SPEC_FILE$(ls ${PHASE_DIR}/*-AI-SPEC.md 2/dev/null | head -1) EVAL_REVIEW_FILE$(ls ${PHASE_DIR}/*-EVAL-REVIEW.md 2/dev/null | head -1)State A—— 同时存在AI-SPEC.md与SUMMARY.md执行对照规格的全量审计audit against specState B—— 只有SUMMARY.md、没有AI-SPEC.md退化为对照通用 AI 评估最佳实践的审计并给出非阻塞性警告提示下次实现前应先运行/gsd:ai-integration-phaseState C—— 没有SUMMARY.md直接退出提示Phase {N} not executed. Run /gsd:execute-phase {N} first.。此外若EVAL-REVIEW.md已存在会通过 AskUserQuestion 询问用户是Re-audit重新审计还是View展示现有报告并退出。3.3 Step 2收集审计上下文构建交给 auditor 的文件清单AI-SPEC.md若存在即规划中的评估策略阶段目录下全部SUMMARY.md阶段目录下全部PLAN.md。3.4 Step 3孵化 gsd-eval-auditor流程以 Task 方式孵化 auditor携带的 prompt 包含 objectiveState A 则Audit against AI-SPEC.md evaluation planState B 则Audit against general AI eval best practices、files_to_read清单以及结构化 inputai_spec_path、phase_dir、phase_number、phase_name、padded_phase、state。模型取上一步解析出的AUDITOR_MODEL。3.5 Step 4解析审计结果读取 auditor 写出的EVAL-REVIEW.md提取三个关键字段overall_score、verdictPRODUCTION READY | NEEDS WORK | SIGNIFICANT GAPS | NOT IMPLEMENTED、critical_gap_count。3.6 Step 5展示摘要与下一步终端输出审计完成摘要分数、判定、关键差距数、报告路径并按判定分支给出后续动作PRODUCTION READY→ 进入/gsd:plan-phase下一阶段或部署NEEDS WORK→ 先处理EVAL-REVIEW.md中的关键差距再重跑/gsd:eval-review {N}SIGNIFICANT GAPS / NOT IMPLEMENTED→ 回看AI-SPEC.md的评估计划关键评估维度未实现禁止部署。3.7 Step 6提交可选当commit_docs为 true 时自动将报告纳入版本控制git add ${EVAL_REVIEW_FILE} git commit -m docs({phase_slug}): add EVAL-REVIEW.md — score {overall_score}/100 ({verdict})四、文本模式非 Claude 运行时的兼容开关工作流明确支持workflow.text_mode: true配置或--text标志一旦激活TEXT_MODE所有AskUserQuestion交互都会被替换为纯文本编号列表由用户输入选项编号。这是为 OpenAI Codex、Gemini CLI 等不具备AskUserQuestion能力的运行时准备的必需路径保证审计命令在多 AI 运行时下可用。五、审计 Agent 的评分模型5.1 对抗式立场gsd-eval-auditor的核心立场是FORCE stance对抗式假设默认认为评估策略没有被实现直到代码库证据证明相反。其角色定义明确要求回答实现的系统是否真的交付了规划的评估策略而非看起来像实现了。Agent 指令还显式列出了审计者常见的变软失败模式用于自我纠偏因为有一些测试就把 MISSING 标成 PARTIAL——关键评估维度的部分覆盖在缺口未被量化前应视为 MISSING把指标日志当作评估已实现的证据而忽略日志指标是否真正驱动决策把AI-SPEC.md的文档本身当作实现证据只验证测试文件存在而不验证评估维度是否对照 rubric 评分为了软化报告而把 MISSING 降级为 PARTIAL。差距分级为两种BLOCKER评估维度 MISSING 或护栏未实现AI 系统不得上生产与WARNING评估维度 PARTIAL覆盖不足但并非缺失。每个规划维度必须归入 COVERED、PARTIALWARNING或 MISSINGBLOCKER之一。5.2 执行流程与代码扫描auditor 的执行流包含五步读阶段产物AI-SPEC.md 的 Section 5/6/7、SUMMARY.md、PLAN.md→ 扫描代码库 → 逐维度评分 → 基础设施审计 → 计算分数并写报告。代码扫描覆盖五个类别见 agents/gsd-eval-auditor.md 中的scan_codebase步骤典型的探测命令包括# 评估/测试文件 find . \( -name *.test.* -o -name *.spec.* -o -name test_* -o -name eval_* \) \ -not -path */node_modules/* -not -path */.git/* 2/dev/null | head -40 # 追踪/可观测性配置 grep -r langfuse\|langsmith\|arize\|phoenix\|braintrust\|promptfoo \ --include*.py --include*.ts --include*.js -l 2/dev/null | head -20 # 护栏实现 grep -r guardrail\|safety_check\|moderation\|content_filter \ --include*.py --include*.ts --include*.js -l 2/dev/null | head -205.3 维度评分标准状态判定标准COVERED实现存在、针对 rubric 行为、可运行自动化或文档化的手动方式PARTIAL存在但不完整——缺 rubric 特异性、未自动化或存在已知缺口MISSING该维度无任何实现对 PARTIAL 与 MISSING需要记录规划了什么 / 实际发现了什么 / 达到 COVERED 的具体补救步骤。5.4 基础设施审计与加权打分基础设施审计对 5 个组件分别评 ok / partial / missing评估工具链已安装且真实被调用而非仅列在依赖里、参考数据集文件存在且满足规模/构成规格、CI/CD 集成Makefile、GitHub Actions 中存在评估命令、在线护栏每个规划的护栏真实进入请求路径而非桩实现、追踪工具已配置并包裹真实 AI 调用。最终三档分数按固定公式计算coverage_score covered_count / total_dimensions × 100 infra_score (tooling dataset cicd guardrails tracing) / 5 × 100 overall_score (coverage_score × 0.6) (infra_score × 0.4)判定阈值80–100 →PRODUCTION READY带监控部署60–79 →NEEDS WORK上线前处理关键差距40–59 →SIGNIFICANT GAPS禁止部署0–39 →NOT IMPLEMENTED回看 AI-SPEC.md 并补实现。5.5 EVAL-REVIEW.md 输出结构auditor 必须使用 Write 工具而非 heredoc写入{phase_dir}/{padded_phase}-EVAL-REVIEW.md标准结构包含审计日期与 AI-SPEC 是否存在、总分与判定、Dimension Coverage 表维度/状态/测量方式/发现、Infrastructure Audit 表五组件状态与发现、Critical Gaps仅列 Critical 严重度的 MISSING 项、分层的Remediation PlanMust fix before production / Should fix soon / Nice to have以及扫描中发现的评估相关文件清单Files Found。六、评分框架参考ai-evals.md 提供的底层逻辑eval-review的评分不是凭空打分而是建立在 get-shit-done/references/ai-evals.md 的评估方法论之上该文档也是gsd-eval-planner与gsd-eval-auditor共用的框架为什么需要评估AI 系统具有非确定性单靠单元测试与集成测试不够模型评估 vs 产品评估MMLU/HumanEval 等模型评估只作初筛80% 的评估精力应投入产品评估你的数据、用户与领域规则每次评估的三要素Input查询、历史、检索文档、系统提示、配置、Expected通过 rubric 定义的好行为、Actual实际产出含中间步骤、工具调用与推理轨迹三种测量方式代码化指标确定性、快、便宜先用、LLM 裁判主观质量需先与人工校准、人工评估黄金标准但不可规模化用于校准/边界/高价值决策护栏 vs 飞轮决策若行为出错对业务是灾难性的 → 在线实时护栏有延迟成本要克制否则 → 离线批量分析飞轮Rubric 设计必须定义维度、1/3/5 分档5 分制或 pass/fail 标准、领域内可接受/不可接受行为的示例否则 LLM 裁判产出的是噪声而非信号参考数据集起步 10–20 条高质量样例覆盖关键成功场景、常见用户流、已知边界与历史失败模式由领域专家标注评估工具选型RAGASRAG 评估、Langfuse / Arize Phoenix平台化、可自托管、LangSmithLangChain 生态、Braintrust模型无关、PromptfooCLI 优先、CI/CD等。七、闭环关系planner 规划 → auditor 审计要真正用好eval-review需要理解它与上游gsd-eval-planner的契约关系。planner 在实现前就把评估策略写入AI-SPEC.md按系统类型RAG / Multi-Agent / Conversational / Extraction / Autonomous / Content / Code / Hybrid映射必需维度如 RAG 需 context faithfulness、hallucination、answer relevance、retrieval precision、source citationAutonomous 需 safety guardrails、tool use correctness、cost/token adherence、task completion并始终包含 safety 与 task completion 两个通用维度每个 rubric 用 PASS/FAIL 加测量方式Code / LLM Judge / Human格式化标记优先级Critical/High/Medium并规划工具链、参考数据集规格与在线护栏。审计时 auditor 逐条核对规划 vs 实际若只有通用实践而无阶段专属计划State B审计强度自然下降——这正是工作流会警告用户下次先跑 /gsd:ai-integration-phase的原因。八、实现佐证仓库测试如何保障该体系仓库中的 tests/ai-evals.test.cjs 覆盖了这套评估体系的契约完整性包括workflow.ai_integration_phase配置键的默认值默认为 true与 config-set/config-get 往返持久化、validate-health在缺少该配置时给出 W016 警告、addAiIntegrationPhaseKey修复动作、AI-SPEC.md 模板的 Section 完整性、plan-phase 的 AI 关键词提示块、ai-integration-phase 与 eval-review 两个命令的 frontmatter以及 ai-evals.md / ai-frameworks.md 参考文件存在且非空。这从侧面印证了eval-review不是孤立命令而是与配置、健康检查、模板和参考文档一起被持续验证的系统能力。九、使用要点与最佳实践顺序正确先/gsd:execute-phase {N}完成实现再/gsd:eval-review {N}做回溯审计缺省参数时自动选择最近完成的阶段。先有规划实现 AI 阶段前优先运行/gsd:ai-integration-phase生成AI-SPEC.md否则审计降级为对照通用实践State B且会收到非阻塞警告。按判定行动NEEDS WORK 时先消化EVAL-REVIEW.md的 Critical Gaps 再重跑审计SIGNIFICANT GAPS 与 NOT IMPLEMENTED 阶段禁止进入部署。多运行时兼容在 Codex、Gemini CLI 等环境使用--text标志或配置workflow.text_mode: true交互会切换为纯文本编号列表。重复审计报告已存在时选择 Re-audit 可重新生成配合commit_docs自动提交形成可追溯的评估记录链。十、局限说明eval-review是评估覆盖度审计而非功能正确性审计——它回答规划的评估体系是否落地不直接替代码质量把关其评分依赖 auditor 对代码库的扫描深度与AI-SPEC.md中规划维度的质量规划本身越粗糙审计上限越低。此外文本模式与模型解析AUDITOR_MODEL依赖 GSD SDK 与gsd-sdk query resolve-model的可用性这些属于运行时的前提条件。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考