

当直觉驱动的代码生成遭遇合规、复杂与长生命周期的企业系统，架构师的位置在哪里？

### 1 两种范式的碰撞

Vibe Coding 这个词由 Andrej Karpathy 在 2025 年 2 月提出，一年内进入柯林斯词典年度词汇。它的核心定义是：用自然语言描述意图，让 AI 生成代码，开发者通过运行而非阅读来验证结果。

> Fully give in to the vibes, embrace exponentials, and forget that the code even exists.
> — Andrej Karpathy, 2025

这是一种速度优先的开发范式。原型在几分钟内出现，功能在几小时内迭代，开发者的注意力从"如何实现"转向"想要什么"。对于 to C 产品、内部工具、原型验证，这是一次生产关系的释放。

但 To B 大型业务系统处在另一个世界。

**To B 系统的基本特征**：需求来自多个利益相关方且经常相互矛盾，系统需要与十几个甚至几十个存量系统集成，数据安全和合规是刚性约束而非事后补充，系统生命周期以十年为单位计算，维护成本远高于初始开发成本。

**Vibe Coding 的逻辑：**速度优先，快速迭代 / 直觉驱动，运行验证 / 局部最优，逐步逼近 / 代码是副产品，功能是目的 / 个人或小团队效率

**To B 架构的逻辑：**稳定优先，谨慎变更 / 设计驱动，全局一致 / 全局最优，长期演进 / 代码是资产，理解是前提 / 大规模团队协作

这不是"新旧交替"的简单叙事。Vibe coding 不会自然地"升级"为企业级开发能力。两者的底层逻辑存在**结构性冲突**，这些冲突不会因为 AI 能力的提升而自动消解——它们会以更隐蔽的方式累积，直到某个临界点爆发。

以下是七个具体的困境。没有解决方案，只有问题本身。
![Gemini_Generated_Image_kww12dkww12dkww1.jpeg](https://developer.qcloudimg.com/http-save/yehe-2177732/fe2ea9b040d91b751ecfd7c54d8e0841.jpg)

### 2 七重困境

**01 架构知识的隐性化**

架构设计的核心产出不是代码，而是决策。为什么选择这个服务边界？为什么用关系型数据库而不是时序数据库？为什么这里需要异步解耦？这些决策及其背后的权衡，构成了系统的"架构知识"。

在传统开发模式中，架构知识通过设计文档、代码评审、方案讨论等方式显性化，并在团队中形成共识。Vibe coding 改变了这个过程：开发者描述需求，AI 直接生成实现方案。架构决策被包裹在生成的代码中，没有显式的决策过程，也没有权衡记录。

**代码有了，决策没了。**AI 生成的代码可以跑通，甚至跑得很好。但为什么是这个结构？为什么用了这个模式？这些问题的答案不存在于任何地方——AI 没有记录决策过程，开发者因为"vibe"而没有深究。系统的架构知识从显性资产变成了隐性直觉。

To B 系统的生命周期通常在十年以上。十年后，当系统需要重构、迁移或应对新的业务场景时，后来者面对的是一堆"能跑但不知道为什么这么跑"的代码。**架构债务不是技术债务的子集——它是技术债务的母集**，因为它决定了技术债务能否被识别和偿还。

**02 全局一致性的瓦解**

To B 大型系统的架构质量，很大程度上体现在一致性上：数据模型的命名一致、接口风格的规范一致、错误处理的模式一致、跨模块的交互协议一致。一致性不是审美问题，它直接决定了系统的可维护性和扩展成本。

Vibe coding 是局部优化的。每一次 prompt 都是对一个具体问题的响应，AI 生成的代码在局部是合理的，但它不知道系统其他部分的约定。十个开发者用 AI 写十个模块，可能出现十种不同的架构风格、五种数据访问模式、三种错误处理方式。

有人会说："我们可以在 prompt 里加入编码规范。"这能解决命名和格式层面的问题，但解决不了架构层面的一致性。架构一致性的核心是**决策的一致性**——什么时候用策略模式，什么时候用事件驱动，什么时候应该引入抽象层。这些决策依赖对系统全局的理解，而不是一个模板。

**局部最优的总和 ≠ 全局最优。**每个模块在 AI 生成时都是"最优解"，但拼在一起可能是一团乱麻。因为局部决策时缺少全局上下文——不知道相邻模块怎么设计的，不知道半年前做过什么决策。架构的价值恰恰在于处理这些跨时间、跨模块的协调问题。

**03  技术债务的加速累积**

技术债务不是新问题。但 vibe coding 改变了技术债务的产生速度和隐蔽程度。

GitClear 对 2020-2024 年 AI 辅助开发的纵向分析显示：代码重构比例从 25% 下降到不足 10%，代码重复增加了四倍，"代码 churn"（合并后不久被重写的代码）翻了一番。另一项研究指出，到 2027 年，AI 生成的代码将累计贡献 **1.5 万亿美元**的技术债务。


| | | | |
|:-:|:-:|:-:|:-:|
|指标|人工开发|AI 辅助开发|变化|
|代码重构比例|~25%|<10%|↓ 60%+|
|代码重复率|基准|×4|↑ 300%|
|代码 churn 率|基准|×2|↑ 100%|
|开发速度（原型）|基准|×3-10|↑ 200-900%|

对 To B 系统来说，技术债务的利息是复利计算的。系统越老，债务越多，修改成本越高，越不敢改，债务继续累积——这是一个正反馈的死循环。Vibe coding 让这个循环的起点速度加快了数倍，但没有改变循环的方向。

更隐蔽的问题是：AI 生成的代码看起来质量不错。变量命名规范，结构看似合理，注释也有。这导致技术债务更难被及时识别——它以**"架构不一致"、"抽象层次混乱"、"边界划分随意"**的形式潜伏着。

**核心矛盾：**Vibe coding 把开发的成本前移了——写代码更快了，但理解代码、维护代码、演进系统的成本后移了，而且总量更大了。To B 系统的成本结构中，维护占 70% 以上，所以这个"前移"对 To B 来说可能是净损失。

**04  领域知识的代际流失**

To B 系统的复杂度本质上是业务复杂度。ERP、CRM、供应链、财务——这些领域的知识沉淀在代码中，也沉淀在开发者的头脑里。老员工为什么重要？不是因为他们写代码快，而是因为他们知道"这个字段为什么要留三位小数"、"这个判断条件是为了应对 2018 年的那次监管变更"。

Vibe coding 改变了知识传递的方式。以前，一个新人要通过读代码、改 bug、做需求来逐步理解业务领域。现在，他可以直接让 AI 生成代码，不用深入理解业务逻辑也能交付功能。

短期看，效率提升了。长期看，**理解系统的人越来越少**。

**从"理解后修改"到"修改后验证"。**Vibe coding 的工作模式是：描述需求 → AI 生成 → 运行验证。这个闭环中没有"理解"这个环节。对于 To B 系统，当问题出现在两个模块的交界处、出现在业务规则的例外情况时——没有领域理解的开发者根本不知道该向 AI 描述什么。

这不是一个"年轻人不努力"的问题，而是一个激励结构问题。如果靠 vibe coding 就能完成 80% 的日常工作，为什么还要花时间去啃那些复杂的业务逻辑？但 To B 系统真正困难的是剩下的 20%——那些边缘场景、历史包袱、跨系统纠缠的问题。

当最后一批理解系统的人离开后，剩下的代码和文档就是一个黑箱。AI 可以在黑箱上继续叠加功能，但没人知道下面是什么。

**05  安全与合规的责任真空**

To B 系统，尤其是涉及金融、医疗、政务的系统，面临严格的合规要求：数据不能泄露，操作必须可审计，权限必须最小化，变更必须可追溯。这些不是最佳实践，是法律要求。

Vibe coding 在合规层面引入了两个新问题。

第一是**代码来源的不可追溯性**。AI 生成的代码可能来自训练数据中的某个开源项目，而那个项目的许可证可能与你的项目不兼容。合规审计要求每一行代码的来源都是清晰的，但 AI 生成的代码没有来源。

第二是**安全漏洞的隐性引入**。AI 生成的代码在功能层面是正确的，但在安全层面可能有缺陷。SQL 注入、XSS、权限绕过——这些问题在"跑通"的验证中不会暴露。而 vibe coding 的工作流中，安全测试往往是滞后的，甚至是缺失的。


| | | |
|:-:|:-:|:-:|
|合规要求|传统开发|Vibe Coding|
|代码可追溯|代码评审 + 版本历史|AI 生成，来源不可追溯|
|安全审计|设计阶段考虑 + 代码审查|功能验证优先，安全滞后|
|责任归属|开发者 → 团队 → 组织|AI 生成 → 谁负责？|
|许可证合规|依赖审查|训练数据中的许可证边界模糊|

更深层的问题是责任归属。如果 AI 生成的代码导致了数据泄露，谁负责？写 prompt 的开发者？审核代码的人？提供 AI 工具的厂商？目前法律没有明确答案。对于 To B 企业来说，这种不确定性本身就是合规风险。

**06  系统集成的复杂度爆炸**

To B 系统几乎从来不是孤立存在的。一个典型的中大型企业，内部有 ERP、CRM、OA、HRM、财务系统、数据分析平台……新系统需要和这些存量系统对接。系统集成占 To B 项目工作量的 30%-60%，是主要的成本和风险来源。

Vibe coding 擅长从零开始生成一个独立系统。但它不擅长处理"在已有十个异构系统的环境中加入第十一个系统"这种问题。因为集成的难点不是写代码，而是理解每个系统的接口约定、数据模型、异常处理、性能特征。

**AI 不知道你不知道什么。**集成项目的最大风险是"未知的未知"——你不知道对方系统有什么隐性约定，不知道它的历史包袱。Vibe coding 可以基于你描述的接口生成对接代码，但它无法发现你没提到的那些坑。而 To B 集成项目的大部分工作量，恰恰来自这些坑。

还有一个结构性问题：Vibe coding 降低了开发门槛，意味着更多团队会构建更多系统。每个团队都可以用 AI 快速搭建自己的小工具、小系统。结果是企业内部的系统数量加速增长，系统间的集成需求呈 **O(n²) 增长**，整体复杂度爆炸。

这就是"AI 生产力悖论"在企业级的体现：个体效率提升了，但系统整体的协调成本上升得更快。

**07  架构师的角色危机**

最后一个困境是关于人的——架构师这个角色，在 vibe coding 时代应该做什么？

传统架构师的工作内容包括：技术选型、方案设计、代码评审、规范制定、疑难问题解决。这些工作中，相当一部分是"判断 AI 生成的代码对不对"、"告诉 AI 应该用什么技术"。这不是一个可持续的定位——如果架构师的价值只是给 AI 把关，那 AI 越强大，架构师越边缘化。

真正的问题是：当代码可以被快速生成时，**架构的稀缺性在哪里？**

答案可能在两个方向。一个是"向上走"——更多地理解业务，理解战略，把技术能力和业务目标对齐。另一个是"向下沉"——更深入地理解系统的底层原理，处理 AI 搞不定的复杂问题。但这两个方向都需要时间积累，不是靠工具切换就能完成的。

**未回答的问题：**如果说以前的架构师是"设计师 + 工匠"，那在 AI 时代，工匠的部分被替代了，剩下的设计部分是否足以支撑一个独立的角色？还是说，架构能力会变成每个开发者都应该具备的基础素养，而不再有专门的架构师？这个问题没有标准答案，但每个 To B 技术团队都需要面对它。

### 3 困境的根源

这七个困境不是孤立的。它们有共同的根源——**两种时间观的冲突**。

Vibe coding 的时间观是**即时的**。关注当下的问题，快速给出答案，迭代逼近目标。它优化的是"从想法到可运行代码"的时间，以分钟和小时计算。

To B 架构的时间观是**长期的**。关注三年后系统能不能扩展，五年后能不能迁移，十年后能不能维护。它优化的是系统全生命周期的总成本，以年和十年计算。

这个断层不会因为 AI 变得更聪明而消失。因为问题不在 AI 的能力，而在于**优化目标的根本差异**。一个优化短期交付速度的工具，不能自动解决长期架构质量的问题。

更棘手的是，vibe coding 的收益是即时可见的——今天用了，今天就更快。而它的代价是延迟兑现的——半年后、一年后、三年后才会逐渐显现。在大多数企业的激励机制下，当下的收益比未来的代价更有分量。

### 4 没有答案的问题

这篇文章不提供解决方案。不是因为没有解法，而是因为任何简单的答案都会误导。

"加强代码评审"——说起来容易，但 AI 生成的代码量大、结构复杂，评审成本比手写代码更高。

"制定更严格的规范"——规范只能约束已知的问题，而 AI 会制造新的、超出规范预期的问题。

"架构师负责设计，AI 负责实现"——听起来合理，但架构设计如果脱离了实现细节，很快就会变成纸上谈兵。

真正的答案可能在这些问题之中：

• 在 AI 可以生成大部分代码的时代，架构设计的产出物应该是什么？

• 如何衡量一个 To B 系统的"架构健康度"，并将其纳入研发效能指标？

• 当代码的生产成本趋近于零时，软件的价值在哪里？

• 在"能跑就行"和"完美设计"之间，To B 系统的平衡点在哪里？

• 十年后，我们今天用 vibe coding 写的系统，会被怎样评价？

这些问题没有标准答案。但它们是每个 To B 架构师都需要思考的。

Vibe coding 不会杀死架构师。但它会淘汰那些只做"代码质量把关"的架构师，留下那些能处理 AI 搞不定的问题的人——只是，我们还不确定那些问题具体是什么。

Vibe Coding 这个词由 Andrej Karpathy 在 2025 年 2 月提出，一年内进入柯林斯词典年度词汇。它的核心定义是：用自然语言描述意图，让 AI 生成代码，开发者通过运行而非阅读来验证结果。

Vibe Coding 时代To B 架构的七重困境

当直觉驱动的代码生成遭遇合规、复杂与长生命周期的企业系统，架构师的位置在哪里？

架构设计

编程语言

职业发展

Vibe Coding与ToB架构的碰撞揭示AI开发新困境：速度优势与系统稳定性冲突，引发架构知识隐性化、全局一致性瓦解、技术债务加速等七大挑战。文章剖析AI辅助开发对传统架构师角色的冲击，探讨长期系统演进中的关键平衡点，为理解AI时代企业级开发提供深度思考。

2026上云采购 | AI焕新·智启新局

ctsdb

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Vibe Coding 时代To B 架构的七重困境-腾讯云开发者社区-腾讯云

Vibe Coding 时代To B 架构的七重困境

Vibe Coding 时代To B 架构的七重困境

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐