从提示词到Agent：企业AI应用课程设计全攻略

我最早拿到“课程大纲——AI部分”这个题目时，第一反应不是马上去罗列模型列表，而是先问自己：这套课程要在什么样的人身上生效？当时的工作背景是给一家做内部训练营的企业技术团队搭课，学员里有后端开发、测试、产品经理，也混着少数做硬件和内容运营的人。如果把这门课做成“AI通识讲座”，讲完大家会觉得热闹但用不上；如果做成纯模型原理课，又会把大部分人直接劝退。

所以我最终把这门课定位成“AI应用工程交付课”——不追求让人从头训练大模型，但要求学员在课程结束时，能独立完成一个带真实业务场景的AI小系统：能调用模型、能管理上下文、能接外部工具、能评估效果、能控制成本。这个定位放在今天依然是合理的，因为大多数企业缺的不是“知道AI的人”，而是“能把AI接入业务流程并保证不出大错的人”。

这篇文章就把整套设计过程拆开讲，包含目标人群分析、模块设计逻辑、每个模块怎么转化为课堂任务、以及我在真实带班过程中踩过的坑。如果你们公司或你个人也在计划一个类似的“AI部分”课程大纲，可以直接拿这套思路去做减法或加法。

1. 定位这门 AI 部分课程：先确定培养什么能力

1.1 学员画像不一样，课程就不能用同一套标准

当时团队给我的学员名单大致可以分成三类。

第一类是研发工程师，包括后端Java、前端、大数据岗位。他们的真实诉求是：能不能用AI帮我写代码、做代码评审、生成单元测试？进一步，能不能把大模型接到公司内部系统里，做成内部知识库问答或自动化处理工具？这类人最适合往基建和应用开发方向带。

第二类是测试和运维工程师。测试最关心的是AI能不能自动生成测试用例、做页面异常检测、把线上日志变成可读报告；运维则关心大模型服务怎么部署、GPU怎么估算、本地模型和云端API怎么选。这类人需要更偏向模型工程和自动化工具链的内容。

第三类是产品经理、运营、内容制作等非技术岗位。他们不写复杂度太高的代码，但特别想做两件事：一是把日常重复工作交给AI，比如批量生成文案和脚本、做竞品分析摘要；二是学会给AI产品定指标，知道一个智能客服或一个AI内容工具到底算不算成功。

这三类人放在同一门课里，如果只给一条平均路径，有人会觉得浅，有人会觉得深。我的解决办法是：在总课纲里安排统一的“核心必修模块”，集中解决基础认知、提示词、RAG、Agent安全边界这些共通问题；再用分组实战的形式，让不同岗位进入自己的专项项目。这样既能保持班级的整体进度，又能让每个岗位都拿到对口产出。

1.2 主线为什么不是“模型原理”，而是“任务式学习”

很多AI课程喜欢从深度学习、Transformer结构开始讲，这对技术管理者可能很过瘾，但对大多数学习者来说信息密度太大。我采用的任务式主线是：每堂课先设定一个“模拟生产任务”，然后围绕任务学工具和原理，在任务交付过程中把知识带出来。

类比一下：一个人学开车时，不需要先把内燃机和变速箱的每个零件都研究透。他需要先掌握方向盘、油门、刹车和路感，知道车在什么条件下容易失控，再慢慢了解保养和故障排查。大模型教学也一样——先让学员建立“模型输入输出”的直觉，知道它善于生成但不一定善于精确计算，知道它会一本正经说错话；然后才进入上下文管理、工具调用、部署评估等进阶内容。底层数学不展开不是因为它不重要，而是因为课程属于应用工程而非算法研究。

当然，完全不讲原理也会出问题。所以我在第一模块单独加了一小节“模型为什么会出现幻觉”，用最通俗的例子解释“模型只是在预测下一个词的概率，它没有外接数据库，也不会联网核对，所以它输出的内容必须由调用方负责校验”。这个观念一旦建立，后面的RAG、提示词工程、输出格式校验就都有了落地理由。

2. 课程模块怎么排：六个模块串起一条完整链路

我把整个“AI部分”分成六个模块，顺序基本固定：基础使用 → 知识库与上下文 → Agent与工作流 → AI编程与研发效能 → 模型接入与部署 → 内容生成与产品化评估。这六个模块不是相互割裂的，它们对应的是一个AI应用从“想法”到“稳定运行”的完整生命周期。

为了让你快速建立整体概念，先放一张我在课程说明里用过的模块总览：

2.1 模块一：先解决“不会和模型说话”的问题

第一模块虽然叫基础，但内容设计要非常克制。常见误区是把所有提示词技巧都塞进来，什么思维链、角色扮演、少样本示例讲一大堆，结果学员记不住，真正用的时候还是靠感觉。我的课纲只保留了四个概念：上下文窗口、温度参数、输出格式约束、幻觉与校验。

上下文窗口要解释清楚：模型一次能“看到”的文本量有限，超过窗口的部分会被截断或者压缩，所以给模型塞资料时必须做取舍。温度参数是很多人忽略的重点，我建议直接给学员看对比实验：同一个分类任务，温度调到0附近时答案比较稳定；温度调到0.8以后就开始“自由发挥”。所以生产环境里的信息提取和格式化输出，温度一般设得很低，只有在写文案、做头脑风暴时才适合调高。

提示词讲义里，我会给一个可复用的模板，大致是：定义角色 → 说明背景 → 给出输入 → 指定输出格式 → 列出禁止行为。这个模板不花哨，但我多次验证过它能解决80%的通用场景问题。模块作业也不是让学员自由写提示词，而是给一批固定的原始材料，要求他们编写提示词能稳定提取指定字段，并用10条以上测试数据做验证。这从一开始就传递了一个关键观念：提示词是不是成功，取决于输出是不是每一条都符合要求，而不是某一个回答看起来“聪明”。

2.2 模块二：知识库不是拉一堆文档丢给模型

RAG（检索增强生成）是当前企业落地最常用的一招，培训里必须重点讲。但很多人误解了RAG，以为“把文档一股脑塞进向量库，再让模型去里面找答案”就万事大吉。实际教学中要反复强调：RAG本质上是一套“检索→拼接→生成→溯源”的流程管理，每个环节都能让结果偏离正确方向。

课内的实操链路我拆成了四步。第一步是数据处理：把PDF、Word、网页、表格统一转成干净文本，按结构切成块，切分范围建议在500到800个字符左右，同时保留相邻文本之间的重叠区域，避免把一个完整语义切断。第二步是向量化：选择适合中文的向量模型，把每一段文字转成向量存进向量数据库。第三步是召回：用户提问后，先把问题向量化，再检索最相关的若干段；如果预算和场景允许，可以在向量召回后加一个Rerank环节，把相关性排序再校准一次。第四步是生成：把召回片段拼进提示词，并要求模型只能基于片段回答，如果片段里没有答案，就明确说“根据已有资料无法回答”，同时在输出后附上引用来源的编号。

为什么必须在课程里强调“溯源”？因为大模型生成的答案看起来太流畅，流畅到容易让人放松警惕。如果不强制模型给出资料编号，学员根本无法判断答案是不是模型自己脑补的。我带的班级里，第一版RAG作业几乎全都遇到过“编造引用”的情况，后来大家统一在提示词里加了“如果引用资料中没有该信息，必须回答无法确认，不能补充外部知识”，问题才明显下降。

2.3 模块三：Agent不是“更聪明的聊天框”，而是“带边界的执行器”

第三模块是当前很多学员最兴奋的话题，因为“AI Agent”听起来很前沿。但我在课纲里会先泼一盆冷水：把Agent理解为“一个会自己决定并且调用工具的循环程序”，它固然可以做更多事，也同时带来了更大的失控风险。模块的首要目标是教会学员如何给Agent划定清晰的工作边界。

我会用一个很简单的流程来描述Agent运作过程：用户发出请求 → 模型判断需要调用什么工具 → 调用函数并拿到返回结果 → 模型根据返回内容决定是继续调用还是生成最终回复。这个循环本身并不神秘，真正难的是设计“什么时候该调工具”和“调完工具后怎么校验”。在实训项目里，我们通常会限制Agent只能访问一个很小的函数集合，例如查询天气、查库存、提交工单，且所有可能导致写操作的动作都必须经过人工点击确认。

如果学员基础可以，我还会提及工具调用协议和统一的函数注册机制。现在各种主流的Agent框架和开发套件可选择的很多，企业内部快速搭建常用智能体平台或轻量级工作流引擎都很方便。框架怎么选不重要，核心原则只有一个：不要让Agent拿着一张可以到处访问的“万能通行证”。课程上我会带学员做一个“最小可用Agent”——比如一个工单分类助手，它调用内部工单查询接口，判断紧急程度，并将处理结果先放人工审核列表，不允许直接触发退款、删除等高风险动作。这一步走通后，再往里面加其他编排能力才有意义，否则做出来的Agent只是“玩一玩”。

2.4 模块四：AI编程工具和研发效能怎么真正落地

这个模块对研发和测试岗是最实用的。课程内容不会花太多时间讲某个IDE插件怎么安装，因为工具迭代太快，界面经常变化。我更倾向于教一条稳定工作流：让AI先理解项目背景，再完成小粒度任务，最后经过严格校验合入代码。

例如在代码编辑器中，与其直接让AI“生成一个支付接口”，不如先把相关服务的接口文档和现有代码目录结构引入上下文，然后让AI按这个顺序工作：分析需求，列出需要修改的文件清单；生成接口伪代码；补上单元测试；自查潜在问题并说明。这个流程看起来慢，但实际比“一句话生成一大段代码”可靠得多。我也明确告诉学员：不要相信AI直接产生的代码是正确的，它写的代码和它生成的文字一样，存在“流畅但错误”的可能，代码审查是绝对不可省的一环。

测试岗位在这个模块有另外一套练习：让AI阅读一段业务代码或一个页面需求描述，自动生成覆盖正常流程、异常流程和边界条件的测试用例。课程里我加入了一个重点案例——由AI生成单元测试后，人还需要检查断言是否正确，不能只看到“测试通过”就觉得万事大吉，因为AI经常会生成“永远通过的无效断言”。这类练习同时呼应了所谓“AI自动化测试”的真实做法：不是全自动，而是人机协同。

2.5 模块五：模型接入和部署，绕不开钱和算力

到第五模块，学员已经对模型应用有了实感，此时再讲部署细节会事半功倍。课程目标不是让每个学员都成为运维专家，而是要让他们能看懂三个问题：方案用云端API还是私有化部署？如果私有化，需要多大算力？整个系统每月要花多少钱？

云端API适合快速验证，成本可控，功能迭代快；私有化部署适合有严格数据边界要求的场景，但需要准备GPU资源，还可能要自己维护推理服务。教学里我会用一张对比表把两者的差异列出来，包括前期时间、单位调用成本、数据存储位置、可定制程度。针对硬件研发等高性能计算场景，可以额外演示一个行业扩展案例——用一个轻量级开源模型辅助生成Verilog寄存器描述代码或测试平台代码，再在内部仿真工具里校验。这个案例不是为了培养芯片设计能力，而是让学员看到：AI落地的边界，只取决于这个领域能不能把任务拆成“输入-输出-校验”的闭环。

成本估算是很多技术型学员的盲区。他们会认真调模型，但从不计算一次调用花了多少钱。我在课上会给出一个简单的推演公式：单个任务费用约等于输入Token数乘以输入单价，加上输出Token数乘以输出单价；如果所有学员共用一个大模型服务，还要把并发和缓存考虑进去。比如一个RAG问答任务平均输入2000 Token、输出300 Token，学生做20次训练，100个人合计约460万Token，再乘以模型单价就能得出大约的成本区间。这个方法不求精确，但能帮团队快速判断一个AI功能是不是做得起。

部署层还应该包含“如何选择合适尺寸的模型”这个点。很多技术同学一上来就选最大参数模型，理由是效果最好，但没考虑推理速度和显存成本。一个70B级别的大模型即使在量化后也需要高配置GPU服务器，而一个7B到14B级别的模型经过针对性调优后，已经能胜任很多内部文档总结和结构化信息提取任务。所以部署课程会专门教一件事：先用小模型跑通流程并用测试集打分，如果效果不够再逐步升级模型，不要一开始就把资源拉满。

2.6 模块六：多模态内容生成，以及产品化评估

这个模块更像一个“面向真实业务形态”的收口。很多学员来自运营和市场岗位，他们的兴趣点是：AI能不能帮我们批量制作短视频、图片、宣传文案、甚至AI短剧或漫剧？当然能，而且流程已经比较成熟。但课程的落点不是“AI能画出什么样的图”，而是“从头到尾搭一条可重复的内容生产流水线”。

内容生产流水线我会拆成几个环节：确定主题 → 生成脚本/分镜 → 生成画面素材或视频片段 → 加入配音和字幕 → 人工审核 → 发布。每个环节都有对应的AI工具，但真正决定生产效率的是脚本结构、提示词模板、素材管理规范和审核节点。举个例子，如果一个团队要定期产出短视频，他们不应该每次都从头让AI写剧本，而应该在课程里沉淀下来一套“选题库+剧本提示词模板+分镜模板+审核清单”，这样后续每期内容都是在既定框架内迭代，效率和稳定性才会高。

对产品经理类学员，这一模块的核心是结果指标设计。我给了一个非常实际的指标集：每次问答或每次生成任务的平均成本、首轮解决率、人工修正率、用户最终满意度。没有这些指标，AI产品永远只能靠“感觉好不好”来判断，很难持续优化。课程要求每个Product方向的结业项目必须写清楚：项目服务谁、核心流程是什么、成功标准是什么、如果失败的话最可能卡在哪一环。这个习惯放到真实工作里可以直接使用。

3. 把模块变成课堂任务：实训设计和作业体系

3.1 先用一张“任务卡”让所有人进入状态

很多课的问题在于“听起来全懂，做起来全懵”。为了减少这种落差，我给每个实训任务都设计了结构化的任务卡，包含角色、输入材料、目标输出、约束条件、验收标准五个字段。拿模块一的例子来说，任务卡长这样：学员是数据分析助理，输入是一份客服对话记录，目标是从中提取用户诉求、情绪倾向和是否包含激烈投诉，输出必须是结构化表格，并且不得编造对话里不存在的内容，验收标准是至少20条测试样本中，关键字段准确率达到90%以上。

这个任务看起来简单，实际操作中很多人第一次会做的“过于复杂”——又是调角色，又是加各种提示词，结果测试准确率反而下降。我一般会引导大家先做减法：用最简单的指令跑完20条，找到最容易错的3类样本，再针对错误补充规则。这种训练能帮助学员建立一种工程直觉：AI应用优化是迭代过程，不是一次性魔法。

3.2 RAG和Agent模块建议用“业务数据”而不是“网上随便找的资料”

企业内部培训最容易忽略的一点是练习数据。如果RAG练习使用过于规整的公开文档，学员会认为RAG很简单，换到杂乱无章的真实业务数据后立刻崩溃。我在课程里是有意拿一些“不那么干净”的资料作为练习素材的，比如扫描版制度文件、带页眉页脚的合同扫描件、表格内容错位的产品说明。处理这些材料的过程，才是真正有价值的训练。

到Agent环节，练习会再上一个台阶。示例项目里的Agent只允许查询课程自建的模拟库存系统和模拟订单系统，不允许调用任何公网接口，也不允许执行修改类操作。项目要求很具体：用户发一句“明天要开新产品发布会，帮我检查物料库存”，Agent需要调用库存接口、对比物料清单、标记缺失项目、并生成一份需要人工确认的补充采购建议。要想完成这个任务，学员得学会给工具写规范文档，让模型能判断何时调用、怎么把参数填对。这里的难点并不是模型能力不足，而是工具描述不清晰，经常会出现参数写错、逻辑混乱等问题。这些踩坑过程，我认为比顺利跑通一个完美Demo更有教学价值。

3.3 Capstone项目题目库和验收标准应该怎么定

整个课程的收尾是分组完成一个综合项目，时间大概占用最后三分之一。项目题目不能是老师随口想出来的，我会从业务优先角度去准备一组参考题目，让学员按岗位选择：

验收标准不能只看“结果看起来不错”，要尽量数据化。以智能客服项目为例，我关心的指标包括：测试集上的答案和资料相关内容是否符合要求、拒答率是否合理、单次平均响应时长多少、整体调用成本约多少、需要人工介入的比例多大。如果学员能把这些问题用一张表说清楚，比在答辩现场放十分钟花哨的演示更代表真实能力。

4. 课程落地时最容易出问题的四个位置以及我的处理办法

4.1 只有“展示”，没有“评测”，学员会误以为AI无所不能

我前面反复提到测试集，这里再集中展开一次。AI应用的价值判断很容易滑向“凭感觉打分”，但实际工程化必须建立最小评估集。课程中我会让学员自己为项目创建至少20条典型输入，并且给每一条提前写好“标准答案”或“必须包含的关键信息”，之后每次改动提示词、切换模型或调整检索参数，都用同一套数据重跑，比对输出变化。

评估指标不追求复杂，重点看几个维度：回答正确率或任务完成率、内容忠实度、输出格式合规率、平均耗时和成本。为了让学员有体感，我还会让他们做一次“回归实验”：把同一个问题在两周后重新跑一遍，很多学员会发现模型输出可能已经变了，哪怕代码一行都没改。这个现象对一个AI应用开发者来说极其重要，所以课程里必须建立“线上效果持续监控”的意识，而这些意识的起点，就是一个可控的测试集。

4.2 AI工具版本迭代太快，课堂演示经常“当场翻车”

课程设计完到正式上课之间一般隔着几周时间，这时候很容易出现一个问题：老师上周录制的演示视频和现在最新版工具界面已经完全不一样了。很多应届同学照着视频操作，点不到对应按钮，教学进度直接卡住。

我的处理方式是给课程指定“工具版本基线”。正式上课前，我会和学生说明：这个训练周期内，我们统一使用固定版本的核心框架和必要插件，不在中途随意升级。所有线上文档和示例代码都以该版本为准，最新版的新功能放到“附录和扩展阅读”里讲，不作为考核内容。同时，凡是依赖外部云端界面的操作，我要求在讲课前一天的晚上跑一遍完整流程，因为很多云端服务在夜间升级，早上上课时可能就变了。这些话都被验证过很多次，真不是我过度谨慎。

4.3 资源预算和并发限制要在开班之前就设计好

AI课程最大的一笔隐形开销是模型调用费用。如果不提前设限，很容易出现学员为了完成大作业无限调用模型，最后账单出来吓人一跳。我的经验是按项目预算给学生发一个“虚拟额度”，比如每人一个训练周期内可用的Token配额，超出部分需要申请说明理由。这种做法不是限制学习热情，而是让学员培养成本意识，知道一个功能上线之后每月大概多少调用量、该不该加缓存策略，以及是否需要对用户提问长度加以控制。

同时要考虑并发对延迟的影响。如果几十个学员同时发起请求，共用同一个对外服务会被限流，课堂演示会非常慢。我在班里的做法是提前向服务提供方报备使用时间和大致并发数，或者把班级分组，让不同组在不同时间段访问需要耗用大量资源的应用。看似是琐碎事务，但处理不当会直接影响教学质量和学员体验。

4.4 权限和数据底线必须作为一门独立课程内容来写

AI课程不可能绕开安全和合规，但我不会把它讲成空洞的说教，而是把它落成几条非常具体的工程约束。第一条：任何学员项目里不能直接接触真实生产数据，练习一律使用脱敏数据或模拟数据。第二条：所有访问密钥不能出现在代码和共享文档里，必须通过环境变量或密钥管理服务注入。第三条：凡是涉及Agent自动执行动作的，必须预留人工确认环节，尤其是退款、删除、发布、发送消息等高风险操作。第四条：对生成式内容，尤其是图片、视频和文案，要建立素材权限检查意识，不把未经授权的肖像、商标、版权素材直接丢进生成流程。

我把这些要求从一开始就写进课程大纲，而不是放到最后“提醒一下”。当“安全约束”成为每个项目研发的前置条件之后，学员做出的选型方案从一开始就是工程化和稳妥的。反而那些觉得“先不管限制、能实现最重要”的思路，在真实项目里几乎都会回头补课，返工成本非常高。

4.5 不同岗位学员结课之后，怎么继续保持练习方向

课程时间终归有限，很多学员结课时只是刚刚入了门。我会在最后给不同岗位学员分别留一个“课后一个月”的行动建议。对研发人员，建议把近期一个低风险真实需求用AI辅助完成，并记录与不使用的效果差异；对产品人员，建议挑一个现有功能，画一遍AI改造方案，并估算改动成本和收益；对内容和运营人员，建议建立一套属于自己的AI模板库，把高频重复的写作、修图、剪辑需求标准化。

这些建议不需要占用大量教学时间，但要清晰写进讲义里，让学员感觉离开课堂后仍然有一条可以继续往前走的路线。就我个人经验而言，真正决定一次AI培训有效性的，往往不是课堂上讲了多少高深理论，而是它有没有给学员留下一个可重复运转的工作习惯和一个能观察到效果变化的评估框架。这个框架一旦建立，后续工具怎么换、模型怎么升级都不重要，因为他们已经知道该怎么判断新工具的好坏。