ishenwei/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update nexus: fix conflicts and sync local changes

Browse Source
This commit is contained in:
Shen Wei
2026-04-26 12:06:50 +08:00
parent 191797c01b
commit f09834b5a5
2443 changed files with 254323 additions and 255154 deletions
Download Patch File Download Diff File Expand all files Collapse all files

82
wiki/concepts/14种UML图.md
View File

@@ -1,41 +1,41 @@
---
title: "14种UML图"
type: concept
tags: []
sources: [fireworks-tech-graph]
last_updated: 2026-04-18
---
## Description
fireworks-tech-graph 完整支持的 14 种 UML（统一建模语言）图类型，涵盖结构图、行为图和交互图三大类。
## 完整图类型列表
| UML 类型 | 描述 | 推荐风格 |
|---------|------|---------|
| **类图** | 类、属性、方法、关系 | 风格 1, 4 |
| **组件图** | 软件组件和依赖关系 | 风格 1, 3 |
| **部署图** | 硬件节点和软件部署 | 风格 3 |
| **包图** | 包组织和依赖关系 | 风格 1, 4 |
| **复合结构图** | 类/组件的内部结构 | 风格 1, 3 |
| **对象图** | 对象实例和关系 | 风格 1, 4 |
| **用例图** | 参与者、用例、系统边界 | 风格 1 |
| **活动图** | 工作流、并行流程 | 风格 3 |
| **状态机图** | 状态转换和事件 | 风格 2, 3 |
| **序列图** | 时间顺序的消息交换 | 风格 2 |
| **通信图** | 对象交互和消息 | 风格 1, 2 |
| **时序图** | 状态随时间的变化 | 风格 2 |
| **交互概览图** | 高层交互流程 | 风格 1, 2 |
| **ER 图** | 实体关系数据模型 | 风格 1, 3 |
## 分类
**结构图（7种）：** 类图、组件图、部署图、包图、复合结构图、对象图、用例图
**行为图（2种）：** 活动图、状态机图
**交互图（5种）：** 序列图、通信图、时序图、交互概览图
## Relationships
- [[14种UML图]] is supported_by [[fireworks-tech-graph]]
- [[14种UML图]] is used_by [[7种视觉风格系统]]
---
title: "14种UML图"
type: concept
tags: []
sources: [fireworks-tech-graph]
last_updated: 2026-04-18
---
## Description
fireworks-tech-graph 完整支持的 14 种 UML（统一建模语言）图类型，涵盖结构图、行为图和交互图三大类。
## 完整图类型列表
| UML 类型 | 描述 | 推荐风格 |
|---------|------|---------|
| **类图** | 类、属性、方法、关系 | 风格 1, 4 |
| **组件图** | 软件组件和依赖关系 | 风格 1, 3 |
| **部署图** | 硬件节点和软件部署 | 风格 3 |
| **包图** | 包组织和依赖关系 | 风格 1, 4 |
| **复合结构图** | 类/组件的内部结构 | 风格 1, 3 |
| **对象图** | 对象实例和关系 | 风格 1, 4 |
| **用例图** | 参与者、用例、系统边界 | 风格 1 |
| **活动图** | 工作流、并行流程 | 风格 3 |
| **状态机图** | 状态转换和事件 | 风格 2, 3 |
| **序列图** | 时间顺序的消息交换 | 风格 2 |
| **通信图** | 对象交互和消息 | 风格 1, 2 |
| **时序图** | 状态随时间的变化 | 风格 2 |
| **交互概览图** | 高层交互流程 | 风格 1, 2 |
| **ER 图** | 实体关系数据模型 | 风格 1, 3 |
## 分类
**结构图（7种）：** 类图、组件图、部署图、包图、复合结构图、对象图、用例图
**行为图（2种）：** 活动图、状态机图
**交互图（5种）：** 序列图、通信图、时序图、交互概览图
## Relationships
- [[14种UML图]] is supported_by [[fireworks-tech-graph]]
- [[14种UML图]] is used_by [[7种视觉风格系统]]

116
wiki/concepts/7种视觉风格系统.md
View File

@@ -1,58 +1,58 @@
---
title: "7种视觉风格系统"
type: concept
tags: []
sources: [fireworks-tech-graph]
last_updated: 2026-04-18
---
## Description
fireworks-tech-graph 内置的 7 种视觉风格系统，每种风格定义了背景色、字体、颜色 Token、布局规范和使用场景推荐。
## The 7 Styles
| # | 名称 | 背景色 | 字体 | 适用场景 |
|---|------|--------|------|---------|
| 1 | **扁平图标风**（默认） | `#ffffff` | Helvetica | 博客、幻灯片、技术文档 |
| 2 | **暗黑极客风** | `#0f0f1a` | SF Mono / Fira Code | GitHub README、开发者文章 |
| 3 | **工程蓝图风** | `#0a1628` | Courier New | 架构设计文档、工程规范 |
| 4 | **Notion 极简风** | `#ffffff` | system-ui | Notion、Confluence、内部 Wiki |
| 5 | **玻璃态卡片风** | `#0d1117` 渐变 | Inter | 产品官网、演讲 Keynote |
| 6 | **Claude 官方风格** | `#f8f6f3` | system-ui | Anthropic 风格图表，温暖专业美学 |
| 7 | **OpenAI 官方风格** | `#ffffff` | system-ui | OpenAI 风格图表，简洁现代设计 |
## 风格选择指南
**UML 图类型：**
- 类图/组件图/包图：风格 1（扁平图标风）或风格 4（Notion极简风）
- 序列图/时序图：风格 2（暗黑极客风）
- 状态机图/活动图：风格 3（工程蓝图风）
- 用例图/交互图：风格 1（扁平图标风）
**AI/Agent 图类型：**
- RAG/Agentic Search：风格 2（暗黑极客风）或风格 5（玻璃态卡片风）
- 记忆架构：风格 3（工程蓝图风）
- Multi-Agent：风格 5（玻璃态卡片风）
**文档类型：**
- 内部文档：风格 4（Notion极简风）
- 技术博客：风格 1（扁平图标风）
- GitHub README：风格 2（暗黑极客风）
- 演示文稿：风格 5（玻璃态卡片风）或风格 6（Claude官方风格）
**品牌特定：**
- Anthropic/Claude 项目：风格 6（Claude官方风格）
- OpenAI 项目：风格 7（OpenAI官方风格）
## Key Enhancements
- `style_overrides`：微调标题对齐或配色 token
- `containers[].header_prefix` / `containers[].header_text`：工程编号分区标题（风格3）
- `containers[].side_label`：左侧 Layer Label（风格6）
- `window_controls` / `meta_*`：终端/文档风格顶部 chrome
- `blueprint_title_block`：蓝图标题信息框（风格3）
## Relationships
- [[7种视觉风格系统]] is implemented_by [[fireworks-tech-graph]]
- [[7种视觉风格系统]] is used_for [[14种UML图]]
- [[7种视觉风格系统]] is used_for [[RAG]]
- [[7种视觉风格系统]] is used_for [[AI Agent]]
---
title: "7种视觉风格系统"
type: concept
tags: []
sources: [fireworks-tech-graph]
last_updated: 2026-04-18
---
## Description
fireworks-tech-graph 内置的 7 种视觉风格系统，每种风格定义了背景色、字体、颜色 Token、布局规范和使用场景推荐。
## The 7 Styles
| # | 名称 | 背景色 | 字体 | 适用场景 |
|---|------|--------|------|---------|
| 1 | **扁平图标风**（默认） | `#ffffff` | Helvetica | 博客、幻灯片、技术文档 |
| 2 | **暗黑极客风** | `#0f0f1a` | SF Mono / Fira Code | GitHub README、开发者文章 |
| 3 | **工程蓝图风** | `#0a1628` | Courier New | 架构设计文档、工程规范 |
| 4 | **Notion 极简风** | `#ffffff` | system-ui | Notion、Confluence、内部 Wiki |
| 5 | **玻璃态卡片风** | `#0d1117` 渐变 | Inter | 产品官网、演讲 Keynote |
| 6 | **Claude 官方风格** | `#f8f6f3` | system-ui | Anthropic 风格图表，温暖专业美学 |
| 7 | **OpenAI 官方风格** | `#ffffff` | system-ui | OpenAI 风格图表，简洁现代设计 |
## 风格选择指南
**UML 图类型：**
- 类图/组件图/包图：风格 1（扁平图标风）或风格 4（Notion极简风）
- 序列图/时序图：风格 2（暗黑极客风）
- 状态机图/活动图：风格 3（工程蓝图风）
- 用例图/交互图：风格 1（扁平图标风）
**AI/Agent 图类型：**
- RAG/Agentic Search：风格 2（暗黑极客风）或风格 5（玻璃态卡片风）
- 记忆架构：风格 3（工程蓝图风）
- Multi-Agent：风格 5（玻璃态卡片风）
**文档类型：**
- 内部文档：风格 4（Notion极简风）
- 技术博客：风格 1（扁平图标风）
- GitHub README：风格 2（暗黑极客风）
- 演示文稿：风格 5（玻璃态卡片风）或风格 6（Claude官方风格）
**品牌特定：**
- Anthropic/Claude 项目：风格 6（Claude官方风格）
- OpenAI 项目：风格 7（OpenAI官方风格）
## Key Enhancements
- `style_overrides`：微调标题对齐或配色 token
- `containers[].header_prefix` / `containers[].header_text`：工程编号分区标题（风格3）
- `containers[].side_label`：左侧 Layer Label（风格6）
- `window_controls` / `meta_*`：终端/文档风格顶部 chrome
- `blueprint_title_block`：蓝图标题信息框（风格3）
## Relationships
- [[7种视觉风格系统]] is implemented_by [[fireworks-tech-graph]]
- [[7种视觉风格系统]] is used_for [[14种UML图]]
- [[7种视觉风格系统]] is used_for [[RAG]]
- [[7种视觉风格系统]] is used_for [[AI Agent]]

210
wiki/concepts/ABTesting.md
View File

@@ -1,105 +1,105 @@
---
title: "A/B Testing Framework"
type: concept
tags: ["optimization", "statistics", "ppc", "creative"]
---
## Definition
A/B Testing Framework（A/B 测试框架）是创意优化的标准方法论，通过对照实验验证假设，区分真实效果提升与随机波动，以数据驱动决策。
## Core Principles
1. **假设驱动（Hypothesis-Driven）**：每个测试始于明确假设
2. **控制变量（Single Variable）**：每次只改变一个变量
3. **统计显著性（Statistical Significance）**：基于置信区间判断结果可靠性
4. **可重复性（Reproducibility）**：测试结果可推广至更大规模
## Test Design
### Hypothesis Template
> "If [change], then [expected outcome], because [reason]."
示例：
> "If we add urgency language to headlines, then CTR will increase by 10%, because scarcity drives action."
### Sample Size Calculation
| 转化率 | 最小样本（每变体） | 预估测试周期 |
|--------|-------------------|-------------|
| 5% | 2,500 | 7-14 天 |
| 2% | 6,500 | 14-28 天 |
| 1% | 13,000 | 28-56 天 |
**公式**（简化版）：
```
n = 16 × σ² / δ²
其中：σ = 标准差，δ = 最小可检测差异
```
### Statistical Significance
| 置信度 | Z-score | 可靠性 |
|--------|---------|--------|
| 90% | 1.645 | 初步参考 |
| 95% | 1.96 | 标准基准 ✅ |
| 99% | 2.576 | 高确定性 |
## Testing Workflow
```
1. Define Hypothesis → 2. Design Test → 3. Launch → 4. Monitor → 5. Analyze → 6. Scale/Iterate
```
### Step 1: Define Hypothesis
- 明确要测试的变量（Headline A vs Headline B）
- 设定预期提升目标
- 确定主要指标（CTR/CVR/CPA）
### Step 2: Design Test
- 流量分配（50/50 或 80/20）
- 测试持续时间（2-4 周）
- 样本量计算
### Step 3: Launch
- 确保变体间随机分配
- 记录测试开始时间
- 不在测试期间修改其他变量
### Step 4: Monitor
- 每日检查基本数据
- 避免提前终止（除非严重错误）
- 监控外部因素（季节性/节假日）
### Step 5: Analyze
- 计算统计显著性
- 分析次级指标（CVR/CPA）
- 撰写结论报告
### Step 6: Scale/Iterate
- 胜出方案规模化推广
- 败出方案归档（积累学习）
- 从败出中提取新假设
## Common Test Types
| 类型 | 测试内容 | 适用场景 |
|------|---------|---------|
| Headline Test | 不同标题变体 | RSA 优化 |
| CTA Test | 不同行动号召 | 转化率优化 |
| Image Test | 不同图片/颜色 | Display/Social |
| Landing Page Test | 不同落地页 | 转化路径优化 |
| Audience Test | 不同受众 | 定向策略优化 |
## Success Criteria
- **统计显著性**：95%+ 置信度
- **测试周期**：2-4 周
- **最小样本**：每变体至少 1000+ 转化
- **Winner Criteria**：显著优于控制组（10%+）
## Sources
- [[paid-media-creative-strategist]]
- [[paid-media-ppc-strategist]]
---
title: "A/B Testing Framework"
type: concept
tags: ["optimization", "statistics", "ppc", "creative"]
---
## Definition
A/B Testing Framework（A/B 测试框架）是创意优化的标准方法论，通过对照实验验证假设，区分真实效果提升与随机波动，以数据驱动决策。
## Core Principles
1. **假设驱动（Hypothesis-Driven）**：每个测试始于明确假设
2. **控制变量（Single Variable）**：每次只改变一个变量
3. **统计显著性（Statistical Significance）**：基于置信区间判断结果可靠性
4. **可重复性（Reproducibility）**：测试结果可推广至更大规模
## Test Design
### Hypothesis Template
> "If [change], then [expected outcome], because [reason]."
示例：
> "If we add urgency language to headlines, then CTR will increase by 10%, because scarcity drives action."
### Sample Size Calculation
| 转化率 | 最小样本（每变体） | 预估测试周期 |
|--------|-------------------|-------------|
| 5% | 2,500 | 7-14 天 |
| 2% | 6,500 | 14-28 天 |
| 1% | 13,000 | 28-56 天 |
**公式**（简化版）：
```
n = 16 × σ² / δ²
其中：σ = 标准差，δ = 最小可检测差异
```
### Statistical Significance
| 置信度 | Z-score | 可靠性 |
|--------|---------|--------|
| 90% | 1.645 | 初步参考 |
| 95% | 1.96 | 标准基准 ✅ |
| 99% | 2.576 | 高确定性 |
## Testing Workflow
```
1. Define Hypothesis → 2. Design Test → 3. Launch → 4. Monitor → 5. Analyze → 6. Scale/Iterate
```
### Step 1: Define Hypothesis
- 明确要测试的变量（Headline A vs Headline B）
- 设定预期提升目标
- 确定主要指标（CTR/CVR/CPA）
### Step 2: Design Test
- 流量分配（50/50 或 80/20）
- 测试持续时间（2-4 周）
- 样本量计算
### Step 3: Launch
- 确保变体间随机分配
- 记录测试开始时间
- 不在测试期间修改其他变量
### Step 4: Monitor
- 每日检查基本数据
- 避免提前终止（除非严重错误）
- 监控外部因素（季节性/节假日）
### Step 5: Analyze
- 计算统计显著性
- 分析次级指标（CVR/CPA）
- 撰写结论报告
### Step 6: Scale/Iterate
- 胜出方案规模化推广
- 败出方案归档（积累学习）
- 从败出中提取新假设
## Common Test Types
| 类型 | 测试内容 | 适用场景 |
|------|---------|---------|
| Headline Test | 不同标题变体 | RSA 优化 |
| CTA Test | 不同行动号召 | 转化率优化 |
| Image Test | 不同图片/颜色 | Display/Social |
| Landing Page Test | 不同落地页 | 转化路径优化 |
| Audience Test | 不同受众 | 定向策略优化 |
## Success Criteria
- **统计显著性**：95%+ 置信度
- **测试周期**：2-4 周
- **最小样本**：每变体至少 1000+ 转化
- **Winner Criteria**：显著优于控制组（10%+）
## Sources
- [[paid-media-creative-strategist]]
- [[paid-media-ppc-strategist]]

76
wiki/concepts/ADDIE-Model.md
View File

@@ -1,38 +1,38 @@
---
title: "ADDIE 模型"
type: concept
tags: []
last_updated: 2026-04-25
---
## Definition
ADDIE 模型是企业培训课程开发的系统性框架，包含五个阶段：
1. **Analysis（分析）**：培训需求分析——组织诊断、能力差距识别、培训 ROI 估算、需求优先级排序
2. **Design（设计）**：学习目标设计——基于 Bloom 认知分类定义可衡量的学习成果
3. **Development（开发）**：课程内容开发——微课、案例、练习、题库、课件
4. **Implementation（实施）**：培训交付——线上/线下/混合学习交付方式
5. **Evaluation（评估）**：效果评估——基于 Kirkpatrick 四级模型评估培训效果
## Aliases
- ADDIE
- ADDIE Model
- ADDIE 教学设计模型
- 分析-设计-开发-实施-评估
## Key Characteristics
- **每个阶段有明确交付物**：分析报告、教学设计文档、课程包、培训执行计划、效果评估报告
- **迭代性**：实践中通常循环迭代，而非严格线性执行
- **系统性**：确保培训项目从需求到效果有完整闭环
## Related Concepts
- [[Kirkpatrick-四级评估]]：ADDIE 的最后一步（Evaluation）的具体方法论
- [[Bloom-认知分类]]：ADDIE Design 阶段学习目标设计的认知层次框架
- [[Kolb-体验式学习圈]]：与 ADDIE 并行的另一学习设计框架，侧重体验循环
## Source
- [[corporate-training-designer]]
---
title: "ADDIE 模型"
type: concept
tags: []
last_updated: 2026-04-25
---
## Definition
ADDIE 模型是企业培训课程开发的系统性框架，包含五个阶段：
1. **Analysis（分析）**：培训需求分析——组织诊断、能力差距识别、培训 ROI 估算、需求优先级排序
2. **Design（设计）**：学习目标设计——基于 Bloom 认知分类定义可衡量的学习成果
3. **Development（开发）**：课程内容开发——微课、案例、练习、题库、课件
4. **Implementation（实施）**：培训交付——线上/线下/混合学习交付方式
5. **Evaluation（评估）**：效果评估——基于 Kirkpatrick 四级模型评估培训效果
## Aliases
- ADDIE
- ADDIE Model
- ADDIE 教学设计模型
- 分析-设计-开发-实施-评估
## Key Characteristics
- **每个阶段有明确交付物**：分析报告、教学设计文档、课程包、培训执行计划、效果评估报告
- **迭代性**：实践中通常循环迭代，而非严格线性执行
- **系统性**：确保培训项目从需求到效果有完整闭环
## Related Concepts
- [[Kirkpatrick-四级评估]]：ADDIE 的最后一步（Evaluation）的具体方法论
- [[Bloom-认知分类]]：ADDIE Design 阶段学习目标设计的认知层次框架
- [[Kolb-体验式学习圈]]：与 ADDIE 并行的另一学习设计框架，侧重体验循环
## Source
- [[corporate-training-designer]]

104
wiki/concepts/AGENTS.md.md
View File

@@ -1,52 +1,52 @@
---
title: "AGENTS.md"
type: concept
tags: [opencode, openclaw, project-context, agent]
sources: [如何在ubuntu上安装opencode并配置vibe-kanban, 万字讲透openclaw-workspace深度解析-2026-03-21]
last_updated: 2026-03-21
---
## Definition
**AGENTS.md** 是 AI Agent 框架中定义 Agent **工作说明书**的核心文件。存在两种语境：
1. **OpenCode 语境**（自动生成）：位于项目根目录，由 `/init` 命令自动分析项目结构生成，包含项目结构、编码规范、约定俗成等上下文信息，帮助 AI 理解项目的整体背景。
2. **OpenClaw 语境**（手动配置）：位于 `~/.openclaw/workspace/`，是用户手动编写的岗位说明书，定义 Agent 的职责、边界、多 Agent 协作流程。
## OpenCode: 自动生成
运行 `/init` 命令后，OpenCode 会自动分析项目结构并生成 `AGENTS.md`：
```bash
cd /path/to/project
opencode
/init
```
最佳实践：
- **纳入版本控制**：OpenCode 官方建议将 AGENTS.md 提交到 Git，以获得一致的跨团队体验
- **持续维护**：随着项目演进，定期更新 AGENTS.md 以反映最新的架构决策
- **具体示例**：提供代码示例和模式说明，帮助 AI 生成符合项目风格的代码
## OpenClaw: 手动配置
在 OpenClaw 中，AGENTS.md 回答的是：
- 这个 Agent 叫什么，主要职责是什么？
- 遇到什么类型的任务该用什么方式处理？
- 有哪些事情是绝对不该做的？
- 当用户说某类话时，该优先走哪套流程？
- 在多 Agent 场景里，该怎么协调其他 Agent？
**经验法则**：300-500 字的 AGENTS.md，比 2000 字的更有效。边界比能力描述更重要——LLM 默认会"发挥创意"，需要约束。
**场景触发优于通用指令**：与其写"始终保持专业语气"，不如写"当用户问技术问题时，使用专业准确的措辞；当用户随意聊天时，语气可以轻松一些"。
## Related Concepts
- [[OpenCode]] — OpenCode 语境下生成和使用 AGENTS.md 的核心工具
- [[OpenClaw]] — OpenClaw 语境下 AGENTS.md 所属的框架
- [[SOUL.md]] — Agent 性格档案，与 AGENTS.md 分工明确
- [[Agent Specialization]] — AGENTS.md 定义多 Agent 协作的核心机制
- [[Plan Mode]] — 利用 AGENTS.md 提供充足上下文以生成精准方案
- [[Vibe Coding]] — AI 辅助编程的工作流理念
---
title: "AGENTS.md"
type: concept
tags: [opencode, openclaw, project-context, agent]
sources: [如何在ubuntu上安装opencode并配置vibe-kanban, 万字讲透openclaw-workspace深度解析-2026-03-21]
last_updated: 2026-03-21
---
## Definition
**AGENTS.md** 是 AI Agent 框架中定义 Agent **工作说明书**的核心文件。存在两种语境：
1. **OpenCode 语境**（自动生成）：位于项目根目录，由 `/init` 命令自动分析项目结构生成，包含项目结构、编码规范、约定俗成等上下文信息，帮助 AI 理解项目的整体背景。
2. **OpenClaw 语境**（手动配置）：位于 `~/.openclaw/workspace/`，是用户手动编写的岗位说明书，定义 Agent 的职责、边界、多 Agent 协作流程。
## OpenCode: 自动生成
运行 `/init` 命令后，OpenCode 会自动分析项目结构并生成 `AGENTS.md`：
```bash
cd /path/to/project
opencode
/init
```
最佳实践：
- **纳入版本控制**：OpenCode 官方建议将 AGENTS.md 提交到 Git，以获得一致的跨团队体验
- **持续维护**：随着项目演进，定期更新 AGENTS.md 以反映最新的架构决策
- **具体示例**：提供代码示例和模式说明，帮助 AI 生成符合项目风格的代码
## OpenClaw: 手动配置
在 OpenClaw 中，AGENTS.md 回答的是：
- 这个 Agent 叫什么，主要职责是什么？
- 遇到什么类型的任务该用什么方式处理？
- 有哪些事情是绝对不该做的？
- 当用户说某类话时，该优先走哪套流程？
- 在多 Agent 场景里，该怎么协调其他 Agent？
**经验法则**：300-500 字的 AGENTS.md，比 2000 字的更有效。边界比能力描述更重要——LLM 默认会"发挥创意"，需要约束。
**场景触发优于通用指令**：与其写"始终保持专业语气"，不如写"当用户问技术问题时，使用专业准确的措辞；当用户随意聊天时，语气可以轻松一些"。
## Related Concepts
- [[OpenCode]] — OpenCode 语境下生成和使用 AGENTS.md 的核心工具
- [[OpenClaw]] — OpenClaw 语境下 AGENTS.md 所属的框架
- [[SOUL.md]] — Agent 性格档案，与 AGENTS.md 分工明确
- [[Agent Specialization]] — AGENTS.md 定义多 Agent 协作的核心机制
- [[Plan Mode]] — 利用 AGENTS.md 提供充足上下文以生成精准方案
- [[Vibe Coding]] — AI 辅助编程的工作流理念

84
wiki/concepts/AI-Agent.md
View File

@@ -1,42 +1,42 @@
---
title: "AI Agent"
type: concept
tags: [ai-agent, autonomous, llm]
last_updated: 2026-04-25
---
## Definition
AI Agent（AI 智能体）是围绕大语言模型（LLM）构建的循环控制系统，具备感知目标、规划步骤、执行动作、反思结果的能力，实现真正的自主行动。
## Core Loop
AI Agent 通过一个连续循环过程实现其目标：
1. **获取任务**：接收高层目标（用户或自动触发）
2. **扫描场景**：感知环境，获取上下文信息（工具/记忆/资源）
3. **仔细思考**：由推理模型驱动，分析任务与场景，制定行动计划
4. **采取行动**：调用适当工具（API/代码/数据库），作用于外部世界
5. **观察并迭代**：观察行动结果，更新上下文，循环回到步骤3
## Key Capabilities
- **自主决策**：根据上下文自主选择行动策略
- **工具使用**：调用 API、执行代码、查询数据库
- **多步骤规划**：分解复杂任务为可执行步骤
- **自我反思**：基于执行结果调整下一步行动
## Role in AI System Architecture
- **执行层**：AI Agent 作为 AI 系统的"行动系统"，负责将决策转化为实际行动
- 使用 [[Large Language Model]] 进行推理
- 使用 [[RAG]] 确保信息来源准确
## Related Concepts
- [[Large Language Model]] — Agent 的"大脑"
- [[RAG]] — Agent 的"记忆"
- [[Model Context Protocol]] — Agent 连接外部工具的标准协议
- [[ReAct Pattern]] — Agent 的推理-行动模式
- [[Agentic AI]] — 具备自主决策能力的 AI 系统
## Sources
- [[llms-rag-ai-agent-三个到底什么区别]]
- [[designing-for-agentic-ai]]
- [[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]]
- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]
---
title: "AI Agent"
type: concept
tags: [ai-agent, autonomous, llm]
last_updated: 2026-04-25
---
## Definition
AI Agent（AI 智能体）是围绕大语言模型（LLM）构建的循环控制系统，具备感知目标、规划步骤、执行动作、反思结果的能力，实现真正的自主行动。
## Core Loop
AI Agent 通过一个连续循环过程实现其目标：
1. **获取任务**：接收高层目标（用户或自动触发）
2. **扫描场景**：感知环境，获取上下文信息（工具/记忆/资源）
3. **仔细思考**：由推理模型驱动，分析任务与场景，制定行动计划
4. **采取行动**：调用适当工具（API/代码/数据库），作用于外部世界
5. **观察并迭代**：观察行动结果，更新上下文，循环回到步骤3
## Key Capabilities
- **自主决策**：根据上下文自主选择行动策略
- **工具使用**：调用 API、执行代码、查询数据库
- **多步骤规划**：分解复杂任务为可执行步骤
- **自我反思**：基于执行结果调整下一步行动
## Role in AI System Architecture
- **执行层**：AI Agent 作为 AI 系统的"行动系统"，负责将决策转化为实际行动
- 使用 [[Large Language Model]] 进行推理
- 使用 [[RAG]] 确保信息来源准确
## Related Concepts
- [[Large Language Model]] — Agent 的"大脑"
- [[RAG]] — Agent 的"记忆"
- [[Model Context Protocol]] — Agent 连接外部工具的标准协议
- [[ReAct Pattern]] — Agent 的推理-行动模式
- [[Agentic AI]] — 具备自主决策能力的 AI 系统
## Sources
- [[llms-rag-ai-agent-三个到底什么区别]]
- [[designing-for-agentic-ai]]
- [[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]]
- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]

112
wiki/concepts/AI-Auto-Response.md
View File

@@ -1,56 +1,56 @@
---
title: "AI Auto-Response"
type: concept
tags: []
sources: []
---
# AI Auto-Response
## Definition
AI Agent 基于客户消息内容和知识库自动生成并发送回复，无需人工介入的处理模式，是多渠道客服降低人工成本的核心机制。
## Workflow
```
Customer Message
↓
[Language Detection] → Detect language
↓
[Intent Classification] → FAQ / Appointment / Complaint / Review
↓
[Business Knowledge Base] → Retrieve relevant info
↓
[Response Generation] → Contextual, language-matched reply
↓
[Send to Channel] (or [Test Mode] → log only)
```
## Effectiveness Metrics
| Metric | Description |
|--------|-------------|
| **Auto-response Rate** | 自动处理的消息占比（目标: >80%） |
| **Response Time** | 从收到消息到发送回复的平均时长 |
| **Escalation Rate** | 转人工的消息占比 |
| **Customer Satisfaction** | 自动化回复的客户满意度评分 |
餐厅案例：自动处理率 80%，平均响应时间 <2 分钟（对比人工 4+ 小时）。
## Quality Safeguards
- **Never invent**：禁止生成知识库中没有的信息
- **Handoff guard**：不确定时主动转人工而非猜测
- **Brand consistency**：回复语气与品牌形象一致
## Related Concepts
- [[Intent-Classification]]：意图分类决定触发哪种回复策略
- [[Business-Knowledge-Base]]：知识库是自动回复的信息来源
- [[Human-Handoff]]：AI 边界之外的场景转交人工
- [[Language-Detection]]：回复语言跟随客户语言
## Sources
- [[multi-channel-customer-service]]
---
title: "AI Auto-Response"
type: concept
tags: []
sources: []
---
# AI Auto-Response
## Definition
AI Agent 基于客户消息内容和知识库自动生成并发送回复，无需人工介入的处理模式，是多渠道客服降低人工成本的核心机制。
## Workflow
```
Customer Message
↓
[Language Detection] → Detect language
↓
[Intent Classification] → FAQ / Appointment / Complaint / Review
↓
[Business Knowledge Base] → Retrieve relevant info
↓
[Response Generation] → Contextual, language-matched reply
↓
[Send to Channel] (or [Test Mode] → log only)
```
## Effectiveness Metrics
| Metric | Description |
|--------|-------------|
| **Auto-response Rate** | 自动处理的消息占比（目标: >80%） |
| **Response Time** | 从收到消息到发送回复的平均时长 |
| **Escalation Rate** | 转人工的消息占比 |
| **Customer Satisfaction** | 自动化回复的客户满意度评分 |
餐厅案例：自动处理率 80%，平均响应时间 <2 分钟（对比人工 4+ 小时）。
## Quality Safeguards
- **Never invent**：禁止生成知识库中没有的信息
- **Handoff guard**：不确定时主动转人工而非猜测
- **Brand consistency**：回复语气与品牌形象一致
## Related Concepts
- [[Intent-Classification]]：意图分类决定触发哪种回复策略
- [[Business-Knowledge-Base]]：知识库是自动回复的信息来源
- [[Human-Handoff]]：AI 边界之外的场景转交人工
- [[Language-Detection]]：回复语言跟随客户语言
## Sources
- [[multi-channel-customer-service]]

174
wiki/concepts/AI-ChatOps.md
View File

@@ -1,87 +1,87 @@
---
title: "AI ChatOps"
tags:
- devops
- chatops
- ai
- collaboration
- observability
created: 2026-04-25
---
# AI ChatOps
## Definition
AI ChatOps 是通过自然语言接口（Slack / Teams / CLI）进行故障排查，AI 提供日志分析和解决方案建议的运维协作模式。Agentic AI 作为 24/7 的运维助手，工程师随时可通过对话获取即时支持。
## 与 Traditional ChatOps 的区别
| 维度 | Traditional ChatOps | AI ChatOps |
|------|--------------------|------------|
| 响应能力 | 依赖人工在线 | 24/7 即时响应 |
| 问题诊断 | 人工搜索日志 | AI 自动分析 + 建议 |
| 知识依赖 | 依赖个人经验 | 跨团队知识聚合 |
| 学习能力 | 经验不可复制 | 持续学习 + 知识积累 |
| 平均响应 | 数分钟至数小时 | 毫秒级 |
## Agentic AI ChatOps 能力
```python
ChatOps_Capabilities = {
"Log Query": "自然语言查询日志: 'Show me errors from API service in last hour'",
"Incident Summary": "AI 生成事故摘要: 'This is caused by X, fix is Y'",
"Runbook Suggestion": "AI 推荐运维手册: 'Based on error pattern, try runbook #42'",
"Metric Correlation": "AI 关联指标: 'CPU spike correlates with DB connection pool'",
"Action Execution": "AI 执行操作: '/runbook restart-service api-gateway'",
"Post-mortem": "AI 生成复盘报告: 自动生成 incident timeline"
}
```
## 示例
> Engineer in Slack:
> `@ai-ops Our API is slow, users are complaining`
>
> AI Response:
> ```
> 🔍 Analysis complete:
>
> Root Cause: External payment API timeout (upstream)
> - Payment API p99 latency: 15,000ms (normally 200ms)
> - Correlated: API gateway retries causing backpressure
>
> Suggested Actions:
> 1. Enable circuit breaker (auto-deploy via /ops deploy)
> 2. Fallback to cache for payment status (auto via /ops deploy)
> 3. Monitor: https://grafana.link/d/abc123
>
> Shall I proceed with option 1? (yes/no)
> ```
## 与 [[AIOps]] 的关系
AI ChatOps 是 [[AIOps]] 能力矩阵的用户交互层：
```python
AIOps_Capabilities = {
"Anomaly Detection": "检测异常模式",
"Root Cause Analysis": "自动诊断",
"Predictive Maintenance": "预测性维护",
"Smart Alerting": "减少告警疲劳",
"Automated Remediation": "自动修复",
"Capacity Optimization": "容量优化",
"AI ChatOps ←": "自然语言交互层" # ← 本页
}
```
## Related Concepts
- [[AIOps]] — ChatOps 是 AIOps 的用户交互接口
- [[Root Cause Analysis]] — ChatOps 依赖 RCA 能力
- [[Observability]] — ChatOps 依赖可观测性数据
- [[Incident Management]] — ChatOps 加速事故响应
## Related Sources
- [[how-agentic-ai-can-help-for-cloud-devops]]
---
title: "AI ChatOps"
tags:
- devops
- chatops
- ai
- collaboration
- observability
created: 2026-04-25
---
# AI ChatOps
## Definition
AI ChatOps 是通过自然语言接口（Slack / Teams / CLI）进行故障排查，AI 提供日志分析和解决方案建议的运维协作模式。Agentic AI 作为 24/7 的运维助手，工程师随时可通过对话获取即时支持。
## 与 Traditional ChatOps 的区别
| 维度 | Traditional ChatOps | AI ChatOps |
|------|--------------------|------------|
| 响应能力 | 依赖人工在线 | 24/7 即时响应 |
| 问题诊断 | 人工搜索日志 | AI 自动分析 + 建议 |
| 知识依赖 | 依赖个人经验 | 跨团队知识聚合 |
| 学习能力 | 经验不可复制 | 持续学习 + 知识积累 |
| 平均响应 | 数分钟至数小时 | 毫秒级 |
## Agentic AI ChatOps 能力
```python
ChatOps_Capabilities = {
"Log Query": "自然语言查询日志: 'Show me errors from API service in last hour'",
"Incident Summary": "AI 生成事故摘要: 'This is caused by X, fix is Y'",
"Runbook Suggestion": "AI 推荐运维手册: 'Based on error pattern, try runbook #42'",
"Metric Correlation": "AI 关联指标: 'CPU spike correlates with DB connection pool'",
"Action Execution": "AI 执行操作: '/runbook restart-service api-gateway'",
"Post-mortem": "AI 生成复盘报告: 自动生成 incident timeline"
}
```
## 示例
> Engineer in Slack:
> `@ai-ops Our API is slow, users are complaining`
>
> AI Response:
> ```
> 🔍 Analysis complete:
>
> Root Cause: External payment API timeout (upstream)
> - Payment API p99 latency: 15,000ms (normally 200ms)
> - Correlated: API gateway retries causing backpressure
>
> Suggested Actions:
> 1. Enable circuit breaker (auto-deploy via /ops deploy)
> 2. Fallback to cache for payment status (auto via /ops deploy)
> 3. Monitor: https://grafana.link/d/abc123
>
> Shall I proceed with option 1? (yes/no)
> ```
## 与 [[AIOps]] 的关系
AI ChatOps 是 [[AIOps]] 能力矩阵的用户交互层：
```python
AIOps_Capabilities = {
"Anomaly Detection": "检测异常模式",
"Root Cause Analysis": "自动诊断",
"Predictive Maintenance": "预测性维护",
"Smart Alerting": "减少告警疲劳",
"Automated Remediation": "自动修复",
"Capacity Optimization": "容量优化",
"AI ChatOps ←": "自然语言交互层" # ← 本页
}
```
## Related Concepts
- [[AIOps]] — ChatOps 是 AIOps 的用户交互接口
- [[Root Cause Analysis]] — ChatOps 依赖 RCA 能力
- [[Observability]] — ChatOps 依赖可观测性数据
- [[Incident Management]] — ChatOps 加速事故响应
## Related Sources
- [[how-agentic-ai-can-help-for-cloud-devops]]

106
wiki/concepts/AI-Driven-Task-Extraction.md
View File

@@ -1,53 +1,53 @@
---
title: "AI-Driven Task Extraction"
type: concept
tags: [ai, task-management, nlp, automation]
sources: [todoist-task-manager, meeting-notes-action-items]
last_updated: 2026-04-21
---
## Definition
AI-Driven Task Extraction（AI 驱动的任务提取）是指利用大语言模型（LLM）从非结构化文本中自动识别并提取任务要素（谁/做什么/何时/何地/优先级），并将其转换为结构化任务数据的过程。核心技术栈：LLM（解析） + Task API（存储） + Cron Job（追踪）。
## Aliases
- AI Task Extraction
- Task Extraction from Text
- 自动任务提取
- Natural Language to Task
- 任务自动录入
## How It Works
1. **输入源**：邮件正文、会议记录、聊天消息、语音转录文本
2. **LLM 解析**：Prompt 设计引导模型输出结构化 JSON（含任务描述、截止日期、优先级、标签）
3. **任务创建**：调用 Todoist/Jira/Notion 等 API 创建任务
4. **确认反馈**：回复用户"已创建：[任务名] @[项目] 🔴 高优先级，截止 [日期]"
5. **持续追踪**：Cron Job 扫描逾期任务，主动推送提醒
## Prompt Example
```
你是一个任务提取助手。从以下文本中提取所有待办事项，
输出 JSON 格式：{"tasks": [{"description": "", "due": "", "priority": 1-4, "project": ""}]}
原文：
"{user_input}"
```
## Use Cases
- **Email Inbox**：扫描 Gmail 收件箱，提取"需要回复"类任务
- **Meeting Notes**：从 Otter.ai/Zoom 转录中提取行动项
- **Slack/Discord**：监听频道消息，自动识别任务请求
- **Voice Transcription**：SuperCall 电话转录 → 提取待确认/待执行事项
- **Newsletter 阅读**：文章中提到的"需要跟进"点 → 创建研究任务
## Key Relationships
- [[LLM]] — 核心解析引擎
- [[Todoist API]] — 任务存储后端
- [[Todoist Task Manager]] — 自然语言→任务提取的完整实现
- [[Meeting Notes Action Items]] — 会议场景的任务提取
- [[Cron Job]] — 逾期任务主动追踪
- [[Preference Learning]] — 从用户反馈中优化提取准确率
---
title: "AI-Driven Task Extraction"
type: concept
tags: [ai, task-management, nlp, automation]
sources: [todoist-task-manager, meeting-notes-action-items]
last_updated: 2026-04-21
---
## Definition
AI-Driven Task Extraction（AI 驱动的任务提取）是指利用大语言模型（LLM）从非结构化文本中自动识别并提取任务要素（谁/做什么/何时/何地/优先级），并将其转换为结构化任务数据的过程。核心技术栈：LLM（解析） + Task API（存储） + Cron Job（追踪）。
## Aliases
- AI Task Extraction
- Task Extraction from Text
- 自动任务提取
- Natural Language to Task
- 任务自动录入
## How It Works
1. **输入源**：邮件正文、会议记录、聊天消息、语音转录文本
2. **LLM 解析**：Prompt 设计引导模型输出结构化 JSON（含任务描述、截止日期、优先级、标签）
3. **任务创建**：调用 Todoist/Jira/Notion 等 API 创建任务
4. **确认反馈**：回复用户"已创建：[任务名] @[项目] 🔴 高优先级，截止 [日期]"
5. **持续追踪**：Cron Job 扫描逾期任务，主动推送提醒
## Prompt Example
```
你是一个任务提取助手。从以下文本中提取所有待办事项，
输出 JSON 格式：{"tasks": [{"description": "", "due": "", "priority": 1-4, "project": ""}]}
原文：
"{user_input}"
```
## Use Cases
- **Email Inbox**：扫描 Gmail 收件箱，提取"需要回复"类任务
- **Meeting Notes**：从 Otter.ai/Zoom 转录中提取行动项
- **Slack/Discord**：监听频道消息，自动识别任务请求
- **Voice Transcription**：SuperCall 电话转录 → 提取待确认/待执行事项
- **Newsletter 阅读**：文章中提到的"需要跟进"点 → 创建研究任务
## Key Relationships
- [[LLM]] — 核心解析引擎
- [[Todoist API]] — 任务存储后端
- [[Todoist Task Manager]] — 自然语言→任务提取的完整实现
- [[Meeting Notes Action Items]] — 会议场景的任务提取
- [[Cron Job]] — 逾期任务主动追踪
- [[Preference Learning]] — 从用户反馈中优化提取准确率

70
wiki/concepts/AI-Logo-Generation.md
View File

@@ -1,35 +1,35 @@
---
title: "AI Logo Generation"
type: concept
tags: []
last_updated: 2026-04-23
---
## Description
AI Logo Generation（AI Logo 生成）是指使用人工智能工具自动生成品牌标识（Logo）、图标、吉祥物等品牌视觉资产的设计方式。通过结构化的提示词策略，AI 可以根据品牌名称、行业属性、风格偏好等输入，产出扁平化、几何、手绘、渐变等多种风格的专业级视觉资产。
## Key Characteristics
- **低门槛**：非设计师也能快速产出专业级品牌视觉资产
- **高效率**：几分钟内完成多版本设计方案，传统流程需数小时至数天
- **可迭代**：支持 SVG（矢量格式，适合缩放）和 PNG（位图格式）多格式导出
- **风格多样**：支持扁平化、几何、手绘、渐变、3D 等多种风格
## Tools & Methods
- [[baoyu-imagine]]：Claude Code Skill，通过 Logo 专用提示词策略驱动 AI 生图
- [[Midjourney]]：通用 AI 生图工具，Logo 生成需大量迭代
- [[Nano Banana]]：Google AI 生图工具，可用于图标设计
- [[Stable Diffusion]]：开源 AI 生图模型，可通过 LoRA 微调生成风格一致的品牌资产
## Relationship to Related Concepts
- [[prompt-engineering]]：AI Logo 生成的核心技术支撑
- [[Claude-Code-Skill]]：baoyu-imagine 的载体形式
- [[Vibe-Coding]]：AI Logo 生成可作为 Vibe Coding 工作流中的视觉资产生成环节
## Related Sources
- [[我做了个-skill-让-ai-帮你生成-logo-和图标]]
## Aliases
- AI Logo 生成
- AI 图标生成
- 品牌视觉资产 AI 生成
- AI 标志设计
---
title: "AI Logo Generation"
type: concept
tags: []
last_updated: 2026-04-23
---
## Description
AI Logo Generation（AI Logo 生成）是指使用人工智能工具自动生成品牌标识（Logo）、图标、吉祥物等品牌视觉资产的设计方式。通过结构化的提示词策略，AI 可以根据品牌名称、行业属性、风格偏好等输入，产出扁平化、几何、手绘、渐变等多种风格的专业级视觉资产。
## Key Characteristics
- **低门槛**：非设计师也能快速产出专业级品牌视觉资产
- **高效率**：几分钟内完成多版本设计方案，传统流程需数小时至数天
- **可迭代**：支持 SVG（矢量格式，适合缩放）和 PNG（位图格式）多格式导出
- **风格多样**：支持扁平化、几何、手绘、渐变、3D 等多种风格
## Tools & Methods
- [[baoyu-imagine]]：Claude Code Skill，通过 Logo 专用提示词策略驱动 AI 生图
- [[Midjourney]]：通用 AI 生图工具，Logo 生成需大量迭代
- [[Nano Banana]]：Google AI 生图工具，可用于图标设计
- [[Stable Diffusion]]：开源 AI 生图模型，可通过 LoRA 微调生成风格一致的品牌资产
## Relationship to Related Concepts
- [[prompt-engineering]]：AI Logo 生成的核心技术支撑
- [[Claude-Code-Skill]]：baoyu-imagine 的载体形式
- [[Vibe-Coding]]：AI Logo 生成可作为 Vibe Coding 工作流中的视觉资产生成环节
## Related Sources
- [[我做了个-skill-让-ai-帮你生成-logo-和图标]]
## Aliases
- AI Logo 生成
- AI 图标生成
- 品牌视觉资产 AI 生成
- AI 标志设计

110
wiki/concepts/AIOps.md
View File

@@ -1,55 +1,55 @@
---
title: AIOps
tags:
- ai
- devops
- it-operations
created: 2026-04-22
---
# AIOps
## Definition
AIOps (Artificial Intelligence for IT Operations) is the application of artificial intelligence and machine learning to IT operations. It automates the detection, diagnosis, and resolution of operational issues in cloud environments.
## Purpose
AIOps enables:
- **Proactive issue detection** — Identifying problems before they impact users
- **Intelligent alerting** — Reducing noise and focusing on actionable alerts
- **Automated root cause analysis** — Accelerating incident resolution
- **Predictive analytics** — Forecasting capacity needs and potential failures
## Relationship with Cloud Service Delivery
AIOps is a natural extension of the [[Cloud Service Delivery]] operational model, specifically supporting:
- [[Performance & Availability Monitoring]]
- [[Incident Management]]
- [[Problem Management]]
- [[Change Management]]
## Related Concepts
- [[Cloud Service Delivery]]
- [[Cloud DevOps Maturity Model]]
- [[Observability]]
- [[Incident Management]]
## Related Sources
- [[what-i-know-about-cloud-service-delivery-1]]
## AIOps Capabilities
```python
# Typical AIOps capabilities
aiops_capabilities = [
"Anomaly Detection", # Identify unusual patterns
"Root Cause Analysis", # Automatic diagnosis
"Predictive Maintenance", # Forecast failures
"Smart Alerting", # Reduce alert fatigue
"Automated Remediation", # Self-healing systems
"Capacity Optimization" # Resource optimization
]
```
---
title: AIOps
tags:
- ai
- devops
- it-operations
created: 2026-04-22
---
# AIOps
## Definition
AIOps (Artificial Intelligence for IT Operations) is the application of artificial intelligence and machine learning to IT operations. It automates the detection, diagnosis, and resolution of operational issues in cloud environments.
## Purpose
AIOps enables:
- **Proactive issue detection** — Identifying problems before they impact users
- **Intelligent alerting** — Reducing noise and focusing on actionable alerts
- **Automated root cause analysis** — Accelerating incident resolution
- **Predictive analytics** — Forecasting capacity needs and potential failures
## Relationship with Cloud Service Delivery
AIOps is a natural extension of the [[Cloud Service Delivery]] operational model, specifically supporting:
- [[Performance & Availability Monitoring]]
- [[Incident Management]]
- [[Problem Management]]
- [[Change Management]]
## Related Concepts
- [[Cloud Service Delivery]]
- [[Cloud DevOps Maturity Model]]
- [[Observability]]
- [[Incident Management]]
## Related Sources
- [[what-i-know-about-cloud-service-delivery-1]]
## AIOps Capabilities
```python
# Typical AIOps capabilities
aiops_capabilities = [
"Anomaly Detection", # Identify unusual patterns
"Root Cause Analysis", # Automatic diagnosis
"Predictive Maintenance", # Forecast failures
"Smart Alerting", # Reduce alert fatigue
"Automated Remediation", # Self-healing systems
"Capacity Optimization" # Resource optimization
]
```

90
wiki/concepts/AI代理.md
View File

@@ -1,45 +1,45 @@
---
title: "AI代理"
type: concept
tags: [ai, agent, automation]
last_updated: 2026-04-22
---
## Overview
AI代理（AI Agent）是基于AI模型的自动化任务助手，可以按模式生成代码、规划任务或回答疑问。AI代理具备自主决策和任务执行能力，是Agentic AI系统的核心组件。
## Agent Modes
### Plan（规划模式）
- 让AI拆解步骤，形成清晰的开发路线图
- 适用于需求分析和任务分解
- 输出通常为Markdown格式的任务列表
### Agent（执行模式）
- AI代理执行计划任务，逐步生成代码
- 会直接修改文件
- 适用于完整的项目构建
### Ask（咨询模式）
- 仅返回文本答案，不改动代码
- 安全性最高，适合学习和探索
- 适用于问答和代码理解
## Key Characteristics
- **自主性**：能够独立完成复杂任务
- **多模态**：支持代码生成、文档撰写、任务规划
- **上下文感知**：理解项目整体结构和上下文
- **可扩展**：通过MCP等协议集成外部工具
## Applications
- [[Vibe Coding]]：通过AI代理实现自然语言编程
- [[Cursor]]：支持多代理并行操作
- [[Claude Code]]：命令行AI代理工具
## Related Concepts
- [[Agentic AI]] — 具有自主决策能力的AI系统
- [[MCP（Model Context Protocol）]] — AI代理的扩展协议
- [[Plan Mode]] — 规划模式
- [[Build Mode]] — 执行模式
## Sources
- [[cursor-2-0初学者使用指南]]
---
title: "AI代理"
type: concept
tags: [ai, agent, automation]
last_updated: 2026-04-22
---
## Overview
AI代理（AI Agent）是基于AI模型的自动化任务助手，可以按模式生成代码、规划任务或回答疑问。AI代理具备自主决策和任务执行能力，是Agentic AI系统的核心组件。
## Agent Modes
### Plan（规划模式）
- 让AI拆解步骤，形成清晰的开发路线图
- 适用于需求分析和任务分解
- 输出通常为Markdown格式的任务列表
### Agent（执行模式）
- AI代理执行计划任务，逐步生成代码
- 会直接修改文件
- 适用于完整的项目构建
### Ask（咨询模式）
- 仅返回文本答案，不改动代码
- 安全性最高，适合学习和探索
- 适用于问答和代码理解
## Key Characteristics
- **自主性**：能够独立完成复杂任务
- **多模态**：支持代码生成、文档撰写、任务规划
- **上下文感知**：理解项目整体结构和上下文
- **可扩展**：通过MCP等协议集成外部工具
## Applications
- [[Vibe Coding]]：通过AI代理实现自然语言编程
- [[Cursor]]：支持多代理并行操作
- [[Claude Code]]：命令行AI代理工具
## Related Concepts
- [[Agentic AI]] — 具有自主决策能力的AI系统
- [[MCP（Model Context Protocol）]] — AI代理的扩展协议
- [[Plan Mode]] — 规划模式
- [[Build Mode]] — 执行模式
## Sources
- [[cursor-2-0初学者使用指南]]

110
wiki/concepts/AI图生视频.md
View File

@@ -1,55 +1,55 @@
---
title: "AI图生视频"
type: concept
tags: [ai, video-generation, image-to-video]
---
## Definition
AI图生视频（Image-to-Video）是一种将静态图片通过人工智能模型自动转化为动态视频的技术。模型需要完成运动估计（从静态图像推断可能的运动方向）、时序生成（合成多帧连续画面）、内容填充（生成原图中未显示的视角和细节）三大核心任务。
## Aliases
- 图生视频
- Image to Video (I2V)
- Img2Vid
- AI Video Generation from Image
## Core Techniques
- **运动估计**：从单张静态图片推断场景中各元素的运动方向和速度
- **时序生成**：合成帧间连续性，确保视频流畅无闪烁
- **内容扩展**：根据图片上下文填充画面外延区域（如物体背面、背景延续）
- **主体一致性**：在多段视频中保持人物/物体的视觉特征（面部、衣着、颜色）高度一致
- **音频同步**：根据视频内容自动生成匹配的音效或背景音乐
## Control Methods
| 控制方式 | 描述 | 代表工具 |
|---------|------|---------|
| 文本提示词 | 通过自然语言描述控制运动和场景变化 | 智谱清影、通义万相、可灵AI |
| 动作模板 | 预定义的动作序列，用户直接选择 | 绘蛙AI视频 |
| 运镜参数 | 调整摄像机运动方式（推进/拉远/倾斜/轨道） | 即梦AI、Stable Video、Viva |
| 首尾帧 | 以首帧和尾帧图片约束视频首尾画面 | 即梦AI、PixVerse |
| 运动笔刷 | 手动选择图片中需要动态化的区域 | 艺映AI |
## Key Capabilities
- **生成时长**：2秒至6秒不等，取决于工具和付费等级
- **分辨率**：720p至1440p，免费工具通常为720p-1024p
- **生成速度**：30秒至数分钟
- **风格支持**：写实、动漫、3D动画、油画、赛博朋克、国风等
- **音效支持**：部分工具（智谱清影）支持AI自动生成匹配音效
## Applications
- **电商场景**：模特图动态化（换装展示、动作演示）、商品展示视频
- **内容创作**：创意短片、自媒体视频素材
- **广告制作**：营销视频、产品演示
- **社交媒体**：小红书、抖音、快手短视频素材
## Related Concepts
- [[AI文生视频]]：通过文本描述直接生成视频，与图生视频互补
- [[主体一致性]]：多段视频中保持人物视觉特征一致的技术
- [[运镜控制]]：摄像机运动参数对视频效果的影响
- [[首尾帧控制]]：以约束帧控制视频首尾画面的技术
## Key Entities
- [[智谱清影]]：支持音效自动生成的AI视频工具
- [[可灵AI]]：快手推出的1080p高质量图生视频工具
- [[即梦AI]]：首尾帧精准控制、多参数自定义
- [[Vidu]]：清华大学联合发布，主体一致性领先
---
title: "AI图生视频"
type: concept
tags: [ai, video-generation, image-to-video]
---
## Definition
AI图生视频（Image-to-Video）是一种将静态图片通过人工智能模型自动转化为动态视频的技术。模型需要完成运动估计（从静态图像推断可能的运动方向）、时序生成（合成多帧连续画面）、内容填充（生成原图中未显示的视角和细节）三大核心任务。
## Aliases
- 图生视频
- Image to Video (I2V)
- Img2Vid
- AI Video Generation from Image
## Core Techniques
- **运动估计**：从单张静态图片推断场景中各元素的运动方向和速度
- **时序生成**：合成帧间连续性，确保视频流畅无闪烁
- **内容扩展**：根据图片上下文填充画面外延区域（如物体背面、背景延续）
- **主体一致性**：在多段视频中保持人物/物体的视觉特征（面部、衣着、颜色）高度一致
- **音频同步**：根据视频内容自动生成匹配的音效或背景音乐
## Control Methods
| 控制方式 | 描述 | 代表工具 |
|---------|------|---------|
| 文本提示词 | 通过自然语言描述控制运动和场景变化 | 智谱清影、通义万相、可灵AI |
| 动作模板 | 预定义的动作序列，用户直接选择 | 绘蛙AI视频 |
| 运镜参数 | 调整摄像机运动方式（推进/拉远/倾斜/轨道） | 即梦AI、Stable Video、Viva |
| 首尾帧 | 以首帧和尾帧图片约束视频首尾画面 | 即梦AI、PixVerse |
| 运动笔刷 | 手动选择图片中需要动态化的区域 | 艺映AI |
## Key Capabilities
- **生成时长**：2秒至6秒不等，取决于工具和付费等级
- **分辨率**：720p至1440p，免费工具通常为720p-1024p
- **生成速度**：30秒至数分钟
- **风格支持**：写实、动漫、3D动画、油画、赛博朋克、国风等
- **音效支持**：部分工具（智谱清影）支持AI自动生成匹配音效
## Applications
- **电商场景**：模特图动态化（换装展示、动作演示）、商品展示视频
- **内容创作**：创意短片、自媒体视频素材
- **广告制作**：营销视频、产品演示
- **社交媒体**：小红书、抖音、快手短视频素材
## Related Concepts
- [[AI文生视频]]：通过文本描述直接生成视频，与图生视频互补
- [[主体一致性]]：多段视频中保持人物视觉特征一致的技术
- [[运镜控制]]：摄像机运动参数对视频效果的影响
- [[首尾帧控制]]：以约束帧控制视频首尾画面的技术
## Key Entities
- [[智谱清影]]：支持音效自动生成的AI视频工具
- [[可灵AI]]：快手推出的1080p高质量图生视频工具
- [[即梦AI]]：首尾帧精准控制、多参数自定义
- [[Vidu]]：清华大学联合发布，主体一致性领先

72
wiki/concepts/AI开源平替.md
View File

@@ -1,36 +1,36 @@
---
title: "AI开源平替"
type: concept
tags: [AI, 开源, 替代方案]
last_updated: 2026-04-24
---
## Definition
**AI开源平替**是指以 GitHub 等平台上的开源项目替代闭源商业 AI 产品，通过本地部署或自托管降低使用成本，同时实现数据隐私保护。
## Core Categories（来源：[[2025-年-11-个神级-ai-开源平替-github-杀疯了]]）
| 领域 | 闭源标杆 | 开源平替 | 代表项目 |
|------|---------|---------|---------|
| 大语言模型 | OpenAI GPT、Claude | DeepSeek、Qwen | DeepSeek R1/V3、Qwen 3 |
| AI 生图 | Midjourney V7 | Flux、Stable Diffusion | Flux（人体解剖最正确）、SD 3.5（LoRA 生态最丰富） |
| AI 生视频 | Google Veo 3 | HunyuanVideo | 腾讯混元视频，参数量最大 |
| AI 智能体 | Manus | OpenManus | 规划→执行→反馈 |
| AI 编码 | Cursor | Cline | VS Code 最强自主编程插件 |
| 工作流自动化 | Zapier | n8n、Dify | n8n（16 万 Star）、Dify（LLM 应用平台） |
| AI 搜索 | Perplexity | Perplexica | SearXNG+本地模型 |
| AI 知识库 | NotebookLM | OpenNotebook、SurfSense | 文档问答+播客生成 |
## Key Principles
- 开源平替 ≠ 100% 等价替代，需根据具体场景评估效果
- 本地部署可实现完全数据隐私，无需担心被大公司"炼丹"
- 开源社区迭代速度快，部分领域已实现弯道超车（如 DeepSeek R1 对标 o1）
## Related Concepts
- [[AI Agent]] — AI 智能体领域
- [[DeepSeek]] — 国产开源 LLM 代表
- [[n8n]] — 开源工作流自动化
- [[Perplexica]] — AI 搜索开源方案
## Sources
- [[2025-年-11-个神级-ai-开源平替-github-杀疯了]]
---
title: "AI开源平替"
type: concept
tags: [AI, 开源, 替代方案]
last_updated: 2026-04-24
---
## Definition
**AI开源平替**是指以 GitHub 等平台上的开源项目替代闭源商业 AI 产品，通过本地部署或自托管降低使用成本，同时实现数据隐私保护。
## Core Categories（来源：[[2025-年-11-个神级-ai-开源平替-github-杀疯了]]）
| 领域 | 闭源标杆 | 开源平替 | 代表项目 |
|------|---------|---------|---------|
| 大语言模型 | OpenAI GPT、Claude | DeepSeek、Qwen | DeepSeek R1/V3、Qwen 3 |
| AI 生图 | Midjourney V7 | Flux、Stable Diffusion | Flux（人体解剖最正确）、SD 3.5（LoRA 生态最丰富） |
| AI 生视频 | Google Veo 3 | HunyuanVideo | 腾讯混元视频，参数量最大 |
| AI 智能体 | Manus | OpenManus | 规划→执行→反馈 |
| AI 编码 | Cursor | Cline | VS Code 最强自主编程插件 |
| 工作流自动化 | Zapier | n8n、Dify | n8n（16 万 Star）、Dify（LLM 应用平台） |
| AI 搜索 | Perplexity | Perplexica | SearXNG+本地模型 |
| AI 知识库 | NotebookLM | OpenNotebook、SurfSense | 文档问答+播客生成 |
## Key Principles
- 开源平替 ≠ 100% 等价替代，需根据具体场景评估效果
- 本地部署可实现完全数据隐私，无需担心被大公司"炼丹"
- 开源社区迭代速度快，部分领域已实现弯道超车（如 DeepSeek R1 对标 o1）
## Related Concepts
- [[AI Agent]] — AI 智能体领域
- [[DeepSeek]] — 国产开源 LLM 代表
- [[n8n]] — 开源工作流自动化
- [[Perplexica]] — AI 搜索开源方案
## Sources
- [[2025-年-11-个神级-ai-开源平替-github-杀疯了]]

72
wiki/concepts/AI文生视频.md
View File

@@ -1,36 +1,36 @@
---
title: "AI文生视频"
type: concept
tags: [ai, video-generation, text-to-video]
---
## Definition
AI文生视频（Text-to-Video）是一种通过文本描述直接生成视频内容的人工智能技术。用户输入自然语言提示词，模型自动生成包含场景、角色、动作的动态视频。与 [[AI图生视频]] 互补：文生视频从零开始创作，图生视频则在静态图片基础上添加动态效果。
## Aliases
- 文生视频
- Text to Video (T2V)
- TXT2VID
- AI Video Generation from Text
## Core Techniques
- **文本编码**：将自然语言提示词编码为语义向量
- **图像生成**：基于文本语义生成视频首帧或关键帧
- **时序扩散**：通过扩散模型逐步生成帧间连续画面
- **运动建模**：根据文本描述生成合理的物理运动
- **视频解码**：将生成的隐表示解码为最终视频帧序列
## Key Capabilities
- 纯文本驱动，无需准备素材图片
- 支持复杂场景描述和角色交互
- 风格可控（写实、动漫、3D等）
- 生成时长通常2-6秒
## Applications
- 概念演示视频
- 营销视频自动生成
- 创意内容快速原型
## Related Concepts
- [[AI图生视频]]：在静态图片基础上添加动态效果，与本文生视频互补
- [[运镜控制]]：摄像机运动参数对视频效果的影响
---
title: "AI文生视频"
type: concept
tags: [ai, video-generation, text-to-video]
---
## Definition
AI文生视频（Text-to-Video）是一种通过文本描述直接生成视频内容的人工智能技术。用户输入自然语言提示词，模型自动生成包含场景、角色、动作的动态视频。与 [[AI图生视频]] 互补：文生视频从零开始创作，图生视频则在静态图片基础上添加动态效果。
## Aliases
- 文生视频
- Text to Video (T2V)
- TXT2VID
- AI Video Generation from Text
## Core Techniques
- **文本编码**：将自然语言提示词编码为语义向量
- **图像生成**：基于文本语义生成视频首帧或关键帧
- **时序扩散**：通过扩散模型逐步生成帧间连续画面
- **运动建模**：根据文本描述生成合理的物理运动
- **视频解码**：将生成的隐表示解码为最终视频帧序列
## Key Capabilities
- 纯文本驱动，无需准备素材图片
- 支持复杂场景描述和角色交互
- 风格可控（写实、动漫、3D等）
- 生成时长通常2-6秒
## Applications
- 概念演示视频
- 营销视频自动生成
- 创意内容快速原型
## Related Concepts
- [[AI图生视频]]：在静态图片基础上添加动态效果，与本文生视频互补
- [[运镜控制]]：摄像机运动参数对视频效果的影响

58
wiki/concepts/AI簡報工作流.md
View File

@@ -1,29 +1,29 @@
---
title: "AI簡報工作流"
type: concept
tags: [AI, 簡報, 自動化, 工作流]
sources: [教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報]
last_updated: 2026-04-23
---
## Definition
两阶段演示文稿制作工作流——先用大语言模型（如 ChatGPT）做知识整理和信息结构化，再交由 AI 设计工具（如 Canva / Gamma AI）输出演示文稿。
## Core Principle
让 AI 扮演不同角色，充分发挥各自优势：
- **第一阶段（思考者）**：LLM 负责深度理解、总结、重组信息，将分散资料转化为清晰、有逻辑的内容框架
- **第二阶段（设计师）**：AI 设计工具负责视觉呈现与排版，将结构化内容转化为精美演示文稿
## Why This Works
- 直接让 AI 生成简报往往内容逻辑不清、堆砌信息
- 先整理后设计的工作流确保：内容有深度，呈现有美感
- 符合"专注做擅长的事"原则——让工具各司其职
## Related Concepts
- [[知識結構化]]：将非结构化信息转化为清晰框架的能力
- [[AI設計工具]]：Canva、Gamma AI 等自动将内容转化为视觉呈现的工具
- [[YouTube-Content-Pipeline]]：共享"AI 整理 → AI 输出"两阶段模式
## Aliases
- AI简报自动化工作流
- 智能简报工作流
---
title: "AI簡報工作流"
type: concept
tags: [AI, 簡報, 自動化, 工作流]
sources: [教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報]
last_updated: 2026-04-23
---
## Definition
两阶段演示文稿制作工作流——先用大语言模型（如 ChatGPT）做知识整理和信息结构化，再交由 AI 设计工具（如 Canva / Gamma AI）输出演示文稿。
## Core Principle
让 AI 扮演不同角色，充分发挥各自优势：
- **第一阶段（思考者）**：LLM 负责深度理解、总结、重组信息，将分散资料转化为清晰、有逻辑的内容框架
- **第二阶段（设计师）**：AI 设计工具负责视觉呈现与排版，将结构化内容转化为精美演示文稿
## Why This Works
- 直接让 AI 生成简报往往内容逻辑不清、堆砌信息
- 先整理后设计的工作流确保：内容有深度，呈现有美感
- 符合"专注做擅长的事"原则——让工具各司其职
## Related Concepts
- [[知識結構化]]：将非结构化信息转化为清晰框架的能力
- [[AI設計工具]]：Canva、Gamma AI 等自动将内容转化为视觉呈现的工具
- [[YouTube-Content-Pipeline]]：共享"AI 整理 → AI 输出"两阶段模式
## Aliases
- AI简报自动化工作流
- 智能简报工作流

88
wiki/concepts/APT-仓库配置.md
View File

@@ -1,44 +1,44 @@
---
title: "APT 仓库配置"
tags: [apt, ubuntu, repository]
date: 2026-04-22
---
# APT 仓库配置
## Definition
APT (Advanced Package Tool) 仓库是 Ubuntu/Debian 系统的软件包来源，通过配置文件指定软件包的下载位置和签名验证方式。
## Docker 官方仓库配置流程
1. 安装 HTTPS 传输依赖：`sudo apt-get install ca-certificates curl`
2. 创建密钥目录：`sudo install -m 0755 -d /etc/apt/keyrings`
3. 下载并导入 GPG 密钥
4. 添加仓库源文件到 `/etc/apt/sources.list.d/`
## 配置文件位置
| 路径 | 作用 |
|------|------|
| `/etc/apt/sources.list` | 系统主仓库配置 |
| `/etc/apt/sources.list.d/*.list` | 第三方仓库配置 |
| `/etc/apt/keyrings/` | GPG 密钥存储目录 |
## Docker 仓库源文件示例
```bash
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
```
## Key Concepts
- **架构变量** `$(dpkg --print-architecture)`：自动适配 amd64/arm64 等架构
- **版本代号** `$VERSION_CODENAME`：Ubuntu 版本代号（如 jammy、noble）
- **签名验证** `signed-by`：指定 GPG 密钥路径
## Related Sources
- [[如何在ubuntu-server安装-docker-docker-compose]] — Docker APT 仓库完整配置流程
## Related Concepts
- [[GPG 密钥验证]] — apt 包签名验证机制
- [[Docker Engine]] — 通过 APT 仓库安装
- [[Ubuntu Server]] — APT 包管理器的宿主系统
---
title: "APT 仓库配置"
tags: [apt, ubuntu, repository]
date: 2026-04-22
---
# APT 仓库配置
## Definition
APT (Advanced Package Tool) 仓库是 Ubuntu/Debian 系统的软件包来源，通过配置文件指定软件包的下载位置和签名验证方式。
## Docker 官方仓库配置流程
1. 安装 HTTPS 传输依赖：`sudo apt-get install ca-certificates curl`
2. 创建密钥目录：`sudo install -m 0755 -d /etc/apt/keyrings`
3. 下载并导入 GPG 密钥
4. 添加仓库源文件到 `/etc/apt/sources.list.d/`
## 配置文件位置
| 路径 | 作用 |
|------|------|
| `/etc/apt/sources.list` | 系统主仓库配置 |
| `/etc/apt/sources.list.d/*.list` | 第三方仓库配置 |
| `/etc/apt/keyrings/` | GPG 密钥存储目录 |
## Docker 仓库源文件示例
```bash
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
```
## Key Concepts
- **架构变量** `$(dpkg --print-architecture)`：自动适配 amd64/arm64 等架构
- **版本代号** `$VERSION_CODENAME`：Ubuntu 版本代号（如 jammy、noble）
- **签名验证** `signed-by`：指定 GPG 密钥路径
## Related Sources
- [[如何在ubuntu-server安装-docker-docker-compose]] — Docker APT 仓库完整配置流程
## Related Concepts
- [[GPG 密钥验证]] — apt 包签名验证机制
- [[Docker Engine]] — 通过 APT 仓库安装
- [[Ubuntu Server]] — APT 包管理器的宿主系统

78
wiki/concepts/AWS-Secrets-Manager.md
View File

@@ -1,39 +1,39 @@
---
title: "AWS Secrets Manager"
type: concept
tags:
- AWS
- Secrets-Management
- Security
last_updated: 2026-04-14
---
## Definition
AWS Secrets Manager 是 AWS 提供的完全托管式密钥管理服务，用于安全存储和检索应用程序、服务和 IT 资源的密钥。
## Core Features
- **内置数据库集成**：开箱即用支持 AWS RDS、Redshift、DynamoDB 等服务的密钥管理
- **高可用与 DR**：托管服务自动实现跨可用区高可用和灾难恢复
- **按用量计费**：基于 API 调用次数计费，无需预付成本
- **自动密钥轮换**：通过 Lambda 函数实现数据库凭证自动轮换
- **IAM 访问控制**：通过 IAM 角色和标签实现精细化权限管理
- **账户级管理**：AWS 在账户级别管理密钥，可降低成本并提升安全性
## Evaluation vs HashiCorp Vault
| 维度 | AWS Secrets Manager | HashiCorp Vault |
|------|---------------------|-----------------|
| 部署模式 | 完全托管 | 自托管 |
| 云厂商 | AWS 原生 | 云厂商无关 |
| 成本模型 | 按用量计费 | 按用户数收费 |
| 高可用 | 内置 | 企业版才支持 |
| 动态密钥 | 支持 | 支持 |
| 证书签名 | 不支持原生 | 支持嵌入式签名 |
| 实施复杂度 | 简单易用 | 需要专业知识 |
## Implementation Phases
1. **试点阶段（30天）**：验证开箱即用功能，识别缺失功能（SSH 密钥轮换、用户密码轮换）
2. **实施阶段**：从 Control Tower 开始，从 CI/CD 流程中清除明文密码和密钥，集中化管理
## Sources
- [[ctp-topic-37-secrets-certificates-management]]（选型评估）
- [[ctp-topic-62-aws-secrets-manager]]（企业级深度实践）
---
title: "AWS Secrets Manager"
type: concept
tags:
- AWS
- Secrets-Management
- Security
last_updated: 2026-04-14
---
## Definition
AWS Secrets Manager 是 AWS 提供的完全托管式密钥管理服务，用于安全存储和检索应用程序、服务和 IT 资源的密钥。
## Core Features
- **内置数据库集成**：开箱即用支持 AWS RDS、Redshift、DynamoDB 等服务的密钥管理
- **高可用与 DR**：托管服务自动实现跨可用区高可用和灾难恢复
- **按用量计费**：基于 API 调用次数计费，无需预付成本
- **自动密钥轮换**：通过 Lambda 函数实现数据库凭证自动轮换
- **IAM 访问控制**：通过 IAM 角色和标签实现精细化权限管理
- **账户级管理**：AWS 在账户级别管理密钥，可降低成本并提升安全性
## Evaluation vs HashiCorp Vault
| 维度 | AWS Secrets Manager | HashiCorp Vault |
|------|---------------------|-----------------|
| 部署模式 | 完全托管 | 自托管 |
| 云厂商 | AWS 原生 | 云厂商无关 |
| 成本模型 | 按用量计费 | 按用户数收费 |
| 高可用 | 内置 | 企业版才支持 |
| 动态密钥 | 支持 | 支持 |
| 证书签名 | 不支持原生 | 支持嵌入式签名 |
| 实施复杂度 | 简单易用 | 需要专业知识 |
## Implementation Phases
1. **试点阶段（30天）**：验证开箱即用功能，识别缺失功能（SSH 密钥轮换、用户密码轮换）
2. **实施阶段**：从 Control Tower 开始，从 CI/CD 流程中清除明文密码和密钥，集中化管理
## Sources
- [[ctp-topic-37-secrets-certificates-management]]（选型评估）
- [[ctp-topic-62-aws-secrets-manager]]（企业级深度实践）

132
wiki/concepts/AWS-Source-Identity.md
View File

@@ -1,66 +1,66 @@
---
title: "AWS Source Identity"
type: concept
tags: [AWS, Security, IAM, Auditing, FinOps]
created: 2026-04-26
updated: 2026-04-26
sources: [Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md]
last_updated: 2026-04-26
---
# AWS Source Identity
> **Source Identity** 是 AWS STS（Security Token Service）的一个属性，通过 `sts:SourceIdentity` 在用户假设 IAM 角色时保留原始登录身份，使 CloudTrail 能够追踪联邦登录（Federated Login）跨角色切换的完整用户链。
## 定义
在 AWS 联邦身份认证场景中，用户通过身份提供商（IdP，如 NetIQ Access Manager）认证后，会假设多个 IAM 角色在不同账户间跳转。**默认情况下，CloudTrail 只记录假设角色后的角色身份，无法追溯到原始登录用户。**
Source Identity 通过在 `AssumeRole` 请求中携带 `SourceIdentity` 参数，解决了这一问题：
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/MyRole \
--source-identity alice@example.com
```
## 核心价值
| 维度 | 无 Source Identity | 有 Source Identity |
|------|-------------------|-------------------|
| 审计追踪 | 只能看到角色身份 | 可见原始用户身份 |
| FinOps 场景 | 无法关联账户支出到具体用户 | 可将成本责任追溯到个人 |
| 安全调查 | 难以定位跨角色操作的发起人 | 可完整还原操作路径 |
| 合规审计 | 不满足最小权限追溯要求 | 满足审计链要求 |
## 在 FinOps 中的应用
在 [[Budget-Control-Automation]] 场景中，SRE Core 团队通过 Source Identity 实现：
- **用户维度的成本归因**：通过 CloudTrail + Source Identity 将每个 AWS API 调用关联到具体个人
- **Top Users 报告**：利用 Cost Explorer 数据 + CloudTrail Source Identity 识别账户内日度支出最高的用户
- **成本责任到人**：账户 owner 可精确定位哪些团队成员产生了异常支出
## 与 AWS 服务的集成
- **CloudTrail**：Source Identity 字段记录在 CloudTrail 日志的 `userIdentity` 块中
- **STS (Security Token Service)**：`AssumeRole`、`AssumeRoleWithSAML`、`AssumeRoleWithWebIdentity` 均支持 Source Identity
- **Cost Explorer**：结合 Source Identity 数据可实现用户维度的成本分析
- **AWS Budgets**：告警流程中的 Lambda 函数可查询 CloudTrail Source Identity 数据进行用户归因
## 关键约束
- Source Identity 只能**设置**，不能**覆盖**：一旦设置为某个值，在当前会话期间无法更改
- Source Identity 有长度限制（最大 64 字符）
- 需要 IAM 角色显式授权 `sts:TagSession` 和 `sts:SourceIdentity` 权限才能使用
- NetIQ Access Manager 等联邦 IdP 需要配置为在假设角色请求中传递 Source Identity
## 相关概念
- [[CloudTrail]]：AWS 审计日志服务，Source Identity 使其具备跨角色用户追踪能力
- [[IAM-Roles]]：Source Identity 在角色假设场景中使用
- [[Federated-Identity]]：联邦身份管理（如 NetIQ），Source Identity 解决其跨角色追踪盲区
- [[FinOps]]：FinOps 审计和成本归因需要 Source Identity 提供用户级可见性
## 来源
本概念页基于 [[public-cloud-learning-sessions-budget-control-20240319]]（SRE Core 团队 Budget Control 自动化学习分享）中关于 Source Identity 实现细节的记录。
---
title: "AWS Source Identity"
type: concept
tags: [AWS, Security, IAM, Auditing, FinOps]
created: 2026-04-26
updated: 2026-04-26
sources: [Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md]
last_updated: 2026-04-26
---
# AWS Source Identity
> **Source Identity** 是 AWS STS（Security Token Service）的一个属性，通过 `sts:SourceIdentity` 在用户假设 IAM 角色时保留原始登录身份，使 CloudTrail 能够追踪联邦登录（Federated Login）跨角色切换的完整用户链。
## 定义
在 AWS 联邦身份认证场景中，用户通过身份提供商（IdP，如 NetIQ Access Manager）认证后，会假设多个 IAM 角色在不同账户间跳转。**默认情况下，CloudTrail 只记录假设角色后的角色身份，无法追溯到原始登录用户。**
Source Identity 通过在 `AssumeRole` 请求中携带 `SourceIdentity` 参数，解决了这一问题：
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/MyRole \
--source-identity alice@example.com
```
## 核心价值
| 维度 | 无 Source Identity | 有 Source Identity |
|------|-------------------|-------------------|
| 审计追踪 | 只能看到角色身份 | 可见原始用户身份 |
| FinOps 场景 | 无法关联账户支出到具体用户 | 可将成本责任追溯到个人 |
| 安全调查 | 难以定位跨角色操作的发起人 | 可完整还原操作路径 |
| 合规审计 | 不满足最小权限追溯要求 | 满足审计链要求 |
## 在 FinOps 中的应用
在 [[Budget-Control-Automation]] 场景中，SRE Core 团队通过 Source Identity 实现：
- **用户维度的成本归因**：通过 CloudTrail + Source Identity 将每个 AWS API 调用关联到具体个人
- **Top Users 报告**：利用 Cost Explorer 数据 + CloudTrail Source Identity 识别账户内日度支出最高的用户
- **成本责任到人**：账户 owner 可精确定位哪些团队成员产生了异常支出
## 与 AWS 服务的集成
- **CloudTrail**：Source Identity 字段记录在 CloudTrail 日志的 `userIdentity` 块中
- **STS (Security Token Service)**：`AssumeRole`、`AssumeRoleWithSAML`、`AssumeRoleWithWebIdentity` 均支持 Source Identity
- **Cost Explorer**：结合 Source Identity 数据可实现用户维度的成本分析
- **AWS Budgets**：告警流程中的 Lambda 函数可查询 CloudTrail Source Identity 数据进行用户归因
## 关键约束
- Source Identity 只能**设置**，不能**覆盖**：一旦设置为某个值，在当前会话期间无法更改
- Source Identity 有长度限制（最大 64 字符）
- 需要 IAM 角色显式授权 `sts:TagSession` 和 `sts:SourceIdentity` 权限才能使用
- NetIQ Access Manager 等联邦 IdP 需要配置为在假设角色请求中传递 Source Identity
## 相关概念
- [[CloudTrail]]：AWS 审计日志服务，Source Identity 使其具备跨角色用户追踪能力
- [[IAM-Roles]]：Source Identity 在角色假设场景中使用
- [[Federated-Identity]]：联邦身份管理（如 NetIQ），Source Identity 解决其跨角色追踪盲区
- [[FinOps]]：FinOps 审计和成本归因需要 Source Identity 提供用户级可见性
## 来源
本概念页基于 [[public-cloud-learning-sessions-budget-control-20240319]]（SRE Core 团队 Budget Control 自动化学习分享）中关于 Source Identity 实现细节的记录。

132
wiki/concepts/AWS-Tagging-Standards.md
View File

@@ -1,66 +1,66 @@
---
title: "AWS Tagging Standards"
type: concept
tags: [AWS, Tagging, Governance, Compliance, Policy]
last_updated: 2026-04-14
---
## Definition
AWS Tagging Standards（AWS 标签规范）是企业级 AWS Landing Zone 治理框架的核心组成部分，定义了 AWS 资源上必须使用的标准标签键（Mandatory Tags）、命名约定（Naming Conventions）和允许值列表（Allowed Values）。标签规范是企业云治理的第一道防线，直接影响网络安全策略、成本分配和资源管理效率。
## Aliases
- Tagging Policy
- Tag Standard
- AWS Tagging Policy
- Tag Governance
## Core Components
### 1. Mandatory Tags（强制标签）
组织定义的必须存在于所有 AWS 资源上的标签键，例如：
- `Environment`: `dev | staging | prod`
- `CostCenter`: 成本中心代码
- `Owner`: 资源负责人
- `Application`: 应用名称
- `Project`: 项目名称
### 2. Naming Conventions（命名约定）
资源命名的标准化规则，例如：
- `prod-web-server-001`
- `dev-db-postgres-01`
### 3. Allowed Values（允许值列表）
每个标签键对应的允许值集合，例如：
```yaml
Environment:
- dev
- staging
- prod
- uat
CostCenter:
- CC-001
- CC-002
```
## Context in This Wiki
在该组织的 AWS Landing Zone 环境中，标签规范具有双重关键性：
1. **Checkpoint 防火墙安全策略**：Checkpoint 防火墙读取 EC2、安全组和负载均衡器的标签值来配置网络访问策略，标签缺失或无效将直接导致流量被拦截。
2. **服务控制策略（SCPs）**：AWS Organizations 的 SCPs 基于标签规范阻止不合规资源的新建，但仅能阻止新资源，无法处理存量不合规资源。
3. **标签验证工具（Tag Validation Tool）**：SRE 团队开发的 Python/Boto3 工具，通过 `variables.yaml` 配置文件扫描所有现有资源并与规范比对，生成 CSV 审计报告。
4. **未来成本核算**：标签计划用于区分同一账户下不同产品的资源消耗，支持 FinOps 成本分摊。
## Related Concepts
- [[AWS-Tags]]：AWS 资源标签的基础定义
- [[Tag-Validation-Tool]]：基于标签规范的自动化审计工具
- [[Service-Control-Policies-SCPs]]：基于标签规范的上游强制机制
- [[Variables-YAML]]：标签验证工具的核心配置文件
- [[FinOps]]：利用标签实现成本分摊
## Sources
- [[ctp-topic-28-aws-tag-validation-tool]]
- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]
---
title: "AWS Tagging Standards"
type: concept
tags: [AWS, Tagging, Governance, Compliance, Policy]
last_updated: 2026-04-14
---
## Definition
AWS Tagging Standards（AWS 标签规范）是企业级 AWS Landing Zone 治理框架的核心组成部分，定义了 AWS 资源上必须使用的标准标签键（Mandatory Tags）、命名约定（Naming Conventions）和允许值列表（Allowed Values）。标签规范是企业云治理的第一道防线，直接影响网络安全策略、成本分配和资源管理效率。
## Aliases
- Tagging Policy
- Tag Standard
- AWS Tagging Policy
- Tag Governance
## Core Components
### 1. Mandatory Tags（强制标签）
组织定义的必须存在于所有 AWS 资源上的标签键，例如：
- `Environment`: `dev | staging | prod`
- `CostCenter`: 成本中心代码
- `Owner`: 资源负责人
- `Application`: 应用名称
- `Project`: 项目名称
### 2. Naming Conventions（命名约定）
资源命名的标准化规则，例如：
- `prod-web-server-001`
- `dev-db-postgres-01`
### 3. Allowed Values（允许值列表）
每个标签键对应的允许值集合，例如：
```yaml
Environment:
- dev
- staging
- prod
- uat
CostCenter:
- CC-001
- CC-002
```
## Context in This Wiki
在该组织的 AWS Landing Zone 环境中，标签规范具有双重关键性：
1. **Checkpoint 防火墙安全策略**：Checkpoint 防火墙读取 EC2、安全组和负载均衡器的标签值来配置网络访问策略，标签缺失或无效将直接导致流量被拦截。
2. **服务控制策略（SCPs）**：AWS Organizations 的 SCPs 基于标签规范阻止不合规资源的新建，但仅能阻止新资源，无法处理存量不合规资源。
3. **标签验证工具（Tag Validation Tool）**：SRE 团队开发的 Python/Boto3 工具，通过 `variables.yaml` 配置文件扫描所有现有资源并与规范比对，生成 CSV 审计报告。
4. **未来成本核算**：标签计划用于区分同一账户下不同产品的资源消耗，支持 FinOps 成本分摊。
## Related Concepts
- [[AWS-Tags]]：AWS 资源标签的基础定义
- [[Tag-Validation-Tool]]：基于标签规范的自动化审计工具
- [[Service-Control-Policies-SCPs]]：基于标签规范的上游强制机制
- [[Variables-YAML]]：标签验证工具的核心配置文件
- [[FinOps]]：利用标签实现成本分摊
## Sources
- [[ctp-topic-28-aws-tag-validation-tool]]
- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]

88
wiki/concepts/AWS-Tags.md
View File

@@ -1,44 +1,44 @@
---
title: "AWS Tags"
type: concept
tags: [AWS, Tagging, Metadata, Cloud-Governance]
last_updated: 2026-04-14
---
## Definition
AWS Tags（AWS 资源标签）是附加在 AWS 资源上的键值对（Key-Value Pair）元数据，用于识别、分类和管理云资源。在企业 AWS Landing Zone 环境中，标签不仅是资源管理的工具，更是安全策略（Checkpoint 防火墙网络访问控制）和成本核算的基础。
## Aliases
- Resource Tags
- AWS Resource Tags
- 标签策略（Tagging Policy）
## Core Attributes
| 属性 | 说明 |
|------|------|
| 格式 | `Key: Value`（键值对） |
| 作用对象 | EC2, Security Groups, Load Balancers, Lambda, RDS 等 |
| 常见标签键 | `Name`, `Environment`, `CostCenter`, `Owner`, `Application`, `Project` |
| 适用层面 | 网络安全、成本核算、资源分组、访问控制 |
## Context in This Wiki
AWS Tags 在该组织中扮演双重关键角色：
1. **网络安全**：Checkpoint 防火墙通过读取 EC2、安全组和负载均衡器的标签值动态配置网络访问策略；标签缺失或无效时，防火墙将拦截相关流量。
2. **成本核算**：标签用于按产品/部门/环境区分同一账户下不同资源的成本消耗。
## Related Concepts
- [[AWS-Tagging-Standards]]：AWS 标签规范，包括强制标签键、命名约定
- [[Tag-Validation-Tool]]：用于审计 AWS 资源标签合规性的自动化工具
- [[Service-Control-Policies-SCPs]]：AWS Organizations 策略，用于强制执行标签规范
- [[FinOps]]：云财务管理，标签是成本分摊的基础
- [[Checkpoint-Firewall]]：依赖标签值配置网络策略
## Sources
- [[ctp-topic-28-aws-tag-validation-tool]]
- [[ctp-topic-10-aws-tagging-deep-dive]]
---
title: "AWS Tags"
type: concept
tags: [AWS, Tagging, Metadata, Cloud-Governance]
last_updated: 2026-04-14
---
## Definition
AWS Tags（AWS 资源标签）是附加在 AWS 资源上的键值对（Key-Value Pair）元数据，用于识别、分类和管理云资源。在企业 AWS Landing Zone 环境中，标签不仅是资源管理的工具，更是安全策略（Checkpoint 防火墙网络访问控制）和成本核算的基础。
## Aliases
- Resource Tags
- AWS Resource Tags
- 标签策略（Tagging Policy）
## Core Attributes
| 属性 | 说明 |
|------|------|
| 格式 | `Key: Value`（键值对） |
| 作用对象 | EC2, Security Groups, Load Balancers, Lambda, RDS 等 |
| 常见标签键 | `Name`, `Environment`, `CostCenter`, `Owner`, `Application`, `Project` |
| 适用层面 | 网络安全、成本核算、资源分组、访问控制 |
## Context in This Wiki
AWS Tags 在该组织中扮演双重关键角色：
1. **网络安全**：Checkpoint 防火墙通过读取 EC2、安全组和负载均衡器的标签值动态配置网络访问策略；标签缺失或无效时，防火墙将拦截相关流量。
2. **成本核算**：标签用于按产品/部门/环境区分同一账户下不同资源的成本消耗。
## Related Concepts
- [[AWS-Tagging-Standards]]：AWS 标签规范，包括强制标签键、命名约定
- [[Tag-Validation-Tool]]：用于审计 AWS 资源标签合规性的自动化工具
- [[Service-Control-Policies-SCPs]]：AWS Organizations 策略，用于强制执行标签规范
- [[FinOps]]：云财务管理，标签是成本分摊的基础
- [[Checkpoint-Firewall]]：依赖标签值配置网络策略
## Sources
- [[ctp-topic-28-aws-tag-validation-tool]]
- [[ctp-topic-10-aws-tagging-deep-dive]]

94
wiki/concepts/Account-Health-Score.md
View File

@@ -1,47 +1,47 @@
---
title: "Account Health Score"
type: concept
tags: []
last_updated: 2026-04-25
---
## Definition
Account Health Score（账户健康评分）是对单个客户账户综合健康状况的量化评估，用于指导客户成功团队的投资优先级和干预策略。
## Score Components
| Component | What It Measures | Risk Threshold |
|-----------|-----------------|----------------|
| Product Usage | MAU、特征采纳率、容量使用率 | 核心特征采纳 <50% |
| Support Ticket Sentiment | CSAT、升级频率、解决时间 | CSAT <3.5 |
| Stakeholder Engagement | 利益相关者活跃度、会议参与度 | 单线程、高管断联 >60天 |
| Contract Timeline | 续约时间线、合同条款 | <90天续约窗口 |
| Executive Sponsor Activity | 高管发起人接触频率 | >60天无接触 |
| Champion Status | Champion 健康度和稳定性 | Champion 离职/职位变动 |
## Health Bands & Playbooks
| Score Band | Interpretation | Recommended Play |
|-----------|----------------|-----------------|
| 🟢 Green | 健康账户 | 扩张机会识别、执行 Land-and-Expand |
| 🟡 Yellow | 需要关注 | 稳定化计划、加强参与度 |
| 🔴 Red | 高风险 | 救流失计划、Executive Escalation |
**永远不在红色账户上执行扩张策略。**
## Early Warning Signals
领先指标（提前 90 天预警）：
- 月活跃用户数下降
- 核心特征采纳率下降
- 高管发起人接触中断 >60 天
- Champion 职位变动或离职
- 支持工单升级频率上升
- 竞争对手开始在账户中活跃
## Connection
- [[Net Revenue Retention (NRR)]] — Account Health Score 是 NRR 的分解指标
- [[Land-and-Expand]] — 健康评分决定何时推扩张
- [[Churn Prevention Playbook]] — 红色账户触发救流失流程
- [[sales-account-strategist]] — Account Strategist 维护账户健康评分
---
title: "Account Health Score"
type: concept
tags: []
last_updated: 2026-04-25
---
## Definition
Account Health Score（账户健康评分）是对单个客户账户综合健康状况的量化评估，用于指导客户成功团队的投资优先级和干预策略。
## Score Components
| Component | What It Measures | Risk Threshold |
|-----------|-----------------|----------------|
| Product Usage | MAU、特征采纳率、容量使用率 | 核心特征采纳 <50% |
| Support Ticket Sentiment | CSAT、升级频率、解决时间 | CSAT <3.5 |
| Stakeholder Engagement | 利益相关者活跃度、会议参与度 | 单线程、高管断联 >60天 |
| Contract Timeline | 续约时间线、合同条款 | <90天续约窗口 |
| Executive Sponsor Activity | 高管发起人接触频率 | >60天无接触 |
| Champion Status | Champion 健康度和稳定性 | Champion 离职/职位变动 |
## Health Bands & Playbooks
| Score Band | Interpretation | Recommended Play |
|-----------|----------------|-----------------|
| 🟢 Green | 健康账户 | 扩张机会识别、执行 Land-and-Expand |
| 🟡 Yellow | 需要关注 | 稳定化计划、加强参与度 |
| 🔴 Red | 高风险 | 救流失计划、Executive Escalation |
**永远不在红色账户上执行扩张策略。**
## Early Warning Signals
领先指标（提前 90 天预警）：
- 月活跃用户数下降
- 核心特征采纳率下降
- 高管发起人接触中断 >60 天
- Champion 职位变动或离职
- 支持工单升级频率上升
- 竞争对手开始在账户中活跃
## Connection
- [[Net Revenue Retention (NRR)]] — Account Health Score 是 NRR 的分解指标
- [[Land-and-Expand]] — 健康评分决定何时推扩张
- [[Churn Prevention Playbook]] — 红色账户触发救流失流程
- [[sales-account-strategist]] — Account Strategist 维护账户健康评分

146
wiki/concepts/Account-Tiering-Model.md
View File

@@ -1,73 +1,73 @@
---
title: "Account Tiering Model"
type: concept
tags: [sales, outbound, account-based]
sources: [sales-outbound-strategist]
last_updated: 2026-04-25
---
## Definition
三层账户分级模型——根据 ICP 匹配度和战略价值将目标账户分为三个层级，每个层级采用不同的出站深度和个性化程度。
## Three Tiers
### Tier 1: Top 50-100 Accounts — Deep, Multi-Threaded, Highly Personalized
**目标**：最高价值账户的深度渗透
**策略**：
- 全账户研究：10-K/年报、财报电话会议、战略举措
- 多线程渗透：每账户 3-5 个联系人（经济决策者/Champion/影响者/终端用户/教练）
- 每个 persona 定制消息，引用账户特定举措
- 整合触达：直邮、热情引荐、活动触达
- 专属销售拥有权，每周账户策略审查
### Tier 2: Next 200-500 Accounts — Semi-Personalized Sequences
**目标**：规模化与个性化的平衡
**策略**：
- 行业特定消息 + 开场白账户级个性化
- 每账户 2-3 个联系人（主要买家 + 一位额外利益相关者）
- 信号触发的序列注册 + persona 匹配消息
- 季度重新评估：根据互动情况晋升 Tier 1 或降级 Tier 3
### Tier 3: Remaining ICP-fit — Automated with Light Personalization
**目标**：最大化 ICP 覆盖率
**策略**：
- 行业和角色级别序列 + 动态个性化 token
- 每账户单一主要联系人
- **仅信号触发注册**——无手动出站
- 自动互动评分以识别晋升账户
## Tiering Criteria
| Criteria | Tier 1 | Tier 2 | Tier 3 |
|----------|--------|--------|--------|
| ACV 预期 | 最高 | 中 | 低-中 |
| 战略契合度 | 完全匹配 | 高匹配 | 基本匹配 |
| 联系人数量 | 3-5 | 2-3 | 1 |
| 消息定制 | 完全定制 | 行业+账户 | 行业+角色 |
| 手动出站 | ✅ | ✅ | ❌ |
| 评估频率 | 每周 | 每月 | 每季度 |
## Tiering Dynamics
- Tier 1 和 Tier 2 是**手动管理**的
- Tier 3 账户通过**自动化**运营
- Tier 3 中互动达到阈值的账户自动**晋升**到 Tier 2
- Tier 2 中持续无互动的账户降级到 Tier 3
## Key Metric: Pipeline per Rep
Tier 1 账户需要更多销售时间，但产生更高 ACV。销售需要深度拥有 50-80 个账户（Tier 1 + Tier 2），而非浅层拥有 500 个账户。
## Connections
- [[sales-outbound-strategist]] — 账户分级模型来源
- [[ICP (Ideal Customer Profile)]] — 分级依据的匹配度判断
- [[Signal-Based Selling Framework]] — 账户触发的信号来源
- [[Multi-Channel Sequence Architecture]] — 不同层级对应不同序列深度
---
title: "Account Tiering Model"
type: concept
tags: [sales, outbound, account-based]
sources: [sales-outbound-strategist]
last_updated: 2026-04-25
---
## Definition
三层账户分级模型——根据 ICP 匹配度和战略价值将目标账户分为三个层级，每个层级采用不同的出站深度和个性化程度。
## Three Tiers
### Tier 1: Top 50-100 Accounts — Deep, Multi-Threaded, Highly Personalized
**目标**：最高价值账户的深度渗透
**策略**：
- 全账户研究：10-K/年报、财报电话会议、战略举措
- 多线程渗透：每账户 3-5 个联系人（经济决策者/Champion/影响者/终端用户/教练）
- 每个 persona 定制消息，引用账户特定举措
- 整合触达：直邮、热情引荐、活动触达
- 专属销售拥有权，每周账户策略审查
### Tier 2: Next 200-500 Accounts — Semi-Personalized Sequences
**目标**：规模化与个性化的平衡
**策略**：
- 行业特定消息 + 开场白账户级个性化
- 每账户 2-3 个联系人（主要买家 + 一位额外利益相关者）
- 信号触发的序列注册 + persona 匹配消息
- 季度重新评估：根据互动情况晋升 Tier 1 或降级 Tier 3
### Tier 3: Remaining ICP-fit — Automated with Light Personalization
**目标**：最大化 ICP 覆盖率
**策略**：
- 行业和角色级别序列 + 动态个性化 token
- 每账户单一主要联系人
- **仅信号触发注册**——无手动出站
- 自动互动评分以识别晋升账户
## Tiering Criteria
| Criteria | Tier 1 | Tier 2 | Tier 3 |
|----------|--------|--------|--------|
| ACV 预期 | 最高 | 中 | 低-中 |
| 战略契合度 | 完全匹配 | 高匹配 | 基本匹配 |
| 联系人数量 | 3-5 | 2-3 | 1 |
| 消息定制 | 完全定制 | 行业+账户 | 行业+角色 |
| 手动出站 | ✅ | ✅ | ❌ |
| 评估频率 | 每周 | 每月 | 每季度 |
## Tiering Dynamics
- Tier 1 和 Tier 2 是**手动管理**的
- Tier 3 账户通过**自动化**运营
- Tier 3 中互动达到阈值的账户自动**晋升**到 Tier 2
- Tier 2 中持续无互动的账户降级到 Tier 3
## Key Metric: Pipeline per Rep
Tier 1 账户需要更多销售时间，但产生更高 ACV。销售需要深度拥有 50-80 个账户（Tier 1 + Tier 2），而非浅层拥有 500 个账户。
## Connections
- [[sales-outbound-strategist]] — 账户分级模型来源
- [[ICP (Ideal Customer Profile)]] — 分级依据的匹配度判断
- [[Signal-Based Selling Framework]] — 账户触发的信号来源
- [[Multi-Channel Sequence Architecture]] — 不同层级对应不同序列深度

76
wiki/concepts/AccountArchitecture.md
View File

@@ -1,38 +1,38 @@
---
title: "Account Architecture"
type: concept
tags: ["paid-media", "google-ads", "strategy", "structure"]
last_updated: 2026-04-20
---
## Aliases
- Account Structure
- Campaign Architecture
- Google Ads Structure
## Overview
账户架构是 [[PaidMediaPpcStrategist]] 的核心理念：将整个广告账户视为一个系统，而非关键词和出价的简单集合。活动、广告组、受众、信号协同工作以驱动业务成果。
## Key Components
- **Campaign Structure**: 活动层级，定义预算、地理位置、受众、出价策略
- **Ad Group Taxonomy**: 广告组分类，结构化组织关键词和受众
- **Label Systems**: 标签系统，用于分类管理和自动化规则
- **Naming Conventions**: 命名规范，确保规模化运营的可读性和可维护性
## Best Practices (PPC Strategist)
- 活动之间应隔离预算和目标，避免内耗
- 广告组应保持主题一致性
- 广泛匹配关键词配合智能竞价是规模化增长的核心
- 负关键词架构防止无效流量侵蚀预算
- 账户层级与 MCC（多账户管理）策略配合
## Tiered Campaign Architecture
- **Brand**: 品牌词保护，高转化，低成本
- **Non-Brand**: 非品牌词，规模化增长的核心
- **Competitor**: 竞品词，主动触达竞品用户
- **Conquest**: 征服策略，针对高价值竞品用户
## Related Concepts
- [[TieredCampaignArchitecture]]: 分层活动架构的具体实现
- [[SmartBidding]]: 账户架构中出价策略的选择
- [[NegativeKeyword]]: 负关键词是账户架构的重要组成部分
---
title: "Account Architecture"
type: concept
tags: ["paid-media", "google-ads", "strategy", "structure"]
last_updated: 2026-04-20
---
## Aliases
- Account Structure
- Campaign Architecture
- Google Ads Structure
## Overview
账户架构是 [[PaidMediaPpcStrategist]] 的核心理念：将整个广告账户视为一个系统，而非关键词和出价的简单集合。活动、广告组、受众、信号协同工作以驱动业务成果。
## Key Components
- **Campaign Structure**: 活动层级，定义预算、地理位置、受众、出价策略
- **Ad Group Taxonomy**: 广告组分类，结构化组织关键词和受众
- **Label Systems**: 标签系统，用于分类管理和自动化规则
- **Naming Conventions**: 命名规范，确保规模化运营的可读性和可维护性
## Best Practices (PPC Strategist)
- 活动之间应隔离预算和目标，避免内耗
- 广告组应保持主题一致性
- 广泛匹配关键词配合智能竞价是规模化增长的核心
- 负关键词架构防止无效流量侵蚀预算
- 账户层级与 MCC（多账户管理）策略配合
## Tiered Campaign Architecture
- **Brand**: 品牌词保护，高转化，低成本
- **Non-Brand**: 非品牌词，规模化增长的核心
- **Competitor**: 竞品词，主动触达竞品用户
- **Conquest**: 征服策略，针对高价值竞品用户
## Related Concepts
- [[TieredCampaignArchitecture]]: 分层活动架构的具体实现
- [[SmartBidding]]: 账户架构中出价策略的选择
- [[NegativeKeyword]]: 负关键词是账户架构的重要组成部分

76
wiki/concepts/ActionItemTracking.md
View File

@@ -1,38 +1,38 @@
---
title: "ActionItemTracking"
type: concept
tags: []
last_updated: 2026-04-22
---
# ActionItemTracking
从非结构化文本（会议记录、邮件、聊天记录）中识别行动项并持续追踪其执行状态的方法论。核心要素包括：任务描述、负责人（Owner）、截止日（Deadline）、状态（Status）。
## Definition
ActionItemTracking 解决的核心问题：团队讨论中产生的行动项往往停留在口头或聊天记录中，缺乏系统化追踪机制导致遗忘和责任不清。该模式通过 AI 自动化实现：
- 从会议转录中提取所有行动项
- 识别每项任务的负责人（通过姓名匹配或说话人归属）
- 提取或推断截止日期（未提及则标记为 TBD）
- 自动在项目管理工具中创建任务
- 设置截止日前提醒机制
## Key Attributes
| 属性 | 说明 |
|------|------|
| Task | 需要完成的具体任务描述 |
| Owner | 负责人，通过发言人或@提及识别 |
| Deadline | 截止日，未提及则 TBD |
| Status | 状态：Pending / In Progress / Done |
| Source | 来源：会议转录、邮件、聊天等 |
## Implementation
- [[Todoist Task Manager]] — Todoist 中的通用行动项管理
- [[meeting-notes-action-items]] — 从会议转录自动提取行动项
## Related Concepts
- [[MeetingNotes]] — 行动项的主要来源场景
- [[TaskAutomation]] — 行动项的自动化创建
---
title: "ActionItemTracking"
type: concept
tags: []
last_updated: 2026-04-22
---
# ActionItemTracking
从非结构化文本（会议记录、邮件、聊天记录）中识别行动项并持续追踪其执行状态的方法论。核心要素包括：任务描述、负责人（Owner）、截止日（Deadline）、状态（Status）。
## Definition
ActionItemTracking 解决的核心问题：团队讨论中产生的行动项往往停留在口头或聊天记录中，缺乏系统化追踪机制导致遗忘和责任不清。该模式通过 AI 自动化实现：
- 从会议转录中提取所有行动项
- 识别每项任务的负责人（通过姓名匹配或说话人归属）
- 提取或推断截止日期（未提及则标记为 TBD）
- 自动在项目管理工具中创建任务
- 设置截止日前提醒机制
## Key Attributes
| 属性 | 说明 |
|------|------|
| Task | 需要完成的具体任务描述 |
| Owner | 负责人，通过发言人或@提及识别 |
| Deadline | 截止日，未提及则 TBD |
| Status | 状态：Pending / In Progress / Done |
| Source | 来源：会议转录、邮件、聊天等 |
## Implementation
- [[Todoist Task Manager]] — Todoist 中的通用行动项管理
- [[meeting-notes-action-items]] — 从会议转录自动提取行动项
## Related Concepts
- [[MeetingNotes]] — 行动项的主要来源场景
- [[TaskAutomation]] — 行动项的自动化创建

92
wiki/concepts/Active-Accountability.md
View File

@@ -1,46 +1,46 @@
---
title: "Active Accountability"
type: concept
tags: []
last_updated: 2026-04-17
---
## Definition
AI Agent **主动发消息询问用户**是否完成了某项任务/习惯，而非等待用户主动打开 App 记录——将行为追踪从被动记录转变为主动对话。
## Contrast with Passive Tracking
| 维度 | 被动追踪（Passive Tracking） | 主动问责（Active Accountability） |
|------|---------------------------|-------------------------------|
| 触发方式 | 用户主动打开 App | AI Agent 按定时计划主动发送消息 |
| 用户参与成本 | 需要主动记录 | 只需回复确认/否认 |
| 通知行为 | Push 通知容易被忽略 | 主动询问，回复率更高 |
| 典型产品 | Streaks、Habitica、Loop Habit | OpenClaw Habit Tracker |
| 放弃率 | 高（一周后通常停止） | 低（持续参与度高） |
## Why It Works
行为改变研究（Klein, 2011; Gollwitzer, 1999）表明：
- **承诺一致性**：当用户通过回复消息明确表态（"是的，我完成了"），心理承诺效应使他们更可能在未来坚持
- **即时反馈**：AI 即时确认和鼓励比事后查看 App 数据更有激励效果
- **社会存在感**：主动发消息的 AI 提供了"有人在监督"的真实感觉
## Implementation
依赖 [[OpenClaw]] 的 [[Scheduled Reminder]] 能力，配合 [[Adaptive Tone]] 调节消息语气：
1. Cron Job 按设定时间发送签到消息
2. 用户回复完成/未完成
3. AI 解析回复并更新 [[Streak Tracking]]
4. 根据当前连续状态调整语气（[[Adaptive Tone]]）
5. 每周日汇总 [[Weekly Pattern Analysis]]
## Related Concepts
- [[Adaptive Tone]] — Active Accountability 的关键差异化因素
- [[Streak Tracking]] — Active Accountability 的核心激励机制
- [[Scheduled Reminder]] — Active Accountability 的技术实现
- [[Morning Briefing]] — Active Accountability 的同模式应用
## Source
- [[habit-tracker-accountability-coach]]
---
title: "Active Accountability"
type: concept
tags: []
last_updated: 2026-04-17
---
## Definition
AI Agent **主动发消息询问用户**是否完成了某项任务/习惯，而非等待用户主动打开 App 记录——将行为追踪从被动记录转变为主动对话。
## Contrast with Passive Tracking
| 维度 | 被动追踪（Passive Tracking） | 主动问责（Active Accountability） |
|------|---------------------------|-------------------------------|
| 触发方式 | 用户主动打开 App | AI Agent 按定时计划主动发送消息 |
| 用户参与成本 | 需要主动记录 | 只需回复确认/否认 |
| 通知行为 | Push 通知容易被忽略 | 主动询问，回复率更高 |
| 典型产品 | Streaks、Habitica、Loop Habit | OpenClaw Habit Tracker |
| 放弃率 | 高（一周后通常停止） | 低（持续参与度高） |
## Why It Works
行为改变研究（Klein, 2011; Gollwitzer, 1999）表明：
- **承诺一致性**：当用户通过回复消息明确表态（"是的，我完成了"），心理承诺效应使他们更可能在未来坚持
- **即时反馈**：AI 即时确认和鼓励比事后查看 App 数据更有激励效果
- **社会存在感**：主动发消息的 AI 提供了"有人在监督"的真实感觉
## Implementation
依赖 [[OpenClaw]] 的 [[Scheduled Reminder]] 能力，配合 [[Adaptive Tone]] 调节消息语气：
1. Cron Job 按设定时间发送签到消息
2. 用户回复完成/未完成
3. AI 解析回复并更新 [[Streak Tracking]]
4. 根据当前连续状态调整语气（[[Adaptive Tone]]）
5. 每周日汇总 [[Weekly Pattern Analysis]]
## Related Concepts
- [[Adaptive Tone]] — Active Accountability 的关键差异化因素
- [[Streak Tracking]] — Active Accountability 的核心激励机制
- [[Scheduled Reminder]] — Active Accountability 的技术实现
- [[Morning Briefing]] — Active Accountability 的同模式应用
## Source
- [[habit-tracker-accountability-coach]]

210
wiki/concepts/AdExtensions.md
View File

@@ -1,105 +1,105 @@
---
title: "Ad Extensions"
type: concept
tags: ["google-ads", "ppc", "creative", "visibility"]
---
## Definition
Ad Extensions（广告附加信息）是 Google Ads 在基础文字广告基础上额外展示的扩展信息，通过增加广告视觉空间、提升实用性和点击率。
## Extension Types
### Sitelink Extensions
**用途**：链接到网站特定页面
**最佳实践**：
- 4-6 个 Sitelinks
- 每个有独立标题和描述
- 链接至对应落地页（Message Match）
- 配合促销文案（如"免费试用"）
**示例**：
| 标题 | 描述 |
|------|------|
| 查看价格 | 比较各版本方案和定价 |
| 免费试用 | 14天全功能免费体验 |
| 客户案例 | 查看500+企业成功案例 |
### Callout Extensions
**用途**：突出关键卖点/优势
**最佳实践**：
- 4-10 条 Callouts
- 每条约 25 字符
- 列举核心差异化优势
- 不含可点击 URL
**示例**：
| Callout |
|---------|
| 24/7 客户支持 |
| 免费部署协助 |
| 企业级安全认证 |
| 1分钟快速集成 |
### Structured Snippets
**用途**：展示产品/服务类别
**格式**：Header + Values
**最佳实践**：
- 选择与核心产品最相关的类别
- 4-10 个 Values
- 体现产品线宽度或服务多样性
**示例**：
| Header | Values |
|--------|--------|
| 服务类型 | SEO优化 · 内容营销 · 社媒运营 · 数据分析 |
### Image Extensions
**用途**：在广告中展示产品/品牌图片
**规格**：728×90, 320×150, 300×250
**最佳实践**：
- 高质量图片（避免文字过多）
- 品牌视觉一致性
- 补充而非重复文字信息
### Call Extensions
**用途**：让用户直接拨打联系电话
**最佳实践**：
- 本地号码更可信
- 配置呼叫追踪
- 配合移动端优先策略
### Promotion Extensions
**用途**：展示促销/折扣信息
**最佳实践**：
- 配合季节性活动
- 明确优惠幅度或条件
- 配合倒计时（季节性促销）
### Price Extensions
**用途**：直接展示价格信息
**最佳实践**：
- 价格有竞争力的产品适用
- 定期更新避免过时信息
- 配合 Message Match
## Impact Metrics
| 指标 | 基础广告 | 带 Extensions |
|------|---------|--------------|
| CTR | 基准 | +10-30% |
| 展示份额 | 基准 | +5-15% |
| 转化率 | 基准 | +5-15% |
## Strategy Principles
1. **完整性**：启用所有适用的 Extension 类型
2. **Message Match**：每个 Sitelink/Callout 对应独立落地页
3. **差异化**：各 Extension 传递不同信息，避免重复
4. **更新节奏**：每季度审查 Extensions 相关性和新鲜度
5. **移动优先**：确保 Call/Location Extension 移动端体验良好
## Sources
- [[paid-media-creative-strategist]]
- [[paid-media-ppc-strategist]]
---
title: "Ad Extensions"
type: concept
tags: ["google-ads", "ppc", "creative", "visibility"]
---
## Definition
Ad Extensions（广告附加信息）是 Google Ads 在基础文字广告基础上额外展示的扩展信息，通过增加广告视觉空间、提升实用性和点击率。
## Extension Types
### Sitelink Extensions
**用途**：链接到网站特定页面
**最佳实践**：
- 4-6 个 Sitelinks
- 每个有独立标题和描述
- 链接至对应落地页（Message Match）
- 配合促销文案（如"免费试用"）
**示例**：
| 标题 | 描述 |
|------|------|
| 查看价格 | 比较各版本方案和定价 |
| 免费试用 | 14天全功能免费体验 |
| 客户案例 | 查看500+企业成功案例 |
### Callout Extensions
**用途**：突出关键卖点/优势
**最佳实践**：
- 4-10 条 Callouts
- 每条约 25 字符
- 列举核心差异化优势
- 不含可点击 URL
**示例**：
| Callout |
|---------|
| 24/7 客户支持 |
| 免费部署协助 |
| 企业级安全认证 |
| 1分钟快速集成 |
### Structured Snippets
**用途**：展示产品/服务类别
**格式**：Header + Values
**最佳实践**：
- 选择与核心产品最相关的类别
- 4-10 个 Values
- 体现产品线宽度或服务多样性
**示例**：
| Header | Values |
|--------|--------|
| 服务类型 | SEO优化 · 内容营销 · 社媒运营 · 数据分析 |
### Image Extensions
**用途**：在广告中展示产品/品牌图片
**规格**：728×90, 320×150, 300×250
**最佳实践**：
- 高质量图片（避免文字过多）
- 品牌视觉一致性
- 补充而非重复文字信息
### Call Extensions
**用途**：让用户直接拨打联系电话
**最佳实践**：
- 本地号码更可信
- 配置呼叫追踪
- 配合移动端优先策略
### Promotion Extensions
**用途**：展示促销/折扣信息
**最佳实践**：
- 配合季节性活动
- 明确优惠幅度或条件
- 配合倒计时（季节性促销）
### Price Extensions
**用途**：直接展示价格信息
**最佳实践**：
- 价格有竞争力的产品适用
- 定期更新避免过时信息
- 配合 Message Match
## Impact Metrics
| 指标 | 基础广告 | 带 Extensions |
|------|---------|--------------|
| CTR | 基准 | +10-30% |
| 展示份额 | 基准 | +5-15% |
| 转化率 | 基准 | +5-15% |
## Strategy Principles
1. **完整性**：启用所有适用的 Extension 类型
2. **Message Match**：每个 Sitelink/Callout 对应独立落地页
3. **差异化**：各 Extension 传递不同信息，避免重复
4. **更新节奏**：每季度审查 Extensions 相关性和新鲜度
5. **移动优先**：确保 Call/Location Extension 移动端体验良好
## Sources
- [[paid-media-creative-strategist]]
- [[paid-media-ppc-strategist]]

108
wiki/concepts/AdStrength.md
View File

@@ -1,54 +1,54 @@
---
title: "Ad Strength"
type: concept
tags: ["google-ads", "meta-ads", "creative", "quality"]
---
## Definition
Ad Strength（广告强度）是 Google Ads 衡量广告创意质量和多样性的评分指标，直接影响广告效果和竞价竞争力。
## Google Ads Ad Strength
### Scoring Levels
| 评分 | 含义 | 目标 |
|------|------|------|
| Excellent | 创意丰富、多样、与关键词高度相关 | ✅ 终极目标 |
| Good | 创意质量良好，有一定多样性 | ✅ 基准线 |
| Average | 创意质量一般，多样性不足 | ⚠️ 需改进 |
| Poor | 创意严重不足 | ❌ 必须修复 |
### 影响因素
1. **数量（Quantity）**：标题/描述是否达到最大数量
2. **多样性（Diversity）**：各标题传递不同信息，避免重复
3. **相关性（Relevance）**：创意与关键词和广告组主题的匹配度
4. **历史效果（Past Performance）**：基于类似创意的历史 CTR 预测
### 优化路径
- 添加缺失类别的 headline（品牌/利益/功能/CTA/社会证明）
- 避免同义词重复
- 确保每个 headline 传递独特信息
- 使用关键词插入提升相关性
## Meta Relevance Diagnostics
Meta Ads 的相关度评分机制：
- **Very High**：创意与受众高度匹配
- **High**：匹配良好
- **Average**：匹配一般
- **Low**：匹配不足，需调整创意或受众
## Target Benchmarks
| 平台 | 指标 | 目标 |
|------|------|------|
| Google Ads | Ad Strength | 90%+ Excellent/Good |
| Google Ads | RSA headline count | 12-15 条 |
| Meta Ads | Relevance Diagnostics | Above Average/Top |
## Sources
- [[paid-media-creative-strategist]]
---
title: "Ad Strength"
type: concept
tags: ["google-ads", "meta-ads", "creative", "quality"]
---
## Definition
Ad Strength（广告强度）是 Google Ads 衡量广告创意质量和多样性的评分指标，直接影响广告效果和竞价竞争力。
## Google Ads Ad Strength
### Scoring Levels
| 评分 | 含义 | 目标 |
|------|------|------|
| Excellent | 创意丰富、多样、与关键词高度相关 | ✅ 终极目标 |
| Good | 创意质量良好，有一定多样性 | ✅ 基准线 |
| Average | 创意质量一般，多样性不足 | ⚠️ 需改进 |
| Poor | 创意严重不足 | ❌ 必须修复 |
### 影响因素
1. **数量（Quantity）**：标题/描述是否达到最大数量
2. **多样性（Diversity）**：各标题传递不同信息，避免重复
3. **相关性（Relevance）**：创意与关键词和广告组主题的匹配度
4. **历史效果（Past Performance）**：基于类似创意的历史 CTR 预测
### 优化路径
- 添加缺失类别的 headline（品牌/利益/功能/CTA/社会证明）
- 避免同义词重复
- 确保每个 headline 传递独特信息
- 使用关键词插入提升相关性
## Meta Relevance Diagnostics
Meta Ads 的相关度评分机制：
- **Very High**：创意与受众高度匹配
- **High**：匹配良好
- **Average**：匹配一般
- **Low**：匹配不足，需调整创意或受众
## Target Benchmarks
| 平台 | 指标 | 目标 |
|------|------|------|
| Google Ads | Ad Strength | 90%+ Excellent/Good |
| Google Ads | RSA headline count | 12-15 条 |
| Meta Ads | Relevance Diagnostics | Above Average/Top |
## Sources
- [[paid-media-creative-strategist]]

86
wiki/concepts/Adaptive-Tone.md
View File

@@ -1,43 +1,43 @@
---
title: "Adaptive Tone"
type: concept
tags: []
last_updated: 2026-04-17
---
## Definition
AI Agent 根据用户表现动态调整语气和沟通策略的机制。连续成功时给予鼓励（encouraging），连续失败时保持温和坚持（gently persistent），而非使用统一的模板化消息。
## Core Mechanism
| 用户状态 | AI 语气策略 |
|---------|-----------|
| 连续完成（高连续天数） | 简短肯定 + 引用连续记录，例："Day 12 of morning workouts. Solid." |
| 偶发错失（1-2天） | 温和提醒 + 初心提醒，例："Just acknowledge it and remind me why I started." |
| 连续错失（≥3天） | 更长激励消息 + 询问是否调整目标 |
## Why It Matters
- **静态提醒容易被忽视**：Push 通知、每日模板消息最终会被大脑过滤为"噪音"
- **个性化消息具有真实激励效果**："Day 15, don't break it now" 这类引用具体连续记录的消息会触发心理承诺一致性效应
- **避免羞辱感**：连续错失时不要 guilt-trip（内疚轰炸），保持支持性语气才能让用户持续参与
## Implementation Example（OpenClaw）
```
When I confirm a habit, respond with a short encouraging message and
mention my current streak. Example: "Day 12 of morning workouts. Solid."
When I miss a habit, don't guilt-trip me. Just acknowledge it and remind
me why I started. If I miss 3 days in a row, send a longer motivational
message and ask if I want to adjust the goal.
```
## Related Concepts
- [[Agent Personality]] — Adaptive Tone 是 Agent Personality 在习惯追踪场景的具体应用
- [[Streak Tracking]] — Adaptive Tone 消息中的数据来源
- [[Active Accountability]] — 需要 Adaptive Tone 才能真正实现主动问责
## Source
- [[habit-tracker-accountability-coach]]
---
title: "Adaptive Tone"
type: concept
tags: []
last_updated: 2026-04-17
---
## Definition
AI Agent 根据用户表现动态调整语气和沟通策略的机制。连续成功时给予鼓励（encouraging），连续失败时保持温和坚持（gently persistent），而非使用统一的模板化消息。
## Core Mechanism
| 用户状态 | AI 语气策略 |
|---------|-----------|
| 连续完成（高连续天数） | 简短肯定 + 引用连续记录，例："Day 12 of morning workouts. Solid." |
| 偶发错失（1-2天） | 温和提醒 + 初心提醒，例："Just acknowledge it and remind me why I started." |
| 连续错失（≥3天） | 更长激励消息 + 询问是否调整目标 |
## Why It Matters
- **静态提醒容易被忽视**：Push 通知、每日模板消息最终会被大脑过滤为"噪音"
- **个性化消息具有真实激励效果**："Day 15, don't break it now" 这类引用具体连续记录的消息会触发心理承诺一致性效应
- **避免羞辱感**：连续错失时不要 guilt-trip（内疚轰炸），保持支持性语气才能让用户持续参与
## Implementation Example（OpenClaw）
```
When I confirm a habit, respond with a short encouraging message and
mention my current streak. Example: "Day 12 of morning workouts. Solid."
When I miss a habit, don't guilt-trip me. Just acknowledge it and remind
me why I started. If I miss 3 days in a row, send a longer motivational
message and ask if I want to adjust the goal.
```
## Related Concepts
- [[Agent Personality]] — Adaptive Tone 是 Agent Personality 在习惯追踪场景的具体应用
- [[Streak Tracking]] — Adaptive Tone 消息中的数据来源
- [[Active Accountability]] — 需要 Adaptive Tone 才能真正实现主动问责
## Source
- [[habit-tracker-accountability-coach]]

56
wiki/concepts/Advantage+-Campaigns.md
View File

@@ -1,28 +1,28 @@
---
title: "Advantage+ Campaigns"
type: concept
tags: ["paid-media", "meta", "automation", "ai"]
last_updated: 2026-04-25
---
## Aliases
- Advantage+ Shopping
- Advantage+ App Campaigns
- Meta 自动化广告系列
## Overview
Advantage+ 是 Meta 推出的 AI 驱动型自动化广告系列，涵盖 Advantage+ Shopping（A+SC）和 Advantage+ App Campaigns。该框架将传统 CBO（广告系列预算优化）和 ABO（广告组预算优化）的部分人工决策替换为机器学习算法。
## Definition
核心特点：
- **受众自动化**：Meta AI 自动探索最优受众，减少人工定向投入
- **创意自动化**：自动组合多套素材，找出最优创意组合
- **竞价自动化**：动态竞价，基于转化概率实时调整出价
- **全漏斗优化**：跨引流和再营销阶段统一优化
与 [[SmartBidding]]（Google Ads）理念相似，但实现于 Meta 生态系统。
## Connections
- [[Paid Media Paid Social Strategist]] Agent 的核心工具
- 与 [[Conversions API]] 配合可提升 Advantage+ 的机器学习信号质量
- 与 [[TieredCampaignArchitecture]] 存在张力：Advantage+ 倾向于减少人工结构干预
---
title: "Advantage+ Campaigns"
type: concept
tags: ["paid-media", "meta", "automation", "ai"]
last_updated: 2026-04-25
---
## Aliases
- Advantage+ Shopping
- Advantage+ App Campaigns
- Meta 自动化广告系列
## Overview
Advantage+ 是 Meta 推出的 AI 驱动型自动化广告系列，涵盖 Advantage+ Shopping（A+SC）和 Advantage+ App Campaigns。该框架将传统 CBO（广告系列预算优化）和 ABO（广告组预算优化）的部分人工决策替换为机器学习算法。
## Definition
核心特点：
- **受众自动化**：Meta AI 自动探索最优受众，减少人工定向投入
- **创意自动化**：自动组合多套素材，找出最优创意组合
- **竞价自动化**：动态竞价，基于转化概率实时调整出价
- **全漏斗优化**：跨引流和再营销阶段统一优化
与 [[SmartBidding]]（Google Ads）理念相似，但实现于 Meta 生态系统。
## Connections
- [[Paid Media Paid Social Strategist]] Agent 的核心工具
- 与 [[Conversions API]] 配合可提升 Advantage+ 的机器学习信号质量
- 与 [[TieredCampaignArchitecture]] 存在张力：Advantage+ 倾向于减少人工结构干预

66
wiki/concepts/Adversarial-Debate-Pattern.md
View File

@@ -1,33 +1,33 @@
---
title: "Adversarial Debate Pattern"
type: concept
tags: []
sources: []
last_updated: 2026-04-25
---
# Adversarial Debate Pattern
## 定义
多智能体系统的对抗式辩论模式——一个Agent提出方案，另一个Agent攻击反驳，由第三个Agent（裁判）决定胜负。核心是用外部批评者和评判者模拟人类的"恐惧"动机。
## 角色
- **Generator**："Here is my plan."（生成方案）
- **Critic**："Here are 3 reasons why that plan sucks."（扮演魔鬼代言人）
- **Judge**："The Critic is right. Fix it."（裁判/主持人）
## 核心洞察
LLM是"Yes-Men"，一旦开始写作很少自我纠正——需要一个指定的反对者来打破这种惯性。
## 关键机制
- 三方应使用**不同模型**（不同训练/微调/提示），多样性有益
- 顺序执行+循环特性导致速度可能非常慢
- Agent可能陷入无限辩论——可使用**Watchdog**（确定性代码）在时间/次数超阈值时打破循环
## 适用场景
- 安全分析（Security Analysis）
- 代码审查（Code Review）
- 高风险内容审核（High-Stakes Content Moderation）
## 来源
- [[multi-agent-system-reliability]]
---
title: "Adversarial Debate Pattern"
type: concept
tags: []
sources: []
last_updated: 2026-04-25
---
# Adversarial Debate Pattern
## 定义
多智能体系统的对抗式辩论模式——一个Agent提出方案，另一个Agent攻击反驳，由第三个Agent（裁判）决定胜负。核心是用外部批评者和评判者模拟人类的"恐惧"动机。
## 角色
- **Generator**："Here is my plan."（生成方案）
- **Critic**："Here are 3 reasons why that plan sucks."（扮演魔鬼代言人）
- **Judge**："The Critic is right. Fix it."（裁判/主持人）
## 核心洞察
LLM是"Yes-Men"，一旦开始写作很少自我纠正——需要一个指定的反对者来打破这种惯性。
## 关键机制
- 三方应使用**不同模型**（不同训练/微调/提示），多样性有益
- 顺序执行+循环特性导致速度可能非常慢
- Agent可能陷入无限辩论——可使用**Watchdog**（确定性代码）在时间/次数超阈值时打破循环
## 适用场景
- 安全分析（Security Analysis）
- 代码审查（Code Review）
- 高风险内容审核（High-Stakes Content Moderation）
## 来源
- [[multi-agent-system-reliability]]

106
wiki/concepts/Agent-Build-Gate.md
View File

@@ -1,53 +1,53 @@
---
title: "Agent-Build-Gate"
type: concept
tags: []
last_updated: 2026-04-22
---
## Overview
Agent 执行构建任务前的条件检查机制——只有通过门控条件的 Agent 才允许进入实际代码编写阶段。通过在 Agent 的 instructions 中嵌入 pre-gate 规则实现自动化门控，是 [[Pre-Build Validation]] 的技术实现机制。
## Implementation Pattern
在 [[OpenClaw]] Agent 的 instructions 中嵌入规则：
```text
Before starting any new project, feature, or tool, always run idea_check first.
Rules:
- If reality_signal > 70: STOP. Report top 3 competitors.
Ask me if I want to proceed, pivot, or abandon.
- If reality_signal 30-70: Show me results and pivot_hints.
Suggest a niche angle that existing projects don't cover.
- If reality_signal < 30: Proceed to build.
Mention that the space is open.
- Always show the reality_signal score and top competitors before writing any code.
```
## How It Works
1. 用户向 Agent 发送构建指令（如"build me a CLI tool for AI code review"）
2. Agent 自动调用 `idea_check()` 工具（而非立即开始写代码）
3. 获取 `reality_signal` 和竞品信息
4. 根据阈值执行对应规则（STOP / 展示建议 / 直接构建）
5. 只有在 `reality_signal < 30` 或用户明确授权的情况下，Agent 才进入代码编写阶段
## Relationship to Related Concepts
- [[Pre-Build Validation]] ← Agent-Build-Gate 是其技术实现
- [[idea-reality-mcp]] ← 提供 `idea_check()` 工具
- [[Reality-Signal]] ← Gate 的判断依据
- [[Pivot-Strategy]] ← Gate 触发 STOP 时的后续建议
- [[OpenClaw]] ← 当前唯一支持此模式的 Agent 框架
## Advantages over Manual Gate
- **自动化**：无需人工触发，Agent 自动执行检查
- **强制化**：Agent 指令层面嵌入，无法绕过（除非修改 instructions）
- **上下文保持**：检查结果和 Agent 对话上下文共存，无需额外工具切换
- **持续生效**：每次新的构建指令都会自动触发，无需重复提醒
## Related
- [[Pre-Build Validation]]
- [[idea-reality-mcp]]
- [[Reality-Signal]]
- [[Pivot-Strategy]]
- [[OpenClaw]]
- [[Competition-Analysis]]
---
title: "Agent-Build-Gate"
type: concept
tags: []
last_updated: 2026-04-22
---
## Overview
Agent 执行构建任务前的条件检查机制——只有通过门控条件的 Agent 才允许进入实际代码编写阶段。通过在 Agent 的 instructions 中嵌入 pre-gate 规则实现自动化门控，是 [[Pre-Build Validation]] 的技术实现机制。
## Implementation Pattern
在 [[OpenClaw]] Agent 的 instructions 中嵌入规则：
```text
Before starting any new project, feature, or tool, always run idea_check first.
Rules:
- If reality_signal > 70: STOP. Report top 3 competitors.
Ask me if I want to proceed, pivot, or abandon.
- If reality_signal 30-70: Show me results and pivot_hints.
Suggest a niche angle that existing projects don't cover.
- If reality_signal < 30: Proceed to build.
Mention that the space is open.
- Always show the reality_signal score and top competitors before writing any code.
```
## How It Works
1. 用户向 Agent 发送构建指令（如"build me a CLI tool for AI code review"）
2. Agent 自动调用 `idea_check()` 工具（而非立即开始写代码）
3. 获取 `reality_signal` 和竞品信息
4. 根据阈值执行对应规则（STOP / 展示建议 / 直接构建）
5. 只有在 `reality_signal < 30` 或用户明确授权的情况下，Agent 才进入代码编写阶段
## Relationship to Related Concepts
- [[Pre-Build Validation]] ← Agent-Build-Gate 是其技术实现
- [[idea-reality-mcp]] ← 提供 `idea_check()` 工具
- [[Reality-Signal]] ← Gate 的判断依据
- [[Pivot-Strategy]] ← Gate 触发 STOP 时的后续建议
- [[OpenClaw]] ← 当前唯一支持此模式的 Agent 框架
## Advantages over Manual Gate
- **自动化**：无需人工触发，Agent 自动执行检查
- **强制化**：Agent 指令层面嵌入，无法绕过（除非修改 instructions）
- **上下文保持**：检查结果和 Agent 对话上下文共存，无需额外工具切换
- **持续生效**：每次新的构建指令都会自动触发，无需重复提醒
## Related
- [[Pre-Build Validation]]
- [[idea-reality-mcp]]
- [[Reality-Signal]]
- [[Pivot-Strategy]]
- [[OpenClaw]]
- [[Competition-Analysis]]

100
wiki/concepts/Agent-Design-Principles.md
View File

@@ -1,50 +1,50 @@
---
title: "Agent Design Principles"
type: concept
tags: [multi-agent, agent-design, the-agency]
sources: [contributing_zh-cn, contributing-to-the-agency]
last_updated: 2026-04-24
---
# Agent Design Principles
The five core design principles for building high-quality AI agents in The Agency framework.
## Five Principles
### 1. 🎭 Distinct Personality
- Give each agent a unique tone and persona
- Avoid generic "I am a helpful assistant" — be specific and memorable
- Example: "I will find 3-5 problems by default and ask for visual evidence" (Evidence Collector)
### 2. 📋 Clear Deliverables
- Provide actionable code examples
- Include templates and frameworks
- Show real output, not vague descriptions
### 3. ✅ Success Metrics
- Include specific, quantifiable metrics
- Example: "Page load time under 3 seconds on 3G network"
- Example: "10,000+ combined karma points across accounts"
### 4. 🔄 Verified Workflows
- Step-by-step processes that are clear
- Validated in real-world scenarios
- Reject pure theory without testing
### 5. 💡 Learning & Memory
- Agents identify which patterns to recognize
- How they iterate and optimize over time
- What they remember between sessions
## Anti-Patterns (Avoid)
- ❌ Generic "helpful assistant" persona
- ❌ Vague "I will help you..." descriptions
- ❌ No code examples or deliverables
- ❌ Too broad scope (jack of all trades)
- ❌ Untested theoretical solutions
## Connections
- Extends [[Multi-Agent-System-Reliability]] — design-time quality standards complement runtime reliability patterns
- Used by [[Multi-Agent-Team]] — standardized agent creation framework
- Related to [[Agent-Template]] — the structural template implementing these principles
---
title: "Agent Design Principles"
type: concept
tags: [multi-agent, agent-design, the-agency]
sources: [contributing_zh-cn, contributing-to-the-agency]
last_updated: 2026-04-24
---
# Agent Design Principles
The five core design principles for building high-quality AI agents in The Agency framework.
## Five Principles
### 1. 🎭 Distinct Personality
- Give each agent a unique tone and persona
- Avoid generic "I am a helpful assistant" — be specific and memorable
- Example: "I will find 3-5 problems by default and ask for visual evidence" (Evidence Collector)
### 2. 📋 Clear Deliverables
- Provide actionable code examples
- Include templates and frameworks
- Show real output, not vague descriptions
### 3. ✅ Success Metrics
- Include specific, quantifiable metrics
- Example: "Page load time under 3 seconds on 3G network"
- Example: "10,000+ combined karma points across accounts"
### 4. 🔄 Verified Workflows
- Step-by-step processes that are clear
- Validated in real-world scenarios
- Reject pure theory without testing
### 5. 💡 Learning & Memory
- Agents identify which patterns to recognize
- How they iterate and optimize over time
- What they remember between sessions
## Anti-Patterns (Avoid)
- ❌ Generic "helpful assistant" persona
- ❌ Vague "I will help you..." descriptions
- ❌ No code examples or deliverables
- ❌ Too broad scope (jack of all trades)
- ❌ Untested theoretical solutions
## Connections
- Extends [[Multi-Agent-System-Reliability]] — design-time quality standards complement runtime reliability patterns
- Used by [[Multi-Agent-Team]] — standardized agent creation framework
- Related to [[Agent-Template]] — the structural template implementing these principles

76
wiki/concepts/Agent-Driven-Market-Research.md
View File

@@ -1,38 +1,38 @@
---
title: "Agent-Driven Market Research"
type: concept
tags: [market-research, agentic-ai, automation]
sources: [market-research-product-factory]
last_updated: 2026-04-22
---
## Definition
Agent-Driven Market Research（Agent 驱动的市场调研）是指利用 AI Agent 自动采集、整理和分析市场信息的方法，替代传统人工搜索、浏览和归纳的市场调研模式。
## Core Mechanism
- **自动化数据采集**：AI Agent 主动从 Reddit、X、论坛等平台抓取用户讨论
- **结构化信息提取**：从非结构化文本中提取痛点、功能请求、竞品评价等关键信息
- **趋势分析**：按时间窗口（近7天/30天/90天）聚合分析，识别新兴趋势
- **多源交叉验证**：综合多个来源确保洞察的可靠性和代表性
## Contrast with Traditional Methods
| 维度 | 传统市场调研 | Agent-Driven Market Research |
|------|-------------|----------------------------|
| 数据来源 | 问卷/访谈/一手报告 | Reddit/X/论坛/评论 |
| 数据真实性 | 经过受访者过滤和美化的二手信息 | 用户原生表达，未加工的真实情绪 |
| 时效性 | 调研周期长，数据可能滞后 | 近实时采集，可聚焦特定时间窗口 |
| 成本 | 专业调研公司费用高 | AI Agent 自动化，成本极低 |
| 规模 | 样本量受限 | 可覆盖数十万条讨论帖子 |
## Relationship to Other Concepts
- [[Agent-Driven Market Research]] → 输出 → [[Pain Point Mining]] → 支撑 → [[Startup MVP Pipeline]]
- [[Agentic AI]] → 技术基础 → [[Agent-Driven Market Research]]
- [[Last 30 Days Method]] → 工具方法 → [[Agent-Driven Market Research]]
## Sources
- [[market-research-product-factory]]
---
title: "Agent-Driven Market Research"
type: concept
tags: [market-research, agentic-ai, automation]
sources: [market-research-product-factory]
last_updated: 2026-04-22
---
## Definition
Agent-Driven Market Research（Agent 驱动的市场调研）是指利用 AI Agent 自动采集、整理和分析市场信息的方法，替代传统人工搜索、浏览和归纳的市场调研模式。
## Core Mechanism
- **自动化数据采集**：AI Agent 主动从 Reddit、X、论坛等平台抓取用户讨论
- **结构化信息提取**：从非结构化文本中提取痛点、功能请求、竞品评价等关键信息
- **趋势分析**：按时间窗口（近7天/30天/90天）聚合分析，识别新兴趋势
- **多源交叉验证**：综合多个来源确保洞察的可靠性和代表性
## Contrast with Traditional Methods
| 维度 | 传统市场调研 | Agent-Driven Market Research |
|------|-------------|----------------------------|
| 数据来源 | 问卷/访谈/一手报告 | Reddit/X/论坛/评论 |
| 数据真实性 | 经过受访者过滤和美化的二手信息 | 用户原生表达，未加工的真实情绪 |
| 时效性 | 调研周期长，数据可能滞后 | 近实时采集，可聚焦特定时间窗口 |
| 成本 | 专业调研公司费用高 | AI Agent 自动化，成本极低 |
| 规模 | 样本量受限 | 可覆盖数十万条讨论帖子 |
## Relationship to Other Concepts
- [[Agent-Driven Market Research]] → 输出 → [[Pain Point Mining]] → 支撑 → [[Startup MVP Pipeline]]
- [[Agentic AI]] → 技术基础 → [[Agent-Driven Market Research]]
- [[Last 30 Days Method]] → 工具方法 → [[Agent-Driven Market Research]]
## Sources
- [[market-research-product-factory]]

98
wiki/concepts/Agent-Memory.md
View File

@@ -1,49 +1,49 @@
---
title: "Agent-Memory"
type: concept
tags: [OpenClaw, Agent, Memory, Long-Term]
sources: [万字讲透openclaw-workspace深度解析-2026-03-21]
last_updated: 2026-03-21
---
## Definition
**Agent-Memory** 是 OpenClaw 通过 workspace 文件体系实现的**跨会话长期记忆**机制。核心洞察：对 Agent 来说，真正算数的长期记忆，是 workspace 里那些 Markdown 文件，不是什么看不见摸不着的黑盒数据库。
## 记忆机制
OpenClaw 支持两种记忆方案：
- **builtin**（默认）：原始记忆还是 Markdown 文件，系统维护本地索引方便检索
- **qmd**：换了一套更强的检索/索引方式来辅助"想起来"
## 工作流程
```
对话发生
↓
Agent 通过普通文件工具把重要信息写入 `memory/` 或 `MEMORY.md`
↓
下次对话开始
↓
Agent 通过 `memory_search` / `memory_get` 检索相关记忆
↓
相关记忆被注入到当前对话的上下文里
↓
Agent 表现出"我记得你说过……"的能力
```
## 为什么重要
默认情况下，LLM 对话是无状态的——每次新开会话，什么都不记得。对持续工作的 Agent 来说很伤：
- 每次都要重新解释项目背景
- Agent 无法在多个会话之间积累对工作的理解
- 花了时间告诉它的偏好和经验，换个会话就白费了
## Related Concepts
- [[MEMORY.md]] — 长期知识总表，与 memory/ 目录共同构成记忆层
- [[Workspace]] — Agent-Memory 的载体
- [[OpenClaw]] — 实现 Agent-Memory 的框架
---
title: "Agent-Memory"
type: concept
tags: [OpenClaw, Agent, Memory, Long-Term]
sources: [万字讲透openclaw-workspace深度解析-2026-03-21]
last_updated: 2026-03-21
---
## Definition
**Agent-Memory** 是 OpenClaw 通过 workspace 文件体系实现的**跨会话长期记忆**机制。核心洞察：对 Agent 来说，真正算数的长期记忆，是 workspace 里那些 Markdown 文件，不是什么看不见摸不着的黑盒数据库。
## 记忆机制
OpenClaw 支持两种记忆方案：
- **builtin**（默认）：原始记忆还是 Markdown 文件，系统维护本地索引方便检索
- **qmd**：换了一套更强的检索/索引方式来辅助"想起来"
## 工作流程
```
对话发生
↓
Agent 通过普通文件工具把重要信息写入 `memory/` 或 `MEMORY.md`
↓
下次对话开始
↓
Agent 通过 `memory_search` / `memory_get` 检索相关记忆
↓
相关记忆被注入到当前对话的上下文里
↓
Agent 表现出"我记得你说过……"的能力
```
## 为什么重要
默认情况下，LLM 对话是无状态的——每次新开会话，什么都不记得。对持续工作的 Agent 来说很伤：
- 每次都要重新解释项目背景
- Agent 无法在多个会话之间积累对工作的理解
- 花了时间告诉它的偏好和经验，换个会话就白费了
## Related Concepts
- [[MEMORY.md]] — 长期知识总表，与 memory/ 目录共同构成记忆层
- [[Workspace]] — Agent-Memory 的载体
- [[OpenClaw]] — 实现 Agent-Memory 的框架

84
wiki/concepts/Agent-Mode.md
View File

@@ -1,42 +1,42 @@
---
title: "Agent模式"
type: concept
tags: [cursor, ai, agent, interaction-mode]
sources: []
last_updated: 2026-04-22
---
## Overview
Agent 模式是 Cursor Composer 模块中的一种交互方式，允许 AI 自动执行内嵌命令并处理工具调用，显著减少手动操作步骤，实现命令链路的自动打通。
## Aliases
- Agent Mode
- Composer Agent 模式
- 自动执行模式
## Agent模式 vs Normal模式
| 特性 | Agent 模式 | Normal 模式 |
|------|-----------|-------------|
| 命令执行 | 自动执行 | 用户手动复制执行 |
| 工具调用 | 自动触发和处理 | 需要用户确认 |
| 效率 | 高，适合批量任务 | 低，适合精确控制 |
| 风险 | 可能误操作（建议关闭 Yolo Mode） | 安全 |
| 使用门槛 | 低，无需干预 | 高，需用户操作 |
## Key Features
- **自动工具链**：自动调用 MCP 工具并整合结果
- **命令链路打通**：减少用户在不同环境间切换的操作步骤
- **对话标识**：Agent 模式下对话界面下方会显示"agent"标识
- **可关闭**：用户可随时切换回 Normal 模式
## Yolo Mode
Agent 模式下的危险选项。开启后会自动无确认执行所有命令，可能造成误操作（如误删文件）。官方默认关闭，建议用户谨慎使用。
## Connections
- [[Cursor]] — Agent 模式所在的模块
- [[MCP（Model Context Protocol）]] — Agent 模式可调用的协议
- [[Sequential Thinking]] — Agent 模式下可触发的 MCP 工具
- [[Tool Calling]] — Agent 模式自动执行的调用机制
## Sources
- [[mcp在cursor中的集成与应用详解]]
---
title: "Agent模式"
type: concept
tags: [cursor, ai, agent, interaction-mode]
sources: []
last_updated: 2026-04-22
---
## Overview
Agent 模式是 Cursor Composer 模块中的一种交互方式，允许 AI 自动执行内嵌命令并处理工具调用，显著减少手动操作步骤，实现命令链路的自动打通。
## Aliases
- Agent Mode
- Composer Agent 模式
- 自动执行模式
## Agent模式 vs Normal模式
| 特性 | Agent 模式 | Normal 模式 |
|------|-----------|-------------|
| 命令执行 | 自动执行 | 用户手动复制执行 |
| 工具调用 | 自动触发和处理 | 需要用户确认 |
| 效率 | 高，适合批量任务 | 低，适合精确控制 |
| 风险 | 可能误操作（建议关闭 Yolo Mode） | 安全 |
| 使用门槛 | 低，无需干预 | 高，需用户操作 |
## Key Features
- **自动工具链**：自动调用 MCP 工具并整合结果
- **命令链路打通**：减少用户在不同环境间切换的操作步骤
- **对话标识**：Agent 模式下对话界面下方会显示"agent"标识
- **可关闭**：用户可随时切换回 Normal 模式
## Yolo Mode
Agent 模式下的危险选项。开启后会自动无确认执行所有命令，可能造成误操作（如误删文件）。官方默认关闭，建议用户谨慎使用。
## Connections
- [[Cursor]] — Agent 模式所在的模块
- [[MCP（Model Context Protocol）]] — Agent 模式可调用的协议
- [[Sequential Thinking]] — Agent 模式下可触发的 MCP 工具
- [[Tool Calling]] — Agent 模式自动执行的调用机制
## Sources
- [[mcp在cursor中的集成与应用详解]]

88
wiki/concepts/Agent-Personality.md
View File

@@ -1,44 +1,44 @@
---
title: "Agent Personality"
type: concept
tags: [OpenClaw, Agent, Design, UX]
sources: [multi-agent-team]
last_updated: 2026-04-23
---
## Definition
**Agent Personality** 是给 AI Agent 赋予独特的名字、性格设定和沟通风格的设计实践，使其与用户协作时更加自然，而非像一个通用 AI 工具。
## 核心洞察
> "Personality matters more than you'd think: Giving agents distinct names and communication styles makes it natural to 'talk to your team' rather than wrestle with a generic AI"
赋予 Agent 个性比想象中更重要：
- **降低协作摩擦**：用户自然地"与团队对话"，而非使用工具
- **明确的职责边界**：名字和人格暗示了 Agent 的专长
- **增强信任感**：有个性的 Agent 更容易建立情感连接
## 设计要素
- **Name（名字）**：简短、独特，如 Milo、Josh、Dev
- **性格描述**：用叙事性语言定义 Agent 的行事风格
- Milo: "Confident, big-picture, charismatic"（策略领导型）
- Josh: "Pragmatic, straight to the point, numbers-driven"（商业分析型）
- Dev: "Precise, thorough, security-conscious"（开发严谨型）
- **沟通风格**：决定 Agent 如何呈现信息和建议
## 与 Agent Specialization 的关系
Agent Personality 配合 Agent Specialization 共同作用：
- **Personality** 解决"如何沟通"的问题
- **Specialization** 解决"做什么任务"的问题
- 两者结合让 Agent 更像一个真实的团队成员
## Related Concepts
- [[Agent Specialization]] — Agent 的专业分工
- [[OpenClaw]] — SOUL.md 是 Agent Personality 的配置文件
- [[Agent-Memory]] — 个性配合长期记忆增强 Agent 连续性
- [[Chained Agents]] — 链式 Agent 中的角色设计
---
title: "Agent Personality"
type: concept
tags: [OpenClaw, Agent, Design, UX]
sources: [multi-agent-team]
last_updated: 2026-04-23
---
## Definition
**Agent Personality** 是给 AI Agent 赋予独特的名字、性格设定和沟通风格的设计实践，使其与用户协作时更加自然，而非像一个通用 AI 工具。
## 核心洞察
> "Personality matters more than you'd think: Giving agents distinct names and communication styles makes it natural to 'talk to your team' rather than wrestle with a generic AI"
赋予 Agent 个性比想象中更重要：
- **降低协作摩擦**：用户自然地"与团队对话"，而非使用工具
- **明确的职责边界**：名字和人格暗示了 Agent 的专长
- **增强信任感**：有个性的 Agent 更容易建立情感连接
## 设计要素
- **Name（名字）**：简短、独特，如 Milo、Josh、Dev
- **性格描述**：用叙事性语言定义 Agent 的行事风格
- Milo: "Confident, big-picture, charismatic"（策略领导型）
- Josh: "Pragmatic, straight to the point, numbers-driven"（商业分析型）
- Dev: "Precise, thorough, security-conscious"（开发严谨型）
- **沟通风格**：决定 Agent 如何呈现信息和建议
## 与 Agent Specialization 的关系
Agent Personality 配合 Agent Specialization 共同作用：
- **Personality** 解决"如何沟通"的问题
- **Specialization** 解决"做什么任务"的问题
- 两者结合让 Agent 更像一个真实的团队成员
## Related Concepts
- [[Agent Specialization]] — Agent 的专业分工
- [[OpenClaw]] — SOUL.md 是 Agent Personality 的配置文件
- [[Agent-Memory]] — 个性配合长期记忆增强 Agent 连续性
- [[Chained Agents]] — 链式 Agent 中的角色设计

52
wiki/concepts/Agent-Routing-Rules.md
View File

@@ -1,26 +1,26 @@
---
title: "Agent Routing Rules"
type: concept
last_updated: 2026-04-10
---
## Definition
Agent Routing Rules 是 OpenClaw 中绑定特定 Channel（如 Telegram）到特定模型的配置规则，优先级高于全局配置文件（`openclaw.json`）。
## Key Characteristics
- 定义在 OpenClaw 的 Agent 路由层，不在 `openclaw.json` 全局 compaction 配置里
- 修改全局配置对 Agent 级别路由无效
- 模型 context window 直接影响可用 token 数量
## Common Failure Pattern
当 fallback 机制切换到小 context 模型，且该模型在路由规则中被绑定到某个 channel 时：
- Telegram channel → deepseek-reasoner (16K)
- 16K context + 16K safeguard 预留 = 0 可用 token
## Related
- [[Model-Fallback]]: 触发模型切换的机制
- [[Compaction]]: Agent 级别 compaction 与全局配置的区别
- [[Layered-Configuration]]: 分层配置的重要性
## Sources
- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]]
---
title: "Agent Routing Rules"
type: concept
last_updated: 2026-04-10
---
## Definition
Agent Routing Rules 是 OpenClaw 中绑定特定 Channel（如 Telegram）到特定模型的配置规则，优先级高于全局配置文件（`openclaw.json`）。
## Key Characteristics
- 定义在 OpenClaw 的 Agent 路由层，不在 `openclaw.json` 全局 compaction 配置里
- 修改全局配置对 Agent 级别路由无效
- 模型 context window 直接影响可用 token 数量
## Common Failure Pattern
当 fallback 机制切换到小 context 模型，且该模型在路由规则中被绑定到某个 channel 时：
- Telegram channel → deepseek-reasoner (16K)
- 16K context + 16K safeguard 预留 = 0 可用 token
## Related
- [[Model-Fallback]]: 触发模型切换的机制
- [[Compaction]]: Agent 级别 compaction 与全局配置的区别
- [[Layered-Configuration]]: 分层配置的重要性
## Sources
- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]]

110
wiki/concepts/Agent-Specialization.md
View File

@@ -1,55 +1,55 @@
---
title: "Agent Specialization"
type: concept
tags: [OpenClaw, Agent, Architecture, Team]
sources: [multi-agent-team]
last_updated: 2026-04-23
---
## Definition
**Agent Specialization** 是多 Agent 系统中，每个 Agent 拥有独立角色、专长领域和针对性优化的模型，通过协作完成复杂任务的架构设计原则。
## 核心洞察
> "One agent can't do everything well: A single agent's context window fills up fast when juggling strategy, code, marketing research, and business analysis"
核心问题：
- **上下文窗口瓶颈**：单个 Agent 同时处理多领域任务时上下文快速填满
- **泛化输出的局限**：通用提示产生通用输出，专业任务需要专业 Agent
- **效率不均衡**：不同任务需要的模型能力不同，混用造成资源浪费
## 专业化 Agent 示例
| Agent | 角色 | 模型选择 | 核心职责 |
|-------|------|----------|----------|
| Milo | 策略领导 | Claude Opus | 战略规划、OKR 追踪、Agent 协调 |
| Josh | 商业分析 | Claude Sonnet | 定价策略、KPI 追踪、竞品分析 |
| Marketing | 营销研究 | Gemini | 内容创意、SEO 研究、社媒监控 |
| Dev | 开发工程 | Claude Opus/Codex | 代码审查、架构决策、文档撰写 |
## 模型匹配原则
> "Right model for the right job: Don't use an expensive reasoning model for keyword monitoring"
- **复杂推理任务**：Claude Opus（深度思考、架构设计）
- **分析性任务**：Claude Sonnet（快速分析、数据处理）
- **研究性任务**：Gemini（长上下文、网页研究）
- **执行性任务**：Codex（代码生成、工具调用）
## 起步策略
> "Start with 2, not 4: Begin with a lead + one specialist, then add agents as you identify bottlenecks"
从最小可行团队开始：
1. **1 个领导 Agent**：总协调、决策、汇总
2. **1 个专家 Agent**：根据当前最大瓶颈选择
3. **逐步扩展**：瓶颈出现时添加新 Agent
## Related Concepts
- [[Agent Personality]] — Agent 个性化与专业化相辅相成
- [[Multi-Agent Coordination]] — 多 Agent 协调机制
- [[Parallel Agent Execution]] — 并行执行提升效率
- [[Chained Agents]] — 链式 Agent（另一种协作模式）
---
title: "Agent Specialization"
type: concept
tags: [OpenClaw, Agent, Architecture, Team]
sources: [multi-agent-team]
last_updated: 2026-04-23
---
## Definition
**Agent Specialization** 是多 Agent 系统中，每个 Agent 拥有独立角色、专长领域和针对性优化的模型，通过协作完成复杂任务的架构设计原则。
## 核心洞察
> "One agent can't do everything well: A single agent's context window fills up fast when juggling strategy, code, marketing research, and business analysis"
核心问题：
- **上下文窗口瓶颈**：单个 Agent 同时处理多领域任务时上下文快速填满
- **泛化输出的局限**：通用提示产生通用输出，专业任务需要专业 Agent
- **效率不均衡**：不同任务需要的模型能力不同，混用造成资源浪费
## 专业化 Agent 示例
| Agent | 角色 | 模型选择 | 核心职责 |
|-------|------|----------|----------|
| Milo | 策略领导 | Claude Opus | 战略规划、OKR 追踪、Agent 协调 |
| Josh | 商业分析 | Claude Sonnet | 定价策略、KPI 追踪、竞品分析 |
| Marketing | 营销研究 | Gemini | 内容创意、SEO 研究、社媒监控 |
| Dev | 开发工程 | Claude Opus/Codex | 代码审查、架构决策、文档撰写 |
## 模型匹配原则
> "Right model for the right job: Don't use an expensive reasoning model for keyword monitoring"
- **复杂推理任务**：Claude Opus（深度思考、架构设计）
- **分析性任务**：Claude Sonnet（快速分析、数据处理）
- **研究性任务**：Gemini（长上下文、网页研究）
- **执行性任务**：Codex（代码生成、工具调用）
## 起步策略
> "Start with 2, not 4: Begin with a lead + one specialist, then add agents as you identify bottlenecks"
从最小可行团队开始：
1. **1 个领导 Agent**：总协调、决策、汇总
2. **1 个专家 Agent**：根据当前最大瓶颈选择
3. **逐步扩展**：瓶颈出现时添加新 Agent
## Related Concepts
- [[Agent Personality]] — Agent 个性化与专业化相辅相成
- [[Multi-Agent Coordination]] — 多 Agent 协调机制
- [[Parallel Agent Execution]] — 并行执行提升效率
- [[Chained Agents]] — 链式 Agent（另一种协作模式）

154
wiki/concepts/Agent-Template.md
View File

@@ -1,77 +1,77 @@
---
title: "Agent Template"
type: concept
tags: [multi-agent, agent-design, the-agency]
sources: [contributing_zh-cn, contributing-to-the-agency]
last_updated: 2026-04-24
---
# Agent Template
The standardized YAML frontmatter + structured document template for creating The Agency agents.
## YAML Frontmatter
```yaml
---
name: Agent Name
description: One-sentence description of agent's specialty and positioning
color: Color Name or "#hex-value"
---
```
## Document Structure
### 🧠 Identity & Memory
- **Role**: Clear role description
- **Personality**: Personality traits and communication style
- **Memory**: What the agent needs to remember and learn
- **Experience**: Domain expertise and perspective
### 🎯 Core Mission
- Core Responsibility 1 (with clear deliverables)
- Core Responsibility 2 (with clear deliverables)
- Core Responsibility 3 (with clear deliverables)
- **Default Requirement**: Always follow best practices
### 🚨 Critical Rules
Domain-specific rules and constraints that define how the agent operates.
### 📋 Technical Deliverables
Concrete outputs the agent produces:
- Code examples
- Templates
- Frameworks
- Documentation
### 🔄 Workflow
Step-by-step process the agent follows:
1. Phase 1: Exploration & Research
2. Phase 2: Planning & Strategy
3. Phase 3: Execution & Implementation
4. Phase 4: Review & Optimization
### 💭 Communication Style
- How the agent communicates
- Example phrases and expression patterns
- Tone and style
### 🔄 Learning & Memory
What the agent continuously learns from:
- Success patterns
- Failure cases
- User feedback
- Domain evolution
### 🎯 Success Metrics
Quantifiable outcomes:
- Quantitative metrics (with specific values)
- Qualitative metrics
- Performance benchmarks
### 🚀 Advanced Capabilities
Advanced techniques and methods the agent masters.
## Connections
- Implements [[Agent-Design-Principles]] — structural template for the five design principles
- Used in [[Multi-Agent-Team]] — standardized agent creation
---
title: "Agent Template"
type: concept
tags: [multi-agent, agent-design, the-agency]
sources: [contributing_zh-cn, contributing-to-the-agency]
last_updated: 2026-04-24
---
# Agent Template
The standardized YAML frontmatter + structured document template for creating The Agency agents.
## YAML Frontmatter
```yaml
---
name: Agent Name
description: One-sentence description of agent's specialty and positioning
color: Color Name or "#hex-value"
---
```
## Document Structure
### 🧠 Identity & Memory
- **Role**: Clear role description
- **Personality**: Personality traits and communication style
- **Memory**: What the agent needs to remember and learn
- **Experience**: Domain expertise and perspective
### 🎯 Core Mission
- Core Responsibility 1 (with clear deliverables)
- Core Responsibility 2 (with clear deliverables)
- Core Responsibility 3 (with clear deliverables)
- **Default Requirement**: Always follow best practices
### 🚨 Critical Rules
Domain-specific rules and constraints that define how the agent operates.
### 📋 Technical Deliverables
Concrete outputs the agent produces:
- Code examples
- Templates
- Frameworks
- Documentation
### 🔄 Workflow
Step-by-step process the agent follows:
1. Phase 1: Exploration & Research
2. Phase 2: Planning & Strategy
3. Phase 3: Execution & Implementation
4. Phase 4: Review & Optimization
### 💭 Communication Style
- How the agent communicates
- Example phrases and expression patterns
- Tone and style
### 🔄 Learning & Memory
What the agent continuously learns from:
- Success patterns
- Failure cases
- User feedback
- Domain evolution
### 🎯 Success Metrics
Quantifiable outcomes:
- Quantitative metrics (with specific values)
- Qualitative metrics
- Performance benchmarks
### 🚀 Advanced Capabilities
Advanced techniques and methods the agent masters.
## Connections
- Implements [[Agent-Design-Principles]] — structural template for the five design principles
- Used in [[Multi-Agent-Team]] — standardized agent creation

54
wiki/concepts/AgentFileFormat.md
View File

@@ -1,27 +1,27 @@
---
title: "AgentFileFormat"
type: concept
tags: []
---
## Definition
Agent 定义文件采用 `.md` + YAML frontmatter 格式，是 Agency 项目与 GitHub Copilot 的共同标准文件格式。
## Core Properties
- **格式**：`Markdown 文本 + YAML frontmatter 元数据`
- **Frontmatter 字段**（典型）：`name`、`description`、`instructions`、`tools`、`model` 等
- **兼容平台**：The Agency agents、GitHub Copilot agents、Cursor（通过 `.mdc` 转换）
## Usage
1. **The Agency**：所有 agent 定义均使用此格式，存储于 `agency-agents/` 目录下
2. **GitHub Copilot**：直接读取 `.md` + YAML frontmatter，无需转换
3. **Cursor**：通过 `install.sh --tool cursor` 转换为 `.mdc` 规则文件
## Aliases
- Agent Definition Format
- Agency Agent Format
## Related
- [[GitHubCopilot]] — 使用此格式的 IDE
- [[TheAgency]] — 使用此格式的核心项目
- [[Cursor]] — 支持此格式（需转换）的 IDE
---
title: "AgentFileFormat"
type: concept
tags: []
---
## Definition
Agent 定义文件采用 `.md` + YAML frontmatter 格式，是 Agency 项目与 GitHub Copilot 的共同标准文件格式。
## Core Properties
- **格式**：`Markdown 文本 + YAML frontmatter 元数据`
- **Frontmatter 字段**（典型）：`name`、`description`、`instructions`、`tools`、`model` 等
- **兼容平台**：The Agency agents、GitHub Copilot agents、Cursor（通过 `.mdc` 转换）
## Usage
1. **The Agency**：所有 agent 定义均使用此格式，存储于 `agency-agents/` 目录下
2. **GitHub Copilot**：直接读取 `.md` + YAML frontmatter，无需转换
3. **Cursor**：通过 `install.sh --tool cursor` 转换为 `.mdc` 规则文件
## Aliases
- Agent Definition Format
- Agency Agent Format
## Related
- [[GitHubCopilot]] — 使用此格式的 IDE
- [[TheAgency]] — 使用此格式的核心项目
- [[Cursor]] — 支持此格式（需转换）的 IDE

64
wiki/concepts/Agile-Ceremonies.md
View File

@@ -1,32 +1,32 @@
---
title: "Agile Ceremonies"
type: concept
tags: []
sources: []
last_updated: 2026-04-24
---
## 定义
敏捷仪式（Agile Ceremonies）是敏捷框架中定义的固定会议和活动，目的是促进团队协作、沟通和持续改进。
## Scrum 标准仪式
- **Sprint Planning（冲刺规划）：** Sprint 开始时，确定本 Sprint 要完成的工作
- **Daily Stand-up（每日站会）：** 每天定时短会，回答三个问题：昨天完成什么、今天做什么、有什么阻碍
- 时长：15-30 分钟
- 围绕看板工具展开
- **Sprint Review（冲刺评审）：** Sprint 结束时向利益相关方演示已完成的工作
- **Sprint Retrospective（回顾会议）：** Sprint 结束时团队复盘，识别改进点
## 仪式保留策略（混合框架）
云转型团队保留 Scrum 的两个核心仪式：
- **Daily Stand-up：** 确保快速同步团队状态
- **Retrospective：** 驱动快速反馈循环，持续改进产品和开发文化
放弃 Sprint 固定节奏以允许持续变更。
## 最佳实践
- 行动项必须带负责人（Owner）
- 回顾会议输出具体可执行的改进措施
## 来源
- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
---
title: "Agile Ceremonies"
type: concept
tags: []
sources: []
last_updated: 2026-04-24
---
## 定义
敏捷仪式（Agile Ceremonies）是敏捷框架中定义的固定会议和活动，目的是促进团队协作、沟通和持续改进。
## Scrum 标准仪式
- **Sprint Planning（冲刺规划）：** Sprint 开始时，确定本 Sprint 要完成的工作
- **Daily Stand-up（每日站会）：** 每天定时短会，回答三个问题：昨天完成什么、今天做什么、有什么阻碍
- 时长：15-30 分钟
- 围绕看板工具展开
- **Sprint Review（冲刺评审）：** Sprint 结束时向利益相关方演示已完成的工作
- **Sprint Retrospective（回顾会议）：** Sprint 结束时团队复盘，识别改进点
## 仪式保留策略（混合框架）
云转型团队保留 Scrum 的两个核心仪式：
- **Daily Stand-up：** 确保快速同步团队状态
- **Retrospective：** 驱动快速反馈循环，持续改进产品和开发文化
放弃 Sprint 固定节奏以允许持续变更。
## 最佳实践
- 行动项必须带负责人（Owner）
- 回顾会议输出具体可执行的改进措施
## 来源
- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]

68
wiki/concepts/AgilePractices.md
View File

@@ -1,34 +1,34 @@
---
title: "Agile Practices"
type: concept
tags: [agile, scrum, kanban, devops]
sources: [devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin]
last_updated: 2026-04-22
---
## Summary
Agile Practices are iterative development methodologies (Scrum, Kanban) that emphasize continuous delivery, customer collaboration, and adaptability. In the DevOps context, Agile and DevOps are symbiotic — Agile focuses on iterative development while DevOps extends agility to operations, together enabling end-to-end speed and quality. Agile frameworks provide the delivery cadence while DevOps provides the operational excellence to sustain it.
## Key Frameworks
### Scrum
- Structured sprints with defined timeboxes
- Roles: Product Owner, Scrum Master, Development Team
- Ceremonies: Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective
### Kanban
- Continuous flow model (no fixed sprints)
- Visual board with WIP limits
- Focus on throughput and cycle time
## Agile + DevOps Integration
- **CI/CD as Agile Accelerators**: Automating testing and deployment shrinks feedback cycles from weeks to minutes
- **Value Stream Mapping**: Lean technique to identify and eliminate waste in Agile/DevOps workflows
- **Shift-Left**: Moving operations concerns (security, performance) into Agile sprints
## Connections
- [[DevOps Culture]] — Agile and DevOps are symbiotic; DevOps extends Agile to operations
- [[CI/CD Pipeline]] — CI/CD accelerates Agile feedback cycles
- [[Value Stream Mapping]] — Lean technique for Agile/DevOps workflow optimization
- [[Shift-Left Testing]] — Agile practice of moving testing earlier in the lifecycle
- [[Project State Management]] — [[Event Sourcing]] as an alternative to Kanban-style collaboration (see Conflict Area in overview.md)
---
title: "Agile Practices"
type: concept
tags: [agile, scrum, kanban, devops]
sources: [devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin]
last_updated: 2026-04-22
---
## Summary
Agile Practices are iterative development methodologies (Scrum, Kanban) that emphasize continuous delivery, customer collaboration, and adaptability. In the DevOps context, Agile and DevOps are symbiotic — Agile focuses on iterative development while DevOps extends agility to operations, together enabling end-to-end speed and quality. Agile frameworks provide the delivery cadence while DevOps provides the operational excellence to sustain it.
## Key Frameworks
### Scrum
- Structured sprints with defined timeboxes
- Roles: Product Owner, Scrum Master, Development Team
- Ceremonies: Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective
### Kanban
- Continuous flow model (no fixed sprints)
- Visual board with WIP limits
- Focus on throughput and cycle time
## Agile + DevOps Integration
- **CI/CD as Agile Accelerators**: Automating testing and deployment shrinks feedback cycles from weeks to minutes
- **Value Stream Mapping**: Lean technique to identify and eliminate waste in Agile/DevOps workflows
- **Shift-Left**: Moving operations concerns (security, performance) into Agile sprints
## Connections
- [[DevOps Culture]] — Agile and DevOps are symbiotic; DevOps extends Agile to operations
- [[CI/CD Pipeline]] — CI/CD accelerates Agile feedback cycles
- [[Value Stream Mapping]] — Lean technique for Agile/DevOps workflow optimization
- [[Shift-Left Testing]] — Agile practice of moving testing earlier in the lifecycle
- [[Project State Management]] — [[Event Sourcing]] as an alternative to Kanban-style collaboration (see Conflict Area in overview.md)

104
wiki/concepts/Aha-Moment.md
View File

@@ -1,52 +1,52 @@
---
title: "Aha Moment"
type: concept
tags: [sales, demo, pre-sales, b2b]
last_updated: 2026-04-25
---
## Definition
Aha Moment 是 B2B 演示中买家产生"这正是我们需要的"这一刻——是演示成功的核心衡量标准。如果演示结束那一刻未出现 Aha Moment，演示就失败了，无论功能展示多全面。
## Core Rule
**每个演示必须产生至少一个 Aha Moment。**
这不是可选项，而是必须项。如果演示结束了，买家还没有说或明显想过"这正是我们需要的"，演示就失败了。
## How to Engineer the Aha Moment
### 1. Identify the Most Impactful Capability
在演示设计阶段：
- 基于发现阶段的买家痛点，确定哪个产品能力对当前受众最具冲击力
- 不同受众 = 不同 Aha Moment 能力
### 2. Build the Narrative Arc to Peak There
- 前半部分建立情境，让买家准备好在高潮处产生共鸣
- 不要把 Aha Moment 能力藏在演示最后——它应该在买家注意力最高、耐心最好的时刻展示
### 3. Design for the Reaction
- 展示能力后，留白等待买家反应
- 如果没有反应，追加一个问题来引导："这对您来说重要吗？"
- 不要自己填补沉默
## Examples
### Before (Weak Demo)
> "让我展示我们的完整功能集：仪表板、分析、报表、工作流..."
### After (Aha Moment Engineering)
> "您提到您的团队每周花 6 小时手动协调三个系统之间的数据。让我向您展示当这个过程自动化时是什么样..."
>
> *[展示结果仪表盘]*
>
> "这是自动化后的协调视图——所有不一致实时高亮，数据流跨系统同步，差异报告一键生成。您提到您每周花 6 小时做这个..."
>
> *[买家停顿，产生 Aha Moment]*
## Connections
- [[DemoEngineering]] — Aha Moment 是 Demo Engineering 方法论的核心成功指标
- [[SalesEngineer]] — 规划并实现 Aha Moment 是 Sales Engineer 的关键职责
- [[POC-Scoping]] — POC 成功标准本质上也是一种 Aha Moment（证明核心能力可行）
## Contradictions
- 无已知冲突
---
title: "Aha Moment"
type: concept
tags: [sales, demo, pre-sales, b2b]
last_updated: 2026-04-25
---
## Definition
Aha Moment 是 B2B 演示中买家产生"这正是我们需要的"这一刻——是演示成功的核心衡量标准。如果演示结束那一刻未出现 Aha Moment，演示就失败了，无论功能展示多全面。
## Core Rule
**每个演示必须产生至少一个 Aha Moment。**
这不是可选项，而是必须项。如果演示结束了，买家还没有说或明显想过"这正是我们需要的"，演示就失败了。
## How to Engineer the Aha Moment
### 1. Identify the Most Impactful Capability
在演示设计阶段：
- 基于发现阶段的买家痛点，确定哪个产品能力对当前受众最具冲击力
- 不同受众 = 不同 Aha Moment 能力
### 2. Build the Narrative Arc to Peak There
- 前半部分建立情境，让买家准备好在高潮处产生共鸣
- 不要把 Aha Moment 能力藏在演示最后——它应该在买家注意力最高、耐心最好的时刻展示
### 3. Design for the Reaction
- 展示能力后，留白等待买家反应
- 如果没有反应，追加一个问题来引导："这对您来说重要吗？"
- 不要自己填补沉默
## Examples
### Before (Weak Demo)
> "让我展示我们的完整功能集：仪表板、分析、报表、工作流..."
### After (Aha Moment Engineering)
> "您提到您的团队每周花 6 小时手动协调三个系统之间的数据。让我向您展示当这个过程自动化时是什么样..."
>
> *[展示结果仪表盘]*
>
> "这是自动化后的协调视图——所有不一致实时高亮，数据流跨系统同步，差异报告一键生成。您提到您每周花 6 小时做这个..."
>
> *[买家停顿，产生 Aha Moment]*
## Connections
- [[DemoEngineering]] — Aha Moment 是 Demo Engineering 方法论的核心成功指标
- [[SalesEngineer]] — 规划并实现 Aha Moment 是 Sales Engineer 的关键职责
- [[POC-Scoping]] — POC 成功标准本质上也是一种 Aha Moment（证明核心能力可行）
## Contradictions
- 无已知冲突

58
wiki/concepts/Ai-Powered-Digest.md
View File

@@ -1,29 +1,29 @@
---
title: "AI-Powered Digest"
type: concept
tags: []
last_updated: 2026-04-22
---
## Definition
AI-Powered Digest（AI 驱动的自动化摘要）是一种由 AI Agent 主导的信息获取-整理-格式化-投递模式。核心特征：定时/事件触发 → 自动抓取原始数据 → AI 理解与结构化 → 投递到即时通讯工具 → 用户无需主动搜索。
## Pattern Components
1. **Trigger**：定时（Cron Job）或事件驱动
2. **Collection**：通过 API/Web 搜索/爬虫获取原始数据
3. **Processing**：AI 理解内容，提取关键信息
4. **Formatting**：结构化摘要（分类、排序、highlight）
5. **Delivery**：推送至 Telegram/Slack/Email 等即时渠道
## Variants in the Wiki
| 场景 | 来源 | Trigger | 内容源 |
|------|------|---------|--------|
| 财报追踪 | [[earnings-tracker]] | Cron Job（周日扫描+财报发布后触发） | 财报日历+搜索结果 |
| YouTube 摘要 | [[daily-youtube-digest]] | Cron Job（频道更新检测） | 视频转录+摘要 |
| 晨报 | [[self-healing-home-server]] | Cron Job（每日 8AM） | 天气/日历/系统状态 |
## Related Concepts
- [[Cron Job]] — 定时触发的技术基础
- [[Telegram Topic]] — 投递渠道
- [[Daily-Digest]] — Digest 模式在 YouTube 场景的具体化
- [[Earnings Calendar]] — Digest 模式的金融场景应用
---
title: "AI-Powered Digest"
type: concept
tags: []
last_updated: 2026-04-22
---
## Definition
AI-Powered Digest（AI 驱动的自动化摘要）是一种由 AI Agent 主导的信息获取-整理-格式化-投递模式。核心特征：定时/事件触发 → 自动抓取原始数据 → AI 理解与结构化 → 投递到即时通讯工具 → 用户无需主动搜索。
## Pattern Components
1. **Trigger**：定时（Cron Job）或事件驱动
2. **Collection**：通过 API/Web 搜索/爬虫获取原始数据
3. **Processing**：AI 理解内容，提取关键信息
4. **Formatting**：结构化摘要（分类、排序、highlight）
5. **Delivery**：推送至 Telegram/Slack/Email 等即时渠道
## Variants in the Wiki
| 场景 | 来源 | Trigger | 内容源 |
|------|------|---------|--------|
| 财报追踪 | [[earnings-tracker]] | Cron Job（周日扫描+财报发布后触发） | 财报日历+搜索结果 |
| YouTube 摘要 | [[daily-youtube-digest]] | Cron Job（频道更新检测） | 视频转录+摘要 |
| 晨报 | [[self-healing-home-server]] | Cron Job（每日 8AM） | 天气/日历/系统状态 |
## Related Concepts
- [[Cron Job]] — 定时触发的技术基础
- [[Telegram Topic]] — 投递渠道
- [[Daily-Digest]] — Digest 模式在 YouTube 场景的具体化
- [[Earnings Calendar]] — Digest 模式的金融场景应用

136
wiki/concepts/Alerting.md
View File

@@ -1,68 +1,68 @@
---
title: "Alerting"
type: concept
tags: [Monitoring, Automation, Notification, Threshold]
sources: [dynamic-dashboard]
last_updated: 2026-04-22
---
## Definition
**Alerting** 是在指标超过预设阈值时，主动通知相关人员的机制。与被动查询仪表盘不同，告警实现"异常来找人"而非"人去查异常"的范式转变。
## 核心洞察
> "指标异常不是被看到，而是被通知"
## 告警生命周期
```
Threshold Exceeded → Alert Triggered → Notification Sent → Acknowledged → Resolved
│ │ │ │ │
监控规则 事件生成 多渠道推送 用户确认 问题修复
```
## 告警类型
1. **阈值告警**
- 固定阈值: `if cpu > 90% → alert`
- 变化率: `if stars_change > 50/hour → alert`
2. **趋势告警**
- 异常检测: Twitter 负面情绪突增
- 预测告警: 基于历史趋势预测故障
3. **复合告警**
- 多条件组合: `if cpu > 80% AND disk < 20% → alert`
## 告警渠道
| 渠道 | 适用场景 | 优势 |
|------|----------|------|
| Discord | 团队协作/实时讨论 | 频道分类、@mention |
| Email | 正式记录/异步通知 | 归档、可搜索 |
| Slack | 企业团队集成 | 频道/线程组织 |
| Telegram | 个人/移动优先 | 即时推送 |
| SMS | 紧急故障 | 无网络依赖 |
## 告警疲劳管理
- **聚合**: 相似告警合并，减少噪音
- **静默期**: 维护窗口自动静默
- **升级**: 无人响应时升级通知级别
- **去重**: 同一问题不重复通知
## 与 Prometheus Alertmanager 的对比
| 维度 | 自定义 Alerting | Prometheus Alertmanager |
|------|----------------|------------------------|
| 触发规则 | 自然语言描述 | PromQL 表达式 |
| 数据源 | 任意 API | Prometheus metrics |
| 灵活性 | 高（对话式调整） | 中（规则编写） |
| 集成成本 | 低 | 中 |
## Related Concepts
- [[Dynamic-Dashboard]] — 告警是动态仪表盘的核心输出
- [[Scheduled-Task-Flywheel]] — 定时检查是告警的前置条件
- [[Prometheus告警规则]] — Prometheus 生态的规则定义方式
---
title: "Alerting"
type: concept
tags: [Monitoring, Automation, Notification, Threshold]
sources: [dynamic-dashboard]
last_updated: 2026-04-22
---
## Definition
**Alerting** 是在指标超过预设阈值时，主动通知相关人员的机制。与被动查询仪表盘不同，告警实现"异常来找人"而非"人去查异常"的范式转变。
## 核心洞察
> "指标异常不是被看到，而是被通知"
## 告警生命周期
```
Threshold Exceeded → Alert Triggered → Notification Sent → Acknowledged → Resolved
│ │ │ │ │
监控规则 事件生成 多渠道推送 用户确认 问题修复
```
## 告警类型
1. **阈值告警**
- 固定阈值: `if cpu > 90% → alert`
- 变化率: `if stars_change > 50/hour → alert`
2. **趋势告警**
- 异常检测: Twitter 负面情绪突增
- 预测告警: 基于历史趋势预测故障
3. **复合告警**
- 多条件组合: `if cpu > 80% AND disk < 20% → alert`
## 告警渠道
| 渠道 | 适用场景 | 优势 |
|------|----------|------|
| Discord | 团队协作/实时讨论 | 频道分类、@mention |
| Email | 正式记录/异步通知 | 归档、可搜索 |
| Slack | 企业团队集成 | 频道/线程组织 |
| Telegram | 个人/移动优先 | 即时推送 |
| SMS | 紧急故障 | 无网络依赖 |
## 告警疲劳管理
- **聚合**: 相似告警合并，减少噪音
- **静默期**: 维护窗口自动静默
- **升级**: 无人响应时升级通知级别
- **去重**: 同一问题不重复通知
## 与 Prometheus Alertmanager 的对比
| 维度 | 自定义 Alerting | Prometheus Alertmanager |
|------|----------------|------------------------|
| 触发规则 | 自然语言描述 | PromQL 表达式 |
| 数据源 | 任意 API | Prometheus metrics |
| 灵活性 | 高（对话式调整） | 中（规则编写） |
| 集成成本 | 低 | 中 |
## Related Concepts
- [[Dynamic-Dashboard]] — 告警是动态仪表盘的核心输出
- [[Scheduled-Task-Flywheel]] — 定时检查是告警的前置条件
- [[Prometheus告警规则]] — Prometheus 生态的规则定义方式

96
wiki/concepts/Algorithm-Agility.md
View File

@@ -1,48 +1,48 @@
---
title: "Algorithm-Agility"
type: concept
tags: [cryptography, post-quantum, future-proof]
sources: [agentic-identity-trust.md]
last_updated: 2026-04-25
---
## Definition
Algorithm-Agility（算法敏捷性）是一种密码学系统设计原则——将密码学算法作为可替换参数抽象，而非硬编码选择，从而使系统能够在不破坏现有身份链的前提下完成算法升级（如从经典加密迁移到后量子加密）。
## Motivation
当前使用的 Ed25519/ECDSA 等经典签名算法面临量子计算威胁。当 NIST 后量子标准（ML-DSA、ML-KEM、SLH-DSA）成熟并部署时，需要确保：
- 历史签名的身份链仍可验证
- 无需重新颁发所有现有凭证
- 迁移过程平滑，无需停机
## Design Pattern
```python
# 差的实践：硬编码算法
signature = ed25519.sign(private_key, payload)
# 好的实践：算法作为参数
class IdentityVerifier:
def verify(self, payload, signature, algorithm="Ed25519"):
impl = self._get_implementation(algorithm)
return impl.verify(self.public_key, payload, signature)
```
## Hybrid Scheme（过渡期策略）
在经典算法向量子安全算法迁移期间，使用混合签名：
```
hybrid_signature = concat(
classical_signature(Ed25519, payload),
post_quantum_signature(ML-DSA, payload)
)
```
## Relationships
- [[Zero-Trust]]：Algorithm-Agility 确保 Zero-Trust 基础设施在后量子时代仍可用
- [[Evidence-Chain]]：历史 Evidence-Chain 记录必须在新算法体系下仍可独立验证
## Sources
- [[agentic-identity-trust.md]]
---
title: "Algorithm-Agility"
type: concept
tags: [cryptography, post-quantum, future-proof]
sources: [agentic-identity-trust.md]
last_updated: 2026-04-25
---
## Definition
Algorithm-Agility（算法敏捷性）是一种密码学系统设计原则——将密码学算法作为可替换参数抽象，而非硬编码选择，从而使系统能够在不破坏现有身份链的前提下完成算法升级（如从经典加密迁移到后量子加密）。
## Motivation
当前使用的 Ed25519/ECDSA 等经典签名算法面临量子计算威胁。当 NIST 后量子标准（ML-DSA、ML-KEM、SLH-DSA）成熟并部署时，需要确保：
- 历史签名的身份链仍可验证
- 无需重新颁发所有现有凭证
- 迁移过程平滑，无需停机
## Design Pattern
```python
# 差的实践：硬编码算法
signature = ed25519.sign(private_key, payload)
# 好的实践：算法作为参数
class IdentityVerifier:
def verify(self, payload, signature, algorithm="Ed25519"):
impl = self._get_implementation(algorithm)
return impl.verify(self.public_key, payload, signature)
```
## Hybrid Scheme（过渡期策略）
在经典算法向量子安全算法迁移期间，使用混合签名：
```
hybrid_signature = concat(
classical_signature(Ed25519, payload),
post_quantum_signature(ML-DSA, payload)
)
```
## Relationships
- [[Zero-Trust]]：Algorithm-Agility 确保 Zero-Trust 基础设施在后量子时代仍可用
- [[Evidence-Chain]]：历史 Evidence-Chain 记录必须在新算法体系下仍可独立验证
## Sources
- [[agentic-identity-trust.md]]

136
wiki/concepts/Amazon-EKS.md
View File

@@ -1,68 +1,68 @@
---
title: "Amazon EKS"
type: concept
tags: [AWS, Kubernetes, 托管服务, 容器编排]
sources: [ctp-topic-70-eks-deployment-using-iac, public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks, ctp-topic-59-achieving-reliability-with-amazon-eks, ctp-topic-64-scaling-out-with-amazon-eks]
last_updated: 2026-04-24
---
# Amazon EKS
## Overview
Amazon Elastic Kubernetes Service (EKS) 是 AWS 提供的托管 Kubernetes 服务，提供完全托管的控制平面，支持零停机滚动部署和 Worker Node 自动扩缩容。
## Key Features
- **完全托管控制平面**：AWS 自动管理 Kubernetes Control Plane 的可用性和扩展性
- **零停机滚动部署**：Worker Node 更新时实现零停机
- **IAM RBAC Mapping**：通过最小权限原则控制 EKS 集群访问
- **多可用区高可用**：自动跨多个 AZ 部署 Control Plane
- **与 AWS 服务集成**：VPC、CNI、IAM、CloudWatch、ALB 等原生集成
## Deployment Methods
### Terraform
通过 `tera-grant.scl` 文件定义集群参数：
- 环境变量配置
- EKS 集群版本
- Worker Node 类型（CPU/GPU/Default）
- AWS Secret Manager 集成（工程联系人通知）
### AWS Service Catalog
通过产品组合模块化部署：
- 版本选择
- Worker Node 类型配置
- 更精细的安全和权限控制
## Networking
### EMI (ENI Multi-IP)
自定义网络解决方案，解决 VPC CIDR 限制：
- 为 Pod 分配额外 IP 地址
- 通过虚拟弹性网络接口（ENI）实现
- 支持更高的 Pod 密度
### ALB Ingress Controller
AWS Load Balancer Controller 集成：
- 管理 Application Load Balancer 资源
- 实现 Kubernetes Service 的七层负载均衡
- 自动配置路由规则
## Autoscaling
### Cluster Autoscaler
Kubernetes Cluster Autoscaler：
- 根据资源需求自动扩缩 Worker Node
- 与 AWS Auto Scaling Groups 集成
- 未来计划引入 Carpenter 实现更高效的实例类型创建
## Monitoring
- **CloudWatch Agent + FluentBit**：以 DaemonSet 方式部署，收集日志和指标
- **Container Insights**：发布容器级别指标到 CloudWatch
- **AWS OpenTelemetry**：统一的可观测性数据采集方案
- **Grafana**：通过模板化仪表盘可视化指标
## Related Concepts
- [[Kubernetes]]：EKS 的底层技术
- [[Infrastructure as Code]]：EKS 部署的推荐方式
- [[AWS Service Catalog]]：EKS 部署的 Service Catalog 方式
- [[Cluster Autoscaler]]：Worker Node 自动扩缩容
- [[EMI]]：EKS 自定义网络方案
- [[CloudWatch Container Insights]]：EKS 监控方案
- [[AWS OpenTelemetry]]：可观测性数据采集
---
title: "Amazon EKS"
type: concept
tags: [AWS, Kubernetes, 托管服务, 容器编排]
sources: [ctp-topic-70-eks-deployment-using-iac, public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks, ctp-topic-59-achieving-reliability-with-amazon-eks, ctp-topic-64-scaling-out-with-amazon-eks]
last_updated: 2026-04-24
---
# Amazon EKS
## Overview
Amazon Elastic Kubernetes Service (EKS) 是 AWS 提供的托管 Kubernetes 服务，提供完全托管的控制平面，支持零停机滚动部署和 Worker Node 自动扩缩容。
## Key Features
- **完全托管控制平面**：AWS 自动管理 Kubernetes Control Plane 的可用性和扩展性
- **零停机滚动部署**：Worker Node 更新时实现零停机
- **IAM RBAC Mapping**：通过最小权限原则控制 EKS 集群访问
- **多可用区高可用**：自动跨多个 AZ 部署 Control Plane
- **与 AWS 服务集成**：VPC、CNI、IAM、CloudWatch、ALB 等原生集成
## Deployment Methods
### Terraform
通过 `tera-grant.scl` 文件定义集群参数：
- 环境变量配置
- EKS 集群版本
- Worker Node 类型（CPU/GPU/Default）
- AWS Secret Manager 集成（工程联系人通知）
### AWS Service Catalog
通过产品组合模块化部署：
- 版本选择
- Worker Node 类型配置
- 更精细的安全和权限控制
## Networking
### EMI (ENI Multi-IP)
自定义网络解决方案，解决 VPC CIDR 限制：
- 为 Pod 分配额外 IP 地址
- 通过虚拟弹性网络接口（ENI）实现
- 支持更高的 Pod 密度
### ALB Ingress Controller
AWS Load Balancer Controller 集成：
- 管理 Application Load Balancer 资源
- 实现 Kubernetes Service 的七层负载均衡
- 自动配置路由规则
## Autoscaling
### Cluster Autoscaler
Kubernetes Cluster Autoscaler：
- 根据资源需求自动扩缩 Worker Node
- 与 AWS Auto Scaling Groups 集成
- 未来计划引入 Carpenter 实现更高效的实例类型创建
## Monitoring
- **CloudWatch Agent + FluentBit**：以 DaemonSet 方式部署，收集日志和指标
- **Container Insights**：发布容器级别指标到 CloudWatch
- **AWS OpenTelemetry**：统一的可观测性数据采集方案
- **Grafana**：通过模板化仪表盘可视化指标
## Related Concepts
- [[Kubernetes]]：EKS 的底层技术
- [[Infrastructure as Code]]：EKS 部署的推荐方式
- [[AWS Service Catalog]]：EKS 部署的 Service Catalog 方式
- [[Cluster Autoscaler]]：Worker Node 自动扩缩容
- [[EMI]]：EKS 自定义网络方案
- [[CloudWatch Container Insights]]：EKS 监控方案
- [[AWS OpenTelemetry]]：可观测性数据采集

78
wiki/concepts/AmbientMessageMonitoring.md
View File

@@ -1,39 +1,39 @@
---
title: "Ambient Message Monitoring"
type: concept
tags: []
sources: []
last_updated: 2026-04-22
---
# Ambient Message Monitoring
## Definition
Agent 被动监听消息流（iMessage/SMS/Telegram 等），在识别到可执行模式（如预约确认、承诺回复、活动变更）时自动采取行动，无需用户主动请求。
## How It Works
1. **定时轮询**：每 N 分钟（典型 15 分钟）检查新消息
2. **模式识别**：检测预约类文本（如 "confirmed for...", "moved to Saturday at 3pm"）
3. **自动行动**：创建日历事件 → 添加行车缓冲 → 推送确认消息
4. **承诺追踪**：检测承诺类文本（如 "I'll send that by Friday"）→ 创建待办提醒
## Key Properties
- **被动**：Agent 主动感知，用户无需发起请求
- **上下文感知**：理解对话意图，而非机械关键词匹配
- **行动闭环**：从识别 → 创建事件 → 通知伴侣，全自动完成
## Comparison
| | Active（主动请求） | Ambient（环境感知） |
|---|---|---|
| 触发方式 | 用户说"创建日历事件" | Agent 自动检测到预约后行动 |
| 用户负担 | 高（需主动指令） | 低（零摩擦） |
| 覆盖面 | 只覆盖被请求的事项 | 覆盖所有对话中的可执行项 |
## Related Concepts
- [[Morning Briefing]]：Ambient Monitoring 的输出之一
- [[Cron Job]]：Ambient Monitoring 的底层调度机制
- [[Second Brain]]：Ambient Monitoring 的认知增强效果
## Related Sources
- [[family-calendar-household-assistant]] — 主要来源，牙医预约短信自动创建日历事件案例
- [[n8n-workflow-orchestration]] — n8n Webhook 触发机制对比
---
title: "Ambient Message Monitoring"
type: concept
tags: []
sources: []
last_updated: 2026-04-22
---
# Ambient Message Monitoring
## Definition
Agent 被动监听消息流（iMessage/SMS/Telegram 等），在识别到可执行模式（如预约确认、承诺回复、活动变更）时自动采取行动，无需用户主动请求。
## How It Works
1. **定时轮询**：每 N 分钟（典型 15 分钟）检查新消息
2. **模式识别**：检测预约类文本（如 "confirmed for...", "moved to Saturday at 3pm"）
3. **自动行动**：创建日历事件 → 添加行车缓冲 → 推送确认消息
4. **承诺追踪**：检测承诺类文本（如 "I'll send that by Friday"）→ 创建待办提醒
## Key Properties
- **被动**：Agent 主动感知，用户无需发起请求
- **上下文感知**：理解对话意图，而非机械关键词匹配
- **行动闭环**：从识别 → 创建事件 → 通知伴侣，全自动完成
## Comparison
| | Active（主动请求） | Ambient（环境感知） |
|---|---|---|
| 触发方式 | 用户说"创建日历事件" | Agent 自动检测到预约后行动 |
| 用户负担 | 高（需主动指令） | 低（零摩擦） |
| 覆盖面 | 只覆盖被请求的事项 | 覆盖所有对话中的可执行项 |
## Related Concepts
- [[Morning Briefing]]：Ambient Monitoring 的输出之一
- [[Cron Job]]：Ambient Monitoring 的底层调度机制
- [[Second Brain]]：Ambient Monitoring 的认知增强效果
## Related Sources
- [[family-calendar-household-assistant]] — 主要来源，牙医预约短信自动创建日历事件案例
- [[n8n-workflow-orchestration]] — n8n Webhook 触发机制对比

126
wiki/concepts/Analogy-as-Straitjacket.md
View File

@@ -1,63 +1,63 @@
---
title: "Analogy as Straitjacket"
type: concept
tags:
- "Conceptual Thinking"
- "AI Tooling Design"
last_updated: 2026-04-13
---
# Analogy as Straitjacket（类比作为束缚）
## Definition
类比是探索新领域的自然方式——通过将未知映射到已知，降低认知成本并借用已有的理解框架。然而，一旦深度理解形成后仍固守类比，类比就会从**认知杠杆**转变为**思维枷锁**，阻碍更深层次的洞察和更好的替代设计方案。
## Mechanism
```
阶段1: 类比作为杠杆
- 借用已知领域的框架理解新领域
- 提供初始认知入口
- 帮助建立初步直觉
阶段2: 深度理解形成
- 新领域有了独立的理解框架
- 类比不再提供额外价值
- 开始出现失配和不精确
阶段3: 类比成为束缚
- 困在类比框架中解读一切
- 难以采用不同视角
- 过度简化抹杀了复杂性
- 排挤更好的设计方案
```
## Case Study: AI Tooling
[[The Picture They Paint of You]] 指出当前 AI 工具设计中的类比困境：
**软件工厂类比**（Software Factory）：
- 将软件开发类比为工厂制造
- 导致泰勒制回归——工人被视为可替代的生产单元
- 忽视了软件工程的创造性、探索性和学习性本质
**AI SRE 的类比**：
- 将 AI SRE 类比为"替代者"或"下属"
- 暗示 SRE 工作是可以被标准化和替代的体力活
- 忽视了 SRE 中的判断力、上下文理解和从事故中学习的能力
## Core Argument
> "As much as an analogy can be a lever, it can also be a straitjacket. When you're stuck inside a model, you interpret everything in its own terms, and it becomes much harder to adopt a different perspective or to break out of the oversimplification."
更好的类比应该：
- 反映工作的真实复杂性
- 给予人类工作者应有的尊严和判断力
- 承认人类与 AI 的协作而非替代关系
- 在深度理解后能够被抛弃
## Connections
- [[Taylorism]] ← 过度类比的产物 ← Analogy as Straitjacket
- [[AI SRE]] ← 被类比框架束缚 ← Analogy as Straitjacket
- [[Software Factory]] ← 泰勒制类比 ← Analogy as Straitjacket
- [[The Picture They Paint of You]] ← 核心论点 ← Analogy as Straitjacket
## Sources
- [[the-picture-they-paint-of-you]]
---
title: "Analogy as Straitjacket"
type: concept
tags:
- "Conceptual Thinking"
- "AI Tooling Design"
last_updated: 2026-04-13
---
# Analogy as Straitjacket（类比作为束缚）
## Definition
类比是探索新领域的自然方式——通过将未知映射到已知，降低认知成本并借用已有的理解框架。然而，一旦深度理解形成后仍固守类比，类比就会从**认知杠杆**转变为**思维枷锁**，阻碍更深层次的洞察和更好的替代设计方案。
## Mechanism
```
阶段1: 类比作为杠杆
- 借用已知领域的框架理解新领域
- 提供初始认知入口
- 帮助建立初步直觉
阶段2: 深度理解形成
- 新领域有了独立的理解框架
- 类比不再提供额外价值
- 开始出现失配和不精确
阶段3: 类比成为束缚
- 困在类比框架中解读一切
- 难以采用不同视角
- 过度简化抹杀了复杂性
- 排挤更好的设计方案
```
## Case Study: AI Tooling
[[The Picture They Paint of You]] 指出当前 AI 工具设计中的类比困境：
**软件工厂类比**（Software Factory）：
- 将软件开发类比为工厂制造
- 导致泰勒制回归——工人被视为可替代的生产单元
- 忽视了软件工程的创造性、探索性和学习性本质
**AI SRE 的类比**：
- 将 AI SRE 类比为"替代者"或"下属"
- 暗示 SRE 工作是可以被标准化和替代的体力活
- 忽视了 SRE 中的判断力、上下文理解和从事故中学习的能力
## Core Argument
> "As much as an analogy can be a lever, it can also be a straitjacket. When you're stuck inside a model, you interpret everything in its own terms, and it becomes much harder to adopt a different perspective or to break out of the oversimplification."
更好的类比应该：
- 反映工作的真实复杂性
- 给予人类工作者应有的尊严和判断力
- 承认人类与 AI 的协作而非替代关系
- 在深度理解后能够被抛弃
## Connections
- [[Taylorism]] ← 过度类比的产物 ← Analogy as Straitjacket
- [[AI SRE]] ← 被类比框架束缚 ← Analogy as Straitjacket
- [[Software Factory]] ← 泰勒制类比 ← Analogy as Straitjacket
- [[The Picture They Paint of You]] ← 核心论点 ← Analogy as Straitjacket
## Sources
- [[the-picture-they-paint-of-you]]

80
wiki/concepts/Annales-School.md
View File

@@ -1,40 +1,40 @@
---
title: "Annales School"
type: concept
tags: ["historiography", "french-history", "material-culture", "longue-duree"]
sources: ["academic-historian"]
last_updated: 2026-04-25
---
## Definition
法国史学流派，以《年鉴》（*Annales d'histoire économique et sociale*，1929年创刊）为核心阵地，由马克·布洛赫（Marc Bloch）和吕西安·费弗尔（Lucien Febvre）共同创立。主张历史研究应突破传统政治军事史的局限，关注普通人的日常生活、物质条件和长期社会结构。
## Core Principles
- **物质条件优先**：在讨论政治/军事/思想之前，必须先理解经济基础、农业、贸易和技术
- **长时段视角（Longue Durée）**：历史变化发生在几十年乃至几个世纪的时间尺度上，聚焦于塑造事件发生的深层结构
- **日常生活史（*Histoire du quotidien*）**：关注饮食、服饰、建筑、信仰、恐惧——Annales 学派不只写国王和战争
- **跨学科方法**：整合地理学、经济学、社会学、人类学、人口学的方法论
- **问题导向史学**：以问题而非编年驱动历史研究
## Key Figures
- **马克·布洛赫**（Marc Bloch，1886-1944）：年鉴学派创始人之一，《封建社会》作者，二战期间参加抵抗运动后被枪决
- **吕西安·费弗尔**（Lucien Febvre，1878-1956）：年鉴学派创始人之一，专注于16世纪精神状态史
- **费尔南·布罗代尔**（Fernand Braudel，1902-1985）：年鉴学派第二代领袖，《菲利普二世时代的地中海和地中海世界》——长时段理论的奠基之作，将历史分为三个时间层次：地理时间（长时段）、社会时间（中时段）、事件时间（短时段）
- **埃马纽埃尔·勒华拉杜里**（Emmanuel Le Roy Ladurie，*Montaillou* 作者）：微观史的代表人物
## Relationship to Historiography
- **反对**：兰克学派（Rankean）聚焦政治史和伟大人物的传统史学；辉格史观（Whig History）以现代标准评判历史
- **影响**：新文化史、微观史、历史社会学、后殖民史学均受其影响
- **对话/张力**：年鉴学派有时因过度关注结构而被批评忽视个体能动性（agency），微观史（Microhistory）部分是对此的回应
## Connections
- [[Geographic-Coherence]] ← 理论关联 ← [[Annales-School]]：两者都强调物质地理条件对人类历史的约束作用
- [[academic-historian]] ← 方法论来源 ← [[Annales-School]]：Historian Agent 优先使用年鉴学派方法
- [[Longue-Duree]] ← 核心概念 ← [[Annales-School]]：长时段分析是年鉴学派最重要的方法论贡献
## Aliases
- 年鉴学派
- Annales
- Annales d'histoire économique et sociale
- Annales School of historiography
- French historical school
---
title: "Annales School"
type: concept
tags: ["historiography", "french-history", "material-culture", "longue-duree"]
sources: ["academic-historian"]
last_updated: 2026-04-25
---
## Definition
法国史学流派，以《年鉴》（*Annales d'histoire économique et sociale*，1929年创刊）为核心阵地，由马克·布洛赫（Marc Bloch）和吕西安·费弗尔（Lucien Febvre）共同创立。主张历史研究应突破传统政治军事史的局限，关注普通人的日常生活、物质条件和长期社会结构。
## Core Principles
- **物质条件优先**：在讨论政治/军事/思想之前，必须先理解经济基础、农业、贸易和技术
- **长时段视角（Longue Durée）**：历史变化发生在几十年乃至几个世纪的时间尺度上，聚焦于塑造事件发生的深层结构
- **日常生活史（*Histoire du quotidien*）**：关注饮食、服饰、建筑、信仰、恐惧——Annales 学派不只写国王和战争
- **跨学科方法**：整合地理学、经济学、社会学、人类学、人口学的方法论
- **问题导向史学**：以问题而非编年驱动历史研究
## Key Figures
- **马克·布洛赫**（Marc Bloch，1886-1944）：年鉴学派创始人之一，《封建社会》作者，二战期间参加抵抗运动后被枪决
- **吕西安·费弗尔**（Lucien Febvre，1878-1956）：年鉴学派创始人之一，专注于16世纪精神状态史
- **费尔南·布罗代尔**（Fernand Braudel，1902-1985）：年鉴学派第二代领袖，《菲利普二世时代的地中海和地中海世界》——长时段理论的奠基之作，将历史分为三个时间层次：地理时间（长时段）、社会时间（中时段）、事件时间（短时段）
- **埃马纽埃尔·勒华拉杜里**（Emmanuel Le Roy Ladurie，*Montaillou* 作者）：微观史的代表人物
## Relationship to Historiography
- **反对**：兰克学派（Rankean）聚焦政治史和伟大人物的传统史学；辉格史观（Whig History）以现代标准评判历史
- **影响**：新文化史、微观史、历史社会学、后殖民史学均受其影响
- **对话/张力**：年鉴学派有时因过度关注结构而被批评忽视个体能动性（agency），微观史（Microhistory）部分是对此的回应
## Connections
- [[Geographic-Coherence]] ← 理论关联 ← [[Annales-School]]：两者都强调物质地理条件对人类历史的约束作用
- [[academic-historian]] ← 方法论来源 ← [[Annales-School]]：Historian Agent 优先使用年鉴学派方法
- [[Longue-Duree]] ← 核心概念 ← [[Annales-School]]：长时段分析是年鉴学派最重要的方法论贡献
## Aliases
- 年鉴学派
- Annales
- Annales d'histoire économique et sociale
- Annales School of historiography
- French historical school

80
wiki/concepts/Appearance-Anxiety.md
View File

@@ -1,40 +1,40 @@
---
title: "Appearance Anxiety（容貌焦虑）"
type: concept
tags: [healthcare, compliance, medical-aesthetics, china]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Definition
"容貌焦虑"（容貌焦虑情绪/appearance anxiety）是医美广告中通过暗示不进行医美将导致负面后果，从而诱导消费者接受医美服务的营销手法。2021年起，国家市场监督管理总局（SAMR）在《医疗美容广告执法指南》中明确将制造"容貌焦虑"列为医美广告红线。
## Legal Prohibition
> "医美广告不得制造'容貌焦虑'——2021年起市场监管总局执法力度显著加强。" — SAMR《医疗美容广告执法指南》
## Prohibited Expressions
医美广告中禁止使用以下暗示负面后果的表述：
- "丑陋""不美丽""影响社交"
- "影响就业""影响感情"
- 任何暗示不进行医美将导致负面影响的表述
## Compliant Alternatives
| 违规表述 | 合规替代 |
|----------|----------|
| "现在不做，以后会后悔" | 介绍医美项目原理和技术特点 |
| "你的脸型需要改变" | 展示医师资质和机构合规证书 |
| "变美是女性的权利" | 介绍适合人群和技术安全性 |
| "再不整就晚了" | 提供科学医美知识教育 |
## Enforcement Context
2021年《医疗美容广告执法指南》发布后，市场监管部门对医美广告实施专项整治，重点打击：
- 制造容貌焦虑的广告内容
- 使用患者前后对比照片
- 虚假夸大医美效果
- 违规医美直播带货
## Related Concepts
- [[Healthcare-Marketing-Compliance]]：容貌焦虑是医美合规的核心红线
- [[SAMR]]：《医疗美容广告执法指南》的发布机构
- [[Xiaohongshu]]：小红书大规模清理医美日记类内容的重要背景
- [[Compliance-Risk-Matrix]]：制造容貌焦虑属 High Risk 级别，面临罚款+账号封禁
---
title: "Appearance Anxiety（容貌焦虑）"
type: concept
tags: [healthcare, compliance, medical-aesthetics, china]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Definition
"容貌焦虑"（容貌焦虑情绪/appearance anxiety）是医美广告中通过暗示不进行医美将导致负面后果，从而诱导消费者接受医美服务的营销手法。2021年起，国家市场监督管理总局（SAMR）在《医疗美容广告执法指南》中明确将制造"容貌焦虑"列为医美广告红线。
## Legal Prohibition
> "医美广告不得制造'容貌焦虑'——2021年起市场监管总局执法力度显著加强。" — SAMR《医疗美容广告执法指南》
## Prohibited Expressions
医美广告中禁止使用以下暗示负面后果的表述：
- "丑陋""不美丽""影响社交"
- "影响就业""影响感情"
- 任何暗示不进行医美将导致负面影响的表述
## Compliant Alternatives
| 违规表述 | 合规替代 |
|----------|----------|
| "现在不做，以后会后悔" | 介绍医美项目原理和技术特点 |
| "你的脸型需要改变" | 展示医师资质和机构合规证书 |
| "变美是女性的权利" | 介绍适合人群和技术安全性 |
| "再不整就晚了" | 提供科学医美知识教育 |
## Enforcement Context
2021年《医疗美容广告执法指南》发布后，市场监管部门对医美广告实施专项整治，重点打击：
- 制造容貌焦虑的广告内容
- 使用患者前后对比照片
- 虚假夸大医美效果
- 违规医美直播带货
## Related Concepts
- [[Healthcare-Marketing-Compliance]]：容貌焦虑是医美合规的核心红线
- [[SAMR]]：《医疗美容广告执法指南》的发布机构
- [[Xiaohongshu]]：小红书大规模清理医美日记类内容的重要背景
- [[Compliance-Risk-Matrix]]：制造容貌焦虑属 High Risk 级别，面临罚款+账号封禁

78
wiki/concepts/Architectural-Empathy.md
View File

@@ -1,39 +1,39 @@
---
title: "Architectural Empathy"
type: concept
tags: [ux-design, cultural-intelligence, design-philosophy]
sources: [specialized-cultural-intelligence-strategist]
last_updated: 2026-04-25
---
## Definition
通过结构性解决方案而非表演性行为来实现包容性的设计哲学——在系统架构层面消除排斥根源，而非在产品表面添加"看起来包容"的元素。Architectural Empathy Engine 是 [[Cultural-Intelligence-Strategist]] 的角色定位，强调同理心必须融入产品的骨架，而非仅装饰于表面。
## Core Principles
### 1. Structural > Cosmetic
- ❌ 在首页添加一张多元人群图
- ✅ 重新设计表单字段以接受全球命名结构
### 2. Precondition, Not Afterthought
- ❌ 产品上线后再考虑国际化
- ✅ 国际化是架构设计的前提条件（Global-First Architecture）
### 3. "Who is left out?" as First Question
每个工作流审查的第一个问题必须是："如果用户是神经多样性者、视障者、非西方文化背景者、或使用不同历法，这个设计还能工作吗？"
### 4. Absolute Cultural Humility
永远不声称当前知识是完整的。在为任何群体生成内容前，必须自主研究该群体的当前、尊重、赋权的表征标准。
## Relationship to Other Concepts
- [[Invisible-Exclusion]]：Architectural Empathy 的诊断对象
- [[Global-First-Architecture]]：Architectural Empathy 的实施方法
- [[Cultural-Intelligence]]：Architectural Empathy 的知识基础
## Contrast: Performative vs. Structural Empathy
| 维度 | 表演性同理心 | 结构性同理心 |
|------|------------|------------|
| 位置 | 表面层 | 架构层 |
| 效果 | 短期感知改善 | 长期用户摩擦消除 |
| 检测方式 | 多元图片存在 | APAC 用户转化率提升 |
| 维护 | 每次更新需重新添加 | 架构内建，持续有效 |
---
title: "Architectural Empathy"
type: concept
tags: [ux-design, cultural-intelligence, design-philosophy]
sources: [specialized-cultural-intelligence-strategist]
last_updated: 2026-04-25
---
## Definition
通过结构性解决方案而非表演性行为来实现包容性的设计哲学——在系统架构层面消除排斥根源，而非在产品表面添加"看起来包容"的元素。Architectural Empathy Engine 是 [[Cultural-Intelligence-Strategist]] 的角色定位，强调同理心必须融入产品的骨架，而非仅装饰于表面。
## Core Principles
### 1. Structural > Cosmetic
- ❌ 在首页添加一张多元人群图
- ✅ 重新设计表单字段以接受全球命名结构
### 2. Precondition, Not Afterthought
- ❌ 产品上线后再考虑国际化
- ✅ 国际化是架构设计的前提条件（Global-First Architecture）
### 3. "Who is left out?" as First Question
每个工作流审查的第一个问题必须是："如果用户是神经多样性者、视障者、非西方文化背景者、或使用不同历法，这个设计还能工作吗？"
### 4. Absolute Cultural Humility
永远不声称当前知识是完整的。在为任何群体生成内容前，必须自主研究该群体的当前、尊重、赋权的表征标准。
## Relationship to Other Concepts
- [[Invisible-Exclusion]]：Architectural Empathy 的诊断对象
- [[Global-First-Architecture]]：Architectural Empathy 的实施方法
- [[Cultural-Intelligence]]：Architectural Empathy 的知识基础
## Contrast: Performative vs. Structural Empathy
| 维度 | 表演性同理心 | 结构性同理心 |
|------|------------|------------|
| 位置 | 表面层 | 架构层 |
| 效果 | 短期感知改善 | 长期用户摩擦消除 |
| 检测方式 | 多元图片存在 | APAC 用户转化率提升 |
| 维护 | 每次更新需重新添加 | 架构内建，持续有效 |

158
wiki/concepts/Asset-Management.md
View File

@@ -1,79 +1,79 @@
---
title: "Asset Management"
type: concept
tags: [itsm, operations, finops]
date: 2025-03-01
---
## Definition
资产管理（Asset Management）是[[ITSM]]的核心流程之一，负责**跟踪和管理IT资产从采购到退役的完整生命周期**，优化资产利用率、控制成本并确保合规。
## Asset Lifecycle
```
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Procure │ → │ Deploy │ → │Operate │ → │Maintain │ → │ Retire │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘
↓ ↓ ↓ ↓ ↓
Purchase Provision Monitor Patch/Update Archive/
Planning & Config & Optimize & Upgrade Dispose
```
## Asset Management Focus Areas
| 领域 | 描述 |
|------|------|
| Hardware Lifecycle | 服务器、网络设备生命周期 |
| Software Licensing | 软件许可管理（SAM） |
| Cloud Optimization | 云资源成本优化 |
| Shadow IT Prevention | 影子IT发现与治理 |
| Compliance | 许可证合规审计 |
## Modern Asset Management (ITSM 2.0)
在[[ITSM 2.0]]中，资产管理由AI驱动：
### Intelligent Features
| 能力 | 描述 | 价值 |
|------|------|------|
| Automated Lifecycle Tracking | 自动追踪资产状态 | 减少人工 |
| License Optimization | 许可证使用分析 | 成本节省 |
| Usage Analytics | 利用率分析 | Rightsizing |
| Cost Forecasting | 成本预测 | 预算规划 |
| Cloud Resource Optimization | 云资源优化 | FinOps |
### Cloud-Optimized SAM (Software Asset Management)
```
Software License Usage
├── Used Licenses: 80%
├── Unused Licenses: 15%
└── Over-licensed: 5%
↓
AI Analysis
├── Reclaim unused
├── Optimize purchases
└── Prevent overruns
```
## Key Metrics
| 指标 | 描述 |
|------|------|
| Asset Utilization Rate | 资产利用率 |
| License Compliance | 许可证合规率 |
| Shadow IT Count | 影子IT数量 |
| Cost per Asset | 单资产成本 |
## Related Concepts
- [[ITSM]] — 父框架
- [[FinOps]] — 云财务管理
- [[Rightsizing]] — 资源优化
- [[Cloud-Optimization]] — 云优化
## Sources
- [[understanding-complete-itsm]] — Intelligent Asset Lifecycle Tracking
---
title: "Asset Management"
type: concept
tags: [itsm, operations, finops]
date: 2025-03-01
---
## Definition
资产管理（Asset Management）是[[ITSM]]的核心流程之一，负责**跟踪和管理IT资产从采购到退役的完整生命周期**，优化资产利用率、控制成本并确保合规。
## Asset Lifecycle
```
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Procure │ → │ Deploy │ → │Operate │ → │Maintain │ → │ Retire │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘
↓ ↓ ↓ ↓ ↓
Purchase Provision Monitor Patch/Update Archive/
Planning & Config & Optimize & Upgrade Dispose
```
## Asset Management Focus Areas
| 领域 | 描述 |
|------|------|
| Hardware Lifecycle | 服务器、网络设备生命周期 |
| Software Licensing | 软件许可管理（SAM） |
| Cloud Optimization | 云资源成本优化 |
| Shadow IT Prevention | 影子IT发现与治理 |
| Compliance | 许可证合规审计 |
## Modern Asset Management (ITSM 2.0)
在[[ITSM 2.0]]中，资产管理由AI驱动：
### Intelligent Features
| 能力 | 描述 | 价值 |
|------|------|------|
| Automated Lifecycle Tracking | 自动追踪资产状态 | 减少人工 |
| License Optimization | 许可证使用分析 | 成本节省 |
| Usage Analytics | 利用率分析 | Rightsizing |
| Cost Forecasting | 成本预测 | 预算规划 |
| Cloud Resource Optimization | 云资源优化 | FinOps |
### Cloud-Optimized SAM (Software Asset Management)
```
Software License Usage
├── Used Licenses: 80%
├── Unused Licenses: 15%
└── Over-licensed: 5%
↓
AI Analysis
├── Reclaim unused
├── Optimize purchases
└── Prevent overruns
```
## Key Metrics
| 指标 | 描述 |
|------|------|
| Asset Utilization Rate | 资产利用率 |
| License Compliance | 许可证合规率 |
| Shadow IT Count | 影子IT数量 |
| Cost per Asset | 单资产成本 |
## Related Concepts
- [[ITSM]] — 父框架
- [[FinOps]] — 云财务管理
- [[Rightsizing]] — 资源优化
- [[Cloud-Optimization]] — 云优化
## Sources
- [[understanding-complete-itsm]] — Intelligent Asset Lifecycle Tracking

70
wiki/concepts/Atomic-Commit.md
View File

@@ -1,35 +1,35 @@
---
title: "Atomic Commit"
type: concept
tags: ["git", "code-quality", "delivery-traceability"]
last_updated: 2026-04-25
---
## Definition
Atomic Commit（原子提交）是一种 Git 提交粒度原则——每次提交仅包含一个逻辑变更单元（一个清晰的改动），易于审查、回滚和溯源，不捆绑多个不相关的变更。
## Characteristics
- **单一职责**：一个 commit = 一个清晰的改动
- **可独立回滚**：回滚一个 commit 不会影响其他功能的正常运行
- **可独立审查**：reviewer 能在短时间内理解单个 commit 的意图
- **易于溯源**：通过 commit message 快速定位引入特定行为的 ticket
## Anti-patterns
| 反模式 | 描述 | 风险 |
|--------|------|------|
| Mega commit | 一次性提交大量不相关变更 | review 成本高；回滚连带损伤 |
| WIP commit | 包含 work-in-progress 代码的提交 | 污染历史，难以理解 |
| Fixup commit | 在 review 过程中不断追加修改 | 历史难以重建 |
| Bundled commit | 将多个功能捆在一个 commit 里 | 拆分困难，回滚粒度过粗 |
## Relationship to Branch Strategy
Atomic Commit 与 [[Branch-Strategy]] 共同构成 [[Jira-Git-Traceability]] 的基础：
- Branch 隔离不同任务的工作
- 每个 branch 内的 commit 进一步原子化
## Sources
- [[project-management-jira-workflow-steward]]
---
title: "Atomic Commit"
type: concept
tags: ["git", "code-quality", "delivery-traceability"]
last_updated: 2026-04-25
---
## Definition
Atomic Commit（原子提交）是一种 Git 提交粒度原则——每次提交仅包含一个逻辑变更单元（一个清晰的改动），易于审查、回滚和溯源，不捆绑多个不相关的变更。
## Characteristics
- **单一职责**：一个 commit = 一个清晰的改动
- **可独立回滚**：回滚一个 commit 不会影响其他功能的正常运行
- **可独立审查**：reviewer 能在短时间内理解单个 commit 的意图
- **易于溯源**：通过 commit message 快速定位引入特定行为的 ticket
## Anti-patterns
| 反模式 | 描述 | 风险 |
|--------|------|------|
| Mega commit | 一次性提交大量不相关变更 | review 成本高；回滚连带损伤 |
| WIP commit | 包含 work-in-progress 代码的提交 | 污染历史，难以理解 |
| Fixup commit | 在 review 过程中不断追加修改 | 历史难以重建 |
| Bundled commit | 将多个功能捆在一个 commit 里 | 拆分困难，回滚粒度过粗 |
## Relationship to Branch Strategy
Atomic Commit 与 [[Branch-Strategy]] 共同构成 [[Jira-Git-Traceability]] 的基础：
- Branch 隔离不同任务的工作
- 每个 branch 内的 commit 进一步原子化
## Sources
- [[project-management-jira-workflow-steward]]

92
wiki/concepts/Attachment-Theory.md
View File

@@ -1,46 +1,46 @@
---
title: "Attachment Theory"
type: concept
tags: []
sources: ["academic-psychologist"]
last_updated: 2026-04-20
---
## Definition
依恋理论（Attachment Theory）由 **John Bowlby** 创立，描述婴幼儿与主要照护者之间形成的情感纽带如何塑造成年后的亲密关系模式。
### 成人依恋四种类型
| 类型 | 特征 | 关系中行为表现 |
|------|------|---------------|
| **安全型（Secure）** | 信任他人，舒适亲密 | 开放沟通，冲突时能修复 |
| **焦虑型（Anxious-Preoccupied）** | 担心被抛弃，过度依赖 | 黏人、验证需求、情绪化 |
| **回避型（Dismissive-Avoidant）** | 独立优先，压抑情感 | 亲密回避，最小化关系 |
| **恐惧型（Fearful-Avoidant）** | 既渴望又害怕亲密 | 矛盾行为，墙-梯综合征 |
## Key References
- **John Bowlby**：依恋理论创始人，提出"安全基地"概念
- **Mary Ainsworth**：陌生情境实验（Strange Situation），四种依恋类型的实证识别
## Applications in Character Design
- 依恋风格决定角色在亲密关系中的**行为模式**和**触发情境**
- 安全型角色：能主动修复冲突，追求互惠
- 焦虑型角色：过度验证对方承诺，在被忽视时崩溃
- 回避型角色：在冲突升级时退缩，长期压抑情感需求
- 恐惧型角色：在渴望亲密和害怕被伤害之间持续摆荡
## Critical Limitations
- **文化中心主义**：Bowlby/Ainsworth 研究基于西方核心家庭，集体主义文化中"安全"模式可能不同
- 依恋风格不是固定的——经历（特别是新的治疗关系）可以改变依恋模式
- 简化为"类型"会忽略连续谱本质
## Connections
- [[Big-Five-Personality]]（Neuroticism 与焦虑型依恋共享情绪不稳定维度）
- [[Psychological-Profile]]（依恋风格是角色心理画像的核心组成部分）
- [[Defense-Mechanisms]]（回避型依恋与隔离/反向形成等防御机制相关）
- [[Trauma-Informed-Analysis]]（不安全依恋常源于早期创伤）
---
title: "Attachment Theory"
type: concept
tags: []
sources: ["academic-psychologist"]
last_updated: 2026-04-20
---
## Definition
依恋理论（Attachment Theory）由 **John Bowlby** 创立，描述婴幼儿与主要照护者之间形成的情感纽带如何塑造成年后的亲密关系模式。
### 成人依恋四种类型
| 类型 | 特征 | 关系中行为表现 |
|------|------|---------------|
| **安全型（Secure）** | 信任他人，舒适亲密 | 开放沟通，冲突时能修复 |
| **焦虑型（Anxious-Preoccupied）** | 担心被抛弃，过度依赖 | 黏人、验证需求、情绪化 |
| **回避型（Dismissive-Avoidant）** | 独立优先，压抑情感 | 亲密回避，最小化关系 |
| **恐惧型（Fearful-Avoidant）** | 既渴望又害怕亲密 | 矛盾行为，墙-梯综合征 |
## Key References
- **John Bowlby**：依恋理论创始人，提出"安全基地"概念
- **Mary Ainsworth**：陌生情境实验（Strange Situation），四种依恋类型的实证识别
## Applications in Character Design
- 依恋风格决定角色在亲密关系中的**行为模式**和**触发情境**
- 安全型角色：能主动修复冲突，追求互惠
- 焦虑型角色：过度验证对方承诺，在被忽视时崩溃
- 回避型角色：在冲突升级时退缩，长期压抑情感需求
- 恐惧型角色：在渴望亲密和害怕被伤害之间持续摆荡
## Critical Limitations
- **文化中心主义**：Bowlby/Ainsworth 研究基于西方核心家庭，集体主义文化中"安全"模式可能不同
- 依恋风格不是固定的——经历（特别是新的治疗关系）可以改变依恋模式
- 简化为"类型"会忽略连续谱本质
## Connections
- [[Big-Five-Personality]]（Neuroticism 与焦虑型依恋共享情绪不稳定维度）
- [[Psychological-Profile]]（依恋风格是角色心理画像的核心组成部分）
- [[Defense-Mechanisms]]（回避型依恋与隔离/反向形成等防御机制相关）
- [[Trauma-Informed-Analysis]]（不安全依恋常源于早期创伤）

70
wiki/concepts/Attach容器.md
View File

@@ -1,35 +1,35 @@
---
title: "Attach 容器"
type: concept
tags: [docker, remote-development, debugging]
last_updated: 2026-04-22
---
## Definition
将 IDE 直接连接到正在运行的 Docker 容器内部进行代码开发和调试的工作模式。
## Mechanism
1. 在已运行的 Docker 容器中安装 IDE Server 代理
2. 本地 IDE UI 通过 SSH/TCP 隧道与容器内 IDE Server 通信
3. 所有代码编辑、终端、插件均运行在容器内部
4. 容器重启后需重新 Attach
## Characteristics
- **环境完全隔离**：直接使用容器内的 Python/Node/Go 等语言环境，无需在宿主机安装
- **适合调试**：数据库、服务等依赖已在容器中运行
- **适合轻量级修改**：代码变更即时生效（取决于是否使用 Bind Mount）
- **不适合镜像重建场景**：如需重新 build Dockerfile，需退出 Attach 重建
## vs 宿主机文件模式
| 维度 | Attach 容器 | 宿主机文件 + Docker CLI |
|------|-------------|------------------------|
| 代码位置 | 容器内部 | 宿主机文件系统 |
| 环境隔离 | ✅ 完全 | ⚠️ 依赖宿主机环境 |
| 适合场景 | 调试、多语言混合 | docker-compose 编排 |
| Git 操作 | 需 SSH Agent Forwarding | 直接使用 |
## Connections
- [[Remote-SSH]] — Attach 的实现基础
- [[Bind Mount]] — 如需代码实时生效，可结合使用
- [[Docker]] — 容器平台
- [[Trae]] — 支持 Attach 容器的 IDE
---
title: "Attach 容器"
type: concept
tags: [docker, remote-development, debugging]
last_updated: 2026-04-22
---
## Definition
将 IDE 直接连接到正在运行的 Docker 容器内部进行代码开发和调试的工作模式。
## Mechanism
1. 在已运行的 Docker 容器中安装 IDE Server 代理
2. 本地 IDE UI 通过 SSH/TCP 隧道与容器内 IDE Server 通信
3. 所有代码编辑、终端、插件均运行在容器内部
4. 容器重启后需重新 Attach
## Characteristics
- **环境完全隔离**：直接使用容器内的 Python/Node/Go 等语言环境，无需在宿主机安装
- **适合调试**：数据库、服务等依赖已在容器中运行
- **适合轻量级修改**：代码变更即时生效（取决于是否使用 Bind Mount）
- **不适合镜像重建场景**：如需重新 build Dockerfile，需退出 Attach 重建
## vs 宿主机文件模式
| 维度 | Attach 容器 | 宿主机文件 + Docker CLI |
|------|-------------|------------------------|
| 代码位置 | 容器内部 | 宿主机文件系统 |
| 环境隔离 | ✅ 完全 | ⚠️ 依赖宿主机环境 |
| 适合场景 | 调试、多语言混合 | docker-compose 编排 |
| Git 操作 | 需 SSH Agent Forwarding | 直接使用 |
## Connections
- [[Remote-SSH]] — Attach 的实现基础
- [[Bind Mount]] — 如需代码实时生效，可结合使用
- [[Docker]] — 容器平台
- [[Trae]] — 支持 Attach 容器的 IDE

80
wiki/concepts/Attention-Economy.md
View File

@@ -1,40 +1,40 @@
---
title: "Attention Economy"
type: concept
tags: []
sources: []
last_updated: 2026-04-25
---
## Definition
注意力经济——在 AI 时代，注意力成为最后的竞争壁垒之一。当任何人都能编写代码或生成内容时，只有那些能够吸引并保持注意力的产品才能在市场中胜出。
## Core Properties
- 注意力是稀缺的——互联网上的信息量远超人类处理能力
- AI 正在使内容生成成本趋近于零，信息的边际成本接近零
- 在同等质量的产品中，被知晓的产品才能胜出
- 品牌、内容、产品三者的整合是捕获注意力的系统性方法
## The Moat Argument
> "注意力是最后的护城河之一。因为当任何人都能编写任何代码或构建任何软件时，哪些会获胜？是那些广为人知的产品。你可以拥有世界上最好的产品，但如果无人知晓，那么能够吸引并保持用户注意力的人将会遥遥领先于你。" — thedankoe
## Key Insight
注意力经济与 [[System-Economy]] 和 [[Brand-Environment]] 紧密相关：
- [[Brand-Environment]] 是捕获注意力的机制
- [[System-Economy]] 是通过差异化保持注意力的机制
- [[Idea-Density]]（创意密度）是内容层面吸引注意力的核心
## Related Concepts
- [[Brand-Environment]] — 注意力捕获机制
- [[System-Economy]] — 差异化保持注意力
- [[Idea-Density]] — 内容层面的注意力吸引
- [[Content-Creator]] — 注意力经济的参与者
## Sources
- [[if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间]]
---
title: "Attention Economy"
type: concept
tags: []
sources: []
last_updated: 2026-04-25
---
## Definition
注意力经济——在 AI 时代，注意力成为最后的竞争壁垒之一。当任何人都能编写代码或生成内容时，只有那些能够吸引并保持注意力的产品才能在市场中胜出。
## Core Properties
- 注意力是稀缺的——互联网上的信息量远超人类处理能力
- AI 正在使内容生成成本趋近于零，信息的边际成本接近零
- 在同等质量的产品中，被知晓的产品才能胜出
- 品牌、内容、产品三者的整合是捕获注意力的系统性方法
## The Moat Argument
> "注意力是最后的护城河之一。因为当任何人都能编写任何代码或构建任何软件时，哪些会获胜？是那些广为人知的产品。你可以拥有世界上最好的产品，但如果无人知晓，那么能够吸引并保持用户注意力的人将会遥遥领先于你。" — thedankoe
## Key Insight
注意力经济与 [[System-Economy]] 和 [[Brand-Environment]] 紧密相关：
- [[Brand-Environment]] 是捕获注意力的机制
- [[System-Economy]] 是通过差异化保持注意力的机制
- [[Idea-Density]]（创意密度）是内容层面吸引注意力的核心
## Related Concepts
- [[Brand-Environment]] — 注意力捕获机制
- [[System-Economy]] — 差异化保持注意力
- [[Idea-Density]] — 内容层面的注意力吸引
- [[Content-Creator]] — 注意力经济的参与者
## Sources
- [[if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间]]

54
wiki/concepts/Audit-Trail.md
View File

@@ -1,27 +1,27 @@
---
title: "Audit-Trail"
type: concept
tags: [observability, compliance, n8n, security]
sources: [n8n-workflow-orchestration]
last_updated: 2026-04-17
---
## Aliases
- Audit Trail
- 审计轨迹
## Definition
系统自动记录每次工作流执行的完整输入、输出和状态信息，形成可追溯的执行历史。在 n8n 中，每次工作流触发都会记录执行数据，无需额外配置即可获得完整的操作审计日志。
## Why It Matters
- **合规需求**：SOC2、ISO 27001 等框架要求记录所有敏感操作
- **故障排查**：API 调用失败时可快速定位问题
- **Agent 行为审查**：确认 Agent 实际发送了什么数据
- **数据回放**：失败的执行可重新触发
## Connections
- [[Visual-Debugging]] — 可视化调试依赖审计数据
- [[Webhook-Proxy-Pattern]] — 自动为 Webhook 调用生成审计记录
- [[n8n]] — 提供开箱即用的工作流执行审计能力
- [[Defense-in-Depth]] — 审计轨迹是纵深防御的重要组成部分
---
title: "Audit-Trail"
type: concept
tags: [observability, compliance, n8n, security]
sources: [n8n-workflow-orchestration]
last_updated: 2026-04-17
---
## Aliases
- Audit Trail
- 审计轨迹
## Definition
系统自动记录每次工作流执行的完整输入、输出和状态信息，形成可追溯的执行历史。在 n8n 中，每次工作流触发都会记录执行数据，无需额外配置即可获得完整的操作审计日志。
## Why It Matters
- **合规需求**：SOC2、ISO 27001 等框架要求记录所有敏感操作
- **故障排查**：API 调用失败时可快速定位问题
- **Agent 行为审查**：确认 Agent 实际发送了什么数据
- **数据回放**：失败的执行可重新触发
## Connections
- [[Visual-Debugging]] — 可视化调试依赖审计数据
- [[Webhook-Proxy-Pattern]] — 自动为 Webhook 调用生成审计记录
- [[n8n]] — 提供开箱即用的工作流执行审计能力
- [[Defense-in-Depth]] — 审计轨迹是纵深防御的重要组成部分

74
wiki/concepts/Automated-Health-Logging.md
View File

@@ -1,37 +1,37 @@
---
title: "Automated Health Logging"
type: concept
tags: []
sources: []
last_updated: 2026-04-22
---
# Automated Health Logging
利用 AI 自动解析自然语言输入并写入结构化健康数据日志的实践方法。
## Definition
通过自然语言接口（消息、语音、文本）收集健康数据，由 AI 自动解析提取关键实体（食物、症状、药物等）并写入结构化日志文件，减少人工录入负担。
## Key Components
1. **自然语言输入**：用户以日常语言描述，无需记忆特定格式
2. **AI 解析引擎**：提取食物名称、数量、时间、症状描述等关键信息
3. **结构化存储**：写入 Markdown/JSON 等可读且易处理的日志文件
4. **定时提醒**：Cron Job 驱动的一日多次提醒，确保数据完整性
## Comparison with Manual Logging
| 维度 | 手动记录 | 自动化日志 |
|------|---------|-----------|
| 门槛 | 需要记忆格式 | 任意自然语言 |
| 一致性 | 易遗漏 | 提醒驱动 |
| 可分析性 | 依赖用户格式化 | AI 标准化 |
| 维护成本 | 高 | 低 |
## Implementation
- [[health-symptom-tracker]]：Telegram topic → OpenClaw Agent → Markdown 日志文件
- [[habit-tracker-accountability-coach]]：类似的自动化记录模式
## Connections
- [[Food Sensitivity Tracking]] ← enabled_by ← [[Automated Health Logging]]
- [[OpenClaw]] ← powers ← [[Automated Health Logging]]
---
title: "Automated Health Logging"
type: concept
tags: []
sources: []
last_updated: 2026-04-22
---
# Automated Health Logging
利用 AI 自动解析自然语言输入并写入结构化健康数据日志的实践方法。
## Definition
通过自然语言接口（消息、语音、文本）收集健康数据，由 AI 自动解析提取关键实体（食物、症状、药物等）并写入结构化日志文件，减少人工录入负担。
## Key Components
1. **自然语言输入**：用户以日常语言描述，无需记忆特定格式
2. **AI 解析引擎**：提取食物名称、数量、时间、症状描述等关键信息
3. **结构化存储**：写入 Markdown/JSON 等可读且易处理的日志文件
4. **定时提醒**：Cron Job 驱动的一日多次提醒，确保数据完整性
## Comparison with Manual Logging
| 维度 | 手动记录 | 自动化日志 |
|------|---------|-----------|
| 门槛 | 需要记忆格式 | 任意自然语言 |
| 一致性 | 易遗漏 | 提醒驱动 |
| 可分析性 | 依赖用户格式化 | AI 标准化 |
| 维护成本 | 高 | 低 |
## Implementation
- [[health-symptom-tracker]]：Telegram topic → OpenClaw Agent → Markdown 日志文件
- [[habit-tracker-accountability-coach]]：类似的自动化记录模式
## Connections
- [[Food Sensitivity Tracking]] ← enabled_by ← [[Automated Health Logging]]
- [[OpenClaw]] ← powers ← [[Automated Health Logging]]

166
wiki/concepts/Automated-Security-Audit.md
View File

@@ -1,83 +1,83 @@
---
title: "Automated Security Audit"
tags:
- devops
- security
- automation
- compliance
- ai
created: 2026-04-25
---
# Automated Security Audit
## Definition
Automated Security Audit 是通过 AI 自动扫描 IAM 策略、网络规则和容器漏洞，**检测安全风险并自动修复**的能力。Agentic AI 持续监控安全态势，实时执行合规修复。
## Scope
| 扫描对象 | 检测内容 | 修复动作 |
|---------|---------|---------|
| IAM Policies | 过度权限、公共访问风险 | 自动限制权限 |
| Network Rules | 开放端口、安全组配置错误 | 自动收紧规则 |
| Container Images | 已知漏洞 (CVE) | 触发重建 + 更新 |
| S3 Buckets | 公开访问、数据泄露风险 | 自动阻止公共访问 |
| Firewalls | 配置错误、入站规则过宽 | 自动修正 |
## Agentic AI Security Audit 工作流
```
1. 持续扫描 → AWS Inspector / GCP Security Command Center / Azure Defender
2. 风险评估 → CVSS 评分 + 业务影响分析
3. 自动修复 → 低风险自动修复，高风险人工审批
4. 合规验证 → SOC 2 / FedRAMP / PCI DSS 持续检查
5. 报告生成 → 安全态势仪表盘 + 合规报告
```
## 与 [[DevSecOps]] 的关系
Automated Security Audit 是 [[DevSecOps]] 实践的核心组件：
```python
DevSecOps_Pipeline = {
"Build": "SAST (Static Application Security Testing)",
"Test": "DAST (Dynamic Application Security Testing)",
"Deploy": "Container Scanning ←", # 漏洞扫描
"Monitor": "Automated Security Audit ←", # ← 本页
"Respond": "自动威胁缓解"
}
```
## 示例
> Agentic AI detects an over-permissive IAM role:
> - Role: `production-app-read-all`
> - Allows: `s3:*` on `arn:aws:s3:::customer-data-*`
> - Risk: Public access enabled on bucket
> - **AI Action**:
> - Immediately restricts bucket policy
> - Notifies DevOps team via Slack
> - Creates Jira ticket for IAM review
> - Logs audit trail for compliance
## 与合规框架的关系
| 合规框架 | Agentic AI 支持方式 |
|---------|-------------------|
| SOC 2 | 持续访问审计 + 变更记录 |
| FedRAMP | 安全配置基线检查 + 报告 |
| PCI DSS | 数据访问控制 + 加密验证 |
| ISO 27001 | 风险评估 + 修复验证 |
## Related Concepts
- [[DevSecOps]] — Automated Security Audit 是 DevSecOps 的技术基础
- [[Cloud Security]] — 审计是云安全的核心实践
- [[IAM]] — 主要审计对象之一
- [[Compliance]] — 审计支持合规证明
## Related Sources
- [[how-agentic-ai-can-help-for-cloud-devops]]
- [[cloud-devop-maturity-guideline]]
---
title: "Automated Security Audit"
tags:
- devops
- security
- automation
- compliance
- ai
created: 2026-04-25
---
# Automated Security Audit
## Definition
Automated Security Audit 是通过 AI 自动扫描 IAM 策略、网络规则和容器漏洞，**检测安全风险并自动修复**的能力。Agentic AI 持续监控安全态势，实时执行合规修复。
## Scope
| 扫描对象 | 检测内容 | 修复动作 |
|---------|---------|---------|
| IAM Policies | 过度权限、公共访问风险 | 自动限制权限 |
| Network Rules | 开放端口、安全组配置错误 | 自动收紧规则 |
| Container Images | 已知漏洞 (CVE) | 触发重建 + 更新 |
| S3 Buckets | 公开访问、数据泄露风险 | 自动阻止公共访问 |
| Firewalls | 配置错误、入站规则过宽 | 自动修正 |
## Agentic AI Security Audit 工作流
```
1. 持续扫描 → AWS Inspector / GCP Security Command Center / Azure Defender
2. 风险评估 → CVSS 评分 + 业务影响分析
3. 自动修复 → 低风险自动修复，高风险人工审批
4. 合规验证 → SOC 2 / FedRAMP / PCI DSS 持续检查
5. 报告生成 → 安全态势仪表盘 + 合规报告
```
## 与 [[DevSecOps]] 的关系
Automated Security Audit 是 [[DevSecOps]] 实践的核心组件：
```python
DevSecOps_Pipeline = {
"Build": "SAST (Static Application Security Testing)",
"Test": "DAST (Dynamic Application Security Testing)",
"Deploy": "Container Scanning ←", # 漏洞扫描
"Monitor": "Automated Security Audit ←", # ← 本页
"Respond": "自动威胁缓解"
}
```
## 示例
> Agentic AI detects an over-permissive IAM role:
> - Role: `production-app-read-all`
> - Allows: `s3:*` on `arn:aws:s3:::customer-data-*`
> - Risk: Public access enabled on bucket
> - **AI Action**:
> - Immediately restricts bucket policy
> - Notifies DevOps team via Slack
> - Creates Jira ticket for IAM review
> - Logs audit trail for compliance
## 与合规框架的关系
| 合规框架 | Agentic AI 支持方式 |
|---------|-------------------|
| SOC 2 | 持续访问审计 + 变更记录 |
| FedRAMP | 安全配置基线检查 + 报告 |
| PCI DSS | 数据访问控制 + 加密验证 |
| ISO 27001 | 风险评估 + 修复验证 |
## Related Concepts
- [[DevSecOps]] — Automated Security Audit 是 DevSecOps 的技术基础
- [[Cloud Security]] — 审计是云安全的核心实践
- [[IAM]] — 主要审计对象之一
- [[Compliance]] — 审计支持合规证明
## Related Sources
- [[how-agentic-ai-can-help-for-cloud-devops]]
- [[cloud-devop-maturity-guideline]]

74
wiki/concepts/AutomationGovernance.md
View File

@@ -1,37 +1,37 @@
---
title: "AutomationGovernance"
type: concept
tags: []
last_updated: 2026-04-25
---
# AutomationGovernance（自动化治理）
## Definition
通过决策框架和标准，对业务流程自动化进行事前评估、事中监控和事后审计的完整治理体系。
## Core Framework
### Four Evaluation Dimensions
1. **Time Savings Per Month**（每月时间节省）：节省是否重复发生且数额可观；流程频率是否足以支撑自动化开销
2. **Data Criticality**（数据关键性）：是否涉及客户/财务/合同/日程记录；数据错误/延迟/重复/缺失的影响是什么
3. **External Dependency Risk**（外部依赖风险）：链条中涉及多少外部 API/服务；它们是否稳定、有文档、可观测
4. **Scalability**（可扩展性）：1x 到 100x 时，重试、去重、限流是否仍能正常工作；异常处理在量级下是否可管理
### Five Verdicts
| 裁决 | 条件 |
|------|------|
| **APPROVE** | 价值强、风险可控、架构可维护 |
| **APPROVE AS PILOT** | 价值可期但需限制试点范围 |
| **PARTIAL AUTOMATION ONLY** | 仅自动化安全段落，保留人工检查点 |
| **DEFER** | 流程不成熟、价值不明确或依赖不稳定 |
| **REJECT** | 经济价值弱或运营/合规风险不可接受 |
## Related Concepts
- [[N8nWorkflowStandard]]：n8n 编排工具的标准工作流模板
- [[DecisionFramework]]：本概念的评估维度体系
- [[ReliabilityBaseline]]：生产级工作流的可靠性最低要求
- [[IntegrationGovernance]]：集成接入的治理规范
## Sources
- [[automation-governance-architect]]（primary）
---
title: "AutomationGovernance"
type: concept
tags: []
last_updated: 2026-04-25
---
# AutomationGovernance（自动化治理）
## Definition
通过决策框架和标准，对业务流程自动化进行事前评估、事中监控和事后审计的完整治理体系。
## Core Framework
### Four Evaluation Dimensions
1. **Time Savings Per Month**（每月时间节省）：节省是否重复发生且数额可观；流程频率是否足以支撑自动化开销
2. **Data Criticality**（数据关键性）：是否涉及客户/财务/合同/日程记录；数据错误/延迟/重复/缺失的影响是什么
3. **External Dependency Risk**（外部依赖风险）：链条中涉及多少外部 API/服务；它们是否稳定、有文档、可观测
4. **Scalability**（可扩展性）：1x 到 100x 时，重试、去重、限流是否仍能正常工作；异常处理在量级下是否可管理
### Five Verdicts
| 裁决 | 条件 |
|------|------|
| **APPROVE** | 价值强、风险可控、架构可维护 |
| **APPROVE AS PILOT** | 价值可期但需限制试点范围 |
| **PARTIAL AUTOMATION ONLY** | 仅自动化安全段落，保留人工检查点 |
| **DEFER** | 流程不成熟、价值不明确或依赖不稳定 |
| **REJECT** | 经济价值弱或运营/合规风险不可接受 |
## Related Concepts
- [[N8nWorkflowStandard]]：n8n 编排工具的标准工作流模板
- [[DecisionFramework]]：本概念的评估维度体系
- [[ReliabilityBaseline]]：生产级工作流的可靠性最低要求
- [[IntegrationGovernance]]：集成接入的治理规范
## Sources
- [[automation-governance-architect]]（primary）

142
wiki/concepts/Availability.md
View File

@@ -1,71 +1,71 @@
# Availability
## Definition
Availability is the time a system remains operational and accessible to users. It is typically expressed as a percentage of uptime over a defined period (e.g., monthly or yearly).
The DevOps Maturity Model explicitly lists Availability as one of the key metrics for measuring DevOps maturity.
## Availability SLAs
Common availability targets:
| Availability | Downtime/Year | Downtime/Month | Downtime/Week |
|-------------|---------------|----------------|---------------|
| 99% | 3.65 days | 7.31 hours | 1.68 hours |
| 99.9% | 8.76 hours | 43.83 minutes | 10.08 minutes |
| 99.99% | 52.60 minutes | 4.38 minutes | 1.01 minutes |
| 99.999% | 5.26 minutes | 26.30 seconds | 6.05 seconds |
## Across DevOps Maturity Levels
| Maturity | Availability Capability |
|----------|----------------------|
| Phase 1 | Poor — reactive monitoring, siloed teams, manual processes cause frequent outages |
| Phase 2 | Improving — essential monitoring detects issues, but manual intervention required |
| Phase 3 | Better — automated infrastructure reduces human errors, faster recovery |
| Phase 4 | High — continuous monitoring for early detection, root cause analysis capability |
| Phase 5 | Max uptime — no interruptions to customer experience, rapid data-driven decisions |
## Key Practices for High Availability
### Architecture
- Redundancy at every layer
- Load balancing
- Geographic distribution
- Graceful degradation
- Circuit breakers
### Operations
- Continuous monitoring
- Automated failover
- Disaster recovery planning
- Regular maintenance windows
- Capacity planning
### Development
- Robust error handling
- Idempotent operations
- Transaction management
- Feature flags for rapid rollback
- Chaos engineering
## Relationship with Other Metrics
| Metric | Relationship with Availability |
|--------|-------------------------------|
| **MTTD** | Faster detection = shorter outage = higher availability |
| **MTTR** | Faster recovery = shorter outage = higher availability |
| **Error Budget** | Availability target defines the error budget |
| **Change Failure Rate** | Fewer failed deployments = fewer outages = higher availability |
| **Scalability** | Better scalability prevents availability degradation under load |
## Sources
- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]]
## Related Concepts
- [[concepts/High-Availability]]
- [[concepts/MTTR]]
- [[concepts/Error-Budget]]
- [[concepts/Scalability]]
- [[concepts/Disaster-Recovery]]
- [[concepts/DevOps-Maturity]]
# Availability
## Definition
Availability is the time a system remains operational and accessible to users. It is typically expressed as a percentage of uptime over a defined period (e.g., monthly or yearly).
The DevOps Maturity Model explicitly lists Availability as one of the key metrics for measuring DevOps maturity.
## Availability SLAs
Common availability targets:
| Availability | Downtime/Year | Downtime/Month | Downtime/Week |
|-------------|---------------|----------------|---------------|
| 99% | 3.65 days | 7.31 hours | 1.68 hours |
| 99.9% | 8.76 hours | 43.83 minutes | 10.08 minutes |
| 99.99% | 52.60 minutes | 4.38 minutes | 1.01 minutes |
| 99.999% | 5.26 minutes | 26.30 seconds | 6.05 seconds |
## Across DevOps Maturity Levels
| Maturity | Availability Capability |
|----------|----------------------|
| Phase 1 | Poor — reactive monitoring, siloed teams, manual processes cause frequent outages |
| Phase 2 | Improving — essential monitoring detects issues, but manual intervention required |
| Phase 3 | Better — automated infrastructure reduces human errors, faster recovery |
| Phase 4 | High — continuous monitoring for early detection, root cause analysis capability |
| Phase 5 | Max uptime — no interruptions to customer experience, rapid data-driven decisions |
## Key Practices for High Availability
### Architecture
- Redundancy at every layer
- Load balancing
- Geographic distribution
- Graceful degradation
- Circuit breakers
### Operations
- Continuous monitoring
- Automated failover
- Disaster recovery planning
- Regular maintenance windows
- Capacity planning
### Development
- Robust error handling
- Idempotent operations
- Transaction management
- Feature flags for rapid rollback
- Chaos engineering
## Relationship with Other Metrics
| Metric | Relationship with Availability |
|--------|-------------------------------|
| **MTTD** | Faster detection = shorter outage = higher availability |
| **MTTR** | Faster recovery = shorter outage = higher availability |
| **Error Budget** | Availability target defines the error budget |
| **Change Failure Rate** | Fewer failed deployments = fewer outages = higher availability |
| **Scalability** | Better scalability prevents availability degradation under load |
## Sources
- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]]
## Related Concepts
- [[concepts/High-Availability]]
- [[concepts/MTTR]]
- [[concepts/Error-Budget]]
- [[concepts/Scalability]]
- [[concepts/Disaster-Recovery]]
- [[concepts/DevOps-Maturity]]

118
wiki/concepts/BEATS.md
View File

@@ -1,59 +1,59 @@
---
title: "BEATS"
type: concept
tags: [DevOps, Observability, Logging, OpenSource]
sources: [ctp-topic-54-esm-saas-log-analytics]
last_updated: 2026-04-25
---
# BEATS
**BEATS** 是 Elastic 公司开发的轻量级开源日志与指标数据采集代理家族，属于 ELK Stack 的数据采集层。名称来自 "Beats" 系列工具（Filebeat、Metricbeat、Packetbeat 等）。
## Core Concept
*"The application collects your log, it's called the BEATS."* — Jackie
BEATS 代理部署在应用侧，轻量级运行，持续将日志数据推送至 Logstash 或 Elasticsearch/OpenSearch。
## Member Tools
| Tool | Purpose |
|------|---------|
| **Filebeat** | 日志文件采集（最常用），支持容器环境（Kubernetes DaemonSet） |
| **Metricbeat** | 系统和服务指标采集 |
| **Packetbeat** | 网络数据包分析 |
| **Heartbeat** | 站点可用性探测 |
| **Auditbeat** | Linux 审计框架数据 |
| **Journalbeat** | systemd journal 采集 |
## Use in ELK Architecture
```
应用层 (Application VPC)
└── Filebeat (容器/DaemonSet) → 持续采集日志文件
↓
日志层 (Logging VPC)
└── Logstash → 解析和转换字段
↓
└── Elasticsearch/OpenSearch → 存储
↓
└── Kibana → 可视化
```
## Key Claims
- Filebeat 是在 Kubernetes 容器环境中部署日志采集的首选方案
- BEATS 代理轻量、低资源占用，适合在每个应用节点部署
- Filebeat 支持多行日志合并（如 Java Stack Trace）和多种日志格式解析
## Related Concepts
- [[ELK-Stack]]：BEATS 是 ELK 栈的采集层
- [[Logstash]]：BEATS 采集的数据通常先推送至 Logstash 进行处理
- [[OpenSearch]]：Filebeat 可直接推送至 OpenSearch，无需 Logstash
- [[Centralized-Logging]]：BEATS 是集中式日志采集的重要组件
## Sources
- [[ctp-topic-54-esm-saas-log-analytics]]
---
title: "BEATS"
type: concept
tags: [DevOps, Observability, Logging, OpenSource]
sources: [ctp-topic-54-esm-saas-log-analytics]
last_updated: 2026-04-25
---
# BEATS
**BEATS** 是 Elastic 公司开发的轻量级开源日志与指标数据采集代理家族，属于 ELK Stack 的数据采集层。名称来自 "Beats" 系列工具（Filebeat、Metricbeat、Packetbeat 等）。
## Core Concept
*"The application collects your log, it's called the BEATS."* — Jackie
BEATS 代理部署在应用侧，轻量级运行，持续将日志数据推送至 Logstash 或 Elasticsearch/OpenSearch。
## Member Tools
| Tool | Purpose |
|------|---------|
| **Filebeat** | 日志文件采集（最常用），支持容器环境（Kubernetes DaemonSet） |
| **Metricbeat** | 系统和服务指标采集 |
| **Packetbeat** | 网络数据包分析 |
| **Heartbeat** | 站点可用性探测 |
| **Auditbeat** | Linux 审计框架数据 |
| **Journalbeat** | systemd journal 采集 |
## Use in ELK Architecture
```
应用层 (Application VPC)
└── Filebeat (容器/DaemonSet) → 持续采集日志文件
↓
日志层 (Logging VPC)
└── Logstash → 解析和转换字段
↓
└── Elasticsearch/OpenSearch → 存储
↓
└── Kibana → 可视化
```
## Key Claims
- Filebeat 是在 Kubernetes 容器环境中部署日志采集的首选方案
- BEATS 代理轻量、低资源占用，适合在每个应用节点部署
- Filebeat 支持多行日志合并（如 Java Stack Trace）和多种日志格式解析
## Related Concepts
- [[ELK-Stack]]：BEATS 是 ELK 栈的采集层
- [[Logstash]]：BEATS 采集的数据通常先推送至 Logstash 进行处理
- [[OpenSearch]]：Filebeat 可直接推送至 OpenSearch，无需 Logstash
- [[Centralized-Logging]]：BEATS 是集中式日志采集的重要组件
## Sources
- [[ctp-topic-54-esm-saas-log-analytics]]

80
wiki/concepts/BI平台.md
View File

@@ -1,40 +1,40 @@
---
title: "BI平台"
type: concept
aliases:
- BI Platform
- Business Intelligence Platform
- 数据分析平台
tags: [bi, data, visualization, analytics]
date: 2026-04-14
---
# BI平台
## Definition
**BI 平台**（Business Intelligence Platform）是一种软件系统，用于从企业数据中提取洞察、支持决策制定。核心功能包括：数据连接与整合、SQL 查询与探索、多样化图表可视化、交互式仪表盘构建、数据驱动报警。
## Key Capabilities
1. **多数据源连接**: 支持 SQL 数据库、API、文件导入等多种数据源
2. **SQL 探索**: 内置 SQL 查询编辑器，支持即席分析
3. **图表可视化**: 提供折线图、柱状图、饼图、地理图、热力图等多样化图表
4. **仪表盘构建**: 将多个图表组合为仪表盘，支持筛选和交互
5. **权限管理**: 基于角色的访问控制（RBAC）
## Wiki 中的相关工具
| 工具 | 类型 | 特点 | 部署方式 |
|------|------|------|----------|
| [[Apache Superset]] | BI 平台 | Apache 基金会项目，SQL 优先，图表 Gallery 丰富 | Docker |
| [[Grafana]] | 监控/仪表盘 | 监控数据可视化首选，支持告警 | Docker |
| [[Jellyfin]] | 媒体服务器 | 视频播放管理，非 BI | Docker |
## Key Distinction: BI vs 监控
- **BI 平台**：面向业务分析（销售/财务/运营），强调交互式探索和美观的图表 Gallery
- **监控平台**（如 Grafana）：面向系统可靠性（CPU/内存/服务可用性），强调告警和时序数据
- 两者在仪表盘层面有重叠，Superset 可以接入 Prometheus 等监控数据源
## Related Concepts
- [[数据可视化]]
- [[Docker容器化部署]]
- [[Home Server Automation]]
---
title: "BI平台"
type: concept
aliases:
- BI Platform
- Business Intelligence Platform
- 数据分析平台
tags: [bi, data, visualization, analytics]
date: 2026-04-14
---
# BI平台
## Definition
**BI 平台**（Business Intelligence Platform）是一种软件系统，用于从企业数据中提取洞察、支持决策制定。核心功能包括：数据连接与整合、SQL 查询与探索、多样化图表可视化、交互式仪表盘构建、数据驱动报警。
## Key Capabilities
1. **多数据源连接**: 支持 SQL 数据库、API、文件导入等多种数据源
2. **SQL 探索**: 内置 SQL 查询编辑器，支持即席分析
3. **图表可视化**: 提供折线图、柱状图、饼图、地理图、热力图等多样化图表
4. **仪表盘构建**: 将多个图表组合为仪表盘，支持筛选和交互
5. **权限管理**: 基于角色的访问控制（RBAC）
## Wiki 中的相关工具
| 工具 | 类型 | 特点 | 部署方式 |
|------|------|------|----------|
| [[Apache Superset]] | BI 平台 | Apache 基金会项目，SQL 优先，图表 Gallery 丰富 | Docker |
| [[Grafana]] | 监控/仪表盘 | 监控数据可视化首选，支持告警 | Docker |
| [[Jellyfin]] | 媒体服务器 | 视频播放管理，非 BI | Docker |
## Key Distinction: BI vs 监控
- **BI 平台**：面向业务分析（销售/财务/运营），强调交互式探索和美观的图表 Gallery
- **监控平台**（如 Grafana）：面向系统可靠性（CPU/内存/服务可用性），强调告警和时序数据
- 两者在仪表盘层面有重叠，Superset 可以接入 Prometheus 等监控数据源
## Related Concepts
- [[数据可视化]]
- [[Docker容器化部署]]
- [[Home Server Automation]]

70
wiki/concepts/BOOTSTRAP.md.md
View File

@@ -1,35 +1,35 @@
---
title: "BOOTSTRAP.md"
type: concept
tags: [OpenClaw, Agent, Setup]
sources: [万字讲透openclaw-workspace深度解析-2026-03-21]
last_updated: 2026-03-21
---
## Definition
**BOOTSTRAP.md** 是 OpenClaw workspace 中最特殊的一个文件——它的使命是把一个全新的 workspace 引导到"可正常使用"的状态。这是一份"第一次上岗前的引导词"，Agent 读到它后知道自己不是立刻开工，而是先把自己安顿好。
## 引导流程
1. 和用户聊几句，搞清楚 Agent 应该叫什么名字、是什么性格、用什么 emoji
2. 把结果写入 `IDENTITY.md`
3. 记录用户的基本信息到 `USER.md`
4. 一起打开 `SOUL.md`，把真正的性格和边界写进去
5. （可选）引导用户接入渠道——WhatsApp、Telegram 等
## 一次性特性
官方模板的最后一句话非常有意思：
> *"Delete this file. You don't need a bootstrap script anymore — you're you now."*
BOOTSTRAP.md 本质上是一次性引导，Agent 在完成初始化后必须把它删掉。
## Related Concepts
- [[IDENTITY.md]] — 初始化时写入身份元数据的目标文件
- [[SOUL.md]] — 初始化时写入性格设定的目标文件
- [[USER.md]] — 初始化时写入用户画像的目标文件
- [[OpenClaw]] — BOOTSTRAP.md 所属的框架
---
title: "BOOTSTRAP.md"
type: concept
tags: [OpenClaw, Agent, Setup]
sources: [万字讲透openclaw-workspace深度解析-2026-03-21]
last_updated: 2026-03-21
---
## Definition
**BOOTSTRAP.md** 是 OpenClaw workspace 中最特殊的一个文件——它的使命是把一个全新的 workspace 引导到"可正常使用"的状态。这是一份"第一次上岗前的引导词"，Agent 读到它后知道自己不是立刻开工，而是先把自己安顿好。
## 引导流程
1. 和用户聊几句，搞清楚 Agent 应该叫什么名字、是什么性格、用什么 emoji
2. 把结果写入 `IDENTITY.md`
3. 记录用户的基本信息到 `USER.md`
4. 一起打开 `SOUL.md`，把真正的性格和边界写进去
5. （可选）引导用户接入渠道——WhatsApp、Telegram 等
## 一次性特性
官方模板的最后一句话非常有意思：
> *"Delete this file. You don't need a bootstrap script anymore — you're you now."*
BOOTSTRAP.md 本质上是一次性引导，Agent 在完成初始化后必须把它删掉。
## Related Concepts
- [[IDENTITY.md]] — 初始化时写入身份元数据的目标文件
- [[SOUL.md]] — 初始化时写入性格设定的目标文件
- [[USER.md]] — 初始化时写入用户画像的目标文件
- [[OpenClaw]] — BOOTSTRAP.md 所属的框架

60
wiki/concepts/Behavioral-Psychology.md
View File

@@ -1,30 +1,30 @@
---
title: "Behavioral Psychology"
type: concept
tags: [behavioral-science, psychology, motivation, habit-formation]
last_updated: 2026-04-20
---
## Definition
行为心理学（Behavioral Psychology）研究可观察行为及其与环境刺激的关系，强调通过强化、条件反射和习惯回路来理解和改变人类行为。是 [[Behavioral Nudge Engine]] 的核心理论基础。
## Key Theories & Concepts
- **操作性条件反射**（B.F. Skinner）：行为结果强化/惩罚决定行为频率
- **习惯回路**：暗示 → 惯常行为 → 奖励（Charles Duhigg 模型）
- **即时正强化**：比起延迟奖励，即时小奖励更能维持行为
- **认知偏差**：默认偏差、现状偏差、可得性启发等影响决策的系统性偏差
- **可变奖励机制**：间隔强化比固定强化更持久（如老虎机效应）
## Applications in Software
- [[Gamification]]：积分、徽章、排行榜
- [[Default Bias]]：预填、默认选项
- [[Cognitive Load Reduction]]：减少认知摩擦维持行为
- [[Habit Tracker & Accountability Coach]]：习惯追踪与问责机制
## Related Concepts
- [[Gamification]]：行为心理学在产品设计中的应用
- [[Default Bias]]：行为偏见的具体表现
- [[Momentum Nudge]]：即时正强化驱动的动量机制
## Source
- [[Behavioral Nudge Engine]] — 核心应用场景
---
title: "Behavioral Psychology"
type: concept
tags: [behavioral-science, psychology, motivation, habit-formation]
last_updated: 2026-04-20
---
## Definition
行为心理学（Behavioral Psychology）研究可观察行为及其与环境刺激的关系，强调通过强化、条件反射和习惯回路来理解和改变人类行为。是 [[Behavioral Nudge Engine]] 的核心理论基础。
## Key Theories & Concepts
- **操作性条件反射**（B.F. Skinner）：行为结果强化/惩罚决定行为频率
- **习惯回路**：暗示 → 惯常行为 → 奖励（Charles Duhigg 模型）
- **即时正强化**：比起延迟奖励，即时小奖励更能维持行为
- **认知偏差**：默认偏差、现状偏差、可得性启发等影响决策的系统性偏差
- **可变奖励机制**：间隔强化比固定强化更持久（如老虎机效应）
## Applications in Software
- [[Gamification]]：积分、徽章、排行榜
- [[Default Bias]]：预填、默认选项
- [[Cognitive Load Reduction]]：减少认知摩擦维持行为
- [[Habit Tracker & Accountability Coach]]：习惯追踪与问责机制
## Related Concepts
- [[Gamification]]：行为心理学在产品设计中的应用
- [[Default Bias]]：行为偏见的具体表现
- [[Momentum Nudge]]：即时正强化驱动的动量机制
## Source
- [[Behavioral Nudge Engine]] — 核心应用场景

88
wiki/concepts/Big-Five-Personality.md
View File

@@ -1,44 +1,44 @@
---
title: "Big Five Personality"
type: concept
tags: []
sources: ["academic-psychologist", "academic-narratologist"]
last_updated: 2026-04-20
---
## Definition
大五人格模型（Big Five Personality Traits），也称 OCEAN 模型，是当代人格心理学中最被广泛接受和实证验证的人格框架。五个核心维度：
| 维度 | 高分特征 | 低分特征 |
|------|----------|----------|
| **Openness（开放性）** | 好奇心、想象力、创造力 | 务实、传统、保守 |
| **Conscientiousness（尽责性）** | 自律、组织性、可靠性 | 随意、松散、冲动 |
| **Extraversion（外向性）** | 社交、活力、果断 | 内向、安静、独立 |
| **Agreeableness（宜人性）** | 合作、信任、同理心 | 竞争、怀疑、冷淡 |
| **Neuroticism（神经质）** | 情绪不稳定、焦虑、敏感 | 情绪稳定、冷静、自信 |
## Key References
- **Eysenck**（Eysenck Personality Questionnaire）：大五人格先驱研究者
- Costa & McCrae（NEO-PI-R）：五因素模型标准化测量工具
## Applications in Character Design
- 每个特质高低组合产生独特行为模式（25种核心组合）
- Neuroticism × Extraversion 组合决定角色在压力下的公开/回避反应
- Conscientiousness 是最强的工作/绩效行为预测因子
- Openness 是创意角色和知识追求角色的核心特征
## Limitations
- 描述性而非解释性（不说明特质来源）
- 西方文化中心主义（跨文化可重复性存在争议）
- 特质与行为之间存在情境调节变量
- 不能预测具体行为，只能预测行为倾向
## Connections
- [[Attachment-Theory]]（依恋风格与 Big Five 共享情绪调节维度）
- [[Psychological-Profile]]（Big Five 是角色心理画像的核心框架之一）
- [[Cognitive-Distortions]]（Neuroticism 高分个体更易出现认知扭曲）
---
title: "Big Five Personality"
type: concept
tags: []
sources: ["academic-psychologist", "academic-narratologist"]
last_updated: 2026-04-20
---
## Definition
大五人格模型（Big Five Personality Traits），也称 OCEAN 模型，是当代人格心理学中最被广泛接受和实证验证的人格框架。五个核心维度：
| 维度 | 高分特征 | 低分特征 |
|------|----------|----------|
| **Openness（开放性）** | 好奇心、想象力、创造力 | 务实、传统、保守 |
| **Conscientiousness（尽责性）** | 自律、组织性、可靠性 | 随意、松散、冲动 |
| **Extraversion（外向性）** | 社交、活力、果断 | 内向、安静、独立 |
| **Agreeableness（宜人性）** | 合作、信任、同理心 | 竞争、怀疑、冷淡 |
| **Neuroticism（神经质）** | 情绪不稳定、焦虑、敏感 | 情绪稳定、冷静、自信 |
## Key References
- **Eysenck**（Eysenck Personality Questionnaire）：大五人格先驱研究者
- Costa & McCrae（NEO-PI-R）：五因素模型标准化测量工具
## Applications in Character Design
- 每个特质高低组合产生独特行为模式（25种核心组合）
- Neuroticism × Extraversion 组合决定角色在压力下的公开/回避反应
- Conscientiousness 是最强的工作/绩效行为预测因子
- Openness 是创意角色和知识追求角色的核心特征
## Limitations
- 描述性而非解释性（不说明特质来源）
- 西方文化中心主义（跨文化可重复性存在争议）
- 特质与行为之间存在情境调节变量
- 不能预测具体行为，只能预测行为倾向
## Connections
- [[Attachment-Theory]]（依恋风格与 Big Five 共享情绪调节维度）
- [[Psychological-Profile]]（Big Five 是角色心理画像的核心框架之一）
- [[Cognitive-Distortions]]（Neuroticism 高分个体更易出现认知扭曲）

96
wiki/concepts/BindMount.md
View File

@@ -1,48 +1,48 @@
---
title: "Bind Mount"
type: concept
tags: [docker, storage, development]
last_updated: 2026-04-17
---
## Aliases
- Bind Mount
- 绑定挂载
- Host Volume Mount
## Definition
Docker 中将宿主机的特定目录或文件直接映射到容器内部的一种挂载方式。与命名卷（Named Volume）不同，绑定挂载使用宿主机上的绝对路径，使容器内外的文件系统保持同步，实现代码修改实时生效。
## Use Cases
- **开发环境**：代码文件频繁变更，绑定挂载实现宿主机编辑 → 容器即时生效的热重载
- **配置文件**：将 nginx.conf、.env 等配置文件挂载进容器，方便实时调整
- **日志收集**：将容器日志目录挂载到宿主机，实现日志持久化和集中管理
## Syntax
```yaml
# docker-compose.yml
services:
app:
volumes:
- /home/user/project/src:/app/src # 宿主机路径:容器路径
- ./config:/app/config # 相对路径（相对于 compose 文件位置）
```
## Trade-offs
| 优点 | 缺点 |
|------|------|
| 代码修改实时生效 | 依赖宿主机文件系统结构 |
| 无需数据迁移 | 权限问题（UID/GID 不匹配）|
| 便于调试和热重载 | 生产环境不推荐使用 |
## Related Concepts
- [[Docker Volume]]：命名卷，适合生产环境的数据持久化
- [[Remote Development]]：远程开发中使用 Bind Mount 实现代码同步
- [[Docker Compose]]：通过 YAML 定义 Bind Mount 配置
## Related Entities
- [[Docker]]：Bind Mount 的实现平台
- [[Trae]]：通过 Remote-SSH 连接远程服务器，编辑 Bind Mount 挂载的代码
## References
- [[Trae远程开发部署指南]] — 开发环境 docker-compose.yml 使用 Bind Mount 实现代码热重载
---
title: "Bind Mount"
type: concept
tags: [docker, storage, development]
last_updated: 2026-04-17
---
## Aliases
- Bind Mount
- 绑定挂载
- Host Volume Mount
## Definition
Docker 中将宿主机的特定目录或文件直接映射到容器内部的一种挂载方式。与命名卷（Named Volume）不同，绑定挂载使用宿主机上的绝对路径，使容器内外的文件系统保持同步，实现代码修改实时生效。
## Use Cases
- **开发环境**：代码文件频繁变更，绑定挂载实现宿主机编辑 → 容器即时生效的热重载
- **配置文件**：将 nginx.conf、.env 等配置文件挂载进容器，方便实时调整
- **日志收集**：将容器日志目录挂载到宿主机，实现日志持久化和集中管理
## Syntax
```yaml
# docker-compose.yml
services:
app:
volumes:
- /home/user/project/src:/app/src # 宿主机路径:容器路径
- ./config:/app/config # 相对路径（相对于 compose 文件位置）
```
## Trade-offs
| 优点 | 缺点 |
|------|------|
| 代码修改实时生效 | 依赖宿主机文件系统结构 |
| 无需数据迁移 | 权限问题（UID/GID 不匹配）|
| 便于调试和热重载 | 生产环境不推荐使用 |
## Related Concepts
- [[Docker Volume]]：命名卷，适合生产环境的数据持久化
- [[Remote Development]]：远程开发中使用 Bind Mount 实现代码同步
- [[Docker Compose]]：通过 YAML 定义 Bind Mount 配置
## Related Entities
- [[Docker]]：Bind Mount 的实现平台
- [[Trae]]：通过 Remote-SSH 连接远程服务器，编辑 Bind Mount 挂载的代码
## References
- [[Trae远程开发部署指南]] — 开发环境 docker-compose.yml 使用 Bind Mount 实现代码热重载

92
wiki/concepts/Blocking.md
View File

@@ -1,46 +1,46 @@
---
title: "Blocking"
type: concept
tags: ["identity-resolution", "performance", "algorithm", "entity-matching"]
sources: ["identity-graph-operator"]
last_updated: 2026-04-25
---
# Blocking（阻塞/分块）
## Definition
身份解析中的候选对筛选技术——通过预计算的 **blocking key** 将全量 O(n²) 记录对比较减少为可控规模候选集的 O(n×k) 操作，是大规模实体解析的性能关键。
## Blocking Key Types
| 类型 | 示例 | 适用场景 |
|------|------|----------|
| Email Domain | `acme.com` | 同一公司账号 |
| Phone Prefix | `+1555` | 同一地区号码 |
| Name Soundex | `S530` | 语音相似姓名（Williams→W452） |
| Postal Code | `94105` | 同一地理区域 |
| Composite | email_domain + name_soundex | 联合分块，减少假阳性 |
## Workflow
```
全量记录
↓
为每条记录生成 blocking key(s)
↓
按 blocking key 分组（分块）
↓
仅对同组记录对进行 pairwise scoring
↓
跨块记录对被阻塞（不比较）
```
## Design Considerations
- **召回率 vs 性能**：blocking key 越宽松 → 更多候选对 → 更高召回率但更慢；越严格 → 更少候选对但可能遗漏真匹配
- **假阴性风险**：两个同实体但 blocking key 不同（如 "gmail.com" vs "googlemail.com"）会跨块遗漏
- **假阳性成本**：同块内异实体（如同名不同人的 "John Smith"）需靠 scoring 层排除
## Relationship to Related Concepts
- [[Blocking]] 是 [[Identity Resolution]] 的性能优化组件，通过牺牲少量召回率换取大规模场景可接受的计算成本
- [[Fuzzy-Matching]] 在 Blocking 筛选出的候选对上执行细粒度评分
- [[Confidence-Score]] 综合 Blocking + Scoring 的结果给出最终合并决策
---
title: "Blocking"
type: concept
tags: ["identity-resolution", "performance", "algorithm", "entity-matching"]
sources: ["identity-graph-operator"]
last_updated: 2026-04-25
---
# Blocking（阻塞/分块）
## Definition
身份解析中的候选对筛选技术——通过预计算的 **blocking key** 将全量 O(n²) 记录对比较减少为可控规模候选集的 O(n×k) 操作，是大规模实体解析的性能关键。
## Blocking Key Types
| 类型 | 示例 | 适用场景 |
|------|------|----------|
| Email Domain | `acme.com` | 同一公司账号 |
| Phone Prefix | `+1555` | 同一地区号码 |
| Name Soundex | `S530` | 语音相似姓名（Williams→W452） |
| Postal Code | `94105` | 同一地理区域 |
| Composite | email_domain + name_soundex | 联合分块，减少假阳性 |
## Workflow
```
全量记录
↓
为每条记录生成 blocking key(s)
↓
按 blocking key 分组（分块）
↓
仅对同组记录对进行 pairwise scoring
↓
跨块记录对被阻塞（不比较）
```
## Design Considerations
- **召回率 vs 性能**：blocking key 越宽松 → 更多候选对 → 更高召回率但更慢；越严格 → 更少候选对但可能遗漏真匹配
- **假阴性风险**：两个同实体但 blocking key 不同（如 "gmail.com" vs "googlemail.com"）会跨块遗漏
- **假阳性成本**：同块内异实体（如同名不同人的 "John Smith"）需靠 scoring 层排除
## Relationship to Related Concepts
- [[Blocking]] 是 [[Identity Resolution]] 的性能优化组件，通过牺牲少量召回率换取大规模场景可接受的计算成本
- [[Fuzzy-Matching]] 在 Blocking 筛选出的候选对上执行细粒度评分
- [[Confidence-Score]] 综合 Blocking + Scoring 的结果给出最终合并决策

80
wiki/concepts/Bloom-认知分类.md
View File

@@ -1,40 +1,40 @@
---
title: "Bloom 认知分类"
type: concept
tags: []
last_updated: 2026-04-25
---
## Definition
Bloom 认知分类（Bloom's Taxonomy）是由 Benjamin Bloom 等人于 1956 年提出的教育目标分类框架，将学习认知过程分为六个递进层次：
1. **Remember（记忆）**：识记、回忆基本事实——定义、列表、复述
2. **Understand（理解）**：解释概念含义——总结、分类、解释原因
3. **Apply（应用）**：将知识运用于新情境——执行、操作、解决问题
4. **Analyze（分析）**：拆解复杂结构——区分、组织、归因
5. **Evaluate（评价）**：基于标准做判断——检查、批判、论证
6. **Create（创造）**：整合元素形成新结构——设计、建构、发明
## Aliases
- Bloom's Taxonomy
- Bloom 认知分类
- Bloom 教育目标分类
- 布鲁姆认知分类
## Key Characteristics
- **递进性**：从低阶思维（记忆/理解）到高阶思维（分析/评价/创造）
- **教学设计应用**：每个层次对应不同的学习活动和评估方式
- 低阶目标 → 讲授、阅读、测验
- 高阶目标 → 案例分析、项目实践、创作展示
- **逆向设计**：从期望的认知层次出发，设计学习活动和评估
## Related Concepts
- [[ADDIE-Model]]：Bloom 分类是 ADDIE Design 阶段学习目标定义的核心工具
- [[Kirkpatrick-四级评估]]：学习活动的认知层次影响 Level 2 评估方法的选择
## Source
- [[corporate-training-designer]]
---
title: "Bloom 认知分类"
type: concept
tags: []
last_updated: 2026-04-25
---
## Definition
Bloom 认知分类（Bloom's Taxonomy）是由 Benjamin Bloom 等人于 1956 年提出的教育目标分类框架，将学习认知过程分为六个递进层次：
1. **Remember（记忆）**：识记、回忆基本事实——定义、列表、复述
2. **Understand（理解）**：解释概念含义——总结、分类、解释原因
3. **Apply（应用）**：将知识运用于新情境——执行、操作、解决问题
4. **Analyze（分析）**：拆解复杂结构——区分、组织、归因
5. **Evaluate（评价）**：基于标准做判断——检查、批判、论证
6. **Create（创造）**：整合元素形成新结构——设计、建构、发明
## Aliases
- Bloom's Taxonomy
- Bloom 认知分类
- Bloom 教育目标分类
- 布鲁姆认知分类
## Key Characteristics
- **递进性**：从低阶思维（记忆/理解）到高阶思维（分析/评价/创造）
- **教学设计应用**：每个层次对应不同的学习活动和评估方式
- 低阶目标 → 讲授、阅读、测验
- 高阶目标 → 案例分析、项目实践、创作展示
- **逆向设计**：从期望的认知层次出发，设计学习活动和评估
## Related Concepts
- [[ADDIE-Model]]：Bloom 分类是 ADDIE Design 阶段学习目标定义的核心工具
- [[Kirkpatrick-四级评估]]：学习活动的认知层次影响 Level 2 评估方法的选择
## Source
- [[corporate-training-designer]]

168
wiki/concepts/Blue-Green-Deployment.md
View File

@@ -1,84 +1,84 @@
---
title: "Blue-Green Deployment"
type: concept
tags: [devops, deployment, release-management, high-availability]
date: 2025-03-01
---
## Definition
蓝绿部署（Blue-Green Deployment）是一种零停机发布策略，维护两套相同的生产环境（蓝环境和绿环境），通过负载均衡器切换流量实现无缝部署和快速回滚。
## Architecture
```
Load Balancer
│
┌──────────┴──────────┐
│ │
Blue Env Green Env
(Production) (Staging)
│ │
v1.0 v1.1 (New)
│
Traffic ON Traffic OFF
```
## Deployment Flow
```
1. Blue (v1.0) serving all traffic
2. Deploy to Green (v1.1)
3. Test/Verify Green
4. Switch LB to Green
5. Blue becomes standby (or update to next version)
```
## Key Benefits
| 优势 | 描述 |
|------|------|
| 零停机 | 流量切换瞬间完成 |
| 快速回滚 | 切换回蓝色环境即可 |
| 测试完整性 | 完整生产环境测试 |
| 风险可控 | 新版本未暴露给全部用户 |
## Comparison: Blue-Green vs Canary
| 维度 | Blue-Green | Canary |
|------|-----------|--------|
| 流量切换 | 全量切换 | 渐进式 |
| 回滚速度 | 秒级 | 秒级 |
| 资源成本 | 2x | 增量 |
| 适用场景 | 关键系统 | 持续迭代 |
| 风险 | 全量暴露 | 逐步暴露 |
## In ITSM Context
在[[ITSM 2.0]]的[[Release-Management]]中，蓝绿部署是关键实践：
```
Release Management 2.0
├── Blue-Green Deployment
│ ├── 零停机发布
│ ├── 秒级回滚
│ └── 全量验证
├── Canary Release
│ ├── 渐进式发布
│ └── 实时监控
└── DevOps-integrated ITSM
├── CI/CD Pipeline
└── Automated Governance
```
## Related Concepts
- [[Release-Management]] — 发布管理总框架
- [[Canary-Release]] — 金丝雀发布
- [[High-Availability]] — 高可用架构
- [[Failover]] — 故障转移
- [[Deployment-Automation]] — 部署自动化
## Sources
- [[understanding-complete-itsm]] — Blue-Green在现代ITSM中的应用
---
title: "Blue-Green Deployment"
type: concept
tags: [devops, deployment, release-management, high-availability]
date: 2025-03-01
---
## Definition
蓝绿部署（Blue-Green Deployment）是一种零停机发布策略，维护两套相同的生产环境（蓝环境和绿环境），通过负载均衡器切换流量实现无缝部署和快速回滚。
## Architecture
```
Load Balancer
│
┌──────────┴──────────┐
│ │
Blue Env Green Env
(Production) (Staging)
│ │
v1.0 v1.1 (New)
│
Traffic ON Traffic OFF
```
## Deployment Flow
```
1. Blue (v1.0) serving all traffic
2. Deploy to Green (v1.1)
3. Test/Verify Green
4. Switch LB to Green
5. Blue becomes standby (or update to next version)
```
## Key Benefits
| 优势 | 描述 |
|------|------|
| 零停机 | 流量切换瞬间完成 |
| 快速回滚 | 切换回蓝色环境即可 |
| 测试完整性 | 完整生产环境测试 |
| 风险可控 | 新版本未暴露给全部用户 |
## Comparison: Blue-Green vs Canary
| 维度 | Blue-Green | Canary |
|------|-----------|--------|
| 流量切换 | 全量切换 | 渐进式 |
| 回滚速度 | 秒级 | 秒级 |
| 资源成本 | 2x | 增量 |
| 适用场景 | 关键系统 | 持续迭代 |
| 风险 | 全量暴露 | 逐步暴露 |
## In ITSM Context
在[[ITSM 2.0]]的[[Release-Management]]中，蓝绿部署是关键实践：
```
Release Management 2.0
├── Blue-Green Deployment
│ ├── 零停机发布
│ ├── 秒级回滚
│ └── 全量验证
├── Canary Release
│ ├── 渐进式发布
│ └── 实时监控
└── DevOps-integrated ITSM
├── CI/CD Pipeline
└── Automated Governance
```
## Related Concepts
- [[Release-Management]] — 发布管理总框架
- [[Canary-Release]] — 金丝雀发布
- [[High-Availability]] — 高可用架构
- [[Failover]] — 故障转移
- [[Deployment-Automation]] — 部署自动化
## Sources
- [[understanding-complete-itsm]] — Blue-Green在现代ITSM中的应用

90
wiki/concepts/Blue-Hat-Logo.md
View File

@@ -1,45 +1,45 @@
---
title: "Blue Hat Logo（蓝帽子标识）"
type: concept
tags: [healthcare, compliance, supplement, china]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Definition
"蓝帽子"（保健食品专用标志，保健食品专有标志的俗称）是经国家市场监督管理总局（SAMR）批准注册的保健食品专属标识。合法保健食品必须取得并展示蓝帽子标志，否则不得以保健食品名义进行销售或推广。
## Legal Requirements
- 保健食品须经 SAMR 注册审批或完成备案
- 须在产品包装及营销材料中展示蓝帽子标志和批准文号
- 无蓝帽子标志的产品不得以"保健食品"名义推广
## Marketing Restrictions
### 允许范围
- 24项经批准保健功能声称（如：增强免疫力、辅助降血脂、辅助降血糖、改善睡眠等）
- 必须使用标准化功能声称语言（如"辅助降血脂"而非"降血脂"）
- 必须标注："保健食品不是药物，不能替代药物治疗疾病"
### 禁止事项
- 声称治疗功能（"治愈疾病""代替药物"）
- 使用医疗术语（"治愈""治疗""保证康复"）
- 超出批准保健功能范围宣传
- 功效与药品比较或暗示替代关系
- 夸大宣传或虚假功效声称
## Compliance Risk
> "保健食品不得声称具有治疗功能——这是行业内处罚最高频的违规原因。" — SAMR 合规统计
违规后果：罚款 + 产品下架 + 媒体曝光
## Key Distinction
| 类别 | 标识要求 | 功能声称 | 法律定性 |
|------|----------|----------|----------|
| 保健食品 | 须展示蓝帽子 | 24项批准功能范围内 | 食品，非药品 |
| 药品 | 须展示批准文号 | 治疗适应症 | 药品 |
| 普通食品 | 无特殊标识 | 不得声称保健功能 | 食品 |
## Related Concepts
- [[Healthcare-Marketing-Compliance]]：蓝帽子管理是医疗营销合规的组成部分
- [[SAMR]]：蓝帽子注册审批由 SAMR 负责
- [[Compliance-Risk-Matrix]]：无蓝帽子宣传保健功能属 High Risk 级别
---
title: "Blue Hat Logo（蓝帽子标识）"
type: concept
tags: [healthcare, compliance, supplement, china]
sources: [healthcare-marketing-compliance]
last_updated: 2026-04-25
---
## Definition
"蓝帽子"（保健食品专用标志，保健食品专有标志的俗称）是经国家市场监督管理总局（SAMR）批准注册的保健食品专属标识。合法保健食品必须取得并展示蓝帽子标志，否则不得以保健食品名义进行销售或推广。
## Legal Requirements
- 保健食品须经 SAMR 注册审批或完成备案
- 须在产品包装及营销材料中展示蓝帽子标志和批准文号
- 无蓝帽子标志的产品不得以"保健食品"名义推广
## Marketing Restrictions
### 允许范围
- 24项经批准保健功能声称（如：增强免疫力、辅助降血脂、辅助降血糖、改善睡眠等）
- 必须使用标准化功能声称语言（如"辅助降血脂"而非"降血脂"）
- 必须标注："保健食品不是药物，不能替代药物治疗疾病"
### 禁止事项
- 声称治疗功能（"治愈疾病""代替药物"）
- 使用医疗术语（"治愈""治疗""保证康复"）
- 超出批准保健功能范围宣传
- 功效与药品比较或暗示替代关系
- 夸大宣传或虚假功效声称
## Compliance Risk
> "保健食品不得声称具有治疗功能——这是行业内处罚最高频的违规原因。" — SAMR 合规统计
违规后果：罚款 + 产品下架 + 媒体曝光
## Key Distinction
| 类别 | 标识要求 | 功能声称 | 法律定性 |
|------|----------|----------|----------|
| 保健食品 | 须展示蓝帽子 | 24项批准功能范围内 | 食品，非药品 |
| 药品 | 须展示批准文号 | 治疗适应症 | 药品 |
| 普通食品 | 无特殊标识 | 不得声称保健功能 | 食品 |
## Related Concepts
- [[Healthcare-Marketing-Compliance]]：蓝帽子管理是医疗营销合规的组成部分
- [[SAMR]]：蓝帽子注册审批由 SAMR 负责
- [[Compliance-Risk-Matrix]]：无蓝帽子宣传保健功能属 High Risk 级别

120
wiki/concepts/Brain-Dump.md
View File

@@ -1,60 +1,60 @@
---
title: "Brain Dump"
type: concept
tags: [knowledge-management, agent-memory, prompting]
sources: [overnight-mini-app-builder, second-brain]
last_updated: 2026-04-22
---
## Definition
Brain Dump（脑暴倾倒）是一种将所有目标、使命、任务和上下文一次性倒入 AI Agent 记忆系统的操作方式。目的是给 Agent 足够的背景信息，使其能够自主生成高质量的每日可执行任务，而非被动等待指令。
## Aliases
- 脑暴倾倒
- 目标倾倒
- Context Injection
## How It Works
用户通过消息/短信/Telegram 将所有目标一次性告诉 Agent：
```text
Here are my goals and missions. Remember all of this:
Career:
- Grow my YouTube channel to 100k subscribers
- Launch my SaaS product by Q3
- Build a community around AI education
Personal:
- Read 2 books per month
- Learn Spanish
Business:
- Scale revenue to $10k/month
- Build partnerships with 5 companies in my space
- Automate as much of my workflow as possible
Use this context for everything you do going forward.
```
## Key Insight
> "The brain dump is everything. The more context you give about your goals, the better the agent's daily tasks will be."
Brain Dump 是整个 [[overnight-mini-app-builder]] 工作流中**最重要的一步**。它决定了 Agent 每日任务的相关性和价值。
## Relationship to Second Brain
- [[Second Brain]] — Brain Dump 是 Second Brain 捕获阶段的具体实践方式
- [[overnight-mini-app-builder]] — 将 Brain Dump 作为自主任务生成的上下文输入
- [[Cumulative Memory]] — Brain Dump 产生的上下文被 [[OpenClaw]] 永久记忆，随时间积累
## Key Relationships
- [[Cumulative Memory]] — Brain Dump 产生的上下文被 Agent 永久记忆
- [[Second Brain]] — Brain Dump 是 Second Brain 捕获零摩擦理念的具体操作
- [[Zero-Friction Capture]] — Brain Dump 强调用最自然的方式（发消息）完成捕获
- [[overnight-mini-app-builder]] — 本概念的来源场景
---
title: "Brain Dump"
type: concept
tags: [knowledge-management, agent-memory, prompting]
sources: [overnight-mini-app-builder, second-brain]
last_updated: 2026-04-22
---
## Definition
Brain Dump（脑暴倾倒）是一种将所有目标、使命、任务和上下文一次性倒入 AI Agent 记忆系统的操作方式。目的是给 Agent 足够的背景信息，使其能够自主生成高质量的每日可执行任务，而非被动等待指令。
## Aliases
- 脑暴倾倒
- 目标倾倒
- Context Injection
## How It Works
用户通过消息/短信/Telegram 将所有目标一次性告诉 Agent：
```text
Here are my goals and missions. Remember all of this:
Career:
- Grow my YouTube channel to 100k subscribers
- Launch my SaaS product by Q3
- Build a community around AI education
Personal:
- Read 2 books per month
- Learn Spanish
Business:
- Scale revenue to $10k/month
- Build partnerships with 5 companies in my space
- Automate as much of my workflow as possible
Use this context for everything you do going forward.
```
## Key Insight
> "The brain dump is everything. The more context you give about your goals, the better the agent's daily tasks will be."
Brain Dump 是整个 [[overnight-mini-app-builder]] 工作流中**最重要的一步**。它决定了 Agent 每日任务的相关性和价值。
## Relationship to Second Brain
- [[Second Brain]] — Brain Dump 是 Second Brain 捕获阶段的具体实践方式
- [[overnight-mini-app-builder]] — 将 Brain Dump 作为自主任务生成的上下文输入
- [[Cumulative Memory]] — Brain Dump 产生的上下文被 [[OpenClaw]] 永久记忆，随时间积累
## Key Relationships
- [[Cumulative Memory]] — Brain Dump 产生的上下文被 Agent 永久记忆
- [[Second Brain]] — Brain Dump 是 Second Brain 捕获零摩擦理念的具体操作
- [[Zero-Friction Capture]] — Brain Dump 强调用最自然的方式（发消息）完成捕获
- [[overnight-mini-app-builder]] — 本概念的来源场景

78
wiki/concepts/Branch-Strategy.md
View File

@@ -1,39 +1,39 @@
---
title: "Branch Strategy"
type: concept
tags: ["git", "workflow", "delivery-traceability"]
last_updated: 2026-04-25
---
## Definition
Branch Strategy（分支策略）是一套基于变更类型的分支分层管理模型，通过规范化分支命名和来源规则，确保各类型的代码变更在正确的上下文中开发、审查和合并。
## Branch Types
| 类型 | 模式 | 来源分支 | 目标分支 | 典型场景 |
|------|------|----------|----------|----------|
| Feature | `feature/JIRA-ID-description` | develop | develop | 新产品或平台功能 |
| Bugfix | `bugfix/JIRA-ID-description` | develop | develop | 非关键缺陷修复 |
| Hotfix | `hotfix/JIRA-ID-description` | main | main | 关键生产环境修复 |
| Refactor | `feature/JIRA-ID-description` | develop | develop | 结构清理（需关联 Jira 任务） |
| Docs | `feature/JIRA-ID-description` | develop | develop | 文档更新（需关联 Jira 任务） |
| Tests | `bugfix/JIRA-ID-description` | develop | develop | 回归测试（需关联 Jira 任务） |
| Config | `feature/JIRA-ID-description` | develop | develop | 配置或工作流策略变更 |
| Dependencies | `bugfix/JIRA-ID-description` | develop | develop | 依赖或平台升级 |
| Release | `release/version` | develop | main | 发布准备 |
## Protected Branches
- `main`：始终生产就绪；所有合并必须经过 PR review
- `develop`：持续集成的集成分支；feature/bugfix 从其拉取
- `release/*`：发布准备分支；仍需关联 release ticket 或变更控制项
## Relationship to Other Concepts
- [[Atomic-Commit]]：在 branch 内部进一步原子化 commit
- [[Jira-Git-Traceability]]：每个 branch 必须包含 Jira ID 作为唯一标识
- [[Jira-Gate]]：branch 创建前必须验证 Jira Task 存在
## Sources
- [[project-management-jira-workflow-steward]]
---
title: "Branch Strategy"
type: concept
tags: ["git", "workflow", "delivery-traceability"]
last_updated: 2026-04-25
---
## Definition
Branch Strategy（分支策略）是一套基于变更类型的分支分层管理模型，通过规范化分支命名和来源规则，确保各类型的代码变更在正确的上下文中开发、审查和合并。
## Branch Types
| 类型 | 模式 | 来源分支 | 目标分支 | 典型场景 |
|------|------|----------|----------|----------|
| Feature | `feature/JIRA-ID-description` | develop | develop | 新产品或平台功能 |
| Bugfix | `bugfix/JIRA-ID-description` | develop | develop | 非关键缺陷修复 |
| Hotfix | `hotfix/JIRA-ID-description` | main | main | 关键生产环境修复 |
| Refactor | `feature/JIRA-ID-description` | develop | develop | 结构清理（需关联 Jira 任务） |
| Docs | `feature/JIRA-ID-description` | develop | develop | 文档更新（需关联 Jira 任务） |
| Tests | `bugfix/JIRA-ID-description` | develop | develop | 回归测试（需关联 Jira 任务） |
| Config | `feature/JIRA-ID-description` | develop | develop | 配置或工作流策略变更 |
| Dependencies | `bugfix/JIRA-ID-description` | develop | develop | 依赖或平台升级 |
| Release | `release/version` | develop | main | 发布准备 |
## Protected Branches
- `main`：始终生产就绪；所有合并必须经过 PR review
- `develop`：持续集成的集成分支；feature/bugfix 从其拉取
- `release/*`：发布准备分支；仍需关联 release ticket 或变更控制项
## Relationship to Other Concepts
- [[Atomic-Commit]]：在 branch 内部进一步原子化 commit
- [[Jira-Git-Traceability]]：每个 branch 必须包含 Jira ID 作为唯一标识
- [[Jira-Gate]]：branch 创建前必须验证 Jira Task 存在
## Sources
- [[project-management-jira-workflow-steward]]

112
wiki/concepts/Brand-Environment.md
View File

@@ -1,56 +1,56 @@
---
title: "Brand Environment"
type: concept
tags: []
sources: []
last_updated: 2026-04-25
---
## Definition
品牌作为环境——品牌不是个人简介和头像，而是一个让人们前来转变的小世界，是读者关注 3-6 个月后在脑海中积累的整体印象和感受。
## Core Properties
- 品牌是积累的，而非瞬间传达的
- 品牌在读者关注 3-6 个月后形成，而非首次访问个人资料时
- 每个接触点（帖子、简介、设计、内容、声音）都在构建品牌
- 品牌是故事——你来自哪里、低谷经历、技能和成长
## Key Distinction
> "你的个人简介和头像并不重要。有些人个人简介里只有一个词，头像也只用了一种颜色。"
## The Building Blocks
品牌通过以下接触点构建：
- 横幅、头像、个人简介
- 简介链接、落地页设计
- 置顶内容、帖子、主题串
- 新闻简报、视频
- 世界观、人生哲学的表达
## Brand as Story
> "你的品牌就是你的故事。"
你的故事包括：
- 你来自哪里
- 人生中的"低谷"
- 经历过的挑战和获得的技能
- 这些事物如何帮助你成长
## Brand in the System Economy
在 [[System-Economy]] 中，品牌是将受众引入你的系统的入口。[[Content-Creator]] 创作内容不是为了流量，而是通过持续输出 [[Idea-Density]]（高密度创意）来构建一个值得追随和付费的品牌。
## Related Concepts
- [[System-Economy]] — 品牌是系统的入口
- [[Content-Creator]] — 品牌通过内容构建
- [[Idea-Density]] — 高密度内容是品牌建设的核心
- [[Attention-Economy]] — 品牌捕获注意力
## Sources
- [[if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间]]
---
title: "Brand Environment"
type: concept
tags: []
sources: []
last_updated: 2026-04-25
---
## Definition
品牌作为环境——品牌不是个人简介和头像，而是一个让人们前来转变的小世界，是读者关注 3-6 个月后在脑海中积累的整体印象和感受。
## Core Properties
- 品牌是积累的，而非瞬间传达的
- 品牌在读者关注 3-6 个月后形成，而非首次访问个人资料时
- 每个接触点（帖子、简介、设计、内容、声音）都在构建品牌
- 品牌是故事——你来自哪里、低谷经历、技能和成长
## Key Distinction
> "你的个人简介和头像并不重要。有些人个人简介里只有一个词，头像也只用了一种颜色。"
## The Building Blocks
品牌通过以下接触点构建：
- 横幅、头像、个人简介
- 简介链接、落地页设计
- 置顶内容、帖子、主题串
- 新闻简报、视频
- 世界观、人生哲学的表达
## Brand as Story
> "你的品牌就是你的故事。"
你的故事包括：
- 你来自哪里
- 人生中的"低谷"
- 经历过的挑战和获得的技能
- 这些事物如何帮助你成长
## Brand in the System Economy
在 [[System-Economy]] 中，品牌是将受众引入你的系统的入口。[[Content-Creator]] 创作内容不是为了流量，而是通过持续输出 [[Idea-Density]]（高密度创意）来构建一个值得追随和付费的品牌。
## Related Concepts
- [[System-Economy]] — 品牌是系统的入口
- [[Content-Creator]] — 品牌通过内容构建
- [[Idea-Density]] — 高密度内容是品牌建设的核心
- [[Attention-Economy]] — 品牌捕获注意力
## Sources
- [[if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间]]

128
wiki/concepts/Break-the-Build.md
View File

@@ -1,64 +1,64 @@
# Break-the-Build
## Definition
"Break the Build" is a mechanism that stops the development process if security risks are too high until resolved.
## Concept
当 CI/CD 管道中的安全扫描发现高风险问题时，自动阻止构建继续进行，直到安全问题得到修复。
## How It Works
### Trigger Conditions
- SAST 发现高危漏洞
- SCA 发现有漏洞的依赖
- 机密信息泄露检测
- 许可证合规违规
### Process Flow
```
代码提交 → 构建开始 → 安全扫描 →
├─ 通过 → 继续部署
└─ 失败 → 停止构建 → 通知团队 → 修复 → 重新提交
```
## Implementation
### CI/CD Integration
```yaml
# GitLab CI Example
security_scan:
stage: test
script:
- sast-scan
allow_failure: false # 阻止构建
```
### Gatekeeping Strategy
| 漏洞等级 | 默认策略 |
|---------|---------|
| Critical | 强制阻止 |
| High | 阻止（可配置） |
| Medium | 警告 |
| Low | 忽略 |
## Benefits
- 防止不安全代码进入生产环境
- 强制开发者及时修复安全问题
- 提高整体安全基线
- 减少安全债务
## Best Practices
1. 明确定义"阻塞"阈值
2. 平衡安全与开发速度
3. 提供清晰的错误信息
4. 集成通知机制
## Related Concepts
- [[DevSecOps]] — Break-the-Build 是其自动化组件
- [[SAST]] — 触发条件来源
- [[SCA]] — 触发条件来源
- [[CI/CD Pipeline]] — 实施载体
- [[Shift-Left-Security]] — 早期发现问题的策略
## Sources
- [[what-is-devsecops-best-practices-benefits-and-tools]]
# Break-the-Build
## Definition
"Break the Build" is a mechanism that stops the development process if security risks are too high until resolved.
## Concept
当 CI/CD 管道中的安全扫描发现高风险问题时，自动阻止构建继续进行，直到安全问题得到修复。
## How It Works
### Trigger Conditions
- SAST 发现高危漏洞
- SCA 发现有漏洞的依赖
- 机密信息泄露检测
- 许可证合规违规
### Process Flow
```
代码提交 → 构建开始 → 安全扫描 →
├─ 通过 → 继续部署
└─ 失败 → 停止构建 → 通知团队 → 修复 → 重新提交
```
## Implementation
### CI/CD Integration
```yaml
# GitLab CI Example
security_scan:
stage: test
script:
- sast-scan
allow_failure: false # 阻止构建
```
### Gatekeeping Strategy
| 漏洞等级 | 默认策略 |
|---------|---------|
| Critical | 强制阻止 |
| High | 阻止（可配置） |
| Medium | 警告 |
| Low | 忽略 |
## Benefits
- 防止不安全代码进入生产环境
- 强制开发者及时修复安全问题
- 提高整体安全基线
- 减少安全债务
## Best Practices
1. 明确定义"阻塞"阈值
2. 平衡安全与开发速度
3. 提供清晰的错误信息
4. 集成通知机制
## Related Concepts
- [[DevSecOps]] — Break-the-Build 是其自动化组件
- [[SAST]] — 触发条件来源
- [[SCA]] — 触发条件来源
- [[CI/CD Pipeline]] — 实施载体
- [[Shift-Left-Security]] — 早期发现问题的策略
## Sources
- [[what-is-devsecops-best-practices-benefits-and-tools]]

126
wiki/concepts/Bug-Bounty.md
View File

@@ -1,63 +1,63 @@
# Bug Bounty
## Definition
Bug Bounty programs incentivize external security researchers to report vulnerabilities in an organization's systems, websites, or applications.
## Concept
Bug Bounty（漏洞赏金）计划通过向外部安全研究人员提供奖励，激励他们报告组织系统、网站或应用程序中的漏洞。
## How It Works
### Program Setup
1. 定义范围（Scope）
2. 制定规则和奖励表
3. 建立提交和处理流程
4. 部署公开平台或使用第三方服务
### Researcher Workflow
```
发现漏洞 → 提交报告 → 厂商验证 → 确认/分类 → 修复 → 发放奖励
```
## Benefits
### For Organizations
- 扩展安全测试覆盖面
- 成本效益比聘请专职安全团队更高
- 获得多样化的安全研究人员视角
- 提高安全响应能力
### For Researchers
- 获得经济奖励
- 建立安全研究声誉
- 学习真实环境漏洞
## Platforms
- HackerOne
- Bugcrowd
- Open Bug Bounty
- 厂商自有平台（Google VRP, Microsoft Bounty）
## Best Practices
### For Program Owners
1. 清晰的规则和范围定义
2. 公平的奖励机制
3. 快速响应提交
4. 透明的沟通
5. 法律保护（Safe Harbor）
### Responsible Disclosure
- 给厂商合理时间修复
- 不公开漏洞细节直到修复
- 遵循协调漏洞披露（CVD）
## Related Concepts
- [[DevSecOps]] — Bug Bounty 是持续安全改进的一部分
- [[Penetration-Testing]] — 正式渗透测试
- [[Vulnerability-Scanning]] — 自动化漏洞扫描
- [[Incident-Response]] — 漏洞响应
- [[Responsible-Disclosure]] — 负责任披露
## Sources
- [[what-is-devsecops-best-practices-benefits-and-tools]]
# Bug Bounty
## Definition
Bug Bounty programs incentivize external security researchers to report vulnerabilities in an organization's systems, websites, or applications.
## Concept
Bug Bounty（漏洞赏金）计划通过向外部安全研究人员提供奖励，激励他们报告组织系统、网站或应用程序中的漏洞。
## How It Works
### Program Setup
1. 定义范围（Scope）
2. 制定规则和奖励表
3. 建立提交和处理流程
4. 部署公开平台或使用第三方服务
### Researcher Workflow
```
发现漏洞 → 提交报告 → 厂商验证 → 确认/分类 → 修复 → 发放奖励
```
## Benefits
### For Organizations
- 扩展安全测试覆盖面
- 成本效益比聘请专职安全团队更高
- 获得多样化的安全研究人员视角
- 提高安全响应能力
### For Researchers
- 获得经济奖励
- 建立安全研究声誉
- 学习真实环境漏洞
## Platforms
- HackerOne
- Bugcrowd
- Open Bug Bounty
- 厂商自有平台（Google VRP, Microsoft Bounty）
## Best Practices
### For Program Owners
1. 清晰的规则和范围定义
2. 公平的奖励机制
3. 快速响应提交
4. 透明的沟通
5. 法律保护（Safe Harbor）
### Responsible Disclosure
- 给厂商合理时间修复
- 不公开漏洞细节直到修复
- 遵循协调漏洞披露（CVD）
## Related Concepts
- [[DevSecOps]] — Bug Bounty 是持续安全改进的一部分
- [[Penetration-Testing]] — 正式渗透测试
- [[Vulnerability-Scanning]] — 自动化漏洞扫描
- [[Incident-Response]] — 漏洞响应
- [[Responsible-Disclosure]] — 负责任披露
## Sources
- [[what-is-devsecops-best-practices-benefits-and-tools]]

62
wiki/concepts/Build-Mode.md
View File

@@ -1,31 +1,31 @@
---
title: "Build Mode"
type: concept
tags: [opencode, workflow, implementation]
sources: [如何在ubuntu上安装opencode并配置vibe-kanban]
last_updated: 2026-04-22
---
## Definition
**Build Mode**（构建模式）是 OpenCode 的双模式工作流之一。通过 Tab 键从 Plan 模式切换回来，执行实际的代码修改和文件写入。
## Mechanism
- 从 Plan 模式按 Tab 键切换回 Build 模式
- AI 获得完整的文件写入权限
- 执行 Plan 阶段生成的实现方案
- 支持 `/undo` 撤销最近的修改，`/redo` 重做
## Build Workflow
1. **Plan 阶段**：描述需求，AI 生成实现方案
2. **Review 阶段**：审阅方案，补充上下文和示例
3. **Build 阶段**：Tab 切换，执行 `Sounds good! Go ahead and make the changes.`
4. **Iterate 阶段**：如需调整，用 `/undo` 回退后重新 Plan
## Related Concepts
- [[Plan Mode]] — Build 模式的前置阶段，生成实现方案
- [[OpenCode]] — 提供 Plan/Build 双模式的核心工具
- [[Vibe Coding]] — AI 辅助编程的工作流理念
---
title: "Build Mode"
type: concept
tags: [opencode, workflow, implementation]
sources: [如何在ubuntu上安装opencode并配置vibe-kanban]
last_updated: 2026-04-22
---
## Definition
**Build Mode**（构建模式）是 OpenCode 的双模式工作流之一。通过 Tab 键从 Plan 模式切换回来，执行实际的代码修改和文件写入。
## Mechanism
- 从 Plan 模式按 Tab 键切换回 Build 模式
- AI 获得完整的文件写入权限
- 执行 Plan 阶段生成的实现方案
- 支持 `/undo` 撤销最近的修改，`/redo` 重做
## Build Workflow
1. **Plan 阶段**：描述需求，AI 生成实现方案
2. **Review 阶段**：审阅方案，补充上下文和示例
3. **Build 阶段**：Tab 切换，执行 `Sounds good! Go ahead and make the changes.`
4. **Iterate 阶段**：如需调整，用 `/undo` 回退后重新 Plan
## Related Concepts
- [[Plan Mode]] — Build 模式的前置阶段，生成实现方案
- [[OpenCode]] — 提供 Plan/Build 双模式的核心工具
- [[Vibe Coding]] — AI 辅助编程的工作流理念

80
wiki/concepts/Build-Your-Own-X.md
View File

@@ -1,40 +1,40 @@
---
title: "Build-Your-Own-X"
type: concept
tags: [methodology, learning, programming, byox]
last_updated: 2026-04-23
---
## Aliases
- BYOX
- Build Your Own X
- Build-Your-Own-x
- build-your-own-x
- build your own x
- "自己动手重建"
## Definition
Build Your Own X（BYOX）是一种学习方法论：通过从零实现主流技术（X）来深入理解其内部原理。核心理念引用 Richard Feynman 的名言："What I cannot create, I do not understand"——动手重建是真正理解技术的唯一途径。
## Details
- **起源**: GitHub 仓库 codecrafters-io/build-your-own-x，由 [[DanielStefanovic]] 创建，现由 [[CodeCrafters]] 维护
- **覆盖领域**: 26+ 技术领域（3D Renderer、Web Browser、Database、Docker、Git、Operating System、Programming Language、Neural Network、Bot、Shell、Game、Physics Engine、Search Engine、Regex Engine 等）
- **支持语言**: C++、Python、Java、JavaScript、Go、Rust、Haskell、TypeScript、C#、Ruby、Kotlin、Scala 等 15+ 编程语言
- **推荐资源**: [[NAND-to-Tetris]] 被列为操作系统和编程语言教程的推荐前置资源
## Key Principles
1. **从零开始（From Scratch）**: 不使用高级框架或库，在最小化依赖下理解核心原理
2. **分步指南**: 每条教程提供循序渐进的分步骤指引，而非大段理论
3. **动手实践**: 阅读 10 篇文档不如实现一个简化版本
4. **深度理解**: 不仅知道"怎么用"，更理解"为什么这样工作"
## Connection to Vibe Coding
BYOX 强调从零重建（Build）理解原理，[[Vibe-Coding]] 强调用 AI 高效实现（Ship）交付产品。两者互补——BYOX 建立直觉，Vibe Coding 高效执行。
## Connections
- [[Build-Your-Own-X]] ← maintained_by ← [[CodeCrafters]]
- [[Build-Your-Own-X]] ← founded_by ← [[DanielStefanovic]]
- [[Build-Your-Own-X]] ← quotes ← [[RichardFeynman]]
- [[Build-Your-Own-X]] ← covers ← [[From-Scratch-Methodology]]
- [[Build-Your-Own-X]] ← enables ← [[Learn-By-Building]]
- [[Build-Your-Own-X]] ← includes ← [[NAND-to-Tetris]]
---
title: "Build-Your-Own-X"
type: concept
tags: [methodology, learning, programming, byox]
last_updated: 2026-04-23
---
## Aliases
- BYOX
- Build Your Own X
- Build-Your-Own-x
- build-your-own-x
- build your own x
- "自己动手重建"
## Definition
Build Your Own X（BYOX）是一种学习方法论：通过从零实现主流技术（X）来深入理解其内部原理。核心理念引用 Richard Feynman 的名言："What I cannot create, I do not understand"——动手重建是真正理解技术的唯一途径。
## Details
- **起源**: GitHub 仓库 codecrafters-io/build-your-own-x，由 [[DanielStefanovic]] 创建，现由 [[CodeCrafters]] 维护
- **覆盖领域**: 26+ 技术领域（3D Renderer、Web Browser、Database、Docker、Git、Operating System、Programming Language、Neural Network、Bot、Shell、Game、Physics Engine、Search Engine、Regex Engine 等）
- **支持语言**: C++、Python、Java、JavaScript、Go、Rust、Haskell、TypeScript、C#、Ruby、Kotlin、Scala 等 15+ 编程语言
- **推荐资源**: [[NAND-to-Tetris]] 被列为操作系统和编程语言教程的推荐前置资源
## Key Principles
1. **从零开始（From Scratch）**: 不使用高级框架或库，在最小化依赖下理解核心原理
2. **分步指南**: 每条教程提供循序渐进的分步骤指引，而非大段理论
3. **动手实践**: 阅读 10 篇文档不如实现一个简化版本
4. **深度理解**: 不仅知道"怎么用"，更理解"为什么这样工作"
## Connection to Vibe Coding
BYOX 强调从零重建（Build）理解原理，[[Vibe-Coding]] 强调用 AI 高效实现（Ship）交付产品。两者互补——BYOX 建立直觉，Vibe Coding 高效执行。
## Connections
- [[Build-Your-Own-X]] ← maintained_by ← [[CodeCrafters]]
- [[Build-Your-Own-X]] ← founded_by ← [[DanielStefanovic]]
- [[Build-Your-Own-X]] ← quotes ← [[RichardFeynman]]
- [[Build-Your-Own-X]] ← covers ← [[From-Scratch-Methodology]]
- [[Build-Your-Own-X]] ← enables ← [[Learn-By-Building]]
- [[Build-Your-Own-X]] ← includes ← [[NAND-to-Tetris]]

134
wiki/concepts/BuildInPublic.md
View File

@@ -1,67 +1,67 @@
---
title: "Build in Public"
type: concept
tags: [内容营销, 个人品牌, 创业]
last_updated: 2026-04-22
---
## 定义
Build in Public（公开构建）是一种创业和个人品牌策略，即在项目/产品开发过程中公开分享进展、挑战、失败和学到的东西。
## 核心理念
### 在 AI 泛滥时代，活人感更重要
- AI 生成内容越来越多，同质化严重
- 真实的构建过程、思考和挣扎更能建立信任
- 受众喜欢看到"真人"而不是"完美机器"
### 透明度创造连接
- 分享失败比分享成功更有价值
- 过程比结果更能引发共鸣
- 让受众参与你的成长旅程
## 实践方法
### 内容矩阵
- **观察类**：行业洞察、趋势分析
- **反直觉类**：挑战常规认知的观点
- **操作指南类**：可执行的步骤和教程
- **个人故事类**：真实的创业经历和教训
- **清单类**：可复用的资源和工具
### 反向金字塔内容法
```
一次长形式内容
↓ 拆分
无数微内容
↓ 分发
一次制作，百次分发
```
## 在一人公司中的作用
Build in Public 是[[一人公司]]内容策略的重要组成部分，配合：
- [[产品四层级体系]] 实现引流
- [[销售漏斗]] 实现转化
- [[底层能力]] 确定分享主题
## 相关来源
- [[万字保姆级教程-90天跑通一人公司模式]]
## 相关概念
- [[一人公司]]
- [[内容矩阵]]
- [[个人品牌]]
## Aliases
- 公开构建
- 透明创业
- 公开分享
---
title: "Build in Public"
type: concept
tags: [内容营销, 个人品牌, 创业]
last_updated: 2026-04-22
---
## 定义
Build in Public（公开构建）是一种创业和个人品牌策略，即在项目/产品开发过程中公开分享进展、挑战、失败和学到的东西。
## 核心理念
### 在 AI 泛滥时代，活人感更重要
- AI 生成内容越来越多，同质化严重
- 真实的构建过程、思考和挣扎更能建立信任
- 受众喜欢看到"真人"而不是"完美机器"
### 透明度创造连接
- 分享失败比分享成功更有价值
- 过程比结果更能引发共鸣
- 让受众参与你的成长旅程
## 实践方法
### 内容矩阵
- **观察类**：行业洞察、趋势分析
- **反直觉类**：挑战常规认知的观点
- **操作指南类**：可执行的步骤和教程
- **个人故事类**：真实的创业经历和教训
- **清单类**：可复用的资源和工具
### 反向金字塔内容法
```
一次长形式内容
↓ 拆分
无数微内容
↓ 分发
一次制作，百次分发
```
## 在一人公司中的作用
Build in Public 是[[一人公司]]内容策略的重要组成部分，配合：
- [[产品四层级体系]] 实现引流
- [[销售漏斗]] 实现转化
- [[底层能力]] 确定分享主题
## 相关来源
- [[万字保姆级教程-90天跑通一人公司模式]]
## 相关概念
- [[一人公司]]
- [[内容矩阵]]
- [[个人品牌]]
## Aliases
- 公开构建
- 透明创业
- 公开分享

204
wiki/concepts/Business-Impact-Analysis.md
View File

@@ -1,102 +1,102 @@
---
title: "Business Impact Analysis (业务影响分析)"
tags: [devops, disaster-recovery, risk-management, business-continuity, planning]
aliases: [BIA]
created: 2026-04-25
---
# Business Impact Analysis (业务影响分析)
**Business Impact Analysis (BIA)** 是确定不同应用系统故障对业务影响的分析过程，用于设定 [[RTO]] 和 [[RPO]] 目标以及分层保护策略。
## Aliases
- BIA
- 业务影响分析
## Definition
BIA 的核心问题：
1. 如果系统停机 1 小时，会发生什么？
2. 如果丢失过去 1 小时的数据，会发生什么？
回答这些问题，才能科学地确定每个系统的 RTO/RPO 目标，而非凭感觉设定"激进但无法实现"的目标。
## 关键分析问题
### 如果系统停机 1 小时？
- **收入损失**？损失多少？
- **客户不满**？影响多少客户？
- **员工受阻**？他们能绕过去工作吗？
- **合规风险**？法律问题？
### 如果丢失过去 1 小时的数据？
- **数据能重建吗**？
- **是否涉及资金/交易**？
- **用户会注意到吗**？
- **合规要求**是否要求保留这些数据？
## Tiered Protection Model
基于 BIA 结论，将应用分为不同保护级别：
| Tier | 场景 | RTO 目标 | RPO 目标 | 投资策略 |
|------|------|----------|----------|----------|
| **(1) Critical** | 支付处理、用户认证、核心产品功能 | < 5 分钟 | < 1 分钟 | Feature Flag + 自动化监控 + 3AM 告警 + 热备 |
| **(2) Important** | 管理后台、报表、客户支持工具 | < 1 小时 | < 15 分钟 | Feature Flag（主要发布）+ 业务时间监控 + 标准备份 |
| **(3) Nice-to-have** | 内部工具、开发环境、文档站点 | < 4 小时 | < 1 小时 | 基础监控 + 手动恢复流程 + 每日备份 |
## 投资优先级
> "Most teams try to give everything Tier 1 treatment, which can lead to burnout. Be ruthless about what actually matters to your business. You can't do *everything*."
### Tier 1 投资
- [[Feature Flag]] + 自动化监控
- 自动化告警（支持 3AM 叫醒）
- [[Kill Switch]] + 备用路径就绪
- 近实时数据复制
### Tier 2 投资
- [[Feature Flag]]（主要发布场景）
- 业务时间监控
- 文档化的回滚程序
- 小时级备份
### Tier 3 投资
- 基础监控
- 手动恢复程序
- 每日备份
- 期望最好的结果
## BIA 与成本收益
> "Do the math honestly. What does an hour of downtime actually cost your business? If it's $10K, don't spend $100K/year on infrastructure to prevent it. You're better off accepting some downtime and investing in faster recovery."
| 系统停机损失 | 合理灾备投资上限（年化） |
|-------------|------------------------|
| $10K/小时 | $100K/年 |
| $100K/小时 | $1M/年 |
**关键洞察**：预防和恢复的成本必须与实际业务损失相匹配。
## BIA 与 [[Feature Flag]] 的关系
BIA 结论指导 Feature Flag 的使用策略：
- **Tier 1 系统**：必须有 Kill Switch，Progressive Rollout 强制
- **Tier 2 系统**：建议 Feature Flag 主要发布场景
- **Tier 3 系统**：根据 ROI 决定是否使用 Feature Flag
## Related Concepts
- [[RTO]] — BIA 结论决定 RTO 目标
- [[RPO]] — BIA 结论决定 RPO 目标
- [[Feature Flag]] — 基于 BIA 分层保护的技术手段
- [[Kill Switch]] — Tier 1 系统的必备应急机制
- [[Disaster Recovery]] — BIA 是灾备规划的基础
- [[Risk-Mitigation]] — BIA 是风险管理的一部分
## Sources
- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]
---
title: "Business Impact Analysis (业务影响分析)"
tags: [devops, disaster-recovery, risk-management, business-continuity, planning]
aliases: [BIA]
created: 2026-04-25
---
# Business Impact Analysis (业务影响分析)
**Business Impact Analysis (BIA)** 是确定不同应用系统故障对业务影响的分析过程，用于设定 [[RTO]] 和 [[RPO]] 目标以及分层保护策略。
## Aliases
- BIA
- 业务影响分析
## Definition
BIA 的核心问题：
1. 如果系统停机 1 小时，会发生什么？
2. 如果丢失过去 1 小时的数据，会发生什么？
回答这些问题，才能科学地确定每个系统的 RTO/RPO 目标，而非凭感觉设定"激进但无法实现"的目标。
## 关键分析问题
### 如果系统停机 1 小时？
- **收入损失**？损失多少？
- **客户不满**？影响多少客户？
- **员工受阻**？他们能绕过去工作吗？
- **合规风险**？法律问题？
### 如果丢失过去 1 小时的数据？
- **数据能重建吗**？
- **是否涉及资金/交易**？
- **用户会注意到吗**？
- **合规要求**是否要求保留这些数据？
## Tiered Protection Model
基于 BIA 结论，将应用分为不同保护级别：
| Tier | 场景 | RTO 目标 | RPO 目标 | 投资策略 |
|------|------|----------|----------|----------|
| **(1) Critical** | 支付处理、用户认证、核心产品功能 | < 5 分钟 | < 1 分钟 | Feature Flag + 自动化监控 + 3AM 告警 + 热备 |
| **(2) Important** | 管理后台、报表、客户支持工具 | < 1 小时 | < 15 分钟 | Feature Flag（主要发布）+ 业务时间监控 + 标准备份 |
| **(3) Nice-to-have** | 内部工具、开发环境、文档站点 | < 4 小时 | < 1 小时 | 基础监控 + 手动恢复流程 + 每日备份 |
## 投资优先级
> "Most teams try to give everything Tier 1 treatment, which can lead to burnout. Be ruthless about what actually matters to your business. You can't do *everything*."
### Tier 1 投资
- [[Feature Flag]] + 自动化监控
- 自动化告警（支持 3AM 叫醒）
- [[Kill Switch]] + 备用路径就绪
- 近实时数据复制
### Tier 2 投资
- [[Feature Flag]]（主要发布场景）
- 业务时间监控
- 文档化的回滚程序
- 小时级备份
### Tier 3 投资
- 基础监控
- 手动恢复程序
- 每日备份
- 期望最好的结果
## BIA 与成本收益
> "Do the math honestly. What does an hour of downtime actually cost your business? If it's $10K, don't spend $100K/year on infrastructure to prevent it. You're better off accepting some downtime and investing in faster recovery."
| 系统停机损失 | 合理灾备投资上限（年化） |
|-------------|------------------------|
| $10K/小时 | $100K/年 |
| $100K/小时 | $1M/年 |
**关键洞察**：预防和恢复的成本必须与实际业务损失相匹配。
## BIA 与 [[Feature Flag]] 的关系
BIA 结论指导 Feature Flag 的使用策略：
- **Tier 1 系统**：必须有 Kill Switch，Progressive Rollout 强制
- **Tier 2 系统**：建议 Feature Flag 主要发布场景
- **Tier 3 系统**：根据 ROI 决定是否使用 Feature Flag
## Related Concepts
- [[RTO]] — BIA 结论决定 RTO 目标
- [[RPO]] — BIA 结论决定 RPO 目标
- [[Feature Flag]] — 基于 BIA 分层保护的技术手段
- [[Kill Switch]] — Tier 1 系统的必备应急机制
- [[Disaster Recovery]] — BIA 是灾备规划的基础
- [[Risk-Mitigation]] — BIA 是风险管理的一部分
## Sources
- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]

90
wiki/concepts/Business-Knowledge-Base.md
View File

@@ -1,45 +1,45 @@
---
title: "Business Knowledge Base"
type: concept
tags: []
sources: []
---
# Business Knowledge Base
## Definition
AI Agent 的结构化业务知识库，包含服务详情、定价政策、营业时间、常见问题解答和人工升级触发条件等信息，是 AI 自动回复准确性的核心依赖。
## Contents
| Category | Examples |
|----------|---------|
| **Services & Pricing** | 服务列表、价格区间、套餐选项 |
| **Business Hours** | 营业时间、节假日安排、紧急联系方式 |
| **Location** | 地址、交通指引、停车信息 |
| **FAQ Responses** | 预定义的高频问答对 |
| **Escalation Triggers** | 需要人工处理的场景定义（投诉、退款、特殊情况） |
## Knowledge Injection
在 [[OpenClaw]] 中通过以下方式构建知识库：
1. **Structured data**：JSON/YAML 格式的结构化业务数据
2. **AGENTS.md 配置**：路由规则和回复模板中嵌入知识
3. **Document ingestion**：产品手册、政策文档导入
## Quality Considerations
- **准确性**：知识库内容必须与实际业务一致，否则 AI 会生成错误回复
- **覆盖度**：覆盖越全面，AI 自动处理率越高
- **更新机制**：业务变更时同步更新知识库，避免信息滞后
## Related Concepts
- [[AI-Auto-Response]]：知识库是自动回复的信息来源
- [[Intent-Classification]]：知识库结构影响意图分类的准确性
- [[Human-Handoff]]：升级触发条件定义在知识库中
## Sources
- [[multi-channel-customer-service]]
---
title: "Business Knowledge Base"
type: concept
tags: []
sources: []
---
# Business Knowledge Base
## Definition
AI Agent 的结构化业务知识库，包含服务详情、定价政策、营业时间、常见问题解答和人工升级触发条件等信息，是 AI 自动回复准确性的核心依赖。
## Contents
| Category | Examples |
|----------|---------|
| **Services & Pricing** | 服务列表、价格区间、套餐选项 |
| **Business Hours** | 营业时间、节假日安排、紧急联系方式 |
| **Location** | 地址、交通指引、停车信息 |
| **FAQ Responses** | 预定义的高频问答对 |
| **Escalation Triggers** | 需要人工处理的场景定义（投诉、退款、特殊情况） |
## Knowledge Injection
在 [[OpenClaw]] 中通过以下方式构建知识库：
1. **Structured data**：JSON/YAML 格式的结构化业务数据
2. **AGENTS.md 配置**：路由规则和回复模板中嵌入知识
3. **Document ingestion**：产品手册、政策文档导入
## Quality Considerations
- **准确性**：知识库内容必须与实际业务一致，否则 AI 会生成错误回复
- **覆盖度**：覆盖越全面，AI 自动处理率越高
- **更新机制**：业务变更时同步更新知识库，避免信息滞后
## Related Concepts
- [[AI-Auto-Response]]：知识库是自动回复的信息来源
- [[Intent-Classification]]：知识库结构影响意图分类的准确性
- [[Human-Handoff]]：升级触发条件定义在知识库中
## Sources
- [[multi-channel-customer-service]]

102
wiki/concepts/CAPA.md
View File

@@ -1,51 +1,51 @@
---
title: "CAPA"
type: concept
tags: [Incident-Management, Post-mortem, Root-Cause, Preventive-Action]
last_updated: 2026-04-14
---
## Definition
CAPA (Corrective and Preventive Action，纠正和预防措施) 是 Emergency Change 事后必须执行的流程，用于从事故中提取根本原因并预防同类问题再次发生。CAPA 通常与 Post-mortem 回顾结合使用。
## Components
### Corrective Action（纠正措施）
- 修复当前事故的直接措施
- 目标是恢复服务到期望状态
- 通常在 Emergency Change 执行阶段完成
### Preventive Action（预防措施）
- 防止同类问题再次发生的长期措施
- 目标是消除根本原因
- 通常在 Post-mortem 分析后制定
## Relationship with Emergency Change
CAPA 是 Emergency Change 流程的关键组成部分：
```
Incident 发生
↓
Emergency Change 执行（Corrective Action）
↓
CAPA/Post-mortem 分析
↓
制定 Preventive Action
↓
可能转化为 Standard Change（避免未来同类事件）
```
## Process
1. **Incident Review**：回顾事故经过
2. **Root Cause Analysis**：识别根本原因
3. **Corrective Action**：执行即时修复
4. **Preventive Action**：制定长期预防措施
5. **Follow-up**：跟踪措施执行情况
6. **Closure**：完成 CAPA 记录
## Sources
- [[ctp-topic-30-managing-change]]
---
title: "CAPA"
type: concept
tags: [Incident-Management, Post-mortem, Root-Cause, Preventive-Action]
last_updated: 2026-04-14
---
## Definition
CAPA (Corrective and Preventive Action，纠正和预防措施) 是 Emergency Change 事后必须执行的流程，用于从事故中提取根本原因并预防同类问题再次发生。CAPA 通常与 Post-mortem 回顾结合使用。
## Components
### Corrective Action（纠正措施）
- 修复当前事故的直接措施
- 目标是恢复服务到期望状态
- 通常在 Emergency Change 执行阶段完成
### Preventive Action（预防措施）
- 防止同类问题再次发生的长期措施
- 目标是消除根本原因
- 通常在 Post-mortem 分析后制定
## Relationship with Emergency Change
CAPA 是 Emergency Change 流程的关键组成部分：
```
Incident 发生
↓
Emergency Change 执行（Corrective Action）
↓
CAPA/Post-mortem 分析
↓
制定 Preventive Action
↓
可能转化为 Standard Change（避免未来同类事件）
```
## Process
1. **Incident Review**：回顾事故经过
2. **Root Cause Analysis**：识别根本原因
3. **Corrective Action**：执行即时修复
4. **Preventive Action**：制定长期预防措施
5. **Follow-up**：跟踪措施执行情况
6. **Closure**：完成 CAPA 记录
## Sources
- [[ctp-topic-30-managing-change]]

64
wiki/concepts/CEOPattern.md
View File

@@ -1,32 +1,32 @@
---
title: "CEO Pattern"
type: concept
tags: [multi-agent, architecture, orchestration]
sources: [autonomous-project-management]
last_updated: 2026-04-22
---
## 定义
主 Agent 仅负责策略决策（strategy only），所有执行操作下沉至子 Agent 的极简主控模式。其名称来源于"CEO 只做战略，不管执行"的企业管理隐喻。
## 核心原则
- **主会话越薄越好**：0-2 步工具调用，响应速度与主会话的"薄度"成正比
- **只做决策**：任务分配、优先级调整、结果汇总
- **不做事**：不直接执行工具调用，不处理具体业务逻辑
- **所有执行下沉**：子 Agent 自主工作，主会话只负责协调
## 关键洞察
> "The less the main agent does, the faster it responds."
主会话的功能越少，其响应速度越快——这是去中心化协调架构的性能保障。
## 实现方式
通过 [[PM Delegation Pattern]]，每个子 Agent 被赋予特定范围的任务，独立完成，主会话不干预具体执行过程。
## 与传统 Orchestrator 模式的区别
| 维度 | Orchestrator 模式 | CEO 模式 |
|------|-------------------|---------|
| 主 Agent 角色 | 交通指挥员（所有调用必经） | CEO（仅决策） |
| 并行能力 | 受限（中心瓶颈） | 强（完全并行） |
| 响应速度 | 随任务数线性下降 | 稳定（子 Agent 异步执行） |
| 扩展性 | O(n) 瓶颈 | O(1) 主会话成本 |
---
title: "CEO Pattern"
type: concept
tags: [multi-agent, architecture, orchestration]
sources: [autonomous-project-management]
last_updated: 2026-04-22
---
## 定义
主 Agent 仅负责策略决策（strategy only），所有执行操作下沉至子 Agent 的极简主控模式。其名称来源于"CEO 只做战略，不管执行"的企业管理隐喻。
## 核心原则
- **主会话越薄越好**：0-2 步工具调用，响应速度与主会话的"薄度"成正比
- **只做决策**：任务分配、优先级调整、结果汇总
- **不做事**：不直接执行工具调用，不处理具体业务逻辑
- **所有执行下沉**：子 Agent 自主工作，主会话只负责协调
## 关键洞察
> "The less the main agent does, the faster it responds."
主会话的功能越少，其响应速度越快——这是去中心化协调架构的性能保障。
## 实现方式
通过 [[PM Delegation Pattern]]，每个子 Agent 被赋予特定范围的任务，独立完成，主会话不干预具体执行过程。
## 与传统 Orchestrator 模式的区别
| 维度 | Orchestrator 模式 | CEO 模式 |
|------|-------------------|---------|
| 主 Agent 角色 | 交通指挥员（所有调用必经） | CEO（仅决策） |
| 并行能力 | 受限（中心瓶颈） | 强（完全并行） |
| 响应速度 | 随任务数线性下降 | 稳定（子 Agent 异步执行） |
| 扩展性 | O(n) 瓶颈 | O(1) 主会话成本 |

102
wiki/concepts/CI-CD-Pipeline.md
View File

@@ -1,51 +1,51 @@
---
title: "CI/CD Pipeline"
type: concept
sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-9-ci-cd-with-gruntwork]
last_updated: 2026-04-14
---
## Definition
CI/CD 流水线（CI/CD Pipeline）是持续集成（Continuous Integration）和持续交付/部署（Continuous Delivery/Deployment）的自动化流程，用于管理基础设施代码（IaC）的构建、测试和部署。在 Gruntwork Landing Zone 架构中，每个 Landing Zone 配置独立的 Jenkins 服务器和 CI/CD 流水线来自动化 Terraform 基础设施变更。
## Core Components
### CI（持续集成）
- **代码提交**：开发人员将特性分支代码推送到 GitHub 仓库
- **自动构建**：Jenkins 触发 Terraform 初始化和格式化验证
- **自动测试**：TerraTest 执行基础设施单元测试和集成测试
- **代码审查**：Pull Request 必须通过审查才能合并到主分支
### CD（持续交付/部署）
- **自动部署**：合并到主分支后，Jenkins 自动执行 Terraform Plan
- **审批流程**：变更需要人工审批后才执行 Apply
- **渐进式部署**：支持 Blue-Green 部署和 Canary Release 策略
### Infrastructure-Specific Considerations
- **状态管理**：Terraform State 的锁定和远程存储（使用 S3 + DynamoDB）
- **幂等性**：Terraform 模块设计必须支持重复执行而不产生副作用
- **回滚机制**：通过 Terraform State 历史版本实现快速回滚
- **漂移检测**：定期运行 `terraform plan` 检测配置漂移
## Tools in Gruntwork Landing Zone Context
- **Jenkins**：核心 CI/CD 引擎，每个 Landing Zone 独立部署
- **Terraform**：IaC 工具，定义和管理 AWS 资源
- **TerraTest**：Go 语言编写的基础设施测试框架
- **GitHub**：代码仓库，支持特性分支和 Pull Request 工作流
## Git Workflow
- 特性分支开发：`feature/<description>`
- 通过 Pull Request 合并到主分支
- 必须经过代码审查和 CI 测试
- 合并后触发自动部署流水线
## Related Concepts
- [[Landing-Zone-Architecture]]：CI/CD 流水线是 Landing Zone 自动化运维的核心机制
- [[Terraform-Modules]]：被 CI/CD 流水线自动化部署的 IaC 模块
- [[GitOps]]：基于 Git 的运维方式，CI/CD 是其技术实现
- [[TerraTest]]：用于基础设施变更的自动化测试工具
## References
- [[ctp-topic-1-gruntwork-landing-zone-architecture]]
- [[ctp-topic-9-ci-cd-with-gruntwork]]
- [[ctp-topic-2-git]]
---
title: "CI/CD Pipeline"
type: concept
sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-9-ci-cd-with-gruntwork]
last_updated: 2026-04-14
---
## Definition
CI/CD 流水线（CI/CD Pipeline）是持续集成（Continuous Integration）和持续交付/部署（Continuous Delivery/Deployment）的自动化流程，用于管理基础设施代码（IaC）的构建、测试和部署。在 Gruntwork Landing Zone 架构中，每个 Landing Zone 配置独立的 Jenkins 服务器和 CI/CD 流水线来自动化 Terraform 基础设施变更。
## Core Components
### CI（持续集成）
- **代码提交**：开发人员将特性分支代码推送到 GitHub 仓库
- **自动构建**：Jenkins 触发 Terraform 初始化和格式化验证
- **自动测试**：TerraTest 执行基础设施单元测试和集成测试
- **代码审查**：Pull Request 必须通过审查才能合并到主分支
### CD（持续交付/部署）
- **自动部署**：合并到主分支后，Jenkins 自动执行 Terraform Plan
- **审批流程**：变更需要人工审批后才执行 Apply
- **渐进式部署**：支持 Blue-Green 部署和 Canary Release 策略
### Infrastructure-Specific Considerations
- **状态管理**：Terraform State 的锁定和远程存储（使用 S3 + DynamoDB）
- **幂等性**：Terraform 模块设计必须支持重复执行而不产生副作用
- **回滚机制**：通过 Terraform State 历史版本实现快速回滚
- **漂移检测**：定期运行 `terraform plan` 检测配置漂移
## Tools in Gruntwork Landing Zone Context
- **Jenkins**：核心 CI/CD 引擎，每个 Landing Zone 独立部署
- **Terraform**：IaC 工具，定义和管理 AWS 资源
- **TerraTest**：Go 语言编写的基础设施测试框架
- **GitHub**：代码仓库，支持特性分支和 Pull Request 工作流
## Git Workflow
- 特性分支开发：`feature/<description>`
- 通过 Pull Request 合并到主分支
- 必须经过代码审查和 CI 测试
- 合并后触发自动部署流水线
## Related Concepts
- [[Landing-Zone-Architecture]]：CI/CD 流水线是 Landing Zone 自动化运维的核心机制
- [[Terraform-Modules]]：被 CI/CD 流水线自动化部署的 IaC 模块
- [[GitOps]]：基于 Git 的运维方式，CI/CD 是其技术实现
- [[TerraTest]]：用于基础设施变更的自动化测试工具
## References
- [[ctp-topic-1-gruntwork-landing-zone-architecture]]
- [[ctp-topic-9-ci-cd-with-gruntwork]]
- [[ctp-topic-2-git]]

86
wiki/concepts/CICDPipeline.md
View File

@@ -1,43 +1,43 @@
---
title: "CI/CD Pipeline"
type: concept
tags: [devops, cicd, automation, continuous-delivery]
sources: [devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin]
last_updated: 2026-04-22
---
## Summary
CI/CD (Continuous Integration / Continuous Delivery) Pipelines automate the entire software delivery process — from code commit through testing, integration, and deployment. In DevOps, CI/CD is a foundational automation enabler that shrinks feedback cycles from weeks to minutes. Key tools include Jenkins, GitLab CI, and GitHub Actions.
## Key Concepts
### Continuous Integration (CI)
- Developers merge code changes frequently (multiple times daily)
- Automated builds and tests run on every commit
- Catches integration bugs early
### Continuous Delivery (CD)
- Code changes are automatically prepared for release
- Deployment to staging/production is a manual decision
- Ensures software is always in a deployable state
### Continuous Deployment
- Every change that passes tests is automatically deployed to production
- Full automation of the release process
## Key Tools
- **Jenkins** — Open-source automation server with extensive plugin ecosystem
- **GitLab CI** — Integrated CI/CD within GitLab
- **GitHub Actions** — CI/CD built into GitHub
## In the DevOps Context
CI/CD pipelines are described as "Agile Accelerators" that automate testing and deployment to shrink feedback cycles. They enable teams to:
- Ship features faster with confidence
- Reduce deployment risk through automated testing
- Enable frequent, low-risk releases
## Connections
- [[DevOps Culture]] — CI/CD is an automation pillar of DevOps
- [[Infrastructure as Code (IaC)]] — Complementary automation practice
- [[DevSecOps]] — Security tools integrated into CI/CD pipelines
- [[GitOps]] — GitOps extends CI/CD with Git-as-source-of-truth
---
title: "CI/CD Pipeline"
type: concept
tags: [devops, cicd, automation, continuous-delivery]
sources: [devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin]
last_updated: 2026-04-22
---
## Summary
CI/CD (Continuous Integration / Continuous Delivery) Pipelines automate the entire software delivery process — from code commit through testing, integration, and deployment. In DevOps, CI/CD is a foundational automation enabler that shrinks feedback cycles from weeks to minutes. Key tools include Jenkins, GitLab CI, and GitHub Actions.
## Key Concepts
### Continuous Integration (CI)
- Developers merge code changes frequently (multiple times daily)
- Automated builds and tests run on every commit
- Catches integration bugs early
### Continuous Delivery (CD)
- Code changes are automatically prepared for release
- Deployment to staging/production is a manual decision
- Ensures software is always in a deployable state
### Continuous Deployment
- Every change that passes tests is automatically deployed to production
- Full automation of the release process
## Key Tools
- **Jenkins** — Open-source automation server with extensive plugin ecosystem
- **GitLab CI** — Integrated CI/CD within GitLab
- **GitHub Actions** — CI/CD built into GitHub
## In the DevOps Context
CI/CD pipelines are described as "Agile Accelerators" that automate testing and deployment to shrink feedback cycles. They enable teams to:
- Ship features faster with confidence
- Reduce deployment risk through automated testing
- Enable frequent, low-risk releases
## Connections
- [[DevOps Culture]] — CI/CD is an automation pillar of DevOps
- [[Infrastructure as Code (IaC)]] — Complementary automation practice
- [[DevSecOps]] — Security tools integrated into CI/CD pipelines
- [[GitOps]] — GitOps extends CI/CD with Git-as-source-of-truth

142
wiki/concepts/CIS-Benchmark.md
View File

@@ -1,71 +1,71 @@
---
title: "CIS Benchmark"
type: concept
tags:
- Security
- Compliance
- Hardening
- Standards
sources:
- public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w
last_updated: 2026-04-24
---
# CIS Benchmark
CIS Benchmark（Center for Internet Security Benchmark）是全球最具权威的 IT 基础设施安全加固指南，由非营利组织 CIS（Center for Internet Security）维护，涵盖操作系统、数据库、Web 服务器、容器平台等数百种技术的安全配置标准。
## 核心特点
- **社区驱动**：基于全球安全专家的共识实践，经多轮评审和测试
- **中立性**：独立于厂商，为任何组织提供客观的安全配置建议
- **分级设计**：Level 1（基础安全，适合大多数环境）和 Level 2（深度防御，适合高安全要求环境）
- **广泛覆盖**：涵盖 100+ 技术类别，包括 Linux、Windows、macOS、AWS、GCP、Azure、Kubernetes、Docker 等
## 典型检查项示例（Linux）
| 类别 | Level | 检查项 |
|------|-------|--------|
| 初始设置 | 1 | 确认是否禁用不必要的服务（如 telnet、rsh） |
| 服务配置 | 1 | 配置 SSH 禁用 root 登录和密码认证 |
| 日志配置 | 1 | 启用审计日志并配置适当的日志轮转 |
| 文件系统 | 2 | 配置 `/tmp` 目录为 noexec、nosuid、nodev |
| 访问控制 | 1 | 配置 PAM 强制密码复杂度 |
| 网络配置 | 2 | 配置防火墙规则限制入站流量 |
## 在 Bottlerocket 中的支持
Bottlerocket OS 提供专用的 CIS Benchmark 安全加固指南：
- 预配置的 SE Linux 策略覆盖大部分容器相关检查项
- 只读根文件系统和 dm-verity 自动满足多项文件系统完整性要求
- 分区设计满足审计日志分离存储要求
- 最佳实践：使用 CIS Benchmark 自动化工具（如 CIS-CAT）定期扫描 Bottlerocket 节点合规性
## 认证与合规
CIS Benchmark 是多项安全合规框架的重要组成部分：
| 合规框架 | 与 CIS Benchmark 的关系 |
|---------|------------------------|
| PCI-DSS | 引用 CIS Benchmarks 作为技术控制要求 |
| SOC 2 | 推荐 CIS Benchmarks 作为安全配置基线 |
| ISO 27001 | 参考 CIS Benchmarks 满足访问控制要求 |
| NIST CSF | CIS Benchmarks 映射到 NIST Cybersecurity Framework |
| FedRAMP | 使用 CIS Benchmarks 作为云服务安全基线 |
## 工具支持
- **CIS-CAT Pro**：官方自动化评估工具，支持扫描并生成合规报告
- **InSpec**：Chef 的合规性即代码框架，有 CIS Benchmark 配置文件
- **OpenSCAP**：开源 CVE/配置扫描工具，有 CIS Benchmark 配置文件
- **kube-bench**：Kubernetes CIS Benchmark 自动化评估工具
## 与其他安全标准的对比
| 标准 | 侧重点 | 适用范围 |
|------|--------|---------|
| CIS Benchmark | 安全配置最佳实践 | 操作系统、应用、云服务 |
| NIST SP 800-53 | 联邦信息安全控制 | 美国政府机构 |
| ISO 27001/27002 | 信息安全管理体系 | 所有组织 |
| DISA STIG | 国防部安全技术实施指南 | 美国国防部系统 |
| SOC 2 Trust Criteria | 服务组织控制 | SaaS/云服务提供商 |
---
title: "CIS Benchmark"
type: concept
tags:
- Security
- Compliance
- Hardening
- Standards
sources:
- public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w
last_updated: 2026-04-24
---
# CIS Benchmark
CIS Benchmark（Center for Internet Security Benchmark）是全球最具权威的 IT 基础设施安全加固指南，由非营利组织 CIS（Center for Internet Security）维护，涵盖操作系统、数据库、Web 服务器、容器平台等数百种技术的安全配置标准。
## 核心特点
- **社区驱动**：基于全球安全专家的共识实践，经多轮评审和测试
- **中立性**：独立于厂商，为任何组织提供客观的安全配置建议
- **分级设计**：Level 1（基础安全，适合大多数环境）和 Level 2（深度防御，适合高安全要求环境）
- **广泛覆盖**：涵盖 100+ 技术类别，包括 Linux、Windows、macOS、AWS、GCP、Azure、Kubernetes、Docker 等
## 典型检查项示例（Linux）
| 类别 | Level | 检查项 |
|------|-------|--------|
| 初始设置 | 1 | 确认是否禁用不必要的服务（如 telnet、rsh） |
| 服务配置 | 1 | 配置 SSH 禁用 root 登录和密码认证 |
| 日志配置 | 1 | 启用审计日志并配置适当的日志轮转 |
| 文件系统 | 2 | 配置 `/tmp` 目录为 noexec、nosuid、nodev |
| 访问控制 | 1 | 配置 PAM 强制密码复杂度 |
| 网络配置 | 2 | 配置防火墙规则限制入站流量 |
## 在 Bottlerocket 中的支持
Bottlerocket OS 提供专用的 CIS Benchmark 安全加固指南：
- 预配置的 SE Linux 策略覆盖大部分容器相关检查项
- 只读根文件系统和 dm-verity 自动满足多项文件系统完整性要求
- 分区设计满足审计日志分离存储要求
- 最佳实践：使用 CIS Benchmark 自动化工具（如 CIS-CAT）定期扫描 Bottlerocket 节点合规性
## 认证与合规
CIS Benchmark 是多项安全合规框架的重要组成部分：
| 合规框架 | 与 CIS Benchmark 的关系 |
|---------|------------------------|
| PCI-DSS | 引用 CIS Benchmarks 作为技术控制要求 |
| SOC 2 | 推荐 CIS Benchmarks 作为安全配置基线 |
| ISO 27001 | 参考 CIS Benchmarks 满足访问控制要求 |
| NIST CSF | CIS Benchmarks 映射到 NIST Cybersecurity Framework |
| FedRAMP | 使用 CIS Benchmarks 作为云服务安全基线 |
## 工具支持
- **CIS-CAT Pro**：官方自动化评估工具，支持扫描并生成合规报告
- **InSpec**：Chef 的合规性即代码框架，有 CIS Benchmark 配置文件
- **OpenSCAP**：开源 CVE/配置扫描工具，有 CIS Benchmark 配置文件
- **kube-bench**：Kubernetes CIS Benchmark 自动化评估工具
## 与其他安全标准的对比
| 标准 | 侧重点 | 适用范围 |
|------|--------|---------|
| CIS Benchmark | 安全配置最佳实践 | 操作系统、应用、云服务 |
| NIST SP 800-53 | 联邦信息安全控制 | 美国政府机构 |
| ISO 27001/27002 | 信息安全管理体系 | 所有组织 |
| DISA STIG | 国防部安全技术实施指南 | 美国国防部系统 |
| SOC 2 Trust Criteria | 服务组织控制 | SaaS/云服务提供商 |

136
wiki/concepts/CMDB.md
View File

@@ -1,68 +1,68 @@
---
title: "Configuration Management Database (CMDB)"
type: concept
tags: [cloud, devops, operations, itsm]
date: 2025-03-01
---
## Definition
配置管理数据库（CMDB）是存储IT基础设施中所有配置项（Configuration Items, CI）及其关系关系的数据库。在现代ITSM中，AI驱动的CMDB增强了依赖映射、漂移检测和实时影响分析能力。
## Traditional vs Modern CMDB
| 维度 | 传统CMDB | AI-Enhanced CMDB |
|------|---------|------------------|
| 数据来源 | 手动录入 | 自动发现 |
| 关系映射 | 静态 | 动态 |
| 漂移检测 | 定期审计 | 实时监控 |
| 影响分析 | 人工推断 | AI预测 |
| 多云支持 | 有限 | 原生支持 |
## Key Capabilities (Modern CMDB)
### 1. Dependency Mapping
```
服务 → 应用 → 中间件 → 数据库 → 基础设施
↓ ↓ ↓ ↓ ↓
自动发现配置项及其依赖关系
```
### 2. Drift Detection
- 配置变更自动检测
- 与预期配置对比
- 告警和自动修复
### 3. Real-time Impact Analysis
- 变更前影响预测
- 事件影响范围评估
- 服务依赖可视化
## In ITSM Context
在[[ITSM]]中，CMDB是[[Configuration-Management]]的核心：
```
Configuration Management (ITSM 5.0)
├── AI-powered CMDB
│ ├── 依赖映射
│ ├── 漂移检测
│ └── 实时影响分析
├── Multi-cloud Orchestration
│ ├── 公有云
│ ├── 私有云
│ └── 混合云
└── Misconfiguration Prevention
└── 安全漏洞预防
```
## Related Concepts
- [[Configuration-Management]] — 配置管理流程
- [[ITSM]] — CMDB的父框架
- [[AIOps]] — AI驱动的CMDB能力
- [[Cloud-Native]] — 多云CMDB支持
## Sources
- [[understanding-complete-itsm]] — AI-CMDB在现代ITSM中的应用
---
title: "Configuration Management Database (CMDB)"
type: concept
tags: [cloud, devops, operations, itsm]
date: 2025-03-01
---
## Definition
配置管理数据库（CMDB）是存储IT基础设施中所有配置项（Configuration Items, CI）及其关系关系的数据库。在现代ITSM中，AI驱动的CMDB增强了依赖映射、漂移检测和实时影响分析能力。
## Traditional vs Modern CMDB
| 维度 | 传统CMDB | AI-Enhanced CMDB |
|------|---------|------------------|
| 数据来源 | 手动录入 | 自动发现 |
| 关系映射 | 静态 | 动态 |
| 漂移检测 | 定期审计 | 实时监控 |
| 影响分析 | 人工推断 | AI预测 |
| 多云支持 | 有限 | 原生支持 |
## Key Capabilities (Modern CMDB)
### 1. Dependency Mapping
```
服务 → 应用 → 中间件 → 数据库 → 基础设施
↓ ↓ ↓ ↓ ↓
自动发现配置项及其依赖关系
```
### 2. Drift Detection
- 配置变更自动检测
- 与预期配置对比
- 告警和自动修复
### 3. Real-time Impact Analysis
- 变更前影响预测
- 事件影响范围评估
- 服务依赖可视化
## In ITSM Context
在[[ITSM]]中，CMDB是[[Configuration-Management]]的核心：
```
Configuration Management (ITSM 5.0)
├── AI-powered CMDB
│ ├── 依赖映射
│ ├── 漂移检测
│ └── 实时影响分析
├── Multi-cloud Orchestration
│ ├── 公有云
│ ├── 私有云
│ └── 混合云
└── Misconfiguration Prevention
└── 安全漏洞预防
```
## Related Concepts
- [[Configuration-Management]] — 配置管理流程
- [[ITSM]] — CMDB的父框架
- [[AIOps]] — AI驱动的CMDB能力
- [[Cloud-Native]] — 多云CMDB支持
## Sources
- [[understanding-complete-itsm]] — AI-CMDB在现代ITSM中的应用

156
wiki/concepts/Calibration-Testing.md
View File

@@ -1,78 +1,78 @@
---
title: "Calibration Testing"
type: concept
tags: [model-evaluation, probability-calibration, model-quality]
last_updated: 2026-04-25
---
## Definition
概率校准（Calibration Testing）验证模型输出的预测概率与实际发生的频率是否一致。一个校准良好的分类器：若它预测某事件概率为 80%，则该事件实际发生的频率应接近 80%。
## Core Methods
### Hosmer-Lemeshow Test
- 将预测概率分组（默认10组），比较每组观测正例数与期望正例数
- 统计量：$\chi^2 = \sum \frac{(observed - expected)^2}{expected(1 - expected/n)}$
- 自由度：组数 - 2；p-value < 0.05 → 拒绝原假设（校准差）
- **局限性**：对样本量敏感，分组方式不同结果不同
### Brier Score
- $BS = \frac{1}{N}\sum(p_i - y_i)^2$，取值 [0, 0.25]（二分类）
- 同时衡量校准（calibration）和区分度（refinement）
- 值越低越好，可分解为：$BS = Calibration^2 + Refinement$
- **优势**：无需分组，对样本量稳健，可跨模型比较
### Reliability Diagram（可靠性图）
- 将预测概率分箱（bin），绘制实际正例率 vs 预测概率
- 理想情况为 45° 对角线；S 形曲线表示欠/过度预测
- 视觉诊断工具，适合识别系统性校准偏差
### Expected Calibration Error (ECE)
- 加权平均每箱预测概率与实际频率的绝对差
- $ECE = \sum_b \frac{|b|}{n} |acc(b) - conf(b)|$
- 量化校准误差，便于跨模型对比
## Usage
```python
# Hosmer-Lemeshow
from scipy.stats import chi2
def hosmer_lemshow_test(y_true, y_pred, groups=10):
data = pd.DataFrame({"y": y_true, "p": y_pred})
data["bucket"] = pd.qcut(data["p"], groups, duplicates="drop")
agg = data.groupby("bucket", observed=True).agg(
n=("y", "count"), observed=("y", "sum"), expected=("p", "sum")
)
hl_stat = (((agg["observed"] - agg["expected"])**2) /
(agg["expected"] * (1 - agg["expected"]/agg["n"]))).sum()
dof = len(agg) - 2
p_value = 1 - chi2.cdf(hl_stat, dof)
return {"HL_statistic": round(hl_stat, 4), "p_value": round(p_value, 6), "calibrated": p_value >= 0.05}
# Brier Score
from sklearn.metrics import brier_score_loss
bs = brier_score_loss(y_true, y_pred)
```
## Model QA 中的应用
Model QA Specialist 执行以下校准审计：
1. **跨子群体校准**：在年龄/地区/收入等子群体上分别测试，发现整体指标掩盖的局部校准问题
2. **时间窗口稳定性**：跨 OOT（Out-of-Time）窗口测试校准稳定性，识别时间漂移
3. **分布偏移下的校准**：在压力场景（population shift）下测试，评估模型鲁棒性
4. **决策阈值校准**：根据业务决策阈值（如 p > 0.6 触发行动），评估该阈值处的校准质量
## Relationship
- **依赖** [[Discrimination-Metrics]]：先验证模型有区分能力（AUC/Gini），再讨论校准才有意义
- **依赖** [[SHAP]]：SHAP 解释"哪个特征导致校准偏差"，支撑诊断方向
- **依赖** [[Population-Stability-Index]]：PSI 捕捉特征分布漂移，漂移是校准失效的根本原因之一
- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的核心审计步骤之一
## Key Insights
- **High AUC ≠ Well Calibrated**：模型可以高区分度但低校准（如逻辑回归自然校准，神经网络往往过度自信）
- **业务影响**：校准误差 180bps（0.18）在 decile 10 可能影响 12% 的资产组合
- **监管要求**：巴塞尔协议/IFRS 9/CCAR 等监管框架明确要求信用风险模型的概率校准
---
title: "Calibration Testing"
type: concept
tags: [model-evaluation, probability-calibration, model-quality]
last_updated: 2026-04-25
---
## Definition
概率校准（Calibration Testing）验证模型输出的预测概率与实际发生的频率是否一致。一个校准良好的分类器：若它预测某事件概率为 80%，则该事件实际发生的频率应接近 80%。
## Core Methods
### Hosmer-Lemeshow Test
- 将预测概率分组（默认10组），比较每组观测正例数与期望正例数
- 统计量：$\chi^2 = \sum \frac{(observed - expected)^2}{expected(1 - expected/n)}$
- 自由度：组数 - 2；p-value < 0.05 → 拒绝原假设（校准差）
- **局限性**：对样本量敏感，分组方式不同结果不同
### Brier Score
- $BS = \frac{1}{N}\sum(p_i - y_i)^2$，取值 [0, 0.25]（二分类）
- 同时衡量校准（calibration）和区分度（refinement）
- 值越低越好，可分解为：$BS = Calibration^2 + Refinement$
- **优势**：无需分组，对样本量稳健，可跨模型比较
### Reliability Diagram（可靠性图）
- 将预测概率分箱（bin），绘制实际正例率 vs 预测概率
- 理想情况为 45° 对角线；S 形曲线表示欠/过度预测
- 视觉诊断工具，适合识别系统性校准偏差
### Expected Calibration Error (ECE)
- 加权平均每箱预测概率与实际频率的绝对差
- $ECE = \sum_b \frac{|b|}{n} |acc(b) - conf(b)|$
- 量化校准误差，便于跨模型对比
## Usage
```python
# Hosmer-Lemeshow
from scipy.stats import chi2
def hosmer_lemshow_test(y_true, y_pred, groups=10):
data = pd.DataFrame({"y": y_true, "p": y_pred})
data["bucket"] = pd.qcut(data["p"], groups, duplicates="drop")
agg = data.groupby("bucket", observed=True).agg(
n=("y", "count"), observed=("y", "sum"), expected=("p", "sum")
)
hl_stat = (((agg["observed"] - agg["expected"])**2) /
(agg["expected"] * (1 - agg["expected"]/agg["n"]))).sum()
dof = len(agg) - 2
p_value = 1 - chi2.cdf(hl_stat, dof)
return {"HL_statistic": round(hl_stat, 4), "p_value": round(p_value, 6), "calibrated": p_value >= 0.05}
# Brier Score
from sklearn.metrics import brier_score_loss
bs = brier_score_loss(y_true, y_pred)
```
## Model QA 中的应用
Model QA Specialist 执行以下校准审计：
1. **跨子群体校准**：在年龄/地区/收入等子群体上分别测试，发现整体指标掩盖的局部校准问题
2. **时间窗口稳定性**：跨 OOT（Out-of-Time）窗口测试校准稳定性，识别时间漂移
3. **分布偏移下的校准**：在压力场景（population shift）下测试，评估模型鲁棒性
4. **决策阈值校准**：根据业务决策阈值（如 p > 0.6 触发行动），评估该阈值处的校准质量
## Relationship
- **依赖** [[Discrimination-Metrics]]：先验证模型有区分能力（AUC/Gini），再讨论校准才有意义
- **依赖** [[SHAP]]：SHAP 解释"哪个特征导致校准偏差"，支撑诊断方向
- **依赖** [[Population-Stability-Index]]：PSI 捕捉特征分布漂移，漂移是校准失效的根本原因之一
- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的核心审计步骤之一
## Key Insights
- **High AUC ≠ Well Calibrated**：模型可以高区分度但低校准（如逻辑回归自然校准，神经网络往往过度自信）
- **业务影响**：校准误差 180bps（0.18）在 decile 10 可能影响 12% 的资产组合
- **监管要求**：巴塞尔协议/IFRS 9/CCAR 等监管框架明确要求信用风险模型的概率校准

120
wiki/concepts/Call-Worthy-Threshold.md
View File

@@ -1,60 +1,60 @@
---
title: "Call-Worthy Threshold"
type: concept
tags: [notification, prioritization, alerting, UX]
sources: [phone-call-notifications]
last_updated: 2026-04-23
---
## Definition
Call-Worthy Threshold 是判断某个事件是否值得触发电话通知的评估标准。核心原则：**电话通知必须稀缺，只有真正重要的信息才配得上占用用户的电话注意力**。如果 Agent 每天打电话 10 次，用户就会开始忽视电话——电话的价值在于其稀缺性。
## Decision Framework
Agent 评估是否"值得打电话"时，应考虑：
### 紧急程度（Urgency）
- 是否有时间敏感性？延迟处理会有什么后果？
- 优先级递减：紧急（立即影响）> 重要（今天内需处理）> 参考（可稍后阅读）
### 影响范围（Impact）
- 对用户的直接财务/健康/安全影响有多大？
- 优先级递减：高影响（金钱/健康/安全）> 中影响（机会成本）> 低影响（信息）
### 可替代性（Substitutability）
- 是否可以用更低打扰的方式通知？
- 优先级递减：无法替代 > 低打扰通知不足 > 简单通知即可
## Anti-Patterns
- **通知疲劳**：Agent 频繁打电话 → 用户开始忽略 → 真正重要的电话也被忽视
- **过载包装**：将 10 条普通消息合并成一条电话播报 → 信息过载，用户无法聚焦
- **误判优先级**：小事打电话，大事发消息 → 优先级判断标准混乱
## Best Practices
1. **明确定义阈值**：用户应与 Agent 协商"什么情况打电话"，形成清晰标准
2. **定期审计**：每月检查电话触发记录，确保频率保持在用户舒适范围内
3. **日志可见**：用户可查看电话触发历史，理解 Agent 的判断逻辑
4. **双向反馈**：用户说"这事不值得打电话"时，Agent 应记住并调整阈值
## Examples
| Event | Worth Calling? | Reason |
|-------|---------------|--------|
| NVDA 股价暴跌 5% | ✅ Yes | 财务影响大，时间敏感 |
| 老板发来紧急邮件 | ✅ Yes | 高度时间敏感，潜在重大影响 |
| 天气预报提醒带伞 | ❌ No | 低紧急性，普通推送即可 |
| 日程冲突提醒 | ❌ No | 提前提醒，低紧急性 |
| 服务器完全宕机 | ✅ Yes | 安全/业务影响，即时行动必需 |
## Related Concepts
- [[Voice Notification Channel]] — 电话通道的价值建立在稀缺性之上
- [[Alerting]] — 告警规则设计应与通知阈值协同
- [[Preference Learning]] — Agent 可从用户反馈中学习阈值偏好
## Sources
- [[phone-call-notifications]]
---
title: "Call-Worthy Threshold"
type: concept
tags: [notification, prioritization, alerting, UX]
sources: [phone-call-notifications]
last_updated: 2026-04-23
---
## Definition
Call-Worthy Threshold 是判断某个事件是否值得触发电话通知的评估标准。核心原则：**电话通知必须稀缺，只有真正重要的信息才配得上占用用户的电话注意力**。如果 Agent 每天打电话 10 次，用户就会开始忽视电话——电话的价值在于其稀缺性。
## Decision Framework
Agent 评估是否"值得打电话"时，应考虑：
### 紧急程度（Urgency）
- 是否有时间敏感性？延迟处理会有什么后果？
- 优先级递减：紧急（立即影响）> 重要（今天内需处理）> 参考（可稍后阅读）
### 影响范围（Impact）
- 对用户的直接财务/健康/安全影响有多大？
- 优先级递减：高影响（金钱/健康/安全）> 中影响（机会成本）> 低影响（信息）
### 可替代性（Substitutability）
- 是否可以用更低打扰的方式通知？
- 优先级递减：无法替代 > 低打扰通知不足 > 简单通知即可
## Anti-Patterns
- **通知疲劳**：Agent 频繁打电话 → 用户开始忽略 → 真正重要的电话也被忽视
- **过载包装**：将 10 条普通消息合并成一条电话播报 → 信息过载，用户无法聚焦
- **误判优先级**：小事打电话，大事发消息 → 优先级判断标准混乱
## Best Practices
1. **明确定义阈值**：用户应与 Agent 协商"什么情况打电话"，形成清晰标准
2. **定期审计**：每月检查电话触发记录，确保频率保持在用户舒适范围内
3. **日志可见**：用户可查看电话触发历史，理解 Agent 的判断逻辑
4. **双向反馈**：用户说"这事不值得打电话"时，Agent 应记住并调整阈值
## Examples
| Event | Worth Calling? | Reason |
|-------|---------------|--------|
| NVDA 股价暴跌 5% | ✅ Yes | 财务影响大，时间敏感 |
| 老板发来紧急邮件 | ✅ Yes | 高度时间敏感，潜在重大影响 |
| 天气预报提醒带伞 | ❌ No | 低紧急性，普通推送即可 |
| 日程冲突提醒 | ❌ No | 提前提醒，低紧急性 |
| 服务器完全宕机 | ✅ Yes | 安全/业务影响，即时行动必需 |
## Related Concepts
- [[Voice Notification Channel]] — 电话通道的价值建立在稀缺性之上
- [[Alerting]] — 告警规则设计应与通知阈值协同
- [[Preference Learning]] — Agent 可从用户反馈中学习阈值偏好
## Sources
- [[phone-call-notifications]]

112
wiki/concepts/Canary-Deployment.md
View File

@@ -1,56 +1,56 @@
---
title: "Canary Deployment"
type: concept
tags: [DevOps, Deployment, Kubernetes, ECS, AWS]
sources: [learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]
last_updated: 2026-05-05
---
# Canary Deployment
## Definition
金丝雀部署（Canary Deployment）是一种软件发布策略，通过将新版本逐步推向一小部分用户来降低风险——在新版本全面推广前，先将少量流量导向新版本，观察其行为和性能，验证无误后再逐步扩大比例。
## Core Mechanism
1. **流量分割**：将用户流量按比例分割（如 5%/10%/50%/100%）
2. **逐步提升**：从低比例开始，逐步增加新版本流量
3. **快速回滚**：发现问题时，立即将流量切回旧版本
## Implementation in AWS
### ECS (Elastic Container Service)
ECS 模块支持金丝雀部署，通过 Target Group 权重调整实现流量控制：
- 创建新旧两个 Task Definition
- 通过 ALB/NLB 的 Target Group 逐步调整权重
- 结合 CloudWatch 监控自动决策扩缩比例
### EKS (Elastic Kubernetes Service)
Kubernetes 原生支持金丝雀部署，通过以下机制：
- `ReplicaSet` 控制新旧版本副本数
- `Service` 选择器配合金丝雀标签
- Argo Rollouts 等高级工具提供声明式金丝雀策略
### AWS Tools
- **AWS CodeDeploy**：原生支持 ECS 和 Lambda 的金丝雀部署策略
- **ALB Target Groups**：权重路由实现流量分割
- **CloudWatch**：金丝雀指标监控
## Comparison with Other Deployment Strategies
| 策略 | 风险 | 成本 | 适用场景 |
|------|------|------|----------|
| **Blue-Green** | 中 | 高（双倍资源） | 快速回滚需求 |
| **Canary** | 低 | 中 | 生产验证 |
| **Rolling** | 中 | 低 | 资源受限环境 |
| **A/B Testing** | 低 | 中 | 功能验证 |
## Key Metrics to Monitor
- 错误率（5xx）
- 延迟（P50/P95/P99）
- 业务指标（转化率/点击率）
- 资源利用率
## Related Concepts
- [[Blue-Green-Deployment]]：双环境切换策略
- [[ECS-Module-Deployment]]：ECS 场景的模块化部署
- [[Infrastructure-as-Code]]：部署自动化基础
---
title: "Canary Deployment"
type: concept
tags: [DevOps, Deployment, Kubernetes, ECS, AWS]
sources: [learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]
last_updated: 2026-05-05
---
# Canary Deployment
## Definition
金丝雀部署（Canary Deployment）是一种软件发布策略，通过将新版本逐步推向一小部分用户来降低风险——在新版本全面推广前，先将少量流量导向新版本，观察其行为和性能，验证无误后再逐步扩大比例。
## Core Mechanism
1. **流量分割**：将用户流量按比例分割（如 5%/10%/50%/100%）
2. **逐步提升**：从低比例开始，逐步增加新版本流量
3. **快速回滚**：发现问题时，立即将流量切回旧版本
## Implementation in AWS
### ECS (Elastic Container Service)
ECS 模块支持金丝雀部署，通过 Target Group 权重调整实现流量控制：
- 创建新旧两个 Task Definition
- 通过 ALB/NLB 的 Target Group 逐步调整权重
- 结合 CloudWatch 监控自动决策扩缩比例
### EKS (Elastic Kubernetes Service)
Kubernetes 原生支持金丝雀部署，通过以下机制：
- `ReplicaSet` 控制新旧版本副本数
- `Service` 选择器配合金丝雀标签
- Argo Rollouts 等高级工具提供声明式金丝雀策略
### AWS Tools
- **AWS CodeDeploy**：原生支持 ECS 和 Lambda 的金丝雀部署策略
- **ALB Target Groups**：权重路由实现流量分割
- **CloudWatch**：金丝雀指标监控
## Comparison with Other Deployment Strategies
| 策略 | 风险 | 成本 | 适用场景 |
|------|------|------|----------|
| **Blue-Green** | 中 | 高（双倍资源） | 快速回滚需求 |
| **Canary** | 低 | 中 | 生产验证 |
| **Rolling** | 中 | 低 | 资源受限环境 |
| **A/B Testing** | 低 | 中 | 功能验证 |
## Key Metrics to Monitor
- 错误率（5xx）
- 延迟（P50/P95/P99）
- 业务指标（转化率/点击率）
- 资源利用率
## Related Concepts
- [[Blue-Green-Deployment]]：双环境切换策略
- [[ECS-Module-Deployment]]：ECS 场景的模块化部署
- [[Infrastructure-as-Code]]：部署自动化基础

126
wiki/concepts/Canary-Release.md
View File

@@ -1,63 +1,63 @@
---
title: "Canary Release"
type: concept
tags: [devops, deployment, release-management, automation]
date: 2025-03-01
---
## Definition
金丝雀发布（Canary Release）是一种渐进式软件发布策略，将新版本首先部署给小部分用户，验证稳定性后再逐步扩大范围，最终替换全部用户。这种策略降低了全量发布风险，实现近乎零干扰的发布。
## How It Works
```
Phase 1: 5% Traffic Phase 2: 20% Traffic Phase 3: 100% Traffic
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ New Version │ │ New Version │ │ Old Version │
│ ██ │ │ ████ │ │ ░░░░ │
│ 5% users │ │ 20% users │ │ Rollback if │
└─────────────────┘ └─────────────────┘ │ issues │
↓ ↓ └─────────────────┘
Monitor metrics Monitor + Auto-rollback ↓
Auto-promote if failure rate ↑ Full Deployment
```
## Key Metrics to Monitor
| 指标 | 描述 | 告警阈值 |
|------|------|---------|
| Error Rate | 错误率变化 | +2% |
| Latency | 响应时间 | +50ms |
| Business KPIs | 转化率、订单量 | -5% |
| Resource Usage | CPU/内存 | +30% |
## In ITSM Context
在[[ITSM 2.0]]的[[Release-Management]]中，金丝雀发布是关键实践：
```
Release Management 2.0
├── Canary Release
│ ├── 渐进式流量转移
│ ├── 实时监控
│ └── 自动回滚
├── Blue-Green Deployment
│ ├── 零停机切换
│ └── 快速回滚
└── Feature Flags
├── 精细化控制
└── A/B Testing
```
## Related Concepts
- [[Release-Management]] — 发布管理总框架
- [[Blue-Green-Deployment]] — 蓝绿部署
- [[Feature-Flag]] — 特性开关
- [[Progressive-Rollout]] — 渐进式发布
- [[Deployment-Automation]] — 部署自动化
## Sources
- [[understanding-complete-itsm]] — Canary Release在现代ITSM中的应用
---
title: "Canary Release"
type: concept
tags: [devops, deployment, release-management, automation]
date: 2025-03-01
---
## Definition
金丝雀发布（Canary Release）是一种渐进式软件发布策略，将新版本首先部署给小部分用户，验证稳定性后再逐步扩大范围，最终替换全部用户。这种策略降低了全量发布风险，实现近乎零干扰的发布。
## How It Works
```
Phase 1: 5% Traffic Phase 2: 20% Traffic Phase 3: 100% Traffic
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ New Version │ │ New Version │ │ Old Version │
│ ██ │ │ ████ │ │ ░░░░ │
│ 5% users │ │ 20% users │ │ Rollback if │
└─────────────────┘ └─────────────────┘ │ issues │
↓ ↓ └─────────────────┘
Monitor metrics Monitor + Auto-rollback ↓
Auto-promote if failure rate ↑ Full Deployment
```
## Key Metrics to Monitor
| 指标 | 描述 | 告警阈值 |
|------|------|---------|
| Error Rate | 错误率变化 | +2% |
| Latency | 响应时间 | +50ms |
| Business KPIs | 转化率、订单量 | -5% |
| Resource Usage | CPU/内存 | +30% |
## In ITSM Context
在[[ITSM 2.0]]的[[Release-Management]]中，金丝雀发布是关键实践：
```
Release Management 2.0
├── Canary Release
│ ├── 渐进式流量转移
│ ├── 实时监控
│ └── 自动回滚
├── Blue-Green Deployment
│ ├── 零停机切换
│ └── 快速回滚
└── Feature Flags
├── 精细化控制
└── A/B Testing
```
## Related Concepts
- [[Release-Management]] — 发布管理总框架
- [[Blue-Green-Deployment]] — 蓝绿部署
- [[Feature-Flag]] — 特性开关
- [[Progressive-Rollout]] — 渐进式发布
- [[Deployment-Automation]] — 部署自动化
## Sources
- [[understanding-complete-itsm]] — Canary Release在现代ITSM中的应用

52
wiki/concepts/Canvas.md
View File

@@ -1,26 +1,26 @@
---
title: "Canvas"
type: concept
tags: [obsidian, skills, visualization]
last_updated: 2026-04-21
---
## Definition
Canvas（画布）是 Obsidian 的 JSON 格式白板文件格式，用于在 Obsidian 中创建可视化节点布局，包含文本节点、文件节点、链接节点和组节点，以及节点之间的连线逻辑。
## Skill 版本对比
| Skill | 发布者 | 推荐度 | 特点 |
|-------|--------|--------|------|
| [[Json-Canvas]] | kepano | ❌ | 底层 JSON 语法正确性，AI 可能机械摆放节点 |
| [[Obsidian-Canvas-Creator]] | Axton | ✅ | 高层排版策略，自动计算坐标，处理连线，径向/自由排版算法 |
## Canvas 文件结构
- **节点类型**：text（文本）、file（文件）、link（链接）、group（组）
- **布局属性**：每个节点有 x/y 坐标、宽度、高度
- **连线逻辑**：source/target 节点 + 端点位置
## Connections
- [[Obsidian-Canvas-Creator]] — 推荐使用的 Skill
- [[Json-Canvas]] — 底层格式（不推荐直接使用）
- [[obsidian-必装-skills]] — 来源文档
---
title: "Canvas"
type: concept
tags: [obsidian, skills, visualization]
last_updated: 2026-04-21
---
## Definition
Canvas（画布）是 Obsidian 的 JSON 格式白板文件格式，用于在 Obsidian 中创建可视化节点布局，包含文本节点、文件节点、链接节点和组节点，以及节点之间的连线逻辑。
## Skill 版本对比
| Skill | 发布者 | 推荐度 | 特点 |
|-------|--------|--------|------|
| [[Json-Canvas]] | kepano | ❌ | 底层 JSON 语法正确性，AI 可能机械摆放节点 |
| [[Obsidian-Canvas-Creator]] | Axton | ✅ | 高层排版策略，自动计算坐标，处理连线，径向/自由排版算法 |
## Canvas 文件结构
- **节点类型**：text（文本）、file（文件）、link（链接）、group（组）
- **布局属性**：每个节点有 x/y 坐标、宽度、高度
- **连线逻辑**：source/target 节点 + 端点位置
## Connections
- [[Obsidian-Canvas-Creator]] — 推荐使用的 Skill
- [[Json-Canvas]] — 底层格式（不推荐直接使用）
- [[obsidian-必装-skills]] — 来源文档

76
wiki/concepts/Centralized-Logging.md
View File

@@ -1,38 +1,38 @@
---
title: Centralized Logging
type: concept
tags: [DevOps, Observability, CloudOps, AWS]
date: 2025-10-24
---
## Definition
Centralized Logging（集中日志）是一种将分散在多个系统、账户、服务或地理位置的日志汇总到单一中心位置进行统一管理的模式。核心目标是在分布式系统中消除监控盲区，提供全局可观测性。
## Core Properties
- **聚合**：将多个来源的日志合并到单一存储
- **统一查询**：跨来源的集中搜索和分析
- **集中告警**：基于聚合数据的统一告警策略
- **合规保留**：统一的数据保留和合规策略
## Related Concepts
- [[Multi-Account Deployment]]：多账户场景是集中日志的主要驱动因素
- [[Cross-Account Monitoring]]：跨账户监控依赖集中日志基础设施
- [[StackSets Deployment Visibility]]：StackSets 部署可观测性依赖集中日志
- [[Event Sourcing]]：集中日志可以视为事件溯源的一种实现
- [[APM]]（Application Performance Monitoring）：APM 工具通常依赖集中日志数据
- [[CloudWatch Logs]]：AWS 生态系统中的集中日志存储服务
- [[Prometheus]]：时间序列监控，可与集中日志互补
## Implementation Patterns
1. **日志采集层**：Agent/Fluentd/Firelens 收集各来源日志
2. **传输层**：EventBridge/Kinesis/Firehose 传输日志事件
3. **存储层**：CloudWatch Logs/OpenSearch/S3 + Athena
4. **分析层**：CloudWatch Logs Insights/OpenSearch Dashboards/Grafana Loki
5. **告警层**：CloudWatch Alarms/Grafana Alerting/PagerDuty
## AWS Context
- AWS CloudWatch Logs：AWS 原生日志存储和分析服务
- AWS EventBridge：事件驱动的日志采集路由
- AWS CloudTrail：AWS API 调用的审计日志（集中日志的特殊形式）
- AWS Systems Manager OpsCenter：基于集中日志的运营问题管理
- [[Centralized Logging]] ← uses ← [[Amazon EventBridge]] ← routes ← [[Amazon CloudWatch Logs]]
---
title: Centralized Logging
type: concept
tags: [DevOps, Observability, CloudOps, AWS]
date: 2025-10-24
---
## Definition
Centralized Logging（集中日志）是一种将分散在多个系统、账户、服务或地理位置的日志汇总到单一中心位置进行统一管理的模式。核心目标是在分布式系统中消除监控盲区，提供全局可观测性。
## Core Properties
- **聚合**：将多个来源的日志合并到单一存储
- **统一查询**：跨来源的集中搜索和分析
- **集中告警**：基于聚合数据的统一告警策略
- **合规保留**：统一的数据保留和合规策略
## Related Concepts
- [[Multi-Account Deployment]]：多账户场景是集中日志的主要驱动因素
- [[Cross-Account Monitoring]]：跨账户监控依赖集中日志基础设施
- [[StackSets Deployment Visibility]]：StackSets 部署可观测性依赖集中日志
- [[Event Sourcing]]：集中日志可以视为事件溯源的一种实现
- [[APM]]（Application Performance Monitoring）：APM 工具通常依赖集中日志数据
- [[CloudWatch Logs]]：AWS 生态系统中的集中日志存储服务
- [[Prometheus]]：时间序列监控，可与集中日志互补
## Implementation Patterns
1. **日志采集层**：Agent/Fluentd/Firelens 收集各来源日志
2. **传输层**：EventBridge/Kinesis/Firehose 传输日志事件
3. **存储层**：CloudWatch Logs/OpenSearch/S3 + Athena
4. **分析层**：CloudWatch Logs Insights/OpenSearch Dashboards/Grafana Loki
5. **告警层**：CloudWatch Alarms/Grafana Alerting/PagerDuty
## AWS Context
- AWS CloudWatch Logs：AWS 原生日志存储和分析服务
- AWS EventBridge：事件驱动的日志采集路由
- AWS CloudTrail：AWS API 调用的审计日志（集中日志的特殊形式）
- AWS Systems Manager OpsCenter：基于集中日志的运营问题管理
- [[Centralized Logging]] ← uses ← [[Amazon EventBridge]] ← routes ← [[Amazon CloudWatch Logs]]

74
wiki/concepts/Chained Agents.md
View File

@@ -1,37 +1,37 @@
---
title: "Chained Agents"
type: concept
tags: [multi-agent, workflow, automation]
sources: [content-factory]
last_updated: 2026-04-22
---
## Definition
Chained Agents（链式 Agent）是一种多 Agent 协作模式，其中上游 Agent 的输出直接作为下游 Agent 的输入，无需人工逐步干预。核心价值在于将复杂任务拆解为多个专业化子任务，通过流水线式编排实现全自动化执行。
## Key Characteristics
- **顺序依赖**：Agent A 输出 → Agent B 输入 → Agent B 输出 → Agent C 输入
- **无需人工中转**：每个环节由 Agent 自动触发和推进
- **可插拔**：可替换任意环节 Agent（如将本地模型替换为 API）
- **透明可查**：通过 Discord 频道等隔离机制，每个 Agent 的工作独立可审查
## Example: Content Factory
```
Research Agent (#research)
→ 输出：Top 5 内容机会（含来源）
↓
Writing Agent (#scripts)
→ 输出：完整脚本/推文串/Newsletter 草稿
↓
Thumbnail Agent (#thumbnails)
→ 输出：AI 生成的缩略图/封面
```
## Related Concepts
- [[Multi-Agent Coordination]]：多 Agent 协作的整体框架
- [[Workflow Architecture]]：工作流架构设计原则
- [[Content Automation]]：内容创作自动化
---
title: "Chained Agents"
type: concept
tags: [multi-agent, workflow, automation]
sources: [content-factory]
last_updated: 2026-04-22
---
## Definition
Chained Agents（链式 Agent）是一种多 Agent 协作模式，其中上游 Agent 的输出直接作为下游 Agent 的输入，无需人工逐步干预。核心价值在于将复杂任务拆解为多个专业化子任务，通过流水线式编排实现全自动化执行。
## Key Characteristics
- **顺序依赖**：Agent A 输出 → Agent B 输入 → Agent B 输出 → Agent C 输入
- **无需人工中转**：每个环节由 Agent 自动触发和推进
- **可插拔**：可替换任意环节 Agent（如将本地模型替换为 API）
- **透明可查**：通过 Discord 频道等隔离机制，每个 Agent 的工作独立可审查
## Example: Content Factory
```
Research Agent (#research)
→ 输出：Top 5 内容机会（含来源）
↓
Writing Agent (#scripts)
→ 输出：完整脚本/推文串/Newsletter 草稿
↓
Thumbnail Agent (#thumbnails)
→ 输出：AI 生成的缩略图/封面
```
## Related Concepts
- [[Multi-Agent Coordination]]：多 Agent 协作的整体框架
- [[Workflow Architecture]]：工作流架构设计原则
- [[Content Automation]]：内容创作自动化

116
wiki/concepts/Challenger-Sales-Model.md
View File

@@ -1,58 +1,58 @@
---
title: "Challenger Sales Model"
type: concept
tags: ["sales", "methodology", "coaching"]
sources: ["sales-coach", "sales-deal-strategist", "sales-outbound-strategist"]
last_updated: 2026-04-25
---
## Definition
Challenger Sales Model 是由 CEB（现 Gartner）开发的高绩效销售方法论，核心洞察是：**最优秀的销售代表通过商业洞察重新构建买家的思考方式**，而不是简单回应买家的已知需求。
## Core Principle
**"Teach, Tailor, Take Control"**
- **Teach for differentiation**: 通过独特的商业洞察引发买家对问题的重新思考
- **Tailor for value**: 根据买家的具体情境定制信息
- **Take Control of the sale**: 主动控制销售节奏和对话方向
## vs Traditional Selling
| 传统销售 | Challenger 销售 |
|---------|----------------|
| 倾听买家需求 | **重构**买家对问题的理解 |
| 以产品功能回应 | 以商业洞察引领 |
| 被动跟随买家节奏 | 主动控制销售过程 |
| 提供解决方案 | 创造新的思考框架 |
## Application in Sales Coaching
[[sales-coach]] 使用 Challenger 模型作为辅导工具：
- 教导销售代表"以商业洞察引领对话"，而非"回应已知需求"
- 核心辅导问题："你能提供什么买家还不知道的洞察？"
- 区分"响应式销售"（买家的思路）和"重构式销售"（改变买家的思路）
## Key Insight
买家通常在接触销售之前已经对解决方案有了初步想法。Challenger 销售不是否定买家的想法，而是在买家思考的基础上添加新的维度，让他们以不同的方式看待自己的业务。
## Deal-Level Application（[[sales-deal-strategist]]）
[[sales-deal-strategist]] 将 Challenger 框架延伸为 **Commercial Teaching（商业教学）六步序列**：
1. **The Warmer**：展示对买方世界的理解，引用行业通用挑战作为信号
2. **The Reframe**：引入挑战买方当前假设的洞察，"大多数公司用X方式处理这个问题，但数据显示为什么规模化后会失败"
3. **Rational Drowning**：量化现状成本，堆叠证据直到当前方法变得不可持续
4. **Emotional Impact**：让痛点个人化。谁每天承受这个痛苦？如果这事没解决，VP 的数字会怎样？
5. **A New Way**：提出替代方法——还不是产品，而是方法论
6. **Your Solution**：此时才连接到产品。"产品"应感觉像是必然结论而非销售话术
核心原则：**永远先重构理解，再展示方案**；决策在理性层面被论证，在感性层面被做出。
## Connections
- [[sales-coach]] ← uses ← [[Challenger Sales Model]]
- [[sales-deal-strategist]] ← uses ← [[Challenger Sales Model]]（Commercial Teaching 六步序列）
- [[MEDDPICC]] ← often used alongside ← [[Challenger Sales Model]]
---
title: "Challenger Sales Model"
type: concept
tags: ["sales", "methodology", "coaching"]
sources: ["sales-coach", "sales-deal-strategist", "sales-outbound-strategist"]
last_updated: 2026-04-25
---
## Definition
Challenger Sales Model 是由 CEB（现 Gartner）开发的高绩效销售方法论，核心洞察是：**最优秀的销售代表通过商业洞察重新构建买家的思考方式**，而不是简单回应买家的已知需求。
## Core Principle
**"Teach, Tailor, Take Control"**
- **Teach for differentiation**: 通过独特的商业洞察引发买家对问题的重新思考
- **Tailor for value**: 根据买家的具体情境定制信息
- **Take Control of the sale**: 主动控制销售节奏和对话方向
## vs Traditional Selling
| 传统销售 | Challenger 销售 |
|---------|----------------|
| 倾听买家需求 | **重构**买家对问题的理解 |
| 以产品功能回应 | 以商业洞察引领 |
| 被动跟随买家节奏 | 主动控制销售过程 |
| 提供解决方案 | 创造新的思考框架 |
## Application in Sales Coaching
[[sales-coach]] 使用 Challenger 模型作为辅导工具：
- 教导销售代表"以商业洞察引领对话"，而非"回应已知需求"
- 核心辅导问题："你能提供什么买家还不知道的洞察？"
- 区分"响应式销售"（买家的思路）和"重构式销售"（改变买家的思路）
## Key Insight
买家通常在接触销售之前已经对解决方案有了初步想法。Challenger 销售不是否定买家的想法，而是在买家思考的基础上添加新的维度，让他们以不同的方式看待自己的业务。
## Deal-Level Application（[[sales-deal-strategist]]）
[[sales-deal-strategist]] 将 Challenger 框架延伸为 **Commercial Teaching（商业教学）六步序列**：
1. **The Warmer**：展示对买方世界的理解，引用行业通用挑战作为信号
2. **The Reframe**：引入挑战买方当前假设的洞察，"大多数公司用X方式处理这个问题，但数据显示为什么规模化后会失败"
3. **Rational Drowning**：量化现状成本，堆叠证据直到当前方法变得不可持续
4. **Emotional Impact**：让痛点个人化。谁每天承受这个痛苦？如果这事没解决，VP 的数字会怎样？
5. **A New Way**：提出替代方法——还不是产品，而是方法论
6. **Your Solution**：此时才连接到产品。"产品"应感觉像是必然结论而非销售话术
核心原则：**永远先重构理解，再展示方案**；决策在理性层面被论证，在感性层面被做出。
## Connections
- [[sales-coach]] ← uses ← [[Challenger Sales Model]]
- [[sales-deal-strategist]] ← uses ← [[Challenger Sales Model]]（Commercial Teaching 六步序列）
- [[MEDDPICC]] ← often used alongside ← [[Challenger Sales Model]]

166
wiki/concepts/Change-Failure-Rate.md
View File

@@ -1,83 +1,83 @@
# Change Failure Rate
## Definition
Change Failure Rate (CFR) is the percentage of deployments that cause failures in production — such as service outages, degraded performance, or incidents requiring hotfixes, rollbacks, or patches.
Change Failure Rate is one of the four core **DORA metrics** used to measure DevOps performance.
## Why Change Failure Rate Matters
A low change failure rate indicates:
- High confidence in the deployment process
- Robust testing and quality assurance
- Effective risk management
- Mature operational practices
A high change failure rate means:
- Frequent production incidents
- Unstable deployments
- Low team confidence
- Customer impact
## Across DevOps Maturity Levels
| Maturity | Change Failure Rate Characteristic |
|----------|-----------------------------------|
| Phase 1 | High — manual processes, no automated testing, siloed teams, security only at release |
| Phase 2 | Improving — unit, integration, and end-to-end tests implemented, but security separate |
| Phase 3 | Lower — automated infrastructure, security scans integrated throughout development |
| Phase 4 | Significantly reduced — performance/load testing, immutable infrastructure, dependency vulnerability management |
| Phase 5 | 0-15% (elite) — zero human intervention, real-time data decisions, high-level security integration prevents non-compliant code |
## Elite Performance Benchmark (DORA)
- **Elite performers**: 0-15% change failure rate
- **High performers**: 16-30% change failure rate
- **Medium performers**: 16-30% change failure rate
- **Low performers**: 31-100% change failure rate
## Types of Failed Changes
- Production outages
- Service degradations
- Data corruption
- Security vulnerabilities introduced
- Performance regressions
- Failed rollbacks
## How to Reduce Change Failure Rate
### Technical Practices
- Comprehensive test automation (unit, integration, E2E)
- Feature flags for gradual rollouts
- Canary deployments
- Blue-green deployments
- Automated rollback mechanisms
- Chaos engineering to find weaknesses before production
### Process Improvements
- Code review requirements
- Security scanning in CI/CD pipeline
- Staging environment parity with production
- Small batch sizes to limit blast radius
- Dependency management and vulnerability scanning
### Cultural Factors
- Blameless post-mortems
- Learning from failures
- Psychological safety to report issues
- Shared ownership of reliability
## Relationship with Other DORA Metrics
- **Deployment Frequency**: Higher frequency with lower CFR indicates elite performance
- **Lead Time**: Shorter lead times with maintained/low CFR = high performance
- **MTTR**: Lower CFR means fewer incidents, contributing to lower overall MTTR
## Sources
- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]]
- [[sources/cloud-devop-maturity-guideline.md]]
## Related Concepts
- [[concepts/DORA-Metrics]]
- [[concepts/Continuous-Deployment]]
- [[concepts/DevOps-Maturity]]
- [[concepts/Error-Budget]]
- [[concepts/Rollback-Rate]]
# Change Failure Rate
## Definition
Change Failure Rate (CFR) is the percentage of deployments that cause failures in production — such as service outages, degraded performance, or incidents requiring hotfixes, rollbacks, or patches.
Change Failure Rate is one of the four core **DORA metrics** used to measure DevOps performance.
## Why Change Failure Rate Matters
A low change failure rate indicates:
- High confidence in the deployment process
- Robust testing and quality assurance
- Effective risk management
- Mature operational practices
A high change failure rate means:
- Frequent production incidents
- Unstable deployments
- Low team confidence
- Customer impact
## Across DevOps Maturity Levels
| Maturity | Change Failure Rate Characteristic |
|----------|-----------------------------------|
| Phase 1 | High — manual processes, no automated testing, siloed teams, security only at release |
| Phase 2 | Improving — unit, integration, and end-to-end tests implemented, but security separate |
| Phase 3 | Lower — automated infrastructure, security scans integrated throughout development |
| Phase 4 | Significantly reduced — performance/load testing, immutable infrastructure, dependency vulnerability management |
| Phase 5 | 0-15% (elite) — zero human intervention, real-time data decisions, high-level security integration prevents non-compliant code |
## Elite Performance Benchmark (DORA)
- **Elite performers**: 0-15% change failure rate
- **High performers**: 16-30% change failure rate
- **Medium performers**: 16-30% change failure rate
- **Low performers**: 31-100% change failure rate
## Types of Failed Changes
- Production outages
- Service degradations
- Data corruption
- Security vulnerabilities introduced
- Performance regressions
- Failed rollbacks
## How to Reduce Change Failure Rate
### Technical Practices
- Comprehensive test automation (unit, integration, E2E)
- Feature flags for gradual rollouts
- Canary deployments
- Blue-green deployments
- Automated rollback mechanisms
- Chaos engineering to find weaknesses before production
### Process Improvements
- Code review requirements
- Security scanning in CI/CD pipeline
- Staging environment parity with production
- Small batch sizes to limit blast radius
- Dependency management and vulnerability scanning
### Cultural Factors
- Blameless post-mortems
- Learning from failures
- Psychological safety to report issues
- Shared ownership of reliability
## Relationship with Other DORA Metrics
- **Deployment Frequency**: Higher frequency with lower CFR indicates elite performance
- **Lead Time**: Shorter lead times with maintained/low CFR = high performance
- **MTTR**: Lower CFR means fewer incidents, contributing to lower overall MTTR
## Sources
- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]]
- [[sources/cloud-devop-maturity-guideline.md]]
## Related Concepts
- [[concepts/DORA-Metrics]]
- [[concepts/Continuous-Deployment]]
- [[concepts/DevOps-Maturity]]
- [[concepts/Error-Budget]]
- [[concepts/Rollback-Rate]]

118
wiki/concepts/Change-Management.md
View File

@@ -1,59 +1,59 @@
---
title: "Change-Management"
type: concept
tags: [Organizational-Change, Process-Improvement, ITSM]
sources: [testing-workflow-optimizer, understanding-complete-itsm]
last_updated: 2026-04-21
---
# Change-Management
变更管理——在组织中系统性地规划、实施和控制人员、流程和技术变更的管理学科。核心目标是降低变更风险、提高采纳率、确保变革产生预期业务价值，同时最小化对现有服务运营的干扰。
## Aliases
- 变革管理
- 组织变革管理
- IT Change Management（ITSM 语境）
## Core Frameworks
### Kotter's 8-Step Change Model
1. **Create Urgency**（创造紧迫感）——让利益相关者认识到变革必要性
2. **Build Guiding Coalition**（组建指导联盟）——建立变革领导团队
3. **Form Strategic Vision**（形成战略愿景）——清晰描述变革后的未来状态
4. **Enlist a Volunteer Army**（动员志愿者）——让尽可能多的人参与
5. **Enable Action by Removing Barriers**（消除障碍）——移除阻碍变革的结构性和文化性壁垒
6. **Generate Short-Term Wins**（创造短期胜利）——通过快速成果建立信心
7. **Sustain Acceleration**（持续加速）——保持势头，不给反对派喘息空间
8. **Institute Change**（固化变革）——将变革融入组织文化
### ADKAR Model（Prosci）
- **A**wareness（认知）——了解为什么需要变革
- **D**esire（渴望）——愿意参与和支持变革
- **K**nowledge（知识）——知道如何变革
- **A**bility（能力）——能够实施新行为
- **R**einforcement（强化）——巩固变革成果
## In ITSM Context（ITIL Change Management）
在 ITSM 框架中，变更管理分为：
- **标准变更（Standard Change）**：预批准的低风险例行变更
- **正常变更（Normal Change）**：需经 CAB（变更顾问委员会）评估和批准
- **紧急变更（Emergency Change）**：突发事件驱动的快速变更，事后评估
## In Workflow Optimization
[[testing-workflow-optimizer]] 在实施流程优化时必须考虑变更管理：
- **测量基线**前先建立利益相关者共识
- **设计优化方案**需要获得关键干系人认同
- **实施规划**必须包含培训和沟通计划
- **自动化落地**需要克服员工的恐惧和阻力
## Common Pitfalls
- **变革疲劳（Change Fatigue）**：频繁变更导致员工抵触
- **忽略人因素**：只关注流程和技术，忽视人的情感
- **缺乏可见成果**：没有短期胜利导致失去支持
- **变革太快或太慢**：节奏失控
## Connections
- [[testing-workflow-optimizer]] — 流程优化落地的必要保障机制
- [[ITSM]] — ITSM 框架中的三大核心流程之一
- [[Kaizen]] — 持续改进需要有效的变更管理支撑
---
title: "Change-Management"
type: concept
tags: [Organizational-Change, Process-Improvement, ITSM]
sources: [testing-workflow-optimizer, understanding-complete-itsm]
last_updated: 2026-04-21
---
# Change-Management
变更管理——在组织中系统性地规划、实施和控制人员、流程和技术变更的管理学科。核心目标是降低变更风险、提高采纳率、确保变革产生预期业务价值，同时最小化对现有服务运营的干扰。
## Aliases
- 变革管理
- 组织变革管理
- IT Change Management（ITSM 语境）
## Core Frameworks
### Kotter's 8-Step Change Model
1. **Create Urgency**（创造紧迫感）——让利益相关者认识到变革必要性
2. **Build Guiding Coalition**（组建指导联盟）——建立变革领导团队
3. **Form Strategic Vision**（形成战略愿景）——清晰描述变革后的未来状态
4. **Enlist a Volunteer Army**（动员志愿者）——让尽可能多的人参与
5. **Enable Action by Removing Barriers**（消除障碍）——移除阻碍变革的结构性和文化性壁垒
6. **Generate Short-Term Wins**（创造短期胜利）——通过快速成果建立信心
7. **Sustain Acceleration**（持续加速）——保持势头，不给反对派喘息空间
8. **Institute Change**（固化变革）——将变革融入组织文化
### ADKAR Model（Prosci）
- **A**wareness（认知）——了解为什么需要变革
- **D**esire（渴望）——愿意参与和支持变革
- **K**nowledge（知识）——知道如何变革
- **A**bility（能力）——能够实施新行为
- **R**einforcement（强化）——巩固变革成果
## In ITSM Context（ITIL Change Management）
在 ITSM 框架中，变更管理分为：
- **标准变更（Standard Change）**：预批准的低风险例行变更
- **正常变更（Normal Change）**：需经 CAB（变更顾问委员会）评估和批准
- **紧急变更（Emergency Change）**：突发事件驱动的快速变更，事后评估
## In Workflow Optimization
[[testing-workflow-optimizer]] 在实施流程优化时必须考虑变更管理：
- **测量基线**前先建立利益相关者共识
- **设计优化方案**需要获得关键干系人认同
- **实施规划**必须包含培训和沟通计划
- **自动化落地**需要克服员工的恐惧和阻力
## Common Pitfalls
- **变革疲劳（Change Fatigue）**：频繁变更导致员工抵触
- **忽略人因素**：只关注流程和技术，忽视人的情感
- **缺乏可见成果**：没有短期胜利导致失去支持
- **变革太快或太慢**：节奏失控
## Connections
- [[testing-workflow-optimizer]] — 流程优化落地的必要保障机制
- [[ITSM]] — ITSM 框架中的三大核心流程之一
- [[Kaizen]] — 持续改进需要有效的变更管理支撑

60
wiki/concepts/Channel-Based-Monitoring.md
View File

@@ -1,30 +1,30 @@
---
title: "Channel-Based Monitoring"
type: concept
tags: [Channel, Monitoring, YouTube, RSS, Subscription]
sources: [daily-youtube-digest, how-to-get-youtube-channel-id, how-to-get-the-rss-feed-for-any-youtube-channel]
last_updated: 2026-04-22
---
## Definition
Channel-Based Monitoring 是一种以订阅频道为单位跟踪内容更新的策略——用户明确指定感兴趣的频道列表，AI Agent 定期检查这些频道的最新上传，而非被动依赖平台推荐算法。
## Why Not Just Use YouTube Notifications?
YouTube 通知系统不可靠：订阅频道的新视频经常不会出现在通知或首页推荐中，被平台算法压制。Channel-Based Monitoring 通过主动检查（RSS Feed / API）绕过这一限制。
## Implementation
- **RSS Feed**: `https://www.youtube.com/feeds/videos.xml?channel_id=<ID>`
- **TranscriptAPI**: `channel/latest` API（免费，0 积分）
- **yt-dlp**: `--flat-playlist` 模式
### Getting Channel ID
参考 [[how-to-get-youtube-channel-id]]：在浏览器地址栏打开 `view-source:https://www.youtube.com/@ChannelName`，搜索 `channel_id` 字符串即可获得 RSS Feed URL。
## Connections
- [[Channel-Based Monitoring]] ← powers ← [[Daily YouTube Digest]]
- [[RSS Feed]] ← feeds ← [[Channel-Based Monitoring]]
- [[Keyword-Based Monitoring]] ← complements ← [[Channel-Based Monitoring]]
---
title: "Channel-Based Monitoring"
type: concept
tags: [Channel, Monitoring, YouTube, RSS, Subscription]
sources: [daily-youtube-digest, how-to-get-youtube-channel-id, how-to-get-the-rss-feed-for-any-youtube-channel]
last_updated: 2026-04-22
---
## Definition
Channel-Based Monitoring 是一种以订阅频道为单位跟踪内容更新的策略——用户明确指定感兴趣的频道列表，AI Agent 定期检查这些频道的最新上传，而非被动依赖平台推荐算法。
## Why Not Just Use YouTube Notifications?
YouTube 通知系统不可靠：订阅频道的新视频经常不会出现在通知或首页推荐中，被平台算法压制。Channel-Based Monitoring 通过主动检查（RSS Feed / API）绕过这一限制。
## Implementation
- **RSS Feed**: `https://www.youtube.com/feeds/videos.xml?channel_id=<ID>`
- **TranscriptAPI**: `channel/latest` API（免费，0 积分）
- **yt-dlp**: `--flat-playlist` 模式
### Getting Channel ID
参考 [[how-to-get-youtube-channel-id]]：在浏览器地址栏打开 `view-source:https://www.youtube.com/@ChannelName`，搜索 `channel_id` 字符串即可获得 RSS Feed URL。
## Connections
- [[Channel-Based Monitoring]] ← powers ← [[Daily YouTube Digest]]
- [[RSS Feed]] ← feeds ← [[Channel-Based Monitoring]]
- [[Keyword-Based Monitoring]] ← complements ← [[Channel-Based Monitoring]]

Some files were not shown because too many files have changed in this diff Show More