微软生成式 AI 入门课第 14 课的应用生命周期：从原型到上线中间少了哪几步

2026-08-18

先说清楚这篇文章从哪儿开始。你照着 06-text-generation-apps/python/oai-app.py 那类脚本把第一个文本生成应用搭起来了——文件里就是 load_dotenv() 读配置、client = OpenAI() 建客户端、client.responses.create(model=deployment, input=prompt, store=False) 发一次请求、print(response.output_text) 打印结果，主干四行。然后呢？这中间到「可以放给别人用」之间，缺的到底是哪几步——14-the-generative-ai-application-lifecycle/README.md 这一课回答的就是这个问题。

它的正文不长，也没有配套代码目录（这一课的目录下只有 README 与 images，没有 python/ 之类的示例文件夹）。所以它更像一张检查表，而不是一段能跑的东西。既然是检查表，那就得把每一格对应到你手里的什么产出物上，否则读完只剩几个名词。

先换坐标系：从 MLOps 到 LLMOps

课程开头没有直接给流程图，而是先摆了一次视角切换：过去的应用是 “ML Apps”，现在是 “GenAI Apps”。README 里写明，在 LLMOps 下关注点更偏向应用开发者，集成是关键，模型按 “Models-as-a-Service” 来用。

跟着这个视角，它列出了度量的几个方向，我把课程给的原名保留：Quality（响应质量）、Harm（负责任 AI）、Honesty（响应的 groundedness，即答案站不站得住）、Cost（方案预算）、Latency（token 响应的平均时间）。一共五项。

这五项值得单独停一下，因为它们的可测性差得很远。Cost 与 Latency 是工程量，你在代码里就能埋点拿到；Quality、Harm、Honesty 三项要么靠人判、要么靠另一个模型判。课程正文只把这五项列出来，并没有给出评分脚本——这一点后面还会再提，因为它决定了这一课在实操里能用到什么程度。

三大步：每一步交付什么

课程说流程图看着复杂，先抓三个大步骤。README 原文给的三步是这样的：

1. Ideating/Exploring（构思与探索）。按业务需求做探索，做原型，建一个 PromptFlow，测一下这个 flow 对你的假设来说够不够用。这一步的产出物就是「假设成立与否」的一个判断，加上一个能跑的原型。你照着第 6 课抄下来的那个脚本，就落在这个格子里。

2. Building/Augmenting（构建与增强）。课程写明这一步开始在更大的数据集上做评估，并引入 Fine-tuning、RAG 这类技术来检验方案的稳健性；如果不行，就重新实现、在 flow 里加新步骤，或者重构数据。原文最后一句是关键：测过流程与规模、并且核对了指标之后，才算可以进下一步。

3. Operationalizing（运营化）。这一步是集成：给系统加上监控与告警，做部署，把它接进你的应用。

三步之外还有一个环——课程称之为 overarching cycle of Management，聚焦安全、合规与治理。注意它的措辞是「贯穿的」，不是排在第四位的一个阶段。同样值得注意的是 README 明确写了：这不是线性的，而是集成在一起的循环，迭代进行。所以把这三步画成一条从左到右的流水线，是读反了。

评估到底出现在哪几处

这是这一课最容易被读漏的部分。按课程正文，评估不是某一步的名字，它在三个不同位置各出现一次，性质完全不同：

第一处在探索阶段的末尾：判断的是「假设是否成立」，是定性的、一次性的。课程用词是测试这个 flow 对假设来说是否 efficient enough。
第二处在构建阶段的末尾，是一道闸门：课程写的是在更大数据集上评估，核对指标通过后才进入下一步。这一处的产出物应该是一份可复现的评估结果，而不是「我试了几条觉得还行」。
第三处在运营化阶段，是持续的：形式变成了监控与告警系统，评估从一次性动作变成了线上的常驻能力。

再往前翻一课能补上一块。03-using-generative-ai-responsibly/README.md 的 “Mitigate Potential Harms” 一节给了四层缓解：Model（选型）、Safety System（平台侧的安全系统与内容过滤）、Metaprompt（元提示与 grounding，也包括用 RAG 只让模型从可信来源取信息）、User Experience（界面上限制用户能发什么、展示什么）。紧接着这四层，才是 “Evaluate model” 那一条，它要求度量输出的 accuracy、similarity、groundedness 与 relevance。

把这两处放在一起看，能对上一条线：第 3 课的 groundedness 就是第 14 课那五项里的 Honesty。区别在于第 3 课把评估摆在四层缓解之后，也就是说，它默认你先有了缓解措施，评估是用来验证这些措施是否奏效的，而不是拿来发现问题的第一道工序。这两课谁也没说另一个是错的，我只是把它们并排放着，剩下的判断留给你自己的项目。

仓库里哪些部分真的有代码

讲到这里得诚实一点：这一课的正文停在概念层，工具那一节指向的是 Azure AI Platform、PromptFlow 与 Microsoft Foundry（课程正文注明 Microsoft Foundry 的前身是 Azure AI Studio），也就是说要走完整个生命周期，落地要靠仓库之外的平台。

那这个课程仓自己给了什么？shared/python/ 下有三个工具模块（另有一个 __init__.py），是全课程共用的部分，也是「运营化」与「管理环」在这个仓里唯一有实际代码的落点：

env_utils.py：get_required_env(var_name, description=None) 取必需的环境变量，取不到就抛 ValueError 并在消息里提示去 .env 里设置；validate_env_vars(*var_names) 一次校验多个并返回字典。这对应的是配置与密钥不进代码这条纪律。
api_utils.py：make_safe_request(url, method="GET", timeout=30, retries=3, **kwargs)，函数体是一个按 retries 计数的循环，每次拿到响应后先调 raise_for_status() 再返回；捕获到 RequestException 时，不是最后一次就继续下一轮，是最后一次就把异常原样抛出去。代码里还留了一句注释说这里可以加指数退避，也就是说当前实现没有退避，重试是贴着来的。这里的 timeout 与 retries 数值是仓库当前代码里的默认值，随版本可能变动。同一文件里还有 create_openai_client 与 create_azure_openai_client 两个客户端构造函数，后者的文档字符串写明它指向 Azure OpenAI 的 v1 端点（<endpoint>/openai/v1/），因此不需要传 api_version。
input_validation.py：sanitize_prompt_input(value, max_length=1000, strict=False) 用于清洗要送进 prompt 的用户输入，函数文档字符串写明它针对的是 prompt injection。它剥掉控制字符，再按一组正则去掉模板注入 {{...}}、变量替换 ${...}、<script> 标签与 javascript: 这类模式；strict=True 时只保留一个更窄的字符集。同样，max_length 的数值是仓库当前代码里的默认值。

tests/ 目录里是 test_api_utils.py、test_env_utils.py、test_input_validation.py 三个测试文件加一个 conftest.py，覆盖的正是上面这三个模块，一一对应。conftest.py 只做一件事：把仓库根目录塞进 sys.path，让 shared.python 在任何工作目录下都能导入。test_api_utils.py 里用 monkeypatch.setattr 把 shared.python.api_utils.requests.request 换成假函数，断言 timeout 被正确传下去，另一个用例让假函数每次都抛 RequestException，再断言调用次数等于传入的 retries——也就是说，这套测试不打真实 API，验的是重试与参数传递这层控制流。

把这两件事并排放着，结论就很清楚：这个仓给的是输入侧与配置侧的可执行代码，第 14 课那五项度量里，Quality、Harm、Honesty 三项在仓库里只有概念，没有对应的评估脚本。这不是缺陷，课程本来就把工具指向了平台侧，但你如果指望 clone 下来就有一套 LLM 输出评估的 harness，会扑空。

两个会在阶段之间咬人的实际问题

生命周期里最疼的从来不是画图，而是「探索阶段成立的结论，到了构建阶段不成立了」。仓库里现成就有两个例子。

一是采样参数。 06-text-generation-apps/README.md 写明：当前 Microsoft Foundry 上未废弃的模型是 reasoning 模型（GPT-5 家族、o 系列），它们不支持 temperature 与 top_p，也不支持 max_tokens（改用 max_output_tokens）；把 temperature 发给 gpt-5-mini 会得到一个「参数不支持」的错误。该文档同时说明，要试温度这类例子，得指向仍支持采样控制的模型。这意味着你在探索阶段靠调温度得出的「输出可控性」结论，换一类模型就直接失效——这正是课程说流程「不是线性的」的一个具体形态。

二是 provider 路线。 仓库里同一课常有 oai-*、aoai-*、githubmodels-* 三套示例。这里有个必须交代的错位：00-course-setup/03-providers.md 写明 GitHub Models 于 2026 年 7 月底退役，直接替代者是 Microsoft Foundry Models；该文件的标签说明里也写着 githubmodels 这个文件名标签实际要求的是 Microsoft Foundry Models 的 endpoint 与 key。今天已经过了那个时间点。所以第三条路线的正确说法是「Microsoft Foundry Models（原 GitHub Models 路线）」，.env 里要填的是 AZURE_INFERENCE_ENDPOINT 与 AZURE_INFERENCE_CREDENTIAL，不要再把 GitHub Models 的 token 当作现行配置。前缀名和实际接入目标已经脱节，这一点以仓库最新内容为准。

拿这件事回看第 14 课就很有意思：一个 provider 在你项目周期内下线，属于典型的「贯穿的管理环」要接住的事，而不是某一个阶段的事。

落到你手上怎么用

给一个把上面几块串起来的最小骨架，按仓库代码的接口语义组合：

from shared.python.env_utils import validate_env_vars
from shared.python.input_validation import sanitize_prompt_input

env = validate_env_vars("AZURE_INFERENCE_ENDPOINT", "AZURE_INFERENCE_CREDENTIAL")
safe_prompt = sanitize_prompt_input(user_text, max_length=1000, strict=True)

以上为按仓库代码中的接口语义组合的示例，未经实测，以仓库最新代码为准。

这里的两个变量名只属于 Microsoft Foundry Models 那条路线；走 OpenAI 路线时 create_openai_client 读的是 OPENAI_API_KEY，走 Azure OpenAI 路线时 create_azure_openai_client 读的是 AZURE_OPENAI_ENDPOINT 与 AZURE_OPENAI_API_KEY。三套变量名互不通用，别混着填。

配置文件那一步，00-course-setup/03-providers.md 给的是 cp .env.copy .env。Windows 侧提醒一句：PowerShell 里 cp 是 Copy-Item 的别名，可以直接用；老式的 cmd 里没有 cp，需要换成 copy。这句属于通用的命令行常识，不是该课程的官方内容。密钥一律写成占位符 <YOUR_API_KEY> 的形式提交，.env 本身在仓库里是被 gitignore 掉的。

最后说回这一课的读法。它的价值不在于告诉你用哪个工具，而在于逼你回答三个问题：我的假设在探索阶段是怎么被证伪或证实的？进入构建阶段的那道指标闸门，具体是哪几条、谁来判？线上的监控告警盯的是哪几项——是只有 Cost 与 Latency，还是 Quality、Harm、Honesty 也有人在看？前两个问题课程给了位置，第三个问题的答案得你自己往里填，因为这个仓里没有现成代码。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。

本文依据 github.com/microsoft/generative-ai-for-beginners 仓库于 2026-08-18 的公开内容整理，事实来自仓库内的课程正文与代码示例。我们没有跑过文中涉及的代码，因此不涉及运行结果、耗时与生成质量的任何描述。该课程持续更新，文中涉及的文件路径、依赖与接口写法随版本变动，请以仓库最新内容为准。文中涉及的云端服务调用会产生费用并可能上传数据，请自行评估密钥与数据边界。