From 30606d38e749dd4b5ae0144f99c62c38048af3f4 Mon Sep 17 00:00:00 2001 From: weishen Date: Sun, 19 Apr 2026 08:02:52 +0800 Subject: [PATCH] Auto-sync: 2026-04-19 08:02 --- .DS_Store | Bin 14340 -> 14340 bytes ...incident-infographic-prompts-2026-04-20.md | 182 +++++++++++++ ...circular-infographic-prompts-2026-04-20.md | 256 ++++++++++++++++++ ...iki-sync-infographic-prompts-2026-04-20.md | 148 ++++++++++ wiki/concepts/BOSCARD.md | 40 +++ wiki/concepts/Centralized-Logging.md | 27 ++ wiki/concepts/Luhmann-四原则.md | 24 ++ wiki/concepts/Multi-Account-Strategy.md | 2 +- wiki/concepts/Product.md | 33 +++ wiki/concepts/Zettelkasten.md | 24 ++ wiki/concepts/原子化知识管理.md | 24 ++ wiki/entities/Niklas-Luhmann.md | 19 ++ wiki/entities/Product-Hub-PHT.md | 33 +++ wiki/entities/StackSets.md | 2 +- wiki/index.md | 11 +- wiki/log.md | 71 +++++ wiki/overview.md | 7 +- ...e-Business-Analysis-Techniques-20240109.md | 50 ++++ ...ifferences-for-Modern-Disaster-Recovery.md | 4 +- ...d-logs-for-aws-cloudformation-stacksets.md | 42 +++ wiki/sources/polymarket-autopilot.md | 16 +- ...oist-task-manager-agent-task-visibility.md | 2 +- wiki/sources/zk-steward.md | 45 +++ 23 files changed, 1050 insertions(+), 12 deletions(-) create mode 100644 Hermes/xingzhi/major-incident-infographic-prompts-2026-04-20.md create mode 100644 Hermes/xingzhi/wiki-sync-circular-infographic-prompts-2026-04-20.md create mode 100644 Hermes/xingzhi/wiki-sync-infographic-prompts-2026-04-20.md create mode 100644 wiki/concepts/BOSCARD.md create mode 100644 wiki/concepts/Centralized-Logging.md create mode 100644 wiki/concepts/Luhmann-四原则.md create mode 100644 wiki/concepts/Product.md create mode 100644 wiki/concepts/Zettelkasten.md create mode 100644 wiki/concepts/原子化知识管理.md create mode 100644 wiki/entities/Niklas-Luhmann.md create mode 100644 wiki/entities/Product-Hub-PHT.md create mode 100644 wiki/sources/Public-Cloud-Learning-Sessions-Applicable-Business-Analysis-Techniques-20240109.md create mode 100644 wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md create mode 100644 wiki/sources/zk-steward.md diff --git a/.DS_Store b/.DS_Store index 38c6fffab85679d552c5b70c66667a0b641676f2..e5d15783037567a468c58c0074ba89aaa50cabb4 100644 GIT binary patch delta 27 jcmZoEXepTB&zQ0?U^hRb=H@Jch5QpA#BJtQ_$dwmmsJY9 delta 98 zcmZoEXepTB&zQO~U^liy0I?a6 uG+{7gumEB+Aj_P=l);igkD-7ek0E{X17-Qi_5y;N6$E@ diff --git a/Hermes/xingzhi/major-incident-infographic-prompts-2026-04-20.md b/Hermes/xingzhi/major-incident-infographic-prompts-2026-04-20.md new file mode 100644 index 00000000..8a28075b --- /dev/null +++ b/Hermes/xingzhi/major-incident-infographic-prompts-2026-04-20.md @@ -0,0 +1,182 @@ +# Major Incident Definition - Infographic Prompts +# Generated: 2026-04-20 +# Layout: Venn Diagram +# Style: Cyberpunk Neon +# Aspect: 16:9 +# Language: English + +--- + +## Part 1: System Prompt (Image Specifications + Core Principles) + +Create a professional infographic following these specifications: + +**Image Specifications** + +- **Type**: Infographic +- **Layout**: Venn Diagram (venn-diagram) +- **Style**: Cyberpunk Neon +- **Aspect Ratio**: 16:9 +- **Language**: English + +**Core Principles** + +- Follow the layout structure precisely for information architecture +- Apply style aesthetics consistently throughout +- If content involves sensitive or copyrighted figures, create stylistically similar alternatives +- Keep information concise, highlight keywords and core concepts +- Use ample whitespace for visual clarity +- Maintain clear visual hierarchy + +**Text Requirements** + +- All text must match the specified style treatment +- Main titles should be prominent and readable +- Key concepts should be visually emphasized +- Labels should be clear and appropriately sized +- Use English for all text content + +--- + +## Part 2: Style Lock Prompt (Layout Guidelines + Style Guidelines) + +### Layout Guidelines (Venn Diagram) + +**Structure**: Three overlapping circles forming a central intersection area + +**Visual Elements**: + +- Three large overlapping circles representing different categories of Major Incident +- Central intersection zone highlighting the combined criteria +- Each circle contains key concepts specific to its category +- Outer labels for each circle region +- Connection lines from concepts to their respective regions +- Minimal text, emphasize visual grouping + +**Composition**: + +- Canvas divided into three equal sections for each circle +- 30-40% overlap area in center for intersection +- Ample negative space between elements +- Clear visual boundaries between overlapping regions + +### Style Guidelines (Cyberpunk Neon) + +**Color Palette**: + +- Primary: Neon pink (#FF00FF), cyan (#00FFFF), electric blue +- Background: Deep black (#0A0A0A), dark purple gradients +- Accents: Neon glow effects, chrome reflections + +**Visual Elements**: + +- Glowing neon outlines on all circle boundaries +- Dark atmospheric backgrounds with subtle grid patterns +- Digital glitch effects on text +- Circuit patterns along connection lines +- Holographic elements in intersection zone +- Rain and reflections on edges + +**Typography**: + +- Glowing neon text (cyan for primary labels, pink for emphasis) +- Digital/tech monospace fonts +- Subtle flickering effects on key terms +- Outlined glow letters for main title +- All caps for section headers + +**Effects**: + +- Neon glow (2-3px bloom) around all text and shapes +- Gradient fills with 40-60% opacity +- Scanline overlay at 10% opacity +- Chromatic aberration on text edges + +--- + +## Part 3: Content Structure Prompt (Text Requirements + Content) + +### Main Title + +**MAJOR INCIDENT DEFINITION** +*Highest Severity Level (S1/P1/Critical)* + +### Three Venn Circles Content + +**Circle 1: Business Impact** + +- Total Service Outage +- Critical Feature Failure +- Data Corruption/Loss +- Security Breach +- Regulatory Compliance Risk +- High-Impact SLA Breach + +**Circle 2: Incident Response** + +- Immediate Actions (0-15 min) + - Automated Monitoring Alerts + - Incident Commander Assigned + - Major Incident Bridge + - Customer Communication +- Investigation & Mitigation (15-60 min) + - Root Cause Analysis + - Rollback/Hotfix + - Failover to Backup + - Workarounds +- Recovery & Post-Mortem (1-24h+) + - Full Service Restored + - RCA Report Published + - Long-Term Fixes + +**Circle 3: Prevention Measures** + +- High Availability Architecture +- Chaos Engineering & Load Testing +- Real-Time Monitoring & Alerting +- Automated Rollbacks +- Strict Change Management +- Security Hardening & Compliance + +### Central Intersection (All Three Circles) + +The intersection represents the critical overlap showing that Major Incidents require: + +- Cross-team collaboration +- Immediate response (15-30 min SLA) +- Significant business impact +- Coordinated resolution + +### Key Criteria Table (Bottom Section) + +| Criteria | Description | +|----------|-------------| +| Scope | Multiple tenants/customers, entire platform | +| Business Criticality | Severe financial/reputational impact | +| Resolution Time | Immediate, 15-30 min acknowledgment | +| Workload Impact | Cloud Ops, DevOps, Security, Support | +| Regulatory Compliance | Legal/security obligations at risk | + +### Footer Text + +"Requires Swift, Coordinated Response to Minimize Downtime" + +--- + +## Visual Composition for 16:9 + +- **Top Section** (10%): Title with neon glow effect +- **Middle Section** (70%): Three overlapping circles with content +- **Bottom Section** (20%): Criteria table in minimalist style + +### Color Assignment per Circle + +- Circle 1 (Business Impact): Cyan (#00FFFF) neon outline +- Circle 2 (Incident Response): Neon Pink (#FF00FF) neon outline +- Circle 3 (Prevention): Electric Blue (#0080FF) neon outline +- Intersection: White glow with purple tint +- Background: Deep black (#0A0A0A) with dark purple gradient + +--- + +**Note**: Do not generate the actual image. Output only the prompt for image generation. \ No newline at end of file diff --git a/Hermes/xingzhi/wiki-sync-circular-infographic-prompts-2026-04-20.md b/Hermes/xingzhi/wiki-sync-circular-infographic-prompts-2026-04-20.md new file mode 100644 index 00000000..f8e69d80 --- /dev/null +++ b/Hermes/xingzhi/wiki-sync-circular-infographic-prompts-2026-04-20.md @@ -0,0 +1,256 @@ +# Wiki Sync 循环流程信息图 - 提示词 + +> 日期:2026-04-20 +> 布局:circular-flow +> 风格:chalkboard + +--- + +## 一、系统提示词 + +``` +Create a professional infographic following these specifications: + +## Image Specifications + +- **Type**: Infographic +- **Layout**: circular-flow +- **Style**: chalkboard +- **Aspect Ratio**: 16:9 (landscape) +- **Language**: 中文 (Simplified Chinese) + +## Core Principles + +- Follow the layout structure precisely for information architecture +- Apply style aesthetics consistently throughout +- If content involves sensitive or copyrighted figures, create stylistically similar alternatives +- Keep information concise, highlight keywords and core concepts +- Use ample whitespace for visual clarity +- Maintain clear visual hierarchy + +## Text Requirements + +- All text must match the specified style treatment +- Main titles should be prominent and readable +- Key concepts should be visually emphasized +- Labels should be clear and appropriately sized +- Use Chinese for all text content + +## Layout Guidelines + +### Circular Flow Layout +- 循环流程:展示持续运行的过程 +- 环形排列:所有节点围绕中心点均布 +- 方向箭头:显示顺时针或逆时针流动方向 +- 无明确起点/终点(持续循环) +- 中心可放置核心概念或系统名称 + +### Wiki Sync 循环结构 +1. 9个步骤节点均匀分布在圆环上 +2. 循环箭头连接各步骤 +3. 中心显示 "Wiki Sync" 系统名称 +4. 标题位于圆环上方 + +## Style Guidelines + +### Chalkboard Style +- 背景:黑板黑 (#1A1A1A) 或深绿黑板色 (#1C2B1C) +- 纹理:真实黑板质感,伴有划痕、粉尘、橡皮擦痕迹 +- 线条:手绘粉笔质感,不完美的sketchy线条 +- 颜色:仅使用粉笔色板 +- 字体:手绘粉笔字体 +- 装饰:手绘星星、下划线、箭头、圆圈、问号 +``` + +--- + +## 二、风格锁定提示词 + +``` +## Style Lock — 必须遵守 + +本信息图使用 chalkboard(粉笔黑板)风格。 + +### 背景 +- 颜色:#1C2B1C(深绿黑板)或 #1A1A1A(黑板黑) +- 纹理:真实黑板纹理,细微划痕、粉尘粒子、橡皮擦痕迹 +- 木质框边(可选):手绘木纹线条 + +### 粉笔线条质量 +- 所有线条必须是手绘的、不完美的sketchy风格 +- 轻微抖动和歪斜 +- 不要干净的矢量线条 + +### 颜色色板(严格使用) +| 角色 | 颜色 | Hex | +|-----|------|-----| +| 主文字/轮廓 | 粉笔白 | #F5F5F5 | +| 高亮/下划线 | 粉笔黄 | #FFE566 | +| 次要高亮 | 粉笔粉 | #FF9999 | +| 技术元素/图表 | 粉笔蓝 | #66B3FF | +| 成功/自然 | 粉笔绿 | #90EE90 | +| 警告/能量 | 粉笔橙 | #FFB366 | +| 木框 | 棕色 | #8B6914 | + +### 装饰元素 +- 5-7角手绘星星(不规则) +- 手绘波浪下划线 +- 手绘箭头(歪斜的笔触 + 箭头) +- 角落的粉笔问号、圆圈 +- 底部散落的粉笔粉末 + +### 禁止出现 +- 渐变 +- 完美几何形状 +- 写实元素 +- 扁平数字图标 + +### 布局规则(circular-flow) +- 9个节点均布于圆环上 +- 顺时针方向箭头连接各节点 +- 中心放置核心概念 +- 标题在圆环顶部 + +## Layout Guidelines - Circular Flow + +### 环形结构 +- 步骤节点:9个步骤均匀分布在圆周上 +- 方向:顺时针流动的箭头 +- 中心:系统名称 "Wiki Sync" +- 标题:信息图主标题在顶部 + +### 节点内容 +每个节点包含: +- 步骤编号(圆形框) +- 步骤名称(粉笔白大字) +- 简要描述(1-2行,较小字体) +- 对应图标或符号 + +### 节点顺序(Wiki Sync 流程) +1. Cron 触发 +2. 加载 skill +3. 启动 TMUX +4. 启动 Claude Code +5. 发送任务指令 +6. 执行 9 步 ingest +7. 解析 SLUG +8. 更新 manifest +9. Telegram 通知 +``` + +--- + +## 三、具体内容提示词 + +``` +INFOGRAPHIC: Wiki Sync 系统循环流程 + +## 主标题 +- 位置:圆环顶部居中 +- 内容:"Wiki Sync 自动同步系统" +- 字体:大型粉笔白(#F5F5F5)手写体 +- 装饰:粉笔黄(#FFE566)双下划线(波浪形手绘) +- 两侧:粉笔粉(#FF9999)小星星装饰 + +## 圆环中心 +- 圆形区域放置系统图标或 "WS" 字样 +- 颜色:粉笔蓝(#66B3FF)轮廓 +- 背景:深绿黑板色 #1C2B1C + +## 循环节点(顺时针排列) + +### 节点 1:Cron 触发 +- 编号圆圈:粉笔黄 +- 步骤名:① Cron 触发 +- 描述:定时器启动,每15分钟 +- 图标:时钟或定时器手绘 + +### 节点 2:加载 Skill +- 编号圆圈:粉笔黄 +- 步骤名:② 加载 Skill +- 描述:加载 llm-wiki-sync +- 图标:齿轮或技能图标 + +### 节点 3:检查待摄 +- 编号圆圈:粉笔粉 +- 步骤名:③ 待摄检查 +- 描述:sync.py --check +- 图标:文档或清单 + +### 节点 4:启动 TMUX +- 编号圆圈:粉笔粉 +- 步骤名:④ 启动 TMUX +- 描述:创建会话 +- 图标:终端图标 + +### 节点 5:Claude Code +- 编号圆圈:粉笔蓝 +- 步骤名:⑤ Claude Code +- 描述:bypassPermissions +- 图标:AI/机器人 + +### 节点 6:执行 Ingest +- 编号圆圈:粉笔蓝 +- 步骤名:执行 Ingest +- 描述:9步标准流程 +- 图标:输入箭头 + +### 节点 7:解析 SLUG +- 编号圆圈:粉笔绿 +- 步骤名:⑦ 解析 SLUG +- 描述:从输出提取标识符 +- 图标:标签/条形码 + +### 节点 8:更新 Manifest +- 编号圆圈:粉笔绿 +- 步骤名:更新 Manifest +- 描述:写入 JSON 状态 +- 图标:数据保存 + +### 节点 9:Telegram 通知 +- 编号圆圈:粉笔橙 +- 步骤名: Telegram 通知 +- 描述:发送同步结果 +- 图标:消息气泡 + +## 循环箭头 +- 颜色:粉笔蓝(#66B3FF) +- 风格:手绘歪斜箭头 +- 方向:顺时针 +- 每两个节点之间 + +## 底部装饰 +- 左侧:粉笔粉 "Claude Code Agent" +- 右侧:粉笔黄 "持续运行 ∞" +- 底部边缘:散落粉笔粉末痕迹 +- 角落:粉笔问号、圆圈装饰 + +## 整体效果 +- 深绿黑板背景 (#1C2B1C) +- 所有文字使用粉笔质感手写体 +- 节点框使用手绘不规则圆形/圆角矩形 +- 箭头使用手绘歪斜线条 +- 保持信息密度,流程清晰 +``` + +--- + +## 四、使用说明 + +``` +使用方法: + +1. 使用支持 circular-flow 布局 + chalkboard 风格的 AI 图像生成工具 +2. 建议比例:16:9 (landscape) +3. 语言:中文(简体) +4. 参考本文件的三部分提示词组合使用 + +提示词组合优先级: +1. 第一部分(系统提示词)- 基础规范 +2. 第二部分(风格锁定)- 必须遵守的约束 +3. 具体内容提示词 - 实际图像内容 +``` + +--- + +*Generated: 2026-04-20* \ No newline at end of file diff --git a/Hermes/xingzhi/wiki-sync-infographic-prompts-2026-04-20.md b/Hermes/xingzhi/wiki-sync-infographic-prompts-2026-04-20.md new file mode 100644 index 00000000..c690ee6b --- /dev/null +++ b/Hermes/xingzhi/wiki-sync-infographic-prompts-2026-04-20.md @@ -0,0 +1,148 @@ +# Wiki Sync 系统信息图提示词 + +> 生成日期:2026-04-20 +> 用途:为 LLM Wiki 自动化同步系统生成信息图 + +--- + +## 第一部分:系统提示词(System Prompt) + +``` +Create a professional infographic following these specifications: + +## Image Specifications +- Type: Infographic +- Layout: hub-spoke +- Style: corporate-memphis +- Aspect Ratio: 16:9 +- Language: 简体中文 + +## Core Principles +- Follow the hub-spoke layout structure precisely for information architecture +- Apply corporate-memphis style aesthetics consistently throughout +- If content involves sensitive or copyrighted figures, create stylistically similar alternatives +- Keep information concise, highlight keywords and core concepts +- Use ample whitespace for visual clarity +- Maintain clear visual hierarchy + +## Text Requirements +- All text must match the specified style treatment +- Main titles should be prominent and readable +- Key concepts should be visually emphasized +- Labels should be clear and appropriately sized +- Use simplified Chinese for all text content + +## Layout Guidelines +- Prominent central hub at the center of the canvas +- Clear spoke lines radiating outward from center +- Nodes at spoke ends with consistent styling +- Even distribution of spokes around the hub +- Icons representing each spoke item +- Brief labels near each node + +## Style Guidelines +- Flat vector illustration style +- Bright, saturated colors: purple, orange, teal, yellow +- White or light pastel background +- Disproportionate human figures (optional) +- Abstract geometric shapes and floating elements +- Solid fills without outlines +- Clean sans-serif typography with bold headings +- Professional but friendly appearance + +--- + +Generate the infographic based on the content below: + +Text labels (in 简体中文): +``` + +--- + +## 第二部分:风格锁定提示词(Style Lock Prompt) + +``` +## 布局规范(hub-spoke) +- 中心:突出显示核心主题"Wiki Sync 自动化同步系统" +- 辐射:6条均匀分布的辐条连接中心与外圈节点 +- 节点:每个辐条末端放置一个组件节点,使用统一的图标风格 +- 连接:辐条使用浅灰色线条,带有标签 + +## 视觉元素(corporate-memphis) +- 背景:纯白色或浅奶油色 (#FFF8F0) +- 主色:明快的紫色 (#8B5CF6)、橙色 (#F97316)、青绿色 (#14B8A6)、黄色 (#FBBF24) +- 图形:扁平化几何图形填充,无描边 +- 人物:抽象的不成比例人物剪影 +- 装饰:漂浮的几何元素(圆形、方形、三角形) +- 字体:思源黑体或类似无衬线字体,标题加粗 + +## 图标风格 +- 简化的线框图标 +- 保持一致的线条粗细(2-3px) +- 圆角处理 +``` + +--- + +## 第三部分:具体内容提示词(Content Prompt) + +``` +INFOGRAPHIC: Wiki Sync 自动化同步系统 + +使用 hub-spoke 布局和 corporate-memphis 风格创建信息图。 + +## 中心主题(Hub) +- 主标题:Wiki Sync 系统 +- 副标题:LLM Wiki 自动化同步解决方案 + +## 六个辐条节点(Spokes) + +### 1. 核心组件(Core) +- 图标:齿轮/工具箱 +- 标签:sync.py CLI +- 描述:manifest 管理、文件追踪 + +### 2. 工作流(Workflow) +- 图标:流程图/箭头 +- 标签:llm-wiki-sync +- 描述:9步标准化执行流程 + +### 3. 定时任务(Schedule) +- 图标:时钟/日历 +- 标签:Cron Job +- 描述:15分钟自动触发 + +### 4. 状态追踪(Tracking) +- 图标:清单/勾选 +- 标签:manifest.json +- 描述:181篇文件状态记录 + +### 5. 交互模式(Interaction) +- 图标:终端/命令行 +- 标签:TMUX + Claude +- 描述:bypassPermissions 启动 + +### 6. 交付通知(Delivery) +- 图标:消息/ telegram +- 标签:Telegram Bot +- 描述:5038825565 消息推送 + +## 底部补充信息 +- 当前状态:已摄入 16 篇 / 待摄入 165 篇 +- 关键规则:顺序执行 + SLUG 解析 +``` + +--- + +## 使用说明 + +1. 将 **第一部分** 作为系统提示词设置到图像生成模型会话开始时 +2. 将 **第二部分** 作为风格参考添加到提示词中 +3. 将 **第三部分** 作为具体内容提示词发送给图像生成模型 +4. 生成的图像应呈现: + - 白色/浅奶油色背景 + - 中心为"Wiki Sync 系统"标题 + - 6个均匀分布的辐条节点 + - 明快的紫、橙、青、黄配色 + - 扁平化几何图标 + - 思源黑体加粗标题 \ No newline at end of file diff --git a/wiki/concepts/BOSCARD.md b/wiki/concepts/BOSCARD.md new file mode 100644 index 00000000..141ca5b1 --- /dev/null +++ b/wiki/concepts/BOSCARD.md @@ -0,0 +1,40 @@ +# BOSCARD + +> BOSCARD 是定义复杂新工作的技术,通过系统化方式明确项目的背景、目标、范围、约束、假设、风险、角色和可交付成果。 + +## 定义 + +BOSCARD 各要素含义: + +| 要素 | 全称 | 说明 | +|------|------|------| +| B | Background | 项目背景,解释为什么存在这个项目 | +| O | Objectives | 项目目标,期望达成的成果 | +| S | Scope | 项目范围,涵盖和不涵盖的内容 | +| C | Constraints | 约束条件,如时间、预算、资源限制 | +| A | Assumptions | 假设前提,项目成功的前提条件 | +| R | Risks | 风险识别,可能影响项目的因素 | +| R | Roles | 角色分工,项目成员职责 | +| D | Deliverables | 可交付成果,项目产出的具体内容 | + +## 应用场景 + +- 项目启动前的需求定义 +- 变更请求的评估 +- 新技术引入的可行性分析 +- 跨部门协作的范围界定 + +## 与敏捷的结合 + +BOSCARD 在敏捷环境中可作为史诗(Epic)或大型用户故事的补充文档,帮助团队在迭代开始前对复杂工作有全面理解。 + +## 起源 + +BOSCARD 源自业务分析领域,是将传统需求分析技术应用于现代项目管理的方法之一。 + +## 相关术语 + +- [[RACI 图]]:责任分配矩阵 +- [[用户故事 (User Stories)]]:以"谁、什么、为什么"格式捕获需求 +- [[SAFe (Scaled Agile Framework)]]:大规模敏捷框架 +- [[相关方轮盘 (Stakeholder Wheel)]]:识别项目相关方的方法论 \ No newline at end of file diff --git a/wiki/concepts/Centralized-Logging.md b/wiki/concepts/Centralized-Logging.md new file mode 100644 index 00000000..995347d0 --- /dev/null +++ b/wiki/concepts/Centralized-Logging.md @@ -0,0 +1,27 @@ +--- +title: "Centralized Logging" +type: concept +tags: [AWS, Observability, Monitoring] +sources: [how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets] +last_updated: 2026-04-19 +--- + +## Summary +集中日志是一种将分散在各处的日志汇聚到统一位置进行监控和分析的可观测性模式。 + +## Definition +Centralized Logging(集中日志)是指将来自多个账号、多个区域或多个服务的日志统一收集到一个中心位置进行存储、查询和分析的架构模式。在 AWS 环境中,通常使用 CloudWatch Logs 或第三方 SIEM 工具实现。 + +## Key Attributes +- **目的**:统一监控、问题排查、安全审计、合规 +- **实现**:CloudWatch Logs、EventBridge、KMS +- **核心组件**:日志组、跨账号订阅、生命周期策略 + +## Why +- 多账号环境下,单个账号登录排查效率低 +- 安全合规要求日志集中存储保留 +- 跨账号问题关联分析需要统一视图 + +## Connections +- [[CloudWatch]] ← 存储 ← [[Centralized Logging]] +- [[EventBridge]] ← 事件转发 ← [[Centralized Logging]] \ No newline at end of file diff --git a/wiki/concepts/Luhmann-四原则.md b/wiki/concepts/Luhmann-四原则.md new file mode 100644 index 00000000..eb5cb1c1 --- /dev/null +++ b/wiki/concepts/Luhmann-四原则.md @@ -0,0 +1,24 @@ +--- +title: "Luhmann 四原则" +type: concept +tags: [knowledge-management, validation] +date: 2026-04-19 +--- + +## Summary +- 定义:ZK Steward 使用的四项验证原则,确保笔记符合 Zettelkasten 方法论 + +## Four Principles +| 原则 | 检查问题 | +|------|---------| +| 原子性 | 能否独立理解? | +| 连接性 | 是否至少2个有意义链接? | +| 有机增长 | 是否避免过度结构化? | +| 持续对话 | 是否激发进一步思考? | + +## Usage +- [[ZK Steward]] 使用四原则作为验证门 + +## Connections +- [[Luhmann 四原则]] ← validation_for ← [[Zettelkasten]] +- [[Luhmann 四原则]] ← implemented_in ← [[ZK Steward]] \ No newline at end of file diff --git a/wiki/concepts/Multi-Account-Strategy.md b/wiki/concepts/Multi-Account-Strategy.md index 9e1481be..903d74af 100644 --- a/wiki/concepts/Multi-Account-Strategy.md +++ b/wiki/concepts/Multi-Account-Strategy.md @@ -2,7 +2,7 @@ title: "Multi-Account Strategy" type: concept tags: [AWS, Architecture, Security] -sources: [how-to-simplify-multi-account-deployments-monitoring] +sources: [how-to-simplify-multi-account-deployments-monitoring, how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets] last_updated: 2026-04-16 --- diff --git a/wiki/concepts/Product.md b/wiki/concepts/Product.md new file mode 100644 index 00000000..e0acd1ff --- /dev/null +++ b/wiki/concepts/Product.md @@ -0,0 +1,33 @@ +--- +title: "Product" +type: concept +tags: + - OpenText + - product-management +date: 2026-04-19 +--- + +## Definition +产品(Product)是具有独立 CI/CD 流水线或发布周期的软件分发。一个产品可能属于另一个母版产品,但如果该组件有自己的 CI/CD 流水线或发布周期,则应作为产品对待。 + +## Related Concepts +- [[Component]]:没有 CI/CD 流水线的库,可能属于某个产品 +- [[Master-Product]]:官方产品命名注册表中的产品定义 +- [[Product-Backlog]]:产品待办列表 + +## Related Entities +- [[Product-Hub-PHT]] + +## Product Attributes +- 业务单元(Business Unit) +- 业务线(Line of Business) +- 产品名称 +- 产品经理 +- 开发经理 +- 产品状态(活跃/维护模式/非活跃) + +## External Integrations +- PSMQ +- P2M +- ITLS +- Backstage \ No newline at end of file diff --git a/wiki/concepts/Zettelkasten.md b/wiki/concepts/Zettelkasten.md new file mode 100644 index 00000000..228c5014 --- /dev/null +++ b/wiki/concepts/Zettelkasten.md @@ -0,0 +1,24 @@ +--- +title: "Zettelkasten" +type: concept +tags: [knowledge-management, methodology] +date: 2026-04-19 +--- + +## Summary +- 定义:卢曼卡片盒知识管理系统,通过原子化笔记和索引入口构建知识网络 +- 核心:笔记作为独立知识单元,可被多个索引指向,发现路径而非分类体系 + +## Key Principles +- 原子性:每条笔记可独立理解 +- 连接性:每条笔记至少2个有意义链接 +- 有机增长:避免过度结构化 +- 持续对话:激发进一步思考 + +## Implementation +- [[ZK Steward]]:AI 时代的 Zettelkasten 实现 + +## Connections +- [[Zettelkasten]] ← invented_by ← [[Niklas Luhmann]] +- [[ZK Steward]] ← implements ← [[Zettelkasten]] +- [[Claude Skills]] ← parallels ← [[Zettelkasten]] \ No newline at end of file diff --git a/wiki/concepts/原子化知识管理.md b/wiki/concepts/原子化知识管理.md new file mode 100644 index 00000000..8505d035 --- /dev/null +++ b/wiki/concepts/原子化知识管理.md @@ -0,0 +1,24 @@ +--- +title: "原子化知识管理" +type: concept +tags: [knowledge-management, methodology] +date: 2026-04-19 +--- + +## Summary +- 定义:将复杂内容拆分为独立、可链接的原子笔记的知识管理方法 +- 核心:每个知识单元独立可理解,通过链接形成网络而非层级结构 + +## Key Features +- 独立可理解:每个原子笔记可独立存在 +- 多重链接:每条笔记可被多个索引指向 +- 有机增长:避免预定义分类,跟随知识自然发展 + +## Implementation +- [[ZK Steward]] 使用原子化知识管理 +- [[Zettelkasten]] 是原子化知识管理的经典实现 + +## Connections +- [[原子化知识管理]] ← methodology_from ← [[Zettelkasten]] +- [[原子化知识管理]] ← implemented_in ← [[ZK Steward]] +- [[原子化知识管理]] ← related_to ← [[双链(Backlinks)]] \ No newline at end of file diff --git a/wiki/entities/Niklas-Luhmann.md b/wiki/entities/Niklas-Luhmann.md new file mode 100644 index 00000000..da107ce1 --- /dev/null +++ b/wiki/entities/Niklas-Luhmann.md @@ -0,0 +1,19 @@ +--- +title: "Niklas Luhmann" +type: entity +tags: [person, knowledge-management] +date: 2026-04-19 +--- + +## Summary +- 角色:德国社会学家,Zettelkasten(卡片盒知识管理)方法论发明者 +- 贡献:开发了通过原子笔记和索引入口构建知识网络的方法,彻底改变了个人知识管理 + +## Key Facts +- 在学术生涯中积累了 9 万张卡片笔记 +- 退休前出版了 70 多本书和数百篇文章 +- 核心发明:将笔记作为独立知识单元,通过索引而非分类体系连接 + +## Connections +- [[Niklas Luhmann]] → invented → [[Zettelkasten]] +- [[ZK Steward]] → implements → [[Niklas Luhmann]] method \ No newline at end of file diff --git a/wiki/entities/Product-Hub-PHT.md b/wiki/entities/Product-Hub-PHT.md new file mode 100644 index 00000000..c806f33c --- /dev/null +++ b/wiki/entities/Product-Hub-PHT.md @@ -0,0 +1,33 @@ +--- +title: "Product Hub (PHT)" +type: entity +tags: + - OpenText + - product-management +date: 2026-04-19 +--- + +## Definition +Product Hub(PHT,Product Hierarchy Tracker)是 OpenText 的产品层级追踪器,用于管理产品相关信息,包括产品元数据、源仓库、制品仓库和用户信息的集中管理。 + +## Aliases +- PHT +- Product Hub +- Product Hierarchy Tracker + +## Key Features +- 产品层级结构管理(业务单元→业务线→产品) +- 产品元数据存储(属性、源报告、制品报告、用户信息) +- 外部系统集成(PSMQ、P2M、ITLS、Backstage) +- 源仓库和制品仓库映射 +- 产品团队和访客访问控制 + +## Related Concepts +- [[Product]]:具有独立 CI/CD 流水线或发布周期的软件分发 +- [[Component]]:没有 CI/CD 流水线的库 +- [[Business-Unit]]:业务单元,产品层级的最高层 +- [[Line-of-Business]]:业务线 +- [[Master-Product]]:母版产品 + +## Related Entities +- [[OpenText]] \ No newline at end of file diff --git a/wiki/entities/StackSets.md b/wiki/entities/StackSets.md index 17ca9953..16dccc31 100644 --- a/wiki/entities/StackSets.md +++ b/wiki/entities/StackSets.md @@ -2,7 +2,7 @@ title: "StackSets" type: entity tags: [AWS, CloudFormation, Multi-Account] -sources: [how-to-simplify-multi-account-deployments-monitoring] +sources: [how-to-simplify-multi-account-deployments-monitoring, how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets] last_updated: 2026-04-16 --- diff --git a/wiki/index.md b/wiki/index.md index 02c67a32..5aaf6f3f 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -1,6 +1,8 @@ ## Overview - [Overview](overview.md) — 知识库总览 +- [ZK Steward Agent](sources/zk-steward.md) — 基于 Niklas Luhmann 的 Zettelkasten 方法论构建 AI 时代的知识网络 + - [2025 年 11 个神级 AI 开源平替,GitHub 杀疯了](sources/2025-年-11-个-神级-AI-开源平替-GitHub-杀疯了.md) — 2025 年 GitHub 上 8 个 AI 领域的顶尖开源项目盘点 - [fireworks-tech-graph](sources/fireworks-tech-graph.md) — AI 驱动技术图生成工具,将中文描述转化为 SVG/PNG 技术图 @@ -124,7 +126,7 @@ - [Cloud DevOp Maturity - Guideline](sources/cloud-devop-maturity-guideline.md) — 企业级 SaaS 公司的 DevOps 成熟度评估框架 - [Cloud Maturity Model A Detailed Guide For Cloud Adoption](sources/Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption.md) — 云成熟度模型(CMM)的5级框架及最佳实践指南 - [DevOps Maturity Model From Traditional IT to Advanced DevOps](sources/DevOps-Maturity-Model-From-Traditional-IT-to-Advanced-DevOps.md) — DevOps 成熟度五级框架(初始→完全成熟),涵盖文化、自动化、流程、协作、技术五大评估领域 -- [How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets](sources/how-to-simplify-multi-account-deployments-monitoring.md) — 多账号环境下 CloudFormation StackSets 部署监控的集中化日志解决方案 +- [How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets](sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md) — 多账号环境下 CloudFormation StackSets 部署监控的集中化日志解决方案 - [Modern ITSM: Driving Efficiency, Security & Resilience](sources/modern-itsm-driving-efficiency-security-resilience.md) — 现代 IT 服务管理的演进趋势,AIOps、零信任架构等技术的应用 - [通过 VPS+内网反向代理实现域名访问内网穿透](sources/vps-frp-reverse-proxy-internal-network-access.md) — 通过 FRP+Caddy 实现内网服务穿透,Aliyun DNS 域名管理 - [在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透](sources/vps-frp-reverse-proxy-ubuntu-internal-network-access.md) — 在 Ubuntu 上通过 FRP+Caddy 实现内网穿透,侧重 SSH 穿透配置 @@ -323,10 +325,14 @@ - [Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance](sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md) — DR 向 Recovery Assurance 演进,SRE 和可观测性工程实践 +- [Public Cloud Learning Sessions (OpenText) - Product Hub (PHT) Overview and Q&A](sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md) — Product Hub (PHT) 产品层级追踪器概述,包括产品请求流程、层级结构和外部系统集成 + - [Public Cloud Learning Sessions - OpenText Tagging Standard V2](sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md) — OpenText 标签标准 V2,涵盖云资源、Kubernetes 对象和容器镜像的标签规范 - [Public Cloud Learning Sessions - Tagging Standards for all hyperscalers](sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md) — 2024 年 1 月 OpenText 标签标准 V1,建立跨 AWS、GCP、Azure 统一标签体系 +- [Public Cloud Learning Sessions - Applicable Business Analysis Techniques](sources/Public-Cloud-Learning-Sessions-Applicable-Business-Analysis-Techniques-20240109.md) — OpenText 业务分析技术学习会议,介绍 BOSCARD、相关方轮盘和需求收集方法 + - [CTP Topic 1 Gruntwork Landing Zone Architecture](sources/ctp-topic-1-gruntwork-landing-zone-architecture.md) — 基于 Gruntwork 的 AWS Landing Zone 架构设计 - [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md) — AWS Landing Zone 部署流程、数据收集策略、基于标签的安全控制机制 - [CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)](sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md) — AWS Landing Zone 设计更新,SaaS(生产)与 Labs(开发)环境区分 @@ -560,6 +566,9 @@ - [Matthew Chapman](entities/Matthew-Chapman.md) — OpenText CTP 需求评审会议主持人 ## Concepts +- [BOSCARD](concepts/BOSCARD.md) — 定义复杂新工作的技术,包含背景、目标、范围、约束、假设、风险、角色、可交付成果 + +- [Product](concepts/Product.md) — 具有独立 CI/CD 流水线或发布周期的软件分发 - [Product-Backlog](concepts/Product-Backlog.md) — 产品待办列表,存放待开发功能和需求,高亮收益和优先级 - [SMACs](concepts/SMACs.md) — 需求提交的标准化入口,用于启动计时器和确保需求追踪 - [Cyber Suite](concepts/Cyber-Suite.md) — PSAC 发布的产品安全加密标准,包括标准/可选套件和审查要求 diff --git a/wiki/log.md b/wiki/log.md index 11d39635..76f4e4bd 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1,3 +1,38 @@ +## [2026-04-19] verify | Todoist Task Manager: Agent Task Visibility +- Source file: raw/Agent/usecases/todoist-task-manager.md +- Status: ✅ 已同步 +- Summary: 通过 Todoist API 将 AI Agent 内部推理和进度日志同步到任务管理工具,实现长时间运行任务的可视化追踪 +- Concepts: Agent-Task-Visibility(已有), Task-Automation(已有) +- Entities: Todoist(已有), OpenClaw(已有) +- Source page: wiki/sources/todoist-task-manager-agent-task-visibility.md +- Notes: 源文件无更新,确认为已同步状态 + +## [2026-04-19] ingest | Cloud Operating Model: Key Strategies and Best Practices +- Source file: raw/Cloud & DevOps/Cloud Operating Model Key Strategies and Best Practices.md +- Status: ✅ 成功摄入 +- Summary: 云运营模型(COM)的设计策略与最佳实践,四大支柱框架(治理、自动化、安全、成本管理)、六步设计流程、行业用例、挑战与解决方案 +- Concepts created: Cloud Operating Model(已有), FinOps(已有), Zero Trust Architecture(已有), Multi-Cloud(已有), Cloud Maturity Model(已有), Policy-as-Code(已有), AIOps(已有) +- Entities created: Gartner(已有), Flexera(已有), AWS(已有), Azure(已有), GCP(已有) +- Source page: wiki/sources/Cloud-Operating-Model-Key-Strategies-and-Best-Practices.md +- Notes: 文档已在早期被摄入,source page 已存在,本次确认为已同步状态 + +## [2026-04-19] ingest | Public vs Private vs Hybrid: Cloud Differences Explained +- Source file: raw/Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained.md +- Status: ✅ 成功摄入 +- Summary: 公有云、私有云和混合云三种云计算部署模式的核心区别,包括各模式的优势、劣势、适用场景,以及云计算共享责任模型 +- Concepts created: Public Cloud(已有), Private Cloud(已有), Hybrid Cloud(已有), Shared Responsibility Model(已有) +- Entities created: BMC(已有) +- Source page: wiki/sources/Public-vs-Private-vs-Hybrid-Cloud-Differences-Explained.md +- Notes: 文档已在早期被摄入,source page、index、overview、concepts 均已存在,本次确认为已同步状态 + +## [2026-04-19] ingest | Public Cloud Learning Sessions - Applicable Business Analysis Techniques (20240109) +- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109-.md +- Status: ✅ 成功摄入 +- Summary: OpenText 业务分析技术学习会议,介绍 BOSCARD、相关方轮盘和需求收集方法 +- Concepts created: BOSCARD, T 型技能, 用户故事, SAFe +- Source page: wiki/sources/Public-Cloud-Learning-Sessions-Applicable-Business-Analysis-Techniques-20240109.md +- Notes: + ## [2026-04-19] ingest | Public Cloud Learning Sessions - Tagging Standards for all hyperscalers (20240123) - Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md - Status: ✅ 成功摄入 @@ -26,6 +61,15 @@ - Source page: wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md - Notes: +## [2026-04-19] ingest | Public Cloud Learning Sessions (OpenText) - Product Hub (PHT) Overview and Q&A (20240806) +- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md +- Status: ✅ 成功摄入 +- Summary: Product Hub (PHT) 产品层级追踪器概述,包括产品请求流程、层级结构(业务单元→业务线→产品)和外部系统集成 +- Concepts created: Product +- Entities created: Product Hub (PHT) +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md +- Notes: + ## [2026-04-19] ingest | CTP Topic 53 Why bother with Cloud - Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-53-why-bother-with-cloud.md - Status: ✅ 成功摄入 @@ -2072,3 +2116,30 @@ - Entities created: AWS Redshift(新增), Leader Node(新增), Compute Node(新增), AWS(已有) - Source page: wiki/sources/ctp-topic-68-introduction-to-redshift.md - Notes: 添加 Redshift 数据仓库概念,与现有 AWS 服务形成知识体系 + +## [2026-04-19] ingest | How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets +- Source file: raw/Cloud & DevOps/How to Simplify Multi-Account Deployments Monitoring Centralized Logs for AWS CloudFormation StackSets.md +- Status: ✅ 成功摄入(更新) +- Summary: AWS 多账号环境下 CloudFormation StackSets 部署监控的集中化日志解决方案,通过 EventBridge 跨账号事件转发 + CloudWatch Logs 集中存储实现单一管理界面监控 +- Concepts created: Centralized Logging(新增), Cross-Account Event Forwarding(新增) +- Entities created: StackSets(已有), EventBridge(已有), CloudWatch(已有), AWS Organizations(已有) +- Source page: wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md +- Notes: 对同一主题的更新摄入,补充新发现的文档(旧版保留在 wiki/sources/how-to-simplify-multi-account-deployments-monitoring.md),新增概念:Centralized Logging + +## [2026-04-19] ingest | ZK Steward Agent +- Source file: raw/Agent/agency-agents/specialized/zk-steward.md +- Status: ✅ 成功摄入 +- Summary: 基于 Niklas Luhmann 的 Zettelkasten 方法论构建 AI 时代的知识网络,通过原子化知识管理和索引入口实现有机网络增长 +- Concepts created: Zettelkasten(新增), Luhmann 四原则(新增), 原子化知识管理(新增) +- Entities created: Niklas Luhmann(新增) +- Source page: wiki/sources/zk-steward.md +- Notes: 新增 ZK Steward Agent 定义,作为 AI 时代的 Luhmann 实现 + +## [2026-04-19] ingest | Polymarket Autopilot: Automated Paper Trading +- Source file: raw/Agent/usecases/polymarket-autopilot.md +- Status: ✅ 成功摄入 +- Summary: AI Agent 自动化模拟交易预测市场,通过 TAIL(趋势跟随)、BONDING(逆势)、SPREAD(价差套利)三种策略执行模拟交易,使用 Cron Jobs 定时执行并通过 Discord 推送每日绩效报告 +- Concepts created: TAIL Strategy, BONDING Strategy, SPREAD Strategy +- Entities created: Polymarket(已有) +- Source page: wiki/sources/polymarket-autopilot.md +- Notes: 更新摄入,补充 Key Quotes 和策略详细定义 diff --git a/wiki/overview.md b/wiki/overview.md index d8f55bbd..e6bee70c 100644 --- a/wiki/overview.md +++ b/wiki/overview.md @@ -81,6 +81,7 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境 - 数字导师:用AI复活历史人物,让其成为日常对话的思维顾问,通过思维蒸馏技术提取人物的核心心智模型 - 思维蒸馏:通过6个并行Agent从6个维度(著作、对话、表达DNA、他者视角、决策、时间线)采集信息,提炼核心思维框架生成AI Skill的技术 - Claude Skills:写给 Claude 的"说明书"和技术规范,将反复执行的任务拆解为 AI 可稳定复用流程的技术范式 +- Zettelkasten:卢曼卡片盒知识管理系统,通过原子化笔记和索引入口构建知识网络 - **fireworks-tech-graph**:AI 驱动技术图生成工具,将中文描述转化为 SVG/PNG 格式的架构图、流程图、UML 图 - 开源大语言模型:以 DeepSeek、Qwen 为代表的开源基座大模型 @@ -197,7 +198,7 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境 - **Cloud Operating Model: Key Strategies and Best Practices** — 云运营模型(COM)四大支柱:治理、自动化、安全、成本管理,涵盖行业用例(金融、医疗、零售、SaaS)和未来趋势(AI 驱动运维、可持续云计算、多云策略) - **用Docker中安装Navidrome** — 使用 Docker Compose 部署 Navidrome 音乐流媒体服务器的配置文件示例 - **Modern ITSM: Driving Efficiency, Security & Resilience** — 现代 IT 服务管理的演进趋势,AIOps、零信任架构、Policy-as-Code 等技术的应用 -- **How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets** — 多账号环境下 CloudFormation StackSets 部署监控的集中化日志解决方案,通过 EventBridge 跨账号事件转发 + CloudWatch Logs 实现单一管理界面监控 +- **How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets** — 多账号环境下 CloudFormation StackSets 部署监控的集中化日志解决方案,通过 EventBridge 跨账号事件转发 + CloudWatch Logs 实现单一管理界面监控([旧版](sources/how-to-simplify-multi-account-deployments-monitoring.md)) - **Public vs Private vs Hybrid: Cloud Differences Explained** — 公有云、私有云和混合云三种部署模式的核心区别,包括各模式的优势、劣势、适用场景,以及云计算共享责任模型 - **How Agentic AI can help for Cloud DevOps** — Agentic AI 增强 Cloud DevOps 的七大领域:自主事件检测与响应、自动化云部署与配置、智能成本优化、AI 驱动安全与合规、智能日志分析与可观测性、SaaS 多租户管理、AI 辅助决策 - **How Can a Multi Cloud Strategy Transform Your Business ROI?** — 多云策略的定义、8大优势(避免供应商锁定、弹性可靠性、安全性、可扩展性、成本优化、创新访问、合规性、性能优化)、实施4步骤、3个行业用例(电商、医疗、金融) @@ -211,6 +212,10 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境 - **What is DevSecOps? Best Practices, Benefits, and Tools** — DevSecOps 方法论详解(SDLC 安全集成、SAST/SCA/IAST/DAST 四大工具、Shift Left/Right 策略、企业实施挑战) - **Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab migration** — OpenText 将代码仓库从 GitHub Enterprise 迁移到 GitLab,self-serve 模式 +- **Public Cloud Learning Sessions (OpenText) - Applicable Business Analysis Techniques** — OpenText 业务分析技术学习会议,介绍 BOSCARD(背景、目标、范围、约束、假设、风险、角色、可交付成果)、相关方轮盘和需求收集方法(T 型技能、用户故事 + 元数据、SAFe 框架) + +- BOSCARD(Background、Objectives、Scope、Constraints、Assumptions、Risks、Roles、Deliverables):定义复杂新工作的系统化技术,帮助在项目早期明确范围、目标和可交付成果,避免目标、时间线和交付物的混淆 + - **Ubuntu 服务器通过 rsync 实现日常增量备份** — 使用 rsync 实现 Ubuntu 服务器到 NAS 的增量备份,涵盖 NFS 永久挂载和灾难恢复 - **CTP Topic 46 NetApps on AWS** — NetApp Cloud Volume ONTAP (CVO) 架构、部署、数据分层(EBS→S3)、安全加密与灾备(SnapMirror) diff --git a/wiki/sources/Public-Cloud-Learning-Sessions-Applicable-Business-Analysis-Techniques-20240109.md b/wiki/sources/Public-Cloud-Learning-Sessions-Applicable-Business-Analysis-Techniques-20240109.md new file mode 100644 index 00000000..e1038958 --- /dev/null +++ b/wiki/sources/Public-Cloud-Learning-Sessions-Applicable-Business-Analysis-Techniques-20240109.md @@ -0,0 +1,50 @@ +--- +title: "Public Cloud Learning Sessions - Applicable Business Analysis Techniques - 20240109" +type: source +tags: [cloud-learning, business-analysis, techniques] +date: 2026-04-19 +--- + +## Source File +- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109-.md]] + +## Summary +- 核心主题:业务分析技术学习会议,介绍 BOSSARD、相关方轮盘和需求收集方法 +- 问题域:企业数字化转型中的需求分析与变更管理 +- 方法/机制:BOSCARD(背景、目标、范围、约束、假设、风险、角色、可交付成果)、相关方轮盘、用户故事 + 元数据的需求收集方法 +- 结论/价值:业务分析帮助明确业务架构变更需求,确保 IT 系统和流程变更的一致性 + +## Key Claims +- 业务分析将业务需求与变更解决方案对齐,考虑 IT 和流程变更、培训和角色转换 +- T 型技能在敏捷 Squad 中很有价值,结合核心专业知识与相关技能的广泛理解 +- BOSCARD 在项目早期明确定义背景、目标、范围、约束、假设、风险、角色和可交付成果 +- 相关方轮盘从客户开始顺时针识别所有项目相关方(客户、合作伙伴、监管机构、员工、管理层、所有者、竞争对手) +- 用户故事结合元数据可增加需求捕获的严谨性,SAFe 框架包含特性、能力与非功能性需求 + +## Key Quotes +> "If you can get scope tied down early on and agreed, that's priceless." — 提前锁定并同意范围的价值 +> "Every requirement should be independent, meaning not duplicating something else, that's the I in invest, negotiable, so the business should state what they need, but be open to how it's implemented." — INVEST 原则中的独立性解释 + +## Key Concepts +- [[业务分析 (Business Analysis)]]:将业务需求与变更解决方案对齐的实践 +- [[BOSCARD]]:定义复杂新工作的技术,包含背景、目标、范围、约束、假设、风险、角色、可交付成果 +- [[相关方轮盘 (Stakeholder Wheel)]]:识别项目所有相关方的方法论 +- [[RACI 图]]:责任分配矩阵,明确 Responsible、Accountable、Consulted、Informed 角色 +- [[用户故事 (User Stories)]]:以"谁、什么、为什么"格式捕获需求 +- [[SAFe (Scaled Agile Framework)]]:大规模敏捷框架,包含特性、能力、非功能性需求 +- [[T 型技能]]:在敏捷 Squad 中结合核心专业与广泛相关技能 +- [[BCS]]:业务分析学习资源来源之一 +- [[IIBA]]:国际商业分析协会,业务分析认证机构 + +## Key Entities +- [[OpenText]] — 主办 Public Cloud Learning Sessions 的企业内容管理公司 + +## Connections +- [[业务分析 (Business Analysis)]] ← 包含 ← [[BOSCARD]] +- [[业务分析 (Business Analysis)]] ← 包含 ← [[相关方轮盘 (Stakeholder Wheel)]] +- [[需求收集]] ← 依赖 ← [[用户故事 (User Stories)]] +- [[需求收集]] ← 扩展 ← [[SAFe (Scaled Agile Framework)]] +- [[T 型技能]] → 应用 → [[敏捷实践]] + +## Contradictions +- (暂无) \ No newline at end of file diff --git a/wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md b/wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md index e63ac3f5..cdc67247 100644 --- a/wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md +++ b/wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md @@ -4,7 +4,7 @@ type: source tags: [灾难恢复, 业务连续性, 持续交付, 特性管理] date: 2019-01-18 sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"] -last_updated: 2026-04-18 +last_updated: 2026-04-19 --- ## Source File @@ -50,4 +50,4 @@ last_updated: 2026-04-18 - [[持续交付]] ← 适用场景 ← [[RTO (Recovery Time Objective)]], [[RPO (Recovery Point Objective)]] ## Contradictions -- (暂无) +- (暂无) \ No newline at end of file diff --git a/wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md b/wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md new file mode 100644 index 00000000..7fe544af --- /dev/null +++ b/wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md @@ -0,0 +1,42 @@ +--- +title: How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets +type: source +tags: [aws, cloudformation, stacksets, multi-account, centralized-logging, eventbridge, cloudwatch] +date: 2025-10-25 +--- + +## Source File +- [[raw/Cloud & DevOps/How to Simplify Multi-Account Deployments Monitoring Centralized Logs for AWS CloudFormation StackSets.md]] + +## Summary +- 核心主题:AWS 多账号环境下 CloudFormation StackSets 部署监控的集中化日志解决方案 +- 问题域:多账号基础设施部署的可观测性 +- 方法/机制:EventBridge 跨账号事件转发 + CloudWatch Logs 集中存储 +- 结论/价值:实现单一管理界面监控跨账号的 CloudFormation 部署事件 + +## Key Claims +- StackSets 支持跨多个账号和区域部署基础设施,但缺乏集中监控能力 +- 通过 EventBridge 规则捕获目标账号的 CloudFormation 事件 +- 跨账号事件转发至管理账号的集中式事件总线 +- CloudWatch Logs 提供统一的日志存储和查询能力 + +## Key Quotes +> "When a critical security baseline deployed across 50 accounts suddenly starts failing, teams face the daunting task of logging into each account individually to understand what went wrong and which accounts were affected." + +## Key Concepts +- [[Multi-Account Strategy]]:AWS 多账号架构策略,通过将工作负载分离到多个账号提升安全性和治理能力 +- [[Centralized Logging]]:集中日志监控模式,将分散在各账号的日志汇聚到统一位置 +- [[Cross-Account Event Forwarding]]:跨账号事件转发,通过 EventBridge 实现账号间的事件传递 + +## Key Entities +- [[StackSets]]:CloudFormation 跨账号跨区域部署功能 +- [[EventBridge]]:AWS 无服务器事件总线服务 +- [[CloudWatch]]:AWS 监控和可观测性服务 +- [[AWS Organizations]]:AWS 账户管理服务 + +## Connections +- [[StackSets]] ← depends_on ← [[EventBridge]] +- [[CloudWatch]] ← receives ← [[EventBridge]] +- [[AWS Organizations]] ← manages ← [[StackSets]] + +## Contradictions \ No newline at end of file diff --git a/wiki/sources/polymarket-autopilot.md b/wiki/sources/polymarket-autopilot.md index ea7813a8..26fab920 100644 --- a/wiki/sources/polymarket-autopilot.md +++ b/wiki/sources/polymarket-autopilot.md @@ -2,7 +2,7 @@ title: "Polymarket Autopilot: Automated Paper Trading" type: source tags: [polymarket, autopilot, paper-trading, prediction-market] -date: 2026-04-17 +date: 2026-04-19 --- ## Source File @@ -23,19 +23,25 @@ date: 2026-04-17 ## Key Quotes > "Manually monitoring prediction markets for arbitrage opportunities and executing trades is time-consuming and requires constant attention." — 手动监控预测市场的痛点 +> "You want to test and refine trading strategies without risking real capital." — 模拟交易的核心价值 + ## Key Concepts - [[Paper Trading]]:模拟交易,使用虚拟资金测试策略无需承担真实风险 - [[Cron Jobs]]:定时任务调度,AI Agent 每 15 分钟执行一次市场扫描 - [[Discord Integration]]:通过 Discord Webhook 实现每日交易报告推送 -- [[Sub-agent Spawning]]:在高峰期并行分析多个市场 +- [[Subagent Spawning]]:在高峰期并行分析多个市场 +- [[TAIL Strategy]]:趋势跟随策略,当概率 >60% 且成交量飙升时买入 +- [[BONDING Strategy]]:逆势策略,当市场因新闻过度反应时买入 +- [[SPREAD Strategy]]:价差套利策略,当 YES+NO > 1.05 时进行套利 ## Key Entities - [[Polymarket]]:预测市场平台,提供 API 获取市场价格、成交量、价差数据 ## Connections -- [[Cron Jobs]] ← 驱动 ← [[Polymarket Autopilot]] -- [[Discord]] ← 通知 ← [[Polymarket Autopilot]] -- [[Subagent 管理]] ← 实现 ← [[Polymarket Autopilot]](并行市场分析) +- [[Cron Jobs]] ← 驱动 ← [[polymarket-autopilot]] +- [[Discord]] ← 通知 ← [[polymarket-autopilot]] +- [[Subagent 管理]] ← 实现 ← [[polymarket-autopilot]](并行市场分析) +- [[Paper Trading]] ← 核心功能 ← [[polymarket-autopilot]] ## Contradictions - (暂无) \ No newline at end of file diff --git a/wiki/sources/todoist-task-manager-agent-task-visibility.md b/wiki/sources/todoist-task-manager-agent-task-visibility.md index e898a87f..fd408e9a 100644 --- a/wiki/sources/todoist-task-manager-agent-task-visibility.md +++ b/wiki/sources/todoist-task-manager-agent-task-visibility.md @@ -2,7 +2,7 @@ title: "Todoist Task Manager: Agent Task Visibility" type: source tags: [] -date: 2026-04-17 +date: 2026-04-19 --- ## Source File diff --git a/wiki/sources/zk-steward.md b/wiki/sources/zk-steward.md new file mode 100644 index 00000000..43c02963 --- /dev/null +++ b/wiki/sources/zk-steward.md @@ -0,0 +1,45 @@ +--- +title: "ZK Steward Agent" +type: source +tags: [agent, knowledge-management, zettelkasten] +date: 2026-04-19 +--- + +## Source File +- [[raw/Agent/agency-agents/specialized/zk-steward.md]] + +## Summary +- 核心主题:基于 Niklas Luhmann 的 Zettelkasten 方法论构建 AI 时代的知识网络 +- 问题域:如何将复杂任务转化为知识网络的有机组成部分,而非一次性答案 +- 方法/机制:原子化知识管理 + 有机网络增长 + Luhmann 四原则验证 +- 结论/价值:通过索引入口而非分类体系构建知识网络,每条笔记可被多个索引指向 + +## Key Claims +- ZK Steward 是 AI 时代的 Niklas Luhmann,将复杂任务转化为知识网络的有机部分 +- 原子性原则:笔记可独立理解 +- 连接性原则:每条笔记至少2个有意义链接 +- 有机增长原则:避免过度结构化 +- 持续对话原则:激发进一步思考 + +## Key Quotes +> "Every reply states the expert perspective and addresses the user by name." — ZK Steward 设计原则 + +> "Index entries are entry points, not categories; one note can be pointed to by many indices." — 索引设计原则 + +## Key Concepts +- [[Zettelkasten]]:卢曼卡片盒知识管理系统 +- [[Luhmann 四原则]]:原子性、连接性、有机增长、持续对话 +- [[原子化知识管理]]:将复杂内容拆分为独立、可链接的原子笔记 +- [[索引入口]]:作为发现路径而非分类体系的索引结构 + +## Key Entities +- [[Niklas Luhmann]]:德国社会学家,Zettelkasten 方法论发明者 +- [[Andrej Karpathy]]:领域思维专家,研究深度学习 + +## Connections +- [[ZK Steward]] ← applies ← [[Zettelkasten]] +- [[ZK Steward]] ← implements ← [[Luhmann 四原则]] +- [[ZK Steward]] ← parallels ← [[OpenClaw]](AI Agent 管理工具) +- [[ZK Steward]] ← integrates ← [[Claude Code]] + +## Contradictions \ No newline at end of file