Day7：从大模型 API 到“能干活”——四个渐进式实战场景 日期：2026-03-23 坦白说，很多大模型教程往往止步于“调通一次对话”。当你真正进入产品开发阶段，会遇到几个绕不开的坎：输出必须可控制、需要对接自有数据接口、要能解析图片或表格、还得具备多步推理能力。下面这四个实战场景，恰好串联起一条从“只会聊天”到“像一个智能体那样先思考、再查询、再回答”的能力进阶路线。 --- ### 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 如何搭配，取决于你的延迟要求、成本预算和数据出境规定。