用最简单的大模型技术打造一个迁云专家有多难？

云迁移是将客户现有系统从传统IDC或友商云平台迁移至阿里云的技术过程。尽管我们有各种云迁移工具、标准解决方案，也总结过标准方法论，但在实际交付中，每个大型企业级项目仍必须配备资深迁云专家全程把控。这看似矛盾的现象背后，折射出云迁移领域两个深层次的技术命题。

任何标准化方案都建立在特定的前提和假设之上，然而真实的生产环境往往远超预设边界。例如，DTS在处理SQL Server的增量迁移时存在一些限制，或RedisShark在应对Redis大Key时会面临吞吐量瓶颈。当项目进入现场的方案选型与验证阶段，专家必须凭借深厚的实战经验，对现有方案进行灵活地选择、组合甚至改造，才能继续推进。

《云迁移方法论的三阶六步与实际迁移的“凌波微步”》

理论上，云迁移看似遵循“调研-设计-实施-验证”的瀑布模型，但实践中，它更像一个螺旋式上升的迭代过程。一个真实的项目，往往需要经历多轮“深度调研 → 方案优化 → POC验证 → 局部实施”的循环。随着调研的深入，一个已确认的方案，很可能因后续某个技术点的验证效果不佳而被重新审视。这个过程极其考验决策者的定力和智慧，需要专家能够持续推动、敏锐应变、不惧试错，通过“微创新”为项目寻找最优解。

《云迁移项目反复论证方案的过程》

归根结底，在一个复杂的企业级项目中，光靠着标准的工具、方案、方法论往往不足以支撑客户自助的完成云迁移。迁云专家的核心价值，是抹平标准方案与现实的差距，并动态化解实施过程中的不确定性。这里的“专家”，不仅指阿里云技术服务团队，也包括那些技术能力深厚的客户架构师，他们同样也很擅长担任这个角色。

既然云迁移过程需要一个专家，这让我们自然地想到：大模型能否胜任“云迁移专家”这一角色？尤其在朋友圈充斥着“30分钟搭建RAG应用”等论调的背景下，RAG似乎已成为垂直领域AIGC最成熟、门槛最低的解决方案。

基于此，我们迅速启动了验证。团队整理了近千篇内部技术沉淀文档及官方产品文档，借助百炼平台的RAG框架，快速构建了知识库。诚然，工程搭建的便利性毋庸置疑，但真正的挑战也随之而来。

虽然现成的RAG 功能，避免了我们自己实现切片、向量化、排序、双路召回等复杂的工作。但是对于知识本身的不会因为工程化而降低质量要求，反而因为能够参与的搜索链路改动更少，文档的格式要求变得更高。而我们看到的现状是我们通过语雀、钉钉文档、线下PPT与Word等一系列的材料并没有统一的知识维度。有的是概要的方法论，有的是项目历程介绍，有的是技术设计细节，有的是问题排错日志。不光知识维度不同，不同材料之间还存在大量的准确性问题：版本陈旧、背景模糊、互相矛盾......这些文档搜出来，一股脑儿丢到大模型，那出来的结果自然是支离破碎、逻辑混乱。

正如人类专家需要通过频繁的系统调研和用户访谈来获取决策依据，大模型同样严重依赖高质量的上下文。当前对RAG的前沿研究，如Agentic RAG，也正强调模型主动感知与理解环境的重要性。然而，传统的RAG交互模式，往往鼓励用户用“一句话需求”去换取“完善的解决方案”。这种模式显然过于理想化，忽略了迁移场景的复杂性——用户一句话需求背后，可能隐藏着对迁移成本、数据安全、割接平滑度、云上架构性能等多维度的隐性约束。如果模型无法获知这些关键背景，就无法生成真正可落地的方案。这是简单RAG应用在实践中暴露的另一大局限。

我们期望大模型能替代专家，但专家脑海中那套结构化且灵活的权衡决策，却是最难被编码和传递的。

一位迁移专家在设计方案时，会同时考虑云上架构和网络搭建；考虑数据迁移和应用适配；考虑系统负载和技术风险；考虑系统割接和业务影响。更重要的是，这些模块并非孤立，而是相互掣肘、动态关联的。例如：

• 为了缩短项目周期，可能会放弃复杂的增量数据同步方案，但这同时也意味着需要接受更长的业务中断时间。

• 因为无法精细拆分业务流量，选择一次性割接所有系统，这同时也意味着需要承受更大的潜在爆炸半径和回滚风险。

专家既能够在模块化的方法论框架内全面思考，又能跳出框架，洞察到跨模块、跨周期的“蝴蝶效应”。相比之下，当前大模型生成的方案往往缺失章法，也没有整体观和权衡智慧，这也是我们认为其与真正专家的核心差距所在。

在我们团队，拥有像刘衍（被誉为“迁云之神”）和观省（人称“大数据搬站王”）这样的顶尖交付专家，他们在应用和大数据迁移领域积累了不可替代的实战经验。然而，专家的精力是有限的，其“并发度”远不能满足日益增长的项目需求。同时，并非所有项目都像“某头部旅行公司”或“某头部互联网社交平台”那般超大规模与极端复杂，也就是说他们八成的能力也能完成项目交付。因此，我们提出了一个核心目标：如何利用大模型，复刻专家80%的核心能力，从而让更多项目能享受到高质量的专家级支持？

同时，作为一个面向客户的技术服务团队，我们选择了一条对广大企业更具参考价值的务实路径起步：不自建GPU集群，不从零“炼丹”，仅依靠阿里云上成熟的大模型API与百炼平台，验证一个专业AI应用的构建的可行性。

带着这个使命，内部代号为“LX0.1”（刘省0.1）我们正式开工。

俗话说，巧妇难为无米之炊。无论是人类专家还是AI，高质量的输入（上下文）是产出有效方案的前提。在云迁移领域，我们经过反复研讨，将云迁移方案生成所需的核心上下文定义为三大要素：

1.调研结果: 对客户源端环境的全面信息采集。

2.产品选型: 目标端阿里云产品的规划与映射。

3.原子方案: 针对一对源端和目标端的标准化解决路径。

这三要素存在递进关系，构成了迁移项目方案的骨架。为了高效获取“调研结果”，我们充分利用了云迁移中心（CMH）的王牌功能——“资源调研”，它能自动化采集源端信息，为后续分析提供精准数据。这种自动化数据采集 引导 精准知识召回的模式，我们认为，这本质上就是一种高效的Agentic RAG实践。

《用大模型生成迁移方案的上下文》

我们深知，一个新手的成长路径离不开三类知识源：“前人经验总结”、“云厂商官方文档”和“开发者社区实践”。自然，这些也构成了我们AI知识库的基石。但与人类不同，RAG对知识的质量和结构极为敏感，如果知识库中存在大量同质化、甚至相互矛盾的内容，AI可能会召回错误信息并将其写入最终方案。为此，我们没有直接“喂”给AI海量文档，而是进行了一次彻底的知识库重建。

我们根据最终方案的生成目标，将知识体系划分为“原子方案”、“固定场景方案”、“汇总方案”等多个类别，并为每一类知识精心设计了标准化的标题、内容框架、原理图片。然后，我们利用大模型自身强大的文本处理能力，对现有文档进行自动化地挖掘、清洗和重构，将其转化为真正结构化、高质量、可信赖的知识。

《知识加工示意图》

有了上下文和高质量知识库，如何引导AI像专家一样有条不紊地撰写一份长篇、复杂的方案呢？如何克服单一提示词在面对长文档生成的遗忘问题？我们的解决方案是：化整为零，模块化生成。

我们将一份完整的HLD（High Level Design）方案拆解为架构设计、产品选型、迁移路径、风险评估等多个独立模块。每个模块由一个独立的Prompt来引导，并调用与之相关的特定知识库子集进行撰写。这就像一个“专家委员会”，每个“委员”负责自己最擅长的部分，最后再将各自的成果组装成完整报告。这种架构不仅保证了各章节的专业深度，还天然支持并发生成，将一份数千字方案的生成时间缩短至原来的1/10甚至更少。

《独立模块的生成和组装》

磕磕绊绊，经过团队几个月夜以继日的打磨，以及对刘衍、观省两位专家不厌其烦地“骚扰”和请教，“LX0.1”——这个承载着我们期望的AI专家助手，终于在CMH上，作为“CMH迁移助理-智能方案”功能[1]与大家见面。现在，您只需复用CMH的调研能力或上传一份调研表，它就能为您总结系统和负载情况、规划目标云产品、提供原子方案，并最终生成一份图文并茂的完整HLD（High Level Design）方案，甚至能调用Mermaid工具为您绘制清晰的架构图。

《“CMH迁移助理-智能方案”功能截图》

我们深知，当前的“LX0.1”，仅仅是迈出了从“0”到“1”的第一步，距离完美复刻专家智慧、彻底解决云迁移中标准化与反复论证的复杂问题，仍有很长的路要走。另外，过程中我们对大模型现阶段的能力边界有了更加清醒的认知，也坚定了我们持续迭代的决心。接下来，我们的核心工作就是建立一个高效的“犯错-改错”闭环。

与传统的单次对话生成不同，CMH的迁移助理将方案生成过程拆解为多个步骤。这种“分而治之”的架构在提升稳定性的同时，也给效果评估带来了新的挑战——一个简单的“点赞/点踩”已无法准确定位问题所在，而让用户对每一步生成结果都进行详细反馈又不现实。

为此，我们按照系统架构的思路，同步设计了一套分层评测体系：

• 按技术架构分层：我们将评测目标拆解到RAG架构的各个环节，分别对“基础模型”、“百炼平台应用”和“客户端实现”进行独立评估。

• 按内容质量分层：我们将评测维度细化为“事实准确性”（如产品参数、API调用是否正确）和“内容规范性”（如行文风格、格式是否符合标准）。

通过这套体系，评测结果能清晰地将优化方向指向具体的模块，无论是需要调整“提示词”、优化“知识内容”、改进“召回排序”，还是修复“工程缺陷”，都能做到有的放矢。

《分层的评测方案》

生产环境不比实验室，即便AIGC的准确率达到95%，那剩下的5%错误对于具体某个带着需求的用户而言，也可能意味着100%的不可用，而不可用是一个生产系统不能容忍的。因此，我们在产品设计之初就融入了“面向失败设计”的理念，赋予用户充分的控制权。

• 全流程可编辑：从上下文构建到最终方案生成，大模型产出的每一步内容，用户都可以在界面上直接修改。这意味着用户可以快速纠正AI的微小偏差，并让后续流程基于正确的信息继续执行，既不用全盘推倒重来，也会阻塞正确的答案生成。

• 对话式迭代：云迁移方案往往需要在反复论证中不断演进。我们通过对话式的交互，模拟了客户与专家之间的沟通场景。用户可以通过自然语言提出修改需求（例如“将应用迁移的方案从SMC镜像迁移改成客户自行重新部署”），AI便能精准地对方案相应段落进行重写，极大提升了方案的迭代效率。

《截图：对话式引导大模型修改方案》

完成了所有技术层面的“拳法”后，我们怀着一丝忐忑，将“LX0.1”作为CMH迁移助理的首个功能正式上线。即便是设计了各种评测，但是我们深知冰冷的内部评测数据无法完全代表产品的真实价值。这个AI助理是否真正解决了用户的痛点？我们的设计思路是否切中了实际需求？我们更想从用户体验中找到产品的调整方向，在真实用户的“吐槽”中寻找价值出口。于是乎，我们也加上了小小的用户调研，期待各位客官给出宝贵的建议。

《CMH迁移助理功能的调研问卷结果》

行文至此，我们完整回顾了如何利用现有的大模型API，成功构建并上线了一款面向云迁移领域的RAG应用。在此，我们简要回应文章开头提出的挑战：

• 我们通过高质量知识库与大模型泛化能力的结合，致力于弥合标准化方案与复杂现实之间的鸿沟。

• 我们通过定义清晰的上下文与增强用户交互，尝试应对迁移项目反复论证、动态调整的特性。

• 我们通过模块化提示词工程，将资深专家的隐性经验沉淀为可复用的模板，企图复刻真实交付体验。

然而，一份方案的生成仅仅是云迁移的起点。后续的POC验证与大规模实施依旧是极其严格的挑战，并且这些都需要“真刀真枪”的实操能力。

这恰恰是AI在云迁移领域更广阔的未来所在。我们正在积极探索两个方向：

1.从“规划者”到“执行者”：迈向自动化迁移。 借助阿里云MCP Server和完善的SDK体系，和当下AI强大的代码生成与理解能力，我们逐渐探索了一条通过Vibe Coding 和MCP相互结合的行为方案，将AI从一个“顾问”升级为“工程师”。

2.从“同构”到“异构”：攻克应用现代化难题。 行业趋势也印证了这一点，例如Amazon Transform 在辅助.NET Framework现代化改造到跨平台.NET 。在我们的实践中，无论是异构数据库迁移，还是云上数据湖的构建，都存在大量代码转换和逻辑重构工作。如何利用大模型提升这些改造任务的效率与准确性也是一个不简单的命题。

《畅想：用AI全面改进云迁移的过程》

AI时代像一个巨大的历史车轮，呼啸着滚滚而来。作为奋战在一线的技术服务“手艺人”，我们怀揣着双重使命：既要脚踏实地，利用AI为当前工作提质增效；也要仰望星空，将沉淀的最佳实践分享给客户，共同推动技术浪潮的前行。

大模型技术的演进速度感觉真的是按“天”计算。身处这股洪流之中，我们的感受是复杂的——交织着焦虑、憧憬、困惑、向往。但我们相信，穿越这种不确定性周期的最好方式，就是回归本心：踏实地立足真实场景，在持续的探索中寻找答案。