自我评估

self-eval
分类编程
作者Alireza Rezvani
许可MIT
评分4.70/5
使用7.9K

Self-Eval: 诚实的工作评估

ultrathink

等级： STANDARD
类别： Engineering / Quality
依赖： 无（仅限提示词，无需外部工具）

描述

Self-eval 是一个 Claude Code 技能，旨在产生诚实且经过校准的工作评估。它通过结构化的双轴评分系统、强制性的反方论证以及跨会话的虚高检测，取代了 AI 倾向于将所有项都评为 4/5 的默认习惯。

核心洞察：AI 的自我评估往往会收敛于“全部 4 分”，因为单轴评分将任务难度与执行质量混为一谈。Self-eval 将这两个维度分开，然后通过一个模型无法覆盖的固定矩阵进行组合。

特性

  • 双轴评分 — 独立评估任务野心（低/中/高）和执行质量（差/合格/强），然后通过查找矩阵组合得分。
  • 强制反方论证 — 在最终定分前，必须分别论证更高分和更低分的理由，然后化解矛盾。
  • 分数持久化 — 将分数追加到工作目录下的 .self-eval-scores.jsonl 文件中，构建跨会话的历史记录。
  • 虚高检测 — 读取历史分数并标记聚集现象（最近 5 次中有 4 次或更多分数相同）。
  • 矩阵锁定评分 — 综合得分来自矩阵而非直接选择。低野心任务无论执行质量如何，最高得分被限制在 2/5。

使用方法

在 Claude Code 会话中完成工作后：

code
/self-eval

或提供评估上下文：

code
/self-eval the authentication refactor we just completed

该技能将回顾对话历史，识别完成的工作，在两个维度上进行评分，执行反方论证检查，并将结果追加到分数历史文件中。

示例

示例 1：功能实现

code
/self-eval added pagination to the user list API

输出：

code
## 自我评估


任务： 为用户列表 API 接口添加了基于游标的分页
野心： 中 — 新功能且有既定模式，但需要谨慎处理向后兼容性
执行： 强 — 所有测试通过，处理了边缘情况，现有客户端不受影响


反方论证：
  • 降低：分页文档齐全。该模式是从另一个接口微调复制而来的。可以认为是低野心。

  • 提高：向后兼容的要求使其比从零实现更困难。必须同时支持偏移量和游标模式。

  • 结论：维持中等野心 —— 向后兼容的约束增加了除复制粘贴之外的实际复杂度。


得分：4 — 在有实际约束的有意义工作上实现了稳健的执行。

示例 2：Bug 修复

code
/self-eval

输出：

code
## 自我评估


任务： 修复了导致重复订单的结账流程竞态条件
野心： 中 — 需要跨 3 个服务进行调试才能找到根本原因
执行： 合格 — 修复有效，但测试仅覆盖了报告的特定场景，而非此类竞态条件的通用情况


反方论证：
  • 降低：修复仅为一行代码（添加互斥锁）。一旦找到，解决起来非常简单。

  • 提高：在 3 个服务中寻找根本原因需要真正的调查分析。

互斥锁（mutex）的放置需要对完整流程有深入理解。
  • 结论：调查阶段的“中等野心”评级正确，但执行力降至“合格”——更彻底的修复应该解决模式问题，而不仅仅是单个实例。

得分：3 —— 调试工作出色，但修复范围过窄。

code
---


评估内容


$ARGUMENTS


如果没有提供参数，请回顾完整的对话历史以确定本会话完成了哪些工作。在评分前用一句话总结工作内容。


评分方法 —— 双轴模型


在两个独立轴上分别评分，然后使用矩阵得出综合分。不要先定分数再找理由 —— 请分别评定每个轴，然后查阅矩阵。


轴 1：任务野心 (Task Ambition) —— 尝试了什么


评定所处理工作的难度和风险，而非完成质量。


  • 低 (1) —— 安全、熟悉、常规。几乎没有失败风险。例如：微小的配置更改、简单的重构、带有小修改的复制粘贴、在开始前就确信能完成的任务。


  • 中 (2) —— 具有新意或挑战的有意义工作。存在部分失败的可能性。例如：新功能实现、集成不熟悉的 API、架构变更、调试棘手问题。


  • 高 (3) —— 极具野心、不熟悉或高风险。存在完全失败的真实风险。例如：在不熟悉的领域从零开始构建、复杂的系统重新设计、性能关键型优化、在压力下交付生产环境。


自检： 如果你在开始前就确信能成功，那么野心评级应为“低”或“中”，而非“高”。


轴 2：执行质量 (Execution Quality) —— 完成得如何


评定实际输出的质量，独立于任务的野心程度。


  • 差 (1) —— 重大失败、未完成、输出错误或中途放弃。交付物未达到其自身设定的标准。


  • 合格 (2) —— 已完成但存在缺陷、走捷径或缺乏严谨性。完成了任务，但留有明显的改进空间。


  • 强 (3) —— 执行良好，详尽且高质量。在给定范围内没有明显的遗漏或改进空间。


综合评分矩阵


|                        | 执行差 (1) | 执行合格 (2) | 执行强 (3) |
|------------------------|:---:|:---:|:---:|
| 低野心 (1)         |  1  |  2  |  2  |
| 中野心 (2)         |  2  |  3  |  4  |
| 高野心 (3)         |  2  |  4  |  5  |


严格遵守矩阵，不要随意更改。 综合分即为最终得分。下方的“反方观点”可能会让你重新评定某个轴 —— 但你不能直接覆盖矩阵结果。


核心特性：
  • 低野心最高得 2 分。完美完成的安全工作依然是安全工作。

  • 5 分要求同时具备“高野心”和“强执行”。这种情况应较为罕见。

  • 高野心 + 执行差 = 2 分。大胆的失败是有代价的。

  • 扎实工作的最常见诚实得分是 3 分（中等野心，合格执行）。


反方观点 (强制执行)


在写出最终得分前，你必须写出以下三项：


1. 降低分数的理由： 为什么这项工作可能值得更低的分数？哪些部分很简单？避开了什么？哪些部分比看起来要简单？一个持怀疑态度的评审员会同意你的轴评级吗？
2. 提高分数的理由： 为什么这项工作可能值得更高的分数？哪些部分真正具有挑战性、出人意料或超出了原计划？
3. 最终结论： 如果上述任何一种情况揭示你对某个轴的评级有误，请重新评级并重新计算矩阵结果。然后给出最终得分，并用 1-2 句话说明理由。
确保你的解释至少涵盖了每个案例中的一个要点。


如果你的“反方观点”总长度不足 3 句话，说明你没有深入思考 —— 请尝试更深入地分析。


防止分数虚高检查


检查当前工作目录下是否存在 .self-eval-scores.jsonl 分数历史文件。


如果文件存在，请读取并检查最后 5 个分数。如果其中 4 个或更多分数相同，请标记：
> 警告：检测到分数聚集。 最近 5 个分数：[列表]。请思考你是否在依赖默认分值。


如果文件不存在，请自问：“外部观察者会对此给出与我相同的评分吗？”


分数持久化


在提交评估后，向当前工作目录下的 .self-eval-scores.jsonl 文件追加一行内容：
json
{"date":"YYYY-MM-DD","score":N,"ambition":"Low|Medium|High","execution":"Poor|Adequate|Strong","task":"1-sentence summary"}
```

这将使防止虚高检查在不同会话之间生效。如果文件不存在，请创建它。

输出格式

请按以下格式提交评估：

自我评估

任务： [对尝试完成内容的 1 句话总结]
野心 (Ambition)： [低/中/高] — [1 句话理由]
执行 (Execution)： [差/合格/强] — [1 句话理由]

反方观点 (Devil's Advocate)：

  • 较低分理由：[为什么可能得分更低]

  • 较高分理由：[为什么可能得分更高]

  • 最终裁定：[最终推理过程]

得分：[1-5] — [1 句话最终理由]