用途：解决提示词作者无法自评质量的问题——作者已掌握隐含上下文，重读难以发现歧义。该方法通过派发无偏见的执行者、双向评分并迭代，直到改进停滞。它是方法而非工具，运行在 Claude Code 中，借助 Task 工具生成全新子代理；仓库的 scripts/eval-skill.sh 与 evals/ 目录负责记录，SKILL.md 是工作流。灵感来自 mizchi/skills/empirical-prompt-tuning，可用 apm install -g mizchi/skills/empirical-prompt-tuning 安装上游版本。
适用时机：新建或大幅修改技能、斜杠命令、子代理提示词或 CLAUDE.md 之后；技能从草稿转为发布（合并 main 前）；用户反馈行为异常且怀疑是指令歧义而非模型失败。不适用：一次性临时提示词、琐碎措辞改动、仅检查个人偏好。
工作流：0）先核对 SKILL.md 前置描述与正文是否一致，避免子代理按描述曲解正文造成假阳性。1）冻结评测装置：在 evals/<skill-name>/scenarios.yaml 写 2–3 个真实场景（1 典型 + 1 边界），每场景 3–7 项需求清单，至少一项标 [critical]；记录后不得回溯修改清单。可用 bash scripts/eval-skill.sh init <skill-name> 搭建目录。2）无偏见派发：每个场景用 Task 工具生成全新子代理，只传场景提示，不粘贴、不概述、不暗示答案。3）双向评分：填写 runs/<timestamp>.md，记录执行者自述（不清晰点、自行填补处、模板不适配处，按理解/规划/执行/格式化阶段标注）与指令侧指标（通过/失败、准确率、工具调用步数、耗时、重试次数），并按 Issue/Cause/General Fix Rule 记录。4）最小修复：每轮只改一个主题，先说明对应哪条清单项；若同一修复规则反复出现，应把已有修复移到更显眼位置而非新增。5）循环：每次用新子代理，连续两轮无新不清晰点且准确率/步数/耗时改进低于 5% 时停止；高重要性技能需连续三轮平台期。6）记录：向 ledger.md 追加一行摘要。CI 质量门（eval-quality-gate.yml）要求修改 SKILL.md 的 PR 附带通过记录，或在描述中加 [skip-eval] 并说明理由。
反模式：自读草稿判定清晰、看到结果后改清单、跨轮复用同一子代理、为反复出现的失败类新增记录。收敛后最终报告应含技能名与提交哈希、各轮准确率与步数、已解决的失败模式、残留限制及最新运行文件位置。