用途：帮助开发者正确标注 LLM 输出，属于评测工作流第 1 步（共 7 步），无前置要求，下一步为 llm-issue-discovery。开始前先检查项目中是否存在 CLAUDE.md、product-marketing-context.md 等上下文文件，若有则先读取，跳过已回答的问题。
两种模式：先询问用户是已有标注需要审查，还是从零搭建评分标准。
模式 A（从零搭建）：先验证数据，直接读取 10–20 条样本，或请用户提供 5–10 条示例，确认字段、输出形态及影响标准写法的因素，未看到真实样本前不设计标准。再获取上下文，问两个问题：这个 AI 做什么（一句话）；想测量什么维度（准确性、语气、完整性、安全性等），让用户自由回答。然后把维度转成具体、可观察的标准，检验方式是两名评审独立应用能否得到相同答案，例如把“回答有帮助吗”改写为“回答是否包含至少一个用户现在就能采取的行动”。接着选择评分方案：二元（是/否）适合明确问题；1–5 分适合有程度差异的质量，但必须逐点定义 1 到 5 各代表什么行为。每个标准都要加理由字段“为什么给这个分数”。最后输出可复制的评分标准，并建议先用 2–3 名评审对同样 10 条样本测试，若持续分歧应打磨标准而非归咎评审；分歧不要取平均，应逐条讨论并更新标准。
模式 B（审查已有标注）：索取 20–50 条样本及所用标准。按严重程度检查：标准缺失或含糊；缺少理由（超过 30% 无理由需标记）；分数分布问题（80% 以上同分、或只有 1 和 5）；相似输入得分差异大；一个分数混合多个维度（范围蔓延）。随后逐项修复，并输出标注质量报告，包含审查条数、是否有标准、问题及严重程度、具体示例、建议修复、做得好的地方和优先后续步骤。
结尾统一给出三个选择：继续人工标注、用这些标注构建自动化 judge（llm-judge-creator）、分析失败模式（llm-issue-discovery）。原则：含糊标准产生噪声而非数据；理由是信号；规模化前先测试；每个标准只测一个维度；标注的最终目的是让自身变得不必要。资料未提供具体收费、平台支持范围或安装命令。