低代码还是写代码：微软生成式 AI 入门课第 10 课的边界断在哪

2026-08-18

接到「把收到的发票自动录进表里」这种需求时，多数人第一反应是先问一句：这活儿要不要写代码。generative-ai-for-beginners 这个课程仓刚好在同一套教材里给了两条完全不同的答案——第 10 课 10-building-low-code-ai-applications/README.md 全程不写一行代码，第 6 课和第 11 课则从 .env 配起、一路写到函数调用的分发逻辑。

这两条路线在课程里不是对立的，但边界确实在某处断掉了。下面这些都是仓库里白纸黑字写的东西，我按「你处在什么处境」来排，而不是按参数表来排。

第 10 课让你实际做的，比宣传语具体得多

第 10 课的介绍段写明 Power Platform 由五个产品组成：Power Apps、Power Automate、Power BI、Power Pages 和 Copilot Studio（README 里注明 Copilot Studio 的前身是 Power Virtual Agents）。这一课只用其中两个做作业。

真正值得看的是第二个作业——发票处理流。README 的步骤是这样走的：在 Power Automate 首页用一句自然语言描述需求（示例给的是 Process an invoice when it arrives in my mailbox），Copilot 生成一个 flow，然后你要动手改它：

把触发器的 Folder 指到发票所在的文件夹（示例用 Inbox），点 Show advanced options 把 Only with Attachments 设成 Yes；
从生成的 flow 里删掉 HTML to text、Compose 以及 Compose 2 到 Compose 4，再删掉 Condition，README 给的理由就是「你用不到它们」；
加一个 Dataverse 的 Add a new row 动作；
把 Extract Information from invoices 这个动作的 Invoice File 接到邮件的 Attachment Content 上；
手工把 ID、Amount、Date、Name、Status、Supplier Email 这几个字段一个个接到上游动作的 dynamic content，其中 Status 固定填 Pending，Supplier Email 取触发器 When a new email arrives 的 From。

我第一次读到这段的时候有点意外：这一课的主题明明是「用自然语言把东西描述出来」，但真正的工作量落在生成之后的删动作和接字段上。这不是低代码的缺点，而是这条路线的真实形状——Copilot 负责给骨架，字段级的接线还是你的。判断一个需求适不适合走低代码，看的就是这部分接线你能不能在可视化界面里说清楚。

换成写代码，同一类事情长什么样

代码路线上最短的一个样本是 06-text-generation-apps/python/aoai-app.py。它做的事情只有一件：加载 .env、构造客户端、发一次请求。

client = OpenAI(
  api_key=os.environ['AZURE_OPENAI_API_KEY'],
  base_url=f"{os.environ['AZURE_OPENAI_ENDPOINT'].rstrip('/')}/openai/v1/",
  )

deployment=os.environ['AZURE_OPENAI_DEPLOYMENT']

response = client.responses.create(model=deployment, input=prompt, store=False)

以上原样取自仓库中该文件，是仓库里的示例代码，不是我们组合出来的写法。

到了第 11 课 11-integrating-with-function-calling/python/aoai-assignment.ipynb，结构就变成三步——notebook 里逐字写的是：带着函数清单和用户消息调一次接口、读模型的响应去执行动作、把函数返回的结果再发一次给模型来组织最终回复。函数清单本身要你自己写 name、description、required；notebook 特别强调 description 要写得具体清楚，因为模型是靠它决定调哪个函数的。取回调用意图的那一行是这样的：

tool_calls = [item for item in response.output if item.type == "function_call"]

notebook 里还写了一句很关键的话：使用 function calling 时，LLM 并不会真的去调用或运行任何函数，它只是按你给的结构返回，由你的应用去决定跑哪个函数。示例里那个函数是 search_courses(role, product, level)。

把这两段和第 10 课的接字段步骤放在一起看，会发现它们其实在做同一件事——都要有人把「模型输出」和「下游动作」对上。区别只在这件事是在可视化界面里点，还是在 Python 里写字典映射。

三条我会用来分路的判断

第一条：你要控制的是结果，还是请求体本身。 第 10 课全程没有出现任何请求参数，AI 能力以「模型」的形态出现在 AI Builder 里，你选它、接输入、拿输出。第 6 课 README 里则明确教你用 max_output_tokens 控制输出长度、用 temperature 控制随机性。如果你的需求描述里出现了「输出要更稳一点」「长度要卡住」，那就已经越过第一条线了。

这里有个 2026 年的坑必须提：06-text-generation-apps/README.md 写明当前 Microsoft Foundry 上未废弃的模型是 reasoning 模型（GPT-5 家族、o 系列），它们不支持 temperature 和 top_p，也不支持 max_tokens（改用 max_output_tokens），往 gpt-5-mini 传 temperature 会拿到「参数不支持」的错误。README 给的替代做法是把采样参数的实验指向仍支持它们的开放模型。所以「我要调 temperature」这个理由本身，在选模型这一层就先被收窄了一次。

第二条：现成模型够不够用。 第 10 课把 AI Builder 的模型明确分成 Prebuilt 和 Custom 两类：Prebuilt 是微软训好、开箱可用的，README 举的例子包括 Invoice Processing、Sentiment Analysis 这类；Custom 允许你把自己的模型带进来用自有数据训练，但 README 紧跟着写了一句「使用自己的模型时存在一些限制」，并链到官方的 limitations 页。这句话的位置很说明问题——能不能用低代码，取决于你的场景是否落在现成模型的覆盖范围内。发票、名片、表单这类结构化抽取落在里面；你自己那套业务语义的判定，仓库没有承诺它落在里面。

第三条：产品边界。 第 10 课写明 Copilot 在全部五个产品里都可用，而 AI Builder 只在 Power Apps 和 Power Automate 里可用。这条是硬边界，选型时先看它。

低代码这一侧还写了什么，以及哪些不比

第 10 课关于 Copilot Studio 的一节列了若干能力：从知识源（公开网站、SharePoint、OneDrive、Dataverse、上传的文件、通过 connector 接入的企业数据）生成有依据的答案；用生成式编排替代固定触发短语来决定组合哪些知识、topic 和动作；动作可以由 Power Platform 预置 connector、Power Automate flow、自定义 REST API、prompt 或 MCP 服务器支撑；可以做由事件触发的自主 agent；agent 之间可以互相调用；可以从 Microsoft Foundry 模型目录挑模型；建好之后可发布到 Teams、Microsoft 365 Copilot、网站或自定义应用等多个渠道。

这些是课程 README 列出来的能力项。我们没有跑过其中任何一条，所以只转述它写了什么，不谈它做得如何。

另外几个维度我明确不比：成本、上手时间、维护难度、团队协作方式——课程仓在这两条路线上都没有给可比的依据，硬比就是编。第 10 课里有 Dataverse 的一段介绍（托管在云上、带数据分类与基于角色的访问控制这类治理能力），代码路线那边则完全没有对应的存储方案，样例只是把结果打印出来，这两者不构成一组可比项。

一个容易照抄错的配置细节

如果你决定走代码路线，00-course-setup/03-providers.md 里有条规则要先看：作业文件名带的 tag 决定它需要哪套凭据，aoai 要 Azure OpenAI 的 endpoint 和 key，oai 要 OpenAI 的 key，hf 要 Hugging Face token。第四个 tag 是 githubmodels，但这个前缀现在名不副实——同一份文档逐字写明它实际需要的是 Microsoft Foundry Models 的 endpoint 和 key，并注明 GitHub Models 于 2026 年 7 月底退役。今天已经过了那个时间点，所以看到 githubmodels- 开头的文件，要配的是 .env 里的 AZURE_INFERENCE_ENDPOINT 和 AZURE_INFERENCE_CREDENTIAL，不是旧的 token 变量。

环境这块 Windows 侧不能照抄 macOS 的行。00-course-setup/02-setup-local.md 给的虚拟环境激活命令分两行：source .venv/bin/activate 标的是 macOS / Linux，.\.venv\Scripts\activate 标的是 Windows PowerShell。创建 .env 也分两套，Unix 侧是 touch .env，Windows 侧文档给的是 echo . > .env。这些都是仓库原文，课程持续更新，以仓库最新内容为准。

收口

我的判断是：当需求能被描述成「从固定形态的输入里抽固定字段、写进一张表、触发一次通知」时，第 10 课那条路线是够的——即便如此你也要准备好做删动作和接字段的收尾。一旦出现「要控制请求参数」「要按模型返回的结构自己决定跑哪个函数」「要在多个 provider 之间切换」这三件事里的任意一件，课程就把你交给了第 6 课和第 11 课。这不是谁更强的问题，是两条路线各自把边界划在了不同的地方。

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

本文对照的是同一项目内的两种用法，依据均为上述仓库内容，不对两种用法做优劣排名，选型结论只在仓库文档写明的能力边界内成立。安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。