AI 编程与 AI Agent 杂谈

近日在面试某厂后端的时，被频繁问到 AI 编程相关内容。面试官在最后也提到了，现在 AI 编程是大势所趋，即使是后端开发，也需要了解相应的基础知识（~~完后便被挂掉一面~~）。“AI 时代程序员的护城河是什么”，类似的问题在近期也是经常出现在所读的文章中。虽然自己并不能即刻给出回答，但了解一下这些 AI 编程工具的知识大概也不是个坏事。

结果这篇博客是越写越长，AI 的新概念层出不穷，文章标题已经改了几次了。以及发现现在不管是写代码还是写博客，都越来越懒了，有问题扔给 AI 就完事了（）

从 Vibe 编程到 Spec 编程

Vibe Coding（氛围编程） 是一种使用 AI 辅助的编程范式，程序员会用提示描述要处理的问题，提供给软件开发专用的大型语言模型（LLM）。应用程序的源代码是由大型语言模型产生，程序员的工作从原来的编写代码，改为指导 AI 产生代码，测试及优化代码。Vibe coding 的提倡者认为这甚至可以让新手程序员在没有以往软件工程要求技能的情形下产出软件。

值得注意的是，当前许多 AI 编程工具已不仅仅停留在“问答式”代码生成上，而是逐步融入了命令行、IDE 等真实开发环境。例如，一些 AI 工具能够直接运行测试、调用构建工具、甚至完成简单部署。这种更智能、更具行动力的 AI Agent，正在将 Vibe 编程推向一个新的阶段。

Spec Coding（规范编程） 是一种以“明确规格（Specification）”驱动开发的新型编程范式。它的核心思想是：开发者不再直接描述实现细节，而是定义系统应具备的行为、约束与目标，由 AI 或自动化工具推导出符合规范的实现。这种方式更接近“与 AI 合作设计系统”，而非单纯让 AI 生成代码。

我是在某个技术讨论中看到“Spec 编程”这个说法的，觉得非常有趣，就记了下来。可以把它理解为面试环节中“手撕算法题”的一个反转隐喻：

在 Vibe 编程中，AI 像是面试者，你提出题目（需求），然后一步步引导它完成代码实现。
而在 Spec 编程中，AI 则变成了面试官，它根据你的目标与问题不断追问、提示、引导你明确逻辑、完善约束，最终由人类和 AI 协同得到正确、可验证的实现。

从 Vibe 编程到 Spec 编程，表面上看只是从“人指导 AI”到“AI 引导人”的角色互换，但本质上这是人机协作的深化：AI 不再只是生成工具，而是成为理解问题、验证正确性、优化实现的伙伴。这种范式尤其适用于复杂算法、系统工程、AI agent workflow 等领域，因为它能在保持创造性的同时，确保逻辑的完备与规范性。

一些知识

GPT 与 Transformer

三蓝一棕的 Transformer 扫盲视频：

看过之后至少会对这些术语有一定印象和了解：

嵌入向量
解嵌入
单头注意力
多头注意力
查询向量、键向量
值向量

一篇不错的关于实现 Transformer 的博客：[译] Transformer 是如何工作的：600 行 Python 代码实现 self-attention 和两类 Transformer（2019）

以及一个非常棒的 GPT2 原理演示网站：Transformer Explained Visually: Learn How LLM Transformer Models Work with Interactive Visualization

RAG

RAG（Retrieval-Augmented Generation，检索增强生成）是一种结合了信息检索与文本生成的 AI 技术框架。

传统大语言模型依赖训练时获得的内部知识，无法访问最新或特定领域的信息；而 RAG 则通过在生成前从外部知识库中检索相关内容，将结果与用户输入一并送入模型，从而生成更准确、实时且上下文相关的回答。

在这个过程中，有两个主要步骤：语义搜索和生成输出。在语义搜索步骤中，从知识库中找到与要回答的查询最相关的部分内容。然后，在生成步骤中，将使用这些内容来生成响应。

这种架构广泛应用于文档问答、企业知识库问答、代码搜索与 AI Agent 的记忆系统中。与纯 LLM 相比，RAG 的优势在于：

可引入最新知识，避免模型“幻觉”
提高可解释性，能展示信息来源
降低模型训练成本，通过知识检索扩展模型能力
提高数据安全性，避免私有数据进入模型参数中

MCP

MCP（Model Context Protocol，模型上下文协议），由 Anthropic 推出的一种开放标准，旨在统一大模型与外部数据源和工具之间的通信协议。MCP 的主要目的在于解决当前 AI 模型因数据孤岛限制而无法充分发挥潜力的难题，MCP 使得 AI 应用能够安全地访问和操作本地及远程数据，为 AI 应用提供了连接万物的接口。官方将其比喻为“AI 应用的 USB-C 接口”，即像 USB-C 那样，为各种 AI 模型、工具、数据源提供一个通用、标准化的接口。

AI Workflow/Agent

以下内容参考自：[译] AI Workflow & AI Agent：架构、模式与工程建议（Anthropic，2024）

增强型大模型

基本构建模块是一个增强型的 LLM，这个模型具有检索、工具和记忆等增强功能。模型可以主动使用这些功能，例如搜索查询、选择适当的工具、保存必要的信息到记忆模块中等等。

Workflow

Workflow 是通过预定义的代码路径来编排大模型和工具，一些常见的 AI Workflow 范式如下。

提示链（Prompt chaining）

提示链将任务分解为一系列顺序的子任务，每个 LLM call 处理前一个 LLM call 的输出；可以在中间任何步骤添加检查点（图中的 “Gate”），以确保处理过程仍在正轨上。

适用于能干净地将任务分解为固定子任务的场景。相比于一整个大任务，拆解后的每个 LLM call 都是一个准确率更高、延迟更低、更容易完成的任务。

路由（Routing）

通过路由对输入进行分类，并将其转发到专门的后续任务（specialized followup task）。将任务的关注点进行拆解，从而针对每个具体任务设计和调整提示词。否则，（all-in-one）提示词不仅很长，而且针对任何一种任务的提示词优化都可能会导致其他任务的性能下降。

适用于存在不同类别的复杂任务，而且这些类别分开处理时，都能得到更好的效果。前提是能够准确分类，至于是使用大模型分类，还是使用传统模型/算法分类，关系不大。

并行化（Parallelization）

编排者-工作者（Orchestrator-workers）

在这种 Workflow 中，一个中心式 LLM 动态地分解任务，将其委托给 worker LLM，并汇总它们的结果。

适用于无法预测所需子任务的复杂任务。例如，在编程中，修改的文件数量。虽然在拓扑上与 Parallelization Workflow 相似，但关键区别在于其灵活性 —— 子任务不是预先定义的，而是由协调者/编排者根据特定输入确定的。

评估者-优化者（Evaluator-optimizer）

在这种 Workflow 中，一个 LLM call 生成响应，而另一个提供评估和反馈，形成一个闭环。

适用于有明确的评估标准，并且迭代式改进确实有效（可衡量）的场景。此类场景的标志一般是，当人类给出明确反馈时，LLM 响应可以明显改进，且 LLM 也能提供此类反馈。

Agent

Workflow 中虽然有动态的能力，但动态能力还是预定义的。而 Agent 则是大模型动态决定自己的流程及使用什么工具，自主控制如何完成任务。

Agent 可以处理复杂的任务，但其实现通常很简单——它们通常只是一些“在一个循环中，基于环境反馈来选择合适的工具，最终完成其任务的大模型”。因此，给 Agent 设计工具集时，其文档时必须清晰，否则这些工具大模型用起来可能会效果欠佳。

在实现 Agent 时，建议遵循三个核心原则：

Agent 设计的简洁性。
Agent 工作过程的透明性，例如能明确显示 Agent 的规划和步骤。
通过完善的文档和测试，精心设计 Agent 与计算机之间的接口（agent-computer interfaces, ACI）。

开源框架可以帮助你快速入门，但落地生产时，要极力减少抽象层，尽量使用基本组件。遵循这些原则，就能创建出强大、可靠、可维护并受到用户信任的 Agent。

如果你对 Coding Agent 很感兴趣，可以看看这篇对 Trae 进行简单解析的文章：字节开源的 AI Coding Agent —— Trae Agent深入浅出。

Spec Coding 工作流

在使用 Cursor、Copilot 这类具备 Agent 能力的编程工具时，你会注意到一种明显不同的交互模式：当我们提出一个需求时，对话页面会“唰唰唰”地生成文本，IDE 里的代码也会分块地出现，有时还会看到对话界面上列出了类似 TODO 的任务清单。而在某些情况下，比如使用 Copilot，它甚至会在 .github 文件夹下自动生成项目文档或配置文件。

与以往那种“抽奖式”的 Vibe Coding 相比，这种工作流更像是一次有条不紊的项目协作。它不再只是“让模型猜出我要什么”，而是通过明确步骤、规划任务、生成规范文档的方式，让 AI 更系统地理解和实现需求。

在 Spec Coding 工作流中，开发过程通常遵循以下阶段：

需求分析（Requirement Specification）

开发从自然语言需求开始，通过反复对话澄清细节。AI 会尝试将模糊的需求转化为清晰的功能目标，形成一份初步的开发规范（Spec）。
规范生成（Spec Generation）

规范以文档、计划或配置文件的形式呈现，比如生成 api.spec.yaml、接口约定、模块职责说明、测试计划等。这一步确立了“AI 与人类协作的共同语言”。
代码实现（Code Implementation）

模型依据规范逐步生成代码，而不是一次性输出完整结果。你会看到 AI 在 IDE 中分步骤填充实现细节，完成从“设计”到“实现”的映射。
验证与迭代（Verification & Refinement）

最后，通过运行测试、审查规范与实现的差距，反向更新 Spec。这形成了一个持续闭环：Spec -> Code -> Test -> Refine Spec。

相比于传统的 Vibe 编程，Spec 编程让 AI 从“执行者”变为“协作者”，它强调明确的目标、可验证的规范与持续的反馈循环。这种方式不仅提升了生成结果的可靠性，也让人机协作的过程更可控、更具可解释性。

最后

在文章的最后，我希望聊一聊关于 AI 取代程序员的问题。22 年的 AI 还是对话模型，虽然它很惊艳，但当时我完全不觉得 AI 有取代程序员的可能。但是 25 年的今天，AI 编程已经能让大众上手编程，做出自己想要的一个小 DEMO 了，AI 也是 DEBUG 的好手。那程序员最后会不会被淘汰呢？我想会取代程序员的不是 AI，而是会用 AI 的程序员。这种讨论就像当年相机取代绘画，数字绘画取代绘画，AI 绘画取代绘画一样。更新升级的永远是工具，程序员也是从卡孔条带、机器码、汇编语言到高级语言一步步走来的。语言的“升级抽象”让程序员能投入更多的精力到上层工作中，AI 编码则是将编程的层级提高到了自然语言编程。

我相信，AI 时代一样会有很多的程序员，但程序员的工作和任务会和以往的大有不同。不过，程序员向来是走在不断学习的路上的，所以我们要做的，就是拥抱 AI，继续进步！~~而且 AI 没法背锅，程序员才能背锅，从这个角度 AI 也还取代不了程序员~~

目录