Agentic engineering 的边界：规划、评审、排查怎么落到工程流程里

先把结论说清楚：agentic engineering 的工程边界不在“能不能生成代码”，而在生成之外的三段工作——规划、评审、排查——每一段都要回答同一个问题：这一步由谁做决定，拿什么证据，在哪里停下。代码生成变快，不会自动让这三段变快；如果流程没改，多出来的产出会直接变成评审和排查的负担。

本次材料能确认到什么程度#

可核验的来源只有一篇 GitHub 博客的标题与摘要：Beyond code generation: A developer’s guide to agentic engineering（来源日期 2026-11-06）。摘要的说法是：写代码变快了，但围绕它的工作没有；文章覆盖用 GitHub Copilot 做规划、写代码、评审变更和排查生产问题，并讨论哪些工作仍然需要人的判断。

需要划清的限制：本文没有读到该文全文，也没有核验其中提到的具体功能、版本、计费或可用范围。下文的分段方法和任务卡格式是工程建议与演示，不是对原文内容的复述；涉及具体产品能力时请以官方文档为准，本文标注为待核实。

规划：产出必须是一份可以被驳回的计划#

让 agent 直接改代码，最常见的问题不是改错，而是改对了你没让它改的地方。规划段的作用就是把这件事提前拦住。一份可用的计划至少包含四项：

• 假设：这次改动依赖哪些尚未确认的前提，例如“空购物车由 items.length === 0 判定”。假设写不出来，说明问题还没收敛。
• 范围：允许改哪些目录，禁止碰哪些目录（迁移脚本、基础设施配置通常应排除）。
• 验收条件：可判定的完成标准，而不是“功能正常”。
• 回滚方式：单 commit 可回退，还是涉及数据结构变更需要额外步骤。

这四项的意义在于：计划本身成为评审对象。人不需要读完全部生成代码才发现方向错了，只要在计划阶段说“这个假设不成立”或“迁移目录不许动”。

演示：任务卡格式（未执行示例）

下面的格式仅用于说明字段结构，未在任何工具或仓库中运行，路径与判定条件均为占位。

# 演示用任务卡，未执行
task: 修复 /orders 接口在空购物车时返回 500
scope:
  allow: ["src/orders/**", "tests/orders/**"]
  deny:  ["migrations/**", "infra/**"]
assumptions:
  - 空购物车由 cart.items.length == 0 判定
acceptance:
  - 新增用例覆盖空购物车：状态码 200，body.items 为空数组
  - 现有订单相关测试全部通过
evidence_required:
  - 测试命令、退出码与失败项清单
  - 变更文件清单与每处改动的理由
rollback: 单 commit 可 revert，不涉及 schema 变更

评审：先看变更面，再看写法#

生成速度提高后，评审最容易失效的方式是“逐行读完”。人的注意力应该优先花在变更面上。下表是建议的检查顺序，属于工程建议而非来源结论。

第 3 条值得单独强调：评审时需要区分“测试已运行”和“测试被生成”。前者有命令、环境、退出码；后者只是文本。没有可核验记录时，只能按未验证处理。

排查：默认只读，假设成列，设停止条件#

生产问题排查是 agent 介入风险最高的一段，因为它天然要求“动手”。可行的做法是把权限和顺序分开：

1. 只读优先：先查日志、指标、近期变更记录，不改任何东西。
2. 假设成列：把可能原因写成列表，每条附一个能证伪它的观察点，而不是直接给结论。
3. 停止条件：明确“查到什么程度就交回给人”，例如涉及数据修复、权限变更、对外公告时立即停止。
4. 留痕：把查过的命令与输出摘要记录下来，避免同一轮排查被重复执行。

这样做的代价是慢一点，收益是结论可复核：每条判断都能追到一次具体观察，而不是一段读起来很顺的解释。

落地顺序与不该用的场景#

如果要从现有流程迁移，建议顺序是：先加任务卡模板，再加评审检查表，最后才放开排查类权限。反过来做，等于在证据链最弱的地方先放大产出。

以下场景建议不交给 agent 自主执行：涉及生产数据写入或删除、涉及密钥与权限变更、缺乏可回滚路径的变更、以及验收条件本身还说不清楚的任务。最后一条常被忽略——验收条件写不出来，说明这件事还没到可以委派的阶段。

回到标题的问题：边界不在代码生成，而在人愿意为哪一步签字。规划段签的是方向，评审段签的是证据，排查段签的是结论。生成速度再快，这三处签字的位置不会移动。