Vibe Coding 之后,软件工程还在吗?

先说核心观点，可能有点反直觉：

1.1 每次抽象层提升，都是「谁来管细节」的重新分配

回看编程七十年的历史，你会发现一个清晰的模式：工具接管的东西一直在向下沉，人负责的东西一直在向上走。

汇编写成高级语言，编译器接管了寄存器分配和指令调度，但人开始负责数据结构和算法；框架时代到来，脚手架接管了路由、状态管理和构建，但人开始负责业务建模和性能治理。每一次抽象层提升，被「省掉」的都是重复性劳动，被「放大」的都是判断力。

今天轮到自然语言了。语法、样板代码、重复 CRUD、甚至整个模块的实现，都可以交给编程 Agent。但「谁都不管」的层，从来不存在。

更重要的是：抽象层越高，单人单位时间的信息产出量就越大，单点错误的破坏半径也越大。汇编时代写错一行，崩的是一个函数；今天一句被误解的 prompt，崩掉的可能是整个模块的架构。所以人不是「可以不审」，而是必须换一种方式审 —— 从语法级的逐行检查，上移到意图级、架构级的审核与调试。

1.2 工程量没有消失，只是换了位置

传统开发里，「实现编写」占掉大部分精力（可粗略示意为六成）；AI 协作模式下，实现被 Agent 大幅压缩，而「意图定义」和「验证审核」明显膨胀 —— 下面的图是一个粗略的比例示意，不是精确统计数据。

这不是错觉，行业数据也在说同一件事：

有意思的是，Karpathy 本人在一年后也修正了自己的说法：AI 编程 Agent 正在成为默认的专业工作流，但前提是「有更多监督内建其中」，他给这种新模式起了新名字 —— Agentic Engineering。连造词的人都这么说，这场争论其实已经结束了。

1.3 每次变革，淘汰的都是拒绝更新抽象层认知的人

「不学新东西的人会被淘汰」，这话在每次技术变革时都会被说一遍，而每次都应验。但更准确的说法应该是：

注意，这里说的「驾驭」，不是「会用工具生成代码」这么简单。生成代码的门槛正在快速趋近于零，真正稀缺的能力是：把模糊需求翻译成清晰约束、给 AI 搭好上下文、用工程化手段验证它的产出、并且在它犯错时快速定位归因。这四件事，恰恰是软件工程最核心的部分。

所以，Vibe Coding 的正确姿势从来不是「躺平让 AI 写」，而是 Vibe + Engineering：人做「验收官」和「约束设计者」，AI 做「不知疲倦的实现者」。软件工程还在，只是换了一种在场方式。

2.1 现状：Agent 平台已经全面开战

如果只看今年的产品动态，会发现所有大厂都在朝同一个方向冲刺 —— 多 Agent 协作。

字节在 2026 年 8 月发布「豆包工作」，主打多 Agent「工作小队」分工；同一场发布会上，飞书 8.0 为 Agent 做了系统性重构，并发布了官方称为「国内首个团队智能体」的「豆包工作伙伴」—— 它拥有独立身份、权限和记忆，能像同事一样加入群聊，记住群聊、文档和会议内容，积累并复用团队经验（目前处于与企业定向共创阶段）。同一时间，腾讯的 WorkBuddy 也在推进多窗口多 Agent 并行，背后是超 7 万种技能的 SkillHub 生态、30+ 连接器和多模型自由路由。编程工具这条线上，Claude Code 的子智能体、CodeBuddy 的 SPEC 规范流程、Trae 与 Qoder 的快速迭代，走的也是同一条路。

2.2 本质：Agent 开发，就是编排喂给模型的输入

听起来很玄的多 Agent 开发，拆开看骨架其实非常朴素。一个公式：Agent = 模型 + 循环 + 工具 + 上下文。模型本身只做一件事 —— 根据当前收到的上下文，预测下一步动作。真正拉开产品差距的，是模型外面那一圈「输入编排层」：

▍Rules（规则）：角色设定、技术栈约束、输出格式，每次会话都加载，相当于给模型立规矩；▍Memory（记忆）：项目约定、历史决策、踩过的坑，跨会话持续累积；▍Skills（技能）：把验证过的流程封装成 SOP，一次沉淀、按需触发 —— 2025 年 12 月已被发布为开放标准，微软、OpenAI、Cursor 等相继采纳；▍MCP（工具）：统一协议接上设计稿、接口、数据库这些实时系统，让模型摸得到真实世界；▍Sub-agent（子智能体）：把复杂任务拆给不同角色的 Agent 分头处理再汇总 —— 这就是「多 Agent」的全部秘密。

这五样东西没有一样是「模型内部的能力」，全是模型外部的输入工程。所以行业里有个越来越流行的说法：别再卷 Prompt Engineering 了，真正值钱的是 Context Engineering（上下文工程）—— 在什么时机、把什么信息、以什么形式喂给模型。同一个模型，喂的东西不同，产出可以差出十倍。

2.3 落到编程场景：Agent 选型没有最强，只有最合适

过去一年，主流的编程 Agent 基本都在真实任务里跑过一轮。既然各家底层同构，选型就别看排行榜，看四个硬指标：

几个关键体感：Claude Code 被业界普遍视为 Agentic 工作流的事实标准之一，CLI + Skills + Hooks + MCP 体系最完整，它「用规则文件约束 AI」的整套设计是搭建知识仓的主要参考，短板是海外网络与订阅门槛；Cursor 是 IDE 体验天花板，Tab 补全至今没有对手，但企业级管控偏弱；国产阵营各有所长 —— Trae 靠「免费 + 中文友好」适合零成本起步，CodeBuddy 的 SPEC 规范驱动流程与重流程团队最同频，通义灵码胜在企业私有化部署成熟（代码不出内网，需企业版支持），Qoder 是国内认真对标 Claude Code 的新势力。

用了一年多 AI 编程，最大的心得是一句话：Agent 的产出上限由模型决定，产出下限由你给的上下文决定。同一个模型，在有知识仓的仓库里干活和在一个裸仓库里干活，产出质量完全是两个世界。

3.1 团队 AI 协作的三种方式

方法论落地之前，先看团队协作层面的现状。目前主流的团队 AI 协作方式有三级，差别不在模型能力，而在三件事：上下文放在哪、谁能共享、归谁管。

▍方式一：仓库层 —— 随 Git 走，克隆即生效。把 rules（统一代码规范，每次任务自动加载）、skills（项目专属能力）、commands（高频斜杠命令）放进代码仓库、随 Git 走，谁克隆谁生效，规范变更走 PR 评审。零平台依赖、版本化管理，起步成本最低。局限也明显：只覆盖单个仓库，任务协作、资产复用、组织度量都管不到。

▍方式二：项目层 —— 云端协作阵地。在仓库层之上，把上下文从个人搬进项目空间：项目指令对所有任务自动继承，不用每次重复交代背景；项目资产库通过 RAG 注入上下文，需求文档、领域知识随取随用；任务分享 / 流转时产物带着上下文移交，接手的人（和接手的 Agent）不用从零理解。局限是边界仍是一个项目，跨项目的公共知识难以复用。

▍方式三：企业层 —— 组织级管控。再往上一层，面向整个组织：Skill 下发策略用白名单 / 黑名单控制哪些能力全员可用、哪些仅限特定团队；自定义指令全组织统一调用，好用的经验不再锁在单个项目里；研效度量（补全生成率等指标）让管理层第一次看清 AI 的真实产出。局限是知识沉淀在平台侧，与代码仓库形成两套真相。

三层是递进关系，不是三选一。但如果把三层的能力要求合起来看 —— 规范要版本化、资产要共享、能力要管控 —— 会发现它们其实可以不依托任何平台，而是收进一个自己持有的仓库。这就是接下来要讲的「单仓库知识仓」。

3.2 单仓库知识仓：把三层能力收进一个仓库

单仓起步和知识仓本质是同一条路的两步：起步时只放 rules / skills / commands（对应仓库层）；走稳之后，把散落在群聊、Wiki、平台资产库里的需求文档、接口契约、设计规范、组件、经验，也全部收拢进同一个 monorepo —— 这就是 「AI 协作知识仓」。它同时服务人和 Agent：人查文档不再翻聊天记录，AI 读上下文不再靠猜。

▍知识层 —— AI 的长期记忆。需求文档（prd/）、接口契约（api/，OpenAPI 格式）、数据字典（data/，表结构、字段说明与关联关系）、设计规范（design/）同仓同源，前端、后端、数据读的都是同一份真相。没有这一层，AI 每次任务都在「失忆状态」下猜你的业务 —— 猜错一次，返工一天。

▍能力层 —— AI 的手脚。组件库（packages/ui）除了代码，还带 props 元数据，AI 能精确知道每个组件怎么用，而不是自己造轮子；.ai/skills/ 里放可执行的工作流（发布流程、联调步骤、兼容性测试清单）；.ai/memory/ 里沉淀项目记忆和踩坑记录 —— 这是最容易被忽视、复利又最高的部分，后面细说。

▍约束层 —— AI 的围栏。.ai/rules/（AGENTS.md / CLAUDE.md / Cursor Rules）限定 AI 能改什么、遵循什么；standards/review/ 里的评审清单给人用 —— AI 的每次产出，人按清单逐项审核，不看感觉看清单；再配 CI 门禁做最后兜底。

3.3 MCP：给 AI 装上四类感官

知识仓解决「AI 懂不懂业务」，MCP 解决「AI 连不连得上真实世界」。模型有个硬伤：它看不见的东西，就只能靠猜 —— 猜页面长什么样、猜接口字段、猜表结构。所以接 MCP 的思路很简单：研发决策依赖哪份真相，就把哪份真相接进上下文。按这个思路捋下来，是四类：

▍设计侧 —— 视觉真相（Figma / MasterGo MCP）。让 Agent 直接读设计稿的 DSL（结构化设计数据）：图层树、布局结构、设计 Token、组件定义。生成的页面代码，色值间距直接来自设计变量而不是截图目测，组件直接映射到自有组件库的 props，还原度大幅提升。尤其是 MasterGo 对国内团队更友好，MCP 已能把画布深度开放给模型做读写 —— 按自然语言生成页面、修改图层，还能把本地代码与画布做差异比对（团队版及以上可用）。

▍接口侧 —— 契约真相（OpenAPI / YAPI / Apifox MCP）。「读」：AI 拿到接口契约，自动生成 TS 类型、请求函数和 Mock 数据，字段命名与后端同源，联调返工明显减少；「写」：联调中发现的契约变更，由人审核后回写接口文档 —— 文档永远不再滞后。

▍数据侧 —— 数据真相（MySQL / PostgreSQL / 数仓 MCP）。这是最容易被忽略、对全栈交付却最关键的一类。AI 改后端最常犯的错是「凭空造表结构」：字段名靠猜、类型靠猜、关联关系靠猜，生成的 SQL 和实体类看着合理，一跑就崩。数据库 MCP 让 Agent 直接读 schema —— 表结构、字段类型与注释、索引、外键关系，再配一份脱敏的样本数据。于是它写下的每一条 SQL、每一个实体类、每一份 ORM 映射，都是「查出来的」而不是「猜出来的」。典型用法四类：读数据字典，需求评审时就能判断改动影响面；校验 SQL，先 explain 再执行，在测试库验证结果集；生成数据模型，实体类、DTO、迁移脚本草案的字段命名与库表同源；排查数据问题，报错进上下文后直接查预发库定位，不用再「找 DBA 导数据 → 手动比对」。

▍运行侧 —— 运行真相（浏览器 / 日志 / 流水线 MCP）。前三类解决「写对」，这一类解决「跑通」，也最直接呼应第一章的判断 —— Agent 不该只交代码，还应该先自己跑一遍。浏览器自动化 MCP（Chrome DevTools / Playwright）让 Agent 真实打开页面、点击、填表单，读 console 报错、抓 network 请求、比对样式，改完不用等人验收，它自己先跑一遍、把报错和截图一起交回来；日志与流水线 MCP 让 CI 失败时 Agent 直接读构建日志、定位到具体哪一行，线上报错时结构化堆栈直接进上下文，不用人从截图里手抄。它的价值在于把「验证」拆成两半：机械性的自检交给 AI，判断性的验收留给人 —— 人的位置从「逐行调试」上移到「判断决策」，这比单纯提速更有意义。

四类之外，还有需求管理（TAPD / Jira）、代码仓库与 CI、IM 协同等 MCP，按实际链路选择性接入，不必贪全。落地节奏上，建议从只读、低风险的设计侧与接口侧开始，闭环跑顺了再碰数据库与运行环境这两类权限敏感的 —— 能力开放的节奏，要跟着权限收敛的能力走。

3.4 为什么说 Node 全栈在 AI 时代更吃香

单仓库知识仓要发挥最大威力，有个隐含前提：前后端的知识能对齐。接口契约、类型定义、工具链如果分裂在两套技术栈里，AI 的上下文就要维护两份。这不是语言信仰之争，而是上下文效率之争 —— 而 Node 全栈恰好把这个成本压到最低。

挑两点最关键的展开。一是「类型即契约」。接口契约（OpenAPI）自动生成 TS 类型，前后端共用同一份定义 —— 字段一改，编译期就报错。这意味着 MCP 回写的契约变更、AI 改的接口，其正确性由类型系统兜底，人审的工作量大幅下降。

二是「组织形态的杠杆」。上下文同源 + 工具链统一，意味着一个工程师带着 Agent 就能覆盖「改接口 → 改服务 → 改页面」的完整链路，一个人就是一个全栈小队。AI 时代团队规模的意义在重新定义，全栈能力的性价比从未这么高过。

当然，这不等于鼓吹所有后端都迁到 Node。存量 Java / Go 服务没必要动，更现实的路径是：主后端保持稳定，用 Node 做 BFF 和工具层，把「面向前端的多变部分」收到 AI 最擅长、迭代成本最低的技术栈里。

3.5 人机协作闭环：AI 提速，人掌舵

把前面所有东西串起来，就是实际运转的协作闭环。六个节点里人有三个，而且都卡在最关键的位置上：

特别要强调第 6 步 —— 踩坑沉淀回仓。大多数团队的 AI 转型死在这里：AI 犯过的错没有沉淀，同一个坑换个同事再踩一遍；好用的 prompt 和工作流散落在个人对话里，人走了经验就清零。把每次返工的根因写回 memory，把验证过的操作序列固化成 skill，让每一次踩坑都变成团队的永久资产。这就是 AI 时代的知识复利。

至于度量，原则是：不看 AI 代码行数占比这种虚荣指标，看需求交付周期、缺陷密度和返工率。毕竟交付价值才是目的，AI 只是手段。

如果这篇文章对你有启发，欢迎点赞、在看、转发给你的技术搭子 👋