两小时 LLM 系统课，值得留下的只有 19 分钟

这门课最有价值的一课只有 19 分钟。课程落地页标注的总时长为 1 小时 55 分钟，只要求基础 Python。

Building Systems with the ChatGPT API 是 DeepLearning.AI 的一门短课，由 OpenAI 技术团队成员（Member of Technical Staff）Isa Fulford 和 Andrew Ng 讲授。课程面向初学者，包含 11 个视频、9 个代码示例和一次计分测验，最近一次更新是 2025 年 10 月 14 日。

如果你已经工作了几年，这些代码不会难倒你。值得学的原因在于，它提供了一种思考 LLM 系统的方式，前线部署工程师（FDE）到了客户现场可以直接用上。花一个晚上看完，记住下面三个思路，但别把它当成通往生产环境的门票。

拆开，才知道系统错在哪里

第一个思路也是课程承诺要教的内容：通过串联模型调用来自动化复杂工作流，把一个大任务拆成一串子任务。

19 分钟的 Chaining Prompts 一课讲的正是这项技术。Anthropic 在 Building effective agents 中描述了同样的设计模式：每次 LLM 调用都处理上一次调用的输出。

设想一家物流公司想自动回复投诉邮件。一个巨型提示词也能全部搞定，但一旦出错，你分不清是读错了订单号，还是用错了政策。把工作拆成四步（分类、提取订单号、查询信息、起草回复），每一步就都能度量。

度量之所以重要，是因为错误会迅速累积。假设每一步准确率为 95%，错误相互独立，且任何一步出错都会毁掉整封邮件，那么整条链的正确率只有 0.95⁴，约 81%。1,000 封邮件里，大约有 185 封会出问题，尽管单看每一步都还不错。

什么时候不该用提示链？

课程教的是技术本身，但在现场，更难的问题是到底该不该用。Anthropic 把条件说得相当清楚：当任务能干净地拆分为固定子任务时，这种模式最合适。客户的工作很少这么规整。

回到那家物流公司。如果延迟送达的投诉总是走上面四步，一条固定链就够了。但如果一封邮件既要求退款、又询问合同，还附上了货物破损的照片，步骤顺序就得因事而变，僵硬的链条开始失效。

动手之前，拿 20 封真实邮件，手工写出每封需要的步骤。如果这些清单几乎一致，就放心用提示链。

如果每封邮件都不一样，就不要硬塞进同一条链。把分类步骤放在最前面，再分出几条短链，每条负责一组固定任务，比如延迟送达、退款或合同。包含多个诉求的邮件，先拆成单独的诉求，再分别送进各自的分支。

任何分支都对不上的，应当交给人工处理并记录下来，而不是让模型去猜。假设 20 封邮件中有 15 封能匹配三个分支：你可以自动化 75%，每个分支仍能单独度量，剩下的 5 封邮件则告诉你下一步该加哪个分支。在承诺时间表之前，先把这个数字告诉客户。

输入输出都要管控，但别照搬细节

第二个思路体现在课程结构里：Moderation 和 Check Outputs 是两节独立的课。对工程师来说，值得记住的是：管控必须是系统中的一个步骤，输入和输出两端都要有，而不是夹在提示词里的一句提醒。

Moderation 一课的技术细节已经过时，所以要取其思路，不要照搬做法。写代码之前，先读 OpenAI 当前的内容审核文档：该端点免费，omni-moderation-latest 模型同时接受文本和图片，图片文件最大 20 MB。

如果客户的工作流包含图片，比如上例中货物破损的照片，设计审核步骤时就必须把图片考虑进去。

内容审核也替代不了业务检查，因为它对客户的退款政策一无所知。第一次工作会议上，问两个问题：哪些数据可以发送到外部 API？哪种错误回答造成的损失最大？第二个问题的答案，实际上就是输出检查的需求说明。

评测：课程在这里收得太早

第三个思路是，评测必须作为一项独立的工作来对待。课程为 Evaluation 安排了三节课，这个信号是对的。但这部分止步于短课程的固定测试集，没有触及系统在客户处部署后的真实输出。

Hamel Husain 在 Your AI Product Needs Evals 中推荐了另外两种做法。第一种可以马上开始：按他的说法，LLM 的单元测试就是你在 pytest 里早已在写的那种断言，运行起来又快又便宜。

对邮件系统来说，断言可以是：回复中出现的任何订单号，都必须存在于查询到的数据中；只有邮件被正确归入退款类别时，才能提及退款。

第二种更难，因为它是需要坚持的习惯，而不是写一次就完事的代码。Husain 写道，永远不要停止查看数据，没有捷径。在客户现场，部署后的头几周，每周安排时间阅读真实输出；每发现一种新错误，就把它变成一条新断言。

学习顺序与可略过的部分

这门课是 ChatGPT Prompt Engineering for Developers 的后续，但前一门课并非必修。如果你给真实产品写过提示词，可以直接开始；如果从没调用过 LLM API，先学前一门课会让这门课更轻松。

这门课最适合准备转做 FDE 的工程师。开始学之后，按下表进行：先串联步骤，再在输入输出两端拦截错误，最后做评测。

有了步骤链，才知道拦截点放在哪里；有了完整的系统，才有东西可评测。如果你已经在运行 LLM 系统，其余部分可以跳过，只看 Evaluation 部分。

顺序	课程部分	学习方式	在客户现场的用途
1	Chaining Prompts	精读，亲手运行代码	把工作流梳理成可度量的步骤
2	Moderation	取其思路，阅读最新文档	搭建输入审核步骤
3	Check Outputs	精读	编写拦截代价最高错误的规则
4	Evaluation（三节）	精读，补充断言	用真实数据构建测试集
5	Chain of Thought Reasoning	略读	某一步需要先推理再作答时尝试使用

写简历时，别只写课程名称。用公开数据做一个小项目，写清楚你把工作流拆成了几步、每一步准确率多少、哪条断言拦住了哪种错误。

阅读 FDE 岗位描述时，留意两个词：“evals”和“production”。如果招聘信息提到了它们，这个小项目就是面试时该拿出来讲的例子。

这门课教你把步骤串起来。而 FDE 的工作，从这条步骤链没有预料到的第一封邮件开始。