agent 写代码之外：计划、评审与问题定位如何被代理化

GitHub 在 2026 年 11 月 6 日发布的一篇开发者指南给出了一个直白的判断：写代码变快了，但围绕代码的工作没有变快。该文把 agentic engineering 拆成四段——计划、写代码、评审变更、排查生产问题——并说明哪些工作仍需人的判断（Beyond code generation: A developer’s guide to agentic engineering，以下为对标题与摘要的转述）。

先说明材料边界：本次只取得该文的标题与摘要，未读全文。因此下文不是对原文功能的复述，而是按这个框架做的工程分析；GitHub Copilot 在这些环节的具体能力、可用范围与限制，待核实。

计划：代理化的是「把意图写成可核对的东西」#

计划环节的价值不在于产出一段更长的自然语言方案，而在于产出一组能被逐条打勾或打叉的条目。判断一个计划是否可用，可以看它有没有写清四件事：改动落在哪些文件或模块；哪些部分明确不动；用什么方式验收；出问题时怎么回滚。agent 起草这些条目的速度很快，但条目本身是否成立，仍要人确认。

条件也很明确：当任务边界能写成断言（输入范围、输出格式、必须保持的不变量），agent 起草计划的质量较高；当需求本身还在摇摆，它倾向于把不确定性写成语气自信的步骤，看起来完整，实际不可执行。所以计划应当是给人过的检查点，而不是直接喂回给 agent 的执行指令。

评审：扩覆盖面容易，定标准难#

评审是三者中最容易被代理化、也最容易失控的一环。agent 擅长机械一致性检查：命名是否符合仓库约定、错误分支是否被吞掉、新增逻辑有没有对应测试、边界条件是否被忽略。它不擅长判断一个改动该不该存在——那属于目标与取舍问题。

实际落地时有两个约束值得先定下来。其一是分级：把评审输出分成阻断、建议、仅记录三档，并写清每档的处理人和时限，否则大量低价值评论会稀释真正需要拦下的问题。其二是可追溯：每条意见要指到具体位置、给出理由，并区分「违反仓库已写下的规则」与「评审者的个人偏好」。合并权不因为引入 agent 而转移。

问题定位：串联证据可以代理，选择假设不行#

生产问题的排查通常按「现象 → 时间窗 → 相关变更 → 假设 → 验证」推进。agent 能加速的是中间的证据收集与串联：把日志片段、最近部署记录和相关代码路径放在一起，列出若干可能原因。它不能替代的是决定先验证哪一个——这取决于当前影响面、可用的回滚手段和业务时段。

建议对定位类 agent 设两条边界：只读权限与明确的查询范围，避免它在排查过程中改动线上状态；要求输出「假设 + 验证方法」而不是直接给结论。最常见的失败模式是把相关性当因果，尤其在只有一小段日志时，看起来最像原因的那条线索往往只是时间上相邻。

三环的分工怎么划#

这张表是分析框架，不是 GitHub 原文的分类。真正需要守住的判断大致有四类：目标是否值得做、风险能接受到什么程度、规则由谁解释、对外承诺怎么给。这四件事都无法从代码里读出来，也就无法被代理化。

如果要把这套框架用进团队流程，建议先从一个环节、一类任务开始，记录 agent 输出被采纳和被推翻的比例，再决定是否扩大范围。至于该文提到的具体做法与 Copilot 的功能细节，需回到原文核对，本文不作推断。