AI 工程师协调评测、Agent 和交付流水线的主题插图
AI Native Engineering

AI 工程师的
核心竞争力:
从抽卡到可验证交付

真正稀缺的不是会不会提示模型,而是能否把不确定的生成能力,收敛成可运行、可评估、可维护的业务结果。

Harness First Boundary Aware Agent Loop Engineering Closure

AI 让软件开发的生产函数发生了变化。过去工程师的核心竞争力常常被理解为“把代码写出来”,而在 AI 原生环境中,代码生成本身正在变成一种可调用能力。

新的问题变成了:怎样把模糊想法变成清晰任务?怎样让 Agent 知道边界?怎样在多轮生成中稳定接近验收标准?怎样让一次成功的演示变成可持续维护的系统?

01 / Argument

“抽卡”是入口,不是终点

用 AI 快速尝试多个方案,本质上是一种搜索。但成熟工程能力不是依赖运气,而是设计一个更容易产出好结果、也更容易淘汰坏结果的系统。

初级抽卡

  • 靠单轮 Prompt 试运气。
  • 结果好坏主要凭主观感觉。
  • 失败样例不沉淀,下次继续踩坑。
  • 能做 Demo,但很难稳定上线。

工程化抽卡

  • 设计上下文、工具、数据和约束。
  • 用测试、Eval、验收标准做评分器。
  • 让多 Agent 或多方案并行探索。
  • 把成功经验和失败模式反哺 Harness。
一句话:初级是抽卡,高级是设计卡池、评分器、重抽机制、淘汰机制和沉淀机制。
02 / Workflow

Harness 应该在最前面,而且持续优化

Harness 不是某个需求开始后的临时步骤,而是 AI 工程师工作的底座。它提供环境、样例、测试、日志、回放和评测,让后续需求可以被可靠执行。

常驻层
Harness
运行环境一键启动、依赖固定、数据可复现。
测试与 Eval单测、集成测试、任务评测集。
观测与回放日志、Trace、成本、延迟、案例复盘。
Agent 上下文架构说明、约束、改动范围、风险点。
每个需求的交付循环
1

需求澄清

把模糊想法转成目标、对象、范围、约束。

2

边界判断

判断 AI 能做、不能做、需要人审的部分。

3

验收定义

列出当前 case、目标 case、边界 case。

4

Agent 循环

探索、实现、测试、修复,多轮逼近标准。

5

收敛交付

人工验收、Review、重构、前后对比。

每完成一个需求,都应反哺 Harness:补测试、补文档、补失败样例、补 Agent 工作说明。
03 / Capability Model

AI 工程师的六项核心能力

会写 Prompt 只是表层能力。更完整的 AI 工程师画像,应该覆盖从环境建设到组织认知校准的完整链路。

Capability 01

Harness 建设能力

搭建一套人和 Agent 都能稳定工作的运行环境,包括安装、启动、测试、Mock、样例数据、日志和回放。

Capability 02

AI 边界判断能力

理解模型擅长什么、不擅长什么,知道哪些输出必须人审,哪些场景不该为了 AI 而 AI。

Capability 03

需求具体化能力

把一句话需求拆成背景、目标、范围、输入输出、验收标准、异常路径和回归风险。

Capability 04

Agent 编排能力

让不同 Agent 承担探索、实现、测试、审查、总结等角色,并通过多轮反馈逼近目标。

Capability 05

工程收敛能力

把 AI 生成的代码整理成可读、可测、可维护的工程资产,而不是停留在“看起来能跑”。

Capability 06

组织校准能力

帮助老板、产品、业务方从 AI 神话和 AI 幻灭中走出来,形成理性的场景判断。

04 / Metrics

可以量化什么?看五组指标

AI 工程能力要避免停留在“感觉效率变高”。真正可管理的能力,需要被拆成速度、稳定性、需求质量、Agent 协作和工程质量。

维度 关键问题 可量化指标
落地速度 能不能快? Idea to Demo Time Idea to PR Time First Pass Success Rate Time to Iterate
Harness 质量 能不能稳? One-command Setup Success Rate Test/Eval Coverage Regression Catch Rate Replayability
需求具体化 Agent 是否知道该做什么? Acceptance Criteria Completeness Scope Clarity Ambiguity Rate Rework Rate
Agent 协作 能否管理 AI 劳动力? Agent Task Pass Rate Human Intervention Rate Loop Count to Pass Parallel Exploration Yield
工程质量 是否能长期维护? Review Defect Density Test Stability Change Failure Rate Production Incident Rate
05 / Boundary

成熟组织会从“AI 万能”走向“边界清晰”

企业老板和团队对 AI 的认知,经常会经历四个阶段。AI 工程师的重要价值,就是把组织从前两个极端带到后两个可执行状态。

过度乐观

AI 什么都能做

被宣传、Demo 和短期效果吸引,容易把“能生成”误解成“能负责”。

落地受挫

AI 什么都不能做

遇到幻觉、成本、权限、质量波动和集成难题后,进入否定阶段。

场景可用

这个 AI 可以做

开始理解任务边界,找到适合 AI 的输入、输出、流程和兜底方式。

理性规划

为什么这个不能 AI 做

深入业务本质,能解释风险、责任边界、ROI 和替代方案。

能生成,不等于能负责;能演示,不等于能上线;能跑一次,不等于能稳定运行。
06 / Role Mapping

三个 AI 原生岗位的分工

AI 应用开发工程师、AI 解决方案架构师和 AI 产品经理之间不是割裂的三类人,而是围绕“从模型能力到业务结果”的不同切面。

AI 应用开发工程师

把模型能力转成可上线、可维护、可迭代的软件系统。

  • RAG、知识库、Agent、模型 API。
  • 结构化输出、工具调用、成本控制。
  • 系统评测、测试、部署和稳定性。

AI 解决方案架构师

把企业现场混乱的业务、数据和流程组织成可执行方案。

  • 场景诊断、PoC 验证、业务流程拆解。
  • 客户沟通、ROI 评估、上线推进。
  • 理解边界,并能说服组织接受边界。

AI 产品/项目经理

定义 AI 产品价值、交互方式、输出标准和风险兜底。

  • 需求识别、功能规划、效果评估。
  • AI 交互设计、用户反馈闭环。
  • 验收标准、失败兜底和项目节奏。
07 / Practice Checklist

判断一个人是否具备 AI 工程能力

相比问“你会哪些模型和框架”,更有效的问题是看他能否把 AI 变成一套可复用的工程闭环。

能否一键跑通环境?

新同事或 Agent 能不能快速进入同一个可复现上下文。

能否提前写出验收标准?

在改代码前,就明确当前 case、目标 case 和边界 case。

能否解释为什么不用 AI?

不是保守,而是能识别责任、权限、数据和稳定性边界。

能否让 Agent 多轮逼近目标?

会拆任务、打包上下文、读测试结果,并控制修改范围。

能否沉淀失败样例?

每次踩坑都应变成测试、Eval、文档或工作说明。

能否把生成结果重构成工程资产?

最终交付的是可维护系统,而不是一次性的 AI 产物。

AI 工程师的真正价值,是把随机生成变成可控搜索,把单次成功变成稳定交付,把工具红利变成组织能力。

最终竞争力不在于“问得多漂亮”,而在于“收敛得多可靠”。