可自托管的开源代码补全服务——这是 Tabby 最主要的用途，也是本文讨论的前提。

当数据不能离开公司或个人设备时，就需要考虑自托管或开源路线。

先判断：它能不能自托管

它本身是开源项目，可以自托管：数据留在自己的机器上，但升级、安全补丁与故障排查都要团队自己承担。

决策要点

  • 数据敏感级别：只有内部公开信息时，云端服务通常更省事。
  • 团队是否有人负责运维和安全更新。
  • 硬件投入：本地运行模型需要显卡或较大的内存。
  • 效果差距：用自己的任务实测，不要只看榜单。

可以评估的开源方向包括：Zed 编辑器 AI、Gemini CLI、Roo Code。它们与 Tabby 的能力并不完全等同，适合用来承接对数据要求最高的那部分任务。

用同一个任务做对比

修复报错

适用情况：手头有一段报错堆栈和相关代码时。

这是报错信息和相关代码。请先解释报错原因，给出最小修改方案，并说明为什么这个修改不会影响其他调用方。

检查点：修改范围足够小。

自托管上线清单

  • 固定版本号并记录配置。
  • 只在内网暴露服务或加上认证。
  • 设置日志与资源监控。
  • 订阅仓库的版本发布与安全公告。
  • 准备回滚方案。

延伸练习

读懂陌生代码库

输入：一个刚接手的项目仓库。

先不要改任何代码。请阅读这个仓库，输出：1）目录结构说明；2）主要模块之间的调用关系；3）本地运行步骤；4）你认为最脆弱的 3 个地方。

检查点：运行步骤能实际跑通。

小功能开发

输入：一个清晰的需求描述。

实现以下需求：【需求】。要求：先给出实现计划和要改动的文件列表，等我确认后再写代码；遵循现有代码风格；补充必要的测试。

交付前确认：先有计划再动手。

代码审查

准备材料：一个 Pull Request 的改动。

审查这个改动，按「必须修改 / 建议修改 / 可以忽略」三级列出问题，每条附上文件和行号，重点关注安全、并发和错误处理。

交付前确认：问题定位到行。

常见问题：AI 改动范围过大

要求先给计划和文件清单，限定只改指定文件。

常见问题：泄露密钥的风险

把密钥放在环境变量，规则文件中禁止读取 .env 等敏感文件。

常见问题：测试全绿但功能不对

人工补充关键用例，检查测试是否真正断言了结果。

概念补充：差异审阅

在接受 AI 修改前逐个查看 diff，是最重要的安全习惯。

概念补充：规则文件

放在仓库里的说明文件，告诉 AI 项目约定和禁止事项。

适合人群：设计师

设计师可以用 Tabby 处理灵感与草图、多尺寸物料适配等工作。需要注意：确认生成素材与字体的商用授权，客户未公开的项目不要上传。

适合人群：游戏开发者

游戏开发者可以用 Tabby 处理原型与素材、NPC 对话与文案等工作。需要注意：关注生成素材的授权和平台对 AI 内容的披露要求。

写在最后

文中提示词和示例仅作示意，实际效果取决于你的材料和 Tabby 当前版本，重要内容请人工核对后再使用。

所有示例输出均为示意，不代表真实统计或效果承诺；请以自己的测试结果为准。

延伸阅读