Auto-sync: wiki-ingest 3 sources (2026-04-16)

wiki/sources/3.2万人收藏的Claude-Skills-才是AI这条路.md

@@ -0,0 +1,58 @@
+---
+title: "3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！"
+type: source
+tags: [claude, skills, anthropic, workflow, prompt-engineering]
+date: 2026-01-08
+sources:
+  - "3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ 1.md"
+---
+
+## Source File
+- raw/AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ 1.md
+
+## Summary
+- 核心主题：Claude Skills 作为 AI 应用的新范式，代表从提示词工程向流程工程的转型
+- 问题域：大多数 AI 用户还在纠结如何写好 Prompt，而高阶玩家已开始构建可复用的 Skills
+- 方法/机制：Skills = 写给 Claude 的"说明书" + SOP（标准作业程序），将固定流程任务拆解为 AI 可理解、可稳定复用、可自动执行的流程
+- 结论/价值：Skills 的爆发标志从提示词工程迈向流程工程；未来有价值的不是谁的 Prompt 写得最花，而是谁最懂业务流程、谁能将经验沉淀为 SOP
+
+## Key Claims
+- Skills 本质是"说明书"和"SOP"：将反复执行、有固定流程的任务拆解为 AI 能理解、稳定复用、自动执行的流程
+- Anthropic 官方 Skills 仓库（github.com/anthropics/skills）收藏数突破 3.2 万，原封不动地拆解了 Claude.ai 网页版的生产级能力
+- 官方库覆盖三大类：办公自动化（Word/PDF/PPT/Excel）、开发者工具箱（MCP Server、Web 测试、Artifacts、自动化验证）、创意类 Skills
+- 三个 Awesome-Claude-Skills 精选仓库：ComposioHQ、VoltAgent、BehiSecc
+- 三个 Skill 聚合站：skillsmp.com、aitmpl.com/skills、claudemarketplaces.com
+- Skills 的本质是官方在教"怎么像 Anthropic 一样开发 AI 应用"
+
+## Key Quotes
+> "Skills 就是一套你写给 Claude 的'说明书'和'SOP（标准作业程序）'" — 核心定义
+> "这个库本质上是官方在教你，'怎么像我们一样开发 AI 应用'" — 价值定位
+> "未来真正有价值的，不是谁的 Prompt 写得最花、谁一次能生成最多内容；而是谁最懂业务流程、谁能把经验沉淀成 SOP、谁能把 SOP 交给 AI 稳定执行" — 趋势判断
+
+## Key Concepts
+- [[AI技能封装]]：将固定流程任务拆解为 AI 可理解、可复用、可自动执行的结构化流程的方法论
+- [[Prompt工程]] → [[流程工程]]：从优化单次输出质量转向优化整套流程的稳定性与可复用性
+- [[Claude Skills]]：Anthropic 官方发布的 AI 技能指南，本质是"说明书 + SOP"
+
+## Key Entities
+- [[Anthropic]]：Claude Skills 官方仓库的发布者
+- [[Anthropic Skills 官方库]]：github.com/anthropics/skills，3.2 万收藏，生产级能力拆解
+- [[ComposioHQ/awesome-claude-skills]]：精选 Claude Skills 仓库
+- [[VoltAgent/awesome-claude-skills]]：精选 Claude Skills 仓库
+- [[BehiSecc/awesome-claude-skills]]：精选 Claude Skills 仓库
+- [[skillsmp.com]]：Skill 聚合站
+- [[aitmpl.com/skills]]：Skill 聚合站
+- [[claudemarketplaces.com]]：Skill 聚合站
+
+## Connections
+- [[Anthropic]] ← 发布者 ← [[Anthropic Skills 官方库]]
+- [[Anthropic Skills 官方库]] ← 官方示例 ← [[Claude Skills]]
+- [[Claude Skills]] ← 范式升级 ← [[Prompt工程]]
+- [[Claude Skills]] ← 具体实现 ← [[AI技能封装]]
+- [[skillsmp.com]] ← 聚合平台 ← [[Claude Skills]]
+- [[aitmpl.com/skills]] ← 聚合平台 ← [[Claude Skills]]
+- [[claudemarketplaces.com]] ← 聚合平台 ← [[Claude Skills]]
+- [[Vibe Coding]] ← 尽头是 ← [[Claude Skills]]
+
+## Contradictions
+- 无已知冲突

wiki/sources/A-Formalization-of-Recursive-Self-Optimizing-Generative-Systems.md

@@ -1,52 +1,42 @@
 ---
 title: "A Formalization of Recursive Self-Optimizing Generative Systems"
 type: source
-tags: [cs.LO, cs.AI, math.CT, 形式化, 元学习]
-sources: [raw/AI/A Formalization of Recursive Self-Optimizing Generative Systems.md]
-last_updated: 2026-04-15
+tags: [ai, formalization, self-improvement, lambda-calculus]
+date: 2025-12-30
 ---
 
 ## Source File
-- raw/AI/A Formalization of Recursive Self-Optimizing Generative Systems.md
+- [[raw/AI/A Formalization of Recursive Self-Optimizing Generative Systems.md]]
 
 ## Summary
-- 核心主题：递归自优化生成系统的形式化建模，固定点语义下的自举动力学
-- 问题域：AI 系统自我改进机制的理论基础，元生成器的收敛性证明
-- 方法/机制：自映射（Self-Map）、固定点（Fixed Point）、λ-calculus 递归组合子（Y Combinator）
-- 结论/价值：为自改进 AI 架构、自动元提示词系统提供严谨的数学框架
+- 核心主题：递归自优化生成系统的形式化建模，通过自映射（self-map）和固定点（fixed point）语义描述 AI 系统的自我改进动力学
+- 问题域：如何让 AI 系统在不依赖外部干预的情况下持续改进自身生成能力
+- 方法/机制：自映射 Φ(G) = M(G, O(G(I), Ω)) 将优化结果反馈给生成器；Y Combinator 实现 λ-calculus 自举
+- 结论/价值：稳定生成能力对应 Φ 的固定点 G*，自我改进的目标是收敛行为而非单次最优输出
 
 ## Key Claims
-- 递归自优化的目标不是单个最优输出，而是在生成器空间（Generator Space）中收敛到稳定生成能力
-- 稳定生成能力对应于元生成算子（Meta-Generative Operator）的固定点（Fixed Point）
-- 自举（Bootstrapping）过程通过"生成→优化→更新"的循环迭代实现系统自我超越
-- Y Combinator 表达自引用动力学：G* = Y STEP，G* = STEP G*，即生成器是自身变换的不动点
+- 递归自优化系统的目标不是最优输出，而是生成器空间 {G_n} 的收敛行为
+- 稳定生成能力 = Φ 的固定点 G*，即 Φ(G*) = G*
+- Y Combinator 表达式 G* = Y STEP 满足 G* = STEP G*，体现了系统的自指本质
+- 自举（bootstrapping）通过优化产物反馈给系统，启动下一轮进化循环
 
 ## Key Quotes
-> "The system's objective is not a particular P*, but the convergence behavior of the sequence {G_n}." — 论文核心命题，生成器迭代的收敛性才是关键，而非单次输出质量
-> "A stable generative capability is defined as a fixed point of Φ: G* ∈ G, Φ(G*) = G*" — 稳定生成能力即系统不动点
-> "Such systems align with classical results on self-reference, recursion, and bootstrapping computation" — 自引用经典理论框架下的一次形式化尝试
+> "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." — tukuai
+
+> "Such systems naturally instantiate a bootstrapping meta-generative process governed by fixed-point semantics." — tukuai
 
 ## Key Concepts
-- [[自递归优化生成系统]]：α-提示词（生成器）+Ω-提示词（优化器）通过自举实现无限逼近理想状态
-- [[固定点]]：Φ(G*) = G* 的生成器，不随自身生成-优化-更新循环而改变
-- [[自举]]：用优化后的产物反馈给系统，再次优化生成器本身，形成递归超越
-- [[元生成器]]（Meta-Generator）：更新生成器的函数 M: G × P → G
-- [[λ-calculus 递归]]：使用 Y Combinator 表达 G* = Y STEP 的自引用不动点
-- [[Generator Space]]：所有可能的生成器构成的空间 ℒ ⊆ ℘^ℐ
+- [[自递归优化生成系统]]：α-提示词（生成器 G）+ Ω-提示词（优化器 O）+ 元生成器（M）三角色递归循环
+- [[固定点]]：Φ(G*) = G* 的生成器状态，系统不动点，即自洽的稳定生成能力
+- [[Y Combinator]]：λ-calculus 固定点组合子，Y ≡ λf.(λx.f(x,x))(λx.f(x,x))，用于表达自指动力学
 
 ## Key Entities
-- [[tukuai]]：独立研究者，该形式化框架的提出者，GitHub 账户 https://github.com/tukuai
+- [[tukuai]]：递归自优化生成系统形式化框架提出者，独立研究者
 
 ## Connections
-- [[自递归优化生成系统]] ← 理论基础 ← [[固定点]]
-- [[自递归优化生成系统]] ← 形式化工具 ← [[λ-calculus]]
-- [[Agent Skill 设计模式]] ← 实践对应：Generator Pattern 实现自递归优化的工程化版本
-- [[自递归优化生成系统]] ← 收敛目标 ← [[固定点]]
-- [[自递归优化生成系统]] → 实践框架 → [[Agent Skill 设计模式]]
-- [[自递归优化生成系统]] → 认知基础 → [[自我改进]]
+- [[Multi-Agent System Reliability]] ← relates_to ← [[Multi-Agent Hierarchy]]，层级架构中 Supervisor 对应 Generator 角色
+- [[Agent Skill 设计模式]] ← extends ← [[自递归优化生成系统]]，Skill Generator Pattern 是固定点语义的具体实践
+- [[Claude Code]] ← tools ← [[自递归优化生成系统]]，Claude Code 通过 Skill 加载实现生成器更新
 
 ## Contradictions
-- 与 [[Claude-Code调用方法总结]] 冲突：
-  - 冲突点：Claude Code 作为工具是否具备自优化能力
-  - 当前观点：Claude Code 是静态工具，仅被动响应指令，无自我改进机制
-  - 对方观点：递归自优化系统理论暗示 AI 工具通过迭代使用可以形成隐式自我改进（通过生成器空间收敛）
+- 与 [[AI Agent 思维方式]] 冲突：本文强调"停止拟人化 LLM"，AI Agent 思维方式强调先问关键问题。冲突点：本文主张架构约束 > 情感化 prompt；AI Agent 思维方式认为澄清问题优先于执行。当前观点：架构约束更根本，澄清问题是执行层面的优化。

wiki/sources/AI-解决方案专家培训课程.md

@@ -0,0 +1,45 @@
+---
+title: "AI 解决方案专家培训课程"
+type: source
+tags: [ai, coze, workflow, industry-solution]
+date: 2025-06-20
+---
+
+## Source File
+- [[raw/AI/AI 解决方案专家培训课程.md]]
+
+## Summary
+- 核心主题：Coze 中文版平台提供的多行业 AI Agent 与工作流 Demo 集合，覆盖金融/教育/医疗/电商/客服等场景
+- 问题域：企业难以快速构建可落地的 AI 解决方案，缺乏从概念到实际部署的完整参考
+- 方法/机制：Coze 平台提供预置 Bot/Workflow 模板，用户可 Fork 后自定义改造，API 调用外部工具（GPT-SoVITS/F5-TTS/FaceFusion）
+- 结论/价值：低代码平台大幅降低 AI 解决方案开发门槛，非技术用户也能搭建企业级 AI 应用
+
+## Key Claims
+- Coze 平台实现 AI 应用开发平民化，通过邀请链接即可加入团队空间体验 Demo
+- Workflow 模式（工作流模式）比 Bot 模式更适合复杂多步骤任务，流程固定但灵活性强
+- 表格问答助手支持代码版和插件版两种实现，满足不同技术能力用户需求
+- 医疗分诊助手结合图像识别（影像图片 Excel 数据）+ 问诊逻辑，实现端到端 AI 辅助
+
+## Key Quotes
+> "数据分析案例：https://www.coze.cn/space/7433704316877520906/project-ide/7507579385827360779" — Coze 平台数据分析案例
+
+> "AI证件照Demo：https://idphoto.bananaresearch.cn/" — 泛娱乐场景 AI 应用 Demo
+
+## Key Concepts
+- [[Coze工作流]]：Coze 平台的可视化 Workflow 编辑器，通过节点串联实现复杂业务流程
+- [[AI行业解决方案]]：针对特定行业（金融/教育/医疗/电商）垂直场景的 AI Agent 定制方案
+- [[表格问答助手]]：基于知识库的自然语言 SQL 查询工具，支持代码版和插件版两种架构
+
+## Key Entities
+- [[Coze]]：字节跳动旗下的 AI Agent 开发平台，国内版（coze.cn）和海外版（coze.com）双版本运营
+- [[FaceFusion]]：人脸融合 AI 工具，用于泛娱乐场景的 AI 证件照和视频生成
+- [[F5-TTS]]：开源语音克隆项目，用于数字人和 AI 客服的语音合成
+- [[GPT-SoVITS]]：声音克隆模型，用于医疗问诊等场景的个性化语音交互
+
+## Connections
+- [[n8n]] ← comparable_to ← [[Coze工作流]]，两者都是可视化工作流编排工具，但 Coze 专注于 AI Agent，n8n 通用性更强
+- [[AI数据处理]] ← uses ← [[AI行业解决方案]]，行业方案依赖数据处理层实现结构化信息提取
+- [[智能体工作流]] ← extends ← [[Coze工作流]]，Coze 工作流是智能体工作流的具体实现之一
+
+## Contradictions
+- 与 [[Workflow vs Agent]] 概念：本文的 Workflow 模式强调固定流程；Coze 也支持 Agent 模式（LLM 动态决策）。冲突点：固定流程 vs 动态决策的适用场景。当前观点：复杂业务场景优先 Workflow，简单问答场景用 Agent 模式更灵活。

wiki/sources/Autonomous-Project-Management-STATE-yaml.md

@@ -0,0 +1,38 @@
+---
+title: "Autonomous Project Management（去中心化协调模式）"
+type: source
+tags: [project-management, autonomous, subagent, state-yaml, openclaw]
+date: 2026-04-13
+---
+
+## Source File
+- [[raw/Agent/usecases/autonomous-project-management.md]]
+
+## Summary
+- 核心主题：去中心化项目协调——通过共享 STATE.yaml 文件替代中央 orchestrator
+- 问题域：传统中央协调模式（主 Agent 做交通警察）造成瓶颈，多并行工作流项目需要真正的并行执行
+- 方法/机制：每个项目维护 STATE.yaml 作为单一真实源，subagent 自主读写状态文件协调
+- 结论/价值：主会话保持薄（CEO 模式），所有执行下沉到 subagent，Git 作为审计日志
+
+## Key Claims
+- STATE.yaml > 中央 orchestrator：基于文件的协调比消息传递更具可扩展性
+- Git 作为审计日志：STATE.yaml 变更提交 Git 实现完整历史追溯
+- 标签命名规范：`pm-{project}-{scope}` 便于追踪
+- 薄主会话原则：主 Agent 越少做事，响应越快
+
+## Key Quotes
+> "Main session = coordinator ONLY. All execution goes to subagents." — OpenClaw PM Delegation Pattern
+
+## Key Concepts
+- [[STATE.yaml]]：项目协调文件，YAML 结构定义任务状态与依赖，支持 next_actions 驱动
+- [[去中心化协调]]：无中央 orchestrator，各 subagent 通过共享状态文件自主协调
+- [[GitOps]]（隐式）：Git commit STATE.yaml 变更实现项目状态版本管理
+
+## Key Entities
+- [[Nicholas Carlini]]：自主编码 agent 方法论提出者，STATE.yaml 去中心化协调灵感来源
+- [[OpenClaw]]：支持 sessions_spawn/sessions_send，subagent 文件系统访问
+
+## Connections
+- [[Autonomous-Project-Management-STATE-yaml]] ← implements ← [[Multi-Agent Hierarchy]]（Planner+Worker+Validator，STATE.yaml 替代中央验证器）
+- [[Autonomous-Project-Management-STATE-yaml]] ← shares_pattern ← [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]]（均依赖共享状态协调，而非中央 orchestrator）
+- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← extends ← [[Autonomous-Project-Management-STATE-yaml]]（Solo-Founder 团队在 PM 维度应用去中心化协调）

wiki/sources/Best 7 news API data feeds - AI News.md

@@ -0,0 +1,60 @@
+---
+title: "Best 7 News API Data Feeds"
+type: source
+tags: [news-api, data-feed, ai, 新闻聚合]
+date: 2025-03-11
+---
+
+## Source File
+- [[raw/AI/Best 7 news API data feeds - AI News.md]]
+
+## Summary
+- 核心主题：7 款主流新闻 API 数据源全面评测
+- 问题域：如何为 AI 应用选择合适的新闻数据源
+- 方法/机制：对比维度（覆盖范围/价格/适用场景/核心能力）
+- 结论/价值：不同场景对应不同 API——金融选 Bloomberg/FT、舆情选 Webz.io/Opoint、小型应用选 GNews/Mediastack
+
+## Key Claims
+- Webz.io 是覆盖最全面的新闻 API，同时覆盖 surface web + deep web + dark web，金融/网安/风控场景首选
+- GNews API 轻量低价，适合小型应用和初创公司，支持多语言本地化
+- The Guardian API 专注高质量编辑内容，适合研究和内容平台
+- Bloomberg API + Financial Times API 面向机构级金融分析，FT 提供经济报告，Bloomberg 提供实时市场数据
+- Opoint 擅长舆情监控和情感分析，PR/营销/品牌监测首选
+- Mediastack 7000+ 来源，免费套餐可用，最适合开发者构建多来源聚合应用
+
+## Key Quotes
+> "News API data feeds are platforms that aggregate, organise, and deliver structured news data from multiple sources." — AI News 概述
+
+## Key Concepts
+- [[News API]]：标准化 HTTP API 接口获取新闻数据，返回 JSON/XML 格式结构化数据
+- [[新闻聚合]]：将多个来源新闻整合为统一格式，Eliminate 人工采集成本
+- [[舆情监控]]：实时跟踪品牌/竞品媒体提及和情感倾向
+- [[金融情报]]：实时分析市场动向新闻，驱动投资决策
+
+## Key Entities
+- [[Webz.io]]：全覆盖新闻 API（surface+deep+dark web）
+- [[GNews API]]：轻量低价新闻 API
+- [[The Guardian API]]：高质量编辑内容新闻源
+- [[Bloomberg API]]：机构级金融数据 API
+- [[Financial Times API]]：专业财经分析与经济报告
+- [[Opoint]]：舆情监控与情感分析平台
+- [[Mediastack API]]：7000+ 来源可扩展新闻 API
+
+## Connections
+- [[News API]] ← 分类产品 ← [[Webz.io]] / [[GNews API]] / [[The Guardian API]] / [[Bloomberg API]] / [[Financial Times API]] / [[Opoint]] / [[Mediastack API]]
+- [[舆情监控]] ← 工具 ← [[Opoint]]
+- [[金融情报]] ← 工具 ← [[Bloomberg API]] / [[Financial Times API]]
+
+## Use Cases
+| 场景 | 推荐 API |
+|------|---------|
+| 金融分析与市场数据 | Bloomberg API / Financial Times API |
+| 舆情监控与品牌追踪 | Opoint / Webz.io |
+| 网安与风控情报 | Webz.io |
+| 小型应用与本地化 | GNews API / Mediastack |
+| 高质量编辑内容 | The Guardian API |
+| AI 训练数据获取 | Mediastack（来源多+价格灵活） |
+
+## Contradictions
+- Webz.io vs Mediastack：Webz.io 覆盖最广但价格高；Mediastack 来源多且有免费套餐，但深度不如 Webz.io
+- Bloomberg vs Financial Times：Blochberg 偏实时市场数据，FT 偏深度经济报告，可互补

wiki/sources/Build-Your-Own-X-从零构建技术栈.md

@@ -0,0 +1,38 @@
+---
+title: "Build Your Own X — 从零构建技术的编程学习资源集"
+type: source
+tags: [learning, programming, github, tutorial, build-from-scratch]
+date: 2026-01-01
+---
+
+## Source File
+- [[raw/AI/codecrafters-iobuild-your-own-x Master programming by recreating your favorite technologies from scratch.md]]
+
+## Summary
+- 核心主题：GitHub 编程学习资源集，通过从零重建流行技术来掌握编程
+- 问题域：如何通过动手重建而非被动阅读来深度理解技术原理
+- 方法/机制：收录 25 个技术领域的分步骤指南，每指南附多语言实现教程
+- 结论/价值："What I cannot create, I do not understand"——费曼学习法的技术领域实践
+
+## Key Claims
+- 重建流行技术是深度掌握编程的最有效方法
+- 分步骤指南覆盖 25 个技术领域，从 Web 服务器到神经网络到操作系统
+- 每个领域提供多语言实现（Python/JavaScript/Go/C++/Rust 等），学习者可选择熟悉语言切入
+- codecrafters.io 提供在线编程挑战平台
+
+## Key Quotes
+> "What I cannot create, I do not understand." — Richard Feynman
+
+## Key Concepts
+- [[费曼学习法]]：不能创造即不能真正理解，动手重建是最高效的深度学习路径
+- [[Vibe Coding]]：BYOX 与 Vibe Coding 均强调动手实践，BYOX 是更激进的"完全从零"版本
+
+## Key Entities
+- [[CodeCrafters]]：build-your-own-x 的维护方，提供在线编程挑战平台
+- [[Daniel Stefanovic]]：build-your-own-x 项目创始人
+- [[Richard Feynman]]：费曼学习法起源
+
+## Connections
+- [[Build-Your-Own-X-从零构建技术栈]] ← enables ← [[Vibe Coding]]（BYOX 是 Vibe Coding 的底层实践）
+- [[Build-Your-Own-X-从零构建技术栈]] ← implements ← [[费曼学习法]]
+- [[Vibe-Kanban-OpenCode-Ubuntu-Server安装管理指南]] ← related ← [[Vibe Coding]]（Vibe Coding 工具链）

wiki/sources/Clonezilla对Ubuntu-Server进行全盘镜像备份.md

@@ -0,0 +1,45 @@
+---
+title: "Clonezilla对Ubuntu Server进行全盘镜像备份"
+type: source
+tags: [clonezilla, ubuntu, backup, nas, disaster-recovery]
+date: 2025-12-20
+---
+
+## Source File
+- [[raw/Home Office/Clonezilla对Ubuntu Server进行全盘镜像备份.md]]
+
+## Summary
+- 核心主题：使用 Clonezilla 对 Ubuntu Server 进行全盘镜像备份到 Synology NAS
+- 问题域：物理机 Ubuntu Server 如何在不停机的情况下做完整磁盘备份并支持灾难恢复
+- 方法/机制：Rufus 制作 USB 启动盘 → Clonezilla live NFS 挂载 NAS → savedisk 生成镜像文件
+- 结论/价值：Clonezilla 等同于企业级 Ghost，支持增量镜像差异备份，NFS 作为备份目标实现集中存储
+
+## Key Claims
+- Clonezilla 支持两种模式：device-image（磁盘备份为镜像文件）和直接克隆（磁盘对磁盘）
+- NFS 是连接 NAS 备份的最佳协议，Linux 兼容性优于 SMB/CIFS
+- Rufus 制作 Clonezilla USB 启动盘：ISO 镜像模式（非 DD 模式），GPT 分区方案（UEFI 非 CSM）
+- 备份参数：-z1p 高压缩率（节省 NAS 空间），-sfsck 跳过文件系统检查（节省时间）
+- 灾难恢复路径：与备份流程相同，仅在"具体操作"中选择 restoredisk 覆盖目标磁盘
+
+## Key Quotes
+> "蓝色 U盘 32G 安装了 Clonezilla" — 作者自用 Clonezilla 启动盘配置
+
+## Key Concepts
+- [[磁盘镜像备份]]：将整个磁盘内容打包为单个镜像文件存储，支持完整恢复
+- [[Clonezilla]]：开源磁盘克隆/镜像工具，支持备份到 NFS/SMB/USB 等多种存储后端
+- [[灾难恢复]]：硬盘损坏后通过镜像文件还原系统，destoredisk 完成后系统即刻复活
+- [[NFS 挂载]]：Network File System 协议挂载 NAS 共享目录作为备份目标
+- [[Rufus]]：快速制作 USB 启动盘工具，支持 ISO 写入和 FAT32 格式化
+
+## Key Entities
+- [[Rufus]]：USB 启动盘制作工具，将 Clonezilla ISO 写入 U 盘
+- [[Synology NAS]]：备份目标存储，NFS 服务器端，提供 /volume2/backups 共享目录
+- [[NFS]]：Network File System，Linux 原生网络文件系统协议，Clonezilla NAS 备份推荐协议
+- [[Ubuntu Server]]：备份源系统，HP ZBook 工作站上运行的 Server 版本
+
+## Connections
+- [[rsync增量备份]] ← complements ← [[磁盘镜像备份]]（全量 vs 增量互补）
+- [[NFS永久挂载]] ← is_similar_to ← [[NFS 挂载]]
+- [[Synology NAS]] ← provides ← [[NFS]]
+
+## Contradictions

wiki/sources/GitHub-上-5000-人收藏的-Vibe-Coding-神级指南。.md

@@ -0,0 +1,50 @@
+---
+title: "GitHub 上 5000 人收藏的 Vibe Coding 神级指南（中文版）"
+type: source
+tags: [vibe-coding, AI编程, github, 中文资源]
+date: 2025-12-30
+---
+
+## Source File
+- [[raw/AI/GitHub 上 5000 人收藏的 Vibe Coding 神级指南。.md]]
+
+## Summary
+- 核心主题：vibe-coding-cn 中文开源项目——面向中文开发者的 Vibe Coding 资源库与工作站
+- 问题域：中文开发者难以系统性获取 Vibe Coding 方法论和工具链资源
+- 方法/机制：整合 AI 编程资源、提示词库、学习路径和实操流程，形成可操作的工作站
+- 结论/价值：Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行；规划就是一切，防止 AI 理解偏差导致项目逻辑混乱
+
+## Key Claims
+- Vibe Coding 核心公式：规划驱动 + 上下文固定 + AI 结对执行，让想法到可维护代码成为可审计流水线
+- Vibe Coding 本质：开发者做导演，AI 做执行，专注于产品逻辑/用户流程/审美/交互把握
+- Karpathy 原话："我几乎不写代码了，我只负责调整氛围（Vibe），代码会自动长出来"
+- vibe-coding-cn = 中文开发者 Vibe Coding 资源库，提供方法论+工具链+提示词库+开发经验全链路覆盖
+- 工具链推荐：Cursor + Claude Opus 4.5-xhigh，直接可用无需筛选
+- 提示词库覆盖：需求澄清/系统架构设计/分步执行/自测全链路，支持 Excel 与 Markdown 互转
+
+## Key Quotes
+> "Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行，让『从想法到可维护代码』变成一条可审计的流水线，而不是一团无法迭代的巨石文件。" — vibe-coding-cn 定义
+
+> "我几乎不写代码了，我只负责调整氛围（Vibe），代码会自动长出来。" — Andrej Karpathy
+
+## Key Concepts
+- [[Vibe Coding]]：氛围编程，开发者做导演而非码农，专注于规划和审美而非逐行代码
+- [[规划驱动]]：Vibe Coding 第一原则，AI 写代码前必须有清晰技术选型、实施规划和模块化设计
+- [[上下文固定]]：Vibe Coding 第二原则，通过 .cursorrules 等文件约束 AI 行为边界
+- [[AI 结对执行]]：Vibe Coding 第三原则，AI 作为 pair programmer 替代传统 IDE
+- [[vibe-coding-cn]]：中文开发者 Vibe Coding 开源资源库，GitHub 仓库 tukuai/vibe-coding-cn
+
+## Key Entities
+- [[Karpathy]]：Vibe Coding 概念提出者，OpenAI/特斯拉前研究科学家
+- [[Cursor]]：AI 代码编辑器，Vibe Coding 推荐首选 IDE
+- [[Windsurf]]：AI 编程 IDE，Vibe Coding 工具选项之一
+- [[Trae]]：AI 编程 IDE，Vibe Coding 工具选项之一
+- [[vibe-coding-cn]]：中文 Vibe Coding 开源资源库，GitHub tukuai/vibe-coding-cn
+
+## Connections
+- [[Vibe Coding]] ← is_extended_by ← [[vibe-coding-cn]]
+- [[Cursor]] ← is_used_in ← [[Vibe Coding]]
+- [[项目规则]] ← enables ← [[上下文固定]]
+- [[vibe-coding-cn]] ← aggregates ← [[Prompt工程]]
+
+## Contradictions

wiki/sources/How-Can-a-Multi-Cloud-Strategy-Transform-Your-Business-ROI.md

@@ -0,0 +1,62 @@
+---
+title: "How Can a Multi Cloud Strategy Transform Your Business ROI?"
+type: source
+tags: [cloud, strategy, multi-cloud, ROI]
+date: 2024-12-24
+---
+
+## Source File
+- [[raw/Cloud & DevOps/How Can a Multi Cloud Strategy Transform Your Business ROI.md]]
+
+## Summary
+- 核心主题：多云策略（Multi-Cloud）如何提升业务 ROI
+- 问题域：单一云厂商依赖导致成本高、弹性差、风险集中
+- 方法/机制：跨 AWS/Azure/GCP 分配工作负载，利用各厂商优势定价和服务能力
+- 结论/价值：多云策略可降低 30% 运营成本，提升韧性、弹性、安全性和创新能力
+
+## Key Claims
+- 78% 采用多云策略的企业将工作负载部署在超过 3 个公有云，以提升敏捷性和成本效益（Virtana）
+- 86% 企业计划在 2024 年底前采用多云策略（New Horizons）
+- 多云策略可为企业降低 30% 运营成本（Forrester）
+- 多云不等于备份策略：真正的价值在于跨厂商性能优化、成本优化和弹性扩展
+- 多云不等于复杂性增加：Kubernetes、Terraform 等工具和治理框架可简化管理
+
+## Key Quotes
+> "You can leverage computing from AWS, AI tools from Google, and store your data in Microsoft Azure without fearing vendor lock-in yet enjoy high availability." — 多云核心价值描述
+
+## Key Concepts
+- [[多云策略]]：跨多个公有云（AWS/Azure/GCP）分配工作负载，利用各厂商差异化优势
+- [[供应商锁定规避]]：通过多厂商策略避免单一云厂商绑定，保持谈判议价能力
+- [[多云治理]]：跨云资源管理、安全策略、成本控制和合规性的统一框架
+- [[多云成本优化]]：利用不同厂商的差异化定价模型降低整体云支出
+- [[云弹性扩展]]：跨多个云动态调配资源，应对突发流量峰值
+- [[数据主权合规]]：选择符合区域法规的云厂商存储和处理数据
+
+## Key Entities
+- [[AWS]]：多云策略中的基础设施和通用计算主力厂商
+- [[Azure]]：多云策略中的企业级 AI 和数据服务厂商
+- [[GCP]]：多云策略中的机器学习和分析工具厂商
+- [[Kubernetes]]：多云环境容器编排和 workload 统一管理工具
+- [[Terraform]]：IaC 工具，跨云基础设施声明式管理
+- [[CloudHealth]]：多云成本和性能监控工具（原文提及）
+- [[Datadog]]：跨云统一可观测性监控平台
+
+## Connections
+- [[Cloud Operating Model]] ← is_applied_to ← [[多云策略]]
+- [[DevOps成熟度模型]] ← enables ← [[多云治理]]
+- [[多云成本优化]] ← depends_on ← [[FinOps]]
+- [[Kubernetes]] ← enables ← [[多云治理]]
+- [[Terraform]] ← enables ← [[多云治理]]
+
+## Industry Use Cases
+- **电商**：黑五/网一高峰期跨云弹性扩展，保障高可用和低延迟
+- **医疗**：符合 HIPAA 区域数据主权要求，分布式存储降低单云依赖成本
+- **金融**：利用不同厂商最优安全特性，满足严格合规要求同时最大化 ROI
+
+## Implementation Steps
+1. 评估需求：明确目标（韧性/成本优化/扩展）、预算分析、现有工作负载梳理
+2. 选择厂商：AWS 做基础设施、Google Cloud 做分析、Azure 做 AI，根据场景匹配
+3. 集成管理：采用 Kubernetes/Terraform 统一编排，确保数据互操作性
+4. 监控优化：CloudHealth/Datadog 持续跟踪性能和成本，动态调整资源分配
+
+## Contradictions

wiki/sources/If-you-have-multiple-interests-do-not-waste-the-next-2-3-years.md

@@ -0,0 +1,58 @@
+---
+title: "If You Have Multiple Interests, Do Not Waste the Next 2-3 Years"
+type: source
+tags: [ai, entrepreneurship, generalist, content, self-education]
+date: 2025-04-15
+---
+
+## Source File
+- [[raw/AI/If you have multiple interests, do not waste the next 2-3 years  如果你有多项兴趣爱好，不要浪费接下来的两三年时间。.md]]
+
+## Summary
+- 核心主题：在 AI 时代，拥有多重兴趣的通才（Generalist）比专才（Specialist）更具优势；多兴趣交叉创造独特视角是最终的护城河
+- 问题域：工业时代专业化分工思维使人沦为螺丝钉，社会对"专注单一技能"的迷信阻碍个人发展
+- 方法/机制：三要素框架（自学 Self-education + 自利 Self-interest + 自立 Self-sufficiency）→ 通才自然涌现；内容创作作为收入载体；系统经济时代系统 > 产品
+- 结论/价值：AI 时代是第二次文艺复兴，多兴趣通才拥有前所未有机遇；品牌即环境，内容即新颖视角，系统即产品
+
+## Key Claims
+- 专业化导致愚蠢和依赖，通才（Generalist）才能实现主权（Self-sufficiency）和适应力
+- 第二次文艺复兴已到来：印刷术降低知识成本 → 个人可追求多领域精通；AI 降低执行成本 → 个人可将兴趣转化为产品
+- 最终护城河是独特视角（Perspective），这来自独一无二的人生经历，无法被复制
+- 三要素：Self-education（引擎）+ Self-interest（指南针）+ Self-sufficiency（基石）
+- 系统经济时代，人们要的是你的解决方案而非通用解决方案；2 Hour Writer 系统即产品
+
+## Key Quotes
+> "The man whose whole life is spent in performing a few simple operations... generally becomes as stupid and ignorant as it is possible for a human creature to become." — Adam Smith
+
+> "Your edge lies more in intersection than it does in expertise." — Dan Koe
+
+> "Your brand is your story." — Dan Koe
+
+> "Content is novel perspectives." — Dan Koe
+
+> "Systems are the new product." — Dan Koe
+
+## Key Concepts
+- [[超级通才]]：拥有多领域交叉能力的个体，AI 时代比专才更具主权和适应力，对应 [[超级个体]] 但更强调知识广度
+- [[自教育]]：自主定向学习以获得与传统教育不同的结果，是通才养成的引擎
+- [[自利]]：追随自身利益而非被组织利益裹挟，是通才的指南针
+- [[自立自强]]：拒绝外包判断力、学习力和自主性，是通才的基石
+- [[创意博物馆]]：Idea Museum，创作素材库，通过 ruthless curation 积累高密度创意
+- [[系统经济]]：Systems Economy，解决方案的价值在于系统本身而非产品功能，2HW 系统即产品
+- [[内容创意密度]]：Idea Density，内容质量的衡量标准 = Performance（受众关注）× Excitement（个人热情）
+
+## Key Entities
+- [[Dan Koe]]（TheDankoe）：多兴趣创业者，内容创作者，2 Hour Writer 系统开发者，Eden 软件创始人
+- [[Adam Smith]]：《国富论》作者，专业化分工理论的提出者，"螺丝钉"批评的引用来源
+- [[Leonardo da Vinci]]：文艺复兴通才典范，绘画/雕塑/工程/解剖/战争机器/人体绘图跨界
+- [[Jordan Peterson]]：《12 rules for life》作者，作为通才不追随内容潮流而是用思想质量建立影响力
+
+## Connections
+- [[超级个体]] ← extends ← [[超级通才]]，超级通才是超级个体在知识广度上的具体表达
+- [[品味]] ← relates_to ← [[独特视角]]，两者均强调 AI 无法复制的判断力护城河
+- [[死亡过滤器]] ← relates_to ← [[自利]]，两者均帮助筛选真正值得投入的方向
+- [[内容矩阵]] ← extends ← [[创意博物馆]]，创意博物馆是内容矩阵的输入端
+- [[反向金字塔]] ← relates_to ← [[系统经济]]，反向金字塔分发是系统执行的体现
+
+## Contradictions
+- 与 [[一人公司]] 框架：本文强调"不要成为 YouTuber/个人品牌/网红，要做自己"；一人公司框架强调需要关注（Attention）才能变现。冲突点：追求纯粹 vs 追求分发。当前观点：两者本质一致——通过真实自我吸引精准受众，只是叙事风格不同。

wiki/sources/Multi-Agent-Specialized-Team-Solo-Founder-Setup.md

@@ -1,44 +1,37 @@
 ---
-title: "Multi-Agent Specialized Team (Solo Founder Setup)"
+title: "Multi-Agent Specialized Team（Solo Founder 模式）"
 type: source
-tags: [openclaw, multi-agent, telegram, solo-founder, workflow]
-date: 2026-04-15
+tags: [multi-agent, openclaw, solo-founder, team, telegram]
+date: 2026-04-13
 ---
 
 ## Source File
 - [[raw/Agent/usecases/multi-agent-team.md]]
 
 ## Summary
-- 核心主题：Solo founder 通过多 Agent 虚拟团队实现 24/7 全天候工作能力
-- 问题域：单一 Agent 无法高效处理多领域工作；Context 切换破坏深度工作；知识孤岛导致洞察无法跨 Agent 流动
-- 方法/机制：专业化 Agent（各角色独立模型/人格）+ 共享记忆（GOALS.md/DECISIONS.md）+ 私有上下文 + Telegram 统一入口 + 定时主动任务
-- 结论/价值：从 2 Agent 开始按瓶颈扩展；定时任务是价值飞轮；团队协作产生真正价值
+- 核心主题：Solo Founder 如何通过多 Agent 专精团队实现 24/7 全天候工作能力
+- 问题域：单一 Agent 无法同时擅长战略/开发/营销/销售；角色切换破坏深度工作
+- 方法/机制：每个 Agent 独立角色+人格+模型，通过共享内存协作，Telegram 统一入口
+- 结论/价值：从"管理一个工具"到"指挥一个团队"的范式转变，Agent 主动推送而非被动响应
 
 ## Key Claims
-- 单一 Agent 无法高效处理战略/开发/营销/分析多领域，context window 快速填满
-- 共享记忆（GOALS.md/DECISIONS.md）+ 私有上下文是多 Agent 协作核心
-- 所有 Agent 通过同一 Telegram 群聊控制，各自只响应被 @ 的消息
-- 定时主动任务（早会摘要/指标推送/内容创意）是价值飞轮
-- 从 2 Agent 开始，不是一上来建 4 个团队
-- [[Trebuh]] 的实践：4 个 Agent（Milo/Josh/Marketing/Dev）+ Telegram + VPS，描述为"真正的 24/7 小团队"
+- 2 Agent 起步（Lead + 1 专精），按瓶颈扩展，而非一上来建 4 个团队
+- 共享内存（GOALS.md/DECISIONS.md/PROJECT_STATUS.md）+ 私有上下文是关键组合
+- 定时主动任务（早会摘要/指标推送/内容创意）是真正的价值杠杆
+- Telegram 单群聊入口 + @AgentName 路由 + 无@默认 Lead
 
 ## Key Quotes
-> "Start with 2, not 4: Begin with a lead + one specialist, then add agents as you identify bottlenecks" — 实践总结
-> "The real value emerges when agents proactively surface insights, not just when you ask" — 定时任务价值
-> "Personality matters more than you'd think: Giving agents distinct names and communication styles makes it natural to talk to your team" — Trebuh
-
-## Key Concepts
-- [[共享记忆模式]]：GOALS.md（OKR与优先级，所有Agent可读）+ DECISIONS.md（关键决策日志）+ PROJECT_STATUS.md（当前项目状态）
-- [[定时主动任务]]：Agent 主动在后台工作并推送结果，而非等待用户请求
-- [[Multi-Agent Hierarchy]]：团队层级架构，Lead Agent 协调 + Specialist Agent 执行
-- [[Telegram路由]]：单群聊入口 + @AgentName 路由 + 无@默认 Lead Agent
+> "A real small team available 24/7." — [[Trebuh]] 描述其 4 Agent 团队
 
 ## Key Entities
-- [[Trebuh]]：Solo founder，4 Agent 团队实践者，通过 X 分享案例
-- [[OpenClaw]]：多 Agent 管理平台，支持 sessions_spawn/sessions_send/Telegram skill
+- [[Trebuh]]：Solo founder，4 Agent 团队（Milo/Josh/Marketing/Dev）+ Telegram + VPS 实践者
+- [[OpenClaw]]：多 Agent 协作框架，支持 sessions_spawn/sessions_send/共享文件系统
+- [[Claude Code]]：深度代码任务执行（Agent 模式）
+- [[Telegram]]：统一控制平面，单群聊入口实现多 Agent 路由
 
 ## Connections
-- [[Trebuh]] ← 实践者 ← [[Multi-Agent Specialized Team]]
-- [[OpenClaw]] ← 平台 ← [[Multi-Agent Specialized Team]]
-- [[共享记忆模式]] ← 核心机制 ← [[Multi-Agent Specialized Team]]
-- [[定时主动任务]] ← 价值飞轮 ← [[Multi-Agent Specialized Team]]
+- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← implements ← [[Multi-Agent Hierarchy]]（Supervisor=Lead，Worker=专精 Agent）
+- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← shares_pattern ← [[Autonomous-Project-Management]]（共享状态协调模式）
+- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← extends ← [[Multi-Agent-System-Reliability-Alex-Ewerlof]]（Hierarchy 模式的 OpenClaw 具体实践）
+- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← uses ← [[共享内存模式]]（GOALS.md/DECISIONS.md/PROJECT_STATUS.md）
+- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← enables ← [[定时主动任务]]（Agent 主动后台工作推送结果）

wiki/sources/Multi-Agent-System-Reliability-Alex-Ewerlof.md

@@ -0,0 +1,53 @@
+---
+title: "Multi-Agent System Reliability（Alex Ewerlöf）"
+type: source
+tags: [multi-agent, reliability, architecture, llm]
+date: 2026-04-13
+---
+
+## Source File
+- [[raw/AI/Multi-Agent System Reliability.md]]
+
+## Summary
+- 核心主题：多智能体系统的可靠性架构模式
+- 问题域：LLM 作为不可靠组件，如何构建企业级可靠的多智能体系统
+- 方法/机制：4种架构模式（Hierarchy/Consensus/Adversarial Debate/Knock-out）+ 可靠性工程原理
+- 结论/价值：将 LLMs 视为分布式系统中不可靠组件，而非拟人化智能体；通过架构约束而非"小心谨慎"来保证正确性
+
+## Key Claims
+- LLM 本质随机（stochastic），单次回答仅代表一种概率分布，幻觉率约 20%
+- 将 LLM 拟人化（给钱/威胁/情感操控）仅改变 token 预测分布，不产生真正的动机
+- 3 个模型同时产生完全相同谎言的概率为 0.8%（0.2³），多数投票可有效消除幻觉噪声
+- 从"AI 原型"到"企业级 AI"的转变核心：停止要求模型"小心"，改为强制其"正确"
+
+## Key Quotes
+> "We don't need AI that 'cares.' We need AI that is constrained, verified, pruned, and challenged." — [[Alex Ewerlöf]]
+> "Don't anthropomorphize LLMs! Find a way to piggy back on their human-corpus training while being aware of their non-biological differences." — [[Alex Ewerlöf]]
+> "If you threaten a model too hard, it might just lie to make you happy. This is Sycophancy." — [[Alex Ewerlöf]]
+
+## Key Concepts
+- [[Multi-Agent Hierarchy]]：Supervisor（规划器）+ Worker（工作者）+ Validator（验证器）的三角色顺序协作
+- [[Multi-Agent Consensus]]：N 个模型对同一任务独立响应，多数票消除随机噪声（0.8% 相同谎言概率）
+- [[Multi-Agent Adversarial Debate]]：Generator + Critic + Judge 三方对抗，Truth survives the fight
+- [[Multi-Agent Knock-out]]：遗传算法启发的适应度淘汰制，最差代理被淘汰（cattle not pets）
+- [[LLM Sycophancy]]：模型过度迎合用户意图而撒谎的现象，多数投票可缓解
+
+## Key Entities
+- [[Alex Ewerlöf]]：Senior Staff Engineer，KTH 系统工程硕士，专注可靠性工程与 LLM 应用（2023年起）
+- [[Groupthink]]：共识模式中的反馈回路风险，导致从众效应放大错误
+- [[Genetic Algorithm]]：Knock-out 模式理论基础，适应度函数评估并淘汰低质量个体
+
+## Connections
+- [[Multi-Agent-System-Reliability-Alex-Ewerlof]] ← foundational_theory ← [[Multi-Agent Hierarchy]]
+- [[Multi-Agent-System-Reliability-Alex-Ewerlof]] ← foundational_theory ← [[Multi-Agent Consensus]]
+- [[Multi-Agent-System-Reliability-Alex-Ewerlof]] ← foundational_theory ← [[Multi-Agent Adversarial Debate]]
+- [[Multi-Agent-System-Reliability-Alex-Ewerlof]] ← foundational_theory ← [[Multi-Agent Knock-out]]
+- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← extends ← [[Multi-Agent-System-Reliability-Alex-Ewerlof]]（Hierarchy 模式的具体实践）
+- [[Autonomous-Project-Management]] ← implements ← [[Multi-Agent Hierarchy]]（STATE.yaml 替代中央验证器）
+- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← shares_pattern ← [[Autonomous-Project-Management]]（均依赖共享状态协调）
+
+## Contradictions
+- 与纯 LLM 原型思维：
+  - 冲突点：认为"小心提示"可解决幻觉
+  - 当前观点：架构约束（验证器/投票/淘汰）才是可靠性来源
+  - 对方观点：通过情感化 prompt（给钱/威胁）激励模型正确输出

wiki/sources/MySQL-MariaDB-数据库详细信息.md

@@ -0,0 +1,56 @@
+---
+title: "MySQL MariaDB 数据库详细信息"
+type: source
+tags: [database, mariadb, mysql, nas, synology]
+date: 2026-04-15
+---
+
+## Source File
+- [[raw/Home Office/MySQL MariaDB 数据库详细信息.md]]
+
+## Summary
+- 核心主题：Synology NAS Docker MariaDB 10.11 内网/公网访问配置与用户权限管理
+- 问题域：NAS 部署的 MariaDB 仅允许 localhost 访问，远程连接需手动创建用户
+- 方法/机制：socket 本地登录 → CREATE USER → GRANT ALL PRIVILEGES → FLUSH PRIVILEGES
+- 结论/价值：建立 NAS 统一数据库层，支持公网域名 mysql.ishenwei.online:63307 访问
+
+## Key Claims
+- Synology Docker MariaDB 默认只允许 root@localhost 连接，不存在 root@% 或任何远程用户
+- 远程连接失败的根因是缺少 host/user 组合与对应权限
+- 创建 'shenwei'@'%' 可实现任意 IP 的远程访问，但密码强度必须符合 MariaDB 策略要求
+
+## Key Quotes
+> "进入 MariaDB（使用 socket 登陆）：sudo mysql -u root -p -S /run/mysqld/mysqld10.sock" — 本地 socket 登录方式
+> "CREATE USER 'shenwei'@'%' IDENTIFIED BY '!Abcde12345'; GRANT ALL PRIVILEGES ON *.* TO 'shenwei'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES;" — 远程访问用户创建标准 SQL
+
+## Key Concepts
+- [[Socket登录]]：通过本地 socket 文件 /run/mysqld/mysqld10.sock 连接 MariaDB，无需 TCP 端口认证
+- [[MariaDB用户权限模型]]：host + user 组合决定访问权限，localhost 表示仅本机，% 表示任意 IP
+- [[FLUSH PRIVILEGES]]：将内存中的权限表重新读取到内存，使权限变更立即生效
+
+## Key Entities
+- [[Synology NAS]]：硬件平台（192.168.3.17），MariaDB 10.11.6 运行在 Docker 容器内
+- [[MariaDB]]：MySQL 分支数据库，版本 10.11.6，端口 3307（内网）、63307（公网）
+- [[Cloudflare]]：域名 mysql.ishenwei.online DNS 解析层
+
+## Connections
+- [[MySQL MariaDB 数据库详细信息]] ← runs_on ← [[Synology NAS]]
+- [[MySQL MariaDB 数据库详细信息]] ← accessible_via ← [[Cloudflare]]（公网域名反向代理）
+
+## Contradictions
+
+## Internal Access Credentials
+| 项目 | 值 |
+|------|-----|
+| IP | 192.168.3.17 |
+| Port | 3307 |
+| Username | shenwei / root |
+| Password | !Abcde12345 |
+
+## Public Access Credentials
+| 项目 | 值 |
+|------|-----|
+| Domain | mysql.ishenwei.online |
+| Port | 63307 |
+| Username | shenwei / root |
+| Password | !Abcde12345 |

wiki/sources/N8N Full Tutorial Building AI Agents in 2025 for Beginners.md

@@ -0,0 +1,40 @@
+---
+title: "N8N Full Tutorial - Building AI Agents in 2025 for Beginners"
+type: source
+tags: [n8n, ai-agent, 工作流, 教程]
+date: 2025-03-06
+---
+
+## Source File
+- [[raw/Agent/n8n full tutorial building AI agents in 2025 for Beginners!.md]]
+
+## Summary
+- 核心主题：N8N 平台构建 AI Agent 入门教程
+- 问题域：Workflow 和 Agent 的区别，N8N 5 类节点，Agent 中 Memory 机制
+- 方法/机制：N8N 可视化节点编排，Trigger → Action/Utility/Code/AI Agent 节点
+- 结论/价值：Agent = LLM 动态选择工具 + Memory 保持上下文；Workflow = 预定义自动化
+
+## Key Claims
+- Workflow vs Agent：Workflow 是预定义自动化（固定输出），Agent 由 LLM 动态决定工具调用（适应用户输入）
+- N8N 5 类节点：Trigger（触发器）、Action（操作）、Utility（工具）、Code（代码）、Advanced AI（AI Agent）
+- Memory 是 AI Agent 与用户对话连贯性的关键，保留上下文使响应更相关
+- Airtable 可作为工具接入 N8N Agent，实现库存查询和更新
+- 多 Agent 串联和工作流链式调用可构建复杂自动化系统
+
+## Key Concepts
+- [[Agentic System]]：Agent + Workflow 的组合，Agent 动态选择工具，Workflow 预定义执行路径
+- [[N8N Workflow]]：N8N 可视化工作流，Trigger → 多节点串联
+- [[Memory in AI Agent]]：Agent 保持对话上下文的机制，使多轮交互连贯
+- [[Workflow vs Agent]]：固定自动化 vs LLM 动态决策的本质区别
+
+## Key Entities
+- [[Airtable]]：在线数据库，可作为 N8N Agent 工具接入，实现库存管理
+
+## Connections
+- [[n8n]] ← 工具 ← [[N8N Workflow]]
+- [[n8n]] ← 工具 ← [[Agentic System]]
+- [[Agentic System]] ← 包含 ← [[Workflow vs Agent]] + [[Memory in AI Agent]]
+- [[Airtable]] ← 工具 ← [[Memory in AI Agent]]
+
+## Contradictions
+- 与 [[n8n Docker 安装与更新]]：后者专注部署安装，本文档专注工作流构建方法论

wiki/sources/Nano-Banana-提示词框架.md

@@ -0,0 +1,43 @@
+---
+title: "Nano Banana 结构化提示词框架"
+type: source
+tags: [ai, prompt, image-generation, google]
+date: 2025-03-15
+---
+
+## Source File
+- [[raw/AI/Nano Banana 提示词框架.md]]
+
+## Summary
+- 核心主题：Google 发布的图像生成结构化提示词框架，通过 9 个标准化字段将创意描述转化为机器可执行参数
+- 问题域：自然语言描述图像存在歧义和模糊性，AI 生成结果与预期不符
+- 方法/机制：9 层结构化字段（Shot/Subject/Environment/Lighting/Camera/ColorGrade/Style/Quality/Negatives）；物件描述框架与人物描述框架共用结构，subject 字段内容不同
+- 结论/价值：结构化提示词大幅提升 AI 图像生成的可控性和一致性，降低迭代成本
+
+## Key Claims
+- Nano Banana 框架将图像生成提示词标准化为 9 个字段，每个字段控制特定维度
+- negatives（负向提示词）是质量控制关键字段，明确排除不需要的特征
+- camera 字段提供电影级构图控制（focal_length/aperture/angle），实现专业级运镜效果
+- 物件描述框架与人物描述框架核心结构一致，区别仅在 subject 字段内容（item/materials/details/condition vs age/appearance/pose）
+
+## Key Quotes
+> "negatives": "no scratches, no dust, no logos or brand names, no human hands, blurry watch face, unrealistic lighting." — 示例中的负向提示词
+
+## Key Concepts
+- [[Nano Banana]]：Google 发布的结构化图像生成提示词框架，9 层标准化字段设计
+- [[物件描述框架]]：Nano Banana 中用于描述物品的字段结构（item/materials/details/condition）
+- [[人物描述框架]]：Nano Banana 中用于描述人物的字段结构（age/appearance/pose）
+- [[负向提示词]]：Negatives，通过明确排除不需要的特征来提升生成质量
+- [[运镜控制]]：Camera 参数控制焦距/光圈/角度，实现电影级构图
+
+## Key Entities
+- [[Google]]：Nano Banana 框架的发布方，AI 图像生成工具的技术引领者
+
+## Connections
+- [[AI生图]] ← uses ← [[Nano Banana]]，Nano Banana 是 AI 生图的结构化提示词方法论
+- [[Prompt工程]] ← extends ← [[Nano Banana]]，Nano Banana 是 Prompt工程 在图像生成领域的具体实现
+- [[Never write another prompt]] ← comparable_to ← [[Nano Banana]]，两者都提供结构化提示词能力，但 Nano Banana 专用于图像生成
+- [[主体一致性]] ← relates_to ← [[负向提示词]]，负向提示词有助于维持主体一致性
+
+## Contradictions
+- 与 [[风格迁移]] 概念：Nano Banana 强调精确控制（结构化字段），风格迁移强调美学转化。冲突点：精确控制 vs 美学灵活。当前观点：两者互补——Nano Banana 控制主体和构图，风格迁移处理美学层面的二次加工。

wiki/sources/Never-write-another-prompt.md

@@ -1,35 +1,42 @@
 ---
-title: "Never write another prompt"
+title: "Never Write Another Prompt"
 type: source
-tags: [tutorial, ai-tools, prompt-engineering]
+tags: [ai, prompt, youtube, tool]
 date: 2025-03-06
 ---
 
 ## Source File
-- raw/AI/Never write another prompt.md
+- [[raw/AI/Never write another prompt.md]]
 
 ## Summary
-- 核心主题：AI 提示词生成工具的使用教程
-- 问题域：用户难以编写精确的提示词导致 AI 输出质量不佳
-- 方法/机制：将基础描述转换为结构化详细提示词的自动化工具
-- 结论/价值：无需专业提示词工程背景即可生成高质量提示词，大幅降低使用成本
+- 核心主题：通过提示词生成工具，从简单描述自动生成结构化详细提示词，降低 AI 应用门槛
+- 问题域：用户难以写出精确的提示词，导致 AI 返回质量不佳的响应；专业提示词服务费用高达 $100-500/条
+- 方法/机制：工具将简单描述转化为结构化提示词，支持变量插入和编辑；API Key 认证保护账户安全
+- 结论/价值：提示词工程民主化让任何人都能创建高质量提示词，无需专业技术背景
 
 ## Key Claims
-- 工具可以将简单描述自动转化为详细的结构化提示词
-- 生成一个高质量提示词通常需要 100-500 美元，自动化工具可大幅降低成本
-- 变量功能支持高度定制化
-- 提示词库提供灵感来源，可显著减少创建时间
-- 成功的提示词可保存复用，提高长期效率
+- 提示词工程已从专业技能转变为工具化流程，非技术用户也能生成高质量提示词
+- 变量（Variables）机制使提示词可高度定制，无需重写即可适应不同场景
+- 提示词库（Prompt Libraries）作为灵感来源，显著减少创作时间
+- AI 工具成本极低，用户可创建无限量提示词
+
+## Key Quotes
+> "Prompt engineering is the art of crafting prompts that elicit specific responses from AI. With the introduction of this tool, users no longer need to be experts in this field." — Never Write Another Prompt
+
+> "You become a curator of ideas that people wouldn't even think to ask AI for, and that people would never come across organically." — Demystified principle
 
 ## Key Concepts
-- [[提示词工程自动化]]：将复杂提示词编写过程简化为描述输入
-- [[提示词变量]]：允许用户自定义定制化输出的占位符机制
-- [[提示词库]]：预制提示词的资源集合，用于快速复用
+- [[Prompt工程]]：通过结构化方式构建 AI 提示词以获得最佳响应的技术
+- [[提示词生成工具]]：将简单描述自动转化为结构化提示词的 AI 应用工具
+- [[变量机制]]：提示词中可插入变量以实现模板化和复用的设计模式
 
 ## Key Entities
-- [[Anthropic Console]]：Claude API 管理控制台
-- [[YouTube]]：视频教程发布平台
+- [[Anthropic Claude Console]]：提供 API 访问权限的 Claude 控制台，用于提示词测试
 
 ## Connections
-- [[Prompt工程]] ← 关联 ← 自动化提示词生成降低工程门槛
-- [[Claude-Code]] ← 关联 ← 两者都是提升 AI 使用效率的工具
+- [[Claude Code]] ← uses ← [[Prompt工程]]，Claude Code 通过高质量提示词调用 Claude 模型
+- [[Nano Banana 提示词框架]] ← extends ← [[Prompt工程]]，Nano Banana 是结构化提示词的具体实现
+- [[Agent Skill 设计模式]] ← relates_to ← [[提示词生成工具]]，Skill 是提示词的封装形式
+
+## Contradictions
+- 与 [[流程工程]] 视角：本文将 Prompt工程 工具化；流程工程认为 Prompt 只是表面，SOP 才是核心。冲突点：工具化降低门槛但无法保证一致性；SOP 封装才能保证稳定复用。当前观点：工具化适合个人使用，流程工程适合团队协作。

wiki/sources/TikTok Shop - Apache Superset Dashboard设计思路.md

@@ -0,0 +1,77 @@
+---
+title: "TikTok Shop - Apache Superset Dashboard设计思路"
+type: source
+tags: [tiktok-shop, superset, bi, dashboard, 电商分析]
+date: 2025-03-14
+---
+
+## Source File
+- [[raw/跨境电商/TikTok Shop - Apache Superset Dashboard设计思路.md]]
+
+## Summary
+- 核心主题：TikTok Shop 电商选品数据可视化分析系统设计
+- 问题域：如何将 TikTok Shop 爬取数据转化为可操作的选品决策支持系统
+- 方法/机制：Apache Superset + SQL Views + 多维度 Dashboard 设计
+- 结论/价值：4-Tab 专业选品 Dashboard，覆盖爆品发现、价格带分析、类目机会、店铺监控
+
+## Key Claims
+- TikTok Shop 数据适合做 6 类分析：爆品发现、价格销量关系、类目机会、店铺监控、SKU 库存、评论分析
+- Superset 无法直接解析 JSON，必须通过 SQL View 预处理 JSON_EXTRACT 字段
+- 选品评分模型 = sold×0.4 + rating×12 + rating_count×0.2 + discount_percent×0.5
+- 气泡图（价格×销量×评分）可一眼识别"低价高销量"和"高客单价爆品"
+
+## Key Concepts
+- [[电商选品分析]]：通过销量、评分、折扣多维度评分发现高潜力产品
+- [[Superset Dashboard]]：Apache Superset 可视化分析平台，支持导入 JSON Dashboard 配置
+- [[选品评分模型]]：加权评分公式自动排序推荐产品
+- [[KPI 卡片]]：关键业绩指标数字看板，支持快速筛选热卖/高评分/折扣产品
+- [[价格带分析]]：气泡图/直方图识别最优价格区间
+- [[类目机会分析]]：热力图+箱线图发现蓝海类目
+- [[店铺监控]]：竞争对手销量/评分/上新节奏/价格策略跟踪
+- [[JSON_EXTRACT]]：MySQL JSON 字段预处理，将 JSON 拆分为可计算列
+
+## Key Entities
+- [[TikTok Shop]]：字节跳动旗下电商平台，数据来源
+- [[Apache Superset]]：开源 BI 可视化平台（Airbnb 出品），支持 SQL Dataset、Chart、Dashboard
+- [[TikTok Products]]：核心事实表（products），包含 sold/price/rating/category/store_name/timestamp 等字段
+- [[Product Reviews]]：辅助表，支持评分趋势和 NLP 评论分析
+
+## Connections
+- [[TikTok Shop]] ← 数据源 ← [[电商选品分析]]
+- [[Apache Superset]] ← 可视化工具 ← [[Superset Dashboard]]
+- [[电商选品分析]] ← 支撑 ← [[选品评分模型]]
+- [[选品评分模型]] ← 使用 ← [[TikTok Products]]
+- [[店铺监控]] ← 依赖 ← [[TikTok Products]]
+- [[类目机会分析]] ← 依赖 ← [[JSON_EXTRACT]]
+
+## SQL View
+
+### view_products_cleaned
+```sql
+CREATE OR REPLACE VIEW view_products_cleaned AS
+SELECT
+    id, source_id, title, store_name, category,
+    final_price, initial_price, discount_percent,
+    sold, position, timestamp,
+    JSON_EXTRACT(prodct_rating, '$.rating') AS rating,
+    JSON_EXTRACT(prodct_rating, '$.count') AS rating_count,
+    (final_price * sold) AS total_gmv,
+    (initial_price - final_price) AS discount_amount
+FROM products;
+```
+
+## Dashboard 结构（4 Tab）
+
+| Tab | 名称 | 核心图表 |
+|-----|------|---------|
+| 1 | 爆品雷达 | KPI卡片×6、Top10条形图、类目占比饼图、价格×销量气泡图、评分直方图 |
+| 2 | 类目机会洞察 | 类目销量榜、评分×销量热力图、价格箱线图 |
+| 3 | 店铺监控 | 店铺GMV/销量/评分排名、上新趋势面积图、价格策略对比 |
+| 4 | 评论分析 | 评分趋势折线图、评论数×销量散点图、好评/差评占比 |
+
+## Contradictions
+- 与 [[可自动化可扩展AI增强的电商数据采集与处理系统]]：后者专注爬取+AI处理，本文档专注数据可视化层面，两者构成采集→分析完整管线
+
+## Aliases
+- Superset = Apache Superset
+- TikTok Shop = TikTok电商

wiki/sources/Ubuntu服务器通过rsync实现日常增量备份.md

@@ -0,0 +1,83 @@
+---
+title: "Ubuntu服务器通过rsync实现日常增量备份"
+type: source
+tags: [ubuntu, rsync, backup, nas, nfs, fstab]
+date: 2026-04-15
+---
+
+## Source File
+- [[raw/Home Office/Ubuntu服务器通过rsync实现日常增量备份.md]]
+
+## Summary
+- 核心主题：Ubuntu 服务器通过 rsync 实现对 NAS 的每日增量备份自动化
+- 问题域：已有机房镜像备份（Clonezilla），需补充实时增量数据保护方案
+- 方法/机制：rsync -azR --delete 差异同步，lockfile 防重入，crontab 凌晨自动执行，/etc/fstab 实现 NFS 永久挂载
+- 结论/价值：构建"时间点恢复"能力，NAS 掉线时自动中止备份防止本地硬盘爆满
+
+## Key Claims
+- rsync 在备份正在写入的二进制文件（如 MySQL）时可能导致恢复后无法启动，应先用 mysqldump 导出 SQL 再同步
+- rsync 返回码 23/24 在备份运行中系统时属于正常（部分文件权限问题或源文件消失），重点检查数据是否大部分已同步
+- /etc/fstab 中 _netdev 参数确保网络设备就绪后再执行挂载，防止开机因网络未就绪而挂载失败
+- lockfile 机制防止 rsync_backup.sh 重入，脚本开头检查 lockfile 存在则跳过本次执行
+
+## Key Quotes
+> "rsync -azR --delete — -a 归档模式保留权限属性，-z 压缩传输，-R 相对路径，--delete 删除目标端多余文件" — rsync 核心参数解析
+> "0 3 * * * /usr/local/bin/rsync_backup.sh — 每天凌晨 3 点业务低峰期执行备份" — Crontab 时间配置
+> "192.168.3.17:/volume2/backup /mnt/nas_backup nfs defaults,timeo=900,retrans=5,_netdev 0 0" — NFS /etc/fstab 永久挂载条目
+> "timeo=900（90秒超时），retrans=5（重连5次），_netdev（等待网络就绪）" — NFS 挂载参数详解
+
+## Key Concepts
+- [[rsync]]：远程增量同步工具，通过 Delta-transfer 算法只传输变化部分
+- [[增量备份]]：仅备份自上次备份以来变化的文件，相比全量备份节省存储和带宽
+- [[NFS永久挂载]]：通过 /etc/fstab 将 NFS 挂载配置为系统启动时自动执行
+- [[lockfile]]：防止脚本重入的简单机制，PID 文件 + kill -0 检测进程存活
+- [[Crontab]]：Linux 定时任务调度器，支持分钟级精确控制
+- [[Clonezilla]]：磁盘镜像备份工具，与 rsync 形成"整机镜像 + 增量数据"二级保护
+- [[mysqldump]]：MySQL/MariaDB 逻辑备份工具，在 rsync 之前先导出 SQL 文件保证数据库一致性
+
+## Key Entities
+- [[Synology NAS]]：备份目标端（192.168.3.17:/volume2/backup）
+- [[Ubuntu服务器]]：备份源端，运行 rsync_backup.sh
+- [[Docker]]：数据来源之一（/var/lib/docker/volumes/、/etc/docker/、/home/shenwei/Docker/）
+
+## Connections
+- [[Ubuntu服务器通过rsync实现日常增量备份]] → backups_to → [[Synology NAS]]
+- [[Ubuntu服务器通过rsync实现日常增量备份]] ← runs_on ← [[Ubuntu服务器]]
+- [[Docker]] ← source_data ← [[Ubuntu服务器通过rsync实现日常增量备份]]
+
+## 备份策略矩阵
+
+| 备份类型 | 工具 | 频率 | 覆盖范围 | 恢复时间 |
+|---------|------|------|---------|---------|
+| 整机镜像 | Clonezilla | 按需/周 | 全盘扇区级 | 长（全盘还原） |
+| 增量数据 | rsync | 每日凌晨3点 | 变化文件 | 短（选择性还原） |
+
+## 关键脚本：rsync_backup.sh 防重入逻辑
+```bash
+LOCKFILE="/tmp/rsync_backup.lock"
+if [ -e ${LOCKFILE} ] && kill -0 `cat ${LOCKFILE}`; then
+    echo "备份任务已在运行中，跳过本次执行。"
+    exit
+fi
+echo $$ > ${LOCKFILE}
+trap "rm -f ${LOCKFILE}" EXIT
+```
+
+## NFS 永久挂载验证流程
+```bash
+# 1. 卸载当前挂载
+sudo umount /mnt/nas_backup
+# 2. 模拟开机自动挂载
+sudo mount -a
+# 3. 验证挂载成功
+df -h | grep nas_backup
+```
+
+## Contradictions
+
+## 常见问题排查
+| 问题 | 原因 | 解决方案 |
+|------|------|---------|
+| 重启后挂载失效 | nfs-common 启动慢于 mount -a | systemctl enable remote-fs.target |
+| rsync 返回码 20 | 进程被手动中断（SIGINT/SIGTERM） | 使用 nohup 或 screen 后台运行 |
+| 备份写满本地硬盘 | NAS 掉线时挂载点变成普通目录 | 脚本开头加 mountpoint -q 检查 |

wiki/sources/n8n-Claude-自然语言自动化工作流.md

@@ -0,0 +1,44 @@
+---
+title: "n8n + Claude 通过自然语言自动化工作流"
+type: source
+tags: [n8n, Claude, 工作流自动化, MCP]
+date: 2026-03-29
+---
+
+## Source File
+- [[raw/Agent/n8n+Claude 通过自然语言自动化工作流.md]]
+
+## Summary
+- 核心主题：n8n + Claude（通过 MCP 协议）实现自然语言驱动的自动化工作流生成
+- 问题域：n8n 工作流设计门槛高、非技术用户难以快速上手
+- 方法/机制：n8n-mcp 作为桥梁，让 Claude 能够理解 n8n 的 543 个节点并生成完整工作流 JSON
+- 结论/价值：自然语言生成工作流完成度 80-90%，但需人工修正 10-20%
+
+## Key Claims
+- n8n-mcp 提供 Claude 对 n8n 543 个节点的完整结构化访问
+- Claude 生成 n8n 工作流 JSON 完成度约 80-90%，10%-20% 错误率需人工介入
+- 选择 Opensea 模型并开启 extended thinking 可显著提升生成质量
+- n8n AI Agent 节点支持对话式循环执行，而非单次执行
+- Anthropic MCP 是 Claude 与 n8n 通信的核心协议
+
+## Key Quotes
+> "n8n AI Agent 节点内置 Memory 机制，支持多轮对话上下文"
+> "OpenAI 的 o1-preview 和 o3 模型太慢，实际工作流生成不现实"
+
+## Key Concepts
+- [[n8n-mcp]]：Claude 与 n8n 之间的 MCP 协议桥接，提供 543 个节点的结构化访问
+- [[AI工作流自动生成]]：通过自然语言描述让 AI 自动生成 n8n 工作流 JSON
+- [[Memory in AI Agent]]：n8n AI Agent 节点内置 Memory，支持对话式循环执行
+- [[Workflow vs Agent]]：预定义固定路径 vs LLM 动态决策，n8n AI Agent 节点属于后者
+
+## Key Entities
+- [[Claude]]（Anthropic）：负责理解用户意图并生成 n8n 工作流 JSON
+- [[n8n]]：工作流自动化执行引擎，通过 MCP 接收 Claude 生成的工作流指令
+- [[czlonkowski]]：n8n-mcp 项目作者
+
+## Connections
+- [[Claude]] ← generates via [[n8n-mcp]] ← [[n8n]]
+- [[n8n Docker 安装与更新]] ← 部署基础
+- [[AI工作流自动生成]] ← 应用场景
+
+## Contradictions

wiki/sources/一语点醒梦中人-东方人生智慧.md

@@ -0,0 +1,41 @@
+---
+title: "一语点醒梦中人 — 东方人生智慧"
+type: source
+tags: [wisdom, daoism, confucianism, buddhism, chinese-philosophy]
+date: 2026-01-01
+---
+
+## Source File
+- [[raw/AI/一语点醒梦中人.md]]
+
+## Summary
+- 核心主题：道家、儒家、佛教经典箴言与人生智慧
+- 问题域：如何在困境中保持内心平静，如何以东方哲学应对人生无常
+- 方法/机制：收录王维、曾国藩、老庄等思想家的经典箴言，配以现代解读与实践指南
+- 结论/价值：东方智慧的核心在于"绝处逢生"——以空性智慧观照困境，以道家态度顺势而为
+
+## Key Claims
+- 王维"行到水穷处，坐看云起时"：困境（水穷处）中放下执着，静观变化（云起），顿悟人生
+- "知其不可奈何而安之若命"（庄子）：先尽人事，后听天命，非消极认命而是接纳与行动的平衡
+- "执一守中，有劳而作，言行意合，自然而行"：儒家守中+道家自然+佛家修言的统一修养路径
+- "唯忘机可以消众机，唯懵懂可以祓不祥"（曾国藩）：以无争朴拙应对复杂环境
+- "一切有为法，如梦幻泡影，如露亦如电"（金刚经）：以空性智慧观照世间一切现象
+
+## Key Concepts
+- [[空性智慧]]：一切因缘和合之物皆虚幻短暂，不执着于"自性"，以清醒觉知观照流动真相
+- [[绝处逢生]]："行到水穷处，坐看云起时"，东方逆境转化智慧——困境是转机
+- [[知其不可奈何而安之若命]]：先辨"可奈何"与"不可奈何"，全力于前者，接纳后者
+- [[执一守中]]：儒家"执两用中"与道家"守中"结合，避免极端，动态平衡中守持正道
+- [[大智若愚]]：收敛锋芒，以质朴掩藏才智（老子/苏轼）
+- [[和光同尘]]：不标新立异，与世无争以保全自身（老子）
+
+## Key Entities
+- [[王维]]："诗佛"，行到水穷处典故出处，佛学影响下形成空寂淡泊心境
+- [[曾国藩]]：《治心经·诚心篇》作者，"唯忘机可以消众机"出处，晚清政局中以"拙诚"自保
+- [[庄子]]：《人间世》"知其不可奈何而安之若命"出处，道家逍遥派代表
+- [[老子]]：《道德经》"大巧若拙/和其光同其尘"出处，道家无为思想核心
+
+## Connections
+- [[一语点醒梦中人-东方人生智慧]] ← foundational ← [[空性智慧]]
+- [[一语点醒梦中人-东方人生智慧]] ← foundational ← [[绝处逢生]]
+- [[su-dongpo-perspective]] ← similar_tradition ← [[一语点醒梦中人-东方人生智慧]]（均属东方人生智慧，苏东坡视角可与此互相补充）

wiki/sources/万字保姆级教程-90天跑通一人公司模式-2026-03-29.md

@@ -0,0 +1,50 @@
+---
+title: "万字保姆级教程：90天跑通一人公司模式"
+type: source
+tags: [一人公司, Ikigai, 个人品牌, 商业变现, AI提示词]
+date: 2026-03-29
+---
+
+## Source File
+- [[raw/Agent/万字保姆级教程-90天跑通一人公司模式-2026-03-29.md]]
+
+## Summary
+- 核心主题：用 AI 辅助，从自我认知到商业变现，90 天跑通一人公司模式
+- 问题域：有行业经验但不知如何将个人优势转化为可变现产品
+- 方法/机制：天才地带模型 → 底层能力挖掘 → Ikigai 四圈交集 → 数据验证赛道 → 产品漏斗设计
+- 结论/价值：一人公司的关键是更聪明地定位，而非更努力地工作
+
+## Key Claims
+- 天才地带（Flow）：能产生心流、时间飞逝、精力充沛的活动区域
+- 底层能力的三个自检问题：追溯童年/毫不费力/底层通用
+- 四个心理陷阱：愧疚陷阱、效率陷阱、卓越陷阱、努力陷阱
+- Ikigai 四圈：热爱 × 擅长 × 市场需要 × 能获报酬
+- 产品体系四层：引流（免费PDF）→ 入门（¥199工具）→ 核心（¥4999训练营）→ 高价（¥20000/月的陪跑咨询）
+- 内容矩阵：横轴核心主题 × 纵轴内容形式（观察类/反直觉类/操作指南类/个人故事类/清单类）
+- 反向金字塔：一次长形式内容，切成无数微内容百次分发
+
+## Key Quotes
+> "一人公司的关键，和你更努力地工作一点关系没有，是更聪明地定位"
+> "在你觉得太简单所以不值钱的事情里，在朋友们总是找你帮忙的那个领域里——现在，是时候把它挖掘出来了"
+> "AI 时代能判断什么是真正好的（品味）成为稀缺护城河"
+
+## Key Concepts
+- [[天才地带]]：能产生心流的活动区域，回顾过去一个月找到精力充沛的项目
+- [[底层能力]]：冰山水下的通用能力，能串起多件擅长的事
+- [[Ikigai]]：热情/使命/天职/职业的交汇点，四圈交集处是最佳定位
+- [[一人公司]]：用最小杠杆撬动最大价值，核心支点是个人优势
+- [[产品漏斗]]：获客（社交媒体→落地页）→ 激活（免费资源→系列内容）→ 转化（低价直接/高价咨询）
+- [[价格锚定]]：高价咨询放顶部，让低价显得便宜
+- [[内容矩阵]]：核心主题 × 内容形式的二维矩阵
+- [[反向金字塔]]：一次长内容切多次分发
+
+## Key Entities
+- [[超级个体]]：某领域八九十分 + AI 横向扩展
+- [[品味]]：AI 时代真正的护城河
+- [[端到端]]：不做别人 AI 流水线上的零件
+
+## Connections
+- [[普通人如何在AI时代赚钱]] ← 同一主题的不同版本
+- [[AI产品经理]] ← 相关：精准表达与结构化思维
+
+## Contradictions

wiki/sources/万字讲透OpenClaw-Workspace深度解析-2026-03-21.md

@@ -0,0 +1,52 @@
+---
+title: "万字讲透OpenClaw Workspace深度解析（2026-03-21版）"
+type: source
+tags: [OpenClaw, Workspace, Agent, AGENTS.md, SOUL.md, IDENTITY.md]
+date: 2026-03-21
+---
+
+## Source File
+- [[raw/Agent/万字讲透OpenClaw-Workspace深度解析-2026-03-21.md]]
+
+## Summary
+- 核心主题：OpenClaw workspace 7 大核心文件体系的深度解析与最佳实践
+- 问题域：为什么有些 Agent 每次像重新 onboarding，有些 Agent 却记得一切
+- 方法/机制：workspace 文件体系（AGENTS.md/SOUL.md/USER.md/IDENTITY.md/TOOLS.md/BOOTSTRAP.md/memory/）各司其职
+- 结论/价值：这套文件配合好了，Agent 从"能工作"变成"好用了"，成为真正懂你、记得你、靠谱的长期搭档
+
+## Key Claims
+- AGENTS.md 是岗位说明书，SOUL.md 是性格档案，两者分工明确不应混写
+- AGENTS.md 最佳长度为 300-500 字，过长反而冲淡重点
+- SOUL.md 是叙事性角色设定（人物小传），IDENTITY.md 是结构化元数据（名片）
+- TOOLS.md 的核心价值是"什么时候不用"，而非"什么时候用"
+- BOOTSTRAP.md 是一次性引导，完成后必须删除
+- memory/ 是 Agent 真正的长期记忆，对 Agent 来说真正算数的是 Markdown 文件而非黑盒数据库
+- bootstrapMaxChars/boolstrapTotalMaxChars 长度限制会影响 session 启动时带进系统提示词的内容量
+
+## Key Quotes
+> "AGENTS.md 告诉你 Agent 该做什么、不该做什么；SOUL.md 定义 Agent 的性格，让它变得可预期"
+> "BOOTSTRAP.md 的使命是把一个全新的 workspace 引导到可正常使用的状态"
+> "对 Agent 来说，真正算数的长期记忆，是 workspace 里那些 Markdown 文件，不是什么看不见摸不着的黑盒数据库"
+
+## Key Concepts
+- [[Workspace]]：OpenClaw Agent 的工作台，决定 Agent 怎么工作
+- [[AGENTS.md]]：Agent 的岗位职责说明书（功能性）
+- [[SOUL.md]]：Agent 的性格档案（人格性）
+- [[USER.md]]：用户偏好固化，减少重复交代
+- [[IDENTITY.md]]：Agent 结构化身份元数据（名字/emoji/头像）
+- [[TOOLS.md]]：工具权限声明与使用规范，核心是"什么时候不用"
+- [[BOOTSTRAP.md]]：一次性初始化引导，完成后必须删除
+- [[memory/]]：Agent 的长期记忆目录，按日期滚动的 Markdown 文件
+- [[长期记忆]]：Agent 跨会话保留重要信息的能力
+
+## Key Entities
+- [[OpenClaw]]：整个 workspace 文件体系的承载平台
+- [[DracoVibeCoding]]：本文作者，微信公众号 Draco正在VibeCoding
+
+## Connections
+- [[Workspace]] ← contains ← [[AGENTS.md]] + [[SOUL.md]] + [[USER.md]] + [[IDENTITY.md]] + [[TOOLS.md]] + [[BOOTSTRAP.md]] + [[memory/]]
+- [[万字讲透OpenClaw-Workspace深度解析]] ← 早版（内容基本相同）
+- [[BOOTSTRAP.md]] → deleted after initialization → [[SOUL.md]] created
+
+## Contradictions
+- 与[[万字讲透OpenClaw-Workspace深度解析]]：本质同一篇文章的不同版本，此版本为公众号发布版（2026-03-21），原版为早期传播版

wiki/sources/养虾日记3-Obsidian-Gitea持久化笔记系统.md

@@ -0,0 +1,55 @@
+---
+title: "养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统"
+type: source
+tags: [OpenClaw, Obsidian, Gitea, 笔记系统, LLM Wiki, Karpathy]
+date: 2026-04-09
+---
+
+## Source File
+- [[raw/微信公众号/养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统.md]]
+
+## Summary
+- 核心主题：用 Obsidian 做知识库、Gitea 做版本控制、OpenClaw 做写入接口，构建 AI 助手的持久化笔记系统
+- 问题域：AI 助手每次对话输出后消失在聊天记录里，无法积累和复用
+- 方法/机制：AI 输出直接写入 Obsidian 笔记 → iCloud Drive 三端同步 → Gitea 版本管理
+- 结论/价值：把 AI 变成一个会自动整理笔记的实习生，做完事顺手把记录更新好
+
+## Key Claims
+- AI 输出的有价值结论直接落盘到笔记，而非留在聊天记录里
+- 每个 Agent 有专属 Archive（openclaw/<agentId>/），knowledgebase/ 是跨 Agent 共用的整理后知识
+- 核心原则：研究过程写入 Agent Archive；经过验证可复用的知识沉淀到 Knowledge Base
+- Obsidian Git 插件 Auto commit-and-sync interval 实现完全自动的版本管理
+- Karpathy LLM Wiki 思路：RAG 是每次从零检索知识不积累；LLM Wiki 是增量构建和维护持久化 Wiki，页面间互相链接知识越积越厚
+- Graph View 是知识健康检查工具：孤岛页面（无页面链接指向它）= 需要补上交叉引用
+- Wiki 规模在几百页之前，index.md 完全够用；规模变大后再接入 QMD 精准搜索
+
+## Key Quotes
+> "用 Obsidian 做知识库，用 Gitea 做版本控制，用 OpenClaw 做写入接口"
+> "RAG 模式是每次从零检索，知识不积累；而 LLM Wiki 是让 AI 增量构建和维护一个持久化的 Wiki"
+> "把 AI 变成了一个会自动整理笔记的实习生——它做完事，就会顺手把记录更新好"
+
+## Key Concepts
+- [[LLM Wiki]]：增量构建和维护持久化 Wiki，页面间互相链接，知识越积越厚（区别于 RAG 每次从零检索）
+- [[Obsidian Web Clipper]]：浏览器插件，快速采集外部素材为 Markdown 到 Obsidian
+- [[Graph View]]：知识健康检查工具，发现孤岛页面和知识盲区
+- [[Git自动同步]]：Obsidian Git 插件 Auto commit 实现版本管理完全自动化
+- [[QMD]]：本地 Markdown 搜索引擎，Wiki 规模变大后的精准搜索方案
+- [[知识可发现性]]：Graph View + 双向链接让知识形成网络而非孤岛
+- [[被动更新]]：AI 在执行任务过程中顺手更新文档，无需人工维护
+
+## Key Entities
+- [[Obsidian]]：本地知识库，支持双向链接、Graph View、Git 插件
+- [[Gitea]]：自建 Git 服务，提供私有 Git 仓库，内网运行数据不出域
+- [[Karpathy]]：LLM Wiki 思路提出者，RAG vs Wiki 对比框架
+- [[OpenClaw]]：写入接口，通过 Obsidian Skill 直接写笔记
+- [[iCloud Drive]]：跨设备同步通道，Mac mini / Laptop / iPhone 三端一致
+
+## Connections
+- [[养虾日记1-OpenClaw照片整理实战]] ← 同一系列
+- [[养虾日记2-OpenClaw-Self-Improving复盘实战]] ← 同一系列
+- [[个人知识库]] ← 同主题（本文是具体实现）
+- [[LLM Wiki]] ← 核心理论（Karpathy）
+- [[Gitea]] ← 版本控制层
+- [[memory/]] ← OpenClaw 内置记忆机制（与本文 Obsidian 方案互补）
+
+## Contradictions

wiki/sources/用Docker中安装Navidrome.md

@@ -0,0 +1,69 @@
+---
+title: "用Docker中安装Navidrome"
+type: source
+tags: [docker, music, navidrome, synology, nas]
+date: 2026-04-15
+---
+
+## Source File
+- [[raw/Home Office/用Docker中安装Navidrome.md]]
+
+## Summary
+- 核心主题：Synology NAS Docker 部署 Navidrome 开源音乐服务器
+- 问题域：自托管音乐流媒体服务搭建，支持多客户端访问和转码
+- 方法/机制：docker-compose 定义服务，指定 UID/GID 用户映射，音乐目录只读挂载，数据目录持久化
+- 结论/价值：获得私有 Spotify 替代品，完全掌控音乐数据和流媒体服务
+
+## Key Claims
+- Navidrome 音乐目录以只读（:ro）方式挂载，防止容器误操作损坏原始音乐文件
+- ND_AUTOTRANSCODEDOWNLOAD=true 使 Navidrome 根据客户端能力自动下载合适格式
+- ND_TRANSCODINGCACHESIZE=200MB 限制转码缓存保护 NAS 磁盘空间
+- 容器以非 root 用户（1026:100）运行，符合最小权限原则
+
+## Key Quotes
+> "ND_LOGLEVEL=info — 开启详细日志，便于排查流媒体传输问题" — 故障排查配置
+> "ND_ENABLETRANSCODINGCONFIG=true — 启用转码配置界面" — 管理接口配置
+> "user: "1026:100" — 以指定 UID/GID 用户身份运行容器" — 安全加固配置
+
+## Key Concepts
+- [[Navidrome]]：开源 Web UI 音乐播放器，支持 Subsonic API，兼容绝大多数音乐客户端
+- [[音乐流媒体服务器]]：将本地音乐库通过 HTTP 流媒体协议提供给多设备客户端
+- [[Transcoding（转码）]]：根据客户端能力动态转换音频格式（如 FLAC → MP3 320kbps）
+- [[只读挂载]]：:ro 后缀保护原始数据，容器只能读取不能写入
+- [[Subsonic API]]：开源音乐流媒体协议标准，众多音乐 App 均兼容此协议
+
+## Key Entities
+- [[Synology NAS]]：硬件平台（192.168.3.17），Docker 宿主机
+- [[Docker]]：容器化平台，运行 Navidrome 服务
+- [[deluan/navidrome]]：Navidrome 官方 Docker 镜像
+
+## Connections
+- [[用Docker中安装Navidrome]] ← hosted_on ← [[Synology NAS]]
+- [[用Docker中安装Navidrome]] ← managed_by ← [[Docker]]
+
+## Navidrome Docker Compose 配置
+```yaml
+version: '3.8'
+services:
+  navidrome:
+    image: deluan/navidrome:latest
+    container_name: navidrome
+    user: "1026:100"
+    restart: unless-stopped
+    ports:
+      - "4533:4533"
+    volumes:
+      - /volume1/music:/music:ro"
+      - /volume1/docker/navidrome/data:/data
+    environment:
+      - ND_LOGLEVEL=info
+      - ND_ENABLETRANSCODINGCONFIG=true
+      - ND_AUTOTRANSCODEDOWNLOAD=true
+      - ND_TRANSCODINGCACHESIZE=200MB
+```
+
+## Contradictions
+
+## Reference
+- Navidrome Doc: https://www.navidrome.org/docs/
+- Navidrome FAQ: https://www.navidrome.org/docs/faq/