1. 项目概述Machtiani一个能与你的代码库深度对话的本地AI助手如果你和我一样每天都要面对一个拥有数千次提交、数万行代码的庞大项目那么你一定理解那种在代码海洋中寻找特定逻辑或修复一个陈年Bug时的无力感。传统的全局搜索grep和代码导航工具如ctags在理解代码的语义和上下文关联上显得力不从心而直接向ChatGPT或Claude提问又常常因为无法提供完整的项目上下文而得到泛泛的、甚至错误的答案。更别提那些按Token计费的云端模型一次深入的代码分析可能就会让你的账单数字跳动得心惊肉跳。Machtiani简称mct就是为了解决这个痛点而生的。它不是一个简单的代码补全工具而是一个基于终端的、本地运行的代码聊天服务。它的核心思想非常直接将你的整个Git仓库——包括所有的提交历史、文件结构和代码变更——转换成一个可供大型语言模型LLM高效查询的“知识库”。当你提出一个问题时mct不是盲目地将整个代码库扔给模型而是像一位经验丰富的资深开发者一样先通过智能检索从浩如烟海的提交记录和文件中精准地找到与问题最相关的代码片段和上下文然后再将这些“精华”喂给LLM让它基于最精确的信息来生成答案或修改。这带来的好处是革命性的。首先成本急剧下降。因为每次交互只发送最相关的上下文而非整个文件或目录Token消耗可能只有传统方法的十分之一甚至百分之一。其次答案质量显著提升。模型基于确切的、有历史脉络的代码进行推理生成的代码建议更符合项目规范修复方案也更精准。最后完全的隐私和可控。所有数据代码、生成的嵌入向量都留在你的本地机器上只有向LLM API发送的查询请求会离开本地如果你使用云端API的话你甚至可以使用完全本地的模型如通过Ollama或MLX-LM实现彻底的离线操作。简单来说mct让你能够“与你的代码历史对话”。你可以问它“上次修改用户认证逻辑是在哪次提交当时为什么要那么改”或者直接下达指令“为/api/users端点添加请求速率限制。”它会理解你的项目找到正确的文件并生成一个可以直接应用的Git补丁。2. 核心设计思路为什么是“提交历史”而非“当前文件”很多代码AI工具聚焦于分析当前工作目录下的文件。mct选择了一条更深刻但也更复杂的路径以Git提交历史作为核心数据源。这个设计决策背后有深刻的工程考量也是它区别于其他工具的关键。2.1 提交历史是代码的“活文档”一个文件的当前状态只是一个静态的快照。而它的Git提交历史则是一部动态的“传记”记录了每一次变更的原因提交信息、内容差异和上下文关联的文件。当我们需要理解一段代码时知道“它为什么被写成这样”往往比知道“它现在是什么样”更重要。一个TODO注释可能已经存在了两年但查看历史你会发现当初因为一个紧急的线上Bug而搁置了重构计划。mct通过分析提交历史能够捕捉到这种隐藏在时间线中的逻辑和决策脉络。2.2 实现精准的上下文检索mct的工作流程可以拆解为两个核心阶段索引Sync和查询Chat。在索引阶段mct sync它会遍历你指定的Git提交。对于每个提交它不仅会提取提交信息和变更的文件列表更关键的是它会使用一个嵌入模型Embedding Model将提交的语义内容通常是提交信息加上变更文件的路径转换为一个高维向量Vector并存储在本地的向量数据库中。这个过程就像是给你的每一个提交都打上了一个独特的、基于语义的“指纹”。在查询阶段mct “你的问题”当你提出一个问题时mct会做以下几件事问题向量化将你的问题文本同样转换为一个向量。向量相似度搜索在本地向量数据库中快速查找与问题向量最相似的若干个提交向量。这就是所谓的“语义搜索”它找的不是关键词匹配而是意思相近的内容。上下文组装获取这些最相关提交的详细信息包括完整的差异内容。mct的聪明之处在于它不会把整个提交的庞大差异全部扔给LLM。它会进行一轮“精炼”可能只提取差异中与当前问题最相关的几个代码块Hunk。构造最终提示词将精炼后的代码上下文、你的问题以及具体的指令例如“请生成一个Git补丁来修复这个问题”组合成一个结构化的提示词发送给配置的LLM如GPT-4o-mini、Claude 3.5 Sonnet或本地模型。解析与执行解析LLM返回的结果。如果是在默认的commit模式下并且LLM返回了有效的代码修改建议mct会尝试将这些建议格式化成Git可以应用的补丁Patch并询问你是否要应用。注意mct默认的commit模式是只读的。它生成的补丁需要你手动确认git apply或通过mct本身来应用。它不会未经允许直接修改你的源文件。这种设计保证了操作的安全性让你有机会审查AI生成的代码。2.3 与“纯聊天”工具的本质区别市面上很多工具也能让你“与代码聊天”但它们通常有两种方式一是上传整个项目文件成本高、隐私差、有大小限制二是让模型基于有限的上下文“猜”。mct通过本地向量检索在精度和效率之间取得了绝佳的平衡。它让强大的LLM能够专注于它最擅长的部分——基于给定的精确上下文进行推理和生成而不是在庞大的、无关的信息中挣扎。3. 从零开始环境准备与安装部署理论很美好现在让我们动手把它跑起来。整个过程大致分为三步安装mct命令行工具、启动本地聊天服务、配置你的第一个项目。3.1 安装mctCLI 工具mct本身是一个用Go编写的命令行工具它的安装依赖于Go语言环境。第一步确保系统已安装Go你需要Go 1.21或更高版本。可以通过go version命令检查。如果未安装请访问 Go官网 下载并安装。第二步克隆仓库并安装打开终端执行以下命令# 克隆项目注意要递归克隆子模块 git clone --recurse-submodules https://github.com/tursomari/machtiani cd machtiani进入项目后安装mct命令cd mct go install \ -ldflags$(go run ./generate_ldflags) \ ./cmd/mct cd -这条命令做了两件事1. 编译mct2. 通过一个辅助脚本generate_ldflags将当前的Git提交哈希注入二进制文件方便后续版本检查。第三步配置PATH安装后mct可执行文件会出现在$(go env GOPATH)/bin目录下。你需要确保这个目录在你的系统PATH环境变量中。# 临时添加到当前shell会话的PATH export PATH$PATH:$(go env GOPATH)/bin # 永久添加推荐将上面这行添加到你的shell配置文件如 ~/.bashrc, ~/.zshrc中 echo export PATH$PATH:$(go env GOPATH)/bin ~/.zshrc source ~/.zshrc现在运行mct --help如果看到帮助信息说明CLI工具安装成功。3.2 启动本地聊天服务后端mctCLI工具是前端它需要与一个本地运行的后端服务通信。这个后端服务负责管理向量数据库、处理Git仓库数据等。项目使用Docker Compose来一键启动这个后端。前提安装Docker和Docker Compose确保你的系统已经安装了Docker和Docker Compose。这是运行后端服务的必要条件。启动服务在machtiani项目的根目录即包含docker-compose.yml文件的目录下运行docker-compose up --build --remove-orphans--build参数确保使用最新的代码构建镜像--remove-orphans会清理旧的、不再使用的容器。第一次运行会花费一些时间下载基础镜像和构建项目镜像。看到日志输出显示服务已启动并监听某个端口通常是8080时就表示后端服务已经就绪。实操心得建议在后台运行这个服务以免占用一个终端窗口。可以使用docker-compose up -d在后台启动用docker-compose logs -f查看实时日志用docker-compose down停止服务。3.3 关键配置API密钥与模型端点要让mct能够调用LLM你需要告诉它使用哪个模型以及如何连接。mct兼容任何遵循OpenAI API格式的提供商这给了你极大的灵活性。配置方式二选一环境变量推荐更灵活直接在终端中设置。配置文件方便可管理创建一个YAML配置文件。以使用OpenAI官方API为例环境变量方式export MCT_MODEL_BASE_URLhttps://api.openai.com/v1 export MCT_MODEL_API_KEYsk-your-openai-api-key-here如果你使用其他兼容OpenAI API的提供商比如OpenRouter一个聚合了众多模型的平台export MCT_MODEL_BASE_URLhttps://openrouter.ai/api/v1 export MCT_MODEL_API_KEYsk-your-openrouter-api-key-here如果你的项目托管在私有Git仓库如GitHub Private Repomct在同步sync时需要克隆你的仓库。如果仓库是私有的你需要提供访问凭证。export CODE_HOST_API_KEYghp-your-github-personal-access-token-here这个环境变量名是通用的CODE_HOST_API_KEY意味着它也适用于GitLab、Bitbucket等任何需要认证的代码托管平台。配置文件方式如果你不想每次打开终端都设置环境变量可以创建配置文件。mct会按以下优先级查找配置当前项目根目录下的.machtiani-config.yml用户家目录下的~/.machtiani-config.yml创建一个~/.machtiani-config.yml文件内容如下environment: MCT_MODEL_BASE_URL: https://api.openai.com/v1 MCT_MODEL_API_KEY: sk-your-openai-api-key-here # CODE_HOST_API_KEY: ghp-your-token # 如果需要再取消注释环境变量的优先级高于配置文件。如果同时设置了环境变量则以环境变量为准。4. 核心工作流实战同步项目与开始对话配置好环境后我们就可以开始真正的“人码对话”了。整个工作流的核心是两个命令sync同步/索引和直接提问聊天。4.1 首次同步为你的代码库建立索引假设你有一个名为my-awesome-project的Git项目你想让mct理解它。cd /path/to/my-awesome-project mct sync --model gpt-4o-mini --model-threads 10让我们拆解这个命令sync: 告诉mct开始索引这个仓库。--model gpt-4o-mini: 指定用于处理提交信息的LLM。这里有一个非常重要的成本考量同步过程主要是让LLM理解提交信息并生成高质量的文本描述以供嵌入并不需要最强的推理能力。因此使用低成本、高速度的模型是明智之举。gpt-4o-mini是目前性价比极高的选择。--model-threads 10: 并发请求数。这能极大加快同步速度前提是你的API提供商允许足够的并发例如OpenRouter的并发数与账户积分相关。对于初次同步有大量提交的项目调高此值如50或100可以节省大量时间。同步过程发生了什么mct会获取你仓库的完整提交历史或通过--depth限制深度。对于每个提交它会用指定的LLM生成一段清晰的、概括性的描述。将这些描述通过嵌入模型如sentence-transformers转换为向量并存入本地的向量数据库服务启动时由Docker容器提供。进度和消耗的Token数会实时显示在终端。注意事项首次同步一个历史悠久的项目可能需要几分钟到几十分钟并产生一些API调用费用对于万次提交的项目使用gpt-4o-mini可能只需几美分。但这是一次性的投入。之后的增量同步只同步新的提交会非常快成本几乎可以忽略不计。你可以随时使用mct status命令来查看当前项目的同步状态和进度。4.2 开始对话提出你的第一个问题同步完成后你就可以像询问一位熟悉项目历史的同事一样提问了。基础提问mct “我们项目的用户登录模块最近一次修复安全漏洞的提交是什么具体改了哪里”mct会检索与“用户登录”、“安全漏洞”、“修复”最相关的提交将相关的代码差异作为上下文然后请求LLM总结出一个清晰的答案。请求代码修改默认commit模式mct “在utils/validation.py文件中为validate_email函数添加对国际化域名IDN邮箱地址的支持。”在这个模式下mct会尝试生成一个Git补丁。它会在终端输出补丁内容并询问你是否要应用这个补丁。务必仔细审查AI生成的代码确认无误后再应用。纯聊天模式chat模式如果你只想讨论代码而不希望mct直接生成补丁可以使用--mode chat。mct “帮我解释一下src/services/payment/processor.go里HandleWebhook函数的逻辑特别是错误重试机制。” --mode chat --model claude-3.5-sonnet这个模式适合代码审查、学习复杂逻辑或设计讨论。4.3 高级同步策略平衡成本与覆盖率对于超大型仓库一次性同步所有历史可能成本较高。mct提供了灵活的同步策略。1. 使用--depth限制同步深度只同步最近的N次提交这对于活跃项目通常足够了因为大部分问题都集中在近期代码中。mct sync --model gpt-4o-mini --model-threads 20 --depth 10002. 使用--amplify提高索引质量代价是更高成本--amplify参数让LLM对提交进行更详细、更高质量的分析生成更丰富的描述从而提升后续检索的准确性。它有off(默认)、low、mid、high几个级别。low: 成本约2倍速度稍慢。high: 成本约20倍速度慢5倍。适用于对检索精度要求极高的场景或提交信息非常模糊的情况。# 对最近的500次提交进行高质量同步确保核心代码的检索精度 mct sync --amplify high --depth 500 --model gpt-4o-mini --model-threads 103. 分阶段同步这是一个结合Git命令的实用技巧。比如你想对古老历史用普通同步对近期重要历史用高质量同步。# 第一步同步较老的历史例如从开头到5000次提交前 git checkout HEAD~5000 mct sync --model gpt-4o-mini --model-threads 15 # 第二步同步最新的、更重要的历史 git checkout main mct sync --amplify low --model gpt-4o-mini --model-threads 154. 仅估算成本--cost-only在真正执行同步前你可以先让mct估算一下需要多少Token做到心中有数。mct sync --cost-only --model gpt-4o-mini --depth 50005. 模式解析与组合技让mct与codex强强联合mct的设计哲学是“做好一件事”——即深度理解代码库并精准检索上下文。它并不试图成为一个全能的、能执行任意命令的AI Agent。相反它鼓励与其它优秀的命令行工具组合使用发挥各自特长。官方文档中特别提到了与codex一个专注于代码执行、重构和测试的AI命令行工具的搭配这是一种非常高效的“组合技”。5.1 理解不同的--modemct有三种主要的操作模式通过--mode参数指定commit(默认)这是全能模式。mct会检索相关提交上下文并请求LLM生成一个可应用的Git补丁。它专注于“代码变更”。chat对话模式。mct会检索上下文并与LLM对话但不会生成或应用补丁。输出是纯文本回答适合咨询、解释、讨论。answer-only答案模式。这是为组合使用设计的“管道”模式。mct会进行检索和思考但最终输出的是一个极度精简、结构化的“行动计划”或“答案摘要”不包含任何对话式的废话。这个输出可以直接作为另一个工具如codex的输入。5.2 与codex的组合实战设想一个场景你需要为一个大型项目添加全面的API调用错误处理。如果只用mct(默认commit模式)mct会找到所有需要进行错误处理的API相关文件并尝试生成一个庞大的、涉及多个文件的补丁。这对于复杂的、跨模块的修改来说成功率可能不高因为LLM一次性处理太多上下文容易出错。如果只用codex你需要手动为codex提供非常精确的指令和文件上下文否则它可能无法理解项目的具体结构导致生成的代码不匹配。组合方案让mct做“战略规划”codex做“战术执行”。# 步骤1用 mct 分析问题并生成一个精炼的“改造计划” PLAN$(mct “为项目中所有的外部API调用添加统一的错误处理和重试逻辑” --mode answer-only --model Qwen2.5-Coder-7B-Instruct-Q6) echo “$PLAN”--mode answer-only会让mct输出类似这样的内容目标为所有外部API调用添加错误处理。 涉及文件 - src/services/payment/gateway.go (函数: ChargeCard) - src/services/auth/provider.go (函数: ValidateToken) - src/clients/email/sender.go (函数: SendWelcomeEmail) 建议方案 1. 在 pkg/utils/retry.go 中创建通用重试函数 RetryWithBackoff。 2. 修改上述三个文件用 RetryWithBackoff 包裹API调用。 3. 定义标准错误类型 APIError 于 pkg/errors/api.go。步骤2将这个清晰的计划交给codex去具体实现。# 假设 codex 命令可以接受一个计划文件或字符串来执行 codex --execute-plan “$PLAN” --model o1-mini这里mct利用其对代码库的深度理解完成了最困难的“定位问题”和“制定方案”工作产出了一个精准、低Token消耗的计划。然后codex利用其强大的代码生成和执行能力接收这个明确的指令高效地完成代码编写和测试。这种分工带来了多重好处成本最优昂贵的、需要深度推理的模型如mct可能使用的Qwen2.5-Coder只用于小规模的规划而执行任务可以由更快或更便宜的模型如o1-mini完成。质量更高每个工具都做自己最擅长的事避免了让一个模型“既当元帅又当兵”可能产生的混乱。流程更可靠清晰的计划使得整个自动化过程更可控、更易于调试。6. 高级配置、问题排查与实战技巧掌握了基本操作后一些高级配置和实战中遇到的“坑”能让你用得更顺手。6.1 忽略文件配置你的项目里肯定有一些文件是不需要被mct索引和检索的比如依赖锁文件package-lock.json,poetry.lock、二进制文件、构建产物等。让这些文件进入检索系统只会增加噪音和消耗资源。在项目根目录创建一个名为.machtiani.ignore的文件语法类似于.gitignore# 依赖锁文件 package-lock.json yarn.lock pnpm-lock.yaml Cargo.lock go.sum poetry.lock Pipfile.lock # 构建输出和依赖目录 node_modules/ dist/ build/ *.pyc __pycache__/ target/ *.class # 环境配置和机密文件 .env .env.local *.pem *.key # 文档和媒体通常不需要代码分析 *.pdf *.md images/ *.png *.jpg在运行mct sync之前配置好这个文件被忽略的文件将不会被处理。6.2 使用本地模型完全离线对于代码安全要求极高的场景你可以配置mct使用完全在本地运行的LLM。方案一通过 Ollama (跨平台)Ollama是目前运行本地模型最方便的工具之一。首先在本地启动Ollama服务并拉取一个适合代码的模型比如deepseek-coderollama run deepseek-coder:6.7b然后将mct的配置指向本地的Ollama服务它兼容OpenAI APIexport MCT_MODEL_BASE_URLhttp://localhost:11434/v1 export MCT_MODEL_API_KEYollama # Ollama通常不需要key但有些客户端要求非空可以任意填现在你的mct sync和聊天请求都将使用本地的deepseek-coder模型所有数据不出本地。方案二通过 MLX-LM (macOS Apple Silicon 优化)如果你使用的是苹果M系列芯片的MacMLX-LM能提供极佳的本地推理性能。你需要按照其文档搭建一个兼容OpenAI API的服务器然后将MCT_MODEL_BASE_URL指向该服务器地址。6.3 常见问题与排查实录问题1执行mct sync时卡住或报错“连接失败”。检查后端服务确保docker-compose up正在运行并且没有报错。尝试用curl http://localhost:8080/health端口可能不同查看docker-compose日志确认检查服务是否健康。检查网络和代理如果你在公司网络或使用了代理确保Docker容器能访问外部网络用于调用LLM API。可能需要配置Docker的代理设置。检查API密钥和URL确认MCT_MODEL_BASE_URL和MCT_MODEL_API_KEY设置正确。可以先用curl命令测试一下API端点是否可连通。问题2mct检索的上下文似乎不相关。检查同步质量如果同步时使用了--amplify off默认且提交信息很简略如“fix bug”生成的嵌入向量质量可能不高。尝试对项目重新进行--amplify low的同步。调整--match-strength在提问时使用--match-strength high。这个参数控制检索时返回的上下文片段与问题的匹配强度。“high”会更严格返回更少但可能更相关的片段“low”则更宽松返回更多可能相关的片段。对于模糊的问题可以尝试low。优化你的提问像对待搜索引擎一样对待mct。使用更具体的关键词例如“修改用户登录函数以添加双因素认证”而不是“怎么加2FA”。问题3生成的补丁无法应用git apply失败。代码冲突这是最常见的原因。AI生成的补丁是基于它检索到的某个历史版本的文件上下文。如果你的本地文件在相关区域已经发生了修改就会产生冲突。务必在应用前审查补丁。mct通常会在生成补丁后提示你查看你可以将其保存到文件.patch然后用git apply --check file.patch检查或用git apply --3way file.patch尝试三方合并。上下文不足如果问题涉及的文件或函数在提供的上下文中信息不全LLM可能会“编造”Hallucinate出错误的代码结构。尝试使用--mode chat先进行讨论确保LLM理解了正确的代码结构或者手动提供更精确的文件路径在问题中。问题4增量同步mct sync没有识别到新的提交。确保本地提交已推送mct sync是基于远程仓库origin进行同步的。如果你只在本地commit但没有pushmct是感知不到的。这是一个设计上的约束保证了所有协作者基于同一套远程历史进行索引。检查远程仓库URLmct目前主要支持HTTP/HTTPS格式的远程仓库URL。如果你的远程仓库使用的是SSH地址如gitgithub.com:...可能需要先在本地将其改为HTTPS格式或者确保你的SSH密钥能被git命令在无交互情况下使用这通常需要ssh-agent。问题5Token消耗比预期高很多。检查.machtiani.ignore文件确保大型的、无意义的文件如node_modules已被忽略。避免使用“重型”模型进行同步反复强调同步请务必使用gpt-4o-mini、claude-3-haiku这类轻量、快速的模型。用gpt-4o或claude-3.5-sonnet来跑sync是极大的浪费。使用--cost-only先进行估算在对大型仓库或使用--amplify high前先用此命令估算成本。将mchtiani集成到你的日常开发工作流中它更像是一个随时待命的、拥有“项目记忆”的超级助手。我个人习惯在开始一项新功能或修复一个复杂Bug前先用mct做一次“代码考古”快速理清历史脉络和现有模式。在代码评审时我也会让mct帮我分析被修改代码的原始意图这常常能发现一些隐藏的设计问题。最重要的是它改变了我和代码库的交互方式——从被动的“搜索-阅读”变成了主动的“提问-解答”这种体验上的提升远比节省的那点Token费用更有价值。