2022年荣获韩国软件竞赛IT架构奖项。
2023年，在中国出版专著《需求工程：数字化转型加速器》。
BMG公司持有20余项知识产权与专利。
说明：SOLVENT平台有不同的版本类型，业务建模版本类型在大陆地区的版权归属为中国建信金融科技有限责任公司，大陆地区的高版本类型以及除大陆区域外所有版本类型的版权归属为BMG公司。
内容目录
1 内容概述
2 应用研发过程
2.1 业务分析
2.2 业务模型
2.3 本体模型
2.4 应用设计
2.4.1 基于UML的设计
2.4.2 架构决策
3 关键研发成果
3.1 前端架构
3.1.1 用户体验框架
3.1.2 用户界面
3.1.3 用户界面逻辑
3.1.4 后端接口
3.2 后端架构
3.2.1 应用程序编程接口（API）
3.2.2 数据传输对象 (DTO)
3.2.3 应用服务
3.2.4 领域服务
3.2.5 存储服务
3.3 本体语义查询与答案
4 内容回顾
在快速发展的软件工程领域，人工智能为大幅提升开发效率创造了前所未有的机遇。本文探讨了一个突破性案例，该案例通过战略性地运用本体与AI代理，彻底重塑了企业级应用程序的研发模式。这种方法从根本上重新构想了业务需求转化为功能性软件的方式，从而显著缩短产品上市时间，提高业务敏捷性，提升质量保障级别，并降低开发成本。
本转化方法的核心之处是一个精密方法论，从29个维度分析业务需求文档，以此构建全方位的业务本体模型。这一多维本体作为整个应用生态体系的语义基础，使AI代理能够从语境层面深度理解复杂的业务规则和关联关系。本实施方案中运用基于图技术的本体服务器，为智能化设计实现系统提供了必要的结构化框架，此实现覆盖从前端的用户界面组件到后端业务逻辑。
本案例涉及住房信贷管理系统，覆盖从贷款申请启动至还款催收的全生命周期。该领域向来都是一个复杂业务流程，因其涉及大量监管要求、各种风险评估框架以及众多客户交互环节。本文介绍的系统是采用基于本体的方法，首先将复杂的业务数字化体现为知识模型，该模型可由AI代理解读、推理，并转换为可执行的应用组件。
尤为值得关注的是，此方法可以极大缩减开发周期。从初步理解业务需求到系统全面部署，整个过程仅耗时三天——这在传统软件工程模式下是无法实现的。这并非渐进式的改进企业软件交付方式，而是一次根本性革新式的再构思。
本文将进一步探讨促成该创新的架构原则、本体建模技术以及AI代理的行为机制。我们将从29个维度检讨本体的特定构成，阐述基于图的知识服务器的技术实现，并说明生成整个应用栈的自动化设计流程。此外，我们将定量评估开发效率的提升，并讨论系统质量与业务匹配度的定性改进。通过这份分析，我们旨在为致力于在软件工程实践中实现类似创新性突破的组织，提供一份可参照的蓝图。
1. 内容概览
在当今快速发展的数字化环境中，企业正面临着将战略愿景转化为实际运营成果的前所未有的挑战。基于业务本体的方法，能够为关键业务执行领域的转化提供完整框架（图1），涵盖企业能力评估、业务能力实现、业务模型创新、数字化与AI转型、价值挖掘与数据变现、领域专家系统、决策管理、应用研发以及数据管控。本文重点关注应用研发，作为所有其他创新场景在数字化领域得以实现的基础。
应用研发是九大创新场景的独特交汇点。其他场景侧重于构建业务能力、模型与决策，主要关注构建框架，而应用研发场景则是将这些概念性成果通过数字体系转化为落地实现的关键实施环节。如果没有基于业务本体的有效应用研发方法，即使是最精准的业务战略，往往只能停留于理论层面，难以在以数字为中心的经济环境下创造真实价值。在数字时代，业务执行与数字化实现已密不可分——这一看似基本的前提，实则蕴含着强大的变革力量。
将本体方法集成到应用研发中，标志着组织在概念化、设计与实现软件解决方案的方式上发生了深刻的范式转变。传统的应用研发常面临“翻译失真”问题，即业务需求在从业务利益相关者传递到技术实现团队的过程中发生曲解。业务本体提供了一个结构化的语义基础，以机器可理解的格式捕捉领域知识，从而在业务与技术利益相关者之间建立起一种共享语言。这座语义桥梁，使得人工智能驱动的开发工具能够在整个开发生命周期中，始终精准贯彻业务意图。
在一套完善构建的业务本体模型指导下的应用研发，使组织得以构建与业务操作紧密衔接的系统。本体驱动的方法不仅仅在于基于现有流程构建自动化的应用系统，其目的是创建能够内嵌业务知识、适应动态变化、并基于领域专业知识提供决策支持的系统。最终，这些应用不仅能够执行交易，更能积极地为业务智能、操作灵活性与获取战略优势做出贡献。这些应用由此成为业务能力的数字化载体，而非仅仅是技术产物。
本体驱动的应用研发方式的优势不仅限于技术层面，更重要的是创造核心业务价值。通过构建能够继承自业务并理解业务概念、关联关系与业务规则的应用系统，企业可以显著缩小战略构想与落地执行之间的差距。这种方法能够支持更快的市场响应、更有效的知识留存、更高的决策质量，并强化业务与技术领域间的联结。此外，本体驱动的应用通过将领域知识显性化、机器可处理化与AI赋能化，为持续创新奠定了坚实基础。
在接下来的章节中，我们将深入探讨如何将业务本体与AI技术相结合，从而转变应用研发的实践。我们将阐述知识提取与形式化的方法论、基于本体的软件工程技术、语义数据集成的方式，以及在应用全生命周期中保持本体一致性的框架。通过实际案例与实现模式的展示，我们将不仅展示这一方法是如何重塑应用开发本身的，同时也阐述为何应用研发会成为业务本体生态体系中其他八个创新场景的关键驱动力，最终推动实现真正的数字化业务转型。
【图 1】基于本体的业务和工作创新场景
2. 应用研发过程
本项目是一个实验性项目，旨在探索利用本体与AI代理开发企业级应用程序的潜力。为此，项目确立了以下核心原则：
- 最小化人为干预：确保从任务分析到代码完成的整个流程无需人工介入。但涉及架构决策——即确定所需架构及实现约束——则由项目经理明确定义决策因素。我们共识别了84项架构决策因素，并将相关的决策逻辑赋予AI代理。这些因素亦包括各类标准比如命名标准等规范化准则。
- 使用真实业务文档与需求：我们采用真实的、未加任何修改或调整的业务文档与需求。换言之，项目未专门规范化或创建业务文档，而是100%直接使用实际业务中产生的文档。这些文档均来自公寓住宅销售办公室，例如一份约76页的住宅首付贷款合同。我们从中提取业务模型、本体元素及公理，直接用于本体构建、应用设计与代码生成。
- 以AI智能体的能力弥补不一致与遗漏：现实文档常存在不一致或信息缺失。在本体中，概念定义与公理至关重要，但某些本体元素在文档中可能缺乏明确定义。此时，我们依赖智能体的推理能力进行补充与协调。
- 除架构决策外，由AI代理执行所有的任务：这不仅是一次开发，更是训练AI代理理解并实践软件开发流程的流程。项目启动前，我们进行了约一个月的代理训练与测试优化以持续提升AI代理的能力。经过这一个月的AI代理培训阶段，实际实施周期从分析到代码编写的全过程仅用了三天：其中约1.5天用于分析与建模，0.5天用于设计，1天用于编码完成。每个阶段均设有严格的质量审核代理，对每个本体元素、每次分析、每项设计以及最终代码的一致性进行全面核查。
- 确保反复生成过程中程序结构与命名一致性：在使用人工智能生成代码时，常出现每次迭代结果不一致的情况，导致程序结构及内部命名发生变动，进而引发混乱。因此，我们确保在整个开发周期中使用相同的程序结构与命名规范。
- 采用工程化方法，避免“随性编程(Vibe Coding)”：正如先前分享的“沉浸式随性编程”经验所示，随性编程方式随项目规模与应用复杂度增长会暴露出显著局限，尤其是难以维持程序或模块间的一致性，常需频繁重构，甚至可能导致系统整体失控。这使得其难以用于企业级应用的开发与维护。因此，为了研发企业级的应用，我们转向工程化方法。该方法要求体系化定义工程方法论与架构决策，并对开发代理进行相应“培训”——这一流程类似于将初级开发人员培养为高级工程师。由此实现可重复、可持续的研发。
基于以上原则，最终产品包含约4,500个本体元素、29个工作流、107个业务操作、42个用户界面、108个业务实体、64个业务事件、69个代码表、153项约束、101条业务决策规则、19个产品组件、13条定价规则、50条验证规则，以及约2,000个程序代码文件。内容包括代码实例（最底层元素）、验证规则、业务约束、数据安全设置、审批权限及各类业务规则。该应用覆盖从推出住宅首付贷款产品、获客、风险评估、贷款申请、抵押品评估与设立、贷款审批、还款管理，直至风险与合规监控的全生命周期。
开发企业级应用所面临的挑战远超传统编码。在迭代周期中保持一致性始终是难点——从初始概念到最终交付，知识、假设与实现方法常会发生变化。传统的基于提问的AI开发难以应对企业系统内部复杂的相互依赖，因为单个变动可能影响多个组件。此外，企业应用所需处理的信息量巨大，往往超出标准AI系统的语境窗口与注意力能力，因此需要采用超越常规开发范式的专门方法，以确保所有业务需求得到满足。
为此，我们采用了如图2所示的体系化的方法：
1) 基于本体的分析
为应对固有的复杂性，本体驱动方法首先利用专门的分析与建模代理（建模智能体），对业务及需求文档进行细致处理。这些AI代理提取关键概念、关系、约束与流程，将非结构化的业务叙述转化为规范化的模型。通过精准的自然语言处理、语义分析与知识提取技术，该阶段建立对业务领域的基础理解。与传统需求分析不同，代理生成的是机器可解释的表现形式，所构造的全面知识结构将指导后续所有研发工作。
2) 多视角业务建模
分析阶段生成29个视角的模型，全面展现企业架构。这些模型覆盖业务能力、组织架构、流程、信息流、系统、技术、安全、合规等关键维度，并为从C级别的高管到技术专家的各类利益相关者提供各种所需专门的视角。该方法的优势在于维持各视角间的语义关联，确保某一模型中映射的业务流程能正确关联到其他模型中的数据实体、角色与技术组件，从而形成对企业一致且多维的理解。
3) 本体模型集成与语义增强
随着各模型逐渐完善，它们通过一个整合过程形成统一的企业本体模型。该流程并非简单合并图表，而是进行深层的语义增强——模型元素通过有意义的关系相互连接。本体逐渐发展为知识图谱，其中实体通过类型化关系（如“流程消耗资源”、“部门负责对外能力”、“系统实现功能”）表达精确语义。这种丰富的语义赋予企业本体强大的推理能力，使其不再是传统的知识库，而是能实现自动化的一致性检查、影响分析与智能查询，最终成为企业业务与技术环境的鲜活数字孪生。
4) 本体划分确定项目范围
启动具体项目时，我们会体系化地从企业本体中识别并提取相关部分，形成项目专属本体。该范围界定过程不仅明确项目所需的关键元素，也识别出依赖关系、相关法规、利益相关方关切及相关举措的历史背景。生成的项目本体模型为开发工作提供了语义精确的边界，同时保持与企业本体语境的关联，这种方法可以确保资源聚焦于特定的业务能力，且项目符合企业标准规范。
5) 确定并验证项目范围
开发开始前，项目本体模型需要经过语义推理引擎的严格验证。引擎采用逻辑规则检测不一致性、识别缺口，并确保定义范围的完整性。例如，自动推理可发现业务流程缺失的必要数据输入、安全要求与可访问性要求间的冲突，或技术组件缺失所需能力等问题。此类验证不仅限于语法层面，更涵盖业务逻辑的语义检查，从而在开发前解决不一致与不完整问题，显著减少项目中期因范围变更或结构调整导致的高昂成本。
6) 多智能体协同开发
开发过程中，各专业AI代理基于已验证的输入数据协作，将业务需求转化为功能软件。用户体验设计代理从本体中提取用户旅程并设计最优流程；界面设计代理将其转化为符合本体模型中所包含的企业标识规范的线框图与视觉设计；应用设计代理建立符合企业标准的技术模式；数据库设计代理将信息模型转化为优化后的数据库结构。所有代理基于同一本体工作，使其能在应用领域专业知识解决具体问题的同时，保持所有产出的一致性。
在整个开发生命周期中，本体作为核心协调机制，维护着传统上相互独立的各类关注点之间的一致性。当业务分析师更新需求时，本体将变更的语义传播至受影响的用户界面、数据结构、安全控制与测试用例中。这种自动传播确保所有研发的工作成果能够保持对接，显著减少传统上对自然语言所描述的需求解读不一致，所导致的组件间实现不一致的问题，因为这里，所有开发者与AI助手们均引用同一套语义准确的本体定义。
随着开发推进，实现过程中的工作产物会根据本体所表达的业务意图进行持续性的验证。开发代理生成的代码不仅需通过语法检查，还需验证其语义是否与业务需求一致。例如，系统可自动检验数据访问组件是否强制执行了本体中定义的所有安全约束。这种持续验证能在早期发现业务意图与实现之间的偏差，避免问题遗留至集成测试或生产环境。
测试用例设计代理利用本体生成综合测试场景，以验证技术正确性及对业务规则的遵循。由于本体包含业务规则、约束与预期行为的正规定义，系统可自动生成测试用例，确保实现正确反映这些语义。质量审核代理则持续审查实现是否符合本体中编码的企业标准与最佳实践。这种方法显著提升了交付方案的业务价值，确保测试不仅验证系统“是否运行”，更验证其“是否按业务预期运行”。
一旦开发完成后，项目团队会创建一份“应用本体”，以业务与技术术语记录已构建的系统。该本体记录最终实现决策、其与初始业务需求的映射关系，以及需求如何被满足。应用本体还涵盖操作层面视角，包括操作参数、监控点与常见支持场景等。这一综合的知识库在应用的整个运行周期中作为权威参考，通过提供系统结构与行为的准确语义信息，支持维护、改进乃至最终被取缔的工作。
7) 语义问答系统
应用本体最终赋能领域专家系统，使其能从业务与技术角度回答关于应用的复杂问题。用户可提出如“修改此数据字段会影响哪些业务流程？”或“此功能适用哪些合规法规？”等自然语言问题。系统利用本体中丰富的语义关联，连接应用的各个层面，提供语境相关且精准的答案。该能力显著提升了知识转移效率、支持操作决策，并为系统未来演进提供宝贵洞察，从而形成一种从初始概念到运营支持全程保持语义准确性的完整研发方法。
【图 2】企业级应用研发语境
2.1 业务分析
业务分析是应用开发的基础支柱，需要能够系统地识别、审查和文档化驱动业务运营的核心需求。在当今数字化环境中，有效的分析不仅限于文档记录现有流程，更要挖掘隐藏的概念、未定义的关系以及存在但尚未明晰阐述的业务域。通过系统性调查，业务分析能够全面理解组织的运营框架、利益相关者的诉求和战略目标。作为第一个关键步骤，为所有后续研发活动奠定概念基础，确保技术解决方案贴合真实的业务需求，而非停留于表面。
深入的业务分析至关重要，它与应用程序的有效性及组织价值创造直接相关。肤浅或不完整的分析必然导致应用无法应对核心业务挑战，无论其技术实现多么卓越。反之，能够揭示先前未定义概念和关系的全面分析，可使组织开发出超越单纯对现有流程进行数字化，而是真正推动运营变革的解决方案。这种探索性分析帮助企业适应不断变化的市场条件，识别竞争优势，并发现潜在机遇。业务分析的丰富性与深度，直接决定应用程序能否创造有意义的业务价值与可持续的竞争优势。
在当今分析领域，AI赋能的商业分析代理正彻底改变企业驾驭和定义其运营领域的方式。这些专业的数字实体人拥有特定领域知识，能够以远超人工分析师的规模和速度，处理海量信息、识别模式并挖掘商业概念。流程分析代理负责绘制工作流程并识别低效环节；价值分析代理负责量化利益相关者的优先级，发现未满足的需求；实体分析代理负责发现和定义核心业务概念及其相互关系；监管代理则负责确保符合复杂的合规要求。这些专业化分析代理共同构成一个全面的分析生态系统，能够实现传统方法无法获得的洞察。
这类分析AI代理的显著特点在于其概念发现能力——即检测业务域中未命名或未定义的元素。AI代理并非仅仅记录显性知识，而是借助复杂的模式识别、语义分析与推理能力，识别那些存在却尚未正式定义的隐性概念。通过命名、定义并揭示这些先前不可见的元素，分析代理大幅扩展了应用开发可用的概念图景。这种概念的延伸催生出更全面的数字化解决方案，不仅能满足已知业务需求，也能回应利益相关者潜在、未表达的期望。最终，这类应用程序展现出更深刻的业务理解、更强的运营相关性，以及更卓越的创新价值交付能力。
2.2 业务建模
业务分析模型是应用程序开发的基础框架，它系统地捕捉显性和隐性的业务概念。这29个模型构建了一个全面的业务生态系统数字化展示方式，涵盖了从利益相关者价值链到组织职责的方方面面。通过从价值主张、能力需求、制造流程、交付机制和交换协议等不同角度审视业务流程，这些模型能够识别、命名、定义并将先前未被注意到的业务概念集成到应用程序架构中。这种深入的概念探索直接决定了最终应用程序的丰富性和有效性。
从原始业务分析到结构化模型的过渡是通过复杂的概念识别和关系映射流程实现的。最初，通过利益相关者访谈和流程观察收集有关业务运营的非结构化信息。随着信息被逐步组织成相关的模型，这些信息也逐渐被提炼和完善。每个模型都侧重于业务的不同方面，从人机交互到组织角色描述。这一转换流程体系化地将业务概念分类到合适的模型中，同时建立模型间相关概念的关键联系，最终展示出一致的业务环境，作为应用程序开发的蓝图。
这些模型着重关注商业生态系统中既相互关联又各自独立的方面。价值导向模型阐述了企业如何创造、生产、交付价值，以及如何与各利益相关方交换价值。能力模型则识别了实现这些价值所需的资源、技能和资产。交互模型描绘了人员如何在业务流程中与机器和系统进行交互。组织模型定义了业务单位之间的角色、职责和关系。这些模型共同提供了操作和战略层面的全面业务视图，揭示了以往隐藏的概念和关系，而这些概念和关系对于开发稳健的应用程序至关重要。
专业的AI建模代理彻底革新了这一分析流程，为每个建模维度提供领域专业知识。价值建模代理识别核心价值主张和权衡取舍；流程建模代理绘制工作流程和决策点；业务实体建模代理捕捉数据关系和生命周期状态；用户体验建模代理则专注于用户交互和体验历程。合规性建模代理确保监管要求得到正确整合；价值主张建模代理则提升业务市场的产品提案。在整个流程中，质量审核代理会对每个模型应用严格的标准，以验证其完整性、一致性以及与业务目标的契合度。这些AI专家代理全面确保最终模型达到必要的深度和质量，从而指导开发真正满足业务需求的成功应用程序。
2.3 本体论
贷款处理本体包含一个全面的语义结构，涵盖所有必要的领域知识，包括贷款产品、申请人信息、财务指标、监管要求、风险评估标准和业务流程工作流。它正式定义了借款人、担保人、贷款人、抵押资产、信用评分、贷款期限和还款计划等实体之间的关系。此外，它还整合了管理贷款发放和服务流程的业务规则、合规参数、审批工作流和决策标准。这种丰富的语义框架超越了静态信息的表示，体现了贷款操作中复杂的条件关系和依赖性。
该本体作为贷款应用开发的基础，其稳健性源于它能够提供超越部门壁垒和系统边界的唯一可信的业务资产。通过将分析和建模结果对接到一套一致的图模型中，该本体消除了通常困扰复杂软件开发项目的不一致性和矛盾之处。其规范化的语义结构支持自动推理和推断功能，能够在编写任何代码之前检测逻辑不一致、验证业务规则并确保符合监管要求。此外，基于图的表示方法，允许敏捷性地适应不断变化的需求、市场状况或监管框架，而无需进行彻底的系统改造，从而显著降低维护成本，避免造成技术债。
通过利用准确且语境丰富的信息，本体模型可以作为知识地图，使开发团队能够构建更准确、更合规的信贷处理系统。当开发人员或业务利益相关者就特定用例或边缘场景提出问题时，本体模型会提供完整的语境以及所有相关的邻近数据，而不是孤立的答案，从而实现对含义和依赖关系的整体理解。这种综合性知识库显著减少了对需求的误解，提高了业务和 IT 之间的领域一致性，并通过消除代价高昂的返工来加快开发周期。最终，信贷申请系统能够更忠实地实现业务意图，更容易适应变化，并在各个功能模块和用户界面之间保持一致性。
[图 3] 本体图示例
2.4 应用设计
当战略性地采用本体模型作为底层业务语义模型，应用设计流程得以实现根本性的变革。本体模型中统一的、结构化且对接的信息架构，显著简化了设计流程。本体驱动的实现方法中，具有一个平台无关的模型（PIM），能够准确捕捉业务语义，使AI设计代理在极少人工干预下能够理解和实现需求。这些AI代理在84项架构决策的指导与约束下，将丰富的本体模型转化为功能性软件组件。这一框架能够确保最终应用在满足实施环境的技术需求的同时，仍然保持业务语义的一致性。
UML工作成果——包括类图、用例图、组件图、交互图、数据库结构和状态转换图等——通过AI代理直接在本体中生成和表示。这标志着设计方法论的一次范式转变：传统上，设计师需手动将业务需求转化为这些技术表达；现在，AI代理则系统化地分析本体关系、层次结构与业务规则，生成一致的设计工作成果，并保持与原始业务模型的可追溯性。这种自动化转换方式，既提供了实现所需的特定技术细节，也完整保持业务域的语义内涵。
架构决策为AI代理的工作提供了关键语境，架构决策中包括了定义本体概念如何映射到应用组件、建立服务接口模式、确定状态管理方法以及指定数据持久化策略等。这些决策作为桥梁，将本体丰富的语义与实际实现问题有效衔接，使AI代理能够生成不仅技术上准确，更重要的是能够贴合业务需求的解决方案。最终的应用设计在业务契合度与技术合理性之间求得平衡，展现出AI驱动的设计流程，如何借助本体模型生成既符合底层业务语义、又满足所有功能与非功能需求的复杂软件架构。
2.4.1 基于UML的设计
UML视图构成了信贷申请系统的完整设计文档，从多角度展现系统架构。这些文档包括：通过类图展示实体关系的结构视角，通过序列图捕捉交易流程的行为视角，以及描述系统整体架构的组件图。这些元素共同形成统一蓝图，通过明确信贷处理各环节——从申请受理、审批流程到客户管理——的边界、交互与责任，有效指导系统实现。
这些架构工作成果在系统实现过程中发挥关键的指导作用，既保障开发工作的一致性，也确保与业务需求持续对齐。各类视图在利益相关者之间建立起共享的术语与共识，并强化设计模式与架构约束。通过提供定义清晰的接口与组件关系，架构图减少了实现过程中的歧义，促进了模块化开发。这种结构化方法支持工作条线的并行研发，同时维护系统完整性，最终减少集成问题以加快部署进度。
AI代理之所以能出色生成这些架构工作成果，是因为它们能体系化处理海量的软件模式、领域模型与最佳实践知识，而不受人类设计师常有的认知偏差或思维不一致的影响。它们可基于需求快速评估多种设计方案，生成符号完全一致、内容全面的设计文档。与人类设计师可能在多图表间引入不一致或忽略细节集成点不同，AI代理能够全面覆盖系统各方面，并保持不同视图之间的完整可追溯性。此外，AI生成的设计还受益于内置的质量审核机制，该机制系统验证其是否符合架构原则、设计模式与安全实践，从而产出更健壮、更易维护的系统，更好地应对持续变化的业务需求。
2.4.1.1 类图
[图 4] 设计-类图
2.4.1.2 用例图
[图 5] 设计-用例图
2.4.1.3 组件图
[图 6] 设计-组件图
2.4.1.4 交互图
[图 7] 设计-交互图
2.4.1.5 数据库结构
[图 8] 设计 – 数据库结构
2.4.1.6 状态转换图
[图 9] 设计-状态转换图
2.4.2 架构决策
[图 10] 设计-架构决策
3. 关键研发成果
本文中实现的信贷申请系统成功实施了三层架构，包括响应式前端应用、后端服务和存储库层，实现了清晰的职责分离。前端采用符合用户体验指南的现代响应式Web框架构建，确保跨设备访问并保持视觉一致性。前端优先实施全面的语法和语义验证，以便在用户流程早期发现错误，同时融入业务工作流逻辑，引导申请人直观地完成贷款流程。API层作为前端与后端组件之间的明确接口，支持前后方各自独立开发，并通过标准化接口保持清晰的通信渠道。
后端服务基于Spring Boot开发，遵循领域驱动设计原则，使技术实现与业务域保持一致。该方法清晰界定了信贷处理系统中各功能域的边界，从而更好地组织业务逻辑。持久层采用优化的数据访问模式，并通过适当的事务管理确保数据完整性。整体系统架构充分考虑了安全性、可扩展性和性能等非功能性需求，并实施了相应的缓存策略与连接池机制，以应对不同的贷款申请负载。
在实施阶段，各AI代理依据其专业角色协同工作，共同构建系统组件。前端程序员代理专注于基于响应式设计原则创建直观的用户界面，并实现客户端验证与工作流引导。应用架构师代理构建了整体架构，定义组件边界与通信模式；应用程序员代理则实现了后端服务的核心业务逻辑。集成程序员代理确保系统各层之间的无缝整合，数据库设计代理优化了表结构设计与查询性能。这种专业AI代理之间的职责划分，保障了每个组件均具备相应的专业水准。
测试与质量保证是实施过程中的关键环节。负责测试数据生成的AI代理生成了涵盖各类贷款申请场景的多样化数据集，包括可能触发验证失败或异常处理路径的边缘场景。AI测试代理系统性地验证系统功能是否符合需求，并执行单元测试、集成测试与端到端测试，确保系统在各层均可正常运行。同时，AI质量审核代理审查代码质量指标、性能基准与安全实践，确保系统符合既定的工程标准与最佳实践。这种全面的测试方法有助于在实施早期发现并解决问题。
工程化的实施工作流程，通过建立清晰的交接步骤与协作机制，有效协调了各AI代理的工作。前端程序员代理完成用户界面组件后，集成程序员代理验证其与API接口协议的兼容性，测试员代理则根据需求确认其行为符合预期。应用架构师代理定期审查架构，确保实施决策与整体系统设计保持一致。这种协调机制使得经验丰富的AI代理能够充分发挥各自专业知识，同时保持项目方向的一致性。最终成果是一个高质量、稳健的信贷申请系统，这表明基于AI的软件工程能够通过协调的专业能力与严格的流程规范，有效实现复杂的业务应用。
3.1 前端架构
3.1.1 用户体验框架
[图 11] 实现 – 用户体验框架
3.1.2 用户界面
[图 12] 实现 – 用户界面
3.1.3 用户界面逻辑
[图 13] 实现 – 用户界面后端 – Stub API 驱动
3.1.4 后端接口
[图 14] 实现 – 后端接口
3.2 后端架构
[图 15] 实现 – 后端架构工作成果
3.2.1 应用程序编程接口（API）
[图 16] 实现 – 后端应用程序 API
3.2.2 数据传输对象（DTO）
[图 17] 实现 – 后端 DTO
3.2.3 应用服务
[图 18] 实现 – 后端应用服务
3.2.4 领域服务
[图 18] 实现 – 后端领域服务
3.2.5 存储服务
[图 19] 实现 – 后端存储服务
3.3 本体语义查询与应答
在当今复杂的企业环境中，将业务与IT本体整合为唯一的且一致的框架，是一项具有变革意义的成就。此统一的知识库作为组织的“唯一可信知识库”，成为一个全面而权威的信息中心，覆盖从高层战略目标到技术实施细节的各个方面。通过建立业务概念与技术表达之间的双向可追溯性，组织得以消除传统上隔离战略规划与执行的信息孤岛。这种集成化方法确保所有业务需求、流程定义和战略举措都直接关联到相应的技术组件，从而在整个企业范围内形成连续一致的责任链并达成共识。
唯一可信知识来源的价值远不止于技术上的精妙。它从根本上改变了决策方式，能够为跨领域问题提供一致且可靠的答案——而以往这类问题往往需要协调多个来源中相互矛盾的信息。无论是高层管理者询问某项技术实现如何支撑战略目标，还是IT团队需要了解系统变更对业务运营的影响，统一本体都能通过自然语言查询提供即时、情境相关的洞察。这种能力显著缩短了信息检索时间，消除了依据过时或矛盾数据行动的风险，并使所有利益相关者都能基于对业务现实与技术实现的共同理解开展工作。
当组织基于唯一可靠信息源运作时，业务敏捷性——即快速有效响应市场变化的能力——将得到显著提升。面对新的机遇或挑战，管理者能够迅速追溯其对业务与技术的波及影响，从而以前所未有的清晰度掌握受影响的流程、系统及依赖关系。这种可视性支持更快、更自信的决策，并使组织能够基于对企业级影响的全面认知来推动变革。自然语言查询功能进一步加速了这一过程，它通过普及对复杂信息的访问，使各层级利益相关者无需专业技术背景即可获取所需的具体洞察。
尤为重要的是，这种统一的本体为持续创新与改进奠定了坚实基础。随着业务战略演进与技术实施方案更新，唯一可信信息源亦会持续演化，从而维持业务意图与技术执行之间的关键联结。这一动态的知识库减少了组织在变革过程中常见的知识流失，并使团队能够在前人工作的基础上持续推进，而非反复解决相同问题。通过建立这样一个全面且易于访问的企业知识体系，组织不仅能优化当前运营，更能凭借提升的敏捷性、减少的冗余以及更有效的跨业务-IT边界的协作，赢得可持续的竞争优势。
[图 20] 实现-综合知识库专家系统
4. 内容回顾
通过实践，我们证明一项融合本体论与AI代理工程的实验性项目取得了显著成功，彻底改变了企业应用开发的格局。团队仅用三天时间和150美元预算，就交付了一套涵盖前端应用与后端数据库的完整住宅信贷申请系统，其开发速度之快前所未有。这一成就挑战了传统开发模式——后者通常需要数周甚至数月时间以及更高预算才能实现类似成果。该项目的成功体现在多方面，包括业务敏捷性的提升、系统质量保障、显著的成本节约，以及对企业级标准的全面遵循。
[图 21]开发人员和AI代理在设计阶段的角色
最为重要的成就在于建立了能够连接业务需求与IT运维的唯一可信信息源。基于本体的方法实现了业务概念与技术实现之间的无缝转换，从而消除了企业软件项目中常见的脱节现象。这一统一的知识库能够真实地反映系统架构中的业务逻辑，有效避免了业务分析师、架构师和开发人员之间因交接转手而产生信息损耗的问题。此外，AI代理成功解析了本体模型，生成了既准确体现业务领域内涵，又严格遵循架构最佳实践的一致性高质量代码。
[图 22] 开发人员和 AI 代理在实施、测试和实施阶段的角色
该工程化方法的可重复性和一致性是另一项关键成就。传统的开发方式常因人为因素导致质量波动和进度难以预测。相比之下，本项目证明，基于本体模型与工程工作流程对AI代理进行正确引导，能够产出可预期的高质量成果。这种一致性贯穿所有系统组件，从数据模型到用户界面，最终形成一个完整连贯的整体，而非零散元素的简单拼凑。此外，该方法具备良好的适应性，能够在保持架构完整性的同时，实现对需求变化的快速响应与迭代。
本项目总结的首要关键经验，是工程化工作流（方法论）的重要性。项目中我们发现，AI代理需要结构化的流程才能发挥最佳效能。临时性的指导方式往往导致结果不一致，而采用定义清晰的工程工作流程——明确顺序、依赖关系与质量门控制节点——可显著提升成果的一致性与质量。这种结构化方法使得代理能够始终在恰当的语境中开展工作，并基于已有成果持续延伸，而非创建彼此孤立的组件。同时，该流程也有助于高效检测并纠正错误，防止问题在系统架构中扩散。
本项目凸显了具备领域专长能力的综合型AI代理的必要性。通用AI工具在企业级架构任务中表现欠佳，而基于特定工程模式与架构原则训练的代理则取得了显著更优的效果。最有效的代理不仅掌握了技术知识，还展现出对业务的领域概念的理解以及跨领域转换的能力。这种综合素养使它们能够在满足业务目标与技术约束的同时，做出恰当的权衡与设计决策。
架构决策被证明是影响系统整体质量的关键因素。本项目显示，AI代理在获得明确指导时能有效实现架构模式，但在需自主做出架构决策时则表现不足。最成功的路径是由人类架构师定义关键的架构原则与模式，再由AI代理在全程实现中始终如一地应用这些原则。这种责任分工结合了人类的战略思维优势与AI执行的一致性和细节专注力，形成一种互补协同的关系，最终达成出色的架构成果。
最后，该项目揭示了AI代理的训练与传统软件开发存在本质区别。最有效的方法并非单纯提供规范指令，而是引导代理理解架构决策背后的“原因”。基于架构原则与领域模型进行训练的代理，能够自主推理出合适的实施方案；而仅接受具体指令训练的代理，则持续依赖外部指导。这一发现表明，未来的AI增强型开发应更注重构建具备深层概念理解能力的代理，而非仅仅扩展其代码生成范围。通过在此类代理训练上投入，企业能够建立可持续的开发体系，在保持本实验项目所展现的高效性的同时，持续交付高质量的企业级解决方案。
业务模型阐述企业的价值实现过程
企业的本质是一个有组织的实体，其核心是协调个人的生产力以提供商品或服务，以满足特定市场的客户需求和愿望。每个企业的基本目标都是创造价值，这种价值可以体现为有形产品、无形服务或两者的结合。成功的价值创造可以使企业产生收入，理想情况下，还能带来利润。
盈利能力是衡量企业可持续发展的关键指标，它表明企业能有效地管理资源，创造出超过支出的收入。这种财务稳健性为企业的未来运营、增长和投资提供了保障。
企业在一个包含诸多因素的复杂生态系统中运营，这些因素包括整体经济状况、行业趋势、竞争压力以及监管框架等。成功地应对这些因素对于企业的长期成功至关重要。
在不断变化的商业环境中，创新和适应性是取得成功的关键。企业通过不断追求产品、流程和客户服务的改进，可以保持竞争优势，并满足市场的不断变化的需求。
总的来说，商业连接了生产者和消费者，它在经济中发挥着重要的作用，推动商品和服务的交换，为社会福利和经济增长做出贡献。
商业模式画布
商业模式画布是一种可视化、体系化的方式用于描述、分析并设计商业模式的战略管理工具。它通过结构化框架，清晰展示组织如何创造价值、传递价值并最终获取价值。
该画布可分为两大组成部分：商业模式板块与财务模式板块，二者共同勾勒出企业运营与盈利的内在逻辑。
商业模式板块聚焦于价值创造的核心环节，包含以下要素：
- 价值主张：企业为客户提供的独特产品、服务或利益组合，旨在满足特定需求、解决核心痛点，并实现与竞争者的有效区分。这是商业模式的出发点与立足点。
- 客户群体：企业所瞄准并服务的特定目标用户或组织群体。深入理解其需求、行为与特征，是精准塑造价值主张的基础。
- 渠道：企业用以接触客户、传递价值主张的路径与方式，涵盖宣传、销售、分销及售后等全链路触点。
- 客户关系：企业与客户群体建立并维持的互动类型，包括个性化服务、自动化交互或社区运营等，直接影响客户忠诚度与长期价值。
- 核心活动：为确保商业模式运转而必须执行的关键运营动作，如产品研发、平台维护、供应链管理或问题解决方案的实施。
- 核心资源：支撑价值主张交付与商业模式运行的关键资产，包括实体设施、知识产权、人力资源与金融资本等。
- 核心合作关系：指与供应商、合作伙伴等构成的协作网络，旨在提升效率、降低风险、获取资源或扩展市场影响力。
财务模式板块则关注商业模式的可持续性与经济效益，主要包括：
- 收益来源：企业从各个客户群体获得的收入途径，可来源于产品销售、订阅收费、授权许可、广告佣金等多种形式。
- 成本结构：运营整个商业模式所产生的所有支出，包括固定成本、变动成本，以及对规模经济效应的考量，直接决定商业模式的财务可行性。
本质上，商业模式画布通过揭示各要素之间的内在联系与动态互动，为企业提供一幅完整的运营全景图。借助这一工具，企业能够系统化地呈现战略思路、发掘优化机会，并在不断变化的市场中增强适应力与竞争力。
业务模型创新与数字化转型
商业模式(Business Model 也译为业务模型)，阐述了企业如何创造、提供和获取价值的框架，明确企业创造收入和维持业务所需的活动、资源和关系。业务模型包括对客户/市场的价值主张、创造价值的核心流程以及创造过程中所需的关键资源等，
业务模型创新主要源于外部竞争压力。企业不断重新设计其核心运营、价值主张和收入来源，以在竞争激烈的市场中实现差异化。商业模式/业务模型创新，是指重新思考和重组现有的商业模式，追求卓越商业价值的过程。这可能涉及对价值主张、核心活动、收入流/成本结构、客户群及客群关系的改变。其目的是探索新的方法、新的产品、新的市场等，通过创新为客户提供独特的价值，实现企业业务差异化从而在竞争中保持领先地位。
数字化的手段可以提升企业的影响力。主要体现为三类，一是自动化降低了成本并提高了效率。二是人工智能实现了数据驱动的决策和个性化体验。三是增强连接性可以促进协作并扩大影响力。
数字化转型就是要整合这两个观点以产生协同效应。这不是零碎的技术引进，而是对企业经营方式的整体改变。
现代商业环境要求企业的业务模型不断迭代。企业不可能是静态的实体，只有不断的变化才可以抓住新的机遇，适应多方压力。
市场需求日益复杂，对个性化服务和即时响应的期望越来越高。人们越来越需要能够满足这些不断变化的需求的创新商业模式。
技术进步提供了强大的工具。企业正在利用这些资源来简化流程、预测市场趋势并与客户建立更密切的关系。
自动化通过处理日常任务释放人力资本，使其能够专注于需要创造力和战略思维的更高价值的活动。智能系统分析海量数据集以提取有助于决策的可行见解。
连接性实现了跨多个平台的无缝通信和数据共享。这提高了协作、响应能力和整体敏捷性。
不断发展的商业模式对于长期成功至关重要。这不是一个一次性的项目，而是一个持续的适应、学习和改进的过程。
数字化转型是利用数字技术推动商业模式创新并创造卓越业务价值的过程；数字化是应用数字技术改善卓越运营和客户体验的过程；而商业模式创新则是对重组商业模式的过程，目的是实现企业的核心价值，在企业发展的同时，践行可持续和普惠大众的理念，为更多人创造价值。这些概念共同构成了一种共生关系，推动企业在数字化时代的有序发展。
操作层面的业务模型
战略业务模型定义了组织的长期目标和竞争优势，以概括描述理想的未来状况。然而，如果这种战略愿景没有为企业的日常活动提供信息，那么它就无法实现。而操作业务模型则解释了组织在更细分的层面上是如何运作的，其中包括直接为创造和传递价值做出贡献的过程、资源和活动。如果没有与战略模型明确的联系，操作模型就存在走向低效和错误方向的风险。
因此，从战略模型向操作模型的转变是必要的，这是因为需要填补愿望和执行之间的差距。根据战略精心定义的操作模型，可以确保所有员工理解自己在实现整体业务目标中的角色。这种协调会导致协调的行动和集中的努力。
战略模型的转变从对核心原则的全面理解开始。分析目标客户群、价值主张、收入来源等核心要素，并分析其在操作中的影响。
在这种转变过程中，业务架构在将战略目标落实到操作能力的过程中，扮演重要角色。业务架构是指定义组织的业务流程、信息、技术和人员的结构、组成部分和关系的框架。它为组织如何运营和调整资源以实现战略目标提供了蓝图。
为了确保实现利益相关者的价值要求，需要价值实现框架是将利益相关方的价值期望转化为所需能力，并将所需能力需求落实到责任流程、以及业务模型要素中，以实现能力和解决方案。
将业务模型细化为操作层面的业务模型，需要依赖各种细化框架，比如创新框架等，这些框架有助于将战略概念具体化，将抽象的想法转变为具体的行动，使员工能够理解自己的日常工作如何体现为组织的目标。
在这个过程中，高质量的方法指南提供了执行特定操作的详细指导和最佳实践。这些指南通过确保一致性和效率，最大限度地减少错误以提升有效性。
此外，转化过程还包括识别关键绩效指标（KPI）来衡量操作模型在实现战略目标中的效率。这些KPI提供了对性能的反馈，促进了持续的改进。
最终，将战略业务模型转化为操作模型将形成一个协调和负责任的文化。通过这种方式，员工可以根据支持组织战略目标的信息做出决策，从而导致持续的竞争优势和价值创造。
操作层面的业务模型作为IT需求
借助战术层面的业务架构将战略目标转化为日常运营的操作层面的业务模型后，将作为业务和IT的共同语言，为业务人员和IT开发人员提供无缝衔接。
操作层面的业务模型，既是日常业务运营的执行的依据，同时为实施战略性需求实现过程提供了一个细节框架，以确保战略性需求得到有效传达并融入组织的日常运作中。这种细节视角有助于明确责任划分、工作流程和数据流动，从而在整个组织中建立共享的理解。
操作层面的业务模型中需要IT/数字化实现的部分，将作为IT需求传递给IT实施团队并立项。所以说操作层面的业务模型是业务的全局视图，促进了业务与IT两个领域间的协调。
操作层面业务模型的结构化特性，使我们能够清晰地文档化和标准化所有的业务流程和业务规则。这种结构化的格式使得沟通更为顺畅，确保IT解决方案能在明确定义的业务需求的坚实基础上构建。作为业务本体论中的中间层，运营模型连接了高层次的战略概念和底层的实施细节。这种连接确保了信息流动的顺畅，使IT项目能够直接支持战略目标。
操作层面的业务模型作为基础，构成了企业的业务本体模型，基于业务本来的逻辑，构建了合理的业务的知识神经网络。以业务模型作为IT需求，IT的迭代实现可以有效拼接起来，减少不必要的研发。
业务模型中包含了业务的解决方案，并且得到业务层面的验证和理解，以此为基础推进实施，减少了需求的模糊性和误解，最大限度地减少了开发不符合业务需求的解决方案的风险。
业务模型包含战略、战术到运营层面的所有细节，提高了在整个开发生命周期中的追踪性。这种追踪性使利益相关者能够追踪战略目标如何在IT系统中转化为特定功能。
运营业务模型通过鼓励对业务流程的共同理解，扮演了业务部门和IT部门之间的共同语言角色。这种共享的词汇促进了有效的沟通和协作，导致更好的协调，最终导致更成功的IT实施。
总的来说，运营业务模型为将业务战略转化为IT解决方案提供了结构化、详细且可追踪的框架。这个清晰且全面的模型是缩小业务和IT之间的差距，推动创新，并引领组织成功的非常有用的工具。
操作层面业务模型和数字化
操作层面业务模型和数字化
操作层面业务模型是企业本体模型的核心要素。在这里，本体模型是一个全面的框架，定义了特定领域（在这种情况下是企业的运营）的概念、关系和规则。操作层面的业务模型实现了组织的战略愿景，精确地描述了如何部署资源、执行流程和向客户传递价值。这种对日常活动的详细描述对于理解组织的实际运营现状非常重要。
由于这些丰富的细节，运营模型可以轻易地适应数字化。通过清楚地表达流程、数据流和决策点，我们可以为将模型转化为数字形式建立坚实的基础。
认知技术通过自动化以前由人类执行的复杂任务来改进运营模型。这些技术可以分析大量的数据，识别模式，并提供洞察，从而改善效率和决策制定。机器学习算法作为人工智能的一个子集，可以通过学习过去的运营数据来预测未来的结果，优化资源分配，并检测异常。这样，我们就可以提前调整运营模型，提高其响应性和适应性。
人工智能可以自动化整个运营过程，如客户服务交互、供应链管理和质量控制。不仅减少手工操作，提高速度，更可以提升质量和精确度。
借助语义查询能力，用户可以在运营模型中轻松访问和分析信息。利用自然语言查询，利益相关者可以更深入地理解模型的结构、关系和依赖性。
通过模拟工具，组织可以测试各种情况，并评估对运营模型的更改可能产生的影响。这有助于在现实世界中发生之前识别潜在的风险和机会。
决策管理系统可以自动支持运营模型中的决策过程。这些系统使用预定义的规则和算法，基于可用的数据推荐最佳行动。
通过微服务实现，可以将运营模型模块化为更小、独立的服务。这可以提高灵活性、可扩展性和恢复性，使组织能够更快地适应变化的市场环境。因此，这些数字技术不仅是简单的附加功能，而是改进和优化运营业务模型，提高效率和战略敏捷性的必要组成部分。
总之，基于业务模型，可以更优地采纳数字化手段。比如，认知计算可以提高渠道识别能力，语义认知和大型语言模型可以理解业务场景，机器人顾问可以提高组合建议，推荐系统可以基于客户画像定义推荐规则，动态决策系统可以定义决策规则，机器学习可以发现模型要素关系，数据挖掘和高级分析等都说明业务模型有利于数字化技术的有效实现。
操作层面业务模型到IT实现
操作层面业务模型到IT实现
经过文档化和数字化的操作层面的业务模型对于采用基于LLM（大型语言模型）的人工智能实现需求的重要性不言而喻。良好定义的操作层面的业务模型提供了明确性和结构，为AI集成提供了坚实的基础。
通过对业务流程的这种结构化理解，LLM可以快速把握IT需求的上下文和目标。尤其是以数字孪生形式表示的操作层面的业务模型，为业务提供了实时的交互式表示。这种数字复制品为LLM提供了一个动态环境，以理解各个组件如何相互作用以及各种任务的结果。因此，LLM可以生成更准确和有效的解决方案。
基于LLM的AI能够识别支持操作层面的业务模型的业务本体，因此可以与实际业务需求相匹配的方式解读需求。这种理解能够将抽象需求转换为精准的实质性的IT解决方案。而且，得益于操作层面的业务模型的结构化特性，LLM能够识别人类分析师可能忽视的模式和依赖关系。这种能力可以提高实施过程的效率和准确性。此外，操作层面的业务模型为业务用户和IT开发人员之间的沟通提供了标准化的词汇和框架。这有助于促进更简化和协作的实施过程，从而减少误解和重复工作。
业务模型的存在改变了IT的实现方式。基于LLM的AI利用操作层面的业务模型实现IT服务的方式，模型充当了自动化的蓝图。LLM可以使用这个蓝图来生成代码，配置系统和部署服务，从而最小化人为干预。LLM可以直接访问和分析操作层面的业务模型的数字孪生表示中的数据。这为IT服务设计和性能优化提供了宝贵的洞察。
IT服务实现时，对于事务型服务，LLM可以自动化工作流，数据有效性检查规则，安全协议生成，以确保事务的有效和安全处理。利用数字孪生的数据来优化配置。对于分析型服务，LLM可以支持数据挖掘，特征工程，模型学习，以加速机器学习算法的开发。LLM可以根据在操作层面的业务模型中定义的业务上下文，提出最合适的算法和参数。
此外，LLM还可以自动化IT服务的测试和验证，以确保满足所需的性能和稳定性标准。这种自动化的测试可以降低实施服务的错误和缺陷风险。
总的来说，操作层面的业务模型促进了基于LLM的AI的引入，AI利用这个模型自动化和优化了IT服务的实施。这种业务模型与AI协同的作用实现高度的自动化研发。IT解决方案的实施质量和敏捷性得到了提高，可以更准确，更有效地应对业务需求的动态变化。
以下提问，来自2025年10月DACon数智大会（由DataFun策划）关于“本体论”实践的闭门研讨会，BMG公司基于自身实践，分享了其核心见解，现整理如下以供探讨。
1. 如何通过本体论，将散乱的数据表升级为能映射、模拟、预测真实业务运转的活的系统？
重点是要实现从“数据记录”到“业务语义”的转变。散乱的数据表仅仅是业务发生后留下的“已发生的事实”，它们本身是离散的、缺乏业务语义的。要实现对业务的模拟和预测，关键在于理解并形式化地定义数据背后的业务含义、关系和流程。这正是本体模型所能提供的。
我们认为，要让数据在业务语义层面真正发挥作用，与其从现有数据自底向上进行梳理、承担较高的成本，不如采取自上而下的方式，从业务关注的核心问题入手。首先应明确：企业为何需要这些数据？希望实现怎样的业务目标？所关注的业务场景与流程是什么？需要执行哪些关键动作，才能获取对业务有价值的信息？最终希望交付什么样的价值？关键在于，始终围绕“为什么需要”和“业务目标是什么”展开思考，而不是仅仅停留在“我们有什么数据”的层面。
本体模型可根据其成熟度划分为不同层级（更多细节请参考本体模型的层次https://bmgovernance.com/zh/hierarchy-of-ontology-models_zh/），各自适用于不同的业务目标。一级成熟度（数据模型），即您现有的数据表与数据字典，主要描述数据的物理结构，尚未充分表达其背后的业务含义。二级成熟度（业务实体与关系），在这一层级，会识别出核心业务实体（如“客户”“订单”“产品”），明确其属性与实体之间的关系（如“客户与订单”），以及每个定义对应的目的、多维的含义和多维的范围，从而为数据赋予初步的业务语义。若要进一步模拟或预测真实业务行为，则必须构建具备三级成熟度的本体模型, 不仅包含实体模型，还整合了市场模型、业务流程与决策模型等, 明确定义每个流程环节所消耗的资源、创造和交付的价值，以及约束与指导流程的逻辑规则（例如“仅VIP客户可享受此折扣”）。业务语义都体现在业务模型中。举例来说，即便已定义“约定转账”的含义，若缺乏流程支持，仍无法模拟其创建、取消或修订的操作。如图所示，流程模型中明确了企业内外流程的交互节点、输入输出、政策制度、关键决策以及对价值的理解——流程的根本目标正是实现并交付价值。脱离业务流程，实体所能发挥的作用将极为有限。本体模型还有更高的成熟度，此提问所需的到三级成熟即可。在构建包含业务模型的本体之后，我们将已有的历史数据“迁移”或“映射”至该模型中。唯有如此，数据才能在业务语义层面真正发挥作用。
总而言之，成功的关键在于目标明确与手段合理，不应让业务迁就数据，而应让数据在一个精心设计的业务本体模型包括实体模型、流程模型、决策模型中“复活”，从而可以利用数据模拟并预测业务操作。
图1-操作层面的业务流程示意
2. 在构建知识图谱时，我们是否过于关注数据的“躯体”（实例），而忽略了定义其关系和逻辑的“灵魂”（本体）？
这里需要明确数据、实体，实体模型和本体模型，以及本体模型和知识图谱的区别。
首先区分数据和实体。
数据记录的是已发生的历史事实。例如，“张三”这个名字出现在客户数据表中，仅仅代表一个过去的记录，数据模型表示了已经记录的数据之间的关系。有很多业务感兴趣的定义是没有记录在数据库中的，而且数据模型也难以表述概念的业务定义，比如对于客户，客户表中有可能获取了客户的联系地址以及客户与账户的关系，但是不一定有客户与各类地址（户口所在地、公司地址、居住地址、邮寄地址等等）的关系，也不一定有客户与客户的关系、客户与员工的各种历史关联等。
而实体模型的根本目的，在于准确反映业务的关注点与内在语义，必须为其中每个定义明确其目的、内涵与范围，这一点至关重要。例如，客户与地址之间的归属关系、与产品之间的持有关系、与员工之间的服务关系等，都需要清晰地阐述。这里，每个定义的业务目标不同，会影响模型和定义。比如“客户”这个定义，若目标是扩大市场占有率，那么所有访问过官网或进行过产品咨询的人，都可能被视作“客户”；而若目标是提升现有客户的生命周期价值，则“客户”可能仅指那些已完成签约并有实际消费记录的用户。这些关键的业务语义与复杂关系，均在实体模型中得以定义。但即便如此，实体模型仍不构成本体模型的全部。
其次区分知识图谱和本体模型。
在一般意义上，知识图谱主要通过“节点”和“关系”来表达知识，其侧重点在于描述具体的实例以及实例之间的关联。这种方式相对更偏向于对数据实例及其关系的直接呈现，而在知识的系统化分类与深层结构组织方面有所不足。
而本体模型则是承载企业认知的语义，随着成熟度的不同，可以包含多维度的内涵定义、关联关系、价值关注以及动态变化。相应地，本体模型的成熟度也分为不同层次：若仅为了从历史事实中发现关联、掌握数据及其标准，那么包含数据和数据字典的一维本体模型已能满足要求；若旨在构建统一的业务定义，则需要引入二维本体模型，即在语义层面定义业务实体及其关系；若要解决业务问题、推动业务创新并支持决策，则需建立三维本体模型，纳入使实体产生价值的业务流程、规则与逻辑；若期望实现企业的持续优化与转型，乃至构建数字孪生，则需引入具备时间维度的四维本体模型，以支撑并预测企业或客户在动态环境中的多维度演变。（更多细节请参考本体论定义）。
总之，我们认同本体模型是必不可少的，企业需要更具自身的目标，选择适合的本体模型的成熟度、深度和覆盖范围。
3. 如何将模糊的业务概念（如“客户价值”、“供应链韧性”）精准定义为机器可理解的“类”、“关系”和“属性”？推动业务、技术、数据团队就此达成共识的路径是什么？
“客户价值”、“供应链韧性”这类模糊的业务概念转化为机器可理解的模型，本质上是一个业务建模的过程，需要依赖结构化的本体模型来准确反映业务语义。此处，需要关注以下几点。
首先，本体模型中所有的名词都需要具体化，形容词需要量化。以客户价值为例子， “客户”这一名词必须被明确定义，包括其目的、内涵与范围，客户的标识、联系方式以及多维分类方式等等。价值一词也需要被量化。例如，需明确“客户价值”指的是客户自身的价值期望，还是客户对企业的贡献价值，并进一步根据业务目标，将其转化为诸如“年消费金额大于100万元”或“最近一次消费在30天以内”等具体、可被机器识别与执行的规则。
其次，本体模型具备不同的成熟度级别。要厘清复杂的业务概念，往往需要借助多维业务模型。这类模型不仅包含定义“事物”的实体模型，也涵盖描述“如何运作”的流程模型。以“供应链韧性”为例，
实体模型会定义“供应商”“仓库”“运输路线”“库存”等实体及其相互关系；而对“韧性”的理解，首先要确定是和响应与恢复能力还是灵活性与冗余度相关的指标，然后需要通过流程模型（如采购商品、入库商品、配送货品等），识别影响韧性的关键环节（如“供应商交付货物”“选择运输路线”等），进而将这些环节与实体（如供应商的历史准时交付率，路线风险等级）相挂钩。由此，“韧性”不再是一个模糊概念，而是转化为一系列可监控、可优化的具体节点与指标。
此外，业务目标的不同也直接决定了本体模型的构建细节程度。根据目标层级的差异，业务模型可被定义至不同的详细程度，一级关注价值链、二级关注收入及竞争力、三级关注客户的价值、四级关注角色的责任、五级关注决策逻辑。举例来说，若目标是制定业务条线计划，建模仅需到达商业模式层面（三级）。此时，“客户价值”需明确客户定义、客户标识及各类关系，但无需定义所有的属性；价值也需转化为具体指标，如“高净值客户群对收入的贡献度”等，并需要明确相关价值活动与产品特征。若目的是提升市场竞争力与产品创新，分析不同客户细分的利润率和忠诚度，则模型需要细化到客户的目标工作（job）与具体期望及痛点，并结构化定义产品提案、产品特征、渠道特征、实体与属性、业务场景及决策依据。若目的是需优化具体业务操作，则必须定义至最细的五级业务模型，即操作层面的业务模型，其中不仅包括所有属性，还需明确其取值范围与约束条件。
最后，必须认识到，本体模型作为企业的统一语言（更多细节请参考https://bmgovernance.com/zh/depth-of-the-ontology-model_zh/），很难依靠自下而上的方式在跨团队间达成共识。其成功必须依赖于自上而下的系统性保障。需要决策者亲自引领目标并深度参与，需要由企业级架构师zh整体设计，需要专职团队负责构建统一的本体语义资产库与配套环境，需要实施持续的优化与治理机制。共识的建立是个持续实践过程，无法通过一次性会议或零星事件驱动来实现，而是需要将本体模型融入企业日常的操作流程中，整合到需求分析、产品创新、客户服务等所有过程中，确保所有协作都在共同的语义基础上进行。
4. 设计本体论的T-box（规则层）是最高阶的挑战。我们应如何定义业务中的“公理”？例如，在信贷风控中，“控股关系具有传递性”这条规则，应如何制定并保证其被所有系统遵守？
所谓“公理”，是所有参与者的共同认知与基本规则。本体模型作为企业的统一语言，是企业业务公理的载体。在制定规则时，需要汇总所有相关方的业务诉求。例如，针对“控股关系”，信贷业务条线、风控团队、授信审批、监管及合规等不同部门的理解可能各不相同，这就需要在建模过程中汇总并协调各方的业务兴趣点。
其次，业务规则渗透在业务模型的方方面面。以信贷风控中“控股关系具有传递性”为例，在实体模型中，该规则体现在“公司”实体的“控股股东”属性上。此属性的定义（如“对另一公司有超过50%的表决权”）、其取值的唯一性约束（如一个公司在某一时刻只能有一个控股股东）、以及“控股关系”作为一种关系本身的逻辑特性（传递性），都要在实体模型中定义。在流程模型中也会有规则的定义，比如执行判断、审批授权、风险评级等环节。而在产品与市场模型中，规则体现在产品条件的依赖关系、客户细分维度等方面。例如，当“变更企业所有方”事件触发时，在执行“重检公司风险”活动时，有可能需要执行“识别最终控股人”任务。此时，流程中的规则将依据实体模型中定义的控股关系传递性，追溯控股链条，解读公司客户所涉及的产品中是否存在相关限制与约束，从而触发尽职调查和风险预警。
应该说，实体模型包含了约70%的业务规则。细化业务规则是一个持续的过程，而建模方法是明晰语义的强大工具。以实体模型为例，起初可能只是简单构建了公司及公司关系实体并定义了属性。通过针对属性进行九个标准化方向的泛化（如图所示），可以逐步细化业务规则：1）分析每个属性是否隐藏其他含义？例如，若初期建模时将“控股”作为一个属性，在明确其含义时可能发现“控股”隐含了“表决权”和“分红权”，从而需要优化模型。2）分析属性含义是否完全覆盖且相互排他？例如，控股关系的类型是否覆盖所有情况且无重复。3）分析某一时刻属性是否存在多个取值？4）分析属性在不同时点是否会发生变化？如果回答“是”，则可能引出新的实体，例如“控股关系生命周期”。5）分析属性的各样本取值是否完全相同？例如，若“可传递性”作为属性，但在不同情况下存在差异，则需要进一步细化。6）分析属性的取值是否适用于所有样本？例如，若“持股比例”是一个属性，但存在多种计算或表述方式，就需要区分属性或引入新的实体。7）分析属性的取值是否可由其他数据派生？例如，若“持股比例”是一个计算值，则需要找到其计算公式和信息源，确保没有遗漏关键业务概念。8）分析属性的颗粒度是否可进一步优化？9）分析所有属性是否基于唯一标识等。每个泛化标准都是帮助细化业务规则的重要工具。
最后，为保证各方遵循统一的规则定义资产，需要落实三种角色和能力：一是企业架构师，负责战略对齐、架构设计、方案落实，在出现冲突时提供架构解决方案，并推动实现统一的资产平台；二是统筹协调者，负责达成共识、促进有效沟通、协调各方工作并优化管控机制；三是拥有决策权威的责任人，作为本体模型的“所有者”和“最终裁决者”，对关键决策负责。
图2-属性的泛化规则
5. 在AI Agent时代，“LLM + 向量数据库”的RAG模式是否足够？为何必须引入“本体论”来确保决策的严谨性、可解释性与一致性？
在AI Agent时代，仅依赖“LLM + 向量数据库”的RAG模式已远远不够（请注意，向量数据库只是实现RAG的一种技术路径，而非全部）。尽管RAG通过检索增强提升了生成答案的准确性，但其本质上处理的仍是非结构化信息的语义匹配。这种方式缺乏对世界进行深度结构化建模与理解的能力，从而导致决策在严谨性、可解释性和一致性方面存在天然局限。
引入本体论（更多细节可参考：https://bmgovernance.com/zh/ontology-is-the-foundation_zh/），正是为AI Agent构建一个结构化的“世界观”，从根本上保障其决策的可靠性。具体而言：
结构化确保严谨性，防止逻辑谬误。本体模型以结构化方式定义语义，可涵盖业务模型与动态变化。仅依赖文档RAG的Agent，可能因训练数据中的矛盾或语境缺失而忽略关键规则。而接入本体模型的Agent，则能理解企业自身的业务语言与明确定义，严格遵循语义逻辑进行推理，避免逻辑跳跃和仅基于统计的事实错误。
增强可解释性，提供含有语义的推理链条。RAG能够提供答案的“出处”，但往往只是碎片化的文本片段。本体模型则能呈现符合业务内涵的清晰推理路径。例如，当Agent做出“拒绝该集团授信”的决策时，不仅能引用相关文档，还能根据模型关联推理：“公司A控股B，B控股C” → 根据本体定义的关系和规则推出“A控股C” → 合并计算A、B、C的总负债 → 触发风控规则。这种基于业务含义与关系的追溯机制，使决策过程清晰、可追踪、可信任。
维护一致性，实现全局语义统一。缺乏统一的本体模型，不同业务条线或不同时期的Agent可能对同一概念（如“客户”是指现有产品顾客，还是包括潜在或历史顾客）产生歧义，进而引发决策冲突。企业级本体模型作为“唯一的真实资产库”，为所有Agent提供了统一的语义基础。无论Agent服务于风控、营销还是供应链，它们对核心业务概念和规则的理解都同根同源，从而确保跨领域、跨时间决策的一致性。
总结而言，LLM与RAG赋予了AI Agent处理海量非结构化知识的多样性，而本体模型则赋予基于结构化的语义进行推理的能力。本体模型明确了业务的目标、语义与规则，构成了AI Agent的“理性骨架”。要在复杂决策中充分发挥AI的潜力，结构化的本体知识与来自文档的非结构化知识，都是需要的。
6. 当前主流的“LLM+向量数据库”RAG模式，本质是语义检索和内容生成。如何融入本体论，使其具备逻辑推理能力？例如，让AI不仅能找到甲公司的财报，还能基于规则自动推断出其关联公司的潜在风险。
在当前以“LLM + 向量数据库”为代表的RAG模式中，其本质是语义检索与内容生成，能够在一定程度上解决“知道什么”的问题。然而，要真正实现具备业务理解与逻辑推理能力的AI，就需要引入本体论作为其“大脑”，为AI提供结构化的业务逻辑框架。这里，架构的设计尤为关键。如图所示的架构设计，可以让AI Agent 拥有执行具体任务的角色能力，获取结构化的本体知识和非结构化的文档知识，并能够注入动态变化的语境，
在架构层面，需要将业务本体作为语义模型结合执行角色的能力注入到AI智能体,比如AI Agent首先从企业级的业务本体和分类学中，提取与选定流程相关的语义，包括业务目标、操作层面的业务模型以及IT模型等。这些结构化的知识为AI Agent提供了进行逻辑推理所必需的概念、逻辑关系（关联公司）和规则（风险级别和规则）。为了进行推理需要理解非结构化知识，利用RAG技术，从向量数据库中检索与非结构化知识（如监管文件、操作手册、风险报告、历史财报、培训视频等）相关的信息。
而且需要让AIAgent 掌握随时变化的动态语境，通过模型语境协议(MCP)，让智能体理解实时动态信息和外部算法、从系统中获取最新数据，以及最新财报、市场动态(比如关于甲公司所在行业的最新负面政策新闻），以及挖掘的场景目标和上下文与范围等内容，注入到AI智能体中。
AI Agent不应仅仅是一个“检索-摘要”工具，而应成为具备推理能力的决策引擎。能够结合记忆模块与注入的语境，理解本体模型的业务语义，进行推理、研判结果、综合评估，最终通过LLM等AI技术生成可理解的反馈。例如，基于本体模型所提供的“公司关联关系”，构建出“甲公司 → 乙公司 → 丙公司”的血缘图谱；再结合动态语境（如行业负面新闻）与静态知识（如乙公司财报中的风险点），进行风险传导分析。其推理过程可能如下：“甲公司所在行业面临风险，而乙公司对甲公司业务依赖度高于某种程度，且其自身财报表现触发了约定限制，因此乙公司的风险很可能通过控股链传导至甲公司，进而波及整个集团。”最终，AI Agent将根据预设的风险规则与合规要求，输出分析依据、验证结果与应对建议。
需要指出的是，企业对本体模型的认识与运用程度，取决于其发展目标与战略定位，而其中更为关键的，需要企业级架构师及架构团队的整体设计与落地执行能力。
图3-人工智能AI代理
7. 当我们需要多个AI Agent协同完成一个复杂任务（如自动完成信贷审批）时，本体论如何成为它们之间无歧义协作的“共同语言”和“行动准则”？
在多智能体系统中，本体模型的核心价值在于提供一套共同的语言与行动标准，为所有智能体提供全面、共享、无歧义的业务知识，确保每个Agent对术语和操作的理解完全一致。基于不同成熟度，本体模型可以包括数据字典、实体关系、业务模型及动态变化等多维度模型，每个本体对象都可具备多维度的语义内涵、多元的价值创造方式、复杂的关系网络以及随时间演变的动态属性。通常而言，本体模型的维度越丰富，其成熟度就越高，所能支撑的智能协作与业务价值也就越显著。
在多智能体系统中，本体模型的核心价值在于构建一套统一的语言体系与行为准则，为所有智能体提供全面、共享且无歧义的业务知识框架，从而确保每个Agent对术语语义与操作逻辑的理解高度一致。
每个AI智能体都以本体模型所构建的语境作为其实现目标。所有Agent对概念（如“客户”，以及“客户与地域的关系”）的理解，都严格遵循本体模型的唯一权威定义；而且基于流程模型定义的行为准则（例如“申请贷款”），对业务事件、流程协同、任务的分解与流转都由统一认识；并可基于决策模型则规范每个Agent行为（如“批准贷款额度”）的前置条件、逻辑处理与后置效果。
作为AI智能体的统一业务语义基础，本体模型与AI Agent架构深度融合，为其提供了目标、指令、角色责任、上下文与规则等一系列共同语言与执行标准。这种设计使得多个Agent之间的任务传递与协作能够如精密齿轮般无缝衔接，所有智能体围绕同一业务目标，依循逻辑链条被有序串联，如同被一根隐线贯穿的珠链——虽不可见，却始终在统一的语义框架下协调运转，提升协同的可靠性与精准性。
如感兴趣，欢迎访问 https://www.youtube.com/@BusinessModelGovernance 获取相关视频，其中展示了基于本体模型的多智能体协作系统，如何在实际应用中完成理财组合分析的实例。 
图4-数字孪生使用示例
8.业务在快速变化，本体论如何迭代？谁应拥有和维护这套“业务宪法”？
在快速变化的业务环境中，企业的动态性体现在各类需求之中——包括战略能力的实现、生态创新需求的落地、流程的持续优化，还是操作层面的改进需求。为应对这些变化，企业可采用“从项目到产品”的演进方式，持续优化和完善本体模型。这一过程是持续性的，需要企业设立专职团队，并持续投入时间与资源进行维护与更新。
企业需要两套模型的协同运作，一是企业级本体模型，作为需求实现的起点与规则基准，可以简约但必须具备；二是基于特定需求范围构建的项目/方案级模型，属于为满足局部或临时性业务目标而设计的解决方案。当新的业务需求出现时，团队首先依据企业级本体模型界定范围；项目团队随后设计相应的“项目级方案模型”。关键在于，项目方案必须最终回归并整合至企业级本体模型中，才能验证可行性。项目成功上线后，其方案模型中经过验证的物理实现也需被吸纳进企业级本体模型。这一闭环过程必须依赖平台化与智能化手段的支持，仅靠人工难以实现高效与一致的管理。这意味着，本体模型的更新并非凭空设计，而是伴随每一个业务需求的落地，逐步迭代、“生长”而成。
如图所示，企业级本体模型作为统一的语义基础与资产库，其唯一性与可信性至关重要。所有用户，无论是业务侧还是技术侧，都应基于同一份权威、一致的资产信息开展工作。因此，企业必须建立并维护唯一可信的本体模型——该模型涵盖业务模型及所有需求定义。为确保模型的有效治理与持续一致，本体内容需通过明确的角色与职责矩阵进行管理，清晰界定业务所有方、业务操作方、业务实施方、技术所有方及技术实施方等各类角色的权责。同时，企业必须确保所有团队能够便捷地获取并使用这一统一模型，从而在全局范围内保障语义一致性与协作效率。
未来的企业竞争，从某种意义上将是本体模型的竞争。企业应依据自身认知与治理结构，明确具备权威与能力的责任主体，负责本体模型资产的拥有与维护。在此过程中，三大原则至关重要：唯一性原则：企业必须有且仅有一套统一的、公认的业务本体模型，作为“唯一可信源”；嵌入式管控原则：模型的使用与遵从机制应嵌入至项目与运营流程中，而非依赖事后检查；权责对等原则：模型的所有权应赋予具备相应决策权（财务、人力、冲突）的人员，例如C级别高管，使其能够调动资源与财务支持，确保治理的有效性。
图5-基于本体的数字孪生资产库
9.构建和维护一套高质量的本体论与知识图谱，初始投入和长期成本巨大。如何向决策者证明其价值？它的ROI应如何衡量？（是减少决策时间、避免风险损失，还是提升运营效率？
首先，我们需明确本体模型与知识图谱的区别。本体模型是对现实世界的一种结构化描述方式，强调多维度的信息整合，包括丰富的内涵定义、复杂的关联关系、多元的价值关注以及动态的变化过程。相比之下，知识图谱（通常意义的定义）更侧重于通过“节点-关系-节点”这一基本结构来表达知识，其重点在于呈现实例与实例之间的关联，属于一种偏重数据层面的表达，通常在知识的系统化分类与深层结构方面有所欠缺。
企业对本体模型的认知与定位，根本上取决于决策层的发展视野与战略意图。若仅将其视为成本支出，那么即便建成也难以发挥价值，本体模型反而可能成为负担；反之，若将其定位为企业的“数字大脑”，则它将演化为AI时代的关键竞争力，系统化提升整个组织的认知水平与决策质量。其投资回报（ROI）并不直接体现为节省了多少人力或时间，而是反映在更高维度的收益上：例如基于本体模型的AI推理能够识别隐藏的关联风险（如集团客户间的风险传导），从而避免重大损失；又或者体现为“机会捕获型ROI”——通过统一语义和自动化逻辑推理，将业务需求至系统实现的周期从“月”压缩至“周”，显著加快产品上市速度。
在实施路径上，通常存在两种典型方式：自上而下与自下而上。自上而下是从企业战略与核心业务概念出发进行整体设计，这种方法能最大化长期价值，但对业务目标、架构与创新能力与组织协同能力要求极高；自下而上则是从现有系统或局部数据切入，起步较快，能迅速解决具体问题，但容易陷入“局部优化”困境，缺乏整体一致性，未来整合成本高、整体价值有限。
企业可以尝试“T型”混合策略，以兼顾两者优势：“一横”（顶层设计）：在较短时间内，与企业战略层共同勾勒出企业级本体的整体蓝图与核心目标，如同装修前的整体设计图，确保未来各模块风格统一、互联互通。“多竖”（敏捷试点）：选择目标明确、价值可衡量的业务领域（如某一金融产品或业务活动），纵深构建本体覆盖，像“一个房间一个房间装修”那样逐步推进数字化。
成功推进还需把握几个关键点：首先是让决策者亲身见证价值，最好能亲自参与甚至动手体验AI Agent如何借助本体模型在具体场景中化解痛点、创造价值；其次是培育创新文化，企业应营造允许试错、鼓励使用新技术解决核心业务问题的组织氛围。
总而言之，构建本体模型不是一项IT开支，而是一次战略投资。通过“T型”策略，企业可在整体规划下逐步推进数字化转型，使“数字大脑”从试点场景中持续成长，最终成为AI时代企业核心竞争力的坚实基石。
10.如何让本体论层与现有的关系型数据库、数据中台、业务系统协同工作？是颠覆性重建，还是渐进式覆盖？
我们理解，企业数据赋能的核心挑战在于弥合业务语义与物理数据之间的鸿沟，而解决之道在于构建统一的语义层。本体模型正是这一语义层的具体实现，它为整个企业提供了一套关于“事物”及其“关系”以及“行动”和“规则”的语义共识性。相比之下，IT系统中存储的往往是分散、异构的数据表与字段。若缺乏本体模型这一语义层，业务人员将难以直接、高效且准确地使用数据资产。
引入本体模型作为语义层，其目的并非颠覆或取代现有系统，而是充当它们之间的“通用翻译官”与“业务指挥家”。现有的关系型数据库、数据中台及业务系统，既是企业的宝贵资产，也因其数据模型的分散与不一致，技术多样性难以维护构成了巨大的技术负债。本体模型作为语义层，正是将这份“负债”转化为“资产”的核心桥梁。通过构建本体模型，逻辑地整合和利用散落在各系统中的数据，为能够将物理系统和数据在业务逻辑层面进行整合提供了可能性，以支持业务目标的实现。
在具体构建策略上，通常面临“颠覆性重建”与“渐进式覆盖”两种路径选择，这好比是“建造一座新城”与“改造一座旧城”的区别：
颠覆性重建的优势在于架构统一、重复投资少、无历史包袱。缺点在于对能力要求高，如果没有已经验证的方法、可靠的本体平台，前期投入巨大、实施周期长、业务中断风险高。以往这类项目动辄以年为单位，尽管现代技术手段已能将其缩短至月级别，但其高风险性仍使大多数企业望而却步。
渐进式覆盖优点在于起步快、影响范围小、能快速在特定业务场景中交付价值并验证方向。其挑战则在于整体转型周期可能更长，具有重复投资，过程中需持续解决新旧体系之间的冲突与融合问题，维护成本高，需要长期坚持和强大的治理能力。
最终，路径选择并非纯粹的技术决策，其成功关键在于企业的认知、决心与执行力。这考验的是企业是否具备拥抱创新的文化，以及决策层能否直接参与、具有洞察力和意愿，有足够魄力打破既有观念，并以坚定的执行力持续推进这一战略转型。无论选择哪条路径，将本体模型作为企业语义层来构建，都是通往数据驱动与智能决策未来的必由之路。
11. 你认为Palantir崛起最值得我们反思的是什么，最值得我们学习借鉴的又是什么？
我们认为Palantir最值得反思和借鉴的有以下几点
1、以本体模型为”数字基石”，统一企业认知：Palantir将本体模型提升至战略高度，未来的业务竞争是本体的战争。构建企业统一的大脑，不仅是统一的语义层，更是组织唯一可信的资产，是数字孪生的基础。
2、以价值为主，精准指引发展方向：Palantir始终将价值创造作为核心导向，并坚持对价值进行量化衡量，涵盖客户价值与企业价值双重维度。在AI赋能过程中，公司聚焦于客户的痛点问题与核心目标，将模糊的“提升有效性”转化为可衡量的精准指标，例如“将高价值客户收入占比在18个月内从20%提升至35%”。这种对价值定义的严谨态度，确保了AI能力始终对准客户最关键的业务痛点，有效避免了技术资源的浪费。
3、聚焦“实体-行动-规则”，实现业务决策闭环。Palantir 深刻把握价值实现的内在机制，以业务实体明确业务关注的事物，以流程行动定义可行动步骤，以决策规则建立判断逻辑。将静态知识转化为动态业务行为，确保AI所产生的洞察能够嵌入并驱动关键业务流程，从而构建从认知到执行的完整闭环。在这一体系中，所有行为与实体均围绕业务决策展开，真正体现了AI在复杂环境中赋能决策的实际意义。
4、以“智慧失败”为进化机制，将试错成本转化为组织资产。在我们长期的观察与实践中，最具启发性的是对“失败”的重新定义——将试错从一种成本转化为一种资产。通过构建快速实验与反馈的机制，每一次“失败”都被视作一次宝贵的认知收获，基于目标和架构系统化地沉淀为组织的共同经验。这种机制使组织成为一个持续进化的有机体，不是畏惧失败，而是在不断试错中实现持续迭代与成长。
总之，高层洞察力和坚持，对本质和系统化思维的认识，对价值和目标的持续追求，远比任何单一技术更值得深入学习（更多细节请参考https://bmgovernance.com/zh/数字孪生/）。
e-mail : [email protected]
引言：你是在沙滩上建造城堡吗？
您的公司是否正在为AI转型投入巨额预算？但你是否准备好面对这个残酷现实——大多数AI项目最终未能达到预期，甚至以失败告终？问题的根源往往不在于数据或算法的匮乏，而在于缺少一个能够被称为业务“中枢神经系统”的核心基础。
正如谚语所说：“串起来的珠子才是宝。”孤立的数据和技术，就像散落的珠子，本身无法创造价值。它们需要一根“线”，将所有元素有意义地串联起来。这根线，就是定义业务中所有概念与关系的“活蓝图”——也就是“本体论”。
本文不仅将带你超越对新技术的简单介绍，更将提出五项战略指令，它们将从根本上重塑你的AI战略。
____________________________________
1. AI并非仅靠数据驱动：为AI植入业务的“世界观”
我们或许以为使用AI是要“处理”数据，但事实并非如此。数据要发挥真正价值，AI必须理解业务“语境”。本体论正是为AI提供业务“世界观”的语义基础——它定义了业务由哪些概念构成、这些概念如何关联、以及遵循何种规则运作。这就像一部人类与AI都能无歧义理解的“公共字典”。
全球数据分析公司Palantir的成功印证了这一点。他们的核心竞争力并非仅是大数据技术，更是“基于本体论的数据整合”能力。这种方法将不同数据源编织成连贯的整体，为组织从数据中创造价值确立了新范式。
仅能识别模式的AI，与真正理解业务的AI，存在本质区别。本体论将AI从精密的数据处理器，提升为能够理解业务语境并根据语义进行推理的合作伙伴。这正是决定无数AI项目成败的关键。
结论： 仅会识别模式的AI已经是成型的商品；而理解你业务本体论的AI，才是无可替代的竞争优势。
2. 无法执行的业务模型，只是一叠昂贵的废纸
业务模型不应只停留在PPT或Word文档中。正如“从战略到代码”理念所示，它必须成为直接驱动实际运营和IT系统的详细蓝图。
关键在于定义“操作层级的业务模型”。战略构想必须落实到员工的具体工作和数字系统中，定义到产品规格、定价策略、客户细分等细节层面。这个“操作层级的业务模型”不仅是详细设计方案，更是你业务本体模型在代码中的实现——将抽象战略转化为驱动实际操作的具体规则与关系。
这一理念是解决大多数企业“战略与执行脱节”的关键。当业务模型本身即是可执行代码时，企业才能真正实现业务敏捷性——在业务变化时，IT系统能即时响应。
结论： 要弥合战略与执行之间的断层，就必须将业务模型从PowerPoint转化为可执行的本体模型。
3, 古代哲学家早已决定AI的未来：亚里士多德 vs. 道家
令人惊讶的是，AI技术的核心挑战与古代哲学洞见深刻相连。特别是两种哲学观点的融合，将决定业务的数字化未来：
– 亚里士多德的实体论：将世界视为由独立、可分类的“对象”构成。这构成了现代数据库和面向对象编程的基础，在定义稳定的认识结构方面具有优势。
– 道家的变化论：认为世界并非由固定实体构成，而是持续不断的“变化与关系”之流。“道”是万物的根源，也是恒常变化的生生不息的水恒流变自身。这为捕捉业务的动态性提供了不可或缺的视角。
能够同时容纳稳定结构（亚里士多德）与动态变化（道家）的本体论（体现在本体模型中），才是构建复杂且不断演进的现代业务“数字孪生”的核心哲学。
结论： 您的业务是静态“名词”的集合，还是流动的“动词”过程？正确答案是“两者皆是”。无法承载这种双重性的AI战略，只能取得一半的成功。
4. 切勿只依赖ChatGPT：构建你公司专属的“本地大脑”
仅依赖外部通用AI是危险的。真正的竞争优势来自将公司独有知识的资产化。这需要“知识工厂”的战略——以结合外部AI与内部AI：
– 全球大脑：如ChatGPT，拥有海量外部知识的通用AI。
– 本地大脑：基于公司特有业务本体论，学习内部业务模型、产品、流程与客户数据的专属AI。
这个“本地大脑”是前述哲学融合的终极技术实现。它既能将业务中稳定的“是什么”（亚里士多德式对象）编码化，同时也是一个持续学习并适应业务操作“如何做”与“为何做”（道家式流变）的体系。构建“本地大脑”可以保护企业的知识资产，避免敏感数据外漏，既保障安全，又可以将公司独有的语境与差异化融入AI，以此实现无法复制的竞争优势。
结论： ChatGPT等是人人可用的公共图书馆；企业真正的优势在于谁能率先构建自身专属的机密资产库——“本地大脑”。
5. 这一切并非理论，而是现实
这并非空谈，而是已被证实的实践。本文来自著作《利用本体论与人工智能创新业务价值》（尚未出版），正是由AI作为合著者参与撰写的。作者使用名为“知识挖掘（Knowledge Miner）”的AI，挖掘并提炼了书中海量内容。
这正是所有所述概念(本体论、知识工厂、本地大脑等)确实可行的最有力“证据（Proven evidence）”。它是理论与实践的完美融合的案例，也清晰揭示了在AI时代，人类应专注于哪些创造性角色。
“在数字/AI时代，构建负责协同的串珠子的‘线’将成为人类必须从事的核心工作。‘线’是创造性的，而珠子是可以被挖掘出来的。本书所阐述的，正是人类将从事的创造性工作。”
结论： 应将挖掘“珠子”的重复工作交给AI，人类则专注于贯穿一切的创造性“线”——即本体论的设计。这才是未来知识劳动的核心。
____________________________________
结论：你的业务拥有怎样的“大脑”？这个大脑在哪里？
真正的AI创新，不在于简单引入新技术。它始于构建一个将业务所有知识、关系与规则体系化结构化的“动态的数字模型”——即本体论。本体论是串联散落珠子的“线”，是理解业务的AI的“世界观”，是连接战略与执行的“代码”。
现在，请审视您组织的“大脑”：它是如同化石般僵硬的Excel与PowerPoint碎片，还是已准备好思考未来、适应变化并赢得胜利的活神经网络——本体论？这个答案关乎你的业务未来。
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 即时生成样板 |
|
如何学习与成长 |
Javascript function traditionalLearning() { |
Javascript |
|
解决问题的方法 |
– 独立思考 |
– 与 AI 头脑风暴 |
|
代码质量与一致性 |
– 依赖开发人员个人风格 |
– AI 自动应用最佳实践 |
|
创造力与实验性 |
– 实现可行性优先 |
– 探寻“这可能吗？ |
|
主要区别概述 |
Vibe Coding 将开发者从“代码打字员”进化为“软件架构师”。AI 负责处理重复性和机械性任务，而开发者则专注于创造力、解决问题和创造商业价值。这不仅仅是工具使用方式的改变，更是我们思考和处理开发方式的范式转变。正如计算器的出现将数学家从简单计算中解放出来，使他们能够专注于更复杂的理论研究一样，Vibe Coding 也让开发者能够专注于解决更高层次的问题。 |
|
参考文献：
- 演示视频：业务能力工厂 – DREAMER（2025）
- 参考网站：http://www.bmgovernance.com
在现代企业环境中，本地大脑大语言模型接口已经成为企业赖以驾驭复杂商业环境的关键工具。作为知识工厂的一个重要组成部分，本地大脑的建立，不仅能深度理解公司行业和客户，还能确保公司的知识和洞察力能满足其特定需求和挑战。
首先，本地大脑通过开发全面的业务本体来构建，包括对公司产品、服务、流程和市场动态的深度理解。这种深度理解是全球大脑可能缺乏的，但对企业来说却是至关重要的。有了这个本地大脑，企业就能够把握住行业和客户的细微差别，从而制定出更精准的战略和决策。
其次，本地大脑可以是基于业务本体构建的任何语言模型，该模型是在公司内部数据的基础上训练而成的，使其能够理解公司的具体情况并产生独到的见解。这种见解能够帮助企业洞察市场趋势，挖掘潜在的商业机会，从而取得竞争优势。
此外，本地大脑的建立是一个集合企业内部各利益相关方智慧的过程。主题专家们将他们的专业技能和知识融入到业务本体中，使其能够捕捉到行业和客户的细微差别。同时，企业的流程和工作流也被映射到本体上，形成一个操作层面的业务模型，详细介绍公司的运营方式。
创新枢纽提供的本地大脑大语言模型接口的能力不仅在于其深度理解企业和行业，还在于其能够生成独到见解，以及其集合企业内部各利益相关方智慧的能力。它是全球大脑的有力补充，使企业能够提出符合其目标和独特需求的见解和解决方案。通过利用本地大脑，企业可以降低单纯依赖全球大脑所带来的风险，确保所提供的知识和建议准确无误并符合公司需求。它是企业提升竞争力，驾驭复杂商业环境的重要工具。
利用大型语言模型和人工智能工具，可以更有效地开发和优化解决方案。理解问题是解决方案开发的核心。我们通过与客户、合作伙伴和内部团队进行深入对话，以了解他们的需求和期望。我们使用大型语言模型，分析和解析这些对话，从而更好地理解问题的核心。
我们还会利用业务模型和知识工厂来定义和优化我们的解决方案。问题澄清的过程和构建解决方案都可以借助人工智能工具。这可能包括使用机器学习算法来预测未来趋势，或者使用自然语言处理工具来解读明确隐含的问题，或者借助大语言模型深度探索问题的关联和可能的方案。
在这个多次中，定义提示是另一个关键步骤。提示可以帮助我们更深入地理解问题，并找到可能的解决方案。这些提示不仅需要明确地表达问题的目标，还需要定义期望的答案格式和推理参数。探索解决方案后，借助AI可以模拟解决方案的效果，同时也会利用大型语言模型来生成可能的解决方案，也可以比较评估每个解决方案的优点和缺点，从而找到最佳的解决方案。
在找到最佳解决方案后，我们会进行测试和验证。我们利用人工智能工具来模拟解决方案的实际效果，同时也会利用大型语言模型来生成测试报告。我们会根据这些报告来调整和优化我们的解决方案。
综上所述，利用大型语言模型和人工智能工具，我们能够更有效地理解问题，构建和探索解决方案，并进行测试和验证。这种方法不仅提高了我们的工作效率，也使我们能够提供更高质量的解决方案。
业务本体在需求工程中的重要性不可忽视。需求工程是一种工程化方法，它全面跟进并落实需求，以实现业务模型的数字孪生。在这个过程中，业务本体扮演了关键的角色。业务本体是对业务领域知识的系统化表述，包括概念、关系和规则。本体模型是一个核心知识图谱，为组织和管理公司的知识资产提供了一个结构化框架。
从本质上讲，业务本体是一种以系统化有组织的方式定义业务世界的方法。涉及企业感兴趣的业务、规划、运营以及与生态、环境互动的所有关键概念，以及概念的关系，包括数据、元数据、模型、元模型、元模型的模型等所有的知识内涵及关联关系。业务本体的主要目的是为业务领域提供一种可在整个组织内使用的通用语言和理解，业务本体模型可以清晰地揭示出业务需求的内在逻辑和关系，从而有助于精确地捕捉和描述业务需求。
在知识管理中使用业务本体，首先，有助于确保知识的组织方式易于查找和使用。这是因为本体为组织信息提供了清晰的结构，从而更容易浏览和定位特定的知识片段。其次有助于确保知识的一致性和准确性。通过定义业务范畴内的关键概念和关系，本体有助于确保每个人都使用相同的定义和对这些概念的理解。这有助于避免混淆和误解，以免造成代价高昂的错误。
而且，业务本体论还有助于改善组织内部的协作和沟通。通过提供对业务领域的共同语言和理解，不同团队和部门可以更容易地协同工作和共享知识。这可以提高决策的效率和效果，并为整个企业带来更好的成果。
以下客户的项目中签约使用SOLVENT平台
- 中国建设银行（CCB）
- 中国银行（BOC）
- 中信银行（CITIC）
- 上海浦发银行（SPDB）
- 中国建信金融科技有限责任公司（CCBFintech）
《数字孪生构建方法论》（包括《持续价值创新方法论》）在中国有超过20家金融机构（包括所有大型商业银行）中得到应用与验证。