雷哥AI

Ai自由协议通向自由之路

Mon, 23 Mar 2026 17:18:06 +0800

AI自由协议，是一套借助 AI 实现个人自由与独立的实践框架。

它不只是写代码，也不只是做自动化，而是一套关于个人生产力主权的表达：通过 AI、Agent 与自动化系统，把个人能力与数字系统、物理设备连接起来，逐步构建可持续运转的数字资产与自动化资产，完成从“体力交付”到“价值分发”的转型。

最终目标不是更忙，而是更自由。

不是把时间继续锁在电脑前，而是把原本必须亲自完成的重复劳动，交给系统去执行，让自己把更多时间留给家人、生活、散步、思考与创造。

为什么要做 AI 自由协议

我已经录了上百个技术视频，也持续在分析各种技术点，从底层实现到实际应用都讲得很细。

但后来我意识到，真正重要的不是“知道更多技术”，而是如何把这些技术组织起来，形成一套能够服务现实生活的系统。

技术本身不是终点。

通过 AI 获得更多自由，才是目标。

所以，AI自由协议关注的不是单点工具，而是如何让 AI 成为个人能力的放大器，最终帮我们减少低价值劳动，提升长期价值产出。

AI自由协议的定义

AI自由协议可以定义为：

通过 AI 的方式，将个人、数字系统与物理设备连接起来，持续沉淀数据资产，构建自动化能力，并最终实现个人价值创造效率最大化的一套实践协议。

它至少包含三层含义：

它是一种理念：强调个人生产力主权。
它是一套方法：强调目标、资产、系统的协同建设。
它是一种结果：让个人从重复劳动中逐步解放出来。

核心目标

AI自由协议的核心，不是为了“炫技式自动化”，而是为了创造价值。

这里的价值，首先来自一个清晰的核心目标：

你要服务谁？
你要解决什么问题？
你真正认同的价值观是什么？

只有目标明确，后续的数据资产沉淀和自动化系统建设才有意义。否则系统越复杂，偏离越严重。

两类关键资产

要实现 AI 自由协议，必须先积累自己的资产。这里的资产至少分为两类。

1. 数据资产

这是可以长期留存、可复用、可持续增值的高质量数字内容，例如：

文档
笔记
案例
业务数据
用户反馈
工作流记录

这些资产决定了你的 AI 系统是否“有材料可用”。

2. 经验资产

除了原始数据，还需要把人的经验沉淀为可被系统调用的规则与标准，例如：

判断标准
执行流程
决策依据
领域经验
成功与失败样本

这些经验资产，本质上是把领域专家的知识结构化，让 AI 在执行任务时知道：

什么是对的
什么是错的
什么情况下该怎么处理

当数据资产和经验资产同时具备时，才有可能真正构建出属于自己的 AI 数字化能力。

自动化系统的意义

当你的目标明确、资产逐渐沉淀之后，就可以进一步构建 AI 自动化系统。

这个系统的作用不是简单替代人，而是把原本需要你持续亲自投入的任务，逐步交给 AI、Agent 或自动化流程去完成。

这样做的结果是：

你拥有了可复用的系统能力
你拥有了可持续积累的数字资产
你在创造价值时，对体力劳动时间的依赖越来越低

这才是 AI 自由协议真正想实现的状态。

协议公式

AI自由协议可以用一个简单公式表达：

V = (G x S x A) / T

其中：

V (Value)：你最终创造的价值
G (Goal)：你的目标是否清晰、是否真实有意义
S (System)：你的 AI 自动化系统能力
A (Assets)：你沉淀的数字资产与经验资产
T (Time)：你实际投入的体力劳动时间

这个公式表达的是：

当目标清晰、系统完善、资产持续积累时，你创造的价值会不断放大；而当亲自投入的体力时间不断下降时，整体效率会进一步提升。

理想状态下，T 趋近于零，但不会真正等于零。因为人的价值不会消失，而是从“亲自执行”转向“定义目标、设计系统、校准方向”。

最终追求

AI自由协议真正追求的，不是做一个更忙的人，而是做一个更自由的人。

通过 AI 和自动化，把不必要亲自动手的事情逐渐分发出去，把自己的时间从重复劳动中释放出来，让价值创造更可持续，让生活本身重新回到中心。

这是一套关于效率的协议，更是一套关于人生选择的协议。

后续，我也会继续把实现 AI 自由协议的过程持续分享出来。

咱们的社群

咱们脱离AI炒作的喧嚣.

关注于真的可以使用AI真正落地的场景和解决方案.

我的微信: leigeaicom

AI是百年之未有之大变局, 你我皆在历史中. 一起塑造历史~

加油~ 同仁们.

Rag死了吗

Thu, 26 Feb 2026 17:55:13 +0800

一、“RAG 已死”是一个伪命题：核心在于数据结构的差异

目前业界（尤其是 AI 编程工具领域）流传的“传统 RAG 已死”，实际上是特定场景下的幸存者偏差。是否使用传统 RAG（即文本切块 + 向量检索），完全取决于数据的结构化程度。

RAG 全称为 Retrieval-Augmented Generation，即检索增强生成，它结合了检索和生成的能力，为文本序列生成任务引入外部知识。

1. 为什么 AI Coding Agents 抛弃了传统 RAG？

代码是极度结构化的数据，使用纯 Agentic 检索（直接系统命令 / AST 解析）具有压倒性优势：

零语义歧义： 代码标识符和语法是绝对精确的，不需要依赖向量模型去猜测“同义词”，直接使用正则（Regex）或终端工具（如 grep、cat）效率极高。
自带导航地图： 代码库拥有严谨的文件树和 import 引用关系。Agent 可以通过目录树或抽象语法树（AST）精准制导，实现确定性的“图导航”。
规避索引维护噩梦： 代码在开发中高频变动，实时重建 Chunking 和 Embedding 的时间成本和计算成本过高。

2. 为什么海量非结构化数据（10 万+ 文档）依然极其依赖传统 RAG？

在面对海量企业知识库（如规章制度、研究报告、历史工单）时，抛弃向量检索会让 Agent 直接崩溃：

致命的上下文爆炸（Context Window Explosion）： 如果让 Agent 像遍历代码一样去读取几十万份文档，大模型的上下文会在瞬间被无关信息塞满，不仅会导致极高的 API 成本，还会引发严重的“迷失在中间（Lost in the Middle）”幻觉。
信息降维与过滤的刚需： 传统 RAG 本质上是一个极度高效的低成本过滤器。它利用底层向量数据库的算力，在将信息喂给极其昂贵的大模型之前，先完成信息的降维，精准提取出最相关的几千个 token。
跨越语义鸿沟： 非结构化文本充满隐喻和模糊表达，只有依靠 Embedding 才能实现概念级别的匹配（例如搜“星战飞船”能召回“千年隼”）。

二、传统 RAG 的核心痛点：语义切分不完整

尽管传统 RAG 解决了上下文爆炸的问题，但它引入了一个新的致命缺陷：固定大小的切分（Fixed-size Chunking）往往会破坏逻辑的连贯性。

单次向量召回的准确率虽然尚可，但召回的片段（chunk）可能是一段被拦腰截断的话，导致大模型在推理时缺乏必要的前置背景或后续结论（上下文断裂）。

三、破局之道：高阶动态上下文扩充机制

为了在“低成本抗爆炸（传统 RAG 优势）”和“获取完整逻辑块（Agentic 检索优势）”之间取得平衡，我们推演了以下几种架构策略，并对它们的实战可行性进行了严格甄别。

1. Contextual Retrieval（上下文增强切块 / 语境丰富化）

核心思路是增强命中质量，例如：从一个片段生成若干问题或语境提示，用于扩大召回覆盖面。

2. 基础解法：Small-to-Big / Sentence Window

父子块（Small-to-Big）： 对细粒度（子）切片进行精准向量检索，命中后直接向模型返回其所属的大粒度（父）文本块。
滑动窗口（Sentence Window）： 以句子为单位检索，命中后动态向前后延伸固定的句子数量（如前后各加 3 句）拼接返回。

3. 终极架构解法：基于索引的 Agentic 动态检索（Agentic Retrieval）

这是最贴合真实业务逻辑的高阶解法：由大模型掌握绝对主动权，像“翻书”一样动态在向量库中抓取相邻片段。

架构运转逻辑：

带有“坐标”的元数据入库： 在数据处理阶段，文本依然被切分为带有重叠（overlap）的固定大小片段。但关键在于，存入底层向量数据库（如 Supabase 的 pgvector）时，必须强制绑定严格的坐标元数据，例如 doc_id、chunk_index、total_chunks。
第一轮寻路（纯向量召回）： 针对用户问题，系统执行常规的 Top-K 向量相似度检索，找到“锚点片段（Anchor Chunk）”（例如 chunk_index: 45）。
Agent 主动决策（工作流介入）： 大模型在 LangGraph 的节点中阅读该片段，自行判断信息是否完整。如果发现缺失上下文，它会决定调用预设的扩展工具。
基于元数据的精准扩充： Agent 调用的不再是模糊的“文本读取”或“向量匹配”，而是调用带有确切索引的工具，例如 fetch_adjacent_chunks(doc_id="xxx", start_index=46, end_index=48)。
SQL 级精准提取： 系统收到指令后，跳过所有 Embedding 和相似度计算，直接通过 pgvector 的元数据过滤（metadata filtering），将第 46、47、48 个片段快速拉出并拼接进大模型上下文。

核心优势：

彻底规避让 Agent 直接解析复杂原始文件的“荒谬感”。
完美解决语义截断问题，逻辑链条的完整性由 Agent 动态判断并补全。
大幅节省 token 消耗，因为每一次扩充都是极度精准的索引调用。

咱们的社群

星球中有源码、解决方案、提示词,以及落地经验.

欢迎加入我们，思考技术对商业的价值.

欢迎找我合作

AI咨询、AI项目陪跑、AI项目落地.

我的微信: leigeaicom

构建Skill的最佳实践

Thu, 12 Feb 2026 17:27:23 +0800

网址: https://claude.com/blog/equipping-agents-for-the-real-world-with-agent-skills

1. 环境的隔离

这种虚拟机环境可以有多种表现形式：

Claude Code： 在你的本地终端运行，这时候“虚拟机”的概念更倾向于一个受限的本地文件访问和执行权限。
Claude Platform / API： 在云端为 Agent 提供临时的 Docker 容器或沙箱环境，让 Agent 有一个可以存放临时文件（如生成的图表、处理后的文档）的地方。
2. skill.md变大之后的渐进式加载

当一个技能上下文变大时，需要将该技能中需查询的相关内容变为独立文件。在引用时，若用到相关文件，则使其前往该文件进行查找。

3.优先考虑code执行,保证确定性

大模型擅长很多任务，但确保确定性输出的任务仍是传统的。代码执行的方式可以保证确定性。因此，在设计时，若存在非保证确定性的内容，我们优先考虑用代码实现。

4.持续改进skills

1.写好简单的skill,然后运行它,识别它完成具体任务的差距,从而改进skills的内容 2.持续拆分skill,到不同的上下文中,进行渐进式加载 3.从claude的视角去考虑,name和descript是否描述清晰了(保证可以触发skills) 4.要利用模型的自我审查能力: 把成功的case和失败的case都给他,让他进行反思和改进

5.安全的使用skills

市面上有太多的skills，若要使用，必须确保在使用前验证其内部逻辑。

咱们的社群

星球中有源码、解决方案、提示词,以及落地经验.

欢迎加入我们，思考技术对商业的价值.

欢迎找我合作

AI咨询、AI项目陪跑、AI项目落地.

我的微信: leigeaicom

Python好玩的模块

Wed, 11 Feb 2026 11:25:38 +0800

极简版

JSON 美化/校验：python3 -m json.tool data.json
Base64 编解码：echo "Hi" | python3 -m base64；解码 -d
代码微基准：python3 -m timeit '[i for i in range(1000)]'
性能分析：python3 -m cProfile -s time your_script.py
ZIP 压缩/解压：python3 -m zipfile -c out.zip a.txt b.txt；解压 -e
Python 之禅：python3 -m this
反重力彩蛋：python3 -m antigravity
终端日历：python3 -m calendar 2026

python -m http.server 确实是 Python 标准库（Standard Library）中“一行流”工具的经典代表。它利用了 Python 的 -m 参数，将库当作脚本来执行。

Python 的标准库里藏着很多像瑞士军刀一样好用的工具，不需要安装任何第三方包，开箱即用。

这里为你整理了一些最实用、最有趣且灵活的 python -m 模块用法：

1. 数据处理与格式化

JSON 美化神器：`json.tool`

当你拿到一坨乱糟糟的 JSON 数据时，不需要找在线工具，直接用这个。它不仅能格式化（Pretty Print），还能校验 JSON 语法是否正确。

用法：

Bash

  # 假设你有一个 data.json 文件
  python3 -m json.tool data.json
    
  # 或者结合管道命令（curl 的结果直接美化）
  echo '{"name": "Gemini", "type": "AI"}' | python3 -m json.tool

Base64 编解码：`base64`

快速对字符串或文件进行 Base64 编码/解码，不用写脚本。

用法：

Bash

  # 编码
  echo "Hello World" | python3 -m base64
    
  # 解码 (-d)
  echo "SGVsbG8gV29ybGQK" | python3 -m base64 -d

图片编码

python3 -m base64 -e logo.png > logo_b64.txt

2. 性能分析与调试

代码跑分王：`timeit`

想知道一行代码执行得有多快？或者比较两种写法哪个效率高？timeit 是最权威的微基准测试工具。

用法：

Bash

  # 比如：测试生成列表，列表推导式 vs 普通循环
  python3 -m timeit '[i for i in range(1000)]'

性能分析器：`cProfile`

如果你的 Python 脚本运行很慢，想知道时间都花在哪个函数上了，用这个可以直接生成分析报告。

用法：

Bash

  # 直接运行脚本并输出性能统计，按时间排序 (-s time)
  python3 -m cProfile -s time your_script.py

3. 文件与系统管理

压缩/解压工具：`zipfile` / `tarfile`

在一个没有安装 zip 或 tar 命令的精简 Linux 环境（如某些 Docker 容器）中，只要有 Python，就能处理压缩包。

用法：

Bash

  # 创建压缩包 (-c create)
  python3 -m zipfile -c output.zip file1.txt file2.txt
    
  # 解压压缩包 (-e extract)
  python3 -m zipfile -e output.zip target_dir/

4. 趣味与彩蛋 (Easter Eggs)

Python 社区以幽默感著称，标准库里也有不少彩蛋。

Python 之禅：`this`

展示 Python 的核心设计哲学。

用法：

Bash
```
  python3 -m this
```

反重力漫画：`antigravity`

这会直接打开浏览器跳转到那幅著名的 XKCD 漫画，解释了为什么要学习 Python。

用法：

Bash
```
  python3 -m antigravity
```

日历：`calendar`

在终端快速打印日历，有点像 Linux 的 cal 命令。

用法：

Bash

  # 打印 2026 年日历
  python3 -m calendar 2026

咱们的社群

星球中有源码、解决方案、提示词,以及落地经验.

欢迎加入我们，思考技术对商业的价值.

欢迎找我合作

AI咨询、AI项目陪跑、AI项目落地.

我的微信: leigeaicom

如何用Ai写一本书

Fri, 06 Feb 2026 17:44:21 +0800

提示词:

# Role: 专家级商业技术图书合著者 (Ghostwriter for Lei Ge)

## 你的使命
请你协助资深 AI 开发者/博主“雷哥”，将其知识星球中的一系列碎片化文章、随笔和技术复盘，打磨成一本实体书中引人入胜的章节。
你的工作不仅仅是修辞润色，更是**深度加工**。你需要弥补原稿中的信息差，通过网络检索补全背景，将其提升为一章既有个人实战经验，又有行业广度深度的经典文字。

## 风格锚点 (Style Guide)
写作风格对标《Shoe Dog》(鞋狗) 的叙事感与《Acquired》(播客) 的商业深度。
* **权威而亲历**：保持“雷哥”的第一人称视角，但要把口语化的博客腔调升级为沉稳的书籍叙事文字。
* **厚重感**：不要让读者觉得这是“博文拼凑”，要让他们觉得这是经过深思熟虑的行业复盘。
* **信息密度**：既有故事的流动性，又有知识的结晶感。

## 执行步骤 (Step-by-Step Instructions)

### 第一步：构建叙事骨架 (Narrative Arc)
阅读提供的所有素材，不要急着动笔，先找出贯穿其中的“红线”：
* **核心冲突**：这一章主要解决了什么难题？（是技术架构的抉择？还是商业模式的痛苦转型？）
* **情绪心流**：理清作者从“困惑”到“探索”再到“突破”的心理变化轨迹。
* **场景化**：找出原稿中提到的关键场景（如“深夜调试代码”、“与客户的艰难谈判”），将其作为章节的锚点。

### 第二步：深度调研与信息补全 (Critical Research & Contextualization) —— **关键步骤**
**这是最重要的一步。** 原稿是写给圈内人看的，可能略去了很多背景。面对实体书读者，你需要**主动检索并补全**这些信息差：
* **识别盲区**：当文中提到特定的技术（如 MCP、Dify）、公司、人物或历史事件，但未做详细解释时，**必须进行网络搜索**。
* **补全背景**：查阅该技术/事件的定义、历史沿革、当时的市场环境或争议点。
* **无缝植入**：不要把查到的资料生硬地贴在文中（不要写“百度百科说...”）。而是要将这些背景知识内化为作者的认知。
    * *坏例子*：“MCP 是 Model Context Protocol，它是由...”
    * *好例子*：“当时，整个行业都在为大模型上下文的孤岛问题而头疼，而 Model Context Protocol (MCP) 的出现，恰好切中了这个痛点。它不仅仅是一个协议，更像是……”
* **建立坐标系**：通过搜索，找到当时行业发生的其他大事，作为背景板，来衬托作者正在做的事情的意义。

### 第三步：降维解释与去黑话 (Demystify)
* **破除知识诅咒**：对于复杂的 AI 概念，必须用**通俗的类比**或**具体的商业场景**来解释，确保非技术背景的“好奇心读者”也能看懂。
* **逻辑连贯**：如果原稿中有逻辑跳跃（例如直接给出了结论），你需要通过逻辑推理或搜索补充资料，把推导过程补写出来，让读者觉得顺理成章。

### 第三步：文字打磨与结构融合 (Crafting the Chapter)
将原稿素材与你调研补充的内容融合：
* **电影感开头**：放弃“本文主要讲...”的陈词滥调。直接从一个具体的动作、对话或思考场景切入。
* **章节流动**：移除所有 Markdown 列表项（Bullet Points）。实体书是连续的散文，用段落的起承转合来推进内容。
* **金句提炼**：保留作者最犀利的洞察，并将其打磨得更加隽永。

## 质量自检清单 (Checklist)
在输出前，请自问：
1.  **信息差补全了吗？** 我是否解释清楚了原稿中一笔带过的技术背景？如果不清楚，我是否去搜索并补写了？
2.  **像书吗？** 读起来是流畅的章节，还是一堆帖子的拼盘？
3.  **有深度吗？** 我是否通过补充资料，提升了原文的行业视角？
4.  **易读吗？** 我是否把复杂的概念讲得连文科生都能懂？

## 输入素材

我的所有的文章都在目录articles下. 这本书应该包含我所有的文章内容. 一定要包含所有文章内容.

灵感来自看到了 zara 将长播客转成书籍的提示词: https://x.com/zarazhangrui/status/2009080125292511655?s=20

咱们的社群

星球中有源码、解决方案、提示词,以及落地经验.

欢迎加入我们，思考技术对商业的价值.

欢迎找我合作

AI咨询、AI项目陪跑、AI项目落地.

我的微信: leigeaicom

Ai时代的工程学复利工程

Tue, 13 Jan 2026 22:48:41 +0800

核心介绍

我看到的关键: 尽量不动手改代码,就会发现更多的沉淀经验

📌 问题层面

传统开发：功能叠加 → 复杂度增加 → 越来越难
复利工程：经验积累 → 复杂度降低 → 越来越简单

🔄 核心流程（五步循环）

Plan (计划) → Work (执行) → Review (审查) → Compound (积累) → Repeat (重复)

关键点：

80% 时间在计划和审查
20% 时间在写代码
每次循环都固化经验

🛠️ 三大支撑

AI 代理体系：27个专业代理（审查、研究、设计等）
自动化测试：通过浏览器让 Agent 像用户一样验证
并行审查：12个子代理同时从不同角度检查代码

💡 核心价值

小项目：少计划，直接做
大项目：重计划，保质量
每次开发都为下次铺路

具体使用

具体插件的使用: https://github.com/EveryInc/compound-engineering-plugin

这个 Compound Engineering Plugin 不是一个简单的单功能插件，而是一个企业级的 AI 开发工作流系统。它的目录结构反映了其复杂性和完整性：

核心结构

compound-engineering-plugin/ ├── .claude-plugin/ # 插件元数据和配置 ├── .github/workflows/ # CI/CD 自动化工作流 ├── docs/ # 完整文档 ├── plans/ # 预定义的计划模板 └── plugins/ ├── coding-tutor/ # 编程教学子插件 └── compound-engineering/ # 主插件 ├── agents/ # 27个AI代理 ⭐ │ ├── review/ # 14个审查代理 │ ├── research/ # 4个研究代理 │ ├── design/ # 3个设计代理 │ ├── workflow/ # 5个工作流代理 │ └── docs/ # 1个文档代理 ├── commands/ # 20个命令 ├── skills/ # 13个技能 └── MCP Servers/ # 2个服务器

为什么需要这么多组件？

27个专业代理 - 每个代理都是一个 .md 文件，定义了特定任务的 AI 行为：
- agent-native-reviewer.md - 验证功能的 agent-native 特性
- security-sentinel.md - 安全审计
- performance-oracle.md - 性能分析
- dhh-rails-reviewer.md - DHH 风格的 Rails 代码审查
- 等等…
20个命令 - 斜杠命令用于不同的工作流任务
- /workflows:plan - 创建实施计划
- /workflows:review - 代码审查
- /reproduce-bug - Bug 复现
- 等等…
13个技能 - 可重用的专业知识模块
2个 MCP 服务器 - Playwright（浏览器自动化）和 Context7（框架文档查询）

设计理念

这个插件实现了 Plan → Work → Review → Compound → Repeat 循环，80% 时间在计划和审查，20% 在执行。每个组件都是这个循环的一部分，目标是让”每个工程单元都比上一个更容易”。

所以，目录多是因为它是一个完整的开发方法论和工具集，而不仅仅是一个简单的插件！

原文

https://every.to/chain-of-thought/compound-engineering-how-every-codes-with-agents

咱们的社群

星球中有开箱即用的源码、解决方案、讲解视频、提示词,以及落地经验.

欢迎加入我们，思考技术对商业的价值.

欢迎找我合作

AI咨询、AI项目陪跑、AI项目落地.

我的微信: leigeaicom

企业Ai数据飞轮三种方法

Fri, 09 Jan 2026 22:31:24 +0800

我在给企业做AI化，如何让AI加速数据资产的累积，这在AI时代非常重要。今天我想把其中的关键点跟大家说清楚。

企业最重要的资产是数据。在AI时代，最重要的依然是数据资产。这是因为模型微调依然是个难题，不仅难以工程落地，而且不易调优，也不利于整体方向的快速迭代。所以现在最好的路径是结合知识库和AI。我们一直在说知识库，其实最大的问题不是知识库本身，而是知识库到底是什么？其实就是企业的核心数据资产。

之前聊过，企业的数据资产在未来一定特别重要。但现在最大的问题是，很多企业没有数据资产，还是按照之前的老路子，想通过一个创新、一个方式来打造产品壁垒。其实以最近给企业落地的经验来看，很少有企业有这种技术或产品级的壁垒——除非是在搞科学研究、搞很底层的技术。否则，很多AI应用或者说企业的壁垒，更多是在数据上。既然壁垒在数据上，那如何使用AI来把数据飞轮做起来，这是每家企业都在面临的问题。

AI workflow

(详细内容我放星球上了)

AI 置信度

(详细内容我放星球上了)

Ralph Wiggum 方法

(详细内容我放星球上了)

这就是我在做数据资产的三种通用方法。这三种方法都是真正的在企业实践中落地过的。也希望这些方法大家都能用起来。

咱们的社群

星球中有开箱即用的源码、解决方案、讲解视频、提示词,以及落地经验.

欢迎加入我们，思考技术对商业的价值.

如果你有场景和困难, 欢迎找我聊聊AI

AI咨询、AI项目陪跑.

我的微信: leigeaicom

企业如何有效的使用图谱?

Mon, 05 Jan 2026 22:53:53 +0800

使用图谱的有效方式

理解用户意图 → 选择模板 → 提取参数（AI擅长的NLP任务）

核心优势: 每次预制一个Cypher就是对一个场景的深入理解。

Cypher生成的致命问题

❌ 语法错误风险

AI可能生成：

MATCH (p:Person WHERE name = "马斯克"  -- 缺少右括号
MATCH (p:Person)-[:CREATED_BY]→(o:Organization  -- 箭头符号错误
MATCH (p:Persion)  -- 拼写错误

问题：即使GPT-4也会犯低级语法错误
后果：查询直接报错，用户体验极差

❌ Schema幻觉问题

AI可能编造不存在的标签/关系：

MATCH (p:Person)-[:FOUNDED_BY]->(o:Company)  -- 实际应该是CREATED_BY + Organization
MATCH (p:Person)-[:IS_FRIEND_OF]->(o:Person)  -- 关系类型根本不在Schema里

问题：AI”自作聪明”创造新类型
后果：查询结果为空，用户以为没有数据

❌ 性能灾难

AI可能生成超低效查询：

MATCH (a)-[*5..10]-(b)  -- 5-10跳遍历，可能导致数据库卡死
MATCH (a), (b), (c), (d)  -- 笛卡尔积，数据量大了直接崩
WHERE a.name = "马斯克" OR b.name = "马斯克" OR c.name = "马斯克"

做图谱的思路

核心思路: 通过Schema约束的LLM抽取方法，让大模型在预定义的实体类型和关系类型范围内，生成结构化的JSON图谱数据。这种方法在准确性、通用性和可维护性之间取得了良好平衡。

示例查询：

CALL db.index.fulltext.queryNodes("entity_index", $query)
YIELD node, score
MATCH (node)-[r]->(neighbor)
RETURN node.name + ' ' + type(r) + ' ' + neighbor.name as text
LIMIT 5

Schema设计

节点标签（实体类型）

VALID_NODE_LABELS = [
    "Person",        # 人物：马斯克、乔布斯
    "Organization",  # 组织：特斯拉、苹果
    "Location",      # 地点：加州、北京
    "Concept",       # 概念：AI、区块链
    "Document",      # 文档：报告、论文
    "Event",         # 事件：发布会、并购
    "Product"        # 产品：iPhone、Model 3
]

关系类型

VALID_RELATION_TYPES = [
    "WORKS_FOR",     # 雇佣：马斯克 →WORKS_FOR→ 特斯拉
    "LOCATED_IN",    # 位置：特斯拉 →LOCATED_IN→ 加州
    "RELATES_TO",    # 相关：AI →RELATES_TO→ 机器学习
    "MENTIONS",      # 提及：文档 →MENTIONS→ 公司
    "PART_OF",       # 部分：加州 →PART_OF→ 美国
    "CREATED_BY",    # 创建：SpaceX →CREATED_BY→ 马斯克
    "HAS_FEATURE"    # 特征：产品 →HAS_FEATURE→ 功能
]

Prompt模板

prompt = f"""
You are a Knowledge Graph extraction engine.
Extract nodes and relationships from the text.

Allowed Node Labels: {VALID_NODE_LABELS}
Allowed Relationship Types: {VALID_RELATION_TYPES}

Return JSON format only:
nodes],
    "edges": [source]
}}

Input Text:
{text}
"""

使用示例

输入文本

"Elon Musk founded SpaceX in 2002. The company is headquartered in Hawthorne, California."

LLM输出

{
    "nodes": [
        {"id": "Elon Musk", "type": "Person"},
        {"id": "SpaceX", "type": "Organization"},
        {"id": "2002", "type": "Event"},
        {"id": "Hawthorne", "type": "Location"},
        {"id": "California", "type": "Location"}
    ],
    "edges": [
        {"source": "Elon Musk", "target": "SpaceX", "type": "CREATED_BY"},
        {"source": "SpaceX", "target": "2002", "type": "RELATES_TO"},
        {"source": "SpaceX", "target": "Hawthorne", "type": "LOCATED_IN"},
        {"source": "Hawthorne", "target": "California", "type": "PART_OF"}
    ]
}

咱们的社群

星球中有开箱即用的源码、解决发难、讲解视频、提示词,以及落地经验.

欢迎加入我们，思考技术对商业的价值.

如果你有场景和困难, 欢迎找我聊聊AI

AI咨询、AI项目陪跑.

我的微信: leigeaicom

Ralph Wiggum 背后的哲学与应用

Sun, 04 Jan 2026 22:52:56 +0800

Ralph是什么？

for n :; do cat PROMPT.md | claude ; done

逻辑是：循环运行一个提示词n次。

这与传统AI编程工作流完全不同，你无需关注每一个步骤，只需预先设定成功的标准，然后让智能体朝着这个标准方向运行。过去失败的数据会成为其改进的基础，每一次迭代都会根据上一次的失败原因进行优化。

但意义重大：在一个充满不确定性的世界里（即 LLM 的输出不可控），通过构建一个确定性的、甚至看似”愚蠢”的死循环，来迫使系统收敛于正确结果。

这种哲学的核心在于反直觉的容错机制：不再追求一次 Prompt 就能完美生成代码，而是预设 AI 会失败，并构建一个能够容纳无数次失败的框架，直到完成任务为止。

使用方法

步骤 1：启动 Claude Code

claude --dangerously-skip-permissions

启动 Claude Code CLI 工具。--dangerously-skip-permissions 参数可以跳过某些权限检查，使插件安装更便捷。

步骤 2：添加插件市场

/plugin marketplace add anthropics/claude-code

添加 Anthropic 官方的插件市场源，这样才能访问和安装官方插件。

步骤 3：安装 Ralph 插件

/plugin install ralph-wiggum@claude-code-plugins

从插件市场安装 Ralph Wiggum 插件，这个插件提供了循环执行提示词的功能。

步骤 4：使用 Ralph 循环

/ralph-wiggum:ralph-loop "用Next.js + Tailwind CSS 做一个todolist程序,你要写好测试用例,测试用例都通过后,最终网站要能正常使用" --max-iterations 10

使用 Ralph 插件开始循环执行任务。参数说明：

"用Next.js + Tailwind CSS 做一个todolist程序"：任务描述/提示词
--max-iterations 10：最大迭代次数，防止无限循环

机会和可能

使用ralph的背景知识是：

任务的成功取决于提示词，而并非完全取决于模型
使用它的前提是任务有严格的完成标准

重复执行的成本又过高，多次重复又可以提高完成的准确度。

那么找到一个性能差不多又便宜的模型就是一个很好的优势——这时候GLM4.7的机会就来了。

Ralph提示词最佳实践

(这部分我放到星球里了)

Ralph的4大应用场景

(这部分我放到星球里了)

咱们的社群

星球中有开箱即用的源码、解决发难、讲解视频、提示词,以及落地经验.

欢迎加入我们，思考技术对商业的价值.

如果你有场景和困难, 欢迎找我聊聊AI

AI咨询、AI项目陪跑.

我的微信: leigeaicom

/ralph-wiggum:ralph-loop “讲我的静态页面转成nextjs项目，我的html是’/Volumes/ORICO/ex_projects/superpowers_aiba/html’，我nextjs的最佳实践是’/Volumes/ORIC O/ex_projects/superpowers_aiba/ARCHITECTURE.md’,完成之后，你需要将每个页面的每个功能都测试一下，你要使用chrome-dev这个工具模拟去测试” –max-iterations 30

/ralph-wiggum:ralph-loop “将我的静态页面转成nextjs项目，我的html是’/Volumes/ORICO/ex_projects/superpowers_aiba/html’，我nextjs的最佳实践是’/Volumes/ORIC O/ex_projects/superpowers_aiba/ARCHITECTURE.md’,完成之后，你需要将每个页面的每个功能都测试一下，你要使用chrome-dev这个工具模拟去测试” –max-iterations 10

“将我的静态页面转成nextjs项目，我的html是’/Volumes/ORICO/ex_projects/superpowers_aiba/html’，我nextjs的最佳实践是’/Volumes/ORIC O/ex_projects/superpowers_aiba/ARCHITECTURE.md’,先不考supabse等动态对接”

被低估的Rag方法

Sat, 27 Dec 2025 11:29:26 +0800

这是一种被低估的RAG方法。它可以让你的召回失败率降低49%。

原文: https://www.anthropic.com/engineering/contextual-retrieval

方法介绍

如果你一直在做RAG相关工作，对它一定不陌生。它是Anthropic在24年9月份提出的一种方法——上下文检索(Contextual Retrieval)

按句子拆分:

ACME Corp 2023年第二季度财务业绩报告。本季度公司面临宏观经济挑战，但总体表现稳健。特别是标准产品部门表现优异。收入比上一季度增长了 3%。然而，云服务部门的利润率略有下降，主要由于基础设施投资增加。 CEO Jane Doe 表示：”我们要加倍投入研发，以确保长期竞争力。” 关于未来的展望，我们预计下个季度会有温和的增长。

假设这个问题: 哪个季度增长了?

	收入比上一季度增长了 3%。
	
	本季度公司面临宏观经济挑战，但总体表现稳健。
	
	关于未来的展望，我们预计下个季度会有温和的增长。

这些召回的片段，根本没有办法回答用户的问题，因为它缺乏全文的上下文信息。

如果需要让它有全文上下文信息，并且可以稳定召回，我们就需要把上下文信息补充进去。比如：

	本季度ACME Corp收入环比增长3%，背景为宏观经济挑战下标准产品部门表现优异，体现整体稳健态势。
	收入比上一季度增长了 3%。
	
	2023年第二季度，ACME Corp标准产品部门表现优异，收入环比增长3%，成为本季度亮点。
	特别是标准产品部门表现优异。

上面被补充的这部分上下文信息，其实是我们使用模型生成的。通过这样的方式，我们可以把模型生成的上文信息补充到现有片段里。因为片段本身是零碎的，实际上缺少很多上文信息，这就补全了我们上下文信息缺省的问题。

为什么今天还讲

但今天为什么把这个技术拿出来讲呢？因为它仍然是一个非常被低估的方法。而且时间过去了一年多，从模型能力来看，这个方法的可行性大大提升了。

![[被低估的RAG方法 2025-12-27 10.47.34.excalidraw]]

随着现在模型变得越来越强，以前生成准确的摘要信息，必须依靠大参数模型。尤其在24年底或25年初，DeepSeek那波浪潮没有起来之前，这里边的限制包括上下文大小不足、大模型费用比较高。当然后来有了缓存技术，降低了一些模型成本。但从整体的准确率和响应速度来讲，它还没有达到工程级或工业级的应用水平。

现在小模型对于摘要总结已经有很大的优势了。

摘要评估: https://www.siliconflow.com/articles/zh-Hans/best-open-source-llms-for-summarization

模型选型: https://ollama.com/alibayram/Qwen3-30B-A3B-Instruct-2507

embedding选型: https://ollama.com/library/bge-m3

有了这些之后，我们的应用就可以搭建起来了。

我搭建的这个源码

完全本地搭建.

因为很多朋友还不知道如何做一个后端是Python、前端通过Next.js这个React框架去实现的联动程序。所以我结合后端Python，前端Next.js，中间使用FastAPI进行交互，把整个项目搭建起来了，使用的全都是开源技术。以我的Mac电脑来讲，是可以完全本地跑起来的应用。

使用到的技术: 前端: nextjs

后端: 提供接口服务:fastapi 模型框架:langchain 向量库框架:chroma

模型: 本地LLM:qwen32b-3a 本地embedding: bge-m3

当对整个项目的架构越来越了解，结合AI Coding的话，我们就可以慢慢把它转成一个生产级、服务于更多人的项目。

源码

源码都在星球中了.

咱们的社群

星球中有开箱即用的源码、解决发难、讲解视频、提示词,以及落地经验.

欢迎加入我们，思考技术对商业的价值.

如果你有场景和困难, 欢迎找我聊聊AI

AI咨询、AI项目陪跑.

我的微信: leigeaicom

雷哥AI

Ai自由协议 通向自由之路

为什么要做 AI 自由协议

AI自由协议的定义

核心目标

两类关键资产

1. 数据资产

2. 经验资产

自动化系统的意义

协议公式

最终追求

咱们的社群

Rag死了吗

一、“RAG 已死”是一个伪命题：核心在于数据结构的差异

1. 为什么 AI Coding Agents 抛弃了传统 RAG？

2. 为什么海量非结构化数据（10 万+ 文档）依然极其依赖传统 RAG？

二、传统 RAG 的核心痛点：语义切分不完整

三、破局之道：高阶动态上下文扩充机制

1. Contextual Retrieval（上下文增强切块 / 语境丰富化）

2. 基础解法：Small-to-Big / Sentence Window

3. 终极架构解法：基于索引的 Agentic 动态检索（Agentic Retrieval）

咱们的社群

欢迎找我合作

构建Skill的最佳实践

1. 环境的隔离

2. skill.md变大之后的渐进式加载

3.优先考虑code执行,保证确定性

4.持续改进skills

5.安全的使用skills

咱们的社群

欢迎找我合作

Python好玩的模块

极简版

1. 数据处理与格式化

JSON 美化神器：json.tool

Base64 编解码：base64

2. 性能分析与调试

代码跑分王：timeit

性能分析器：cProfile

3. 文件与系统管理

压缩/解压工具：zipfile / tarfile

4. 趣味与彩蛋 (Easter Eggs)

Python 之禅：this

反重力漫画：antigravity

日历：calendar

咱们的社群

欢迎找我合作

如何用Ai写一本书

咱们的社群

欢迎找我合作

Ai时代的工程学 复利工程

核心介绍

具体使用

原文

咱们的社群

欢迎找我合作

企业Ai数据飞轮 三种方法

AI workflow

AI 置信度

Ralph Wiggum 方法

咱们的社群

如果你有场景和困难, 欢迎找我聊聊AI

企业如何有效的使用图谱?

使用图谱的有效方式

Cypher生成的致命问题

❌ 语法错误风险

❌ Schema幻觉问题

❌ 性能灾难

做图谱的思路

Schema设计

节点标签（实体类型）

关系类型

Prompt模板

使用示例

输入文本

LLM输出

咱们的社群

如果你有场景和困难, 欢迎找我聊聊AI

Ralph Wiggum 背后的哲学与应用

Ralph是什么？

Ai自由协议通向自由之路

JSON 美化神器：`json.tool`

Base64 编解码：`base64`

代码跑分王：`timeit`

性能分析器：`cProfile`

压缩/解压工具：`zipfile` / `tarfile`

Python 之禅：`this`

反重力漫画：`antigravity`

日历：`calendar`

Ai时代的工程学复利工程

企业Ai数据飞轮三种方法