GitHub 的 issue 和 PR 正成为人与 AI 代理协作的主要界面

思考GitHub的PR和issue如何正在成为人类与agent协作的主要界面。

我注意到，GitHub——或者更准确地说，GitHub的核心构建模块——正越来越多地被当作人类与agent之间工作管理的自然选择。具体来说，就是issue和pull request。一个贴近我和同事们的例子是，我的朋友兼上司Tom Jung如何以我们教程系统仓库中issue的形式，来管理交给agent执行的任务的识别、划分和规格说明。

另一个例子是，这些工作随后以pull request（PR）的形式被管理，我想这是第一个观察的自然结果。顺带一提，这让我想到，这也改变了issue机制——它不再只是问题陈述，而成为工作项的载体。这或许是件好事。

总之，正是在PR这个话题上，我看到了两位我仰慕已久的人写的博客文章。

在《Hide your slop PR descriptions behind <details><summary>》中，Simon Willison使用HTML的details披露元素，来避免人们产生“我才不要读这么多”的TL;DR反应——那些由agent撰写的超详细描述虽然并非不正确，但对于人类做概览而言过于深入了。

在《“Doctor, it hurts when agents create unreviewable PRs.” “Don’t do that.”》中，Jon Udell描述了agent提交包含数千行代码、几乎不可能被正确理解的PR这一问题。他坚持认为（我也同意），PR应当是人与agent之间的共享上下文，而且——尽管有人会说用agent来审查这种庞然大物是解决办法之一——更小的工作分块才是答案。

两种做法都让PR得以继续作为跟踪和审查的工作单元，同时为人类留出空间，使其仍然是决策过程中的积极裁决者。用传统的话说，PR可以主要是一封信，而不是一本账。

与许多人一样，Simon和Jon都在用现有的工具和机制探索前路，提出一些务实变通的方案，而这些方案最终会成为规范。这正是在线社区几十年来一直在做的事。