self-eval

self-eval skill 概览

self-eval 适合用来做什么

self-eval skill 是一个仅基于 prompt 的 Claude Code skill，用于在工作完成后进行坦诚的自我评估。它能帮助 AI agent 在完成任务、代码审查、实现开发、调试排查或方案规划之后，评估自己的输出，而不是默认给出空泛表扬或虚高的“4/5”分数。

self-eval 不是在单一主观尺度上问“这做得怎么样？”，而是把评估拆成两个维度：任务目标的难度/野心，以及执行质量。这样，当你需要一个更有校准感的答案时，它会更有用：这次工作到底是真的很强，还是只是把一个简单任务做到了及格？

最适合的用户和任务

如果你希望 agent 在你接受结果、合并代码或继续基于它开发之前，先回顾已完成的工作，可以使用 self-eval skill。它尤其适合在工程团队中用于 AI 参与的代码生成、重构、issue 分诊、测试编写或架构分析。

它不能替代测试套件、人工 review、安全审查或生产环境验证。它的价值在于结构化自我批判：抑制过度自信，暴露薄弱点，并在多个工作会话之间留下可追踪的评分记录。

它和普通 prompt 有什么不同

普通的“评价一下你的工作”prompt 往往会产出泛泛的优点、轻描淡写的保留意见，以及偏乐观的分数。self-eval 增加了一些约束，让分数膨胀更难发生：必须进行 devil’s advocate 推理、使用固定评分矩阵，并把分数持久化到 .self-eval-scores.jsonl。

这种持久化很重要。如果近期评估结果过于集中，skill 可以提示可能存在评分膨胀模式，而不是把每次 review 都当作孤立事件处理。

如何使用 self-eval skill

self-eval 安装与仓库检查

可以使用你的 skill manager 从 GitHub skill source 安装，例如：

npx skills add alirezarezvani/claude-skills --skill self-eval

相关仓库路径是：

engineering/skills/self-eval/SKILL.md

当前结构中没有外部依赖、辅助脚本、内置规则或参考文件。安装前如果想快速判断是否适合，先阅读 SKILL.md；其中包含评分模型、工作流和输出预期。由于这是一个 prompt-only skill，引入风险较低，但输出质量很大程度取决于你是否提供了足够的任务上下文。

skill 需要哪些输入

要让 self-eval 真正有用，不要只说“评价一下这个”。你需要把已完成的工作，以及判断它好坏的标准，一起提供给 agent。

高质量输入包括：

• 原始用户请求或 issue 描述
• agent 产出的最终回答、patch、方案或 review
• 相关约束，例如时间限制、风格规则、测试要求或禁止采用的做法
• 验证证据，例如运行过的测试、改动过的文件、执行过的命令或已知缺口
• 目标读者：maintainer、reviewer、product owner、新手用户或生产团队

较弱的 prompt 只是要求给分。较强的 prompt 会给 skill 足够证据，用来区分“目标不高但执行干净”和“目标很高但完成度不足”。

获得更好结果的 prompt 模式

self-eval 应该在工作完成后使用，而不是开始前使用。一个实用 prompt 可以这样写：

Use the self-eval skill to evaluate the work below. Original task: [goal]. Output produced: [answer or diff summary]. Constraints: [tests, style, repo rules]. Validation performed: [commands or none]. Known concerns: [risks]. Give the two-axis evaluation, devil's advocate reasoning, final matrix score, and concrete follow-up actions.

这种结构能提升评估质量，因为它避免模型只根据语气或努力程度打分。它会迫使 review 同时考虑目标难度、执行结果、证据和未解决风险。

建议工作流

在那些“过于正面”的评估可能带来成本的检查点运行 self-eval：

1. 完成任务或起草解决方案。
2. 使用原始目标和工作证据请求 self-eval。
3. 先阅读 devil’s advocate 部分，再看最终分数。
4. 把暴露出的弱点转成简短修复清单。
5. 只有在做了实质性修改后才重新运行，不要在只做了格式或措辞调整后重跑。

如果你的工作目录中生成了 .self-eval-scores.jsonl，请把它视为本地评估历史。你的团队需要决定这个文件是提交到仓库、加入 ignore，还是定期回顾。

self-eval skill 常见问题

self-eval 是用于 Model Evaluation 还是代码质量？

两者都可以，但含义要收窄理解。self-eval for Model Evaluation 更适合理解为对 AI agent 自身工作进行任务级评估，而不是基准测试级别的模型测量。它可以帮助比较不同会话、发现虚高的自评分，并改善 review 纪律，但不能替代正式的 eval harness、golden dataset 或人工标注评分。

什么时候不应该使用 self-eval？

不要把它作为高风险工作的唯一关卡：安全敏感改动、法律或医疗内容、生产迁移，或任何需要验证正确性的事项都不适合只靠它判断。没有具体可评估产物时也应避免使用。这个 skill 需要任务、输出和评估标准；否则它仍然会生成结构化内容，但证据会很薄弱。

它适合新手吗？

适合，因为它是 prompt-only，没有工具依赖。不过新手在使用前仍然应该阅读 SKILL.md，尤其是评分逻辑。主要学习成本不在安装，而在于提供足够上下文，避免评估只凭感觉。

它和直接要求 critique 有什么区别？

critique 可以列出问题，但不一定有校准过的评分。self-eval 使用双轴模型和矩阵锁定的最终分数，因此 agent 更难随意为一个“感觉合理”的评分找理由。devil’s advocate 步骤也要求在给出最终判断前，分别为更高分和更低分进行论证。

如何改进 self-eval skill

为 self-eval 提供更强证据

改进 self-eval 结果的最好方式，是让证据更具体。包括改动文件、失败或通过的测试、重要遗漏项和验收标准。如果没有运行测试，就明确说明。如果回答有意跳过了某个要求，也要写出来。

更好的输入不等于更长的输入，而是更可评估的输入。“Refactored auth code”很弱。“Refactored auth/session.ts to remove duplicated token parsing; ran npm test -- auth; did not test OAuth callback manually”则给了 skill 可以真正评分的材料。

留意常见失败模式

最常见的失败，是让模型奖励努力程度，而不是结果质量。另一个常见问题，是把一个困难任务中的部分完成自动视为强表现。self-eval 的设计就是为了抵抗这些倾向，但前提是用户提供了原始目标和实际交付物。

也要留意评分历史的噪声。如果 .self-eval-scores.jsonl 混入了彼此无关的任务类型，聚类信号的意义可能会下降。一次文档润色和一次复杂迁移，不应仅仅因为数值分数相同就被解读为等价。

从分数迭代到行动

不要停在最终分数上。真正有用的是目标难度和执行质量之间的差距。把这个差距转成修复 prompt：

Based on the self-eval weaknesses, revise the work to address the top three execution gaps. Do not expand scope. Preserve the original constraints and report what changed.

这样可以让下一轮迭代保持聚焦，也能防止 agent 为了追求更高分而通过添加无关功能来“改进”工作。

谨慎定制

如果你要调整 self-eval skill，请保留那些用于校准的关键部分：分离的评估轴、devil’s advocate 推理、固定分数映射，以及对评分历史的感知。定制标签、输出格式或团队专属验收标准通常是安全的。移除那些迫使模型反驳自身判断的约束，会让这个 skill 退化成普通 review prompt。