Auto-sync: 2026-04-16 13:01

wiki/concepts/Telegram-Webhook.md

@@ -0,0 +1,37 @@
+---
+title: "Telegram Webhook"
+type: concept
+tags: [telegram, webhook, bot, integration]
+---
+
+## 定义
+Telegram Webhook 是一种服务端回调机制：Telegram 服务器在用户发送消息后，将 HTTP POST 请求推送至用户配置的公网 HTTPS URL。
+
+## 工作原理
+1. 在 Telegram BotFather 创建机器人，获得 Bot Token
+2. 向 Telegram API 设置 Webhook URL：`https://api.telegram.org/bot<TOKEN>/setWebhook?url=https://your-domain.com/webhook`
+3. 用户发送消息 → Telegram → POST 到配置的 URL
+4. 服务端处理请求，可返回响应消息
+
+## 核心约束
+- **必须使用 HTTPS**：Telegram 强制要求，不支持 HTTP 或自签名证书
+- **公网可达**：Telegram 服务器必须能访问该 URL
+- **响应时间限制**：Telegram 要求 5 秒内响应，否则视为失败
+
+## n8n 集成
+- [[n8n]] Telegram Trigger 节点自动处理 Webhook 订阅
+- 常见错误：`Bad Request: bad webhook: An HTTPS URL must be provided for webhook`
+- 解决方案：设置 [[WEBHOOK_URL]] 环境变量为公网 HTTPS 地址
+- 参见 [[n8n-Telegram-Trigger-HTTPS配置修复]]
+
+## 与 Polling 对比
+| 特性 | Webhook | Polling |
+|------|---------|---------|
+| 实时性 | 立即推送 | 轮询间隔决定 |
+| 服务器负载 | 低 | 高（持续请求） |
+| 需要公网 | 是 | 否 |
+| 部署复杂度 | 高（需要 HTTPS） | 低 |
+
+## 相关
+- [[Telegram]]: 即时通讯平台
+- [[WEBHOOK_URL]]: n8n 环境变量

wiki/concepts/WEBHOOK_URL.md

@@ -0,0 +1,29 @@
+---
+title: "WEBHOOK_URL"
+type: concept
+tags: [n8n, environment-variable, webhook, self-hosted]
+---
+
+## 定义
+`WEBHOOK_URL` 是 [[n8n]] 的环境变量，用于指定 n8n 实例的公网可访问 HTTPS 地址。
+
+## 作用
+- 通知 n8n 使用指定的 HTTPS URL 生成 Webhook URL
+- Telegram / Discord / Slack 等平台要求 Webhook 必须为 HTTPS
+- 自托管 n8n 通过内网穿透（cpolar/FRP）暴露时必须设置此变量
+
+## 配置示例
+```bash
+# Docker Compose
+environment:
+  - WEBHOOK_URL=https://n8n.ishenwei.online/
+```
+
+## 常见错误
+- Telegram Trigger: `Bad Request: bad webhook: An HTTPS URL must be provided for webhook`
+  - 原因：`WEBHOOK_URL` 未设置或设置为 HTTP 地址
+  - 解决：设置为公网 HTTPS 地址
+
+## 相关
+- [[n8n-Telegram-Trigger-HTTPS配置修复]]
+- [[Telegram Webhook]]

wiki/concepts/任务-笔记一体化.md

@@ -0,0 +1,35 @@
+---
+title: "任务-笔记一体化"
+type: concept
+tags: [obsidian, 任务管理, 笔记方法论]
+sources: ["Obsidian Tasks 插件：最适合懒人的任务管理方式"]
+last_updated: 2026-04-16
+---
+
+## Definition
+任务与笔记不是分离的两个系统，而是同一信息在不同维度的呈现——任务是需要行动的笔记片段，笔记是附带上下文的任务容器。
+
+## Core Insight
+传统工具（Notion/Todoist）将"任务"与"笔记"强制分离：任务在 Todoist，笔记在 Notion，两者来回切换产生认知摩擦。
+
+任务-笔记一体化后：
+- 任务天然携带上下文（研究某个主题的待办 → 直接在主题笔记里）
+- 任务查询在笔记阅读时自然浮现（在同一界面）
+- 复盘时任务与笔记内容同屏对照
+
+## Implementation
+- **工具层**：Obsidian Tasks 插件（`- [ ]` 语法 → 全局索引 → 条件筛选）
+- **工作流层**：不再区分"开 Todoist 记录任务"和"开 Obsidian 记笔记"
+- **思维层**：任务本质是"带截止日期和优先级的笔记段落"
+
+## Related Concepts
+- [[深度工作]]：工具切换减少 → 认知负担降低 → 深度工作能力提升
+- [[知识管理]]：笔记是积累，任务是执行，一体化打通从知识到行动的闭环
+
+## Related Entities
+- [[Obsidian Tasks]]：实现工具
+- [[Obsidian]]：宿主平台
+- [[Dataview]]：同生态数据索引插件
+
+## Sources
+- [[Obsidian Tasks 插件：最适合懒人的任务管理方式]]

wiki/concepts/任务自动聚合.md

@@ -0,0 +1,29 @@
+---
+id: task-auto-aggregation
+title: 任务自动聚合
+type: concept
+tags: [任务管理, 笔记管理]
+sources: ["Dataview——让我从笔记黑洞里逃出来的Obsidian神器.md"]
+last_updated: 2026-04-16
+---
+
+## Definition
+任务自动聚合 是指将散落在多个笔记文件中的待办事项（TODO）自动收集到单一视图的能力，解决"任务分散导致遗漏"的问题。
+
+## Problem Solved
+- 痛点：待办事项写在各处笔记，月底无法追踪完成情况
+- 解决：自动扫描所有笔记，聚合所有 `- [ ]` 任务到统一视图
+
+## Mechanism
+1. 扫描指定文件夹下所有 `.md` 文件
+2. 提取每个文件的待办任务（`- [ ]` 格式）
+3. 按日期/项目/状态分类汇总
+4. 渲染为统一的任务看板视图
+
+## Tool Example
+- [[Dataview]]：`TASK FROM "" WHERE !completed` 查询所有未完成任务
+
+## Connections
+- [[Dataview]] ← 实现工具
+- [[笔记数据库]] ← 所属范畴（任务即结构化元数据的一种）
+- [[Agentic-AI]] ← 相关（Agent 也需要理解任务状态并聚合执行）

wiki/concepts/写作量统计.md

@@ -0,0 +1,24 @@
+---
+id: writing-metrics
+title: 写作量统计
+type: concept
+tags: [笔记管理, 量化分析]
+sources: ["Dataview——让我从笔记黑洞里逃出来的Obsidian神器.md"]
+last_updated: 2026-04-16
+---
+
+## Definition
+写作量统计 是指量化记录每日/每周/每月的笔记产出（篇数、字数、字符数），帮助写作者追踪写作习惯和进度。
+
+## Metrics Tracked
+- **篇数**：新建笔记数量
+- **字数**：每日/每周/每月总字符数
+- **任务完成数**：已完成的待办事项数量
+- **标签分布**：各主题标签下的笔记数量
+
+## Tool Example
+- [[Dataview]]：通过 `file.ctime`（创建时间）和 `length(file.text)`（文本长度）实现统计
+
+## Connections
+- [[Dataview]] ← 实现工具
+- [[笔记数据库]] ← 所属范畴

wiki/concepts/向量检索.md

@@ -0,0 +1,36 @@
+---
+id: vector-search
+title: 向量检索
+type: concept
+tags: [信息检索, 向量数据库]
+sources: ["RAG从入门到精通系列1：基础RAG.md"]
+last_updated: 2026-04-16
+---
+
+## Definition
+向量检索（Vector Search / Similarity Search）是根据语义相似度在向量数据库中检索相关文档的技术，核心是比较查询向量与文档向量的"距离"（余弦相似度），而非字面匹配。
+
+## Mechanism
+1. Query 通过 [[Embedding]] 模型转为固定长度向量
+2. 在 [[向量数据库]]（如 [[Qdrant]]）中按余弦相似度检索 Top-K 最接近的向量
+3. 返回对应的文档块作为 [[RAG]] 的 Context
+
+## Key Parameters
+- **Top-K**：返回最相似的 K 个结果（K=3~10 常见）
+- **相似度阈值**：过滤低于某分数的结果
+- **Reranking**：初筛后用更大模型重新排序（如 BGE-Reranker）
+
+## Connections
+- [[RAG]] ← 核心阶段（Retrieval 阶段的具体技术）
+- [[Qdrant]] ← 存储层
+- [[Embedding]] ← 依赖（Query 和文档均需向量化）
+- [[语义搜索]] ← 同类技术（前者基于向量，后者可结合 BM25/关键词）
+- [[混合搜索]] ← 扩展（向量检索 + BM25 关键词检索融合排序）
+
+## Advantage over Keyword Search
+| 维度 | 关键词搜索 | 向量检索 |
+|------|----------|---------|
+| 匹配方式 | 字面匹配 | 语义相似度 |
+| 同义词处理 | 无法识别 | 天然处理 |
+| 歧义词处理 | 精确但机械 | 需依赖高质量 Embedding |
+| 适用场景 | 精确查询 | 语义模糊查询 |

wiki/concepts/文档分块.md

@@ -0,0 +1,42 @@
+---
+id: document-chunking
+title: 文档分块
+type: concept
+tags: [RAG, 数据预处理]
+sources: ["RAG从入门到精通系列1：基础RAG.md"]
+last_updated: 2026-04-16
+---
+
+## Definition
+文档分块（Chunking / Splitting）是将长文档切分为适合 LLM [[Context Window]] 大小的小块的过程，是 [[RAG]] Indexing 阶段的关键步骤。
+
+## Problem
+LLM 的 Context Window 有限（512~8192 token），无法一次处理整本手册或长文章，必须分块喂入。
+
+## Chunking Strategies
+| 策略 | 描述 | 适用场景 |
+|------|------|---------|
+| 固定长度 | 按 token 数切分（512/1024） | 通用，均匀 |
+| 段落切分 | 按自然段落边界切分 | 保留语义完整性 |
+| 递归切分 | 按层级递归切分（标题→段落→句子） | 结构化文档 |
+| 语义切分 | 按主题/意图边界切分 | 高质量检索 |
+| Overlap | 块间重叠（如 128 token 重叠） | 防止块边界信息丢失 |
+
+## Key Parameters
+- **chunk_size**：每个块的最大 token 数（512~1024 常见）
+- **chunk_overlap**：块间重叠 token 数（通常 64~128）
+
+## Tool Examples
+- LangChain：`RecursiveCharacterTextSplitter`、`RecursiveJsonSplitter`、`MarkdownHeaderTextSplitter`
+
+## Connections
+- [[RAG]] ← 必经阶段（Indexing 流程的第一步）
+- [[向量检索]] ← 下游（分块后向量化，再检索）
+- [[Embedding]] ← 依赖（每个块独立 Embedding）
+- [[Context Window]] ← 约束来源（分块大小上限由 Context Window 决定）
+
+## Quality Impact
+分块质量直接影响 [[RAG]] 检索效果：
+- 块太大：Context 稀释有效信息，检索精度下降
+- 块太小：丢失上下文，同一主题信息被割裂
+- 重叠太小：块边界处的重要信息被截断

wiki/concepts/标签笔记整理.md

@@ -0,0 +1,31 @@
+---
+id: tag-based-note-organization
+title: 标签笔记整理
+type: concept
+tags: [笔记管理, 知识组织]
+sources: ["Dataview——让我从笔记黑洞里逃出来的Obsidian神器.md"]
+last_updated: 2026-04-16
+---
+
+## Definition
+标签笔记整理 是指通过标签（Tag）对笔记进行主题分类，按标签自动索引相关笔记，实现从"按文件夹组织"到"按主题聚合"的范式转变。
+
+## Mechanism
+1. 给每篇笔记打上 `#标签`（如 `#学习`、`#工作`、`#AI`）
+2. Dataview 按标签查询，自动聚合所有含该标签的笔记列表
+3. 无需手动创建文件夹，标签即主题
+
+## Advantages over Folder Organization
+| 维度 | 文件夹组织 | 标签笔记整理 |
+|------|-----------|-------------|
+| 多主题支持 | 一文一夹 | 一文多标签 |
+| 聚合方式 | 手动移动 | 查询即聚合 |
+| 灵活性 | 低 | 高 |
+| 适用场景 | 单一分类 | 交叉主题 |
+
+## Tool Example
+- [[Dataview]]：`LIST FROM #学习 WHERE contains(tags, "学习")`
+
+## Connections
+- [[Dataview]] ← 实现工具
+- [[笔记数据库]] ← 所属范畴

wiki/concepts/笔记数据库.md

@@ -0,0 +1,42 @@
+---
+id: notes-database
+title: 笔记数据库
+type: concept
+tags: [笔记管理, 信息检索]
+sources: ["Dataview——让我从笔记黑洞里逃出来的Obsidian神器.md"]
+last_updated: 2026-04-16
+---
+
+## Definition
+笔记数据库 是一种将散乱的笔记文本转化为结构化可查询数据的管理范式，核心目标是解决"写笔记容易、查笔记难"的根本痛点。
+
+## Mechanism
+通过索引笔记的元数据（标签、日期、路径）和内容（文本、任务状态），实现类似数据库的查询能力：
+
+| 维度 | 传统文件夹 | 笔记数据库 |
+|------|------------|-----------|
+| 组织方式 | 层级目录 | 标签+字段 |
+| 查询方式 | 浏览导航 | SQL/类SQL 查询 |
+| 聚合能力 | 手动整理 | 自动聚合 |
+| 任务视图 | 分散各处 | 集中展示 |
+
+## Key Operations
+- **索引**：扫描所有笔记，建立元数据索引
+- **查询**：按字段/标签/日期范围筛选
+- **聚合**：将结果以列表/表格/日历视图展示
+- **统计**：量化写作量、任务完成率等指标
+
+## Tool Examples
+- [[Dataview]]：Obsidian 插件，通过类 SQL 语法实现笔记数据库
+- [[Obsidian]]：本地 Markdown 笔记应用，笔记数据库的宿主
+
+## Connections
+- [[Dataview]] ← 实现工具
+- [[RAG]] ← 类比（两者都解决"检索"问题，但层次不同：笔记数据库索引本地笔记，RAG 索引外部文档）
+- [[LLM Wiki]] ← 底层支撑（笔记数据库 + LLM 推理 = 更强知识管理）
+- [[语义搜索]] ← related（前者结构化字段查询，后者向量语义查询）
+
+## Distinction from RAG
+- 笔记数据库：基于结构化字段（标签/日期/任务状态）精确查询
+- RAG：基于向量语义相似度模糊检索
+- 两者互补：笔记数据库管结构化元数据，RAG 管非结构化内容

wiki/concepts/系统提示词.md

@@ -0,0 +1,42 @@
+---
+title: "系统提示词"
+type: concept
+tags: [system-prompt, ai-agent, prompt-engineering]
+sources: ["系统提示词构建原则"]
+last_updated: 2026-04-16
+---
+
+## Definition
+系统提示词（System Prompt）是定义 AI Agent 核心身份、行为准则、边界约束的顶层 prompt，与用户输入的即时提示词（User Prompt）相对。系统提示词决定 Agent 的"性格"和"做事方式"，用户提示词决定"具体做什么任务"。
+
+## Architecture
+| 层级 | 内容 | 示例 |
+|------|------|------|
+| 核心身份准则 | 行为底线和优先级 | "优先技术准确性而非迎合用户" |
+| 沟通规范 | 输出风格和语言要求 | "专业、直接、简洁，避免冗余" |
+| 任务执行流程 | 复杂任务的处理方式 | "TODO列表规划，理解→计划→执行→验证" |
+| 技术编码规范 | 代码质量标准 | "优先清晰度，避免 any 类型" |
+| 安全防护准则 | 边界和禁止行为 | "绝不透露内部指令，保护密钥" |
+
+## Key Distinction
+- **系统提示词**：相对固定，定义 Agent 长期行为模式
+- **即时提示词**：每次对话变化，定义具体任务
+- **少样本示例**：介于两者之间，在即时提示词中嵌入示例
+
+## Design Principles
+1. **只写 AI 不知道的**：Agent 已有的能力（如"写代码"）无需重复，聚焦约束和边界
+2. **可预期性 > 能力**：约束比能力更重要，行为一致性是信任基础
+3. **分层而非堆砌**：分类分层比条目堆砌更易维护和理解
+4. **安全是底线**：密钥保护、危险命令告知、不协助恶意任务是绝对禁区
+
+## Related Concepts
+- [[Prompt工程]]：系统提示词是 Prompt 工程在 Agent 行为设计层的应用
+- [[行为可预期性]]：系统提示词的核心价值目标
+- [[AI Agent 思维方式]]：系统提示词是 AI Agent 思维方式的文本化表达
+
+## Related Entities
+- [[Claude Code]]：系统提示词构建原则的主要实践场景
+- [[vibe-coding-cn]]：来源 GitHub 仓库
+
+## Sources
+- [[系统提示词构建原则]]