PR 不只是代码差异页了：冲突解决、收件箱和 Agent 会话正在重写协作方式

软件工程

发布日期: 2026-03-29

导语：
截至 2026 年 3 月 29 日，软件工程流程里最值得团队认真适配的一组变化，都集中在 GitHub 3 月 25 日和 3 月 26 日这两天。先是 github.com/pulls 的新收件箱和 saved views 进入 public preview，随后 @copilot 可以直接处理 PR merge conflicts，agent session 又开始显示在 Issues 和 Projects 里。再配上 3 月 25 日刚补上的 used_copilot_coding_agent 指标，一个明显趋势已经出现：软件协作正在从“人手动盯列表”变成“队列、上下文和执行状态都尽量留在同一个平面里”。

1. PR 之所以让人累，很多时候不是因为改动大

团队做久了都会发现，PR 累人的地方经常不是理解代码，而是找优先级、找上下文、找谁在处理、找哪个冲突该先解。以前这些信息分散在通知、Projects、Issues、群消息、草稿 note 里。现在 GitHub 的几条更新，明显是在把它们往同一块看板上收。

这类变化最容易被低估，因为它们看上去只是“更方便”。但软件工程效率往往就是被这些切换成本拖垮的。

2. 这组更新连起来后，协作方式发生了什么变化

先看 PR dashboard。
它不是简单把老搜索页美化一下，而是给了 inbox、saved views 和更强的过滤语法。对多人协作来说，这意味着 PR 队列终于能按角色、状态、仓库、更新时间被明确整理，而不是每个人靠浏览器书签和搜索语句凑合。

再看 merge conflict 处理。
@copilot Merge in main and resolve the conflicts 让低风险冲突开始有了自动执行入口。它的意义不在于“省一次手动 rebase”，而在于把冲突从纯人工耗时工，变成可验证、可审阅的执行任务。

最后看 agent activity。
当 issue 和 project 里都能直接看到 agent session 的 queued、working、waiting for review、completed 状态，项目经理、tech lead 和 reviewer 终于能在同一张看板上看见工作推进，而不是靠口头同步。

3. 一套更适合现在的协作流程

第一步，给 PR 队列建 saved views。
最少应该有四类：等我评审、需要我修复、可合并、高风险改动。别让所有 PR 挤在一个默认列表里。

第二步，把 merge conflict 分级。
可机械处理的冲突可以交给 @copilot；涉及 schema、迁移脚本、锁文件大范围漂移的，仍然由人负责。

第三步，让 issue 和 project 成为 agent 编排面。
如果团队已经在 issue 里指派 agent，就不要再平行维护一套微信群状态同步。让看板成为唯一事实来源。

第四步，把 agent 行为接进指标。
用 used_copilot_coding_agent 和实际 PR 采用率一起看，区分“大家试过”与“真的形成流程”。

第五步，保留 review 纪律。
自动解决冲突并不等于可以自动合并。只要改动进入主干，review 责任仍然要落在人身上。

4. 这套玩法里最容易出问题的地方

最常见的问题，是团队一看到自动解冲突就想放大使用范围。实际上这类能力越方便，越要先收范围。
另一个问题，是开了 dashboard 却不重写工作协议。没有 saved views 规则、没有状态定义，工具只是新的界面，不会自动带来秩序。

工具给了你更好的平面，流程还得自己补。

5. 建议本周就执行的动作

为评审人统一一套 PR inbox saved views。
规定哪些冲突允许 @copilot 先处理。
在 Issues/Projects 中打开 agent session 显示。
每周统计一次 agent 参与的 PR 数量和通过率。
将“waiting for review” 状态纳入团队 SLA。

6. 结语

软件工程真正的协作成本，往往藏在那些看起来很小的断点里：冲突谁来解、列表怎么排、状态去哪看。3 月底这波更新把这些断点往一块地方收拢了。对团队来说，机会不在于“又多了几个 AI 功能”，而在于终于可以把 PR、Issue、Project 和 agent 行为连成一条更顺的工作线。谁先顺着这条线改流程，谁就会先看到协作摩擦下降。