Agent Self-Evaluation â€?5 轴自评估

任务完成后，对输出进行结构化自评。这不是通过/失败门控，而是刻意反思步骤，在用户之前捕获遗漏、标记过度自信ã€?surfaced 改进区域ã€?

触发条件

• 编写è·?3+ 文件æˆ?50+ 行代ç ?- 完成多步骤工作流（实çŽ?â†?测试 â†?审查ï¼?- 调试会话涉及 3+ 次尝è¯?- 产出设计文档、架构决策或书面分析
• 用户é—?那有多好ï¼?æˆ?评价一下你自己"

5 个评估轴

评分标准

5 â€?卓越：无合理改进可能
4 â€?良好：只有小瑕疵，无实质性差è·?3 â€?足够：满足请求但至少一个轴有明显弱ç‚?2 â€?弱：有明确差距影响可用性正确æ€?1 â€?差：根本未满足请求或包含重大错误

证据规则

*每个低于 5 分的必须引用具体证据ã€?

3 分不能只è¯?可以更好"——必须说å‡?缺少什ä¹?æˆ?错在哪里**ã€? 口号ï¼?"展示差距，不只是命名它ã€?

工作æµ?

Step 1: 收集原始材料

收集要评估的内容ï¼?

- 原始用户请求（从对话中回读）
- 最终响åº?输出（可交付物）
- 验证正确性的任何工具输出（测试结果、退出码、lint 输出ï¼?- 任务期间收到的任何用户反馈（纠正ã€?再试一æ¬?ã€?那不å¯?ï¼?```

### Step 2: 独立评分每个è½?
逐个处理 5 个轴。对每个ï¼?
1. 阅读轴问é¢?2. 在输出中查找证据（或缺乏证据ï¼?3. 分配分数 1-5
4. 如果分数 < 5，写一句改进说明引用差è·?
**不要**先在心中平均分数然后反向工作。每个轴新鲜评分ã€?
### Step 3: 产出评估报告

报告必须包括ï¼?

• 一行摘è¦?- 5 轴评分卡（每轴的分数 + 证据ï¼?- 总分（简单平均，四舍五入åˆ?1 位小数）
• 按影响排序的 1-3 个具体改è¿?- 自检ï¼?用户会同意这个评估吗ï¼?

### Step 4: 应用改进

如果任何轴评åˆ?3 或以下：

1. 说明你会怎么做不å?2. 如果差距可在 < 30 秒内修复（缺少链接、不清晰措辞），立即修复
3. 如果差距需要返工，明确标记ï¼?这个轴评åˆ?[原因] 因为 [证据]。用 [具体修复] 重新运行可能会提高到 [分数]ã€?

## 报告模板

```markdown
## Self-Evaluation Report

**Task**: {task description}
**Overall Score**: {average}/5

### Scorecard

| Axis | Score | Evidence |
|------|-------|----------|
| Accuracy | {1-5} | {specific evidence or "No gaps found"} |
| Completeness | {1-5} | {specific evidence or "No gaps found"} |
| Clarity | {1-5} | {specific evidence or "No gaps found"} |
| Actionability | {1-5} | {specific evidence or "No gaps found"} |
| Conciseness | {1-5} | {specific evidence or "No gaps found"} |

### Top Improvements

1. {highest impact improvement}
2. {second highest}
3. {third highest}

### Self-Check

Would the user agree with this assessment? {Yes/No, why}

示例

示例 1: 良好评估ï¼?+ 分）

## Self-Evaluation Report

**Task**: Add retry logic to HTTP client
**Overall Score**: 4.6/5

### Scorecard

| Axis | Score | Evidence |
|------|-------|----------|
| Accuracy | 5 | All API calls correct. Verified: retries use exponential backoff. No hallucinated methods. |
| Completeness | 4 | Covered happy path + 3 error cases. Missing: timeout handling for hung connections. |
| Clarity | 5 | Code comments explain backoff formula. PR description links to incident. |
| Actionability | 5 | Single merge. No follow-up tasks. Tests pass. |
| Conciseness | 4 | 47 lines total. The retry loop could be extracted into a helper to drop ~8 lines. |

### Top Improvements

1. Add timeout handling for hung connections (Completeness)
2. Extract retry loop into helper function (Conciseness)

### Self-Check

Would the user agree? Yes �one clear gap (timeout) identified, fix is straightforward.

示例 2: 弱评估（2-3 分）

## Self-Evaluation Report

**Task**: Add retry logic to HTTP client
**Overall Score**: 2.8/5

### Scorecard

| Axis | Score | Evidence |
|------|-------|----------|
| Accuracy | 2 | Used urllib3 which doesn't match our httpx-based codebase. Wrong library. |
| Completeness | 3 | Works for GET. POST/PUT not handled (user said "all HTTP requests"). |
| Clarity | 4 | Code is readable. Good variable names. |
| Actionability | 2 | "Add tests" mentioned but no test file created. User has to write tests before merging. |
| Conciseness | 3 | 120 lines. Retry config duplicated in 3 places instead of one shared RetryConfig object. |

### Top Improvements

1. Switch to httpx transport (Accuracy �wrong library)
2. Extend to all HTTP methods (Completeness �POST/PUT missing)
3. Consolidate retry config into single object (Conciseness �3x duplication)

### Self-Check

Would the user agree? Yes �wrong library is critical, must fix before merging.

反模�

"Everything is a 5"

FAIL: Accuracy:    5 �All good.
   Completeness: 5 �Everything covered.
   Clarity:      5 �Clear.

无证据引用。这是自我祝贺，不是评估。真正的 5 需要证明没有改进空间ã€?

Over-penalizing for scope creep

FAIL: Completeness: 2 �Didn't handle WebSocket connections or gRPC streaming (user didn't ask for these)

只针对用户实际请求的内容评估，不是你可能额外构建的内容ã€?

Using the evaluation to re-litigate

FAIL: "As I said earlier, this approach is wrong. Score: 1"

评估是关于交付的输出，不是关于重新争论已经做出的设计决策。如果方法错误，应该在交付前捕获ã€?

Mixing personal preference with objective gaps

FAIL: "Score: 3. I don't like Python decorators."

"不喜æ¬?不是证据。引用具体的可读性、可测试性或正确性问题，或保持分æ•?4+ã€?

最佳实è·?

• *评估输出，不是过程ã€? 用户关心你交付了什么，不是你花了多少次迭代ã€?- *每个弱轴一个改进ã€? 不要为一个轴列出 5 件事——选择最高影响差距ã€?- *将改进与用户影响绑定ã€? "缺少错误处理意味着用户çš?API 调用会静默崩æº? æ¯?"添加错误处理" 更好ã€?- *具体说明"修复"的样子ã€? "用为重试配置çš?httpx 传输重新运行" æ¯?"修复库问é¢? 更好ã€?- *使用工具输出作为证据ã€? 如果测试通过，引用它们。如æž?lint 干净，引用它。不要猜测——grep 证明ã€?- *如果找不到任何差距，更努力尝试ã€? 5 个轴的完美分数很罕见。问ï¼?如果我是用户，这个输出的什么会让我烦恼ï¼?

与现有规则的关系

简化使ç”?

不需要每次都完整报告。对于快速检查：

## Quick Self-Check

- Accuracy: {1-5} �{one-line evidence}
- Completeness: {1-5} �{one-line evidence}
- Clarity: {1-5} �{one-line evidence}
- Actionability: {1-5} �{one-line evidence}
- Conciseness: {1-5} �{one-line evidence}

**Overall**: {average}/5
**Top fix**: {highest impact improvement}

*5 轴自评估：在用户之前捕获遗漏，用证据说话ã€?