Agentic engineering 不只是生成代码：计划、评审与问题调查各自的工程约束

把 agentic engineering 等同于“让 agent 写代码”，通常会在三个地方卡住：动手前的计划、动手后的评审、上线后的问题调查。这三步的产出不是可编译的代码，而是决策和证据，所以约束也不一样——计划约束“做什么、不做什么”，评审约束“改动能不能被解释”，问题调查约束“结论有没有证据链”。代码生成变快，并不会自动让这三件事变快。

先划材料边界#

本文依据的是 GitHub Blog 于 2026 年 11 月 6 日发布的文章《Beyond code generation: A developer’s guide to agentic engineering》的标题与摘要（来源链接）。摘要说明该文讨论用 GitHub Copilot 做计划、写代码、评审改动和调查生产问题，并讨论哪些工作仍需要开发者判断；摘要同时指出“写代码变快了，围绕它的工作没有”。

本次材料未提供该文正文，因此 Copilot 在上述环节的具体能力、入口、限制与版本差异均待核实，本文不作描述。下文的约束是从工程角度提出的建议与推断，不是该文的结论，也不是实测结果。

计划环节：约束是范围与验收#

计划阶段最容易失效的地方，是把一个模糊目标直接交给 agent。建议在交出去之前先补齐三项：

• 范围：明确列出本次要改的模块，也列出明确不动的部分，避免“顺手重构”。
• 验收：先写下怎样算完成、用什么检查（测试、构建、手工验证），再开始生成。
• 回退：约定失败时的退路，例如分多次提交、保留可回滚的边界。

这些字段的作用不是限制 agent，而是让计划本身可被评审——一份无法判断对错的计划，后面所有环节都会失去基准。

评审环节：约束是差异可解释#

评审面对的是 diff，而不是生成过程。可行的约束是：每个改动块都应能对应到计划中的某一条；对应不上的改动，先退回而不是先合并。这条规则的价值在于把“看起来没问题”换成“能说清为什么改”。责任归属仍在人身上：谁批准，谁承担合并后的结果，这一点不能因为生成速度快而转移。

问题调查：约束是只读优先与证据链#

生产问题调查与写代码的目标相反：先取证，后修改。建议的顺序是只读收集（日志、指标、最近的变更记录）→ 形成假设 → 用可复现步骤验证 → 才讨论修复。让 agent 直接进入修复，容易把“症状消失”误当成“原因找到”。是否允许它在生产环境执行操作，属于组织策略问题，本次材料未涉及，需按各自环境单独确认。

一份可复用的计划卡模板#

下面只是字段占位模板，未执行，也不依赖任何具体工具：

目标：一句话说明要达成的结果
范围：允许改动的路径 / 明确不动的路径
验收：需要通过的检查项
回退：失败时如何撤回
未知项：需要人工确认的问题（逐条列出）

哪些判断仍留在人手里#

摘要提到该文讨论了“哪些工作仍需要你的判断”。就可以确定的部分而言，至少三类判断不宜外包：计划中的目标取舍（做哪个需求）、评审中的责任归属（谁批准合并）、事故处置中的优先级（先止血还是先定位）。这三项都缺少可自动验证的对错标准，而这正是工程约束需要写清楚的地方——不是因为 agent 做不到，而是因为做错了没人能替你负责。