Busabase × CursorCursor 知识库
指令留在代码附近，决策、证据和负责人进入经过审核的记录。这样知识才能跨越分支、编辑器和人员交接。
Rules 是指令
Cursor Rules 用来约束行为，不应该变成包罗万象的事实库。
Cursor 官方文档区分 Project Rules、User Rules、Team Rules 和 AGENTS.md。它们的任务是在 Prompt 阶段指导 Agent。团队决策承担的是另一种职责：它需要证据、负责人、日期和清晰的审核历史。
| 指令层 | 适用范围 | 应该保存什么 |
|---|---|---|
| Project Rules | 仓库与文件范围 | 架构约定和重复工作流 |
| User Rules | 个人 Cursor 环境 | 个人偏好与交互方式 |
| Team Rules | 受管理的 Cursor 团队 | 组织统一的 Agent 行为 |
| AGENTS.md | 仓库目录树 | 靠近代码、方便阅读的操作指令 |
所有权边界
Rule 告诉 Cursor 应该怎么做，记录说明团队已经接受了什么。
把两者混在一起，只会让它们同时变弱：指令被历史信息撑得越来越长，决策又失去审核所需的结构。把内容移出聊天或分支之前，先做一次简单判断。
知识从哪里开始漂移
同一个仓库，可能同时存在三个版本的“我们已经决定”。
本地 Agent 会话、长期分支和相邻仓库经常携带不同假设。代码也许仍能编译，但产品、客服或运营团队可能还在按旧决策行动。
决策表
只保存下一次 Cursor 会话真正需要信任的字段。
一张精简的 Base 比不断增长的项目笔记更容易维护。它把决策和证据分开，也让过期状态清晰可见。
| 字段 | 回答的问题 |
|---|---|
| decision | 团队现在可以依赖什么？ |
| scope | 影响哪个仓库、服务或客户？ |
| evidence | 哪些测试、链接或记录支持它？ |
| owner | 谁负责保持信息有效？ |
| effective_from | 从什么时候开始生效？ |
| revisit_when | 出现什么情况需要重新讨论？ |
审核闭环
让 Cursor 提交更新，但不要让它静默改写项目事实。
Cursor 先读取当前任务所需的已接受记录。持久决策发生变化时，它提交 Change Request；审核者看到字段级差异，再决定新值是否应该成为正式记录。
读取已接受决策
在当前仓库中执行
带证据提交字段变更
审核并合并正式记录
连接步骤单独负责
这页回答应该记住什么，不重复讲怎样编辑 mcp.json。
全局或项目级 MCP 与 OAuth 配置继续使用现有连接指南。Cursor 官方 Rules 文档解释指令范围，Busabase 则保存这些指令可能引用的已审核记录。
采用前常见问题
Cursor 知识库常见问题
Busabase 会取代 .cursor/rules 或 AGENTS.md 吗？
不会。Agent 指令继续放在 Cursor Rules 或 AGENTS.md。需要负责人、来源并跨仓库复用的事实和决策再进入 Busabase。
Cursor 的每个发现都要建记录吗？
不需要。只有其他人或 Agent 之后会依赖的信息才值得沉淀；临时分析、猜测和一次性调试结果应该保持临时状态。
Cursor 可以更新决策表吗？
可以，具体操作取决于权限。共享知识建议授予 Change Request 权限，让 Cursor 只能提议字段变化，由审核者控制合并。
哪些内容应该继续放在 Git？
代码、测试、迁移、仓库指令和由实现负责的文档继续留在 Git。同一决策还会影响其他仓库或业务系统时，Busabase 才有价值。
一张 Base 能服务多个仓库吗？
可以，但必须有明确的 scope 字段和精确的证据链接，既支持跨仓库复用，也不假装所有决策处处适用。
从最容易反复漂移的决策开始
让下一次 Cursor 会话读取已接受答案，而不是翻旧聊天。
创建一张精简的决策表，连接 Cursor，在第一次纠正被复用之前完成审核。