Published on

用本地大模型 + Continue 在 IDEA 打造 AI “核动力”架构

Authors
  • avatar
    Name
    Charles Chen
    Twitter

用本地大模型 + Continue 在 IDEA 打造 AI “核动力”架构

引言：429 报错，是架构师进阶的号角

当你在 IDEA 里配置 Continue 却撞上 RESOURCE_EXHAUSTED (429) 这种冷冰冰的报错时，平庸的程序员会去刷信用卡求 Google 给点额度，但准 50w 刀年薪的大数据架构师会冷笑一声，转手启动本地的 Ollama。

既然手里握着 M4 Pro + 48GB 统一内存 这种物理外挂，还去卷那几个被限流的 API Token？格局小了。今天我们就把这台 Mac 榨干，实现 AI 自由。

一、 架构转型：从“伸手党”到“私有云”

云端 API 是“租房”，本地模型才是“豪宅”。我们把 Continue 的配置从不稳定的 Gemini 切换到了 Qwen3-Coder-30B。

架构核心逻辑：

  • 大脑 (Chat/Agent)： 采用 30B/32B 级别的模型（如 Qwen3 或 DeepSeek R1）。它们有足够的参数规模来理解 Flink 的状态管理或 TiDB 迁移 OceanBase 的复杂 DDL。
  • 神经反射 (Tab Autocomplete)： 采用 7B/8B 级别的模型。补全要求的是毫秒级响应，大模型会卡顿，小模型才是“手速王”。
  • 感知系统 (RAG/Embeddings)： 使用本地的 nomic-embed-text。不走网络，直接在本地对千万行大数据代码进行向量化处理。
{
  "models": [
    {
      "title": "Qwen3 Coder 30B",
      "provider": "ollama",
      "model": "qwen3-coder:30b"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Qwen3 Coder 30B",
    "provider": "ollama",
    "model": "qwen3-coder:30b"
  },
  "embeddingsProvider": {
    "provider": "ollama",
    "model": "nomic-embed-text"
  }
}

二、 避坑指南：48GB 内存如何“不炸裂”？

很多老哥担心 30B 加上 32B 同时跑，内存会当场去世。作为架构师，我们要懂得 “时间换空间” 和 “按需加载”：

  1. Ollama 的“渣男”策略：它默认只在内存里保留模型 5 分钟。当你从 Qwen 切换到 DeepSeek 时，它会自动踢掉前任，腾出显存。
  2. 资源隔离：大数据容器（Kafka/Flink/MySQL）建议限制在 12GB 以内，给我们的 AI 大脑留足 30GB+ 的呼吸空间。
  3. 配置文件保护机制：IDEA 对 config.json 的“非项目文件保护”不是报错，是勋章。直接点击“确定”，那是通往自由的门票。

三、 极致性能优化：过滤掉那些“代码噪音”

如果你不配置 .continueignore，你的 AI 就会像个没头苍蝇一样去索引 target/ 里的字节码和 node_modules 里的垃圾。

架构师的素养： 在项目根目录创建一个 .continueignore，把 target/、.m2/、.gradle/ 通通拉黑。让 AI 只关注你的业务核心逻辑。这不仅是提速，更是降低 RAG 检索的信噪比。

四、 生产力实战：别让 Agent 模式“磨洋工”

虽然 30B 模型很强，但在调用 create_new_file 这种工具时偶尔会“翻车”（出现红色 X）。

高阶姿势：

  • 别死磕 Agent：如果它创建文件失败，直接 Cmd + I (Inline Edit)。
  • 指哪打哪：先建个空文件，按 Cmd + I 丢下一句“基于 Codebase 帮我写个 README”，看着它瞬间填满屏幕，这种掌控感才是架构师该有的快乐。

五、 核心资产分析：我的项目长啥样？

在这一系列的调优之后，我让这个“核动力” AI 对我当前的项目结构进行了深度拆解。以下是它的分析报告：

📂 项目结构深度解析报告 (Project Structure Analysis)

项目名称

这是一个基于大数据流处理的项目，用于处理从Kafka到Milvus的数据流。项目包含多个模块，专门用于实时数据处理和向量数据库操作。

## 项目结构

.
├── dataflow/ # 数据生成模块
│ └── user_click_gen_data.py # 用户点击数据生成脚本
├── datastream/ # 核心数据流处理模块
│ ├── kafka2milvus/ # Kafka到Milvus数据流处理
│ ├── employee-message-processor/ # 员工消息处理器
│ └── realtime-riskcontrol-embedding-job/ # 实时风险控制嵌入作业
├── pom.xml # 项目根POM文件
├── build.sh # 构建脚本
├── docker-compose.yml # Docker容器编排配置
├── schema.sql # 数据库模式定义
└── requirements.txt # Python依赖列表


## 核心模块说明

### datastream/kafka2milvus/
这是项目的核心模块，负责处理从Kafka接收数据并将其写入Milvus向量数据库的完整数据流处理流程。

主要组件：
- `Main.java` - 项目主入口点
- `AsyncEmbeddingFunction.java` - 异步嵌入函数，用于数据转换
- `VectorEmbeddingPipeline.java` - 向量嵌入流水线，负责数据流处理

### datastream/employee-message-processor/
员工消息处理器模块。

### datastream/realtime-riskcontrol-embedding-job/
实时风险控制嵌入作业模块。

## 依赖说明

项目使用Maven进行依赖管理，主要依赖包括：
- Kafka客户端
- Milvus Java SDK
- Apache Flink/Spark (根据具体实现)
- 序列化库（JSON、Protobuf等）
- 日志框架

## 构建说明

```bash
# 构建项目
./build.sh

# 或使用Maven
mvn clean install

## 部署说明

项目使用Docker容器化部署，通过`docker-compose.yml`文件进行编排。

## 贡献指南

欢迎提交Issue和Pull Request来改进项目。

## 许可证

[项目许可证信息]

结语

当你把 Continue、Ollama 和 M4 Pro 完美缝合的那一刻，你不再是一个在云端卑微乞求 API 额度的开发者，你就是那个掌控一切代码流向的上帝。

Discuss on Twitter • View on GitHub