先看看你手头的家伙，再决定跑什么模型

上个月帮一个做金融数据分析的朋友搭本地大模型。他丢过来一句话，我到现在还记得：“数据出网一次，合规就得写三页说明。” 这话说得真不夸张。医疗、金融、法律这些行业，敏感数据哪怕只经过一次云端API，心里都不踏实。本地部署大模型，说白了就是把AI的“脑子”放在自己口袋里，数据不出门，离线也能跑。而且算一笔长期账：如果团队每天要调几百次API，一个月下来账单比请人喝咖啡还贵。自己用Ollama拉个模型下来，电费加显卡折旧，成本直接砍半。

但光有模型还不够。团队里三个人写Prompt，能写出三种完全不同的风格。A写的指令AI秒懂，B写的总是答非所问，C干脆把Prompt写成小作文。这时候一个统一的Prompt模板库就派上用场了——把写Prompt的套路沉淀下来，新人上手快，老人输出稳，协作效率蹭蹭涨。说白了，模板库搭好了，比换一个好模型还管用。

Selecting open source model for hardware

模型选型：别追大的，追对的

Ollama官网目前列了几十种模型，从400M参数的小模型到几百B的大怪兽都有。怎么选？我自己的经验是：先看你的硬件，再看你的任务。

如果你手头只是普通笔记本，没有独立显卡，或者只有8GB内存，别硬上大模型。Phi-4（微软的轻量级模型）或者Gemma 3（Google出品）就很合适。Phi-4只有14B参数，但推理速度飞快，写个邮件、改个文案完全够用。我试过在MacBook Air上跑Phi-4，对话基本没延迟。

团队有台24GB显存的显卡？那Mistral或者Llama 3.3（70B版本）是多数场景的甜点。它们能处理更复杂的指令，上下文理解也更强。我们团队目前就在用Llama 3.3做日常的代码审查和文档生成，响应质量稳定，偶尔还能给出让人惊喜的建议。

要是专门搞代码或者数学推理，DeepSeek-R1或者CodeLlama更对口。DeepSeek-R1在推理任务上表现突出，做逻辑题、写算法都能hold住。CodeLlama则对代码补全和bug修复有优化。别指望一个模型打天下——按场景选模型，比盲目追求参数大小聪明得多。

Installing Ollama on laptop command line

装、拉、跑三步走，顺便避个坑

装Ollama比想象中简单。去官网（ollama.com）下载对应系统的安装包，Windows点exe，macOS拖dmg，Linux跑一行curl命令。装完打开终端，输ollama --version确认版本号。我写这篇文章时Ollama的最新稳定版是0.5.8，安装过程不到两分钟。

接下来拉模型。比如你想试Phi-4，终端里输：

ollama pull phi-4:latest

等进度条跑完，模型就存本地了。想看看本地有哪些模型？ollama list一下。第一次跑模型记得用ollama run phi-4，它会自动启动交互式对话。你打一句“你好”，它回一句“你好”，就这么简单。这里有个坑：如果拉模型时网络不稳定，可能中途断掉。解决办法是重新跑ollama pull，它会断点续传，不用重头下。

验证模型是否正常工作，我习惯丢一个具体问题，比如“用Python写一个快速排序，并解释每一行代码的作用”。如果回答有条理、代码能跑，说明模型没问题。如果答得乱七八糟，可能是模型版本不对，或者硬件内存不够——Ollama会报错提示。

给Prompt画个框：角色、任务、约束、输出格式

很多人写Prompt像写微信聊天，想到哪说到哪。但模板库不是这么玩的。你得给Prompt画个框：角色、任务、约束、输出格式，这四个字段是标配。

举个例子，我们团队有个“代码审查”模板：

角色：资深Python开发工程师
任务：审查以下代码，找出潜在bug和性能问题
约束：只关注逻辑错误和性能瓶颈，不讨论代码风格
输出格式：用列表列出问题，每个问题附一行修改建议

这样结构化的Prompt，模型输出稳定，不会跑题。模板库怎么组织呢？按用途分类：写作类、编程类、分析类、客服类。再按复杂度打标签：简单（一句话指令）、进阶（带多轮对话上下文）、专家（结合外部数据）。

版本管理这块，我推荐用Git。每个模板建一个Markdown文件，修改时commit，哪天改坏了还能回滚。Ollama的Modelfile也能记录模型配置的变更，但模板本身还是Git顺手。团队里统一用GitHub私有仓库，谁改了模板，PR一发，大家都能看到。

别让模板躺在仓库吃灰：评审、测试、迭代

模板搭好了，没人用等于白干。我们团队摸索出一套流程：一个人提模板草案，写成PR；至少两个人评审，主要看指令是否清晰、输出格式是否合理；评审通过后，拉一个测试分支，跑10个测试用例；测试通过，合并到主分支，通知全员。

效果怎么量化？我们定了三个指标：

  • 响应准确性：模型输出是否命中预期答案（人工打分，0-5分）
  • 相关性：输出有没有跑题（比如问代码审查，模型却开始讲架构设计）
  • 一致性：同一个模板跑三次，结果是否稳定

每周五下午，团队花半小时过一遍本周的模板使用反馈。有人发现某个模板在长文本场景下容易漏信息，就在模板里加了一条“请逐段总结，不要遗漏关键数据”。这种持续迭代，比一次性搞个大而全的模板库有效得多。

把Ollama和自动化工作流串起来

Ollama自带REST API，默认监听localhost:11434。你可以用curl或者Python的requests库直接调。比如把模型集成到Slack机器人里：用户发一条消息，机器人把消息加上模板，POST到API，返回结果贴回频道。我们团队用这个方案处理日常的日志分析，每天省下一个小时。

批量测试是另一个大招。写个Python脚本，循环读取模板库里的所有模板，每个模板跑5次，记录响应时间和输出内容，最后生成对比表格。哪条模板表现好、哪条不稳定，一目了然。我自己的脚本大概40行，跑一次十分钟，比人工测试靠谱一百倍。

性能监控别忽略。Ollama有内置的metrics，可以导出到Prometheus+Grafana。重点关注响应延迟和GPU显存占用。如果某个模型响应越来越慢，可能是并发请求太多，或者模型缓存满了。及时调整，别等到用户抱怨才动手。

本地部署大模型这件事，门槛其实比想象中低。你不需要是AI专家，也不需要配几万块的服务器。一台普通电脑、一个Ollama、一套趁手的模板库，就能让团队的工作流聪明起来。下次开会时，别人还在等云端API响应，你已经拿着本地跑完的结果开始讨论了。那种感觉，试过就知道。