上周坐高铁回杭州，信号断断续续。我原本想在路上改一篇稿子，结果打开常看的几个 AI 网页，转圈的时间比写字还长。最后是笔记本电脑上一个本地模型帮我把段落理顺的——不快，但一直在。
这件事让我重新想了一个平时不太会问的问题：我选 AI 产品的时候，几乎只看"它强不强"，很少问"它跑在哪"。
而过去两年真正让我放弃一个工具的原因，往往不是能力不够，而是位置不对。把敏感材料贴进云端对话框，心里不踏实；把一次性的文案任务塞进工程平台，流程重得离谱；把需要读仓库的改动交给网页聊天框，只能靠手贴代码。能力是同一层的东西，位置决定了它能不能进入你的日常。
这篇文章聊三个产品：Ollama、Cherry Studio、CodeArts。它们分别代表三种运行位置——自己的机器、桌面入口、工程环境。不是榜单，也不谈价格和版本，产品能力请以官方说明和自己的试用为准；我只说我在什么任务上用它们，以及哪些事不会交给它们。
一、先把"运行位置"想清楚
我大致把 AI 的运行位置分成三类，每一类都对应不同的约束。
第一类，本地。 模型和推理都在自己的机器上。好处是数据不出门、断网可用、没有调用次数焦虑；代价是硬件决定上限，模型质量通常不如云端旗舰，更新与维护要自己管。
第二类，桌面入口。 客户端装在自己电脑上，模型调用走云端 API。好处是一个窗口里能切换多家模型、统一管理密钥和资料；代价是它本身不生产能力，背后接什么模型就是什么水平。
第三类，工程环境。 AI 直接进入代码仓库、构建系统和测试流程。好处是上下文不用人手搬，改动可以看 diff、可以跑测试；代价是接入成本高，工程规范越差，效果越差。
同一个任务，放在不同位置，体验完全不同。所以我现在选工具的顺序是：先画边界，再选产品。
二、Ollama：把模型变成一台本地服务
Ollama 是我留在电脑上最久的一个本地工具。它的核心很简单：用命令行拉取并运行开源模型，在本机暴露一个接口，其他程序可以把它当成模型后端。
我主要用它做四类事：
一是不能出内网的文本。比如还没脱敏的会议记录、内部故障复盘、带客户信息的草稿。这类材料我不会贴进任何云端对话框，本地模型哪怕总结得粗糙一点，也先在自己的机器上过一遍。
二是离线场景。高铁、飞机、断网酒店，本地模型至少能帮我列提纲、改语病、把散乱的要点归并成段落。
三是批量的小任务。给几十条日志做初步分类、把一批标题改成统一语气、从长文里抽关键词。这些任务对推理要求不高，但对"随便跑多少次都不心疼"要求很高。
四是给别的本地工具提供模型。桌面客户端里可以同时接云端 API 和本地 Ollama，敏感内容走本地，普通内容走云端，这个组合比二选一更实用。
但它的边界也很清楚。
硬件就是上限。 显存和内存不够时，只能跑更小的模型或量化版本，输出质量和云端大模型有肉眼可见的差距。长上下文、复杂推理、多轮工具调用，这些恰恰是本地小模型最容易露怯的地方。
维护成本是自己的。 模型文件占磁盘，端口、更新、不同客户端之间的兼容，都要自己处理。它不像网页产品那样打开就能用。
它不懂你的工程。 本地模型看不到你的仓库结构、构建配置和测试结果。你可以把代码贴给它，但那又回到了人工搬运上下文的老问题。
所以我的判断是：Ollama 适合"数据不能出门"和"离线也要干活"，不适合"我要最强的推理"。把它当成一台随时可用的小型模型服务，而不是云端旗舰的替代品，预期就对了。
三、Cherry Studio：把多个模型收进一个桌面入口
如果说 Ollama 解决的是"模型在哪跑"，Cherry Studio 解决的是"我在哪跟模型说话"。
它是一个桌面客户端，可以接入多家模型服务商的 API，也能接本地模型。对话、助手、知识库这些围绕使用场景的功能被放在同一个界面里。对我来说，它最大的价值不是某个功能，而是减少了切换。
以前我的浏览器里长期挂着四五个 AI 网页，每个标签页对应一家模型。写东西时想让两个模型各写一版，得复制粘贴两遍；查资料时想把同一份文档喂给不同模型，又得重新上传。桌面客户端把这件事收拢了：同一段对话可以换模型重跑，同一份资料可以留在本地知识库里反复用。
它适合的场景很具体：
需要多模型对比的时候。同一个问题，让两家模型各答一遍，差异往往比单看一家的答案更有信息量。
需要个人知识库的时候。把常用的规范、笔记、产品资料放进去，提问时先检索再回答，比每次手动贴背景省事。
需要统一管理密钥和配置的时候。多个服务商的 Key、模型名、参数集中在一个地方，换电脑时不用重新找回每个网页的设置。
但它终究是一个"壳"。
能力来自背后的模型。 客户端不会让一个弱模型变强，也不会替你判断哪家模型更适合当前任务。模型选错了，界面再顺手也白搭。
初次配置有门槛。 服务商、API Key、模型名称、代理设置，这些都要自己填。对不熟悉的人来说，第一步就可能卡住。
知识库不是"上传就懂"。 文档怎么切分、检索命中多少、回答引用哪一段，都会影响结果。资料脏、结构乱，检索出来的内容也不会干净。
它更适合个人，不太适合团队。 权限、审计、共享、协作这些事，不是个人桌面客户端的强项。
我的用法是把它当成"个人 AI 工作台的入口"：敏感的走本地模型，需要质量的走云端，资料留在自己的知识库里。它是入口，不是能力本身。
四、CodeArts：把 AI 放进工程环境
前两个产品解决的是"个人怎么用模型"，CodeArts 解决的是另一类问题：当任务本身长在工程里，AI 应该站在工程里，而不是站在聊天框里。
CodeArts 是华为云的一站式软件开发平台，覆盖需求、代码、构建、测试、部署这条链路。它的 AI 能力不是独立的一个聊天窗口，而是放在仓库、构建和测试的上下文里工作。这个位置差异，决定了它能做和不能做的事。
它适合的任务，通常有三个特征：
改动需要理解仓库。 不是"写一个函数"，而是"在这个项目里，按现有分层改一个接口，并补上对应测试"。这种任务靠手贴几个文件很难说清楚，AI 需要看到目录结构、依赖关系和已有写法。
结果需要被验证。 改完能看 diff，能跑构建，能执行测试。对工程任务来说，"看起来对"远远不够，能不能通过流水线才是标准。
流程需要连起来。 从需求到代码、从提交到构建、从测试到部署，中间少一次人工搬运，就少一次上下文丢失。
它的局限也同样明显。
接入有成本。 工程要接进平台，权限、流水线、规范都要配。对一个人的小项目，这套东西可能比任务本身还重。
对一次性任务过重。 让我写一段文案、解释一个概念，打开工程平台是完全不划算的。位置对了，工具才轻。
依赖网络和账号体系。 它是云端平台，离线场景不适用。
生成不等于正确。 越能自动改代码，越需要人看 diff、跑测试。这一点和所有编码 Agent 一样，没有例外。
所以我对 CodeArts 的判断是：它不是"更强的聊天机器人"，而是"把 AI 放进工程流程的一种方式"。任务长在工程里，它才有优势；任务不在工程里，别硬塞。
五、按任务选位置
把三个产品放在一张表里，我的选择大概是这样：
| 任务 | 我选的位置 | 原因 |
|---|---|---|
| 未脱敏的会议记录、内部复盘 | 本地（Ollama） | 数据不出机器 |
| 多模型对比、个人资料问答 | 桌面入口（Cherry Studio） | 统一入口，减少切换 |
| 仓库内改动、构建与测试 | 工程环境（CodeArts） | 需要工程上下文与验证 |
| 一次性文案、概念解释 | 云端网页 | 最快，不值得上流程 |
这张表不是标准答案，只是一个提醒：同一个模型，放在不同位置，适合的任务完全不同。
六、三个容易踩的坑
第一个坑，把"能跑"当成"好用"。 本地模型第一次跑起来很兴奋，但真正的标准是"我每天会不会打开它"。如果一周只用一次，它带来的维护成本可能大于收益。
第二个坑，用工具数量代替产出。 装十个工具，不如把一个工具接进固定流程。工具越多，切换成本越高，最后往往回到最顺手的那一个。
第三个坑，忽略验收。 越自动化的工具，越容易让人跳过检查。本地模型会一本正经地编，工程 Agent 会自信地改错文件。位置选对了，验收这一步也不能省。
写在最后
我现在选 AI 产品，会先问三个问题：它在哪跑？它能拿到什么上下文？它的结果我怎么验证？
这三个问题，比"它是不是最强"更能决定一个工具能不能留下来。Ollama 让我在断网时也能工作，Cherry Studio 让我不用在五个网页之间来回切换，CodeArts 让 AI 站进了工程流程本身。它们不是互相替代的关系，而是三种位置各自解决了不同的问题。
不是所有 AI 都要上云。先想清楚边界，再决定把哪一个放进来。
评论