编码 Agent 评估特例

不要把编码代理的做法推广到一般 AI 产品。"只靠 vibes"在编码代理上成立有三个隐藏前提：

1. 开发者本人就是域专家：构建者能直接看出生成代码的好坏，标注/反馈环路坍缩进个人判断，不需要显式组织 error analysis。
2. 全天候真实 dogfooding：开发者整天用自己的产品，等价于持续的人肉在线监控。多数领域不具备这个条件——工程师不会以病人身份高强度使用医疗 AI，也不会主动索取错误医疗建议来测试容错。
3. 站在基座模型 evals 的肩膀上：Claude Code 受益于 Anthropic 对模型做的大量编码 benchmark；"不做 evals"的产品其实构建在同事的 evals 之上。

此外这类团队大概率仍在做隐式 evals：监控使用量/对话长度、内部反馈队列、非正式 error analysis——按"系统性度量与改进"的定义这些都是 evals。争论多半源于对 evals 的狭义定义（只当它是单元测试或 Likert 打分），以及被劣质 evals 烧伤过的经历。

附带 caveat：宣称式 dogfooding 是危险的——很多团队说自己在 dogfood，但没达到能闭合反馈环路的强度。

自检清单（判断能否降低显式 evals 投入）：团队是否就是目标域专家？是否高强度真实使用自己的产品？是否有上游/基座模型 evals 兜底？三者不全，就需要显式 evals 流程。