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）

RAG

注意

施工中

MCP

注意

施工中

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 工作流

注意

施工中

最后

注意

施工中

程序员，最后会不会被淘汰？

目录