企业官网建设流程全解析

一站式Agent学习平台：ai-studyhub.cn

1：RAG 和微调（SFT）的核心区别是什么？能不能一起用？

• 出现次数：31
• 重要性评分：91.1

答案

RAG 解决的是“知识从哪里来”，微调解决的是“模型应该怎么表现”。

RAG 不改模型参数，而是在运行时把相关资料检索出来，再交给模型生成答案，所以更适合处理时效性强、更新频繁、需要可溯源的知识。微调会改模型参数，更适合提升输出风格一致性、结构化能力、分类能力或领域行为稳定性。

它们当然可以一起用，而且很多企业项目就是这么落地的：用 RAG 提供知识，用微调或强约束输出提升行为稳定性。比如客服项目里，产品政策靠 RAG 保持最新，回复格式和字段输出靠微调或结构化输出保证稳定。

2：什么时候该用 Prompt、RAG、微调、Workflow、Agent？

• 出现次数：10
• 重要性评分：57.1

答案

最稳的判断方式，是先判断问题到底是缺知识、缺行为，还是缺流程能力。

• 如果模型本来就会，只是任务没描述清楚，先用 Prompt。
• 如果缺的是私有知识、最新知识、外部知识，优先上 RAG。
• 如果缺的是稳定行为，比如固定格式、固定语气、固定分类习惯，再考虑微调。
• 如果流程固定、节点明确、强调稳定和可审计，优先 Workflow。
• 如果路径不固定，需要边做边决定下一步、动态调用工具，再考虑 Agent。

这条选型主线可以压缩成一句话：

• Prompt解决任务表达问题。
• RAG解决知识来源问题。
• 微调解决行为稳定问题。
• Workflow解决固定流程问题。
• Agent解决动态决策问题。

真实项目里通常不会一开始就说“必须做 Agent”。大部分需求先用Prompt + RAG + Workflow就能覆盖，只有在任务开放度高、工具选择依赖中间结果、流程没法提前写死时，Agent 的价值才会真正体现出来。

3：Token 和上下文窗口是什么？它们在工程上意味着什么？

• 出现次数：11
• 重要性评分：58.6

答案

Token 可以看作模型处理文本的基本计量单位，不等于“字数”或“单词数”。模型在训练和推理时看到的不是原始文本，而是 tokenizer 切出来的一串 token。

上下文窗口则是模型单次推理时最多能看到多少 token 的上限。工程上常说的8K、32K、128K，本质上说的都是“这次请求里系统提示、历史对话、检索结果、用户问题加起来最多能塞多少 token”。

它的工程意义非常直接：

• 上下文窗口决定了你能不能做长文问答、多轮对话和大段 RAG 上下文拼接。
• token 越多，成本通常越高，延迟也更容易上升。
• 超出窗口的内容会被截断、压缩或根本进不了模型，所以不是“塞得越多越好”。

如果只做一个大致口径，128K token可以看作很长的一段内容。按常见经验口径，1 个中文字符大约是0.6个 token，1 个英文字符大约是0.3个 token，所以128K token粗略可以近似成二十万级别的中文字符量级。但这只是估算，真实数字会因为 tokenizer、语言类型、代码、标点和格式不同而波动。

4：大模型应用上线前你最关心哪些工程指标？

• 出现次数：12
• 重要性评分：60.6

答案

通常会从效果、性能、成本、稳定性、治理性五个维度看。

• 效果：准确率、忠实度、任务完成率、引用正确率。
• 性能：首 token 延迟、端到端延迟、P95/P99。
• 成本：token 消耗、检索成本、工具调用成本。
• 稳定性：超时率、错误率、重试率、降级命中率。
• 治理性：日志、Trace、Prompt 版本、索引版本、权限审计。

如果是 RAG / Agent 项目，我还会额外看检索召回质量、工具调用成功率、人工兜底比例和 badcase 回灌效率，因为这些才是真正影响线上体验的关键指标。

5：模型路由应该怎么做？

• 出现次数：13
• 重要性评分：62.1

答案

模型路由的核心不是“让所有请求自动找最强模型”，而是让不同复杂度、不同风险等级的请求走到最合适的链路。

比较常见的做法有三层：

• 意图路由：先判断这是 FAQ、RAG、工具调用、复杂 Agent，还是应该直接转人工。
• 复杂度路由：简单分类、格式化抽取、轻量总结走小模型；多步规划、开放生成、复杂决策走大模型。
• 成本路由：热点问题先查缓存，能规则化解决的就别进大模型，高价值用户或高风险任务再给更强模型预算。

真正落地时，通常不会把“路由”做成纯主观规则，而会配合评测和线上数据来调：

• 看不同路由分支的完成率、延迟、每任务成本。
• 看是不是某类问题被错误地下沉到了小模型。
• 看路由规则是否需要引入回退机制，比如小模型失败后升级到大模型。

所以模型路由本质上是效果、成本和稳定性之间的平衡器。做得好的系统，不是每次都用最贵的模型，而是能把“该省的地方省掉，该花的地方花对”。

6：System Message 和 User Message 应该怎么分工？

• 出现次数：14
• 重要性评分：63.7

答案

System Message 负责放稳定约束，User Message 负责放动态任务。

System 里一般放角色、目标、边界、安全规则、输出格式要求、工具使用规范，这些内容应该尽量稳定、少改。User Message 放用户当次任务、输入数据、补充上下文和个性化要求。

这样拆分的好处是结构更清晰，便于版本管理，也更适合后续做模板化、灰度和评测。如果把所有内容都混在一段 prompt 里，后面排查效果波动会非常困难。

7：结构化输出有哪些常见做法？各自的优缺点是什么？

• 出现次数：26
• 重要性评分：84.5

答案

从 Model I/O 这条主线看，结构化输出大致可以分成“后处理解析”和“前约束结构化输出”两类。

• 纯 Prompt 约束：直接要求模型按 JSON 返回。优点是最简单、起步快；缺点是模型多说一句话、少个逗号，程序就容易崩，稳定性最差。
• Output Parser：比如StrOutputParser、JsonOutputParser、PydanticOutputParser。它更接近“模型已经输出了，我再把结果转成程序可用的数据”，适合prompt | model | parser这条经典链路。
• Structured Output：比如with_structured_output(TypedDict / Pydantic / JSON Schema)。它更接近“在模型输出前就先把 schema 定好”，让模型按结构生成并自动解析，约束力更强。
• Function Calling / Tool Calling：本质上也是结构化输出的一种，只不过目标更偏“生成调用意图和参数”，特别适合工具调用、外部接口编排和 Agent。

如果模型平台支持更严格的结构化输出能力，通常会优先采用只保证“返回合法 JSON”的模式，因为前者更接近“按 schema 生成”，后者很多时候只是“长得像 JSON”。

如果再往下细分：

• TypedDict适合字段固定、但不追求很强运行时校验的场景。
• Pydantic适合字段类型、范围、必填项比较严格的业务场景。
• JSON Schema更适合跨语言、跨系统共享结构协议。

工程上通常不会把“让模型输出 JSON”当成真正的生产方案，更稳的顺序通常是：

1. 能用原生结构化输出就优先用。
2. 需要强校验时优先用 Pydantic 一类 schema。
3. 即使模型已经结构化输出，也要补业务校验、缺省值处理和失败重试。

归根结底，Prompt 只能“尽量要求它长成这样”，Parser 和 Structured Output 才是在帮你把模型输出真正接进程序系统。

8：Prompt Engineering 中，如何系统优化提示词并把准确率做上去？

• 出现次数：16
• 重要性评分：67.0

答案

通常不会把 Prompt 优化理解成“反复手改几句提示词”，而是把它当成一个小型工程闭环。真正想把准确率稳定做上去，核心不是玄学技巧，而是任务拆解、样例驱动、评测回归和边界收敛。

比较稳的做法通常是：

• 先定义任务边界：先说清楚什么叫答对，什么叫答错，哪些情况必须拒答或澄清。
• 做输入分层：把稳定规则放System，动态任务放User，别把所有约束揉成一段长 prompt。
• 先修大问题再修措辞：如果问题本质是缺知识、缺工具、缺流程，不要强行靠 Prompt 硬抬效果。
• 用样例和反例：few-shot 示例、反例约束、输出格式示例，通常比抽象要求更稳定。
• 做结构化约束：能用 schema、parser、structured output 的地方，不要只写“请返回 JSON”。
• 建 badcase 集：把线上错例沉淀成固定评测集，每次改 Prompt 都跑回归，而不是靠体感判断“好像更准了”。
• 做版本和灰度：Prompt、模型版本、温度、输出格式要求一起管理，避免改了一个点却查不清影响。

9：Prompt 工程的边界是什么？为什么不能把一切问题都交给 Prompt？

• 出现次数：17
• 重要性评分：69.1

答案

Prompt 更接近一种“任务表达和约束手段”，但它解决不了知识缺失、复杂状态管理和强执行需求。

比如资料太多时，仅靠 Prompt 塞上下文会出现成本高、噪声多、丢关键信息的问题，这时候应转向 RAG。多步骤复杂流程如果全靠 Prompt 硬编排，会变成不可维护的长指令，应该转 Workflow 或 LangGraph。需要稳定调用外部系统时，应该走 Tools / Function Calling，而不是让模型在文本里“假装调用了接口”。

所以工程上更合理的思路是：Prompt 负责表达规则，RAG 负责补知识，Tools 负责执行能力，Graph / Workflow 负责流程控制。

10：如何做 Prompt 版本管理与回归？

• 出现次数：18
• 重要性评分：70.6

答案

如果 Prompt 已经进入生产环境，就不能再把它当成一段“临时改改的字符串”，而要把它当成配置资产或代码资产来管理。

通常会同时管理四样东西：

• Prompt 模板本身：System、User 模板、few-shot 示例、输出格式要求。
• 运行参数：模型名、模型版本、temperature、top_p、max_tokens。
• 评测集：固定 golden questions、典型 badcase、失败样例。
• 发布信息：模板版本号、发布时间、负责人、灰度范围、回滚版本。

更稳的做法通常是：

1. Prompt 和代码一起版本化，或者放进配置中心统一管理。
2. 每次改 Prompt 都跑固定回归集，不只看主观感觉。
3. 记录模板 hash、模型版本和关键参数，避免“明明没改 Prompt，效果却变了”时查不清原因。
4. 上线前做灰度和抽样人工复核，高风险链路保留快速回滚能力。

还有一个很容易被忽略的点：换底层模型后，旧 Prompt 不一定还能保持原效果。所以很多时候回归的对象不是“这段 Prompt 对不对”，而是“Prompt 和当前模型组合起来还稳不稳”。

11：你常用哪些 AI 开发工具？各自适合什么场景？

• 出现次数：9
• 重要性评分：55.2

答案

比较稳的答法，不是罗列名字，而是按场景分层。

通常可以分成几类：

• 通用对话与研究类：例如ChatGPT、Claude、Perplexity，适合快速验证想法、梳理方案、写初稿、做资料总结。
• AI 编码协作类：例如Cursor、Claude Code、GitHub Copilot，适合读代码、改代码、补测试、解释代码库结构，重点看它是更偏 IDE 内协作，还是更偏终端里的代码库级 Agent。
• 低代码 / 工作流平台类：例如Coze、Dify，更适合业务快速验证、工作流编排、知识库接入和多人协作。
• RAG / 知识库平台类：例如RAGFlow，更适合文档导入、解析、切块、检索和引用链路验证。

如果放到真实项目里，通常不会只选一种工具，而是按阶段组合使用。比如前期用通用对话工具梳理方案，用低代码平台做 POC，用 AI 编码工具接手核心链路实现，后面再把评测、部署和可观测性补齐。

12：Cursor、Claude Code、Copilot 这类 AI 编码工具的差异该怎么理解？

• 出现次数：10
• 重要性评分：57.1

答案

可以将它们理解为“都在帮助开发，但协作位置和交互方式不同”。

• Cursor 这类工具更偏 IDE 内协作，适合一边看代码、一边补全、局部改写、基于当前文件或工作区做编辑。
• Claude Code 这类工具更偏终端里的代码库级 Agent，适合跨文件理解、执行命令、改一组文件、做更完整的任务闭环。
• Copilot 这类工具更偏轻量级代码补全和编辑辅助，优势通常在低打断、嵌入现有编辑器工作流。

因此，不宜简单判断谁更强，而应回到任务类型本身。如果是“边写边补全、快速改一段代码”，IDE 内工具体验更顺；如果是“要理解整个代码库、跑命令、跨文件修改、完成一个更完整任务”，终端型 Agent 更有优势；如果团队已经有稳定 IDE 习惯，轻量补全类工具的接入成本也更低。

还可以补一句：工具能力会持续变化，所以真正稳定的判断标准不是名字，而是它对代码库上下文的理解深度、执行边界、可控性，以及是否契合团队工作流。

13：总结“AI 应用工程师”和“算法研究岗”的差异？

• 出现次数：11
• 重要性评分：58.5

答案

可以概括为，AI 应用工程师更关注“把模型能力稳定、安全、低成本地交付到业务系统中”，而算法研究岗更关注“如何改进模型本身的能力边界”。

前者的核心工作通常是技术选型、RAG / Agent 架构、工具和数据接入、工作流编排、评测、部署、监控和业务闭环；后者则更偏模型训练、微调策略、数据构造、算法实验和指标突破。两者会有交集，但能力重点不一样。