作者：Lei阅读 --

会用 Coding Agent，不等于会做 AI Engineering：四项差距能力与训练法

用一个订单 CSV 导出案例，具体定义需求规格、Agent 操作、Eval 回归与部署观测四项能力，并结合 SWE-bench、SWE-agent、MAST、AgentOps 等论文给出可练习、可验收的进阶路径。

AIAgent 工程评测工程实践系统设计

会用 coding agent 不等于会做 AI engineering；真正的差距在可验证规格、错误分析、系统边界和部署治理。高技能开发者会被放大，低质量 vibe coding 的维护成本也会同步放大。

这句话最容易被误读成：“别 vibe coding，要多写文档、多做测试。”这没有错，但几乎没法指导下一次工作。真正值得追问的是：差距究竟由哪些能力构成？每项能力做到什么程度才算合格？又要怎么练？

先给出本文的定义：

Coding agent 的能力是把指令变成代码；AI engineering 的能力，是把不确定的生成过程变成可验证、可控制、可维护的系统变化。

前者关注“它能不能写出来”，后者还要回答四个问题：我们要的到底是什么？执行过程有没有跑偏？这次成功能不能稳定复现？上线出错时能不能发现、止损和恢复？

这篇是《在 AI 时代胜人一筹：杠杆不在模型多强，而在你和模型之间那道界面》的实践篇。上一篇解释为什么流程决定人机杠杆；这一篇只做一件事：把“好流程”拆成四项可以刻意练习的硬功。

先看全局：四项能力其实是一条闭环

AI engineering 位于一个更大的软件交付系统中。你需要追踪四个模块，以及每个模块改变后会发生什么：

flowchart LR
    A["需求规格<br/>把意图变成契约"] --> B["Agent 操作<br/>把契约变成受控行动"]
    B --> C["Eval 回归<br/>把失败变成长期资产"]
    C --> D["部署观测<br/>把风险限制在边界内"]
    D --> E["真实反馈与事故"]
    E --> A
    E --> C
  • 规格更清楚，Agent 搜索错误方向的成本会下降，Eval 也更容易自动化；
  • 操作边界更小，失败更容易定位，错误的爆炸半径也更小；
  • Eval 更贴近真实风险，升级模型、提示词和工具时才敢快速迭代；
  • 部署更可观察、可回滚，生产失败才能回流为新规格和新回归用例。

任何一环缺失，速度都会变成债：没有规格，生成越快，歧义实现得越快；没有回归，修得越多，旧错复发得越频繁；没有边界和观测，上线越快，事故发生后越难解释。

名词速查

术语一句话解释
可验证规格不只描述“想要什么”，还写清什么证据足以判定完成或失败
harness包在模型外面的运行框架，负责给上下文、开放工具、保存状态和执行检查
Eval用一组任务和判定规则，测系统是否做成了我们真正关心的事
回归曾经做对的行为在修改后又坏了，或曾经修掉的错误再次出现
终态验证不听 Agent 自称成功，而是检查数据库、文件、页面等真实世界状态
可观测性能用日志、指标、链路和版本信息解释系统发生了什么
爆炸半径一次错误最多能影响多少用户、数据、权限或下游系统
护栏由代码、权限或审批实现的硬约束，而不是提示词里的一句“请不要”

一个小需求，足以暴露四层差距

假设产品经理提了一个看似简单的需求：

给订单后台加一个“导出 CSV”按钮。

一个会用 coding agent 的人可能把需求原样发出去。Agent 很快加了按钮和接口：查询订单、拼成 CSV、返回下载。开发环境里点一下，文件能打开，于是任务完成。

但生产系统很快提出另一组问题：

  • 导出的是当前页、筛选结果，还是账户下所有订单？
  • 北京时间 8 月 1 日的订单，在 UTC 数据库里从几点算起？
  • 普通客服能不能导出包含手机号的字段？能否读到别的租户数据？
  • 恶意用户把姓名写成 =HYPERLINK(...)，财务用表格软件打开时怎么办？
  • 一百万行订单是占满应用内存，还是进入异步任务？
  • 导出一半失败，用户看见什么？系统留下什么审计记录？
  • 新版本把列顺序改了，下游财务脚本会不会静默读错？

这些问题没有一个靠“代码写得更快”自动解决。它们分别属于规格、操作、评测和部署边界。下面就用这一个需求，把四项差距能力逐层拆开。

能力一：把模糊意图变成可验证契约

具体定义

规格能力不是把需求写得很长，而是提前消灭那些会产生多个合理实现的歧义，并为关键承诺指定可观察的证据。

“支持导出订单”只表达了愿望。“有 finance:export 权限的用户，可以导出当前租户在所选本地日期范围内的订单；超过一万行转异步任务；所有外部输入按 CSV 安全规则转义；旧版列名和顺序保持不变”才开始接近契约。

一份最小可验证规格至少回答六类问题：

规格槽位要回答的问题CSV 导出例子
目标谁为什么需要它？财务人员下载筛选后的订单做月度对账
初始状态与输入在什么状态下，以什么参数开始？当前租户、用户权限、本地日期范围、订单筛选条件
期望终态世界最终要变成什么样？生成一份字段稳定、数据完整的 CSV，或一个可查询的异步任务
不变量无论怎么实现，什么绝不能变？不跨租户；未授权字段不出现；不能执行表格公式；现有 API 不破坏
边界与失败极端输入和依赖失败时怎么办？空结果、跨月、夏令时、大数据量、对象存储失败、重复点击
验收证据用什么自动或人工检查判定完成？权限测试、日期边界测试、CSV 注入用例、十万行压测、审计记录检查

SWE-bench之所以比“给我写一个函数”更接近真实软件工程，就是因为任务不只包含自然语言问题，还包含整个仓库环境，并用测试判断补丁是否真正解决问题。它提醒我们：需求文字不是完整真相，环境状态和验证器也是规格的一部分。

MAST对多 Agent 系统失败的分析又把“规格与系统设计失败”列为三大类之一。模型变强可以减少局部编码错误，却不会替团队决定权限、兼容性和风险容忍度。

高低水平的差别

低水平做法高水平做法
把需求原文直接交给 Agent先找出至少两种都说得通、但结果不同的解释
用“页面看起来对”验收把验收写成输入、状态、输出和不变量
只写正常路径主动覆盖边界、权限、容量和失败恢复
让 Agent 自己补业务决定把未知决定列出，由责任人确认或采用显式默认值
完工后才想测试写代码前先写最关键的失败样例

怎么练

练习一：分歧探针。 每次拿到模糊需求，先让 Agent 给出三种彼此不兼容、但都符合原句的实现。例如“导出订单”可以是当前页、全部筛选结果或全账户数据。把这些分歧逐一变成产品决定。你训练的不是提示词技巧，而是发现隐藏决策的能力。

练习二：五格边界表。 每个功能都补五类例子：正常、边界、未授权、超容量、依赖失败。CSV 场景分别可以是 100 行正常数据、日期末秒、客服越权、100 万行、对象存储超时。

练习三：先写一个失败验收。 开工前只要求自己写出最危险的一条可执行检查，例如“租户 A 的登录态无法导出租户 B 的任何订单”。一条硬测试往往比十段形容词更能约束 Agent。

验收自己的进步： 记录代码评审或上线前新发现的“未决定事项”数量、关键验收条件的自动化比例，以及因为需求理解错误造成的返工次数。真正的进步表现为这些遗漏持续减少，不是规格文档越来越长。

能力二：把 Agent 当成闭环系统操作，而不是聊天框

具体定义

Agent 操作能力，是持续管理上下文、权限、动作粒度、反馈和停止条件，让 Agent 在可恢复的小步里逼近目标。

低质量使用方式是“描述任务，然后等完整答案”。工程化方式更像控制一个会犯错的执行系统：先观察，再计划；只开放必要动作；每做一小步就读取环境反馈；证据不够就不宣布完成。

SWE-agent提出 ACI（Agent-Computer Interface，Agent—计算机界面）：同一个语言模型，面对专门设计的文件查看、编辑和测试接口时，解决真实软件问题的能力会明显变化。结论不只是“工具很重要”，而是：Agent 的有效能力由模型与操作环境共同决定。 你给它看什么、允许它改什么、何时要求验证，都是系统设计。

一个实用的 Agent 操作闭环可以写成六步：

  1. 定框： 写清目标、允许范围、禁区、验收条件和停止条件；
  2. 观察： 先读现有实现、调用关系、测试和约定，不急着修改；
  3. 计划： 把任务拆成可独立验证、可回滚的小步；
  4. 行动： 每次只做当前最小改动，避免把探索、重构和功能混成一团；
  5. 验证： 读取测试、类型检查、差异和真实终态，而不是相信 Agent 的总结；
  6. 记录： 保存假设、失败、版本和待办，让下一轮基于新世界状态继续。

CSV 导出任务的权限可以这样分层：

动作默认权限原因
读取相关代码、测试和 schema自动允许可逆、低风险，是建立上下文所必需的
修改限定目录中的代码自动允许，但必须查看 diff影响可控，能通过版本控制恢复
新增依赖或修改数据库结构先说明影响再执行会扩大供应链或迁移风险
访问真实订单数据默认禁止，使用脱敏样本隐私边界不能靠提示词保证
部署测试环境校验通过后允许需要真实集成反馈，但不触达用户
部署生产、删除数据、扩大权限人工审批高副作用动作必须有独立放行者

下面这份操作卡比“请认真一点”有效得多：

目标：完成订单 CSV 导出，并满足已列出的验收条件。
范围：只修改导出模块、路由和对应测试；不要顺手重构订单系统。
边界：不得读取真实生产数据，不得部署生产，不得新增依赖。
流程：先检查现有权限、筛选与日期处理方式，再给出分步计划。
每步：展示变更意图，执行最小改动，运行最窄相关验证并报告证据。
停止：需求冲突、需要迁移或验证连续失败时停止猜测，报告当前状态。

它不是万能提示词，而是一份运行协议：把决定权、动作权和验证责任放到明确位置。

怎么练

练习一：小步预算。 规定每轮只解决一个可观察行为，或只动一个清晰边界内的模块。完成后必须看 diff 和验证结果，再允许下一轮。练几次后，你会自然识别“任务是不是拆得太大”。

练习二：作者与验证者分离。 第一轮让 Agent 实现；第二轮开启新上下文，只给规格和 diff，让它寻找反例、越权和遗漏。验证者不继承作者的解释，比较容易发现“代码为什么看起来合理但其实不满足目标”。

练习三：人为注入一次故障。 在安全环境中让测试、网络或依赖返回异常，观察 Agent 是继续乱改、无限重试，还是能保留证据并正确停止。长任务能力不只是坚持，也是知道什么时候不该继续。

验收自己的进步： 看无关 diff 比例、首次失败后的有效诊断率、需要人工救火的次数、回滚是否简单，以及 Agent 宣布完成后被验证器打回的比例。聊天轮数少不代表操作得好；可恢复地到达正确终态才算。

能力三：把每次错误变成 Eval 与回归资产

具体定义

错误分析能力，是区分症状、失败步骤和根因；Eval 回归能力，是把已确认的根因压缩成一个以后会自动报警的永久样例。

“导出的文件不对”只是症状。根因可能完全不同：

  • 产品规格没说日期按哪个时区；
  • Agent 没找到项目已有的租户过滤器；
  • 计划中漏了权限检查；
  • CSV 转义实现有逻辑错误；
  • 测试只检查 HTTP 200，验证器本身太弱；
  • 线上数据量和测试数据量不在一个数量级。

如果每次都归因为“模型又幻觉了”，团队永远只能换模型、改提示词、重新祈祷。更可用的错误账本至少分七类：规格歧义、上下文缺失、规划越界、实现错误、工具或环境错误、验证器缺陷、生产分布变化。一个故障可以有多个标签，但必须选出最接近可修复控制点的根因。

《Bugs in Large Language Models Generated Code》分析了 333 个 LLM 生成代码中的 bug，归纳出误解需求、遗漏边界、错误输入类型、虚构对象和生成不完整等十类模式。论文的实用价值不在于背下十个名字，而是证明：错误不是均匀随机的；一旦分类，就能设计针对性的检查。

一套面向 Agent 工程的回归集，不应该只有单元测试：

层级检查什么CSV 导出例子
静态与局部类型、格式、纯函数行为CSV 转义、时区转换、列映射
集成契约模块与真实依赖如何协作数据库筛选、权限中间件、对象存储失败
任务终态用户要的世界状态是否出现文件内容正确；异步任务状态完整；无跨租户记录
安全与非功能哪些坏事绝不能发生公式注入、越权字段、内存峰值、超时、重复任务
稳定性同一条件下是否反复可靠多次运行、不同模型或提示版本、不同数据切片

τ-bench采用的关键方法，是在对话结束后比较数据库终态和目标状态，并用 pass^k 检查多次运行的可靠性。它传达了两个朴素原则：Agent 说“已完成”不算完成；偶然成功一次也不等于可依赖。

Meta 的 TestGen-LLM也没有直接接收模型生成的测试，而是让候选测试通过构建、稳定运行和覆盖提升等过滤器。生成可以是概率性的，进入回归库的资产必须经过确定性的质量门。

一条失败怎样进入回归库

假设线上发现：8 月 31 日 23:30 的订单没有出现在“8 月”导出中。

  1. 保存证据： 请求参数、用户时区、数据记录时间、代码与配置版本；
  2. 最小复现： 只保留一条跨 UTC 日期边界的订单；
  3. 确定根因： API 把本地日期直接当 UTC 日期查询，而不是数据库偶发失败；
  4. 选择修复层： 补充日期语义规格，在服务边界完成时区转换；
  5. 固化验证： 新增跨月、跨年和夏令时地区用例；
  6. 扩大同类搜索： 检查报表、账单和搜索接口是否复制了同一错误模式。

这六步比“把失败日志丢给 Agent，让它修好”多花十分钟，却会留下可以复利的资产。

怎么练

练习一：建立错误账本。 每次 Agent 被打回时记录：症状、最小复现、根因分类、在哪一层修复、增加了哪条回归、是否曾经发生过。连续记录二十次，你会看见自己的高频弱点。

练习二：一错一永久样例。 只要一个错误值得花时间修，就要求它留下自动化测试或明确的监控规则。没有留下资产的修复，下次仍然要付全价。

练习三：测试验证器本身。 故意把租户过滤删除、把日期比较符号改错、把安全转义关闭，看现有测试能否变红。这叫变异测试：不是问代码能否通过测试，而是问错误代码能否被测试抓住。

验收自己的进步： 观察生产逃逸缺陷、同类错误复发率、失败可复现率、回归集不稳定比例，以及高风险清单中有自动检查的占比。覆盖率可以参考，但“风险是否被抓住”比行覆盖率更接近目标。

能力四：画清系统边界，并让上线可观察、可止损

具体定义

系统边界能力，是明确 Agent 能看见什么、能调用什么、能改变什么、最多影响什么；部署治理能力，是让每次变化都有身份、证据、放量路径、停止开关和恢复方案。

代码通过测试只是“候选版本成立”。生产环境还有真实权限、脏数据、并发、第三方依赖和旧消费者。AI 生成更多代码后，这些传统工程问题没有消失，反而更容易因改动频率增加而累积。

《Hidden Technical Debt in Machine Learning Systems》早在 2015 年就指出，机器学习系统的成本常隐藏在胶水代码、纠缠依赖、反馈循环、未声明消费者和外部世界变化中。它虽然写于 coding agent 之前，但今天更适用：生成局部实现很便宜，不等于修改整个系统很便宜。

CSV 导出的安全边界可以这样落地：

  • 租户 ID 由服务端登录态注入，Agent 生成的查询参数不能覆盖；
  • 字段权限由固定策略判断，不让模型临场决定哪些个人信息可导出；
  • 大导出只能进入有并发上限的队列，不能占满 Web 进程；
  • 下载链接短期有效且绑定身份，访问写入审计日志；
  • 功能先由开关控制，只向内部财务和小流量租户开放；
  • 错误率、队列延迟、导出行数、内存峰值和权限拒绝率有独立指标；
  • 代码、数据库迁移、配置和任务格式都有兼容与回滚方案。

“提示词里写了不能跨租户”不算边界。真正的边界必须在模型无法绕过的位置：数据库访问层、权限系统、沙箱、网络策略、配额、审批或不可变审计中。

《Concrete Problems in AI Safety》把避免副作用、奖励投机、安全探索和分布变化列为实际安全问题。翻译到 coding agent：不要只奖励“测试变绿”，否则 Agent 可能删除测试或绕开检查；不要在生产环境探索未知操作；不要假设测试数据与线上分布相同。

最小部署治理表

阶段必须留下的东西CSV 导出例子
上线前版本、风险清单、Eval 结果、负责人、回滚步骤记录代码 SHA、测试集版本、容量结果、开关位置
放量中小流量范围、业务与技术指标、停止阈值先内部账号；错误率或内存超阈值自动关停
运行时Trace、权限主体、输入摘要、工具与配置版本、外部副作用谁在何时导出了什么范围、生成了哪个文件
降级与恢复kill switch、幂等、补偿、旧版本兼容停止新任务；已生成文件仍按旧协议可读
事故后时间线、根因、影响范围、永久改进新增数据切片、监控告警和回归用例

AgentOps提出的核心观点，是一次 Agent 运行需要追踪目标、计划、任务、工具、评估和护栏等全生命周期工件，而不只是模型输入输出。ML Test Score则把生产就绪拆成数据、模型、基础设施和监控等 28 项具体检查。两者共同指向一个事实：可观测性不是多存日志，而是保留足够证据，让人能解释、比较和恢复一次运行。

怎么练

练习一：每个外部动作画五条边界。 写下调用主体、可读数据、可写资源、最大配额、失败后的补偿。支付、邮件、部署、删除和数据导出尤其要做。

练习二：上线前做一次反向推演。 假设功能已经制造了最糟事故，倒推它如何穿过权限、测试、审批和监控。每穿过一层，就补一个硬控制或报警证据。

练习三：亲手演练关闭和回滚。 在测试环境触发阈值、关闭开关、回退版本并确认旧任务仍可处理。写在文档里但从未演练的回滚，不算真正存在。

验收自己的进步： 看高风险动作的硬权限覆盖率、关键 Trace 字段完整率、异常发现时间、停止放量时间、回滚恢复时间，以及事故是否能关联到具体模型、提示、工具、代码和配置版本。

四项能力如何彼此放大

这四项不是四门平行课程，而是同一条质量链：

如果缺少直接后果长期后果
可验证规格Agent 不知道“正确”是什么团队不断为需求歧义返工
闭环操作一次改动过大，跑偏后难恢复Diff 越来越难审，人工逐渐失去控制感
Eval 与错误分析成功靠演示，失败靠重试换模型、提示或依赖时不敢升级
系统边界与部署治理测试通过也可能造成真实副作用事故不可解释、不可止损、不可复盘

这也解释了为什么高技能开发者会被 Agent 放大。他们原本就会澄清需求、识别边界、设计测试、控制变更、观察生产；Agent 只是把这些判断更快地变成实现。低质量 vibe coding 同样会被放大：模糊决定被批量写进代码，局部补丁绕过系统约束，没有人知道哪些行为只是在某次演示里碰巧成功。

真正会复利的产物不是代码行数，而是四类资产：更清楚的契约、更可靠的操作协议、更锋利的回归集、更完整的生产证据。 代码可能重写，这些资产会让下一次变化更便宜。

一套四周训练计划

不必先搭一整套 Agent 平台。选一个有真实用户、但爆炸半径可控的小功能，每周练一个模块即可。

第一周：需求规格

  • 从待办列表挑 5 个模糊需求，每个写出 3 种合理解释；
  • 为其中 1 个需求补齐目标、初始状态、终态、不变量、边界和证据；
  • 在写实现前创建 5 条验收样例，至少包含权限、容量和失败路径；
  • 周末复盘：评审阶段又冒出了哪些未决定事项？为什么一开始没看见？

过关信号： 另一个人只看规格与验收样例，就能判断一个候选实现是否合格。

第二周：Agent 操作

  • 给同一任务设置明确的文件范围、工具权限和停止条件；
  • 要求 Agent 先观察和计划，每次只执行一个可验证小步；
  • 分离作者与验证者上下文；
  • 人为制造一次测试失败或依赖超时，检查它能否正确停下并报告证据。

过关信号： 任意一步失败都能回到最近的稳定状态，不需要推翻整次改动。

第三周：Eval 与错误分析

  • 建一个至少 20 条样例的小型回归集，覆盖正常、边界、权限、容量和依赖失败；
  • 对每次失败记录症状、根因分类、修复层与新增回归；
  • 手工注入 5 个错误，检查回归集是否能抓住；
  • 对有随机性的 Agent 任务重复运行，记录不稳定样例，而不是只保存最好结果。

过关信号： 每个重要失败都能稳定复现，并且修复后会留下永久报警器。

第四周：部署观测

  • 为功能加开关、小流量放量和一键停止路径；
  • 记录主体、版本、关键输入、动作、结果和外部副作用；
  • 写出三个停止阈值和明确负责人；
  • 在测试环境完成一次“异常 → 告警 → 关停 → 回滚 → 验证恢复”演练。

过关信号： 不问原作者，值班同事也能从证据判断发生了什么，并在限定时间内止损。

四周结束后，再把同类任务交给 Agent。你追求的变化不是“提示词写得更华丽”，而是：需求来回更少、无关改动更少、错误更早暴露、上线更敢放量、事故更快恢复。

一张真正有用的自检表

下次准备把任务交给 coding agent 时，先问自己：

  1. 是否存在两个都符合文字描述、但业务结果不同的实现？
  2. 成功是否能由环境状态或自动检查证明，而不是靠 Agent 自述？
  3. 权限、隐私、容量、兼容性和失败恢复是否有明确决定？
  4. Agent 能读、能写、能调用、不能触碰的边界是否清楚？
  5. 修改是否被拆到每一步都可验证、可恢复？
  6. 失败时能否区分规格、上下文、规划、实现、工具和验证器问题？
  7. 这次修复是否留下了一个永久回归样例？
  8. 测试是否真的能抓住错误实现，而不只是覆盖代码行？
  9. 上线是否有小流量、停止阈值、开关和回滚路径？
  10. 出事后能否还原当时的代码、模型、提示、工具、配置和数据范围？

如果前两题都答不上来，先别让 Agent 写代码；你还没有定义任务。如果后四题答不上来，可以做原型，但还不具备生产发布条件。

最后的灰度：不是每个任务都要上重治理

个人一次性脚本、可丢弃原型和生产支付系统，不应该使用同一套仪式。工程成熟度不是文档数量，而是控制强度与风险相匹配：

  • 可随时删除的本地实验，保留目标和一个结果检查就够；
  • 团队长期维护的功能，需要规格、测试、版本和错误账本；
  • 涉及资金、隐私、权限或不可逆副作用的系统，才需要审批、隔离、放量、审计和演练。

同样也不要把某一篇论文的结果当永恒定律。METR 在 2025 年的随机对照实验中发现，16 位熟悉成熟项目的开发者使用当时的 AI 工具后，完成任务反而慢了 19%；但 METR 在 2026 年的后续说明也明确表示，新一轮数据受到参与者选择偏差和并行 Agent 计时困难影响，无法可靠估计最新工具的提速幅度。正确结论不是“AI 一定拖慢人”，而是：主观感觉不能替代测量，而且结果强烈依赖任务、工具、工程环境和使用能力。

本文对“四项差距能力”的划分，是我结合论文与生产工程做出的实践性综合，不是某篇论文已经验证过的统一能力模型。它真正的检验也不在文字里，而在你的下一次任务中：能不能更早发现歧义，更小步地控制 Agent，把一次错误变成永久资产，并让一次上线始终处在可观察、可停止、可恢复的边界内。

会用 Agent 的人能更快地产生候选答案；会做 AI engineering 的人，能持续生产值得信任的结果。

参考来源

Agent 与软件工程评测

错误、测试与生产治理

生产力测量