★ FEATURED ARTICLE 【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载GSD Core 的gsd-eval-planner是 AI 设计契约AI-SPEC.md流水线的最后一个专项 Agent它回答一个关键问题我们如何知道这个 AI 系统真的工作正常本文基于仓库中的 Agent 规格文档 agents/gsd-eval-planner.compact.md及完整版 agents/gsd-eval-planner.md结合其依赖的评估框架 gsd-core/references/ai-evals.md、编排工作流 gsd-core/workflows/ai-integration-phase.md、模板 gsd-core/templates/AI-SPEC.md 与评分实现 src/eval.cts完整讲解其输入契约、七步执行流程、维度映射表、Rubric 写法、工具选择、参考数据集、护栏设计以及写入 AI-SPEC 第 5–7 节的落地纪律。读完本文你将掌握为任何 RAG、Multi-Agent、抽取、对话等 AI 系统产出一份可执行评估方案含 CI/CD 集成与生产监控的完整方法论。一、gsd-eval-planner 在 GSD 生命周期中的位置在 GSD 的 AI 集成工作流中gsd-eval-planner是 ai-integration-phase 编排器 依序派生的第 4 个也是最后一个Agent位于discuss-phase与plan-phase之间。整条流水线为gsd-framework-selector—— 选择 AI 框架gsd-ai-researcher—— 调研框架文档与 AI 系统最佳实践gsd-domain-researcher—— 调研业务领域上下文写入 AI-SPEC 第 1b 节gsd-eval-planner—— 基于领域上下文设计评估策略写入第 5–7 节编排器在第 9 步派生它并在派生 prompt 中明确告知AI-SPEC.md 现在已包含领域上下文第 1b 节——将其作为你的 Rubric 起点。见 gsd-core/workflows/ai-integration-phase.mdAI-SPEC.md 通过这种方式在规划器创建任务之前锁定四件事评估策略是其中之一。整个工作流由能力开关workflow.ai_integration_phase控制默认true见 capabilities/ai-integration/capability.json测试 tests/ai-evals.test.cjs 验证了该配置项默认值与开关行为并断言ai-integration-phase.md必须引用这 4 个 Agent。二、输入契约规划器拿到什么gsd-eval-planner的输入来自编排器的input块决定了评估策略的范围输入说明system_typeRAG / Multi-Agent / Conversational / Extraction / Autonomous / Content / Code / Hybridframework已选定的 AI 框架来自 gsd-framework-selectormodel_providerOpenAI / Anthropic / Model-agnosticphase_name、phase_goal来自 ROADMAP.md 的阶段名与目标ai_spec_pathAI-SPEC.md 路径context_path、requirements_pathCONTEXT.md、REQUIREMENTS.md若存在Agent 规格中还特别约定如果 prompt 里出现required_reading必须先读完列出的文件再做任何事。对 eval-planner 而言必读文件是评估框架~/.claude/gsd-core/references/ai-evals.md仓库内对应 gsd-core/references/ai-evals.md。该参考文件是全仓库评估方法论的单一事实来源为什么需要 EvalAI 系统非确定性单测/集成测试不足以覆盖、模型评估 vs 产品评估的差别80% 的评估精力应投入产品评估、每个 Eval 的三要素Input / Expected / Actual。三、第一步读取阶段上下文read_phase_context规划器不会凭空设计评估方案。它必须先完整读取 AI-SPEC.md聚焦以下前置章节第 1 节系统分类与关键失败模式Critical Failure Modes第 1b 节gsd-domain-researcher产出的领域 Rubric 素材——这是最重要的输入第 3–4 节框架快速参考与实现指导Pydantic 模式 → 可测试的判据第 2 节框架决策决定工具默认值同时读取 CONTEXT.md 与 REQUIREMENTS.md。规格文档反复强调分工边界领域研究员已经完成了 SME领域专家工作——你的任务是把他们的 Rubric 素材转成可度量标准而不是重新推导领域上下文。 这与 agents/gsd-domain-researcher.compact.md 的分工严格对应domain-researcher 负责产出Dimension / Good / Bad / Stakes / Source格式的领域 Rubric 要素eval-planner 负责将其落地为可执行判据。四、第二步按系统类型选择评估维度select_eval_dimensions规划器将system_type映射到 gsd-core/references/ai-evals.md 中定义的评估维度。映射表如下来自 Agent 规格未删减系统类型必备评估维度RAGfaithfulness忠实度、hallucination幻觉、answer relevance答案相关性、retrieval precision检索精度、source citation来源引用Multi-Agenttask decomposition任务分解、handoffAgent 间交接、goal completion目标完成、loop detection循环检测Conversationaltone/style语气/风格、safety安全、instruction following指令遵循、escalation accuracy升级准确性Extractionschema complianceSchema 合规、field accuracy字段准确率、format validity格式有效性Autonomoussafety guardrails安全护栏、tool use correctness工具使用正确性、cost/token adherence成本/Token 遵守、task completion任务完成Contentfactual accuracy事实准确、brand voice品牌口吻、tone语气、originality原创性Codecorrectness正确性、safety安全、test pass rate测试通过率、instruction following指令遵循两个始终必须包含的维度面向用户的系统必须包含safety安全Agent 类系统必须包含task completion任务完成。此处的维度语义可回溯到参考文件中的Pre-Deployment (Development Phase)维度表含 What It Measures / When It Matters 两列规划器可据此理解每个维度到底测什么、何时重要。五、第三步编写 Rubricwrite_rubrics——从领域语言到可判定标准这是规划器产出质量的关键步骤。Agent 规格给出的规则是起点必须是第 1b 节的领域 Rubric 素材而不是通用维度标签只有当 1b 内容稀疏时才回退到通用维度。每个维度必须按固定格式给出具体可判定的标准 PASS: {领域语言描述的可接受行为} FAIL: {领域语言描述的不可接受行为} Measurement: Code / LLM Judge / Human每个维度标注优先级Critical / High / Medium。测量方式Measurement的选型规则参考文件Three Measurement Approaches的完整阐释Code-based代码度量确定性检查——schema 校验、必填字段存在性、性能阈值、正则。快、便宜、可靠优先使用。LLM judgeLLM 评判一个模型按 Rubric 评估另一个模型适合语气、推理质量、安全违规检测等主观维度必须经过人类校准才能信任参考文件给出的目标是 LLM judge 与人类评分相关性 ≥ 0.7。Human review人工评审边界用例、LLM judge 校准、高风险抽样。不具扩展性但用于校准与高利害决策。参考文件用一句很精辟的话点明 Rubric 的必要性没有 RubricLLM judge 产出的只是噪音而非信号——Helpfulness 在房产领域意味着清晰总结房源在医疗领域意味着知道何时不回答。一个合格 Rubric 需要定义被测维度、5 分制下 1/3/5 分或 PASS/FAIL标准、领域语言下的可接受/不可接受行为示例。六、第四步选择评估工具select_eval_tooling工具选择遵循先探测、后默认原则。规划器首先扫描代码库中是否已存在评估/追踪工具避免引入第二套重复工具链grep -r langfuse\|langsmith\|arize\|phoenix\|braintrust\|promptfoo\|ragas \ --include*.py --include*.ts --include*.toml --include*.json \ -l 2/dev/null | grep -v node_modules | head -10如果探测到已有工具就以其作为追踪默认否则应用以下主观默认值opinionated defaults关注点默认工具追踪 / 可观测性Arize Phoenix—— 开源、可自托管、通过 OpenTelemetry 与框架无关RAG 评估指标RAGAS—— faithfulness、answer relevance、context precision/recallPrompt 回归 / CIPromptfoo—— CLI 优先、无需平台账号LangChain/LangGraphLangSmith—— 若已在该生态则覆盖 PhoenixAgent 规格要求把 Phoenix 的初始化代码直接写入 AI-SPEC.md 的评估工具节# pip install arize-phoenix opentelemetry-sdk import phoenix as px from opentelemetry import trace from opentelemetry.sdk.trace import TracerProvider px.launch_app() # http://localhost:6006 provider TracerProvider() trace.set_tracer_provider(provider) # Instrument: LlamaIndexInstrumentor().instrument() / LangChainInstrumentor().instrument()参考文件 gsd-core/references/ai-evals.md 的Eval Tooling Guide进一步给出了完整选型对照表RAGAS / Langfuse / LangSmith / Arize Phoenix / Braintrust / Promptfoo 的 Type、Best For、Key Strength以及按系统类型的推荐组合RAG 用 RAGAS Phoenix/Braintrust多智能体用 Langfuse Phoenix对话/单模型用 Promptfoo Braintrust结构化抽取用 Promptfoo 代码校验器LangChain/LangGraph 项目用 LangSmith。测试 tests/ai-evals.test.cjs 断言参考文件必须提及 Arize Phoenix 与 RAGAS保证工具默认值的可追溯性。七、第五步规定参考数据集specify_reference_dataset评估没有数据就没有意义。规划器必须在 AI-SPEC.md 中明确数据集的四项规格规模size至少10 条起步面向生产至少20 条。参考文件的原则更直白10–20 条高质量示例而不是 200 条平庸的——先小规模高精度再根据生产中学到的东西扩展而不是为假想的覆盖率构建。构成composition覆盖关键路径、边界用例、历史失败模式、对抗性输入。标注方式labeling领域专家 / 经校准的 LLM judge / 自动化。参考文件强调由领域专家而非仅工程师标注示例。创建时间线timeline在实现过程中就开始构建而不是实现完成后补做——这与参考文件Execute Phase阶段的要求一致实现第一天就加追踪、与实现并行构建参考数据集。八、第六步设计护栏design_guardrails规划器针对每个关键失败模式AI-SPEC 第 1 节中列出的 3–5 个绝对不能出错的行为做二分类在线护栏Online guardrail针对灾难性失败——每个请求都运行、实时、必须快干预方式为 Block / Escalate / Flag。离线飞轮Offline flywheel针对质量信号——采样批量分析反馈给改进循环。关键原则保持最小化——每个护栏都会增加延迟。参考文件的判断问题同样简洁如果这种行为出错对我的业务是灾难性的吗 是 → 护栏在线、实时、立即干预否 → 飞轮离线批量、喂给持续改进。生产监控维度的完整映射见参考文件safety violations 与 compliance failures 走在线护栏quality degradation trends 走离线飞轮新兴失败模式用信号-指标背离signal-metric divergence探测成本/延迟漂移用代码度量自动告警。九、第七步写入 AI-SPEC 第 5、6、7 节write_sections_5_6_7规划器最终把成果落到 AI-SPEC.md 的三个章节对应模板 gsd-core/templates/AI-SPEC.md 的结构第 5 节Evaluation Strategy维度表Dimension / Rubric / Measurement Approach / Priority、工具与安装命令、参考数据集规格size composition labeling、CI/CD 评估命令。第 6 节Guardrails在线护栏表Guardrail / Trigger / Intervention、离线飞轮表Metric / Sampling Strategy / Action on Degradation。第 7 节Production Monitoring追踪工具、关键指标3–5 个、告警阈值何时 paging/告警、智能抽样策略基于信号的过滤器例如重试、异常长度、显式升级等可疑信号加权抽样。写入工具纪律重要完整版 Agent 规格 agents/gsd-eval-planner.md 明确了两条硬性纪律必须使用 Write 工具创建文件严禁用Bash(cat EOF)或 heredoc 写文件。在 ai-integration-phase 工作流 中所有写入 AI-SPEC.md 的 Agent 只用Edit 工具绝不用 Write 覆盖整文件因为Write会替换整个文件、静默覆盖并行/串行兄弟 Agent 的成果工作流还注明了一个已确认的高发竞争约 40% 概率的 last-writer-wins 竞态#3096因此第 7、8 步必须串行执行。如果读完全部产物后领域上下文仍不清晰允许只问一个问题通过AskUserQuestion询问主要领域/行业上下文选项为 Internal developer tooling / Customer-facing (B2C) / Business tool (B2B) / Regulated industry (healthcare, finance, legal) / Research / experimental——而不是一连串追问。完整性校验编排器在第 10 步对写回的 AI-SPEC.md 做验证其中与评估相关的门槛包括第 5 节维度表至少一行、第 6 节至少一个护栏或显式注明N/A for internal tool、末尾 Checklist 至少 3 项勾选。模板末尾的 Checklist 对评估部分的要求是评估维度扎根于领域 Rubric 素材、每个维度有具体 Rubric领域语言的 Good/Bad、工具默认值Arize Phoenix确认或注明覆盖、参考数据集规格size ≥ 10 构成与标注、CI/CD 评估集成、在线护栏、生产监控追踪工具 抽样策略。测试 tests/ai-evals.test.cjs 逐项断言模板必须包含这些章节与表格结构。十、闭环gsd-eval-auditor 与确定性评分评估规划不是一次性活动。gsd-eval-planner的产出由/gsd:eval-review命令工作流 gsd-core/workflows/eval-review.md在阶段实现后做追溯审计gsd-eval-auditoragents/gsd-eval-auditor.compact.md以对抗性姿态扫描代码库按 AI-SPEC 第 5–7 节逐维度打 COVERED / PARTIAL / MISSING并审计五项基础设施工具链、参考数据集、CI/CD 集成、在线护栏、追踪配置。值得强调的是评分不是手算的编排器调用确定性动词gsd_run query eval.score --covered N --total N --infra a,b,c,d,e --raw由 src/eval.cts 中的computeEvalScore完成算术。其算法源码可直接验证coverage_score covered / total × 100infra_score 五项基础设施每项 ok1 / partial0.5 / missing0之和 / 5 × 100overall coverage × 0.6 infra × 0.4verdict 阈值≥80 → PRODUCTION READY≥60 → NEEDS WORK≥40 → SIGNIFICANT GAPS否则 NOT IMPLEMENTED这体现了 GSD Core 的代码委派纪律把算术从 Agent prompt 挪进代码保证评分可复现、可测试、不被 LLM 篡改。这也是理解 eval-planner 设计哲学的重要一环——规划产出的可度量标准最终要被确定性程序审计。十一、gsd-eval-planner 的成功标准Agent 规格结尾的成功标准清单即评估方案的最低完备定义关键失败模式已确认至少 3 个评估维度已选定至少 3 个且适配系统类型每个维度有具体 Rubric而非通用标签每个维度有测量方式Code / LLM Judge / Human评估工具已选定并给出安装命令参考数据集规格已写出规模 构成 标注已指定 CI/CD 评估集成命令已定义在线护栏面向用户的系统至少 1 个已定义离线飞轮指标AI-SPEC.md 第 5、6、7 节已写入且非空十二、延伸阅读Agent 完整规格agents/gsd-eval-planner.md含工具纪律等细节评估方法论参考gsd-core/references/ai-evals.md维度定义、工具对照、生命周期、六大常见陷阱编排工作流gsd-core/workflows/ai-integration-phase.md四 Agent 派生顺序、Edit 防竞争纪律、完整性校验输出模板gsd-core/templates/AI-SPEC.md第 5/6/7 节与 Checklist 骨架评分实现src/eval.cts确定性计分与 verdict 阈值追溯审计 Agentagents/gsd-eval-auditor.compact.md 与 gsd-core/workflows/eval-review.md上游分工agents/gsd-domain-researcher.compact.md第 1b 节领域 Rubric 素材的产出者测试验证tests/ai-evals.test.cjs模板章节完整性、配置开关、Agent/工作流存在性赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐GSD-2 实战指南用 /gsd eval-review 审计切片 AI 评估策略并产出可机器读取的 EVAL-REVIEW.mdGSD 2 实战指南用 /gsd eval review 审计切片 AI 评估策略并产出可机器读取的 EVAL REVIEW.md /gsd eval rev人工智能AI Agent代码智能体Agent 编排CLIAI 应用面向 AI 系统的产品级评估框架get-shit-done 的 gsd-eval-planner 与 gsd-eval-auditor 实战指南面向 AI 系统的产品级评估框架get shit done 的 gsd eval planner 与 gsd eval auditor 实战指南 在由 TÂC人工智能AI 应用提示工程开发工具工作流自动化AI Agentgsd-core 阶段 ID 字母变体支持12A/23A.1.2 在代码评审与规划工作流中的规范化落地gsd core 阶段 ID 字母变体支持 12A / 23A.1.2 在代码评审与规划工作流中的规范化落地 本文基于 gsd core 仓库的 .chang上一篇dart-event-bus性能优化避免内存泄漏的5个关键策略下一篇AI4Animation终极指南Unity中让角色活起来的10个核心技术创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
