标签 Tree-sitter 下的文章

目前市面上的本地 Markdown 编辑器,大多在文件规模变大后性能急剧下降。字数一多,输入卡顿、CPU 飙升,编辑体验直线下滑,几乎不可用。

最近在研究 tree-sitter ,基于它实现了一个 Markdown 增量解析器,效果比预期好很多:

  • 200 万字符(约 10 万行)全量解析:约 200ms
  • 增量解析(插入 1 个字符):仅 10–20ms
  • 生成的 CST 并非 AST

也就是说,在超大文档场景下,依然可以做到接近实时的解析和响应;配合上 CST 可以执行格式化等一些列操作。


目前的想法是使用 Qt5 + WebView2 ,做一款跨平台的本地 Markdown 增量编辑器,核心目标:

  • 不管文件多大,编辑都要丝滑
  • 轻量级,安装包控制在 10-20mb
  • WYSIWYG 和 代码模式

想请教下大家:
你们在 Markdown 编辑器里,是否遇到过「大文件卡顿」的问题?

这样的产品,还有没有市场和实际需求?

项目链接:GitHub - hsingjui/ContextWeaver: ContextWeaver 是一个基于 MCP 协议、利用 Tree-sitter 和向量搜索为大语言模型提供本地代码库智能上下文编织与检索的工具。

augment code 的账号太难注册了,注册了就封,从海鲜市场买别人注册好的号也是几天就封了,augment context engine 又很好用,只能试试看能不能做一个平替了

项目使用方式

  1. 安装
# 全局安装
npm install -g @hsingjui/contextweaver

# 或使用 pnpm
pnpm add -g @hsingjui/contextweaver
  1. 配置
# 初始化
contextweaver init
# 或者简写
cw init

#修改 `~/.contextweaver/.env`

EMBEDDINGS_API_KEY=your-api-key-here
EMBEDDINGS_BASE_URL=https://api.siliconflow.cn/v1/embeddings
EMBEDDINGS_MODEL=BAAI/bge-m3
EMBEDDINGS_MAX_CONCURRENCY=10
EMBEDDINGS_DIMENSIONS=1024

RERANK_API_KEY=your-api-key-here
RERANK_BASE_URL=https://api.siliconflow.cn/v1/rerank
RERANK_MODEL=BAAI/bge-reranker-v2-m3
RERANK_TOP_N=20

这里 EmbeddingReranker 模型用的硅基流动免费的模型,用 Qwen/Qwen3-Embedding-8BQwen/Qwen3-Reranker-8B,效果好一些,但是速度会慢一点

  1. 索引代码库
#这一步不是必须的,使用mcp搜索的时候,如果没有索引代码库会自动索引 # 在代码库根目录执行
contextweaver index

# 指定路径
contextweaver index /path/to/your/project

# 强制重新索引
contextweaver index --force
  1. 使用 mcp
{
  "mcpServers": {
    "contextweaver": {
      "command": "contextweaver",
      "args": ["mcp"]
    }
  }
}

claude code 使用

claude mcp add contextweaver -- command contextweaver mcp

这是项目的工作流程

下面是图一乐的用 claude codenew-api 的仓库对比 aceContextWeaver 的结果,仅供参考
使用的 prompt

任务:对比 Ace 和 ContextWeaver 在当前项目中的 Codebase Retrieval (代码库检索) 效果。
请执行以下步骤进行 A/B 测试:
设定三个测试问题:使用问题 "[请在此处填入具体的复杂技术问题,例如:如何修改鉴权逻辑以支持JWT?]" 作为基准。
分别检索:
场景 A (Ace):调用 Ace 的检索能力,列出其提取的关键文件和代码片段。
场景 B (ContextWeaver):调用 ContextWeaver 的检索能力,列出其提取的关键文件和代码片段。
对比分析:请基于以下维度创建一个对比表格:
相关性 (Precision):检索到的文件是否直接解决了问题?是否有核心文件遗漏?
噪音干扰 (Noise):是否包含了大量无关的测试文件或通用配置?
上下文完整度 (Context):是否提供了足够的上下文(如引用链路、类型定义)来理解代码?
结论:基于当前项目的代码结构,通过三个测试问题,指出哪一个工具的检索策略更优。

📌 转载信息
原作者:
hsingjui
转载时间:
2025/12/29 15:10:29