Day7：从大模型 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。

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

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

延伸思考（自选）

• RAG：长上下文贵，检索把「该看的几段」喂给模型，是另一种降本增效。
• ️ Chunk：文档切开时如何避免半句话、半截表格，直接影响抽取质量。
• ️ 算力：本地 GPU 推理与云端 API 如何组合，取决于延迟、成本与数据出境要求。