那我干什么：从审查代码到设计验证体系

走到这里，一个根本性的角色转变已经发生了。

在传统开发中，高级工程师的核心工作之一是 code review：逐行阅读团队成员的代码，检查逻辑正确性、代码风格、潜在的性能问题、安全漏洞。这项工作依赖审查者对系统的深入理解和丰富的工程经验。

在 Agent 驱动的开发中，逐行审查代码变得既不可行（速度跟不上）也非最优（人类的注意力应该花在更高杠杆的地方）。验证体系接管了大部分传统 code review 的职责。测试验证功能正确性。对抗式 Agent 检查规约遵从度。自动化工具检查代码风格和安全漏洞。

人类的角色从审查代码转移到两个更高杠杆的活动上。

第一，审查测试和规约。验收标准是否准确反映了业务意图？Trophy 测试是否覆盖了关键的用户场景？测试的断言是否验证的是行为而非实现细节？这些判断需要对业务的理解和对用户需求的把握，是 Agent 无法替代的。

第二，设计验证体系本身。在什么环节设置闸门？用什么类型的测试覆盖什么层面的风险？如何配置对抗式验证的规则？验证体系的设计决定了整个开发流程的可靠性上限。

合并门槛也随之变化。传统的合并标准是"通过 code review + CI 测试全绿"。在 Agent 驱动的开发中，正确性测试全绿仍然是必要条件，但不充分。合并之前至少还需要一个适用性（fitness）信号：端到端的 Trophy 测试通过，或者真实数据的回放验证通过，或者利益相关者的验收确认。如果以上都没有，需要明确记录豁免理由。

这个角色转变对团队的能力结构有深远影响。传统团队最看重的是编码能力：算法水平、语言熟练度、调试技巧。Agent 驱动的团队最看重的是规约能力和验证设计能力：能否将业务意图转化为可测试的验收标准，能否设计出有效的验证策略来保障产出质量。编码能力让位于工程判断力。