本文目录#

引言：为什么一线工程师要把“会用 AI”升级为“会交付 AI”#

过去一年，很多团队都经历了同一个阶段：

  • 个人层面，大家都能用大模型提高写代码、写文档、排查问题的效率；
  • 团队层面，却常常出现“Demo 很快、上线很慢”“上线后不可控”“回归一塌糊涂”。

问题不在于模型不够强，而在于工程流程没有跟上。Agentic Engineering 的核心并不是“让 Agent 自动写更多代码”，而是把需求、设计、实现、验证、发布、复盘这些老问题，用面向 Agent 协作的方式重新组织成可重复流水线。

这篇是连载第一篇，我们只解决一个问题：如何把“需求到发布”的过程从个人经验，变成团队可复制的工程通路。

1. 流水线起点：需求不是一句话，而是一组可验证约束#

很多失败都从一句模糊需求开始：

“把这个页面 AI 化一下。”

对于一线工程师来说，第一步不是开写，而是把需求翻译为可执行约束。最小集合建议包含 6 项：

  1. 目标用户：谁在什么场景下使用？
  2. 成功指标：上线后看什么指标才算成功？
  3. 边界条件：失败、超时、空数据、权限不足如何处理？
  4. 风险级别：是低风险建议型能力，还是高风险自动执行能力？
  5. 回滚策略：失败后能否快速回退到旧路径？
  6. 验收标准（AC）：必须可测试、可判定。

你可以把它理解为“让 Agent 与人共享同一份任务上下文”。如果需求本身没有判定标准，Agent 只会把模糊性放大。

一个简单的文本模板就够用：

1
2
3
4
5
6
需求目标：
用户场景：
成功指标（含阈值）：
边界与异常：
权限与角色：
验收标准（可测试条目）：

2. 设计阶段：从“能做”到“能验收”#

在传统开发里，设计文档常常写“方案”；在 Agentic Engineering 里，设计文档更重要的是写“决策与证据”。

建议把设计拆成四层：

  • 接口层：输入/输出契约、错误码、幂等策略；
  • 流程层：主路径 + 异常路径 + 回退路径；
  • 验证层：哪些测试先写、首次失败点在哪里；
  • 发布层：灰度范围、告警阈值、回滚触发条件。

用一张纯文本流程图就能把关键决策固定下来：

1
需求澄清 -> 设计评审 -> 先写测试并确认失败 -> 最小实现 -> 自测与回归 -> 灰度发布 -> 观测复盘

关键点在于：每一步都必须有“下一步的入场条件”。例如，测试没先失败，不允许进入实现；覆盖率不达标，不允许进入发布。

3. 开发阶段：把 TDD 变成 Agent 协作的防漂移护栏#

很多人担心 Agent 参与后代码风格会漂。我的经验是：风格不是靠“提醒”，而是靠门禁。

开发阶段推荐固定四个动作：

  1. 先写测试：先定义“什么叫失败”。
  2. 首次失败留痕：保留失败输出，证明测试确实能拦截问题。
  3. 最小实现：只改满足测试所需最小范围。
  4. 双轮验证：关键命令连续两次通过，避免偶发绿。

对应的执行口径可以是：

1
Baseline Gate -> TDD First Fail -> Minimal Change -> Full Verification x2

对一线工程师最实用的原则是：不要让 Agent 直接决定“做什么”，只让它加速“怎么做”。需求边界、风险判断、发布时机依旧由你主导。

4. 发布阶段：把“上线”当作一个可回退实验#

Agentic Engineering 不鼓励“全量一次性上线”。

更稳妥的方法是把发布定义为实验流程：

  • 小流量灰度：先让低风险用户路径吃到新版本；
  • 可观测对照：新旧链路对比成功率、延迟、成本；
  • 自动熔断与回滚：触发阈值即回退，不依赖人工临场判断；
  • 变更记录：每次发布记录“改了什么、为什么改、如何验证”。

一个可执行的发布清单示例：

  • 灰度范围已定义（用户/地域/功能）
  • 关键指标阈值已定义（错误率、p95 延迟、单请求成本）
  • 回滚开关已验证可用
  • 监控与告警已接入
  • 发布后 30/60/120 分钟观测计划已排班

5. 首次落地最常见的 5 个坑#

坑 1：把 Agent 当“万能工程师”#

正确做法：让 Agent 承担生成与执行，把决策和验收留在人类工程师手中。

坑 2：只做 happy path#

正确做法：边界条件优先写测试，尤其是超时、重试、重复提交、权限失败。

坑 3：没有统一术语#

正确做法：在需求与设计文档里固定术语，例如“任务”“运行”“回放”“门禁”。

坑 4：发布不带回滚演练#

正确做法：发布前先做一次“假故障回滚”演练。

坑 5：复盘只讲现象不讲机制#

正确做法：复盘必须回答“哪条门禁失效了，如何补门禁”。

结语：先把流程跑通，再追求全自动#

Agentic Engineering 的第一性原理是：稳定交付优先于局部效率。先把需求到发布这条流水线打通，团队才有资格讨论更高阶的自动化。

下一篇（Part 2）我们会进入最关键的工程现实：如何把评估、回归、成本与安全变成上线闸门，而不是上线后的补救动作。

本作品系原创，采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可，转载请注明出处。