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

2026-04-28 12:03:10 +08:00
parent c898cc3fb9
commit f8b421ece6
45 changed files with 1739 additions and 1073 deletions
--- a/wiki/sources/ai-memory-tools-two-camps.md
+++ b/wiki/sources/ai-memory-tools-two-camps.md
@@ -1,68 +1,76 @@
 ---
 title: "I Went Through Every AI Memory Tool I Could Find. There Are Two Camps."
 type: source
-tags: [ai-agent, memory, context-management, tooling]
+tags: [AI-Agent, Memory-Tools, Context-Management, Agentic-AI]
 sources: []
-last_updated: 2026-04-23
+last_updated: 2026-04-15
 ---

 ## Source File
- [[raw/Agent/AI-Memory-Tools-Two-Camps.md]]
+- [[Agent/AI-Memory-Tools-Two-Camps.md]]

 ## Summary（用中文描述）
- 核心主题：AI 记忆工具的全景分类——揭示该领域存在两个根本不同的技术路线
- 问题域：AI Agent 的持久化上下文问题——如何让 Agent 跨会话保持记忆
- 方法/机制：Camp 1（记忆后端）通过向量提取+检索解决事实召回；Camp 2（上下文基质）通过文件累积+背景整合实现上下文复合增长
- 结论/价值：提出了"记忆"与"上下文"不是同一问题的核心洞察；预测 6 个月内"context engineering"将取代"memory"成为主流术语；ALIVE 是作者实际运行的上下文基质方案
+- 核心主题：AI Agent 记忆工具的全景分类——作者系统梳理了 450+ 个 GitHub 仓库，将 AI 记忆工具划分为两个根本不同的范式阵营
+- 问题域：AI Agent 如何在多会话、长时间运行的场景中保持上下文连续性
+- 方法/机制：提出 Memory Backend（记忆后端）和 Context Substrate（上下文基质）两大阵营的分类框架
+- 结论/价值：Camp 1 工具解决"事实召回"问题；Camp 2 工具解决"上下文累积复合"问题；长期运行的 Agent 需要 Context Substrate 架构；"Context Engineering"将取代"Memory"成为主流术语

 ## Key Claims（用中文描述）
- Camp 1 与 Camp 2 是两个根本不同的技术范式，而非同一问题的不同实现
- Camp 1 工具优化目标是**召回**：能否找到正确的事实
- Camp 2 工具优化目标是**复合**：系统是否随时间变得更好
- Zep 将品牌定位从"memory"重塑为"context engineering"是市场上最强的信号，表明 Camp 2 路线正在成为主流
- GitHub 上 450+ repos 标记"agent-memory"、460+ 标记"context-management"，但几乎无人明确区分这两种范式
- 持续运行的 24/7 Agent 场景下，只有 Camp 2 架构才能真正实现跨会话复合增长
+- 作者系统梳理了 450+ 个 GitHub 仓库，将 AI 记忆工具划分为两个根本不同的范式阵营
+- Camp 1（Memory Backend）：从对话中提取事实，存入向量数据库，检索相关事实——问的是"AI 应该记住什么？"
+- Camp 2（Context Substrate）：维护结构化、人类可读的上下文，跨会话累积——问的是"AI 应该在什么上下文中工作？"
+- Camp 1 工具的共同循环：对话发生 → 系统提取事实或存储内容 → 事实进入数据库（向量、图或两者） → 下一对话，检索并注入相关事实
+- Camp 2 工具的共同循环：Agent 工作前读取结构化上下文 → Agent 在上下文中工作 → Agent 或后台进程写回结构化上下文 → 下一会话，上下文比之前更丰富
+- Camp 1 优化的是召回（recall）：系统能否找到正确的事实？
+- Camp 2 优化的是复合（compounding）：系统是否随时间变得更好？
+- Zep 从"Memory"全面重新品牌定位为"Context Engineering"，这是整个领域最强的市场信号
+- 作者预测：6 个月内，"Context Engineering"将取代"Memory"成为严肃 Agent 基础设施的默认术语

 ## Key Quotes
-> "there are 450+ repos tagged 'agent-memory' on github and 460+ tagged 'context-management.' me and my agentic best friends went through them." — @witcheer，揭示该领域分类混乱的现状
-> "the line from their docs that defines the philosophy: 'the model only remembers what gets saved to disk, there is no hidden state.'" — OpenClaw 定义了 Camp 2 的核心哲学
-> "a funded company with 4.4k stars looked at where the space was going and decided 'memory' was the wrong word for what they were building." — Zep 的品牌重塑是市场信号
-> "within 6 months, 'context engineering' replaces 'memory' as the default term for what serious agent infrastructure does." — 作者的核心预测
-> "if you're building agents that need to run for more than one conversation, you're going to end up here." — Camp 2 是长期运行 Agent 的必然归宿
+> "the model only 'remembers' what gets saved to disk, there is no hidden state." — OpenClaw 官方文档，定义 Context Substrate 的核心哲学
+> "memory is not RAG." — Supermemory 的核心差异化定位
+> "Context Cores" — TrustGraph 引入的便携、带版本的知识容器，可类比代码进行版本控制、测试和回滚
+> "ALIVE (alivecontext.com)" — 作者正在使用的 Context Substrate 项目，结构化上下文基质、文件原生、Agent 无关

 ## Key Concepts
- [[Memory Backend]]：从对话中提取事实，存入向量数据库，检索时召回。代表工具：Mem0、MemPalace、Supermemory、Honcho、Cognee。核心问题：记忆是扁平条目，无关系；提取质量依赖 LLM prompt；事实不进化
- [[Context Substrate]]：维护结构化、人类可读的上下文文件，跨会话累积。代表工具：OpenClaw、Zep、Thoth、TrustGraph、MemSearch、ALIVE。核心哲学："nothing gets extracted — the context is the files"
- [[Fact Recall]] vs [[Compounding]]：Camp 1 优化召回精度，Camp 2 优化复合增长；前者问"AI 应该记住什么"，后者问"AI 应该在什么样的上下文中工作"
- [[Dreaming Cycle]]：OpenClaw 的背景整合过程——light sleep（分组）→ REM（频繁访问提升）→ deep sleep（写入长期记忆），六维评分机制（相关性0.30、频率0.24、查询多样性0.15、时效性0.15、整合度0.10、概念丰富度0.06）
- [[Temporal Knowledge Graph]]：Zep 的 Graphiti 框架使用带 valid_at/invalid_at 时间戳的知识图谱，自动提取关系，返回预格式化上下文块，<200ms 检索
- [[Context Core]]：TrustGraph 引入的可移植、带版本控制的上下文捆绑包（领域schema+知识图谱+向量嵌入+证据来源+检索策略），将上下文视为第一公民制品
- [[Context Engineering]]：作者预测将取代"memory"成为描述 Agent 基础设施的标准术语
+- [[Memory-Backend]]：从对话中提取事实并存储到向量数据库的工具范式；代表工具：Mem0、MemPalace、Supermemory；核心问题是"事实召回"
+- [[Context-Substrate]]：维护结构化、人类可读上下文，跨会话累积，不提取事实而是让上下文成为文件本身的工具范式；代表工具：OpenClaw、Zep、Thoth、TrustGraph；核心问题是"上下文复合"
+- [[Context-Engineering]]：由 Zep 重新品牌化引入的术语，代表从"Memory"向"Context Substrate"方向的范式转移
+- [[Dream-Cycle]]：OpenClaw 和 Thoth 采用的后台知识整合机制——夜间多阶段过程将日常笔记整合为长期记忆
+- [[Context-Cores]]：TrustGraph 引入的概念，便携、带版本的上下文容器，包含领域 schema、知识图谱、向量嵌入、证据来源和检索策略
+- [[Fact-Recall-vs-Compounding]]：Camp 1 优化召回精度（96%+），Camp 2 优化随时间的复合增长能力

 ## Key Entities
- [[Mem0]]：53.1k stars，Camp 1 类别领导者，四操作（add/search/update/delete），三层存储（user/session/agent），混合检索，集成简单但记忆为扁平条目，无关系推理
- [[MemPalace]]：46.2k stars，本地优先逐字记忆，用 ChromaDB 组织为 wings（实体）/rooms（主题）/drawers（原内容），LongMemEval 96.6% 召回率但线性增长无压缩
- [[Supermemory]]：21.8k stars，差异化是时序感知（"I moved to SF"自动取代旧城市），expired facts 自动遗忘，MemoryBench 声称第一，多模态连接器（Google Drive/Gmail/Notion/GitHub）
- [[Honcho]]：2.4k stars，将人/Agent 视为统一模型中的"对等体"，异步推理服务推导心理洞察，PostgreSQL + pgvector，AGPL-3.0
- [[OpenClaw]]：358k stars，plain markdown 文件（Mmemory.md + daily notes + DREAMS.md），无向量数据库，dreaming 三阶段整合，Camp 2 典型代表
- [[Zep]]：4.4k stars，从"memory"重塑品牌为"context engineering"，Graphiti 时序知识图谱，SOC2 Type 2 + HIPAA 合规，<200ms 检索，架构上处于两 Camp 边界
- [[Thoth]]：145 stars，最深层架构，10 实体类型 + 67 有向关系类型 + FAISS + 图扩展检索，四阶段夜间 dream cycle，三层反污染机制防止跨实体事实混淆
- [[TrustGraph]]：2.0k stars，Context Cores 可移植版本化上下文容器，treats context like code，Cassandra + Qdrant 基础设施
- [[MemSearch]]：1.2k stars，Zilliz 团队出品，Markdown 文件为唯一真相，Milvus 为下游"阴影索引"，三层层级渐进披露（语义块→完整章节→原始记录）
- [[ALIVE]]：作者实际运行的方案，structured context substrate，file-native，agent-agnostic，walnuts 作为可移植上下文容器，零基础设施依赖，运行在 Hermes Agent + Claude Code + Mac Mini M4 上
+- [[Mem0]]（53.1k stars）：Camp 1 类别领导者，四操作（add/search/update/delete），三层级存储（user/session/agent），依赖提取质量
+- [[MemPalace]]（46.2k stars）：本地优先，逐字记忆，Wings/Rooms/Drawers 组织结构，LongMemEval 基准 96.6% 纯语义搜索召回率
+- [[Supermemory]]（21.8k stars）：时间感知，自动覆盖过期事实，声称在 LongMemEval/LoCoMo/ConvoMem 排名第一，提出 MemoryBench 基准
+- [[Honcho]]（2.4k stars）：将人和 Agent 视为统一模型中的对等体，后台异步推理服务推导心理洞察，PostgreSQL + pgvector
+- [[OpenClaw]]（358k stars）：Camp 2 代表，MEMORY.md + 每日笔记 + DREAMS.md 架构，"无隐藏状态"哲学，Dreaming 三阶段整合机制
+- [[Zep]]（4.4k stars）：从"Memory"重新品牌为"Context Engineering"，TKG 时间知识图谱（Graphiti），valid_at/invalid_at 时间戳，SOC2/HIPAA 合规
+- [[Thoth]]（145 stars）：10 种实体类型 + 67 种有向关系类型，FAISS + 图扩展，Dream Cycle 四阶段，90 天置信度衰减，反污染三层机制
+- [[TrustGraph]]（2.0k stars）：引入 Context Cores，将上下文视为代码（版本控制/测试/回滚），Cassandra + Qdrant 实现
+- [[MemSearch]]（1.2k stars）：Markdown 优先，Milvus 作为"影子索引"，文件是真相来源，向量搜索只是访问层
+- [[ALIVE]]（alivecontext.com）：作者 @witcheer 正在使用的 Context Substrate 项目，文件原生，Agent 无关，核桃作为便携上下文容器
+- [[@witcheer]]：Twitter/X 作者，24/7 Mac Mini M4 Agent 设置运营者，独立完成全景分析

 ## Connections
- [[RAG]] ← related_to ← [[Memory Backend]]：两者共享向量检索的基本机制，但 RAG 通常指一次性问答场景，Memory Backend 指跨会话累积
- [[OpenClaw]] ← implements ← [[Context Substrate]]：OpenClaw 的 Markdown 文件架构是 Context Substrate 范式的典型实现
- [[Semantic-Memory-Search]] ← extends ← [[OpenClaw]]：MemSearch 为 OpenClaw 的 Markdown 记忆提供语义搜索能力
- [[Memory Backend]] ← evolves_into ← [[Context Substrate]]：Supermemory 的时序感知和 Honcho 的心理建模代表了 Camp 1 向 Camp 2 的演进趋势
- [[Second Brain]] ← uses ← [[Context Substrate]]：[[Second Brain]] 基于 OpenClaw 的累积记忆能力，本质上是 Context Substrate 范式在个人知识管理中的应用
- [[养龙虾5天血泪史]] ← experiences ← [[OpenClaw]]：实战中暴露了 OpenClaw 记忆压缩和检索的痛点，推动了对 Context Substrate 架构的深入理解
- [[Context Substrate]] ← enables ← [[Self-Improving-Skill]]：Self-Improving 的复盘机制（[[养虾日记2]]）是 Context Substrate 中背景整合思想的实践
+- [[Mem0]] ← 属于 ← [[Memory-Backend]]
+- [[MemPalace]] ← 属于 ← [[Memory-Backend]]
+- [[Supermemory]] ← 属于 ← [[Memory-Backend]]
+- [[Honcho]] ← 属于 ← [[Memory-Backend]]
+- [[OpenClaw]] ← 属于 ← [[Context-Substrate]]
+- [[Zep]] ← 属于 ← [[Context-Substrate]]
+- [[Zep]] ← 重新品牌化 ← [[Context-Engineering]]
+- [[Thoth]] ← 属于 ← [[Context-Substrate]]
+- [[TrustGraph]] ← 引入 ← [[Context-Cores]]
+- [[OpenClaw]] ← 实现 ← [[Dream-Cycle]]
+- [[Thoth]] ← 实现 ← [[Dream-Cycle]]
+- [[Memory-Backend]] ← 优化目标 ← [[Fact-Recall-vs-Compounding]]
+- [[Context-Substrate]] ← 优化目标 ← [[Fact-Recall-vs-Compounding]]
+- [[Context-Engineering]] ← 预测将取代 ← [[Memory-Backend]]

 ## Contradictions
- 与 [[semantic-memory-search]] 可能存在张力：
-  - 冲突点：MemSearch（Camp 2）将向量索引视为文件的下游"阴影索引"，可随时重建；[[semantic-memory-search]] 则将向量搜索作为记忆检索的核心能力
-  - 当前观点：向量索引是可选的访问加速层，Markdown 文件才是唯一真相
-  - 对方观点：向量语义搜索是必要的，单纯的关键词/Markdown 文件无法高效处理"我上周讨论的那个关于 X 的内容"
-  - 注：两者其实互补——MemSearch 本身也使用混合搜索，但强调文件优先而非索引优先
+- 与 [[ALIVE]] 对比：
+  - 冲突点：ALIVE 声称是 Context Substrate，但文档未详细说明其具体架构实现细节
+  - 当前观点：ALIVE 是作者认为最有效的 Context Substrate 方案（因为在 24/7 设置中成功运行）
+  - 对方观点：现有 Wiki 中 ALIVE 页面可能缺少与其他 Camp 2 工具（OpenClaw/Thoth/Zep）的架构对比
--- a/wiki/sources/building-your-quartz.md
+++ b/wiki/sources/building-your-quartz.md
@@ -2,60 +2,51 @@
 title: "Building your Quartz"
 type: source
 tags:
+  - clippings
  - quartz
  - obsidian
-  - static-site-generator
-  - self-hosting
-date: 2026-03-04
+date: 2026-04-17
 ---

 ## Source File
- [[raw/Home Office/Building your Quartz.md]]
+- [[Home Office/Building your Quartz]]

 ## Summary（用中文描述）
- 核心主题：Quartz 静态网站的本地预览与自托管部署指南
- 问题域：如何将 Markdown 文件构建为可预览的本地网站，以及如何通过主流 Web 服务器（Nginx/Apache/Caddy）实现公网自托管
- 方法/机制：Quartz 将 Markdown 文件转换为 HTML/JS/CSSbundle；本地预览通过 `npx quartz build --serve` 启动热重载服务器；自托管需配置 Web 服务器处理无扩展名链接（`try_files $uri $uri.html $uri/`）
- 结论/价值：Quartz 提供了一套完整的从笔记到静态网站的构建与部署流程，支持多种主流 Web 服务器的自托管方案，适合将 Obsidian 笔记发布为公网可访问的静态网站
+- 核心主题：Quartz 静态网站构建与部署完整指南
+- 问题域：如何将 Obsidian 笔记发布为可公网访问的静态网站
+- 方法/机制：
+  - 本地预览模式：`npx quartz build --serve` 启动热重载预览服务器
+  - 自托管部署：通过 Nginx / Apache / Caddy 等主流 Web 服务器托管生成的 `public/` 目录
+  - 关键技术：利用 `try_files` 指令处理无扩展名 URL（Quartz 生成链接不含 `.html` 后缀）
+- 结论/价值：Quartz 是一个将 Markdown 文件转换为静态网站的工具，生成的 `public/` 目录可部署到任意静态托管平台，Serve 模式仅用于本地预览，生产部署需配置正确的 Web 服务器

 ## Key Claims（用中文描述）
- Quartz 将 Markdown 文件和资源转换为 HTML、JS 和 CSS 文件包（即一个网站）
- Serve 模式仅用于本地预览，生产环境部署需使用 GitHub Pages 等静态托管服务
- 静态托管前需正确配置 `baseUrl`，否则 RSS Feed 和 Sitemap 生成功能将无法正常工作
- 自托管时 Web 服务器必须处理不含 `.html` 扩展名的链接（Quartz 生成此类链接）
- Nginx 通过 `try_files $uri $uri.html $uri/ =404` 规则处理无扩展名链接
- Apache 通过 RewriteCond/RewriteRule 组合实现相同功能
- Caddy 通过 `try_files {path} {path}.html {path}/ =404` 实现，并支持 gzip 压缩和错误页处理
+- Quartz 将 Markdown 文件和资源转换为 HTML、JS、CSS 静态文件（网站）
+- 要发布网站到公网，需要使用托管服务，Quartz 生成的 `public/` 目录可部署到任何支持静态 HTML 的服务
+- 本地 Serve 模式仅用于预览，生产环境应使用专用托管方案
+- 由于 Quartz 生成不含 `.html` 扩展名的链接，Web 服务器需配置 `try_files` 规则来处理 URL 重写
+- 启用 RSS Feed 和 sitemap 功能需要正确配置 `baseUrl`

 ## Key Quotes
-> "Serve mode is intended for local previews only. For production workloads, see the page on hosting."
-> — Quartz 官方文档，明确 serve 模式仅用于本地预览
-
-> "Some Quartz features (like RSS Feed and sitemap generation) require `baseUrl` to be configured properly in your configuration to work properly."
-> — Quartz 官方文档，部署前必须配置 baseUrl
+> "Quartz effectively turns your Markdown files and other resources into a bundle of HTML, JS, and CSS files (a website!)." — 核心功能描述
+> "Serve mode is intended for local previews only. For production workloads, see the page on hosting." — Serve 模式用途说明
+> "Since Quartz generates links that do not include the `.html` extension, you need to let your web server know how to deal with it." — 自托管关键配置说明

 ## Key Concepts
- [[Quartz]]：Obsidian 笔记静态网站生成器，将 Markdown 转换为 HTML/JS/CSS bundle
- [[Static Site Generator]]：静态网站生成器，无需服务器端渲染，直接托管 HTML 文件
- [[npx quartz build]]：Quartz 构建命令，核心参数包括 `-d/--directory`（内容目录）、`-o/--output`（输出目录）、`--serve`（本地预览）、`--port`（端口）、`--concurrency`（并发数）
- [[try_files]]：Nginx 指令，按顺序尝试文件、HTML 文件、目录，最后返回 404
- [[RewriteRule]]：Apache mod_rewrite 模块指令，用于 URL 重写处理无扩展名链接
- [[baseUrl]]：Quartz 配置项，用于生成正确的绝对 URL，RSS Feed 和 Sitemap 功能依赖此配置
+- [[Static Site Generator]]：Quartz 的本质——将 Markdown 转换为静态 HTML/CSS/JS 网站的工具
+- [[Obsidian Publishing]]：Quartz 作为 Obsidian 笔记发布平台的角色
+- [[try_files Directive]]：Nginx/Caddy 中用于处理无扩展名 URL 的指令，Quartz 自托管必须配置

 ## Key Entities
- [[Quartz]]：开源静态网站生成器，专注于将 Obsidian 风格的双链笔记发布为静态网站
- [[Obsidian]]：本地笔记软件，Quartz 的内容来源
- [[GitHub Pages]]：Quartz 推荐的公网托管方案
+- Quartz：开源 Obsidian 发布工具，由 jzhao.xyz 维护
+- Nginx：主流开源 Web 服务器，用于自托管 Quartz 生成的静态网站
+- Apache：另一种主流 Web 服务器，支持 .htaccess 配置 URL 重写
+- Caddy：现代开源 Web 服务器，默认支持 HTTPS，内置静态文件服务

 ## Connections
- [[Obsidian]] — provides content → [[Quartz]]
- [[Quartz]] — builds to static files → [[Static Site Generator]]
- [[Quartz]] — local preview → [[npx quartz build --serve]]
- [[Quartz]] — production deployment → [[GitHub Pages]] / Self-hosting
- Self-hosting — requires → [[try_files]] (Nginx) / [[RewriteRule]] (Apache) / [[Caddyfile]] (Caddy)
+- [[Obsidian]] ← uses ← [[Building your Quartz]]
+- [[Static Site Generator]] ← implements ← [[Building your Quartz]]
+- [[Obsidian Publishing]] ← extends ← [[Obsidian]]

 ## Contradictions
- 与通用静态网站托管方案（如 Vercel/Netlify）冲突：
-  - 冲突点：这些平台自动处理 URL 重写，无需手动配置 Web 服务器
-  - 当前观点：Quartz 支持手动自托管（自行配置 Nginx/Apache/Caddy），提供完全控制权
-  - 对方观点：使用 Vercel/Netlify 可零配置自动部署，省去服务器维护成本
+- 无已知冲突内容
--- a/wiki/sources/gog-cli-安装配置指南.md
+++ b/wiki/sources/gog-cli-安装配置指南.md
@@ -1,7 +1,7 @@
 ---
 title: "GOG CLI 安装配置指南"
 type: source
-tags: [gog, gog-cli, macos, google-workspace]
+tags: [gog, gog-cli, macos, google-workspace, oauth]
 date: 2026-03-15
 ---

@@ -9,37 +9,39 @@ date: 2026-03-15
 - [[raw/Skills/GOG-CLI-安装配置指南.md]]

 ## Summary（用中文描述）
- 核心主题：gog CLI（Google Workspace 命令行工具）在 macOS 系统上的完整安装与配置流程
- 问题域：如何通过命令行管理 Google Workspace 全套服务（Gmail、Google Calendar、Google Drive、Google Contacts、Google Docs、Google Sheets），并与 AI Agent 工作流集成
- 方法/机制：Homebrew 安装 → Google Cloud Console 创建 OAuth 凭证 → 移动凭证文件到 gogcli 配置目录 → 添加测试用户解除 Google 安全限制 → 启用各 Google API → 验证授权状态
- 结论/价值：实现通过命令行管理 Google Workspace 全套服务的能力，可集成到 AI Agent 工作流中（自动邮件处理、日历管理等）
+- 核心主题：gog CLI 工具在 macOS 上的完整安装与配置流程
+- 问题域：Google Workspace（Gmail、Google Calendar、Google Drive、Google Contacts、Google Docs、Google Sheets）的命令行管理
+- 方法/机制：通过 Homebrew 安装 → Google Cloud Console 创建 OAuth 凭证 → 配置凭证文件 → 添加测试用户绕过 Google 安全验证 → 启用各 Google API → 验证授权
+- 结论/价值：实现通过命令行高效管理 Google Workspace 全套服务，支持搜索邮件、发送邮件、管理日历、搜索 Drive 文件、操作 Sheets/Docs 等功能

 ## Key Claims（用中文描述）
- Homebrew 可通过 `brew install steipete/tap/gogcli` 一键安装 gog CLI，输出路径为 `/opt/homebrew/bin/gog`
- OAuth 凭证需要放置在 `/Users/weishen/Library/Application Support/gogcli/credentials.json`，并通过 `gog auth credentials` 命令指定路径
- 首次授权时 Google 会阻止未验证应用，需要在 Google Cloud Console 的 OAuth 客户端中将测试用户邮箱加入白名单才能通过授权
- Google API 调用需要同时满足两个条件：OAuth 授权成功 + API 已启用（Enabling），缺一不可
- 启用新的 API 服务后需要重新授权（`gog auth revoke` + `gog auth login`），因为旧 token 不包含新权限
+- 通过 Homebrew 安装 gog CLI 是最简方式，安装路径为 /opt/homebrew/bin/gog
+- Google API 调用需同时满足 OAuth 授权和 API Enablement 两层条件，缺一不可
+- 对于未经 Google 验证的应用，通过在 OAuth 客户端中添加测试用户可绕过"此应用未经 Google 验证"的安全限制
+- 启用新 API 服务后需重新授权（revoke + login），否则旧 token 不包含新权限会导致 403 错误
+- 设置 GOG_ACCOUNT 环境变量可避免每次命令都需指定账号

 ## Key Quotes
-> "此应用未经 Google 验证。此应用请求访问您 Google 账号中的敏感信息。在开发者让该应用通过 Google 验证之前，请勿使用该应用。" — Google 首次授权时的安全警告，解决方案是在测试用户中添加 Google 邮箱
-> "即使 OAuth 成功，如果 API 未启用也会报错：403 accessNotConfigured" — API 调用失败的常见原因
-> "旧 token 不包含新权限" — 启用新 API 后必须重新授权的原因
+> "此应用未经 Google 验证。此应用请求访问您 Google 账号中的敏感信息。在开发者让该应用通过 Google 验证之前，请勿使用该应用。" — 首次授权时的典型 Google 安全警告
+> "即使 OAuth 成功，如果 API 未启用也会报错：403 accessNotConfigured" — OAuth 与 API Enablement 的两层机制说明
+> "gog auth revoke → gog auth login：旧 token 不包含新权限" — 启用新 API 后的必要重新授权步骤

 ## Key Concepts
- [[OAuth 2.0]]：Google 账号身份认证协议，gog CLI 使用 OAuth 完成用户授权
- [[Google Cloud Console]]：Google API 管理平台，用于创建 OAuth 凭证和启用 API 服务
- [[Google Workspace]]：Google 办公套件，包含 Gmail、Google Calendar、Google Drive、Google Contacts、Google Docs、Google Sheets
- [[Google API Enablement]]：Google API 调用需要先在 Google Cloud Console 中启用对应服务，与 OAuth 认证是两层独立机制
+- [[OAuth 2.0]]：Google API 的用户身份认证机制，gog 通过 OAuth 让用户授权 CLI 访问其 Google 账号数据
+- [[Google Cloud Console]]：Google 云平台控制台，用于创建 OAuth 凭证和启用 Google API 服务
+- [[Google Workspace]]：Google 生产力工具套件，包含 Gmail、Google Calendar、Google Drive、Google Contacts、Google Docs、Google Sheets
+- [[Homebrew]]：macOS 包管理器，gog CLI 通过 `brew install steipete/tap/gogcli` 安装

 ## Key Entities
- [[gog CLI]]：由 steipete 开发的 Google Workspace 命令行管理工具，通过 Homebrew 分发
- [[Google Cloud Console]]：Google 云平台控制台，用于管理 OAuth 凭证和 API 启用状态
+- [[steipete]]：gogcli 项目的开发者，维护 gog CLI 工具
+- [[ishenwei@gmail.com]]：配置中使用的 Google 账号，通过该账号授权 gog 访问 Google Workspace

 ## Connections
- [[personal-crm]] ← uses ← [[gog CLI]]（gog CLI 提供 Gmail 和 Calendar 数据，是 personal-crm 的前置依赖）
- [[gog CLI]] ← requires ← [[OAuth 2.0]]（认证机制）
- [[gog CLI]] ← requires ← [[Google API Enablement]]（每项服务需单独启用）
+- [[Homebrew]] ← 安装工具 ← [[GOG CLI 安装配置指南]]
+- [[Google Workspace]] ← 管理对象 ← [[GOG CLI 安装配置指南]]
+- [[OAuth 2.0]] ← 认证机制 ← [[GOG CLI 安装配置指南]]
+- [[Google Cloud Console]] ← 配置平台 ← [[GOG CLI 安装配置指南]]

 ## Contradictions
- 无已知冲突内容
+- 暂无已知冲突内容
+
--- a/wiki/sources/last30days-使用指南.md
+++ b/wiki/sources/last30days-使用指南.md
@@ -1,35 +1,53 @@
 ---
 title: "Last30Days 使用指南"
 type: source
-tags: []
-date: 2026-04-21
+tags: [hackernews, instagram, last30days, polymarket, scrapecreator, tiktok, x, youtube]
+date: 2026-04-28
 ---

 ## Source File
 - [[raw/Skills/Last30Days-使用指南.md]]

 ## Summary（用中文描述）
- 核心主题：Last30Days 方法论——通过 AI Agent 自动化追踪近30天内新增/更新的内容源（网站、社交媒体、工具更新），避免信息过载
- 问题域：个人知识管理、信息聚合、竞品监控
- 方法/机制：配置信息源列表 → AI Agent 定时扫描 → 去重过滤 → 摘要生成 → 投递
- 结论/价值：将"主动订阅"转变为"被动接收"，用 AI 替代人工巡检，节省 80% 信息搜集时间
+- 核心主题：Last30Days 工具的使用方法与最佳实践
+- 问题域：如何在 Reddit、X、YouTube、TikTok、Instagram、Hacker News、Polymarket 等平台上研究过去 30 天的热门内容
+- 方法/机制：通过 Python 脚本调用多个数据源 API，整合互动数据（upvotes/likes/views）生成结构化研究报告
+- 结论/价值：提供了一套完整的多平台热点研究工作流，支持快速模式、深度模式、对比模式，适用于行业追踪、竞品分析、工具选型等场景

 ## Key Claims（用中文描述）
- Last30Days Agent 通过定时扫描使信息追踪从主动变为被动，减少认知负担
- 近30天内容过滤机制天然去除了过时信息，保证了内容新鲜度
- AI 驱动的摘要生成将原始内容压缩为可操作的关键要点
- 多渠道投递（Discord/Telegram/Email）确保用户在常用平台接收更新
+- Last30Days 通过整合 8 个数据来源生成研究报告，其中 Reddit/X 权重最高
+- ScrapeCreators API key 一个 key 覆盖 Reddit + TikTok + Instagram 三个平台
+- X 搜索支持两种方案：浏览器 Cookie (AUTH_TOKEN/CT0) 或 XAI API Key
+- 对比模式（"A vs B"）可生成并排对比研究报告
+- Polymarket 赔率数据因真实钱币投注，是最高置信度的数据来源

 ## Key Quotes
-> "信息不是力量，整理过的信息才是" — 核心价值主张
+> "深度研究需要 2-8 分钟，支持 8 个数据来源" — 工具能力说明
+> "Reddit 评论往往比帖子更有价值，关注 top comments" — 最佳实践建议
+> "Polymarket 赔率是最高置信度的数据" — 数据权重说明

 ## Key Concepts
- [[Last 30 Days Method]]：信息追踪方法论，只关注近30天内更新内容，过滤历史噪音
- [[信息消费习惯]]：从主动搜索到被动接收的范式转变
+- [[数据源权重排序]]：Reddit/X > YouTube > TikTok > Polymarket > Web，不同来源权重不同
+- [[对比模式]]：使用 "A vs B" 格式可生成并排对比研究报告
+- [[紧凑输出模式]]：通过 --emit=compact 参数控制输出格式
+- [[多平台数据整合]]：整合 Reddit、X、YouTube、TikTok、Instagram、Hacker News、Polymarket、Web 的数据

 ## Key Entities
- [[Last30Days]]：核心工具/方法论本身
+- [[OpenClaw]]：Last30Days 工具所在的技术栈平台
+- [[ScrapeCreators]]：覆盖 Reddit + TikTok + Instagram 的 API 服务
+- [[XAI]]：作为 X/Twitter 搜索的替代 API 方案
+- [[Polymarket]]：预测市场平台，提供真实钱币投注的赔率数据

 ## Connections
- [[Multi-Source Tech News Digest]] ← 相似模式 ← [[Last 30 Days Method]]
- [[Personal Knowledge Base (RAG)]] ← 支持 ← [[Last 30 Days Method]]
+- [[Multi-Source Tech News Digest]] ← related_to ← [[Last30Days 使用指南]]
+- [[Polymarket Autopilot: Automated Paper Trading]] ← extends ← [[Last30Days 使用指南]]
+- [[YouTube Content Pipeline]] ← related_to ← [[Last30Days 使用指南]]
+- [[Daily Reddit Digest]] ← related_to ← [[Last30Days 使用指南]]
+
+## Contradictions
+- 无已知冲突内容
+
+## Related Resources
+- GitHub: https://github.com/mvanhorn/last30days-skill
+- 技能目录: `~/.openclaw/skills/last30days-official/`
+- 研究保存: `~/Documents/Last30Days/`
--- a/wiki/sources/learn-ai-for-free-directly-from-top-companies.md
+++ b/wiki/sources/learn-ai-for-free-directly-from-top-companies.md
@@ -3,55 +3,49 @@ title: "Learn AI for free directly from top companies"
 type: source
 tags:
  - "AI学习"
-  - "教育资源"
-  - "免费课程"
+  - "免费资源"
+  - "在线课程"
 date: 2026-04-16
 ---

 ## Source File
- [[raw/AI/Learn AI for free directly from top companies.md]]
+- [[AI/Learn AI for free directly from top companies.md]]

 ## Summary（用中文描述）
- 核心主题：汇总全球顶级科技公司提供的免费 AI 学习资源
- 问题域：AI 教育普及与免费学习资源获取
- 方法/机制：列举 10 家顶级公司/平台的免费 AI 课程资源及直链
- 结论/价值：无需付费，即可直接获取权威 AI 培训内容
+- 核心主题：汇总顶级科技公司和AI组织提供的免费学习资源，帮助用户免费学习AI技能
+- 问题域：AI学习路径规划、免费教育资源发现
+- 方法/机制：通过X(Twitter)线程形式，由社区整理并分享头部AI公司的官方免费学习平台链接
+- 结论/价值：一份高价值的免费AI学习资源导航，覆盖从基础到进阶的完整学习路径

 ## Key Claims（用中文描述）
- Anthropic 提供免费 AI 技能培训平台（Skilljar）
- Google 提供免费 AI 学习路径（Google AI Learning）
- Meta 开源 AI 学习资源平台
- NVIDIA 提供 CUDA 开发者免费学习资源
- Microsoft 提供免费技术培训（Microsoft Learn）
- OpenAI 提供 Academy 免费课程
- IBM SkillsBuild 提供免费 AI 技能培训
- AWS 提供 Skill Builder 免费学习平台
- DeepLearning.AI 提供免费 AI 课程
- Hugging Face 提供免费学习路径
+- 顶级AI公司均提供免费学习资源，无需付费即可学习前沿AI技能
+- 学习资源来自Anthropic、Google、Meta、NVIDIA、Microsoft、OpenAI、IBM、AWS、DeepLearning.AI、Hugging Face等头部组织
+- 学习路径可从基础概念（DeepLearning.AI/Hugging Face）到专业认证（AWS Skills Builder/IBM SkillsBuild）全覆盖

 ## Key Quotes
-> "Learn AI for free directly from top companies." — Leonard Rodman (@RodmanAi)
+> "Learn AI for free directly from top companies." — @RodmanAi，2026-04-15，号召社区收藏分享
+> "Must bookmark for future reference." — @RodmanAi，强调资源的长期参考价值

 ## Key Concepts
- [[AI教育]]
- [[免费学习资源]]
- [[企业级AI培训]]
+- [[AI免费学习]]：通过官方免费课程和培训平台获取AI知识和技能

 ## Key Entities
- [[Anthropic]]：AI 安全与对齐研究公司，提供 skilljar.com 免费培训平台
- [[Google]]：提供 grow.google/ai 免费 AI 学习路径
- [[Meta]]：提供 ai.meta.com/resources/ 开源 AI 学习资源
- [[NVIDIA]]：提供 developer.nvidia.com/cuda 免费 CUDA 课程
- [[Microsoft]]：提供 Microsoft Learn 免费技术培训平台
- [[OpenAI]]：提供 academy.openai.com 免费课程
- [[IBM]]：通过 SkillsBuild 提供免费 AI 技能培训
- [[AWS]]：通过 Skill Builder 提供免费学习平台
- [[DeepLearning.AI]]：吴恩达创立的免费 AI 课程平台
- [[Hugging Face]]：提供 huggingface.co/learn 免费学习路径
+- [[Anthropic]]：AI安全公司，提供 Claude 官方培训课程
+- [[Google]]：提供 Google AI 学习平台 (grow.google/ai)
+- [[Meta]]：提供 AI 资源中心 (ai.meta.com)
+- [[NVIDIA]]：提供 CUDA 开发者学习资源
+- [[Microsoft]]：提供 Azure AI 和机器学习培训
+- [[OpenAI]]：提供 OpenAI Academy 课程
+- [[IBM]]：提供 SkillsBuild 免费技能培训
+- [[AWS]]：提供 AWS Skills Builder 免费学习平台
+- [[DeepLearning.AI]]：吴恩达创办的深度学习教育平台
+- [[Hugging Face]]：提供开源机器学习学习资源

 ## Connections
- [[AI教育]] ← 资源来源 ← [[Anthropic]] / [[Google]] / [[Meta]] / [[NVIDIA]] / [[Microsoft]] / [[OpenAI]] / [[IBM]] / [[AWS]] / [[DeepLearning.AI]] / [[Hugging Face]]
- [[免费学习资源]] ← 涵盖 ← [[Claude Prompt Library]]（Anthropic 官方提示词库）
+- [[DeepLearning.AI]] ← provides ← [[AI免费学习]] resources
+- [[Hugging Face]] ← provides ← [[AI免费学习]] resources
+- [[AWS Skills Builder]] ← provides ← [[AI免费学习]] resources
+- [[IBM SkillsBuild]] ← provides ← [[AI免费学习]] resources

 ## Contradictions
 - 无已知冲突
--- a/wiki/sources/obsidian-必装-skills.md
+++ b/wiki/sources/obsidian-必装-skills.md
@@ -2,63 +2,64 @@
 title: "Obsidian 必装 Skills"
 type: source
 tags: [obsidian, skills, claude-code, openclaw, hermes]
-date: 2026-04-21
+date: 2026-04-28
 ---

 ## Source File
- [[raw/Skills/Obsidian 必装 Skills.md]]
+- [[Skills/Obsidian 必装 Skills]]

 ## Summary（用中文描述）
- 核心主题：Obsidian 笔记软件与 AI Agent 集成的必装 Skills 全景图，涵盖网页清洗、笔记操作、图表可视化、学术研究、插件配置五大方向
- 问题域：如何让 AI Agent 高效操作 Obsidian 笔记库，实现知识管理自动化
- 方法/机制：官方 CLI / OpenClaw Skills / 第三方插件，三层技术路径
- 结论/价值：推荐 defuddle / obsidian-cli / obsidian-bases / obsidian-canvas-creator / mermaid-visualizer / excalidraw-diagram / tutor-skills / scholar-skill；obsidian-skill / json-canvas 不推荐
+- 核心主题：Obsidian 生态中值得安装的 AI Agent Skills 全景盘点与配置指南
+- 问题域：如何在 Obsidian 中借助 AI Agent 实现知识管理自动化、内容创作加速
+- 方法/机制：通过 Skill 分类推荐（官方/第三方）、插件安装方案、依赖配置与使用示例
+- 结论/价值：为 Obsidian 用户提供完整的 AI Skills 选型地图，按推荐度标注，节省探索时间

 ## Key Claims（用中文描述）
- defuddle 能将杂乱网页转换为纯净 Markdown，大幅减少 AI Token 消耗，且支持 YouTube 字幕获取
- obsidian-cli 让 AI Agent 直接调用 Obsidian 官方 CLI，实现笔记的增删改查，需 Obsidian 1.12+ 并开启 CLI 开关
- obsidian-bases 通过 .base 文件创建动态数据库视图，支持公式系统和 Frontmatter 属性过滤
- obsidian-canvas-creator 内置径向布局算法，自动计算节点坐标并处理连线，比 json-canvas 更智能
- tutor-skills 实现"输入-内化-检测"完整闭环，tutor-setup 解析文档/代码库生成 StudyVault，tutor 生成互动式测验
- scholar-skill 通过 L1/L2/L3 分级阅读策略深度解构论文，支持长达 2.5 小时的异步挂机任务
- claudian 和 obsidian-agent-client 是 Obsidian 第三方插件，分别适配 Claude Code 和多 Agent（Claude Code / Codex / Gemini CLI / OpenCode / Qwen Code）
+- Obsidian CEO @kepano 官方发布的 defuddle（网页清洗）、obsidian-cli（CLI 操作）、obsidian-bases（数据库视图）、obsidian-markdown（规范写作）四个 Skills 中，前三者推荐安装
+- obsidian-cli 是让 AI Agent 直接调用 Obsidian 官方 CLI 的核心技能，可实现笔记增删改查、日记自动生成
+- Axton 的 obsidian-canvas-creator 通过径向/自由布局算法解决节点重叠问题，优于官方 json-canvas skill
+- tutor-skills 通过"输入-内化-检测"闭环将文档/代码库转化为结构化学习金库（StudyVault）
+- scholar-skill 通过 L1/L2/L3 分级阅读策略将论文转化为双链笔记，适合学术研究场景
+- claudian 和 obsidian-agent-client 是让主流 AI Agent（Claude Code、Codex、OpenCode 等）接入 Obsidian 的关键插件

 ## Key Quotes
-> "defuddle 主要用来抓取网页里的核心正文。它会自动删掉导航条、侧边栏和广告等干扰元素，只留下干净的 Markdown 内容。" — 核心功能描述
-> "scholar-skill 是一个深度的个人知识管理与文献解构工作流。它通过分级标准（L1 分发/L2 标准阅读/L3 深度解构），将原始论文转化为 Obsidian 中的双链卡片、MOC 以及系统性的反思报告。" — 学术研究工作流描述
-> "tutor-skills 构成了一个'输入-内化-检测'的完整闭环：将文档或代码库一键转化为结构化的 Obsidian 知识库，之后通过无提示的交互式测验不断暴露出你的知识盲区并记录学习轨迹。" — 学习闭环描述
+> "defuddle 主要用来抓取网页里的核心正文。它会自动删掉导航条、侧边栏和广告等干扰元素，只留下干净的 Markdown 内容。" — defuddle 功能说明
+> "obsidian-cli 让 AI Agent 能够直接调用 Obsidian 官方的命令行工具，从而实现对笔记、任务、属性的增删改查。" — obsidian-cli 功能说明
+> "tutor-skills 构成了一个'输入-内化-检测'的完整闭环：将文档或代码库一键转化为结构化的 Obsidian 知识库，之后通过无提示的交互式测验不断暴露出你的知识盲区并记录学习轨迹。" — tutor-skills 功能说明
+> "scholar-skill 通过分级标准（L1分发/L2标准阅读/L3深度解构），将原始论文转化为 Obsidian 中的双链卡片、MOC及系统性反思报告。" — scholar-skill 功能说明

 ## Key Concepts
- [[Obsidian-Skill]]：让 AI Agent 能够创建、编辑和管理 Obsidian 笔记的 Skill 体系
- [[Defuddle]]：网页内容清洗工具，将杂乱的 HTML 转换为干净的 Markdown
- [[Obsidian-CLI]]：Obsidian 官方命令行接口，允许 AI 增删改查笔记
- [[Obsidian-Bases]]：通过 .base 文件创建 Obsidian 动态数据库视图的 Skill
- [[Canvas]]：Obsidian 的 JSON 格式白板文件，用于可视化节点布局
- [[Mermaid]]：文本转图表的标记语言，Obsidian 内置渲染支持
- [[Excalidraw]]：手绘风格图表工具，Obsidian Excalidraw 插件提供集成
- [[StudyVault]]：结构化 Obsidian 学习知识库，包含双链、MOC 和复习题
- [[Scholar-Skill]]：学术论文分级阅读与知识内化工作流（L1/L2/L3）
- [[Claudian]]：Obsidian 第三方插件，适配 Claude Code Agent
- [[Obsidian-Agent-Client]]：Obsidian 第三方插件，支持多 Agent 集成
+- [[defuddle]]：网页内容清洗工具，剔除广告和导航栏，保留纯净 Markdown，降低 AI 处理时的 Token 消耗
+- [[obsidian-cli]]：Obsidian 官方命令行工具的 AI Agent 调用接口，支持笔记 CRUD 和日记生成
+- [[obsidian-bases]]：通过 .base 文件创建类似 Notion 数据库的动态视图，支持公式和条件过滤
+- [[obsidian-canvas-creator]]：加强版 Canvas skill，内置径向布局和自由排版算法，自动计算节点坐标避免重叠
+- [[tutor-skills]]："输入-内化-检测"三阶段学习闭环工具，含 tutor-setup（构建 StudyVault）和 tutor（互动复习）
+- [[scholar-skill]]：基于 OpenClaw 框架的学术论文分级阅读工作流（L1/L2/L3）
+- [[claudian]]：适配 Claude Code 的 Obsidian 第三方插件，支持自定义 AI 模型（如 GLM/DeepSeek）
+- [[obsidian-agent-client]]：适配多主流 Agent（Claude Code、Codex、OpenCode、Qwen Code）的 Obsidian 插件

 ## Key Entities
- [[kepano]]：Obsidian CEO，发布了 defuddle / obsidian-cli / obsidian-bases / obsidian-markdown / json-canvas 等 Skills
- [[Axton]]（@回到Axton）：博主，发布了 obsidian-canvas-creator / mermaid-visualizer / excalidraw-diagram Skills
- [[OpenClaw]]：开源 AI Agent 框架，支持 Obsidian Skill 集成
- [[BRAT]]：Obsidian Beta 插件管理工具，用于安装未上架市场的第三方插件
- [[ClawHub]]（clawhub.ai）：OpenClaw Skill 市场
- [[YishenTu]]：Claudian 插件作者，GitHub: `YishenTu/claudian`
- [[RAIT-09]]：obsidian-agent-client 插件作者，GitHub: `RAIT-09/obsidian-agent-client`
- [[Choi Wontak]]：tutor-skills 作者，GitHub: `RoundTable02/tutor-skills`
- [[EESJGong]]：scholar-skill 作者，GitHub: `EESJGong/scholar-skill`
+- [[kepano]]（Obsidian CEO）：官方 Skills 仓库 kepano/obsidian-skills 的维护者，发布 defuddle、obsidian-cli、obsidian-bases 等核心工具
+- [[Axton]]（回到Axton博主）：obsidian-canvas-creator 和 mermaid-visualizer 等可视化 Skills 的作者
+- [[OpenClaw]]：Agent 框架，scholar-skill 基于其构建，支持 MCP 工具集成
+- [[BRAT]]：Obsidian 第三方插件管理器，支持 Beta 插件自动更新，是安装 claudian 的推荐方式
+- [[ClawHub]]：OpenClaw 的 Skill 市场，托管第三方 Obsidian Skills

 ## Connections
- [[obsidian-高效指南]] ← related_to ← [[obsidian-必装-skills]]（Obsidian 插件配置相关）
- [[obsidian-最有必要安装的10款插件]] ← related_to ← [[obsidian-必装-skills]]（Obsidian 插件生态）
- [[养虾日记3]] ← depends_on ← [[obsidian-必装-skills]]（持久化笔记系统的插件依赖）
- [[claude-code调用方法总结]] ← related_to ← [[obsidian-必装-skills]]（Claude Code 与 Obsidian 集成）
- [[Second Brain]] ← related_to ← [[obsidian-必装-skills]]（Obsidian 作为 Second Brain 工具）
- [[Quartz]] ← extends ← [[obsidian-必装-skills]]（Obsidian → Quartz 发布链条）
+- [[obsidian-cli]] ← 依赖 ← [[kepano]]
+- [[defuddle]] ← 依赖 ← [[kepano]]
+- [[obsidian-bases]] ← 依赖 ← [[kepano]]
+- [[obsidian-canvas-creator]] ← 基于 ← [[json-canvas]]（改进）
+- [[tutor-skills]] ← 依赖 ← [[OpenClaw]]
+- [[scholar-skill]] ← 依赖 ← [[OpenClaw]]
+- [[claudian]] ← 安装方式 ← [[BRAT]]
+- [[obsidian-agent-client]] ← 安装方式 ← [[BRAT]]
+- [[obsidian-高效指南-我常用的插件与实用技巧]] ← 相关 ← [[claudian]]（同一插件不同场景）
+- [[dataview-让我从笔记黑洞里逃出来的-obsidian-神器-1]] ← 相关 ← [[obsidian-bases]]（同类数据库视图工具）
+- [[obsidian-tasks-插件-这可能是最适合懒人的任务管理方式]] ← 相关 ← [[obsidian-cli]]（任务管理能力）

 ## Contradictions
- 无明显内容冲突。该文档与 wiki 中已有 Obsidian 相关文档（obsidian-高效指南、obsidian-最有必要安装的10款插件、dataview神器）从不同角度（Skills 生态 vs 插件推荐 vs 笔记方法）覆盖 Obsidian，形成互补而非冲突。
+- 与 [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]] 的 obsidian-skill 方案冲突：
+  - 冲突点：obsidian-skill（OpenClaw 官方）通过文件系统直接读写 .md 文件，与 obsidian-cli（官方 CLI）方案的选择
+  - 当前观点：推荐使用 obsidian-cli（官方 API，更稳定），obsidian-skill 过时且 Token 消耗大
+  - 对方观点：obsidian-skill 不依赖 Obsidian 客户端运行状态，文件系统直写更灵活（尤其在 iCloud 同步场景）
--- a/wiki/sources/scrapy-playwright-抓取tiktok-shop-data.md
+++ b/wiki/sources/scrapy-playwright-抓取tiktok-shop-data.md
@@ -1,49 +1,50 @@
 ---
 title: "Scrapy + Playwright 抓取TikTok Shop Data"
 type: source
-tags: [playwright, scrapy, tiktok-shop, python, docker, 爬虫]
-date: 2026-04-24
+tags: [playwright, scrapy, tiktok-shop, python, docker]
+date: 2026-04-28
 ---

 ## Source File
 - [[raw/跨境电商/Scrapy + Playwright 抓取TikTok Shop Data.md]]

 ## Summary（用中文描述）
- 核心主题：使用 Scrapy + Playwright 技术栈抓取 TikTok Shop 商家数据的环境配置与运行指南
- 问题域：TikTok Shop 跨境电商数据采集的工程实现
- 方法/机制：通过 Python venv 虚拟环境隔离依赖，使用 scrapy-playwright 集成包驱动 Chromium 浏览器执行动态页面渲染，再通过 Docker 容器化部署
- 结论/价值：提供了完整的开发环境搭建流程和生产级 Docker 部署配置，是跨境电商数据采集项目的技术基座
+- 核心主题：使用 Scrapy + Playwright 抓取 TikTok Shop 店铺数据的技术配置与实践指南
+- 问题域：TikTok Shop 跨境电商数据采集的 Python 环境搭建与依赖安装
+- 方法/机制：
+  - 创建 Python 虚拟环境（venv）并激活
+  - 在虚拟环境中安装 `scrapy` 和 `scrapy-playwright`
+  - 安装 Playwright Chromium 浏览器
+  - 通过 `scrapy runspider` 命令行运行爬虫并传入店铺 URL 参数
+  - Docker 环境下需在 Dockerfile 中预配置 Python 虚拟环境路径
+  - 验证 Playwright 安装成功的测试脚本
+- 结论/价值：提供了完整的开发环境配置流程，覆盖本地开发和 Docker 容器两种部署场景

 ## Key Claims（用中文描述）
- **虚拟环境隔离是首选方案**：通过 `python3 -m venv` 创建独立虚拟环境，安装 Scrapy + scrapy-playwright 依赖，相比 Docker 直接安装更适合开发调试
- **Playwright Chromium 是渲染引擎**：通过 `playwright install chromium` 安装无头浏览器，负责处理 TikTok Shop 的 JavaScript 动态加载内容
- **Docker 部署需配置 venv 环境变量**：在 Dockerfile 中添加 `RUN python3 -m venv /app/venv ENV PATH="/app/venv/bin:$PATH"`，使容器内 Python 命令使用虚拟环境
- **可用命令行参数指定目标店铺**：通过 `scrapy runspider tiktok_shop_spider.py -a shop_url="..."` 传递 TikTok Shop 店铺 URL 参数
+- scrapy-playwright 插件可实现 Scrapy 爬虫与 Playwright 浏览器自动化协同工作
+- 在 Docker 容器中运行需要通过 Dockerfile 预先配置 Python venv 环境变量
+- Playwright Chromium 是驱动动态页面渲染的核心依赖
+- `python -c "from playwright.sync_api import sync_playwright; print('Playwright OK')"` 可验证安装成功

 ## Key Quotes
-> "最推荐：创建虚拟环境 (venv) 并安装 Scrapy + Playwright" — 文档作者推荐的最佳实践方案
-
-> "source venv/bin/activate" — venv 激活命令
-
-> "RUN python3 -m venv /app/venv ENV PATH=\"/app/venv/bin:$PATH\"" — Docker 中配置 Python venv 的标准写法
-
-> "python -c \"from playwright.sync_api import sync_playwright; print('Playwright OK')\"" — Playwright 验证命令
+> "pip install scrapy scrapy-playwright" — 核心依赖安装命令
+> "scrapy runspider tiktok_shop_spider.py -a shop_url=\"https://www.tiktok.com/shop/store/xxxx/xxxxxxxxxxxx\"" — 爬虫运行命令示例
+> "RUN python3 -m venv /app/venv && ENV PATH=\"/app/venv/bin:$PATH\"" — Docker 虚拟环境配置

 ## Key Concepts
- [[Scrapy]]：Python 爬虫框架，负责请求调度、数据解析和管道存储
- [[Playwright]]：Microsoft 开发的无头浏览器自动化工具，支持 Chromium/Firefox/WebKit 多引擎，用于渲染 JavaScript 动态页面
- [[scrapy-playwright]]：连接 Scrapy 与 Playwright 的集成包，使 Scrapy Spider 能够执行浏览器自动化操作
- [[venv]]：Python 内置虚拟环境工具，用于隔离项目依赖，避免版本冲突
- [[Docker]]：容器化平台，用于生产环境部署
- [[Chromium]]：Google 浏览器引擎，Playwright 的默认渲染引擎
+- [[WebScraping]]：通过 Scrapy + Playwright 组合实现 TikTok Shop 动态网页数据抓取
+- [[BrowserAutomation]]：Playwright 提供浏览器自动化能力，用于渲染 JavaScript 动态内容
+- [[VirtualEnvironment]]：Python venv 隔离项目依赖，避免包冲突

 ## Key Entities
- [[TikTok Shop]]：字节跳动旗下的电商平台，本文档的数据采集目标
- shenwei：文档作者，提供实际操作笔记
+- [[TikTok Shop]]：数据采集的目标电商平台
+- [[Scrapy]]：Python 爬虫框架，提供网页抓取基础设施
+- [[Playwright]]：微软开源浏览器自动化工具，支持 Chromium/ Firefox/WebKit
+- [[Docker]]：容器化部署平台，文中涉及 Dockerfile 配置

 ## Connections
- [[TikTok Shop Apache Superset Dashboard]] ← uses ← [[Scrapy-Playwright-TikTok-Shop-Data]]
- [[做tk跨境思路不对努力白费]] ← related_to ← [[Scrapy-Playwright-TikTok-Shop-Data]]
+- [[可自动化、可扩展、AI增强的电商数据采集与处理系统]] ← related_to ← [[Scrapy + Playwright 抓取TikTok Shop Data]]
+- [[TikTok Shop - Apache Superset Dashboard设计思路]] ← related_to ← [[Scrapy + Playwright 抓取TikTok Shop Data]]

 ## Contradictions
- 无已知冲突内容
+- 无明显内容冲突
--- a/wiki/sources/tiktok-shop-apache-superset-dashboard设计思路.md
+++ b/wiki/sources/tiktok-shop-apache-superset-dashboard设计思路.md
@@ -1,53 +1,48 @@
 ---
 title: "TikTok Shop - Apache Superset Dashboard设计思路"
 type: source
-tags: ["TikTok电商", "数据可视化", "Apache Superset", "选品分析", "BI仪表盘"]
-date: 2026-04-18
+tags: ["TikTok Shop", "Apache Superset", "跨境电商", "选品分析", "数据可视化"]
+date: 2026-04-28
 ---

 ## Source File
- [[raw/跨境电商/TikTok Shop - Apache Superset Dashboard设计思路.md]]
+- [[跨境电商/TikTok Shop - Apache Superset Dashboard设计思路.md]]

 ## Summary（用中文描述）
- 核心主题：Apache Superset 在 TikTok Shop 电商选品分析场景的完整 Dashboard 设计方案
- 问题域：TikTok Shop 跨境电商卖家如何通过数据可视化系统发现爆品、识别类目机会、监控竞品店铺
- 方法/机制：基于 Scrapy + Playwright 抓取的 TikTok Shop 产品数据（products 表、product_reviews 表、product_variations 表），通过 SQL View 预处理 JSON 字段，设计 4-Tab 专业 Dashboard（爆品雷达 / 类目洞察 / 店铺监控 / 评论分析），结合动态过滤器实现选品决策自动化
- 结论/价值：提供了一套"可长期演进的专业选品分析系统"的完整设计蓝图，从数据准备→指标体系→可视化图表→Dashboard 布局→高阶选品评分 SQL，均有可直接落地的方案
+- 核心主题：使用 Apache Superset 构建 TikTok Shop 电商选品分析 Dashboard 的完整设计指南
+- 问题域：TikTok Shop 跨境电商选品决策支持、竞品监控、价格策略分析
+- 方法/机制：通过 SQL View 预处理数据（JSON 字段提取），设计多 Tab Dashboard（爆品雷达、类目洞察、店铺监控、评论分析），提供 25-30 个图表的详细配置方案及可导入 Superset 的 JSON 模板
+- 结论/价值：提供一套"低价高销量"、"高客单价爆品"、"蓝海类目"的自动化选品评分模型，结合交互过滤器实现动态选品系统

 ## Key Claims（用中文描述）
- Apache Superset 不会自动解析 JSON 字段，必须通过 SQL View 预先提取 rating、rating_count 等数值字段，才能构建 KPI 卡、Heatmap 等图表
- 核心选品目标为"找出热卖产品 + 高评分 + 低竞争 + 高折扣"，Dashboard 应支持动态过滤器实现交互式选品决策
- SQL 选品评分公式：score = sold × 0.4 + rating × 15 + discount_percent × 0.5 + rating_count × 0.2，可根据业务需求自定义权重
- 推荐 4-Tab Dashboard 结构：爆品雷达（KPI总览）→ 类目机会洞察（热力图/箱线图）→ 店铺监控（时序图）→ 评论分析（评分趋势）
+- 通过 `JSON_EXTRACT` 将 `prodct_rating`、`videos` 等 JSON 字段预处理为数值列，Superset 才能直接计算 numeric metrics
+- 选品评分模型 = `sold * 0.4 + rating * 12 + rating_count * 0.2 + discount_percent * 0.5`，权重可自定义
+- 气泡图（X=final_price, Y=sold, Size=rating, Color=category）可一眼识别"低价高销量类"和"高客单价爆品"
+- 类目竞争度分析：`COUNT(*)` 少但 `SUM(sold)` 大的类目 = 典型蓝海类目
+- 竞争对手监控：利用 `timestamp` 字段追踪店铺上新趋势，判断哪家店最近疯狂上新或做活动冲 GMV

 ## Key Quotes
 > "找出热卖产品 + 高评分 + 低竞争 + 高折扣 → 决定选哪些产品卖" — 选品 Dashboard 核心目标
-> "Superset 不会自动解析 JSON，你需要创建 SQL View 预先提取数值字段" — 数据准备关键步骤
-> "这样整个 Dashboard 变成一个动态选品系统" — 动态过滤器的价值定位
+> "Superset 支持将整个 Dashboard 导出成 JSON，Settings → Import Dashboard → 选择 JSON 即可一键导入完整成品 Dashboard" — Superset 可导出/导入机制
+> "创建 `view_products_cleaned` 只需要一次，之后所有图表都基于此 View" — 数据预处理一次性完成原则

 ## Key Concepts
- [[Apache Superset]]：开源 BI 可视化平台，支持 SQL 查询、多样化图表和仪表盘构建，本文档中使用 Docker 容器化部署
- [[KPI Card]]：关键绩效指标卡片，展示总产品数、热卖产品数、平均评分、平均价格等核心数字
- [[选品评分公式]]：加权多维度评分公式，权重可自定义（sold × 0.4 + rating × 15 + discount × 0.5 + rating_count × 0.2）
- [[Scatter Plot]]（散点图）：用于分析销量 vs 价格关系，气泡大小代表评分，颜色代表类目
- [[Box Plot]]（箱线图）：用于分析类目价格带分布，找出"利润空间大但竞争低"的类目
- [[Heatmap]]（热力图）：用于类目评分 vs 销量交叉分析
- [[SQL View]]：在数据库层面预处理 JSON 字段（如 JSON_EXTRACT），使 Superset 能直接计算数值指标
- [[Dynamic Filter]]（动态过滤器）：支持 Category/Store Name/价格范围/时间范围等交互式筛选，使 Dashboard 具备实时分析能力
- [[GMV]]（商品交易总额）：final_price × sold，用于产品排名
+- [[选品评分模型]]：通过加权公式（销量×0.4 + 评分×12 + 评分数量×0.2 + 折扣比例×0.5）对产品进行综合排名，用于自动化推荐值得跟卖的产品
+- [[蓝海类目]]：指产品数量少但总销量大的细分市场，竞争度低但需求旺盛，适合新卖家切入
+- [[价格带分析]]：通过气泡图、箱线图分析不同价格区间与销量的关系，找出最优价格带
+- [[GMV分析]]：`total_gmv = final_price * sold`，用于衡量店铺/产品的整体成交额
+- [[竞品监控]]：通过追踪目标店铺的上新节奏、价格策略变化、评分趋势来进行竞争情报分析

 ## Key Entities
- [[TikTok Shop]]：字节跳动旗下电商平台，本文档数据抓取的目标平台
- [[tiktok_products 数据库]]：包含 products、product_reviews、product_variations 三张核心表的数据库结构
- [[products 表]]：存储产品基础信息（id/title/sold/price/rating/category/store_name/timestamp/position）
- [[product_reviews 表]]：存储用户评论数据（rating/review_date/review_text/product_id）
- [[product_variations 表]]：存储 SKU 层变体数据（sku/stock/final_price/discount_percent）
+- [[TikTok Shop]]：目标电商平台，数据来源；通过爬虫抓取 `tiktok_products` 数据库
+- [[Apache Superset]]：开源 BI 可视化工具，支持 SQL 查询、多图表类型、交互过滤器、Dashboard 导入导出
+- [[tiktok_products]]：存储 TikTok Shop 商品数据的数据库表，包含 products、product_reviews、product_variations 三张核心表

 ## Connections
- [[Scrapy + Playwright 抓取TikTok Shop Data]] ← upstream_data_source ← [[TikTok Shop Apache Superset Dashboard设计思路]]
- [[TikTok PM - Python Django 项目]] ← shares_database_schema ← [[TikTok Shop Apache Superset Dashboard设计思路]]
- [[Apache Superset]] ← tool ← [[TikTok Shop Apache Superset Dashboard设计思路]]
- [[用Docker安装Apache Superset]] ← prerequisite ← [[TikTok Shop Apache Superset Dashboard设计思路]]
+- [[Scrapy + Playwright 抓取TikTok Shop Data]] ← depends_on ← [[TikTok Shop - Apache Superset Dashboard设计思路]]（前者提供数据源，后者消费数据做分析）
+- [[做TK跨境思路不对努力白费]] ← extends ← [[TikTok Shop - Apache Superset Dashboard设计思路]]（前者提供宏观跨境策略，后者提供数据驱动选品工具）
+- [[选品评分模型]] ← part_of ← [[TikTok Shop - Apache Superset Dashboard设计思路]]

 ## Contradictions
- 与 [[电商如何选品-如何找到爆款-选品策略]]：后者侧重选品策略理论（市场调研/竞争对手分析/利润测算），前者侧重数据驱动的可视化执行工具（Apache Superset Dashboard）。两者互补而非冲突——策略指导选品方向，Dashboard 提供实时数据验证。
+- 与 [[Scrapy + Playwright 抓取TikTok Shop Data]] 无冲突：两者互补，前者专注数据采集，后者专注数据可视化分析
+- 与 [[电商如何选品-如何找到爆款选品策略]] 无冲突：本文侧重"如何用 BI 工具落地选品分析"，策略层面一致但工具方法不同
--- a/wiki/sources/tk美国面单授权及操作流程.md
+++ b/wiki/sources/tk美国面单授权及操作流程.md
@@ -1,36 +1,37 @@
 ---
 title: "TK美国面单授权及操作流程"
 type: source
-tags: ["tiktok", "跨境电商", "物流", "面单", "美国"]
+tags: ["TikTok", "跨境电商", "美国面单", "物流授权"]
 date: 2025-12-19
 ---

 ## Source File
- [[raw/跨境电商/TK美国面单授权及操作流程.md]]
+- [[跨境电商/TK美国面单授权及操作流程.md]]

 ## Summary（用中文描述）
- 核心主题：TikTok美国市场面单授权配置与操作流程
- 问题域：跨境电商物流履约中的面单打印与授权管理
- 方法/机制：通过截图教程演示TK美国面单的授权步骤和操作流程
- 结论/价值：帮助跨境卖家完成TikTok美国站的面单系统配置
+- 核心主题：TikTok Shop 美国站点的面单授权配置与操作流程
+- 问题域：跨境电商卖家在 TikTok 美国市场发货所需的物流面单授权环节
+- 方法/机制：通过 6 张截图展示了 TK 美国面单授权的具体操作步骤，包括进入授权界面、填写凭证、确认绑定等流程
+- 结论/价值：帮助跨境卖家快速完成 TikTok 美国站点的物流面单授权，为正式发货做好准备

 ## Key Claims（用中文描述）
- TikTok美国站需要完成面单授权才能进行订单履约
- 面单授权流程包含多个配置步骤（截图展示具体操作界面）
+- TK美国卖家需通过平台授权流程完成面单服务绑定，方可使用平台面单进行发货

 ## Key Quotes
-> 图片教程来源：Zipline图床备份，包含6张操作截图
+> "Image Backups — Backup created at 2025-12-19 14:43" — 记录了6张 TK 美国面单授权操作截图的备份时间与来源

 ## Key Concepts
- [[TikTokShop]]：TikTok电商平台，支持美国市场
- [[面单授权]]：跨境物流系统中打印官方物流面单的必要授权流程
- [[跨境电商物流]]：涉及国际运输、清关、最后一公里配送的电商履约体系
+- [[美国面单]]：跨境电商平台提供的本地化物流面单服务，美国站点特指 USPS 体系下的面单授权与打印
+- [[物流授权]]：卖家在平台侧完成第三方物流服务商账号绑定与授权的流程

 ## Key Entities
- [[TikTok美国站]]：TikTok Shop的美国市场站点，商家在此开展跨境销售
+- [[TikTok Shop]]：字节跳动旗下跨境电商平台，覆盖美国等多个市场
+- [[TikTok 美国站]]：TikTok Shop 的美国市场站点，对卖家有本地化物流要求

 ## Connections
- [[做tk跨境思路不对努力白费]] ← related_to ← [[TK美国面单授权及操作流程]]
+- [[做TK跨境思路不对努力白费]] ← relates_to ← [[TK美国面单授权及操作流程]]
+- [[电商如何选品-如何找到爆款选品策略]] ← relates_to ← [[TK美国面单授权及操作流程]]
+- [[Scrapy + Playwright 抓取TikTok Shop Data]] ← extends ← [[TK美国面单授权及操作流程]]

 ## Contradictions
- 暂无冲突记录
+- 无已知冲突内容
--- a/wiki/sources/做tk跨境思路不对努力白费.md
+++ b/wiki/sources/做tk跨境思路不对努力白费.md
@@ -1,45 +1,49 @@
 ---
 title: "做TK跨境思路不对努力白费"
 type: source
-tags: [tiktok, 跨境电商]
-date: 2026-04-18
+tags: [tiktok, 跨境电商, 选品策略, 市场选择, 短视频营销]
+date: 2026-04-28
 ---

 ## Source File
- [[raw/跨境电商/做TK跨境思路不对努力白费.md]]
+- [[跨境电商/做TK跨境思路不对努力白费.md]]

 ## Summary（用中文描述）
- 核心主题：TikTok 跨境电商全流程实战指南，从市场选择到团队建设的完整攻略
- 问题域：个人或小团队如何从零开始在 TikTok 平台开展跨境电商业务
- 方法/机制：市场选择 → 账号准备 → 选品策略 → 店铺运营 → 流量获取 → 仓储物流 → 团队建设
- 结论/价值：提供了一套完整的 TikTok 跨境电商执行框架，强调"思路正确"是成功的前提
+- 核心主题：TikTok 跨境电商全流程实战指南，从市场选择、账号运营、选品策略到团队建设
+- 问题域：跨境电商入门者或中小卖家如何系统性地在 TikTok 平台开展跨境业务
+- 方法/机制：市场选择优先发达国家→账号运营看直播学习→办理执照合规经营→选品软件数据分析→流量跟踪优化→短视频+达人营销→海外仓储保障物流→团队协作分工明确
+- 结论/价值：形成完整的 TK 跨境电商闭环流程，强调思路（方向选择）比努力更重要

 ## Key Claims（用中文描述）
- 跨境卖家应优先选择发达国家市场（如美区、日本），避免竞争激烈且利润低的东南亚市场
- 选品是跨境电商的核心竞争力，应使用数据软件分析市场环境，确定单一垂直类目
- 店铺运营需要持续监控流量数据，及时下架表现不佳的商品，优化商品列表
- 短视频营销和达人合作是获取流量、提升转化的关键手段
- 随着业务规模扩大，应招聘合适人才分担日常任务，确保业务持续增长
+- 跨境电商用户增长面临三大挑战，需通过正确思路应对而非蛮力
+- 优先选择发达国家市场（美区、日本）而非东南亚，因消费能力强、利润更高
+- 通过 TikTok 账号观看直播了解跨境流程和政策是高效入门路径
+- 选品应使用数据分析软件，聚焦单一类目深耕，而非盲目跟风
+- 持续监控店铺流量和销售数据，及时下架表现不佳商品
+- 短视频营销与达人合作是提升曝光率和转化率的核心手段
+- 海外仓储与海运补货策略可确保持续供应和物流稳定性
+- 团队协作与分工明确是电商业务持续增长的基础

 ## Key Quotes
-> "市场选择：优先考虑发达国家市场，如美区和日本，避免东南亚。" — 强调市场定位的重要性
-> "选品策略：使用数据软件分析市场环境，确保选择适合的单一类目。" — 聚焦垂直领域
-> "团队协作：成功的电商运营需要团队的配合与沟通，分工明确才能高效运作。" — 组织能力
+> "在选品上应考虑到行业的发展趋势与消费者需求，而不是盲目跟风" — 创新思维在选品中的体现
+> "数据分析能有效反映市场变化，帮助做出快速决策" — 数据驱动运营的核心价值
+> "成功的电商运营需要团队的配合与沟通，分工明确才能高效运作" — 团队建设的重要性

 ## Key Concepts
- [[跨境电商]]：通过互联网平台进行跨国商品交易的商业模式
- [[选品策略]]：通过数据分析确定适合目标市场的商品类目
- [[TikTok电商]]：基于 TikTok 平台的短视频+直播带货模式
- [[达人营销]]：与平台 KOL 合作推广商品的营销方式
+- [[市场选择策略]]：优先消费能力强、高利润的发达国家市场，避免竞争激烈且利润低的市场
+- [[选品策略]]：使用数据软件分析市场环境，选择适合的单一类目进行深耕
+- [[流量运营分析]]：持续监控店铺流量，优化商品列表，分析销售数据并调整策略
+- [[短视频营销]]：通过短视频内容和达人合作提升品牌曝光和转化率
+- [[跨境电商闭环]]：从选区、选品到运营、团队建设的完整业务流程

 ## Key Entities
- [[TikTok Shop]]：TikTok 平台的电商功能，支持短视频带货和直播带货
- [[美区]]：美国 TikTok 市场，消费能力强，利润空间大
- [[日本]]：发达国家市场，目标用户购买力强
+- [[TikTok Shop]]：跨境电商核心平台，提供直播带货和短视频营销基础设施
+- [[TikTok]]：字节跳动旗下短视频社交平台，TK 跨境的流量入口

 ## Connections
- [[电商如何选品-如何找到爆款-选品策略]] ← related_to ← [[做tk跨境思路不对努力白费]]
- [[可自动化-可扩展-ai增强的电商数据采集与处理系统]] ← related_to ← [[做tk跨境思路不对努力白费]]
+- [[电商如何选品-如何找到爆款选品策略]] ← related_to ← [[做TK跨境思路不对努力白费]]（均为电商选品主题）
+- [[TK美国面单授权及操作流程]] ← depends_on ← [[做TK跨境思路不对努力白费]]（先有运营思路，再完成面单授权操作）
+- [[电商视频Prompt库]] ← supports ← [[做TK跨境思路不对努力白费]]（短视频内容生产依赖 Prompt 库）

 ## Contradictions
- 暂无已知冲突内容
+- 与现有 Wiki 页面暂无明显内容冲突
--- a/wiki/sources/可自动化-可扩展-ai增强的电商数据采集与处理系统.md
+++ b/wiki/sources/可自动化-可扩展-ai增强的电商数据采集与处理系统.md
@@ -1,70 +1,53 @@
---
-title: "可自动化、可扩展、AI增强的电商数据采集与处理系统"
-type: source
-tags: []
-date: 2025-11-11
---
-
-## Source File
- [[raw/Others/可自动化、可扩展、AI增强的电商数据采集与处理系统.md]]
-
-## Summary（用中文描述）
- 核心主题：基于 Docker + Ubuntu + n8n 构建可自动化、可扩展、AI增强的电商数据采集与处理系统
- 问题域：电商数据爬取效率低、AI处理缺失、缺乏自动化管线
- 方法/机制：三层架构（爬虫层→AI处理层→存储展示层）；Scrapy+Playwright组合抓取动态页面；n8n工作流编排自动化；Docker Compose容器化部署
- 结论/价值：提供完整的开源技术栈方案，实现从爬取到AI分析的全链路自动化
-
-## Key Claims（用中文描述）
- Scrapy 负责结构化抓取、分页调度、媒体下载；Playwright 负责加载动态页面；两者通过 Docker Compose 容器化，输出 JSON/CSV 供 n8n 消费
- n8n 工作流可实现定时启动爬虫→读取JSON→调用LLM提取属性→写入数据库→生成报表通知的全链路自动化
- AI 处理任务包括：内容摘要分类、多语言翻译、特征提取（品牌/价格/类别）、异常检测（异常价格/缺图产品）、结构化JSON输出
- 本地可使用 Ollama（Mistral/Llama3）通过 HTTP Request 调用本地 API，无需外部 API Key
- 防封策略：User-Agent轮换、代理池（BrightData/ScraperAPI）、下载延迟+随机化访问、分布式调度（Scrapyd/Scrapy集群）
-
-## Key Quotes
-> "Scrapy + Playwright（或 Crawlee + Playwright）" — 推荐爬虫工具组合
-> "在 n8n 中可以通过 workflow 实现整个管线自动化" — n8n 自动化核心理念
-> "可以本地使用 Ollama (Mistral, Llama3) 模型，通过 n8n 的 HTTP Request 调用本地 http://localhost:11434/api/generate" — 本地AI处理方案
-
-## Key Concepts
- [[Scrapy]]：Python 爬虫框架，擅长结构化抓取、分页调度和媒体下载
- [[Playwright]]：浏览器自动化工具，支持 JS 渲染页面和无头模式
- [[scrapy-playwright]]：让 Scrapy 调用 Playwright 渲染动态页面的插件
- [[n8n]]：开源工作流自动化平台，支持 Trigger/Action/AI 节点编排
- [[Docker Compose]]：容器化编排工具，定义和运行多容器应用
- [[Ollama]]：本地 LLM 运行框架，支持 Mistral/Llama3 等模型
- [[LangChain]]：结合 Vector DB（Qdrant/Milvus）存储产品语义信息
- [[Bright Data]]：商业代理池服务，用于爬虫防封
- [[Scrapyd]]：Scrapy 分布式部署集群管理工具
- [[MinIO]]：S3 兼容对象存储，用于存储图片和视频
- [[Grafana]]：可视化平台，生成电商趋势与分析报表
- [[Metabase]]：开源 BI 工具，连接数据库生成分析报表
- [[FastAPI]]：Python Web 框架，用于暴露 REST API 给前端或 BI 工具
-
-## Key Entities
- [[Amazon]]：电商平台示例，Scrapy 爬虫的目标站点
- [[JD]]（京东）：电商平台示例
- [[Taobao]]（淘宝）：电商平台示例
- [[Shopee]]：电商平台示例，提供公开 API
- [[Scrapy]] 社区：开源爬虫框架生态
-
-## Connections
- [[Scrapy]] ← 核心爬虫 ← [[scrapy-playwright]]
- [[scrapy-playwright]] ← 集成 → [[Playwright]]
- [[n8n]] ← 编排自动化 ← [[Docker Compose]]
- [[Docker Compose]] ← 容器化 ← [[Scrapy]] + [[Playwright]]
- [[Ollama]] ← 本地 LLM ← [[n8n HTTP Request Node]]
- [[Bright Data]] ← 代理池 ← 防封策略
- [[Metabase]] ← 数据可视化 ← PostgreSQL/SQLite
- [[MinIO]] ← 对象存储 ← 图片/视频存储
-
-## Contradictions
- 无已知冲突内容
-
-## 起步路径
-1. 在 Ubuntu 上安装 Docker + Docker Compose
-2. 启动基础环境：scrapy + playwright + n8n
-3. 选择 1–2 个电商站点（Amazon / JD / Taobao）
-4. 构建 Scrapy 爬虫模板
-5. 用 n8n 处理数据并测试 AI 工作流
-6. 逐步扩展至全自动管线
+---
+title: "可自动化、可扩展、AI增强的电商数据采集与处理系统"
+type: source
+tags: []
+date: 2025-11-11
+---
+
+## Source File
+- [[raw/Others/可自动化、可扩展、AI增强的电商数据采集与处理系统.md]]
+
+## Summary（用中文描述）
+- 核心主题：基于 Docker + Ubuntu + n8n 构建可自动化、可扩展、AI增强的电商数据采集与处理系统
+- 问题域：电商平台产品信息采集、清洗、AI处理、存储与可视化
+- 方法/机制：三层架构（采集层→处理层→存储层），Scrapy + Playwright 组合抓取，n8n 自动化工作流编排，LLM API 进行内容摘要/分类/翻译/特征提取
+- 结论/价值：提供完整开源技术栈的电商数据采集方案，支持容器化部署和 AI 增强处理
+
+## Key Claims（用中文描述）
+- Scrapy + Playwright 组合是电商爬虫的最佳实践（Scrapy 负责结构化抓取，Playwright 处理动态页面）
+- n8n 可通过工作流实现整个数据管线自动化（定时触发→执行爬虫→读取JSON→调用AI→存入数据库）
+- Ollama 本地部署可替代外部 OpenAI API，降低成本并保护数据隐私
+
+## Key Quotes
+> "Scrapy + Playwright（或Crawlee + Playwright）" — 推荐爬虫技术组合，Scrapy 负责结构化抓取、分页调度、媒体下载；Playwright 负责加载动态页面
+> "用 n8n 的 HTTP Request 调用本地 http://localhost:11434/api/generate" — 本地 Ollama 调用方式
+> "使用 User-Agent轮换、代理池、下载延迟 + 随机化访问" — 防封策略核心三要素
+
+## Key Concepts
+- [[网页爬虫]]：自动化抓取网页数据的程序或脚本
+- [[自动化工作流引擎]]：通过可视化编排实现业务流程自动化的平台
+- [[防封技术]]：防止爬虫被目标网站封禁的技术手段（UA轮换、代理池、延迟访问）
+- [[Docker容器化]]：使用 Docker 将爬虫和服务打包部署的技术
+- [[LLM API集成]]：调用大语言模型进行内容处理（摘要、分类、翻译）
+- [[向量数据库]]：存储语义信息用于 AI 检索（Qdrant、Milvus）
+
+## Key Entities
+- [[Scrapy]]：Python 爬虫框架，适合结构化数据抓取和分布式部署
+- [[Playwright]]：微软开源的浏览器自动化工具，支持动态页面渲染
+- [[n8n]]：开源工作流自动化平台，支持 API 集成和定时任务
+- [[Ollama]]：本地 LLM 运行时，支持 Mistral、Llama3 等模型
+- [[Docker Compose]]：Docker 容器编排工具，用于多服务协同部署
+- [[PostgreSQL]]：开源关系型数据库，适合结构化数据存储
+- [[MinIO]]：S3 兼容的对象存储，用于图片和视频存储
+- [[Grafana]]：开源数据可视化平台，用于监控仪表盘
+
+## Connections
+- [[Scrapy]] ← 依赖 → [[Playwright]]
+- [[n8n]] ← 消费数据 → [[Scrapy]]
+- [[n8n]] ← 调用 → [[Ollama]]
+- [[Scrapy]] ← 写入 → [[PostgreSQL]]
+
+## Contradictions
+- 暂无内容冲突
+
--- a/wiki/sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md
+++ b/wiki/sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md
@@ -1,53 +1,52 @@
 ---
-title: "在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B"
+title: 在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B
 type: source
-tags: [ollama, qwen, qwen-coder, ubuntu, 本地大模型]
-date: 2026-04-18
+tags: [ollama, qwen, qwen-coder, ubuntu, 本地大模型, ai-coding]
+date: 2026-04-28
 ---

 ## Source File
- [[raw/AI/在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B.md]]
+- [[AI/在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B]]

 ## Summary（用中文描述）
- 核心主题：在 Ubuntu 系统上通过官方安装脚本部署 Ollama 本地大模型运行框架，并下载运行 Qwen2.5-Coder 7B 代码生成模型
- 问题域：本地 AI 推理环境搭建、大模型私有部署、本地 API 服务暴露
- 方法/机制：通过官方 install.sh 脚本一键安装 Ollama；使用 systemd 管理服务；通过 `OLLAMA_HOST=0.0.0.0` 开放远程 API；CUDA 自动 GPU 加速
- 结论/价值：3 条命令完成安装部署；Qwen2.5-Coder 7B 因其 Tool usage 能力强、Shell/Python/SQL 理解强、Repo 级代码理解强，比普通 qwen2.5:7b 更适合工程任务
+- 核心主题：在 Ubuntu 系统上通过 Ollama 本地部署 Qwen2.5-Coder 7B 代码大模型，并支持 REST API 和多语言 SDK 调用
+- 问题域：本地 AI 推理环境搭建、代码助手部署
+- 方法/机制：Ollama 作为本地大模型运行时，通过 systemd 服务管理，支持 GPU 加速，提供 REST API 和 Python/NodeJS SDK
+- 结论/价值：3 条命令完成安装部署，适合开发者本地 AI Coding 基础设施搭建

 ## Key Claims（用中文描述）
 - Ollama 官方安装脚本自动完成 CLI 安装、systemd 服务创建和 API 启动
- qwen2.5-coder:7b 模型大小约 4.5GB，推荐配置为 8+ CPU cores + 16GB RAM + NVIDIA GPU
- 默认 Ollama API 仅监听 127.0.0.1（本地），需修改 systemd 服务配置 `OLLAMA_HOST=0.0.0.0` 才能开放远程访问
- 若系统安装了 CUDA，Ollama 会自动使用 GPU 加速，无需额外配置
- 小型机器可选择 qwen2.5-coder:3b 替代 7B 以降低资源需求
- 推荐搭配工具：Open WebUI（ChatGPT UI）、n8n（AI 自动化）、LangChain（Agent framework）、OpenClaw（AI coding agent）
+- qwen2.5-coder:7b 模型约 4.5GB，最低 8GB RAM 推荐 16GB，无需 GPU 也可运行
+- Ollama 默认仅监听 127.0.0.1，通过 OLLAMA_HOST=0.0.0.0 环境变量开放远程 API 访问
+- 安装 CUDA 后 Ollama 自动使用 NVIDIA GPU 加速，无需额外配置
+- qwen2.5-coder:7b 在 Tool usage、Shell/Python/SQL 理解和 Repo 级代码理解方面优于普通 qwen2.5:7b

 ## Key Quotes
-> "qwen2.5-coder:7b 因为 Tool usage 能力强、Shell / Python / SQL 理解强、Repo 级代码理解强，比普通 qwen2.5:7b **更适合工程任务**" — 选型建议
-
-> "如果安装了 CUDA，Ollama 会 **自动使用 GPU**，无需额外配置" — GPU 加速机制
-
-> "最简安装流程：curl -fsSL https://ollama.com/install.sh | sh && ollama pull qwen2.5-coder:7b && ollama run qwen2.5-coder:7b" — 3 条命令完成部署
+> "qwen2.5-coder:7b" — 模型推荐，适用于 DevOps automation、SQL Agent、Kubernetes troubleshooting、n8n workflow AI
+> "curl -fsSL https://ollama.com/install.sh | sh" — 最简安装命令，一条命令完成 Ollama 安装
+> "Ollama 默认提供 REST API: http://localhost:11434" — API 端点说明

 ## Key Concepts
- [[Ollama]]：开源本地 LLM 运行框架，支持 macOS/Windows/Linux/Docker，`ollama run <model>` 一键运行大语言模型
- [[Qwen2.5-Coder]]：阿里通义千问团队开发的代码生成模型，7B 版本约 4.5GB，在 Tool usage、Shell/Python/SQL 理解和 Repo 级代码理解方面优于通用版 Qwen2.5
- [[本地大模型部署]]：在自有硬件上运行 AI 模型，数据完全私有、无需 API Key、无网络依赖
- [[GPU 加速推理]]：Ollama 自动检测 CUDA 环境并调用 NVIDIA GPU 加速推理，无需手动配置
- [[REST API]]：Ollama 默认提供 localhost:11434 REST API 接口，支持 JSON 格式的对话请求
+- [[Ollama]]：本地大模型运行时，通过单一命令安装，支持 systemd 管理，提供 REST API 和多语言 SDK
+- [[Qwen2.5-Coder]]：通义千问代码大模型系列，7B 参数规模约 4.5GB，擅长 Tool usage、代码理解和生成
+- [[本地大模型部署]]：在本地机器而非云端运行 LLM，适合隐私敏感和离线场景
+- [[GPU 加速]]：通过 NVIDIA CUDA 自动加速 Ollama 推理性能
+- [[REST API]]：Ollama 提供的 HTTP API，可被 n8n、WebUI、Agent 等外部工具调用

 ## Key Entities
- [[Open WebUI]]：开源大模型 Web 界面，支持 Ollama/OpenAI API 接入，可配置 RAG 本地知识库和联网搜索
- [[n8n]]：开源工作流自动化平台，可通过 Webhook 与本地 Ollama API 集成实现 AI 驱动的自动化工作流
- [[OpenClaw]]：AI coding agent，支持配置 `ollama/qwen2.5-coder:7b` 作为后端模型
- [[LangChain]]：Agent framework，可与本地 Ollama API 集成构建复杂 AI 应用
+- [[Ollama]]：Ollama 公司开发的本地 LLM 运行时工具，安装地址 ollama.com
+- [[Qwen2.5-Coder]]：阿里云通义千问团队开发的代码专用大模型
+- [[Open WebUI]]：开源的 ChatGPT 风格 Web 界面，可搭配 Ollama 使用
+- [[n8n]]：开源工作流自动化平台，可通过 API 调用 Ollama 实现 AI 自动化
+- [[LangChain]]：Agent 开发框架，可集成 Ollama 作为 LLM 后端
+- [[OpenClaw]]：AI Coding Agent，可配置使用 ollama/qwen2.5-coder:7b 作为后端

 ## Connections
- [[Ollama]] ← 基础平台 ← [[详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1]]
- [[Open WebUI]] ← 依赖 ← [[Ollama]]
- [[n8n]] ← 可调用 ← [[Ollama API]]
- [[OpenClaw]] ← 可配置 ← [[Qwen2.5-Coder]]
- [[Qwen2.5-Coder]] ← 特定版本 ← [[Ollama]]
+- [[Ollama]] ← runs ← [[Qwen2.5-Coder]]
+- [[Open WebUI]] ← connects_to ← [[Ollama]] API
+- [[n8n]] ← calls ← [[Ollama]] REST API
+- [[LangChain]] ← uses ← [[Ollama]] as LLM backend
+- [[OpenClaw]] ← configured_with ← [[Qwen2.5-Coder]]

 ## Contradictions
- 暂无冲突内容
+- 暂无发现与其他 Wiki 页面的冲突内容。
--- a/wiki/sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md
+++ b/wiki/sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md
@@ -1,43 +1,51 @@
---
-title: "我做了个 Skill：让 AI 帮你生成 Logo 和图标"
-type: source
-tags: []
-date: 2026-04-23
---
-
-## Source File
- [[raw/Skills/我做了个 Skill：让 AI 帮你生成 Logo 和图标.md]]
-
-## Summary（用中文描述）
- 核心主题：介绍一个名为 baoyu-imagine 的 Claude Code Skill，用于通过 AI 生成 Logo 和图标设计
- 问题域：设计师和创作者需要快速生成 Logo、图标、吉祥物等品牌视觉资产，传统的 AI 生图工具缺乏针对 Logo 场景的专业提示词优化
- 方法/机制：baoyu-imagine 通过 npm 安装（`npx baoyu-imagine`），提供 Logo 专用的提示词构建策略，支持风格关键词（扁平化/渐变/几何/手绘等）、颜色规范、格式要求（SVG/PNG）等多种参数配置，生成后自动保存到本地目录
- 结论/价值：让非设计师也能快速产出专业级品牌视觉资产，降低品牌创建的门槛和成本
-
-## Key Claims（用中文描述）
- baoyu-imagine Skill 通过结构化提示词策略，可生成扁平化、几何、手绘、渐变等多种风格的专业 Logo
- 安装方式为 `npx baoyu-imagine`，无需手动配置环境，Claude Code 中直接调用
- 支持导出 SVG（矢量格式，适合缩放）和 PNG（位图格式，适合直接使用）两种格式
- 生成的 Logo 可通过描述品牌名称、行业属性、风格偏好等信息定制化生成
-
-## Key Quotes
-> "用 AI 做 Logo / 图标" — baoyu-imagine 的核心定位
-
-## Key Concepts
- [[baoyu-imagine]]：Claude Code Skill，通过结构化提示词策略驱动 AI 生图工具生成专业 Logo 和图标
- [[Claude-Code-Skill]]：Claude Code 的可复用提示词模板扩展，以 .skill 文件形式封装专业领域的工作流和提示词规范
- [[AI-Logo-Generation]]：使用人工智能工具自动生成品牌标识、图标、吉祥物等视觉资产的设计方式
-
-## Key Entities
- [[baoyu]]：baoyu-imagine Skill 的作者/发布者，专注于 AI 图像生成工具链的开发者
-
-## Connections
- [[Claude-Code]] ← uses ← [[baoyu-imagine]]
- [[AI-Logo-Generation]] ← enables ← [[品牌视觉资产创建]]
- [[prompt-engineering]] ← applied_in ← [[baoyu-imagine]]
-
-## Contradictions
- 与通用 AI 生图工具（如 Midjourney）相比：
-  - 冲突点：通用工具的 Logo 生成质量不稳定，需要大量迭代
-  - 当前观点：baoyu-imagine 通过 Logo 专用提示词策略提升生成质量
-  - 对方观点：通用工具覆盖范围更广，但 Logo 场景专业化程度不足
+---
+title: "我做了个 Skill：让 AI 帮你生成 Logo 和图标"
+type: source
+tags: []
+sources: []
+last_updated: 2026-04-28
+---
+
+## Source File
+- [[Skills/我做了个 Skill：让 AI 帮你生成 Logo 和图标]]
+
+## Summary（用中文描述）
+- 核心主题：开源 Logo Generator Skill——用 AI 生成 SVG Logo + 高级展示图的完整工作流
+- 问题域：开发者/独立创作者快速获取专业品牌视觉资产
+- 方法/机制：AI 生成可编辑 SVG 基础 → AI 生成高级展示图，两步工作流替代图片模型直出
+- 结论/价值：降低设计门槛，让每个人都能快速获得"够用的好 Logo"，定位是"快速可用"而非"替代设计师"
+
+## Key Claims（用中文描述）
+- AI 生成 SVG Logo 优于直接用图片模型生成 Logo：SVG 可编辑、可导入 Figma 精修、可做动效、矢量无损
+- Logo Generator Skill 三步工作流（信息收集→6+ 设计变体→高级展示图）可让无设计背景的人快速获得专业视觉资产
+- 12 种专业背景风格（暗色 6 种 + 亮色 6 种）适配不同产品类型
+- WebGL 动态背景（6 种）适合官网首页和交互场景
+- 最终交付物：SVG 文件 + 多尺寸 PNG 导出 + 展示图 + 交互式网页
+
+## Key Quotes
+> "Gemini 真是做设计的一把好手，尤其是用 SVG 画 logo 只要给一些适当的引导就可以画的很好" — @op7418
+> "好的设计来自理解，而不是随机生成" — Skill 核心原则
+> "AI 生成基础，人工精修细节" — 核心工作流理念
+> "工具应该是开放的，让更多人能用上 AI 的设计能力" — 开源理念
+> "Canva 没有替代设计师，而是让更多人能做出'够用的海报'一样" — Skill 的定位类比
+
+## Key Concepts
+- [[AI生成SVG设计]]：用 AI 生成可编辑的 SVG 矢量 Logo，优于图片模型直出，支持导入 Figma 精修
+- [[LogoGeneratorSkill]]：三步 Logo 生成 Skill（信息收集→设计变体→展示图），推荐在 Gemini CLI 或 Claude Code 中使用
+- [[AI设计工作流]]：AI 生成基础 + 人工精修细节，两步结合保证可控性和专业视觉效果
+- [[SVG-vs-图片生成]]：SVG 可精确控制参数、可编辑、可做动效、矢量无损；图片模型控制精度差、无法编辑、位图放大失真
+
+## Key Entities
+- [[@op7418]]（归藏/guizang.ai）：Skill 作者，CodePilot 项目维护者，Gemini 深度用户
+- [[CodePilot]]：开源项目，Gemini 生成新 Logo 的实践案例
+- [[Nano Banana]]（Gemini 图片生成）：Skill 中用于生成高级展示图的工具，支持 12 种专业背景
+- [[logo-generator-skill]]（GitHub）：开源 Skill，地址 https://github.com/op7418/logo-generator-skill
+
+## Connections
+- [[Claude Skills]] ← is_type_of ← [[LogoGeneratorSkill]]
+- [[Gemini]] ← powers ← [[Nano Banana]]
+- [[Vibe Coding]] ← design_asset_needs ← [[LogoGeneratorSkill]]
+- [[AI生成SVG设计]] ← enables ← [[Figma精修流程]]
+
+## Contradictions
+- 无与其他 Wiki 页面的实质性内容冲突
--- a/wiki/sources/电商如何选品-如何找到爆款-选品策略.md
+++ b/wiki/sources/电商如何选品-如何找到爆款-选品策略.md
@@ -1,55 +1,49 @@
 ---
 title: "电商如何选品 - 如何找到爆款选品策略"
 type: source
-tags: []
-date: 2026-04-18
+tags: ["跨境电商", "选品策略", "电商运营"]
+date: 2026-04-28
 ---

 ## Source File
- [[raw/跨境电商/电商如何选品 如何找到爆款 选品策略.md]]
+- [[跨境电商/电商如何选品 如何找到爆款 选品策略]]

 ## Summary（用中文描述）
- 核心主题：电商选品策略与爆款发现方法论，聚焦跨境电商（Tk Shop / Etsy 平台）
- 问题域：电商创业者如何系统化找到高潜力产品，降低试错成本，实现年销售额数百万美元
- 方法/机制：20 种选品策略 + 情境配对 + 季节性规划 + POD 低成本测款 + 工具辅助分析（Salesmartly / Erank / Pinterest / Etsy 趋势）
- 结论/价值：未来品牌需针对细分市场而非大众市场；多工具组合使用可提升客户转化率和选品效率
+- **核心主题**：电商选品策略与爆款产品发现方法
+- **问题域**：跨境电商卖家如何选择有市场潜力的产品，包括初学者入门和进阶卖家的选品思路
+- **方法/机制**：
+  - 20种选品策略（细分市场、情境配对、节日趋势等）
+  - 工具辅助：Salesmartly（订单管理）、Erank（竞品分析）、Pinterest/Etsy趋势报告
+  - POD（Print on Demand）低成本测试市场模式
+- **结论/价值**：通过系统化选品策略结合数据工具，可有效提升电商销售转化率，降低库存风险

 ## Key Claims（用中文描述）
- 细分市场定位比大众市场更有增长潜力，未来品牌需针对 LGBTQ、特定人群等细分群体
- 情境配对的产品组合（如露营三件套）比单品更具吸引力，能提升客单价
- POD（Print on Demand）模式允许创业者以极低成本测试市场需求，降低库存风险
- 季节性和节日趋势是选品的关键时机，需提前规划布局
- Erank 等工具可分析竞争对手销售情况，提高产品上市效率
- 跨平台订单管理工具（如 Salesmartly）可提升多渠道运营效率
+- 细分市场（针对特定人群如LGBTQ）的产品具有较大市场成长潜力
+- 情境配对产品（如露营三件套）比单品更具吸引力，可提升客单价
+- POD模式允许低库存风险测试市场需求，适合初创卖家
+- 季节性和节日趋势是选品的重要时间窗口，需提前布局
+- 工具辅助（Erank、Salesmartly）可显著提升选品效率和客户转化率

 ## Key Quotes
-> "未来品牌需针对细分市场" — 视频核心观点，强调细分人群定位的战略价值
-> "POD模式让创业者可以低风险测试市场需求" — 降低创业门槛的关键方法
-> "关注Pinterest和Etsy的季度趋势报告，便于掌握热门关键词与产品上市时机" — 趋势洞察工具推荐
+> "未来品牌需针对细分市场进行产品选择" — 强调细分市场的重要性
+> "具有情境的产品组合比单独产品更具吸引力" — 情境配对选品逻辑

 ## Key Concepts
- [[电商选品策略]]：系统化评估和选择电商平台销售产品的决策框架，涵盖市场需求分析、竞争度评估、利润空间计算
- [[爆款产品]]：在特定市场 Segment 中获得高销量和高利润的产品，通常具有差异化竞争力和稳定供应链
- [[POD模式]]（Print on Demand）：按需印刷模式，创业者无需囤货，有订单再生产，大幅降低库存风险和启动成本
- [[情境配对]]：将多个互补产品组合为使用场景套装，通过提升整体价值感知来提高客单价和转化率
- [[季节性选品]]：根据节假日、季节变化、消费趋势预测提前规划产品线，最大化流量高峰期销售
- [[细分市场定位]]：针对特定人群（如LGBTQ、特定年龄层、特定兴趣圈）开发差异化产品，避免大众市场竞争
+- [[选品策略]]：通过系统化方法筛选具有市场潜力的产品线的过程
+- [[细分市场]]：聚焦特定人群或垂直领域的产品定位策略
+- [[情境配对]]：将互补产品组合形成使用场景的产品开发方式
+- [[POD模式]]：Print on Demand，按需打印，低库存风险的产品测试模式
+- [[季节性选品]]：根据节假日和季节变化提前规划产品线的策略

 ## Key Entities
- [[Salesmartly]]：跨平台订单管理和客户沟通工具，支持多渠道消息聚合，提升电商运营效率
- [[Erank]]：Etsy 平台关键词和竞争分析工具，帮助评估产品市场潜力和搜索排名
- [[TikTok Shop]]：字节跳动旗下短视频电商平台，本视频重点运营渠道之一
- [[Etsy]]：手工/创意类 C2C 电商平台，适合 POD 产品和创意商品销售
- [[Pinterest]]：图片分享社交平台，其趋势报告是选品和内容营销的重要参考数据源
+- [[Salesmartly]]：跨平台订单和客户管理工具
+- [[Erank]]：Amazon/Etsy关键词和竞品分析工具
+- [[Etsy]]：手工艺品和创意产品电商平台
+- [[Pinterest]]：趋势发现和灵感来源平台

 ## Connections
- [[电商视频Prompt库]] ← 同一作者/系列 ← 电商选品内容创作
- [[做TK跨境思路不对努力白费]] ← 依赖 ← 选品策略（本文）作为上游输入
- [[可自动化-可扩展-ai增强的电商数据采集与处理系统]] ← 关联 ← 电商选品工具链
+- [[做TK跨境思路不对努力白费]] ← related_to ← [[电商如何选品-如何找到爆款-选品策略]]（均涉及跨境电商运营）
+- [[电商视频prompt]] ← related_to ← [[电商如何选品-如何找到爆款-选品策略]]（均服务于电商内容创作）

 ## Contradictions
- 与 [[做TK跨境思路不对努力白费]] 潜在冲突：
-  - 冲突点：选品的具体平台优先级
-  - 当前观点：Etsy/Pinterest 趋势是重要参考，适合 POD 和创意类产品
-  - 对方观点：优先美区/日本 TikTok Shop，避开东南亚，需数据软件分析
-  - 注：两者针对的产品类型不同（Etsy 手工艺/POD vs TikTok 快消品），可互补而非冲突
+- 暂无发现与其他 Wiki 页面的内容冲突
--- a/wiki/sources/电商视频prompt.md
+++ b/wiki/sources/电商视频prompt.md
@@ -1,45 +1,48 @@
 ---
-title: "电商视频Prompt库"
+title: "电商视频Prompt库（宠物用品/宠物衣服）"
 type: source
-tags: [ai, image-to-video, prompt, text-to-video]
-date: 2026-04-23
+tags: [ai, prompt, image-to-video, text-to-video]
+date: 2026-04-28
 ---

 ## Source File
- [[raw/跨境电商/电商视频Prompt.md]]
+- [[跨境电商/电商视频Prompt.md]]

 ## Summary（用中文描述）
- 核心主题：AI 生成宠物用品电商视频的模块化 Prompt 库
- 问题域：TikTok Shop / 跨境电商宠物用品视频内容生产
- 方法/机制：7 大模块化 Prompt（产品展示 / 宠物动作 / 衣服防穿帮 / 场景变化 / Negative Prompt / 卖货文案 / 全流程示例），通过"拼积木"方式组合使用
- 结论/价值：**低翻车率 + 高真实感**的视频生成方案，服务 TikTok 带货，可扩展到 1 个产品 → 3 条视频 → 6 条文案 → A/B 测试的全链路自动化
+- 核心主题：AI 图生视频（Image-to-Video）Prompt 模块化库，专为 TikTok 电商宠物用品带货场景设计
+- 问题域：电商卖家需要低成本、高真实感、低翻车率的商品展示视频，用于 TikTok 带货
+- 方法/机制：7 大模块化 Prompt 组件（产品展示、宠物动作、服装防穿帮、场景变化、Negative Prompt、卖货文案、全流程合成），通过"拼积木"方式组合使用
+- 结论/价值：实现"图片 → 自动生成 3 条视频 → 自动生成 6 条文案 → A/B 测试"的半自动化电商内容生产流水线

 ## Key Claims（用中文描述）
- 模块化 Prompt 组合策略能够**降低 AI 视频翻车率、提高真实感**，专为电商带货场景设计
- 宠物衣服类视频必须使用**"防穿帮"专用 Prompt**（Clothing Alignment 模块），否则衣服会出现滑动、漂浮、变形
- 场景变化 Prompt 应作为**加法模块叠加**，不应在初始 Prompt 中写死，以实现一条视频模板覆盖多场景
- 一套产品可生成**3 条差异化视频**（细节展示版 / 宠物日常版 / 情绪共鸣版），配合 6 条文案进行 A/B 测试
+- 模块化 Prompt 库可使 AI 图生视频翻车率显著降低，同时保持高真实感
+- 宠物衣服类视频必须使用服装防穿帮（Anti-Clipping）模块，否则极易出现衣物漂浮或穿帮
+- 一个产品可同时产出 3 条视频模板（细节展示版 / 宠物日常版 / 情绪共鸣版），满足 A/B 测试需求
+- Negative Prompt（统一防翻车列表）应作为标准配置降低各类视频生成场景的通用错误率

 ## Key Quotes
 > "低翻车率 + 高真实感 + 为 TikTok 带货服务" — 整体设计目标
 > "场景一定是加法模块，不要一开始就写死" — 场景变化模块使用原则
-> "一个产品 = 3 条视频模板 → 自动生成 6 条文案 → A/B 测试" — 进阶自动化愿景
+> "图片 → 自动生成 3 条视频 → 自动生成 6 条文案 → A/B 测试" — 进阶自动化愿景

 ## Key Concepts
- [[Prompt库设计原则]]：模块化（Modular）、变量化（Variable）、可组合（Composable）
- [[Negative Prompt]]：反向提示词，统一放置以降低翻车率，排除卡通风格/畸形解剖/水印等干扰
- [[Image-to-Video]]：以产品图片为输入，生成动态展示视频（核心工作流）
- [[TikTok电商内容自动化]]：图片 → 视频 → 文案 → A/B 测试的全链路自动化
+- [[模块化Prompt库]]：将视频生成 Prompt 拆分为可独立复用、可自由组合的功能模块，降低使用门槛
+- [[NegativePrompt]]：通过声明"不要生成什么"来约束 AI 行为，是降低翻车率的核心手段
+- [[防穿帮Prompt]]：针对宠物衣服类视频的特殊模块，确保衣物随宠物身体自然运动而不漂浮或变形
+- [[电商视频流水线]]：图片 → AI 视频 → 卖货文案 → A/B 测试的半自动化内容生产闭环

 ## Key Entities
- [[TikTok Shop]]：目标平台，该 Prompt 库的视频专为 TikTok Shop 带货场景设计
- [[宠物用品]]：核心品类，以宠物衣服为典型案例（防穿帮、衣服合身问题）
- [[TikTok]]：短视频/电商平台，卖货文案生成模块（TikTok E-commerce Copywriter）以该平台用户为受众
+- [[TikTok]]：目标发布平台，电商带货场景的核心载体
+- [[TikTok Shop]]：电商转化路径的终点
+- [[Sora]]：AI 图生视频工具之一（由 [[如何利用Sora接口实现视频自动化生成工作流]] 文档补充）

 ## Connections
- [[电商如何选品-如何找到爆款-选品策略]] ← complements ← [[电商视频prompt]]
- [[14个免费的AI图生视频工具-用AI让图片动起来]] ← related_to ← [[电商视频prompt]]
- [[二创视频必不可少-2025年最热门AI工具推荐合集-AI配音-声音克隆]] ← related_to ← [[电商视频prompt]]
+- [[电商如何选品]] ← 支撑 ← 本文档（视频内容服务于选品）
+- [[文字生成视频网站推荐]] ← 关联 ← [[14个免费的AI图生视频工具]] ← 同类主题
+- [[二创视频必不可少！2025年最热门AI工具推荐合集]] ← 关联 ← AI 视频工具生态

 ## Contradictions
- 暂无发现与 Wiki 中其他页面的实质冲突
+- 与 [[如何利用Sora接口实现视频自动化生成工作流]] 在工具选择上可能存在差异：
+  - 冲突点：本文档未指定具体视频生成工具（通用 Prompt），后者聚焦 Sora 接口调用
+  - 当前观点：采用通用模块化 Prompt 策略，可在多个图生视频工具间迁移使用
+  - 对方观点：Sora 是实现视频自动化流水线的核心工具，需要专门的 API 调用方案
--- a/wiki/sources/超达物流定价.md
+++ b/wiki/sources/超达物流定价.md
@@ -6,47 +6,40 @@ date: 2025-12-19
 ---

 ## Source File
- [[raw/跨境电商/超达物流定价.md]]
+- [[跨境电商/超达物流定价]]

 ## Summary（用中文描述）
- 核心主题：超达物流（ChaoDa Logistics）跨境电商定价规则与操作注意事项
- 问题域：TikTok Shop 美国市场跨境发货的物流计费与面单管理
- 方法/机制：
-  - 计费重量取申报重量、实重、材积重三者最大值
-  - UIN渠道提供预上网服务，申请单号后24-48小时推送轨迹
-  - TK平台面单跟踪号以"TKM"开头的为无效单号
-  - 发货截止时间每天12点，美区周日不发货
- 结论/价值：掌握超达物流计费规则，避免因申报重量或面单问题导致额外费用
+- 核心主题：超达物流服务渠道的定价规则与操作注意事项，聚焦 TikTok Shop 美国市场发货场景。
+- 问题域：跨境电商物流成本控制、面单操作规范、轨迹追踪管理。
+- 方法/机制：UIN 渠道提供预上网服务满足 TK 平台轨迹上传需求；申报重量取最大值收费（申报重量、实重、材积三取一）；美区发货截止每天 12 点，周日休息。
+- 结论/价值：为 TikTok 跨境卖家提供超达物流渠道的操作规范与成本注意事项。

 ## Key Claims（用中文描述）
- 超达物流对申报重量、实重、材积取最大值收费，申报重量应低于或等于收费重量
- UIN渠道申请单号后24-48小时产生轨迹上网，需控制好申请单号的时间
- TK平台"TKM"开头的跟踪号为无效单号，需联系客服处理
- 草稿订单状态的单号不会推送轨迹上网，需及时处理
- UIN渠道：未推送轨迹取消单号不收费，已推送则收取全额挂号费
- TK平台面单：未推送轨迹取消单号不收费，已推送收取10元/票操作费
- 选错渠道后期修改均收取10元/票操作费
- 每天12点前到仓的货物当天打包发走，美区周日休息不发货
+- 超达物流 UIN 渠道提供预上网服务，满足 TikTok 上传轨迹需求，申请单号后 24-48 小时左右有轨迹上网。
+- 物流收费按申报重量、实重、材积三者最大值计算，申报重量应低于收费重量以避免多付运费。
+- 申报重量和实重/材积差距尽量不要超过 0.1Kg。
+- UIN 渠道取消单号：未推送轨迹不收操作费，已推送轨迹需收取全额挂号费。
+- TK 平台面单取消单号：未推送轨迹不收操作费，已推送轨迹收取 10 元/票操作费。
+- 发货时间：每天 12 点前到仓当天发走；美区周日休息不发货，周一晚上发。
+- 选错渠道修改收取 10 元/票操作费。

 ## Key Quotes
-> "申报重量、实重、材积取最大值收费，请务必注意。" — 超达物流核心计费原则
+> "申报重量、实重、材积取最大值收费，请务必注意。" — 超达物流收费核心原则
+> "每天12点之前到仓的，都会当天打包发走。美区周日休息不发货，周一晚上发。" — 发货时效说明

 ## Key Concepts
- [[计费重量原则]]：申报重量、实际重量、材积重量三者取最大值作为收费依据
- [[轨迹推送机制]]：UIN渠道在收到单号后24-48小时内推送上网轨迹
- [[取消单号收费]]：以轨迹是否推送为分界，未推送免费，已推送根据渠道收取操作费
+- [[物流预上网服务]]：渠道提前推送物流轨迹，满足平台追踪要求
+- [[材积重]]：根据包装尺寸计算的虚拟重量，与实重比较取大者计费
+- [[挂号费]]：物流单号的注册/追踪服务费用，取消时可能全额收取

 ## Key Entities
- [[超达物流]]：跨境电商物流服务商，提供UIN渠道和TK平台面单服务
- [[TikTok Shop]]：主要销售平台，本文档涉及美国市场发货操作
- [[UIN渠道]]：超达物流提供的预上网渠道，支持24-48小时轨迹推送
+- [[超达物流]]：提供跨境电商物流服务的渠道商
+- [[TikTok Shop]]：本文涉及的跨境电商平台
+- [[UIN 渠道]]：超达物流提供的支持预上网服务的发货渠道

 ## Connections
- [[TikTok Shop]] ← 使用 ← [[超达物流]]
- [[超达物流定价]] ← relates_to ← [[TK美国面单授权及操作流程]]
+- [[TK美国面单授权及操作流程]] ← relates_to ← [[超达物流定价]]
+- [[做TK跨境思路不对努力白费]] ← theme ← [[超达物流定价]]

 ## Contradictions
- 与 [[TK美国面单授权及操作流程]]：
-  - 冲突点：两份文档均涉及超达物流与TikTok美国市场，但本文档专注于定价规则，前者专注于授权配置
-  - 当前观点：定价规则与授权配置可独立存在，互为补充
-  - 对方观点：授权文档侧重系统配置步骤
+- 无已知内容冲突。