应用开发 — 从模型到产品
这一章讲三件事: 典型场景的全景(挑代表讲透,不铺清单);两个开发案例的完整实现路径;本地部署的最小可行方案。 一句话定位: 模型能力在前面十二章,这一章讲「拿去用」——用在哪、怎么开发、不联网行不行。
1. 九类场景:能力与约束怎么咬合
书里铺了九类场景,这里不抄清单,挑四个能说明 「咬合关系」的讲透,其余在原文地图里给坐标。
客服机器人:这是最成熟、要求也最苛刻的场景。难点不在聊天,在术语准确——保险场景里用户问「重疾险在国外就医能理赔吗?质子重离子治疗报销吗?」,模型要依据条款细则和过往理赔案例回答,错一个字就是纠纷1。这个场景的真实架构几乎必然是第 11 章的 RAG(条款库做检索底座),裸调模型没人敢上线。
虚拟助手:老一代助手(Siri、Alexa)是任务导向的对话系统,只会预定义动作;接上大模型后能处理隐喻和口语化表述——发图时图片会先转成 base64(用文字表示二进制数据的编码)再随请求发出。书里的例子是荣耀 YOYO:先问「附近有哪些川菜馆」再问「哪家评价最高」,它能关联上下文,甚至直接代打电话预订2。技术上吃的正是第 10 章的两样东西:多轮前文记忆 + 调外部程序。
代码辅助:GitHub Copilot 按上下文补全代码;Cursor 更进一步,「约 25% 的情况下可精准预判」开发者接下来要敲什么,按 Tab 直接补全;调试侧有 DeepCode 这类扫代码库找安全漏洞的工具3。
法律合规:LawGeex 做合同自动审查,识别遗漏、错误、歧义与风险条款,书里给的账是节省高达 90% 的审查成本;Casetext 面向法律检索与案情分析4。与客服同理,法律场景的可信度靠「检索到的条款」背书,而非模型自由发挥。
其余五类(内容创作的 Sudowrite、翻译场景的 Deep Research 与 Booking.com 多语客服、信息抽取的 BloombergGPT、搜索推荐的 Kimi 搜索与 SearchGPT、教育的 Khanmigo 与讯飞学习机、企业管理的 Otter.AI 会议摘要)结构相似:一个通用模型 + 一个领域知识源 + 一个交互壳。看懂四个,等于看懂九个。
2. 开发案例一:FisherAI 浏览器插件
痛点很日常:网页太长想摘要、外文看不懂想翻译、视频没字幕想理解。FisherAI 是一个开源 Chrome 插件,把摘要、网页翻译、视频翻译、多轮对话装进浏览器;模型可配(ChatGPT、Gemini、DeepSeek、Qwen、Mistral 等,也能通过 Ollama 走本地模型)5。
主走查:划词翻译的六步实现
选中一段外文 → 弹出译文,中间发生了什么?核心逻辑是两段事件监听6:
① 监听 mouseup 事件:用户松开鼠标时,
调 window.getSelection() 检查是否有选中文本
② 有选中 → getClientRects() 拿到选区的屏幕位置,
把「翻译」小按钮定位到选区旁,显示出来
③ 没选中 → 按钮和弹窗一并隐藏(防止残留)
④ 用户点击按钮:从 chrome.storage 同步读取模型配置
(选了哪个模型、API 地址、密钥)
⑤ 调 chatWithLLM(模型, 翻译提示词 + 选中文本)
—— 这一步就是把「把下面内容翻译成中文」的提示词
拼上用户选的文字,发给大模型接口
⑥ 译文渲染进页面上的悬浮弹窗(translationPopup)
图说:六步全部来自书里的代码讲解(content.js 与 llm.js)。
机制上没有任何新东西:事件监听 + 拼提示词 + 调 API + 渲染。
这个案例的开发学价值在于它的小:没有向量库、没有微调、没有智能体循环,一个「事件 → 提示词 → 接口 → 渲染」的最小闭环,就是绝大多数大模型应用的骨架。
3. 开发案例二:PaSa 论文搜索助理
第二个案例难度陡增:文献检索是专业活,「基于 UCB 算法的非平稳强化学习中价值导向研究」这类查询,通用搜索引擎难以完整覆盖;研究者要的不只是找论文,还要判断相关性、顺藤摸瓜追引文。
PaSa(字节开源)用两个智能体协作解这个问题7:
- 爬取器(Crawler):接到检索请求后,自主决定调用搜索工具还是从已读论文里追引文,动态扩充待读文献库,循环往复直到建起一个够大的候选池;
- 选择器(Selector):逐篇阅读候选,判断是否真的符合用户查询,决定「选择/放弃」。
训练方式也值得记:用包含 35000 个精细学术查询的合成(人工造出来而非真实采集的)数据集 AutoScholarQuery 做强化学习优化(AGILE 框架),再用真实查询基准 RealScholarQuery 验证——主要靠合成数据(人工造出来、非真实采集的数据)训练,却在真实基准上显著优于 Google、Google Scholar、GPT-4 改写查询的 Google、带搜索的 ChatGPT 和 GPT-o18。检索与筛选的分工、用 RL 优化多步决策、合成数据练真实仗——这三招是「智能体做搜索」的标准配方。
4. 本地部署:不联网的三层方案
数据不出门、离线可用、成本可控——本地部署的三层架构是:模型库 → llama.cpp(推理引擎)→ Open WebUI(对话界面)9。
第一层:llama.cpp。 纯 C/C++ 实现的推理项目,吃遍硬件:Apple Silicon(ARM NEON/Metal)、x86(AVX/AVX2/AVX512/AMX)、NVIDIA(CUDA)与 AMD(HIP);量化从 1.5-bit 到 8-bit 任选,还支持 CPU 与 GPU(加速卡)混合推理——显存不够也能跑,只是慢。模型要转成它的 GGUF 格式(HuggingFace 上有在线转换工具)10。
命令行工具按用途分:llama-cli(对话/补全/按语法(措辞的格式规则)约束的输出)、llama-server(起一个 OpenAI API 兼容的本地服务,支 持多用户并行与推测解码)、llama-perplexity(测困惑度)、llama-bench(测吞吐,书里给的样例是 Qwen2-1.5B 量化版在 Metal 后端上预填充约 5765 词元/秒、逐词元生成约 198 词元/秒)11。
其中「语法约束」值得单说:用一份语法(措辞的格式规则)规则文件,规定「什么样的字符串(一串文字)算合法输出」,强制模型照办。
最常用的格式是 JSON(系统间传数据的「键:值」成对文本格式)——输出能被下游程序直接读,靠的就是它。
第二层:Ollama。 把 llama.cpp 包成傻瓜式工具:macOS/Windows/Linux 装完就能 ollama run llama3.2;想当后端服务用就 ollama serve,自带 REST API(默认端口 11434,/api/generate 与 /api/chat 两个端点);模型管理(pull/rm/cp)一行命令,还支持多模态模型(llava 直接吃图片路径)12。
第三层:Open WebUI。 给不肯用命令行的人一个类 ChatGPT 界面:自托管、完全离线运行,支持 Ollama 和一切 OpenAI 兼容 API,内置 RAG 推理引擎;Docker 一条命令起服务(3000 端口映射),管理员界面里管理本地模型13。
三层的分工可以这么记:llama.cpp 管「怎么算」,Ollama 管「怎么跑得省心」,Open WebUI 管「怎么给人用」。
5. 作者的判断与证据
- 有证据的: Cursor 的 25% 预判率、LawGeex 的 90% 成本节省、PaSa 对五个基线的胜出、llama-bench 的实测吞吐,均有出处(部分为产品方自报数字,如 LawGeex 与 Cursor)。
- 作者的判断: 「构建系统化的开发流程与方法尤为重要」是作者的立场;场景九分法是整理框架,行业里分类口径不一。
- 书里的坦白: FisherAI 的模型配置需要用户自备 API 密钥——书没有回避「模型即服务」的成本问题。
6. 边界与局限
- 场景部分全是 2025 年初之前的产品快照,产品名迭代快,机制(检索+提示词+壳)不过时。
- 开发案例只有前端插件与智能体两个;后端服务化(鉴权、限流、计费)完全没有覆盖。
- 本地部署一节没给硬件选型的量化建议(多大模型需要多少内存),需要结合第 12 章的量化知识自行估算。
- 安全与合规(企业数据出境、生成内容的审核责任)只有一句「面临诸多挑战」,没有展开。
7. 可带走的
- 九类场景一个骨架:通用模型 + 领域知识源 + 交互壳;评估任何「大模型产品」先拆出这三件;
- 高风险场景(保险、法律)的模型必须配检索底座——答案要能指回条 款原文,不能靠参数记忆;
- 最小可行应用 = 事件监听 → 拼提示词 → 调 API → 渲染结果,六步的划词翻译就是模板;
- 智能体做检索的标准配方:爬取/筛选分权、RL 优化多步决策、合成数据训练真实任务验证;
- 本地部署三层:llama.cpp(算)、Ollama(跑)、Open WebUI(给人用),每层都可独立替换;
- GGUF + 量化是本地跑模型的门票:1.5-bit 到 8-bit 任选,显存不够 CPU 顶上(慢但能跑);
ollama serve+ REST API(11434 端口)是把本地模型当后端用的最快路径;- 买产品看「模型能力」之外,更要看场景约束:术语准确性、上下文长度、隐私边界——约束决定架构,模型只是零件。
8. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 内容创作与初稿 | 12 应用开发 | text/12-ch12.txt:202(搜「初稿」) · text/12-ch12.txt:208(搜「Sudowrite」) |
| 保险客服例 | 12 应用开发 | text/12-ch12.txt:229(搜「重疾险」) |
| YOYO 上下文 | 12 应用开发 | text/12-ch12.txt:239(搜「川菜馆」) |
| Replika 情感陪伴 | 12 应用开发 | text/12-ch12.txt:244(搜「Replika」) |
| Deep Research | 12 应用开发 | text/12-ch12.txt:272(搜「Deep Research」) |
| Booking 多语客服 | 12 应用开发 | text/12-ch12.txt:277(搜「Booking.com」) |
| BloombergGPT 抽取 | 12 应用开发 | text/12-ch12.txt:293(搜「BloombergGPT」) |
| Copilot 与 Cursor | 12 应用开发 | text/12-ch12.txt:312(搜「GitHub Copilot」) · text/12-ch12.txt:321(搜「25% 的情况下」) |
| 调试工具 | 12 应用开发 | text/12-ch12.txt:325(搜「DeepCode」) |
| 搜索增强 | 12 应用开发 | text/12-ch12.txt:345(搜「SearchGPT」) |
| 个性化推荐 | 12 应用开发 | text/12-ch12.txt:354(搜「Spotify」) |
| 教育场景 | 12 应用开发 | text/12-ch12.txt:372(搜「Khanmigo」) |
| 企业管理 | 12 应用开发 | text/12-ch12.txt:400(搜「Quick BI」) · text/12-ch12.txt:410(搜「Otter.AI」) |
| 法律审查 | 12 应用开发 | text/12-ch12.txt:424(搜「Kira Systems」) · text/12-ch12.txt:444(搜「90% 的审查成本」) |
| FisherAI 定位 | 12 应用开发 | text/12-ch12.txt:467(搜「FisherAI」) |
| 划词翻译实现 | 12 应用开发 | text/12-ch12.txt:487(搜「mouseup」) · text/12-ch12.txt:541(搜「chatWithLLM」) |
| PaSa 动机与结果 | 12 应用开发 | text/12-ch12.txt:573(搜「AutoScholarQuery」) · text/12-ch12.txt:575(搜「RealScholarQuery」) |
| Crawler/Selector | 12 应用开发 | text/12-ch12.txt:577(搜「爬取器」) |
| 本地部署三层 | 12 应用开发 | text/12-ch12.txt:619(搜「llama.cpp」) · text/12-ch12.txt:642(搜「Apple Silicon」) |
| GGUF 与混合推理 | 12 应用开发 | text/12-ch12.txt:648(搜「GGUF」) |
| llama.cpp 工具链 | 12 应用开发 | text/12-ch12.txt:666(搜「llama-cli」) · text/12-ch12.txt:711(搜「8080」) · text/12-ch12.txt:750(搜「5.4007」) |
| llama-bench 实测 | 12 应用开发 | text/12-ch12.txt:666(搜「llama-bench」) |
| Ollama 用法 | 12 应用开发 | text/12-ch12.txt:779(搜「ollama run llama3.2」) · text/12-ch12.txt:792(搜「11434」) |
| Open WebUI | 12 应用开发 | text/12-ch12.txt:824(搜「Open WebUI」) |