569 lines
170 KiB
Markdown
569 lines
170 KiB
Markdown
# Overview
|
||
|
||
This wiki is a living synthesis of curated sources spanning AI agents, cloud infrastructure, DevOps, productivity tools, and home server automation.
|
||
|
||
## Major Themes
|
||
|
||
### Multi-Agent AI Systems
|
||
The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents) and **OpenClaw**. The Agency provides 147 specialized agents across 12 business divisions (Engineering, Design, Finance, Game Dev, Marketing, Paid Media, Product, Project Management, Testing, Support, Spatial Computing, Specialized). OpenClaw focuses on autonomous agents with persistent memory and workflow orchestration via n8n.
|
||
|
||
**[[multi-channel-assistant]]**:基于 [[OpenClaw]] 的多渠道个人助理方案——以 Telegram Topic 路由为统一入口,整合 Google Workspace(gog)、Slack、Todoist、Asana,实现"说一句话完成全套工作"。核心价值:消除应用切换疲劳,AI 主动推送定时提醒(如每周垃圾清理、公司周报)。
|
||
|
||
**[[phone-based-personal-assistant]]**:通过 ClawdTalk + Telnyx 将任意手机变成 AI 助理语音入口——拨打电话即可与 [[OpenClaw]] 对话,支持日历查询、Jira 任务更新、网络搜索等技能,无需智能手机 App 或浏览器,覆盖驾驶、步行等双手占用场景。与 [[multi-channel-assistant]] 互补:文字入口覆盖图文交互,语音入口覆盖无屏场景。
|
||
|
||
**[[phone-call-notifications]]**:AI Agent 通过 [[clawr.ing]] 托管电话服务主动向用户拨打电话通知——Agent 评估事件优先级(股价暴跌/紧急邮件/日程提醒),自动拨叫用户真实号码,用户接听后可实时提问,Agent 双向对话响应。与 [[phone-based-personal-assistant]] 互补:后者为用户→Agent 的来电接收(用户主动呼叫),前者为 Agent→用户的去电通知(Agent 主动呼叫),共同构成完整语音双向通信能力。覆盖 100+ 国家 PSTN 电话,不存储录音,加密传输后即时销毁。
|
||
|
||
**[[multi-channel-customer-service]]**:基于 [[OpenClaw]] 的企业级多渠道 AI 客服统一收件箱——整合 WhatsApp Business、Instagram DMs、Gmail 和 Google Reviews 至单一 AI 驱动的收件箱,AI 自动识别消息意图(FAQ/Appointment/Complaint/Review)并匹配对应处理策略,语言自动检测匹配客户语言(ES/EN/UA),支持 Test Mode 演示而不影响真实客户。餐厅实测响应时间从 4+ 小时降至 2 分钟以内,80% 咨询自动处理。与 [[multi-channel-assistant]] 互补——后者面向个人助理多渠道入口,前者面向企业客服场景。
|
||
|
||
**Inbox De-clutter**:基于 [[OpenClaw]] 的 Newsletter 自动整理方案——每天 20:00 通过 Cron Job 阅读过去 24 小时的新邮件,生成精华摘要并附原文链接,根据用户反馈持续学习偏好。需前置 Gmail OAuth Setup。与 [[custom-morning-brief]] 属同一 Cron Job + AI 摘要模式的 Newsletter 垂直场景。与 [[email-triage]] 属同一方法论的不同实现。
|
||
|
||
**[[Second Brain]]**:基于 [[OpenClaw]] 的个人第二大脑记忆捕获系统——通过短信/Telegram/Discord 零摩擦捕获任何内容(\"Remind me to read a book...\"),OpenClaw 永久记忆存储所有对话,Next.js 可搜索仪表盘提供全局检索,Cmd+K 跨所有记忆/文档/任务全局搜索。核心价值:**捕获像发短信一样简单,检索像搜索一样简单**。无需文件夹、无需标签、无需复杂组织——文本加搜索足矣。OpenClaw 的累积记忆系统使 AI 随时间变得越来越强大,用户从手机发消息就能在电脑端构建内容。灵感来源:Alex Finn 的 YouTube 视频、Tiago Forte 的《Building a Second Brain》。
|
||
|
||
**Self-Improving 自改进系统**([[养虾日记2]]):解决 AI Agent"每次对话都是白纸"的核心问题——三层记忆架构(短期文件 + 长期向量数据库 + self-improving 复盘)配合每日 23:00 定时复盘,实现"错误只犯一次"的 Agent 学习闭环。Pattern-Key 重复是系统性问题的信号;Recurrence-Count 是区分一次性错误与重复问题的关键指标。[[Self-Improving-Skill]] 的 Suggested Action 必须具体到可直接执行(如 `--to 5038825565`),而非泛泛建议。
|
||
|
||
**[[养虾日记3]]**:用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统——解决"AI 对话结束输出就消失"的核心问题。核心架构:**Obsidian 做知识库**(iCloud Drive 三端同步)、**Gitea 做版本控制**(完整保留所有历史版本)、**OpenClaw obsidian skill 做写入接口**。三个 Agent(星枢/星辉/星曜)分别向各自 Obsidian 目录写入,knowledgebase/ 存放跨 Agent 共用知识,<agentId>/ 存放单一 Agent 私有笔记。核心价值:把 AI 变成"会自动整理笔记的实习生"——做完事顺手更新记录。与 [[Second Brain]](对话记忆)、[[Personal Knowledge Base (RAG)]](知识检索)同属持久化记忆能力的不同实现。与 [[self-healing-home-server]] 的 Morning Briefing 共享同一笔记更新机制。融合了 Karpathy 的 LLM Wiki 理念:让 AI 增量构建 Wiki,页面间互链,知识越积越厚。与 [[养虾日记1]](照片整理)、[[养虾日记2]](Self-Improving)、**[[养龙虾5天血泪史]]**(记忆调试)属同一「养虾日记」系列。
|
||
|
||
**[[养龙虾5天血泪史]]**:AI Agent 记忆失效问题的专项调试全记录——作者(比利哥)花费 5 天时间系统修复 OpenClaw 助理"星辉"的失忆问题。发现 5 类根本原因:①上下文压缩导致细节丢失(姓名/数字/决定)→ 配置 `memoryFlush` 在压缩前写入磁盘;②纯语义搜索在专有名词上失败 → 切换到 QMD 混合搜索(BM25+向量+重排);③Agent 找到但不自动使用信息 → 启动序列强制触发检索;④多次压缩后上下文仍丢失 → 配置 `contextPruning` 协同工作;⑤系统提示词膨胀 28% → 全面清理未使用技能和无效文件。**10 条黄金法则**:只有 7 个自动加载文件(AGENTS/SOUL/TOOLS/IDENTITY/USER/HEARTBEAT/MEMORY);启动序列必须放在 AGENTS.md 最顶部;**写入纪律比读取纪律更重要**;交接协议是模型切换修复的关键;定期运行 `/context detail` 检测 token 消耗。核心洞察:**压缩不是敌人,未写入的上下文才是**;系统提示词中每个令牌都是代理携带的开销。最终将系统提示词从 209,652 精简到 9,349 令牌,减少 28%。与 [[养虾日记1]](照片整理)、[[养虾日记2]](Self-Improving)属同一「养虾日记」系列,从不同角度解决 OpenClaw 的记忆与持久化问题。
|
||
|
||
**[[养虾日记5]]**:用AI蒸馏历史人物思维框架创建"数字导师"——以苏东坡为首位实践,展示如何将千年前古人的心智模型(六道:进退由时/此心安处/辞达而已/逆境转化/自出新意/天人合一)转化为可运行的AI Skill。女娲·Skill造人术通过6个并行Agent从6个维度(著作/对话/表达DNA/他者视角/决策/时间线)采集信息,提炼心智模型、决策启发式和表达DNA,产出自包含的.skill文件。核心洞察:AI时代用AI放大人类历史上最强大的脑子——学投资蒸馏芒格,学物理思维蒸馏费曼,逆境中保持风骨蒸馏苏东坡。与 [[养虾日记1/2/3/4]] 和 [[养龙虾5天血泪史]] 属同一「养虾日记」系列,从"AI数字导师"新角度扩展了 OpenClaw 的使用场景。与 [[Second Brain]](对话记忆捕获)、[[思维蒸馏(女娲造人术)]] 同属用AI构建外部认知能力的不同路径。
|
||
|
||
**Recursive Self-Optimizing Generative Systems**([[a-formalization-of-recursive-self-optimizing-generative-systems]]):递归自我优化生成系统的形式化理论模型——将 [[养虾日记2]] 中 Self-Improving 的实践经验抽象为严格数学框架:系统目标不是直接产出最优输出,而是通过迭代自我修改构建稳定的生成能力 $G^*$。定义生成器空间 $\mathcal{G}$ → 优化算子 $O$ → 元生成算子 $M$ → 自映射 $\Phi$ → 稳定不动点 $G^*$,最终用 λ-calculus Y 组合子表达自引用结构 $G^* \equiv Y\;\text{STEP}$。核心发现:**递归自我优化自然涌现不动点结构**——当 $\Phi$ 满足收缩性条件时,$G^* = \lim_{n \to \infty} \Phi^n(G_0)$。该框架为 [[Self-Improving-Skill]] 和所有自我改进 AI 架构提供了原则性理论基础。
|
||
|
||
**[[multi-agent-system-reliability]]**(Alex Ewerlöf):多智能体系统可靠性的架构模式理论——反对拟人化LLM,主张将LLM视为分布式系统中不可靠的组件。核心4模式:[[Hierarchy-Agent-Pattern]](主管→工作→验证链)、[[Consensus-Voting-Pattern]](N个LLM多数票消除幻觉)、[[Adversarial-Debate-Pattern]](Generator→Critic→Judge对抗辩论)、[[Knock-out-Pattern]](适者生存淘汰制)。核心洞察:不应要求模型"小心",而应**强制**其正确——通过架构约束而非提示词约束。与 [[Designing for Agentic AI]] 互补(架构 vs 用户体验),与 [[Recursive Self-Optimization]] 共享自引用结构思想。与 [[Genetic-Algorithm]](遗传算法)有关联——Knock-out/Tree of Thoughts 是 GA 的精简实现。
|
||
|
||
Key concepts: [[Recursive Self-Optimization]], [[Generator Space]], [[Self-Referential Computation]], [[Fixed-Point Semantics]], [[Y-Combinator]], [[Self-Improving AI]], [[Automated Prompt Engineering]], [[Email Triage]], [[Newsletter Digest]], [[Preference Learning]], [[Cron Job]], [[Multi-Agent Coordination]], [[Multi-Tool Integration]], [[MCP Tool Interface Design]], [[Workflow Architecture]], [[Shared Memory Architecture]], [[Private Context]], [[Single Control Plane]], [[Scheduled Task Flywheel]], [[Parallel Agent Execution]], [[Topic-Based Routing]], [[Voice Interface]], [[Telephony Integration]], [[Voice Notification Channel]], [[Two-Way Voice Conversation]], [[Call-Worthy Threshold]], [[PSTN Calling]], [[PM Delegation Pattern]], [[CEO Pattern]], [[Shared State Coordination]], [[Git-as-Audit-Log]], [[Dynamic-Dashboard]], [[Alerting]], [[Zero-Friction Capture]], [[Cumulative Memory]], [[Conversational Interface]], [[Text-and-Search]], [[Unified-Inbox]], [[Intent-Classification]], [[Human-Handoff]], [[Test-Mode]], [[Business-Knowledge-Base]], [[Language-Detection]], [[AI-Auto-Response]], [[Heartbeat-Monitoring]], [[Self-Improving-Skill]], [[双层记忆架构]], [[每日复盘机制]], [[Pattern-Key]], [[Recurrence-Count]], [[Self-Improvement-Log]], [[AI-Agent思维方式]], [[批次任务拆分]], [[精确去重]], [[小文件清理]], [[安全删除策略]], [[Telegram通知]], [[Context-Window]], [[Model-Fallback]], [[Compaction]], [[Agent-Routing-Rules]], [[Error-Surface-vs-Root-Cause]], [[Layered-Configuration]], [[Log-Driven-Debugging]], [[Hidden-Failure-Paths]], [[Large Language Model]], [[RAG]], [[AI Agent]], [[ReAct Pattern]], [[Hierarchy-Agent-Pattern]], [[Consensus-Voting-Pattern]], [[Adversarial-Debate-Pattern]], [[Knock-out-Pattern]], [[Tree-of-Thoughts]], [[Genetic-Algorithm]], [[Reliability-Engineering]]
|
||
|
||
### Multi-Agent Monitoring & Automation
|
||
**Dynamic Dashboard**:基于 [[OpenClaw]] 的多数据源实时监控仪表盘——通过子代理并行抓取 GitHub/Twitter/Polymarket/系统健康等多数据源,定时聚合结果推送 Discord,支持告警阈值和历史趋势存储。用对话式指令替代数周前端开发,立即获得实时洞察。[[polymarket-autopilot]] 是 Polymarket 市场监控的具体实现——AI Agent 24/7 自动监控预测市场、分析概率变化、自动执行交易策略。与 [[self-healing-home-server]] 的系统监控场景关联,[[earnings-tracker]] 的市场数据监控场景扩展,[[content-factory]] 共享子代理并行执行模式。
|
||
|
||
**[[multi-source-tech-news-digest]]**:AI Agent 驱动的多源科技新闻自动聚合与投递系统——四层数据管道整合 46 个 RSS 源、44 个 Twitter/X KOL 账号、19 个 GitHub Releases 仓库和 4 个 Brave Search 主题,覆盖 109+ 信息源;通过标题相似度去重和多维度质量评分(priority source +3, multi-source +5, recency +2, engagement +1)生成精选简报;支持 Discord/Email/Telegram 三通道投递,30 秒内通过自然语言添加自定义来源。属 [[Daily-YouTube-Digest]] / [[Daily Reddit Digest]] 同款 Cron Job + AI 摘要模式的不同垂直场景(前者视频,后者 Reddit 社区,本方案文字新闻)。
|
||
|
||
### Cloud Transformation & DevOps
|
||
Git 是云转型计划中 DevOps 与 CI/CD 流水线的基础技能。**[[ctp-topic-2-git]]**(CTP Topic 2)作为 CI/CD/GitOps 系列的开篇,涵盖 Git 版本控制系统基础概念与实践,与 [[ctp-topic-9-ci-cd-with-gruntwork]](Gruntwork CI/CD)和 [[ctp-topic-33-an-introduction-to-gitops]](GitOps 入门)构成完整的学习链路。**[[ctp-topic-3-deploy-and-maintain-infrastructure]]**(CTP Topic 3)深入 Landing Zone 环境下的基础设施部署方法论——核心区分:Service Module(业务视角,满足业务需求的一组模块组合)与 Regular Module(技术视角,单一技术构建块);Terragrunt HCL 文件通过版本锁定而非 master 分支引用模块;Service Catalog 支持三级复用(单账户→产品团队→跨团队)。类 OO 继承原则:抽象层次越高,配置选项越少。Terragrunt 在运行前预取所有依赖,通过缓存目录管理克隆仓库。属 IaC 模块化治理的基础原则层,与 [[ctp-topic-9-ci-cd-with-gruntwork]](CI/CD 实践)和 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]](Atlantis 工具)共同构成完整的 IaC 知识链路。注意:[[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 提到 Atlantis 当前不支持 EKS 部署,两者存在实践约束差异,需通过 Jenkins + Terragrunt 替代。
|
||
|
||
**[[ctp-topic-9-ci-cd-with-gruntwork]]**(CTP Topic 9)聚焦 CI/CD 与 Gruntwork 在 AWS Landing Zone 中的实践,基于 Gruntwork 参考架构通过 Terraform/Terragrunt 实现基础设施自动化交付(⚠️ 视频待 Whisper 转录后补充详细内容)。
|
||
|
||
Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Terraform, GitOps, FinOps, observability, security, and enterprise architecture. Key themes: 3 Lines of Defence framework, ITSM, container hardening, backup & DR strategies. DevOps culture focuses on four pillars: Collaboration, Automation (CI/CD, IaC), Continuous Improvement (Kaizen), and Customer-Centricity. Agile practices (Scrum, Kanban) are symbiotic with DevOps. Emerging trends: DevSecOps, GitOps, Serverless DevOps, AI/ML-driven automation, and Edge Computing DevOps.
|
||
|
||
**[[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]**(CTP Topic 32):Atlantis 替代 Jenkins 用于 Terraform IaC 部署——针对当前 Jenkins 流水线初始化慢(多次代码克隆/顺序测试/ECS 预配置)和架构复杂(持续叠加功能导致脆弱)的双重痛点,Atlantis 提供 PR 评论式协作模型,开发者直接在 GitHub PR 上评论 `atlantis plan`/`apply` 即可触发变更,无需独立账号;每个 Landing Zone 共享账户部署单台 EC2 实例,通过 GitHub Enterprise Webhook 接收通知,服务账号负责评论/合并/关闭 PR;跨账户访问通过在各账户部署的 IAM 角色实现;并行构建支持多模块并发 plan/apply;锁定机制防止多 PR 同时操作同一模块产生冲突。Atlantis 在 merge 前即应用变更,确保代码与基础设施始终同步。属 [[GitOps]] 工具实践层,与 [[ctp-topic-33-an-introduction-to-gitops]](GitOps 概念)和 [[ctp-topic-9-ci-cd-with-gruntwork]](Gruntwork CI/CD)共同构成完整链路。注意:[[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 提到 Atlantis 当前不支持 EKS 部署,两者存在实践约束差异。
|
||
|
||
**[[ctp-topic-33-an-introduction-to-gitops]]**(CTP Topic 33):Victor Etkin 讲解 GitOps 方法论入门——GitOps 将软件开发原则应用于部署流程,解决部署失败和配置不一致问题。四大原则:声明式配置、版本控制、CD 流程分离、自修复协调器;核心工具仅需 Git。GitOps Controller 持续比对 Git 声明的期望状态与系统实际状态,自动调和偏差。Pull 模型(代理同时监控 Git 和目标系统)比 Push 模型安全性更高,是 GitOps 推荐模式。CI 专注代码构建和分析,CD 专注二进制部署,两者解耦增强安全性。幂等平台(如 Kubernetes)是 CD 流程顺利运行的必要条件。Git 提交日志天然构成合规审计追踪。属 [[GitOps]] 概念层核心来源,与 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]](Atlantis 工具)和 [[ctp-topic-2-git]](Git 基础)共同构成 CI/CD/GitOps 完整知识链路。
|
||
|
||
**[[ctp-topic-56-automated-infrastructure-testing]]**(CTP Topic 56):Mark Francis 主讲自动化基础设施测试——将软件测试原则应用于 Terraform IaC 代码,通过 TerraTest(Golang 框架)实现 apply → test → destroy 自动化验证循环。核心主张:集成测试超越语法检查,验证实际部署行为是否符合预期;倡导测试驱动开发(TDD)应用于 IaC 领域,先写测试再实现功能;提议将测试编写作为基础设施开发的首要步骤,移除手动验证,追求自动化验证套件和更高的部署信心。核心价值观:"让机器做重复的事,把人脑留给复杂的人类问题"。属 [[GitOps]] 和 [[CI/CD Pipeline]] 的质量保障层,与 [[ctp-topic-33-an-introduction-to-gitops]](GitOps 概念)和 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]](Atlantis 工具)共同构成完整的 IaC 质量保障链路。
|
||
|
||
**[[ctp-topic-21-supply-chain-security-in-micro-focus]]**(CTP Topic 21):
|
||
|
||
**[[ctp-topic-24-micro-focus-product-privacy-framework]]**(CTP Topic 24):Micro Focus 产品隐私框架在云转型中的应用——PSAC(产品安全顾问委员会)与法律顾问合作,将 GDPR/CCPA 等晦涩法律条款翻译为约 110 项低级别技术要求;隐私框架是 STLC(安全开发生命周期)中 13 个安全与隐私轨道之一;通过五类需求(架构类/文档类/法律类/实现类/SAS 运营类)和成熟度模型(0-4 级)评估产品隐私合规状态;通过"蜘蛛图"直观展示产品在安全去标识化、被遗忘权、数据可移植性等 KPI 上的合规现状;最终产出标准化《产品隐私设置文档》,确保客户获得一致的隐私信息参考。属 [[Product Privacy Framework(产品隐私框架)]] 在 [[Micro Focus]] 云转型场景的核心实践,与 [[Micro Focus Security Development Life Cycle (STLC) Overview]](STLC 整体架构)直接关联。
|
||
|
||
**[[ctp-topic-49-container-lifecycle-hardening-standards]]**(CTP Topic 49):
|
||
|
||
**[[public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w]]**(Public Cloud Learning Sessions,EKS 计算优化专题 Part 2):Bottlerocket OS(火箭瓶)深度解析——AWS 专为容器工作负载优化的最小化开源 Linux 发行版,核心设计理念:最小化(去除包管理器/Shell/SSH,仅打包必要内核组件)、安全更新(分区镜像 A/B 切换确保原子性)、安全加固(dm-verity 根文件系统加密验证 + SE Linux enforcing 模式 + 根文件系统默认只读)。Variant 机制通过平台+架构+工作负载组件组合在构建时定制功能,支持 Bottlerocket for EKS AMI(自管理节点组)、托管节点组(Managed Node Groups)和 Carpenter 节点池三种集成方式。属 [[Bottlerocket]] 在 [[Amazon EKS]] 场景的核心实践,与 Part 1(Karpenter 计算优化)和 Part 3(EKS Auto Mode)共同构成 EKS 优化三专题完整链路;Part 3 的 EKS Auto Mode 默认使用 Bottlerocket 作为节点操作系统。
|
||
|
||
**[[ctp-topic-67-cloud-native-observability-using-opentelemetry]]**(CTP Topic 67):AWS 解决方案架构师 Surav 分享的 EKS/ECS 云原生可观测性深度实践——核心主题:可观测性三信号模型(Traces/Metrics/Logs)、OpenTelemetry Collector 架构(Receivers → Processors → Exporters)、ADOT(AWS Distro for OpenTelemetry)的多种 EKS/ECS 部署模式(Sidecar/独立任务/DaemonSet/HA Replicas)。核心观点:**构建可观测的应用是开发者的责任**——开发者需主动在代码中植入观测能力;Trace 捕获应用调用栈各层的处理耗时,是性能瓶颈定位的核心手段;Correlation ID(如 X-Ray Trace ID)使日志事件可深度链接至 Trace 视图。ADOT 在标准 OTEL Collector 基础上封装 AWS 专用组件,包含 SIGV4 Auth Extension 实现 AWS 服务无缝集成,支持 CloudWatch/X-Ray/Prometheus/Grafana 等多种后端。与 [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]](Jay Comer 概述版)同属 OpenTelemetry 专题,属 Surav 主讲的深度实践版;与 [[ctp-topic-42-grafana-observability-dashboard]](Grafana 仪表盘)互补,后者为 ADOT 推荐的可视化后端;与 [[ctp-topic-54-esm-saas-log-analytics]](ELK 日志方案)共同构成企业级可观测性知识体系。
|
||
|
||
**[[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]]**(Public Cloud Learning Sessions,Jay Comer 主讲):AWS OpenTelemetry 可观测性全景介绍——涵盖可观测性定义(通过外部输出推断内部状态)、三信号模型(Metrics/Logs/Traces)、OpenTelemetry 核心架构(OTLP 协议 + 11 种语言 SDK + Collector 组件)、AWS Distribution for OpenTelemetry(统一代理 + EKS Operator 自动注入)、最新发布动态(安全合规/规模化/集中管理面板/日志支持)。Demo 展示 EKS 环境完整链路:Fluent Bit 采集容器日志 → OpenTelemetry Collector(端口 55681)→ Amazon OpenSearch Service,OpenSearch Dashboard 可按 trace group 展示延迟并通过应用组成图定位性能瓶颈。属 [[OpenTelemetry]] 在 AWS EKS 场景的核心实践,与 [[ctp-topic-67-cloud-native-observability-using-opentelemetry]](CTP Topic 67)同属 OpenTelemetry 专题,与 [[ctp-topic-54-esm-saas-log-analytics]](ELK 日志方案)共同构成企业级可观测性知识体系。
|
||
|
||
**[[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]**(Public Cloud Learning Sessions,EKS Auto Mode 专题):AWS EKS Auto Mode 深度解析——将数据平面管理责任从用户扩展至 AWS,覆盖计算节点(Carpenter Controller)、存储(EBS CSI Controller)、网络(AWS LB Controller)和安全(Pod Identity Associations)。Bottlerocket OS 提供最小化安全容器操作系统,自动应用安全补丁;Carpenter Controller 监听控制面版本变更,自动触发节点 AMI 滚动升级;Pod Identity Associations 替代 K8s RBAC 实现 Pod 级 IAM 权限控制,无需修改 ServiceAccount;Prefix Delegation 默认启用优化 Pod 网络 IP 分配。默认两个节点池(General Purpose 锁定 AMD64,System 带 taint),支持自定义节点池指定 Graviton。Auto Mode 兼容所有 Kubernetes-compliant 工作负载,实例附加 12% 管理溢价。属 EKS 运维简化的核心实践,与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]](EKS 可靠性)、[[ctp-topic-64-scaling-out-with-amazon-eks]](EKS 扩缩容)共同构成 EKS 完整知识链路。
|
||
|
||
**[[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]**(CTP Topic 39):EKS 在受限 Lab Landing Zone 网络环境下的技术实施方案——Spencer 和 Guy 分享。核心问题:Micro Focus 网络的 AWS Lab 环境 IP 地址池不足,无法满足 Octane(IP 密集型 SaaS 应用)的 EKS Pod 需求。解决方案:创建独立私有子网(非主 VPC 子网),由 EKS 模块自定义网络标志控制 Pod IP 分配;Pod 规范设置 `hostNetwork: true` 使其同时访问内部 Micro Focus 网络和外部资源;Terraform/Terragrunt 模块封装完整 EKS 部署逻辑,支持跨账户角色映射。Atlantis 当前不支持 EKS 部署,需通过 Jenkins + Terragrunt 模块替代。属 [[Amazon EKS]] 在受限网络场景下的技术实践,与 [[ctp-topic-70-eks-deployment-using-iac]](IaC 部署)共同构成 EKS 完整知识链路。
|
||
|
||
**[[ctp-topic-70-eks-deployment-using-iac]]**(CTP Topic 70):EKS 集群通过 IaC 部署的完整方法论——涵盖容器与 VM 的对比(启动速度/内存效率/可移植性)、EKS 核心特性(完全托管控制平面/零停机滚动更新/IAM RBAC 最小权限)。SRE EKS 模块支持两种部署路径:Terraform(`tera-grant.scl` 定义集群参数+Secret Manager 集成)和 Service Catalog(模块化产品组合+版本选择)。自定义网络通过 EMI(ENI Multi-IP)为 Pod 分配额外 IP 地址解决 VPC CIDR 限制;Cluster Autoscaler 实现 Worker Node 自动扩缩容。监控栈:CloudWatch Agent + FluentBit(DaemonSet)+ Container Insights + AWS OpenTelemetry + Grafana。属 [[Amazon EKS]] 部署方法的完整入口,与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]](可靠性)、[[ctp-topic-64-scaling-out-with-amazon-eks]](扩缩容)、[[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]](Auto Mode)共同构成 EKS 完整知识链路。
|
||
|
||
**[[ctp-topic-59-achieving-reliability-with-amazon-eks]]**(CTP Topic 59):Amazon EKS 可靠性最佳实践——AWS 高级解决方案架构师 Surav Paul 主讲。涵盖 EKS 容器服务选型(ECS vs EKS)、可靠性定义(可预测行为、故障检测、优雅降级、自愈、按需扩缩)、shared responsibility model(AWS 负责控制平面,客户负责工作节点/OS/应用配置,Fargate 模式下客户无需管理节点)、应用层可靠性(避免单例 Pod、AZ 分散、拓扑分布约束、HPA/VPA 扩缩容、Rolling/Blue-Green/Canary 部署、存活/就绪/启动探针、PodDisruptionBudget)、控制平面可靠性(监控 API server 指标、安全认证加固、准入 Webhook 管理、集群升级 14 个月支持周期)和数据平面可靠性(节点问题检测、资源预留、QoS、资源配额、Pod 优先级抢占)。属 [[Amazon EKS]] 生产级可靠性保障的核心知识来源,与 [[ctp-topic-70-eks-deployment-using-iac]](IaC 部署)和 [[ctp-topic-64-scaling-out-with-amazon-eks]](扩缩容)共同构成 EKS 完整知识链路。
|
||
|
||
**[[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]**(CTP Topic 4):云转型计划中敏捷实践的落地经验——Heather Norris 主讲。核心内容:①框架演进——从 Scrum(两周 Sprint,含 Product Backlog/Sprint Planning/Retrospectives/Reviews/Daily Scrum)因"Sprint 期间不允许变更"的问题而转向 Kanban 持续流动模式;②混合方案——以 Kanban 为主(随时可调整优先级、持续交付),同时保留 Scrum 的固定仪式(每日站会和回顾会议);③Microsoft Planner 看板——五列布局(Backlog/To Do/In Progress/Program Key Decisions/Icebox),每张卡必须指定单一负责人、链接依赖、设置优先级和截止日期;④核心价值观——"Agile is all about getting that rapid feedback to make the product and make the development culture better"。属 [[Agile Ceremonies]] 和 [[Scrum]] vs [[Kanban]] 在企业级云迁移场景下的实战案例,与 [[ctp-topic-57-product-backlog-managing-demand]](需求管理)和 [[ctp-topic-30-managing-change]](变更管理)共同构成 CTP 项目管理知识体系。
|
||
|
||
**[[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]**(Public Cloud Learning Sessions 20240109):业务分析(Business Analysis)基础技能与三大核心技法——T型技能模型、BOSCARD框架、干系人轮盘(Stakeholder Wheel)、结合元数据的用户故事需求收集。业务分析将业务需求与技术变更解决方案对齐,涵盖IT系统变更、流程变更、培训和角色转换。BOSCARD(Background/Objectives/Scope/Constraints/Assumptions/Risks/Roles/Deliverables)通过澄清背景、目标、范围等8个维度定义复杂新工作,"早期锁定范围无价"。干系人轮盘从客户出发顺时针识别所有项目干系人。INVEST原则(Independent/Negotiable/Valuable/Estimable/Small/Testable)用于检查需求质量。属 [[Product-Backlog]] 和 [[Demand-Management]] 的前置技法层,与 [[ctp-topic-4]](敏捷实践)和 [[ctp-topic-57]](需求管理)共同构成云转型计划的完整方法论(规划→需求→执行)。
|
||
|
||
**[[ctp-topic-18-wide-area-networking-in-aws-cloud]]**(CTP Topic 18):AWS 广域网架构设计——Micro Focus IT 网络架构师 Christian Deckelman 主讲。核心架构:全球划分为 APJ/EMEA/AMS 三个地理区域,每个区域设立 Hub(如 EMEA 伦敦、AMS 俄勒冈),所有 Landing Zones 通过 TGW Peering 以星型拓扑接入区域 Hub,区域 Hub 之间全网状互联。现阶段 TGW 间路由依赖静态前缀列表,缺乏 BGP 动态路由,DR 场景需人工干预。演进路线:引入 Silver Peak SD-WAN 作为叠加网络实现动态路径选择;Pulse VPN 迁移至 Palo Alto Prisma Access (SASE) 实现就近接入并打通 SD-WAN 骨干。属 [[AWS-Transit-Gateway]] 架构实践,与 [[ctp-topic-25-labs-landing-zone-overview-itom-teams]](Labs LZ 网络)和 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]](网络分段)共同构成 Landing Zone 网络知识体系。
|
||
|
||
**[[ctp-topic-25-labs-landing-zone-overview-itom-teams]]**(CTP Topic 25):Labs Landing Zone 运维团队视角——Labs LZ 基于 Gruntwork 参考架构,采用多账户策略,全部资源通过 Terraform/Terragrunt 管理(Jenkins 流水线扫描 GitHub 仓库变更触发 plan/apply);核心账户包括:Shared(托管 Jenkins 主节点和加固 AMI)、Logs(CloudTrail/Config 日志集中存储)、Security(联邦用户和跨账户访问)、Core(AD 管理 Windows 实例和 IDP、DNS 管理 Swimford.net)、Network(Transit Gateway + JetPult 防火墙管理所有互联网流量,Pulse VPN 提供 Micro Focus 网络访问)、Shared Services(45 Arc Site 监控、Qualys 漏洞扫描)。Product Account 通过 Terraform 模块部署 subnet,需与网络团队协调 IP 范围和标签策略,防火墙通过标签自动配置网络访问策略。属 [[AWS-Landing-Zone]] Labs 视角的运维实践,与 [[ctp-topic-1-gruntwork-landing-zone-architecture]](架构基础)和 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]](SaaS vs Labs 职责划分)共同构成完整的 AWS Landing Zone 知识体系。
|
||
|
||
**[[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]**(CTP Topic 31):AWS Landing Zone 网络隔离与安全远程访问方案——解决 On-prem 系统和 VPN 用户因共享网络配置而可直接访问生产工作负载的安全风险。核心方案:①网络隔离通过 Checkpoint 防火墙启用 SPI 特性(default-deny),阻断内部网络对 AWS 网段的直接连通;②安全访问通过 AWS Systems Manager (SSM) 替代 VPN,用户假设 IAM 角色访问目标 EC2 实例上的 SSM Agent,支持浏览器会话和 AWS CLI 两种模式,提供双因素认证和 AWS 网络内安全连接。定位为 SD-WAN 实施前的过渡方案;长期演进目标为 IaC 化以消除控制台访问,break-glass 访问仅保留用于紧急场景。与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]](广域网架构)互补——后者关注如何打通网络,Topic 31 关注如何限制网络访问;两者共同构成 Landing Zone 网络知识体系。属 [[AWS-Landing-Zone]] 网络安全层的核心实践。
|
||
|
||
**[[ctp-topic-8-obm-cloud-monitoring]]**(CTP Topic 8):使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 公有云监控的完整解决方案——OBM AWS Account 部署 OBM 应用、Postgres RDS 和 Operation Agent 三层组件;Agent 通过 AWS Management Pack 利用 IAM Role 信任关系跨账户采集 CloudWatch 指标,无需在被监控账户安装服务器或共享 Access Key;Global OBM 作为 Manager of Managers 汇聚多区域 Regional OBM 数据,事件通过 SMACKS 触发工单;新增实例自动发现、策略自动下发,解决云环境动态性监控难题;支持任意公有云(AWS/Azure/GCP)的 CloudWatch 兼容服务。与 [[ctp-topic-29-cloud-monitoring-saas-lz-accounts]](账户架构)互补构成完整监控体系,属 [[AWS-Landing-Zone]] 监控层的核心实践。
|
||
|
||
**[[ctp-topic-54-esm-saas-log-analytics]]**(CTP Topic 54):ITOM ESM SAS 架构师 Jackie 主讲的企业级日志分析解决方案(ESM SaaS)——涵盖 ELK/OpenSearch 技术栈架构(BEATS 采集 → Logstash 处理 → Elasticsearch/OpenSearch 存储 → Kibana 可视化)、双 VPC 隔离架构(应用 VPC + 日志 VPC)、Redis 缓冲层防止 Logstash 过载。安全加固涵盖静态加密(NVMe 硬件级)、传输加密(TLS 1.2)、VPC 私有流量和 RBAC 访问控制;GDPR 合规要求推动日志农场按区域分割部署(美国俄勒冈、欧洲)。方案对比:AWS OpenSearch(~$1,500/月,SLA 99.9%,推荐)、Logz.io(~$4,000/月,SLA 99.8%)、自托管 ELK(成本低维护高)、Microfocus OBA(商业成熟,列级访问控制)。起步建议先用 Logz.io 试用,再迁移 AWS OpenSearch。与 [[ctp-topic-8-obm-cloud-monitoring]] 同属企业监控体系,Topic 8 聚焦指标监控,Topic 54 聚焦日志分析,共同构成完整可观测性视图。
|
||
|
||
**[[ctp-topic-42-grafana-observability-dashboard]]**(CTP Topic 42):企业级 Grafana 可观测性平台在 AWS 多账户环境下的架构设计与 Terraform IaC 自动化实践——涵盖 Grafana 核心定位(不存储数据,仅从数据源可视化)、基础设施架构(监控账户部署 Grafana,通过 IAM 角色跨账户访问产品团队 AWS 账户)、用户和团队访问控制(Editor/Viewer/Admin 角色)、示例仪表盘(CPU/I/O/Network/EBS/Estimated Charges)、告警系统(Microsoft Teams 通知)、Terraform 模块化供给(数据源模块 + 组织模块 + LZSAP 自动化接入)、Prometheus 网络监控(Checkpoint/防火墙 SNMP 指标)。与 [[ctp-topic-54-esm-saas-log-analytics]](日志分析)同属可观测性专题,共同构成监控知识体系;长期目标是构建应用级仪表盘替代 [[Micro Focus Operations Bridge Manager]]。
|
||
|
||
**[[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]**(CTP Topic 35):AWS Landing Zone 设计复习——重点明确 SaaS(生产)与 Labs(开发)的职责划分。SaaS Landing Zone 为每个产品区域提供客户专属环境,产品账户连接至共享服务账户(安全、日志、网络);核心账户组包含 AD、DNS 和 Network 账户;Gruntwork 账户跨所有账户管理 AMI、日志和安全。近期变更:网络分段阻断对 SaaS 工作负载的直接连通性;CCOEs CloudTrail 取代 Gruntworks CloudTrail 实现统一审计;入站流量拟通过 Network 账户 Checkpoint 重新路由;原生 AWS Backup 有望强制化;新账户可能取消 Management VPC。核心结论:**SaaS = 生产,Labs = 开发**;PoC Landing Zone 将并入 Labs 以最大化资源共享;Cloud Technology Design Forum 推动 Micro Focus 云交付标准化。
|
||
|
||
**[[ctp-topic-6-aws-workspaces-demo]]**(CTP Topic 6):AWS Workspaces 虚拟桌面解决方案实操演示——通过 AWS Workspaces 为云转型团队提供托管 Windows 虚拟桌面(Windows Server 2016),预装 PFSSO、Terraform、TerraGrunt、Git 和 VS Code。用户通过邮件联系 Naga 申请账号,接收注册码和用户名后登录,可立即访问 AWS Console(Federation)和 GitHub Enterprise 并生成 SSH 密钥。演示全程约 21 分钟完成仓库克隆、PFSSO 认证和 TerraGrunt Plan 执行,达成"申请后 45 分钟内运行 Terraform"的目标。未来计划与 Active Directory 集成实现自动化账号管理。属 [[AWS-Landing-Zone]] 用户端工具层的核心实践,与 [[ctp-topic-1-gruntwork-landing-zone-architecture]](基础架构)和 [[ctp-topic-9-ci-cd-with-gruntwork]](CI/CD 流程)共同构成完整的"架构→交付→使用"链路。
|
||
|
||
**[[public-cloud-learning-sessions-aws-end-user-compute-services-20240430]]**(Public Cloud Learning Sessions,Christian O'Donough 主讲):AWS 终端用户计算(EUC)服务全景介绍——覆盖四大服务:① **Workspaces**(全持久虚拟桌面,适合知识工作者一对一实例管理);② **AppStream 2.0**(选择持久/非持久应用流,多租户模式降低成本,适合实验室/培训/堡垒主机);③ **Workspace Core**(提供 VDI 基础设施 API,支持 Horizon View、Citrix 等第三方集成);④ **Workspace Web**(低成本安全浏览器)。核心选型原则:需要完整桌面 → Workspaces;非持久桌面/应用流 → AppStream 2.0;第三方 VDI → Workspace Core;安全浏览 → Workspace Web。安全措施包括 Active Directory 集成、加密、IAM 配置文件、SAML 认证和多因素认证。属 [[AWS-Landing-Zone]] 用户端计算层的理论基础,与 [[ctp-topic-6-aws-workspaces-demo]](实操演示)共同构成完整的 EUC 知识体系。
|
||
|
||
**[[ctp-topic-7-saas-landing-zone-design]]**(CTP Topic 7):SAS 生产 Landing Zone 顶层架构设计——定义了完整的四层账户体系:①核心账户(Core Accounts):Shared 托管 AMI + 主 Jenkins 服务器通过 Lambda 触发各账户 Jenkins slave;Logs 集中管理所有账户日志(CloudTrail/Config/Flowlogs);Security 托管 IAM 角色。②基线账户(Baseline Accounts):Network 账户部署区域级 Transit Gateway + Checkpoint Appliance 按标签监控跨账户流量;DNS 账户托管 Route 53,各产品拥有独立托管区;Active Directory 账户提供双 AD 节点实现域加入和资源访问控制。③共享服务账户(Shared Services Accounts):Software Factory(45 个 hub + Octane Hub + Artifactory)、Cyber(Qalis)、ARC Site、Monitoring(OBM/Sitescope)。④产品账户(Product Accounts):工作负载置于私有子网,公有子网通过负载均衡器和互联网网关对外暴露,WAF 监控入站流量。自动化部署链路:GitHub 仓库变更 → Jenkins(GitHub Hook 触发)→ Management VPC → Lambda → ECS Cluster,Staging 测试后才部署生产。远程访问从 Checkpoint VPN 迁移至 Pulse VPN(通过 AD 认证)。属 [[AWS-Landing-Zone]] 的原始设计规范,与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]](近期变更)共同构成 SAS LZ 的设计演进脉络。
|
||
|
||
**[[ctp-topic-1-gruntwork-landing-zone-architecture]]**(CTP Topic 1):Gruntwork AWS Landing Zone 架构基础——核心概念:参考架构(Reference Architecture)是包含核心账户 Shared/Logs/Security 和工作负载账户 Prod/Stage/Dev 的最佳实践起点;Landing Zone 基于 Gruntwork 仓库但由产品团队自行定义具体服务;安全账户使用联邦用户(Federated User),通过 AD 组映射到 IAM 角色;每个 Landing Zone 配置独立 Jenkins 服务器和特性分支 Git 工作流。属整个 CTP Landing Zone 系列的基础入门篇。
|
||
|
||
**[[learning-sessions-standard-amis-updates]]**(Learning Sessions 20231205):AWS 标准 AMI 更新机制与生命周期管理——Jenkins 多分支流水线构建测试 AMI,验证周期从 3-4 天缩短至 60 分钟;支持 23 种 AMI 涵盖 Amazon Linux/CentOS/RHEL/Rocky Linux/SUSE/Ubuntu/Windows;CentOS 7/RHEL 7 将于 2024 年 6 月 EOL,由 Rocky Linux 替代;机器人框架自动化验证是该优化流程的核心。属 [[AWS-Landing-Zone]] AMI 管理层的实践补充。
|
||
|
||
**[[ctp-topic-50-ami-roadmap-for-aws-amis]]**(CTP Topic 50):CCOE AMI 路线图详解——涵盖 CCOE AMI 路线图规划、操作系统 EOL 时间线(Windows Server 2008/2008 R2 已 EOL;CentOS 8 已 EOL;Windows Server 2012 将于 2023 年 10 月 EOL;RHEL 7 和 CentOS 7 将于 2024 年 6 月 EOL)、AMI 通知机制、变更日志(CCRE 门户)、新 AMI 添加流程(服务集成→功能启用→构建测试)、当前支持的 AMI 清单及未来路线图(SLES 15/RHEL 9 2022年11月;openSUSE 15/Amazon Linux 2022 2023年1月;Rocky 8/9 2023年3月;RHEL 9.4 ARM/Ubuntu 22.04 ARM 2023年5月)。自 2023 年 5 月起所有 ARM AMI 同步发布。路线图优先级主要由 ADM 需求驱动,变更需通过需求管道流程提交。AMI 通过跨账号共享分发给组织内所有账户。属 [[AWS-Landing-Zone]] AMI 层的路线图补充,与 [[ctp-topic-26-standard-ami-build-publish-share-processes]](生命周期管理)和 [[ctp-topic-58-aws-ec2-image-builder]](未来演进方向 EC2 Image Builder)共同构成完整的 AMI 管理知识体系。
|
||
|
||
**[[ctp-topic-26-standard-ami-build-publish-share-processes]]**(CTP Topic 26):Foundation AMI 全生命周期管理详解——Srihari、Alan 和 Praveen 三位专家主讲。Foundation AMI 基于市场主流 OS(CentOS/Ubuntu/Windows)进行 CIS 安全基准加固,集成 McAfee EPO 防病毒 + Syslog-ng 日志管理 + AD 单点登录 + SSM Agent + SiteScope 监控;使用 HashiCorp Packer + Jenkins 流水线实现镜像创建完全自动化;通过跨账号共享(AMI Sharing)分发至全球多区域(俄勒冈/法兰克福/悉尼),而非物理复制(AMI Copying),避免额外存储成本;每两个月更新,采用 N-2 版本保留策略。责任共担模型:CCOE 提供安全基础镜像,产品团队在其上构建产品特定 AMI。属 [[AWS-Landing-Zone]] AMI 层的核心基础,与 [[ctp-topic-58-aws-ec2-image-builder]](演进方向 EC2 Image Builder)和 [[learning-sessions-standard-amis-updates]](2023年更新机制)共同构成完整的 AMI 管理知识体系。
|
||
|
||
**[[ctp-topic-55-aws-firewall-manager]]**(CTP Topic 55):AWS Firewall Manager 在 Grand Torque 多 Landing Zone 环境中的集中化安全策略管理实践——核心动机:跨 RLABS/R&D/SAS/CAT 多个 Landing Zone 管理安全策略的复杂性;原有 Checkpoint Firewall 无法完全覆盖公网子网流量安全。核心方案:①在独立的 Firewall Manager 账户创建安全组策略,指定目标账户或 OU,自动将基线安全组附加到现有和新实例;②三种策略类型——通用安全组(允许产品团队自增)、审计与强制安全组规则(拒绝过度宽松规则,支持手动或自动修复)、清理未使用冗余安全组;③通过 RAM 前缀列表跨账户共享规则,支持 Atlantis CI/CD 流水线部署。Demo 演示了策略创建后 EC2 实例的自动附加与策略删除后的自动移除。前提条件:OU 内管理员权限 + AWS Config 全账户启用。属 [[AWS-Landing-Zone]] 安全策略集中化管理层的核心实践,与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]](Checkpoint 防火墙)互补——后者提供网络边界防火墙,前者提供实例级别安全组基线。|
|
||
|
||
**CTP Topic 10**([[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]):AWS Landing Zone 部署、数据收集策略与基于标签的云原生安全架构——Steve Jarman 和 Pradeep 主讲。核心内容:①Landing Zone 部署前必须深入了解 BU 资产清单、IP 地址空间及数据敏感性;②DNS、Transit Gateway 等基础服务已通过 SRE 团队实现高度自动化;③**基于标签的安全控制机制**——传统基于 IP 的防火墙规则无法适应云环境动态性,转向利用 AWS 标签作为安全凭证;④**SCP 强制执行标签规范**——通过「显式拒绝」逻辑防止用户通过篡改标签绕过审计,确保资源创建时即具备正确的 BU/产品/环境归属;⑤**Checkpoint 防火墙有序层逻辑**——按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离,实现跨 VPC/On-prem/互联网的精细化流量控制;⑥Inline 层基于账号号的父子规则架构,简化跨账户策略管理。与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 的安全层扩展,与 [[ctp-topic-28-aws-tag-validation-tool]](标签审计)共同构成标签治理闭环。
|
||
|
||
**[[ctp-topic-45-automatic-ip-address-allocation-with-ipam]]**(CTP Topic 45):Infoblox NIOS IPAM 自动分配 AWS VPC IP 地址——通过 YAML 配置文件声明期望子网大小和区域父 CIDR,NIOS 自动分配下一个可用 IP 地址块(≤/24 自动,>/24 需审批);销毁 VPC 时自动从 IPAM Grid 清除条目;建立单一可信数据源,消除手工电子表格记录。属 [[IPAM(IP Address Management)]] 的机制层详解。
|
||
|
||
**[[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]**(CTP Topic 61):Workload VPC 完整自动化供给方案——Pushka(Principal SRE)主讲,在 Topic 45 的 IPAM 自动分配机制基础上,展示了端到端 VPC 供给流程。核心增强:多 VPC 批量供给支持、邮件通知机制、CIDR /22 阈值自动审批(更大 CIDR 自动,更小需理由审批)、非路由 IP 地址(如 10.2.0.0/16)支持、使用 AZ ID 避免跨账号不一致。Infoblox Grid 作为全局唯一 IP 地址数据源防止重叠,架构包含休斯顿数据中心主库及冗余 DNS/NTP/DHCP 服务。核心理念:**"只需把信息放到正确位置,一切自动完成。"** 属 [[IPAM(IP Address Management)]] 的应用层扩展,与 [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] 共同构成 IPAM 的"机制 → 应用"完整链路。
|
||
|
||
Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Waste]], [[Benefits-Quantification]], [[Cost-of-Delay]], [[WSJF]], [[SOM]], [[Feature-Level-Value-Breakdown]], [[Program-Demand-Process]], [[Proof-of-Concept]], [[Gate-Process]], [[Solution-Design]], [[Landing Zone Architecture]], [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Octane]], [[Hybrid DNS Resolution]], [[VMware-Cloud-on-AWS]], [[VMware]], [[HCX]], [[SDDC]], [[Stretched-Cluster]], [[Hybrid-Cloud]], [[Multi-Cloud Strategy]], [[Multi-Cloud-ROI]], [[DevOps Culture]], [[CI/CD Pipeline]], [[DevSecOps]], [[Shift-Left-Security]], [[Shift-Right-Security]], [[SAST]], [[DAST]], [[IAST]], [[SCA]], [[Break-the-Build]], [[Agile Practices]], [[DevOps Maturity]], [[DORA Metrics]], [[Infrastructure as Code]], [[Cloud-Native]], [[Cloud Maturity Levels]], [[Cloud Adoption Strategy]], [[Cloud Service Delivery]], [[Cloud DevOps Maturity Model]], [[Cloud Operating Model]], [[Cloud Governance]], [[Cloud Cost Optimization]], [[Serverless Computing]], [[Edge Computing]], [[Green Computing]], [[Data-Warehouse]], [[MPP]], [[Columnar-Storage]], [[Sort-Key]], [[Distribution-Key]], [[Vendor-Lock-In]], [[Data-Sovereignty]], [[NFR(非功能需求)]], [[Error Budget(错误预算)]], [[Chaos Engineering]], [[Product Privacy Framework(产品隐私框架)]], [[STLC(Security Development Life Cycle)]], [[PSAC(Product Security Advisory Committee)]], [[PII(Personally Identifiable Information)]], [[Maturity Model(成熟度模型)]], [[Spider Chart(蜘蛛图)]], [[Product Privacy Settings Document]], [[Data Controller vs. Data Processor]], [[Anonymization & Pseudonymization]], [[被遗忘权]], [[数据可移植性]], [[高可用(High Availability)]], [[灾难恢复架构模式]], [[Vault Lock]], [[ELK Stack]], [[OpenSearch]], [[Logstash]], [[Kibana]], [[BEATS]], [[Filebeat]], [[OpenTelemetry]], [[Fluent Bit]], [[Observability(可观测性)]], [[OTLP(OpenTelemetry Protocol)]], [[Three Signals]], [[Centralized-Logging]], [[Redis缓存]], [[RBAC]], [[TLS]], [[API-Key-Rotation]], [[跨账户备份]], [[增量备份]], [[SPF]], [[DKIM]], [[TLS]], [[API-Key-Rotation]], [[Cyber-Suite]], [[CBC-Mode]], [[SendGrid]], [[Twilio]] vs [[全量备份]](CTP Topic 72:增量仅捕获变更,节省存储成本)、**[[AWS Backup Audit Manager]]**(BAM,CTP Topic 72:合规审计报告)、**[[AWS-Tagging-Standards]]**(CTP Topic 28:AWS 标签规范,涵盖命名约定、强制标签键、成本标签策略;与 Checkpoint 防火墙安全策略直接关联,标签缺失导致流量拦截)、**[[Tag-Validation-Tool]]**(CTP Topic 28:SRE 团队开发的 Python/Boto3 工具,通过 YAML 配置扫描 AWS 资源标签合规性)、**[[Service-Control-Policies-SCPs]]**(AWS Organizations 策略类型,通过「显式拒绝」逻辑强制执行标签规范)、**[[OU-Layered-Security]]**(通过组织单元分层结构检查标签确保正确归属)、**[[Tag-Based-Security]]**(将资源标签作为安全凭证替代传统 IP 规则)、**[[Checkpoint-Firewall]]**(防火墙供应商,依赖 AWS 标签值配置网络访问策略)、**[[Variables-YAML]]**(Tag Validation Tool 核心配置文件,定义每个账户的合法标签键及允许值)、**[[SRE-Tools-Repository]]**(内部代码仓库,存放 Tag Validation Tool 等 SRE 自动化脚本):[[WAF]], [[APM]], [[Cloud Security]], [[Cloud Migration]], [[High Availability]], [[Pay-as-you-go]], [[Failover]], [[Multi-factor-Authentication]], [[Data-Governance]], [[Continuous Integration]], [[Continuous Deployment]], [[Lead Time]], [[Time-to-Market]], [[MTTR]], [[MTTD]], [[MTTA]], [[Change Failure Rate]], [[Error Budget]], [[Rollback Rate]], [[Availability]], [[Scalability]], **[[Agentic AI]]**, [[Root Cause Analysis (RCA)]], [[Predictive Maintenance]], [[Deployment Automation]], [[Rightsizing]], [[Automated Security Audit]], [[AI ChatOps]], [[What-If Simulation]], **[[RTO]]**, **[[RPO]]**, **[[Feature Flag]]**, **[[Kill Switch]]**, **[[Progressive Rollout]]**, **[[Micro-Recovery]]**, **[[Deployment-vs-Release]]**, **[[Business Impact Analysis]]**, **[[Public Cloud]]**, **[[Private Cloud]]**, **[[Hybrid Cloud]]**, **[[Shared Responsibility Model]]**, [[Multi-Tenancy]], [[Intentional Cloud Strategy]], **[[Centralized Logging]]**, **[[Cross-Account Monitoring]]**, **[[Multi-Account Deployment]]**, **[[StackSets Deployment Visibility]]**, [[CMDB]], [[Problem-Management]], [[Release-Management]], [[Configuration-Management]], [[Asset-Management]], [[Security-and-Compliance]], [[DRaaS]], [[Canary-Release]], [[Blue-Green-Deployment]], [[Threat Modeling]], [[OWASP-Top-Ten]], [[Bug-Bounty]], [[Vulnerability-Scanning]], [[Penetration-Testing]], [[Compliance-Automation]]
|
||
|
||
**[[ctp-topic-40-saas-database-architecture]]**(CTP Topic 40):SAS 数据库团队在 AWS 云上的架构与运维实践——团队分布于美国/加拿大/印度/以色列,管理 500+ 数据库和 1000+ DB 服务器;支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多引擎;高可用架构采用三可用区模式(主库/备用库/见证节点);使用 Oracle Data Guard、Postgres Active-Passive/Active-Active、RDS HA 实现多活;通过 Terraform、AWS CLI、Shell/PowerShell 实现 IaC 自动化;Oracle GoldenGate 支持零停机迁移。属 [[AWS-Landing-Zone]] 数据库层的核心实践,与 [[ctp-topic-51-purpose-built-databases]](数据库品类全景)和 [[ctp-topic-66-rds-vs-aurora]](关系型选型)共同构成完整的 AWS 数据库知识体系。
|
||
|
||
**[[ctp-topic-43-vmware-cloud-on-aws]]**(CTP Topic 43):VMware Cloud on AWS 混合云服务介绍——VMware 与 AWS 联合开发,在 AWS 裸金属服务器(i3.metal/i3en.metal)上原生安装 vSphere 8,为不完全准备完全迁移至原生云的企业提供中间路线。工作负载可在数秒内往返迁移于本地与云端之间,通过 HCX 实现 any-to-any vSphere 迁移。Brian Reeves 讨论经济学效益:相比常规云方案节省 27% 成本,云经济学团队可提供 TCO 计算。Mike O'Reilly(VMware Staff Cloud Solutions Architect)强调这是真正的联合工程而非简单地将 VMware 软件部署到云端。支持 SDDC 部署,通过 vCenter 管理,支持跨可用区的 Stretched Cluster 高可用架构。属 [[Hybrid-Cloud]] 在 AWS 落地的核心实践,与 [[ctp-topic-53-why-bother-with-cloud]] 存在是否应迁移至云端的观点张力。
|
||
|
||
**[[ctp-topic-53-why-bother-with-cloud]]**(CTP Topic 53):云转型商业价值论证——用数据说明"为何要上云"。Micro Focus 拥有全球最大的商业数据中心足迹——14个数据中心、近20,000台资产;尽管年营收25亿美元,但 VMware 足迹比规模大8倍的公司还大,硬件利用率不足40%。三个产品从 Bublikan 迁出后下线575台物理服务器,云端仅需240台虚拟服务器替代;Redding 退出时40%的应用直接关机,Houston 有89个空机架和360台未使用服务器。核心理念:**云迁移不仅是成本节约,更是创新催化剂**——赋能产品增强、改善灾备、开拓新市场。当前55%的 AWS 成本发生在 Landing Zone 之外,亟需治理。属 [[Cloud Transformation Programme]] 的战略论证层,与 [[ctp-topic-43-vmware-cloud-on-aws]](混合云中间路线)共同构成完整的云迁移决策框架。
|
||
|
||
**[[ctp-topic-69-vmware-vm-migration-best-practices]]**(CTP Topic 69):VMC on AWS 虚拟机迁移最佳实践——基于 VMware 顾问支持的经验分享。核心内容:①架构——VMware Cloud 托管于 AWS 基础设施,通过 Direct Connect 和 Virtual Transit Gateway 实现与本地数据中心的混合云连接;②HCX 多云管理——每次迭代最多支持 200 台 VM 迁移,支持从 STDC 查看本地 vSphere 环境和反向操作;③两种迁移方法——UI 方式(VMware Cloud 原生)和 CCOE 脚本方案(使用输入文件定义 VM 详情);④成本原则——"Anything which leaves definitely attracts cost",数据传输产生费用;⑤后迁移管理——通过 Brown to Manage (BHM) 系统集成 SMACS Suite 和 HCMX 实现虚拟机管理。属 [[VMware-Cloud-on-AWS]] 迁移执行层面的核心补充,与 [[ctp-topic-43-vmware-cloud-on-aws]] 互补构成完整的"概述→迁移执行"知识链路。
|
||
|
||
**[[ctp-topic-46-netapps-on-aws]]**(CTP Topic 46):NetApp 存储系统 AWS 实践——Sandeep 和 Yael 主讲。覆盖传统 NetApp 架构(ONTAP / Aggregate / FlexVol / Qtree / LUN / LIF / SVM)和 AWS 云版本 Cloud Volume ONTAP (CVO)。CVO 通过 EC2 实例提供软件定义存储,支持单节点或 HA 配对(跨多 AZ 同步复制);数据分层机制将 30 天非活跃数据从 EBS 自动迁移到 S3;SnapMirror 实现块级跨集群复制;支持的迁移工具包括 SnapMirror、NetApp XCP、Cloud Sync、AWS DataSync。组织已在 15 个 AWS 区域部署约 1.3 PB 数据,使用 Cloud Manager 集中管理,计划引入 FSX for NetApp(POC)和 Terraform 自动化部署。属 [[AWS-Landing-Zone]] 存储层架构的核心补充。
|
||
|
||
**[[ctp-topic-51-purpose-built-databases]]**(CTP Topic 51):AWS 数据库专家 Femi George 分享专用数据库选型与架构原则——核心思维:现代应用"为正确的工作选择正确的专用数据库",避免一刀切。AWS 提供完整数据库品类:关系型(RDS、Aurora MySQL/PostgreSQL)、NoSQL 键值( DynamoDB,日处理万亿请求)、文档(DocumentDB,MongoDB 兼容)、宽列(Keyspaces,Cassandra 兼容)、内存(ElastiCache Redis/Memcached)、图(Neptune)、时序(Timestream)、账本。实战案例:Duolingo 用 DynamoDB + ElastiCache + Aurora 组合;Netflix 用 DynamoDB 做高弹性 JSON 文档;Peloton 用 ElastiCache Redis 提供即时客户反馈。云时代 DBA 职能从底层平台管理转向应用创新(查询优化/架构设计)。属 [[AWS-Landing-Zone]] 数据库层的完整品类指南,与 [[ctp-topic-66-rds-vs-aurora]](关系型内部选型)互补。
|
||
|
||
**[[ctp-topic-68-introduction-to-redshift]]**(CTP Topic 68):AWS Redshift 数据仓库基础——Redshift 是完全托管的 PB 级云数据仓库,核心架构包含 Leader Node(管理 Schema、元数据、查询计划)和 Compute Node(通过 Slices 执行 MPP 并行查询)。支持列式存储(适合 OLAP 聚合查询)和行式存储两种模式;Sort Key 和 Distribution Key 是性能优化核心;RA3 实例类型性价比最优,支持 AWS 托管 NVMe 存储。属 [[AWS-Landing-Zone]] 数据库层的核心补充,与 [[ctp-topic-51-purpose-built-databases]](数据库品类全景)和 [[ctp-topic-66-rds-vs-aurora]](关系型选型)共同构成完整的 AWS 数据库知识体系。
|
||
|
||
**[[ctp-topic-66-rds-vs-aurora]]**(CTP Topic 66):PostgreSQL RDS 与 Aurora 深度对比——Greg Klau 主讲。核心维度对比:①最小规格和成本(RDS 更低);②最大容量和 IO 性能(Aurora 更优,适合 > 10-20 TB);③RTO(Aurora 30秒 vs RDS 2分钟);④存储灵活性(RDS 有 GP2/GP3/预置 IOPS/磁性,Aurora 按 IO 收费无上限);⑤架构(RDS:EC2+EBS 分离,Multi-AZ 备用节点;Aurora:跨 3 AZ 的 6 副本共享集群卷);⑥Blue-Green 部署(仅 Aurora MySQL 支持);⑦端点设计(Aurora 独立 Writer/Reader Endpoint)。高可用调优技巧:DNS TTL 设为 1 秒、TCP Keep-Alive 快速检测故障、JDBC 连接串配置 reader/writer 端点路由。属 [[AWS-Landing-Zone]] 数据库选型的核心参考。
|
||
|
||
**[[ctp-topic-14-octane-hub-on-aws]]**(CTP Topic 14):Octane Hub CTO 实战案例——Docker 容器化工作负载从 Bibling Lab 物理服务器迁移到 AWS Landing Zone。核心技术要点:Packer 构建 AMI + Terraform/TerraGrunt 替代控制台脚本(IaC 演进路径);EFS 适合备份、EBS 适合实时数据库(存储选型原则);VPC Transit Gateway 实现多 VPC 互联;"紧密镜像现有设置"作为无缝迁移策略。下一步:DR 改进、MSSQL→Postgres 迁移、ECS 演进。属 [[AWS-Landing-Zone]] 从设计到落地的完整案例补充。
|
||
|
||
**[[ctp-topic-22-global-dns-service-offerings]]**(CTP Topic 22):企业级全球 DNS 服务架构详解——Sankar 和 Vino 主讲。核心架构:Route 53 Private Hosted Zone(私有托管区域)配合 AD 托管 DNS,通过 Route 53 Resolver 入站/出站终端节点打通 AWS VPC 与本地网络的 DNS 查询;Outbound Endpoint 出站规则配置多个区域 AD 域控制器 IP,单区域故障时自动切换确保弹性。本地 Infoblox 平台利用 DNS Anycast 实现全球低延迟和自动故障转移;AWS EC2 不支持 Anycast,需手动维护 IP 列表。DNS 安全涵盖防隧道攻击、防数据外泄及缓存污染;"就近解析"原则优化 Office 365 等全球化 SaaS 访问性能。属 [[AWS-Landing-Zone]] 网络层 DNS 专题,与 [[ctp-topic-19-configuring-dns-within-aws-lzs]] 共同构成 Landing Zone DNS 知识体系——后者(前文)介绍 Route 53 Resolver Inbound/Outbound Endpoints 打通混合 DNS 架构,本视频(后者)聚焦 Landing Zone 内部集中化 DNS 账号的配置实践,Terraform 自动化实现新账号上线即具备完整解析能力。
|
||
|
||
**[[ctp-topic-36-sendgrid-as-an-email-service]]**(CTP Topic 36):SendGrid 被选定为经典和新 Landing Zone 的标准邮件服务,替换现有语义消息网关(Port 25 不安全、即将停用本地网络)和 SES(每封限制 50 收件人)。SendGrid 支持每封最多 1,000 收件人、全云兼容、TLS 端到端加密和双因素认证;支持计划覆盖每月 500 万封邮件;提供直连 SendGrid(需 TLS)和中继服务器(不支持 TLS 的应用)两种架构,数据通过全球中继节点(伦敦/印度/东京)走私有线路汇至美国数据中心。配置要求:使用 software.microcopy.com 域名、连接 smtp.sendgrid.net:587、启用 TLS;SPF/DKIM 记录为邮件送达必要条件;API 密钥每 180 天轮换,日志保留 7 天。同期 Yu-Yan 分享了 Cyber Suite 加密标准更新,涵盖 FIPS/Java/Golang/Node.js/OpenCell 等行业标准合规模件,可选套件因包含 CBC 模式(弱加密)仅作向后兼容,使用非标准套件的产品需经 PSAC 审查。属 [[AWS-Landing-Zone]] 通信层基础组件,与 [[ctp-topic-37-secrets-certificates-management]] 同属安全运维范畴。
|
||
|
||
**[[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]**(CTP Topic 17):Paul 讲解 Gruntwork AWS Landing Zones 中的 AD 服务集成——双域名策略(`swinford.net` 用于 R&D Labs,`intsas.local` 用于生产/SAS 环境);SRE 预制 AMI 内置 PowerShell/Shell 脚本,通过 Terraform `user_data` 实现自动化域加入;旧域名 `infra` 和 `AST` 已废弃,提供明确迁移路径;Linux 支持安全动态更新(Secure Dynamic Updates)自动注册 DNS A 记录;R&D 环境使用 MIM 自助服务,生产/SAS 环境通过 SMACKS 工单系统申请账号。属 [[AWS-Landing-Zone]] AD 集成的核心实践参考。
|
||
|
||
**[[ctp-topic-5-aws-identity-and-access-management-iam]]**(CTP Topic 5):AWS IAM 核心组件与联邦访问机制——涵盖 IAM Dashboard 四大资源(用户、组、客户托管策略、角色、身份提供商);联邦用户通过 Active Directory 组映射到 IAM 角色实现单点登录;`accounts.json` 位于每个 Landing Zone 根目录,包含账户号列表;IAM 用户主要用于服务账号,人工用户优先使用联邦访问;角色本身不启用操作,而是将"谁可以做什么"与"可以做什么"关联;策略分为 AWS 托管和客户托管两种,Terraform 模块可定义 IAM 角色(假设角色策略 + 内联策略块);PFSSO 工具实现 CLI 联邦访问;最小权限原则贯穿始终。属 [[AWS-Landing-Zone]] 身份与访问管理层的入门基础,与 [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]](AD 集成)、[[ctp-topic-11-ad-integration-and-login-using-ad-accounts]](AD 登录)、[[learning-sessions-identity-governance-vsm-replacement]](身份治理)共同构成完整的身份治理知识体系。
|
||
|
||
**[[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]**(CTP Topic 11,Niranjan 主讲):Jenkins 与企业 Active Directory (AD) 的集成,以及 Terraform 代码的自动化质量检查——核心内容:① Jenkins 与 SW Infra AD 的安全域集成,用户入离职通过 AD 账号实现自动化管理,无需手动维护本地用户;② 通过 AD 组策略实现 RBAC 精细化权限控制(只读、读写、流水线创建权限);③ pre-commit 框架集成 terraform fmt(格式统一)、TFLint(逻辑验证)、Checkov(安全扫描)三款工具,在代码提交阶段自动嵌入安全检查;④ CI/CD 流水线分层治理模式:Commit 阶段仅触发自动化检查 → PR 阶段触发检查+terraform plan → Master 分支人工审核后执行 terraform apply。核心理念:**"左移"(Shift-Left)将安全问题从生产阶段提前到开发早期**,通过分层治理实现基础设施即代码的安全性与稳定性。属 [[AWS-Landing-Zone]] 身份与访问管理层的实践延伸,与 [[ctp-topic-5-aws-identity-and-access-management-iam]](AWS IAM 联邦访问)共同构成身份治理知识体系。
|
||
|
||
**[[public-cloud-learning-sessions-opentext-tagging-standard-v2]]**(Learning Sessions,Martin Rosler 主讲):OpenText 云资源标签标准 v2——三大驱动力(成本优化/风险降低/自动化效率);覆盖云账户、云资源(compute/storage/network)、Kubernetes 对象(namespaces/pods/deployments/services/config maps)和容器镜像;通过标准化前缀(OT\_ / app.opentext.com / com.opentext.image)确保跨平台标签语义无歧义;最佳实践:IaC 自动化替代手动打标、禁止标签存储敏感数据、对频繁变更标签谨慎处理。属 [[AWS-Tagging-Standards]](CTP Topic 28)同一标签治理领域的补充——前者定义 AWS 内部规范,后者定义 OpenText 跨云统一标准,两者互补。
|
||
|
||
**[[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]]**(Learning Sessions):OpenText 将源代码管理平台从 GitHub Enterprise 迁移至 GitLab——Project Thor 整合 Micro Focus 和 OpenText 工具链,GitLab 作为源代码控制黄金标准;GitHub 许可证12月底到期不续;各团队自主盘点资产、识别流水线并规划迁移(self-serve 模式),Build Hub 提供辅助支持;两种迁移方案(镜像同步 / 搬移重构);迁移完成标准:代码迁移 + 流水线转型 + PHT 更新;网络连通性挑战通过 Brook Park GitLab 代理解决。属 [[DevOps Culture]] 中企业级工具链标准化转型的典型案例。
|
||
|
||
**[[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]**(Learning Sessions,Arnold Dacan 主讲):Project Thor 平台架构与数据流设计详解——五大支柱框架(敏捷周期治理、产品发布治理、开发者门户 Backstage、安全与治理、Build Hub);核心数据流:源代码流(GitLab)→ 制造流程(Build Farms)→ Artifactory → 客户环境;地理分布:工具链主站点 Brook Park + 灾备站点 Sacramento;标准化目标:统一 GitLab/Artifactory/UCMDB 工具链,夯实供应链安全基础。属 [[DevOps Culture]] 企业级工具链标准化与供应链安全的深度补充,与 GitHub→GitLab 迁移文档共同构成 Project Thor 知识体系。
|
||
|
||
**[[ctp-topic-62-aws-secrets-manager]]**(CTP Topic 62):AWS Secrets Manager 企业级密钥管理深度实践——Nurit 和 Daniel 分享。核心内容:①选型背景——HashiCorp Vault 与 AWS Secrets Manager POC 对比,AWS Secrets Manager 以更低成本和更简实施被选定为最终方案;②AWS Secrets Management Standard 文档——最佳实践文档演变为公有云密钥管理标准,基于 Control Tower 实施经验,包含分阶段方法论(集中化密钥 → 调整自动化获取 → 启动轮换);③核心原则——开发者无需直接访问密钥,通过 IAM 角色和标签实现访问控制;④实施机会——Oracle DB 用户密码轮换(Lambda 函数连接 Oracle 实例执行轮换,无需邮件传递密码)、SendGrid 集中邮件服务(API 密钥轮换通过集中 SMTP 服务实现,无需应用重启或代码修改);⑤Demo——Victor 演示使用 JDBC Wrapper + AWS SDK 免密登录 Oracle 数据库,用户名由角色控制,密钥可通过标签进行分类和访问控制。属 [[AWS-Secrets-Manager]] 在企业落地的核心实践,与 [[ctp-topic-37-secrets-certificates-management]](Secrets 与 Certificates 统一管理框架)互补,与 [[ctp-topic-36-sendgrid-as-an-email-service]](SendGrid 邮件服务)共同构成安全运维知识体系。
|
||
|
||
**[[public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me]]**(Learning Sessions,Mike & Ed 主讲):OpenText 全球信息安全团队(GIS)安全策略全景——GIS 是分层组织架构,包含安全运营(事件响应与保障)、合规(认证与政策执行)、治理风险验证(GRV,季度审查 Admin 角色)、隐私(新增集成中)四个支柱。OpenText 采用分层方法定义安全策略——与各团队协作定义"做什么",与执行团队协作确定"怎么做";持有 FedRAMP 等多项行业及政府认证,可进入多个垂直市场销售;每月处理 2250 亿条日志,分诊约 350 个案例。姿态框架基于 ISO 27001(2022 年更新,新增 11 个控制方面);Global Information Security Policy(GISP)是最高纲领性政策,季度审查。安全运营涵盖 Cyber Response Center、威胁情报(BrightCloud)、云安全、安全工具与工程等核心服务;合规组织涵盖合规项目、路线图、产品风险评估、持续合规与审计、自动化等内容。属企业级安全治理体系的核心入门,与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]](AWS 层面标签化安全)互补——GISP 定义全局政策纲领,Landing Zone 层面通过标签和 SCP 实现技术落地。
|
||
|
||
**[[ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management]]**(CTP Topic 52):Coyote(Enterprise Application Security 负责人)分享 Three Lines of Defence(3LoD)安全治理框架落地和 Cloud Security Posture Management(CSPM)工具选型——3LoD 框架经 ELT 批准后成为组织统一的安全治理模型,明确业务单元(一线:实施管理安全控制)→ 集团职能部门(二线:政策/事件响应/网络安全工具)→ 审计(三线:确保一二线合规)的三层责任分层,解决了此前安全团队和政策碎片化导致的审计问题。CSPM 解决多云账户管理碎片化问题,提供统一的合规框架视图( CIS、NIST、ISO)和自定义策略能力;Cloud Guard 在 POC 后被选中,核心功能涵盖态势管理、资产管理、网络配置可视化、事件管理和威胁情报,新账户在创建流程中即被纳入 Cloud Guard 确保全面覆盖。核心理念:**从被动安全响应转向主动防御**,通过 CSPM 主动发现和修复云配置偏差。与 [[ctp-topic-55-aws-firewall-manager]](Firewall Manager 安全组策略)和 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]](标签化安全)共同构成完整的云安全防护体系,与 [[public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me]](GIS 安全策略全景)互补——后者定义组织层面的安全策略框架,前者定义云安全运营的技术落地层。
|
||
|
||
**[[ctp-topic-28-aws-tag-validation-tool]]**(CTP Topic 28):AWS 标签验证工具——Lewis Brown 主讲,SRE 团队开发的 Python/Boto3 工具。Checkpoint 防火墙通过读取 EC2、安全组、负载均衡器的标签值动态配置网络访问策略,标签缺失或无效将导致流量被拦截;SCPs 可阻止不合规资源创建但无法修复存量资源。该工具通过 `variables.yaml` 定义每个账户的合法标签值,自动扫描 EC2/安全组/负载均衡器/Lambda,生成 CSV 审计报告。使用 Poetry 管理 Python 环境,存放于 SRE Tools Repository。标签策略还计划用于未来成本核算,区分同一账户下不同产品的资源消耗。属 [[AWS-Landing-Zone]] 标签治理闭环的核心补充——制定规范(Topic 10)→ 强制执行(SCPs)→ 审计发现(Topic 28)。
|
||
|
||
**[[ctp-topic-30-managing-change]]**(CTP Topic 30):云转型中的变更管理与 SRE 团队协作——Brendan Starnig(SRE Function Lead)主讲。核心内容:①SRE 职责——用软件工程思维解决运维问题,追求可靠性、可测试性、可重复性,核心是打破运维与产品的壁垒;②变更分类——Standard Change(预批准,完全自动化 IaC+CI/CD,无需 CAB)→ Normal Change(需 CAB 审批,目标是通过自动化逐步归入 Standard Change)→ Emergency Change(立即执行缓解事故,事后 CAPA/Post-mortem 修复根因);③SRE 三阶段协作——构建(Build)/早期上线支持(Early Live Support)/BAU;④Self-Healing 演进方向——各产品组分享实践,SRE 协助在监控产品中落地。属 [[AWS-Landing-Zone]] 运维治理层的核心补充,与 [[ctp-topic-28-aws-tag-validation-tool]](IaC 变更的 Tagging 标准属于 Standard Change 范畴)共同构成变更管理知识体系。
|
||
|
||
**[[ctp-topic-41-nfrs-and-error-budgets]]**(CTP Topic 41):NFR(非功能需求)与 Error Budget(错误预算)在云转型和敏捷开发中的实践——Micro Focus SRE 负责人 Brendan Standing 主讲。核心内容:①NFR 定义——评判系统运行的准则(可用性、性能、安全性、可扩展性),云环境下应更具规范性,充分利用云原生服务(如 AWS Backup 定时备份 + IaC 基础设施代码化);②NFR Epic 模板——将 NFR 集成到 Sprint Backlog,确保任何重大变更都考虑非功能需求;③AWS 共享责任模型——云提供商负责基础设施,公司在云中架构和管理服务以满足 NFR;④Error Budget 机制——Error Budget = 1 - 可用性 SLO(如 99.9% SLO → 0.1% Error Budget),用于衡量系统在影响客户前可承受的不可靠程度,驱动开发和运维决策;⑤SLR/SLO/SLA 三层体系——SLR 是可量化的可靠性指标,SLO 定义服务应如何表现,SLA 是客户级别协议;⑥混沌工程——主动注入故障测试系统韧性,确保 NFR 得到满足。核心理念:**Error Budget 将失败归一化为开发流程的一部分,弥合了开发与运维之间的文化鸿沟**。属 [[AWS-Landing-Zone]] SRE 可靠性工程层的核心补充,与 [[ctp-topic-30-managing-change]](SRE 变更管理)和 [[ctp-topic-72-enterprise-dr-strategy-aws-backup]](DR 可用性目标)共同构成完整的 SRE 知识体系。
|
||
|
||
**[[ctp-topic-57-product-backlog-managing-demand]]**(CTP Topic 57):CTP 产品待办列表(Backlog)需求管理完整管道——①需求提交(通过 SMACs 启动计时器和追踪)→ ②双周评审会议(Matthew Chapman/David Grant/Brendan)评估理解度、价值和优先级,约20题评估问卷判断简洁性、成本和野心程度 → ③Octane 特性化(带任务列表)→ ④Sprint 规划(提前6个 Sprint,50% 新需求 / 50% 支持+技术债)→ ⑤Prerequisite Phase(新产品组入职:介绍会议→AWS账户创建→解决方案设计→GitHub仓库→防火墙标签,产品团队约2小时,1-2周)→ ⑥SRE 构建账号并交接(提供控制台/GitHub访问详情)→ ⑦2周 Hyper Care 支持。现有产品组通过 SMACs/邮件/Teams 请求支持,Teams 频道连接产品组、SRE工程师、解决方案架构师和交付经理。核心理念:**透明化需求管道,确保所有工作以同一标准评估**。属 [[AWS-Landing-Zone]] 需求治理层的核心补充,与 [[ctp-topic-20-program-demand-process-flow]](Gate Process 和 POC 入职)、[[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]](敏捷实践)、[[ctp-topic-30-managing-change]](变更管理与 SRE 协作)共同构成完整的 CTP 治理知识体系。
|
||
|
||
**[[public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16]]**(Public Cloud Learning Sessions,Oli Workflow):超大规模云厂商支出审批工作流与需求管理端到端流程——涵盖两大部分:① **Oli 工作流审批机制**:所有超大规模云厂商支出无论金额均需 MUI 或 Shannon 书面审批;Oli 系统由 Tom Bice 领导的 FinOps 团队接管,正在集成到 SMACs 平台;提议的三阶段审批工作流(FinOps 可行性验证→云服务技术可行性验证→FPNA 团队预算可用性验证);Oli 系统提供飞行中 CSV 报告追踪状态/申请人/成本中心/月成本。② **OpenText 需求管理全链路**:ITIL 框架下服务战略→设计→过渡→运营→持续改进五阶段;主服务目录(Combined Cloud Products Master Catalog)将嵌入 SMACs;Octane 和 Qixi 是两大需求提交入口;ADM/ITOM 需求规划会议捕获所需内容、数量和发布版本;核心理念:**"机器做机器能做的事",目标 80% 场景业务单元自助完成需求选择**。属 [[Demand-Management]] 和 [[FinOps]] 在 OpenText 云转型场景的核心实践,与 [[ctp-topic-57-product-backlog-managing-demand]](Backlog 管理管道)共同构成完整的需求治理知识体系。
|
||
|
||
**[[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]**(CTP Topic 65):云转型中的价值交付量化框架——提供系统性衡量、捕获和优先排序云转型业务价值的方法论。核心内容:①基础概念——过程(Process)将输入转化为产出/成果,成果分硬性(时间/成本/质量)和软性(健康/安全);Lean 识别三类活动:增值活动、价值赋能活动、浪费;价值(Value)由客户决定,体现为公平回报;②价值流(Value Stream)分为运营价值流(OVS,面向客户)和开发价值流(DVS,内部产品);③收益量化框架——涵盖财务、生产力、质量和体验四个维度,聚焦收入增长、成本降低、风险改善和服务可获得市场规模(SOM);④WSJF 优先级排序——通过 Cost of Delay / Size of Job 比值对工作排序,实现"最小投入尽早交付最大价值";延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会;⑤功能级价值拆解——可按单一功能归属、均分或不均匀分配(基于触达/影响/努力等标准)。属 [[AWS-Landing-Zone]] 价值治理层的核心方法论,与 [[ctp-topic-30-managing-change]](变更管理)和 [[ctp-topic-20-program-demand-process-flow]](需求流程)共同构成完整的 CTP 治理知识体系。
|
||
|
||
**[[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]]**(CTP Topic 20):云转型计划的程序需求流程与 POC 入职流程——Sergio 和 Damian 主讲。核心内容:①需求来源——主要由业务案例(如数据中心关闭)、高层管理人员战略优先级及产品路线图驱动;②Gate Process——Gate 0 评估准入、Gate 1 负责 Design Authority 审批、Gate 3 作为启动迁移的最终准入;③POC 目的——不仅验证架构和技术可行性,还包括让团队熟悉基于 Gruntwork 的新一代 Landing Zone;④新环境特点——强调 IaC(Terraform/Terragrunt)自动化部署,严禁手动构建;⑤PCG 团队——平台控制组,负责提供云环境支持、安全策略制定及协助产品组进行 POC;⑥成功标准——POC 成功标准必须在启动前明确定义。属 CTP 治理知识体系入口,与 [[ctp-topic-65]](价值量化)、[[ctp-topic-57]](需求管理)、[[ctp-topic-30]](变更管理)共同构成完整的治理框架链条。
|
||
|
||
**[[ctp-topic-47-enterprise-architecture-cloud-standards]]**(CTP Topic 47):Lindsay 分享企业架构云标准——核心概念:Landing Zone 框架聚焦安全、合规和可管理性,为云工作负载提供托管基础,包含账户结构(dev/stage/prod)、网络、安全、访问管理和遥测;账户结构与环境和角色对齐,通过零信任和最小权限原则定义访问控制;Terraform/Terragrunt 实现 IaC,促进标准化和可测试性;云防护栏文档捕获强制性要求和最佳实践,指导可扩展性、成本最小化和灵活性;功能分区将单体应用拆分为更小的独立模块或无服务器函数。强调需要应用团队的输入来完善防护栏并纳入实践经验。属 [[AWS-Landing-Zone]] 企业架构层的理论补充。
|
||
|
||
**[[ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]]**(CTP Topic 23):技术架构团队职能与云转型价值——Martin Nash(技术架构经理)主讲。核心内容:①组织变革背景——PSTC 与 IT 部门整合至 CIO 统一领导下,实现两个大型组织的深度融合;②云优先策略——除非数据主权、合规性或极端成本原因必须保留在本地,否则所有新业务优先上云;③三层架构分工——EA(企业架构)对接业务战略,SA(方案架构)负责中间件与服务优化,TA(技术架构)专注底层技术实施与基础设施治理;④技术领域划分——将技术栈划分为身份认证、网络、Microsoft 堆栈等领域,每个领域由首席架构师负责其生命周期与路线图;⑤主动规划转型——通过制定 12-24 个月技术路线图,从被动响应转向预测性规划,帮助业务部门规避风险、优化预算、提升交付速度。属 [[AWS-Landing-Zone]] 架构治理层的核心补充,与 [[ctp-topic-47-enterprise-architecture-cloud-standards]](EA 云标准)共同构成企业架构知识体系。
|
||
|
||
**[[ctp-topic-72-enterprise-dr-strategy-aws-backup]]**(CTP Topic 72):AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略与 AWS Backup 架构设计——核心内容:HA(高可用)关注系统运行时间和 MTBF,DR(灾难恢复)专注于防止数据丢失和系统恢复,两者互补;RPO(恢复点目标)定义可接受的最大数据丢失量,RTO(恢复时间目标)定义可接受的最大停机时间;AWS Backup 完全托管、基于策略,通过 Backup Plans 定义何时备份什么,Backup Vaults 存储恢复点,支持跨账户跨区域复制;四级 DR 架构模式(Backup and Restore → Pilot Light → Warm Standby → Active-Active)提供从低成本到高弹性的递进选择;增量备份仅捕获变更,节省成本;Vault Lock 合规模式防止任何人(包括根用户)提前删除恢复点,有效防勒索软件;建议使用独立的 Vault/Bunker Account 存储备份副本,取证账户(Forensic Account)定期测试恢复点并扫描恶意软件。属 [[AWS-Landing-Zone]] DR 与数据保护层的理论基础补充,与 [[ctp-topic-44-aws-backup-in-micro-focus]](聚焦 Micro Focus 内部评估)和 [[ctp-topic-73-aws-backup-implementation]](聚焦 CTP 迁移实施)构成完整的 AWS Backup 知识体系。
|
||
|
||
**[[Install WSL]]**([[install-wsl]]):微软官方 WSL 完整安装指南——`wsl --install` 一键安装(Windows 10/11 Build 19041+),支持 Ubuntu/Debian/SUSE/Kali 等多发行版并行安装,`wsl.exe --set-default-version` 切换 WSL1/WSL2;离线场景通过 MSI + DISM 命令手动启用 Virtual Machine Platform;运行入口推荐 Windows Terminal(含多标签、自定义快捷键)。[[Install WSL]] 与 [[WSL2 启动与网络配置指南]] 互补——前者解决安装问题,后者解决网络配置问题。
|
||
|
||
**[[WSL2]]** 是 Windows 内置的 Linux 运行环境,WSL2 默认使用 NAT 网络模式导致 Windows 代理无法被 WSL2 内部访问。通过 `.wslconfig` 启用 `networkingMode=mirrored` + `dnsTunneling=true` 可实现 WSL2 与 Windows 共享网络堆栈;国内环境下可使用 `ghproxy.com` 反向代理加速 GitHub 下载。[[WSL2]] 与 [[Ubuntu Server]] 同属 Linux 环境,[[WSL2]] 侧重 Windows 桌面开发场景,[[Ubuntu Server]] 侧重无头服务器场景。
|
||
|
||
### Home Server Automation
|
||
Home office setup guides cover a complete multi-node home network infrastructure across 5 nodes: **RackNerd VPS** (public gateway), **Mac Mini M4** (control node), **Synology NAS DS718** (media & storage), and **2 Ubuntu Servers** (monitoring & services). The architecture uses **FRP** (frps/frpc v0.65.0) for reverse tunnel-based intranet penetration, **Caddy** for automatic HTTPS with Let's Encrypt, and **Cloudflare** for DNS托管. **内网穿透方案(VPS + frp + Caddy)**提供完整公网域名访问:Cloudflare DNS A 记录指向 VPS 公网 IP → VPS 运行 frps 和 Caddy → 内网主机运行 frpc 将本地端口映射到 VPS(TCP 隧道)→ Caddy 反向代理到 frp 映射端口,自动申请 Let's Encrypt 证书提供 HTTPS 访问。支持 SSH 穿透(remote_port TCP 映射)不走 Caddy,包含 7 步系统化故障排查(端口监听检查、token 验证、防火墙规则、telnet 诊断等)。 Services deployed include Docker monitoring stack (**Prometheus** + **Grafana** + node_exporter + cAdvisor + blackbox_exporter + Alertmanager), media servers (**Jellyfin**, **Navidrome**, **Transmission**), personal dashboards (**Homarr**, **Apache Superset**), password management (**vaultwarden**), workflow automation (**n8n**), self-hosted Git (**Gitea**), diagram editing (**Draw.io**), developer utilities (**it-tools**), image hosting (**Zipline** + **MinIO**), cloud drive mounting (**CloudDrive2**), AI assistant (**OpenClaw**), e-book management (**Calibre**), proxy client (**v2rayA**), and Docker management (**Portainer**). All services are containerized via Docker Compose. The media workflow follows: Transmission (download) → organize → Jellyfin/Navidrome (play). Key configurations include read-only music mounts, transcode caching (200MB limit), FRP TCP tunnel port mappings (remotePort 60022-60026 for SSH, 13000 for Grafana, 14533 for Navidrome, etc.), Caddy domain mapping table (20+ subdomains under *.ishenwei.online), and SOCKS5 proxy (127.0.0.1:10808) status tracking across all nodes (Mac mini, Ubuntu1, Ubuntu2 working; NAS local-only). **CloudDrive2** enables direct NAS access to cloud storage via virtual filesystem mount (Aliyun Drive resource directory only, scan QR code with App authorization). Backup automation is implemented via rsync incremental sync to NAS, using **Synology DSM NFS** (Squash=admin, sys security, _netdev fstab params) and **nfs-common** client on Ubuntu Server. SSH server setup on Ubuntu 24.04 introduces **ssh.socket activation** (on-demand startup) as the default; administrators can switch to persistent ssh.service mode. Cross-border AI service registration guides cover using **fingerprint browsers** (**AdsPower**), **high-purity US proxies**, **SMS verification platforms** (**PingMe**), and **virtual credit cards** (**WildCard**) to safely subscribe to **Claude Pro**. The architecture provides unified HTTPS public access to all internal services without requiring static IPs, achieving privacy for internal services while maintaining low bandwidth costs.
|
||
|
||
Key concepts: [[Docker-Image]], [[Docker-Save]], [[Docker-Load]], [[Docker Compose]], [[Docker Engine]], [[Docker 用户组]], [[APT 仓库配置]], [[GPG 密钥验证]], [[it-tools]], [[RSSHub]], [[内网穿透]], [[反向代理]], [[TCP隧道]], [[Caddy]], [[frp]], [[Symbolic Link]], [[软链接策略]], [[目录映射]], [[Prometheus]], [[PromQL]], [[Prometheus告警规则]], [[Grafana]], [[node_exporter]], [[cAdvisor]], [[blackbox_exporter]], [[Alertmanager]], [[Uptime Kuma]], [[Netdata]], [[VictoriaMetrics]], [[合成监控]], [[Exporter]], [[时序数据库]], [[TUI]], [[Process Management]], [[System Monitoring]], [[容器资源限制]], [[容器重启策略]], [[端口映射]], [[媒体服务器]], [[转码缓存]], [[只读挂载]], [[增量备份]], [[永久挂载]], [[挂载点检查]], [[Cron定时任务]], [[进程管理]], [[Socket 登录]], [[用户权限]], [[固件刷入]], [[过渡固件]], [[JFFS双清]], [[策略组分流]], [[故障转移]], [[订阅机制]], [[PUID/PGID]], [[桥接网络]], [[Socket Activation]], [[UFW 防火墙]], [[开机自启]], [[VPN Panel]], [[Xray]], [[BBR]], [[Web Proxy Protocol]], **[[全盘镜像备份]]**, **[[裸机恢复]]**, **[[NFS网络备份]]**, **[[UEFI启动]]**, [[指纹浏览器]], [[IP纯净度]], [[虚拟信用卡]], [[接码平台]], [[账号隔离]], **[[云盘挂载]]**, **[[NAS套件管理]]**, [[Root权限修复]], [[SPK套件格式]], [[launchd]], [[Gatekeeper]], **[[图床]]**, **[[S3-兼容对象存储]]**, **[[Docker堆栈]]**, **[[逻辑备份]]**, [[systemd]], [[Ubuntu Server]], **[[BI平台]]**, [[数据可视化]], **[[systemd-logind]]**, **[[HandleLidSwitch]]**, [[休眠目标]], [[pmset]], [[caffeinate]], [[Wake-on-LAN]], [[Headless 服务器]], [[系统睡眠管理]]
|
||
|
||
**Self-Healing Infrastructure Agent**: 基于 [[OpenClaw]] 的家庭服务器自动驾驶代理(代号 "Reef")——通过 SSH 访问家庭网络所有机器,配置 Cron Job 系统(15个活跃任务)实现 24/7 全天候自动化:每 15 分钟检查看板、每小时健康监控+邮件分拣、每 6 小时知识库录入+自检、每日 8AM 晨报(天气/日历/系统状态)、每周安全审计。Agent 可自动执行 SSH、Terraform、Ansible、kubectl 命令修复基础设施问题——"在你知道问题前就修复它"。核心安全策略:TruffleHog pre-push hooks + 私有 Gitea CI 扫描_pipeline + 1Password 专用 AI vault + 每日安全审计(防特权容器/硬编码 secrets/过度权限)。知识提取具有复利效应——一位用户从 ChatGPT 历史中提取了 49,079 条原子事实。Key concepts: [[Morning Briefing]], [[Email Triage]], [[Local-first Git]], [[Defense-in-Depth]], [[Self-Healing-Systems]], [[Agentic AI]], [[Infrastructure-as-Code]], [[Gitea]], [[TruffleHog]], [[ArgoCD]], [[Loki]], [[Gatus]], [[K3s]]
|
||
|
||
### YouTube Automation
|
||
A practical tip for extracting YouTube Channel IDs: use `view-source:` prefix in browser to access channel page source, search for `channel_id` string in the page source to find the RSS Feed URL containing the channel ID. Can be used in [[n8n]] workflows for YouTube subscription monitoring.
|
||
|
||
**本地 RSSHub 部署方案**([[实战笔记-本地部署-rsshub-并获取-youtube-订阅]]):通过 Docker 一键部署 RSSHub(`diygod/rsshub`,端口 1200),使用 `/youtube/channel/{channel_id}` 路由生成 YouTube 频道 RSS 源。相比第三方在线服务,本地部署更稳定可靠,可完全控制数据流向。本地 RSSHub 同时支撑 [[blogwatcher-daily]] Skill 的 YouTube 频道订阅监控(31个频道中18个通过 RSSHub 代理)。
|
||
|
||
**AI-Powered Daily Digest**: [[daily-youtube-digest]] provides a fully automated pipeline — AI Agent periodically checks subscribed channels for new uploads → extracts video transcripts via [[TranscriptAPI.com]] → generates key-point summaries → delivers a daily digest. Runs on [[OpenClaw]] via the `youtube-full` skill (installable from [[ClawHub]]), using 0-credit free API calls for channel checking and 1 credit per transcript for summarization. Supports two modes: channel-based (e.g., @TED, @Fireship, @LexFridman) and keyword-based (e.g., "Claude Code", "AI agents").
|
||
|
||
**[[YouTube-Content-Pipeline]]**:AI Agent 驱动的 YouTube 选题发现与选题自动化流水线——每小时 Cron Job 扫描 Web + X/Twitter 突发 AI 新闻,向 Telegram 推送选题;同时维护 90 天视频目录(播放量 + 主题分析)避免选题重复,通过 SQLite 向量嵌入实现语义去重;在 Slack 分享链接时自动研究主题、搜索 X、查询知识库并创建带大纲的 Asana 任务卡。与 [[Daily-YouTube-Digest]] 互补:后者侧重订阅频道更新监控,前者侧重全网趋势主动发现。与 [[Content-Factory]] 共享并行子 Agent 执行模式。
|
||
|
||
**[[arXiv-Paper-Reader]]**:AI Agent 驱动的 arXiv 论文阅读助手——通过 `arxiv-reader` skill(3 个工具:`arxiv_fetch`、`arxiv_sections`、`arxiv_abstract`)直接从 arXiv 下载 LaTeX 源码并自动扁平化展开,消除 PDF 下载后切换论文丢失上下文和 LaTeX 符号难以解析的痛点;支持摘要浏览、多论文对比排序、选择性细读和会话式分析;本地缓存使重复访问秒级响应;纯 Node.js 零依赖部署。与 [[academic-historian]] 同属学术研究场景互补——前者侧重理工科论文,后者侧重人文社科;与 [[YouTube-Content-Pipeline]] 的 Research Agent 共享研究工作流设计模式。
|
||
|
||
**[[Daily Reddit Digest]]**:AI Agent 驱动的 Reddit 每日精选摘要自动化——通过 [[OpenClaw]] + `reddit-readonly` skill,每日定时抓取指定 Subreddit 的热门/最新/最高赞帖子,AI 记忆用户偏好并持续优化精选规则(如排除表情包类内容)。纯读取模式,无需认证。属 [[Daily YouTube Digest]] 同款模式(定时 + AI 摘要 + 偏好学习)的 Reddit 垂直场景。
|
||
|
||
**Multi-Agent Content Factory**: [[content-factory]] 是基于 Discord 频道的多 Agent 内容工厂,通过 Research Agent → Writing Agent → Thumbnail Agent 链式协作,实现内容创作全流程自动化(研究→写作→设计)。每天定时运行,创作者次日醒来即可收获成品内容。[[OpenClaw]] 提供 sessions_spawn/sessions_send 能力支撑多 Agent 编排。
|
||
|
||
**X/Twitter Automation**: [[x-twitter-automation]] 是基于 [[OpenClaw]] 的 X/Twitter 全功能自动化方案——通过 TweetClaw 插件(`@xquik/tweetclaw`)连接 X/Twitter 托管 API,实现自然语言驱动的发帖、回复、点赞、转发、关注、DM、搜索、数据提取、抽奖选人和账号监控。支持可配置的抽奖筛选条件(最低粉丝数/账号年龄/关键词),账号监控可追踪指定用户的新推文或粉丝变化并推送通知。所有操作通过托管 API 完成,无 Cookie、无爬虫、无凭证暴露。与 [[x-account-analysis]] 互补(分析 vs 操作),可与 [[content-factory]] 配合扩展社交媒体内容发布能力。
|
||
|
||
**[[x-account-analysis]]**:基于 [[OpenClaw]] + [[Bird Skill]] 的 X 账号定性分析方案——通过 Cookie 认证(auth-token / ct0)读取真实账号推文,AI 深入分析内容模式(为何有时 1000+ 赞有时 <5 赞)、话题偏好与互动差异原因。定性分析聚焦"质量"而非"数字",揭示帖子病毒式传播的规律。免费替代 $10-$50/月 的第三方订阅分析服务。核心安全建议:为 OpenClaw 单独创建 [[ClawdBot]] 专用账号而非直接使用真实账号。与 [[x-twitter-automation]] 互补——前者侧重内容质量分析,后者侧重账号操作自动化。
|
||
|
||
Key concepts: [[Channel ID]], [[RSS Feed]], [[X/Twitter-API-Automation]], [[Social-Media-Giveaway]], [[Account-Monitoring]], [[Daily-Digest]], [[Transcript-Based Summarization]], [[TranscriptAPI.com]], [[Chained Agents]], [[Content Automation]], [[Semantic-Deduplication]], [[Vector-Embedding]], [[Knowledge-Base-RAG]], [[arXiv-API]], [[LaTeX-扁平化]], [[本地缓存]], [[论文摘要批量获取]]
|
||
|
||
### n8n Workflow Automation
|
||
[[n8n]] 是开源工作流自动化平台,支持 Trigger 节点监听外部事件。n8n 可与 [[Telegram]] 集成,接收机器人消息触发工作流;也可与 YouTube API 集成实现订阅监控。Telegram 集成时需要通过 `WEBHOOK_URL` 环境变量(设为 HTTPS 地址)解决 Telegram 对 Webhook 协议的要求,否则会报 "bad webhook: An HTTPS URL must be provided for webhook" 错误。
|
||
|
||
**入门教程**:[[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]] 提供了使用 N8N 构建 AI Agent 的完整指南,涵盖五类节点系统(Trigger/Action/Utility/Code/Advanced AI)、Agent 记忆机制、以及与 Airtable 等外部工具的集成方法。教程强调了 Agentic System 的核心概念:Agent 利用 LLM 动态选择工具,结合 Memory 实现上下文保持,使 AI 应用能够根据用户输入自适应响应。
|
||
|
||
**Claude + N8N MCP 自动化工作流**:通过安装 [[n8n-mcp]](Model Context Protocol 多功能控制面板),Claude 可理解并调用 543 个 N8N 节点,自动生成工作流。使用 OpenSea 模型 + Extended Thinking 模式可提升生成质量,Claude 生成的 N8N 工作流完成度约 80%-90%,仍需人工二次修正,但显著降低了新手的入门门槛。两种接入路径:**Claude Desktop** 端侧方案(适合桌面用户,通过本地 MCP 连接 n8n)与 **Claude API** 云端方案(适合程序化集成),核心均依赖 [[Node.js]] 运行环境。
|
||
|
||
Key concepts: [[Webhook]], [[WEBHOOK_URL]], [[n8n Workflow]], [[n8n-mcp]], [[Extended Thinking]], [[工作流自动化]], [[Claude Desktop]], [[Node.js]], [[Webhook-Proxy-Pattern]], [[Credential-Isolation]], [[Lockable-Workflow]], [[Visual-Debugging]], [[Safeguard-Steps]], [[Audit-Trail]]
|
||
|
||
**OpenClaw + n8n Webhook 代理模式**:[[n8n-workflow-orchestration]] 描述了一种将 OpenClaw Agent 外部 API 交互委托给 n8n 的安全架构——OpenClaw 通过 Webhook 调用 n8n 工作流,n8n 持有凭证并执行 API 调用,Agent 完全不知道密钥。核心机制:构建 → 测试 → 锁定循环,确保工作流行为不被 Agent 静默修改。[[openclaw-n8n-stack]] Docker Compose 堆栈提供一键部署,[[Simon-Hoiberg]] 是该模式的提出者。与 n8n-mcp 的互补关系:Claude + n8n-mcp 解决工作流生成问题,本模式解决 Agent 安全集成问题。
|
||
|
||
### Linux System Monitoring
|
||
Six Linux resource monitoring tools reviewed: TUI tools (Btop++, Htop, Glances, Bottom) for SSH-friendly server management; GUI tools (Mission Center, Stacer) for desktop use. Author's top pick: Btop++ for its balance of usability and aesthetics. [[Btop++]], [[Htop]], [[Glances]], [[Bottom]], [[Mission Center]], [[Stacer]], [[TUI]], [[TOTP]], [[Passkey]], [[Self-Hosted Password Manager]]
|
||
|
||
### Linux Operations Command Reference
|
||
A comprehensive Linux command reference covering 150 essential commands across 16 categories: help commands (man, help), file operations (ls, cd, cp, find, mkdir, mv, rm, touch, tree), text processing (cat, grep, sort, uniq, wc, diff, vim), compression (tar, gzip, zip, unzip), system info (uname, dmesg, uptime, du, df, top, free), search (which, locate), user management (useradd, sudo, visudo), networking (ssh, scp, wget, ping, ifconfig, netstat, ss, nmap, tcpdump), disk/filesystem (mount, fdisk, mkfs, mkswap, sync), permissions (chmod, chown, chgrp, umask), process management (kill, crontab, ps, nohup), and system shutdown/restart (shutdown, halt, poweroff). Key insight: Linux treats everything as a file (CPU, memory, disks, keyboard, users). **CPU architecture detection**: `uname -m` (x86_64/aarch64/armv7l), `lscpu` (Architecture field), `cat /proc/cpuinfo` (model name/AArch64), `file /bin/bash` (ELF metadata).
|
||
|
||
Key concepts: [[CPU架构检测]], [[x86_64]], [[aarch64]], [[ARM64]], [[ELF格式]]
|
||
|
||
### Educational Resources
|
||
**[[Build Your Own X]]**:GitHub 上由 [[CodeCrafters]] 维护的精选教程列表(build-your-own-x),收录 26+ 技术领域的分步骤指南,涵盖 3D Renderer、Web Browser、Database、Docker、Git、Operating System、Programming Language、Neural Network 等领域。每条教程引用 Richard Feynman 的名言:"What I cannot create, I do not understand"作为核心理念——通过从零重建主流技术实现深度技术理解。与 [[ChinaTextbook]](教材资源)互补,前者侧重工程实践(重建系统),后者侧重学科理论(课程教材)。
|
||
|
||
ChinaTextbook(TapXWorld/ChinaTextbook)是一个托管于 GitHub 的开源项目,收集中国小学、初中、高中、大学全阶段 PDF 教材,总库大小 41.53GB。教材来源于国家中小学智慧教育平台(basic.smartedu.cn),可通过第三方工具(tchMaterial-parser)下载。覆盖小学 10 门学科(语文、数学、英语、科学,音乐、美术、体育与健康、道德与法治等)、初中 17 门学科、高中 18 门学科,以及大学阶段概率论、离散数学、线性代数、高等数学等基础课程。
|
||
|
||
**免费 AI 学习资源全景**([[learn-ai-for-free-directly-from-top-companies]]):@RodmanAi 汇总的 10 家顶级科技公司免费 AI 学习资源——Anthropic(Skilljar 培训平台)、Google(Grow.google/AI 学习路径)、Meta(AI 资源中心)、NVIDIA(CUDA 开发者课程)、Microsoft(Microsoft Learn)、OpenAI(Academy)、IBM(SkillsBuild)、AWS(Skill Builder)、DeepLearning.AI(吴恩达课程)、Hugging Face(学习路径)。核心价值:**免费获取权威 AI 培训内容**,无需付费订阅。与 [[Claude Prompt Library]](Anthropic 官方提示词库)属同一教育生态。
|
||
|
||
Key concepts: [[国家中小学智慧教育平台]], [[tchMaterial-parser]], [[ChinaTextbook]], [[Build-Your-Own-X]], [[BYOX]], [[Learn-By-Building]], [[From-Scratch-Methodology]], [[CodeCrafters]], [[NAND-to-Tetris]], [[AI教育]], [[免费学习资源]]
|
||
|
||
### AI Tools & Prompt Engineering
|
||
Covers Claude Code, Claude Code Templates (npx 一键安装 Skills/Agents/MCP via `npx claude-code-templates@latest --skill=<path> --yes` from aitmpl.com), OpenCode, [[Cursor]], [[Trae]], Gemini CLI, Vibe Coding, [[RAG]], multi-agent workflows, NotebookLM, Nano Banana prompting, and video generation tools.
|
||
|
||
**Claude Skills 范式**([[3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1]]):Anthropic 官方 Skills 仓库(github.com/anthropics/skills,3.2 万收藏)将 Claude.ai 网页版的生产级能力原封不动拆解展示,包含办公自动化(Word/PDF/PPT/Excel)、开发者工具箱(MCP Server/自动化测试/Artifacts 构建)和创意类 Skill。核心洞察:**Skills = 说明书 + SOP**,将反复执行的有固定流程的任务拆解为 AI 能理解、能复用、能自动执行的一套流程。Claude Skills 的爆发标志着从「提示词工程」向「流程工程」的范式转变——最有价值的不是 Prompt 写得最花,而是能把业务流程沉淀成 SOP 并交给 AI 稳定执行。Vibe Coding 的尽头也是 Skills。三大 Skill 聚合站(skillsmp.com、aitmpl.com/skills、claudemarketplaces.com)可"拿来主义"直接使用;3 款高产开源 Awesome-Claude-Skills 仓库(ComposioHQ/VoltAgent/BehiSecc)提供系统性灵感。
|
||
|
||
**Vibe Coding 中文指南**([[github-上-5000-人收藏的-vibe-coding-神级指南]]):介绍 vibe-coding-cn 开源项目(github.com/tukuai/vibe-coding-cn),为中文开发者汇集全球顶尖 AI 编程资源。核心公式:**Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行**,让「从想法到可维护代码」变成可审计的流水线,而非一团无法迭代的巨石文件。工具推荐:Cursor + Claude Opus(高 context window 保证上下文一致性)。包含方法论、提示词优化技巧(需求澄清/系统架构设计/分步执行/自测全链路脚本)和完整开发流程教程。核心理念:**规划就是一切**——让 AI 写代码前必须先完成技术选型、实施规划和模块化设计,防止 AI 因理解偏差导致项目逻辑混乱。[[系统提示词构建原则]] 提供了该框架的详细行为准则——从身份定义(遵守项目约定、优先技术准确性)到具体执行规范(TODO 规划、Search/Replace 编辑、精确搜索策略),构成 Vibe Coding 的操作层指南。
|
||
|
||
**Gemini 3 十应用实战**([[我用-gemini-3-一口气做了-10-个应用-附教程]]):使用 Google [[Gemini-3]] 模型通过对话式提示词构建 10 个实用可视化应用(冷知识卡片/配色卡片/电影海报/绘画思维导图等)。核心方法论:①限定垂直场景(诗词/小说/电影)→ ②用提示词约束结构化输出(JSON/SVG)→ ③用前端 SVG/HTML 作为输出容器。三步核心机制:**AI 生成 SVG 代码 → 前端渲染为精美卡片/海报/导图**。该方法论与 [[Vibe-Coding]] 的"对话驱动 + AI 结对"理念高度契合——通过限制输入场景降低 AI 理解成本,通过提示词约束结构化输出,通过前端代码作为最终容器,是 Vibe Coding 在 AI 可视化产品方向的具体实践。
|
||
|
||
**[[fireworks-tech-graph]]**:Claude Code Skill,将自然语言描述转化为精美 SVG 技术图并导出 PNG——解决技术文档/博客缺乏高质量可视化图表、手动绘图耗时且风格不统一的核心痛点。内置 **7 种视觉风格**(扁平图标风/暗黑极客风/工程蓝图风/Notion极简风/玻璃态卡片风/Claude官方风格/OpenAI官方风格)和 **14 种 UML 图类型**,深度覆盖 AI/Agent 领域常见 Pattern(RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 流程等)。语义形状词汇表确保图形语义一致(LLM=双边框圆角矩形、Agent=六边形、Vector Store=带内环圆柱),语义箭头系统通过颜色+虚线编码含义(主数据流/控制触发/记忆读取/写入/异步/反馈循环)。通过 `rsvg-convert` 导出 1920px PNG,可直接嵌入文章发布。安装:`npx skills add yizhiyanhua-ai/fireworks-tech-graph`,依赖 `librsvg`(macOS: `brew install librsvg`,Ubuntu: `sudo apt install librsvg2-bin`)。核心价值:**AI Agent 可快速生成专业级技术图,无需手动绘制**,支持 SVG 可编辑 + PNG 无损发布。
|
||
|
||
**Claude Prompt Library**([[useful-prompt-lib]]):Anthropic 官方提示词库,收录 64+ 款专业化提示词,覆盖开发工具(Python Bug Buster、Code Consultant、Git Gud)、效率工具(Data Organizer、Review Classifier、CSV Converter)、创意工具(Storytelling Sidekick、Culinary Creator)、营销工具(Babel's Broadcasts 多语言推文、Polyglot Superpowers 互译)、教育工具(Meeting Scribe、Lesson Planner、Socratic Sage)等 10+ 领域。TikTok 跨境电商推荐三剑客:Babel's Broadcasts(10 种语言产品发布)、Review Classifier(评论自动化分类)、Data Organizer(非结构化文本→JSON,对接 n8n 工作流)。
|
||
|
||
**LLM / RAG / AI Agent 三层架构**:基于 [[llms-rag-ai-agent-三个到底什么区别]] 的系统梳理,AI 应用的三层架构:
|
||
- **[[Large Language Model]]**:思考层(天才大脑),负责推理生成,但知识有截止日期
|
||
- **[[RAG]]**:认知层(记忆系统),将 LLM 链接外部知识库,消除幻觉、提供可追溯来源
|
||
- **[[AI Agent]]**:执行层(行动系统),感知→规划→执行→反思的循环控制,实现真正自主性
|
||
|
||
**[[RAG从入门到精通系列1-基础rag]]**:RAG 系列教程第一篇,系统讲解基础 RAG 的 Indexing(文档加载→切分→向量化入库)→ Retrieval(向量相似度检索 Top-k 文档块)→ Generation(问题+上下文→LLM 生成带事实依据的答案)三阶段流程。实战工具链:Qwen(LLM)+ BAAI(BGE Embedding)+ LangChain(应用编排)+ Qdrant(向量数据库)。配套 Jupyter Notebook 演示完整 Pipeline,LangSmith 可视化调试。是 [[rag从入门到精通系列1-基础rag]] 系列的基础入门篇。
|
||
|
||
入门术语参考:[[大模型相关术语和框架总结]] 提供 LLM、Prompt、MCP、Agent、RAG、Embedding、vLLM、Token、数据蒸馏等核心概念的通俗解释,可作为三层架构体系的术语速查手册。与 [[llms-rag-ai-agent-三个到底什么区别]](系统梳理)属互补关系——前者入门科普,后者架构深化。
|
||
|
||
核心洞察:未来不在于选择其一,而在于将三者结合架构设计。
|
||
|
||
**ChatGPT 个性化配置**:基于 [[openai-chatgpt-个性化定义]] 的用户完整配置案例,展示如何通过 ChatGPT 自定义指令将通用 AI 塑造成专属协作者。核心配置原则包括:[[Expert User Assumption]](将用户视为所有领域专家,无需简化技术细节)、[[Proactive AI]](主动预判需求而非被动等待)、[[Error Accountability]](错误零容忍且主动反馈配置导致的回复质量下降)。[[Custom Instructions]] 通过两条配置(自定义指令 + 用户详情)永久定义 AI 行为,无需每次对话重复说明。[[Personalization]] 的关键是系统性配置——错误政策、引用格式、推测告知、内容政策冲突处理——而非零散提示词。
|
||
|
||
**[[AI图生视频工具盘点]]**:基于 [[14个免费的AI图生视频工具-用ai让图片动起来]] 的综合分析,介绍了14个免费AI图生视频工具,覆盖阿里巴巴(绘蛙、通义万相、万相营造)、字节跳动(即梦AI)、快手(可灵AI)、智谱AI(智谱清影)、MiniMax(海螺AI)、生数科技(Vidu)、爱诗科技(PixVerse)、潞晨科技(Video Ocean)、智象未来(Viva)、MewXAI(艺映AI)、Stability AI(Stable Video)等厂商。核心能力包括:文本提示词控制运动、动作模板选择、运镜参数调节、首尾帧精准控制、主体一致性保持、音效自动生成等。电商场景(模特图动态化、商品展示)、视频创作(创意短片)、广告制作是三大主要应用方向。与 [[文字生成视频网站推荐]] 属同类AI视频生成工具的不同角度——前者侧重点图生视频,后者侧重文生视频。
|
||
|
||
**[[电商视频Prompt库]]**:基于 [[电商视频prompt]] 的 AI 生成宠物电商视频模块化 Prompt 库——7 大模块(产品展示/宠物动作/衣服防穿帮/场景变化/Negative Prompt/卖货文案/全流程示例),以"拼积木"方式组合使用,实现**低翻车率 + 高真实感**的 TikTok Shop 带货视频生成。核心原则:宠物衣服必加防穿帮模块,场景变化作为加法叠加而非写死;可扩展至 1 产品 → 3 条视频 → 6 条文案 → A/B 测试全链路自动化。与 [[AI图生视频工具盘点]](工具盘点)和 [[做TK跨境思路不对努力白费]](运营策略)共同构成 TikTok 跨境电商内容生产的完整知识链条。
|
||
|
||
**[[固定镜头短视频制作的AI全流程解析]]**:基于固定机位 + 内容连续变化 + 时间压缩三大原理的家装短视频 AI 制作方法论——分镜拆解(Google AI Studio)→ 九宫格图像生成(Midjourney/Nano Banana)→ 首尾针动画(海螺AI/KAI)→ 快节奏剪辑(剪映)→ 声音设计,10 分钟内完成成片。核心突破:九宫格一次性生成保证画面一致性,首尾针动画替代复杂转场,硬切反而更干净。适用于所有固定机位且状态变化明显的短视频类型。与 [[AI图生视频工具盘点]] 同属 AI 视频创作工具应用,后者侧重工具评测,前者侧重完整工作流程。
|
||
|
||
**NotebookLM 开源平替生态**:基于 [[google-神级生产力工具-所有-github-开源平替都找到了]] 的系统梳理,Google [[NotebookLM]] 作为 AI 笔记助手标杆,支持文档问答和播客生成两大核心能力,GitHub 上已形成完整的开源替代生态:[[OpenNotebook]](14.6k Stars,全功能本地化,支持 16+ AI 提供商和本地模型)是 Star 最高的平替;[[SurfSense]](11.4k Stars)定位为 NotebookLM + Perplexity + Glean 的综合替代,支持语义+全文混合搜索和团队 RBAC;[[Podcastfy]] 专注播客生成,整合 100+ LLM 和多种 TTS 引擎;[[NotebookLlama]](LlamaIndex 官方项目)展示文档转播客的完整技术链条;[[PageLM]] 聚焦教育场景,提供康奈尔笔记和间隔重复闪卡;[[InsightsLM]] 采用 Supabase + N8N 低代码架构,支持完全离线部署。该生态覆盖从"全功能替代"到"垂直聚焦"的不同需求层次。与 [[Personal Knowledge Base (RAG)]](文档检索知识库)同属 AI 驱动的知识管理工具,但 NotebookLM 生态侧重"文档→对话/音频"的交互形态。
|
||
|
||
**[[7-ways-i-use-notebooklm-to-make-my-life-easier]]**:NotebookLM 7种日常生活场景实测——①处理信息积压(将未读 PDF/文章/视频上传,AI 自动消化,用户通过问答提取要点);②播客笔记(Audio Overviews 将文档转为双 AI 主持的对话播客,适合驾驶/健身等被动学习场景);③快速成为多主题专家(将 Batman/Star Wars 宇宙资料或 Jupiter/Marine Corps 等专业领域文档上传,通过播客辩论式学习);④编程辅助(上传官方文档,上下文学习,提供引用回溯);⑤项目管理中枢(将零散研究、想法、会议记录整合为结构化路线图,作者用此法一年做出 6 个 App);⑥版本对比(对比 App 更新、新闻稿、长文档差异,列出具体变化并附带引用);⑦法律文档审核(租约/合同分析,每个答案附引用,可一键回溯原文核实)。核心机制:[[Source-Grounding]]——知识库严格限定于可信文档,确保答案有据可查。Premium 版提供更完整的功能。与 [[Second Brain]](对话记忆捕获)同属个人知识管理,NotebookLM 侧重文档驱动的问答与音频交互。
|
||
|
||
**AI 开源平替生态**:基于 [[2025-年-11-个神级-ai-开源平替-github-杀疯了]] 的系统盘点,GitHub 上各 AI 领域已形成完整的开源平替生态——大语言模型([[DeepSeek]] R1/V3、Qwen 3)、AI 生图([[Flux]]、Stable Diffusion)、AI 生视频([[HunyuanVideo]] 混元视频)、AI 智能体([[OpenManus]] 对标 [[Manus]])、AI 编码([[Cline]] 对标 [[Cursor]])、工作流自动化([[n8n]] 16万 Star、[[Dify]])、AI 搜索([[Perplexica]] 对标 Perplexity)。核心洞察:国产开源模型在多个领域已达到或超越国际闭源竞品水平,[[DeepSeek]] R1 是开源界首个将 o1 级深度推理拉下神坛的破壁者,[[Manus]] 则定义了 AI Agent 元年并被 Meta 收购。
|
||
|
||
**[[custom-morning-brief]]**:基于 [[OpenClaw]] 的晨间简报自动化——每天定时(例 8AM)通过 Telegram/Discord/iMessage 推送结构化报告,内容涵盖:新闻研究(AI/创业/科技方向)、当日待办事项(集成 Todoist/Apple Reminders/Asana)、主动任务推荐(AI 自主思考可帮助完成的事项)、睡前完成的完整草稿(脚本/邮件/商业方案,而非仅标题)。核心洞察:**主动任务推荐**是整个系统最有价值的部分——AI 主动思考如何帮助用户,而非被动等待指令;完整草稿(full draft)比标题建议节省大量时间;用户只需发消息即可调整简报内容,无门槛个性化。与 [[self-healing-home-server]] 的 Morning Briefing 属同一模式的不同垂直场景。
|
||
|
||
**[[family-calendar-household-assistant]]**:基于 [[OpenClaw]] 的家庭日程协调与物资管理方案——聚合 5+ 个分散日历(工作/个人/家庭/学校/课外)生成每日晨间简报;通过环境消息监控(Ambient Message Monitoring)自动从 iMessage 中识别预约并创建日历事件(含行车时间缓冲);维护家庭库存 JSON(冰箱/储藏室),支持照片 OCR 和小票识别更新;生成购物清单。核心洞察:**Ambient > Active**——Agent 在不被要求时主动行动才是最大突破;Mac Mini 是该场景的最优硬件(iMessage 集成 + 始终在线)。与 [[Custom Morning Brief]] 属同一晨间简报模式的不同场景(个人 vs 家庭)。
|
||
|
||
**Todoist Task Manager**:基于 [[OpenClaw]] 的 AI 驱动任务管理自动化——Agent 解析自然语言指令("这周完成 Q1 报告")→ 调用 Todoist REST API 创建结构化任务(含截止/项目/标签)→ Cron Job 定时扫描逾期任务主动推送提醒。与 [[multi-channel-assistant]] 中 Todoist 集成属同一技术栈,Todoist Task Manager 侧重任务管理的深度自动化(Cron 追踪/会议→任务闭环),multi-channel-assistant 侧重多渠道入口的统一体验。
|
||
|
||
**Health & Symptom Tracker**:基于 [[OpenClaw]] 的食物敏感性自动追踪方案——通过 Telegram 话题记录食物和症状,Cron Job 每日三餐定时提醒(8AM/1PM/7PM),OpenClaw 自动解析消息并带时间戳写入 Markdown 日志,每周分析关联模式识别潜在触发因素。无需专用 App,完全自托管。
|
||
|
||
**Habit Tracker & Accountability Coach**:基于 [[OpenClaw]] 的 AI 主动问责习惯追踪方案——通过 Telegram/SMS 每日定时签到,替代被动习惯追踪 App。与 [[Health & Symptom Tracker]] 属同一框架(OpenClaw + Telegram + Cron Job + 每周模式分析),但垂直于个人习惯养成而非健康追踪。核心洞察:**主动问责**(AI 直接询问)比被动记录更能驱动行为改变;保持 3-5 个习惯可避免签到疲劳;[[Adaptive Tone]] 自适应语气是关键差异化因素。
|
||
|
||
**AI-Powered Earnings Tracker**:基于 [[OpenClaw]] 的财报季自动化追踪方案——每周日 6PM 扫描财报日历并过滤用户关注公司(NVDA/MSFT/GOOGL/META/AMZN/TSLA/AMD),Telegram 投递预览列表;用户确认后为每家公司调度一次性 Cron Job,财报发布后自动搜索、格式化摘要(beat/miss、营收、EPS、AI 亮点、指引)并投递。与 [[Daily YouTube Digest]] 同属 Cron Job + AI 摘要 + Telegram 投递模式的不同实例。
|
||
|
||
**Event Guest Confirmation**:基于 [[OpenClaw]] + [[SuperCall]] 的活动嘉宾自动确认方案——通过 AI 语音电话批量外呼客人,确认出席状态并收集备注(饮食禁忌、Plus-One、到达时间等),通话完成后生成出席确认/未出席/未接听三分类摘要。核心价值:真人电话比短信/文字消息回复率更高;SuperCall 的沙盒 persona 设计确保 AI 只拥有预设上下文,无法访问用户 Agent 或数据,无 Prompt Injection 风险;每通电话独立重置,无对话间信息混淆。与 [[phone-based-personal-assistant]] 同属 AI 电话外呼场景,但 [[SuperCall]] 的独立沙盒设计更适用于确认类单一任务。
|
||
|
||
**[[personal-crm]]**:基于 [[OpenClaw]] 的个人 CRM 自动联系人发现系统——每日 Cron Job 扫描 Gmail 和日历,自动提取新联系人并更新 SQLite 数据库(姓名、邮箱、首次出现时间、最后联系时间、互动次数、备注);通过 Telegram personal-crm topic 提供自然语言查询接口("Who needs follow-up?"、"When did I last talk to [person]?");每日 7AM 会议前简报自动研究外部参会者并推送背景资料(含上次交流内容和待跟进事项)。核心价值:**零手动录入,AI 自动维护联系人关系记忆**,让每次会议都有准备。需 [[gog CLI]] 提供邮件和日历数据。与 [[local-crm-framework]](DenchClaw)和 [[Second Brain]] 同属 OpenClaw 持久化记忆能力的不同应用场景——personal-crm 侧重结构化联系人和会议准备。
|
||
|
||
**Local CRM Framework**:基于 [[OpenClaw]] 的本地 CRM 框架 [[DenchClaw]]——通过 `npx denchclaw` 一键安装完整技术栈(DuckDB + Web UI + OpenClaw Profile + 浏览器自动化),所有设置/视图以 YAML/Markdown 文件存储,Agent 可直接修改 UI 而无需 API 抽象层。核心创新:Chrome Profile 克隆使 Agent 继承用户认证状态,可直接导入 HubSpot 等平台数据。[[Second Brain]] 和 [[personal-crm]] 均属同类 OpenClaw 持久化记忆能力的不同应用场景。
|
||
|
||
**Goal-Driven Autonomous Tasks**:[[overnight-mini-app-builder]] 是基于 [[OpenClaw]] 的目标驱动型自主任务方案——每天清晨 8:00 自动生成 4-5 个贴近目标的自主任务(研究/写作/竞品分析/MVP 构建),通过 Next.js Kanban 看板实时追踪,进度透明可见。核心洞察:**将"规划"和"执行"都外包给 AI Agent,用户只需定义目的地,Agent 自动分解并执行每日步骤**。该方案还包含过夜惊喜 Mini-App 构建模式——指示 Agent 构建 MVP,每天醒来即收获一个新产品原型。与 [[market-research-product-factory]] 同属 Alex Finn 启发的 OpenClaw 高阶用法,但前者侧重任务追踪和持续执行,后者侧重产品机会发现。与 [[Project State Management]] 的看板 vs 事件溯源存在潜在冲突。核心工程实践:**Git-style append-only 日志模式**(主会话管 AUTONOMOUS.md 状态,子代理只追加 tasks-log.md)解决多 Agent 竞态条件;[[Token-Light Design]] 保持 AUTONOMOUS.md 在 50 行以内避免心跳轮询 token 浪费。
|
||
|
||
**Pre-Build Idea Validator**:基于 [[OpenClaw]] + [[idea-reality-mcp]] 的 AI 项目启动前竞争分析门控——在写代码之前自动扫描 GitHub/Hacker News/npm/PyPI/Product Hunt 五个数据源,返回 `reality_signal` 分数(0-100)评估赛道拥挤度:高分数(>70)触发 STOP(展示竞品+询问是否继续/转向),低分数(<30)直接构建。核心价值:**在投入时间前发现已解决的同类问题**,是单兵创业者最重要的决策门控。与 [[market-research-product-factory]] 互补:后者挖痛点找方向,前者在动手前验证赛道的竞争密度。
|
||
|
||
**Never Write Another Prompt**:基于 YouTube 视频的工具介绍,展示一款将简单描述自动转化为详细结构化提示词的 AI 工具——用户无需具备提示词工程专业知识,只需输入简单描述即可获得专业级提示词,支持变量插入和自定义编辑。与 [[Claude Prompt Library 汇总表]](现成提示词库)和 [[Nano Banana 提示词框架]](结构化模板)同属提示词工程的不同路径——本工具侧重自动化生成,后者侧重模板规范。市场上单个专业提示词售价 $100-$500,本工具大幅降低了使用门槛。
|
||
|
||
**[[清华出的DeepSeek使用手册]]**:清华大学发布的《DeepSeek从入门到精通2025》官方使用指南(104页),由新闻与传播学院元宇宙文化实验室余梦珑博士后及团队撰写。与其他泛化教程不同,该手册强调"授人以渔"——不仅教用户"怎么问",更教"为什么这么问",帮助用户掌握提示词底层逻辑。涵盖 DeepSeek-R1 模型选择、提示语设计技巧、避免 AI 幻觉策略等核心内容。与 [[llms-rag-ai-agent-三个到底什么区别]] 同属 AI 工具方法论,但该手册聚焦 DeepSeek 特定实践。来源:[[清华出的DeepSeek使用手册,104页,真的是太厉害了!(免费领取)]]
|
||
|
||
**[[如何写出完美的Prompt-提示词]]**:系统阐述 Prompt 构建底层逻辑的职场应用指南——核心理念:Prompt 是一套人与 AI 的协作协议,本质是将模糊需求转化为 AI 可执行的结构化任务。四大构建要素(角色+需求+场景+目标)+ 三层技巧体系(基础:需求拆解/上下文补全/格式定义/示例引导;进阶:思维链/任务拆分/角色赋能/预填回复/不确定性管理;高阶:跨模态联动/领域知识注入/反馈循环嵌入)+ 四大业务场景实战模板(内容创作/数据分析/方案策划/客户服务)+ 六大避坑指南。核心洞察:Prompt 能力的本质是有对问题清晰界定的能力 + 结构化的思维逻辑和表达能力,这决定了人能否用好 AI。与 [[清华出的DeepSeek使用手册]](DeepSeek 特定实践)和 [[系统提示词构建原则]](Agent 系统级指令)互补,构成完整的提示词工程方法论体系。
|
||
|
||
**[[Nano Banana 提示词框架]]**:Nano Banana 基础框架文档,提供两套结构化 JSON Schema 模板——物件描述框架(item / materials / details / condition)和人物描述框架(age / appearance / pose)——共用法学 shot / environment / lighting / camera / color_grade / style / quality / negatives 参数字段。将艺术总监级别的专业摄影描述语言转化为可结构化填写的模板,降低 AI 图像生成的专业门槛。与 [[Nano Banana Pro 提示词指南]](进阶版)和 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]](综合版)同属 Nano Banana 提示词体系。
|
||
|
||
**[[Nano Banana 2 国内使用指南]]**:基于 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]],Nano Banana 2(Gemini 3 Pro Image)是 Google 发布的推理型图像生成模型——在生成图像前会进行内部推理,自动补完提示词的深层次需求,支持 1K/2K/4K 分辨率输出,最多可将 14 张输入图像组合为 1 张输出,擅长中文界面渲染、科研配图、技术路线图、教学插画等高准确性要求的图像创作。国内用户可通过 [[DeepSider]] 浏览器插件(deepsider.ai,Edge 扩展)直接访问,无需特殊网络和海外账户,插件同时支持 GPT5/GPT4.1/Claude/Gemini 2.5 Pro/Grok/Sora 2 等数十款 AI 模型。与 [[Nano Banana Pro 提示词指南]](进阶专业提示)和 [[Nano Banana 提示词框架]](结构化模板)同属 Nano Banana 提示词体系。
|
||
|
||
**[[Nano Banana Pro 提示词指南]]**:谷歌发布的 Nano Banana Pro 官方提示词指南(《The Complete Guide to Nano Banana Pro: 10 Tips for Professional Asset Production》,含上下两篇),凌晨无预警发布,核心主题是"将 AI 从趣味性图像生成升级为功能性专业资产生产"。核心理念:**停止标签堆砌,像创意总监一样思考**。核心突破:意图理解引擎实现物理规则推演、构图美学理解和语义上下文推理(而非传统关键词匹配)。关键能力:支持 14 张参考图像(6 张高保真)实现"身份锁定";默认生成思考图像(不收费)后再输出最终结果;支持 1K-4K 原生高分辨率;[[Google Search]] 信息锚定减少实时内容幻觉。10 大黄金法则包括:编辑而非重新生成、使用自然语言完整句子、具体且具描述性、提供上下文("为什么"或"为谁")。上篇([[nano-banana-pro-prompting-guide-strategies-1]])覆盖前 9 个能力域(文本渲染/信息图、角色一致性/病毒缩略图、Google 搜索信息锚定、高级编辑/修复/着色、2D/3D 维度转换、高分辨率/纹理、思考推理、故事板/概念艺术、结构控制/布局引导),附大量可直接复制的实战提示词模板。与 [[清华出的DeepSeek使用手册]] 同属 AI 工具方法论指南——前者聚焦 DeepSeek 文本推理,后者聚焦 Nano Banana Pro 图像生成;与 [[nano-banana-提示词框架]](Nano Banana 基础框架)和 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]](Nano Banana 2 综合指南)同属 Nano Banana 提示词体系的不同层次。
|
||
|
||
**[[Ollama 本地 LLM 部署]]**:基于 [[详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1]] 的完整实操指南,展示如何使用 Ollama + DeepSeek-R1 + Open WebUI 在本地离线部署大模型。核心价值:**免费、无需 API Key、数据完全私有**。Ollama 跨平台支持(macOS/Windows/Linux/Docker),通过 `ollama run deepseek-r1:8b` 一键运行;国内网络环境下可通过魔塔社区(modelscope.cn)或 HuggingFace Mirror(hf-mirror.com)加速下载;云服务器部署必须通过 nginx + Bearer Token 保护 API 防止恶意调用;Open WebUI 提供浏览器端 Web 界面,支持 RAG 本地知识库(bge-m3 嵌入模型)和联网搜索。硬件要求:1.5B 模型需 4GB RAM,7B 需 16GB RAM,32B 需 64GB RAM+48GB 显存(Apple M2 Max 可流畅运行 32b 及以下)。
|
||
|
||
**[[Qwen2.5-Coder]] 部署实战**([[在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b]]):Ubuntu 上通过 Ollama 本地部署 Qwen2.5-Coder 7B 代码生成模型,3条命令完成安装(`curl -fsSL https://ollama.com/install.sh | sh && ollama pull qwen2.5-coder:7b && ollama run qwen2.5-coder:7b`)。推荐配置:8+ CPU cores + 16GB RAM + NVIDIA GPU(CUDA 自动加速)。**qwen2.5-coder:7b 因 Tool usage 能力强、Shell/Python/SQL 理解强、Repo 级代码理解强,比普通 qwen2.5:7b 更适合工程任务**。支持 REST API(默认 localhost:11434)和 Python/Node.js SDK,可与 [[Open WebUI]]、[[n8n]]、[[OpenClaw]] 等工具集成构建本地 AI 应用栈。与 [[Ollama 本地 LLM 部署]](DeepSeek-R1)同属 Ollama 本地部署场景,本方案侧重 Qwen2.5-Coder 的代码生成能力优势。
|
||
|
||
**Claude Code 调用方法**:[[claude-code调用方法总结]] 详细记录了 Hermes Agent 通过 `terminal` 工具调用 Claude Code 的两种模式——Print Mode(`claude -p`,适合绝大多数任务)和 TMUX 交互模式(适合超长任务)。核心参数包括 `--permission-mode bypassPermissions`(跳过所有权限确认)和 `--add-dir`(加载 SKILL.md)。关键结论:当任务需要 Claude Code 的 Skill 时,应使用 `terminal` 调用 `claude -p` 而非 `delegate_task`。
|
||
|
||
**Mac 必装软件清单**([[mac必装软件清单-2026-04-17]]):精选 8 款 Mac 必备软件——Claude(AI 助手)、Obsidian(AI 知识库)、Chrome(浏览器)、Rectangle(分屏工具)、iShot(截图录屏)、Lemon(系统清理)、Raycast(启动器)、Homebrew(包管理器)。核心理念:**用最少的软件达到最高的效率**。[[Homebrew]] 是用 Claude Code 搭 Agent 的前置依赖,[[Obsidian]] 搭配 [[Claudian]] 可打造 AI 驱动的终极个人知识库。与 [[Second Brain]] 和 [[Personal Knowledge Base (RAG)]] 同属知识管理场景。
|
||
|
||
**baoyu-imagine AI Logo 生成**:[[我做了个-skill-让-ai-帮你生成-logo-和图标]] 介绍了一个 Claude Code Skill `baoyu-imagine`(`npx baoyu-imagine` 安装),通过 Logo 专用提示词策略驱动 AI 生图工具生成专业 Logo 和图标。核心价值:让非设计师快速产出扁平化/几何/手绘/渐变等多种风格的专业品牌视觉资产,支持 SVG(矢量缩放)和 PNG 格式导出。与 [[Nano Banana]] 提示词体系(侧重摄影/插画/科研配图)同属 AI 图像生成工具链,baoyu-imagine 专注于 Logo/图标这一垂直场景。
|
||
|
||
**Coze 平台多行业 AI Agent 培训**([[ai-解决方案专家培训课程]]):Coze(扣子)平台的实战培训课程,分国内版(coze.cn)和海外版(coze.com),提供覆盖金融(客户分层营销、智能客服)、医疗(分诊助手、影像识别)、教育(知识库问答、拍照搜题)、电商(混剪助手、在线换衣、抖音直播回复)、人力资源(招聘打分、面试对练、AI 培训对练)、泛娱乐(AI 证件照、视频生成工作流)、在线客服(AI 助教、AI 销售)等 7 大行业共 50+ 可体验 Agent Demo,是 AI 解决方案专家培训的实操案例库。与 [[Prompt Engineering]](提示词技能)、[[RAG(检索增强生成)]](知识库问答)、[[Function Call]](工具调用)三大基础能力配套,学员可通过邀请链接直接加入团队空间体验所有 Agent,并可 Fork 改造。与 [[固定镜头短视频制作的AI全流程解析]] 的 AI 视频生成工作流相关联。
|
||
|
||
**AI辅助PRD生成**:[[不会gemini的产品经理真的要淘汰]] 展示了大模型在产品经理工作流中的实战应用——通过 FeatureList 构思框架 → Mermaid 逻辑图辅助理解 → 分页面逐一描述生成 PRD+HTML 原型,可缩短文档工作时间 90% 以上。核心方法论:人负责"想"(创意决策),大模型负责"写"(格式补全)。
|
||
|
||
**[[autonomous-game-dev-pipeline]]**:基于 [[OpenClaw]] 的 AI Agent 全自动教育游戏开发流水线——每小时轮询队列产出 1 款儿童 HTML5 游戏,通过 "Bugs First" 优先策略(先修 bug 再做新功能)、Round Robin 年龄组均衡分配、纯 HTML5/CSS3/JS 无框架技术栈,实现单人维护 41+ 款游戏。核心工程纪律:同步 master → feature branch → conventional commits → PR merge,每次交付自动更新 CHANGELOG 和队列状态。核心价值:**每 7 分钟产出 1 款游戏或 1 个 bugfix**,单人可管理完整产品线。与 [[content-factory]] 同属 Agent 自动化内容生产,但前者侧重多 Agent 协作链,本方案侧重单人 Agent 的高纪律性流水线。
|
||
|
||
**[[aionui-cowork-desktop]]**:基于 [[AionUi]] 的 OpenClaw 桌面可视化 + 远程救援方案——通过 AionUi 的 Cowork 工作空间,用户可直接看到 OpenClaw 读写文件、运行命令、浏览网页,而非仅终端日志;内置 OpenClaw 部署专家,通过 Telegram/WebUI 远程诊断修复(`openclaw doctor`),解决"OpenClaw 挂了且不在机器旁"的困境;统一 MCP 配置一次,全局同步到 OpenClaw + 12+ 其他 Agent。与 [[Self-Healing-Home-Server]] 的远程修复场景关联,[[Multi-AgentHub]] 共享同一多 Agent 并行管理理念。
|
||
|
||
**播客制作自动化**:[[podcast-production-pipeline]] 提供 AI Agent 全自动播客制作流水线,覆盖「录前研究→大纲脚本→录制→时间戳笔记→社媒推广包→SEO描述」全链路。与 [[Content Factory]] 配合可将播客内容复用为博客、Newsletter、视频片段等多格式资产。
|
||
|
||
**Google ADK Skill 设计模式**:Google Cloud 发布的 5 种结构化设计模式,**[[ToolWrapper]]**(按需加载领域知识)、**[[Generator]]**(模板填空生成)、**[[Reviewer]]**(检查逻辑分离)、**[[Inversion]]**(先收集再行动)、**[[Pipeline]]**(硬性检查点工作流)。Anthropic 的 Skill 实践:内部几百个 Skills 总结出 3 条铁律——只写 Agent 不知道的东西、重点写踩坑清单、给工具不给指令。
|
||
|
||
**MCP 在 Cursor 中的集成**:MCP(Model Context Protocol)是基于 Client-Server 架构的协议,通过三种接口(GET 资源获取、POST 工具调用、Promise 提示词)实现 AI 大模型与外部工具的高效集成。在 Cursor 中有两种接入方式:SSE 服务端模式和本地 Command 命令行方式。在 Composer 的 Agent 模式下可自动执行 MCP 工具链,典型应用包括热点新闻服务(smisery 提供九个新闻来源)和 Sequential Thinking 逻辑推理工具。启用 Yolo Mode 可无确认自动执行命令,但存在误操作风险,默认关闭。
|
||
|
||
**会议记录自动化**:[[meeting-notes-action-items]] 提供 AI Agent 自动将会议转录文本(Otter.ai、Google Meet、Zoom)转换为结构化摘要,自动从会议中提取行动项并创建 Jira/Linear/Todoist/Notion 任务,同时发送 Slack/Discord 摘要,支持截止日提醒。核心洞察:**自动任务创建**比摘要本身更有价值,无法转化为追踪任务的会议记录只是"文档剧场"。
|
||
|
||
**Designing for Agentic AI**:[[designing-for-agentic-ai]] 阐述 GenAI(创作内容)vs Agentic AI(主动行动)的核心差异,以及为 Agentic AI 设计用户体验的 TCPCA 五原则——**透明度**(可视化 AI 决策进度与推理摘要)、**控制感**(停止/撤销/偏好设置机制)、**个性化**(基于历史行为预测未来需求)、**对话式交互**(自然语言界面 + 输入解读反馈)、**主动预判**(AI 预判需求并主动提供帮助,同时允许用户控制 AI 自主权级别)。核心洞察:**观察 AI 决策过程本身就是一种参与方式**,用户不再是被动旁观者;设计隐喻从"响应用户点击/滑动"转向"AI 运行时的实时反馈"。与 [[Google-5个-Agent-Skill-设计模式]](ToolWrapper/Generator/Reviewer/Inversion/Pipeline)同属 AI Agent 设计方法论——后者侧重 Skill 架构模式,前者侧重终端用户体验设计。
|
||
|
||
**AI 簡報自動化工作流**:用 ChatGPT 先做知識整理,再交給 Canva / Gamma AI 输出演示文稿。两阶段工作流比直接用 AI 生成简报效果更好——ChatGPT 负责深度思考与内容组织,Canva/Gamma AI 负责视觉呈现与排版。核心洞察:让 AI 扮演不同角色(思考者 vs 设计师),充分发挥各工具的优势。与 [[YouTube-Content-Pipeline]] 共享同一"AI 整理 → AI 输出"两阶段模式。与 [[AI图生视频工具盘点]] 同属 AI 内容创作工具应用的不同垂直场景。
|
||
|
||
**[[我的工具集]]**:个人 AI 工具推荐清单,按类型分类(Text-to-Speech / Image-Editor / Image-to-Video / Web-Scraper / AI-Summary),每类列出工具名称、提供商、定价和链接。覆盖 Google AI Studio(Wavespeed 图生视频、Vidu $8/月、海螺 AI ¥42/月)、Brightdata(付费网页爬取)、Decopy(AI 摘要/思维导图/多语言输出)。与 [[AI图生视频工具盘点]] 互补——前者侧重工具索引清单,后者侧重免费工具详细评测。
|
||
|
||
Key concepts: [[AI簡報工作流]], [[AI圖生視頻工具]], [[文字生成視頻]], [[電商場景]], [[AI工具整合]], [[ChatGPT]], [[Canva]], [[Gamma AI]], [[Morning Briefing]], [[Todoist API]], [[AI-Driven Task Extraction]], [[TaskAutomation]], [[Recurring Tasks]], [[MeetingNotes]], [[ActionItemTracking]], [[TranscriptProcessing]], [[RAG从入门到精通系列]], [[Agent Personality Design]], [[Vibe Coding]], [[Design-to-Code Workflow]], [[Multi-AI Review]], [[CodeWeaver]], [[LLM Wiki]], [[多智能体系统可靠性]], [[Plan Mode]], [[Build Mode]], [[Workspace]], [[API Enablement]], [[OAuth 2.0]], [[Google Cloud Console]], [[Agent-Memory]], [[Claude Code Templates]], [[MCP(Model Context Protocol)]], [[Remote-SSH]], [[Bind Mount]], [[Attach 容器]], [[Docker 用户组]], [[SSH Config]], [[SSH 免密登录]], [[Vibe-Kanban]], [[OpenCode]], [[nvm]], [[pm2]], [[单一职责原则]], [[DRY原则]], [[模块化编程]], [[微服务架构]], [[Redis缓存]], [[消息队列]], [[输入-处理-输出模型]], [[并发编程]], [[Pain Point Mining]], [[Startup MVP Pipeline]], [[Agent-Driven Market Research]], [[Last 30 Days Method]], [[Pre-Build Validation]], [[Reality-Signal]], [[Competition-Analysis]], [[Pivot-Strategy]], [[Agent-Build-Gate]], [[CoworkWorkspace]], [[RemoteRescuePattern]], [[Multi-AgentHub]], [[MCPOnceAllAgents]], [[Personalization]], [[Custom Instructions]], [[Proactive AI]], [[Expert User Assumption]], [[Error Accountability]], [[baoyu-imagine]], [[AI-Logo-Generation]], [[Claude-Code-Skill]]
|
||
|
||
### Productivity & Knowledge Management
|
||
Obsidian plugins, blogwatcher RSS monitoring, [[Quartz]] static site generation, project management systems, and personal CRM frameworks. QuickAdd plugin enables quick note capture via hotkeys for rapid idea recording.
|
||
|
||
**Obsidian Skills 生态**([[obsidian-必装-skills]]):AI Agent 操作 Obsidian 的完整工具链——kepano 发布的 defuddle(网页清洗)、obsidian-cli(官方 CLI 增删改查)、obsidian-bases(.base 动态数据库);Axton 发布的 obsidian-canvas-creator(径向布局算法智能排版)、mermaid-visualizer(文本转图表)、excalidraw-diagram(手绘风格图);学术研究工具 tutor-skills(输入-内化-检测学习闭环)和 scholar-skill(L1/L2/L3 分级论文阅读,最长 2.5 小时异步任务)。[[Obsidian-CLI]]([[obsidian-cli]])是 Obsidian v1.12+ 内置的官方命令行工具,通过终端执行所有 GUI 操作,支持 AI Agent 自动化集成;[[Claudian]] 和 [[Obsidian-Agent-Client]] 是两款适配 Claude Code / OpenCode 等 Agent 的 Obsidian 第三方插件。与 [[Second Brain]](对话记忆)、[[Personal Knowledge Base (RAG)]](知识检索)、[[semantic-memory-search]](向量搜索)同属 Obsidian 知识管理能力的不同实现。
|
||
|
||
**[[Quartz]]** 是 Obsidian 笔记的静态网站发布方案——将 Markdown 文件通过 `npx quartz build` 构建为 HTML/JS/CSS bundle,支持本地预览(`--serve`)和自托管部署。本地预览适合开发调试,生产部署需配置 Web 服务器处理无扩展名链接:Nginx 使用 `try_files $uri $uri.html $uri/ =404`,Apache 使用 RewriteRule,Caddy 使用 `try_files {path} {path}.html {path}/`。部署前必须正确配置 `baseUrl`,否则 RSS Feed 和 Sitemap 功能无法正常工作。[[Obsidian]] 笔记 → [[Quartz]] 构建 → 自托管(GitHub Pages / Nginx / Apache / Caddy)构成完整的个人知识发布链条。
|
||
|
||
**Personal Knowledge Base (RAG)**:基于 [[OpenClaw]] 的个人知识库 RAG 系统——通过 Telegram Topic 或 Slack Channel 投递任意 URL(网页/推文/YouTube 字幕/PDF),Agent 自动抓取内容并以 Embedding 向量入库;支持语义搜索("我保存的关于 LLM memory 的内容?"),返回排名结果并附带来源;可被其他工作流(如 [[YouTube-Content-Pipeline]])主动查询。核心理念:**捕获像发短信一样简单,检索像搜索一样容易**,无需专用 App。[[ClawHub]] 提供 knowledge-base skill 一键安装。与 [[Second Brain]] 同属 OpenClaw 持久记忆能力,Second Brain 侧重对话记忆,本方案侧重结构化知识检索。
|
||
|
||
**[[semantic-memory-search]]**:通过 [[memsearch]](基于 [[Milvus]] 向量数据库)为 OpenClaw 的 Markdown 记忆文件添加语义搜索能力——用自然语言提问("我们选了哪个缓存方案?")即可找到相关内容,无需精确措辞。混合搜索(稠密向量 + BM25 + RRF 重排)兼顾语义相似性和关键词精确匹配;SHA-256 内容哈希实现增量索引,仅重新嵌入变更内容;支持本地模式(无需 API Key)。Markdown 文件是唯一真相,向量索引随时可重建。与 [[Knowledge-Base-RAG]] 同属 RAG 技术栈的不同场景。
|
||
|
||
**[[ai-memory-tools-two-camps]]**:AI 记忆工具的全景分类框架(@witcheer,2026-04-15)——GitHub 上 450+ repos 标记"agent-memory"、460+ 标记"context-management",但几乎无人明确区分两个根本不同的技术路线:
|
||
- **Camp 1(Memory Backend)**:从对话中提取事实,存入向量/图数据库,检索时召回。代表:Mem0、MemPalace、Supermemory、Honcho。优化目标:**召回精度**
|
||
- **Camp 2(Context Substrate)**:维护结构化人类可读文件(Markdown/知识图谱),跨会话累积,背景进程整合。代表:OpenClaw、Zep、Thoth、TrustGraph、MemSearch、ALIVE。优化目标:**复合增长**
|
||
- Zep 从"memory"重塑品牌为"context engineering"是市场上最强的信号;作者预测 6 个月内"context engineering"将取代"memory"成为描述成熟 Agent 基础设施的标准术语。与 [[semantic-memory-search]](MemSearch 的文件优先哲学)、[[Self-Improving-Skill]](背景整合实践)同属 Context Substrate 范式的不同切面。
|
||
|
||
Key concepts: [[Obsidian Tasks]], [[Dataview]], [[Templater]], [[QuickAdd]], [[Spaced Repetition]], [[Kanban]], [[Projects]], [[Outliner]], [[Calendar]], [[DB Folder]], [[Homepage]], [[间隔重复]], [[看板]], [[动态模板]], [[双向链接]], [[Daily Notes]], [[Event Sourcing]], [[Second Brain]], [[Personal CRM]], [[Knowledge-Base-RAG]], [[Zero-Friction-Capture]], [[Semantic-Search]], [[Content-Ingestion]], [[semantic-memory-search]], [[memsearch]], [[Hybrid Search]], [[Reciprocal Rank Fusion]], [[Content Hashing]], [[File Watcher]]
|
||
|
||
### 经典智慧与人生哲学
|
||
**一语点醒梦中人**([[一语点醒梦中人]]):收录中国传统诗词与哲学典籍中的经典名句及其释义,涵盖儒、道、佛三家智慧——王维"行到水穷处,坐看云起时"的佛学顿悟、曾国藩"唯忘机可以消众机"的处世哲学、庄子"知其不可奈何而安之若命"的接受智慧、《老子》"大智若愚"的守拙哲学、《金刚经》"一切有为法如梦幻泡影"的空性观。核心价值:跨越千年的东方哲学智慧为现代人面对困境提供精神指引。
|
||
|
||
### 个人品牌与一人公司
|
||
**[[If-You-Have-Multiple-Interests]]**(thedankoe):系统论证多重兴趣是 AI 时代超能力的个人发展指南——核心主张:工业化专业化分工使人类沦为"愚蠢而依赖"的螺丝钉,[[Second-Renaissance]](第二次文艺复兴)已经到来。个人成功三要素:[[Self-Education]](自学)+ [[Self-Interest]](自利)+ [[Self-Sufficiency]](自立),三者相互支撑,自然涌现出 [[Generalist]](通才型人才)。品牌不是个人简介和头像,而是读者关注3-6个月后积累的整体印象;内容是高质量创意的策展[[Idea-Museum]](创意博物馆);[[System-Economy]](系统经济)中,产品即系统,差异化来自个人实践。内容创作三步法:①建立创意博物馆(3-5个高密度信息源)②基于 [[Idea-Density]](创意密度)= 表现力 × 兴奋度筛选 ③同一想法用1000种结构表达。参考 [[Adam Smith]] 分工批判、达芬奇/米开朗基罗/[[Leonardo da Vinci]] 作为 [[Generalist]] 典范、[[Jordan Peterson]] 作为"非内容创作者"案例。核心洞察:你的优势更多在于跨领域知识的交汇处,而非专业知识本身。
|
||
|
||
系统性的个人商业化方法论:**天才地带自检**(识别能产生心流的活动)→ **底层能力挖掘**(追溯童年、毫不费力、底层通用三个维度)→ **心理陷阱识别**(愧疚陷阱、效率陷阱、卓越陷阱、努力陷阱)→ **Ikigai 框架定位**(热情 × 擅长 × 市场需求 × 报酬)→ **赛道验证**(搜索意图分析、支付意愿测试、落地页测试、预售验证)→ **产品体系设计**(引流免费PDF → ¥199入门工具 → ¥4999核心特训营 → ¥20,000/月高价咨询)→ **内容矩阵构建**(核心主题 × 内容形式,反向金字塔内容法,Build in Public)→ **销售漏斗搭建**(获客 → 激活 → 转化,价格锚定与诱饵效应)。
|
||
|
||
核心观点:一人公司的关键不是更努力工作,而是更聪明地定位,用 AI 杠杆放大个人优势。
|
||
|
||
Key concepts: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Sufficiency]], [[Second-Renaissance]], [[Idea-Density]], [[Idea-Museum]], [[Brand-Environment]], [[Content-Creator]], [[System-Economy]], [[Attention-Economy]], [[AdamSmith]], [[LeonardoDaVinci]], [[一人公司]], [[个人品牌]], [[Ikigai框架]], [[天才地带(Zone of Genius)]], [[底层能力]], [[四个心理陷阱]], [[产品四层级体系]], [[内容矩阵]], [[Build in Public]], [[销售漏斗]], [[价格锚定]], [[诱饵效应]]
|
||
|
||
## Source Distribution
|
||
|
||
| Category | Count | Key Sources |
|
||
|----------|-------|-------------|
|
||
| The Agency Agents | 147+ agents | README, CONTRIBUTING, 12 divisions |
|
||
| CTP Topics | 73 topics | AWS, Azure, FinOps, Security |
|
||
| Learning Sessions | 30+ sessions | OpenText, AWS, EKS, Cloud FinOps |
|
||
| Home Office | 60+ docs | Docker, NAS, Network, Monitoring |
|
||
| AI & Productivity | 80+ docs | Claude, OpenClaw, Obsidian, Prompting |
|
||
| Marketing Agents | 30+ agents | Cross-platform, China E-commerce |
|
||
|
||
## Key Entities
|
||
|
||
- [[tukuai]] — 独立研究者,递归自我优化生成系统论文作者,为 [[Self-Improving-Skill]] 提供原则性理论框架
|
||
- [[Alex Ewerlöf]] — 资深Staff Engineer(27年经验),KTH系统工程硕士,专注可靠性工程和弹性架构,《Multi-Agent System Reliability》作者,主张将LLM视为不可靠组件而非拟人化智能体
|
||
- [[Adam Smith]] — 古典经济学家,《国富论》(1776)作者,其分工理论被 [[If-You-Have-Multiple-Interests]] 引用,揭示专业化分工对人类智识和自主性的负面影响
|
||
- [[Leonardo da Vinci]] — 文艺复兴时期通才典范(画家+雕塑家+工程师+解剖学家),[[If-You-Have-Multiple-Interests]] 中 [[Second-Renaissance]] 和 [[Generalist]] 概念的历史原型
|
||
- [[The Agency]] — open-source AI agent collection (147 agents, 12 divisions)
|
||
- [[agency-agents]] — GitHub repository
|
||
- [[DracoVibeCoding]] — 公众号"Draco正在VibeCoding"作者,专注 Vibe Coding 与 AI Agent 实战分享
|
||
- [[OpenClaw]] — multi-agent framework with memory
|
||
- [[clawr.ing]] — 托管电话服务提供商,消除 Twilio 等传统电话 API 配置复杂度,为 Agent 提供主动拨打电话通知能力,覆盖 100+ 国家 PSTN 电话,不存储录音
|
||
- [[clawhub.ai]] — OpenClaw Skill 市场,托管 clawr.ing 等 Skill 安装包
|
||
- [[AionUi]] — 桌面多 Agent Hub(macOS/Windows/Linux),将 OpenClaw 作为可视化 Cowork Agent 运行,支持内置远程救援专家和统一 MCP 配置
|
||
- [[n8n]] — workflow automation
|
||
- [[Shlomi Ben-Hur]] — Micro Focus 产品安全小组(PSAC)成员,主讲 CTP Topic 21(供应链安全)和 CTP Topic 24(产品隐私框架),推动将法律合规要求翻译为技术实现
|
||
- [[Octane-Hub]] — Software Factory 团队,Micro Focus 云转型计划一部分,主导 Docker 容器化工作负载从 Bibling Lab 向 AWS Landing Zone 的迁移项目,CTO 为 Holger Rode
|
||
- [[Node.js]] — JavaScript 运行时环境,n8n-mcp 的运行依赖,也是 [[n8n]] 工作流引擎的后端运行环境
|
||
- [[gog CLI]] — 由 steipete 开发的 Google Workspace 命令行管理工具(Homebrew 安装),支持 Gmail/Calendar/Drive/Contacts/Docs/Sheets 全套服务,[[personal-crm]] 和 [[multi-channel-assistant]] 的前置依赖
|
||
- [[Quartz]] — static site generator for wikis
|
||
- [[RSSHub]] — open-source RSS aggregator
|
||
- [[RackNerd]]:低总价OpenVZ/KVM VPS提供商,本方案中托管公网VPS1(192.227.222.142, vps.ishenwei.online),运行frps服务端(端口7000)和Caddy自动HTTPS反向代理(*.ishenwei.online),作为全网内网服务的统一公网入口
|
||
- [[Synology NAS DS718]]:群晖NAS设备(192.168.3.17, nas.ishenwei.online),运行DSM管理界面及Calibre/MinIO/Zipline/Navidrome/Jellyfin/Prometheus/Alertmanager/v2rayA/vaultwarden/Portainer/CloudDrive2等Docker应用,通过FRP+Caddy暴露nas/navidrome/calibre/jellyfin/zipline/miniflux等服务至公网
|
||
- [[Docker卷]] — Docker 容器持久化数据存储,默认路径 /var/lib/docker/volumes,是 TikTok 业务数据备份的核心对象
|
||
- [[it-tools]] — 开源开发者工具集合 Web UI(corentinth/it-tools),提供 100+ 实用工具如 URL 编解码、UUID 生成、Cron 解析、哈希计算等,通过 Docker Compose 部署,端口 8999,内存限制 128MB
|
||
- [[Navidrome]] — 开源音乐流媒体服务器,Subsonic API 兼容,支持网页端与移动客户端
|
||
- [[Transmission]] — 开源 BT 下载客户端,Home Server 媒体中心核心组件,负责下载环节,与 Jellyfin/Navidrome 构成"下载→播放"工作流
|
||
- [[LinuxServer.io]] — 开源 Docker 镜像维护组织,为 Transmission/Jellyfin/Navidrome 等自托管应用提供标准化 Docker 镜像
|
||
- [[MariaDB]] — 开源关系型数据库,Synology NAS Docker 环境部署,支持内网(192.168.3.17:3307)和公网(mysql.ishenwei.online:63307)双通道访问
|
||
- [[Claude Code]] — Anthropic CLI agent
|
||
- [[Claude Desktop]] — Anthropic Claude AI 桌面应用,支持 MCP 协议扩展,通过 n8n-mcp 连接 n8n 工作流引擎
|
||
- [[ChatGPT]] — OpenAI 开发的大语言模型对话产品,支持自定义指令(Custom Instructions)功能,[[openai-chatgpt-个性化定义]] 是其完整配置案例
|
||
- [[OpenAI]] — 美国 AI 研究公司,开发 GPT 系列大语言模型、ChatGPT 产品、API 接口,为本 Wiki 多个 AI 工具提供底层技术支持
|
||
- [[OpenCode]] — Vibe Coding CLI agent
|
||
- [[Trae]] — 国产 AI 增强型 IDE,支持 Remote-SSH 远程开发和 VS Code 插件生态
|
||
- [[ISO-27001]] — 国际信息安全管理体系标准(云安全合规基础)
|
||
- [[HIPAA]] — 美国医疗健康信息隐私法规
|
||
- [[GDPR]] — 欧盟通用数据保护条例
|
||
- [[Raj-Vardhan-Singh]] — LinkedIn 云计算文章作者
|
||
- [[Agentic AI]] — 自主决策和任务执行能力的AI系统
|
||
- [[Kubernetes]] — 容器编排平台(EKS/GKE/AKS)
|
||
- [[Terraform]] — IaC 基础设施即代码工具
|
||
- [[LaunchDarkly]] — Feature Flag 管理平台(HP、Christian Dior RTO 优化案例)
|
||
- [[Veeam]] — 传统灾备工具(数据库备份、服务器镜像)
|
||
- [[Acronis]] — 传统灾备工具(跨区域复制)
|
||
- [[Portainer]] — Docker 可视化管理工具(portainer/portainer-ce),通过 Web UI 管理容器/卷/网络,支持 Edge Agent 集群管理,Home Server 运维常用;重装前需清理残留容器/Volume/Network,可通过 `external: true` 复用旧资源
|
||
- [[Docker]] — 容器化平台,所有监控组件(Prometheus / Grafana / node_exporter / cAdvisor / blackbox_exporter)的部署底座,通过 Docker Compose 实现一键启动
|
||
- [[Docker Compose]] — 多容器应用的定义和编排工具,通过 YAML 文件(docker-compose.yml / compose.yaml)声明式定义服务/网络/卷,`docker compose up/down` 管理整个堆栈生命周期,支持 `external: true` 复用已有网络和卷
|
||
- [[Docker卷]] — Docker 容器持久化数据存储,默认路径 /var/lib/docker/volumes,通过 `docker volume ls` 查看,`docker volume rm` 删除;[[用docker安装portainer]] 的 `portainer_data` 卷存储 Portainer 用户、配置和 Edge Agent 数据
|
||
- [[Docker Network]] — Docker 容器网络连接,默认 bridge 网络 IP 为 172.17.0.1,自定义网络如 172.24.0.1;compose 项目间同名网络冲突会产生 WARN 警告
|
||
- [[Prometheus]] — CNCF 毕业项目,开源时序数据库和监控告警系统,pull 模式采集 exporters 指标,支持 PromQL 查询和告警规则引擎,是家庭监控方案的核心数据引擎
|
||
- [[Grafana]] — 开源可视化平台,支持多数据源(Prometheus / Loki / VictoriaMetrics)仪表盘和告警管理,家庭方案中通过 Dashboard ID(1860/14282/7587)快速导入官方模板
|
||
- [[node_exporter]] — Prometheus 官方主机指标采集器,以 host network 模式运行,采集 CPU / 内存 / 磁盘 / 网络 / I/O 等系统指标
|
||
- [[cAdvisor]] — Google 开源容器资源监控工具,挂载 Docker socket 采集容器级别资源指标,为 Prometheus 提供容器层可观测性
|
||
- [[blackbox_exporter]] — Prometheus 官方黑盒探测 exporter,通过 HTTP/TCP/ICMP/DNS/TLS 探测实现服务可用性和证书到期监控
|
||
- [[Alertmanager]] — Prometheus 告警分发组件,支持告警分组、抑制、静默及邮件/Slack/Teams/Webhook 多通道路由
|
||
- [[Uptime Kuma]](louislam/uptime-kuma)— 自托管 uptime monitoring 工具,支持 HTTP/TCP/DNS/TLS 合成监控,适合外网/内网可用性探测
|
||
- [[Netdata]] — 开箱即用的实时主机/容器监控面板,默认端口 19999,适合快速诊断,与 Prometheus 可互补使用
|
||
- [[VictoriaMetrics]] — Prometheus 时序数据库替代方案,支持长期存储和高效写入,适合大规模数据保留场景
|
||
- [[Portainer]] — Docker 可视化管理工具,不替代 Prometheus 但便于运维快速操作容器
|
||
- **[[BMC]]** — 企业IT管理解决方案提供商(BMC Helix / Control-M)
|
||
- **[[AWS]]** — Amazon Web Services,提供 RDS 和 Aurora 两款托管数据库服务
|
||
- **[[Amazon RDS]]** — 关系型数据库服务,计算与存储分离(EBS),支持 Multi-AZ 部署
|
||
- **[[Amazon Aurora]]** — 云原生关系型数据库,6 副本跨 3 AZ 共享集群卷架构
|
||
- [[Greg Klau]] — CTP Topic 66 讲师,主讲 PostgreSQL RDS vs Aurora 差异对比
|
||
- [[Martin Rosler]] — Learning Sessions 讲师,主讲 OpenText Tagging Standard v2,聚焦云资源标签标准化
|
||
- [[Phenops-Team]] — OpenText 内部团队,2023 年发起云资源标签标准化项目
|
||
- **[[Google-Cloud]]** — Google Cloud Platform
|
||
- [[Btop++]] — TUI系统监控器,作者首选
|
||
- [[Htop]] — 轻量级TUI进程监控器
|
||
- [[Glances]] — 超轻量TUI监控器
|
||
- [[Bottom]] — TUI实时图表监控器
|
||
- [[Mission Center]] — 类Windows任务管理器的GUI应用
|
||
- [[Stacer]] — 功能最全的GUI监控+维护工具
|
||
- [[网件RAX50]] — NETGEAR WiFi 6路由器,支持刷入梅林固件
|
||
- [[梅林固件]] — 华硕路由器第三方固件改良版,支持软件中心插件
|
||
- [[MerlinClash插件]] — 基于Clash核心的梅林固件科学上网插件,支持策略组分流
|
||
- [[机场]] — 提供代理节点订阅服务的服务商
|
||
- [[3X-UI]] — Xray 可视化管理面板(mhsanaei/3x-ui),提供 Web UI 管理 25 项运维操作(启停、更新、SSL证书、Geo更新、BBR等),支持 VLESS+Reality 入站配置生成
|
||
- [[Xray]] — 新一代代理核心,支持 VLESS/VMess/Trojan/SS 等多协议,内置 Reality 流量伪装方案,是 3X-UI 的底层引擎
|
||
- [[frp]] — 开源内网穿透工具,包含 frps(服务端)和 frpc(客户端)两个组件,通过反向隧道使内网服务可被公网访问,支持 TCP/UDP/HTTP 等多种协议
|
||
- [[Ubuntu Server]] — Ubuntu Server 是 Canonical 维护的 Linux 服务器操作系统,默认使用 systemd 作为初始化系统,Ubuntu Server 24.04 LTS 是当前长期支持版本
|
||
- [[systemd]] — Linux 系统和服务管理器,Ubuntu Server 的默认初始化系统,通过 unit 文件(service/timer/socket)和 systemctl 命令管理服务生命周期,支持开机自启(enable)、自动重启(Restart=on-failure)、日志收集(journald)等生产级特性
|
||
- [[Mac Mini M4]] — Apple Silicon Mac Mini,作为家庭服务器运行 FRP 客户端、N8n、OpenClaw 等服务,支持 ARM64 架构
|
||
- [[systemd-logind]] — Linux 系统登录管理器,负责管理用户会话、电源事件和系统休眠行为,Ubuntu 笔记本合盖休眠行为由其控制,通过 /etc/systemd/logind.conf 配置 HandleLidSwitch 系列参数
|
||
- [[HandleLidSwitch]] — systemd-logind 的合盖动作配置指令,支持 ignore(忽略/继续运行)/suspend(待机)/hibernate(休眠)/poweroff(关机)/lock(锁屏)等值,Ubuntu Server 笔记本作为无显示器服务器时需设为 ignore
|
||
- [[Caddy]] — Go 语言编写的自动 HTTPS 反向代理服务器,默认启用 Let's Encrypt 证书,与 frp 配合提供内网服务的 HTTPS 访问
|
||
- [[VPS]] — 公网虚拟专用服务器,本方案中托管 frps 和 Caddy,作为内网穿透的公网中转站(IP: 192.227.222.142)
|
||
- [[阿里云 DNS]] — 域名 ishenwei.online 的 DNS 解析服务,通过 A 记录将子域名指向 VPS 公网 IP
|
||
- [[Bandwagon VPS]] — 低总价 OpenVZ/KVM VPS 提供商,资料中 VPS2(104.194.92.188)托管了 3X-UI + Xray 服务
|
||
- **[[CloudDrive2]]** — 云盘挂载工具,支持阿里云盘/Google Drive/OneDrive 等,通过虚拟文件系统将云端存储挂载为本地目录,Web UI 端口 19798
|
||
- **[[矿神源]]** — Synology 社群第三方套件源(SPK 格式),提供 CloudDrive2 等官方未收录应用
|
||
- **[[阿里云盘]]** — 阿里巴巴云盘服务,CloudDrive2 的主要挂载目标
|
||
- [[AdsPower]] — 指纹浏览器产品,支持浏览器指纹隔离,免费版提供5个环境,是跨境服务注册的推荐工具
|
||
- [[PingMe]] — 短信接码平台,支持美国区号码接收验证码,需下载App,最低充值2美元
|
||
- [[WildCard]] — 虚拟信用卡服务,支持支付宝充值,解决国内用户跨境支付难题
|
||
- [[Claude Pro]] — Anthropic Claude AI聊天工具的Pro订阅服务,月费20美元,需海外支付方式
|
||
- [[v2rayN]] — 跨平台代理客户端(Windows/Linux/macOS),支持 VLESS+Reality 等多协议。内置部分 Core(Xray/sing-box/mihomo),其他 Core 需单独下载。Windows WPF 版需 .NET 8 Runtime;Avalonia UI 版为跨平台自包含版本;macOS DMG 需 `xattr -cr` 修复签名
|
||
- [[v2rayNG]] — Android 代理客户端,v2rayN 的移动版,功能一致
|
||
- [[Avalonia UI]] — 跨平台 .NET UI 框架,v2rayN desktop 版基于此构建,实现 Windows/Linux/macOS 三平台统一界面,无需额外运行时依赖
|
||
- [[sing-box]] — v2rayN 支持的代理核心之一,支持多协议
|
||
- [[mihomo]] — v2rayN 支持的代理核心,mihomo 协议实现
|
||
- [[2dust]] — v2rayN GitHub 仓库维护者(github.com/2dust)
|
||
- [[BBR]] — Google TCP 拥塞控制算法,3X-UI 提供一键启用,可提升跨境网络吞吐量
|
||
- [[代理客户端]] — 运行在终端设备上通过代理协议连接远程节点的软件,v2rayN 是典型产品,支持 VLESS/VMess/Trojan/SS 等多种协议
|
||
- [[代理协议]] — 代理客户端与服务端通信的协议规范,如 VLESS+Reality、VMess、Trojan、Shadowsocks 等
|
||
- [[Reality]] — Xray 的流量伪装方案,通过 SNI 分流实现深度伪装,v2rayN 可作为 Reality 客户端使用
|
||
- [[Avalonia UI]] — 跨平台 .NET UI 框架,v2rayN desktop 版基于此构建,实现 Windows/Linux/macOS 三平台统一界面,无需额外运行时依赖
|
||
- [[WPF]] — Windows Presentation Foundation,Windows 原生 UI 框架,.NET 桌面应用首选,v2rayN WPF 版基于此
|
||
- [[.NET Desktop Runtime]] — .NET 桌面运行时环境,WPF 应用必需依赖,v2rayN WPF 版要求 .NET 8 Desktop Runtime
|
||
- [[便携版]] — 解压即用、数据存放在程序同目录、可复制多份独立运行的软件分发方式
|
||
- [[安装版]] — 数据存放在系统规定用户目录、通过包管理器安装的软件分发方式(deb/rpm/dmg)
|
||
- [[代理核心]] — 代理客户端的底层引擎,如 Xray、sing-box、mihomo,负责实际流量转发
|
||
- [[分流模式]] — 代理客户端的路由策略,"大陆白名单"模式下仅代理非中国大陆流量,减少不必要的代理开销
|
||
- [[VPN Panel]] — Web 界面类代理管理工具的统称,3X-UI 属于此类,降低 Xray 服务端运维门槛
|
||
- [[KoolCenter固件服务器]] — 提供梅林固件下载的服务器平台
|
||
- **[[Clonezilla]]** — 开源磁盘镜像工具(再生龙),支持 savedisk/restoredisk 全盘镜像备份到 NAS
|
||
- **[[Rufus]]** — 开源 U 盘启动盘制作工具,ISOHybrid 镜像写入模式选择(ISO 模式推荐)
|
||
- **[[HP ZBook]]** — HP 工作站笔记本,支持 UEFI/F9 启动菜单,F10 进入 BIOS,作为 Ubuntu 24.04 安装目标机
|
||
- **[[NodeWarden]]** — 将 Bitwarden 服务器端部署到 Cloudflare Workers 的开源实现,运行在边缘计算平台,无需 VPS 和服务器维护,数据存储在 Cloudflare D1 + R2,支持 Bitwarden 官方全平台客户端
|
||
- **[[Cloudflare Workers]]** — Cloudflare 边缘计算平台,基于 V8 隔离的 Serverless 运行时,NodeWarden 的部署环境
|
||
- **[[Cloudflare D1]]** — Cloudflare 边缘 SQLite 数据库,NodeWarden 的主数据存储(保管库/同步数据)
|
||
- **[[Cloudflare R2]]** — Cloudflare S3 兼容对象存储,NodeWarden 用于存储密码附件
|
||
- [[V2RayA]] — V2Ray 的 Web 可视化管理界面,基于 V2Ray 内核,支持透明代理和分流策略,在群晖 NAS 上以 Docker 容器方式部署
|
||
- **[[Apache Superset]]** — Apache 软件基金会旗下的开源 BI 平台,通过 Docker 快速部署,支持 SQL 查询、多样化图表和仪表盘构建。Home Server 场景通过 `apache/superset:GHA-*` 镜像容器化部署,6 步初始化流程:拉取镜像 → 启动容器 → 创建管理员 → 数据库迁移 → 加载示例 → 完成初始化,默认端口 8088(映射 8777),内置 SQLite,可选外挂 MySQL
|
||
- **[[RustDesk]]** — 开源远程桌面软件,支持自建中继服务器,可通过修改 GDM3 配置 `WaylandEnable=false` 强制 X11 解决 Ubuntu 24.04 Wayland 登录限制问题
|
||
- **[[Ollama]]** — 开源本地 LLM 运行框架(ollama.com/ollama.org.cn),支持 macOS/Windows/Linux/Docker,提供简洁命令 `ollama run <model>` 运行大语言模型,通过 API(localhost:11434)和 Open WebUI 提供多元化接入方式,DeepSeek-R1 系列模型官方支持
|
||
|- **[[Open WebUI]]** — 开源大模型 Web 界面(ghcr.io/open-webui/open-webui:main),基于浏览器访问,支持 Ollama/OpenAI API 接入,可配置 RAG 本地知识库(bge-m3 嵌入模型)和联网搜索,Docker Compose 一键部署
|
||
|- **[[WSL2]]** — Windows Subsystem for Linux 2,Windows 10/11 内置的 Linux 虚拟机环境,默认使用 NAT 网络模式,通过 `.wslconfig` 的 `networkingMode=mirrored` 可实现与 Windows 共享网络堆栈;[[ghproxy]] 提供 GitHub 下载的反向代理加速
|
||
|
||
|- **[[ghproxy]]** — ghproxy.com,国内可访问的 GitHub 反向代理服务,通过将 `github.com` 替换为 `mirror.ghproxy.com/https://github.com` 绕过网络限制,适用于 uv 安装器、Claude Code 等工具的下载加速
|
||
|- [[ProxyChains]]:通过 LD_PRELOAD 劫持 socket 调用使任意终端命令走 SOCKS5 代理的工具,配置文件 /etc/proxychains4.conf,格式 `socks5 127.0.0.1 10808`,适用于临时命令级代理
|
||
- [[Git 全局代理]]:Git 不读取系统环境变量,必须通过 `git config --global http.proxy socks5://127.0.0.1:10808` 设置
|
||
- [[Docker Daemon Proxy]]:通过 systemd drop-in 文件(/etc/systemd/system/docker.service.d/http-proxy.conf)注入环境变量使 docker pull 走代理,docker info | grep -i proxy 验证
|
||
- [[Docker 网络网关 IP]]:Docker 容器内访问宿主机的 IP,bridge 网络默认 172.17.0.1,自定义网络如 172.24.0.1,容器内 127.0.0.1 指向自身而非宿主机
|
||
- [[SOCKS5h 代理]]:socks5h 协议变体,DNS 解析由代理服务器完成,防止本地 DNS 污染,curl -x socks5h:// 使用
|
||
- [[环境变量代理]]:通过 HTTP_PROXY/HTTPS_PROXY/ALL_PROXY 环境变量让程序走代理,Docker 容器内使用 ALL_PROXY=socks5://172.24.0.1:10808
|
||
- [[Wayland]]:Linux 新一代显示协议,Ubuntu 24.04 默认使用,基于安全设计严格限制外部程序在未登录状态下获取屏幕控制权,是 RustDesk 无法在 Login Screen 场景工作的根本原因
|
||
- [[X11]]:经典显示协议,兼容性好、权限开放度高,远程桌面场景下稳定性优于 Wayland,通过修改 GDM3 配置 `WaylandEnable=false` 强制启用
|
||
- [[GDM3]]:GNOME Display Manager,Ubuntu 默认登录管理器,控制用户会话初始化,支持 Wayland 和 X11 两种显示协议
|
||
- **[[透明代理]]** — 通过修改 iptables 规则劫持系统出站流量,国内直连、国外走代理的分流机制,V2RayA 的核心实现方式
|
||
- **[[分流模式]]** — V2RayA 的路由策略,"大陆白名单"模式下仅代理非中国大陆流量,减少不必要的代理开销
|
||
- **[[iptables]]** — Linux 内核防火墙,V2RayA 通过修改 iptables 规则实现透明代理
|
||
- **[[MinIO]]** — 开源 S3 兼容对象存储,Zipline 图床系统的存储后端,提供高性价比本地存储
|
||
- **[[Zipline]]** — 开源自托管图床应用,提供前端上传 UI 和 REST API,支持 [[n8n]] 工作流集成
|
||
|
||
### TikTok E-commerce Operations
|
||
**[[电商如何选品-如何找到爆款-选品策略]]**(YouTube 视频摘要):电商选品系统方法论——20 种选品策略(细分市场定位如LGBTQ群体、情境配对如露营三件套、季节性规划等)+ POD 低成本测款模式 + 工具辅助分析(Salesmartly 多平台订单管理、Erank 竞争分析、Pinterest/Etsy 趋势报告)。核心观点:未来品牌需针对细分市场而非大众市场;多工具组合使用可提升客户转化率和选品效率。与 [[做TK跨境思路不对努力白费]](运营策略)和 [[TikTok E-commerce Product Management]](Django 产品管理系统)共同构成 TikTok 跨境电商知识体系。
|
||
|
||
**[[做TK跨境思路不对努力白费]]**:TikTok 跨境电商全流程实战指南——从市场选择(优先美区/日本,避开东南亚)→ 账号准备(选区看直播了解流程)→ 选品策略(数据软件分析+单一垂直类目)→ 店铺运营(流量监控+商品优化)→ 流量获取(短视频营销+达人合作)→ 仓储物流(海外仓+海运补货)→ 团队建设(招聘分工),提供完整的执行框架。核心观点:思路正确是成功的前提,市场定位和选品是核心竞争力。与 [[电商如何选品]] 同属选品策略范畴,与 [[TikTok E-commerce Product Management]](Django 产品管理系统)互补——前者侧重运营策略,后者侧重技术实现。
|
||
|
||
**电商数据采集与处理系统**:基于 Docker + Ubuntu + n8n 的可自动化、可扩展、AI增强的电商数据采集与处理系统。三层架构:爬虫层(Scrapy/Playwright)→ AI处理层(n8n + LLM API)→ 存储展示层(PostgreSQL/MinIO + Grafana)。推荐 Scrapy + Playwright 组合抓取动态页面,Docker Compose 容器化部署,输出 JSON/CSV 供 n8n 消费;n8n 工作流实现定时启动爬虫→读取数据→LLM提取属性→写入数据库→报表通知的全链路自动化;AI 处理任务包括摘要分类、多语言翻译、特征提取、异常检测;本地可使用 Ollama(Mistral/Llama3)通过 HTTP Request 调用,无需外部 API Key;防封策略包括 User-Agent 轮换、代理池(Bright Data/ScraperAPI)和下载延迟随机化。与 [[做TK跨境思路不对努力白费]](运营策略)互补,后者侧重电商运营全流程,前者侧重技术架构搭建。与 [[scrapy-playwright-抓取tiktok-shop-data]] 同属电商数据采集技术栈。
|
||
|
||
### TikTok E-commerce Product Management
|
||
A comprehensive Django-based product data management system for TikTok Shop. Covers Django ORM models (Product, ProductImage, ProductVideo, ProductVariation, ProductReview), Django Admin customization (TinyMCE rich text, inline models, image preview modals), REST API via Django REST Framework with django-filter for search and filtering, Docker + Gunicorn + Nginx production deployment, Django-Q async task queue for Bright Data API scraping, and custom Management Commands for JSON data import. Key components: Product list with thumbnail display, multi-condition filtering by store_name, bulk product fetch via Bright Data asynchronous API, description detail HTML generation, and Apache Superset BI dashboard integration.
|
||
|
||
Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]], [[Docker 容器化部署]], [[Django-Q 异步任务]], [[Bright Data API]], [[MySQL / MariaDB 数据库]], [[Gunicorn]], [[Nginx]], [[自定义管理命令]]
|
||
|
||
### New Linux/DevOps Concepts (recently added)
|
||
- **[[efibootmgr]]** — Linux NVRAM 启动项管理工具,可强制重写 BootOrder 解决 HP BIOS 固执行为
|
||
- **[[ISOHybrid镜像]]** — 同时支持 BIOS 和 UEFI 引导的混合 ISO 镜像,Rufus 提供 ISO/DD 两种写入模式
|
||
- **[[UEFI Only]]** — HP ZBook 终极启动修复方案,切换后消除 Legacy BBS 项干扰
|
||
- **[[NVMe硬盘分区]]** — Ubuntu 24.04 自动识别并优化 NVMe 分区对齐
|
||
|
||
## Conflict Areas
|
||
|
||
1. **Kanban vs Event Sourcing**: Kanban emphasizes visual team collaboration; Event Sourcing emphasizes auto-tracking and context preservation. **[[Project State Management]]**(事件驱动看板替代方案)vs 传统 PM 工具。核心差异:手动拖拽 vs 自然语言输入;静态快照 vs 全历史保留;无上下文 vs 完整决策链。**[[Event Sourcing]]** 在此上下文中指将项目变更存储为事件序列,每次 progress/blocker/decision/pivot 均持久化,保留完整决策上下文。
|
||
|
||
2. **Kuaishou vs Douyin**: Kuaishou emphasizes authenticity and balanced algorithm; Douyin emphasizes polished content and central recommendation. Same country, opposite platform strategies.
|
||
|
||
3. **Micro-Enterprise vs Portage Salarial**: Micro-enterprise yields higher net income but lacks social protections; Portage Salarial costs more but includes unemployment insurance, pension, mutuelle. Financial trade-off vs social safety net.
|
||
|
||
4. **CI/CD Build Output**: SECURITY.md says build output is always closed; GitHub Actions best practice says certain generated files should be committed for reproducibility. Reproducibility vs cleanliness tension.
|
||
|
||
5. **路由器科学上网 vs VPS科学上网 vs NAS科学上网 vs Server终端代理**:四层方案各有适用场景。[[网件RAX50刷梅林固件与科学上网]] 路由网关方案([[MerlinClash插件]])→ 全屋透明代理,无需客户端配置;[[3X-UI Xray on BandwagonVPS]] VPS服务端方案([[3X-UI]] + [[Xray]])→ 集中式代理节点,可扩展;[[群晖NAS科学上网]] NAS 代理方案(V2RayA 透明代理)→ 覆盖 NAS 本身及容器;[[ubuntu-server科学上网]] Server 终端代理方案([[ProxyChains]] + [[Git 全局代理]] + [[Docker Daemon Proxy]])→ 仅覆盖该 Server 本身。最佳实践:路由器作为主网关([[MerlinClash插件]]),VPS作为代理节点池(订阅机制),NAS 按需透明代理,Server 终端按工具单独配置。**额外洞察**:在群晖 DSM 7.x 和 Ubuntu Server 中,V2RayA/透明代理不一定对 Docker Daemon 生效,**显式配置 Docker Daemon Proxy 环境变量**(systemd drop-in 文件)比依赖透明代理更可靠。
|
||
|
||
6. **Prometheus 监控 vs OpenTelemetry**:Prometheus 生态成熟、部署简单,适合家庭服务器和小型集群;OpenTelemetry 是云原生可观测性新标准(metrics/traces/logs 三合一),长期可考虑迁移路径但学习成本高。[[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] vs [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]。
|
||
|
||
7. **Netdata vs Prometheus**:Netdata 开箱即用适合实时短期诊断(默认 19999 端口),Prometheus + Grafana 适合长期存储和趋势分析。两者可互补使用:Netdata 做快速排查,Prometheus 做 SLA 报表和历史分析。
|
||
|
||
8. **macOS vs Linux 睡眠管理**:macOS 使用 `pmset` 命令配置电源管理(sleep/displaysleep/standby/hibernatemode),Linux/Ubuntu 使用 `systemd-logind` 的 `HandleLidSwitch=ignore` 配置。两者目标相同(防止服务器睡眠),但工具链完全不同,不可互换但互为参考。[[mac-mini-服务器配置-防止自动锁屏与睡眠]] vs [[ubuntu禁用合盖休眠]]。
|
||
|
||
9. **数据库备份方案**:pg_dump 逻辑备份 vs rsync 文件级备份。pg_dump 是热备份标准(零停机、跨平台迁移能力强),但不能备份运行中数据库的物理文件目录;rsync 适合 Docker 卷备份但需确保数据库一致状态。[[MinIO + Zipline 图床安装]] 使用 pg_dump 逻辑备份 PostgreSQL + Hyper Backup 文件备份 MinIO 目录,两者互补。
|
||
|
||
10. **SuperCall 沙盒 Persona vs 通用语音 Agent**:[[event-guest-confirmation]] 中使用的 [[SuperCall]] 强调独立沙盒设计——AI persona 只持有预设的 persona name、goal、opening line,无法访问外部系统;[[phone-based-personal-assistant]] 侧重通用个人助手场景,需要访问更多上下文。**[[Sandboxed Persona]]** 适用于确认类单一任务(安全、无注入风险);通用语音 Agent 适用于需要跨系统协调的复杂助手场景。
|
||
|
||
11. **Agent 去电通知 vs Agent 来电接收**:[[phone-call-notifications]] 中 Agent 主动向用户拨打电话通知(Agent → User),通话由 Agent 触发,用户是被动接收方;[[phone-based-personal-assistant]] 中用户主动呼叫 Agent(User → Agent),Agent 接听并提供助理服务。两者方向相反但互补——前者用于紧急告警、定时简报、重要事件通知,后者用于随时咨询、查询、执行任务。共同构成完整语音双向通信能力。
|