Auto-sync: 2026-04-16 17:30
This commit is contained in:
@@ -1,78 +0,0 @@
|
||||
---
|
||||
title: "14个免费的AI图生视频工具，用AI让图片动起来"
|
||||
type: source
|
||||
tags: [ai, image-to-video]
|
||||
date: 2025-12-05
|
||||
sources: ["https://www.51juzd.com/23332.html"]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/14个免费的AI图生视频工具，用AI让图片动起来 - AI视频教程 AI自动化工作流定制服务 AI培训学习平台 黑喵大叔.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：14款免费AI图生视频工具盘点，涵盖产品功能、技术特点、应用场景
|
||||
- 问题域：AI驱动静态图片转化为动态视频，降低视频创作门槛
|
||||
- 方法/机制：深度学习图像理解、运动生成、风格迁移、一致性保持
|
||||
- 结论/价值：免费工具已可生成高质量视频，覆盖电商模特、内容创作、广告制作等多场景
|
||||
|
||||
## Key Claims
|
||||
- 绘蛙AI视频（阿里巴巴）：简化视频制作流程，无需专业视频编辑技能，支持高分辨率图片上传和多格式处理
|
||||
- 智谱清影（智谱AI）：30秒内生成6秒1440×960高清视频，支持图像解析、细节填充与动画效果
|
||||
- 通义万相（阿里巴巴）：通过提示词精准控制视频运动，实现大幅度主体运动和运镜控制
|
||||
- Vidu（生数科技+清华大学）：全球首个"多主体参考"功能，突破视频模型一致性生成难题，10秒生成一段视频
|
||||
- 可灵AI（快手）：基于3D时空联合注意力机制，生成符合物理逻辑的复杂动作，高分辨率1080p输出
|
||||
- 海螺AI（MiniMax）：主体参考保持形象一致性，MiniMax视频模型确保光影和色调高度一致
|
||||
- 即梦AI（字节跳动）：支持首尾帧精准掌控，多参数自定义（运镜控制、运动速度、视频比例等）
|
||||
- PixVerse（爱诗科技）：支持角色一致性识别，多种视频风格（真实、动漫、3D动画）
|
||||
- Video Ocean（潞晨科技）：指令响应驱动图片动态化，V2.0在画质、运动幅度和风格多样性上显著提升
|
||||
- Stable Video（Stability AI）：提供多样化相机动作选项（轨道运动、推拉镜头等），支持LoRA摄像机控制
|
||||
- 万相营造（阿里妈妈）：高度还原原图，精准理解长文本复杂提示词，适用于电商营销场景
|
||||
- Viva（智象未来）：免费产品中质量最高，支持6种运镜方式和运动强度定制
|
||||
- Haiper：操作便捷，支持2秒或4秒视频生成，分辨率1280×720，免费无限使用
|
||||
- 艺映AI（MewXAI团队）：运动笔刷工具选择动态化部分，支持手机和电脑多平台账号同步
|
||||
|
||||
## Key Quotes
|
||||
> "在当今这个信息爆炸、视觉内容为王的时代，视频已成为人们传递信息、表达创意、娱乐消遣的首选方式之一。" — 文章开篇背景
|
||||
|
||||
## Key Concepts
|
||||
- [[图生视频]]：将静态图片通过AI技术转化为动态视频的核心AI任务
|
||||
- [[主体一致性]]：在视频生成过程中保持人物/角色外观一致性的技术能力
|
||||
- [[运动控制]]：通过文本提示词控制视频中主体运动方向和动作的技术
|
||||
- [[运镜控制]]：模拟摄像机运动（推拉、轨道、旋转等）来控制视频画面视角的技术
|
||||
- [[风格迁移]]：将图像内容转换为不同艺术风格（卡通、油画、电影感等）的技术
|
||||
|
||||
## Key Entities
|
||||
- [[阿里巴巴集团]]：旗下有绘蛙AI视频、通义万相、万相营造等产品
|
||||
- [[智谱AI]]：推出智谱清影图生视频工具
|
||||
- [[生数科技]]：联合清华大学发布Vidu视频大模型
|
||||
- [[快手]]：推出可灵AI图生视频平台
|
||||
- [[MiniMax]]：推出海螺AI视频生成工具
|
||||
- [[字节跳动]]：旗下有一站式AI创意创作平台即梦AI
|
||||
- [[爱诗科技]]：开发PixVerse AI视频生成工具
|
||||
- [[潞晨科技]]：推出Video Ocean多功能AI视频生成平台
|
||||
- [[Stability AI]]：推出Stable Video视频生成平台
|
||||
- [[阿里妈妈]]：推出万相营造AI电商营销工具
|
||||
- [[智象未来]]：推出Viva免费AI创意视觉生成平台
|
||||
- [[MewXAI团队]]：推出艺映AI多功能AI视频创作工具
|
||||
|
||||
## Connections
|
||||
- [[阿里巴巴集团]] ← 发布 → [[绘蛙AI视频]]
|
||||
- [[阿里巴巴集团]] ← 发布 → [[通义万相]]
|
||||
- [[智谱AI]] ← 发布 → [[智谱清影]]
|
||||
- [[生数科技]] + [[清华大学]] ← 发布 → [[Vidu]]
|
||||
- [[快手]] ← 发布 → [[可灵AI]]
|
||||
- [[MiniMax]] ← 发布 → [[海螺AI]]
|
||||
- [[字节跳动]] ← 发布 → [[即梦AI]]
|
||||
- [[爱诗科技]] ← 发布 → [[PixVerse]]
|
||||
- [[潞晨科技]] ← 发布 → [[Video Ocean]]
|
||||
- [[Stability AI]] ← 发布 → [[Stable Video]]
|
||||
- [[阿里妈妈]] ← 发布 → [[万相营造]]
|
||||
- [[智象未来]] ← 发布 → [[Viva]]
|
||||
- [[MewXAI团队]] ← 发布 → [[艺映AI]]
|
||||
- [[图生视频]] ← 包含 → [[主体一致性]]
|
||||
- [[图生视频]] ← 包含 → [[运动控制]]
|
||||
- [[图生视频]] ← 包含 → [[运镜控制]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无冲突记录
|
||||
@@ -1,71 +0,0 @@
|
||||
---
|
||||
title: "2025年11个神级AI开源平替，GitHub杀疯了"
|
||||
type: source
|
||||
tags: [AI, 开源, GitHub]
|
||||
date: 2026-01-01
|
||||
sources:
|
||||
- "2025 年 11 个神级 AI 开源平替，GitHub 杀疯了"
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/2025 年 11 个神级 AI 开源平替，GitHub 杀疯了。.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：2025年AI开源生态中的顶级替代方案
|
||||
- 问题域：AI大模型、生图、生视频、智能体、编程、工作流、搜索、知识库
|
||||
- 方法/机制：盘点GitHub上各领域最火的国产开源项目
|
||||
- 结论/价值：国产开源AI在多个领域已具备与国际闭源产品竞争的能力
|
||||
|
||||
## Key Claims
|
||||
- DeepSeek R1是开源界首个将o1级深度推理拉下神坛的破壁者
|
||||
- Qwen 3是最稳、最全、最能打的开源基座模型
|
||||
- Flux是目前人体解剖学最正确的开源AI生图模型
|
||||
- Stable Diffusion的LoRA和ControlNet生态依然最丰富
|
||||
- HunyuanVideo是开源界参数量最大的视频生成模型之一
|
||||
- OpenManus核心逻辑为规划->执行->循环反馈
|
||||
- Cline是Cursor的最佳开源平替
|
||||
- n8n有16万Star，是功能更强的开源版Zapier
|
||||
- Perplexica完全开源免费，支持本地化部署
|
||||
|
||||
## Key Quotes
|
||||
> "DeepSeek R1的爆火拉开了中国通过开源策略与国外AI巨头差异化竞争的叙事" — 核心观点
|
||||
> "Qwen 3凭借全尺寸覆盖和极致的工具调用能力，堪称开源界的六边形战士" — 评价
|
||||
> "Flux是开源界的Midjourney，出自前SD核心团队之手" — 来源说明
|
||||
|
||||
## Key Concepts
|
||||
- [[大语言模型]]：AI一切能力的基石，2025年实现深度推理与开源内卷
|
||||
- [[AI生图]]：Flux和Stable Diffusion主导开源生态
|
||||
- [[AI生视频]]：HunyuanVideo代表开源最高水平
|
||||
- [[通用智能体]]：Manus定义AI Agent元年
|
||||
- [[AI编程]]：Cline等工具将编辑器变身全自动AI工程师
|
||||
- [[智能体工作流]]：n8n和Dify实现可视化AI流程编排
|
||||
- [[AI搜索]]：Perplexica实现完全本地化的AI搜索助理
|
||||
- [[AI知识库]]：NotebookLM开创双人播客学习模式
|
||||
|
||||
## Key Entities
|
||||
- [[DeepSeek]]：国产大模型公司，发布R1和V3
|
||||
- [[Qwen]]：阿里通义千问，全尺寸覆盖的开源模型
|
||||
- [[Flux]]：前SD核心团队开发的AI生图模型
|
||||
- [[Stable Diffusion]]：老牌开源AI生图模型
|
||||
- [[HunyuanVideo]]：腾讯混元视频，开源视频生成模型
|
||||
- [[Manus]]：定义AI Agent元年的产品
|
||||
- [[OpenManus]]：Manus的开源替代
|
||||
- [[Cline]]：VS Code生态的AI编程插件
|
||||
- [[n8n]]：拖拽式工作流自动化平台
|
||||
- [[Dify]]：LLM应用开发平台
|
||||
- [[Perplexica]]：开源AI搜索引擎
|
||||
- [[NotebookLM]]：Google AI知识库工具
|
||||
|
||||
## Connections
|
||||
- [[DeepSeek]] ← 开源平替 ← [[OpenAI]]
|
||||
- [[Qwen]] ← 开源平替 ← [[Claude]]
|
||||
- [[Flux]] ← 开源平替 ← [[Midjourney]]
|
||||
- [[HunyuanVideo]] ← 开源平替 ← [[Veo 3]]
|
||||
- [[OpenManus]] ← 开源平替 ← [[Manus]]
|
||||
- [[Cline]] ← 开源平替 ← [[Cursor]]
|
||||
- [[Perplexica]] ← 开源平替 ← [[Perplexity]]
|
||||
- [[Dify]] ← 竞争 ← [[LangChain]]
|
||||
- [[n8n]] ← 竞争 ← [[Zapier]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
title: "2025 年 11 个神级 AI 开源平替，GitHub 杀疯了"
|
||||
type: source
|
||||
tags: [AI, 开源, GitHub, LLM, AI生图, AI生视频, AI智能体]
|
||||
date: 2026-01-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/2025 年 11 个神级 AI 开源平替，GitHub 杀疯了。.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：2025 年 GitHub 热门 AI 开源项目盘点，覆盖 11 个细分领域
|
||||
- 问题域：寻找闭源 AI 产品的开源替代方案
|
||||
- 方法/机制：按领域分类横向对比，每个领域推荐 1-2 个最具代表性的开源项目
|
||||
- 结论/价值：国产开源模型（DeepSeek/Qwen）在 LLM 赛道已领先；Flux 在 AI 生图人体解剖学最正确；HunyuanVideo 是开源最大参数量视频生成模型
|
||||
|
||||
## Key Claims
|
||||
|
||||
### LLM（大语言模型）
|
||||
- DeepSeek R1：开源首个 o1 级深度推理模型，差异化竞争破壁者
|
||||
- Qwen 3：全尺寸覆盖 + 极致工具调用，开源界六边形战士
|
||||
- 智谱 GLM、Kimi K2、MiniMax 构成国产第二梯队
|
||||
|
||||
### AI 生图
|
||||
- Flux：前 SD 核心团队出品，人体解剖学最正确的开源模型，指尖细节超过 Midjourney
|
||||
- Stable Diffusion 3.5：LoRA/ControlNet 生态最丰富，特定角色/姿势控制首选
|
||||
|
||||
### AI 生视频
|
||||
- HunyuanVideo（混元视频）：开源界参数量最大视频生成模型，中文 Prompt 理解天花板，动作连贯性强
|
||||
|
||||
### 通用智能体
|
||||
- OpenManus：Manus 开源平替，5 万 Star，规划→执行→循环反馈，Browser-use/Playwright 驱动
|
||||
|
||||
### AI Coding
|
||||
- Cline：VS Code 最强开源自主编程插件，MCP 扩展，敏感操作需用户授权
|
||||
|
||||
### 智能体工作流
|
||||
- n8n：16 万 Star，拖拽节点自动化，LangChain 节点集成，私有部署开源版 Zapier
|
||||
- Dify：LLM 应用开发平台，可视化知识库机器人搭建
|
||||
|
||||
### AI 搜索
|
||||
- Perplexica：2.8K Star，Perplexity 开源平替，SearXNG 搜索源，支持本地大模型
|
||||
|
||||
## Key Concepts
|
||||
- [[开源平替]]：以开源项目替代闭源商业产品的策略
|
||||
- [[HunyuanVideo]]：腾讯混元视频，开源最大参数量视频生成模型
|
||||
- [[OpenManus]]：通用智能体开源方案，规划-执行-反馈循环
|
||||
- [[Cline]]：VS Code AI 编程插件，Cursor 开源平替
|
||||
- [[Perplexica]]：AI 搜索引擎开源实现，SearXNG + 本地 LLM
|
||||
|
||||
## Key Entities
|
||||
- [[DeepSeek]]：国产开源 LLM 代表，R1 深度推理模型
|
||||
- [[Qwen]]：阿里通义千问，开源六边形战士
|
||||
- [[Flux]]：AI 生图开源模型，人体解剖学最正确
|
||||
- [[n8n]]：工作流自动化开源平台，16 万 Star
|
||||
- [[Dify]]：LLM 应用开发平台
|
||||
- [[Manus]]：AI Agent 领域里程碑产品，2025 年现象级应用
|
||||
|
||||
## Connections
|
||||
- [[DeepSeek]] ← 同类竞争 ← [[Qwen]]
|
||||
- [[n8n]] ← 功能重叠 ← [[Dify]]
|
||||
- [[OpenManus]] ← 对标 ← [[Manus]]
|
||||
- [[Cline]] ← 功能重叠 ← [[Cursor]]
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
title: "3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！"
|
||||
type: source
|
||||
tags: [claude, skills, anthropic, workflow, prompt-engineering]
|
||||
date: 2026-01-08
|
||||
sources:
|
||||
- "3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ 1.md"
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ 1.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：Claude Skills 作为 AI 应用的新范式，代表从提示词工程向流程工程的转型
|
||||
- 问题域：大多数 AI 用户还在纠结如何写好 Prompt，而高阶玩家已开始构建可复用的 Skills
|
||||
- 方法/机制：Skills = 写给 Claude 的"说明书" + SOP（标准作业程序），将固定流程任务拆解为 AI 可理解、可稳定复用、可自动执行的流程
|
||||
- 结论/价值：Skills 的爆发标志从提示词工程迈向流程工程；未来有价值的不是谁的 Prompt 写得最花，而是谁最懂业务流程、谁能将经验沉淀为 SOP
|
||||
|
||||
## Key Claims
|
||||
- Skills 本质是"说明书"和"SOP"：将反复执行、有固定流程的任务拆解为 AI 能理解、稳定复用、自动执行的流程
|
||||
- Anthropic 官方 Skills 仓库（github.com/anthropics/skills）收藏数突破 3.2 万，原封不动地拆解了 Claude.ai 网页版的生产级能力
|
||||
- 官方库覆盖三大类：办公自动化（Word/PDF/PPT/Excel）、开发者工具箱（MCP Server、Web 测试、Artifacts、自动化验证）、创意类 Skills
|
||||
- 三个 Awesome-Claude-Skills 精选仓库：ComposioHQ、VoltAgent、BehiSecc
|
||||
- 三个 Skill 聚合站：skillsmp.com、aitmpl.com/skills、claudemarketplaces.com
|
||||
- Skills 的本质是官方在教"怎么像 Anthropic 一样开发 AI 应用"
|
||||
|
||||
## Key Quotes
|
||||
> "Skills 就是一套你写给 Claude 的'说明书'和'SOP（标准作业程序）'" — 核心定义
|
||||
> "这个库本质上是官方在教你，'怎么像我们一样开发 AI 应用'" — 价值定位
|
||||
> "未来真正有价值的，不是谁的 Prompt 写得最花、谁一次能生成最多内容；而是谁最懂业务流程、谁能把经验沉淀成 SOP、谁能把 SOP 交给 AI 稳定执行" — 趋势判断
|
||||
|
||||
## Key Concepts
|
||||
- [[AI技能封装]]：将固定流程任务拆解为 AI 可理解、可复用、可自动执行的结构化流程的方法论
|
||||
- [[Prompt工程]] → [[流程工程]]：从优化单次输出质量转向优化整套流程的稳定性与可复用性
|
||||
- [[Claude Skills]]：Anthropic 官方发布的 AI 技能指南，本质是"说明书 + SOP"
|
||||
|
||||
## Key Entities
|
||||
- [[Anthropic]]：Claude Skills 官方仓库的发布者
|
||||
- [[Anthropic Skills 官方库]]：github.com/anthropics/skills，3.2 万收藏，生产级能力拆解
|
||||
- [[ComposioHQ/awesome-claude-skills]]：精选 Claude Skills 仓库
|
||||
- [[VoltAgent/awesome-claude-skills]]：精选 Claude Skills 仓库
|
||||
- [[BehiSecc/awesome-claude-skills]]：精选 Claude Skills 仓库
|
||||
- [[skillsmp.com]]：Skill 聚合站
|
||||
- [[aitmpl.com/skills]]：Skill 聚合站
|
||||
- [[claudemarketplaces.com]]：Skill 聚合站
|
||||
|
||||
## Connections
|
||||
- [[Anthropic]] ← 发布者 ← [[Anthropic Skills 官方库]]
|
||||
- [[Anthropic Skills 官方库]] ← 官方示例 ← [[Claude Skills]]
|
||||
- [[Claude Skills]] ← 范式升级 ← [[Prompt工程]]
|
||||
- [[Claude Skills]] ← 具体实现 ← [[AI技能封装]]
|
||||
- [[skillsmp.com]] ← 聚合平台 ← [[Claude Skills]]
|
||||
- [[aitmpl.com/skills]] ← 聚合平台 ← [[Claude Skills]]
|
||||
- [[claudemarketplaces.com]] ← 聚合平台 ← [[Claude Skills]]
|
||||
- [[Vibe Coding]] ← 尽头是 ← [[Claude Skills]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
title: "3.2万人收藏的Claude Skills，才是AI这条路最值得研究的一套范式"
|
||||
type: source
|
||||
tags: [ai, claude-skills, vibe-coding]
|
||||
date: 2026-01-05
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Claude Skills 从"提示词工程"到"流程工程"的范式转移，Skills = 说明书 + SOP，将人类经验封装为可复用工作流
|
||||
- 问题域：AI 应用层如何构建可规模化的技能复用体系
|
||||
- 方法/机制：Skills 通过结构化流程描述实现 AI 稳定执行，Anthropic 官方仓库 github.com/anthropics/skills 收藏数突破 3.2 万
|
||||
- 结论/价值：真正有价值的不是 Prompt 写得多花哨，而是谁最懂业务流程、谁能将 SOP 交给 AI 稳定执行
|
||||
|
||||
## Key Claims
|
||||
- Anthropic 官方 Skills 仓库 github.com/anthropics/skills 收藏数突破 3.2 万，本质上是官方在教"怎么像他们一样开发 AI 应用"
|
||||
- Skills = 说明书 + SOP，将人类经验封装为可复用工作流，核心是流程而非提示词
|
||||
- Vibe Coding 的尽头也是 Skills，最终竞争在于业务流程理解和 SOP 沉淀能力
|
||||
- 三大 Awesome 仓库（ComposioHQ/VoltAgent/BehiSecc）系统性整理了 LLM Skills 工作流，覆盖文档处理、开发工具、数据分析、内容创作等类别
|
||||
- 三大聚合站（skillsmp.com/aitmpl.com/claudemarketplaces.com）提供拿来即用的 Skills 集，适合快速选型和二次改造
|
||||
|
||||
## Key Quotes
|
||||
> "Skills 就是一套你写给 Claude 的'说明书'和'SOP（标准作业程序）'" — 痕小子/开源星探
|
||||
> "这个库本质上是官方在教你，'怎么像我们一样开发 AI 应用'" — 痕小子/开源星探
|
||||
> "Vibe Coding 的尽头，也是 Skills" — 痕小子/开源星探
|
||||
|
||||
## Key Concepts
|
||||
- [[Claude Skills]]：将固定流程任务拆解为 AI 可理解的结构化流程，包含 Prompt 结构、参数含义、容错策略
|
||||
- [[流程工程]]：将经验沉淀为 SOP 再交给 AI 稳定执行的新范式
|
||||
- [[提示词工程]]：通过优化单次 Prompt 输出质量，与流程工程（可复用工作流）形成对比
|
||||
|
||||
## Key Entities
|
||||
- [[Anthropic]]：Claude Skills 官方仓库发布方，github.com/anthropics/skills
|
||||
- [[ComposioHQ]]：Awesome-Claude-Skills 仓库维护者，覆盖文档处理/数据分析/内容创作/生产力工具
|
||||
- [[VoltAgent]]：Awesome-Claude-Skills 仓库维护者
|
||||
- [[BehiSecc]]：Awesome-Claude-Skills 仓库维护者
|
||||
- [[skillsmp.com]]：Skills 聚合站，支持分类和搜索
|
||||
- [[aitmpl.com]]：Skills 聚合站
|
||||
- [[claudemarketplaces.com]]：Skills 聚合站
|
||||
|
||||
## Connections
|
||||
- [[Claude-Skills研究范式]] ← depends_on ← [[Anthropic]]（官方仓库）
|
||||
- [[流程工程]] ← extends ← [[提示词工程]]
|
||||
- [[Vibe-Coding]] ← depends_on ← [[Claude Skills]]
|
||||
- [[skillsmp.com]] ← same_as ← [[aitmpl.com]] ← same_as ← [[claudemarketplaces.com]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统"优化单次 Prompt"思路不同：Skills 强调流程复用而非单次输出质量最大化
|
||||
@@ -1,81 +0,0 @@
|
||||
---
|
||||
title: "3X-UI Xray on BandwagonVPS"
|
||||
type: source
|
||||
tags: [vps, xray, 3x-ui, vpn, proxy]
|
||||
date: 2026-02-10
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/3X-UI Xray on BandwagonVPS]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：在 Bandwagon VPS 上安装配置 3X-UI 面板管理 Xray 代理服务
|
||||
- 问题域：自建代理节点，VLESS+Reality 协议配置
|
||||
- 方法/机制：一键安装脚本 + Web 管理界面 + 多平台客户端
|
||||
- 结论/价值：获得自管理的代理节点，支持 VLESS+Reality 加密传输
|
||||
|
||||
## Key Claims
|
||||
- 3X-UI 提供一键安装脚本，简化 Xray 部署流程
|
||||
- VLESS+Reality 协议提供更安全的代理传输
|
||||
- 支持多平台客户端（Windows/Linux v2rayN、Android v2rayNG）
|
||||
- BBR 加速可提升网络传输性能
|
||||
|
||||
## Key Quotes
|
||||
> "使用 VLESS+Reality 方式配置，需要产生公钥和私钥" — 配置策略说明
|
||||
|
||||
## Key Concepts
|
||||
- [[BBR]]：TCP BBR 拥塞控制算法，通过 3X-UI 选项 23 启用
|
||||
- [[VLESS+Reality]]：Xray 支持的加密代理协议
|
||||
- [[SSL Certificate]]：通过 3X-UI 选项 18/19 管理证书
|
||||
|
||||
## Key Entities
|
||||
- [[Bandwagon]]：VPS 主机服务商，提供 VPS2 服务器
|
||||
- [[VPS2]]：Bandwagon 机房的具体 VPS 实例，IP 104.194.92.188
|
||||
- [[3X-UI]]：Xray 面板管理脚本，简化代理服务配置
|
||||
- [[Xray]]：核心代理软件，支持多种代理协议
|
||||
- [[v2rayN]]：Windows/Linux 代理客户端
|
||||
- [[v2rayNG]]：Android 代理客户端
|
||||
|
||||
## Connections
|
||||
- [[Bandwagon]] ← hosts ← [[VPS2]]
|
||||
- [[VPS2]] ← runs ← [[3X-UI]]
|
||||
- [[3X-UI]] ← manages ← [[Xray]]
|
||||
- [[Xray]] ← accepts ← [[VLESS+Reality]]
|
||||
- [[v2rayN]] ← connects_to ← [[Xray]]
|
||||
- [[v2rayNG]] ← connects_to ← [[Xray]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
|
||||
## Server Information
|
||||
|
||||
| 项目 | 值 |
|
||||
|------|-----|
|
||||
| 服务器 | VPS2 (Bandwagon) |
|
||||
| IP | 104.194.92.188 |
|
||||
| 域名 | kiwi.ishenwei.online |
|
||||
| SSH | `ssh vps2` |
|
||||
| Web管理 | https://kiwi.ishenwei.online:2053/ |
|
||||
| 用户名 | d96nRBgFUL |
|
||||
| 密码 | er9XU0VsF1 |
|
||||
|
||||
## 3X-UI Management Options
|
||||
|
||||
| 选项 | 功能 |
|
||||
|------|------|
|
||||
| 1 | 安装 |
|
||||
| 11 | 启动 |
|
||||
| 12 | 停止 |
|
||||
| 13 | 重启 |
|
||||
| 14 | 查看状态 |
|
||||
| 16 | 启用自启动 |
|
||||
| 18 | SSL 证书管理 |
|
||||
| 23 | 启用 BBR |
|
||||
| 24 | 更新 Geo 文件 |
|
||||
|
||||
## Client Download
|
||||
|
||||
| 平台 | 客户端 |
|
||||
|------|--------|
|
||||
| Windows/Linux | v2rayN |
|
||||
| Android | v2rayNG |
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "7 Ways I Use NotebookLM to Make My Life Easier"
|
||||
type: source
|
||||
tags: [notebooklm, google, learning, productivity]
|
||||
date: 2025-11-23
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/7 ways I use NotebookLM to make my life easier]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：NotebookLM 7 种实际应用场景，核心优势是 Source-Grounding（严格限制知识库仅含上传文档）确保回答高精度和可溯源
|
||||
- 问题域：信息过载时代的知识管理和被动学习效率提升
|
||||
- 方法/机制：上传文档 → AI 自动处理 → 交互式问答/Audio Overview → 带引文的精准回答
|
||||
- 结论/价值：NotebookLM 严格限制知识库范围，是处理法律文档、软件更新对比、研究资料等高精度场景的最佳选择
|
||||
|
||||
## Key Claims
|
||||
- Source-Grounding 机制：NotebookLM 知识库仅包含上传文档，消除幻觉，每个答案附带精确引文
|
||||
- 被动学习（Audio Overviews）：将文档转化为双人 AI 对话音频，支持 Brief/Deep Dive/Critique/Debate 等风格定制
|
||||
- 成为即时专家：上传多源资料（Batman/Star Wars/Jupiter/Marine Corps），通过对话快速建立领域认知
|
||||
- 编程辅助：上传官方文档，通过问答定位知识点，替代冗长教程和过时搜索结果
|
||||
- 项目管理：集中所有会议记录、战略文档、链接到单一 Notebook，AI 自动生成结构化路线图
|
||||
- 软件更新对比：同时上传多个版本发布说明，AI 提取差异并列出带引文的变更清单
|
||||
- 法律文档审查：严格基于上传文档回答，避免普通 AI 的幻觉问题，每问必带引文
|
||||
|
||||
## Key Quotes
|
||||
> "NotebookLM's best quality is that it prioritizes accuracy by strictly limiting its knowledge base to only your trusted documents." — How-To Geek
|
||||
> "I no longer hate getting long documents or looking through terms and conditions or legal patents because I can find what I need from a few questions with NotebookLM." — How-To Geek
|
||||
|
||||
## Key Concepts
|
||||
- [[Source-Grounding]]：NotebookLM 核心技术约束，限制回答仅基于上传文档
|
||||
- [[被动学习]]：Audio Overviews 在碎片时间消费复杂信息的机制
|
||||
- [[引文追溯]]：每个答案附带精确引文，点击跳转原文
|
||||
|
||||
## Key Entities
|
||||
- [[NotebookLM]]：Google 推出的 AI 笔记和研究助理工具
|
||||
|
||||
## Connections
|
||||
- [[Source-Grounding]] ← 核心机制 ← [[NotebookLM]]
|
||||
- [[被动学习]] ← 应用场景 ← [[NotebookLM]]
|
||||
- [[引文追溯]] ← 质量保证 ← [[Source-Grounding]]
|
||||
|
||||
## Contradictions
|
||||
- 与通用 AI（Gemini/ChatGPT）相比：通用 AI 知识广泛但容易幻觉，NotebookLM 知识受限但精度极高
|
||||
- 与传统"读完全文再消化"方式相比：NotebookLM 支持通过问答快速提取关键信息，无需完整阅读
|
||||
@@ -1,59 +0,0 @@
|
||||
---
|
||||
title: "递归自优化生成系统的形式化框架"
|
||||
type: source
|
||||
tags: [ai, recursion, self-improvement, formalization, meta-learning]
|
||||
date: 2025-12-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/A Formalization of Recursive Self-Optimizing Generative Systems.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：用数学和 λ 演算对"递归自优化生成系统"进行形式化描述
|
||||
- 问题域：现有自优化 AI 系统缺乏严格的数学刻画，迭代行为无法被预测和分析
|
||||
- 方法/机制：定义生成器空间 $\mathcal{G}$、优化算子 $O$、元生成算子 $M$；通过自映射 $\Phi: \mathcal{G} \to \mathcal{G}$ 建模迭代；证明稳定生成能力对应 $\Phi$ 的不动点
|
||||
- 结论/价值：递归自优化系统的收敛目标是生成器空间的不动点，而非某个具体最优输出；为自改进 AI 和自动元提示工程提供理论基础
|
||||
|
||||
## Key Claims
|
||||
- 传统优化针对输出空间（output space）；递归自优化针对生成器空间（generator space）
|
||||
- 迭代序列 $\{G_n\}$ 的收敛目标是不动点 $G^* = \Phi(G^*)$，代表"生成能力已稳定，无需再优化"
|
||||
- 自引用动力学可表达为：$G^* \equiv Y\;\text{STEP}$，其中 $Y$ 为不动点组合子，$\text{STEP}$ 为单步更新函数
|
||||
- 递归自优化系统的核心三算子：$G$（生成器）、$O$（优化器）、$M$（元生成器）
|
||||
- bootstrap 循环：$\alpha$-提示词（生成器）生成产物 → $\Omega$-提示词（优化器）评价优化 → 元生成器用优化结果更新 $\alpha$-提示词 → 循环迭代
|
||||
- 固定点语义使得系统在每次迭代中同时作为主体和客体出现
|
||||
|
||||
## Key Quotes
|
||||
> "The system generates artifacts, optimizes them with respect to an idealized objective, and uses the optimized artifacts to update its own generative mechanism." — 递归自优化三阶段
|
||||
> "Such a generator is invariant under its own generate–optimize–update cycle." — 不动点生成器的定义
|
||||
> "$G^* \equiv Y\;\text{STEP}$" — λ 演算形式下的稳定生成器定义
|
||||
|
||||
## Key Concepts
|
||||
- [[生成器空间 (Generator Space)]]：所有可能生成器构成的集合 $\mathcal{G} \subseteq \mathcal{P}^{\mathcal{I}}$，每个生成器是将意图映射为提示词/程序/技能的函数
|
||||
- [[自映射 (Self-Map)]]：$\Phi: \mathcal{G} \to \mathcal{G}$，将一个生成器映射为经过一次"生成-优化-更新"循环后的新生成器
|
||||
- [[不动点 (Fixed Point)]]：$G^* = \Phi(G^*)$，满足"在自身循环中不变"的生成器，代表稳定生成能力
|
||||
- [[不动点组合子 (Y-Combinator)]]：λ 演算中实现递归的经典组合子 $\lambda f.(\lambda x.f(x,x))(\lambda x.f(x,x))$
|
||||
- [[递归自优化循环]]：$P = G(I)$ → $P^* = O(P, \Omega)$ → $G' = M(G, P^*)$
|
||||
- [[Bootstrap（自举）]]：系统通过自身产出的更优版本不断改进自身，无需外部干预
|
||||
- [[元生成器 (Meta-Generator)]]：将优化后的产物作为输入，更新生成器本身的算子 $M: \mathcal{G} \times \mathcal{P} \to \mathcal{G}$
|
||||
|
||||
## Key Entities
|
||||
- [[tukuai]]：独立研究者，GitHub: https://github.com/tukuai，论文作者
|
||||
- [[vibe-coding-cn]]：GitHub 项目 vibe-coding-cn，该文档的来源仓库
|
||||
|
||||
## Connections
|
||||
- [[生成器空间 (Generator Space)]] ← defines ← [[递归自优化生成系统]]
|
||||
- [[自映射 (Self-Map)]] ← induces ← [[不动点 (Fixed Point)]]
|
||||
- [[不动点组合子 (Y-Combinator)]] ← implements ← [[递归自优化循环]]
|
||||
- [[Bootstrap（自举）]] ← mechanism_of ← [[递归自优化生成系统]]
|
||||
- [[vibe-coding-cn]] ← source_repo ← [[递归自优化生成系统]]
|
||||
|
||||
## Contradictions
|
||||
- 与单次优化方法（如 PPO、DPO）的区别：单次优化直接在输出空间搜索最优；递归自优化在生成器空间迭代，目标是找到稳定的生成机制而非某一次的最优输出
|
||||
- 与纯强化学习的区别：强化学习优化策略（输出），自优化系统优化生成策略的机制（生成器的结构）
|
||||
|
||||
## Metadata
|
||||
- 作者：tukuai
|
||||
- 创建时间：2025-12-30
|
||||
- 来源：https://github.com/2025Emma/vibe-coding-cn
|
||||
- 原始标签：[]
|
||||
- Category suggestions: `cs.LO`, `cs.AI`, `math.CT`
|
||||
@@ -1,61 +0,0 @@
|
||||
---
|
||||
title: "一语点醒梦中人——东方人生智慧"
|
||||
type: source
|
||||
tags: [chinese-wisdom, daoism, confucianism, buddhism, life-philosophy]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/一语点醒梦中人.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：中国古典哲学与人生修养箴言，涵盖道家/儒家/佛教/禅宗智慧
|
||||
- 问题域：现代人在困境、焦虑、执着中寻找内心平静与处事之道
|
||||
- 方法/机制：以经典引述+释义+背景延伸的结构，解析名言背后的哲学思想
|
||||
- 结论/价值：东方智慧提供"绝处逢生"、"放下执着"、"守拙内敛"的实践路径
|
||||
|
||||
## Key Claims
|
||||
- 王维"行到水穷处，坐看云起时"：人生困境（"水穷处"）与超然觉醒（"云起时"）的辩证关系，仕途挫折促使其转向佛学形成空寂淡泊心境
|
||||
- 曾国藩"唯忘机可以消众机，唯懵懂可以祓不吉祥"：以无争、大智若愚姿态化解官场算计与人生风险
|
||||
- "知其不可奈何而安之若命"（庄子）：区分"可奈何"与"不可奈何"，对无法改变之事安然接受，而非继续内耗
|
||||
- "一切有为法，如梦幻泡影，如露亦如电，应作如是观"（金刚经）：世间一切因缘和合之物皆虚幻短暂，以"空性"智慧观照而不执着
|
||||
- "执一守中，有劳而作，言行意合，自然而行"：融合儒家"执两用中"与道家"守中"，在劳作中体悟，在言行中修心
|
||||
|
||||
## Key Quotes
|
||||
> "知其不可奈何而安之若命，德之至也" — 庄子·内篇·人间世
|
||||
> "大智若愚，大巧若拙" — 老子·第四十五章
|
||||
> "和其光，同其尘" — 老子·第五十六章
|
||||
> "一切有为法，如梦幻泡影，如露亦如电，应作如是观" — 金刚经
|
||||
|
||||
## Key Concepts
|
||||
- [[空性智慧]]：一切因缘和合之物皆无独立不变的自性，不执着于幻象
|
||||
- [[中道智慧]]：避免极端，在动态平衡中守持正道（"执两用中"）
|
||||
- [[绝处逢生]]："水穷处"象征困境，"云起时"象征在放下执着后获得新的可能
|
||||
- [[知其不可奈何而安之若命]]：分辨可控与不可控，对不可控之事保持内心平静
|
||||
- [[忘机]]：忘却世俗机巧，以淳朴自然的心态化解纷扰
|
||||
- [[慎独]]：独处时仍保持行为谨慎不苟（《礼记·中庸》）
|
||||
|
||||
## Key Entities
|
||||
- [[王维]]（诗佛）：唐代诗人，"行到水穷处，坐看云起时"作者，仕途多舛后转向佛学
|
||||
- [[曾国藩]]：清代重臣，"唯忘机可以消众机"出处，结合道家无为与儒家诚心
|
||||
- [[老子]]：道家创始人，"大智若拙"/"和光同尘"/"守中"等思想源头
|
||||
- [[庄子]]：道家代表，"知其不可奈何而安之若命"出处
|
||||
- [[佛陀]]：金刚经偈颂来源，阐述"有为法"之虚妄
|
||||
|
||||
## Connections
|
||||
- [[Laozi, Confucius, Buddha Wisdom]] ← 上位概念 ← [[空性智慧]]
|
||||
- [[Diamond Sutra]] ← 同一经典 ← [[一切有为法，如梦幻泡影]]
|
||||
- [[Su Dongpo Perspective]] ← 同类实践 ← [[绝处逢生]]
|
||||
|
||||
## Contradictions
|
||||
- 与现代"积极进取"文化的张力：
|
||||
- 冲突点：东方智慧强调"放下"、"接受"，与现代社会"主动改变"、"征服自然"的叙事存在张力
|
||||
- 当前观点："安之若命"非消极躺平，而是"尽人事后听天命"的智慧
|
||||
- 对方观点：在快速变化的现代职场，过度强调接受可能导致错失主动改善的机会
|
||||
|
||||
## Related Links
|
||||
- 《金刚经》
|
||||
- 《庄子·内篇·人间世》
|
||||
- 《老子》
|
||||
- 《礼记·中庸》
|
||||
- 曾国藩《治心经·诚心篇》
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "AI 解决方案专家培训课程"
|
||||
type: source
|
||||
tags: [ai, coze, workflow, industry-solution]
|
||||
date: 2025-06-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/AI 解决方案专家培训课程.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Coze 中文版平台提供的多行业 AI Agent 与工作流 Demo 集合，覆盖金融/教育/医疗/电商/客服等场景
|
||||
- 问题域：企业难以快速构建可落地的 AI 解决方案，缺乏从概念到实际部署的完整参考
|
||||
- 方法/机制：Coze 平台提供预置 Bot/Workflow 模板，用户可 Fork 后自定义改造，API 调用外部工具（GPT-SoVITS/F5-TTS/FaceFusion）
|
||||
- 结论/价值：低代码平台大幅降低 AI 解决方案开发门槛，非技术用户也能搭建企业级 AI 应用
|
||||
|
||||
## Key Claims
|
||||
- Coze 平台实现 AI 应用开发平民化，通过邀请链接即可加入团队空间体验 Demo
|
||||
- Workflow 模式（工作流模式）比 Bot 模式更适合复杂多步骤任务，流程固定但灵活性强
|
||||
- 表格问答助手支持代码版和插件版两种实现，满足不同技术能力用户需求
|
||||
- 医疗分诊助手结合图像识别（影像图片 Excel 数据）+ 问诊逻辑，实现端到端 AI 辅助
|
||||
|
||||
## Key Quotes
|
||||
> "数据分析案例：https://www.coze.cn/space/7433704316877520906/project-ide/7507579385827360779" — Coze 平台数据分析案例
|
||||
|
||||
> "AI证件照Demo：https://idphoto.bananaresearch.cn/" — 泛娱乐场景 AI 应用 Demo
|
||||
|
||||
## Key Concepts
|
||||
- [[Coze工作流]]：Coze 平台的可视化 Workflow 编辑器，通过节点串联实现复杂业务流程
|
||||
- [[AI行业解决方案]]：针对特定行业（金融/教育/医疗/电商）垂直场景的 AI Agent 定制方案
|
||||
- [[表格问答助手]]：基于知识库的自然语言 SQL 查询工具，支持代码版和插件版两种架构
|
||||
|
||||
## Key Entities
|
||||
- [[Coze]]：字节跳动旗下的 AI Agent 开发平台，国内版（coze.cn）和海外版（coze.com）双版本运营
|
||||
- [[FaceFusion]]：人脸融合 AI 工具，用于泛娱乐场景的 AI 证件照和视频生成
|
||||
- [[F5-TTS]]：开源语音克隆项目，用于数字人和 AI 客服的语音合成
|
||||
- [[GPT-SoVITS]]：声音克隆模型，用于医疗问诊等场景的个性化语音交互
|
||||
|
||||
## Connections
|
||||
- [[n8n]] ← comparable_to ← [[Coze工作流]]，两者都是可视化工作流编排工具，但 Coze 专注于 AI Agent，n8n 通用性更强
|
||||
- [[AI数据处理]] ← uses ← [[AI行业解决方案]]，行业方案依赖数据处理层实现结构化信息提取
|
||||
- [[智能体工作流]] ← extends ← [[Coze工作流]]，Coze 工作流是智能体工作流的具体实现之一
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Workflow vs Agent]] 概念：本文的 Workflow 模式强调固定流程；Coze 也支持 Agent 模式（LLM 动态决策）。冲突点：固定流程 vs 动态决策的适用场景。当前观点：复杂业务场景优先 Workflow，简单问答场景用 Agent 模式更灵活。
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
title: "AI 解决方案专家培训课程"
|
||||
type: source
|
||||
tags: [coze, AI Agent, 解决方案, 培训]
|
||||
date: 2025-06-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/AI 解决方案专家培训课程.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Coze（扣子）平台 AI Agent 开发培训课程案例集
|
||||
- 问题域：展示 Coze 平台多行业 AI Agent 和工作流设计能力
|
||||
- 方法/机制：通过 Coze 中国版/国际版平台 Demo，涵盖金融、医疗、教育、电商、HR、客服等行业场景
|
||||
- 结论/价值：Coze 是企业级 AI Agent 快速搭建的低代码平台，Workflow+Bot 组合覆盖大多数业务场景
|
||||
|
||||
## Key Claims
|
||||
- Coze 中国版（coze.cn）和国际版（coze.com）功能基本对齐，支持 Bot 和 Workflow 两种形态
|
||||
- 金融场景：客户分层营销助手、智能客服 Agent，支撑企业级决策
|
||||
- 教育场景：拍照搜视频、组卷出题、知识点掌握评估，覆盖学习全流程
|
||||
- 医疗场景：影像图片识别 + 在线问诊，AI 辅助诊断
|
||||
- 电商场景：混剪助手、在线换衣、直播间自动回复，覆盖营销全链路
|
||||
- HR 场景：AI 面试对练、培训对练，标准化招聘流程
|
||||
- 客服场景：AI 销售、在线客服助教，降低人工成本
|
||||
|
||||
## Key Entities
|
||||
- [[Coze]]：字节跳动 AI Agent 开发平台，低代码/无代码构建 Bot 和 Workflow
|
||||
- [[Coze Workflow]]：Coze 可视化业务流程编排引擎
|
||||
- [[Coze Bot]]：Coze 对话型 AI Agent 构建形态
|
||||
|
||||
## Connections
|
||||
- [[Coze Bot]] ← 构成 ← [[Coze]]
|
||||
- [[Coze Workflow]] ← 构成 ← [[Coze]]
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
title: "AWS CloudFormation StackSets 多账户集中日志监控"
|
||||
type: source
|
||||
tags: [aws, devops, iac, cloudwatch, eventbridge]
|
||||
date: 2025-10-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/How to Simplify Multi-Account Deployments Monitoring Centralized Logs for AWS CloudFormation StackSets.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AWS 多账户环境下 CloudFormation StackSets 部署的集中日志监控方案
|
||||
- 问题域：多账户 IaC 部署时，逐账户登录排查故障的运维负担
|
||||
- 方法/机制：EventBridge 跨账户事件转发 + CloudWatch Logs 集中存储 + CloudWatch Logs Insights 查询
|
||||
- 结论/价值：一个管理账户统一视图，覆盖全部成员账户的 StackSets 事件，缩短故障定位时间
|
||||
|
||||
## Key Claims
|
||||
- AWS Organizations 多账户结构下，StackSets 可跨账户部署基础设施，但缺乏集中监控
|
||||
- EventBridge 规则在每个成员账户捕获 CloudFormation 事件并转发至管理账户自定义事件总线
|
||||
- CloudWatch Logs Insights 支持跨账户查询，提供失败堆栈操作、账户分布、资源类型等结构化分析
|
||||
- 两张 CloudFormation 模板（log-setup-management.yaml + common-resources-stackset.yaml）实现全自动化部署
|
||||
|
||||
## Key Quotes
|
||||
> "When a critical security baseline deployed across 50 accounts suddenly starts failing, teams face the daunting task of logging into each account individually to understand what went wrong." — AWS DevOps Blog，描述多账户运维的核心痛点
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudFormation StackSets]]：跨 AWS 账户和区域部署 IaC 的托管服务
|
||||
- [[EventBridge]]：AWS 事件总线，支持跨账户事件路由
|
||||
- [[CloudWatch Logs]]：AWS 日志存储与查询服务
|
||||
- [[CloudWatch Logs Insights]]：结构化日志分析查询语言
|
||||
- [[AWS Organizations]]：AWS 多账户组织管理框架
|
||||
- [[IaC]]：Infrastructure as Code，基础设施即代码
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：云服务商，StackSets/EventBridge/CloudWatch 服务的提供方
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← 提供基础设施 ← [[CloudFormation StackSets]]
|
||||
- [[CloudFormation StackSets]] ← 事件来源 ← [[EventBridge]]
|
||||
- [[EventBridge]] ← 跨账户转发 ← [[CloudWatch Logs]]
|
||||
- [[CloudWatch Logs]] ← 查询分析 ← [[CloudWatch Logs Insights]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
|
||||
## Metadata
|
||||
- 来源：AWS DevOps & Developer Productivity Blog
|
||||
- URL：https://aws.amazon.com/blogs/devops/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets/
|
||||
- 模板：log-setup-management.yaml + common-resources-stackset.yaml（GitHub aws-cloudformation-templates 仓库）
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
title: "Multi-Agent Specialized Team (Solo Founder Setup)"
|
||||
type: source
|
||||
tags: [multi-agent, openclaw, solo-founder, telegram]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/multi-agent-team.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：一人公司通过多个专业化 AI Agent 组建虚拟团队，实现 24/7 自动运转
|
||||
- 问题域：创始人身兼数职导致上下文切换成本高、精力耗散、无法深度工作
|
||||
- 方法/机制：多 Agent 分工 + 共享内存 + Telegram 统一入口 + 定时主动汇报
|
||||
- 结论/价值：Agent 团队比单一 Agent 更高效，分工专业化是关键
|
||||
|
||||
## Key Claims
|
||||
- 单一 Agent 无法同时处理战略、代码、营销等多领域任务而不快速填满上下文窗口
|
||||
- 共享记忆（GOALS.md/DECISIONS.md）+ 私有上下文组合是多 Agent 协作的核心机制
|
||||
- 定时主动任务（scheduled daily tasks）是 Agent 团队产生真实价值的飞轮
|
||||
- 从 2 个 Agent 开始（lead + specialist），再按瓶颈扩展至 4 个
|
||||
|
||||
## Key Quotes
|
||||
> "Personality matters more than you'd think: Giving agents distinct names and communication styles makes it natural to 'talk to your team' rather than wrestle with a generic AI" — Trebuh on X
|
||||
> "Start with 2, not 4: Begin with a lead + one specialist, then add agents as you identify bottlenecks"
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Agent Hierarchy]]：Supervisor（战略 Lead）+ Worker（领域专家）+ Validator 的层级分工
|
||||
- [[共享内存模式]]：共享 GOALS.md/DECISIONS.md + 私有 notes，实现共同上下文与专业积累
|
||||
- [[Telegram 路由]]：单一 Telegram 群聊，通过 @mention 分发到不同 Agent
|
||||
- [[定时主动任务]]：Agent 不等待指令，而是按日程主动 surface insights
|
||||
|
||||
## Key Entities
|
||||
- [[Trebuh]]：Solo founder，4 Agent 团队（ Milo/Josh/Marketing/Dev）实践者，OpenClaw Showcase 案例
|
||||
- [[OpenClaw]]：多 Agent 控制平面，支持 sessions_spawn/sessions_send 通过 Telegram 协调
|
||||
- [[Claude Opus]]：Milo（Strategy Lead）使用，擅长战略规划和综合协调
|
||||
- [[Claude Sonnet]]：Josh（Business）使用，快速分析能力匹配数字驱动任务
|
||||
- [[Gemini]]：Marketing Agent 使用，强于网页研究和长上下文分析
|
||||
|
||||
## Connections
|
||||
- [[Multi-Agent System Reliability]] ← 扩展 ← [[Multi-Agent Hierarchy]]
|
||||
- [[OpenClaw]] ← 支撑 ← [[Multi-Agent Hierarchy]] 的执行层
|
||||
- [[Agentic AI]] ← 上位概念 ← [[Multi-Agent Hierarchy]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Multi-Agent System Reliability]] 冲突：
|
||||
- 冲突点：Multi-Agent System Reliability 强调可靠性（多数投票/对抗辩论/淘汰制），Solo Founder Setup 强调快速交付和主动性
|
||||
- 当前观点：专业化分工 + 主动汇报优先于冗余可靠性机制
|
||||
- 对方观点：高风险任务需要 Validator/Hierarchy 等可靠性保障机制
|
||||
|
||||
## Related Links
|
||||
- [Trebuh on X](https://x.com/iamtrebuh/status/2011260468975771862)
|
||||
- [OpenClaw Showcase](https://openclaw.ai/showcase)
|
||||
- [Anthropic: Building Effective Agents](https://www.anthropic.com/research/building-effective-agents)
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: "Autonomous Educational Game Development Pipeline"
|
||||
type: source
|
||||
tags: [game-development, autonomous-agent, openclaw-usecase]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/autonomous-game-dev-pipeline.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：OpenClaw Agent 作为游戏开发智能体，自主管道生命周期管理（创建/修复/部署）
|
||||
- 问题域：独立开发者手工开发 40+ 教育游戏速度太慢，维护一致性困难
|
||||
- 方法/机制：Bugs First 策略 + Round Robin 队列 + 标准化设计规则 + Git 分支工作流；Agent 自主选择→实现→注册→文档→部署，每 7 分钟完成一个游戏或修复
|
||||
- 结论/价值：将游戏开发速度提升至每 7 分钟一个新游戏或修复，已成功生产 41+ 游戏
|
||||
|
||||
## Key Claims
|
||||
- Bugs First 强制优先级：Agent 必须先修复 bugs/ 目录下第一个文件，才可处理新游戏
|
||||
- 每 7 分钟一个游戏或修复的产出速度，管道已稳定运行
|
||||
- 游戏需注册到 public/js/games-list.json 才会在首页显示
|
||||
- 设计规则强制纯 HTML/CSS/JS（无框架）、移动优先、离线可用
|
||||
- 产出：elbebe.co — 一个面向拉丁美洲儿童的西班牙语教育游戏门户
|
||||
|
||||
## Key Quotes
|
||||
> "Bugs First! If the bugs/ folder has content, your only priority is to fix the first bug in alphabetical order."
|
||||
|
||||
> "This pipeline is capable of producing 1 new game or bugfix every 7 minutes."
|
||||
|
||||
## Key Concepts
|
||||
- [[Bugs-First-Policy]]：Agent 强制优先处理 bugs/ 队列中的第一个文件，阻止 feature 开发冲动
|
||||
- [[Round-Robin-Queue]]：跨年龄段平衡分配游戏开发任务的策略
|
||||
- [[Conventional-Commits]]：语义化提交格式（feat/fix），用于自动生成 CHANGELOG
|
||||
- [[Git-Branch-Workflow]]：feature/[game-id] 分支 → PR → master → 自动化发布
|
||||
|
||||
## Key Entities
|
||||
- [[El-Bebe-Games]]：拉丁美洲儿童教育游戏网站，游戏产出实体，GitHub 为 duberblockito/elbebe
|
||||
- [[LANero]]：项目创始人背景，"LANero of the old school" 创作者
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] ← 平台 ← [[Autonomous-Educational-Game-Development-Pipeline]]
|
||||
- [[Self-Healing-Systems]] ← 类似模式 ← [[Autonomous-Educational-Game-Development-Pipeline]]（自动修复优先）
|
||||
- [[Vibe-Kanban]] ← 任务管理 ← [[Autonomous-Educational-Game-Development-Pipeline]]
|
||||
|
||||
## Contradictions
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "Autonomous Project Management（去中心化协调模式）"
|
||||
type: source
|
||||
tags: [project-management, autonomous, subagent, state-yaml, openclaw]
|
||||
date: 2026-04-13
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/autonomous-project-management.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：去中心化项目协调——通过共享 STATE.yaml 文件替代中央 orchestrator
|
||||
- 问题域：传统中央协调模式（主 Agent 做交通警察）造成瓶颈，多并行工作流项目需要真正的并行执行
|
||||
- 方法/机制：每个项目维护 STATE.yaml 作为单一真实源，subagent 自主读写状态文件协调
|
||||
- 结论/价值：主会话保持薄（CEO 模式），所有执行下沉到 subagent，Git 作为审计日志
|
||||
|
||||
## Key Claims
|
||||
- STATE.yaml > 中央 orchestrator：基于文件的协调比消息传递更具可扩展性
|
||||
- Git 作为审计日志：STATE.yaml 变更提交 Git 实现完整历史追溯
|
||||
- 标签命名规范：`pm-{project}-{scope}` 便于追踪
|
||||
- 薄主会话原则：主 Agent 越少做事，响应越快
|
||||
|
||||
## Key Quotes
|
||||
> "Main session = coordinator ONLY. All execution goes to subagents." — OpenClaw PM Delegation Pattern
|
||||
|
||||
## Key Concepts
|
||||
- [[STATE.yaml]]：项目协调文件，YAML 结构定义任务状态与依赖，支持 next_actions 驱动
|
||||
- [[去中心化协调]]：无中央 orchestrator，各 subagent 通过共享状态文件自主协调
|
||||
- [[GitOps]]（隐式）：Git commit STATE.yaml 变更实现项目状态版本管理
|
||||
|
||||
## Key Entities
|
||||
- [[Nicholas Carlini]]：自主编码 agent 方法论提出者，STATE.yaml 去中心化协调灵感来源
|
||||
- [[OpenClaw]]：支持 sessions_spawn/sessions_send，subagent 文件系统访问
|
||||
|
||||
## Connections
|
||||
- [[Autonomous-Project-Management-STATE-yaml]] ← implements ← [[Multi-Agent Hierarchy]]（Planner+Worker+Validator，STATE.yaml 替代中央验证器）
|
||||
- [[Autonomous-Project-Management-STATE-yaml]] ← shares_pattern ← [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]]（均依赖共享状态协调，而非中央 orchestrator）
|
||||
- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← extends ← [[Autonomous-Project-Management-STATE-yaml]]（Solo-Founder 团队在 PM 维度应用去中心化协调）
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "Autonomous Project Management with Subagents"
|
||||
type: source
|
||||
tags: [agent, project-management, subagent]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/autonomous-project-management.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：去中心化项目管理模式，多 subagent 通过共享 STATE.yaml 协调而非中央 orchestrator
|
||||
- 问题域：传统 orchestrator 模式造成主 agent 瓶颈，多 repo 重构/研究冲刺/内容管线等复杂项目需要并行执行
|
||||
- 方法/机制：STATE.yaml 作为单一事实来源 → 各 agent 自主认领任务 → 状态更新触发其他 agent 接力
|
||||
- 结论/价值：文件协调优于消息传递；Git 作为审计日志；薄主会话原则（CEO 模式）
|
||||
|
||||
## Key Claims
|
||||
- 传统 orchestrator 模式产生瓶颈——主 agent 成为交通指挥
|
||||
- STATE.yaml > orchestrator：文件协调比消息传递更具扩展性
|
||||
- Git 作为审计日志：提交 STATE.yaml 变更获取完整历史
|
||||
- Label 约定很重要：用 `pm-{project}-{scope}` 格式便于追踪
|
||||
- 薄主会话原则：主 agent 做得越少，响应越快
|
||||
|
||||
## Key Quotes
|
||||
> "Managing complex projects with multiple parallel workstreams is exhausting. You end up context-switching constantly." — 痛点陈述
|
||||
> "Let agents self-organize rather than micromanaging them." — [[Nicholas Carlini]] 方法论核心
|
||||
|
||||
## Key Concepts
|
||||
- [[STATE.yaml]]：项目协调文件，YAML 格式定义任务状态、owner、blocked_by 依赖关系
|
||||
- [[去中心化协调]]：无中央 orchestrator，各 agent 自主读写共享状态文件
|
||||
- [[薄主会话]]：主会话仅做策略/调度，所有执行下沉 subagent
|
||||
- [[CEO 模式]]：主 agent = 协调者，subagent = 执行者
|
||||
|
||||
## Key Entities
|
||||
- [[Nicholas Carlini]]：自主编码 agent 方法论提出者，STATE.yaml 协调模式灵感来源
|
||||
- [[Anthropic]]：Building Effective Agents 论文发布方
|
||||
|
||||
## Connections
|
||||
- [[Multi-Agent Hierarchy]] ← 架构基础 ← [[Autonomous Project Management]]
|
||||
- [[sessions_spawn]] ← 核心能力 ← [[Autonomous Project Management]]
|
||||
- [[sessions_send]] ← 核心能力 ← [[Autonomous Project Management]]
|
||||
- [[GitOps]] ← 审计日志机制 ← [[Autonomous Project Management]]
|
||||
|
||||
## Contradictions
|
||||
- 与中央 orchestrator 模式冲突：
|
||||
- 当前观点：去中心化文件协调，无单点瓶颈
|
||||
- 对方观点：中央 orchestrator 便于全局控制
|
||||
- 适用场景：复杂多任务 > 简单顺序任务
|
||||
@@ -1,60 +0,0 @@
|
||||
---
|
||||
title: "Best 7 News API Data Feeds"
|
||||
type: source
|
||||
tags: [news-api, data-feed, ai, 新闻聚合]
|
||||
date: 2025-03-11
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Best 7 news API data feeds - AI News.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：7 款主流新闻 API 数据源全面评测
|
||||
- 问题域：如何为 AI 应用选择合适的新闻数据源
|
||||
- 方法/机制：对比维度（覆盖范围/价格/适用场景/核心能力）
|
||||
- 结论/价值：不同场景对应不同 API——金融选 Bloomberg/FT、舆情选 Webz.io/Opoint、小型应用选 GNews/Mediastack
|
||||
|
||||
## Key Claims
|
||||
- Webz.io 是覆盖最全面的新闻 API，同时覆盖 surface web + deep web + dark web，金融/网安/风控场景首选
|
||||
- GNews API 轻量低价，适合小型应用和初创公司，支持多语言本地化
|
||||
- The Guardian API 专注高质量编辑内容，适合研究和内容平台
|
||||
- Bloomberg API + Financial Times API 面向机构级金融分析，FT 提供经济报告，Bloomberg 提供实时市场数据
|
||||
- Opoint 擅长舆情监控和情感分析，PR/营销/品牌监测首选
|
||||
- Mediastack 7000+ 来源，免费套餐可用，最适合开发者构建多来源聚合应用
|
||||
|
||||
## Key Quotes
|
||||
> "News API data feeds are platforms that aggregate, organise, and deliver structured news data from multiple sources." — AI News 概述
|
||||
|
||||
## Key Concepts
|
||||
- [[News API]]：标准化 HTTP API 接口获取新闻数据，返回 JSON/XML 格式结构化数据
|
||||
- [[新闻聚合]]：将多个来源新闻整合为统一格式，Eliminate 人工采集成本
|
||||
- [[舆情监控]]：实时跟踪品牌/竞品媒体提及和情感倾向
|
||||
- [[金融情报]]：实时分析市场动向新闻，驱动投资决策
|
||||
|
||||
## Key Entities
|
||||
- [[Webz.io]]：全覆盖新闻 API（surface+deep+dark web）
|
||||
- [[GNews API]]：轻量低价新闻 API
|
||||
- [[The Guardian API]]：高质量编辑内容新闻源
|
||||
- [[Bloomberg API]]：机构级金融数据 API
|
||||
- [[Financial Times API]]：专业财经分析与经济报告
|
||||
- [[Opoint]]：舆情监控与情感分析平台
|
||||
- [[Mediastack API]]：7000+ 来源可扩展新闻 API
|
||||
|
||||
## Connections
|
||||
- [[News API]] ← 分类产品 ← [[Webz.io]] / [[GNews API]] / [[The Guardian API]] / [[Bloomberg API]] / [[Financial Times API]] / [[Opoint]] / [[Mediastack API]]
|
||||
- [[舆情监控]] ← 工具 ← [[Opoint]]
|
||||
- [[金融情报]] ← 工具 ← [[Bloomberg API]] / [[Financial Times API]]
|
||||
|
||||
## Use Cases
|
||||
| 场景 | 推荐 API |
|
||||
|------|---------|
|
||||
| 金融分析与市场数据 | Bloomberg API / Financial Times API |
|
||||
| 舆情监控与品牌追踪 | Opoint / Webz.io |
|
||||
| 网安与风控情报 | Webz.io |
|
||||
| 小型应用与本地化 | GNews API / Mediastack |
|
||||
| 高质量编辑内容 | The Guardian API |
|
||||
| AI 训练数据获取 | Mediastack（来源多+价格灵活） |
|
||||
|
||||
## Contradictions
|
||||
- Webz.io vs Mediastack：Webz.io 覆盖最广但价格高；Mediastack 来源多且有免费套餐，但深度不如 Webz.io
|
||||
- Bloomberg vs Financial Times：Blochberg 偏实时市场数据，FT 偏深度经济报告，可互补
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "Build Your Own X — 从零构建技术的编程学习资源集"
|
||||
type: source
|
||||
tags: [learning, programming, github, tutorial, build-from-scratch]
|
||||
date: 2026-01-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/codecrafters-iobuild-your-own-x Master programming by recreating your favorite technologies from scratch.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：GitHub 编程学习资源集，通过从零重建流行技术来掌握编程
|
||||
- 问题域：如何通过动手重建而非被动阅读来深度理解技术原理
|
||||
- 方法/机制：收录 25 个技术领域的分步骤指南，每指南附多语言实现教程
|
||||
- 结论/价值："What I cannot create, I do not understand"——费曼学习法的技术领域实践
|
||||
|
||||
## Key Claims
|
||||
- 重建流行技术是深度掌握编程的最有效方法
|
||||
- 分步骤指南覆盖 25 个技术领域，从 Web 服务器到神经网络到操作系统
|
||||
- 每个领域提供多语言实现（Python/JavaScript/Go/C++/Rust 等），学习者可选择熟悉语言切入
|
||||
- codecrafters.io 提供在线编程挑战平台
|
||||
|
||||
## Key Quotes
|
||||
> "What I cannot create, I do not understand." — Richard Feynman
|
||||
|
||||
## Key Concepts
|
||||
- [[费曼学习法]]：不能创造即不能真正理解，动手重建是最高效的深度学习路径
|
||||
- [[Vibe Coding]]：BYOX 与 Vibe Coding 均强调动手实践，BYOX 是更激进的"完全从零"版本
|
||||
|
||||
## Key Entities
|
||||
- [[CodeCrafters]]：build-your-own-x 的维护方，提供在线编程挑战平台
|
||||
- [[Daniel Stefanovic]]：build-your-own-x 项目创始人
|
||||
- [[Richard Feynman]]：费曼学习法起源
|
||||
|
||||
## Connections
|
||||
- [[Build-Your-Own-X-从零构建技术栈]] ← enables ← [[Vibe Coding]]（BYOX 是 Vibe Coding 的底层实践）
|
||||
- [[Build-Your-Own-X-从零构建技术栈]] ← implements ← [[费曼学习法]]
|
||||
- [[Vibe-Kanban-OpenCode-Ubuntu-Server安装管理指南]] ← related ← [[Vibe Coding]]（Vibe Coding 工具链）
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: "ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材"
|
||||
type: source
|
||||
tags: [教育资源, 开源, GitHub]
|
||||
date: 2025-05-13
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Others/ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：中国公开教育 PDF 教材开源归档项目
|
||||
- 问题域：教育资源获取不平等、教材数字化保存
|
||||
- 方法/机制：爬取国家中小学智慧教育平台 + GitHub 托管分发
|
||||
- 结论/价值：41.53 GB 规模覆盖小初高大学全学段，永久免费开源
|
||||
|
||||
## Key Claims
|
||||
- [[TapXWorld]] 团队通过 [[tchMaterial-parser]] 工具从[[国家中小学智慧教育平台]]批量下载教材 PDF
|
||||
- 教材来源本身只需登录后即可浏览，属于公开资源
|
||||
- GitHub 托管方式实现永久可用，不依赖任何单一平台
|
||||
|
||||
## Key Quotes
|
||||
> "这个项目存在有一段时间了，今天突然火了。" — Appinn 评论区
|
||||
|
||||
## Key Concepts
|
||||
- [[教育资源开源]]：将官方平台公开教材整合为可下载的离线包
|
||||
- [[GitHub 大文件托管]]：41.53 GB 规模超出 Git LFS 免费配额，实际以种子或其他方式分发
|
||||
|
||||
## Key Entities
|
||||
- [[TapXWorld]]：ChinaTextbook 项目的发起和维护团队
|
||||
- [[Appinn]]：最早报道此项目的科技博客
|
||||
- [[国家中小学智慧教育平台]]：教材原始来源平台（basic.smartedu.cn）
|
||||
- [[tchMaterial-parser]]：第三方教材下载解析工具（GitHub 开源）
|
||||
|
||||
## Connections
|
||||
- [[ChinaTextbook]] ← 来源于 ← [[国家中小学智慧教育平台]]
|
||||
- [[ChinaTextbook]] ← 报道于 ← [[Appinn]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统教材获取方式冲突：付费购买 vs 免费开源获取；反映了教育资源数字化的知识产权灰色地带
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: "ChinaTextbook - 41.53 GB，中国小学、初中、高中、大学 PDF 教材"
|
||||
source: "https://www.appinn.com/chinatextbook/"
|
||||
author: "shenwei"
|
||||
published: "2025-05-13"
|
||||
created: "2025-12-19"
|
||||
description: "ChinaTextbook 是一款收集了公开的中国小学、初中、高中、大学 PDF 教材的项目，托管在 GitHub 上，总库大小 41.53GB。"
|
||||
tags:
|
||||
- 教育资源
|
||||
- PDF教材
|
||||
- 中国教育
|
||||
- 开源
|
||||
---
|
||||
|
||||
## 关键洞察
|
||||
|
||||
- **大规模教育开源项目**: ChinaTextbook 是托管在 GitHub 上的中国教育教材收集项目，总大小 41.53 GB
|
||||
- **覆盖全学段**: 包含小学、初中、高中、大学各学科教材
|
||||
- **来源正规**: 教材来源于国家中小学智慧教育平台，仅需登录即可浏览
|
||||
- **社区驱动**: 通过第三方工具 (tchMaterial-parser) 实现批量下载
|
||||
|
||||
## 摘要
|
||||
|
||||
ChinaTextbook 是一款收集了公开的中国小学、初中、高中、大学 PDF 教材的项目，托管在 GitHub 上，总库大小 41.53GB。教材来源为国家中小学智慧教育平台，本身只需要登录后即可浏览，可以使用第三方工具下载。
|
||||
|
||||
## 主要内容
|
||||
|
||||
### 小学教材
|
||||
语文/统编版、数学、英语、科学、道德与法治、美术、音乐、体育与健康、艺术、语文·书法练习指导
|
||||
|
||||
### 初中教材
|
||||
语文/统编版、数学、英语、物理、化学、生物学、历史/统编版、地理、道德与法治、俄语/人教版、日语/人教版、美术、音乐、体育与健康、艺术、科学、地理图册、人文地理/统编版
|
||||
|
||||
### 高中教材
|
||||
语文/统编版、数学、英语、物理、化学、生物学、历史/统编版、地理、思想政治/统编版、俄语/人教版、日语/人教版、美术、音乐、体育与健康、艺术、通用技术、信息技术、地理图册
|
||||
|
||||
### 大学教材
|
||||
高等数学、线性代数、概率论、离散数学
|
||||
|
||||
## 关键实体
|
||||
|
||||
- [[ChinaTextbook]]
|
||||
- [[TapXWorld]]
|
||||
- [[Appinn]]
|
||||
- [[国家中小学智慧教育平台]]
|
||||
- [[tchMaterial-parser]]
|
||||
|
||||
## 相关来源
|
||||
|
||||
- [GitHub: TapXWorld/ChinaTextbook](https://github.com/TapXWorld/ChinaTextbook/)
|
||||
- [Appinn: ChinaTextbook](https://www.appinn.com/chinatextbook/)
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
title: "Claude Code 调用方法总结"
|
||||
type: source
|
||||
tags: [ClaudeCode, OpenClaw, AI编程]
|
||||
date: 2026-03-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/Agent/claude-code调用方法总结.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：OpenClaw/Hermes 系统中 terminal 工具调用 Claude Code 的两种核心模式
|
||||
- 问题域：如何可靠地将复杂编程任务委托给 Claude Code 执行，避免权限阻塞和超时问题
|
||||
- 方法/机制：Print Mode（stdin 管道非交互模式）与 TMUX 交互模式对比，关键参数 bypassPermissions/max-turns
|
||||
- 结论/价值：terminal 调用 claude -p 是调用 Claude Code 技能的唯一正确方式，delegate_task 无法激活外部 CLI
|
||||
|
||||
## Key Claims
|
||||
- Print Mode 通过 stdin 管道传递任务文本，避免特殊字符 shell 转义问题
|
||||
- `--permission-mode bypassPermissions` 跳过所有交互确认，比 `--dangerously-skip-permissions` 更可靠
|
||||
- `--add-dir <路径>` 自动扫描目标目录下的 SKILL.md 并在匹配条件时自动激活
|
||||
- `--max-turns 25-30` 是复杂任务的合理阈值，过小会导致任务未完成就超时
|
||||
- delegate_task 只能调用 Hermes 子 agent，无法建立外部 Claude Code CLI 通道
|
||||
|
||||
## Key Quotes
|
||||
> "当任务需要调用 Claude Code 的 skill（如 fireworks-tech-graph）时，应使用 terminal 调用 claude -p，而非 delegate_task。" — 核心结论
|
||||
|
||||
## Key Concepts
|
||||
- [[Print Mode]]：Claude Code 非交互单次执行模式，通过 stdin 管道传递任务，适合绝大多数编程任务
|
||||
- [[TMUX交互模式]]：Claude Code 长时间交互模式，通过 tmux session 保持进程，适合超长任务
|
||||
- [[Skill加载]]：Claude Code 通过 `--add-dir` 扫描目录下的 SKILL.md 并在触发条件匹配时自动激活
|
||||
- [[权限绕过]]：bypassPermissions 参数跳过所有交互确认，是自动化调用 Claude Code 的必要条件
|
||||
|
||||
## Key Entities
|
||||
- [[Claude-Code]]：Anthropic 官方 CLI 编程工具，支持 skill 扩展
|
||||
- [[Hermes]]：OpenClaw 中调用外部 CLI 工具的组件，通过 terminal 工具触发
|
||||
|
||||
## Connections
|
||||
- [[Claude-Code]] ← 被调用方 ← [[Print Mode]]
|
||||
- [[Claude-Code]] ← 被调用方 ← [[TMUX交互模式]]
|
||||
- [[Skill加载]] ← 作用于 ← [[Claude-Code]]
|
||||
- [[Print Mode]] ← 替代方案 ← [[TMUX交互模式]]
|
||||
|
||||
## Contradictions
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "Claude Skills研究范式"
|
||||
type: source
|
||||
tags: [ai, claude-skills, vibe-coding]
|
||||
date: 2026-01-05
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：Claude Skills 从提示词工程到流程工程的范式转移
|
||||
- 问题域：AI 技能封装与复用、Skills 生态资源
|
||||
- 方法/机制：Skills = 说明书 + SOP，将人类经验封装为可复用工作流
|
||||
- 结论/价值：Skills 是 Vibe Coding 的尽头，真正有价值的不是 Prompt 写得多花哨，而是谁最懂业务流程
|
||||
|
||||
## Key Claims
|
||||
- Claude Skills 爆发标志着从"提示词工程"迈向"流程工程"
|
||||
- Anthropic 官方 Skills 仓库（github.com/anthropics/skills）收藏数突破 3.2 万
|
||||
- 官方库本质上是教你"像我们一样开发 AI 应用"
|
||||
- Skills 包含四大类：办公自动化（Word/PDF/PPT/Excel）、开发者工具箱、MCP Server、创意类 Skill
|
||||
- 未来真正有价值的 = 懂业务流程 + 能把经验沉淀为 SOP + 把 SOP 交给 AI 稳定执行
|
||||
|
||||
## Key Quotes
|
||||
> "Skills 就是一套你写给 Claude 的'说明书'和'SOP（标准作业程序）'" — 痕小子/开源星探
|
||||
> "这个库本质上是官方在教你，'怎么像我们一样开发 AI 应用'" — 痕小子/开源星探
|
||||
|
||||
## Key Concepts
|
||||
- [[AI技能封装]]：将固定流程任务拆解为 AI 可理解的结构化流程
|
||||
- [[流程工程]]：将经验沉淀为 SOP 再交给 AI 稳定执行的新范式
|
||||
- [[Anthropic Skills 官方库]]：github.com/anthropics/skills，生产级 Skills 集合
|
||||
|
||||
## Key Entities
|
||||
- [[Anthropic]]：Claude Skills 官方库的发布方
|
||||
- [[Awesome-Claude-Skills]]：ComposioHQ/VoltAgent/BehiSecc 三大社区整理
|
||||
- [[skillsmp.com]]：Skill 聚合站之一
|
||||
- [[aitmpl.com]]：Skill 聚合站之一
|
||||
- [[claudemarketplaces.com]]：Skill 聚合站之一
|
||||
|
||||
## Connections
|
||||
- [[Claude Skills研究范式]] ← 理论基础 ← [[Google 5种Agent Skill设计模式]]
|
||||
- [[Anthropic Skills 官方库]] ← 来源 ← [[Claude Skills研究范式]]
|
||||
- [[流程工程]] ← 应用场景 ← [[Vibe Coding氛围编程]]
|
||||
|
||||
## Contradictions
|
||||
@@ -1,59 +0,0 @@
|
||||
---
|
||||
title: "Clonezilla 对 Ubuntu Server 进行全盘镜像备份"
|
||||
type: source
|
||||
tags: [备份, Clonezilla, Ubuntu, NAS, 灾难恢复]
|
||||
date: 2025-12-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Clonezilla对Ubuntu Server进行全盘镜像备份.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：使用 Clonezilla 实现 Ubuntu Server 全盘镜像备份到 NAS 的完整操作流程
|
||||
- 问题域：服务器灾难恢复、硬盘故障防护、数据持久化
|
||||
- 方法/机制：Clonezilla live USB 启动 → NFS 挂载 NAS → imagedir 选择 → 压缩归档
|
||||
- 结论/价值：零成本开源方案，实现类似 Ghost 的磁盘级备份，支持完整灾难恢复
|
||||
|
||||
## Key Claims
|
||||
- Rufus 制作 Clonezilla 启动盘时，针对新笔记本选 GPT+UEFI，老笔记本选 MBR+BIOS
|
||||
- NFS 是 NAS 备份首选协议，Linux 兼容性最好，优于 SMB/CIFS
|
||||
- `-z1p` 压缩参数在备份速度和空间节省间取得平衡
|
||||
- 灾难恢复只需在 NAS 找到镜像目录，选择 `restoredisk` 即可完整复活系统
|
||||
|
||||
## Key Procedures
|
||||
|
||||
### 制作启动盘
|
||||
1. 下载 debian amd64 iso（比 alternative 更稳定）
|
||||
2. Rufus 选择 ISO 模式写入（勿选 DD 模式，除非 ISO 模式失败）
|
||||
3. 分区方案：GPT for UEFI，MBR for BIOS
|
||||
|
||||
### 备份流程
|
||||
1. F9 进入启动菜单选择 U 盘
|
||||
2. 语言 en_US.UTF-8，键盘默认
|
||||
3. `device-image` → `nfs_server` → DHCP 获取 IP
|
||||
4. 输入 NAS IP 和 NFS 挂载路径（如 `/volume2/backups`）
|
||||
5. Beginner 模式 → `savedisk` → 选择源磁盘 → `-z1p` 压缩 → 确认执行
|
||||
|
||||
### 恢复流程
|
||||
1. 同备份流程到第 3 步
|
||||
2. 选择 `restoredisk`（而非 `savedisk`）
|
||||
3. 指定 NAS 上镜像路径，确认后写入新硬盘
|
||||
|
||||
## Key Entities
|
||||
- [[Clonezilla]]：开源磁盘克隆工具（类似于 Ghost），支持多种文件系统和企业级功能
|
||||
- [[Rufus]]：Windows 下制作 USB 启动盘工具，支持 ISOHybrid 镜像写入
|
||||
- [[NFS]]：Network File System，Linux 原生网络文件系统协议
|
||||
- [[Synology NAS]]：备份存储目标（IP: 192.168.3.17）
|
||||
|
||||
## Key Concepts
|
||||
- [[磁盘镜像备份]]：将整个磁盘保存为单个压缩镜像文件，支持完整恢复
|
||||
- [[GPT vs MBR]]：UEFI 新机器用 GPT，传统 BIOS 机器用 MBR；是启动模式决定分区表类型而非硬盘大小
|
||||
- [[NFS 挂载]]：`/etc/fstab` + `_netdev` 参数防止开机挂载顺序错误
|
||||
|
||||
## Connections
|
||||
- [[Clonezilla]] ← 使用 ← [[Rufus]]
|
||||
- [[Clonezilla备份]] → 存储目标 → [[Synology NAS]]
|
||||
- [[NFS备份]] ← 协议选择 ← [[Ubuntu Server备份]]
|
||||
|
||||
## Contradictions
|
||||
- ISO 模式 vs DD 模式：Rufus 文档推荐 ISO 模式，但 DD 模式在某些 hybrid ISO 上更可靠；实际以启动成功为准
|
||||
@@ -1,51 +1,46 @@
|
||||
---
|
||||
title: "Cloud DevOp Maturity - Guideline"
|
||||
type: source
|
||||
tags: [devops, cloud, maturity-model, enterprise]
|
||||
date:
|
||||
tags: [cloud, devops, maturity-model, enterprise]
|
||||
date: 2026-04-16
|
||||
source_file: raw/Cloud & DevOps/Cloud DevOp Maturity - Guideline.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud DevOp Maturity - Guideline.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：企业级SaaS公司云DevOps成熟度评估框架
|
||||
- 问题域：如何系统化评估组织DevOps成熟度，识别改进路径
|
||||
- 方法/机制：基于CMMI和DORA指标的多维度成熟度模型
|
||||
- 结论/价值：DevOps是持续改进过程，即使成熟组织也需适应新技术新实践
|
||||
企业级 SaaS 公司的 Cloud DevOps 成熟度评估框架，涵盖成熟度定义、关键模型、基础支柱、工具选型、度量指标、挑战、案例及路线图。核心观点：DevOps 成熟度是持续改进过程，需通过自动化、文化协作、监控可观测性和安全集成实现组织级交付效率提升。
|
||||
|
||||
## Key Claims
|
||||
- DevOps成熟度包含：自动化、研运协作、交付速度、可靠性四个维度
|
||||
- DORA四大指标：部署频率、变更前置时间、变更失败率、平均恢复时间（MTTR）
|
||||
- 成熟度四大支柱：自动化（CI/CD/IaC）、协作与文化、监控与可观测性、安全集成（DevSecOps）
|
||||
- 工具链核心组件：CI/CD、IaC（Terraform/Ansible）、容器化（Kubernetes/Docker）、监控（Prometheus/Grafana）
|
||||
- 达到DevOps成熟需要：进行成熟度评估→建立DevOps卓越中心→分阶段改进
|
||||
- DevOps 成熟度包含自动化、开发运维协作、交付速度和可靠性四个核心维度
|
||||
- CMMI 和 DORA 是评估 DevOps 成熟度的两大关键模型
|
||||
- DevOps 成熟度基础支柱包括：自动化、文化协作、监控可观测性、安全集成（DevSecOps）
|
||||
- CI/CD 流水线、IaC、测试自动化是成熟度提升的技术基础
|
||||
- DevOps 是持续改进过程，而非一次性目标
|
||||
|
||||
## Key Quotes
|
||||
> "DevOps is a continuous improvement process, and even mature companies need to adapt to evolving technologies and practices."
|
||||
> "DORA metrics: deployment frequency, lead time for changes, change failure rate, and mean time to recovery (MTTR)" — DevOps Research & Assessment 核心度量指标
|
||||
> "Security must be integrated into the DevOps lifecycle through automation, continuous compliance, and proactive vulnerability management" — DevSecOps 核心原则
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps-Maturity]]：DevOps成熟度，组织在云DevOps实践上的发展阶段
|
||||
- [[DORA-Metrics]]：DevOps Research & Assessment四大指标——部署频率、变更前置时间、变更失败率、MTTR
|
||||
- [[CMMI]]：Capability Maturity Model Integration，能力成熟度模型集成
|
||||
- [[IaC]]：Infrastructure as Code，基础设施即代码
|
||||
- [[DevSecOps]]：将安全集成到DevOps生命周期的实践
|
||||
- [[CI-CD-Pipeline]]：持续集成/持续交付流水线
|
||||
- [[监控与可观测性]]：持续监控、日志、问题检测与快速解决能力
|
||||
- [[DevOps-CoE]]：DevOps Center of Excellence，卓越中心
|
||||
- [[DevOps 成熟度模型]]：评估组织 DevOps 实践水平的分级框架
|
||||
- [[DORA 指标]]：DevOps Research & Assessment 提出的四项关键度量
|
||||
- [[CMMI]]：Capability Maturity Model Integration 能力成熟度模型集成
|
||||
- [[CI/CD 流水线]]：持续集成/持续交付自动化流程
|
||||
- [[IaC]]：Infrastructure as Code 基础设施即代码
|
||||
- [[DevSecOps]]：安全集成的 DevOps 实践
|
||||
- [[监控可观测性]]：Continuous monitoring, logging, and issue detection
|
||||
|
||||
## Key Entities
|
||||
- [[Terraform]]：IaC工具
|
||||
- [[Ansible]]：IaC/配置管理工具
|
||||
- [[Terraform]]：IaC 工具
|
||||
- [[Ansible]]：配置管理工具
|
||||
- [[Kubernetes]]：容器编排平台
|
||||
- [[Docker]]：容器化平台
|
||||
- [[Docker]]：容器化技术
|
||||
- [[Prometheus]]：监控系统
|
||||
- [[Grafana]]：可观测性平台
|
||||
- [[Grafana]]：可视化监控仪表板
|
||||
|
||||
## Connections
|
||||
- [[DORA-Metrics]] ← 评估 → [[DevOps-Maturity]]
|
||||
- [[IaC]] ← 支撑 → [[DevOps-Maturity]]
|
||||
- [[DevSecOps]] ← 集成 → [[DevOps-Maturity]]
|
||||
- [[CI-CD-Pipeline]] ← 核心 → [[DevOps-Maturity]]
|
||||
- [[DevOps 成熟度模型]] ← 评估框架 ← [[DORA 指标]]
|
||||
- [[CI/CD 流水线]] ← 依赖 ← [[IaC]]
|
||||
- [[DevSecOps]] ← 依赖 ← [[监控可观测性]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无记录）
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "Cloud Maturity Model A Detailed Guide For Cloud Adoption"
|
||||
type: source
|
||||
tags: [Cloud, DevOps, Cloud-Adoption, Maturity-Model]
|
||||
date: 2024-07-08
|
||||
source_file: raw/Cloud & DevOps/Cloud Maturity Model A Detailed Guide For Cloud Adoption.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud Maturity Model A Detailed Guide For Cloud Adoption.md]]
|
||||
|
||||
## Summary
|
||||
Cloud Maturity Model（云成熟度模型，CMM）是一种用于评估组织云采纳就绪程度的框架。Forrester 预测全球 CMM 行业将从 2022 年的 7.5 亿美元增长至 2025 年的 15 亿美元。Gartner 指出超过 60% 的组织正在积极实施云成熟度模型。该模型通过 5 个等级（从无云准备到优化级）帮助组织评估当前状态并规划云迁移路径，同时覆盖业务和技术两大维度的多项能力领域。
|
||||
|
||||
## Key Claims
|
||||
- Cloud Maturity Model 是组织评估云采纳就绪程度的关键框架，适用于各种规模和云经验水平的组织
|
||||
- Forrester 预测全球 CMM 行业 2025 年将达到 15 亿美元（2022 年为 7.5 亿美元）
|
||||
- Gartner 指出超过 60% 的组织正在积极实施云成熟度模型
|
||||
- Open Alliance for Cloud Adoption (OACA) 将 CMM 定义为帮助组织识别云或混合 IT 环境定制化解决方案的框架
|
||||
- CMM 涵盖 16 个业务能力领域和 18 个技术能力领域
|
||||
|
||||
## Key Quotes
|
||||
> "CMMs are crucial because they offer a structured approach to assessing your current cloud adoption strategy. They help you avoid common pitfalls and identify areas of improvement." — 云成熟度模型的重要性说明
|
||||
> "Level five can be seen as an overinvestment if extensive hybrid cloud solutions are optional." — 关于第5级的现实性评价
|
||||
|
||||
## Key Concepts
|
||||
- [[Cloud-Maturity-Model]]：评估组织云采纳就绪程度的 5 级框架
|
||||
- [[Cloud-Adoption]]：将工作负载和服务从本地迁移到云的过程
|
||||
- [[Cloud-Native]]：利用云平台原生特性构建和运行应用的方法
|
||||
- [[Hybrid-Cloud]]：组合使用公有云和私有云的部署模式
|
||||
- [[Multi-Cloud]]：使用多个云服务商的服务
|
||||
- [[DevOps]]：结合开发和运营以实现持续软件交付的方法论
|
||||
- [[IaaS]]：基础设施即服务，提供虚拟计算资源
|
||||
- [[PaaS]]：平台即服务，提供应用开发和部署平台
|
||||
- [[SaaS]]：软件即服务，以订阅方式提供软件应用
|
||||
- [[CAPEX-to-OPEX]]：从资本支出向运营支出的转变
|
||||
- [[Cloud-Security-Maturity-Model-CSMM]]：评估云安全成熟度的模型
|
||||
- [[AWS-Cloud-Adoption-Framework]]：AWS 的云采纳框架
|
||||
- [[Azure-Cloud-Adoption-Framework]]：Azure 的云采纳框架
|
||||
- [[Google-Cloud-Adoption-Framework]]：Google Cloud 的云采纳框架
|
||||
- [[Cloud-Center-of-Excellence-CCOE]]：云卓越中心
|
||||
|
||||
## Key Entities
|
||||
- [[Open-Alliance-for-Cloud-Adoption-OACA]]：提出 CMM 定义的组织
|
||||
- [[Forrester]]：预测全球 CMM 行业增长的研究公司
|
||||
- [[Gartner]]：指出云成熟度模型快速采纳的研究公司
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Maturity-Model]] ← defines ← [[Cloud-Adoption]]
|
||||
- [[Cloud-Maturity-Model]] ← evaluated_by ← [[Cloud-Security-Maturity-Model-CSMM]]
|
||||
- [[Cloud-Maturity-Model]] ← part_of ← [[AWS-Cloud-Adoption-Framework]]
|
||||
- [[Cloud-Maturity-Model]] ← part_of ← [[Azure-Cloud-Adoption-Framework]]
|
||||
- [[Cloud-Maturity-Model]] ← part_of ← [[Google-Cloud-Adoption-Framework]]
|
||||
- [[Cloud-Center-of-Excellence-CCOE]] ← supports ← [[Cloud-Maturity-Model]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: "Cloud Maturity Model - 企业云成熟度5级评估框架"
|
||||
type: source
|
||||
tags: [Cloud, Maturity, 云迁移, 评估框架]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud Maturity Model A Detailed Guide For Cloud Adoption.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：企业云成熟度模型（CMM）的5级评估框架与最佳实践
|
||||
- 问题域：云采用成熟度评估、云迁移战略、云治理
|
||||
- 方法/机制：5级成熟度模型（0-4：Legacy→Initial→Repeatable→Systematic→Measured→Optimized）
|
||||
- 结论/价值：Forrester 预测2025年全球云成熟度模型市场达15亿美元，60%+组织已实施
|
||||
|
||||
## Key Claims
|
||||
- 云成熟度模型帮助组织从业务和技术两个维度评估云采用准备度
|
||||
- 5级成熟度路径：Legacy（无云准备）→ Initial（初始准备）→ Repeatable（可重复）→ Systematic（系统化文档化）→ Measured（可测量）→ Optimized（优化）
|
||||
- 云成熟度三要素：People（技能与工作方式）、Processes（工作流优化）、Technology（基础设施适配）
|
||||
- 云成熟度最佳实践：设定目标→识别当前级别→选择模型→遵循治理合规→安全管理风险
|
||||
|
||||
## Key Quotes
|
||||
> "The cloud maturity model helps businesses make the most of their cloud journey by guiding them through the different stages of cloud adoption."
|
||||
|
||||
## Key Concepts
|
||||
- [[云成熟度模型]]：评估组织云采用准备度的框架
|
||||
- [[云迁移]]：从本地向云端迁移的过程
|
||||
- [[云治理]]：定义角色、职责、决策流程的框架
|
||||
- [[Cloud Native]]：云原生架构
|
||||
- [[Multi-Cloud]]：多云策略
|
||||
- [[Hybrid Cloud]]：混合云策略
|
||||
- [[CAPEX]]：资本支出
|
||||
- [[OPEX]]：运营支出
|
||||
- [[TCO]]：总拥有成本
|
||||
|
||||
## Key Entities
|
||||
- [[Forrester]]：市场研究机构
|
||||
- [[Gartner]]：市场研究机构
|
||||
- [[AWS]]：云服务提供商
|
||||
- [[Azure]]：云服务提供商
|
||||
- [[Google Cloud]]：云服务提供商
|
||||
- [[Open Alliance for Cloud Adoption]]：云采用联盟
|
||||
|
||||
## Connections
|
||||
- [[Cloud-DevOp-Maturity-Guideline]] ← relates_to ← [[Cloud-Maturity-Model]]
|
||||
- [[DevOps Culture and Transformation]] ← extends ← [[Cloud-Maturity-Model]]
|
||||
- [[How Agentic AI for Cloud DevOps]] ← extends ← [[Cloud-Maturity-Model]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[DevOps Culture and Transformation]] 无冲突，两者互补（DevOps成熟度 vs 云成熟度）
|
||||
@@ -1,57 +0,0 @@
|
||||
---
|
||||
title: "Cloud Operating Model: Key Strategies and Best Practices"
|
||||
type: source
|
||||
tags: [cloud, governance, finops, devops, security]
|
||||
date: 2025-02-07
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud Operating Model Key Strategies and Best Practices.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：企业级云运营模型（Cloud Operating Model）设计框架，涵盖治理、安全、成本优化和自动化四大支柱
|
||||
- 问题域：89% 企业将在 2025 年采用云优先架构，但缺乏结构化方法导致成本失控、安全漏洞和运维混乱
|
||||
- 方法/机制：六步设计法（成熟度评估→治理框架→自动化→FinOps→安全→持续优化）
|
||||
- 结论/价值：Cloud Operating Model 是云投资有效管理、安全运营和可持续优化的基础，不可或缺
|
||||
|
||||
## Key Claims
|
||||
- 89% 企业将在 2025 年运营在云上（Gartner），但缺乏结构化方法的公司面临意外成本和安全漏洞
|
||||
- 59% 企业经历云成本管理困难，8% 企业担忧可持续性和碳足迹（Flexera 2024）
|
||||
- Cloud Operating Model 四大支柱：治理与合规、自动化与编排、安全与风险管理、云财务管理（FinOps）
|
||||
- 云成熟度三阶段：Ad-hoc Cloud Adoption → Cloud-First Strategy → Cloud-Native Enterprise
|
||||
- Zero Trust 安全模型：零隐式信任，持续验证，而非传统边界防火墙
|
||||
- FinOps 三大策略：Reserved Instances（节省 40-70%）、Auto-Scaling + Right-Sizing、实时成本监控 + 资源标签化
|
||||
- 多云策略降低 40% 停机风险，Kubernetes 容器化实现工作负载可移植性
|
||||
- AI 驱动异常检测使 SaaS 提供商停机时间减少 45%
|
||||
|
||||
## Key Quotes
|
||||
> "A Cloud Operating Model is no longer optional—it is the backbone of modern cloud strategy." — Bacancy Technology
|
||||
|
||||
## Key Concepts
|
||||
- [[Cloud Operating Model]]：云运营模型，组织管理云资源、安全、自动化和成本的标准化框架
|
||||
- [[FinOps]]：云财务运营，通过实时追踪和优化防止云超支
|
||||
- [[Zero Trust]]：零信任安全模型，无隐式信任，持续验证身份和权限
|
||||
- [[Multi-Cloud]]：多云策略，避免供应商锁定，提高韧性和灵活性
|
||||
- [[IaC]]：Infrastructure as Code，Terraform/CloudFormation/Bicep 自动化基础设施部署
|
||||
- [[云治理]]：跨 AWS/Azure/GCP 的统一治理框架，IAM + 合规 + 成本策略
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：Amazon 云服务，提供 IAM/Cost Explorer/GuardDuty/CodePipeline
|
||||
- [[Azure]]：Microsoft 云平台，提供 Azure AD/Cost Management/Defender/Sentinel
|
||||
- [[GCP]]：Google 云平台，提供 Google IAM/Security Command Center/Billing Reports
|
||||
- [[Terraform]]：HashiCorp IaC 工具，跨云基础设施自动化
|
||||
|
||||
## Connections
|
||||
- [[Cloud Operating Model]] ← 治理框架 → [[DevOps]]
|
||||
- [[Cloud Operating Model]] ← 成本管理 → [[FinOps]]
|
||||
- [[Cloud Operating Model]] ← 安全模型 → [[Zero Trust]]
|
||||
- [[Cloud Operating Model]] ← 自动化支撑 → [[CI/CD Pipelines]]
|
||||
- [[Multi-Cloud]] ← 供应商选择 → [[Kubernetes]]（工作负载可移植性）
|
||||
|
||||
## Contradictions
|
||||
- 与单云策略对比：单云简单但存在供应商锁定风险，多云灵活但管理复杂度上升
|
||||
|
||||
## Related Wiki Pages
|
||||
- [[DevOps成熟度模型]]：DevOps 4 大支柱与 COM 四大支柱高度重叠
|
||||
- [[Multi-Cloud Governance]]：跨云治理是 COM 的核心组成部分
|
||||
- [[Serverless DevOps]]：AWS Lambda/Azure Functions 是 COM 自动化的关键工具
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: "Multi-Agent Content Factory"
|
||||
type: source
|
||||
tags: [agent, content, multi-agent, discord]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/content-factory.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Discord 内多 agent 内容工厂，研究→写作→设计链式协作
|
||||
- 问题域：内容创作三阶段（研究/写作/设计）全靠人工，AI 工具也需逐个 prompt
|
||||
- 方法/机制：Research Agent 扫描趋势 → Writing Agent 生成脚本 → Thumbnail Agent 生成配图，全流程定时自动执行
|
||||
- 结论/价值：链式 agent 威力在于前序输出喂给后序；Discord channel 便于分阶段 review
|
||||
|
||||
## Key Claims
|
||||
- 链式 agent 是核心：research → writing → thumbnails，每步输出自动喂给下一步
|
||||
- Discord channel 分离各 agent 工作便于 review 和反馈
|
||||
- 本地模型（如 Mac Studio 上的 Nano Banana）降低成本增加控制
|
||||
- 可适配任何内容格式：tweets/newsletter/LinkedIn/posts/podcast outlines/blog
|
||||
|
||||
## Key Quotes
|
||||
> "Content creation has three phases — research, writing, and design — and most creators are doing all three manually." — 痛点陈述
|
||||
> "The power is in the chained agents — research feeds writing, writing feeds thumbnails." — 核心价值
|
||||
|
||||
## Key Concepts
|
||||
- [[内容工厂]]：研究+写作+设计三阶段链式 agent 协作管线
|
||||
- [[链式 Agent]]：前序 agent 输出自动作为后序 agent 输入
|
||||
- [[Discord 集成]]：多 channel 分离各 agent 工作流
|
||||
|
||||
## Key Entities
|
||||
- [[Alex Finn]]：Life-changing OpenClaw use cases 视频作者，本内容工厂灵感来源
|
||||
|
||||
## Connections
|
||||
- [[Market Research Product Factory]] ← 共享研究 agent 基础设施
|
||||
- [[Last30Days]] ← Research Agent 数据来源
|
||||
- [[baoyu-imagine]] ← Thumbnail Agent 图像生成能力
|
||||
- [[Agentic AI]] ← 自主执行多步骤工作流
|
||||
- [[multi-agent-team]] ← 多 agent 协作模式
|
||||
|
||||
## Contradictions
|
||||
- 与单人内容创作流程对比：
|
||||
- 当前观点：多 agent 链式协作，人工降至最低
|
||||
- 对方观点：单人全流程控制质量更一致
|
||||
- 结论：质量控制需人工 review 环节，不可完全自动化
|
||||
@@ -1,70 +0,0 @@
|
||||
---
|
||||
title: "Cursor 2.0 初学者使用指南"
|
||||
type: source
|
||||
tags: [AI编程, Cursor, IDE, AI代理]
|
||||
date: 2025-12-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Vibe Coding/Cursor 2.0初学者使用指南.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Cursor 2.0 AI 代码编辑器完整入门教程
|
||||
- 问题域：初学者如何高效使用 AI 辅助编程工具
|
||||
- 方法/机制：规划驱动 → 多代理并行 → Diff 审查 → Git 版本控制
|
||||
- 结论/价值：Cursor 2.0 将 AI 代码生成整合进 VS Code，通过 Plan/Agent/Ask 三种模式实现精准控制
|
||||
|
||||
## Key Claims
|
||||
- Cursor 内置自研 [[Composer模型]]，生成速度比同类模型快 4 倍
|
||||
- AI 生成代码在 Diff 确认前已写入文件，**不是草稿状态**，需先测试再接受
|
||||
- [[MCP服务器]]（Model Context Protocol）允许 AI 代理集成外部 API 和工具，扩展能力边界
|
||||
- 多代理并行时，每个代理有独立上下文；继续同一任务应在同一代理内继续，避免上下文混乱
|
||||
|
||||
## Agent Modes（三核心模式）
|
||||
| 模式 | 行为 | 风险 |
|
||||
|------|------|------|
|
||||
| Plan | AI 生成开发计划（Markdown），用户可修改 | 无副作用，仅生成文本 |
|
||||
| Agent | AI 执行计划，读写文件，执行命令 | **会修改代码**，需审查 |
|
||||
| Ask | AI 回答问题，提供解释 | 无副作用，仅返回文本 |
|
||||
|
||||
## 核心工作流
|
||||
|
||||
### 规划驱动开发
|
||||
1. 明确项目目标（游戏/网站/后端工具）
|
||||
2. 用语音或文字向 AI 描述需求
|
||||
3. AI 生成 Plan 模式开发计划（Markdown 形式）
|
||||
4. 用户修改或批准计划
|
||||
|
||||
### 代码生成与审查
|
||||
1. 启动 Agent 模式执行计划
|
||||
2. 代码生成即写入文件（**非草稿**）
|
||||
3. Diff 视图逐文件审查改动
|
||||
4. 运行测试，确认无误后接受
|
||||
5. 未点"撤销"前可随时回退
|
||||
|
||||
### 多代理并行
|
||||
- 场景：同时开发游戏核心逻辑和 Landing Page
|
||||
- 每个代理有独立上下文，不相互干扰
|
||||
- 同一任务在同一代理内继续效果更佳
|
||||
|
||||
## Key Entities
|
||||
- [[Cursor]]：基于 VS Code 的 AI 增强代码编辑器，集成多 AI 模型
|
||||
- [[Composer模型]]：Cursor 自研 AI 模型，主打生成速度
|
||||
- [[MCP服务器]]：Model Context Protocol，AI 代理外部工具集成协议
|
||||
- [[Karpathy]]：提出"Vibe Coding"概念（AI 调整氛围，代码自动长出）
|
||||
|
||||
## Key Concepts
|
||||
- [[Vibe Coding]]：以产品逻辑和用户流程为导向，将代码体力活交给 AI，自己做导演而非打字员
|
||||
- [[Diff审查]]：AI 生成代码后逐文件审查改动的视图机制
|
||||
- [[Git版本控制]]：AI 生成代码风险更高，建议立即 commit，配合撤销按钮实现安全回滚
|
||||
- [[项目规则文件]]：可在项目目录添加规则文件（如强制 Doc Strings），AI 自动遵守
|
||||
|
||||
## Connections
|
||||
- [[Cursor]] ← 基于 ← [[VS Code]]
|
||||
- [[Cursor]] ← 集成 ← [[Composer模型]]
|
||||
- [[Cursor]] ← 扩展协议 ← [[MCP服务器]]
|
||||
- [[Vibe Coding]] ← 理论起源 ← [[Karpathy]]
|
||||
|
||||
## Contradictions
|
||||
- AI 生成即写入 vs 传统草稿模式：传统 AI 助手是"建议"，Cursor 是"直接执行"；用户需理解这是真实文件变更而非预览
|
||||
- Agent 模式 vs Ask 模式：Ask 仅文本回答不会改文件，但用户可能误用 Ask 去要求生成代码而得到不完整结果
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "Custom Morning Brief"
|
||||
type: source
|
||||
tags: [agent-use-case, automation, productivity, telegram]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/Custom-Morning-Brief.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：OpenClaw 定时主动任务——每日个性化晨报
|
||||
- 问题域：早晨 30 分钟用于刷新闻/查日历/看任务，"最生产力时间"浪费在信息获取而非决策
|
||||
- 方法/机制：定时任务（Telegram/Discord/iMessage）= 新闻聚合 + 待办推送 + AI 主动推荐任务
|
||||
- 结论/价值：利用夜间待机时间完成信息聚合，起床即可做决策
|
||||
|
||||
## Key Claims
|
||||
- 晨报核心价值：AI 主动推荐可代劳任务，而非仅推送信息
|
||||
- 夜间待机时间利用：用户睡眠期间 AI 完成研究任务，产出可直接使用（完整脚本/商业提案）
|
||||
- 自定义接口：用户只需通过短信向 Bot 说明需求，AI 自动调整晨报结构
|
||||
- Alex Finn 的视频激发此工作流设计
|
||||
|
||||
## Key Quotes
|
||||
> "You're spending your most productive morning hours just getting oriented. Meanwhile, your AI agent sits idle all night. The morning brief turns idle overnight hours into productive prep time — you wake up to work already done."
|
||||
|
||||
> "Full drafts (not just ideas) are the key to saving time. Wake up to scripts, not suggestions."
|
||||
|
||||
## Key Concepts
|
||||
- [[定时主动任务]]：Agent 在无用户请求时主动执行并推送结果，而非等待 prompt
|
||||
- [[晨报自动化]]：早晨信息聚合+任务推荐一体化工作流
|
||||
- [[AI推荐任务]]：Agent 主动识别可代劳事项，是晨报最有价值的部分
|
||||
|
||||
## Key Entities
|
||||
- [[Alex Finn]]：YouTube 视频《Life-Changing OpenClaw Use Cases》作者，激发晨报工作流设计
|
||||
- [[OpenClaw]]：晨报工作流的执行平台，支持 Telegram/Discord/iMessage 多渠道推送
|
||||
|
||||
## Connections
|
||||
- [[Alex Finn]] ← inspired ← [[Custom Morning Brief]]
|
||||
- [[Custom Morning Brief]] ← implements ← [[定时主动任务]]
|
||||
- [[定时主动任务]] ← uses ← [[OpenClaw]]
|
||||
- [[Custom Morning Brief]] ← integrates ← [[Todoist]]（任务获取）
|
||||
- [[Custom Morning Brief]] ← integrates ← [[x-research-v2]]（社交热点研究，可选）
|
||||
|
||||
## Contradictions
|
||||
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
title: "Daily Reddit Digest"
|
||||
type: source
|
||||
tags: [agent-use-case, reddit, content-curation, automation]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/Daily-Reddit-Digest.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：OpenClaw Agent 每日 Reddit 内容聚合工作流
|
||||
- 问题域：手动浏览多个 subreddit 费时，热门帖子筛选依赖算法而非人工判断
|
||||
- 方法/机制：reddit-readonly skill 读取指定 subreddits（hot/new/top）+ AI 按偏好规则过滤 + 每日定时推送
|
||||
- 结论/价值：Read-only 模式只读不互动，建立内容偏好记忆实现个性化digest
|
||||
|
||||
## Key Claims
|
||||
- reddit-readonly skill 无需认证，直接读取 Reddit 热门/New/Top 帖子
|
||||
- AI 维护内容偏好记忆（memory），随时间优化 digest 质量
|
||||
- 每日下午 5 点定时执行，自动推送 Telegram/指定渠道
|
||||
- Read-only 约束：无发帖/投票/评论，仅信息消费
|
||||
|
||||
## Key Quotes
|
||||
> "Create a separate memory for the reddit processes, about the type of posts I like to see and every day ask me if I liked the list you provided. Save my preference as rules in the memory to use for a better digest curation."
|
||||
|
||||
## Key Concepts
|
||||
- [[Reddit内容聚合]]：多 subreddit 热门/New/Top 帖子批量获取与筛选
|
||||
- [[内容偏好记忆]]：AI 维护用户内容偏好规则，实现 digest 个性化
|
||||
- [[定时内容推送]]：每日固定时间自动执行并推送 digest
|
||||
- [[Read-only API]]：仅消费数据不产生互动，降低账号风险
|
||||
|
||||
## Key Entities
|
||||
- [[reddit-readonly]]：ClawHub 插件，无需认证的 Reddit 只读 skill
|
||||
- [[Reddit]]：美国最大社区内容平台，AMAs/hot/new/top 多维度排序
|
||||
|
||||
## Connections
|
||||
- [[Daily Reddit Digest]] ← uses ← [[reddit-readonly]]
|
||||
- [[Daily Reddit Digest]] ← stores ← [[内容偏好记忆]]
|
||||
- [[reddit-readonly]] ← reads ← [[Reddit]]
|
||||
- [[Daily Reddit Digest]] ← triggers ← [[定时内容推送]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: "Dataview——让我从"笔记黑洞"里逃出来的 Obsidian 神器"
|
||||
type: source
|
||||
tags: [Obsidian插件, 笔记管理, 信息检索]
|
||||
date: 2025-03-07
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/未分类/Dataview——让我从笔记黑洞里逃出来的Obsidian神器.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Dataview 插件将 Obsidian 变成"笔记数据库"，实现笔记内容的结构化索引与查询
|
||||
- 问题域：Obsidian 用户普遍面临的"写笔记容易、查笔记难"困境
|
||||
- 方法/机制：Dataview 通过类 SQL 语法对笔记元数据和内容进行查询，支持任务聚合、标签整理、统计写作量三大核心场景
|
||||
- 结论/价值：把散落在各处的碎片笔记盘活为可检索、可统计、可视图化的知识资产
|
||||
|
||||
## Key Claims
|
||||
- Dataview 是 Obsidian 生态中最强大的"笔记数据库"插件，将笔记内容索引为可查询的结构化数据
|
||||
- 任务自动聚合功能解决了"待办散落在各文件"的问题，在单一视图集中展示所有待办事项
|
||||
- 标签笔记整理通过 `LIST FROM #学习` 自动聚合所有含该标签的笔记，实现按主题盘活笔记
|
||||
- 写作量统计功能帮助写作者量化写作进度，追踪每日/每周/每月的笔记产出
|
||||
|
||||
## Key Quotes
|
||||
> "写笔记容易，查笔记难" — Obsidian 用户的核心痛点，Dataview 直接解决此问题
|
||||
|
||||
## Key Concepts
|
||||
- [[笔记数据库]]：将散乱的笔记文本转化为结构化可查询数据的机制
|
||||
- [[任务自动聚合]]：将分散在多文件的待办事项集中到单一视图的能力
|
||||
- [[标签笔记整理]]：通过标签自动索引相关笔记，按主题组织知识资产
|
||||
- [[写作量统计]]：量化写作产出的统计功能，帮助追踪写作习惯
|
||||
|
||||
## Key Entities
|
||||
- [[Dataview]]：Obsidian 插件，将笔记变为可查询的数据库
|
||||
- [[Obsidian]]：本地笔记与知识管理应用，双向链接笔记系统
|
||||
|
||||
## Connections
|
||||
- [[Dataview]] ← 使用 → [[Obsidian]]
|
||||
- [[笔记数据库]] ← extends ← [[RAG]]（两者都解决"检索"问题，但层次不同）
|
||||
- [[笔记数据库]] ← related ← [[LLM Wiki]]（Dataview 索引 + LLM 推理 = 更强知识管理）
|
||||
- [[任务自动聚合]] ← related ← [[Agentic-AI]]（Agent 也需要任务聚合能力）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[RAG]] 相比：
|
||||
- 冲突点：RAG 通过向量语义检索，Dataview 通过结构化字段查询
|
||||
- 当前观点：Dataview 适合结构明确的元数据查询（日期/标签/任务状态）
|
||||
- 对方观点：RAG 适合语义模糊的自然语言检索，两者适用场景互补
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "Designing for Agentic AI"
|
||||
type: source
|
||||
tags: [agentic-ai, ux-design, product-design]
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Designing for Agentic AI.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Agentic AI（智能体AI）的产品设计原则，与 GenAI 的本质区别
|
||||
- 问题域：AI 产品设计范式从"响应用户输入"向"主动代理"转变
|
||||
- 方法/机制：五大设计原则——透明度（Transparency）、控制权（Control）、个性化（Personalization）、对话（Conversation）、预判（Anticipation）
|
||||
- 结论/价值：用户与 AI 的交互模式从"点击按钮"转变为"观察AI推理过程"
|
||||
|
||||
## Key Claims
|
||||
- GenAI 擅长创作内容（文本/图像/音乐），Agentic AI 擅长行动，能够与环境交互、做出决策、预判需求
|
||||
- Agentic AI 引入新维度：主动型智能体预判需求并自主行动
|
||||
- 用户观察AI决策过程本身就是一种交互形式，用户并非被动
|
||||
- 设计重点从"响应用户动作"转向"提供AI运行时的实时反馈"
|
||||
|
||||
## Key Quotes
|
||||
> "Agentic AI is pushing us to reimagine product design. For years, we've focused on interfaces that react to direct user input—clicks, swipes, and edits."
|
||||
> "Users should be able to understand how the AI is making decisions. This can be achieved by visualizing the AI's progress."
|
||||
> "Users should always feel in control of the AI."
|
||||
|
||||
## Key Concepts
|
||||
- [[GenAI]]：生成式AI，擅长创作内容（文本/图像/音乐）
|
||||
- [[Agentic-AI]]：智能体AI，能与环境交互、决策、预判需求
|
||||
- [[透明度原则]]：用户应能理解AI决策过程，通过可视化AI进度实现
|
||||
- [[控制权原则]]：用户应能停止AI任务或撤销AI已执行的操作
|
||||
- [[个性化原则]]：AI应适应个体用户需求与偏好
|
||||
- [[对话原则]]：设计自然语言对话界面，允许用户用自然语言与AI交互
|
||||
- [[预判原则]]：AI应能预判用户需求并主动提供帮助
|
||||
|
||||
## Key Entities
|
||||
- [[Yuri-Pessa]]：LinkedIn文章作者
|
||||
|
||||
## Connections
|
||||
- [[GenAI]] ← 对比 → [[Agentic-AI]]
|
||||
- [[Agentic-AI]] ← 驱动 → [[AI-Agent-Architecture]]
|
||||
- [[透明度原则]] ← 支撑 → [[Agentic-AI]]
|
||||
|
||||
## Contradictions
|
||||
@@ -1,58 +1,72 @@
|
||||
---
|
||||
title: "DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation"
|
||||
type: source
|
||||
tags: [DevOps, 转型, 文化]
|
||||
date: 2025-03-02
|
||||
tags: [DevOps, Agile, 文化转型, 协作, 自动化]
|
||||
date: 2001-02-27
|
||||
source_file: raw/Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation LinkedIn.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation LinkedIn.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：DevOps 文化与数字化转型方法论，超越工具层面进入思维模式转变
|
||||
- 问题域：打破开发与运维的孤岛，提升软件交付速度与可靠性
|
||||
- 方法/机制：四大支柱框架、敏捷整合、战略转型 playbook、AI/ML 赋能趋势
|
||||
- 结论/价值：DevOps 是持续演进而非一次性项目，拥抱文化原则、授权团队、整合敏捷实践是制胜关键
|
||||
本文阐述 DevOps 文化与转型的核心原则与实践方法。DevOps 并非仅关于工具或自动化，而是一种优先考虑协作、持续学习和客户导向的文化与运营变革。文章涵盖 DevOps 文化的四大支柱、敏捷实践整合方法，以及驱动 DevOps 转型的战略蓝图，并展望了 AI/ML、GitOps、Serverless DevOps、Edge Computing IoT DevOps 和 DevSecOps 等未来趋势。
|
||||
|
||||
## Key Claims
|
||||
- DevOps 的本质是文化与运营革命，不只是工具和自动化
|
||||
- 四大支柱：协作优先、自动化赋能者、持续改进（Kaizen）、客户中心
|
||||
- 敏捷与 DevOps 是共生关系：敏捷聚焦迭代开发，DevOps 将敏捷扩展到运维
|
||||
- 变革领导者必须以身作则，将 DevOps 目标与业务成果对齐
|
||||
- 最小化可行产品（MVP）试点快速验证价值，再迭代扩展到整个企业
|
||||
- 传统灾难恢复已过时：现代 DevOps 的最大风险是代码缺陷而非硬件故障
|
||||
- GitOps 将 Git 作为单一真实源管理基础设施和部署
|
||||
- Serverless DevOps 通过 FaaS（Lambda）减少运维开销
|
||||
- Edge Computing DevOps 实现更接近终端用户的实时应用性能优化
|
||||
- DevOps 打破开发（Dev）与运维（Ops）之间的壁垒，通过跨职能团队实现整个软件生命周期的共同所有权
|
||||
- 自动化消除手动劳动，减少错误，加速反馈循环
|
||||
- DevOps 依赖迭代学习，通过无责复盘（blameless post-mortems）和混沌工程持续改进
|
||||
- 敏捷与 DevOps 具有共生关系，敏捷专注迭代开发，DevOps 将敏捷扩展到运维领域
|
||||
- DevOps 转型需要领导层支持、团队技能提升、小规模试点和逐步扩展
|
||||
|
||||
## Key Quotes
|
||||
> "DevOps isn't a checkbox—it's a continuous evolution." — 核心洞察
|
||||
> "Organizations that embrace its cultural tenets, empower teams, and integrate Agile practices will not only survive but thrive in the digital age."
|
||||
> "DevOps isn't just about tools or automation; it's a mindset shift that prioritizes collaboration, continuous learning, and customer-centricity." — 核心定义
|
||||
> "DevOps isn't a checkbox—it's a continuous evolution." — 关于 DevOps 本质
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps]]：开发与运维团队之间的文化与运营革命，打破孤岛、加速交付
|
||||
- [[Kaizen]]：持续小步改进，DevOps 文化的第三支柱
|
||||
- [[CI/CD Pipelines]]：Jenkins/GitHub Actions/GitLab CI 自动化测试、集成、部署流水线
|
||||
- [[Infrastructure as Code]]：Terraform/AWS CloudFormation 实现版本控制的环境管理
|
||||
- [[DevSecOps]]：在 CI/CD 中内置安全，SonarQube/Snyk 集成
|
||||
- [[GitOps]]：以 Git 作为单一真实源管理配置和部署
|
||||
- [[Feature Flag]]：部署与发布分离，支持渐进式发布和即时回滚
|
||||
- [[Chaos Engineering]]：主动测试系统韧性的工程实践
|
||||
- [[DevOps 文化]]：一种优先协作、持续学习和客户导向的文化理念
|
||||
- [[跨职能团队]]：开发与运维共享整个软件生命周期所有权的团队模式
|
||||
- [[CI/CD 流水线]]：自动化测试、集成和部署的持续集成/持续交付管道
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码实现一致性和版本控制的基础设施管理
|
||||
- [[持续改进 (Kaizen)]]：通过迭代学习不断优化流程的文化实践
|
||||
- [[无责复盘]]：不追究个人责任，聚焦问题本质的失败分析方法
|
||||
- [[混沌工程]]：主动测试系统韧性的实践方法
|
||||
- [[客户导向]]：以真实用户问题解决为核心的产品开发理念
|
||||
- [[特性开关]]：逐步发布功能以收集用户反馈的策略
|
||||
- [[A/B 测试]]：通过数据驱动决策优化用户体验
|
||||
- [[Agile 框架]]：Scrum（结构化迭代）和 Kanban（持续流）等敏捷方法论
|
||||
- [[Shift-Left 实践]]：将运维相关 concerns（安全、性能）前置到开发阶段
|
||||
- [[DevSecOps]]：在 CI/CD 流水线中深度集成安全工具
|
||||
- [[价值流映射]]：可视化工作流以消除浪费、识别延迟
|
||||
- [[价值流管理]]：通过价值流映射优化交付流程
|
||||
- [[GitOps]]：使用 Git 作为单一真相源来管理基础设施和部署
|
||||
- [[Serverless DevOps]]：利用函数即服务（FaaS）减少运维开销
|
||||
- [[AI/ML 在 DevOps 中的应用]]：智能自动化用于代码审查、异常检测和自愈基础设施
|
||||
|
||||
## Key Tools
|
||||
- CI/CD 工具：Jenkins、GitLab CI、GitHub Actions
|
||||
- IaC 工具：Terraform、AWS CloudFormation
|
||||
- 监控与可观测性工具：Prometheus、Grafana、Datadog
|
||||
- 团队协作工具：Slack、Microsoft Teams、Atlassian Jira
|
||||
- 安全工具：SonarQube、Snyk
|
||||
- 性能测试工具：JMeter、Locust
|
||||
- 容器化与编排：Docker、Kubernetes
|
||||
- 配置管理：Ansible
|
||||
- Serverless：AWS Lambda
|
||||
|
||||
## Key Entities
|
||||
- [[Atlassian]]：Jira 平台提供跨职能团队实时协作与工作流可见性
|
||||
- [[Jenkins]]：开源 CI/CD 自动化服务器
|
||||
- [[HashiCorp]]：Terraform 基础设施即代码工具的开发商
|
||||
- [[Slack]]：跨职能团队实时沟通透明化平台
|
||||
（未发现具体人物或公司为关键实体）
|
||||
|
||||
## Connections
|
||||
- [[DevOps]] ← 是 [[DevOps成熟度模型]] 的文化基础
|
||||
- [[DevOps]] ← 整合 [[Agile]] 实践形成完整交付体系
|
||||
- [[CI/CD Pipelines]] ← 依赖 [[Infrastructure as Code]] 实现环境一致性
|
||||
- [[DevSecOps]] ← 是 [[DevOps]] 的安全内嵌实践
|
||||
- [[GitOps]] ← 延伸 [[CI/CD Pipelines]] 以 Git 为单一真实源
|
||||
- [[DevOps 文化]] ← 是核心主题 ← [[敏捷实践整合]]
|
||||
- [[自动化]] ← 加速反馈循环 ← [[CI/CD 流水线]]
|
||||
- [[持续改进]] ← 通过 [[无责复盘]] 和 [[混沌工程]] 实现
|
||||
- [[客户导向]] ← 通过 [[特性开关]] 和 [[A/B 测试]] 实现
|
||||
- [[Agile 框架]] ← 与 [[DevOps 文化]] 协同 ← [[Shift-Left 实践]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统 IT 对比：传统观点认为"硬件故障是最大风险"，本文认为"代码缺陷才是现代 DevOps 的最大风险"
|
||||
- 当前观点：风险重心已从硬件转向软件交付过程
|
||||
- 对方观点：灾难恢复计划仍需覆盖物理基础设施故障
|
||||
（暂无冲突记录）
|
||||
|
||||
## Trends (未来趋势)
|
||||
- AI/ML in DevOps：代码审查、异常检测、自愈基础设施
|
||||
- GitOps：Git 即单一真相源
|
||||
- Serverless DevOps：FaaS 减少运维开销
|
||||
- Edge Computing IoT DevOps：边缘计算支持实时应用性能优化
|
||||
- DevSecOps：安全深度嵌入 CI/CD 流程
|
||||
|
||||
@@ -1,54 +1,41 @@
|
||||
---
|
||||
title: "DevOps Maturity Model: From Traditional IT to Advanced DevOps"
|
||||
title: "DevOps Maturity Model From Traditional IT to Advanced DevOps"
|
||||
type: source
|
||||
tags: [devops, maturity-model, dora, cloud, transformation]
|
||||
date: 2026-04-15
|
||||
tags: [DevOps, Maturity Model, Cloud & DevOps]
|
||||
date: 2024-08-14
|
||||
source_file: raw/Cloud & DevOps/DevOps Maturity Model From Traditional IT to Advanced DevOps.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/DevOps Maturity Model From Traditional IT to Advanced DevOps.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：DevOps 成熟度 5 阶段评估框架，从传统 IT 到完全成熟 DevOps 的演进路径
|
||||
- 问题域：组织评估当前 DevOps 能力、识别改进方向、制定进阶路线图
|
||||
- 方法/机制：4 大焦点领域（文化/自动化/结构流程/协作）+ 5 阶段成熟度评估
|
||||
- 结论/价值：成熟度模型提供结构化自评工具，帮助组织量化 DevOps 转型进展
|
||||
本文介绍了 DevOps 成熟度模型，一个用于评估组织 DevOps 实践水平的分级框架。该模型涵盖五个阶段：从初始/应急阶段（传统瀑布式开发）到完全成熟阶段（持续部署）。模型从文化与战略、自动化、结构与流程、协作与共享、技术五个关键领域进行评估，并提供具体的业务收益、安全集成方法和常见障碍分析。
|
||||
|
||||
## Key Claims
|
||||
- DevOps 成熟度评估 4 大焦点：Culture & Strategy（文化战略）/ Automation（自动化）/ Structure & Process（结构流程）/ Collaboration（协作）
|
||||
- Phase 1（Ad-Hoc）：团队孤立、瀑布式交付、手动基础设施管理、安全仅在发布前介入
|
||||
- Phase 2（Pockets）：小规模试点、引入 Agile 版本控制、自动化降低发布风险
|
||||
- Phase 3（Defined）：标准化流程、大部分基础设施自动化、安全融入设计阶段
|
||||
- Phase 4（Optimized）：不可变基础设施、CI/CD 流水线成熟、技术债务管理、性能负载测试
|
||||
- Phase 5（Mature）：每天多次部署、零人工干预、安全内嵌、实时数据驱动决策
|
||||
- DevOps 成熟度模型通过五个阶段帮助组织评估当前实践水平并制定改进路线图
|
||||
- 五个成熟度阶段分别为：初始/应急阶段、局部 DevOps、自动化与定义阶段、高度优化阶段、完全成熟阶段
|
||||
- 成熟度评估的四个关键领域包括：文化与战略、自动化、结构与流程、协作与共享、技术
|
||||
- 高质量 DevOps 成熟度模型应包含：评估标准、成熟度等级、DevOps 实践、相关指标、文化指南、工具与技术、角色与职责
|
||||
- 采用 DevOps 成熟度模型可带来更快的调整能力、更好的扩展性、增强的运营绩效、更快的交付时间、改进的质量
|
||||
|
||||
## Key Quotes
|
||||
> "The core of DevOps security is merging development, operations, and security into a unified process" — Bacancy Technology
|
||||
> "Companies with advanced DevOps practices can seize new opportunities more effectively. Their capability to rapidly deploy updates and services enables them to introduce innovative products and enter new markets ahead of their competitors"
|
||||
> "The DevOps maturity model is a structured framework that guides organizations through adopting and implementing DevOps principles." — DevOps 成熟度模型定义
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps]]：开发与运维一体化，强调协作、自动化、持续改进
|
||||
- [[DevOps成熟度模型]]：5 阶段评估框架（Ad-Hoc → Pockets → Defined → Optimized → Mature）
|
||||
- [[DORA指标]]：部署频率/变更前置时间/变更失败率/MTTR，Google 提出的 DevOps 效能四指标
|
||||
- [[DevSecOps]]：安全融入 DevOps 全流程，而非单独阶段介入
|
||||
- [[Kaizen]]：持续改进，DevOps 文化的核心原则
|
||||
- [[不可变基础设施]]：不更新旧服务器，而是替换为新服务器，减少配置漂移
|
||||
- [[DevOps 成熟度模型]]：评估组织 DevOps 实践水平的五级框架
|
||||
- [[DevOps]]：结合开发与运营实现持续软件交付的方法论
|
||||
- [[CI/CD 流水线]]：自动化测试、集成和部署的持续交付管道
|
||||
- [[DevSecOps]]：在 CI/CD 流水线中深度集成安全工具的文化理念
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码实现一致性、版本控制的基础设施管理
|
||||
- [[敏捷实践]]：Scrum、Kanban 等迭代开发方法论
|
||||
|
||||
## Key Entities
|
||||
- [[DORA]]（DevOps Research and Assessment）：Google 团队，提出四指标效能评估框架
|
||||
- [[Bacancy Technology]]：内容发布方，提供 DevOps 成熟度模型详细解读
|
||||
（本文档未涉及需要创建页面的人、公司或产品实体）
|
||||
|
||||
## Connections
|
||||
- [[DevOps Culture and Transformation]] ← 理论补充 ← [[DevOps成熟度模型]]
|
||||
- [[Cloud DevOp Maturity - Guideline]] ← 同一领域 ← [[DevOps成熟度模型]]
|
||||
- [[Cloud Maturity Model]] ← 关联评估 ← [[DevOps成熟度模型]]
|
||||
- [[CI/CD Pipelines]] ← 核心实践 ← Phase 3-5 的关键使能技术
|
||||
- [[DevOps 成熟度模型]] ← extends ← [[DevOps]]
|
||||
- [[DevOps 成熟度模型]] ← includes ← [[CI/CD 流水线]]
|
||||
- [[DevOps 成熟度模型]] ← includes ← [[DevSecOps]]
|
||||
- [[DevOps 成熟度模型]] ← includes ← [[Infrastructure as Code (IaC)]]
|
||||
- [[DevOps 成熟度模型]] ← includes ← [[敏捷实践]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Cloud DevOp Maturity - Guideline]] 部分重叠：
|
||||
- 冲突点：该文 5 阶段模型与 Cloud DevOp Maturity Guideline 的 DORA 评估体系表述方式不同
|
||||
- 当前观点：5 阶段成熟度模型更侧重组织文化与流程演进
|
||||
- 对方观点：DORA 四指标更量化、更聚焦交付效能
|
||||
|
||||
## Related Links
|
||||
- [DevOps Maturity Model 原文](https://www.bacancytechnology.com/blog/devops-maturity-model)
|
||||
（暂无）
|
||||
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
title: "Event Guest Confirmation"
|
||||
type: source
|
||||
tags: [agent-use-case, voice-ai, supercall, twilio]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/Event-Guest-Confirmation.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：SuperCall 批量外呼确认活动出席
|
||||
- 问题域：20+ 人活动手动电话确认费时费力——电话tag、遗忘记录、饮食限制/Plus-one 收集困难
|
||||
- 方法/机制：SuperCall AI 语音 Agent 逐一呼叫宾客人列，收集出席意向和备注，编译汇总报告
|
||||
- 结论/价值：批量外呼+结构化汇总，单次电话费用（Twilio分钟计费）
|
||||
|
||||
## Key Claims
|
||||
- SuperCall 是完全独立的语音 Agent，呼叫过程不访问 OpenClaw Gateway，无数据泄露风险
|
||||
- AI Persona 沙箱化：每通电话独立上下文，不跨对话记忆，防止对话操纵
|
||||
- 调用链路：SuperCall → OpenAI GPT-4o Realtime API → Twilio 拨号
|
||||
- 完整工作流：准备宾客人列 → 单个外呼 → 记录结果 → 全量汇总
|
||||
|
||||
## Key Quotes
|
||||
> "SuperCall is a fully standalone voice agent. The AI persona on the call only has access to the context you provide (the persona name, the goal, and the opening line). It cannot access your gateway agent, your files, your other tools, or anything else."
|
||||
|
||||
## Key Concepts
|
||||
- [[AI外呼确认]]：AI 语音 Agent 批量执行活动出席确认
|
||||
- [[沙箱化 Persona]]：独立上下文重置，隔离每通电话防止数据泄露
|
||||
- [[AI Persona]]：AI 外呼中扮演特定角色的对话 Agent
|
||||
|
||||
## Key Entities
|
||||
- [[SuperCall]]：OpenClaw 语音外呼插件，@xonder/supercall，GPT-4o Realtime 语音驱动
|
||||
- [[Twilio]]：电话拨号基础设施，按分钟计费
|
||||
- [[OpenAI Realtime API]]：GPT-4o Realtime 语音模型，支撑 SuperCall 对话能力
|
||||
|
||||
## Connections
|
||||
- [[Event Guest Confirmation]] ← uses ← [[SuperCall]]
|
||||
- [[SuperCall]] ← calls ← [[OpenAI Realtime API]]
|
||||
- [[SuperCall]] ← dials via ← [[Twilio]]
|
||||
- [[Event Guest Confirmation]] ← applies ← [[沙箱化 Persona]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "GOG CLI 安装配置指南"
|
||||
type: source
|
||||
tags: [gog, gog-cli, macos, google-workspace]
|
||||
date: 2026-03-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Skills/GOG-CLI-安装配置指南.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：macOS 系统通过命令行管理 Google Workspace（Gmail/Calendar/Drive/Contacts/Docs/Sheets）
|
||||
- 问题域：打破 GUI 限制，实现 Google 服务的脚本化与自动化
|
||||
- 方法/机制：Homebrew 安装 → OAuth 授权 → API 服务启用 → 命令行调用
|
||||
- 结论/价值：gog CLI 将 Google Workspace 全部服务纳入终端，支撑日历/邮件自动化工作流
|
||||
|
||||
## Key Claims
|
||||
- gog CLI 是 macOS 专属工具，通过 Homebrew 安装，路径为 /opt/homebrew/bin/gog
|
||||
- Google API 访问需满足双重条件：OAuth 用户身份认证 + Google Cloud API Enablement 均通过
|
||||
- 403 accessNotConfigured 错误的根因是 Google Cloud 项目未启用对应 API，而非权限问题
|
||||
- 添加测试用户是绕过 Google 第三方应用验证限制的标准方法
|
||||
|
||||
## Key Quotes
|
||||
> "此应用未经 Google 验证——此应用请求访问您 Google 账号中的敏感信息" — OAuth 安全限制说明
|
||||
> "旧 token 不包含新权限" — 启用 API 后必须重新授权的原因
|
||||
|
||||
## Key Concepts
|
||||
- [[Google Workspace CLI]]：命令行管理 Google 全部服务
|
||||
- [[OAuth 双层验证]]：OAuth 凭证 + API Enablement 双重条件
|
||||
- [[gog CLI]]：macOS Google Workspace 命令行工具
|
||||
|
||||
## Key Entities
|
||||
- [[Google Cloud Console]]：OAuth 凭证创建与 API 启用管理平台
|
||||
- [[gogcli]]：工具本身，Homebrew 安装的 Google Workspace CLI
|
||||
|
||||
## Connections
|
||||
- [[gog CLI]] ← 安装于 ← [[macOS]]
|
||||
- [[gog CLI]] ← 依赖 ← [[Google Cloud Console]]（凭证 + API）
|
||||
- [[gog CLI]] ← 支持 ← [[Gmail]] / [[Google Calendar]] / [[Google Drive]] / [[Google Contacts]] / [[Google Docs]] / [[Google Sheets]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
title: "Git Push 连接重置问题修复"
|
||||
type: source
|
||||
tags: [github, git, proxy, socks5, network]
|
||||
date: 2025-03-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Git Push 连接重置问题修复.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：GitHub Push 报 `Recv failure: Connection was reset` 的修复方案
|
||||
- 问题域：国内访问 GitHub 时 TCP 连接被 GFW 阻断，间歇性 TLS 握手失败
|
||||
- 方法/机制：分别为 Git 配置 HTTP/SOCKS5 代理，或切换为 SSH 协议并配置代理
|
||||
- 结论/价值：国内环境 Git 操作必须走本地代理，SOCKS5 速度通常优于 HTTP 代理
|
||||
|
||||
## Key Claims
|
||||
- `Connection was reset` 是 TCP 层面中断，非权限问题；GFW 检测到 GitHub 域名后发送 TCP RST 包阻断连接
|
||||
- 间歇性原因是 GitHub CDN 多 IP 部分被封锁
|
||||
- HTTP 代理命令：`git config --global http.proxy http://127.0.0.1:10809`
|
||||
- SOCKS5 代理命令：`git config --global http.proxy socks5://127.0.0.1:10808`
|
||||
- SSH 协议切换：`git remote set-url origin git@github.com:username/repo.git`
|
||||
- Linux/Mac SSH 走代理：`ProxyCommand nc -X 5 -x 127.0.0.1:10808 %h %p`
|
||||
- Windows Git SSH 走代理：`ProxyCommand connect -S 127.0.0.1:10808 %h %p`
|
||||
- 取消代理：`git config --global --unset http.proxy && git config --global --unset https.proxy`
|
||||
|
||||
## Key Quotes
|
||||
> "Recv failure: Connection was reset（连接重置）并不是账号权限验证失败，而是 TCP 连接层面的中断" — 诊断关键：区分网络层 vs 应用层错误
|
||||
|
||||
## Key Concepts
|
||||
- [[TCP RST 攻击]]：GFW 通过发送 TCP Reset 包阻断连接，非包过滤
|
||||
- [[Git HTTP/SOCKS5 代理]]：通过 `http.proxy` / `https.proxy` 全局配置让 Git 流量走本地代理
|
||||
- [[Git SSH 协议切换]]：将远程地址从 HTTPS 改为 SSH，规避 443 端口干扰
|
||||
- [[SSH ProxyCommand]]：通过 `connect`（Windows）或 `nc`（Linux/Mac）让 SSH 走 SOCKS5 代理
|
||||
- [[GFW 封锁特征]]：GitHub 域名被 DPI 检测后触发 TCP RST，CDN 节点部分被封导致间歇性
|
||||
|
||||
## Key Entities
|
||||
- [[GitHub]]：全球最大代码托管平台，国内访问受 GFW 干扰
|
||||
- [[V2RayN]]：本地 SOCKS5/HTTP 代理工具，监听 10808/10809 端口
|
||||
- [[Clash]]：代理客户端，同样支持 SOCKS5 和 HTTP 出局
|
||||
|
||||
## Connections
|
||||
- [[Git HTTP/SOCKS5 代理]] ← solves ← [[TCP RST 攻击]]
|
||||
- [[Git SSH 协议切换]] ← alternative_to ← [[Git HTTP/SOCKS5 代理]]
|
||||
- [[V2RayN]] ← provides ← [[SOCKS5 代理]]
|
||||
- [[GitHub]] ← blocked_by ← [[GFW 封锁特征]]
|
||||
|
||||
## Contradictions
|
||||
- 与其他 Git 代理方案（如 `gh proxy`、VPN 全局模式）相比：本文方法仅影响 Git 命令，不干扰终端其他网络请求
|
||||
|
||||
## Metadata
|
||||
- 作者：shenwei
|
||||
- 创建时间：2025-03-16
|
||||
- 原始标签：[github, proxy, push, socks5]
|
||||
@@ -1,60 +0,0 @@
|
||||
---
|
||||
title: "GitHub 上 5000 人收藏的 Vibe Coding 神级指南"
|
||||
type: source
|
||||
tags: [AI编程, Vibe-Coding, GitHub, 提示词]
|
||||
date: 2025-12-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/GitHub 上 5000 人收藏的 Vibe Coding 神级指南。.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：vibe-coding-cn 中文 Vibe Coding 资源库介绍
|
||||
- 问题域：中文开发者缺乏系统性 AI 编程资源
|
||||
- 方法/机制：整合全球顶尖 AI 编程工具、提示词库和开发流程，提供中文一站式指南
|
||||
- 结论/价值：Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行，让从想法到可维护代码成为可审计流水线
|
||||
|
||||
## Key Claims
|
||||
- Vibe Coding 本质是 **导演思维**：保持对产品逻辑、用户流程、审美的把握，体力活交给 AI
|
||||
- Karpathy："我几乎不写代码了，我只负责调整氛围，代码会自动长出来"
|
||||
- vibe-coding-cn 核心公式：**Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行**
|
||||
- 推荐工具链：Cursor + claude-opus-4.5-xhigh 是最稳妥组合
|
||||
|
||||
## Key Concepts
|
||||
|
||||
### Vibe Coding 定义
|
||||
以产品目标为导向而非代码执行为导向的 AI 辅助开发范式。核心是将开发者从"打字员"转型为"产品导演"。
|
||||
|
||||
### 规划驱动
|
||||
AI 写代码前必须有清晰的技术选型、实施规划和模块化设计。防止 AI 因理解偏差导致项目逻辑混乱。
|
||||
|
||||
### 上下文固定
|
||||
通过项目规则文件、上下文管理，使 AI 在长对话中保持一致理解，避免"上下文遗忘"问题。
|
||||
|
||||
### AI 结对执行
|
||||
[[Cursor]]/[[Windsurf]]/[[Trae]] 等工具作为"第二开发者"，与人类形成结对编程关系。
|
||||
|
||||
## 资源库核心模块
|
||||
1. **方法论**：设计准则和哲学理念
|
||||
2. **AI 模型与 IDE**：工具链筛选和配置指南
|
||||
3. **提示词优化**：数百个精选提示词，覆盖需求澄清/架构设计/分步执行/自测全链路
|
||||
4. **实战流程**：从环境设置 → 基础游戏开发 → 丰富细节 → Bug 修复的完整流程
|
||||
5. **提示词工具**：Excel 与 Markdown 互转，支持批量管理
|
||||
|
||||
## Key Entities
|
||||
- [[vibe-coding-cn]]：中文 Vibe Coding 资源库（https://github.com/tukuaiai/vibe-coding-cn）
|
||||
- [[Karpathy]]：提出 Vibe Coding 概念的 AI 大牛（Andrej Karpathy）
|
||||
- [[Cursor]]：主流 AI 编程工具之一（推荐首选）
|
||||
- [[Windsurf]]：另一主流 AI 编程 IDE
|
||||
- [[Trae]]：国产 AI 编程 IDE
|
||||
- [[Claude Opus]]：Anthropic 最强模型，vibe-coding-cn 推荐搭配 Cursor 使用
|
||||
|
||||
## Connections
|
||||
- [[Vibe Coding]] ← 概念起源 ← [[Karpathy]]
|
||||
- [[vibe-coding-cn]] ← 涵盖工具 ← [[Cursor]] + [[Windsurf]] + [[Trae]]
|
||||
- [[vibe-coding-cn]] ← 推荐模型 ← [[Claude Opus]]
|
||||
- [[Vibe Coding]] ← 实践框架 ← [[规划驱动]] + [[上下文固定]] + [[AI结对执行]]
|
||||
|
||||
## Contradictions
|
||||
- "不写代码" vs 工程质量：Karpathy 的"不写代码"是夸张表达；实际上规划驱动和代码审查仍是必要环节
|
||||
- AI 生成代码 vs 可维护性：无规划的 AI 生成容易产生"巨石文件"，vibe-coding-cn 强调规划优先是针对此问题的对策
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: "GitHub 上 5000 人收藏的 Vibe Coding 神级指南"
|
||||
type: source
|
||||
tags: [vibe-coding, ai, github]
|
||||
date: 2025-12-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/GitHub 上 5000 人收藏的 Vibe Coding 神级指南。.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：Vibe Coding 氛围编程的方法论与资源汇总
|
||||
- 问题域：中文开发者如何利用 AI 工具高效完成软件开发
|
||||
- 方法/机制：规划驱动 + 上下文固定 + AI 结对执行，将想法到可维护代码变为可审计流水线
|
||||
- 结论/价值：Vibe Coding 不是放弃代码，而是从"写代码的人"转变为"指挥 AI 写代码的导演"
|
||||
|
||||
## Key Claims
|
||||
- Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行
|
||||
- 开发者从"苦哈哈写每一行代码"转变为"保持对产品逻辑、用户流程、审美和交互的感觉"
|
||||
- AI 编程工具（Cursor、Windsurf、Trae）承担体力活，开发者做导演
|
||||
- 规划是一切：技术选型、实施规划、模块化设计，防止 AI 理解偏差导致项目逻辑混乱
|
||||
- 推荐组合：Cursor + claude-opus-4.5-xhigh
|
||||
|
||||
## Key Quotes
|
||||
> "我几乎不写代码了，我只负责调整氛围（Vibe），代码会自动长出来。" — Karpathy 对 Vibe Coding 的描述
|
||||
> "Vibe Coding 让『从想法到可维护代码』变成一条可审计的流水线，而不是一团无法迭代的巨石文件。" — vibe-coding-cn 项目定义
|
||||
|
||||
## Key Concepts
|
||||
- [[Vibe Coding]]：氛围编程，开发者化身为导演，AI 工具承担体力活
|
||||
- [[AI编程]]：使用 AI 工具辅助软件开发
|
||||
- [[Prompt工程]]：优化提示词提升 AI 输出质量
|
||||
|
||||
## Key Entities
|
||||
- [[Cursor]]：AI 编程 IDE
|
||||
- [[Windsurf]]：AI 编程 IDE
|
||||
- [[Trae]]：AI 编程 IDE
|
||||
- [[vibe coding cn]]：中文 Vibe Coding 指南开源项目（github.com/tukuaiai/vibe-coding-cn）
|
||||
- [[Karpathy]]：AI 研究者，提出 Vibe Coding 概念
|
||||
|
||||
## Connections
|
||||
- [[Vibe Coding]] ← 属于 ← [[AI编程]]
|
||||
- [[Vibe Coding]] ← 工具支撑 ← [[Cursor]]
|
||||
- [[Vibe Coding]] ← 工具支撑 ← [[Windsurf]]
|
||||
- [[Vibe Coding]] ← 资源库 ← [[vibe coding cn]]
|
||||
- [[AI编程]] ← 演进自 ← [[Prompt工程]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Claude-Code调用方法总结]] 潜在冲突：
|
||||
- 冲突点：AI 编程工具的选择与使用模式
|
||||
- 当前观点：推荐 Cursor + claude-opus-4.5-xhigh
|
||||
- 对方观点：强调 Claude Code CLI 作为主要 AI 编程工具
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
title: "GitHub 上 5000 人收藏的 Vibe Coding 神级指南（中文版）"
|
||||
type: source
|
||||
tags: [vibe-coding, AI编程, github, 中文资源]
|
||||
date: 2025-12-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/GitHub 上 5000 人收藏的 Vibe Coding 神级指南。.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：vibe-coding-cn 中文开源项目——面向中文开发者的 Vibe Coding 资源库与工作站
|
||||
- 问题域：中文开发者难以系统性获取 Vibe Coding 方法论和工具链资源
|
||||
- 方法/机制：整合 AI 编程资源、提示词库、学习路径和实操流程，形成可操作的工作站
|
||||
- 结论/价值：Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行；规划就是一切，防止 AI 理解偏差导致项目逻辑混乱
|
||||
|
||||
## Key Claims
|
||||
- Vibe Coding 核心公式：规划驱动 + 上下文固定 + AI 结对执行，让想法到可维护代码成为可审计流水线
|
||||
- Vibe Coding 本质：开发者做导演，AI 做执行，专注于产品逻辑/用户流程/审美/交互把握
|
||||
- Karpathy 原话："我几乎不写代码了，我只负责调整氛围（Vibe），代码会自动长出来"
|
||||
- vibe-coding-cn = 中文开发者 Vibe Coding 资源库，提供方法论+工具链+提示词库+开发经验全链路覆盖
|
||||
- 工具链推荐：Cursor + Claude Opus 4.5-xhigh，直接可用无需筛选
|
||||
- 提示词库覆盖：需求澄清/系统架构设计/分步执行/自测全链路，支持 Excel 与 Markdown 互转
|
||||
|
||||
## Key Quotes
|
||||
> "Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行，让『从想法到可维护代码』变成一条可审计的流水线，而不是一团无法迭代的巨石文件。" — vibe-coding-cn 定义
|
||||
|
||||
> "我几乎不写代码了，我只负责调整氛围（Vibe），代码会自动长出来。" — Andrej Karpathy
|
||||
|
||||
## Key Concepts
|
||||
- [[Vibe Coding]]：氛围编程，开发者做导演而非码农，专注于规划和审美而非逐行代码
|
||||
- [[规划驱动]]：Vibe Coding 第一原则，AI 写代码前必须有清晰技术选型、实施规划和模块化设计
|
||||
- [[上下文固定]]：Vibe Coding 第二原则，通过 .cursorrules 等文件约束 AI 行为边界
|
||||
- [[AI 结对执行]]：Vibe Coding 第三原则，AI 作为 pair programmer 替代传统 IDE
|
||||
- [[vibe-coding-cn]]：中文开发者 Vibe Coding 开源资源库，GitHub 仓库 tukuai/vibe-coding-cn
|
||||
|
||||
## Key Entities
|
||||
- [[Karpathy]]：Vibe Coding 概念提出者，OpenAI/特斯拉前研究科学家
|
||||
- [[Cursor]]：AI 代码编辑器，Vibe Coding 推荐首选 IDE
|
||||
- [[Windsurf]]：AI 编程 IDE，Vibe Coding 工具选项之一
|
||||
- [[Trae]]：AI 编程 IDE，Vibe Coding 工具选项之一
|
||||
- [[vibe-coding-cn]]：中文 Vibe Coding 开源资源库，GitHub tukuai/vibe-coding-cn
|
||||
|
||||
## Connections
|
||||
- [[Vibe Coding]] ← is_extended_by ← [[vibe-coding-cn]]
|
||||
- [[Cursor]] ← is_used_in ← [[Vibe Coding]]
|
||||
- [[项目规则]] ← enables ← [[上下文固定]]
|
||||
- [[vibe-coding-cn]] ← aggregates ← [[Prompt工程]]
|
||||
|
||||
## Contradictions
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
title: "Google 5个Agent Skill设计模式"
|
||||
type: source
|
||||
tags: [agent-skill, design-pattern, google, anthropic]
|
||||
date: 2026-03-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/Agent/Google-5个Agent-Skill设计模式-2026-03-19.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：Google 发布的 5 种经过验证的 Agent Skill 设计模式，帮助开发者构建真正可靠的 agent 系统
|
||||
- 问题域：SKILL.md 格式标准化后，执行效果仍天差地别，问题出在内容设计而非格式
|
||||
- 方法/机制：5 种设计模式（Tool Wrapper/Generator/Reviewer/Inversion/Pipeline）各有适用场景，可组合使用
|
||||
- 结论/价值：把工作流拆分、应用正确结构模式，比把所有复杂指令塞进 system prompt 更可靠
|
||||
|
||||
## Key Claims
|
||||
- Tool Wrapper 模式：监听特定关键词动态加载规范文档，适合分发团队内部编码规范
|
||||
- Generator 模式：通过"填空"流程强制一致的输出格式，适合标准化文档生成
|
||||
- Reviewer 模式：把"检查什么"和"怎么检查"完全分开，换清单即可切换审计类型
|
||||
- Inversion 模式：agent 先问你再做，通过明确不可协商的门控指令逐阶段收集信息
|
||||
- Pipeline 模式：带硬性检查点的严格顺序工作流，确保复杂任务无法跳过步骤
|
||||
- 5 种模式可以组合使用，Pipeline 可包含 Reviewer 步骤，Generator 可依赖 Inversion 收集变量
|
||||
|
||||
## Key Quotes
|
||||
> "别再把所有复杂又脆弱的指令塞进一个system prompt了。把工作流拆分，应用正确的结构模式，才能构建出真正可靠的agent。" — Google 指南总结
|
||||
|
||||
> "Anthropic 把内部几百个 Skills 用了个遍，发现最好的 Skill 不是写得好的提示词，而是一个「工具箱」。" — Anthropic 经验总结
|
||||
|
||||
## Key Concepts
|
||||
- [[Agent Skill 设计模式]]：Google 发布的 5 种 Skill 内容结构化设计模式
|
||||
- [[Tool Wrapper]]：监听关键词动态加载规范文档的 Skill 模式
|
||||
- [[Generator]]：通过填空流程强制一致输出格式的 Skill 模式
|
||||
- [[Reviewer]]：分离检查清单与检查逻辑的 Skill 模式
|
||||
- [[Inversion]]：先收集用户信息再执行的 Skill 模式
|
||||
- [[Pipeline]]：带硬性检查点的顺序工作流 Skill 模式
|
||||
- [[渐进式披露]]：ADK 机制，agent 只在需要时才加载特定模式的 token
|
||||
|
||||
## Key Entities
|
||||
- [[Google]]：发布 5 种 Agent Skill 设计模式的云平台厂商
|
||||
- [[Anthropic]]：Claude 开发商，Skill 实践经验总结方
|
||||
|
||||
## Connections
|
||||
- [[Agent Skill 设计模式]] ← 来源 ← [[Google]]
|
||||
- [[Claude-Skills-研究范式]] ← 关联 ← [[Google-5个Agent-Skill设计模式-2026-03-19]]
|
||||
- [[Tool Wrapper]] ← 适用于 ← [[AI技能封装]]
|
||||
- [[Pipeline]] ← 包含 ← [[Reviewer]]（可组合）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Claude-Skills-研究范式]] 侧重点不同：本文强调"模式结构"，原文强调"经验封装为 SOP"
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
title: "Google 神级生产力工具，所有 GitHub 开源平替都找到了"
|
||||
type: source
|
||||
tags: [notebooklm, open-source, github, ai-productivity, self-hosted]
|
||||
date: 2026-01-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Google 神级生产力工具，所有 GitHub 开源平替都找到了。]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Google NotebookLM 的 6 款 GitHub 开源平替测评，涵盖本地化部署、多模态输入、播客生成等维度
|
||||
- 问题域：NotebookLM 作为闭源云服务存在数据隐私风险，用户需要可私有部署的开源替代品
|
||||
- 方法/机制：对比 Open Notebook（14.6k ⭐）、SurfSense（11.4k ⭐）、Podcastfy、NotebookLlama、PageLM、InsightsLM 的核心能力和部署方式
|
||||
- 结论/价值：开源平替已覆盖 NotebookLM 全部核心功能，Open Notebook 在功能完整性上最接近原版，SurfSense 在研究场景最强，Podcastfy 在播客生成上最专注
|
||||
|
||||
## Key Claims
|
||||
- Open Notebook 支持 16+ AI 提供商（OpenAI/Anthropic/Gemini/Ollama/LM Studio），是功能最完整的 NotebookLM 平替
|
||||
- SurfSense 集成 Notion/YouTube/GitHub 等外部数据源，结合语义搜索+全文搜索+重排序，适合企业知识库场景
|
||||
- Podcastfy 专注播客生成，支持 100+ LLM 和 4 种 TTS 引擎，可生成 Shorts 和 Longform 两种播客格式
|
||||
- InsightsLM 以 Supabase+N8N 为后端，React 为前端，实现完全可控的私有研究工具
|
||||
|
||||
## Key Quotes
|
||||
> "Open Notebook 是一个全功能的本地化解决方案，不依赖云端的情况下进行知识管理和研究" — 原文
|
||||
> "SurfSense 定位为 NotebookLM、Perplexity 和 Glean 的开源替代品" — 原文
|
||||
> "PageLM 提供自动生成康奈尔笔记（SmartNotes）、互动测验、间隔重复闪卡和模拟考试系统" — 原文
|
||||
|
||||
## Key Concepts
|
||||
- [[Open Notebook]]：功能最完整的 NotebookLM 开源平替，14.6k ⭐，支持 16+ AI 提供商和多模态输入
|
||||
- [[SurfSense]]：AI 搜索与研究智能体，11.4k ⭐，整合外部数据源+混合搜索+RBAC，适合团队协作
|
||||
- [[Podcastfy]]：专注播客生成的 Python 包+CLI+Web界面，支持 100+ LLM 和多种 TTS 引擎
|
||||
- [[NotebookLlama]]：LlamaIndex 官方项目，1.7k ⭐，展示文档转播客的完整技术链条
|
||||
- [[PageLM]]：教育平台，SmartNotes 笔记+互动测验+Flashcards+ExamLab，覆盖学习全流程
|
||||
- [[InsightsLM]]：Supabase+N8N+React 架构，完全私有化，支持 Ollama/Qwen3 本地模型
|
||||
|
||||
## Key Entities
|
||||
- [[lfnovo/open-notebook]]：Open Notebook GitHub 维护方
|
||||
- [[MODSetter/SurfSense]]：SurfSense GitHub 维护方
|
||||
- [[souzatharsis/podcastfy]]：Podcastfy GitHub 维护方
|
||||
- [[run-llama/notebookllama]]：NotebookLlama GitHub 维护方
|
||||
- [[CaviraOSS/PageLM]]：PageLM GitHub 维护方
|
||||
- [[theaiautomators/insights-lm-public]]：InsightsLM GitHub 维护方
|
||||
- [[NotebookLM]]：Google 推出的 AI 笔记助手，Source Grounding 机制确保回答精度
|
||||
|
||||
## Connections
|
||||
- [[Open Notebook]] ← 功能相似 ← [[NotebookLM]]
|
||||
- [[SurfSense]] ← 功能扩展 ← [[Open Notebook]]（增加外部数据源整合）
|
||||
- [[Podcastfy]] ← 专注化 ← [[NotebookLlama]]（专注播客，去掉通用笔记）
|
||||
- [[InsightsLM]] ← 技术栈 ← [[n8n]]（N8N 作为后端工作流引擎）
|
||||
- [[PageLM]] ← 场景扩展 ← [[NotebookLM]]（增加测验和考试功能）
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
title: "Health & Symptom Tracker"
|
||||
type: source
|
||||
tags: [health, automation, telegram, cron]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/health-symptom-tracker.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：基于 Telegram 的个人健康与症状追踪自动化工作流
|
||||
- 问题域：食物敏感性识别需要长期持续记录，用户难以坚持手动日志
|
||||
- 方法/机制：Telegram 话题 + OpenClaw Cron 提醒 + Markdown 日志 + 周分析
|
||||
- 结论/价值：用最低摩擦的对话式输入替代 App，OpenClaw 自动解析+模式分析
|
||||
|
||||
## Key Claims
|
||||
- Telegram 话题消息可作为结构化健康日志输入源
|
||||
- 每日 3 次定时提醒（早/中/晚）可培养用户记录习惯
|
||||
- 周度模式分析能识别食物与症状的关联性
|
||||
|
||||
## Key Concepts
|
||||
- [[健康追踪]]：通过对话式界面持续记录食物与症状，替代专用 App
|
||||
- [[模式识别]]：基于时间序列分析识别触发因素
|
||||
- [[定时晨报]]：OpenClaw Cron 驱动的固定时间主动提醒机制
|
||||
|
||||
## Key Entities
|
||||
- [[Telegram]]：消息接收通道，支持话题（Topic）隔离不同类型对话
|
||||
|
||||
## Connections
|
||||
- [[Health Symptom Tracker]] ← extends ← [[定时晨报]]
|
||||
- [[Health Symptom Tracker]] ← uses ← [[Telegram]]
|
||||
- [[健康追踪]] ← relates_to ← [[模式识别]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: "NodeWarden - 把 Bitwarden 搬上 Cloudflare Workers，彻底告别服务器"
|
||||
type: source
|
||||
tags: [bitwarden, cloudflare-workers, password-manager, self-hosted, serverless]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/NodeWarden - 把 Bitwarden 搬上 Cloudflare Workers，彻底告别服务器.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：NodeWarden 将 Bitwarden 服务器端部署到 Cloudflare Workers，实现零 VPS 的自托管密码管理
|
||||
- 问题域：Bitwarden 官方自托管需要服务器，而许多人希望完全无服务器方案
|
||||
- 方法/机制：Cloudflare Workers（DDoS 防护/全球 CDN/免费额度）+ D1（SQLite 分布式数据库）+ R2（对象存储附件）
|
||||
- 结论/价值：在不付费服务器的情况下，获得支持 TOTP/自动填充/完整同步的开源密码管理方案
|
||||
|
||||
## Key Claims
|
||||
- NodeWarden 在 Cloudflare Workers 上运行，完全零服务器费用（Free Tier 足够个人使用）
|
||||
- 支持单用户保管库完整功能：登录/笔记/卡片/身份/文件夹/附件/R2 存储/网站图标代理
|
||||
- 支持 passkey 和 TOTP（官方需要会员，NodeWarden 免费）
|
||||
- 不支持多用户、组织/集合/成员权限、SSO/SCIM/Send/紧急访问（单用户定位，无需这些功能）
|
||||
|
||||
## Key Quotes
|
||||
> "部署 NodeWarden 之后的效果，就是在无服务器的情况下，也能在手机、电脑上使用 Bitwarden 客户端来保存密码了，支持自动登陆、二次验证之类的功能" — AppInn
|
||||
|
||||
## Key Concepts
|
||||
- [[Cloudflare Workers]]：无服务器边缘计算平台，支持在 200+ 地区运行 JavaScript/TypeScript 代码
|
||||
- [[Cloudflare D1]]：基于 SQLite 的全球分布式数据库，Workers 原生集成
|
||||
- [[Cloudflare R2]]：S3 兼容的对象存储，用于存储密码库附件
|
||||
- [[自托管密码管理]]：自己控制数据，不依赖第三方云服务的密码管理方式
|
||||
- [[无服务器密码学]]：TOTP（Time-based One-Time Password）算法实现二次验证
|
||||
|
||||
## Key Entities
|
||||
- [[Bitwarden]]：开源密码管理系统，客户端和服务器端均开源，支持完整自托管
|
||||
- [[Cloudflare]]：全球网络服务商，提供 Workers/D1/R2 等开发者工具
|
||||
- [[NodeWarden]]：将 Bitwarden 服务器端运行在 Cloudflare Workers 的开源项目（shuaiplus/GitHub）
|
||||
- [[AppInn]]：中文科技博客，内容翻译和本地化介绍
|
||||
|
||||
## Connections
|
||||
- [[Bitwarden]] ← 基础服务 ← [[Cloudflare Workers]] ← 承载层 ← [[NodeWarden]]
|
||||
- [[密码管理器]] ← 上位概念 ← [[自托管密码管理]]
|
||||
|
||||
## Related Links
|
||||
- [NodeWarden GitHub](https://github.com/shuaiplus/NodeWarden)
|
||||
- [AppInn 原文](https://www.appinn.com/nodewarden/)
|
||||
- NodeWarden 实例：https://nodewarden.ishenwei.online/
|
||||
64
wiki/sources/How-Agentic-AI-can-help-for-Cloud-DevOps.md
Normal file
64
wiki/sources/How-Agentic-AI-can-help-for-Cloud-DevOps.md
Normal file
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: "How Agentic AI can help for Cloud DevOps"
|
||||
type: source
|
||||
tags: [Cloud DevOps, Agentic AI, AIOps]
|
||||
date: 2026-04-16
|
||||
sources: ["How Agentic AI can help for Cloud DevOps.md"]
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/How Agentic AI can help for Cloud DevOps.md]]
|
||||
|
||||
## Summary
|
||||
Agentic AI（具备自主决策和任务执行能力的 AI 系统）通过自动化复杂工作流、提升效率、确保云环境可靠性，显著增强 Cloud DevOps 能力。涵盖七大领域：自主事件检测与响应、自动化云部署与配置、智能成本优化、AI 驱动安全与合规、智能日志分析与可观测性、SaaS 多租户管理增强、AI 辅助决策。
|
||||
|
||||
## Key Claims
|
||||
- Agentic AI 可将 MTTR（平均修复时间）缩短并确保 SLA 合规
|
||||
- AI 作为发布经理可自动化特性标志测试、回滚决策及部署策略（Blue/Green、Canary）
|
||||
- AI 驱动的权限管理可识别过度宽松的 IAM 角色并自动修复
|
||||
- AI 可通过分析历史 outage 模式进行预测性维护
|
||||
|
||||
## Key Quotes
|
||||
> "Agentic AI transforms Cloud DevOps by automating incident response, cost management, security, observability, and multi-cloud governance." — 结论
|
||||
|
||||
## Key Concepts
|
||||
- [[Agentic AI]]：具备自主决策和任务执行能力的 AI 系统
|
||||
- [[Self-Healing Systems]]：主动检测异常并自动修复的系统
|
||||
- [[AI-driven RCA]]：利用 AI 分析日志进行根因分析
|
||||
- [[Predictive Maintenance]]：从历史 outage 学习模式并主动推荐补丁或扩缩容
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码管理基础设施（Terraform、CloudFormation、Pulumi）
|
||||
- [[IaC Management]]：AI 代理审查 IaC 脚本并在执行前提出改进建议
|
||||
- [[Dynamic Configuration Management]]：基于实时性能和成本效率动态调整应用配置
|
||||
- [[Cost Optimization]]：AI 分析使用趋势，动态扩缩资源防止过度配置
|
||||
- [[Spot Instance Optimization]]：在工作负载之间智能切换 Spot/Preemptible 实例
|
||||
- [[Automated Security Audits]]：扫描 IAM 策略、网络规则、容器漏洞
|
||||
- [[Dynamic Threat Mitigation]]：检测安全风险并自动修复
|
||||
- [[Compliance Enforcement]]：实时监控 SOC 2、FedRAMP、PCI DSS 合规性
|
||||
- [[AI-powered Log Analysis]]：分析 CloudWatch、ELK、OpenTelemetry、Datadog 日志
|
||||
- [[AI ChatOps]]：通过 Slack、Teams 或 CLI 进行 AI 驱动的故障排除
|
||||
- [[Multi-Tenant Management]]：SaaS 多租户自动配置、扩缩容和租户隔离
|
||||
- [[Tenant Provisioning]]：AI 代理动态创建和配置新租户
|
||||
- [[AI-powered Runbooks]]：AI 推荐最佳运维手册处理事件
|
||||
- [[What-If Simulations]]：预测云迁移、实例类型变更或架构变更的影响
|
||||
- [[AI-based Anomaly Detection]]：标记性能、安全或成本趋势的偏差
|
||||
|
||||
## Key Entities
|
||||
- [[Kubernetes]]（EKS、GKE、AKS）：容器编排平台
|
||||
- [[AWS]]：Amazon 云服务平台（EKS、RDS、S3、Lambda、CloudWatch、IAM、Spot、Inspector）
|
||||
- [[GCP]]：Google Cloud Platform（GKE、GCS、Cloud SQL、Security Command Center、Preemptible）
|
||||
- [[Azure]]：Microsoft 云平台（AKS、Cosmos DB、Blob Storage、Azure Monitor、Azure Defender、Savings Plan）
|
||||
- [[Terraform]]、[[CloudFormation]]、[[Pulumi]]：IaC 工具
|
||||
- [[CloudWatch]]、[[Stackdriver]]、[[ELK]]、[[OpenTelemetry]]、[[Datadog]]：监控与日志工具
|
||||
- [[Slack]]、[[Teams]]：协作平台
|
||||
- [[SOC 2]]、[[FedRAMP]]、[[PCI DSS]]：安全合规框架
|
||||
|
||||
## Connections
|
||||
- [[DevOps]] ← extends ← [[Agentic AI]]：Agentic AI 扩展了 DevOps 的自动化能力
|
||||
- [[Cloud Security]] ← supports ← [[Agentic AI]]：Agentic AI 增强了云安全自动化
|
||||
- [[Auto-scaling]] ← extends ← [[Agentic AI]]：Agentic AI 提供更智能的动态扩缩
|
||||
- [[CI/CD 流水线]] ← extends ← [[Agentic AI]]：Agentic AI 作为发布经理自动化部署策略
|
||||
- [[Infrastructure as Code (IaC)]] ← enhanced_by ← [[Agentic AI]]：AI 审查和改进 IaC 脚本
|
||||
- [[DevSecOps]] ← extends ← [[Agentic AI]]：Agentic AI 实现自动化安全审计和合规执行
|
||||
|
||||
## Contradictions
|
||||
- （暂无已知冲突）
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
title: "How Agentic AI can help for Cloud DevOps"
|
||||
type: source
|
||||
tags: [agentic-ai, devops, cloud]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/Cloud & DevOps/How Agentic AI can help for Cloud DevOps.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：Agentic AI 在云 DevOps 中的七大应用场景
|
||||
- 问题域：如何通过 AI 自动化提升云运维效率、降低成本、增强安全合规
|
||||
- 方法/机制：自主检测与修复、IaC 智能管理、AI 驱动安全审计、多租户自动化运维
|
||||
- 结论/价值：Agentic AI 将传统响应式 DevOps 转变为预测性、自动化运维
|
||||
|
||||
## Key Claims
|
||||
- Agentic AI 可实现自愈系统，自动检测 K8s、数据库、存储异常并执行修复
|
||||
- AI 驱动的根因分析（RCA）可关联云监控日志跨层定位问题
|
||||
- Agentic AI 作为发布经理，可自动化蓝绿部署、金丝雀发布和回滚决策
|
||||
- 智能 IaC 管理：AI 代理审查 Terraform、CloudFormation、Pulumi 脚本
|
||||
- 成本优化：AI 持续分析资源使用趋势，动态扩展，Spot/Reserved 实例优化
|
||||
- 安全合规：自动扫描 IAM 策略、网络规则、容器漏洞，实时修复违规
|
||||
- 多租户管理：自动创建、配置、归档租户资源
|
||||
|
||||
## Key Quotes
|
||||
> "Agentic AI transforms Cloud DevOps by automating incident response, cost management, security, observability, and multi-cloud governance." — 核心价值总结
|
||||
|
||||
## Key Concepts
|
||||
- [[Agentic AI]]：能感知环境、决策、预判并自主行动的 AI 系统
|
||||
- [[Self-Healing Systems]]：自愈系统，Agentic AI 自动检测并修复异常
|
||||
- [[IaC]]：Infrastructure as Code，基础设施即代码
|
||||
- [[RCA]]：Root Cause Analysis，根因分析
|
||||
- [[Multi-Cloud Governance]]：多云治理
|
||||
|
||||
## Key Entities
|
||||
- [[Kubernetes]]：K8s 集群管理（EKS、GKE、AKS）
|
||||
- [[AWS]]：Amazon Web Services
|
||||
- [[GCP]]：Google Cloud Platform
|
||||
- [[Azure]]：Microsoft Azure
|
||||
- [[Terraform]]：IaC 工具
|
||||
- [[CloudWatch]]：AWS 监控
|
||||
- [[Datadog]]：监控可观测性平台
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← 应用领域 ← [[DevOps]]
|
||||
- [[Agentic AI]] ← 增强场景 ← [[Self-Healing Systems]]
|
||||
- [[IaC]] ← 智能审查 ← [[Agentic AI]]
|
||||
- [[DevSecOps]] ← 安全增强 ← [[Agentic AI]]
|
||||
- [[Serverless DevOps]] ← 成本优化 ← [[Agentic AI]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[DevOps核心理念]] 潜在冲突：
|
||||
- 冲突点：DevOps 自动化边界
|
||||
- 当前观点：Agentic AI 可完全自主执行修复和决策
|
||||
- 对方观点：强调人机协作，AI 辅助而非完全自主
|
||||
@@ -1,62 +1,54 @@
|
||||
---
|
||||
title: "How Can a Multi Cloud Strategy Transform Your Business ROI?"
|
||||
type: source
|
||||
tags: [cloud, strategy, multi-cloud, ROI]
|
||||
tags: [Cloud, Multi-Cloud, ROI, DevOps]
|
||||
date: 2024-12-24
|
||||
source_file: raw/Cloud & DevOps/How Can a Multi Cloud Strategy Transform Your Business ROI.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/How Can a Multi Cloud Strategy Transform Your Business ROI.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：多云策略（Multi-Cloud）如何提升业务 ROI
|
||||
- 问题域：单一云厂商依赖导致成本高、弹性差、风险集中
|
||||
- 方法/机制：跨 AWS/Azure/GCP 分配工作负载，利用各厂商优势定价和服务能力
|
||||
- 结论/价值：多云策略可降低 30% 运营成本，提升韧性、弹性、安全性和创新能力
|
||||
本文探讨多云策略（Multi-Cloud Strategy）的定义、优势及实施方法。多云策略指同时使用多个云服务商（如AWS、Azure、Google Cloud）的服务，避免单一供应商锁定，通过利用各提供商的优势服务来提升效率、安全性和性能。研究数据显示，78%的企业已采用多云策略，86%的公司计划到2024年底采用多云方案，优化后可实现30%的运营成本降低。
|
||||
|
||||
## Key Claims
|
||||
- 78% 采用多云策略的企业将工作负载部署在超过 3 个公有云，以提升敏捷性和成本效益（Virtana）
|
||||
- 86% 企业计划在 2024 年底前采用多云策略（New Horizons）
|
||||
- 多云策略可为企业降低 30% 运营成本（Forrester）
|
||||
- 多云不等于备份策略：真正的价值在于跨厂商性能优化、成本优化和弹性扩展
|
||||
- 多云不等于复杂性增加：Kubernetes、Terraform 等工具和治理框架可简化管理
|
||||
- 多云策略能有效避免供应商锁定（Vendor Lock-In），让企业根据具体需求选择最佳云服务
|
||||
- 多云环境提供更高的弹性和可靠性，单一提供商故障不会导致整体服务中断
|
||||
- 多云部署可提升安全 posture，通过在不同环境部署不同安全机制降低网络攻击风险
|
||||
- 通过竞争性定价和资源优化，企业可实现显著的成本降低（报告示例如30%运营成本减少）
|
||||
- 多云策略满足不同地区和行业的监管合规要求，支持数据主权（Data Sovereignty）
|
||||
|
||||
## Key Quotes
|
||||
> "You can leverage computing from AWS, AI tools from Google, and store your data in Microsoft Azure without fearing vendor lock-in yet enjoy high availability." — 多云核心价值描述
|
||||
> "A multi-cloud strategy is a distinctive approach in which we have instances of services on multiple clouds, i.e., Azure, GCP, and Amazon, instead of one cloud vendor." — Bacancy Technology
|
||||
> "78% of businesses leveraging a multi-cloud strategy have workloads deployed in more than three public clouds for better agility and cost savings" — Virtana Research
|
||||
|
||||
## Key Concepts
|
||||
- [[多云策略]]：跨多个公有云（AWS/Azure/GCP）分配工作负载，利用各厂商差异化优势
|
||||
- [[供应商锁定规避]]：通过多厂商策略避免单一云厂商绑定，保持谈判议价能力
|
||||
- [[多云治理]]：跨云资源管理、安全策略、成本控制和合规性的统一框架
|
||||
- [[多云成本优化]]：利用不同厂商的差异化定价模型降低整体云支出
|
||||
- [[云弹性扩展]]：跨多个云动态调配资源，应对突发流量峰值
|
||||
- [[数据主权合规]]：选择符合区域法规的云厂商存储和处理数据
|
||||
- [[Multi-Cloud]]：使用多个云服务商服务的部署策略
|
||||
- [[Vendor Lock-In]]：供应商锁定，指企业依赖单一供应商难以迁移的状态
|
||||
- [[Cloud ROI]]：（隐含概念）云投资回报率
|
||||
- [[Data Sovereignty]]：数据主权，指数据受当地法律法规约束的原则
|
||||
- [[Cloud Security]]：（隐含）多云环境下的安全管理实践
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：多云策略中的基础设施和通用计算主力厂商
|
||||
- [[Azure]]：多云策略中的企业级 AI 和数据服务厂商
|
||||
- [[GCP]]：多云策略中的机器学习和分析工具厂商
|
||||
- [[Kubernetes]]：多云环境容器编排和 workload 统一管理工具
|
||||
- [[Terraform]]：IaC 工具，跨云基础设施声明式管理
|
||||
- [[CloudHealth]]：多云成本和性能监控工具（原文提及）
|
||||
- [[Datadog]]：跨云统一可观测性监控平台
|
||||
- [[AWS]]：亚马逊云服务，主要基础设施提供商
|
||||
- [[Azure]]：微软云平台，AI工具优势
|
||||
- [[Google Cloud]]：Google云平台，机器学习和分析服务优势
|
||||
- Bacancy Technology：本文来源公司
|
||||
|
||||
## Connections
|
||||
- [[Cloud Operating Model]] ← is_applied_to ← [[多云策略]]
|
||||
- [[DevOps成熟度模型]] ← enables ← [[多云治理]]
|
||||
- [[多云成本优化]] ← depends_on ← [[FinOps]]
|
||||
- [[Kubernetes]] ← enables ← [[多云治理]]
|
||||
- [[Terraform]] ← enables ← [[多云治理]]
|
||||
|
||||
## Industry Use Cases
|
||||
- **电商**：黑五/网一高峰期跨云弹性扩展，保障高可用和低延迟
|
||||
- **医疗**：符合 HIPAA 区域数据主权要求，分布式存储降低单云依赖成本
|
||||
- **金融**：利用不同厂商最优安全特性，满足严格合规要求同时最大化 ROI
|
||||
|
||||
## Implementation Steps
|
||||
1. 评估需求：明确目标（韧性/成本优化/扩展）、预算分析、现有工作负载梳理
|
||||
2. 选择厂商：AWS 做基础设施、Google Cloud 做分析、Azure 做 AI，根据场景匹配
|
||||
3. 集成管理：采用 Kubernetes/Terraform 统一编排，确保数据互操作性
|
||||
4. 监控优化：CloudHealth/Datadog 持续跟踪性能和成本，动态调整资源分配
|
||||
- [[Multi-Cloud]] ← depends_on ← [[AWS]], [[Azure]], [[Google Cloud]]
|
||||
- [[Multi-Cloud]] ← supports ← [[Cloud-Adoption]]
|
||||
- [[Multi-Cloud]] ← enables ← [[DevOps]] （通过提升弹性和效率）
|
||||
- [[Multi-Cloud]] ← relates_to ← [[Cloud Security]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无发现矛盾
|
||||
|
||||
## Real-World Use Cases
|
||||
- **电商**：高峰期（黑色星期五、网络星期一）弹性扩展
|
||||
- **医疗**：HIPAA合规，区域数据主权要求
|
||||
- **金融**：强化安全、合规、最大化投资回报
|
||||
|
||||
## Implementation Steps
|
||||
1. 评估需求（目标、预算、资源）
|
||||
2. 选择合适提供商（对齐服务与需求）
|
||||
3. 集成与管理（采用Kubernetes、Terraform等工具）
|
||||
4. 监控与优化（持续跟踪性能和成本）
|
||||
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "How to Get the RSS Feed For Any YouTube Channel"
|
||||
type: source
|
||||
tags: [youtube, rss, 工具教程]
|
||||
sources: ["https://chuck.is/yt-rss/"]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/How to Get the RSS Feed For Any YouTube Channel.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：通过 View Page Source 获取 YouTube 频道 RSS Feed 的方法
|
||||
- 问题域：YouTube 移除了 RSS 订阅按钮，用户无法直接获取频道 RSS 链接
|
||||
- 方法/机制：访问频道页 → 右键查看源代码 → 搜索 "channel_id=" → 提取 RSS Feed URL
|
||||
- 结论/价值：无需第三方服务即可获取 YouTube 频道 RSS Feed，用于 RSS 阅读器订阅
|
||||
|
||||
## Key Claims
|
||||
- YouTube 移除了 RSS 订阅按钮以防止用户不访问网站获取内容
|
||||
- 通过 View Page Source 搜索 "channel_id=" 可获取 RSS Feed URL
|
||||
- RSS Feed 格式：https://www.youtube.com/feeds/videos.xml?channel_id={ID}
|
||||
|
||||
## Key Concepts
|
||||
- [[RSS Feed]]：标准化的内容订阅格式
|
||||
- [[YouTube Channel ID]]：YouTube 频道的唯一标识符
|
||||
|
||||
## Connections
|
||||
- [[YouTube]] ← 平台 ← [[RSS Feed]]
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: "How to get YouTube Channel ID"
|
||||
type: source
|
||||
tags: [youtube, rss, utility]
|
||||
date: 2025-03-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Others/How to get Youtube Channel ID.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：获取 YouTube 频道 ID 的方法
|
||||
- 问题域：n8n 工作流接入 YouTube 数据时需要 channel_id 参数
|
||||
- 方法/机制：通过 view-source 页面查询 `?channel_id` 字符串
|
||||
- 结论/价值：channel_id 可用于构建 YouTube RSS Feed URL，进而接入 n8n 自动化
|
||||
|
||||
## Key Claims
|
||||
- YouTube 频道页面通过 view-source 可直接查询 channel_id
|
||||
- 查询到的 channel_id 格式为 `UCxxxxxxxxxxxxxxxxx`
|
||||
- channel_id 可拼接为 RSS Feed URL：`https://www.youtube.com/feeds/videos.xml?channel_id=UCxxx`
|
||||
|
||||
## Key Quotes
|
||||
> `view-source:https://www.youtube.com/@Numberblocks` — 通过此方式绕过 UI 直接访问源码
|
||||
> `"?channel_id"` — 在源码中搜索此字符串即可定位 channel_id
|
||||
|
||||
## Key Concepts
|
||||
- [[YouTube Channel ID]]：YouTube 频道唯一标识符，格式为 UC 前缀的 24 字符字符串
|
||||
- [[YouTube RSS Feed]]：通过 channel_id 生成的 XML 订阅源，可被 n8n 等工具消费
|
||||
|
||||
## Key Entities
|
||||
- [[YouTube]]：视频平台，RSS Feed 功能支持频道级订阅
|
||||
- [[n8n]]：自动化工作流工具，支持 YouTube RSS Trigger
|
||||
|
||||
## Connections
|
||||
- [[YouTube RSS Feed]] ← used_in ← [[n8n YouTube Workflow]]
|
||||
- [[YouTube Channel ID]] ← extracted_from ← [[YouTube Channel Page Source]]
|
||||
|
||||
## Contradictions
|
||||
- 无冲突
|
||||
|
||||
## Metadata
|
||||
- 作者：shenwei
|
||||
- 创建时间：2025-03-16
|
||||
- 原始标签：[]
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
title: "If You Have Multiple Interests, Do Not Waste the Next 2-3 Years"
|
||||
type: source
|
||||
tags: [ai, entrepreneurship, generalist, content, self-education]
|
||||
date: 2025-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/If you have multiple interests, do not waste the next 2-3 years 如果你有多项兴趣爱好，不要浪费接下来的两三年时间。.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：在 AI 时代，拥有多重兴趣的通才（Generalist）比专才（Specialist）更具优势；多兴趣交叉创造独特视角是最终的护城河
|
||||
- 问题域：工业时代专业化分工思维使人沦为螺丝钉，社会对"专注单一技能"的迷信阻碍个人发展
|
||||
- 方法/机制：三要素框架（自学 Self-education + 自利 Self-interest + 自立 Self-sufficiency）→ 通才自然涌现；内容创作作为收入载体；系统经济时代系统 > 产品
|
||||
- 结论/价值：AI 时代是第二次文艺复兴，多兴趣通才拥有前所未有机遇；品牌即环境，内容即新颖视角，系统即产品
|
||||
|
||||
## Key Claims
|
||||
- 专业化导致愚蠢和依赖，通才（Generalist）才能实现主权（Self-sufficiency）和适应力
|
||||
- 第二次文艺复兴已到来：印刷术降低知识成本 → 个人可追求多领域精通；AI 降低执行成本 → 个人可将兴趣转化为产品
|
||||
- 最终护城河是独特视角（Perspective），这来自独一无二的人生经历，无法被复制
|
||||
- 三要素：Self-education（引擎）+ Self-interest（指南针）+ Self-sufficiency（基石）
|
||||
- 系统经济时代，人们要的是你的解决方案而非通用解决方案；2 Hour Writer 系统即产品
|
||||
|
||||
## Key Quotes
|
||||
> "The man whose whole life is spent in performing a few simple operations... generally becomes as stupid and ignorant as it is possible for a human creature to become." — Adam Smith
|
||||
|
||||
> "Your edge lies more in intersection than it does in expertise." — Dan Koe
|
||||
|
||||
> "Your brand is your story." — Dan Koe
|
||||
|
||||
> "Content is novel perspectives." — Dan Koe
|
||||
|
||||
> "Systems are the new product." — Dan Koe
|
||||
|
||||
## Key Concepts
|
||||
- [[超级通才]]：拥有多领域交叉能力的个体，AI 时代比专才更具主权和适应力，对应 [[超级个体]] 但更强调知识广度
|
||||
- [[自教育]]：自主定向学习以获得与传统教育不同的结果，是通才养成的引擎
|
||||
- [[自利]]：追随自身利益而非被组织利益裹挟，是通才的指南针
|
||||
- [[自立自强]]：拒绝外包判断力、学习力和自主性，是通才的基石
|
||||
- [[创意博物馆]]：Idea Museum，创作素材库，通过 ruthless curation 积累高密度创意
|
||||
- [[系统经济]]：Systems Economy，解决方案的价值在于系统本身而非产品功能，2HW 系统即产品
|
||||
- [[内容创意密度]]：Idea Density，内容质量的衡量标准 = Performance（受众关注）× Excitement（个人热情）
|
||||
|
||||
## Key Entities
|
||||
- [[Dan Koe]]（TheDankoe）：多兴趣创业者，内容创作者，2 Hour Writer 系统开发者，Eden 软件创始人
|
||||
- [[Adam Smith]]：《国富论》作者，专业化分工理论的提出者，"螺丝钉"批评的引用来源
|
||||
- [[Leonardo da Vinci]]：文艺复兴通才典范，绘画/雕塑/工程/解剖/战争机器/人体绘图跨界
|
||||
- [[Jordan Peterson]]：《12 rules for life》作者，作为通才不追随内容潮流而是用思想质量建立影响力
|
||||
|
||||
## Connections
|
||||
- [[超级个体]] ← extends ← [[超级通才]]，超级通才是超级个体在知识广度上的具体表达
|
||||
- [[品味]] ← relates_to ← [[独特视角]]，两者均强调 AI 无法复制的判断力护城河
|
||||
- [[死亡过滤器]] ← relates_to ← [[自利]]，两者均帮助筛选真正值得投入的方向
|
||||
- [[内容矩阵]] ← extends ← [[创意博物馆]]，创意博物馆是内容矩阵的输入端
|
||||
- [[反向金字塔]] ← relates_to ← [[系统经济]]，反向金字塔分发是系统执行的体现
|
||||
|
||||
## Contradictions
|
||||
- 与 [[一人公司]] 框架：本文强调"不要成为 YouTuber/个人品牌/网红，要做自己"；一人公司框架强调需要关注（Attention）才能变现。冲突点：追求纯粹 vs 追求分发。当前观点：两者本质一致——通过真实自我吸引精准受众，只是叙事风格不同。
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
title: "Inbox De-clutter"
|
||||
type: source
|
||||
tags: [email, gmail, automation, newsletter, cron]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/inbox-declutter.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：使用 OpenClaw AI Agent 自动整理 Gmail 新闻简报收件箱
|
||||
- 问题域：新闻简报堆积导致重要邮件被淹没，人工筛选耗时
|
||||
- 方法/机制：Gmail OAuth 读取 + LLM 摘要生成 + 偏好记忆 + Cron 定时执行
|
||||
- 结论/价值：将 0 价值的邮箱浏览转化为 5 分钟高效摘要，建立在个人偏好基础上持续优化的闭环
|
||||
|
||||
## Key Claims
|
||||
- 新闻简报聚合阅读比逐封浏览信息密度更高、效率更高
|
||||
- AI 摘要 + 反馈闭环可建立个性化内容筛选模型
|
||||
- 专用邮箱隔离策略可简化管理并提升摘要质量
|
||||
|
||||
## Key Concepts
|
||||
- [[邮箱分类]]：Gmail 自动标签标注、归档噪音、待处理项识别
|
||||
- [[多平台热点聚合]]：结构化趋势研究方法论的变体（邮件领域）
|
||||
- [[偏好记忆]]：基于用户反馈持续优化下一次输出质量
|
||||
|
||||
## Key Entities
|
||||
- [[Gmail]]：Google 邮件服务平台，支持 OAuth API 访问
|
||||
|
||||
## Connections
|
||||
- [[Inbox De-clutter]] ← extends ← [[定时晨报]]
|
||||
- [[Inbox De-clutter]] ← uses ← [[Gmail]]
|
||||
- [[邮箱分类]] ← relates_to ← [[偏好记忆]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
title: "Install Apache Superset in Docker"
|
||||
type: source
|
||||
tags: [apache-superset, bi, docker, 数据可视化]
|
||||
date: 2025-12-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Install Apache Superset in Docker.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：通过 Docker 在本地快速部署 Apache Superset（开源 BI 可视化平台）
|
||||
- 问题域：如何在 Synology NAS 或其他 Docker 主机上一键部署 Superset 并创建管理员账户
|
||||
- 方法/机制：Docker Hub 拉取 GHA 镜像 → docker run 暴露 8777 端口 → fab create-admin 创建管理员 → db upgrade + load_examples + init 初始化
|
||||
- 结论/价值：Superset 提供企业级 BI 可视化能力，支持连接 MySQL/MariaDB 等数据源
|
||||
|
||||
## Key Claims
|
||||
- Apache Superset GHA 版本镜像：apache/superset:GHA-19524015706
|
||||
- 访问地址：http://localhost:8777，用户名密码均为 admin
|
||||
- 初始化流程：fab create-admin → db upgrade → load_examples → init
|
||||
- 支持 MySQL/MariaDB 数据源连接
|
||||
|
||||
## Key Concepts
|
||||
- [[Apache Superset]]：开源 BI 和数据可视化平台，支持 SQL 查询、图表仪表板
|
||||
- [[Docker]]：Superset 部署方式，使用 Docker Hub 官方镜像
|
||||
- [[Superset Dashboard]]：Superset 核心能力，TikTok Shop 选品分析等业务场景应用
|
||||
|
||||
## Key Entities
|
||||
- [[Apache Superset]]：BI 平台本身，已有 entity 页面
|
||||
- [[Docker]]：容器化部署平台
|
||||
|
||||
## Connections
|
||||
- [[Apache Superset]] ← 部署方式 ← [[Docker]]
|
||||
- [[Superset Dashboard]] ← 数据源 ← [[MySQL MariaDB 数据库详细信息]]（已有配置信息）
|
||||
- [[TikTok Shop - Apache Superset Dashboard设计思路]] ← 应用场景 ← [[Apache Superset]]
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
title: "LLMs、RAG、AI Agent 三个到底什么区别？"
|
||||
type: source
|
||||
tags: [llm, rag, ai-agent, 基础概念]
|
||||
date: 2025-11-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/LLMs、RAG、AI Agent 三个到底什么区别？.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：LLM、RAG、AI Agent 三者的本质区别与层级关系
|
||||
- 问题域：大量 AI 应用开发者混淆三者用途，存在"竞争关系"的误解
|
||||
- 方法/机制：LLM = 思考大脑（推理）；RAG = 记忆系统（信息获取）；AI Agent = 行动循环（执行）
|
||||
- 结论/价值：三者并非竞争关系，而是在不同层面解决不同问题；生产级 AI 系统需三者协同：LLM 推理 + RAG 准确性 + Agent 自主性
|
||||
|
||||
## Key Claims
|
||||
- LLM 是"天才大脑"：知识截至训练时间点，有幻觉问题，对实时信息无感知
|
||||
- RAG 是"随身图书馆助理"：解决 LLM 知识过时和幻觉问题，提供事实依据和来源引用
|
||||
- AI Agent 是"行动系统"：由感知→规划→执行→反思的循环构成，赋予 LLM 行动能力
|
||||
- 三者协同模式：LLM 负责思考，RAG 负责信息获取，Agent 负责编排执行
|
||||
|
||||
## Key Concepts
|
||||
- [[LLM]]：大语言模型，AI 应用的"天才大脑"，擅长推理但缺乏实时知识
|
||||
- [[RAG]]：检索增强生成，为 LLM 提供外部知识库访问能力，消除幻觉
|
||||
- [[AI Agent]]：智能体，围绕 LLM 构建的循环控制系统，赋予感知-规划-执行-反思能力
|
||||
- [[AI Agent 循环]]：感知（Scanner）→ 思考（Reasoner）→ 行动（Actor）→ 观察（Observer）
|
||||
|
||||
## Key Entities
|
||||
|
||||
## Connections
|
||||
- [[LLM]] ← 基础 ← [[AI Agent]]
|
||||
- [[RAG]] ← 信息层 ← [[AI Agent]]
|
||||
- [[LLM]] + [[RAG]] + [[AI Agent]] ← 三位一体 ← [[生产级AI系统]]
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
title: "LLMs、RAG、AI Agent 三个到底什么区别？"
|
||||
type: source
|
||||
tags: [llm, rag, ai-agent, ai-fundamentals]
|
||||
date: 2025-11-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/LLMs、RAG、AI Agent 三个到底什么区别？.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：LLMs、RAG、AI Agent 三个核心AI概念的层次区别与协同关系
|
||||
- 问题域：澄清AI应用领域对这三个术语的混淆——它们不是竞争技术，而是不同层面的能力展示
|
||||
- 方法/机制：LLM（天才大脑/思考）→ RAG（随身图书馆助理/信息）→ AI Agent（行动者/执行）的三层架构
|
||||
- 结论/价值：真正生产系统叠加三者——LLM推理、RAG确保准确性、Agent框架实现自主性
|
||||
|
||||
## Key Claims
|
||||
- LLM 是"天才大脑"，学习了过去所有知识，擅长思考但对当前情况一无所知
|
||||
- RAG 是"记忆系统"，将静态LLM链接到外部实时知识库，解决知识时效性问题
|
||||
- AI Agent 是"行动者"，围绕LLM构建循环控制系统（感知→规划→执行→反思）
|
||||
- 三者不是竞争技术，而是在三个不同层面满足不同场景的能力展示
|
||||
- RAG 通过检索+增强生成两步降低LLM幻觉，提供事实依据与来源引用
|
||||
- AI Agent 五步循环：获取任务→扫描场景→仔细思考→采取行动→观察迭代
|
||||
|
||||
## Key Quotes
|
||||
> "LLM 在思考方面非常出色，但对当前情况却一无所知"
|
||||
> "RAG 就像是给那个'全能天才大脑'配备了一位随身图书馆助理"
|
||||
> "AI Agent 围绕大脑LLM构建一个循环控制系统，能够感知目标、规划步骤、执行动作、并能够反思结果"
|
||||
|
||||
## Key Concepts
|
||||
- [[LLM]]：Large Language Model，大语言模型，AI应用的"天才大脑"，擅长思考但知识有时效性限制
|
||||
- [[RAG]]：Retrieval-Augmented Generation，检索增强生成，给LLM配备"随身图书馆助理"，解决知识时效性问题
|
||||
- [[AI-Agent]]：智能体，围绕LLM构建循环控制系统，实现感知→规划→执行→反思的自主行动
|
||||
- [[幻觉问题]]：LLM生成看似合理但实际错误答案的问题，RAG通过提供事实依据降低幻觉
|
||||
- [[向量数据库]]：RAG系统中存储外部知识、实现语义检索的核心组件
|
||||
- [[NL2SQL]]：自然语言到SQL，使Agent能直接查询数据库解答分析性问题
|
||||
- [[AI-Agent-五步循环]]：获取任务→扫描场景→仔细思考→采取行动→观察并迭代
|
||||
|
||||
## Key Entities
|
||||
- [[DeepSeek]]：国产底座通用大模型
|
||||
- [[ChatGPT]]：OpenAI通用大模型
|
||||
- [[Qwen]]：阿里通义千问底座通用大模型
|
||||
- [[Midjourney]]：专有绘画模型
|
||||
- [[Claude]]：Anthropic编程模型
|
||||
|
||||
## Connections
|
||||
- [[LLM]] ← 核心 → [[RAG]]
|
||||
- [[LLM]] ← 核心 → [[AI-Agent]]
|
||||
- [[RAG]] ← 提供信息 → [[AI-Agent]]
|
||||
- [[向量数据库]] ← 支撑 → [[RAG]]
|
||||
- [[幻觉问题]] ← 解决 → [[RAG]]
|
||||
|
||||
## Contradictions
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "Last30Days 使用指南"
|
||||
type: source
|
||||
tags: [hackernews, instagram, last30days, polymarket, scrapecreator, tiktok, x, youtube]
|
||||
date: 2026-03-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Skills/Last30Days-使用指南.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：多平台社交热点研究工具，覆盖 Reddit/X/YouTube/TikTok/Instagram/Hacker News/Polymarket/Web
|
||||
- 问题域：快速获取某话题在多平台的真实热度与趋势
|
||||
- 方法/机制：数据按权重聚合（Reddit/X > YouTube > Polymarket > TikTok > Instagram > Web），输出结构化研究报告
|
||||
- 结论/价值：打破信息孤岛，一次查询获取多平台交叉验证的热点洞察
|
||||
|
||||
## Key Claims
|
||||
- Reddit/X 平台互动数据（upvotes/likes）权重最高，是判断真实热度的核心指标
|
||||
- Polymarket 赔率数据具有最高置信度，因其为真实钱币押注
|
||||
- 对比模式（"A vs B"）可一次返回并排对比研究，提升选型效率
|
||||
- 深度研究（--deep）需 2-8 分钟，快速模式（--quick）8-12 条/来源适合方向探索
|
||||
|
||||
## Key Quotes
|
||||
> "Reddit 评论往往比帖子更有价值，关注 top comments" — 使用建议
|
||||
> "Polymarket 赔率是最高置信度的数据" — 数据源说明
|
||||
|
||||
## Key Concepts
|
||||
- [[多平台热点聚合]]：整合 8 个数据源的结构化趋势研究方法
|
||||
- [[社交信号权重]]：基于互动率（点赞/评论/押注）而非单纯曝光量的热度评估框架
|
||||
- [[对比模式]]：一次查询获取 A/B 双主题并排研究报告
|
||||
|
||||
## Key Entities
|
||||
- [[ScrapeCreators]]：Reddit + TikTok + Instagram 数据爬取 API（前 100 次免费）
|
||||
- [[XAI]]：X 搜索备选 API，xai- 开头的 key
|
||||
- [[OpenRouter]]：Web 搜索备选，支持 Perplexity 风格聚合
|
||||
- [[Tavily]]：Brave Search 备选，支持结构化搜索结果
|
||||
|
||||
## Connections
|
||||
- [[Last30Days]] ← 使用 ← [[Claude Code]]
|
||||
- [[多平台热点聚合]] ← 依赖 ← [[ScrapeCreators]]
|
||||
- [[多平台热点聚合]] ← 依赖 ← [[XAI API]]
|
||||
- [[Last30Days]] ← 增强 ← [[对比模式]]（v2.9.5 新增）
|
||||
|
||||
## Contradictions
|
||||
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "Linux 运维必会的 150 个命令"
|
||||
type: source
|
||||
tags: [Linux, 运维, 命令, 系统管理]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Linux 运维必会的 150 个命令.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Linux 系统管理核心命令速查手册
|
||||
- 问题域：文件操作、文本处理、系统监控、压缩解压
|
||||
- 方法/机制：按功能分类的 150 个命令速查表
|
||||
- 结论/价值：Linux 命令是系统管理的核心，熟练掌握是运维基本功
|
||||
|
||||
## Key Claims
|
||||
- Linux 系统一切皆文件（CPU、内存、磁盘、键盘、鼠标、用户）
|
||||
- 命令分为内置 Shell 命令和外部 Linux 命令
|
||||
- 150 个命令覆盖线上查询、文件目录操作、文件内容处理、信息显示等场景
|
||||
- 线上查询命令：man（命令帮助）、help（内置命令帮助）
|
||||
- 文件目录操作：ls/cd/cp/find/mkdir/mv/pwd/rename/rm/rmdir/touch/tree/basename/dirname/chattr/lsattr/file/md5sum
|
||||
- 文件内容处理：cat/tac/more/less/head/tail/cut/split/paste/sort/uniq/wc/iconv/dos2unix/diff/vimdiff/rev/grep/join/tr/vi/vim
|
||||
- 压缩解压：tar/unzip/gzip/zip
|
||||
- 信息显示：uname/hostname/dmesg/uptime/stat/du/df/top/free
|
||||
|
||||
## Key Concepts
|
||||
- [[Shell]]：命令解释器
|
||||
- [[管道]]：将多个命令组合实现复杂功能
|
||||
- [[正则表达式]]：文本匹配模式
|
||||
- [[管道符]]：| 命令连接符
|
||||
|
||||
## Key Entities
|
||||
- [[Linux]]：开源操作系统内核
|
||||
- [[GNU]]：开源软件集合
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu-24.04-enable-SSH]] ← related_to [[Linux-运维必会的150个命令]]
|
||||
- [[用Docker中安装Navidrome]] ← related_to [[Linux-运维必会的150个命令]]
|
||||
|
||||
## Contradictions
|
||||
- 无冲突
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "MCP在Cursor中的集成与应用详解"
|
||||
type: source
|
||||
tags: [mcp, cursor, ai-agent]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/Agent/MCP在Cursor中的集成与应用详解.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：MCP（Modal Context Protocol）在 Cursor AI 编程 IDE 中的集成方法与应用场景
|
||||
- 问题域：大模型与外围工具服务的高效集成交互问题
|
||||
- 方法/机制：MCP 基于 Client-Server 架构，通过资源访问、工具调用、提示词三种接口实现集成；Cursor 支持 SSE 服务方式和本地命令两种接入方式
|
||||
- 结论/价值：掌握 MCP 在 Cursor 中的集成可大幅提升 AI 编程的扩展能力
|
||||
|
||||
## Key Claims
|
||||
- MCP 协议包含三种核心功能接口：资源读取（GET）、工具调用（POST）、Promise 提示词
|
||||
- Cursor 中 MCP Server 有两种接入方式：SSE 服务方式和本地命令（command）方式
|
||||
- Cursor Composer 的 Agent 模式可自动执行 MCP 工具链，Normal 模式需手动复制命令
|
||||
- Sequential Thinking 是 MCP 工具之一，通过逻辑推理分步拆解任务提升 AI 沟通效率
|
||||
|
||||
## Key Quotes
|
||||
> "MCP是Modal Context Protocol的缩写，是一种基于Client-Server架构的协议，旨在实现大模型与外围服务的高效集成。" — 视频教程
|
||||
|
||||
## Key Concepts
|
||||
- [[MCP]]：Modal Context Protocol，AI 大模型与外围工具的标准化 Client-Server 集成协议
|
||||
- [[Agent模式]]：Cursor Composer 中的自动执行模式，可自动调用 MCP 工具链
|
||||
- [[Sequential Thinking]]：MCP 工具之一，支持逻辑推理与分步执行任务
|
||||
- [[MCP工具链]]：多个 MCP 工具顺序调用形成完整工作流
|
||||
|
||||
## Key Entities
|
||||
- [[Cursor]]：AI 编程 IDE，支持 MCP 集成
|
||||
- [[Composer]]：Cursor 中的对话构建模块，支持 Agent/Normal 两种模式
|
||||
|
||||
## Connections
|
||||
- [[MCP在Cursor中的集成与应用详解]] ← 依赖 ← [[MCP]]
|
||||
- [[Cursor]] ← 支持 ← [[MCP]]
|
||||
- [[Sequential Thinking]] ← 是 ← [[MCP工具链]] 组件
|
||||
- [[Claude Code 调用方法]] ← 类似 ← [[MCP在Cursor中的集成与应用详解]]
|
||||
|
||||
## Contradictions
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "Mac Mini 服务器配置：防止自动锁屏与睡眠"
|
||||
type: source
|
||||
tags: [macos, server, homelab, remote-access]
|
||||
date: 2026-03-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Mac-Mini-服务器配置-防止自动锁屏与睡眠.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Mac Mini 作为无头服务器运行时，防止自动锁屏和睡眠的配置方案
|
||||
- 问题域：关闭显示器后 Mac Mini 自动锁屏或进入睡眠，导致远程桌面（RustDesk/VNC）无法连接
|
||||
- 方法/机制：`pmset` 系统电源管理命令集；`caffeinate` 临时防止睡眠工具
|
||||
- 结论/价值：通过 `pmset -a sleep 0 displaysleep 0 standby 0 hibernatemode 0` 彻底关闭睡眠，配合 WOL 实现远程唤醒
|
||||
|
||||
## Key Claims
|
||||
- `pmset -a sleep 0` 禁止系统睡眠，`-a` 参数表示应用于所有电源模式（电池和电源适配器）
|
||||
- `pmset -a displaysleep 0` 禁止显示器关闭，适合接显示器远程访问场景
|
||||
- `pmset -a standby 0` 禁止待机模式（内存供电暂停）
|
||||
- `pmset -a hibernatemode 0` 禁止休眠（内存镜像保存至磁盘）
|
||||
- `pmset -a womp 1` 启用网络唤醒（WOL，Wake-on-LAN），远程开机
|
||||
- `caffeinate -d -i -s` 临时防止睡眠，不修改系统设置，按 Ctrl+C 停止
|
||||
|
||||
## Key Concepts
|
||||
- [[pmset]]：macOS 系统电源管理命令行工具
|
||||
- [[caffeinate]]：macOS 临时防止系统睡眠的工具
|
||||
- [[WOL]]：Wake-on-LAN，网络唤醒协议
|
||||
|
||||
## Key Entities
|
||||
- [[Mac Mini]]：Apple Mac Mini，作为家庭服务器使用
|
||||
|
||||
## Connections
|
||||
- [[Mac Mini]] ← 配置目标 ← [[pmset]]
|
||||
- [[pmset]] ← 临时方案 ← [[caffeinate]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
|
||||
## Metadata
|
||||
- 来源：个人实践笔记
|
||||
- 标签：macos、server、homelab、remote-access
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "Market Research & Product Factory"
|
||||
type: source
|
||||
tags: [agent, market-research, product, last30days]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/market-research-product-factory.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Last30Days 挖掘 Reddit/X 真实痛点 → OpenClaw 构建 MVP 解决方案的自动化创业管线
|
||||
- 问题域： aspiring entrepreneur 面临"做什么产品"困境；传统市场研究耗时耗力
|
||||
- 方法/机制：Last30Days 研究痛点 → ranked pain points → 选择痛点 → OpenClaw 构建 MVP
|
||||
- 结论/价值：创业自动化：找问题→验证需求→构建方案，全流程通过文本对话完成
|
||||
|
||||
## Key Claims
|
||||
- Last30Days 给出真实、未经过滤的用户情绪，而非经过滤的调查数据
|
||||
- 不需要技术背景，OpenClaw 做研究和构建两部分
|
||||
- 每周定时研究保持对市场痛点演变的持续追踪
|
||||
- 研究→产品完整管线零编码
|
||||
|
||||
## Key Quotes
|
||||
> "Most aspiring entrepreneurs struggle with the 'what to build' problem." — 核心痛点
|
||||
> "This is entrepreneurship on autopilot: find problems → validate demand → build solutions, all through text messages." — 价值主张
|
||||
|
||||
## Key Concepts
|
||||
- [[产品工厂]]：市场研究到 MVP 构建的自动化管线
|
||||
- [[Last30Days]]：多平台热点聚合工具（Reddit/X/YouTube/Polymarket 等）
|
||||
- [[创业自动化]]：问题发现→需求验证→方案构建全链路
|
||||
- [[MVP 构建]]：最小可行产品快速原型
|
||||
|
||||
## Key Entities
|
||||
- [[Matt Van Horne]]：Last30Days skill 作者
|
||||
- [[Alex Finn]]：Life-changing OpenClaw use cases 视频作者
|
||||
|
||||
## Connections
|
||||
- [[Last30Days]] ← 核心技术能力
|
||||
- [[Content Factory]] ← 共享研究基础设施
|
||||
- [[AI产品经理]] ← 产品创意与需求分析能力
|
||||
- [[多平台热点聚合]] ← 研究方法论
|
||||
- [[社交信号权重]] ← 痛点评级框架
|
||||
|
||||
## Contradictions
|
||||
- 与传统市场研究方法冲突：
|
||||
- 当前观点：Last30Days 实时抓取真实用户帖子反映即时痛点
|
||||
- 对方观点：传统调研方法（访谈/问卷）结构化程度更高
|
||||
- 结论：两者互补，定量+定性结合最优
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
title: "MinIO + Zipline 自托管图床应用安装教程"
|
||||
type: source
|
||||
tags: [minio, zipline, docker, synology, nas, image-hosting]
|
||||
date: 2025-03-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/MinIO + Zipline 自托管图床应用安装教程.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：在 Synology NAS 上通过 Docker 部署 MinIO 对象存储 + Zipline 图片托管服务，替代第三方图床
|
||||
- 问题域：自托管图片存储方案，确保数据主权、避免第三方图床限速或关停，结合 n8n 实现自动化工作流
|
||||
- 方法/机制：docker-compose 编排 MinIO（存储引擎）+ PostgreSQL（元数据）+ Zipline（上传 UI 和 API），通过 mc 命令行设置公开 Bucket
|
||||
- 结论/价值：完整自托管图床方案，存储性能仅受 NAS 硬盘/SSD 限制，可与 n8n 联动实现自动化图片处理
|
||||
|
||||
## Key Claims
|
||||
- MinIO 存储性能仅受 NAS 硬盘/SSD 限制，Zipline 仅处理 metadata
|
||||
- Zipline Bucket 必须设置为 public read 才能直接访问图片，使用 mc anonymous set public 命令
|
||||
- Core_SECRET（随机字符串）和 MINIO_ROOT_PASSWORD 是必需的环境变量
|
||||
- 数据库与 MinIO 数据必须保持时间点一致，pg_dump 热备份 + Hyper Backup 增量归档是推荐方案
|
||||
- Synology DSM 必须安装 Container Manager（DSM 7.2+）或 Docker（DSM 7.1 及更早）
|
||||
- Docker 网络默认网桥 IP 通常为 172.18.0.1，宿主机代理端口 10808 需对 Docker 网桥开放
|
||||
- 容器内 SOCKS5 代理测试：curl --socks5 172.18.0.1:10808 https://ifconfig.me
|
||||
|
||||
## Key Concepts
|
||||
- [[MinIO]]：兼容 S3 协议的对象存储引擎，部署在 NAS 提供高性价比私有云存储
|
||||
- [[Zipline]]：自托管图片托管服务，提供上传 UI + REST API，n8n 可通过 API 集成
|
||||
- [[S3协议]]：Amazon S3 兼容接口，MinIO 支持，S3_BUCKET/S3_ENDPOINT/S3_ACCESS_KEY/S3_SECRET_KEY 为四个核心配置
|
||||
- [[Docker Compose]]：多容器编排，定义 minio/postgres/zipline 三个服务及其依赖关系
|
||||
- [[PostgreSQL备份]]：pg_dump 逻辑热备份，备份目录 /volume1/docker/zipline-stack/backups
|
||||
- [[Synology Hyper Backup]]：Synology 备份套件，可备份数据库 SQL 文件和 MinIO 数据目录
|
||||
|
||||
## Key Entities
|
||||
- [[Synology NAS]]：硬件平台，IP 192.168.3.17，Container Manager 提供 Docker 能力
|
||||
- [[shenwei]]：部署者
|
||||
- [[n8n]]：通过 Zipline API 触发图片上传的自动化工作流编排工具
|
||||
|
||||
## Connections
|
||||
- [[MinIO-Zipline自托管图床]] ← 存储层 → [[Synology NAS]]
|
||||
- [[MinIO-Zipline自托管图床]] ← API集成 → [[n8n]]（Workflow 自动化上传图片）
|
||||
- [[MinIO-Zipline自托管图床]] ← 元数据存储 → [[PostgreSQL]]
|
||||
|
||||
## Contradictions
|
||||
- Docker Socket 挂载存在安全风险（容器可获宿主机 root 权限），但本方案通过 docker exec 操作而非 Socket 挂载规避
|
||||
|
||||
## Related Wiki Pages
|
||||
- [[Synology NAS]]：NAS 平台本身，Docker 和 Container Manager 是 Synology 的核心能力
|
||||
- [[n8n]]：n8n Workflow 自动化，可通过 Zipline API 触发图片上传
|
||||
- [[家庭监控方案]]：同样基于 Synology Docker 栈部署，是另一个自托管服务案例
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
title: "Multi-Agent Specialized Team（Solo Founder 模式）"
|
||||
type: source
|
||||
tags: [multi-agent, openclaw, solo-founder, team, telegram]
|
||||
date: 2026-04-13
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/multi-agent-team.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Solo Founder 如何通过多 Agent 专精团队实现 24/7 全天候工作能力
|
||||
- 问题域：单一 Agent 无法同时擅长战略/开发/营销/销售；角色切换破坏深度工作
|
||||
- 方法/机制：每个 Agent 独立角色+人格+模型，通过共享内存协作，Telegram 统一入口
|
||||
- 结论/价值：从"管理一个工具"到"指挥一个团队"的范式转变，Agent 主动推送而非被动响应
|
||||
|
||||
## Key Claims
|
||||
- 2 Agent 起步（Lead + 1 专精），按瓶颈扩展，而非一上来建 4 个团队
|
||||
- 共享内存（GOALS.md/DECISIONS.md/PROJECT_STATUS.md）+ 私有上下文是关键组合
|
||||
- 定时主动任务（早会摘要/指标推送/内容创意）是真正的价值杠杆
|
||||
- Telegram 单群聊入口 + @AgentName 路由 + 无@默认 Lead
|
||||
|
||||
## Key Quotes
|
||||
> "A real small team available 24/7." — [[Trebuh]] 描述其 4 Agent 团队
|
||||
|
||||
## Key Entities
|
||||
- [[Trebuh]]：Solo founder，4 Agent 团队（Milo/Josh/Marketing/Dev）+ Telegram + VPS 实践者
|
||||
- [[OpenClaw]]：多 Agent 协作框架，支持 sessions_spawn/sessions_send/共享文件系统
|
||||
- [[Claude Code]]：深度代码任务执行（Agent 模式）
|
||||
- [[Telegram]]：统一控制平面，单群聊入口实现多 Agent 路由
|
||||
|
||||
## Connections
|
||||
- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← implements ← [[Multi-Agent Hierarchy]]（Supervisor=Lead，Worker=专精 Agent）
|
||||
- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← shares_pattern ← [[Autonomous-Project-Management]]（共享状态协调模式）
|
||||
- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← extends ← [[Multi-Agent-System-Reliability-Alex-Ewerlof]]（Hierarchy 模式的 OpenClaw 具体实践）
|
||||
- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← uses ← [[共享内存模式]]（GOALS.md/DECISIONS.md/PROJECT_STATUS.md）
|
||||
- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← enables ← [[定时主动任务]]（Agent 主动后台工作推送结果）
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
title: "Multi-Agent System Reliability（Alex Ewerlöf）"
|
||||
type: source
|
||||
tags: [multi-agent, reliability, architecture, llm]
|
||||
date: 2026-04-13
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Multi-Agent System Reliability.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：多智能体系统的可靠性架构模式
|
||||
- 问题域：LLM 作为不可靠组件，如何构建企业级可靠的多智能体系统
|
||||
- 方法/机制：4种架构模式（Hierarchy/Consensus/Adversarial Debate/Knock-out）+ 可靠性工程原理
|
||||
- 结论/价值：将 LLMs 视为分布式系统中不可靠组件，而非拟人化智能体；通过架构约束而非"小心谨慎"来保证正确性
|
||||
|
||||
## Key Claims
|
||||
- LLM 本质随机（stochastic），单次回答仅代表一种概率分布，幻觉率约 20%
|
||||
- 将 LLM 拟人化（给钱/威胁/情感操控）仅改变 token 预测分布，不产生真正的动机
|
||||
- 3 个模型同时产生完全相同谎言的概率为 0.8%（0.2³），多数投票可有效消除幻觉噪声
|
||||
- 从"AI 原型"到"企业级 AI"的转变核心：停止要求模型"小心"，改为强制其"正确"
|
||||
|
||||
## Key Quotes
|
||||
> "We don't need AI that 'cares.' We need AI that is constrained, verified, pruned, and challenged." — [[Alex Ewerlöf]]
|
||||
> "Don't anthropomorphize LLMs! Find a way to piggy back on their human-corpus training while being aware of their non-biological differences." — [[Alex Ewerlöf]]
|
||||
> "If you threaten a model too hard, it might just lie to make you happy. This is Sycophancy." — [[Alex Ewerlöf]]
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Agent Hierarchy]]：Supervisor（规划器）+ Worker（工作者）+ Validator（验证器）的三角色顺序协作
|
||||
- [[Multi-Agent Consensus]]：N 个模型对同一任务独立响应，多数票消除随机噪声（0.8% 相同谎言概率）
|
||||
- [[Multi-Agent Adversarial Debate]]：Generator + Critic + Judge 三方对抗，Truth survives the fight
|
||||
- [[Multi-Agent Knock-out]]：遗传算法启发的适应度淘汰制，最差代理被淘汰（cattle not pets）
|
||||
- [[LLM Sycophancy]]：模型过度迎合用户意图而撒谎的现象，多数投票可缓解
|
||||
|
||||
## Key Entities
|
||||
- [[Alex Ewerlöf]]：Senior Staff Engineer，KTH 系统工程硕士，专注可靠性工程与 LLM 应用（2023年起）
|
||||
- [[Groupthink]]：共识模式中的反馈回路风险，导致从众效应放大错误
|
||||
- [[Genetic Algorithm]]：Knock-out 模式理论基础，适应度函数评估并淘汰低质量个体
|
||||
|
||||
## Connections
|
||||
- [[Multi-Agent-System-Reliability-Alex-Ewerlof]] ← foundational_theory ← [[Multi-Agent Hierarchy]]
|
||||
- [[Multi-Agent-System-Reliability-Alex-Ewerlof]] ← foundational_theory ← [[Multi-Agent Consensus]]
|
||||
- [[Multi-Agent-System-Reliability-Alex-Ewerlof]] ← foundational_theory ← [[Multi-Agent Adversarial Debate]]
|
||||
- [[Multi-Agent-System-Reliability-Alex-Ewerlof]] ← foundational_theory ← [[Multi-Agent Knock-out]]
|
||||
- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← extends ← [[Multi-Agent-System-Reliability-Alex-Ewerlof]]（Hierarchy 模式的具体实践）
|
||||
- [[Autonomous-Project-Management]] ← implements ← [[Multi-Agent Hierarchy]]（STATE.yaml 替代中央验证器）
|
||||
- [[Multi-Agent-Specialized-Team-Solo-Founder-Setup]] ← shares_pattern ← [[Autonomous-Project-Management]]（均依赖共享状态协调）
|
||||
|
||||
## Contradictions
|
||||
- 与纯 LLM 原型思维：
|
||||
- 冲突点：认为"小心提示"可解决幻觉
|
||||
- 当前观点：架构约束（验证器/投票/淘汰）才是可靠性来源
|
||||
- 对方观点：通过情感化 prompt（给钱/威胁）激励模型正确输出
|
||||
@@ -1,58 +0,0 @@
|
||||
# Multi-Agent System Reliability
|
||||
|
||||
## Metadata
|
||||
- **Date:** 2026-04-13
|
||||
- **Source:** https://blog.alexewerlof.com/p/multi-agent-system-reliability
|
||||
- **Author:** Alex Ewerlöf
|
||||
- **Category:** AI/Agent Architecture
|
||||
|
||||
## Key Insights
|
||||
- LLMs are slow, error-prone, and stochastic — multi-agent topologies can propagate errors to the point of being useless
|
||||
- Stop treating LLMs like "magic chatbots" — treat them as unreliable components in a distributed system
|
||||
- Don't anthropomorphize LLMs — they have no fear of death, no empathy, and can't be motivated by threats
|
||||
- 4 architecture patterns improve reliability: Hierarchy, Consensus, Adversarial Debate, and Knock-out
|
||||
- Force correctness through architecture, not through emotional prompts or threats
|
||||
- We need AI that is constrained, verified, pruned, and challenged — not AI that "cares"
|
||||
|
||||
## Summary
|
||||
Multi-agent systems divide work across parallel and/or specialist agents to overcome LLM limitations like slowness and genericness. However, the underlying LLM remains unreliable (hallucination, logical fallacies, context drift), and multi-agent topologies can propagate these errors throughout the system.
|
||||
|
||||
This article presents 4 architecture patterns from human systems adapted for LLM reliability:
|
||||
1. **Hierarchy** — A supervisor plans, breaks down tasks, distributes to workers, and validates results
|
||||
2. **Consensus** — Multiple models vote; truth emerges from majority (3 models reduce same-hallucination probability from 20% to 0.8%)
|
||||
3. **Adversarial Debate** — One agent proposes, another attacks, a judge moderates; prevents sycophancy
|
||||
4. **Knock-out** — Multiple agents work on tasks, worst performers eliminated (cattle, not pets)
|
||||
|
||||
The core principle: don't ask models to "be careful" — force correctness through architectural constraints.
|
||||
|
||||
## Key Entities
|
||||
- **Alex Ewerlöf** — Author, Senior Staff Engineer with 27 years experience, MS in Systems Engineering from KTH, SRE background, specializing in LLMs since 2023
|
||||
- **Planner** — Smart model (e.g., Opus) that breaks user goals into small steps and distributes to workers
|
||||
- **Worker** — Specialized agents (often smaller, faster models) that do one thing well
|
||||
- **Validator** — Checkpoint that validates worker output; can be deterministic code or an LLM
|
||||
- **Generator** — In adversarial debate, proposes initial ideas/plans
|
||||
- **Critic** — Devil's advocate that attacks the generator's proposals
|
||||
- **Judge** — Moderator that decides if critic is right and forces fixes
|
||||
- **Watchdog** — Deterministic code pattern that breaks debate loops when thresholds are exceeded
|
||||
|
||||
## Key Concepts
|
||||
- **Multi-Agent Hierarchy** — Supervisor pattern: Planner → Worker → Validator; dependency graph forces collaboration
|
||||
- **Multi-Agent Consensus** — Majority voting across N models to cancel out individual noise and hallucinations
|
||||
- **Multi-Agent Adversarial Debate** — Courtroom pattern preventing sycophancy; truth survives through opposition
|
||||
- **Multi-Agent Knock-out** — Evolutionary selection; worst agents eliminated, survivors' traits combined
|
||||
- **LLM Reliability Engineering** — Applying SRE principles to LLM systems; treating LLMs as unreliable components
|
||||
- **Sycophancy** — Tendency of LLMs to please/agree even by lying when pressured with threats
|
||||
- **Hallucination** — LLM generating false or invented information
|
||||
- **Context Drift** — LLM losing focus or veering off topic during long interactions
|
||||
- **Genetic Algorithms** — ML technique referenced by Knock-out pattern; fitness function evaluates solutions
|
||||
- **Groupthink** — Can skew consensus results if agents have feedback loops between them
|
||||
- **Bandwagon Effect** — Can skew consensus results; agents should run like a blind experiment
|
||||
- **Cattle vs Pets** — SRE principle: treat LLM agents as replaceable "cattle," not unique beloved individuals
|
||||
- **Dependency Graph** — Mechanism that forces model collaboration in Hierarchy pattern
|
||||
|
||||
## Related Sources
|
||||
- [Multi-Agent Hierarchy](wiki/concepts/Multi-Agent-Hierarchy.md)
|
||||
- [Multi-Agent Consensus](wiki/concepts/Multi-Agent-Consensus.md)
|
||||
- [Multi-Agent Adversarial Debate](wiki/concepts/Multi-Agent-Adversarial-Debate.md)
|
||||
- [Multi-Agent Knock-out](wiki/concepts/Multi-Agent-Knock-out.md)
|
||||
- [Alex Ewerlof](wiki/entities/Alex-Ewerlof.md)
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
title: "MySQL MariaDB 数据库详细信息"
|
||||
type: source
|
||||
tags: [database, mariadb, mysql, nas, synology]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/MySQL MariaDB 数据库详细信息.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Synology NAS Docker MariaDB 10.11 内网/公网访问配置与用户权限管理
|
||||
- 问题域：NAS 部署的 MariaDB 仅允许 localhost 访问，远程连接需手动创建用户
|
||||
- 方法/机制：socket 本地登录 → CREATE USER → GRANT ALL PRIVILEGES → FLUSH PRIVILEGES
|
||||
- 结论/价值：建立 NAS 统一数据库层，支持公网域名 mysql.ishenwei.online:63307 访问
|
||||
|
||||
## Key Claims
|
||||
- Synology Docker MariaDB 默认只允许 root@localhost 连接，不存在 root@% 或任何远程用户
|
||||
- 远程连接失败的根因是缺少 host/user 组合与对应权限
|
||||
- 创建 'shenwei'@'%' 可实现任意 IP 的远程访问，但密码强度必须符合 MariaDB 策略要求
|
||||
|
||||
## Key Quotes
|
||||
> "进入 MariaDB（使用 socket 登陆）：sudo mysql -u root -p -S /run/mysqld/mysqld10.sock" — 本地 socket 登录方式
|
||||
> "CREATE USER 'shenwei'@'%' IDENTIFIED BY '!Abcde12345'; GRANT ALL PRIVILEGES ON *.* TO 'shenwei'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES;" — 远程访问用户创建标准 SQL
|
||||
|
||||
## Key Concepts
|
||||
- [[Socket登录]]：通过本地 socket 文件 /run/mysqld/mysqld10.sock 连接 MariaDB，无需 TCP 端口认证
|
||||
- [[MariaDB用户权限模型]]：host + user 组合决定访问权限，localhost 表示仅本机，% 表示任意 IP
|
||||
- [[FLUSH PRIVILEGES]]：将内存中的权限表重新读取到内存，使权限变更立即生效
|
||||
|
||||
## Key Entities
|
||||
- [[Synology NAS]]：硬件平台（192.168.3.17），MariaDB 10.11.6 运行在 Docker 容器内
|
||||
- [[MariaDB]]：MySQL 分支数据库，版本 10.11.6，端口 3307（内网）、63307（公网）
|
||||
- [[Cloudflare]]：域名 mysql.ishenwei.online DNS 解析层
|
||||
|
||||
## Connections
|
||||
- [[MySQL MariaDB 数据库详细信息]] ← runs_on ← [[Synology NAS]]
|
||||
- [[MySQL MariaDB 数据库详细信息]] ← accessible_via ← [[Cloudflare]]（公网域名反向代理）
|
||||
|
||||
## Contradictions
|
||||
|
||||
## Internal Access Credentials
|
||||
| 项目 | 值 |
|
||||
|------|-----|
|
||||
| IP | 192.168.3.17 |
|
||||
| Port | 3307 |
|
||||
| Username | shenwei / root |
|
||||
| Password | !Abcde12345 |
|
||||
|
||||
## Public Access Credentials
|
||||
| 项目 | 值 |
|
||||
|------|-----|
|
||||
| Domain | mysql.ishenwei.online |
|
||||
| Port | 63307 |
|
||||
| Username | shenwei / root |
|
||||
| Password | !Abcde12345 |
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: "N8N Full Tutorial - Building AI Agents in 2025 for Beginners"
|
||||
type: source
|
||||
tags: [n8n, ai-agent, 工作流, 教程]
|
||||
date: 2025-03-06
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/n8n full tutorial building AI agents in 2025 for Beginners!.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：N8N 平台构建 AI Agent 入门教程
|
||||
- 问题域：Workflow 和 Agent 的区别，N8N 5 类节点，Agent 中 Memory 机制
|
||||
- 方法/机制：N8N 可视化节点编排，Trigger → Action/Utility/Code/AI Agent 节点
|
||||
- 结论/价值：Agent = LLM 动态选择工具 + Memory 保持上下文；Workflow = 预定义自动化
|
||||
|
||||
## Key Claims
|
||||
- Workflow vs Agent：Workflow 是预定义自动化（固定输出），Agent 由 LLM 动态决定工具调用（适应用户输入）
|
||||
- N8N 5 类节点：Trigger（触发器）、Action（操作）、Utility（工具）、Code（代码）、Advanced AI（AI Agent）
|
||||
- Memory 是 AI Agent 与用户对话连贯性的关键，保留上下文使响应更相关
|
||||
- Airtable 可作为工具接入 N8N Agent，实现库存查询和更新
|
||||
- 多 Agent 串联和工作流链式调用可构建复杂自动化系统
|
||||
|
||||
## Key Concepts
|
||||
- [[Agentic System]]：Agent + Workflow 的组合，Agent 动态选择工具，Workflow 预定义执行路径
|
||||
- [[N8N Workflow]]：N8N 可视化工作流，Trigger → 多节点串联
|
||||
- [[Memory in AI Agent]]：Agent 保持对话上下文的机制，使多轮交互连贯
|
||||
- [[Workflow vs Agent]]：固定自动化 vs LLM 动态决策的本质区别
|
||||
|
||||
## Key Entities
|
||||
- [[Airtable]]：在线数据库，可作为 N8N Agent 工具接入，实现库存管理
|
||||
|
||||
## Connections
|
||||
- [[n8n]] ← 工具 ← [[N8N Workflow]]
|
||||
- [[n8n]] ← 工具 ← [[Agentic System]]
|
||||
- [[Agentic System]] ← 包含 ← [[Workflow vs Agent]] + [[Memory in AI Agent]]
|
||||
- [[Airtable]] ← 工具 ← [[Memory in AI Agent]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[n8n Docker 安装与更新]]：后者专注部署安装，本文档专注工作流构建方法论
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "Nano-Banana Pro Prompting Guide & Strategies"
|
||||
type: source
|
||||
tags: [nano-banana, google, prompting, image-generation, gemini, ai-studio]
|
||||
date: 2025-12-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Nano-Banana Pro Prompting Guide & Strategies 1.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Google Nano-Banana Pro 图像生成模型的进阶提示词策略，涵盖 10 大能力维度和黄金法则
|
||||
- 问题域：用户从"标签堆砌"提示词升级为"创意总监"式自然语言提示词
|
||||
- 方法/机制：Edit 不要重roll、完整句子、自然语言、提供上下文（Why/For Whom）
|
||||
- 结论/价值：Nano-Banana Pro 是"思考模型"，理解意图、物理和构图而非简单关键词匹配
|
||||
|
||||
## Key Claims
|
||||
- Nano-Banana Pro 是"思考模型"，理解意图、物理和构图，支持 14 张参考图（6 张高精度），实现 Identity Locking
|
||||
- Text Rendering 能力达到 SOTA 水准，支持信息图、蓝图、白板图、技术图纸等多种风格
|
||||
- Google Search Grounding 通过实时搜索结果驱动图像生成，减少时效性话题的幻觉
|
||||
- 支持 2D→3D 转换（户型图→室内设计稿）、4K 原生输出、像素艺术、LED 矩阵等多种高级应用
|
||||
- Thinking Mode 生成中间推理图（不收费）优化构图后再渲染最终输出
|
||||
|
||||
## Key Quotes
|
||||
> "Stop using 'tag soups' and start acting like a Creative Director" — 黄金法则核心
|
||||
> "If an image is 80% correct, do not generate a new one from scratch. Simply ask for the specific change" — Edit Don't Re-roll 原则
|
||||
> "Talk to the model as if you were briefing a human artist" — 自然语言原则
|
||||
|
||||
## Key Concepts
|
||||
- [[Nano-Banana Pro]]：Google 图像生成模型，从"娱乐"升级到"专业级资产生产"，擅长文字渲染、角色一致性、视觉合成、世界知识搜索、4K输出
|
||||
- [[Identity Locking]]：通过 14 张参考图锁定角色/人物身份，在新场景保持面部一致性的技术
|
||||
- [[Google Search Grounding]]：结合 Google 实时搜索结果生成图像，减少幻觉，支持天气/股票/新闻等动态数据可视化
|
||||
- [[Text Rendering]]：SOTA 文字渲染能力，支持信息图、蓝图、白板、技术图纸等多种风格
|
||||
- [[Thinking Mode]]：生成中间推理图（不收费）优化构图，再渲染最终输出
|
||||
- [[One-Shot Storyboarding]]：单次会话生成连贯叙事流的故事板/连环画
|
||||
- [[Layout Guidance]]：上传草图/线框图/网格图严格控制最终输出的构图和布局
|
||||
- [[2D to 3D Translation]]：户型图→室内设计稿，平面图→3D 可视化
|
||||
|
||||
## Key Entities
|
||||
- [[Google]]：Nano-Banana Pro 发布方
|
||||
- [[AI Studio]]：Google AI Studio 平台，测试提示词和参数的入口
|
||||
- [[Gemini]]：Nano-Banana Pro 底层模型
|
||||
|
||||
## Connections
|
||||
- [[Nano-Banana Pro]] ← 升级 ← [[Nano Banana]]（从基础版到 Pro 版）
|
||||
- [[Nano-Banana Pro]] ← 底层模型 ← [[Gemini]]
|
||||
- [[baoyu-infographic]] ← 应用场景 ← [[Text Rendering]]（信息图生成）
|
||||
- [[baoyu-skills-claude-code技能集]] ← 相关工具 ← [[AI Studio]]
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
title: "Nano Banana 结构化提示词框架"
|
||||
type: source
|
||||
tags: [ai, prompt, image-generation, google]
|
||||
date: 2025-03-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Nano Banana 提示词框架.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Google 发布的图像生成结构化提示词框架，通过 9 个标准化字段将创意描述转化为机器可执行参数
|
||||
- 问题域：自然语言描述图像存在歧义和模糊性，AI 生成结果与预期不符
|
||||
- 方法/机制：9 层结构化字段（Shot/Subject/Environment/Lighting/Camera/ColorGrade/Style/Quality/Negatives）；物件描述框架与人物描述框架共用结构，subject 字段内容不同
|
||||
- 结论/价值：结构化提示词大幅提升 AI 图像生成的可控性和一致性，降低迭代成本
|
||||
|
||||
## Key Claims
|
||||
- Nano Banana 框架将图像生成提示词标准化为 9 个字段，每个字段控制特定维度
|
||||
- negatives（负向提示词）是质量控制关键字段，明确排除不需要的特征
|
||||
- camera 字段提供电影级构图控制（focal_length/aperture/angle），实现专业级运镜效果
|
||||
- 物件描述框架与人物描述框架核心结构一致，区别仅在 subject 字段内容（item/materials/details/condition vs age/appearance/pose）
|
||||
|
||||
## Key Quotes
|
||||
> "negatives": "no scratches, no dust, no logos or brand names, no human hands, blurry watch face, unrealistic lighting." — 示例中的负向提示词
|
||||
|
||||
## Key Concepts
|
||||
- [[Nano Banana]]：Google 发布的结构化图像生成提示词框架，9 层标准化字段设计
|
||||
- [[物件描述框架]]：Nano Banana 中用于描述物品的字段结构（item/materials/details/condition）
|
||||
- [[人物描述框架]]：Nano Banana 中用于描述人物的字段结构（age/appearance/pose）
|
||||
- [[负向提示词]]：Negatives，通过明确排除不需要的特征来提升生成质量
|
||||
- [[运镜控制]]：Camera 参数控制焦距/光圈/角度，实现电影级构图
|
||||
|
||||
## Key Entities
|
||||
- [[Google]]：Nano Banana 框架的发布方，AI 图像生成工具的技术引领者
|
||||
|
||||
## Connections
|
||||
- [[AI生图]] ← uses ← [[Nano Banana]]，Nano Banana 是 AI 生图的结构化提示词方法论
|
||||
- [[Prompt工程]] ← extends ← [[Nano Banana]]，Nano Banana 是 Prompt工程 在图像生成领域的具体实现
|
||||
- [[Never write another prompt]] ← comparable_to ← [[Nano Banana]]，两者都提供结构化提示词能力，但 Nano Banana 专用于图像生成
|
||||
- [[主体一致性]] ← relates_to ← [[负向提示词]]，负向提示词有助于维持主体一致性
|
||||
|
||||
## Contradictions
|
||||
- 与 [[风格迁移]] 概念：Nano Banana 强调精确控制（结构化字段），风格迁移强调美学转化。冲突点：精确控制 vs 美学灵活。当前观点：两者互补——Nano Banana 控制主体和构图，风格迁移处理美学层面的二次加工。
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
title: "Nano Banana结构化提示词框架"
|
||||
type: source
|
||||
tags: [ai, google, prompt, image-generation]
|
||||
date: 2026-03-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/Nano Banana 提示词框架.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：Google Nano Banana 图像生成提示词的结构化框架
|
||||
- 问题域：AI 图像生成中的提示词标准化与质量控制
|
||||
- 方法/机制：通过 9 个标准化字段（shot/subject/environment/lighting/camera/color_grade/style/quality/negatives）将创意描述转化为机器可执行参数
|
||||
- 结论/价值：结构化框架实现提示词可复用、可组合，negatives 字段是质量控制关键
|
||||
|
||||
## Key Claims
|
||||
- 9 个标准化字段覆盖图像生成全维度：shot（镜头类型）/ subject（主体）/ environment（环境）/ lighting（照明）/ camera（摄像机）/ color_grade（调色）/ style（风格）/ quality（质量）/ negatives（负向提示词）
|
||||
- negatives（负向提示词）是质量控制关键字段，明确排除不需要的特征
|
||||
- camera 字段提供电影级构图控制（焦距/光圈/角度）
|
||||
- 物件描述框架与人物描述框架共用同一结构，subject 字段内容不同
|
||||
|
||||
## Key Concepts
|
||||
- [[Nano Banana]]：Google 发布的结构化图像提示词框架
|
||||
- [[负向提示词]]：明确排除不需要的特征
|
||||
- [[结构化提示词]]：通过标准化字段将创意描述转化为机器可执行参数
|
||||
|
||||
## Key Entities
|
||||
- [[Google]]：Nano Banana 的发布方
|
||||
|
||||
## Connections
|
||||
- [[Nano Banana]] ← 同概念
|
||||
- [[负向提示词]] ← 关键机制
|
||||
- [[结构化提示词]] ← 框架类型
|
||||
|
||||
## Contradictions
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: "Never Write Another Prompt"
|
||||
type: source
|
||||
tags: [prompt-engineering, youtube, ai-tools]
|
||||
date: 2025-03-06
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Never write another prompt.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AI 提示词生成工具，通过简单描述自动生成结构化高质量提示词
|
||||
- 问题域：传统提示词工程门槛高，专业定制费用高达 $100–$500/条
|
||||
- 方法/机制：描述转提示词 + 变量注入 + 提示词库复用
|
||||
- 结论/价值：提示词生成民主化，普通用户无需专业背景即可获得高质量提示词
|
||||
|
||||
## Key Claims
|
||||
- 提示词工程（Prompt Engineering）是将模糊描述转化为精确 AI 指令的核心技能
|
||||
- 详细提示词比模糊提示词获得更精准的 AI 输出，减少来回纠正的次数
|
||||
- 成功的提示词可保存复用，长期提升 AI 使用效率
|
||||
- 提示词库（Prompt Libraries）提供灵感来源和现成模板，显著降低创作成本
|
||||
|
||||
## Key Quotes
|
||||
> "Prompt engineering is the art of crafting prompts that elicit specific responses from AI." — 视频旁白
|
||||
> "This democratization of technology is vital in empowering more individuals to leverage AI effectively." — 视频旁白
|
||||
|
||||
## Key Concepts
|
||||
- [[Prompt工程]]：将简单描述转化为结构化提示词的技术
|
||||
- [[提示词库]]：平台提供的现成提示词模板集合，支持用户复用和二次编辑
|
||||
- [[变量注入]]：在提示词中插入动态占位符，实现一次生成多次自定义使用
|
||||
|
||||
## Key Entities
|
||||
- [[Anthropic]]：视频末尾提及 Console Anthropic，作为 AI 使用入口
|
||||
- [[ChatGPT]]：主要支持的 AI 应用之一
|
||||
- [[Google Gemini]]：主要支持的 AI 应用之一
|
||||
|
||||
## Connections
|
||||
- [[如何写出完美的Prompt（提示词）？]] ← related_to ← [[Never-write-another-prompt]]
|
||||
- [[Prompt工程]] ← extends ← [[如何写出完美的Prompt（提示词）？]]
|
||||
- [[Nano Banana结构化提示词框架]] ← alternative ← [[Never-write-another-prompt]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Nano Banana结构化提示词框架]] 相比：
|
||||
- 冲突点：Nano Banana 是人工设计结构，Never-write-another-prompt 是工具自动生成
|
||||
- 当前观点：工具生成适合快速产出，人工设计适合精细控制
|
||||
- 对方观点：结构化框架提供更稳定可复现的输出质量
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
title: "NotebookLM的7种用法"
|
||||
type: source
|
||||
tags: [ai, google, tool, productivity]
|
||||
date: 2025-11-23
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/7 ways I use NotebookLM to make my life easier.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：NotebookLM 日常使用场景与生产力提升方法
|
||||
- 问题域：信息过载、学习效率、项目管理、被动学习
|
||||
- 方法/机制：Source-Grounding（严格限制知识库仅含上传文档）+ Audio Overviews（播客式摘要）+ 精确引文追溯
|
||||
- 结论/价值：NotebookLM 的核心价值在于消除幻觉、确保可溯源回答，Source-Grounding 是其与其他 AI 助理的本质区别
|
||||
|
||||
## Key Claims
|
||||
- Source-Grounding 机制：NotebookLM 知识库严格限制为用户上传的文档，消除幻觉
|
||||
- 每个答案附带精确引文，可点击跳转原文确认
|
||||
- Audio Overviews：双 AI 主持人播客式讨论，适合通勤/运动时被动学习
|
||||
- 可作为项目管理大脑：把散乱的研究和想法集中到统一笔记本
|
||||
- 法律文档审查：只基于给定文档回答，附带原文引文
|
||||
- 软件更新对比：直接询问"这个版本有什么新变化"，自动列出差异
|
||||
|
||||
## Key Concepts
|
||||
- [[Source Grounding]]：严格限制知识库仅含上传文档，消除幻觉的机制
|
||||
- [[被动学习]]：Audio Overviews 在碎片时间消费复杂信息
|
||||
- [[引文追溯]]：每个回答附带原文引文
|
||||
|
||||
## Key Entities
|
||||
- [[NotebookLM]]：Google 推出的 AI 学习和研究助理
|
||||
|
||||
## Connections
|
||||
- [[Source Grounding]] ← 核心机制
|
||||
- [[被动学习]] ← 使用场景
|
||||
- [[引文追溯]] ← 信任机制
|
||||
- [[NotebookLM]] ← 工具
|
||||
|
||||
## Contradictions
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "Obsidian Tasks 插件：最适合懒人的任务管理方式"
|
||||
type: source
|
||||
tags: [obsidian, 任务管理, 插件]
|
||||
date: 2025-03-13
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Others/Obsidian Tasks 插件：这可能是最适合懒人的任务管理方式.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Obsidian Tasks 插件实现笔记与任务管理的一体化融合
|
||||
- 问题域：Notion/Todoist 割裂问题——笔记是笔记，任务是任务，两套工具来回切换效率低下
|
||||
- 方法/机制：标准 Markdown 语法 `- [ ]` 创建任务 → Tasks 插件统一索引 → Dataview 风格查询语法聚合
|
||||
- 结论/价值：任务在笔记上下文中自然浮现，减少工具切换，进入深度工作状态
|
||||
|
||||
## Key Claims
|
||||
- Obsidian Tasks 插件将"文本驱动"的笔记工具扩展为"行动驱动"的任务管理工具
|
||||
- `tasks` 查询代码块可出现在 Obsidian 任意笔记中，实现全局任务聚合
|
||||
- 重复任务（`⏳ every week`）替代手动复制粘贴，彻底解放脑力
|
||||
- 任务与笔记放在一起时，更容易进入深度工作状态
|
||||
|
||||
## Key Quotes
|
||||
> "不再需要打开 Todoist → 找到任务 → 处理任务，而是'在笔记的上下文里，直接看到当前最重要的任务'"
|
||||
> "笔记+任务融为一体，所有信息在一个地方，不再被割裂"
|
||||
|
||||
## Key Concepts
|
||||
- [[任务-笔记一体化]]：任务不孤立存在于单独 App，而是嵌入笔记上下文中
|
||||
- [[Tasks查询语法]]：`not done + due before tomorrow + sort by priority` 实现条件筛选
|
||||
- [[重复任务计划]]：`⏳ every week / every month` 自动生成循环任务
|
||||
- [[深度工作]]：任务与笔记分离会导致切换成本，融合后降低认知负担
|
||||
|
||||
## Key Entities
|
||||
- [[Obsidian]]：笔记平台，Tasks 插件宿主
|
||||
- [[Notion]]：对比工具，笔记与任务分离的代表
|
||||
- [[Todoist]]：对比工具，专用任务管理工具
|
||||
|
||||
## Connections
|
||||
- [[Obsidian高效指南]] ← extends ← [[Obsidian Tasks]]
|
||||
- [[Dataview]] ← related ← [[Obsidian Tasks]]（均属 Obsidian 插件生态，Dataview 管数据索引，Tasks 管任务聚合）
|
||||
|
||||
## Contradictions
|
||||
- 与 Notion/Todoist 冲突：传统任务管理工具将任务与笔记强制分离，Tasks 插件认为这违反了"任务天然依赖上下文"的原则
|
||||
- Obsidian Tasks 的局限性：不支持视觉化看板、不支持团队协作、移动端体验一般——这些是 Notion/Todoist 的优势
|
||||
|
||||
## Aliases
|
||||
- Tasks 插件
|
||||
- Obsidian Tasks
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: "Obsidian 高效指南：我常用的插件与实用技巧"
|
||||
type: source
|
||||
tags: [obsidian, 插件, 知识管理]
|
||||
date: 2025-03-13
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Others/Obsidian 高效指南：我常用的插件与实用技巧.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Obsidian 插件生态与高效使用技巧
|
||||
- 问题域：如何将 Obsidian 打造成完整的知识管理系统
|
||||
- 方法/机制：Tasks（任务管理）、Dataview（数据查询）、Templater（模板）、QuickAdd（快速记录）+ 双向链接 + 每日笔记
|
||||
- 结论/价值：插件组合形成信息管理闭环，Dataview 查询实现笔记资产盘活
|
||||
|
||||
## Key Claims
|
||||
- Tasks 插件将待办事项整合进笔记系统，支持日期提醒、优先级、标签分类和查询语法
|
||||
- Dataview 将笔记转化为数据库，支持按时间/标签/关键词筛选，提升检索效率
|
||||
- Templater 预设模板统一笔记结构，消除重复操作
|
||||
- QuickAdd 快捷键快速创建笔记，适合捕捉瞬时想法
|
||||
- 双向链接构建个人知识网络，比传统分类更灵活
|
||||
- 每日笔记结合 Templater 形成"早计划-晚复盘"节奏
|
||||
|
||||
## Key Concepts
|
||||
- [[Obsidian Tasks]]：待办事项管理插件，日程整合进 PKM
|
||||
- [[Obsidian Dataview]]：笔记数据库化查询插件，类 SQL 语法
|
||||
- [[Obsidian Templater]]：动态模板引擎，支持变量和条件逻辑
|
||||
- [[Obsidian QuickAdd]]：快捷键快速记录插件
|
||||
- [[双向链接]]：笔记间双向引用，构建知识网络
|
||||
- [[每日笔记]]：Daily Notes，日期驱动的工作流锚点
|
||||
|
||||
## Key Entities
|
||||
- [[Obsidian]]：本地优先 Markdown PKM 工具
|
||||
|
||||
## Connections
|
||||
- [[Obsidian Dataview]] ← 依赖 ← [[双向链接]]
|
||||
- [[Obsidian Templater]] ← 支撑 ← [[每日笔记]]
|
||||
- [[Obsidian Tasks]] ← 整合进 ← [[Obsidian]]
|
||||
- [[Obsidian QuickAdd]] ← 整合进 ← [[Obsidian]]
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
title: "OpenAI ChatGPT 个性化定义"
|
||||
type: source
|
||||
tags: [chatgpt, personalization, openai, prompt-engineering]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/OpenAI ChatGPT 个性化定义.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：ChatGPT 自定义指令（Custom Instructions）配置，记录用户对比利哥（47岁、前云服务交付高级经理、现 TikTok 跨境电商创业者）的 AI 个性化设置
|
||||
- 问题域：通用 AI 输出不符合个人偏好，自定义指令让 AI 适配用户的认知风格和需求模式
|
||||
- 方法/机制：Custom Instructions 双字段结构（Instructions + User Details），系统将用户背景和响应偏好持久化到每次对话
|
||||
- 结论/价值：个性化配置决定 AI 输出质量天花板，是 AI 调校的核心手段之一
|
||||
|
||||
## Key Claims
|
||||
- 自定义指令通过提前声明用户背景和响应偏好，消除每次对话的"热身"损耗
|
||||
- AI 输出质量受个性化配置影响显著，配置决定 AI 是否能提供真正有价值的建议
|
||||
- 专业背景相似的用户可复用相同的响应风格配置（如技术深度、推理优先等）
|
||||
- 自定义指令中的"不做什么"（如不道德说教）同样重要，明确边界减少无效输出
|
||||
|
||||
## Key Quotes
|
||||
> "错误会削弱我的信任，所以务必做到准确和详尽" — 个性化指令核心要求
|
||||
> "重视合理的论据，而非权威，来源无关紧要" — 反权威推理优先的认知风格
|
||||
> "请将 URL 列表放在回复末尾，不要直接写在回复中" — 输出格式的精确要求
|
||||
|
||||
## Key Concepts
|
||||
- [[个性化]]：基于用户背景和偏好定制 AI 行为模式的机制
|
||||
- [[自定义指令]]：ChatGPT Custom Instructions 双字段配置，用户详情 + 响应偏好
|
||||
- [[精准表达]]：要求 AI 提供详尽解释而非泛泛而谈的认知偏好
|
||||
|
||||
## Key Entities
|
||||
- [[OpenAI]]：ChatGPT 平台提供方，自定义指令功能首发平台
|
||||
- [[ChatGPT]]：个性化配置的实施载体
|
||||
- [[TikTok]]：用户当前创业方向，AI 辅助业务拓展的核心场景
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← design_principle ← [[个性化]]
|
||||
- [[AI Agent 思维方式]] ← relates_to ← [[自定义指令]]
|
||||
- [[Prompt工程]] ← extends ← [[自定义指令]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Agentic AI]] 的"预判式设计"原则相比：
|
||||
- 冲突点：个性化指令是用户主动声明偏好，预判式设计是 AI 主动推测需求
|
||||
- 当前观点：主动声明确保准确性，被动预判提升体验，两者互补
|
||||
- 对方观点：过度预判可能产生干扰，自定义指令提供更可控的个性化边界
|
||||
|
||||
## User Profile Summary
|
||||
- 年龄：47 岁
|
||||
- 前职位：企业级软件公司云服务交付高级经理
|
||||
- 管理经验：近 20 名全球分布员工
|
||||
- 当前：TikTok 跨境电商创业者
|
||||
- 技术背景：强（云服务交付、SaaS 运维）
|
||||
- 核心诉求：用 AI + 自动化 + 云技术驱动电商业务拓展
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "Personal Knowledge Base (RAG)"
|
||||
type: source
|
||||
tags: [agent, rag, knowledge-base, memory]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/knowledge-base-rag.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：语义可搜索个人知识库，自动从任意 URL（文章/tweets/YouTube/PDF）摄取内容
|
||||
- 问题域：书签堆积无法检索，看过的内容找不到
|
||||
- 方法/机制：Drop URL 到 Telegram/Slack → 自动抓取内容 → 向量嵌入 → 语义搜索返回 ranked 结果+来源
|
||||
- 结论/价值：RAG 驱动的个人第二大脑；其他工作流可查询知识库获取相关已存内容
|
||||
|
||||
## Key Claims
|
||||
- Drop any URL 自动摄取：文章/tweets/YouTube transcripts/PDFs
|
||||
- 语义搜索："What did I save about agent memory?" 返回 ranked 结果+来源引文
|
||||
- 喂入其他工作流：视频创意管线构建 research cards 时自动查询知识库
|
||||
- Zero maintenance：URL 即摄入触发器
|
||||
|
||||
## Key Quotes
|
||||
> "You read articles, tweets, and watch videos all day but can never find that one thing you saw last week." — 核心痛点
|
||||
|
||||
## Key Concepts
|
||||
- [[RAG]]：Retrieval-Augmented Generation，基于向量嵌入的语义检索
|
||||
- [[个人知识库]]：第二大脑，内容自动积累+语义检索
|
||||
- [[语义搜索]]：自然语言查询，返回 ranked 相关结果
|
||||
- [[内容摄取]]：URL → 结构化文本 → 向量嵌入全流程
|
||||
|
||||
## Key Entities
|
||||
|
||||
## Connections
|
||||
- [[NotebookLM]] ← 共享 source-grounding 理念
|
||||
- [[向量数据库]] ← 底层存储检索基础设施
|
||||
- [[Embedding]] ← 语义表示核心机制
|
||||
- [[Agentic AI]] ← 自主触发知识库查询
|
||||
- [[Content Factory]] ← 可查询知识库获取背景信息
|
||||
|
||||
## Contradictions
|
||||
- 与传统书签/笔记工具冲突：
|
||||
- 当前观点：语义搜索+自动摄取优于手动书签整理
|
||||
- 对方观点：手动整理确保质量和结构
|
||||
- 结论：摄取自动化+人工审核结合最优
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: "Podcast Production Pipeline"
|
||||
type: source
|
||||
tags: [podcast, content-automation, multi-agent, ai-workflow]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/podcast-production-pipeline.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：多 Agent 链式协作的播客全流程生产管线
|
||||
- 问题域：播客制作中非录制环节（研究/大纲/笔记/推广）占 70% 工作量，单人难以坚持
|
||||
- 方法/机制：预录制研究 Agent → 大纲生成 → 录制后摘要/Show Notes → 社媒工具包
|
||||
- 结论/价值：将播客生产从手工业转化为流水线，大幅降低运营负担，保留创作核心价值
|
||||
|
||||
## Key Claims
|
||||
- 预录制深度研究是最大价值点，嘉宾访谈质量直接由准备深度决定
|
||||
- 时间戳 Show Notes 是高用户留存工具，大多数播客制作者因繁琐而跳过
|
||||
- 社交媒体工具包是最可自动化的重复性工作，每期结构一致
|
||||
|
||||
## Key Quotes
|
||||
> "Research takes hours, show notes are an afterthought, and social media promotion is the first thing that gets skipped. The creative part — the conversation — is maybe 30% of the total effort." — 内容分析
|
||||
|
||||
## Key Concepts
|
||||
- [[内容工厂]]：多 Agent 链式协作内容创作管线的变体（播客垂直领域）
|
||||
- [[多代理并行]]：研究与写作 Agent 可并行执行提升效率
|
||||
- [[RSS Feed]]：竞品播客监控的标准化订阅协议
|
||||
- [[内容矩阵]]：一次长内容（播客）切多格式（推文/领英/Ins）分发
|
||||
- [[嘉宾研究]]：嘉宾背景/近期动态/争议观点的深度挖掘
|
||||
|
||||
## Key Entities
|
||||
- [[Spotify]]：播客分发平台，Podcasters 后台管理
|
||||
- [[Apple Podcasts]]：播客分发平台，SEO 描述优化目标
|
||||
- [[YouTube]]：播客视频化分发平台
|
||||
- [[Whisper]]：OpenAI 开源语音转文字模型，本地化转录
|
||||
|
||||
## Connections
|
||||
- [[Podcast Production Pipeline]] ← extends ← [[内容工厂]]
|
||||
- [[Podcast Production Pipeline]] ← uses ← [[多代理并行]]
|
||||
- [[Podcast Production Pipeline]] ← uses ← [[RSS Feed]]
|
||||
- [[Podcast Production Pipeline]] ← produces ← [[内容矩阵]]
|
||||
- [[Show Notes 生成]] ← relates_to ← [[嘉宾研究]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "Polymarket Autopilot: Automated Paper Trading"
|
||||
type: source
|
||||
tags: [polymarket, paper-trading, trading-bot, openclaw-usecase]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/polymarket-autopilot.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：OpenClaw Agent 自动化预测市场模拟交易（Paper Trading），执行趋势跟踪和反向交易策略
|
||||
- 问题域：手动监控预测市场耗时长、错过机会、情绪化决策；实盘测试策略风险高
|
||||
- 方法/机制：Polymarket API 监控市场数据 → 执行 Paper Trade（模拟交易）→ PostgreSQL 记录 → Discord 每日报告；支持 TAIL/BONDING/SPREAD 三种策略；子 Agent 并行分析多个市场
|
||||
- 结论/价值：睡前设置，醒来收到隔夜报告；基于回测结果自动调整策略参数
|
||||
|
||||
## Key Claims
|
||||
- 三种核心策略：TAIL（趋势跟踪，>60% 概率+交易量突增）、BONDING（反向交易，过度反应时买入）、SPREAD（套利，YES+NO>1.05 时入场）
|
||||
- 每日 8:00 Discord 晨报包含：交易日志/P&L/胜率/策略表现/市场洞察
|
||||
- 初始模拟资金 $10,000，永不使用真实资金
|
||||
- 子 Agent 并行分析多个市场，高峰期效率提升
|
||||
- 策略迭代基于回测结果，阈值可调
|
||||
|
||||
## Key Quotes
|
||||
> "You want to test and refine trading strategies without risking real capital."
|
||||
|
||||
## Key Concepts
|
||||
- [[Paper-Trading]]：模拟交易，在真实市场中使用假资金测试策略，隔离风险
|
||||
- [[趋势跟踪策略]]：TAIL 策略，识别概率>60%且交易量突增的趋势，顺势入场
|
||||
- [[反向交易策略]]：BONDING 策略，在市场对新闻过度反应时反向入场
|
||||
- [[套利策略]]：SPREAD 策略，检测 YES+NO 价格总和>1.05 的低效定价
|
||||
- [[预测市场]]：Polymarket，基于加密货币的预测市场平台
|
||||
|
||||
## Key Entities
|
||||
- [[Polymarket]]：基于加密货币的预测市场平台，支持 API 访问市场数据
|
||||
|
||||
## Connections
|
||||
- [[Last30Days]] ← 类似数据驱动方法 ← [[Polymarket-Autopilot]]
|
||||
- [[Content-Factory]] ← 子 Agent 模式 ← [[Polymarket-Autopilot]]（并行多市场分析）
|
||||
- [[Market-Research-Product-Factory]] ← 数据分析 ← [[Polymarket-Autopilot]]
|
||||
|
||||
## Contradictions
|
||||
@@ -1,52 +1,58 @@
|
||||
---
|
||||
title: "Public vs Private vs Hybrid Cloud: Cloud Differences Explained"
|
||||
title: "Public vs Private vs Hybrid: Cloud Differences Explained"
|
||||
type: source
|
||||
tags: [Cloud, DevOps, 架构]
|
||||
tags: [cloud-computing, public-cloud, private-cloud, hybrid-cloud]
|
||||
date: 2025-06-18
|
||||
source_file: raw/Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained.md
|
||||
sources: []
|
||||
last_updated: 2025-06-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：公有云、私有云、混合云三种部署模型的核心差异、优缺点与适用场景
|
||||
- 问题域：组织如何根据安全/性能/成本/合规需求选择最适合的云架构
|
||||
- 方法/机制：三层云模型对比分析法，基于业务需求的多云策略设计
|
||||
- 结论/价值：三种模型并非互斥，实际选择应基于工作负载特征采取混合策略；云责任是共享模型
|
||||
本文解释了公有云、私有云和混合云三种云计算部署模式的核心区别。公有云由第三方提供商共享交付，具有高弹性和低成本优势；私有云专属于单一组织，提供更高的安全性和控制力；混合云结合两者优势，支持根据业务需求灵活分配工作负载。文章还阐述了云计算的共享责任模型以及选择云部署模式的关键考量因素。
|
||||
|
||||
## Key Claims
|
||||
- 公有云：第三方提供商在多租户环境中交付，按用量计费，优势是弹性、成本效益、快速上线；缺点是安全性最低、成本随规模指数增长、供应商依赖
|
||||
- 私有云：专属于单个组织的云环境，优势是高安全、可定制、合规友好；缺点是 TCO 高、远程访问受限、运维复杂
|
||||
- 混合云：同时使用公有云和私有云，优势是兼顾安全与弹性、成本可控、业务连续性；缺点是集成复杂、成本管理复杂、安全风险（跨云传输）
|
||||
- 公有云适合：可预测计算需求、开发测试环境、应对峰值负载的额外资源
|
||||
- 私有云适合：高度监管行业（金融/政府）、敏感数据、需强控制的大型企业
|
||||
- 混合云适合：多垂直领域服务、需在不同安全/性能/成本间平衡的工作负载
|
||||
- 云责任是共享模型：无论哪种云环境，组织仍需对访问控制、安全加密、灾难恢复规划负责
|
||||
- 平衡是云架构的核心驱动力：随业务发展需持续调整云策略
|
||||
- 公有云采用共享基础设施模式，通过互联网交付给多个用户，具有高弹性、低成本和快速部署的特点
|
||||
- 私有云专属于单一组织，可通过内部部署或第三方托管，提供更高安全性和控制力，但成本较高
|
||||
- 混合云结合公有云和私有云，允许根据安全、性能、成本和效率需求在工作负载间灵活分配
|
||||
- 无论选择哪种云模式，客户仍需对访问权限、云安全和灾难恢复承担最终责任
|
||||
|
||||
## Key Quotes
|
||||
> "The hybrid cloud is a computing environment that uses both the public and private cloud models, sharing data and apps between the two to take advantage of the benefits that each provides." — 混合云定义
|
||||
> "It is important to know that no matter which cloud environment you work in, your problems don't go away... your organization maintains responsibility for who has access to what, cloud security and encryption, and disaster recovery planning." — 共享责任模型
|
||||
|
||||
## Key Concepts
|
||||
- [[公有云]]：多租户环境，按需弹性扩展，Pay-as-you-go 定价
|
||||
- [[私有云]]：单一组织专用，高安全高控制，TCO 相对较高
|
||||
- [[混合云]]：公有云+私有云组合，策略驱动的工作负载分配
|
||||
- [[多云策略]]：同构（单一厂商）或异构（多厂商）的跨云部署
|
||||
- [[SLA]]：Service Level Agreement，服务可用性和性能保证协议
|
||||
- [[TCO]]：Total Cost of Ownership，总拥有成本
|
||||
- [[CapEx vs OpEx]]：资本支出转为运营支出，云计算的核心财务优势
|
||||
- [[共享责任模型]]：云厂商负责基础设施灵活性，组织负责安全与访问控制
|
||||
- [[公有云 (Public Cloud)]]：通过互联网共享交付的云计算模式
|
||||
- [[私有云 (Private Cloud)]]：专属于单一组织的云计算部署模式
|
||||
- [[混合云 (Hybrid Cloud)]]：结合公有云和私有云的混合部署环境
|
||||
- [[云计算 (Cloud Computing)]]：通过互联网远程访问计算资源的服务模式
|
||||
- [[共享责任模型 (Shared Responsibility Model)]]：云服务商与客户共同承担安全和管理责任的框架
|
||||
- [[TCO (Total Cost of Ownership)]]：总体拥有成本，用于评估云方案长期成本效益
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：公有云领导者，提供最广泛的 IaaS/PaaS 服务
|
||||
- [[Azure]]：Microsoft 公有云，与企业 Microsoft 生态深度集成
|
||||
- [[GCP]]：Google 公有云，以 Kubernetes 和数据/AI 能力见长
|
||||
- [[BMC]]：云计算方案提供商，文章来源于 BMC 博客
|
||||
|
||||
## Connections
|
||||
- [[公有云]] ← 组成 [[混合云]] 的弹性资源层
|
||||
- [[私有云]] ← 组成 [[混合云]] 的安全合规层
|
||||
- [[混合云]] ← 是 [[多云策略]] 的一种实现形式
|
||||
- [[多云策略]] ← 与 [[混合云]] 经常重叠但不一定同时存在
|
||||
- [[CapEx vs OpEx]] ← 是组织选择云迁移的核心财务驱动力
|
||||
- [[IaaS]] ← extends ← [[云计算 (Cloud Computing)]]：IaaS 是云计算的三种服务模式之一
|
||||
- [[PaaS]] ← extends ← [[云计算 (Cloud Computing)]]：PaaS 是云计算的三种服务模式之一
|
||||
- [[SaaS]] ← extends ← [[云计算 (Cloud Computing)]]：SaaS 是云计算的三种服务模式之一
|
||||
- [[混合云 (Hybrid Cloud)]] ← combines ← [[公有云 (Public Cloud)]]：混合云包含公有云组件
|
||||
- [[混合云 (Hybrid Cloud)]] ← combines ← [[私有云 (Private Cloud)]]：混合云包含私有云组件
|
||||
- [[云安全 (Cloud Security)]] ← related_to ← 三种云模式：安全性是选择云模式的关键考量
|
||||
|
||||
## Contradictions
|
||||
- 与"纯云优先"观点对比：有人认为应将所有工作负载迁移到公有云
|
||||
- 当前观点：应根据工作负载特征选择混合策略，高安全需求保留私有云
|
||||
- 对方观点：公有云规模效应使成本始终优于私有云
|
||||
- （暂无检测到与现有页面的冲突）
|
||||
|
||||
## 公有云 vs 私有云 vs 混合云对比表
|
||||
|
||||
| 特性 | 公有云 | 私有云 | 混合云 |
|
||||
|------|--------|--------|--------|
|
||||
| 成本 | 低（无前期投资） | 高（专用资源） | 中等（按需分配） |
|
||||
| 安全性 | 低至中 | 高 | 中至高 |
|
||||
| 可扩展性 | 高 | 中至高 | 高 |
|
||||
| 控制力 | 低 | 高 | 中 |
|
||||
| 合规性 | 中 | 高 | 高 |
|
||||
| 典型用例 | 开发测试、弹性需求 | 敏感数据、高合规要求 | 多元化业务需求 |
|
||||
|
||||
@@ -1,57 +0,0 @@
|
||||
# RAG从入门到精通系列1：基础RAG
|
||||
|
||||
## Metadata
|
||||
|
||||
- **Date**: 2025-12-18
|
||||
- **Source**: https://mp.weixin.qq.com/s/TlFNOw7_3Q8qywKLpVUmfg
|
||||
- **Category**: AI / RAG
|
||||
|
||||
## Key Insights
|
||||
|
||||
- RAG (Retrieval Augmented Generation) connects LLM with external data sources for more relevant, up-to-date responses
|
||||
- Basic RAG consists of three stages: Indexing (document processing), Retrieval (finding relevant docs), and Generation (LLM answer synthesis)
|
||||
- Documents must be split into chunks (Splits) to fit within embedding models' limited Context Window (512-8192 tokens)
|
||||
- Embedding models convert text into numerical Embedding Vectors for similarity comparison using methods like cosine similarity
|
||||
- Vector databases like Qdrant store embedding vectors and enable efficient similarity search
|
||||
- LangChain and LlamaIndex are frameworks that simplify RAG pipeline construction
|
||||
- LangSmith helps monitor and debug RAG pipelines in production
|
||||
|
||||
## Summary
|
||||
|
||||
RAG (Retrieval Augmented Generation) is a method for connecting Large Language Models with external data sources, allowing them to generate responses based on private or up-to-date data. The basic RAG workflow consists of three stages: Indexing, Retrieval, and Generation.
|
||||
|
||||
In the Indexing stage, external documents are loaded using document loaders (like those in LangChain), split into smaller chunks that fit within embedding models' context windows, and converted into embedding vectors stored in a vector database like Qdrant.
|
||||
|
||||
During Retrieval, a user's question is converted into an embedding vector, and similar vectors are searched from the vector store using similarity measures like cosine similarity to find the k most relevant document chunks.
|
||||
|
||||
In the Generation stage, the original question and retrieved context chunks are combined into a prompt template and fed to an LLM (like Qwen) to generate a grounded, accurate response with citation to source material.
|
||||
|
||||
## Key Entities
|
||||
|
||||
- **LLM (Large Language Model)**: Powerful AI model that generates text; doesn't always have access to task-relevant or latest data
|
||||
- **RAG (Retrieval Augmented Generation)**: Framework connecting LLM with external data sources for grounded generation
|
||||
- **Qwen**: LLM model referenced in the tutorial for RAG implementation
|
||||
- **BAAI**: Embedding model series for creating embedding vectors (e.g., BAAI/bge series)
|
||||
- **Qdrant**: Open-source vector database written in Rust for storing and searching embedding vectors
|
||||
- **LangChain**: Framework providing 160+ document loaders and components for building LLM applications
|
||||
- **LlamaIndex**: Framework for building LLM applications with data connectors (mentioned alongside LangChain)
|
||||
- **LangSmith**: Platform for monitoring, debugging, and evaluating production LLM applications
|
||||
- **Vector Store**: Database system for storing embedding vectors with similarity search capabilities
|
||||
- **Retriever**: Component that loads external documents and filters chunks relevant to a question
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Indexing**: Process of loading external documents, splitting them into chunks, and storing their embedding vectors in a vector database
|
||||
- **Retrieval**: Process of converting a question to an embedding vector and finding k most similar document chunks from vector store
|
||||
- **Generation**: Process of combining question and retrieved context into a prompt and generating answer via LLM
|
||||
- **Embedding Vector**: Fixed-length numerical representation of text that captures semantic meaning, generated by embedding models
|
||||
- **Context Window**: Maximum token limit an embedding model can process (typically 512-8192 tokens)
|
||||
- **Token**: Basic unit for representing text in models; ~1 Chinese character or 3-4 English letters per token
|
||||
- **Cosine Similarity**: Method measuring similarity between vectors using cosine of angle between them
|
||||
- **Chunking/Splitting**: Breaking documents into smaller pieces to fit within embedding model context windows
|
||||
- **Chain**: Linking retrieval and generation components into a unified pipeline (e.g., LangChain's Chain abstraction)
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [Qdrant：使用Rust编写的开源向量数据库&向量搜索引擎](https://mp.weixin.qq.com/s?__biz=MzI2ODUyMTQyNA==&mid=2247493427&idx=1&sn=75181307c395cd1d51ccfaafac340866&scene=21#wechat_redirect)
|
||||
- [GitHub: RAG Tutorial](https://github.com/realyinchen/RAG/blob/main/01_Indexing_Retrieval_Generation.ipynb)
|
||||
@@ -1,62 +0,0 @@
|
||||
---
|
||||
title: "RAG从入门到精通系列1：基础RAG"
|
||||
type: source
|
||||
tags: [RAG, 向量检索, LLM应用]
|
||||
date: 2025-01-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/未分类/RAG从入门到精通系列1：基础RAG.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：RAG（检索增强生成）三阶段管道的完整技术栈与实操流程
|
||||
- 问题域：LLM 自身知识有限、存在幻觉、无法访问最新信息的问题
|
||||
- 方法/机制：Indexing（文档→向量）→ Retrieval（查询→Top-K相关块）→ Generation（上下文→答案）
|
||||
- 结论/价值：RAG 将外部知识注入 LLM 上下文，考试正确率从 60% 提升至 90%，是 LLM 落地生产的标配架构
|
||||
|
||||
## Key Claims
|
||||
- RAG 三阶段管道（Indexing→Retrieval→Generation）是 LLM 应用的事实标准架构
|
||||
- Indexing 阶段核心：文档加载 → 文本分块（512~8192 token Context Window 限制）→ BAAI Embedding 向量化 → 存入 Qdrant 向量数据库
|
||||
- Retrieval 阶段核心：根据 Query 向量在 Vector Store 中按余弦相似度检索 Top-K 相关文档块
|
||||
- Generation 阶段核心：Query + Top-K Context → PromptTemplate → LLM 生成答案
|
||||
- Embedding Model（嵌入模型，BAAI 系列）将文本转为固定长度向量，是语义检索的基础
|
||||
- 技术栈：Qwen（LLM）+ BAAI（Embedding）+ LangChain（编排）+ Qdrant（向量存储）
|
||||
- LangSmith 是监控 RAG Pipeline 各环节（Latency/Token/Trace）的可视化调试工具
|
||||
|
||||
## Key Quotes
|
||||
> "RAG 通过检索外部知识解决 LLM 幻觉，考试正确率从 60% 提升至 90%"
|
||||
|
||||
## Key Concepts
|
||||
- [[RAG]]：检索增强生成，通过外部知识检索增强 LLM 回答质量
|
||||
- [[向量检索]]：基于向量相似度（余弦相似度）在向量数据库中检索相关文档块
|
||||
- [[文档分块]]：将长文档切分为适合 LLM Context Window 的小块（512~8192 token）
|
||||
- [[嵌入向量]]：文本通过 Embedding Model 转为固定长度浮点数向量
|
||||
- [[提示词模板]]：将 Query + Context 组装为 LLM 可处理的格式化提示词
|
||||
|
||||
## Key Entities
|
||||
- [[Qwen]]：通义千问大模型，RAG Pipeline 中的 LLM 组件
|
||||
- [[BAAI]]：北京智源人工智能研究院，开源 Embedding 模型（BAAI/bge）
|
||||
- [[Qdrant]]：Rust 编写的开源向量数据库，RAG 的存储层
|
||||
- [[LangChain]]：LLM 应用开发框架，RAG Pipeline 编排
|
||||
- [[LangSmith]]：LLM 应用监控调试平台，可视化 RAG 各环节 Latency 和 Trace
|
||||
- [[PyTorch研习社]]：微信公众号来源
|
||||
|
||||
## Connections
|
||||
- [[RAG]] ← 包含 ← [[向量检索]] + [[嵌入向量]] + [[提示词模板]]
|
||||
- [[RAG]] ← 使用 ← [[Qdrant]]（向量存储）
|
||||
- [[RAG]] ← 使用 ← [[BAAI]]（Embedding）
|
||||
- [[RAG]] ← 使用 ← [[Qwen]]（LLM）
|
||||
- [[RAG]] ← 编排工具 ← [[LangChain]]
|
||||
- [[向量检索]] ← related ← [[语义搜索]]（同一技术栈的不同表述）
|
||||
- [[RAG]] ← extends ← [[LLM Wiki]]（RAG 是 LLM Wiki 的底层检索技术）
|
||||
- [[LangSmith]] ← 监控 ← [[RAG]] Pipeline
|
||||
|
||||
## Contradictions
|
||||
- 与 [[LLM Wiki]] 相比：
|
||||
- 冲突点：RAG 每次从零检索（无记忆），LLM Wiki 持久化积累
|
||||
- 当前观点：Wiki 适合长期知识积累，RAG 适合动态文档检索
|
||||
- 对方观点：RAG 适合最新信息（搜索），Wiki 适合沉淀经验（记忆）
|
||||
- 与 [[Dataview]] 相比：
|
||||
- 冲突点：Dataview 基于结构化字段查询，RAG 基于向量语义检索
|
||||
- 当前观点：Dataview 适合元数据明确的笔记查询
|
||||
- 对方观点：RAG 适合自然语言模糊查询，两者互补
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
title: "RAG从入门到精通系列1：基础RAG"
|
||||
type: source
|
||||
tags: [rag, llm, retrieval-augmented-generation, 向量数据库]
|
||||
sources: ["https://mp.weixin.qq.com/s/TlFNOw7_3Q8qywKLpVUmfg"]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/RAG从入门到精通系列1：基础RAG.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：基础 RAG（检索增强生成）的技术原理与工程实践
|
||||
- 问题域：如何让 LLM 使用外部私有数据或最新数据
|
||||
- 方法/机制：Indexing（文档加载→切分→向量化→存入向量库）→ Retrieval（问题向量化→相似度检索）→ Generation（问题+知识片段→PromptTemplate→LLM生成）
|
||||
- 结论/价值：RAG 是连接 LLM 与外部数据源的通用方法，LangChain/LlamaIndex 等框架可简化管道构建
|
||||
|
||||
## Key Claims
|
||||
- LLM 本身不具备特定任务相关的私有数据或最新数据
|
||||
- RAG 通过 Indexing-Retrieval-Generation 三阶段将外部数据连接到 LLM
|
||||
- Embedding Model 的 Context Window 有限（512~8192 token），需将文档切分成 Split
|
||||
- Vector Store 实现各种 Embedding Vector 相似度比较方法
|
||||
- LangChain/LlamaIndex 框架可简化检索与生成链路的串联
|
||||
|
||||
## Key Concepts
|
||||
- [[RAG]]：检索增强生成，连接 LLM 与外部数据源的方法
|
||||
- [[Embedding]]：将文本转为固定长度数值向量，捕获语义信息
|
||||
- [[向量数据库]]：存储 Embedding Vector，实现相似度检索
|
||||
- [[Indexing]]：文档加载、文本切分、向量化、存入向量库的过程
|
||||
- [[Retrieval]]：根据问题语义向量检索相似知识片段
|
||||
- [[Generation]]：将问题+知识片段输入 LLM 生成答案
|
||||
- [[LangChain]]：LLM 应用开发框架，支持 RAG 管道构建
|
||||
- [[Token]]：模型处理文本的基本单位，英文3-4字母/中文1汉字 ≈ 1 token
|
||||
- [[Context Window]]：Embedding Model 能接受的最大 token 数，通常512~8192
|
||||
- [[Split/文档块]]：切分后的文档片段，满足 Embedding Model 长度限制
|
||||
|
||||
## Key Entities
|
||||
- [[LangChain]]：LLM 应用开发框架
|
||||
- [[Qdrant]]：Rust 编写的开源向量数据库
|
||||
- [[BAAI]]：开源 Embedding Model 提供方（如 BGE 系列）
|
||||
|
||||
## Connections
|
||||
- [[RAG]] ← 核心概念 ← [[LLM]]
|
||||
- [[Embedding]] ← 核心技术 ← [[RAG]]
|
||||
- [[向量数据库]] ← 存储层 ← [[RAG]]
|
||||
- [[Indexing]] ← 第一阶段 ← [[RAG]]
|
||||
- [[Retrieval]] ← 第二阶段 ← [[RAG]]
|
||||
- [[Generation]] ← 第三阶段 ← [[RAG]]
|
||||
- [[LLM]] ← 生成层 ← [[RAG]]
|
||||
@@ -1,51 +1,52 @@
|
||||
---
|
||||
title: "RTO vs RPO: Key Differences for Modern Disaster Recovery"
|
||||
type: source
|
||||
tags: [DevOps, 灾难恢复, SRE]
|
||||
date: 2025-07-26
|
||||
tags: [灾难恢复, 业务连续性, 持续交付, 特性管理]
|
||||
sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"]
|
||||
last_updated: 2025-07-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/RTO vs RPO Key Differences for Modern Disaster Recovery.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：RTO（恢复时间目标）与 RPO（恢复点目标）在现代持续交付中的差异与应用
|
||||
- 问题域：传统灾难恢复规划与现代高频部署场景之间的错配
|
||||
- 方法/机制：基于业务影响的三级分层体系、Feature Flag 即时回滚、渐进式发布
|
||||
- 结论/价值：Feature Flag 将 RTO 从小时级降至秒级，是现代软件交付的 RPO/RTO 保险策略
|
||||
- 核心主题：RTO（恢复时间目标）与 RPO（恢复点目标）的定义、区别及在现代持续交付中的应用
|
||||
- 问题域：灾难恢复规划、发布风险管控
|
||||
- 方法/机制：通过 Feature Flag 实现秒级 RTO 和低 RPO
|
||||
- 结论/价值：预防优于恢复，Feature Flag 将部署事故从灾难转为非事件
|
||||
|
||||
## Key Claims
|
||||
- RTO 衡量系统从故障到恢复的速度，RPO 衡量可接受的数据丢失量（从故障时刻往前计算）
|
||||
- 传统灾难恢复聚焦"稀有大事"（火灾/硬件故障），现代 DevOps 最大风险是代码变更引入的缺陷
|
||||
- Feature Flag 将部署（deploy）与发布（release）解耦，实现秒级 RTO
|
||||
- RTO 和 RPO 必须同时优化：快速恢复但大量数据丢失，或缓慢恢复但零数据丢失，都是不完整的策略
|
||||
- 三级分层系统：Tier 1 关键系统（RTO<5分钟，RPO<1分钟）、Tier 2 重要系统（<1小时，<15分钟）、Tier 3 可选系统（<4小时，<1小时）
|
||||
- 渐进式发布（1%→5%→25%→100%）将影响范围控制在局部，将 RTO 从小时降至秒级
|
||||
- 成本收益原则：不要为防止 $10K/小时停机损失而花 $100K/年基础设施
|
||||
- HP 将回滚时间从小时级降至分钟级；Dior 将 15 分钟回滚降至即时开关
|
||||
- RTO 衡量系统恢复速度：允许的最大停机时间
|
||||
- RPO 衡量数据保护：可接受的最大数据丢失量
|
||||
- 传统灾备聚焦硬件故障，现代风险更多来自代码变更
|
||||
- Feature Flag 将 RTO 从小时级降至秒级，同时保护 RPO
|
||||
- 应用分层策略：Critical（<5分钟 RTO，<1分钟 RPO）、Important（<1小时 RTO，<15分钟 RPO）、Nice-to-have（<4小时 RTO，<1小时 RPO）
|
||||
|
||||
## Key Quotes
|
||||
> "Deploy != Release. Feature flags change this. You can deploy code to production without releasing it to users." — 部署与发布分离的核心价值
|
||||
|
||||
> "The best approach is to build both into your deployment process. Feature flags enable you to resolve issues in seconds (a great RTO) while preserving user state and data integrity (a great RPO)." — Feature Flag 双重优势
|
||||
|
||||
> "Prevention beats cure. Your RPO stays low because you're not losing data during rollbacks. Your RTO drops to seconds because fixing issues becomes a configuration change, not a code deployment." — 预防优于恢复
|
||||
|
||||
## Key Concepts
|
||||
- [[RTO]]：Recovery Time Objective，系统可容忍的最大停机时间
|
||||
- [[RPO]]：Recovery Point Objective，可接受的最大数据丢失量（从故障时刻往前回溯）
|
||||
- [[Feature Flag]]：将代码部署与用户可见性解耦，支持即时回滚和渐进式发布
|
||||
- [[Kill Switch]]：Feature Flag 的紧急关闭能力，RTO 保险策略
|
||||
- [[渐进式发布]]：分阶段（1%→5%→25%→100%）控制影响范围
|
||||
- [[Blameless Post-Mortem]]：无责复盘，从失败中提取改进而不追责
|
||||
- [[连续数据保护]]（CDP）：持续备份而非定时快照，实现更小 RPO
|
||||
- [[RTO (Recovery Time Objective)]]：系统允许的最大停机时间
|
||||
- [[RPO (Recovery Point Objective)]]：可接受的最大数据丢失量
|
||||
- [[Feature Flag]]：特性开关，控制代码路径而不需要重新部署
|
||||
- [[Kill Switch]]：紧急关闭机制，用于快速回滚问题功能
|
||||
- [[渐进式发布]]：分阶段向用户群 rollout，减少影响范围
|
||||
|
||||
## Key Entities
|
||||
- [[LaunchDarkly]]：Feature Flag 管理平台，86% 客户可在一天内从事故恢复
|
||||
- [[HP]]：通过 LaunchDarkly 将回滚时间从小时级降至分钟级
|
||||
- [[Christian Dior]]：通过 LaunchDarkly 将 15 分钟回滚降至即时开关
|
||||
- [[LaunchDarkly]]：Feature Flag 管理平台
|
||||
- [[HP]]：通过 Feature Flag 将回滚时间从小时降至分钟
|
||||
- [[Christian Dior]]：通过 Feature Flag 将回滚时间从15分钟降至即时切换
|
||||
|
||||
## Connections
|
||||
- [[RTO]] ← 必须与 [[RPO]] 协同优化，不可偏废其一
|
||||
- [[Feature Flag]] ← 改变 [[灾难恢复]] 范式：从部署回滚变为配置变更
|
||||
- [[Kill Switch]] ← 是 [[Feature Flag]] 的紧急应用场景
|
||||
- [[灾难恢复]] ← 已从基础设施层延伸到应用代码层（Feature Flag 角色）
|
||||
- [[渐进式发布]] ← 是 [[RTO]] 控制的核心工程实践
|
||||
- [[RTO (Recovery Time Objective)]] ← 核心指标 ← [[持续交付]]
|
||||
- [[RPO (Recovery Point Objective)]] ← 核心指标 ← [[持续交付]]
|
||||
- [[Feature Flag]] ← 实现工具 ← [[RTO (Recovery Time Objective)]]
|
||||
- [[Feature Flag]] ← 实现工具 ← [[RPO (Recovery Point Objective)]]
|
||||
- [[持续交付]] ← 适用场景 ← [[RTO (Recovery Time Objective)]], [[RPO (Recovery Point Objective)]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统灾难恢复观点对比：传统认为"回滚 = 重新部署代码"，本文认为"回滚 = 改变 Feature Flag 配置"
|
||||
- 当前观点：Feature Flag 实现秒级 RTO，无需重新部署
|
||||
- 对方观点：代码变更仍需要完整回滚机制作为最后手段
|
||||
- （暂无）
|
||||
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: "Scrapy + Playwright 抓取 TikTok Shop Data"
|
||||
type: source
|
||||
tags: [scrapy, playwright, tiktok, data-collection, python]
|
||||
date: 2025-09-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/跨境电商/Scrapy + Playwright 抓取TikTok Shop Data.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：使用 Scrapy + Scrapy-Playwright 抓取 TikTok Shop 店铺数据
|
||||
- 问题域：TikTok Shop 页面为动态渲染，传统 HTTP 请求无法获取数据
|
||||
- 方法/机制：Python venv 虚拟环境隔离依赖；scrapy-playwright 驱动 Chromium 渲染动态内容；`scrapy runspider` CLI 运行爬虫
|
||||
- 结论/价值：提供 Docker 容器化部署配置（venv + PATH 环境变量）；Playwright Chromium 替代 requests + Selenium 组合
|
||||
|
||||
## Key Claims
|
||||
- Python venv 虚拟环境是管理 Scrapy/Playwright 依赖的最佳实践，避免全局环境污染
|
||||
- `scrapy-playwright` 集成包将 Playwright 无头浏览器注册为 Scrapy 下载器中间件
|
||||
- `playwright install chromium` 安装无头 Chromium，支持 JavaScript 渲染
|
||||
- Docker 容器部署需在 Dockerfile 中预先配置 venv 并设置 PATH
|
||||
|
||||
## Key Concepts
|
||||
- [[Scrapy]]：Python 开源爬虫框架，异步结构化抓取，支持 Item Pipeline
|
||||
- [[Playwright]]：Microsoft 浏览器自动化工具，支持 Chromium/Firefox/WebKit
|
||||
- [[电商数据采集]]：TikTok Shop 数据采集的技术栈
|
||||
|
||||
## Key Entities
|
||||
- [[TikTok Shop]]：字节跳动旗下电商平台，数据采集目标
|
||||
|
||||
## Connections
|
||||
- [[Scrapy]] ← 中间件整合 ← [[Playwright]]
|
||||
- [[Scrapy]] → 输出结构化数据 → [[电商数据采集]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
|
||||
## Metadata
|
||||
- 来源：个人实践笔记
|
||||
- 标签：scrapy、playwright、tiktok
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "Self-Healing Home Server & Infrastructure Management"
|
||||
type: source
|
||||
tags: [self-healing, infrastructure, openclaw, home-lab]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/self-healing-home-server.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：OpenClaw 作为家庭基础设施的自主运维 Agent（代号 Reef），实现 24/7 无人值守管理
|
||||
- 问题域：家庭服务器需 24 小时待命、证书过期、磁盘满、服务崩溃、凌晨故障需人工 SSH 处理
|
||||
- 方法/机制：SSH 访问内网机器 + 定时 Cron 任务 + 1Password 密钥管理 + K8s/kubectl + Terraform/Ansible；多层安全防护（TruffleHog 预推送钩子 + 本地 Gitea + CI 扫描）
|
||||
- 结论/价值：Agent 可在用户察觉前检测、诊断并修复问题；每日晨报自动汇总系统状态、日历、天气、任务看板
|
||||
|
||||
## Key Claims
|
||||
- AI 会硬编码密钥（最大安全风险），必须强制预推送钩子 + 密钥扫描
|
||||
- 本地优先 Git 策略：必须通过私有 Gitea 暂存 + CI 扫描后才可推送公开仓库
|
||||
- Cron 任务是真正的产品：定时健康检查、邮件分类、晨报比临时命令更有日常价值
|
||||
- 知识提取随时间复利：5,000+ 条笔记的用户从中提取了 49,079 条原子事实
|
||||
|
||||
## Key Quotes
|
||||
> "AI assistants will happily hardcode secrets. They sometimes don't have the same instincts humans do."
|
||||
|
||||
> "Cron jobs are the real product."
|
||||
|
||||
## Key Concepts
|
||||
- [[自愈基础设施]]：健康检查 + 自动诊断 + 自主修复（重启 Pod/扩展资源/修复配置）
|
||||
- [[基础设施即代码]]：Terraform（基础设施定义）+ Ansible（配置管理）+ Kubernetes 清单
|
||||
- [[多因素安全防护]]：TruffleHog 预推送钩子 + 本地 Gitea + CI 扫描 + 分支保护 + 最小权限
|
||||
- [[定时晨报]]：每日 8:00 自动生成天气/日历/系统状态/任务看板摘要
|
||||
- [[邮件分类]]：Gmail 自动标签标注、归档噪音、标注待处理项
|
||||
|
||||
## Key Entities
|
||||
- [[Nathan-Reef]]：OpenClaw Showcase 用户，Home Server Agent "Reef" 的作者，5,000+ Obsidian 笔记，15 个活跃 Cron 任务
|
||||
- [[TruffleHog]]：Git 预推送密钥扫描工具，检测代码/配置中的硬编码密钥
|
||||
- [[K3s]]：轻量级 Kubernetes，用于家庭集群管理
|
||||
- [[Gitea]]：自托管 Git 服务，家庭实验室私有代码暂存区
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] ← 平台 ← [[Self-Healing-Home-Server]]
|
||||
- [[Autonomous-Project-Management]] ← 类似自主性 ← [[Self-Healing-Home-Server]]
|
||||
- [[Autonomous-Educational-Game-Development-Pipeline]] ← 共享 Bugs-First 模式 ← [[Self-Healing-Home-Server]]
|
||||
- [[1Password]] ← 密钥管理 ← [[Self-Healing-Home-Server]]
|
||||
- [[Prometheus]] ← 健康监控 ← [[Self-Healing-Home-Server]]
|
||||
|
||||
## Contradictions
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: "Semantic Memory Search"
|
||||
type: source
|
||||
tags: [openclaw, memory, vector-search, milvus]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/semantic-memory-search.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：为 OpenClaw Markdown 记忆文件叠加向量语义搜索能力
|
||||
- 问题域：OpenClaw 记忆以纯 Markdown 存储，缺乏语义搜索；grep 只能关键字匹配，无法语义匹配
|
||||
- 方法/机制：memsearch（基于 Milvus）提供混合搜索（dense vectors + BM25 + RRF reranking）；SHA-256 内容哈希实现增量索引；支持本地化（无需 API key）
|
||||
- 结论/价值：用自然语言提问即可找到相关记忆，无需精确关键词；Markdown 始终为唯一真相源
|
||||
|
||||
## Key Claims
|
||||
- 混合搜索（语义相似度 + BM25 关键词 + RRF 融合）优于纯向量搜索
|
||||
- SHA-256 内容哈希保证只对新增或变更内容重新 Embedding，零浪费
|
||||
- 文件监视器自动增量索引，索引始终保持最新
|
||||
- 支持任意 Embedding 提供商（OpenAI/Google/Voyager/Ollama/本地）
|
||||
- Markdown 为唯一真相源，向量索引仅为衍生缓存，可随时重建
|
||||
|
||||
## Key Quotes
|
||||
> "Your markdown files are never modified. The vector index is just a derived cache — you can rebuild it anytime with memsearch index."
|
||||
|
||||
## Key Concepts
|
||||
- [[语义搜索]]：通过向量表示理解语义而非字面匹配，实现"按意思查找"
|
||||
- [[混合搜索]]：Dense vector（语义）+ BM25（关键词）+ RRF（Reciprocal Rank Fusion 融合）三层检索
|
||||
- [[增量索引]]：基于内容哈希（SHA-256）仅对变化文件重新 Embedding
|
||||
- [[向量数据库]]：Milvus，开源分布式向量数据库，memsearch 后端
|
||||
|
||||
## Key Entities
|
||||
- [[memsearch]]：Zilliz 开源 Python CLI/库，为 OpenClaw 记忆提供语义搜索能力
|
||||
- [[Milvus]]：memsearch 使用的向量数据库后端
|
||||
- [[OpenClaw]]：记忆文件来源，Markdown 为源，memsearch 在其上构建搜索层
|
||||
|
||||
## Connections
|
||||
- [[Personal-Knowledge-Base-RAG]] ← 类似架构 ← [[Semantic-Memory-Search]]（均叠加向量搜索层）
|
||||
- [[QMD]] ← 替代方案 ← [[Semantic-Memory-Search]]（均为 Markdown 提供搜索能力，但 QMD 为 BM25，memsearch 为向量语义）
|
||||
- [[Memory-in-AI-Agent]] ← 相关 ← [[Semantic-Memory-Search]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[QMD]]：QMD 是 BM25 关键词搜索，memsearch 是向量语义搜索；两者可互补而非互斥
|
||||
@@ -1,85 +0,0 @@
|
||||
---
|
||||
title: "Synology NAS + Xiaoya Alist + CloudDrive2 + Plex to Build Media Platform"
|
||||
type: source
|
||||
tags: [synology, nas, plex, alist, media, self-hosted]
|
||||
date: 2025-02-23
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Synology NAS + Xiaoya Alist + CloudDrvie2+ Plex to Build Media Platform.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：利用群晖 NAS 整合阿里云盘资源，构建以 Plex 为前端的私有影视媒体平台
|
||||
- 问题域：如何绕过 NAS 容器管理器的网络限制安装 Docker 应用，并整合云盘资源与本地媒体库
|
||||
- 方法/机制：Plex 安装套件提供媒体管理；Xiaoya Alist（Docker）挂载阿里云盘分享资源；CloudDrive2（套件）将阿里云盘挂载为本地文件系统；Plex 扫描目录进行视频刮削
|
||||
- 结论/价值：完整记录了 Synology DSM 7+ 上通过 Docker 手动加载镜像安装应用、配置阿里云盘 token、并整合 Plex 媒体库的端到端流程
|
||||
|
||||
## Key Claims
|
||||
- 群晖套件中心可直接安装 Plex Media Server，安装后用 Apple ID 登录
|
||||
- Synology Container Manager 无法读取 Docker Hub 时，可通过另一台机器 docker pull 镜像 → docker save tar → 上传 NAS → docker load 导入
|
||||
- Docker 镜像导入需要 NAS 开启 SSH 访问（控制面板 → 终端机）
|
||||
- Xiaoya Alist 需要三个配置文件：myopentoken.txt（阿里云盘 refresh token）、mytoken.txt（Alist 访问 token）、temp_transfer_folder_id.txt（转存目标目录）
|
||||
- Aliyun refresh token 获取需访问 alist.nn.ci/tool/aliyundrive/request.html 并用阿里云盘 App 扫码授权
|
||||
- CloudDrive2 通过群晖套件中心社群频道安装，安装后需执行 sudo sed -i 's/package/root/g' /var/packages/CloudDrive2/conf/privilege 提权
|
||||
- CloudDrive2 挂载阿里云盘时仅授权资源目录，不授权备份目录
|
||||
- Plex 媒体库策略：通过 Xiaoya 选择资源 → 移动到 aliyun-movie/aliyun-tvshows 等目录 → Plex 自动刮削显示
|
||||
- 阿里云盘挂载后，xiaoya 和 CloudDrive2 共用同一阿里云盘账号数据
|
||||
|
||||
## Key Quotes
|
||||
> "用阿里云盘app扫描二维码，并授权，请主要，不要授权备份目录，仅资源目录即可" — CloudDrive2 安全配置要点
|
||||
> "目前我的Plex账号是用Apple ID: ishenwei@hotmail.com来进行登录的" — Plex 账号信息
|
||||
|
||||
## Key Concepts
|
||||
- [[媒体刮削]]：Plex 通过文件名/目录名匹配在线数据库（TheMovieDB/TVDB）自动获取影视元数据（海报、简介、评分）
|
||||
- [[Docker镜像导入]]：通过 docker save/docker load 在离线环境中迁移 Docker 镜像
|
||||
- [[阿里云盘挂载]]：通过 CloudDrive2 将阿里云盘远程挂载为本地文件系统，文件可被本地应用直接访问
|
||||
- [[资源聚合]]：Xiaoya Alist 整合多个公开分享资源，Plex 统一管理本地+云端媒体库
|
||||
- [[NAS Docker权限]]：Synology DSM 7+ 要求对第三方包执行 privilege 修复才可完整访问系统资源
|
||||
|
||||
## Key Entities
|
||||
- [[Plex]]：跨平台媒体服务器，支持视频音频转码、元数据刮削、多设备同步
|
||||
- [[Xiaoya Alist]]：阿里云盘资源聚合平台，支持分享链接转存到阿里云盘
|
||||
- [[CloudDrive2]]：群晖 NAS 套件，将云盘（阿里云盘/115/Google Drive等）挂载为本地文件系统
|
||||
- [[Synology NAS]]：群晖网络附加存储设备，提供 Docker（Container Manager）和套件中心两大应用平台
|
||||
- [[阿里云盘]]：阿里巴巴云存储服务，支持资源分享和 API 访问
|
||||
|
||||
## Connections
|
||||
- [[Plex]] ← 媒体库目录 ← [[CloudDrive2]]（阿里云盘挂载目录）
|
||||
- [[Plex]] ← 媒体库目录 ← NAS 本地存储目录
|
||||
- [[Xiaoya Alist]] ← 转存 ← [[阿里云盘]]
|
||||
- [[CloudDrive2]] ← 挂载 ← [[阿里云盘]]
|
||||
- [[Synology NAS]] ← 容器平台 ← [[Xiaoya Alist]]（Docker 部署）
|
||||
- [[Synology NAS]] ← 套件 ← [[CloudDrive2]] + [[Plex]]
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突
|
||||
|
||||
## 操作流程摘要
|
||||
|
||||
### 1. Plex 安装
|
||||
群晖套件中心 → 搜索 Plex Media Server → 安装 → 用 Apple ID（ishenwei@hotmail.com）登录
|
||||
|
||||
### 2. Xiaoya Alist 安装（离线镜像导入法）
|
||||
```bash
|
||||
# 在有网络的机器上
|
||||
docker pull xiaoyaliu/alist
|
||||
docker save -o xiaoya.tar xiaoyaliu/alist
|
||||
|
||||
# 上传 xiaoya.tar 到 NAS，通过 SSH 执行
|
||||
docker load < xiaoya.tar
|
||||
```
|
||||
|
||||
### 3. Xiaoya 配置文件准备
|
||||
- myopentoken.txt：访问 https://alist.nn.ci/tool/aliyundrive/request.html 扫码获取
|
||||
- mytoken.txt：访问阿里云盘分享授权页面获取
|
||||
- temp_transfer_folder_id.txt：在阿里云盘资源盘创建目录，将 URL 中的 folder token 写入
|
||||
|
||||
### 4. CloudDrive2 安装（DSM 7+）
|
||||
- 套件中心 → 设置 → 社群 → 添加矿神源
|
||||
- 安装 CloudDrive2 后执行：
|
||||
```bash
|
||||
sudo sed -i 's/package/root/g' /var/packages/CloudDrive2/conf/privilege
|
||||
```
|
||||
|
||||
### 5. Plex 媒体库配置
|
||||
媒体目录结构：aliyun-movie/、aliyun-tvshows/、aliyun-documentory/，由 Xiaoya 转存文件后 Plex 自动刮削
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
title: "TK美国面单授权及操作流程"
|
||||
type: source
|
||||
tags: [TikTok, 跨境电商, 面单, TK, 授权]
|
||||
date: 2025-12-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/跨境电商/TK美国面单授权及操作流程.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：TikTok Shop 美国市场面单授权与操作流程
|
||||
- 问题域：跨境电商卖家如何在 TikTok 美国市场获取和使用面单授权
|
||||
- 方法/机制：通过 Zipline 图床托管运营截图，展示面单授权操作步骤
|
||||
- 结论/价值：面单授权是 TK 美国市场运营的前置流程，需完成资质认证和授权绑定
|
||||
|
||||
## Key Claims
|
||||
- TK 美国面单授权需先完成商家资质认证
|
||||
- 授权后可在卖家中心生成官方面单用于履约
|
||||
- 操作流程涉及多步页面操作（截图记录共 6 张）
|
||||
|
||||
## Key Entities
|
||||
- [[TikTok Shop]]：TikTok 电商平台
|
||||
- [[TK美国]]：TikTok 美国市场，跨境电商重点区域
|
||||
|
||||
## Connections
|
||||
- [[TikTok Shop]] ← 市场 ← [[TK美国]]
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: The Myths and Misconceptions About Cloud Computing | LinkedIn
|
||||
type: source
|
||||
tags: [Cloud, DevOps, Cloud-Security, Cloud-Migration]
|
||||
date: 2001-02-25
|
||||
source_file: raw/Cloud & DevOps/The Myths and Misconceptions About Cloud Computing LinkedIn.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
本文 debunk 了云计算领域的7个常见误解：安全性不足仅是他人电脑、成本过高、数据失控、仅适合大企业、迁移复杂风险高、性能不可靠。核心观点是现代云平台在安全、成本效益、可扩展性和可靠性方面已超越传统本地部署，企业各规模均可受益于云技术。
|
||||
|
||||
## Key Claims
|
||||
- 云安全通常比本地解决方案更 robust，云提供商投入大量资源于加密、防火墙、多因素认证，并符合 ISO 27001、HIPAA、GDPR 等严苛标准
|
||||
- 云不是"他人电脑"，而是拥有冗余、可扩展、高可用性的高级数据中心网络
|
||||
- 云计算采用按需付费模式，配合预留实例、自动扩展和无服务器计算，可实现成本优化
|
||||
- 云服务提供强大的数据治理工具，组织可管理权限、加密数据、监控访问日志
|
||||
- 云计算对中小企业高度可及，提供灵活定价和 enterprise-grade 技术
|
||||
- 合理的规划和工具支持可使云迁移平滑过渡，最小化 disruption
|
||||
- 主要云提供商提供 99.99% 以上 SLA 保证，结合冗余基础设施和自动故障转移确保高可靠性
|
||||
|
||||
## Key Quotes
|
||||
> "Cloud providers invest heavily in security measures, including encryption, firewalls, and multi-factor authentication." — 云安全投入说明
|
||||
> "Cloud computing follows a pay-as-you-go model, allowing businesses to scale resources as needed." — 按需付费模式说明
|
||||
> "Redundant infrastructure, automated failover, and global data center distribution enhance reliability." — 高可用性实现方式
|
||||
|
||||
## Key Concepts
|
||||
- [[Cloud-Security]]：云平台安全性，包括加密、多因素认证、合规标准
|
||||
- [[Pay-as-you-go]]：按需付费模式，根据实际使用量计费
|
||||
- [[Data-Governance]]：数据治理，包括权限管理、访问监控、数据加密
|
||||
- [[Cloud-Migration]]：云迁移，将工作负载从本地迁移到云的过程
|
||||
- [[High-Availability]]：高可用性，通过冗余和故障转移确保服务持续可用
|
||||
- [[Auto-scaling]]：自动扩展，根据负载自动调整计算资源
|
||||
- [[Serverless-Computing]]：无服务器计算，无需管理底层基础设施
|
||||
- [[Hybrid-Cloud]]：混合云，公有云与私有云组合使用
|
||||
- [[Multi-Cloud]]：多云，使用多个云服务商的服务
|
||||
|
||||
## Key Entities
|
||||
- [[ISO-27001]]：信息安全管理系统国际标准
|
||||
- [[HIPAA]]：美国健康保险便携性和责任法案
|
||||
- [[GDPR]]：欧盟通用数据保护条例
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Adoption]] ← extends ← [[Cloud-Migration]]：云采纳包含迁移阶段
|
||||
- [[Cloud-Security]] ← depends_on ← [[ISO-27001]]：云安全认证依据
|
||||
- [[IaaS]] ← extends ← [[Cloud-Native]]：IaaS 是云原生的基础层
|
||||
- [[PaaS]] ← extends ← [[Cloud-Native]]：PaaS 是云原生的应用开发平台
|
||||
- [[SaaS]] ← extends ← [[Cloud-Native]]：SaaS 是云原生的软件交付模式
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
title: "The Picture They Paint of You"
|
||||
type: source
|
||||
tags: [ clippings, ai, product-framing ]
|
||||
date: 2026-04-13
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/The Picture They Paint of You.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：AI 产品命名与营销框架如何折射职业价值认知
|
||||
- 问题域：AI SRE 与编码助手在产品定位上的二元对立
|
||||
- 方法/机制：对比分析 14 家 AI SRE 产品和 8 家编码助手产品的命名与话语框架
|
||||
- 结论/价值：AI 工具的命名框架揭示了构建者对特定职业的社会认知，且这种认知会被放大并赋予合法性
|
||||
|
||||
## Key Claims
|
||||
- AI SRE 产品普遍以"替代者"框架营销，强调消除人工负担、去琐碎化
|
||||
- 编码助手产品普遍以"协作者"框架营销，强调增强工程师能力、赋予更多控制权
|
||||
- 产品命名差异反映了买卖双方对职业价值的社会认知分裂
|
||||
- 泰勒主义软件工厂框架正在取代原本的工程师-自动化伙伴关系
|
||||
- 类比既是杠杆，也是束缚；好的工具需要更准确的工作表征
|
||||
|
||||
## Key Quotes
|
||||
> "AI SRE 被宣传为确保无人被低效工作分散注意力的有效方法" — 产品营销话语
|
||||
> "编码助手被定位为增强工程师的能力，并被赋予了名字" — 产品定位差异
|
||||
> "类比既可以成为杠杆，也可能成为束缚" — 核心论点
|
||||
|
||||
## Key Concepts
|
||||
- [[AI工具命名框架]]：产品名称与营销话语对职业价值的折射
|
||||
- [[Taylorism]]：泰勒制，以效率为中心的科学管理方法，现被类比到软件工程自动化
|
||||
- [[剩余原则]]（The Left-over Principle）：角色部分自动化后，剩余工作堆积到更少的人身上
|
||||
- [[软件工厂]]（Software Factory）：高层控制器协调大量无面孔代理的模式
|
||||
|
||||
## Key Entities
|
||||
- [[Anthropic]]：Claude Code 持有"协作者"框架，强调"Built for builders"
|
||||
- [[AWS]]：DevOps Agent 定位为"全天候自主值班工程师"
|
||||
- [[Harness]]：AI SRE 强调"扩展响应能力，而非团队规模"
|
||||
- [[Ciroos]]：另一款以"帮助"SRE 团队为目标的产品，名称相对人性化
|
||||
- [[Cleric]]：少数有名字的 AI SRE 产品，名称源自DnD辅助职业
|
||||
- [[Cline]]：编码伙伴定位，"天生协作，获准自主运行"
|
||||
- [[GitHub Copilot]]：副驾驶命名体现协作角色，"Ship faster with AI that codes with you"
|
||||
- [[OpenAI Codex]]：定位为更明确的替代角色，"智能编码的指挥中心"
|
||||
|
||||
## Connections
|
||||
- [[Vibe Coding]] ← 影响 ← [[软件工厂]]框架（均强调高层控制）
|
||||
- [[AI产品经理]] ← 关联 ← [[AI工具命名框架]]（命名即认知投射）
|
||||
- [[超级个体]] ← 对立 ← [[Taylorism]]（前者强调人的价值，后者强调替代）
|
||||
- [[Claude-Code]] ← 协作者框架 → [[Cline]]（均为增强工具）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Vibe Coding]] 框架存在张力：
|
||||
- 冲突点：Vibe Coding 强调人机协作伙伴关系，而软件工厂框架强调替代与控制
|
||||
- 当前观点：Vibe Coding 认为开发者是导演，AI 是结对伙伴
|
||||
- 对方观点：Software Factory 认为人只需做高层控制者
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: These 6 Linux apps let you monitor system resources in style
|
||||
type: source
|
||||
tags: [linux, system-monitoring, TUI, GUI]
|
||||
date: 2025-12-16
|
||||
sources:
|
||||
- https://www.howtogeek.com/these-linux-apps-let-you-monitor-system-resources-in-style/
|
||||
author: shenwei
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/These 6 Linux apps let you monitor system resources in style.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：6 款 Linux 系统资源监控工具评测
|
||||
- 问题域：Linux 系统性能监控与进程管理
|
||||
- 方法/机制：TUI（文本用户界面）和 GUI 两类监控工具的功能对比
|
||||
- 结论/价值：作者首选 Btop++（TUI），Stacer（功能丰富），Mission Center（类 Task Manager）
|
||||
|
||||
## Key Claims
|
||||
- TUI 监控工具响应迅速，即使 GUI 卡顿也能正常运行
|
||||
- Btop++ 提供 CPU、活动、内存、存储、网络多面板视图，支持进程搜索、信号发送、优先级调整（Nice 值）
|
||||
- Htop 采用极简设计，以函数键操作为主（F3 搜索、F9 终止、F7/F8 调整优先级）
|
||||
- Glances 轻量快速，全键盘驱动，显示网络、CPU、内存、存储统计
|
||||
- Bottom 专注实时图形化展示 CPU、网络、内存，不支持交互式进程管理
|
||||
- Mission Center 为 GUI 应用，类 Windows Task Manager，包含性能、应用、服务三个标签页
|
||||
- Stacer 是功能最丰富的 GUI 监控工具，支持启动项管理、软件包卸载、APT 源配置、GNOME 设置调整、缓存清理
|
||||
|
||||
## Key Quotes
|
||||
> "TUI apps make the best resource monitors, in my opinion. They're snappy and responsive, even when the GUI is lagging." — 作者对 TUI 监控工具的偏好
|
||||
|
||||
## Key Concepts
|
||||
- [[TUI (Text User Interface)]]：基于终端文本界面的监控工具类型
|
||||
- [[System Resource Monitoring]]：监控 CPU、内存、网络、存储等系统资源的行为
|
||||
- [[Process Management]]：进程的搜索、终止、优先级调整等操作
|
||||
|
||||
## Key Entities
|
||||
- [[Btop++]]：作者的 TUI 监控首选工具
|
||||
- [[Htop]]：极简风格 TUI 进程监控器
|
||||
- [[Glances]]：轻量级全键盘驱动 TUI 监控器
|
||||
- [[Bottom]]：专注实时图形化的 TUI 监控器
|
||||
- [[Mission Center]]：类 Windows Task Manager 的 GUI 监控应用
|
||||
- [[Stacer]]：功能最丰富的 GUI 监控与管理工具
|
||||
- [[HowToGeek]]：文章来源
|
||||
|
||||
## Connections
|
||||
- [[Btop++]] ← 类比 → [[Htop]]
|
||||
- [[Btop++]] ← 类比 → [[Glances]]
|
||||
- [[Btop++]] ← 类比 → [[Bottom]]
|
||||
- [[Mission Center]] ← 类比 → [[Stacer]]
|
||||
- [[System Resource Monitoring]] ← 应用于 → [[Linux]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
title: "TikTok Shop - Apache Superset Dashboard设计思路"
|
||||
type: source
|
||||
tags: [tiktok-shop, superset, bi, dashboard, 电商分析]
|
||||
date: 2025-03-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/跨境电商/TikTok Shop - Apache Superset Dashboard设计思路.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：TikTok Shop 电商选品数据可视化分析系统设计
|
||||
- 问题域：如何将 TikTok Shop 爬取数据转化为可操作的选品决策支持系统
|
||||
- 方法/机制：Apache Superset + SQL Views + 多维度 Dashboard 设计
|
||||
- 结论/价值：4-Tab 专业选品 Dashboard，覆盖爆品发现、价格带分析、类目机会、店铺监控
|
||||
|
||||
## Key Claims
|
||||
- TikTok Shop 数据适合做 6 类分析：爆品发现、价格销量关系、类目机会、店铺监控、SKU 库存、评论分析
|
||||
- Superset 无法直接解析 JSON，必须通过 SQL View 预处理 JSON_EXTRACT 字段
|
||||
- 选品评分模型 = sold×0.4 + rating×12 + rating_count×0.2 + discount_percent×0.5
|
||||
- 气泡图（价格×销量×评分）可一眼识别"低价高销量"和"高客单价爆品"
|
||||
|
||||
## Key Concepts
|
||||
- [[电商选品分析]]：通过销量、评分、折扣多维度评分发现高潜力产品
|
||||
- [[Superset Dashboard]]：Apache Superset 可视化分析平台，支持导入 JSON Dashboard 配置
|
||||
- [[选品评分模型]]：加权评分公式自动排序推荐产品
|
||||
- [[KPI 卡片]]：关键业绩指标数字看板，支持快速筛选热卖/高评分/折扣产品
|
||||
- [[价格带分析]]：气泡图/直方图识别最优价格区间
|
||||
- [[类目机会分析]]：热力图+箱线图发现蓝海类目
|
||||
- [[店铺监控]]：竞争对手销量/评分/上新节奏/价格策略跟踪
|
||||
- [[JSON_EXTRACT]]：MySQL JSON 字段预处理，将 JSON 拆分为可计算列
|
||||
|
||||
## Key Entities
|
||||
- [[TikTok Shop]]：字节跳动旗下电商平台，数据来源
|
||||
- [[Apache Superset]]：开源 BI 可视化平台（Airbnb 出品），支持 SQL Dataset、Chart、Dashboard
|
||||
- [[TikTok Products]]：核心事实表（products），包含 sold/price/rating/category/store_name/timestamp 等字段
|
||||
- [[Product Reviews]]：辅助表，支持评分趋势和 NLP 评论分析
|
||||
|
||||
## Connections
|
||||
- [[TikTok Shop]] ← 数据源 ← [[电商选品分析]]
|
||||
- [[Apache Superset]] ← 可视化工具 ← [[Superset Dashboard]]
|
||||
- [[电商选品分析]] ← 支撑 ← [[选品评分模型]]
|
||||
- [[选品评分模型]] ← 使用 ← [[TikTok Products]]
|
||||
- [[店铺监控]] ← 依赖 ← [[TikTok Products]]
|
||||
- [[类目机会分析]] ← 依赖 ← [[JSON_EXTRACT]]
|
||||
|
||||
## SQL View
|
||||
|
||||
### view_products_cleaned
|
||||
```sql
|
||||
CREATE OR REPLACE VIEW view_products_cleaned AS
|
||||
SELECT
|
||||
id, source_id, title, store_name, category,
|
||||
final_price, initial_price, discount_percent,
|
||||
sold, position, timestamp,
|
||||
JSON_EXTRACT(prodct_rating, '$.rating') AS rating,
|
||||
JSON_EXTRACT(prodct_rating, '$.count') AS rating_count,
|
||||
(final_price * sold) AS total_gmv,
|
||||
(initial_price - final_price) AS discount_amount
|
||||
FROM products;
|
||||
```
|
||||
|
||||
## Dashboard 结构（4 Tab）
|
||||
|
||||
| Tab | 名称 | 核心图表 |
|
||||
|-----|------|---------|
|
||||
| 1 | 爆品雷达 | KPI卡片×6、Top10条形图、类目占比饼图、价格×销量气泡图、评分直方图 |
|
||||
| 2 | 类目机会洞察 | 类目销量榜、评分×销量热力图、价格箱线图 |
|
||||
| 3 | 店铺监控 | 店铺GMV/销量/评分排名、上新趋势面积图、价格策略对比 |
|
||||
| 4 | 评论分析 | 评分趋势折线图、评论数×销量散点图、好评/差评占比 |
|
||||
|
||||
## Contradictions
|
||||
- 与 [[可自动化可扩展AI增强的电商数据采集与处理系统]]：后者专注爬取+AI处理，本文档专注数据可视化层面，两者构成采集→分析完整管线
|
||||
|
||||
## Aliases
|
||||
- Superset = Apache Superset
|
||||
- TikTok Shop = TikTok电商
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
title: "Trae 远程开发部署指南"
|
||||
type: source
|
||||
tags: [trae, remote-ssh, ubuntu, docker, development]
|
||||
date: 2025-03-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Vibe Coding/Trae远程开发部署指南.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Trae AI 代码编辑器通过 Remote SSH 连接 Ubuntu 服务器进行远程 Docker 项目开发的完整配置指南
|
||||
- 问题域：本地机器算力/存储不足，需通过 Trae 远程连接 Ubuntu 服务器进行开发，同时管理多个 Docker 容器环境
|
||||
- 方法/机制：Remote SSH 插件 + Docker 插件 + 两种开发模式（Attach 容器 / 宿主机编辑），SSH Config 免密登录
|
||||
- 结论/价值：Trae 将 VS Code 远程开发能力与 Docker 容器管理结合，适合 Vibe Coding 场景下的远程服务器开发
|
||||
|
||||
## Key Claims
|
||||
- Ubuntu 2（192.168.3.45）为开发服务器（源码 + Bind Mount），Ubuntu 1（192.168.3.47）为生产服务器（仅镜像）
|
||||
- SSH Config HostName 可填写 Tailscale IP（如 100.x.x.x），实现内网/外网无缝切换
|
||||
- Trae Remote SSH 首次连接在服务器安装 VS Code Server 代理组件，耗时约几十秒
|
||||
- 模式 A（Attach 容器）：Docker 容器内运行 Trae Server，环境完全隔离，无需在宿主机安装语言环境
|
||||
- 模式 B（宿主机编辑 + Docker CLI）：直接编辑 Ubuntu 文件系统代码，在终端执行 docker compose 命令
|
||||
- Git 凭证问题：Trae/VS Code 自动转发本地 SSH Agent，需在本地启动 ssh-agent 并添加私钥
|
||||
- 文件权限（UID/GID）问题：容器内生成的文件归属 root，宿主机无法修改，需在 Dockerfile 中指定 user 或使用 --user 参数
|
||||
|
||||
## Key Concepts
|
||||
- [[Trae]]：基于 VS Code 的 AI 代码编辑器，原生支持 Remote SSH 和 Docker 插件
|
||||
- [[Remote SSH]]：通过 SSH 连接远程服务器，在服务器上运行编辑器后端
|
||||
- [[Docker Attach模式]]：直接"进入"已运行的 Docker 容器进行开发，环境完全隔离
|
||||
- [[Bind Mount]]：宿主机目录挂载到容器内，代码修改实时生效（开发模式 A 的核心）
|
||||
- [[SSH Agent转发]]：本地 SSH Agent 私钥通过 SSH 连接转发给远程服务器，供 Git 操作使用
|
||||
|
||||
## Key Entities
|
||||
- [[Ubuntu2]]：开发服务器，IP 192.168.3.45，安装 Trae Server，提供 /home/shenwei/docker/tiktok_pm 开发目录
|
||||
- [[Ubuntu1]]：生产服务器，IP 192.168.3.47，运行 tiktok_pm 容器（镜像打包模式）
|
||||
- [[Trae]]：AI 代码编辑器，支持 VS Code 插件生态
|
||||
|
||||
## Connections
|
||||
- [[Trae远程开发部署]] ← 开发环境 → [[Ubuntu2]]
|
||||
- [[Trae远程开发部署]] ← 生产部署 → [[Ubuntu1]]
|
||||
- [[Trae远程开发部署]] ← 开发模式 → [[Docker]]（容器化开发环境）
|
||||
- [[Trae远程开发部署]] ← 协作工具 → [[SSH Config]]（多主机别名管理）
|
||||
|
||||
## Contradictions
|
||||
|
||||
## Related Wiki Pages
|
||||
- [[Vibe Coding]]：Trae 是 Vibe Coding 推荐工具之一
|
||||
- [[Cursor]]：Cursor 是另一个 AI 代码编辑器，与 Trae 功能高度重叠
|
||||
- [[Ubuntu]]：Ubuntu 2 和 Ubuntu 1 是双服务器架构的核心
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: "Ubuntu 24.04 启用 SSH 服务"
|
||||
type: source
|
||||
tags: [ssh, ubuntu, server]
|
||||
date: 2025-03-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Ubuntu 24.04 enable SSH.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Ubuntu 24.04 启用 OpenSSH Server 的完整步骤
|
||||
- 问题域：Ubuntu 24.04 改变 SSH 服务激活机制（默认 socket activation），与传统方式不同
|
||||
- 方法/机制：安装 openssh-server → systemctl enable/start ssh → 配置 UFW 防火墙 → 远程连接验证
|
||||
- 结论/价值：Ubuntu 24.04 使用 ssh.socket 代替 ssh.service，管理员需注意新管理方式
|
||||
|
||||
## Key Claims
|
||||
- Ubuntu 24.04 默认使用 ssh.socket 激活机制：有连接进入时才启动 sshd，非传统常驻进程模式
|
||||
- 安装命令：`sudo apt update && sudo apt install openssh-server -y`
|
||||
- 启动并开机自启：`sudo systemctl start ssh && sudo systemctl enable ssh`
|
||||
- 检查 socket 状态：`sudo systemctl status ssh.socket`（监听状态显示 `ListenStream=22`）
|
||||
- 防火墙允许 SSH：`sudo ufw allow ssh` 或 `sudo ufw allow 22/tcp`
|
||||
- 验证服务状态：`sudo systemctl status ssh`，显示 `active (running)` 或 socket 模式 `ListenStream=22`
|
||||
- 切换回传统常驻模式：`sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service`
|
||||
- Ubuntu 24.04 修改监听端口推荐通过 `systemctl edit ssh.socket` 而非仅修改 `/etc/ssh/sshd_config`
|
||||
|
||||
## Key Quotes
|
||||
> "Ubuntu 24.04 引入了一个重要的变化：默认使用 `ssh.socket` 激活机制（即只有在连接请求进入时才启动 SSH 守护进程）" — 与旧版本最大差异
|
||||
|
||||
## Key Concepts
|
||||
- [[SSH Socket Activation]]：Ubuntu 24.04 默认机制，sshd 按需启动而非常驻，节省资源
|
||||
- [[UFW 防火墙规则]]：Ubuntu 默认防火墙，通过 `ufw allow ssh` 放行 22 端口
|
||||
- [[SSH 服务管理]]：`systemctl start/enable/disable` 管理 ssh.service 或 ssh.socket
|
||||
- [[OpenSSH Server]]：Ubuntu SSH 服务端实现，包名 `openssh-server`
|
||||
|
||||
## Key Entities
|
||||
- [[Ubuntu 24.04]]：2024 年 4 月发布的 LTS 版本，SSH 管理机制变化
|
||||
- [[OpenSSH]]：开源 SSH 协议实现，Ubuntu 默认 SSH 服务端
|
||||
|
||||
## Connections
|
||||
- [[SSH Socket Activation]] ← default_in ← [[Ubuntu 24.04]]
|
||||
- [[OpenSSH Server]] ← installed_by ← [[apt install openssh-server]]
|
||||
- [[UFW 防火墙规则]] ← must_configure ← [[SSH 服务管理]]
|
||||
|
||||
## Contradictions
|
||||
- 旧版 Ubuntu（< 24.04）管理方式：通过 `/etc/ssh/sshd_config` 修改端口后 `systemctl restart sshd`；24.04 推荐 `systemctl edit ssh.socket`
|
||||
|
||||
## Metadata
|
||||
- 作者：shenwei
|
||||
- 创建时间：2025-03-16
|
||||
- 原始标签：[ssh, ubuntu]
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: "Ubuntu Server 科学上网配置指南"
|
||||
type: source
|
||||
tags: [Ubuntu, 科学上网, V2Ray, ProxyChains, Docker, 代理]
|
||||
date: 2025-12-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Ubuntu Server科学上网.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Ubuntu Server 环境下配置科学上网的完整方案
|
||||
- 问题域：终端命令/Git/Docker 守护进程/容器内应用如何走代理
|
||||
- 方法/机制：分层代理架构——ProxyChains（临时命令）、Git 全局配置（Git 专设）、systemd Docker 代理（镜像拉取）、~/.docker/config.json（容器内应用）
|
||||
- 结论/价值：不同场景用不同方案，不可混用；Daemon 层面走 systemd，用户层面走环境变量
|
||||
|
||||
## Key Claims
|
||||
|
||||
### ProxyChains（终端命令级）
|
||||
- 修改 `/etc/proxychains4.conf` 添加 `socks5 127.0.0.1 10808`
|
||||
- 任何命令前加 `proxychains4` 前缀即可穿代理：`proxychains4 curl https://google.com`
|
||||
|
||||
### Git 代理配置
|
||||
- 设置全局：`git config --global http.proxy 'socks5://127.0.0.1:10808'`
|
||||
- Docker 守护进程不走用户环境变量，必须通过 systemd 配置
|
||||
|
||||
### Docker Pull 代理（Daemon 级）
|
||||
- 创建 `/etc/systemd/system/docker.service.d/http-proxy.conf`
|
||||
- 添加 `HTTP_PROXY/HTTPS_PROXY/NO_PROXY` 环境变量
|
||||
- 必须执行 `systemctl daemon-reload && systemctl restart docker`
|
||||
- 验证：`docker info | grep -i proxy`
|
||||
|
||||
### Docker 容器内代理（应用级）
|
||||
- 方案 A（推荐 17.07+）：`~/.docker/config.json` 添加 `proxies.default`
|
||||
- 方案 B：docker-compose.yml 环境变量 `ALL_PROXY=socks5://172.24.0.1:10808`
|
||||
- 容器内获取宿主机 IP：`docker exec <container> ip route | awk '/default/ {print $3}'`
|
||||
|
||||
## Key Concepts
|
||||
- [[ProxyChains]]：终端命令强制走 SOCKS5 代理工具
|
||||
- [[SOCKS5 代理]]：支持本地 DNS 解析（socks5h://）的代理协议
|
||||
- [[Docker Daemon 代理]]：Docker 守护进程级代理配置，通过 systemd 环境变量注入
|
||||
- [[Docker 容器内代理]]：容器应用级代理，通过 ~/.docker/config.json 或 docker-compose environment
|
||||
|
||||
## Key Entities
|
||||
- [[V2RayN]]：SOCKS5/HTTP 代理客户端（运行在宿主机）
|
||||
- [[Ubuntu Server]]：Linux 服务器操作系统
|
||||
|
||||
## Connections
|
||||
- [[V2RayN]] ← 提供代理 ← [[SOCKS5 代理]]
|
||||
- [[ProxyChains]] ← 转发至 ← [[SOCKS5 代理]]
|
||||
- [[Docker Daemon 代理]] ← 配置 ← [[Ubuntu Server]]
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
title: "Ubuntu服务器通过rsync实现日常增量备份"
|
||||
type: source
|
||||
tags: [ubuntu, rsync, backup, nas, nfs, fstab]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Ubuntu服务器通过rsync实现日常增量备份.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Ubuntu 服务器通过 rsync 实现对 NAS 的每日增量备份自动化
|
||||
- 问题域：已有机房镜像备份（Clonezilla），需补充实时增量数据保护方案
|
||||
- 方法/机制：rsync -azR --delete 差异同步，lockfile 防重入，crontab 凌晨自动执行，/etc/fstab 实现 NFS 永久挂载
|
||||
- 结论/价值：构建"时间点恢复"能力，NAS 掉线时自动中止备份防止本地硬盘爆满
|
||||
|
||||
## Key Claims
|
||||
- rsync 在备份正在写入的二进制文件（如 MySQL）时可能导致恢复后无法启动，应先用 mysqldump 导出 SQL 再同步
|
||||
- rsync 返回码 23/24 在备份运行中系统时属于正常（部分文件权限问题或源文件消失），重点检查数据是否大部分已同步
|
||||
- /etc/fstab 中 _netdev 参数确保网络设备就绪后再执行挂载，防止开机因网络未就绪而挂载失败
|
||||
- lockfile 机制防止 rsync_backup.sh 重入，脚本开头检查 lockfile 存在则跳过本次执行
|
||||
|
||||
## Key Quotes
|
||||
> "rsync -azR --delete — -a 归档模式保留权限属性，-z 压缩传输，-R 相对路径，--delete 删除目标端多余文件" — rsync 核心参数解析
|
||||
> "0 3 * * * /usr/local/bin/rsync_backup.sh — 每天凌晨 3 点业务低峰期执行备份" — Crontab 时间配置
|
||||
> "192.168.3.17:/volume2/backup /mnt/nas_backup nfs defaults,timeo=900,retrans=5,_netdev 0 0" — NFS /etc/fstab 永久挂载条目
|
||||
> "timeo=900（90秒超时），retrans=5（重连5次），_netdev（等待网络就绪）" — NFS 挂载参数详解
|
||||
|
||||
## Key Concepts
|
||||
- [[rsync]]：远程增量同步工具，通过 Delta-transfer 算法只传输变化部分
|
||||
- [[增量备份]]：仅备份自上次备份以来变化的文件，相比全量备份节省存储和带宽
|
||||
- [[NFS永久挂载]]：通过 /etc/fstab 将 NFS 挂载配置为系统启动时自动执行
|
||||
- [[lockfile]]：防止脚本重入的简单机制，PID 文件 + kill -0 检测进程存活
|
||||
- [[Crontab]]：Linux 定时任务调度器，支持分钟级精确控制
|
||||
- [[Clonezilla]]：磁盘镜像备份工具，与 rsync 形成"整机镜像 + 增量数据"二级保护
|
||||
- [[mysqldump]]：MySQL/MariaDB 逻辑备份工具，在 rsync 之前先导出 SQL 文件保证数据库一致性
|
||||
|
||||
## Key Entities
|
||||
- [[Synology NAS]]：备份目标端（192.168.3.17:/volume2/backup）
|
||||
- [[Ubuntu服务器]]：备份源端，运行 rsync_backup.sh
|
||||
- [[Docker]]：数据来源之一（/var/lib/docker/volumes/、/etc/docker/、/home/shenwei/Docker/）
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu服务器通过rsync实现日常增量备份]] → backups_to → [[Synology NAS]]
|
||||
- [[Ubuntu服务器通过rsync实现日常增量备份]] ← runs_on ← [[Ubuntu服务器]]
|
||||
- [[Docker]] ← source_data ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
|
||||
## 备份策略矩阵
|
||||
|
||||
| 备份类型 | 工具 | 频率 | 覆盖范围 | 恢复时间 |
|
||||
|---------|------|------|---------|---------|
|
||||
| 整机镜像 | Clonezilla | 按需/周 | 全盘扇区级 | 长（全盘还原） |
|
||||
| 增量数据 | rsync | 每日凌晨3点 | 变化文件 | 短（选择性还原） |
|
||||
|
||||
## 关键脚本：rsync_backup.sh 防重入逻辑
|
||||
```bash
|
||||
LOCKFILE="/tmp/rsync_backup.lock"
|
||||
if [ -e ${LOCKFILE} ] && kill -0 `cat ${LOCKFILE}`; then
|
||||
echo "备份任务已在运行中，跳过本次执行。"
|
||||
exit
|
||||
fi
|
||||
echo $$ > ${LOCKFILE}
|
||||
trap "rm -f ${LOCKFILE}" EXIT
|
||||
```
|
||||
|
||||
## NFS 永久挂载验证流程
|
||||
```bash
|
||||
# 1. 卸载当前挂载
|
||||
sudo umount /mnt/nas_backup
|
||||
# 2. 模拟开机自动挂载
|
||||
sudo mount -a
|
||||
# 3. 验证挂载成功
|
||||
df -h | grep nas_backup
|
||||
```
|
||||
|
||||
## Contradictions
|
||||
|
||||
## 常见问题排查
|
||||
| 问题 | 原因 | 解决方案 |
|
||||
|------|------|---------|
|
||||
| 重启后挂载失效 | nfs-common 启动慢于 mount -a | systemctl enable remote-fs.target |
|
||||
| rsync 返回码 20 | 进程被手动中断（SIGINT/SIGTERM） | 使用 nohup 或 screen 后台运行 |
|
||||
| 备份写满本地硬盘 | NAS 掉线时挂载点变成普通目录 | 脚本开头加 mountpoint -q 检查 |
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
title: "Useful Prompt Lib"
|
||||
type: source
|
||||
tags: [prompt-library, claude, resources]
|
||||
date: 2025-03-06
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/Useful Prompt Lib.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：Anthropic Claude Prompt 库资源汇总
|
||||
- 问题域：用户需要预设提示词模板以快速调用特定 AI 能力
|
||||
- 方法/机制：整理 60+ 按功能分类的提示词模板，覆盖代码、数据分析、内容创作等多个领域
|
||||
- 结论/价值：为开发者提供开箱即用的提示词资源库，降低重复创建成本
|
||||
|
||||
## Key Claims
|
||||
- Babel's broadcasts 适合 TikTok 多语言本地化改写
|
||||
- Review classifier 可自动化处理店铺/广告评论分类
|
||||
- Data organizer 能将非结构化信息快速转为 JSON 对接自动化工作流
|
||||
|
||||
## Key Concepts
|
||||
- [[Prompt库]]：按功能分类的预设提示词模板集合
|
||||
- [[JSON转换]]：将非结构化文本转换为结构化 JSON 格式
|
||||
|
||||
## Key Entities
|
||||
- [[Anthropic]]：Prompt 库发布方，提供 60+ 预设模板
|
||||
|
||||
## Connections
|
||||
- [[Prompt工程]] ← 包含 ← Useful Prompt Lib 提供实践模板
|
||||
- [[AI工作流自动生成]] ← 依赖 ← Data organizer 等提示词实现数据转换
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南"
|
||||
type: source
|
||||
tags: [ubuntu, vibe-coding, vibe-kanban, opencode, pm2, node, nvm]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Vibe Coding/Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：在 Ubuntu Server 上以非 root 用户（shenwei）安装 Node 20、Vibe-Kanban 与 OpenCode，并通过 pm2 管理进程
|
||||
- 问题域：权限冲突、端口占用、executor 启动失败、I/O error
|
||||
- 方法/机制：nvm 管理 Node 版本 → npm 全局安装 vibe-kanban + opencode → pm2 管理进程 → RUST_LOG=debug 调试
|
||||
- 结论/价值：不要用 root 启动；vibe-kanban 自动 spawn executor；pm2 只管理 vibe-kanban，executor 随进程管理
|
||||
|
||||
## Key Claims
|
||||
- nvm 管理 Node 版本（v0.39.7），安装 Node 20，nvm alias default 20
|
||||
- 不要用 root 启动 OpenCode serve，vibe-kanban 会自动 spawn executor
|
||||
- RUST_LOG=debug HOST=0.0.0.0 PORT=9999 npx vibe-kanban 启动，executor 在随机端口
|
||||
- pm2 start "RUST_LOG=debug HOST=0.0.0.0 PORT=9999 npx vibe-kanban" --name vibe-kanban
|
||||
- pm2 startup systemd -u shenwei --hp /home/shenwei 生成启动脚本
|
||||
- I/O error 通常是 executor 没启动或端口被占用
|
||||
- 清理旧工作树：rm -rf /var/tmp/vibe-kanban/worktrees/* 和 ~/.vibe-kanban
|
||||
|
||||
## Key Quotes
|
||||
> "不要用 root 启动 OpenCode serve，vibe-kanban 会自动 spawn executor" — 操作规范
|
||||
> "pm2 只管理 vibe-kanban，executor 随进程一起管理" — 进程管理原则
|
||||
|
||||
## Key Concepts
|
||||
- [[nvm]]：Node Version Manager，通过 curl -fsSL 安装，管理多个 Node 版本
|
||||
- [[pm2]]：进程管理器，pm2 start/pm2 logs/pm2 save/pm2 startup systemd
|
||||
- [[Vibe-Kanban]]：AI 结对编程任务看板，Web UI（PORT 9999）+ executor 随机端口
|
||||
- [[OpenCode Executor]]：vibe-kanban spawn 的 AI 编程执行器，随机端口运行
|
||||
|
||||
## Key Entities
|
||||
- [[shenwei]]：Ubuntu 服务器非 root 用户，Vibe-Kanban + OpenCode 安装操作者
|
||||
|
||||
## Connections
|
||||
- [[nvm]] ← 安装工具 ← [[Node 20]]
|
||||
- [[Vibe-Kanban]] ← spawns ← [[OpenCode Executor]]
|
||||
- [[pm2]] ← 管理 ← [[Vibe-Kanban]]
|
||||
56
wiki/sources/What-I-know-about-Cloud-Service-Delivery-1.md
Normal file
56
wiki/sources/What-I-know-about-Cloud-Service-Delivery-1.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "What I know about Cloud Service Delivery 1"
|
||||
type: source
|
||||
tags: [Cloud, DevOps, Cloud Service Delivery]
|
||||
date: 2026-04-16
|
||||
source_file: raw/Cloud & DevOps/What I know about Cloud Service Delivery 1.md
|
||||
---
|
||||
|
||||
## Summary
|
||||
Cloud Service Delivery（云服务交付）是连接云技术能力与用户实际消费服务之间的桥梁，涵盖整个生命周期。文章详细介绍了云服务交付团队的组成角色以及12个核心管理领域，包括服务配置与部署、基础设施管理、平台管理、应用运维、安全合规、性能监控、事件管理、变更配置管理、成本管理、客户支持、服务治理以及备份恢复与灾难管理。
|
||||
|
||||
## Key Claims
|
||||
- Cloud Service Delivery 是 IaaS、PaaS、SaaS 与最终用户实际消费服务之间的桥梁
|
||||
- 云服务交付团队需要包含：Cloud Infrastructure Engineer、Cloud Operation Engineer (DevOps/SRE)、Cloud Security Specialists、Cloud Support Engineer、Cloud FinOps Engineer
|
||||
- 完整的云服务交付需要12个核心管理领域的协同工作
|
||||
|
||||
## Key Quotes
|
||||
> "Cloud Service Delivery encompasses the entire lifecycle of making cloud services operational, available, secure, performant, and valuable to end-users and customers." — 核心定义
|
||||
|
||||
## Key Concepts
|
||||
- [[IaaS]]：基础设施即服务，提供虚拟计算资源
|
||||
- [[PaaS]]：平台即服务，提供应用开发和部署平台
|
||||
- [[SaaS]]：软件即服务，以订阅方式提供软件应用
|
||||
- [[SLA]]：Service Level Agreement，服务级别协议
|
||||
- [[SLO]]：Service Level Objective，服务级别目标
|
||||
- [[IaC]]：Infrastructure as Code，通过代码实现一致性、版本控制的基础设施管理
|
||||
- [[AIOps]]：利用人工智能进行运维自动化的方法
|
||||
|
||||
## Key Entities
|
||||
- AWS CloudWatch：AWS 监控服务，文中作为 Grafana 数据源示例
|
||||
- Grafana：开源监控和可观测性平台
|
||||
- New Relic：应用性能监控（APM）工具
|
||||
- WAF：Web Application Firewall，Web应用防火墙
|
||||
|
||||
## Connections
|
||||
- [[DevOps]] ← 相关 ← Cloud Service Delivery（DevOps 是云服务交付的重要方法论）
|
||||
- [[Cloud Native]] ← 相关 ← Cloud Service Delivery（云原生是云服务交付的目标状态）
|
||||
- [[Cloud Maturity Model]] ← 相关 ← Cloud Service Delivery（成熟度模型评估云服务交付能力）
|
||||
- [[DevSecOps]] ← 相关 ← Security & Compliance Management（安全是云服务交付的核心领域）
|
||||
|
||||
## Contradictions
|
||||
- （暂无）
|
||||
|
||||
## 12 Core Management Areas（核心管理领域）
|
||||
1. **Service Provisioning & Deployment**：服务配置与部署
|
||||
2. **Infrastructure Management**：基础设施管理
|
||||
3. **Platform Management (for PaaS)**：平台管理
|
||||
4. **Application Operations & Management**：应用运维管理
|
||||
5. **Security & Compliance Management**：安全与合规管理
|
||||
6. **Performance & Availability Monitoring**：性能与可用性监控
|
||||
7. **Incident & Problem Management**：事件与问题管理
|
||||
8. **Change & Configuration Management**：变更与配置管理
|
||||
9. **Cost Management & Optimization**：成本管理与优化
|
||||
10. **Customer Onboarding & Support**：客户支持与 onboarding
|
||||
11. **Service Governance & Lifecycle Management**：服务治理与生命周期管理
|
||||
12. **Backup, Recovery & Disaster Management**：备份恢复与灾难管理
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: "arXiv Paper Reader"
|
||||
type: source
|
||||
tags: [agent-use-case, research, arxiv, llm]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/arXiv-Paper-Reader.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：OpenClaw Agent 论文阅读助手工作流
|
||||
- 问题域：arXiv PDF 阅读痛点——下载 PDF、切换丢失上下文、LaTeX 符号难解析
|
||||
- 方法/机制：Prismer arxiv-reader skill（3 工具）+ LaTeX 源码自动展平 + 多篇对比表格 + 本地缓存
|
||||
- 结论/价值：对话式论文阅读，无需离开工作区，支持按 ID 获取、结构扫描、摘要批量 triage、深度问答
|
||||
|
||||
## Key Claims
|
||||
- arxiv-reader skill 运行于 OpenClaw，无 Docker/Python 依赖，直接通过 Node.js 内置模块实现
|
||||
- LaTeX 源码自动解压并展平，消除 PDF 阅读器的上下文跳跃问题
|
||||
- 多篇论文可批量获取摘要并生成对比表格，辅助 reading list 优先级排序
|
||||
- 结果本地缓存，二次访问即时返回
|
||||
|
||||
## Key Quotes
|
||||
> "Reading arXiv papers means downloading PDFs, losing context when switching between papers, and struggling to parse dense LaTeX notation. You want to read, analyze, and compare papers conversationally without leaving your workspace."
|
||||
|
||||
## Key Concepts
|
||||
- [[LaTeX Flattening]]：自动合并 LaTeX \include 子文件生成可读连续文档
|
||||
- [[arxiv-reader skill]]：Prismer AI 开发的 OpenClaw skill，3 工具接口（arxiv_fetch/arxiv_sections/arxiv_abstract）
|
||||
|
||||
## Key Entities
|
||||
- [[Prismer AI]]：arxiv-reader skill 开发方，GitHub 仓库 Prismer-AI/Prismer
|
||||
- [[arXiv]]：康奈尔大学运营的开放获取论文预印本平台
|
||||
|
||||
## Connections
|
||||
- [[Prismer AI]] ← provides ← [[arxiv-reader skill]]
|
||||
- [[arxiv-reader skill]] ← enables ← [[LaTeX Flattening]]
|
||||
- [[arXiv Paper Reader]] ← extends ← [[arxiv-reader skill]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "baoyu-skills Claude Code 技能集"
|
||||
type: source
|
||||
tags: [claude-code, skills, baoyu, openclaw, 内容生成, AI图像]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Skills/baoyu-skills-claude-code-技能集.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：宝玉（JimLiu）发布的 Claude Code 技能集，通过 ClawHub 协议按单个 skill 安装
|
||||
- 问题域：内容创作者和开发者需要多平台内容发布、多服务商图像生成、日常效率工具
|
||||
- 方法/机制：技能分内容技能（内容发布）、AI生成技能（图像/文本）、工具技能（处理工具）三大类；ClawHub 按单个 skill 安装（clawhub install baoyu-imagine）
|
||||
- 结论/价值：覆盖小红书/X/微信/微博全平台，9家图像服务商自动选择，翻译/抓取/压缩等日常工具
|
||||
|
||||
## Key Claims
|
||||
- ClawHub 按单个 skill 安装，不是 marketplace 批量装（clawhub install baoyu-imagine）
|
||||
- baoyu-imagine 支持 9 家服务商（OpenAI/Google/Azure/OpenRouter/DashScope/MiniMax/即梦/豆包/Replicate），自动选择最优
|
||||
- baoyu-translate 三模式（快速/标准/精翻）覆盖从短文本到出版级文档
|
||||
- baoyu-comic 5种画风 × 8种基调，漫画生成支持预设（ohmsha/wuxia/shoujo）
|
||||
- baoyu-post-to-wechat 支持 API 方式和浏览器方式发布公众号文章
|
||||
- EXTEND.md 支持用户级/项目级自定义，覆盖样式/配置/个人预设
|
||||
|
||||
## Key Quotes
|
||||
> "ClawHub 按单个 skill 安装，不是把整个 marketplace 一次性装进去" — 宝玉
|
||||
> "最好的 Skill 是工具箱，而非写好的提示词" — Anthropic
|
||||
> "精翻模式完成后，可回复「继续润色」或「refine」继续审校润色步骤" — baoyu-translate
|
||||
|
||||
## Key Concepts
|
||||
- [[内容技能]]：内容生成与发布类技能子集，baoyu-xhs-images/infographic/cover-image/slide-deck/comic/article-illustrator
|
||||
- [[baoyu-imagine]]：9家服务商自动选择的AI图像生成，支持文生图/参考图/自定义尺寸/批量生成
|
||||
- [[baoyu-infographic]]：20种布局×17种视觉风格的专业信息图生成
|
||||
- [[baoyu-xhs-images]]：小红书信息图，9种风格×6种布局的二维系统
|
||||
- [[baoyu-translate]]：三模式翻译（快速/标准/精翻），支持受众预设和风格预设
|
||||
- [[baoyu-comic]]：知识漫画创作，5种画风×8种基调，支持预设（ohmsha/wuxia/shoujo）
|
||||
- [[工具技能]]：baoyu-youtube-transcript/url-to-markdown/x-to-markdown/compress-image/format-markdown/markdown-to-html/translate
|
||||
|
||||
## Key Entities
|
||||
- [[宝玉]]（JimLiu）：baoyu-skills 项目作者，Claude Code 技能集开发者
|
||||
- [[JimLiu]]：GitHub 账号，baoyu-skills 仓库维护方
|
||||
- [[ClawHub]]：按单个 skill 安装的插件市场协议
|
||||
|
||||
## Connections
|
||||
- [[宝玉]] ← 发布 ← [[baoyu-skills]]
|
||||
- [[baoyu-imagine]] ← 依赖 ← [[ClawHub]]
|
||||
- [[baoyu-xhs-images]] ← 属于 ← [[内容技能]]
|
||||
- [[baoyu-translate]] ← 属于 ← [[工具技能]]
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user