写码这件事已经被 AI 加速得很彻底了，但围绕写码的其它工作没有同步变快。GitHub 官方在一篇讲 Agentic 工程的文章里给了一组数字：2026 年 10 月单周收到的 commit 超过 12 亿次，比一年前涨了 400% 以上；而 Faros AI 的研究显示，团队从低 AI 采用率转向高采用率后，pull request 在评审环节的耗时延长了 441%。
也就是说，代码生成得越多，评审、规划、排障这些环节的压力越大。文章把这个问题拆成 Plan、Build、Verify、Observe 四个阶段，每一段都给出了 Copilot 能接手什么、人该留在哪里。下面按这个结构走一遍。
规划与评审的顺序
先下判断：Agentic 工程的价值不在让 AI 多写几行代码，而在把写码之外、最耗时的那部分也交给 agent，同时把"人审"卡在真正要决策的节点上。规划阶段尤其如此——需求分散在 Slack、旧 PR、设计文档里，人花在检索上的时间比决策还多。
Copilot 在规划阶段做的事是把上下文接起来。它能在 Slack 或 Teams 里和 PM、设计师一起核对假设、细化需求；把共识转成带验收标准的 GitHub Issues；用 Agentic Workflows 自动打标签、估复杂度，把低复杂度任务直接派给 Copilot。Plan Mode 让它在界面里比较几个方案、细化计划，再交给人批准。
关键动作是把"需求"变成"可执行、可验收"的 Issue。这一步做对了，后面评审才有据可依。下面这条命令就是把一个模糊需求落成 Issue 的方式：
gh issue create --title "为订单服务增加幂等键，避免重复下单" --body "$(cat <<'EOF'
## 背景
用户在超时重试时会产生重复订单。
## 验收标准
- [ ] POST /orders 接收 Idempotency-Key 请求头
- [ ] 同一 key 的重复请求只落库一次
- [ ] 未带 key 的请求按现有逻辑处理，不报错
## 范围
仅订单服务，不改支付回调。
EOF
)"
验收标准写在 Issue 里，是后面 Copilot code review 和 Agent Merge 判断"能不能合"的依据。没有验收标准的 Issue，交给 agent 就是让它自由发挥。
仓库指令
Build 阶段要解决的是"agent 跑起来之后，怎么让它遵守团队的约定"。文章给的一类工具叫 Repository instructions，就是一个落在仓库里的指令文件，记录团队约定和验证命令。它的作用是让 agent 每次开任务先读约定，而不是靠人反复在提示词里重复。
# 仓库约定
- 提交信息遵循 Conventional Commits，前缀用 feat/fix/refactor。
- 改 src/ 下的代码必须同步补 tests/ 下的用例。
- 验证命令：`npm test && npm run lint`，两个都要绿才能提交。
- 不要在 PR 里改 package-lock.json，除非确有依赖变更。
这份文件的价值在于"可沉淀"。人不用在每轮对话里重讲一遍"先跑测试再提交"，约定写进仓库，agent 每次自己读。文章还提到 Copilot memory 和 Copilot Dreaming：前者跨仓库复用有用的事实，后者定期审会话和 PR 反馈、更新记忆并主动提指令或技能改进。
Build 阶段的另一个重点是隔离和连续性。Session continuity 让你跨设备接着上一个会话；Cloud sandboxes 让任务在云端沙箱跑、不占本地机器；每个会话有隔离的仓库副本，不共享没写完的工作树。Copilot Fusion 按任务选模型和推理深度，企业托管设置把公司策略带到所有 Copilot 界面。
评审卡在哪
Verify 阶段是整篇文章最尖锐的部分。一个标注"small refactor"的 PR 改了 47 个文件，核心验证逻辑被淹没在大量改动里，评审的人要么硬着头皮读、要么放行。这正是 441% 延时的来源。
对策不是让 AI 更快地"看"，而是把评审拆小、把常规检查前置。Stacked pull requests 把有依赖的工作拆成更小、更聚焦的 PR，每个独立评审，下游能基于未合并的 PR 继续往下建；GitHub Code Quality 在人工评审前就按组织标准拦常规问题；Copilot code review 对简单变更做轻量分析、复杂变更做深度分析。
# 拆小 PR：一个改动一个分支，一次提交一件事
gh pr create --title "feat: 订单幂等键" --body "见 #123 的验收标准" --draft
# 检查通过后自动合并，合并后删除分支
gh pr merge --auto --squash --delete-branch
安全侧还有一层：AI Scan 在 CodeQL 覆盖不到的语言和文件里找漏洞，AI secret detection 识别模式匹配漏掉的非结构化密钥，License compliance 在合并前查依赖许可，package firewall 当前对 npm 处于 public preview、能拦下违反安全策略的包。Agentic Autofix 对安全问题直接给修复建议，Agent Merge 自动处理失败的检查、评审意见和合并冲突，配好之后能在验证步骤通过后自动合并。
排障与回归
Observe 阶段处理上线后的问题：间歇性超时、大客户受影响，要比对日志、发布历史、客户报告，再决定回不回归。Copilot 通过 Connectors（比如 Fabric）接进可观测性工具和业务数据，帮你圈出哪些请求、哪些客户群体受影响；再让它起草 Issue，带上支持证据、验收标准，以及针对这次故障的回归测试。
这里有一条容易被忽略：排障的产出不该只是"修好了"，而是一条带回归测试的 Issue。故障每发生一次，就该沉淀一条能自动验证的防线，否则同一个坑会再踩一遍。Copilot Dreaming 也在这一环起作用，它利用会话和仓库活动反过来优化记忆、技能和 code review 的指导。
什么团队适合先上
这套东西不是让团队一次性全换掉。文章给的起步建议很实在：从本周最让你头疼的一件事开始，把一个 agent 派上去，再逐步扩到流程其它部分。
判断标准有三条。一是团队已经用 Copilot 写码、想往评审和排障延伸的，收益最直接，因为瓶颈本来就在那。二是能把验收标准写清楚的团队——agent 依赖明确的标准工作，标准含糊的团队用起来会失望。三是愿意维护仓库指令和记忆的团队，这类"沉淀"性投入要持续才有回报。
反过来，纯靠口头约定、没有 issue 和 PR 流程的团队，先别急着上 agent 评审，先把 Issue 和验收标准这套地基打好。工具再好，也补不上流程缺的课。
最后提醒一句：文章里提到的 Agentic Workflows、Agent Merge 这些能力在持续迭代，具体配置和可用范围要以 GitHub 官方文档为准，本文只讲方法论和分工，不贴具体配置格式。