断网之后，六款工具还剩什么场景：高铁进隧道，Wi-Fi 断了北京到上海的高铁，过了济南之后进入一段 40 分钟的信号盲

断网之后，六款工具还剩什么

利益声明：本文作者参与了 wescode 的开发。文中涉及 wescode 的技术描述基于内部测试数据；涉及其他工具的描述基于各家公开文档和社区反馈。

场景：高铁进隧道，Wi-Fi 断了

北京到上海的高铁，过了济南之后进入一段 40 分钟的信号盲区。你正在用 AI 编程工具重构一个微服务——刚让 AI 帮你分析了 OrderService 的调用链，准备动手改接口签名。

然后网断了。

你的 Cursor 弹出红色错误：Failed to connect to API。Tab 补全消失了，@codebase 语义搜索返回空结果，内嵌的 AI 对话框转圈后超时。你能做的只剩下——打开文件树，手动一个个翻代码，像 2019 年那样。

但隔壁座位的同事打开 wescode，CKG 项目概览面板照常渲染着 D3 交互式调用图。他点击 OrderService.CreateOrder，影响分析列出了 12 个受影响的函数。FTS5 搜索瞬间定位到所有 orderID 的引用位置。他甚至打开了本地 Ollama，用 Qwen2.5-Coder 7B 做简单的代码补全和问答。

同一列车，同一个断网，两种完全不同的工作状态。

差异不在网速，不在设备性能，在于一个根本的架构选择：代码理解能力是放在云端 GPU 上算，还是放在本地 CPU 上算。

这篇文章不讲理论，讲事实：哪些功能天然离线，哪些功能断网就死，以及在完全没有网络的三个小时里，你到底能做多少工作。

先搞清楚：什么功能必须联网，什么不必

AI 编程工具的每个功能背后都有一个技术栈。有些技术栈天然依赖网络，有些天然不依赖。搞清楚这层关系，才能判断"断网后还剩什么"不是一句口号，而是可以逐项验证的技术事实。

五种核心技术的联网依赖

技术	代表工具	为什么需要联网	离线替代方案
Embedding 向量搜索	Cursor `@codebase`	向量计算需要云端 GPU；本地 CPU 算一次 10 万行要几十分钟，且质量差	tree-sitter 结构化解析（精确但语义弱）；本地小模型 Embedding（质量降级明显）
LLM 推理	所有 AI 对话/补全	70B+ 参数模型需要 A100 级 GPU；本地 Apple Silicon 只能跑 7B-13B	本地 Ollama 跑 7B 模型（≈GPT-3.5 水平，补全可用，复杂推理弱）
tree-sitter 解析	wescode CKG	纯 CPU 操作，逐文件解析 AST，毫秒级完成	不需要替代——本身就是离线技术
SQLite 查询	wescode CKG/FTS5	纯文件数据库，读写都在本地磁盘	不需要替代——本身就是离线技术
LSP 语言服务	VS Code 内置	语言服务器在本地进程运行，提供跳转/引用/补全	不需要替代——本身就是离线技术

关键洞察：Cursor 和 Copilot 的核心能力（Embedding 搜索 + LLM 推理）恰好都在"必须联网"这一侧。wescode 的 CKG 和 CSE 恰好都在"天然离线"这一侧。这不是巧合，是架构选择的结果——选择在本地 CPU 上做确定性计算，而不是在云端 GPU 上做概率推理。

用 TypeScript 伪代码展示两种架构在代码搜索上的根本差异：

// 两种架构：云端概率搜索 vs 本地确定性查询

// --- Embedding 架构（Cursor / Copilot）---
async function embeddingSearch(query: string): Promise<CodeSnippet[]> {
  // 步骤 1：把查询文本发到云端，计算向量
  const queryVector = await cloudAPI.embed(query)  // ⚠️ 需要网络
  // 步骤 2：在云端向量数据库中做近似最近邻搜索
  const results = await cloudAPI.vectorSearch(queryVector, { topK: 20 })  // ⚠️ 需要网络
  // 返回的是"语义最相似的 20 个片段"——概率排名，可能漏掉结构相关但语义无关的代码
  return results
}

// --- CKG 架构（wescode）---
function ckgSearch(symbol: string): CallGraphNode[] {
  // 步骤 1：在本地 SQLite 中查询符号的调用关系
  const callers = db.query(`
    SELECT source_file, source_symbol, relation_type
    FROM edges WHERE target_symbol = ? 
    ORDER BY source_file
  `, [symbol])  // ✅ 纯本地磁盘操作，< 50ms
  // 返回的是"确定调用了这个符号的所有函数"——精确结果，零遗漏
  return callers
}

一个走网络，一个走磁盘。断网后，前者返回 NetworkError，后者返回和联网时完全一样的结果。

tree-sitter 如何在本地构建代码知识图谱

wescode 离线能力逐项清单

下表列出 wescode 的每一项功能在断网时的状态。不是"能不能用"的简单回答，而是为什么能/为什么不能的技术原因。

功能	离线可用	技术原因	备注
CKG 调用图查询	✅ 完全可用	tree-sitter 解析 → SQLite 存储，全部在本地 CPU 完成	10 万行项目索引 5-15 秒
CKG 影响分析	✅ 完全可用	基于本地 SQLite 中的调用边数据做图遍历	增量更新 100-500ms
CSE 约束检查	✅ 完全可用	本地推导引擎，从 CKG 数据推断代码惯例	不依赖任何外部 API
项目概览面板	✅ 完全可用	D3.js 从本地 CKG 数据渲染交互式调用图	浏览器内渲染，零网络请求
FTS5 代码搜索	✅ 完全可用	SQLite FTS5 全文索引，纯本地文件操作	比 `grep -r` 快且支持排序
Git 操作	✅ 完全可用	Git 是分布式版本控制，本地仓库包含完整历史	push/pull 需要网络，commit/branch/diff 不需要
终端	✅ 完全可用	本地 shell 进程	涉及网络的命令（curl、npm install）自然失败
文件编辑	✅ 完全可用	VS Code 编辑器核心，纯本地操作	扩展全兼容，离线时扩展商店不可访问
AI 对话（云端）	不可用	需要调用 OpenAI/Anthropic/DeepSeek 等云端 API	断网即失效
AI 对话（本地 Ollama）	✅ 可用	BYOK 配置 `http://localhost:11434`，模型运行在本地	需提前下载模型；质量受限于本地算力
AI 补全（云端）	不可用	Tab 补全依赖云端模型实时推理	断网即失效
AI 补全（本地）	✅ 可用	本地 Ollama 提供补全端点	延迟较高（首 token 1-3 秒），质量降级
记忆读取	✅ 可用	记忆存储在本地 Cell 的 SQLite 数据库中	每个工作区 = 一个 Cell，数据物理隔离
记忆写入	✅ 可用	同上，写入本地数据库	不依赖平台同步
Skill 加载	✅ 可用	Skill 文件存储在本地 Cell 目录下	安装新 Skill 需要网络，已安装的离线可用

15 项功能中，13 项离线完全可用。仅有云端 AI 对话和云端 AI 补全需要网络——而这两项都有本地 Ollama 作为降级替代。

六款工具离线能力全量对比

不只看 wescode，把 2026 年主流的六款 AI 编程工具拉到同一张表里：

能力	Cursor	Copilot	Claude Code	通义灵码	Trae	wescode
代码编辑	✅	✅	无（终端工具）	✅	✅	✅
AI 对话	纯云端	纯云端	纯云端	纯云端	纯云端	支持（本地 Ollama）
AI 补全	纯云端	纯云端	N/A	纯云端	纯云端	支持（本地 Ollama）
语义代码搜索	云端 Embedding	云端 Embedding	依赖 grep	云端搜索	云端搜索	支持（CKG + FTS5）
调用图 / 影响分析	无	无	无	无	无	支持（CKG 本地图遍历）
项目结构概览	无	无	无	无	无	支持（D3 交互式面板）
约束检查	无	无	无	无	无	支持（CSE 本地推导）
记忆 / 上下文	断网后无法访问	无	无	无	无	支持（本地 SQLite）
Git 操作	✅ 本地部分	✅ 本地部分	✅ 本地部分	✅ 本地部分	✅ 本地部分	✅ 本地部分
断网后实际能力	基础编辑器 + LSP	基础编辑器 + LSP	grep + 终端	基础编辑器 + LSP	基础编辑器 + LSP	完整代码分析 + 本地 AI

wescode 的离线 AI 对话和补全依赖提前下载的本地模型（7B 质量约等于 GPT-3.5），与云端大模型有代际差距。首次索引也需 5-15 秒。详见下文"能力边界"。

Before/After 对比——断网三小时的工作效率：

维度	Before（纯云端工具）	After（wescode 本地架构）
代码搜索	`grep -r` 手工翻找，无排序无关联	CKG 调用图 + FTS5 排序，< 50ms 返回精确结果
影响面定位	人工沿调用链逐文件查看，~30 分钟/次	CKG 一键遍历全部调用方，< 1 秒
AI 问答	完全不可用	本地 Ollama 7B，单函数级别问题秒回
AI 补全	完全不可用	本地 Ollama 补全，首 token ~1.5 秒
项目约定检查	人工记忆 + 肉眼审查	CSE 自动推导检查
三小时产出估算	1-2 个文件修改（大量时间消耗在搜索和定位）	3-5 个文件修改（搜索和定位零成本）

高铁三小时：一个完整的离线工作流

以下是一个真实的工作场景还原——不是假设，是 wescode 用户在断网环境下的实际操作序列。

上车前（联网状态）

你在候车厅连着 Wi-Fi 打开 wescode，确认三件事：

CKG 索引已就绪——状态栏显示"AI 就绪"，10 万行项目的调用图已经建好，项目概览面板能正常渲染
记忆已加载——上次关于 OrderService 重构的对话记忆还在，AI 记得你讨论过的拆分方案和接口变更计划
Ollama 模型已下载——终端输入 ollama list，确认 qwen2.5-coder:7b 已经在本地，4.7GB 模型文件完整

三项确认完毕，合上笔记本上车。即使信号完全消失，所有工作数据都已经在本地磁盘上了。

进隧道（断网瞬间）

手机信号消失，Wi-Fi 连接中断。以下是立即发生的变化：

失去	保留
云端 AI 对话（Claude/GPT/DeepSeek）	CKG 调用图 + 影响分析 + 项目概览
Tab 智能补全（云端模型）	CSE 约束检查（本地推导）
Embedding 语义搜索	FTS5 全文代码搜索
扩展商店 / 远程仓库	Git 本地操作（commit/branch/diff）
—	本地 Ollama AI（已下载模型）
—	所有已安装扩展 + Skill

wescode 没有弹任何错误提示。 因为正在使用的所有功能——文件编辑、CKG 索引查询、CSE 约束检查、FTS5 搜索、Git——没有一个依赖网络。编辑器状态和断网前完全一致。

断网期间（具体操作）

第 1 小时：理解代码结构

打开项目概览面板，D3 调用图清晰地展示 OrderService 的依赖关系。点击 CreateOrder 方法，影响分析列出：

CreateOrder
├── validateOrder (internal/validator/order.ts:45)
├── calculatePrice (internal/pricing/engine.ts:112)
├── deductInventory (internal/inventory/stock.ts:78)
├── createPayment (internal/payment/gateway.ts:34)
└── sendNotification (internal/notify/dispatcher.ts:91)

5 个直接调用方，12 个间接影响函数。这些数据全部来自本地 SQLite，查询耗时 < 50ms。

第 2 小时：修改代码

用 FTS5 搜索所有 orderID 的引用——0.1 秒返回 47 个结果，按文件分组排列。CSE 告诉你项目惯例：错误返回格式是 throw new AppError("operation: description", code)，接口方法按字母序排列。

改完三个文件后，用本地 Ollama 问了一个简单问题：

Q: 这个 TypeScript 接口改了签名，调用方需要怎么改？
A: [Qwen2.5-Coder 7B 在 2 秒内给出了正确的改法]

7B 模型应付这种单文件、单函数级别的问题绰绰有余。

做不到的事：你试着让 Ollama 分析整个支付链路的事务一致性问题——7B 模型给出了模棱两可的回答，缺少对全局状态的把握。你又尝试让它做多文件重构方案，结果遗漏了两个调用方。复杂的跨文件推理、架构级分析仍然需要 Claude Sonnet 级别的模型。记住：本地 AI 是保底，不是替代。

第 3 小时：验证和提交

编译通过。测试全部通过。本地提交完成。

三小时产出：3 个文件修改，1 次本地提交，全程零等待、零报错、零因断网造成的工作阻塞。

出隧道（恢复网络）

网络恢复后，切换回来是无缝的：

之前的所有编辑、CKG 分析结果、Git 提交完整保留——没有任何数据丢失或需要重建
在设置中把 AI 模型切回 Claude Sonnet——立即可用，之前的对话记忆也还在
git push origin feature/order-refactor——代码推送到远端
CKG 索引无需重建——它从来就是本地的，恢复网络不影响它的任何状态

断网不是"暂停工作"，是"换一种方式继续工作"。 你失去的是云端大模型的智力上限，保留的是完整的代码理解、搜索、分析和编辑工具链。

本地模型实测：Ollama 能做什么，不能做什么

离线 AI 的质量取决于你的硬件和模型选择。以下是 Apple Silicon Mac 上的实测数据：

模型	参数量	M2 MacBook (16GB)	M2 Pro (32GB)	首 token 延迟	生成速度	代码质量	内存占用
DeepSeek-Coder 7B	7B	✅ 流畅	✅ 流畅	~1.5s	~25 tok/s	单函数补全可用	~5GB
Qwen2.5-Coder 7B	7B	✅ 流畅	✅ 流畅	~1.2s	~30 tok/s	补全+简单问答	~5GB
CodeLlama 13B	13B	⚠️ 较慢	✅ 可用	~3s	~15 tok/s	中等复杂度可用	~9GB
Qwen2.5-Coder 32B (Q4)	32B	内存不足	⚠️ 勉强	~6s	~8 tok/s	接近 GPT-4 级别	~20GB

诚实的能力边界

7B 模型 ≈ GPT-3.5 水平：单文件补全、简单代码问答够用；跨文件推理、架构设计、复杂 debug 力不从心
13B 是性价比甜点：32GB 内存的 Mac 可以流畅运行，质量比 7B 有明显提升，能处理中等复杂度的代码问题
32B 量化版接近 GPT-4：但需要 32GB+ 内存，且响应速度较慢，适合"想清楚再问"的使用方式
本地模型不是云端的替代品——它是断网时的保底方案，让你从"完全没有 AI"升级到"有一个还行的 AI"

用 Python 展示本地 Ollama 配置和 fallback 机制的实现原理：

# 本地 Ollama 配置 + 自动 fallback 的工作原理

class ProviderResolver:
    """wescode 的 Provider 解析器——简化示意"""
    
    def __init__(self, providers: list):
        self.providers = providers  # 按优先级排列
    
    def resolve(self, request) -> Provider:
        for provider in self.providers:
            if provider.is_available():
                return provider
        raise NoProviderAvailable()
    
    def is_available(self) -> bool:
        # 云端 provider：检查网络连通性
        if self.type == "cloud":
            try:
                resp = http_head(self.base_url, timeout=2)
                return resp.status == 200
            except NetworkError:
                return False
        # 本地 provider：检查进程是否在运行
        if self.type == "ollama":
            try:
                resp = http_get("http://localhost:11434/api/tags")
                return resp.status == 200
            except ConnectionRefused:
                return False

# 配置示例：云端优先，本地兜底
# providers:
#   - name: claude-sonnet    type: cloud     priority: 1
#   - name: local-ollama     type: ollama    priority: 2
#
# 联网时 → 使用 claude-sonnet（高质量）
# 断网时 → 自动切换到 local-ollama（保底质量）
# 恢复网络 → 下次请求自动切回 claude-sonnet

Cell 隔离确保离线数据安全

合规场景：断网不是意外，是要求

对很多企业来说，"离线能力"不是高铁上的锦上添花，而是采购的准入门槛。代码能不能出内网，直接决定了你能用什么工具、不能用什么工具。

以下三类场景覆盖了中国开发者最常遇到的网络隔离需求：

金融行业

银行和券商的核心交易系统代码不允许离开内网。开发环境部署在行内数据中心，外网完全隔断。传统方案是 VSCode + 人工 code review，没有任何 AI 辅助。wescode + 内网部署的 Ollama 或 vLLM 可以在零外网依赖的前提下提供完整的 CKG 调用图分析、CSE 惯例检查和本地 AI 对话。合规底线不碰，工具能力不降级——这在以前是不可能的。

政企 / 央企

等保三级要求开发环境与互联网隔离。典型架构：跳板机 → 内网开发机，开发机无任何外网访问权限。在这种环境下安装 Cursor 没有意义——它的每一项核心能力（对话、补全、语义搜索）都需要联网才能工作。wescode 的全部离线能力（CKG + CSE + FTS5 + 本地 Ollama）在这种环境下开箱即用，不需要申请白名单、不需要配置代理、不需要审批任何外网连接。

军工 / 涉密

物理隔离网络，不是"限制外网"而是"物理上不存在外网"。在这种环境下，依赖云端 API 的工具根本无法安装——连 npm install 都做不到。wescode 基于 VS Code Fork，可以离线安装（.vsix 离线包），CKG 索引完全在本地 CPU 完成，Ollama 支持离线部署模型文件（ollama cp 从加密 U 盘导入）。完全断网是这些行业的日常，不是异常。

用 Java 伪代码理解 wescode 数据隔离的安全模型——为什么代码"从未离开你的机器"：

// wescode 数据隔离安全模型——概念说明

public class CellIsolation {
    // 每个工作区 = 一个 Cell，数据物理隔离
    // 路径：$XDG_DATA_HOME/wescode/cells/ws-{hash}/
    
    private final Path cellDir;    // 本 Cell 的根目录
    private final SQLiteDB metaDb;     // meta.db：元数据
    private final SQLiteDB sessionsDb; // sessions.db：对话记忆
    private final SQLiteDB stateDb;    // state.db：运行时状态
    private final Path indexDir;       // index/：CKG 索引
    
    public void verifySecurity() {
        // ✅ 所有数据存储在本地磁盘
        assert cellDir.startsWith(localDataDir);
        
        // ✅ 无云端同步服务
        assert noCloudSyncConfigured();
        
        // ✅ CKG 索引纯 CPU 计算，不调用任何外部 API
        assert ckgIndex.isLocalOnly();
        
        // ✅ 记忆存储在本地 SQLite，不上传
        assert sessionsDb.getPath().startsWith(cellDir);
        
        // ✅ 不同工作区的 Cell 数据物理隔离
        // ws-a1b2 的数据目录和 ws-c3d4 完全独立
        // 无法跨 Cell 访问（连数据库文件都是不同的）
    }
}

六款工具数据安全能力对比

能力边界：我们做不到的

诚实地说，wescode 的离线模式不是万能的：

离线 AI 无法替代云端 AI——7B 本地模型和 Claude Sonnet 4 之间有代际差距，本地 AI 是保底方案，不是同等替代
CKG 不做自然语言理解——它精确回答"谁调用了这个函数"，但回答不了"这段代码的业务逻辑是什么"
首次索引需要时间——10 万行项目 5-15 秒，50 万行可能需要 1-2 分钟，但之后增量更新只需 100-500ms
Ollama 需要提前下载——模型文件 4-20GB 不等，必须在有网络时提前准备好
扩展商店离线不可用——已安装的扩展正常工作，但无法浏览和安装新扩展
Embedding 语义搜索离线不可用——CKG 提供结构化替代，但"用自然语言找代码"这件事仍需云端 AI

FAQ

Q：Cursor 能不能也配本地模型实现离线？

Cursor 的 AI 功能与其云端服务深度绑定——模型调用、@codebase 语义搜索、Tab 补全都走 Cursor 自己的服务器。即使配了本地模型，@codebase 的 Embedding 搜索仍然需要云端 API 计算向量。换句话说，AI 对话可以本地化，但代码理解能力无法本地化——这是 Embedding 架构的固有限制。

wescode 不同：CKG 的代码理解（调用图、影响分析、项目概览）本身就是本地计算，和 AI 模型是两个独立系统。断网后你失去的是"AI 帮你写代码"，但"AI 帮你理解代码"这件事完全不受影响。

Q：为什么 wescode 不用 Embedding 做代码搜索？

wescode 用 CKG（代码知识图谱）替代 Embedding 做结构化代码理解。CKG 基于 tree-sitter 精确解析 AST，构建调用图和依赖关系——这是确定性计算，不是概率推理。搜索 OrderService.CreateOrder 的调用方，CKG 给出的是精确的 12 个函数列表，不是"语义最相似的 10 个片段"。

代价是 CKG 不擅长自然语言模糊搜索（比如"处理支付的代码在哪"）——这种场景仍然需要 LLM 的语义理解能力。但在离线环境下，精确结果远比模糊结果有用。

Q：本地 Ollama 的 7B 模型真的能用吗？

看场景。能用的：单函数补全、简单代码问答、格式转换、正则表达式生成、简单的 API 用法查询。不能用的：跨文件重构建议、架构设计、复杂 bug 分析、需要理解完整业务上下文的推理任务。

实际体验：7B 模型大约是 2023 年初 GPT-3.5 的水平。如果你用过 ChatGPT 早期版本写代码的感觉——差不多就是那样。有比没有好很多，但别指望它替代 Claude Sonnet。

Q：wescode 与 VS Code 扩展兼容吗？离线时扩展能用吗？

wescode 基于 VS Code Fork，扩展全兼容。已安装的扩展在离线时完全正常工作——语言支持、主题、代码片段、格式化工具等都不受影响。唯一的限制是扩展商店（marketplace）本身需要联网访问，所以无法在离线状态下浏览和安装新扩展。建议在有网络时把常用扩展装好，之后离线使用完全无障碍。

Q：wescode 的离线数据安全吗？

每个工作区 = 一个 Cell，数据物理隔离在 $XDG_DATA_HOME/wescode/cells/ws-{hash}/ 目录下。CKG 索引、记忆、Skill 都存储在本地 SQLite 数据库中，不经过任何云端同步服务。对于金融/政企/军工场景，这意味着代码和分析数据从未离开过你的开发机器——这不只是技术实现，更是可审计的合规保证。

wescode 的安全架构模型

Q：如何为离线工作做准备？

一份清单：

下载 Ollama + 模型：ollama pull qwen2.5-coder:7b（4.7GB），推荐 32GB 内存的机器额外下载 13B 版本
确认 CKG 索引就绪：打开项目，等状态栏显示"AI 就绪"（10 万行约 5-15 秒）
安装常用扩展：Python、ESLint、Prettier、GitLens 等——离线后扩展商店不可用
确认 Git 仓库完整：git fetch --all 确保远程分支数据在本地
可选：下载离线文档：devdocs.io 支持离线下载常用框架文档

准备完成后，即使完全断网一周，你的 wescode 工作环境也和联网时几乎一样（云端大模型除外）。

本文数据基于 2026-09 实测，硬件为 M2 Pro MacBook Pro 32GB。不同硬件配置的性能数据可能有差异。

"断网后还能做什么"不是一个产品功能问题，是一个架构选择问题。

选择 Embedding + 云端 LLM 的工具，得到了强大的语义理解能力，代价是完全依赖网络连接。选择 tree-sitter + SQLite + 本地引擎的工具，得到了确定性的代码分析能力，而且天然离线可用。两种架构没有绝对的好坏之分，但在不同的使用场景下会呈现截然不同的可用性。

对于经常出差、通勤中需要写代码的开发者，对于工作环境要求代码不出内网的金融/政企/军工行业——这可能是你在选择 AI 编程工具时需要了解的最重要的技术差异。