feat(wiki): ingest Cloud DevOps and Home Office sources batch
This commit is contained in:
48
wiki/concepts/AgentSkill设计模式.md
Normal file
48
wiki/concepts/AgentSkill设计模式.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
id: agent-skill-design-pattern
|
||||
title: "AgentSkill设计模式"
|
||||
type: concept
|
||||
tags: [Agent, Skill, 设计模式]
|
||||
sources: [Google-5个Agent-Skill设计模式.md]
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
# AgentSkill设计模式
|
||||
|
||||
将领域知识或工作流有效封装进Skill的五种设计模式，Google与Anthropic经验总结。
|
||||
|
||||
## 五种模式
|
||||
|
||||
| 模式 | 核心机制 | 适用场景 |
|
||||
|------|----------|----------|
|
||||
| [[ToolWrapper]] | 按需动态加载知识文档 | 编码规范、框架最佳实践 |
|
||||
| [[Generator]] | 模板+变量填充生成一致输出 | API文档、报告生成 |
|
||||
| [[Reviewer]] | 检查标准与执行逻辑分离 | 代码审查、安全审计 |
|
||||
| [[Inversion]] | 先问再做，延迟执行 | 需求分析、项目规划 |
|
||||
| [[Pipeline]] | 硬性检查点强制顺序执行 | 复杂流水线、质量控制 |
|
||||
|
||||
## 核心问题
|
||||
|
||||
SKILL.md格式标准化后（已被30+主流工具支持），同等格式的skill执行效果天差地别。差距在于**内容设计**，而非格式。
|
||||
|
||||
## 模式组合
|
||||
|
||||
五种模式并非互斥，可以组合使用：
|
||||
- Pipeline末尾可加Reviewer进行double-check
|
||||
- Generator开始可用Inversion收集必要变量
|
||||
- Reviewer可嵌入Pipeline作为质量关卡
|
||||
|
||||
## 理论基础
|
||||
|
||||
- [[Anthropic]]经验：最好的Skill是「工具箱」，不是大prompt；三条铁律：只写Agent不知道的、重点写踩坑清单、给工具不给指令
|
||||
- [[Google]]ADK：SkillToolset和渐进式披露机制，agent只在运行时需要时才消耗上下文token加载特定模式
|
||||
|
||||
## 与AgenticAI关系
|
||||
|
||||
[[AgenticAI]]的发展使得Skill设计从"写好提示词"转向"设计好工作流结构"。五种模式将[[AgenticAI]]的能力通过结构化Skill封装为可复用模块。
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[AgentSkill]]：Skill的实例化
|
||||
- [[AgenticAI]]：Agent具备自主行动能力
|
||||
- [[工作流自动化]]：Pipeline模式的技术基础
|
||||
48
wiki/concepts/Generator.md
Normal file
48
wiki/concepts/Generator.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
id: generator
|
||||
title: "Generator"
|
||||
type: concept
|
||||
tags: [Agent, Skill, 设计模式]
|
||||
sources: []
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
# Generator
|
||||
|
||||
通过模板和变量填充流程，从用户需求生成结构化、一致性输出的Skill设计模式。
|
||||
|
||||
## 定义
|
||||
|
||||
Generator模式利用预定义的输出模板和样式指南，由Agent扮演项目经理角色，通过"收集缺失变量→填充模板→输出结果"的流程，保证每次运行生成格式完全一致的文档或代码。
|
||||
|
||||
## 机制
|
||||
|
||||
- assets/目录存放输出模板
|
||||
- references/目录存放样式指南
|
||||
- SKILL.md作为协调器，指导Agent加载模板、读取指南、收集变量、填充内容
|
||||
- 变量未齐全时，Agent主动向用户询问
|
||||
|
||||
## 适用场景
|
||||
|
||||
- 统一API文档生成
|
||||
- 标准化commit信息格式
|
||||
- 项目脚手架初始化
|
||||
- 报告/简报批量生成
|
||||
|
||||
## 优点
|
||||
|
||||
- 输出格式完全一致可预期
|
||||
- 模板与内容分离，便于更新样式
|
||||
- 变量收集机制确保信息完整
|
||||
|
||||
## 缺点
|
||||
|
||||
- 模板维护成本较高
|
||||
- 变量收集可能增加交互轮次
|
||||
- 不适合高度创造性任务
|
||||
|
||||
## 关系
|
||||
|
||||
- 上位概念：[[AgentSkill设计模式]]
|
||||
- 可组合：[[Inversion]]（用Inversion收集变量）
|
||||
- 可组合：[[Reviewer]]（用Reviewer检查输出）
|
||||
47
wiki/concepts/Inversion.md
Normal file
47
wiki/concepts/Inversion.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
id: inversion
|
||||
title: "Inversion"
|
||||
type: concept
|
||||
tags: [Agent, Skill, 设计模式]
|
||||
sources: []
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
# Inversion
|
||||
|
||||
将Agent工作流从"先做后问"反转为"先问再做"的Skill设计模式。Agent变为面试官，通过阶段性提问收集必要信息后才会开始执行。
|
||||
|
||||
## 定义
|
||||
|
||||
Inversion模式通过硬性门控指令（gate）控制工作流：明确规定"不到所有阶段完成就不开始构建"。Agent逐阶段提问，等待用户回答，确认后才进入下一阶段，最终才执行核心任务。
|
||||
|
||||
## 机制
|
||||
|
||||
- 硬性门控指令：不到所有阶段完成就不开始构建
|
||||
- 阶段化提问：Agent按阶段逐一提问
|
||||
- 等待确认：每个阶段需用户明确回答后才进入下一阶段
|
||||
- 延迟执行：收集完所有必要信息后才执行实际操作
|
||||
|
||||
## 适用场景
|
||||
|
||||
- 项目规划（收集需求、约束、优先级）
|
||||
- 需求分析（功能范围、技术栈、时间线）
|
||||
- 决策咨询（收集选项、偏好、限制条件）
|
||||
- 内容创作（主题、受众、风格偏好）
|
||||
|
||||
## 优点
|
||||
|
||||
- 确保执行前信息完整
|
||||
- 用户参与度高，减少返工
|
||||
- 避免Agent盲目猜测导致浪费
|
||||
|
||||
## 缺点
|
||||
|
||||
- 初始交互轮次多，用户可能不耐烦
|
||||
- 问题设计需要精心规划
|
||||
- 不适合紧急/简单任务
|
||||
|
||||
## 关系
|
||||
|
||||
- 上位概念：[[AgentSkill设计模式]]
|
||||
- 可组合：[[Generator]]（用Inversion收集Generator所需的变量）
|
||||
61
wiki/concepts/Pipeline.md
Normal file
61
wiki/concepts/Pipeline.md
Normal file
@@ -0,0 +1,61 @@
|
||||
---
|
||||
id: pipeline
|
||||
title: "Pipeline"
|
||||
type: concept
|
||||
tags: [Agent, Skill, 设计模式]
|
||||
sources: []
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
# Pipeline
|
||||
|
||||
在复杂任务中设置硬性检查点，强制Agent按严格顺序执行工作流的Skill设计模式。
|
||||
|
||||
## 定义
|
||||
|
||||
Pipeline模式通过实现明确的门控条件，确保Agent无法跳过步骤或忽略指令。每个关键节点设置检查点，用户必须在进入下一步之前确认，否则流程不会继续。
|
||||
|
||||
## 机制
|
||||
|
||||
- 工作流步骤明确定义在SKILL.md中
|
||||
- 每步有明确的进入前置条件
|
||||
- 门控条件未满足时阻止进入下一步
|
||||
- 文档流水线示例：解析清点→生成文档字符串→组装文档→质量检查
|
||||
|
||||
## 适用场景
|
||||
|
||||
- 复杂多步骤任务（文档生成流水线）
|
||||
- 需要严格质量控制的流程
|
||||
- 合规/审计要求不能跳过的步骤
|
||||
- 多人协作中需要明确交接点
|
||||
|
||||
## 优点
|
||||
|
||||
- 步骤不会被跳过
|
||||
- 质量控制点明确
|
||||
- 流程可追溯可审计
|
||||
- 减少因跳过步骤导致的错误
|
||||
|
||||
## 缺点
|
||||
|
||||
- 灵活性低，急救场景不适用
|
||||
- 用户可能觉得检查点过多
|
||||
- 流程僵化，难以适应特殊情况
|
||||
|
||||
## 与Inversion对比
|
||||
|
||||
| 维度 | Pipeline | Inversion |
|
||||
|------|----------|-----------|
|
||||
| 方向 | 强制顺序执行 | 先问再做 |
|
||||
| 控制点 | 技术门控（条件判断） | 问答门控（收集信息） |
|
||||
| 适用场景 | 复杂技术流程 | 需求分析决策 |
|
||||
|
||||
## 关系
|
||||
|
||||
- 上位概念：[[AgentSkill设计模式]]
|
||||
- 可组合：[[Reviewer]]（Pipeline末尾加Reviewer步骤）
|
||||
- 示例应用：[[文档流水线]]
|
||||
|
||||
## 相关实体
|
||||
|
||||
- [[Google]]：发布Pipeline模式的云服务提供商
|
||||
52
wiki/concepts/Reviewer.md
Normal file
52
wiki/concepts/Reviewer.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
id: reviewer
|
||||
title: "Reviewer"
|
||||
type: concept
|
||||
tags: [Agent, Skill, 设计模式]
|
||||
sources: []
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
# Reviewer
|
||||
|
||||
将"检查什么"（审查标准）与"怎么检查"（执行逻辑）完全分离的Skill设计模式。
|
||||
|
||||
## 定义
|
||||
|
||||
Reviewer模式将审查规则与执行机制解耦：审查标准存放于references/review-checklist.md，可替换为Python风格检查、安全审计、数据质量检查等；执行逻辑保持静态，Agent动态加载对应审查标准并输出结构化结果。
|
||||
|
||||
## 机制
|
||||
|
||||
- references/目录存放可替换的审查清单
|
||||
- SKILL.md定义静态审查指令
|
||||
- Agent动态加载特定审查标准
|
||||
- 输出按严重程度分组的结构化结果
|
||||
|
||||
## 适用场景
|
||||
|
||||
- 代码审查（Python风格、PEP8等）
|
||||
- 安全审计（OWASP Top 10等）
|
||||
- 文档质量检查
|
||||
- 数据质量验证
|
||||
|
||||
## 优点
|
||||
|
||||
- 一套skill基础设施，换清单即换专项
|
||||
- 审查标准独立维护，便于更新
|
||||
- 结构化输出便于后续处理
|
||||
|
||||
## 缺点
|
||||
|
||||
- 清单设计需要领域专业知识
|
||||
- 多标准并存时可能冲突
|
||||
- 动态加载机制增加复杂度
|
||||
|
||||
## 关系
|
||||
|
||||
- 上位概念：[[AgentSkill设计模式]]
|
||||
- 可组合：[[Pipeline]]（Pipeline末尾加Reviewer double-check）
|
||||
- 审查清单类型：[[代码审查]]、[[安全审计]]
|
||||
|
||||
## 相关实体
|
||||
|
||||
- [[Anthropic]]：Reviewer模式被用于Claude Code代码审查Skill
|
||||
47
wiki/concepts/ToolWrapper.md
Normal file
47
wiki/concepts/ToolWrapper.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
id: tool-wrapper
|
||||
title: "ToolWrapper"
|
||||
type: concept
|
||||
tags: [Agent, Skill, 设计模式]
|
||||
sources: []
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
# ToolWrapper
|
||||
|
||||
将某个库或框架的规范文档打包成skill的包装模式。Agent只有在真正用到该技术时才会动态加载相关文档（references/目录），而非将所有规则塞入system prompt。
|
||||
|
||||
## 定义
|
||||
|
||||
ToolWrapper是一种Skill设计模式，核心机制是**按需加载**——将领域知识、编码规范、最佳实践封装为可触发的文档模块，仅在Agent检测到相关关键词时激活对应知识。
|
||||
|
||||
## 机制
|
||||
|
||||
- references/目录存放具体技术文档（如conventions.md）
|
||||
- SKILL.md监听特定关键词或事件
|
||||
- 当用户开始使用某技术时，动态加载对应规范
|
||||
- 规范被Agent当作"绝对真理"执行
|
||||
|
||||
## 适用场景
|
||||
|
||||
- 团队内部编码规范分发
|
||||
- 特定框架最佳实践封装
|
||||
- 减少system prompt信息过载
|
||||
- 需要精确控制规范版本和加载时机
|
||||
|
||||
## 优点
|
||||
|
||||
- 按需加载，不浪费上下文token
|
||||
- 规范独立，便于单独更新维护
|
||||
- Agent只在需要时才加载，避免干扰
|
||||
|
||||
## 缺点
|
||||
|
||||
- 需要预先识别和封装所有相关知识
|
||||
- 关键词触发机制可能遗漏边界情况
|
||||
- 多skill并发时可能有加载冲突
|
||||
|
||||
## 关系
|
||||
|
||||
- 上位概念：[[AgentSkill设计模式]]
|
||||
- 并列模式：[[Generator]]、[[Reviewer]]、[[Inversion]]、[[Pipeline]]
|
||||
30
wiki/entities/Google.md
Normal file
30
wiki/entities/Google.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: google
|
||||
title: "Google"
|
||||
type: entity
|
||||
tags: [公司, 云服务, AI]
|
||||
sources: []
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
# Google
|
||||
|
||||
Alphabet Inc.旗下科技公司，云服务提供商，AI领域重要玩家。
|
||||
|
||||
## 基本信息
|
||||
|
||||
- 全称：Google LLC（Alphabet Inc.子公司）
|
||||
- 总部：美国加州山景城
|
||||
- 核心业务：搜索、广告、云计算、AI
|
||||
|
||||
## AI相关
|
||||
|
||||
- Google Cloud：提供AI/ML云服务
|
||||
- Gemini：Google AI大语言模型系列
|
||||
- ADK（Agent Development Kit）：Google发布的Agent开发工具包
|
||||
- 2026年发布5种Agent Skill设计模式指南
|
||||
|
||||
## 在本Wiki中的角色
|
||||
|
||||
- 发布[[AgentSkill设计模式]]（ToolWrapper、Generator、Reviewer、Inversion、Pipeline）的源头之一
|
||||
- 与[[Anthropic]]并列为Skill设计的两大参考来源
|
||||
@@ -9,6 +9,7 @@
|
||||
- [MCP在Cursor中的集成与应用详解](sources/MCP在Cursor中的集成与应用详解.md)
|
||||
- [N8N Full Tutorial Building AI Agents](sources/n8n-full-tutorial-building-ai-agents.md)
|
||||
- [N8N Configure Telegram Trigger](sources/n8n-configure-telegram-trigger.md)
|
||||
- [N8N Docker Install Update](sources/n8n-docker-install-update.md)
|
||||
- [使用Claude自动生成N8N工作流的实操教程](sources/使用Claude自动生成N8N工作流的实操教程.md)
|
||||
- [N8N+Claude通过自然语言自动化工作流](sources/n8n+Claude通过自然语言自动化工作流.md)
|
||||
- [Podcast Production Pipeline](sources/podcast-production-pipeline.md)
|
||||
@@ -40,6 +41,7 @@
|
||||
- [Polymarket Autopilot](sources/polymarket-autopilot.md)
|
||||
- [YouTube Content Pipeline](sources/youtube-content-pipeline.md)
|
||||
- [Personal CRM with Automatic Contact Discovery](sources/personal-crm.md)
|
||||
- [Phone-Based Personal Assistant](sources/phone-based-personal-assistant.md)
|
||||
- [Knowledge Base RAG](sources/knowledge-base-rag.md)
|
||||
- [X/Twitter Automation from Chat](sources/x-twitter-automation.md)
|
||||
- [Multi-Source Tech News Digest](sources/multi-source-tech-news-digest.md)
|
||||
@@ -81,6 +83,7 @@
|
||||
- [Anthropic Prompt Library实用合集](sources/Anthropic-Prompt-Library-实用合集.md)
|
||||
- [Sora视频自动化生成工作流](sources/Sora视频自动化生成工作流.md)
|
||||
- [Gemini-3-一口气做了10个应用](sources/Gemini-3-一口气做了10个应用.md)
|
||||
- [Google-5个Agent-Skill设计模式](sources/Google-5个Agent-Skill设计模式.md)
|
||||
- [我的工具集](sources/我的工具集.md)
|
||||
- [ChatGPT-Canva-Gamma-简报工作流](sources/ChatGPT-Canva-Gamma-简报工作流.md)
|
||||
- [文字生成视频网站推荐](sources/文字生成视频网站推荐.md)
|
||||
|
||||
41
wiki/sources/2025-03-02.md
Normal file
41
wiki/sources/2025-03-02.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "2025-03-02 日记"
|
||||
type: source
|
||||
tags: [diary]
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Daily notes/2025-03-02.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AI Agent在工作场景中的应用探索
|
||||
- 问题域：Cloud DevOps中如何利用AI提升效率
|
||||
- 方法/机制：通过阅读LinkedIn文章和YouTube视频了解Agentic AI最新发展
|
||||
- 结论/价值：计划撰写Agentic AI在Cloud DevOps中的应用文章，探索Grafana数据喂给AI进行决策的可行性
|
||||
|
||||
## Key Claims
|
||||
- LinkedIn上有价值的Agentic AI文章值得系统整理并撰写文章分享
|
||||
- n8n可作为设计Agentic AI工作流的工具本地部署
|
||||
- Grafana监控数据可喂入AI Agent的向量数据库辅助决策
|
||||
- 告警机制可用于实时事件处理和自动创建工单
|
||||
|
||||
## Key Quotes
|
||||
> "Use data from Grafana to feed into an Agent's Vector DB so the AI can consume the data and help us make decisions."
|
||||
> "Use the alerting mechanism to handle incidents in real time, such as immediate notifications and direct incident creation."
|
||||
|
||||
## Key Concepts
|
||||
- [[Agentic AI]]：能够自主行动以达成目标的AI系统
|
||||
- [[VectorDB]]：向量数据库，用于存储和检索嵌入向量
|
||||
- [[Grafana]]：开源监控和可观测性平台
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：开源AI Agent框架
|
||||
- [[N8N]]：工作流自动化平台
|
||||
- [[DavidOndrej]]：YouTube内容创作者
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← 应用场景 ← [[Grafana]]
|
||||
- [[N8N]] ← 用于构建 ← [[工作流自动化]]
|
||||
|
||||
## Contradictions
|
||||
36
wiki/sources/2025-03-04.md
Normal file
36
wiki/sources/2025-03-04.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "2025-03-04 日记"
|
||||
type: source
|
||||
tags: [diary]
|
||||
date: 2025-03-04
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Daily notes/2025-03-04.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：利用现有数据构建AI模型支持
|
||||
- 问题域：如何将运营数据转化为AI可用的标准化数据集
|
||||
- 方法/机制：通过与Jackie Ye讨论，确定了利用监控数据、标准化指标、阈值和运行手册构建数据集的路径
|
||||
- 结论/价值：AI驱动的情感分析、工单自动分配和解决方案建议是三个可行的PoC方向
|
||||
|
||||
## Key Claims
|
||||
- 现有的监控数据、标准化指标和阈值可作为AI模型训练的基础
|
||||
- 客户工单情感分析可帮助Customer Success Managers优化策略
|
||||
- AI可实现工单自动分配和历史方案推荐
|
||||
|
||||
## Key Quotes
|
||||
> "We need well-structured and mature datasets to support future development and implementation."
|
||||
|
||||
## Key Concepts
|
||||
- [[标准化数据集]]：结构化、可复用的数据集合
|
||||
- [[PoC]]：概念验证
|
||||
|
||||
## Key Entities
|
||||
- [[Jackie Ye]]：Cloud Ops团队成员
|
||||
|
||||
## Connections
|
||||
- [[标准化数据集]] ← 基础 ← [[监控数据]]
|
||||
- [[情感分析]] ← 应用场景 ← [[客户工单]]
|
||||
|
||||
## Contradictions
|
||||
37
wiki/sources/2025-03-05.md
Normal file
37
wiki/sources/2025-03-05.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "2025-03-05 日记"
|
||||
type: source
|
||||
tags: [diary]
|
||||
date: 2025-03-05
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Daily notes/2025-03-05.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AI Agent构建学习和n8n实践
|
||||
- 问题域：如何快速入门AI Agent开发
|
||||
- 方法/机制：观看YouTube视频学习CrewAI框架，使用NoteGPT提取YouTube字幕并用DeepSeek-R1总结
|
||||
- 结论/价值：CrewAI是初学者入门的好选择，建议从小项目开始逐步迭代
|
||||
|
||||
## Key Claims
|
||||
- CrewAI是适合初学者的AI Agent开发框架
|
||||
- 可以使用Google Colab进行无代码配置
|
||||
- 应从自动化重复任务开始，逐步构建复杂工作流
|
||||
|
||||
## Key Quotes
|
||||
> "Start Small: Automate repetitive tasks (e.g., daily research) before tackling complex workflows."
|
||||
|
||||
## Key Concepts
|
||||
- [[CrewAI]]：开源AI Agent框架
|
||||
- [[Agent模式]]：模型自动执行工具命令的交互模式
|
||||
|
||||
## Key Entities
|
||||
- [[CrewAI]]：AI Agent开发框架
|
||||
- [[DeepSeek-R1]]：DeepSeek推理模型
|
||||
|
||||
## Connections
|
||||
- [[CrewAI]] ← 用于构建 ← [[AI Agent]]
|
||||
- [[DeepSeek-R1]] ← 用于 ← [[内容总结]]
|
||||
|
||||
## Contradictions
|
||||
37
wiki/sources/2025-03-10.md
Normal file
37
wiki/sources/2025-03-10.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "2025-03-10 日记"
|
||||
type: source
|
||||
tags: [diary]
|
||||
date: 2025-03-10
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Daily notes/2025-03-10.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：N8N工作流配置与应用
|
||||
- 问题域：实现自动化内容生成和发布
|
||||
- 方法/机制：配置n8n实现工作流备份、AI生成社交媒体内容、RSS翻译推送
|
||||
- 结论/价值：成功配置三个n8n工作流，覆盖备份、内容生成和RSS翻译场景
|
||||
|
||||
## Key Claims
|
||||
- n8n可实现工作流自动备份到Google Drive
|
||||
- AI可基于关键词生成社交媒体内容并自动发布
|
||||
- RSS Feed可结合AI实现实时翻译并推送至Telegram
|
||||
|
||||
## Key Quotes
|
||||
> "AI-Powered Social Media Content Generator & Publisher"
|
||||
|
||||
## Key Concepts
|
||||
- [[工作流自动化]]：使用工具自动执行重复性任务
|
||||
- [[RSS]]：Really Simple Syndication，信息聚合标准
|
||||
|
||||
## Key Entities
|
||||
- [[N8N]]：工作流自动化平台
|
||||
- [[Google Drive]]：云存储服务
|
||||
|
||||
## Connections
|
||||
- [[N8N]] ← 实现 ← [[工作流自动化]]
|
||||
- [[RSS]] ← 触发 ← [[AI翻译]]
|
||||
|
||||
## Contradictions
|
||||
39
wiki/sources/2025-03-14.md
Normal file
39
wiki/sources/2025-03-14.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "2025-03-14 日记"
|
||||
type: source
|
||||
tags: [diary]
|
||||
date: 2025-03-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Daily notes/2025-03-14.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：F5-TTS本地语音克隆工具安装
|
||||
- 问题域：如何在本地实现语音克隆
|
||||
- 方法/机制：使用Conda创建Python 3.10环境，安装PyTorch和F5-TTS，配置FFmpeg
|
||||
- 结论/价值：成功安装F5-TTS并测试语音转换，效果良好但CPU处理较慢
|
||||
|
||||
## Key Claims
|
||||
- F5-TTS是由交大学生开发的开源语音克隆项目
|
||||
- 使用Conda可以创建独立的Python环境避免依赖冲突
|
||||
- FFmpeg是处理音频文件的必要组件
|
||||
- GPU加速可显著提升推理速度
|
||||
|
||||
## Key Quotes
|
||||
> "ffmpeg was not found but is required to load audio files from filename"
|
||||
|
||||
## Key Concepts
|
||||
- [[语音克隆]]：用少量样本重建个人声音
|
||||
- [[Conda]]：Python环境管理工具
|
||||
|
||||
## Key Entities
|
||||
- [[F5-TTS]]：开源语音克隆项目
|
||||
- [[FFmpeg]]：多媒体处理工具
|
||||
- [[Gradio]]：Web界面框架
|
||||
|
||||
## Connections
|
||||
- [[F5-TTS]] ← 基于 ← [[PyTorch]]
|
||||
- [[语音克隆]] ← 应用场景 ← [[AI配音]]
|
||||
|
||||
## Contradictions
|
||||
34
wiki/sources/2025-03-15.md
Normal file
34
wiki/sources/2025-03-15.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "2025-03-15 日记"
|
||||
type: source
|
||||
tags: [diary]
|
||||
date: 2025-03-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Daily notes/2025-03-15.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Chat-TTS、Notion集成和CUDA配置
|
||||
- 问题域：探索轻量级语音合成和知识管理工具
|
||||
- 方法/机制：对比Chat-TTS与F5-TTS，安装NVIDIA CUDA运行时，集成Notion
|
||||
- 结论/价值：Chat-TTS执行更快，Notion可作为笔记存储后端
|
||||
|
||||
## Key Claims
|
||||
- Chat-TTS比F5-TTS执行更快，基于默认语音库处理
|
||||
- NVIDIA CUDA可加速模型推理
|
||||
- Notion API可实现笔记集成
|
||||
|
||||
## Key Concepts
|
||||
- [[AI配音]]：文本转语音技术
|
||||
|
||||
## Key Entities
|
||||
- [[Chat-TTS]]：开源语音合成工具
|
||||
- [[NVIDIA CUDA]]：GPU计算平台
|
||||
- [[Notion]]：笔记和知识管理平台
|
||||
|
||||
## Connections
|
||||
- [[Chat-TTS]] ← 对比 ← [[F5-TTS]]
|
||||
- [[Notion]] ← 集成 ← [[Obsidian]]
|
||||
|
||||
## Contradictions
|
||||
30
wiki/sources/2025-05-13.md
Normal file
30
wiki/sources/2025-05-13.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "Ubuntu合盖行为配置"
|
||||
type: source
|
||||
tags: [tutorial]
|
||||
date: 2025-05-13
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Daily notes/2025-05-13.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Ubuntu系统合盖行为配置
|
||||
- 问题域：如何在Ubuntu系统中禁用合盖休眠
|
||||
- 方法/机制：修改systemd-logind服务配置，设置HandleLidSwitch为ignore
|
||||
- 结论/价值：通过配置文件可灵活控制笔记本合盖行为
|
||||
|
||||
## Key Claims
|
||||
- 修改/etc/systemd/logind.conf可控制合盖行为
|
||||
- GNOME桌面环境可能有独立的电源设置覆盖systemd配置
|
||||
|
||||
## Key Concepts
|
||||
- [[systemd]]：Linux系统和服务管理器
|
||||
|
||||
## Key Entities
|
||||
- [[Ubuntu]]：Linux发行版
|
||||
|
||||
## Connections
|
||||
- [[systemd]] ← 管理 ← [[电源行为]]
|
||||
|
||||
## Contradictions
|
||||
30
wiki/sources/2025-07-02.md
Normal file
30
wiki/sources/2025-07-02.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "2025-07-02 日记"
|
||||
type: source
|
||||
tags: [diary]
|
||||
date: 2025-07-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Daily notes/2025-07-02.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：直播换脸技术和AI养生视频
|
||||
- 问题域：探索AI在直播和视频内容创作中的应用
|
||||
- 方法/机制：研究VisoMaster开源项目，了解AI生成养生视频的可行性
|
||||
- 结论/价值：直播换脸和AI养生视频是两个值得探索的赛道
|
||||
|
||||
## Key Claims
|
||||
- VisoMaster是开源的直播换脸解决方案
|
||||
- AI生成养生视频是一个有潜力的内容方向
|
||||
|
||||
## Key Concepts
|
||||
- [[换脸技术]]：实时面部替换技术
|
||||
|
||||
## Key Entities
|
||||
- [[VisoMaster]]：开源直播换脸项目
|
||||
|
||||
## Connections
|
||||
- [[AI视频生成]] ← 应用场景 ← [[直播换脸]]
|
||||
|
||||
## Contradictions
|
||||
37
wiki/sources/2025-07-05.md
Normal file
37
wiki/sources/2025-07-05.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "2025-07-05 日记"
|
||||
type: source
|
||||
tags: [diary]
|
||||
date: 2025-07-05
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Daily notes/2025-07-05.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：自在自得的实践路径
|
||||
- 问题域：如何实现身心平衡和自我提升
|
||||
- 方法/机制：整合古典智慧与现代方法，从身心调适、认知提升、行动落实三层面实践
|
||||
- 结论/价值：提出执一守中、有劳而作、言行意合、自然而行的实践理念
|
||||
|
||||
## Key Claims
|
||||
- 4-7-8呼吸法可快速平复焦虑
|
||||
- 情绪标签法可削弱情绪强度
|
||||
- 悖论允许可解除对抗消耗
|
||||
- 全局视野可减少小我执念
|
||||
|
||||
## Key Quotes
|
||||
> "执一守中，有劳而作，言行意合，自然而行"
|
||||
> "终极心法：允许身体如云舒展，允许情绪如溪流来去，允许在不完美中完整存在"
|
||||
|
||||
## Key Concepts
|
||||
- [[4-7-8呼吸法]]：吸气4秒→屏息7秒→吐气8秒的呼吸技术
|
||||
- [[情绪标签法]]：精准命名情绪以削弱其强度
|
||||
|
||||
## Key Entities
|
||||
|
||||
## Connections
|
||||
- [[身心调适]] ← 方法 ← [[认知提升]]
|
||||
- [[认知提升]] ← 支撑 ← [[行动落实]]
|
||||
|
||||
## Contradictions
|
||||
31
wiki/sources/2025-07-07.md
Normal file
31
wiki/sources/2025-07-07.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "2025-07-07 日记"
|
||||
type: source
|
||||
tags: [diary]
|
||||
date: 2025-07-07
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Daily notes/2025-07-07.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：视频转文字并AI总结的实践
|
||||
- 问题域：如何高效理解长视频内容
|
||||
- 方法/机制：使用在线工具将视频转音频，再用AI工具总结
|
||||
- 结论/价值：FFmpeg可作为本地视频音频处理的通用工具
|
||||
|
||||
## Key Claims
|
||||
- online-convert.com和tinywow可实现在线视频转音频
|
||||
- notegpt.io可实现音频AI总结
|
||||
- FFmpeg支持几乎所有视频音频格式转换
|
||||
|
||||
## Key Concepts
|
||||
- [[FFmpeg]]：开源多媒体处理框架
|
||||
|
||||
## Key Entities
|
||||
|
||||
## Connections
|
||||
- [[视频处理]] ← 工具 ← [[FFmpeg]]
|
||||
- [[AI总结]] ← 输入 ← [[音频转文字]]
|
||||
|
||||
## Contradictions
|
||||
33
wiki/sources/2025-07-25.md
Normal file
33
wiki/sources/2025-07-25.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "2025-07-25 日记"
|
||||
type: source
|
||||
tags: [diary]
|
||||
date: 2025-07-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Daily notes/2025-07-25.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：n8n更新和V2RayA配置
|
||||
- 问题域：自动化工具和网络代理的配置
|
||||
- 方法/机制：更新n8n到最新版本，配置V2RayA使用新代理服务
|
||||
- 结论/价值：成功更新n8n和V2RayA，可通过HTTP直接访问n8n
|
||||
|
||||
## Key Claims
|
||||
- N8N_RUNNERS_ENABLED=true可启用Runner功能
|
||||
- N8N_SECURE_COOKIE=false可通过HTTP本地访问
|
||||
- V2RayA可作为NAS的网络代理工具
|
||||
|
||||
## Key Concepts
|
||||
- [[V2Ray]]：代理工具
|
||||
|
||||
## Key Entities
|
||||
- [[N8N]]：工作流自动化平台
|
||||
- [[V2RayA]]：V2Ray的图形化客户端
|
||||
|
||||
## Connections
|
||||
- [[N8N]] ← 配置 ← [[Docker]]
|
||||
- [[V2RayA]] ← 运行在 ← [[NAS]]
|
||||
|
||||
## Contradictions
|
||||
@@ -1,39 +1,40 @@
|
||||
---
|
||||
title: "Claude Skills最值得研究的AI范式"
|
||||
title: "3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！"
|
||||
type: source
|
||||
tags: [claude-skills, prompt-engineering, workflow, vibe-coding]
|
||||
date: 2026-01-05
|
||||
tags: []
|
||||
date: 2026-01-08
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！.md]]
|
||||
- [[raw/AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ 1.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Claude Skills范式深度解析
|
||||
- 问题域：提示词工程向流程工程的转变需求
|
||||
- 方法/机制：Skills作为AI的"说明书"和"SOP"，实现稳定复用和自动执行
|
||||
- 结论/价值：Skills的爆发标志着从提示词工程迈向流程工程
|
||||
- 核心主题：Anthropic 官方 Claude Skills 仓库及其生态
|
||||
- 问题域：AI 技能（Skills）的标准化构建与复用
|
||||
- 方法/机制：Skills 作为 AI 的"说明书"和"SOP"，将重复性任务封装为可复用流程
|
||||
- 结论/价值：从提示词工程（Prompt Engineering）迈向流程工程（Process Engineering），Skills 是 AI 应用范式的质变
|
||||
|
||||
## Key Claims
|
||||
- Skills是Anthropic官方发布的AI技能指南，本质是写给Claude的"说明书"和"SOP"
|
||||
- 官方Skills仓库展示：办公自动化四大件（Word/PDF/PPT/Excel）、开发者工具箱、创意类Skill
|
||||
- 三大Awesome-Claude-Skills仓库：ComposioHQ、VoltAgent、BehiSecc
|
||||
- Skills聚合站：skillsmp.com、aitmpl.com/skills、claudemarketplaces.com
|
||||
- Skills爆发标志从提示词工程到流程工程的关键转变
|
||||
- Anthropic 官方 Skills 仓库（github.com/anthropics/skills）收藏数突破 3.2 万，原封不动拆解 Claude.ai 网页版的生产级能力
|
||||
- Skills 本质是写给 Claude 的"说明书"和"SOP"，将固定流程任务拆解为 AI 能理解、稳定复用、自动执行的一套流程
|
||||
- 官方库展示四大类 Skills：办公自动化（Word/PDF/PPT/Excel）、开发者工具箱、MCP Server、创意类 Skill
|
||||
- Skills 爆发标志着从"提示词工程"迈向"流程工程"，核心价值在于把经验沉淀为 SOP，再交给 AI 稳定执行
|
||||
|
||||
## Key Quotes
|
||||
> "Skills 就是一套你写给 Claude 的'说明书'和'SOP（标准作业程序）'" — 文章定义
|
||||
> "这个库本质上是官方在教你，'怎么像我们一样开发 AI 应用'" — 对官方库的评价
|
||||
> "Claude Skills 的爆发，标志着我们从提示词工程迈向了流程工程" — 核心结论
|
||||
|
||||
## Key Concepts
|
||||
- [[Claude Skills]]：AI技能的系统化封装，包含Prompt结构、参数含义、容错策略
|
||||
- [[流程工程]]：Skills将经验沉淀为SOP，交给AI稳定执行
|
||||
- [[Vibe Coding]]：AI编程方式，其尽头也是Skills
|
||||
- [[SOP标准化]]：将重复任务拆解为AI能理解、稳定复用的流程
|
||||
- [[Claude Skills]]：将反复执行、有固定流程的任务封装为 AI 可理解、可复用、可自动执行的标准化流程
|
||||
- [[流程工程]]：将经验沉淀为 SOP，再交给 AI 稳定执行的新范式，区别于单独的提示词优化
|
||||
|
||||
## Key Entities
|
||||
- [[Anthropic]]：Claude Skills官方仓库发布者
|
||||
- [[Claude]]：AI助手
|
||||
- [[Anthropic]]：Claude Skills 的官方发布者，拥有 github.com/anthropics/skills 仓库
|
||||
|
||||
## Connections
|
||||
- [[提示词工程]] ← evolves_to ← [[流程工程]]
|
||||
- [[Claude Skills]] ← implements ← [[SOP标准化]]
|
||||
- [[Vibe Coding]] ← uses ← [[Claude Skills]]
|
||||
- [[Claude Skills]] ← extends ← [[流程工程]]
|
||||
- [[Anthropic]] ← provides ← [[Claude Skills]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
@@ -1,35 +1,39 @@
|
||||
---
|
||||
title: "7 ways I use NotebookLM to make my life easier"
|
||||
type: source
|
||||
tags: [notebooklm, google, learning, productivity]
|
||||
date: 2025-11-23
|
||||
tags: []
|
||||
date: 2025-12-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/7 ways I use NotebookLM to make my life easier.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：NotebookLM使用技巧
|
||||
- 问题域：信息过载、文档处理、学习效率
|
||||
- 方法/机制：source-grounding文档问答、音频概览、项目管理
|
||||
- 结论/价值：NotebookLM通过严格限制知识库范围保证准确性，是个人学习和项目管理的强大助手
|
||||
- 核心主题：NotebookLM 的深度使用场景与实用技巧
|
||||
- 问题域：信息过载时代的知识管理、被动学习效率提升
|
||||
- 方法/机制：利用 NotebookLM 的 Source-Grounding 限制、Audio Overviews 播客生成、交互式问答等功能，将碎片化信息转化为可消费内容
|
||||
- 结论/价值：NotebookLM 的核心优势在于准确性优先(strictly limiting knowledge base to trusted documents)，可作为个性化项目管理和法律文档审查助手
|
||||
|
||||
## Key Claims
|
||||
- NotebookLM的source-grounding机制确保回答准确且可溯源
|
||||
- 音频概览功能将文档转化为双人播客，适合被动学习
|
||||
- 可作为个性化项目管理中心，集中管理分散的研究和想法
|
||||
- 法律文档审查时提供精确引用，避免AI幻觉
|
||||
- NotebookLM 的 Source-Grounding 机制将知识库严格限制在用户上传的文档内，输出结果自动带有引用验证
|
||||
- Audio Overviews 功能将文档转化为 AI 双人播客，适合通勤、健身等被动学习场景
|
||||
- NotebookLM 可作为个性化项目管理系统，将分散的研究和想法汇聚成结构化路线图
|
||||
- 法律文档（租约等）审查是 NotebookLM 的高价值场景：每个答案附带精确引用，可直接定位原文
|
||||
|
||||
## Key Quotes
|
||||
> "NotebookLM's best quality is that it prioritizes accuracy by strictly limiting its knowledge base to only your trusted documents" — 核心定位
|
||||
> "It cuts right through all that informational mess and makes sure I feel like I have processed the content, even though I technically never read the original source" — 被动学习价值
|
||||
|
||||
## Key Concepts
|
||||
- [[Source-Grounding]]：NotebookLM的核心机制，限制知识库仅包含用户上传的文档
|
||||
- [[音频概览]]：将文档转化为AI双人播客格式
|
||||
- [[项目中心]]：集中管理研究、想法、会议记录的统一空间
|
||||
- [[Source-Grounding]]：NotebookLM 将知识库严格限制在上传文档内，确保输出准确且自带引用的机制
|
||||
- [[音频概览]]：NotebookLM 将文档转化为 AI 双人播客格式，支持主动学习和被动消费
|
||||
|
||||
## Key Entities
|
||||
- [[NotebookLM]]：Google推出的AI学习工具
|
||||
- [[NotebookLM]]：Google 出品的 AI 学习工具，核心功能包括 Source-Grounding、Audio Overviews、交互式问答
|
||||
|
||||
## Connections
|
||||
- [[NotebookLM]] ← uses ← [[Source-Grounding]]
|
||||
- [[AI学习工具]] ← extends ← [[NotebookLM]]
|
||||
- [[Source-Grounding]] ← implemented_by ← [[NotebookLM]]
|
||||
- [[音频概览]] ← implemented_by ← [[NotebookLM]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "A Formalization of Recursive Self-Optimizing Generative Systems"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-12-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/A Formalization of Recursive Self-Optimizing Generative Systems.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：递归自我优化生成系统的形式化数学模型
|
||||
- 问题域：如何让 AI 系统通过迭代自我修改构建稳定的生成能力
|
||||
- 方法/机制：定义生成器空间（Generator Space）、优化算子（O-operator）、元生成算子（M-operator），通过不动点（Fixed Point）语义描述系统收敛行为
|
||||
- 结论/价值：稳定的生成能力对应于元生成算子的不动点，递归自我优化自然导致不动点结构而非终端输出
|
||||
|
||||
## Key Claims
|
||||
- 系统定义：Generator G（I→P）、O-operator O（P×Ω→P）、M-operator M（G×P→G）三者构成递归循环
|
||||
- 不动点定义：G* 满足 Φ(G*) = G*，其中 Φ 是生成器空间上的自映射
|
||||
- λ-calculus 表达：使用 Y-组合子（固定点组合子）表达稳定生成器 G* ≡ Y·STEP
|
||||
- 自举过程（Bootstrap）：α-提示词（生成器）和 Ω-提示词（优化器）通过递归优化循环无限逼近理想状态
|
||||
|
||||
## Key Quotes
|
||||
> "The system's objective is not a particular P*, but the convergence behavior of the sequence {G_n}" — 核心目标
|
||||
> "Such a generator is invariant under its own generate–optimize–update cycle" — 不动点含义
|
||||
> "What I cannot create, I do not understand — Richard Feynman" — 核心理念
|
||||
|
||||
## Key Concepts
|
||||
- [[固定点语义]]：递归自我优化生成器的稳定状态由元生成算子的不动点定义
|
||||
- [[自举Meta-生成]]：α-提示词（生成器）和 Ω-提示词（优化器）通过递归循环实现自我超越
|
||||
- [[生成器空间]]：所有可能生成器的集合 Φ ⊆ P^I，系统在其中收敛
|
||||
|
||||
## Key Entities
|
||||
|
||||
## Connections
|
||||
- [[固定点语义]] ← defines ← [[自举Meta-生成]]
|
||||
- [[生成器空间]] ← iterates_on ← [[固定点语义]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
39
wiki/sources/AI-解决方案专家培训课程.md
Normal file
39
wiki/sources/AI-解决方案专家培训课程.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "AI 解决方案专家培训课程"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-06-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/AI 解决方案专家培训课程.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Coze（扣子）平台的 Demo 合集，涵盖多行业 AI Agent 应用案例
|
||||
- 问题域：企业级 AI Agent 的快速搭建与行业应用
|
||||
- 方法/机制：通过 Coze 国内版和海外版平台，提供 Bot（智能体）和 Workflow（工作流）两种构建方式，覆盖金融、教育、医疗、电商、人力资源、在线客服等多个行业
|
||||
- 结论/价值：Coze 平台大幅降低了 AI Agent 的开发门槛，无需编程即可创建功能丰富的对话式 AI 应用
|
||||
|
||||
## Key Claims
|
||||
- Coze 平台支持国内版（coze.cn）和海外版（coze.com），提供 Bot 和 Workflow 两种构建模式
|
||||
- 金融行业案例：知乎财报解读、客户分层营销助手、智能客服 Agent
|
||||
- 教育行业案例：知识库问答、拍照搜视频、组卷出题、知识点掌握情况评估
|
||||
- 医疗行业案例：影像图片识别、在线问诊、医疗分诊助手
|
||||
- 电商行业案例：混剪助手、在线换衣、抖音直播间自动回复助手
|
||||
|
||||
## Key Quotes
|
||||
> "Coze平台demo合集" — 平台概述
|
||||
|
||||
## Key Concepts
|
||||
- [[Coze Bot]]：扣子平台的对话式 AI Agent，无需编程即可创建
|
||||
- [[Coze Workflow]]：扣子平台的工作流自动化编排工具，支持复杂业务流程
|
||||
|
||||
## Key Entities
|
||||
- [[Coze]]：字节跳动出品的 AI Agent 构建平台，支持国内版和海外版
|
||||
|
||||
## Connections
|
||||
- [[Coze Bot]] ← part_of ← [[Coze]]
|
||||
- [[Coze Workflow]] ← part_of ← [[Coze]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
42
wiki/sources/Best-7-News-API-Data-Feeds.md
Normal file
42
wiki/sources/Best-7-News-API-Data-Feeds.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Best 7 news API data feeds - AI News"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-03-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Best 7 news API data feeds - AI News.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：七大新闻 API 数据源平台的对比分析与行业应用
|
||||
- 问题域：企业获取结构化新闻数据的技术选型
|
||||
- 方法/机制：通过新闻 API 将非结构化内容聚合、格式化（JSON/XML）并交付给应用和workflows
|
||||
- 结论/价值：不同 API 各有专长——金融分析选 Bloomberg/Webz.io，初创项目选 GNews/Mediastack，新闻监测选 Opoint
|
||||
|
||||
## Key Claims
|
||||
- Webz.io：最全面的新闻 API，涵盖表层、深层和暗网数据，支持情感分析，适合金融和网络安全领域
|
||||
- GNews API：轻量级、易用、免费额度充足，适合小型应用和区域化新闻聚合
|
||||
- The Guardian API：高质量编辑内容，适合研究和专业内容平台
|
||||
- Bloomberg API：专注于金融市场数据，提供实时市场覆盖和专业投资分析
|
||||
- Financial Times API：商业和经济新闻的高级解决方案，适合经济学家和高层管理者
|
||||
- Opoint：专注于新闻监测和情感分析，支持多语言，适合 PR 和品牌监测团队
|
||||
- Mediastack：聚合全球 7500+ 来源，支持免费套餐，灵活性和可扩展性强
|
||||
|
||||
## Key Quotes
|
||||
> "News API data feeds are platforms that aggregate, organise, and deliver structured news data from multiple sources" — 定义
|
||||
|
||||
## Key Concepts
|
||||
- [[新闻 API]]：聚合、组织并以结构化格式（JSON/XML）交付新闻数据的技术平台
|
||||
|
||||
## Key Entities
|
||||
- [[Webz.io]]：综合性新闻 API，涵盖表层/深层/暗网数据
|
||||
- [[GNews API]]：轻量级新闻 API，提供实时全球覆盖
|
||||
- [[Opoint]]：新闻监测与情感分析 API
|
||||
- [[Mediastack]]：可扩展新闻聚合 API，支持 7500+ 来源
|
||||
|
||||
## Connections
|
||||
- [[新闻 API]] ← includes ← [[Webz.io]], [[GNews API]], [[Opoint]], [[Mediastack]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
36
wiki/sources/Claude-Prompt-Library.md
Normal file
36
wiki/sources/Claude-Prompt-Library.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Claude Prompt Library"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-12-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Useful Prompt Lib.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Anthropic 官方 Claude Prompt Library 完整清单与功能说明
|
||||
- 问题域：如何快速找到适用的提示词模板提升 AI 使用效率
|
||||
- 方法/机制：汇总 58 个官方提示词模板，按功能分类（开发工具、数据处理、内容创作、生产力、伦理分析等）
|
||||
- 结论/价值：针对 TikTok 跨境电商业务，推荐 Babel's broadcasts（多语言本地化）、Review classifier（评论分类）、Data organizer（数据格式化）三大核心提示词
|
||||
|
||||
## Key Claims
|
||||
- Anthropic 官方 Prompt Library 包含 58 个结构化提示词模板
|
||||
- 覆盖领域：开发工具（Python bug buster、SQL sorcerer、Git gud）、数据处理（CSV converter、Data organizer）、内容创作（Storytelling sidekick、Brand builder）、生产力（Meeting scribe、Career coach）
|
||||
- TikTok 跨境电商推荐：Babel's broadcasts（多语言本地化改写）、Review classifier（评论分类）、Data organizer（非结构化数据→JSON）
|
||||
- 核心应用场景：提示词自动化生成、数据结构化、内容分类、情感分析、格式转换
|
||||
|
||||
## Key Quotes
|
||||
> "针对你目前的 TikTok 跨境电商业务，我建议你重点关注以下几个 Prompt 的逻辑" — 业务应用建议
|
||||
|
||||
## Key Concepts
|
||||
- [[提示词模板]]：预先封装的结构化提示词，针对特定任务（数据分类、格式转换、代码生成）提供即用型解决方案
|
||||
|
||||
## Key Entities
|
||||
- [[Anthropic]]：提供官方 Claude Prompt Library 的 AI 公司
|
||||
|
||||
## Connections
|
||||
- [[提示词模板]] ← provided_by ← [[Anthropic]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
45
wiki/sources/Cloud DevOp Maturity - Guideline.md
Normal file
45
wiki/sources/Cloud DevOp Maturity - Guideline.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Cloud DevOps Maturity Guideline"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud DevOp Maturity - Guideline.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：企业级SaaS公司云DevOps成熟度评估指南
|
||||
- 问题域：DevOps成熟度模型、评估指标、改进路径
|
||||
- 方法/机制：基于CMMI和DORA指标的成熟度评估框架
|
||||
- 结论/价值：提供持续改进的路线图，提升交付效率与可靠性
|
||||
|
||||
## Key Claims
|
||||
- DevOps成熟度评估可降低上市时间、提升运营效率
|
||||
- 成熟度分为多个级别，从初始阶段到高度优化自动化环境
|
||||
- 四大支柱：自动化、协作与文化、监控与可观测性、安全集成
|
||||
|
||||
## Key Quotes
|
||||
> "DevOps is a continuous improvement process, and even mature companies need to adapt to evolving technologies and practices."
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps成熟度模型]]：基于CMMI和DORA指标的评估框架，包含部署频率、变更前置时间、变更失败率、平均恢复时间
|
||||
- [[基础设施即代码]]：使用Terraform、Ansible等工具实现基础设施的版本控制和自动化配置
|
||||
- [[DevSecOps]]：将安全集成到DevOps生命周期中，通过自动化实现持续合规
|
||||
- [[云原生架构]]：采用微服务、容器化、无服务器技术加速交付
|
||||
|
||||
## Key Entities
|
||||
- [[CMMI]]：能力成熟度模型集成
|
||||
- [[DORA]]：DevOps研究与评估组织，提出四项核心指标
|
||||
- [[Terraform]]：基础设施即代码工具
|
||||
- [[Ansible]]：自动化配置管理工具
|
||||
- [[Prometheus]]：监控系统
|
||||
- [[Grafana]]：可视化监控系统
|
||||
|
||||
## Connections
|
||||
- [[DevOps成熟度模型]] ← uses ← [[CMMI]]
|
||||
- [[DevOps成熟度模型]] ← uses ← [[DORA]]
|
||||
- [[云原生架构]] ← enables ← [[CI/CD]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Cloud Maturity Model - A Detailed Guide For Cloud Adoption"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud Maturity Model A Detailed Guide For Cloud Adoption.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：云成熟度模型(CMM)的5个级别及最佳实践
|
||||
- 问题域：企业云采用准备度评估、云迁移路径
|
||||
- 方法/机制：基于人员、流程、技术三维度评估云成熟度
|
||||
- 结论/价值：提供从初始阶段到优化阶段的渐进式云成熟度提升路径
|
||||
|
||||
## Key Claims
|
||||
- 云成熟度模型帮助企业在业务和技术维度评估云采用准备度
|
||||
- 5个成熟度级别：从无云准备到云原生优化
|
||||
- 云成熟度提升是持续改进过程，不能跳跃式发展
|
||||
|
||||
## Key Quotes
|
||||
> "Cloud Maturity Model helps organizations with cloud maturity assessment & readiness for cloud adoption from both business and technical perspectives."
|
||||
|
||||
## Key Concepts
|
||||
- [[云成熟度模型]]：五级评估框架，从等级0（遗留系统）到等级5（优化）
|
||||
- [[云采用框架]]：AWS CAF、Azure CAF、Google CAF等供应商特定框架
|
||||
- [[云治理]]：定义角色、职责和决策流程的结构化框架
|
||||
- [[FinOps]]：云财务运营，优化云支出
|
||||
|
||||
## Key Entities
|
||||
- [[Open Alliance for Cloud Adoption]]：提出云成熟度模型
|
||||
- [[AWS Cloud Adoption Framework]]：AWS云采用框架
|
||||
- [[Azure Cloud Adoption Framework]]：微软云采用框架
|
||||
- [[GCP]]：Google Cloud Platform
|
||||
|
||||
## Connections
|
||||
- [[云成熟度模型]] ← evaluates ← [[云采用框架]]
|
||||
- [[云治理]] ← enables ← [[FinOps]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Cloud Operating Model - Key Strategies and Best Practices"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud Operating Model Key Strategies and Best Practices.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：云运营模型设计策略与最佳实践
|
||||
- 问题域：云治理、安全、成本优化、多云策略
|
||||
- 方法/机制：四大核心支柱——治理、自动化、安全、财务管理
|
||||
- 结论/价值：构建可扩展、安全、合规、经济的云运营体系
|
||||
|
||||
## Key Claims
|
||||
- 云运营模型是云投资有效管理的基础框架
|
||||
- 四大支柱必须对齐IT域与业务条件
|
||||
- 2025年89%企业将运营在云端
|
||||
|
||||
## Key Quotes
|
||||
> "A Cloud Operating Model guarantees orderliness and is the foundation upon which cloud investments can be managed effectively, securely, and sustainably."
|
||||
|
||||
## Key Concepts
|
||||
- [[云运营模型]]：标准化云资源管理、安全、成本控制的框架
|
||||
- [[Zero Trust安全模型]]：无隐式信任、持续验证的安全架构
|
||||
- [[基础设施即代码]]：使用Terraform等工具实现部署自动化
|
||||
- [[多云策略]]：跨AWS、Azure、GCP分布工作负载
|
||||
|
||||
## Key Entities
|
||||
- [[Terraform]]：基础设施即代码工具
|
||||
- [[AWS Cost Explorer]]：AWS成本管理工具
|
||||
- [[Azure Cost Management]]：Azure成本管理工具
|
||||
- [[FinOps]]：云财务运营
|
||||
|
||||
## Connections
|
||||
- [[云运营模型]] ← uses ← [[Zero Trust安全模型]]
|
||||
- [[云运营模型]] ← uses ← [[基础设施即代码]]
|
||||
- [[云运营模型]] ← uses ← [[FinOps]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "DevOps Culture and Transformation"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation LinkedIn.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：DevOps文化转型与协作实践
|
||||
- 问题域：打破部门墙、加速交付、驱动创新
|
||||
- 方法/机制：四大支柱——协作、自动化、持续改进、客户导向
|
||||
- 结论/价值：构建持续交付和创新的组织文化
|
||||
|
||||
## Key Claims
|
||||
- DevOps不仅是工具，更是一种文化转变
|
||||
- 跨职能团队共享整个软件生命周期的所有权
|
||||
- CI/CD将反馈周期从数周缩短到数分钟
|
||||
|
||||
## Key Quotes
|
||||
> "DevOps isn't just about tools or automation; it's a mindset shift that prioritizes collaboration, continuous learning, and customer-centricity."
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps文化]]：打破开发与运维壁垒的协作文化
|
||||
- [[CI/CD]]：持续集成/持续交付流水线
|
||||
- [[基础设施即代码]]：版本控制的环境配置
|
||||
- [[GitOps]]：使用Git作为唯一真实来源的基础设施管理
|
||||
- [[DevSecOps]]：将安全集成到DevOps工作流
|
||||
|
||||
## Key Entities
|
||||
- [[Jenkins]]：CI/CD工具
|
||||
- [[GitLab CI]]：GitLab持续集成
|
||||
- [[GitHub Actions]]：GitHub自动化工作流
|
||||
- [[Prometheus]]：监控系统
|
||||
- [[Grafana]]：可视化监控
|
||||
|
||||
## Connections
|
||||
- [[DevOps文化]] ← enables ← [[CI/CD]]
|
||||
- [[DevOps文化]] ← integrates ← [[DevSecOps]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "DevOps Culture and Transformation"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation LinkedIn.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：DevOps文化转型与协作实践
|
||||
- 问题域：打破部门墙、加速交付、驱动创新
|
||||
- 方法/机制：四大支柱——协作、自动化、持续改进、客户导向
|
||||
- 结论/价值：构建持续交付和创新的组织文化
|
||||
|
||||
## Key Claims
|
||||
- DevOps不仅是工具，更是一种文化转变
|
||||
- 跨职能团队共享整个软件生命周期的所有权
|
||||
- CI/CD将反馈周期从数周缩短到数分钟
|
||||
|
||||
## Key Quotes
|
||||
> "DevOps isn’t just about tools or automation; it’s a mindset shift that prioritizes collaboration, continuous learning, and customer-centricity."
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps文化]]：打破开发与运维壁垒的协作文化
|
||||
- [[CI/CD]]：持续集成/持续交付流水线
|
||||
- [[基础设施即代码]]：版本控制的环境配置
|
||||
- [[GitOps]]：使用Git作为唯一真实来源的基础设施管理
|
||||
- [[DevSecOps]]：将安全集成到DevOps工作流
|
||||
|
||||
## Key Entities
|
||||
- [[Jenkins]]：CI/CD工具
|
||||
- [[GitLab CI]]：GitLab持续集成
|
||||
- [[GitHub Actions]]：GitHub自动化工作流
|
||||
- [[Prometheus]]：监控系统
|
||||
- [[Grafana]]：可视化监控
|
||||
|
||||
## Connections
|
||||
- [[DevOps文化]] ← enables ← [[CI/CD]]
|
||||
- [[DevOps文化]] ← integrates ← [[DevSecOps]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "DevOps Maturity Model - From Traditional IT to Advanced DevOps"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/DevOps Maturity Model From Traditional IT to Advanced DevOps.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：DevOps成熟度模型的5个阶段
|
||||
- 问题域：从传统IT到高级DevOps的转型路径
|
||||
- 方法/机制：文化、自动化、结构、协作、技术五维度评估
|
||||
- 结论/价值：实现持续部署和高频交付
|
||||
|
||||
## Key Claims
|
||||
- DevOps成熟度模型帮助组织评估当前实践并识别改进领域
|
||||
- 5个阶段从初始/adhoc到完全成熟
|
||||
- 关键指标包括部署频率、MTTR、变更失败率
|
||||
|
||||
## Key Quotes
|
||||
> "The DevOps maturity model is a structured framework that guides organizations through adopting and implementing DevOps principles."
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps成熟度模型]]：五阶段评估框架
|
||||
- [[CI/CD]]：持续集成/持续交付
|
||||
- [[DevSecOps]]：将安全集成到DevOps
|
||||
- [[MTTR]]：平均恢复时间
|
||||
- [[Lead Time]]：代码提交到部署的时间
|
||||
|
||||
## Key Entities
|
||||
- [[Kubernetes]]：容器编排平台
|
||||
- [[Docker]]：容器化工具
|
||||
- [[Terraform]]：基础设施即代码
|
||||
|
||||
## Connections
|
||||
- [[DevOps成熟度模型]] ← includes ← [[CI/CD]]
|
||||
- [[DevOps成熟度模型]] ← integrates ← [[DevSecOps]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
38
wiki/sources/Git Push 连接重置问题修复.md
Normal file
38
wiki/sources/Git Push 连接重置问题修复.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "Git Push 连接重置问题修复"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Git Push 连接重置问题修复.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Git Push连接重置问题的解决方案
|
||||
- 问题域：国内访问GitHub时的网络干扰
|
||||
- 方法/机制：配置HTTP/SOCKS5代理、切换SSH协议
|
||||
- 结论/价值：根本解决TCP连接层面中断问题
|
||||
|
||||
## Key Claims
|
||||
- Recv failure是TCP连接中断，非权限问题
|
||||
- 代理方案最有效
|
||||
- 可切换SSH协议绕过
|
||||
|
||||
## Key Quotes
|
||||
> "连接重置是TCP连接层面的中断。"
|
||||
|
||||
## Key Concepts
|
||||
- [[Git代理]]：为Git单独配置代理
|
||||
- [[TCP RST]]：连接重置包
|
||||
- [[Git SSH]]：使用SSH协议
|
||||
|
||||
## Key Entities
|
||||
- [[GitHub]]：代码托管平台
|
||||
- [[V2RayN]]：代理软件
|
||||
|
||||
## Connections
|
||||
- [[Git代理]] ← uses ← [[SOCKS5代理]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Google 5个Agent Skill设计模式"
|
||||
title: "Google-5个Agent-Skill设计模式"
|
||||
type: source
|
||||
tags: []
|
||||
tags: [Agent, Skill, 设计模式, Google]
|
||||
date: 2026-03-19
|
||||
---
|
||||
|
||||
@@ -9,22 +9,42 @@ date: 2026-03-19
|
||||
- [[raw/Agent/Google-5个Agent-Skill设计模式-2026-03-19.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Google发布的5个常用Agent Skill设计模式
|
||||
- 问题域：Agent Skill开发、最佳实践
|
||||
- 方法/机制：5种经过生产验证的Agent Skill设计模式
|
||||
- 结论/价值：继Anthropic之后，Google也公布了其内部使用的Agent Skill设计模式
|
||||
- 核心主题：Google发布的5种Agent Skill设计模式，用于解决同等格式skill执行效果差异巨大的问题
|
||||
- 问题域：Agent Skill的内容设计层面，如何将知识/规范/工作流有效封装
|
||||
- 方法/机制：Tool Wrapper、Generator、Reviewer、Inversion、Pipeline五种设计模式
|
||||
- 结论/价值：格式标准化解决了外在结构问题，内在逻辑设计才是skill质量的关键；五种模式可组合使用
|
||||
|
||||
## Key Claims
|
||||
- Google公布5个常用的Agent Skill设计模式
|
||||
- 模式覆盖：Tool Use、Code Execution、Data Processing等场景
|
||||
- 每个模式配有具体实现指导和示例
|
||||
- SKILL.md格式标准化后，格式不再是问题，但同等格式的skill执行效果天差地别，差距在于内容设计
|
||||
- Tool Wrapper模式通过动态加载机制，让agent只在需要时才加载相关文档，避免信息过载
|
||||
- Generator模式通过模板+变量填充流程，保证agent输出格式一致性
|
||||
- Reviewer模式将"检查什么"和"怎么检查"完全分离，审查标准可替换
|
||||
- Inversion模式将agent从"先做后问"反转为"先问再做"，通过硬性门控指令控制流程
|
||||
- Pipeline模式在复杂任务中设置硬性检查点，强制agent按序执行
|
||||
- 五种模式可组合：Pipeline末尾可加Reviewer，Generator开始可用Inversion收集变量
|
||||
|
||||
## Key Quotes
|
||||
> "最好的Skill不是写得好的提示词，而是一个「工具箱」。" — Anthropic Skill设计经验
|
||||
> "把工作流拆分开，应用正确的结构模式，才能构建出真正可靠的agent。" — Google指南总结
|
||||
|
||||
## Key Concepts
|
||||
- [[AgentSkill设计模式]]：经过生产验证的Agent开发模式
|
||||
- [[GoogleAgent]] ← 来源 ← [[AgentSkill设计模式]]
|
||||
- [[ToolWrapper]]：将领域知识文档打包成skill，agent只在用到时才动态加载，减少信息过载
|
||||
- [[Generator]]：使用模板+样式指南，通过变量填充流程保证一致输出的skill模式
|
||||
- [[Reviewer]]：将审查标准与审查逻辑分离，标准可替换的代码/文档审查skill模式
|
||||
- [[Inversion]]：agent先提问收集必要信息再行动的反向工作流模式
|
||||
- [[Pipeline]]：带硬性检查点的严格顺序工作流，防止agent跳过关键步骤
|
||||
- [[AgentSkill]]：封装特定领域知识或工作流的技能模块，是OpenClaw等框架的扩展机制
|
||||
|
||||
## Key Entities
|
||||
- [[Google]]：发布Agent Skill设计模式的科技公司
|
||||
- [[Google]]：发布5种Agent Skill设计模式的云服务提供商
|
||||
- [[Anthropic]]：Claude模型开发商，提出Skill分类九类和三条铁律
|
||||
- [[SKILL_md]]：Skill的标准格式文件，已被30+主流工具支持
|
||||
|
||||
## Connections
|
||||
- [[ClaudeSkills]] ← parallel ← [[GoogleAgent]] ← similar ← [[AgentSkill设计模式]]
|
||||
- [[AgenticAI]] ← fundamental ← [[AgentSkill]] ← uses ← [[ToolWrapper]], [[Generator]], [[Reviewer]], [[Inversion]], [[Pipeline]]
|
||||
- [[Skill设计模式]] ← derived_from ← [[AgenticAI]] ← implemented_by ← [[OpenClaw]], [[ClaudeCode]]
|
||||
|
||||
## Contradictions
|
||||
- 与通用单一Prompt方案冲突：本文认为分散的专用模式优于集中式大prompt
|
||||
- 当前观点：好的Skill是工具箱而非大prompt，应拆分专业模式
|
||||
- 对方观点：单一统一prompt更易管理维护
|
||||
|
||||
42
wiki/sources/How Agentic AI can help for Cloud DevOps.md
Normal file
42
wiki/sources/How Agentic AI can help for Cloud DevOps.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "How Agentic AI Can Help for Cloud DevOps"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/How Agentic AI can help for Cloud DevOps.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AI Agent在云DevOps中的应用
|
||||
- 问题域：自动化事件检测、成本优化、安全合规
|
||||
- 方法/机制：自主决策和执行任务的AI系统
|
||||
- 结论/价值：实现更快的部署和主动问题解决
|
||||
|
||||
## Key Claims
|
||||
- Agentic AI可主动检测异常并自动修复
|
||||
- AI驱动的根因分析加速MTTR
|
||||
- 多云成本治理和优化
|
||||
|
||||
## 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]]：预测性维护
|
||||
|
||||
## Key Entities
|
||||
- [[AWS EKS]]：Amazon Elastic Kubernetes Service
|
||||
- [[GKE]]：Google Kubernetes Engine
|
||||
- [[Azure AKS]]：Azure Kubernetes Service
|
||||
- [[CloudWatch]]：AWS监控
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← enables ← [[Self-Healing Systems]]
|
||||
- [[Agentic AI]] ← optimizes ← [[多云策略]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "How Can a Multi Cloud Strategy Transform Your Business ROI"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/How Can a Multi Cloud Strategy Transform Your Business ROI.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：多云策略的业务价值
|
||||
- 问题域：避免供应商锁定、成本优化、性能优化
|
||||
- 方法/机制：跨AWS、Azure、GCP分布工作负载
|
||||
- 结论/价值：实现30%运营成本降低
|
||||
|
||||
## Key Claims
|
||||
- 78%企业使用多云策略部署在3个以上公有云
|
||||
- 多云策略避免供应商锁定
|
||||
- 数据主权和合规要求满足
|
||||
|
||||
## Key Quotes
|
||||
> "The 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."
|
||||
|
||||
## Key Concepts
|
||||
- [[多云策略]]：使用多个云服务提供商
|
||||
- [[供应商锁定]]：依赖单一云提供商的风险
|
||||
- [[数据主权]]：数据存储的地域合规要求
|
||||
- [[ROI]]：投资回报率
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：Amazon Web Services
|
||||
- [[Azure]]：Microsoft Azure
|
||||
- [[Google Cloud]]：GCP
|
||||
- [[Kubernetes]]：容器编排
|
||||
- [[Terraform]]：基础设施即代码
|
||||
|
||||
## Connections
|
||||
- [[多云策略]] ← reduces ← [[供应商锁定]]
|
||||
- [[多云策略]] ← enables ← [[数据主权]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/How to Simplify Multi-Account Deployments Monitoring Centralized Logs for AWS CloudFormation StackSets.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：多账户AWS部署的集中日志监控
|
||||
- 问题域：跨账户部署跟踪和故障排除
|
||||
- 方法/机制：EventBridge + CloudWatch Logs集中化方案
|
||||
- 结论/价值：实现单一界面监控整个组织的CloudFormation部署
|
||||
|
||||
## Key Claims
|
||||
- CloudFormation StackSets支持跨多账户和区域部署基础设施
|
||||
- 集中日志方案提供单一监控界面
|
||||
- 跨账户事件转发使用EventBridge
|
||||
|
||||
## Key Quotes
|
||||
> "Managing infrastructure across multiple AWS accounts doesn't have to be complex."
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudFormation StackSets]]：跨账户部署模板
|
||||
- [[EventBridge]]：事件驱动架构
|
||||
- [[CloudWatch Logs]]：云日志服务
|
||||
- [[跨账户部署]]：多AWS账户基础设施部署
|
||||
|
||||
## Key Entities
|
||||
- [[AWS Organizations]]：AWS组织
|
||||
- [[KMS]]：Key Management Service
|
||||
|
||||
## Connections
|
||||
- [[CloudFormation StackSets]] ← uses ← [[EventBridge]]
|
||||
- [[CloudFormation StackSets]] ← uses ← [[CloudWatch Logs]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
36
wiki/sources/Install Apache Superset in Docker.md
Normal file
36
wiki/sources/Install Apache Superset in Docker.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Install Apache Superset in Docker"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Install Apache Superset in Docker.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Docker中安装Apache Superset
|
||||
- 问题域：BI平台部署
|
||||
- 方法/机制：Docker容器化部署
|
||||
- 结论/价值：快速部署企业级BI平台
|
||||
|
||||
## Key Claims
|
||||
- 使用Docker镜像部署Superset
|
||||
- 需要初始化数据库和管理员账号
|
||||
- 支持加载示例数据
|
||||
|
||||
## Key Quotes
|
||||
- 无
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker]]：容器化平台
|
||||
- [[Apache Superset]]：开源BI工具
|
||||
|
||||
## Key Entities
|
||||
- [[MySQL]]：数据库
|
||||
|
||||
## Connections
|
||||
- [[Apache Superset]] ← runs_on ← [[Docker]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
38
wiki/sources/Mac-Mini-服务器配置-防止自动锁屏与睡眠.md
Normal file
38
wiki/sources/Mac-Mini-服务器配置-防止自动锁屏与睡眠.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "Mac Mini 服务器配置：防止自动锁屏与睡眠"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Mac-Mini-服务器配置-防止自动锁屏与睡眠.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Mac Mini服务器防睡眠配置
|
||||
- 问题域：远程访问中断
|
||||
- 方法/机制：pmset命令修改电源设置
|
||||
- 结论/价值：实现持续远程访问
|
||||
|
||||
## Key Claims
|
||||
- pmset命令禁止所有睡眠模式
|
||||
- caffeinate工具实现临时唤醒
|
||||
- 支持WOL网络唤醒
|
||||
|
||||
## Key Quotes
|
||||
> "Mac Mini 作为服务器使用时，关闭显示器后会自动锁屏或进入睡眠状态。"
|
||||
|
||||
## Key Concepts
|
||||
- [[pmset]]：电源管理命令
|
||||
- [[WOL]]：网络唤醒
|
||||
- [[caffeinate]]：保持唤醒工具
|
||||
|
||||
## Key Entities
|
||||
- [[Mac Mini]]：苹果迷你主机
|
||||
- [[RustDesk]]：远程桌面软件
|
||||
|
||||
## Connections
|
||||
- [[pmset]] ← controls ← [[Mac Mini睡眠]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Public vs Private vs Hybrid Cloud Differences Explained"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：公有云、私有云、混合云的区别
|
||||
- 问题域：云部署模型选择
|
||||
- 方法/机制：三维度对比分析
|
||||
- 结论/价值：平衡是选择云策略的核心要素
|
||||
|
||||
## Key Claims
|
||||
- 公有云：共享的第三方资源，弹性高，成本低
|
||||
- 私有云：仅供单一组织使用，安全性和控制力强
|
||||
- 混合云：结合两者优势，灵活分配工作负载
|
||||
|
||||
## Key Quotes
|
||||
> "Balance is the driver in architecting your approach to cloud computing."
|
||||
|
||||
## Key Concepts
|
||||
- [[公有云]]：共享基础设施
|
||||
- [[私有云]]：专用环境
|
||||
- [[混合云]]：公私结合
|
||||
- [[SaaS]]：软件即服务
|
||||
- [[IaaS]]：基础设施即服务
|
||||
- [[PaaS]]：平台即服务
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：Amazon Web Services
|
||||
- [[Azure]]：Microsoft Azure
|
||||
- [[Google Cloud]]：GCP
|
||||
|
||||
## Connections
|
||||
- [[混合云]] ← combines ← [[公有云]]
|
||||
- [[混合云]] ← combines ← [[私有云]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "RTO vs RPO Key Differences for Modern Disaster Recovery"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/RTO vs RPO Key Differences for Modern Disaster Recovery.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：RTO和RPO在现代灾难恢复中的差异
|
||||
- 问题域：恢复时间和恢复点的选择
|
||||
- 方法/机制：分层恢复目标策略
|
||||
- 结论/价值：预防优于恢复
|
||||
|
||||
## Key Claims
|
||||
- RTO：系统可容忍的最大停机时间
|
||||
- RPO：可容忍的最大数据丢失量
|
||||
- 功能开关实现秒级恢复
|
||||
|
||||
## Key Quotes
|
||||
> "The best way to reach aggressive RTO and RPO targets isn't building a better disaster recovery plan—it's shipping code that doesn't break in the first place."
|
||||
|
||||
## Key Concepts
|
||||
- [[RTO]]：恢复时间目标
|
||||
- [[RPO]]：恢复点目标
|
||||
- [[功能开关]]：特性标志控制
|
||||
- [[渐进式发布]]：逐步推广
|
||||
|
||||
## Key Entities
|
||||
- [[LaunchDarkly]]：功能管理平台
|
||||
- [[Feature Flags]]：特性标志
|
||||
|
||||
## Connections
|
||||
- [[功能开关]] ← enables ← [[RTO]]
|
||||
- [[功能开关]] ← protects ← [[RPO]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "The Myths and Misconceptions About Cloud Computing"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/The Myths and Misconceptions About Cloud Computing LinkedIn.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：云计算的常见误解与事实
|
||||
- 问题域：安全、成本、控制、数据主权
|
||||
- 方法/机制：逐条反驳云神话
|
||||
- 结论/价值：云提供增强的安全性、成本效益和可扩展性
|
||||
|
||||
## Key Claims
|
||||
- 云安全通常比本地解决方案更强大
|
||||
- 云采用按需付费模式，成本可控
|
||||
- 云适合各种规模的企业
|
||||
|
||||
## Key Quotes
|
||||
> "Cloud computing is often misunderstood due to persistent myths and misconceptions."
|
||||
|
||||
## Key Concepts
|
||||
- [[云安全]]：加密、防火墙、多因素认证
|
||||
- [[按需付费]]：云成本模式
|
||||
- [[SLA]]：服务级别协议
|
||||
|
||||
## Key Entities
|
||||
- [[ISO 27001]]：信息安全管理体系
|
||||
- [[HIPAA]]：健康保险流通与责任法案
|
||||
- [[GDPR]]：通用数据保护条例
|
||||
|
||||
## Connections
|
||||
- [[云安全]] ← complies_with ← [[ISO 27001]]
|
||||
- [[云安全]] ← complies_with ← [[HIPAA]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "These 6 Linux Apps Let You Monitor System Resources in Style"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/These 6 Linux apps let you monitor system resources in style.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：6款Linux系统资源监控工具
|
||||
- 问题域：系统性能监控、进程管理
|
||||
- 方法/机制：TUI和GUI两类工具对比
|
||||
- 结论/value：btop++是最佳TUI选择
|
||||
|
||||
## Key Claims
|
||||
- TUI监控器在SSH远程访问时更高效
|
||||
- btop++提供美观的界面和丰富的功能
|
||||
- Mission Center提供类似Windows任务管理器的体验
|
||||
|
||||
## Key Quotes
|
||||
> "btop++ always gets my vote for its balance between usability and aesthetics."
|
||||
|
||||
## Key Concepts
|
||||
- [[TUI]]：文本用户界面
|
||||
- [[资源监控]]：CPU、内存、网络监控
|
||||
- [[进程管理]]：终止进程、调整优先级
|
||||
|
||||
## Key Entities
|
||||
- [[btop++]]：TUI资源监控器
|
||||
- [[htop]]：轻量级进程监控
|
||||
- [[Glances]]：轻量级系统监控
|
||||
- [[Bottom]]：图表式资源监控
|
||||
- [[Mission Center]]：GUI任务管理器
|
||||
- [[Stacer]]：功能丰富的系统优化工具
|
||||
|
||||
## Connections
|
||||
- [[btop++]] ← replaces ← [[htop]]
|
||||
- [[Mission Center]] ← similar_to ← [[Windows任务管理器]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
41
wiki/sources/Understanding Complete ITSM.md
Normal file
41
wiki/sources/Understanding Complete ITSM.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "Understanding Complete ITSM"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Understanding Complete ITSM.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：现代IT服务管理(ITSM)趋势
|
||||
- 问题域：效率、安全、韧性
|
||||
- 方法/机制：AIOps驱动的问题管理、变更管理
|
||||
- 结论/价值：ITSM是运营卓越的战略推动者
|
||||
|
||||
## Key Claims
|
||||
- AI驱动的异常检测消除重复故障
|
||||
- AIOps转变传统响应模型
|
||||
- 自愈IT生态系统实现自动化修复
|
||||
|
||||
## Key Quotes
|
||||
> "IT Service Management (ITSM) is no longer just about ticketing—it's the strategic enabler of operational excellence."
|
||||
|
||||
## Key Concepts
|
||||
- [[ITSM]]：IT服务管理
|
||||
- [[AIOps]]：AI运维
|
||||
- [[CMDB]]：配置管理数据库
|
||||
- [[IaC]]：基础设施即代码
|
||||
- [[Zero Trust]]：零信任架构
|
||||
|
||||
## Key Entities
|
||||
- [[ServiceNow]]：ITSM平台
|
||||
- [[Jira]]：ITSM工具
|
||||
|
||||
## Connections
|
||||
- [[ITSM]] ← uses ← [[AIOps]]
|
||||
- [[ITSM]] ← integrates ← [[CI/CD]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
41
wiki/sources/What I know about Cloud Service Delivery.md
Normal file
41
wiki/sources/What I know about Cloud Service Delivery.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "What I Know About Cloud Service Delivery"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/What I know about Cloud Service Delivery 1.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：云服务交付的完整生命周期
|
||||
- 问题域：服务配置、监控、安全、成本管理
|
||||
- 方法/机制：12个核心领域的云服务管理
|
||||
- 结论/价值：云服务交付是连接技术与业务价值的桥梁
|
||||
|
||||
## Key Claims
|
||||
- 云服务交付涵盖IaaS、PaaS、SaaS的完整生命周期
|
||||
- 团队包含云基础设施工程师、运维工程师、安全专家
|
||||
- AIOps驱动云DevOps成熟度
|
||||
|
||||
## Key Quotes
|
||||
> "Cloud Service Delivery is the bridge between the raw capabilities of cloud technology and the reliable, secure, performant services that businesses and users actually consume."
|
||||
|
||||
## Key Concepts
|
||||
- [[云服务交付]]：云服务生命周期管理
|
||||
- [[FinOps]]：云财务管理
|
||||
- [[IaC]]：基础设施即代码
|
||||
- [[SLA]]：服务级别协议
|
||||
- [[SLO]]：服务级别目标
|
||||
|
||||
## Key Entities
|
||||
- [[AWS CloudWatch]]：监控工具
|
||||
- [[Grafana]]：可视化监控
|
||||
|
||||
## Connections
|
||||
- [[云服务交付]] ← includes ← [[FinOps]]
|
||||
- [[云服务交付]] ← uses ← [[IaC]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "What is DevSecOps - Best Practices, Benefits, and Tools"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/What is DevSecOps Best Practices, Benefits, and Tools.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：DevSecOps最佳实践与工具
|
||||
- 问题域：安全集成、自动化、合规
|
||||
- 方法/机制：在SDLC每个阶段集成安全
|
||||
- 结论/价值：70%的发布后漏洞可通过DevSecOps防止
|
||||
|
||||
## Key Claims
|
||||
- DevSecOps在开发流程每个阶段集成安全
|
||||
- 自动化安全测试集成到CI/CD管道
|
||||
- 左移安全：早期识别漏洞
|
||||
|
||||
## Key Quotes
|
||||
> "70% of software vulnerabilities discovered post-launch could have been prevented with DevSecOps."
|
||||
|
||||
## Key Concepts
|
||||
- [[DevSecOps]]：开发安全运维
|
||||
- [[CI/CD]]：持续集成/持续交付
|
||||
- [[SAST]]：静态应用安全测试
|
||||
- [[DAST]]：动态应用安全测试
|
||||
- [[SCA]]：软件组成分析
|
||||
|
||||
## Key Entities
|
||||
- [[SonarQube]]：代码质量管理
|
||||
- [[Snyk]]：开源安全扫描
|
||||
- [[Amazon Inspector]]：漏洞扫描
|
||||
|
||||
## Connections
|
||||
- [[DevSecOps]] ← integrates ← [[CI/CD]]
|
||||
- [[DevSecOps]] ← uses ← [[SAST]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Build Your Own X"
|
||||
type: source
|
||||
tags: [build-your-own-x, learning, programming, tutorials]
|
||||
tags: []
|
||||
date: 2026-01-01
|
||||
---
|
||||
|
||||
@@ -9,25 +9,28 @@ date: 2026-01-01
|
||||
- [[raw/AI/codecrafters-iobuild-your-own-x Master programming by recreating your favorite technologies from scratch.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Build Your Own X编程学习资源合集
|
||||
- 问题域：学习编程需要通过实践重建技术来深入理解
|
||||
- 方法/机制：提供分步骤指南，从零开始重建流行技术
|
||||
- 结论/价值：费曼的名言"我不能创造的东西，我就不理解"
|
||||
- 核心主题：codecrafters-io/build-your-own-x 项目——通过从零重建技术来掌握编程
|
||||
- 问题域：如何通过动手重建（Rebuild）而非消费（Consume）来深度理解技术原理
|
||||
- 方法/机制：提供 25 个技术领域的分步指南，每领域多语言实现，覆盖 3D Renderer、Web Server、Database、Git、Neural Network 等
|
||||
- 结论/价值：Richard Feynman 名言"What I cannot create, I do not understand"——重建是理解的最佳路径
|
||||
|
||||
## Key Claims
|
||||
- 涵盖23个技术类别：3D渲染器、AR、BitTorrent、区块链、Bot、CLI工具、数据库、Docker、模拟器、前端框架、游戏、Git、网络栈、神经网络、操作系统、物理引擎、编程语言、正则引擎、搜索引擎、Shell、模板引擎、文本编辑器、视觉识别系统、体素引擎、网页浏览器、网页服务器
|
||||
- 每种技术都提供多种编程语言的教程
|
||||
- 著名引用：Richard Feynman的"我不能创造的东西，我就不理解"
|
||||
- 项目涵盖 25 个技术领域：3D Renderer、Web Server、Database、Git、Blockchain、Bot、Shell、Operating System、Programming Language、Neural Network 等
|
||||
- 每领域提供多种语言实现（如 Redis 可用 C++、Go、C# 等实现）
|
||||
- 代码Crafters 平台（codecrafters.io）提供付费进阶练习
|
||||
- 核心方法论：理解技术的最佳方式是亲手重建它，而非仅阅读文档
|
||||
|
||||
## Key Quotes
|
||||
> "What I cannot create, I do not understand — Richard Feynman." — 核心理念
|
||||
|
||||
## Key Concepts
|
||||
- [[Build Your Own X]]：通过重建技术来学习的编程学习法
|
||||
- [[CodeCrafters]]：提供编程挑战的平台
|
||||
- [[Build-Your-Own-X]]：通过从零重建技术来深度学习和掌握原理的方法论
|
||||
|
||||
## Key Entities
|
||||
- [[CodeCrafters]]：编程学习平台
|
||||
- [[Richard Feynman]]：物理学家名言出处
|
||||
- [[Codecrafters]]：提供 build-your-own-x 实践课程的编程教育平台
|
||||
|
||||
## Connections
|
||||
- [[编程学习]] ← uses ← [[Build Your Own X]]
|
||||
- [[Build-Your-Own-X]] ← hosted_on ← [[Codecrafters]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Designing for Agentic AI"
|
||||
type: source
|
||||
tags: [agentic-ai, product-design, UX]
|
||||
tags: []
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
@@ -9,27 +9,30 @@ date: 2025-03-02
|
||||
- [[raw/AI/Designing for Agentic AI.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Agentic AI产品设计原则
|
||||
- 问题域：AI从被动响应到主动行动的转变
|
||||
- 方法/机制：透明性、控制权、个性化、对话、预判五大设计原则
|
||||
- 结论/价值：Agentic AI需要新的设计范式，强调实时反馈和用户控制
|
||||
- 核心主题：Agentic AI（智能体 AI）的产品设计原则与用户体验范式
|
||||
- 问题域：如何在产品设计中处理主动型 AI Agent 的新交互维度
|
||||
- 方法/机制：五大最佳实践——透明性（Transparency）、控制性（Control）、个性化（Personalization）、对话设计（Conversation）、预判能力（Anticipation）
|
||||
- 结论/价值：Agentic AI 推动产品设计从"响应用户操作"转向"实时反馈 AI 运作过程"，用户通过观察 AI 决策过程实现隐式交互
|
||||
|
||||
## Key Claims
|
||||
- GenAI擅长内容生成，Agentic AI擅长行动执行
|
||||
- Agentic AI引入新维度：主动 agent 预判需求并自主行动
|
||||
- 用户通过观察AI决策过程进行交互，而非传统点击输入
|
||||
- 五大设计原则：透明性、控制权、个性化、对话、预判
|
||||
- GenAI（生成式 AI）擅长创作内容；Agentic AI 擅长行动，能与环境交互、做出决策并预判用户需求
|
||||
- Agentic AI 需要新的设计隐喻：Crafting experiences that provide live feedback as the AI operates
|
||||
- 五大设计原则：透明性（可视化 AI 进度和推理过程）、控制性（停止/撤销能力）、个性化（基于历史行为预测未来需求）、对话设计（自然语言交互）、预判能力（主动提供帮助且用户可调节自主程度）
|
||||
- 用户在 Agentic 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. But agentic AI introduces a new dimension: proactive agents that anticipate needs and act autonomously" — 范式转移
|
||||
|
||||
## Key Concepts
|
||||
- [[GenAI]]：生成式AI，擅长创作内容
|
||||
- [[Agentic AI]]：智能体AI，能够自主行动和决策
|
||||
- [[实时反馈]]：Agentic AI设计中的核心用户体验要素
|
||||
- [[用户控制]]：确保用户对AI行为有最终决定权
|
||||
- [[Agentic AI]]：能够与环境交互、做出决策并预判用户需求的主动型 AI 系统，区别于被动响应的 GenAI
|
||||
- [[透明性设计]]：可视化 AI 决策进度和推理过程，让用户理解并评估 AI 行为
|
||||
- [[控制性设计]]：提供停止 AI 任务和撤销已执行操作的清晰机制
|
||||
|
||||
## Key Entities
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← implements ← [[透明性设计]], [[控制性设计]]
|
||||
- [[Agentic AI]] ← extends ← [[GenAI]]
|
||||
- [[AI产品设计]] ← uses ← [[Agentic AI设计原则]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
@@ -1,43 +1,45 @@
|
||||
---
|
||||
title: "Multi-Agent System Reliability"
|
||||
type: source
|
||||
tags: [multi-agent, reliability, architecture, LLM]
|
||||
date: 2023-01-09
|
||||
tags: []
|
||||
date: 2026-04-13
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Multi-Agent System Reliability.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：多智能体系统可靠性架构模式
|
||||
- 问题域：LLM的不可靠性（幻觉、逻辑谬误、上下文漂移）导致多智能体系统崩溃
|
||||
- 方法/机制：层级、共识、对抗辩论、淘汰制四种架构模式
|
||||
- 结论/价值：将LLM视为分布式系统中不可靠的组件，通过架构设计强制正确性
|
||||
- 核心主题：多智能体系统的四大可靠性架构模式
|
||||
- 问题域：如何克服 LLM 的不可靠性（幻觉、逻辑谬误、上下文漂移）并构建稳健的多智能体系统
|
||||
- 方法/机制：Hierarchy（层级结构）、Consensus（共识投票）、Adversarial Debate（对抗辩论）、Knock-out（淘汰制）四种架构模式
|
||||
- 结论/价值：从"AI Prototype"到"Enterprise AI"的转变关键在于停止将 LLM 视为魔法聊天机器人，开始将其视为分布式系统中不可靠的组件
|
||||
|
||||
## Key Claims
|
||||
- 4种可靠性架构模式：Hierarchy（层级）、Consensus（共识）、Adversarial Debate（对抗辩论）、Knock-out（淘汰制）
|
||||
- 单一模型20%幻觉率下，3个模型共识投票可将谎言概率降至0.8%
|
||||
- 不要将LLM拟人化，它们没有死亡恐惧或同理心
|
||||
- 构建稳健系统需要停止要求模型"小心"，而是强制它正确
|
||||
- LLM 天生不可靠：产生幻觉、逻辑谬误、上下文漂移；将其拟人化是谬误
|
||||
- 层级结构（Hierarchy）：Planner（规划器）分解任务 → Worker（工作者）执行 → Validator（验证器）验证结果
|
||||
- 共识（Consensus）：N 个模型对同一任务独立生成答案，取多数票；3 个模型同时产生相同幻觉的概率仅为 0.8%（0.2³）
|
||||
- 对抗辩论（Adversarial Debate）：Generator 提出方案 → Critic 攻击缺陷 → Judge 裁决，Watchdog 打破死循环
|
||||
- 淘汰制（Knock-out）：N 个 Agent 执行任务，Validator 淘汰最差者；类比 SRE 中服务器是"cattle"而非"pets"
|
||||
- 四种模式均源于人类系统的协作模式：军队（层级）、民主投票（共识）、法庭（辩论）、自然选择（淘汰）
|
||||
|
||||
## Key Quotes
|
||||
> "We don't need AI that 'cares.' We need AI that is constrained, verified, pruned, and challenged."
|
||||
> "Stop treating LLMs like magic chatbots. Start treating them like unreliable components in a distributed system" — 核心转变
|
||||
> "We don't need AI that 'cares.' We need AI that is constrained, verified, pruned, and challenged" — 需求定义
|
||||
> "Don't anthropomorphize LLMs!" — 关键警告
|
||||
|
||||
## Key Concepts
|
||||
- [[层级模式]]：Supervisor规划器分配任务，Worker执行，Validator验证
|
||||
- [[共识模式]]：多数投票机制降低幻觉概率
|
||||
- [[对抗辩论]]：Generator提出，Critic攻击，Judge裁决
|
||||
- [[淘汰制]]：多个agent竞争，验证器淘汰最差者
|
||||
- [[LLM不可靠性]]：幻觉、逻辑谬误、上下文漂移
|
||||
- [[多Agent可靠性模式]]：Hierarchy（层级）、Consensus（共识）、Adversarial Debate（对抗辩论）、Knock-out（淘汰制）
|
||||
- [[LLM不可靠性]]：LLM 固有的幻觉、逻辑谬误和上下文漂移问题
|
||||
- [[验证器模式]]：Validator 通过确定性代码（单元测试、JSON schema）或 LLM 验证输出的机制
|
||||
- [[共识投票]]：N 个独立 LLM 对同一任务生成答案，取多数票降低幻觉概率
|
||||
|
||||
## Key Entities
|
||||
- [[Alex Ewerlöf]]：作者，可靠性工程专家
|
||||
- [[Alex Ewerlöf]]：资深工程师，专注于可靠性工程和弹性架构，自 2023 年专攻 LLM
|
||||
|
||||
## Connections
|
||||
- [[多Agent系统]] ← uses ← [[层级模式]]
|
||||
- [[多Agent系统]] ← uses ← [[共识模式]]
|
||||
- [[多Agent系统]] ← uses ← [[对抗辩论]]
|
||||
- [[多Agent系统]] ← uses ← [[淘汰制]]
|
||||
- [[可靠性工程]] ← applies_to ← [[多Agent系统]]
|
||||
- [[多Agent可靠性模式]] ← resolves ← [[LLM不可靠性]]
|
||||
- [[共识投票]] ← uses ← [[LLM不可靠性]]
|
||||
- [[验证器模式]] ← implements ← [[多Agent可靠性模式]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
@@ -1,28 +1,34 @@
|
||||
---
|
||||
title: "N8N+Claude通过自然语言自动化工作流"
|
||||
title: "n8n+Claude通过自然语言自动化工作流"
|
||||
type: source
|
||||
tags: [n8n, claude, automation]
|
||||
date: 2025-03-06
|
||||
tags: [n8n, Claude, 自动化工作流]
|
||||
date: 2026-03-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/n8n+Claude通过自然语言自动化工作流.md]]
|
||||
- [[raw/Agent/n8n+Claude 通过自然语言自动化工作流.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：使用Claude通过自然语言自动化创建N8N工作流
|
||||
- 问题域：如何让不懂技术的用户也能创建复杂工作流
|
||||
- 方法/机制：通过n8n-mcp实现自然语言到工作流的转换
|
||||
- 结论/价值：AI辅助工作流创建降低门槛，提升效率
|
||||
- 核心主题：n8n与Claude集成通过自然语言自动化工作流
|
||||
- 问题域：Claude Desktop安装、工作流自动化配置
|
||||
- 方法/机制：通过Claude API/Desktop与n8n协同
|
||||
- 结论/价值：（文档为草稿，内容较少）
|
||||
|
||||
## Key Claims
|
||||
- n8n-mcp提供结构化访问543个N8N节点的能力
|
||||
- 87%文档覆盖率，包括AI节点
|
||||
- 支持2个AI-capable节点的完整文档
|
||||
- Claude Desktop下载地址：https://claude.com/download
|
||||
- n8n可与Claude Desktop通过API或本地接口集成
|
||||
|
||||
## Key Concepts
|
||||
- [[自然语言处理]]：将人类语言转换为机器可执行指令
|
||||
- [[工作流生成]]：AI自动创建自动化流程
|
||||
- [[自然语言工作流]]：通过自然语言描述自动生成/执行工作流
|
||||
- [[ClaudeIntegration]]：Claude与n8n的集成机制
|
||||
|
||||
## Key Entities
|
||||
- [[Claude]]：Anthropic大语言模型，n8n集成的AI后端
|
||||
- [[N8N]]：工作流自动化平台
|
||||
|
||||
## Connections
|
||||
- [[Claude]] ← generates ← [[工作流生成]]
|
||||
- [[n8n-mcp]] ← bridges ← [[N8N]]
|
||||
- [[N8N]] ← integrates_with ← [[Claude]] ← via ← API
|
||||
- [[Claude]] ← deployed_as ← [[ClaudeDesktop]]
|
||||
|
||||
## Note
|
||||
文档内容不完整，为草稿状态，仅包含安装指引和目录结构
|
||||
|
||||
@@ -1,28 +1,31 @@
|
||||
---
|
||||
title: "N8N Configure Telegram Trigger"
|
||||
title: "n8n-configure-telegram-trigger"
|
||||
type: source
|
||||
tags: [n8n, telegram, troubleshooting]
|
||||
date: 2025-03-06
|
||||
tags: [n8n, Telegram, 故障排除]
|
||||
date: 2026-03-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/n8n configure telegram trigger.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：解决N8N中Telegram Trigger配置错误问题
|
||||
- 问题域：Telegram Webhook需要HTTPS URL的配置问题
|
||||
- 核心主题：n8n Telegram Trigger节点Webhook配置错误解决
|
||||
- 问题域：本地/无HTTPS的n8n实例无法配置Telegram Webhook
|
||||
- 方法/机制：设置WEBHOOK_URL环境变量为HTTPS地址
|
||||
- 结论/价值：Docker环境下运行N8N需要正确配置WEBHOOK_URL
|
||||
- 结论/价值：Telegram要求Webhook必须为HTTPS URL，本地n8n需配置WEBHOOK_URL环境变量
|
||||
|
||||
## Key Claims
|
||||
- Telegram要求Webhook URL必须为HTTPS
|
||||
- 通过设置WEBHOOK_URL环境变量解决Telegram Trigger报错
|
||||
- Docker中配置：WEBHOOK_URL=https://n8n.cpolar.top
|
||||
- Telegram Webhook必须提供HTTPS URL，HTTP或本地地址会被拒绝
|
||||
- 解决方法是设置WEBHOOK_URL环境变量为有效的HTTPS地址
|
||||
- Docker Desktop中通过环境变量配置：WEBHOOK_URL=https://n8n.cpolar.top
|
||||
|
||||
## Key Concepts
|
||||
- [[Webhook]]：服务器向客户端推送实时事件的技术
|
||||
- [[Telegram Trigger]]：N8N中用于触发工作流的Telegram集成
|
||||
- [[Webhook]]：Telegram与n8n通信的回调机制，必须HTTPS
|
||||
- [[n8nTrigger]]：n8n中触发工作流的事件节点类型
|
||||
|
||||
## Key Entities
|
||||
- [[N8N]]：开源工作流自动化平台
|
||||
- [[Telegram]]：消息平台，Telegram Trigger作为n8n触发器
|
||||
|
||||
## Connections
|
||||
- [[N8N]] ← uses ← [[Telegram Trigger]]
|
||||
- [[Telegram Trigger]] ← requires ← [[Webhook]]
|
||||
- [[N8N]] ← uses ← [[Telegram]] ← via ← [[Webhook]]
|
||||
|
||||
41
wiki/sources/n8n-docker-install-update.md
Normal file
41
wiki/sources/n8n-docker-install-update.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "n8n-docker-install-update"
|
||||
type: source
|
||||
tags: [n8n, Docker, 安装配置]
|
||||
date: 2026-03-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/n8n docker install & update.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：n8n Docker安装、更新及容器内网络代理配置完整指南
|
||||
- 问题域：Ubuntu2服务器上n8n Docker部署、网络代理配置、科学上网
|
||||
- 方法/机制：Dockerfile扩展官方镜像安装curl/wget；docker-compose配置HTTPS环境和SOCKS5代理
|
||||
- 结论/价值：n8n容器化部署的最佳实践配置，容器内流量通过宿主机代理实现科学上网
|
||||
|
||||
## Key Claims
|
||||
- n8n官方镜像通过Dockerfile扩展安装curl和wget工具
|
||||
- WEBHOOK_URL必须设为HTTPS地址，否则Telegram Trigger无法工作
|
||||
- ALL_PROXY=socks5://172.21.0.1:10808使容器内所有HTTP/HTTPS流量走SOCKS5代理
|
||||
- Docker网桥IP需通过docker network inspect确认，172.21.0.1为默认网段
|
||||
- 更新流程：docker compose pull → docker compose down → docker compose up -d
|
||||
|
||||
## Key Quotes
|
||||
> "容器内HTTP/HTTPS流量和n8n请求都会走SOCKS5"
|
||||
> "WEBHOOK_URL=https://n8n.ishenwei.online/" — Telegram Trigger必须
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker容器化]]：n8n部署方式，容器与宿主机网络隔离
|
||||
- [[SOCKS5代理]]：容器内流量通过宿主机代理实现科学上网
|
||||
- [[Webhook]]：n8n对外暴露的回调端点，必须HTTPS
|
||||
- [[n8n环境变量]]：N8N_PROTOCOL、HWEBHOOK_URL、N8N_TRUST_PROXY等关键配置
|
||||
|
||||
## Key Entities
|
||||
- [[N8N]]：开源工作流自动化平台
|
||||
- [[Docker]]：容器化平台，n8n部署环境
|
||||
|
||||
## Connections
|
||||
- [[N8N]] ← deployed_as ← [[Docker容器化]]
|
||||
- [[Docker容器化]] ← network ← [[SOCKS5代理]] ← via ← [[V2Ray]]
|
||||
- [[N8N]] ← requires ← [[Webhook]] ← must_be ← HTTPS
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "N8N Full Tutorial Building AI Agents in 2025"
|
||||
title: "n8n-full-tutorial-building-ai-agents"
|
||||
type: source
|
||||
tags: [n8n, ai-agent, tutorial]
|
||||
tags: [n8n, AI, Agent, 教程]
|
||||
date: 2025-03-06
|
||||
---
|
||||
|
||||
@@ -9,27 +9,32 @@ date: 2025-03-06
|
||||
- [[raw/Agent/n8n full tutorial building AI agents in 2025 for Beginners!.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：使用N8N平台构建AI Agents的完整教程
|
||||
- 问题域：新手如何利用N8N构建自动化工作流和AI Agent
|
||||
- 方法/机制：理解Agentic系统（Agent vs Workflow）、掌握N8N节点类型、管理Memory实现上下文保留
|
||||
- 结论/价值：N8N的视觉化界面降低了自动化工作流创建门槛
|
||||
- 核心主题：n8n平台构建AI Agent入门完整教程
|
||||
- 问题域：n8n基本概念、节点类型、工作流创建、AI Agent内存管理、工具集成
|
||||
- 方法/机制：可视化节点编排、动态工具选择、上下文内存、Airtable数据库集成
|
||||
- 结论/价值：n8n入门指南，Workflow（预定义自动化）与Agent（动态LLM决策）的区别
|
||||
|
||||
## Key Claims
|
||||
- Agentic系统结合了Workflow的可预测性和Agent的灵活性
|
||||
- N8N节点分为五类：触发器、动作节点、工具节点、代码节点、高级AI节点
|
||||
- Memory机制允许Agent保留对话上下文
|
||||
- 外部工具集成（如Airtable）扩展了Agent能力
|
||||
- Agentic系统由Agent和Workflow组成，Agent动态选择工具，Workflow是预定义自动化
|
||||
- n8n节点分五类：trigger（触发器）、action（动作）、utility（工具）、code（代码）、advanced AI（高级AI）
|
||||
- 内存（Memory）使Agent能跨对话保留上下文，提升交互连贯性
|
||||
- Airtable等外部工具集成扩展Agent能力，实现数据库查询和更新
|
||||
- Workflow可链接（chaining）形成复杂自动化，多Agent协同实现高级场景
|
||||
|
||||
## Key Concepts
|
||||
- [[Agentic系统]]：由Agent和Workflow组成的智能系统
|
||||
- [[Workflow]]：预定义的自动化流程
|
||||
- [[N8N节点]]：工作流中的单个操作单元
|
||||
- [[Memory机制]]：Agent保留上下文的能力
|
||||
- [[AgenticAI]]：Agent利用LLM动态决定所需工具和输出的系统
|
||||
- [[n8n节点类型]]：trigger、action、utility、code、advanced AI五类
|
||||
- [[Memory]]：Agent跨会话保留上下文的能力
|
||||
- [[Workflow]]：预定义自动化，产生一致输出
|
||||
- [[ToolIntegration]]：Agent与外部工具（Airtable等）的集成
|
||||
|
||||
## Key Entities
|
||||
- [[N8N]]：开源工作流自动化平台
|
||||
- [[Airtable]]：在线数据库工具
|
||||
- [[N8N]]：开源工作流自动化平台，本教程核心工具
|
||||
- [[Airtable]]：云数据库，作为n8n Agent的工具集成示例
|
||||
- [[LLM]]：大语言模型，Agent动态决策的核心
|
||||
|
||||
## Connections
|
||||
- [[N8N]] ← contains ← [[N8N节点]]
|
||||
- [[N8N]] ← supports ← [[Agentic系统]]
|
||||
- [[N8N]] ← provides ← [[n8n节点类型]] ← composed_into ← [[AgenticAI]]
|
||||
- [[AgenticAI]] ← uses ← [[Memory]] ← enables ← 上下文保留
|
||||
- [[AgenticAI]] ← integrates ← [[Airtable]] ← for ← [[ToolIntegration]]
|
||||
- [[Workflow]] ← composed_into ← [[N8N]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "Never Write Another Prompt"
|
||||
title: "Never write another prompt"
|
||||
type: source
|
||||
tags: [prompt-engineering, AI, tools]
|
||||
tags: []
|
||||
date: 2025-03-06
|
||||
---
|
||||
|
||||
@@ -9,24 +9,28 @@ date: 2025-03-06
|
||||
- [[raw/AI/Never write another prompt.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AI提示词生成工具
|
||||
- 问题域：编写有效提示词复杂且昂贵
|
||||
- 方法/机制：将基础描述转换为详细结构化提示词
|
||||
- 结论/价值：通过工具自动化提示词创建，普通用户也能生成专业级提示词
|
||||
- 核心主题：利用 Prompt 生成工具从简单描述自动创建高质量提示词
|
||||
- 问题域：用户难以写出有效的专业级提示词，导致 AI 输出质量不佳
|
||||
- 方法/机制：输入简单描述 → 工具自动生成结构化、详细的专业提示词 → 保存复用
|
||||
- 结论/价值：提示词工程民主化，普通用户无需成为提示词专家即可获得高质量 AI 输出
|
||||
|
||||
## Key Claims
|
||||
- 工具允许用户从简单描述生成详细提示词，无需专业提示词工程背景
|
||||
- 单个优质提示词服务价格高达100-500美元
|
||||
- 支持变量使用实现高定制化
|
||||
- 可保存提示词供长期使用
|
||||
- Prompt 生成工具将简单描述转化为详细、结构化的专业提示词，无需手工编写
|
||||
- 成本效益显著：专业提示词单次购买价格为 100-500 美元，工具可无限生成
|
||||
- 生成后的提示词支持变量（Variables）插入，便于定制化复用
|
||||
- 生成后的提示词易于编辑，可根据具体场景微调
|
||||
- 提示词库（Prompt Libraries）提供即用型模板，可直接应用于各种 AI 任务
|
||||
|
||||
## Key Quotes
|
||||
> "Prompt engineering is the art of crafting prompts that elicit specific responses from AI. With the introduction of this tool, users no longer need to be experts in this field" — 民主化价值
|
||||
|
||||
## Key Concepts
|
||||
- [[提示词工程]]：编写有效提示词的艺术
|
||||
- [[提示词生成器]]：自动化提示词创建的工具
|
||||
- [[提示词工程民主化]]：通过工具自动生成高质量提示词，降低使用门槛，使非专家用户也能获得专业级 AI 输出
|
||||
|
||||
## Key Entities
|
||||
|
||||
## Connections
|
||||
- [[AI工具]] ← uses ← [[提示词生成器]]
|
||||
- [[提示词工程民主化]] ← enables ← [[提示词框架]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
37
wiki/sources/phone-based-personal-assistant.md
Normal file
37
wiki/sources/phone-based-personal-assistant.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "phone-based-personal-assistant"
|
||||
type: source
|
||||
tags: [OpenClaw, 电话, 语音助手, 用例]
|
||||
date: 2026-03-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/phone-based-personal-assistant.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：通过电话与AI Agent进行语音交互的解决方案
|
||||
- 问题域：无智能手机或无法使用浏览器时的语音AI访问需求；驾驶/步行时免手操作
|
||||
- 方法/机制：ClawdTalk将任意电话变为OpenClaw的语音网关，通过Telnyx实现电话连通性
|
||||
- 结论/价值：扩展OpenClaw能力边界，实现电话语音交互，支持日历查询、Jira更新、网络搜索
|
||||
|
||||
## Key Claims
|
||||
- ClawdTalk使OpenClaw能接收和拨打电话，将任意电话变为AI助手入口
|
||||
- 通过电话可获取日历提醒、Jira更新、网络搜索结果（语音播报）
|
||||
- 短信支持即将推出
|
||||
- 依赖Telnyx提供可靠的电话连通性
|
||||
|
||||
## Key Concepts
|
||||
- [[语音助手]]：通过语音与AI交互，无需屏幕或键盘
|
||||
- [[电话网关]]：电话作为AI系统的入口媒介
|
||||
- [[免手操作]]：驾驶或手忙时的语音优先交互模式
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：AI Agent框架，本用例核心平台
|
||||
- [[ClawdTalk]]：OpenClaw电话集成工具，使Agent可接收/拨打电话
|
||||
- [[Telnyx]]：电话API提供商，提供电话连通性
|
||||
- [[GoogleCalendar]]：日历技能，电话查询日历事件的支撑
|
||||
- [[Jira]]：项目管理工具集成
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] ← extended_by ← [[ClawdTalk]] ← uses ← [[Telnyx]]
|
||||
- [[ClawdTalk]] ← integrates ← [[语音助手]] ← provides ← 日历查询、Jira更新、搜索
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "The Picture They Paint of You"
|
||||
type: source
|
||||
tags: [AI-SRE, coding-assistant, AI产品定位]
|
||||
tags: []
|
||||
date: 2026-04-13
|
||||
---
|
||||
|
||||
@@ -9,32 +9,32 @@ date: 2026-04-13
|
||||
- [[raw/AI/The Picture They Paint of You.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：AI产品命名和定位反映对人类工作的认知
|
||||
- 问题域：AI SRE被定位为替代者，编码助手被定位为合作伙伴
|
||||
- 方法/机制：对比分析AI SRE和编码助手产品的营销框架
|
||||
- 结论/价值：产品命名和定位暴露了开发者对不同角色价值认知的差异
|
||||
- 核心主题：AI 工具的命名和框架化如何反映和塑造对人类工作的认知
|
||||
- 问题域：AI SRE 被定位为替代者，而编码助手被定位为协作者——这种差异揭示了什么
|
||||
- 方法/机制：对比分析各类 AI SRE 产品（替代性框架）与编码助手产品（协作性框架）的命名和营销语言
|
||||
- 结论/价值：工具的命名和定位框架反映的是买卖双方对工作价值的认知，而非工作本身的客观价值；泰勒主义正在渗透软件工程领域
|
||||
|
||||
## Key Claims
|
||||
- AI SRE产品：将工作定位为低地位、可替代的，强调消除"救火"工作
|
||||
- 编码助手产品：强调增强工程师能力、合作伙伴关系
|
||||
- 产品定位反映买卖双方对工作价值的认知差异
|
||||
- 泰勒主义软件工厂框架正在取代软件工程师与自动化的伙伴关系
|
||||
- AI SRE 产品普遍使用替代性框架：强调消除人工（"不需要睡觉的 SRE"、"处理繁重工作"），命名多为角色本身（AI SRE、AlertD）
|
||||
- 编码助手产品使用协作性框架：命名多为人名或伙伴角色（Claude Code、Copilot、Cline），强调增强而非替代
|
||||
- 这种差异揭示：SRE 工作在企业内部被视为低价值/干扰性工作，而软件工程被视为高价值工作
|
||||
- 类比秘书被拟人化为 AI 助手：工具的构建方式暴露了构建者对某些工作价值的看法
|
||||
- 泰勒主义渗透软件工程：Software Factory 框架将人定位为高层控制者，周围是大规模无面孔 Agent
|
||||
|
||||
## Key Quotes
|
||||
> "Software Engineering work is perceived as valuable work... The AI exists to be a partner, a teammate, or an assistant."
|
||||
> "Software Reliability Engineering work is a hindrance... The AI exists to replace or be a substitute to the worker."
|
||||
> "The picture they paint of you says a lot. Just not about you" — 核心论点
|
||||
> "We keep being told it has never been cheaper, easier, or more accessible to create new stuff. This should give everyone involved more time to explore the problem space and learn. Yet here we are" — 对泰勒主义的批评
|
||||
|
||||
## Key Concepts
|
||||
- [[AI SRE]]：站点可靠性工程的人工智能替代方案
|
||||
- [[编码助手]]：增强工程师能力的AI工具
|
||||
- [[泰勒主义]]：科学管理理论，用于描述现代AI工作框架
|
||||
- [[拟人化]]：给AI组件命名导致的认知偏差
|
||||
- [[泰勒主义软件工厂]]：将开发者定位为高层控制者，周围是大规模可替换 Agent 的架构思维
|
||||
- [[AI拟人化谬误]]：将 LLM 拟人化（赋予名字、情感、恐惧）是一种设计谬误，忽视了人类与 LLM 的本质差异
|
||||
|
||||
## Key Entities
|
||||
- [[Ferdinand]]（作者）：长期关注软件工程和 AI 的研究者，作品涵盖《找乐子》等技术博客
|
||||
|
||||
## Connections
|
||||
- [[AI产品定位]] ← reflects ← [[工作价值认知]]
|
||||
- [[编码助手]] ← positioned_as ← [[合作伙伴]]
|
||||
- [[AI SRE]] ← positioned_as ← [[替代者]]
|
||||
- [[泰勒主义软件工厂]] ← critiques ← [[AI拟人化谬误]]
|
||||
- [[多Agent系统]] ← implements ← [[泰勒主义软件工厂]]
|
||||
|
||||
## Contradictions
|
||||
- 与某些 AI 助手定位冲突：本文认为将 Agent 命名和拟人化会强化对工作的错误认知
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "How to Get the RSS Feed For Any YouTube Channel"
|
||||
type: source
|
||||
tags: [youtube, RSS, automation]
|
||||
tags: []
|
||||
date: 2025-10-10
|
||||
---
|
||||
|
||||
@@ -9,24 +9,27 @@ date: 2025-10-10
|
||||
- [[raw/AI/How to Get the RSS Feed For Any YouTube Channel.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：获取YouTube频道RSS订阅源的方法
|
||||
- 问题域：YouTube移除了页面上的RSS订阅按钮
|
||||
- 方法/机制：通过查看页面源代码找到channel_id
|
||||
- 结论/价值：在RSS阅读器中统一接收订阅内容
|
||||
- 核心主题：获取任意 YouTube 频道 RSS 订阅源的方法
|
||||
- 问题域：YouTube 关闭官方 RSS 订阅按钮后如何继续通过 RSS 阅读器获取频道更新
|
||||
- 方法/机制：通过"查看页面源码"（View Page Source）找到 channel_id，拼接 RSS Feed URL
|
||||
- 结论/价值：无需注册任何第三方服务，直接利用 YouTube 页面源码获取真实 RSS 链接
|
||||
|
||||
## Key Claims
|
||||
- 访问YouTube频道页面，右键查看页面源代码
|
||||
- 在源代码中搜索"channel_id="
|
||||
- 找到格式为https://www.youtube.com/feeds/videos.xml?channel_id=的RSS链接
|
||||
- 复制到RSS阅读器订阅
|
||||
- YouTube 已移除频道页面的 RSS 订阅按钮，用户无法直接获取 RSS 链接
|
||||
- 获取方法：访问频道页面 → 右键查看页面源码 → 搜索 "channel_id=" → 拼接完整 RSS URL
|
||||
- RSS Feed URL 格式：https://www.youtube.com/feeds/videos.xml?channel_id=<CHANNEL_ID>
|
||||
- 此方法无需注册任何第三方服务，纯原生操作
|
||||
|
||||
## Key Quotes
|
||||
> "Back in the day, the RSS subscribe button was prominently displayed on every YouTube account. But that meant users could access YouTube content without visiting the website which negatively effects YouTube's bottom line, so it was removed" — RSS 按钮被移除的原因
|
||||
|
||||
## Key Concepts
|
||||
- [[RSS订阅]]：将YouTube频道内容聚合到阅读器
|
||||
- [[YouTube RSS]]：通过channel_id获取频道订阅源
|
||||
- [[YouTube RSS]]：通过 channel_id 拼接的 YouTube 视频 Atom/RSS 订阅格式
|
||||
|
||||
## Key Entities
|
||||
|
||||
## Connections
|
||||
- [[YouTube]] ← provides ← [[RSS订阅]]
|
||||
- [[YouTube RSS]] ← obtained_by ← [[View Page Source]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
43
wiki/sources/可自动化、可扩展、AI增强的电商数据采集与处理系统.md
Normal file
43
wiki/sources/可自动化、可扩展、AI增强的电商数据采集与处理系统.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "可自动化、可扩展、AI增强的电商数据采集与处理系统"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/可自动化、可扩展、AI增强的电商数据采集与处理系统.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Docker+n8n构建电商数据采集处理系统
|
||||
- 问题域：数据爬取、AI处理、自动化管道
|
||||
- 方法/机制：Scrapy+Playwright爬虫+n8n工作流+LLM处理
|
||||
- 结论/价值：实现全自动电商数据采集与分析
|
||||
|
||||
## Key Claims
|
||||
- 三层架构：采集层、处理层、存储展示层
|
||||
- Scrapy+Playwright组合适合动态页面爬取
|
||||
- n8n实现自动化工作流
|
||||
|
||||
## Key Quotes
|
||||
> "在 Ubuntu 上使用 Docker Compose 部署一个自动化电商爬虫系统。"
|
||||
|
||||
## Key Concepts
|
||||
- [[Scrapy]]：Python爬虫框架
|
||||
- [[Playwright]]：浏览器自动化
|
||||
- [[n8n]]：工作流自动化
|
||||
- [[Docker Composer]]：容器编排
|
||||
- [[LLM]]：大语言模型
|
||||
|
||||
## Key Entities
|
||||
- [[PostgreSQL]]：数据库
|
||||
- [[MinIO]]：对象存储
|
||||
- [[Grafana]]：可视化
|
||||
- [[Ollama]]：本地LLM
|
||||
|
||||
## Connections
|
||||
- [[Scrapy]] ← uses ← [[Playwright]]
|
||||
- [[n8n]] ← integrates ← [[LLM]]
|
||||
|
||||
## Contradictions
|
||||
- 无
|
||||
Reference in New Issue
Block a user