Auto-sync: 2026-04-23 04:02

wiki/concepts/AI图生视频.md

@@ -0,0 +1,55 @@
+---
+title: "AI图生视频"
+type: concept
+tags: [ai, video-generation, image-to-video]
+---
+
+## Definition
+AI图生视频（Image-to-Video）是一种将静态图片通过人工智能模型自动转化为动态视频的技术。模型需要完成运动估计（从静态图像推断可能的运动方向）、时序生成（合成多帧连续画面）、内容填充（生成原图中未显示的视角和细节）三大核心任务。
+
+## Aliases
+- 图生视频
+- Image to Video (I2V)
+- Img2Vid
+- AI Video Generation from Image
+
+## Core Techniques
+- **运动估计**：从单张静态图片推断场景中各元素的运动方向和速度
+- **时序生成**：合成帧间连续性，确保视频流畅无闪烁
+- **内容扩展**：根据图片上下文填充画面外延区域（如物体背面、背景延续）
+- **主体一致性**：在多段视频中保持人物/物体的视觉特征（面部、衣着、颜色）高度一致
+- **音频同步**：根据视频内容自动生成匹配的音效或背景音乐
+
+## Control Methods
+| 控制方式 | 描述 | 代表工具 |
+|---------|------|---------|
+| 文本提示词 | 通过自然语言描述控制运动和场景变化 | 智谱清影、通义万相、可灵AI |
+| 动作模板 | 预定义的动作序列，用户直接选择 | 绘蛙AI视频 |
+| 运镜参数 | 调整摄像机运动方式（推进/拉远/倾斜/轨道） | 即梦AI、Stable Video、Viva |
+| 首尾帧 | 以首帧和尾帧图片约束视频首尾画面 | 即梦AI、PixVerse |
+| 运动笔刷 | 手动选择图片中需要动态化的区域 | 艺映AI |
+
+## Key Capabilities
+- **生成时长**：2秒至6秒不等，取决于工具和付费等级
+- **分辨率**：720p至1440p，免费工具通常为720p-1024p
+- **生成速度**：30秒至数分钟
+- **风格支持**：写实、动漫、3D动画、油画、赛博朋克、国风等
+- **音效支持**：部分工具（智谱清影）支持AI自动生成匹配音效
+
+## Applications
+- **电商场景**：模特图动态化（换装展示、动作演示）、商品展示视频
+- **内容创作**：创意短片、自媒体视频素材
+- **广告制作**：营销视频、产品演示
+- **社交媒体**：小红书、抖音、快手短视频素材
+
+## Related Concepts
+- [[AI文生视频]]：通过文本描述直接生成视频，与图生视频互补
+- [[主体一致性]]：多段视频中保持人物视觉特征一致的技术
+- [[运镜控制]]：摄像机运动参数对视频效果的影响
+- [[首尾帧控制]]：以约束帧控制视频首尾画面的技术
+
+## Key Entities
+- [[智谱清影]]：支持音效自动生成的AI视频工具
+- [[可灵AI]]：快手推出的1080p高质量图生视频工具
+- [[即梦AI]]：首尾帧精准控制、多参数自定义
+- [[Vidu]]：清华大学联合发布，主体一致性领先

wiki/concepts/AI文生视频.md

@@ -0,0 +1,36 @@
+---
+title: "AI文生视频"
+type: concept
+tags: [ai, video-generation, text-to-video]
+---
+
+## Definition
+AI文生视频（Text-to-Video）是一种通过文本描述直接生成视频内容的人工智能技术。用户输入自然语言提示词，模型自动生成包含场景、角色、动作的动态视频。与 [[AI图生视频]] 互补：文生视频从零开始创作，图生视频则在静态图片基础上添加动态效果。
+
+## Aliases
+- 文生视频
+- Text to Video (T2V)
+- TXT2VID
+- AI Video Generation from Text
+
+## Core Techniques
+- **文本编码**：将自然语言提示词编码为语义向量
+- **图像生成**：基于文本语义生成视频首帧或关键帧
+- **时序扩散**：通过扩散模型逐步生成帧间连续画面
+- **运动建模**：根据文本描述生成合理的物理运动
+- **视频解码**：将生成的隐表示解码为最终视频帧序列
+
+## Key Capabilities
+- 纯文本驱动，无需准备素材图片
+- 支持复杂场景描述和角色交互
+- 风格可控（写实、动漫、3D等）
+- 生成时长通常2-6秒
+
+## Applications
+- 概念演示视频
+- 营销视频自动生成
+- 创意内容快速原型
+
+## Related Concepts
+- [[AI图生视频]]：在静态图片基础上添加动态效果，与本文生视频互补
+- [[运镜控制]]：摄像机运动参数对视频效果的影响

wiki/concepts/AI簡報工作流.md

@@ -0,0 +1,29 @@
+---
+title: "AI簡報工作流"
+type: concept
+tags: [AI, 簡報, 自動化, 工作流]
+sources: [教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報]
+last_updated: 2026-04-23
+---
+
+## Definition
+两阶段演示文稿制作工作流——先用大语言模型（如 ChatGPT）做知识整理和信息结构化，再交由 AI 设计工具（如 Canva / Gamma AI）输出演示文稿。
+
+## Core Principle
+让 AI 扮演不同角色，充分发挥各自优势：
+- **第一阶段（思考者）**：LLM 负责深度理解、总结、重组信息，将分散资料转化为清晰、有逻辑的内容框架
+- **第二阶段（设计师）**：AI 设计工具负责视觉呈现与排版，将结构化内容转化为精美演示文稿
+
+## Why This Works
+- 直接让 AI 生成简报往往内容逻辑不清、堆砌信息
+- 先整理后设计的工作流确保：内容有深度，呈现有美感
+- 符合"专注做擅长的事"原则——让工具各司其职
+
+## Related Concepts
+- [[知識結構化]]：将非结构化信息转化为清晰框架的能力
+- [[AI設計工具]]：Canva、Gamma AI 等自动将内容转化为视觉呈现的工具
+- [[YouTube-Content-Pipeline]]：共享"AI 整理 → AI 输出"两阶段模式
+
+## Aliases
+- AI简报自动化工作流
+- 智能简报工作流

wiki/concepts/Agent-Routing-Rules.md

@@ -0,0 +1,26 @@
+---
+title: "Agent Routing Rules"
+type: concept
+last_updated: 2026-04-10
+---
+
+## Definition
+Agent Routing Rules 是 OpenClaw 中绑定特定 Channel（如 Telegram）到特定模型的配置规则，优先级高于全局配置文件（`openclaw.json`）。
+
+## Key Characteristics
+- 定义在 OpenClaw 的 Agent 路由层，不在 `openclaw.json` 全局 compaction 配置里
+- 修改全局配置对 Agent 级别路由无效
+- 模型 context window 直接影响可用 token 数量
+
+## Common Failure Pattern
+当 fallback 机制切换到小 context 模型，且该模型在路由规则中被绑定到某个 channel 时：
+- Telegram channel → deepseek-reasoner (16K)
+- 16K context + 16K safeguard 预留 = 0 可用 token
+
+## Related
+- [[Model-Fallback]]: 触发模型切换的机制
+- [[Compaction]]: Agent 级别 compaction 与全局配置的区别
+- [[Layered-Configuration]]: 分层配置的重要性
+
+## Sources
+- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]]

wiki/concepts/Call-Worthy-Threshold.md

@@ -0,0 +1,60 @@
+---
+title: "Call-Worthy Threshold"
+type: concept
+tags: [notification, prioritization, alerting, UX]
+sources: [phone-call-notifications]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+Call-Worthy Threshold 是判断某个事件是否值得触发电话通知的评估标准。核心原则：**电话通知必须稀缺，只有真正重要的信息才配得上占用用户的电话注意力**。如果 Agent 每天打电话 10 次，用户就会开始忽视电话——电话的价值在于其稀缺性。
+
+## Decision Framework
+
+Agent 评估是否"值得打电话"时，应考虑：
+
+### 紧急程度（Urgency）
+- 是否有时间敏感性？延迟处理会有什么后果？
+- 优先级递减：紧急（立即影响）> 重要（今天内需处理）> 参考（可稍后阅读）
+
+### 影响范围（Impact）
+- 对用户的直接财务/健康/安全影响有多大？
+- 优先级递减：高影响（金钱/健康/安全）> 中影响（机会成本）> 低影响（信息）
+
+### 可替代性（Substitutability）
+- 是否可以用更低打扰的方式通知？
+- 优先级递减：无法替代 > 低打扰通知不足 > 简单通知即可
+
+## Anti-Patterns
+
+- **通知疲劳**：Agent 频繁打电话 → 用户开始忽略 → 真正重要的电话也被忽视
+- **过载包装**：将 10 条普通消息合并成一条电话播报 → 信息过载，用户无法聚焦
+- **误判优先级**：小事打电话，大事发消息 → 优先级判断标准混乱
+
+## Best Practices
+
+1. **明确定义阈值**：用户应与 Agent 协商"什么情况打电话"，形成清晰标准
+2. **定期审计**：每月检查电话触发记录，确保频率保持在用户舒适范围内
+3. **日志可见**：用户可查看电话触发历史，理解 Agent 的判断逻辑
+4. **双向反馈**：用户说"这事不值得打电话"时，Agent 应记住并调整阈值
+
+## Examples
+
+| Event | Worth Calling? | Reason |
+|-------|---------------|--------|
+| NVDA 股价暴跌 5% | ✅ Yes | 财务影响大，时间敏感 |
+| 老板发来紧急邮件 | ✅ Yes | 高度时间敏感，潜在重大影响 |
+| 天气预报提醒带伞 | ❌ No | 低紧急性，普通推送即可 |
+| 日程冲突提醒 | ❌ No | 提前提醒，低紧急性 |
+| 服务器完全宕机 | ✅ Yes | 安全/业务影响，即时行动必需 |
+
+## Related Concepts
+
+- [[Voice Notification Channel]] — 电话通道的价值建立在稀缺性之上
+- [[Alerting]] — 告警规则设计应与通知阈值协同
+- [[Preference Learning]] — Agent 可从用户反馈中学习阈值偏好
+
+## Sources
+
+- [[phone-call-notifications]]

wiki/concepts/Compaction.md

@@ -0,0 +1,26 @@
+---
+title: "Compaction"
+type: concept
+last_updated: 2026-04-10
+---
+
+## Definition
+Compaction 是 OpenClaw 对话上下文压缩机制，用于在 token 接近上限时将历史对话压缩为摘要，释放上下文空间。
+
+## Safeguard Mode
+在 safeguard 模式下，OpenClaw 会预留 16K tokens 用于执行压缩操作：
+- `reserveTokensFloor`: 压缩预留 token 下限
+- 当模型 context window 较小时（如 deepseek-reasoner 的 16K），预留空间与 context 相等导致实际可用空间为 0
+
+## Configuration Levels
+- **全局配置** (`openclaw.json`): 影响所有 Agent
+- **Agent 级别配置** (routing rules): 影响特定 Agent/Channel，优先级更高
+
+## Related
+- [[Context-Window]]: 压缩的必要性来自 context window 的限制
+- [[Agent-Routing-Rules]]: Agent 级别配置可能覆盖全局 compaction 设置
+- [[上下文压缩]]: 已在 [[养龙虾5天血泪史]] 中详细讨论
+
+## Sources
+- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]]
+- [[养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录]]

wiki/concepts/Context-Window.md

@@ -0,0 +1,21 @@
+---
+title: "Context Window"
+type: concept
+last_updated: 2026-04-10
+---
+
+## Definition
+模型的 Context Window 是指单次 API 请求能处理的最大 token 数量（包括输入 prompt + 历史对话 + 输出 response）。超过这个上限就会触发"Context Limit Exceeded"错误。
+
+## Key Facts
+- **DeepSeek-reasoner**: 16K tokens context window
+- **MiniMax-M2.7**: 200K tokens context window
+- 16K context 模型配合 OpenClaw safeguard 模式预留 16K tokens = 实际可用 0 tokens
+
+## Related
+- [[Compaction]]: OpenClaw 通过上下文压缩管理 token 消耗
+- [[Model-Fallback]]: 模型切换的触发机制
+- [[Agent-Routing-Rules]]: Telegram channel 绑定特定模型的方式
+
+## Sources
+- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]]

wiki/concepts/Error-Surface-vs-Root-Cause.md

@@ -0,0 +1,26 @@
+---
+title: "Error Surface vs Root Cause"
+type: concept
+last_updated: 2026-04-10
+---
+
+## Definition
+错误表象（Error Surface）是指错误信息字面上描述的问题，而根本原因（Root Cause）是导致错误发生的真正系统状态。"Context Limit Exceeded"字面上提示"对话太长"，但真实原因可能是"模型配置错误"。
+
+## Core Principle
+> **不要默认认为错误信息就是表面意思。先问一句：到底哪儿出问题了？**
+
+## Debugging Mindset
+| 错误表象 | 根本原因 |
+|---|---|
+| Context limit exceeded = 对话太长 | 模型 context window 太小 |
+| Session 文件爆满 = 文件需要清理 | 模型切换导致 token 立即耗尽 |
+| 重启后问题复发 = 持久化配置错误 | Agent 路由规则在启动时重新加载 |
+
+## Related
+- [[Log-Driven-Debugging]]: 通过日志还原真实系统状态
+- [[Hidden-Failure-Paths]]: 复杂系统中的隐藏故障路径
+- [[Layered-Configuration]]: 分层配置导致问题藏在不同层级
+
+## Sources
+- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]]

wiki/concepts/Hidden-Failure-Paths.md

@@ -0,0 +1,30 @@
+---
+title: "Hidden Failure Paths"
+type: concept
+last_updated: 2026-04-10
+---
+
+## Definition
+Hidden Failure Paths 是指在复杂分布式系统中，故障可能隐藏在多个层面和路径中，单点排查无法发现全部问题来源。
+
+## OpenClaw 中的隐藏路径
+在 OpenClaw 这类分布式 AI Agent 系统中，一个"Context Limit Exceeded"问题可能藏在：
+1. Session 文件（历史对话积累）
+2. Memory plugin（记忆注入量）
+3. Model config（context window 大小）
+4. Routing rules（模型绑定）
+5. Compaction 策略（token 预留量）
+
+## Debugging Strategy
+逐一排除法：按层级逐层排查，每层确认无误后再进入下一层。
+
+## Key Insight
+> **工具/系统越复杂，问题的隐藏路径越深。**
+
+## Related
+- [[Error-Surface-vs-Root-Cause]]: 隐藏路径导致表象与根因分离
+- [[Log-Driven-Debugging]]: 日志是发现隐藏路径的唯一可靠手段
+- [[Layered-Configuration]]: 分层架构本身就产生隐藏路径
+
+## Sources
+- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]]

wiki/concepts/LLM-Wiki.md

@@ -0,0 +1,51 @@
+---
+title: "LLM Wiki"
+type: concept
+tags: [AI知识管理, 知识系统, RAG对比]
+sources: []
+last_updated: 2026-04-09
+---
+
+# LLM Wiki
+
+## 描述
+让 AI 增量构建和维护一个持久化的 Wiki 系统，页面之间互相链接，知识越积越厚。
+
+## 核心理念（来自 Karpathy 2026-03 分享）
+
+### RAG 模式的问题
+"每次从零检索"，知识不积累。
+
+### LLM Wiki 的优势
+- AI 在执行任务过程中顺手维护链接
+- 更新摘要
+- 添加 Tag
+- 标记新旧矛盾
+- 页面间互相链接，知识越积越厚
+- 不是被动等着被查询
+
+## 与 RAG 的对比
+
+| 维度 | RAG | LLM Wiki |
+|------|-----|----------|
+| 知识积累 | 每次从零检索 | 增量构建 |
+| 上下文 | 临时检索 | 持久化链接 |
+| 关系 | 独立文档 | 互相链接形成网络 |
+| 维护 | 被动等待查询 | 主动更新 |
+
+## 实现案例
+
+### 用户实践（养虾日记3）
+- **Obsidian 做知识库**（多端同步）
+- **Gitea 做版本控制**（Git 历史）
+- **OpenClaw 做写入接口**（obsidian skill）
+- AI 在执行任务的过程中顺手维护链接、更新摘要、添加 Tag、标记新旧矛盾
+
+### 相关工具
+- [[Obsidian]]：本地 Wiki 载体
+- [[Gitea]]：版本控制
+- [[OpenClaw]]：写入接口
+
+## 相关来源
+- [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]]
+- [[karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]]

wiki/concepts/Layered-Configuration.md

@@ -0,0 +1,26 @@
+---
+title: "Layered Configuration"
+type: concept
+last_updated: 2026-04-10
+---
+
+## Definition
+Layered Configuration（分层配置）指系统配置存在多个层级，不同层级的配置有不同的优先级和作用范围。修改某一层级的配置无法影响其他层级的行为。
+
+## OpenClaw 配置层级
+1. **Global Config** (`openclaw.json`): 全局 compaction 配置，影响所有 Agent
+2. **Agent/Channel Specific Config**: 针对特定 Telegram Channel 或 Agent 的模型映射规则
+3. **环境变量**: 启动脚本里的 `MODEL_DEFAULT` 可能覆盖配置文件
+
+## Debugging Implication
+> **两层配置要分清：全局 compaction 配置和 agent 模型配置是两码事。改全局不行，就得往 agent 级别去找。**
+
+当问题在全局层面无法解决时，需要检查 Agent 级别的路由规则和模型绑定配置。
+
+## Related
+- [[Agent-Routing-Rules]]: Agent 级别配置的具体形式
+- [[Compaction]]: 全局 compaction 配置的作用范围
+- [[Error-Surface-vs-Root-Cause]]: 分层配置是"错误表象 ≠ 根本原因"的常见原因
+
+## Sources
+- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]]

wiki/concepts/Log-Driven-Debugging.md

@@ -0,0 +1,29 @@
+---
+title: "Log-Driven Debugging"
+type: concept
+last_updated: 2026-04-10
+---
+
+## Definition
+Log-Driven Debugging 是一种通过系统日志定位问题根因的调试方法，尤其适用于分布式系统和多层配置架构。当错误信息具有误导性时，日志是最直接的系统状态反映。
+
+## Key Insight
+> **日志真的有用：Gateway 日志把问题写得明明白白，只是我自己没仔细看。**
+
+## OpenClaw Gateway Log Example
+```
+provider=custom-api-deepseek-reasoner/deepseek-reasoner ctx=16000
+estimatedPromptTokens=393 overflowTokens=392 reserveTokens=16384
+```
+这条日志直接揭示了：
+1. 当前模型已被切换为 deepseek-reasoner
+2. 模型 context window 为 16K
+3. Safeguard 预留 16K tokens 导致 overflow
+
+## Related
+- [[Error-Surface-vs-Root-Cause]]: 日志帮助还原真实根因
+- [[Hidden-Failure-Paths]]: 日志是发现隐藏故障路径的唯一可靠手段
+- [[Layered-Configuration]]: 日志帮助识别配置层级问题
+
+## Sources
+- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]]

wiki/concepts/Model-Fallback.md

@@ -0,0 +1,17 @@
+---
+title: "Model Fallback"
+type: concept
+last_updated: 2026-04-10
+---
+
+## Definition
+Model Fallback 是 OpenClaw 在默认模型不可用时，按优先级自动切换到 fallback 列表中下一个模型的机制。
+
+## Triggers
+1. **显式 API 不可用**: HTTP 503/502（服务宕机）、429（频率限制）、Connection Timeout
+2. **隐性 Token 溢出预判**: 路由权重配置错误导致切换到更小 context 的模型
+3. **配置文件优先级覆盖**: Agent/Channel 级别配置覆盖全局配置
+4. **负载均衡算法**: 随机或轮询分发请求
+
+## Sources
+- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]]

wiki/concepts/Self-Improving-Skill.md

@@ -0,0 +1,98 @@
+---
+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]]

wiki/concepts/Two-Way-Voice-Conversation.md

@@ -0,0 +1,45 @@
+---
+title: "Two-Way Voice Conversation"
+type: concept
+tags: [voice, conversation, interaction, AI, real-time]
+sources: [phone-call-notifications]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+Two-Way Voice Conversation 是一种实时双向语音交互模式——AI Agent 主动拨叫用户，用户接听后可随时提问，Agent 实时响应。与传统的单向播报（TTS）或录音通知不同，真正的双向对话意味着用户可以打断、追问、澄清，而不是被动接收广播式信息。
+
+## Why It Matters
+
+传统通知（推送、邮件、SMS）的本质是**单向广播**——Agent 发送信息，用户被动接收，无法即时互动。Two-Way Voice Conversation 打破了这一限制：
+
+- **即时澄清**：用户可以说"等等，哪封邮件？"或"现在价格多少？"，Agent 立即查询并回答
+- **动态深度**：用户可追问"为什么跌了？"引导 Agent 深入解释
+- **决策支持**：电话中即可做出决策（"帮我取消"、"确认出席"），无需挂断后额外操作
+
+## Contrast with One-Way Notification
+
+| Aspect | One-Way Notification | Two-Way Voice Conversation |
+|--------|---------------------|---------------------------|
+| Direction | Agent → User | Agent ↔ User |
+| User Action | Passive receive | Active query |
+| Depth | Fixed message | Dynamic based on questions |
+| Decision Making | Post-call action needed | Can decide on-call |
+| Latency Tolerance | Low (pre-composed) | Higher (live response) |
+
+## Design Considerations
+
+- **模型速度**：通话场景需要低延迟响应，建议使用快速模型（Haiku 级别）减少等待
+- **上下文管理**：Agent 需要在通话中维护对话上下文，切换话题时自然流畅
+- **通话礼仪**：Agent 应简洁明了，不说废话，直接回答用户问题
+
+## Related Concepts
+
+- [[Voice Notification Channel]] — 双向语音是电话通知的核心能力
+- [[Voice Interface]] — 语音交互的更宽泛概念
+- [[Telephony Integration]] — 电话集成的技术实现
+
+## Sources
+
+- [[phone-call-notifications]]

wiki/concepts/Voice-Notification-Channel.md

@@ -0,0 +1,37 @@
+---
+title: "Voice Notification Channel"
+type: concept
+tags: [notification, voice, alerting, channels]
+sources: [phone-call-notifications]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+Voice Notification Channel 是一种高优先级通知投递机制，AI Agent 通过主动拨打电话将关键信息触达用户。与推送通知、聊天消息等文字通道不同，电话具有无法被忽视的物理强制力——用户必须主动操作才能关闭铃音。
+
+## Core Characteristics
+
+- **最高触达优先级**：电话是所有通知渠道中唯一能强制中断用户注意力的通道
+- **稀缺性原则**：电话通知必须稀缺，仅用于真正重要的事件；过度使用会导致通知疲劳
+- **主动触达**：Agent 主动拨叫用户，而非等待用户查询
+
+## Channel Hierarchy
+
+| Channel | Priority | Latency | Attention Force |
+|---------|----------|---------|-----------------|
+| Phone Call | 🔴 最高 | 即时 | 无法忽视 |
+| Push Notification | 🟡 中 | 即时 | 可忽略 |
+| Chat Message | 🟢 低 | 即时 | 可埋没 |
+| Email | ⚪ 低 | 异步 | 易堆积 |
+
+## Related Concepts
+
+- [[Alerting]] — 告警生成机制
+- [[Heartbeat-Monitoring]] — 触发告警的监控机制
+- [[Call-Worthy Threshold]] — 判断事件是否触发电话通知的标准
+- [[Two-Way Voice Conversation]] — 电话通知的核心差异化能力
+
+## Sources
+
+- [[phone-call-notifications]]

wiki/concepts/上下文刷新.md

@@ -0,0 +1,74 @@
+---
+title: "上下文刷新（Memory Flush）"
+type: concept
+tags: [openclaw, memory, context-window, compaction]
+sources: [养龙虾5天血泪史]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+上下文刷新是 OpenClaw 的压缩前内存保护机制——在压缩器运行前，自动触发静默回合，提示 Agent 将重要上下文写入磁盘，确保关键信息在压缩后仍然可用。
+
+## How It Works
+
+```
+对话累积 → 接近 Context Window → Memory Flush 触发 → Agent 写入 memory/YYYY-MM-DD.md → 压缩运行 → 摘要丢失但重要内容存活
+```
+
+### 配置示例
+
+```json
+{
+  "compaction": {
+    "memoryFlush": {
+      "enabled": true,
+      "softThresholdTokens": 4000
+    }
+  }
+}
+```
+
+### 参数说明
+
+| 参数 | 说明 |
+|------|------|
+| `enabled` | 是否启用内存刷新 |
+| `softThresholdTokens` | 触发刷新的 token 阈值 |
+
+### 阈值设置原则
+
+- **小上下文模型**（8K-32K）：4000-8000 合适
+- **大上下文模型**（128K-200K）：需要更高阈值，避免过早触发导致上下文碎片化
+- **公式**：Context Window × 0.2 ~ 0.4
+
+## The Gap: Memory Flush Only Runs Once Per Compression Cycle
+
+> "内存刷新每个压缩周期只触发一次。如果会话足够长，有两三次压缩，只有第一次得到刷新处理。之后的一切都处于风险中。"
+
+### 补充方案：Context Pruning
+
+```json
+{
+  "contextPruning": {
+    "mode": "cache-ttl",
+    "ttl": "6h",
+    "keepLastAssistants": 3
+  }
+}
+```
+
+- 在 6 小时后积极修剪旧上下文
+- 同时保留最后 3 个助手响应
+- 与 Memory Flush 结合：早期将重要内容写入磁盘，旧上下文在溢出前被清理
+
+## Key Insight
+
+> "如果在磁盘上，它能在压缩中存活。如果只在对话中，它就有风险。"
+
+## Connections
+- [[上下文压缩]] ← Memory Flush 防止上下文压缩的信息丢失
+- [[Context-Pruning]] ← 与 Memory Flush 协同工作
+- [[写入纪律]] ← Memory Flush 是写入纪律的技术实现
+- [[交接协议]] ← 互补：Memory Flush 处理压缩周期，交接协议处理模型切换
+- [[养龙虾5天血泪史]] ← 主要来源

wiki/concepts/上下文压缩.md

@@ -0,0 +1,64 @@
+---
+title: "上下文压缩（Context Compaction）"
+type: concept
+tags: [openclaw, memory, context-window]
+sources: [养龙虾5天血泪史]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+上下文压缩是 AI Agent 在对话填满 Context Window 时，将旧消息压缩成摘要为新消息腾出空间的内置机制。是 OpenClaw 管理上下文长度的核心手段。
+
+## How It Works
+
+当对话消息积累到一定量（接近 Context Window 限制）时，OpenClaw 的压缩器运行：
+1. 扫描历史消息
+2. 生成摘要（Summary）
+3. 丢弃原始消息
+4. 用摘要替代历史
+
+## The Problem
+
+**压缩摘要丢失细节**：
+- 姓名、数字、具体决定等关键信息全部消失
+- 摘要抓住了要点，但丢掉了可操作的细节
+- 精心设计的第 3 条消息指令和第 7 条闲聊得到相同处理
+
+> "上下文窗口是有限的。但默认行为对一切一视同仁，这意味着你精心设计的第三条消息指令，和第七条消息的闲聊得到了相同待遇。" — [[养龙虾5天血泪史]]
+
+## Solution: Memory Flush
+
+**在压缩运行前将重要上下文写入磁盘**：
+
+```json
+{
+  "compaction": {
+    "memoryFlush": {
+      "enabled": true,
+      "softThresholdTokens": 4000
+    }
+  }
+}
+```
+
+当会话接近上下文限制时：
+1. OpenClaw 触发静默回合
+2. Agent 将重要内容写入 `memory/YYYY-MM-DD.md`
+3. 压缩器运行
+4. 即使摘要丢失，重要内容仍保留在磁盘上
+
+**注意**：4000 这个数值要根据模型上下文窗口大小调整。大模型（32K/128K/200K tokens）应设置更高值，避免过度压缩导致上下文碎片化。
+
+## Key Insight
+
+> "压缩不是敌人。压缩过程中丢失信息才是。"
+
+**如果只在上下文窗口中，它是临时的。如果在磁盘上，它就能存活。**
+
+## Connections
+- [[上下文刷新]] ← 防止上下文压缩的信息丢失
+- [[上下文压缩]] ← 触发 [[上下文刷新]]
+- [[Context-Pruning]] ← 与上下文压缩协同工作
+- [[写入纪律]] ← 上下文刷新是写入纪律的技术实现
+- [[养龙虾5天血泪史]] ← 主要来源

wiki/concepts/交接协议.md

@@ -0,0 +1,82 @@
+---
+title: "交接协议（Handoff Protocol）"
+type: concept
+tags: [openclaw, memory, model-switch, agentic-ai]
+sources: [养龙虾5天血泪史]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+交接协议是 AI Agent 在模型切换或会话结束时，将当前上下文状态写入每日日志的规程。解决 OpenClaw Agent 切换模型时丢失所有上下文的核心问题。
+
+## The Problem
+
+OpenClaw Agent 在切换模型时丢失所有上下文：
+- 新模型以新鲜上下文窗口开始
+- 只看到自动加载的文件
+- 当前会话状态、进行中的任务、待处理决定全部丢失
+
+> "切换模型后，Agent 表现得像我们从未交谈过。我提到两天前的讨论决定，它一脸茫然。"
+
+## Solution
+
+在任何模型切换或会话结束前执行交接：
+
+```markdown
+# Handoff Protocol
+
+## Current Session State
+- Current task: [task description]
+- Progress: [X% complete]
+- Pending decisions: [list]
+- Next steps: [action items]
+
+## What Worked
+- [insight 1]
+- [insight 2]
+
+## What Didn't Work
+- [failed approach 1]
+- [failed approach 2]
+```
+
+## Implementation
+
+### 在 AGENTS.md 顶部添加交接指令
+
+```markdown
+# Handoff Protocol (必须执行)
+Before any model switch or session end:
+1. Write current task state to memory/YYYY-MM-DD.md
+2. Include: progress, pending decisions, next steps
+3. Note what worked and what didn't
+4. This is non-negotiable — DO NOT skip
+```
+
+### 触发时机
+
+- `/model` 命令切换模型
+- `/exit` 或 `/quit` 结束会话
+- 长时间无响应后的新会话
+- 主动要求交接时
+
+## Key Insight
+
+> "交接协议是模型切换的修复"
+
+没有交接协议，新模型不知道发生了什么。有了交接协议，新模型从每日日志读取当前状态，无缝继续工作。
+
+## 与上下文刷新的关系
+
+- **上下文刷新**（Memory Flush）：防止单次压缩周期内的信息丢失
+- **交接协议**：防止模型切换时的信息丢失
+
+两者互补，共同确保长期会话的信息完整性。
+
+## Connections
+- [[上下文压缩]] ← 交接协议解决压缩无法覆盖的多次压缩问题
+- [[上下文刷新]] ← 互补机制
+- [[写入纪律]] ← 交接协议是写入纪律的具体场景
+- [[自动加载文件]] ← 新模型只看到自动加载的文件，交接日志弥补缺失
+- [[养龙虾5天血泪史]] ← 主要来源

wiki/concepts/写入纪律.md

@@ -0,0 +1,79 @@
+---
+title: "写入纪律（Write Discipline）"
+type: concept
+tags: [openclaw, memory, agentic-ai, best-practices]
+sources: [养龙虾5天血泪史]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+写入纪律是指强制 AI Agent 在任务执行过程中将决定、结果和错误主动记录到磁盘的规范。与"读取纪律"（设置文件供 Agent 读取）相对，是确保 Agent 记忆持久化的关键机制。
+
+## Core Principle
+
+> "写入纪律比读取纪律更重要"
+
+大多数人设置文件供 Agent 读取，但从不强制执行写回。如果 Agent 不将决定、结果和错误记录到磁盘，这些东西只存在于上下文窗口中。而上下文窗口会被压缩。
+
+**写回是临时上下文变成永久记忆的唯一方式。**
+
+## Three Rules of Write Discipline
+
+1. **每个任务记录其结果**：任务完成后必须写入 memory/YYYY-MM-DD.md
+2. **每个错误变成规则**：Agent 犯的错误必须转化为一行规则写入 LEARNINGS.md
+3. **任何值得记住的内容在压缩前写入**：配置 memoryFlush 确保重要信息存活
+
+## How to Enforce Write Discipline
+
+### 1. 启动序列强制指令
+
+在 AGENTS.md 顶部明确列出写入时机：
+```
+开始任何任务前：
+- 搜索 memory/YYYY-MM-DD.md 获取相关上下文
+- 检查 LEARNINGS.md 获取此类任务的规则
+- 完成后立即写入结果
+
+任务期间：
+- 如果有重要决定或新信息产生，立即写入 memory/YYYY-MM-DD.md
+```
+
+### 2. 交接协议
+
+在任何模型切换或会话结束前，Agent 将当前上下文写入每日日志：
+```
+# Handoff Protocol
+Before model switch or session end:
+1. Write current task state to memory/YYYY-MM-DD.md
+2. Note any pending decisions
+3. Record what worked and what didn't
+```
+
+### 3. 禁止直接写入 MEMORY.md
+
+> "任务期间永远不要直接写入 MEMORY.md"
+
+- **每日日志**（`memory/YYYY-MM-DD.md`）：原始且仅追加，Agent 可自由写入
+- **MEMORY.md**：策划的长期记忆，在定期审查期间（心跳或定时任务）通过提炼每日日志来更新
+
+让 Agent 向 MEMORY.md 转储任何内容，几周内它就会膨胀成 200 行的混乱。
+
+## LEARNINGS.md: The Most Underrated File
+
+> "Agent 犯的每个错误都应该变成一行规则"
+
+示例：
+- "在声称代码已推送前永远不要不检查 git 状态"
+- "不要在群聊中读取完整的 MEMORY.md"
+- "在安排前始终确认用户的时区"
+
+这些规则会复合——几周后，Agent 就有了从自己失败中构建的个人操作手册。
+
+## Connections
+- [[上下文压缩]] ← 写入纪律防止压缩导致信息丢失
+- [[上下文刷新]] ← 技术实现写入纪律的手段
+- [[LEARNINGS.md]] ← 写入纪律的具体存储文件
+- [[交接协议]] ← 写入纪律在模型切换时的应用
+- [[养龙虾5天血泪史]] ← 主要来源
+- [[Self-Improving-Skill]] ← 类似的自改进机制

wiki/concepts/启动序列.md

@@ -0,0 +1,79 @@
+---
+title: "启动序列（Boot Sequence）"
+type: concept
+tags: [openclaw, agentic-ai, best-practices]
+sources: [养龙虾5天血泪史]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+启动序列是 AI Agent 启动时必须执行的操作指令集合，包括读取文件、搜索上下文、检查规则等初始化行为。是 Agent 正常工作的前提保障。
+
+## Critical Rule: Put It at the Top of AGENTS.md
+
+> "启动序列放在 AGENTS.md 顶部。不要在中间。不要在底部。最顶部。"
+
+**自动加载的文件被注入系统提示词，所以启动指令需要是 Agent 处理的第一件事。**
+
+## OpenClaw 自动加载的文件
+
+OpenClaw 在每个新会话上自动读取这些文件：
+1. AGENTS.md ✅
+2. SOUL.md ✅
+3. TOOLS.md ✅
+4. IDENTITY.md ✅
+5. USER.md ✅
+6. HEARTBEAT.md ✅
+7. MEMORY.md ✅
+
+**其他一切都需要 AGENTS.md 中的明确读取指令。**
+
+## Common Pitfall: Files That Don't Auto-Load
+
+> "我的 BOOT.md 有整个启动序列。但 OpenClaw 不自动加载 BOOT.md。所以指令就坐在那里，未读，什么都不做。我用了好几周。"
+
+### 不自动加载的文件（需要读取指令）
+- BOOT.md ❌
+- BOOTSTRAP.md ❌
+- LEARNINGS.md（需要读取指令）
+- 每日日志 memory/YYYY-MM-DD.md（需要读取指令）
+- docs/ 文件夹（需要读取指令）
+
+## Boot Sequence Template
+
+```markdown
+# AGENTS.md
+
+# 🚀 启动序列（必须首先执行）
+
+## 1. 读取每日日志
+- 检查 memory/ 目录获取最近 3 天的日志
+- 搜索与当前任务相关的上下文
+
+## 2. 检查学习规则
+- 读取 learnings/LEARNINGS.md
+- 应用任何相关规则
+
+## 3. 确认用户信息
+- 读取 USER.md 确认当前用户身份
+- 检查是否有活跃任务
+
+## 4. 开始任务
+[具体任务指令...]
+```
+
+## Boot Sequence Best Practices
+
+1. **最顶部**：启动序列必须是 AGENTS.md 的第一件事
+2. **具体**：明确列出文件名和执行顺序
+3. **可执行**：每个指令都是 Agent 可直接执行的动作
+4. **包含写回**：启动序列应包含"完成后写回结果"的指令
+5. **测试验证**：植入标记，跨会话测试 Agent 是否真正执行
+
+## Connections
+- [[自动加载文件]] ← 只有 7 个文件自动加载
+- [[写入纪律]] ← 启动序列应包含写回指令
+- [[检索触发]] ← 启动序列应强制触发检索
+- [[交接协议]] ← 模型切换时通过启动序列读取交接日志
+- [[养龙虾5天血泪史]] ← 主要来源

wiki/concepts/思维蒸馏（女娲造人术）.md

@@ -0,0 +1,70 @@
+---
+title: "思维蒸馏（女娲造人术）"
+type: concept
+tags: [AI-Skill, Agent工作流, 认知框架]
+sources: []
+last_updated: 2026-04-23
+---
+
+# 思维蒸馏（女娲造人术）
+
+## 描述
+通过深度调研，从一个真实人物（历史人物/伟人/专家）的大量公开信息中，提炼出其核心思维框架，把它变成一个可运行的AI Skill。"女娲造人"这个比喻出自《风俗通》——女娲用泥土捏出了人类，我们的"造人"不是从虚无中创造角色，而是信息蒸馏。
+
+## 核心机制
+不是让AI扮演肤浅的NPC，而是捕捉一个人**看世界的方式**：
+- 决策逻辑
+- 思维模型
+- 表达DNA（高频用词、自嘲式幽默、方言痕迹）
+- 遇逆境时的第一反应
+- 价值观与边界
+
+## 工作流（女娲框架）
+
+```
+用户输入 → 入口分流（人名？模糊需求？）
+         ↓
+    Phase 0.5: 创建技能目录
+         ↓
+    Phase 1: 6个Agent并行采集（著作/对话/表达DNA/他者视角/决策/时间线）
+         ↓
+    Phase 1.5: 调研Review检查点
+         ↓
+    Phase 2: 框架提炼（心智模型/决策启发式/表达DNA/价值观/诚实边界）
+         ↓
+    Phase 2.5: 提炼确认检查点
+         ↓
+    Phase 3: Skill构建
+         ↓
+    Phase 4: 质量验证（已知测试/边缘测试/风格测试）
+         ↓
+    Phase 5: 双Agent精炼
+         ↓
+      交付: [人名]-perspective/SKILL.md
+```
+
+**关键特点**：整个过程不依赖任何外部文件——技能目录是自包含的，复制到任何地方都能独立运行。
+
+## 与"单向输出"的区别
+读《穷查理宝典》学芒格、看曾国藩家书学修身——这些都是**单向输出**：你在读他的话，但他的话不会回答你的具体问题。思维蒸馏的产出是一个可以**对话的导师**——可以针对你的具体问题，用伟人的思维框架给出建议。
+
+## 蒸馏案例
+| 人物 | 适用场景 |
+|------|---------|
+| [[苏东坡]] | 逆境中保持风骨、豁达面对困境 |
+| 芒格 | 投资决策、多元思维模型 |
+| 费曼 | 物理思维、简化复杂问题 |
+| 塔勒布 | 决策质量、风险管理 |
+| 乔布斯 | 产品设计、直觉判断 |
+| 海明威 | 写作风格 |
+
+## 与其他认知框架的关联
+- [[数字导师]] — 思维蒸馏的应用目标：让伟人成为日常思维顾问
+- [[AI-Skill]] — 思维蒸馏的产出格式
+- [[Second Brain]] — Second Brain捕获记忆，思维蒸馏蒸馏伟人——都是用AI构建外部认知能力
+- [[Agentic AI]] — 思维蒸馏依赖多Agent并行工作流（6个Agent同时采集）
+
+## Related Links
+- [[女娲]]（Nuwa Skill）：github.com/alchaincyf/nuwa-skill
+- [[苏东坡]] — 首个蒸馏实践
+- [[养虾日记5]] — 思维蒸馏的完整记录

wiki/concepts/播客生成.md

@@ -0,0 +1,33 @@
+---
+title: "播客生成"
+type: concept
+tags: [ai, content-generation, tts, llm]
+sources: [google-神级生产力工具-所有-github-开源平替都找到了, podcast-production-pipeline]
+last_updated: 2026-04-23
+---
+
+## Definition
+播客生成（Podcast Generation）是将文本内容（文档、网页、PDF 等多模态输入）通过 AI 技术转换为逼真的多人对话音频的流程。核心是 LLM 脚本生成 + TTS 语音合成的组合。
+
+## Technical Pipeline
+1. **内容输入**：PDF、网页、音频、YouTube 字幕等多模态格式
+2. **文本理解**：LLM 提取核心信息和关键观点
+3. **脚本生成**：LLM 生成双人/多人对话脚本，赋予角色性格
+4. **语音合成（TTS）**：使用 ElevenLabs、Google TTS、Edge TTS 等引擎生成自然语音
+5. **音频编辑**：合并多轨音频，添加过渡效果
+
+## Key Parameters
+- **角色数量**：NotebookLM 双人对话；OpenNotebook 支持最多 4 位演讲者
+- **内容模式**：短视频风格（Shorts）vs 长篇深度（Longform）
+- **语言支持**：多语言（Podcastfy 支持 100+ LLM 脚本生成）
+- **TTS 引擎**：OpenAI、Google、ElevenLabs、Microsoft Edge TTS 等
+
+## Applications
+- 学习消化：通过听来消化复杂资料
+- 内容创作：将长文转化为播客，扩大受众覆盖
+- 知识分享：将文档内容以音频形式分发
+
+## Related Concepts
+- [[LLM]] — 脚本生成的大脑
+- [[TTS]]（文本转语音）— 语音合成引擎
+- [[文档问答]] — NotebookLM 的另一个核心功能

wiki/concepts/数字导师.md

@@ -0,0 +1,39 @@
+---
+title: "数字导师"
+type: concept
+tags: [AI-Skill, 认知增强, 历史伟人]
+sources: []
+last_updated: 2026-04-23
+---
+
+# 数字导师
+
+## 描述
+用AI蒸馏历史人物或伟人的思维框架，使其成为可对话的日常思维顾问——不是肤浅的NPC扮演，而是捕捉一个人看世界的方式（决策逻辑、思维模型、表达DNA、遇逆境时的第一反应），在需要时用他的思维镜片看自己的问题。
+
+## 核心价值
+- **用别人的脑子思考自己的人生** — 读《穷查理宝典》是单向输出，数字导师可以针对你的具体问题给出建议
+- **每个人的Skill都是一个认知操作系统** — 你不需要同意他的所有观点，但可以在需要时借用他的镜片
+- **AI时代用AI放大人类历史上最强大的脑子** — 让历史伟人成为日常思维顾问
+
+## 实现路径
+通过[[思维蒸馏（女娲造人术）]]将真实人物的核心思维框架蒸馏成AI Skill，激活后AI以该人物的视角与用户对话。
+
+## 实践案例
+- [[养虾日记5]] — 蒸馏[[苏东坡]]为首位"数字导师"，展示了完整的蒸馏过程和真实对话记录
+- 失业焦虑者与苏东坡对话，苏东坡给出："真正风流的人，不是站在浪尖上的人，而是被浪打下去还能爬起来的人"
+
+## 应用场景
+| 想学什么 | 蒸馏谁 |
+|---------|--------|
+| 投资 | 芒格 |
+| 物理思维 | 费曼 |
+| 逆境中保持风骨 | 苏东坡 |
+| 提升决策质量 | 塔勒布 |
+| 写作 | 海明威 |
+| 产品直觉 | 乔布斯 |
+
+## 相关来源
+- [[养虾日记5]]
+- [[思维蒸馏（女娲造人术）]]
+- [[苏东坡]]

wiki/concepts/文档问答.md

@@ -0,0 +1,23 @@
+---
+title: "文档问答"
+type: concept
+tags: [ai, knowledge-management, rag]
+sources: [google-神级生产力工具-所有-github-开源平替都找到了, knowledge-base-rag]
+last_updated: 2026-04-23
+---
+
+## Definition
+文档问答（Document Q&A）是指 AI 系统基于用户上传的文档内容进行问答，并能提供精准的原文引用。它是 RAG（检索增强生成）的一种具体应用形态，强调答案的可验证性和引用准确性。
+
+## Core Characteristics
+- **严格范围限制**：回答严格基于上传文档，不发散到外部知识
+- **原文引用**：每个答案附带精准的原文出处，支持回溯验证
+- **上下文感知**：理解文档整体结构，答案具有连贯性
+
+## Key Distinction from General Q&A
+普通 AI 问答（如 ChatGPT）是开放域生成，可能产生幻觉；文档问答强制限定知识范围，从根本上减少幻觉风险，提高回答可信度。
+
+## Related Concepts
+- [[RAG]] — 检索增强生成，是文档问答的技术基础
+- [[语义搜索]] — 文档问答的检索层技术
+- [[混合搜索]] — 语义 + 全文的组合检索技术

wiki/concepts/本地化部署.md

@@ -0,0 +1,33 @@
+---
+title: "本地化部署"
+type: concept
+tags: [ai, self-hosted, privacy, docker]
+sources: [google-神级生产力工具-所有-github-开源平替都找到了]
+last_updated: 2026-04-23
+---
+
+## Definition
+本地化部署（Local Deployment）是指在不依赖云端服务的情况下，在本地机器或私有服务器上运行 AI 应用。通过 Docker 等容器化技术简化部署，同时支持本地模型（Ollama、LM Studio）实现完全离线运行。
+
+## Core Benefits
+- **数据隐私**：文档和数据不离开本地，无需上传云端
+- **成本可控**：无需支付 API 调用费用
+- **离线可用**：完全离线环境下正常工作
+- **定制灵活**：可自由切换底层 AI 模型
+
+## Key Technologies
+- **容器化**：`docker run` 一键部署，无需手动配置环境
+- **本地模型**：
+  - [[Ollama]] — 最流行的本地 LLM 运行平台
+  - [[LM Studio]] — 桌面端本地模型运行工具
+- **模型选择**：OpenAI、Anthropic Claude、Google Gemini 等云端 API 按需调用
+
+## Use Cases
+- 企业内部文档问答（数据不能外传）
+- 个人知识管理（隐私优先）
+- 网络受限环境（离线场景）
+
+## Related Entities
+- [[OpenNotebook]] — 支持 Ollama/LM Studio 本地部署
+- [[InsightsLM]] — 支持 Ollama/Qwen3 完全离线
+- [[SurfSense]] — 支持本地 LLM 保护隐私

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

@@ -0,0 +1,58 @@
+---
+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]]

wiki/concepts/混合搜索.md

@@ -0,0 +1,26 @@
+---
+title: "混合搜索"
+type: concept
+tags: [ai, search, vector, bm25, rag]
+sources: [google-神级生产力工具-所有-github-开源平替都找到了]
+last_updated: 2026-04-23
+---
+
+## Definition
+混合搜索（Hybrid Search）结合语义搜索（向量相似度）和全文搜索（BM25/关键词匹配）两种技术，并通过重排序算法（Re-ranking）整合结果，兼顾语义理解深度和关键词精确度。
+
+## Why Hybrid?
+- **语义搜索擅长**：理解意图、同义词扩展、语义相关但不含关键词的内容
+- **BM25 擅长**：精确关键词匹配、人名/产品名/技术术语、查询词密集出现的内容
+- **两者结合**：互相补充，提升整体召回率和精确率
+
+## Technical Pipeline (SurfSense 方案)
+1. **语义搜索**：向量相似度初筛，获取语义相关候选集
+2. **BM25 全文搜索**：关键词精确匹配，补充专有名词召回
+3. **融合排序**：使用 RRF（Reciprocal Rank Fusion）等算法合并两个结果集
+4. **重排序（Re-ranking）**：使用更精准的模型对 top 结果二次排序
+
+## Related Concepts
+- [[语义搜索]] — 混合搜索的一个组成维度
+- [[重排序]]（Re-ranking）— 对混合结果集进行精排
+- [[RAG]] — 混合搜索常作为 RAG 系统的检索层

wiki/concepts/语义搜索.md

@@ -0,0 +1,24 @@
+---
+title: "语义搜索"
+type: concept
+tags: [ai, search, vector, rag]
+sources: [google-神级生产力工具-所有-github-开源平替都找到了, semantic-memory-search]
+last_updated: 2026-04-23
+---
+
+## Definition
+语义搜索（Semantic Search）是通过理解查询意图和文档语义的搜索方式，超越传统关键词匹配，基于向量相似度找到语义相关的内容。
+
+## How It Works
+1. **向量化**：将文档切分为 chunk，通过 Embedding 模型转换为向量
+2. **语义匹配**：将用户查询也转为向量，计算与文档向量的相似度
+3. **结果排序**：按相似度得分返回最相关的内容
+
+## Limitations
+- 对专有名词（如人名、产品名、技术术语）召回率低
+- 精确匹配需求场景表现不如 BM25
+
+## Related Concepts
+- [[混合搜索]] — 语义搜索 + BM25 的组合，互补各自局限
+- [[RAG]] — 语义搜索是 RAG 检索层的核心
+- [[重排序]]（Re-ranking）— 对语义搜索初筛结果进行二次精排