1. 项目概述：一个为AI编码伙伴打造的“统一指挥中心”

如果你和我一样，日常开发中已经离不开Claude Code、Cursor、GitHub Copilot这些AI编码助手，那你肯定也体会过那种“精神分裂”般的割裂感。在Claude里刚跟它讲明白项目的架构规范和某个第三方库的奇葩API调用方式，切换到Cursor开始另一个功能模块时，又得从头解释一遍。更别提那些散落在各个编辑器 .cursorrules 、 .claude 目录下的规则文件，稍微改一点，就得手动同步到其他平台，一不留神就版本错乱，知识“漂移”。

这就是Lore要解决的核心痛点。它不是一个新AI，而是一个**“AI伙伴的伙伴” ——一个用Go写的轻量级二进制工具。你可以把它理解为你所有AI编码助手的 统一管理后台和知识同步中枢**。它的核心思想是“一次编写，处处运行”：你只需要在一个地方（Lore）定义好项目的规则、技能和专属的AI智能体配置，Lore会自动将这些内容“编译”或“投影”成各个平台（Claude Code, Cursor, Copilot等）能原生识别的配置文件。从此，你的项目规范、踩坑记录、常用指令集，在所有AI工具间保持了强一致性，会话体验是连续而非割裂的。

简单说，Lore通过一套中心化的配置和分发机制，让你团队的AI编码伙伴们“共用同一个大脑”，极大地提升了AI辅助的效率和可靠性。这对于追求工程规范、团队协作或是在复杂项目上深度使用AI的开发者来说，是一个改变工作流的利器。

2. 核心设计思路：三层配置与统一投影

Lore的优雅之处在于其清晰的分层设计。它没有试图创造一套全新的、封闭的配置语法来取代各家平台，而是做了一个聪明的“适配层”。它的工作流程可以概括为： 收集 -> 合并 -> 投影 。

2.1 配置来源的三层结构

Lore管理的配置来源于三个层次，优先级从低到高依次覆盖：

  1. Bundle层（生态包） ：这是Lore最具扩展性的设计。Bundle可以理解为社区或官方发布的、针对特定技术栈或场景的预配置包。例如，可能有一个“Next.js + TypeScript + Tailwind最佳实践”Bundle，里面预置了对应的代码规范规则、组件生成技能等。它通常安装在用户的 ~/.lore-os/ 目录下，为所有项目提供基础能力。
  2. Global层（用户全局层） ：位于 ~/.config/lore/ 。这里存放你个人跨项目的偏好和通用知识。比如你个人习惯的代码风格（即使与Bundle冲突）、你总结的通用调试技巧、或者你为自己定义的一个“代码审查专家”AI智能体。这些配置会对你的所有项目生效。
  3. Project层（项目本地层） ：位于项目根目录的 .lore/ 文件夹下。这里的配置拥有最高优先级，用于定义本项目独有的规则、技能和智能体。例如，本项目特有的API密钥命名规范、数据库操作技能、或是针对本项目业务逻辑的“领域专家”智能体。

当运行 lore generate 命令时，Lore会从这三个来源读取所有配置，按照优先级进行智能合并，最终在内存中形成一份完整的、针对当前项目的“终极配置”。

注意 ：合并策略通常是“覆盖”而非“拼接”。如果项目层定义了一条名为“命名规范”的规则，那么它会完全覆盖Global层或Bundle层同名的规则。对于技能和智能体，也是类似的覆盖逻辑。这要求你在命名时要有清晰的规划，避免意外覆盖。

2.2 统一投影机制

得到合并后的“终极配置”后，Lore的“投影器”开始工作。它会遍历你在 .lore/config.json 中启用的所有目标平台，然后将统一的配置“翻译”成每个平台能理解的本地文件。

例如，一条在Lore中定义的“禁止使用 any 类型”的规则：

  • 投影到 Cursor ，可能会生成一个 .cursor/rules/typescript_no_any.mdc 文件。
  • 投影到 Claude Code ，可能会在 CLAUDE.md 文件中添加一个章节，或者在 .claude/rules/ 目录下生成一个对应的Markdown文件。
  • 投影到 GitHub Copilot ，可能会在 .github/copilot-instructions.md 中写入这条规则。

这个过程的精髓在于， 作为使用者的你，只需要维护Lore这一套配置 。无论是新增一个技能，还是修改一条规则，你都只需要在Lore的体系内操作一次，然后运行 lore generate ，所有平台的本地文件都会自动更新。这彻底解决了多平台间配置同步的噩梦。

3. 核心概念深度解析：规则、技能、智能体与现场笔记

要玩转Lore，必须吃透它的四个核心概念：Rules（规则）、Skills（技能）、Agents（智能体）和Fieldnotes（现场笔记）。它们共同构成了你AI伙伴的“知识体系”和“行为模式”。

3.1 规则：AI必须遵守的“法律”

规则是你对AI编码行为的强制性约束和指导原则。它不仅仅是写在文档里的建议，而是通过 钩子 机制在关键时刻被主动注入AI的上下文，确保其被遵守。

规则的内容可以包括：

  • 代码风格 ：缩进、命名约定（驼峰、帕斯卡）、导入排序。
  • 安全策略 ：禁止硬编码密钥、禁止使用已知的不安全函数。
  • 架构约束 ：组件必须使用函数式声明、API调用必须封装在特定服务层。
  • 业务逻辑 ：用户状态更新必须通过特定的Redux action。

一个规则文件的示例结构： 

# rule: typescript_strict
description: 强制TypeScript严格模式最佳实践
scope: [“*.ts”, “*.tsx”]

## 规则正文
1. 必须显式定义函数返回值类型，禁止依赖类型推断（简单箭头函数除外）。
2. 禁止使用`any`类型。对于未知类型，优先使用`unknown`并做类型守卫。
3. 所有异步操作必须使用`try/catch`进行错误处理，或使用更高级的错误处理库。
4. 模块导出必须使用命名导出（`export const`），默认导出仅用于React组件或Vue SFC。

## 触发钩子
- `before_file_write`: 在AI即将写入文件前，此规则会被注入，AI会据此检查即将生成的代码。

实操心得 ：规则并非越多越好。初期建议从最影响代码质量和安全性的2-3条核心规则开始。过于严苛或琐碎的规则可能会限制AI的创造力，或导致其频繁“触礁”而无法完成任务。一个好的规则应该像交通法规，保障安全与秩序，而非窒息驾驶乐趣。

3.2 技能：AI可调用的“工具箱”

如果说规则是“不能做什么”，技能就是“可以怎么做”。技能封装了复杂的、可重复的操作流程，让AI能够执行超出简单代码补全范围的任务。

技能的本质是一个详细的、步骤化的指令集或一个可执行的脚本。 例如：

  • “搭建React组件”技能 ：告诉AI如何创建包含Props接口、CSS模块导入、基础生命周期注释的组件文件。
  • “添加新的API端点”技能 ：指导AI在基于Express的后端项目中，创建路由文件、控制器、服务层以及更新Swagger文档的一整套流程。
  • “数据库迁移”技能 ：结合项目使用的ORM（如Prisma），给出生成和运行迁移文件的精确命令和检查点。

技能配置示例： 

# skill: generate_react_component
description: 生成一个标准的React函数组件
command: internal_generation # 或指向一个外部脚本
parameters:
  - name: componentName
    type: string
    required: true
  - name: withStyles
    type: boolean
    default: true
  - name: withTests
    type: boolean
    default: false

instructions: |
  你是一个经验丰富的React开发者。请根据以下参数生成一个组件：
  1. 组件名称为`{{.componentName}}`。
  2. 使用TypeScript，定义清晰的Props接口。
  3. 使用函数声明式组件。
  4. 如果`withStyles`为真，导入对应的CSS模块文件`{{.componentName}}.module.css`。
  5. 在组件顶部添加JSDoc注释，说明组件用途。
  6. 如果`withTests`为真，在注释中提示“需要创建对应的测试文件”。
  输出仅为组件代码，不要有其他解释。

当AI在编码过程中识别到用户的意图符合某个技能时（例如用户说“请创建一个用户头像组件”），它可以主动建议或直接调用这个“生成React组件”技能，从而输出结构统一、符合规范的高质量代码块。

3.3 智能体：具备特定“人格”和专长的AI

这是Lore中最有趣的概念。你可以超越平台默认的通用AI，创建针对不同任务的“专属特工”。

一个智能体定义包括：

  • 名称与描述 ：如“前端架构师”、“数据库调优专家”、“代码审查员”。
  • 系统指令 ：定义其核心角色、目标和行为边界。例如，给“代码审查员”的指令是“你是一个苛刻的资深工程师，专注于发现代码中的坏味道、潜在bug和安全漏洞，不关心代码风格（因为已有规则约束）”。
  • 启用的技能 ：这个智能体擅长使用哪些技能。比如“前端架构师”可能拥有“搭建组件库”、“配置构建优化”等技能。
  • 绑定的规则 ：这个智能体需要额外遵守或侧重的规则集。比如“安全审计员”智能体会绑定所有安全相关规则。

在支持智能体切换的平台上（如Cursor的 AGENTS.md ），你可以根据当前任务，快速切换到最合适的智能体。比如写业务逻辑时用“高效开发者”，完成后再切换到“审查员”来检查代码，实现了工作流的专业分工。

3.4 现场笔记：让AI“吃一堑，长一智”

这是解决“会话失忆”问题的关键。现场笔记是AI在与你协作过程中，自动或由你手动记录的“经验教训”或“上下文快照”。

典型场景：

  • AI在调用某个第三方API时遇到了一个奇怪的429错误，你们一起排查发现需要添加一个特定的请求头。这个排查过程和解决方案可以立即保存为一个现场笔记，标题为“XX API速率限制与特殊请求头”。
  • 项目在部署到某个特定环境时，需要修改一个不起眼的配置文件参数。这个部署“秘籍”被记录下来。

当下次开启一个新的AI会话时，Lore会将这些与当前项目/目录相关的现场笔记作为上下文加载给AI。这意味着， 同一个坑，整个团队只需要踩一次 。新来的同事或者新开启的会话，AI已经“知道”了之前遇到的问题和解决方案，避免了重复劳动和错误。

4. 从零开始：安装、初始化与生成你的第一个配置

理论讲完了，我们动手实操。Lore的安装和使用非常简洁，这得益于其单一的Go二进制设计。

4.1 安装Lore CLI

你有两种主流安装方式：

方式一：通过npm（推荐给大多数开发者） 

npm install -g @lorehq/cli

安装后，直接在终端输入 lore ，如果看到帮助信息，说明安装成功。这种方式通常能自动处理好系统路径。

方式二：从源码安装（适合Go开发者或想体验最新版） 

go install github.com/lorehq/lore@latest

确保你的 $GOPATH/bin 或 $GOBIN 在系统PATH环境变量中。

4.2 初始化你的第一个Lore项目

进入你的项目根目录（或者一个新目录），执行初始化命令：

cd /path/to/your/project
lore init

这个命令会做两件事：

  1. 在项目根目录下创建 .lore/ 文件夹。
  2. 在 .lore/ 下生成一个基础的 config.json 配置文件。

让我们看一下这个初始的 config.json ：

{
  “$schema”: “https://lorehq.github.io/schema/config.json”,
  “version”: “1”,
  “platforms”: {
    “claudecode”: true,
    “cursor”: true,
    “githubcopilot”: true,
    “gemini”: false,
    “windsurf”: false,
    “opencode”: false,
    “cline”: false
  }
}

关键配置项是 platforms 。这里默认开启了Claude Code、Cursor和GitHub Copilot。你可以根据自己实际使用的工具，将对应的值设为 true 或 false 。Lore在生成时，只会为开启的平台创建文件。

4.3 创建你的第一条规则

现在，我们在项目层添加一条简单的规则。在 .lore/ 目录下，创建 RULES/ 文件夹，然后在里面创建一个Markdown文件，例如 no_console_log.md 。

# rule: no_console_log_in_prod
description: 禁止在生产代码中留下console.log
scope: [“*.js”, “*.ts”, “*.jsx”, “*.tsx”]

## 规则
除非在明确标记为开发用途的文件中，否则禁止提交包含`console.log`、`console.error`等控制台输出语句的代码。调试信息应使用专业的日志库。

## 理由
1.  控制台语句会影响生产环境性能。
2.  可能泄露敏感信息。
3.  使日志管理混乱，难以追踪真正的错误。

## 替代方案
- 使用如`winston`、`pino`等日志库。
- 使用`debug`包，并通过环境变量控制输出。
- 在Vite/Webpack等构建工具中配置插件，在构建生产包时移除这些语句。

## 钩子
此规则通过`before_file_write`钩子生效。AI在生成或修改代码文件前，会收到此规则的提醒。

4.4 生成平台专属配置

保存规则文件后，在项目根目录运行生成命令：

lore generate

静待命令执行完成。现在，检查你的项目目录，你会发现多出了一些新文件：

  • CLAUDE.md ：里面包含了你的规则内容。
  • .cursor/rules/no_console_log_in_prod.mdc ：Cursor专用的规则文件。
  • .github/copilot-instructions.md ：Copilot的指令文件中，也增加了相应的规则段落。

恭喜！ 你已经完成了Lore的核心工作流：在中心（Lore）定义规则，一键分发到所有平台。现在，当你在这个项目中使用Claude Code、Cursor或Copilot时，它们都会“知道”不应该随意添加 console.log 。

5. 高级工作流：技能创建、智能体配置与现场笔记应用

掌握了基础规则管理后，我们来探索更强大的功能，构建一个高效的个人AI工作流。

5.1 创建一个实用的技能：自动化生成API Service层

假设你有一个使用Axios的Vue/React项目，每次调用后端API都需要写重复的样板代码。我们可以创建一个技能来简化这个过程。

在 .lore/SKILLS/ 目录下创建 generate_api_service.md ：

# skill: generate_api_service
description: 为指定的API端点生成一个标准的Service层函数
command: internal_generation

## 参数
- `moduleName` (字符串，必需): API的功能模块名，如`user`、`product`。
- `endpoint` (字符串，必需): API端点路径，如`/api/v1/users`。
- `method` (字符串，可选，默认`GET`): HTTP方法，`GET`、`POST`、`PUT`、`DELETE`。
- `hasAuth` (布尔值，可选，默认`true`): 是否需要携带认证token。

## 指令
你是一个精通前端架构和Axios的开发者。请根据以下参数生成一个TypeScript函数：

1.  函数名应为`fetch{{.moduleName | TitleCase}}Data`或`post{{.moduleName | TitleCase}}Data`等（根据method动态生成）。
2.  使用项目内统一的Axios实例（假设从`@/utils/request`导入）。
3.  明确定义请求参数的类型`Params`和响应数据的类型`Response`。对于`GET`，Params应为`query`对象；对于`POST/PUT`，Params应为`data`对象。
4.  函数必须返回Promise<Response>。
5.  如果`hasAuth`为真，确保请求头中包含`Authorization`。
6.  对错误进行统一捕获，使用项目约定的日志函数`logError`进行记录，并重新抛出错误。
7.  在函数上方添加清晰的JSDoc注释，说明其用途、参数和返回值。

请只输出最终的TypeScript函数代码，不要有其他解释。

现在，当你在AI聊天框中输入“为用户登录接口创建一个service，端点是 /api/auth/login ，方法是POST”，AI识别到这个意图后，就可以调用这个技能，直接生成一个完美符合你项目规范的、健壮的API请求函数。

5.2 配置一个专属的代码审查智能体

在 .lore/AGENTS/ 目录下创建 code_reviewer.md ：

# agent: strict_reviewer
description: 一个严格、细致的代码审查员，专注于逻辑缺陷、安全漏洞和性能问题。

## 系统指令
你是一个拥有15年经验的首席架构师，以审查代码极其严格、眼光毒辣著称。你的唯一任务是在代码合并前发现所有潜在问题。你不在乎开发者的感受，只在乎代码的质量和系统的长期健康度。

## 核心关注点（按优先级排序）
1.  **安全**：SQL注入、XSS、CSRF、不安全的依赖、硬编码密钥、权限绕过风险。
2.  **正确性**：边界条件处理、竞态条件、未处理的异常、逻辑错误、算法复杂度。
3.  **性能**：不必要的重复计算、低效的数据库查询、大内存对象泄漏风险、阻塞主线程的操作。
4.  **可维护性**：过度的嵌套、函数过长、魔法数字、含糊的命名、重复代码。

## 忽略以下方面
- 代码风格（如缩进、分号）。这部分由`eslint`和`prettier`规则负责。
- 简单的语法错误。这应由开发者的IDE在编写时捕获。

## 审查输出格式
对于每个发现的问题，请按以下格式指出：
**[严重级别: 高/中/低] 问题简述**
- **文件**: `path/to/file.js:行号`
- **上下文**: 展示有问题的代码片段。
- **风险**: 解释这个问题的潜在后果。
- **修复建议**: 提供具体的代码修改建议或最佳实践。

在Cursor等平台，你可以通过 AGENTS.md 文件快速切换到这个“strict_reviewer”。当你完成一段代码编写后，将这段代码发给它，你会得到一份堪比资深同事的、一针见血的审查报告。

5.3 记录与使用现场笔记

现场笔记通常由AI在对话中根据你的指令自动创建，但你也可以手动维护。它们通常存储在项目层的 .lore/ 目录下，或与特定Bundle关联。

一个典型的现场笔记内容： 

# fieldnote: stripe_webhook_signature_verification
date: 2023-10-27
trigger: 部署到生产环境后，Stripe webhook验证失败。

## 问题
我们的Stripe webhook处理器在生产环境一直返回401错误。本地测试正常。

## 根本原因
Stripe在发送webhook事件时，会根据你的webhook端点密钥、负载和时间戳生成一个签名。我们的验证代码在获取请求头中的`stripe-signature`时，使用了`req.headers['stripe-signature']`。然而，在生产服务器（Nginx）后面，请求头可能被标准化为小写`stripe-signature`，但我们的代码可能在某些部署环境下获取不到（如大小写敏感问题）。

## 解决方案
1.  使用`req.headers['stripe-signature'] || req.headers['Stripe-Signature']`来兼容不同环境。
2.  更健壮的做法是，遍历`req.headers`的键，寻找忽略大小写后匹配`stripe-signature`的键。
3.  更新部署文档，明确要求反向代理服务器传递原始请求头。

## 相关文件
- `/backend/src/webhooks/stripeHandler.ts`
- `/docs/deployment.md`

这个笔记被保存后，未来任何AI在该项目中处理Stripe webhook相关任务时，这段关键的上下文信息都会被自动提供，从而避免团队再次掉入同一个陷阱。

6. 项目管理与团队协作实践

Lore不仅适用于个人，在团队协作中更能发挥巨大价值。关键在于如何管理共享的配置。

6.1 项目配置的版本控制

.lore/ 目录应该被提交到项目的版本控制系统（如Git）中。这样：

  • 确保一致性 ：所有团队成员拉取代码后，运行 lore generate ，就能获得完全相同的AI辅助环境。
  • 知识传承 ：项目特有的规则、技能和现场笔记随着项目代码一起被记录和传承，新成员 onboarding 时，AI已经具备了项目的“集体记忆”。
  • 流程化 ：可以将 lore generate 作为项目 postinstall 或 pre-commit 钩子的一部分，确保生成的平台配置总是最新的。

6.2 使用Bundle共享团队/技术栈最佳实践

对于公司或大型团队，维护一个内部的Lore Bundle是最高效的方式。

Bundle可以包含：

  • 公司级编码规范 ：安全红线、Git提交信息规范、API设计规范等。
  • 技术栈标准技能 ：基于内部UI库生成组件的技能、连接内部微服务的技能、部署到公司云平台的技能等。
  • 通用智能体 ：公司级的“安全审计员”、“性能分析员”智能体。

团队成员只需安装并启用这个公司Bundle，就能在所有项目中自动获得这些标准化配置。Bundle的更新可以像更新一个npm包一样推送给所有人，确保最佳实践能快速同步。

6.3 配置的优先级与冲突解决

记住三层优先级： Project > Global > Bundle 。

  • 团队规范与个人习惯 ：公司Bundle里定义了使用 axios ，但你在Global层覆盖为 fetch ，那么在你个人的所有项目中，都会用 fetch 。但如果你在某个项目（Project层）的配置里又指定用 axios ，那么这个项目会用 axios 。这给了个人极大的灵活性。
  • 处理冲突 ：最可能发生的冲突是同名规则或技能。Lore的合并逻辑是覆盖。因此，清晰的命名规范至关重要。建议在团队Bundle中使用前缀，如 company_secure_coding_rule ，在个人Global层使用 personal_react_style ，在项目层使用 project_x_api_convention 。

7. 常见问题与故障排查实录

在实际使用中，你可能会遇到一些问题。以下是我和社区成员遇到过的一些典型情况及其解决方案。

7.1 生成命令无效或平台文件未更新

症状 ：运行 lore generate 后，目标平台（如Cursor）的配置文件没有变化或没有生成。

排查步骤：

  1. 检查平台开关 ：首先确认 .lore/config.json 中对应平台的 enabled 字段是否为 true 。一个常见的疏忽是复制了配置却忘了修改。
  2. 检查文件权限 ：确保Lore有权限在项目根目录下创建和写入文件。在某些严格的容器或服务器环境中，可能需要调整权限。
  3. 查看详细日志 ：使用 lore generate -v 或 --verbose 标志运行命令，查看详细的处理过程和可能的错误信息。Lore会输出它读取了哪些源文件、合并过程以及尝试投影到哪些平台。
  4. 清理缓存 ：极少数情况下，缓存可能导致问题。可以尝试删除 ~/.config/lore/.cache/ 目录下的文件（主要是 registry.json ），然后重试。
  5. 检查规则/技能语法 ：如果某个规则或技能文件存在语法错误（如YAML/JSON格式错误、Markdown结构不符合预期），Lore可能会在解析时静默失败。尝试暂时移除非核心文件，逐个添加来定位问题文件。

7.2 AI助手似乎“无视”生成的规则

症状 ：规则文件已经生成，但AI在编码时仍然做出了违反规则的行为。

排查步骤：

  1. 确认平台支持 ：并非所有规则都能被所有平台完美支持。例如，一些复杂的、依赖运行时分析的规则（如“循环复杂度不能超过10”），可能只有部分高级平台能理解。查阅Lore官方文档，了解各平台对规则类型的支持程度。
  2. 检查规则作用域 ：确认你的规则文件中的 scope 字段是否正确匹配了当前正在编辑的文件类型。如果你在 .tsx 文件中工作，但规则的 scope 只写了 [“*.js”] ，那么该规则不会被触发。
  3. 理解钩子的局限性 ： before_file_write 钩子主要影响AI 生成新代码 或 大幅重写代码 的时刻。对于AI在你已有的代码行中进行的小修小补或补全，某些平台可能不会每次都重新注入完整的规则上下文。这更多是平台自身实现的限制。
  4. 平台重启 ：一些IDE或编辑器插件（如Copilot）可能需要重启或重新加载工作区，才能识别新生成的指令文件。尝试重启你的编辑器。

7.3 技能调用不准确或未被识别

症状 ：定义了技能，但AI在相关对话中不会主动建议或调用它。

排查步骤：

  1. 优化技能描述和指令 ：技能的 description 和 instructions 字段至关重要。AI（尤其是底层的大语言模型）依赖这些文本来理解技能的用途和调用时机。确保描述清晰、具体，指令步骤化、无歧义。在 instructions 中，使用明确的、可操作的语言。
  2. 检查参数定义 ：确保参数 name 与 instructions 中使用的变量占位符（如 {{.paramName}} ）完全一致，包括大小写。
  3. 用户意图表达 ：当你希望AI使用技能时，在对话中尽可能清晰地描述任务。例如，说“请使用‘生成API Service’技能，为产品列表端点创建函数”比简单说“创建一个获取产品的函数”更容易触发技能匹配。
  4. 平台差异 ：不同平台对技能调用的支持度不同。有些平台可能只支持在特定聊天窗口或通过特定命令触发技能。参考各平台自己的文档，了解如何与自定义指令/技能交互。

7.4 现场笔记未被加载到新会话

症状 ：之前记录的现场笔记，在新的AI聊天会话中似乎没有被提及。

排查步骤：

  1. 笔记相关性 ：现场笔记通常与特定的文件路径、代码片段或技术关键词关联。确保你新开启的会话讨论的问题，与现场笔记记录的内容在语义上是相关的。AI不会在无关的上下文中强行插入所有笔记。
  2. 笔记存储位置 ：确认现场笔记文件被正确保存在 .lore/ 目录下或当前激活的Bundle中。运行 lore generate 会确保这些笔记被索引。
  3. 平台上下文长度限制 ：这是最可能的原因。AI模型的上下文窗口有限。如果项目很大、规则、技能、现场笔记很多，平台可能无法将所有内容都加载到初始上下文中。Lore和平台通常会采用优先级策略。 解决方案 ：对于非常重要的、需要常驻记忆的笔记，考虑将其核心内容提炼成一条 规则 或写入项目的 LORE.md / CLAUDE.md 等核心指令文件的开头部分，这些文件的优先级通常最高。

7.5 性能问题：生成速度慢或IDE卡顿

症状 ：在大型项目（如Monorepo）中运行 lore generate 耗时较长，或者生成大量配置文件后IDE响应变慢。

优化建议：

  1. 使用 .loreignore 文件 ：在项目根目录创建 .loreignore 文件（类似于 .gitignore ），忽略不需要Lore处理的目录，如 node_modules 、 dist 、 build 、 .git 等。这能显著减少Lore扫描和文件操作的时间。
  2. 精简平台配置 ：只开启你真正使用的平台。在 config.json 中，将不用的平台设为 false 。
  3. 按需生成 ：Lore可能在未来支持增量生成或监听模式。目前，可以手动在需要更新配置时才运行 lore generate ，而非将其加入频繁执行的钩子中。
  4. IDE/编辑器配置 ：某些编辑器可能会监控并解析新生成的配置文件（如Cursor解析 .mdc 文件）。如果文件数量巨大，可能会带来短暂开销。确保你的编辑器已更新到最新版本，通常它们会对这类文件做优化索引。

8. 个人使用体会与进阶技巧

经过一段时间的深度使用，Lore已经从“一个有趣的想法”变成了我开发工作流中不可或缺的基础设施。它带来的最大改变是 心智负担的降低和协作效率的质变 。我不再需要记住在不同工具间同步了什么，也不再需要向每个新AI会话复述项目背景。

这里分享几个我总结的进阶技巧：

1. 从“规则警察”到“规则教练”的思维转变 初期，我热衷于制定几十条严苛的规则，试图让AI写出“完美”代码。结果却常常导致AI束手束脚，或者频繁触发规则警告而打断流畅的编码过程。后来我意识到，规则应该像一位经验丰富的教练，在关键时刻给出关键提醒，而不是一个无处不在的警察。现在我的核心规则不超过10条，主要聚焦于 安全、架构红线和高频坏味道 ，把代码风格等交给Prettier和ESLint。这反而让AI的合作产出更高效、质量更高。

2. 技能设计：抽象与具体的平衡 设计技能时，最容易犯的错误是过于抽象或过于具体。一个“处理所有表单提交”的技能指令会太模糊，AI难以执行；而一个“创建包含姓名、邮箱、密码字段的注册表单”的技能又太具体，复用性差。 好的技能应该封装一个“可重复的工作单元” 。例如，“创建CRUD Service函数”是一个好技能，你可以通过参数指定资源名和字段。关键在于，技能的指令要能清晰地将参数映射到具体的代码结构上。

3. 利用现场笔记构建“项目知识图谱” 不要只把现场笔记当作错误记录。我习惯用它来记录：

  • 决策记录 ：为什么选择A方案而非B。
  • 第三方集成秘钥 ：某个服务特殊的配置步骤。
  • 复杂业务逻辑的简要说明 ：一段难以理解的遗留代码的“人话”注释。 久而久之，项目的 .lore/ 目录就成了一个结构化的、机器可读的“项目维基”。新同事加入后，只要运行 lore generate ，他的AI伙伴就已经是了解项目全部历史的“老员工”了。

4. 智能体切换：匹配工作阶段 我为自己配置了三个核心智能体，并在一天中切换使用：

  • “开拓者” ：用于快速原型设计和头脑风暴。它的指令是“快速给出多种解决方案，不拘泥于细节，鼓励创新”。规则绑定较少。
  • “工匠” ：用于具体功能实现。它绑定所有代码规范和安全规则，技能齐全，专注于写出健壮、可读的代码。
  • “审计员” ：用于代码审查和重构。它极度关注性能、边界条件和可维护性，像一位挑剔的客户。 通过快捷键或命令快速切换它们，让我感觉不是在用一个AI，而是在带领一个专业的微型开发团队。

Lore所代表的“Harness Engineering”理念，正在将AI从一种随机的、会话式的工具，转变为一种可预测、可管理、可集成的工程化组件。它可能不是每个开发者都需要的工具，但对于那些希望将AI深度、稳定、规模化地融入软件开发流程的团队和个人来说，它提供了一个极其优雅和强大的解决方案。开始可能只需要一条规则、一个技能，但当你逐渐构建起属于自己的AI配置体系时，你会发现，你和你的AI伙伴，正在以一种前所未有的高效方式共同成长。

Logo
DeepSeek技术社区

欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。

更多推荐

cover

Agent 状态机设计：为什么你的工具调用总失控？

avatar DeepSeek技术社区
cover

DeepSeek路由别名漂移实战：为什么一次模型表更新能引发客服工单风暴？

avatar DeepSeek技术社区
cover

换 embedding 模型必须重建索引？新旧向量空间混搭检索的工程真相

avatar DeepSeek技术社区