因此，我们需要用一套可测量、可验证的三元组标准来替代这些模糊表述。每条标准都必须包含三个硬性要素：问题现象、检测方法和数值阈值。最后，必须强制输出 JSON 格式，并要求每条证据都精确标注原文出处。
先剥离非评价要素
打开你当前使用的评价提示词，逐句扫描，将所有与“指标是否可测量、结果是否可验证”无关的内容标记出来。不要犹豫，直接删除“语言生动”“逻辑清晰”“富有感染力”这类无法用工具校验的表述。它们不是评价标准，只是审美上的幻觉。
遇到“用户看完会点头认同”这类描述，同样直接删除。Gemini 无法读心，也无法模拟用户的点头动作；但你可以检查“文案里是否包含至少 2 个真实的学员原声短语”——这个能计数、能查证、能回溯，才是有效的评价指标。
用三元组锚定每条标准
每一条评价标准都必须拆分为明确的
方法一：从“问题现象”反推标准
假设原文提到“简历投了石沉大海”→ 我们可以这样构造标准：
- 触发条件：检测是否嵌入学员原声短语
- 状态判定：该短语必须来自《2026Q1咨询对话抽样》第7页第3条原始消息
- 得分效果：命中则得1分，未命中得0分
方法二：用数值卡死模糊地带
另一个例子：
- 触发条件：统计动词密度
- 状态判定：全文共428字
- 得分效果：动词数量≥63个（即每6.8字含1个动词），低于此数值则标记“动作感不足”
注意：这里的动词必须是真实的行为动词，比如“删掉”“塌陷”“崩”“卡顿”；禁用“体现”“展现”“传达”这类伪动词。
绑定校验动作并强制输出格式
第一步：在提示词末尾添加一条硬性指令：“仅输出 JSON 对象，字段为 {score: number, flaws: string[], evidence: string[]}，不得包含任何解释性文字或 Markdown 格式。”
第二步：要求 evidence 字段必须引用原文的精确位置。例如“第2段第3行‘改完bug又崩’符合学员原声要求”。不允许含糊其辞。
第三步：追加一条失败拦截句：“若 flaws 数组为空，则自动补入‘未检测到具体问题点’并重评。”如果不这样做，Gemini 常常默认输出“整体不错”，等于没有评价。
这样一来，每次评价的基准都是固定的、可回溯的，横向对比也有了真正的底气。