09-Vibe-Coding到Agentic-Engineering三次范式迁移

从 Vibe Coding 到 Agentic Engineering：AI 编程范式三次迁移全景

前言

如果你正在读这系列文章，说明你已经走过了一段 AI 编程的旅程——从第 01 章的工具全景，到第 06/07 章的 Agent/RAG 原理，再到第 08 章的 Harness 防护。你已经看到 AI 编程工具的「能力面」和「陷阱面」。

但这一章要回答的是另一个问题：这场革命的全局图景是什么？

• 2021 年 GitHub Copilot 刚发布时，AI 还只是「行补全器」
• 2025 年 Karpathy 喊出 “vibe coding”，AI 变成了「自然语言到代码的转换器」
• 2026 年 DeepSeek Harness 喊出「一切皆插件」，AI 变成了「可被任何人改造的基础设施」

三次迁移，每一次都涉及主导权的转移——从「人写 AI 补」到「人描述 AI 写」再到「AI 主导人指挥」。本章从宏观视角回顾这条演进路径，剖析 Vibe Coding 五步法的实战要诀，拆解 Harness 工程化的核心组成，展望 DeepSeek Harness「一切皆插件」代表的开放生态，以及 OpenClaw / OpenSpec / OpenCode 等开源项目共同形成的未来图景。

一、三次范式迁移：主导权的逐级交接

1.1 三次迁移的时间线与核心特征

1.2 Copilot 范式：「AI 帮补代码」

2021 年 GitHub Copilot 上线，AI 在 IDE 里以灰色补全的形式出现。核心特征：

• 触发方式：人写一行，AI 补几行
• 能力边界：行级补全，函数级片段
• 人的角色：写代码的执行者
• 典型局限：上下文窗口小、不能跨文件理解、生成后需要人 review

Copilot 让开发者第一次感受到「AI 懂我」，但它本质仍是「人写 AI 补」——代码的主导权完全在人手里。

1.3 Vibe Coding 范式：「人描述 AI 写」

2025 年 2 月，Karpathy 在 X 上抛出一个新词：

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

他的工作方式：用 SuperWhisper 语音输入，对 Cursor Composer 说话，完全放弃手写代码，接受 AI 的指数级进化。

Vibe Coding 的核心转变：

传统编程思维：需求 → 语法 → 代码 → 调试
Vibe Coding 思维：需求 → 描述 → AI 生成 → 验证 → 调整描述

这不是简单的工具升级，而是程序员核心能力的重构：

但 Vibe Coding 也有明确边界——它适合个人小项目和快速原型。一旦进入团队协作或生产环境，「完全 give in to the vibes」很快就会失控：AI 写出一坨「看似能跑」的代码，下一个接手维护的人会陷入无尽的技术债。这就是 2026 年社区开始反思的「氛围编程幻觉」。

1.4 Agentic Engineering 范式：「AI 主导 + 人指挥」

2026 年的共识是：vibe coding 适合个人小项目，但生产级代码需要Skills 化、流程化、测试驱动。这就是 Agentic Engineering——AI 主导执行，人类指挥方向与验收。

Software Engineering → Agentic Engineering 的范式跃迁：

核心命题：软件开发正从「人写代码」转变为「人指挥 AI 写代码」。

在 Agentic Engineering 时代，Harness （马具）取代 Prompt 成为新的核心生产资料——下一节详解。

1.5 主导权逐级交接的深层逻辑

为什么是三次迁移而不是两次？因为主导权的交接需要分三步走：

每一步都是AI 能力边界和人类信任边界同步扩展的结果。当模型不够强时，AI 只能当补全器；当模型足够强但人还不信任时，需要人描述清楚；当模型足够强且 Harness 足够可靠时，人才敢放手让 AI 主导。

二、Vibe Coding 五步工作法：个人生产力的放大器

范式迁移是宏观叙事，真正落地到每个人的工作里，要靠可操作的方法论。Vibe Coding 的五步工作法就是这样的方法论：

Pick → Describe → Iterate → Test → Ship

2.1 Pick：选一个你熟悉的问题

「我想做一个每周读书清单的管理工具」 ✅

「我想做一个社交平台」 ❌（太大）

为什么 Pick 这么重要？因为 Vibe Coding 的核心是「描述 + 验证 + 反馈」的循环——如果你对自己要做的问题不熟悉，就无法判断 AI 生成的对不对、好不好。选熟悉的领域，你才能在 AI 跑偏时第一时间发现。

2.2 Describe：用自然语言描述，但要具体

Vibe Coding 的核心心法是「给目标，不给实现路径」：

• ❌ “用 React 的 useState 和 useEffect 写一个计数器组件”
• ✅ “页面顶部显示一个数字，点了按钮数字会增加”

一个好的描述应该包含：

PRD 是 Vibe Coding 的「项目说明书」。建议在项目根目录新建 PROJECT_PRD.md，每次让 AI 修改时引用：

# 项目 PRD
## 项目概述
## 目标用户
## 核心功能（3-5 个最重要）
## 页面 / 模块结构
## 设计与体验要求
## 技术约束
## 素材与数据
## 验收标准
## 暂不做的事情（避免项目变复杂）

2.3 Iterate：小步迭代，一次改一个问题

这是 Vibe Coding 最重要的方法论。

不要一次性说 10 个修改意见。每次只说一个，等 AI 改完，你测试，确认没问题，再提下一个。

为什么？小步迭代有两个关键好处：

Git 是 Vibe Coding 的安全网——每次大改前先 commit，改坏了随时回退。

2.4 Test：马上测试，像用户一样使用

不要相信「看起来没问题」。你要真的去点、去输错、去断网。AI 写的代码经常有看起来合理但跑不通的边界情况——比如空字符串、Unicode 字符、网络超时、并发竞争。这些只有真测才会暴露。

2.5 Ship：部署分享，收集反馈

做出第一个版本就发布，别憋着。真实用户的反馈比你在家里想一百遍都有用——这是 Vibe Coding 区别于传统开发的根本：发布成本趋近于零，迭代成本也趋近于零。

2.6 提示词五条铁律

Vibe Coding 的「Describe」环节具体怎么写？五条铁律供参考：

2.7 三条安全铁律：Vibe Coding 不能碰的红线

Vibe Coding 不是万能的，有三个领域永远不能 Vibe Code：

金句：「AI 写出来的屎山代码，你来维护？」——这是 Vibe Coding 在生产环境的真实代价。

三、Harness 工程化：从个人防护到团队规范

Vibe Coding 适合个人小项目，但生产级代码需要 Skills 化、流程化、测试驱动。这就是 Harness Engineering（马具工程）的用武之地。

3.1 什么是 Harness

「Harness」（马具）的比喻非常形象：LLM 是动力十足的烈马，Harness 是让它全速奔跑又不偏离轨道的缰绳。

在 Agent = LLM + Planning + Memory + Tool Use 公式里，除 LLM 外的所有部分（规划/记忆/工具/可观测性/安全/版本管理）都可纳入 Harness 范畴。

核心公式：

Agent 的能力 = LLM 智力 × Harness 工程化水平
↑
LLM 决定上限
↑
Harness 决定下限

3.2 Harness 五大组件

一个完整的 Harness 包含 5 大组件：

1. Context Engineering（上下文工程）

• 三级架构：全局 AGENTS.md（项目级铁律）+ 目录级 rule file（模块级约束）+ skill/docs/（按需加载）
• 渐进式披露：不一次性塞入所有上下文，而是按需加载——这是 Harness 区别于 Prompt 的关键

2. TDD + 静态分析

• 强制 RED-GREEN-REFACTOR 循环
• 用 linter / type-checker / test runner 作为 AI 输出的验证关卡

3. 架构约束

• 在 Harness 层强制目录结构、模块边界、依赖规则
• 防止 AI 写出"能跑但违反架构"的代码

4. 执行隔离 Sandbox

• AI 代码运行在隔离环境，不影响主分支
• 典型实现：Docker / Firecracker / daytona 远程 devbox

5. Entropy 治理（熵治理）

• 监控 AI 输出的"混乱度"，及时介入
• 检测幻觉、循环、跑偏等异常模式

3.3 四大典型落地案例

Harness 不是纸面理论，已经有大量工业级实践：

注意 LangChain DeepAgents 的数据——纯 Harness 优化就让模型在 Terminal Bench 2.0 上的得分从 52.8% 提升到 66.5%。这印证了「LLM 决定上限，Harness 决定下限」的判断。

3.4 个人 Harness 公式

对个人开发者来说，Harness 是什么？

个人 Agent = 通用 Agent + 个性化上下文&流程约束
↓
行为规则（AGENT.md）+ 能力模块（Skills）

这意味着即使你用 Claude Code 这种「现成」的工具，你仍然可以通过写好 CLAUDE.md（项目级规则）和自定义 Skills（能力模块）来打造自己的 Harness。这是Harness Engineering 平权化的关键——它不是大厂的专利。

3.5 Harness vs Vibe Coding：从「Prompt Engineering」到「Context Engineering」

Vibe Coding 的核心是 Prompt Engineering——写好一次性 Prompt 让 AI 输出好结果。
Harness 的核心是 Context Engineering——构建持续的、按需加载的上下文系统。

两者的差别是：

• Prompt 是「一次性输入」——你说一句话，AI 回一句
• Context 是「持续输入」——AGENTS.md 长期生效，Skills 按需加载，工具调用历史被记录

关键洞察：「通用的模型 Harness 只是模型能力缺口的临时解法，会随模型变强被拆掉；但个性化的上下文不会，你用得越久，上下文越丰富，Agent 表现越好」。

四、DeepSeek Harness 与「一切皆插件」理念

如果说 Harness Engineering 是「方法论」，那 DeepSeek Harness（DSH）就是这种方法论的极端实现——它把 Harness 的开放性推到了极致。

4.1 DSH 的定位：可组合的 Agent 运行时平台

DeepSeek 在 2026-08 开源了 DeepSeek Harness（DSH），GitHub 一天冲 7 万+ Star。它的官方定位是：

可以高度定制的 AI 编程工具，对标 Claude Code/Codex，但野心更大——是一套「可配置、可重组的 Agent 运行环境」。

核心公式：Agent = Model + Harness——模型负责思考生成，Harness 负责把能力接入文件系统/终端/网页/工具链。

4.2 「一切皆插件」：与 Codex/Claude Code 的根本差异

DSH 的官方口号是「一切皆插件」——模型、工具、技能、会话、沙箱、UI，甚至 Agent 的运行循环本身，都是可拔插的插件。

这是与 Codex/Claude Code 的根本性差异：

关键金句：「Codex 是给你用的，DSH 是给你改的」——一字之差，定位天差地别。

4.3 DSH 的 4 种运行模式

DSH 内置 4 种运行模式，应对不同场景：

4.4 DSH 的 4 大核心设计

1. 一切皆插件：内核可整体替换，扩展不限于外围——这是与 Codex/Claude Code 的根本差异

2. 能力族（capability family）三角色：

packages/ 按能力族分组
├── Service Definition（接口包）— 声明 ctx key 与类型契约
├── Service Provider（实现包）— local / sandbox / e2b / 各厂商可替换
└── Consumer（消费包）— 通常是模型工具，注册到 ctx.tools

3. YAML 分层 patch + 编译期 declaration merging——配置可以像 Git 一样分层合并，last-write-wins

4. 事件溯源日志可 fork/回放 + 同进程插件树（基于 Cordis Context）——所有状态可追溯、可回放、可分叉

4.5 鱼皮 4 个项目实测

鱼皮（阿里云开发者社区）在 DSH 上线后做了 4 个项目实测：

关键数据：

• 缓存命中率 ≥ 99%（4 个任务均达此水平）
• 4 个任务总成本 < 5 元
• 效果可对标 Claude Opus 5（用 DeepSeek V4 Pro + DSH）

4.6 插件生态

DSH 上线 1 天，dsh-plugin topic 已涌现 300+ 精选插件，包括：

• UI 皮肤：dsh-deep-whale（鲸鱼娘）、dsh-deepcel（Excel 风格）、dsh-tianshu-tui（TUI 终端）
• 能力补齐：modlens（OCR + JSON 结构化解析，补齐 DSH 文本模型无法看图的短板）
• 交互优化：DSH-better-sidebar（侧边栏优化）、dsh-at-file（@ 符号文件引用）

「自己的模型配自己的 Harness 工具，真的强」——这是「模型 + Harness」协同效应的最直接证明。

五、开源生态：OpenClaw / OpenSpec / OpenCode

DSH 不是孤例。在 AI 编程开源生态里，有三个值得关注的开源项目：

5.1 OpenClaw：多 Agent Discord 协作框架

OpenClaw 是面向 Discord 等 IM 平台的多 Agent AI 协作框架。它支持同时挂载多个专业化 Agent（编程、内容创作、健康管理、投资分析），每个 Agent 绑定独立的 Discord 频道和 Bot 账号，实现「任务分流 + 专业化响应 + 实时流式推送」。

典型多 Agent 团队配置：

Block Streaming 实时推送是 OpenClaw 的关键能力——解决 AI 推理 30 秒-1 分钟时「用户干等着没反馈、突然一大段砸过来」的体验问题：

// openclaw.json
{
"streaming": {
"blockStreaming": {
"enabled": true,
"minChars": 200, // 累积 200 字符才推一次
"maxChars": 1500, // 单次最多推 1500 字符
"idleMs": 600 // 静默 600ms 触发推送
}
}
}

OpenClaw 可视为 Claude Code 在 IM 平台上的「团队协作化扩展」。

5.2 OpenSpec：规格驱动开发的工程化升级

OpenSpec 是 Vibe Coding 的「规格先行」工程化升级——把「模糊需求」转化为「机器可读的规约」，让 AI 先说清楚再动手。

核心四件套：

proposal.md — 动机、目标、影响范围
design.md — 架构、接口、数据流
tasks.md — 任务拆解（可勾选 checklist）
spec-deltas/ — 规格变更历史（每次改 spec 都留痕）

实战价值：

• 需求漂移防护：把"邮箱登录 vs 手机号登录"在 proposal 阶段就明确
• 变更可追溯：每次 spec 变更都有 spec-deltas 记录，团队成员可回溯
• AI 协作契约：AI 与团队共同遵守同一份规约，避免"AI 想的是 A，团队要的是 B"
• 多 AI 工具适配：OpenSpec 规格独立于具体 AI 工具（Claude Code/Codex/Cursor 均可执行）

OpenSpec 与 Superpowers 的关系是完美互补：「OpenSpec 解决’做什么’，Superpowers 解决’怎么做’」，两者焊死后形成完整闭环。

5.3 OpenCode：供应商自由的开源 CLI

OpenCode 是一个开源、供应商中立的终端 AI Agent（基于 MIT 协议）。它对标 Claude Code，但核心差异是模型可换——你可以用 Claude、GPT、DeepSeek、Gemini、本地 Ollama 等任意模型，没有供应商锁定。

对追求「数据主权」和「成本可控」的团队，OpenCode 是 Claude Code 的开源替代品。

5.4 三者协同：完整生态图景

┌─────────────────────────────────────────────────────┐
│ Agentic Engineering 时代 │
├─────────────────────────────────────────────────────┤
│ 工具层 Claude Code / OpenCode / DeepSeek Harness │
│ ↓ ↓ ↓ │
│ 协议层 MCP 协议（工具接入） Skills（能力封装） │
│ ↓ ↓ ↓ │
│ 协作层 SubAgent（任务分工） OpenClaw（IM 团队） │
│ ↓ ↓ ↓ │
│ 规格层 OpenSpec（做什么） Superpowers（怎么做） │
└─────────────────────────────────────────────────────┘

这四个层级共同构成了 Agentic Engineering 的完整生态：工具层提供入口，协议层定义边界，协作层解决分工，规格层约束质量。

六、未来展望：AI 编程的下一个范式

站在 2026 年中回看，AI 编程已经走完了三次范式迁移。下一个范式会是什么？

6.1 短期（2026-2027）：Agent Harness 标准化

未来 1-2 年，Harness 会出现事实标准——就像 HTTP 之于 Web、SQL 之于数据库。预计会出现：

• Harness 规范文件（类似 AGENTS.md 的标准化版本）
• Harness 评测基准（类似 Terminal Bench，但专门测 Harness 质量）
• Harness 工具链（可视化编辑器、性能分析器、调试器）

DSH 的「一切皆插件」如果成功，可能成为下一代 Harness 的事实标准——就像 Linux 内核之于操作系统。

6.2 中期（2027-2030）：AI Native 应用爆发

当 Harness 足够成熟，AI Native 应用会大量涌现——它们不是「传统应用 + AI 增强」，而是从一开始就是为 AI 协作设计的应用：

• 数据层：原生支持 AI 写入和查询（如向量数据库成为一等公民）
• 接口层：原生支持 AI Agent 调用（如 MCP 成为默认协议）
• UI 层：原生支持 AI 协作（如 Command Palette + 自然语言混合输入）

6.3 长期（2030+）：代码不再是瓶颈，护城河回归「Vibe」

当代码生成成本趋近于零，真正的护城河是「Vibe」——品味、意图、判断力。

「The vibe is the moat」（Vibe 才是护城河）

这意味着未来程序员的核心能力会彻底重构：

• 编码能力：依然重要，但不再是稀缺品
• 架构能力：判断什么值得做、怎么做得对、边界在哪里——这是 AI 暂时无法替代的
• 沟通能力：理解用户真实需求、把模糊意图翻译成清晰 Spec——这是 Vibe Coding 的核心
• 审美能力：在「代码不再昂贵」的时代，品味决定了产品的上限

Karpathy 2025 年的「Vibe Coding」乍听像技术退步（不写代码了），但 2026 年的共识显示：这是对「什么是稀缺品」的重新定义——当执行不再稀缺，判断、品味、意图就成了新护城河。

总结

这一章从宏观视角回顾了 AI 编程的三次范式迁移：

每一次迁移都是主导权的逐级交接——从「人写 AI 补」到「人描述 AI 写」再到「AI 主导人监督」。

Vibe Coding 五步法（Pick → Describe → Iterate → Test → Ship）和提示词五条铁律是个人生产力的放大器，但生产级代码必须靠 Harness Engineering 来兜底。Harness 五大组件（Context / TDD / 架构 / Sandbox / Entropy）和 DeepSeek Harness 的「一切皆插件」理念共同构成了 Agentic Engineering 的方法论与基础设施。

未来 5 年，Skills + CLI + MCP 三件套协同 + Harness 标准化 将成为 AI 编程的主战场。代码不再是瓶颈，Vibe（品味 + 意图 + 判断力）才是新的护城河。

下一篇

下一篇：第 10 章 Vibe Coding 实战 — 单人+AI 做出商业级微信小游戏 — 用真实案例展示 Vibe Coding 的「个人生产力放大」价值，看单人+AI 如何完成开发+上架+变现全流程。