Auto-sync: 2026-04-28 16:03

wiki/sources/blogwatcher-daily收藏.md

@@ -1,58 +1,73 @@
 ---
 title: "Blogwatcher Daily 技能收藏"
 type: source
-tags: [hermes-agent, rss, automation, daily-digest]
+tags: [rss, automation, hermes-agent, skill]
 date: 2026-04-18
 ---
 
 ## Source File
-- [[raw/Skills/blogwatcher-daily收藏.md]]
+- [[Skills/blogwatcher-daily收藏.md]]
 
 ## Summary（用中文描述）
-- 核心主题：RSS/YouTube 订阅频道的自动化监控与每日摘要生成
-- 问题域：个人资讯获取效率——手动逐个打开各频道耗时且容易遗漏更新
-- 方法/机制：Hermes Agent 自定义 Skill，定时抓取 31 个订阅频道，SQLite 去重，每日追加写入 Markdown 日报
-- 结论/价值：将信息获取自动化，用户每天早上只需阅读一篇摘要即可掌握所有频道动态
+- 核心主题：Hermes Agent 自定义技能 blogwatcher-daily，实现 RSS/YouTube 订阅自动化监控与每日摘要生成
+- 问题域：个人资讯获取与信息聚合
+- 方法/机制：RSSHub 转换 YouTube 频道为 RSS + feedparser 解析 + SQLite 去重 + Cron 定时调度
+- 结论/价值：每天自动整理 31 个订阅频道的新文章，减少信息过载，提高阅读效率
 
 ## Key Claims（用中文描述）
-- Hermes Agent 通过自定义 Skill `blogwatcher-daily` 实现 31 个订阅频道的自动化监控
-- 每日扫描（Cron Job）自动追加新文章到 `YYYY-MM-DD.md` 日报，避免覆盖历史内容
-- YouTube 频道通过 RSSHub 本地部署代理转换为 RSS Feed，绕过直接访问限制
-- SQLite 数据库按 URL 去重，已读链接不重复写入
-- 强制回扫（`--all`）写入独立文件 `all-YYYY-MM-DD.md`，不污染日常日报
-- 支持 `--scan-only` 调试模式，只打印结果不写文件
+- Hermes Agent 通过 blogwatcher-daily 技能实现 31 个 RSS/YouTube 频道的自动化监控
+- RSSHub 将 YouTube Channel ID 转换为 RSS Feed，解决 YouTube 订阅源获取问题
+- feedparser 库支持 RSS 1.0/2.0/Atom 格式，自动处理 GB2312/GBK/ISO-8859-1 编码和畸形 XML
+- SQLite 数据库按 URL 排重，已读链接不重复写入，避免信息冗余
+- Cron 定时任务（每天早上 6:00）自动调用 skill 脚本，结果推送 Telegram 通知
 
 ## Key Quotes
-> "📊 扫描完成: 共发现 12 篇新文章" — 日常扫描输出示例
-
-> "新增订阅需要补历史、某个频道很久没看想批量回顾" — 强制回扫适用场景
-
-> "wikiHow 禁止所有爬虫，无法抓取，永远返回 0 篇" — 已知限制说明
+> "RSS 解析库：feedparser（支持 RSS 1.0/2.0/Atom、GB2312/GBK 编码、畸形 XML）" — 技术选型说明
+> "追加写入：日常扫描正确追加到日报，不覆盖历史内容" — 数据持久化策略
+> "wikiHow 禁止所有爬虫，无法抓取，永远返回 0 篇" — 已知的限制
 
 ## Key Concepts
-- [[RSS Monitoring]]：通过 RSS/Atom Feed 订阅网站和 YouTube 频道更新的标准化协议
-- [[Cron Job]]：定时任务调度，每天早上 6:00 自动执行扫描
-- [[RSSHub]]：开源 RSS 生成器，将不支持 RSS 的网站（如 YouTube）转换为 RSS Feed
-- [[feedparser]]：Python RSS 解析库，支持 RSS 1.0/2.0/Atom 及 GB2312/GBK 编码
-- [[Deduplication]]：SQLite 按 URL 排重，避免重复写入
-- [[每日日报]]：追加模式日记文件，每天一篇，持续积累
-- [[增量写入]]：日常扫描追加到日报，强制回扫写入独立文件，二者互不干扰
+- [[RSSHub]]：开源 RSS 生成器，将无 RSS 的网站/YouTube 频道转为 RSS Feed，部署在 `http://192.168.3.45:1200`
+- [[feedparser]]：Python RSS/Atom 解析库，支持多种编码和畸形 XML，是本技能的核心解析引擎
+- [[SQLite 去重机制]]：通过 SQLite 数据库按 URL 排重，已读链接不重复写入每日日报
+- [[Hermes Agent]]：AI Agent 平台，blogwatcher-daily 是其自定义技能之一，通过 cron 定时调度执行
+- [[Cron 定时任务]]：每天 `0 6 * * *` 执行，Job ID `ecdd35bb7df3`，通过 `deliver=origin` 推送 Telegram 通知
 
 ## Key Entities
-- [[Hermes Agent]]：运行 blogwatcher-daily Skill 的 AI Agent 平台，通过 Cron Job 调度
-- [[RSSHub]]：本地部署的 RSSHub 实例（`http://192.168.3.45:1200`），用于转换 YouTube 频道为 RSS
-- [[blogwatcher-daily]]：Hermes Agent 自定义 Skill，核心脚本为 `blogwatcher-daily.py`
-- [[feedparser]]：Python RSS 解析库，解决 RSS 1.0、GB2312 乱码、畸形 XML 等兼容性问题
+- [[Hermes Agent]]：技能运行平台，提供 cron 调度和 Telegram 通知能力
+- RSSHub（`http://192.168.3.45:1200`）：本地部署的 RSSHub 实例，用于转换 YouTube 频道为 RSS
+- blogwatcher-daily 脚本：主脚本位于 `~/.hermes/skills/custom/blogwatcher-daily/scripts/blogwatcher-daily.py`
 
 ## Connections
-- [[blogwatcher-daily收藏]] ← depends_on ← [[RSSHub]]
-- [[blogwatcher-daily收藏]] ← depends_on ← [[feedparser]]
-- [[blogwatcher-daily收藏]] ← depends_on ← [[每日日报]]
-- [[blogwatcher-daily收藏]] ← extends ← [[multi-source-tech-news-digest]]
+- [[Hermes Agent]] ← runs ← [[blogwatcher-daily]]
+- [[blogwatcher-daily]] ← uses ← [[RSSHub]]
+- [[blogwatcher-daily]] ← uses ← [[feedparser]]
+- [[blogwatcher-daily]] ← stores state in ← [[SQLite 去重机制]]
+- [[blogwatcher-daily]] ← scheduled by ← [[Cron 定时任务]]
 
 ## Contradictions
-- 与 [[multi-source-tech-news-digest]]：
-  - 冲突点：两者都是 RSS 多源新闻聚合方案
-  - 当前观点：blogwatcher-daily 侧重 YouTube + RSS 直订的本地化方案，覆盖 31 个固定频道
-  - 对方观点：multi-source-tech-news-digest 侧重多平台（RSS + Twitter + GitHub）的大规模聚合，支持动态添加来源
-  - 说明：两者定位互补，blogwatcher-daily 是轻量级固定订阅方案，后者是大规模动态监控方案
+- 暂无发现与其他 Wiki 页面的冲突
+
+## 技术细节
+
+| 维度 | 技术选型 |
+|------|----------|
+| RSS 解析 | feedparser（支持 RSS 1.0/2.0/Atom） |
+| YouTube 支持 | RSSHub（`http://192.168.3.45:1200`） |
+| 去重存储 | SQLite（`blogwatcher.db`） |
+| 编码处理 | 自动检测 GB2312、GBK、ISO-8859-1 |
+| 定时调度 | Cron `0 6 * * *` |
+| 通知方式 | Telegram（`deliver=origin`） |
+
+## 已解决的问题
+- ✅ RSS 1.0 支持：Slashdot 使用 RSS 1.0，feedparser 解决
+- ✅ GB2312 乱码：feedparser 自动处理
+- ✅ 畸形 XML：feedparser 兜底
+- ✅ YouTube RSSHub：绕过 YouTube 直接访问限制
+- ✅ 追加写入：日报模式不覆盖历史
+- ✅ 独立 force-all：强制回扫写入独立文件
+
+## 已知限制
+- wikiHow 禁止爬虫，永远返回 0 篇
+- FeedBurner 频道（電腦玩物、阿榮福利味）RSSHub 可能不稳定
+- `--all` 强制回扫不要加入 cron，仅作例外操作

wiki/sources/ctp-topic-1-gruntwork-landing-zone-architecture.md

@@ -3,7 +3,7 @@ title: "CTP Topic 1 Gruntwork Landing Zone Architecture"
 type: source
 tags: [AWS, Landing-Zone, Gruntwork, CTP, Terraform, CI/CD]
 sources: []
-last_updated: 2026-04-14
+last_updated: 2026-05-06
 ---
 
 ## Source File

wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md

@@ -1,5 +1,5 @@
 ---
-title: "CTP Topic 14 Octane Hub on AWS Real Life Experience Moving Production Services"
+title: "CTP Topic 14 Octane Hub on AWS: Real-Life Experiences Moving Production Services"
 type: source
 tags:
   - AWS
@@ -7,63 +7,63 @@ tags:
   - Migration
   - CTP
   - Landing-Zone
-date: 2026-04-14
+sources: []
+last_updated: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]]
 
 ## Summary（用中文描述）
-- 核心主题：Octane Hub CTO Holger Rode 分享将生产服务从 Bibling Lab 数据中心迁移到 AWS Landing Zone 的实战经验
-- 问题域：企业级 Docker 容器化工作负载的云迁移规划与实施
-- 方法/机制：使用 AWS Landing Zone 账户体系，结合 Packer 构建 AMI、Terraform/TerraGrunt 部署、VPC Transit Gateway 网络互联、Route 53 DNS 管理
-- 结论/价值：提供从物理数据中心向 AWS 云端无缝迁移的具体路径，涵盖存储选型（EFS vs EBS）、网络配置、DNS 设置及 IaC 部署演进过程
+
+- **核心主题**：Octane Hub CTO Holger Rode 分享将生产服务从本地 Bibling Lab 数据中心迁移到 AWS Landing Zone 的实战经验
+- **问题域**：企业云迁移中的技术选型、网络配置、存储方案及 IaC 实践
+- **方法/机制**：Docker 容器化工作负载迁移；使用 Packer 构建 AMI + Terraform/TerraGrunt 部署；VPC Transit Gateway + 标签系统管理网络访问
+- **结论/价值**：提供从本地物理服务器迁移到 AWS 云的真实路径，展示 EBS vs EFS 存储选型教训、网络协调流程及未来演进方向
 
 ## Key Claims（用中文描述）
-- Octane Hub 团队通过 Docker 容器化主要 Web 应用（QuickSee、Release Manager、Patch Manager、安全程序板等），结合约 10TB 文件存储和 MSSQL 数据库，实现从 Bibling Lab 三台物理服务器向 AWS 的完整迁移
-- 云迁移动因源于 Bibling 数据中心即将关闭，云转型计划提供 POC Landing Zone（5月）和生产账户（6月），团队目标是无缝过渡、紧密镜像现有设置以避免 Go Live 期间进行重大技术变更
-- EFS 不适用于需要高性能数据库场景（数据库无法直接在 EFS 上运行），EBS 更适合实时数据库，EFS 适用于备份存储
-- IaC 部署从控制台脚本演进为 Packer 构建 AMI + Terraform/TerraGrunt 部署，实现了可重复、可审计的部署流程
+
+- Octane Hub 团队通过 Docker 容器化运行 QuickSee、Release Manager、Patch Manager 等多个 Web 应用，并管理约 10TB 文件存储和大型 MSSQL 数据库
+- 云迁移动因来自 Bibling 数据中心关闭，通过云转型计划获得 Landing Zone 账户访问权限（POC 账户5月，生产账户6月）
+- EFS 因性能问题（数据库无法直接在 EFS 上运行）不适用于生产数据库，最终采用 EBS 用于实时数据库、EFS 用于备份
+- 部署方式从控制台脚本演进为 Packer 构建 AMI + Terraform/TerraGrunt 部署，实现基础设施即代码
+- DNS 配置使用 CNAME 指向 AWS software infra.net 域，通过 Route 53 管理
 
 ## Key Quotes
-> "Holger Rode（Octane Hub CTO 软件工厂团队负责人）分享了 Octane Hub 云设计考虑因素、学习曲线、网络和安全要求以及常见陷阱。" — 视频演讲主题介绍
 
-> "从控制台脚本演变为使用 Packer 构建 AMI，使用 Terraform/TerraGrunt 部署。" — IaC 演进路径
+> "Holger Rode（Octane Hub CTO 软件工厂团队负责人）分享了 Octane Hub 云设计考虑因素、学习曲线、网络和安全要求以及常见陷阱。" — 演讲者背景介绍
+
+> "VPC Transit Gateway 并实施标签系统管理访问" — 网络架构方案
 
 ## Key Concepts
-- [[Docker-Containerization]]：Octane Hub 的主要部署模式，运行 QuickSee、Release Manager、Patch Manager 等 Web 应用
+
+- [[Docker容器化]]：Octane Hub 的主要部署模式，用于运行 QuickSee、Release Manager、Patch Manager 等 Web 应用程序
 - [[Packer]] + [[Terraform]]/TerraGrunt：基础设施即代码的部署流程，从控制台脚本演进而来
-- [[VPC-Transit-Gateway]]：AWS 网络互联解决方案，实现多 VPC 之间的安全通信
-- [[EFS-vs-EBS]]：文件存储与块存储的性能差异——EFS 适合备份，EBS 适合实时数据库
-- [[AWS-Landing-Zone]]：多账户 AWS 环境架构，提供 POC 和生产账户分离
+- [[VPC Transit Gateway]]：AWS 网络互联解决方案，用于连接多个 VPC
+- [[AWS Landing Zone]]：AWS 多账户架构框架，Octane Hub 通过该架构迁移生产服务
+- [[EBS vs EFS]]：块存储与文件存储的性能差异——EFS 不适合直接运行数据库，最终选择 EBS 用于实时数据库
 
 ## Key Entities
-- [[Holger-Rode]]：Octane Hub CTO，软件工厂团队负责人，云迁移项目负责人
-- [[Octane-Hub]]：软件工厂团队名称，主导从 Bibling Lab 向 AWS 的生产服务迁移
-- [[Bibing-Lab]]：Octane Hub 原有数据中心，即将关闭，触发云迁移
-- [[QuickSee]]：Octane Hub 托管的 Web 应用之一
-- [[Release-Manager]]：Octane Hub 托管的 Web 应用之一
-- [[Patch-Manager]]：Octane Hub 托管的 Web 应用之一
-- [[MSSQL]]：Octane Hub 原有数据库，计划迁移到 Postgres
-- [[AWS]]：目标云平台
-- [[Packer]]：AMI 构建工具
-- [[Terraform]]/TerraGrunt：基础设施即代码部署工具
+
+- [[Octane Hub]]：一家使用 Docker 容器运行多个 Web 应用的公司，团队负责人为 CTO Holger Rode
+- [[Holger Rode]]：Octane Hub CTO 软件工厂团队负责人，本次分享的主讲人
+- [[Bibling Lab]]：Octane Hub 之前的托管数据中心，拥有三台物理服务器和多台虚拟机，即将关闭
+- [[AWS]]：目标云平台，通过 Landing Zone 架构承载 Octane Hub 的生产工作负载
 
 ## Connections
-- [[AWS-Landing-Zone]] ← depends_on ← [[VPC-Transit-Gateway]]
-- [[Octane-Hub]] ← migrated_from ← [[Bibing-Lab]]
-- [[Docker-Containerization]] ← uses ← [[Packer]] + [[Terraform]]
-- [[ctp-topic-7-saas-landing-zone-design]] ← extends ← [[AWS-Landing-Zone]]
-- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← related_to ← [[AWS-Landing-Zone]]
+
+- [[ctp-topic-7-saas-landing-zone-design]] ← related_to ← [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]]
+- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← related_to ← [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]]
+- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] ← related_to ← [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]]
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← extends ← [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]]
 
 ## Contradictions
-- 与 [[ctp-topic-7-saas-landing-zone-design]] 的设计视角：
-  - 冲突点：SaaS Landing Zone 侧重多租户架构设计，本视频侧重单体团队的实际迁移路径
-  - 当前观点：Octane Hub 案例强调紧密镜像现有设置、避免 Go Live 期间重大变更
-  - 对方观点：SaaS Landing Zone 设计更关注长期架构演进和租户隔离
 
-## Next Steps（迁移路线图）
-- 改进 DR（灾难恢复）和高可用性
-- 通过最佳匹配存储选项（S3）进行成本优化
-- 从 MSSQL 迁移到 Postgres
+- 暂无发现与其他页面的直接冲突。存储选型（EBS vs EFS）教训可与 [[ctp-topic-51-architecting-with-aws-purpose-built-databases]] 相互补充。
+
+## Future Roadmap
+
+- 改进 DR 和高可用性
+- 通过 S3 优化存储成本
+- 数据库从 MSSQL 迁移到 Postgres
 - 可能迁移到 AWS ECS 服务

wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md

@@ -1,59 +1,51 @@
 ---
 title: "CTP Topic 17 Active Directory Services in Gruntwork AWS LZs"
 type: source
-tags: [AWS, Landing-Zone, AD, Gruntwork, CTP]
-sources: []
-last_updated: 2026-04-14
+tags:
+  - AWS
+  - Landing-Zone
+  - AD
+  - Gruntwork
+  - CTP
+date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md]]
 
 ## Summary（用中文描述）
-- 核心主题：在 Gruntwork AWS Landing Zones 架构中集成与管理 Active Directory (AD) 服务的核心实践
-- 问题域：企业级 AWS 多环境（研发/生产）的 AD 域名规划、自动化域加入、以及开发者自助服务
-- 方法/机制：
-  - 双域名策略：`swinford.net`（研发实验室 R&D Labs）vs `intsas.local`（生产/SAS 环境）
-  - SRE 团队预制 AMI，内置 PowerShell（Windows）/Shell（Linux）域加入脚本
-  - Terraform `user_data` 触发自动域加入流程
-  - MIM（Microsoft Identity Manager）提供研发环境安全组自助管理
-  - SMACKS 工单系统处理生产环境账号申请
-- 结论/价值：旧域名（`infra`、`AST`）已在 Gruntwork LZ 中废弃，提供了清晰的迁移路径和所有权归属建议
+- 核心主题：在 Gruntwork AWS Landing Zones 架构中集成与管理 Active Directory 服务
+- 问题域：多环境（研发/生产/SAS）下的 AD 域名规划与自动化域加入
+- 方法/机制：SRE 预制 AMI + User Data 脚本实现 Windows/Linux 实例自动加入不同 AD 域；研发环境用 MIM 自助服务，生产环境走 SMACKS 工单
+- 结论/价值：统一域名规范（`swinford.net` / `intsas.local`），废弃旧有 `infra` / `AST` 域，提供清晰的迁移路径与所有权归属
 
 ## Key Claims（用中文描述）
-- Gruntwork Landing Zones 按环境类型（研发 vs 生产）分别使用不同的 AD 域名，以满足隔离性和合规审计需求
-- Windows 实例通过 Terraform `user_data` 调用 SRE 预制 AMI 中的 PowerShell 脚本，实现自动化域加入、旧对象清理和本地管理员分配
-- Linux 实例通过安全动态更新（Secure Dynamic Updates）机制自动向 Windows DNS 服务器注册 DNS A 记录
-- 旧域名 `infra` 和 `AST` 在新 Gruntwork LZ 中已被废弃，开发者必须迁移至新域名架构
-- R&D 环境支持 MIM 自助服务工具，生产/SAS 环境通过 SMACKS 工单系统申请账号
+- R&D Labs 环境统一使用 `swinford.net` AD 域名，支持开发者的自助服务管理
+- 生产环境与分阶段 SAS 环境统一使用 `intsas.local` AD 域名，强调资源所有权与审计
+- 旧有的 `infra` 和 `AST` 域名在新的 Gruntwork Landing Zone 中已被废弃
+- Windows 实例通过 SRE 提供的预制 AMI + Terraform `user_data` 中的 PowerShell 脚本实现自动域加入（命名/权限/旧对象清理）
+- Linux 实例通过 SRE 提供的 Shell 脚本 + 安全动态更新（Secure Dynamic Updates）自动注册 DNS A 记录到 Windows DNS 服务器
+- R&D 环境通过 MIM（Microsoft Identity Manager）提供安全组管理和权限申请的自助服务
+- 生产/SAS 环境的 AD 操作需通过 SMACKS 工单系统提交
 
 ## Key Quotes
-> "本次视频是 DevOps 云学习系列课程之一，重点介绍了在 Gruntwork AWS Landing Zones 架构中集成与管理 Active Directory (AD) 服务的核心实践。演讲者 Paul 详细阐述了两种主要环境的域名配置：研发实验室（R&D Labs）统一使用 `swinford.net` 域名，而生产与分阶段 SAS 环境则采用 `intsas.local`。" — 视频摘要
-
-> "旧有的 `infra` 和 `AST` 域名在新的 Gruntwork 落地页中已被废弃，并为用户提供了相应的迁移路径和所有权归属建议。" — 视频摘要
+> "R&D Labs 统一使用 `swinford.net` 域名；生产与 SAS 环境统一使用 `intsas.local` 域名；旧的 `infra` 和 `AST` 域名在 Gruntwork Landing Zones 中已被废弃。" — Paul
 
 ## Key Concepts
-- [[Gruntwork Landing Zones]]：预配置的、基于最佳实践的 AWS 基础架构框架，分为 R&D Labs 和 SAS 两种环境类型
-- [[swinford.net]]：专门用于研发实验室（R&D Labs）环境的 Active Directory 域名，支持 MIM 自助服务管理
-- [[intsas.local]]：用于生产和分阶段 SAS 环境的内部 Active Directory 域名，强调资源所有权归属和审计合规
-- [[SRE-provided AMIs]]：由 SRE 团队预先构建的机器镜像，内置了用于自动加入域的 PowerShell（Windows）和 Shell（Linux）脚本
-- [[User Data]]：在 AWS EC2 实例启动时执行的脚本数据，本视频中用于触发自动化的域加入流程
-- [[MIM (Microsoft Identity Manager)]]：用于 R&D 环境中安全组管理和权限申请的自助服务解决方案
-- [[SMACKS Ticket]]：内部服务管理工单系统，用于申请新账号、重置密码或处理复杂的生产环境变更
-- [[Secure Dynamic Updates]]：一种 DNS 安全机制，允许 Linux 系统在加入域时向 Windows DNS 服务器安全地注册其 A 记录
+- [[Gruntwork Landing Zones]]：预配置的、基于最佳实践的 AWS 基础架构框架，分 R&D Labs 和 SAS 两种环境类型
+- [[Domain Join]]：将计算机实例自动或手动加入 Active Directory 域的过程
+- [[Secure Dynamic Updates]]：一种 DNS 安全机制，允许 Linux 系统在加入域时向 Windows DNS 服务器安全注册 A 记录
+- [[Microsoft Identity Manager (MIM)]]：用于 R&D 环境安全组管理和权限申请的自助服务解决方案
+- [[User Data]]：AWS 实例启动时执行的脚本数据，用于触发自动化的域加入流程
 
 ## Key Entities
-- [[Paul]]：CTP Topic 17 讲师，Gruntwork AWS LZs AD 集成方案的讲解者
-- [[Gruntwork]]：提供 Landing Zones 基础设施框架的团队/组织
-- [[SRE Team]]：负责构建和维护预制 AMI 的 Site Reliability Engineering 团队
-- [[MIM]]：Microsoft Identity Manager，R&D 环境的安全组自助管理工具
-- [[SMACKS]]：内部服务管理工单系统，用于生产/SAS 环境的账号申请和变更处理
+- [[Paul]]（演讲者）：DevOps 云学习系列课程讲师，主讲 AD 服务集成
+- [[Gruntwork]]：提供 AWS Landing Zone 参考架构的 IaC 公司
 
 ## Connections
-- [[Gruntwork AWS Landing Zones Overview]] ← foundational ← [[CTP Topic 17 Active Directory Services]]
-- [[SRE Standard AMIs and Image Building]] ← source ← [[SRE-provided AMIs]]
-- [[Terraform Single Server Module Deep Dive]] ← deployment mechanism ← [[User Data]]
-- [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]] ← related ← [[AD Integration in AWS LZs]]
+- [[CTP Topic 11 AD Integration and Login using AD Accounts]] ← related_to ← [[CTP Topic 17 Active Directory Services in Gruntwork AWS LZs]]
+- [[CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security]] ← related_to ← [[CTP Topic 17 Active Directory Services in Gruntwork AWS LZs]]
+- [[CTP Topic 9 CI CD with Gruntwork]] ← related_to ← [[CTP Topic 17 Active Directory Services in Gruntwork AWS LZs]]
 
 ## Contradictions
-- 暂无检测到与其他 Wiki 页面的冲突
+- 无已知冲突

wiki/sources/ctp-topic-46-netapps-on-aws.md

@@ -1,8 +1,9 @@
 ---
 title: "CTP Topic 46 NetApps on AWS"
 type: source
-tags: [NetApp, AWS, Storage, CTP, Cloud-Storage]
+tags: [NetApp, AWS, Storage, CTP, Cloud-Storage, CVO, ONTAP]
 date: 2026-04-14
+last_updated: 2026-04-26
 ---
 
 ## Source File

wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md

@@ -11,59 +11,52 @@ date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md]]
 
 ## Summary（用中文描述）
-- 核心主题：PostgreSQL 在 Amazon RDS 与 Aurora 两种托管方案之间的核心差异对比
-- 问题域：AWS 云数据库选型——何时选 RDS，何时选 Aurora，成本与性能的权衡
-- 方法/机制：从架构设计、最小实例规格、最大扩展能力、自动扩缩容、故障恢复时间、存储灵活性、端点设计、Blue-Green 部署、监控方案及高可用性能调优等多维度进行系统对比
-- 结论/价值：数据库规模 < 10-20TB 优先选 RDS（成本更低、存储选项更灵活）；超过该规模或有严格 RTO 要求（30 秒）则选 Aurora（跨 AZ 六副本架构、自动故障恢复）
+- 核心主题：PostgreSQL 在 Amazon RDS 与 Aurora 两种托管方案之间的技术差异对比，涵盖性能、成本、架构、灾备与高可用性等维度
+- 问题域：AWS 数据库选型、RTO/RPO 保障、跨区域灾备、存储类型选择
+- 方法/机制：RDS 采用计算与 EBS 存储分离架构，Multi-AZ 通过独立备用节点实现故障切换；Aurora 采用 6 块 EBS 卷横跨 3 个可用区的共享存储集群，由 Amazon 管理副本
+- 结论/价值：为组织在小型数据库（选 RDS）与大型高 IO 数据库（选 Aurora，>10-20TB）之间提供清晰的决策依据
 
 ## Key Claims（用中文描述）
-- RDS 因架构简单、提供更小规格实例，初始成本低于 Aurora；Aurora 最小规格较高
-- Aurora 单集群最大容量和 IO 性能优于 RDS，适合超过 10-20 TB 的数据库
-- Aurora Serverless v2 支持自动扩缩容，但对实例类型、版本和区域有限制
-- Aurora 的 RTO（恢复时间目标）为 30 秒，RDS 为 2 分钟（AZ 故障场景）
-- RDS 提供多种存储类型（GP2、GP3、预置 IOPS、磁性），Aurora 按 IO 计数收费
-- Aurora 采用跨 3 个 AZ 的 6 块 EBS 卷组成的共享集群卷，读副本无需重新复制数据
-- Aurora MySQL 支持 Blue-Green 部署，PostgreSQL 不支持
-- Aurora 使用临时 SSD（短暂存储）用于临时工作，RDS 使用 EBS
+- RDS 提供 GP2、GP3、预配置 IOPS、磁性存储等多种存储类型，存储灵活性更高；Aurora 按 IO 计费，IO 消耗无上限
+- Aurora 最小规格和成本高于 RDS，适合中小型数据库场景选 RDS 更经济
+- Aurora 存储最多支持 64TB，单节点 IO 性能优于 RDS，适合 10-20TB 以上数据库
+- Aurora 自动扩展（Serverless v2）存在实例类型、版本和区域的限制
+- Aurora AZ 故障时 RTO 为 30 秒；RDS 为 2 分钟
+- Aurora MySQL 支持蓝绿部署（Major Version Upgrade）；PostgreSQL 版本不支持
+- Aurora Global 支持跨区域灾备，故障切换无需重新复制数据
+- RDS 跨区域复制为异步，切换时需阻断访问并重建集群
+- Aurora 临时存储使用本地 SSD（ephemeral），固定容量由实例类型决定；RDS 临时存储使用 EBS
 
 ## Key Quotes
-> "Aurora IO is generally unbounded because they're motivated to give you as much IO as you can consume because they're charging you per IO." — Aurora 按 IO 收费机制使其有动力提供尽可能高的 IO
-
-> "With Aurora, you get six EBS volumes. They're spread across three availability zones." — Aurora 跨 3 AZ 的六副本架构是高性能和高可用的基础
+> "Aurora IO is generally unbounded because they're motivated to give you as much IO as you can consume because they're charging you per IO." — Aurora IO 计费模式说明，IO 消耗越多收益越高
 
 > "With RDS, you get to choose multiple different storage mechanisms." — RDS 存储灵活性优势
 
+> "Aurora has a 30-second RTO, compared to RDS's two minutes in the event of an AZ failure." — Aurora 高可用性优势
+
 ## Key Concepts
-- [[RTO（Recovery Time Objective）]]：从故障中恢复的时间目标，Aurora 为 30 秒，RDS 为 2 分钟
-- [[Shared Cluster Volume]]：Aurora 的跨 AZ 共享存储卷，6 块 EBS 卷组成，读副本共享同一数据副本无需重新复制
-- [[Blue-Green Deployment]]：Aurora MySQL 支持主备环境切换式部署，用于大版本升级，PostgreSQL 不支持
-- [[Endpoint Architecture]]：Aurora 提供独立的 Writer Endpoint 和 Reader Endpoint，RDS 仅有一个集群端点
-- [[Aurora Global]]：Aurora 跨区域复制方案，支持干净的托管式切换和故障转移
-- [[Temporary Storage]]：Aurora 使用临时 SSD（短暂存储）处理临时工作，固定大小取决于实例类型
+- [[RTO]]：Recovery Time Objective，故障恢复时间目标，Aurora 为 30 秒，RDS 为 2 分钟
+- [[Multi-AZ]]：多可用区部署，通过备用节点实现故障切换
+- [[Aurora Global]]：Aurora 跨区域数据库，支持干净的托管切换（Managed Switchover），无需重新复制数据
+- [[Blue-Green Deployment]]：蓝绿部署，Aurora MySQL 支持 Major Version Upgrade，PostgreSQL 版本不支持
+- [[Serverless V2]]：Aurora 自动扩展方案，存在实例类型、版本和区域的限制
+- [[JDBC Connection String Overloading]]：通过读写端点配置 JDBC 连接字符串提升韧性
 
 ## Key Entities
-- [[AWS]]：Amazon Web Services，提供 RDS 和 Aurora 两款托管数据库服务
-- [[Amazon RDS]]：关系型数据库服务，计算与存储分离（EBS），支持 Multi-AZ 部署
-- [[Amazon Aurora]]：云原生关系型数据库，6 副本跨 3 AZ 共享集群卷架构
-- [[Greg Klau]]：CTP Topic 66 讲师，主讲 PostgreSQL RDS vs Aurora 差异对比
-- [[EBS]]：Elastic Block Store，RDS 的存储后端；Aurora 的底层存储（6 块卷跨 3 AZ）
-- [[CloudWatch]]：AWS 监控服务，RDS 和 Aurora 均支持
-- [[Performance Insights]]：AWS 数据库性能监控工具，Aurora 和 RDS 均支持
-- [[JDBC]]：Java Database Connectivity，连接串可配置 reader/writer 端点以提升韧性
+- [[Amazon RDS]]：AWS 托管关系型数据库服务，计算与 EBS 存储分离，Multi-AZ 需独立备用节点
+- [[Amazon Aurora]]：AWS 云原生关系型数据库，采用 6 块 EBS 卷跨 3 AZ 共享存储集群，由 Amazon 管理副本，读副本共享同一集群卷无需数据复制
+- [[Greg Klau]]：本次分享的主讲人
 
 ## Connections
 - [[Amazon Aurora]] ← extends ← [[Amazon RDS]]
-- [[RTO（Recovery Time Objective）]] ← depends_on ← [[Shared Cluster Volume]]
-- [[Blue-Green Deployment]] ← supports ← [[Aurora Global]]
-- [[Aurora Global]] ← enables ← [[Multi-Region Failover]]
-- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]] ← related_to ← 本页（AWS 数据库选型）
-- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← related_to ← 本页（灾备策略）
+- [[RTO]] ← improves ← [[Aurora Global]]
+- [[Amazon Aurora]] ← provides ← [[Blue-Green Deployment]]（仅 Aurora MySQL）
 
 ## Contradictions
-- 与 [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]] 冲突：
-  - 冲突点：Terraform 部署 RDS 时对存储类型的选择
-  - 当前观点：Aurora 按 IO 收费适合高 IO 场景，RDS 提供多种存储类型（GP2/GP3/预置 IOPS）适合成本敏感型场景
-  - 对方观点：Terraform IaC 部署关注点是资源标准化和可重复性，存储选型属于运维决策
+- 与 [[RTO vs RPO: Key Differences for Modern Disaster Recovery]] 潜在关联：
+  - 冲突点：RTO 指标的具体数值
+  - 当前观点：本文视频（Greg Klau 分享）指出 Aurora RTO 为 30 秒、RDS 为 2 分钟
+  - 对方观点：[[RTO vs RPO]] 文章可能给出不同数值，建议交叉验证

wiki/sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md

@@ -7,6 +7,8 @@ tags:
   - Backup
   - Enterprise
   - CTP
+  - RTO
+  - RPO
 date: 2026-04-14
 ---
 
@@ -14,62 +16,50 @@ date: 2026-04-14
 - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略，以及如何利用 AWS Backup 服务实现 DR 自动化。
-- 问题域：企业级灾难恢复（DR）规划、高可用（HA）与 DR 的区别、RTO/RPO 指标定义与架构设计。
-- 方法/机制：
-  - HA（高可用）关注系统运行时间和可用性，DR（灾难恢复）关注数据丢失预防和恢复能力
-  - RPO（恢复点目标）定义可接受的数据丢失量，RTO（恢复时间目标）定义可接受的停机时间
-  - AWS Backup 集中化备份服务，支持跨账户、跨区域复制，Vault Lock 防勒索软件
-  - 四级 DR 架构模式：Backup and Restore → Pilot Light → Warm Standby → Active-Active
-  - 增量备份（Incremental Backup）仅备份自上次备份以来的变更，全量备份（Full Backup）每次捕获所有数据
-  - 不可变恢复点（Immutable Recovery Points）+ Vault Lock 合规模式阻止删除
-  - Forensic Account（取证账户）定期测试恢复点并扫描恶意软件
-- 结论/价值：为 Micro Focus 云转型计划提供了完整的 DR 策略框架，从基本概念到 AWS Backup 架构设计，是 [[ctp-topic-44-aws-backup-in-micro-focus]] 的理论基础补充。
+- 核心主题：使用 AWS Backup 构建企业级灾备（DR）策略
+- 问题域：如何在 AWS 云环境中实现数据保护、灾难恢复，并区分高可用性与灾备的关系
+- 方法/机制：Sabith（AWS）系统讲解 RTO/RPO 定义与架构模式（从多活到备份恢复），介绍 AWS Backup 的备份计划（Backup Plans）、备份保管库（Backup Vaults）、跨账户复制（Cross-Account Copy）、Vault Lock 不可变性等核心功能
+- 结论/价值：AWS Backup 作为全托管策略驱动型备份服务，结合 Organizations 跨账户管理和 Audit Manager 合规报告，可构建完整的企业级灾备体系
 
 ## Key Claims（用中文描述）
-- 高可用（HA）衡量系统执行其功能的持续性，通过平均故障间隔时间（MTBF）衡量；灾难恢复（DR）专注于防止数据丢失和系统恢复，HA 专注于系统运行时间和可用性。
-- RPO 定义组织可接受的最大数据丢失量（时间窗口），RTO 定义组织可接受的最大停机时间，两者共同决定 DR 架构选型和成本投入。
-- AWS Backup 是完全托管的、基于策略的备份服务，通过 Backup Plans（备份计划）定义何时备份什么、通过什么方式备份，并将恢复点存储在 Backup Vaults（备份保管库）中。
-- AWS Backup 支持与 AWS Organizations 集成，实现跨账户备份复制（Cross-Account Backup），建议使用独立的 Vault/Bunker Account 存储备份副本，与工作负载账户隔离。
-- 完整备份（Full Backup）每次捕获所有数据，增量备份（Incremental Backup）仅捕获自上次备份以来的变更，节省存储成本。
-- Vault Lock 合规模式（Compliance Mode）防止包括根用户在内的任何人删除恢复点，直至其生命周期结束，有效防御勒索软件攻击。
-- Forensic Account（取证账户）用于定期测试恢复点、扫描恶意软件，确保备份数据的可用性和安全性。
-- AWS Backup Audit Manager（BAM）提供合规报告能力，支持审计备份活动的合规性。
+- 高可用性（HA）关注系统运行时间和可用性，用 MTBF 衡量；灾难恢复（DR）关注数据丢失防护和恢复能力
+- RPO（Recovery Point Objective）定义可接受的数据丢失量，RTO（Recovery Time Objective）定义可接受的停机时间
+- AWS Backup 是全托管、策略驱动的备份服务，通过备份计划定义何时备份什么、存储到哪个保管库
+- AWS Backup 支持通过 Organizations 进行跨账户备份复制（Cross-Account Backup Copy），实现备份隔离
+- Vault Lock 合规模式可防止任何人（包括 AWS 根用户）在生命周期结束前删除恢复点，有效防御勒索软件
+- 增量备份（Incremental Backup）仅捕获自上次备份以来的变更，节省存储成本
+- 建议使用独立的 Bunker/Vault 账户存储备份副本，使用 Forensic 账户定期测试恢复点
 
 ## Key Quotes
-> "We should always be prepared for a situation that everything falls all the time." — Sabith, AWS 解决方案架构师
-> "High availability ensures a system performs its functions, measured by mean time between failures. Disaster recovery focuses on data loss prevention and recovery, while high availability focuses on system uptime and service availability." — 视频摘要
-> "AWS Backup uses backup plans to define what, when, and how to back up, storing recovery points in backup vaults." — 视频摘要
-> "Vault Lock in compliance mode prevents even root users from deleting recovery points until their lifecycle ends, deterring ransomware." — 视频摘要
+> "We should always be prepared for a situation that everything falls all the time." — 灾备意识的核心理念：时刻为最坏情况做准备
+> "The shared responsibility model defines AWS's and the customer's roles in ensuring a resilient cloud environment." — AWS 与客户在云弹性环境中的责任划分
+> "High availability ensures a system performs its functions, measured by mean time between failures. Disaster recovery focuses on data loss prevention and recovery." — HA 与 DR 的核心区别
 
 ## Key Concepts
-- [[AWS Backup]]：AWS 托管的集中化数据保护服务，通过备份计划（Backup Plans）自动化跨账户、跨区域的数据备份，支持不可变性和合规报告。
-- [[灾难恢复（Disaster Recovery）]]：防止数据丢失和系统停机的策略体系，与高可用（HA）互补，HA 保运行，DR 保数据。
-- [[高可用（High Availability）]]：通过冗余和快速故障转移保持系统持续可用的架构模式，MTBF 是其核心衡量指标。
-- [[RTO（Recovery Time Objective）]]：恢复时间目标，定义从故障恢复到服务可用的最大可接受时间窗口。
-- [[RPO（Recovery Point Objective）]]：恢复点目标，定义可接受的最大数据丢失时间窗口。
-- [[增量备份（Incremental Backup）]]：仅备份自上次备份以来的变更，与全量备份相比节省存储成本和备份时间。
-- [[全量备份（Full Backup）]]：每次备份捕获所有数据，恢复速度快但存储成本高。
-- [[Vault Lock]]：AWS Backup 保管库的合规锁定机制，合规模式下即使根用户也无法提前删除恢复点。
-- [[跨账户备份复制（Cross-Account Backup）]]：通过 AWS Organizations 在不同账户间复制备份，增强隔离性和安全性。
-- [[Bunker Account]]：专用存储备份副本的账户，与工作负载账户隔离，防止单点妥协。
-- [[Forensic Account]]：取证账户，用于定期测试恢复点可用性和恶意软件扫描。
-- [[共享责任模型（Shared Responsibility Model）]]：AWS 与客户在云弹性环境中的责任划分框架。
-- [[AWS Backup Audit Manager（BAM）]]：AWS Backup 的合规审计功能，支持备份活动的合规性报告。
-- [[灾难恢复架构模式]]：Backup and Restore / Pilot Light / Warm Standby / Active-Active 四级递进模式，从低成本低恢复到高成本高弹性。
+- [[AWS Backup]]：AWS 原生全托管策略驱动型备份服务，支持 80+ 资源类型，可跨账户跨区域复制恢复点
+- [[RTO]]（Recovery Time Objective）：可接受的系统停机时间，是 DR 策略的核心指标
+- [[RPO]]（Recovery Point Objective）：可接受的数据丢失量，决定备份频率
+- [[High Availability]]（高可用性）：关注系统运行时间和可用性，用 MTBF（平均故障间隔时间）衡量
+- [[Vault Lock]]：备份保管库合规锁定模式，防止恢复点被提前删除，防御勒索软件
+- [[增量备份]]：仅备份自上次备份以来的变更，相比全量备份节省存储成本
+- [[跨账户备份]]：通过 AWS Organizations 将备份复制到独立账户，实现备份隔离
 
 ## Key Entities
-- [[AWS]]：Amazon Web Services，AWS Backup 服务的提供方。
-- [[Sabith]]：AWS 解决方案架构师，本视频的主讲人。
-- [[Cloud Transformation Programme (CTP)]]：云转型计划，该视频属于 01_AWS-Landing-Zone 系列第 72 个主题。
-- [[Micro Focus]]：企业客户，CTP 的参与方。
+- [[AWS]]：云服务提供商，AWS Backup 和所有相关灾备功能的服务提供者
+- [[Cloud Transformation Programme]]（CTP）：企业级云转型计划，本视频为其 Topic 72，专注 DR 策略理论
+- Sabith（AWS）：本视频讲师，AWS 技术专家，主讲企业 DR 策略
+- SRE Teams：Site Reliability Engineering 团队，负责灾备策略设计和实施
 
 ## Connections
-- [[ctp-topic-44-aws-backup-in-micro-focus]] ← extends ← [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]
-- [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] ← extends ← [[ctp-topic-44-aws-backup-in-micro-focus]]
-- [[AWS Backup]] ← related ← [[RTO]]
-- [[AWS Backup]] ← related ← [[RPO]]
-- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← depends_on ← [[AWS Backup]]
+- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← extends ← [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]]（Topic 72 提供 DR 理论基础，Topic 73 聚焦 CTP 实施落地）
+- [[ctp-topic-44-aws-backup-in-micro-focus]] ← relates_to ← [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]（均讨论 AWS Backup，Topic 44 聚焦 Micro Focus 内部评估，Topic 72 提供 AWS 官方视角）
+- [[High Availability]] ← relates_to ← [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]（HA 与 DR 为灾备体系的两大支柱，DR 关注数据恢复，HA 关注系统可用性）
+- [[RTO]] ← key_metric ← [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]（RTO 是本视频的核心 DR 指标之一）
+- [[RPO]] ← key_metric ← [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]（RPO 是本视频的核心 DR 指标之一）
 
 ## Contradictions
-- 无明显内容冲突。本视频与 [[ctp-topic-44-aws-backup-in-micro-focus]] 构成互补关系——Topic 72 提供 DR 策略和 AWS Backup 的理论框架，Topic 44 聚焦 Micro Focus 内部评估和迁移路径，两者共同构成完整的 AWS Backup 知识体系。
+- 与 [[ctp-topic-44-aws-backup-in-micro-focus]] 存在视角差异：
+  - 冲突点：Micro Focus 内部评估指出 AWS Backup 存在局限性（无法选择性排除 EC2 附加卷、崩溃一致而非热备份）
+  - 当前观点：Topic 72 强调 AWS Backup 的优势和全托管特性
+  - 对方观点：Topic 44 建议同时评估快照管理工具作为补充
+  - 综合结论：两者互补，AWS Backup 适用于标准化策略驱动的备份，快照工具适用于细粒度定制场景

wiki/sources/fireworks-tech-graph.md

@@ -1,49 +1,159 @@
----
-title: "fireworks-tech-graph"
-type: source
-tags: []
-date: 2026-04-18
----
-
-## Source File
-- [[raw/Skills/fireworks-tech-graph.md]]
-
-## Summary（用中文描述）
-- 核心主题：用自然语言描述系统，几秒内生成可直接发布的 SVG + PNG 技术图
-- 问题域：技术文档/博客/演示缺乏高质量可视化图表，手动绘图耗时且风格不统一
-- 方法/机制：内置 7 种视觉风格（扁平图标/暗黑极客/工程蓝图/Notion极简/玻璃态/Claude官方/OpenAI官方）、14 种 UML 图类型、AI/Agent 领域内建 Pattern，通过 `rsvg-convert` 导出 1920px PNG
-- 结论/价值：AI Agent 可快速生成专业级技术图，无需手动绘制，支持 SVG 可编辑 + PNG 无损发布
-
-## Key Claims（用中文描述）
-- fireworks-tech-graph 将自然语言描述转化为精美的 SVG 技术图，通过 rsvg-convert 导出高分辨率 PNG
-- 内置 7 种视觉风格，深度覆盖 AI/Agent 领域常见图类型（RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 流程等）
-- 完整支持全部 14 种 UML 图类型
-- AI/Agent 领域内建知识：RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 等常见 Pattern 开箱即用
-- 语义形状词汇表：LLM = 双边框圆角矩形，Agent = 六边形，Vector Store = 带内环圆柱
-- 语义箭头系统：颜色 + 虚线样式编码含义（写入/读取/异步/循环）
-- SVG + PNG 双输出：SVG 可编辑，1920px PNG 可直接嵌入文章
-
-## Key Quotes
-> "不用手画图了。用中文描述你的系统，几秒钟得到可直接发布的 SVG + PNG 技术图。" — 项目 tagline
-> "所有示例图均以 1920px 宽度（2× 视网膜分辨率）通过 rsvg-convert 导出为 PNG 格式。技术图应选 PNG（无损），JPG 有损压缩会在文字和线条边缘产生噪点。" — 导出格式建议
-
-## Key Concepts
-- [[技术图生成]]：用自然语言生成 SVG/PNG 格式的技术架构图、流程图、UML 图
-- [[7种视觉风格系统]]：扁平图标风（默认）、暗黑极客风、工程蓝图风、Notion极简风、玻璃态卡片风、Claude官方风格、OpenAI官方风格
-- [[语义形状词汇表]]：每种概念类型（LLM/Agent/VectorStore/工具等）对应特定 SVG 形状
-- [[语义箭头系统]]：颜色 + 虚线样式编码数据流向（主数据流/控制触发/记忆读取/记忆写入/异步/反馈循环）
-- [[14种UML图]]：类图/组件图/部署图/包图/复合结构图/对象图/用例图/活动图/状态机图/序列图/通信图/时序图/交互概览图/ER图
-
-## Key Entities
-- [[fireworks-tech-graph]]：Claude Code Skill，将自然语言转化为 SVG 技术图，支持 7 种风格和 14 种 UML 图类型
-- [[rsvg-convert]]：librsvg 工具，用于将 SVG 渲染为高分辨率 PNG
-
-## Connections
-- [[fireworks-tech-graph]] ← uses ← [[语义形状词汇表]]
-- [[fireworks-tech-graph]] ← uses ← [[语义箭头系统]]
-- [[fireworks-tech-graph]] ← implements ← [[7种视觉风格系统]]
-- [[fireworks-tech-graph]] ← supports ← [[14种UML图]]
-- [[fireworks-tech-graph]] ← outputs ← [[rsvg-convert]]
-
-## Contradictions
-- 无冲突内容
+---
+title: "fireworks-tech-graph"
+type: source
+tags: []
+date: 2026-04-18
+last_updated: 2026-04-28
+---
+
+## Source File
+- [[raw/Skills/fireworks-tech-graph.md]]
+
+## Summary（用中文描述）
+- 核心主题：用自然语言描述系统，几秒内生成可直接发布的 SVG + PNG 技术图
+- 问题域：技术文档/博客/演示缺乏高质量可视化图表，手动绘图耗时且风格不统一
+- 方法/机制：内置 7 种视觉风格（扁平图标/暗黑极客/工程蓝图/Notion极简/玻璃态/Claude官方/OpenAI官方）、14 种 UML 图类型、AI/Agent 领域内建 Pattern，通过 `rsvg-convert` 导出 1920px PNG
+- 结论/价值：AI Agent 可快速生成专业级技术图，无需手动绘制，支持 SVG 可编辑 + PNG 无损发布
+
+## Key Claims（用中文描述）
+- fireworks-tech-graph 将自然语言描述转化为精美的 SVG 技术图，通过 rsvg-convert 导出高分辨率 PNG
+- 内置 7 种视觉风格，深度覆盖 AI/Agent 领域常见图类型（RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 流程等）
+- 完整支持全部 14 种 UML 图类型
+- AI/Agent 领域内建知识：RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 等常见 Pattern 开箱即用
+- 语义形状词汇表：LLM = 双边框圆角矩形，Agent = 六边形，Vector Store = 带内环圆柱
+- 语义箭头系统：颜色 + 虚线样式编码含义（写入/读取/异步/循环）
+- SVG + PNG 双输出：SVG 可编辑，1920px PNG 可直接嵌入文章
+
+## Key Quotes
+> "不用手画图了。用中文描述你的系统，几秒钟得到可直接发布的 SVG + PNG 技术图。" — 项目 tagline
+> "所有示例图均以 1920px 宽度（2× 视网膜分辨率）通过 rsvg-convert 导出为 PNG 格式。技术图应选 PNG（无损），JPG 有损压缩会在文字和线条边缘产生噪点。" — 导出格式建议
+
+## 7 种视觉风格
+
+| # | 名称 | 背景色 | 字体 | 适用场景 |
+|---|------|--------|------|----------|
+| 1 | **扁平图标风**（默认） | `#ffffff` | Helvetica | 博客、幻灯片、技术文档 |
+| 2 | **暗黑极客风** | `#0f0f1a` | SF Mono / Fira Code | GitHub README、开发者文章 |
+| 3 | **工程蓝图风** | `#0a1628` | Courier New | 架构设计文档、工程规范 |
+| 4 | **Notion 极简风** | `#ffffff` | system-ui | Notion、Confluence、内部 Wiki |
+| 5 | **玻璃态卡片风** | `#0d1117` 渐变 | Inter | 产品官网、演讲 Keynote |
+| 6 | **Claude 官方风格** | `#f8f6f3` | system-ui | Anthropic 风格图表，温暖专业美学 |
+| 7 | **OpenAI 官方风格** | `#ffffff` | system-ui | OpenAI 风格图表，简洁现代设计 |
+
+### 风格选择指南
+- **UML 图类型**：类图/组件图/包图 → 风格 1 或 4；序列图/时序图 → 风格 2；状态机图/活动图 → 风格 3
+- **AI/Agent 图类型**：RAG/Agentic Search → 风格 2 或 5；记忆架构 → 风格 3；Multi-Agent → 风格 5
+- **品牌特定**：Anthropic/Claude 项目 → 风格 6；OpenAI 项目 → 风格 7
+
+## 语义形状词汇表
+
+形状在所有风格中保持一致的语义：
+
+| 概念 | 形状 |
+|------|------|
+| 用户 / 人类 | 圆形 + 身体路径 |
+| LLM / 模型 | 圆角矩形，双边框，⚡ |
+| Agent / 编排器 | 六边形 |
+| 短期记忆 | 虚线边框圆角矩形 |
+| 长期记忆 | 实线圆柱体 |
+| Vector Store | 带内环圆柱 |
+| Graph DB | 三圆簇 |
+| 工具 / 函数 | 带 ⚙ 的矩形 |
+| API / 网关 | 六边形（单边框） |
+| 消息队列 / 流 | 横向管道 |
+| 文档 / 文件 | 折角矩形 |
+| 浏览器 / UI | 带三点标题栏的矩形 |
+| 决策节点 | 菱形 |
+| 外部服务 | 虚线边框矩形 |
+
+## 语义箭头系统
+
+| 流类型 | 线宽 | 虚线 | 含义 |
+|--------|------|------|------|
+| 主数据流 | 2px 实线 | — | 主要请求/响应路径 |
+| 控制 / 触发 | 1.5px 实线 | — | 系统 A 触发 B |
+| 记忆读取 | 1.5px 实线 | — | 从存储检索 |
+| 记忆写入 | 1.5px | `5,3` | 写入/存储操作 |
+| 异步 / 事件 | 1.5px | `4,2` | 非阻塞 |
+| 反馈 / 循环 | 1.5px 曲线 | — | 迭代推理 |
+
+## AI/Agent 领域内建 Pattern
+
+```
+RAG Pipeline         → Query → Embed → VectorSearch → Retrieve → LLM → Response
+Agentic RAG          → 在 RAG 基础上加入 Agent 循环 + 工具调用
+Agentic Search       → Query → Planner → [Search/Calc/Code] → Synthesizer
+Mem0 记忆层          → Input → Memory Manager → [VectorDB + GraphDB] → Context
+Agent 记忆类型       → 感知记忆 → 工作记忆 → 情景记忆 → 语义记忆 → 程序记忆
+Multi-Agent          → Orchestrator → [SubAgent×N] → Aggregator → Output
+Tool Call 流程       → LLM → Tool Selector → Execution → Parser → LLM (循环)
+```
+
+## 支持的图类型
+
+| 类型 | 描述 | 关键布局规则 |
+|------|------|-------------|
+| **架构图** | 服务、组件、云基础设施 | 水平分层，自上而下 |
+| **数据流图** | 数据在系统中的流向 | 每条箭头标注数据类型 |
+| **流程图** | 决策树、流程步骤 | 菱形 = 决策，自上而下 |
+| **Agent 架构图** | LLM + 工具 + 记忆 | 五层模型：输入/Agent/记忆/工具/输出 |
+| **记忆架构图** | Mem0、MemGPT 风格 | 读/写路径分离，记忆层级分明 |
+| **序列图** | API 调用链、时序交互 | 垂直生命线，水平消息箭头 |
+| **对比图** | 功能矩阵、方案比较 | 列 = 系统，行 = 属性 |
+| **思维导图** | 概念地图、发散思维 | 中心节点，贝塞尔曲线分支 |
+
+### UML 图类型（14 种）
+
+| UML 类型 | 描述 | 推荐风格 |
+|----------|------|----------|
+| **类图** | 类、属性、方法、关系 | 风格 1, 4 |
+| **组件图** | 软件组件和依赖关系 | 风格 1, 3 |
+| **部署图** | 硬件节点和软件部署 | 风格 3 |
+| **包图** | 包组织和依赖关系 | 风格 1, 4 |
+| **复合结构图** | 类/组件的内部结构 | 风格 1, 3 |
+| **对象图** | 对象实例和关系 | 风格 1, 4 |
+| **用例图** | 参与者、用例、系统边界 | 风格 1 |
+| **活动图** | 工作流、并行流程 | 风格 3 |
+| **状态机图** | 状态转换和事件 | 风格 2, 3 |
+| **序列图** | 时间顺序的消息交换 | 风格 2 |
+| **通信图** | 对象交互和消息 | 风格 1, 2 |
+| **时序图** | 状态随时间的变化 | 风格 2 |
+| **交互概览图** | 高层交互流程 | 风格 1, 2 |
+| **ER 图** | 实体关系数据模型 | 风格 1, 3 |
+
+## 产品图标覆盖范围
+
+**AI/ML 模型：** OpenAI、Anthropic/Claude、Google Gemini、Meta LLaMA、Mistral、Cohere、Groq、Hugging Face
+
+**AI 框架：** Mem0、LangChain、LlamaIndex、LangGraph、CrewAI、AutoGen、DSPy、Haystack
+
+**向量数据库：** Pinecone、Weaviate、Qdrant、Chroma、Milvus、pgvector、Faiss
+
+**关系型/NoSQL 数据库：** PostgreSQL、MySQL、MongoDB、Redis、Elasticsearch、Neo4j、Cassandra
+
+**消息队列：** Kafka、RabbitMQ、NATS、Pulsar
+
+**云服务 & 基础设施：** AWS、GCP、Azure、Cloudflare、Vercel、Docker、Kubernetes
+
+**可观测性：** Grafana、Prometheus、Datadog、LangSmith、Langfuse、Arize
+
+## Key Concepts
+- [[技术图生成]]：用自然语言生成 SVG/PNG 格式的技术架构图、流程图、UML 图
+- [[7种视觉风格系统]]：扁平图标风（默认）、暗黑极客风、工程蓝图风、Notion极简风、玻璃态卡片风、Claude官方风格、OpenAI官方风格
+- [[语义形状词汇表]]：每种概念类型（LLM/Agent/VectorStore/工具等）对应特定 SVG 形状
+- [[语义箭头系统]]：颜色 + 虚线样式编码数据流向（主数据流/控制触发/记忆读取/记忆写入/异步/反馈循环）
+- [[14种UML图]]：类图/组件图/部署图/包图/复合结构图/对象图/用例图/活动图/状态机图/序列图/通信图/时序图/交互概览图/ER图
+
+## Key Entities
+- [[fireworks-tech-graph]]：Claude Code Skill，将自然语言转化为 SVG 技术图，支持 7 种风格和 14 种 UML 图类型
+- [[rsvg-convert]]：librsvg 工具，用于将 SVG 渲染为高分辨率 PNG
+
+## Connections
+- [[fireworks-tech-graph]] ← uses ← [[语义形状词汇表]]
+- [[fireworks-tech-graph]] ← uses ← [[语义箭头系统]]
+- [[fireworks-tech-graph]] ← implements ← [[7种视觉风格系统]]
+- [[fireworks-tech-graph]] ← supports ← [[14种UML图]]
+- [[fireworks-tech-graph]] ← outputs ← [[rsvg-convert]]
+
+## Contradictions
+- 无冲突内容

wiki/sources/install-wsl.md

@@ -1,49 +1,49 @@
 ---
 title: "Install WSL"
 type: source
-tags: []
+tags:
+  - "clippings"
+  - "wsl"
+  - "ubuntu"
+  - "windows"
 date: 2026-04-18
 ---
 
 ## Source File
-- [[raw/Home Office/Install WSL.md]]
+- [[Home Office/Install WSL]]
 
 ## Summary（用中文描述）
-- 核心主题：Windows Subsystem for Linux（WSL）的官方安装与配置完整指南
-- 问题域：Windows 10/11 系统上快速安装 Linux 开发环境，包括单命令安装、多发行版支持、版本管理、离线安装等场景
-- 方法/机制：① `wsl --install` 一键安装；② `-d` 参数切换默认发行版；③ `wsl.exe --set-default-version` 切换 WSL 1/2；④ MSI 包 + DISM 命令离线安装；⑤ Windows Terminal / 开始菜单 / PowerShell 多入口运行
-- 结论/价值：微软官方权威安装文档，提供从零到生产可用的完整路径，WSL2 为默认版本，支持并行运行多个不同 Linux 发行版
+- 核心主题：Windows Subsystem for Linux (WSL) 的安装与配置
+- 问题域：开发者如何在 Windows 系统上快速安装和使用 Linux 环境
+- 方法/机制：通过 `wsl --install` 一条命令自动启用 WSL 功能并安装 Ubuntu；支持更换默认发行版、版本切换（WSL 1/WSL 2）、多发行版管理
+- 结论/价值：开发者可在 Windows 上无缝使用 Linux 工具链，无需虚拟机或双系统，适合跨平台开发
 
 ## Key Claims（用中文描述）
-- `wsl --install` 一条命令完成 WSL 全部组件启用和 Ubuntu 默认发行版安装，适用于 Windows 10 version 2004+（Build 19041+）和 Windows 11
-- WSL2 默认使用 NAT 网络模式，通过 `.wslconfig` 配置 `networkingMode=mirrored` 可实现与 Windows 共享网络堆栈（参考 [[WSL2 启动与网络配置指南]]）
-- 支持并行安装多个 Linux 发行版（Ubuntu/Debian/SUSE/Kali/Fedora 等），可从 Microsoft Store 下载或导入自定义 TAR 分发版
-- 新安装的 Linux 发行版默认使用 WSL 2，可通过 `wsl.exe --set-version <Distro> 1` 降级到 WSL 1
-- 离线安装需从 GitHub releases 下载 MSI 安装包，并通过 DISM 命令启用 Virtual Machine Platform 组件
+- 微软通过 `wsl --install` 命令实现一键安装：自动启用 WSL 所需功能 + 安装默认 Ubuntu 发行版
+- Windows 10 version 2004+ (Build 19041+) 或 Windows 11 才能使用该命令，旧版本需手动安装
+- 新安装的 Linux 发行版默认使用 WSL 2，可通过命令在 WSL 1 和 WSL 2 之间切换
+- 支持同时运行多个不同 Linux 发行版，可从 Windows Terminal、开始菜单、PowerShell 等多种方式启动
 
 ## Key Quotes
-> "You can now install everything you need to run WSL with a single command." — 微软官方文档
-> "New Linux installations, installed using the `wsl --install` command, will be set to WSL 2 by default." — 微软官方文档
+> "Developers can access the power of both Windows and Linux at the same time on a Windows machine." — 官方文档开篇
+> "WSL lets developers install a Linux distribution... and use Linux applications, utilities, and Bash command-line tools directly on Windows, unmodified, without the overhead of a traditional virtual machine or dualboot setup." — WSL 核心价值描述
+> "New Linux installations, installed using the `wsl --install` command, will be set to WSL 2 by default." — WSL 2 默认设置说明
 
 ## Key Concepts
-- [[WSL2]]：Windows Subsystem for Linux 2，Windows 10/11 内置 Linux 虚拟机环境，默认版本，支持完整 Linux 内核
-- [[WSL1]]：WSL 第一代，基于翻译层，性能较差但兼容性好，新发行版默认不使用
-- [[WSL 安装命令]]：`wsl --install` 单命令安装，启用所需功能并安装默认 Ubuntu 发行版
-- [[多发行版支持]]：WSL 支持并行安装运行多个不同 Linux 发行版，可通过 `--distribution` 参数指定运行哪个
-- [[离线安装]]：通过 MSI 包 + DISM 命令手动启用 Virtual Machine Platform 组件，适用于无法联网的环境
+- [[WSL]]：Windows Subsystem for Linux，允许在 Windows 上原生运行 Linux 二进制可执行文件
+- [[WSL2]]：WSL 的第二代架构，使用轻量级虚拟机和支持完整的 Linux 内核，提升文件系统性能和系统调用兼容性
+- [[PowerShell]]：Windows 命令行 shell，用于执行 WSL 安装和管理命令
+- [[Windows Terminal]]：微软推荐的终端应用，支持多标签页，可在同一窗口中运行 PowerShell、WSL、命令提示符等
 
 ## Key Entities
-- [[Microsoft]]：WSL 官方文档发布方
+- [[Microsoft]]：WSL 的开发者和发布者
 - [[Ubuntu]]：WSL 默认安装的 Linux 发行版
-- [[PowerShell]]：Windows 命令行环境，执行 `wsl --install` 的工具（需管理员模式）
-- [[Windows Terminal]]：微软官方终端应用，推荐用于运行 WSL，支持多标签页
+- [[Debian]]：WSL 支持的 Linux 发行版之一
+- [[Kali Linux]]：WSL 支持的安全/渗透测试专用 Linux 发行版
+- [[WSL]]：OpenSUSE 等其他 WSL 支持的发行版
 
 ## Connections
-- [[WSL2 启动与网络配置指南]] ← related_to ← [[Install WSL]]（安装完成后需参考网络配置指南解决代理问题）
-- [[Ubuntu Server]] ← related_to ← [[WSL2]]（WSL2 中的 Ubuntu 与 Ubuntu Server 同属 Ubuntu 系 Linux 环境）
+- [[Install WSL]] ← extends ← [[WSL2 启动与网络配置指南]]
 
 ## Contradictions
-- 与 [[WSL2 启动与网络配置指南]] 的侧重点差异：
-  - 冲突点：本文档聚焦安装过程，未涉及网络配置；[[WSL2 启动与网络配置指南]] 聚焦安装后的网络配置
-  - 当前观点：先安装（本文档）→ 后配置网络（[[WSL2 启动与网络配置指南]]），两篇互补
-  - 对方观点：WSL2 默认 NAT 网络模式下 localhost 代理不可用，需配置镜像模式才能与 Windows 共享代理
+- （暂无发现冲突内容）

wiki/sources/mac必装软件清单-2026-04-17.md

@@ -1,47 +1,55 @@
 ---
 title: "Mac必装软件清单"
 type: source
-tags: []
+tags: [Mac, 效率工具, 软件推荐, 知识管理, AI]
 date: 2026-04-17
+sources: []
+last_updated: 2026-04-28
 ---
 
 ## Source File
-- [[raw/Home Office/Mac必装软件清单-2026-04-17.md]]
+- [[Home Office/Mac必装软件清单-2026-04-17.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Mac 用户必装软件推荐清单
-- 问题域：macOS 效率工具与生产力软件选型
-- 方法/机制：精选 8 款软件，涵盖 AI、知识管理、浏览器、效率工具、开发工具等类别，每款附推荐理由
-- 结论/价值：用最少的软件达到最高的效率，适合从 Windows 转 Mac 的用户和追求效率的 macOS 用户
+- 核心主题：Mac 用户必备软件推荐清单
+- 问题域：macOS 效率工具选型，覆盖 AI、浏览器、截图、系统清理、启动器、包管理器
+- 方法/机制：作者（Claw小龙虾 @openclaw1024）基于个人使用经验精选 8 款软件，强调"用最少的软件，达到最高的效率"
+- 结论/价值：提供一份精炼的 Mac 软件入门清单，适合从 Windows 转 Mac 或新入手 Mac 的用户
 
 ## Key Claims（用中文描述）
-- Claude 是 AI 时代必备工具，桌面版 Cowork 功能专为文字工作者打造
+- Claude 是 AI 时代人手必备的工具，其桌面版 Cowork 功能专为文字工作者打造
 - Obsidian 搭配 Claudian 插件可打造 AI 驱动的终极个人知识库
-- Raycast 是替代 Spotlight 的万能启动器，计算器和剪贴板功能超好用
-- Homebrew 是用 Claude Code 搭 Agent 的前置依赖
+- Chrome 比 Safari 更好用，是 Gmail 用户的不二之选
+- Rectangle 是免费的分屏神器，大屏办公必备，从 Windows 转 Mac 必装
+- iShot 是简洁免费的截图工具，支持圆角截图，五年老用户推荐
+- Lemon 是轻量系统清理工具，多任务卡顿时清理缓存很管用
+- Raycast 替代 Spotlight 的万能启动器，计算器和剪贴板历史超好用
+- Homebrew 是 Mac 包管理器，用 Claude Code 搭 Agent 的前置依赖
 
 ## Key Quotes
-> "用最少的软件，达到最高的效率。" — Claw小龙虾
+> "用最少的软件，达到最高的效率。" — Claw小龙虾， Telegram频道「Hermes爱马仕&🦞OpenClaw小龙虾」
 
 ## Key Concepts
-- [[Raycast]]：替代 Spotlight 的 macOS 万能启动器，支持计算器、剪贴板历史等功能
-- [[Obsidian]]：本地优先的笔记与知识管理工具，支持双向链接
-- [[Homebrew]]：macOS 包管理器，是开发工具安装的事实标准
+- [[个人知识库]]：Obsidian 作为笔记工具，搭配 Claudian 插件可实现 AI 驱动的知识管理
+- [[效率工具]]：Rectangle 分屏、Raycast 启动器、Lemon 清理等提升日常工作效率的实用软件
+- [[包管理器]]：Homebrew 作为 macOS 的命令行包管理工具，是开发环境的基石
 
 ## Key Entities
-- [[Claude]]：Anthropic 开发的 AI 助手，桌面版 Cowork 功能专为文字工作者设计
-- [[Chrome]]：Google 浏览器，比 Safari 更好用，Gmail 用户的不二之选
-- [[Rectangle]]：免费分屏工具，大屏办公必备
-- [[iShot]]：简洁免费的 macOS 截图工具，支持圆角截图
-- [[Lemon]]：轻量 Mac 系统清理工具
-- [[Homebrew]]：macOS 包管理器
-- [[Claw小龙虾]]：Telegram频道「Hermes爱马仕&🦞OpenClaw小龙虾」作者
+- [[Claude]]：Anthropic 的 AI 助手，桌面版 Cowork 功能为文字工作者设计，本清单推荐第一名
+- [[Obsidian]]：本地优先的笔记/知识管理应用，推荐搭配 Claudian 插件使用
+- [[Chrome]]：Google 浏览器，比 Safari 更适合 Gmail 重度用户
+- [[Rectangle]]：开源免费的分屏管理工具，支持窗口快捷键对齐
+- [[iShot]]：macOS 截图录屏工具，支持长截图、延时截图、圆角截图
+- [[Lemon]]：轻量级 Mac 系统清理工具
+- [[Raycast]]：macOS 万能启动器，替代 Spotlight，支持计算器、剪贴板历史、窗口管理
+- [[Homebrew]]：macOS 包管理器，安装命令行工具的事实标准
 
 ## Connections
-- [[Obsidian]] ← 搭配 ← [[Claudian插件]]
-- [[Obsidian]] ← 关联 ← [[Second Brain]]
-- [[Homebrew]] ← 依赖 ← [[Claude Code]]
-- [[Raycast]] ← 替代 ← [[Spotlight]]
+- [[Obsidian]] ← 搭配插件 ← [[Claude]]
+- [[Obsidian]] ← 相关工具 ← [[我的工具集]]
+- [[Homebrew]] ← 前置依赖 ← Claude Code
+- [[Rectangle]] ← 替代品 ← [[macOS Spatial/Metal Engineer Agent Personality]]
+- [[Raycast]] ← 相关生态 ← [[我的工具集]]
 
 ## Contradictions
-- 无冲突内容
+- 暂无已知冲突内容

wiki/sources/obsidian-cli.md

@@ -1,58 +1,85 @@
----
-title: "Obsidian CLI"
-type: source
-tags:
-  - "obsidian"
-  - "cli"
-  - "automation"
-  - "skills"
-date: 2026-04-16
----
-
-## Source File
-- [[raw/Skills/Obsidian CLI.md]]
-
-## Summary（用中文描述）
-- 核心主题：Obsidian CLI 官方命令行工具——从终端完全控制 Obsidian，支持脚本化、自动化和外部工具集成
-- 问题域：日常笔记操作的命令行化、AI Agent 对 Obsidian 的自动化控制、插件与主题开发调试
-- 方法/机制：通过 TUI（交互终端界面）或单命令两种模式，以 `obsidian <command>` 语法调用各类内置命令；支持 vault 切换、参数/标志传参、文件定位（file= vs path=）；开发者命令通过 CDP（Chrome DevTools Protocol）实现截图、控制台执行、插件热重载
-- 结论/价值：Obsidian CLI 将 Obsidian 的全部 GUI 功能暴露给命令行，使 AI Agent 可以通过标准化 CLI 接口实现笔记的增删改查、日程管理、搜索、任务操作等，是 AI Agent 操作 Obsidian 知识库的核心工具
-
-## Key Claims（用中文描述）
-- Obsidian CLI 覆盖了 Obsidian GUI 中的所有功能，任何 GUI 操作均可通过命令行实现
-- Obsidian CLI 需要 Obsidian 1.12+ 安装程序，首次使用需在 Settings → General 中启用并注册
-- Obsidian CLI 需要 Obsidian 应用处于运行状态，首条命令会自动启动应用
-- TUI 模式支持命令历史、反向搜索（Ctrl+R）和自动补全，适合交互式使用
-- 开发者命令通过 Chrome DevTools Protocol 实现，使 AI Agent 能够自动测试和调试插件
-
-## Key Quotes
-> "Anything you can do in Obsidian you can do from the command line. Obsidian CLI even includes developer commands to access developer tools, inspect elements, take screenshots, reload plugins, and more." — Obsidian CLI 官方文档
-> "Obsidian CLI requires the Obsidian app to be running. If Obsidian is not running, the first command you run launches Obsidian." — Obsidian CLI 官方文档
-
-## Key Concepts
-- [[Obsidian-CLI]]：官方命令行工具，通过终端控制 Obsidian 的全部功能
-- [[Obsidian-TUI]]：交互式终端界面，支持命令历史、自动补全、反向搜索
-- [[Vault-Management]]：vault 切换机制，支持按名称或 ID 定向操作不同笔记库
-- [[Developer-Commands]]：开发者命令组，通过 Chrome DevTools Protocol 实现插件调试和自动化测试
-- [[Daily-Notes-CLI]]：CLI 中的日记命令，支持打开/追加/前置日记内容
-- [[File-Recovery]]：文件历史版本管理，支持 diff 对比和 history 恢复
-- [[CDP-Commands]]：Chrome DevTools Protocol 命令集，支持截图、控制台执行、DOM 查询
-- [[Plugin-Reload]]：插件热重载命令，无需重启应用即可刷新社区插件
-
-## Key Entities
-- [[Obsidian]]：笔记软件开发商，本文档的 CLI 工具发布方
-- [[Obsidian-Skills]]：kepano 发布的 Obsidian Skills 工具链，obsidian-cli 是其中之一（来源：[[obsidian-必装-skills]]）
-
-## Connections
-- [[Obsidian-CLI]] ← 依赖 ← [[Obsidian]]（官方内置 CLI 工具）
-- [[Obsidian-CLI]] ← 属于 ← [[Obsidian-Skills]]（Skills 工具链之一）
-- [[Obsidian-CLI]] → 支持 → [[AI-Agent-Obsidian-Integration]]（AI Agent 通过 CLI 操作 Obsidian）
-- [[Obsidian-CLI]] → 互补 → [[Claudian]]（Claude Code 插件方案 vs CLI 方案）
-- [[Obsidian-CLI]] → 互补 → [[Obsidian-Agent-Client]]（第三方 Agent 插件方案）
-
-## Contradictions
-- 与 [[obsidian-必装-skills]] 中的 obsidian-cli 描述存在细微视角差异：
-  - 冲突点：obsidian-cli 究竟是"官方 CLI 工具"还是"第三方 Skill"
-  - 当前观点（本文档）：obsidian-cli 是 Obsidian 官方内置 CLI（Obsidian.md 出品）
-  - 对方观点（obsidian-必装-skills）：将 obsidian-cli 列为 kepano 发布的 Obsidian Skills 之一
-  - 分析：两种描述均正确——obsidian-cli 既是 Obsidian 官方内置功能（v1.12+），也是 kepano 在 Skills 项目中收录整理的工具
+---
+title: "Obsidian CLI"
+type: source
+tags:
+  - "obsidian"
+  - "cli"
+  - "automation"
+  - "skills"
+date: 2026-04-16
+---
+
+## Source File
+- [[raw/Skills/Obsidian CLI.md]]
+
+## Summary（用中文描述）
+- 核心主题：Obsidian 官方 CLI 命令行工具——从终端完全控制 Obsidian，支持脚本化、自动化和外部工具集成，涵盖日常使用、开发者调试、AI Agent 集成全场景
+- 问题域：笔记操作命令行化、AI Agent 对 Obsidian 的自动化控制、插件与主题开发调试、vault 管理和多端同步
+- 方法/机制：通过 TUI（交互终端界面）或单命令两种模式，以 `obsidian <command>` 语法调用 50+ 内置命令；支持 vault 切换、参数/标志传参、文件定位（file= vs path=）；开发者命令通过 CDP（Chrome DevTools Protocol）实现截图、控制台执行、插件热重载
+- 结论/价值：Obsidian CLI 将 Obsidian 的全部 GUI 功能暴露给命令行，使 AI Agent 可以通过标准化 CLI 接口实现笔记的增删改查、日程管理、搜索、任务操作等，是 AI Agent 操作 Obsidian 知识库的核心基础设施
+
+## Key Claims（用中文描述）
+- Obsidian CLI 覆盖了 Obsidian GUI 中的所有功能，任何 GUI 操作均可通过命令行实现
+- Obsidian CLI 需要 Obsidian 1.12.7+ 安装程序，首次使用需在 Settings → General 中启用并注册
+- Obsidian CLI 需要 Obsidian 应用处于运行状态，首条命令会自动启动应用（Headless 同步需另见 Obsidian Headless）
+- TUI 模式支持命令历史、反向搜索（Ctrl+R）和自动补全，适合交互式使用
+- 开发者命令通过 Chrome DevTools Protocol 实现，使 AI Agent 能够自动测试和调试插件和主题
+- Vault 默认使用当前工作目录（如为 vault 文件夹）或当前活跃 vault；可用 `vault=<name>` 或 `vault=<id>` 定向指定
+- 参数（parameter）使用 `key=value` 语法，多词值需引号包裹；标志（flag）为布尔开关，写入即开启
+- 所有命令支持 `--copy` 标志将输出复制到剪贴板
+
+## Key Quotes
+> "Anything you can do in Obsidian you can do from the command line. Obsidian CLI even includes developer commands to access developer tools, inspect elements, take screenshots, reload plugins, and more." — Obsidian CLI 官方文档
+> "Obsidian CLI requires the Obsidian app to be running. If Obsidian is not running, the first command you run launches Obsidian." — Obsidian CLI 官方文档
+> "Many developer commands are available for plugin and theme development. These commands allow agentic coding tools to automatically test and debug." — Obsidian CLI 官方文档
+
+## Key Concepts
+- [[Obsidian-CLI]]：官方命令行工具，通过终端控制 Obsidian 的全部功能，支持单命令模式和 TUI 交互模式
+- [[Obsidian-TUI]]：交互式终端界面，支持命令历史、自动补全、反向搜索（Ctrl+R）
+- [[Vault-Management]]：vault 切换机制，支持按名称或 ID 定向操作不同笔记库，`vault=<name>` 为首个参数
+- [[Developer-Commands]]：开发者命令组，通过 Chrome DevTools Protocol 实现插件调试、自动化测试
+- [[CDP-Commands]]：Chrome DevTools Protocol 命令集，支持截图、控制台执行、DOM 查询、CSS 检查
+- [[Plugin-Reload]]：插件热重载命令，无需重启应用即可刷新社区插件（`plugin:reload id=<plugin-id>`）
+- [[Daily-Notes-CLI]]：CLI 中的日记命令，支持打开/追加/前置/读取日记内容
+- [[File-Recovery]]：文件历史版本管理，支持 diff 对比和 history 恢复（File Recovery + Sync 双源）
+- [[Base-Commands]]：Bases（数据库视图）相关命令，支持创建、查询（JSON/CSV/TSV/MD 格式输出）
+- [[Property-Commands]]：属性（frontmatter）管理命令，支持设置、读取、删除文件属性
+- [[Task-Commands]]：任务管理命令，支持过滤（todo/done）、每日笔记任务、按文件和状态筛选
+- [[Template-Commands]]：模板命令，支持读取（可解析 {{date}} 等变量）、插入模板到活动文件
+- [[Sync-Commands]]：Obsidian Sync 控制命令，支持暂停/恢复、版本历史查看和恢复
+- [[Plugin-Management-CLI]]：插件管理命令，支持安装/卸载/启用/禁用/重载社区插件
+- [[Publish-Commands]]：Obsidian Publish 命令，支持站点信息、发布状态、增删发布文件
+
+## Key Entities
+- [[Obsidian]]：笔记软件开发商，CLI 工具发布方（obsidian.md），要求安装程序版本 1.12.7+
+- [[Obsidian-Skills]]：kepano 发布的 Obsidian Skills 工具链，obsidian-cli 作为官方内置 CLI 在 Skills 项目中被收录（来源：[[obsidian-必装-skills]]）
+
+## Connections
+- [[Obsidian-CLI]] ← 依赖 ← [[Obsidian]]（官方内置 CLI，v1.12.7+）
+- [[Obsidian-CLI]] ← 属于 ← [[Obsidian-Skills]]（Skills 工具链之一）
+- [[Obsidian-CLI]] → 支持 → [[AI-Agent-Obsidian-Integration]]（AI Agent 通过 CLI 操作 Obsidian）
+- [[Obsidian-CLI]] → 互补 → [[Claudian]]（Claude Code 插件方案 vs CLI 方案）
+- [[Obsidian-CLI]] → 互补 → [[Obsidian-Agent-Client]]（第三方 Agent 插件方案）
+- [[Obsidian-CLI]] → 互补 → [[Obsidian-Headless]]（CLI 需要桌面应用运行，Headless 用于无头同步）
+
+## Command Categories Overview（完整命令分类速查）
+
+| 分类 | 主要命令 | 用途 |
+|---|---|---|
+| 日常使用 | `daily`, `search`, `read`, `open`, `tags` | 日记、搜索、读写、标签 |
+| 文件管理 | `create`, `move`, `rename`, `delete`, `append` | 文件增删改移 |
+| 链接管理 | `backlinks`, `links`, `unresolved`, `orphans` | 链接分析 |
+| 任务管理 | `tasks`, `task` | 任务增删改查 |
+| 开发者 | `devtools`, `plugin:reload`, `eval`, `dev:screenshot` | 调试自动化 |
+| 数据管理 | `bases`, `base:create`, `base:query` | 数据库视图 |
+| 同步与历史 | `sync`, `diff`, `history`, `history:restore` | 版本控制 |
+| 插件管理 | `plugins`, `plugin:install`, `plugin:enable` | 插件操作 |
+| 发布 | `publish:add`, `publish:status` | Obsidian Publish |
+| 工作区 | `workspace:save`, `workspace:load`, `tabs` | 工作区管理 |
+
+## Contradictions
+- 与 [[obsidian-必装-skills]] 中的 obsidian-cli 描述存在视角差异：
+  - 冲突点：obsidian-cli 究竟是"官方 CLI 工具"还是"第三方 Skill"
+  - 当前观点（本文档）：obsidian-cli 是 Obsidian 官方内置 CLI（Obsidian.md 出品，v1.12+）
+  - 对方观点（obsidian-必装-skills）：将 obsidian-cli 列为 kepano 发布的 Obsidian Skills 之一
+  - 分析：两种描述均正确——obsidian-cli 既是 Obsidian 官方内置功能（v1.12+），也是 kepano 在 Skills 项目中收录整理的工具，本质上不矛盾

wiki/sources/obsidian-官方-cli-命令全景速查表.md

@@ -2,53 +2,45 @@
 title: "Obsidian 官方 CLI 命令全景速查表"
 type: source
 tags: []
-date: 2026-04-23
+date: 2026-04-28
 ---
 
 ## Source File
-- [[raw/Skills/Obsidian 官方 CLI 命令全景速查表.md]]
+- [[Skills/Obsidian 官方 CLI 命令全景速查表.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Obsidian v1.12+ 内置官方 CLI 命令行工具的完整命令速查表
-- 问题域：Obsidian 用户和 AI Agent 如何通过终端自动化操作笔记库
-- 方法/机制：通过 `obsidian <命令> 参数名=参数值 标记参数` 格式执行 80+ 条命令，覆盖 16 个功能模块
-- 结论/价值：CLI 使 Obsidian 从图形界面工具升级为 AI Agent 可编程的知识管理系统，是构建本地 RAG 和自动化工作流的基础设施
+- 核心主题：Obsidian v1.12+ 官方 CLI 命令完整参考，包含 80+ 条命令，涵盖所有功能模块
+- 问题域：如何通过终端自动化控制 Obsidian 笔记软件（文件操作、数据库、搜索、发布、插件管理等）
+- 方法/机制：统一的 `obsidian <命令> 参数名=参数值` 命令格式，支持标记参数和 JSON/CSV 输出
+- 结论/价值：使 Obsidian 可被 AI Agent 深度集成，实现零配置本地 RAG、自动化工作流和跨平台数据库录入
 
 ## Key Claims（用中文描述）
-- Obsidian CLI 提供从基础操作到开发者模式的 80+ 命令，覆盖笔记库管理的全场景
-- AI Agent 可通过 `obsidian read` + `obsidian search:context` + `obsidian backlinks` 组合实现零配置的本地 RAG 对话助理
-- 通过 n8n Webhook 调用 CLI，可实现跨平台数据库级联录入（Obsidian Bases + 外部数据）
-- `obsidian unique` 命令支持 Zettelkasten 卡片盒模式，按时间戳生成唯一笔记 ID
-- 开发者模式（dev:cdp、eval）提供 Chrome DevTools Protocol 级别的底层访问能力
+- Obsidian CLI 可实现 Agent 接入：Agent 通过 `obsidian read` 直接读取笔记内容进行 RAG，无需额外向量数据库
+- 双链自动维护：`obsidian move/rename` 在重命名文件时自动更新全库双向链接，绝不断链
+- 批量元数据清洗：通过 `obsidian property:set` 批量覆写 YAML 属性，强制符合标准格式
+- 极速闪记：结合 Raycast/Alfred 绑定脚本，实现完全无需唤醒 Obsidian 界面的后台追加记录
 
 ## Key Quotes
-> "obsidian read — 打印文件内容，Agent 接入必用命令"
-> "obsidian search:context — 提供包含上下文的检索结果"
-> "obsidian eval — 注入 JavaScript 代码到底层执行并返回结果"
+> "obsidian read — 打印文件内容，Agent 接入必用命令。" — 文档核心价值定位
+> "obsidian move/rename — 移动或重命名文件（自动更新双链）" — 双链维护保证
+> "obsidian eval — 注入 JavaScript 代码到底层执行并返回结果" — 开发者模式顶级权限
 
 ## Key Concepts
-- [[Obsidian CLI]]：Obsidian v1.12+ 内置的官方命令行工具，通过终端操作笔记库，支持 AI Agent 集成
-- [[Obsidian Bases]]：Obsidian 1.12 新增的 .base 数据库功能，支持结构化数据存储和查询
-- [[Zettelkasten]]：卡片盒笔记法，`obsidian unique` 命令支持按时间戳生成唯一笔记 ID
-- [[本地 RAG]]：利用 CLI 的搜索和链接查询能力，结合本地 LLM 构建隐私优先的知识库
-- [[工作流自动化]]：n8n 定时任务 + Obsidian CLI 实现笔记自动化处理
-- [[元数据管理]]：`property:set` / `property:read` 等命令支持 YAML 属性的批量读写
-- [[快速闪记]]：`daily:append` 支持在后台直接追加内容到每日笔记，无需唤醒 Obsidian 界面
+- [[Zettelkasten]]：CLI 提供 `obsidian unique` 命令，按照卡片盒时间戳格式自动生成唯一笔记
+- [[YAML 属性]]：Obsidian 1.12+ 通过 `obsidian property:set/remove/read` 实现标准化的 frontmatter 操作
+- [[双向链接]]：CLI 在 `move/rename` 时自动维护 backlinks 和 forward links，保证知识图谱完整性
+- [[本地 RAG]]：文档推荐的"绝对隐私的本地 RAG"方案：用 `search:context` + `backlinks` + `read` 三命令构建上下文，完全零配置
 
 ## Key Entities
-- [[Obsidian]]：知识管理应用，v1.12+ 内置官方 CLI 命令行工具
-- [[Obsidian CLI]]：官方内置 CLI，覆盖文件操作/数据库/搜索/插件管理等 80+ 命令
-- [[Dataview]]：Obsidian 社区插件，与 CLI 的 `properties` 命令互补提供数据查询能力
-- [[QuickAdd]]：Obsidian 社区插件，用于快速创建笔记，与 CLI 的 `create` 命令功能重叠但 GUI 更便捷
-- [[Templater]]：Obsidian 社区插件，支持动态模板，与 CLI 的 `template:read` / `template:insert` 互补
+- [[Obsidian]]：本 CLI 工具所属的笔记软件厂商；CLI 从 v1.12 开始官方支持
+- [[Dataview]]：社区插件，CLI 提供 `plugin:enable/disable` 管理
+- [[n8n]]：工作流自动化平台，文档中多个场景用它编排 Obsidian CLI 调用
+- [[Raycast]] / [[Alfred]]：启动器工具，与 CLI 结合实现极速闪记工作流
+- [[OpenClaw]]：文档中 AI 收件箱自动分拣员场景使用的 Agent 框架
 
 ## Connections
-- [[obsidian-cli]] ← depends_on ← [[Obsidian]]（v1.12+ 内置）
-- [[obsidian-必装-skills]] ← extends ← [[obsidian-cli]]（CLI 是必装 Skills 之一）
-- [[obsidian-高效指南]] ← relates_to ← [[obsidian-cli]]（高频使用插件与 CLI 互补）
-- [[养虾日记3]] ← uses ← [[obsidian-cli]]（用 CLI 操作 Obsidian 笔记库）
-- [[obsidian-bases]] ← part_of ← [[obsidian-cli]]（Bases 是 CLI 的数据库子模块）
-- [[quartz]] ← consumes ← [[Obsidian]] notes（Quartz 消费 Obsidian 导出的 Markdown）
+- [[obsidian-官方-cli-命令全景速查表]] ← depends_on ← [[Obsidian]]
+- [[obsidian-必装-skills.md]] ← extends ← [[obsidian-官方-cli-命令全景速查表]]
 
 ## Contradictions
-- 与 [[obsidian-cli]]（另一份同名页面）无冲突：同一来源的重复引用，内容一致
+- 无已知冲突

wiki/sources/wsl2-启动与网络配置指南.md

@@ -6,37 +6,49 @@ date: 2026-04-17
 ---
 
 ## Source File
-- [[raw/Home Office/WSL2 启动与网络配置指南.md]]
+- [[Home Office/WSL2 启动与网络配置指南.md]]
 
 ## Summary（用中文描述）
-- 核心主题：WSL2（Windows Subsystem for Linux 2）的安装启动与网络配置实操指南
-- 问题域：Windows 环境下 Linux 开发环境搭建，重点解决 WSL2 网络隔离导致的 GitHub/海外资源访问障碍
-- 方法/机制：① `wsl --install` 快速安装；② `.wslconfig` 启用镜像网络模式（mirrored mode）实现 WSL2 与 Windows 共享网络堆栈；③ 终端代理环境变量手动配置；④ ghproxy.com 反向代理绕过网络限制
-- 结论/价值：提供从零安装到生产可用的完整 WSL2 配置路径，镜像网络模式是最稳妥的解决方案，避免 NAT 模式下的 localhost 代理失效问题
+- 核心主题：WSL2（Windows Subsystem for Linux 2）日常使用操作与网络配置
+- 问题域：WSL2 网络隔离导致 Windows 代理无法被 Linux 内部访问的痛点
+- 方法/机制：
+  - 首次安装：`wsl --install` 一键安装
+  - 状态检查：`wsl -l -v` 查看版本
+  - 版本转换：`wsl --set-version <分发版> 2`
+  - 镜像网络模式：`.wslconfig` 配置 `networkingMode=mirrored` + `dnsTunneling=true`
+  - 手动代理：获取宿主机 IP 后设置 `http_proxy/https_proxy` 环境变量
+  - GitHub 加速：通过 `ghproxy.com` 反向代理下载
+- 结论/价值：提供完整的 WSL2 从安装到生产可用的端到端操作指南
 
 ## Key Claims（用中文描述）
-- WSL2 默认使用 NAT 模式，导致 Windows 宿主机 localhost 代理无法被 WSL2 内部正确访问，这是 GitHub/海外资源连接失败的根本原因
-- 在 `.wslconfig` 中设置 `networkingMode=mirrored` + `dnsTunneling=true` + `autoProxy=true` 可使 WSL2 与 Windows 共享网络堆栈，是解决网络问题的推荐方案
-- 使用 `ghproxy.com` 反向代理可绕过 GitHub 访问限制，适用于 uv 安装器、Hermes Agent 等工具的下载场景
+- WSL2 默认 NAT 模式导致 Windows localhost 代理无法被 WSL2 内部访问
+- `.wslconfig` 中 `networkingMode=mirrored` 使 WSL2 与 Windows 共享网络堆栈，彻底解决代理镜像问题
+- `ghproxy.com` 反向代理可将 GitHub 下载请求重定向至国内可访问节点
 
 ## Key Quotes
-> "WSL2 默认使用 NAT 模式，常会出现'localhost 代理无法镜像'或无法访问海外资源的情况。" — 背景说明
-> "在 PowerShell 执行 `wsl --shutdown` 后重启 WSL。" — 镜像模式生效操作
+> "WSL2 默认使用 NAT 模式，常会出现 localhost 代理无法镜像或无法访问海外资源的情况" — 问题背景说明
+> "这是最稳妥的方案，使 WSL2 与 Windows 共享网络堆栈" — 镜像模式推荐理由
+> "始终先执行 `cd ~` 进入 Linux 原生家目录后再进行环境配置" — 文件权限最佳实践
 
 ## Key Concepts
-- [[WSL2]]：Windows Subsystem for Linux 2，Windows 10/11 内置的 Linux 虚拟机环境，默认使用 NAT 网络模式
-- [[镜像网络模式]]（Mirrored Network Mode）：WSL2 与 Windows 共享网络堆栈的配置模式，使 WSL2 能直接访问 Windows 代理
-- [[NAT模式]]：WSL2 默认网络模式，WSL2 拥有独立 IP，localhost 代理不可用
-- [[ghproxy]]：ghproxy.com，反向代理服务，将 GitHub 资源 URL 替换为代理地址以绕过网络限制
+- [[WSL2]]：Windows Subsystem for Linux 2，Windows 10/11 内置 Linux 虚拟机环境
+- [[镜像网络模式（Mirrored Networking）]]：WSL2 网络配置选项，使 WSL2 与 Windows 共享网络堆栈而非 NAT
+- [[NAT 模式]]：WSL2 默认网络模式，WSL2 有独立 IP 与 Windows 隔离
+- [[ghproxy]]：ghproxy.com，GitHub 反向代理加速服务
 
 ## Key Entities
-- [[Ubuntu]]：WSL2 默认安装的 Linux 分发版
-- [[Windows]]：宿主操作系统，WSL2 运行其上
-- [[PowerShell]]：Windows 命令行环境，用于执行 wsl 管理命令
+- [[WSL2]]：本文档主题，Windows 内置 Linux 子系统第二版
+- [[uv]]：Python 包管理/安装工具，本文通过镜像地址安装
+- [[Hermes Agent]]：本文通过 ghproxy 镜像安装的 AI Agent 产品
 
 ## Connections
-- [[Ubuntu Server]] ← related_to ← [[WSL2]]（WSL2 是 Ubuntu 在 Windows 上的轻量运行方式）
-- [[ubuntu-server科学上网]] ← related_to ← [[WSL2 网络配置]]（均涉及 Linux 环境代理配置）
+- [[Install WSL]] ← depends_on ← [[WSL2 启动与网络配置指南]]（安装指南为前置，配置指南为后续）
+- [[WSL2 启动与网络配置指南]] ← extends ← [[Ubuntu Server科学上网]]（均为 Linux 环境网络配置）
+- [[WSL2 启动与网络配置指南]] ← uses ← [[ghproxy]]（ghproxy 是解决 GitHub 下载的核心工具）
 
 ## Contradictions
-- （无已知冲突）
+- 与 [[Install WSL]] 视角差异：
+  - 冲突点：Install WSL 聚焦安装过程，本文聚焦日常使用与网络配置
+  - 当前观点：本文将网络配置作为 WSL2 日常使用的重要组成部分
+  - 对方观点：Install WSL 将安装与配置视为独立阶段
+  - 说明：两者互补，无本质冲突，安装指南完成后需参考本文完成网络配置

wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md

@@ -1,51 +1,49 @@
 ---
 title: "实战笔记：本地部署 RSSHub 并获取 YouTube 订阅"
 type: source
-tags: ["Home Office", "RSSHub", "YouTube", "Docker"]
-date: 2026-04-21
+tags: [rsshub, youtube, docker, self-hosted]
+date: 2026-04-23
 ---
 
 ## Source File
-- [[raw/Home Office/实战笔记：本地部署 RSSHub 并获取 YouTube 订阅.md]]
+- [[Home Office/实战笔记：本地部署 RSSHub 并获取 YouTube 订阅]]
 
 ## Summary（用中文描述）
-- 核心主题：本地自托管 RSSHub 并通过其生成 YouTube 频道 RSS 订阅源
-- 问题域：YouTube 官方不直接提供 RSS，且第三方在线 RSS 服务不稳定
-- 方法/机制：
-  - Docker Compose 一键部署 RSSHub（port 1200）
-  - 获取 YouTube 频道 ID（浏览器 view-source 方式）
-  - RSSHub 路由格式 `/youtube/channel/{channel_id}` 生成 RSS 源
-  - 支持订阅列表监控
-- 结论/价值：完全自托管，稳定可靠，绕过 YouTube 官方限制
+- 核心主题：通过本地部署 RSSHub 解决 YouTube 频道订阅跟踪问题
+- 问题域：国内网络无法直接访问 YouTube，以及 YouTube 官方缺乏订阅通知机制
+- 方法/机制：在 Ubuntu Server 宿主机上使用 Docker Compose 部署 RSSHub，通过 YouTube Data API v3 稳定获取频道更新，配合本地 HTTP 代理实现容器内科学上网
+- 结论/价值：提供了一套稳定、低成本（免费 API 额度）的 YouTube 订阅 RSS 化方案
 
 ## Key Claims（用中文描述）
-- RSSHub Docker 部署命令：`docker run -d --name rsshub -p 1200:1200 diygod/rsshub`
-- YouTube 频道 ID 获取方式：浏览器访问频道页面 URL，`view-source:` 查看源码搜索 `channel_id`
-- RSSHub YouTube RSS 路由：`http://localhost:1200/youtube/channel/{channel_id}`
-- 支持订阅列表路由：`/youtube/channel/{channel_id}/videos` 获取该频道视频列表
+- YouTube Data API v3 提供充足免费额度，足以支撑个人用户每月使用
+- 配置 YOUTUBE_KEY 环境变量是解决 YouTube 抓取失败的核心手段
+- 通过 HTTP_PROXY / HTTPS_PROXY 代理可解决容器内访问 YouTube 的网络问题
+- 防火墙放通端口后，局域网内其他设备均可访问 RSSHub 服务
+- 验证成功的标志：访问 RSSHub 频道 URL 返回 XML 列表且无 `fetch failed` 错误
 
 ## Key Quotes
-> "RSSHub 是一个开源、简单易用、方便扩展的 RSS 生成器" — RSSHub 官方定位
+> "这是解决 YouTube 订阅最稳定的方案，每月有足够的免费额度供个人使用。" — 方案定性
 
-> "获取 YouTube 频道 ID 的方法：访问频道页面 → view-source → 搜索 channel_id" — 频道 ID 获取技巧
+> "配置 YOUTUBE_KEY=AIzaSy... 后，通过 HTTP_PROXY=http://127.0.0.1:10808 实现容器内科学上网" — 核心配置逻辑
 
 ## Key Concepts
-- [[RSSHub]]：开源 RSS 聚合生成器，可为不支持 RSS 的网站生成订阅源
-- [[Docker]]：容器化平台，RSSHub 通过 Docker 一键部署
-- [[RSS]]：Really Simple Syndication，网站内容聚合订阅协议
+- [[RSSHub]]：开源 RSS 聚合器，支持为各种不支持 RSS 的网站生成 RSS 源
+- [[YouTube Data API v3]]：Google 官方 API，通过申请 API Key 可稳定获取 YouTube 频道/视频数据
+- [[Docker Compose]]：Docker 编排工具，用于定义和运行多容器 Docker 应用
+- [[HTTP_PROXY]]：HTTP 代理环境变量，RSSHub 容器通过此变量将出站请求经代理发出
 
 ## Key Entities
-- [[diygod]]（DIYgod）：RSSHub 项目的主要维护者，Docker 镜像 `diygod/rsshub` 的发布者
-- [[YouTube]]：视频平台，本场景的 RSS 订阅目标
+- [[RSSHub]]：开源项目（diygod/rsshub），提供 YouTube RSS 路由
+- [[Google Cloud Console]]：YouTube Data API Key 的申请入口
 
 ## Connections
-- [[RSSHub]] ← 使用 Docker 部署 ← [[Docker]]
-- [[RSSHub]] ← 为 [[YouTube]] 生成 RSS ← [[YouTube Content Pipeline]]
-- [[YouTube Content Pipeline]] ← 依赖 RSS 监控 ← [[RSSHub]]
+- [[YouTube Content Pipeline]] ← uses ← [[RSSHub]]
+- [[RSSHub]] ← requires ← [[YouTube Data API v3]]
+- [[Docker Compose]] ← hosts ← [[RSSHub]]
+- [[Home Office]] ← location ← 当前笔记归属 Home Office 分类
 
 ## Contradictions
-- 与 [[How to Get the RSS Feed For Any YouTube Channel]] 略有差异：
-  - 冲突点：在线获取 vs 本地生成
-  - 当前观点：本地 RSSHub 部署更稳定可靠
-  - 对方观点：在线服务无需维护，适合临时使用
-  - 结论：两者互补使用——RSSHub 主用 + 在线工具备用
+- 与 [[how-to-get-the-rss-feed-for-any-youtube-channel]] 可能存在互补：
+  - 冲突点：对方文章介绍的是无需 API Key 的第三方服务方案
+  - 当前观点：自建 RSSHub + YouTube API Key = 稳定可控
+  - 对方观点：第三方 RSS 生成服务 = 零配置但依赖外部服务稳定性