评估的七个维度
User-facing Dimensions（用户面维度）
用户直接体验的维度：
Dimension 1：Intent Satisfaction（意图满足）
问题：Agent 是否构建了用户真正想要的，而非仅是用户说的？
难点： - 意图未陈述、模糊、常在会话中途改变 - 用户最终判断依据
评估挑战：
用户说："Make the dashboard load faster"
Agent 可能理解：
• 优化查询？✓
• 添加缓存？✓
• 减少数据量？✓
• 简化 UI？✓
哪个是用户真正想要的？→ 最难评估维度Dimension 2：Functional Correctness（功能正确性）
问题：代码是否构建、运行、通过测试？
性质：地板而非天花板
易游戏：
危险模式：
• 测试可删除或 mock → red turn green（红变绿）但不修复任何东西
• Agent 可能删除失败测试而非修复代码 ❌Dimension 3：Visual and Behavioural Correctness（视觉和行为正确性）
适用：生成 web apps 或 UI 的 Agent
焦点：渲染输出而非代码
关键：
代码级指标完全错过重点：
正确评估：
• 页面看起来正确 ✓
• 页面行为正确 ✓
而非：
• 代码语法正确 ❌（无关）Internal Dimensions（内部维度）
Agent 不可见行为：
Dimension 4：Cost and Efficiency（成本和效率）
指标：
- Token spend（令牌消费）
- Wall-clock latency（墙钟延迟）
- Tool-call count（工具调用计数）
- Iteration count（迭代计数）
- 用户修正次数 → Agent 收敛需要多少修正？
关键对比：
Agent A：1 轮达到正确 diff
Agent B：8 轮修正达到正确 diff
→ 两种完全不同的产品Dimension 5：Code Quality and Convention Matching（代码质量和规范匹配）
问题：代码是否匹配项目风格、模式、规范？
Vibe-coding 失败：
示例：
Diff 通过测试 ✓
但违反代码库风格 ❌
→ 本地正确但全局失败
→ Vibe-coding 失败Dimension 6：Trajectory Quality（轨迹质量）
问题：Agent 是否采取合理路径？
考虑：
- 先读相关文件？
- 序列编辑连贯？
- 每步选择正确工具/skill？
关键洞察：
Correct output produced by bad reasoning is a fragile success
— 糟糕推理产生的正确输出是脆弱的成功
Dimension 7：Self-Repair Behaviour（自修复行为）
问题：构建失败、测试破坏、用户说”不，不是那样”时，Agent 是否恢复或加剧失败？
性质：恢复质量在多轮会话中复合
Dimension Relationships（维度关系）
非独立：维度相互关联
示例关系：
更强 Trajectory Quality (维度 6)
→ 通常意味更强 Functional Correctness (维度 2)
→ 是 Intent Satisfaction (维度 1) 的前提