Tabby：给团队的代码补全和问答，接上自己的仓库与文档

团队项目里有自己的接口封装、错误码约定和开发说明。通用代码助手知道语言语法，却未必知道这些惯例。Tabby 值得从这里认识：它是可以自托管的编程助手，而它的 Context Providers 负责把团队材料接进补全、聊天和搜索。

项目 README把自托管、OpenAPI 和编辑器接入作为基础能力。对工程团队而言，更需要继续看的问题是：装好一个服务后，它怎样拿到与自己项目有关的上下文？

源码和开发文档，各自补一块信息

官方上下文文档将材料分为源码仓库和开发文档两类。前者连接 Git、GitHub、GitLab 等来源，取回源码，以及相应的 PR、MR、issue、提交等协作材料，再解析并进入索引，用于代码补全、聊天和搜索。

这条路径适合项目内部的实现问题。比如，“同类接口都怎样处理分页？”这个教学问题需要的是当前仓库已有做法，而不只是模型凭通用经验写一份新封装。仓库上下文让助手有机会先找到已有模式，再组织建议；是否找对，仍能回到对应代码核对。

开发文档补的是另一类材料：约定可能没有完整写在函数里，而是放在说明站点。文档接入后，可以在聊天中按 @ 选择希望纳入的内容。你因此能更明确地把某份协议说明与代码问题放到一起，而不是希望助手自动猜到该看哪一个网页。

添加仓库后，Tabby 会启动取回和索引任务。文档介绍了 Jobs 日志与 Code Browser，可以查看处理是否完成，以及服务当前看到了哪个仓库。若没有构建索引，只安装编辑器插件并不会自动拥有整个团队的知识。

开发文档也有取材方式的区别：通常使用 Katana 抓取；站点提供 llms.txt 时，会直接获取其中指定的文档。Docker 镜像预装 Katana，非 Docker 部署则需要另行安装。这些条件只在你确实要接文档时才需要准备。

文档同时描述了管理页面和配置文件路径，但有一处很关键：对于 Tabby OSS，添加仓库要通过 ~/.tabby/config.toml，不能看到管理 UI 截图，就认为开源版安装后拥有所有同样的入口。配置中的仓库名和 Git URL 决定服务要处理的材料。

本地仓库也能通过 file:// 引用；如果服务在容器里运行，路径必须在容器内可见。这是文件可达性问题，换一个提示词解决不了。

Tabby 根许可将开源部分置于 Apache-2.0 下，但 ee/ 企业目录与第三方组件另有许可，不能把整仓所有功能都视为同一开源授权。模型选择、模型许可与运行硬件仍需单独判断。README 里的旧型号示例说明如何启动服务，不适合直接当成今天所有团队的配置建议。

我会把 Tabby 放在“希望自己掌握服务部署，并且愿意维护工程上下文”的团队选项里。先接一个实际仓库，再用一份确有用的开发文档补约定，确认助手能围绕这些材料工作，才比只比较补全按钮更接近选型问题。