Show HN：LuckyCLI 终端编码助手，具备原生的 Tree-sitter 知识图谱
1 分•作者: Fenix46•26 天前
我一直在开发 LuckyCLI，一个用 TypeScript 编写的基于终端的人工智能编码助手。其核心理念源于一个痛点：大多数助手要么将你锁定在单一提供商，要么在你切换时立即丢失上下文。
我专注于两个尚未在其他地方结合的方面：
* **基于知识图谱的 Tree-sitter** — LuckyCLI 不会将原始文件直接放入上下文，而是构建一个结构化的代码库图谱（包括函数、类、导入、调用关系）。代理在将任何内容发送给模型之前，会查询该图谱以确定哪些内容实际上是相关的。系统提示经过专门调整，以配合这种表示方式，从而使模型能够基于结构进行推理，而不仅仅是文本。
* **聊天中切换提供商** — 如果你已经与多个提供商（Claude、ChatGPT、Gemini、Ollama 等）进行了身份验证，你可以在会话中切换，而不会丢失对话或项目上下文。身份验证通过浏览器 OAuth 处理，因此订阅制提供商无需 API 密钥。
近期工作：修复了 TUI（之前比较粗糙，现在已经很稳定），改进了工具调用处理，并优化了提供商切换流程，使其真正无缝。
GitHub：<a href="https://github.com/Fenix46/LuckyCLI" rel="nofollow">https://github.com/Fenix46/LuckyCLI</a>
我很乐意回答关于架构、知识图谱设计或 OAuth 方法（我知道这是一个值得公开讨论的灰色地带）的问题。
查看原文
I've been building LuckyCLI, a terminal-based AI coding agent written in TypeScript. The core idea started from a frustration: most agents either lock you to one provider or lose context the moment you switch.
Two things I focused on that I haven't seen combined elsewhere:
Knowledge graph with tree-sitter — instead of dumping raw files into context, LuckyCLI builds a structured graph of your codebase (functions, classes, imports, call relationships). The agent queries the graph to decide what's actually relevant before sending anything to the model. System prompts are tuned specifically to work with this representation, so the model reasons about structure, not just text.
Mid-chat provider switching — if you're already authenticated with multiple providers (Claude, ChatGPT, Gemini, Ollama, and others), you can switch mid-session without losing the conversation or project context. Auth is handled via browser OAuth, so no API key required for the subscription-based providers.
Recent work: fixed the TUI (it was rough, now it's solid), improved tool call handling, and polished the provider-switching flow so it actually feels seamless.
GitHub: <a href="https://github.com/Fenix46/LuckyCLI" rel="nofollow">https://github.com/Fenix46/LuckyCLI</a>
Happy to answer questions about the architecture, the knowledge graph design, or the OAuth approach (which I know is a grey area worth discussing openly).