【人工智能】基于“大模型”的智能化转型思路（通用版）

背景：

近几年，随着国内外大模型产品的批量涌现，如：ChatGPT、DeepSeek、Grok、文心一言、Kimi、豆包等，人工智能技术再次引发现象级关注，下一轮技术革命——人工智能，也逐步成为全社会的共识。

为赶上这次技术革命，需要持续学习、了解人工智能相关的知识。但当前网络上的各类知识：

• 要么过于专业，即使搞研究的人员也很难看懂；
• 要么过于表面，内容空泛，多存在夸大和误导性。

针对上述问题，结合在日常学习、工作中对技术和市场的理解，便萌生了一种想法：计划以通俗的语言把人工智能发展的一些关键概念、逻辑讲清楚，供各位参考。

（声明：本人非专业科研人员，如有描述不准确/错漏之处，还望批评指正，十分感谢！）

本篇内容，主要梳理——基于“大模型”的数字化转型思路。

2025年春节期间，DeepSeek横空出世，似乎一举斩断了西方在人工智能方向的技术领先优势，各种宣传铺天盖地。

春节后，在DeepSeek技术的带动下，很多地区政府机关、大中小企业发起了“智能化转型工作”，三个月过去，大家冷静下来后，我们发现这些项目基本都是“雷声大、雨点小”，渐渐没有动静了。

从前几年提出的“数字化转型”，到近两年的“智慧化转型”，我们在开展这些工作的过程中，似乎总是呈现虎头蛇尾的现象，给人一种“眼看他起高楼、眼看他宴宾客、眼看他楼塌了”的观感。

笔者经过在多个项目中的沟通、交流和复盘，也想借此机会，谈一下对这些事情的看法。

总的来看，笔者认为，出现上述问题，还是几个原因导致：

1. 认识不足：缺乏对信息化技术工具的认识
2. 完美主义：总想等所有条件都具备后再启动
3. 缺乏路径：没有一套完整的方法论指导

下面，结合实际工作，对这几个问题逐个分析下，希望能给大家提供一些参考。

一、认识不足

很多机构在推行数字化转型或智慧化转型的过程中，还是缺乏基本的认识，容易做出“拍脑袋”的决策方案，主要包括以下几方面。

（一）缺乏对数字化转型的认识

我们先来看几个数据：

1. 福布斯的调查报告显示，84%的企业在数字化转型中遭遇了失败；
2. Everest Group研究表明，73%的企业表示没有在数字化转型中获得任何商业价值；
3. Gartner公司调查发现，84%的受访者表示数字化转型体验未达到预期目标。

为什么会出现上述问题？

其实可以分析很多原因，但归根到底，我认为，最普遍、也是最根本的原因是：

管理者普遍缺乏对数字化转型的认识，习惯于把数字化技术同经营管理制度和体系割裂开来看待，没有把数字化转型是服务发展、服务经营的意识摆正。

也是基于对上述问题的认识不够，才导致数字化转型过程中出现的下列各类情况：

1. 速成型：对数字化转型的长期性缺乏认识，想要一蹴而就
2. 烟囱型：无法突破各级部门间的管理制度，难以筑牢根基
3. 盲目型：缺乏专业的专家带领，没有统筹规划，盲目上线项目
4. 阻碍型：没有大领导的牵头督办，各项工作开展举步维艰

最终导致企业/政府机关在数字化转型中面临失败。

不仅如此，还形成一种很不好的风气：

1.配合度差：各单位工作人员都认为数字化转型就是一个空话，不再愿意配合

2.市场萎靡：似乎谁再提数字化转型，谁就是大忽悠，大家也普遍不再开展此类工作

但总的来说，数字化转型还是企业/政府机关发展的必经之路，前期的工作都是有一定价值的，至少积累了经验，不能因短期没看到成果就放弃。

要做好数字化转型，关键不在于技术，而在于提高对数字化转型的认识——数字化转型是不同于过往的信息化升级的，在数字化转型过程中，技术只是提供工具支撑能力，要结合实际经营管理体系和制度，以数字化的技术能力，赋能/重塑全套经营管理工作，以提升效率、增加效益、提高产品及服务质量。

（二）缺乏对大模型的认识

受各类媒体的误导，管理层往往认为大模型是能直接解决当前一切实际问题的“灵丹妙药”。比如：

• “大模型可以实现编程，你这个平台为什么还要我这么多钱？”
• “大模型能直接梳理项目流程，为什么你们现在还在用这么low的管理工具？”
• “大模型能统计和分析数据，为什么我想要的那些数据你们还给不出来？”
• ......

总之，就是一个思路——认为大模型能解决一切问题。

但对于懂行的人员来说，这就是一个极大的误解。

说到底，大模型本质还是一个“更加智能的技术工具”。相当于给你提供一个计算机，但需要你来想好算什么、怎么算，再借助计算机算出来。

有了这个工具，那对于专家来说，就可以计算各种复杂函数；对于小学生来说，就只会计算加减乘除。所以大模型的使用效果是取决于使用人和使用方式的。

所以，在很多时候，不得不频繁跟各级领导解释：

1.大模型能力范围：无论是chatGPT、DeepSeek、还是Grok，在当前的发展阶段，其智慧化、自动化程度还远未达到新闻媒体宣传的效果。

2.大模型自动化程度：大模型或许在一定条件下可以编程，但其专业性、自动化程度、全面性、可用性、以及与现实需求的结合能力都有待考量。

退一步说，即使大模型可以提供想要的代码，但软件开发是一个复杂的系统工程，其工作包含了“需求分析、原型设计、可行性研究、系统架构设计、数据库设计、模块接口设计、安全设计、UI交互设计、环境搭建、代码开发、版本控制、测试方案、模块测试、缺陷管理、部署环境、发布管理、运维监控、项目管理、文档管理、风险管理”等等多项工作，涉及多个工种的协同保障，并不是单纯靠一两段代码就能完成的。

虽然能解释清楚，但往往还得落下一个埋怨：“是不是你们技术能力不够啊，我看新闻上说的怎么着怎么着......”，可以理解，毕竟把大家美好期望戳破的人是不受待见的，虽然是实话。

归根到底，要认识到——大模型的本质是一个智慧化工具，可以在某些方面为人类社会提供智慧化辅助和支持。但距离真正实现大家想象中的自动化、智能化，还有很长的路要走。

（三）缺乏对场景化应用的认识

上文提到，大模型是一个泛智能化工具，旨在帮助各业务环节提高效率和自动化、智能化程度。

在实际的行业应用中，比如政务服务、医疗服务、教育服务中，可能会细分出数千个场景，每个场景都有一套对应的逻辑和流程，并不仅仅是通过一个泛智能化工具就能解决场景化应用难题的。

对这方面认识不足，就会导致提出很多让人哭笑不得的要求：

1.你直接给我在网上爬一下数据，让我看看区域内有多少家企业

2.你用大模型给我分析下地区的高危风险企业，然后动态展示出来

3.你能不能给我部署一个大模型，能代替医生给病人看病

......

在这里，关键还是要认识到——要真正解决各方向各场景中的堵点、难点问题，一定是要结合该场景的实际工作流程、机制、模式开展，大模型等各类技术只是一些支持手段，关键在于业务流的打通，工作模式/机制的调整，整体业务模式的贯通。要依托实际业务开展方式，统筹完成“数据、大模型、应用”三位一体的建设工作，才可能取得实效。

（四）缺乏对数据要素的认识

现阶段，数据要素已经越来越成为人工智能行业的重中之重了。没有详实而具体的数据，即使再酷炫的应用界面、再强大的模型能力，也是“巧妇难为无米之炊”。

但很多人，还是缺乏对数据要素的理解：

• 要么认为，你给我从网上直接爬出来数据就行
• 要么认为，你从那些有数据的人手里买一些数据就好
• 要么认为，我这儿有一些数据，你应该直接把知识库给我建成

这些想法还是过于单纯，甚至过于儿戏了。在真正的业务应用中，比如：

• 如果要提高企业服务能力——可能涉及到的数据包括“企业基本信息（这个里面又包含了企业注册信息、股东信息、人员信息、对外投资、分支机构、企业联系方式等上百条信息类型）、企业标签信息、企业经营服务信息、企业信用风险信息”等等，仅仅要获取的信息类型就有数百条；
• 如果要建设政策的咨询服务——也不是说把一些政策文件爬出来就行，而是要进一步将其中的各类要素分解出来，才能精准地为使用人员提供服务和帮助。
• 在大多数服务中——即使前期已经收集齐了所有类型数据，但在实际应用场景建设过程中，还是要根据特定需要来调整数据的维度、类型。同时，还要开展数据治理工作，才能保障数据的质量和可靠性。

总的来说，数据要素的收集、治理、使用是一个复杂的系统工程，绝不是“爬一下、买一点、把现有数据上传上去”就能搞定的。

二、完美主义

很多单位在开展智能化转型过程中，容易出现“完美主义”倾向。

说两个典型的案例：

（一）案例一：数据要素治理

两个同级单位同时启动了数据要素工作。

• A单位：在开展工作期间，发现数据来源有问题、数据应用不明确、也不清楚怎么做，在建成一个工具平台后，就把这件事放下了；
• B单位：当然也遇到了类似问题，但B单位有个特点，就死磕。缺数据就要，要不到就买，实在没有就安排团队摸排，用了五年时间把一套数据要素底座搭了起来。

结果：等到DeepSeek等大模型横空出世的时候，B单位很轻易的就利用之前的数据开展了各项能力建设工作，而A单位这时候才发现，还得重新把那五年搁置的路走一遍......

（二）案例二：“干中学”和“学完干”

这个典型的案例关于“卫星”的。

1.马斯克如何做卫星

大家应该听说过，马斯克发射了很多卫星，用于建设“星链”。

那问题来了——马斯克的技术成熟吗？他想好“星链”怎么建设了吗？他解决了星链传输等一系列问题吗？

答案是：不成熟！没有！没有！

但是马斯克这个人的特点就是，我先做，做的过程中“逢山开路、遇水搭桥”，做着做着就做成第一了，就没有竞争对手了。

纵观马斯克的发展历史，无论是特斯拉，还是火箭回收，都是这个逻辑。

2.一些研究机构如何做卫星

不同于马斯克，很多研究机构，采用了另一种方式——先把“星链”可能遇到的问题都设想一遍，再通过理论、建模等方式，逐个把问题试验解决。

当然不是说这种方式就不好。

关键问题是——

1.研究的问题都是假设的，在实际应用中会不会发生都不太好说，更别提在实际应用中普遍存在的问题偏离情况了，有可能很多前期理论研究都是无用功。

2.更要命的是，随着马斯克的卫星发射越来越多，优势卫星轨道很快就会被对方占满，到时其他机构就只能占用其他轨道资源了，成本和代价必然是更大的。

说这两个故事：

• 一方面，是提醒大家，很多工作都是靠长期的坚持来完成的，不是一朝一夕的事；
• 一方面，也是建议，之前在技术、模式、发展比较落后的时候，我们还能参考欧美等发达国家，但是在当前，我们已经立在潮头了，很难有人给我们提供直接、系统的参考了，很多事情都只能是走一步看一步，碰到问题再解决问题，很难一蹴而就。

三、路径参考

当然，大多数企业/政府机关，可能苦于没有一套完整的路径参考，所以在智能化转型过程中走的磕磕绊绊。

在此，结合过往的项目经验，提供一个相对通用的智能化场景建设工作开展路径，仅供大家参考。

整体智能化场景建设工作，建议遵循“需求筛选—>数据打通与治理—>应用开发—>试点运行—>推广应用”流程开展，下面对各个环节进行详细的介绍。

（一）需求筛选：明确当前要建设的场景应用及目标

在开展此阶段工作中，主要原则如下——

1. 明确主要服务对象：以政务服务场景为参考，其主要服务对象为“企业、群众、领导、工作人员”，所以在需求规划中，主要了解这四类用户的痛点、堵点难题。
2. 优先高频应用场景：任何场景化建设都需要结合实际业务流、数据流开展，都需要消耗时间、人工、资金等资源，建议优先开展高频应用场景筛选，以解决当前“急难愁盼”的堵点问题。
3. 业务部门配合程度：场景化建设工作，要依托业务部门在实际工作场景中的痛点、堵点，做模式、机制、流程等优化或重建，也将涉及业务部门工作流程的调整或重建，确保业务部门是可以完全配合开展工作是非常必要的。
4. 场景的可落地性：有一些应用场景，在当前的执行过程中，存在很多的不规范性、不确定性，比如：某项办事流程需要提供很多非标准化的资料、数据，或者涉及到多个层级多个单位的审批（中央、省级单位、市级单位、区级单位），或者现阶段就没有特别明晰和准确的流程系统（比如很多环节只能线下办理）。如果针对此类场景开展建设，就会遇到多部门协调、流程规范化、数据规范化等多项额外工作成本，建设会存在很大不确定性。

所以在建设规划之初，就应对该场景的“整体业务流程、所需数据支持、所需配合系统、需要配合部门”等多个维度进行清晰的梳理，确保数据可获得、各部门能配合、业务流程相对规范标准，系统可打通穿透，如此才能确保场景化建设工作的顺利推进。

在本环节中，需要明确如下信息：应用场景、业务全流程（包含：涉及系统、涉及部门、涉及人员）、数据需求及数据类型、数据获取方式。

（二）数据打通与治理：完成数据的归集治理形成可用的知识库

在开展此阶段工作中，主要工作如下。

1. 数据框架搭建：一方面，根据场景化建设需要，完成对应的数据知识库搭建；另一方面，寻求有相关经验的团队协助，提前开展各类知识库框架搭建。
2. 数据对接归集：根据数据框架中明确的数据需求、数据类型、数据获取方式，对接数据提供方，通过“数据库、API、文件系统”等方式，实现存量数据的传输，并建设数据共享机制（按天、按周等），以保持数据的更新。
3. 数据质量治理：结合数据应用的需要，将归集的数据，通过向量化、OCR识别、清洗、整合等大数据治理能力，建立分类体系、提取核心数据要素、构建多维度数据标签，形成知识图谱（知识库）。

在本环节中，需要实现如下输出：各类知识库框架/标准建设、场景化知识库/知识图谱建设。

（三）应用开发：完成全套应用场景的对接、开发、部署

此阶段，就基本进入了执行阶段，交给软件开发团队按进度推进即可。

但要注意的是——

1. 及时沟通：在开发过程中，要实时保持沟通和跟进，确保整个功能的开发不偏离原定需求及方向；
2. 积极参与：要调动业务部门的积极性，让业务部门时刻参与此阶段工作，了解进展；
3. 尽早测试：在具备测试条件情况下，第一时间给业务部门测试使用，来明确使用感受、问题，方便及时调整。

在本环节中，需要实现如下输出：实际应用、应用模型的建设（小程序、网站、甚至建模工具都可以，只要能实现功能的端到端支持）。

（四）试点运行：开展小规模试用，发现问题、优化实现

在正式上线之前，要开展小规模试用。

比如有20个窗口工作人员，可以先开通2个窗口做试用。

小规模试用主要是为了避免几个问题：

1. 使用感受差：贸然大规模启用，很多人的习惯改不过来，可能出现各类负面情绪和问题，包括过多的咨询问题，也会让支撑人员措手不及，造成不好的使用感受。
2. 不可预知问题多：通过小规模试用，可以很好的发现场景化应用的问题，敏捷迭代，避免被有心之人利用，造成舆论等各类压力。
3. 前期成本高：初期小规模试用，也可以避免在基础设施资源上的过度投资和浪费，便于快速调整方向，节省资金压力。

在本环节中，主要是通过试用总结经验、优化不足、判断是否具备正式上线条件。

（五） 推广应用：培训并正式投入使用

如果通过了前面的试用，就可以针对该场景的全体业务人员进行培训了。

通过培训，确保所有工作人员的意识到位、实操能力具备，再正式投入试用中。

在此环节需注意：

1. 支持到位：安排足够多的支持人员，避免大量咨询类问题同时出现，无人接应；
2. 版本回退：要预留一定量的原业务环境，避免出现系统性问题无法处理；
3. 收集问题：要定期（每天）收集和统计问题，逐步优化场景化应用；
4. 关注舆论：要及时关注各类舆论消息，避免被有心之人利用。

如果能顺利完成1-2个月的试用，基本就通过这个阶段验证了，也就得到了各方的认可了，可以开展下一个场景化应用的建设工作了。

以上，通过介绍“认识不足、完美主义”问题，并给出“路径参考”，提供给大家“基于’大模型‘的智能化转型思路”，希望能解答困扰大家的问题，给大家一定参考和帮助！

如有不足，还希望批评指正！

2025年5月7日  北京