Auto-sync: 2026-04-27 08:02

wiki/sources/chinatextbook-41-53-gb-中国小学-初中-高中-大学-pdf-教材.md

@@ -1,42 +1,39 @@
----
-title: "ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材"
-type: source
-tags: []
-date: 2025-12-19
----
-
-## Source File
-- [[raw/Others/ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材.md]]
-
-## Summary
-- 核心主题：ChinaTextbook 是一个收集中国全学段教材 PDF 的开源 GitHub 项目，总库大小 41.53GB。
-- 问题域：优质教育资源获取，免费公开教材的聚合与归档。
-- 方法/机制：项目维护者从国家中小学智慧教育平台抓取教材，托管于 GitHub；用户可使用 tchMaterial-parser 等工具自行下载合并教材。
-- 结论/价值：提供了小学、初中、高中、大学全阶段教材的免费 PDF 资源，适合自学、教育研究和 AI 训练数据使用。
-
-## Key Claims
-- ChinaTextbook 项目（TapXWorld/ChinaTextbook）收集了公开的中国小学、初中、高中、大学 PDF 教材，总库大小 41.53GB，在 GitHub 上公开托管。
-- 教材来源为国家中小学智慧教育平台（basic.smartedu.cn），登录后即可浏览，可使用第三方工具（如 tchMaterial-parser）下载。
-- 小学教材覆盖：体育与健康、数学、科学、美术、艺术、英语、语文/统编版、语文·书法练习指导、道德与法治/统编版、音乐共 10 门学科。
-- 初中教材覆盖：人文地理、体育与健康、俄语、化学、历史、数学、日语、物理、生物学、科学、美术、艺术、英语、语文、道德与法治、音乐共 17 门学科（含地理图册）。
-- 高中教材覆盖：体育与健康、俄语、信息技术、化学、历史、地理、思想政治、数学、日语、物理、生物学、美术、艺术、英语、语文、通用技术、音乐共 18 门学科。
-- 大学教材覆盖：概率论、离散数学、线性代数、高等数学共 4 门基础数学课程。
-
-## Key Quotes
-> "如果有需求，可以制作一个如何下载/合并教材的教程。" — Appinn 原文评论区的用户建议
-
-## Key Concepts
-- [[国家中小学智慧教育平台]]：教材来源平台，basic.smartedu.cn，登录后提供全学段教材浏览
-- [[tchMaterial-parser]]：第三方下载工具，可解析并批量下载国家中小学智慧教育平台的教材
-
-## Key Entities
-- [[TapXWorld/ChinaTextbook]]：GitHub 仓库维护者和项目发起方
-- [[Appinn]]：资讯网站，最早报道此项目并引发关注
-
-## Connections
-- [[Appinn]] — reported_by — [[TapXWorld/ChinaTextbook]]
-- [[tchMaterial-parser]] — used_by — [[TapXWorld/ChinaTextbook]]
-- [[国家中小学智慧教育平台]] — source_of — [[TapXWorld/ChinaTextbook]]
-
-## Contradictions
-- 暂无发现与其他 Wiki 页面的内容冲突。
+---
+title: "ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材"
+type: source
+tags: []
+date: 2025-05-13
+---
+
+## Source File
+- [[raw/Others/ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材.md]]
+
+## Summary（用中文描述）
+- 核心主题：ChinaTextbook 是一个托管在 GitHub 上的中国中小学及大学 PDF 教材开源收集项目，总库大小 41.53 GB
+- 问题域：教育资源公开化与可获取性；国家教材平台的资源下载与整理
+- 方法/机制：通过爬取国家中小学智慧教育平台的公开教材，整合为 GitHub 仓库供公众免费获取
+- 结论/价值：为中文学习者和教育工作者提供了系统化的免费教材资源，覆盖小学至大学阶段
+
+## Key Claims（用中文描述）
+- ChinaTextbook 项目托管在 GitHub，总库大小 41.53 GB，收集了中国从小学到大学阶段的 PDF 教材
+- 教材来源为国家中小学智慧教育平台，该平台登录后即可浏览，第三方工具（如 tchMaterial-parser）可辅助下载
+- 项目覆盖小学、初中、高中及大学四个教育阶段，涉及语文、数学、英语、物理、化学、历史、地理、生物等主要学科
+- 大学阶段主要收录数学类教材，包括概率论、离散数学、线性代数、高等数学
+
+## Key Quotes
+> "这个项目存在有一段时间了，今天突然火了。" — Appinn 报道描述 ChinaTextbook 项目突然获得关注
+> "教材来源为：国家中小学智慧教育平台，本身只需要登录后即可浏览，可以使用第三方工具下载。" — 说明教材合法来源及获取方式
+
+## Key Entities
+- [[TapXWorld]]：GitHub 用户，ChinaTextbook 项目的创建者和维护者
+- [[国家中小学智慧教育平台]]：中国官方中小学教育资源平台，为 ChinaTextbook 提供教材来源
+
+## Key Concepts
+- [[教育资源开源]]：将国家官方教材整理并开源发布，降低教育资源的获取门槛
+- [[PDF教材数字化]]：将纸质教材数字化为 PDF 格式，便于传播和离线使用
+
+## Connections
+- [[国家中小学智慧教育平台]] ← 原始来源 ← [[ChinaTextbook]]
+
+## Contradictions
+- 暂无已知冲突

wiki/sources/dataview-让我从"笔记黑洞"里逃出来的-obsidian-神器-1.md

@@ -0,0 +1,43 @@
+---
+title: "Dataview——让我从"笔记黑洞"里逃出来的 Obsidian 神器"
+type: source
+tags: []
+date: 2025-03-07
+---
+
+## Source File
+- [[raw/Others/Dataview——让我从"笔记黑洞"里逃出来的 Obsidian 神器 1.md]]
+
+## Summary（用中文描述）
+- 核心主题：Dataview 插件如何将 Obsidian 打造成"笔记数据库"，解决笔记越记越乱的问题
+- 问题域：Obsidian 用户的笔记检索与组织困境——笔记越记越多，查找越来越困难
+- 方法/机制：Dataview 提供类 SQL 的查询语法，可对笔记的 YAML frontmatter 和标签进行动态查询，自动生成视图
+- 结论/价值：Dataview 让笔记"活"起来，自动整理待办事项、按标签索引笔记、统计写作量，将散落的笔记转化为可查询的知识库
+
+## Key Claims（用中文描述）
+- Dataview 插件可将 Obsidian 打造成"笔记数据库"，对所有笔记内容进行动态查询
+- Dataview 能自动整理散落在各笔记中的待办事项，生成统一的任务视图
+- 通过标签系统（#学习、#写作），Dataview 可自动生成笔记索引，无需手动维护
+- Dataview 支持统计写作量，帮助用户追踪笔记产出
+- 最基础的查询语法 `LIST FROM "Notes" WHERE contains(tags, "学习")` 即可实现标签笔记的自动罗列
+
+## Key Quotes
+> "写笔记的时候激情满满，查笔记的时候满头大汗。" — 对笔记管理困境的精准描述
+> "Dataview 就是 Obsidian 里的'笔记数据库'，它可以帮你自动整理各种内容" — Dataview 的核心定位
+
+## Key Concepts
+- [[NoteDatabase]]：将笔记视为数据库，支持结构化查询的概念
+- [[QueryLanguage]]：Dataview 的查询语法，类似 SQL 的声明式查询语言
+- [[TagBasedIndexing]]：通过标签自动索引和分类笔记的方法
+
+## Key Entities
+- [[DataviewPlugin]]：Obsidian 社区插件，将笔记数据库化
+
+## Connections
+- [[ObsidianTasksPlugin]] ← 对比/延伸 ← [[DataviewPlugin]]
+  - 两者均面向 Obsidian 任务管理，Dataview 更通用（支持所有笔记字段查询），Tasks 专注文务语法
+- [[Notion]] ← 对比 ← [[DataviewPlugin]]
+  - Notion 内置数据库 vs Obsidian + Dataview 的本地化方案
+
+## Contradictions
+- 无已知冲突

wiki/sources/google-5个agent-skill设计模式-2026-03-19.md

@@ -1,59 +1,55 @@
----
-title: "Google 5个 Agent Skill 设计模式"
-type: source
-tags: [Agent, Skill, 设计模式, Google, Anthropic, ADK]
-sources: []
-last_updated: 2026-03-19
----
-
-## Source File
-- [[Agent/Google-5个Agent-Skill设计模式-2026-03-19.md]]
-
-## Summary（用中文描述）
-- 核心主题：Google Cloud 发布的 5 种经过验证的 Agent Skill 设计模式，每种都有完整的 ADK 代码示例
-- 问题域：Agent 开发中同样 SKILL.md 格式，执行效果天差地别的问题
-- 方法/机制：Tool Wrapper、Generator、Reviewer、Inversion、Pipeline 五种结构化设计模式
-- 结论/价值：将工作流拆分为正确的结构模式，才能构建出真正可靠的 Agent
-
-## Key Claims（用中文描述）
-- SKILL.md 格式标准化后，内容设计成为决定执行效果的关键
-- Tool Wrapper 模式通过动态加载 references/ 目录实现按需知识注入
-- Generator 模式通过"填空"流程强制一致的输出格式
-- Reviewer 模式将"检查什么"和"怎么检查"完全分离
-- Inversion 模式让 Agent 变成面试官，先收集信息再行动
-- Pipeline 模式通过硬性检查点强制执行严格的顺序工作流
-- 五种模式可以组合使用，ADK 的 SkillToolset 支持按需加载
-
-## Key Quotes
-> "最好的 Skill 不是写得好的提示词，而是一个「工具箱」" — Anthropic Skill 设计经验
-> "把工作流拆分开，应用正确的结构模式，才能构建出真正可靠的 agent" — Google ADK 指南总结
-> "Anthropic 把内部几百个 Skills 用了个遍，发现最好的 Skill 不是写得好的提示词，而是一个「工具箱」。他们把 Skills 分成九类，从参考手册到故障排查，每类都有明确的场景。" — Anthropic 的 Skill 实践
-
-## Key Concepts
-- [[ToolWrapper模式]]：将库/框架规范打包成 Skill，监听关键词按需加载 references/ 目录下的文档
-- [[Generator模式]]：利用 assets/ 存放输出模板、references/ 存放样式指南，通过"填空"流程生成结构化输出
-- [[Reviewer模式]]：将审查标准存放在 references/review-checklist.md，指令保持静态，Agent 动态加载特定审查标准
-- [[Inversion模式]]：Agent 先变成面试官逐阶段提问，等用户回答完所有问题后再行动
-- [[Pipeline模式]]：通过硬性检查点和明确门控条件强制执行严格的顺序工作流
-- [[渐进式披露]]：ADK 的 SkillToolset 机制，Agent 只在运行时需要时才消耗上下文 token 加载特定模式
-- [[SkillToolset]]：ADK 中支持多个 Skill 组合使用的工具集
-
-## Key Entities
-- [[GoogleCloud]]：发布 ADK Agent 开发指南的主体，提供了 5 种设计模式
-- [[Anthropic]]：Claude Code 开发者，其 Skill 设计经验（9 类分类、3 条铁律）作为附录被引用
-- [[SabooShubham]]：Google ADK 指南作者之一
-- [[lavinigam]]：Google ADK 指南作者之一
-- [[ADK]]（Agent Development Kit）：Google Cloud 的 Agent 开发工具包，提供了完整的代码示例
-- [[ClaudeCode]]：Anthropic 的 CLI Agent，支持 SKILL.md 格式
-- [[awesome-agent-skills]]：GitHub 仓库，收集了主流工具的 Skill 示例
-
-## Connections
-- [[ClaudeCode调用方法总结]] ← related_to ← [[Google5个AgentSkill设计模式]]
-- [[AnthropicSkill实践]] ← extends ← [[Google5个AgentSkill设计模式]]
-- [[ClaudeCodeTemplates]] ← related_to ← [[SkillToolset]]
-
-## Contradictions
-- 与 [[ClaudeSkill设计指南9种类型]] 冲突：
-  - 冲突点：Google 强调 5 种结构化设计模式；Anthropic 强调 9 类 Skill 分类
-  - 当前观点：结构模式和分类体系可以互补，Google 关注 Skill 内部结构，Anthropic 关注 Skill 的使用场景
-  - 对方观点：两种方法论各有侧重，共同目标是构建可靠的 Agent
+---
+title: "Google 5个 Agent Skill 设计模式"
+type: source
+tags: ["Agent", "Skill", "设计模式", "Google", "ADK"]
+date: 2026-03-19
+sources: []
+last_updated: 2026-05-15
+---
+
+## Source File
+- [[Agent/Google-5个Agent-Skill设计模式-2026-03-19.md]]
+
+## Summary（用中文描述）
+- 核心主题：Google ADK 发布的 5 种经过验证的 Agent Skill 设计模式，帮助开发者将复杂的工作流从脆弱的 system prompt 中解耦出来
+- 问题域：Agent 开发中，SKILL.md 格式已标准化，但相同格式的 skill 执行效果差异巨大，问题出在内容设计上
+- 方法/机制：5 种结构化设计模式（Tool Wrapper、Generator、Reviewer、Inversion、Pipeline），通过 SKILL.md 的目录结构（references/、assets/）和渐进式披露机制实现
+- 结论/价值：这 5 种模式可组合使用，通过 ADK 的 SkillToolset 在运行时按需加载，只在需要时才消耗上下文 token
+
+## Key Claims（用中文描述）
+- Google ADK 的 SkillToolset 和渐进式披露机制，使得 agent 只在运行时需要时才加载特定的 skill 逻辑
+- Tool Wrapper 模式通过监听特定库关键词，动态加载 references/ 目录下的规范文档，让 agent 在真正用到该技术时才加载相关规则
+- Generator 模式通过 assets/（输出模板）和 references/（样式指南）两个目录，实现强制一致的文档结构输出
+- Reviewer 模式将"检查什么"（references/review-checklist.md）和"怎么检查"（SKILL.md 指令）完全分离，同一 skill 基础设施换清单就是不同专项审计
+- Inversion 模式通过明确的门控指令（如"不到所有阶段完成就不开始构建"），让 agent 变成面试官，先问你问题再行动
+- Pipeline 模式通过硬性检查点（gating conditions）强制执行严格顺序工作流，确保 agent 无法绕过步骤直接给出未验证结果
+- Anthropic 经验：最好的 Skill 不是写好的提示词，而是"工具箱"；写好 Skill 的三条铁律：只写 Agent 不知道的东西、重点写踩坑清单、给工具不给指令
+
+## Key Quotes
+> "别再把所有复杂又脆弱的指令塞进一个 system prompt了。把工作流拆分开，应用正确的结构模式，才能构建出真正可靠的 agent。" — 结论总结
+> "Anthropic 把内部几百个 Skills 用了个遍，发现最好的 Skill 不是写得好的提示词，而是一个「工具箱」。" — Anthropic 的 Skill 实践
+
+## Key Concepts
+- [[ToolWrapper模式]]：将某个库或框架的规范文档打包成一个 skill，agent 只在用到该技术时才动态加载相关规则
+- [[Generator模式]]：利用 assets/ 和 references/ 两个目录，通过"填空"流程生成结构化输出
+- [[Reviewer模式]]：将审查标准（references/review-checklist.md）与检查逻辑（SKILL.md）完全分离
+- [[Inversion模式]]：agent 先问你再做，通过门控指令强制 agent 逐阶段提问并等待用户回答
+- [[Pipeline模式]]：带硬性检查点的严格顺序工作流，确保复杂任务无法跳过步骤
+- [[渐进式披露]]：ADK 的 SkillToolset 机制，只在运行时按需加载需要的 skill 内容，按需消耗上下文 token
+- [[SkillToolset]]：Google ADK 中的 skill 基础设施，支持目录结构和动态加载
+
+## Key Entities
+- [[Google ADK]]：Google Agent Development Kit，由 Saboo_Shubham_ 和 lavinigam 撰写，发布 5 种 Skill 设计模式指南
+- [[Anthropic Claude Code]]：参考了 Anthropic 的 Skill 实践经验，Claude Code 是支持 SKILL.md 格式的主流工具之一
+- [[Saboo_Shubham_]]：Google ADK Skill 设计模式指南作者之一
+- [[lavinigam]]：Google ADK Skill 设计模式指南作者之一
+
+## Connections
+- [[Anthropic Claude Code]] ← 参考 ← [[Google 5个 Agent Skill 设计模式]]
+- [[渐进式披露]] ← 由 ← [[Google ADK]]
+- [[SkillToolset]] ← 属于 ← [[Google ADK]]
+- [[Reviewer模式]] ← 可组合 ← [[Pipeline模式]]
+- [[Generator模式]] ← 可组合 ← [[Inversion模式]]
+
+## Contradictions
+- 与 [[Anthropic Claude Code]] 不冲突：Anthropic 强调"给工具不给指令"，Google 的 5 种模式正是这一理念的具体实现方式

wiki/sources/how-to-get-youtube-channel-id.md

@@ -1,40 +1,42 @@
----
-title: "How to get Youtube Channel ID"
-type: source
-tags: []
-date: 2025-03-16
----
-
-## Source File
-- [[raw/Others/How to get Youtube Channel ID.md]]
-
-## Summary（用中文描述）
-- 核心主题：通过浏览器 view-source 方法获取 YouTube 频道的 Channel ID
-- 问题域：YouTube 频道识别与 RSS 订阅源获取
-- 方法/机制：使用 `view-source:` URL 前缀访问频道页面，在页面源码中搜索 `channel_id` 字符串，从中提取 RSS Feed URL 中的频道 ID
-- 结论/价值：无需 API Key 或第三方工具，即可通过纯浏览器操作获取频道 ID，可用于 [[n8n]] 工作流等自动化场景
-
-## Key Claims（用中文描述）
-- 用户可通过浏览器访问 `view-source:https://www.youtube.com/@频道名` 获取页面源码
-- 在源码中搜索 `channel_id` 字符串可找到 RSS Feed 地址
-- RSS Feed URL 格式为 `https://www.youtube.com/feeds/videos.xml?channel_id=UCxxxxxx`
-- 获取到的 Channel ID 可用于 [[n8n]] 等工作流自动化工具
-
-## Key Quotes
-> "view-source:https://www.youtube.com/@Numberblocks" — 浏览器地址栏输入此 URL 访问频道页面源码
-> "channel_id=UCPlwvN0w4qFSP1FllALB92w" — 搜索 `?channel_id` 可找到该频道的 RSS Feed URL
-> "channel id can be used in n8n workflow" — Channel ID 的实际应用场景
-
-## Key Concepts
-- [[Channel ID]]：YouTube 频道的唯一标识符，格式为 `UC` 开头加 22 位字符
-- [[RSS Feed]]：`https://www.youtube.com/feeds/videos.xml?channel_id=<ID>` 是 YouTube 频道的 RSS 订阅源格式
-
-## Key Entities
-- [[YouTube]]：全球最大视频分享平台，Channel ID 是其频道资源的唯一标识
-- [[n8n]]：工作流自动化工具，可利用 Channel ID 订阅 YouTube 频道更新
-
-## Connections
-- [[n8n-workflow-orchestration]] ← uses ← [[YouTube Channel ID]] ← extracted_from ← [[RSSHub]]（相关工作流自动化集成）
-
-## Contradictions
-- （无冲突）
+---
+title: "How to get Youtube Channel ID"
+type: source
+tags: []
+date: 2025-03-16
+---
+
+## Source File
+- [[Others/How to get Youtube Channel ID]]
+
+## Summary（用中文描述）
+- 核心主题：从 YouTube 频道页面获取 Channel ID 的方法
+- 问题域：YouTube 自动化工作流（如 n8n）中需要使用 Channel ID，但 YouTube 官方界面不直接显示
+- 方法/机制：通过浏览器 view-source 查看频道页面 HTML 源码，搜索 `?channel_id` 字符串即可提取
+- 结论/价值：获取的 Channel ID 可用于 n8n 工作流、RSS 订阅源、API 调用等场景
+
+## Key Claims（用中文描述）
+- 通过浏览器访问 `view-source:https://www.youtube.com/@频道名` 可查看频道页面的 HTML 源码
+- 在源码中搜索 `?channel_id` 字符串，可以找到该频道对应的唯一 Channel ID
+- 找到的 Channel ID 格式为：`https://www.youtube.com/feeds/videos.xml?channel_id=UCxxxx`
+- 获取的 Channel ID 可用于 n8n 等自动化工作流
+
+## Key Quotes
+> "view-source:https://www.youtube.com/@Numberblocks" — 在浏览器地址栏输入此 URL 查看频道页面的 HTML 源代码
+> "?channel_id" — 在源代码中搜索此字符串以定位频道 ID
+
+## Key Concepts
+- [[YouTube Channel ID]]：YouTube 为每个频道分配的唯一标识符，格式为 UC 开头，用于 API 调用、RSS 订阅等场景
+
+## Key Entities
+- [[Numberblocks]]：示例 YouTube 频道（儿童数学教育频道），文档中用于演示获取 Channel ID 的示例频道
+
+## Connections
+- [[实战笔记：本地部署 RSSHub 并获取 YouTube 订阅]] ← related_to ← [[YouTube Channel ID]]
+
+## Contradictions
+- 无已知冲突
+
+## Aliases
+- Channel ID
+- channel_id
+- YouTube Channel Identifier

wiki/sources/mcp在cursor中的集成与应用详解.md

@@ -1,52 +1,55 @@
----
-title: "MCP在Cursor中的集成与应用详解"
-type: source
-tags: [ai, ai-agent, cursor, mcp]
-sources: []
-last_updated: 2026-04-22
----
-
-## Source File
-- [[Agent/MCP在Cursor中的集成与应用详解]]
-
-## Summary（用中文描述）
-- 核心主题：MCP（Model Context Protocol）在 Cursor AI IDE 中的集成配置与实际应用。
-- 问题域：AI 大模型与外部工具服务的集成交互协议与实操配置。
-- 方法/机制：基于 Client-Server 架构的 MCP 协议，通过 SSE 服务端模式和本地 Command 命令行两种方式接入 Cursor；在 Composer 模块的 Agent 模式下调用 MCP 工具链。
-- 结论/价值：MCP 实现了 AI 大模型与多样化外部工具的无缝集成，显著提升 AI 应用的扩展能力和交互效率。
-
-## Key Claims（用中文描述）
-- MCP 是 Modal Context Protocol 的缩写，是一种基于 Client-Server 架构的协议，旨在实现大模型与外围服务的高效集成。
-- MCP Server 提供三种功能接口：资源获取（GET）、工具调用（POST）、Promise 提示词。
-- Cursor 中 MCP Server 有两种接入方式：SSE 服务方式和本地执行命令（Command）方式。
-- Composer 中的 Agent 模式能自动执行内嵌命令并处理工具调用，减少手动操作步骤。
-- Sequential Thinking 是 MCP 工具之一，支持逻辑推理与分步执行任务，优化 AI 模型的思考与响应过程。
-
-## Key Quotes
-> "MCP是Modal Context Protocol的缩写，是一种基于Client-Server架构的协议，旨在实现大模型与外围服务的高效集成。MCP Server提供三种功能接口：资源获取（类似HTTP的GET）、工具调用（类似POST请求）、以及Promise提示词，用于多样化的交互与扩展。"
-> — MCP 架构定义
-
-> "Agent模式与Normal模式的最大区别在于：Agent模式实现命令的链路打通，减少手动操作的步骤，自动执行内嵌命令并处理工具调用。"
-> — Cursor Composer Agent模式说明
-
-## Key Concepts
-- [[MCP（Model Context Protocol）]]：基于 Client-Server 架构的协议，支持 AI 大模型与外围工具基于 GET/POST/Promise 三种接口进行高效交互。
-- [[Sequential Thinking]]：MCP 工具之一，支持逻辑推理与分步执行任务，优化 AI 模型的思考与响应过程。
-- [[Tool Calling]]：MCP 协议中的工具调用机制，类似 POST 请求，用于触发外部工具执行。
-- [[SSE（Server-Sent Events）]]：一种服务器向客户端推送实时事件的技术，作为 MCP 的一种接入方式。
-- [[Agent模式]]：Cursor Composer 中的交互方式，自动执行内嵌命令并处理工具调用，提升操作效率。
-- [[Yolo Mode]]：Cursor Agent 模式中的自动执行开关，开启后会无确认执行所有命令，存在较高误操作风险，默认关闭。
-
-## Key Entities
-- [[Cursor]]：AI 增强型代码编辑器，支持 MCP 协议集成，通过 Composer 模块实现 Agent 模式与 MCP 工具链调用。
-- [[smisery]]：提供热点新闻 MCP Server 的网站，支持九个新闻来源的 MCP 服务集成。
-- [[鱼凤老师]]：视频教程作者，专注 AI 大模型与工具集成的实战分享。
-
-## Connections
-- [[Cursor]] ← 集成 ← [[MCP（Model Context Protocol）]]
-- [[Cursor]] ← 使用模式 ← [[Agent模式]]
-- [[Sequential Thinking]] ← 工具调用 ← [[MCP（Model Context Protocol）]]
-- [[热点新闻服务]] ← MCP Server 实现 ← [[smisery]]
-
-## Contradictions
-- 无已知冲突内容。
+---
+title: "MCP在Cursor中的集成与应用详解"
+type: source
+tags: [ai, ai-agent, cursor, mcp]
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/MCP在Cursor中的集成与应用详解.md]]
+
+## Summary（用中文描述）
+- 核心主题：MCP（Modal Context Protocol）在 Cursor AI 编程工具中的集成配置与实际应用方法。
+- 问题域：AI 大模型如何与外部工具和服务高效集成的协议标准问题。
+- 方法/机制：MCP 基于 Client-Server 架构，提供资源（GET）、工具调用（POST）、Promise 提示词三类接口；在 Cursor 中通过 SSE 服务或本地命令两种方式接入 MCP Server；在 Composer 的 Agent 模式下调用 MCP 工具链实现自动化任务执行。
+- 结论/价值：MCP 协议为 AI 应用提供了标准化的工具扩展框架，使大模型能够无缝调用外部数据源和工具；Sequential Thinking 等工具展示了 MCP 工具链协同工作的实际效果。
+
+## Key Claims（用中文描述）
+- MCP 协议基于 Client-Server 架构，使 AI 大模型能够通过标准化接口与外部工具服务进行高效集成。
+- MCP Server 提供三类核心接口：资源访问（类 GET）、工具调用（类 POST）、Promise 提示词。
+- Cursor 中 MCP Server 的两种接入方式为 SSE 服务方式和本地执行命令（Command）方式。
+- Composer Agent 模式可自动执行 MCP 工具链命令，相比 Normal 模式减少了手动操作步骤。
+- "enable yolo mode" 自动执行所有命令风险较高，建议默认关闭以避免误操作。
+- Sequential Thinking 工具通过逻辑推理分步拆解任务，提升 AI 沟通效率和决策质量。
+
+## Key Quotes
+> "MCP 是 Modal Context Protocol 的缩写，是一种基于 Client-Server 架构的协议，旨在实现大模型与外围服务的高效集成。" — MCP 协议定义
+> "Agent模式能实现自动运行工具命令，Normal模式需要用户手动复制命令执行，理解区别尤为关键。" — Agent 模式与 Normal 模式的核心区别
+> "enable yolo mode 开启后会自动执行所有命令，可能造成误操作如误删文件，官方默认关闭，建议用户谨慎选择。" — Yolo Mode 安全警告
+
+## Key Concepts
+- [[ModalContextProtocol]]：一种 AI 大模型与外部工具服务集成的标准化 Client-Server 协议，提供资源访问、工具调用、提示词三类接口。
+- [[SequentialThinking]]：MCP 工具之一，支持逻辑推理与分步执行任务，优化 AI 模型的思考与响应过程。
+- [[AgentMode]]：Cursor Composer 中的自动化交互模式，自动执行内嵌命令并处理工具调用。
+- [[YoloMode]]：Cursor 中的高风险自动执行模式，开启后自动执行所有命令，建议默认关闭。
+- [[McpServer]]：MCP 协议体系中的服务提供方，负责对外提供资源和工具接口。
+
+## Key Entities
+- [[Cursor]]：支持 MCP 集成的 AI 编程 IDE，Composer 模块提供 Agent 模式和 Normal 模式两种交互方式。
+- [[Smisery]]：提供热点新闻 MCP Server 的网站，支持九个新闻来源的数据接入。
+- [[Composer]]：Cursor 中的对话构建模块，支持切换 Agent 模式以调用 MCP 工具链。
+- [[SSE]]：Server-Sent Events，一种服务器向客户端推送实时事件的技术，作为 MCP 接入方式之一。
+- [[鱼凤老师]]：本视频的讲解者，围绕 MCP 在 Cursor 中的集成与应用进行讲解。
+
+## Connections
+- [[McpBuilderAgent]] ← extends ← [[ModalContextProtocol]]
+- [[Cursor]] ← integrates_with ← [[ModalContextProtocol]]
+- [[SequentialThinking]] ← tool_of ← [[ModalContextProtocol]]
+- [[Cursor]] ← extends ← [[Cursor2.0初学者使用指南]]
+
+## Contradictions
+- 与 [[McpBuilderAgent]]：
+  - 冲突点：本文侧重于 MCP 的终端用户使用（如何在 Cursor 中配置和调用 MCP），而 [[McpBuilderAgent]] 侧重于 MCP Server 的构建开发。
+  - 当前观点：用户应通过配置 MCP Server 在 Cursor 中直接使用现成的 MCP 工具链。
+  - 对方观点：开发者应使用 MCP Builder Agent 构建自定义的 MCP Server 来满足特定需求。
+  - 说明：两者实为互补关系——MCP Builder Agent 构建 Server，Cursor 用户消费 Server。

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

@@ -1,48 +1,35 @@
----
-title: "n8n + Claude：通过自然语言自动化工作流"
-type: source
-tags: [claude, n8n, n8n-mcp, nodejs]
-date: 2025-12-31
----
-
-## Source File
-- [[Agent/n8n+Claude 通过自然语言自动化工作流.md]]
-
-## Summary（用中文描述）
-- 核心主题：通过在 Claude Desktop 中配置 n8n-mcp MCP 服务器，使 Claude 能够通过自然语言指令直接调用 n8n 的 543 个节点，自动生成和执行工作流，实现"用嘴做自动化"。
-- 问题域：用户需要在 Claude Desktop 环境中使用 MCP 协议连接 n8n，通过自然语言驱动的 AI Agent 实现工作流自动化。
-- 方法/机制：安装 Claude Desktop → 安装 Node.js 运行环境 → 安装 n8n-mcp MCP 服务器 → 配置 MCP 连接 → 用自然语言向 Claude 描述需求 → Claude 调用 n8n 节点生成工作流。
-- 结论/价值：结合 Claude 的自然语言理解和 n8n 的 543 个节点能力，实现低门槛的 AI 驱动工作流自动化，大幅降低非技术用户的自动化实现成本。
-
-## Key Claims（用中文描述）
-- n8n-mcp 作为 MCP 服务器，将 Claude Desktop 与 n8n 工作流引擎连接，使 Claude 能够理解并调用 n8n 全部 543 个节点。
-- Claude Desktop 通过 MCP 协议与 n8n 通信，实现"自然语言 → 工作流代码"的端到端自动化生成。
-- n8n 是开源工作流自动化平台，Node.js 运行环境是其依赖基础。
-- Node.js 是 n8n-mcp 的运行时环境，必须先安装 Node.js 才能启动 MCP 服务。
-
-## Key Quotes
-> "安装 Claude Desktop 后，在 Claude Desktop 中安装 mcp npm 包，以实现本地与 n8n 的 MCP 连接。" — 环境准备步骤
-
-## Key Concepts
-- [[工作流自动化]]：通过自然语言指令让 AI 自动设计和搭建 n8n 自动化流程的技术方法。
-- [[MCP（Model Context Protocol）]]：Anthropic 推出的模型上下文协议，作为 Claude Desktop 与 n8n-mcp 之间的通信桥梁，实现工具调用标准化。
-- [[Extended Thinking]]：Claude 的深层推理模式，提升代码生成质量和逻辑正确性（本来源 [[使用Claude自动生成N8N工作流的实操教程]] 关联）。
-
-## Key Entities
-- [[Claude Desktop]]：Anthropic Claude AI 桌面应用，支持 MCP 协议扩展，可通过 n8n-mcp 连接 n8n 工作流引擎。
-- [[n8n-mcp]]：czlonkowski/n8n-mcp 开源 MCP 服务器项目，充当 Claude Desktop 与 n8n 之间的桥梁，支持 543 个 n8n 节点、87% 官方文档覆盖。
-- [[Node.js]]：JavaScript 运行时环境，n8n-mcp 的运行依赖，必须先安装 Node.js 才能启动 MCP 服务。
-- [[N8N]]：开源工作流自动化平台（由多个节点按顺序执行的自动化流程组成），Claude 通过 n8n-mcp 调用其全部节点。
-
-## Connections
-- [[Claude Desktop]] ← connects via ← [[MCP（Model Context Protocol）]] ← through ← [[n8n-mcp]]
-- [[n8n-mcp]] ← controls ← [[N8N]]（工作流执行引擎）
-- [[n8n-mcp]] ← requires ← [[Node.js]]（运行环境）
-- [[Claude Desktop]] ← generates ← [[工作流自动化]]（目标产出）
-
-## Contradictions
-- 与 [[使用Claude自动生成N8N工作流的实操教程]] 对比：
-  - 冲突点：两篇文章均介绍 Claude + n8n 自动化，但实现路径不同。
-  - 当前观点（本篇）：使用 Claude Desktop（桌面客户端）+ n8n-mcp MCP 服务器本地连接，适合桌面用户。
-  - 对方观点（另一篇）：使用 Claude API（云端）+ n8n-mcp，适合 API 编程集成场景。
-  - 说明：两者核心技术相同（n8n-mcp + MCP 协议），差异在于 Claude 的接入方式（桌面客户端 vs API），可互补使用。
+---
+title: "n8n + Claude：通过自然语言自动化工作流"
+type: source
+tags: [claude, n8n, nodjs]
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/n8n+Claude 通过自然语言自动化工作流.md]]
+
+## Summary（用中文描述）
+- 核心主题：通过 Claude Desktop 的自然语言能力与 n8n 工作流自动化平台结合，实现工作流的自然语言驱动创建与管理
+- 问题域：如何让非技术用户无需编写代码，通过自然语言描述即可生成 n8n 自动化工作流
+- 方法/机制：利用 Claude Desktop 作为自然语言理解与代码生成层，输出 n8n 工作流 JSON 配置
+- 结论/价值：降低自动化工作流创建门槛，让用户以对话方式快速构建复杂业务流程
+
+## Key Claims（用中文描述）
+- Claude Desktop 能够理解自然语言描述的工作流程需求（主体 + 机制 + 结果）
+- n8n 作为开源工作流自动化平台，支持通过 JSON 配置定义工作流节点与连接关系（主体 + 机制 + 结果）
+- 自然语言 → Claude → n8n JSON 的链路可以大幅降低工作流创建门槛（主体 + 机制 + 结果）
+
+## Key Quotes
+> "通过 Claude Desktop，用户可以直接用自然语言描述需求，Claude 解析后生成可执行的 n8n 工作流配置" — 核心方法论
+
+## Key Concepts
+- [[工作流自动化]]：使用软件系统代替人工执行重复性业务流程的技术
+- [[自然语言接口]]：通过人类语言与系统交互，无需学习专用语法或编程语言
+
+## Key Entities
+- [[Claude Desktop]]：Anthropic 推出的桌面客户端，内置 Claude AI 助手，支持自然语言对话与代码生成
+- [[n8n]]：开源工作流自动化工具，支持通过可视化界面或 JSON 配置创建自动化流程
+
+## Connections
+- [[使用Claude自动生成N8N工作流的实操教程]] ← related_to ← [[n8n + Claude：通过自然语言自动化工作流]]
+- [[n8n-workflow-orchestration]] ← extends ← [[n8n + Claude：通过自然语言自动化工作流]]

wiki/sources/n8n-configure-telegram-trigger.md

@@ -1,42 +1,42 @@
----
-title: "n8n configure telegram trigger"
-type: source
-tags: [n8n, telegram]
-date: 2026-04-22
----
-
-## Source File
-- [[Agent/n8n configure telegram trigger.md]]
-
-## Summary（用中文描述）
-- 核心主题：n8n Telegram Trigger 节点的 HTTPS Webhook 配置与故障排查
-- 问题域：n8n 工作流自动化平台在接收 Telegram 机器人消息时的 Webhook 注册问题
-- 方法/机制：通过设置 `WEBHOOK_URL` 环境变量为 HTTPS URL，使 n8n 生成符合 Telegram 要求的 HTTPS Webhook 地址；Docker Desktop 容器环境下配置该环境变量
-- 结论/价值：解决 Telegram "bad webhook: An HTTPS URL must be provided for webhook" 错误，成功激活 Telegram Trigger 节点
-
-## Key Claims（用中文描述）
-- Telegram 要求 Webhook URL 必须是 HTTPS 协议，HTTP 或空值均无法注册
-- `WEBHOOK_URL` 环境变量控制 n8n 生成的 Webhook URL 协议前缀
-- 在 Docker Desktop 环境中设置 `WEBHOOK_URL=https://n8n.cpolar.top` 可解决内网 n8n 实例的 Telegram Webhook 配置问题
-
-## Key Quotes
-> "Telegram Trigger: Bad Request: bad webhook: An HTTPS URL must be provided for webhook" — 错误信息，表明 Telegram 要求 HTTPS Webhook
-
-> "WEBHOOK_URL=https://your-domain.com/" — 官方推荐的 n8n Telegram Trigger HTTPS Webhook 配置方法
-
-## Key Concepts
-- [[Webhook]]：网络钩子，一种服务器间实时推送数据的机制；Telegram Bot API 使用 Webhook 模式而非轮询来接收消息
-- [[Telegram Trigger]]：n8n 平台中用于接收 Telegram 机器人消息并触发工作流的节点
-- [[WEBHOOK_URL]]：n8n 环境变量，指定 n8n 实例的对外 HTTPS 访问地址，用于生成 Telegram Webhook URL
-
-## Key Entities
-- [[n8n]]：开源工作流自动化平台，支持通过 Trigger 节点监听外部事件（如 Telegram 消息）
-- [[Telegram]]：即时通讯平台，提供 Bot API，支持 Webhook 推送消息
-- [[Docker Desktop]]：桌面级 Docker 运行环境，在其中运行 n8n 容器时通过环境变量配置 WEBHOOK_URL
-
-## Connections
-- [[n8n Docker 安装与更新]] ← extends ← [[n8n configure telegram trigger]]（本文为 n8n Docker 部署的 Telegram 集成补充）
-- [[Webhook]] ← used_by ← [[Telegram Trigger]]（Webhook 机制是 Telegram Trigger 的底层通信方式）
-
-## Contradictions
-- 无已知冲突
+---
+title: "n8n configure telegram trigger"
+type: source
+tags: [n8n, telegram]
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/n8n configure telegram trigger.md]]
+
+## Summary（用中文描述）
+- 核心主题：n8n Telegram Trigger 节点的 HTTPS Webhook 配置与故障排查
+- 问题域：n8n 工作流自动化平台在接收 Telegram 机器人消息时的 Webhook 注册问题
+- 方法/机制：通过设置 `WEBHOOK_URL` 环境变量为 HTTPS URL，使 n8n 生成符合 Telegram 要求的 HTTPS Webhook 地址；Docker Desktop 容器环境下配置该环境变量
+- 结论/价值：解决 Telegram "bad webhook: An HTTPS URL must be provided for webhook" 错误，成功激活 Telegram Trigger 节点
+
+## Key Claims（用中文描述）
+- Telegram 要求 Webhook URL 必须是 HTTPS 协议，HTTP 或空值均无法注册
+- `WEBHOOK_URL` 环境变量控制 n8n 生成的 Webhook URL 协议前缀
+- 在 Docker Desktop 环境中设置 `WEBHOOK_URL=https://n8n.cpolar.top` 可解决内网 n8n 实例的 Telegram Webhook 配置问题
+
+## Key Quotes
+> "Telegram Trigger: Bad Request: bad webhook: An HTTPS URL must be provided for webhook" — 错误信息，表明 Telegram 要求 HTTPS Webhook
+
+> "WEBHOOK_URL=https://your-domain.com/" — 官方推荐的 n8n Telegram Trigger HTTPS Webhook 配置方法
+
+## Key Concepts
+- [[Webhook]]：网络钩子，一种服务器间实时推送数据的机制；Telegram Bot API 使用 Webhook 模式而非轮询来接收消息
+- [[Telegram Trigger]]：n8n 平台中用于接收 Telegram 机器人消息并触发工作流的节点
+- [[WEBHOOK_URL]]：n8n 环境变量，指定 n8n 实例的对外 HTTPS 访问地址，用于生成 Telegram Webhook URL
+
+## Key Entities
+- [[n8n]]：开源工作流自动化平台，支持通过 Trigger 节点监听外部事件（如 Telegram 消息）
+- [[Telegram]]：即时通讯平台，提供 Bot API，支持 Webhook 推送消息
+- [[Docker Desktop]]：桌面级 Docker 运行环境，在其中运行 n8n 容器时通过环境变量配置 WEBHOOK_URL
+
+## Connections
+- [[n8n Docker 安装与更新]] ← extends ← [[n8n configure telegram trigger]]（本文为 n8n Docker 部署的 Telegram 集成补充）
+- [[Webhook]] ← used_by ← [[Telegram Trigger]]（Webhook 机制是 Telegram Trigger 的底层通信方式）
+
+## Contradictions
+- 无已知冲突

wiki/sources/n8n-docker-install-update.md

@@ -1,54 +1,49 @@
----
-title: "n8n Docker 安装与更新"
-type: source
-tags: [docker, n8n, workflow, 自动化]
-sources: []
-last_updated: 2025-12-30
----
-
-## Source File
-- [[Agent/n8n docker install & update]]
-
-## Summary（用中文描述）
-- **核心主题**：n8n 工作流自动化平台的 Docker 容器化部署与配置，包括网络代理设置和版本更新流程
-- **问题域**：在家庭服务器环境中通过 Docker 部署 n8n，并解决容器内访问国外 API 的网络代理问题
-- **方法/机制**：
-  - 自定义 Dockerfile 扩展官方 n8n 镜像（安装 curl/wget 工具）
-  - Docker Compose YAML 配置 HTTPS、反向代理环境变量
-  - 通过 `ALL_PROXY` 环境变量配置容器内 SOCKS5 代理，使 n8n 节点可访问国外服务
-  - 使用 `docker compose pull && down && up -d` 流程更新版本
-- **结论/价值**：提供一套完整的 n8n Docker 生产级部署方案，包含网络安全代理配置和版本维护脚本
-
-## Key Claims（用中文描述）
-- 宿主机 V2Ray/Tuic 需配置 `0.0.0.0` 监听，并将 SOCKS5 端口（10808）暴露给 Docker 网桥
-- Docker 容器内通过 `ALL_PROXY=socks5://172.21.0.1:10808` 环境变量使所有出站流量走代理
-- Docker 网桥网关 IP（`docker network inspect n8n_default` 查看 Gateway）需替换实际值
-- `N8N_TRUST_PROXY=true` 配合 Caddy 反向代理实现真实客户端 IP 传递
-- 更新 n8n 版本只需 `docker compose pull && docker compose down && docker compose up -d`
-
-## Key Quotes
-> "注意：`172.21.0.1` 需替换为以下命令输出的网桥 IP（Gateway）。`docker network inspect n8n_default`" — 容器内访问宿主机代理的关键网络配置说明
-
-> "配置容器内网络代理" — n8n 节点（如 HTTP Request）访问国外 API 的核心机制
-
-## Key Concepts
-- [[Docker网络网关IP]]：Docker 容器内访问宿主机服务的网关地址，自定义网络如 `172.21.0.1`
-- [[SOCKS5代理]]：通过 SOCKS5 协议转发 HTTP/HTTPS 流量的代理机制，`ALL_PROXY` 环境变量启用
-- [[环境变量代理]]：通过 `HTTP_PROXY/HTTPS_PROXY/ALL_PROXY` 环境变量让程序走代理
-- [[Caddy反向代理]]：`N8N_TRUST_PROXY=true` 使 n8n 获取真实客户端 IP
-- [[Docker卷]]：n8n 数据持久化卷 `n8n_data`，挂载至 `/home/node/.n8n`
-- [[Docker Compose]]：声明式定义 n8n 服务的 YAML 配置文件
-
-## Key Entities
-- [[n8n]]：开源工作流自动化平台，支持可视化编排和 API 集成
-- [[Docker]]：容器化运行时，n8n 的部署底座
-- [[V2Ray/Tuic]]：宿主机运行的代理客户端，提供 SOCKS5 服务
-
-## Connections
-- [[n8n]] ← 部署方式 ← [[Docker]]
-- [[n8n]] ← 网络代理 ← [[SOCKS5代理]]
-- [[SOCKS5代理]] ← 运行于 ← [[Docker网络网关IP]]
-- [[n8n configure telegram trigger]] ← 相关配置 ← [[n8n]]
-
-## Contradictions
-- 无已知冲突
+---
+title: "n8n Docker install & update"
+type: source
+tags: [n8n, docker, workflow]
+date: 2026-04-22
+---
+
+## Source File
+- [[Agent/n8n docker install & update.md]]
+
+## Summary（用中文描述）
+- 核心主题：n8n 工作流自动化平台的 Docker 容器化部署、网络代理配置与版本更新
+- 问题域：如何在 Linux 服务器上通过 Docker Compose 部署 n8n，并配置容器内网络代理实现科学上网
+- 方法/机制：通过自定义 Dockerfile 扩展官方镜像安装 curl/wget 工具；设置 `ALL_PROXY=socks5://宿主机Docker网桥IP:10808` 环境变量使容器流量走 SOCKS5 代理；配置 Caddy 反向代理提供 HTTPS 访问
+- 结论/价值：实现 n8n 容器在受限网络环境下的完整部署，支持通过域名访问 Web UI 和接收 Telegram 等外部服务的 Webhook 回调
+
+## Key Claims（用中文描述）
+- n8n Docker 容器内通过 SOCKS5 代理（V2Ray/Tuic）实现科学上网，代理地址为宿主机 Docker 网桥 IP + 端口 10808
+- `ALL_PROXY` 环境变量控制容器内 HTTP/HTTPS 流量走指定 SOCKS5 代理
+- 端口 5678 映射到宿主机，配合 Caddy 反向代理提供外部 HTTPS 访问
+- Docker 网络 `n8n_default` 由 docker-compose 自动创建，需确保宿主机防火墙允许 Docker 网桥访问代理端口 10808
+- 更新 n8n 版本：进入目录 → `docker compose pull` → `docker compose down` → `docker compose up -d`
+
+## Key Quotes
+> "Docker network inspect n8n_default" — 查看 Docker 网桥 Gateway IP，用于配置 `ALL_PROXY` 地址
+
+> "注意：`172.21.0.1` 需替换为以下命令输出的网桥 IP（Gateway）" — 强调网桥 IP 因环境而异
+
+> "Telegram 要求 Webhook URL 必须是 HTTPS 协议，HTTP 或空值均无法注册" — 来自 [[n8n-configure-telegram-trigger]]
+
+## Key Concepts
+- [[Docker Compose]]：定义和运行多容器 Docker 应用的工具，通过 `docker-compose.yml` 配置 n8n 服务
+- [[SOCKS5 代理]]：一种网络代理协议，n8n 容器通过 `ALL_PROXY=socks5://...` 环境变量配置容器内流量走代理
+- [[Docker 网桥网络]]：Docker 为每个自定义网络分配的内部网桥 IP，容器可通过该 IP 访问宿主机服务
+- [[反向代理]]：Caddy 作为反向代理，将外部 HTTPS 请求转发到本地 5678 端口的 n8n 服务
+
+## Key Entities
+- [[n8n]]：开源工作流自动化平台，本文档详细说明其 Docker 容器化部署配置
+- [[Docker]]：容器化平台，用于运行 n8n 及其依赖服务
+- [[V2Ray/Tuic]]：SOCKS5 代理服务，运行在宿主机端口 10808，为 n8n 容器提供科学上网能力
+- [[Caddy]]：自动 HTTPS 的反向代理服务器，将外部 HTTPS 请求转发到 n8n Web UI
+
+## Connections
+- [[n8n-configure-telegram-trigger]] ← extends ← [[n8n Docker 安装与更新]]（本文档提供 n8n Docker 基础部署，Telegram Trigger 是在此基础上的集成配置）
+- [[n8n-workflow-orchestration]] ← depends_on ← [[n8n Docker 安装与更新]]（Docker 部署是工作流编排的基础设施）
+- [[openclaw-n8n-stack]] ← extends ← [[n8n Docker 安装与更新]]（openclaw-n8n-stack 是社区维护的 Docker Compose 堆栈，扩展了本文档的单容器部署模式）
+
+## Contradictions
+- 无已知冲突

wiki/sources/obsidian-tasks-插件-这可能是最适合懒人的任务管理方式.md

@@ -1,46 +1,50 @@
----
-title: "Obsidian Tasks 插件：这可能是最适合懒人的任务管理方式"
-type: source
-tags: []
-date: 2025-03-13
-last_updated: 2026-04-22
----
-
-## Source File
-- [[raw/Others/Obsidian Tasks 插件：这可能是最适合懒人的任务管理方式.md]]
-
-## Summary（用中文描述）
-- 核心主题：Obsidian Tasks 插件将任务管理无缝整合进笔记工作流，解决「笔记+任务割裂」的核心痛点
-- 问题域：个人知识管理与任务管理的工具整合；Notion/Todoist 等独立任务管理工具与笔记软件之间的割裂问题
-- 方法/机制：通过 Markdown 任务语法（`- [ ]`）创建任务，支持日期/优先级/标签/重复任务，并通过代码块查询（`tasks` 代码块）在任意笔记中嵌入动态任务列表
-- 结论/价值：Tasks 插件让 Obsidian 用户实现「笔记即任务、任务即笔记」的统一工作流，适合已深度使用 Obsidian 的个人用户；不适合需要视觉化界面或团队协作的场景
-
-## Key Claims（用中文描述）
-- Obsidian Tasks 插件通过统一的 Markdown 语法，将任务管理与笔记记录合二为一，消除工具切换带来的割裂感
-- Tasks 插件的任务查询功能（`tasks` 代码块）比 Notion 数据库更灵活，可嵌入任意笔记的上下文中，实现「在笔记里直接看到当前最重要的任务」
-- 重复任务（`⏳ every week/month`）功能让周期性任务自动化，彻底解放手动更新日期的重复劳动
-- Tasks 插件适合已深度使用 Obsidian 的个人用户，不适合习惯 Trello/Things 视觉化看板、需要团队协作、或依赖手机端快速添加任务的场景
-
-## Key Quotes
-> "- [ ] 撰写公众号文章 📅 2025-03-03 🔼 #高优先级" — 简洁的 Markdown 任务语法，一行搞定时间+优先级+标签
-> "Tasks 最让我惊喜的，是它的查询功能……这种灵活性，让我的任务管理变得更自然，不再是'打开 Todoist → 找到任务 → 处理任务'，而是'在笔记的上下文里，直接看到当前最重要的任务'" — 任务查询嵌入笔记上下文的体验描述
-> "Tasks 插件确实强大，但它不是完美的……更适合已经习惯 Obsidian 工作流的人" — 作者对插件适用场景的客观评价
-
-## Key Concepts
-- [[Obsidian Tasks]]：Obsidian 的任务管理插件，通过 Markdown 语法（`- [ ]`）创建任务，支持日期、优先级、标签、重复任务，并通过代码块查询（`tasks` 代码块）在任意笔记中嵌入动态任务筛选视图
-- [[Task Query]]：Tasks 插件的查询语法，通过 `tasks` 代码块定义筛选条件（`not done`/`due before tomorrow`/`sort by priority` 等），在笔记任意位置嵌入动态任务列表
-- [[Recurring Task]]：重复任务机制，使用 `⏳ every week`/`⏳ every month` 等语法自动创建周期性新任务，避免手动复制粘贴更新日期
-
-## Key Entities
-- [[shenwei]]：本文作者，长期 Obsidian 用户，分享从 Notion/Todoist 迁移到 Obsidian Tasks 插件的个人经验
-
-## Connections
-- [[Obsidian 高效指南：我常用的插件与实用技巧]] ← mentions → [[Obsidian Tasks]]
-- [[Dataview]] ← complements → [[Obsidian Tasks]]（Dataview 提供笔记索引，Tasks 提供任务管理，共同构成 Obsidian 知识管理双核心）
-- [[Todoist]] ← compared_with → [[Obsidian Tasks]]（Todoist 是独立任务管理工具，Tasks 将任务整合进笔记；作者认为 Tasks 更适合 Obsidian 深度用户）
-
-## Contradictions
-- 与 [[Todoist]] 冲突：
-  - 冲突点：任务管理工具的整合度 vs 专业化
-  - 当前观点（本文）：Tasks 插件将任务整合进笔记，消除工具切换，适合 Obsidian 深度用户
-  - 对方观点：Todoist 作为独立任务管理工具，提供更专业的功能（更好的移动端体验、团队协作、可视化看板），适合需要独立任务管理系统的用户
+---
+title: "Obsidian Tasks 插件：这可能是最适合懒人的任务管理方式"
+type: source
+tags: []
+date: 2025-03-13
+---
+
+## Source File
+- [[raw/Others/Obsidian Tasks 插件：这可能是最适合懒人的任务管理方式.md]]
+
+## Summary（用中文描述）
+- 核心主题：Obsidian Tasks 插件如何将任务管理与笔记系统深度整合，实现"笔记即任务"的融合体验
+- 问题域：任务管理工具（Notion、Todoist）与笔记工具之间的割裂问题，以及用户在不同工具间频繁切换导致的效率损耗
+- 方法/机制：通过 Markdown 语法创建任务（`- [ ]`）、强大的查询语法（`tasks` 代码块）、重复任务自动生成来替代传统待办应用
+- 结论/价值：Tasks 插件让任务和笔记成为一个整体，适合已深度使用 Obsidian 的个人用户，不适合需要视觉化界面或团队协作的场景
+
+## Key Claims（用中文描述）
+- Obsidian Tasks 插件将任务管理与笔记系统深度整合，消除了任务工具与笔记工具之间的割裂感
+- Tasks 插件使用最简单的 Markdown 语法（`- [ ] 任务内容`）创建任务，支持日期、优先级、标签等元数据
+- 任务查询功能允许在任何笔记中嵌入灵活的筛选条件（按截止日期、优先级、状态等），比 Notion 数据库更灵活
+- 重复任务功能（`⏳ every week/month`）自动生成新任务，解放了手动复制粘贴的繁琐操作
+- Tasks 插件不适合喜欢 Trello/Things 等卡片式界面、需团队协作、或依赖手机端快速添加任务的用户
+
+## Key Quotes
+> "在 Obsidian 里记录任务，就像在日记本上列待办事项，难免有点笨拙。但现实是，我的待办事项往往和笔记密不可分" — 作者阐述为何最终选择将任务管理整合进 Obsidian
+> "这个查询可以出现在 Obsidian 的任何笔记里，而不是被局限在一个固定的界面中。这种灵活性，让我的任务管理变得更自然" — 描述 Tasks 查询功能的独特优势
+> "Tasks 插件不仅帮我省下了任务管理的精力，还让我更容易进入深度工作状态，因为所有的信息都在一个地方，不再被割裂" — 总结 Tasks 插件带来的核心价值
+
+## Key Concepts
+- [[TaskQuerySyntax]]：Tasks 插件的查询语法，支持在代码块中用自然语言描述筛选条件（如 `not done`、`due before tomorrow`、`sort by priority`），可嵌入任意笔记
+- [[ObsidianRecurringTasks]]：重复任务机制，支持 `⏳ every week` / `⏳ every month` 等指令自动生成下一个周期任务，无需手动复制
+- [[MarkdownBasedTask]]：基于 Markdown 语法的任务管理方式，用 `- [ ]` 标记任务，语法最小化，元数据（日期、优先级、标签）内联其中
+- [[ContextDrivenTask]]：上下文驱动的任务管理，将任务放在相关笔记的上下文中，而非孤立的任务列表中，保留决策背景和参考资料
+
+## Key Entities
+- [[Obsidian]]：笔记软件，Tasks 插件的宿主平台，文章主角的深度使用工具
+- [[Todoist]]：被作者放弃的传统待办事项应用，Tasks 插件的对标竞品
+- [[Notion]]：被提及的另一任务管理工具，作者曾用其在 Notion 和 Obsidian 之间来回切换
+
+## Connections
+- [[Obsidian]] ← uses ← [[ObsidianTasksPlugin]]（插件寄生于 Obsidian，提供任务管理能力）
+- [[ObsidianTasksPlugin]] ← replaces ← [[Todoist]]（作者用 Tasks 替代了 Todoist 进行任务管理）
+- [[ObsidianTasksPlugin]] ← integrates_with ← [[Obsidian]]（任务与笔记天然整合在同一知识库中）
+- [[ObsidianTasksPlugin]] ← compared_with ← [[Notion]]（查询功能比 Notion 数据库更灵活）
+
+## Contradictions
+- 与 [[Todoist]] 的任务管理理念冲突：
+  - 冲突点：Todoist 主张任务与笔记分离，各司其职；Tasks 插件主张任务与笔记合一
+  - 当前观点（Tasks 插件）：待办事项往往与笔记密不可分，分离反而造成割裂和效率损耗
+  - 对方观点（Todoist）：专业任务管理需要独立的界面和操作逻辑，与笔记混合会降低任务处理效率

wiki/sources/obsidian最有必要安装的10款插件是这些.md

@@ -1,65 +1,58 @@
----
-title: "Obsidian最有必要安装的10款插件是这些"
-type: source
-tags: [obsidian, 插件, 知识管理]
-sources: []
-last_updated: 2025-03-04
----
-
-## Source File
-- [[raw/Others/Obsidian最有必要安装的10款插件是这些.md]]
-
-## Summary（用中文描述）
-- 核心主题：Obsidian 最核心、最必要的 10 款插件推荐
-- 问题域：Obsidian 上千款插件中，哪些最值得安装
-- 方法/机制：作者试用近 100 种高下载量插件后，按功能分类为 4 组：核心生产力（必装）、效率增强（按需）、信息可视化（辅助）、便利性（可选）
-- 结论/价值：Dataview + Templater 必装，其余按工作流需求组合；可形成"知识管理流""任务管理流""学习研究流"三种典型组合
-
-## Key Claims（用中文描述）
-- Obsidian 有上千款插件，但真正有必要安装的不超过 10 款，甚至在特殊情况下只需 2-3 款
-- Templater 插件通过动态模板语法和脚本，显著提升笔记创建效率
-- Dataview 通过类 SQL 查询语言，使跨笔记的动态筛选、排序和展示成为可能
-- Spaced Repetition 插件将间隔重复学习方法内置于 Obsidian，无需依赖外部工具（如 Anki）
-- Kanban + Projects 组合可实现复杂的任务与项目管理
-- Dataview 和 DB Folder 功能高度重叠但各有侧重，可二选一或结合使用
-- 核心插件组合：知识管理流（Dataview + Templater + Calendar）、任务管理流（Kanban + Projects + Outliner）、学习研究流（Spaced Repetition + DB Folder）
-
-## Key Quotes
-> "人不可能都去了解，时间成本也非常高，因此，尽早去确定最有必要安装的插件才是最高效的" — 插件选择策略
-> "在尝试了快近100种高下载量插件，经过深度使用总结后发现，其实有必要安装的不过如下10款插件" — 推荐依据
-
-## Key Concepts
-- [[间隔重复]]: Spaced Repetition 插件实现的学习方法，通过定时复习提升记忆效果
-- [[看板]]: Kanban 插件提供的可视化任务管理视图
-- [[动态模板]]: Templater 插件支持的模板变量和脚本注入能力
-
-## Key Entities
-- [[Obsidian]]: 笔记软件平台，所有 10 款插件的宿主
-- [[Templater]]: 动态模板插件，支持复杂模板语法和脚本
-- [[Dataview]]: 类 SQL 查询插件，跨笔记动态视图
-- [[Spaced Repetition]]: 间隔重复插件，内置记忆复习功能
-- [[Kanban]]: 看板视图插件，可视化任务管理
-- [[Projects]]: 多项目管理插件，项目级视图
-- [[Outliner]]: 大纲视图插件，分层笔记管理
-- [[Calendar]]: 日历视图插件，日记和时间管理
-- [[DB Folder]]: 数据库化笔记插件，结构化数据管理
-- [[Homepage]]: 启动主页插件，固定工作空间
-- [[File Explorer Note Count]]: 文件计数插件，文件夹笔记数量统计
-
-## Connections
-- [[Obsidian]] ← provides_platform ← [[Templater]], [[Dataview]], [[Spaced Repetition]], [[Kanban]], [[Projects]], [[Outliner]], [[Calendar]], [[DB Folder]], [[Homepage]], [[File Explorer Note Count]]
-- [[知识管理]] ← enables ← [[Dataview]] + [[Templater]] + [[Calendar]]
-- [[任务管理]] ← enables ← [[Kanban]] + [[Projects]] + [[Outliner]]
-- [[学习研究]] ← enables ← [[Spaced Repetition]] + [[DB Folder]]
-- [[Dataview]] ← competes_with ← [[DB Folder]]（可二选一或结合）
-- [[Homepage]] ← depends_on ← [[Calendar]]（每日工作台组合）
-
-## Contradictions
-- 与 [[obsidian-高效指南-我常用的插件与实用技巧]] 冲突：
-  - 冲突点：插件推荐范围不同
-  - 当前观点：本文主张"最少插件优先"，推荐 10 款（部分可选），极简场景仅 2-3 款
-  - 对方观点：另一篇主张更广泛的插件生态探索
-- 与 [[obsidian-必装-skills]] 冲突：
-  - 冲突点：Obsidian 插件 vs Skills 的侧重点
-  - 当前观点：聚焦原生插件组合
-  - 对方观点：侧重 Obsidian Skills 生态
+---
+title: "Obsidian最有必要安装的10款插件是这些"
+type: source
+tags: []
+date: 2025-03-04
+---
+
+## Source File
+- [[Others/Obsidian最有必要安装的10款插件是这些.md]]
+
+## Summary（用中文描述）
+- 核心主题：Obsidian 最核心、最必要的 10 款插件精选与组合使用建议
+- 问题域：面对上千款插件的时间成本，选择最值得安装的核心插件
+- 方法/机制：作者经过近 100 种高下载量插件深度使用后，总结出 10 款按功能分类的必备插件
+- 结论/价值：聚焦核心插件（2-3 款即可），其余按需选择，将精力集中在写作本身
+
+## Key Claims（用中文描述）
+- Obsidian 上千款插件中，真正有必要安装的不过 10 款，部分场景仅需 2-3 款
+- Templater 通过动态模板语法和脚本实现笔记自动化创建，减少重复劳动
+- Dataview 以类 SQL 查询语言实现跨笔记动态视图，大幅增强信息检索能力
+- Spaced Repetition 将间隔重复学习方法内置于 Obsidian，无需手动导出至 Anki
+- Kanban 提供可视化看板，将任务管理从纯文本升级为图形化工作流
+- Calendar 提供日历视图，实现日记和时间线笔记的快速访问
+- DB Folder 将笔记转化为数据库结构，与 Dataview 形成互补（二选一或结合）
+- 三大推荐组合：知识管理流（Dataview+Templater+Calendar）、任务管理流（Kanban+Projects+Outliner）、学习研究流（Spaced Repetition+DB Folder）
+
+## Key Quotes
+> "虽然 Obsidian 有上千款插件可以拓展，各种神奇绚丽的功能可以挖掘探索，但是，人不可能都去了解，时间成本也非常高，因此，尽早去确定最有必要安装的插件才是最高效的。" — 插件选择原则
+> "Dataview 是 Obsidian 的一款超级插件，它允许用户通过类似 SQL 的查询语言在笔记间创建动态视图。" — Dataview 定位
+> "与 Kanban 配合使用更高效。" — Projects 插件补充说明
+> "与 Dataview 二选一，或结合使用更高效。" — DB Folder 与 Dataview 关系
+
+## Key Concepts
+- [[间隔重复]]：基于科学遗忘曲线定期复习知识点的学习方法，Spaced Repetition 插件将其内置于 Obsidian
+- [[看板管理]]：Kanban 插件将任务按阶段（待办/进行中/已完成）可视化呈现的工作流管理方式
+- [[动态模板]]：Templater 插件支持复杂模板语法和脚本，自动填充日期、标签等变量
+- [[知识管理流]]：Dataview + Templater + Calendar 三插件组合，实现笔记自动化记录与检索
+- [[任务管理流]]：Kanban + Projects + Outliner 三插件组合，实现复杂任务拆解与执行
+- [[学习研究流]]：Spaced Repetition + DB Folder 组合，实现知识记忆与结构化存储
+
+## Key Entities
+- [[Obsidian]]：本地优先双链笔记软件，插件生态是核心扩展能力
+- [[Notion]]：被提及作为笔记工具对比——Notion 适合团队协作，Obsidian 适合个人深度知识管理
+- [[Anki]]：被提及作为间隔重复替代方案——Anki 需导出数据，操作繁琐
+
+## Connections
+- [[ObsidianTasksPlugin]] ← complements ← [[Obsidian最有必要安装的10款插件是这些]]（Tasks 插件未在 10 款列表中，但与 Dataview/Kanban 互补）
+- [[Obsidian高效指南]] ← related_to ← [[Obsidian最有必要安装的10款插件是这些]]（同主题深度使用指南）
+
+## Contradictions
+- 与 [[ObsidianTasksPlugin]] 相比：
+  - 冲突点：本文档 10 款插件列表中未包含 Obsidian Tasks 插件
+  - 当前观点：推荐 Dataview（类 SQL 查询）和 Kanban（看板视图）作为任务管理方案
+  - 对方观点：Obsidian Tasks 插件使用原生 Markdown 语法（`- [ ]`）管理任务，任务与笔记融为一体，无需学习专门语法；推荐 Dataview + Kanban 的方案适合需要复杂查询和可视化看板的场景，而 Obsidian Tasks 适合追求"笔记即任务"理念的用户
+- 与 [[Notion]] Entity 页面对比：
+  - 冲突点：Notion 本身提供看板视图（Board），而 Obsidian 需 Kanban 插件实现类似功能
+  - 当前观点：Obsidian 通过插件组合（Kanban+Projects）可实现不逊于 Notion 的任务管理能力
+  - 对方观点：Notion 内置看板无需安装配置，开箱即用，但灵活性受限于 Notion 的数据库结构

wiki/sources/tiktok-pm-python-django-project.md

@@ -1,56 +1,66 @@
----
-title: "TikTok PM - Python Django 项目"
-type: source
-tags: [django, python, tiktok, mysql, mariadb, docker, bright-data]
-date: 2025-11-24
----
-
-## Source File
-- [[raw/Others/TikTok PM - Python Django Project.md]]
-
-## Summary（用中文描述）
-- 核心主题：TikTok Shop 产品数据管理系统的完整 Django Web 应用开发教程
-- 问题域：电商产品数据抓取、存储、管理与可视化分析
-- 方法/机制：Django ORM + MySQL + Django REST Framework + Docker 容器化部署 + Bright Data API 异步数据抓取
-- 结论/价值：提供从零构建 TikTok 电商产品管理系统的完整技术方案，含 Admin 后台、API 接口、Docker 生产部署、异步任务队列
-
-## Key Claims（用中文描述）
-- Django Admin 可通过富文本编辑器（django-tinymce）、自定义视图、内联关联模型实现复杂产品管理界面
-- Django REST Framework + django-filter 可快速构建支持快速搜索和多条件过滤的 RESTful API，供 n8n 等自动化工具调用
-- Docker + Gunicorn + Nginx 容器化部署方案可实现零停机版本更新和快速回滚
-- Django-Q 异步任务队列可处理 Bright Data 异步 API 调用，实现不阻塞 Web 请求的产品数据抓取与导入
-- 自定义 Management Command 可将 JSON 文件批量导入逻辑封装为 `python manage.py import_json_data` 命令
-
-## Key Quotes
-> "无论修改字段类型、添加新字段，还是像您这样修改字段约束（例如从非空改为可空 null=True），都必须遵循这两步流程：makemigrations + migrate" — Django 数据库迁移最佳实践
-
-> "原子性部署：docker compose up --build -d 确保了所有依赖项和配置都会在新镜像中构建好，如果构建失败，旧服务不会受到影响" — Docker 生产部署最佳实践
-
-## Key Concepts
-- [[Django ORM]]：通过 Python 类定义数据库表结构，Django 自动生成 SQL 并管理迁移
-- [[Django REST Framework]]：构建 RESTful API 的 Django 第三方框架，支持序列化器、视图集、过滤和搜索
-- [[Docker 容器化部署]]：使用 Dockerfile + docker-compose.yml 实现应用容器化，结合 Gunicorn + Nginx 进行生产部署
-- [[Django Admin 定制]]：通过 fieldsets、inlines、readonly_fields、list_display 等实现复杂管理界面
-- [[Django-Q 异步任务]]：Django 异步任务队列，用于处理耗时的外部 API 调用
-- [[Bright Data API]]：第三方数据抓取服务，支持异步请求模式，适合大规模产品数据采集
-- [[MySQL/MariaDB 数据库]]：项目使用 MySQL/MariaDB 作为后端数据库，存储 TikTok 产品数据
-
-## Key Entities
-- [[TikTok Shop]]：电商平台，数据来源
-- [[Django]]：Python Web 框架
-- [[Bright Data]]：第三方数据抓取 API 提供商
-- [[MySQL / MariaDB]]：关系型数据库
-- [[Docker]]：容器化平台
-- [[Gunicorn]]：Python WSGI HTTP 服务器
-- [[Nginx]]：反向代理和静态文件服务
-- [[n8n]]：自动化工作流工具（通过 REST API 集成）
-
-## Connections
-- [[Django REST Framework]] ← builds_on ← [[Django ORM]]
-- [[Docker 容器化部署]] ← extends ← [[Gunicorn]] + [[Nginx]]
-- [[Django-Q 异步任务]] ← used_by ← [[Bright Data API]]
-- [[MySQL / MariaDB]] ← stores ← TikTok 产品数据
-
-## Contradictions
-- 暂无发现与其他 Wiki 页面的冲突
-
+---
+title: "TikTok PM - Python Django 项目"
+type: source
+tags: [django, python, tiktok, mysql, mariadb, docker, bright-data, django-q, product-management]
+date: 2025-11-24
+last_updated: 2026-05-12
+---
+
+## Source File
+- [[raw/Others/TikTok PM - Python Django Project.md]]
+
+## Summary（用中文描述）
+- 核心主题：TikTok Shop 产品数据管理系统的完整 Django Web 应用开发教程
+- 问题域：电商产品数据抓取、存储、管理与可视化分析
+- 方法/机制：Django ORM + MySQL + Django REST Framework + Docker 容器化部署 + Bright Data API 异步数据抓取 + Django-Q 任务队列
+- 结论/价值：提供从零构建 TikTok 电商产品管理系统的完整技术方案，含 Admin 后台（富文本/缩略图/模态框）、REST API、Docker 生产部署、异步任务队列、JSON 批量导入管理命令
+
+## Key Claims（用中文描述）
+- Django Admin 可通过 django-tinymce 富文本编辑器、自定义 Admin 视图、内联关联模型（ProductImage/ProductVideo/ProductVariation/ProductReview）实现复杂产品管理界面
+- Admin 列表页可通过自定义方法显示产品缩略图，并通过 django.jQuery + 模态框 CSS/JS 实现点击放大功能
+- Django REST Framework + django-filter 可快速构建支持快速搜索和多条件过滤的 RESTful API，供 n8n 等自动化工具调用
+- Docker + Gunicorn + Nginx 容器化部署方案通过 `docker compose up --build -d` 实现原子性部署和零停机版本更新
+- Django-Q 异步任务队列可处理 Bright Data 异步 API 调用，实现不阻塞 Web 请求的产品数据抓取与导入
+- 自定义 Django Management Command 可将 JSON 文件批量导入逻辑封装为 `python manage.py import_json_data` 命令
+- 自定义 Admin 视图可通过 `get_urls()` 注册自定义路由，并通过面包屑导航融入 Admin 体系
+
+## Key Quotes
+> "无论修改字段类型、添加新字段，还是像您这样修改字段约束（例如从非空改为可空 null=True），都必须遵循这两步流程：makemigrations + migrate" — Django 数据库迁移最佳实践
+
+> "原子性部署：docker compose up --build -d 确保了所有依赖项和配置都会在新镜像中构建好，如果构建失败，旧服务不会受到影响" — Docker 生产部署最佳实践
+
+> "自定义管理命令可以将 importer_wrapper.py 包装成 python manage.py import_json_data 的形式执行手动导入 JSON 文件" — Django Management Command 最佳实践
+
+## Key Concepts
+- [[Django ORM]]：通过 Python 类定义数据库表结构，Django 自动生成 SQL 并管理迁移
+- [[Django REST Framework]]：构建 RESTful API 的 Django 第三方框架，支持序列化器、视图集、过滤和搜索
+- [[Docker 容器化部署]]：使用 Dockerfile + docker-compose.yml 实现应用容器化，结合 Gunicorn + Nginx 进行生产部署
+- [[Django Admin 定制]]：通过 fieldsets、inlines、readonly_fields、list_display、自定义视图实现复杂管理界面
+- [[Django-Q 异步任务]]：Django 异步任务队列，用于处理耗时的外部 API 调用
+- [[Bright Data API]]：第三方数据抓取服务，支持异步请求模式，适合大规模产品数据采集
+- [[MySQL / MariaDB 数据库]]：项目使用 MySQL/MariaDB 作为后端数据库，存储 TikTok 产品数据
+- [[Django Management Command]]：自定义 Django 命令行工具，将 Python 脚本封装为 manage.py 子命令
+- [[Django Admin 自定义视图]]：通过 get_urls() 注册自定义视图页面，融入 Admin 导航体系
+
+## Key Entities
+- [[TikTok Shop]]：电商平台，数据来源
+- [[Django]]：Python Web 框架
+- [[Bright Data]]：第三方数据抓取 API 提供商
+- [[MySQL / MariaDB]]：关系型数据库
+- [[Docker]]：容器化平台
+- [[Gunicorn]]：Python WSGI HTTP 服务器
+- [[Nginx]]：反向代理和静态文件服务
+- [[n8n]]：自动化工作流工具（通过 REST API 集成）
+- [[Django-Q]]：Django 异步任务队列
+- [[Django TinyMCE]]：Django 富文本编辑器集成
+
+## Connections
+- [[Django REST Framework]] ← builds_on ← [[Django ORM]]
+- [[Docker 容器化部署]] ← extends ← [[Gunicorn]] + [[Nginx]]
+- [[Django-Q 异步任务]] ← used_by ← [[Bright Data API]]
+- [[Django Admin 自定义视图]] ← part_of ← [[Django Admin 定制]]
+- [[Django Management Command]] ← wraps ← JSON 数据导入逻辑
+- [[MySQL / MariaDB]] ← stores ← TikTok 产品数据
+
+## Contradictions
+- 暂无发现与其他 Wiki 页面的冲突

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

@@ -1,61 +1,53 @@
----
-title: "万字保姆级教程，让你90天跑通一人公司模式（附AI提示词）"
-type: source
-tags: [一人公司, 个人品牌, 商业变现, AI提示词, 产品体系, 内容营销]
-date: 2026-02-11
----
-
-## Source File
-- [[Agent/万字保姆级教程-90天跑通一人公司模式-2026-03-29.md]]
-
-## Summary（用中文描述）
-
-- **核心主题**：90天内建立一人公司的系统性方法论，通过自我定位、产品设计、内容营销和销售漏斗实现个人商业化
-- **问题域**：个人职业转型、副业创业、一人公司运营
-- **方法/机制**：天才地带自检 → 底层能力挖掘 → 心理陷阱识别 → Ikigai 框架定位 → 赛道验证 → 产品体系设计 → 内容矩阵构建 → 销售漏斗搭建
-- **结论/价值**：一人公司的关键不是更努力工作，而是更聪明地定位；用 AI 杠杆放大个人优势
-
-## Key Claims（用中文描述）
-
-- 一人公司的本质是用最小的杠杆撬动最大的价值，杠杆支点是个人优势
-- 天才地带（Zone of Genius）是能产生心流的区域，时间飞逝、精力充沛
-- 底层能力需要通过"追溯童年、毫不费力、底层通用"三个问题自检
-- 四个心理陷阱（愧疚陷阱、效率陷阱、卓越陷阱、努力陷阱）会困住个人发展
-- Ikigai 是热情、擅长、市场需求、报酬四个维度的交集
-- 产品体系需要四个层级：引流产品（免费）→ 入门产品（¥199）→ 核心产品（¥4999）→ 高价产品（¥20,000/月）
-- 客户需要逐步建立信任，没有人一开始就买最贵的
-
-## Key Quotes
-
-> "一人公司的关键，和你更努力地工作一点关系没有，是更聪明地定位。" — 文章核心观点
-
-> "在你觉得太简单所以不值钱的事情里，在朋友们总是找你帮忙的那个领域里——现在，是时候把它挖掘出来了。" — 结语
-
-## Key Concepts
-
-- [[天才地带（Zone of Genius）]]：能产生心流的区域，时间飞逝，精力充沛，与"不胜任区""胜任区""卓越区"并列
-- [[底层能力]]：隐藏在活动表象下的核心能力，可通过三个自检问题追溯
-- [[四个心理陷阱]]：愧疚陷阱（"我不喜欢别人肯定也不喜欢"）、效率陷阱（"忙=创造价值"）、卓越陷阱（"最厉害的人才能做"）、努力陷阱（"轻松=没价值"）
-- [[Ikigai框架]]：四个圆圈交集——你所热爱的 × 你所擅长的 × 世界所需要的 × 你能获得报酬的
-- [[产品四层级体系]]：引流（免费PDF）→ 入门（¥199工具）→ 核心（¥4999特训营）→ 高价（¥20,000/月咨询）
-- [[内容矩阵]]：核心主题（横轴）× 内容形式（纵轴：观察类、反直觉类、操作指南类、个人故事类、清单类）
-- [[反向金字塔内容法]]：一次长形式内容切成无数微内容，一次制作百次分发
-- [[Build in Public]]：公开构建过程建立信任，AI泛滥时代活人感更重要
-- [[价格锚定]]：高价选项放顶部让低价显得便宜
-- [[诱饵效应]]：三个定价选项引导用户选择中间选项
-
-## Key Entities
-
-- [[盖伊·亨德里克斯]]（Gay Hendricks）：心理学家，提出"天才地带（Zone of Genius）"概念
-
-## Connections
-
-- [[Ikigai框架]] ← 是 ← [[万字保姆级教程-90天跑通一人公司模式]]
-- [[Build in Public]] ← 来源于 ← [[万字保姆级教程-90天跑通一人公司模式]]
-- [[一人公司]] ← 核心概念 ← [[万字保姆级教程-90天跑通一人公司模式]]
-- [[产品体系设计]] ← 来源于 ← [[万字保姆级教程-90天跑通一人公司模式]]
-- [[销售漏斗]] ← 来源于 ← [[万字保姆级教程-90天跑通一人公司模式]]
-
-## Contradictions
-
-- （暂无）
+---
+title: "万字保姆级教程，让你90天跑通\"一人公司\"模式（附AI提示词）"
+type: source
+tags: []
+date: 2026-03-29
+---
+
+## Source File
+- [[Agent/万字保姆级教程-90天跑通一人公司模式-2026-03-29]]
+
+## Summary（用中文描述）
+- 核心主题：如何用 90 天跑通"一人公司"模式——用最小的杠杆撬动最大的价值
+- 问题域：职场人寻找个人定位、突破职业瓶颈、实现商业变现的路径
+- 方法/机制：通过自我体检发现"天才地带"→挖掘底层能力→避开心理陷阱→构建 Ikigai 商业模型→搭建产品体系→用 AI 构建内容系统→搭建销售漏斗
+- 结论/价值：一人公司的关键不是更努力，而是更聪明地定位——在你觉得太简单所以不值钱的事里，在朋友们总是找你帮忙的那个领域里，找到你的 Ikigai
+
+## Key Claims（用中文描述）
+- 一人公司的本质是用最小的杠杆撬动最大的价值，杠杆的支点是个人优势
+- 盖伊·亨德里克斯的"天才地带"理论：将活动分为不胜任区、胜任区、卓越区（最危险）、天才区；真正的独特定位来自天才区
+- 底层能力三个自检问题：追溯童年、毫不费力、底层通用——满足任一条件即为底层能力
+- 四个心理陷阱（愧疚陷阱、效率陷阱、卓越陷阱、努力陷阱）正在阻止人们找到自己的天才区
+- Ikigai 是四个圆圈的交集：你热爱的 × 你擅长的 × 市场需要的 × 能获得报酬的
+- 客户需要逐步建立信任，没有人一开始就买最贵的——产品体系需分层设计
+- 内容生产用"反向金字塔"策略：一次长形式内容切成无数微内容，一次制作百次分发
+- AI 时代，"活人感"比内容本身更重要——Build in Public 公开构建过程建立信任
+
+## Key Quotes
+> "一人公司的关键，和你更努力地工作一点关系没有，是更聪明地定位。" — 核心结论
+> "在你觉得太简单所以不值钱的事情里，在朋友们总是找你帮忙的那个领域里——现在，是时候把它挖掘出来了。" — 行动召唤
+> "让每个人都待在自己的擅长地带。" — 分工的核心原则
+
+## Key Concepts
+- [[Ikigai框架]]: 源自日本的生命意义框架，由四个圆圈交集构成——你所热爱的 × 你所擅长的 × 世界所需要的 × 你能以此获得报酬的。是找到一人公司定位的核心工具
+- [[天才地带]]: 心理学家盖伊·亨德里克斯提出的活动分类区域，指能产生心流、时间飞逝、精力充沛的区域——一人公司的最佳起点
+- [[底层能力]]: 藏在冰山水下的通用能力，通过三个问题识别——追溯童年、毫不费力、底层通用
+- [[心理陷阱]]: 指阻碍个人找到天才区的四个认知偏差——愧疚陷阱、效率陷阱、卓越陷阱、努力陷阱
+- [[产品分层体系]]: 引流产品（免费）→入门产品（低价）→核心产品（高价）→高价咨询的分层定价策略
+- [[反向金字塔内容策略]]: 一次长形式内容切成多个微内容，一次制作百次分发的内容生产方法
+- [[BuildInPublic]]: 公开构建过程，在 AI 泛滥时代用"活人感"建立信任的内容策略
+
+## Key Entities
+- [[盖伊·亨德里克斯]]: 心理学家，"天才地带"概念提出者，将人类活动分为四个区域
+- [[营销人张飞宇]]: 微信公众号作者，本文出处
+
+## Connections
+- [[不谈技术-普通人该怎么在ai时代赚钱]] ← 关联 ← [[万字保姆级教程-90天跑通一人公司模式-2026-03-29]]
+  - 两者都强调 AI 时代个人定位的重要性，都提供找到真正热爱之事的方法论
+  - 本文提供系统性 90 天框架，该文提供思维原则；互补关系
+- [[Ikigai]] ← 是本文核心 ← [[万字保姆级教程-90天跑通一人公司模式-2026-03-29]]
+  - Ikigai 是本文第三步的核心工具，是连接自我认知与商业变现的桥梁
+
+## Contradictions
+- 无明显冲突

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

@@ -1,57 +1,57 @@
----
-title: "万字讲透OpenClaw Workspace深度解析"
-type: source
-tags: [OpenClaw, Agent, Workspace, AGENTS.md, SOUL.md]
-sources: []
-last_updated: 2026-03-21
----
-
-## Source File
-- [[Agent/万字讲透OpenClaw-Workspace深度解析-2026-03-21.md]]
-
-## Summary（用中文描述）
-- 核心主题：OpenClaw 的 workspace 目录体系——让 Agent 从"能用"进化到"真好用"的关键文件架构
-- 问题域：Agent 个性化配置、长期记忆机制、多 Agent 协作时的行为一致性
-- 方法/机制：通过 workspace 目录下的多个 Markdown 文件（AGENTS.md/SOUL.md/USER.md/IDENTITY.md/TOOLS.md/MEMORY.md 等）分别管理职责、性格、用户偏好、身份元数据、工具规范和长期记忆
-- 结论/价值：workspace 文件配合好后，Agent 不再是每次都要重新 onboarding 的陌生人，而是一个真正懂你、记得你、靠谱的长期搭档
-
-## Key Claims（用中文描述）
-- OpenClaw 使用者存在一条隐形分界线：一边每次都要重新交代背景，另一边的 Agent 已知道用户是谁、该怎么说话——这条分界线就是 workspace
-- workspace 管的是"Agent 平时怎么干活"（文件内容），openclaw.json 管的是"系统怎么把 Agent 跑起来"（配置参数），两者职责不同
-- AGENTS.md 是岗位说明书（做什么、怎么做、边界在哪），SOUL.md 是性格档案（是谁、什么风格、怎么思考），两者不应混写
-- 300-500 字的 AGENTS.md 比 2000 字的更有效——边界比能力描述更重要，LLM 默认会"发挥创意"需要约束
-- SOUL.md 定义 Agent 性格，USER.md 定义用户偏好，两者放在一起相当于在 Agent 脑子里预装了"人机关系的基本共识"
-- TOOLS.md 的核心价值是明确"什么时候不该用"比"什么时候该用"更重要，减少工具误用和权限越界
-- 真正算数的长期记忆是 workspace 里那些 Markdown 文件，不是看不见的黑盒数据库——memory/ 目录让 Agent 真正拥有跨会话记忆
-
-## Key Quotes
-> "workspace 是 Agent 的工作台（决定怎么工作），agentDir 是 openclaw.json 里的配置字段（指向存放运行状态的目录），sessions 是工作日志（记对话历史）。三者职责不同，不要混为一谈。" — workspace 全貌区分
-> "AGENTS.md 不是越长越好——300-500 字的 AGENTS.md，比 2000 字的更有效。" — 经验法则
-> "一个没有 SOUL.md 的 Agent，每次对话都像第一次见面——它不记得自己是谁，说话没有固定风格。" — SOUL.md 必要性
-> "对 Agent 来说，真正算数的长期记忆，是 workspace 里那些 Markdown 文件，不是什么看不见摸不着的黑盒数据库。" — 记忆机制核心洞察
-
-## Key Concepts
-- [[Workspace]]：Agent 的工作台目录（~/.openclaw/workspace/），包含 AGENTS.md、SOUL.md、USER.md 等配置文件，决定 Agent 怎么工作
-- [[AGENTS.md]]：Agent 的工作说明书，定义职责、边界、多 Agent 协作流程；300-500 字最优
-- [[SOUL.md]]：Agent 的性格档案，叙事性角色设定文档（与 IDENTITY.md 的结构化元数据分工明确）
-- [[USER.md]]：用户画像与偏好固化，减少每次对话的重复交代
-- [[IDENTITY.md]]：Agent 结构化身份元数据（Name/Creature/Vibe/Emoji/Avatar），与 SOUL.md 叙事分工
-- [[TOOLS.md]]：工具权限声明与使用规范，明确"什么时候不该用"比"什么时候该用"更重要
-- [[BOOTSTRAP.md]]：一次性出厂引导，完成初始化后应删除
-- [[HEARTBEAT.md]]：会话节奏/状态提示的默认模板之一
-- [[MEMORY.md]]：长期知识总表，与 memory/ 日期滚动目录共同构成 Agent 的持久记忆层
-- [[Agent-Memory]]：OpenClaw 通过 builtin 或 qmd 方案，将重要信息写入 memory/ 或 MEMORY.md，下次对话通过 memory_search/memory_get 检索注入上下文
-
-## Key Entities
-- [[OpenClaw]]：本文的核心研究对象，multi-agent 框架，workspace 体系是其从"能用"到"真好用"的分水岭
-- [[DracoVibeCoding]]：公众号"Draco正在VibeCoding"作者，本文原创作者
-
-## Connections
-- [[OpenClaw]] ← uses ← [[Workspace]]
-- [[Workspace]] ← composed of ← [[AGENTS.md]], [[SOUL.md]], [[USER.md]], [[IDENTITY.md]], [[TOOLS.md]], [[MEMORY.md]]
-- [[AGENTS.md]] ← informs ← [[Agent-Specialization]]
-- [[Agent-Memory]] ← built on ← [[Workspace]] + [[MEMORY.md]] + [[memory/目录]]
-
-## Contradictions
-- 无已知冲突
-
+---
+title: "万字讲透OpenClaw Workspace深度解析"
+type: source
+tags: [OpenClaw, Agent, Workspace, AGENTS.md, SOUL.md]
+date: 2026-03-21
+---
+
+## Source File
+- [[Agent/万字讲透OpenClaw-Workspace深度解析-2026-03-21.md]]
+
+## Summary（用中文描述）
+- 核心主题：OpenClaw workspace 文件体系详解，从"能用"到"真好用"的分水岭
+- 问题域：Agent 每次对话都需要重新 onboarding 的痛点，以及 workspace 如何解决长期记忆和行为一致性问题
+- 方法/机制：通过 workspace 目录下的一系列 Markdown 文件（AGENTS.md、SOUL.md、USER.md、IDENTITY.md、TOOLS.md、BOOTSTRAP.md、memory/）实现 Agent 的身份、性格、用户偏好、工具规范的持久化
+- 结论/价值：这套文件体系让 Agent 不再是每次都重新 onboarding 的陌生人，而成为真正懂用户、记得用户、靠谱的长期搭档
+
+## Key Claims（用中文描述）
+- workspace 是"能用"到"真好用"的分界线：通过持久化文件让 Agent 记住上下文、偏好和积累的知识
+- AGENTS.md 是岗位说明书：定义 Agent 做什么、怎么做、优先级，以及多 Agent 协作方式；300-500 字比 2000 字更有效
+- SOUL.md 定义 Agent 的性格叙事：与 AGENTS.md 分工明确，前者偏功能性，后者偏人格性，两者不应混写
+- USER.md 固化用户偏好：把反复要交代的背景信息沉淀为默认背景，减少重复 onboarding
+- TOOLS.md 规范工具使用：明确什么时候该用、什么时候不该用，降低权限越界风险
+- IDENTITY.md 是结构化身份档案：与 SOUL.md 分工明确，前者管元数据（名字/emoji/头像），后者管性格叙事
+- BOOTSTRAP.md 是一次性引导：使命是把新 workspace 引导到可用状态，完成后应删除
+- memory/ 目录是 Agent 真正的长期记忆：LLM 对话无状态，通过文件工具读写 memory/ 目录实现跨会话记忆
+
+## Key Quotes
+> "workspace 是 Agent 的工作台（决定怎么工作），agentDir 是 openclaw.json 里的配置字段（指向存放运行状态的目录），sessions 是工作日志（记对话历史）。三者职责不同，不要混为一谈。" — workspace、agentDir、sessions 的职责区分
+> "AGENTS.md 不是越长越好。300-500 字的 AGENTS.md，比 2000 字的更有效。" — AGENTS.md 最佳实践
+> "对 Agent 来说，真正算数的长期记忆，是 workspace 里那些 Markdown 文件，不是什么看不见摸不着的黑盒数据库。" — 记忆机制的核心原则
+> "BOOTSTRAP.md 的使命，是把一个全新的 workspace 引导到可正常使用的状态。" — BOOTSTRAP.md 的作用
+> "Delete this file. You don't need a bootstrap script anymore — you're you now." — BOOTSTRAP.md 官方模板结尾
+
+## Key Concepts
+- [[OpenClaw Workspace]]：OpenClaw 的 Agent 工作区目录，包含 AGENTS.md、SOUL.md、USER.md 等文件
+- [[AGENTS.md]]：Agent 的行为规则与多 Agent 协调文件，定义职责、边界和优先级
+- [[SOUL.md]]：Agent 的叙事性格设定文件，定义 Agent 的说话风格、价值观和个性
+- [[USER.md]]：用户画像与偏好文件，把用户的偏好固化下来减少重复交代
+- [[IDENTITY.md]]：Agent 身份元数据文件（名字/emoji/头像），与 SOUL.md 分工明确
+- [[TOOLS.md]]：工具权限声明与使用规范文件，减少工具误用和权限越界
+- [[BOOTSTRAP.md]]：首次启动引导文件，完成初始化后应删除
+- [[memory目录]]：按日期滚动的记忆笔记目录，实现 Agent 的跨会话长期记忆
+- [[bootstrapMaxChars]]：控制 AGENTS.md 等文件加载长度的配置参数
+- [[AgentDir]]：openclaw.json 中的配置字段，指向存放运行状态（auth-profiles.json、models.json）的目录
+- [[Sessions目录]]：会话历史目录，存放 *.jsonl 文件
+
+## Key Entities
+- [[DracoVibeCoding]]：本文作者，公众号"Draco正在VibeCoding"
+- [[OpenClaw]]：开源 AI Agent 框架，workspace 是其核心特性之一
+
+## Connections
+- [[养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录]] ← relates_to ← [[万字讲透openclaw-workspace深度解析-2026-03-21]]
+- [[Google 5个 Agent Skill 设计模式]] ← extends ← [[万字讲透openclaw-workspace深度解析-2026-03-21]]
+- [[系统提示词构建原则]] ← extends ← [[万字讲透openclaw-workspace深度解析-2026-03-21]]
+
+## Contradictions
+- 暂无发现冲突内容

wiki/sources/使用claude自动生成n8n工作流的实操教程.md

@@ -1,52 +1,49 @@
----
-title: "使用Claude自动生成N8N工作流的实操教程"
-type: source
-tags: []
-date: 2025-12-31
----
-
-## Source File
-- [[Agent/使用Claude自动生成N8N工作流的实操教程.md]]
-
-## Summary（用中文描述）
-- 核心主题：如何借助 AI 助手 Claude 自动创建 N8N 工作流，解决新手在架构设计和节点选择中的困惑。
-- 问题域：N8N 工作流自动化工具的使用门槛高，新手不知如何设计工作流架构和选择节点。
-- 方法/机制：通过安装 n8n-mcp（Model Context Protocol 多功能控制面板），将 Claude 与 N8N 连接，用自然语言描述需求，Claude 自动选择节点、编写代码、生成完整工作流。
-- 结论/价值：Claude 可完成约 80%-90% 的工作流设计和编码，显著降低学习门槛，适合无编码基础的 N8N 初学者，但仍需人工二次修正。
-
-## Key Claims（用中文描述）
-- n8n-mcp 通过提供 543 个 n8n nodes、节点属性 99% 覆盖、节点操作 63.6% 覆盖，使 Claude 能理解并生成 N8N 工作流。
-- Claude 使用 OpenSea 模型并开启 Extended Thinking 模式后，代码生成效果更优。
-- Claude 自动生成工作流的完成度约 80%-90%，仍有 10%-20% 的错误率需要人工修正。
-- 自然语言驱动的 N8N 工作流自动化，显著降低新手学习门槛和制作时间。
-
-## Key Quotes
-> "通过此方法，特别是缺乏编程基础的新手能快速搭建功能复杂的自动化流程，大幅提升效率。" — 教程总结
-
-> "Claude能实现约80%-90%正确的工作流布局和逻辑，尽管有细节错误仍需人工二次修正，但对新手尤其友好，显著降低学习门槛和工作时间。" — 优缺点分析
-
-## Key Concepts
-- [[N8N]]：开源工作流自动化工具，支持节点连接执行任务，由多个节点按顺序执行的自动化流程组成。
-- [[MCP（Model Context Protocol）]]：N8N 的多功能控制面板协议，允许外部工具（如 Claude）调用 N8N 所有节点，实现自动工作流创建。
-- [[Extended Thinking]]：Claude 的一种运行模式，支持更深层次逻辑推理，提升代码生成质量。
-- [[工作流自动化]]：通过自然语言指令让 AI 自动设计和搭建自动化流程的技术方法。
-- [[Node.js]]：n8n-mcp 的运行环境，需先安装 Node.js 才能启动 MCP 服务。
-- [[API Key]]：用于认证访问 N8N 服务的密钥，保证接口调用的安全。
-
-## Key Entities
-- [[n8n-mcp]]：开源 MCP 项目（czlonkowski/n8n-mcp），作为 Claude 与 N8N 之间的桥梁，支持 543 个节点、87% 官方文档覆盖。
-- [[Claude]]：Anthropic AI 助手，可通过 MCP 扩展调用 N8N 节点能力，自动生成工作流。
-- [[Node.js]]：JavaScript 运行时环境，n8n-mcp 的运行依赖。
-
-## Connections
-- [[Claude]] ← uses ← [[n8n-mcp]]
-- [[Claude]] ← uses ← [[Node.js]]（运行环境）
-- [[n8n-mcp]] ← provides nodes to ← [[N8N Workflow]]
-- [[Claude]] ← configured with ← [[API Key]]
-- [[Claude]] ← optimized by ← [[Extended Thinking]]
-
-## Contradictions
-- 与传统手工搭建 N8N 工作流对比：
-  - 冲突点：手工搭建强调用户自主设计每个节点，AI 辅助强调自然语言生成。
-  - 当前观点：AI 自动生成可大幅降低门槛，但存在 10%-20% 错误率需人工修正。
-  - 对方观点：手工搭建可精确控制每个细节，但学习成本高、耗时长。
+---
+title: "使用Claude自动生成N8N工作流的实操教程"
+type: source
+tags: []
+date: 2026-04-26
+---
+
+## Source File
+- [[Agent/使用Claude自动生成N8N工作流的实操教程.md]]
+
+## Summary（用中文描述）
+- 核心主题：利用 Claude AI 助手结合 n8n-mcp 项目，通过自然语言自动生成 N8N 工作流，降低新手入门门槛
+- 问题域：N8N 工作流自动化平台的使用与 AI 辅助开发
+- 方法/机制：安装 n8n-mcp MCP 服务器 → 配置 Claude Desktop 连接 → 导入高级 Prompt → 输入自然语言指令 → Claude 自动选节点、写代码、生成工作流
+- 结论/价值：Claude 可自动完成约 80-90% 的工作流布局和逻辑，但仍需人工二次修正；显著降低 N8N 学习成本，适合无编码基础的新手
+
+## Key Claims（用中文描述）
+- n8n-mcp 项目作为桥梁，让 AI 模型能够理解和操作 n8n 节点，提供 543 个 n8n 节点、271 个 AI 能力节点、2709 个工作流模板的完整覆盖
+- Claude Desktop 通过 Developer 配置连接 n8n-mcp 服务后，可自动寻找节点、编写代码、生成完整工作流
+- 使用 Opensea 模型 + Extended Thinking 模式可获得更好的代码生成效果
+- Claude 自动生成的工作流完成度约 80-90%，有 10-20% 的细节错误需要人工修正
+
+## Key Quotes
+> "n8n-MCP serves as a bridge between n8n's workflow automation platform and AI models, enabling them to understand and work with n8n nodes effectively." — n8n-mcp 官方介绍
+> "Claude能实现约80%-90%正确的工作流布局和逻辑，尽管有细节错误仍需人工二次修正，但对新手尤其友好，显著降低学习门槛和工作时间。" — 教程作者总结
+
+## Key Concepts
+- [[N8N]]：开源的工作流自动化工具，支持节点连接执行各种自动化任务
+- [[MCP]]：Model Context Protocol，多功能控制面板协议，允许外部工具调用 n8n 所有节点功能
+- [[Extended Thinking]]：Claude 的深度推理模式，支持更深层次的逻辑推理，提升代码生成质量
+- [[工作流自动化]]：通过预先定义的流程自动执行重复性任务，减少人工操作
+
+## Key Entities
+- [[n8n-mcp]]：n8n-mcp 开源项目（https://github.com/czlonkowski/n8n-mcp），将 n8n 节点能力暴露给 AI 模型使用
+- [[Claude]]：Anthropic 开发的 AI 助手，可读取指令并自动生成代码或工作流
+- [[OpenSea 模型]]：为代码生成优化的 Claude 子模型，适合自动编程任务
+- [[Node.js]]：n8n-mcp 的运行时环境，需先安装 Node.js 才能运行 npx n8n-mcp
+
+## Connections
+- [[Claude]] ← uses ← [[n8n-mcp]]
+- [[n8n-mcp]] ← provides_node_access ← [[N8N]]
+- [[OpenSea 模型]] ← improves ← [[Claude]]
+- [[Extended Thinking]] ← enhances ← [[Claude]]
+
+## Contradictions
+- 与 [[n8n-claude-通过自然语言自动化工作流]] 可能的交叉验证：
+  - 冲突点：两篇文档均介绍 Claude + n8n 自动化，但侧重点和实现细节可能存在差异
+  - 当前观点：本教程强调 n8n-mcp 的完整功能覆盖和 80-90% 自动生成完成度
+  - 对方观点：另一篇文档可能有不同的配置路径或效果评估