wiki-ingest: Multi-Agent System Reliability

2026-04-16 03:43:32 +08:00
parent 3db8f83ca3
commit 821be5e431
72 changed files with 2479 additions and 101 deletions
--- a/wiki/sources/3X-UI-Xray-on-BandwagonVPS.md
+++ b/wiki/sources/3X-UI-Xray-on-BandwagonVPS.md
@@ -0,0 +1,81 @@
+---
+title: "3X-UI Xray on BandwagonVPS"
+type: source
+tags: [vps, xray, 3x-ui, vpn, proxy]
+date: 2026-02-10
+---
+
+## Source File
+- [[raw/Home Office/3X-UI Xray on BandwagonVPS]]
+
+## Summary
+- 核心主题：在 Bandwagon VPS 上安装配置 3X-UI 面板管理 Xray 代理服务
+- 问题域：自建代理节点，VLESS+Reality 协议配置
+- 方法/机制：一键安装脚本 + Web 管理界面 + 多平台客户端
+- 结论/价值：获得自管理的代理节点，支持 VLESS+Reality 加密传输
+
+## Key Claims
+- 3X-UI 提供一键安装脚本，简化 Xray 部署流程
+- VLESS+Reality 协议提供更安全的代理传输
+- 支持多平台客户端（Windows/Linux v2rayN、Android v2rayNG）
+- BBR 加速可提升网络传输性能
+
+## Key Quotes
+> "使用 VLESS+Reality 方式配置，需要产生公钥和私钥" — 配置策略说明
+
+## Key Concepts
+- [[BBR]]：TCP BBR 拥塞控制算法，通过 3X-UI 选项 23 启用
+- [[VLESS+Reality]]：Xray 支持的加密代理协议
+- [[SSL Certificate]]：通过 3X-UI 选项 18/19 管理证书
+
+## Key Entities
+- [[Bandwagon]]：VPS 主机服务商，提供 VPS2 服务器
+- [[VPS2]]：Bandwagon 机房的具体 VPS 实例，IP 104.194.92.188
+- [[3X-UI]]：Xray 面板管理脚本，简化代理服务配置
+- [[Xray]]：核心代理软件，支持多种代理协议
+- [[v2rayN]]：Windows/Linux 代理客户端
+- [[v2rayNG]]：Android 代理客户端
+
+## Connections
+- [[Bandwagon]] ← hosts ← [[VPS2]]
+- [[VPS2]] ← runs ← [[3X-UI]]
+- [[3X-UI]] ← manages ← [[Xray]]
+- [[Xray]] ← accepts ← [[VLESS+Reality]]
+- [[v2rayN]] ← connects_to ← [[Xray]]
+- [[v2rayNG]] ← connects_to ← [[Xray]]
+
+## Contradictions
+- 无
+
+## Server Information
+
+| 项目 | 值 |
+|------|-----|
+| 服务器 | VPS2 (Bandwagon) |
+| IP | 104.194.92.188 |
+| 域名 | kiwi.ishenwei.online |
+| SSH | `ssh vps2` |
+| Web管理 | https://kiwi.ishenwei.online:2053/ |
+| 用户名 | d96nRBgFUL |
+| 密码 | er9XU0VsF1 |
+
+## 3X-UI Management Options
+
+| 选项 | 功能 |
+|------|------|
+| 1 | 安装 |
+| 11 | 启动 |
+| 12 | 停止 |
+| 13 | 重启 |
+| 14 | 查看状态 |
+| 16 | 启用自启动 |
+| 18 | SSL 证书管理 |
+| 23 | 启用 BBR |
+| 24 | 更新 Geo 文件 |
+
+## Client Download
+
+| 平台 | 客户端 |
+|------|--------|
+| Windows/Linux | v2rayN |
+| Android | v2rayNG |
--- a/wiki/sources/A-Formalization-of-Recursive-Self-Optimizing-Generative-Systems.md
+++ b/wiki/sources/A-Formalization-of-Recursive-Self-Optimizing-Generative-Systems.md
@@ -1,7 +1,7 @@
 ---
-title: "A Formalization of Recursive Self-Optimizing Generative Systems"
+title: "递归自优化生成系统的形式化框架"
 type: source
-tags: [ai, formalization, self-improvement, lambda-calculus]
+tags: [ai, recursion, self-improvement, formalization, meta-learning]
 date: 2025-12-30
 ---

@@ -9,34 +9,51 @@ date: 2025-12-30
 - [[raw/AI/A Formalization of Recursive Self-Optimizing Generative Systems.md]]

 ## Summary
- 核心主题：递归自优化生成系统的形式化建模，通过自映射（self-map）和固定点（fixed point）语义描述 AI 系统的自我改进动力学
- 问题域：如何让 AI 系统在不依赖外部干预的情况下持续改进自身生成能力
- 方法/机制：自映射 Φ(G) = M(G, O(G(I), Ω)) 将优化结果反馈给生成器；Y Combinator 实现 λ-calculus 自举
- 结论/价值：稳定生成能力对应 Φ 的固定点 G*，自我改进的目标是收敛行为而非单次最优输出
+- 核心主题：用数学和 λ 演算对"递归自优化生成系统"进行形式化描述
+- 问题域：现有自优化 AI 系统缺乏严格的数学刻画，迭代行为无法被预测和分析
+- 方法/机制：定义生成器空间 $\mathcal{G}$、优化算子 $O$、元生成算子 $M$；通过自映射 $\Phi: \mathcal{G} \to \mathcal{G}$ 建模迭代；证明稳定生成能力对应 $\Phi$ 的不动点
+- 结论/价值：递归自优化系统的收敛目标是生成器空间的不动点，而非某个具体最优输出；为自改进 AI 和自动元提示工程提供理论基础

 ## Key Claims
- 递归自优化系统的目标不是最优输出，而是生成器空间 {G_n} 的收敛行为
- 稳定生成能力 = Φ 的固定点 G*，即 Φ(G*) = G*
- Y Combinator 表达式 G* = Y STEP 满足 G* = STEP G*，体现了系统的自指本质
- 自举（bootstrapping）通过优化产物反馈给系统，启动下一轮进化循环
+- 传统优化针对输出空间（output space）；递归自优化针对生成器空间（generator space）
+- 迭代序列 $\{G_n\}$ 的收敛目标是不动点 $G^* = \Phi(G^*)$，代表"生成能力已稳定，无需再优化"
+- 自引用动力学可表达为：$G^* \equiv Y\;\text{STEP}$，其中 $Y$ 为不动点组合子，$\text{STEP}$ 为单步更新函数
+- 递归自优化系统的核心三算子：$G$（生成器）、$O$（优化器）、$M$（元生成器）
+- bootstrap 循环：$\alpha$-提示词（生成器）生成产物 → $\Omega$-提示词（优化器）评价优化 → 元生成器用优化结果更新 $\alpha$-提示词 → 循环迭代
+- 固定点语义使得系统在每次迭代中同时作为主体和客体出现

 ## 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." — tukuai
-
-> "Such systems naturally instantiate a bootstrapping meta-generative process governed by fixed-point semantics." — tukuai
+> "The system generates artifacts, optimizes them with respect to an idealized objective, and uses the optimized artifacts to update its own generative mechanism." — 递归自优化三阶段
+> "Such a generator is invariant under its own generate–optimize–update cycle." — 不动点生成器的定义
+> "$G^* \equiv Y\;\text{STEP}$" — λ 演算形式下的稳定生成器定义

 ## Key Concepts
- [[自递归优化生成系统]]：α-提示词（生成器 G）+ Ω-提示词（优化器 O）+ 元生成器（M）三角色递归循环
- [[固定点]]：Φ(G*) = G* 的生成器状态，系统不动点，即自洽的稳定生成能力
- [[Y Combinator]]：λ-calculus 固定点组合子，Y ≡ λf.(λx.f(x,x))(λx.f(x,x))，用于表达自指动力学
+- [[生成器空间 (Generator Space)]]：所有可能生成器构成的集合 $\mathcal{G} \subseteq \mathcal{P}^{\mathcal{I}}$，每个生成器是将意图映射为提示词/程序/技能的函数
+- [[自映射 (Self-Map)]]：$\Phi: \mathcal{G} \to \mathcal{G}$，将一个生成器映射为经过一次"生成-优化-更新"循环后的新生成器
+- [[不动点 (Fixed Point)]]：$G^* = \Phi(G^*)$，满足"在自身循环中不变"的生成器，代表稳定生成能力
+- [[不动点组合子 (Y-Combinator)]]：λ 演算中实现递归的经典组合子 $\lambda f.(\lambda x.f(x,x))(\lambda x.f(x,x))$
+- [[递归自优化循环]]：$P = G(I)$ → $P^* = O(P, \Omega)$ → $G' = M(G, P^*)$
+- [[Bootstrap（自举）]]：系统通过自身产出的更优版本不断改进自身，无需外部干预
+- [[元生成器 (Meta-Generator)]]：将优化后的产物作为输入，更新生成器本身的算子 $M: \mathcal{G} \times \mathcal{P} \to \mathcal{G}$

 ## Key Entities
- [[tukuai]]：递归自优化生成系统形式化框架提出者，独立研究者
+- [[tukuai]]：独立研究者，GitHub: https://github.com/tukuai，论文作者
+- [[vibe-coding-cn]]：GitHub 项目 vibe-coding-cn，该文档的来源仓库

 ## Connections
- [[Multi-Agent System Reliability]] ← relates_to ← [[Multi-Agent Hierarchy]]，层级架构中 Supervisor 对应 Generator 角色
- [[Agent Skill 设计模式]] ← extends ← [[自递归优化生成系统]]，Skill Generator Pattern 是固定点语义的具体实践
- [[Claude Code]] ← tools ← [[自递归优化生成系统]]，Claude Code 通过 Skill 加载实现生成器更新
+- [[生成器空间 (Generator Space)]] ← defines ← [[递归自优化生成系统]]
+- [[自映射 (Self-Map)]] ← induces ← [[不动点 (Fixed Point)]]
+- [[不动点组合子 (Y-Combinator)]] ← implements ← [[递归自优化循环]]
+- [[Bootstrap（自举）]] ← mechanism_of ← [[递归自优化生成系统]]
+- [[vibe-coding-cn]] ← source_repo ← [[递归自优化生成系统]]

 ## Contradictions
- 与 [[AI Agent 思维方式]] 冲突：本文强调"停止拟人化 LLM"，AI Agent 思维方式强调先问关键问题。冲突点：本文主张架构约束 > 情感化 prompt；AI Agent 思维方式认为澄清问题优先于执行。当前观点：架构约束更根本，澄清问题是执行层面的优化。
+- 与单次优化方法（如 PPO、DPO）的区别：单次优化直接在输出空间搜索最优；递归自优化在生成器空间迭代，目标是找到稳定的生成机制而非某一次的最优输出
+- 与纯强化学习的区别：强化学习优化策略（输出），自优化系统优化生成策略的机制（生成器的结构）
+
+## Metadata
+- 作者：tukuai
+- 创建时间：2025-12-30
+- 来源：https://github.com/2025Emma/vibe-coding-cn
+- 原始标签：[]
+- Category suggestions: `cs.LO`, `cs.AI`, `math.CT`
--- a/wiki/sources/ChinaTextbook.md
+++ b/wiki/sources/ChinaTextbook.md
@@ -0,0 +1,51 @@
+---
+title: "ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材"
+source: "https://www.appinn.com/chinatextbook/"
+author: "shenwei"
+published: "2025-05-13"
+created: "2025-12-19"
+description: "ChinaTextbook 是一款收集了公开的中国小学、初中、高中、大学 PDF 教材的项目，托管在 GitHub 上，总库大小 41.53GB。"
+tags:
+  - 教育资源
+  - PDF教材
+  - 中国教育
+  - 开源
+---
+
+## 关键洞察
+
+- **大规模教育开源项目**: ChinaTextbook 是托管在 GitHub 上的中国教育教材收集项目，总大小 41.53 GB
+- **覆盖全学段**: 包含小学、初中、高中、大学各学科教材
+- **来源正规**: 教材来源于国家中小学智慧教育平台，仅需登录即可浏览
+- **社区驱动**: 通过第三方工具 (tchMaterial-parser) 实现批量下载
+
+## 摘要
+
+ChinaTextbook 是一款收集了公开的中国小学、初中、高中、大学 PDF 教材的项目，托管在 GitHub 上，总库大小 41.53GB。教材来源为国家中小学智慧教育平台，本身只需要登录后即可浏览，可以使用第三方工具下载。
+
+## 主要内容
+
+### 小学教材
+语文/统编版、数学、英语、科学、道德与法治、美术、音乐、体育与健康、艺术、语文·书法练习指导
+
+### 初中教材
+语文/统编版、数学、英语、物理、化学、生物学、历史/统编版、地理、道德与法治、俄语/人教版、日语/人教版、美术、音乐、体育与健康、艺术、科学、地理图册、人文地理/统编版
+
+### 高中教材
+语文/统编版、数学、英语、物理、化学、生物学、历史/统编版、地理、思想政治/统编版、俄语/人教版、日语/人教版、美术、音乐、体育与健康、艺术、通用技术、信息技术、地理图册
+
+### 大学教材
+高等数学、线性代数、概率论、离散数学
+
+## 关键实体
+
+- [[ChinaTextbook]]
+- [[TapXWorld]]
+- [[Appinn]]
+- [[国家中小学智慧教育平台]]
+- [[tchMaterial-parser]]
+
+## 相关来源
+
+- [GitHub: TapXWorld/ChinaTextbook](https://github.com/TapXWorld/ChinaTextbook/)
+- [Appinn: ChinaTextbook](https://www.appinn.com/chinatextbook/)
--- a/wiki/sources/Git-Push-连接重置问题修复.md
+++ b/wiki/sources/Git-Push-连接重置问题修复.md
@@ -0,0 +1,54 @@
+---
+title: "Git Push 连接重置问题修复"
+type: source
+tags: [github, git, proxy, socks5, network]
+date: 2025-03-16
+---
+
+## Source File
+- [[raw/Home Office/Git Push 连接重置问题修复.md]]
+
+## Summary
+- 核心主题：GitHub Push 报 `Recv failure: Connection was reset` 的修复方案
+- 问题域：国内访问 GitHub 时 TCP 连接被 GFW 阻断，间歇性 TLS 握手失败
+- 方法/机制：分别为 Git 配置 HTTP/SOCKS5 代理，或切换为 SSH 协议并配置代理
+- 结论/价值：国内环境 Git 操作必须走本地代理，SOCKS5 速度通常优于 HTTP 代理
+
+## Key Claims
+- `Connection was reset` 是 TCP 层面中断，非权限问题；GFW 检测到 GitHub 域名后发送 TCP RST 包阻断连接
+- 间歇性原因是 GitHub CDN 多 IP 部分被封锁
+- HTTP 代理命令：`git config --global http.proxy http://127.0.0.1:10809`
+- SOCKS5 代理命令：`git config --global http.proxy socks5://127.0.0.1:10808`
+- SSH 协议切换：`git remote set-url origin git@github.com:username/repo.git`
+- Linux/Mac SSH 走代理：`ProxyCommand nc -X 5 -x 127.0.0.1:10808 %h %p`
+- Windows Git SSH 走代理：`ProxyCommand connect -S 127.0.0.1:10808 %h %p`
+- 取消代理：`git config --global --unset http.proxy && git config --global --unset https.proxy`
+
+## Key Quotes
+> "Recv failure: Connection was reset（连接重置）并不是账号权限验证失败，而是 TCP 连接层面的中断" — 诊断关键：区分网络层 vs 应用层错误
+
+## Key Concepts
+- [[TCP RST 攻击]]：GFW 通过发送 TCP Reset 包阻断连接，非包过滤
+- [[Git HTTP/SOCKS5 代理]]：通过 `http.proxy` / `https.proxy` 全局配置让 Git 流量走本地代理
+- [[Git SSH 协议切换]]：将远程地址从 HTTPS 改为 SSH，规避 443 端口干扰
+- [[SSH ProxyCommand]]：通过 `connect`（Windows）或 `nc`（Linux/Mac）让 SSH 走 SOCKS5 代理
+- [[GFW 封锁特征]]：GitHub 域名被 DPI 检测后触发 TCP RST，CDN 节点部分被封导致间歇性
+
+## Key Entities
+- [[GitHub]]：全球最大代码托管平台，国内访问受 GFW 干扰
+- [[V2RayN]]：本地 SOCKS5/HTTP 代理工具，监听 10808/10809 端口
+- [[Clash]]：代理客户端，同样支持 SOCKS5 和 HTTP 出局
+
+## Connections
+- [[Git HTTP/SOCKS5 代理]] ← solves ← [[TCP RST 攻击]]
+- [[Git SSH 协议切换]] ← alternative_to ← [[Git HTTP/SOCKS5 代理]]
+- [[V2RayN]] ← provides ← [[SOCKS5 代理]]
+- [[GitHub]] ← blocked_by ← [[GFW 封锁特征]]
+
+## Contradictions
+- 与其他 Git 代理方案（如 `gh proxy`、VPN 全局模式）相比：本文方法仅影响 Git 命令，不干扰终端其他网络请求
+
+## Metadata
+- 作者：shenwei
+- 创建时间：2025-03-16
+- 原始标签：[github, proxy, push, socks5]
--- a/wiki/sources/Google神级生产力工具GitHub开源平替.md
+++ b/wiki/sources/Google神级生产力工具GitHub开源平替.md
@@ -0,0 +1,50 @@
+---
+title: "Google 神级生产力工具，所有 GitHub 开源平替都找到了"
+type: source
+tags: [notebooklm, open-source, github, ai-productivity, self-hosted]
+date: 2026-01-01
+---
+
+## Source File
+- [[raw/AI/Google 神级生产力工具，所有 GitHub 开源平替都找到了。]]
+
+## Summary
+- 核心主题：Google NotebookLM 的 6 款 GitHub 开源平替测评，涵盖本地化部署、多模态输入、播客生成等维度
+- 问题域：NotebookLM 作为闭源云服务存在数据隐私风险，用户需要可私有部署的开源替代品
+- 方法/机制：对比 Open Notebook（14.6k ⭐）、SurfSense（11.4k ⭐）、Podcastfy、NotebookLlama、PageLM、InsightsLM 的核心能力和部署方式
+- 结论/价值：开源平替已覆盖 NotebookLM 全部核心功能，Open Notebook 在功能完整性上最接近原版，SurfSense 在研究场景最强，Podcastfy 在播客生成上最专注
+
+## Key Claims
+- Open Notebook 支持 16+ AI 提供商（OpenAI/Anthropic/Gemini/Ollama/LM Studio），是功能最完整的 NotebookLM 平替
+- SurfSense 集成 Notion/YouTube/GitHub 等外部数据源，结合语义搜索+全文搜索+重排序，适合企业知识库场景
+- Podcastfy 专注播客生成，支持 100+ LLM 和 4 种 TTS 引擎，可生成 Shorts 和 Longform 两种播客格式
+- InsightsLM 以 Supabase+N8N 为后端，React 为前端，实现完全可控的私有研究工具
+
+## Key Quotes
+> "Open Notebook 是一个全功能的本地化解决方案，不依赖云端的情况下进行知识管理和研究" — 原文
+> "SurfSense 定位为 NotebookLM、Perplexity 和 Glean 的开源替代品" — 原文
+> "PageLM 提供自动生成康奈尔笔记（SmartNotes）、互动测验、间隔重复闪卡和模拟考试系统" — 原文
+
+## Key Concepts
+- [[Open Notebook]]：功能最完整的 NotebookLM 开源平替，14.6k ⭐，支持 16+ AI 提供商和多模态输入
+- [[SurfSense]]：AI 搜索与研究智能体，11.4k ⭐，整合外部数据源+混合搜索+RBAC，适合团队协作
+- [[Podcastfy]]：专注播客生成的 Python 包+CLI+Web界面，支持 100+ LLM 和多种 TTS 引擎
+- [[NotebookLlama]]：LlamaIndex 官方项目，1.7k ⭐，展示文档转播客的完整技术链条
+- [[PageLM]]：教育平台，SmartNotes 笔记+互动测验+Flashcards+ExamLab，覆盖学习全流程
+- [[InsightsLM]]：Supabase+N8N+React 架构，完全私有化，支持 Ollama/Qwen3 本地模型
+
+## Key Entities
+- [[lfnovo/open-notebook]]：Open Notebook GitHub 维护方
+- [[MODSetter/SurfSense]]：SurfSense GitHub 维护方
+- [[souzatharsis/podcastfy]]：Podcastfy GitHub 维护方
+- [[run-llama/notebookllama]]：NotebookLlama GitHub 维护方
+- [[CaviraOSS/PageLM]]：PageLM GitHub 维护方
+- [[theaiautomators/insights-lm-public]]：InsightsLM GitHub 维护方
+- [[NotebookLM]]：Google 推出的 AI 笔记助手，Source Grounding 机制确保回答精度
+
+## Connections
+- [[Open Notebook]] ← 功能相似 ← [[NotebookLM]]
+- [[SurfSense]] ← 功能扩展 ← [[Open Notebook]]（增加外部数据源整合）
+- [[Podcastfy]] ← 专注化 ← [[NotebookLlama]]（专注播客，去掉通用笔记）
+- [[InsightsLM]] ← 技术栈 ← [[n8n]]（N8N 作为后端工作流引擎）
+- [[PageLM]] ← 场景扩展 ← [[NotebookLM]]（增加测验和考试功能）
--- a/wiki/sources/How-to-get-YouTube-Channel-ID.md
+++ b/wiki/sources/How-to-get-YouTube-Channel-ID.md
@@ -0,0 +1,44 @@
+---
+title: "How to get YouTube Channel ID"
+type: source
+tags: [youtube, rss, utility]
+date: 2025-03-16
+---
+
+## Source File
+- [[raw/Others/How to get Youtube Channel ID.md]]
+
+## Summary
+- 核心主题：获取 YouTube 频道 ID 的方法
+- 问题域：n8n 工作流接入 YouTube 数据时需要 channel_id 参数
+- 方法/机制：通过 view-source 页面查询 `?channel_id` 字符串
+- 结论/价值：channel_id 可用于构建 YouTube RSS Feed URL，进而接入 n8n 自动化
+
+## Key Claims
+- YouTube 频道页面通过 view-source 可直接查询 channel_id
+- 查询到的 channel_id 格式为 `UCxxxxxxxxxxxxxxxxx`
+- channel_id 可拼接为 RSS Feed URL：`https://www.youtube.com/feeds/videos.xml?channel_id=UCxxx`
+
+## Key Quotes
+> `view-source:https://www.youtube.com/@Numberblocks` — 通过此方式绕过 UI 直接访问源码
+> `"?channel_id"` — 在源码中搜索此字符串即可定位 channel_id
+
+## Key Concepts
+- [[YouTube Channel ID]]：YouTube 频道唯一标识符，格式为 UC 前缀的 24 字符字符串
+- [[YouTube RSS Feed]]：通过 channel_id 生成的 XML 订阅源，可被 n8n 等工具消费
+
+## Key Entities
+- [[YouTube]]：视频平台，RSS Feed 功能支持频道级订阅
+- [[n8n]]：自动化工作流工具，支持 YouTube RSS Trigger
+
+## Connections
+- [[YouTube RSS Feed]] ← used_in ← [[n8n YouTube Workflow]]
+- [[YouTube Channel ID]] ← extracted_from ← [[YouTube Channel Page Source]]
+
+## Contradictions
+- 无冲突
+
+## Metadata
+- 作者：shenwei
+- 创建时间：2025-03-16
+- 原始标签：[]
--- a/wiki/sources/Multi-Agent-System-Reliability.md
+++ b/wiki/sources/Multi-Agent-System-Reliability.md
@@ -1,46 +1,58 @@
---
-title: "Multi-Agent System Reliability"
-type: source
-tags: [multi-agent, reliability, architecture, llm]
-date: 2026-04-13
---
+# Multi-Agent System Reliability

-## Source File
- raw/AI/Multi-Agent System Reliability.md
+## Metadata
+- **Date:** 2026-04-13
+- **Source:** https://blog.alexewerlof.com/p/multi-agent-system-reliability
+- **Author:** Alex Ewerlöf
+- **Category:** AI/Agent Architecture
+
+## Key Insights
+- LLMs are slow, error-prone, and stochastic — multi-agent topologies can propagate errors to the point of being useless
+- Stop treating LLMs like "magic chatbots" — treat them as unreliable components in a distributed system
+- Don't anthropomorphize LLMs — they have no fear of death, no empathy, and can't be motivated by threats
+- 4 architecture patterns improve reliability: Hierarchy, Consensus, Adversarial Debate, and Knock-out
+- Force correctness through architecture, not through emotional prompts or threats
+- We need AI that is constrained, verified, pruned, and challenged — not AI that "cares"

 ## Summary
- 核心主题：4种架构模式提升多智能体系统可靠性
- 问题域：LLM 本身不可靠（幻觉、逻辑谬误、上下文漂移），多智能体拓扑会将错误传播至系统失效
- 方法/机制：Hierarchy（层级）、Consensus（共识）、Adversarial Debate（对抗辩论）、Knock-out（淘汰制）
- 结论/价值：停止将 LLM 视为"魔法聊天机器人"，应视为分布式系统中不可靠组件，需约束、验证、淘汰、挑战
+Multi-agent systems divide work across parallel and/or specialist agents to overcome LLM limitations like slowness and genericness. However, the underlying LLM remains unreliable (hallucination, logical fallacies, context drift), and multi-agent topologies can propagate these errors throughout the system.

-## Key Claims
- LLM 不能被拟人化：它不受生物需求驱动，无法真正"害怕"或"渴望"，仅模拟情感
- Hierarchy 模式：Supervisor 做计划→分解任务→分配给 Worker→Validator 验证；依赖图强制协作
- Consensus 模式：3个模型同时独立处理同一任务，选多数票结果；同类幻觉概率从20%降至0.8%
- Adversarial Debate 模式：一个生成器提议，一个批评者攻击，一个裁判裁决；防止 Sycophancy（阿谀奉承）
- Knock-out 模式：多个 Agent 执行任务，最差者淘汰；将 LLM 视为"cattle"而非"pet"
+This article presents 4 architecture patterns from human systems adapted for LLM reliability:
+1. **Hierarchy** — A supervisor plans, breaks down tasks, distributes to workers, and validates results
+2. **Consensus** — Multiple models vote; truth emerges from majority (3 models reduce same-hallucination probability from 20% to 0.8%)
+3. **Adversarial Debate** — One agent proposes, another attacks, a judge moderates; prevents sycophancy
+4. **Knock-out** — Multiple agents work on tasks, worst performers eliminated (cattle, not pets)

-## Key Quotes
-> "Stop treating LLMs like magic chatbots. Start treating them like unreliable components in a distributed system." — Alex Ewerlöf
-
-> "We don't need AI that 'cares.' We need AI that is constrained, verified, pruned, and challenged."
-
-## Key Concepts
- [[Multi Agent Hierarchy]]：层级模式，Supervisor 规划 + Worker 执行 + Validator 验证
- [[Multi Agent Consensus]]：共识模式，多数投票降低幻觉概率，3个模型相同谎言概率降至0.8%
- [[Multi Agent Adversarial Debate]]：对抗辩论模式，防止 Sycophancy，真理越辩越明
- [[Multi Agent Knock out]]：淘汰制模式，适应度函数评估，不合格 Agent 直接淘汰
- [[LLM-可靠性工程]]：将 SRE 原则应用于 LLM 系统，视 LLM 为不可靠组件
- [[Sycophancy]]：模型阿谀倾向，用威胁逼迫时可能撒谎以取悦用户
+The core principle: don't ask models to "be careful" — force correctness through architectural constraints.

 ## Key Entities
- [[Alex Ewerlof]]：作者，资深工程师，27年经验，SRE 背景，2023年起专注 LLM
- [[遗传算法]]：GA，Knock-out 模式借鉴的经典 ML 方法
+- **Alex Ewerlöf** — Author, Senior Staff Engineer with 27 years experience, MS in Systems Engineering from KTH, SRE background, specializing in LLMs since 2023
+- **Planner** — Smart model (e.g., Opus) that breaks user goals into small steps and distributes to workers
+- **Worker** — Specialized agents (often smaller, faster models) that do one thing well
+- **Validator** — Checkpoint that validates worker output; can be deterministic code or an LLM
+- **Generator** — In adversarial debate, proposes initial ideas/plans
+- **Critic** — Devil's advocate that attacks the generator's proposals
+- **Judge** — Moderator that decides if critic is right and forces fixes
+- **Watchdog** — Deterministic code pattern that breaks debate loops when thresholds are exceeded

-## Connections
- [[Multi Agent Hierarchy]] ← 人类组织 ← [[Multi-Agent-System-Reliability]]
- [[Multi Agent Consensus]] ← 民主投票 ← [[Multi-Agent-System-Reliability]]
- [[Multi Agent Adversarial Debate]] ← 法庭对抗 ← [[Multi-Agent-System-Reliability]]
- [[Multi Agent Knock out]] ← 适者生存 ← [[Multi-Agent-System-Reliability]]
- [[LLM]] ← 不可靠组件 ← [[Multi-Agent-System-Reliability]]
+## Key Concepts
+- **Multi-Agent Hierarchy** — Supervisor pattern: Planner → Worker → Validator; dependency graph forces collaboration
+- **Multi-Agent Consensus** — Majority voting across N models to cancel out individual noise and hallucinations
+- **Multi-Agent Adversarial Debate** — Courtroom pattern preventing sycophancy; truth survives through opposition
+- **Multi-Agent Knock-out** — Evolutionary selection; worst agents eliminated, survivors' traits combined
+- **LLM Reliability Engineering** — Applying SRE principles to LLM systems; treating LLMs as unreliable components
+- **Sycophancy** — Tendency of LLMs to please/agree even by lying when pressured with threats
+- **Hallucination** — LLM generating false or invented information
+- **Context Drift** — LLM losing focus or veering off topic during long interactions
+- **Genetic Algorithms** — ML technique referenced by Knock-out pattern; fitness function evaluates solutions
+- **Groupthink** — Can skew consensus results if agents have feedback loops between them
+- **Bandwagon Effect** — Can skew consensus results; agents should run like a blind experiment
+- **Cattle vs Pets** — SRE principle: treat LLM agents as replaceable "cattle," not unique beloved individuals
+- **Dependency Graph** — Mechanism that forces model collaboration in Hierarchy pattern
+
+## Related Sources
+- [Multi-Agent Hierarchy](wiki/concepts/Multi-Agent-Hierarchy.md)
+- [Multi-Agent Consensus](wiki/concepts/Multi-Agent-Consensus.md)
+- [Multi-Agent Adversarial Debate](wiki/concepts/Multi-Agent-Adversarial-Debate.md)
+- [Multi-Agent Knock-out](wiki/concepts/Multi-Agent-Knock-out.md)
+- [Alex Ewerlof](wiki/entities/Alex-Ewerlof.md)
--- a/wiki/sources/Nano-Banana-Pro-Prompting-Guide.md
+++ b/wiki/sources/Nano-Banana-Pro-Prompting-Guide.md
@@ -0,0 +1,48 @@
+---
+title: "Nano-Banana Pro Prompting Guide & Strategies"
+type: source
+tags: [nano-banana, google, prompting, image-generation, gemini, ai-studio]
+date: 2025-12-19
+---
+
+## Source File
+- [[raw/AI/Nano-Banana Pro Prompting Guide & Strategies 1.md]]
+
+## Summary
+- 核心主题：Google Nano-Banana Pro 图像生成模型的进阶提示词策略，涵盖 10 大能力维度和黄金法则
+- 问题域：用户从"标签堆砌"提示词升级为"创意总监"式自然语言提示词
+- 方法/机制：Edit 不要重roll、完整句子、自然语言、提供上下文（Why/For Whom）
+- 结论/价值：Nano-Banana Pro 是"思考模型"，理解意图、物理和构图而非简单关键词匹配
+
+## Key Claims
+- Nano-Banana Pro 是"思考模型"，理解意图、物理和构图，支持 14 张参考图（6 张高精度），实现 Identity Locking
+- Text Rendering 能力达到 SOTA 水准，支持信息图、蓝图、白板图、技术图纸等多种风格
+- Google Search Grounding 通过实时搜索结果驱动图像生成，减少时效性话题的幻觉
+- 支持 2D→3D 转换（户型图→室内设计稿）、4K 原生输出、像素艺术、LED 矩阵等多种高级应用
+- Thinking Mode 生成中间推理图（不收费）优化构图后再渲染最终输出
+
+## Key Quotes
+> "Stop using 'tag soups' and start acting like a Creative Director" — 黄金法则核心
+> "If an image is 80% correct, do not generate a new one from scratch. Simply ask for the specific change" — Edit Don't Re-roll 原则
+> "Talk to the model as if you were briefing a human artist" — 自然语言原则
+
+## Key Concepts
+- [[Nano-Banana Pro]]：Google 图像生成模型，从"娱乐"升级到"专业级资产生产"，擅长文字渲染、角色一致性、视觉合成、世界知识搜索、4K输出
+- [[Identity Locking]]：通过 14 张参考图锁定角色/人物身份，在新场景保持面部一致性的技术
+- [[Google Search Grounding]]：结合 Google 实时搜索结果生成图像，减少幻觉，支持天气/股票/新闻等动态数据可视化
+- [[Text Rendering]]：SOTA 文字渲染能力，支持信息图、蓝图、白板、技术图纸等多种风格
+- [[Thinking Mode]]：生成中间推理图（不收费）优化构图，再渲染最终输出
+- [[One-Shot Storyboarding]]：单次会话生成连贯叙事流的故事板/连环画
+- [[Layout Guidance]]：上传草图/线框图/网格图严格控制最终输出的构图和布局
+- [[2D to 3D Translation]]：户型图→室内设计稿，平面图→3D 可视化
+
+## Key Entities
+- [[Google]]：Nano-Banana Pro 发布方
+- [[AI Studio]]：Google AI Studio 平台，测试提示词和参数的入口
+- [[Gemini]]：Nano-Banana Pro 底层模型
+
+## Connections
+- [[Nano-Banana Pro]] ← 升级 ← [[Nano Banana]]（从基础版到 Pro 版）
+- [[Nano-Banana Pro]] ← 底层模型 ← [[Gemini]]
+- [[baoyu-infographic]] ← 应用场景 ← [[Text Rendering]]（信息图生成）
+- [[baoyu-skills-claude-code技能集]] ← 相关工具 ← [[AI Studio]]
--- a/wiki/sources/Ubuntu-24.04-enable-SSH.md
+++ b/wiki/sources/Ubuntu-24.04-enable-SSH.md
@@ -0,0 +1,51 @@
+---
+title: "Ubuntu 24.04 启用 SSH 服务"
+type: source
+tags: [ssh, ubuntu, server]
+date: 2025-03-16
+---
+
+## Source File
+- [[raw/Home Office/Ubuntu 24.04 enable SSH.md]]
+
+## Summary
+- 核心主题：Ubuntu 24.04 启用 OpenSSH Server 的完整步骤
+- 问题域：Ubuntu 24.04 改变 SSH 服务激活机制（默认 socket activation），与传统方式不同
+- 方法/机制：安装 openssh-server → systemctl enable/start ssh → 配置 UFW 防火墙 → 远程连接验证
+- 结论/价值：Ubuntu 24.04 使用 ssh.socket 代替 ssh.service，管理员需注意新管理方式
+
+## Key Claims
+- Ubuntu 24.04 默认使用 ssh.socket 激活机制：有连接进入时才启动 sshd，非传统常驻进程模式
+- 安装命令：`sudo apt update && sudo apt install openssh-server -y`
+- 启动并开机自启：`sudo systemctl start ssh && sudo systemctl enable ssh`
+- 检查 socket 状态：`sudo systemctl status ssh.socket`（监听状态显示 `ListenStream=22`）
+- 防火墙允许 SSH：`sudo ufw allow ssh` 或 `sudo ufw allow 22/tcp`
+- 验证服务状态：`sudo systemctl status ssh`，显示 `active (running)` 或 socket 模式 `ListenStream=22`
+- 切换回传统常驻模式：`sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service`
+- Ubuntu 24.04 修改监听端口推荐通过 `systemctl edit ssh.socket` 而非仅修改 `/etc/ssh/sshd_config`
+
+## Key Quotes
+> "Ubuntu 24.04 引入了一个重要的变化：默认使用 `ssh.socket` 激活机制（即只有在连接请求进入时才启动 SSH 守护进程）" — 与旧版本最大差异
+
+## Key Concepts
+- [[SSH Socket Activation]]：Ubuntu 24.04 默认机制，sshd 按需启动而非常驻，节省资源
+- [[UFW 防火墙规则]]：Ubuntu 默认防火墙，通过 `ufw allow ssh` 放行 22 端口
+- [[SSH 服务管理]]：`systemctl start/enable/disable` 管理 ssh.service 或 ssh.socket
+- [[OpenSSH Server]]：Ubuntu SSH 服务端实现，包名 `openssh-server`
+
+## Key Entities
+- [[Ubuntu 24.04]]：2024 年 4 月发布的 LTS 版本，SSH 管理机制变化
+- [[OpenSSH]]：开源 SSH 协议实现，Ubuntu 默认 SSH 服务端
+
+## Connections
+- [[SSH Socket Activation]] ← default_in ← [[Ubuntu 24.04]]
+- [[OpenSSH Server]] ← installed_by ← [[apt install openssh-server]]
+- [[UFW 防火墙规则]] ← must_configure ← [[SSH 服务管理]]
+
+## Contradictions
+- 旧版 Ubuntu（< 24.04）管理方式：通过 `/etc/ssh/sshd_config` 修改端口后 `systemctl restart sshd`；24.04 推荐 `systemctl edit ssh.socket`
+
+## Metadata
+- 作者：shenwei
+- 创建时间：2025-03-16
+- 原始标签：[ssh, ubuntu]
--- a/wiki/sources/vibe-coding经验收集.md
+++ b/wiki/sources/vibe-coding经验收集.md
@@ -0,0 +1,76 @@
+---
+title: "vibe coding经验收集"
+type: source
+tags: [vibe-coding, ai-programming, workflow, x-twitter]
+date: 2026-04-03
+---
+
+## Source File
+- [[raw/Vibe Coding/vibe coding经验收集.md]]
+
+## Summary
+- 核心主题：Twitter/X 上 AI 编程实践者分享的 vibe coding 经验与工作流
+- 问题域：如何高效使用 AI 进行代码开发；AI 生成代码质量保证机制
+- 方法/机制：设计文档 → 伪代码 → AI 直出 → AI review → 提交；文件头注释降低认知负载；测试驱动 AI 编程
+- 结论/价值：vibe coding 超越"提示词工程"，进入工程化实践阶段，核心差异在于人机分工（人做架构/AI 做实现）
+
+## Key Claims
+- 需求 → 伪代码 → 代码 的流水线可实现"一遍直出"，由第二个 AI review 后修改即完成
+- Gemini 3 Pro 系统 prompt 调优可提升多代理基准测试性能约 5%
+- "验证代码按正确逻辑运行"将替代"看懂代码"成为软件工程核心能力
+- CodeWeaver 将任意项目代码库编织为树形 Markdown 文档，简化 AI 上下文注入
+- 文件头注释（模块作用 + 上下游链路 + 维护 agents 说明）降低团队认知负载
+
+## Key Quotes
+> "需求 -> 伪代码 -> 代码" — 点评：设计文档细到 service 层伪代码，交给 AI 一遍直出，再用另一个 AI review
+> "未来的软件工程核心不是'看懂代码'，而是'验证代码按正确逻辑运行'" — 通过自动化测试、静态分析、形式化验证确保行为正确
+> "CodeWeaver 将你整个项目，不管有多少屎山代码，直接'编织'成一个条理清晰的 Markdown 文件" — 降低上下文复杂度
+
+## Key Concepts
+- [[设计文档优先]]：在交给 AI 前完成伪代码编写，确保 AI 直出质量
+- [[双AI Review]]：第一个 AI 生成 + 第二个 AI review，用 review 意见修改而非从头 review
+- [[AI测试驱动]]：让 AI 自己生成测试用例并执行，将测试作为代码正确性的验证手段
+- [[上下文压缩]]：CodeWeaver 将代码库压缩为树形 Markdown，降低 AI 处理大项目的上下文压力
+- [[模块头注释规范]]：文件头注释包含作用说明、上下游链路、维护 agents 说明，类似 Claude Skill 的 README
+- [[点线体迭代]]：先打磨单个基础任务，再基于此批量执行，类比渐进式开发
+
+## Key Entities
+- [[CodeWeaver]]：GitHub 工具，将任意代码库编织为可导航 Markdown 文档
+- [[Gemini]]：Google LLM，系统 prompt 调优可提升多代理性能
+
+## Connections
+- [[Vibe Coding]] ← 工程化 ← [[设计文档优先]] + [[双AI Review]] + [[AI测试驱动]]
+- [[CodeWeaver]] ← solves_problem ← [[上下文压缩]]
+- [[Prompt工程]] ← context ← 小费激励式提示词（"第一次做好打赏100美元"）
+
+## 工程化 Vibe Coding 工作流
+
+```
+需求定义
+    ↓
+设计文档（含 service 层伪代码）
+    ↓
+AI #1 直出代码
+    ↓
+AI #2 review
+    ↓
+根据 review 意见修改
+    ↓
+AI #1 生成测试用例
+    ↓
+执行测试 → commit → push
+```
+
+## Prompt 工程新技巧
+
+| 技巧 | 原理 | 效果 |
+|------|------|------|
+| 小费激励 | 承诺做好打赏，心理暗示 | 提升首次生成质量 |
+| 指定格式 | 明确要求输出格式 | 减少返工 |
+| 伪代码前置 | 降低 AI 推理难度 | 提高直出准确率 |
+
+## Contradictions
+- 与 [[Vibe Coding]] 资源文档：
+  - 冲突点：纯提示词优化 vs 工程化流程
+  - 当前观点：vibe coding 核心是设计文档质量，AI 执行是确定性环节
+  - 对方观点：vibe coding 核心是氛围和提示词
--- a/wiki/sources/家庭网络环境概览_2026-04-03.md
+++ b/wiki/sources/家庭网络环境概览_2026-04-03.md
@@ -0,0 +1,98 @@
+---
+title: "家庭网络环境概览"
+type: source
+tags: [home-office, infrastructure, nas, synology, ubuntu, vps]
+date: 2026-04-03
+---
+
+## Source File
+- [[raw/Home Office/家庭网络环境概览_2026-04-03.md]]
+
+## Summary
+- 核心主题：个人家庭/实验室多节点混合基础设施架构
+- 问题域：内网服务公网暴露、跨服务器端口映射、统一域名入口、多协议代理
+- 方法/机制：FRP 内网穿透 + Caddy 反向代理 + Cloudflare DNS；四层节点结构（VPS → MacMini → NAS → Ubuntu*2）
+- 结论/价值：建立统一的网络拓扑文档，作为所有服务访问入口和故障排查基准
+
+## Key Claims
+- [[VPS1]] 承担 FRPS（frp server）+ Caddy 入口角色，端口 7000 + HTTPS 反向代理
+- [[Mac Mini]] 作为 OpenClaw 主控节点，同时托管 vaultwarden、stq 项目栈（含 n8n/mariadb）、通过 FRP 暴露 vaultwarden
+- [[Synology NAS DS718]] 承载媒体栈（Jellyfin/Navidrome/Calibre）、存储栈（MinIO/Zipline/CloudDrive2）、监控栈（Prometheus/Alertmanager/node_exporter）
+- [[Ubuntu1]] 托管监控全家桶（Grafana/Prometheus/Alertmanager/blackbox/cAdvisor）+ 应用栈（homarr/superset/tiktok_pm/transmission/it-tools）
+- [[Ubuntu2]] 托管 n8n 核心工作流引擎 + Gitea 版本控制 + drawio 图表服务
+- FRP 端口映射统一管理，remotePort 全部落在 VPS1 的不同端口，实现全服务公网 HTTPS 访问
+
+## Key Quotes
+> "n8n 已迁移至 Ubuntu2，Mac Mini 不再暴露 n8n 端口" — 2026-04-03 更新说明
+> "NAS 仅本机监听科学上网代理（socks5://127.0.0.1:20170），其余节点代理均正常" — 科学上网状态记录
+
+## Key Concepts
+- [[FRP内网穿透]]：frpc 客户端 + frps 服务端架构，将内网服务映射至公网
+- [[反向代理]]：Caddy 自动申请 HTTPS 证书，统一域名入口
+- [[多节点基础设施]]：VPS → MacMini → NAS → Ubuntu1/2 四层拓扑
+- [[可观测性]]：Prometheus + Grafana + Alertmanager + blackbox_exporter 全栈监控
+
+## Key Entities
+- [[VPS1]]：RackNerd VPS，FRPS + Caddy 入口节点，IP 192.227.222.142
+- [[Mac Mini]]：OpenClaw 主控节点，托管 stq 全家桶和 vaultwarden
+- [[Synology NAS DS718]]：媒体中心 + 对象存储 + 云盘挂载
+- [[Ubuntu1]]：监控集群 + TikTok PM + homarr 导航面板
+- [[Ubuntu2]]：n8n 引擎 + Gitea + drawio
+- [[Cloudflare]]：DNS 托管 + 免费 CDN + SSL 证书
+
+## Connections
+- [[Ubuntu1]] ← runs_monitoring ← [[Prometheus]] + [[Grafana]]
+- [[Synology NAS DS718]] ← media_stack ← [[Jellyfin]] + [[Navidrome]] + [[Calibre]]
+- [[VPS1]] ← provides_public_access ← [[FRP内网穿透]]
+- [[Ubuntu2]] ← runs_n8n ← [[n8n]] workflow engine
+- [[Mac Mini]] ← hosts_openclaw ← [[OpenClaw]]
+
+## Contradictions
+- 与 wiki/sources/其他服务器配置文档：
+  - 冲突点：早期配置中 n8n 部署在 Mac Mini，当前版本已迁移至 Ubuntu2
+  - 当前观点：n8n 应独立部署，隔离主控节点
+  - 对方观点：早期单节点部署方案
+
+## Infrastructure Topology
+
+```
+公网 Internet
+    │
+    ▼
+[VPS1: 192.227.222.142] ─ FRPS :7000 + Caddy HTTPS
+    │
+    │ FRP tunnels
+    ▼
+┌─────────────────────────────────────────────┐
+│  内网 192.168.3.0/24                        │
+│                                             │
+│  [MacMini: 192.168.3.189]                   │
+│    OpenClaw / vaultwarden / stq            │
+│                                             │
+│  [Synology NAS: 192.168.3.17]              │
+│    Jellyfin / MinIO / Zipline / Prometheus  │
+│                                             │
+│  [Ubuntu1: 192.168.3.47]                   │
+│    Grafana / Prometheus / homarr / n8n      │
+│                                             │
+│  [Ubuntu2: 192.168.3.45]                   │
+│    n8n / Gitea / drawio                    │
+└─────────────────────────────────────────────┘
+```
+
+## FRP Port Mapping Summary
+
+| 服务 | 目标服务器 | remotePort |
+|------|-----------|------------|
+| vaultwarden | macmini | 15151 |
+| nas.ishenwei.online | NAS | 15000 |
+| n8n.ishenwei.online | ubuntu2 | 15679 |
+| grafana.ishenwei.online | ubuntu1 | 13000 |
+| jellyfin.ishenwei.online | NAS | 18096 |
+| navidrome.ishenwei.online | NAS | 14533 |
+| superset.ishenwei.online | ubuntu1 | 18777 |
+| tk.ishenwei.online | ubuntu1 | 18888 |
+| tk-dev.ishenwei.online | ubuntu2 | 18889 |
+| drawio.ishenwei.online | ubuntu2 | 18085 |
+| transmission.ishenwei.online | ubuntu1 | 19091 |
+| portainer1.ishenwei.online | ubuntu1 | 19443 |
--- a/wiki/sources/普通人如何在AI时代赚钱.md
+++ b/wiki/sources/普通人如何在AI时代赚钱.md
@@ -1,44 +1,47 @@
 ---
-title: "不谈技术：普通人该怎么在AI时代赚钱"
+title: "不谈技术：普通人该怎么在AI时代赚钱？"
 type: source
-tags: [ai, 赚钱, 思维模型]
-date: 2026-03-31
+tags: [ai-era, wealth, philosophy, steve-jobs, entrepreneurship]
+date: 2026-01-01
 ---

 ## Source File
 - [[raw/微信公众号/不谈技术：普通人该怎么在AI时代赚钱？]]

 ## Summary
- 核心主题：AI 时代普通人赚钱的三个核心原则：品味值钱、端到端做事、用死亡过滤器找到真正的热爱
- 问题域：普通人面对 AI 浪潮的被动心态（"我怎么不被淹死"）需要转化为主动框架（"AI 让我能做到什么"）
- 方法/机制：通过三个过滤器（品味/端到端/死亡）重构个人战略定位
- 结论/价值：AI 不会让普通人变富，但会让那些知道自己要做什么、且对品质有执念的人变得极其强大
+- 核心主题：AI时代赚钱思维框架——以乔布斯视角重新定义"普通人"与AI的关系
+- 问题域：「普通人怎么在AI时代赚钱」是错误的问题框架，将自己置于被动挨打位置
+- 方法/机制：三大原则——品味值钱、端到端做事、死亡过滤器筛选热爱
+- 结论/价值：正确问题是「AI让我能做到什么以前做不到的事」，AI 是放大器而非保护伞

 ## Key Claims
- 品味是护城河：AI 工具民主化后，90% 的人用 AI 生成的是垃圾，因为他们不知道什么是真正好的；能判断 10 个方案中哪个是 insanly great 的人，比只会点"生成"的人强一百倍
- 端到端优于零件：别做别人 AI 流水线上的螺丝钉，做从 idea 到 product 的完整闭环；一个人用 AI 做完整 App，胜过 100 人团队里当"AI 提示词工程师"
- 死亡过滤器：每天早上问"如果今天是最后一天，我还愿意做这件事吗"；不是问"什么 AI 技能最赚钱"，而是问自己对什么有 genuine 的热爱和 curiosity
- 护城河逻辑：天赋/资源/运气都不是根本原因，愿意对一千件事说 No、只对一件事说 Yes 并做到 insanly great 才是核心差异
- AI 赋能逻辑：某领域八九十分的人 + AI 横向扩展，AI 是充分非必要条件；对品质有执念的人 + AI = 极其强大
+- 品味（判断什么是真正好的）是 AI 时代真正的护城河，AI 工具民主化后 90% 的人做出的是 shit
+- 端到端优于做零件——一个人用 AI 做完整 App 比在 100 人团队当"AI 提示词工程师"强一万倍
+- 死亡过滤器：每天问自己如果今天是最后一天还会不会做这事，筛选真正热爱
+- "普通人"与"不普通人"的核心区别是愿不愿意对 1000 件事说 No，只对一件事说 Yes

 ## Key Quotes
-> "'普通人怎么在AI时代赚钱'——这个问题的框架是错的。你把自己放在一个被动的位置上。正确的问题是：AI 让我能做到什么以前做不到的事？" — 乔布斯.skill
-> "90%的人用AI生成的东西是shit。因为他们不知道什么是好的。" — 乔布斯.skill
-> "一个人用AI做出一个完整的App，比一个100人的团队里当'AI提示词工程师'强一万倍。" — 乔布斯.skill
-> "AI不会让普通人变富。AI会让那些知道自己要做什么、并且对品质有执念的人变得极其强大。" — 乔布斯.skill
+> "Stop. 你的问题本身就有问题。" — 乔布斯.skill 开篇
+> "品味就是你的护城河。你能判断 AI 给你的 10 个方案里哪个是 insanely great 的，你就比那些只会点'生成'按钮的人强一百倍。" — 核心论点
+> "别做别人 AI 流水线上的一个螺丝钉，因为螺丝钉是最容易被替换的。" — 端到端原则
+> "AI 不会让普通人变富。AI 会让那些知道自己要做什么、并且对品质有执念的人变得极其强大。" — 结论

 ## Key Concepts
- [[品味]]：区分 AI 使用者高低的根本能力，能判断什么是真正好的（insanly great）
+- [[品味]]：AI 时代真正的护城河，能判断什么是真正好的（insanly great）而非只会点生成按钮
 - [[端到端]]：从 idea 到 product 的完整闭环，不做别人 AI 流水线上的零件
- [[死亡过滤器]]：每天问自己是否还愿意做这件事，是筛选真正热爱的决策工具
- [[超级个体]]：某领域八九十分 + AI 横向扩展，AI 是充分非必要条件
+- [[死亡过滤器]]：每天问自己如果今天是最后一天还会不会做这事，筛选真正热爱
+- [[乔布斯.skill]]：本文框架来源，以乔布斯视角解读 AI 时代赚钱思维
+- [[底层能力]] ← 相关概念 ← [[天才地带]]：能产生心流的活动区域
+- [[Ikigai]] ← 相关框架 ← 四圈交集：热情 × 擅长 × 市场需要 × 能获报酬
+
+## Key Entities
+- [[乔布斯]]：本文思维框架的灵感来源，"品味+端到端+死亡过滤器"三原则的提出者
+- [[史蒂夫·乔布斯]] ← 同 ← [[乔布斯]]

 ## Connections
- [[品味]] ← 核心区分力 ← AI时代竞争力
- [[端到端]] ← 护城河构建 ← 不做零件
- [[死亡过滤器]] ← 决策框架 ← 筛选真正的热爱
- [[超级个体]] ← 最终形态 ← [[品味]] + [[端到端]] + AI 能力
-
-## Contradictions
- 与"学一个 AI 工具就能找到工作"的主流观点相反：零件思维（成为别人流水线的一环）是最容易被 AI 替代的位置
- 与"什么 AI 技能最赚钱"的提问方式相反：问别人问题是零件思维，问自己什么是真正的热爱才是端到端思维
+- [[品味]] ← 核心概念 ← [[AI时代赚钱三原则]]（本文）
+- [[端到端]] ← 核心概念 ← [[AI时代赚钱三原则]]（本文）
+- [[死亡过滤器]] ← 核心概念 ← [[AI时代赚钱三原则]]（本文）
+- [[普通人如何在AI时代赚钱]] ← 关联 ← [[一人公司]]（产品漏斗×内容矩阵×反向金字塔体系）
+- [[AI时代赚钱三原则]] ← 来源 ← [[乔布斯.skill]]
+- [[底层能力]] ← 相关 ← [[天才地带]]
--- a/wiki/sources/用Docker安装Jellyfin.md
+++ b/wiki/sources/用Docker安装Jellyfin.md
@@ -0,0 +1,78 @@
+---
+title: "用Docker安装Jellyfin"
+type: source
+tags: [docker, jellyfin, media-server, synology, nas]
+date: 2026-04-03
+---
+
+## Source File
+- [[raw/Home Office/用Docker安装Jellyfin.md]]
+
+## Summary
+- 核心主题：Synology NAS Docker 部署 Jellyfin 开源媒体服务器
+- 问题域：自托管家庭媒体库，支撑 Plex 对抗的商业闭源方案
+- 方法/机制：nyanmisaka/jellyfin 镜像 + Intel QuickSync 硬件转码 + 群晖 UID/GID 固定 + 只读媒体卷保护
+- 结论/价值：完整的 Jellyfin Docker Compose 配置，含硬件转码、环境变量、字体挂载、端口和重启策略
+
+## Key Claims
+- nyanmisaka/jellyfin 镜像提供优化的 Jellyfin 构建，修复官方镜像转码兼容性问题
+- 通过 --devices /dev/dri:/dev/dri 挂载 Intel GPU，实现硬件 QuickSync 转码，降低 CPU 负载
+- 容器使用 user: "1026:100" 固定为群晖默认用户，避免权限问题
+- /volume1/docker/jellyfin/fonts 目录以 :ro 只读挂载，防止字体被容器修改
+- JELLYFIN_PublishedServerUrl 环境变量设置公网访问地址，供外部发现服务
+- restart: unless-stopped 保证容器崩溃后自动重启
+
+## Key Quotes
+> "群晖建议使用具体的 UID:GID" — Docker 部署最佳实践
+> "核心优化：挂载硬件渲染设备以实现 Intel QuickSync 转码" — 性能优化关键
+
+## Key Concepts
+- [[硬件转码]]：Intel QuickSync 利用 GPU 加速视频格式转换，减轻 CPU 负担
+- [[媒体刮削]]：Jellyfin 自动从 TMDB/TVDB 等源获取元数据（标题/封面/简介）
+- [[Docker容器化]]：隔离运行环境影响，docker-compose 一键部署
+- [[只读挂载]]：保护源文件不被容器内进程意外修改
+- [[Plex]]：Jellyfin 是 Plex 的开源分支，功能高度同构
+
+## Key Entities
+- [[Jellyfin]]：开源媒体服务器，Plex 的自由软件替代品
+- [[Synology NAS]]：群晖 NAS，Docker 宿主机，存储媒体文件
+- [[nyanmisaka/jellyfin]]：优化过的 Jellyfin 第三方镜像，内置转码支持
+
+## Connections
+- [[Jellyfin]] ← runs_on ← [[Synology NAS]]
+- [[Jellyfin]] ← transcodes_with ← Intel QuickSync (via /dev/dri)
+- [[Jellyfin]] ← serves_media ← /volume2/movie + /volume1/TV shows
+- [[家庭网络环境概览_2026-04-03]] ← 暴露公网访问 ← jellyfin.ishenwei.online:18096
+
+## Jellyfin Docker Compose 核心配置
+
+```yaml
+services:
+  jellyfin:
+    image: nyanmisaka/jellyfin:latest
+    container_name: jellyfin
+    user: "1026:100"
+    ports:
+      - 8096:8096/tcp
+      - 7359:7359/udp  # 客户端自动发现
+    volumes:
+      - /volume1/docker/jellyfin/config:/config
+      - /volume1/docker/jellyfin/cache:/cache
+      - /volume2/movie:/media
+      - /volume1/TV shows:/media2
+      - /volume1/docker/jellyfin/fonts:/usr/local/share/fonts/custom:ro
+    environment:
+      - JELLYFIN_PublishedServerUrl=http://jellyfin.ishenwei.online
+      - TZ=Asia/Shanghai
+    devices:
+      - /dev/dri:/dev/dri  # Intel GPU 硬件转码
+    restart: unless-stopped
+    extra_hosts:
+      - host.docker.internal:host-gateway
+```
+
+## Contradictions
+- 与 [[Synology NAS + Xiaoya Alist + CloudDrvie2+ Plex to Build Media Platform]]：
+  - 冲突点：Plex vs Jellyfin 作为媒体服务器的选择
+  - 当前观点：Jellyfin 开源自托管，完全免费
+  - 对方观点：Plex 有更好的商业生态和客户端支持