用途：在开始为 AI 系统构建评估之前，确认是否具备必要基础。缺少基础就构建评估，会产出泛化、错位或无法验证的评估，浪费精力。
四项前提（逐层依赖）：追踪——AI 功能的输入输出被捕获到可访问处；日志——有足够数量的真实生产交互；标注——人工审阅日志样本并标记好坏；问题——标注被用于识别具体、命名的失败模式。四项齐备才算就绪。
使用方式：该技能以代码智能体形式运行，先检查代码库和项目文件，寻找每项前提的证据，仅在无法判断时才询问开发者。
第1步检查追踪/可观测性：搜索 latitude、@latitude-data/sdk、opentelemetry、langsmith、braintrust、helicone、traceloop 等导入或 SDK 调用，以及 LATITUDE_API_KEY、LANGCHAIN_TRACING、OTEL_EXPORTER_* 等环境变量。未找到则询问；若答案为否，提示先搭建可观测性。
第2步检查生产日志：查找含 LLM 输入输出的 .json、.csv、.jsonl、.log 文件或日志目标引用。20 条交互为最低门槛，少于则建议积累流量或生成合成用例。
第3步检查标注：查找 annotation、rating、label、score、thumbs_up、feedback 等字段。有失败原因备注为 ✅，仅有分数为 ⚠️。最低 20 条带失败备注的标注输出。
第4步检查命名问题列表：查找 issue-report、failure-patterns、eval-issues 等文件。问题须具体（如“库存检查失败时推荐缺货书籍”）而非泛化（如“坏回复”），每个问题至少 5 个示例。
第5步输出就绪报告：以表格列出四项前提的状态（✅/⚠️/❌）与备注。全部 ✅ 时给出推荐路径：llm-eval-type-selector 选择评估类型、llm-judge-creator 构建评判提示、llm-judge-alignment 验证评判。存在 ⚠️ 时列出需尽快弥补的缺口；存在 ❌ 时只报告第一个阻塞项及具体下一步，修复后重新运行本清单。
原则：先检查再询问；一次只报一个阻塞项；具体性是前提；5 个示例是下限而非目标，5–15 为 ⚠️，低于 5 为 ❌；无推理的标注是弱信号。
限制：资料未提供该技能的收费、价格、平台支持范围等具体信息。