AI 编程助手选型：本地隐私与云端索引

Continue.dev 和 Cursor 的选择，先看代码能不能交给云端处理，再看补全速度。原文的结论很明确：需要本地运行、控制数据流向，优先考虑 Continue；接受云端处理、希望开箱即用，Cursor 更省事。

这篇比较值得读的是架构与故障分析。不过，作者虽然给出不少测试数字，却缺少完整结果表，计费、合规和产品能力也有若干未经充分支撑的断言。适合拿来设计试点，不适合直接当采购结论。

代码在哪里处理，决定了哪些方案能入围

Continue 以 VS Code / JetBrains 扩展配合本地 Node/Python 核心运行。嵌入、重排、中间补全 FIM，都可以接本地服务或托管 API。Ollama、llama.cpp、vLLM、LM Studio 通过 OpenAI-compatible endpoints 接入，聊天和补全也能分别选模型。

下面这段原文架构图，说明代码索引与模型推理如何留在工作站内：

flowchart LR
    subgraph Workstation["Developer Workstation (air-gap capable)"]
        IDE["VS Code / JetBrains"] --> CC["Continue Core (Node + Python sidecar)"]
        CC -->|chunks + mtimes| IDX[("LanceDB (local disk,\nHNSW index, ~1.2GB per 500k LOC)")]
        CC -->|OpenAI-compatible HTTP| OLL["Ollama / vLLM / llama.cpp\n(Qwen2.5-Coder-7B, local)"]
        CC -.->|optional| API["Hosted LLM API\n(Anthropic/OpenAI)"]
    end
    IDX --- CC
    OLL -->|FIM tokens| CC --> IDE
    style IDX fill:#d4e8ff
    style OLL fill:#d4ffd8

要看清 CC -.->|optional| API 这一行：Continue 可以全部本地运行，也可以调用云端。选了开源扩展，不代表配置里的代码一定不出网。

按作者描述，索引位于 ~/.continue/index/lancedb，SQLite 记录文件修改时间，用于增量更新。切块借助 tree-sitter 理解约 15 种语言的语法边界，以函数、类为单位，目标约 512 tokens 并保留重叠。检索再组合 SQLite FTS5、LanceDB HNSW（ef=64）及可选重排，最后去重、裁剪上下文。

Cursor 则被描述为依赖云端索引的 VS Code 闭源分支：客户端同步 Merkle 树哈希及变化内容，服务端重新处理变更部分。作者给出的 500k 行仓库增量同步量约为 2–8 MB，图中还标注了 32 路并行嵌入。

这里真正要问的是：谁处理源码、索引能否迁移、网络中断时还能完成什么工作。作者称 Cursor 索引不可导出，但没有交代对应版本，也没有充分展开隐私模式、数据保留和部署选项。涉及 HIPAA、ITAR 或金融监管时，原文的「唯一可行」判断过于绝对，本地运行也不能自动等同于合规。

本地补全有没有竞争力，要把速度和正确率分开

作者的主工作站是 Ryzen 9 7950X、128 GB DDR5-5600、RTX 4090 24 GB，加 Samsung 990 Pro 4 TB NVMe。测试仓库包括 480k 行 TypeScript/Python、工作区 5.1 GB 的 monorepo-A，以及 95k 行 Go/Terraform 的 infra-B。

补全测试使用 120 道人工整理的 FIM 任务，以单元测试计算 pass@1，也就是第一次生成就通过的比例；每种配置采样 2,000 次触发延迟。

Cursor 在 EU-West、1 Gbps 对称光纤、到云端 42 ms RTT 的环境中，按键到灰字的 p50 为 145 ms，比调优后的本地 3B 方案快约 35 ms。作者还称，本地 7B 模型在 310 ms 延迟下正确率更高，并引用约 400 ms 的用户容忍阈值。

这些数字支持本地方案值得测试，却不足以证明它普遍优于 Cursor。

原文没有展示各配置的 pass@1 数值、完整模型版本、提示词和失败样例。它也不能直接回答国内网络、不同代码库和不同语言下的体验。

检索同样依赖硬件。作者给出的 500k 行仓库检索延迟是 p50 约 85 ms、p99 约 240 ms，前提是 NVMe 与热页缓存；HDD 或启动后首次查询可能慢 3–5 倍。冷建索引时测得 4k 随机写约 18k IOPS、顺序读约 210 MB/s，SATA SSD 预计需要约 14 分钟，但没有提供对应的完整 NVMe 建库时间。

显存配置也别照单全收。作者建议 RTX 4090 同时运行 Qwen2.5-Coder-14B 的 Q5_K_M 量化版，约占 10.5 GB，再加约 2.2 GB 的 3B FIM；16 GB 笔记本显卡则保留本地补全、聊天走 API，避免共享内存交换把 p99 推到 8 秒以上。

真正拖慢团队的，可能是账单和维护工作

原文对 Cursor 的主要批评，是请求额度不等于对话次数。按作者所述的套餐口径，Pro 的「500 fast requests」会因上下文和工具调用，让一次 agent 或 Composer 操作消耗 2–15 个单位；涉及 10 个文件的复杂重构，可能消耗 30–40 个。

作者称重度用户会在 8–12 个工作日耗尽额度，按需费用约为直接 API 价格的 2–3 倍，并复现过一个 $20 席位在一次 sprint 中产生 $340 超额费用。其建议是查看 Settings → Usage，关闭「on-demand」。

这些只能视为原文所述时期的账单案例。文章没有给出套餐日期和完整账单，也没有依据证明这是支持工单、差评或迁移的首要原因。

Continue 的代价则更偏向运维。作者估算，40 人规模每月需要 8–10 个开发工时，负责模型升级、容量和 vLLM 兼容；所谓 CUDA/驱动矩阵每年约出问题两次，也只是他们的经验。

两个故障尤其有实际参考价值：

• 分支切换后，索引可能仍引用已删除符号。作者建议删除 ~/.continue/index/ 重建，检查 SQLite 的 file_features，并在 post-checkout hook 中安排 Continue: Full reindex。但原文提到的 git config core.truetime 没有给出来源，不应直接当作通用 Git 配置。
• 本地模型与 Chrome、Docker、Electron 编辑器争抢资源，可能让补全从 300 ms 跳到 4–9 s。作者建议 Linux 下使用 --mlock、限制 --parallel 2，或迁往局域网 vLLM 服务，增加约 3–8 ms RTT。--mlock 也不能据此被理解为解决所有显存问题的保证。

原文还声称 Cursor 遇到 Zscaler、Netskope 的 TLS 代理误配置时会失去整个编辑器，以及迁移需要每人 0.5–1.5 个开发日。这些影响很大，但缺少版本和复现步骤，应作为试点验证项。

我的判断

我认同作者把数据边界放在补全体验前面。源码不能交给外部服务时，模型再快，也不能替团队绕过约束。Continue 可替换推理后端、沿用现有 IDE，确实提供了更大的控制空间。

但成本和质量结论明显比证据走得更远。

作者声称，25 人以下 Cursor 超额费用会侵蚀标价优势，100 人以上且已有 GPU 或预留容量时，自托管 Continue 可便宜 30–45%。原文却缺少完整 TCO 表，无法核对硬件折旧、闲置率、维护工时与实际 API 消耗。最终 4.8/5 和 4.5/5 的评分也没有权重说明，只能当作作者偏好。

此外，Continue 接托管 API 是重要的中间选项：保留现有编辑器与后端选择权，同时减少 GPU 维护。代价是仍然存在云端代码处理。对于没有硬件、接受云端处理的 5–25 人团队，Cursor 的集成体验有吸引力，但仍需用实际任务核对费用。

能拿来做什么

• 先给项目划定数据边界，明确源码、嵌入和索引分别允许在哪里处理，再决定 Continue 的本地、混合或托管 API 配置。
• 用自己的 TypeScript、Node 仓库准备一组可运行测试的补全任务，同时记录正确率、p50、p99 和采纳情况，别只比较灰字出现速度。
• 用包含跨文件修改的真实工作日验证账单；原文的重度使用口径是每天约 35 次 agent/chat 请求、800 次补全，可用于对照自己的负载。
• 企业试点可以参考作者的两周方案，用一个团队和一台 L40S 验证容量，同时检查分支切换后的索引、代理网络和维护工时，再讨论采购。