前言

---

通过前面课程的学习，你已经从认识大模型开始，一步步知道怎么把任务讲清楚，怎么给 AI 补资料，怎么让 Agent 读文件、用工具、沉淀 Skill，也知道复杂任务做完后还要核对结果、守住安全边界。

这门课的主线可以概括成一句话：从“让大模型回答问题”，走向“让大模型帮你完成任务”。最后这一课会把前面学过的能力串起来，再向你介绍一套分析思路，看一看为什么有的 AI 场景能落地，有的却做不下去。

1 回顾：从认识大模型到驾驭大模型

---

回头看这门课，你走过的是一条从“认识大模型”到“让 Agent 稳定、安全地完成工作”的路径：

课时	你学到了什么
课时1 认识大模型	看到大模型有什么特点、怎么工作，也知道阿里云有哪些大模型产品
课时2 典型应用场景	看清大模型应用的三个层次：生成助手、执行智能体、自主运转，并识别自己工作中可以交给 AI 的场景
课时3 优化输入	看到一句话提示词为什么容易得到通用回答，学会用角色、任务、背景、约束把任务讲清楚，并让 Agent 反问或先列计划
课时4 知识库与 RAG	知道 RAG 怎样让大模型先查资料再回答，并用评测、问题归因和优化让 RAG 应用持续改进
课时5 微调	了解微调适合解决什么问题，以及它和提示词、RAG 的适用边界
课时6 Agent 入门	区分聊天式大模型和桌面 Agent，用“先计划、再执行”的方式批量处理本地文件，也可以接到钉钉或微信继续指挥桌面任务
课时7 知识库与工具接入	让 Agent 读取资料文件夹、接入地图等 MCP 工具，观察它如何选择工具、调用工具和读取结果，并看出工具数量、权限和上下文对稳定性的影响
课时8 Skill	把重复工作的标准、步骤、输出格式和边界沉淀成 Skill，让 Agent 不再每次临场发挥
课时9 自检闭环	用核实记录和自检清单检查 AI 生成的日报、报告等输出，让 Agent 修订后再核对一遍，形成可复用闭环
课时10 安全合规	识别外部资料和工具结果中的注入风险，判断资料是否需要脱敏，并对 AI 输出、知识库权限和对外发布内容进行把关

这些内容串起来，回答的是一个核心问题：遇到一个具体的业务问题，我应该选择哪种技术方案来解决它？

1.1 选对工具比努力更重要

课程中你会发现，不同的问题需要不同的解法：

• 大模型回答质量不够好 → 先试优化提示词（课时4），成本最低、见效最快

• 大模型缺少特定领域知识、经常编造回答 → 用RAG接入知识库（课时6）

• 需要大模型输出特定格式或风格 → 用你的数据做微调（课时7）

• 任务复杂、步骤多、需要调用外部工具 → 用Agent编排（课时8）

• 大模型本身能力不够 → 加装插件扩展（课时5）

这不是一个固定的选择题，而是一个渐进的工具箱。关键是理解每种技术解决什么问题，才能在实际场景中做出正确判断。

1.2 从会提问，到会组织任务

刚开始使用大模型时，很多人关注的是“怎么问”。问得越清楚，模型越容易给出有用答案。因此，优化输入仍然是最先尝试、成本最低的方法。

但在真实工作中，你往往不只是要一段回答，而是要完成一件事。例如整理资料、准备汇报、处理一批文件、做一套团队可以复用的流程。这时，只会写提示词还不够，还要给 AI 准备资料、工具、边界和检查方法。

课程中的能力可以这样看：

问题	优先考虑的能力
回答太笼统、总是套话	优化输入：补充角色、任务、背景、约束和样例
模型不知道内部资料、专业知识或最新信息	知识库、搜索、RAG、多数据源
任务需要查询外部服务或执行外部动作	工具、MCP、业务系统接口
任务步骤多，需要读文件、调用工具或生成结果	Agent
同类任务会反复做，希望沉淀方法	项目规则、Skill
结果需要核对状态、依据和可发布范围	自检闭环、评测和人工确认
需要稳定特定格式、风格或领域行为	提示词、RAG、评测；更进阶时可考虑微调
涉及个人信息、企业数据、内容发布	安全合规和人工确认

这些能力不是互相替代的。实际工作中常常需要组合使用：Agent 可以调用知识库和工具，RAG 结果需要评测，Skill 可以把反复验证过的方法沉淀下来，安全合规则贯穿整个过程。

1.3 RAG、Agent、Skill：分别解决什么问题

RAG、Agent 和 Skill 都能改善大模型应用效果，但解决的问题不同。

能力	主要解决什么问题	适合场景
RAG / 知识库	模型缺少资料，需要先查再答	企业制度问答、产品手册问答、客服知识库、项目文档助手
Agent	任务需要多步骤执行、工具调用、结果检查和反馈迭代	文件整理、资料调研、页面制作、流程自动化、数字员工
Skill	同类任务会反复出现，需要稳定方法和验收标准	周报、对比决策、会议纪要、资料整理、团队流程

简单说：补知识看 RAG，做复杂任务看 Agent，沉淀方法看 Skill。

不过，真正做起来时，很少只用一种能力。一个企业知识助手可能同时需要 RAG、权限控制、评测集和人工反馈；一个销售支持 Agent 也可能同时需要产品知识库、业务系统工具、会议记录、自检流程和团队沉淀的 Skill。         

2 从会用 AI，到判断 AI 场景能不能落地

---

学完前面十课，你已经知道怎么把任务讲清楚，怎么接知识库，怎么让 Agent 调工具，怎么用 Skill 固化方法，也知道要给结果加自检、给能力划边界，什么时候考虑微调。接下来要问的是：在工作中，哪件事可以优先让 AI 做？

先看两个反差案例。

• 一家做出海产品的公司，有几百份产品文档要翻译成十几种语言。过去靠翻译团队一篇篇做，成本高、周期长，既懂本地语言又懂技术的译员也不好招。后来改用 AI 翻译方案，成本降了很多，质量评分还不降反升。

• 另一家公司想做“用一句话查数据”。员工不用写查询语句，直接问“上个月华东区销售额多少”，AI 帮他查。听起来很方便，做了大半年，最后没人用，因为 AI 给出的数字经常对不上。

同样是 AI，同样投入了资源，为什么业务结果截然不同？

翻译那家，文档本来就整理得清清楚楚，翻译质量也有长期使用的评分标准，评审人员一直都在。引入 AI 之后，只是把一件原本就跑顺的事做得更快、更便宜。

查数据那家，问题不在 AI，而在自己的数据基础没有理顺：同一个“销售额”，不同部门定义不一样；连人都写不出稳定的查询逻辑；也没人能告诉 AI，什么答案才算正确。这些问题不先解决，AI 只会把原来的混乱放大。

这就是挑场景的核心判断：AI 更适合放大已经理顺的流程，而不是替业务把混乱流程自动理顺。

当你需要挑选业务场景时，你可以先问自己三件事：

• 这件事的相关知识有没有写下来？ 如果知识只在少数老员工脑子里，AI 就没有可靠材料可参考，回答很容易变成现编。

• 你能说清“做得好”长什么样吗？ 如果只能说“质量要好”，却说不出合格样例、检查标准和常见错误，AI 输出好坏就没人能评。

• 有人愿意持续把关吗？ 如果业务规则、模板、数据口径变了，却没人维护知识和标准，做出来的 AI 应用很快会过时。

前两件问的是“这件事有没有理顺”，第三件问的是“有没有人愿意持续维护”。三个问题里只要有一个答不上来，先别急着上 AI，先把缺的那块补上。

3 用 RIDE 看懂：为什么有的 AI 场景能落地

---

讲到这里，你脑中可能已经有了一些候选场景，也准备试一试了。但如果想让 AI 真正帮业务提效，还要继续想几个问题：谁来判断它做得好不好？哪些资料要给它？结果错了谁来改？这些问题不解决，哪怕第一版看起来不错，也很难持续推进。

这时，你可以用一套更完整的判断框架来检查，叫 RIDE——重构生产关系 / 识别落地场景 / 定义度量标准 / 执行落地，RIDE 是这四个英文词（Reorganize / Identify / Define / Execute）的首字母。

这不是要你负责整个公司的 AI 转型，而是给你一张判断清单：当你想把一个 Agent 任务从“我自己试试”推进到“小组持续使用”时，先看这四件事有没有说清楚。

R — Reorganize（重构生产关系：先说清谁主导、谁验收、谁维护）

AI 能不能持续用下去，不只是技术问题，更是业务和技术的协作关系问题。

很多团队第一次做 AI 项目时，会很自然地把它交给技术团队：让产研的同事接模型、配工具、做页面。但 AI 项目不是“技术接了模型，业务难题就自动解决”。真正决定业务效果的，往往是业务侧的判断：客户进展怎么分级，哪些风险必须升级，什么样的周报才算能用。

这也是 Reorganize 要强调的核心变化：业务领域专家是核心，业务是需求方，业务团队与技术团队双方围绕真实业务痛点合作。业务方提出问题、定义目标、给出验收标准；技术方把模型、数据、工具和系统能力组合起来。很多项目做不出效果，不是因为“不够 AI”，而是因为一开始就没有对准业务痛点，只是在“为了 AI 而 AI”。

所以，Reorganize 先问三件事：

• 谁定目标：这件事到底是为了省整理时间、减少漏项，还是提高交付质量？

• 谁验收结果：AI 写出来的周报，谁能判断“能不能发出去”？

• 谁持续维护：客户分级规则变了、周报模板改了、业务口径更新了，谁负责告诉 Agent？

这一步不是让你写组织架构图，而是先把双方的责任说清楚。技术团队可以帮你做出系统，但“为什么要做、什么叫做好、做到什么程度才算有用”，必须由懂业务的人给出来。

I — Identify（识别落地场景：不是每件事都适合先交给 AI）

如何识别哪件事值得先做？你可以用如下三个要点来判断：

• 主要处理文字：问答、摘要、翻译、报告、客户记录整理，都是大模型比较擅长的类型。

• 重复出现：每周甚至每天都做，流程大体固定，AI 才有持续帮忙的空间。

• 业务压力明显：这件事不一定难，但由于频繁出现，会挤占大量时间，甚至人力不足时会出现积压。

当三个要点都满足时，你再查一个前提：基础准备好了吗？相关知识有没有写下来，判断标准有没有说清，原始材料能不能拿到。基础不清楚，AI 只会更快地放大混乱。

D — Define（定义度量标准：提前说清什么叫做好）

AI 任务最容易卡在一句话上：“看起来还行，但到底算不算好？”

传统软件也看交互、体验和流程顺不顺。AI 产品多了一件必须盯住的事：结果准不准。回答不准、数字不准、该做的任务没做完，界面再顺也没有用；如果是实时对话，还要看响应够不够快、是否满足安全合规要求。

所以 Define 不是只写一句“效果要好”，而是把指标拆成三层：

层级	核心例子	回答的问题
产品指标	回答准确率、任务解决率、响应时效、安全合规	AI 能力本身够不够用
运营指标	使用人数、提问数、覆盖率、留存率	用户是不是真的在持续使用
技术指标	检索召回率、检索准确率、首字时间 TTFT、生成耗时	哪个技术环节需要优化

三层里，产品指标最先决定“能不能用”。比如问答系统，回答准确率不够，用户根本不敢信；实时对话场景中，响应太慢，用户会明显感觉不顺。运营指标用来防止自我感觉良好：如果大家今天试了一次，下周就不再用了，说明它没有真正解决问题，哪怕内部评测看起来不错也不算成功。

对个人或小团队来说，不必一上来做复杂看板。先拿 5 条真实样例试一轮，提前写清楚每条样例什么结果算合格。Agent 做完后，先看关键事实和数字对不对，再看这份结果能不能直接进入你的工作流。如果结果不理想，再往下追：是资料没找到，规则没写清，还是响应太慢、生成过程出了问题。

课时3中的“把任务讲清楚”，本质上就是在练习 Define：你在定义目标、上下文、约束和验收方式。RAG 章节中的评测、归因和优化，Agent 自检闭环中的核实记录和检查清单，也是在帮助你建立“什么才算回答得好、做得对”的标准。

E — Execute（执行落地：先小步验证，再逐步加能力）

场景选好、标准定了，才进入执行。执行不是一上来做大系统，而是先从边界最清楚的版本开始。

翻译模式起步：这里的“翻译”不只是中英互译，而是把一种材料转换成另一种明确交付物。比如把客户跟进记录整理成周报，把会议纪要整理成待办，把一堆反馈整理成问题清单。输入和输出都清楚，也容易验收，适合作为第一步。

Agent 模式演进：翻译模式跑通之后，再让 Agent 处理更长的任务链。比如它不只是写周报，还会自己去找记录、发现缺失信息、标出需要你确认的地方、按验收标准自查。Agent 模式要盯住的是一件事：你到底想完成什么，它有没有把这件事办完。

开发 AI 系统时，业务领域专家最有价值的贡献不是“会不会写代码”，而是能不能提供这四类材料：

• 整理用户意图清单：你的用户会需要什么样的服务，会提出哪些方面的问题？你可以主动调研、收集反馈。

• 检查知识是否覆盖：每类任务需要哪些规则、模板、历史样例？这属于知识工程，你需要持续地查漏补缺。

• 收集真实提问并给出准答案：拿你调研或者你收集到的真实需求材料做基础，给出你认为合格的标准答案或评价指标，构建出标准评测集。

• 推动数据和工具接入：Agent 要读哪些文件、查哪些系统、调用哪些工具，你作为业务需求方要说清楚。

RIDE 方法论总结

RIDE 阶段	企业级动作	你在课程中学到的
R Reorganize	说清谁主导、谁验收、谁维护，让业务判断进入 AI 项目	认识大模型、知道 AI 能力与边界，和技术团队建立共同语言
I Identify	找到文字多、重复多、压力大的小场景，并检查基础是否清楚	识别典型应用场景，判断哪些任务适合 AI
D Define	定义产品指标、运营指标、技术指标，准备真实样例和验收标准	优化输入、建立 RAG 评测和问题归因思路，用自检清单明确验收标准
E Execute	先小步验证，再补知识、接工具、固化 Skill、加闭环、必要时微调、持续迭代	知识库/RAG、Agent、工具/MCP、Skill、自检闭环和安全合规

把 RIDE 放回自己的工作里，可以这样记：

        作为业务专家：

          作为协作推动者：

你不一定要成为算法工程师，但你可以把业务问题讲清楚，把知识和标准准备好，再把 AI 能力用到真实场景里。

• R：先找对负责判断的人，不要把业务判断都丢给技术。

• I：先挑文字多、重复多、压力大的小场景，不要一上来做大而散的项目。

• D：先写清“好结果”长什么样，不要只凭感觉说好不好。

• E：先用 10 分钟验证，再补知识、固化 Skill、加闭环。

  4 你如何帮助组织落地 AI 

  ---

  你不一定需要写代码，或者包办整个 AI 项目，你可以基于自己在组织中的角色定位来发挥作用：

  作为 AI 使用者：

• 你能判断一个任务该先优化输入，还是该补知识库、接工具、用 Agent 拆步骤。

• 你知道不是所有问题都要换模型：很多时候，补上下文、补资料、补标准，比换一个更强的模型更重要。

• 你可以把重复工作逐步沉淀成提示词模板、资料文件夹、Skill 和自检闭环，让 Agent 越用越稳定。

• 你能说清哪些业务场景真的值得先做，哪些只是“为了 AI 而 AI”。

• 你能提供 AI 做事所需的业务知识：用户意图、规则口径、历史样例、合格答案和常见错误。

• 你能判断结果是否可用，知道什么内容可以直接发布，什么内容必须人工确认。

• 你能和技术团队说清业务目标、数据来源、工具需求、验收标准和安全边界。

• 你能参与小范围验证，而不是等一个完整系统一次性上线。

• 你能把一次成功经验整理成可复用的方法，让团队里更多人用同一套标准使用 AI。