AI 应用开发到底是在做什么？

很多人搜索“AI 应用开发”，其实并不是想研究“大模型到底怎么训练出来的”，而是遇到了一个更现实的问题：我手上有一个业务场景，怎么把大模型接到产品里，并且让它真的稳定可用？

说得直白一点，AI 应用开发通常不是从零开始训练一个大模型，而是基于现成模型的能力，搭出一套可以交付、可以上线的软件系统。这里面会涉及模型调用、Prompt 设计、知识库检索、工具调用、权限控制、日志监控、部署发布等一系列工作。

它和下面几个概念容易混在一起，最好先分清楚：

概念	主要做什么	更适合谁	成本特点
AI 应用开发	把模型能力包装成产品功能或业务流程	应用开发者、产品团队	成本相对可控，通常优先调用 API
AI 模型训练	训练或微调模型本身	算法工程师、研究团队	数据、算力和评估成本都比较高
RAG 开发	让模型基于私有知识库来回答问题	企业知识库、客服、文档问答场景	比微调轻量，更新也更方便
AI Agent 开发	让模型能规划任务、调用工具并执行流程	自动化、多步骤任务编排	工程复杂度明显更高

对大多数中文开发者来说，第一步没必要上来就训练模型，也不一定要直接做 Agent。更稳妥的做法，是先做出一个能稳定回答问题、能接入业务数据、能评估、能上线的 AI 应用。

先说结论：新手应该怎么开始？

如果你刚开始看 AI 开发教程，可以按场景来选路线：

• 想做企业知识库问答：优先考虑 RAG。代码框架可以看 LlamaIndex、LangChain；低代码平台可以试试 Dify、FastGPT、RAGFlow。
• 想做智能客服或 FAQ 助手：先用 Prompt + RAG 就够了，不要一开始就想着微调。
• 想做自动化流程：如果任务需要查系统、发邮件、调接口，再考虑函数调用或 Agent。
• 想做内部办公助手：别只盯着模型效果，权限、日志和数据安全反而更关键。
• 想快速验证产品想法：低代码平台会更快；如果后面要长期产品化，再补代码级框架能力。

这里有个很实用的判断方法：

能靠 Prompt 解决的，就先别上 RAG；只有必须接入私有知识时，再用 RAG；需要让模型执行动作时，再接工具调用；任务需要多步骤规划时，再考虑 Agent；只有现有模型明显不适合业务要求时，才去评估微调。

AI 应用开发框架怎么选？

现在 AI 应用开发框架很多，但其实没必要每个都学一遍。选框架最重要的不是“哪个最火”，而是它适不适合你的场景。

框架/平台	类型	优点	可能的不足	更适合的场景	新手友好度
LangChain	代码框架	生态丰富，适合链式编排、工具调用和 Agent 原型	API 变化较快，不同版本差异要留意	复杂 AI 应用、工具调用、Agent 原型	中
LlamaIndex	代码框架	知识库和 RAG 能力比较突出，数据连接器也多	更偏 RAG，通用编排灵活度不如 LangChain	文档问答、企业知识库	中高
Semantic Kernel	代码框架	适合 .NET 和微软生态，工程化思路比较清晰	中文资料相对少一些	企业系统、微软技术栈团队	中
AutoGen	Agent 框架	多 Agent 协作能力强	工程复杂度偏高，不适合简单问答	多角色协作、复杂任务实验	中低
CrewAI	Agent 框架	角色和任务抽象比较直观	真正生产落地还需要补不少工程能力	多 Agent 流程编排	中
Dify	低代码平台	上手快，适合工作流、RAG 和应用发布	深度定制能力取决于平台本身	快速搭建 AI 应用	高
Coze	低代码/智能体平台	很适合快速做 Bot 和工作流	对平台能力和生态依赖比较强	轻量智能体、运营型应用	高
Flowise	可视化编排	节点拖拽，适合理解 AI 应用链路	项目复杂后维护成本会上升	原型验证、教学演示	高
FastGPT	知识库平台	面向中文知识库场景，部署和使用都比较直接	复杂定制通常需要二次开发	企业 FAQ、知识库问答	高
RAGFlow	RAG 平台	比较关注文档解析和检索链路	需要结合实际部署能力来评估	文档知识库、检索增强生成	中高

如果要给一个更直接的建议，可以这样看：

• 个人开发者：先用 Dify / FastGPT 做出可见效果，再学 LlamaIndex 或 LangChain。
• 后端开发者：可以从 Python + FastAPI + LlamaIndex/LangChain 入手。
• 知识库产品方向：优先关注 LlamaIndex、RAGFlow、FastGPT。
• 业务系统集成方向：LangChain、Semantic Kernel 更值得看。
• 多 Agent 实验方向：再去研究 AutoGen、CrewAI，但不建议把它们作为新手第一站。

AI 应用开发的完整流程

一个真正能落地的 AI 应用，通常至少要走完下面这些步骤。

1. 先把场景边界说清楚

不要一开始就写“我要做一个万能 AI 助手”。这种需求太大，也很难测试。更好的描述方式是先问清楚几个问题：

• 给谁用：客服、销售、员工，还是外部用户？
• 解决什么问题：查文档、写报告、查订单，还是生成摘要？
• 用户输入是什么：自然语言、文件、表单，还是系统事件？
• 系统输出是什么：一段答案、结构化 JSON、工单，还是某个操作结果？
• 明确不能做什么：不能编造政策、不能泄露内部数据、不能越权查询。

边界越清楚，后面的 Prompt、RAG、测试和上线都会轻松很多。很多项目失败，并不是模型不够强，而是最开始的需求就没有收住。

2. 选择模型和接入方式

模型一般可以通过官方 API、云厂商服务，或者第三方兼容接入平台来调用。中文项目尤其要关注中文理解能力、上下文长度、响应速度、调用成本、合规要求和服务稳定性。

如果涉及 Claude API 的兼容接入，比如使用 ClaudeAPI 这类第三方 Claude API 兼容接入服务平台，需要提前说明一点：它并不是 Anthropic 官方服务。这类平台通常更适合有兼容接入、多线路选择、中文支持、企业充值、开票或基础技术协助需求的团队。至于具体能力、价格和规则，还是要以平台官网的最新说明为准。

3. 准备数据

RAG 项目里最常见的数据来源包括 PDF、Word、Markdown、网页、FAQ、数据库记录等。不过，数据准备绝不只是“把文件上传一下”这么简单，通常还要处理这些事情：

• 去掉重复文档
• 清理已经过期的内容
• 保留标题层级
• 解析表格
• 加上权限标签
• 对敏感信息做脱敏

知识库质量如果很差，模型再强也容易“看错材料”。这一点在企业项目里尤其明显：不是模型不会答，而是它拿到的资料本身就乱。

4. 设计 Prompt

Prompt 不建议只写一句“请回答用户问题”。这种写法在 Demo 里可能还行，一旦进真实场景就容易不稳定。

更靠谱的 Prompt 通常会包含这些信息：

• 角色：比如“你是企业 FAQ 助手”
• 任务：只基于给定资料回答问题
• 约束：不知道就说不知道，不要编造
• 输出格式：分点、表格，或者 JSON
• 引用要求：尽量标注来源文档

Prompt 的目标不是把模型“管死”，而是让它在业务边界内稳定发挥。

5. 接入 RAG

RAG 的基本链路可以理解为：

文档切分 → 向量化 → 写入向量库 → 用户问题向量化 → 检索相关片段 → 把片段交给模型生成答案。

这里最容易出问题的是文档切分。切得太粗，召回不准；切得太细，上下文又容易断掉。中文知识库最好结合标题、段落和语义块来切分，而不是简单按固定字符数硬切。

比如一份制度文档，按章节、条款和小标题切，通常比每 500 个字切一段效果更好。

6. 接入工具调用或 Agent

如果应用只是回答文档问题，并不需要 Agent。很多项目其实用 RAG 就已经够了。

只有当模型需要“做事”的时候，才需要考虑工具调用，比如：

• 查询订单状态
• 创建工单
• 调用 CRM
• 发送通知
• 生成报表

Agent 更适合多步骤任务，比如“分析销售数据，生成报告，并发送给负责人”。不过要注意，Agent 虽然听起来更高级，但也更难测试、更难控制。不要为了显得技术栈先进而过度设计。

7. 测试与评估

AI 应用不能只靠一句“看起来回答不错”就上线。至少要准备一批测试问题，包括：

• 标准问题
• 边界问题
• 无答案问题
• 诱导攻击问题
• 权限越界问题
• 多轮追问问题

评估时可以看回答正确率、引用命中率、幻觉率、拒答准确率、平均延迟、用户满意度等指标。

尤其是企业知识库场景，引用来源非常重要。用户不仅要看到答案，还要知道答案从哪里来。

8. 部署上线

部署时要考虑的不只是一个模型接口，还包括接口服务、前端页面、向量数据库、模型密钥管理、日志系统和监控告警。

有两个坑一定要避开：不要把 API Key 写在前端，也不要把用户原始敏感数据直接打到日志里。很多安全问题不是模型造成的，而是基础工程没做好。

9. 持续监控和优化

AI 应用上线之后，不是就结束了。相反，真正的优化才刚开始。你需要持续观察：

• 哪些问题经常答错
• 哪些文档经常被命中
• 哪些回答被用户点踩
• Token 消耗有没有异常
• 延迟是不是变高了
• 有没有出现 Prompt Injection

AI 应用本质上是一个需要长期调优的系统，不太可能一次开发就永远稳定。

实战：做一个最小可运行的企业 FAQ 助手

下面用“企业 FAQ 知识库助手”举个例子，看看一个最小 AI 开发教程可以怎么设计。技术栈可以这样选：

• 后端：Python + FastAPI
• RAG 框架：LlamaIndex 或 LangChain
• 向量库：Chroma、Milvus、pgvector 等
• 前端：任意 Web 框架，或者先用简单 HTML 页面
• 模型：根据预算、中文效果和部署要求，选择 API 或私有化模型

项目目录示例

ai-faq-demo/
├── app.py
├── requirements.txt
├── .env
├── data/
│   └── faq.md
├── storage/
├── services/
│   ├── rag.py
│   └── guard.py
└── logs/

接口设计

最小版本其实只需要两个接口：

接口	方法	作用
/api/chat	POST	接收用户问题并返回答案
/api/rebuild-index	POST	重建知识库索引，上线后建议加管理员鉴权

请求示例：

{
  "user_id": "u001",
  "question": "公司报销发票有什么要求？"
}

返回示例：

{
  "answer": "根据知识库，报销发票需确保抬头、税号、金额与实际业务一致。如资料中未覆盖特殊情况，建议咨询财务部门。",
  "sources": ["faq.md"],
  "trace_id": "req_20250101_xxx"
}

核心开发步骤

先把 FAQ 文档放到 data/ 目录里。服务启动时读取文档，并按合适的规则切分内容；然后用 embedding 模型生成向量，写入本地或远程向量数据库。

当用户提问时，系统先检索 Top K 个相关片段，再把这些片段和用户问题一起交给大模型。模型生成答案后，接口返回答案、来源文档和请求 ID。与此同时，还要记录日志，方便后面排查问题。

这个 Demo 不需要一开始就做得很复杂，但最好具备真实项目的基本骨架：能检索、能追踪、能替换模型，也方便后续扩展权限控制。

RAG、微调、函数调用、Agent 到底怎么选？

技术路线	适合目标	成本	是否适合新手	典型场景
Prompt	规范模型输出	低	推荐	摘要、改写、分类、简单问答
RAG	基于私有知识回答	中	推荐	企业知识库、客服、文档问答
函数调用	让模型调用外部系统	中	适中	查订单、查库存、创建工单
Agent	多步骤规划和执行	较高	谨慎	自动化流程、多工具协作
微调	调整模型风格或增强特定能力	较高	不建议一开始就做	特定领域表达、固定格式任务

大多数业务场景其实不需要微调。尤其是政策、制度、产品文档经常变化的场景，RAG 往往比微调更合适。原因很简单：更新知识库比重新训练模型灵活得多，也便宜得多。

上线前必须补齐的工程能力

能演示的 AI 应用，和能真正上线的 AI 应用，中间差得很远。上线前至少要检查这些能力：

• 鉴权：用户有没有登录？不同角色能不能访问不同知识库？
• 权限控制：检索时是否过滤了用户无权查看的文档？
• 审计日志：能不能记录谁在什么时间问了什么、命中了哪些资料？
• 敏感信息脱敏：手机号、身份证、合同金额等是否被谨慎处理？
• 限流与配额：有没有防止单个用户疯狂刷接口，导致成本失控？
• 缓存：高频问题能不能缓存答案或检索结果？
• 容错降级：模型不可用时，系统是友好提示，还是直接崩掉？
• Prompt Injection 防护：用户输入“忽略以上规则”时，系统会不会被绕过？
• 内容安全：违法、违规、敏感内容有没有过滤和拦截？
• 监控告警：延迟、错误率、Token 消耗、检索失败率有没有持续监控？

这些东西看起来不如换一个新框架“有技术感”，但对生产环境来说，它们往往更重要。

中文 AI 应用开发要注意的本地化问题

中文项目有一些很现实的特殊点，不能直接照搬英文资料里的做法。

中文文档切分要尽量保留语义

不能只按英文句号，或者固定长度来切分。更好的方式是结合标题、段落、条款和业务结构，让每个片段尽量完整表达一个意思。

Embedding 模型一定要测中文召回

不同 embedding 模型在中文、表格、长文档上的表现差异很明显。不要只看排行榜，最好拿真实问题去测，看看能不能召回正确材料。

国内部署要考虑合规要求

如果涉及用户数据、企业内部资料、个人信息，就必须关注数据存储、传输和访问权限。尤其是企业项目，合规不是上线后再补的事情。

企业知识库必须做权限过滤

普通员工不能检索到管理层文档，客户也不能看到内部工单。RAG 如果不做权限控制，很容易把“知识库问答”变成“数据泄露入口”。

模型供应要方便替换

建议封装模型调用层，不要让业务代码和某一个模型强绑定。这样后面无论是切换 API，还是换成本地模型，都会轻松很多。

常见问题 FAQ

AI 应用开发需要学哪些技术？

至少要掌握一种后端语言、HTTP API、数据库、Prompt 基础、RAG 原理、向量数据库、部署和日志监控。如果要做生产级应用，还要补权限、安全、限流和评估这些能力。

新手应该先学 RAG 还是 Agent？

更建议先学 RAG。RAG 是知识库问答、智能客服、企业助手这类应用的基础能力，落地场景更广。Agent 可以等你有了工具调用和流程编排需求之后再学。

一定要微调模型吗？

不一定。大多数企业知识库、客服问答、文档助手，优先用 RAG 就够了。只有当 Prompt 和 RAG 都无法满足特定表达风格、领域格式或稳定输出要求时，再考虑微调。

免费框架和商业平台怎么选？

如果只是快速验证想法，可以先用低代码或商业平台，节省开发时间。如果要长期产品化、强定制或私有部署，代码框架加自建服务会更稳。选择时不要只看功能列表，还要看数据可控性、扩展能力和后期维护成本。

国内项目推荐哪些 AI 应用开发框架？

如果是知识库问答，可以优先评估 LlamaIndex、FastGPT、RAGFlow、Dify；如果是复杂编排和工具调用，可以看 LangChain；如果团队偏 .NET 或微软生态，可以评估 Semantic Kernel。最终还是要回到团队技术栈、部署要求和业务复杂度上来判断。

最后总结：不同团队应该怎么选？

如果你是个人开发者，可以先用 Dify、FastGPT 或 Flowise 做出一个能演示的版本，再慢慢补 LlamaIndex、LangChain 这些代码框架。

如果你是初创团队，建议先用低代码平台验证需求。等确认用户真的需要，再用代码框架重构核心链路，这样试错成本会低很多。

如果你是企业内部团队，不要只盯着模型效果。权限、审计、合规、日志和成本控制，最好从第一阶段就放进设计里。

如果你要做知识库问答产品，RAG 是主线。真正要花精力优化的，是文档解析、切分、召回、引用和评估。

如果你要做自动化 Agent 产品，建议先从函数调用开始，把每个工具的输入、输出、权限和失败处理设计清楚，再考虑多 Agent 协作。

真正有效的 AI 应用开发，不是把热门框架全都用一遍，而是围绕一个清晰场景，选择足够简单、可维护、可评估的技术路线。对大多数开发者来说，比较稳的入门路径是：先用 Prompt 入门，再用 RAG 落地，之后通过工具调用扩展能力，Agent 谨慎引入，而工程化能力要从头贯穿到尾。