AI 编程范式进化论：从 Vibe 到 Harness 再到 Agentic

一个从“野蛮生长”到“专业分工”的完整进化路径

🚗 驾驶技术类比

• Vibe Coding 就像 “开碰碰车”：追求乐趣和快速移动，规则宽松，撞了墙也没关系。
• Harness Engineering 就像 “造赛道和修缰绳”：专注于如何设计和控制，确保AI这匹“烈马”能沿着正确的路径狂奔。
• Agentic Engineering 就像 “当赛车手”：坐在驾驶舱里，手握方向盘，指挥整个团队（AI代理）协同作战，冲向终点。

---

📊 三阶段深度对比分析

维度	Vibe Coding (氛围编码)	Harness Engineering (驾驭工程)	Agentic Engineering (代理工程)
核心理念	“随波逐流”：跟着感觉走，让AI自由发挥，享受编码的“氛围感”。	“驾驭烈马”：设计精密的“缰绳”和“赛道”，引导和约束AI，使其产出稳定可靠。	“指挥团队”：工程师从写代码的人，升级为管理AI代理的架构师，负责拆解任务和验收成果。
人类角色	“体验者”/“协作者”：和AI一起头脑风暴，共同编写代码，像伙伴一样。	“工程师”/“设计师”：负责顶层设计、制定规则、选择工具，AI是执行者。	“项目经理”/“架构师”：负责系统设计、任务拆解、质量监督和问题诊断。
AI角色	“高级自动补全”：辅助人类写代码，提供建议和片段。	“专业执行者”：在人类设定的框架内（如代码库、规则、API），自主完成任务。	“协同作战团队”：多个AI代理分工协作，各自负责不同模块，通过工具和API进行交互。
代码质量	参差不齐：可能产出惊艳的创意，但也容易产生混乱和错误，需要人工大量修正。	稳定可控：通过工程化手段，代码质量有基本保障，但高度依赖“缰绳”设计的好坏。	高可靠性：通过多代理协作和严格验收，代码质量和系统一致性达到生产级别标准。
典型场景	快速原型设计、个人小项目、探索性编程。	中大型项目开发、企业级应用构建、需要长期维护的代码库。	复杂的系统开发、多模块协同的大型项目、需要持续集成的产品。
时间阶段	2023-2024 (萌芽期)	2024-2025 (规范期)	2025- (专业期)

---

🚀 进化背后的逻辑：从“能用”到“好用”再到“可靠”

1. Vibe Coding (2023-2024 萌芽期)

• 驱动力：AI（如Cursor）刚出现时带来的新奇感和效率提升。
• 特点：随意、快速、有趣。人们惊叹于AI能写代码，享受“我说你写”的协作乐趣。
• 局限性：缺乏工程约束，当项目规模变大时，AI生成的代码可能导致“技术债务”快速累积，难以维护和调试。

2. Harness Engineering (2024-2025 规范期)

• 驱动力：随着AI能力增强，业界开始思考如何系统化地利用它，避免其产生的混乱。
• 核心突破：提出了**“控制”**的概念。不再让AI自由发挥，而是通过设计精良的提示词、代码库结构、测试用例等“缰绳”，来引导AI产出符合工程标准的代码。
• 典型代表：OpenAI的“3人5个月百万行代码”实验。他们全程不写代码，但一定写了很多**“规则”和“设计文档”**，这就是“缰绳”。

3. Agentic Engineering (2025 专业期)

• 驱动力：对Vibe Coding的反思和升级。Andrej Karpathy认为，真正的专业开发不能停留在“随性”层面。
• 核心突破：提出了**“角色转变”。工程师不再是“码农”，而是“AI代理的指挥家”**。你的核心价值在于理解复杂业务、设计系统架构、拆解任务、以及诊断AI代理无法解决的边缘问题。
• 能力要求：需要更强的系统设计能力、逻辑思维能力和问题抽象能力。写代码本身变成了AI代理的工作，而工程师则专注于更高层次的思考和决策。

---

💎 最终总结

• Vibe Coding 是 “启蒙运动”，让所有人看到了AI编程的可能性。
• Harness Engineering 是 “工业革命”，找到了如何规模化、工程化地使用AI的方法。
• Agentic Engineering 是 “专业分工”，重新定义了人在AI时代的核心价值和角色。

一句话概括：
如果你还在享受Vibe Coding的乐趣，说明你正处在AI编程的探索期；如果你开始思考如何设计“缰绳”来驾驭AI，说明你进入了Harness Engineering的实践期；而当你意识到自己的价值在于指挥AI代理完成复杂系统时，你就已经是一个Agentic Engineer了。

💎 道路选好了，咋走？

Simon Willison 的 Agentic Engineering 中的 TDD 开发也许是不错的方法学。

将经典测试驱动开发（TDD）适配到与AI代理协作的新场景

🎯 核心概念：红/绿 TDD（Red/Green TDD）

Simon Willison提出的“红/绿 TDD”是他Agentic Engineering（代理工程）模式中的一个核心实践。它并非一个全新的概念，而是将经典的**测试驱动开发（TDD）**方法论，巧妙地适配到了与AI代理协作的新场景中。

简单来说：这是一种让AI代理遵循 “先写一个会失败的测试，再写代码让它通过” 的开发流程。这能极大地提升AI生成代码的质量和可靠性。

---

🔑 为什么在Agentic Engineering中要强调TDD？

Simon Willison认为，在与AI代理合作时，采用测试优先的开发方式有几个关键好处：

1. 为“廉价”的代码建立“护栏”

他有一个核心观点是 “现在写代码很便宜” 。AI可以快速地生成大量代码，但这些代码的质量可能参差不齐。TDD就像是为AI这匹“烈马”修建的“赛道”和“护栏”，通过预先定义的测试用例，将AI的创造力约束在正确的轨道上。

2. 让AI代理拥有“自我验证”的能力

TDD流程能迫使AI代理在执行任务前先理解验收标准。当它看到测试从“红”（失败）变为“绿”（通过）时，就获得了一个清晰的、可量化的成功信号，而不是模糊地认为“代码写完了”。

3. 捕捉难以预料的错误

AI代理可能会以一些人类难以预料的方式破坏现有代码。一个完善的测试套件能够可靠地捕获这些回归错误，这是在复杂的AI协作项目中保障软件稳定性的关键。

---

🛠️ 如何让AI代理遵循“红/绿 TDD”？

Simon Willison在他的指南中分享了具体的方法。关键在于如何向AI下达指令。例如，你可以这样告诉你的编码代理（如Claude Code或OpenAI Codex）：

“采用测试优先的开发方式。首先，为我想要的新功能编写测试用例，并运行它们，向我展示它们失败（红灯）。然后，再编写实现代码，直到所有测试通过（绿灯）。”

通过这种方式，你实际上是在训练AI代理遵循一个严谨的工程流程，让它从一个“代码生成器”转变为一个有目标的“问题解决者”。

---

📋 红/绿 TDD 流程图解

┌─────────────────┐
│ 编写测试用例 │
│ (预期会失败) │
└────────┬────────┘
↓
┌─────────────────┐
│ 运行测试 │ ◄────┐
│ 🔴 红灯(失败) │ │
└────────┬────────┘ │
↓ │
┌─────────────────┐ │
│ 编写实现代码 │ │
│ (让测试通过) │ │
└────────┬────────┘ │
↓ │
┌─────────────────┐ │
│ 运行测试 │ │
│ 🟢 绿灯(通过) │ ─────┘
└────────┬────────┘ (循环直到通过)
↓
┌─────────────────┐
│ 重构优化 │
│ (保持绿灯) │
└─────────────────┘

---

TDD（测试驱动开发）详解

TDD不是一种测试技术，而是一种**“先写测试，再写代码”的设计技术，其终极目标是倒逼你写出更清晰、更健壮的代码**。

---

🏗️ 传统开发模式 vs. TDD模式

想象一下，你要建造一栋房子（开发一个功能）：

传统方式（先建后验）

1. 先盖房子（写功能代码）
2. 房子盖好了，再请验收团队（写测试代码）来检查：门窗能不能打开？水电通不通？
3. 发现问题：如果验收时发现窗户打不开（功能有bug），就得返工修改，成本很高。

TDD方式（先验后建）

1. 先写验收标准（写测试）。比如，你告诉施工队：“我需要一扇能打开90度的窗户。”但此时房子还没盖，这个标准注定会失败（红灯）。
2. 再盖房子（写功能代码）。施工队只做一件事：让那扇窗户能打开90度，其他的暂时不管。
3. 验证：窗户装好了，你去推了一下，刚好90度，验收通过（绿灯）。
4. 优化（重构）：看看窗户有没有毛刺，开关是否顺滑，但保证它依然能开90度（仍保持绿灯）。

---

🔴🟢 TDD的核心三定律（红/绿/重构）

┌─────────────────────────────────────┐
│ TDD 循环流程 │
├─────────────────────────────────────┤
│ │
│ ┌───────────────┐ │
│ │ 红灯阶段 │ │
│ │ (写测试) │ │
│ └───────┬───────┘ │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ 绿灯阶段 │ ◀───┐ │
│ │ (写代码) │ │ │
│ └───────┬───────┘ │ │
│ │ │ │
│ ▼ │ │
│ ┌───────────────┐ │ │
│ │ 运行测试 │ │ │
│ │ 🔴 失败 │ │ │
│ │ 🟢 通过 │─────┘ │
│ └───────┬───────┘ │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ 重构阶段 │ │
│ │ (优化代码) │ │
│ └───────────────┘ │
│ │
└─────────────────────────────────────┘

1. 红灯阶段（写测试）

• 在写任何功能代码之前，先写下你期望代码的行为
• 注意：这个测试必须是可执行的，并且因为它对应的功能还没写，所以运行起来一定会失败（显示红灯）
• 这一步的目的是：定义“完成”的标准

2. 绿灯阶段（写代码）

• 现在，写刚好能让那个测试通过的最简单代码
• 注意：不需要考虑代码是否优美，是否高效，哪怕只是写死一个返回值都行
• 这一步的目的是：让测试变绿，证明你的代码满足了最初定义的那个行为

3. 重构阶段（优化代码）

• 这是最关键的一步。测试通过了，说明你的逻辑是对的
• 现在，你可以放心地去优化代码结构、去除重复、提升可读性
• 注意：因为有测试在（安全网），你修改完后可以随时再跑一遍测试。只要测试还是绿的，就说明你的优化没有破坏任何原有的功能

---

🤔 为什么TDD在AI时代被重新强调？

结合Agentic Engineering（代理工程），你会发现TDD完美地解决了与AI协作时的核心痛点：

1. 把“模糊需求”变成“精确指令”

• 人类对AI说“写一个用户登录功能”，AI可能会写出好几种不同的实现
• 但如果先给AI一个写好的测试用例，里面规定了“输入正确账号密码返回200，输入错误密码返回401”，AI的任务就从模糊变得非常精确了

2. 让AI可以“自我纠错”

• 在传统的TDD中，是人类跑测试
• 在Agentic时代，AI代理自己就能跑测试。它写完代码后，可以立刻运行测试，看到红灯，就知道自己写错了，然后自己修改代码直到绿灯
• 这就形成了一个自动化的质量闭环

3. 解决“写代码便宜，修bug贵”的问题

• Simon Willison说的“写代码便宜”，是指AI生成代码的成本极低
• 但如果生成的代码充满bug，需要人花大量时间去调试，那总成本依然很高
• TDD相当于在AI写代码的同时，自动配备了一个**“24小时不间断的质量检查员”**，把大部分问题消灭在萌芽阶段

---

📝 实际示例：TDD实现一个加法函数

红灯阶段：先写测试

# test_calculator.py
def test_add():
    # 定义期望：add(2, 3) 应该返回 5
    from calculator import add
    result = add(2, 3)
    assert result == 5  # 此时运行会失败，因为add函数还不存在

绿灯阶段：写最简单的代码让测试通过

python

# calculator.py
def add(a, b):
    return 5  # 最简单的实现，只为通过测试

重构阶段：优化代码（同时保持测试通过）

TDD 总结

TDD的本质：一种通过测试来思考和设计代码的编程方式，而不仅仅是验证代码

TDD的流程：红（写失败测试） → 绿（写代码通过） → 重构（优化并保持通过）

在AI时代的意义：TDD为AI代理提供了清晰的目标（测试用例）和即时的反馈（红/绿信号），让AI从单纯的“代码生成器”进化成能自我纠错的“智能开发者”

所以，当你以后和AI结对编程时，可以试试先对它说：“帮我写一个测试。”你会发现，整个开发过程会变得前所未有的清晰和可靠。

💎 总结

在Agentic Engineering时代，TDD不仅没有过时，反而变得更加重要。它成为了：

• 沟通工具：让人类开发者向AI代理清晰传达“什么是正确的”
• 安全网：防止AI代理的“创造性”破坏现有功能
• 质量门禁：确保AI生成代码达到可接受的标准
• 协作框架：让人类和AI围绕可验证的目标高效协作