1. 断网场景下的工具选型逻辑
1.1 为什么要在断网环境里做工具盘点
断网这件事，平时大家不太当回事，真到了关键时刻——比如出差在高铁上、机房割接断外网、或者单纯想验证一下自己手头的工具链到底有多少是真本事——才会发现很多工具离了网络就是一堆图标。我这次做的测试很朴素：把网线拔了，WiFi关了，手机热点也不开，然后逐个打开六款平时高频使用的工具，看它们还能干什么、不能干什么、报什么错、有没有降级方案。
这个测试的价值不在于猎奇，而在于帮你搞清楚一件事：你的工作流里哪些环节是真正依赖外部服务的，哪些是可以本地闭环的。尤其是这两年AI编程工具井喷，很多人习惯了打开网页就能补全代码、对话就能生成项目，但一旦网络抖动或者服务端限流，整个节奏就断了。搞清楚每款工具的离线能力边界，本质上是在给自己的生产力做冗余设计。
六款工具我按类型分了三组：本地大模型运行器（Ollama）、AI编程辅助工具（Wescode、Trae类）、代码检索与知识管理（CKG、FTS5）、以及一个综合性的本地AI工作台。测试环境是一台16GB内存的笔记本，系统盘512GB SSD，外接一块2TB机械盘放模型文件。断网方式采用物理断网加防火墙双重确认，确保没有任何后台心跳能偷偷连出去。
1.2 测试方法与评判标准
测试方法上我设计了四个维度：启动可用性（能不能打开、要不要登录）、核心功能可用性（主要功能是否还能跑）、降级表现（有没有替代方案或缓存机制）、恢复成本（重新联网后需要多久回到正常状态）。每个维度打分1到5分，最后汇总看整体离线生存能力。
启动可用性这块，重点看有没有强制在线校验。有些工具启动时非要连服务器验证授权，断网直接卡在启动页，这种就是一票否决。核心功能可用性看的是断网后还能不能完成主要任务，比如代码补全、模型推理、全文检索。降级表现看工具有没有本地缓存或者离线模式，比如之前下载过的模型能不能继续用、索引好的数据能不能继续查。恢复成本看重新联网后需不需要重新登录、重新同步、重新下载。
评判标准我尽量客观，但难免带一点个人使用习惯的偏好。比如我平时写代码重度依赖本地模型做代码解释和单元测试生成，所以对Ollama这类工具的离线表现期待值更高。如果你平时主要用云端API做代码生成，那你的权重分配可能跟我不同。这个测试的结论你可以参考，但最终还是要结合自己的实际工作流来判断。
提示：做断网测试前一定要先确认工具在联网状态下已经完成初始化，包括模型下载、索引构建、账号登录。否则你测的不是离线能力，而是首次配置的失败率。
2. Ollama在断网后的真实表现
2.1 模型加载与推理的离线闭环
Ollama是我这次测试里离线表现最稳的一个。原因很简单，它的设计哲学就是本地优先。只要模型文件已经下载到本地，断网后启动ollama serve，然后ollama run qwen2.5:7b，整个推理链路完全不碰外网。我实测下来，断网状态下从发出请求到第一个token返回，延迟跟联网时几乎没有区别，因为本来就没走网络。
这里有个细节值得展开：Ollama的模型文件存储路径默认在~/.ollama/models，Linux下如果你把模型存在系统盘，很容易被占满。我自己的做法是在安装后就修改存储路径到外接盘或者大容量数据盘。具体操作是编辑systemd服务文件或者设置环境变量OLLAMA_MODELS。比如在Linux上：
sudo systemctl edit ollama.service然后在override配置里加上：
[Service] Environment="OLLAMA_MODELS=/data/ollama/models"改完daemon-reload再重启服务。这样模型文件就不会挤占系统盘，断网时也能正常从数据盘加载。Windows下则是设置系统环境变量OLLAMA_MODELS指向非系统盘目录，然后重启Ollama服务。
断网后Ollama唯一不能做的是拉取新模型。ollama pull会直接报网络错误，这个没得商量。但已经在本地的模型，ollama list能正常列出，ollama run能正常跑，ollama ps能看加载状态。如果你之前配置了国内镜像源加速下载，断网后镜像源也失效，但已经下载好的模型不受影响。
2.2 断网环境下的API调用与集成
Ollama默认监听127.0.0.1:11434，断网后这个本地API依然可用。这意味着任何通过HTTP调用Ollama的本地应用——比如FastAPI写的后端、CherryStudio这类客户端、或者你自己写的脚本——都能继续工作。我测试时用Python的requests库直接POST到http://localhost:11434/api/generate，断网状态下正常返回结果。
但这里有个坑：如果你之前用Nginx反向代理Ollama并设置了API Key做鉴权，断网后Nginx本身没问题，但如果你在代理配置里写了外部DNS或者上游指向了外网地址，那就会失败。正确的做法是确保Nginx的proxy_pass指向127.0.0.1:11434，并且不要在配置里引入任何外部依赖。我见过有人在Nginx配置里加了resolver 8.8.8.8做动态解析，断网后直接502。
另一个常见问题是Docker部署的Ollama。如果你用Docker跑Ollama，断网后容器本身能启动，但如果你在docker-compose.yml里配置了depends_on一个需要联网的服务，或者镜像拉取策略设成了always，那容器可能起不来。解决办法是把镜像策略改成if_not_present，并且确保所有依赖服务都是本地的。
services: ollama: image: ollama/ollama:latest pull_policy: if_not_present volumes: - /data/ollama:/root/.ollama ports: - "11434:11434"这样断网后docker compose up能正常启动已有镜像，模型文件也从挂载卷加载，整个链路本地闭环。
2.3 断网时Ollama的局限与应对
Ollama断网后最大的局限是没法下载新模型，也没法访问模型库查看有哪些可用模型。如果你平时习惯ollama pull试各种新模型，断网后这个习惯得改。我的应对策略是提前把常用模型下载好，并且定期更新。比如Qwen系列、Llama系列、DeepSeek Coder这些，各留一个稳定版本在本地。
另外，Ollama的WebUI如果用的是Open WebUI这类需要联网加载前端资源的，断网后页面可能样式错乱或者功能受限。解决办法是确保Open WebUI的静态资源已经本地缓存，或者直接用命令行交互。我平时用ollama run加管道做批量处理，断网时反而更顺手，因为没有网页端的干扰。
还有一个容易被忽略的点：Ollama在断网后如果遇到模型加载失败，错误信息可能不够明确。比如模型文件损坏时，它可能报一个模糊的加载错误。这时候可以检查~/.ollama/logs/server.log，里面会有更详细的堆栈信息。我遇到过因为磁盘坏道导致模型文件读取失败的情况，日志里能看到具体的IO错误。
注意：断网测试前先用
ollama list确认模型列表，再用ollama run随便跑一个prompt确认推理正常。如果这一步就失败，先解决本地问题，别急着归因于断网。
3. AI编程工具的离线能力对比
3.1 Wescode与Trae类工具的断网表现
Wescode和Trae这类AI编程工具，核心卖点是云端大模型驱动的代码补全、对话生成和项目级理解。断网后，这些工具的云端能力基本归零。我实测Wescode断网后启动能打开，但代码补全请求全部超时，对话窗口提示网络错误。Trae类似，断网后只能当普通编辑器用，AI功能全部不可用。
但这里有个区分：有些工具支持配置本地模型后端。比如你可以在Wescode的设置里把模型端点指向本地的Ollama服务。如果之前配置过，断网后理论上可以走本地推理。我试了一下，把Wescode的API地址改成http://localhost:11434，模型名填qwen2.5:7b，断网后代码补全居然能工作，虽然效果比云端模型差一些，但至少能用。
Trae这边我试了类似的配置，但它对本地模型的支持不够完善，断网后即使指向本地Ollama，补全延迟也明显偏高，而且经常超时。可能是它的请求格式或者超时设置跟Ollama的响应模式不太匹配。如果你重度依赖Trae，建议断网前先测试一下本地模型配置是否可用，别等到断网了才发现配不通。
这类工具断网后的共同问题是：项目索引和上下文理解依赖云端。即使本地模型能补全单行代码，但涉及跨文件理解、项目级重构时，本地模型的能力和上下文窗口都有限。所以断网后这类工具更适合做小范围的代码修改，不适合大型重构。
3.2 本地模型接入AI编程工具的配置要点
如果你想让AI编程工具在断网后还能用，核心思路是提前把模型后端切到本地。具体配置步骤因工具而异，但大体逻辑一致：找到设置里的模型提供方选项，选择自定义或本地，填入Ollama的API地址和模型名称。
以Wescode为例，在设置里找到AI Provider，选择Ollama，Base URL填http://127.0.0.1:11434，Model填你本地已有的模型名。保存后断网测试，如果补全能用，说明配置成功。如果报错，检查Ollama服务是否在运行，以及模型名是否拼写正确。
这里有个经验：本地模型的补全质量跟模型大小直接相关。7B模型做代码补全勉强够用，但复杂逻辑容易出错。如果你机器内存够，建议至少跑14B或32B的代码模型。我实测Qwen2.5-Coder-14B在断网后的补全质量明显好于7B，但推理速度会慢一些，需要权衡。
另一个坑是上下文长度。云端模型通常支持128K甚至更长的上下文，本地模型受限于显存和内存，上下文窗口往往只有8K或32K。断网后用本地模型做项目级理解时，很容易超出上下文限制导致截断。解决办法是手动缩小检索范围，或者用CKG这类工具先做代码检索，再把相关片段喂给本地模型。
3.3 断网后AI编程的降级工作流
断网后如果AI编程工具完全不可用，也不意味着写不了代码。我的降级工作流是这样的：先用CKG或FTS5做本地代码检索，找到相关函数和模块；然后用Ollama跑本地模型做代码解释和单元测试生成；最后手动完成代码修改和集成。整个流程虽然比云端AI辅助慢，但完全本地闭环，不受网络影响。
具体操作上，我会先用CKG的语义检索找到相关代码片段，比如搜“用户认证逻辑”，它会返回相关的函数和文件路径。然后把这些片段复制到Ollama的对话里，让本地模型解释逻辑并生成测试用例。修改完代码后，再用本地模型做一次代码审查，检查有没有明显的逻辑错误。
这个工作流的关键是检索质量。如果CKG的索引没建好，检索出来的片段不相关，后续的模型推理就是垃圾进垃圾出。所以断网前一定要确保CKG的索引是最新的，并且覆盖了你当前项目的核心代码。我通常会在每天下班前跑一次索引更新，这样即使晚上断网加班，检索也是可用的。
提示：本地模型的代码审查能力有限，别指望它能发现所有bug。断网后的代码审查建议聚焦在语法错误、明显的逻辑漏洞和边界条件上，复杂的架构问题还是等联网后用云端模型处理。
4. CKG与FTS5的本地检索能力
4.1 CKG断网后的知识图谱检索
CKG这类代码知识图谱工具，核心价值是把代码库的结构、依赖、调用关系建成图，然后支持语义检索和影响分析。断网后，只要图谱已经构建好并且存储在本地，检索功能完全可用。我实测断网后CKG的查询响应速度跟联网时一样，因为查询走的是本地图数据库，不依赖外部服务。
但CKG的图谱构建通常需要联网下载依赖或者调用云端API做代码解析。如果你断网前没有完成图谱构建，断网后就只能干瞪眼。所以关键操作是：在联网状态下完成全量索引构建，并定期增量更新。我自己的习惯是每次git pull之后跑一次增量索引，确保图谱跟代码库同步。
CKG断网后的一个隐藏优势是：没有网络延迟，检索反而更快。尤其是做跨文件调用链分析时，本地图数据库的遍历速度比云端API快很多。我测试时查一个跨5个文件的函数调用链，CKG断网后返回结果只用了不到200毫秒，联网时反而要等1秒多，因为要往返云端。
不过CKG的图谱构建对代码解析的准确性依赖较高。如果代码里有动态导入、反射调用或者复杂的元编程，图谱可能漏掉一些边。断网后你没法调用云端的高级解析服务来补全这些边，所以检索结果可能不完整。我的应对策略是在代码里尽量用显式导入和静态调用，减少动态特性，这样图谱更准确。
4.2 FTS5全文检索的离线优势
FTS5是SQLite的全文检索扩展，天生就是本地优先的设计。断网后FTS5完全不受影响，因为它的索引和数据都在本地SQLite文件里。我平时用FTS5给代码库和文档建全文索引，断网后搜索速度极快，而且支持布尔查询、短语搜索、前缀匹配等高级语法。
FTS5的配置要点是分词器和索引字段的选择。对于代码检索，我通常用unicode61分词器，并且把代码内容、注释、文件名都建到索引里。建索引的SQL大概是这样：
CREATE VIRTUAL TABLE code_fts USING fts5( file_path, content, tokenize='unicode61 remove_diacritics 2' );然后批量插入代码内容。断网后查询：
SELECT file_path, snippet(code_fts, 1, '<b>', '</b>', '...', 20) FROM code_fts WHERE code_fts MATCH '用户认证 AND 令牌';这个查询在断网后毫秒级返回，非常适合快速定位代码。
FTS5的局限是它只做关键词匹配，不理解语义。你搜“登录”它不会返回“认证”相关的代码，除非你手动扩展同义词。所以FTS5适合精确查找，CKG适合语义查找，两者互补。断网后我通常先用FTS5快速定位，再用CKG做调用链分析。
4.3 检索工具的联合使用与索引维护
断网后最高效的检索策略是FTS5加CKG联合使用。FTS5负责快速关键词定位，CKG负责语义理解和影响分析。我通常的流程是：先用FTS5搜到一个函数名，然后用CKG查这个函数被哪些地方调用，最后用Ollama本地模型解释这个函数的逻辑。
索引维护是断网检索的生命线。我的做法是写一个定时脚本，每天凌晨跑一次全量索引更新，包括FTS5的全文索引和CKG的图谱索引。脚本大概长这样：
#!/bin/bash # 更新FTS5索引 sqlite3 /data/code_index.db "DELETE FROM code_fts;" find /project/src -name "*.py" -exec sqlite3 /data/code_index.db "INSERT INTO code_fts VALUES ('{}', readfile('{}'));" \; # 更新CKG图谱 ckg index --project /project --output /data/ckg_graph这个脚本断网也能跑，因为所有操作都是本地的。唯一需要注意的是readfile函数需要SQLite编译时开启，或者用Python脚本替代。
索引文件的大小需要关注。FTS5索引通常比原始代码大30%到50%，CKG图谱可能更大。如果项目代码量很大，索引文件可能占几个GB。建议把索引存在数据盘，别放系统盘。另外定期做VACUUM回收空间，尤其是频繁增删索引后。
注意：FTS5的
MATCH查询对特殊字符敏感，比如代码里的*、(、)需要转义。我踩过这个坑，搜foo(直接报语法错误，后来改成foo加引号才正常。
5. 断网工作流的搭建与恢复策略
5.1 断网前的准备工作清单
断网工作流能不能跑起来，九成取决于断网前的准备。我整理了一份检查清单，每次出差或者进机房前都会过一遍：
| 检查项 | 具体操作 | 验证方法 |
|---|---|---|
| 模型文件 | 确认常用模型已下载到本地 | ollama list能看到模型 |
| 模型路径 | 确认存储路径指向数据盘 | 检查OLLAMA_MODELS环境变量 |
| 代码索引 | 跑一次全量FTS5和CKG索引 | 检索几个关键词确认有结果 |
| AI工具配置 | 把编程工具的模型后端切到本地Ollama | 断网前先模拟测试 |
| 依赖镜像 | Docker镜像全部拉取到本地 | docker images确认存在 |
| 文档缓存 | 常用文档和API参考存本地 | 用离线阅读器打开确认 |
这份清单看起来繁琐，但真到断网时能省下大量折腾时间。我印象最深的一次是在客户现场做离线部署，因为没提前确认Docker镜像，结果断网后docker compose up一直卡在拉取镜像，最后只能用docker save从另一台机器导出镜像再docker load，多花了两个小时。
5.2 断网状态下的工作流实录
断网后的实际工作流我按任务类型分三种：写代码、查资料、做部署。写代码时，我先用FTS5搜相关函数，再用CKG看调用关系，然后用Ollama本地模型生成代码片段和测试。查资料时，本地文档加Ollama问答基本够用，复杂问题记下来等联网再查。做部署时，所有镜像和配置文件提前准备好，断网后直接docker compose up。
我记录了一次典型的断网工作 session：上午9点断网，先跑ollama serve确认模型可用，然后用Wescode加本地Ollama做代码补全，写了一个用户注册模块。中午用FTS5查了之前项目的认证逻辑做参考。下午用CKG分析了新模块对现有代码的影响范围，然后用Ollama生成了单元测试。整个过程没有因为断网中断，只是补全速度比云端慢一些。
这个 session 里最耗时的环节是CKG的调用链分析，因为本地图谱对动态导入的解析不够完整，我手动补了几条边。如果提前在代码里避免动态导入，这个环节会快很多。另外Ollama的14B模型在16GB内存的机器上跑得有点吃力，后来换成7B模型才流畅起来。
5.3 恢复联网后的同步与更新
重新联网后第一件事不是马上干活，而是做同步和更新。我会按顺序跑：先ollama pull更新常用模型，再跑一次全量索引更新，然后检查AI编程工具的云端配置有没有被本地配置覆盖，最后同步本地文档和依赖。
这里有个坑：如果你断网前把Wescode的模型后端切到了本地Ollama，恢复联网后它不会自动切回云端。你需要手动改回云端配置，否则会一直用本地模型，补全质量下降。我建议在断网前记下原始配置，恢复后对照改回。
另一个坑是CKG的增量索引。断网期间如果改了代码，恢复联网后要跑增量索引，否则图谱跟代码不同步。我通常用ckg index --incremental做增量更新，比全量快很多。但如果改动很大，还是建议全量重建，避免图谱碎片化。
恢复联网后的模型更新也要注意磁盘空间。ollama pull新模型前先ollama list看看哪些旧模型可以删，尤其是那些只试过一次的模型。我一般保留3到5个常用模型，其他的用完就删，避免磁盘被模型文件塞满。
提示：恢复联网后先别急着跑大型任务，让Ollama和索引工具先完成同步。我试过一联网就急着跑代码生成，结果Ollama还在后台更新模型，推理请求排队等了很久。
6. 常见问题与排查技巧实录
6.1 断网后工具启动失败排查
断网后工具启动失败是最常见的问题，排查思路按优先级来：先看是不是强制在线校验，再看是不是依赖外部服务，最后看本地配置有没有问题。
强制在线校验的典型表现是启动页卡住或者弹窗提示“无法连接服务器”。这类工具断网后基本没救，除非它有离线模式或者你之前登录过并且token没过期。我遇到过一款工具断网后还能用，是因为它的授权token缓存了7天，断网后走本地校验。所以断网前确认一下工具的授权缓存策略很重要。
依赖外部服务的表现是启动时报DNS错误或者连接超时。这时候检查工具的配置文件，看有没有硬编码的外部地址。比如有些工具的默认配置里写了云端API地址，断网后启动时尝试连接导致超时。解决办法是提前把配置改成127.0.0.1或者本地地址。
本地配置问题包括模型路径错误、索引文件损坏、端口冲突等。这类问题联网时也可能出现，但断网后更明显，因为没有云端降级方案。排查时先看日志，Ollama的日志在~/.ollama/logs/，CKG的日志通常在项目目录的.ckg/logs/。日志里一般能看到具体的错误原因。
6.2 模型推理超时与性能问题
断网后本地模型推理超时，通常是因为模型太大或者硬件资源不足。我整理了一个排查表：
| 现象 | 可能原因 | 解决方法 |
|---|---|---|
| 首次推理特别慢 | 模型加载到内存耗时 | 等待加载完成，或换小模型 |
| 推理中途卡住 | 内存不足触发swap | 关掉其他占内存的程序 |
| 响应时间越来越长 | 上下文累积过长 | 清空对话历史重新开始 |
| 报OOM错误 | 模型超出显存/内存 | 换量化版模型或减小上下文 |
| GPU利用率低 | 模型没跑在GPU上 | 检查Ollama的GPU配置 |
我实测16GB内存跑14B模型时，如果同时开着浏览器和IDE，很容易触发swap，推理速度从每秒20token掉到每秒3token。后来我养成习惯，跑大模型前先关掉不必要的应用，尤其是Chrome这种内存大户。
另一个性能技巧是用量化模型。Ollama支持q4_0、q4_K_M等量化格式，同样参数量的模型，量化后内存占用能减少一半以上，推理速度也更快。代价是精度略有下降，但代码补全场景下差异不明显。我通常用q4_K_M，平衡了速度和精度。
6.3 索引损坏与检索异常处理
FTS5索引损坏的表现是查询报database disk image is malformed，CKG图谱损坏的表现是查询返回空结果或者报图数据库错误。这类问题通常是因为索引文件在写入时被中断，或者磁盘空间不足导致写入不完整。
FTS5索引损坏的修复方法是重建索引。先备份原始数据，然后DROP TABLE code_fts再重新CREATE VIRTUAL TABLE并插入数据。如果原始数据还在，重建通常几分钟到几十分钟，取决于代码量。我建议索引文件单独存一个SQLite文件，别跟业务数据混在一起，这样损坏时影响范围小。
CKG图谱损坏的修复类似，删掉图谱文件重新构建。但CKG重建通常比FTS5慢，因为要做代码解析和关系抽取。我一般每周做一次全量重建，每天做增量更新，这样即使损坏，最多丢失一天的增量。
检索异常还包括结果不相关或者漏结果。这通常是索引没覆盖到最新代码，或者分词器配置不合适。检查索引更新时间，如果落后于代码修改时间，跑一次增量更新。分词器方面，代码检索建议用unicode61，文档检索可以用porter做词干化。
注意：索引重建前先确认磁盘空间足够。我遇到过重建到一半磁盘满了，索引文件损坏，只能从头再来。建议预留至少两倍于索引大小的空间。
6.4 断网工作流的独家避坑经验
踩过的坑里，最值得分享的是三个：模型路径别放系统盘、索引更新要自动化、本地模型配置要提前测试。
模型路径放系统盘这个坑我踩过两次。第一次是Ollama默认路径把系统盘塞满，导致系统卡顿；第二次是重装系统时忘了备份模型，几十GB的模型文件全丢了。后来我把模型路径统一设到数据盘，并且用rsync定期备份到另一块盘。虽然占空间，但省心。
索引更新自动化是另一个关键。手动跑索引很容易忘，尤其是项目多的时候。我写了一个cron任务，每天凌晨2点跑全量索引，每4小时跑一次增量。这样即使断网，索引也是最新的。cron脚本里加上日志输出，方便排查失败原因。
本地模型配置提前测试这个坑，我是在一次客户现场断网后才意识到的。当时以为Wescode配了本地Ollama就能用，结果断网后发现配置没保存，AI功能全挂。后来我养成习惯，每次改完本地模型配置，先断网模拟测试一遍，确认能用再继续。
最后分享一个小技巧：断网前用ollama ps确认模型加载状态，用curl http://localhost:11434/api/tags确认API可用，用sqlite3 code_index.db "SELECT count(*) FROM code_fts"确认索引有数据。这三个命令跑一遍，基本能确认断网工作流的核心组件都就绪了。
