Auto-sync: 2026-04-27 20:02

wiki/concepts/Account-Monitoring.md

@@ -0,0 +1,37 @@
+---
+title: "Account-Monitoring"
+type: concept
+tags: ["monitoring", "social-media", "automation", "notification", "twitter"]
+last_updated: 2026-04-27
+---
+
+## Overview
+Account-Monitoring 是指持续追踪指定 X/Twitter 账号的内容发布或粉丝变动并触发通知的自动化技术。
+
+## Definition
+通过 API 定期轮询或订阅目标账号的最新动态（推文发布、转发、粉丝变化等），当检测到变化时自动向用户发送通知。
+
+## Key Characteristics
+- **持续追踪**：不间断监控目标账号状态变化
+- **多维度监控**：
+  - 新推文/转发发布
+  - 粉丝数量变化
+  - 关注/取消关注操作
+- **主动通知**：检测到变化时自动推送通知，无需用户主动查询
+- **可配置阈值**：可设置仅在特定条件触发时通知（如粉丝数突破阈值）
+
+## Implementation
+在 [[x-twitter-automation]] 中，通过 [[TweetClaw]] 的 Monitors 功能实现：
+1. 配置监控目标账号列表
+2. 定期通过 API 获取账号最新状态
+3. 与上次状态对比，检测变化
+4. 变化发生时自动向用户发送通知
+
+## Related Use Cases
+- [[x-twitter-automation]] — TweetClaw 提供账号监控功能
+
+## Sources
+- [[x-twitter-automation]]
+
+## Connections
+- [[X/Twitter-API-Automation]] ← powers ← [[Account-Monitoring]]（监控功能依赖 API 获取账号动态）

wiki/concepts/Content-Aggregation.md

@@ -0,0 +1,28 @@
+---
+title: "Content-Aggregation"
+type: concept
+tags: [RSS, Data-Pipeline, Information-Retrieval]
+sources: [multi-source-tech-news-digest.md]
+last_updated: 2026-04-27
+---
+
+# Content-Aggregation
+
+内容聚合——将来自多个异构来源的信息统一收集、去重、标准化后呈现的机制，是解决信息碎片化问题的核心手段。
+
+## Definition
+
+从多个来源（RSS、社交媒体、API、Web 抓取等）收集内容，通过合并、去重、排序等处理，最终生成统一的结构化输出。
+
+## Key Characteristics
+
+- **多来源合并**：支持不同协议和格式（RSS/Atom、JSON API、HTML 爬取等）
+- **标准化**：统一内容格式（标题、摘要、URL、时间戳、来源标签）
+- **时序整合**：按时间线重新排序跨来源的内容
+- **质量分层**：按来源权威性、用户偏好等对内容分级
+
+## Related Concepts
+
+- [[Content-Deduplication]]：内容聚合的前置步骤
+- [[Quality-Scoring]]：内容聚合的后置筛选
+- [[RSSHub]]：生成标准化 RSS 的工具，使不原生支持 RSS 的来源可被聚合

wiki/concepts/Content-Deduplication.md

@@ -0,0 +1,27 @@
+---
+title: "Content-Deduplication"
+type: concept
+tags: [Data-Processing, NLP, Similarity-Matching]
+sources: [multi-source-tech-news-digest.md]
+last_updated: 2026-04-27
+---
+
+# Content-Deduplication
+
+内容去重——识别并合并重复或近似内容的技术，解决同一内容从多个渠道涌入造成的冗余问题。
+
+## Definition
+
+通过计算标题/摘要的相似度（如 Jaccard 相似度、余弦相似度、编辑距离），判断两条内容是否指向同一信息，并将重复项合并。
+
+## Approaches
+
+- **精确匹配**：基于 URL、唯一 ID 去重（适用于同一平台内的内容）
+- **模糊匹配**：基于标题/摘要的语义或字符串相似度去重（适用于跨平台聚合）
+- **聚类去重**：将相似内容聚类，每类只保留一条代表
+
+## Related Concepts
+
+- [[Content-Aggregation]]：去重是内容聚合流程中的关键步骤
+- [[Quality-Scoring]]：去重后对每类的代表内容进行评分
+- [[Semantic-Search]]：语义相似度技术同样可用于去重

wiki/concepts/Cowork-UI.md

@@ -0,0 +1,21 @@
+---
+title: "Cowork-UI"
+type: concept
+tags: [ai-agent, ui, visualization]
+sources: [aionui-cowork-desktop]
+last_updated: 2026-04-27
+---
+
+## Definition
+
+Cowork-UI 是一种 AI Agent 桌面协作界面范式——在可视化工作空间中实时展示 Agent 读写文件、运行终端命令、浏览网页的全过程，用户不再是"只能看日志"，而是真正"看见 Agent 在做什么"。
+
+## Key Characteristics
+- **操作可视化**：文件读写、终端命令、网页浏览等操作均有图形化展示
+- **多 Agent 并行**：支持 OpenClaw、Claude Code、Codex 等 12+ Agent 在同一界面中切换或并行运行
+- **上下文共享**：工作空间内所有 Agent 共享同一 MCP 配置
+
+## Related Concepts
+- [[Remote-Rescue]]：Cowork-UI 的远程接入扩展
+- [[Multi-Agent-Unified-MCP]]：Cowork-UI 的配置统一机制
+- [[Tool-Integration]]：Cowork-UI 的工具层基础

wiki/concepts/GAS-Gameplay-Ability-System.md

@@ -1,9 +1,11 @@
 ---
-title: "GAS (Gameplay Ability System)"
+title: GAS Gameplay Ability System
 type: concept
 tags: [unreal-engine, networking, multiplayer, ue5, abilities]
-sources: ["unreal-multiplayer-architect", "unreal-systems-engineer"]
+sources: 
 last_updated: 2026-04-26
+---
+
 
 ## Additional Sources
 Gameplay Ability System（GAS）是 UE5 的可扩展技能与属性框架，通过 UGameplayAbility、UAttributeSet、UAbilitySystemComponent 实现网络就绪的技能系统。[[UnrealSystemsEngineer]] 补充：所有 Tick 逻辑必须 C++；FGameplayTag 优于字符串标识符；通过 UPROPERTY(ReplicatedUsing=OnRep_Health) + GAMEPLAYATTRIBUTE_REPNOTIFY 宏实现属性复制。

wiki/concepts/Gatekeeper.md

@@ -1,69 +1,69 @@
-# Gatekeeper
-
-> macOS 的安全机制，用于验证应用程序是否来自已识别的开发者可信来源。
-
-## Overview
-Gatekeeper 是 macOS 的应用安全验证系统，旨在保护用户免受恶意软件的侵害。它会检查应用程序的来源和签名状态，拒绝运行未授权的软件。
-
-## How It Works
-Gatekeeper 会在用户尝试运行从互联网下载的应用程序时触发验证流程：
-1. 检查应用是否来自 App Store
-2. 检查是否有有效的 Developer ID 签名
-3. 检查是否被标记为已隔离（quarantined）
-
-## Quarantine Attribute
-macOS 使用扩展属性（Extended Attributes）来标记从互联网下载的文件：
-- `com.apple.quarantine`：标记文件来自互联网下载
-- `com.apple.metadata`：包含下载来源 URL 等元数据
-
-## Removing Quarantine
-```bash
-# 递归移除 quarantine 属性（适用于目录）
-xattr -rd com.apple.quarantine /path/to/application/
-
-# 验证（无输出表示解除成功）
-xattr /path/to/application/binary
-
-# 查看 quarantine 状态
-xattr -l /path/to/application/binary
-```
-
-## Gatekeeper Modes
-```bash
-# 查看当前 Gatekeeper 状态
-spctl --status
-
-# 允许所有来源（不推荐，存在安全风险）
-sudo spctl --master-disable
-
-# 查看应用状态
-spctl --assess --verbose /path/to/application
-```
-
-## Use Cases
-- **Homebrew**：安装后需解除 quarantine 才能运行
-- **FRP**：从 GitHub 下载的二进制文件需解除限制
-- **第三方工具**：任何未签名的可执行文件
-
-## Security Considerations
-| 方法 | 安全性 | 适用场景 |
-|------|--------|----------|
-| Developer ID 签名 | 最高 | 正式发布的软件 |
-| App Store | 高 | 仅限 App Store 应用 |
-| 解除 quarantine | 低 | 自托管工具/开发环境 |
-
-## Best Practices
-1. **仅对可信来源解除限制**：如 GitHub Release 官方二进制文件
-2. **使用 -r 递归参数**：确保目录内所有文件解除限制
-3. **验证文件完整性**：下载后检查 SHA256 校验和
-4. **保持 Gatekeeper 开启**：除非完全了解风险，否则不要禁用
-
-## Related Concepts
-- [[launchd]] — macOS 服务管理器
-- [[frp]] — 需要解除 Gatekeeper 才能运行
-- [[Mac Mini M4]] — 需要处理 Gatekeeper 问题
-
-## References
-- Apple Support: Safely open apps on your Mac
-- `man xattr`
-- `man spctl`
+# Gatekeeper
+
+> macOS 的安全机制，用于验证应用程序是否来自已识别的开发者可信来源。
+
+## Overview
+Gatekeeper 是 macOS 的应用安全验证系统，旨在保护用户免受恶意软件的侵害。它会检查应用程序的来源和签名状态，拒绝运行未授权的软件。
+
+## How It Works
+Gatekeeper 会在用户尝试运行从互联网下载的应用程序时触发验证流程：
+1. 检查应用是否来自 App Store
+2. 检查是否有有效的 Developer ID 签名
+3. 检查是否被标记为已隔离（quarantined）
+
+## Quarantine Attribute
+macOS 使用扩展属性（Extended Attributes）来标记从互联网下载的文件：
+- `com.apple.quarantine`：标记文件来自互联网下载
+- `com.apple.metadata`：包含下载来源 URL 等元数据
+
+## Removing Quarantine
+```bash
+# 递归移除 quarantine 属性（适用于目录）
+xattr -rd com.apple.quarantine /path/to/application/
+
+# 验证（无输出表示解除成功）
+xattr /path/to/application/binary
+
+# 查看 quarantine 状态
+xattr -l /path/to/application/binary
+```
+
+## Gatekeeper Modes
+```bash
+# 查看当前 Gatekeeper 状态
+spctl --status
+
+# 允许所有来源（不推荐，存在安全风险）
+sudo spctl --master-disable
+
+# 查看应用状态
+spctl --assess --verbose /path/to/application
+```
+
+## Use Cases
+- **Homebrew**：安装后需解除 quarantine 才能运行
+- **FRP**：从 GitHub 下载的二进制文件需解除限制
+- **第三方工具**：任何未签名的可执行文件
+
+## Security Considerations
+| 方法 | 安全性 | 适用场景 |
+|------|--------|----------|
+| Developer ID 签名 | 最高 | 正式发布的软件 |
+| App Store | 高 | 仅限 App Store 应用 |
+| 解除 quarantine | 低 | 自托管工具/开发环境 |
+
+## Best Practices
+1. **仅对可信来源解除限制**：如 GitHub Release 官方二进制文件
+2. **使用 -r 递归参数**：确保目录内所有文件解除限制
+3. **验证文件完整性**：下载后检查 SHA256 校验和
+4. **保持 Gatekeeper 开启**：除非完全了解风险，否则不要禁用
+
+## Related Concepts
+- [[launchd]] — macOS 服务管理器
+- [[frp]] — 需要解除 Gatekeeper 才能运行
+- [[Mac Mini M4]] — 需要处理 Gatekeeper 问题
+
+## References
+- Apple Support: Safely open apps on your Mac
+- `man xattr`
+- `man spctl`

wiki/concepts/Generation.md

@@ -1,33 +1,33 @@
----
-title: "Generation"
-type: concept
-tags: [rag, generation, llm, prompt, reasoning]
-last_updated: 2025-01-16
----
-
-## Definition
-Generation（生成阶段）是 RAG Pipeline 的第三步，将用户问题与 Retrieval 阶段检索到的相关文档块组合为 Prompt，输入 LLM 生成最终答案。
-
-## Process
-1. **Context Assembly**：将用户问题（Question）与 Top-k 个相关文档块（Context）放入字典结构：`{"question": ..., "context": ...}`
-2. **Prompt Templating**：通过 PromptTemplate 将 Question 和 Context 组合为结构化的 Prompt String
-3. **LLM Inference**：将 Prompt 输入 LLM，LLM 严格基于上下文中提供的信息生成答案
-4. **Output Parsing**：从 LLM 输出中提取纯字符串结果
-
-## Key Requirements for Generation
-- **Source Grounding**：LLM 必须严格基于检索到的上下文生成，不能凭空发挥
-- **Answer Attribution**：理想情况下应提供答案的来源引用（哪些文档块支持该答案）
-
-## In RAG Pipeline
-- **上游**：接收 Retrieval 阶段返回的文档块作为上下文
-- **下游**：输出最终答案给用户
-
-## Frameworks Simplify This
-LangChain 和 LlamaIndex 将 Retrieval + Generation 封装为 RAG Chain（如 RetrievalQA Chain），只需几行代码即可完成端到端 Pipeline。
-
-## Related Concepts
-- [[RAG]] — Generation 是 RAG Pipeline 的第三阶段
-- [[Retrieval]] — Generation 的上游，提供上下文
-- [[PromptTemplate]] — 组装 Question + Context 的模板技术
-- [[Chain]] — LangChain 中串联 Retrieval 和 Generation 的抽象
-- [[Large Language Model]] — 实际执行生成任务的模型
+---
+title: "Generation"
+type: concept
+tags: [rag, generation, llm, prompt, reasoning]
+last_updated: 2025-01-16
+---
+
+## Definition
+Generation（生成阶段）是 RAG Pipeline 的第三步，将用户问题与 Retrieval 阶段检索到的相关文档块组合为 Prompt，输入 LLM 生成最终答案。
+
+## Process
+1. **Context Assembly**：将用户问题（Question）与 Top-k 个相关文档块（Context）放入字典结构：`{"question": ..., "context": ...}`
+2. **Prompt Templating**：通过 PromptTemplate 将 Question 和 Context 组合为结构化的 Prompt String
+3. **LLM Inference**：将 Prompt 输入 LLM，LLM 严格基于上下文中提供的信息生成答案
+4. **Output Parsing**：从 LLM 输出中提取纯字符串结果
+
+## Key Requirements for Generation
+- **Source Grounding**：LLM 必须严格基于检索到的上下文生成，不能凭空发挥
+- **Answer Attribution**：理想情况下应提供答案的来源引用（哪些文档块支持该答案）
+
+## In RAG Pipeline
+- **上游**：接收 Retrieval 阶段返回的文档块作为上下文
+- **下游**：输出最终答案给用户
+
+## Frameworks Simplify This
+LangChain 和 LlamaIndex 将 Retrieval + Generation 封装为 RAG Chain（如 RetrievalQA Chain），只需几行代码即可完成端到端 Pipeline。
+
+## Related Concepts
+- [[RAG]] — Generation 是 RAG Pipeline 的第三阶段
+- [[Retrieval]] — Generation 的上游，提供上下文
+- [[PromptTemplate]] — 组装 Question + Context 的模板技术
+- [[Chain]] — LangChain 中串联 Retrieval 和 Generation 的抽象
+- [[Large Language Model]] — 实际执行生成任务的模型

wiki/concepts/Hybrid-Search.md

@@ -1,51 +1,27 @@
----
-title: "Hybrid Search"
-type: concept
-tags: [search, vector, bm25, retrieval]
-sources: [semantic-memory-search, knowledge-base-rag]
-last_updated: 2026-04-22
----
-
-## Definition
-
-混合搜索结合两种或多种检索策略——通常是稠密向量检索（语义相似性）和稀疏关键词检索（BM25）——通过排名融合算法合并结果，兼顾语义理解和精确匹配。是当前 RAG 系统提升召回率的主流方法。
-
-## How It Works
-
-```
-查询 → [向量检索（ANN）] ─┐
-     → [BM25 关键词检索] ──┼─→ Reciprocal Rank Fusion (RRF) → 融合排名结果
-     → [其他检索器] ──────┘
-```
-
-1. **向量检索**：Embedding 模型将查询编码为向量，通过 ANN 索引（如 HNSW）找到语义相近的文档块
-2. **BM25 检索**：传统关键词检索，统计词频和文档频率，返回字面匹配的文档块
-3. **RRF 融合**：对各检索器的排名结果按 `1/(k+rank)` 公式融合，k 为平滑参数（通常 k=60）
-
-## Why Not Pure Vector Search?
-
-纯向量搜索的局限性：
-- **同义词覆盖不足**：Embedding 空间无法覆盖所有同义词（如"缓存"vs"cache"）
-- **专有名词精度低**：罕见词/新词/数字类实体的向量表示不够精确
-- **计算成本高**：向量检索的计算量随向量维度增长
-
-混合搜索通过 BM25 补充关键词精确匹配，同时保留向量搜索的语义理解能力。
-
-## Key Insight
-
-> "Hybrid search beats pure vector search. Combining semantic similarity (dense vectors) with keyword matching (BM25) via Reciprocal Rank Fusion catches both meaning-based and exact-match queries." — memsearch 文档
-
-## Implementation
-
-| 组件 | 说明 |
-|------|------|
-| 向量检索器 | Milvus / Pinecone / FAISS / Qdrant |
-| BM25 | Elasticsearch / OpenSearch / rank_bm25 |
-| RRF 融合 | 自实现或向量数据库内置 |
-| Embedding | OpenAI text-embedding-3 / BGE / Sentence-BERT |
-
-## Connections
-- [[semantic-memory-search]] — memsearch 使用混合搜索策略
-- [[Knowledge-Base-RAG]] — 混合搜索是知识库 RAG 提升召回率的关键
-- [[Semantic-Search]] — 混合搜索是纯语义搜索的增强版
-- [[Reciprocal Rank Fusion]] — 混合搜索的融合算法
+---
+title: "HybridSearch"
+type: concept
+tags: []
+---
+
+## Definition
+混合搜索，结合多种检索方法以获得比单一搜索方法更优的结果。
+
+## Key Characteristics
+- 结合语义相似度搜索（稠密向量）与关键词精确匹配（BM25）
+- 通过倒数排名融合（RRF）综合多个搜索结果的排名
+- 兼顾"按意思查找"和"按关键词查找"两种需求
+
+## How It Works
+1. **稠密向量搜索**：将查询和文档都嵌入到向量空间，计算语义相似度
+2. **BM25 搜索**：基于词频和文档频率的传统关键词匹配
+3. **RRF 融合**：综合两个排名列表，生成最终排序
+
+## Use Cases
+- [[memsearch]] 使用混合搜索提升记忆检索精度
+- [[Knowledge-Base-RAG]] 混合搜索优化知识库查询
+
+## Related Concepts
+- [[Semantic-Search]] — 纯语义搜索（仅向量）
+- [[Reciprocal-Rank-Fusion]] — 倒数排名融合
+- [[RAG]] — 检索增强生成技术

wiki/concepts/Incremental-Indexing.md

@@ -0,0 +1,27 @@
+---
+title: "IncrementalIndexing"
+type: concept
+tags: []
+---
+
+## Definition
+增量索引，只处理新增或变化的内容，避免重新处理未变化的数据。
+
+## Key Mechanism
+使用内容哈希（如 SHA-256）标识每个文档块：
+1. 首次索引：计算哈希，存储 (哈希, 内容, 向量)
+2. 后续索引：重新计算哈希，仅对不匹配的块进行嵌入
+3. 未变化的块：跳过，零 API 调用
+
+## Benefits
+- **节省成本**：只嵌入新增/变化内容
+- **提升速度**：跳过已索引内容
+- **一致性保证**：相同内容始终生成相同向量
+
+## Application
+- [[memsearch]] 使用 SHA-256 内容哈希实现增量索引
+- 文档原文始终是真相，索引是派生缓存
+
+## Related Concepts
+- [[memsearch]] — 实现增量索引的工具
+- [[RAG]] — 检索增强生成

wiki/concepts/Knowledge-Base.md

@@ -0,0 +1,26 @@
+---
+title: "Knowledge Base"
+type: concept
+last_updated: 2026-04-27
+---
+
+## Definition
+
+集中存储、结构化索引、可按需检索的个人或组织知识集合——将分散的信息（文章、笔记、文档、网页）转化为可搜索、可链接的知识资产。
+
+## Key Characteristics
+
+- **集中存储**：所有知识来源统一入口（URL/文件/对话内容）
+- **结构化索引**：通过 Embedding 向量化或 Metadata 标签实现高效检索
+- **可搜索**：支持关键词搜索、语义搜索或两者混合搜索
+- **可链接**：知识条目之间相互引用，形成知识网络
+
+## Relationship to Related Concepts
+
+- [[Semantic Search]]：知识库的核心检索技术
+- [[RAG]]：知识库是 RAG 系统的外部知识来源
+- [[Second Brain]]：知识库的终极目标——成为个人的第二大脑
+- [[Personal Knowledge Base (RAG)]]：知识库在个人场景的具体实现（URL 摄入 + 语义搜索）
+
+## Sources
+- [[knowledge-base-rag]]

wiki/concepts/Multi-Agent-Unified-MCP.md

@@ -0,0 +1,20 @@
+---
+title: "Multi-Agent-Unified-MCP"
+type: concept
+tags: [ai-agent, mcp, configuration]
+sources: [aionui-cowork-desktop]
+last_updated: 2026-04-27
+---
+
+## Definition
+
+Multi-Agent-Unified-MCP 是一种在单一应用（AionUi）中统一配置 MCP Server，使其自动同步至所有共存 Agent（OpenClaw、Claude Code、Codex 等）的机制——用户只需配置一次 MCP，所有 Agent 即可共享同一工具集，无需逐个 Agent 重复配置。
+
+## Key Characteristics
+- **一次配置全局生效**：在 AionUi 中配置 MCP Server，自动同步
+- **消除重复配置**：12+ Agent 共享同一 MCP 配置，无需逐个设置
+- **工具一致性**：所有 Agent 调用相同的 MCP 工具接口
+
+## Related Concepts
+- [[MCP]]：Multi-Agent-Unified-MCP 的底层协议
+- [[Cowork-UI]]：Multi-Agent-Unified-MCP 的承载界面

wiki/concepts/Multi-Channel-Delivery.md

@@ -1,27 +1,35 @@
----
-title: "Multi-Channel Delivery"
-type: concept
-tags: []
----
-
-## Definition
-多渠道内容投递模式——同一内容根据用户偏好同时或选择性地通过多个平台（Discord、Email、Telegram 等）进行投递，提升触达率和用户便利性。
-
-## Common Channels
-| 渠道 | 特点 | 适用场景 |
-|------|------|----------|
-| Discord | 频道制、社区感、支持富文本 | 社区内容推送 |
-| Email | 正式、可存档、适合长内容 | Newsletter、报告 |
-| Telegram | 即时、话题制、跨设备同步 | 个人助理、私人简报 |
-| Slack | 团队协作、频道/话题隔离 | 工作流通知 |
-
-## Design Pattern
-```
-[内容生成器] → [渠道适配层] → [Discord] / [Email] / [Telegram]
-                              (用户偏好决定投递渠道组合)
-```
-
-## Related Concepts
-- [[Daily-Digest]] — 投递内容的一种常见形式
-- [[Quality-Scoring-Algorithm]] — 投递前的内容筛选
-- [[Preference-Learning]] — 根据用户反馈持续优化渠道选择
+---
+title: "Multi-Channel-Delivery"
+type: concept
+tags: [Notification, Delivery, Platform-Integration]
+sources: [multi-source-tech-news-digest.md]
+last_updated: 2026-04-27
+---
+
+# Multi-Channel-Delivery
+
+多渠道分发——将内容或消息同步推送至多个平台（Discord、邮件、Telegram 等），满足用户在不同场景下的信息消费习惯。
+
+## Definition
+
+同一内容通过多个独立的投递通道（频道）发送，每条通道可能有自己的格式规范、限流规则和用户触达方式。
+
+## Common Channels
+
+| 渠道 | 典型场景 | 特点 |
+|------|----------|------|
+| Discord | 社区通知、机器人推送 | Webhook、多频道、Rich Embed |
+| Email | 正式报告、每日摘要 | MIME 格式、退信处理 |
+| Telegram | 即时通知、私聊/频道 | Bot API、Markdown 格式 |
+| Slack | 团队协作通知 | Webhook、Block Kit |
+
+## Design Principles
+
+- **平台适配**：每条渠道的内容格式需适配（如 Telegram 支持 Markdown，Email 需纯文本 fallback）
+- **去重投递**：避免同一用户通过多个渠道收到重复通知
+- **失败重试**：投递失败时的指数退避重试机制
+
+## Related Concepts
+
+- [[Content-Aggregation]]：多渠道分发的内容来源
+- [[Cron-Job]]：定时触发多渠道分发任务的调度机制

wiki/concepts/OpenClaw-Deployment-Expert.md

@@ -0,0 +1,22 @@
+---
+title: "OpenClaw-Deployment-Expert"
+type: concept
+tags: [ai-agent, deployment, troubleshooting]
+sources: [aionui-cowork-desktop]
+last_updated: 2026-04-27
+---
+
+## Definition
+
+OpenClaw-Deployment-Expert 是 AionUi 内置的 OpenClaw 安装、诊断与修复引导工具——帮助用户在桌面环境中完成 OpenClaw 的完整部署，并在 Agent 出现故障时提供远程诊断和自助修复指导，包括 `openclaw doctor` 诊断命令、配置文件修复和 gateway 重启操作。
+
+## Key Characteristics
+- **安装引导**：协助安装 OpenClaw（`npm install -g openclaw@latest`）
+- **诊断命令**：`openclaw doctor` 自动诊断常见故障
+- **配置修复**：自动识别并修复配置文件问题
+- **gateway 重启**：远程重启 OpenClaw gateway
+- **远程可用**：通过 Telegram/WebUI 远程调用，无需人到机器现场
+
+## Related Concepts
+- [[Remote-Rescue]]：OpenClaw-Deployment-Expert 的典型使用场景
+- [[OpenClaw]]：OpenClaw-Deployment-Expert 的服务对象

wiki/concepts/Pattern-Key.md

@@ -0,0 +1,40 @@
+---
+title: "Pattern-Key"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-17
+---
+
+## 定义
+经验记录（Learning）中的分类键字段，用于跨时间识别同一类问题是否重复出现。格式：`领域.子领域.具体问题`（如 `cron.telegram-delivery`）。
+
+## 使用方式
+记录到 LEARNINGS.md 的 Metadata 中：
+```markdown
+### Metadata
+- Pattern-Key: cron.telegram-delivery
+```
+
+## 核心信号
+**Pattern-Key 重复本身就是一个信号——第一次记了，第二次就该解决了。**
+
+## 实际案例
+| Pattern-Key | 出现次数 | 含义 | 处理策略 |
+|------------|---------|------|---------|
+| `cron.daily-self-review` | 9次 | 每日复盘活跃领域 | 持续积累，每次深化 |
+| `cron.telegram-delivery` | 2次 | Telegram通知配置 | 第二次解决后不再出现 |
+| `cron.naming-convention` | 1次 | 任务命名规范 | 一次性错误，无需跟进 |
+
+## 区分原则
+- 同一 Pattern-Key 多次出现 → 系统性问题，需要根本性解决
+- 只出现一次 → 偶发性错误，记录即可
+
+## 相关 Concept
+- [[Self-Improving-Skill]]：Pattern-Key 的承载结构
+- [[Recurrence-Count]]：配合 Pattern-Key 判断问题严重程度
+- [[每日复盘机制]]：检查 Pattern-Key 重复的执行机制
+
+## Aliases
+- pattern key
+- 模式键

wiki/concepts/Personal-CRM.md

@@ -1,51 +1,51 @@
----
-title: "Personal CRM"
-type: concept
-tags: []
-last_updated: 2026-04-22
----
-
-## Aliases
-- Personal Customer Relationship Management
-- 联系人关系管理
-
-## Definition
-基于 AI Agent 的个人联系人管理系统，通过自动发现而非手动录入维护人际关系记忆，核心价值在于零摩擦积累和主动会议准备。
-
-## Key Attributes
-
-| 属性 | 描述 |
-|------|------|
-| 数据来源 | Gmail、Google Calendar（通过 gog CLI） |
-| 存储结构 | SQLite（联系人表：姓名、邮箱、首见时间、末联系时间、互动次数、备注） |
-| 查询接口 | Telegram Topic（personal-crm）自然语言查询 |
-| 触发机制 | Cron Job（每日联系人扫描 + 每日会议简报） |
-| AI 框架 | OpenClaw |
-
-## Workflow
-
-1. **每日 6AM Cron Job**：扫描 Gmail + Calendar 过去 24 小时
-2. **提取新联系人**：自动识别邮件/日历中的外部参与者
-3. **更新数据库**：新增或更新已有联系人的互动记录
-4. **每日 7AM Cron Job**：查询当天日历，收集每位外部参会者背景
-5. **推送简报**：Telegram 投递会前准备（含上次交流内容、待跟进事项）
-6. **按需查询**：Telegram personal-crm topic 接收自然语言查询
-
-## 与相关概念的区分
-
-| 概念 | 差异点 |
-|------|--------|
-| [[Second Brain]] | 非结构化任意内容捕获，Personal CRM 侧重结构化联系人关系 |
-| [[Local CRM Framework]] | DenchClaw 侧重本地 Web UI + 数据导入；Personal CRM 侧重自动发现 |
-| [[Email Triage]] | 侧重邮件分拣；Personal CRM 侧重联系人关系追踪 |
-| [[Meeting Prep Briefing]] | Personal CRM 的子功能之一 |
-
-## 实现方案
-
-- **[[personal-crm]]**（本文档来源）：OpenClaw + gog CLI + SQLite + Telegram Topic
-- **[[local-crm-framework]]**（DenchClaw）：OpenClaw + DuckDB + Web UI + 浏览器自动化
-
-## Sources
-- [[personal-crm]]
-- [[local-crm-framework]]
-- [[multi-channel-assistant]]
+---
+title: "Personal CRM"
+type: concept
+tags: []
+last_updated: 2026-04-27
+---
+
+## Aliases
+- Personal Customer Relationship Management
+- 联系人关系管理
+
+## Definition
+基于 AI Agent 的个人联系人管理系统，通过自动发现而非手动录入维护人际关系记忆，核心价值在于零摩擦积累和主动会议准备。
+
+## Key Attributes
+
+| 属性 | 描述 |
+|------|------|
+| 数据来源 | Gmail、Google Calendar（通过 gog CLI） |
+| 存储结构 | SQLite（联系人表：姓名、邮箱、首见时间、末联系时间、互动次数、备注） |
+| 查询接口 | Telegram Topic（personal-crm）自然语言查询 |
+| 触发机制 | Cron Job（每日联系人扫描 + 每日会议简报） |
+| AI 框架 | OpenClaw |
+
+## Workflow
+
+1. **每日 6AM Cron Job**：扫描 Gmail + Calendar 过去 24 小时
+2. **提取新联系人**：自动识别邮件/日历中的外部参与者
+3. **更新数据库**：新增或更新已有联系人的互动记录
+4. **每日 7AM Cron Job**：查询当天日历，收集每位外部参会者背景
+5. **推送简报**：Telegram 投递会前准备（含上次交流内容、待跟进事项）
+6. **按需查询**：Telegram personal-crm topic 接收自然语言查询
+
+## 与相关概念的区分
+
+| 概念 | 差异点 |
+|------|--------|
+| [[Second Brain]] | 非结构化任意内容捕获，Personal CRM 侧重结构化联系人关系 |
+| [[Local CRM Framework]] | DenchClaw 侧重本地 Web UI + 数据导入；Personal CRM 侧重自动发现 |
+| [[Email Triage]] | 侧重邮件分拣；Personal CRM 侧重联系人关系追踪 |
+| [[Meeting Prep Briefing]] | Personal CRM 的子功能之一 |
+
+## 实现方案
+
+- **[[personal-crm]]**（本文档来源）：OpenClaw + gog CLI + SQLite + Telegram Topic
+- **[[local-crm-framework]]**（DenchClaw）：OpenClaw + DuckDB + Web UI + 浏览器自动化
+
+## Sources
+- [[personal-crm]]
+- [[local-crm-framework]]
+- [[multi-channel-assistant]]

wiki/concepts/Quality-Scoring.md

@@ -0,0 +1,30 @@
+---
+title: "Quality-Scoring"
+type: concept
+tags: [Ranking, Filtering, AI-Processing]
+sources: [multi-source-tech-news-digest.md]
+last_updated: 2026-04-27
+---
+
+# Quality-Scoring
+
+质量评分——对聚合内容按多维度指标打分，以优先级排序的机制，解决信息过载下的内容筛选问题。
+
+## Definition
+
+通过预设规则或 AI 辅助，对每条内容从多个维度赋予分值（如权威性、时效性、相关性、互动量），综合计算后决定内容的展示优先级。
+
+## Scoring Dimensions
+
+| 维度 | 示例 | 分值范围 |
+|------|------|----------|
+| 优先级来源 | 权威媒体/KOL/官方账号 | +1 ~ +5 |
+| 多来源交叉 | 同一内容被多个来源报道 | +3 ~ +5 |
+| 时效性 | 距发布时间越近分数越高 | +1 ~ +3 |
+| 互动量 | 点赞/评论/分享数 | +1 ~ +2 |
+
+## Related Concepts
+
+- [[Content-Aggregation]]：质量评分作用于聚合后的内容
+- [[Content-Deduplication]]：去重是评分的前置步骤
+- [[RAG]]：RAG 中的 reranking 与质量评分思路类似

wiki/concepts/RAG.md

@@ -1,35 +1,35 @@
----
-title: "RAG"
-type: concept
-tags: [rag, retrieval, llm, ai]
-last_updated: 2025-04-23
----
-
-## Definition
-检索增强生成（Retrieval-Augmented Generation，RAG）是将大语言模型（LLM）链接到外部实时知识库的技术，通过检索+生成的流程提升答案准确性和时效性。
-
-## Core Mechanism
-1. **检索（Retrieval）**：当用户提问时，从外部知识库（向量数据库/知识图谱/公司文档）中检索最相关的信息块（Chunk）
-2. **增强生成（Augmented Generation）**：将检索结果与用户问题作为上下文输入 LLM，指示其严格基于上下文生成答案
-
-## Key Benefits
-- **知识更新与定制**：无需重新训练即可获取最新信息
-- **消除幻觉**：提供事实依据，显著降低胡说八道的风险
-- **引用来源**：可追溯信息来源，增加可信度
-- **成本效益**：相比微调，成本更低、更新更快
-
-## Role in AI System Architecture
-- **认知层**：RAG 作为 AI 系统的"记忆系统"，负责信息获取与准确性保障
-- 补充 [[Large Language Model]] 的知识时效性局限
-- 为 [[AI Agent]] 提供可信赖的信息来源
-
-## Related Concepts
-- [[Large Language Model]] — 被增强的底层模型
-- [[AI Agent]] — 依赖 RAG 提供准确信息
-- [[Hybrid Search]] — RAG 常用检索策略
-- [[Semantic Search]] — 向量检索的核心技术
-
-## Sources
-- [[llms-rag-ai-agent-三个到底什么区别]]
-- [[rag从入门到精通系列1-基础rag]]
-- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]
+---
+title: "RAG"
+type: concept
+tags: [rag, retrieval, llm, ai]
+last_updated: 2026-04-27
+---
+
+## Definition
+检索增强生成（Retrieval-Augmented Generation，RAG）是将大语言模型（LLM）链接到外部实时知识库的技术，通过检索+生成的流程提升答案准确性和时效性。
+
+## Core Mechanism
+1. **检索（Retrieval）**：当用户提问时，从外部知识库（向量数据库/知识图谱/公司文档）中检索最相关的信息块（Chunk）
+2. **增强生成（Augmented Generation）**：将检索结果与用户问题作为上下文输入 LLM，指示其严格基于上下文生成答案
+
+## Key Benefits
+- **知识更新与定制**：无需重新训练即可获取最新信息
+- **消除幻觉**：提供事实依据，显著降低胡说八道的风险
+- **引用来源**：可追溯信息来源，增加可信度
+- **成本效益**：相比微调，成本更低、更新更快
+
+## Role in AI System Architecture
+- **认知层**：RAG 作为 AI 系统的"记忆系统"，负责信息获取与准确性保障
+- 为 [[AI Agent]] 提供可信赖的信息来源
+
+## Sources
+- [[llms-rag-ai-agent-三个到底什么区别]]
+- [[rag从入门到精通系列1-基础rag]]
+- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]
+- [[knowledge-base-rag]]
+
+## Related Concepts
+- [[Large Language Model]] — 被增强的底层模型
+- [[AI Agent]] — 依赖 RAG 提供准确信息
+- [[Hybrid Search]] — RAG 常用检索策略
+- [[Semantic Search]] — 向量检索的核心技术

wiki/concepts/RRF-Reranking.md

@@ -0,0 +1,27 @@
+---
+title: "RRF-Reranking"
+type: concept
+tags: []
+---
+
+## Definition
+RRF（Reciprocal Rank Fusion，倒数排名融合）是一种融合多个排序结果的技术，通过综合不同搜索方法的排名生成统一排序。
+
+## Formula
+```
+RRF_score(d) = Σ 1/(k + rank_i(d))
+```
+其中 k 是平滑因子（通常为60），rank_i(d) 是文档 d 在第 i 个排名列表中的位置。
+
+## Key Characteristics
+- 无需人工调参，对不同搜索方法一视同仁
+- 排名靠前的文档在融合时权重更高
+- 计算简单，可实时融合多个搜索结果
+
+## Application
+- [[memsearch]] 使用 RRF 融合稠密向量搜索和 BM25 搜索的结果
+- [[HybridSearch]] 的核心重排机制
+
+## Related Concepts
+- [[HybridSearch]] — 混合搜索（RRF 是其组成部分）
+- [[Semantic-Search]] — 语义搜索

wiki/concepts/Recurrence-Count.md

@@ -0,0 +1,44 @@
+---
+title: "Recurrence-Count"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-17
+---
+
+## 定义
+Learning 记录 Metadata 中的重复次数字段，用于追踪同一 Pattern-Key 下问题出现的次数。格式：
+```markdown
+### Metadata
+- Recurrence-Count: 2
+- See Also: LRN-20260325-001
+```
+
+## 核心价值
+**区分一次性错误与系统性重复，是最重要的指标之一。**
+
+## 解读原则
+| Recurrence-Count | 含义 | 处理策略 |
+|-----------------|------|---------|
+| 1 | 首次出现，观察 | 正常记录 |
+| 2 | 重复出现 | 第二次就该彻底解决；未解决说明上次 Suggested Action 无效，需重新分析 |
+| ≥3 | 系统性问题 | 需要根本性架构/流程改进，而非单次修复 |
+
+## 实际案例
+- Telegram chat ID 格式错误：`Recurrence-Count: 2` → 第二次直接应用 `Suggested Action: 使用纯数字 chat ID`，问题解决
+- 每日复盘：`Recurrence-Count: 9` → 说明这是一个持续活跃优化的领域，每次复盘都在积累经验
+
+## 与 Pattern-Key 的关系
+- [[Pattern-Key]] 回答"这个问题属于哪一类"
+- [[Recurrence-Count]] 回答"这类问题出现了多少次"
+
+两者配合使用：Pattern-Key 重复 + Recurrence-Count ≥ 2 = 需要系统性解决
+
+## 相关 Concept
+- [[Pattern-Key]]：Recurrence-Count 的分类维度
+- [[Self-Improving-Skill]]：Recurrence-Count 的承载结构
+- [[每日复盘机制]]：检查 Recurrence-Count 的执行时机
+
+## Aliases
+- recurrence count
+- 重复次数

wiki/concepts/Remote-Rescue.md

@@ -0,0 +1,21 @@
+---
+title: "Remote-Rescue"
+type: concept
+tags: [ai-agent, remote, troubleshooting]
+sources: [aionui-cowork-desktop]
+last_updated: 2026-04-27
+---
+
+## Definition
+
+Remote-Rescue 是一种 AI Agent 远程故障修复能力——当 Agent（如 OpenClaw）不可达时，用户通过远程通道（Telegram/WebUI）接入 AionUi，使用内置部署专家执行诊断命令（`openclaw doctor`）、修复配置、重启 gateway，实现无需人到机器现场的远程修复。
+
+## Key Characteristics
+- **远程通道接入**：Telegram、WebUI、Lark、DingTalk
+- **内置诊断专家**：内置 OpenClaw 部署专家，引导安装、诊断、修复
+- **自助修复能力**：`openclaw doctor` 诊断、自动修复配置、gateway 重启
+- **解决痛点**：Agent 坏了但人不在机器旁边的困境
+
+## Related Concepts
+- [[OpenClaw-Deployment-Expert]]：Remote-Rescue 的执行主体
+- [[Cowork-UI]]：Remote-Rescue 的用户交互界面

wiki/concepts/Self-Improving-Skill.md

@@ -1,98 +1,62 @@
----
-title: "Self-Improving-Skill"
-type: concept
-tags: [openclaw, memory, agentic-ai]
-sources: [养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享]
-last_updated: 2026-04-17
----
-
-## Aliases
-- self-improving skill
-- self-improving
-- Self-Improving
-
-## Definition
-
-Self-Improving Skill 是一个结构化的 Agent 经验记录系统。当 AI Agent 遇到问题、做出决策、或发现值得记住的洞见时，调用 `self_improvement_log` 工具，将内容写入 `LEARNINGS.md` 或 `ERRORS.md`。核心目标：**让同一个错误只犯一次，第二次就知道怎么做对**。
-
-## 核心机制
-
-### 记录格式（固定结构）
-
-```markdown
-## [LRN-YYYYMMDD-NNN] correction | workflow | config
-
-**Logged**: YYYY-MM-DDTHH:MM:SS+08:00
-**Priority**: high | medium | low
-**Status**: pending | resolved | dismissed
-**Area**: config | workflow | memory | cron | telegram | ...
-
-### Summary
-一句话描述学到了什么
-
-### Details
-具体发生了什么、问题出在哪
-
-### Suggested Action
-以后遇到类似情况该怎么做（**必须具体到可直接执行**）
-
-### Metadata
-- Pattern-Key: <category.sub-category>
-- Recurrence-Count: 1
-- See Also: LRN-YYYYMMDD-NNN
-```
-
-### 记录类型
-
-| 类型 | 用途 | 示例 |
-|------|------|------|
-| `correction` | 错误修正 | "Telegram chat ID 不应使用 user: 前缀" |
-| `workflow` | 流程改进 | "创建每日复盘 cron job 机制" |
-| `config` | 配置发现 | "cron job 的 deliver 默认不推送 Telegram" |
-
-### 核心字段
-
-- **Pattern-Key**：经验记录的分类键，用于识别重复踩坑信号（如 `cron.telegram-delivery`）。**重复出现是系统性问题的警示灯**。
-- **Recurrence-Count**：元数据中的重复次数字段。**最重要的指标之一**——区分一次性偶发错误与需要系统性解决的重复问题。
-
-## 使用原则
-
-1. **每错必记，但分类要准确**。分类清晰，Pattern-Key 才能真正起作用
-2. **Suggested Action 必须具体到能直接执行**——写 `--to 5038825565`，而非"注意配置格式"
-3. **每次复盘检查 Pattern-Key 重复**。同一个 Pattern-Key 出现第二次时，必须追问：上一次解决了吗？为什么又出现？
-4. **Recurrence-Count 是决策依据**：值高意味着需要系统性解决，而非继续记录
-
-## 与双层记忆架构的关系
-
-Self-Improving-Skill 是[[双层记忆架构]]的第三层（self-improving 层）：
-
-- **短期记忆层**：每日对话记录文件（`memory/YYYY-MM-DD.md`）
-- **长期记忆层**：基于 [[LanceDB]] 的向量数据库（memory-lancedb-pro）
-- **self-improving 层**：每日 23:00 定时复盘，将 learnings 写入文件，检查 Pattern-Key 重复
-
-三层各司其职：**每日文件管上下文，向量数据库管知识，self-improving 管成长**。
-
-## 与每日复盘机制的关系
-
-[[每日复盘机制]] 是 self-improving skill 的执行入口。每天 23:00（北京时间）自动执行复盘流程：
-
-1. 读取当天 memory 文件
-2. 调用 `self_improvement_log` 记录今日学习
-3. 检查是否有 Pattern-Key 与之前重复
-4. 把有价值的经验同步到 memory-lancedb-pro（长期记忆）
-5. 通过 Telegram 发送复盘摘要
-
-## 效果与价值
-
-- **错误只犯一次**：同一个坑第二次就知道怎么修，Recurrence-Count = 2 后再也不会犯
-- **发现静默漏洞**：每日复盘能发现"3月27日没有 memory 文件"这类正常情况下不会主动想到的问题
-- **从单次修正进化到系统性改进**：从"文件保存后要验证"（correction）进化到"建立每日复盘机制"（workflow）
-- **区分一次性错误与系统性重复**：Pattern-Key + Recurrence-Count 提供量化决策依据
-
-## References
-- [[养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享]]
-- [[每日复盘机制]]
-- [[双层记忆架构]]
-- [[Pattern-Key]]
-- [[Recurrence-Count]]
-- [[LEARNINGS.md]]
+---
+title: "Self-Improving-Skill"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-17
+---
+
+## 定义
+结构化经验记录系统——AI Agent 遇问题时调用 `self_improvement_log` 工具，将经验写入 `LEARNINGS.md` 或 `ERRORS.md`，供后续对话检索应用。
+
+## 核心结构
+固定格式的 learning 记录（LRN-[日期]-[序号]）：
+```markdown
+## [LRN-20260325-001] correction
+
+**Logged**: 2026-03-25T14:09:53+08:00
+**Priority**: high
+**Status**: pending
+**Area**: config
+
+### Summary
+一句话描述学到了什么
+
+### Details
+具体发生了什么、问题出在哪
+
+### Suggested Action
+以后遇到类似情况该怎么做
+
+### Metadata
+- Pattern-Key: cron.telegram-delivery
+- Recurrence-Count: 1
+- See Also: LRN-20260325-005
+```
+
+## 记录类型
+- `correction`：错误修正（如 Telegram chat ID 格式错误）
+- `workflow`：流程改进（如 memory 文件创建时机优化）
+- `config`：配置发现（如 cron delivery 配置）
+
+## 关键字段
+- **Pattern-Key**：识别重复踩坑信号，同一 Pattern-Key 第二次出现说明第一次未彻底解决
+- **Recurrence-Count**：重复次数字段，区分一次性错误与系统性重复
+
+## 核心价值
+**错误只犯一次，第二次就知道怎么做对。** Suggested Action 必须具体到可直接执行（如 `--to 5038825565`），而非泛泛建议。
+
+## 相关 Concept
+- [[双层记忆架构]]：Self-Improving 是三层记忆中的最顶层
+- [[每日复盘机制]]：定时触发 Self-Improvement-Log 的执行机制
+- [[Pattern-Key]]：识别系统性重复的关键字段
+- [[Recurrence-Count]]：区分一次性错误与系统性问题的指标
+
+## 相关 Entity
+- [[OpenClaw]]：提供 cron 定时任务调度能力
+- [[LEARNINGS.md]]：存放结构化经验记录的文件
+
+## Aliases
+- self-improving skill
+- self-improving
+- self_improvement_log

wiki/concepts/Semantic-Search.md

@@ -1,36 +1,39 @@
----
-title: "Semantic Search"
-type: concept
-last_updated: 2026-04-22
----
-
-## Definition
-
-基于 Embedding 向量模型将文本编码为高维向量，通过向量相似度（如余弦相似度）而非关键词匹配来检索相关内容的搜索方式。相比 BM25/BM25 等传统关键词检索，能捕捉语义层面的相关性，例如"我保存的关于 LLM memory 的内容？"能匹配到讨论 agent 记忆机制的文章，即使两者用词不同。
-
-## How It Works
-
-```
-用户查询 → Embedding 模型编码 → 高维向量
-文档库 → Embedding 模型编码 → 文档向量集合
-↓
-向量相似度计算（ANN 索引）→ Top-K 结果 → LLM 回答
-```
-
-## Components
-
-| 组件 | 说明 |
-|------|------|
-| Embedding 模型 | text-embedding-3-small、BGE、Sentence-BERT 等 |
-| ANN 索引 | FAISS / HNSW / ScaNN，实现十亿级向量近实时检索 |
-| 相似度度量 | 余弦相似度 / 点积 / 欧氏距离 |
-
-## Why It Matters in RAG
-
-关键词搜索依赖字面匹配，容易漏掉同义词/多义词场景。语义搜索理解查询意图，使 [[Knowledge-Base-RAG]] 返回真正相关结果而非机械的字面匹配。
-
-## Connections
-
-- [[Knowledge-Base-RAG]] — 语义搜索是知识库 RAG 的检索层
-- [[Vector-Embedding]] — 语义搜索的底层编码技术
-- [[Hybrid Search]] — 向量检索 + BM25 关键词检索融合，进一步提升召回率
+---
+title: "Semantic Search"
+type: concept
+last_updated: 2026-04-27
+---
+
+## Definition
+
+基于 Embedding 向量模型将文本编码为高维向量，通过向量相似度（如余弦相似度）而非关键词匹配来检索相关内容的搜索方式。相比 BM25/BM25 等传统关键词检索，能捕捉语义层面的相关性，例如"我保存的关于 LLM memory 的内容？"能匹配到讨论 agent 记忆机制的文章，即使两者用词不同。
+
+## How It Works
+
+```
+用户查询 → Embedding 模型编码 → 高维向量
+文档库 → Embedding 模型编码 → 文档向量集合
+↓
+向量相似度计算（ANN 索引）→ Top-K 结果 → LLM 回答
+```
+
+## Components
+
+| 组件 | 说明 |
+|------|------|
+| Embedding 模型 | text-embedding-3-small、BGE、Sentence-BERT 等 |
+| ANN 索引 | FAISS / HNSW / ScaNN，实现十亿级向量近实时检索 |
+| 相似度度量 | 余弦相似度 / 点积 / 欧氏距离 |
+
+## Why It Matters in RAG
+
+关键词搜索依赖字面匹配，容易漏掉同义词/多义词场景。语义搜索理解查询意图，使 [[Knowledge-Base-RAG]] 返回真正相关结果而非机械的字面匹配。
+
+## Sources
+- [[knowledge-base-rag]]
+
+## Connections
+
+- [[Knowledge-Base-RAG]] — 语义搜索是知识库 RAG 的检索层
+- [[Vector-Embedding]] — 语义搜索的底层编码技术
+- [[Hybrid Search]] — 向量检索 + BM25 关键词检索融合，进一步提升召回率

wiki/concepts/Social-Media-Giveaway.md

@@ -0,0 +1,37 @@
+---
+title: "Social-Media-Giveaway"
+type: concept
+tags: ["giveaway", "social-media", "automation", "random-selection", "twitter"]
+last_updated: 2026-04-27
+---
+
+## Overview
+Social-Media-Giveaway 是指通过程序化方式从社交媒体（尤其是 X/Twitter）推文的互动用户中随机抽取获奖者的自动化技术，支持多条件筛选。
+
+## Definition
+利用社交媒体 API 自动提取推文的点赞者、转发者、引用转发者或评论者，从中按预设规则随机抽取获奖者，确保公平性和可验证性。
+
+## Key Characteristics
+- **随机抽取**：程序化随机选择，确保公平
+- **可配置筛选条件**：
+  - 最低粉丝数要求（过滤机器人/低质量账号）
+  - 账号年龄限制（排除新注册账号）
+  - 关键词要求（确保用户参与质量）
+- **自动化**：从数据提取到抽奖结果全程无需人工干预
+- **可验证**：抽奖过程可追溯、可复现
+
+## Implementation
+在 [[x-twitter-automation]] 中，通过 [[TweetClaw]] 的 Giveaways 功能实现：
+1. 通过 API 提取推文的互动用户列表（点赞者/转发者/评论者）
+2. 应用筛选条件过滤不满足要求的账号
+3. 随机抽取符合条件的中奖者
+4. 输出中奖者名单供运营者确认
+
+## Related Use Cases
+- [[x-twitter-automation]] — TweetClaw 提供抽奖功能实现
+
+## Sources
+- [[x-twitter-automation]]
+
+## Connections
+- [[X/Twitter-API-Automation]] ← powers ← [[Social-Media-Giveaway]]（抽奖功能依赖 API 获取互动用户数据）

wiki/concepts/X-Twitter-API-Automation.md

@@ -0,0 +1,29 @@
+---
+title: "X/Twitter-API-Automation"
+type: concept
+tags: ["twitter", "x", "api", "automation", "social-media"]
+last_updated: 2026-04-27
+---
+
+## Overview
+X/Twitter-API-Automation 是指通过 X/Twitter 官方 API 接口程序化控制 X/Twitter 账号行为，替代手动操作或爬虫方案的技术手段。
+
+## Definition
+通过 X/Twitter 官方提供的 API 接口，以编程方式执行发帖、回复、点赞、转发、关注、发送私信、搜索、数据提取等操作的自动化技术。
+
+## Key Characteristics
+- **官方 API**：通过 X/Twitter 托管 API 完成操作，非第三方爬虫
+- **安全性**：无需浏览器 Cookie、无凭证暴露风险
+- **可编程**：支持自然语言指令触发，或预设规则自动执行
+- **多功能**：覆盖发帖互动、搜索提取、抽奖工具、账号监控等场景
+
+## Related Use Cases
+- [[x-twitter-automation]] — 通过 TweetClaw 实现自然语言驱动的 X/Twitter 全功能自动化
+- [[x-account-analysis]] — 通过 Bird Skill 分析 X 账号内容模式
+
+## Sources
+- [[x-twitter-automation]]
+
+## Connections
+- [[Social-Media-Giveaway]] ← uses ← [[X/Twitter-API-Automation]]（抽奖功能依赖 API 提取互动用户数据）
+- [[Account-Monitoring]] ← uses ← [[X/Twitter-API-Automation]]（监控功能依赖 API 获取账号动态）

wiki/concepts/双层记忆架构.md

@@ -0,0 +1,47 @@
+---
+title: "双层记忆架构"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-17
+---
+
+## 定义
+AI Agent 的多层次持久化记忆方案，由三层构成：
+1. **短期记忆层**：每日对话记录文件（`memory/YYYY-MM-DD.md`）
+2. **长期记忆层**：基于 LanceDB 的向量数据库（`memory-lancedb-pro`）
+3. **Self-Improving 层**：每日 23:00 定时复盘 + 结构化经验记录
+
+## 架构设计
+| 层级 | 存储介质 | 作用 | 检索方式 |
+|------|---------|------|---------|
+| 短期记忆 | 文件系统（每日文件） | 管上下文 | 文件名/日期 |
+| 长期记忆 | LanceDB 向量数据库 | 管知识 | 语义搜索 |
+| Self-Improving | LEARNINGS.md | 管成长 | Pattern-Key |
+
+## 核心理念
+**每日文件管上下文，向量数据库管知识，self-improving 管成长。**
+
+## 解决的问题
+- AI Agent "每次对话都是一张白纸" 的失忆问题
+- 上下文窗口限制导致的历史信息丢失
+- 重复踩坑（同类错误反复出现）
+
+## 实际案例
+- 3月27日 memory 文件为空 → 发现"只在第一次对话时创建文件"的漏洞 → 推动修改为"每次 Session 启动时都检查并创建当天文件"
+- Telegram chat ID 格式错误只犯了两次就再也没出现
+
+## 相关 Concept
+- [[Self-Improving-Skill]]：最顶层的成长机制
+- [[每日复盘机制]]：触发 Self-Improving 层的定时任务
+- [[Pattern-Key]]：跨记忆层识别重复问题的信号
+- [[Recurrence-Count]]：区分一次性错误与系统性重复
+
+## 相关 Entity
+- [[LanceDB]]：长期记忆层的底层引擎
+- [[OpenClaw]]：提供文件系统和定时任务能力
+
+## Aliases
+- 双层记忆
+- 三层记忆架构
+- memory architecture

wiki/concepts/品味作为护城河.md

@@ -0,0 +1,32 @@
+---
+title: "品味作为护城河"
+type: concept
+tags: [AI, 竞争力, 认知框架]
+last_updated: 2026-04-27
+---
+
+## Definition
+AI时代核心竞争力不是掌握AI工具，而是**判断AI产出质量的能力**（品味）。当AI工具被民主化后，品味成为人与人之间最后的护城河。
+
+## Core Insight
+- 工具民主化：任何人都能用AI写代码、做设计、生成内容
+- 品味不对称：90%的人不知道什么是真正好的
+- 护城河机制：能判断AI给出的10个方案里哪个是insanely great的人，比只会点「生成」按钮的人强一百倍
+
+## Origin
+乔布斯引用1984年Mac发布桌面出版后的现象：工具民主化后，90%的桌面出版内容丑陋不堪。AI时代面临同样的问题。
+
+## Related Concepts
+- [[端到端优势]]：品味需要通过完整做事来积累
+- [[死亡过滤器]]：找到真正热爱的领域来培养品味
+
+## Examples
+- 设计师：能判断10个AI生成的logo里哪个真正好
+- 开发者：能从10个AI代码方案中选出最优雅的
+- 作家：能识别AI生成的文字中哪篇真正有灵魂
+
+## Referenced In
+- [[不谈技术-普通人该怎么在ai时代赚钱]]
+
+## Sources
+- [[不谈技术-普通人该怎么在ai时代赚钱]]

wiki/concepts/死亡过滤器.md

@@ -0,0 +1,37 @@
+---
+title: "死亡过滤器"
+type: concept
+tags: [AI, 个人发展, 人生哲学]
+last_updated: 2026-04-27
+---
+
+## Definition
+每天早上对着镜子问自己：**「如果今天是最后一天，我还会做今天要做的事吗？」** —— 用这个过滤器来找到真正值得投入热情的事物，而不是追逐「最赚钱的AI技能」这类别人的问题。
+
+## Core Insight
+- 别问「什么AI技能最赚钱」—— 这是别人的问题
+- 问自己「我对什么东西有genuine的热爱和curiosity？」
+- 然后用AI把它做到极致
+
+## Mechanism
+1. 用死亡过滤器对当前所有待办/追求进行过滤
+2. 找到过滤后仍留下来的事物 → 这是真正值得做的事
+3. 将AI能力与真正热爱的事物结合
+
+## Examples from the Article
+- 喜欢做饭 → 用AI做一个别人从没见过的美食体验
+- 喜欢教小孩 → 用AI做一个让学习变得magical的东西
+- 喜欢某个很窄的领域 → 你的品味+AI的能力 = 独特优势
+
+## Origin
+乔布斯每天早上使用的自我审视方法，文中用以类比：在AI时代，普通人应该用死亡过滤器找到真正的 passion，然后借助AI的力量将其放大。
+
+## Related Concepts
+- [[品味作为护城河]]：真正的热爱是培养品味的前提
+- [[端到端优势]]：将热爱转化为端到端的完整产品/服务
+
+## Referenced In
+- [[不谈技术-普通人该怎么在ai时代赚钱]]
+
+## Sources
+- [[不谈技术-普通人该怎么在ai时代赚钱]]

wiki/concepts/每日复盘机制.md

@@ -1,58 +1,40 @@
----
-title: "每日复盘机制"
-type: concept
-tags: [openclaw, automation, memory, cron]
-sources: [养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享]
-last_updated: 2026-04-17
----
-
-## Definition
-
-每日复盘机制是 [[OpenClaw]] 多 Agent 系统中的自动经验总结流程。每天固定时间（23:00 北京时间）通过 cron 任务自动触发，Agent 回顾当天工作、记录学习、更新记忆。核心目标：**在不被要求时主动发现问题和改进机会**。
-
-## 执行流程
-
-每天 23:00（北京时间），每个 Agent 独立运行自己的复盘流程：
-
-1. **读取当天 memory 文件**（`memory/YYYY-MM-DD.md`）
-2. **调用 `self_improvement_log`** 记录今日学习（分类：correction / workflow / config）
-3. **检查 Pattern-Key 重复**——如果发现同一个 Pattern-Key 出现多次，说明该问题需要系统性解决
-4. **把有价值的经验同步到长期记忆**（memory-lancedb-pro 向量数据库）
-5. **通过 Telegram 发送复盘摘要**
-
-## 复盘发现静默漏洞的能力
-
-复盘机制的价值不仅在于记录已知错误，更在于**主动发现正常情况下不会想到的问题**。例如：
-
-- **LRN-20260328-001** 发现：3月27日的 memory 文件是空的——原来设计只在"第一次对话时"创建 memory 文件，如果一整天都没有对话，文件就不会被创建
-- 这个静默漏洞导致第二天 Agent 想读取 3/27 的记录，发现什么都没有
-- **没有复盘，这个漏洞可能永远不会被发现**
-
-## 与其他组件的关系
-
-- **触发器**：[[OpenClaw]] cron 任务系统（`every day at 23:00`）
-- **执行工具**：`self_improvement_log` 工具 → 写入 [[LEARNINGS.md]]
-- **数据源**：每日对话记录文件（`memory/YYYY-MM-DD.md`）
-- **输出目标**：长期记忆向量数据库 + Telegram 摘要
-- **上层机制**：[[Self-Improving-Skill]]
-
-## 与 Self-Improving-Skill 的关系
-
-[[每日复盘机制]] 是 [[Self-Improving-Skill]] 的**执行入口**。Self-Improving-Skill 定义了经验记录的格式和原则，每日复盘机制负责**定期激活**这一流程。两者的关系：
-
-- Self-Improving-Skill = 记录规范（What to log）
-- 每日复盘机制 = 触发时机（When to log）
-
-## 实践建议
-
-- 每个 Agent 独立运行自己的复盘流程
-- 复盘摘要通过 Telegram 发送给用户，保持透明
-- Pattern-Key 出现重复时，必须追问"上一次解决了吗？为什么又出现？"
-- 有价值的经验同时写入向量数据库，供语义搜索召回
-
-## References
-- [[养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享]]
-- [[Self-Improving-Skill]]
-- [[双层记忆架构]]
-- [[Pattern-Key]]
-- [[OpenClaw]]
+---
+title: "每日复盘机制"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-17
+---
+
+## 定义
+每天 23:00（北京时间）自动执行的复盘流程——通过 OpenClaw cron 任务实现，每个 Agent 独立运行自己的复盘流程。
+
+## 复盘流程（5步）
+1. 读取当天的 memory 文件（`memory/YYYY-MM-DD.md`）
+2. 调用 `self_improvement_log` 记录今日学习
+3. 检查是否有 Pattern-Key 与之前重复（重复踩坑的信号）
+4. 把有价值的经验同步到 memory-lancedb-pro（长期记忆）
+5. 通过 Telegram 发送复盘摘要
+
+## 核心价值
+**发现静默漏洞**：没有人会主动去想"3月27日有没有生成 memory 文件"这种问题，但复盘机制会发现它。
+
+## Pattern-Key 监控
+- `cron.daily-self-review`：活跃持续优化领域（已出现 9 次）
+- `cron.telegram-delivery`：第二次出现即解决
+- `cron.naming-convention`：一次性错误
+
+## 相关 Concept
+- [[Self-Improving-Skill]]：复盘内容的具体载体
+- [[双层记忆架构]]：复盘机制是三层中的最高层
+- [[Pattern-Key]]：复盘时检查重复踩坑的关键字段
+- [[Recurrence-Count]]：判断问题严重程度的指标
+
+## 相关 Entity
+- [[OpenClaw]]：提供 cron 定时任务能力
+
+## Aliases
+- 每日复盘
+- 23:00 复盘
+- self-review
+- daily review

wiki/concepts/端到端优势.md

@@ -0,0 +1,27 @@
+---
+title: "端到端优势"
+type: concept
+tags: [AI, 创业思维, 竞争力]
+last_updated: 2026-04-27
+---
+
+## Definition
+不做别人AI流水线上的一个零件，而是用AI做一个完整的产品/服务/解决方案，从头到尾控制——这种「端到端」的做法比在团队中充当单一环节更有价值，也更抗AI替代。
+
+## Core Insight
+- **零件的宿命**：在AI流水线上当「AI提示词工程师」是最容易被替换的位置
+- **端到端的优势**：一个人用AI做出一个完整的App，比100人团队里当AI提示词工程师强一万倍
+- **控制全链**：从用户需求理解→产品设计→开发→交付→迭代，全部由你控制
+
+## Origin
+乔布斯引用iPod的成功：不是因为有最好的MP3解码器，而是因为有从iTunes（内容生态）→ iPod（硬件）→ iTunes Store（商业闭环）的完整体验。
+
+## Related Concepts
+- [[品味作为护城河]]：端到端做事的品味决定产品质量
+- [[死亡过滤器]]：找到真正想做的端到端项目
+
+## Referenced In
+- [[不谈技术-普通人该怎么在ai时代赚钱]]
+
+## Sources
+- [[不谈技术-普通人该怎么在ai时代赚钱]]