第11章 AI 技术落地与工具链（LLM / RAG / Agent / MCP）

对应简历：技能第14条「持续跟踪大语言模型、多模态、AIGC、AI Agent、RAG、MCP 等企业级 AI 技术与工具，具备选型评估、成本分析与落地方案设计经验」+ 第15条「能基于阿里云百炼 API 与 Cherry Studio、Coze 搭建 RAG 知识库与自动化工作流，掌握 LangChain、LangGraph、deepagents 应用开发，熟练运用 AI 编程与 AI 办公工具提效」/ 项目三全部 4 条职责「基于阿里云百炼（Model Studio）API 接入主流大模型，使用 Cherry Studio 搭建并维护企业知识库与 RAG 问答应用……」「使用 Coze 搭建自动化工作流……」「掌握 LangChain、LangGraph、deepagents 等 AI 应用开发框架……」「累计输出多份选型评估报告与成本分析……将 API 使用成本控制在每月 5000 元以内」

本章是简历的差异化章节：前 13 条技能是"运维同质项"，AI 这两条是别人没有的记忆点。分两类口径：①工具链落地（百炼/Cherry Studio/Coze/成本管理）是真实项目经历，放开讲；②技术概念与开发框架（RAG 原理、Agent、MCP、LangChain 系）按概念准确 + 自学原型级讲，不吹生产级框架开发。

11.1 LLM 基础概念：token / 上下文窗口 / temperature 【必背】

标准回答： 先说结论：大语言模型就是用海量文本训练出来的、靠"预测下一个词"生成内容的模型，用好它有三个绕不开的概念——token、上下文窗口和 temperature。第一个 token，是模型处理文本的最小单位，英文里大约一个单词折一点几个 token，中文一个汉字大概折零点六到一点五个 token，具体由分词器决定。为什么运维的人要特别关心它：因为 API 是按 token 计费的，输入和输出都算钱，token 就是这套体系里的"度量衡"。第二个上下文窗口，是模型一次能"看见"的最大 token 数，可以理解成模型的工作记忆——一次对话里提示词、检索回来的资料、历史轮次、当前回答全都要塞进这个窗口，超了就把最前面的内容挤出去丢掉。做长文档问答时第一件事就是算文档量塞不塞得进窗口。第三个 temperature 温度，是生成随机性的旋钮：调到零附近输出稳定、确定性强，适合知识问答和代码；调高输出越发散有创意，适合写文案。我做企业方案问答应用基本都锁低温度，因为要的是准，不是浪。这三个概念不是我背名词——做 API 成本管理的时候我天天拿 token 概念核算账单，统计每次问答的输入输出量乘以单价，倒推哪些场景该用贵模型、哪些该降级到便宜模型，月成本控制在五千元以内靠的就是这本账。

追问链：

• 追问1：为什么长对话聊着聊着模型就"忘了"前面说的话？ → 答：不是模型健忘，是对话的总长度逼近了上下文窗口上限，最早的那部分内容被截断挤出窗外，模型物理上已经看不见它们了。工程上的标准处理是做对话历史压缩：把旧的轮次总结成一段短摘要替代原文带在上下文里，这样既保留了关键信息又省了窗口空间。我在做知识库应用的时候就是靠这个办法支撑长咨询对话的。
• 追问2：参数量越大的模型就越好吗？ → 答：不能这么比。参数量决定能力上限，但同一代模型之间训练数据的质量、对齐的水平影响非常大，小一号但训得好的模型经常在具体任务上打赢大模型。我的选型原则是不看发布会看实测：拿我们自己的方案文档问题集去跑，比准确率和成本的实测结果，数据说了算。这也正是我做新模型测评的方法论起点。
• 追问3（深挖）：模型到底是怎么"生成"一段话的？ → 答：逐 token 的自回归生成：每一步根据前文计算下一个 token 的概率分布，按 temperature 控制的规则采样出一个，拼回输入里继续预测下一个，直到产出结束符。temperature 就是作用在这个采样环节上的。再往深一层是注意力机制，我理解到"每个字看全句、计算相互相关性做加权"这个层面，公式级的推导我可以会后补，不装懂。

关联话术：这三个概念在我这就是成本管理工具：月成本 5000 元以内的目标，是用 token 计量、按场景分级模型、控制上下文长度这三件事堆出来的，面试官问成本怎么控的，我从概念讲到账本，链路是完整的。

11.2 幻象（幻觉）与缓解手段 【必背】

标准回答： 幻觉是大模型最要命的问题：它会一本正经地编造——生成看起来逻辑通顺、格式专业、但实际是错的内容，编个不存在的版本号、虚构一个产品参数都有可能。根因要理解透：模型的本质是概率生成，不是数据库查询，它没有"事实核对"的机制，训练数据里没有的知识，它会顺着话风把最"像答案"的内容编出来。缓解手段我按四层说。第一层也是最有效的一层是给知识——上 RAG 检索增强，让模型开卷考试而不是闭卷瞎猜，企业场景里这一招解决一大半问题。第二层是提示词约束：在系统提示里明确写"仅根据提供的资料回答，资料里没有就回答不知道"，把"承认不知道"变成一个合法的、不受惩罚的答案，模型才敢说不知道。第三层是参数和模型选择：temperature 调低、优先选带引用溯源能力的模型。第四层是流程兜底：要出给客户看的方案内容，必须加人工审核环节，AI 出初稿、人签字。我的实测结论：纯模型裸答我们方案类问题，错误率完全不可用；接上知识库加上"不知道条款"之后，编造的情况明显收敛，才达到可用的水平。这个前后对比我在测评报告里有数据，不是感觉。

追问链：

• 追问1：上了 RAG 就能百分之百消灭幻觉吗？ → 答：不能，要说清楚残留的三种情况：一是检索环节没召回正确的片段，模型拿不到真知识；二是召回的几个片段互相矛盾，模型各取一半；三是片段都对但模型不听资料自说自话。所以 RAG 之后还要配引用溯源——答案附带出处片段让用户能核对，加提问拒答机制，再定期人工抽查，把幻觉率压到业务可接受的阈值以内，工程目标是可控，不是归零。
• 追问2：幻觉率怎么量化评估？ → 答：我用的是很实在的土办法：准备一组"标准问题加标准答案"的评测集，定期让知识库应用回答，人工比对后打三类分——答对、答错、编造，编造单独统计就是幻觉率的分子。新模型上线前跑一轮、知识库切分参数调整前后各跑一轮，数据摆在一起对比。这套方法就写在我的选型评估报告里，它把"感觉最近答得好一点了"变成了可比较的数字。

11.3 企业落地三条路线：提示词 / RAG / 微调 【必背】

标准回答： 企业把大模型用出业务价值，落地路线就三条，我按成本从低到高说。第一条提示词工程：不动模型不动数据，就靠把指令写清楚来解决，成本几乎为零，适合改写、总结、格式化这类通用任务，是我们全员的起点，也是投入产出比最高的一条。第二条 RAG 检索增强：外挂一个企业知识库，模型回答之前先去检索公司文档，把相关片段喂给它再生成，解决的是"模型不知道你们公司的事"这个根本问题，而且知识可以随时更新——新文档入库就行，不用碰模型。第三条微调 Fine-tuning：拿企业数据继续训练模型，改变它的能力或风格，成本高、周期长，知识一更新就要重新训，只在固定格式输出、行业术语理解这类特定需求下才值得。我的选型逻辑一句话：能用提示词解决的不上 RAG，能用 RAG 解决的不微调。落到我们的场景：需求是"公司方案文档问答"，方案文档不断在新增，知识更新频繁，RAG 的"改文档重新入库即可"正好命中，是性价比最高的解——这个决策不是拍脑袋，是按这个逻辑推出来的，面试时把推理过程讲出来比结论更有说服力。

追问链：

• 追问1：RAG 和微调到底怎么选，给我一个判断框架？ → 答：问自己三个问题。第一问知识更新频率：频繁更新选 RAG，因为改文档就能更新；知识稳定不变、量又大，才考虑微调把它焊进模型。第二问要不要引用溯源：RAG 天然能给出来处，微调的知识融在权重里，回答"为什么"它说不出来源，企业场景溯源几乎是刚需。第三问预算和数据量：微调要有标注好的数据和算力，RAG 把知识库搭起来就能用。三个问题答完，路线基本就定了。我们三问全指向 RAG。
• 追问2（深挖）：微调具体有哪些方法，你了解多深？ → 答：知道两个层面：全量微调是动模型全部参数，效果最彻底但成本最高；参数高效微调比如 LoRA，冻结原模型只训练少量的低秩适配参数，消费级算力就能跑，是现在的主流做法。但我要如实说：我们自己没有训过模型——对我们的需求来说成本和收益不匹配。所以微调在我这里是"理解原理加评估过路线"的口径，不是实操经历。

11.4 多模态与 AIGC 一句话 【了解】

标准回答： 这两个词经常一起出现，但维度不同。多模态是模型的能力维度：模型不止处理文字，还能同时理解和生成图像、音频、视频，比如给它一张架构图它能讲出里面有什么、给它语音它能对话，现在的旗舰模型基本都是多模态的。AIGC 是应用场景维度：AI 生成内容的统称，文本、图片、代码、音视频都算，AIGC 描述的是"AI 在替人产出内容"这件事本身。我在测评新模型的时候会专门测多模态能力，比如拿一张部署架构图问模型能不能看懂组件关系，办公场景的 AIGC 主要用在方案配图、PPT 初稿、文案润色这些提效点上。对运维来说多模态的想象空间很实际：监控大盘截图、报错截图直接丢给 AI 问异常点，这条路我已经试过，能力边界心里有数——能看出明显异常，但细粒度判断还不稳定，属于辅助而非替代。

追问链：

• 追问1：多模态在运维场景你觉得能落什么？ → 答：按可行度排两个：一是截图问答，把监控大盘或者报错信息截图直接问 AI 初步判断，减少打字描述成本；二是日志和拓扑图的理解辅助，比如给它一张调用链截图问瓶颈在哪。更进一步的"告警截图自动初判再触发预案"属于 AIOps 的演进方向，依赖告警数据的结构化和工具链打通。我测评时都亲手试过这些场景，能讲到具体效果而不是概念。

11.5 API 调用与按 token 计费 【必背】

标准回答： 先纠正一个常见误解：用大模型不等于要部署大模型，企业接 API 是绝对主流。云厂商把模型做成 OpenAPI 服务——我们用的是阿里云百炼 Model Studio——申请一个 API Key 就能调，按用量付费，模型升级也由厂商负责。计费逻辑必须搞清楚：输入 token 和输出 token 分开计价，一般输入便宜输出贵；不同档位的模型单价能差几倍到几十倍；如果做知识库，还要加上 embedding 模型的向量化费用，按文档量算，以及检索服务费。所以成本控制我总结了三板斧：第一模型分级，分类、提取这类简单任务用便宜的小模型，复杂推理才上旗舰模型，这一招省的钱最多；第二提示词瘦身，系统提示和知识片段控制长度，上下文不是免费的，塞进去的每一个 token 都是钱；第三用量监控，按应用分密钥，谁的调用量、哪个应用的账单一目了然，异常暴涨马上能发现。我管理的账目口径：每月 API 成本控制在五千元以内，就是这三板斧加上按月复盘账单做出来的，这是有据可查的数字，面试可以放开讲。

追问链：

• 追问1：API Key 的安全管理你怎么做的？ → 答：我立了三条规矩：第一，密钥不发到个人手里，统一由我在平台侧配置，应用里引用配置，绝不硬编码明文，这和运维管数据库密码是同一套纪律；第二，按应用分密钥，一个应用一个 Key，账目和权限都隔离，谁泄露了一眼定位；第三，定期轮换，人员离职转岗即时回收。本质上我是把 API Key 当成一类"密钥资产"来管理，纳入和服务器账号同级的安全纪律。
• 追问2：调用 API 报错或超时，一般是什么原因，怎么处理？ → 答：按层次排查：最常见的限流，返回 429，是 QPS 超了配额，处理是客户端加指数退避重试；其次是网络层，出口策略没放行或者代理配置问题；然后是鉴权层，Key 失效或者账户欠费停服；最后是参数层，模型名写错、消息格式不对。我在做 Coze 工作流和脚本调用的时候，都给调用加了失败重试和降级到备用模型的分支，不能让一次抖动打断整个流程。

实操模板（一次最小 API 调用，理解原理用）：

curl https://百炼平台域名/compatible-mode/v1/chat/completions \
  -H "Authorization: Bearer $DASHSCOPE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen-plus",
    "temperature": 0.2,
    "messages": [
      {"role": "system", "content": "你是公司方案知识助手，仅根据资料回答，没有资料就回答不知道。"},
      {"role": "user", "content": "XX解决方案的部署架构是什么？"}
    ]
  }'
# messages 数组存对话历史；temperature 低值保稳定；响应里 usage 字段返回本次 token 用量

11.6 RAG 完整原理（本章节核心，必背到能画图） 【必背】

标准回答： RAG 全称检索增强生成，解决"模型不知道企业私有知识"的问题，本质就一句话：让大模型开卷考试。完整链路我按五步讲，面试时要能画出来。第一步切分 Chunking：把文档按语义或者固定长度切成片段，一般几百 token 一块，相邻块留一点重叠避免语义被切断——块太大检索不精准，块太小又丢失上下文，这是个平衡问题。第二步向量化 Embedding：用 embedding 模型把每个片段转换成高维向量，语义相近的文本向量在空间里的距离也近，这一步把"意思"变成了可计算的数学对象。第三步存储与检索：向量存进向量数据库，用户提问时问题也被向量化，按相似度——通常用余弦距离——召回最相关的 top-K 个片段。第四步重排 Rerank：向量检索是粗排，快但可能召回"字面像、实际不对"的片段，重排模型把问题和候选片段放一起做精细的相关性打分，从大池子里精选出真正有用的少数片段。第五步生成：把问题、召回的片段、加上指令——仅根据资料回答——拼成提示词交给大模型，生成带出处的回答。为什么这套东西适合企业知识：知识可以随时增删更新，改了文档重新入库就行不用训模型；回答能引用溯源；能按权限控制召回范围；落地成本比微调低一个量级——这四点是它在我们场景完胜微调的原因。这套我不是背的：公司全部《解决方案》和技术文档的知识库是我建我维护的，新方案发布我走的就是"更新文档、重新切分入库、跑评测集验证"这套流程，检索质量问题基本都是切分和召回参数的事，我有第一手踩坑体感。

追问链：

• 追问1：为什么需要重排这一步，向量检索直接取 top-K 不行吗？ → 答：向量检索是"快而粗"的粗排，它只在语义空间里算距离，可能把字面相似但实际不相关的片段排到前面。重排模型的能力不一样，它把问题和每个候选片段拼在一起做交叉的精细相关性判断，准确率明显更高，代价是慢一些。所以工程上的标准做法是两段式：向量检索先从海量片段里粗召回一个较大的候选池，重排再从池子里精选最相关的几个进提示词——速度和精度两头都占。
• 追问2：切分的块大小怎么定？拍脑袋还是有方法？ → 答：经验起点是几百 token 一块、相邻块留百分之十到二十的重叠；结构化强的文档比如方案书，按标题层级切比按固定长度切效果好得多。但我真正的做法是拿评测集做对照实验：不同切分参数各跑一轮标准问答，比对准确率选最优——参数是测出来的，不是猜出来的。这就是我做知识库调优的实操方法，也是"选型评估"能力的一部分。
• 追问3：知识库问答答不上来或者答错了，你怎么排查？ → 答：我有一套三段定位法。先看检索段：期望命中的片段有没有被召回——翻召回日志，如果没召回，要么是切分把关键内容切碎了，要么是 embedding 模型对我们专业术语不敏感；再看生成段：片段明明召回了但答案没用上或者用错了，那是提示词约束不够或者模型没听话；最后看数据段：最朴素的可能，文档压根没进库或者用的是旧版本。三段定位完，对症下药——调切分、调 top-K、改提示词或者补文档。这是我日常维护知识库的主要工作内容，真实案例见 11.20。
• 追问4：现在模型上下文都号称百万 token 了，直接把全部文档塞进去不就行了，为什么还要 RAG？ → 答：三个硬理由。第一成本：每次问答都带全量文档，token 费用随文档量线性增长，公司全部方案文档量级下这个账根本没法看，RAG 每次只带最相关的几个片段。第二可靠性：超长上下文存在"中间遗忘"现象，长文档中段的内容召回率会下降，检索定位比整体塞入更稳。第三权限与溯源：RAG 可以按文档权限控制召回范围，答案能给出来源片段，整窗塞入两者都做不到。所以长上下文和 RAG 是互补关系，不是替代关系。

关联话术：我的知识库导入的是公司全部《解决方案》和技术文档，支撑新员工入职学方案和售前快速问答；维护过程中处理过表格类文档切分打散的真实问题（见 11.20 案例），所以讲到 RAG 我能从原理讲到参数再讲到踩坑，三层都有。

11.7 向量数据库与 Embedding 【理解】

标准回答： 这两个是 RAG 的底层积木。embedding 模型的职责是把一段文本压缩成一个固定维度的向量，比如 1024 维，而且语义相近的文本向量距离也近——"部署架构"和"怎么部署的"两句话字面差很多但向量很近，这就让"意思"变成了可计算的数学对象，语义检索才成为可能。向量数据库是专门存向量并做相似度检索的服务，核心技术是 ANN 近似最近邻算法，在海量向量里毫秒级找出最相近的 top-K。常见产品：Milvus 是国产开源、可以自建，适合大规模生产；Chroma 轻量，适合做原型；Qdrant 也是热门选择；云厂商基本都提供托管服务。还有一个降低门槛的事实：Cherry Studio 这类客户端工具内置了向量库能力，建知识库完全不用自己搭库，我们公司落地走的就是这条路。运维视角我补一句自己的理解：向量数据库本质上也是一个"存储加检索服务"，它的部署形态、索引类型、内存与容量的权衡，和 MySQL、Redis 这类存储的运维思路是相通的——这是我作为运维人学新组件的迁移方法：先找它和已掌握事物的同构性。

追问链：

• 追问1：相似度具体用什么衡量？ → 答：常用余弦相似度，看两个向量方向的夹角，对文本长度不敏感，适合语义比较；另一个是欧氏距离，看空间直线距离。embedding 模型输出的向量一般做过归一化，长度统一，这时余弦和欧氏的排序结果基本一致，用哪个都行。回答时能把"为什么文本用余弦"讲出来——两段话长短不同不代表不相关——就是理解到位的表现。
• 追问2（深挖）：HNSW 索引了解吗？ → 答：知道它是向量库里主流的近似最近邻索引，思想类似分层跳表：高层稀疏用于快速导航定位大致区域，逐层往下越来越密，底层做精确匹配。特点是查询快、但建索引和运行要吃不少内存——本质是拿内存换查询性能。再往深的内部调参我没有实际做过，生产上我用的是工具内置的向量库能力，这层细节可以会后补。

11.8 Prompt 工程基础 【理解】

标准回答： 提示词工程不是玄学，是"把需求说清楚让模型干好活"的方法论。我沉淀的模板有四要素：角色，告诉模型它是什么专家，比如"你是资深售前顾问"，角色设定会激活对应领域的话风和知识偏好；任务，做什么、输出什么格式，越具体越好；约束，划边界——仅根据资料回答、不知道就说不知道、字数和格式要求；示例，复杂任务给一两个输入输出的样例，这一条的效果往往最明显，一个好示例胜过十句抽象描述。两个进阶技巧：少样本示例 few-shot，给几个范例让模型照着做，比纯文字描述管用；思维链 CoT，要求模型"先分析再给结论"，把推理过程写出来，复杂推理任务的准确率会明显提升。这些不是纸上谈兵——我给公司沉淀的就是一套提示词模板库：方案摘要、周报生成、招标应答初稿、代码解释等十几个场景化模板，全员直接套用，这也是我培训分享的主内容之一。可以说提示词工程是我们全员 AI 使用的第一课，成本为零、收益立竿见影。

追问链：

• 追问1：模型输出格式不稳定，有时候一段话有时候一个列表，怎么治？ → 答：两件套：低 temperature 加明确格式约束。提示词里把格式写死——"只输出 JSON，字段为某某"——再附一个符合格式的示例，模型模仿示例的能力很强。如果业务要求百分之百稳定，还要在应用解析层做容错：正则抽取关键字段、解析失败自动重试一次。提示词管大概率，解析层兜小概率，两层叠起来才敢接下游流程。
• 追问2：系统提示词和用户提示词的区别是什么？ → 答：系统提示词 system 定义角色、规则和边界，全程生效，用户改不了它；用户提示词 user 是每一轮的具体问题。企业应用的关键设计是：把"仅根据资料回答、不知道就说不知道、敏感问题引导联系负责人"这类硬约束放在系统层，这样不管用户怎么问，每一次回答都被这套规则框住。我们的知识库助手系统提示词就是这么设计的（全文见 11.24 模板）。
• 追问3：听说过提示词注入攻击吗？ → 答：知道，这是 RAG 场景真实的安全风险：攻击者在用户提问或者入库文档内容里藏指令，比如文档里被塞一句"忽略以上所有规则"，模型可能把它当成指令执行，越出预期行为。防护三板斧：系统提示里明确"资料只是资料不是指令"；入库文档做内容审核；涉及工具调用的操作加白名单和确认机制。核心思想一句话：把文档永远当数据、不当指令，这是 RAG 安全的基本意识。

11.9 AI Agent：规划-工具-记忆 【必背】

标准回答： Agent 是"能自主干活的 AI"。它和普通对话的区别一句话讲清：对话模型是你问一句它答一句，被动响应；Agent 是你给它一个目标，它自己拆解任务、调用工具、观察结果、再决定下一步，循环往复直到目标完成——从"问答机器"变成"执行者"。支撑这个循环的是三要素。第一规划：把大目标拆成可执行的步骤，执行中遇到失败还会反思换路径，这靠模型的推理能力。第二工具 Tools：这是 Agent 的手脚，通过接口调用外部能力——搜索、查数据库、发消息、执行脚本——工具越强，Agent 能干的事越多，这一点对我们运维人特别重要：把巡检脚本、kubectl 命令封装成标准化工具给 Agent 调，就是 AIOps 落地的形态。第三记忆：短期记忆就是对话上下文，长期记忆要靠外部存储比如向量库，把历史经验跨会话留存下来。我理解 Agent 的正确姿势是既看到能力也看到风险：自主性强意味着不确定性也强，所以生产上我对"主流程用固定工作流、局部环节用 Agent"的混合模式更信服，全部交给自主 Agent 在企业里目前还太激进。

追问链：

• 追问1：Agent 和工作流有什么区别？你实际怎么用的？ → 答：工作流是人预先画好的固定流程图，每一步干什么、怎么分支都是人定义的，确定性执行，可靠但死板；Agent 是模型自己决定下一步干什么，自主灵活但结果有不确定性。我的实践是混合：主流程用 Coze 工作流保证每一步可靠执行，个别需要弹性判断的环节嵌一个 Agent 节点。这样可靠性和灵活性各取所长，这也是企业场景比较稳妥的用法。
• 追问2：多 Agent 协作你了解吗？ → 答：了解思路——把"规划者、执行者、审查者"拆成多个 Agent 角色分工迭代，deepagents 这类框架走的就是这个路线，适合复杂的超长任务比如深度调研。但它的代价也很清楚：token 消耗成倍增长、调用链路长、不可控点变多。我们公司的业务用单 Agent 加固定工作流就完全够了，不上多 Agent 是我刻意的复杂度控制——不是不会，是不需要，这个取舍本身是工程判断力。
• 追问3：你说 AIOps，具体能落什么场景？ → 答：按成熟度排四个：第一知识库答疑，已经落地——告警处置手册、运维 SOP 入库，AI 直接回答"这个告警怎么处理"；第二告警信息聚合与初判，把一夜几十条告警摘要成一句人话，附上排查建议，这个技术上现在就能做；第三工单和报告自动生成，比如巡检报告初稿、故障报告的时间线整理；第四真正的自愈闭环——Agent 调工具自动执行预案，这个需要权限体系和审计体系配套，是演进方向。我对这四层的判断都有实测依据，不是看文章背的。

11.10 Function Calling 【理解】

标准回答： Function Calling 是大模型调用外部函数的标准机制，是 Agent 能用工具的底层协议。工作流程是这样：开发者把可用函数的名称、用途描述、参数结构——用 JSON Schema 定义——告诉模型；用户提的问题到了模型那里，如果需要"动手"才能回答，模型不再瞎编答案，而是返回一个结构化的调用请求："我要调用某某函数，参数是什么"；应用层收到这个请求，真正去执行函数——查真实的数据库、调真实的 API——把结果回传给模型；模型基于真实结果组织回答。举个运维的例子：问"昨天的服务器告警有哪些"，模型返回调用 query_alerts(date=yesterday) 的请求，应用拿真实监控数据回来，模型据此总结。这里有个关键的安全设计要讲出来：模型只做决策不执行，执行永远在应用侧——这意味着应用层可以做权限控制、白名单、审计，安全边界握在人手里。Agent 的"调工具"本质上就是一轮轮 Function Calling 的循环。

追问链：

• 追问1：模型会不会瞎编参数或者调不该调的函数？ → 答：会，所以要有三层防护。第一层参数校验：应用侧按 JSON Schema 校验模型返回的参数，不合格直接拒绝执行并让模型重试；第二层工具白名单：只暴露必要的函数给模型，能只读绝不给写；第三层危险操作管控：变更类、删除类操作要么二次确认要么干脆不开放。这套思路和运维的变更管控、最小权限完全同构——AI 工具调用就是新时代的"运维操作入口"，管控逻辑一模一样。

11.11 MCP 是什么 【理解】

标准回答： MCP 全称 Model Context Protocol，模型上下文协议，是 Anthropic 在 2024 年推出的开放协议，解决的是"AI 应用和外部工具、数据源怎么连接"的标准化问题。它出现之前是什么局面：每个 AI 应用要接每个工具，都得单独写一套适配，M 家应用乘以 N 个工具就是 M 乘 N 种集成，重复造轮子。MCP 把它统一成客户端-服务器模式：工具方把自己的能力封装成 MCP Server——现在文件系统、数据库、Kubernetes、浏览器这些都有现成的 Server——任何支持 MCP 的客户端即插即用，Cherry Studio、主流 IDE 的 AI 插件都支持。我最喜欢的一个类比是：MCP 之于 AI 工具，就像 USB 之于电脑外设——统一接口、即插即用，生态因此爆炸。我的实际用法：在 Cherry Studio 里接 MCP Server，扩展模型查本地文件、联网搜索的能力，比一个一个写 Function Calling 适配省事太多。这也是我判断"AI 工具生态会快速繁荣"的依据之一——连接成本降到接近零，工具供给自然井喷，这个判断本身就是持续跟踪技术动态的产出。

追问链：

• 追问1：MCP 和 Function Calling 是什么关系？经常被混着说。 → 答：它们不在同一层。Function Calling 是模型层的调用机制，解决"模型怎么表达我要调工具"——模型输出调用意图和参数；MCP 是应用层的生态协议，解决"工具从哪来、长什么样"——工具的封装、描述和发现标准。两者的衔接是：MCP Server 对外提供的每一个工具，最终到模型那一层还是以 Function Calling 的形式被调用。一句话：MCP 统一了工具的供给，Function Calling 是消费它们的机制。

11.12 LangChain / LangGraph / deepagents 定位（自学口径） 【理解】

标准回答： 这三个我各用一句话定位。LangChain：目前最主流的大模型应用开发框架，把调模型、接知识库、加工具、链式编排这些常见动作封装成现成组件，拼积木一样快速搭原型，是入门必学。LangGraph：同一个团队出品，解决 LangChain 的局限——Chain 是线性流水线，遇到"根据结果决定下一步走哪、失败了回到哪一步重试"这种复杂逻辑就不够用了。LangGraph 把应用建成图或者状态机：节点是步骤（调模型、调工具），边是流转条件，天然支持循环、分支和中断恢复，适合做可靠的多步 Agent 工作流。deepagents：更上层的深度研究型 Agent 框架，内置规划、子任务分解、长任务执行循环，面向"给一个目标，自主完成调研并输出综合结果"的场景。诚实边界必须讲清楚：这三个我是自学加原型级实践——用 LangChain 跑通过知识库问答和简单工具调用的 demo，不是公司生产在用的东西；公司落地走的是百炼加 Cherry Studio 加 Coze 这条低代码路线。框架是我储备的"下一阶段做定制开发"的能力，现在拿出来讲是讲定位和理解，不吹开发深度。

追问链：

• 追问1：既然你都会框架，公司落地为什么不用 LangChain 自己开发？ → 答：这是选型评估的实际结论，逻辑三条：第一看用户——使用者是售前和非技术同事，要的是开箱即用，Cherry Studio 和 Coze 不写代码就能上线，自己开发的应用要培训、要装环境，推广成本高一个量级；第二看维护——低代码工具厂商负责升级，自研应用的所有迭代都压在自己团队身上；第三看时机——当时的需求用现成工具百分之百满足，自研没有增量收益。所以结论是先用低代码快速落地，框架能力留作定制化需求出现时的储备。先看用户和成本，再看技术，这是我做选型的方法论。

11.13 AI 编程与 AI 办公提效（技能第15条明写"熟练运用"，必被问） 【必背】

标准回答： 简历上写的"熟练运用 AI 编程与 AI 办公工具提效"，我拆成三个真实用法讲，每个都有实例。第一 AI 编程，主要用在运维脚本开发：写 Shell 或 Python 脚本，先让 AI 出初稿，我来改参数和边界条件——比如"批量检测各节点时间偏差并输出表格"这类一次性脚本，以前手写半小时，现在五分钟出稿再花几分钟审。读别人写的长脚本、看报错堆栈，也让 AI 先解释一遍，定位速度明显加快。但这里有条铁律：我保有判断权——AI 生成的命令逐行审过才可能上生产，删除类、变更类命令绝不盲跑，这是运维的安全底线，谁都不能替代。第二 AI 办公：方案初稿结构化、会议纪要整理、招标应答初稿、邮件润色，配合我沉淀的提示词模板库一键套用，团队都在用。第三是我真正想强调的方法论：AI 提效的前提是"你本来就会做这件事"——AI 把会做的人提速十倍，把不会做的人变成风险源，因为它看不出错来。所以我培训时反复讲"AI 输出必须可验证"。实测数字：日常重复性文字工作约省一半时间，编码类任务省百分之三十到五十，这个体感我在公司分享时讲过。

追问链：

• 追问1：AI 生成的脚本你直接在生产上跑吗？出过问题吗？ → 答：从不直接跑，我的流程是四步：AI 出稿、我逐行审、测试环境跑、再上生产。审查的重点我非常明确：删除和覆盖类的命令、重启和变更类的动作、循环的边界条件、异常输入的处理。实际出过的问题类型也很典型——"看着对但条件判断漏了边界"，比如文件名带空格没加引号、日志为空时数组越界，这些坑我现在审稿的时候专门盯。AI 写代码快，但生产环境不认快，认对。
• 追问2：哪些事情你绝对不交给 AI？ → 答：三类。涉密的：客户内网信息、密钥证书，提示词本身就是数据外发，这类内容一个字都不能进 AI 工具；要担责判断的：变更决策、对客户的承诺，AI 不能替我担责任，责任链条必须落在人身上；需要保持手感的：核心排障命令和思路我刻意自己写，手生了关键时刻掉链子。一句话，AI 是提效工具，不是责任转移对象。

11.14 我的真实工具链全流程（项目三主线，必背） 【必背】

标准回答（60–90 秒完整讲法）： 我在公司主导了 AI 工具从评估到落地的全过程，整条链路五步。第一步接入：基于阿里云百炼（Model Studio）的 API 接入主流大模型，按任务分级使用——简单任务便宜模型、复杂任务旗舰模型。第二步知识库：用 Cherry Studio 搭建企业知识库和 RAG 问答应用，把公司全部《解决方案》和技术文档导入，做切分入库和持续维护，支撑两个核心场景：新员工入职学方案、售前同事快速答疑。第三步工作流：用 Coze 搭自动化工作流，方案要点提取、资料整理、通知分发这类重复劳动全部流程化，一次编排反复使用。第四步治理：每逢重要新模型上线就组织测评，累计输出多份选型评估报告和成本分析向全员分享；统一管理平台账号、API 密钥和权限，把 API 使用成本控制在每月五千元以内。第五步推广：面向全员开展 AI 工具培训，沉淀出提示词模板库和实践案例库。成果可以用一句话收尾：RAG 知识库成了售前和研发团队的日常工具，新员工方案学习和售前答疑效率明显提升；更重要的是建立了"选型—使用—成本—合规"的闭环管理机制，这套机制比任何一个单点工具都值钱，因为它让公司在 AI 这件事上可持续地用下去。

追问链：

• 追问1：为什么选阿里云百炼，不是别家？ → 答：三个原因：一是模型多且切换方便，一个 API 体系能接多家模型，哪个合适用哪个，避免被单家绑定；二是和我们已有的云资源体系是一个账号体系，管理成本低；三是按量计费透明，配合成本管理好算账。评估的时候也对比测试过其他平台，百炼在中文场景的效果和综合成本上最合适，整个过程有评估记录可查——这个选型本身就是我"选型评估"能力的证明材料。
• 追问2：全员培训具体怎么做的？效果怎么看？ → 答：做法上我坚持分场景培训不讲概念课——按"售前怎么问知识库、开发怎么用 AI 编程、办公怎么用模板"分组，每次只讲一个场景、练一个模板，培训完模板归档进提示词库。效果不看发了多少材料，看两个数：使用数据（哪些部门调用量在涨）和用户反馈（有没有人真的拿它干活）。培训是运营，不是宣讲。
• 追问3：如果到新公司让你重新搭一遍，你会怎么做？ → 答：我有一套现成路径，顺序很讲究：先调研场景，摸清哪类重复问答和文书工作最多；再小范围试点，拿一个部门的文档先入库；用评测集验证效果，达标再扩大范围；同步把密钥、成本、权限的治理规则立起来——这套治理比功能难补得多，必须先立规矩后放量，不然等失控了再收代价很大；最后才做全员培训推广。按这个节奏，一周能出试点，一个月到全员可用。这套打法我在现公司完整走过一遍，是有肌肉记忆的。

11.15 新模型测评方法（评测集怎么建） 【理解】

标准回答： 我的测评方法核心原则是：用自己的业务题测，不看发布会。发布会上的跑分和我们的方案问答是两码事，模型好不好要拿到自己的场景里验。具体四步。第一步建评测集：从公司方案文档里整理二十到五十道标准问答，每道题有问题和标准答案要点，覆盖两类场景——高频场景比如部署要求、架构说明，和边界场景，也就是文档里根本没有的问题，专门考它会不会承认不知道。第二步同条件实测：同一批题、完全相同的提示词和温度参数，分别跑新旧模型，或者知识库调参前后的两版，控制变量。第三步人工评分：每个回答打三类标——答对、答错、编造，同时算单次问答成本，token 用量乘单价。第四步出结论写报告：综合准确率、幻觉率、成本三项做决策——换默认模型、只在核心场景升级、或者不换——报告全员分享。这套方法最大的价值是让"模型好不好"从感觉变成数据：有一次的测评结论是"新旗舰质量确实提升，但成本翻倍，只值得给核心问答场景升级，其他场景维持原模型"——没有数据就做不出这种精细的决策，要么全换浪费钱，要么不换浪费效果。

追问链：

• 追问1：评测集会不会过拟合，变成专为它出题？ → 答：这个风险我想过，用两个办法防：一是题目来源约束——从售前同事的真实提问记录里出题，不是出题人拍脑袋，真实分布的问题天然防过拟合；二是保留"文档里没有"的陷阱题专测幻觉，这类题模型没法刷。另外评测集本身也在迭代，每次模型或参数大调之后补充新题进池子，防止对老题目产生刷题效应。

11.16 私有化部署与开源模型一句话 【了解】

标准回答： 企业用大模型两条路，各有清晰的适用条件。一条是调 API，我们公司选的这条路：零 GPU 投入、按量付费、模型随厂商升级，运维负担最小。另一条是私有化部署开源模型：Qwen、DeepSeek 这类开放权重的模型下载到本地，用 vLLM 这类推理框架自己起服务。私有化的适用条件三个：数据绝对不能出内网，金融政务的硬合规要求；调用量大到 API 按量计费反而更贵，自建摊薄成本；或者需要深度定制模型行为。代价也要说全：GPU 采购或租用成本高、要有人做推理服务的运维——显存管理、并发、版本升级都是活，而且本地部署的开源模型能力通常落后线上旗舰版一到两档。我的判断口径一句话：先 API 起步验证价值，量大或者合规有硬要求再私有化——这段选型逻辑我写在评估报告里过，也是简历上"选型评估、成本分析"的实际底稿。

追问链：

• 追问1：如果公司要求私有化，你接得住吗？ → 答：能接住部署和运维层：选开源模型、用 vLLM 起推理服务、配 GPU 服务器的资源、把 API 网关接给业务用，这条路和运维一个自建中间件的套路是相通的。要如实说的边界是：模型本身的训练调优我做不到，那需要算法背景；但"把开源模型服务化地跑稳、管好、控住成本"是运维职能能覆盖的，我做过同类的事——把 Vastbase、RocketMQ 这些自建服务跑稳的经验可以平移。

11.17 高频追问合集（六连问标准答法）

① RAG 和微调怎么选？ → 答：拿三个问题判断：知识更新频率、是否需要引用溯源、预算和数据量。我们的情况是方案文档频繁更新、企业场景溯源是刚需、没有标注数据和算力预算，三个答案全指向 RAG，所以结论是 RAG 打底、暂不微调。这个决策框架是通用的，换一家公司我也按这三问重新推一遍，不是教条。 ② 幻觉怎么缓解？ → 答：打一套组合拳：RAG 开卷考试让模型有据可依；系统提示加"不知道条款"，让承认不知道成为合法答案；temperature 调低压缩随机性；回答带引用溯源让用户能核对；对外的关键输出再加人工审核这道闸。五层下来编造率压到业务可用，并且定期用评测集抽测监控有没有反弹——幻觉治理是持续运营，不是一次性配置。 ③ 知识库怎么防泄密？ → 答：我做的是四层防护。平台层：账号权限分级，密钥统一管理不落到个人手里；数据层：文档分级入库，含报价、客户信息的敏感文档不进全员知识库；应用层：知识库应用按部门授权，调用有审计记录；边界层：选可控的部署形态，公司数据不出内网或者可信云环境。这四层就是"选型—使用—成本—合规"闭环里"合规"那条腿，我在成本治理的同时把合规一起立起来了。 ④ API 成本怎么控制的？ → 答：三板斧加一个复盘：模型分级，便宜模型干简单活，旗舰模型只用于复杂任务，这一项贡献最大；提示词瘦身，控制系统提示和知识片段长度，token 都是钱；按应用分密钥做用量监控，设预算告警，异常暴涨当天就能发现；再加每月复盘账单持续调优。结果就是月成本控制在 5000 元以内，有账可查。 ⑤ 这和运维有什么关系？（必被问，三段答） → 答：我分三层讲。第一层现在就相关：知识库里入库的运维 SOP、告警处置手册、部署指南，本来就是我运维经验的数字化，AI 是运维知识管理的放大器——我的部署文档现在既给人看也给 AI 用。第二层场景直接落地：这个项目的原始场景就是 IT 支撑职能的提效——新员工学方案、售前答疑，和运维支持研发是同构的。第三层方向一致：AIOps 是运维的演进方向——告警摘要、故障初判、巡检报告生成，再到 Agent 调工具执行预案，这条路上的每一步我都同时具备"运维功底 + AI 工具链实操"，我招进来是干运维的，但我是带着 AI 弹药来的，这是我和普通 3 年运维的差异。 ⑥ 为什么用 Cherry Studio / Coze，不用别的或自研？ → 答：三条选型逻辑：用户是非研发同事，必须开箱即用零代码维护；这两个工具的成熟度够——Cherry Studio 的知识库和多模型接入、Coze 的工作流编排都满足我们的需求；自研不划算——开发和长期迭代成本跟当时的团队画像不匹配。评估时对比过同类工具，过程和结论都写进了选型报告。工具是拿来解决问题的，不是越自研越好，也不是越新越好。

11.18 AI 工具在运维场景的落地实验（口径：测评 + 原型级） 【理解】

标准回答： "AI 和运维怎么结合"这个题，我不只讲方向，讲我亲手做过的五个实验——都是我在测评新模型和搭工具链过程中真实试过的。实验一监控截图问答：把 Grafana 大盘截图发给多模态模型，问"哪个指标异常"——结论是能看出明显的尖峰和红线，但对业务上下文的理解不够，定位到"哪个指标异常"可以、判断"为什么异常"不行。实验二报错日志初判：把一段 Java 堆栈或 K8s 事件粘给模型问可能原因——这个效果出乎意料地好，模型能给出合理的排查方向清单，相当于一个不知疲倦的初级同事。实验三巡检报告初稿生成：把巡检的命令输出喂给模型，按固定模板生成报告文字——可用，但所有数字必须人工核对，模型偶尔会"顺手"改数字。实验四脚本生成：写批量检测脚本让 AI 出初稿我来审——已经是我日常习惯，效率提升三到五成。实验五告警摘要：多条告警让模型聚合成一段人话加处置建议——这个是 AIOps 最现实的一步，测试效果可用。五个实验给我的整体结论：AI 在运维里当前可靠的角色是"助手"——初判、草稿、汇总这些降低重复劳动的环节可以放心用；承担"决策"还不行，因为输出必须人核验。这个结论有实测支撑，面试讲出来比空谈"AIOps 趋势"有力得多。

追问链：

• 追问1：这些实验里哪个你觉得最先能在生产落地？ → 答：日志和告警的初判摘要。原因三点：输入输出都是文本，不需要复杂集成，通过 API 或者工作流就能接；价值直接——告警风暴时把几十条压缩成一段带优先级的摘要，响应效率提升明显；风险可控——AI 只给建议，处置动作仍然人来定，错了也不会直接伤生产。我设想的落地路径是：Alertmanager 的告警 webhook 接一段汇总逻辑调大模型，输出到值班群——技术上现在就能拼起来。

11.19 模型分级与选型速览（了解即可，别背版本号） 【了解】

标准回答： 模型选型我不背具体版本号——版本迭代太快，背了三个月就过时——我讲的是分级逻辑和使用地图。以我们用的百炼平台为例，模型大致分三档：入门/极速档，速度快、价格低，能力有限，适合分类、提取、格式转换这类结构化小任务；标准档，能力和成本均衡，是日常问答、摘要的主力；旗舰档，推理和复杂理解最强，价格数倍于标准档，只用于复杂推理和核心问答场景。这套分级跟服务器选型一个道理：不是全上最强的，是按任务匹配。多模态维度：需要看图、读文档版式的时候选带视觉能力的模型；长文档场景看上下文窗口大小。embedding 模型单独选：中文场景要选中文效果好的，知识库检索质量一半取决于它。我的选型方法论三步：先按任务定档位（这步就砍掉八成成本浪费）、同档位拿自己的评测集比一两家、上线后看实际使用数据再微调默认模型。面试被问"你平时用什么模型"，我答的是这套"怎么选"，比报一个型号专业——型号会过时，方法不会。

追问链：

• 追问1：新模型发布那么多，你怎么保持不落后？ → 答：两个机制：一是事件触发式测评——每逢重要新模型上线，我按 11.15 的四步法跑一轮自己的评测集，用数据决定要不要跟进，而不是看新闻激动；二是持续跟踪技术动态——RAG、Agent、MCP 这些关键方向的演进我保持阅读，但只在"能用评测验证"之后才引入生产。这个"信息宽松、引入严格"的节奏，和运维对新版本软件的态度完全一致：可以激进地了解，必须保守地采用。

11.20 本章案例

• 【真实项目】企业 AI 工具评估落地与智能知识库建设（项目三全部，STAR 完整版约 300 字）：背景是公司解决方案文档越积越多，新员工入职学方案要翻几十份文档，售前同事被同类问题反复打扰，重复劳动成本高。任务是我主导 AI 工具的评估、选型与内部落地。行动按五步走：先基于阿里云百炼 API 接入主流大模型并按任务分级；再用 Cherry Studio 搭建企业知识库与 RAG 问答应用，导入公司全部《解决方案》和技术文档，制定切分参数并建立"新方案发布→重新入库→评测集验证"的更新流程；用 Coze 搭建方案要点提取、通知分发类自动化工作流；治理侧每逢重要新模型上线组织测评、输出选型评估报告与成本分析全员分享，统一管理平台账号、API 密钥与权限，把月成本控制在 5000 元以内；最后面向全员分场景培训，沉淀提示词模板库与实践案例库。结果是知识库成为售前、研发的日常工具，新员工学习和售前答疑效率明显提升，公司建立了"选型—使用—成本—合规"的闭环管理机制，沉淀出评估报告、模板库、案例库等系列可复用资产。
• 【课程/自学】LangChain 原型实践：用 LangChain 完整跑通"文档加载 → 切分 → embedding → 向量库 → 检索问答"的最小链路，理解了 RAG 每一步的代码形态和参数含义。这段原型的价值在对照：正因为搭过代码版，我用 Cherry Studio 建生产知识库时，知道每个界面参数——切分大小、重叠比例、top-K——底层在调什么、出了问题该往哪找，而不是当黑盒用户。
• 【经典场景】新模型上线测评决策（STAR，约 200 字）：背景是某旗舰模型发布，团队都在问要不要全面切换。任务是我组织对比测评给出决策建议。行动：用公司方案问答的固定评测集，同条件跑新旧模型两轮，人工按"答对、答错、编造"三类评分，同时按 token 用量核算单次问答成本，综合三项指标输出评估报告。结果：新模型准确率确有提升，但单次成本接近翻倍，最终结论是"仅在核心问答场景切换新模型，日常任务维持原模型"——用数据和场景做决策，不追新。这份报告也成为我成本治理方法论的一个实证样本。
• 【真实项目】知识库"答不准"优化（STAR，约 250 字）：背景是知识库上线后，一类含大量规格表的方案问题总是答不完整、答得碎。任务是我定位并修复这个检索质量问题。行动：按三段定位法先看检索段——翻召回日志，发现目标内容其实被召回了，但表格被固定长度切分打散，相关单元格和表头不在同一个片段里，模型拿到的是断裂的半张表；对策是对这类文档改用按章节切分、缩小块并加大重叠，同时把 top-K 调大一档让模型能拿到完整表格上下文；改完用评测集复测对比。结果：该类问题的回答完整度明显上来，评测集整体准确率也有提升；更重要的是把"表格类文档单独切分策略"写进了建库规范，后续入库的同类文档默认走新策略，同类问题不再复发。

11.21 实操模板一：企业知识库建设步骤清单（可直接背）

1. 数据准备：收集文档（方案/技术文档/手册），做三类清理——
   过期版本剔除、敏感信息脱敏（报价、客户名、密钥）、格式统一（PDF/Word 转 Markdown 更好切）
2. 工具准备：Cherry Studio + 百炼 API Key（开通 embedding 模型与对话模型）
3. 建知识库：新建知识库 → 选 embedding 模型 → 配切分参数（块大小几百 token、重叠 10%~20%）
4. 导入文档：分批入库 → 检查切分预览（重点看表格/代码有没有被切碎）
5. 建应用：助手绑知识库 → 写系统提示词（"仅根据资料回答+不知道就答不知道+给出处"）→ temperature 调低
6. 验证调优：跑评测集（20~50 题）→ 答不上的按"检索段/生成段/数据段"定位 → 调切分或 top-K 或补文档 → 复测
7. 上线治理：按部门授权访问 → 建立文档更新流程（新方案发布→重新入库→复测）
   → 密钥与用量纳入统一管理

附：调参速查（被问"知识库效果不好调什么"时用）

| 症状 | 先调什么 | 方向 |
| --- | --- | --- |
| 该召回的没召回 | 切分大小/重叠、top-K | 块调小、K 调大，或按章节切 |
| 召回了但答不对 | 系统提示词约束、temperature | 收紧规则、调低温度 |
| 答案缺出处 | 提示词加"标注来源" | 引用要求写进规则 |
| 专业词检索差 | embedding 模型选型 | 换中文/领域更强的 embedding |
| 表格类答得碎 | 表格单独处理 | 按章节切或表格转 Markdown 结构化 |

11.22 实操模板二：一条 Coze 工作流设计示例（方案要点提取流程）

目标：输入一份新方案文档链接/文本，自动输出"方案要点摘要 + 适用客户画像 + 售前三句话卖点"，发到指定群。

节点编排：
开始（接收文档输入）
→ 节点1【文档读取】：拉取/解析文档正文
→ 节点2【大模型-摘要】：提示词=方案分析师角色，输出：背景/架构/亮点/报价模式 四段结构化摘要
→ 节点3【大模型-售前话术】：输入=节点2输出，提示词=资深售前角色，输出三句话卖点+适用客户画像
→ 节点4【格式化】：拼装成固定消息模板（标题/要点/卖点/日期）
→ 节点5【消息通知】：发送到指定群/邮件
异常分支：节点1/2 失败 → 重试 1 次 → 仍失败发失败提醒给管理员

设计要点（面试讲的时候点出来）：
① 主流程固定用工作流保证确定性，不在流程里放自由 Agent，可靠性优先；
② 两个大模型节点各司其职（摘要/话术分离，提示词短而专，比一个大提示词效果好且省 token）；
③ 每个节点有失败处理，输出有固定格式，方便下游和审计。

11.23 术语中英对照速查（面试口语切换用）

中文	英文	一句话
大语言模型	LLM	按概率预测下一个 token 的生成模型
分词/词元	token	计费与窗口的基本单位
上下文窗口	context window	一次能"看见"的最大 token 数
温度	temperature	生成随机性旋钮
幻觉	hallucination	一本正经地编造
微调	fine-tuning	用企业数据继续训练改变能力
检索增强生成	RAG	外挂知识库让模型开卷考试
向量化	embedding	文本变向量、语义可计算
向量数据库	vector database	存向量做相似度检索（Milvus/Chroma）
重排	rerank	对粗排候选精排提准
提示词工程	prompt engineering	把需求说清楚的方法论
思维链	CoT	让模型分步推理再给结论
智能体	Agent	规划-工具-记忆的自主执行体
函数调用	Function Calling	模型决策调用、应用执行
模型上下文协议	MCP	AI 应用接工具的统一接口标准
多模态	multimodal	文字+图像+音视频混合理解生成
内容生成	AIGC	AI 生成内容的统称

11.24 实操模板三：知识库助手系统提示词（可直接背）

角色：你是XX公司的方案知识助手，服务对象是新员工和售前同事。
规则：
1. 仅根据【参考资料】回答问题，资料中没有的信息直接回答"资料中暂无相关内容"，
   禁止自行推测或编造。
2. 回答末尾标注信息出处（引用来源文档名/章节）。
3. 回答结构：先一句话结论，再展开要点，涉及规格数字必须与资料原文一致。
4. 用户询问与公司方案无关的内容（闲聊、写代码等），礼貌引导回业务问题。
5. 涉及报价、客户名单等敏感信息时，提示"请联系对应负责人获取"。
风格：专业、简洁，中文回答；不确定时明确说不确定。

设计要点（面试讲的时候点出来）：第 1 条压幻觉、第 2 条可溯源、第 5 条兜住敏感数据——每一条规则都对应一个真实踩过的坑，提示词是"防护策略"的集合，不是客套话。

11.25 被要求现场演示怎么办（带电脑/共享屏幕时）

• 演示顺序（5 分钟版）：Cherry Studio 知识库问答（问一个真实方案问题，展示引用出处）→ 故意问一个库里没有的（展示"不知道条款"生效）→ Coze 工作流跑一条（展示自动流程）。
• 演示的核心目的不是炫功能，是展示治理：顺手点开密钥管理和用量统计页——"账号统一管理、按应用分密钥、月成本 5000 以内"用画面证明。
• 红线：演示前清除历史会话里的敏感内容；不演示客户相关文档内容；断网有备份（提前录屏）。

11.26 章末自测清单

1. token 是什么？中文大致换算？ → 模型处理文本的最小单位，1 汉字约 0.6~1.5 token，API 按输入+输出 token 计费。
2. 上下文窗口超了会怎样？ → 最早内容被截断出窗，表现为"忘了前面"；要做历史压缩。
3. temperature 高低的用法？ → 低=稳定确定（问答/代码），高=发散创意（文案）。
4. 幻觉根因一句话？ → 模型是概率生成不是查库，没见过的知识会编；缓解靠 RAG+约束+溯源+人审。
5. RAG 五步链路？ → 切分 → 向量化 → 检索召回 → 重排 → 生成。
6. 重排的作用？ → 对向量粗排结果精细打分排序，提升片段准确率，两段式兼顾速度与精度。
7. 向量检索按什么找？ → 语义相似度（余弦距离），embedding 把语义变可计算。
8. Agent 三要素？ → 规划、工具、记忆。
9. Function Calling 里模型干什么、不干什么？ → 模型只输出"调用哪个函数+参数"的决策，不执行；执行在应用侧。
10. MCP 一句话？ → 标准化 AI 应用与外部工具连接的开放协议，类比 USB 即插即用。
11. LangChain/LangGraph/deepagents 定位？ → 组件化应用开发框架 / 图状态机式多步工作流 / 深度研究型 Agent 框架。
12. RAG vs 微调决策三问？ → 知识更新频率、是否要引用溯源、预算与数据量。
13. 我的成本控制三板斧？ → 模型分级、提示词瘦身、分密钥用量监控。
14. 我的知识库防泄密四层？ → 平台权限、数据分级、应用授权审计、部署边界可控。
15. "这和运维什么关系"三段答？ → 运维知识数字化（SOP 入库）、售前研发支持场景已落地、AIOps 演进方向（告警摘要→初判→自愈）。
16. AI 生成的脚本敢直接上生产吗？ → 不敢；逐行审（盯删除/覆盖/边界条件）→ 测试环境 → 生产，判断权在人。
17. 测评四步？ → 建评测集（含陷阱题）→ 同条件实测 → 三类评分+算成本 → 数据决策出报告。
18. API 还是私有化怎么选？ → 先 API 起步验证价值；量大或数据合规硬要求才私有化（GPU 与推理运维成本高）。
19. 提示词注入是什么、怎么防？ → 文档/提问里藏指令诱导模型越轨；防护=资料不当指令+入库审核+工具白名单。
20. 演示知识库时最能加分的一步？ → 展示治理画面（密钥管理、用量统计）——功能谁都有，治理是稀缺的。
21. 五个运维 AI 实验里最先能落地的？ → 日志与告警的初判摘要（输入输出都是文本、价值直接、AI 只建议人决策、风险可控）。
22. 模型分三档怎么用？ → 极速档做分类提取、标准档做日常问答、旗舰档只用于复杂推理——按任务定档是成本控制第一步。
23. 新模型出来怎么跟进？ → 事件触发式测评：用自己的评测集跑数据决定是否采用——信息宽松、引入严格。

11.27 本章口径红线（面试前再读一遍）

1. 两类口径分清：工具链落地（百炼/Cherry Studio/Coze/成本/培训）是真实项目，放开讲细节和数字；框架开发（LangChain 系）是自学原型级，主动亮边界"跑通过 demo，生产用的是低代码路线"。
2. 数字口径：月成本 5000 元以内、全部《解决方案》入库、多份评估报告、评测集 20–50 题——全部有据可查。
3. 必被问的三题：RAG 原理（五步）、幻觉缓解（四层）、和运维什么关系（三段答）——这三题答好，本章的差异化价值就立住了。
4. 不吹：不把 AI 说成万能，主动讲"AI 输出必须可验证"和"不上多 Agent 是复杂度控制"，克制的判断比激进的观点可信。
5. 脱敏：不展示真实客户方案内容；演示和举例用公司自有文档的脱敏版本。