# Vibe Engineering 2026.1 批判性整理

**来源**：Ed Huang（黄东旭），PingCAP TiDB CTO/联合创始人\
**原文**：<https://me.0xffff.me/vibe\\_engineering\\_202601.html>

***

## 一、历史演进：从Vibe Coding到Vibe Engineering

| 时间节点      | 关键转变                                             |
| --------- | ------------------------------------------------ |
| 2025.12之前 | AI编程需要频繁人工干预，主流观点认为只适合简单CRUD                     |
| 2025.12左右 | 主流Coding Agent跨越临界阈值：长时间无人干预循环成为可能               |
| 2026.01   | 作者将术语从"Vibe Coding"升级为"Vibe Engineering"，强调不只是代码 |

**核心技术突破**：

1. **长上下文召回率跃升**：GPT-5.2相比5.1，多轮推理后有效召回从12.5%提升到70%+
2. **上下文工程成熟**：Claude Code、Codex、OpenCode的最佳实践趋于完善

***

## 二、批判性观察

### 2.1 Rust选择 —— "就这么水灵灵的武断吗？"

**原文观点**：2026年新建后端基础设施项目，Rust应为首选

**批判性分析**：

* 作者缺乏完整的决策上下文：为什么Rust？与AI配合有何特殊优势？
* 原文隐含逻辑：Rust的严谨性让AI更容易写出接近无bug的基础设施代码
* **反例**：作者自己的agfs项目用Python，随着规模增长可维护性急剧下降
* **缺失分析**：学习曲线成本、团队技能栈、招聘难度、生态成熟度均未提及

### 2.2 模型成本 —— "智能家居普及问题"

**原文观点**：$20入门模型 vs $200+ Pro Max，体验天差地别

**批判性分析**：

* 个人开发者：可能划算（作者语："省出来的时间摸鱼都舒服"）
* **组织层面的现实问题**：
  * Token消耗呈二八分布，头部工程师消耗量超过其余80%总和
  * 评论区有人提到"一天用不到1亿Token的都不叫Coding"
  * 企业成本负担不容忽视，激励机制如何设计？
* **类比精准**：智能家居不是技术问题，是成本/普及门槛问题

### 2.3 高效冷启动 —— 角色扮演方法

**核心技巧**：

```
让AI角色扮演目标用户群体
→ 例：开发PostgreSQL版TiDB时，让AI假设自己是资深Postgres用户
→ 从开发者视角列出高ROI必须实现的功能
→ 再逐个打磨需求列表
```

**价值评估**：这是一种**让AI帮助发现需求盲区**的有效方法，而非完全依赖人工需求分析。

### 2.4 文档建设 —— 手动项目长期记忆

**核心实践（第一阶段就固化）**：

| 文件                    | 用途                      |
| --------------------- | ----------------------- |
| `work.md` / `todo.md` | 计划和待办列表                 |
| `agents.md`           | 每阶段完成后更新经验教训、测试基础设施使用说明 |
| `.codex/knowledge`    | 设计文档知识库（代码合并后归档）        |

**本质洞察**：这是在Agent缺乏持久记忆能力下的**工程化workaround**。

### 2.5 实现阶段观点 —— "零人工干预"

**原文核心**："要么让AI完全去做，要么完全自己做，千万别混着来"

**批判性分析**：

* 这是一个**强观点**，与传统协作模式相悖
* 背后逻辑：混合干预会破坏AI的上下文一致性
* **适用边界**：可能只适用于模块清晰、测试完备的场景

### 2.6 测试阶段 —— "90%时间在这里"

**核心框架**：

```
There's a test, there's a feature
（有测试，就有功能）
```

**关键洞察**：

* AI擅长：微观单元测试（基本不出bug）
* AI弱项：**集成测试、端到端测试**
* **最佳实践**：
  * 在正式开发前先建好集成测试框架
  * 准备一键运行的测试用例
  * 测试生成与开发工作的Context**必须分离**

### 2.7 重构阶段 —— 5万行阈值

**关键发现**：

* 单模块超过**约5万行代码**后，Agent难以1-shot解决问题
* Agent不会主动做项目结构治理，会把功能堆进几个巨型文件
* **应对策略**：定期停下来做架构重组、模块拆分，然后恢复高并发开发

### 2.8 多Agent协同 —— "运动员与裁判"

**最具参考价值的工作流**：

```
阶段1：GPT-5.2 (Codex) → 生成多个功能的设计文档
        ↓
阶段2：Codex → 根据设计文档逐个实现功能
        ↓
阶段3：将未提交代码交给 Claude Code/OpenCode（无上下文）
        → 根据设计文档Review，提出修改建议
        ↓
阶段4：将建议反馈给Codex → 评估并修改
        ↓
阶段5：Opus 4.5 再次Review
        ↓
循环直到双方满意 → Git提交 → 更新知识库 → 下一个功能
```

**核心原理**：不共享上下文的互相Review能显著提升质量。

**并行扩展**：

* 多个Agent在不同tmux中并行工作
* 用`git worktree`在不同分支各自工作

### 2.9 未来组织形态 —— 深刻的反思时刻

**二八分布现象**：

* 头部工程师：AI增益可能10x，Token消耗超过其余80%总和
* 普通人：增益可能只有10%

**头狼模式**：

* 每个顶尖Vibe Coder有自己独特的工作流
* 同一模块难以容纳两匹头狼（1+1 < 2）
* 管理转变为"资源调度"和"冲突隔离"

**AI-Native组织困境**：

> "AI-Native的研发组织很难自底向上从非AI-Native组织中生长出来，因为大多数开发者面对变革的第一反应是回避和抵触"

***

## 三、速查表：核心结论

| 维度           | 核心观点                               | 批判性注释         |
| ------------ | ---------------------------------- | ------------- |
| **模型选择**     | GPT-5.2 (xhigh) + Opus 4.5，$200+档位 | 成本是普及瓶颈，非技术问题 |
| **冷启动**      | AI角色扮演目标用户，生成需求列表                  | 有效的需求发现方法     |
| **文档建设**     | work.md、agents.md、.codex/knowledge | 手动实现项目长期记忆    |
| **实现阶段**     | 零人工干预，要么全AI要么全人工                   | 强观点，待验证边界     |
| **测试重心**     | 90%精力在测试验收，重点是集成测试                 | 最具操作价值的洞察     |
| **复杂度阈值**    | \~5万行/模块后需主动重构                     | 实用的工程边界       |
| **多Agent协同** | 不共享上下文的互相Review                    | 运动员/裁判分离原则    |
| **组织形态**     | 头狼+Agent群，强解耦并行                    | 传统协作模式失效      |

***

## 四、核心洞察

1. **技术门槛在降低，但成本门槛依然存在** —— Token消耗与产出正相关，这本身就是一种新的资源不平等
2. **AI-Native工作流高度个人化** —— 没有通用最佳实践，每个10x工程师的工作流都不同
3. **测试能力决定AI产出上限** —— "There's a test, there's a feature"是核心方法论
4. **组织形态必须适应工具** —— 而非让工具适应传统组织形态