Auto-sync: 2026-04-19 08:02
This commit is contained in:
@@ -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
|
||||
- （暂无）
|
||||
@@ -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
|
||||
- （暂无）
|
||||
- （暂无）
|
||||
@@ -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
|
||||
@@ -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
|
||||
- （暂无）
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "Todoist Task Manager: Agent Task Visibility"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-17
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
|
||||
45
wiki/sources/zk-steward.md
Normal file
45
wiki/sources/zk-steward.md
Normal file
@@ -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
|
||||
Reference in New Issue
Block a user