Auto-sync: 2026-04-23 04:02
This commit is contained in:
55
wiki/concepts/AI图生视频.md
Normal file
55
wiki/concepts/AI图生视频.md
Normal file
@@ -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]]:清华大学联合发布,主体一致性领先
|
||||
36
wiki/concepts/AI文生视频.md
Normal file
36
wiki/concepts/AI文生视频.md
Normal file
@@ -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图生视频]]:在静态图片基础上添加动态效果,与本文生视频互补
|
||||
- [[运镜控制]]:摄像机运动参数对视频效果的影响
|
||||
29
wiki/concepts/AI簡報工作流.md
Normal file
29
wiki/concepts/AI簡報工作流.md
Normal file
@@ -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简报自动化工作流
|
||||
- 智能简报工作流
|
||||
26
wiki/concepts/Agent-Routing-Rules.md
Normal file
26
wiki/concepts/Agent-Routing-Rules.md
Normal file
@@ -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」错误排查-我以为是小问题-结果踩了大坑]]
|
||||
60
wiki/concepts/Call-Worthy-Threshold.md
Normal file
60
wiki/concepts/Call-Worthy-Threshold.md
Normal file
@@ -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]]
|
||||
26
wiki/concepts/Compaction.md
Normal file
26
wiki/concepts/Compaction.md
Normal file
@@ -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-记忆调试全记录]]
|
||||
21
wiki/concepts/Context-Window.md
Normal file
21
wiki/concepts/Context-Window.md
Normal file
@@ -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」错误排查-我以为是小问题-结果踩了大坑]]
|
||||
26
wiki/concepts/Error-Surface-vs-Root-Cause.md
Normal file
26
wiki/concepts/Error-Surface-vs-Root-Cause.md
Normal file
@@ -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」错误排查-我以为是小问题-结果踩了大坑]]
|
||||
30
wiki/concepts/Hidden-Failure-Paths.md
Normal file
30
wiki/concepts/Hidden-Failure-Paths.md
Normal file
@@ -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」错误排查-我以为是小问题-结果踩了大坑]]
|
||||
51
wiki/concepts/LLM-Wiki.md
Normal file
51
wiki/concepts/LLM-Wiki.md
Normal file
@@ -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-的低效循环]]
|
||||
26
wiki/concepts/Layered-Configuration.md
Normal file
26
wiki/concepts/Layered-Configuration.md
Normal file
@@ -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」错误排查-我以为是小问题-结果踩了大坑]]
|
||||
29
wiki/concepts/Log-Driven-Debugging.md
Normal file
29
wiki/concepts/Log-Driven-Debugging.md
Normal file
@@ -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」错误排查-我以为是小问题-结果踩了大坑]]
|
||||
17
wiki/concepts/Model-Fallback.md
Normal file
17
wiki/concepts/Model-Fallback.md
Normal file
@@ -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」错误排查-我以为是小问题-结果踩了大坑]]
|
||||
98
wiki/concepts/Self-Improving-Skill.md
Normal file
98
wiki/concepts/Self-Improving-Skill.md
Normal file
@@ -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]]
|
||||
45
wiki/concepts/Two-Way-Voice-Conversation.md
Normal file
45
wiki/concepts/Two-Way-Voice-Conversation.md
Normal file
@@ -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]]
|
||||
37
wiki/concepts/Voice-Notification-Channel.md
Normal file
37
wiki/concepts/Voice-Notification-Channel.md
Normal file
@@ -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]]
|
||||
74
wiki/concepts/上下文刷新.md
Normal file
74
wiki/concepts/上下文刷新.md
Normal file
@@ -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天血泪史]] ← 主要来源
|
||||
64
wiki/concepts/上下文压缩.md
Normal file
64
wiki/concepts/上下文压缩.md
Normal file
@@ -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天血泪史]] ← 主要来源
|
||||
82
wiki/concepts/交接协议.md
Normal file
82
wiki/concepts/交接协议.md
Normal file
@@ -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天血泪史]] ← 主要来源
|
||||
79
wiki/concepts/写入纪律.md
Normal file
79
wiki/concepts/写入纪律.md
Normal file
@@ -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]] ← 类似的自改进机制
|
||||
79
wiki/concepts/启动序列.md
Normal file
79
wiki/concepts/启动序列.md
Normal file
@@ -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天血泪史]] ← 主要来源
|
||||
70
wiki/concepts/思维蒸馏(女娲造人术).md
Normal file
70
wiki/concepts/思维蒸馏(女娲造人术).md
Normal file
@@ -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]] — 思维蒸馏的完整记录
|
||||
33
wiki/concepts/播客生成.md
Normal file
33
wiki/concepts/播客生成.md
Normal file
@@ -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 的另一个核心功能
|
||||
39
wiki/concepts/数字导师.md
Normal file
39
wiki/concepts/数字导师.md
Normal file
@@ -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]]
|
||||
- [[思维蒸馏(女娲造人术)]]
|
||||
- [[苏东坡]]
|
||||
23
wiki/concepts/文档问答.md
Normal file
23
wiki/concepts/文档问答.md
Normal file
@@ -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]] — 检索增强生成,是文档问答的技术基础
|
||||
- [[语义搜索]] — 文档问答的检索层技术
|
||||
- [[混合搜索]] — 语义 + 全文的组合检索技术
|
||||
33
wiki/concepts/本地化部署.md
Normal file
33
wiki/concepts/本地化部署.md
Normal file
@@ -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 保护隐私
|
||||
58
wiki/concepts/每日复盘机制.md
Normal file
58
wiki/concepts/每日复盘机制.md
Normal file
@@ -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]]
|
||||
26
wiki/concepts/混合搜索.md
Normal file
26
wiki/concepts/混合搜索.md
Normal file
@@ -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 系统的检索层
|
||||
24
wiki/concepts/语义搜索.md
Normal file
24
wiki/concepts/语义搜索.md
Normal file
@@ -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)— 对语义搜索初筛结果进行二次精排
|
||||
24
wiki/entities/Canva.md
Normal file
24
wiki/entities/Canva.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Canva"
|
||||
type: entity
|
||||
tags: [AI, 设计, 簡報]
|
||||
sources: [教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Canva 是在线可视化设计平台(canva.com),支持简报、海报、社交媒体图片、logo、名片等多种设计类型。提供海量模板和设计素材,用户可通过拖拽操作快速完成设计。
|
||||
|
||||
## Key Features
|
||||
- 海量专业模板库
|
||||
- 品牌套件(Logo、色彩、字体)
|
||||
- AI 辅助设计功能(Magic Design、文本生成图片等)
|
||||
- 团队协作与共享
|
||||
- 支持简报、海报、社交媒体等多种输出格式
|
||||
|
||||
## Role in AI簡報工作流
|
||||
在 AI 簡報工作流中,Canva 担任"设计师"角色——接收 ChatGPT 整理好的结构化内容,快速生成视觉精美的演示文稿。
|
||||
|
||||
## Related
|
||||
- [[Gamma AI]]:AI 简报工具的另一个选择,更侧重 AI 驱动的一键生成
|
||||
- [[AI簡報工作流]]:Canva 在此工作流中负责视觉呈现
|
||||
@@ -2,8 +2,8 @@
|
||||
title: "ClawHub"
|
||||
type: entity
|
||||
tags: [ClawHub, OpenClaw, Skill, Marketplace]
|
||||
sources: [daily-youtube-digest]
|
||||
last_updated: 2026-04-22
|
||||
sources: [daily-youtube-digest, phone-call-notifications]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Aliases
|
||||
@@ -17,8 +17,9 @@ ClawHub(clawhub.ai)是 OpenClaw 的官方 Skill 市场,托管 OpenClaw Age
|
||||
## Key Skills on ClawHub
|
||||
|
||||
- **youtube-full** — 自动获取 YouTube 频道最新视频、提取字幕并摘要
|
||||
- **clawr.ing** — 为 Agent 提供主动拨打电话通知能力,通过 PSTN 电话触达用户(参见 [[phone-call-notifications]])
|
||||
- 持续扩充中(官网 clawhub.ai 浏览全部)
|
||||
|
||||
## Connections
|
||||
- [[ClawHub]] ← hosts ← [[youtube-full skill]]
|
||||
- [[OpenClaw]] ← extends via ← [[ClawHub]] skills
|
||||
- [[clawhub.ai]] ← hosts ← [[youtube-full skill]], [[clawr.ing]]
|
||||
- [[OpenClaw]] ← extends via ← [[clawhub.ai]] skills
|
||||
|
||||
24
wiki/entities/Gamma-AI.md
Normal file
24
wiki/entities/Gamma-AI.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Gamma AI"
|
||||
type: entity
|
||||
tags: [AI, 設計, 簡報]
|
||||
sources: [教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Gamma AI(gamma.app)是一款 AI 驱动的演示文稿生成工具,用户只需输入主题或内容,Gamma AI 即可一键生成完整的演示文稿,支持主题定制和内容编辑。
|
||||
|
||||
## Key Features
|
||||
- 一键生成完整演示文稿
|
||||
- 支持多种主题和风格选择
|
||||
- AI 自动排版和视觉设计
|
||||
- 内置编辑功能,可修改 AI 生成的内容
|
||||
- 支持网页模式(可作为网页发布)
|
||||
|
||||
## Role in AI簡報工作流
|
||||
在 AI 簡報工作流中,Gamma AI 与 Canva 共同担任"设计师"角色。相比 Canva,Gamma AI 更侧重 AI 驱动的一键生成,适合快速从零制作简报的场景。
|
||||
|
||||
## Related
|
||||
- [[Canva]]:另一个 AI 简报工具,更侧重模板和手动设计
|
||||
- [[AI簡報工作流]]:Gamma AI 在此工作流中负责视觉呈现与排版
|
||||
@@ -1,33 +1,25 @@
|
||||
---
|
||||
title: "Gitea"
|
||||
type: entity
|
||||
tags: [git, self-hosted, github-alternative, devops]
|
||||
sources: [self-healing-home-server]
|
||||
last_updated: 2026-04-22
|
||||
tags: [Git, 版本控制, 自托管]
|
||||
sources: []
|
||||
last_updated: 2026-04-09
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Gitea
|
||||
- gitea
|
||||
# Gitea
|
||||
|
||||
## Definition
|
||||
Gitea 是一个开源、轻量级的自托管 Git 服务(GitHub/GitLab 替代方案),使用 Go 语言编写,最低硬件要求极低(512MB RAM)。支持 Git 仓库管理、Issue 追踪、Pull Request、Wiki、CI/CD(Actions)等完整功能。
|
||||
## 描述
|
||||
轻量级的自托管 Git 服务,托管笔记的版本控制,所有历史版本完整保留。
|
||||
|
||||
## In Home Lab Context
|
||||
在 [[self-healing-home-server]] 安全架构中,Gitea 作为**本地优先 Git 仓库**:
|
||||
- 作为私有代码中转站(推送到公共 GitHub 前的 CI 扫描_gate)
|
||||
- CI pipeline 运行 TruffleHog 等 secrets scanning 工具
|
||||
- Human review required before main branch merges
|
||||
- 防止 Agent 直接暴露 API keys 到公共仓库
|
||||
## 与 Obsidian 笔记系统的集成
|
||||
|
||||
## Security Role
|
||||
Gitea 在 [[Local-first Git]] 工作流中的位置:
|
||||
```
|
||||
Agent → commits → Gitea (private) → CI scan (TruffleHog) → Human review → GitHub (public)
|
||||
```
|
||||
通过 Obsidian Git 插件,笔记每次更新都对应一个 Git commit:
|
||||
- **任何时候都能回溯** — 三个月前某台服务器上跑的什么服务,一个 `git log` 就能找到
|
||||
- **变更有据可查** — "这个端口是什么时候改的?" → commit message 里写得清清楚楚
|
||||
- **多人协作预留** — 未来如果想让其他 AI Agent 也参与协作,Gitea 的权限体系天然支持
|
||||
|
||||
## Connections
|
||||
- [[Local-first Git]] — Gitea 作为私有中转的核心基础设施
|
||||
- [[OpenClaw]] — Agent 代码托管和工作流编排平台
|
||||
- [[TruffleHog]] — Gitea CI pipeline 中运行的 secrets scanning 工具
|
||||
- [[Defense-in-Depth]] — Gitea 是多层安全防御架构的一环
|
||||
## 核心价值
|
||||
AI 批量改文件的能力越强,越需要版本管理来兜底。自建服务确保私有数据不出内网。
|
||||
|
||||
## 相关来源
|
||||
- [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]]
|
||||
|
||||
23
wiki/entities/Google.md
Normal file
23
wiki/entities/Google.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Google"
|
||||
type: entity
|
||||
tags: [company, ai, productivity]
|
||||
sources: [google-神级生产力工具-所有-github-开源平替都找到了]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Google(谷歌)是全球领先的科技公司,隶属于 Alphabet 集团。旗下拥有 NotebookLM 等 AI 驱动的生产力工具,在 AI 笔记助手领域具有标杆地位。
|
||||
|
||||
## Aliases
|
||||
- Google LLC
|
||||
- Alphabet Inc.(母公司)
|
||||
- 谷歌
|
||||
|
||||
## Key Products
|
||||
- [[NotebookLM]] — AI 笔记助手,支持文档问答和播客生成
|
||||
- Google Gemini — 多模态大语言模型
|
||||
- Google Workspace — 办公套件
|
||||
|
||||
## Role in This Wiki
|
||||
NotebookLM 是本文档讨论的标杆产品,所有开源平替均以 NotebookLM 为参照系。
|
||||
30
wiki/entities/InsightsLM.md
Normal file
30
wiki/entities/InsightsLM.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "InsightsLM"
|
||||
type: entity
|
||||
tags: [product, open-source, ai, github, low-code]
|
||||
sources: [google-神级生产力工具-所有-github-开源平替都找到了]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
InsightsLM 是 NotebookLM 的替代方案,强调低代码/无代码。它采用 [[Supabase]] 作为后端数据库和存储,结合 [[N8N]] 工作流自动化工具,前端基于 React 构建,提供可完全掌控数据的私有化研究工具。
|
||||
|
||||
## Aliases
|
||||
- theaiautomators/insights-lm-public
|
||||
|
||||
## Key Capabilities
|
||||
- **文档对话**:与上传的文档进行聊天
|
||||
- **带引用答案**:生成可验证引用的回答
|
||||
- **播客生成**:支持播客内容生成
|
||||
- **N8N 工作流集成**:利用 N8N 进行后端逻辑处理
|
||||
- **本地化部署**:支持 Ollama 和 Qwen3 等本地模型,实现完全离线的 AI 交互
|
||||
|
||||
## Tech Stack
|
||||
- **前端**:React
|
||||
- **后端**:[[Supabase]](数据库和存储)+ [[N8N]](工作流自动化)
|
||||
|
||||
## GitHub
|
||||
https://github.com/theaiautomators/insights-lm-public
|
||||
|
||||
## Role in This Wiki
|
||||
InsightsLM 是最容易上手的低代码方案,适合不熟悉技术但希望私有化部署的用户。
|
||||
27
wiki/entities/NotebookLM.md
Normal file
27
wiki/entities/NotebookLM.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "NotebookLM"
|
||||
type: entity
|
||||
tags: [product, ai, google, productivity]
|
||||
sources: [google-神级生产力工具-所有-github-开源平替都找到了]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
NotebookLM 是 Google 推出的 AI 笔记助手,核心特点是严格基于用户上传的文档范围进行回答,并能提供精准的原文引用。其最出圈的功能是**播客生成**,能将复杂资料一键转换为逼真的双人英语对话播客。
|
||||
|
||||
## Aliases
|
||||
- Google NotebookLM
|
||||
- NotebookLM (Google)
|
||||
|
||||
## Core Capabilities
|
||||
- **文档问答**:基于上传文档的精准回答,带原文引用
|
||||
- **播客生成**:多角色对话音频生成,支持收听学习
|
||||
- **多模态输入**:支持 PDF、网页、音频、YouTube 视频
|
||||
|
||||
## Key Parameters
|
||||
- 免费使用
|
||||
- 支持多语言文档
|
||||
- 基于 Google Gemini 模型驱动
|
||||
|
||||
## Role in This Wiki
|
||||
作为标杆产品,是本文档中 6 款开源平替(OpenNotebook、SurfSense、Podcastfy、NotebookLlama、PageLM、InsightsLM)的共同参照对象。
|
||||
27
wiki/entities/NotebookLlama.md
Normal file
27
wiki/entities/NotebookLlama.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "NotebookLlama"
|
||||
type: entity
|
||||
tags: [product, open-source, ai, github, llamaindex]
|
||||
sources: [google-神级生产力工具-所有-github-开源平替都找到了]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
NotebookLlama 是由 [[LlamaIndex]] 官方推出的完全开源项目,当前 1.7k Stars。通过 LlamaCloud 生态系统处理复杂文档解析,并利用开源模型实现从文档到播客的转换流程。
|
||||
|
||||
## Aliases
|
||||
- run-llama/notebookllama
|
||||
|
||||
## Key Capabilities
|
||||
- **完整技术链条展示**:文本提取 → 脚本生成 → 戏剧化改编 → 文本转语音(TTS)
|
||||
- **LlamaCloud 集成**:处理复杂文档解析
|
||||
- **多种模型支持**:OpenAI API、ElevenLabs API,或完全本地化的模型
|
||||
|
||||
## Learning Value
|
||||
该开源项目是学习如何利用 AI 大模型技术链条构建文档转播客应用的参考实现。
|
||||
|
||||
## GitHub
|
||||
https://github.com/run-llama/notebookllama
|
||||
|
||||
## Role in This Wiki
|
||||
NotebookLlama 的核心价值在于作为学习参考,展示构建文档转播客应用的完整 AI 技术链条。
|
||||
66
wiki/entities/Obsidian.md
Normal file
66
wiki/entities/Obsidian.md
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: "Obsidian"
|
||||
type: entity
|
||||
tags: [笔记工具, 知识管理, 双链笔记]
|
||||
sources: []
|
||||
last_updated: 2026-04-09
|
||||
---
|
||||
|
||||
# Obsidian
|
||||
|
||||
## Aliases
|
||||
- Obsidian.md
|
||||
- Obsidian 笔记
|
||||
|
||||
## 描述
|
||||
本地优先的笔记和知识管理工具,支持双链笔记、Graph View 图谱视图和丰富的社区插件生态。通过 iCloud Drive 或 Obsidian Git 插件实现多端同步。
|
||||
|
||||
## 核心特性
|
||||
|
||||
### 双链笔记 (Bidirectional Links)
|
||||
通过 `[[wikilinks]]` 语法在页面间建立双向链接,形成知识网络而非孤岛。
|
||||
|
||||
### Graph View
|
||||
左侧边栏图谱图标(或 `Ctrl+G`)将所有 Wiki 页面以节点展示,双链关系自动连线:
|
||||
- **健康检查**:没有任何页面链接指向它 → 孤岛页面,需要补上交叉引用
|
||||
- **发现盲区**:某个概念被很多页面提到但自己还没有独立页面 → 灰色幽灵节点
|
||||
|
||||
### 社区插件
|
||||
- **Obsidian Git**:自动 commit + push 到 Git 仓库
|
||||
- **Obsidian Web Clipper**:浏览器插件,快速采集网页文章为 Markdown
|
||||
- **Dataview**:类似数据库的笔记查询
|
||||
- **Tasks**:任务管理
|
||||
- **Templater**:动态模板
|
||||
|
||||
## 与 AI Agent 的集成
|
||||
|
||||
### 目录结构(OpenClaw 用法)
|
||||
```
|
||||
/Users/weishen/Workspace/nexus/
|
||||
├── openclaw/
|
||||
│ ├── knowledgebase/ ← 经过整理、跨 Agent 共用的知识
|
||||
│ ├── xingshu/ ← 星枢专属笔记
|
||||
│ ├── xinghui/ ← 星辉专属笔记
|
||||
│ ├── xingyao/ ← 星曜专属笔记
|
||||
└── …(其他 Obsidian 笔记)
|
||||
```
|
||||
|
||||
### OpenClaw obsidian skill
|
||||
支持的操作:
|
||||
- `obsidian write` — 创建或覆盖一篇笔记
|
||||
- `obsidian append` — 在已有笔记末尾追加内容
|
||||
- `obsidian read` — 读取笔记内容
|
||||
- `obsidian search` — 在笔记库中搜索关键词
|
||||
- `obsidian update` — 修改笔记的特定部分
|
||||
|
||||
## 图片本地化
|
||||
剪藏的网页文章图片通常是外链,几个月后失效。解决方案:
|
||||
1. 设置 → 文件与链接 → 附件存储路径 → 设为当前文件夹下的 `attachments/` 子目录
|
||||
2. 绑定下载快捷键(如 `Ctrl+Shift+D`)→ 剪藏完按一下快捷键,所有图片自动下载到本地
|
||||
|
||||
## 相关来源
|
||||
- [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]]
|
||||
- [[obsidian-高效指南-我常用的插件与实用技巧]]
|
||||
- [[obsidian最有必要安装的10款插件是这些]]
|
||||
- [[Obsidian Tasks 插件-这可能是最适合懒人的任务管理方式]]
|
||||
- [[dataview-让我从笔记黑洞里逃出来的-obsidian-神器-1]]
|
||||
31
wiki/entities/OpenNotebook.md
Normal file
31
wiki/entities/OpenNotebook.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "OpenNotebook"
|
||||
type: entity
|
||||
tags: [product, open-source, ai, github, local-deployment]
|
||||
sources: [google-神级生产力工具-所有-github-开源平替都找到了]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
OpenNotebook 是 GitHub 上 Star 数量最高的 NotebookLM 开源平替项目(14.6k Stars)。作为全功能本地化解决方案,不依赖云端即可进行知识管理和研究,支持 Docker 轻松部署。
|
||||
|
||||
## Aliases
|
||||
- Open Notebook
|
||||
- lfnovo/open-notebook
|
||||
|
||||
## Key Capabilities
|
||||
- **多 AI 提供商支持**:超过 16 种 AI 提供商,包括 OpenAI、Anthropic、Claude、Gemini 等主流云端模型
|
||||
- **本地模型支持**:完美支持通过 [[Ollama]] 或 [[LM Studio]] 运行的本地模型
|
||||
- **多模态内容输入**:PDF、网页、音频、YouTube 视频
|
||||
- **文档问答**:类似 NotebookLM 的文档问答和引用功能
|
||||
- **播客生成**:高级播客生成工具,支持创建多达 4 位演讲者的多角色对话,可对脚本进行精细控制
|
||||
|
||||
## Deployment
|
||||
- Docker 容器化部署
|
||||
- 完全本地化运行,无需云端依赖
|
||||
|
||||
## GitHub
|
||||
https://github.com/lfnovo/open-notebook
|
||||
|
||||
## Role in This Wiki
|
||||
OpenNotebook 是开源平替中功能最全面、Star 最高的项目,适合需要完全本地化部署且功能完整替代的用户。
|
||||
27
wiki/entities/PageLM.md
Normal file
27
wiki/entities/PageLM.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "PageLM"
|
||||
type: entity
|
||||
tags: [product, open-source, ai, github, education]
|
||||
sources: [google-神级生产力工具-所有-github-开源平替都找到了]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
PageLM 是一个把学习材料转化为互动式资源的教育平台,通过 AI 技术提升学习效率。该开源项目提供了一系列针对学习场景优化的功能。
|
||||
|
||||
## Aliases
|
||||
- CaviraOSS/PageLM
|
||||
|
||||
## Key Capabilities
|
||||
- **康奈尔笔记(SmartNotes)**:自动生成结构化康奈尔格式笔记
|
||||
- **互动测验**:基于文档的自动生成测验
|
||||
- **间隔重复闪卡(Flashcards)**:支持科学复习的闪卡系统
|
||||
- **模拟考试系统(ExamLab)**:自动化模拟考试生成
|
||||
- **播客转换**:将枯燥的学习资料转化为播客,支持读、听、测三种学习方式
|
||||
- **多 AI 模型支持**:Google Gemini、OpenAI GPT、Anthropic Claude、本地 Ollama 模型
|
||||
|
||||
## GitHub
|
||||
https://github.com/CaviraOSS/PageLM
|
||||
|
||||
## Role in This Wiki
|
||||
PageLM 是教育场景的垂直工具,适合需要将文档转化为学习资源的教育者和学生。
|
||||
31
wiki/entities/Podcastfy.md
Normal file
31
wiki/entities/Podcastfy.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "Podcastfy"
|
||||
type: entity
|
||||
tags: [product, open-source, ai, github, podcast]
|
||||
sources: [google-神级生产力工具-所有-github-开源平替都找到了]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Podcastfy 专注于播客生成,对标的是 NotebookLM 的播客生成功能。它可以把多模态内容(文本、图像、网站、PDF 等)转化为高质量、多语言的音频对话。
|
||||
|
||||
## Aliases
|
||||
- souzatharsis/podcastfy
|
||||
|
||||
## Key Capabilities
|
||||
- **多模态输入转换**:文本、图像、网站、PDF → 高质量音频对话
|
||||
- **高度定制化**:支持短视频风格(Shorts)或长篇深度(Longform)播客内容
|
||||
- **100+ LLM 整合**:用于脚本生成
|
||||
- **多 TTS 引擎**:OpenAI、Google、ElevenLabs、Microsoft Edge TTS 等多种语音合成引擎
|
||||
- **多使用方式**:Python 包、命令行工具、Web 界面
|
||||
|
||||
## Deployment
|
||||
- Python 包(pip install)
|
||||
- 命令行工具
|
||||
- Web 界面
|
||||
|
||||
## GitHub
|
||||
https://github.com/souzatharsis/podcastfy
|
||||
|
||||
## Role in This Wiki
|
||||
Podcastfy 是专门做播客生成的开源工具,适合只需要 NotebookLM 播客功能、不需要文档问答的用户。
|
||||
31
wiki/entities/SurfSense.md
Normal file
31
wiki/entities/SurfSense.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "SurfSense"
|
||||
type: entity
|
||||
tags: [product, open-source, ai, github, research]
|
||||
sources: [google-神级生产力工具-所有-github-开源平替都找到了]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
SurfSense 是一个综合型开源 AI 搜索与研究智能体,定位为 NotebookLM、Perplexity 和 Glean 的开源替代品,在 GitHub 上拥有 11.4k 颗 Star。它不仅能处理上传的文件,还能连接广泛的外部数据源,通过整合个人知识库和外部信息流进行深度定制化研究。
|
||||
|
||||
## Aliases
|
||||
- MODSetter/SurfSense
|
||||
|
||||
## Key Capabilities
|
||||
- **外部数据源集成**:Notion、YouTube、GitHub 等多种平台和工具
|
||||
- **混合搜索技术**:语义搜索 + 全文搜索,结合重排序算法确保精准引用
|
||||
- **自然语言对话**:与保存的内容进行自然语言对话,生成带引用的答案
|
||||
- **本地 LLM 支持**:利用本地 LLM 保护隐私
|
||||
- **播客生成**:快速播客生成智能体,支持多种文本转语音服务
|
||||
- **团队协作**:支持 Docker 部署和基于角色的访问控制(RBAC)
|
||||
|
||||
## Deployment
|
||||
- Docker 容器化部署
|
||||
- 支持 RBAC 团队协作场景
|
||||
|
||||
## GitHub
|
||||
https://github.com/MODSetter/SurfSense
|
||||
|
||||
## Role in This Wiki
|
||||
SurfSense 是最具综合性的平替,适合需要整合外部数据源进行研究的用户。
|
||||
51
wiki/entities/clawr.ing.md
Normal file
51
wiki/entities/clawr.ing.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "clawr.ing"
|
||||
type: entity
|
||||
tags: [clawr.ing, telephony, OpenClaw, notification, voice, PSTN]
|
||||
sources: [phone-call-notifications]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- clawr.ing
|
||||
- Clawr.ing
|
||||
- clawring
|
||||
|
||||
## Definition
|
||||
|
||||
clawr.ing 是一个托管电话服务(Managed Calling Service),为 AI Agent 提供主动向用户拨打电话的能力,无需配置 Twilio 或其他电话 API。用户只需粘贴一段 setup prompt,Agent 即获得电话呼叫能力,支持 100+ 国家的真实 PSTN 电话。音频传输加密,不存储录音或文字记录,通话完成后即时销毁。
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
- **Agent-Initiated Calls**: Agent 主动拨叫用户真实电话号码,而非用户呼叫 Agent
|
||||
- **Two-Way Conversation**: 用户接听后可实时提问,Agent 实时响应——真正的双向对话,而非单向广播
|
||||
- **Global PSTN Coverage**: 100+ 国家真实公共交换电话网电话,非 VoIP 叠加层
|
||||
- **Zero-Config Setup**: 粘贴 setup prompt 即可,无需 Twilio 账号、无需电话号码配置、无需 Webhook
|
||||
- **Privacy by Design**: 不存储录音、不存储文字记录,音频加密传输后即时销毁
|
||||
- **Fast Model Compatible**: 可配合快速模型(Haiku 级别)降低通话延迟
|
||||
|
||||
## How It Works
|
||||
|
||||
1. 用户从 [clawr.ing dashboard](https://clawr.ing) 获取一段 setup prompt
|
||||
2. 将 setup prompt 粘贴到 OpenClaw 对话中,Agent 自动读取文档并配置呼叫能力
|
||||
3. Agent 通过自然语言触发呼叫(如 "Call me if NVDA drops 5% today")
|
||||
4. clawr.ing 执行实际电话呼叫,用户接听即可双向对话
|
||||
|
||||
## Use Cases
|
||||
|
||||
- 紧急告警:股价暴跌、服务器宕机等关键事件立即电话通知
|
||||
- 定时简报:每天早晨 7:30 定时来电播报天气/日历/新闻
|
||||
- 重要邮件过滤:老板或标记紧急的邮件立即电话通知
|
||||
- 任何需要"无法忽视"触达的场景
|
||||
|
||||
## Design Principles
|
||||
|
||||
- **控制频率**:电话通知必须稀缺("这真的很重要才打电话"),否则用户会麻木
|
||||
- **配合触发器**:clawr.ing 是投递通道,需要 Heartbeat/Cron Job 作为触发器
|
||||
- **快速响应优先**:通话场景使用快速模型减少等待延迟
|
||||
|
||||
## Connections
|
||||
- [[clawr.ing]] ← powers ← [[phone-call-notifications]]
|
||||
- [[clawhub.ai]] ← hosts ← [[clawr.ing]] skill
|
||||
- [[OpenClaw]] ← extends via ← [[clawr.ing]] skill
|
||||
- [[phone-based-personal-assistant]] ← related_to ← [[clawr.ing]](后者侧重 Agent 去电通知,前者侧重用户来电咨询)
|
||||
43
wiki/entities/苏东坡.md
Normal file
43
wiki/entities/苏东坡.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "苏东坡"
|
||||
type: entity
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Overview
|
||||
苏轼(1037-1101),号东坡居士,北宋文学家、书法家、画家,唐宋八大家之一。一生三起三落:从庙堂翰林到黄州团练副使,再到惠州、儋州南荒,最后病逝于北归途中常州。无论被贬到多荒远的地方,始终躬耕做事——东坡种田、惠州插秧、儋州办学堂。"问汝平生功业,黄州惠州儋州"是自嘲也是骨气。
|
||||
|
||||
## Type
|
||||
人物 / 历史人物 / 思维导师
|
||||
|
||||
## Aliases
|
||||
- 苏轼
|
||||
- 苏东坡
|
||||
- 东坡居士
|
||||
- 苏子瞻
|
||||
- SuDongPo
|
||||
|
||||
## 蒸馏出的六大心智模型
|
||||
|
||||
1. **进退由时,行藏在我** — 庙堂之高与江湖之远都是正确的人生选项,判断"此刻我能进吗"+"我内心想进吗"
|
||||
2. **此心安处是吾乡** — 故乡不是地理概念,是心安之处;被贬黄州物质最匮乏的三年反而诞生了《赤壁赋》等一生最重要作品
|
||||
3. **辞达而已** — 文章千古事,妙在准确传达,不在辞藻堆砌;回到"我要传达什么"这个根本问题
|
||||
4. **以时受力,逆境转化** — 时间和困苦可以转化,逆境是创作的土壤;不是歌颂苦难,而是肯定人在苦难中的主动转化能力
|
||||
5. **自出新意,不践古人** — 学习古人是为了超越古人,不是成为古人;传承是底座,超越是目的
|
||||
6. **物我相谙,天人合一** — 人与自然不是主客体对立,而是融为一体;从不同尺度、不同角度重新审视问题
|
||||
|
||||
## 关键语录(被AI蒸馏后)
|
||||
- "大江东去,浪淘尽,千古风流人物"——但真正风流的人,不是站在浪尖上的人,而是**被浪打下去、还能爬起来的人**
|
||||
- "人生到处知何似,应似飞鸿踏雪泥"——人生虽充满偶然和不确定性,但每一次经历和痕迹都值得珍惜
|
||||
|
||||
## 蒸馏为AI Skill
|
||||
- 产出:[[苏东坡Skill]](ishenwei/openclaw-skills仓库)
|
||||
- 基于:[[女娲]](Nuwa Skill)框架
|
||||
- 蒸馏方式:6个并行Agent从6维度采集(著作/对话/表达DNA/他者视角/决策/时间线)
|
||||
- 激活后:AI以苏东坡的视角与用户对话
|
||||
|
||||
## Related Links
|
||||
- [[女娲]] — 提供蒸馏框架的开源项目
|
||||
- [[苏东坡Skill]] — 蒸馏产出的AI Skill
|
||||
- [[数字导师]] — 蒸馏苏东坡的动机——成为日常思维顾问
|
||||
- [[养虾日记5]] — 蒸馏苏东坡的完整记录
|
||||
@@ -4,6 +4,22 @@
|
||||
- [Overview](overview.md) — living synthesis
|
||||
|
||||
## Sources
|
||||
- [2026-04-22] [文字生成视频网站推荐](sources/文字生成视频网站推荐.md)
|
||||
- [2026-04-22] [Google 神级生产力工具,所有 GitHub 开源平替都找到了。](sources/google-神级生产力工具-所有-github-开源平替都找到了.md)
|
||||
- [2026-04-22] [教學 ChatGPT 先做知識整理,再讓 Canva、 Gamma AI 輸出簡報](sources/教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報.md)
|
||||
- [2026-04-22] [Designing for Agentic AI](sources/designing-for-agentic-ai.md)
|
||||
- [2026-04-22] [14个免费的AI图生视频工具,用AI让图片动起来](sources/14个免费的ai图生视频工具-用ai让图片动起来-ai视频教程-ai自动化工作流定制服务-ai培训学习平台-黑喵大叔.md)
|
||||
- [2026-04-22] [养虾日记5:深夜与苏轼聊AI,他说:被浪打下去还能爬起来的才叫风流](sources/养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流.md)
|
||||
- [2026-04-22] [养虾日记4:一次「Context Limit Exceeded」错误排查:我以为是小问题,结果踩了大坑](sources/养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑.md)
|
||||
- [2026-04-22] [不谈技术:普通人该怎么在AI时代赚钱?](sources/不谈技术-普通人该怎么在ai时代赚钱.md)
|
||||
- [2026-04-22] [养虾日记3:用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统](sources/养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统.md)
|
||||
- [2026-04-22] [养龙虾5天血泪史:我的AI Agent为什么总失忆?OpenClaw 记忆调试全记录](sources/养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录.md)
|
||||
- [2026-04-22] [养虾日记1:我用 OpenClaw 管了 28 万张照片:一次真实的多设备照片整理实战](sources/养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战.md)
|
||||
- [2026-04-22] [养虾日记2:让Agent更懂你:OpenClaw + Self-Improving 复盘实战案例分享](sources/养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享.md)
|
||||
- [2026-04-22] [X Account Analysis](sources/x-account-analysis.md)
|
||||
- [2026-04-22] [Phone Call Notifications](sources/phone-call-notifications.md)
|
||||
- [2026-04-22] [Autonomous Educational Game Development Pipeline](sources/autonomous-game-dev-pipeline.md)
|
||||
- [2026-04-22] [arXiv Paper Reader](sources/arxiv-paper-reader.md)
|
||||
- [2026-04-22] [Semantic Memory Search](sources/semantic-memory-search.md)
|
||||
- [2026-04-22] [OpenClaw as Desktop Cowork (AionUi) — Remote Rescue & Multi-Agent Hub](sources/aionui-cowork-desktop.md)
|
||||
- [2026-04-22] [Family Calendar Aggregation & Household Assistant](sources/family-calendar-household-assistant.md)
|
||||
@@ -130,7 +146,6 @@
|
||||
- [2026-04-21] [marketing-carousel-growth-engine](sources/marketing-carousel-growth-engine.md) — (expected: wiki/sources/marketing-carousel-growth-engine.md — source missing)
|
||||
- [2026-04-21] [codecrafters-iobuild-your-own-x-master-programming-by-recreating-your-favorite-technologies-from-scratch](sources/codecrafters-iobuild-your-own-x-master-programming-by-recreating-your-favorite-technologies-from-scratch.md) — (expected: wiki/sources/codecrafters-iobuild-your-own-x-master-programming-by-recreating-your-favorite-technologies-from-scratch.md — source missing)
|
||||
- [2026-04-21] [marketing-private-domain-operator](sources/marketing-private-domain-operator.md) — (expected: wiki/sources/marketing-private-domain-operator.md — source missing)
|
||||
- [2026-04-21] [教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報](sources/教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報.md) — (expected: wiki/sources/教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報.md — source missing)
|
||||
- [2026-04-21] [marketing-short-video-editing-coach](sources/marketing-short-video-editing-coach.md) — (expected: wiki/sources/marketing-short-video-editing-coach.md — source missing)
|
||||
- [2026-04-21] [marketing-social-media-strategist](sources/marketing-social-media-strategist.md) — (expected: wiki/sources/marketing-social-media-strategist.md — source missing)
|
||||
- [2026-04-21] [marketing-kuaishou-strategist](sources/marketing-kuaishou-strategist.md) — (expected: wiki/sources/marketing-kuaishou-strategist.md — source missing)
|
||||
@@ -398,22 +413,7 @@
|
||||
- [2026-04-18] [openai-chatgpt-个性化定义](sources/openai-chatgpt-个性化定义.md) — (expected: wiki/sources/openai-chatgpt-个性化定义.md — source missing)
|
||||
- [2026-04-18] [清华出的deepseek使用手册-104页-真的是太厉害了-免费领取](sources/清华出的deepseek使用手册-104页-真的是太厉害了-免费领取.md) — (expected: wiki/sources/清华出的deepseek使用手册-104页-真的是太厉害了-免费领取.md — source missing)
|
||||
- [2026-04-18] [llms-rag-ai-agent-三个到底什么区别](sources/llms-rag-ai-agent-三个到底什么区别.md) — (expected: wiki/sources/llms-rag-ai-agent-三个到底什么区别.md — source missing)
|
||||
- [2026-04-18] [a-formalization-of-recursive-self-optimizing-generative-systems](sources/a-formalization-of-recursive-self-optimizing-generative-systems.md) — (expected: wiki/sources/a-formalization-of-recursive-self-optimizing-generative-systems.md — source missing)
|
||||
- [2026-04-18] [文字生成视频网站推荐](sources/文字生成视频网站推荐.md) — (expected: wiki/sources/文字生成视频网站推荐.md — source missing)
|
||||
- [2026-04-18] [google-神级生产力工具-所有-github-开源平替都找到了](sources/google-神级生产力工具-所有-github-开源平替都找到了.md) — (expected: wiki/sources/google-神级生产力工具-所有-github-开源平替都找到了.md — source missing)
|
||||
- [2026-04-18] [designing-for-agentic-ai](sources/designing-for-agentic-ai.md) — (expected: wiki/sources/designing-for-agentic-ai.md — source missing)
|
||||
- [2026-04-18] [14个免费的ai图生视频工具-用ai让图片动起来-ai视频教程-ai自动化工作流定制服务-ai培训学习平台-黑喵大叔](sources/14个免费的ai图生视频工具-用ai让图片动起来-ai视频教程-ai自动化工作流定制服务-ai培训学习平台-黑喵大叔.md) — (expected: wiki/sources/14个免费的ai图生视频工具-用ai让图片动起来-ai视频教程-ai自动化工作流定制服务-ai培训学习平台-黑喵大叔.md — source missing)
|
||||
- [2026-04-18] [养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流](sources/养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流.md) — (expected: wiki/sources/养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流.md — source missing)
|
||||
- [2026-04-18] [养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑](sources/养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑.md) — (expected: wiki/sources/养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑.md — source missing)
|
||||
- [2026-04-17] [不谈技术-普通人该怎么在ai时代赚钱](sources/不谈技术-普通人该怎么在ai时代赚钱.md) — (expected: wiki/sources/不谈技术-普通人该怎么在ai时代赚钱.md — source missing)
|
||||
- [2026-04-17] [养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统](sources/养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统.md) — (expected: wiki/sources/养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统.md — source missing)
|
||||
- [2026-04-17] [养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录](sources/养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录.md) — (expected: wiki/sources/养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录.md — source missing)
|
||||
- [2026-04-17] [养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战](sources/养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战.md) — (expected: wiki/sources/养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战.md — source missing)
|
||||
- [2026-04-17] [养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享](sources/养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享.md) — (expected: wiki/sources/养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享.md — source missing)
|
||||
- [2026-04-17] [x-account-analysis](sources/x-account-analysis.md) — (expected: wiki/sources/x-account-analysis.md — source missing)
|
||||
- [2026-04-17] [phone-call-notifications](sources/phone-call-notifications.md) — (expected: wiki/sources/phone-call-notifications.md — source missing)
|
||||
- [2026-04-17] [autonomous-game-dev-pipeline](sources/autonomous-game-dev-pipeline.md) — (expected: wiki/sources/autonomous-game-dev-pipeline.md — source missing)
|
||||
- [2026-04-17] [arXiv Paper Reader](sources/arxiv-paper-reader.md) — AI Agent 驱动的 arXiv 论文阅读助手,通过 arxiv-reader skill 实现对话式论文浏览、摘要对比和选择性细读,无需离开工作区
|
||||
- [2025-12-30] [A Formalization of Recursive Self-Optimizing Generative Systems](sources/a-formalization-of-recursive-self-optimizing-generative-systems.md) — 递归自我优化生成系统的形式化模型,用不动点语义刻画元生成过程
|
||||
- [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
|
||||
- [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
|
||||
- [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing)
|
||||
@@ -558,10 +558,12 @@
|
||||
- [Caddy](entities/Caddy.md)
|
||||
- [cAdvisor](entities/cAdvisor.md)
|
||||
- [Calibre](entities/Calibre.md)
|
||||
- [Canva](entities/Canva.md)
|
||||
- [Claude-Desktop](entities/Claude-Desktop.md)
|
||||
- [Claude-Pro](entities/Claude-Pro.md)
|
||||
- [ClawdTalk](entities/ClawdTalk.md)
|
||||
- [ClawHub](entities/ClawHub.md)
|
||||
- [clawr.ing](entities/clawr.ing.md)
|
||||
- [Clonezilla](entities/Clonezilla.md)
|
||||
- [cloud-computing](entities/cloud-computing.md)
|
||||
- [Cloud-Maturity-Model](entities/Cloud-Maturity-Model.md)
|
||||
@@ -582,10 +584,12 @@
|
||||
- [DORA-Metrics](entities/DORA-Metrics.md)
|
||||
- [DracoVibeCoding](entities/DracoVibeCoding.md)
|
||||
- [frp](entities/frp.md)
|
||||
- [Gamma-AI](entities/Gamma-AI.md)
|
||||
- [GDPR](entities/GDPR.md)
|
||||
- [Gitea](entities/Gitea.md)
|
||||
- [glances](entities/glances.md)
|
||||
- [gog](entities/gog.md)
|
||||
- [Google](entities/Google.md)
|
||||
- [Google-Cloud](entities/Google-Cloud.md)
|
||||
- [GoogleCloud](entities/GoogleCloud.md)
|
||||
- [Grafana](entities/Grafana.md)
|
||||
@@ -595,6 +599,7 @@
|
||||
- [HP-ZBook](entities/HP-ZBook.md)
|
||||
- [htop](entities/htop.md)
|
||||
- [idea-reality-mcp](entities/idea-reality-mcp.md)
|
||||
- [InsightsLM](entities/InsightsLM.md)
|
||||
- [ISO-27001](entities/ISO-27001.md)
|
||||
- [it-tools](entities/it-tools.md)
|
||||
- [Jellyfin](entities/Jellyfin.md)
|
||||
@@ -621,12 +626,19 @@
|
||||
- [node-exporter](entities/node-exporter.md)
|
||||
- [Node.js](entities/Node.js.md)
|
||||
- [nodewarden](entities/nodewarden.md)
|
||||
- [NotebookLlama](entities/NotebookLlama.md)
|
||||
- [NotebookLM](entities/NotebookLM.md)
|
||||
- [Obsidian](entities/Obsidian.md)
|
||||
- [Open-Alliance-for-Cloud-Adoption](entities/Open-Alliance-for-Cloud-Adoption.md)
|
||||
- [OpenClaw](entities/OpenClaw.md)
|
||||
- [openclaw-n8n-stack](entities/openclaw-n8n-stack.md)
|
||||
- [OpenCode](entities/OpenCode.md)
|
||||
- [OpenNotebook](entities/OpenNotebook.md)
|
||||
- [PageLM](entities/PageLM.md)
|
||||
- [PingMe](entities/PingMe.md)
|
||||
- [Podcastfy](entities/Podcastfy.md)
|
||||
- [Portainer](entities/Portainer.md)
|
||||
- [Prismer-AI](entities/Prismer-AI.md)
|
||||
- [Prometheus](entities/Prometheus.md)
|
||||
- [Public-Cloud-Provider](entities/Public-Cloud-Provider.md)
|
||||
- [RackNerd](entities/RackNerd.md)
|
||||
@@ -640,6 +652,7 @@
|
||||
- [Slack](entities/Slack.md)
|
||||
- [SparkryAI](entities/SparkryAI.md)
|
||||
- [stacer](entities/stacer.md)
|
||||
- [SurfSense](entities/SurfSense.md)
|
||||
- [Synology-NAS-DS718](entities/Synology-NAS-DS718.md)
|
||||
- [Telnyx](entities/Telnyx.md)
|
||||
- [Terraform](entities/Terraform.md)
|
||||
@@ -662,6 +675,7 @@
|
||||
- [盖伊亨德里克斯](entities/盖伊亨德里克斯.md)
|
||||
- [矿神源](entities/矿神源.md)
|
||||
- [网件RAX50](entities/网件RAX50.md)
|
||||
- [苏东坡](entities/苏东坡.md)
|
||||
|
||||
## Concepts
|
||||
- [ActionItemTracking](concepts/ActionItemTracking.md)
|
||||
@@ -672,6 +686,7 @@
|
||||
- [Agent-Memory](concepts/Agent-Memory.md)
|
||||
- [Agent-Mode](concepts/Agent-Mode.md)
|
||||
- [Agent-Personality](concepts/Agent-Personality.md)
|
||||
- [Agent-Routing-Rules](concepts/Agent-Routing-Rules.md)
|
||||
- [Agent-Specialization](concepts/Agent-Specialization.md)
|
||||
- [AGENTS.md](concepts/AGENTS.md.md)
|
||||
- [AgilePractices](concepts/AgilePractices.md)
|
||||
@@ -681,9 +696,13 @@
|
||||
- [Ai-Powered-Digest](concepts/Ai-Powered-Digest.md)
|
||||
- [AIOps](concepts/AIOps.md)
|
||||
- [AI代理](concepts/AI代理.md)
|
||||
- [AI图生视频](concepts/AI图生视频.md)
|
||||
- [AI文生视频](concepts/AI文生视频.md)
|
||||
- [AI簡報工作流](concepts/AI簡報工作流.md)
|
||||
- [Alerting](concepts/Alerting.md)
|
||||
- [AmbientMessageMonitoring](concepts/AmbientMessageMonitoring.md)
|
||||
- [APT-仓库配置](concepts/APT-仓库配置.md)
|
||||
- [arXiv-API](concepts/arXiv-API.md)
|
||||
- [Asset-Management](concepts/Asset-Management.md)
|
||||
- [Attach容器](concepts/Attach容器.md)
|
||||
- [Audit-Trail](concepts/Audit-Trail.md)
|
||||
@@ -702,6 +721,7 @@
|
||||
- [Business-Impact-Analysis](concepts/Business-Impact-Analysis.md)
|
||||
- [Business-Knowledge-Base](concepts/Business-Knowledge-Base.md)
|
||||
- [caffeinate](concepts/caffeinate.md)
|
||||
- [Call-Worthy-Threshold](concepts/Call-Worthy-Threshold.md)
|
||||
- [Canary-Release](concepts/Canary-Release.md)
|
||||
- [Centralized-Logging](concepts/Centralized-Logging.md)
|
||||
- [CEOPattern](concepts/CEOPattern.md)
|
||||
@@ -727,12 +747,14 @@
|
||||
- [Cloud-Service-Delivery](concepts/Cloud-Service-Delivery.md)
|
||||
- [CMDB](concepts/CMDB.md)
|
||||
- [CodeWeaver](concepts/CodeWeaver.md)
|
||||
- [Compaction](concepts/Compaction.md)
|
||||
- [Competition-Analysis](concepts/Competition-Analysis.md)
|
||||
- [Compliance-Automation](concepts/Compliance-Automation.md)
|
||||
- [Configuration-Management](concepts/Configuration-Management.md)
|
||||
- [Content Automation](concepts/Content Automation.md)
|
||||
- [Content-Hashing](concepts/Content-Hashing.md)
|
||||
- [Content-Ingestion](concepts/Content-Ingestion.md)
|
||||
- [Context-Window](concepts/Context-Window.md)
|
||||
- [Continuous-Deployment](concepts/Continuous-Deployment.md)
|
||||
- [Continuous-Integration](concepts/Continuous-Integration.md)
|
||||
- [Conversational-Interface](concepts/Conversational-Interface.md)
|
||||
@@ -770,6 +792,7 @@
|
||||
- [efibootmgr](concepts/efibootmgr.md)
|
||||
- [Email-Triage](concepts/Email-Triage.md)
|
||||
- [Error-Budget](concepts/Error-Budget.md)
|
||||
- [Error-Surface-vs-Root-Cause](concepts/Error-Surface-vs-Root-Cause.md)
|
||||
- [Event-Correlation](concepts/Event-Correlation.md)
|
||||
- [EventSourcing](concepts/EventSourcing.md)
|
||||
- [Exporter](concepts/Exporter.md)
|
||||
@@ -792,6 +815,7 @@
|
||||
- [Green-Computing](concepts/Green-Computing.md)
|
||||
- [Headless-服务器](concepts/Headless-服务器.md)
|
||||
- [Heartbeat-Monitoring](concepts/Heartbeat-Monitoring.md)
|
||||
- [Hidden-Failure-Paths](concepts/Hidden-Failure-Paths.md)
|
||||
- [high-availability](concepts/high-availability.md)
|
||||
- [HouseholdInventoryTracking](concepts/HouseholdInventoryTracking.md)
|
||||
- [HTTPS自动化证书](concepts/HTTPS自动化证书.md)
|
||||
@@ -818,14 +842,20 @@
|
||||
- [Knowledge-Base-RAG](concepts/Knowledge-Base-RAG.md)
|
||||
- [Language-Detection](concepts/Language-Detection.md)
|
||||
- [Last-30-Days-Method](concepts/Last-30-Days-Method.md)
|
||||
- [LaTeX-Flattening](concepts/LaTeX-Flattening.md)
|
||||
- [launchd](concepts/launchd.md)
|
||||
- [Layered-Configuration](concepts/Layered-Configuration.md)
|
||||
- [Lead-Time](concepts/Lead-Time.md)
|
||||
- [LLM-Wiki](concepts/LLM-Wiki.md)
|
||||
- [Local-Caching](concepts/Local-Caching.md)
|
||||
- [Local-first-Git](concepts/Local-first-Git.md)
|
||||
- [Lockable-Workflow](concepts/Lockable-Workflow.md)
|
||||
- [Log-Driven-Debugging](concepts/Log-Driven-Debugging.md)
|
||||
- [MCPOnceAllAgents](concepts/MCPOnceAllAgents.md)
|
||||
- [MeetingNotes](concepts/MeetingNotes.md)
|
||||
- [MEMORY.md](concepts/MEMORY.md.md)
|
||||
- [Micro-Recovery](concepts/Micro-Recovery.md)
|
||||
- [Model-Fallback](concepts/Model-Fallback.md)
|
||||
- [Morning-Briefing](concepts/Morning-Briefing.md)
|
||||
- [MTTA](concepts/MTTA.md)
|
||||
- [MTTD](concepts/MTTD.md)
|
||||
@@ -843,6 +873,7 @@
|
||||
- [Obsidian-Tasks](concepts/Obsidian-Tasks.md)
|
||||
- [OWASP-Top-Ten](concepts/OWASP-Top-Ten.md)
|
||||
- [Pain-Point-Mining](concepts/Pain-Point-Mining.md)
|
||||
- [Paper-Abstract-Batch-Fetching](concepts/Paper-Abstract-Batch-Fetching.md)
|
||||
- [Parallel-Agent-Execution](concepts/Parallel-Agent-Execution.md)
|
||||
- [passkey](concepts/passkey.md)
|
||||
- [Pay-as-you-go](concepts/Pay-as-you-go.md)
|
||||
@@ -898,6 +929,7 @@
|
||||
- [Security-and-Compliance](concepts/Security-and-Compliance.md)
|
||||
- [Self-Healing-Systems](concepts/Self-Healing-Systems.md)
|
||||
- [self-hosted-password-manager](concepts/self-hosted-password-manager.md)
|
||||
- [Self-Improving-Skill](concepts/Self-Improving-Skill.md)
|
||||
- [Semantic-Deduplication](concepts/Semantic-Deduplication.md)
|
||||
- [Semantic-Search](concepts/Semantic-Search.md)
|
||||
- [Sequential-Thinking](concepts/Sequential-Thinking.md)
|
||||
@@ -940,6 +972,7 @@
|
||||
- [Transcript-Based-Summarization](concepts/Transcript-Based-Summarization.md)
|
||||
- [TranscriptProcessing](concepts/TranscriptProcessing.md)
|
||||
- [tui](concepts/tui.md)
|
||||
- [Two-Way-Voice-Conversation](concepts/Two-Way-Voice-Conversation.md)
|
||||
- [UEFI-Only](concepts/UEFI-Only.md)
|
||||
- [UEFI启动](concepts/UEFI启动.md)
|
||||
- [Unified-Inbox](concepts/Unified-Inbox.md)
|
||||
@@ -949,6 +982,7 @@
|
||||
- [Vibe-Coding](concepts/Vibe-Coding.md)
|
||||
- [Visual-Debugging](concepts/Visual-Debugging.md)
|
||||
- [Voice-Interface](concepts/Voice-Interface.md)
|
||||
- [Voice-Notification-Channel](concepts/Voice-Notification-Channel.md)
|
||||
- [Vulnerability-Scanning](concepts/Vulnerability-Scanning.md)
|
||||
- [Wake-on-LAN](concepts/Wake-on-LAN.md)
|
||||
- [Wayland](concepts/Wayland.md)
|
||||
@@ -963,16 +997,21 @@
|
||||
- [Zero-Friction-Capture](concepts/Zero-Friction-Capture.md)
|
||||
- [Zero-Trust-Architecture](concepts/Zero-Trust-Architecture.md)
|
||||
- [一人公司](concepts/一人公司.md)
|
||||
- [上下文刷新](concepts/上下文刷新.md)
|
||||
- [上下文压缩](concepts/上下文压缩.md)
|
||||
- [个人品牌](concepts/个人品牌.md)
|
||||
- [云盘挂载](concepts/云盘挂载.md)
|
||||
- [交接协议](concepts/交接协议.md)
|
||||
- [产品四层级体系](concepts/产品四层级体系.md)
|
||||
- [价格锚定与诱饵效应](concepts/价格锚定与诱饵效应.md)
|
||||
- [全盘镜像备份](concepts/全盘镜像备份.md)
|
||||
- [内容矩阵](concepts/内容矩阵.md)
|
||||
- [内网穿透](concepts/内网穿透.md)
|
||||
- [写入纪律](concepts/写入纪律.md)
|
||||
- [单一职责原则](concepts/单一职责原则.md)
|
||||
- [反向代理](concepts/反向代理.md)
|
||||
- [合成监控](concepts/合成监控.md)
|
||||
- [启动序列](concepts/启动序列.md)
|
||||
- [四个心理陷阱](concepts/四个心理陷阱.md)
|
||||
- [固件刷入](concepts/固件刷入.md)
|
||||
- [图床](concepts/图床.md)
|
||||
@@ -984,16 +1023,23 @@
|
||||
- [并发编程](concepts/并发编程.md)
|
||||
- [底层能力](concepts/底层能力.md)
|
||||
- [微服务架构](concepts/微服务架构.md)
|
||||
- [思维蒸馏(女娲造人术)](concepts/思维蒸馏(女娲造人术).md)
|
||||
- [挂载点检查](concepts/挂载点检查.md)
|
||||
- [指纹浏览器](concepts/指纹浏览器.md)
|
||||
- [接码平台](concepts/接码平台.md)
|
||||
- [播客生成](concepts/播客生成.md)
|
||||
- [故障转移](concepts/故障转移.md)
|
||||
- [数字导师](concepts/数字导师.md)
|
||||
- [数据可视化](concepts/数据可视化.md)
|
||||
- [文档问答](concepts/文档问答.md)
|
||||
- [时序数据库](concepts/时序数据库.md)
|
||||
- [本地化部署](concepts/本地化部署.md)
|
||||
- [桥接网络](concepts/桥接网络.md)
|
||||
- [模块化编程](concepts/模块化编程.md)
|
||||
- [每日复盘机制](concepts/每日复盘机制.md)
|
||||
- [永久挂载](concepts/永久挂载.md)
|
||||
- [消息队列](concepts/消息队列.md)
|
||||
- [混合搜索](concepts/混合搜索.md)
|
||||
- [版本控制](concepts/版本控制.md)
|
||||
- [用户权限](concepts/用户权限.md)
|
||||
- [硬件转码](concepts/硬件转码.md)
|
||||
@@ -1004,6 +1050,7 @@
|
||||
- [裸机恢复](concepts/裸机恢复.md)
|
||||
- [订阅机制](concepts/订阅机制.md)
|
||||
- [设备直通](concepts/设备直通.md)
|
||||
- [语义搜索](concepts/语义搜索.md)
|
||||
- [账号隔离](concepts/账号隔离.md)
|
||||
- [跨境支付](concepts/跨境支付.md)
|
||||
- [软链接策略](concepts/软链接策略.md)
|
||||
|
||||
1638
wiki/log.md
1638
wiki/log.md
File diff suppressed because it is too large
Load Diff
@@ -11,13 +11,25 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents)
|
||||
|
||||
**[[phone-based-personal-assistant]]**:通过 ClawdTalk + Telnyx 将任意手机变成 AI 助理语音入口——拨打电话即可与 [[OpenClaw]] 对话,支持日历查询、Jira 任务更新、网络搜索等技能,无需智能手机 App 或浏览器,覆盖驾驶、步行等双手占用场景。与 [[multi-channel-assistant]] 互补:文字入口覆盖图文交互,语音入口覆盖无屏场景。
|
||||
|
||||
**[[phone-call-notifications]]**:AI Agent 通过 [[clawr.ing]] 托管电话服务主动向用户拨打电话通知——Agent 评估事件优先级(股价暴跌/紧急邮件/日程提醒),自动拨叫用户真实号码,用户接听后可实时提问,Agent 双向对话响应。与 [[phone-based-personal-assistant]] 互补:后者为用户→Agent 的来电接收(用户主动呼叫),前者为 Agent→用户的去电通知(Agent 主动呼叫),共同构成完整语音双向通信能力。覆盖 100+ 国家 PSTN 电话,不存储录音,加密传输后即时销毁。
|
||||
|
||||
**[[multi-channel-customer-service]]**:基于 [[OpenClaw]] 的企业级多渠道 AI 客服统一收件箱——整合 WhatsApp Business、Instagram DMs、Gmail 和 Google Reviews 至单一 AI 驱动的收件箱,AI 自动识别消息意图(FAQ/Appointment/Complaint/Review)并匹配对应处理策略,语言自动检测匹配客户语言(ES/EN/UA),支持 Test Mode 演示而不影响真实客户。餐厅实测响应时间从 4+ 小时降至 2 分钟以内,80% 咨询自动处理。与 [[multi-channel-assistant]] 互补——后者面向个人助理多渠道入口,前者面向企业客服场景。
|
||||
|
||||
**Inbox De-clutter**:基于 [[OpenClaw]] 的 Newsletter 自动整理方案——每天 20:00 通过 Cron Job 阅读过去 24 小时的新邮件,生成精华摘要并附原文链接,根据用户反馈持续学习偏好。需前置 Gmail OAuth Setup。与 [[custom-morning-brief]] 属同一 Cron Job + AI 摘要模式的 Newsletter 垂直场景。与 [[email-triage]] 属同一方法论的不同实现。
|
||||
|
||||
**[[Second Brain]]**:基于 [[OpenClaw]] 的个人第二大脑记忆捕获系统——通过短信/Telegram/Discord 零摩擦捕获任何内容(\"Remind me to read a book...\"),OpenClaw 永久记忆存储所有对话,Next.js 可搜索仪表盘提供全局检索,Cmd+K 跨所有记忆/文档/任务全局搜索。核心洞见:**捕获像发短信一样简单,检索像搜索一样简单**。无需文件夹、无需标签、无需复杂组织——文本加搜索足矣。OpenClaw 的累积记忆系统使 AI 随时间变得越来越强大,用户从手机发消息就能在电脑端构建内容。灵感来源:Alex Finn 的 YouTube 视频、Tiago Forte 的《Building a Second Brain》。
|
||||
**[[Second Brain]]**:基于 [[OpenClaw]] 的个人第二大脑记忆捕获系统——通过短信/Telegram/Discord 零摩擦捕获任何内容(\"Remind me to read a book...\"),OpenClaw 永久记忆存储所有对话,Next.js 可搜索仪表盘提供全局检索,Cmd+K 跨所有记忆/文档/任务全局搜索。核心价值:**捕获像发短信一样简单,检索像搜索一样简单**。无需文件夹、无需标签、无需复杂组织——文本加搜索足矣。OpenClaw 的累积记忆系统使 AI 随时间变得越来越强大,用户从手机发消息就能在电脑端构建内容。灵感来源:Alex Finn 的 YouTube 视频、Tiago Forte 的《Building a Second Brain》。
|
||||
|
||||
Key concepts: [[Email Triage]], [[Newsletter Digest]], [[Preference Learning]], [[Cron Job]], [[Multi-Agent Coordination]], [[Multi-Tool Integration]], [[MCP Tool Interface Design]], [[Workflow Architecture]], [[Shared Memory Architecture]], [[Private Context]], [[Single Control Plane]], [[Scheduled Task Flywheel]], [[Parallel Agent Execution]], [[Topic-Based Routing]], [[Voice Interface]], [[Telephony Integration]], [[PM Delegation Pattern]], [[CEO Pattern]], [[Shared State Coordination]], [[Git-as-Audit-Log]], [[Dynamic-Dashboard]], [[Alerting]], [[Zero-Friction Capture]], [[Cumulative Memory]], [[Conversational Interface]], [[Text-and-Search]], [[Unified-Inbox]], [[Intent-Classification]], [[Human-Handoff]], [[Test-Mode]], [[Business-Knowledge-Base]], [[Language-Detection]], [[AI-Auto-Response]], [[Heartbeat-Monitoring]]
|
||||
**Self-Improving 自改进系统**([[养虾日记2]]):解决 AI Agent"每次对话都是白纸"的核心问题——三层记忆架构(短期文件 + 长期向量数据库 + self-improving 复盘)配合每日 23:00 定时复盘,实现"错误只犯一次"的 Agent 学习闭环。Pattern-Key 重复是系统性问题的信号;Recurrence-Count 是区分一次性错误与重复问题的关键指标。[[Self-Improving-Skill]] 的 Suggested Action 必须具体到可直接执行(如 `--to 5038825565`),而非泛泛建议。
|
||||
|
||||
**[[养虾日记3]]**:用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统——解决"AI 对话结束输出就消失"的核心问题。核心架构:**Obsidian 做知识库**(iCloud Drive 三端同步)、**Gitea 做版本控制**(完整保留所有历史版本)、**OpenClaw obsidian skill 做写入接口**。三个 Agent(星枢/星辉/星曜)分别向各自 Obsidian 目录写入,knowledgebase/ 存放跨 Agent 共用知识,<agentId>/ 存放单一 Agent 私有笔记。核心价值:把 AI 变成"会自动整理笔记的实习生"——做完事顺手更新记录。与 [[Second Brain]](对话记忆)、[[Personal Knowledge Base (RAG)]](知识检索)同属持久化记忆能力的不同实现。与 [[self-healing-home-server]] 的 Morning Briefing 共享同一笔记更新机制。融合了 Karpathy 的 LLM Wiki 理念:让 AI 增量构建 Wiki,页面间互链,知识越积越厚。与 [[养虾日记1]](照片整理)、[[养虾日记2]](Self-Improving)、**[[养龙虾5天血泪史]]**(记忆调试)属同一「养虾日记」系列。
|
||||
|
||||
**[[养龙虾5天血泪史]]**:AI Agent 记忆失效问题的专项调试全记录——作者(比利哥)花费 5 天时间系统修复 OpenClaw 助理"星辉"的失忆问题。发现 5 类根本原因:①上下文压缩导致细节丢失(姓名/数字/决定)→ 配置 `memoryFlush` 在压缩前写入磁盘;②纯语义搜索在专有名词上失败 → 切换到 QMD 混合搜索(BM25+向量+重排);③Agent 找到但不自动使用信息 → 启动序列强制触发检索;④多次压缩后上下文仍丢失 → 配置 `contextPruning` 协同工作;⑤系统提示词膨胀 28% → 全面清理未使用技能和无效文件。**10 条黄金法则**:只有 7 个自动加载文件(AGENTS/SOUL/TOOLS/IDENTITY/USER/HEARTBEAT/MEMORY);启动序列必须放在 AGENTS.md 最顶部;**写入纪律比读取纪律更重要**;交接协议是模型切换修复的关键;定期运行 `/context detail` 检测 token 消耗。核心洞察:**压缩不是敌人,未写入的上下文才是**;系统提示词中每个令牌都是代理携带的开销。最终将系统提示词从 209,652 精简到 9,349 令牌,减少 28%。与 [[养虾日记1]](照片整理)、[[养虾日记2]](Self-Improving)属同一「养虾日记」系列,从不同角度解决 OpenClaw 的记忆与持久化问题。
|
||||
|
||||
**[[养虾日记5]]**:用AI蒸馏历史人物思维框架创建"数字导师"——以苏东坡为首位实践,展示如何将千年前古人的心智模型(六道:进退由时/此心安处/辞达而已/逆境转化/自出新意/天人合一)转化为可运行的AI Skill。女娲·Skill造人术通过6个并行Agent从6个维度(著作/对话/表达DNA/他者视角/决策/时间线)采集信息,提炼心智模型、决策启发式和表达DNA,产出自包含的.skill文件。核心洞察:AI时代用AI放大人类历史上最强大的脑子——学投资蒸馏芒格,学物理思维蒸馏费曼,逆境中保持风骨蒸馏苏东坡。与 [[养虾日记1/2/3/4]] 和 [[养龙虾5天血泪史]] 属同一「养虾日记」系列,从"AI数字导师"新角度扩展了 OpenClaw 的使用场景。与 [[Second Brain]](对话记忆捕获)、[[思维蒸馏(女娲造人术)]] 同属用AI构建外部认知能力的不同路径。
|
||||
|
||||
**Recursive Self-Optimizing Generative Systems**([[a-formalization-of-recursive-self-optimizing-generative-systems]]):递归自我优化生成系统的形式化理论模型——将 [[养虾日记2]] 中 Self-Improving 的实践经验抽象为严格数学框架:系统目标不是直接产出最优输出,而是通过迭代自我修改构建稳定的生成能力 $G^*$。定义生成器空间 $\mathcal{G}$ → 优化算子 $O$ → 元生成算子 $M$ → 自映射 $\Phi$ → 稳定不动点 $G^*$,最终用 λ-calculus Y 组合子表达自引用结构 $G^* \equiv Y\;\text{STEP}$。核心发现:**递归自我优化自然涌现不动点结构**——当 $\Phi$ 满足收缩性条件时,$G^* = \lim_{n \to \infty} \Phi^n(G_0)$。该框架为 [[Self-Improving-Skill]] 和所有自我改进 AI 架构提供了原则性理论基础。
|
||||
|
||||
Key concepts: [[Email Triage]], [[Newsletter Digest]], [[Preference Learning]], [[Cron Job]], [[Multi-Agent Coordination]], [[Multi-Tool Integration]], [[MCP Tool Interface Design]], [[Workflow Architecture]], [[Shared Memory Architecture]], [[Private Context]], [[Single Control Plane]], [[Scheduled Task Flywheel]], [[Parallel Agent Execution]], [[Topic-Based Routing]], [[Voice Interface]], [[Telephony Integration]], [[Voice Notification Channel]], [[Two-Way Voice Conversation]], [[Call-Worthy Threshold]], [[PSTN Calling]], [[PM Delegation Pattern]], [[CEO Pattern]], [[Shared State Coordination]], [[Git-as-Audit-Log]], [[Dynamic-Dashboard]], [[Alerting]], [[Zero-Friction Capture]], [[Cumulative Memory]], [[Conversational Interface]], [[Text-and-Search]], [[Unified-Inbox]], [[Intent-Classification]], [[Human-Handoff]], [[Test-Mode]], [[Business-Knowledge-Base]], [[Language-Detection]], [[AI-Auto-Response]], [[Heartbeat-Monitoring]], [[Self-Improving-Skill]], [[双层记忆架构]], [[每日复盘机制]], [[Pattern-Key]], [[Recurrence-Count]], [[Self-Improvement-Log]], [[AI-Agent思维方式]], [[批次任务拆分]], [[精确去重]], [[小文件清理]], [[安全删除策略]], [[Telegram通知]], [[Context-Window]], [[Model-Fallback]], [[Compaction]], [[Agent-Routing-Rules]], [[Error-Surface-vs-Root-Cause]], [[Layered-Configuration]], [[Log-Driven-Debugging]], [[Hidden-Failure-Paths]]
|
||||
|
||||
### Multi-Agent Monitoring & Automation
|
||||
**Dynamic Dashboard**:基于 [[OpenClaw]] 的多数据源实时监控仪表盘——通过子代理并行抓取 GitHub/Twitter/Polymarket/系统健康等多数据源,定时聚合结果推送 Discord,支持告警阈值和历史趋势存储。用对话式指令替代数周前端开发,立即获得实时洞察。[[polymarket-autopilot]] 是 Polymarket 市场监控的具体实现——AI Agent 24/7 自动监控预测市场、分析概率变化、自动执行交易策略。与 [[self-healing-home-server]] 的系统监控场景关联,[[earnings-tracker]] 的市场数据监控场景扩展,[[content-factory]] 共享子代理并行执行模式。
|
||||
@@ -51,6 +63,8 @@ A practical tip for extracting YouTube Channel IDs: use `view-source:` prefix in
|
||||
|
||||
**X/Twitter Automation**: [[x-twitter-automation]] 是基于 [[OpenClaw]] 的 X/Twitter 全功能自动化方案——通过 TweetClaw 插件(`@xquik/tweetclaw`)连接 X/Twitter 托管 API,实现自然语言驱动的发帖、回复、点赞、转发、关注、DM、搜索、数据提取、抽奖选人和账号监控。支持可配置的抽奖筛选条件(最低粉丝数/账号年龄/关键词),账号监控可追踪指定用户的新推文或粉丝变化并推送通知。所有操作通过托管 API 完成,无 Cookie、无爬虫、无凭证暴露。与 [[x-account-analysis]] 互补(分析 vs 操作),可与 [[content-factory]] 配合扩展社交媒体内容发布能力。
|
||||
|
||||
**[[x-account-analysis]]**:基于 [[OpenClaw]] + [[Bird Skill]] 的 X 账号定性分析方案——通过 Cookie 认证(auth-token / ct0)读取真实账号推文,AI 深入分析内容模式(为何有时 1000+ 赞有时 <5 赞)、话题偏好与互动差异原因。定性分析聚焦"质量"而非"数字",揭示帖子病毒式传播的规律。免费替代 $10-$50/月 的第三方订阅分析服务。核心安全建议:为 OpenClaw 单独创建 [[ClawdBot]] 专用账号而非直接使用真实账号。与 [[x-twitter-automation]] 互补——前者侧重内容质量分析,后者侧重账号操作自动化。
|
||||
|
||||
Key concepts: [[Channel ID]], [[RSS Feed]], [[X/Twitter-API-Automation]], [[Social-Media-Giveaway]], [[Account-Monitoring]], [[Daily-Digest]], [[Transcript-Based Summarization]], [[TranscriptAPI.com]], [[Chained Agents]], [[Content Automation]], [[Semantic-Deduplication]], [[Vector-Embedding]], [[Knowledge-Base-RAG]], [[arXiv-API]], [[LaTeX-扁平化]], [[本地缓存]], [[论文摘要批量获取]]
|
||||
|
||||
### n8n Workflow Automation
|
||||
@@ -80,6 +94,10 @@ Key concepts: [[国家中小学智慧教育平台]], [[tchMaterial-parser]], [[C
|
||||
### AI Tools & Prompt Engineering
|
||||
Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP via `npx claude-code-templates@latest --skill=<path> --yes` from aitmpl.com), OpenCode, [[Cursor]], [[Trae]], Gemini CLI, Vibe Coding, RAG, multi-agent workflows, NotebookLM, Nano Banana prompting, and video generation tools.
|
||||
|
||||
**[[AI图生视频工具盘点]]**:基于 [[14个免费的AI图生视频工具-用ai让图片动起来]] 的综合分析,介绍了14个免费AI图生视频工具,覆盖阿里巴巴(绘蛙、通义万相、万相营造)、字节跳动(即梦AI)、快手(可灵AI)、智谱AI(智谱清影)、MiniMax(海螺AI)、生数科技(Vidu)、爱诗科技(PixVerse)、潞晨科技(Video Ocean)、智象未来(Viva)、MewXAI(艺映AI)、Stability AI(Stable Video)等厂商。核心能力包括:文本提示词控制运动、动作模板选择、运镜参数调节、首尾帧精准控制、主体一致性保持、音效自动生成等。电商场景(模特图动态化、商品展示)、视频创作(创意短片)、广告制作是三大主要应用方向。与 [[文字生成视频网站推荐]] 属同类AI视频生成工具的不同角度——前者侧重点图生视频,后者侧重文生视频。
|
||||
|
||||
**NotebookLM 开源平替生态**:基于 [[google-神级生产力工具-所有-github-开源平替都找到了]] 的系统梳理,Google [[NotebookLM]] 作为 AI 笔记助手标杆,支持文档问答和播客生成两大核心能力,GitHub 上已形成完整的开源替代生态:[[OpenNotebook]](14.6k Stars,全功能本地化,支持 16+ AI 提供商和本地模型)是 Star 最高的平替;[[SurfSense]](11.4k Stars)定位为 NotebookLM + Perplexity + Glean 的综合替代,支持语义+全文混合搜索和团队 RBAC;[[Podcastfy]] 专注播客生成,整合 100+ LLM 和多种 TTS 引擎;[[NotebookLlama]](LlamaIndex 官方项目)展示文档转播客的完整技术链条;[[PageLM]] 聚焦教育场景,提供康奈尔笔记和间隔重复闪卡;[[InsightsLM]] 采用 Supabase + N8N 低代码架构,支持完全离线部署。该生态覆盖从"全功能替代"到"垂直聚焦"的不同需求层次。与 [[Personal Knowledge Base (RAG)]](文档检索知识库)同属 AI 驱动的知识管理工具,但 NotebookLM 生态侧重"文档→对话/音频"的交互形态。
|
||||
|
||||
**[[custom-morning-brief]]**:基于 [[OpenClaw]] 的晨间简报自动化——每天定时(例 8AM)通过 Telegram/Discord/iMessage 推送结构化报告,内容涵盖:新闻研究(AI/创业/科技方向)、当日待办事项(集成 Todoist/Apple Reminders/Asana)、主动任务推荐(AI 自主思考可帮助完成的事项)、睡前完成的完整草稿(脚本/邮件/商业方案,而非仅标题)。核心洞察:**主动任务推荐**是整个系统最有价值的部分——AI 主动思考如何帮助用户,而非被动等待指令;完整草稿(full draft)比标题建议节省大量时间;用户只需发消息即可调整简报内容,无门槛个性化。与 [[self-healing-home-server]] 的 Morning Briefing 属同一模式的不同垂直场景。
|
||||
|
||||
**[[family-calendar-household-assistant]]**:基于 [[OpenClaw]] 的家庭日程协调与物资管理方案——聚合 5+ 个分散日历(工作/个人/家庭/学校/课外)生成每日晨间简报;通过环境消息监控(Ambient Message Monitoring)自动从 iMessage 中识别预约并创建日历事件(含行车时间缓冲);维护家庭库存 JSON(冰箱/储藏室),支持照片 OCR 和小票识别更新;生成购物清单。核心洞察:**Ambient > Active**——Agent 在不被要求时主动行动才是最大突破;Mac Mini 是该场景的最优硬件(iMessage 集成 + 始终在线)。与 [[Custom Morning Brief]] 属同一晨间简报模式的不同场景(个人 vs 家庭)。
|
||||
@@ -104,6 +122,8 @@ Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP vi
|
||||
|
||||
**Claude Code 调用方法**:[[claude-code调用方法总结]] 详细记录了 Hermes Agent 通过 `terminal` 工具调用 Claude Code 的两种模式——Print Mode(`claude -p`,适合绝大多数任务)和 TMUX 交互模式(适合超长任务)。核心参数包括 `--permission-mode bypassPermissions`(跳过所有权限确认)和 `--add-dir`(加载 SKILL.md)。关键结论:当任务需要 Claude Code 的 Skill 时,应使用 `terminal` 调用 `claude -p` 而非 `delegate_task`。
|
||||
|
||||
**[[autonomous-game-dev-pipeline]]**:基于 [[OpenClaw]] 的 AI Agent 全自动教育游戏开发流水线——每小时轮询队列产出 1 款儿童 HTML5 游戏,通过 "Bugs First" 优先策略(先修 bug 再做新功能)、Round Robin 年龄组均衡分配、纯 HTML5/CSS3/JS 无框架技术栈,实现单人维护 41+ 款游戏。核心工程纪律:同步 master → feature branch → conventional commits → PR merge,每次交付自动更新 CHANGELOG 和队列状态。核心价值:**每 7 分钟产出 1 款游戏或 1 个 bugfix**,单人可管理完整产品线。与 [[content-factory]] 同属 Agent 自动化内容生产,但前者侧重多 Agent 协作链,本方案侧重单人 Agent 的高纪律性流水线。
|
||||
|
||||
**[[aionui-cowork-desktop]]**:基于 [[AionUi]] 的 OpenClaw 桌面可视化 + 远程救援方案——通过 AionUi 的 Cowork 工作空间,用户可直接看到 OpenClaw 读写文件、运行命令、浏览网页,而非仅终端日志;内置 OpenClaw 部署专家,通过 Telegram/WebUI 远程诊断修复(`openclaw doctor`),解决"OpenClaw 挂了且不在机器旁"的困境;统一 MCP 配置一次,全局同步到 OpenClaw + 12+ 其他 Agent。与 [[Self-Healing-Home-Server]] 的远程修复场景关联,[[Multi-AgentHub]] 共享同一多 Agent 并行管理理念。
|
||||
|
||||
**播客制作自动化**:[[podcast-production-pipeline]] 提供 AI Agent 全自动播客制作流水线,覆盖「录前研究→大纲脚本→录制→时间戳笔记→社媒推广包→SEO描述」全链路。与 [[Content Factory]] 配合可将播客内容复用为博客、Newsletter、视频片段等多格式资产。
|
||||
@@ -114,7 +134,11 @@ Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP vi
|
||||
|
||||
**会议记录自动化**:[[meeting-notes-action-items]] 提供 AI Agent 自动将会议转录文本(Otter.ai、Google Meet、Zoom)转换为结构化摘要,自动从会议中提取行动项并创建 Jira/Linear/Todoist/Notion 任务,同时发送 Slack/Discord 摘要,支持截止日提醒。核心洞察:**自动任务创建**比摘要本身更有价值,无法转化为追踪任务的会议记录只是"文档剧场"。
|
||||
|
||||
Key concepts: [[Morning Briefing]], [[Todoist API]], [[AI-Driven Task Extraction]], [[TaskAutomation]], [[Recurring Tasks]], [[MeetingNotes]], [[ActionItemTracking]], [[TranscriptProcessing]], [[RAG从入门到精通系列]], [[Agent Personality Design]], [[Vibe Coding]], [[Design-to-Code Workflow]], [[Multi-AI Review]], [[CodeWeaver]], [[LLM Wiki]], [[多智能体系统可靠性]], [[Plan Mode]], [[Build Mode]], [[Workspace]], [[AGENTS.md]], [[SOUL.md]], [[USER.md]], [[IDENTITY.md]], [[TOOLS.md]], [[BOOTSTRAP.md]], [[HEARTBEAT.md]], [[MEMORY.md]], [[Agent-Memory]], [[Claude Code Templates]], [[MCP(Model Context Protocol)]], [[Remote-SSH]], [[Bind Mount]], [[Attach 容器]], [[Docker 用户组]], [[SSH Config]], [[SSH 免密登录]], [[Vibe-Kanban]], [[OpenCode]], [[nvm]], [[pm2]], [[单一职责原则]], [[DRY原则]], [[模块化编程]], [[微服务架构]], [[Redis缓存]], [[消息队列]], [[输入-处理-输出模型]], [[并发编程]], [[Pain Point Mining]], [[Startup MVP Pipeline]], [[Agent-Driven Market Research]], [[Last 30 Days Method]], [[Pre-Build Validation]], [[Reality-Signal]], [[Competition-Analysis]], [[Pivot-Strategy]], [[Agent-Build-Gate]], [[CoworkWorkspace]], [[RemoteRescuePattern]], [[Multi-AgentHub]], [[MCPOnceAllAgents]]
|
||||
**Designing for Agentic AI**:[[designing-for-agentic-ai]] 阐述 GenAI(创作内容)vs Agentic AI(主动行动)的核心差异,以及为 Agentic AI 设计用户体验的 TCPCA 五原则——**透明度**(可视化 AI 决策进度与推理摘要)、**控制感**(停止/撤销/偏好设置机制)、**个性化**(基于历史行为预测未来需求)、**对话式交互**(自然语言界面 + 输入解读反馈)、**主动预判**(AI 预判需求并主动提供帮助,同时允许用户控制 AI 自主权级别)。核心洞察:**观察 AI 决策过程本身就是一种参与方式**,用户不再是被动旁观者;设计隐喻从"响应用户点击/滑动"转向"AI 运行时的实时反馈"。与 [[Google-5个-Agent-Skill-设计模式]](ToolWrapper/Generator/Reviewer/Inversion/Pipeline)同属 AI Agent 设计方法论——后者侧重 Skill 架构模式,前者侧重终端用户体验设计。
|
||||
|
||||
**AI 簡報自動化工作流**:用 ChatGPT 先做知識整理,再交給 Canva / Gamma AI 输出演示文稿。两阶段工作流比直接用 AI 生成简报效果更好——ChatGPT 负责深度思考与内容组织,Canva/Gamma AI 负责视觉呈现与排版。核心洞察:让 AI 扮演不同角色(思考者 vs 设计师),充分发挥各工具的优势。与 [[YouTube-Content-Pipeline]] 共享同一"AI 整理 → AI 输出"两阶段模式。与 [[AI图生视频工具盘点]] 同属 AI 内容创作工具应用的不同垂直场景。
|
||||
|
||||
Key concepts: [[AI簡報工作流]], [[AI圖生視頻工具]], [[文字生成視頻]], [[電商場景]], [[AI工具整合]], [[ChatGPT]], [[Canva]], [[Gamma AI]], [[Morning Briefing]], [[Todoist API]], [[AI-Driven Task Extraction]], [[TaskAutomation]], [[Recurring Tasks]], [[MeetingNotes]], [[ActionItemTracking]], [[TranscriptProcessing]], [[RAG从入门到精通系列]], [[Agent Personality Design]], [[Vibe Coding]], [[Design-to-Code Workflow]], [[Multi-AI Review]], [[CodeWeaver]], [[LLM Wiki]], [[多智能体系统可靠性]], [[Plan Mode]], [[Build Mode]], [[Workspace]], [[AGENTS.md]], [[SOUL.md]], [[USER.md]], [[IDENTITY.md]], [[TOOLS.md]], [[BOOTSTRAP.md]], [[HEARTBEAT.md]], [[MEMORY.md]], [[Agent-Memory]], [[Claude Code Templates]], [[MCP(Model Context Protocol)]], [[Remote-SSH]], [[Bind Mount]], [[Attach 容器]], [[Docker 用户组]], [[SSH Config]], [[SSH 免密登录]], [[Vibe-Kanban]], [[OpenCode]], [[nvm]], [[pm2]], [[单一职责原则]], [[DRY原则]], [[模块化编程]], [[微服务架构]], [[Redis缓存]], [[消息队列]], [[输入-处理-输出模型]], [[并发编程]], [[Pain Point Mining]], [[Startup MVP Pipeline]], [[Agent-Driven Market Research]], [[Last 30 Days Method]], [[Pre-Build Validation]], [[Reality-Signal]], [[Competition-Analysis]], [[Pivot-Strategy]], [[Agent-Build-Gate]], [[CoworkWorkspace]], [[RemoteRescuePattern]], [[Multi-AgentHub]], [[MCPOnceAllAgents]]
|
||||
|
||||
### Productivity & Knowledge Management
|
||||
Obsidian plugins, blogwatcher RSS monitoring, Quartz static site generation, project management systems, and personal CRM frameworks. QuickAdd plugin enables quick note capture via hotkeys for rapid idea recording.
|
||||
@@ -149,6 +173,8 @@ Key concepts: [[一人公司]], [[个人品牌]], [[Ikigai框架]], [[天才地
|
||||
- [[agency-agents]] — GitHub repository
|
||||
- [[DracoVibeCoding]] — 公众号"Draco正在VibeCoding"作者,专注 Vibe Coding 与 AI Agent 实战分享
|
||||
- [[OpenClaw]] — multi-agent framework with memory
|
||||
- [[clawr.ing]] — 托管电话服务提供商,消除 Twilio 等传统电话 API 配置复杂度,为 Agent 提供主动拨打电话通知能力,覆盖 100+ 国家 PSTN 电话,不存储录音
|
||||
- [[clawhub.ai]] — OpenClaw Skill 市场,托管 clawr.ing 等 Skill 安装包
|
||||
- [[AionUi]] — 桌面多 Agent Hub(macOS/Windows/Linux),将 OpenClaw 作为可视化 Cowork Agent 运行,支持内置远程救援专家和统一 MCP 配置
|
||||
- [[n8n]] — workflow automation
|
||||
- [[Node.js]] — JavaScript 运行时环境,n8n-mcp 的运行依赖,也是 [[n8n]] 工作流引擎的后端运行环境
|
||||
@@ -301,3 +327,5 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]
|
||||
9. **数据库备份方案**:pg_dump 逻辑备份 vs rsync 文件级备份。pg_dump 是热备份标准(零停机、跨平台迁移能力强),但不能备份运行中数据库的物理文件目录;rsync 适合 Docker 卷备份但需确保数据库一致状态。[[MinIO + Zipline 图床安装]] 使用 pg_dump 逻辑备份 PostgreSQL + Hyper Backup 文件备份 MinIO 目录,两者互补。
|
||||
|
||||
10. **SuperCall 沙盒 Persona vs 通用语音 Agent**:[[event-guest-confirmation]] 中使用的 [[SuperCall]] 强调独立沙盒设计——AI persona 只持有预设的 persona name、goal、opening line,无法访问外部系统;[[phone-based-personal-assistant]] 侧重通用个人助手场景,需要访问更多上下文。**[[Sandboxed Persona]]** 适用于确认类单一任务(安全、无注入风险);通用语音 Agent 适用于需要跨系统协调的复杂助手场景。
|
||||
|
||||
11. **Agent 去电通知 vs Agent 来电接收**:[[phone-call-notifications]] 中 Agent 主动向用户拨打电话通知(Agent → User),通话由 Agent 触发,用户是被动接收方;[[phone-based-personal-assistant]] 中用户主动呼叫 Agent(User → Agent),Agent 接听并提供助理服务。两者方向相反但互补——前者用于紧急告警、定时简报、重要事件通知,后者用于随时咨询、查询、执行任务。共同构成完整语音双向通信能力。
|
||||
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: "14个免费的AI图生视频工具,用AI让图片动起来"
|
||||
type: source
|
||||
tags: [ai, image-to-video, 视频生成]
|
||||
date: 2025-12-05
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[AI/14个免费的AI图生视频工具,用AI让图片动起来 - AI视频教程 AI自动化工作流定制服务 AI培训学习平台 黑喵大叔]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:14个免费AI图生视频工具盘点——用户上传静态图片,AI自动生成动态视频,降低视频创作门槛
|
||||
- 问题域:视频制作需要专业设备、技术和时间投入的痛点;普通创作者如何零门槛制作动态视频内容
|
||||
- 方法/机制:AI图生视频技术——通过上传静态图片,结合可选的文本提示词、运动模板、运镜参数等输入,由AI模型自动分析图像内容并生成连贯的动态视频片段
|
||||
- 结论/价值:2025年免费AI图生视频工具已高度成熟,涵盖中国厂商(阿里巴巴、智谱AI、快手MiniMax、字节跳动等)和国际厂商(Stability AI等),支持电商模特图、视频创作、广告制作等多种场景
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- 14个免费AI图生视频工具覆盖从2秒到6秒的短视频生成,平均生成时间30秒至数分钟
|
||||
- 阿里巴巴(绘蛙、通义万相)、字节跳动(即梦AI)、快手(可灵AI)、智谱AI均已推出免费图生视频功能,国产工具在电商场景深度优化
|
||||
- 图生视频技术已支持多种运动控制方式:文本提示词、动作模板、运镜参数、尾帧参考,运动幅度可调节
|
||||
- 主体一致性(人物/物体在多段视频中保持一致)成为差异化竞争焦点,Vidu和海螺AI在此能力上领先
|
||||
- 部分工具(Viva、海螺AI)支持音效/背景音乐自动生成,实现声画同步的完整视频输出
|
||||
|
||||
## Key Quotes
|
||||
> "只需几张图片,借助AI的力量,轻松生成富有动感和创意的视频作品,实现惊人的创造力和便捷性,为视频创作带来全新的变革与机遇。" — 文章引言
|
||||
> "在当今这个信息爆炸、视觉内容为王的时代,视频已成为人们传递信息、表达创意、娱乐消遣的首选方式之一。" — 文章背景
|
||||
|
||||
## Key Concepts
|
||||
- [[AI图生视频]]:将静态图片通过AI模型自动转化为动态视频的技术,核心任务包括运动估计、时序生成、内容填充
|
||||
- [[主体一致性]]:多段视频中保持人物或物体视觉特征(面部、衣着、颜色)高度一致的技术能力,Vidu的"多主体参考"和海螺AI的"主体参考"均属此类
|
||||
- [[运镜控制]]:通过参数调整视频中摄像机的运动方式(如推进、拉远、倾斜、轨道等),决定视频的视觉动态感
|
||||
- [[首尾帧控制]]:以首帧图片和尾帧图片作为视频生成约束,AI自动填充中间帧,确保视频首尾画面符合预期
|
||||
- [[提示词控制]]:通过自然语言描述控制视频中主体的运动方式和场景变化,实现"所想即所见"
|
||||
|
||||
## Key Entities
|
||||
- [[绘蛙AI视频]]:阿里巴巴集团推出的AI图生视频工具,专注电商模特图动态化,支持动作模板,图片要求600×800以上
|
||||
- [[智谱清影]]:智谱AI推出的视频生成工具,图生视频功能30秒生成6秒1440×960高清视频,自带CogSound音效生成
|
||||
- [[通义万相]]:阿里巴巴AI视频生成工具,支持文本提示词控制运动、任意比例裁剪、旋转和国风内容优化
|
||||
- [[Vidu]]:生数科技联合清华大学发布的中国首个长时长高一致性视频大模型,全球首个"多主体参考"功能
|
||||
- [[可灵AI]]:快手推出的AI图生视频平台,生成1080p高清视频,3D时空联合注意力机制实现逼真物理动作
|
||||
- [[海螺AI]]:MiniMax公司推出的AI视频生成工具,MiniMax视频模型确保形象光影高度一致,支持超出图片内容的文本指令
|
||||
- [[即梦AI]]:字节跳动一站式AI创意创作平台,首尾帧精准控制、运镜参数自定义、多参数组合设置
|
||||
- [[PixVerse]]:爱诗科技开发的AI视频生成工具,支持真实/动漫/3D动画多风格,角色一致性功能
|
||||
- [[Video Ocean]]:潞晨科技AI视频生成平台,指令响应式图片动态化,V2.0在画质和风格多样性上有显著提升
|
||||
- [[Stable Video]]:Stability AI推出的视频生成平台,LoRA精细摄像机控制、帧插值技术、3D场景生成
|
||||
- [[万相营造]]:阿里妈妈AI电商营销工具,高度还原原图、精准理解复杂提示词,专注电商商品视频化
|
||||
- [[Viva]]:智象未来免费AI创意视觉平台,6种运镜方式,运动强度可调节,免费工具中质量最高
|
||||
- [[Haiper]]:AI视频生成工具,支持2秒/4秒视频,1280×720分辨率,官网和Discord无限免费使用
|
||||
- [[艺映AI]]:MewXAI团队推出的AI视频创作工具,运动笔刷局部动态化,支持手机电脑多平台同步
|
||||
|
||||
## Connections
|
||||
- [[Vidu]] ← 技术基础 ← [[清华大学]](联合发布)
|
||||
- [[可灵AI]] ← 所属公司 ← [[快手]](发布方)
|
||||
- [[海螺AI]] ← 所属公司 ← [[MiniMax]](发布方)
|
||||
- [[即梦AI]] ← 所属公司 ← [[字节跳动]](发布方)
|
||||
- [[智谱清影]] ← 所属公司 ← [[智谱AI]](发布方)
|
||||
- [[绘蛙AI视频]] ← 所属公司 ← [[阿里巴巴]](发布方)
|
||||
- [[通义万相]] ← 所属公司 ← [[阿里巴巴]](发布方)
|
||||
- [[万相营造]] ← 所属公司 ← [[阿里巴巴]](发布方)
|
||||
- [[Stable Video]] ← 所属公司 ← [[Stability AI]](发布方)
|
||||
- [[Video Ocean]] ← 所属公司 ← [[潞晨科技]](发布方)
|
||||
- [[PixVerse]] ← 所属公司 ← [[爱诗科技]](发布方)
|
||||
- [[Viva]] ← 所属公司 ← [[智象未来]](发布方)
|
||||
- [[艺映AI]] ← 所属公司 ← [[MewXAI]](发布方)
|
||||
|
||||
## Contradictions
|
||||
- 无明显内容冲突。本文为盘点性质,不同工具的功能描述可互补而非互斥。
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "A Formalization of Recursive Self-Optimizing Generative Systems"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-12-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[AI/A Formalization of Recursive Self-Optimizing Generative Systems.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:递归自我优化的生成系统形式化模型——系统的目标不是直接产出最优输出,而是通过迭代自我修改构建稳定的生成能力
|
||||
- 问题域:自动提示工程、元学习、自我改进 AI 系统的理论基础——计算对象从"解"转变为"解的生成器"
|
||||
- 方法/机制:定义生成器空间 $\mathcal{G}$ → 优化算子 $O$ → 元生成算子 $M$ → 自映射 $\Phi$ → 不动点 $G^*$ → λ-calculus Y组合子表达
|
||||
- 结论/价值:递归自我优化系统自然涌现不动点结构,而非终止输出;稳定生成能力 = 元生成算子的不动点
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- 生成器(Generator)作为计算对象优于单个输出:系统优化的是"生成解决方案的机制",而非单个解决方案
|
||||
- 稳定生成能力 = 自映射 $\Phi$ 的不动点 $G^*$:即在自身的"生成-优化-更新"循环下保持不变的生成器
|
||||
- 不动点可通过迭代收敛获得:当 $\Phi$ 满足连续性或收缩性条件时,$G^* = \lim_{n \to \infty} \Phi^n(G_0)$
|
||||
- 自引用结构可形式化为 λ-calculus 的 Y 组合子:$G^* \equiv Y\;\text{STEP}$ 满足 $G^* = \text{STEP}\;G^*$
|
||||
- 该框架为自我改进 AI 架构和自动化元提示系统提供了原则性理论依据
|
||||
|
||||
## Key Quotes
|
||||
> "We study a class of recursive self-optimizing generative systems whose objective is not the direct production of optimal outputs, but the construction of a stable generative capability through iterative self-modification." — 论文 Abstract,核心研究动机
|
||||
|
||||
> "A stable generative capability is defined as a fixed point of $\Phi$: $G^{*} \in \mathcal{G},\ \Phi(G^{*}) = G^{*}$." — 论文 Section 2,稳定生成能力的数学定义
|
||||
|
||||
> "The analysis reveals that such systems naturally instantiate a bootstrapping meta-generative process governed by fixed-point semantics." — 论文 Abstract,核心发现
|
||||
|
||||
## Key Concepts
|
||||
- [[Recursive Self-Optimization]]:通过迭代自我修改构建稳定生成能力的递归优化框架
|
||||
- [[Generator Space]]:生成器空间 $\mathcal{G} \subseteq \mathcal{P}^{\mathcal{I}}$,每个生成器是从意图空间到程序/提示空间的函数
|
||||
- [[Self-Referential Computation]]:生成器被定义为使用自身输出的函数的不动点,体现自引用计算本质
|
||||
- [[Fixed-Point Semantics]]:自映射 $\Phi$ 的不动点语义——系统在不终止输出的情况下实现收敛
|
||||
- [[Y-Combinator]]:λ-calculus 不动点组合子,用于表达自引用生成器的递归结构
|
||||
|
||||
## Key Entities
|
||||
- [[tukuai]]:独立研究者,GitHub @tukuai,本文理论框架的提出者
|
||||
|
||||
## Connections
|
||||
- [[Recursive Self-Optimization]] ← is_theoretical_basis_for ← [[Meta-Learning]]
|
||||
- [[Generator Space]] ← uses_mathematical_framework ← [[Self-Referential Computation]]
|
||||
- [[Fixed-Point Semantics]] ← formalizes ← [[Recursive Self-Optimization]]
|
||||
- [[Y-Combinator]] ← implements ← [[Self-Referential Computation]]
|
||||
- [[Self-Improving AI]] ← is_applied_domain ← [[Recursive Self-Optimization]]
|
||||
- [[Automated Prompt Engineering]] ← is_applied_domain ← [[Recursive Self-Optimization]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无发现与其他 Wiki 页面的内容冲突——本文为纯理论形式化,与 Wiki 中其他 Agent 应用案例属不同层次)
|
||||
56
wiki/sources/autonomous-game-dev-pipeline.md
Normal file
56
wiki/sources/autonomous-game-dev-pipeline.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "Autonomous Educational Game Development Pipeline"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-23
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/autonomous-game-dev-pipeline.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:AI Agent 全自动管理教育游戏的完整开发生命周期
|
||||
- 问题域:单人开发者如何在无团队情况下快速生产 40+ 款儿童教育游戏
|
||||
- 方法/机制:
|
||||
- "Bugs First" 优先策略:Agent 必须先修复 bugs 文件夹中的第一个 bug,再处理新游戏
|
||||
- Round Robin 轮询策略:从队列中按年龄组均衡选取下一款游戏
|
||||
- 完整 Git 工作流:feature branch → conventional commits → PR → merge
|
||||
- 技术栈:纯 HTML5/CSS3/JS,无框架,移动优先,支持离线
|
||||
- 结论/价值:**每 7 分钟产出 1 款游戏或 1 个 bugfix**,单人可维护 41+ 款游戏的知识库
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- Agent 在检测到 bugs/ 文件夹有内容时,必须优先修复字母序第一个 bug,不能同时处理多个 bug
|
||||
- Pipeline 效率达到每 7 分钟完成 1 个新游戏或 1 个 bugfix
|
||||
- 游戏需注册到 `games-list.json` 才能在首页显示,这是关键集成步骤
|
||||
- 使用 conventional commits 规范(feat: add [game-id])确保提交历史可读
|
||||
- 系统指令使用西班牙语(es-419)编写,适配拉丁美洲儿童及其潜在贡献者
|
||||
|
||||
## Key Quotes
|
||||
> "Act as an Expert in Web Game Development and Child UX. Your goal is to develop the next game in the production queue." — Agent 系统指令核心
|
||||
> "BUGS FIRST!: If the bugs/ folder has content, your only priority is to fix the first bug in alphabetical order. Do not attempt to fix multiple bugs at once." — 关键工程纪律
|
||||
> "Register the game in 'games-list.json' (CRITICAL)" — 核心集成步骤
|
||||
> "CRITICAL: git fetch && git pull origin master before starting" — 同步纪律
|
||||
|
||||
## Key Concepts
|
||||
- [[Bugs First]]:优先级策略——Agent 检测到 bug 时必须停止新功能开发,先修 bug,且一次只修一个
|
||||
- [[Round Robin Strategy]]:轮询策略——按年龄组均衡分配,平衡内容多样性
|
||||
- [[Conventional Commits]]:规范化提交格式(如 `feat: add game-id`),保证项目历史可读
|
||||
- [[Feature Branch Workflow]]:Git feature branch → commit → PR → merge 的完整分支管理流程
|
||||
- [[HTML5 Game Development]]:无框架、移动优先、离线可用的轻量游戏开发规范
|
||||
|
||||
## Key Entities
|
||||
- [[duberblockito]]:El Bebe Games 项目作者,GitHub 仓库维护者,"LANero of the old school" 爸爸开发者
|
||||
- [[El Bebe Games]]:面向拉丁美洲儿童的在线教育游戏平台,无广告、无垃圾信息,官网 elbebe.co
|
||||
- [[Susana & Julieta]]:开发者女儿(3岁和即将出生),项目的灵感来源和目标用户
|
||||
- [[OpenClaw]]:(关联)本 pipeline 与 OpenClaw 的 autonomous agent 能力相关,是该技术的实际应用场景
|
||||
|
||||
## Connections
|
||||
- [[Multi-Agent Content Factory]] ← related_to ← [[autonomous-game-dev-pipeline]]
|
||||
- 两者均涉及 Agent 自动化生产内容,但前者侧重多 Agent 协作链(Research → Writing → Design),后者侧重单人 Agent 的独立流水线
|
||||
- [[Goal-Driven Autonomous Tasks]] ← extends ← [[autonomous-game-dev-pipeline]]
|
||||
- Overnight Mini-App Builder 同样采用 Agent 自主执行 + Git 状态追踪的工程纪律,是本 pipeline 方法论的延伸
|
||||
- [[Project State Management]] ← related_to ← [[autonomous-game-dev-pipeline]]
|
||||
- 两者都使用 append-only 日志模式(CHANGELOG.md / master-game-plan.md)作为状态管理机制
|
||||
|
||||
## Contradictions
|
||||
- 无明显内容冲突
|
||||
48
wiki/sources/designing-for-agentic-ai.md
Normal file
48
wiki/sources/designing-for-agentic-ai.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "Designing for Agentic AI"
|
||||
type: source
|
||||
tags: [AI, Agentic AI, Product Design, UX Design]
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[AI/Designing for Agentic AI]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:Agentic AI(智能体AI)与 GenAI(生成式AI)的区别,以及如何为 Agentic AI 设计用户体验
|
||||
- 问题域:传统 UI 设计范式(响应用户直接输入)无法满足 Agentic AI 的主动式、反馈驱动型交互需求
|
||||
- 方法/机制:提出 5 条最佳实践设计原则:透明度(Transparency)、控制感(Control)、个性化(Personalization)、对话式交互(Conversation)、主动预判(Anticipation)
|
||||
- 结论/价值:设计 Agentic AI 体验需要全新的设计隐喻,从"响应用户操作"转向"提供实时反馈",让用户始终理解 AI 正在做什么并保持控制权
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- GenAI 擅长创作新内容(文本/图片/音乐),Agentic AI 擅长行动——与环境交互、做决策、预判需求
|
||||
- Agentic AI 使用户不再是被动参与者:观察 AI 决策过程、理解 AI"思考"本身就是一种交互形式
|
||||
- 设计 Agentic AI 需要新隐喻:不仅是响应用户点击/滑动,而是 AI 运行时提供实时反馈
|
||||
- 5 条最佳实践原则(TCPCA):透明度、控制感、个性化、对话、主动预判
|
||||
|
||||
## Key Quotes
|
||||
> "Agentic AI is pushing us to reimagine product design. For years, we've focused on interfaces that react to direct user input—clicks, swipes, and edits. But agentic AI introduces a new dimension: proactive agents that anticipate needs and act autonomously."
|
||||
> — Yuri Pessa,阐述从响应式 UI 到主动式 Agent UI 的设计范式转变
|
||||
|
||||
> "This doesn't mean users become passive. Observing the AI's decision-making process, understanding its 'thinking,' is a form of interaction in itself."
|
||||
> — Yuri Pessa,用户观察 AI 决策过程本身就是参与方式
|
||||
|
||||
## Key Concepts
|
||||
- [[Agentic AI]]:能够与环境交互、做决策、预判用户需求的主动式 AI 系统,而非被动响应用户指令
|
||||
- [[GenAI]]:生成式 AI,擅长创作新内容(文本/图片/音乐),与 Agentic AI 的行动导向形成对比
|
||||
- [[Transparency]]:透明度原则——用户应能理解 AI 如何做决策,通过可视化 AI 进度和推理过程摘要实现
|
||||
- [[Control]]:控制感原则——用户始终应感到掌控 AI,通过停止/撤销/偏好设置等机制实现
|
||||
- [[Personalization]]:个性化原则——Agentic AI 应适应个人用户需求和偏好,基于历史行为预测未来需求
|
||||
- [[Conversation]]:对话原则——通过自然语言界面设计与 AI 交互,并提供 AI 如何解读输入的反馈
|
||||
- [[Anticipation]]:主动预判原则——Agentic AI 应能预判用户需求并主动提供帮助,同时允许用户控制 AI 自主权级别
|
||||
|
||||
## Key Entities
|
||||
- [[Yuri Pessa]]:LinkedIn 文章作者,专注于 AI 产品设计领域
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← 核心概念 ← [[Designing-for-Agentic-AI]](本文档)
|
||||
- [[Designing-for-Agentic-AI]] ← 应用场景 ← [[Google-5个-Agent-Skill-设计模式]](Skill 设计模式中的设计原则)
|
||||
- [[Designing-for-Agentic-AI]] ← 对比参照 ← [[llms-rag-ai-agent-三个到底什么区别]](LLM vs RAG vs AI Agent 的概念辨析)
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知冲突
|
||||
65
wiki/sources/google-神级生产力工具-所有-github-开源平替都找到了.md
Normal file
65
wiki/sources/google-神级生产力工具-所有-github-开源平替都找到了.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: "Google 神级生产力工具,所有 GitHub 开源平替都找到了。"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-01-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[AI/Google 神级生产力工具,所有 GitHub 开源平替都找到了。.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:Google NotebookLM 的 GitHub 开源替代品生态全景盘点
|
||||
- 问题域:AI 笔记助手、文档问答、播客生成工具的选择与本地化部署
|
||||
- 方法/机制:系统梳理 6 款开源项目(Open Notebook、SurfSense、Podcastfy、NotebookLlama、PageLM、InsightsLM),从功能完整性、模型支持、部署方式、差异化特性等维度对比分析
|
||||
- 结论/价值:开源平替覆盖从"全功能替代"到"垂直聚焦"的不同需求层次,用户可根据隐私需求、预算、技术能力选择最适合的工具
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- Open Notebook 是 GitHub 上 Star 最高的 NotebookLM 开源平替(14.6k Stars),支持 16+ AI 提供商、本地模型、多模态输入和多角色播客生成
|
||||
- SurfSense(11.4k Stars)是综合型 AI 搜索与研究智能体,整合语义搜索+全文搜索+重排序,支持 Notion/GitHub/YouTube 等外部数据源,具备团队协作 RBAC
|
||||
- Podcastfy 专注播客生成,整合 100+ LLM 和多种 TTS 引擎,支持多语言和短视频/长篇双模式
|
||||
- NotebookLlama(LlamaIndex 官方项目)展示如何利用 AI 技术链条构建文档转播客应用
|
||||
- PageLM 专注于教育场景,提供康奈尔笔记、互动测验、间隔重复闪卡和模拟考试系统
|
||||
- InsightsLM 强调低代码/无代码,采用 Supabase + N8N 架构,支持完全离线本地部署
|
||||
|
||||
## Key Quotes
|
||||
> "NotebookLM 是谷歌推出的一款 AI 笔记助手。与普通 AI 不一样,它严格限制在你上传的文档范围里进行回答,并能提供精准的原文引用。" — NotebookLM 的核心价值定位
|
||||
> "Open Notebook 支持超过 16 种 AI 提供商,包括 OpenAI、Anthropic、Gemini 等主流云端模型,同时也完美支持通过 Ollama 或 LM Studio 运行的本地模型。" — 模型选择灵活性
|
||||
> "SurfSense 采用语义搜索 + 全文搜索混合搜索技术,并结合重排序算法,确保在海量数据中能快速精准地找到并引用答案。" — 搜索技术栈
|
||||
> "Podcastfy 整合了超过 100 种 LLM 用于脚本生成,并支持 OpenAI、Google、ElevenLabs 以及 Microsoft Edge TTS 等多种语音合成引擎。" — 播客生成引擎
|
||||
|
||||
## Key Concepts
|
||||
- [[文档问答]]:基于上传文档进行 AI 问答,并提供精准原文引用
|
||||
- [[播客生成]]:将文本/文档内容转换为逼真的双人/多人英语对话播客
|
||||
- [[语义搜索]]:结合向量相似度与全文关键词匹配,提升检索精度
|
||||
- [[混合搜索]]:语义搜索 + BM25 全文搜索 + RRF 重排序的组合检索技术
|
||||
- [[多模态输入]]:支持 PDF、网页、音频、YouTube 视频等多种格式的文档输入
|
||||
- [[本地化部署]]:不依赖云端,通过 Docker 等方式在本地运行 AI 应用
|
||||
- [[RBAC]](基于角色的访问控制):支持团队协作和知识共享的权限管理机制
|
||||
|
||||
## Key Entities
|
||||
- [[NotebookLM]]:Google 推出的 AI 笔记助手,核心标杆产品,支持文档问答和播客生成
|
||||
- [[OpenNotebook]]:GitHub Star 最高的开源平替(14.6k),全功能本地化方案,支持多 AI 提供商
|
||||
- [[SurfSense]]:综合型 AI 搜索与研究智能体(11.4k Stars),定位为 NotebookLM/Perplexity/Glean 的开源替代
|
||||
- [[Podcastfy]]:专注播客生成的开源工具,整合 100+ LLM 和多种 TTS 引擎
|
||||
- [[NotebookLlama]]:LlamaIndex 官方开源项目,展示文档转播客的完整技术链条
|
||||
- [[PageLM]]:教育场景垂直工具,提供康奈尔笔记、互动测验、间隔重复闪卡、模拟考试
|
||||
- [[InsightsLM]]:低代码/无代码方案,Supabase + N8N 架构,支持 Ollama/Qwen3 本地模型
|
||||
- [[Google]]:NotebookLM 开发商,AI 生产力工具领域的重要推动者
|
||||
- [[LlamaIndex]]:NotebookLlama 的背后组织,开源 LLM 应用开发框架
|
||||
- [[Supabase]]:InsightsLM 的后端数据库和存储提供商
|
||||
- [[N8N]]:InsightsLM 的工作流自动化工具后端
|
||||
- [[Ollama]]:本地模型运行平台,多个开源平替均支持
|
||||
- [[ElevenLabs]]:高质量语音合成引擎,Podcastfy 和 NotebookLlama 均支持
|
||||
|
||||
## Connections
|
||||
- [[OpenNotebook]] ← 功能对标 ← [[NotebookLM]]
|
||||
- [[SurfSense]] ← 定位重叠 ← [[NotebookLM]]、[[Perplexity]]、[[Glean]]
|
||||
- [[Podcastfy]] ← 功能聚焦 ← [[NotebookLM]](播客生成子功能)
|
||||
- [[NotebookLlama]] ← 技术参考 ← [[NotebookLM]](文档转播客流程)
|
||||
- [[PageLM]] ← 场景扩展 ← [[NotebookLM]](教育垂直领域)
|
||||
- [[InsightsLM]] ← 架构借鉴 ← [[NotebookLM]](文档问答+播客生成核心)
|
||||
- [[OpenNotebook]] ← 技术集成 ← [[Ollama]]、[[LM-Studio]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知内容冲突
|
||||
61
wiki/sources/phone-call-notifications.md
Normal file
61
wiki/sources/phone-call-notifications.md
Normal file
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "Phone Call Notifications"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/phone-call-notifications.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:AI Agent 通过真实电话呼叫(而非推送通知)向用户发送紧急提醒,实现 Agent → 用户双向语音通话
|
||||
- 问题域:推送通知容易被忽视,聊天消息容易被埋没,紧急信息无法可靠触达用户
|
||||
- 方法/机制:通过 clawr.ing 托管电话服务(无需 Twilio/API Key 配置),Agent 评估事件优先级,决定是否值得打电话,主动拨叫用户真实号码;通话中用户可实时提问,Agent 实时响应,实现真正的双向对话
|
||||
- 结论/价值:电话是唯一可靠绕过注意力屏障的触达方式;Agent 主动判断"是否值得打电话"而非被动响应;clawr.ing 消除电话集成的技术门槛
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- Agent 主动拨叫用户,而非用户呼叫 Agent——这是注意力触达效率的关键差异
|
||||
- clawr.ing 消除了电话 API 配置门槛,一段 setup prompt 即完成集成,覆盖 100+ 国家真实 PSTN 电话
|
||||
- 电话通知需与 Heartbeat/Cron Job 配合作为触发器,clawr.ing 本身仅是投递通道
|
||||
- 通话场景下应使用快速模型(Haiku 级别)以降低延迟
|
||||
- clawr.ing 不存储录音或文字记录,音频传输加密后即时销毁
|
||||
|
||||
## Key Quotes
|
||||
> "Phone call means 'this actually matters.' If your agent calls you 10 times a day, you'll start ignoring it."
|
||||
> — 核心设计原则:控制电话通知频率,保持其作为最高优先级触达通道的价值
|
||||
|
||||
> "Unlike a push notification, you can ask follow-up questions on the call."
|
||||
> — 双向对话是电话通知区别于所有其他通知渠道的本质差异
|
||||
|
||||
## Key Concepts
|
||||
- [[Voice Notification Channel]]:Agent 通过主动拨打电话作为高优先级通知投递通道,与推送通知/聊天消息并列
|
||||
- [[Two-Way Voice Conversation]]:Agent 主动拨叫用户,用户可实时提问,Agent 实时响应,而非单向广播
|
||||
- [[Call-Worthy Threshold]]:仅当事件足够重要时才触发电话,避免通知疲劳
|
||||
- [[PSTN Calling]]:真实公共交换电话网电话(非 VoIP 叠加层),确保全球覆盖和可靠接通
|
||||
|
||||
## Key Entities
|
||||
- [[clawr.ing]]:托管电话服务提供商,消除了 Twilio 等传统电话 API 的配置复杂度,为 Agent 提供一键电话呼叫能力
|
||||
- [[OpenClaw]]:Agent 框架,通过 clawr.ing skill 实现主动电话通知功能
|
||||
- [[clawhub.ai]]:OpenClaw Skill 市场,托管 clawr.ing skill 安装包
|
||||
|
||||
## Connections
|
||||
- [[Phone-Based-Personal-Assistant]] ← extends ← [[phone-call-notifications]]
|
||||
- Phone-Based Personal Assistant 侧重 Agent 接收用户来电并进行语音交互(用户 → Agent)
|
||||
- Phone Call Notifications 侧重 Agent 主动向外拨叫通知用户(Agent → 用户)
|
||||
- 两者互为补充,构成完整的语音双向通信能力
|
||||
- [[multi-channel-assistant]] ← shares_channel ← [[phone-call-notifications]]
|
||||
- 同属 OpenClaw 多渠道个人助理体系,但 Phone Call Notifications 补充了最高优先级的语音触达通道
|
||||
- [[Custom Morning Brief]] ← delivery_channel ← [[phone-call-notifications]]
|
||||
- 晨间简报可通过电话通道投递,实现"每天 7:30 准时来电"场景
|
||||
- [[Self-Healing-Home-Server]] ← delivery_channel ← [[phone-call-notifications]]
|
||||
- 家庭服务器关键告警可通过电话第一时间触达用户
|
||||
- [[earnings-tracker]] ← delivery_channel ← [[phone-call-notifications]]
|
||||
- 股价暴跌等紧急事件可通过电话立即通知
|
||||
|
||||
## Contradictions
|
||||
- 与 [[phone-based-personal-assistant]] 存在方向差异:
|
||||
- 冲突点:谁来发起通话
|
||||
- 当前观点(phone-call-notifications):Agent 主动拨叫用户,拨叫门槛高(仅紧急事件)
|
||||
- 对方观点(phone-based-personal-assistant):用户主动呼叫 Agent,Agent 接听并提供助理服务
|
||||
- 协调说明:两者不冲突——前者用于紧急通知(Agent → 用户),后者用于主动查询(用户 → Agent),共同构成双向语音通信体系
|
||||
42
wiki/sources/x-account-analysis.md
Normal file
42
wiki/sources/x-account-analysis.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "X Account Analysis"
|
||||
type: source
|
||||
tags: ["openclaw", "social-media", "analytics", "x-twitter"]
|
||||
date: 2026-04-23
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/usecases/x-account-analysis]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:X(Twitter)账号定性分析——超越数字指标,洞悉内容质量
|
||||
- 问题域:现有 X 分析工具(X Analytics / 第三方订阅服务)只展示统计数据,无法回答"为什么"的问题
|
||||
- 方法/机制:OpenClaw + Bird Skill,通过 Cookie 认证(auth-token / ct0)读取真实账号推文,AI 定性分析内容模式、话题偏好与互动差异原因
|
||||
- 结论/价值:免费替代 $10-$50/月 订阅服务,自然语言问答式交互,无需专用 App
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- OpenClaw + Bird Skill 可对 X 账号进行定性分析,揭示使帖子病毒式传播的模式
|
||||
- AI 能回答"为何有时帖子 1000+ 赞,有时 <5 赞"——分析内容质量而非数字
|
||||
- Bird Skill 预装在 OpenClaw 中(`clawhub install bird`)
|
||||
- 为安全隔离建议创建专用 ClawdBot 账号,而非直接使用真实账号
|
||||
|
||||
## Key Quotes
|
||||
> "There are many websites designed to give you X analytics, but they focus on the statistics. There are probably 1-2 websites that let you talk with an AI to understand your performance." — 现有分析工具痛点
|
||||
> "Now you can use OpenClaw to do this analysis for you, without needing to pay $10-$50 for subscriptions on these websites." — OpenClaw 免费替代方案
|
||||
|
||||
## Key Concepts
|
||||
- [[X/Twitter-API-Automation]]:通过 Cookie 认证实现 API 访问
|
||||
- [[Social-Media-Analytics]]:定性分析 vs 定量分析
|
||||
- [[Credential-Isolation]]:为机器人创建独立账号实现安全隔离
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]:多 Agent 框架,提供记忆持久化和 Skill 扩展能力
|
||||
- [[Bird Skill]]:OpenClaw X/Twitter 操作 Skill,预装或通过 `clawhub install bird` 安装
|
||||
- [[ClawdBot]]:OpenClaw 的机器人实例,建议创建独立账号用于 X 操作
|
||||
|
||||
## Connections
|
||||
- [[x-twitter-automation]] ← extends ← [[x-account-analysis]](操作 vs 分析,互补关系)
|
||||
- [[content-factory]] ← can_use ← [[x-account-analysis]](社交媒体内容策略分析)
|
||||
|
||||
## Contradictions
|
||||
无已知冲突
|
||||
@@ -41,4 +41,4 @@ date: 2026-04-17
|
||||
- [[n8n-workflow-orchestration]] ← complementary ← [[x-twitter-automation]](n8n Webhook 模式可作为 TweetClaw API 的安全凭证托管层)
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突。与 [[x-account-analysis]](尚未摄入)互补——分析 vs 操作,共同构成 X/Twitter 场景的完整能力覆盖
|
||||
- 无已知冲突。与 [[x-account-analysis]] 互补——分析 vs 操作,共同构成 X/Twitter 场景的完整能力覆盖
|
||||
|
||||
46
wiki/sources/不谈技术-普通人该怎么在ai时代赚钱.md
Normal file
46
wiki/sources/不谈技术-普通人该怎么在ai时代赚钱.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: "不谈技术:普通人该怎么在AI时代赚钱?"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-23
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[微信公众号/不谈技术:普通人该怎么 在AI时代赚钱?]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:AI时代普通人如何赚钱的思维框架,核心观点是"AI不会让普通人变富,但会让有品味、知道自己要做什么的人变得极其强大"
|
||||
- 问题域:普通人在AI浪潮中的自我定位与生存策略
|
||||
- 方法/机制:三大思维原则——品味值钱、做端到端的事、用死亡过滤器
|
||||
- 结论/价值:转变问题框架,从"怎么不被AI淘汰"到"AI能帮我做什么以前做不到的事"
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- AI让工具民主化,但品味没有民主化——90%的人用AI生成的东西是shit,因为他们不知道什么是好的
|
||||
- 做端到端的事(做一个完整的产品/服务),远比在一个AI流水线里当"螺丝钉"更有价值且更抗替代
|
||||
- 用死亡过滤器追问:对什么有genuine的热爱和curiosity?把那一件事做到insanely great
|
||||
- "普通人"和"不普通的人"的区别不在天赋/资源/运气,而在于愿不愿意对一千件事说No,只对一件事说Yes
|
||||
- AI不会让普通人变富;AI会让那些知道自己要做什么、并且对品质有执念的人变得极其强大
|
||||
|
||||
## Key Quotes
|
||||
> "正确的问题是:AI让我能做到什么以前做不到的事?" — 重新框架问题本身
|
||||
> "工具民主化了,但品味没有民主化。" — 为什么90%的AI输出是shit
|
||||
> "一个人用AI做出一个完整的App,比一个100人的团队里当'AI提示词工程师'强一万倍。" — 端到端的价值
|
||||
> "他们愿不愿意对一千件事说No,只对一件事说Yes,然后把那一件事做到insanely great。" — 普通与不普通的分水岭
|
||||
|
||||
## Key Concepts
|
||||
- [[品味(审美)]]: 判断AI方案中哪个是insanely great的能力,是AI时代真正的护城河
|
||||
- [[端到端(End-to-End)]]: 从头到尾做一个完整的产品/服务/解决方案,而非成为AI流水线上的零件
|
||||
- [[死亡过滤器(Death Filter)]]: 每天早上问自己"如果今天是最后一天,我还会做今天要做的事吗?"用于过滤真正值得投入的事
|
||||
- [[工具民主化]]: AI降低了做事的门槛,但判断力/品味依然是稀缺能力
|
||||
|
||||
## Key Entities
|
||||
- [[乔布斯]]: 文章借乔布斯之口阐述三大原则,Mac桌面出版的类比说明品味比工具更重要
|
||||
|
||||
## Connections
|
||||
- [[个人品牌与一人公司]] ← 相关 ← [[不谈技术-普通人该怎么在ai时代赚钱]]
|
||||
- 两者都强调整个人定位:找到真正热爱的事,用AI杠杆放大优势
|
||||
- [[Ikigai框架]] ← 关联 ← [[不谈技术-普通人该怎么在ai时代赚钱]]
|
||||
- 死亡过滤器与Ikigai的"热情(Passion)"维度高度一致:对自己真正在乎的事说Yes
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突
|
||||
55
wiki/sources/养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战.md
Normal file
55
wiki/sources/养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "养虾日记1:我用 OpenClaw 管了 28 万张照片:一次真实的多设备照片整理实战"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-03-31
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[微信公众号/养虾日记1:我用 OpenClaw 管了 28 万张照片:一次真实的多设备照片整理实战.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:作者比利哥使用 OpenClaw AI Agent 成功整理了存储在 NAS 上的 28 万张、跨越 20 年的家庭照片。
|
||||
- 问题域:多设备(68 个设备目录)照片备份混乱、重复文件泛滥、人工整理不现实。
|
||||
- 方法/机制:OpenClaw 通过「提问澄清 → 方案制定 → 批次拆分 → Cron 自动执行 → Telegram 报告」流程,完成全自动化照片整理。
|
||||
- 结论/价值:AI Agent 的核心价值不是单点能力提升,而是思维方式的升级——把模糊需求转化为可执行方案。
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- OpenClaw 通过先问关键问题(照片格式、重复定义、低质量判断标准、删除策略),帮助用户从「没想清楚」到「方案清晰」。
|
||||
- OpenClaw 将 68 个目录、28 万个文件拆分为 8 个批次,每天凌晨 0 点自动执行,全程无需人工介入。
|
||||
- AI Agent 的安全策略:待删文件移入 `To-Be-Deleted` 目录而非直接删除,用户可随时检查确认。
|
||||
- 精确去重机制:MD5 哈希比对,只删除完全相同的文件。
|
||||
- 小文件清理:低于 100KB 的图片大概率是截图或微信压缩图,直接移走。
|
||||
- AI Agent 的核心价值是「思维方式升级」而非单点能力提升。
|
||||
|
||||
## Key Quotes
|
||||
> "我有个目录,里面照片很多,来源很杂,我想整理一下,有什么方案?" — 用户对 OpenClaw 的初始指令
|
||||
> "68 个目录,28 万个文件,一次跑完不现实" — OpenClaw 主动识别到的规模挑战
|
||||
> "它帮我把模糊的想法变成了清晰的结构,把大任务拆成了可执行的批次,把风险控制在了可接受的范围内" — 作者对 OpenClaw 思维方式的评价
|
||||
> "这大概就是 AI Agent 对我来说真正的价值:**不是某个单点能力的提升,而是思维方式的升级**" — 结论
|
||||
|
||||
## Key Concepts
|
||||
- [[AI-Agent思维方式]]:AI Agent 不直接推荐工具,而是先通过提问澄清需求,将模糊想法转化为可执行方案
|
||||
- [[批次任务拆分]]:将大规模任务拆分为可管理的批次,降低单次执行风险
|
||||
- [[精确去重]]:通过 MD5 哈希比对,只删除内容完全相同的文件
|
||||
- [[小文件清理]]:低于 100KB 的图片大概率是截图或微信压缩图
|
||||
- [[安全删除策略]]:待删文件移入临时目录而非直接删除,保留人工检查确认环节
|
||||
- [[Cron-Job自动化]]:定时任务自动化执行,无需人工介入
|
||||
- [[Telegram通知]]:任务完成后通过 Telegram 推送 Summary 报告
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]:AI Agent 操作系统,是本次照片整理任务的执行主体
|
||||
- [[Synology Photos]]:群晖 NAS 自带照片管理工具,作者曾尝试使用但效果一般
|
||||
- [[NAS]]:网络附加存储,28 万张照片的存储位置
|
||||
|
||||
## Connections
|
||||
- [[养虾日记2]] ← follow_up ← [[养虾日记1]]
|
||||
- [[养虾日记1]] ← extends ← [[Self-Healing-Self-Improving]]
|
||||
- [[养虾日记3]] ← follow_up ← [[养虾日记1]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Self-Healing-Home-Server]] 冲突:
|
||||
- 冲突点:Self-Healing 侧重「修复已知问题」,本文侧重「主动规划未知任务」
|
||||
- 当前观点:OpenClaw 在照片整理场景中是「规划者」而非「修复者」,通过提问将模糊需求具体化
|
||||
- 对方观点:Self-Healing 场景中 OpenClaw 主要执行监控和修复命令
|
||||
- 说明:两者并不真正冲突,只是同一工具在不同场景下的角色差异——规划 vs 修复
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "养虾日记2:让Agent更懂你:OpenClaw + Self-Improving 复盘实战案例分享"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[微信公众号/养虾日记2:让Agent更懂你:OpenClaw + Self-Improving 复盘实战案例分享]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:AI Agent 的记忆问题与 self-improving 自改进机制
|
||||
- 问题域:多 Agent 协作中的知识遗忘与错误重复
|
||||
- 方法/机制:self-improving skill(结构化经验记录)+ 每日复盘 cron job + 双层记忆架构
|
||||
- 结论/价值:建立"错误只犯一次"的 Agent 学习闭环,区分一次性错误与系统性重复
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- AI Agent 没有记忆,只有上下文窗口,导致每次对话都是"一张白纸"
|
||||
- self-improving 机制让 Agent 在同一错误第二次出现时能直接应用修复,Recurrence-Count 是关键指标
|
||||
- 双层记忆架构(短期文件 + 长期向量数据库) + self-improving 复盘三层各司其职
|
||||
- Pattern-Key 重复本身是信号——第一次记了,第二次就该解决了
|
||||
- 每日 23:00 定时复盘能发现静默漏洞(如无对话日的记忆断层)
|
||||
|
||||
## Key Quotes
|
||||
> "错误只犯一次,第二次就知道怎么做对" — self-improving 核心价值
|
||||
> "每错必记,但分类要准确。错误用 correction,流程改进用 workflow,配置发现用 config"
|
||||
> "Suggested Action 要具体到能直接执行。不要写'注意配置'这种废话,写 `--to 5038825565` 这种具体写法"
|
||||
> "没有 self-improving 复盘,这个漏洞可能永远不会被发现——因为没有人会主动去想'3月27日有没有生成 memory 文件'这种问题"
|
||||
|
||||
## Key Concepts
|
||||
- [[Self-Improving-Skill]]:结构化经验记录系统,Agent 遇问题时调用 `self_improvement_log` 写入 `LEARNINGS.md` 或 `ERRORS.md`,格式包含 Summary/Details/Suggested Action/Metadata,含 Pattern-Key 和 Recurrence-Count
|
||||
- [[双层记忆架构]]:短期记忆层(每日对话记录文件 memory/YYYY-MM-DD.md)+ 长期记忆层(memory-lancedb-pro 向量数据库)+ self-improving 层(定时复盘)
|
||||
- [[每日复盘机制]]:每天 23:00(北京时间)自动执行的复盘流程,包含读取当天 memory → self_improvement_log → Pattern-Key 重复检查 → 有价值经验同步长期记忆 → Telegram 摘要推送
|
||||
- [[Pattern-Key]]:经验记录的分类键,用于识别重复踩坑信号(如 cron.telegram-delivery);重复出现是系统性问题的警示
|
||||
- [[Recurrence-Count]]:元数据中的重复次数字段,区分一次性错误与系统性重复,是最重要的指标之一
|
||||
- [[Self-Improvement-Log]]:`self_improvement_log` 工具调用格式,固定格式:LRN-[日期]-[序号] + Priority + Status + Area + Summary + Details + Suggested Action + Metadata
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]:多 Agent 框架,通过 cron 任务系统实现定时复盘,支持 Telegram 通知
|
||||
- [[LanceDB]]:向量数据库,memory-lancedb-pro 的底层引擎,提供语义搜索能力
|
||||
- [[LEARNINGS.md]]:结构化经验记录文件,存放 correction/workflow/config 三类 learning
|
||||
|
||||
## Connections
|
||||
- [[Self-Improving-Skill]] ← 依赖 ← [[OpenClaw]](通过 cron job 定时触发)
|
||||
- [[双层记忆架构]] ← 依赖 ← [[LanceDB]](长期记忆向量存储)
|
||||
- [[每日复盘机制]] ← 依赖 ← [[Self-Improving-Skill]]
|
||||
- [[养虾日记1-我用-openclaw-管了-28-万张照片]] ← 前篇 ← [[养虾日记2]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## Notes
|
||||
- 来源:微信公众号 shenwei(2026-04-17),系列文章"养虾日记"第2篇
|
||||
59
wiki/sources/养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统.md
Normal file
59
wiki/sources/养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "养虾日记3:用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统"
|
||||
type: source
|
||||
tags: [AI-Agent, Obsidian, Gitea, 知识管理, LLM-Wiki]
|
||||
date: 2026-04-09
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[微信公众号/养虾日记3:用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:如何用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统,解决 AI 对话结束后输出丢失的核心问题
|
||||
- 问题域:AI Agent 的输出持久化、版本控制、多端同步
|
||||
- 方法/机制:用 Obsidian 做知识库(多端同步)、Gitea 做版本控制(Git 历史)、OpenClaw 做写入接口(obsidian skill)
|
||||
- 结论/价值:把 AI 变成"会自动整理笔记的实习生"——做完事顺手更新记录
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- OpenClaw Agent 通过 obsidian skill 将输出直接写入 Obsidian 笔记,实现持久化存储
|
||||
- Gitea 托管笔记的 Git 版本管理,任何时候都能回溯历史变更
|
||||
- iCloud Drive 保证手机、笔记本和 Mac mini 三端笔记永远同步
|
||||
- 笔记目录采用分层结构:knowledgebase/ 存放跨 Agent 共用知识,<agentId>/ 存放单一 Agent 私有笔记
|
||||
- Karpathy 的 LLM Wiki 思路:让 AI 增量构建和维护持久化 Wiki,页面间互相链接,知识越积越厚
|
||||
- Obsidian Graph View 可以发现"孤岛页面"和"幽灵节点"(被多处引用但没有独立页面的概念)
|
||||
|
||||
## Key Quotes
|
||||
> "用 Obsidian 做知识库,用 Gitea 做版本控制,用 OpenClaw 做写入接口。" — 核心架构概括
|
||||
> "AI 批量改文件的能力越强,你越需要版本管理来兜底。" — 版本管理的重要性
|
||||
> "本质上是把 AI 变成了一个'会自动整理笔记的实习生'——它做完事,就会顺手把记录更新好。" — 系统价值定位
|
||||
> "RAG 模式是'每次从零检索',知识不积累;而 LLM Wiki 是让 AI 增量构建和维护一个持久化的 Wiki,页面之间互相链接,知识越积越厚。" — Karpathy LLM Wiki 核心理念
|
||||
|
||||
## Key Concepts
|
||||
- [[LLM Wiki]]:让 AI 增量构建和维护持久化的 Wiki,页面间互相链接,知识越积越厚(区别于 RAG 的"每次从零检索")
|
||||
- [[Obsidian Git]]:Obsidian 社区插件,支持 Auto commit-and-sync interval,自动 commit + push 到 Git 仓库
|
||||
- [[Graph View]]:Obsidian 内置图谱视图,将所有 Wiki 页面以节点展示,双链关系自动连线,用于发现孤岛页面和知识盲区
|
||||
- [[Obsidian Web Clipper]]:浏览器插件,用于快速采集外部网页文章为 Markdown 到 Obsidian,配合图片本地化
|
||||
- [[QMD]]:完全本地运行的 Markdown 搜索引擎,适合 Wiki 规模变大后的精准搜索
|
||||
- [[版本管理]]:Git 历史记录每一次变更的来源和内容,支持回溯和多协作
|
||||
- [[被动更新]]:AI 在执行任务过程中顺手维护链接、更新摘要、添加 Tag、标记新旧矛盾,而非被动等着被查询
|
||||
- [[双链笔记]]:Obsidian 的核心特性,页面间通过 [[wikilinks]] 互相链接形成知识网络
|
||||
|
||||
## Key Entities
|
||||
- [[Gitea]]:自建 Git 服务,托管笔记的版本控制,所有历史版本完整保留
|
||||
- [[Obsidian]]:笔记管理工具,支持多端同步(iCloud Drive)和双链笔记
|
||||
- [[OpenClaw]]:AI Agent 框架,提供 obsidian skill 作为写入接口
|
||||
- [[Karpathy]]:LLM Wiki 理念的提出者(2026-03 分享)
|
||||
- [[iCloud Drive]]:Apple 云同步服务,确保笔记在 Mac mini、笔记本和 iPhone 三端同步
|
||||
|
||||
## Connections
|
||||
- [[养虾日记1]] ← 同一系列 ← [[养虾日记2]]
|
||||
- [[养虾日记1]] ← 同一系列 ← [[养虾日记3]]
|
||||
- [[养虾日记2]] ← 同一系列 ← [[养虾日记3]]
|
||||
- [[养虾日记4]] ← 同一系列 ← [[养虾日记5]]
|
||||
- [[Second Brain]] ← 类似的持久化记忆理念 ← [[养虾日记3]]
|
||||
- [[Personal Knowledge Base (RAG)]] ← 相关的知识管理方案 ← [[养虾日记3]]
|
||||
- [[LLM Wiki]] ← 核心理论支撑 ← [[养虾日记3]]
|
||||
- [[self-healing-home-server]] ← 使用同款笔记系统 ← [[养虾日记3]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "养虾日记4:一次「Context Limit Exceeded」错误排查:我以为是小问题,结果踩了大坑"
|
||||
type: source
|
||||
tags: [OpenClaw, 错误排查, Context-Window, Telegram, 日志调试]
|
||||
date: 2026-04-10
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[微信公众号/养虾日记4: 一次「Context Limit Exceeded」错误排查:我以为是小问题,结果踩了大坑.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:OpenClaw Agent 系统的 Context Limit 错误深度排查——从表象修复(调整 compaction 配置)到找到根本原因(Telegram channel 绑定了只有 16K context 的 DeepSeek 模型)
|
||||
- 问题域:OpenClaw Telegram Channel 配置、模型 Fallback 机制、Context Window 管理
|
||||
- 方法/机制:通过 Gateway 日志定位到模型被切换为 deepseek-reasoner(16K context),safeguard 模式预留 16K tokens 导致实际可用空间为 0;问题根源在 Agent 路由规则而非全局配置
|
||||
- 结论/价值:错误信息 ≠ 问题根因;分层配置需要分层排查;日志是系统状态的最直接反映
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- 星枢 Telegram Channel 触发「Context limit exceeded」,直接原因并非对话历史过长,而是当前使用的模型(deepseek-reasoner)context window 仅 16K
|
||||
- OpenClaw safeguard 模式在 compaction 时预留 16K tokens,与 16K context 模型叠加,导致实际可用 context 为 0
|
||||
- 全局 compaction 配置(openclaw.json)与 Agent 级别模型配置是两套独立层级,修改全局配置无法解决 Agent 级别的模型问题
|
||||
- 解决根本方案是将星枢 Telegram channel 的路由改回 MiniMax-M2.7(200K context),而非继续调低 compaction 阈值
|
||||
- 日志分析是定位此类"隐藏配置路径"问题的唯一可靠手段
|
||||
|
||||
## Key Quotes
|
||||
> `provider=custom-api-deepseek-reasoner/deepseek-reasoner ctx=16000 / estimatedPromptTokens=393 overflowTokens=392 reserveTokens=16384` — Gateway 日志直接揭示了模型切换和 token 耗尽问题
|
||||
> `「Context limit exceeded」不一定是因为对话太长,可能是模型配置本身就有问题` — 核心教训:错误表象 ≠ 根本原因
|
||||
> `不要默认认为错误信息就是表面意思。先问一句:到底哪儿出问题了?` — 最终方法论总结
|
||||
|
||||
## Key Concepts
|
||||
- [[Context-Window]]: 模型单次请求能处理的最大 token 数量;deepseek-reasoner 仅 16K,MiniMax-M2.7 为 200K
|
||||
- [[Model-Fallback]]: 当默认模型不可用时,OpenClaw 按优先级切换到 fallback 列表中的下一个模型;触发原因包括 API 503/429/Timeout、路由权重错误、或配置覆盖
|
||||
- [[Compaction]]: OpenClaw 的上下文压缩机制,在 safeguard 模式下会预留 16K tokens 用于执行压缩操作
|
||||
- [[Agent-Routing-Rules]]: 绑定 Telegram channel 到特定模型的路由规则,优先级高于全局配置
|
||||
- [[Error-Surface-vs-Root-Cause]]: 不要被错误信息的字面意思误导;表象修复 ≠ 根本解决
|
||||
- [[Layered-Configuration]]: OpenClaw 配置分全局配置(openclaw.json)和 Agent/Channel 级别配置;问题可能藏在不同层级
|
||||
- [[Log-Driven-Debugging]]: Gateway 日志直接揭示了模型切换事件和 token 分配详情,是定位问题的唯一可靠手段
|
||||
- [[Hidden-Failure-Paths]]: 复杂分布式系统中,故障可能藏在 session、memory、model config、routing rules、compaction 策略等多个地方
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]: 运行星枢的 AI Agent 框架;本文核心调试对象
|
||||
- [[星枢]]: 用户的 AI 助手(xingshu/main agent);通过 Telegram 与用户交互
|
||||
- [[DeepSeek]]: deepseek-reasoner 模型提供方;context window 仅 16K,是本次问题的直接触发者
|
||||
- [[MiniMax]]: MiniMax-M2.7 模型提供方;context window 为 200K,是正确的配置目标
|
||||
|
||||
## Connections
|
||||
- [[养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录]] ← related_to ← [[养虾日记4]](同属 OpenClaw 调试系列,互补关系)
|
||||
- [[养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战]] ← related_to ← [[养虾日记4]](同属"养虾日记"系列)
|
||||
- [[养虾日记2-让agent更懂你-openclaw-self-improving-复盘实战案例分享]] ← related_to ← [[养虾日记4]](同属"养虾日记"系列)
|
||||
- [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]] ← related_to ← [[养虾日记4]](同属"养虾日记"系列)
|
||||
- [[n8n调用hermes-agents的工作流架构]] ← related_to ← [[养虾日记4]](OpenClaw 配置层级问题在此亦有体现)
|
||||
|
||||
## Contradictions
|
||||
- 与 [[养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录]] 的互补关系:
|
||||
- 冲突点:养龙虾系列重点在记忆写入/检索失效(semantic memory、context compression),本文重点在模型配置错误导致 context 立即耗尽
|
||||
- 当前观点:两者均为 OpenClaw "记忆失效"症状的不同根因;养龙虾系列归因于记忆插件和压缩机制,本文归因于模型配置本身
|
||||
- 对方观点:养龙虾系列认为写入纪律和压缩协同是主要挑战
|
||||
- 说明:互补而非冲突,两类问题可同时存在
|
||||
78
wiki/sources/养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流.md
Normal file
78
wiki/sources/养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流.md
Normal file
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: "养虾日记5:深夜与苏轼聊AI,他说:被浪打下去还能爬起来的才叫风流"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-23
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[微信公众号/养虾日记5:深夜与苏轼聊AI,他说:被浪打下去还能爬起来的才叫风流]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:用AI蒸馏历史人物思维框架,创建"数字导师"——以苏东坡为首位实践对象,展示如何将千年前古人的心智模型转化为可运行的AI Skill
|
||||
- 问题域:如何让AI不仅"替人做事",还能"帮人思考";如何蒸馏一个人的思维框架并AI化
|
||||
- 方法/机制:女娲·Skill造人术——6个并行Agent从6个维度采集信息(著作/对话/表达DNA/他者视角/决策/时间线),提炼出6个核心心智模型、8条决策启发式和一套表达DNA
|
||||
- 结论/价值:每个人的Skill都是一个认知操作系统,可以随时用历史伟人的思维镜片看自己的困境
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- 作者提出"数字导师"概念:不是肤浅的NPC扮演,而是捕捉一个人看世界的方式——决策逻辑、思维模型、表达DNA、遇逆境时的第一反应
|
||||
- "女娲造人"本质是信息蒸馏:从大量公开信息中提炼核心心智模型、决策启发式、表达DNA和价值观边界,产出自包含的.skill文件
|
||||
- 苏东坡一生三起三落,从庙堂翰林到黄州团练副使到惠州、儋州南荒,无论被贬到哪里都在做事——"问汝平生功业,黄州惠州儋州"是自嘲也是骨气
|
||||
- 真正风流的人不是站在浪尖上的人,而是被浪打下去还能爬起来的人
|
||||
- AI时代用AI放大人类历史上最强大的脑子,让它们成为日常思维顾问——学投资蒸馏芒格,学物理思维蒸馏费曼,逆境中保持风骨蒸馏苏东坡
|
||||
|
||||
## Key Quotes
|
||||
> "大江东去,浪淘尽,千古风流人物"——但真正风流的人,不是站在浪尖上的人,而是被浪打下去、还能爬起来的人。— 苏东坡(AI模拟)对作者说的话
|
||||
> "人生到处知何似,应似飞鸿踏雪泥。"— 苏东坡原诗,文章结尾引用
|
||||
> "此心安处是吾乡"——故乡不是地理概念,是心安之处。被贬黄州物质最匮乏的三年,反而诞生了《赤壁赋》等一生最重要的作品。— 苏东坡的心智模型之一
|
||||
> 通过深度调研,提炼一个真实人物的核心思维框架,把它变成一个可运行的AI Skill。— 女娲造人术的定义
|
||||
|
||||
## Key Concepts
|
||||
- [[数字导师]]:用AI蒸馏历史/伟人思维框架,使其成为可对话的日常思维顾问,而非单向输出的书/课程
|
||||
- [[思维蒸馏(女娲造人术)]]:通过6维度并行Agent采集信息,提炼心智模型、决策启发式和表达DNA,产出自包含的.skill文件
|
||||
- [[心智模型]](SuDongPo):进退由时/此心安处是吾乡/辞达而已/逆境转化/自出新意不践古人/物我相谙天人合一
|
||||
- [[AI-Skill]]:AI Agent的可复用技能模块,激活后以特定人物视角与用户对话
|
||||
|
||||
## Key Entities
|
||||
- [[苏东坡]](苏轼,1037-1101):北宋文学家,蒸馏的首位历史人物,一生三起三落,三大贬谪地黄州/惠州/儋州,"东坡居士"名号象征在泥土里活出人样
|
||||
- [[比利哥]]:本文作者,自称OpenClaw"养虾人",被裁员后通过AI学习重新出发,与苏东坡进行真实对话
|
||||
- [[女娲]](Nuwa Skill):开源AI造人Skill项目,github.com/alchaincyf/nuwa-skill,提供蒸馏历史人物的框架
|
||||
- [[OpenClaw]]:多Agent框架,本文的技术底座,支撑Skill激活和多Agent并行采集
|
||||
- [[苏东坡Skill]]:ishenwei/openclaw-skills仓库中的perspective skill,基于女娲框架蒸馏完成
|
||||
|
||||
## Connections
|
||||
- [[养虾日记3]] ← extends ← [[养虾日记5]]:同属「养虾日记」系列,前者讲持久化笔记系统,后者讲AI数字导师——都是让AI从工具升级为"顾问"
|
||||
- [[养虾日记1]] ← extends ← [[养虾日记5]]:同属「养虾日记」系列
|
||||
- [[养虾日记2]] ← extends ← [[养虾日记5]]:同属「养虾日记」系列
|
||||
- [[养龙虾5天血泪史]] ← extends ← [[养虾日记5]]:同属「养虾日记」系列
|
||||
- [[Second Brain]] ← relates_to ← [[数字导师]]:Second Brain捕获记忆,数字导师蒸馏伟人思维——都是用AI构建外部认知能力
|
||||
- [[思维蒸馏(女娲造人术)]] ← implements ← [[数字导师]]
|
||||
|
||||
## Contradictions
|
||||
- (无明显冲突)
|
||||
|
||||
## 技术细节:女娲工作流
|
||||
|
||||
```
|
||||
用户输入 → 入口分流
|
||||
↓
|
||||
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
|
||||
```
|
||||
|
||||
整个过程不依赖任何外部文件——技能目录是自包含的,复制到任何地方都能独立运行。
|
||||
71
wiki/sources/养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录.md
Normal file
71
wiki/sources/养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录.md
Normal file
@@ -0,0 +1,71 @@
|
||||
---
|
||||
title: "养龙虾5天血泪史:我的AI Agent为什么总失忆?OpenClaw 记忆调试全记录"
|
||||
type: source
|
||||
tags: [AI, Agent, OpenClaw, Memory, Memory-Management]
|
||||
sources: []
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[微信公众号/养龙虾5天血泪史:我的AI Agent为什么总失忆?OpenClaw 记忆调试全记录]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:OpenClaw AI Agent 记忆失效问题的诊断与修复
|
||||
- 问题域:AI Agent 长期记忆缺失、上下文压缩丢失信息、搜索不准确、检索不自动、系统臃肿
|
||||
- 方法/机制:通过5天专项调试,发现5类根本原因(压缩机制、搜索后端、检索触发、压缩协同、系统配置),对应10条黄金法则
|
||||
- 结论/价值:**写入纪律比读取纪律更重要**;系统提示词中每个令牌都是开销;压缩不是敌人,未写入的上下文才是
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- 当对话填满 Context Window 时,OpenClaw 将旧消息压缩成摘要,姓名、数字、具体决定等细节全部丢失
|
||||
- 纯语义搜索在专有名词、具体数字和确切短语上失败,BM25+向量+重新排序的混合搜索明显更好
|
||||
- "信息存在"和"Agent 使用信息"之间有区别——必须通过启动指令强制触发检索
|
||||
- OpenClaw 仅自动加载 AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md、HEARTBEAT.md、MEMORY.md,其他文件需要明确读取指令
|
||||
- 模型切换时丢失所有上下文,新模型只看到自动加载的文件,需要交接协议将状态写入每日日志
|
||||
- 系统提示词从 209,652 精简到 9,349 令牌,轻了 28%
|
||||
|
||||
## Key Quotes
|
||||
> "压缩不是敌人。压缩过程中丢失信息才是。修复方法是确保任何值得记住的内容在压缩器触及前写入文件。" — Day 1 核心洞察
|
||||
|
||||
> "纯语义搜索理论上听起来不错,但在专有名词、具体数字和确切短语上失败。混合搜索对现实世界代理内存明显更好。" — Day 2 核心洞察
|
||||
|
||||
> "'信息存在'和'Agent 使用信息'之间有区别。你需要两者。" — Day 3 核心洞察
|
||||
|
||||
> "真正的修复不是添加更多文件。而是移除那些什么都不做的文件。" — Day 5 核心洞察
|
||||
|
||||
## Key Concepts
|
||||
- [[上下文压缩]]:OpenClaw 将旧消息压缩成摘要为新消息腾空间的机制,摘要丢失细节(姓名、数字、决定)
|
||||
- [[上下文刷新]](Memory Flush):压缩前将重要上下文写入磁盘的配置,`softThresholdTokens: 4000` 触发刷新
|
||||
- [[混合搜索]](Hybrid Search):BM25(关键词)+向量嵌入+重新排序器组合,兼顾精确匹配和语义相似性
|
||||
- [[Context Pruning]]:上下文修剪机制,与压缩协同工作,`cache-ttl` 模式 6 小时后清理旧上下文,保留最后 3 个助手响应
|
||||
- [[系统提示词膨胀]](System Prompt Bloat):未使用技能、臃肿内存文件、不自动读取的文件默默累积 token 开销
|
||||
- [[交接协议]](Handoff Protocol):模型切换前将当前上下文写入每日日志的规程,防止新模型丢失状态
|
||||
- [[启动序列]]:Agent 启动时必须执行的操作指令,必须放在 AGENTS.md 最顶部
|
||||
- [[写入纪律]](Write Discipline):强制 Agent 将决定、结果和错误记录到磁盘,比读取纪律更关键
|
||||
- [[自动加载文件]]:OpenClaw 在每个新会话自动读取的 7 个核心文件(AGENTS/SOUL/TOOLS/IDENTITY/USER/HEARTBEAT/MEMORY)
|
||||
- [[检索触发]](Retrieval Trigger):Agent 必须被明确告知何时搜索,不能依赖隐式线索
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]:multi-agent framework,本文调试的核心框架,内存管理机制的关键系统
|
||||
- [[比利哥]](shenwei):本文作者,正在研究 AI 提高工作效率的个人用户,OpenClaw AI 助理"星辉"的所有者
|
||||
|
||||
## Connections
|
||||
- [[上下文压缩]] ← depends_on ← [[上下文刷新]]
|
||||
- [[上下文刷新]] ← prevents ← [[上下文压缩]]的信息丢失
|
||||
- [[混合搜索]] ← extends ← [[QMD搜索后端]]
|
||||
- [[Context Pruning]] ← coordinates_with ← [[上下文压缩]]
|
||||
- [[交接协议]] ← solves ← [[上下文刷新]]无法覆盖多次压缩的问题
|
||||
- [[养虾日记1]] ← related_to ← [[养虾日记2]] ← related_to ← [[养虾日记3]]
|
||||
- [[养龙虾5天血泪史]] ← related_to ← [[养虾日记1]](同一系列)
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Second Brain]] 冲突:
|
||||
- 冲突点:MEMORY.md 的定位
|
||||
- 当前观点(本文):任务期间永远不要直接写入 MEMORY.md,每日日志是原始且仅追加的,MEMORY.md 应在定期审查期间策划
|
||||
- 对方观点(Second Brain):通过对话零摩擦捕获任何内容,OpenClaw 永久记忆存储所有对话
|
||||
- 说明:两者不矛盾,Second Brain 侧重捕获策略,本文侧重策划和写入纪律
|
||||
|
||||
- 与 [[personal-crm]] 冲突:
|
||||
- 冲突点:联系人信息的记录方式
|
||||
- 当前观点(本文):每日日志仅追加,由定时任务(如心跳或定时任务)期间审查并提炼
|
||||
- 对方观点(personal-crm):每日 Cron Job 扫描 Gmail 和日历,自动提取新联系人并更新 SQLite 数据库
|
||||
- 说明:personal-crm 针对结构化联系人数据有专门处理流程,与本文的通用内存写入纪律互补
|
||||
44
wiki/sources/教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報.md
Normal file
44
wiki/sources/教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "教學 ChatGPT 先做知識整理,再讓 Canva、 Gamma AI 輸出簡報"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-21
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[AI/教學 ChatGPT 先做知識整理,再讓 Canva、 Gamma AI 輸出簡報.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主題:AI 簡報自動化工作流——先用 ChatGPT 做知識整理,再用 Canva / Gamma AI 輸出演示文稿
|
||||
- 問題域:如何高效制作演示文稿,如何将 AI 应用于内容创作流程
|
||||
- 方法/機制:两阶段工作流——知识整理 → 簡報生成
|
||||
- 結論/價值:提升简报制作效率,保证内容质量,ChatGPT 负责深度思考与内容组织,Canva/Gamma AI 负责视觉呈现与排版
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- ChatGPT 擅长知识整理和信息提取,可将分散资料结构化
|
||||
- Canva / Gamma AI 能将整理好的内容快速转化为精美演示文稿
|
||||
- 两阶段工作流比直接用 AI 生成简报效果更好——先让 AI 做"思考者",再做"设计师"
|
||||
- Gamma AI 支持一键生成完整演示文稿,支持主题定制和内容编辑
|
||||
|
||||
## Key Quotes
|
||||
> "ChatGPT 的优势在于理解、总结、重组信息,让它先整理好资料再做简报,能大幅提升内容质量。" — 教程核心观点
|
||||
|
||||
## Key Concepts
|
||||
- [[AI簡報工作流]]:两阶段简报制作流程,先用 LLM 做知识整理,再用 AI 设计工具输出
|
||||
- [[知識結構化]]:将非结构化信息转化为清晰、有逻辑的内容框架
|
||||
- [[AI設計工具]]:Canva、Gamma AI 等将内容自动转化为视觉呈现的工具
|
||||
|
||||
## Key Entities
|
||||
- [[ChatGPT]]:OpenAI 开发的大语言模型,在此教程中担任"知识整理者"角色
|
||||
- [[Canva]]:在线可视化设计平台,支持简报、海报、社交媒体图片等多种设计
|
||||
- [[Gamma AI]]:AI 驱动的演示文稿生成工具,通过 AI 将文本内容一键转换为精美简报
|
||||
|
||||
## Connections
|
||||
- [[AI圖生視頻工具盤點]] ← 同一主题 ← [[AI簡報工作流]](均属 AI 内容创作工具应用)
|
||||
- [[YouTube-Content-Pipeline]] ← 流程相似 ← [[AI簡報工作流]](均为"AI 整理 → AI 输出"两阶段模式)
|
||||
|
||||
## Contradictions
|
||||
- 与直接用 AI 生成简报的方法(如某些"一键生成 PPT"的工具):
|
||||
- 冲突点:是否需要人工介入内容整理环节
|
||||
- 当前观点:先用 ChatGPT 整理知识,确保内容逻辑清晰再交给设计工具
|
||||
- 对方观点:直接让 AI 生成完整简报,节省中间步骤
|
||||
42
wiki/sources/文字生成视频网站推荐.md
Normal file
42
wiki/sources/文字生成视频网站推荐.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "文字生成视频网站推荐"
|
||||
type: source
|
||||
tags: [AI, 视频生成, AI工具]
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[AI/文字生成视频网站推荐.md]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:推荐适合中国用户的文字生成视频 AI 工具
|
||||
- 问题域:AI 视频生成工具选型与性价比评估
|
||||
- 方法/机制:通过搜索结果综合评估工具功能、价格、适用人群
|
||||
- 结论/价值:为不同需求的用户提供工具选型建议(免费/技术型/多语言/长视频处理)
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- 万彩AI 通过完全免费且功能全面的方案,适合预算有限的新手小白、自媒体创作者
|
||||
- 百度AI开放平台 基于多模态技术提供智能化视频生成,大厂技术背书
|
||||
- Zeemo 通过高精度字幕生成(95种语言,98%准确率)满足多语言内容创作者需求
|
||||
- Vizard 通过智能剪辑长视频高光片段,适合需要批量处理视频的用户
|
||||
|
||||
## Key Quotes
|
||||
> "建议优先试用免费工具(如万彩AI或百度AI),再根据实际需求选择付费服务。" — 综合选型建议
|
||||
|
||||
## Key Concepts
|
||||
- [[文字生成视频]]:通过文本描述自动生成视频内容的技术
|
||||
- [[AI视频生成工具]]:集成文字处理、配音合成、素材匹配的自动化视频制作工具
|
||||
- [[数字人]]:AI 生成的虚拟人物形象,用于视频内容创作
|
||||
|
||||
## Key Entities
|
||||
- [[万彩AI]]:提供免费文字生成视频的工具,支持数字人、模板库
|
||||
- [[百度AI开放平台]]:提供 AI 成片功能的大厂平台
|
||||
- [[Zeemo]]:蓝色脉动公司产品,专注多语言字幕生成
|
||||
- [[Vizard]]:蓝色脉动公司产品,专注长视频自动剪辑
|
||||
- [[快影]]:腾讯系短视频剪辑工具
|
||||
|
||||
## Connections
|
||||
- [[AI图生视频工具盘点]] ← 互补 ← [[文字生成视频网站推荐]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
Reference in New Issue
Block a user