反馈评测化

问题：形容词解决不了任何 bug

AI 产品的反馈往往是这样的："不好用"、"AI 味太重"、"不听话"。这类形容词无法路由到任何修复动作——你不知道是理解错了指令、格式输出错了，还是检索到了错误的信息。更糟的是，团队用"感觉变好了"来宣布修复完成，改了五轮 Prompt 之后依然在原地打转，因为没有任何可重跑的东西来告诉你到底改好了没有。

你没法改进一件你没法衡量的事。这个技能要解决的就是：把模糊抱怨变成一套可反复重跑的评测集，让通过率成为唯一裁判。

工作方式：四步闭环

1. 深挖：拒绝形容词，只收集原始失败记录（真实输入 + 真实输出 + 期望输出），至少 20 条。逐条抠出"这次到底败在哪一环"。
2. 聚类：按失败环节分组。经验规律是大部分模糊抱怨最终指向 1-2 个具体可测的问题——比如 Claude 案例中 80% 的"不遵循指令"最终指向 JSON 输出不稳定。输出物应是一句可测的定义（如"字段缺失率约 30%"），而不是"模型不智能"。
3. 固化：把失败例子写成评测集文件（Markdown 表格或 JSONL），起步 20-40 个真实案例即可。判定优先用确定性检查（格式、必含字段、长度），主观维度才用 AI 评委，并人工抽查校准。
4. 门禁：每次改动后全量重跑整个评测集。通过率没升等于没改进；老案例失败视为回归，先修回归再谈新功能。

机制上，AI 负责深挖、聚类、批量重跑和统计；判定标准怎么定、痛点算不算解决，由人拍板。

适用边界与注意点

• 适用：输出不确定、需要反复改进的系统——Prompt、Skill、Agent 工作流、内容模板、客服话术。
• 不适用：一次性任务（没有"下一版"就不需要评测集）；问题还极模糊、连用户是谁都不知道时，先写文档对齐方向。
• 常见错误：拿感觉当结论、用形容词记录问题、等攒齐完美评测集才开始、只测新功能不跑旧案例。
• 连续两轮通过率不动就触发有界回退：先怀疑判定标准测错了东西，再怀疑聚类找错了真问题，最后才是能力上限——按顺序排查，不硬磨。
• 评测集是活资产：每个生产环境的新失败都追加为案例，它才能持续代表"什么是好"。