Pipeline：把多步骤串成可靠流水线
新手喜欢写一个"什么都让它一次干完"的巨型 prompt——又难调又不稳。专业做法是 pipeline（流水线）：把复杂任务拆成几个清晰步骤，一步接一步，每步只干一件事。这是产品稳定的关键架构。
回到我们的练习项目："翻译"看似一步，其实是好几步：先判断这是什么语言 → 再翻译 → 然后检查译文质量（有没有漏译、术语对不对）→ 最后整理成统一格式输出。如果硬塞进一个 prompt 让它一口气全做，它会顾此失彼；拆成流水线，每步都稳、都可单独优化。
什么是 pipeline
Pipeline 就是把一个大任务拆成有先后顺序的若干步骤，前一步的输出，是后一步的输入。像工厂流水线：每个工位只负责一道工序，做完传给下一个工位。每个工位可以用不同的模型、不同的 prompt。
| 巨型单 prompt | Pipeline 多步骤 | |
|---|---|---|
| 稳定性 | 步骤越多越容易乱、漏 | 每步单一职责，更稳 |
| 调试 | 错了不知道错在哪 | 能定位是哪一步出问题 |
| 优化 | 动一处怕影响全局 | 可单独优化某一步 |
| 成本 | 简单步骤也用贵模型 | 每步配"刚好够用"的模型（第 3 讲） |
翻译应用的 pipeline 示例
- 步骤①·语言识别（快省档模型）：判断输入是什么语言，输出语言代码。
- 步骤②·翻译（均衡/旗舰档 + 产品级 prompt）：基于①的结果翻译，输出译文。
- 步骤③·质量自检（均衡档）：检查②的译文有没有漏译、术语错误，给出问题清单或修订。
- 步骤④·格式化（程序处理，不一定要模型）：组装成统一的 JSON 结果返回。
每一步的输出，结构化地喂给下一步。这就是为什么第 4 讲强调"固定输出格式"——格式固定，步骤之间才能可靠地对接。
设计 pipeline 的两个原则
① 单一职责：每一步只干一件清楚的事，别贪多。② 接口清晰：每一步输入输出的格式定死，像水管接口一样严丝合缝。做到这两点，整条线就既稳又好改。
容错：流水线必须考虑"某一步出问题"
真实运行中，某步可能失败（模型超时、返回格式不对）。产品级 pipeline 要有：重试（失败自动再试一次）、兜底（某步实在不行时给个安全的默认结果）、记录（出错时留下日志，方便排查）。这呼应第三部分的"容错+通知"思想，只是这里发生在产品内部。
跟我做一遍：把翻译做成一条 pipeline
第一步 · 先设计流水线（不写代码）
复制
帮我把"翻译"设计成一条 pipeline：拆成 语言识别→翻译→质量自检→格式化 四步。
给我每一步的：职责、用哪档模型、输入格式、输出格式（用 JSON）、失败时怎么兜底。
先出设计，我确认后再实现。
第二步 · 实现并逐步验证
一步步搭、一步步测
按设计实现这条 pipeline，但先逐步验证：
先单独测语言识别这一步是否准；再接上翻译；再接上质量自检。
每接一步就给我跑几个例子看效果，确认稳了再接下一步。
第三步 · 加容错，跑通整条线
让它能扛住出错
整条线打通后，加上容错：每步失败自动重试一次，
某步返回格式不对就记录并走兜底，最后无论如何都返回一个结构合法的结果。
用 10 个不同输入跑一遍，给我每步的中间结果和最终输出。
✓ 你刚刚学会的
把"一个巨型 prompt"拆成"职责单一、接口清晰、各配模型、带容错"的流水线。这是 AI 产品从"玩具"到"能用"的分水岭——稳、可调试、可优化、还省钱。
这一讲记住什么
- Pipeline = 把大任务拆成有序步骤，前一步输出=后一步输入。
- 比巨型 prompt 更稳、更好调试、可单独优化、更省。
- 两原则：单一职责 + 接口清晰（格式固定）。
- 产品级要有重试、兜底、记录。