前言

我平常会更喜欢写技术类型的博客，其实很少写思考类型的博客，这一次本来我是已经写了几篇博客：

  • 结合 RAG 构建你的知识库
  • 利用 transformers LoRA 微调模型
  • 训练属于你自己的 AI 问答模型

写完这些之后，说实话，我有点意兴阑珊。不是因为技术不酷，相反，这些 AI 强大得令人兴奋。然后我发现这些内容好像少了点灵魂，而且网上的教程已经足够多了，特别是视频，一步步教你微调，比我的肯定要详细，于是思考了一下，重新构思才有了今天这篇文章。相比手把手教你敲代码、调参数，我更想聊聊这段时间在尝试“结合 AI 开发应用”过程中一些感悟。这更像是一场自我反思，也希望能引发一些同路人的共鸣。

结合的方式

首先来说说结合 AI 开发应用的方式，实际中当然有很多，我总结分类一下为：

  • 直接利用 AI 对话能力
  • RAG
  • 微调
  • MCP/Agent

所以我将从这几个分类聊聊尝试过后给我的感受。

直接利用 AI 对话能力

这是最直接、门槛最低的方式。开发者通过设计精心构造的提示词（Prompt），调用大型语言模型提供的对话/补全 API，让模型根据输入生成文本输出。我试过的几个场景是：

  • 问答
  • 摘要
  • 翻译

都很不错，接入方便好用，大家也都知道，而这里结合和能否成功的关键在于 产品化。因为这个门槛最低，你的产品交互能否让用户感觉丝滑特别重要。

我的总结思考是：让普通人跳过和 AI 对话的步骤，直接得到想要的结果（路径缩短），这是这类产品的目标。

当然它的缺点是不够专业（我叫作知识局限性），毕竟它得到的数据都是公开的，对于它从来不知道的事情来说，它也 无能为力。那么就需要下面的技术了。

RAG

从你提供的个人数据库中检索出最相关的信息片段。然后将原始问题 + 检索到的相关上下文一起打包成一个新的 Prompt，发送给 AI 生成最终答案。

这里的检索往往都会采用向量的方式，之前我也写过向量数据库相关的文章，有的时候检索结果并不尽人意（不过我也没优化过）。

而其实尝试过 RAG 的同学应该都知道，这个方式最大的问题就在于数据的搜索出来的准确性：

  • 如果原始的问题在你的数据集里面本来就没有答案，凉凉
  • 如果原始的问题在你的数据集里面有答案，但是你通过搜索的方式没找到，也凉了

我的总结和思考是：如果你本来就能通过搜索内容找到答案，那么借助 RAG 能更好的帮助你将答案组织为可读的逻辑给到用户；相反如果本身你的搜索能力就不及格，那就别指望它了。

微调

通过技术微调已有的模型，从而建立专业领域的模型，来完成特定领域场景的任务。

其实就是在一个预训练好的大型语言模型（基模）上，使用你指定的数据集对模型的一部分或全部参数进行额外的训练。目的是让模型更擅长解决你的特定任务或适应你的特定领域语言风格。

微调给我的感受有两个：

  • 训练数据很重要，验证数据更重要。我往往找到了一大堆数据可以进行训练，但是如果仅仅只是训练，你是无法评估你微调前后的差别的。也就是说你无法评判一个微调模型的好坏，那你实际去用的时候其实是没底的。
  • 没办法保证后续的训练不会对前面的训练有影响。

而微调其实现在已经比你想得要容易了，已经有了很多开源的解决方案来帮助你微调模型，你几乎只需要改改参数，就可以了，有的微调甚至还有 UI 可以直接选择等等。甚至一些云厂商可以直接支持数据微调，并直接提供微调后的模型运行。

最重要的是什么？成本！训练成本(小)+运行成本(大)，是否能支撑合理的运行成本是你是否要采用微调的关键。

MCP/Agent

通过外部服务能力，利用 AI 作为大脑，自动化原本的费时场景。MCP/Agent 可以作为手，直接触及到用户使用的场景和行为，帮助你完成一些“力所能及的事”。

这其实是一个很不错的结合场景，因为大多数 AI 仅仅只是对话的话能提供的帮助太少，或者说自动化程度不高。用户都是懒的，被 AI 会越惯越懒，他们（我）甚至只想动动嘴皮子，就把事情做了。所以，如果 AI 仅仅告诉你怎么做，那么还不够，如果能把事情直接完成，那才是尽善尽美的服务。

整个过程可以被抽象为：

  • 规划：分解复杂目标为可执行的子任务。
  • 工具使用：根据需求调用外部工具或服务(MCP)。
  • 记忆：存储和利用历史信息。
  • 反思：评估执行结果，修正错误或调整计划。。

如果你用过各种 AI 的 IDE 你会发现他们的很多设计也是这几个要点。将你的请求先思考，拆分为一个个任务，然后通过本地的各种 tools 去编写修改代码，然后去验证一下写的对不对，不对再调整，如果整个上下文长了还会总结之前的工作交给下一个对话继续操作。

在这里，最重要的部分是协作。是 AI 与工具的协作。我的思考是：一定要清晰的告诉 AI 你的工具能什么，而对于 MCP 来说，提供的选择有时候越少越好。有时候如果你没有清楚的告诉 AI 你的工具的能力，很有可能会被误用，而 MCP 有的时候是因为你提供的工具或者选择太多，导致 AI 误用了很多没必要的工具去操作。

浅谈与思考

妄自菲薄

千万不要妄自菲薄，我经常听到的一句话是：“用户是不是不需要我们这个产品，因为用户自己把东西交给 AI 提问也能得到结果” 错，哪怕你仅仅只是优化了 Prompt 加上了交互，也会有用户付费。路径缩短 或者说节约用户行为时间，这样的体验就会产生依赖。

数据为王

RAG 依赖高质量的知识库，微调需要大量标注精良的数据。然而，现实世界中，企业的文档散乱陈旧，用户数据涉及隐私难以获取，标注成本高昂且质量参差不齐。数据工程的质量和规模，往往直接决定了 AI 应用的成败上限，而这恰恰是很多项目（尤其是个人或小团队项目）最难逾越的鸿沟。 没有好数据，再好的模型也是“巧妇难为无米之炊”。

我的思考是这样一个例子，我自认为人类的大脑比 AI 强大（在私有领域），换作是我，收到 RAG 最终给我的 Prompt 我都无法解决这个问题，那我凭什么期待 AI 能解决呢？对于这个领域(私有)可能它知道并不比我多啊。

我都不知道公司打印机在哪里，AI 怎么会知道呢？

产品思维

掌握一项 AI 技术（如 RAG、微调）让我们具备了“能做”的能力，这很重要，是基础。但决定一个 AI 应用能否成功、能否真正产生价值的，是我们能否精准地找到那个“值得做”的问题，并用产品思维、工程能力和对用户的理解，将技术转化为切实的解决方案。 这个过程，远比调通一个 API、跑通一个微调脚本要复杂和艰难得多。它要求我们从技术的狂热中冷静下来，更深入地走进用户的真实世界，更务实地看待技术的边界与成本，更精心地设计产品与体验。

技术是锤子，但用户需要解决的问题才是那颗钉子。顺序反了，再好的锤子也敲不准。

MVP

最后是 最小可行产品 (MVP) + 快速迭代：，不要追求一上来就做一个完美的、功能繁多的应用。聚焦一个最核心用最快的速度（可能利用现成的 API、简单 RAG 或零样本/少样本提示工程）做出一个粗糙但能用的 MVP。尽快让真实用户用起来，收集反馈，验证价值假设。 基于反馈决定是放弃、转向还是深入优化（这时才可能需要微调、复杂 RAG 等）。

总结

技术会发展，新的与 AI 结合的技术还会不断出现，而结合 AI 开发应用，这场盛宴才刚刚开始，而找到那把开启真正价值之门的钥匙，需要我们所有人持续地思考、实践和反思。