如何判断当前有哪些 Tabnine 指南正在生效（2026版指南）

Tabnine 基于文件的指南部分与其他工具的行为类似。它们是 /.tabnine/guidelines/ 目录下的 Markdown 文件，该目录“将存在于 1) 你的用户主目录中，或 2) 存在于你的项目目录中（按项目划分）”。你可以保存多个指南文件，而 Tabnine 官方的表述只是一种类比，而非标准：“可以把这些文件想象成其他智能体工具使用的 agents.md 文件。”请注意，这只是一个类比——文件名并不是 AGENTS.md，包含该文件的仓库也不会自动将其喂给 Tabnine。此外还有一个文件大小建议：“建议将你的 guidelines.md 文件保持在 500 行或以下。”

有三件事物存在于该目录之外，它们每一个都打破了“读取文件就能回答问题”的假设。

管理控制台（Admin Console）的优先级高于你的本地文件。 这是需要牢记的一句话：

“在此处输入的指南将与 guidelines.md 文件中列出的指南具有相同的效果，但它们的优先级高于 guidelines.md 文件中存在的个人指南。”

组织指南“适用于你组织的所有用户和项目”。因此，最具权威性的层级可能是你无法直接读取的，并且它的优先级高于你眼前的本地文件。如果你的本地指南说的是一套，而控制台说的是另一套，智能体遵循的将是控制台的版本——而你的代码仓库中没有任何记录能体现这一点。

存在一个传播窗口。 控制台的更改“将在 15 分钟后应用到 IDE 插件中，或者在重启 IDE 或插件时立即应用”。在管理员编辑指南后的长达一刻钟内，你的会话运行的仍是上一个版本。在这个时间窗口内，实际生效的指南集合既不匹配你的本地文件，也不匹配当前的控制台状态。这是导致两个配置完全正确的工程师在同一个提交（commit）上看到不同智能体行为的最常见、最易复现的原因。

CLI 使用两条独立的交付路径，且只有一条带有开关。 Tabnine 的 CLI 文档一开头就警告称，“Tabnine CLI 中管理智能体指南的方式与 Tabnine IDE 插件不同”，然后描述了两种工作流。

第一种：“组织指令和服务账户指令会被添加到智能体的运行上下文中。这些指令是由你的 Tabnine 管理员在 CLI 之外配置的。当 Tabnine CLI 启动时，它会获取你已认证账户的可用指令并将其应用到会话中。”服务账户指令“仅在为已认证的服务账户配置时才适用”。

第二种：通过内置的 Tabnine Coaching Guidelines 工具提供的编码指南，智能体可以在“编写代码、审查代码或回答关于团队标准的问题之前”查询该工具。

而对于我们的问题，最关键的一行是：

“这些工作流是独立的。组织指令和服务账户指令是从你的 Tabnine 账户上下文中自动获取的。而 Coaching Guidelines 设置仅控制内置的 Coaching Guidelines MCP 服务器。”

因此，你唯一能看到并切换的设置——通过 /settings 对话框访问的 enableCoaching——只控制这两条路径中的一条。文档明确指出，“此设置并不控制是否获取组织或服务账户指令并将其添加到会话上下文中”。关闭它并不能给你一个无指南的会话；它只是关闭了其中一条路径，而另一条路径依然敞开。

设计上，失败是静默发生的。 两种回退机制都会静默降级：“如果 Tabnine CLI 无法获取组织或服务账户指令，会话将在没有这些指令的情况下继续。如果你的 Tabnine 服务器不支持 Coaching Guidelines，则不会加载内置的 Coaching Guidelines 工具。”

没有任何报错。网络抖动、会话过期、服务器不支持该功能——智能体都会在没有提示信号的情况下，带着更小的指令集继续工作。这与我们在为什么智能体会忽略你的指令文件中描述的失败形式相同，只不过在这里，文件本身没有问题，失败的是获取过程。

这里需要澄清一点，因为“指南（guidelines）”在 Tabnine 的词汇表里承载了太多含义：以上所有内容都不属于 Tabnine 的记忆（memory）范畴。Tabnine 文档中提到了个性化（Personalization）、用于全局代码库感知的连接（Connection），以及包含资产、数据源、运行、分析器和辅导指南的管理员端上下文引擎（Context Engine）。这些都是拥有独立配置的独立机制；本指南仅针对在会话中塑造智能体行为的指南（guideline）层。

只阅读 guidelines.md 就觉得万事大吉。 这回答了错误的问题。该文件只告诉你你请求了什么，而不是实际应用了什么——而且控制台层明确拥有更高的优先级。

询问智能体它的指令是什么。 聊胜于无，Tabnine 也认可这种方法的狭义版本：“你也可以询问 Tabnine CLI，Coaching Guidelines 工具在当前会话中是否可用。”但请注意文档附带的限定条件——“这是一项实用性检查，而不是一个独立的查询状态命令”。它只告诉你某个工具是否看起来可用，而不是上下文中具体有哪些指南文本，并且对组织指令路径只字未提。

一旦发现不对劲就重启。 虽有效但无法证伪。重启可以立即应用控制台的更改，而无需等待 15 分钟，而且更改设置本身也需要重启——“更改此设置需要重启 Tabnine CLI”。但如果重启解决了问题，你只知道之前的数据过期了，却不知道具体是什么内容过期了。

让你的管理员把控制台内容读给你听。 来源正确，但频率不对——它只能为一个人回答一次问题，而控制台随时可能在不通知的情况下再次更改。

将控制台指南复制到本地文件中。 这种做法很有诱惑力，但会让冲突变得更糟。现在你有了两份副本，且它们之间有着文档明确规定的优先级顺序。当控制台版本发生变化时，你的本地副本就会变成一个“自信且错误”的记录。两个可能产生分歧且无法调和的记录，正是我们在检测记忆冲突中描绘的场景。

你无法直接查询生效的集合。但你可以列举其输入源，通过行为检测每一个输入源，并保留一份书面的预期记录进行对比。

步骤 1：按界面列举所有五个输入源

针对当前项目和当前机器，写下以下每个位置存在的内容：

项目目录的 .tabnine/guidelines/——其中的每一个文件，而不仅仅是 guidelines.md，因为系统支持多个文件。用户主目录的 .tabnine/guidelines/——同上，并注意这些文件适用于你的所有项目。管理控制台（Admin Console）的通用指南（General Guideline），由有权限查看的人提供，并附带最后修改日期。服务账户指令（如果会话是以服务账户而非你个人身份进行认证的）。以及来自 /settings 的 Coaching Guidelines 工具状态。

然后记录下你所询问的是哪个界面。控制台层可以同时触达两者——“在管理控制台中配置的指南适用于 CLI 会话，其方式与适用于 IDE 聊天会话的方式相同。CLI 端不需要额外的配置”——但 CLI 的双流模型和 IDE 的 15 分钟传播延迟是特定于界面的。同一个仓库在终端和编辑器中的行为可能会有所不同，这完全是正常的。

步骤 2：通过矛盾检测每个输入源

由于 Tabnine 将可用性检查描述为“一项实用性检查，而不是一个独立的查询状态命令”，因此你可以改用一条清晰无误且无害的指令来测试每个来源——例如你平时绝不会使用的命名规范，或者新函数上必须包含的注释头。

首先测试你的项目文件：添加标记，重启以跳过传播延迟问题，然后请求生成一个简单的函数。如果标记出现了，说明项目目录正在加载。

接下来测试控制台层：让你的管理员添加一个不同的标记，同时保留你项目文件中的标记。哪一个标记出现，就说明哪一层胜出——而 Tabnine 文档给出的答案是控制台。在自己的环境中验证这一点非常值得花上 10 分钟，因为这个事实最常与人们的直觉模型相冲突。

刻意测试一次传播窗口：让管理员更改控制台标记，并记录在不重启的情况下该更改何时生效。确认这个窗口的真实存在，能让你在下一次遇到分歧时直接进行诊断。

通过要求智能体进行基于指南的审查，来测试 CLI 的 Coaching Guidelines 路径。Tabnine 文档中描述的行为是：“如果你请求基于指南的审查，而当前没有可用指南，Tabnine CLI 应该告诉你它无法访问配置的指南，而不是胡编乱造规则。”坦率的拒绝是一个有用的信号。而需要警惕的则是静默发生并给出看似合理的输出。

步骤 3：保留一份在工具之外进行版本控制的书面预期记录

上述测试为你提供了一个快照。而让这个快照在下个月依然发挥作用的关键，是记录下答案应该是什么。

该记录需要具备三个属性。它必须存在于控制台之外，因为控制台是你无法从会话中直接读取的层级。它必须存在于 .tabnine/guidelines/ 之外，因为一旦控制台发生变化，权威文本的副本就会立即变成错误的记录。并且它必须能被每个界面读取，因为 CLI 和 IDE 汇集其集合的方式不同。

记录中包含的不是指南文本本身，而是围绕它的元数据：期望在组织级别强制执行哪些规则，哪些是个人规则，谁决定的，何时决定的，以及它替换了什么。这样，“哪些指南正在生效”就变成了书面预期与观测行为之间的对比，而不是凭空猜测。关于在版本控制规范下保留此类记录的通用案例，请参阅像对待 Git 一样对待 AI 记忆。

MemoryLake 就是存放该预期的地方：每条指南背后的决策记录，独立于当前交付它的层级。当控制台发生变化时，你就有据可查。当某条指南消失时，你依然知道它曾写了什么以及为什么存在。由此开始。

步骤 1：创建 API 密钥

为团队创建一个工作区，而不是为单个仓库创建——组织指南适用于“你组织的所有用户和项目”，因此该记录的范围至少应该与它所描述的层级一样宽广。

步骤 2：上传你的第一批记忆

记录步骤 2 的测试结果：哪一层胜出，以及在哪个界面上。然后添加当前控制台中每条指南背后的决策——原因、日期以及它所替换的版本。向你的管理员索要一次这些历史记录；现在记录下来，比以后重新构建要容易得多。

步骤 3：连接你的 AI 和智能体

连接你使用的两个 Tabnine 界面：IDE 插件和 CLI。因为两者汇集指南的方式不同，让它们读取同一个共享的决策记录，是确保规则的原因在两者中完全一致的唯一方法，即使指南文本是通过不同的路径到达的。

工程师之间的分歧变得可以诊断。当一个人的智能体遵循了某项规范，而另一个人的没有时，你就有了一个排查清单：传播窗口、界面差异、服务账户认证，或者静默失败的获取。这是四个可以验证的假设，而不是无奈的耸耸肩。

静默降级变得可以检测。因为文档记录的回退机制是“会话在没有它们的情况下继续”，所以发现它的唯一方法就是拥有一份可供对比的预期。一次标记测试只需一分钟，却能决定你是今天发现问题，还是在代码审查时才发现。

管理员的更改不再是隐形事件。目前，控制台的编辑在没有任何通知的情况下，直接作为行为变化传达到你的团队。一份带有日期的书面记录能让它变成看得见、摸得着的东西。

而且，推理过程在层级发生变化时依然得以保留。指南会发生迁移——从个人文件到控制台，从控制台到服务账户——每一次迁移都会重写文本。但其背后的决策根本不需要迁移。这就是我们在AI 记忆是一项功能还是锁定机制中提出的所有权问题的实际体现。

测试时，选择重启而不是等待。15 分钟的窗口期对于日常工作来说是一个不错的默认设置，但对于诊断来说却是一个障碍。重启 IDE 或插件可以立即应用控制台的更改。

让个人指南和组织指南关注不同的内容。由于控制台的优先级高于你的 guidelines.md，任何重叠都会导致你在冲突中败北。将本地文件用于真正的个人偏好，而将共享标准留给旨在强制执行它们的层级。

不要将 enableCoaching 视为全局关闭开关。它“仅控制内置的 Coaching Guidelines MCP 服务器”，而组织指令和服务账户指令无论如何都会被获取。如果你需要一个真正干净的会话进行测试，这是一个认证问题，而不是设置问题。

检查会话正在使用哪个身份。服务账户指令“仅在为已认证的服务账户配置时才适用”，因此 CI 运行和本地会话完全可以拥有不同的指南。在你的记录中，将身份与界面一并记下。

遵守长度建议。Tabnine 建议将 guidelines.md 保持在 500 行或以下。系统支持多个指南文件，因此请按主题进行拆分，而不是让单个文件超出建议长度。

定期审计，而不是在产生怀疑时才审计。每季度运行一次标记测试，并将结果与你的书面预期进行对比。这种习惯的更广泛版本在审计你的 AI 实际记住了什么中有所介绍，这在这里尤为重要，因为最具权威性的层级并不是你能在会话中直接检查的。

Tabnine 的指南系统比单个指令文件功能更强大——组织级强制执行、服务账户范围限定，以及智能体可在任务中途查询的工具，这些都是扁平文件无法做到的。这种强大能力的代价是，生效的集合是在会话启动时，从拥有不同所有者、不同界面以及存在文档记录延迟的多个来源中汇集而成的。

没有命令可以打印出答案，Tabnine 官方也是这么说的。你能做的是列举这五个输入源，通过矛盾测试每一个，并保留一份关于应该生效什么的页面记录。这样，问题就不再是无法回答的，而是变成了一个对比——而这正是“当前有哪些指南正在生效”所需要的一切。

如果你仍在评估这一转变，从 GitHub Copilot 迁移到 Tabnine 介绍了两者之间优先级方向是如何反转的，这是来到这里最令人惊讶的部分。