GitHub 把程序员的脏活累活交给 Agent 了：最先升值的，反而是文档和测试
很多人聊 AI 编程，喜欢把重点放在一个很热血的画面上：
- Agent 自己改代码
- Agent 自己提 PR
- Agent 自己跑测试
- 人类只负责最后点头
听起来很爽，但说实话，这种叙事有时候也有点悬浮。因为真实开发里，最烦人的问题往往不是“模型会不会写代码”，而是 它进了一个又乱、又脆、又没人写文档的仓库以后，到底还能不能稳定做事。
GitHub Copilot Applied Science 团队这两天发的一篇实践文，真正让我觉得有意思的，不是它又展示了什么神奇 Agent，而是它把一件很多团队不太愿意承认的事实讲得很明白：
当 Agent 开始成为真正的开发参与者，最先升值的东西，往往不是新功能，而是文档、测试、重构和流程。
这话听起来有点像工程经理鸡汤，但我觉得它恰恰戳中了现在 AI 开发工具最真实的矛盾。
他们到底干了什么
这次 GitHub 分享的背景，不是常见的“我让 Agent 做了个 todo app”。而是 Copilot Applied Science 团队里有人要分析大量 coding agent 的 benchmark 轨迹数据，比如 TerminalBench2 和 SWEBench-Pro 之类。
问题在于，这类轨迹动不动就是成百上千个 JSON 文件，里面全是 agent 在做任务时的思考、动作和执行路径。人工硬读不仅痛苦，而且很容易陷进信息泥潭。
于是他们做了一件很程序员的事：
既然我已经在用 Agent 帮我读这些轨迹，那为什么不继续往前一步，直接做一套用 Agent 构建 Agent 的工具？
最后的结果挺夸张：在不到三天时间里，5 个人一起做出了 11 个新 agent、4 个新 skill，还顺手搞出了一套新的 workflow，代码变更跨了 345 个文件。
如果只看这个结果，很容易得出一个简单粗暴的结论：Agent 已经把开发效率拉爆了。
但我觉得更值得看的，是它背后的条件。
真正决定上限的，不是模型，而是仓库配不配合
这篇分享里最有含金量的一句，不是某个 prompt，也不是某个 benchmark，而是他们反复强调的一个思路：
想让 coding agent 像工程师一样工作，你就得先把工程环境整理到像是给工程师用的。
翻成大白话就是：
- 结构别太乱
- 命名别太抽象
- 文档别常年欠债
- 测试别只是摆设
- review 流程别全靠拍脑袋
以前这些事很多团队也知道重要，但总会被新功能挤掉。理由也很熟：
“先上线再说。”
“文档以后补。”
“这块虽然丑但能跑。”
“测试等有时间再加。”
问题是，人类工程师还能靠经验、语境和忍耐力硬扛；Agent 一进这种环境，立刻就会把仓库真实质量照妖镜一样照出来。
代码结构混乱，它就容易迷路。
命名语义不清，它就容易误判。
文档缺失，它就会用猜的。
测试松散，它就会把回归 bug 当正常演进。
所以 Agent 时代一个很反直觉的变化是：
那些以前常被当成“维护成本”的东西，现在开始直接影响自动化产能。
文档为什么突然变成生产资料
我很认同文中一个核心判断：当你真的开始让 Agent 参与开发，文档不再只是“方便新人上手”的礼貌性资产，它会变成一种直接影响执行质量的生产资料。
因为 Agent 的工作方式，本质上很像一个读得快、手也快、但特别依赖上下文的新同事。你不给它明确规则，它不是不会动，而是会根据仓库里现存的碎片信息自己脑补。
而开发里最可怕的，往往不是它完全不会做，而是 它用一种看起来很合理、实际上不符合你团队约定的方式去做。
所以他们的做法很值得抄：
- 先用
/plan让 Agent 参与规划 - 计划里明确要求把测试写进去
- 文档更新要提前做，不是代码写完再补
- 让 code review agent 先循环 review 几轮
- 最后再上人工 review
这一套下来，文档的角色就变了。它不只是记录过去，而是在约束未来。
测试也不是为了防低级错误，而是为了防“看起来很对”
传统开发里，很多人把测试理解成兜底机制：防止手滑、避免重构翻车。
但到了 Agent 开发阶段，我越来越觉得测试还有另一个用途：
防止一种“表面上特别像对的错误”。
这是 Agent 最容易让人上头的地方。它经常能写出一段风格很顺、结构也像那么回事的代码，甚至还会顺手把旧测试一起改到“全绿”。如果你的测试本身没有契约性，没有明确保留不可随意改动的验证空间，那它很可能一边修功能，一边悄悄改掉原本应该守住的边界。
GitHub 这篇文章里就提到，他们甚至专门设计了一种类似 contract testing 的保护空间，避免 Copilot 把不该碰的测试也一起“优化”掉。
这个思路我觉得特别对。因为 Agent 的风险很多时候不是乱写一通，而是 过于顺滑地帮你把错误合理化。
以后最值钱的，可能不是会下 prompt 的人，而是会搭流程的人
如果把这篇实践再往大一点看，它其实在提醒一件事：AI 编程工具的下一轮竞争，可能不只是“谁模型更强”，而是“谁更会把仓库、流程和守护机制整理成适合 Agent 参与的形状”。
你会发现，这里面真正值钱的能力开始往这些地方偏：
- 会不会把任务拆成 Agent 能理解的边界
- 会不会把文档写成能约束实现的说明
- 会不会设计足够硬的测试和 review 回路
- 会不会在出错后补 guardrail，而不是只骂工具不聪明
这也是文章里那句“blame process, not agents”最有意思的地方。
它不是说 Agent 出错没关系，而是说：如果你已经决定把 Agent 拉进生产流程，那你就不能再用“它怎么又犯傻了”这种情绪化方式管理它。你得像带一个高执行力、但仍然会犯错的初中级工程师一样，靠流程、边界和反馈回路把它带稳。
这件事对普通团队有什么现实意义
不是每个团队都在做 benchmark agent，也不是每个人都用 GitHub Copilot CLI。
但这篇文章对大多数开发团队还是有现实参考价值，因为它把一个很多人模糊感觉到、但还没说透的问题讲清楚了：
Agent 提效不是凭空发生的，它吃的是工程卫生。
如果你的仓库本来就：
- 缺文档
- 缺测试
- 缺命名一致性
- 缺 review 纪律
- 缺最小可验证的交付节奏
那你把再强的 Agent 放进去，它也更像是在垃圾场里开跑车。声势挺大，方向未必稳。
反过来，如果你愿意先把这些基础设施补起来，Agent 才真的可能从“偶尔很好用的炫技工具”，变成“能稳定接活的团队成员”。
我的判断
我对这类实践是偏看好的，而且不是因为它又秀了一次 AI 自动化，而是因为它终于把讨论从“模型多会写”往“团队怎么配合它写”上挪了一步。
这一步非常关键。
因为真正决定 AI 开发工具能不能落地的，从来不只是模型能力上限，而是它进入真实工程系统之后，整个协作面能不能承受它的速度。
GitHub 这篇文章最值得抄作业的地方，不是某个神 prompt，而是它传达出的那种工程态度：
别只想着让 Agent 更能干，也要先把你的仓库收拾到配得上一个很能干的 Agent。
这话不性感，但很真。