随性编程(Vibe Coding )

1,  随性编程（Vibe Coding）的背景

当前软件开发环境正在发生深刻变革。开发者不仅需要编写代码，更需以创造性和直观的方式解决问题。在此背景下，一种名为 “随性编程（Vibe Coding）” 的新理念应运而生。

传统开发强调严谨规划与结构化方法，但快速迭代的技术趋势和用户需求要求开发者采用更灵活、适应性更强的方法。Vibe Coding 正是响应这种需求而诞生的一种开发实践。

近年来，如何在生产力和创造力之间寻求平衡已成为开发者社区的热点话题。随着越来越多的开发者遭遇职业倦怠并丧失编码热情，Vibe Coding 作为一种让开发过程既愉悦又高效的方法，正受到广泛关注。

在本文介绍的业务能力工厂项目中，我们尝试运用 Vibe Coding 方法扩展一款价值百万美元软件的功能，旨在体验这种新方法的成熟度并评估其实际适用性。

 

2. 业务能力工厂项目（Capability Factory Dreamer）的开发阶段介绍

目的： 基于最新人工智能技术，利用数字孪生（公司业务模式的数字化表达）的本体模型，研发能够自动执行业务的操作系统，为将来能够实现企业的自主式运营奠定基础。

目标： 企业自主性 – 相当于自动驾驶第三级（作为本项目首次迭代的目标），目标是通过具有超强能力的智能体自动执行业务，以最大限度减少人工干预。

• 自主执行业务创新

• 自主研发业务解决方案

• 自主完善业务模型

• 自主执行业务流程

• 端到端需求管理自动化及 IT 开发/运维自动化

下图展示了全局视图，图中左边部分展示的是已经产品化的SOLVENT平台。SOLVENT平台的目标是帮助企业构建基于本体模型的数字孪生体系，用以实现业务转型与业务建模。借助平台能够用数字化的方式定义公司所有的业务及工作流，以及与企业业务相关的所有元素的定义、元素之间的关系，以及业务涉及的所有方式方法都能得以清晰的界定。目前已在国际性企业应用，欢迎访问Business Model Governance-BMG公司网站（http://www.bmgovernance.com） 获取更多资讯。

图-1 平台配置全局视图与Vibe Coding 应用区域（黄色区域）

图中右侧黄色区域则是运用 Vibe Coding 的大胆尝试。即本文所提及的“业务能力工厂”Dreamer软体项目，业务能力工厂连接IT系统并通过向LLM提供语境，让智能代理人自动完成企业的业务流程。其中关键组成有：

• 模型上下文协议 (Model Context Protocol-MCP)，负责为 LLM 提供执行企业业务流程所需的上下文语境；

• 检索增强生成系统 (Retrieval Augmented Generation-RAG)，通过将企业各部门能力向量化，而提供企业特定的专属知识；

• LLM大语言模型整合接口，可以支持智能体有选择地使用特定LLM，发挥特定LLM模型的优势；

• 指挥控制组件负责协调智能体间的协作；

• 以及流程引擎，负责整合协同所有组件，产生实际的业务价值。

Dreamer的客户端是Visual Studio Code(VS Code) 的扩展应用。 IT 开发工作本身就是一个遵循工作流（即方法论）的过程，经过这个工作流创建出来的应用程序应该是可以在 VS Code IDE 环境中执行的，所以采纳了VS Code的扩展程序，并且可以与 GitHub 等工具无缝集成。

图-2 监控业务能力活动

首次尝试便挑战采用Vibe Coding的编程方式构建如此规模的系统，可谓大胆（甚至略显鲁莽）。整个项目历时两个月，设计调研耗时一月，开发时长一月。期间历经数十次濒临放弃的困境，在不断的试错、失望与重燃希望中前行。

图-3 统一的代理模型和业务本体

本项目关键创新之一是强大能力的智能体代理人（AI Agent）。代理是特定专业角色的数字化化身，具备执行流程所需的基本能力，其核心能力包括：

• 知识与流程掌握：理解任务相关的知识及处理流程。

• 规划与推理能力：能够按需求规划并制定方案。

• 精细化执行：能够掌握执行任务所需的详尽操作步骤和必要工具。

• 上下文共享：能够根据需要，与现有系统或外部系统共享上下文。

• 实时协作：能够与其他代理实时交互协同。

  这些强大专业能力的高能代理(Higer Competency体现了实际工作中的各类专业人士，是执行任务所需的各类专家角色的实例化（代理人是根据本体模型-Ontology中具有的详细角色描述和职责来创建）。

业务能力工厂是自动执行企业数字孪生的本体模型而自动生成的系统，成为直接基于数字化企业的数字孪生本体（Digital Twin Ontology）执行业务创新和业务模式的系统，凭借其强大的能力，它们本质上构成了能够在完全虚拟环境中自动运行企业的操作系统（OS）——您可将其理解为企业的操作系统。，用户可以通过此操作系统提供的客户端监控流程的执行情况以及执行结果。欢迎通过 YouTube 了解演示视频（业务能力工厂–梦想家）

图-4 智能体代理知识库

本项目架构中的另一关键点是智能体代理知识库（Agent Knowledge Base）。

首先，如前所述，打造“高能”（Higer Competency）代理需要丰富的场景化知识及强大的规划和推理能力。最终，自动化构建了领域专家语言模型（Expert Language Model）。构建该模型所需的所有信息，均来自数字孪生（Digital Twin）中业务创新和业务模型实践的积累，并通过专门的知识管道汇聚而成。以金融机构为例，包含约百种核心专业能力（Competency）的定义，并且根据需要可以定义60~70种对外能力（Capability）。

其次，知识库中要考虑的另一个维度是知识图谱（Knowledge Graph），其基础是组织的业务创新与业务模型的本体模型。业务本体（Business Ontology）兼具内生性（Endogenous内部形成）和外延性（Exogenous外部扩展），本体模型中明确定义了语法、语义及实体关系，会随业务演进动态更新。在商业语境下，与价值定义、价值创造、价值交付和价值获取相关的所有内容均被建模于图谱之中。由此形成的企业知识体系是真实的、一致的、无冗余的数字化知识，而且实现了从战略层到IT代码的关联。

在业务能力工厂的环境中，工作任务被具体化并动态分配给待命状态的智能体代理。流程中的每项任务作为工作行动而执行，并辅助以适合的工具，而来自当前系统的信息（经由模型上下文服务器 Model Context Server）或上下文语境决策/信息（经由大语言模型服务器 LLM Server）将按需进行聚合与处理。

本项目采用的主要技术（Vibe Coding）。如下

服务器环境

• 操作系统：Mac OS、苹果 M2-Max、12 核、64GB

• 编程语言：Python

• 代理对代理通信：G-RPC

• 通信协议：Web Socket

• 数据库：矢量数据库（Chroma）、图形数据库（MemGraph）、本体数据库（MongoDB）

• 基础架构模式：事件驱动架构

• 代理使用的 LLM：OpenAI-4o、Anthropic-Claude 和 Opus、Google-Gemini、Ollama-Mistral

• 开发工具：没有使用 Copilot 或 Cursor，只使用了Prompt（用于找出问题、制约因素和解决方案，之所以仅采用 API目的是实现 IT开发自动化）。

作者在开发时采用的 LLM Prompt 服务主要比例是Anthropic-Claude（约占 80%）、Opus（约占15%）、Google-Gemini（约占 5%）。Opus质量与Claude 相比差别不大，之所以使用 Opus，因其在特定时间段内允许的最大提示数较高，但性价比一般，Google-Gemini 与之类似。Claude虽有令牌限制（单个提示符可使用的最大令牌数量，包括输入和输出），但差异不大，对于一般开发而言，个人认为Claude应该足够了。

客户端环境

• 操作系统以运行VSCode：Mac OS、Windows、Unix 等

• 编程语言：HTML/CSS、Java 脚本、Type 脚本

• 执行环境：VS Code IDE 扩展（将来也可使用 Electron 或 Eclipse Theia）

参与该项目的开发人员有较专业的本体知识，但编程语言基础有限：

• 服务器的技术知识：几乎没有（有读过一本 Python 简介）经验

• 客户端技术知识: 无经验，无技术知识

• 业务本体系统知识 : 高级

• 架构思维水平：高级

• 元认知水平：高级

• 解决问题水平：高级

以上初步介绍了项目的目的和背景，下面具体了解以下Vibe Coding。

 

3. 什么是 Vibe Coding

• Claude 对 Vibe Coding 的解释

Vibe Coding 是一种开发方法，开发者信任自身的直觉与感受，并强调编码过程的流程（flow）。它不仅关注技术能力，更积极利用开发者的情绪状态和创造力。

关键在于开发者需找到自己的编码节奏与风格。如同音乐家即兴演奏，Vibe Coding 的精髓在于鼓励开发者顺其自然地编码，发现创造性的解决方案。这是一种相较于传统方法论和分析方法更有机、更直观的开发方式。

Vibe Coding 也强调开发环境与工具的个性化，鼓励每位开发者建立最舒适高效的环境，并形成独特的编码风格。这不仅是编写代码，更是将开发行为视为一种艺术表达。

• Gemini 对 Vibe Coding 的解释

“Vibe coding” 是开发者社区使用的一个新术语，由 “vibe”（氛围、感觉）和 “coding”（编码）组合而成。它指的是一种主要依赖开发者“直觉”—他们的经验与本能—而非严格、详细的预先计划或既定理论来编程的风格。它是一种感受问题整体脉络，并在解决方案浮现时自发编码的方式，如同爵士乐手无需乐谱的即兴演奏。

这个术语具有双重含义，根据使用者的经验和情况，可能具有积极和消极的含义。例如，资深开发者（“老手”）的“即兴编码”被视为多年深厚经验积累的洞察体现, 他们的直觉通常被视为一种快速高效的解决问题的能力，并常常受到人们的钦佩。反之，缺乏经验的初级开发者无计划的编码则常被视为负面行为，导致难以维护的“意大利面条式代码”或技术债。

在追求极速交付的环境中，“氛围式编码”尤其常见，多见于需要快速原型的初创公司、韩国“快速行动”文化中需要快速实现功能的公司，或协作负担较少的个人项目。当前端开发者凭“感觉”微调 UI 而无固定设计稿，或资深开发者凭直觉定位复杂 Bug 根源并修复时，也体现了 Vibe Coding。

归根结底，Vibe Coding 的成败取决于开发者经验。初级者的“直觉”可能只是有根据的猜测，而高级者的“直觉”则是数万小时解决各类问题实践中根深蒂固的模式识别结果。因此，即使编码方式看似类似，最终代码的可靠性、可扩展性和质量将因经验差异而大相径庭。

简言之，“Vibe coding” 是一个既幽默又现实的术语，表明软件开发不单单是由僵化的逻辑与工程化过程的复杂活动，有时更需要创造力与艺术天赋。它是现代开发者文化的一部分，既承认系统开发方法的重要性，也认可开发者从多年经验中获得的直观洞察力的价值。

• 本项目开发者对 Vibe Coding 的解释（经验之谈）

正如本项目实践所示，Vibe Coding 并非基于传统开发方法（无论是瀑布式还是敏捷式），即开发者根据经验和技术知识，按部就班地进行分析、设计、编码和测试（产出物）。Vibe Coding 是一种更关注待开发对象的需求即开发目标的必要性（Why），和软件应具备的能力（What）的方法，并将实现需求目标的方法（How）定义为一种与人工智能即LLM进行交互式开发的方式。

本项目的核心驱动力是通过未来可期的技术手段确保企业竞争力方法。核心观点是，无论是否期待，很快利用 AI 和机器人确保企业竞争力都会是至关重要的。因此，我们致力于，通过利用强大的 AI 和执行机器人（智能体代理），研发企业经营业务的方式-业务流程（活动工作流），以提升流程的能力，从而确保企业的竞争力。此外，如果这种方法能从元认知层面得到验证，智能体代理也将可以自主地实现业务模型创新。基于此必要性（Why），我们定义并开发了系统所需的必要能力（What）。

因此，如前所述，尽管对开发和运行环境的底层技术知之甚少或一无所知，本项目的开发者最终实现了目标。当然，过程绝非轻松。作为首次尝试，困难重重，并因 LLM 的“幻觉”问题屡次受挫。在反复试错中，我获得了丰富体验，也洞察了未来软件行业应关注的方向以及教育应如何变革等关键问题。

 

4. Vibe Coding 的特点

• 人工智能交互式开发

Vibe Coding 的核心是与人工智能协作开发。它将需求编写为提示指令，通过 LLM 服务获取预期结果。因此，编写高质量的提示（上下文+指令）至关重要。高质量输入带来高质量输出。不一致的提示会带来严重问题：起初差异微小，但随着开发深入和代码复杂度增加，差异会被放大，最坏情况是需丢弃整个代码库重头再来。

• 无固定预设产出物

目前，Vibe Coding 的基础输入尚无固定标准或强制产出物。当然，如果能提供模型通常能获得更高质量的输出，熟悉建模比如UML的开发者应加以利用。若计划仅凭提示开发，系统性地学习编写提示是明智之举（若时间允许，我将在后续文章尝试总结）。

• 迭代、增量式开发

即使最强大的 AI 也难以一次性完成开发。迭代和增量开发是基本要求，熟悉此方式的开发者会更容易上手。不限于此，掌握架构思维和重构技能的开发者将更感轻松。

• 始于原型设计作为基础起点

如前所述，Vibe Coding 本质上是交互式开发，与原型设计类似。通常（即使你本无意于此)通过创建雏形（Mock-up）并逐步细化来实现。也就是说，开发者可以简单地开始（Mock-up），欣赏雏形的完备性，感觉应用系统接近完成开发，认为只需少量优化工作。当然，若能较好地掌控过程，确实可在短时间内完成应用开发。

• “Why”、“What” 至关重要，将“How” 交由 AI 主导

一旦明确“Why”(目的)和“What”（所需内容），AI 就能快速生成简洁代码（Clean Code）。开发者无需深厚的底层技术知识即可进行开发。本项目开发者对技术基础了解甚少，但成功开发便是例证。未来，开发者应大胆让 AI 生成“How”，而将重点放在“Why”和“What”上。但需明确“How”的范畴。根据本项目经验，“How”分两种：一是已知的或是他人已实践过的；二是未知的新方法。第一种情况可放心交由 AI；第二种情况仍需依赖开发者。

 

5. 开发者如何实践 Vibe Coding

实践 Vibe Coding，开发者首先清晰理解自身需要做什么（即开发目标）至关重要。Vibe Coding 是与 LLM（AI）协作完成项目的过程。LLM 在生成结果方面确实迅速，这意味着在简单编码任务上，开发者无法与 AI 竞争。开发者真正的价值在于元认知。一旦不是局限于眼前问题，而是探究根本性问题时，AI 能成为绝佳工具。

根本性问题是指什么？ 即通过追问“为什么”（如同“设计思维”或“六西格玛”研讨会所做），理解根本需求与需交付的价值；然后通过系统思维或架构思维，理解结构性交付该价值所需的能力；再通过相互独立完全穷尽（Mutually Exclusive, Completely Exhausted-MECE）技术验证完整性；最后进行一步一步地重复上述步骤逐步推进。

逐步重复推进是指从高层级向低层级反复应用上述技巧从而展开细化。“What”与“How”的关系是层级性的——在任何层级，其下一层级总是上一级的“How”。从整体完备的结构看，“What”与“How”如同父子关系，在层级之间中反复出现。

理解这一点，可以说已掌握 Vibe Coding 的核心。

余下便是编写提示。向 LLM 清晰传达项目目标（通常 4-5 句足够，最多不超过 10 句）后，将“What”作为“Prompt”输入，LLM 便能顺畅生成“How”。关键在于理解，所生成的“How”会根据“Why”和“What”的不同呈现不同的结果。

此外，截至 今日2025.6.3 的 LLM 技术（如 Anthropic Claude Opus4, Google Gemini Pro 等）尚无法管理如本文规模的大型项目的上下文。这意味着开发者需要自己记忆下之前曾经给LLM解释过的内容，或者另外记录在笔记中。我推测在此规模下无法持续保持一致的上下文的原因，更多在于商业化服务的各种限制（如 Token 限制、调用频率限制），并非 LLM 自身的能力问题，后面我也会解释。

 

6. Vibe Coding 实践体验

事实上，最初我并未计划构建如此庞大的系统。最初的目标是建立一个“解决方案工厂”，在业务创新和业务建模平台上开发业务解决方案。此功能可以为方案设计人员汇总知识并提供数据，一般可通过 Java 编码实现。例如，针对预测客户终身价值的主题，可以借助 LLM 和本体模型获取必要的数据，并开发数据挖掘或机器学习的解决方案用以提供所需数据。这可以通过链式或树状结构完成。这些经验催生了利用 LLM、MCP、Agent、RAG 等最新 AI 技术用于整个业务流程的创新和自动化的想法。之所以有这样的想法，也是源于实现能力胶囊（一种开创性的企业能力获取方式，已注册专利）的想法。更多信息可参考BMG网站，也可以通过检索“可打包的业务能力”（Packaged Business Capabilities-PBC, Gartner 2022 年新兴技术之一）了解其概念。

基于这个背景，我们启动了这个略显宏大的项目“业务能力工厂”（如图1中黄色区域）。

开端很美好，我仅提供了几句背景介绍和描述目标、价值、所需能力等的提示，就产生了令人震惊的代码。如前所述，作为对底层技术毫无经验或知识的开发者，首次测试时看到输出成果，堪称神奇。回想起来，对于我这样没有基础技术知识的人，起初并不敢触碰生成的代码，遵循指令第一次测试的时候，魔术一般神奇。大部分功能代码和测试迅速生成，感觉开发工作仅需两三天。

然而，常言道“细节决定成败”（ the devil is in the details），问题接踵而至。我尝试用下图记录这段经历，欣赏阶段、失望阶段和愤怒阶段。

图-5 Vibe Coding之旅及阶段

我的首次体验遵循（1）号曲线，几天内完成了超过 90% 的代码。此欣赏阶段感觉很神奇，对 AI 的信任开始超越对人类，毕竟仅用几句话就生成了可执行且看似完美的代码。然而，很快我遭遇“Token 限制”。大约在代码量达到 1000 行（大概数字不是精准数字）时，限制开始显现。这意味着在对话涉及约 1000 行代码后，会收到提示达到 Token 限制、需重启会话的通知。重启会话意味着丢失上下文。需要重新提供。在进行一些修正后，又再次提示达到限制，如此反复了一整天。然后突然间，收到信息提示由于操作过于频繁需等待一段时间。这让人不禁怀疑幕后是否真有人在编码？为何不让我继续？

逐渐地，我进入了失望阶段。我检查了 LLM 提供商的订阅等级，得知越昂贵的等级限制额度数会越高，是哦，总是会有办法。于是我果断升级到最高级别。情况似乎略有好转，但失望犹存。我一度打算放弃，心想“让一台机器开发这么多东西还是太难了”，但已投入太多时间，遂想再次尝试。也许明天可以？但随时间推移，遇到了更严重问题。由于重试次数过多，开始发现代码开始不一致，偶尔还会出现“幻觉”。代码是生成了，但由于误解了意图，最终产出错误代码，只能忽略已有代码。

代码质量每况愈下，我开始进入愤怒阶段，到目前位置我一直信任LLM，但这有意义吗？LLM 坚称其生成的代码正确，而且在代码生成完毕还会信心满满地提示此段代码拥有“完美”逻辑。但事实上编译时出现 140 个错误，代码和其他程序之间也出现了不一致的现象，让人很生气，。但我质问为何代码不匹配时，它却轻描淡写地告知遗漏了某些内容。在一番情绪化对话后，LLM突然开始逐个程序或函数生成代码，突然给出一段代码并要求我修正。它指示只需修改几行代码，但代码行号并不匹配。然后，在抛出编译错误后不仅要求我来修改，它还会抱怨我改错了。真实不可理喻！若有这样的人类员工，定会被解雇！至此是无法保证代码质量，只能回滚到上一个检查点版本。浪费了两三天时间，深感沮丧。

那么，该如何改变图中的曲线呢？ 有没有可能改变，至少保持在曲线 (2)，或者有希望实现理想曲线 (3)吗？答案是肯定的，最终我找到了实现曲线 (3) 的方法。我认为目前还是无法完全避免失望阶段，但我可以完成项目并达到 100% 质量要求，即理想的能力水平。秘诀在于：从现在起，开发者需改变人类开发过程中的时间分配方式，明确核心重点，并学习如何与 AI 协作。

 

7. 实现第三条曲线“旅程”的可能性？

之所以使用“旅程”（Journey）一词，因为它不仅是简单旅行（心情轻松欣赏风景），而是计划抵达目的地、面对挑战、解决问题、步步前行，有时折返、绕路，当最终抵达时，它并非终点，而是新阶段的起点。

上图中第二条（2）曲线与第三条曲线（3）的区别在于：第二条曲线无法达到理想质量，只能持续改进程序；而第三条曲线则能在某一刻达到理想质量，最终得到具备预期能力的程序。

图-6 第三条曲线的架构思维

• 系统思维 (System Thinking)

系统思维要求思考任何系统（最终目标）时，兼顾整体与部分。这是认识论的重要概念，也是解决问题方法的起点。如上图所示，一个目标由其子组件（左侧小圆圈）组成。但仅满足子组件要求不足以构成母体，因为母体总存在涌现（Emergent Property）出的新属性。因此，需要将母体分解为子组件，并理解母体的涌现属性。例如，汽车由发动机、底盘、方向盘等组成，但仅有这些并不能成为汽车。需要理解是什么使其成为汽车，并将这些特性添加到组件中。Jamshid Gharajedaghi 的《Managing Chaos and Complexity》一书对系统思维有极大帮助。

• 架构思维 (Architectural Thinking)

关于架构思维，需解释两点：重构与横切的维度。

随着系统演进或时间推移，熵增导致异常频发。在程序设计中，重构是应对方法之一。如上图所示，在步骤①中，子元素边界清晰，但随着步骤深入，分支间冗余增加。经验表明，当此现象出现时，LLM 生成的代码质量会急剧下降，“幻觉”也随之增加。开发者需要监控这种风险。一旦识别此问题，应如图 ②所示界定范围，并沿图 ③ 箭头示意方向重构。重构的标准是功能内聚性与松耦合。这又面临“What”的问题。我们可以指示 LLM 进行重构，但若“What”不明确，问题依旧。

重构的标准是横切的视角。本项目早期困难之一是草率重构，一开始的时候程序创建关注的是层级深度也就是功能深度，如此创建每个功能时无法分考虑全面的维度，所以树状结构中并不建议一枝深入。更重要的是层级迭代逐步深入，每层都需要考虑重构，明确重构角度至关重要。阅读至少一本关于架构设计模式的书籍将大有裨益。

• 上下文语境思维 (Contextual Thinking)

代表“How”的子元素会根据“Why”（目标）和“What”（能力）的定义而变化。母元素是“What”,子元素是母元素的“How”, 进一步思考，从“子元素的子元素”角度看，子元素本身也是一个“What”。关键在于，如果“How”（子元素）生成错误，其下所有内容都将错误。因此，开发者应始终以符合上下文思维的方式与 AI 协作，例如上图 ④ 所示的范围界定。AI 能在瞬间生成“How”，但其保持上下文语境一致性的能力有限。如果开发者未能从上下文角度审查生成的代码，开发者将很快偏离轨道，经历第二条甚至是第一条曲线的旅程。

开发者需要对上下文语境（Context）有清晰理解，需要理解并维系语境无关（context-free），语境感知（context-aware），语境注入（context-injection）和基于语境（context-based）的含义。并善于运用抽象与具体化。LLM 本质上是基于用户（开发者）的上下文思维生成代码，其基础是学习自他人的代码。因此，若开发者缺乏上下文思维，输出代码也将处于同等水平。我多次观察到一旦开发者具备上下文意识，只需少量推动（nudge）即可带来很大改观。Park Changkyu 教授（世界百强工程师之一）所著《If Content is King, Context is God》书名恰如其分地道出了真谛。

• 理解语言 (Language Understanding)

LLM 是大型语言模型。理解语言将帮助你更有效地使用 LLM，获得更高质量的输出。这意味着你需要使用动词、名词、形容词、副词等构建句子。而名词代表了是什么，动词代表了期望的价值（通过动作制造价值）。建议尽可能避免使用形容词和副词，必要时根据情况注明其参照物（比如示例）或具体数值。

对于名词，保持用法一致性至关重要。尽管LLM生成结果时，会根据含义判断用词的相似性，但有时因不一致，经过长时间开发，你以为在不同开发阶段指代不同事物的名词，由于不一致导致不得不回溯到之前的备份代码。实际上，角度上微小的偏差，随着时间推进会画变成巨大弧线导致更大的差异。

对于动词，建议开发者根据价值期望找到合适的动词作为标准。在本项目系统中，我对约 60 个动词进行分类，选出代表动词，相应的问题模式随着动词组织并嵌入到对应的智能体代理中。而且强调从批判性思维角度定义动词，因为动词表达了产出成果的预期价值，智能体代理能提出各种补充问题，从而可以获得更高质量的结果。在本项目中，我采用了同样的方式与AI互动。若对语境性质疑提问不熟悉，推荐阅读 Warren Berger 的《A More Beautiful Question: The Power of Inquiry to Spark Breakthrough Ideas》。

8. Vibe Coding 实践的经验教训

Vibe Coding 实践中，我得到的重要启示是：开发是一项创造性活动，而不仅是技术任务。你会意识到代码不仅是实现功能的工具，也是表达开发者思想与创造力的媒介。同时，Vibe Coding 过程中的试错不可避免。LLM 创建的大多是“How”的子元素，没有“How”就无法构建更高层级元素。然而，拥有所有部件也不等同于高层级元素，必须添加开发者的创新(emergent property)属性。本项目中我的感受，AI 能完成基础层面，但从特定应用层面看，产品最终体现的是开发者的水平。这也是Vibe Coding实践项目中，在经历数百次失败后的我的深刻体会（我每天的工作时间可以作为参考，是从早 8 点至晚 9 点，中间有约 1 小时用餐和 2-3 小时锻炼）。

• 定期备份与设计泛化

在多数应用开发中，很难从欣赏阶段直线抵达最终产品。一旦创建超过一个功能并进行几次修改，就会进入失望阶段。此时需立刻回滚到上次备份检查点。没有备份后果是灾难性的。有时会试图修复，但极易陷入愤怒阶段。经验表明，回滚是减少失望与愤怒阶段的关键。因此，我的原则是每完成一项能力或功能就进行备份。备份分两种：物理代码备份和设计备份（即提问备份）。设计备份比代码备份更重要。因为代码是“How”，若“Why”或“What”改变，“How”会随之过时，之前的工作成果可能失效。而定义和指导“Why”与“What”的提示若保留在最终版本中，即使需求变化，也能快速修改“How”。

• 澄清 (Clarification)

开发者编写提示传递给 AI，由 AI 解释需求并生成代码。然而，准确传达需求并非易事，开发者编写的需求常有不一致或不完整之处。这种情况下，生成的代码自然偏离预期，将项目推回第一条曲线。本项目开始时尝试尽可能多地提供提示/指令来解决，但常遇到因不完整的需求导致污染底层代码的情况。为保持在第三条曲线上，我采用的方法是，先定义需求，向 AI 解释（而非直接指令生成代码），在 AI 指出缺失或我们确认无误并获得“批准”后，再让其生成代码。这显著减少了“幻觉”次数，挫折阶段也相应减少。

• 完整代码集 (Complete Code Set)

AI 的记忆是有限。LLM 理论上能记住每次对话，但商业化服务为保障资源效率必然存在限制。特别是当发现问题或传达改进需求时，生成的代码往往不是完整集合。若开发者稍有不慎，会立刻进入第一条曲线，因为生成代码是基于相似性分析，而且关注的是有问题的代码或新功能的程序，所以，未参与改进或缺陷修复的那部分正常的代码可能会丢失。从资源效率看合理，但对开发者而言，稍不留神就会发现代码被修改，若无备份，直接跌入愤怒阶段。项目初期多次发生此情况，后来我总是在创建新代码时比较总行数。若行数差异巨大，立即质询原因。AI 的回应总是“对不起”。这种情况该怎么办呢？解决方案是下达“编写一套完整代码”指令。但如果因此触发 Token 限制怎么办？只能重启会话并重新设置上下文——核心问题在于如何保持上下文？我尝试了多种关联上下文的方法，但官方答案是无法知晓上一会话的上下文。（尝试在聊天中重建上下文一段时间后，虽然LLM的官方声明是其并“不知道上下文”的，但我常感觉他是“知道的”）。要求重设上下文？这让人愤怒。怎么办？如果项目已进行一段时间，重新输入所有内容会导致两三次对话后再次触及 Token 限制，被迫开启新会话，令人沮丧。解决方案？如果应用足够大，重新输入完整上下文不现实。架构思维再次发挥作用：根据图6 的对应节点，将注意力集中在上次层节点，只为重构的代码集（程序）输入上下文，有时甚至无需输入。一旦设置好图 中④ 所示范围并上传关联程序（可以简单假设每个节点会对应一套程序），随着程序的上传，上下文随之更新。现在似乎进入可控阶段，但如果重构不顺利，需要上传的代码总量增加，会直接触发 Token 限制，再次回到第一条曲线。

• 提供正确视角 (Providing the Right Perspective)

在项目进行中，以 AI 为工具通过提示（输入指令）生成代码的体验新奇且令人大开眼界。然而，习惯后观察生成的代码和描述，会有种感觉：虽然是在生成代码，却像在导入他人的代码——我感觉自己在修改别人已经完成的逻辑和设计以适应这个项目。这是很自然结果，但感觉像在隔靴搔痒，特别是在生成的代码与自己预期似像非像不太一样的时候。此时需要清晰地表达自己的观点以明确视角。视角可能多种多样，考虑抽象层级、软件生命周期、利益相关者价值观（如测试视角）、架构等，重点是要明确的视角清晰地融入到指令中。

• 提示或助推 (Hints or Nudge)

LLM 依赖词汇和上下文相似性决定生成内容。多数情况下，输入的上下文（指令）和会话中累积的上下文决定生成是否合适。但有时，使用暗示 (Hints) 或助推 (Nudge) 传达难以包含在上下文或指令中的特定需求，能极大提升效率和质量，特别是针对用户便捷性或界面美观性需求时。这种情况，提供所需界面的示例图片，或暗示一个广为人知的常见示例，能快速达成目标。本项目常使用 VS Code 的标准作为提示或助推，因为应用是作为VSCode插件形式运行的。在创建后端程序时，使用类似提示和助推的效果也很好。当然，也可根据前述思维方式灵活运用。有时，生成并测试代码后仍出现类似错误，而且会反复出现。此时，若像对待反复出错的员工一样，在代码中加入“彻底检查代码”之类的指令，AI 会注意到并立即响应。

• 避免过度信任 (Avoid Excessive Trust)

本项目中，我注意到一个现象：在以交互方式向 AI 提出需求、审查和测试结果时，会发生奇怪的立场转换。起初对话由开发者驱动，但逐渐地，AI 负责设计与开发，开发者沦为测试员。例如，首次对话是“编写一个界面”，生成屏幕代码后测试主要由人完成。但若后续提出改进或报错，AI 即成为设计者和开发者，人类开发者根据 AI 指示测试、报告结果、检查日志、修改配置。此时，“系统用例”变成了“人类用例”。当 AI 生成和指示的东西失效时，挫败感渐生。这似乎养成了一种基于信任的过度依赖习惯，仿佛 AI 完美无缺。就目前而言，我们不应如此信任 AI，如果过度信赖，很可能落入第一曲线的旅程。始终保持批判性思维，不要忽视 AI 生成的代码也可能出错，尤其在重构不力时，它会复制人类开发遇到的问题。

 

9. Vibe Coding 的阴影

Vibe Coding 的优势显而易见，无需赘述。但它也有其阴影。最大风险是陷入“自我合理化的陷阱”。人们可能将懒惰或缺乏规划简单地美化为 Vibe Coding。真正的 Vibe Coding 中重点是在随意编程的自由度下，不会忽视目标与质量。Vibe Coding 容易诱使你忽略全局，直接进入编码阶段——因为输入一些需求和指令，代码看起来就非常棒（正如许多 YouTuber 展示的），让你产生应用开发已完成的错觉（即进入欣赏阶段）。这种诱惑难以抗拒，却是通往失望与愤怒的捷径。即使“成功开发”，也会导致开发者对代码缺乏深入理解，换句话说，修改他人开发的代码与修改自己开发的代码，面临的风险是不同的。避免此陷阱的方法是深化对架构的理解，在Vibe Coding时将基础目标、所需能力与架构衔接统一，这样 Vibe Coding 可以成为一种可控的开发方法。

传统开发方法中，角色分工明确（架构师、设计师、程序员、测试员等），底层技术也细分（数据库架构师、应用部署架构师等）。但在 Vibe Coding 中，这些界限变得模糊：那些常规化的、对应“How”的任务，实现起来太容易、太快（自动化了）。

图-7 Vibe Coding与传统开发的差异-步骤与工作量

结果是，经验丰富老道的(contextual seasoned ‘감’ 있는)的开发者更能适应 Vibe Coding。因此，关键问题是如何快速培养新开发者成为拥有“有感觉的”的“多面手开发者”（真正的精益开发者）。

 

10.提升 Vibe Coding 的方向

自计算机诞生以来，软件开发方法在持续演进中。持续演进的重点持续上移中，代码本身的重要性相对下降：从微码（微指令Micro Code）编码，到编程（Cobol），再到设计（结构化设计Structured Design），再到分析（统一建模语言UML），再到业务（信息工程Information Engineering），再到客户价值（Design Thinking设计思维, Customer Get Job Done客户目标工作）。经过本项目的实践，发现AI 可替代（或促进）的工作范围比预想更广，如图8绿色区域所示。软件开发流程的演进历史表明，AI 可替代的工作遵循同样模式。这仅在应用开发领域，若考虑本项目中系统所做的事情（业务能力工厂-业务执行自动化），可以预见这种范式转变将更为迅速。

图-8 按开发阶段划分区域

为了更好地实践 Vibe Coding（或换一种说法，如何保持人类开发者的价值），我们应关注什么？

我们需要清晰理解需求。需求分两种：业务需求与 IT 需求。业务需求是在理解外部竞争环境（PESTNL – 政治、经济、社会、技术、自然、法律）、客户价值、业务领域竞争格局以及基于战略的业务变革后，对业务模型进行再设计的要求。IT 需求则可视为对技术基础进行改进或储备，以将业务需求构建为运营模型的要求。由此可见，IT 需求与 IT 架构对齐变得日益重要。IT 架构定义可借助 AI，但因架构的目的是实现战略，所以不同公司架构必然各异。因此，加强架构教育与实践能提升 Vibe Coding 有效性。

而业务模型则更为重要。公司通过业务创造价值。如果定义价值、制造价值、交付价值和获取价值的业务被明确定义，将最大化 Vibe Coding 的有效性。构建业务能力工厂（本项目目标）的主旨，正是基于定义明确的业务模型，建立一个能直接执行业务（无需任何编码）的系统，并通过此系统自动化企业大部分工作（IT 开发和业务运营流程）。

是什么使这一切成为可能？答案是企业的数字孪生系统。 在数字孪生中，从业务模式开始，所有员工日常工作的任何事情（知识Knowledge），都在基于业务本体的业务模型中得以足够细化、精确定义，和数字化表述。这正是本项目流程能够在业务能力工厂中立即执行的原因。

那么，如何构建这样一个数字孪生系统？ 目前为止，仍然需要由业务专家和业务建模师完成。AI 尚无法完全替代，毕竟每家公司愿景、价值观、目标不同，员工技能各异。虽然在韩国的应用情况尚不清楚，但在海外已有许多公司致力于构建业务本体模型，我们参与海外项目已超 10 年，据我们了解类似有约 20 家公司采纳了这种方式。例如，我们直接参与的某金融机构项目中定义了数千个客户价值定义、一千多个价值制造/交付/获取活动、约 4000 个业务任务、数千个决策报告与数据脉络、数百个业务动词和数万个业务名词。每个概念都有明确目的、定义和范围，这些概念之间的关系定义呈现为多维。基于此业务本体模型，我们尝试在业务创新和运营模式变革（业务改进与 IT 开发）中努力最大化客户价值与敏捷性。本文介绍的项目？？旨在直接在业务创新与建模平台上开发和执行业务运营流程，如同部署一项计划让流程直接部署即可执行。

 

11. 结论

Vibe Coding 是在现代软件开发环境中提升开发者创造力和可持续性的一种新模式。它不仅是开发方法，更是帮助开发者提升工作价值、产出更优成果的途径。

然而，Vibe Coding 也对开发者构成挑战。如果开发者不适应前文所述的思维方式（系统思维、架构思维、上下文思维、语言理解等等），他们将面临被替代的风险。因此，开发者必须从现在开始习惯新的思维和工作方式。

公司拥有利用这种新开发方式的巨大机遇，但如果不能对其业务进行明确的定义，Vibe Coding 只能成为效仿其他组织先进技术的工具，能带来的利益也是有限的。请问：您公司的业务定义在哪里？仍然碎片化地存在于员工大脑中或现有的程序中吗？这样的公司无法获得全部收益。

因此，需要从现在起来开始为你的企业构建数字孪生，开发者也要开始尝试新的思维方式与元认知实践方法。新范式的浪潮比想象中来的更快。祝愿您的企业可以充分准备，在浪潮中生存并能扬帆前行。

 

附录：传统开发与 Vibe Coding 的不同

维度	传统开发	Vibe Coding
方法的基本差异	– 手工键入所有函数、变量和逻辑 – 需准确记忆编程语法 – 关注“如何实现？”	– 用自然语言表达意图和目的 – 与 AI 协作完成开发 – 关注“我们要构建什么？”（What）和“为什么？”（Why）
开发者角色演变	– 程序员 → 亲自编写每一行 – 编程专家 → 记忆编程语言细节 – 程序调试人员 → 逐行排查并修复 – 开发人员 → 转化设计为代码	– 架构师 → 设计整体系统结构 – 沟通者 → 与 AI 有效交流 – 协调者 → 审查与策划 AI 输出 – 创新者 → 探索创造性方案
开发流程差异	-需求分析 -详细设计 -码编写（逐行） -编译/运行 -调试 -迭代	-设定愿景与目标 -与 AI 交流以完善想法 -快速创建原型 -实时反馈与改进 -迭代演进 -最终审核与优化
生产力和高效性	-耗时编写样板代码 -耗时查找语法错误 -长时间学习新技术 -大量重复性工作	-AI 即时生成样板 -几乎没有语法错误 -通过对话快速应用新技术 -更多时间用于创意工作
如何学习与成长	Javascript //开发者自己学习和记忆所有编程 function traditionalLearning() { //然后需要阅读文档 // 遵循示例 //重复试错 //需要经过长时间学习 }	Javascript //通过与AI对话快速学习 //比如指令是，“将此程序按观察者模式重构”。 于是 → AI 给出附带解释的实现 →实时理解并纠正 →快速学习和应用
解决问题的方法	– 独立思考 – 搜索 Stack Overflow网站 – 阅读文档 – 试错中解决问题	– 与 AI 头脑风暴 – 即时比较多个方案 – 选择最佳方法 – 快速原型验证
代码质量与一致性	– 依赖开发人员个人风格 – 代码审查事后改进 – 难保一致性 – 质量依赖经验	– AI 自动应用最佳实践 – 实时代码质量反馈 – 易于保持风格一致 – 初级人员也能产出高级代码
创造力与实验性	– 实现可行性优先 – 采用熟悉模式 – 实验成本高 – 方法相对保守	– 探寻“这可能吗？ – 快速尝试不同方法 – 实验成本极低 – 鼓励创新尝试
主要区别概述	Vibe Coding 将开发者从“代码打字员”进化为“软件架构师”。AI 负责处理重复性和机械性任务，而开发者则专注于创造力、解决问题和创造商业价值。这不仅仅是工具使用方式的改变，更是我们思考和处理开发方式的范式转变。正如计算器的出现将数学家从简单计算中解放出来，使他们能够专注于更复杂的理论研究一样，Vibe Coding 也让开发者能够专注于解决更高层次的问题。

参考文献：

• 演示视频：业务能力工厂 – DREAMER（2025）
• 参考网站：http://www.bmgovernance.com