【攻略】Lore/rac-core使用指南

这是什么

Lore 是一个给代码代理使用的“团队决策记录层”。它底层开源引擎叫 RAC，也就是 Requirements as Code；PyPI 包名是 rac-core，安装后提供 rac 命令和 lore MCP server。

它解决的不是“让 AI 搜更多资料”，而是另一个更具体的问题：团队已经做过的架构决策、产品约束、需求边界、路线图、提示词规范，如何让 Claude Code、Cursor 这类代码代理在写代码时稳定读取，并且不要每次都重新发明一遍。

项目地址：github.com/itsthelore/rac-core 文档：itsthelore.github.io/rac-core PyPI：rac-core Owner：itsthelore License：Apache-2.0 最近活动：主分支在 2026-06-29 有更新；Changelog 最新可见版本为 2026.06.5。

---

它和普通 RAG 有什么区别

很多团队现在给代码代理补上下文，第一反应是做 RAG：把文档切片、向量化，然后让模型相似度检索。Lore 的思路更保守，也更适合“团队决策”这种不能含糊的内容。

它把知识写成带 frontmatter 的 Markdown，直接放在代码仓库里。每个文档有类型，例如 requirement、decision、design、roadmap、prompt。代理通过 MCP 只读这些内容，RAC 则负责校验文档结构、链接关系和已废弃决策。

普通 RAG 更擅长“找相近内容”；Lore 更擅长“返回那个确定的、当前有效的决定”。这两者可以配合：先用 RAG 召回，再用 Lore 校验，避免代理把过期或模糊的上下文当成事实。

---

安装

Lore 需要 Python 3.11+。最简单的安装方式：

pip install rac-core

如果你习惯用 uv 管理命令行工具，也可以：

uv tool install rac-core

可选扩展：

# 支持 DOCX / HTML 导入\npip install "rac-core[ingest]"\n\n# 进一步支持 PDF / PPTX / XLSX 导入\npip install "rac-core[ingest-all]"\n\n# 安装终端 Explorer\npip install "rac-core[explorer]"

安装完成后验证：

rac --help

---

5 分钟跑起来

在你的项目根目录执行：

rac quickstart

这个命令会初始化 identity，并帮你搭出第一个知识 artifact。接着可以新建一条团队决策：

rac new decision adr-001-api-boundary.md

写完之后，先让 RAC 检查：

rac validate rac/\nrac gate rac/

rac validate 负责结构和格式校验，rac gate 更像合并前的门禁，会检查关系、引用和问题严重度。团队可以把这两个命令放到 CI 里，让“代理可读取的知识库”也走代码审查。

---

接入 Claude Code、Cursor 和 Claude Desktop

如果你用 Claude Code，在项目根目录执行：

claude mcp add lore -- rac mcp

如果你用 Cursor 或 Claude Desktop，可以在 MCP 配置里加：

{\n  "mcpServers": {\n    "lore": {\n      "command": "rac",\n      "args": ["mcp", "--root", "/absolute/path/to/your/repo"]\n    }\n  }\n}

这里的重点是 --root 要指向真实项目路径。Lore 的 MCP server 是只读的：代理可以查询团队知识，但不能直接改写这些记录。真正的修改仍然应该走人类 PR review。

---

一个实际使用场景

假设团队曾经做过一个决定：后台 API 不再新增 GraphQL，只维护 REST，并且所有跨系统回调都必须走统一签名。以前这类信息可能散落在会议纪要、飞书文档、PR 评论里。代码代理接到需求时，很可能不知道这个约束，于是又生成了一个 GraphQL endpoint。

用 Lore 的做法是，把这条决定写成一个 decision artifact，放进仓库。之后你让代理实现新接口时，它可以从 Lore 查到这条有效决策，并在输出方案时引用它。

这不是让 AI “记性更好”这么简单，而是把团队知识从聊天上下文里搬回工程资产里。只要这个 artifact 仍在仓库、仍通过 rac validate，代理就有一个可审计的依据。

---

适合谁

• 已经大量使用 Claude Code、Cursor、Codex 或其他代码代理的团队
• 有 ADR、需求文档、设计文档，但这些文档没有真正影响 AI 输出的团队
• 希望把“为什么这么做”版本化，并和代码一起走 review 的团队
• 对安全和可审计性敏感，不希望代理随便改写知识库的团队

不太适合谁

• 只是个人小项目，且上下文很少，不需要正式知识治理
• 想要一个自动总结所有聊天记录的通用记忆工具
• 希望用向量搜索处理大量非结构化资料，而不是维护明确的团队决策
• 不愿意把需求和决策写成 Markdown、也不准备把它们纳入代码仓库的人

---

常见坑

1. 不要把 Lore 当成文档垃圾桶。 它适合放“当前有效的决定”和“需要代理遵守的约束”。如果把所有会议记录都倒进去，反而会降低信噪比。

2. 先小范围试，不要一口气迁移全部历史资料。 可以先从 5 到 10 条最容易被代理违反的决策开始，例如 API 风格、数据库迁移约束、前端组件库选择、部署边界。

3. 一定要跑校验。 rac validate 和 rac gate 的价值就在于把知识库当作工程资产处理。没有校验，Lore 很快会退化成另一堆没人敢信的 Markdown。

4. 只读 MCP 是优点，不是限制。 代理不能直接修改知识库，意味着它不能悄悄改写团队共识。更新决策应该由人提出 PR，再通过 review 合并。

5. 注意敏感信息。 不要把 API Key、客户隐私、合同条款原文等敏感内容放进可被代理读取的 artifact。Lore 本身可以本地运行，但团队仍然要做好内容边界。

---

一句话总结

Lore/rac-core 适合那些已经把 AI 代码代理用进日常开发、但开始担心“代理总是不知道团队为什么这么做”的团队。它不追求炫技，而是把需求、决策和设计约束变成可校验、可审计、可被 MCP 读取的工程事实。

如果你的团队已经有 ADR，却发现代理经常绕开它，Lore 值得认真试一下。

---