当 Andrej Karpathy 在 2025 年初创造了"Vibe Coding"这个词时，他可能没想到，仅仅一年后，这个词会催生出如此丰富的方法论生态。2026 年 4 月的今天，AI 辅助编程已经从"用嘴写代码"的单一模式，演化为六种截然不同却又彼此关联的主流形态。

这篇文章的目标不是“罗列名词”，而是帮你快速判断：

  • 每种形态到底解决什么问题
  • 它适合什么阶段、什么团队规模
  • 什么时候该升级方法论，避免项目失控

阅读导航

  • 想先抓主线：看 第 1～3 章（Vibe / Agentic / Harness）
  • 想落地流程：重点看 第 4～6 章（Loop / BMAD / SDD）
  • 想快速决策：直接看 第 8～9 章（对比矩阵 + 选择建议）

六种形态速览（先看这一屏）

形态 一句话理解 最适合场景
Vibe Coding 用自然语言快速出结果 原型、MVP、探索期
Agentic Engineering 人做监督者，代理做执行者 生产级功能开发
Harness Engineering 通过系统约束让 Agent 稳定运行 长任务、复杂工程
Ralph Wiggum Loop 通过循环和验收标准逼近完成态 迁移、批量修复、机械化任务
BMAD Method 多智能体按敏捷流程协作 中大型团队项目
Spec-Driven Development 以规格作为主要制品驱动实现 高可靠、强约束场景

1. Vibe Coding——一切的原点

定义

Vibe Coding 是 Andrej Karpathy 于 2025 年 2 月提出的编程范式，核心理念是：完全沉浸在感觉里，忘掉代码的存在，只告诉 AI 你想要什么，直接接受所有改动。

Karpathy 的原话：

“I just write stuff in natural language, hit enter, and see if it works. I barely even read the diffs anymore.”

这不是一句玩笑——它代表了一种真实的开发方式：人类用自然语言描述意图，AI 生成代码，人类不做代码审查就接受结果。

核心特征

维度 说明
人机关系 人是"产品经理"，AI 是"全能外包"
工作单元 对话——你说一句，AI 回一句
代码审查 无或极少，"跑一下看看"就是全部的验证
适用场景 原型验证、MVP、学习探索、个人项目

爆发数据

  • 92% 的美国开发者每天使用 AI 编程工具
  • 41% 的全球代码由 AI 生成
  • Lovable 凭 Vibe Coding 做到单月 1 亿美元 ARR

三个致命缺陷

Vibe Coding 的假设是"AI 足够聪明，我不需要懂它在做什么"——这在原型阶段成立，但在生产代码里不成立。

缺陷 说明 数据支撑
没有设计 “提需求，拿结果”，跳过架构设计；迭代到第三版代码债开始反噬 —
没有测试 不知道代码为什么能跑，也不知道何时会出错 AI 生成代码的 bug 密度是人工手写的 1.7 倍；63% 开发者承认至少一次调试 AI 代码时间比自己写更长
没有审查 安全漏洞、权限逻辑、敏感数据处理等问题必然被忽略 AI 协作代码安全漏洞数量是人类代码的 2.74 倍，严重问题多出约 1.7 倍

Reddit 热帖（5755 赞，562 评论）总结了社区共同经历：

项目初期非常爽 → AI 修 bug 同时引入新 bug → 代码库变成黑盒 → 加新功能改坏旧功能

2026 年的现状

2026 年 2 月 4 日，Karpathy 本人在 X 上宣布：Vibe Coding 已经过时（passé），替代词是 Agentic Engineering。

但"过时"不意味着"无用"——它依然是 0→1 阶段最快速的方式。问题在于，当项目从原型走向产品，你需要换挡了。

2. Agentic Engineering——Karpathy 的自我修正

定义

Agentic Engineering 是 Karpathy 于 2026 年 2 月提出的后续范式，核心理念是：开发者不再直接编写代码，而是编排 AI 代理并充当监督者。

Karpathy 的原话：

“Agentic 是因为新的默认模式是你 99% 的时间不再直接写代码，而是编排代理并充当监督者。Engineering 是因为其中存在艺术、科学和专业性——这是一种你可以学习并变得更擅长的技能，有它自己的深度。”

关键区分

概念 含义
Agent Engineering 构建 AI 代理本身（工具调度、上下文管理、错误恢复）
Agentic Engineering 使用 AI 代理来构建软件

前者是造工具，后者是用工具。本文讨论的是后者。

四大核心实践

实践 1：上下文工程（Context Engineering）

精心策划 AI 代理所看到的信息。核心产物是 CLAUDE.md / AGENTS.md / .cursorrules 文件，编码项目架构、约定和约束。

原则：不超过 300 行，聚焦"缺失会导致错误"的信息，渐进式加载。

实践 2：任务分解（Task Decomposition）

将工作拆分为代理可执行的粒度：一个功能、一个函数、一个模块。

  • 太宽 → 代理丢失连贯性
  • 太窄 → 协调开销占主导
  • 关键：识别任务间的依赖关系，决定哪些可并行执行

实践 3：验证循环（Verification Loops）

代理测试自己的工作：先写失败测试 → 代理迭代至通过。

测试即规格说明，代理即实现者，开发者即审查者。

包括类型检查、lint、构建等自动化验证。

实践 4：检查点纪律（Checkpoint Discipline）

  • 每次重大变更前提交工作状态
  • 代理失败时回滚而非修补
  • 从已知良好状态重新开始的成功率高于纠正错误

与 Vibe Coding 的对比

维度 Vibe Coding Agentic Engineering
人类角色 描述想要什么 架构师、分解者、审查者
代码审查 无或极少 每个 diff 都要审查
测试方式 跑一下看看 测试先行，代理迭代至通过
代理自主性 单轮生成 多步骤：计划→编码→测试→提交
适用场景 原型、MVP、学习 生产系统、团队代码库

实操示例

1
2
3
4
5
6
7
8
9
# Vibe 模式 ❌
> 帮我加一个用户登录功能

# Agentic 模式 ✅
> 实现登录 API。
> 规格：POST /auth/login，接受 {email, password}
> 返回：成功 200 + JWT，失败 401，密码用 bcrypt
> 安全：限制暴力破解，错误信息不暴露账户存在
> 完成后列出你做的每个决策和原因，我来验收

关键区别：要求 AI 解释它做的判断，这样你才能对架构有控制权。

数据支撑

  • 多代理 vs 单代理的性能提升：90.2%（Anthropic 实验）
  • C 编译器案例：16 个并行代理产出 10 万行 Rust，成本 2 万美元
  • 84% 的开发者正在使用或计划使用 AI 编码，但高度信任 AI 生成代码的仅 3%

3. Harness Engineering——模型之外的一切

定义

Harness Engineering 是 2026 年初迅速席卷工程界的新范式，核心公式：

1
Agent = Model + Harness

Harness 是模型之外的一切——系统提示词、工具调用、文件系统、沙箱环境、编排逻辑、钩子中间件、反馈回路、约束机制。模型本身只是能力来源，只有通过 Harness 把状态、工具、反馈和约束串起来，才真正变成一个 Agent。

Mitchell Hashimoto（HashiCorp 联合创始人）在博客中首次提出这个说法，OpenAI 紧接着发布了百万行代码实验报告，Martin Fowler 也跟进写了长文《Harness Engineering for Coding Agent Users》。

类比理解

模型 Harness
CPU 操作系统
引擎 底盘、方向盘、刹车

CPU 再强，OS 拉胯也白搭。买了最新款 M5 芯片，装了崩溃不断的系统，体验不如老芯片配稳定 OS。

与 Prompt Engineering / Context Engineering 的关系

三者是嵌套关系，非并列关系：

1
Prompt Engineering ⊂ Context Engineering ⊂ Harness Engineering
层级 解决的核心问题 典型工作
Prompt Engineering 表达——怎么写好指令 系统提示词、Few-shot、思维链
Context Engineering 信息——给 Agent 看什么 上下文管理、RAG、记忆注入、Token 优化
Harness Engineering 执行——整个系统怎么防崩、怎么量化、怎么持续运转 文件系统、沙箱、约束执行、熵管理、反馈回路

六层架构

从"定义边界"到"兜底恢复"的完整闭环：

层级 名称 解决什么问题 类比
L1 信息边界层 Agent 该知道什么、不该知道什么 岗位说明书
L2 工具系统层 Agent 怎么跟外部世界交互 办公工具
L3 执行编排层 多步骤任务怎么串起来 标准操作流程
L4 记忆与状态层 长任务中间结果怎么管 项目管理系统和笔记本
L5 评估与观测层 Agent 怎么知道自己做对了没有 质检流程
L6 约束、校验与恢复层 出错了怎么办 红线规则和应急预案

入门建议：不要试图一开始就搭齐六层。从 L1（信息边界）和 L6（约束与恢复）入手，投入产出比最高。L1 决定 Agent 知道该干什么，L6 决定搞砸了能不能拉回来。

为什么瓶颈不在模型而在 Harness

实验 结论
Can.ac 实验 同一模型只换了文件编辑接口调用方式，编码基准分数从 6.7% → 68.3%（10 倍差距）
LangChain Terminal Bench 2.0 优化运行环境后，排名从第 30 名升至第 5 名，模型没换

上下文 40% 阈值现象

Dex Horthy 的观察：168K token 上下文窗口，用到约 40% 时输出质量明显下降：

区间 占比 表现
Smart Zone 0–~40% 推理聚焦、工具调用准确、代码质量高
Dumb Zone 超过~40% 幻觉增多、兜圈子、格式混乱、低质量代码

工程建议：生产环境中设置 40% 阈值告警，超过时触发上下文压缩或任务交接。

一线团队实战摘要

OpenAI（3 人 · 5 月 · 百万行 · 零手写）：

  • AGENTS.md 约 100 行当目录，指向 docs/ 下更深层文档（渐进式披露）
  • 自定义 Linter 强制架构约束，报错消息直接告诉 Agent 怎么改
  • “If it cannot be enforced mechanically, agents will deviate”（不能被机械执行的规则，代理就会偏移）

Anthropic（GAN 式三智能体架构）：

1
Planner（规划者）→ Generator（执行者）⇄ Evaluator（评估者）
  • 上下文快满时不压缩，而是启动全新 Agent，通过结构化交接文档恢复状态

Stripe（每周 1300+ 无人值守 PR）：

  • 混合状态机：该确定的地方确定（lint、push），该灵活的地方灵活（实现功能、修 CI）

4. Ralph Wiggum Loop——以持久性征服不确定性

定义

Ralph Wiggum Loop 是一种将 AI 编码助手的"一次性提示"转化为持续迭代循环的技术，使 AI 不断工作，直到满足完成信号或达到迭代上限才停止。

命名源自《辛普森一家》中的角色 Ralph Wiggum，寓意一个"确定性糟糕"的智能体，通过持久性和反复调优最终达成目标。

创建者 Geoffrey Huntley 的原话：

“Building software with Ralph requires a great deal of faith and a belief in eventual consistency.”（用 Ralph 构建软件需要极大的信念和对最终一致性的信仰。）

“LLMs are mirrors of operator skill… Each time Ralph does something bad, Ralph gets tuned - like a guitar.”（大模型是操作者技能的镜子……每次 Ralph 做错事，Ralph 就被调优——像调吉他一样。）

核心哲学：在不确定的世界中追求"最终一致性"——即使每次迭代都不完美，但通过反复执行和验证，最终能产出可用代码。

两种实现方式

原始版：OG Bash 循环

1
while :; do cat PROMPT.md | claude-code ; done
  • 在 Bash 中无限循环，每次迭代都是全新的上下文，将提示词重新输入给 Claude Code
  • 优势：每次运行都从干净状态开始，避免上下文污染
  • 劣势：无状态记忆，完全依赖文件系统（磁盘上的代码）作为进展的载体

官方插件版：Ralph Loop

1
/ralph-loop "..." --max-iterations N --completion-promise "..."
  • 注册一个 stop hook（停止钩子）
  • 当 Claude 尝试退出时，钩子检查：
    1. 是否输出了完成承诺（completion promise，一个特定字符串）？
    2. 是否达到了迭代上限（max-iterations）？
  • 如果承诺未出现且上限未达，插件会重新注入原始提示，在同一会话中继续运行
  • 取消命令：/cancel-ralph

规格检查机制

Ralph 在"完成"可以被机器验证时效果最佳。常见做法是在提示中嵌入验收标准、测试用例、检查清单。这实际上是 可执行规格（Executable Specs） 和 规格驱动开发 的实践——提示描述的是"何时停止"，而非"如何编码"。

典型工作流

工作流 说明
过夜重构 运行严格的 linter 或测试套件，让循环自动修复失败项
测试先行循环 先写测试作为规格，然后循环直到所有测试通过
绿地脚手架 生成小项目，附带 npm test 或 npm start 检查
迁移循环 迁移测试框架或 API 调用，设定清晰的验收规则

提示模板示例

迁移模板：

1
2
3
4
5
6
7
8
Task: Migrate all tests in src/utils from Jest to Vitest.
Constraints:
- Do not change implementation logic, only test syntax.
- Run npm test after every file change.
Exit criteria:
- Output "<promise>MIGRATION_COMPLETE</promise>" only when:
  1) npm test passes with 0 failures.
  2) No "jest" imports remain in src/utils.

修复循环模板：

1
2
3
4
5
6
7
8
9
Task: Fix the build.
Loop instructions:
1) Run npm run build.
2) Read the error log.
3) Fix ONE error.
4) Commit with message "fix: <error description>".
5) Repeat.
If stuck for 3 iterations, revert the last change and try a different approach.
Output "ALL_GREEN" only when the build succeeds.

适用与不适用场景

✅ 最佳适用 ❌ 不太适用
确定性、机械化任务 架构设计或模糊目标
迁移、lint 修复、测试驱动循环 缺乏硬性退出标准的任务
仓库卫生维护 需要大量人工判断的工作

防护措施

  • 迭代上限：始终设置（如 10-25 次），作为断路器
  • 客观检查：要求测试、lint 或明确的清单验证
  • 显式退出标准：使用唯一的完成承诺，定义如何获得它
  • 成本控制：无限格式化战争或反复测试失败会烧尽 token

常见失败模式

失败模式 说明
幻觉式"完成" 模型未真正运行检查就输出了完成承诺
上下文污染 会话累积错误和干扰，循环质量随时间退化
权限死胡同 无人值守时卡在审批环节
成本爆炸 无限循环烧尽 token

5. BMAD Method——AI 敏捷军团

定义

BMAD 全称 Breakthrough Method of Agile AI-Driven Development（敏捷 AI 驱动开发的突破性方法），是一个 AI 驱动的敏捷开发框架，核心理念是通过多智能体协同 + 结构化工作流，实现从需求到部署的全生命周期自动化闭环。

截至 2026 年 4 月，GitHub Stars 38k+，Forks 4.7k+，最新版本 V6。

核心设计理念

设计维度 核心理念
协作模式 AI 协同而非替代——代理作为专家协作方，引导开发者通过结构化流程产出高质量成果
规模自适应 根据项目复杂度和领域自动调整规划深度
上下文管理 “上下文工程化”——禁止将整个项目文档一次性喂给 LLM，按 Story 独立加载
代理即代码 所有智能体用 Markdown 定义，可版本管理、移植、共享、持续优化
流程标准化 固定工作流 + 指令 + 模板，让 AI 智能体协作有章可循

12+ 专业智能体矩阵

# 智能体角色 职责范围 所在阶段
1 业务分析师 需求梳理、澄清边界 分析阶段
2 产品经理 输出 PRD、用户故事 规划阶段
3 架构师 技术方案、模块划分 解决方案阶段
4 UX 设计师 UX 设计输出 规划阶段
5 前端开发者 前端编码实现 实现阶段
6 后端开发者 后端编码实现 实现阶段
7 客户端开发者 客户端编码实现 实现阶段
8 QA 智能体 自动化测试、对抗式审查 实现阶段
9 DevOps 智能体 构建、部署、监控 实现阶段
10 Scrum Master 统筹进度、卡点疏通 全流程
11 Barry 智能体 Quick Flow 中的对话式需求发现 快速开发流程
12 代码审查智能体 对抗式代码审查 实现阶段

这恰好印证了 Conway 定律：“组织的系统架构反映了组织的沟通结构。” BMAD 将软件开发的组织结构映射到 AI Agent 的分工上。

四阶段工作流

1
阶段 1: 分析（可选） → 阶段 2: 规划 → 阶段 3: 解决方案 → 阶段 4: 实现

阶段 1：分析（可选）

  • 头脑风暴 → 市场研究 → 技术研究 → 领域研究 → 产品简介

阶段 2：规划

  • PRD 创建 → PRD 验证 → PRD 编辑 → UX 设计

阶段 3：解决方案（架构设计）

  • 架构设计 → Epics 与用户故事 → 实现就绪度检查

阶段 4：实现

  • Sprint 规划 → 故事创建 → 故事开发 → 代码审查 → QA 自动化 → 回顾

Quick Flow（快速开发流程）

针对小型、需求明确的变更，BMAD 提供快速通道，跳过阶段 1-3：

1
quick-spec → tech-spec.md → quick-dev → 完成

适用：Bug 修复、小功能、重构、原型探索、单人开发
不适用：需求不清晰、需做架构决策、跨多组件大功能

内置范围检测：当 quick-dev 发现工作超出快速通道范围时，会建议先运行 quick-spec 或切换到完整流程。

上下文持久化机制（核心设计）

BMAD 解决 AI 上下文局限的关键设计：

1
短期记忆（对话）→ 长期记忆（文档）→ 工作记忆（Story）

每个 Story 文件包含：

  • PRD 的功能引用（为什么要做）
  • Architecture 的设计片段（怎么做）
  • 验收标准（做到什么程度）

Dev Agent 打开 Story 即获得完整上下文，无需回溯对话历史，实现**“零上下文污染"和"零上下文启动”**。

安装与使用

1
npx bmad-method install

安装后可运行 bmad-help，根据项目状态和已安装模块获取下一步建议。

6. Spec-Driven Development——代码是规格的实现细节

定义

Spec-Driven Development（SDD，规格驱动开发）的核心理念：将规格说明而非代码作为软件开发的主要制品，代码是从规格说明派生或验证的次要制品。

来自 arXiv 论文《Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants》（2026 年 1 月）：

“在 SDD 中，代码是规格说明的实现细节，而非反过来。规格声明意图，代码实现意图。”

SDD 颠覆了传统工作流：

  • 传统方式：先写代码，后补文档（或不补），代码成为系统的实际真相
  • SDD 方式：先写清晰的规格说明，然后生成、实现或验证代码以匹配规格

与 Vibe Coding 的对比示例

维度 Vibe Coding SDD
提示方式 “给我的应用加个照片分享功能” “用户可上传 JPEG/PNG 照片，上限 10MB，存储到 S3 使用 user-ID 前缀键名，仅上传者可删除，上传时自动缩放到最大 1024px”
AI 的工作 猜测格式、权限、存储方式、压缩等数十个未说明的假设 依据明确的契约生成符合意图的代码
结果 看似合理但充满错误假设的代码 与意图高度一致的可靠代码
根本问题 AI 擅长模式补全，但不擅长读心术 规格消除了歧义，让 AI 无需猜测

规格严格度的三个层级

1
2
3
代码优先 ←─────────────────────────────→ 规格即源码
  Spec-First    Spec-Anchored    Spec-as-Source
  (轻度)          (中度)            (重度)
层级 特征 适用场景
Spec-First（规格优先） 编码前先写规格引导初始实现，之后规格可能不再维护 AI 辅助的初始开发、原型、一次性功能
Spec-Anchored（规格锚定） 规格与代码全生命周期同步维护，变更行为需同时更新规格和代码 大多数生产系统的最佳平衡点
Spec-as-Source（规格即源码） 规格是唯一人类编辑的制品，代码完全由规格生成，永远不手动编辑生成代码 代码生成工具成熟可信的领域

黄金法则：使用能消除歧义的最小规格严格度。

四阶段工作流

1
2
Specify → Plan → Implement → Validate
(定义做什么)  (决定怎么做)  (构建)   (验证是否符合)
阶段 核心问题 关键产出 审查方式
Specify 软件应该做什么？ 功能规格（行为、需求、验收标准） 人工审查
Plan 应该怎么构建？ 技术方案（架构、数据模型、接口、技术选型） 人工审查
Implement 实现代码 工作代码 + 单元测试 人工审查 + 对齐规格和方案
Validate 代码是否满足规格？ 验证结果（自动化测试 + 人工判断） 自动化 + 人工

关键原则：小增量、频繁验证。每个阶段产出约束下一阶段的制品，形成从意图到实现的责任链。

关键支撑工具

类别 工具 说明
BDD 框架 Cucumber / SpecFlow / Behave 用 Gherkin 的 Given/When/Then 编写可执行规格
API 规格工具 OpenAPI / GraphQL SDL / Protocol Buffers 定义契约，生成代码和测试
契约测试 Pact / Specmatic 验证实现是否匹配规格
AI 辅助 SDD GitHub Spec Kit /specify → /plan → /tasks → implement 四阶段流程
Amazon Kiro 结构化需求捕获 + 迭代精炼
Tessl 规格即源码模式，开发者只编辑规格

何时使用 SDD

适合：AI 辅助编码、需求复杂、多维护者、集成密集、受监管领域、遗留系统现代化

不必：一次性原型、单人短期项目、探索性编码（尚未明确要构建什么）、简单的 CRUD 应用

7. Bonus: Context Engineering——被 Harness 吞并的前范式

在讨论 2026 年的编程范式时，有一个概念无法回避——Context Engineering（上下文工程）。虽然它已被 Harness Engineering 吸收为子集，但它的影响如此深远，值得单独一节。

定义

Context Engineering 的核心理念：多数 AI Agent 的失败，并非模型能力的失败，而是上下文工程的失败。

它从 Prompt Engineering（怎么写好指令）升级而来，解决的是一个更根本的问题——在合适的时机，给 Agent 提供正确且必要的事实信息。

三层嵌套关系

1
Prompt Engineering ⊂ Context Engineering ⊂ Harness Engineering
层级 解决什么 典型操作
Prompt Engineering 怎么写好指令 系统提示词、Few-shot、思维链
Context Engineering 给 Agent 看什么 上下文管理、RAG、记忆注入
Harness Engineering 整个系统怎么运转 文件系统、沙箱、约束、反馈回路

核心实践

  • 渐进式披露：不要把所有信息塞进一个文件，按需加载
  • 上下文压缩：超过 40% 上下文窗口时质量下降，需主动压缩
  • 记忆注入：将关键决策、架构约束写入 AGENTS.md 等文件
  • Token 优化：精简无关信息，保留"缺失会导致错误"的内容

Andrej Karpathy 亲自为 Context Engineering 打 Call，认为它是 2025-2026 年最被低估的技能之一。

8. 六种形态的对比矩阵

维度 Vibe Coding Agentic Engineering Harness Engineering Ralph Wiggum Loop BMAD Method SDD
一句话描述 用嘴写代码，不审查 编排代理，充当监督者 模型之外的一切 以持久性征服不确定性 AI 敏捷军团 规格即契约
人机关系 人是产品经理 人是架构师 人是系统设计师 人是规则制定者 人是流程指挥官 人是规格编写者
核心产出 运行代码 通过验证的任务 可靠的 Agent 系统 最终一致的代码 全生命周期文档+代码 规格+验证代码
对代码的态度 不看，接受就行 每个 diff 都审查 系统化约束防崩 反复迭代直到对 代理写，人审规格 代码是规格的实现细节
适用规模 个人/原型 团队/生产 企业/关键系统 机械化任务 中大型项目 任何需要可靠性的项目
学习曲线 零 低 中 低 高 中
关键风险 技术债爆炸 协调开销 过度工程 成本爆炸 流程过重 规格过细
代表工具 Cursor Chat Claude Code OpenAI Agent SDK Claude Code Ralph 插件 BMAD V6 GitHub Spec Kit

9. 如何选择适合自己的形态

按项目阶段选择

1
2
3
4
5
探索期 → 验证期 → 构建期 → 运维期
  |          |          |          |
Vibe     Agentic    Harness    Harness
Coding   Engineering Engineering + SDD
         + SDD       + Ralph Loop

按项目规模选择

规模 推荐形态 理由
个人小项目/原型 Vibe Coding 快速出活，成本最低
单人中型项目 Agentic Engineering + SDD 有审查有规格，但不需重流程
团队项目 BMAD Method + Harness Engineering 多角色协同，系统化约束
企业关键系统 Harness Engineering + SDD 可靠性第一，规格即契约
机械化任务（迁移/修 bug） Ralph Wiggum Loop 自动化循环，最终一致性

切换信号

从 Vibe Coding 切换到更高阶形态的信号：

  • 🟡 项目有了真实用户
  • 🟡 改一个功能开始怕影响其他功能
  • 🟡 AI 建议的方案你已经看不懂逻辑
  • 🟡 代码库超过你无法整体把握的规模
  • 🔴 安全事件发生
  • 🔴 修一个 bug 引入三个新 bug

10. 结语：范式的终点是工程

2025 年，Vibe Coding 的意义是降低入门门槛，让人从 0→1。
2026 年，后续范式的意义是让东西从 1→10 不崩盘。

这六种形态不是互相替代的关系，而是工具箱里的不同工具：

  • Vibe Coding 是锤子——简单直接，但不是所有东西都是钉子
  • Agentic Engineering 是电动工具——更强大，但需要操作规范
  • Harness Engineering 是整个车间——设备、安全规程、质检流程
  • Ralph Wiggum Loop 是自动化工位——设定好规则，让它自己跑
  • BMAD Method 是工厂流水线——从原料到成品的全流程
  • SDD 是工程图纸——先画好蓝图，再动手施工

大多数 Vibe Coding 项目的死法不是技术问题，是方法论追不上规模的问题。选择正确的范式，在正确的时机切换——这才是 2026 年 AI 编程的核心竞争力。

模型决定上限，Harness 决定底线。
与其纠结选哪个模型，不如先把方法论选对。

参考资料

  1. Karpathy, A. (2025). “Vibe Coding” 原帖. X (Twitter).
  2. Karpathy, A. (2026.2.4). “Agentic Engineering” 宣言. X (Twitter).
  3. Hashimoto, M. (2026). Harness Engineering 博客.
  4. Fowler, M. (2026). “Harness Engineering for Coding Agent Users”.
  5. Huntley, G. (2025). Ralph Wiggum Loop. ralphwiggum.org.
  6. Piskala, D. B. (2026). “Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants”. arXiv:2602.00180.
  7. BMAD-METHOD. (2026). GitHub Repository. github.com/bmad-code-org/BMAD-METHOD.
  8. OpenAI. (2026). Million-line Code Experiment Report.
  9. Anthropic. (2026). Multi-Agent Coding Best Practices.
  10. GLM-5 Team. (2026). “GLM-5: from Vibe Coding to Agentic Engineering”. arXiv:2602.15763.

本文写于 2026 年 4 月，基于公开资料整理。AI 编程领域发展迅速，部分信息可能已更新，建议结合最新实践阅读。