一位微软AI研究员最近干了件让同行脊背发凉的事——他用GitHub Copilot写了个工具，把自己每天分析20万行代码的脏活累活全自动化了。更扎心的是，他现在的工作变成了维护这个工具，帮整个团队"复制"自己的失业路径。
这不是裁员故事，而是一份关于"如何用AI把自己从重复劳动中解放出来"的操作手册。Copilot Applied Science团队的John Azariah（约翰·阿扎里亚）在内部博客分享了完整过程，包括他踩过的坑和最终跑通的开发模式。
从"人眼扫描20万行"到"AI自动出报告"
阿扎里亚的日常是评估代码代理（Coding Agent）的性能。行业标准测试集如TerminalBench2、SWEBench-Pro会生成大量轨迹文件（Trajectory）——记录AI代理思考过程和操作步骤的JSON日志。单个任务产生数百行代码，一次基准测试跑下来，他需要消化的信息量轻松突破20万行。
纯人工处理是 mission impossible。他的原始工作流是：用Copilot从海量轨迹中打捞模式，再人工验证关键异常。这个循环他每天重复，直到某个瞬间，"工程师本能"触发——"这明明可以自动化"。
eval-agents项目由此诞生。核心思路很直接：既然Copilot能帮人类读代码，那能不能让Copilot驱动的代理直接生成分析报告？
三个设计原则，避开"自动化陷阱"
阿扎里亚给项目定了三条铁律，全部来自血泪经验。
第一，工程与科学团队必须共用同一套工具链。他见过太多研究代码写成"一次性脚本"，换个环境就跑不通。eval-agents从第一天就按生产级标准构建，科学家能直接上手，工程师也能无缝维护。
第二，开源协作方法论。阿扎里亚有GitHub CLI开源维护者的背景，代码审查、Issue追踪、文档优先——这些习惯被完整移植。他特别强调："你的'临时工具'明天可能就是别人的关键依赖。"
第三条最关键：让非工程师也能自定义分析逻辑。他观察到，科学家同事的需求高度个性化——有人关注代理的调试策略，有人追踪特定类型的失败模式。硬编码任何分析规则都是死路，必须提供"声明式配置"接口。
Copilot的隐藏用法：从"代码补全"到"需求翻译"
eval-agents的开发过程本身成了Copilot能力的压力测试。阿扎里亚总结了几条反直觉的使用技巧。
把自然语言需求直接丢给Copilot，效果往往比精心设计的提示词更好。他举例：与其写"请实现一个函数，输入为JSON轨迹，输出为错误分类统计"，不如直接粘贴同事的原话——"我想知道代理什么时候陷入循环调试"。Copilot对"人类抱怨"的理解能力被严重低估。
另一个发现是上下文窗口的战术性管理。轨迹文件动辄上千行，全部塞进对话会触发token上限。阿扎里亚的做法是：先用Copilot生成"摘要代理"，输出关键事件时间线；再把压缩后的结构喂给"分析代理"。两层架构既规避了长度限制，又保留了可解释性。
最意外的收获是测试策略。传统软件测试验证"代码是否符合预期"，但eval-agents面对的是开放域分析——同样一段轨迹，不同科学家可能关注不同维度。他的解法是让Copilot生成"对抗性测试用例"：故意构造模糊或矛盾的轨迹，检验分析代理是否会给出过度自信的结论。
工具上线后，团队发生了什么
eval-agents目前在Copilot Applied Science团队内部全量推广。阿扎里亚的直属同事们用它自定义了十几种分析视角，从"代理何时调用外部工具"到"多步推理中的上下文丢失模式"。
他本人的工作重心彻底转移。以前80%时间泡在轨迹文件里，现在80%时间维护eval-agents框架、响应同事的定制需求。用他自己的话说："我可能刚刚把自己自动化到了一个完全不同的岗位。"
这个转变的微妙之处在于价值层级的跃迁。从"亲自解决具体问题"到"建造让别人解决具体问题的基础设施"，正是资深工程师与架构师的分水岭。Copilot没有取代他，而是把他从重复认知劳动中弹射出来，迫使他进入更高抽象层级。
阿扎里亚在文末留下一个未解的问题：当每个知识工作者都能用类似思路"自动化自己"，组织该如何重新设计晋升体系和绩效评估？毕竟，传统的"代码产出量"或"分析报告数量"指标，在这种新范式下可能完全失效。
热门跟贴