大模型API实战：四个渐进式场景从入门到落地

Day7：从大模型 API 到“能干活”——四个渐进式实战场景

日期：2026-03-23

坦白说，很多教程止步于“调通一次对话”。等你真正开始做产品时，会接连撞上几个坎：输出必须可控、要对接自家数据接口、要能读懂图片或表格、还得能执行多步推理。下面这四个场景，恰好串起一条从“只会聊天”到“像个Agent一样先思考、再查询、再回答”的能力进阶路线。

---

Case 1：舆情极性——用 System Prompt 把输出“关进”窄门

场景很简单：用户扔来一句商品评价，你需要的不是一篇小作文，而是一个可统计、可对接报表的结论。

怎么做？在系统提示里把事情说清楚就行——你是舆情分析师，只能回答“正向”或“负向”这两个词。用户消息里只放原文，模型在受限的输出空间里完成二分类任务。

这里能学到重要的一课：大模型不必每次都“畅所欲言”。压缩输出空间，是成本最低的控制手段。无论是标签分类、是否违规判定，还是严重程度定档，都可以先靠 Prompt 立规矩，再谈微调或结构化输出。

这套思路可以迁移到：评论审核初筛、工单分类、简单意图识别。本质上都是同一个逻辑——先框定边界，再让模型填空。

---

Case 2：查天气——Function Call 让模型懂得“开口要数据”

用户问“北京天气怎么样”，模型不能瞎编，它得调用你提供的函数。这里用本地模拟数据代替真实气象API来演示。

具体做法是：在请求里注册一个“获取当前天气”的函数描述，包括名称、参数和说明。当模型判断需要查天气时，它会返回一个 function_call，包含函数名和对应的 JSON 参数。你在代码里真正执行这个函数，再把结果以 function 角色写回对话历史，最后让模型基于真实数据生成最终的自然语言回复（比如只要“晴天/阴天”等一个词）。

核心分界线在于：模型负责决策“要不要调、调哪个、传什么参”，你的服务负责执行与鉴权。这正是后来 Agent 体系、插件体系里最根本的分工模式。

这套能力可以迁移到：查订单、查库存、查知识库元数据——凡是“结构化入参 + 可重复执行”的接口，都可以被描述成函数，交模型来调度。

---

Case 3：表格图片变 JSON——多模态“看图说话”落到结构化

日常工作中经常遇到这种情况：一张纸质或截图形式的表格，需要变成 JSON 交给系统用，而不是要一段描述文字。

这时候的做法是：走视觉语言模型链路。在消息里同时传图片（本地路径或URL，视平台要求而定）和文本指令，比如“提取表格内容并输出 JSON”。模型直接对图像做理解，然后按你设定的格式约束组织结果。

这条路径告诉我们：文本API解决不了的问题，得换多模态API。工程上需要留意图片大小、格式、合规和成本问题；提示词里尽量明确字段名、层级、缺省规则，这能显著减少胡编乱造和格式漂移。

可以迁移到：票据识别、质检单录入、报表截图结构化、移动端随手拍入库。一句话：凡是“看图出数”的场景，这套方案都值得一试。

---

Case 4：运维告警 + Tools——更接近“先调用、再总结”的 Agent 形态

用户输入一条告警描述，比如“数据库连接数超阈值”。你希望模型先拉一眼监控指标，再结合告警文案做分析，而不是凭空推断。

做法是：使用平台支持的 Tools 协议，声明可调工具，比如“获取当前数据库服务器状态”。当模型返回 tool_calls 时，你在本地执行对应的 Python 函数，把 JSON 结果作为 tool 角色消息写回对话，同时带上与调用匹配的 tool_call_id，然后发第二轮请求，让模型基于真实指标组织回答。

这里要把握两个关键点：

• 第一，Tools 协议往往面向“多工具、可扩展”的对话式编排。和早期 Function 那种单函数调用相比，协议细节不同，但核心心智模型是一致的：模型提议 → 你执行 → 你回填 → 模型收尾。
• 第二，有一个常见坑：必须先追加“带 tool_calls 的 assistant 消息”，再追加 tool 结果，否则服务端会拒绝上下文。原因是“工具回复”在语义上必须回应上一轮“我要调工具”的那条助手消息，顺序一旦错了，上下文就不成立。

这套思路可以迁移到：智能运维助手、内部客服（查工单、查配置）、任何“先查系统再回答”的 Copilot 场景。

---

小结：四个场景串成一条能力线

台阶	关键词
Case 1	输出约束、分类与标签
Case 2	Function Call、本地执行、回填再生成
Case 3	多模态、图像 → 结构化
Case 4	Tools、多轮上下文、监控类“真数据”

如果你也是从业务开发转向 AI 应用，建议按这个顺序来练习：先控输出，再接函数，再上图，最后玩多轮工具。每一步踩过的报错，都是在补“协议与状态机”这一课。

---

延伸思考（供参考）

• RAG：长上下文成本高，检索把“该看的几段”喂给模型，是另一种降本增效的思路。
• Chunk：文档切分时如何避免半句话、半截表格，直接决定抽取质量的高低。
• 算力：本地 GPU 推理与云端 API 如何搭配，取决于你的延迟要求、成本预算和数据出境规定。