构建生成式 AI 聊天应用从 API 集成、个性化定制到质量监控的完整实战指南【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners本文基于generative-ai-for-beginners仓库第 7 课07-building-chat-applications编写。上一课我们已经掌握了文本生成应用的基本构建方法本课在此基础上进一步深入如何把生成式 AI 真正集成进聊天应用完成从能对话到好用、可定制、可监控、负责任的完整升级。读完本文你将掌握聊天应用的核心架构选型Chatbot 与 AI 聊天应用的区别、基于 SDK/API 的快速接入方法、UX 与可访问性设计要点、面向特定领域的定制与微调策略以及一套可落地的质量指标与负责任 AI 实践框架。为什么需要专门研究聊天应用聊天应用已经成为日常生活的基础设施其价值远不止于闲谈它是客户服务、技术支持乃至复杂咨询系统的重要组成部分。当生成式 AI 被集成进这些平台后系统复杂度急剧上升随之而来的核心问题有两个构建应用如何针对特定用例高效构建并无缝集成这些 AI 能力监控运维应用上线后如何从功能质量和 负责任 AI 六原则 两个维度持续保障其处于最高质量水平本课将依次探讨支撑这些复杂系统的架构要素、针对特定领域任务的定制方法以及确保 AI 负责任落地所需的度量指标与考量。先厘清概念Chatbot 还是 AI 聊天应用动手之前必须先区分Chatbot与生成式 AI 聊天应用这两个角色。Chatbot 的核心目标是自动化特定的对话任务如回答常见问题、跟踪包裹通常由基于规则的逻辑或 AI 算法驱动而生成式 AI 聊天应用是一个更广阔的环境用于承载文本、语音、视频等多种数字通信形态其标志性特征是集成了能够模拟细腻、类人对话的生成式 AI 模型——它可以参与开放域讨论、适应不断演变的对话上下文甚至产出有创意的复杂对话。Chatbot生成式 AI 聊天应用聚焦任务、基于规则上下文感知常被嵌入更大的系统可承载一个或多个 Chatbot局限于预设功能内嵌生成式 AI 模型专业化、结构化交互可进行开放域讨论用 SDK 与 API 复用预置能力构建聊天应用时一个明智的起步动作是评估现成的东西集成文档完善的 SDK 和 API能让应用在可扩展性与可维护性上占据长期优势。本课总结了四点收益加速开发、降低开销复用预置功能把精力投入到更重要的业务逻辑上而不是重复造轮子。更好的性能自己从零实现时迟早要面对怎么扩容能扛住突发流量吗这类问题维护良好的 SDK/API 往往内置了这些解决方案。更简单的维护新版本发布时多数 API/SDK 只需升级一个库即可完成更新。接触前沿技术直接调用在海量数据集上训练、微调过的模型让应用即刻获得自然语言能力。接入 SDK/API 通常需要先取得服务授权最常见的形式是唯一的 API Key 或认证令牌。本课以 OpenAI Python 库为例展示这一流程对应练习见 OpenAI 版 Notebook 与 Azure OpenAI 版 Notebookimport os from openai import OpenAI API_KEY os.getenv(OPENAI_API_KEY,) client OpenAI( api_keyAPI_KEY ) chat_completion client.chat.completions.create(modelgpt-3.5-turbo, messages[{role: user, content: Suggest two titles for an instructional lesson on chat applications for generative AI.}])上面的示例使用 GPT-3.5 Turbo 模型完成 prompt 补全但请注意API Key 必须在调用前设置好否则会直接报错。在仓库的作业 Notebook 中同样的首个聊天 prompt练习已经升级为 OpenAI 的 Responses API07-building-chat-applications/python/oai-assignment.ipynbtext_prompt Should oxford commas always be used? response client.responses.create( modelmodel, input [{role:system, content:You are a helpful assistant.}, {role:user,content:text_prompt},], storeFalse,) response.output_text注意这里input参数已经是一个由 system 角色与 user 角色组成的消息数组——这正是聊天应用与单轮文本生成应用的关键差异多轮消息结构让模型能够感知上下文。Notebook 还引导你重复同样的调用对比多次输出的差异直观体会生成模型输出的随机性。仓库中的多语言实现对照第 7 课作业刻意覆盖了多种语言与接入方式仓库里的三套实现正好印证了SDK/API 多样化接入的主题Python Azure AI Inference SDKgithubmodels-assignment.ipynb使用ChatCompletionsClient并显式构造SystemMessage、UserMessage凭据与端点从AZURE_INFERENCE_CREDENTIAL、AZURE_INFERENCE_ENDPOINT环境变量读取from azure.ai.inference import ChatCompletionsClient from azure.ai.inference.models import SystemMessage, UserMessage from azure.core.credentials import AzureKeyCredential client ChatCompletionsClient( endpointos.environ[AZURE_INFERENCE_ENDPOINT], credentialAzureKeyCredential(os.environ[AZURE_INFERENCE_CREDENTIAL]), )其思路是只需修改model_name变量就能在 Microsoft Foundry 模型目录中跨 GPT-4o mini、Meta Llama、Mistral、Cohere、Phi 等模型间切换实验该 Notebook 同时说明 GitHub Models 将于 2026 年 7 月底停用现已转向同样提供免费试用模型目录的 Microsoft Foundry Models。JavaScript Azure AI Inference SDKapp.jsModelClient在启动时对两个必需环境变量做显式校验缺失即抛出错误再向/chat/completions端点 POST 消息数组其中包含两个 system 消息加一个 user 消息的多系统消息组合最后遍历response.body.choices输出每个候选的message.content。TypeScript OpenAI SDK 指向 Azure OpenAI v1 端点src/main.ts通过dotenv加载配置把 OpenAI 客户端baseURL指向your-endpoint/openai/v1/以部署名作为model参数调用client.responses.create并显式传入max_output_tokens: 100与store: false。三套代码的共同模式值得注意聊天的本质是消息列表的传递system 定义行为、user 提出诉求这是聊天应用区别于普通文本生成的结构基础。用户体验UX设计通用原则之外的三个关键点通用 UX 原则同样适用于聊天应用但由于机器学习组件的引入以下三点变得尤其重要处理歧义的机制生成式 AI 偶尔会产出模棱两可的回答。提供一个允许用户追问澄清的功能能有效化解这类问题。上下文保留先进模型能记住对话内的上下文这是体验的必要资产把上下文的控制与管理权交给用户可提升体验但也带来保留敏感用户信息的风险。因此需要引入保留策略retention policy等机制在上下文需求与隐私之间取得平衡。个性化AI 模型具备学习与适应能力能为用户提供个性化体验。通过用户画像user profiles等特性定制体验既让用户感到被理解也有助于更快找到特定答案。个人化的典型例子是 OpenAI ChatGPT 中的自定义指令Custom instructions设置它允许你提供关于自身的背景信息作为 prompt 的重要上下文这个画像让 ChatGPT 生成关于链表linked lists的教案并且 ChatGPT 会结合用户的经验背景判断其可能需要更深入的教案用 System Message 框架约束模型行为Microsoft 针对如何为 LLM 编写有效的 system message 提供了指导拆解为 4 个方面定义模型的服务对象以及它的能力与局限定义模型的输出格式提供具体示例演示模型应有的行为提供额外的行为护栏behavioral guardrails。仓库示例是这套框架的直接体现无论是 app.js 中的Youre the president of FranceYou have just resigned还是 main.ts 与 Notebook 中的You are a helpful assistant.都是在用 system 消息提前定义角色、情境与边界再让 user 消息触发具体任务。这意味着写好 system message是控制聊天应用输出质量成本最低的手段之一。可访问性让所有人可用无论用户存在视觉、听觉、运动还是认知障碍设计良好的聊天应用都应人人可用。本课按障碍类型拆解了具体特性视觉障碍高对比度主题、可缩放文本、屏幕阅读器兼容听觉障碍文本转语音与语音转文本功能、音频通知的视觉提示运动障碍键盘导航支持、语音命令认知障碍简化语言选项。面向特定领域的定制DSL 模型与微调想象一个能听懂你公司行话、预判用户常见问题的聊天应用。本课给出两条值得关注的路径利用 DSL 模型DSL 指领域特定语言Domain Specific Language。可以借助在特定领域上训练的所谓 DSL 模型来理解该领域的概念与场景。使用方式从从零训练一个到通过 SDK/API 使用现成模型不等也可以选择微调——对预训练模型做领域适配。应用微调Fine-tuning微调是用特定数据对模型做进一步训练的过程通常在预训练模型无法胜任某个专业领域或特定任务时被采用。场景一个医疗应用设想一个帮助医生快速查阅治疗指南、药物相互作用或最新研究成果的聊天应用。通用模型或许能回答基础医学问题、给出一般性建议但在以下方面会力不从心高度特异或复杂的病例例如神经科医生询问目前管理儿童患者耐药性癫痫的最佳实践是什么缺乏最新进展通用模型难以给出融合神经学与药理学最新进展的时效性答案。此时用专门医学数据集微调模型能显著提升其处理这类复杂医学问询的准确性与可靠性——前提是能够获得一个足够大、且能代表领域内真实挑战与问题的相关数据集。高质量 AI 聊天体验的考量度量指标高质量聊天应用的判定标准包括捕获可操作的指标以及遵循负责任地利用 AI 技术的框架。指标定义对聊天开发者的考量正常运行时间Uptime应用处于可运行、用户可访问状态的时间占比如何将停机时间降到最低响应时间Response Time应用响应用户查询所花的时间如何优化查询处理以改善响应时间精确率Precision真正例预测占全部正预测的比例如何验证模型的精确率召回率Recall/Sensitivity真正例预测占实际正例的比例如何测量并提升召回率F1 分数精确率与召回率的调和平均平衡二者取舍F1 目标是多少如何平衡精确率与召回率困惑度Perplexity衡量模型预测的概率分布与数据真实分布的契合度如何最小化困惑度用户满意度指标衡量用户对应用的感知常通过问卷调查捕获多久收集一次用户反馈如何据此调整错误率Error Rate模型在理解或输出上出错的频率有哪些降低错误率的策略重训周期Retraining Cycles模型为纳入新数据与洞察而更新的频率多久重训一次什么会触发一轮重训异常检测Anomaly Detection识别不符合预期行为的不寻常模式的工具与技术如何响应异常这些测量不仅保障应用的功能性还评估 AI 模型质量与用户体验。第 7 课作业 Notebook如 oai-assignment.ipynb正是实践这些维度的载体从运行第一个聊天 prompt到文本摘要、分类、生成产品名再到微调一个分类器覆盖了模型从能跑到跑得好的评估闭环。在聊天应用中落实负责任 AI 实践Microsoft 的负责任 AI 方法归纳了指导 AI 开发与使用的六项原则下表列出各原则的定义、聊天开发者应牢记的考量及其重要性原则Microsoft 定义对聊天开发者的考量为什么重要公平FairnessAI 系统应公平对待所有人确保聊天应用不因用户数据而歧视建立用户间的信任与包容避免法律后果可靠与安全Reliability and SafetyAI 系统应可靠、安全地运行实施测试与故障安全机制将错误与风险降到最低保障用户满意度防止潜在伤害隐私与安全Privacy and SecurityAI 系统应安全并尊重隐私实施强加密与数据保护措施保护敏感用户数据遵守隐私法规包容InclusivenessAI 系统应赋能所有人并让人们参与设计对多元化受众可访问、易用的 UI/UX确保更广泛的人群能有效使用应用透明TransparencyAI 系统应可被理解为 AI 回复提供清晰的文档与解释用户理解决策机制后更可能信任系统问责Accountability人们应为 AI 系统负责建立审计与改进 AI 决策的清晰流程支撑持续改进在出错时提供纠正措施动手实践本课作业访问本课作业目录 07-building-chat-applications/python其中包含一系列从易到难的练习运行你的第一个聊天 prompt再到文本分类、摘要等更多任务。注意本课作业以多种编程语言提供——除了 Python 的 OpenAI / Azure OpenAI / Microsoft Foundry 三个 Notebook 版本外仓库还附带了 JavaScriptjs-githubmodels与 TypeScripttypescript/chat-completions-app实现以及 .NET 的 dotnet/notebook-azure-openai.dib你可以任选熟悉的技术栈完成练习。下一步完成本课后可继续进入第 8 课学习如何构建搜索应用。在此之前建议先按本课的三条主线复盘消息结构与 system message 的编排是否到位、领域定制DSL / 微调是否必要、质量指标与负责任 AI 原则是否已纳入上线前的检查清单——这三件事共同决定了一个聊天应用能否从demo走向生产。【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 构建生成式 AI 聊天应用：从 API 集成、个性化定制到质量监控的完整实战指南
构建生成式 AI 聊天应用从 API 集成、个性化定制到质量监控的完整实战指南【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners本文基于generative-ai-for-beginners仓库第 7 课07-building-chat-applications编写。上一课我们已经掌握了文本生成应用的基本构建方法本课在此基础上进一步深入如何把生成式 AI 真正集成进聊天应用完成从能对话到好用、可定制、可监控、负责任的完整升级。读完本文你将掌握聊天应用的核心架构选型Chatbot 与 AI 聊天应用的区别、基于 SDK/API 的快速接入方法、UX 与可访问性设计要点、面向特定领域的定制与微调策略以及一套可落地的质量指标与负责任 AI 实践框架。为什么需要专门研究聊天应用聊天应用已经成为日常生活的基础设施其价值远不止于闲谈它是客户服务、技术支持乃至复杂咨询系统的重要组成部分。当生成式 AI 被集成进这些平台后系统复杂度急剧上升随之而来的核心问题有两个构建应用如何针对特定用例高效构建并无缝集成这些 AI 能力监控运维应用上线后如何从功能质量和 负责任 AI 六原则 两个维度持续保障其处于最高质量水平本课将依次探讨支撑这些复杂系统的架构要素、针对特定领域任务的定制方法以及确保 AI 负责任落地所需的度量指标与考量。先厘清概念Chatbot 还是 AI 聊天应用动手之前必须先区分Chatbot与生成式 AI 聊天应用这两个角色。Chatbot 的核心目标是自动化特定的对话任务如回答常见问题、跟踪包裹通常由基于规则的逻辑或 AI 算法驱动而生成式 AI 聊天应用是一个更广阔的环境用于承载文本、语音、视频等多种数字通信形态其标志性特征是集成了能够模拟细腻、类人对话的生成式 AI 模型——它可以参与开放域讨论、适应不断演变的对话上下文甚至产出有创意的复杂对话。Chatbot生成式 AI 聊天应用聚焦任务、基于规则上下文感知常被嵌入更大的系统可承载一个或多个 Chatbot局限于预设功能内嵌生成式 AI 模型专业化、结构化交互可进行开放域讨论用 SDK 与 API 复用预置能力构建聊天应用时一个明智的起步动作是评估现成的东西集成文档完善的 SDK 和 API能让应用在可扩展性与可维护性上占据长期优势。本课总结了四点收益加速开发、降低开销复用预置功能把精力投入到更重要的业务逻辑上而不是重复造轮子。更好的性能自己从零实现时迟早要面对怎么扩容能扛住突发流量吗这类问题维护良好的 SDK/API 往往内置了这些解决方案。更简单的维护新版本发布时多数 API/SDK 只需升级一个库即可完成更新。接触前沿技术直接调用在海量数据集上训练、微调过的模型让应用即刻获得自然语言能力。接入 SDK/API 通常需要先取得服务授权最常见的形式是唯一的 API Key 或认证令牌。本课以 OpenAI Python 库为例展示这一流程对应练习见 OpenAI 版 Notebook 与 Azure OpenAI 版 Notebookimport os from openai import OpenAI API_KEY os.getenv(OPENAI_API_KEY,) client OpenAI( api_keyAPI_KEY ) chat_completion client.chat.completions.create(modelgpt-3.5-turbo, messages[{role: user, content: Suggest two titles for an instructional lesson on chat applications for generative AI.}])上面的示例使用 GPT-3.5 Turbo 模型完成 prompt 补全但请注意API Key 必须在调用前设置好否则会直接报错。在仓库的作业 Notebook 中同样的首个聊天 prompt练习已经升级为 OpenAI 的 Responses API07-building-chat-applications/python/oai-assignment.ipynbtext_prompt Should oxford commas always be used? response client.responses.create( modelmodel, input [{role:system, content:You are a helpful assistant.}, {role:user,content:text_prompt},], storeFalse,) response.output_text注意这里input参数已经是一个由 system 角色与 user 角色组成的消息数组——这正是聊天应用与单轮文本生成应用的关键差异多轮消息结构让模型能够感知上下文。Notebook 还引导你重复同样的调用对比多次输出的差异直观体会生成模型输出的随机性。仓库中的多语言实现对照第 7 课作业刻意覆盖了多种语言与接入方式仓库里的三套实现正好印证了SDK/API 多样化接入的主题Python Azure AI Inference SDKgithubmodels-assignment.ipynb使用ChatCompletionsClient并显式构造SystemMessage、UserMessage凭据与端点从AZURE_INFERENCE_CREDENTIAL、AZURE_INFERENCE_ENDPOINT环境变量读取from azure.ai.inference import ChatCompletionsClient from azure.ai.inference.models import SystemMessage, UserMessage from azure.core.credentials import AzureKeyCredential client ChatCompletionsClient( endpointos.environ[AZURE_INFERENCE_ENDPOINT], credentialAzureKeyCredential(os.environ[AZURE_INFERENCE_CREDENTIAL]), )其思路是只需修改model_name变量就能在 Microsoft Foundry 模型目录中跨 GPT-4o mini、Meta Llama、Mistral、Cohere、Phi 等模型间切换实验该 Notebook 同时说明 GitHub Models 将于 2026 年 7 月底停用现已转向同样提供免费试用模型目录的 Microsoft Foundry Models。JavaScript Azure AI Inference SDKapp.jsModelClient在启动时对两个必需环境变量做显式校验缺失即抛出错误再向/chat/completions端点 POST 消息数组其中包含两个 system 消息加一个 user 消息的多系统消息组合最后遍历response.body.choices输出每个候选的message.content。TypeScript OpenAI SDK 指向 Azure OpenAI v1 端点src/main.ts通过dotenv加载配置把 OpenAI 客户端baseURL指向your-endpoint/openai/v1/以部署名作为model参数调用client.responses.create并显式传入max_output_tokens: 100与store: false。三套代码的共同模式值得注意聊天的本质是消息列表的传递system 定义行为、user 提出诉求这是聊天应用区别于普通文本生成的结构基础。用户体验UX设计通用原则之外的三个关键点通用 UX 原则同样适用于聊天应用但由于机器学习组件的引入以下三点变得尤其重要处理歧义的机制生成式 AI 偶尔会产出模棱两可的回答。提供一个允许用户追问澄清的功能能有效化解这类问题。上下文保留先进模型能记住对话内的上下文这是体验的必要资产把上下文的控制与管理权交给用户可提升体验但也带来保留敏感用户信息的风险。因此需要引入保留策略retention policy等机制在上下文需求与隐私之间取得平衡。个性化AI 模型具备学习与适应能力能为用户提供个性化体验。通过用户画像user profiles等特性定制体验既让用户感到被理解也有助于更快找到特定答案。个人化的典型例子是 OpenAI ChatGPT 中的自定义指令Custom instructions设置它允许你提供关于自身的背景信息作为 prompt 的重要上下文这个画像让 ChatGPT 生成关于链表linked lists的教案并且 ChatGPT 会结合用户的经验背景判断其可能需要更深入的教案用 System Message 框架约束模型行为Microsoft 针对如何为 LLM 编写有效的 system message 提供了指导拆解为 4 个方面定义模型的服务对象以及它的能力与局限定义模型的输出格式提供具体示例演示模型应有的行为提供额外的行为护栏behavioral guardrails。仓库示例是这套框架的直接体现无论是 app.js 中的Youre the president of FranceYou have just resigned还是 main.ts 与 Notebook 中的You are a helpful assistant.都是在用 system 消息提前定义角色、情境与边界再让 user 消息触发具体任务。这意味着写好 system message是控制聊天应用输出质量成本最低的手段之一。可访问性让所有人可用无论用户存在视觉、听觉、运动还是认知障碍设计良好的聊天应用都应人人可用。本课按障碍类型拆解了具体特性视觉障碍高对比度主题、可缩放文本、屏幕阅读器兼容听觉障碍文本转语音与语音转文本功能、音频通知的视觉提示运动障碍键盘导航支持、语音命令认知障碍简化语言选项。面向特定领域的定制DSL 模型与微调想象一个能听懂你公司行话、预判用户常见问题的聊天应用。本课给出两条值得关注的路径利用 DSL 模型DSL 指领域特定语言Domain Specific Language。可以借助在特定领域上训练的所谓 DSL 模型来理解该领域的概念与场景。使用方式从从零训练一个到通过 SDK/API 使用现成模型不等也可以选择微调——对预训练模型做领域适配。应用微调Fine-tuning微调是用特定数据对模型做进一步训练的过程通常在预训练模型无法胜任某个专业领域或特定任务时被采用。场景一个医疗应用设想一个帮助医生快速查阅治疗指南、药物相互作用或最新研究成果的聊天应用。通用模型或许能回答基础医学问题、给出一般性建议但在以下方面会力不从心高度特异或复杂的病例例如神经科医生询问目前管理儿童患者耐药性癫痫的最佳实践是什么缺乏最新进展通用模型难以给出融合神经学与药理学最新进展的时效性答案。此时用专门医学数据集微调模型能显著提升其处理这类复杂医学问询的准确性与可靠性——前提是能够获得一个足够大、且能代表领域内真实挑战与问题的相关数据集。高质量 AI 聊天体验的考量度量指标高质量聊天应用的判定标准包括捕获可操作的指标以及遵循负责任地利用 AI 技术的框架。指标定义对聊天开发者的考量正常运行时间Uptime应用处于可运行、用户可访问状态的时间占比如何将停机时间降到最低响应时间Response Time应用响应用户查询所花的时间如何优化查询处理以改善响应时间精确率Precision真正例预测占全部正预测的比例如何验证模型的精确率召回率Recall/Sensitivity真正例预测占实际正例的比例如何测量并提升召回率F1 分数精确率与召回率的调和平均平衡二者取舍F1 目标是多少如何平衡精确率与召回率困惑度Perplexity衡量模型预测的概率分布与数据真实分布的契合度如何最小化困惑度用户满意度指标衡量用户对应用的感知常通过问卷调查捕获多久收集一次用户反馈如何据此调整错误率Error Rate模型在理解或输出上出错的频率有哪些降低错误率的策略重训周期Retraining Cycles模型为纳入新数据与洞察而更新的频率多久重训一次什么会触发一轮重训异常检测Anomaly Detection识别不符合预期行为的不寻常模式的工具与技术如何响应异常这些测量不仅保障应用的功能性还评估 AI 模型质量与用户体验。第 7 课作业 Notebook如 oai-assignment.ipynb正是实践这些维度的载体从运行第一个聊天 prompt到文本摘要、分类、生成产品名再到微调一个分类器覆盖了模型从能跑到跑得好的评估闭环。在聊天应用中落实负责任 AI 实践Microsoft 的负责任 AI 方法归纳了指导 AI 开发与使用的六项原则下表列出各原则的定义、聊天开发者应牢记的考量及其重要性原则Microsoft 定义对聊天开发者的考量为什么重要公平FairnessAI 系统应公平对待所有人确保聊天应用不因用户数据而歧视建立用户间的信任与包容避免法律后果可靠与安全Reliability and SafetyAI 系统应可靠、安全地运行实施测试与故障安全机制将错误与风险降到最低保障用户满意度防止潜在伤害隐私与安全Privacy and SecurityAI 系统应安全并尊重隐私实施强加密与数据保护措施保护敏感用户数据遵守隐私法规包容InclusivenessAI 系统应赋能所有人并让人们参与设计对多元化受众可访问、易用的 UI/UX确保更广泛的人群能有效使用应用透明TransparencyAI 系统应可被理解为 AI 回复提供清晰的文档与解释用户理解决策机制后更可能信任系统问责Accountability人们应为 AI 系统负责建立审计与改进 AI 决策的清晰流程支撑持续改进在出错时提供纠正措施动手实践本课作业访问本课作业目录 07-building-chat-applications/python其中包含一系列从易到难的练习运行你的第一个聊天 prompt再到文本分类、摘要等更多任务。注意本课作业以多种编程语言提供——除了 Python 的 OpenAI / Azure OpenAI / Microsoft Foundry 三个 Notebook 版本外仓库还附带了 JavaScriptjs-githubmodels与 TypeScripttypescript/chat-completions-app实现以及 .NET 的 dotnet/notebook-azure-openai.dib你可以任选熟悉的技术栈完成练习。下一步完成本课后可继续进入第 8 课学习如何构建搜索应用。在此之前建议先按本课的三条主线复盘消息结构与 system message 的编排是否到位、领域定制DSL / 微调是否必要、质量指标与负责任 AI 原则是否已纳入上线前的检查清单——这三件事共同决定了一个聊天应用能否从demo走向生产。【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考