remove wiki
This commit is contained in:
@@ -1,27 +0,0 @@
|
||||
---
|
||||
title: "Charlie Munger"
|
||||
type: entity
|
||||
tags: [investing, strategy, mental-models]
|
||||
sources: [zk-steward]
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Munger
|
||||
- Charles Munger
|
||||
|
||||
## Overview
|
||||
Charlie Munger（1924–2023）是伯克希尔·哈撒韦副主席、巴菲特最重要的人生搭档，被誉为"最伟大的思想家之一"。他的核心方法论是"Mental Models"（心智模型网格）和"Inversion"（倒置法）——先想清楚如何失败再想如何成功。
|
||||
|
||||
## Core Method
|
||||
- **Mental Models Grid**：跨学科心智模型网格（物理学、经济学、心理学、工程学等），用多元框架理解世界
|
||||
- **Inversion**：先想清楚如何失败，然后避免它；"我唯一知道的就是我会死在哪里，这样我就永远不会去那里"
|
||||
- **Lollapalooza Effect**：当多个心智模型同时指向同一方向时，产生巨大的叠加效应
|
||||
|
||||
## Role in ZK Steward
|
||||
ZK Steward 在"商业策略"任务中切换到 Munger 视角，使用 mental models 和 inversion 进行多角度分析。
|
||||
|
||||
## Key Connections
|
||||
- [[ZK-Steward-Agent]] ← uses Munger perspective for business strategy tasks
|
||||
- [[Domain-Thinking]] ← Munger is the reference expert for business strategy domain
|
||||
- [[Luhmann-四原则]] ← Munger 的 mental models 网格与"避免过度结构化"存在张力（Munger 倾向预设框架）
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
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种视觉风格系统]]
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: "2D-First Spatial-Second"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-03-05
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
2D-First Spatial-Second（2D 先行，空间渐进）是 [[nexus-spatial-discovery]] 定义的 [[Nexus Spatial]] 产品分阶段策略——先用高质量 2D Web 仪表盘建立市场，再渐进叠加空间计算能力，而非一开始就押注空间硬件。
|
||||
|
||||
## Strategic Rationale
|
||||
|
||||
**现实约束：**
|
||||
- Vision Pro 全球安装量仅约 100 万台，销量较峰值下跌 95%
|
||||
- 现有 AI Agent 编排工具用户已习惯 2D 工作流
|
||||
- 空间计算的学习曲线对早期采用者构成障碍
|
||||
|
||||
**市场机会：**
|
||||
- WebXR 已获得主流浏览器支持（Safari 2025 年底支持 WebXR Device API）
|
||||
- 2D → 2.5D → 3D 的渐进路径降低用户接受门槛
|
||||
- Web 平台可触达所有设备，无需额外硬件
|
||||
|
||||
## Three-Phase Roadmap
|
||||
|
||||
| 阶段 | 时间 | 产品形态 | 目标 |
|
||||
|------|------|---------|------|
|
||||
| **Phase 1** | 月 1–6 | 2D Web 仪表盘 + Three.js 2.5D | 50 个付费团队，$60K MRR |
|
||||
| **Phase 2** | 月 6–12 | WebXR 空间模式（可选） | 200 个团队，$300K MRR |
|
||||
| **Phase 3** | 月 12–18 | VisionOS 原生应用（按需） | 500 个团队，$1M+ MRR |
|
||||
|
||||
## Cross-Agent Consensus
|
||||
|
||||
该策略是 8 个专业 AI Agent **独立达成的一致结论**：
|
||||
- Product Trend Researcher：Vision Pro 市场数据不支持早期押注
|
||||
- Backend Architect：WebXR 是更合理的架构路径
|
||||
- Brand Guardian：2D 先行不影响空间品牌叙事
|
||||
- UX Researcher：渐进披露符合空间学习曲线
|
||||
- XR Interface Architect：WebXR 分发更广泛
|
||||
|
||||
## Key Tension
|
||||
|
||||
> **MVP scope**：Architecture（Phase 1 仅 2D）vs. Brand（演示需要强调空间价值）
|
||||
|
||||
**Resolution**：2D 先行，但所有 Demo 始终包含空间预览——用 2D 建立用户，用空间区分自己。
|
||||
|
||||
## Connections
|
||||
|
||||
- [[SpatialAIOps]] ← 战略框架
|
||||
- [[Nexus Spatial]] ← 落地产品
|
||||
- [[WebXR]] ← 技术基础
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
title: "3-2-1产品介绍公式"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
# 3-2-1产品介绍公式
|
||||
|
||||
## Aliases
|
||||
- 321 Formula
|
||||
- 快手直播话术框架
|
||||
- 3-2-1 Script Formula
|
||||
|
||||
## Definition
|
||||
快手直播带货的核心产品介绍话术框架，通过"3个痛点→2个演示→1个不可抗拒报价"的结构，在短时间内建立信任并驱动购买决策。
|
||||
|
||||
## Formula Breakdown
|
||||
|
||||
### Step 1: 3 Pain Points（3个痛点）
|
||||
以共情开场，让观众产生共鸣：
|
||||
> "老铁们，你们是不是也遇到过..."
|
||||
|
||||
通过日常生活场景的痛点描述，拉近与观众的距离，建立情感连接。
|
||||
|
||||
### Step 2: 2 Demonstrations（2个产品演示）
|
||||
用现场测试展示产品真实效果：
|
||||
- 展示产品真实使用场景
|
||||
- 对比使用前/使用后效果
|
||||
- 强调产品质量和真实细节
|
||||
|
||||
核心原则：**真实可信**，不夸大效果，粉丝能即时发现虚假演示。
|
||||
|
||||
### Step 3: 1 Irresistible Offer（1个不可抗拒报价）
|
||||
揭晓价格时提供明确价值对比：
|
||||
- 价格揭晓 + 限时优惠
|
||||
- 与线下渠道对比
|
||||
- 与历史价格对比
|
||||
- 库存紧迫感："只有100单"
|
||||
|
||||
## Key Trust-Building Phrases
|
||||
- "老铁们放心，这个东西我自己家里也在用"
|
||||
- "不好用直接来找我，我给你退"
|
||||
- "今天这个价格我跟厂家磨了两个星期"
|
||||
|
||||
## Related
|
||||
- [[直播带货]]：3-2-1公式是直播带货的核心话术工具
|
||||
- [[Marketing-Kuaishou-Strategist]]：快手策略师的标准话术交付物
|
||||
- [[老铁经济]]：公式背后是信任驱动的销售逻辑
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "4-Level Semantic Zoom"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-03-05
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
4-Level Semantic Zoom（四层级语义缩放）是 [[nexus-spatial-discovery]] 中 [[Nexus Spatial]] 产品的导航范式——用户通过语义级别的缩放，在不同抽象层次间流畅切换，从全局舰队视角到单步执行追踪。
|
||||
|
||||
## Four Levels
|
||||
|
||||
| 层级 | 用户视角 | 信息密度 | 典型任务 |
|
||||
|------|---------|---------|---------|
|
||||
| **Fleet View**（舰队视图） | 所有工作流作为抽象形状 | 极低（颜色+状态） | 跨系统健康检查 |
|
||||
| **Workflow View**（工作流视图） | 节点图 + 标签 + 连接线 | 中等（拓扑结构） | 工作流设计/编辑 |
|
||||
| **Node View**（节点视图） | 扩展配置 + 近 I/O + 状态指标 | 高（单节点详情） | 节点调试/配置 |
|
||||
| **Trace View**（追踪视图） | 完整执行追踪 + 数据检查 | 极高（全链路数据） | 深度调试/根因分析 |
|
||||
|
||||
## Design Rationale
|
||||
|
||||
1. **语义对齐而非像素对齐**：缩放的是信息抽象层次，而非物理尺寸
|
||||
2. **与物理空间对应**：Fleet View → 远景（背景）→ Trace View → 近景（前景）
|
||||
3. **减少认知负荷**：用户始终看到"此刻需要关注的信息量"
|
||||
4. **过渡有目的**：每次缩放都是一次导航决策，而非平移
|
||||
|
||||
## Transition Choreography
|
||||
|
||||
| 过渡 | 时长 | 关键动作 |
|
||||
|------|------|---------|
|
||||
| Overview → Focus | 600ms | 相机漂移到目标，其他区域淡出至 30% |
|
||||
| Focus → Detail | 500ms | 节点滑出扩展，连接线高亮 |
|
||||
| Detail → Overview | 600ms | 面板收起，节点退后，全拓扑可见 |
|
||||
| Zone Switch | 500ms | 当前区域侧向滑出，新区域滑入 |
|
||||
| Window → Immersive | 1000ms | 边框溶解，节点展开至完整空间位置 |
|
||||
|
||||
## Connections
|
||||
|
||||
- [[SpatialAIOps]] ← 导航范式
|
||||
- [[Command-Theater]] ← 空间布局
|
||||
- [[Nexus Spatial]] ← 落地产品
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: "6-Slide Narrative Arc"
|
||||
type: concept
|
||||
tags: ["content-strategy", "carousel", "storytelling", "tiktok", "instagram"]
|
||||
sources: ["marketing-carousel-growth-engine"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
标准化的 6 张幻灯片轮播图叙事结构，用于 TikTok 和 Instagram 轮播内容。每个阶段有明确目标，确保内容具备叙事张力和传播力。
|
||||
|
||||
## Structure
|
||||
|
||||
| Slide | Name | Role | Focus |
|
||||
|-------|------|------|-------|
|
||||
| 1 | Hook | 截停滚动 | 问题/疑问/大胆声明/痛点 |
|
||||
| 2 | Problem | 问题深化 | 受众面临的具体挑战 |
|
||||
| 3 | Agitation | 激化痛点 | 竞品对比/未解决的后果 |
|
||||
| 4 | Solution | 解决方案 | 核心价值主张 |
|
||||
| 5 | Feature | 功能展示 | 关键特性/数据/社会证明 |
|
||||
| 6 | CTA | 行动号召 | 明确的转化路径 |
|
||||
|
||||
## Key Rules
|
||||
|
||||
- **Slide 1 决定一切**: 必须截停滚动——使用问题、大胆声明或痛点共鸣
|
||||
- **叙事连贯**: 6 张幻灯片构成完整的"问题-解决"故事弧
|
||||
- **视觉连贯**: Slide 1 定义所有视觉风格，Slides 2-6 保持一致
|
||||
- **底部 20% 空白**: TikTok 控件占位，文字不可放在底部 20%
|
||||
- **格式**: 仅 JPG（TikTok 拒绝 PNG）；768×1376 (9:16 竖版)
|
||||
|
||||
## 变体
|
||||
|
||||
- **Pain Point Hook**: 以受众具体痛点开头
|
||||
- **Question Hook**: 以引发思考的问题开头
|
||||
- **Bold Claim Hook**: 以大胆/反直觉声明开头
|
||||
- **数据钩子**: 以惊人数据开头
|
||||
|
||||
## Usage in [[marketing-carousel-growth-engine]]
|
||||
|
||||
[[marketing-carousel-growth-engine]] 强制使用此结构，所有轮播内容不得偏离这一经过验证的叙事结构。
|
||||
|
||||
## Aliases
|
||||
- 6-Slide Structure
|
||||
- Carousel Arc
|
||||
- Narrative Carousel
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: "7-Layer Harness Stack"
|
||||
type: concept
|
||||
tags:
|
||||
- "harness-engineering"
|
||||
- "agentic-ai"
|
||||
- "system-design"
|
||||
sources:
|
||||
- "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Overview
|
||||
7层 Harness Stack——production-grade AI Agent 系统的分层架构规范，从认知层到约束恢复层的完整 7 层结构。
|
||||
|
||||
## Structure
|
||||
|
||||
| Layer | Name | Core Function |
|
||||
|-------|------|--------------|
|
||||
| 1 | Cognition | 受限操作边界，role file/job description |
|
||||
| 2 | Tools | 工具输出排序/去重/token 预算截断 |
|
||||
| 3 | Contracts & Interfaces | JSON Schema 边界验证，防 Schema Drift |
|
||||
| 4 | Orchestration | DAG/状态机约束允许的动作 |
|
||||
| 5 | Memory & State | Working Memory + Persistent State 分层 |
|
||||
| 6 | Evaluation & Observation | 异构验证（规则/工具/LLM-as-judge）|
|
||||
| 7 | Constraints & Recovery | 幂等重试，Context Reset 机制 |
|
||||
|
||||
## Principles
|
||||
- 模型在 Harness 内部，不直接对用户或外部世界说话
|
||||
- 每个边界交叉处有显式契约：严格 JSON Schema / 类型化函数签名 / 版本化 API spec
|
||||
- 每一层产生可被模型以外的东西验证的输出
|
||||
|
||||
## Related Concepts
|
||||
- [[Harness-Engineering]] — 父概念，本框架所属的工程学科
|
||||
- [[Context-Reset]] — 第 7 层 Constraints & Recovery 的关键机制
|
||||
- [[Sprint-Contract]] — 第 6 层 Evaluation 的关键机制
|
||||
- [[Schema-Drift]] — 第 3 层 Contracts 要解决的核心问题
|
||||
|
||||
## Source
|
||||
- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: "ABM Display"
|
||||
type: concept
|
||||
tags: ["abm", "b2b", "display", "account-based-marketing", "paid-media"]
|
||||
sources: ["paid-media-programmatic-buyer"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
ABM Display（Account-Based Display Advertising）是一种基于账户的展示广告策略，通过特定平台（Demandbase、6Sense、RollWorks 等）识别和定向目标企业账户，实现对特定公司决策者的精准触达。区别于传统基于人口统计或行为的展示广告，ABM Display 以企业账户为基本定向单元。
|
||||
|
||||
## Core Workflow
|
||||
|
||||
1. **Account List Upload**：上传目标企业账户列表（通常基于 CRM 数据）
|
||||
2. **Firmographic Enrichment**：通过 firmographic 数据（公司规模、行业、收入等）丰富账户画像
|
||||
3. **Intent Signal Processing**：利用意图数据（6Sense 等）识别主动研究解决方案的账户
|
||||
4. **Engagement Scoring**：对账户内的不同决策者进行参与度评分
|
||||
5. **CRM-to-Display Activation**：将评分结果激活到 DSP/ABM 平台进行定向投放
|
||||
6. **Cross-Channel Orchestration**：与销售团队协同，实现广告触达与销售跟进的时间协同
|
||||
|
||||
## Key Platforms
|
||||
|
||||
- **Demandbase**：基于 firmographic 的企业账户定向，覆盖 50+ B2B 数据维度
|
||||
- **6Sense**：意图数据和账户参与度评分，支持营销归因
|
||||
- **RollWorks**：经济实惠的 ABM 广告激活平台
|
||||
|
||||
## Success Metrics
|
||||
|
||||
- **Reach Against Target**：目标账户列表触达率（目标 ≥60% 在活动期间触达）
|
||||
- **Engagement Depth**：账户内触达的决策者层级数量
|
||||
- **Pipeline Attribution**：90 天窗口内的正向管道归因
|
||||
|
||||
## Related Concepts
|
||||
- [[Programmatic Buying]]
|
||||
- [[Firmographic Targeting]]
|
||||
- [[Intent Data]]
|
||||
|
||||
## Sources
|
||||
- [[paid-media-programmatic-buyer]]
|
||||
@@ -1,105 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
title: "ACOS"
|
||||
type: concept
|
||||
tags:
|
||||
- amazon
|
||||
- advertising
|
||||
- ppc
|
||||
- metrics
|
||||
- ecommerce
|
||||
sources:
|
||||
- marketing-cross-border-ecommerce
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- ACOS
|
||||
- Advertising Cost of Sales
|
||||
- 广告成本占销售额比例
|
||||
|
||||
## Definition
|
||||
|
||||
ACOS（Advertising Cost of Sales，广告成本占销售额比例）是衡量亚马逊 PPC 广告效率的核心指标，计算公式为：`ACOS = 广告花费 / 广告带来的销售额 × 100%`。ACOS 越低，表示广告效率越高。
|
||||
|
||||
## Formula
|
||||
|
||||
```
|
||||
ACOS = (广告花费 / 广告带来的销售额) × 100%
|
||||
TACOS = 总广告花费（含站内外）/ 总销售额 × 100%
|
||||
```
|
||||
|
||||
## Interpretation
|
||||
|
||||
| ACOS 区间 | 含义 | 适用阶段 |
|
||||
|-----------|------|----------|
|
||||
| < 15% | 高效广告 | 成熟期产品，利润率充足的品类 |
|
||||
| 15-25% | 健康范围 | 成长期产品，平衡增长与利润 |
|
||||
| 25-35% | 可接受 | 新品推广期，侧重增长 |
|
||||
| > 35% | 需优化 | 超毛利率则必须关停或大幅调整 |
|
||||
|
||||
## Key Principles
|
||||
|
||||
- **ACOS 硬性底线**：任何超过毛利率的广告活动必须优化或关停
|
||||
- **TACOS < 10%**：成熟期产品目标，反映广告依赖度降低
|
||||
- **分阶段调控**：新品期允许高 ACOS 换增长，成熟期压低 ACOS 保利润
|
||||
- **负关键词策略**：持续否定非转化词，降低无效花费
|
||||
|
||||
## Connections
|
||||
- [[TACOS]] ← related_metric ← [[ACOS]]
|
||||
- [[Amazon Ads]] ← platform ← [[ACOS]] (measurement occurs within Amazon PPC)
|
||||
- [[Marketing Cross-Border E-Commerce Specialist]] ← uses ← [[ACOS]]
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
title: "ADDIE Model"
|
||||
type: concept
|
||||
tags: [instructional-design, learning-theory]
|
||||
sources: [corporate-training-designer]
|
||||
last_updated: 2026-05-29
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
ADDIE 模型是企业教学设计（Instructional Systems Design, ISD）的经典五阶段框架，代表 **Analysis（分析）→ Design（设计）→ Development（开发）→ Implementation（实施）→ Evaluation（评估）** 五个阶段，每阶段有明确的输入/输出交付物。
|
||||
|
||||
## Phases
|
||||
|
||||
### A — Analysis（分析）
|
||||
- 组织诊断：战略解码、业务痛点映射、人才盘点
|
||||
- 能力差距分析：建立岗位胜任力模型（知识/技能/态度），通过360度评估、绩效数据、主管访谈定位能力缺口
|
||||
- 培训 ROI 估算：基于业务指标（人均生产力、质量合格率、客户满意度等）估算培训投资回报
|
||||
- 需求优先级：紧迫性×重要性矩阵——区分"必须培训"、"应该培训"和"可自学"
|
||||
|
||||
### D — Design（设计）
|
||||
- 选择教学策略和学习形式（线上/线下/混合）
|
||||
- 设计课程大纲和学习路径
|
||||
- 准备培训计划、讲师安排、场地和材料需求
|
||||
- 准备培训预算
|
||||
|
||||
### D — Development（开发）
|
||||
- 访谈主题专家，萃取关键知识和经验
|
||||
- 开发课件、案例、练习和评估题库
|
||||
- 内部评审和试讲——收集反馈并迭代
|
||||
|
||||
### I — Implementation（实施）
|
||||
- 训前：学员通知、预习任务推送、学习平台配置
|
||||
- 训中：课堂授课、互动管理、实时学习效果检查
|
||||
- 训后：作业布置、行动计划制定、学习社群建立
|
||||
|
||||
### E — Evaluation（评估）
|
||||
- 收集培训满意度和学习评估数据
|
||||
- 追踪训后行为改变和业务指标变化
|
||||
- 产出培训效果报告和改进建议
|
||||
- 固化最佳实践，更新课程资源库
|
||||
|
||||
## Key Principles
|
||||
- **阶段门控（Gate）**：每个阶段完成后必须通过评审才能进入下一阶段，确保质量
|
||||
- **迭代性**：在实际项目（尤其是快速迭代场景）可与 [[SAM-Model]] 混合使用
|
||||
- **以终为始**：从评估阶段开始反向设计（Backward Design），确保所有学习活动都指向可测量的目标
|
||||
|
||||
## Connections
|
||||
- [[ADDIE-Model]] ← foundational_model ← [[SAM-Model]]（SAM 是 ADDIE 的快速迭代变体，适合敏捷场景）
|
||||
- [[Bloom-Taxonomy]] ← learning_objective_framework ← [[ADDIE-Model]]（ADDIE 的设计阶段使用 Bloom 分类定义学习目标）
|
||||
- [[Kirkpatrick-Model]] ← evaluation_framework ← [[ADDIE-Model]]（ADDIE 的 E 阶段通常采用 Kirkpatrick 四级评估）
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "ADM"
|
||||
type: concept
|
||||
tags: [AWS, Governance, Architecture]
|
||||
last_updated: 2026-05-07
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
ADM stands for **Architecture Decision Management** — the governance process for managing architecture decisions within an enterprise cloud environment. In the context of [[ctp-topic-50-ami-roadmap-for-aws-amis]], ADM is the primary driver for prioritizing the [[ARM-AMI]] roadmap.
|
||||
|
||||
## Role in AMI Governance
|
||||
|
||||
The [[CCOE]] AMI roadmap prioritization is primarily driven by ADM requirements. Any changes to roadmap prioritization must go through the demand pipeline process:
|
||||
|
||||
> "The order was created mainly by ADM requirements. Any requirements to change the prioritization of the roadmap should go through the demand pipeline process." — [[ctp-topic-50-ami-roadmap-for-aws-amis]]
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Foundation-AMI]]: CCOE-provided hardened base images
|
||||
- [[OS-End-of-Life]]: OS lifecycle management that feeds into ADM decision-making
|
||||
- [[CCOE]]: Organization responsible for AMI governance and roadmap maintenance
|
||||
|
||||
## Connections
|
||||
|
||||
- [[ctp-topic-50-ami-roadmap-for-aws-amis]] → AMI roadmap is primarily driven by ADM requirements
|
||||
- [[ctp-topic-26-standard-ami-build-publish-share-processes]] → ADM decisions influence Foundation AMI feature set
|
||||
- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] → demand pipeline process for changing priorities
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: "AGENTS.md"
|
||||
type: concept
|
||||
tags: [opencode, ai, project-context, documentation]
|
||||
sources: [如何在ubuntu上安装opencode并配置vibe-kanban]
|
||||
last_updated: 2026-04-27
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
**AGENTS.md** 是 OpenCode 等 AI 编程代理为项目自动生成的角色定义文件，包含项目结构、编码规范和最佳实践，帮助 AI 理解项目上下文，生成更准确、更符合团队风格的代码。
|
||||
|
||||
## Purpose
|
||||
|
||||
当运行 `opencode /init` 时，OpenCode 会分析项目结构并自动生成 `AGENTS.md` 文件。该文件记录：
|
||||
- 项目目录结构
|
||||
- 编码规范和约定
|
||||
- 使用的技术栈
|
||||
- 项目的特殊要求或约束
|
||||
|
||||
## Best Practice
|
||||
|
||||
OpenCode 官方建议：**将项目的 `AGENTS.md` 文件提交到 Git 版本控制**。这样每次协作（clone/checkout）时 AI 都能获取最新的项目上下文，保证不同开发者、不同会话中 AI 行为的一致性。
|
||||
|
||||
## File Location
|
||||
|
||||
- 项目根目录：`<project>/AGENTS.md`
|
||||
- 会被 OpenCode 自动加载，无需手动指定
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Vibe Coding]] — AGENTS.md 是 Vibe Coding 工作流中上下文固定的关键机制
|
||||
- [[Plan Mode]] — Plan Mode 依赖 AGENTS.md 提供项目上下文
|
||||
- [[Build Mode]] — Build Mode 依赖 AGENTS.md 保持编码风格一致
|
||||
- [[OpenCode]] — AGENTS.md 由 OpenCode 的 `/init` 命令自动生成
|
||||
|
||||
## Aliases
|
||||
- agents.md
|
||||
- agents file
|
||||
- 项目角色定义文件
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
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-数据蒸馏]]
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: "AI-Assisted Editing"
|
||||
type: concept
|
||||
tags: [video-editing, ai, automation, efficiency]
|
||||
sources: [marketing-short-video-editing-coach]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AI辅助剪辑
|
||||
- 智能剪辑
|
||||
- 人工智能辅助编辑
|
||||
|
||||
## Definition
|
||||
AI辅助剪辑（AI-Assisted Editing）是利用人工智能技术承担视频编辑中重复性高、劳动密集型工作环节的剪辑方法，使人类剪辑师能够将精力集中在需要创意判断的核心环节。AI承担约60%的基础工作，剩余40%的创意打磨仍需人工介入。
|
||||
|
||||
## Core AI Capabilities
|
||||
| 功能 | 工具/技术 | 准确率/效果 |
|
||||
|------|----------|------------|
|
||||
| 自动字幕 | CapCut AI / OpenAI Whisper / ByteDance ASR | 95%+（需人工审核专业术语） |
|
||||
| 智能抠像 | CapCut AI Cutout / Runway ML | 无需绿幕，实时人像分割 |
|
||||
| 文字生成视频 | CapCut text-to-video | 快速生成新闻/口播/图文类视频草稿 |
|
||||
| 音乐生成 | Suno AI / Udio | 快速生成定制 BGM |
|
||||
| 数字人配音 | CapCut Avatar / HeyGen / D-ID | 唇形同步自然度已大幅提升 |
|
||||
|
||||
## Key Principles
|
||||
> "AI-generated videos are 'watchable but soulless' - they handle 60% of the work, but the remaining 40% of creative refinement still requires human craft"
|
||||
|
||||
- AI 生成视频"能看但没有灵魂"
|
||||
- AI 承担 60% 重复性工作，剩余 40% 创意打磨仍需人工
|
||||
- **AI字幕必须人工审核**：技术术语、方言、重叠说话人场景准确率下降明显
|
||||
- **数字人是补充而非替代**：受众对真人出镜的信任度远高于数字人
|
||||
|
||||
## OpenAI Whisper（字幕专用）
|
||||
- 开源离线语音识别，支持 99 种语言
|
||||
- 比云端方案更适合隐私敏感场景
|
||||
- 高准确率，输出 SRT 字幕文件
|
||||
|
||||
## Related Concepts
|
||||
- [[marketing-short-video-editing-coach]] ← AI-Assisted Editing 是该 Agent 技能体系的核心能力之一
|
||||
- [[Template-Based-Production]]：AI辅助 + 模板化共同构成最高效的批量生产工作流
|
||||
|
||||
## Source
|
||||
[[marketing-short-video-editing-coach]]
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,87 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
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]] — 从用户反馈中优化提取准确率
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
title: "AI For On-Call"
|
||||
type: concept
|
||||
tags: [sre, ai, on-call, incident-response, automation]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
# AI For On-Call
|
||||
|
||||
AI 在值班（On-Call）场景中的最佳应用不是自主修复，而是为值班工程师提供足够的上下文以快速修复故障。
|
||||
|
||||
## Core Thesis
|
||||
> "AI's most valuable role in SRE isn't autonomous remediation. It's making sure on-call engineers have the context to fix incidents fast." — Heinrich Hartmann
|
||||
|
||||
## Why Context Matters
|
||||
值班工程师在面对故障时最大的挑战不是不知道怎么做，而是：
|
||||
1. **信息过载**：日志、指标、告警太多，难以快速定位问题
|
||||
2. **上下文丢失**：不熟悉的服务/代码，需要时间理解
|
||||
3. **时间压力**：MTTR 目标要求快速响应
|
||||
|
||||
## AI 辅助 On-Call 的关键场景
|
||||
|
||||
### 1. 上下文聚合（Context Aggregation）
|
||||
AI 从多个来源聚合相关信息：
|
||||
- 告警历史和趋势
|
||||
- 相关的故障报告
|
||||
- 最近变更记录
|
||||
- 依赖服务状态
|
||||
|
||||
### 2. 快速诊断辅助（Rapid Diagnosis）
|
||||
- 总结告警的根本原因
|
||||
- 推荐可能有效的修复步骤
|
||||
- 识别类似的已知问题
|
||||
|
||||
### 3. 值班交接增强（On-Call Handoff）
|
||||
- 自动生成值班交接摘要
|
||||
- 突出显示未解决的问题
|
||||
- 提供历史上下文
|
||||
|
||||
## What AI Should NOT Do
|
||||
- **自动执行修复**：缺乏足够上下文的自动修复可能造成更大损害
|
||||
- **绕过人工审批**：关键变更需要人工确认
|
||||
- **忽视不确定性**：AI 应清楚表达置信度
|
||||
|
||||
## Related Products
|
||||
- [[RunLLM]]：专注于 On-Call 上下文增强的 AI 产品
|
||||
|
||||
## Related Concepts
|
||||
- [[Incident-Response]]
|
||||
- [[Observability]]
|
||||
- [[Resilience]]
|
||||
- [[Self-Healing]]
|
||||
|
||||
## Source
|
||||
- SRE Weekly Issue #513 — [[sre-weekly-issue-513]]
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
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 标志设计
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
title: "AIFinOps"
|
||||
type: concept
|
||||
tags: ["finops", "cost-optimization", "cloud-economics"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AI FinOps
|
||||
- AI Financial Operations
|
||||
- LLM Cost Management
|
||||
|
||||
## Definition
|
||||
AI FinOps（Financial Operations）是 [[AutonomousOptimizationArchitect]] 的成本管理框架——持续追踪每个 LLM Provider 的 Token 消耗、成本、延迟和输出质量，建立历史性能数据库，为 [[SemanticRouting]] 提供成本感知的决策依据。目标是实现 AI 运营成本的可预测性和可控性。
|
||||
|
||||
## Mechanism
|
||||
1. **遥测数据收集**：每次 API 调用记录 Token 数量、响应时间、错误率、成本
|
||||
2. **成本建模**：按 Provider、模型、任务类型建立成本分解模型
|
||||
3. **异常检测**：检测异常流量模式（如 500% 流量突增，可能为 bot 攻击）
|
||||
4. **预算告警**：当成本接近阈值时触发告警
|
||||
5. **优化建议**：基于历史数据生成成本优化建议（如切换到 Gemini Flash）
|
||||
|
||||
## Key Properties
|
||||
- **成本透明**：每百万 Token 成本精确追踪
|
||||
- **可预测性**：基于历史趋势预测未来成本
|
||||
- **与治理对齐**：为 [[CircuitBreaker]] 提供成本异常检测数据
|
||||
|
||||
## Connections
|
||||
- [[AutonomousOptimizationArchitect]] — AIFinOps 是成本管理的核心框架
|
||||
- [[SemanticRouting]] — 成本数据是路由决策的关键输入
|
||||
- [[CircuitBreaker]] — 异常成本流量触发熔断保护
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
title: AIOps
|
||||
tags:
|
||||
- ai
|
||||
- devops
|
||||
- it-operations
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
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
|
||||
]
|
||||
```
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "AISummary"
|
||||
type: concept
|
||||
tags: [ai, summary, document-processing]
|
||||
sources: [我的工具集]
|
||||
last_updated: 2026-05-11
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI Summary 是利用 AI 技术对长文本、PDF 或视频内容进行自动摘要和提炼的服务。
|
||||
|
||||
## Key Characteristics
|
||||
- 支持多种内容格式：文章、PDF、视频
|
||||
- 提供多种摘要模式
|
||||
- 可生成思维导图等可视化输出
|
||||
- 支持多语言摘要输出
|
||||
- 大幅降低信息消化时间
|
||||
|
||||
## Examples from Sources
|
||||
- [[Decopy]] 提供 AI Summary Generator，支持文章、PDF 和视频的摘要生成，具备多摘要模式、思维导图和多语言输出功能
|
||||
|
||||
## Relationships
|
||||
- 属于 [[AI时代发展策略]] 的信息处理层
|
||||
- 为知识管理提供高效的内容处理能力
|
||||
@@ -1,45 +0,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初学者使用指南]]
|
||||
@@ -1,65 +0,0 @@
|
||||
---
|
||||
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视频工具，30秒生成6秒1440×960视频
|
||||
- [[可灵AI]]：快手推出的1080p高质量图生视频工具
|
||||
- [[即梦AI]]：字节跳动旗下，首尾帧精准控制、多参数自定义
|
||||
- [[Vidu]]：清华大学联合生数科技发布，多主体参考功能
|
||||
- [[绘蛙AI视频]]：阿里巴巴旗下，专注模特图片动态化，动作模板驱动
|
||||
- [[通义万相]]：阿里巴巴旗下，精确运镜控制和大幅度主体运动
|
||||
- [[海螺AI]]：MiniMax推出，形象光影高度一致性，电影级特效
|
||||
- [[万相营造]]：阿里妈妈旗下，电商营销场景，高度还原原图
|
||||
- [[PixVerse]]：爱诗科技开发，首尾帧生成和角色一致性保持
|
||||
- [[Video Ocean]]：潞晨科技推出，V2.0版本画质显著提升
|
||||
- [[Stable Video]]：Stability AI推出，精细摄像机运动控制
|
||||
- [[Viva]]：智象未来推出，免费产品中质量最高
|
||||
- [[Haiper]]：免费AI视频生成工具，支持电影/水彩/赛博朋克风格
|
||||
- [[艺映AI]]：MewXAI团队推出，运动笔刷选择性动态化
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
title: "AI幻觉"
|
||||
type: concept
|
||||
tags: [AI, LLM, 问题]
|
||||
last_updated: 2025-12-18
|
||||
---
|
||||
|
||||
## 基本定义
|
||||
AI幻觉（AI Hallucination）是指AI模型生成看似正确、流畅但实际错误、不真实或无依据的内容。这是大语言模型的一个核心挑战。
|
||||
|
||||
## 核心要点
|
||||
- AI幻觉表现为：模型自信地陈述错误事实、编造不存在的引用、生成看似合理但完全错误的数据
|
||||
- 清华大学《DeepSeek从入门到精通2025》手册提供了避免AI幻觉的实用技巧
|
||||
- 解决AI幻觉的方法包括：好的提示词设计、RAG（检索增强生成）、多步骤推理验证
|
||||
|
||||
## 相关来源
|
||||
- [[清华出的deepseek使用手册-104页-真的是太厉害了-免费领取]]
|
||||
|
||||
## 相关概念
|
||||
- [[提示词工程]]：通过好的提示词设计可以有效减少AI幻觉
|
||||
- [[DeepSeek]]
|
||||
|
||||
## Aliases
|
||||
- AI Hallucination
|
||||
- 幻觉
|
||||
- 模型幻觉
|
||||
- LLM Hallucination
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
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-杀疯了]]
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
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图生视频]]：在静态图片基础上添加动态效果，与本文生视频互补
|
||||
- [[运镜控制]]：摄像机运动参数对视频效果的影响
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
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简报自动化工作流
|
||||
- 智能简报工作流
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: "ALB Ingress Controller"
|
||||
type: concept
|
||||
tags: [AWS, Kubernetes, EKS, networking, ingress, load-balancing]
|
||||
last_updated: 2026-04-28
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
AWS Load Balancer Controller（原名 ALB Ingress Controller）是运行在 Kubernetes 集群中的控制器，通过 Kubernetes Ingress 资源动态管理 AWS Application Load Balancer（ALB）的生命周期。它将 Ingress 规则转换为 ALB 配置（目标组、监听规则、路径路由），实现外部流量到集群内 Pod 的自动路由，是 EKS 集群入口流量管理的标准方案。
|
||||
|
||||
## Key Mechanisms
|
||||
|
||||
- **Ingress 驱动**：用户定义 Kubernetes Ingress 资源声明路由规则，控制器自动创建/更新对应 ALB
|
||||
- **多层路由**：支持基于主机名（host-based）和路径（path-based）的路由规则
|
||||
- **AWS WAF 集成**：ALB 可关联 AWS WAF Web ACL，实现 L7 安全防护
|
||||
- **健康检查自动化**：自动配置目标组健康检查指向 Pod 健康端点
|
||||
- **多种 Ingress 类**：支持公开（internet-facing）和私有（internal）ALB
|
||||
|
||||
## Relationship with Kubernetes Ingress
|
||||
|
||||
AWS Load Balancer Controller 扩展了 Kubernetes Ingress API 的 AWS 后端实现：
|
||||
- 标准 Kubernetes Ingress 定义路由规则
|
||||
- 控制器解释规则并调用 AWS API 创建/配置 ALB
|
||||
- 替代手动 ALB 管理，实现声明式基础设施
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-70-eks-deployment-using-iac]]
|
||||
- [[ctp-topic-59-achieving-reliability-with-amazon-eks]]
|
||||
@@ -1,52 +0,0 @@
|
||||
---
|
||||
title: "AMI Sharing"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- AMI
|
||||
- Multi-Account
|
||||
sources: []
|
||||
last_updated: 2026-05-07
|
||||
---
|
||||
|
||||
## AMI Sharing
|
||||
|
||||
AWS 镜像跨账号共享机制，通过授权其他 AWS 账户访问中央镜像，而非物理复制（AMI Copying），避免跨账号复制带来的额外存储成本。
|
||||
|
||||
## Definition
|
||||
|
||||
AMI Sharing 是 AWS 账户管理策略，允许 AMI 所有者：
|
||||
- 将 AMI 共享给特定 AWS 账户
|
||||
- 将 AMI 共享给 AWS Organization 内所有成员账户
|
||||
- 通过 RAM（Resource Access Manager）前缀列表跨账户共享规则
|
||||
|
||||
## Benefits vs AMI Copying
|
||||
|
||||
| 维度 | AMI Sharing | AMI Copying |
|
||||
|------|-------------|-------------|
|
||||
| 存储成本 | 零增量 | 每区域完整副本 |
|
||||
| 一致性 | 单一源，完全一致 | 复制后可能不一致 |
|
||||
| 维护 | 单一更新点 | 每副本需独立更新 |
|
||||
| 权限 | 通过 IAM/KMS 控制 | 独立权限管理 |
|
||||
|
||||
## In Micro Focus CTP
|
||||
|
||||
在 Micro Focus 多账户 AWS 环境中：
|
||||
- Foundation AMI 存储在 CCOE 管理账户
|
||||
- 通过 AMI Sharing 分发给所有产品账户
|
||||
- 同步分发至全球多区域（俄勒冈/法兰克福/悉尼）
|
||||
- EBS 卷和 KMS 密钥同步共享
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- AMI 所有者账户与目标账户在同一 AWS Organization，或
|
||||
- 显式授权跨账户共享
|
||||
- KMS 加密 AMI 需额外授权 KMS 密钥使用
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-26-standard-ami-build-publish-share-processes]] — AMI Sharing 作为分发机制
|
||||
- [[ctp-topic-50-ami-roadmap-for-aws-amis]] — AMI 通过跨账号共享分发给组织内所有账户
|
||||
|
||||
## Related Concepts
|
||||
- [[Foundation-AMI]] — AMI Sharing 分发的主要对象
|
||||
- [[AWS]] Organizations — 跨账号共享的组织基础
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "API Server Priority and Fairness"
|
||||
type: concept
|
||||
tags:
|
||||
- Kubernetes
|
||||
- EKS
|
||||
- API-Server
|
||||
- Performance
|
||||
- Multi-Tenancy
|
||||
sources:
|
||||
- ctp-topic-64-scaling-out-with-amazon-eks
|
||||
last_updated: 2026-04-28
|
||||
---
|
||||
|
||||
## Definition
|
||||
API Server Priority and Fairness（PPF）是 Kubernetes 1.20+ 引入的 API Server 配置特性，通过优先级类别（Priority Class）和并发限制（Flow Schema）管理 API 请求的调度和限流，确保关键工作负载在高负载下的 API 访问稳定性。
|
||||
|
||||
## Key Mechanisms
|
||||
- **Priority Class**：为 API 请求分配优先级（整数越大优先级越高）
|
||||
- **Flow Schema**：定义请求匹配规则，将请求路由到对应的 Flow
|
||||
- **Concurrency Limit**：每个 Flow 的并发请求数限制
|
||||
- **Request Limiting**：超出限制的请求进入等待队列或被拒绝
|
||||
|
||||
## Why Enable PPF
|
||||
- 多租户 EKS 集群中，防止单个租户/工作负载耗尽 API Server 资源
|
||||
- 在扩缩容期间（大量 HPA/Controller 并发请求）保护关键 API 调用
|
||||
- 提升 API Server 在高负载下的可预测性和稳定性
|
||||
|
||||
## Configuration
|
||||
- 通过 kube-apiserver 启动参数 `--enable-priority-and-fairness=true` 启用
|
||||
- Flow Schema 和 Priority Level 通过 kube-apiserver 配置或 admission webhook 管理
|
||||
|
||||
## Relationship with Scaling
|
||||
- 在大规模集群扩缩容时，HPA、Cluster Autoscaler、Custom Controller 等大量并发 API 请求可能压垮 API Server
|
||||
- PPF 确保关键扩缩容操作的 API 请求优先处理
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-64-scaling-out-with-amazon-eks]]
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
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 包管理器的宿主系统
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: "ARM-AMI"
|
||||
type: concept
|
||||
tags: [AWS, AMI, ARM]
|
||||
last_updated: 2026-05-07
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
ARM-AMI refers to Amazon Machine Images (AMIs) built for EC2 instances running on ARM-based processors (Graviton/Graviton2/Graviton3). These AMIs are optimized for ARM architecture and offer better price-performance ratio compared to x86 AMIs for many workloads.
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
- **Architecture**: ARM64 (AArch64), based on AWS Graviton processor family
|
||||
- **Performance**: Better price-performance for many workloads (web servers, containers, microservices)
|
||||
- **Cost**: Lower licensing costs (no x86 licensing fees)
|
||||
- **Availability**: Available for Amazon Linux, Ubuntu, RHEL, and other supported OSes
|
||||
- **Shared Infrastructure**: AMIs, EBS volumes, and KMS keys shared across all organization accounts
|
||||
|
||||
## AMI Roadmap Context
|
||||
|
||||
Per [[ctp-topic-50-ami-roadmap-for-aws-amis]], the ARM-AMI roadmap milestones:
|
||||
|
||||
- **November 2022**: RHEL 9 ARM planned
|
||||
- **May 2023**: RHEL 9.4 ARM and Ubuntu 22.04 ARM
|
||||
- **Starting May 2023**: All ARM processors related to AMIs are released synchronously
|
||||
|
||||
The ordering of ARM AMI releases is primarily driven by [[ADM]] (Architecture Decision Management) requirements.
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Foundation-AMI]]: CCOE-provided hardened base images on which product teams build
|
||||
- [[AMI-Sharing]]: Cross-account AMI sharing mechanism
|
||||
- [[OS-Hardening]]: Security hardening applied to AMIs
|
||||
|
||||
## Connections
|
||||
|
||||
- [[ctp-topic-50-ami-roadmap-for-aws-amis]] → defines ARM-AMI release roadmap
|
||||
- [[ctp-topic-26-standard-ami-build-publish-share-processes]] → foundation AMI hardening standards apply to ARM variants
|
||||
- [[ctp-topic-58-aws-ec2-image-builder]] → Image Builder used to create ARM-variant AMIs
|
||||
@@ -1,61 +0,0 @@
|
||||
---
|
||||
title: "AWS Backup Concepts"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Backup
|
||||
- DR
|
||||
- Cloud-Native
|
||||
sources:
|
||||
- ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup
|
||||
- ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program
|
||||
last_updated: 2026-04-28
|
||||
---
|
||||
|
||||
# AWS Backup Concepts
|
||||
|
||||
本页面汇总 AWS Backup 相关的核心概念。
|
||||
|
||||
## Vault Lock（备份保管库锁定）
|
||||
|
||||
Vault Lock 是 AWS Backup 备份保管库的一种合规模式。在合规模式下：
|
||||
|
||||
- 一旦 Vault Lock 生效，即使 AWS 根用户也无法在设定的生命周期结束前删除恢复点
|
||||
- 有效防御勒索软件攻击（攻击者无法加密/删除备份）
|
||||
- 适用于需要满足监管合规要求（如 SEC、FINRA、GDPR）的场景
|
||||
|
||||
> 对比 CTP Topic 44（Micro Focus 评估）：Micro Focus 内部评估同样认可 Vault Lock 是防勒索软件的关键能力。
|
||||
|
||||
## 增量备份（Incremental Backup）
|
||||
|
||||
增量备份仅捕获自上次备份以来的数据变更：
|
||||
|
||||
- **优势**：首次全量备份后，后续仅备份变更，大幅节省存储成本
|
||||
- **机制**：备份链（Backup Chain）追踪变更，恢复时按顺序重放
|
||||
- **AWS Backup 自动处理**：无需手动管理备份链
|
||||
|
||||
> 与全量备份相比，增量备份显著降低了存储成本和备份窗口时长。
|
||||
|
||||
## 跨账户备份（Cross-Account Backup）
|
||||
|
||||
通过 AWS Organizations 将备份从源账户复制到独立的 DR/Bunker 账户：
|
||||
|
||||
- **隔离原则**：备份账户与工作负载账户物理分离，防止账户被入侵时备份一并丢失
|
||||
- **即时恢复**：备份保留在 DR 账户内，无需跨账户数据拷贝即可恢复
|
||||
- **多区域复制**：结合跨区域复制，实现地理冗余
|
||||
|
||||
## Backup Plan（备份计划）
|
||||
|
||||
备份计划是 AWS Backup 的核心策略配置：
|
||||
|
||||
- **规则（Rules）**：定义备份频率、保留期、启动窗口、复制规则等
|
||||
- **分配（Assignments）**：将计划应用于特定资源或资源集
|
||||
- **生命周期（Lifecycle）**：定义恢复点何时从热存储转为冷存储（Glacier）
|
||||
|
||||
## Backup Vault（备份保管库）
|
||||
|
||||
备份保管库是存储恢复点的加密容器：
|
||||
|
||||
- 每个保管库使用 AWS KMS CMK 加密
|
||||
- 支持基于资源的策略（Resource-based Policy）控制访问
|
||||
- 与 Vault Lock 结合实现合规锁定
|
||||
@@ -1,76 +0,0 @@
|
||||
---
|
||||
title: "AWS End User Computing"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- End-User-Computing
|
||||
- Virtual-Desktop
|
||||
- Cloud-DevOps
|
||||
sources:
|
||||
- public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee
|
||||
last_updated: 2026-05-11
|
||||
---
|
||||
|
||||
## AWS End User Computing（AWS 终端用户计算）
|
||||
|
||||
AWS 终端用户计算（AWS End User Computing，EUC）服务组合是 AWS 为支持远程/混合工作模式而提供的虚拟桌面和应用程序流解决方案组合。核心价值：帮助组织在远程工作时代保护终端、保护 IP 和数据，同时维持生产力并控制成本。
|
||||
|
||||
## AWS EUC Portfolio（四大服务）
|
||||
|
||||
| 服务 | 类型 | 持久性 | 适用场景 |
|
||||
|------|------|--------|----------|
|
||||
| [[Amazon-Workspaces]] | 全持久虚拟桌面 | 完全持久 | 知识工作者、需要完整桌面环境 |
|
||||
| [[AppStream-2]] | 应用程序流/虚拟桌面 | 选择持久 | 实验室、培训、堡垒主机、非持久桌面 |
|
||||
| [[Workspace-Core]] | 第三方 VDI API 集成 | — | Horizon View、Citrix 等第三方 VDI |
|
||||
| [[Workspace-Web]] | 安全浏览器 | 非持久 | 访问内部网站和 SaaS 应用 |
|
||||
|
||||
## Core Design Decisions
|
||||
|
||||
### 持久性对比
|
||||
- **全持久桌面**（Workspaces）：一对一实例管理，应用状态和设置在会话之间保持
|
||||
- **非持久桌面**（AppStream）：每次登录全新桌面，可通过应用连接器和存储连接器实现部分持久化
|
||||
|
||||
### 成本优化机制
|
||||
- **AppStream 并发使用**：多用户共享实例（多租户模式）
|
||||
- **Workspaces 自动停止**：减少空闲资源成本
|
||||
|
||||
### 协议
|
||||
- **WSP 协议**（Workspaces Streaming Protocol）：专为高延迟网络设计的流传输协议
|
||||
|
||||
## Security Posture（安全姿态）
|
||||
|
||||
> *"With so many remote workers organizations are struggling to protect endpoints, as well as their IP and data from bad actors."* — [[Christian-ODonough]]
|
||||
|
||||
安全措施包括：
|
||||
- Active Directory 集成
|
||||
- 加密（静态和传输中）
|
||||
- IAM 配置文件
|
||||
- 多因素认证（MFA）
|
||||
- 设备证书
|
||||
- VPC Interface Endpoints（私有连接）
|
||||
- SAML-based Authentication
|
||||
|
||||
## Architecture
|
||||
|
||||
AWS EUC 架构包含两类 VPC：
|
||||
1. **Service VPC**：AWS 托管
|
||||
2. **Customer VPC**：客户管理
|
||||
|
||||
每个 Workspaces 有两个网络接口连接两类 VPC。
|
||||
|
||||
## DR Considerations
|
||||
|
||||
灾难恢复策略：
|
||||
- 跨 AWS 区域构建 Workspaces
|
||||
- 利用 AppStream 自动扩展能力
|
||||
|
||||
## Connections
|
||||
- [[Amazon-Workspaces]] ← is_a ← [[AWS-End-User-Computing]]
|
||||
- [[AppStream-2]] ← is_a ← [[AWS-End-User-Computing]]
|
||||
- [[Workspace-Core]] ← is_a ← [[AWS-End-User-Computing]]
|
||||
- [[Workspace-Web]] ← is_a ← [[AWS-End-User-Computing]]
|
||||
- [[Amazon-VPC]] ← depends_on ← [[AWS-End-User-Computing]]
|
||||
- [[Active-Directory-Integration]] ← depends_on ← [[AWS-End-User-Computing]]
|
||||
|
||||
## Sources
|
||||
- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]]
|
||||
@@ -1,73 +0,0 @@
|
||||
---
|
||||
title: "AWS Firewall Manager"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Security
|
||||
- Multi-Account
|
||||
- Firewall
|
||||
- Compliance
|
||||
sources:
|
||||
- ctp-topic-55-aws-firewall-manager
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
AWS Firewall Manager 是 AWS 提供的集中化管理服务，用于在组织级别（Organization）跨账户和跨应用程序统一配置防火墙规则和安全策略。它提供了一个合规仪表板视图，支持 WAF、Network Firewall、Shield Advanced 和安全组（Security Group）四种策略类型的统一管理。
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
### 1. Centralized Policy Management
|
||||
- 在单一账户（Firewall Manager Admin Account）中定义策略，自动分发到目标账户或 OU
|
||||
- 支持跨多个 Landing Zone（如 RLABS、R&D、SAS、CAT）的统一纳管
|
||||
- Firewall Manager 账户独立于任何单一 Landing Zone
|
||||
|
||||
### 2. Security Group Policy Types
|
||||
- **Common Security Group Policy**：附加基线安全组，允许产品团队在其上继续添加额外规则
|
||||
- **Audit & Enforcement Security Group Policy**：拒绝过度宽松的安全组规则，支持手动修复或自动修复
|
||||
- **Cleanup Security Group Policy**：清理未使用的冗余安全组
|
||||
|
||||
### 3. Automatic Remediation
|
||||
- 依赖 AWS Config 作为合规评估引擎，检测不合规资源
|
||||
- 通过 AWS Lambda 触发修复事件，自动执行策略
|
||||
- 新建 EC2 实例自动附加基线安全组，删除策略自动从实例剥离安全组
|
||||
|
||||
### 4. Cross-Account Rule Distribution
|
||||
- 通过 Prefix List 定义 CIDR 范围
|
||||
- 通过 AWS RAM（Resource Access Manager）跨账户共享 Prefix List，实现规则同步更新
|
||||
|
||||
## Prerequisites
|
||||
- 需要在组织（Organization）级别启用 Firewall Manager
|
||||
- Firewall Manager 管理员必须在目标 OU 内拥有管理员权限
|
||||
- 所有目标账户必须启用 AWS Config
|
||||
|
||||
## Use Cases
|
||||
- 多 Landing Zone 环境下的安全基线统一实施
|
||||
- 替代 Checkpoint Firewall 无法覆盖的公网子网流量管控
|
||||
- 集中化 WAF 规则管理，支持产品团队在基线规则上叠加自定义规则集
|
||||
|
||||
## Architecture Pattern
|
||||
```
|
||||
Firewall Manager Admin Account
|
||||
├── Security Group Policy Definition
|
||||
│ ├── Target: Account / OU
|
||||
│ └── Baseline Security Group
|
||||
├── AWS Config (Compliance Engine)
|
||||
└── AWS Lambda (Remediation Trigger)
|
||||
↓ (RAM: Prefix List Sharing)
|
||||
Target Accounts
|
||||
└── EC2 Instances (Auto-attached)
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[AWS Config]]：合规评估引擎
|
||||
- [[AWS Lambda]]：自动化修复执行
|
||||
- [[Security Group Policy]]：策略类型分类
|
||||
- [[AWS-Landing-Zone]]：上层基础设施框架
|
||||
- [[Terraform]] + [[Terragrunt]]：IaC 自动化部署
|
||||
|
||||
## Tooling
|
||||
- Terraform provider for Firewall Manager
|
||||
- Terragrunt for Landing Zone multi-account orchestration
|
||||
- Atlantis CI/CD pipeline for automated policy deployment
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "AWS Identity Center"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS-Identity-Center
|
||||
- IAM
|
||||
- Identity-Governance
|
||||
- SSO
|
||||
sources:
|
||||
- learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re
|
||||
last_updated: 2023-11-28
|
||||
---
|
||||
|
||||
## AWS Identity Center
|
||||
|
||||
AWS Identity Center（AWS 单点登录服务，原 AWS SSO）是 AWS 提供的跨账户身份与访问管理服务，为多账户 AWS 环境提供统一的身份认证和权限管理。
|
||||
|
||||
## Core Function
|
||||
|
||||
AWS Identity Center 通过 IAM 提供云资源访问控制，是 Micro Focus IGA 身份治理平台与 AWS 云资源之间的关键集成点。
|
||||
|
||||
## Architecture Integration
|
||||
|
||||
```
|
||||
User → IGA Portal → AD Groups (role mapping) → AWS Identity Center → IAM → AWS Resources
|
||||
↑ ↑
|
||||
└── Azure AD Domain Services (auth bridge)
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Identity-Governance]]：身份治理框架，AWS Identity Center 是其 AWS 云端的实现基础
|
||||
- [[Micro-Focus-IGA]]：Micro Focus 身份治理平台，通过 AWS Identity Center 连接 AWS 资源
|
||||
- [[Active-Directory-Integration]]：AD 组映射到 IAM 角色的联合身份机制
|
||||
|
||||
## Sources
|
||||
|
||||
- [[learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re]]
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
title: "AWS Inspector"
|
||||
type: concept
|
||||
tags: ["AWS", "Security", "Vulnerability-Scanning", "Compliance"]
|
||||
sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2", "ctp-topic-58-aws-ec2-image-builder"]
|
||||
last_updated: 2026-05-08
|
||||
---
|
||||
|
||||
## Definition
|
||||
AWS Inspector 是 AWS 原生的安全漏洞扫描服务，在 AMI 构建和发布流程中集成自动化的安全合规检测，识别已知安全漏洞（CVE）和网络暴露问题。
|
||||
|
||||
## Key Capabilities
|
||||
- **CVE 检测**：识别已知安全漏洞
|
||||
- **网络可达性分析**：检测意外开放的安全组规则
|
||||
- **自动扫描**：集成到 CI/CD 流水线
|
||||
- **合规报告**：生成安全扫描报告
|
||||
|
||||
## Integration in AMI Pipeline
|
||||
1. AMI 构建完成后立即触发 Inspector 扫描
|
||||
2. 扫描结果与安全基准对比
|
||||
3. 发现高危漏洞则阻断发布
|
||||
4. 无问题则继续跨区域复制和共享
|
||||
|
||||
## Connections
|
||||
- [[Amazon-Machine-Image]] — Inspector 扫描的对象
|
||||
- [[Jenkins-Multi-Branch-Pipeline]] — Inspector 集成在 Jenkins 流水线中
|
||||
- [[AWS-Landing-Zone]] — Inspector 是 LZ 安全基础设施的组成部分
|
||||
@@ -1,69 +0,0 @@
|
||||
---
|
||||
title: "AWS Instance Scheduler"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Cost-Optimization
|
||||
- FinOps
|
||||
- Automation
|
||||
- EC2
|
||||
- RDS
|
||||
sources:
|
||||
- ctp-topic-27-aws-instance-scheduler
|
||||
- ctp-topic-63-optimise-resource-cost-using-automation
|
||||
last_updated: 2026-05-12
|
||||
---
|
||||
|
||||
## AWS Instance Scheduler
|
||||
|
||||
AWS 官方提供的自动化解决方案，通过定时控制 EC2 和 RDS 实例的启动和停止状态来降低非生产环境（开发和测试）的云成本。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
技术架构（四层）：
|
||||
|
||||
1. **CloudFormation**：一键部署完整解决方案栈
|
||||
2. **CloudWatch Events**：定时触发器，默认每 15 分钟触发一次 Lambda 函数
|
||||
3. **Lambda 函数**：读取调度配置并执行实例启停操作
|
||||
4. **DynamoDB Config Table**：存储调度定义（Schedules）和周期定义（Periods）
|
||||
|
||||
## Key Features
|
||||
|
||||
- **基于时间表触发**：按预设时间表（而非空闲率）执行启停操作
|
||||
- **多时区支持**：可配置不同办公时间（西雅图时间、英国时间等）
|
||||
- **标签化关联**：通过实例上的 `Schedule` 和 `Period` 标签关联调度逻辑
|
||||
- **RDS 维护窗口兼容**：智能配合 RDS 每 7 天强制维护窗口，维护完成后恢复调度状态
|
||||
- **Override Status**：高级配置，强制将实例保持在停止状态
|
||||
- **数据保留**：实例关机行为必须设置为"停止（Stop）"而非"终止（Terminate）"
|
||||
|
||||
## Deployment Model
|
||||
|
||||
- **独立部署**：通过 AWS 官方 CloudFormation 模板一键部署
|
||||
- **Guardrails 集成**（Micro Focus CTP）：CCOE 通过 Guardrails 框架将 Instance Scheduler 自动推送至公司内月消费 10 美元以上的 AWS 账号，用户无需手动配置
|
||||
|
||||
## Relationship to FinOps
|
||||
|
||||
Instance Scheduler 是 [[FinOps（云财务管理）]] 核心技术手段"自动化调度"的具体实现方案：
|
||||
|
||||
- **CTP Topic 13**：首次提出"实例调度器"作为 FinOps 5 大策略之一
|
||||
- **CTP Topic 27**：详解 AWS 原生 Instance Scheduler 的技术架构和运营要点
|
||||
- **CTP Topic 63**：作为自动化成本优化的 5 大策略之一再次引用
|
||||
|
||||
## Cost Impact
|
||||
|
||||
非 7×24 工作负载（如开发/测试环境）每天只运行 10 小时，相比 24 小时运行可节省约 **70%** 的实例成本。
|
||||
|
||||
## Aliases
|
||||
- Instance Scheduler
|
||||
- AWS EC2 Instance Scheduler
|
||||
- AWS RDS Instance Scheduler
|
||||
|
||||
## Related Pages
|
||||
- [[CloudWatch-Events]] — 触发机制
|
||||
- [[DynamoDB-Config-Table]] — 调度配置存储
|
||||
- [[Tagging]] — 实例关联方式
|
||||
- [[RDS-Maintenance-Window]] — RDS 兼容性
|
||||
- [[Override-Status]] — 高级覆盖配置
|
||||
- [[Godrails]] — CTP 中的自动化部署框架
|
||||
- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源
|
||||
- [[ctp-topic-63-optimise-resource-cost-using-automation]] — 技术实施参考
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "AWS Nitro"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- EC2
|
||||
- Virtualization
|
||||
- Performance
|
||||
aliases:
|
||||
- Nitro
|
||||
- AWS Nitro System
|
||||
- Nitro Hypervisor
|
||||
last_updated: 2026-05-12
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
AWS Nitro 是 AWS 自研的专用虚拟化平台，通过将网络、存储和安全组件从主机处理器卸载到专用硬件（Nitro 卡），大幅提升 EC2 实例的效率和性能。
|
||||
|
||||
## Architecture
|
||||
|
||||
Nitro 系统由多个专用组件组成：
|
||||
- **Nitro Hypervisor**：轻量级 Type-1 hypervisor，负责 CPU 和内存虚拟化
|
||||
- **Nitro Card for VPC**：提供 ENI（Elastic Network Interface）和 VPC 网络
|
||||
- **Nitro Card for EBS**：提供 EBS 卷和网络存储
|
||||
- **Nitro Card for Instance Storage**：提供本地 NVMe 存储
|
||||
- **Nitro Enclaves**：提供隔离的执行环境（用于处理敏感数据）
|
||||
|
||||
## Benefits
|
||||
|
||||
- **性能提升**：减少虚拟化开销，提升网络和存储 I/O 性能
|
||||
- **更强的隔离性**：Nitro Enclaves 提供硬件级隔离的独立计算环境
|
||||
- **更高的安全性**：安全组件卸载到专用硬件，减少攻击面
|
||||
- **更大的实例灵活性**：支持更多实例类型和更大实例规格
|
||||
|
||||
## Graviton on Nitro
|
||||
|
||||
所有 Graviton 实例均运行于 Nitro 系统之上，享受 Nitro 带来的性能和安全优势，同时结合 ARM64 架构的成本效益。
|
||||
|
||||
## Related Pages
|
||||
|
||||
- [[Graviton]]：运行于 Nitro 的 ARM 处理器
|
||||
- [[EC2-Spot-Instances]]：可在 Nitro 实例上使用
|
||||
- [[FinOps]]：云成本优化
|
||||
- [[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]]
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: "AWS Secrets Manager"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Secrets Management
|
||||
- Security
|
||||
sources:
|
||||
- ctp-topic-12-using-ses-smtp-service-terraform-module
|
||||
- ctp-topic-62-aws-secrets-manager
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Definition
|
||||
AWS Secrets Manager 是一项 AWS 服务，用于安全存储和检索敏感信息（如数据库凭证、API 密钥、SMTP 认证信息），支持自动轮换和精细的 IAM 访问控制。
|
||||
|
||||
## Key Use Cases
|
||||
- 存储 SES SMTP 认证信息（IAM 用户 Access Key / Secret Key 转换后的用户名和密码）
|
||||
- Oracle DB 用户密码自动轮换（Lambda 函数连接 Oracle 实例执行轮换）
|
||||
- SendGrid API 密钥集中管理
|
||||
|
||||
## Connections
|
||||
- [[CTP Topic 12 Using SES SMTP service terraform module]] — SES SMTP 凭证存储方案
|
||||
- [[CTP Topic 62 AWS Secrets Manager]] — 深度实践与标准文档
|
||||
- [[VPC Endpoint]] — 配合使用实现凭证的安全私有访问
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: "AWS Service Catalog"
|
||||
type: concept
|
||||
tags: [AWS, IaC, self-service, governance, EKS]
|
||||
last_updated: 2026-04-28
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
AWS Service Catalog 是 AWS 托管的服务，允许组织创建和管理已批准在 AWS 上使用的产品（Products）目录。这些产品本质上是 CloudFormation 模板或 Terraform 模块的受控版本，通过 Portfolio（产品组合）组织，并可授予特定用户或团队访问权限。Service Catalog 为终端用户提供自助服务界面，无需深入了解底层 IaC 模板即可部署标准化的基础设施，同时保证安全与合规。
|
||||
|
||||
## Key Mechanisms
|
||||
|
||||
- **产品（Products）**：预定义的 CloudFormation 模板或 Terraform 模块，代表标准化的基础设施配置
|
||||
- **产品组合（Portfolio）**：产品的逻辑分组，可关联到团队或项目
|
||||
- **访问控制**：通过 IAM 角色向终端用户授予产品访问权限，实现最小权限原则
|
||||
- **版本管理**：支持同一产品的多版本管理，可逐步升级
|
||||
- **EKS 部署集成**：SRE EKS 模块通过 Service Catalog 提供 EKS 集群部署界面，支持版本选择和节点类型配置
|
||||
|
||||
## Relationship with IaC
|
||||
|
||||
Service Catalog 封装底层 IaC 模板（Terraform/CloudFormation），为非技术用户提供受控的自助服务入口：
|
||||
- IaC 模板由平台团队维护（在 Git 仓库中通过 CI/CD 管理）
|
||||
- Service Catalog 充当面向终端用户的治理层，控制可部署的产品范围
|
||||
- 相比直接 Terraform 部署，Service Catalog 提供更细粒度的权限控制
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-70-eks-deployment-using-iac]]
|
||||
- [[ctp-topic-3-deploy-and-maintain-infrastructure]]
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
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 实现细节的记录。
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,82 +0,0 @@
|
||||
---
|
||||
title: "Access Control（访问控制）"
|
||||
type: concept
|
||||
tags: [blockchain, security, smart-contract, access-control]
|
||||
sources: [blockchain-security-auditor]
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Access Control
|
||||
- 访问控制 / 权限控制
|
||||
|
||||
## Definition
|
||||
|
||||
访问控制（Access Control）定义谁可以执行合约中的哪些操作。访问控制缺陷是智能合约最常见的高危漏洞类别之一，错误的权限配置可直接导致资金被盗或协议被永久阻塞。
|
||||
|
||||
## Key Vulnerability Classes
|
||||
|
||||
### 1. Missing Access Modifier（缺失访问修饰符）
|
||||
```solidity
|
||||
// VULNERABLE: withdraw() 没有访问控制，任何人都能调用
|
||||
function withdraw() external {
|
||||
uint256 amount = balances[msg.sender];
|
||||
(bool success,) = msg.sender.call{value: amount}("");
|
||||
require(success);
|
||||
balances[msg.sender] = 0;
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Wrong Access Modifier（错误的访问修饰符）
|
||||
```solidity
|
||||
// VULNERABLE: 应该是 onlyOwner，但误写成 external
|
||||
// 导致任何人都能调用紧急停止
|
||||
function emergencyStop() external {
|
||||
paused = true;
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Unprotected initialization（未保护的初始化）
|
||||
```solidity
|
||||
// VULNERABLE: initialize() 没有 initializer 修饰符
|
||||
// 攻击者可抢先调用，劫持合约
|
||||
function initialize(address _owner) external {
|
||||
owner = _owner;
|
||||
}
|
||||
```
|
||||
|
||||
### 4. Proxy Storage Collision（代理存储冲突）
|
||||
升级型代理合约中，新实现版本的存储布局与旧版本不兼容，导致状态变量被覆盖：
|
||||
```solidity
|
||||
// Implementation V1
|
||||
uint256 public totalValue; // slot 0
|
||||
|
||||
// Implementation V2 — 新增变量导致 slot 0 被覆盖
|
||||
address public newAdmin; // slot 0 ← 覆盖了 totalValue！
|
||||
uint256 public totalValue; // slot 1
|
||||
```
|
||||
|
||||
### 5. Role Renunciation Hijack（角色放弃劫持）
|
||||
允许 admin 放弃角色后无人能恢复，导致协议永久不可升级。
|
||||
|
||||
## Audit Checklist
|
||||
|
||||
- [ ] 所有特权函数都有显式访问修饰符
|
||||
- [ ] Admin 角色不能自我授予（需要多签或时间锁）
|
||||
- [ ] `initialize()` 只能调用一次（initializer 修饰符）
|
||||
- [ ] 实现合约构造函数中有 `_disableInitializers()`
|
||||
- [ ] `_authorizeUpgrade()` 受 owner/多签/时间锁保护
|
||||
- [ ] 存储布局在版本间兼容（无 slot 碰撞）
|
||||
- [ ] 无 `delegatecall` 到用户可控地址
|
||||
|
||||
## Severity Classification
|
||||
|
||||
- **Critical**：缺失关键特权函数的访问控制，可直接导致资金损失
|
||||
- **High**：条件性权限提升（需要特定状态），或协议可被 admin 永久阻塞
|
||||
- **Medium**：缺失非关键函数的访问控制
|
||||
- **Low**：缺少事件日志、代码规范问题
|
||||
|
||||
## Related Concepts
|
||||
- [[Reentrancy]]：缺失访问控制会加剧重入攻击影响
|
||||
- [[Proxy-Upgrade]]：代理升级模式引入额外访问控制风险
|
||||
- [[OpenZeppelin]] 的 AccessControl 库是标准安全实现
|
||||
@@ -1,47 +0,0 @@
|
||||
---
|
||||
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 维护账户健康评分
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
title: "Account-Monitoring"
|
||||
type: concept
|
||||
tags: ["monitoring", "social-media", "automation", "notification", "twitter"]
|
||||
last_updated: 2026-04-27
|
||||
---
|
||||
|
||||
## Overview
|
||||
Account-Monitoring 是指持续追踪指定 X/Twitter 账号的内容发布或粉丝变动并触发通知的自动化技术。
|
||||
|
||||
## Definition
|
||||
通过 API 定期轮询或订阅目标账号的最新动态（推文发布、转发、粉丝变化等），当检测到变化时自动向用户发送通知。
|
||||
|
||||
## Key Characteristics
|
||||
- **持续追踪**：不间断监控目标账号状态变化
|
||||
- **多维度监控**：
|
||||
- 新推文/转发发布
|
||||
- 粉丝数量变化
|
||||
- 关注/取消关注操作
|
||||
- **主动通知**：检测到变化时自动推送通知，无需用户主动查询
|
||||
- **可配置阈值**：可设置仅在特定条件触发时通知（如粉丝数突破阈值）
|
||||
|
||||
## Implementation
|
||||
在 [[x-twitter-automation]] 中，通过 [[TweetClaw]] 的 Monitors 功能实现：
|
||||
1. 配置监控目标账号列表
|
||||
2. 定期通过 API 获取账号最新状态
|
||||
3. 与上次状态对比，检测变化
|
||||
4. 变化发生时自动向用户发送通知
|
||||
|
||||
## Related Use Cases
|
||||
- [[x-twitter-automation]] — TweetClaw 提供账号监控功能
|
||||
|
||||
## Sources
|
||||
- [[x-twitter-automation]]
|
||||
|
||||
## Connections
|
||||
- [[X/Twitter-API-Automation]] ← powers ← [[Account-Monitoring]]（监控功能依赖 API 获取账号动态）
|
||||
@@ -1,59 +0,0 @@
|
||||
---
|
||||
title: "Account Reconciliation"
|
||||
type: concept
|
||||
tags: [finance, accounting]
|
||||
sources: [finance-bookkeeper-controller]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
账户调节（Account Reconciliation）是将总账（GL）余额与支持明细或分账余额进行核对的流程，确保每个账户的余额准确、完整、有据可查。
|
||||
|
||||
## Purpose
|
||||
- 检测和纠正错误
|
||||
- 确保财务信息的准确性
|
||||
- 满足审计要求
|
||||
- 发现异常或欺诈信号
|
||||
|
||||
## Core Template Structure
|
||||
|
||||
### Balance Summary
|
||||
| Source | Amount |
|
||||
|--------|--------|
|
||||
| GL Balance (per trial balance) | $[X] |
|
||||
| Reconciliation Balance (per supporting detail) | $[X] |
|
||||
| **Difference** | **$[X]** |
|
||||
|
||||
### Reconciling Items
|
||||
记录所有待处理差异，包括日期、描述、金额、状态和解决日期。
|
||||
|
||||
### Adjusted Balance
|
||||
| Item | Amount |
|
||||
|------|--------|
|
||||
| GL Balance | $[X] |
|
||||
| + Reconciling Items | $[X] |
|
||||
| **Reconciled Balance** | **$[X]** |
|
||||
| Subledger / Support Balance | **$[X]** |
|
||||
| **Variance** | **$0** |
|
||||
|
||||
## Common Reconciliation Types
|
||||
- 银行账户调节
|
||||
- 信用卡调节
|
||||
- AR aging 与 GL 核对
|
||||
- AP aging 与 GL 核对
|
||||
- 预付账款与摊销计划
|
||||
- 固定资产与折旧
|
||||
- 递延收入滚动表
|
||||
- 关联方交易调节
|
||||
- 权益变动调节
|
||||
- 工资税负债与申报表
|
||||
|
||||
## Core Principle
|
||||
> "Reconciliation is not a chore — it's a detective process. Every unreconciled difference is a story waiting to be understood."
|
||||
> — Dana, Bookkeeper & Controller Agent
|
||||
|
||||
## Related Concepts
|
||||
- [[Month-End-Close-Process]]
|
||||
- [[Journal Entry]]
|
||||
- [[Internal Controls]]
|
||||
- [[Audit Readiness]]
|
||||
@@ -1,73 +0,0 @@
|
||||
---
|
||||
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]] — 不同层级对应不同序列深度
|
||||
@@ -1,52 +0,0 @@
|
||||
---
|
||||
title: "Account Architecture"
|
||||
type: concept
|
||||
tags: ["ppc", "account-structure", "google-ads", "enterprise", "paid-media"]
|
||||
sources: ["paid-media-ppc-strategist"]
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
账户架构（Account Architecture）是 PPC 广告账户的层级结构设计，包括 Campaign（广告系列）→ Ad Group（广告组）→ Keywords/Ads（关键词/广告）的完整层级体系，以及命名规范、标签系统、账户政策等辅助管理机制。核心理念：**账户架构即战略**（account structure as strategy）——而非单纯的关键词和出价管理。
|
||||
|
||||
## Core Components
|
||||
|
||||
### Account Level
|
||||
- **账户设置**：时区、货币、跳转追踪域名
|
||||
- **转化追踪**：Conversion Actions 配置（主/次、微/宏转化）
|
||||
- **用户权限**：多用户协作和访问级别
|
||||
|
||||
### Campaign Level
|
||||
- **广告系列类型**：Search / Shopping / Performance Max / Demand Gen / Display / Video
|
||||
- **预算**：日预算或总预算
|
||||
- **地理定向**：国家/地区/DMA/城市级别定向
|
||||
- **语言定向**：受众语言
|
||||
- **投放时间**：Schedule 设置
|
||||
- **竞价策略**：Manual CPC / Automated Bidding
|
||||
|
||||
### Ad Group Level
|
||||
- **关键词主题**：围绕单一主题/产品/意图的关键词分组
|
||||
- **广告变体**：同一广告组内多个广告文案轮播测试
|
||||
- **受众定向**：广告组级受众叠加
|
||||
|
||||
## Naming Conventions at Scale
|
||||
|
||||
支持数百个广告系列的命名规范示例：
|
||||
```
|
||||
{{Channel}}-{{Region}}-{{ProductLine}}-{{CampaignType}}-{{MatchType}}
|
||||
# 例如：
|
||||
SEA-US-Software-Competitor-Exact
|
||||
PMX-GLOBAL-Brand-Awareness-Broad
|
||||
```
|
||||
|
||||
## Label System
|
||||
|
||||
- **颜色标签**：按产品线/优先级/状态分类
|
||||
- **过滤器**：跨广告系列/广告组的灵活筛选
|
||||
- **脚本自动化**：通过 Labels + Scripts 实现批量操作
|
||||
|
||||
## Connections
|
||||
- [[TieredCampaignArchitecture]]：Account Architecture 的具体实现模式
|
||||
- [[GoogleAds]]：Account Architecture 的主要操作平台
|
||||
- [[PerformanceMax]]：与标准广告系列结构不同的 AI 驱动架构
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
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]] — 行动项的自动化创建
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "Active-Directory-Integration"
|
||||
type: concept
|
||||
tags: [Identity, AWS, Networking]
|
||||
sources: [ctp-topic-7-saas-landing-zone-design]
|
||||
last_updated: 2026-05-06
|
||||
---
|
||||
|
||||
## Active-Directory-Integration
|
||||
|
||||
AWS 环境中的 Active Directory 集成方案，用于实现统一的身份认证和资源访问控制。
|
||||
|
||||
## Definition
|
||||
|
||||
Active Directory 集成是 Landing Zone 基线服务的重要组成部分：
|
||||
- **核心功能**：通过双 AD 节点实现域加入（Domain Join）和资源访问控制
|
||||
- **部署位置**：独立的 Active Directory Account（基线账户层）
|
||||
- **认证用途**：用于 AWS Workspaces、EC2 实例（Windows/Linux）、VPN 接入等场景的身份认证
|
||||
|
||||
## Role in SAS Landing Zone
|
||||
|
||||
在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 Baseline 账户中：
|
||||
- **部署**：Active Directory 账户托管两个 AD 节点（双节点高可用）
|
||||
- **用途 1**：域加入（Domain Join）— Windows 和 Linux 实例自动加入 AD 域
|
||||
- **用途 2**：资源访问控制 — 基于 AD 组映射 IAM 角色，实现最小权限原则
|
||||
- **用途 3**：VPN 认证 — Pulse VPN 通过 AD 认证远程访问人员身份
|
||||
|
||||
## Key Properties
|
||||
- **Type**: Identity & Access Management
|
||||
- **Architecture**: 双 AD 节点高可用
|
||||
- **In SAS LZ Layer**: Baseline Accounts
|
||||
|
||||
## Related Concepts
|
||||
- [[Domain-Join]] — 实例域加入机制
|
||||
- [[Federated-Access]] — 联邦身份认证
|
||||
- [[Multi-factor-Authentication]] — 多因素认证
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 基线账户身份认证基础设施
|
||||
- [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]] — AD 集成与登录详细实践
|
||||
- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] — Gruntwork LZ 中的 AD 服务集成
|
||||
- [[ctp-topic-6-aws-workspaces-demo]] — AWS Workspaces 使用 AD 账号登录
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
title: "Active Accountability"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-27
|
||||
---
|
||||
|
||||
# Active Accountability
|
||||
|
||||
## Definition
|
||||
AI Agent 主动发消息询问用户是否完成习惯，而非等待用户主动打开 App 记录。是区别于传统习惯追踪 App 的核心机制。
|
||||
|
||||
## Core Mechanism
|
||||
- Agent 主动在预设时间发送签到消息（如早上 7:30 询问晨练）
|
||||
- 用户回复确认完成或说明未完成原因
|
||||
- Agent 记录数据并调整后续消息策略
|
||||
- 整个过程无需用户主动打开任何 App
|
||||
|
||||
## Contrast with Passive Tracking
|
||||
|
||||
| | Passive Tracking（传统 App） | Active Accountability（本方案） |
|
||||
|---|---|---|
|
||||
| 触发方式 | 用户主动打开 App | Agent 主动发送消息 |
|
||||
| 推送策略 | Push 通知（易被忽略） | 即时消息（直接触达） |
|
||||
| 数据录入 | 用户手动记录 | 用户回复确认 |
|
||||
| 激励时机 | 视觉激励（成就徽章） | 文字激励（个性化消息） |
|
||||
| 持续性 | 一周后放弃率高 | 可持续更长时间 |
|
||||
|
||||
## Why It Matters
|
||||
真正驱动行为改变的不是 App 的视觉效果，而是有人在关心你、询问你、记住你。Active Accountability 用 AI 实现了"问责伙伴"的每日陪伴感。
|
||||
|
||||
## Used In
|
||||
- [[Habit Tracker & Accountability Coach]]：核心设计理念
|
||||
- [[Custom Morning Brief]]：类似的自主动推送模式
|
||||
|
||||
## Related Concepts
|
||||
- [[Adaptive Tone]]：Active Accountability 的实现机制
|
||||
- [[Check-in Fatigue]]：需要控制频率以避免适得其反
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: "Actor Replication"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: [unreal-multiplayer-architect]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
Actor 复制是 UE5 多人游戏网络同步的基础机制，允许 Actor 的属性和状态在服务器与所有客户端之间自动同步。通过 `UPROPERTY(Replicated)` 和 `GetLifetimeReplicatedProps()` 实现。
|
||||
|
||||
## Core Mechanisms
|
||||
- `UPROPERTY(Replicated)` — 将属性标记为需要复制到所有客户端
|
||||
- `UPROPERTY(ReplicatedUsing=OnRep_X)` — 带通知函数的复制，客户端可在属性变化时执行逻辑
|
||||
- `DOREPLIFETIME_CONDITION` — 条件复制，如 `COND_OwnerOnly`、`COND_SimulatedOnly`
|
||||
- `GetNetPriority()` — 控制 Actor 的复制优先级
|
||||
- `SetNetUpdateFrequency()` — 控制 Actor 的复制频率
|
||||
|
||||
## Key Implementation
|
||||
```cpp
|
||||
void AMyNetworkedActor::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const
|
||||
{
|
||||
Super::GetLifetimeReplicatedProps(OutLifetimeProps);
|
||||
DOREPLIFETIME(AMyNetworkedActor, Health);
|
||||
DOREPLIFETIME_CONDITION(AMyNetworkedActor, PrivateInventoryCount, COND_OwnerOnly);
|
||||
}
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
- 仅复制所有客户端都需要的状态
|
||||
- 使用 `COND_OwnerOnly` 减少私有状态的带宽消耗
|
||||
- 按 Actor 类型设置合适的 `NetUpdateFrequency`（大多数 20–30Hz）
|
||||
- 使用 `ReplicatedUsing` 让客户端能响应属性变化
|
||||
|
||||
## Connection to Other Concepts
|
||||
- [[Server-Authoritative Model]] — Actor Replication 是实现服务器权威的技术基础
|
||||
- [[Network Prediction]] — 客户端利用复制的状态进行预测和调和
|
||||
- [[Replication Graph]] — 空间分区优化复制性能
|
||||
|
||||
## Relationship to Agent
|
||||
[[UnrealMultiplayerArchitect]] 强调 Actor 复制的正确实现是 UE5 多人游戏开发的第一步，必须从一开始就用 `DOREPLIFETIME_CONDITION` 进行带宽优化。
|
||||
|
||||
## Aliases
|
||||
- UE5 Replication
|
||||
- Property Replication
|
||||
- State Synchronization
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "Actor Replication"
|
||||
type: concept
|
||||
tags: ["unreal-engine", "networking", "multiplayer"]
|
||||
sources: ["unreal-multiplayer-architect", "unreal-multiplayer-architect"]
|
||||
last_updated: 2026-04-30
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Actor 复制
|
||||
- 属性复制
|
||||
- Property Replication
|
||||
|
||||
## 定义
|
||||
Actor 复制是 UE5 中将服务器端 Actor 状态同步到客户端的核心网络机制。通过 `UPROPERTY(Replicated)` 声明需要复制的属性。
|
||||
|
||||
## 复制条件
|
||||
- `Replicated`: 无条件复制到所有相关客户端
|
||||
- `ReplicatedUsing=OnRep_Function`: 复制时触发 RepNotify 回调
|
||||
- `DOREPLIFETIME_CONDITION`: 按条件复制（如 `COND_OwnerOnly`、`COND_SimulatedOnly`）
|
||||
|
||||
## 生命周期
|
||||
1. 服务器模拟游戏逻辑，更新 Actor 属性
|
||||
2. UE5 复制层检测属性变化
|
||||
3. 按 `NetUpdateFrequency` 打包更新
|
||||
4. 通过网络传输到客户端
|
||||
5. 客户端应用更新，触发 RepNotify（如果有）
|
||||
|
||||
## 关键配置
|
||||
- `NetUpdateFrequency`: 更新频率（默认 100Hz，通常过高）
|
||||
- `MinNetUpdateFrequency`: 最小更新频率
|
||||
- `GetNetPriority()`: 优先级，靠近/可见的 Actor 优先级更高
|
||||
|
||||
## 优化策略
|
||||
- Replication Graph 空间分区
|
||||
- 条件复制减少带宽
|
||||
- 按 Actor 类型设置差异化频率
|
||||
|
||||
## 相关概念
|
||||
- [[Server-Authoritative Model]] — 复制背后的权威模型
|
||||
- [[Replication Graph]] — 复制优化框架
|
||||
- [[GAS (Gameplay Ability System)]] — 基于复制的能力系统
|
||||
@@ -1,105 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,47 +0,0 @@
|
||||
---
|
||||
title: "Adaptive Music"
|
||||
type: concept
|
||||
tags: [game-audio, music, middleware]
|
||||
sources: [game-audio-engineer]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Adaptive Game Music
|
||||
- Dynamic Music System
|
||||
- Interactive Music
|
||||
|
||||
## Definition
|
||||
|
||||
由游戏状态参数（如 CombatIntensity、Tension、Health）驱动的动态音乐系统。通过音频中间件（FMOD/Wwise）的参数 API，实时调整音乐层切换、混音比例和编曲元素，无需硬切。核心原则：**tempo-synced 转换**（与节拍对齐）和**玩家感受而非意识到**。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
### Tension Parameter（0.0–1.0）
|
||||
| 值 | 游戏状态 | 音乐响应 |
|
||||
|----|---------|---------|
|
||||
| 0.0 | 无敌人/探索 | 仅基础探索层，可无限播放不疲劳 |
|
||||
| 0.3 | 警戒状态 | 鼓点进入 |
|
||||
| 0.6 | 主动战斗 | 完整编曲 |
|
||||
| 1.0 | Boss/危机 | 最高强度层 |
|
||||
|
||||
**来源驱动**：AI threat level aggregator script
|
||||
**更新频率**：每 0.5 秒（lerp 平滑）
|
||||
|
||||
### Music Transition Rules
|
||||
- 必须 tempo-synced（量化为最近节拍边界）
|
||||
- 禁止 hard cuts（除非设计明确要求）
|
||||
- Stem-based horizontal re-sequencing 优先于 vertical layering（内存效率）
|
||||
- 始终保留 neutral/exploration 层可独立无限播放
|
||||
|
||||
## Connections
|
||||
- [[SpatialAudio]]：自适应音乐也需要空间化处理（3D 定位音乐会随玩家位置变化）
|
||||
- [[AudioMiddleware]]（FMOD/Wwise）：提供参数 API 驱动的实时音乐控制
|
||||
- [[game-audio-engineer]] ← authored_by ← [[GameAudioEngineer]]
|
||||
|
||||
## Related Concepts
|
||||
- [[SpatialAudio]]：空间化音效，与自适应音乐共享中间件架构
|
||||
- [[ProceduralAudio]]：程序化音频可作为自适应音乐的补充层
|
||||
|
||||
## Sources
|
||||
- [[game-audio-engineer]]：完整规范包括 CombatIntensity 参数映射表、音乐集成五阶段流程
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: "Adaptive Tone"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-27
|
||||
---
|
||||
|
||||
# Adaptive Tone
|
||||
|
||||
## Definition
|
||||
AI Agent 根据用户当前表现状态动态调整语气和沟通策略的机制。在习惯追踪场景中，连续打卡时给予鼓励性语言（encouraging），连续错过时转为温和坚持（gently persistent）。
|
||||
|
||||
## Core Mechanism
|
||||
- **持续成功时**：强化正面激励，引用当前 streak 天数（如"Day 15，不打断！"）
|
||||
- **偶尔错过时**：承认现状，不施加内疚感，提醒用户当初目标
|
||||
- **连续错过（≥3天）**：发送更长的激励消息，询问是否需要调整目标
|
||||
- **无响应时**：2小时内发送一条跟进消息，之后停止（避免骚扰）
|
||||
|
||||
## Why It Matters
|
||||
静态提醒容易被大脑忽略，个性化且语境感知的消息具有真实激励效果。这是 AI 问责伙伴区别于普通 cron job 的核心差异化因素。
|
||||
|
||||
## Used In
|
||||
- [[Habit Tracker & Accountability Coach]]：核心差异化机制
|
||||
- [[Custom Morning Brief]]：类似的自适应消息策略
|
||||
|
||||
## Related Concepts
|
||||
- [[Active Accountability]]：依赖 Adaptive Tone 实现
|
||||
- [[Streak Tracking]]：为 Adaptive Tone 提供数据依据
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
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+ 倾向于减少人工结构干预
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
title: "Adversarial Debate Pattern"
|
||||
type: concept
|
||||
tags: []
|
||||
sources:
|
||||
- multi-agent-system-reliability
|
||||
last_updated: 2026-04-28
|
||||
---
|
||||
|
||||
# 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]]
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,62 +0,0 @@
|
||||
---
|
||||
title: "Agent Collaboration Protocol"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
规范化多 Agent 协作流程——定义何时发起协作、协作内容模板、协作边界及交接合同。
|
||||
|
||||
## Overview
|
||||
|
||||
在多 Agent 系统中，不同 Agent 负责不同专业领域。Agent Collaboration Protocol 为每个协作节点定义标准化协议，确保信息传递完整、意图清晰、交接无遗漏。
|
||||
|
||||
## Core Components
|
||||
|
||||
### 协作发起时机
|
||||
- 交接点：当前 Agent 工作完成后、需要下游 Agent 承接时
|
||||
- 依赖点：当前 Agent 需要上游 Agent 输出时
|
||||
- 冲突点：发现超出自身职责范围的问题时
|
||||
- 安全点：涉及凭证/密钥/认证等安全敏感操作时
|
||||
|
||||
### 协作内容模板
|
||||
每个协作请求必须包含：
|
||||
1. **上下文摘要**：工作进展和已完成内容
|
||||
2. **具体请求**：需要对方完成什么
|
||||
3. **交付物格式**：期望的输出格式和结构
|
||||
4. **约束条件**：时间限制、质量标准、特殊要求
|
||||
5. **交接合同**：交接数据的 schema 定义
|
||||
|
||||
### 协作边界
|
||||
- 不越权：不在自身职责外做决策
|
||||
- 不兜底：发现超出范围的问题时立即上报，而非自行处理
|
||||
- 不丢失：每次协作记录到 log.md，确保可追溯
|
||||
|
||||
## Workflow Architect 中的协作协议
|
||||
|
||||
| 协作方 | 时机 | 内容 | 交付物 |
|
||||
|--------|------|------|--------|
|
||||
| [[Reality-Checker]] | Draft spec 完成后、标记 Review 前 | 规范与实际代码差距验证 | Reality Checker Findings 表 |
|
||||
| [[Backend-Architect]] | 发现实现缺陷时 | 补充缺失逻辑（重试/错误处理） | 修复代码 |
|
||||
| [[Security-Engineer]] | 涉及凭证/密钥/认证/API 调用时 | 凭证传递机制安全性审查 | 安全评估意见 |
|
||||
| [[API-Tester]] | Spec 标记 Approved 后 | 生成全部测试用例 | 自动化测试脚本 |
|
||||
| [[DevOps-Automator]] | 揭示基础设施销毁顺序需求时 | 验证 IaC 销毁顺序 | 销毁顺序确认 |
|
||||
|
||||
## Key Principles
|
||||
|
||||
- **主动发起**：发现需要协作时立即发起，不等待
|
||||
- **标准化模板**：每次协作使用统一格式，减少理解成本
|
||||
- **明确边界**：知道自己不做什么，比知道自己做什么更重要
|
||||
- **完整交接**：交接内容包括所有上下文，而非仅最终结果
|
||||
|
||||
## Related Concepts
|
||||
- [[Handoff-Contract]]：协作交接的数据 schema 定义
|
||||
- [[Reality-Checker]]：Workflow Architect 的首个强制协作节点
|
||||
- [[Workflow-Tree-Spec]]：协作产出的主要载体
|
||||
|
||||
## Aliases
|
||||
- Multi-Agent Handoff Protocol
|
||||
- Agent Coordination Framework
|
||||
- Inter-Agent Collaboration Standard
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
title: "Agent Collapse"
|
||||
type: concept
|
||||
tags:
|
||||
- "agentic-ai"
|
||||
- "failure-mode"
|
||||
- "context-window"
|
||||
sources:
|
||||
- "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog"
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Overview
|
||||
Agent Collapse（10-Step Collapse）——AI Agent 在多步任务执行过程中逐渐崩溃的现象，典型表现为步骤 1-3 正常执行，步骤 7 开始幻觉数据，步骤 10 输出损坏的 JSON 或崩溃。
|
||||
|
||||
## Root Causes
|
||||
- **Context window 静默截断**：工具输出超出上下文窗口后被静默截断，模型感知不到数据丢失
|
||||
- **无 Schema 验证**：LLM 输出的字段类型漂移（price 从 float 变为 string），下游管道静默产生垃圾数据
|
||||
- **无状态管理**：context window 是易失的，关键状态（如 pending/in-progress/completed 标记）随上下文重置丢失
|
||||
- **无幂等重试**：单步失败导致整个管道重启，而非精确重试失败步骤
|
||||
|
||||
## Manifestation Example
|
||||
> 部署一个自主 Agent 编写市场研究报告。步骤 1-3 完美执行：计划任务 → 搜索网页 → 提取竞品数据。步骤 7 开始幻觉统计数据（因为搜索工具 payload 超出上下文窗口被静默截断）。步骤 10 输出损坏的 JSON 字符串（因为管道中没有 Schema 验证器）。
|
||||
|
||||
## Solutions
|
||||
- [[Harness-Engineering]]：系统性地为每个失效点增加防护层
|
||||
- [[State-Externalization]]：将任务状态写入磁盘，不依赖 context window
|
||||
- [[Schema-Drift]] 防护：每个 LLM 输出必须经过 JSON Schema 验证
|
||||
- [[Idempotency]]：单步失败只重试该步，不重启管道
|
||||
|
||||
## Source
|
||||
- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]]
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
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
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
title: "Agent Handoff"
|
||||
type: concept
|
||||
tags: [multi-agent, coordination, handoff, nexus]
|
||||
sources: [executive-brief, quickstart, workflow-with-memory]
|
||||
last_updated: 2026-05-01
|
||||
aliases:
|
||||
- Agent Handoff Protocol
|
||||
- Structured Handoff
|
||||
- Context Continuity
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Agent 交接（Agent Handoff）—— 多 Agent 工作流中从一个 Agent 交付物传递到下一个 Agent 的结构化上下文传递协议，确保接收 Agent 获得完整的执行上下文，避免冷启动和重复劳动。
|
||||
|
||||
## Core Problem
|
||||
|
||||
**交接边界失败率：73%** —— 当 Agent 缺乏结构化协调协议时，多 Agent 项目在交接边界处的失败率高达 73%，表现为：
|
||||
- 上下文丢失（交接时未传递关键决策和中间产物）
|
||||
- 重复劳动（下一个 Agent 重复上一个 Agent 已完成的工作）
|
||||
- 质量缺口（上一个 Agent 的缺陷传递到下一个 Agent）
|
||||
|
||||
## Structured Handoff Components
|
||||
|
||||
一份完整的 Agent 交接应包含：
|
||||
|
||||
1. **交付物清单**：明确列出发交给下一 Agent 的所有文件和产出
|
||||
2. **上下文摘要**：用 3-5 句话总结当前状态和已完成的关键决策
|
||||
3. **下一步指令**：清楚描述下一 Agent 需要完成的具体任务
|
||||
4. **质量证据**：提供可验证的质量证明（测试截图/性能数据/设计评审通过记录）
|
||||
5. **风险标记**：标注已知的限制条件和潜在风险
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Handoff Boundary]]：交接的边界点，即失败率最高的 73% 失败发生处
|
||||
- [[Evidence Over Claims]]：交接内容必须包含可验证的证据，而非口头承诺
|
||||
- [[Quality Gate]]：交接后需通过质量门控验证才能推进
|
||||
- [[Memory-Based-Handoff]]：通过 MCP Memory Server 实现自动化的 Agent 交接机制
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
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 的框架
|
||||
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
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中的集成与应用详解]]
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
title: "Agent-Orchestration"
|
||||
type: concept
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Definition
|
||||
Agent 编排（Agent Orchestration）是指通过工作流引擎统一协调和调度多个 AI Agent，使它们协同工作完成复杂任务的管理模式。
|
||||
|
||||
## Key Patterns
|
||||
- **集中式编排**：单一工作流引擎（n8n）控制多个 Agent 的调用顺序和数据流转
|
||||
- **并行调用**：同一工作流中同时调用多个 Agent（如 Hermes + OpenClaw）
|
||||
- **条件路由**：根据前一个 Agent 的输出决定调用哪个 Agent
|
||||
|
||||
## n8n 编排架构示例
|
||||
```
|
||||
n8n Workflow
|
||||
├─ Trigger (Telegram/Email/Webhook...)
|
||||
├─ HTTP Request Node 1 → Hermes Agent (port 8642)
|
||||
├─ HTTP Request Node 2 → OpenClaw Agent (port 18789)
|
||||
└─ Output Node (Telegram/File/Email...)
|
||||
```
|
||||
|
||||
## 优势
|
||||
- **统一入口**：用户通过单一界面与多个 Agent 交互
|
||||
- **数据流转**：一个 Agent 的输出可直接作为另一个 Agent 的输入
|
||||
- **可观测性**：工作流引擎提供执行日志和状态追踪
|
||||
- **灵活性**：可随时增删 Agent，不影响整体架构
|
||||
|
||||
## Related
|
||||
- [[n8n]] 是本 Wiki 中记录的编排工具
|
||||
- [[Hermes-Agent]] 和 [[OpenClaw]] 是被编排的 Agent 示例
|
||||
- [[OpenAI-Compatible-API]] 是连接 Agent 的标准接口
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
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 中的角色设计
|
||||
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
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」错误排查-我以为是小问题-结果踩了大坑]]
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
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（另一种协作模式）
|
||||
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
title: "Agent Template"
|
||||
type: concept
|
||||
tags: [multi-agent, agent-design, the-agency]
|
||||
sources: [contributing_zh-cn, contributing, contributing-to-the-agency]
|
||||
last_updated: 2026-04-27
|
||||
---
|
||||
|
||||
# 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
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: "Agent"
|
||||
type: concept
|
||||
tags: [agent, llm, automation, mcp]
|
||||
aliases: [Agent, AI Agent, 智能体, 自主代理]
|
||||
last_updated: 2025-12-20
|
||||
---
|
||||
|
||||
## Definition
|
||||
Agent，智能体，由 [[Large Language Model]] + [[Model Context Protocol|MCP]] + [[Prompt]] 组成，实现自动化执行。LLM 给出步骤方法和工具调用指令，MCP 负责实际执行。
|
||||
|
||||
## Key Facts
|
||||
- LLM 本身只给出"步骤方法"，不会真正执行（如大模型告诉你如何发邮件，但不会自己发）
|
||||
- Agent 将 LLM 与 MCP 工具整合，实现真正的自动化
|
||||
- Agent 工作流：输入 Prompt（含工具描述）→ LLM 返回工具名和参数 → MCP Server 执行 → 返回结果
|
||||
- 是 [[LangChain]] 等开发框架的核心应用场景
|
||||
|
||||
## Connections
|
||||
- [[Large Language Model]] ← 核心组件 ← [[Agent]]
|
||||
- [[Model Context Protocol]] ← 执行层 ← [[Agent]]
|
||||
- [[Prompt]] ← 输入 ← [[Agent]]
|
||||
- [[LangChain]] ← 用于构建 ← [[Agent]]
|
||||
|
||||
## Sources
|
||||
- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
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
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "Agent Integration"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: [qwen-readme]
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Overview
|
||||
Agent Integration（Agent 集成适配）是将统一的 Markdown Agent 规范转换为各 AI 编码工具原生格式的适配层技术。The Agency 通过 `convert.sh` 和 `install.sh` 两层脚本实现这一目标。
|
||||
|
||||
## Definition
|
||||
Agent Integration = 统一的 Agent 行为规范（`.md`） + 工具特定的转换器（`convert.sh`） + 标准化的安装机制（`install.sh`）
|
||||
|
||||
## Key Properties
|
||||
- **单向转换**：从源 `.md` 到目标格式，不做反向同步
|
||||
- **工具原生**：转换后的格式是该工具推荐/唯一的配置方式
|
||||
- **作用域分层**：Home-Scoped（全用户级）vs Project-Scoped（项目级）
|
||||
- **注册机制差异**：部分工具依赖自动发现（如 Claude Code），部分需要显式启动参数（如 Kimi `--agent-file`）
|
||||
|
||||
## Integration Patterns
|
||||
| 工具 | 格式 | 作用域 | 注册机制 |
|
||||
|------|------|--------|---------|
|
||||
| Claude Code | `.md` | Home | 自动发现 |
|
||||
| GitHub Copilot | `.md` | Home | 自动发现 |
|
||||
| Antigravity | `SKILL.md` | Home | 工具内置 |
|
||||
| Gemini CLI | 扩展包 + Skill | Home | 自动加载 |
|
||||
| OpenCode | `.md` | Project | 自动发现 |
|
||||
| OpenClaw | `SOUL.md+AGENTS.md+IDENTITY.md` | Home | Gateway |
|
||||
| Cursor | `.mdc` | Project | 自动发现 |
|
||||
| Aider | `CONVENTIONS.md` | Project | 自动发现 |
|
||||
| Windsurf | `.windsurfrules` | Project | 自动发现 |
|
||||
| Kimi Code | YAML | Home | 显式启动参数 |
|
||||
| Qwen Code | `.md` SubAgent | Project | 自动发现 |
|
||||
|
||||
## Sources
|
||||
- [[OpenCode Integration]]（`Agent/agency-agents/integrations/README.md`）
|
||||
- [[OpenClaw Integration]]（`Agent/agency-agents/integrations/openclaw/README.md`）
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
title: "Agent Scopes"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-29
|
||||
---
|
||||
|
||||
## Overview
|
||||
Agent Scopes（Agent 作用域）指 AI 编码 Agent 的生效范围，决定了 Agent 配置是全局共享还是项目专用。这是 The Agency 集成架构中的重要维度。
|
||||
|
||||
## Home-Scoped Agent（全用户级 Agent）
|
||||
- 安装位置：用户家目录（如 `~/.claude/agents/`、`~/.gemini/`）
|
||||
- 生效范围：该用户所有项目均可用
|
||||
- 安装方式：`./scripts/install.sh --tool <tool>`
|
||||
- 代表工具：Claude Code、GitHub Copilot、Antigravity、Gemini CLI、OpenClaw、Kimi Code
|
||||
|
||||
## Project-Scoped Agent（项目级 Agent）
|
||||
- 安装位置：项目根目录（如 `./.opencode/agents/`、`./.windsurfrules`）
|
||||
- 生效范围：仅当前项目可用
|
||||
- 安装方式：从项目根目录运行 `./scripts/install.sh --tool <tool>`
|
||||
- 代表工具：OpenCode、Cursor、Aider、Windsurf、Qwen Code
|
||||
|
||||
## Key Differences
|
||||
| 维度 | Home-Scoped | Project-Scoped |
|
||||
|------|-------------|----------------|
|
||||
| 安装路径 | `~/.tool/` | `./.tool/` |
|
||||
| 多项目复用 | ✅ | ❌ |
|
||||
| 项目定制化 | ❌ | ✅ |
|
||||
| 权限控制 | 用户级 | 仓库级（可提交 git） |
|
||||
| 冲突风险 | 高（同名覆盖） | 低（项目隔离） |
|
||||
|
||||
## Sources
|
||||
- [[OpenCode Integration]]（`Agent/agency-agents/integrations/README.md`）
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "Agent Workspace"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Overview
|
||||
Agent Workspace（Agent 工作区）是 AI Agent 的定义容器单元，包含 Agent 的全部行为规范、身份和配置信息。
|
||||
|
||||
## Definition
|
||||
Agent Workspace = 行为规范（AGENTS.md/SOUL.md）+ 身份定义（IDENTITY.md）+ 其他配置文件
|
||||
|
||||
## Key Properties
|
||||
- **多文件结构**：OpenClaw Workspace 包含 `SOUL.md`（核心理念）、`AGENTS.md`（行为规范）、`IDENTITY.md`（身份定义）三文件
|
||||
- **安装即注册**：Workspace 复制到目标路径即完成 Agent 注册，无需额外配置
|
||||
- **工具特定性**：不同工具对 Workspace 格式要求不同（OpenClaw 三文件 vs OpenCode 单文件）
|
||||
|
||||
## Relationships
|
||||
- [[AgentIntegration]] ← uses ← [[AgentWorkspace]]（Workspace 是集成的最小单元）
|
||||
- [[OpenClaw]] ← manages ← [[AgentWorkspace]]
|
||||
|
||||
## Sources
|
||||
- [[OpenClaw Integration]]（`Agent/agency-agents/integrations/openclaw/README.md`）
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: "Agentic AI"
|
||||
type: concept
|
||||
tags: []
|
||||
sources:
|
||||
- designing-for-agentic-ai
|
||||
- multi-agent-system-reliability
|
||||
last_updated: 2026-04-27
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Agentic AI（智能体AI）是一种能够**自主行动、主动决策**的AI系统。与传统AI不同，它能够：
|
||||
- 与环境进行真实交互
|
||||
- 基于上下文做出决策
|
||||
- 主动预判用户需求
|
||||
- 在无需持续人工干预的情况下完成任务
|
||||
|
||||
类似于拥有**24/7全天候工作的私人代理**，而非仅响应指令的工具。
|
||||
|
||||
## 与 GenAI 的区别
|
||||
|
||||
| 维度 | GenAI（生成式AI） | Agentic AI（智能体AI） |
|
||||
|------|------------------|----------------------|
|
||||
| 核心能力 | 创建内容（文本/图像/音乐） | 行动、决策、预判 |
|
||||
| 交互模式 | 被动响应用户请求 | 主动发起行动 |
|
||||
| 典型场景 | 生成诗歌、写文章 | 预约会议、发送邀请 |
|
||||
| 设计范式 | 响应式交互 | 实时反馈式交互 |
|
||||
|
||||
## Agentic AI 产品设计五原则
|
||||
|
||||
1. **Transparency（透明度）**：可视化AI任务进度，提供推理过程摘要，让用户理解AI如何做决策
|
||||
2. **Control（控制感）**：允许用户停止AI任务、撤销AI操作、设置AI行为偏好
|
||||
3. **Personalization（个性化）**：用历史行为预测未来需求，允许用户对AI表现提供反馈
|
||||
4. **Conversation（对话式交互）**：用自然语言交互，提供AI输入理解方式的反馈
|
||||
5. **Anticipation（主动预测）**：AI预判用户需求，同时提供调整AI自主权等级的控制项
|
||||
|
||||
## 核心设计洞察
|
||||
|
||||
> "Observing the AI's decision-making process, understanding its 'thinking,' is a form of interaction in itself."
|
||||
|
||||
用户不应成为被动的旁观者——**观察AI决策过程本身就是一种交互形式**。用户虽未点击按钮，但仍在评估、可能介入。
|
||||
|
||||
## Related
|
||||
- [[designing-for-agentic-ai]] — 本概念的主要来源
|
||||
- [[GenAI]] — Agentic AI 的对比基准（生成式AI）
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
title: "Agentic System"
|
||||
type: concept
|
||||
tags: [ai, agent, autonomy, llm]
|
||||
sources: []
|
||||
last_updated: 2025-05-09
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Agentic System
|
||||
- AI Agentic System
|
||||
- 智能体系统
|
||||
|
||||
## Definition
|
||||
由 Agent（智能体）和 Workflow（工作流）组成的混合系统。Agent 利用 LLM 动态判断用户请求需要调用哪些工具并生成响应，而非按预定义路径执行固定的输出序列。与传统工作流的"确定性输出"不同，Agentic System 能根据上下文自适应地选择工具组合。
|
||||
|
||||
## Core Distinction: Workflow vs. Agent
|
||||
|
||||
| 维度 | Workflow | Agent |
|
||||
|------|----------|-------|
|
||||
| 执行逻辑 | 预定义，固定路径 | LLM 驱动，动态选择 |
|
||||
| 输出 | 一致、可预测 | 随输入变化 |
|
||||
| 工具选择 | 预设顺序 | 按需调用 |
|
||||
| 适用场景 | 规则明确的自动化 | 需要推理和判断的任务 |
|
||||
|
||||
## Components
|
||||
- **Agent**：核心决策单元，接收用户输入、调用 LLM、选择并执行工具
|
||||
- **Memory**：保留多轮对话上下文，使 Agent 理解会话历史
|
||||
- **Tools**：Agent 可调用的外部能力（API、数据库、计算模块等）
|
||||
- **Workflow**：将 Agent 嵌入更大的自动化流程中
|
||||
|
||||
## Relationship to Other Concepts
|
||||
- [[N8N]]：N8N 的 Advanced AI Agent 节点是构建 Agentic System 的低代码平台
|
||||
- [[Memory in AI Agents]]：Agent 保留上下文的关键机制
|
||||
- [[Tool Integration]]：Agent 调用外部能力的基础
|
||||
|
||||
## Sources
|
||||
- [[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]]
|
||||
- [[how-agentic-ai-can-help-for-cloud-devops]]
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
title: "AgenticWorkflow"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
多步骤、长时间运行的 AI Agent 任务执行流程——Agent 能够自主规划、子任务分解、工具调用和环境适应，完成复杂目标而非简单问答。
|
||||
|
||||
## Description
|
||||
Agentic Workflow 是 AI Agent 从"被动问答"走向"主动执行"的关键范式。它涉及：
|
||||
- **自主规划**：Agent 将复杂目标拆解为可执行的子步骤序列
|
||||
- **工具调用**：使用代码执行、API、文件系统等工具与环境交互
|
||||
- **状态追踪**：维护中间状态，根据反馈调整下一步行动
|
||||
- **长时运行**：任务可能持续数小时，涉及数百个子步骤
|
||||
|
||||
典型场景：构建完整 Web 应用、深度市场研究、自动化数据管道。
|
||||
|
||||
## Related Concepts
|
||||
- [[TaskVisibility]]
|
||||
- [[ExternalReasoning]]
|
||||
- [[PlanMode]]
|
||||
|
||||
## Related Entities
|
||||
- [[OpenClawWorkspace]]
|
||||
|
||||
## Examples
|
||||
- [[TodoistTaskManager]]：为 Agentic Workflow 提供任务可视化
|
||||
- [[AutonomousProjectManagement]]：多 Agent 协作的复杂项目执行
|
||||
- [[OvernightMiniAppBuilder]]：通宵运行的自主应用构建
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
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)
|
||||
@@ -1,52 +0,0 @@
|
||||
---
|
||||
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
|
||||
- 无已知冲突
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
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 模式的金融场景应用
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
title: "Air-Gapped SLM Fix Generation"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
在完全离线（气隙）的环境中，通过本地 Small Language Models（SLM，如 Ollama 运行的 Phi-3/Llama-3/Mistral）生成确定性修复逻辑（Python lambda）的方法论。
|
||||
|
||||
## Core Principle
|
||||
|
||||
**AI generates logic — never touches data directly.**
|
||||
|
||||
SLM 输出的是一个转换函数（lambda），由系统执行，而非 AI 直接修改数据。这样保证了可审计、可回滚、可解释的数据变更。
|
||||
|
||||
## Workflow
|
||||
|
||||
1. SLM 接收聚类样本 + 列名
|
||||
2. SLM 输出严格格式化的 JSON（含 transformation、confidence_score、reasoning、pattern_type）
|
||||
3. Lambda Safety Gate 验证（必须以 `lambda` 开头，不含 `import/exec/eval/os/subprocess`）
|
||||
4. 验证通过后向量化执行于整个聚类
|
||||
5. 低于 0.75 置信度的自动进入人工隔离队列
|
||||
|
||||
## Safety Guarantees
|
||||
|
||||
- **Zero PII Egress**: 所有处理完全本地，无网络出口
|
||||
- **Deterministic Output**: SLM 输出确定性 lambda，不做创意性文本生成
|
||||
- **Safety Gate**: 任何包含危险关键词的 lambda 立即被拒绝并路由至隔离区
|
||||
- **Audit Trail**: 每条数据变更记录完整上下文
|
||||
|
||||
## Related
|
||||
|
||||
- [[Semantic Anomaly Compression]]
|
||||
- [[Lambda Safety Gate]]
|
||||
- [[AI Generates Logic Not Data]]
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
title: "Alert Management"
|
||||
type: concept
|
||||
tags: [monitoring, alerting, devops, sre]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Alert Management（告警管理）
|
||||
|
||||
**中文名称：** 告警管理
|
||||
|
||||
**类型：** 运维流程与方法论
|
||||
|
||||
**别名：**
|
||||
- 告警管理
|
||||
- 告警分发
|
||||
- Alert Routing
|
||||
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
告警管理（Alert Management）是指从告警**生成 → 接收 → 分类 → 分发 → 响应 → 关闭**的全生命周期管理流程，目的是在关键系统异常时及时通知相关人员，同时避免告警风暴和告警疲劳。
|
||||
|
||||
**告警生命周期：**
|
||||
1. **生成（Generate）：** 监控系统（Prometheus）基于规则判断是否触发告警
|
||||
2. **转发（Forward）：** Prometheus 通过 Alertmanager API 发送告警
|
||||
3. **分发表单（Dismiss）：** Alertmanager 执行抑制、分组、静默
|
||||
4. **路由（Route）：** 按标签/严重级别路由到对应通知渠道
|
||||
5. **响应（Respond）：** 值班人员收到通知并处理
|
||||
6. **关闭（Resolve）：** 问题解决后告警自动消失
|
||||
|
||||
**告警治理最佳实践：**
|
||||
- **SLO/SLA 驱动：** 告警应与业务关键指标绑定，而非基础设施细节
|
||||
- **分级告警：** Critical / Warning / Info 三级，避免所有告警同等紧急
|
||||
- **抑制规则：** 根因告警触发时自动抑制派生告警
|
||||
- **静默期：** 维护窗口内临时屏蔽告警
|
||||
- **On-call Rotation：** 值班轮换确保 24/7 有人响应
|
||||
|
||||
**告警评估黄金法则：** 每条告警必须有明确处理步骤；无法立即采取行动的告警应该被抑制或降低级别
|
||||
|
||||
---
|
||||
|
||||
## Prometheus 告警管理架构
|
||||
|
||||
```
|
||||
Prometheus (规则判断) → Alertmanager (抑制/分组/路由) → 通知渠道 (邮件/Slack/PagerDuty/电话)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]]
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
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 生态的规则定义方式
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
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]]：可观测性数据采集
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "Amazon Machine Image"
|
||||
type: concept
|
||||
tags: ["AWS", "Virtualization", "AMI", "Landing-Zone"]
|
||||
sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2", "ctp-topic-50-ami-roadmap-for-aws-amis", "ctp-topic-26-standard-ami-build-publish-share-processes"]
|
||||
last_updated: 2026-05-08
|
||||
---
|
||||
|
||||
## Definition
|
||||
Amazon Machine Image (AMI) 是 AWS 托管的虚拟机镜像模板，包含操作系统、应用程序和配置。在 Micro Focus AWS Landing Zone 中，标准 AMI 在 AWS 原生镜像基础上增加了企业级组件。
|
||||
|
||||
## Standard AMI Components
|
||||
标准 AMI 在 AWS 原生镜像基础上增加：
|
||||
- **OS 加固**：CIS 安全基准加固
|
||||
- **安全更新**：最新补丁和安全更新
|
||||
- **域名加入**：支持 AD 域集成
|
||||
- **安全工具**：McAfee EPO / Trellix / Sentinel-1 端点保护
|
||||
- **QALIS Agent**：企业端点保护
|
||||
- **SSM Agent**：AWS Systems Manager Agent
|
||||
- **DNS 设置**：企业 DNS 配置
|
||||
- **GP3 EBS 存储**：第三代通用型 SSD
|
||||
|
||||
## AMI Release Process
|
||||
1. **功能分支开发**：变更在功能分支上开发
|
||||
2. **集成分支合并**：合并到集成分支
|
||||
3. **Jenkins 构建**：Jenkins 多分支流水线构建和测试
|
||||
4. **安全扫描**：AWS Inspector 漏洞检测
|
||||
5. **跨区域复制**：AMI Copying 复制到不同区域
|
||||
6. **跨账号共享**：AMI Sharing 分发到多个组织和账户
|
||||
7. **加密共享**：自动创建必要的授权（grants）
|
||||
8. **完整测试套件**：验证无功能退化
|
||||
|
||||
## AMI Types in AWS Landing Zone
|
||||
- **Foundation AMI**（标准 AMI）：CCOE 提供的基线镜像
|
||||
- **Product AMI**：产品团队在 Foundation AMI 基础上定制
|
||||
|
||||
## Connections
|
||||
- [[AWS-Landing-Zone]] — AMI 是 LZ 标准化的核心基础设施
|
||||
- [[Jenkins-Multi-Branch-Pipeline]] — 驱动 AMI 构建和测试
|
||||
- [[AWS-Inspector]] — AMI 安全扫描集成
|
||||
- [[SSM-Patching]] — 长期运行实例的补丁管理
|
||||
- [[OS-End-of-Life]] — AMI EOL 管理
|
||||
@@ -1,39 +0,0 @@
|
||||
---
|
||||
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 触发机制对比
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
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]]
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
title: "Analytics Feedback Loop"
|
||||
type: concept
|
||||
tags: ["analytics", "data-driven", "iteration", "social-media", "carousel"]
|
||||
sources: ["marketing-carousel-growth-engine"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
数据驱动的自我优化闭环：发布内容 → 获取分析数据 → 提取洞察 → 积累学习 → 改进下一条内容。通过持续迭代使内容质量随时间指数级提升。
|
||||
|
||||
## 与 [[Feedback Loop]] 的区别
|
||||
|
||||
[[Feedback Loop]]（已存在）是**多 Agent 评审循环**——后续 Agent 审查前序 Agent 产出的迭代机制。本概念是**数据分析驱动的内容迭代**——通过真实用户数据（播放量/点赞/评论）持续改进内容策略。两者同属反馈循环，但应用于不同层面（AI 协作 vs 内容优化）。
|
||||
|
||||
## Cycle Structure
|
||||
|
||||
```
|
||||
[发布轮播] → [获取数据: views/likes/comments/shares]
|
||||
↓
|
||||
[learn-from-analytics.js 分析]
|
||||
↓
|
||||
[提取洞察: 最佳钩子/最佳时间/最佳风格]
|
||||
↓
|
||||
[写入 learnings.json（持续积累）]
|
||||
↓
|
||||
[读取 learnings.json 规划下一条]
|
||||
↓
|
||||
[改进后发布] → (循环)
|
||||
```
|
||||
|
||||
## 追踪指标
|
||||
|
||||
| 指标 | 来源 | 用途 |
|
||||
|------|------|------|
|
||||
| 播放量 (Views) | per-post analytics | 钩子效果评估 |
|
||||
| 点赞/评论/分享 | per-post analytics | 互动率分析 |
|
||||
| 曝光量 (Impressions) | daily breakdown | 发布时间优化 |
|
||||
| 粉丝变化 | profile analytics | 长期增长追踪 |
|
||||
|
||||
## 学习系统 (learnings.json)
|
||||
|
||||
- **Best Hooks**: 哪种钩子风格（问题/大胆声明/痛点）效果最好
|
||||
- **Optimal Times**: 最佳发布日/小时
|
||||
- **Winning Visual Styles**: 哪些视觉风格参与率最高
|
||||
- **Niche Insights**: 各业务细分的洞察积累
|
||||
- **Engagement Trends**: 随时间的参与率变化
|
||||
- **Platform Differences**: TikTok vs Instagram 表现差异
|
||||
- **容量**: 滚动 100 条历史用于趋势分析
|
||||
|
||||
## 自动调度优化
|
||||
|
||||
- 读取 `learnings.json` 中的 `bestTimes`
|
||||
- 调整 cron 执行时间为最佳发布时段
|
||||
- 下次轮播自动应用最佳钩子风格和视觉建议
|
||||
|
||||
## Usage in [[marketing-carousel-growth-engine]]
|
||||
|
||||
[[marketing-carousel-growth-engine]] 每天执行此循环，确保 carousel #30 显著优于 carousel #1。
|
||||
|
||||
## Aliases
|
||||
- Data-Driven Learning Loop
|
||||
- Performance Loop
|
||||
- Content Optimization Loop
|
||||
- 数据驱动反馈循环
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user