diff --git a/wiki/Charlie-Munger.md b/wiki/Charlie-Munger.md deleted file mode 100644 index cb206ea1..00000000 --- a/wiki/Charlie-Munger.md +++ /dev/null @@ -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 倾向预设框架） diff --git a/wiki/concepts/14种UML图.md b/wiki/concepts/14种UML图.md deleted file mode 100644 index c9b59419..00000000 --- a/wiki/concepts/14种UML图.md +++ /dev/null @@ -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种视觉风格系统]] diff --git a/wiki/concepts/2D-First-Spatial-Second.md b/wiki/concepts/2D-First-Spatial-Second.md deleted file mode 100644 index 674727bd..00000000 --- a/wiki/concepts/2D-First-Spatial-Second.md +++ /dev/null @@ -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]] ← 技术基础 diff --git a/wiki/concepts/3-2-1产品介绍公式.md b/wiki/concepts/3-2-1产品介绍公式.md deleted file mode 100644 index a9c63f1c..00000000 --- a/wiki/concepts/3-2-1产品介绍公式.md +++ /dev/null @@ -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]]：快手策略师的标准话术交付物 -- [[老铁经济]]：公式背后是信任驱动的销售逻辑 diff --git a/wiki/concepts/4-Level-Semantic-Zoom.md b/wiki/concepts/4-Level-Semantic-Zoom.md deleted file mode 100644 index 51fe27cd..00000000 --- a/wiki/concepts/4-Level-Semantic-Zoom.md +++ /dev/null @@ -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]] ← 落地产品 diff --git a/wiki/concepts/6-Slide-Narrative-Arc.md b/wiki/concepts/6-Slide-Narrative-Arc.md deleted file mode 100644 index df5741ed..00000000 --- a/wiki/concepts/6-Slide-Narrative-Arc.md +++ /dev/null @@ -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 diff --git a/wiki/concepts/7-Layer-Harness-Stack.md b/wiki/concepts/7-Layer-Harness-Stack.md deleted file mode 100644 index e6801f02..00000000 --- a/wiki/concepts/7-Layer-Harness-Stack.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/7种视觉风格系统.md b/wiki/concepts/7种视觉风格系统.md deleted file mode 100644 index 094fedca..00000000 --- a/wiki/concepts/7种视觉风格系统.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/ABM-Display.md b/wiki/concepts/ABM-Display.md deleted file mode 100644 index 40e1f56b..00000000 --- a/wiki/concepts/ABM-Display.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/ABTesting.md b/wiki/concepts/ABTesting.md deleted file mode 100644 index a2db9d4e..00000000 --- a/wiki/concepts/ABTesting.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/ACOS.md b/wiki/concepts/ACOS.md deleted file mode 100644 index 72919d84..00000000 --- a/wiki/concepts/ACOS.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/ADDIE-Model.md b/wiki/concepts/ADDIE-Model.md deleted file mode 100644 index 87154cf0..00000000 --- a/wiki/concepts/ADDIE-Model.md +++ /dev/null @@ -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 四级评估） diff --git a/wiki/concepts/ADM.md b/wiki/concepts/ADM.md deleted file mode 100644 index 5ccfec48..00000000 --- a/wiki/concepts/ADM.md +++ /dev/null @@ -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 diff --git a/wiki/concepts/AGENTS.md.md b/wiki/concepts/AGENTS.md.md deleted file mode 100644 index 2f714f64..00000000 --- a/wiki/concepts/AGENTS.md.md +++ /dev/null @@ -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 - -- 项目根目录：`/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 -- 项目角色定义文件 diff --git a/wiki/concepts/AI-Agent.md b/wiki/concepts/AI-Agent.md deleted file mode 100644 index 201baf7e..00000000 --- a/wiki/concepts/AI-Agent.md +++ /dev/null @@ -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-数据蒸馏]] diff --git a/wiki/concepts/AI-Assisted-Editing.md b/wiki/concepts/AI-Assisted-Editing.md deleted file mode 100644 index 0593ef5e..00000000 --- a/wiki/concepts/AI-Assisted-Editing.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AI-Auto-Response.md b/wiki/concepts/AI-Auto-Response.md deleted file mode 100644 index a9a0771c..00000000 --- a/wiki/concepts/AI-Auto-Response.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AI-ChatOps.md b/wiki/concepts/AI-ChatOps.md deleted file mode 100644 index 5f26b21a..00000000 --- a/wiki/concepts/AI-ChatOps.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AI-Driven-Task-Extraction.md b/wiki/concepts/AI-Driven-Task-Extraction.md deleted file mode 100644 index 02ed16a7..00000000 --- a/wiki/concepts/AI-Driven-Task-Extraction.md +++ /dev/null @@ -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]] — 从用户反馈中优化提取准确率 diff --git a/wiki/concepts/AI-For-On-Call.md b/wiki/concepts/AI-For-On-Call.md deleted file mode 100644 index 914af58a..00000000 --- a/wiki/concepts/AI-For-On-Call.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AI-Logo-Generation.md b/wiki/concepts/AI-Logo-Generation.md deleted file mode 100644 index 39fa26eb..00000000 --- a/wiki/concepts/AI-Logo-Generation.md +++ /dev/null @@ -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 标志设计 diff --git a/wiki/concepts/AIFinOps.md b/wiki/concepts/AIFinOps.md deleted file mode 100644 index aa5e1865..00000000 --- a/wiki/concepts/AIFinOps.md +++ /dev/null @@ -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]] — 异常成本流量触发熔断保护 diff --git a/wiki/concepts/AIOps.md b/wiki/concepts/AIOps.md deleted file mode 100644 index 223de08b..00000000 --- a/wiki/concepts/AIOps.md +++ /dev/null @@ -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 -] -``` diff --git a/wiki/concepts/AISummary.md b/wiki/concepts/AISummary.md deleted file mode 100644 index 0802995c..00000000 --- a/wiki/concepts/AISummary.md +++ /dev/null @@ -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时代发展策略]] 的信息处理层 -- 为知识管理提供高效的内容处理能力 diff --git a/wiki/concepts/AI代理.md b/wiki/concepts/AI代理.md deleted file mode 100644 index b60044d8..00000000 --- a/wiki/concepts/AI代理.md +++ /dev/null @@ -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初学者使用指南]] diff --git a/wiki/concepts/AI图生视频.md b/wiki/concepts/AI图生视频.md deleted file mode 100644 index 85bc0677..00000000 --- a/wiki/concepts/AI图生视频.md +++ /dev/null @@ -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团队推出，运动笔刷选择性动态化 diff --git a/wiki/concepts/AI幻觉.md b/wiki/concepts/AI幻觉.md deleted file mode 100644 index a746f69e..00000000 --- a/wiki/concepts/AI幻觉.md +++ /dev/null @@ -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 diff --git a/wiki/concepts/AI开源平替.md b/wiki/concepts/AI开源平替.md deleted file mode 100644 index 44606298..00000000 --- a/wiki/concepts/AI开源平替.md +++ /dev/null @@ -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-杀疯了]] diff --git a/wiki/concepts/AI文生视频.md b/wiki/concepts/AI文生视频.md deleted file mode 100644 index 595e6319..00000000 --- a/wiki/concepts/AI文生视频.md +++ /dev/null @@ -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图生视频]]：在静态图片基础上添加动态效果，与本文生视频互补 -- [[运镜控制]]：摄像机运动参数对视频效果的影响 diff --git a/wiki/concepts/AI簡報工作流.md b/wiki/concepts/AI簡報工作流.md deleted file mode 100644 index 74fe2552..00000000 --- a/wiki/concepts/AI簡報工作流.md +++ /dev/null @@ -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简报自动化工作流 -- 智能简报工作流 diff --git a/wiki/concepts/ALB-Ingress-Controller.md b/wiki/concepts/ALB-Ingress-Controller.md deleted file mode 100644 index 299d81a5..00000000 --- a/wiki/concepts/ALB-Ingress-Controller.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AMI-Sharing.md b/wiki/concepts/AMI-Sharing.md deleted file mode 100644 index 4cb6b5c3..00000000 --- a/wiki/concepts/AMI-Sharing.md +++ /dev/null @@ -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 — 跨账号共享的组织基础 diff --git a/wiki/concepts/API-Server-Priority-and-Fairness.md b/wiki/concepts/API-Server-Priority-and-Fairness.md deleted file mode 100644 index 877bef65..00000000 --- a/wiki/concepts/API-Server-Priority-and-Fairness.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/APT-仓库配置.md b/wiki/concepts/APT-仓库配置.md deleted file mode 100644 index 8772fee9..00000000 --- a/wiki/concepts/APT-仓库配置.md +++ /dev/null @@ -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 包管理器的宿主系统 diff --git a/wiki/concepts/ARM-AMI.md b/wiki/concepts/ARM-AMI.md deleted file mode 100644 index c006db0a..00000000 --- a/wiki/concepts/ARM-AMI.md +++ /dev/null @@ -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 diff --git a/wiki/concepts/AWS-Backup-Concepts.md b/wiki/concepts/AWS-Backup-Concepts.md deleted file mode 100644 index b80ea979..00000000 --- a/wiki/concepts/AWS-Backup-Concepts.md +++ /dev/null @@ -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 结合实现合规锁定 diff --git a/wiki/concepts/AWS-End-User-Computing.md b/wiki/concepts/AWS-End-User-Computing.md deleted file mode 100644 index c1cb1dbe..00000000 --- a/wiki/concepts/AWS-End-User-Computing.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AWS-Firewall-Manager.md b/wiki/concepts/AWS-Firewall-Manager.md deleted file mode 100644 index 15f624aa..00000000 --- a/wiki/concepts/AWS-Firewall-Manager.md +++ /dev/null @@ -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 diff --git a/wiki/concepts/AWS-Identity-Center.md b/wiki/concepts/AWS-Identity-Center.md deleted file mode 100644 index 7ecb5bd9..00000000 --- a/wiki/concepts/AWS-Identity-Center.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AWS-Inspector.md b/wiki/concepts/AWS-Inspector.md deleted file mode 100644 index 85417554..00000000 --- a/wiki/concepts/AWS-Inspector.md +++ /dev/null @@ -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 安全基础设施的组成部分 diff --git a/wiki/concepts/AWS-Instance-Scheduler.md b/wiki/concepts/AWS-Instance-Scheduler.md deleted file mode 100644 index 0b32d314..00000000 --- a/wiki/concepts/AWS-Instance-Scheduler.md +++ /dev/null @@ -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]] — 技术实施参考 diff --git a/wiki/concepts/AWS-Nitro.md b/wiki/concepts/AWS-Nitro.md deleted file mode 100644 index d8ef79d6..00000000 --- a/wiki/concepts/AWS-Nitro.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AWS-Secrets-Manager.md b/wiki/concepts/AWS-Secrets-Manager.md deleted file mode 100644 index c9c18e5a..00000000 --- a/wiki/concepts/AWS-Secrets-Manager.md +++ /dev/null @@ -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]] — 配合使用实现凭证的安全私有访问 diff --git a/wiki/concepts/AWS-Service-Catalog.md b/wiki/concepts/AWS-Service-Catalog.md deleted file mode 100644 index 752e1142..00000000 --- a/wiki/concepts/AWS-Service-Catalog.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AWS-Source-Identity.md b/wiki/concepts/AWS-Source-Identity.md deleted file mode 100644 index 1c6ca0a5..00000000 --- a/wiki/concepts/AWS-Source-Identity.md +++ /dev/null @@ -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 实现细节的记录。 diff --git a/wiki/concepts/AWS-Tagging-Standards.md b/wiki/concepts/AWS-Tagging-Standards.md deleted file mode 100644 index 235c6cdd..00000000 --- a/wiki/concepts/AWS-Tagging-Standards.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AWS-Tags.md b/wiki/concepts/AWS-Tags.md deleted file mode 100644 index 3d023898..00000000 --- a/wiki/concepts/AWS-Tags.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Access-Control.md b/wiki/concepts/Access-Control.md deleted file mode 100644 index 90342492..00000000 --- a/wiki/concepts/Access-Control.md +++ /dev/null @@ -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 库是标准安全实现 diff --git a/wiki/concepts/Account-Health-Score.md b/wiki/concepts/Account-Health-Score.md deleted file mode 100644 index d6be02a7..00000000 --- a/wiki/concepts/Account-Health-Score.md +++ /dev/null @@ -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 维护账户健康评分 diff --git a/wiki/concepts/Account-Monitoring.md b/wiki/concepts/Account-Monitoring.md deleted file mode 100644 index 4eed9476..00000000 --- a/wiki/concepts/Account-Monitoring.md +++ /dev/null @@ -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 获取账号动态） diff --git a/wiki/concepts/Account-Reconciliation.md b/wiki/concepts/Account-Reconciliation.md deleted file mode 100644 index 84ccaed6..00000000 --- a/wiki/concepts/Account-Reconciliation.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Account-Tiering-Model.md b/wiki/concepts/Account-Tiering-Model.md deleted file mode 100644 index 1dc75ba3..00000000 --- a/wiki/concepts/Account-Tiering-Model.md +++ /dev/null @@ -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]] — 不同层级对应不同序列深度 diff --git a/wiki/concepts/AccountArchitecture.md b/wiki/concepts/AccountArchitecture.md deleted file mode 100644 index 11ec2511..00000000 --- a/wiki/concepts/AccountArchitecture.md +++ /dev/null @@ -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 驱动架构 diff --git a/wiki/concepts/ActionItemTracking.md b/wiki/concepts/ActionItemTracking.md deleted file mode 100644 index 500e16ac..00000000 --- a/wiki/concepts/ActionItemTracking.md +++ /dev/null @@ -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]] — 行动项的自动化创建 diff --git a/wiki/concepts/Active-Accountability.md b/wiki/concepts/Active-Accountability.md deleted file mode 100644 index d0739537..00000000 --- a/wiki/concepts/Active-Accountability.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Active-Directory-Integration.md b/wiki/concepts/Active-Directory-Integration.md deleted file mode 100644 index b253bc92..00000000 --- a/wiki/concepts/Active-Directory-Integration.md +++ /dev/null @@ -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 账号登录 diff --git a/wiki/concepts/ActiveAccountability.md b/wiki/concepts/ActiveAccountability.md deleted file mode 100644 index e6ea4664..00000000 --- a/wiki/concepts/ActiveAccountability.md +++ /dev/null @@ -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]]：需要控制频率以避免适得其反 diff --git a/wiki/concepts/Actor-Replication.md b/wiki/concepts/Actor-Replication.md deleted file mode 100644 index 317c75bd..00000000 --- a/wiki/concepts/Actor-Replication.md +++ /dev/null @@ -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& 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 diff --git a/wiki/concepts/ActorReplication.md b/wiki/concepts/ActorReplication.md deleted file mode 100644 index 132ce101..00000000 --- a/wiki/concepts/ActorReplication.md +++ /dev/null @@ -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)]] — 基于复制的能力系统 diff --git a/wiki/concepts/AdExtensions.md b/wiki/concepts/AdExtensions.md deleted file mode 100644 index fcf89ed1..00000000 --- a/wiki/concepts/AdExtensions.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AdStrength.md b/wiki/concepts/AdStrength.md deleted file mode 100644 index 4a37f272..00000000 --- a/wiki/concepts/AdStrength.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Adaptive-Tone.md b/wiki/concepts/Adaptive-Tone.md deleted file mode 100644 index d860db80..00000000 --- a/wiki/concepts/Adaptive-Tone.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AdaptiveMusic.md b/wiki/concepts/AdaptiveMusic.md deleted file mode 100644 index b536ee93..00000000 --- a/wiki/concepts/AdaptiveMusic.md +++ /dev/null @@ -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 参数映射表、音乐集成五阶段流程 diff --git a/wiki/concepts/AdaptiveTone.md b/wiki/concepts/AdaptiveTone.md deleted file mode 100644 index 0cf2230d..00000000 --- a/wiki/concepts/AdaptiveTone.md +++ /dev/null @@ -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 提供数据依据 diff --git a/wiki/concepts/Advantage+-Campaigns.md b/wiki/concepts/Advantage+-Campaigns.md deleted file mode 100644 index b45a4a92..00000000 --- a/wiki/concepts/Advantage+-Campaigns.md +++ /dev/null @@ -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+ 倾向于减少人工结构干预 diff --git a/wiki/concepts/Adversarial-Debate-Pattern.md b/wiki/concepts/Adversarial-Debate-Pattern.md deleted file mode 100644 index 9bf440ee..00000000 --- a/wiki/concepts/Adversarial-Debate-Pattern.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Agent-Build-Gate.md b/wiki/concepts/Agent-Build-Gate.md deleted file mode 100644 index 270bd90f..00000000 --- a/wiki/concepts/Agent-Build-Gate.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Agent-Collaboration-Protocol.md b/wiki/concepts/Agent-Collaboration-Protocol.md deleted file mode 100644 index 728be8f2..00000000 --- a/wiki/concepts/Agent-Collaboration-Protocol.md +++ /dev/null @@ -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 diff --git a/wiki/concepts/Agent-Collapse.md b/wiki/concepts/Agent-Collapse.md deleted file mode 100644 index 25f89727..00000000 --- a/wiki/concepts/Agent-Collapse.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Agent-Design-Principles.md b/wiki/concepts/Agent-Design-Principles.md deleted file mode 100644 index 4fdbd624..00000000 --- a/wiki/concepts/Agent-Design-Principles.md +++ /dev/null @@ -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 diff --git a/wiki/concepts/Agent-Driven-Market-Research.md b/wiki/concepts/Agent-Driven-Market-Research.md deleted file mode 100644 index 9515c441..00000000 --- a/wiki/concepts/Agent-Driven-Market-Research.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Agent-Handoff.md b/wiki/concepts/Agent-Handoff.md deleted file mode 100644 index ca6bf132..00000000 --- a/wiki/concepts/Agent-Handoff.md +++ /dev/null @@ -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 交接机制 diff --git a/wiki/concepts/Agent-Memory.md b/wiki/concepts/Agent-Memory.md deleted file mode 100644 index 8c9466b2..00000000 --- a/wiki/concepts/Agent-Memory.md +++ /dev/null @@ -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 的框架 - diff --git a/wiki/concepts/Agent-Mode.md b/wiki/concepts/Agent-Mode.md deleted file mode 100644 index c9b74e45..00000000 --- a/wiki/concepts/Agent-Mode.md +++ /dev/null @@ -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中的集成与应用详解]] diff --git a/wiki/concepts/Agent-Orchestration.md b/wiki/concepts/Agent-Orchestration.md deleted file mode 100644 index 24f227ce..00000000 --- a/wiki/concepts/Agent-Orchestration.md +++ /dev/null @@ -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 的标准接口 diff --git a/wiki/concepts/Agent-Personality.md b/wiki/concepts/Agent-Personality.md deleted file mode 100644 index acab3b2d..00000000 --- a/wiki/concepts/Agent-Personality.md +++ /dev/null @@ -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 中的角色设计 - diff --git a/wiki/concepts/Agent-Routing-Rules.md b/wiki/concepts/Agent-Routing-Rules.md deleted file mode 100644 index 6f84053d..00000000 --- a/wiki/concepts/Agent-Routing-Rules.md +++ /dev/null @@ -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」错误排查-我以为是小问题-结果踩了大坑]] diff --git a/wiki/concepts/Agent-Specialization.md b/wiki/concepts/Agent-Specialization.md deleted file mode 100644 index bf73bcd1..00000000 --- a/wiki/concepts/Agent-Specialization.md +++ /dev/null @@ -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（另一种协作模式） - diff --git a/wiki/concepts/Agent-Template.md b/wiki/concepts/Agent-Template.md deleted file mode 100644 index 77ebcdb9..00000000 --- a/wiki/concepts/Agent-Template.md +++ /dev/null @@ -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 diff --git a/wiki/concepts/Agent.md b/wiki/concepts/Agent.md deleted file mode 100644 index e38626d6..00000000 --- a/wiki/concepts/Agent.md +++ /dev/null @@ -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-数据蒸馏]] diff --git a/wiki/concepts/AgentFileFormat.md b/wiki/concepts/AgentFileFormat.md deleted file mode 100644 index 25e7f4b3..00000000 --- a/wiki/concepts/AgentFileFormat.md +++ /dev/null @@ -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 diff --git a/wiki/concepts/AgentIntegration.md b/wiki/concepts/AgentIntegration.md deleted file mode 100644 index 562d9835..00000000 --- a/wiki/concepts/AgentIntegration.md +++ /dev/null @@ -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`） diff --git a/wiki/concepts/AgentScopes.md b/wiki/concepts/AgentScopes.md deleted file mode 100644 index bebaa854..00000000 --- a/wiki/concepts/AgentScopes.md +++ /dev/null @@ -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 ` -- 代表工具：Claude Code、GitHub Copilot、Antigravity、Gemini CLI、OpenClaw、Kimi Code - -## Project-Scoped Agent（项目级 Agent） -- 安装位置：项目根目录（如 `./.opencode/agents/`、`./.windsurfrules`） -- 生效范围：仅当前项目可用 -- 安装方式：从项目根目录运行 `./scripts/install.sh --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`） diff --git a/wiki/concepts/AgentWorkspace.md b/wiki/concepts/AgentWorkspace.md deleted file mode 100644 index 1a8691ff..00000000 --- a/wiki/concepts/AgentWorkspace.md +++ /dev/null @@ -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`） diff --git a/wiki/concepts/Agentic-AI.md b/wiki/concepts/Agentic-AI.md deleted file mode 100644 index 09f02496..00000000 --- a/wiki/concepts/Agentic-AI.md +++ /dev/null @@ -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） diff --git a/wiki/concepts/AgenticSystem.md b/wiki/concepts/AgenticSystem.md deleted file mode 100644 index 8785ceae..00000000 --- a/wiki/concepts/AgenticSystem.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AgenticWorkflow.md b/wiki/concepts/AgenticWorkflow.md deleted file mode 100644 index a40aa175..00000000 --- a/wiki/concepts/AgenticWorkflow.md +++ /dev/null @@ -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]]：通宵运行的自主应用构建 diff --git a/wiki/concepts/Agile-Ceremonies.md b/wiki/concepts/Agile-Ceremonies.md deleted file mode 100644 index 28940821..00000000 --- a/wiki/concepts/Agile-Ceremonies.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AgilePractices.md b/wiki/concepts/AgilePractices.md deleted file mode 100644 index b723c8c5..00000000 --- a/wiki/concepts/AgilePractices.md +++ /dev/null @@ -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) diff --git a/wiki/concepts/Aha-Moment.md b/wiki/concepts/Aha-Moment.md deleted file mode 100644 index fa7499d7..00000000 --- a/wiki/concepts/Aha-Moment.md +++ /dev/null @@ -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 -- 无已知冲突 diff --git a/wiki/concepts/Ai-Powered-Digest.md b/wiki/concepts/Ai-Powered-Digest.md deleted file mode 100644 index ef9f16c5..00000000 --- a/wiki/concepts/Ai-Powered-Digest.md +++ /dev/null @@ -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 模式的金融场景应用 diff --git a/wiki/concepts/AirGappedSLMFixGeneration.md b/wiki/concepts/AirGappedSLMFixGeneration.md deleted file mode 100644 index a7d0727c..00000000 --- a/wiki/concepts/AirGappedSLMFixGeneration.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/AlertManagement.md b/wiki/concepts/AlertManagement.md deleted file mode 100644 index bdef4f64..00000000 --- a/wiki/concepts/AlertManagement.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Alerting.md b/wiki/concepts/Alerting.md deleted file mode 100644 index 676d3971..00000000 --- a/wiki/concepts/Alerting.md +++ /dev/null @@ -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 生态的规则定义方式 diff --git a/wiki/concepts/Algorithm-Agility.md b/wiki/concepts/Algorithm-Agility.md deleted file mode 100644 index 7f778ba5..00000000 --- a/wiki/concepts/Algorithm-Agility.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Amazon-EKS.md b/wiki/concepts/Amazon-EKS.md deleted file mode 100644 index 69bfd3c9..00000000 --- a/wiki/concepts/Amazon-EKS.md +++ /dev/null @@ -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]]：可观测性数据采集 diff --git a/wiki/concepts/Amazon-Machine-Image.md b/wiki/concepts/Amazon-Machine-Image.md deleted file mode 100644 index 7de83d3a..00000000 --- a/wiki/concepts/Amazon-Machine-Image.md +++ /dev/null @@ -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 管理 diff --git a/wiki/concepts/AmbientMessageMonitoring.md b/wiki/concepts/AmbientMessageMonitoring.md deleted file mode 100644 index d32e6017..00000000 --- a/wiki/concepts/AmbientMessageMonitoring.md +++ /dev/null @@ -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 触发机制对比 diff --git a/wiki/concepts/Analogy-as-Straitjacket.md b/wiki/concepts/Analogy-as-Straitjacket.md deleted file mode 100644 index 3dc7aec6..00000000 --- a/wiki/concepts/Analogy-as-Straitjacket.md +++ /dev/null @@ -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]] diff --git a/wiki/concepts/Analytics-Feedback-Loop.md b/wiki/concepts/Analytics-Feedback-Loop.md deleted file mode 100644 index 362e459d..00000000 --- a/wiki/concepts/Analytics-Feedback-Loop.md +++ /dev/null @@ -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 -- 数据驱动反馈循环 diff --git a/wiki/concepts/Annales-School.md b/wiki/concepts/Annales-School.md deleted file mode 100644 index bad6abb5..00000000 --- a/wiki/concepts/Annales-School.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Annales School" -type: concept -tags: ["historiography", "french-history", "material-culture", "longue-duree"] -sources: ["academic-historian"] -last_updated: 2026-04-25 ---- - -## Definition -法国史学流派，以《年鉴》（*Annales d'histoire économique et sociale*，1929年创刊）为核心阵地，由马克·布洛赫（Marc Bloch）和吕西安·费弗尔（Lucien Febvre）共同创立。主张历史研究应突破传统政治军事史的局限，关注普通人的日常生活、物质条件和长期社会结构。 - -## Core Principles -- **物质条件优先**：在讨论政治/军事/思想之前，必须先理解经济基础、农业、贸易和技术 -- **长时段视角（Longue Durée）**：历史变化发生在几十年乃至几个世纪的时间尺度上，聚焦于塑造事件发生的深层结构 -- **日常生活史（*Histoire du quotidien*）**：关注饮食、服饰、建筑、信仰、恐惧——Annales 学派不只写国王和战争 -- **跨学科方法**：整合地理学、经济学、社会学、人类学、人口学的方法论 -- **问题导向史学**：以问题而非编年驱动历史研究 - -## Key Figures -- **马克·布洛赫**（Marc Bloch，1886-1944）：年鉴学派创始人之一，《封建社会》作者，二战期间参加抵抗运动后被枪决 -- **吕西安·费弗尔**（Lucien Febvre，1878-1956）：年鉴学派创始人之一，专注于16世纪精神状态史 -- **费尔南·布罗代尔**（Fernand Braudel，1902-1985）：年鉴学派第二代领袖，《菲利普二世时代的地中海和地中海世界》——长时段理论的奠基之作，将历史分为三个时间层次：地理时间（长时段）、社会时间（中时段）、事件时间（短时段） -- **埃马纽埃尔·勒华拉杜里**（Emmanuel Le Roy Ladurie，*Montaillou* 作者）：微观史的代表人物 - -## Relationship to Historiography -- **反对**：兰克学派（Rankean）聚焦政治史和伟大人物的传统史学；辉格史观（Whig History）以现代标准评判历史 -- **影响**：新文化史、微观史、历史社会学、后殖民史学均受其影响 -- **对话/张力**：年鉴学派有时因过度关注结构而被批评忽视个体能动性（agency），微观史（Microhistory）部分是对此的回应 - -- [[Microhistory]] ← 方法论回应 ← [[Annales-School]]：微观史是对年鉴学派过度结构决定论批评的回应之一 -- [[Material-Culture]] ← 核心关注 ← [[Annales-School]]：物质文化是年鉴学派历史分析的第一层 - -## Connections -- [[Geographic-Coherence]] ← 理论关联 ← [[Annales-School]]：两者都强调物质地理条件对人类历史的约束作用 -- [[academic-historian]] ← 方法论来源 ← [[Annales-School]]：Historian Agent 优先使用年鉴学派方法 -- [[Longue-Duree]] ← 核心概念 ← [[Annales-School]]：长时段分析是年鉴学派最重要的方法论贡献 -- [[Microhistory]] ← 方法论互补 ← [[Annales-School]]：微观史是对年鉴学派的结构决定论倾向的回应 - -## Aliases -- 年鉴学派 -- Annales -- Annales d'histoire économique et sociale -- Annales School of historiography -- French historical school diff --git a/wiki/concepts/Answer-Engine-Optimization.md b/wiki/concepts/Answer-Engine-Optimization.md deleted file mode 100644 index c1a27bdf..00000000 --- a/wiki/concepts/Answer-Engine-Optimization.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Answer Engine Optimization" -type: concept -tags: ["SEO", "AI", "marketing", "AEO"] -sources: ["marketing-ai-citation-strategist"] -last_updated: 2026-04-30 ---- - -## Definition - -Answer Engine Optimization（AEO，答案引擎优化）：一种专注于让内容在 AI 推荐引擎（如 ChatGPT、Claude、Gemini、Perplexity）中被直接引用推荐的营销技术。与传统 SEO 不同，AEO 优化的不是页面排名，而是内容被 AI 合成答案选为来源的可能性。 - -## Core Principles - -1. **AI 引用 ≠ SEO 排名**：SEO 信号（关键词密度、反向链接、页面速度）与 AEO 信号（实体清晰度、结构化权威、FAQ 对齐、Schema 标记）完全不同 -2. **引用是概率性的**：AI 响应具有非确定性，只能"提升引用概率"而非"保证被引用" -3. **多平台差异化**：每个 AI 引擎有不同内容偏好和引用行为，必须针对平台定制 - -## Key Signals - -| 信号类型 | 说明 | 适用平台 | -|---------|------|---------| -| Entity Clarity | 品牌/产品在知识图谱中清晰可识别 | 所有平台 | -| Structured Authority | FAQ、对比表、how-to指南等结构化内容 | ChatGPT/Gemini | -| FAQ Alignment | Q&A 内容匹配用户实际输入 AI 的查询模式 | ChatGPT | -| Schema Markup | Organization/Product/FAQ 结构化数据 | Gemini/Perplexity | -| Source Diversity | 多样化的权威来源引用 | Perplexity | -| Recency | 时效性内容 | Perplexity | - -## Related Concepts - -- [[Generative Engine Optimization]]（GEO）— AEO 的扩展，涵盖更广泛的 AI 生成内容可见性 -- [[Schema Markup]] — AEO 的关键技术手段之一 -- [[Citation Audit Scorecard]] — AEO 效果的可量化评估工具 - -## Relationships - -- 互补于 → [[marketing-seo-specialist]] -- 扩展为 → [[marketing-ai-citation-strategist]] diff --git a/wiki/concepts/AntiCheatArchitecture.md b/wiki/concepts/AntiCheatArchitecture.md deleted file mode 100644 index c88f7f3d..00000000 --- a/wiki/concepts/AntiCheatArchitecture.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Anti-Cheat Architecture" -type: concept -tags: [networking, security, multiplayer] -sources: [unity-multiplayer-engineer] -last_updated: 2026-04-26 ---- - -## Aliases -- Server-Side Validation -- Anti-Cheat -- 服务器端验证 - -## Definition -反作弊架构是一套在服务器权威模型下**验证所有客户端输入**的设计原则和实现方案。由于客户端不可信，所有游戏关键操作必须在服务器端进行验证，拒绝非法请求并记录可疑行为。 - -## Core Principles -1. **永远不要信任客户端数据**：客户端发送的任何值都需要验证 -2. **服务器拥有最终裁判权**：位置、生命值、分数等由服务器计算 -3. **输入验证**：检查输入是否在物理上可行 -4. **速率限制**：检测并断开超出人类可能速度的 RPC 调用 - -## Unity (NGO) Implementation -```csharp -[ServerRpc] -private void SendInputServerRpc(Vector2 input, int tick) -{ - // 服务器端验证：物理上是否可能？ - float maxDistancePossible = _moveSpeed * Time.fixedDeltaTime * 2f; - if (Vector3.Distance(_serverPosition.Value, newPosition) > maxDistancePossible) - { - // 拒绝：瞬移检测或严重同步错误 - _serverPosition.Value = _serverPosition.Value; // 强制调和 - return; - } - _serverPosition.Value = newPosition; -} -``` - -## Key Techniques -- **移动验证**：速度上限检测、瞬移检测 -- **命中检测**：服务器端验证目标位置和碰撞 -- **审计日志**：记录所有游戏影响 RPC 的时间戳、玩家ID、动作类型 -- **速率限制**：每玩家每 RPC 类型的调用频率限制 - -## Related Concepts -- [[ServerAuthority]]: 反作弊的基础 -- [[UnityLobby]]: Lobby 数据不应包含游戏状态 -- [[BandwidthManagement]]: 带宽控制也是反作弊的一部分 - -## Related Entities -- [[UnityMultiplayerEngineer]]: 实现反作弊架构的专家 diff --git a/wiki/concepts/Appearance-Anxiety.md b/wiki/concepts/Appearance-Anxiety.md deleted file mode 100644 index edb94a13..00000000 --- a/wiki/concepts/Appearance-Anxiety.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Appearance Anxiety（容貌焦虑）" -type: concept -tags: [healthcare, compliance, medical-aesthetics, china] -sources: [healthcare-marketing-compliance] -last_updated: 2026-04-25 ---- - -## Definition -"容貌焦虑"（容貌焦虑情绪/appearance anxiety）是医美广告中通过暗示不进行医美将导致负面后果，从而诱导消费者接受医美服务的营销手法。2021年起，国家市场监督管理总局（SAMR）在《医疗美容广告执法指南》中明确将制造"容貌焦虑"列为医美广告红线。 - -## Legal Prohibition -> "医美广告不得制造'容貌焦虑'——2021年起市场监管总局执法力度显著加强。" — SAMR《医疗美容广告执法指南》 - -## Prohibited Expressions -医美广告中禁止使用以下暗示负面后果的表述： -- "丑陋""不美丽""影响社交" -- "影响就业""影响感情" -- 任何暗示不进行医美将导致负面影响的表述 - -## Compliant Alternatives -| 违规表述 | 合规替代 | -|----------|----------| -| "现在不做，以后会后悔" | 介绍医美项目原理和技术特点 | -| "你的脸型需要改变" | 展示医师资质和机构合规证书 | -| "变美是女性的权利" | 介绍适合人群和技术安全性 | -| "再不整就晚了" | 提供科学医美知识教育 | - -## Enforcement Context -2021年《医疗美容广告执法指南》发布后，市场监管部门对医美广告实施专项整治，重点打击： -- 制造容貌焦虑的广告内容 -- 使用患者前后对比照片 -- 虚假夸大医美效果 -- 违规医美直播带货 - -## Related Concepts -- [[Healthcare-Marketing-Compliance]]：容貌焦虑是医美合规的核心红线 -- [[SAMR]]：《医疗美容广告执法指南》的发布机构 -- [[Xiaohongshu]]：小红书大规模清理医美日记类内容的重要背景 -- [[Compliance-Risk-Matrix]]：制造容貌焦虑属 High Risk 级别，面临罚款+账号封禁 diff --git a/wiki/concepts/Architectural-Empathy.md b/wiki/concepts/Architectural-Empathy.md deleted file mode 100644 index e65f8514..00000000 --- a/wiki/concepts/Architectural-Empathy.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Architectural Empathy" -type: concept -tags: [ux-design, cultural-intelligence, design-philosophy] -sources: [specialized-cultural-intelligence-strategist] -last_updated: 2026-05-29 ---- - -## Definition -通过结构性解决方案而非表演性行为来实现包容性的设计哲学——在系统架构层面消除排斥根源，而非在产品表面添加"看起来包容"的元素。Architectural Empathy Engine 是 [[Cultural-Intelligence-Strategist]] 的角色定位，强调同理心必须融入产品的骨架，而非仅装饰于表面。 - -## Core Principles - -### 1. Structural > Cosmetic -- ❌ 在首页添加一张多元人群图 -- ✅ 重新设计表单字段以接受全球命名结构 - -### 2. Precondition, Not Afterthought -- ❌ 产品上线后再考虑国际化 -- ✅ 国际化是架构设计的前提条件（Global-First Architecture） - -### 3. "Who is left out?" as First Question -每个工作流审查的第一个问题必须是："如果用户是神经多样性者、视障者、非西方文化背景者、或使用不同历法，这个设计还能工作吗？" - -### 4. Absolute Cultural Humility -永远不声称当前知识是完整的。在为任何群体生成内容前，必须自主研究该群体的当前、尊重、赋权的表征标准。 - -## Relationship to Other Concepts -- [[Invisible-Exclusion]]：Architectural Empathy 的诊断对象 -- [[Global-First-Architecture]]：Architectural Empathy 的实施方法 -- [[Cultural-Intelligence]]：Architectural Empathy 的知识基础 - -## Aliases -- Structural Empathy（结构性同理心） -- Architectural Empathy -| 维度 | 表演性同理心 | 结构性同理心 | -|------|------------|------------| -| 位置 | 表面层 | 架构层 | -| 效果 | 短期感知改善 | 长期用户摩擦消除 | -| 检测方式 | 多元图片存在 | APAC 用户转化率提升 | -| 维护 | 每次更新需重新添加 | 架构内建，持续有效 | diff --git a/wiki/concepts/Architecture-Roadmap.md b/wiki/concepts/Architecture-Roadmap.md deleted file mode 100644 index 036f0442..00000000 --- a/wiki/concepts/Architecture-Roadmap.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Architecture Roadmap" -type: concept -tags: [Architecture, Planning, Governance, Cloud-Transformation] -sources: ["ctp-topic-23-introduction-to-the-technical-architecture-team-and-function"] -last_updated: 2026-05-11 ---- - -## Definition -Architecture Roadmap（技术架构路线图）是技术架构团队制定的 12-24 个月前瞻性技术规划，通过将技术栈划分为不同的"技术领域（Technical Domains）"并由首席架构师负责，实现从"救火式"被动响应到预测性主动规划的转变。 - -## Core Purpose -- **风险规避**：帮助业务部门预见技术风险，提前规划应对措施 -- **预算优化**：通过前瞻性规划，避免临时采购和紧急开支 -- **交付加速**：减少技术债务积累，提升交付速度 -- **价值聚焦**：将业务部门从繁杂的基础设施维护中解放出来，专注于为客户创造价值 - -## Planning Horizon -- **12-24 个月**：短期至中期前瞻规划窗口 -- 覆盖身份认证、网络、Microsoft 堆栈等各技术领域 -- 每条路线图由对应技术领域的首席架构师负责 - -## Relationship to Other Concepts -- [[EA-SA-TA-Framework]] — 路线图由 TA 层制定，EA 层审核战略一致性 -- [[Technical-Architecture-Domains]] — 路线图按技术领域划分，每个领域独立规划 -- [[Cloud-First-Policy]] — 路线图遵循 Cloud-First 策略，除非有充分理由保留本地 - -## Connections -- [[Martin-Nash]] — 路线图规划的主要推动者 -- [[Cloud-Transformation-Programme]] — 路线图服务于云转型整体战略 diff --git a/wiki/concepts/ArchitectureDecisionRecord.md b/wiki/concepts/ArchitectureDecisionRecord.md deleted file mode 100644 index 1e5789e8..00000000 --- a/wiki/concepts/ArchitectureDecisionRecord.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Architecture Decision Record" -type: concept -tags: [] -last_updated: 2026-05-01 ---- - -## Definition -Architecture Decision Record（架构决策记录）是一种轻量级文档，用于捕获架构决策的上下文、选项和理由。ADR 记录的是"为什么这样做"，而不仅仅是"做了什么"。 - -## ADR Format - -```markdown -# ADR-001: [Decision Title] - -## Status -Proposed | Accepted | Deprecated | Superseded by ADR-XXX - -## Context -What is the issue that we're seeing that is motivating this decision? - -## Decision -What is the change that we're proposing and/or doing? - -## Consequences -What becomes easier or harder because of this change? -``` - -## Key Elements -- **Status**：Proposed（提议中）/ Accepted（已接受）/ Deprecated（已废弃）/ Superseded（被替代） -- **Context**：驱动决策的问题或背景 -- **Decision**：具体的决策内容 -- **Consequences**：决策的后果——什么变得更容易，什么变得更难 - -## Core Principles -- **记录 WHY，而非 WHAT**：代码已经说明了"做了什么"，ADR 应该说明"为什么这样做" -- **可追溯性**：随着系统演进，ADR 提供了决策的历史脉络 -- **知识共享**：新成员可以通过 ADR 理解架构决策的背景 - -## Related Concepts -- [[SoftwareArchitect]]：ADR 是 Software Architect Agent 的核心工具之一 -- [[DomainDrivenDesign]]：ADR 常用于记录领域模型的边界决策 - -## Sources -- [[engineering-software-architect]] - -## Aliases -- ADR -- Architecture Decision Record -- 架构决策记录 diff --git a/wiki/concepts/Artifact-Repo.md b/wiki/concepts/Artifact-Repo.md deleted file mode 100644 index 5766de5a..00000000 --- a/wiki/concepts/Artifact-Repo.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Artifact Repo（制品仓库）" -type: concept -tags: [Artifact-Repo, DevOps, CI/CD, OpenText, Thor, Artifactory] -sources: - - public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806 -last_updated: 2026-05-11 ---- - -## Artifact Repo（制品仓库） - -Artifact Repo 是存储 CI/CD 流水线产出的二进制文件（如 JAR、Docker 镜像、安装包等）的仓库。在 OpenText 环境中，制品仓库通过 Artifactory 管理，并在 Product Hub（PHT）中映射权限。 - -## 与 Source Repo 的区别 - -| 维度 | Source Repo | Artifact Repo | -|------|------------|----------------| -| 存储内容 | 源代码 | 构建产物（二进制文件） | -| 工具 | GitLab | Artifactory | -| 权限管理 | PHT 中映射 Source Repo 权限 | PHT 中管理 Artifact Repo 权限 | -| 新结构默认启用 | 否（需手动映射） | 是（自动启用）| - -## 在 Product Hub 中的管理 - -- Product 可以在 PHT 中映射 Artifact Repo -- Artifact Repo 权限为新结构默认启用 -- 与 Product Hierarchy 关联：每个 Product 可以关联多个 Source Repo 和 Artifact Repo - -## 与 CI/CD Pipeline 的关系 - -[[CI/CD Pipeline]] 的产出（构建产物）存储于 Artifact Repo： - -``` -代码提交 → GitLab (Source Repo) - ↓ - CI/CD Pipeline 执行 - ↓ - 构建产物生成 - ↓ - Artifactory (Artifact Repo) - ↓ - 部署到客户环境 -``` - -## 与 Product Hub 的集成 - -[[Product Hub (PhD)]] 管理 Artifact Repo 的： -- 权限配置 -- 与产品的关联关系 -- 跨团队访问控制 - -## Connections - -- [[Artifact-Repo]] ← managed_by ← [[Product Hub (PhD)]] -- [[Artifact-Repo]] ← stores ← CI/CD Pipeline 输出 -- [[Artifact-Repo]] ← provided_by ← Artifactory -- [[Artifact-Repo]] ← associated_with ← Product Hierarchy - -## Sources - -- [[public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806]] diff --git a/wiki/concepts/Asset-Management.md b/wiki/concepts/Asset-Management.md deleted file mode 100644 index 9236a28f..00000000 --- a/wiki/concepts/Asset-Management.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: "Asset Management" -type: concept -tags: [itsm, operations, finops] -date: 2025-03-01 ---- - -## Definition - -资产管理（Asset Management）是[[ITSM]]的核心流程之一，负责**跟踪和管理IT资产从采购到退役的完整生命周期**，优化资产利用率、控制成本并确保合规。 - -## Asset Lifecycle - -``` -┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ -│ Procure │ → │ Deploy │ → │Operate │ → │Maintain │ → │ Retire │ -└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ - ↓ ↓ ↓ ↓ ↓ - Purchase Provision Monitor Patch/Update Archive/ - Planning & Config & Optimize & Upgrade Dispose -``` - -## Asset Management Focus Areas - -| 领域 | 描述 | -|------|------| -| Hardware Lifecycle | 服务器、网络设备生命周期 | -| Software Licensing | 软件许可管理（SAM） | -| Cloud Optimization | 云资源成本优化 | -| Shadow IT Prevention | 影子IT发现与治理 | -| Compliance | 许可证合规审计 | - -## Modern Asset Management (ITSM 2.0) - -在[[ITSM 2.0]]中，资产管理由AI驱动： - -### Intelligent Features - -| 能力 | 描述 | 价值 | -|------|------|------| -| Automated Lifecycle Tracking | 自动追踪资产状态 | 减少人工 | -| License Optimization | 许可证使用分析 | 成本节省 | -| Usage Analytics | 利用率分析 | Rightsizing | -| Cost Forecasting | 成本预测 | 预算规划 | -| Cloud Resource Optimization | 云资源优化 | FinOps | - -### Cloud-Optimized SAM (Software Asset Management) - -``` -Software License Usage -├── Used Licenses: 80% -├── Unused Licenses: 15% -└── Over-licensed: 5% - ↓ - AI Analysis - ├── Reclaim unused - ├── Optimize purchases - └── Prevent overruns -``` - -## Key Metrics - -| 指标 | 描述 | -|------|------| -| Asset Utilization Rate | 资产利用率 | -| License Compliance | 许可证合规率 | -| Shadow IT Count | 影子IT数量 | -| Cost per Asset | 单资产成本 | - -## Related Concepts - -- [[ITSM]] — 父框架 -- [[FinOps]] — 云财务管理 -- [[Rightsizing]] — 资源优化 -- [[Cloud-Optimization]] — 云优化 - -## Sources - -- [[understanding-complete-itsm]] — Intelligent Asset Lifecycle Tracking diff --git a/wiki/concepts/Asset-Pipeline.md b/wiki/concepts/Asset-Pipeline.md deleted file mode 100644 index dfebe13e..00000000 --- a/wiki/concepts/Asset-Pipeline.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Asset Pipeline" -type: concept -tags: [game-dev, asset-pipeline, standards, production] -sources: [technical-artist] -last_updated: 2026-04-26 ---- - -# Asset Pipeline - -## Definition -Asset Pipeline（资产管线）是定义和管理游戏资产从 DCC 创作到引擎交付全流程的标准体系。涵盖多边形数预算、纹理分辨率规范、LOD 链要求、命名约定和导入预设自动化。 - -## Core Standards - -### Texture Compression（纹理压缩标准） -| 类型 | PC | Mobile | Console | -|------|----|--------|---------| -| Albedo | BC7 | ASTC 6×6 | BC7 | -| Normal Map | BC5 | ASTC 6×6 | BC5 | -| Roughness/AO | BC4 | ASTC 8×8 | BC4 | -| UI Sprites | BC7 | ASTC 4×4 | BC7 | - -### Texture Import Rules -- 始终以源分辨率导入纹理，由平台特定覆盖系统进行缩放——禁止以降低分辨率导入 -- UI 和小型环境细节使用纹理图集——独立小纹理是 Draw Call 预算杀手 -- Mipmap 规则按纹理类型指定： - - UI：关闭 - - 世界纹理：开启 - - 法线贴图：开启（正确设置） - -### Asset Handoff Protocol -- 艺术家在建模前收到每种资产类型的技术规格说明书 -- 每项资产在目标光照环境下引擎内审查后才批准——不接受 DCC 预览中的审批 -- 破损 UV、不正确轴心点、非流形几何体在导入时拦截，不在交付时修复 - -## Related Concepts -- [[LOD-Pipeline]]：LOD 是资产管线标准的关键组成部分 -- [[Performance-Budget]]：资产管线标准服务于性能预算 -- [[TextureCompression]]：纹理压缩是资产管线的重要子规范 - -## Connections -- [[TechnicalArtist]] ← defines ← Asset Pipeline -- [[LOD-Pipeline]] ← part of ← Asset Pipeline -- [[Performance-Budget]] ← enabled by ← Asset Pipeline diff --git a/wiki/concepts/Assume-Role.md b/wiki/concepts/Assume-Role.md deleted file mode 100644 index 099c46cd..00000000 --- a/wiki/concepts/Assume-Role.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: "Assume Role" -type: concept -tags: [AWS, IAM, Security, Cross-Account, Authentication] -sources: - - ctp-topic-16-cross-account-terraform-modules.md - - ctp-topic-5-aws-identity-and-access-management-iam.md -last_updated: 2026-05-15 ---- - -## Overview - -Assume Role 是 AWS IAM 的一种安全机制，允许一个 AWS 实体（用户、服务或角色）通过调用 `sts:AssumeRole` API 获取另一个 IAM 角色的临时安全凭证，从而在不同的安全上下文中执行操作。这是 AWS 跨账号访问的核心机制。 - -## How It Works - -```python -# 1. 源实体（如 ECS Deploy Runner）调用 STS AssumeRole -response = sts.assume_role( - RoleArn="arn:aws:iam::TARGET_ACCOUNT:role/Cross-account-ECS-Deploy-Runner-Role", - RoleSessionName="ecs-deploy-runner-session" -) - -# 2. 获取临时凭证 -temp_access_key = response['Credentials']['AccessKeyId'] -temp_secret_key = response['Credentials']['SecretAccessKey'] -temp_token = response['Credentials']['SessionToken'] - -# 3. 使用临时凭证访问目标账号资源 -ec2_client = boto3.client('ec2', - aws_access_key_id=temp_access_key, - aws_secret_access_key=temp_secret_key, - aws_session_token=temp_token -) -``` - -## Key Properties - -- **临时凭证**：有效期通常为 1-12 小时，过期后无法使用 -- **最小权限**：仅获取所 Assume 角色的权限 -- **审计可追溯**：所有 Assume 操作都会记录在 CloudTrail 中 -- **无持久凭证泄露**：无需存储长期 Access Key - -## Use Cases - -| 场景 | 说明 | -|------|------| -| 跨账号部署 | Shared Account 的 EDR Assume 目标账号的角色执行 Terraform | -| 跨账号数据访问 | 账户 A 访问账户 B 的 S3 资源 | -| 服务间授权 | Lambda 函数 Assume 特定角色访问其他服务 | -| 联邦访问 | 跨账户的 IAM Role 信任关系 | - -## Relationship with Cross-Account Terraform - -在 [[Cross-account-Terraform-Modules]] 方案中： - -``` -[[Shared-Account]] (EDR) - ↓ sts:AssumeRole -[[TF-State-Bucket-Accessor]] (目标账号) → 读写 Terraform 状态文件 - ↓ -[[Cross-account-ECS-Deploy-Runner-Role]] (目标账号) → 执行资源部署 -``` - -## Relationships - -- [[Shared-Account]] ← uses ← [[Assume-Role]] -- [[ECS-Deploy-Runner]] ← uses ← [[Assume-Role]] -- [[Blast-Radius]] ← enables ← [[Assume-Role]] -- [[Cross-account-Terraform-Modules]] ← mechanism ← [[Assume-Role]] - -## Related Concepts - -- [[IAM-Policy]]：Assume Role 的权限边界由 IAM Policy 定义 -- [[Blast-Radius]]：Assume Role 是控制爆炸半径的关键工具 -- [[Cross-account-Terraform-Modules]]：Assume Role 是跨账号 Terraform 方案的核心技术 diff --git a/wiki/concepts/Atomic-Commit.md b/wiki/concepts/Atomic-Commit.md deleted file mode 100644 index 266d51ab..00000000 --- a/wiki/concepts/Atomic-Commit.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Atomic Commit" -type: concept -tags: ["git", "code-quality", "delivery-traceability"] -last_updated: 2026-04-25 ---- - -## Definition - -Atomic Commit（原子提交）是一种 Git 提交粒度原则——每次提交仅包含一个逻辑变更单元（一个清晰的改动），易于审查、回滚和溯源，不捆绑多个不相关的变更。 - -## Characteristics - -- **单一职责**：一个 commit = 一个清晰的改动 -- **可独立回滚**：回滚一个 commit 不会影响其他功能的正常运行 -- **可独立审查**：reviewer 能在短时间内理解单个 commit 的意图 -- **易于溯源**：通过 commit message 快速定位引入特定行为的 ticket - -## Anti-patterns - -| 反模式 | 描述 | 风险 | -|--------|------|------| -| Mega commit | 一次性提交大量不相关变更 | review 成本高；回滚连带损伤 | -| WIP commit | 包含 work-in-progress 代码的提交 | 污染历史，难以理解 | -| Fixup commit | 在 review 过程中不断追加修改 | 历史难以重建 | -| Bundled commit | 将多个功能捆在一个 commit 里 | 拆分困难，回滚粒度过粗 | - -## Relationship to Branch Strategy - -Atomic Commit 与 [[Branch-Strategy]] 共同构成 [[Jira-Git-Traceability]] 的基础： -- Branch 隔离不同任务的工作 -- 每个 branch 内的 commit 进一步原子化 - -## Sources -- [[project-management-jira-workflow-steward]] diff --git a/wiki/concepts/Atomic-Note.md b/wiki/concepts/Atomic-Note.md deleted file mode 100644 index 482de2d6..00000000 --- a/wiki/concepts/Atomic-Note.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Atomic Note" -type: concept -tags: [knowledge-management, zettelkasten, note-taking] -sources: [zk-steward] -last_updated: 2026-05-30 ---- - -## Overview -Atomic Note（原子笔记）是 Zettelkasten 系统的基本工作单位——最小的、自包含的知识单元。它必须满足 [[Luhmann-四原则]]中的原子性要求：可以独立理解，不依赖上下文而存在。 - -## Definition -一个原子笔记 = 一个想法 + 一个唯一标识 + 至少两条指向其他笔记的链接 - -## Properties -- **Self-contained**：即使没有上下文，读者也能理解笔记的内容 -- **Single idea**：一个笔记只讨论一个核心主题（one idea per note） -- **Linked**：至少拥有 ≥2 条指向其他笔记/概念/实体的有意义的 wikilinks -- **Non-categorical**：不依赖文件夹层级分类，而是通过网络位置定义自己 - -## 与 Related Concepts 的关系 -- [[Zettelkasten]] ← Atomic Note 是 Zettelkasten 的基本工作单位 -- [[Luhmann-四原则]] ← 原子性（Atomicity）是 Luhmann 四原则之一，直接定义了 Atomic Note 的核心属性 -- [[Link-Proposer]] ← 新笔记归档时，Link-Proposer 确保原子笔记拥有 ≥2 条链接 -- [[Domain-Thinking]] ← 领域专家切换生成的内容，最终需要转化为原子笔记嵌入知识网络 - -## 创建条件 -- 可独立理解（通过 Luhmann 原子性测试） -- 包含 ≥2 条有意义的链接 -- 避免"零链接笔记"——零链接笔记违反 [[ZK-Steward-Agent]] 的核心规则 - -## Example（来自 ZK Steward Agent 文档中的结构笔记示例） -```markdown -## [Title] Structure Note -> **Context**: When, why, and under what project this was created. -> **Default reader**: Yourself in six months—this structure is self-contained. -``` -结构笔记下挂载多个原子笔记，每个原子笔记对应一个可独立理解的概念或论断。 diff --git a/wiki/concepts/Attachment-Theory.md b/wiki/concepts/Attachment-Theory.md deleted file mode 100644 index 44021d5a..00000000 --- a/wiki/concepts/Attachment-Theory.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Attachment Theory" -type: concept -tags: [] -sources: ["academic-psychologist"] -last_updated: 2026-04-20 ---- - -## Definition - -依恋理论（Attachment Theory）由 **John Bowlby** 创立，描述婴幼儿与主要照护者之间形成的情感纽带如何塑造成年后的亲密关系模式。 - -### 成人依恋四种类型 - -| 类型 | 特征 | 关系中行为表现 | -|------|------|---------------| -| **安全型（Secure）** | 信任他人，舒适亲密 | 开放沟通，冲突时能修复 | -| **焦虑型（Anxious-Preoccupied）** | 担心被抛弃，过度依赖 | 黏人、验证需求、情绪化 | -| **回避型（Dismissive-Avoidant）** | 独立优先，压抑情感 | 亲密回避，最小化关系 | -| **恐惧型（Fearful-Avoidant）** | 既渴望又害怕亲密 | 矛盾行为，墙-梯综合征 | - -## Key References - -- **John Bowlby**：依恋理论创始人，提出"安全基地"概念 -- **Mary Ainsworth**：陌生情境实验（Strange Situation），四种依恋类型的实证识别 - -## Applications in Character Design - -- 依恋风格决定角色在亲密关系中的**行为模式**和**触发情境** -- 安全型角色：能主动修复冲突，追求互惠 -- 焦虑型角色：过度验证对方承诺，在被忽视时崩溃 -- 回避型角色：在冲突升级时退缩，长期压抑情感需求 -- 恐惧型角色：在渴望亲密和害怕被伤害之间持续摆荡 - -## Critical Limitations - -- **文化中心主义**：Bowlby/Ainsworth 研究基于西方核心家庭，集体主义文化中"安全"模式可能不同 -- 依恋风格不是固定的——经历（特别是新的治疗关系）可以改变依恋模式 -- 简化为"类型"会忽略连续谱本质 - -## Connections - -- [[Big-Five-Personality]]（Neuroticism 与焦虑型依恋共享情绪不稳定维度） -- [[Psychological-Profile]]（依恋风格是角色心理画像的核心组成部分） -- [[Defense-Mechanisms]]（回避型依恋与隔离/反向形成等防御机制相关） -- [[Trauma-Informed-Analysis]]（不安全依恋常源于早期创伤） diff --git a/wiki/concepts/AttachmentTheory.md b/wiki/concepts/AttachmentTheory.md deleted file mode 100644 index bec7b5a0..00000000 --- a/wiki/concepts/AttachmentTheory.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Attachment Theory" -type: concept -tags: [] -sources: [academic-psychologist] -last_updated: 2026-04-25 ---- - -# Attachment Theory - -## Definition -Bowlby 依恋理论——认为早期与主要照顾者的关系模式会形成内部工作模型，影响个体一生中所有亲密关系的建立方式。 - -## Four Attachment Styles - -| 风格 | 特征 | 关系中的行为模式 | -|------|------|-----------------| -| Secure（安全型） | 信任、情绪调节良好 | 能亲密也能独立 | -| Anxious-Preoccupied（焦虑型） | 害怕被抛弃、过度依赖 | 粘人、情绪化索取 | -| Dismissive-Avoidant（回避型） | 情感独立、贬低亲密 | 逃避亲密、压抑情感 | -| Fearful-Avoidant（恐惧型） | 既渴望又害怕亲密 | 矛盾、忽冷忽热 | - -## Key Concepts -- **内部工作模型**（Internal Working Model）：对自我和他人的认知图式 -- **依恋唤起**（Attachment Activation）：压力情境触发依恋系统 -- **依恋回避**（Attachment Avoidance）：通过情感疏离应对亲密需求 -- **依恋焦虑**（Attachment Anxiety）：通过过度寻求确认应对被遗弃恐惧 - -## Application in Character Design -Psychologist Agent 在评估角色时，要求标注依恋风格及其在**浪漫/家庭/友谊**三种关系类型中的不同表现，并识别特定触发情境。 - -## Connection to Wiki -- Source: [[academic-psychologist]] diff --git a/wiki/concepts/Attach容器.md b/wiki/concepts/Attach容器.md deleted file mode 100644 index f14f88be..00000000 --- a/wiki/concepts/Attach容器.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Attach 容器" -type: concept -tags: [docker, remote-development, debugging] -last_updated: 2026-04-22 ---- - -## Definition -将 IDE 直接连接到正在运行的 Docker 容器内部进行代码开发和调试的工作模式。 - -## Mechanism -1. 在已运行的 Docker 容器中安装 IDE Server 代理 -2. 本地 IDE UI 通过 SSH/TCP 隧道与容器内 IDE Server 通信 -3. 所有代码编辑、终端、插件均运行在容器内部 -4. 容器重启后需重新 Attach - -## Characteristics -- **环境完全隔离**：直接使用容器内的 Python/Node/Go 等语言环境，无需在宿主机安装 -- **适合调试**：数据库、服务等依赖已在容器中运行 -- **适合轻量级修改**：代码变更即时生效（取决于是否使用 Bind Mount） -- **不适合镜像重建场景**：如需重新 build Dockerfile，需退出 Attach 重建 - -## vs 宿主机文件模式 -| 维度 | Attach 容器 | 宿主机文件 + Docker CLI | -|------|-------------|------------------------| -| 代码位置 | 容器内部 | 宿主机文件系统 | -| 环境隔离 | ✅ 完全 | ⚠️ 依赖宿主机环境 | -| 适合场景 | 调试、多语言混合 | docker-compose 编排 | -| Git 操作 | 需 SSH Agent Forwarding | 直接使用 | - -## Connections -- [[Remote-SSH]] — Attach 的实现基础 -- [[Bind Mount]] — 如需代码实时生效，可结合使用 -- [[Docker]] — 容器平台 -- [[Trae]] — 支持 Attach 容器的 IDE diff --git a/wiki/concepts/Attention-Economy.md b/wiki/concepts/Attention-Economy.md deleted file mode 100644 index b28618bc..00000000 --- a/wiki/concepts/Attention-Economy.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Attention-Economy" -type: concept -tags: [economics, marketing, strategy] -sources: [if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间] -last_updated: 2026-04-27 ---- - -## Aliases -- 注意力经济 -- 注意力护城河 - -## Definition -在信息爆炸时代，注意力是最稀缺的经济资源。[[if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间]] 指出： - -> "注意力是最后的护城河之一。" - -当任何人都能写任何内容或构建任何软件时，广为人知的产品才能胜出。再好的产品，如果无人知晓，无法与能吸引并保持注意力的人竞争。 - -## Why Attention Is the Final Moat -1. **信息过载**：AI 正在加速这一趋势 -2. **信任稀缺**：在信息洪流中，信任和信号比以往更重要 -3. **AI 的局限**：AI 只能复制已存在的内容，无法复制你的独特经历和视角 -4. **独特视角 = 不可替代**：你的生活方式、教育背景和兴趣交叉产生的视角，是最后无法被 AI 复制的护城河 - -## Strategic Implications -- **成为创作者**：停止消费，开始创作，将社交媒体作为获取注意力的工具 -- **Newsletter 中心化**：以新闻简报为核心，其他平台作为分发渠道 -- **直接受众关系**：email list > 平台粉丝（不依赖算法） -- **Build in Public**：公开你的思考和实践过程，吸引同频受众 - -## Connections -- [[Brand-Environment]] — 品牌是在注意力经济中获取注意力的机制 -- [[System-Economy]] — 系统经济需要注意力作为分发渠道 -- [[Second-Renaissance]] — 注意力经济是第二次文艺复兴的时代背景 -- [[Generalist]] — 跨领域视角是注意力经济中最稀缺的注意力吸引器 diff --git a/wiki/concepts/AudienceStrategy.md b/wiki/concepts/AudienceStrategy.md deleted file mode 100644 index a7645dc0..00000000 --- a/wiki/concepts/AudienceStrategy.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Audience Strategy" -type: concept -tags: ["ppc", "audience", "targeting", "google-ads", "paid-media"] -sources: ["paid-media-ppc-strategist"] -last_updated: 2026-05-01 ---- - -## Definition - -受众策略（Audience Strategy）是付费媒体中通过分层构建、精准定向和动态优化，最大化广告触达正确用户群体的系统性方法。涵盖第一方数据激活（Customer Match）、相似受众（Similar Segments）、竞品受众（In-Market/Affinity）、自定义受众组合，以及排除策略的整体设计。 - -## Audience Layers - -### Layer 1: First-Party Data（第一方数据） -- **Customer Match**：自有客户邮箱/电话列表，直接匹配 Google 用户 -- **CRM Audiences**：基于 CRM 数据构建的自定义受众 -- **Website Visitors**：GA4/GBoard 追踪的网站访问者（再营销） -- **App Users**：移动应用用户受众 - -### Layer 2: Similar / Lookalike（相似受众） -- **Similar Segments**：在 Customer Match 基础上自动扩展相似新用户 -- **Value-Based Similar**：按客户生命周期价值（CLV）分层的相似受众 - -### Layer 3: In-Market / Affinity（兴趣受众） -- **In-Market Audiences**：主动研究/比较中的潜在购买者（高转化潜力） -- **Affinity Audiences**：长期兴趣/生活方式相关用户（品牌建设场景） -- **Life Events**：人生重大事件（搬家/结婚/大学等） - -### Layer 4: Demographic（人口统计） -- **Age / Gender**：基础人口属性 -- **Household Income**：高收入人群定向（Premium 产品） -- **Parental Status**：家长定向 - -## Targeting vs Observation Mode - -| 模式 | 效果 | -|------|------| -| **Targeting** | 竞价时仅考虑定向人群，缩小范围 | -| **Observation** | 观察指定人群表现，但不限制竞价范围 | - -## Audience Exclusion - -- **排除已转化用户**：避免浪费在已有客户身上 -- **排除低质量受众**：表现差的历史受众列表 -- **排除员工**：避免内部测试流量污染数据 - -## Connections -- [[CustomerMatch]]：第一方数据激活的核心工具 -- [[PerformanceMax]]：Audience Signals 是 PMax 的关键输入 -- [[TieredCampaignArchitecture]]：不同层级的广告系列适用不同的受众策略 diff --git a/wiki/concepts/Audit-Readiness.md b/wiki/concepts/Audit-Readiness.md deleted file mode 100644 index 4349cc63..00000000 --- a/wiki/concepts/Audit-Readiness.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "Audit Readiness" -type: concept -tags: [finance, accounting, compliance, audit] -sources: [finance-bookkeeper-controller] -last_updated: 2026-05-02 ---- - -## Definition -审计就绪（Audit Readiness）是指企业日常维护的持续合规状态，确保在任何时间点审计师进场都能在规定时间内（通常24小时）提供任何财务余额的支持文件。 - -## Core Principle -> "Audit readiness is a daily practice. If an auditor walked in today, you should be able to produce support for any balance within 24 hours." -> — Dana, Bookkeeper & Controller Agent - -## Key Practices - -### Daily Habits -- 所有交易当天有支持文件 -- Journal entries 附带完整描述和审批记录 -- 银行对账每月及时完成 -- 所有支持文件归档有序 - -### Supporting Documentation Requirements -| Balance Type | Required Support | -|---|---| -| Cash | 银行对账单 + 调节表 | -| AR | Aging 报告 + 支持明细 | -| AP | 供应商对账单 + 发票 | -| Inventory | 盘点记录 | -| Fixed Assets | 资产明细表 + 折旧表 | -| Accruals | 计算底稿 | - -### Control Testing -- 所有关键控制有文档记录 -- 控制执行有证据（日志、审批截图） -- 例外情况有书面说明 - -## Core Principle -> "The audit should be boring. If the auditors are surprised, the controls failed." -> — Dana, Bookkeeper & Controller Agent - -## Success Metrics -- 审计调整 < 1% 总资产 -- 零重述 -- 所有审计请求 24 小时内响应 -- 审计周期缩短（目标：无聊的审计 = 成功的审计） - -## Related Concepts -- [[Internal Controls]] -- [[Account Reconciliation]] -- [[Month-End-Close-Process]] -- [[Segregation-Of-Duties]] diff --git a/wiki/concepts/Audit-Trail.md b/wiki/concepts/Audit-Trail.md deleted file mode 100644 index a1b5f694..00000000 --- a/wiki/concepts/Audit-Trail.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Audit-Trail" -type: concept -tags: [observability, compliance, n8n, security] -sources: [n8n-workflow-orchestration] -last_updated: 2026-04-17 ---- - -## Aliases -- Audit Trail -- 审计轨迹 - -## Definition - -系统自动记录每次工作流执行的完整输入、输出和状态信息，形成可追溯的执行历史。在 n8n 中，每次工作流触发都会记录执行数据，无需额外配置即可获得完整的操作审计日志。 - -## Why It Matters -- **合规需求**：SOC2、ISO 27001 等框架要求记录所有敏感操作 -- **故障排查**：API 调用失败时可快速定位问题 -- **Agent 行为审查**：确认 Agent 实际发送了什么数据 -- **数据回放**：失败的执行可重新触发 - -## Connections -- [[Visual-Debugging]] — 可视化调试依赖审计数据 -- [[Webhook-Proxy-Pattern]] — 自动为 Webhook 调用生成审计记录 -- [[n8n]] — 提供开箱即用的工作流执行审计能力 -- [[Defense-in-Depth]] — 审计轨迹是纵深防御的重要组成部分 diff --git a/wiki/concepts/Aurora-Global.md b/wiki/concepts/Aurora-Global.md deleted file mode 100644 index 77c6a0af..00000000 --- a/wiki/concepts/Aurora-Global.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Aurora Global" -type: concept -tags: - - AWS - - Aurora - - Database - - Disaster Recovery - - Multi-Region -sources: - - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora -last_updated: 2026-04-23 ---- - -## Overview -Aurora Global 是 Amazon Aurora 的跨区域数据库部署方案，允许将一个 Aurora 集群复制到其他 AWS 区域，支持低延迟的全局读取和快速的区域级故障转移。 - -## Core Features -- **跨区域复制**：异步复制数据到最多 5 个辅助区域 -- **托管式切换（Managed Switchover）**：支持干净的故障转移，无需重新复制数据 -- **快速故障转移**：AZ 故障时可在约 30 秒内完成 RTO；区域级故障通过 Aurora Global 切换 -- **全局读取加速**：辅助区域可就近提供读取流量，降低读取延迟 - -## Key Capabilities - -### Managed Switchover -Aurora Global 支持托管式切换（Managed Switchover），主区域发生故障时： -1. 将辅助区域提升为新的主区域 -2. 故障区域恢复后，作为新的辅助区域重新加入全球集群 -3. 无需重新复制数据，切换过程干净快速 - -### vs RDS Cross-Region Replication -| 特性 | Aurora Global | RDS Cross-Region | -|------|-------------|-----------------| -| 复制类型 | 异步 | 异步 | -| 故障切换 | 托管式切换，无需重新复制 | 需阻断访问，重建集群 | -| 辅助区域数量 | 最多 5 个 | 依赖具体配置 | -| 读取扩展 | 支持（辅助区域读取） | 支持（读副本） | - -## Related Concepts -- [[Amazon Aurora]]：Aurora Global 的宿主数据库 -- [[RTO]]：Aurora Global 帮助实现低 RTO -- [[Multi-AZ]]：AZ 级高可用 vs Aurora Global 区域级灾备 -- [[Blue-Green Deployment]]：Aurora MySQL 支持的部署策略 - -## Aliases -- Aurora Global Database -- Aurora Global Cluster -- Aurora Cross-Region Replication -- Aurora Multi-Region diff --git a/wiki/concepts/Automated-Health-Logging.md b/wiki/concepts/Automated-Health-Logging.md deleted file mode 100644 index f74a3ab0..00000000 --- a/wiki/concepts/Automated-Health-Logging.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Automated Health Logging" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-22 ---- - -# Automated Health Logging - -利用 AI 自动解析自然语言输入并写入结构化健康数据日志的实践方法。 - -## Definition -通过自然语言接口（消息、语音、文本）收集健康数据，由 AI 自动解析提取关键实体（食物、症状、药物等）并写入结构化日志文件，减少人工录入负担。 - -## Key Components -1. **自然语言输入**：用户以日常语言描述，无需记忆特定格式 -2. **AI 解析引擎**：提取食物名称、数量、时间、症状描述等关键信息 -3. **结构化存储**：写入 Markdown/JSON 等可读且易处理的日志文件 -4. **定时提醒**：Cron Job 驱动的一日多次提醒，确保数据完整性 - -## Comparison with Manual Logging - -| 维度 | 手动记录 | 自动化日志 | -|------|---------|-----------| -| 门槛 | 需要记忆格式 | 任意自然语言 | -| 一致性 | 易遗漏 | 提醒驱动 | -| 可分析性 | 依赖用户格式化 | AI 标准化 | -| 维护成本 | 高 | 低 | - -## Implementation -- [[health-symptom-tracker]]：Telegram topic → OpenClaw Agent → Markdown 日志文件 -- [[habit-tracker-accountability-coach]]：类似的自动化记录模式 - -## Connections -- [[Food Sensitivity Tracking]] ← enabled_by ← [[Automated Health Logging]] -- [[OpenClaw]] ← powers ← [[Automated Health Logging]] diff --git a/wiki/concepts/Automated-Security-Audit.md b/wiki/concepts/Automated-Security-Audit.md deleted file mode 100644 index 0070ec14..00000000 --- a/wiki/concepts/Automated-Security-Audit.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: "Automated Security Audit" -tags: - - devops - - security - - automation - - compliance - - ai -created: 2026-04-25 ---- - -# Automated Security Audit - -## Definition - -Automated Security Audit 是通过 AI 自动扫描 IAM 策略、网络规则和容器漏洞，**检测安全风险并自动修复**的能力。Agentic AI 持续监控安全态势，实时执行合规修复。 - -## Scope - -| 扫描对象 | 检测内容 | 修复动作 | -|---------|---------|---------| -| IAM Policies | 过度权限、公共访问风险 | 自动限制权限 | -| Network Rules | 开放端口、安全组配置错误 | 自动收紧规则 | -| Container Images | 已知漏洞 (CVE) | 触发重建 + 更新 | -| S3 Buckets | 公开访问、数据泄露风险 | 自动阻止公共访问 | -| Firewalls | 配置错误、入站规则过宽 | 自动修正 | - -## Agentic AI Security Audit 工作流 - -``` -1. 持续扫描 → AWS Inspector / GCP Security Command Center / Azure Defender -2. 风险评估 → CVSS 评分 + 业务影响分析 -3. 自动修复 → 低风险自动修复，高风险人工审批 -4. 合规验证 → SOC 2 / FedRAMP / PCI DSS 持续检查 -5. 报告生成 → 安全态势仪表盘 + 合规报告 -``` - -## 与 [[DevSecOps]] 的关系 - -Automated Security Audit 是 [[DevSecOps]] 实践的核心组件： - -```python -DevSecOps_Pipeline = { - "Build": "SAST (Static Application Security Testing)", - "Test": "DAST (Dynamic Application Security Testing)", - "Deploy": "Container Scanning ←", # 漏洞扫描 - "Monitor": "Automated Security Audit ←", # ← 本页 - "Respond": "自动威胁缓解" -} -``` - -## 示例 - -> Agentic AI detects an over-permissive IAM role: -> - Role: `production-app-read-all` -> - Allows: `s3:*` on `arn:aws:s3:::customer-data-*` -> - Risk: Public access enabled on bucket -> - **AI Action**: -> - Immediately restricts bucket policy -> - Notifies DevOps team via Slack -> - Creates Jira ticket for IAM review -> - Logs audit trail for compliance - -## 与合规框架的关系 - -| 合规框架 | Agentic AI 支持方式 | -|---------|-------------------| -| SOC 2 | 持续访问审计 + 变更记录 | -| FedRAMP | 安全配置基线检查 + 报告 | -| PCI DSS | 数据访问控制 + 加密验证 | -| ISO 27001 | 风险评估 + 修复验证 | - -## Related Concepts - -- [[DevSecOps]] — Automated Security Audit 是 DevSecOps 的技术基础 -- [[Cloud Security]] — 审计是云安全的核心实践 -- [[IAM]] — 主要审计对象之一 -- [[Compliance]] — 审计支持合规证明 - -## Related Sources - -- [[how-agentic-ai-can-help-for-cloud-devops]] -- [[cloud-devop-maturity-guideline]] diff --git a/wiki/concepts/AutomatedBiddingStrategy.md b/wiki/concepts/AutomatedBiddingStrategy.md deleted file mode 100644 index f3212635..00000000 --- a/wiki/concepts/AutomatedBiddingStrategy.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Automated Bidding Strategy" -type: concept -tags: ["ppc", "bidding", "automation", "google-ads", "paid-media"] -sources: ["paid-media-ppc-strategist"] -last_updated: 2026-05-01 ---- - -## Definition - -自动化竞价策略（Automated Bidding Strategy）是 Google Ads 等平台提供的基于机器学习的智能出价系统，通过算法自动调整每次竞价出价，以优化预设的绩效目标（转化量、转化价值、ROAS 等）。区别于手动 CPC 出价，自动化竞价利用受众信号、上下文信号和历史数据自动优化。 - -## Available Strategies - -| 策略 | 目标 | 适用场景 | -|------|------|---------| -| **Maximize Conversions** | 最大化转化量 | 数据充足、追求规模 | -| **Maximize Conversion Value** | 最大化转化价值 | 客单价差异大、多产品 | -| **tCPA（Target CPA）** | 固定平均单次转化成本 | 稳定转化数据、追求效率 | -| **tROAS（Target ROAS）** | 固定广告支出回报率 | 有明确 ROAS 目标 | -| **Enhanced CPC（ECPC）** | 在手动 CPC 基础上提升转化 | 向自动竞价过渡阶段 | -| **Maximize Clicks** | 最大化点击量 | 流量获取阶段 | - -## Transition Framework - -从手动向自动竞价迁移的推荐路径： - -1. **数据积累期**（4-6周）：手动 CPC + ECPC，建立转化数据基础 -2. **轻度自动化**（2-4周）：切换至 Maximize Conversions，监控效果 -3. **目标竞价**（持续）：根据业务目标选择 tCPA 或 tROAS - -## Key Requirements - -- **转化数据充足**：策略效果与数据量直接相关 -- **Conversion Action 正确配置**：追踪须准确，否则算法基于错误信号优化 -- **预算充足**：日预算至少达到目标 CPA 的 5-10 倍，保证算法学习 -- **时间窗口合理**：建议 4 周学习期后再评估效果 - -## Connections -- [[GoogleAds]]：Google Ads 是最主要的自动化竞价平台 -- [[PerformanceMax]]：内置 Smart Bidding，是 AI 驱动优化的典型场景 -- [[TieredCampaignArchitecture]]：不同层级的广告系列适用不同竞价策略 diff --git a/wiki/concepts/AutomatedReminders.md b/wiki/concepts/AutomatedReminders.md deleted file mode 100644 index f042b199..00000000 --- a/wiki/concepts/AutomatedReminders.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "AutomatedReminders" -type: concept -tags: [automation, reminders, scheduling] -sources: [multi-channel-assistant] -last_updated: 2026-04-27 ---- - -## Definition -Automated Reminders（自动化提醒）是一种由定时任务（Cron）驱动、由 AI Agent 在预设时间主动向用户发送通知的机制。区别于被动查询——提醒在用户没有主动发起请求的情况下，根据时间或事件自动触发。 - -## Core Pattern -1. **触发条件**：时间驱动（每周一 18:00）或事件驱动（任务截止前 24h） -2. **提醒生成**：AI Agent 根据上下文（个人 CRM、 calendario、项目状态）生成个性化提醒内容 -3. **发送通道**：Telegram / Slack / SMS / Email 等 -4. **记忆上下文**：提醒内容往往依赖 [[Agent-Memory]] 中的个人数据（联系人偏好、日程安排） - -## Example from [[multi-channel-assistant]] -``` -Monday 6 PM: "🗑️ Trash day tomorrow" -Friday 3 PM: "✍️ Time to write the weekly company update" -``` - -## Related Concepts -- [[Scheduled-Task-Flywheel]] — 定时任务的飞轮效应 -- [[Cron定时任务]] — 定时任务的技术实现 -- [[Proactive-Agent-Recommendation]] — 主动式 Agent 的推荐能力 -- [[TopicRouting]] — 提醒通常通过 config/updates 话题发送 - -## Connections -- [[multi-channel-assistant]] ← implements ← [[AutomatedReminders]] -- [[HabitTrackerAccountabilityCoach]] ← uses ← [[AutomatedReminders]]（习惯追踪的主动提醒） diff --git a/wiki/concepts/Automation-Decision-Framework.md b/wiki/concepts/Automation-Decision-Framework.md deleted file mode 100644 index ad980c5b..00000000 --- a/wiki/concepts/Automation-Decision-Framework.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Automation Decision Framework" -type: concept -tags: [automation, governance, decision, evaluation] -sources: [automation-governance-architect] -last_updated: 2026-05-01 ---- - -# Automation Decision Framework - -四维自动化评估框架，Automation Governance Architect 对每个自动化请求强制执行的决策前置步骤。 - -## 四维评估 - -### 1. Time Savings Per Month（月度时间节省） -- 节省是否可持续且有意义？ -- 流程频率是否足以覆盖自动化开销？ - -### 2. Data Criticality（数据关键性） -- 是否涉及客户、财务、合同或调度记录？ -- 错误 / 延迟 / 重复 / 缺失数据的 Impact 是什么？ - -### 3. External Dependency Risk（外部依赖风险） -- 链条中有多少外部 API/服务？ -- 它们是否稳定、有文档、可观测？ - -### 4. Scalability 1x to 100x（可扩展性） -- 重试、去重、速率限制在高负载下是否仍然有效？ -- 异常处理在大规模下是否仍可管理？ - -## 与 Verdict System 的关系 - -四维评估结果直接决定 [[Automation-Verdict-System]] 五级裁定： -- 四维均达标 → APPROVE -- 部分维度满足但有限制 → APPROVE AS PILOT / PARTIAL AUTOMATION ONLY -- 任一维度存在重大问题 → DEFER / REJECT - -## Sources -- [[automation-governance-architect]] diff --git a/wiki/concepts/Automation-Verdict-System.md b/wiki/concepts/Automation-Verdict-System.md deleted file mode 100644 index 8d4a74e3..00000000 --- a/wiki/concepts/Automation-Verdict-System.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Automation Verdict System" -type: concept -tags: [automation, governance, verdict, decision] -sources: [automation-governance-architect] -last_updated: 2026-05-01 ---- - -# Automation Verdict System - -五级自动化裁定结果体系，基于 [[Automation-Decision-Framework]] 四维评估后输出。 - -## 五级裁定 - -| 裁定 | 条件 | 含义 | -|------|------|------| -| **APPROVE** | 强价值 + 可控风险 + 可维护架构 | 可直接进入生产实施 | -| **APPROVE AS PILOT** | 价值存在但需小范围验证 | 限定范围试点，验证后再全面铺开 | -| **PARTIAL AUTOMATION ONLY** | 自动化安全段有价值，人工检查点不可少 | 仅自动化低风险环节，关键决策保留人工 | -| **DEFER** | 流程不成熟 / 价值不明 / 依赖不稳定 | 暂不推进，等待条件成熟 | -| **REJECT** | 经济性弱或运营/合规风险不可接受 | 明确拒绝，不进入实施阶段 | - -## 核心原则 - -- **一次只选一个裁定**：不存在模糊状态 -- **裁定须附带理由**：Verdict 须对应 Rationale（业务 Impact / 关键风险 / 裁定依据） -- **裁定附带架构建议**：即使 APPROVE 也需推荐 Architecture（触发点 / 验证逻辑 / 日志 / 错误处理 / Fallback） - -## Required Output Format（裁定输出格式） - -每份裁定必须包含： -1. Process Summary（流程摘要） -2. Audit Evaluation（四维评估） -3. Verdict（裁定） -4. Rationale（理由） -5. Recommended Architecture（推荐架构） -6. Implementation Standard（实施标准） -7. Preconditions and Risks（前置条件和风险） - -## Sources -- [[automation-governance-architect]] diff --git a/wiki/concepts/AutomationGovernance.md b/wiki/concepts/AutomationGovernance.md deleted file mode 100644 index 52a8a355..00000000 --- a/wiki/concepts/AutomationGovernance.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "AutomationGovernance" -type: concept -tags: [] -last_updated: 2026-04-25 ---- - -# AutomationGovernance（自动化治理） - -## Definition -通过决策框架和标准，对业务流程自动化进行事前评估、事中监控和事后审计的完整治理体系。 - -## Core Framework - -### Four Evaluation Dimensions -1. **Time Savings Per Month**（每月时间节省）：节省是否重复发生且数额可观；流程频率是否足以支撑自动化开销 -2. **Data Criticality**（数据关键性）：是否涉及客户/财务/合同/日程记录；数据错误/延迟/重复/缺失的影响是什么 -3. **External Dependency Risk**（外部依赖风险）：链条中涉及多少外部 API/服务；它们是否稳定、有文档、可观测 -4. **Scalability**（可扩展性）：1x 到 100x 时，重试、去重、限流是否仍能正常工作；异常处理在量级下是否可管理 - -### Five Verdicts -| 裁决 | 条件 | -|------|------| -| **APPROVE** | 价值强、风险可控、架构可维护 | -| **APPROVE AS PILOT** | 价值可期但需限制试点范围 | -| **PARTIAL AUTOMATION ONLY** | 仅自动化安全段落，保留人工检查点 | -| **DEFER** | 流程不成熟、价值不明确或依赖不稳定 | -| **REJECT** | 经济价值弱或运营/合规风险不可接受 | - -## Related Concepts -- [[N8nWorkflowStandard]]：n8n 编排工具的标准工作流模板 -- [[DecisionFramework]]：本概念的评估维度体系 -- [[ReliabilityBaseline]]：生产级工作流的可靠性最低要求 -- [[IntegrationGovernance]]：集成接入的治理规范 - -## Sources -- [[automation-governance-architect]]（primary） diff --git a/wiki/concepts/Autoscaling.md b/wiki/concepts/Autoscaling.md deleted file mode 100644 index 779819d9..00000000 --- a/wiki/concepts/Autoscaling.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Autoscaling" -type: concept -tags: [sre, cloud, scalability, reliability, kubernetes] -last_updated: 2026-04-20 ---- - -# Autoscaling - -自动扩缩容（Autoscaling）是云原生系统中根据负载自动调整资源容量的机制，但它与真正的弹性（Elasticity）有本质区别。 - -## Definition -Autoscaling 通过预定义的规则（如 CPU 使用率、请求队列长度等）自动增加或减少计算资源。它是一种**被动的、反应式的**机制。 - -## Key Limitation -> "Autoscaling is reactive, not resilient. Without caps, metrics, or overrides, it can worsen failures." — David Iyanu Jonathan - -没有以下保护机制时，Autoscaling 可能**加剧故障**： -- **上限（caps）**：防止无限扩容 -- **指标（metrics）**：确保扩容基于可靠数据 -- **覆盖机制（overrides）**：允许人工干预 - -## Autoscaling vs. Elasticity - -| Aspect | Autoscaling | [[Elasticity]] | -|--------|-------------|----------------| -| 性质 | 被动的、反应式的 | 主动的、前瞻性的 | -| 触发 | 基于指标阈值 | 基于策略和规划 | -| 保护机制 | 可能缺失 | 必须具备 | -| 故障时行为 | 可能加剧故障 | 设计上防止故障扩大 | - -## Anti-Patterns -- **Autoscaling to Death**：系统在负载高峰时无限扩容，导致资源耗尽 -- **No Upper Limits**：缺少上限导致成本爆炸 -- **Metrics Blindness**：依赖单一指标，忽视系统整体健康状况 - -## Best Practices -1. 设置合理的扩容上限和缩容下限 -2. 配置多维度指标（不仅仅是 CPU） -3. 建立人工覆盖机制 -4. 在非生产环境测试扩容策略 -5. 监控 Autoscaling 本身的行为 - -## Related Concepts -- [[Elasticity]] -- [[Scalability]] -- [[Cluster-Autoscaler]] -- [[Cost-Optimization]] - -## Source -- SRE Weekly Issue #513 — [[sre-weekly-issue-513]] diff --git a/wiki/concepts/Availability-Zone-ID.md b/wiki/concepts/Availability-Zone-ID.md deleted file mode 100644 index f19c90d4..00000000 --- a/wiki/concepts/Availability-Zone-ID.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: "Availability-Zone-ID" -type: concept -tags: [AWS, VPC, Networking, Multi-Account] -sources: - - ctp-topic-45-automatic-ip-address-allocation-with-ipam - - ctp-topic-61-workload-vpc-provision-with-ipam-automation -last_updated: 2026-04-24 ---- - -## Availability-Zone-ID - -AWS 可用区标识符（如 `ap-southeast-1a`、`ap-southeast-1b`），用于在多账号 AWS 环境中精确定位物理可用区位置。相比 AZ 名称，AZ ID 能唯一标识跨账号的同一物理位置。 - -## Problem: AZ Name Inconsistency - -不同 AWS 账号对同一物理可用区的**名称**可能不同： - -| 账号 A | 账号 B | 物理位置（AZ ID） | -|--------|--------|-------------------| -| ap-southeast-1a | ap-southeast-1b | apse1-az1 | -| ap-southeast-1b | ap-southeast-1a | apse1-az2 | - -**问题**： -- 账号 A 的 `ap-southeast-1a` = 账号 B 的 `ap-southeast-1b`（物理位置相同） -- 如果用 AZ 名称设计跨账号 VPC 对等连接或可用性架构，可能出现"看起来对称但物理不对称"的问题 - -## Solution: Use AZ ID - -使用 AZ ID（如 `apse1-az1`）替代 AZ 名称： - -```yaml -availability_zone_ids: - - apse1-az1 # 物理位置 apse1 的第一个 AZ - - apse1-az2 # 物理位置 apse1 的第二个 AZ -``` - -**优势**： -- 跨账号一致性：AZ ID 在所有账号中唯一标识同一物理位置 -- 可靠性设计：确保高可用架构在物理层面真正对称 -- VPC 对等连接：正确配置跨账号连接 - -## How to Find AZ IDs - -```bash -# 使用 AWS CLI 查询当前账号的 AZ ID 映射 -aws ec2 describe-availability-zones --output json -``` - -输出示例： -```json -{ - "AvailabilityZones": [ - { - "ZoneName": "ap-southeast-1a", - "ZoneId": "apse1-az1", - "RegionName": "ap-southeast-1" - }, - { - "ZoneName": "ap-southeast-1b", - "ZoneId": "apse1-az2", - "RegionName": "ap-southeast-1" - } - ] -} -``` - -## Key Concepts - -- [[VPC-自动化供给]]：AZ ID 是 VPC YAML 配置的一部分 -- [[IPAM]]：IPAM 与 VPC 供给集成时需考虑 AZ 映射 - -## Connections - -- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← YAML 支持指定 AZ ID -- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← 强调 AZ ID 用于跨账号一致性 - -## Aliases - -- AZ ID -- Availability Zone Identifier -- 物理可用区标识符 diff --git a/wiki/concepts/Availability.md b/wiki/concepts/Availability.md deleted file mode 100644 index eee0a915..00000000 --- a/wiki/concepts/Availability.md +++ /dev/null @@ -1,71 +0,0 @@ -# Availability - -## Definition -Availability is the time a system remains operational and accessible to users. It is typically expressed as a percentage of uptime over a defined period (e.g., monthly or yearly). - -The DevOps Maturity Model explicitly lists Availability as one of the key metrics for measuring DevOps maturity. - -## Availability SLAs - -Common availability targets: - -| Availability | Downtime/Year | Downtime/Month | Downtime/Week | -|-------------|---------------|----------------|---------------| -| 99% | 3.65 days | 7.31 hours | 1.68 hours | -| 99.9% | 8.76 hours | 43.83 minutes | 10.08 minutes | -| 99.99% | 52.60 minutes | 4.38 minutes | 1.01 minutes | -| 99.999% | 5.26 minutes | 26.30 seconds | 6.05 seconds | - -## Across DevOps Maturity Levels - -| Maturity | Availability Capability | -|----------|----------------------| -| Phase 1 | Poor — reactive monitoring, siloed teams, manual processes cause frequent outages | -| Phase 2 | Improving — essential monitoring detects issues, but manual intervention required | -| Phase 3 | Better — automated infrastructure reduces human errors, faster recovery | -| Phase 4 | High — continuous monitoring for early detection, root cause analysis capability | -| Phase 5 | Max uptime — no interruptions to customer experience, rapid data-driven decisions | - -## Key Practices for High Availability - -### Architecture -- Redundancy at every layer -- Load balancing -- Geographic distribution -- Graceful degradation -- Circuit breakers - -### Operations -- Continuous monitoring -- Automated failover -- Disaster recovery planning -- Regular maintenance windows -- Capacity planning - -### Development -- Robust error handling -- Idempotent operations -- Transaction management -- Feature flags for rapid rollback -- Chaos engineering - -## Relationship with Other Metrics - -| Metric | Relationship with Availability | -|--------|-------------------------------| -| **MTTD** | Faster detection = shorter outage = higher availability | -| **MTTR** | Faster recovery = shorter outage = higher availability | -| **Error Budget** | Availability target defines the error budget | -| **Change Failure Rate** | Fewer failed deployments = fewer outages = higher availability | -| **Scalability** | Better scalability prevents availability degradation under load | - -## Sources -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] - -## Related Concepts -- [[concepts/High-Availability]] -- [[concepts/MTTR]] -- [[concepts/Error-Budget]] -- [[concepts/Scalability]] -- [[concepts/Disaster-Recovery]] -- [[concepts/DevOps-Maturity]] diff --git a/wiki/concepts/B2B-Social-Selling.md b/wiki/concepts/B2B-Social-Selling.md deleted file mode 100644 index 2119cc88..00000000 --- a/wiki/concepts/B2B-Social-Selling.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "B2B Social Selling" -type: concept -tags: [b2b, social-media, sales, linkedin, lead-generation] -last_updated: 2026-04-26 ---- - -## Definition -B2B 社交销售是一种利用 LinkedIn、Twitter 等专业社交平台建立关系网络、培育潜在客户并最终驱动销售管道增长的策略。它将社交媒体从品牌曝光工具升级为可量化的销售渠道，通过提供有价值的内容和建立专业权威来吸引和转化 B2B 客户。 - -## Core Framework -### 1. Profile Optimization（档案优化） -- 专业头像和高影响力 banner -- 价值主张清晰描述（Headline + About） -- 社会证明（推荐、认证、成就） -- CTA（联系方式或预约链接） - -### 2. Content Publishing（内容发布） -- 行业洞察和问题解决方案 -- 案例研究和成功故事 -- 思想领导力文章 -- 与潜在客户相关的内容分享 - -### 3. Engagement Strategy（互动策略） -- 个性化连接请求（而非批量请求） -- 目标客户公司的员工网络拓展 -- 有价值评论（而非简单点赞） -- 私信培育序列 - -### 4. Pipeline Integration（管道整合） -- CRM 集成追踪社交线索 -- 内容触发的 nurture 序列 -- 会议预约转化路径 -- 销售赋能内容库 - -## Key Metrics -- InMail 打开率 / 回复率 -- 每月新 connections 中目标客户占比 -- 社交引流 leads 数量 -- 社交来源 pipeline 金额 -- 销售周期影响（社交活跃 vs 非活跃客户对比） - -## Key Principles -- **信任先于销售**：通过持续价值输出建立专业信誉 -- **个性化优先**：批量消息效果远低于针对性内容 -- **长期培育**：社交销售是关系投资，非即时转化 -- **内容驱动**：分享知识比推销产品更有效 - -## Sources -- [[marketing-social-media-strategist]] diff --git a/wiki/concepts/BEATS.md b/wiki/concepts/BEATS.md deleted file mode 100644 index 3408e0ac..00000000 --- a/wiki/concepts/BEATS.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "BEATS" -type: concept -tags: [DevOps, Observability, Logging, OpenSource] -sources: [ctp-topic-54-esm-saas-log-analytics] -last_updated: 2026-04-25 ---- - -# BEATS - -**BEATS** 是 Elastic 公司开发的轻量级开源日志与指标数据采集代理家族，属于 ELK Stack 的数据采集层。名称来自 "Beats" 系列工具（Filebeat、Metricbeat、Packetbeat 等）。 - -## Core Concept - -*"The application collects your log, it's called the BEATS."* — Jackie - -BEATS 代理部署在应用侧，轻量级运行，持续将日志数据推送至 Logstash 或 Elasticsearch/OpenSearch。 - -## Member Tools - -| Tool | Purpose | -|------|---------| -| **Filebeat** | 日志文件采集（最常用），支持容器环境（Kubernetes DaemonSet） | -| **Metricbeat** | 系统和服务指标采集 | -| **Packetbeat** | 网络数据包分析 | -| **Heartbeat** | 站点可用性探测 | -| **Auditbeat** | Linux 审计框架数据 | -| **Journalbeat** | systemd journal 采集 | - -## Use in ELK Architecture - -``` -应用层 (Application VPC) - └── Filebeat (容器/DaemonSet) → 持续采集日志文件 - ↓ -日志层 (Logging VPC) - └── Logstash → 解析和转换字段 - ↓ - └── Elasticsearch/OpenSearch → 存储 - ↓ - └── Kibana → 可视化 -``` - -## Key Claims - -- Filebeat 是在 Kubernetes 容器环境中部署日志采集的首选方案 -- BEATS 代理轻量、低资源占用，适合在每个应用节点部署 -- Filebeat 支持多行日志合并（如 Java Stack Trace）和多种日志格式解析 - -## Related Concepts - -- [[ELK-Stack]]：BEATS 是 ELK 栈的采集层 -- [[Logstash]]：BEATS 采集的数据通常先推送至 Logstash 进行处理 -- [[OpenSearch]]：Filebeat 可直接推送至 OpenSearch，无需 Logstash -- [[Centralized-Logging]]：BEATS 是集中式日志采集的重要组件 - -## Sources - -- [[ctp-topic-54-esm-saas-log-analytics]] diff --git a/wiki/concepts/BI平台.md b/wiki/concepts/BI平台.md deleted file mode 100644 index 0637a488..00000000 --- a/wiki/concepts/BI平台.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "BI平台" -type: concept -aliases: - - BI Platform - - Business Intelligence Platform - - 数据分析平台 -tags: [bi, data, visualization, analytics] -date: 2026-04-14 ---- - -# BI平台 - -## Definition -**BI 平台**（Business Intelligence Platform）是一种软件系统，用于从企业数据中提取洞察、支持决策制定。核心功能包括：数据连接与整合、SQL 查询与探索、多样化图表可视化、交互式仪表盘构建、数据驱动报警。 - -## Key Capabilities -1. **多数据源连接**: 支持 SQL 数据库、API、文件导入等多种数据源 -2. **SQL 探索**: 内置 SQL 查询编辑器，支持即席分析 -3. **图表可视化**: 提供折线图、柱状图、饼图、地理图、热力图等多样化图表 -4. **仪表盘构建**: 将多个图表组合为仪表盘，支持筛选和交互 -5. **权限管理**: 基于角色的访问控制（RBAC） - -## Wiki 中的相关工具 - -| 工具 | 类型 | 特点 | 部署方式 | -|------|------|------|----------| -| [[Apache Superset]] | BI 平台 | Apache 基金会项目，SQL 优先，图表 Gallery 丰富 | Docker | -| [[Grafana]] | 监控/仪表盘 | 监控数据可视化首选，支持告警 | Docker | -| [[Jellyfin]] | 媒体服务器 | 视频播放管理，非 BI | Docker | - -## Key Distinction: BI vs 监控 -- **BI 平台**：面向业务分析（销售/财务/运营），强调交互式探索和美观的图表 Gallery -- **监控平台**（如 Grafana）：面向系统可靠性（CPU/内存/服务可用性），强调告警和时序数据 -- 两者在仪表盘层面有重叠，Superset 可以接入 Prometheus 等监控数据源 - -## Related Concepts -- [[数据可视化]] -- [[Docker容器化部署]] -- [[Home Server Automation]] diff --git a/wiki/concepts/BONDING-Strategy.md b/wiki/concepts/BONDING-Strategy.md deleted file mode 100644 index c907900c..00000000 --- a/wiki/concepts/BONDING-Strategy.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "BONDING Strategy" -type: concept -tags: [trading, prediction-market, contrarian] -last_updated: 2026-05-18 ---- - -## Aliases -- Contrarian Strategy -- 均值回归策略 -- 逆向策略 - -## Definition -BONDING 策略是一种逆向/均值回归交易策略，专用于 Polymarket 等预测市场。当市场因突发新闻而过度反应（概率在短时间内骤降超过 10%）时，逆向建仓押注价格回归。该策略假设市场情绪化反应会导致定价偏差，为逆向投资者提供机会。 - -## How It Works -1. 监控 Polymarket 市场的概率突变事件 -2. 当概率因新闻在短时间内骤降 >10% 时触发信号 -3. 逆向建仓（买入被恐慌抛售的选项） -4. 等待价格回归到合理区间 -5. 达到目标价位时平仓获利 - -## Parameters -- 概率骤降阈值：>10%（短时间内） -- 建仓时机：新闻事件后的恐慌期 -- 持仓周期：价格回归期间（可能较长） - -## Related Strategies -- [[TAIL Strategy]]：趋势跟踪策略，在市场强势时顺势操作 -- [[SPREAD Strategy]]：套利策略，在定价错误时捕获无风险收益 - -## Source -- [[polymarket-autopilot]] diff --git a/wiki/concepts/BOOTSTRAP.md.md b/wiki/concepts/BOOTSTRAP.md.md deleted file mode 100644 index 6e85037f..00000000 --- a/wiki/concepts/BOOTSTRAP.md.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "BOOTSTRAP.md" -type: concept -tags: [OpenClaw, Agent, Setup] -sources: [万字讲透openclaw-workspace深度解析-2026-03-21] -last_updated: 2026-03-21 ---- - -## Definition - -**BOOTSTRAP.md** 是 OpenClaw workspace 中最特殊的一个文件——它的使命是把一个全新的 workspace 引导到"可正常使用"的状态。这是一份"第一次上岗前的引导词"，Agent 读到它后知道自己不是立刻开工，而是先把自己安顿好。 - -## 引导流程 - -1. 和用户聊几句，搞清楚 Agent 应该叫什么名字、是什么性格、用什么 emoji -2. 把结果写入 `IDENTITY.md` -3. 记录用户的基本信息到 `USER.md` -4. 一起打开 `SOUL.md`，把真正的性格和边界写进去 -5. （可选）引导用户接入渠道——WhatsApp、Telegram 等 - -## 一次性特性 - -官方模板的最后一句话非常有意思： - -> *"Delete this file. You don't need a bootstrap script anymore — you're you now."* - -BOOTSTRAP.md 本质上是一次性引导，Agent 在完成初始化后必须把它删掉。 - -## Related Concepts - -- [[IDENTITY.md]] — 初始化时写入身份元数据的目标文件 -- [[SOUL.md]] — 初始化时写入性格设定的目标文件 -- [[USER.md]] — 初始化时写入用户画像的目标文件 -- [[OpenClaw]] — BOOTSTRAP.md 所属的框架 - diff --git a/wiki/concepts/BOSCARD.md b/wiki/concepts/BOSCARD.md deleted file mode 100644 index 148b622f..00000000 --- a/wiki/concepts/BOSCARD.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "BOSCARD" -type: concept -tags: [Business-Analysis, Requirements, Project-Management] -sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109] -last_updated: 2026-05-11 ---- - -## Definition - -BOSCARD 是一个用于定义复杂新工作的结构化框架，通过八个维度全面澄清项目背景和关键要素。 - -## BOSCARD 八要素 - -| 字母 | 要素 | 含义 | -|------|------|------| -| **B** | Background | 背景——为什么需要这项工作？ | -| **O** | Objectives | 目标——我们希望实现什么？ | -| **S** | Scope | 范围——包含什么？不包含什么？ | -| **C** | Constraints | 约束——时间、预算、技术等限制条件 | -| **A** | Assumptions | 假设——我们认为哪些前提条件是成立的？ | -| **R** | Risks | 风险——可能出错的因素有哪些？ | -| **R** | Roles | 角色——谁负责什么？ | -| **D** | Deliverables | 交付物——最终产出是什么？ | - -## Key Quote - -> "If you can get scope tied down early on and agreed, that's priceless." - -范围（Scope）的早期锁定和达成共识是无价的——这正是 BOSCARD 的核心价值所在。 - -## Application Scenario - -BOSCARD 特别适用于： -- 新项目的立项定义 -- 复杂需求的澄清会议 -- 变更请求的评估 -- 跨团队协作的初始对齐 - -## Relationship to Other Concepts - -- [[Business-Analysis]]：BOSCARD 是业务分析的核心技法之一 -- [[Stakeholder-Wheel]]：BOSCARD 通常在识别干系人之后使用 -- [[Requirements-Gathering]]：BOSCARD 定义的范围指导后续的需求收集 - -## Aliases -- BOSCARD Technique -- 复杂工作定义框架 diff --git a/wiki/concepts/BYOD.md b/wiki/concepts/BYOD.md deleted file mode 100644 index 96cbbef8..00000000 --- a/wiki/concepts/BYOD.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "BYOD" -type: concept -tags: - - BYOD - - End-User-Computing - - Security - - Hybrid-Work -sources: - - public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee -last_updated: 2026-05-11 ---- - -## BYOD（Bring Your Own Device） - -BYOD（自带设备）是一种企业工作模式，允许员工使用个人设备（笔记本、平板、手机）访问企业资源。[[AWS-End-User-Computing]] 将 BYOD 作为重要适用场景。 - -## Why BYOD Matters for EUC - -BYOD 对终端安全带来挑战： -- 数据可能存储在员工个人设备上 -- 设备安全状态不可控 -- 设备丢失/被盗风险 - -VDI/EUC 解决方案通过将工作负载保留在云端（数据不落盘到端点）来缓解这些风险。 - -## AWS EUC 支持 BYOD 的方式 - -| 服务 | BYOD 支持方式 | -|------|--------------| -| [[Amazon-Workspaces]] | 虚拟桌面在云端运行，数据不存储在个人设备 | -| [[AppStream-2]] | 应用流在云端运行，端点无数据残留 | -| [[Workspace-Web]] | 纯浏览器访问，无本地数据 | - -## Related Concepts -- [[AWS-End-User-Computing]] -- [[Virtual-Desktop-Infrastructure]] -- [[Zero-Trust-Access]] - -## Sources -- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]] diff --git a/wiki/concepts/Background-Job-Scheduling.md b/wiki/concepts/Background-Job-Scheduling.md deleted file mode 100644 index e0aaadf6..00000000 --- a/wiki/concepts/Background-Job-Scheduling.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Background-Job-Scheduling" -type: concept -tags: [] -sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend] -last_updated: 2026-05-02 ---- - -## Definition -Background Job Scheduling 是通过远程 API 管理定时和后台 Agent 任务的能力，使客户端无需长期保持连接即可触发和监控长时间运行的任务。 - -## Implementation in Hermes Agent -`/api/jobs` API 提供完整的 CRUD 接口： -- **Create**：创建定时任务或后台任务 -- **Read**：查询任务状态和结果 -- **Update**：修改任务参数或取消任务 -- **Delete**：删除任务 - -## Key Features -- **定时执行**：支持 cron 表达式或延迟执行 -- **状态追踪**：实时查询任务执行状态 -- **结果获取**：任务完成后可获取完整输出 -- **远程管理**：客户端无需保持连接 - -## Use Cases -- 定时报告生成 -- 批量数据处理 -- 定时通知发送 -- 后台数据同步 - -## Related -- [[OpenAI-Compatible-API]] -- [[Multi-Profile-Isolation]] diff --git a/wiki/concepts/Backlinks.md b/wiki/concepts/Backlinks.md deleted file mode 100644 index 18abe73f..00000000 --- a/wiki/concepts/Backlinks.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Backlinks（双向链接）" -type: concept -tags: [知识管理, 笔记系统, 图谱构建] -sources: - - "[[obsidian-官方-cli-命令全景速查表]]" -last_updated: 2026-04-28 ---- - -## Definition -**Backlinks（反向链接 / 双向链接）** 是一种笔记间的引用机制：当笔记 A 通过 `[[B]]` 链接到笔记 B 时，B 会自动生成一条指向 A 的反向链接记录，从而形成双向关系网络。 - -## Aliases -- 反向链接 -- Backlink -- Bidirectional Links -- 双向链接 -- Wikilinks -- `[[WikiLinks]]` - -## Core Mechanism -- **正向链接（Outgoing Links）**：从当前笔记指向其他笔记 -- **反向链接（Backlinks）**：其他笔记指向当前笔记的链接列表 -- Obsidian 在编辑器侧边栏自动展示 Backlinks 面板 - -## Key Commands (Obsidian CLI) -- `obsidian backlinks file=Index` — 列出指向目标文件的所有反向链接 -- `obsidian links file=Index` — 列出目标文件包含的所有出站链接 -- `obsidian move/rename` — 重命名/移动文件时 CLI 自动更新全库双链，绝不断链 -- `obsidian unresolved` — 提取未创建实体文件的死链接节点 - -## Value in Knowledge Management -- 构建知识图谱：揭示笔记间的隐性关联 -- 上下文追溯：通过反向链接顺藤摸瓜找到相关笔记 -- 支持本地 RAG：Agent 通过 `backlinks` + `read` 构建准确的背景知识库 -- 发现孤立笔记：`orphans` 命令找出没有被任何笔记引用的"死"笔记 - -## Related Concepts -- [[Zettelkasten]] — 双链是卡片盒笔记法的核心技术 -- [[Graph-View]] — 图谱视图可视化双链网络 -- [[Local-RAG]] — Backlinks + search:context 是本地 RAG 的关键组件 diff --git a/wiki/concepts/Baidu-Ecosystem-Integration.md b/wiki/concepts/Baidu-Ecosystem-Integration.md deleted file mode 100644 index 81c8433a..00000000 --- a/wiki/concepts/Baidu-Ecosystem-Integration.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: "Baidu Ecosystem Integration" -type: concept -tags: ["baidu", "content-strategy", "china-marketing", "authority-building"] -sources: [] -last_updated: 2026-04-26 ---- - -# Baidu Ecosystem Integration（百度生态矩阵整合） - -## Aliases -- Baidu Ecosystem Integration -- 百度生态整合 -- Baidu Platform Matrix -- 百度平台矩阵 -- Baidu Waimai（百度的外卖业务，非本概念） - -## Definition -百度生态矩阵整合是通过系统性地在百度自有平台（百科/知道/贴吧/文库/经验）创建和运营内容，建立品牌在百度搜索结果中的权威性的策略。百度对自己的平台有强烈的排名偏好，这些平台的内容往往占据品牌词搜索的黄金位置。 - -## 百度生态五大平台 - -### 1. 百度百科（Baidu Baike）— 权威建设者 -- **用途**：品牌百科词条，包含可验证的参考资料和引用 -- **优先级**：HIGH -- **排名特点**：通常在品牌词搜索中排名 #1 -- **策略**： - - 创建/优化品牌百科词条 - - 包含可验证的参考资料和引用 - - 持续维护，防范竞争对手编辑 - -### 2. 百度知道（Baidu Zhidao）— 问答可见性 -- **用途**：回答与品牌/产品相关的问题 -- **优先级**：HIGH -- **排名特点**：捕获问题意图搜索（how-to/what-is） -- **策略**： - - 埋设与品牌/产品相关的问题 - - 提供详细、有帮助的回答，巧妙提及品牌 - - 随时间积累回答者信誉分 - -### 3. 百度贴吧（Baidu Tieba）— 社区渗透 -- **用途**：建立或参与相关垂直社区 -- **优先级**：MEDIUM -- **排名特点**：对垂直社区 niche 关键词有良好覆盖 -- **策略**： - - 建立或参与相关贴吧社区 - - 通过有帮助的贡献建立自然存在感 - - 监控品牌提及和情感 - -### 4. 百度文库（Baidu Wenku）— 内容权威 -- **用途**：发布白皮书、指南、行业报告 -- **优先级**：MEDIUM -- **排名特点**：对信息型查询有良好排名 -- **策略**： - - 发布高质量文档 - - 优化文档标题和描述以利于搜索 - - 积累下载权威分 - -### 5. 百度经验（Baidu Jingyan）— How-To 可见性 -- **用途**：创建操作步骤指南类内容 -- **优先级**：MEDIUM -- **排名特点**：捕获 how-to 查询意图 -- **策略**： - - 创建分步骤教程内容 - - 包含截图和详细说明 - - 优化程序性搜索查询 - -## 整合原则 - -### 优先级原则 -- **HIGH**：百科（品牌词 #1 位置）和知道（问题意图） -- **MEDIUM**：贴吧（垂直社区）、文库（信息型）、经验（How-to） - -### 内容质量原则 -- 每个平台的内容必须真实有价值 -- 百科需要可验证的参考资料 -- 知道需要详细有帮助的回答 -- 禁止低质量灌水和关键词堆砌 - -### 差异化原则 -- 每个平台的内容应有差异化定位 -- 避免简单重复同一内容 -- 根据平台特性调整内容形式 - -## SEO 价值 - -**为什么百度生态整合重要：** -1. 百度对自己的平台有强烈的排名偏好 -2. 品牌词 + 百度生态 = 搜索结果黄金占位 -3. 多平台背书 = 品牌权威性信号 -4. 百度百科通常排名 #1，为品牌建立第一印象 - -## Related Sources -- [[Marketing-Baidu-SEO-Specialist]]：包含完整的百度生态整合策略框架 diff --git a/wiki/concepts/Baidu-SEO.md b/wiki/concepts/Baidu-SEO.md deleted file mode 100644 index 6e327c31..00000000 --- a/wiki/concepts/Baidu-SEO.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: "Baidu SEO" -type: concept -tags: ["baidu", "seo", "china-marketing", "search-engine"] -sources: [] -last_updated: 2026-04-26 ---- - -# Baidu SEO（百度搜索引擎优化） - -## Aliases -- Baidu SEO -- 百度 SEO -- Baidu Search Optimization -- 百度搜索优化 -- China SEO -- 中国 SEO - -## Definition -Baidu SEO 是针对百度搜索引擎的专项优化策略，与 Google SEO 在算法权重、技术要求和内容标准上存在根本差异。其核心挑战在于：百度有独立的算法体系、生态偏好和监管要求，Google SEO 经验不可直接迁移。 - -## Core Principles - -### 1. ICP 备案是前提（Non-Negotiable） -- 无有效 ICP 备案（ICP备案）的网站将被严重降权或完全排除出搜索结果 -- 这是法律要求，也是百度排名的前提条件 -- 所有 SEO 工作都必须建立在有效备案的基础上 - -### 2. 中国大陆托管是必要条件 -- 服务器必须位于中国大陆 -- 海外服务器会导致抓取延迟和排名惩罚 -- 推荐使用阿里云或腾讯云 CDN 加速 - -### 3. 内容必须原创 -- 百度对重复内容严厉惩罚（飓风算法） -- 原创性是排名的生命线 -- 禁止内容聚合和低质量采集 - -### 4. 移动优先 -- 百度移动搜索占比 80%+ -- 页面加载速度目标：< 2 秒（移动端 4G 网络） -- 必须使用自适应（Responsive）或动态服务（Dynamic Serving） - -### 5. 禁止 Google 服务 -- Google Analytics / Google Fonts / Google reCAPTCHA 在中国均不可访问 -- 必须替换为：百度统计、国内字体 CDN、腾讯防水墙等国内替代方案 - -## Technical SEO Checklist - -### 合规基础 -- [ ] ICP 备案状态：有效 -- [ ] 服务器位置：中国大陆 -- [ ] SSL 证书：国内 CA 颁发 -- [ ] 百度站长平台验证：已完成 -- [ ] 百度统计安装：已安装 - -### 技术优化 -- [ ] Baiduspider 抓取状态正常 -- [ ] 页面加载速度 < 2s（移动端） -- [ ] 移动适配：自适应/代码适配/跳转适配 -- [ ] XML Sitemap 已提交百度 -- [ ] 结构化数据：百度专属 JSON-LD Schema -- [ ] 无 Google 服务阻塞（所有资源替换为国内替代） - -## Baidu-Specific Tools - -| 工具 | 用途 | -|------|------| -| 百度站长平台 | 站点验证、Sitemap 提交、抓取诊断 | -| 百度统计 | 流量分析、用户行为、转化跟踪 | -| 百度指数 | 关键词搜索量趋势、人口统计 | -| 百度推广关键词规划师 | PPC 关键词量级估算 | -| 5118.com | 第三方关键词挖掘、竞品分析 | -| 站长工具（chinaz.com）| 关键词排名追踪 | - -## Relationship to Google SEO - -**核心差异：** -- Google SEO 经验是基础，但不是终点 -- 必须从零学习百度的算法体系、生态偏好和监管要求 -- ICP 备案、生态平台整合、中文分词优化等在 Google SEO 中不存在 -- 内容审查系统是百度独有的合规要求 - -## Related Sources -- [[Marketing-Baidu-SEO-Specialist]]：完整的百度 SEO 专家 Agent diff --git a/wiki/concepts/BandwidthManagement.md b/wiki/concepts/BandwidthManagement.md deleted file mode 100644 index eec28620..00000000 --- a/wiki/concepts/BandwidthManagement.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: "Bandwidth Management" -type: concept -tags: [networking, performance, multiplayer] -sources: [unity-multiplayer-engineer] -last_updated: 2026-04-26 ---- - -## Aliases -- Network Bandwidth Optimization -- 带宽管理 - -## Definition -带宽管理是在多人游戏中**控制网络流量**的技术和策略，目标是在有限的带宽下提供流畅的游戏体验。典型目标：每玩家稳态带宽 < 10KB/s。 - -## Core Techniques - -### 1. Dirty Check（脏值检查） -`NetworkVariable` 仅在值真正变化时触发同步，避免重复设置： -```csharp -// BAD: 每帧设置相同值 → 无意义网络流量 -void Update() { - Position.Value = transform.position; // 即使位置没变也同步！ -} - -// GOOD: 值真正变化才同步 -void FixedUpdate() { - if (Vector3.Distance(transform.position, lastPosition) > 0.01f) - { - Position.Value = transform.position; - lastPosition = transform.position; - } -} -``` - -### 2. Throttling（限流） -非关键状态更新频率限制： -- 生命值条：最高 1Hz -- 分数：最高 1Hz -- 位置同步：使用 NetworkTransform 而非每帧 NetworkVariable - -### 3. Delta Compression（差分压缩） -对复杂结构使用 `INetworkSerializable` 只同步增量： -```csharp -public struct ComplexState : INetworkSerializable -{ - public Vector3 position; - public Quaternion rotation; - // 只同步变化的部分 -} -``` - -### 4. Object Pooling（对象池） -NGO NetworkObject 的 spawn/despawn 成本高，对频繁创建的对象使用对象池复用。 - -## Performance Target -- 每玩家稳态带宽：< 10KB/s -- 峰值带宽（事件触发时）：< 50KB/s -- 同步延迟容忍：200ms 延迟下无明显卡顿 - -## Related Concepts -- [[NetworkVariable]]: 带宽管理的核心对象 -- [[ClientPrediction]]: 预测减少对服务器状态的依赖 -- [[UnityMultiplayerEngineer]]: 负责带宽优化的专家 diff --git a/wiki/concepts/Bearer-Token-Authentication.md b/wiki/concepts/Bearer-Token-Authentication.md deleted file mode 100644 index a5ab65f0..00000000 --- a/wiki/concepts/Bearer-Token-Authentication.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Bearer-Token-Authentication" -type: concept -tags: [] -sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend] -last_updated: 2026-05-02 ---- - -## Definition -Bearer Token Authentication 是一种 HTTP 认证机制，通过 `Authorization: Bearer ` 请求头传递令牌来验证 API 请求的合法性。 - -## Usage in Hermes Agent -Hermes Agent API Server 使用 Bearer Token 认证： -- **环境变量**：`API_SERVER_KEY` 设置认证密钥 -- **请求格式**：`Authorization: Bearer ` -- **适用场景**：任何调用 API Server 的客户端 - -## Security Notes -- 当 API Server 绑定到非 loopback 地址（如 `0.0.0.0`）时，必须配置 `API_SERVER_KEY` -- 默认绑定 `127.0.0.1:8642` 时仅本地访问可用，认证可选 - -## Related -- [[OpenAI-Compatible-API]] -- [[Multi-Profile-Isolation]] diff --git a/wiki/concepts/Beat-Sync.md b/wiki/concepts/Beat-Sync.md deleted file mode 100644 index d6de5c99..00000000 --- a/wiki/concepts/Beat-Sync.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Beat Sync" -type: concept -tags: [video-editing, audio, rhythm, short-video, music] -sources: [marketing-short-video-editing-coach] -last_updated: 2026-04-26 ---- - -## Aliases -- BGM节拍同步 -- 音画同步 -- Beat-Matching -- Rhythm Cutting - -## Definition -节拍同步（Beat Sync）是将视频剪辑点与背景音乐的节拍（重拍、重音）精确对齐的剪辑技术，目的是创造音画合一的视听冲击力。通过在 BGM 的关键节拍点切换镜头，让视觉节奏与听觉节奏完美同步。 - -## Implementation Method -1. **节拍标记**：通篇聆听 BGM，标记所有重拍/重音位置（downbeat/accent） -2. **视觉节拍对齐**：在重拍/重音处切点，创造音画同步的冲击力 -3. **情感同步**：将 BGM 的情感变化节点（intro→chorus、quiet→climax）与内容情绪变化对齐 - -## Key Principle -> "Not every beat needs a cut: sync to 'strong beats' and 'transition points' only; cutting on every beat causes rhythm fatigue" - -- 只需要在**强拍**和**转场点**同步 -- 每个节拍都切会导致节奏疲劳 - -## BGM Selection Principles -- 版权安全（使用平台音乐库或免版权音乐） -- 风格匹配（音乐情绪必须与内容基调一致） -- 音量控制（BGM 音量不得淹没人声） - -## Related Concepts -- [[Speed-Ramping]]：Beat Sync 与 Speed Ramping 协同——在节拍点加速/减速，增强音画一体感 -- [[Audio-Mix-Balance]]：BGM 音量必须低于人声，是 Beat Sync 的前提条件 -- [[marketing-short-video-editing-coach]] ← Beat Sync 是短视频剪辑的核心技术之一 - -## Source -[[marketing-short-video-editing-coach]] diff --git a/wiki/concepts/Behavioral-Analytics.md b/wiki/concepts/Behavioral-Analytics.md deleted file mode 100644 index f519b7b6..00000000 --- a/wiki/concepts/Behavioral-Analytics.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Behavioral Analytics" -type: concept -tags: [ux, behavioral-analytics, data-analysis, user-behavior, analytics] -sources: [design-ux-researcher.md] -last_updated: 2026-04-24 ---- - -## Definition - -Behavioral Analytics（行为分析）是一种通过收集、分析和解读用户在数字产品中的行为数据来识别使用模式、发现问题和优化机会的定量研究方法。是 UX Researcher Agent 在数字产品研究中的重要工具。 - -## Key Techniques - -| 技术 | 说明 | -|------|------| -| Event Tracking | 追踪用户关键行为事件（点击/导航/停留） | -| Funnel Analysis | 分析用户转化漏斗，识别流失点 | -| Cohort Analysis | 按用户群组分析行为差异 | -| Session Recording | 录制用户会话视频，还原真实行为 | - -## Metrics - -- **Activation Rate**：用户激活比例 -- **Engagement Rate**：用户参与度 -- **Retention Rate**：用户留存率 -- **Churn Rate**：用户流失率 - -## Relationship to Other Concepts - -- [[Qualitative-Quantitative-Research]]：行为分析是定量研究方法的具体应用 -- [[User-Journey-Mapping]]：行为数据分析支撑用户旅程地图的构建 -- [[User-Research-Methodology]]：行为分析是混合研究方法的数据支撑层 - -## Source - -- [[design-ux-researcher.md]] — UX Researcher Agent Personality diff --git a/wiki/concepts/Behavioral-Psychology.md b/wiki/concepts/Behavioral-Psychology.md deleted file mode 100644 index 2781025c..00000000 --- a/wiki/concepts/Behavioral-Psychology.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Behavioral Psychology" -type: concept -tags: [behavioral-science, psychology, motivation, habit-formation] -last_updated: 2026-04-20 ---- - -## Definition -行为心理学（Behavioral Psychology）研究可观察行为及其与环境刺激的关系，强调通过强化、条件反射和习惯回路来理解和改变人类行为。是 [[Behavioral Nudge Engine]] 的核心理论基础。 - -## Key Theories & Concepts -- **操作性条件反射**（B.F. Skinner）：行为结果强化/惩罚决定行为频率 -- **习惯回路**：暗示 → 惯常行为 → 奖励（Charles Duhigg 模型） -- **即时正强化**：比起延迟奖励，即时小奖励更能维持行为 -- **认知偏差**：默认偏差、现状偏差、可得性启发等影响决策的系统性偏差 -- **可变奖励机制**：间隔强化比固定强化更持久（如老虎机效应） - -## Applications in Software -- [[Gamification]]：积分、徽章、排行榜 -- [[Default Bias]]：预填、默认选项 -- [[Cognitive Load Reduction]]：减少认知摩擦维持行为 -- [[Habit Tracker & Accountability Coach]]：习惯追踪与问责机制 - -## Related Concepts -- [[Gamification]]：行为心理学在产品设计中的应用 -- [[Default Bias]]：行为偏见的具体表现 -- [[Momentum Nudge]]：即时正强化驱动的动量机制 - -## Source -- [[Behavioral Nudge Engine]] — 核心应用场景 diff --git a/wiki/concepts/Bidirectional-Linking.md b/wiki/concepts/Bidirectional-Linking.md deleted file mode 100644 index e61623c7..00000000 --- a/wiki/concepts/Bidirectional-Linking.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Bidirectional Linking" -type: concept -tags: [obsidian, knowledge-management, zettelkasten] -sources: [obsidian-高效指南-我常用的插件与实用技巧] -last_updated: 2025-03-01 ---- - -## Definition -笔记间双向关联的机制——当笔记 A 通过 `[[wikilink]]` 链接到笔记 B 时，笔记 B 自动显示对 A 的反向引用，形成双向关联网络。相比单向链接，天然支持"反向探索"。 - -## Core Mechanisms -- Wikilink 语法：`[[Note Title]]` 或 `[[Note Title|Display Text]]` -- Backlinks（反向链接）：显示所有链接到当前笔记的其他笔记 -- Graph View（关系图谱）：可视化整个笔记网络的拓扑结构 -- 别名（Aliases）：同一笔记可对应多个名称 - -## Implementations -- **Obsidian**：最广泛使用的双向链接工具，graph view 出色 -- **Roam Research**：双向链接的开创者之一 -- **Logseq**：大纲式双链工具，开源 -- **Notion**：有限的双向链接支持 -- **RemNote**：结合间隔重复的双链工具 - -## Why Bidirectional? -- **知识发现**：通过 backlinks 发现未知的关联笔记 -- **网络效应**：笔记越多，链接越多，发现价值越大 -- **无分类约束**：无需预先规划分类，链接自然形成结构 -- **写作辅助**：引用相关内容时自动建立关联 - -## Use Cases -- 构建个人知识库：通过链接串联相关概念 -- 写作索引页：汇总某一主题下的所有相关笔记 -- 论文写作：关联参考文献和笔记 -- 项目管理：通过双链连接任务、文档和决策 - -## Connections -- [[Zettelkasten]]：双向链接是 Zettelkasten 的核心基础设施 -- [[Personal Knowledge Base]]：双链是 PKB 的关键技术 -- [[Graph Knowledge Network]]：Graph View 是双链的可视化层 -- [[Obsidian]]：最流行的双链实现平台之一 - -## Sources -- [[obsidian-高效指南-我常用的插件与实用技巧]] diff --git a/wiki/concepts/Big-Five-Personality.md b/wiki/concepts/Big-Five-Personality.md deleted file mode 100644 index 9b6bfc00..00000000 --- a/wiki/concepts/Big-Five-Personality.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Big Five Personality" -type: concept -tags: [] -sources: ["academic-psychologist", "academic-narratologist"] -last_updated: 2026-04-20 ---- - -## Definition - -大五人格模型（Big Five Personality Traits），也称 OCEAN 模型，是当代人格心理学中最被广泛接受和实证验证的人格框架。五个核心维度： - -| 维度 | 高分特征 | 低分特征 | -|------|----------|----------| -| **Openness（开放性）** | 好奇心、想象力、创造力 | 务实、传统、保守 | -| **Conscientiousness（尽责性）** | 自律、组织性、可靠性 | 随意、松散、冲动 | -| **Extraversion（外向性）** | 社交、活力、果断 | 内向、安静、独立 | -| **Agreeableness（宜人性）** | 合作、信任、同理心 | 竞争、怀疑、冷淡 | -| **Neuroticism（神经质）** | 情绪不稳定、焦虑、敏感 | 情绪稳定、冷静、自信 | - -## Key References - -- **Eysenck**（Eysenck Personality Questionnaire）：大五人格先驱研究者 -- Costa & McCrae（NEO-PI-R）：五因素模型标准化测量工具 - -## Applications in Character Design - -- 每个特质高低组合产生独特行为模式（25种核心组合） -- Neuroticism × Extraversion 组合决定角色在压力下的公开/回避反应 -- Conscientiousness 是最强的工作/绩效行为预测因子 -- Openness 是创意角色和知识追求角色的核心特征 - -## Limitations - -- 描述性而非解释性（不说明特质来源） -- 西方文化中心主义（跨文化可重复性存在争议） -- 特质与行为之间存在情境调节变量 -- 不能预测具体行为，只能预测行为倾向 - -## Connections - -- [[Attachment-Theory]]（依恋风格与 Big Five 共享情绪调节维度） -- [[Psychological-Profile]]（Big Five 是角色心理画像的核心框架之一） -- [[Cognitive-Distortions]]（Neuroticism 高分个体更易出现认知扭曲） diff --git a/wiki/concepts/BigFive.md b/wiki/concepts/BigFive.md deleted file mode 100644 index 04aa0831..00000000 --- a/wiki/concepts/BigFive.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Big Five Personality Model" -type: concept -tags: [] -sources: [academic-psychologist] -last_updated: 2026-04-25 ---- - -# Big Five Personality Model - -## Aliases -- Big Five -- Five-Factor Model (FFM) -- OCEAN Model - -## Definition -人格五因素模型——通过五个正交维度系统性评估和描述人格特质，是当前人格心理学中最具实证支持的结构框架。 - -## Five Factors - -| 因素 | 高分特征 | 低分特征 | -|------|----------|----------| -| Openness（开放性） | 想象力、好奇心、艺术兴趣 | 务实、保守、按部就班 | -| Conscientiousness（尽责性） | 自律、组织、成就导向 | 随性、冲动、拖延 | -| Extraversion（外向性） | 社交、活力、寻求刺激 | 内向、安静、低社交需求 | -| Agreeableness（宜人性） | 信任、合作、利他、谦逊 | 竞争、怀疑、自利 | -| Neuroticism（神经质） | 焦虑、情绪不稳定、脆弱 | 情绪稳定、抗压、适应性强 | - -## Application in Character Design -Psychologist Agent 使用 Big Five 评估角色特质时，要求每个特质必须有对应的**行为表现**（behavioral manifestation），而非抽象标签。 - -## Connection to Wiki -- Source: [[academic-psychologist]] diff --git a/wiki/concepts/BindMount.md b/wiki/concepts/BindMount.md deleted file mode 100644 index f43cb288..00000000 --- a/wiki/concepts/BindMount.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Bind Mount" -type: concept -tags: [docker, storage, development] -last_updated: 2026-04-17 ---- - -## Aliases -- Bind Mount -- 绑定挂载 -- Host Volume Mount - -## Definition -Docker 中将宿主机的特定目录或文件直接映射到容器内部的一种挂载方式。与命名卷（Named Volume）不同，绑定挂载使用宿主机上的绝对路径，使容器内外的文件系统保持同步，实现代码修改实时生效。 - -## Use Cases -- **开发环境**：代码文件频繁变更，绑定挂载实现宿主机编辑 → 容器即时生效的热重载 -- **配置文件**：将 nginx.conf、.env 等配置文件挂载进容器，方便实时调整 -- **日志收集**：将容器日志目录挂载到宿主机，实现日志持久化和集中管理 - -## Syntax -```yaml -# docker-compose.yml -services: - app: - volumes: - - /home/user/project/src:/app/src # 宿主机路径:容器路径 - - ./config:/app/config # 相对路径（相对于 compose 文件位置） -``` - -## Trade-offs -| 优点 | 缺点 | -|------|------| -| 代码修改实时生效 | 依赖宿主机文件系统结构 | -| 无需数据迁移 | 权限问题（UID/GID 不匹配）| -| 便于调试和热重载 | 生产环境不推荐使用 | - -## Related Concepts -- [[Docker Volume]]：命名卷，适合生产环境的数据持久化 -- [[Remote Development]]：远程开发中使用 Bind Mount 实现代码同步 -- [[Docker Compose]]：通过 YAML 定义 Bind Mount 配置 - -## Related Entities -- [[Docker]]：Bind Mount 的实现平台 -- [[Trae]]：通过 Remote-SSH 连接远程服务器，编辑 Bind Mount 挂载的代码 - -## References -- [[Trae远程开发部署指南]] — 开发环境 docker-compose.yml 使用 Bind Mount 实现代码热重载 diff --git a/wiki/concepts/BlamelessPostMortem.md b/wiki/concepts/BlamelessPostMortem.md deleted file mode 100644 index d0ce4c13..00000000 --- a/wiki/concepts/BlamelessPostMortem.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: "Blameless Post-Mortem" -type: concept -tags: [reliability, incident-management, culture] -last_updated: 2026-05-01 ---- - -## Definition -无责复盘（Blameless Post-Mortem）是一种以系统性视角分析事故的方法——归因于系统缺陷和流程缺口，而非个人错误。其核心原则：**"The system allowed this failure mode"**（系统允许了这种失败模式的存在），而非"X 人员导致了故障"。 - -## Core Principles - -### 1. 聚焦系统，不追责个人 -- **错误框架**："X 人员没有检查配置" -- **正确框架**："系统没有强制执行配置验证流程" -- 关键问题："系统缺少什么护栏/告警/测试，才让这个缺陷通过了？" - -### 2. 5 Whys 根因分析 -通过连续追问找到系统性根本原因： -1. 为什么服务宕机了？→ 配置文件错误 -2. 为什么配置文件错误？→ 变更审批未发现 -3. 为什么未发现？→ 没有自动化配置校验测试 -4. 为什么没有配置校验测试？→ 优先级未排入迭代 -5. 为什么未排入迭代？→ **系统根因**：没有将配置变更纳入质量门槛流程 - -### 3. 事实记录，时序重建 -- 按 UTC 时间重建完整事故时间线（从检测到恢复到后续跟进） -- 记录实际采取的行动，而非"应该"采取的行动 -- 区分缓解措施（止血）和根因修复（治本） - -### 4. 平衡"做得好的"和"做得差的" -- **What Went Well**：有效的流程、工具和团队协作 -- **What Went Poorly**：拖慢检测或恢复的缺口 - -### 5. 行动项必须有跟踪 -- 每次复盘必须有具体行动项（Action Items） -- 每个行动项：清晰的描述 + 负责人 + 优先级 + 截止日期 -- 无跟进行动项的复盘 = 只是会议 - -## Post-Mortem Document Structure - -```markdown -# Post-Mortem: [Incident Title] - -**Date**: YYYY-MM-DD -**Severity**: SEV[1-4] -**Duration**: [start] – [end] ([total]) -**Author**: [name] -**Status**: [Draft / Review / Final] - -## Executive Summary -[2-3句话：发生了什么、影响谁、如何解决] - -## Impact -- Users affected: [数量或百分比] -- Revenue impact: [估算或 N/A] -- SLO budget consumed: [月度错误预算消耗百分比] - -## Timeline (UTC) -| Time | Event | -|-------|-------| -| 14:02 | Monitoring alert fires: API error rate > 5% | -| 14:05 | On-call engineer acknowledges page | -| ... | ... | - -## Root Cause Analysis -### What happened -[详细技术解释] - -### Contributing Factors -1. **Immediate**: [直接触发原因] -2. **Underlying**: [为什么触发成为可能] -3. **Systemic**: [组织/流程层面的缺口] - -### 5 Whys -1. Why...? → [answer] -2. ... - -## What Went Well -- - -## What Went Poorly -- - -## Action Items -| ID | Action | Owner | Priority | Due | Status | -|----|--------|-------|----------|-----|--------| -| 1 | ... | @team | P1 | ... | Open | - -## Lessons Learned -[对未来架构和流程决策的启示] -``` - -## Key Rules - -| 规则 | 说明 | -|------|------| -| 48 小时原则 | 事故解决后 48 小时内必须启动复盘（趁记忆鲜活） | -| 心理安全 | 参与者必须感到安全，不能因发言而受到惩罚 | -| 文档公开 | 复盘文档全公司可见，知识共享 | -| 季度复盘 | 回顾过去季度的事故趋势，识别系统性风险 | - -## Related Concepts -- [[DORA-Metrics]] — 通过 MTTD、MTTR 等指标量化可靠性 -- [[DevOpsCulture]] — 无责文化是 DevOps 的核心支柱之一 -- [[Rollback-Rate]] — 回滚分析是复盘的重要输入 -- [[FiveWhys]] — 5问法是复盘根因分析的经典工具 - -## Sources -- [[engineering-incident-response-commander]] diff --git a/wiki/concepts/Blast-Radius.md b/wiki/concepts/Blast-Radius.md deleted file mode 100644 index b490ab6d..00000000 --- a/wiki/concepts/Blast-Radius.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: "Blast Radius" -type: concept -tags: [Security, AWS, IAM, Risk-Management, Architecture] -sources: - - ctp-topic-16-cross-account-terraform-modules.md - - ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md -last_updated: 2026-05-15 ---- - -## Overview - -Blast Radius（爆炸半径）是一个安全概念，描述在云基础设施中某个组件（如一个 AWS 账号）被攻破或出现故障时，其影响范围的大小。**目标是最小化爆炸半径**，确保单个组件的问题不会波及其他系统。 - -## In AWS Multi-Account Architecture - -在 AWS Landing Zone 多账号架构中，Blast Radius 控制是核心设计原则： - -### Without Blast Radius Control（高风险） - -``` -Workload Account A - ↓ 直接互信 -Workload Account B - -风险：Account A 被攻破 → Account B 同时沦陷 -``` - -### With Blast Radius Control（推荐架构） - -``` -Workload Account A - ↓ (受限) -[[Shared-Account]] - ↓ (受限) -Workload Account B - -风险：Account A 被攻破 → 仅影响与 Shared Account 的受限连接 - Shared Account → Account B 的连接受独立角色控制 -``` - -## Key Mechanisms - -| 机制 | 说明 | -|------|------| -| **独立账号隔离** | 每个 Workload 独立账号，无直接互信 | -| **最小权限角色** | [[TF-State-Bucket-Accessor]] 和 [[Cross-account-ECS-Deploy-Runner-Role]] 仅授予最小必要权限 | -| **Assume Role 临时凭证** | 无长期凭证泄露风险 | -| **审计追踪** | CloudTrail 记录所有跨账号操作 | - -## Blast Radius vs. Blast Width - -- **Blast Radius**：组件被攻破时的**潜在影响范围** -- **Blast Width**：跨账号直接信任连接的**数量和密度** - -降低 Blast Radius 的策略： -1. 减少账号间的直接信任关系 -2. 使用 Shared Account 作为唯一信任中介 -3. 实施最小权限原则 -4. 定期轮换 IAM 角色凭证 - -## Relationships - -- [[Shared-Account]] ← enables ← [[Blast-Radius-Control]] -- [[Cross-account-Terraform-Modules]] ← secures_via ← [[Blast-Radius]] -- [[Assume-Role]] ← minimizes ← [[Blast-Radius]] -- [[AWS-Landing-Zone]] ← designed_for ← [[Blast-Radius-Control]] - -## Related Concepts - -- [[IAM-Policy]]：最小权限是控制 Blast Radius 的工具 -- [[Cross-account-Terraform-Modules]]：Blast Radius 控制是该方案的核心安全价值 -- [[Assume-Role]]：临时凭证机制是控制 Blast Radius 的关键技术 diff --git a/wiki/concepts/Blended-Learning.md b/wiki/concepts/Blended-Learning.md deleted file mode 100644 index 4cf1ce86..00000000 --- a/wiki/concepts/Blended-Learning.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Blended Learning" -type: concept -tags: [learning-strategy, instructional-design] -sources: [corporate-training-designer] -last_updated: 2026-05-29 ---- - -## Definition - -Blended Learning（OMO，Online-Merge-Offline，线上线下融合学习）是将线上学习与线下面对面教学有机结合的学习模式，按照"知道→做到→持续"的认知规律分配学习场景，实现学习效果最大化。 - -## Three-Layer Model - -### 线上 — "知道"（Knowing） -- 知识传递：微课视频、文档阅读、在线测验 -- 特点：可随时随地学习，支持碎片化时间利用 -- 微课程规范：5-15分钟一门课，解决一个问题，结构清晰（痛点导入→知识传递→案例演示→要点总结） - -### 线下 — "做到"（Doing） -- 深度实践：小组讨论、角色扮演、沙盘模拟、动手练习 -- 特点：在安全环境中犯错误、即时反馈、行为强化 -- 场景类型：商业决策沙盘、项目管理沙盘、供应链沙盘等 - -### 学习社群 — "持续"（Sustaining） -- 持续巩固：学习社区、答疑辅导、经验分享、行动学习 -- 特点：将一次性培训转化为持续学习行为 - -## Key Platforms（中国企业） -- [[DingTalk-Learning]]（钉钉学习）：适合阿里巴巴生态企业，与钉钉 OA 深度集成 -- [[WeCom-Learning]]（企业微信学习）：适合微信生态企业，嵌入公众号和小程序 -- [[Feishu-Knowledge-Base]]（飞书知识库）：适合字节跳动生态和知识管理导向组织 -- [[UMU]]：混合学习领域领先者，支持 AI 练习搭档、视频作业、丰富互动功能 -- [[Yunxuetang]]（云学堂）：大中型企业一站式学习平台 - -## Instructional Design Principles -- **场景匹配**：知识类内容适合线上，技能类内容必须线下实践 -- **认知负荷控制**：线上微课控制在15分钟以内；线下培训每90分钟安排互动或休息 -- **行为迁移设计**：每次线下练习必须设计行为迁移任务，确保学员回去能用 - -## Connections -- [[Blended-Learning]] ← learning_strategy ← [[Corporate-Training-Designer]]（培训设计师的核心交付模式） -- [[Flipped-Classroom]] ← practice_application ← [[Blended-Learning]]（翻转课堂是混合学习的一种实践形式） -- [[Kolbs-Learning-Cycle]] ← theoretical_basis ← [[Blended-Learning]]（Kolb 体验学习圈为混合学习的场景分配提供理论依据） -- [[Blended-Learning]] ← platform_infrastructure ← [[Blended-Learning-Platform]]（学习平台是混合学习的技术支撑） diff --git a/wiki/concepts/Blocking.md b/wiki/concepts/Blocking.md deleted file mode 100644 index 39313163..00000000 --- a/wiki/concepts/Blocking.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Blocking" -type: concept -tags: ["identity-resolution", "performance", "algorithm", "entity-matching"] -sources: ["identity-graph-operator"] -last_updated: 2026-04-25 ---- - -# Blocking（阻塞/分块） - -## Definition -身份解析中的候选对筛选技术——通过预计算的 **blocking key** 将全量 O(n²) 记录对比较减少为可控规模候选集的 O(n×k) 操作，是大规模实体解析的性能关键。 - -## Blocking Key Types - -| 类型 | 示例 | 适用场景 | -|------|------|----------| -| Email Domain | `acme.com` | 同一公司账号 | -| Phone Prefix | `+1555` | 同一地区号码 | -| Name Soundex | `S530` | 语音相似姓名（Williams→W452） | -| Postal Code | `94105` | 同一地理区域 | -| Composite | email_domain + name_soundex | 联合分块，减少假阳性 | - -## Workflow - -``` -全量记录 - ↓ -为每条记录生成 blocking key(s) - ↓ -按 blocking key 分组（分块） - ↓ -仅对同组记录对进行 pairwise scoring - ↓ -跨块记录对被阻塞（不比较） -``` - -## Design Considerations -- **召回率 vs 性能**：blocking key 越宽松 → 更多候选对 → 更高召回率但更慢；越严格 → 更少候选对但可能遗漏真匹配 -- **假阴性风险**：两个同实体但 blocking key 不同（如 "gmail.com" vs "googlemail.com"）会跨块遗漏 -- **假阳性成本**：同块内异实体（如同名不同人的 "John Smith"）需靠 scoring 层排除 - -## Relationship to Related Concepts -- [[Blocking]] 是 [[Identity Resolution]] 的性能优化组件，通过牺牲少量召回率换取大规模场景可接受的计算成本 -- [[Fuzzy-Matching]] 在 Blocking 筛选出的候选对上执行细粒度评分 -- [[Confidence-Score]] 综合 Blocking + Scoring 的结果给出最终合并决策 diff --git a/wiki/concepts/Blockout-Discipline.md b/wiki/concepts/Blockout-Discipline.md deleted file mode 100644 index b077d59b..00000000 --- a/wiki/concepts/Blockout-Discipline.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Blockout Discipline" -type: concept -tags: [] -last_updated: 2026-04-26 ---- - -## Definition - -灰盒纪律（Blockout Discipline）是关卡设计中强制执行的开发流程规范——**设计决策必须在灰盒阶段锁定**，未经灰盒 playtest 验证的布局不得进行美术包装。 - -## Three Phases - -### Phase 1: Blockout（灰盒） -- 仅使用无纹理的几何体构建关卡 -- 立即 playtest——灰盒不可读，美术救不了 -- 验证：新玩家能否在无地图情况下导航？ -- **设计决策在此阶段锁定** - -### Phase 2: Dress（美术） -- 在已验证的灰盒基础上添加美术资产 -- 标注哪些几何体是 gameplay-critical（不可改变形状）vs. 纯装饰性 -- 记录每个区域的预期光照方向和色温 - -### Phase 3: Polish（打磨） -- 添加环境叙事道具 -- 验证音效是否支持节奏弧线 -- 使用全新玩家进行最终 playtest——测量时不提供任何帮助 - -## Core Rule -> "Never art-dress a layout that hasn't been playtested as a grey box." - -## Metric -- 100% 的 playtest 参与者在无提示的情况下完成关键路径导航 -- 节奏图表与实际 playtest 时间误差在 20% 以内 - -## Related Concepts -- [[Level Designer Agent Personality]]：Blockout Discipline 是 Level Designer 的强制规则 -- [[Encounter Design]]：Encounter tuning 在灰盒阶段完成 -- [[Pacing Architecture]]：节奏验证基于灰盒 playtest 数据 - -## Sources -- [[Level Designer Agent Personality]] diff --git a/wiki/concepts/Bloom-Taxonomy.md b/wiki/concepts/Bloom-Taxonomy.md deleted file mode 100644 index 446232b0..00000000 --- a/wiki/concepts/Bloom-Taxonomy.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "Bloom Taxonomy" -type: concept -tags: [cognitive-theory, learning-objectives] -sources: [corporate-training-designer] -last_updated: 2026-05-29 ---- - -## Definition - -Bloom 认知分类法（Blooms Taxonomy）由 Benjamin Bloom 等人于 1956 年提出，是一种按认知复杂度排序的学习目标分类体系，包含六个层级（记忆→理解→应用→分析→评价→创造），用于设计学习目标和评估标准。 - -## Six Levels - -### Level 1 — Remember（记忆） -- 识别、回忆事实性信息 -- 关键词：列出、定义、命名、辨认 -- 示例：列举企业培训的五种常见形式 - -### Level 2 — Understand（理解） -- 解释信息的含义 -- 关键词：总结、解释、举例、分类 -- 示例：用自己的话解释 ADDIE 模型的五个阶段 - -### Level 3 — Apply（应用） -- 将知识用于新情境 -- 关键词：执行、使用、演示、解决 -- 示例：在给定的业务场景中，选择合适的教学策略 - -### Level 4 — Analyze（分析） -- 区分整体与部分，理解各部分之间的关系 -- 关键词：比较、对比、分解、辨别 -- 示例：分析某培训课程失败的原因，找出关键要素 - -### Level 5 — Evaluate（评价） -- 基于标准做出判断 -- 关键词：评价、批判、选择、支持 -- 示例：评估两种教学设计方案的优劣 - -### Level 6 — Create（创造） -- 将要素重组为新结构 -- 关键词：设计、构建、创造、制定 -- 示例：设计一套完整的新员工培训方案 - -## Applications in Training Design -- **学习目标撰写**：使用 Bloom 动词明确每个学习目标的认知层级 -- **评估设计**：根据 Bloom 层级设计相应的评估方式（记忆→选择题；应用→案例分析；创造→方案设计） -- **内容深度把控**：确保课程内容覆盖多个认知层级，而不仅是最低层级的"知识灌输" - -## Connections -- [[Bloom-Taxonomy]] ← learning_objective_framework ← [[ADDIE-Model]]（ADDIE 的设计阶段使用 Bloom 分类定义学习目标） -- [[Bloom-Taxonomy]] ← cognitive_level ← [[Kirkpatrick-Model]]（Bloom 定义"学到什么层级"，Kirkpatrick 验证"是否真的学到了"） -- [[Corporate-Training-Designer]] ← uses ← [[Bloom-Taxonomy]]（培训设计师必须掌握的核心教学设计工具） diff --git a/wiki/concepts/Bloom-认知分类.md b/wiki/concepts/Bloom-认知分类.md deleted file mode 100644 index 2bc84614..00000000 --- a/wiki/concepts/Bloom-认知分类.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Bloom 认知分类" -type: concept -tags: [] -last_updated: 2026-04-25 ---- - -## Definition - -Bloom 认知分类（Bloom's Taxonomy）是由 Benjamin Bloom 等人于 1956 年提出的教育目标分类框架，将学习认知过程分为六个递进层次： - -1. **Remember（记忆）**：识记、回忆基本事实——定义、列表、复述 -2. **Understand（理解）**：解释概念含义——总结、分类、解释原因 -3. **Apply（应用）**：将知识运用于新情境——执行、操作、解决问题 -4. **Analyze（分析）**：拆解复杂结构——区分、组织、归因 -5. **Evaluate（评价）**：基于标准做判断——检查、批判、论证 -6. **Create（创造）**：整合元素形成新结构——设计、建构、发明 - -## Aliases -- Bloom's Taxonomy -- Bloom 认知分类 -- Bloom 教育目标分类 -- 布鲁姆认知分类 - -## Key Characteristics - -- **递进性**：从低阶思维（记忆/理解）到高阶思维（分析/评价/创造） -- **教学设计应用**：每个层次对应不同的学习活动和评估方式 - - 低阶目标 → 讲授、阅读、测验 - - 高阶目标 → 案例分析、项目实践、创作展示 -- **逆向设计**：从期望的认知层次出发，设计学习活动和评估 - -## Related Concepts - -- [[ADDIE-Model]]：Bloom 分类是 ADDIE Design 阶段学习目标定义的核心工具 -- [[Kirkpatrick-四级评估]]：学习活动的认知层次影响 Level 2 评估方法的选择 - -## Source - -- [[corporate-training-designer]] diff --git a/wiki/concepts/Blue-Green-Deployment.md b/wiki/concepts/Blue-Green-Deployment.md deleted file mode 100644 index 5e8f4d3c..00000000 --- a/wiki/concepts/Blue-Green-Deployment.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Blue-Green Deployment" -type: concept -tags: - - AWS - - Aurora - - Database - - Deployment - - Release Management -sources: - - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora -last_updated: 2026-04-23 ---- - -## Overview -Blue-Green Deployment（蓝绿部署）是一种零停机部署策略，通过维护两套相同环境（Blue 和 Green）实现快速、平滑的版本切换，最小化部署风险。 - -## How It Works -1. **Blue 环境**：当前生产环境 -2. **Green 环境**：与 Blue 完全相同的新版本副本 -3. **部署过程**： - - 在 Green 环境部署和验证新版本 - - 验证通过后，将流量从 Blue 切换到 Green - - Blue 环境保留作为即时回滚的备用 - -## Aurora Blue-Green Deployment -Aurora MySQL 支持数据库层的 Blue-Green Deployment，用于 Major Version Upgrade（Maj-Vu）： -- **原理**：通过逻辑复制（基于 Binlog）将 Blue 环境的变更同步到 Green 环境 -- **Guardrails**：内置保护机制防止数据丢失 -- **限制**：仅 Aurora MySQL 支持；**Aurora PostgreSQL 不支持** - -### vs Traditional Database Upgrade -| 方式 | 停机时间 | 风险 | 数据保护 | -|------|---------|------|---------| -| In-place Major Upgrade | 分钟级，取决于数据大小 | 高，需执行升级脚本 | 依赖备份 | -| Blue-Green Deployment | 接近零 | 低，可即时回滚 | 自动保护 | - -## Related Concepts -- [[Canary Deployment]]：渐进式流量分配，另一种低风险部署策略 -- [[Amazon Aurora]]：Aurora MySQL 支持 Blue-Green Deployment -- [[Amazon RDS]]：RDS PostgreSQL 不支持 Blue-Green Deployment -- [[Release Management]]：蓝绿部署属于发布管理的工具之一 -- [[RTO]]：Blue-Green Deployment 可将数据库升级的 RTO 降至接近零 - -## Aliases -- Blue-Green -- Blue Green Deployment -- 蓝绿部署 -- 双环境部署 -- Zero-Downtime Deployment diff --git a/wiki/concepts/Blue-Hat-Logo.md b/wiki/concepts/Blue-Hat-Logo.md deleted file mode 100644 index a5fb8cdc..00000000 --- a/wiki/concepts/Blue-Hat-Logo.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Blue Hat Logo（蓝帽子标识）" -type: concept -tags: [healthcare, compliance, supplement, china] -sources: [healthcare-marketing-compliance] -last_updated: 2026-04-25 ---- - -## Definition -"蓝帽子"（保健食品专用标志，保健食品专有标志的俗称）是经国家市场监督管理总局（SAMR）批准注册的保健食品专属标识。合法保健食品必须取得并展示蓝帽子标志，否则不得以保健食品名义进行销售或推广。 - -## Legal Requirements -- 保健食品须经 SAMR 注册审批或完成备案 -- 须在产品包装及营销材料中展示蓝帽子标志和批准文号 -- 无蓝帽子标志的产品不得以"保健食品"名义推广 - -## Marketing Restrictions -### 允许范围 -- 24项经批准保健功能声称（如：增强免疫力、辅助降血脂、辅助降血糖、改善睡眠等） -- 必须使用标准化功能声称语言（如"辅助降血脂"而非"降血脂"） -- 必须标注："保健食品不是药物，不能替代药物治疗疾病" - -### 禁止事项 -- 声称治疗功能（"治愈疾病""代替药物"） -- 使用医疗术语（"治愈""治疗""保证康复"） -- 超出批准保健功能范围宣传 -- 功效与药品比较或暗示替代关系 -- 夸大宣传或虚假功效声称 - -## Compliance Risk -> "保健食品不得声称具有治疗功能——这是行业内处罚最高频的违规原因。" — SAMR 合规统计 - -违规后果：罚款 + 产品下架 + 媒体曝光 - -## Key Distinction -| 类别 | 标识要求 | 功能声称 | 法律定性 | -|------|----------|----------|----------| -| 保健食品 | 须展示蓝帽子 | 24项批准功能范围内 | 食品，非药品 | -| 药品 | 须展示批准文号 | 治疗适应症 | 药品 | -| 普通食品 | 无特殊标识 | 不得声称保健功能 | 食品 | - -## Related Concepts -- [[Healthcare-Marketing-Compliance]]：蓝帽子管理是医疗营销合规的组成部分 -- [[SAMR]]：蓝帽子注册审批由 SAMR 负责 -- [[Compliance-Risk-Matrix]]：无蓝帽子宣传保健功能属 High Risk 级别 diff --git a/wiki/concepts/Brain-Dump.md b/wiki/concepts/Brain-Dump.md deleted file mode 100644 index 17cd939e..00000000 --- a/wiki/concepts/Brain-Dump.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Brain Dump" -type: concept -tags: [knowledge-management, agent-memory, prompting] -sources: [overnight-mini-app-builder, second-brain] -last_updated: 2026-04-22 ---- - -## Definition - -Brain Dump（脑暴倾倒）是一种将所有目标、使命、任务和上下文一次性倒入 AI Agent 记忆系统的操作方式。目的是给 Agent 足够的背景信息，使其能够自主生成高质量的每日可执行任务，而非被动等待指令。 - -## Aliases - -- 脑暴倾倒 -- 目标倾倒 -- Context Injection - -## How It Works - -用户通过消息/短信/Telegram 将所有目标一次性告诉 Agent： - -```text -Here are my goals and missions. Remember all of this: - -Career: -- Grow my YouTube channel to 100k subscribers -- Launch my SaaS product by Q3 -- Build a community around AI education - -Personal: -- Read 2 books per month -- Learn Spanish - -Business: -- Scale revenue to $10k/month -- Build partnerships with 5 companies in my space -- Automate as much of my workflow as possible - -Use this context for everything you do going forward. -``` - -## Key Insight - -> "The brain dump is everything. The more context you give about your goals, the better the agent's daily tasks will be." - -Brain Dump 是整个 [[overnight-mini-app-builder]] 工作流中**最重要的一步**。它决定了 Agent 每日任务的相关性和价值。 - -## Relationship to Second Brain - -- [[Second Brain]] — Brain Dump 是 Second Brain 捕获阶段的具体实践方式 -- [[overnight-mini-app-builder]] — 将 Brain Dump 作为自主任务生成的上下文输入 -- [[Cumulative Memory]] — Brain Dump 产生的上下文被 [[OpenClaw]] 永久记忆，随时间积累 - -## Key Relationships - -- [[Cumulative Memory]] — Brain Dump 产生的上下文被 Agent 永久记忆 -- [[Second Brain]] — Brain Dump 是 Second Brain 捕获零摩擦理念的具体操作 -- [[Zero-Friction Capture]] — Brain Dump 强调用最自然的方式（发消息）完成捕获 -- [[overnight-mini-app-builder]] — 本概念的来源场景 diff --git a/wiki/concepts/Branch-Strategy.md b/wiki/concepts/Branch-Strategy.md deleted file mode 100644 index 8ffb4684..00000000 --- a/wiki/concepts/Branch-Strategy.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Branch Strategy" -type: concept -tags: ["git", "workflow", "delivery-traceability"] -last_updated: 2026-04-25 ---- - -## Definition - -Branch Strategy（分支策略）是一套基于变更类型的分支分层管理模型，通过规范化分支命名和来源规则，确保各类型的代码变更在正确的上下文中开发、审查和合并。 - -## Branch Types - -| 类型 | 模式 | 来源分支 | 目标分支 | 典型场景 | -|------|------|----------|----------|----------| -| Feature | `feature/JIRA-ID-description` | develop | develop | 新产品或平台功能 | -| Bugfix | `bugfix/JIRA-ID-description` | develop | develop | 非关键缺陷修复 | -| Hotfix | `hotfix/JIRA-ID-description` | main | main | 关键生产环境修复 | -| Refactor | `feature/JIRA-ID-description` | develop | develop | 结构清理（需关联 Jira 任务） | -| Docs | `feature/JIRA-ID-description` | develop | develop | 文档更新（需关联 Jira 任务） | -| Tests | `bugfix/JIRA-ID-description` | develop | develop | 回归测试（需关联 Jira 任务） | -| Config | `feature/JIRA-ID-description` | develop | develop | 配置或工作流策略变更 | -| Dependencies | `bugfix/JIRA-ID-description` | develop | develop | 依赖或平台升级 | -| Release | `release/version` | develop | main | 发布准备 | - -## Protected Branches - -- `main`：始终生产就绪；所有合并必须经过 PR review -- `develop`：持续集成的集成分支；feature/bugfix 从其拉取 -- `release/*`：发布准备分支；仍需关联 release ticket 或变更控制项 - -## Relationship to Other Concepts - -- [[Atomic-Commit]]：在 branch 内部进一步原子化 commit -- [[Jira-Git-Traceability]]：每个 branch 必须包含 Jira ID 作为唯一标识 -- [[Jira-Gate]]：branch 创建前必须验证 Jira Task 存在 - -## Sources -- [[project-management-jira-workflow-steward]] diff --git a/wiki/concepts/Branching-Narrative.md b/wiki/concepts/Branching-Narrative.md deleted file mode 100644 index 2c612e27..00000000 --- a/wiki/concepts/Branching-Narrative.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Branching Narrative" -type: concept -tags: [game-narrative, branching-design, choice-architecture] -sources: [narrative-designer.md] -last_updated: 2026-04-26 ---- - -# Branching Narrative - -游戏分支叙事设计——通过选择树结构实现有意义叙事分支的设计方法论。 - -## Definition - -Branching Narrative 是一种通过预先定义的选择树结构，让玩家的决策影响故事走向的叙事设计范式。核心挑战在于：如何让选择真正有意义，同时确保所有分支最终收敛而不产生无法维护的指数级内容爆炸。 - -## Core Principles - -### 有意义选择的标准 -- **类型不同，非程度不同**："I'll help you" vs. "I'll help you later" 不是有意义的选择——两者只是在时间维度上有差异 -- **选择必须涉及不同的价值观**：玩家在不同的价值体系之间做出取舍，而非同一目标的快慢之分 -- **后果必须在 2 个场景内可感知**：玩家选择后，必须在近期内看到结果，否则选择失去意义 - -### 分支收敛策略 -- 所有分支必须最终收敛（除非有明确的设计理由不收敛） -- 收敛不应显得生硬——通过共同的逻辑基础实现自然合并 -- Dead ends（死路）需要明确的叙事理由，不能因为结构设计失误导致 - -### 节点映射（Node Mapping） -- 在写任何对话之前，必须先完成分支节点地图 -- 每个节点需要标注：输入条件、玩家选择列表、各分支后续节点、收敛点 -- 禁止在未完成节点映射的情况下直接写对话 - -## Key Metrics -- **分支密度**：每个主要决策点的平均分支数量（通常 2-4 个） -- **收敛率**：从任何分支回溯到主线的平均步骤数 -- **后果可见性**：玩家感知后果的平均延迟（目标：≤ 2 scenes） - -## Related Concepts -- [[Character Voice Pillars]]：分支选择的可信度依赖角色声音的一致性 -- [[Choice Architecture]]：选择架构定义了何时使用真选择，何时使用 Fake Choice -- [[Lore Architecture]]：分支可能通向不同深度的 Lore 层 - -## Sources -- [[Narrative Designer Agent Personality]] — Branching Design Standards diff --git a/wiki/concepts/Brand-Environment.md b/wiki/concepts/Brand-Environment.md deleted file mode 100644 index 9b319331..00000000 --- a/wiki/concepts/Brand-Environment.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Brand-Environment" -type: concept -tags: [branding, content-creation, strategy] -sources: [if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间] -last_updated: 2026-04-27 ---- - -## Aliases -- 品牌即环境 -- 品牌环境 -- 品牌世界观 - -## Definition -品牌不是你放在个人简介里的一张头像，而是一个让人们前来寻求转变的"小世界"。是读者关注你 3-6 个月后在脑海中积累的整体印象的总和。 - -[[if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间]] 核心主张： - -> "你的品牌就是你的故事。" - -## What Makes Up a Brand Environment -每个接触点都在塑造这个"小世界"： -- Banner（横幅）、头像、个人简介 -- 简介中的链接、落地页设计 -- 置顶内容、帖子、话题串 -- 新闻简报、视频 - -## How to Discover Your Brand -1. 花一天时间写下你的出身、人生低谷、经历和技能，以及这些如何帮助你 -2. 用你的故事筛选创意、内容和产品 -3. 5-10 个反复表达的核心论点 = 影响力来源 -4. 不要担心格式，品牌会在写作过程中自然成型 - -**实践建议**：列出 5-10 位你尊重的网上人物 → 观察他们的一致性 → 借鉴规律，用你自己的风格执行。 - -## Key Insight -> "你的个人简介和头像并不重要。有些人个人简介里只有一个词，头像只用了一种颜色。" - -## Connections -- [[Idea-Density]] — 品牌靠创意密度建立 -- [[Idea-Museum]] — 创意博物馆提供品牌内容 -- [[Attention-Economy]] — 在注意力经济中，品牌是获取注意力的机制 -- [[System-Economy]] — 品牌 + 内容 + 产品 = 独立收入闭环 diff --git a/wiki/concepts/Brand-Foundation-Framework.md b/wiki/concepts/Brand-Foundation-Framework.md deleted file mode 100644 index fea9a560..00000000 --- a/wiki/concepts/Brand-Foundation-Framework.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Brand Foundation Framework" -type: concept -tags: [brand, strategy, framework] -last_updated: 2026-05-15 -sources: [design-brand-guardian] ---- - -## Definition - -品牌基础框架是定义品牌存在的完整战略体系，包含 Purpose（存在意义）、Vision（愿景）、Mission（使命）、Values（价值观）和 Personality（个性）五个核心维度。该框架是所有品牌决策的基础，确保品牌在所有触点的一致性和差异化。 - -## Core Components - -### Brand Purpose（存在意义） -品牌超越盈利之外的存在意义——有意义的价值和影响创造。回答"为什么品牌存在"。 - -### Brand Vision（愿景） -品牌追求的理想未来状态——品牌发展方向和成就。回答"品牌想去哪里"。 - -### Brand Mission（使命） -品牌具体做什么、为谁做——价值交付和目标受众。回答"品牌做什么、为谁做"。 - -### Brand Values（价值观） -指导所有品牌行为和决策的核心原则，例如： -1. Primary Value：定义及行为表现 -2. Secondary Value：定义及行为表现 -3. Supporting Value：定义及行为表现 - -### Brand Personality（个性） -定义品牌特征的人类特征，例如： -- Trait 1：描述及表达方式 -- Trait 2：描述及表达方式 -- Trait 3：描述及表达方式 - -## Brand Promise -对客户和利益相关者的承诺——他们可以永远期待什么。 - -## Connections - -- [[design-brand-guardian]] → 定义了 Brand Foundation Framework 的完整结构 -- [[Visual-Identity-System]] → Brand Foundation Framework 的视觉表达 -- [[Brand-Voice]] → Brand Foundation Framework 的语言表达 -- [[design-ux-architect]] → Brand Foundation Framework 是其技术实现的输入 diff --git a/wiki/concepts/Brand-Personality-Framework.md b/wiki/concepts/Brand-Personality-Framework.md deleted file mode 100644 index 275b21bb..00000000 --- a/wiki/concepts/Brand-Personality-Framework.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Brand Personality Framework" -type: concept -tags: [brand, ux, design] -last_updated: 2026-04-30 ---- - -# 品牌个性框架（Brand Personality Framework） - -## Aliases -- Brand Personality -- 品牌个性 -- 品牌声音（Brand Voice） - -## 定义 - -品牌个性框架是定义品牌在所有接触点上"如何表达自己"的系统方法——包括语言风格（文案/语气）、视觉风格（颜色/动画/图标）和交互风格（如何响应用户行为）。核心目标是在保持一致性的同时，传达独特的情感连接。 - -## 四维个性谱系 - -| 情境 | 维度 | 示例 | -|------|------|------| -| 专业场景 | Professional Context | 简洁、数据驱动、严谨 | -| 休闲场景 | Casual Context | 友好、轻松、有温度 | -| 错误场景 | Error Context | 幽默化解焦虑、提供清晰引导 | -| 成功场景 | Success Context | 热情庆祝、肯定用户成就 | - -## 关键要素 - -1. **品牌声音（Brand Voice）**：在各类情境下保持一致的语言风格和语气 -2. **视觉人格（Visual Personality）**：颜色、动画风格、图标选择等视觉元素的一致性 -3. **交互风格（Interaction Style）**：系统如何响应用户动作——积极的？稳重的？俏皮的？ -4. **文化敏感性**：确保个性表达跨越文化边界时不产生误解 - -## 与微交互的关系 - -微交互是品牌个性在交互层的执行载体——一个"俏皮"的品牌会在微交互中体现俏皮（趣味动画/庆祝效果），一个"专业"的品牌则会选择克制的、精确的反馈。 - -## 应用场景 - -- [[design-whimsy-injector]] 负责将品牌个性框架转化为具体的趣味性设计规范和微文案 -- [[design-brand-guardian]] 负责维护品牌个性的一致性和边界 - -## 相关概念 - -- [[design-whimsy-injector]]：品牌个性框架的具体执行者 -- [[Micro-Interaction]]：品牌个性在交互细节上的表达 -- [[Inclusive-Delight]]：品牌个性需兼顾包容性，不能因追求个性而排除特定用户群 diff --git a/wiki/concepts/Brand-Protection.md b/wiki/concepts/Brand-Protection.md deleted file mode 100644 index d62eafdc..00000000 --- a/wiki/concepts/Brand-Protection.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Brand Protection" -type: concept -tags: [brand, protection, trademark, governance] -last_updated: 2026-05-15 -sources: [design-brand-guardian] ---- - -## Definition - -品牌保护是维护品牌完整性、价值和声誉的综合策略体系，包含 Trademark Strategy（商标策略）、Compliance Monitoring（合规监控）和 Crisis Management（危机管理）三个核心维度。 - -## Core Components - -### Trademark Strategy（商标策略） -- 商标注册和保护计划 -- 知识产权识别和登记 -- 侵权监测和执法 -- 法律保护框架 - -### Compliance Monitoring（合规监控） -- 品牌使用合规性检查 -- 品牌实施跨所有触点的监控 -- 品牌指南遵守情况审计 -- 纠正性指导机制 - -### Crisis Management（危机管理） -- 品牌危机应对预案 -- 声誉保护策略 -- 利益相关者沟通计划 -- 品牌恢复路径 - -## Key Activities - -- 保护品牌知识产权 -- 监控品牌一致性实施 -- 管理品牌危机情况 -- 确保文化敏感性和市场适当性 - -## Brand Protection as Default - -Brand Guardian Agent 将品牌保护作为默认要求内置于所有品牌策略中，而非事后补救。 - -## Connections - -- [[design-brand-guardian]] → 定义了 Brand Protection 的完整框架 -- [[Brand-Foundation-Framework]] → Brand Protection 保护品牌基础框架的完整性 -- [[Automation-Governance-Architect]] → 共享治理和保护的系统性思维 -- [[Compliance-Auditor]] → 提供合规监控的方法论参考 diff --git a/wiki/concepts/Brand-Voice.md b/wiki/concepts/Brand-Voice.md deleted file mode 100644 index 32f73b59..00000000 --- a/wiki/concepts/Brand-Voice.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "Brand Voice" -type: concept -tags: [brand, voice, communication, messaging] -last_updated: 2026-05-15 -sources: [design-brand-guardian] ---- - -## Definition - -品牌声音是品牌语言表达的核心规范，定义品牌如何与受众沟通。包含 Voice Characteristics（声音特征）、Tone Variations（语气变体）和 Messaging Framework（信息架构）三个维度。 - -## Core Components - -### Voice Characteristics（声音特征） -定义品牌沟通的人类特征： -- **Strategic（战略性）**：强调品牌决策的战略价值 -- **Consistent（一致性）**：确保跨所有渠道的品牌表达一致 -- **Protective（保护性）**：维护品牌完整性和价值 -- **Visionary（愿景性）**：传达品牌的未来导向和雄心 - -### Tone Variations（语气变体） -根据场景调整的语气指南： -- **Professional（专业）**：何时使用及示例语言 -- **Conversational（对话）**：何时使用及示例语言 -- **Supportive（支持）**：何时使用及示例语言 - -### Messaging Framework（信息架构） -- **Brand Tagline**：概括品牌精髓的易记短语 -- **Value Proposition**：清晰的客户利益声明 -- **Key Messages**： - 1. 主要受众的主要信息 - 2. 次要受众的次要信息 - 3. 特定用例的支持信息 - -## Writing Guidelines - -- **Vocabulary**：首选术语、需要避免的短语 -- **Grammar**：风格偏好、格式标准 -- **Cultural Considerations**：包容性语言指南 - -## Connections - -- [[Brand-Foundation-Framework]] → Brand Voice 是其语言表达层 -- [[design-brand-guardian]] → 定义了 Brand Voice 的完整规范 -- [[Micro-Interaction]] → Brand Voice 在微交互文案中的应用 -- [[Brand-Personality-Framework]] → Brand Voice 反映品牌个性 diff --git a/wiki/concepts/Break-the-Build.md b/wiki/concepts/Break-the-Build.md deleted file mode 100644 index a77873df..00000000 --- a/wiki/concepts/Break-the-Build.md +++ /dev/null @@ -1,64 +0,0 @@ -# Break-the-Build - -## Definition -"Break the Build" is a mechanism that stops the development process if security risks are too high until resolved. - -## Concept -当 CI/CD 管道中的安全扫描发现高风险问题时，自动阻止构建继续进行，直到安全问题得到修复。 - -## How It Works - -### Trigger Conditions -- SAST 发现高危漏洞 -- SCA 发现有漏洞的依赖 -- 机密信息泄露检测 -- 许可证合规违规 - -### Process Flow -``` -代码提交 → 构建开始 → 安全扫描 → - ├─ 通过 → 继续部署 - └─ 失败 → 停止构建 → 通知团队 → 修复 → 重新提交 -``` - -## Implementation - -### CI/CD Integration -```yaml -# GitLab CI Example -security_scan: - stage: test - script: - - sast-scan - allow_failure: false # 阻止构建 -``` - -### Gatekeeping Strategy -| 漏洞等级 | 默认策略 | -|---------|---------| -| Critical | 强制阻止 | -| High | 阻止（可配置） | -| Medium | 警告 | -| Low | 忽略 | - -## Benefits -- 防止不安全代码进入生产环境 -- 强制开发者及时修复安全问题 -- 提高整体安全基线 -- 减少安全债务 - -## Best Practices -1. 明确定义"阻塞"阈值 -2. 平衡安全与开发速度 -3. 提供清晰的错误信息 -4. 集成通知机制 - -## Related Concepts -- [[DevSecOps]] — Break-the-Build 是其自动化组件 -- [[SAST]] — 触发条件来源 -- [[SCA]] — 触发条件来源 -- [[CI/CD Pipeline]] — 实施载体 -- [[Shift-Left-Security]] — 早期发现问题的策略 - -## Sources -- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Budget-Variance-Analysis.md b/wiki/concepts/Budget-Variance-Analysis.md deleted file mode 100644 index ae63b592..00000000 --- a/wiki/concepts/Budget-Variance-Analysis.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Budget Variance Analysis" -type: concept -tags: ["finance", "budgeting", "variance-analysis"] -last_updated: 2026-04-30 ---- - -## Definition -预算差异分析是通过比较预算金额（budget_amount）与实际金额（actual_amount）之间的差异（variance），判断预算执行状态的财务管控方法，是预算管理闭环的关键环节。 - -## Calculation -``` -variance = budget_amount - actual_amount -variance_percentage = (actual_amount - budget_amount) / budget_amount × 100 -``` - -## Status Thresholds -| 差异百分比 | 预算状态 | -|-----------|---------| -| ≤ 5% (正或负) | On Track（正常） | -| > 5%（超支） | Over Budget（超支） | -| > 5%（节省） | Under Budget（节省） | - -## Core Framework -通过 SQL 窗口函数实现： -1. **CTE `budget_actuals`**：按部门、类别、季度聚合预算与实际数据 -2. **CTE `department_summary`**：按部门维度汇总，输出总预算、总实际、差异总额、平均差异百分比 - -## Success Criteria -预算准确率目标：**95%+**，差异分析需附带差异原因说明和纠正行动计划。 - -## Workflow -1. 财务数据验证与核对 -2. 差异计算与状态分类 -3. 差异解释与根因分析 -4. 纠正措施制定与执行 -5. 下期预算调整 - -## Implementation -参见 [[support-finance-tracker]] 中的年度预算 SQL 查询（`WITH budget_actuals AS ...`）。 - -## Related Concepts -- [[Cash Flow Forecasting]]：现金流预测与预算管理同为财务规划支柱 -- [[Financial Risk Assessment]]：差异分析是财务风险预警的重要信号 diff --git a/wiki/concepts/BudgetPacing.md b/wiki/concepts/BudgetPacing.md deleted file mode 100644 index 8121bbb3..00000000 --- a/wiki/concepts/BudgetPacing.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Budget Pacing" -type: concept -tags: ["ppc", "budget", "pacing", "google-ads", "paid-media"] -sources: ["paid-media-ppc-strategist"] -last_updated: 2026-05-01 ---- - -## Definition - -预算 Pacing（Budget Pacing）是管理广告日预算消耗速度的策略与模型，确保预算在整个日期范围内（通常一天）均匀消耗，避免早期过快耗尽（错失晚间高转化流量）或过慢消耗（浪费展示份额）。核心目标：**日预算消耗率 95-100%，浪费控制在 5% 以内**。 - -## Core Concepts - -### Daily Budget Mechanics -- Google Ads 将日预算乘以 30.4（平均每月天数）作为月预算 -- 实际消耗可能在单日波动 ±20%，月度总量不超过月预算 - -### Pacing Patterns - -| 模式 | 描述 | 风险 | -|------|------|------| -| **Accelerated** | 尽快消耗预算 | 早期耗尽，错失后续流量 | -| **Standard** | 算法均匀分配 | 通常推荐 | -| **Seasonal Adjustment** | 旺季/淡季动态调整 | 需主动管理 | - -## Pacing Analysis - -### Diminishing Returns Analysis -- 识别预算边际效益递减点 -- 测试增量预算的转化效率 -- 确定最优预算天花板 - -### Incremental Spend Testing -``` -Hypothesis：每增加 $X 日预算，可带来 Y 个额外转化 -Methodology：逐步增加预算 20-30%，监控 CPA 变化 -Stop criteria：CPA 上升超过 X% 或转化量无显著提升 -``` - -### Seasonal Budget Shifting -- **Q4 Holiday Season**：提前 4-6 周增加预算，黑色星期五达到峰值 -- **Product Launch**：发布前 2 周开始预热，逐步加码 -- **Off-Peak**：适度降低预算，维持展示份额 - -## Success Metrics -- 日预算消耗率：95-100%（过高=浪费，过低=错失流量） -- 浪费率：<5% -- 周末/工作日 pacing 一致性 - -## Connections -- [[MCCLevelStrategy]]：MCC 级预算分配和 pacing 是多账户协调的核心 -- [[AutomatedBiddingStrategy]]：自动化竞价需配合充足预算才能发挥最佳效果 -- [[GoogleAds]]：Budget Pacing 是 Google Ads 账户管理的基本功 diff --git a/wiki/concepts/Bug-Bounty.md b/wiki/concepts/Bug-Bounty.md deleted file mode 100644 index 3339f0d9..00000000 --- a/wiki/concepts/Bug-Bounty.md +++ /dev/null @@ -1,63 +0,0 @@ -# Bug Bounty - -## Definition -Bug Bounty programs incentivize external security researchers to report vulnerabilities in an organization's systems, websites, or applications. - -## Concept -Bug Bounty（漏洞赏金）计划通过向外部安全研究人员提供奖励，激励他们报告组织系统、网站或应用程序中的漏洞。 - -## How It Works - -### Program Setup -1. 定义范围（Scope） -2. 制定规则和奖励表 -3. 建立提交和处理流程 -4. 部署公开平台或使用第三方服务 - -### Researcher Workflow -``` -发现漏洞 → 提交报告 → 厂商验证 → 确认/分类 → 修复 → 发放奖励 -``` - -## Benefits - -### For Organizations -- 扩展安全测试覆盖面 -- 成本效益比聘请专职安全团队更高 -- 获得多样化的安全研究人员视角 -- 提高安全响应能力 - -### For Researchers -- 获得经济奖励 -- 建立安全研究声誉 -- 学习真实环境漏洞 - -## Platforms -- HackerOne -- Bugcrowd -- Open Bug Bounty -- 厂商自有平台（Google VRP, Microsoft Bounty） - -## Best Practices - -### For Program Owners -1. 清晰的规则和范围定义 -2. 公平的奖励机制 -3. 快速响应提交 -4. 透明的沟通 -5. 法律保护（Safe Harbor） - -### Responsible Disclosure -- 给厂商合理时间修复 -- 不公开漏洞细节直到修复 -- 遵循协调漏洞披露（CVD） - -## Related Concepts -- [[DevSecOps]] — Bug Bounty 是持续安全改进的一部分 -- [[Penetration-Testing]] — 正式渗透测试 -- [[Vulnerability-Scanning]] — 自动化漏洞扫描 -- [[Incident-Response]] — 漏洞响应 -- [[Responsible-Disclosure]] — 负责任披露 - -## Sources -- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Build-Mode.md b/wiki/concepts/Build-Mode.md deleted file mode 100644 index 821adc40..00000000 --- a/wiki/concepts/Build-Mode.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Build Mode" -type: concept -tags: [opencode, ai, workflow, coding] -sources: [如何在ubuntu上安装opencode并配置vibe-kanban] -last_updated: 2026-04-27 ---- - -## Overview - -**Build Mode** 是 OpenCode 的构建模式，是 Plan Mode 的互补模式。通过 Tab 键从 [[Plan Mode]] 切换回来后进入此模式，此时 OpenCode 具有完整的文件写入权限，可以执行实际的代码修改。 - -## How It Works - -1. 在 [[Plan Mode]] 中确认了实现方案后 -2. 按 **Tab** 键切换到 Build Mode（屏幕右下角指示器会变化） -3. 告诉 OpenCode "Sounds good! Go ahead and make the changes." -4. OpenCode 执行代码变更 -5. 如需调整，可使用 `/undo` 命令撤销最近修改 - -## Safety Features - -- `/undo`：撤销最近一次的代码修改，支持多次连续撤销 -- `/redo`：重新执行被撤销的修改 -- 可在 Plan/Build 模式间自由切换，Plan 模式下不会意外修改代码 - -## Relationship to Plan Mode - -Build Mode 是 [[Vibe Coding]] 工作流的执行环节： -- [[Plan Mode]] = 规划、提案、审核 -- Build Mode = 执行、实施、交付 - -## Related Concepts - -- [[Plan Mode]] — 计划模式，生成实现方案不写代码 -- [[Vibe Coding]] — Build Mode 是 Vibe Coding 工作流的关键环节 -- [[AGENTS.md]] — 项目上下文定义，帮助 Build Mode 准确实施代码变更 - -## Aliases -- Build Mode (OpenCode) -- 构建模式 diff --git a/wiki/concepts/Build-Your-Own-X.md b/wiki/concepts/Build-Your-Own-X.md deleted file mode 100644 index 4436afc1..00000000 --- a/wiki/concepts/Build-Your-Own-X.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Build-Your-Own-X" -type: concept -tags: [methodology, learning, programming, byox] -last_updated: 2026-04-23 ---- - -## Aliases -- BYOX -- Build Your Own X -- Build-Your-Own-x -- build-your-own-x -- build your own x -- "自己动手重建" - -## Definition -Build Your Own X（BYOX）是一种学习方法论：通过从零实现主流技术（X）来深入理解其内部原理。核心理念引用 Richard Feynman 的名言："What I cannot create, I do not understand"——动手重建是真正理解技术的唯一途径。 - -## Details -- **起源**: GitHub 仓库 codecrafters-io/build-your-own-x，由 [[DanielStefanovic]] 创建，现由 [[CodeCrafters]] 维护 -- **覆盖领域**: 26+ 技术领域（3D Renderer、Web Browser、Database、Docker、Git、Operating System、Programming Language、Neural Network、Bot、Shell、Game、Physics Engine、Search Engine、Regex Engine 等） -- **支持语言**: C++、Python、Java、JavaScript、Go、Rust、Haskell、TypeScript、C#、Ruby、Kotlin、Scala 等 15+ 编程语言 -- **推荐资源**: [[NAND-to-Tetris]] 被列为操作系统和编程语言教程的推荐前置资源 - -## Key Principles -1. **从零开始（From Scratch）**: 不使用高级框架或库，在最小化依赖下理解核心原理 -2. **分步指南**: 每条教程提供循序渐进的分步骤指引，而非大段理论 -3. **动手实践**: 阅读 10 篇文档不如实现一个简化版本 -4. **深度理解**: 不仅知道"怎么用"，更理解"为什么这样工作" - -## Connection to Vibe Coding -BYOX 强调从零重建（Build）理解原理，[[Vibe-Coding]] 强调用 AI 高效实现（Ship）交付产品。两者互补——BYOX 建立直觉，Vibe Coding 高效执行。 - -## Connections -- [[Build-Your-Own-X]] ← maintained_by ← [[CodeCrafters]] -- [[Build-Your-Own-X]] ← founded_by ← [[DanielStefanovic]] -- [[Build-Your-Own-X]] ← quotes ← [[RichardFeynman]] -- [[Build-Your-Own-X]] ← covers ← [[From-Scratch-Methodology]] -- [[Build-Your-Own-X]] ← enables ← [[Learn-By-Building]] -- [[Build-Your-Own-X]] ← includes ← [[NAND-to-Tetris]] diff --git a/wiki/concepts/BuildInPublic.md b/wiki/concepts/BuildInPublic.md deleted file mode 100644 index 622a4ea7..00000000 --- a/wiki/concepts/BuildInPublic.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: "Build in Public" -type: concept -tags: [内容营销, 个人品牌, 创业] -last_updated: 2026-04-22 ---- - -## 定义 - -Build in Public（公开构建）是一种创业和个人品牌策略，即在项目/产品开发过程中公开分享进展、挑战、失败和学到的东西。 - -## 核心理念 - -### 在 AI 泛滥时代，活人感更重要 - -- AI 生成内容越来越多，同质化严重 -- 真实的构建过程、思考和挣扎更能建立信任 -- 受众喜欢看到"真人"而不是"完美机器" - -### 透明度创造连接 - -- 分享失败比分享成功更有价值 -- 过程比结果更能引发共鸣 -- 让受众参与你的成长旅程 - -## 实践方法 - -### 内容矩阵 - -- **观察类**：行业洞察、趋势分析 -- **反直觉类**：挑战常规认知的观点 -- **操作指南类**：可执行的步骤和教程 -- **个人故事类**：真实的创业经历和教训 -- **清单类**：可复用的资源和工具 - -### 反向金字塔内容法 - -``` -一次长形式内容 - ↓ 拆分 -无数微内容 - ↓ 分发 -一次制作，百次分发 -``` - -## 在一人公司中的作用 - -Build in Public 是[[一人公司]]内容策略的重要组成部分，配合： -- [[产品四层级体系]] 实现引流 -- [[销售漏斗]] 实现转化 -- [[底层能力]] 确定分享主题 - -## 相关来源 - -- [[万字保姆级教程-90天跑通一人公司模式]] - -## 相关概念 - -- [[一人公司]] -- [[内容矩阵]] -- [[个人品牌]] - -## Aliases - -- 公开构建 -- 透明创业 -- 公开分享 diff --git a/wiki/concepts/Business-Analysis.md b/wiki/concepts/Business-Analysis.md deleted file mode 100644 index 3a9716b6..00000000 --- a/wiki/concepts/Business-Analysis.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Business Analysis" -type: concept -tags: [Business-Analysis, Requirements, Agile] -sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109] -last_updated: 2026-05-11 ---- - -## Definition - -业务分析（Business Analysis）是将业务需求与变更解决方案对齐的过程——连接业务问题与技术实现方案的桥梁。 - -## Core Activities - -业务分析的核心活动包括五个步骤： - -1. **调查现状**（Investigate Current Situation） -2. **分析需求**（Analyze Needs） -3. **识别方案**（Identify Solutions） -4. **评估选项**（Evaluate Options） -5. **定义需求**（Define Requirements） - -## Scope - -业务分析涵盖的范围包括： -- **IT系统变更**：定义IT系统的需求和变更方案 -- **流程变更**：分析和优化业务流程 -- **培训需求**：识别和支持人员培训需求 -- **角色转换**：管理组织角色和职责的变更 - -## Business Value - -> "Business analysis helps us work out what changes will be beneficial in our business architecture, including changes to IT systems and defining the requirements for those changes." - -业务分析的核心价值在于： -- **清晰性**：明确目标和交付物 -- **一致性**：确保业务与技术对齐 -- **效率**：早期发现问题，避免返工 - -## Key Techniques - -业务分析师使用的核心技法包括： -- [[BOSCARD]]：复杂新工作的定义框架 -- [[Stakeholder-Wheel]]：干系人识别工具 -- [[Requirements-Gathering]]：结合元数据的需求收集方法 -- [[INVEST]]：优质用户故事检查原则 - -## Related Concepts - -- [[T-Shaped-Skills]]：业务分析师所需的核心技能模型 -- [[SAFe]]：规模化敏捷框架中的需求层次 -- [[RACI]]：责任分配矩阵 - -## Learning Resources - -- **BCS**（英国计算机学会）：业务分析课程与认证 -- **IIBA**（国际商业分析协会）：CBAP等专业认证 - -## Aliases -- BA -- 业务分析 diff --git a/wiki/concepts/Business-Impact-Analysis.md b/wiki/concepts/Business-Impact-Analysis.md deleted file mode 100644 index cb8a77f8..00000000 --- a/wiki/concepts/Business-Impact-Analysis.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: "Business Impact Analysis (业务影响分析)" -tags: [devops, disaster-recovery, risk-management, business-continuity, planning] -aliases: [BIA] -created: 2026-04-25 ---- - -# Business Impact Analysis (业务影响分析) - -**Business Impact Analysis (BIA)** 是确定不同应用系统故障对业务影响的分析过程，用于设定 [[RTO]] 和 [[RPO]] 目标以及分层保护策略。 - -## Aliases -- BIA -- 业务影响分析 - -## Definition - -BIA 的核心问题： -1. 如果系统停机 1 小时，会发生什么？ -2. 如果丢失过去 1 小时的数据，会发生什么？ - -回答这些问题，才能科学地确定每个系统的 RTO/RPO 目标，而非凭感觉设定"激进但无法实现"的目标。 - -## 关键分析问题 - -### 如果系统停机 1 小时？ - -- **收入损失**？损失多少？ -- **客户不满**？影响多少客户？ -- **员工受阻**？他们能绕过去工作吗？ -- **合规风险**？法律问题？ - -### 如果丢失过去 1 小时的数据？ - -- **数据能重建吗**？ -- **是否涉及资金/交易**？ -- **用户会注意到吗**？ -- **合规要求**是否要求保留这些数据？ - -## Tiered Protection Model - -基于 BIA 结论，将应用分为不同保护级别： - -| Tier | 场景 | RTO 目标 | RPO 目标 | 投资策略 | -|------|------|----------|----------|----------| -| **(1) Critical** | 支付处理、用户认证、核心产品功能 | < 5 分钟 | < 1 分钟 | Feature Flag + 自动化监控 + 3AM 告警 + 热备 | -| **(2) Important** | 管理后台、报表、客户支持工具 | < 1 小时 | < 15 分钟 | Feature Flag（主要发布）+ 业务时间监控 + 标准备份 | -| **(3) Nice-to-have** | 内部工具、开发环境、文档站点 | < 4 小时 | < 1 小时 | 基础监控 + 手动恢复流程 + 每日备份 | - -## 投资优先级 - -> "Most teams try to give everything Tier 1 treatment, which can lead to burnout. Be ruthless about what actually matters to your business. You can't do *everything*." - -### Tier 1 投资 -- [[Feature Flag]] + 自动化监控 -- 自动化告警（支持 3AM 叫醒） -- [[Kill Switch]] + 备用路径就绪 -- 近实时数据复制 - -### Tier 2 投资 -- [[Feature Flag]]（主要发布场景） -- 业务时间监控 -- 文档化的回滚程序 -- 小时级备份 - -### Tier 3 投资 -- 基础监控 -- 手动恢复程序 -- 每日备份 -- 期望最好的结果 - -## BIA 与成本收益 - -> "Do the math honestly. What does an hour of downtime actually cost your business? If it's $10K, don't spend $100K/year on infrastructure to prevent it. You're better off accepting some downtime and investing in faster recovery." - -| 系统停机损失 | 合理灾备投资上限（年化） | -|-------------|------------------------| -| $10K/小时 | $100K/年 | -| $100K/小时 | $1M/年 | - -**关键洞察**：预防和恢复的成本必须与实际业务损失相匹配。 - -## BIA 与 [[Feature Flag]] 的关系 - -BIA 结论指导 Feature Flag 的使用策略： - -- **Tier 1 系统**：必须有 Kill Switch，Progressive Rollout 强制 -- **Tier 2 系统**：建议 Feature Flag 主要发布场景 -- **Tier 3 系统**：根据 ROI 决定是否使用 Feature Flag - -## Related Concepts - -- [[RTO]] — BIA 结论决定 RTO 目标 -- [[RPO]] — BIA 结论决定 RPO 目标 -- [[Feature Flag]] — 基于 BIA 分层保护的技术手段 -- [[Kill Switch]] — Tier 1 系统的必备应急机制 -- [[Disaster Recovery]] — BIA 是灾备规划的基础 -- [[Risk-Mitigation]] — BIA 是风险管理的一部分 - -## Sources - -- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/concepts/Business-Knowledge-Base.md b/wiki/concepts/Business-Knowledge-Base.md deleted file mode 100644 index c24b0dd5..00000000 --- a/wiki/concepts/Business-Knowledge-Base.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Business Knowledge Base" -type: concept -tags: [] -sources: [] ---- - -# Business Knowledge Base - -## Definition - -AI Agent 的结构化业务知识库，包含服务详情、定价政策、营业时间、常见问题解答和人工升级触发条件等信息，是 AI 自动回复准确性的核心依赖。 - -## Contents - -| Category | Examples | -|----------|---------| -| **Services & Pricing** | 服务列表、价格区间、套餐选项 | -| **Business Hours** | 营业时间、节假日安排、紧急联系方式 | -| **Location** | 地址、交通指引、停车信息 | -| **FAQ Responses** | 预定义的高频问答对 | -| **Escalation Triggers** | 需要人工处理的场景定义（投诉、退款、特殊情况） | - -## Knowledge Injection - -在 [[OpenClaw]] 中通过以下方式构建知识库： -1. **Structured data**：JSON/YAML 格式的结构化业务数据 -2. **AGENTS.md 配置**：路由规则和回复模板中嵌入知识 -3. **Document ingestion**：产品手册、政策文档导入 - -## Quality Considerations - -- **准确性**：知识库内容必须与实际业务一致，否则 AI 会生成错误回复 -- **覆盖度**：覆盖越全面，AI 自动处理率越高 -- **更新机制**：业务变更时同步更新知识库，避免信息滞后 - -## Related Concepts - -- [[AI-Auto-Response]]：知识库是自动回复的信息来源 -- [[Intent-Classification]]：知识库结构影响意图分类的准确性 -- [[Human-Handoff]]：升级触发条件定义在知识库中 - -## Sources - -- [[multi-channel-customer-service]] diff --git a/wiki/concepts/BusinessImpactQuantification.md b/wiki/concepts/BusinessImpactQuantification.md deleted file mode 100644 index a53e8b9d..00000000 --- a/wiki/concepts/BusinessImpactQuantification.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Business Impact Quantification" -type: concept -tags: ["business-analysis", "consulting", "metrics"] -sources: ["support-executive-summary-generator"] -last_updated: 2026-04-26 ---- - -## Definition -商业影响量化是一种将业务发现和建议转化为具体、可衡量数据的方法论。核心是用 $ 或 % 等定量指标使影响具体可感知，避免模糊表述。 - -## Key Principles -- **量化优先**：用具体数字替代模糊描述（如"34% QoQ增长"而非"显著增长"） -- **财务影响明确**：Revenue/Cost/Market Share 变化必须量化 -- **风险/机会幅度**：用概率或百分比表达不确定性 -- **时间范围**：明确影响实现的时间节点 - -## Application in Executive Summary -- 每个 Key Finding 必须包含 ≥ 1 个量化数据点 -- Business Impact 部分量化潜在收益/损失 -- Recommendations 包含预期结果的可衡量指标 - -## Examples -- "Customer acquisition costs increased 34% QoQ, from $45 to $60 per customer" -- "This initiative could unlock $2.3M in annual recurring revenue within 18 months" - -## Related Concepts -- [[Executive Summary]] -- [[Action-Oriented Recommendations]] diff --git a/wiki/concepts/CACandLTV.md b/wiki/concepts/CACandLTV.md deleted file mode 100644 index b634a429..00000000 --- a/wiki/concepts/CACandLTV.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "CAC and LTV" -type: concept -tags: ["unit-economics", "metrics", "growth", "acquisition"] -last_updated: 2026-04-26 ---- - -## Definition -客户获取成本（CAC）与生命周期价值（LTV）——增长的核心单位经济学指标组合，用于衡量获客效率是否可持续。LTV:CAC ≥ 3:1 为健康增长门槛；CAC 回本周期 < 6个月。 - -## Metrics -- **CAC（Customer Acquisition Cost）**：获取一个新客户所需的平均成本 = 总营销支出 / 新增客户数 -- **LTV（Lifetime Value）**：一个客户在整个生命周期内为产品贡献的总收入 = 平均收入/用户/年 × 平均客户留存年数 -- **LTV:CAC Ratio**：衡量获客投入产出比，健康值 ≥ 3:1 -- **CAC Payback Period**：收回获客成本所需时间，健康值 < 6个月 - -## Why It Matters -增长黑客必须在追求快速增长的同时，确保单位经济学健康——否则增长越快，亏损越大。LTV:CAC 是增长决策的最高优先级指标。 - -## Source -- [[marketing-growth-hacker]]（Marketing Growth Hacker Agent） - -## Aliases -- Customer Acquisition Cost -- Lifetime Value -- Unit Economics diff --git a/wiki/concepts/CAPA.md b/wiki/concepts/CAPA.md deleted file mode 100644 index afab5985..00000000 --- a/wiki/concepts/CAPA.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "CAPA" -type: concept -tags: [Incident-Management, Post-mortem, Root-Cause, Preventive-Action] -last_updated: 2026-04-14 ---- - -## Definition - -CAPA (Corrective and Preventive Action，纠正和预防措施) 是 Emergency Change 事后必须执行的流程，用于从事故中提取根本原因并预防同类问题再次发生。CAPA 通常与 Post-mortem 回顾结合使用。 - -## Components - -### Corrective Action（纠正措施） -- 修复当前事故的直接措施 -- 目标是恢复服务到期望状态 -- 通常在 Emergency Change 执行阶段完成 - -### Preventive Action（预防措施） -- 防止同类问题再次发生的长期措施 -- 目标是消除根本原因 -- 通常在 Post-mortem 分析后制定 - -## Relationship with Emergency Change - -CAPA 是 Emergency Change 流程的关键组成部分： - -``` -Incident 发生 - ↓ -Emergency Change 执行（Corrective Action） - ↓ -CAPA/Post-mortem 分析 - ↓ -制定 Preventive Action - ↓ -可能转化为 Standard Change（避免未来同类事件） -``` - -## Process - -1. **Incident Review**：回顾事故经过 -2. **Root Cause Analysis**：识别根本原因 -3. **Corrective Action**：执行即时修复 -4. **Preventive Action**：制定长期预防措施 -5. **Follow-up**：跟踪措施执行情况 -6. **Closure**：完成 CAPA 记录 - -## Sources - -- [[ctp-topic-30-managing-change]] diff --git a/wiki/concepts/CBT-CognitiveDistortions.md b/wiki/concepts/CBT-CognitiveDistortions.md deleted file mode 100644 index 451849c1..00000000 --- a/wiki/concepts/CBT-CognitiveDistortions.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "CBT Cognitive Distortions" -type: concept -tags: [] -sources: [academic-psychologist] -last_updated: 2026-04-25 ---- - -# CBT Cognitive Distortions - -## Aliases -- Beck's Cognitive Distortions -- Cognitive Distortions -- Thinking Errors - -## Definition -Beck 认知行为疗法中的认知扭曲——非理性、适应不良的思维模式，驱动情绪反应和行为决策。 - -## Common Cognitive Distortions - -| 扭曲类型 | 描述 | 例子 | -|----------|------|------| -| All-or-Nothing（全或无思维） | 非黑即白的极端判断 | "如果我不完美，就是彻底的失败" | -| Overgeneralization（过度概括） | 以单一事件得出普遍结论 | "这次失败了，我永远都会失败" | -| Mental Filter（心理过滤） | 放大负面、忽视正面 | 只记住批评，忘记所有赞美 | -| Disqualifying the Positive（贬损正面） | 把正面经历解释为偶然 | "他们夸我只是客气" | -| Jumping to Conclusions（跳跃式结论） | 无根据的负面解读 | 读心术、预言式思维 | -| Magnification/Minimization（放大/缩小） | 不成比例地放大负面、缩小正面 | 把小错误灾难化 | -| Emotional Reasoning（情绪化推理） | "我感觉是这样，所以就是这样" | "我觉得自己很蠢，所以我就是蠢" | -| Should Statements（"应该"陈述） | 僵化的规则和自我要求 | "我应该总是坚强" | -| Labeling（标签化） | 用标签代替行为描述 | "我是一个失败者" | -| Personalization（个人化） | 不恰当地把外部事件和自己关联 | "他生气是因为我" | - -## Application in Character Design -Psychologist Agent 通过识别角色决策背后的具体认知扭曲，而非泛泛说"他们不理性"，使心理分析具有可操作性。 - -## Connection to Wiki -- Source: [[academic-psychologist]] diff --git a/wiki/concepts/CDC-Change-Data-Capture.md b/wiki/concepts/CDC-Change-Data-Capture.md deleted file mode 100644 index b3150f98..00000000 --- a/wiki/concepts/CDC-Change-Data-Capture.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "CDC (Change Data Capture)" -type: concept -tags: [data-engineering, streaming, incremental-pipeline] -sources: [engineering-data-engineer] -last_updated: 2026-05-02 ---- - -## Definition - -CDC（Change Data Capture，变更数据捕获）是一种从源系统捕获增量变更（插入、更新、删除）的技术，使数据管道无需全量刷新即可同步最新数据，大幅降低计算成本。 - -## How It Works - -1. **识别变更**：从源数据库的事务日志（WAL）、时间戳字段或变更追踪表中提取变更记录 -2. **携带元数据**：每条 CDC 记录携带变更类型（INSERT/UPDATE/DELETE）、变更时间、来源事务 ID -3. **幂等写入**：通过主键或变更时间戳实现幂等 upsert（MERGE INTO Delta Lake），确保重新运行安全 - -## Benefits - -- **成本节省**：增量处理 vs. 全量刷新，成本降低 90%+ -- **低延迟**：变更实时捕获，支持分钟级甚至秒级数据刷新 -- **低影响**：CDC 通常基于数据库日志读取，对源系统影响极小 - -## CDC in Medallion Architecture - -- **Bronze 层**：CDC 记录追加写入，保留完整变更历史（append-only） -- **Silver 层**：基于变更类型（INSERT=插入, UPDATE=更新, DELETE=标记删除）进行去重和 conform -- **Gold 层**：CDC 支持近实时业务指标更新 - -## CDC Technologies - -- **Debezium**：开源 CDC 平台，捕获 MySQL/PostgreSQL/MongoDB 等变更并发布到 Kafka -- **AWS DMS**（Database Migration Service）：AWS 托管 CDC 解决方案 -- **Azure Data Factory** CDC 活动：Azure 生态 CDC 工具 -- **Databricks Auto Loader**：`cloudFiles` 增量摄取 CSV/Parquet/JSON 文件变更 - -## Related Concepts -- [[Medallion Architecture]] -- [[Data Contract]]（CDC 需配合数据契约确保 schema 兼容） -- [[Apache Kafka]]（CDC 常用传输层） diff --git a/wiki/concepts/CEOPattern.md b/wiki/concepts/CEOPattern.md deleted file mode 100644 index a4d3cd24..00000000 --- a/wiki/concepts/CEOPattern.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "CEO Pattern" -type: concept -tags: [multi-agent, architecture, orchestration] -sources: [autonomous-project-management] -last_updated: 2026-04-22 ---- - -## 定义 -主 Agent 仅负责策略决策（strategy only），所有执行操作下沉至子 Agent 的极简主控模式。其名称来源于"CEO 只做战略，不管执行"的企业管理隐喻。 - -## 核心原则 -- **主会话越薄越好**：0-2 步工具调用，响应速度与主会话的"薄度"成正比 -- **只做决策**：任务分配、优先级调整、结果汇总 -- **不做事**：不直接执行工具调用，不处理具体业务逻辑 -- **所有执行下沉**：子 Agent 自主工作，主会话只负责协调 - -## 关键洞察 -> "The less the main agent does, the faster it responds." - -主会话的功能越少，其响应速度越快——这是去中心化协调架构的性能保障。 - -## 实现方式 -通过 [[PM Delegation Pattern]]，每个子 Agent 被赋予特定范围的任务，独立完成，主会话不干预具体执行过程。 - -## 与传统 Orchestrator 模式的区别 -| 维度 | Orchestrator 模式 | CEO 模式 | -|------|-------------------|---------| -| 主 Agent 角色 | 交通指挥员（所有调用必经） | CEO（仅决策） | -| 并行能力 | 受限（中心瓶颈） | 强（完全并行） | -| 响应速度 | 随任务数线性下降 | 稳定（子 Agent 异步执行） | -| 扩展性 | O(n) 瓶颈 | O(1) 主会话成本 | diff --git a/wiki/concepts/CI-CD Pipeline.md b/wiki/concepts/CI-CD Pipeline.md deleted file mode 100644 index d2e897b4..00000000 --- a/wiki/concepts/CI-CD Pipeline.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: "CI/CD Pipeline" -type: concept -tags: [DevOps, Automation, Software Delivery] -sources: [engineering-devops-automator] -last_updated: 2026-05-01 ---- - -# CI/CD Pipeline - -## 定义 -CI/CD 流水线是自动化软件交付的端到端管道，包含持续集成（Continuous Integration）、持续交付（Continuous Delivery）和持续部署（Continuous Deployment）三个阶段。 - -## 三个阶段 - -### 持续集成（CI） -- 开发者频繁提交代码到共享仓库 -- 每次提交自动触发构建和测试 -- 早期发现集成问题 - -### 持续交付（CD） -- 代码通过所有自动化测试后自动部署到 staging 环境 -- 人工审批后部署到生产环境 -- 确保每次变更都可部署 - -### 持续部署（Continuous Deployment） -- 代码通过所有测试后自动部署到生产环境 -- 无需人工干预 -- 需要完善的测试和监控体系支撑 - -## 核心组件 - -### 构建阶段 -- 代码编译 -- 依赖安装 -- 制品构建（Docker 镜像/二进制文件） - -### 测试阶段 -- 单元测试 -- 集成测试 -- 端到端测试 -- 安全扫描 - -### 部署阶段 -- 部署到目标环境 -- 健康检查 -- 流量切换 -- 回滚机制 - -## DevOps Automator 的标准流水线 -```yaml -security-scan → test → build → deploy -``` -- security-scan：依赖漏洞扫描 + 静态安全分析 -- test：单元测试 + 集成测试 -- build：容器构建 + 推送镜像仓库 -- deploy：零停机部署（蓝绿/金丝雀/滚动） - -## 相关工具 -- [[GitHub Actions]]：DevOps Automator 默认选择 -- Jenkins：开源 CI/CD 服务器 -- GitLab CI：GitLab 内置 CI/CD -- ArgoCD：GitOps 持续交付 -- Spinnaker：多云持续交付平台 - -## 相关概念 -- [[Infrastructure as Code]]：CI/CD 部署目标通常是 IaC 管理的基础设施 -- [[Zero-Downtime Deployment]]：CI/CD 的部署策略 -- [[Blue-Green Deployment]]：CI/CD 常用部署策略 - -## 关键指标 -- **部署频率**：每日部署次数 -- **变更前置时间**：代码提交到生产的时间 -- **变更失败率**：生产环境回滚或失败的百分比 -- **MTTR**：平均恢复时间 - -## Aliases -- CI/CD -- CI/CD Pipeline -- 持续集成/持续交付 -- Continuous Integration -- Continuous Delivery -- Continuous Deployment diff --git a/wiki/concepts/CI-CD-Pipeline.md b/wiki/concepts/CI-CD-Pipeline.md deleted file mode 100644 index e6292e14..00000000 --- a/wiki/concepts/CI-CD-Pipeline.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "CI/CD Pipeline" -type: concept -sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-9-ci-cd-with-gruntwork, engineering-devops-automator] -last_updated: 2026-04-14 ---- - -## Definition -CI/CD 流水线（CI/CD Pipeline）是持续集成（Continuous Integration）和持续交付/部署（Continuous Delivery/Deployment）的自动化流程，用于管理基础设施代码（IaC）的构建、测试和部署。在 Gruntwork Landing Zone 架构中，每个 Landing Zone 配置独立的 Jenkins 服务器和 CI/CD 流水线来自动化 Terraform 基础设施变更。 - -## Core Components - -### CI（持续集成） -- **代码提交**：开发人员将特性分支代码推送到 GitHub 仓库 -- **自动构建**：Jenkins 触发 Terraform 初始化和格式化验证 -- **自动测试**：TerraTest 执行基础设施单元测试和集成测试 -- **代码审查**：Pull Request 必须通过审查才能合并到主分支 - -### CD（持续交付/部署） -- **自动部署**：合并到主分支后，Jenkins 自动执行 Terraform Plan -- **审批流程**：变更需要人工审批后才执行 Apply -- **渐进式部署**：支持 Blue-Green 部署和 Canary Release 策略 - -### Infrastructure-Specific Considerations -- **状态管理**：Terraform State 的锁定和远程存储（使用 S3 + DynamoDB） -- **幂等性**：Terraform 模块设计必须支持重复执行而不产生副作用 -- **回滚机制**：通过 Terraform State 历史版本实现快速回滚 -- **漂移检测**：定期运行 `terraform plan` 检测配置漂移 - -## Tools in Gruntwork Landing Zone Context -- **Jenkins**：核心 CI/CD 引擎，每个 Landing Zone 独立部署 -- **Terraform**：IaC 工具，定义和管理 AWS 资源 -- **TerraTest**：Go 语言编写的基础设施测试框架 -- **GitHub**：代码仓库，支持特性分支和 Pull Request 工作流 - -## Git Workflow -- 特性分支开发：`feature/` -- 通过 Pull Request 合并到主分支 -- 必须经过代码审查和 CI 测试 -- 合并后触发自动部署流水线 - -## Related Concepts -- [[Landing-Zone-Architecture]]：CI/CD 流水线是 Landing Zone 自动化运维的核心机制 -- [[Terraform-Modules]]：被 CI/CD 流水线自动化部署的 IaC 模块 -- [[GitOps]]：基于 Git 的运维方式，CI/CD 是其技术实现 -- [[TerraTest]]：用于基础设施变更的自动化测试工具 - -## References -- [[ctp-topic-1-gruntwork-landing-zone-architecture]] -- [[ctp-topic-9-ci-cd-with-gruntwork]] -- [[ctp-topic-2-git]] diff --git a/wiki/concepts/CI-CD-Secrets.md b/wiki/concepts/CI-CD-Secrets.md deleted file mode 100644 index 043fb401..00000000 --- a/wiki/concepts/CI-CD-Secrets.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: "CI/CD-Secrets" -type: concept -tags: - - CI/CD - - Security - - DevOps - - Cloud ---- - -## Definition - -CI/CD Secrets 是指在持续集成/持续部署（CI/CD）流水线中管理敏感信息（密码、API Key、证书、私钥等）的最佳实践。传统 CI/CD 流程中这些 secrets 通常以明文形式硬编码在配置文件、环境变量或脚本中，造成严重的安全风险。 - -## Security Problems with Plain-Text Secrets - -1. **代码仓库泄露**：Secrets 可能意外提交到 Git 等版本控制系统 -2. **日志暴露**：Secrets 在构建日志中可见 -3. **网络传输**：Secrets 在流水线各阶段间传输时可能被截获 -4. **审计缺失**：无法追踪谁在何时访问了哪些凭据 -5. **轮换困难**：硬编码的 Secrets 难以定期轮换 - -## Best Practices for CI/CD Secrets Management - -### 1. Centralized Secrets Management - -将所有 Secrets 集中存储在专用服务中： -- AWS Secrets Manager -- HashiCorp Vault -- Azure Key Vault -- GCP Secret Manager - -### 2. Dynamic Credentials - -使用动态临时凭证替代静态密钥： -```yaml -# ❌ 危险：静态密钥 -environment: - DB_PASSWORD: "static_password_123" - -# ✅ 推荐：动态获取 -environment: - DB_PASSWORD: - from_secret: aws:database-password -``` - -### 3. Pipeline Integration Pattern - -``` -┌─────────────┐ Request ┌─────────────────┐ -│ CI/CD │ ──────────────→│ Secrets │ -│ Pipeline │ │ Manager │ -└─────────────┘←────────────── └─────────────────┘ - Dynamic Secret -``` - -### 4. GitOps with Secrets - -使用 Sealed Secrets、Vault Agent 或 cloud-native solutions 实现 Git 安全存储： -- **Sealed Secrets**：将 secrets 加密后存储在 Git 中 -- **External Secrets Operator**：Kubernetes 原生 secrets 管理 -- **AWS Secrets Manager + SSM**：AWS 原生解决方案 - -## AWS Implementation Example - -```python -# Lambda function for secrets retrieval in CI/CD -import boto3 -import os - -def get_db_credentials(): - client = boto3.client('secretsmanager') - response = client.get_secret_value( - SecretId='prod/database/credentials' - ) - return json.loads(response['SecretString']) -``` - -## Security Controls - -1. **最小权限**：CI/CD 服务账号仅授予必要的 secrets 读取权限 -2. **网络隔离**：Secrets 服务在私有网络中，不暴露给公网 -3. **审计日志**：记录所有 secrets 访问操作 -4. **自动轮换**：Secrets 定期自动轮换，无需人工干预 -5. **临时凭证**：使用 STS 临时凭证替代长期密钥 - -## Related Concepts - -- [[SecretsManagement]]：敏感信息管理的整体框架 -- [[SecretRotation]]：密钥轮换机制 -- [[GitOps]]：基础设施即代码的 Git 工作流 -- [[Infrastructure-as-Code]]：基础设施即代码 - -## Related Entities - -- [[AWS]]：AWS Secrets Manager 提供方 -- [[HashiCorp]]：HashiCorp Vault 提供方 -- [[ControlTower]]：AWS 多账户治理框架 - -## Sources - -- [[ctp-topic-37-secrets-certificates-management]] — CI/CD secrets cleanup implementation phase -- [[ctp-topic-62-aws-secrets-manager]] — JDBC Wrapper + CI/CD integration details - -## Aliases - -- Pipeline Secrets -- Build Secrets -- Deployment Credentials -- GitOps Secrets diff --git a/wiki/concepts/CICDPipeline.md b/wiki/concepts/CICDPipeline.md deleted file mode 100644 index 0874193c..00000000 --- a/wiki/concepts/CICDPipeline.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "CI/CD Pipeline" -type: concept -tags: [devops, cicd, automation, continuous-delivery] -sources: [devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin] -last_updated: 2026-04-22 ---- - -## Summary -CI/CD (Continuous Integration / Continuous Delivery) Pipelines automate the entire software delivery process — from code commit through testing, integration, and deployment. In DevOps, CI/CD is a foundational automation enabler that shrinks feedback cycles from weeks to minutes. Key tools include Jenkins, GitLab CI, and GitHub Actions. - -## Key Concepts - -### Continuous Integration (CI) -- Developers merge code changes frequently (multiple times daily) -- Automated builds and tests run on every commit -- Catches integration bugs early - -### Continuous Delivery (CD) -- Code changes are automatically prepared for release -- Deployment to staging/production is a manual decision -- Ensures software is always in a deployable state - -### Continuous Deployment -- Every change that passes tests is automatically deployed to production -- Full automation of the release process - -## Key Tools -- **Jenkins** — Open-source automation server with extensive plugin ecosystem -- **GitLab CI** — Integrated CI/CD within GitLab -- **GitHub Actions** — CI/CD built into GitHub - -## In the DevOps Context -CI/CD pipelines are described as "Agile Accelerators" that automate testing and deployment to shrink feedback cycles. They enable teams to: -- Ship features faster with confidence -- Reduce deployment risk through automated testing -- Enable frequent, low-risk releases - -## Connections -- [[DevOps Culture]] — CI/CD is an automation pillar of DevOps -- [[Infrastructure as Code (IaC)]] — Complementary automation practice -- [[DevSecOps]] — Security tools integrated into CI/CD pipelines -- [[GitOps]] — GitOps extends CI/CD with Git-as-source-of-truth diff --git a/wiki/concepts/CIDR-审批流程.md b/wiki/concepts/CIDR-审批流程.md deleted file mode 100644 index 8d13e04a..00000000 --- a/wiki/concepts/CIDR-审批流程.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: "CIDR-审批流程" -type: concept -tags: [AWS, Networking, IPAM, Approval, Automation] -sources: - - ctp-topic-45-automatic-ip-address-allocation-with-ipam - - ctp-topic-61-workload-vpc-provision-with-ipam-automation -last_updated: 2026-04-24 ---- - -## CIDR-审批流程 - -基于 CIDR 地址块大小的差异化审批规则，用于平衡自动化效率与 IP 地址空间治理。IPAM 系统根据请求的子网大小自动路由至不同的处理流程。 - -## Approval Matrix - -| CIDR 前缀 | 子网大小 | IP 地址数量 | 审批流程 | -|-----------|----------|-------------|----------| -| /16 | 65,536 | 65,534 可用 | **自动批准** | -| /18 | 16,384 | 16,382 可用 | **自动批准** | -| /20 | 4,096 | 4,094 可用 | **自动批准** | -| /22 | 1,024 | 1,022 可用 | **自动批准** ✅ | -| /24 | 256 | 254 可用 | **需审批** ⚠️ | -| /26 | 64 | 62 可用 | **需审批** ⚠️ | -| /28 | 16 | 14 可用 | **需审批** ⚠️ | - -## Decision Logic - -``` -用户请求子网 - ↓ -IPAM 系统判断 CIDR 大小 - ↓ -┌─────────────────────────────────┐ -│ CIDR ≥ /22？ │ -│ ├─ 是 → 自动批准 │ -│ │ 调用 NIOS API │ -│ │ 分配下一可用块 │ -│ └─ 否 → 提交网络团队审批 │ -│ 用户提供申请理由 │ -│ 网络团队人工审核 │ -└─────────────────────────────────┘ -``` - -## Business Rationale - -1. **/22 及更大（自动批准）** - - IP 地址空间充足 - - 对整体地址空间影响小 - - 鼓励团队自主自动化 - -2. **/24 及更小（需审批）** - - IP 地址空间紧张 - - 需评估是否可合并到更大块 - - 防止地址空间碎片化 - -## Key Concepts - -- [[IPAM]]：执行审批逻辑的核心系统 -- [[Infoblox-NIOS]]：存储和管理 CIDR 分配记录 -- [[VPC-自动化供给]]：CIDR 审批是自动化供给的一部分 - -## Notes - -- 审批阈值（/22）由网络团队定义，可能因组织政策调整 -- 邮件通知机制覆盖用户和网络团队，全程可追溯 -- 参见 [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] 中的详细说明 - -## Aliases - -- CIDR Approval Workflow -- IP 地址审批流程 -- 子网大小审批规则 -- IPAM Approval Threshold diff --git a/wiki/concepts/CIS-Benchmark.md b/wiki/concepts/CIS-Benchmark.md deleted file mode 100644 index 381c1815..00000000 --- a/wiki/concepts/CIS-Benchmark.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: "CIS Benchmark" -type: concept -tags: - - Security - - Compliance - - Hardening - - Standards -sources: - - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w -last_updated: 2026-04-24 ---- - -# CIS Benchmark - -CIS Benchmark（Center for Internet Security Benchmark）是全球最具权威的 IT 基础设施安全加固指南，由非营利组织 CIS（Center for Internet Security）维护，涵盖操作系统、数据库、Web 服务器、容器平台等数百种技术的安全配置标准。 - -## 核心特点 - -- **社区驱动**：基于全球安全专家的共识实践，经多轮评审和测试 -- **中立性**：独立于厂商，为任何组织提供客观的安全配置建议 -- **分级设计**：Level 1（基础安全，适合大多数环境）和 Level 2（深度防御，适合高安全要求环境） -- **广泛覆盖**：涵盖 100+ 技术类别，包括 Linux、Windows、macOS、AWS、GCP、Azure、Kubernetes、Docker 等 - -## 典型检查项示例（Linux） - -| 类别 | Level | 检查项 | -|------|-------|--------| -| 初始设置 | 1 | 确认是否禁用不必要的服务（如 telnet、rsh） | -| 服务配置 | 1 | 配置 SSH 禁用 root 登录和密码认证 | -| 日志配置 | 1 | 启用审计日志并配置适当的日志轮转 | -| 文件系统 | 2 | 配置 `/tmp` 目录为 noexec、nosuid、nodev | -| 访问控制 | 1 | 配置 PAM 强制密码复杂度 | -| 网络配置 | 2 | 配置防火墙规则限制入站流量 | - -## 在 Bottlerocket 中的支持 - -Bottlerocket OS 提供专用的 CIS Benchmark 安全加固指南： -- 预配置的 SE Linux 策略覆盖大部分容器相关检查项 -- 只读根文件系统和 dm-verity 自动满足多项文件系统完整性要求 -- 分区设计满足审计日志分离存储要求 -- 最佳实践：使用 CIS Benchmark 自动化工具（如 CIS-CAT）定期扫描 Bottlerocket 节点合规性 - -## 认证与合规 - -CIS Benchmark 是多项安全合规框架的重要组成部分： - -| 合规框架 | 与 CIS Benchmark 的关系 | -|---------|------------------------| -| PCI-DSS | 引用 CIS Benchmarks 作为技术控制要求 | -| SOC 2 | 推荐 CIS Benchmarks 作为安全配置基线 | -| ISO 27001 | 参考 CIS Benchmarks 满足访问控制要求 | -| NIST CSF | CIS Benchmarks 映射到 NIST Cybersecurity Framework | -| FedRAMP | 使用 CIS Benchmarks 作为云服务安全基线 | - -## 工具支持 - -- **CIS-CAT Pro**：官方自动化评估工具，支持扫描并生成合规报告 -- **InSpec**：Chef 的合规性即代码框架，有 CIS Benchmark 配置文件 -- **OpenSCAP**：开源 CVE/配置扫描工具，有 CIS Benchmark 配置文件 -- **kube-bench**：Kubernetes CIS Benchmark 自动化评估工具 - -## 与其他安全标准的对比 - -| 标准 | 侧重点 | 适用范围 | -|------|--------|---------| -| CIS Benchmark | 安全配置最佳实践 | 操作系统、应用、云服务 | -| NIST SP 800-53 | 联邦信息安全控制 | 美国政府机构 | -| ISO 27001/27002 | 信息安全管理体系 | 所有组织 | -| DISA STIG | 国防部安全技术实施指南 | 美国国防部系统 | -| SOC 2 Trust Criteria | 服务组织控制 | SaaS/云服务提供商 | diff --git a/wiki/concepts/CMDB.md b/wiki/concepts/CMDB.md deleted file mode 100644 index c43d00fd..00000000 --- a/wiki/concepts/CMDB.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: "Configuration Management Database (CMDB)" -type: concept -tags: [cloud, devops, operations, itsm] -date: 2025-03-01 ---- - -## Definition - -配置管理数据库（CMDB）是存储IT基础设施中所有配置项（Configuration Items, CI）及其关系关系的数据库。在现代ITSM中，AI驱动的CMDB增强了依赖映射、漂移检测和实时影响分析能力。 - -## Traditional vs Modern CMDB - -| 维度 | 传统CMDB | AI-Enhanced CMDB | -|------|---------|------------------| -| 数据来源 | 手动录入 | 自动发现 | -| 关系映射 | 静态 | 动态 | -| 漂移检测 | 定期审计 | 实时监控 | -| 影响分析 | 人工推断 | AI预测 | -| 多云支持 | 有限 | 原生支持 | - -## Key Capabilities (Modern CMDB) - -### 1. Dependency Mapping -``` -服务 → 应用 → 中间件 → 数据库 → 基础设施 - ↓ ↓ ↓ ↓ ↓ -自动发现配置项及其依赖关系 -``` - -### 2. Drift Detection -- 配置变更自动检测 -- 与预期配置对比 -- 告警和自动修复 - -### 3. Real-time Impact Analysis -- 变更前影响预测 -- 事件影响范围评估 -- 服务依赖可视化 - -## In ITSM Context - -在[[ITSM]]中，CMDB是[[Configuration-Management]]的核心： - -``` -Configuration Management (ITSM 5.0) -├── AI-powered CMDB -│ ├── 依赖映射 -│ ├── 漂移检测 -│ └── 实时影响分析 -├── Multi-cloud Orchestration -│ ├── 公有云 -│ ├── 私有云 -│ └── 混合云 -└── Misconfiguration Prevention - └── 安全漏洞预防 -``` - -## Related Concepts - -- [[Configuration-Management]] — 配置管理流程 -- [[ITSM]] — CMDB的父框架 -- [[AIOps]] — AI驱动的CMDB能力 -- [[Cloud-Native]] — 多云CMDB支持 - -## Sources - -- [[understanding-complete-itsm]] — AI-CMDB在现代ITSM中的应用 diff --git a/wiki/concepts/CORS-Allowlist.md b/wiki/concepts/CORS-Allowlist.md deleted file mode 100644 index a4e4fc50..00000000 --- a/wiki/concepts/CORS-Allowlist.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "CORS-Allowlist" -type: concept -tags: [] -sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend] -last_updated: 2026-05-02 ---- - -## Definition -CORS Allowlist（跨域资源共享白名单）是一种浏览器安全机制，通过精确配置允许特定来源的跨域请求。 - -## Purpose -当浏览器中的前端应用（如 Open WebUI）调用不同域的后端 API 时，浏览器会先发送预检请求（OPTIONS），服务器需明确允许该来源才能放行。 - -## Configuration in Hermes Agent -Hermes Agent API Server 支持 CORS Allowlist 配置： -- **环境变量**：`CORS_ALLOWED_ORIGINS` 设置允许的域名列表 -- **默认值**：仅允许配置列表中的来源 -- **安全建议**：生产环境仅开放必要的域名 - -## Example -``` -CORS_ALLOWED_ORIGINS=https://app.openwebui.com,https://chat.example.com -``` - -## Related -- [[OpenAI-Compatible-API]] -- [[hermes-agent]]（via Hermes-Agent.md） diff --git a/wiki/concepts/CSS-Design-System.md b/wiki/concepts/CSS-Design-System.md deleted file mode 100644 index 4586b983..00000000 --- a/wiki/concepts/CSS-Design-System.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: "CSS Design System" -type: concept -tags: [css, design-system, frontend, architecture] -sources: [design-ux-architect.md] -last_updated: 2026-04-24 ---- - -## Definition - -CSS Design System 是一套结构化的 CSS 架构规范，通过 CSS Custom Properties（CSS 变量）定义颜色、排版、间距等基础设计 Token，供整个项目复用，确保视觉一致性和主题切换能力。 - -## Core Components - -### Color System -```css -:root { - /* Light Theme Colors */ - --bg-primary: [spec-light-bg]; - --bg-secondary: [spec-light-secondary]; - --text-primary: [spec-light-text]; - --text-secondary: [spec-light-text-muted]; - --border-color: [spec-light-border]; - - /* Brand Colors */ - --primary-color: [spec-primary]; - --secondary-color: [spec-secondary]; - --accent-color: [spec-accent]; -} -``` - -### Typography Scale -```css -:root { - --text-xs: 0.75rem; /* 12px */ - --text-sm: 0.875rem; /* 14px */ - --text-base: 1rem; /* 16px */ - --text-lg: 1.125rem; /* 18px */ - --text-xl: 1.25rem; /* 20px */ - --text-2xl: 1.5rem; /* 24px */ - --text-3xl: 1.875rem; /* 30px */ -} -``` - -### Spacing System -```css -:root { - --space-1: 0.25rem; /* 4px */ - --space-2: 0.5rem; /* 8px */ - --space-4: 1rem; /* 16px */ - --space-6: 1.5rem; /* 24px */ - --space-8: 2rem; /* 32px */ - --space-12: 3rem; /* 48px */ - --space-16: 4rem; /* 64px */ -} -``` - -## Theme Support - -CSS Design System 必须原生支持三种主题模式： - -- **Light Theme**：浅色背景，深色文字 -- **Dark Theme**：深色背景，浅色文字 -- **System Theme**：`prefers-color-scheme` 检测系统偏好 - -```css -[data-theme="dark"] { - --bg-primary: [spec-dark-bg]; - --bg-secondary: [spec-dark-secondary]; - --text-primary: [spec-dark-text]; - --text-secondary: [spec-dark-text-muted]; - --border-color: [spec-dark-border]; -} - -@media (prefers-color-scheme: dark) { - :root:not([data-theme="light"]) { - --bg-primary: [spec-dark-bg]; - /* ... */ - } -} -``` - -## Related Concepts - -- [[Theme-Toggle]]：主题切换交互组件 -- [[Theme-Manager]]：JavaScript 主题管理类 -- [[Layout-Framework]]：基于此系统的布局架构 -- [[Component-Architecture]]：组件样式规范 - -## Sources - -- [[design-ux-architect]] — CSS Design System 的完整定义和示例代码 diff --git a/wiki/concepts/CTV-OTT-Advertising.md b/wiki/concepts/CTV-OTT-Advertising.md deleted file mode 100644 index 041557e4..00000000 --- a/wiki/concepts/CTV-OTT-Advertising.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "CTV/OTT Advertising" -type: concept -tags: ["ctv", "ott", "streaming", "paid-media", "video"] -sources: ["paid-media-programmatic-buyer"] -last_updated: 2026-04-26 ---- - -## Definition - -CTV/OTT Advertising（Connected TV / Over-the-Top Advertising）是指在联网电视设备和流媒体服务上投放的视频广告形式。CTV（Connected TV）指通过互联网连接的消费设备（如 Smart TV、Roku、Amazon Fire TV、Apple TV），OTT（Over-the-Top）指通过互联网直接传输到设备的视频内容订阅服务（如 Netflix、Hulu、Disney+ 等）。 - -## CTV vs OTT - -| 类型 | 设备/平台 | 内容传输方式 | -|------|---------|------------| -| CTV | Smart TV、Roku、Fire TV、Apple TV | 设备通过互联网接收内容 | -| OTT | 独立应用（Netflix、Hulu 等） | 直接通过互联网传输到任何设备 | - -## Ad Formats - -- **Pre-roll**：在流媒体内容播放前展示（最常见） -- **Mid-roll**：在内容中途插入，类似于传统电视广告时段 -- **Post-roll**：在内容结束后展示 -- **Pause Ads**：用户暂停播放时展示的全屏广告 -- **Display Overlay**：视频播放时的底部横幅展示 - -## Buying Methods - -- **Programmatic Direct**：通过程序化直接预订优质流媒体库存 -- **Private Marketplace（PMP）**：与特定流媒体平台建立私有交易 -- **Open Exchange**：公开程序化竞价购买 CTV 库存 - -## Key Metrics - -- **Impression Share**：广告展示占可寻址库存的比例 -- **Completion Rate**：视频广告完整播放率（目标 ≥80%） -- **Viewability Rate**：联网电视 MRC 标准（50% 像素可见 2 秒） -- **Audible Rate**：音频被激活的展示比例（视频广告） -- ** household Coverage**：触达的家庭单位数量 - -## Why CTV/OTT for Brand Extension - -- **传统电视的数字化延伸**：以程序化方式触达线性电视受众 -- **优质内容环境**：流媒体内容的品牌安全性和可见性通常高于数字展示 -- **高级定向能力**：超越传统电视的人口统计定向，实现行为和意图定向 -- **跨设备归因**：结合数字展示和CTV数据构建更完整的受众画像 - -## Related Concepts -- [[Programmatic Buying]] -- [[Viewability]] -- [[Frequency Cap]] - -## Sources -- [[paid-media-programmatic-buyer]] diff --git a/wiki/concepts/Caddy.md b/wiki/concepts/Caddy.md deleted file mode 100644 index 6a280d02..00000000 --- a/wiki/concepts/Caddy.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: "Caddy" -type: concept -tags: [networking, web-server, https, reverse-proxy, golang] -last_updated: 2026-04-03 ---- - -## Aliases -- Caddy Server -- Caddy Web Server -- Caddyfile - -## Definition -Caddy 是一款由 Go 语言编写的开源 Web 服务器，以其零配置自动 HTTPS 特性著称——首次访问域名时自动向 Let's Encrypt 申请并续期 SSL/TLS 证书，无需手动配置。支持反向代理、静态文件服务、FastCGI、负载均衡等常用功能。Caddyfile 是其独特的配置格式，简洁易读，适合个人和小型部署。 - -## Core Features -- **自动 HTTPS**：首次访问自动申请 Let's Encrypt 证书，支持 ACME DNS-01 挑战（适合内网） -- **HTTP/3 支持**：默认启用 QUIC/HTTP3 -- **反向代理**：简洁的 `reverse_proxy` 指令 -- **Caddyfile**：人类可读的配置文件格式 -- **默认 TLS 1.3**：安全开箱即用 -- **热重载**：配置修改自动生效，无需重启 - -## Caddyfile 语法示例 -```caddy -# 基础反向代理 -example.com { - reverse_proxy localhost:8080 -} - -# 多域名配置 -nas.ishenwei.online { - reverse_proxy 127.0.0.1:15000 -} - -n8n.ishenwei.online { - reverse_proxy 127.0.0.1:15678 -} - -# 带基础认证 -admin.example.com { - basicauth /* { - admin - } - reverse_proxy localhost:5678 -} -``` - -## 常用命令 -```bash -# 验证配置语法 -sudo caddy validate --config /etc/caddy/Caddyfile - -# 热重载配置 -sudo caddy reload - -# 彻底重启 -sudo systemctl restart caddy - -# 查看状态 -sudo systemctl status caddy - -# 生成密码哈希 -caddy hash-password -``` - -## 与 Nginx 的对比 -| 特性 | Caddy | Nginx | -|------|-------|-------| -| 自动 HTTPS | ✅ 默认 | ❌ 需手动配置 | -| 配置语法 | 简洁 Caddyfile | 复杂块结构 | -| 性能 | 略低于 Nginx | 极高 | -| 热重载 | ✅ 原生支持 | ❌ 需 signal | -| HTTP/3 | ✅ 默认 | 需额外编译 | -| 学习曲线 | 低 | 中高 | - -## 在本 Wiki 中的应用 -- [[通过VPS+内网反向代理实现域名访问内网穿透]]：Caddy 反向代理到 frp 映射端口，提供 `*.ishenwei.online` HTTPS 访问 -- 映射关系： - - `nas.ishenwei.online` → `127.0.0.1:15000` - - `n8n.ishenwei.online` → `127.0.0.1:15678` - - `transmission.ishenwei.online` → `127.0.0.1:19091` - - `grafana.ishenwei.online` → `127.0.0.1:13000` - - `navidrome.ishenwei.online` → `127.0.0.1:14533` - - `calibre.ishenwei.online` → `127.0.0.1:18083` - -## 重要限制 -- **Caddy 不处理 SSH**：SSH 穿透（TCP 映射）不走 Caddy，只依赖 frps + frpc -- **Caddy 不处理 UDP**：UDP 流量（如 DNS）需要其他方案 - -## Related Concepts -- [[反向代理]]：Caddy 是反向代理的具体实现 -- [[内网穿透]]：Caddy 通常与 frp 配合，Caddy 提供 HTTPS，frp 建立隧道 -- [[TCP隧道]]：Caddy 处理 HTTP/HTTPS 层；TCP 隧道（Caddy 不参与） - -## Related Entities -- [[RackNerd]]：Caddy 部署的 VPS 提供商 -- [[VPS]]：运行 Caddy 的公网服务器 - -## References -- 官网: https://caddyserver.com/ -- 文档: https://caddyserver.com/docs/ -- Caddyfile 语法: https://caddyserver.com/docs/caddyfile diff --git a/wiki/concepts/Calibration-Testing.md b/wiki/concepts/Calibration-Testing.md deleted file mode 100644 index 86d816cd..00000000 --- a/wiki/concepts/Calibration-Testing.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: "Calibration Testing" -type: concept -tags: [model-evaluation, probability-calibration, model-quality] -sources: - - specialized-model-qa -last_updated: 2026-05-29 ---- - -## Definition - -概率校准（Calibration Testing）验证模型输出的预测概率与实际发生的频率是否一致。一个校准良好的分类器：若它预测某事件概率为 80%，则该事件实际发生的频率应接近 80%。 - -## Core Methods - -### Hosmer-Lemeshow Test -- 将预测概率分组（默认10组），比较每组观测正例数与期望正例数 -- 统计量：$\chi^2 = \sum \frac{(observed - expected)^2}{expected(1 - expected/n)}$ -- 自由度：组数 - 2；p-value < 0.05 → 拒绝原假设（校准差） -- **局限性**：对样本量敏感，分组方式不同结果不同 - -### Brier Score -- $BS = \frac{1}{N}\sum(p_i - y_i)^2$，取值 [0, 0.25]（二分类） -- 同时衡量校准（calibration）和区分度（refinement） -- 值越低越好，可分解为：$BS = Calibration^2 + Refinement$ -- **优势**：无需分组，对样本量稳健，可跨模型比较 - -### Reliability Diagram（可靠性图） -- 将预测概率分箱（bin），绘制实际正例率 vs 预测概率 -- 理想情况为 45° 对角线；S 形曲线表示欠/过度预测 -- 视觉诊断工具，适合识别系统性校准偏差 - -### Expected Calibration Error (ECE) -- 加权平均每箱预测概率与实际频率的绝对差 -- $ECE = \sum_b \frac{|b|}{n} |acc(b) - conf(b)|$ -- 量化校准误差，便于跨模型对比 - -## Usage - -```python -# Hosmer-Lemeshow -from scipy.stats import chi2 - -def hosmer_lemshow_test(y_true, y_pred, groups=10): - data = pd.DataFrame({"y": y_true, "p": y_pred}) - data["bucket"] = pd.qcut(data["p"], groups, duplicates="drop") - agg = data.groupby("bucket", observed=True).agg( - n=("y", "count"), observed=("y", "sum"), expected=("p", "sum") - ) - hl_stat = (((agg["observed"] - agg["expected"])**2) / - (agg["expected"] * (1 - agg["expected"]/agg["n"]))).sum() - dof = len(agg) - 2 - p_value = 1 - chi2.cdf(hl_stat, dof) - return {"HL_statistic": round(hl_stat, 4), "p_value": round(p_value, 6), "calibrated": p_value >= 0.05} - -# Brier Score -from sklearn.metrics import brier_score_loss -bs = brier_score_loss(y_true, y_pred) -``` - -## Model QA 中的应用 - -Model QA Specialist 执行以下校准审计： -1. **跨子群体校准**：在年龄/地区/收入等子群体上分别测试，发现整体指标掩盖的局部校准问题 -2. **时间窗口稳定性**：跨 OOT（Out-of-Time）窗口测试校准稳定性，识别时间漂移 -3. **分布偏移下的校准**：在压力场景（population shift）下测试，评估模型鲁棒性 -4. **决策阈值校准**：根据业务决策阈值（如 p > 0.6 触发行动），评估该阈值处的校准质量 - -## Relationship - -- **依赖** [[Discrimination-Metrics]]：先验证模型有区分能力（AUC/Gini），再讨论校准才有意义 -- **依赖** [[SHAP]]：SHAP 解释"哪个特征导致校准偏差"，支撑诊断方向 -- **依赖** [[Population-Stability-Index]]：PSI 捕捉特征分布漂移，漂移是校准失效的根本原因之一 -- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的核心审计步骤之一 - -## Key Insights - -- **High AUC ≠ Well Calibrated**：模型可以高区分度但低校准（如逻辑回归自然校准，神经网络往往过度自信） -- **业务影响**：校准误差 180bps（0.18）在 decile 10 可能影响 12% 的资产组合 -- **监管要求**：巴塞尔协议/IFRS 9/CCAR 等监管框架明确要求信用风险模型的概率校准 diff --git a/wiki/concepts/Call-Worthy-Threshold.md b/wiki/concepts/Call-Worthy-Threshold.md deleted file mode 100644 index 4a3343f0..00000000 --- a/wiki/concepts/Call-Worthy-Threshold.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Call-Worthy Threshold" -type: concept -tags: [notification, prioritization, alerting, UX] -sources: [phone-call-notifications] -last_updated: 2026-04-23 ---- - -## Definition - -Call-Worthy Threshold 是判断某个事件是否值得触发电话通知的评估标准。核心原则：**电话通知必须稀缺，只有真正重要的信息才配得上占用用户的电话注意力**。如果 Agent 每天打电话 10 次，用户就会开始忽视电话——电话的价值在于其稀缺性。 - -## Decision Framework - -Agent 评估是否"值得打电话"时，应考虑： - -### 紧急程度（Urgency） -- 是否有时间敏感性？延迟处理会有什么后果？ -- 优先级递减：紧急（立即影响）> 重要（今天内需处理）> 参考（可稍后阅读） - -### 影响范围（Impact） -- 对用户的直接财务/健康/安全影响有多大？ -- 优先级递减：高影响（金钱/健康/安全）> 中影响（机会成本）> 低影响（信息） - -### 可替代性（Substitutability） -- 是否可以用更低打扰的方式通知？ -- 优先级递减：无法替代 > 低打扰通知不足 > 简单通知即可 - -## Anti-Patterns - -- **通知疲劳**：Agent 频繁打电话 → 用户开始忽略 → 真正重要的电话也被忽视 -- **过载包装**：将 10 条普通消息合并成一条电话播报 → 信息过载，用户无法聚焦 -- **误判优先级**：小事打电话，大事发消息 → 优先级判断标准混乱 - -## Best Practices - -1. **明确定义阈值**：用户应与 Agent 协商"什么情况打电话"，形成清晰标准 -2. **定期审计**：每月检查电话触发记录，确保频率保持在用户舒适范围内 -3. **日志可见**：用户可查看电话触发历史，理解 Agent 的判断逻辑 -4. **双向反馈**：用户说"这事不值得打电话"时，Agent 应记住并调整阈值 - -## Examples - -| Event | Worth Calling? | Reason | -|-------|---------------|--------| -| NVDA 股价暴跌 5% | ✅ Yes | 财务影响大，时间敏感 | -| 老板发来紧急邮件 | ✅ Yes | 高度时间敏感，潜在重大影响 | -| 天气预报提醒带伞 | ❌ No | 低紧急性，普通推送即可 | -| 日程冲突提醒 | ❌ No | 提前提醒，低紧急性 | -| 服务器完全宕机 | ✅ Yes | 安全/业务影响，即时行动必需 | - -## Related Concepts - -- [[Voice Notification Channel]] — 电话通道的价值建立在稀缺性之上 -- [[Alerting]] — 告警规则设计应与通知阈值协同 -- [[Preference Learning]] — Agent 可从用户反馈中学习阈值偏好 - -## Sources - -- [[phone-call-notifications]] diff --git a/wiki/concepts/Canary-Deployment.md b/wiki/concepts/Canary-Deployment.md deleted file mode 100644 index 45015ef7..00000000 --- a/wiki/concepts/Canary-Deployment.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Canary Deployment" -type: concept -tags: - - Deployment - - ECS - - IaC -sources: - - learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi -last_updated: 2023-08-08 ---- - -## Definition -Canary Deployment（金丝雀部署）是一种渐进式发布策略，通过逐步将流量从旧版本切换到新版本，降低新版本上线风险——先让少量用户（"金丝雀"）使用新版本，观察无异常后再全量发布。 - -## How It Works -1. **小流量引入**：新版本部署后，仅将少量流量（如 5-10%）引导至新版本实例 -2. **监控验证**：通过 CloudWatch/Grafana 等监控指标对比新旧版本表现 -3. **渐进切换**：验证通过后，逐步增加新版本流量比例（如 25% → 50% → 100%） -4. **自动回滚**：若新版本指标异常，自动将流量切回旧版本 - -## ECS Context -ECS 模块内置 Canary Deployment 支持，结合 ALB（Application Load Balancer）的目标组权重规则，实现零停机渐进式发布。 - -## Connections -- [[ECS-Module]] ← includes ← Canary Deployment -- [[Infrastructure-as-Code]]：Canary 部署通过 Terraform IaC 定义 -- [[Auto-Scaling]]：常与自动扩缩容配合使用 diff --git a/wiki/concepts/Canary-Release.md b/wiki/concepts/Canary-Release.md deleted file mode 100644 index b7301fea..00000000 --- a/wiki/concepts/Canary-Release.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "Canary Release" -type: concept -tags: [devops, deployment, release-management, automation] -date: 2025-03-01 ---- - -## Definition - -金丝雀发布（Canary Release）是一种渐进式软件发布策略，将新版本首先部署给小部分用户，验证稳定性后再逐步扩大范围，最终替换全部用户。这种策略降低了全量发布风险，实现近乎零干扰的发布。 - -## How It Works - -``` -Phase 1: 5% Traffic Phase 2: 20% Traffic Phase 3: 100% Traffic -┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ -│ New Version │ │ New Version │ │ Old Version │ -│ ██ │ │ ████ │ │ ░░░░ │ -│ 5% users │ │ 20% users │ │ Rollback if │ -└─────────────────┘ └─────────────────┘ │ issues │ - ↓ ↓ └─────────────────┘ - Monitor metrics Monitor + Auto-rollback ↓ - Auto-promote if failure rate ↑ Full Deployment -``` - -## Key Metrics to Monitor - -| 指标 | 描述 | 告警阈值 | -|------|------|---------| -| Error Rate | 错误率变化 | +2% | -| Latency | 响应时间 | +50ms | -| Business KPIs | 转化率、订单量 | -5% | -| Resource Usage | CPU/内存 | +30% | - -## In ITSM Context - -在[[ITSM 2.0]]的[[Release-Management]]中，金丝雀发布是关键实践： - -``` -Release Management 2.0 -├── Canary Release -│ ├── 渐进式流量转移 -│ ├── 实时监控 -│ └── 自动回滚 -├── Blue-Green Deployment -│ ├── 零停机切换 -│ └── 快速回滚 -└── Feature Flags - ├── 精细化控制 - └── A/B Testing -``` - -## Related Concepts - -- [[Release-Management]] — 发布管理总框架 -- [[Blue-Green-Deployment]] — 蓝绿部署 -- [[Feature-Flag]] — 特性开关 -- [[Progressive-Rollout]] — 渐进式发布 -- [[Deployment-Automation]] — 部署自动化 - -## Sources - -- [[understanding-complete-itsm]] — Canary Release在现代ITSM中的应用 diff --git a/wiki/concepts/Canvas.md b/wiki/concepts/Canvas.md deleted file mode 100644 index d8dbc0b0..00000000 --- a/wiki/concepts/Canvas.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Canvas" -type: concept -tags: [obsidian, skills, visualization] -last_updated: 2026-04-21 ---- - -## Definition -Canvas（画布）是 Obsidian 的 JSON 格式白板文件格式，用于在 Obsidian 中创建可视化节点布局，包含文本节点、文件节点、链接节点和组节点，以及节点之间的连线逻辑。 - -## Skill 版本对比 - -| Skill | 发布者 | 推荐度 | 特点 | -|-------|--------|--------|------| -| [[Json-Canvas]] | kepano | ❌ | 底层 JSON 语法正确性，AI 可能机械摆放节点 | -| [[Obsidian-Canvas-Creator]] | Axton | ✅ | 高层排版策略，自动计算坐标，处理连线，径向/自由排版算法 | - -## Canvas 文件结构 -- **节点类型**：text（文本）、file（文件）、link（链接）、group（组） -- **布局属性**：每个节点有 x/y 坐标、宽度、高度 -- **连线逻辑**：source/target 节点 + 端点位置 - -## Connections -- [[Obsidian-Canvas-Creator]] — 推荐使用的 Skill -- [[Json-Canvas]] — 底层格式（不推荐直接使用） -- [[obsidian-必装-skills]] — 来源文档 diff --git a/wiki/concepts/Cash-Flow-Forecasting.md b/wiki/concepts/Cash-Flow-Forecasting.md deleted file mode 100644 index e1e792cb..00000000 --- a/wiki/concepts/Cash-Flow-Forecasting.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Cash Flow Forecasting" -type: concept -tags: ["finance", "forecasting", "liquidity"] -last_updated: 2026-04-30 ---- - -## Definition -现金流预测是通过历史模式分析和季节性因子，对企业未来若干期（通常为 12 期滚动）的现金收支进行量化预测的过程，旨在维持流动性并优化资金使用效率。 - -## Core Components -- **历史模式分析**：按月聚合 receipts（收款）、payments（付款）、net_cash_flow（净现金流）的均值和标准差 -- **季节性因子**：针对不同月份应用季节性调整系数，反映周期性波动 -- **增长因子**：根据业务增长趋势调整预测基准 -- **置信区间**：通常设置 ±15% 的置信区间（如 net_cash_flow × 0.85 / 1.15） - -## Key Metrics -- **累积现金**（cumulative_cash）：当前现金余额 + 预测期净现金流之和 -- **低现金预警**：累积现金 < $50,000 时触发，行动建议为加速收款或延迟付款 -- **高现金机会**：累积现金 > $200,000 时触发，建议考虑短期投资或预付费用 - -## Payment Timing Optimization -根据以下公式计算支付优先级分数： -``` -priority_score = early_pay_discount × amount × 365 / payment_terms -``` -优先处理高折扣机会，同时维持现金流健康。 - -## Implementation -参见 [[support-finance-tracker]] 中 `CashFlowManager` Python 类的实现。 - -## Related Concepts -- [[Budget Variance Analysis]]：与现金流预测同为财务规划核心工具 -- [[ROI]]：投资回报评估与现金流优化相互关联 diff --git a/wiki/concepts/Centralized-Logging.md b/wiki/concepts/Centralized-Logging.md deleted file mode 100644 index 88918da2..00000000 --- a/wiki/concepts/Centralized-Logging.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Centralized Logging -type: concept -tags: [DevOps, Observability, CloudOps, AWS] -date: 2025-10-24 ---- - -## Definition -Centralized Logging（集中日志）是一种将分散在多个系统、账户、服务或地理位置的日志汇总到单一中心位置进行统一管理的模式。核心目标是在分布式系统中消除监控盲区，提供全局可观测性。 - -## Core Properties -- **聚合**：将多个来源的日志合并到单一存储 -- **统一查询**：跨来源的集中搜索和分析 -- **集中告警**：基于聚合数据的统一告警策略 -- **合规保留**：统一的数据保留和合规策略 - -## Related Concepts -- [[Multi-Account Deployment]]：多账户场景是集中日志的主要驱动因素 -- [[Cross-Account Monitoring]]：跨账户监控依赖集中日志基础设施 -- [[StackSets Deployment Visibility]]：StackSets 部署可观测性依赖集中日志 -- [[Event Sourcing]]：集中日志可以视为事件溯源的一种实现 -- [[APM]]（Application Performance Monitoring）：APM 工具通常依赖集中日志数据 -- [[CloudWatch Logs]]：AWS 生态系统中的集中日志存储服务 -- [[Prometheus]]：时间序列监控，可与集中日志互补 - -## Implementation Patterns -1. **日志采集层**：Agent/Fluentd/Firelens 收集各来源日志 -2. **传输层**：EventBridge/Kinesis/Firehose 传输日志事件 -3. **存储层**：CloudWatch Logs/OpenSearch/S3 + Athena -4. **分析层**：CloudWatch Logs Insights/OpenSearch Dashboards/Grafana Loki -5. **告警层**：CloudWatch Alarms/Grafana Alerting/PagerDuty - -## AWS Context -- AWS CloudWatch Logs：AWS 原生日志存储和分析服务 -- AWS EventBridge：事件驱动的日志采集路由 -- AWS CloudTrail：AWS API 调用的审计日志（集中日志的特殊形式） -- AWS Systems Manager OpsCenter：基于集中日志的运营问题管理 -- [[Centralized Logging]] ← uses ← [[Amazon EventBridge]] ← routes ← [[Amazon CloudWatch Logs]] diff --git a/wiki/concepts/Certora.md b/wiki/concepts/Certora.md deleted file mode 100644 index a9d05c51..00000000 --- a/wiki/concepts/Certora.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: "Certora（形式化验证工具）" -type: concept -tags: [blockchain, security, smart-contract, formal-verification, tooling] -sources: [blockchain-security-auditor] -last_updated: 2026-05-30 ---- - -## Aliases -- Certora -- Certora Prover -- Certora Verification System - -## Definition - -Certora 是一个基于符号执行（Symbolic Execution）的智能合约形式化验证工具，通过 CVL（Certora Verification Language）描述协议规范，系统性证明 Solidity 合约的关键属性是否在所有可能状态下成立。与测试不同，Certora 可以证明某个属性**在数学上不可能被违反**。 - -## Key Capabilities - -- **属性证明**：验证合约不变性（invariant）在所有执行路径上成立 -- **反例生成**：当属性无法被证明时，自动生成导致属性失败的最小执行序列 -- **多合约分析**：支持分析调用关系复杂的合约系统 -- **并行验证**：可并行验证多条规则 - -## CVL Example - -``` -rule noUnauthorizedWithdrawal(method f) { - env e; - calldataarg args; - - require f != nop; // 排除空调用 - - // 如果调用成功，则调用者必须是所有者 - f(e, args); - assert e.msg.sender == owner, "Unauthorized withdrawal"; -} - -invariant totalSupplyInvariant() { - // 总供应量恒定 - invariant totalSupply == init(totalSupply); -} -``` - -## Integration with Foundry - -Certora 可与 Foundry 集成： -```bash -# 使用 Halmos 进行字节码级验证 -forge test --match-contract CertoraTest - -# 使用 Certora CLI -certora Run Vault.spec Vault.sol --prover z3 cvc5 -``` - -## Limitations - -- 需要人工编写精确的 CVL 规范（规范本身可能出错） -- 复杂合约状态空间可能导致超时 -- 对外部依赖和链上状态处理有限 -- 学习曲线陡峭 - -## Relationship to Audit - -- Certora 是 [[Blockchain-Security-Auditor]] 进行 [[Formal-Verification]] 的主要工具 -- 适合验证关键协议属性：份额不变性、借贷健康度、权限不变性 -- 与 [[Slither]] 互补：Slither 找代码模式漏洞，Certora 证明数学属性 - -## Connections -- [[Blockchain-Security-Auditor]] ← uses ← [[Certora]] -- [[Formal-Verification]] ← implements ← [[Certora]] -- [[Halmos]] ← complementary bytecode verification ← [[Certora]] diff --git a/wiki/concepts/Chained Agents.md b/wiki/concepts/Chained Agents.md deleted file mode 100644 index cacac019..00000000 --- a/wiki/concepts/Chained Agents.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Chained Agents" -type: concept -tags: [multi-agent, workflow, automation] -sources: [content-factory] -last_updated: 2026-04-22 ---- - -## Definition - -Chained Agents（链式 Agent）是一种多 Agent 协作模式，其中上游 Agent 的输出直接作为下游 Agent 的输入，无需人工逐步干预。核心价值在于将复杂任务拆解为多个专业化子任务，通过流水线式编排实现全自动化执行。 - -## Key Characteristics - -- **顺序依赖**：Agent A 输出 → Agent B 输入 → Agent B 输出 → Agent C 输入 -- **无需人工中转**：每个环节由 Agent 自动触发和推进 -- **可插拔**：可替换任意环节 Agent（如将本地模型替换为 API） -- **透明可查**：通过 Discord 频道等隔离机制，每个 Agent 的工作独立可审查 - -## Example: Content Factory - -``` -Research Agent (#research) - → 输出：Top 5 内容机会（含来源） - ↓ -Writing Agent (#scripts) - → 输出：完整脚本/推文串/Newsletter 草稿 - ↓ -Thumbnail Agent (#thumbnails) - → 输出：AI 生成的缩略图/封面 -``` - -## Related Concepts - -- [[Multi-Agent Coordination]]：多 Agent 协作的整体框架 -- [[Workflow Architecture]]：工作流架构设计原则 -- [[Content Automation]]：内容创作自动化 diff --git a/wiki/concepts/ChalkboardStyle.md b/wiki/concepts/ChalkboardStyle.md deleted file mode 100644 index b5994f5d..00000000 --- a/wiki/concepts/ChalkboardStyle.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "ChalkboardStyle" -type: concept -tags: ["ai-image", "visual-style", "prompt-engineering"] -last_updated: 2026-05-01 ---- - -## Definition - -Chalkboard Style（黑板粉笔风格）是一种复古手绘视觉风格，通过深绿黑背景、手绘粉笔线条、严格限制的 6 色配色盘和木框边框实现统一的视觉氛围，常用于 AI 信息图设计。 - -## Visual Specifications - -### Background -- 颜色：#1C2B1C（深绿黑色） -- 纹理：粉笔灰痕迹、细微划痕、橡皮擦涂抹痕迹 - -### Color Palette（严格限制 6 色） -| 颜色 | Hex 值 | 用途 | -|------|--------|------| -| 粉笔白 | #F5F5F5 | 主要文字、轮廓线 | -| 粉笔黄 | #FFE566 | 高亮、下划线、强调 | -| 粉笔粉 | #FF9999 | 次级高亮、图标 | -| 粉笔蓝 | #66B3FF | 图表、技术元素 | -| 粉笔绿 | #90EE90 | 成功、自然、正面 | -| 粉笔橙 | #FFB366 | 警告、能量 | - -### Lines & Typography -- 所有线条必须手绘、速写式（slightly wavy/imperfect） -- 禁止完美几何形状 -- 禁止渐变效果 -- 禁止数字感强的字体 - -### Frame & Decoration -- 木框边框（hand-drawn wood grain 线条） -- 手绘星星（5-7 点，不规则） -- 手绘下划线（波浪形） -- 手绘箭头（速写式） -- 手绘圆形围绕关键词 -- 手绘对勾标记 -- 散落粉笔灰粒子 - -### Prohibited Elements -- NO gradients（禁止渐变） -- NO perfect geometric shapes（禁止完美几何形状） -- NO photorealistic elements（禁止写实元素） -- NO clean digital vectors（禁止干净的数字矢量） - -## Application - -在 AI 图片生成提示词中使用时，需要： -1. 在 [[StyleSeed]] 中定义完整的视觉参数 -2. 在 [[StyleLock]] 中添加逐项检查清单 -3. 通过 hex 色值消除颜色描述的歧义 - -## Sources - -- [[如何让AI生成风格一致的图片]] diff --git a/wiki/concepts/Challenger-Sales-Model.md b/wiki/concepts/Challenger-Sales-Model.md deleted file mode 100644 index 9650b359..00000000 --- a/wiki/concepts/Challenger-Sales-Model.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "Challenger Sales Model" -type: concept -tags: ["sales", "methodology", "coaching"] -sources: ["sales-coach", "sales-deal-strategist", "sales-outbound-strategist"] -last_updated: 2026-04-25 ---- - -## Definition - -Challenger Sales Model 是由 CEB（现 Gartner）开发的高绩效销售方法论，核心洞察是：**最优秀的销售代表通过商业洞察重新构建买家的思考方式**，而不是简单回应买家的已知需求。 - -## Core Principle - -**"Teach, Tailor, Take Control"** - -- **Teach for differentiation**: 通过独特的商业洞察引发买家对问题的重新思考 -- **Tailor for value**: 根据买家的具体情境定制信息 -- **Take Control of the sale**: 主动控制销售节奏和对话方向 - -## vs Traditional Selling - -| 传统销售 | Challenger 销售 | -|---------|----------------| -| 倾听买家需求 | **重构**买家对问题的理解 | -| 以产品功能回应 | 以商业洞察引领 | -| 被动跟随买家节奏 | 主动控制销售过程 | -| 提供解决方案 | 创造新的思考框架 | - -## Application in Sales Coaching - -[[sales-coach]] 使用 Challenger 模型作为辅导工具： - -- 教导销售代表"以商业洞察引领对话"，而非"回应已知需求" -- 核心辅导问题："你能提供什么买家还不知道的洞察？" -- 区分"响应式销售"（买家的思路）和"重构式销售"（改变买家的思路） - -## Key Insight - -买家通常在接触销售之前已经对解决方案有了初步想法。Challenger 销售不是否定买家的想法，而是在买家思考的基础上添加新的维度，让他们以不同的方式看待自己的业务。 - -## Deal-Level Application（[[sales-deal-strategist]]） - -[[sales-deal-strategist]] 将 Challenger 框架延伸为 **Commercial Teaching（商业教学）六步序列**： - -1. **The Warmer**：展示对买方世界的理解，引用行业通用挑战作为信号 -2. **The Reframe**：引入挑战买方当前假设的洞察，"大多数公司用X方式处理这个问题，但数据显示为什么规模化后会失败" -3. **Rational Drowning**：量化现状成本，堆叠证据直到当前方法变得不可持续 -4. **Emotional Impact**：让痛点个人化。谁每天承受这个痛苦？如果这事没解决，VP 的数字会怎样？ -5. **A New Way**：提出替代方法——还不是产品，而是方法论 -6. **Your Solution**：此时才连接到产品。"产品"应感觉像是必然结论而非销售话术 - -核心原则：**永远先重构理解，再展示方案**；决策在理性层面被论证，在感性层面被做出。 - -## Connections -- [[sales-coach]] ← uses ← [[Challenger Sales Model]] -- [[sales-deal-strategist]] ← uses ← [[Challenger Sales Model]]（Commercial Teaching 六步序列） -- [[MEDDPICC]] ← often used alongside ← [[Challenger Sales Model]] diff --git a/wiki/concepts/Champion-Challenger.md b/wiki/concepts/Champion-Challenger.md deleted file mode 100644 index 5a4f77b6..00000000 --- a/wiki/concepts/Champion-Challenger.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Champion-Challenger Framework" -type: concept -tags: [model-evaluation, model-deployment, champion-challenger, model-governance] -sources: - - specialized-model-qa -last_updated: 2026-05-29 ---- - -## Definition - -Champion-Challenger 框架（冠军-挑战者框架）是一种系统化的模型替代评估方法：在生产环境保持当前模型（Champion）运行的同时，引入新候选模型（Challenger）并行评分，通过量化对比决定是否将 Challenger 升级为新的 Champion。核心目标：在保证业务稳定性的前提下，以数据驱动的方式持续提升模型质量。 - -## Core Mechanics - -### Shadow Mode Deployment（影子模式） -- Challenger 模型在生产流量上实时评分，但**不实际影响决策** -- 所有输出被记录但不触发行动 -- 优势：无需 A/B 分流风险，收集真实分布数据 - -### A/B Split（分流测试） -- 将生产流量按比例分配给 Champion 和 Challenger -- Challenger 的预测直接触发实际决策 -- 适用场景：需要真实业务反馈且风险可控时 - -### Multi-Challenger Ranking -- 同时存在多个 Challenger 时，按以下优先级评估： - 1. **统计显著性**：AUC/KS 提升是否有统计意义（DeLong test） - 2. **业务影响**：性能提升的绝对业务价值（Revenue/Cost/Conversion） - 3. **稳定性**：Challenger 在各子群体和时间窗口上的表现一致性 - 4. **可解释性**：SHAP 特征重要性是否发生重大结构性变化 - -## Model QA 中的应用 - -Model QA Specialist 使用 Champion-Challenger 框架执行以下审计： -1. **基准建立**：记录 Champion 模型的 AUC/Gini/KS 基准值和跨切片表现 -2. **Challenger 评估**：对候选模型进行全 10 域审计，不限于性能指标 -3. **迁移决策**：只有 Challenger 在**所有关键域**达到或超越 Champion 时才建议迁移 -4. **回滚计划**：每次 Challenger 上线必须有可执行的回滚方案 - -## Relationship - -- **依赖** [[Discrimination-Metrics]]：AUC/Gini/KS 是量化 Champion vs Challenger 差异的核心指标 -- **依赖** [[Calibration-Testing]]：Hosmer-Lemeshow 检验确保 Challenger 在各子群体上的校准稳定性 -- **依赖** [[Population-Stability-Index]]：PSI 监控 Challenger 在生产分布上的稳定性 -- **依赖** [[SHAP]]：SHAP 对比分析 Challenger vs Champion 的特征贡献结构变化 -- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 性能与监控步骤中的基准对比工具 - -## Key Insights - -- **不只看 AUC**：Champion 升级决策必须综合考虑性能、公平性、校准和业务影响 -- **时间窗口**：必须收集足够长时间（至少一个业务周期）的 Challenger 数据 -- **灰度发布**：避免一次性全量切换，先小比例验证再扩大 -- **监管合规**：金融/医疗等受监管行业的模型更换须符合模型变更治理流程 diff --git a/wiki/concepts/Change-Failure-Rate.md b/wiki/concepts/Change-Failure-Rate.md deleted file mode 100644 index 3b61974d..00000000 --- a/wiki/concepts/Change-Failure-Rate.md +++ /dev/null @@ -1,83 +0,0 @@ -# Change Failure Rate - -## Definition -Change Failure Rate (CFR) is the percentage of deployments that cause failures in production — such as service outages, degraded performance, or incidents requiring hotfixes, rollbacks, or patches. - -Change Failure Rate is one of the four core **DORA metrics** used to measure DevOps performance. - -## Why Change Failure Rate Matters - -A low change failure rate indicates: -- High confidence in the deployment process -- Robust testing and quality assurance -- Effective risk management -- Mature operational practices - -A high change failure rate means: -- Frequent production incidents -- Unstable deployments -- Low team confidence -- Customer impact - -## Across DevOps Maturity Levels - -| Maturity | Change Failure Rate Characteristic | -|----------|-----------------------------------| -| Phase 1 | High — manual processes, no automated testing, siloed teams, security only at release | -| Phase 2 | Improving — unit, integration, and end-to-end tests implemented, but security separate | -| Phase 3 | Lower — automated infrastructure, security scans integrated throughout development | -| Phase 4 | Significantly reduced — performance/load testing, immutable infrastructure, dependency vulnerability management | -| Phase 5 | 0-15% (elite) — zero human intervention, real-time data decisions, high-level security integration prevents non-compliant code | - -## Elite Performance Benchmark (DORA) -- **Elite performers**: 0-15% change failure rate -- **High performers**: 16-30% change failure rate -- **Medium performers**: 16-30% change failure rate -- **Low performers**: 31-100% change failure rate - -## Types of Failed Changes -- Production outages -- Service degradations -- Data corruption -- Security vulnerabilities introduced -- Performance regressions -- Failed rollbacks - -## How to Reduce Change Failure Rate - -### Technical Practices -- Comprehensive test automation (unit, integration, E2E) -- Feature flags for gradual rollouts -- Canary deployments -- Blue-green deployments -- Automated rollback mechanisms -- Chaos engineering to find weaknesses before production - -### Process Improvements -- Code review requirements -- Security scanning in CI/CD pipeline -- Staging environment parity with production -- Small batch sizes to limit blast radius -- Dependency management and vulnerability scanning - -### Cultural Factors -- Blameless post-mortems -- Learning from failures -- Psychological safety to report issues -- Shared ownership of reliability - -## Relationship with Other DORA Metrics -- **Deployment Frequency**: Higher frequency with lower CFR indicates elite performance -- **Lead Time**: Shorter lead times with maintained/low CFR = high performance -- **MTTR**: Lower CFR means fewer incidents, contributing to lower overall MTTR - -## Sources -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] -- [[sources/cloud-devop-maturity-guideline.md]] - -## Related Concepts -- [[concepts/DORA-Metrics]] -- [[concepts/Continuous-Deployment]] -- [[concepts/DevOps-Maturity]] -- [[concepts/Error-Budget]] -- [[concepts/Rollback-Rate]] diff --git a/wiki/concepts/Change-Management.md b/wiki/concepts/Change-Management.md deleted file mode 100644 index 145e379b..00000000 --- a/wiki/concepts/Change-Management.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "Change-Management" -type: concept -tags: [Organizational-Change, Process-Improvement, ITSM] -sources: [testing-workflow-optimizer, understanding-complete-itsm] -last_updated: 2026-04-21 ---- - -# Change-Management - -变更管理——在组织中系统性地规划、实施和控制人员、流程和技术变更的管理学科。核心目标是降低变更风险、提高采纳率、确保变革产生预期业务价值，同时最小化对现有服务运营的干扰。 - -## Aliases -- 变革管理 -- 组织变革管理 -- IT Change Management（ITSM 语境） - -## Core Frameworks - -### Kotter's 8-Step Change Model -1. **Create Urgency**（创造紧迫感）——让利益相关者认识到变革必要性 -2. **Build Guiding Coalition**（组建指导联盟）——建立变革领导团队 -3. **Form Strategic Vision**（形成战略愿景）——清晰描述变革后的未来状态 -4. **Enlist a Volunteer Army**（动员志愿者）——让尽可能多的人参与 -5. **Enable Action by Removing Barriers**（消除障碍）——移除阻碍变革的结构性和文化性壁垒 -6. **Generate Short-Term Wins**（创造短期胜利）——通过快速成果建立信心 -7. **Sustain Acceleration**（持续加速）——保持势头，不给反对派喘息空间 -8. **Institute Change**（固化变革）——将变革融入组织文化 - -### ADKAR Model（Prosci） -- **A**wareness（认知）——了解为什么需要变革 -- **D**esire（渴望）——愿意参与和支持变革 -- **K**nowledge（知识）——知道如何变革 -- **A**bility（能力）——能够实施新行为 -- **R**einforcement（强化）——巩固变革成果 - -## In ITSM Context（ITIL Change Management） -在 ITSM 框架中，变更管理分为： -- **标准变更（Standard Change）**：预批准的低风险例行变更 -- **正常变更（Normal Change）**：需经 CAB（变更顾问委员会）评估和批准 -- **紧急变更（Emergency Change）**：突发事件驱动的快速变更，事后评估 - -## In Workflow Optimization -[[testing-workflow-optimizer]] 在实施流程优化时必须考虑变更管理： -- **测量基线**前先建立利益相关者共识 -- **设计优化方案**需要获得关键干系人认同 -- **实施规划**必须包含培训和沟通计划 -- **自动化落地**需要克服员工的恐惧和阻力 - -## Common Pitfalls -- **变革疲劳（Change Fatigue）**：频繁变更导致员工抵触 -- **忽略人因素**：只关注流程和技术，忽视人的情感 -- **缺乏可见成果**：没有短期胜利导致失去支持 -- **变革太快或太慢**：节奏失控 - -## Connections -- [[testing-workflow-optimizer]] — 流程优化落地的必要保障机制 -- [[ITSM]] — ITSM 框架中的三大核心流程之一 -- [[Kaizen]] — 持续改进需要有效的变更管理支撑 diff --git a/wiki/concepts/Channel-Based-Monitoring.md b/wiki/concepts/Channel-Based-Monitoring.md deleted file mode 100644 index 1c68980c..00000000 --- a/wiki/concepts/Channel-Based-Monitoring.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Channel-Based Monitoring" -type: concept -tags: [Channel, Monitoring, YouTube, RSS, Subscription] -sources: [daily-youtube-digest, how-to-get-youtube-channel-id, how-to-get-the-rss-feed-for-any-youtube-channel] -last_updated: 2026-04-22 ---- - -## Definition - -Channel-Based Monitoring 是一种以订阅频道为单位跟踪内容更新的策略——用户明确指定感兴趣的频道列表，AI Agent 定期检查这些频道的最新上传，而非被动依赖平台推荐算法。 - -## Why Not Just Use YouTube Notifications? - -YouTube 通知系统不可靠：订阅频道的新视频经常不会出现在通知或首页推荐中，被平台算法压制。Channel-Based Monitoring 通过主动检查（RSS Feed / API）绕过这一限制。 - -## Implementation - -- **RSS Feed**: `https://www.youtube.com/feeds/videos.xml?channel_id=` -- **TranscriptAPI**: `channel/latest` API（免费，0 积分） -- **yt-dlp**: `--flat-playlist` 模式 - -### Getting Channel ID - -参考 [[how-to-get-youtube-channel-id]]：在浏览器地址栏打开 `view-source:https://www.youtube.com/@ChannelName`，搜索 `channel_id` 字符串即可获得 RSS Feed URL。 - -## Connections -- [[Channel-Based Monitoring]] ← powers ← [[Daily YouTube Digest]] -- [[RSS Feed]] ← feeds ← [[Channel-Based Monitoring]] -- [[Keyword-Based Monitoring]] ← complements ← [[Channel-Based Monitoring]] diff --git a/wiki/concepts/Chaos-Physics.md b/wiki/concepts/Chaos-Physics.md deleted file mode 100644 index 73550d20..00000000 --- a/wiki/concepts/Chaos-Physics.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Chaos Physics" -type: concept -tags: ["unreal-engine", "physics", "destruction", "chaos-engine"] -sources: ["unreal-systems-engineer"] -last_updated: 2026-05-30 ---- - -## Aliases -- Chaos Destruction System -- UE5 Chaos Physics Engine -- Geometry Collections - -## 定义 -Chaos 是 UE5 的物理与破坏系统，提供实时网格破碎、刚体约束和高级物理模拟能力。 - -## 核心组件 - -### Geometry Collections -- 用于实时网格破碎的破碎几何体集合 -- 在 Fracture Editor 中制作破碎资产 -- 通过 `UChaosDestructionListener` 触发破碎事件 - -### Constraint Types -Chaos 支持多种约束类型： -- **Rigid**（刚性）— 固定断裂块之间的连接 -- **Soft**（柔性）— 允许一定形变的连接 -- **Spring**（弹簧）— 带弹性的连接 -- **Suspension**（悬挂）— 模拟悬挂系统 - -### Destruction LOD -- 近景：完整 Chaos 模拟 -- 远景：缓存动画播放（降低计算开销） - -## 性能分析 -使用 **Unreal Insights** 的 Chaos 专用 trace 通道分析物理求解器性能。 - -## 相关概念 -- [[Actor Replication]] — 破碎物理的网络复制注意事项 -- [[UnrealEngine5]] — Chaos 是 UE5 的内置物理引擎 diff --git a/wiki/concepts/ChapterBlueprint.md b/wiki/concepts/ChapterBlueprint.md deleted file mode 100644 index faa0f242..00000000 --- a/wiki/concepts/ChapterBlueprint.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Chapter Blueprint" -type: concept -tags: ["writing", "structure", "planning", "workflow"] -sources: ["marketing-book-co-author"] -last_updated: 2026-04-30 ---- - -## Definition - -章节蓝图（Chapter Blueprint）是 Book Co-Author Agent 在起草正文之前，先定义章节承诺（Chapter Promise）、读者收益和战略功能的结构化规划工具。它是叙事架构（[[Narrative Architecture]]）在章节层面的具体化。 - -## Blueprint Structure - -```markdown -## Chapter Promise -- What this chapter proves（本章证明什么） -- Why the reader should care（读者为什么在乎） -- Strategic role in the book（本章在全书的战略角色） - -## Section Logic -1. Opening scene or tension（开场场景或张力） -2. Core argument（核心论点） -3. Supporting example or lesson（支撑案例或教训） -4. Shift in perspective（视角转换） -5. Closing takeaway（结尾要点） -``` - -## Why Blueprint Before Drafting - -1. **防止主题漂移**：没有蓝图，章节容易同时承载过多论点（"tries to do three jobs"） -2. **对齐全书定位**：每个章节都服务于作者的品类定位，而非泛化的"好建议" -3. **编辑前置**：蓝图阶段的决策比草稿阶段的修改成本更低 -4. **委托方对齐**：蓝图是与委托方确认章节方向的机会，避免方向性返工 - -## Blueprints vs Traditional Outlines - -| 维度 | 章节蓝图 | 传统大纲 | -|------|---------|---------| -| 核心问题 | "本章要证明什么？" | "本章要包含哪些内容？" | -| 视角 | 读者收益导向 | 内容清单导向 | -| 关注点 | 战略功能 | 覆盖范围 | -| 与品类定位关系 | 显式关联 | 隐含关联 | - -## Related Concepts -- [[Narrative Architecture]] — 章节蓝图是叙事架构在单章层面的工具 -- [[Thought Leadership Book]] — 章节蓝图为思想领导力书籍服务 -- [[Ghostwriting]] — 章节蓝图是代笔写作流程的重要组成部分 diff --git a/wiki/concepts/Character-Arc.md b/wiki/concepts/Character-Arc.md deleted file mode 100644 index 0c052bff..00000000 --- a/wiki/concepts/Character-Arc.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "角色弧光" -type: concept -tags: [narratology, character-development, story-structure] -sources: ["academic-narratologist"] -last_updated: 2026-05-02 ---- - -## Definition - -**角色弧光**（Character Arc）是叙事中角色从**起点状态**到**终点状态**的内在变化轨迹。与角色类型（静态/扁平/圆形）不同，弧光关注角色经历了什么样的**内在转变**。 - -[[academic-narratologist]] 将角色弧光分解为四个维度： -- **Want**（欲望）：角色外部追求的目标 -- **Need**（需求）：角色内心真正需要的东西（通常与 Want 不同） -- **Lie**（信念谎言）：角色持有的错误信念，是内在冲突的核心 -- **Transformation**（蜕变）：角色是否以及如何面对 Lie、实现 Need - -## Arc Types（角色弧光类型） - -| 类型 | 描述 | 典型模式 | -|------|------|---------| -| **Transformative**（蜕变型） | 角色经历核心转变，Lie 被打破，Need 得到满足 | 英雄之旅的高潮 | -| **Steadfast**（坚定型） | 角色坚守信念，即使面对毁灭性代价（悲剧英雄） | Hamlet, V | -| **Flat**（扁平型） | 角色没有内在变化，但改变了他人或世界 | Sherlock Holmes | -| **Negative**（负面型） | 角色向更坏的状态坠落 | Walter White（后期） | -| **Comedic**（喜剧型） | 角色通过纠正错误信念找到幸福 | Rom-com 主人公 | - -## Arc Checkpoints（弧光检查点） - -[[academic-narratologist]] 采用的故事结构分析框架（基于 Vogler）： - -1. **Ordinary World**（日常世界）：角色起点状态，Lie 信念已存在 -2. **Catalyst**（催化剂）：打破日常的事件，Want 被激活 -3. **Midpoint Shift**（中点转移）：假胜利或假失败，角色开始质疑 Lie -4. **Dark Night of the Soul**（灵魂黑夜）：最低点，Want 彻底失败 -5. **Transformation**（蜕变）：角色面对并打破 Lie，拥抱 Need - -## Fabula-Sjuzhet 在角色弧光中的作用 - -- **Fabula** 决定：角色实际经历了哪些事件（影响弧光的事件顺序） -- **Sjuzhet** 决定：读者何时知道角色的哪些经历（影响读者对弧光的感知节奏） - -## Applications in AI Agent - -- [[academic-narratologist]] 在分析角色动机时使用弧光框架 -- 在[[Character-Arc]]诊断中，心理分析只能作为**视角**而非**处方**使用——角色不是案例研究对象 - -## Related Concepts - -- [[Fabula-Sjuzhet]]：弧光的展开层次（事件 vs 呈现） -- [[Propp-Morphology]]：Donor/Hero 功能与弧光催化剂的对应 -- [[Campbell-Monomyth]]：英雄的蜕变弧光模板 -- [[Defense-Mechanisms]]：角色如何通过防御机制维持 Lie 信念 diff --git a/wiki/concepts/Character-Voice-Pillars.md b/wiki/concepts/Character-Voice-Pillars.md deleted file mode 100644 index c975fa69..00000000 --- a/wiki/concepts/Character-Voice-Pillars.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: "Character Voice Pillars" -type: concept -tags: [game-narrative, character-design, dialogue] -sources: [narrative-designer.md] -last_updated: 2026-04-26 ---- - -# Character Voice Pillars - -角色声音柱——定义角色语言特征的五个维度体系，确保角色在所有对话中保持声音一致性。 - -## Definition - -Character Voice Pillars 是一套用于精确描述角色说话方式的框架，包含五个相互独立又共同构成完整声音形象的维度。通过明确定义每个维度，团队中的所有编剧都能写出风格一致的角色台词。 - -## Five Pillars - -### 1. Vocabulary（词汇） -- **正式/随意**：角色的语言规范程度 -- **专业/通俗**：是否使用行业术语、俚语、方言 -- **情绪强度**：词汇的情感烈度（冷漠旁观 ↔ 情绪激烈） - -### 2. Sentence Rhythm（句子节奏） -- **短促/断续**：适合紧迫、强硬、攻击性场景 -- **绵长/复合**：适合沉思、回忆、哲学性对话 -- **节奏变化**：单一节奏 vs. 随情绪状态变化 - -### 3. Topics Avoided（禁忌话题） -- 每个角色都有不愿意直接谈论的领域 -- 这些禁忌本身就在传递角色信息 -- 定义禁忌话题比定义擅长话题更重要 - -### 4. Verbal Tics（口癖） -- 特定短语、重复句式、犹豫词 -- 角色特有的口头禅或语气词 -- **注意**：口癖必须服务于角色，不能仅为辨识度而添加 - -### 5. Subtext Default（潜台词倾向） -- **直白型**：角色说啥就是啥，从不绕弯子 -- **迂回型**：永远话里有话，需要玩家推断真实意图 -- **回避型**：在特定敏感话题上故意偏离正题 - -## Application - -### Voice Pillar 文档格式 -``` -## Character: [Name] -### Identity -- Role in Story: [Protagonist / Antagonist / Mentor / etc.] -- Core Wound: [What shaped this character's worldview] -- Desire: [What they consciously want] -- Need: [What they actually need, often in tension with desire] - -### Voice Pillars -- Vocabulary: [描述] -- Sentence Rhythm: [描述] -- Topics They Avoid: [列表] -- Verbal Tics: [列表] -- Subtext Default: [描述] - -### What They Would Never Say -[3 example lines that sound wrong for this character] - -### Reference Lines -[已批准的语音示例，标注每个示例演示的维度] -``` - -## Why It Matters -- **团队一致性**：多个编剧在不了解彼此时，仍能写出风格统一的对话 -- **玩家识别度**：90%+ 玩家仅凭对话能正确识别角色性格 -- **分支可信度**：Branching Narrative 的选择后果感，依赖选择时角色声音的一致性 - -## Related Concepts -- [[Branching Narrative]]：Voice Pillar 是分支选择可信度的基础 -- [[Dialogue Writing Standards]]：Voice Pillar 是写作标准的具体化 -- [[Character Voice Pillars]]：引用自身 - -## Sources -- [[Narrative Designer Agent Personality]] — Character Voice Pillars Template diff --git a/wiki/concepts/CharacterArc.md b/wiki/concepts/CharacterArc.md deleted file mode 100644 index 4a01247a..00000000 --- a/wiki/concepts/CharacterArc.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Character Arc" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-30 ---- - -## Aliases -- Character Arc -- 角色弧线 -- 角色发展弧 - -## Overview -Character Arc（角色弧线）描述角色在叙事过程中从起始状态到终态的内在变化轨迹。与角色在情节中采取的行动（Plot Arc）不同，Character Arc 关注角色的内心世界、信念体系和心理成熟度。 - -## Arc Types - -| Type | Description | -|------|-------------| -| **Transformative** | 角色核心信念被颠覆，实现内在成长或改变 | -| **Steadfast** | 角色信念被考验但最终被确认为正确坚守 | -| **Flat** | 角色不经历内在变化（通常是功能性角色） | -| **Tragic** | 角色因无法克服内在缺陷或错误选择而走向毁灭 | -| **Comedic** | 角色通过接受内在真相获得和谐/社会整合 | - -## Core Components（[[Academic Narratologist]] 模型） - -### Four Checkpoints -1. **Want（欲望/外在目标）**：角色在情节中追求的具体目标 -2. **Need（需求/内在必要性）**：角色真正需要获得的东西（通常与其 Want 不同） -3. **Lie（信念谎言）**：角色持有但需要被挑战的错误信念 -4. **Transformation（蜕变）**：角色面对真相时的内在改变 - -### Supporting Elements -- **Ghost/Wound**：驱动角色行为的过往创伤或经历 -- **Backstory**：支撑 Ghost 的具体事件 - -## Application -[[Academic Narratologist]] 的核心分析工具之一。每个角色弧线都必须有清晰的 want/need/lie/transformation 四个要素，并通过故事事件逐一验证。 diff --git a/wiki/concepts/ChatCompletions.md b/wiki/concepts/ChatCompletions.md deleted file mode 100644 index 0acdfebe..00000000 --- a/wiki/concepts/ChatCompletions.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "ChatCompletions" -type: concept -tags: - - "openai" - - "api" - - "chat" -sources: [] -last_updated: 2026-04-20 ---- - -## Overview - -Chat Completions 是 OpenAI 标准的聊天补全 API 格式，通过 `POST /v1/chat/completions` 端点调用。Hermes Agent 的 API Server 默认使用此模式，无需额外配置。 - -## Key Characteristics - -- **请求格式**：`{"model": "...", "messages": [...]}` -- **响应格式**：返回 `choices[].message` 完整回复 -- **历史管理**：每次请求携带完整对话历史 -- **工具调用**：支持 `tools` / `tool_calls` 参数 -- **流式输出**：支持 `stream: true`，实时推送 token - -## vs Responses API - -| 特性 | Chat Completions | Responses API | -|---|---|---| -| 状态管理 | 客户端携带历史 | 服务端 `previous_response_id` | -| 事件流 | 逐 token 块 | 结构化事件（text_delta, function_call） | -| 稳定性 | 稳定（默认） | 实验性 | -| 适用场景 | 通用对话 | 需要服务端状态追踪的场景 | - -## See Also -- [[APIServer]] -- [[ResponsesAPI]] diff --git a/wiki/concepts/Check-in-Fatigue.md b/wiki/concepts/Check-in-Fatigue.md deleted file mode 100644 index fa98111b..00000000 --- a/wiki/concepts/Check-in-Fatigue.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Check-in Fatigue" -type: concept -tags: [] -last_updated: 2026-04-17 ---- - -## Definition - -当追踪的习惯数量过多时，用户因签到负担过重而开始忽略或跳过签到消息，最终导致整个习惯追踪系统失效的行为现象。 - -## Symptom - -- 用户停止回复每日的签到消息 -- 连续天数开始归零，但用户不再关心 -- AI Agent 的消息变成"已读不回" -- 用户最终完全停止使用系统 - -## Root Cause - -**信号淹没**（Signal-to-Noise Ratio Degradation）：当每日签到数量超过认知负荷阈值（建议 3-5 个），大脑将所有签到消息归类为低优先级噪音，选择性忽略。 - -| 追踪习惯数量 | 认知负荷 | 预期行为 | -|------------|---------|---------| -| 1-3 个 | 极低 | 高参与率 | -| 3-5 个 | 可接受 | 良好参与率 | -| 6-10 个 | 较高 | 逐渐疲劳 | -| 10+ 个 | 过高 | 系统性忽略 | - -## Mitigation Strategy - -1. **初始限制**：系统建立时严格限制习惯数量为 3-5 个 -2. **渐进添加**：新习惯须等现有习惯稳定（连续 ≥14 天）后才添加 -3. **季度回顾**：定期评估每个习惯的参与率，淘汰参与率持续低于 50% 的习惯 -4. **优先级排序**：不在同一时间发送多个签到请求，分散到全天不同时段 - -## Related Concepts -- [[Active Accountability]] — Check-in Fatigue 是 Active Accountability 系统的失效模式 -- [[Streak Tracking]] — 当用户开始忽视签到，Streak 连续天数自然归零 - -## Source -- [[habit-tracker-accountability-coach]] diff --git a/wiki/concepts/CheckinFatigue.md b/wiki/concepts/CheckinFatigue.md deleted file mode 100644 index 8fcbeee0..00000000 --- a/wiki/concepts/CheckinFatigue.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Check-in Fatigue" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-27 ---- - -# Check-in Fatigue - -## Definition -当追踪的习惯数量过多时，用户因签到负担过重而开始忽略消息，导致系统失效的现象。这是习惯追踪系统最常见的失败模式之一。 - -## Threshold -建议追踪 3-5 个习惯。超过此数量，用户会因签到疲劳开始忽视消息推送。 - -## Symptoms -- 用户开始"已读不回"签到提醒 -- 连续漏签但未主动调整目标 -- 用户主动关闭通知或禁用 Agent - -## Mitigation -- 从小处开始（2-3个核心习惯），形成稳定节奏后再扩展 -- 设置优先级，区分"必须追踪"和"可选追踪" -- Agent 定期询问用户是否需要调整目标数量 - -## Used In -- [[Habit Tracker & Accountability Coach]]：关键设计原则 - -## Related Concepts -- [[Active Accountability]]：需要控制频率以避免 fatigue -- [[Adaptive Tone]]：可动态调整签到频率以缓解疲劳 diff --git a/wiki/concepts/Checks-Effects-Interactions.md b/wiki/concepts/Checks-Effects-Interactions.md deleted file mode 100644 index 27e7f377..00000000 --- a/wiki/concepts/Checks-Effects-Interactions.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: "Checks-Effects-Interactions Pattern" -type: concept -tags: [blockchain, security, smart-contract, reentrancy, best-practices] -sources: [blockchain-security-auditor] -last_updated: 2026-05-30 ---- - -## Aliases -- Checks-Effects-Interactions -- CEI Pattern -- Checks-Effects-Interactions Pattern - -## Definition - -Checks-Effects-Interactions（CEI，检查-效果-交互）模式是智能合约安全编程的核心防御模式，用于防止重入攻击和其他逻辑漏洞。其核心原则是：**在执行任何外部调用之前，先完成所有的状态检查和状态更新**。 - -## Pattern - -``` -function withdraw() external { - // 1. CHECKS — 验证前置条件 - require(balances[msg.sender] > 0, "No balance"); - - // 2. EFFECTS — 更新合约状态（在外部调用之前） - balances[msg.sender] = 0; - - // 3. INTERACTIONS — 执行外部调用（最后一步） - (bool success,) = msg.sender.call{value: amount}(""); - require(success, "Transfer failed"); -} -``` - -## Why It Works - -传统重入攻击利用的漏洞链： -``` -外部调用（ETH转账）→ 攻击者receive()被触发 -→ 攻击者 re-enter withdraw() -→ balances[msg.sender] 仍 > 0（未清零） -→ 重复提取资金 -``` - -CEI 模式切断漏洞链：**状态在外部调用之前清零**，即使攻击者 re-enter，条件检查阶段 `require(balances[msg.sender] > 0)` 已失败。 - -## Common Mistakes - -### Wrong Order (Vulnerable) -```solidity -// VULNERABLE: 外部调用在状态更新之前 -(bool success,) = msg.sender.call{value: amount}(""); -require(success); -balances[msg.sender] = 0; // 攻击者可在此之前 re-enter -``` - -### Missing Update (Vulnerable) -```solidity -// VULNERABLE: 状态根本没有更新 -require(balances[msg.sender] > 0); -(bool success,) = msg.sender.call{value: amount}(""); -require(success); -// balances[msg.sender] = 0; ← 忘记更新！ -``` - -### ERC-20 Transfer Before Update -```solidity -// VULNERABLE: ERC-20 transfer 触发外部调用 -IERC20(token).transfer(msg.sender, amount); // 外部调用 -balances[msg.sender] -= amount; // 状态更新太晚 -``` - -## Relationship to Other Defenses - -- **CEI is the primary defense** — should always be applied first -- **ReentrancyGuard is additional defense** — use when CEI is difficult to apply (complex logic, callbacks) -- CEI + ReentrancyGuard together provide defense in depth - -## Connections -- [[Reentrancy]] ← prevents ← [[Checks-Effects-Interactions]] -- [[Blockchain-Security-Auditor]] ← enforces ← [[Checks-Effects-Interactions]] -- [[ReentrancyGuard]] ← supplements ← [[Checks-Effects-Interactions]] diff --git a/wiki/concepts/ChecksEffectsInteractions.md b/wiki/concepts/ChecksEffectsInteractions.md deleted file mode 100644 index 752a5f88..00000000 --- a/wiki/concepts/ChecksEffectsInteractions.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "ChecksEffectsInteractions" -type: concept -tags: [] -last_updated: 2026-05-01 ---- - -## Definition -_checks-effects-interactions_ 是 Solidity 智能合约开发的核心安全原则，规定函数内操作必须按以下顺序执行： - -1. **Checks**：验证前置条件（require/assert 语句） -2. **Effects**：更新合约内部状态（状态变量修改） -3. **Interactions**：执行外部调用（token transfer、合约调用等） - -## Why It Matters -违反此顺序会导致 **重入攻击（Reentrancy Attack）**。如果外部调用在状态更新之前执行，攻击者的恶意合约可以在状态仍然显示"资金未提取"的情况下递归调用 withdraw()，反复提取资金。 - -### Vulnerable Pattern (违反 CEI) -```solidity -function withdraw(uint256 amount) external { - require(balances[msg.sender] >= amount); - // ❌ 外部调用在状态更新之前 - msg.sender.call{value: amount}(""); - balances[msg.sender] -= amount; // 太晚了 -} -``` - -### Secure Pattern (遵循 CEI) -```solidity -function withdraw(uint256 amount) external { - require(balances[msg.sender] >= amount); - balances[msg.sender] -= amount; // ✅ 先更新状态 - emit Withdrawal(msg.sender, amount); - msg.sender.call{value: amount}(""); // ✅ 最后外部调用 -} -``` - -## Sources -- [[engineering-solidity-smart-contract-engineer]] -- [[The-DAO]] -- [[blockchain-security-auditor]] diff --git a/wiki/concepts/ChinaLaborLawCompliance.md b/wiki/concepts/ChinaLaborLawCompliance.md deleted file mode 100644 index 47348aca..00000000 --- a/wiki/concepts/ChinaLaborLawCompliance.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "China Labor Law Compliance（中国劳动法合规）" -type: concept -tags: [compliance, labor-law, hr, china] -sources: [recruitment-specialist] -last_updated: 2026-04-25 ---- - -## 定义 -中国劳动法合规是指在招聘、入职、管理、离职全流程中，遵守《中华人民共和国劳动合同法》、《就业促进法》、《个人信息保护法》（PIPL）等法律法规的一系列要求。 - -## 在 [[Recruitment Specialist Agent]] 中的核心模块 - -### 劳动合同法要点 -- **合同签订**：入职30天内必须签订书面劳动合同，违者需支付双倍工资 -- **合同类型**：固定期限、无固定期限、项目型 -- **连续两次固定期限合同后**：员工有权要求签订无固定期限合同 - -### 试用期规定 -- 合同期3个月~1年：试用期 ≤ 1个月 -- 合同期1年~3年：试用期 ≤ 2个月 -- 合同期3年及以上：试用期 ≤ 6个月 -- 试用期工资 ≥ 约定工资的80% 且 ≥ 当地最低工资 -- 同一员工只能设定一次试用期 - -### 五险一金 -- **五险**：养老保险、医疗保险、失业保险、工伤保险、生育保险 -- **一金**：住房公积金 -- 入职30天内必须完成社保登记和缴纳 - -### 竞业限制 -- 期限 ≤ 2年 -- 补偿金通常 ≥ 离职前12个月平均月薪的30% -- 拖欠超过3个月，员工有权解除竞业义务 - -### 经济补偿（N+1） -- **N**：每满一年支付一个月工资 -- **N+1**：未提前30天通知，额外支付一个月工资 -- **违法解除**：2N 赔偿 -- 月工资上限：当地社会平均工资的3倍，最长计算12年 - -## 合规红线 -- 禁止就业歧视（性别、年龄、婚姻状况、民族、宗教） -- 背景调查需候选人书面授权 -- 候选人个人信息收集须符合 PIPL -- 提前排查竞业限制，避免招用有竞业义务的人员 - -## 连接 -- [[Recruitment Specialist Agent]] — 内置劳动法合规知识库 -- [[Recruitment Specialist Agent]] — 入职 SOP 中的合同签署和社保登记流程 diff --git a/wiki/concepts/Choice-Architecture.md b/wiki/concepts/Choice-Architecture.md deleted file mode 100644 index 5ce5367b..00000000 --- a/wiki/concepts/Choice-Architecture.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "Choice Architecture" -type: concept -tags: [game-narrative, choice-design, player-agency] -sources: [narrative-designer.md] -last_updated: 2026-04-26 ---- - -# Choice Architecture - -选择架构——设计玩家决策系统的学科，涵盖从有意义选择到刻意虚假选择的完整设计空间。 - -## Definition - -Choice Architecture 研究如何呈现、组织和框架化玩家的选择。它不只是"给玩家选择"——而是在精确设计的上下文中，通过精确设计的选项集合，引导玩家经历精确设计的心理旅程。 - -## Key Techniques - -### 1. 有意义选择（Meaningful Choice） -- 玩家在不同价值体系之间做出取舍 -- 选择后能感受到世界观的变化 -- 后果在 2 scenes 内可感知 - -### 2. 虚假选择（Fake Choice）的刻意使用 -- **不是设计失误，而是情感工具** -- 场景：特定叙事时刻，illusion of agency 比 real agency 更强大 -- 前提：玩家必须完全信任这个选择是真实的（否则失去情感效力） -- 边界：不能在同一游戏中既用 fake choice 又用 real choice（会导致玩家不信任所有选择） - -### 3. 延迟后果（Delayed Consequence） -- Act 1 的选择在 Act 3 显现后果 -- 创造"世界有记忆"的感觉 -- 需要额外的文档追踪（Narrative Debt Tracking） - -### 4. 后果可见性映射（Consequence Visibility Mapping） -| 后果类型 | 可见性 | 设计意图 | -|---------|--------|---------| -| 即时可见 | 高 | 强化选择-后果因果关系 | -| 延迟可见 | 中 | 创造世界记忆感 | -| 隐蔽 | 低 | 深层玩家的额外奖励 | - -### 5. 选择频率工程 -- 不是所有节点都需要选择 -- 过度选择 = 无选择感 -- 选择密度应与叙事节奏匹配（高潮时减少选择，思考时增加选择） - -## Narrative Debt Tracking -每个延迟后果都是一笔"叙事债务"： -- **记录**：所有伏笔（foreshadowing）和未兑现的承诺必须记录 -- **追踪**：在玩家达到收敛点前，必须有机制确保债务被偿还 -- **退役**：如果某个伏笔无法兑现，需要主动退役（明确告知玩家该线索不再相关） - -## Related Concepts -- [[Branching Narrative]]：Choice Architecture 定义何时用真选择 -- [[Narrative Debt Tracking]]：延迟后果的债务管理机制 -- [[Player Agency]]：选择架构必须与游戏机制层面的玩家自主权匹配 - -## Sources -- [[Narrative Designer Agent Personality]] — Choice Architecture and Agency Design diff --git a/wiki/concepts/Choreography.md b/wiki/concepts/Choreography.md deleted file mode 100644 index a3c06028..00000000 --- a/wiki/concepts/Choreography.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Choreography" -type: concept -tags: - - EDA - - Architecture - - Microservices -last_updated: 2026-04-14 ---- - -## Aliases -- Choreography Pattern -- 编舞模式 -- 去中心化事件协调 - -## Definition -编舞模式（Choreography）是一种微服务间通过事件进行自发协调的模式，各服务自主响应事件并发布新事件，无需中央协调器。服务通过事件总线了解全局状态和下一步操作。 - -## Characteristics -- **Decentralized**：无中央协调器，各服务平等 -- **Autonomous**：每个服务自主决定如何响应事件 -- **Loosely Coupled**：服务之间完全解耦，通过事件总线交互 -- **Resilient**：局部故障不影响其他服务 -- **Harder to Track**：整体业务流程不直观，调试复杂 - -## Example -1. 订单服务发布 `OrderCreated` 事件 -2. 库存服务订阅并发布 `InventoryReserved` 事件 -3. 支付服务订阅并发布 `PaymentProcessed` 事件 -4. 通知服务订阅并发送确认通知 - -## Comparison with Orchestration -| 维度 | Choreography（编舞） | Orchestration（编排） | -|------|---------------------|---------------------| -| 控制 | 去中心化 | 集中式 | -| 协调器 | 无 | 有（Step Functions） | -| 复杂度 | 局部低，整体高 | 局部高，整体低 | -| 可观测性 | 较难追踪 | 易于追踪 | -| 适用场景 | 简单、独立的服务 | 复杂、有明确业务流程 | - -## Sources -- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] -- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] diff --git a/wiki/concepts/Circuit-Breaker.md b/wiki/concepts/Circuit-Breaker.md deleted file mode 100644 index e509df11..00000000 --- a/wiki/concepts/Circuit-Breaker.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Circuit Breaker" -type: concept -tags: [] -sources: [engineering-autonomous-optimization-architect] -last_updated: 2026-05-01 ---- - -# Circuit Breaker - -## Definition - -熔断器模式（Circuit Breaker）——当某个 LLM API 端点连续失败超过预设阈值时，自动切断对该端点的路由，将流量切换到降级路径，同时向人工告警。 - -## Mechanism - -1. **Closed（正常）**：所有请求正常路由到目标端点 -2. **Open（熔断）**：端点连续失败超过阈值，立即切断路由，所有请求跳过该端点 -3. **Half-Open（半开）**：经过冷却期后，放行少量请求试探端点是否恢复 - -## Trigger Conditions - -- 端点流量异常激增（500%+，可能为恶意 bot 攻击） -- 连续出现 HTTP 402（需要付费）/ 429（速率限制）错误 -- 单次请求成本超过安全上限（如 $0.05/次） - -## Example - -```typescript -if (provider.failures > securityLimits.maxRetries) { - tripCircuitBreaker(provider); - routeToFallback(provider); - alertAdmin(`Circuit breaker tripped: ${provider.name}`); -} -``` - -## Related - -- [[Autonomous-Optimization-Architect]]：使用熔断器保护 AI 路由系统的核心组件 -- [[AI-FinOps]]：熔断器是 FinOps 成本控制的最后防线 diff --git a/wiki/concepts/CircuitBreaker.md b/wiki/concepts/CircuitBreaker.md deleted file mode 100644 index c52e63f2..00000000 --- a/wiki/concepts/CircuitBreaker.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "CircuitBreaker" -type: concept -tags: ["reliability", "fault-tolerance", "llm-ops"] -sources: ["engineering-autonomous-optimization-architect"] -last_updated: 2026-04-26 ---- - -## Aliases -- Circuit Breaker -- 熔断器 -- Circuit Breaker Pattern - -## Definition -熔断器模式是 [[AutonomousOptimizationArchitect]] 的核心安全机制——当某个 LLM Provider 的失败频率超过阈值（如 HTTP 402/429 错误、响应超时）时，自动切断该 Provider 并切换至廉价兜底方案，同时触发告警通知人工介入。 - -## Mechanism -1. **监测**：追踪每个 Provider 的失败计数和失败率 -2. **触发**：当失败次数超过 `maxRetries` 阈值，或检测到 HTTP 402/429 错误流时，立即 trip 熔断器 -3. **降级**：所有请求切换到预配置的廉价兜底 Provider（如 Gemini Flash） -4. **恢复**：人工确认问题解决后手动重置，或经过冷却期后自动尝试恢复 - -## Key Properties -- **防止成本失控**：阻止 Token 消耗攻击（如恶意 bot 短时间内大量请求） -- **防止无限重试**：每个 Provider 配置最大重试次数 `maxRetries` -- **分级降级**：逐级切换到更便宜的备用 Provider，直到找到可用路径 - -## Connections -- [[AutonomousOptimizationArchitect]] — 使用 CircuitBreaker 作为金融护栏的核心实现 -- [[LLMasJudge]] — 评估 Provider 降级后输出质量是否可接受 -- [[ShadowTraffic]] — 熔断触发后可异步在影子流量中测试备用 Provider diff --git a/wiki/concepts/Citation-Rate.md b/wiki/concepts/Citation-Rate.md deleted file mode 100644 index 2cc225e5..00000000 --- a/wiki/concepts/Citation-Rate.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Citation Rate" -type: concept -tags: ["metrics", "AEO", "GEO", "AI", "visibility"] -last_updated: 2026-04-26 ---- - -## Definition - -Citation Rate（引用率）是衡量品牌在 AI 推荐引擎中可见性的核心指标，表示品牌在特定 AI 平台的查询中被引用的频率百分比。计算方式： - -``` -Citation Rate = (品牌被引用次数 / 总查询次数) × 100% -``` - -## Application - -### Cross-Platform Audit -在多平台（ChatGPT、Claude、Gemini、Perplexity）上运行相同查询集，分别计算各平台的 Citation Rate，形成跨平台评分卡。 - -### Benchmarking -- **Category Average**：同类品牌在 AI 平台上的平均引用率 -- **Top Competitor Rate**：主要竞争对手的引用率 -- **Gap**：品牌引用率与竞品/均值之间的差距 - -### Tracking -定期（建议每 14 天）重新运行相同查询集，追踪 Citation Rate 变化，验证 Fix Pack 实施效果。 - -## Related Concepts - -- [[Answer Engine Optimization (AEO)]]：提升 Citation Rate 的策略框架 -- [[Generative Engine Optimization (GEO)]]：更广泛的生成式 AI 可见性优化 -- [[Fix Pack]]：提升 Citation Rate 的具体修复包 -- [[Lost Prompt Analysis]]：识别 Citation Rate 损失来源的方法 - -## Sources - -- [[AI Citation Strategist]] diff --git a/wiki/concepts/Claude-Code-Templates.md b/wiki/concepts/Claude-Code-Templates.md deleted file mode 100644 index 4c7b3879..00000000 --- a/wiki/concepts/Claude-Code-Templates.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Claude Code Templates" -type: concept -tags: [claude-code, claude-skills, npx] ---- - -## Definition - -Claude Code Templates 是一个通过 npm 包 `claude-code-templates` 分发的 Claude Code 增强模板库，提供预配置的 Skills（技能）、Agents（代理）和 MCP（Model Context Protocol 工具）三大类可复用模板。 - -## Core Properties - -- **分发方式**：npm 包 + npx 一键安装，无需手动复制粘贴 -- **模板来源**：社区维护，托管于 aitmpl.com -- **安装命令**：`npx claude-code-templates@latest --skill= --yes` -- **支持平台**：Claude Code、Trae IDE - -## Template Categories - -| 分类 | 说明 | 示例路径 | -|------|------|----------| -| Skills | 可复用的 AI 技能单元，封装专业工作流 | `development/git-commit-helper` | -| Agents | 预设角色和行为的专业代理模板 | `agents/` | -| MCP | 扩展 AI 工具调用能力的协议工具 | `mcps/` | - -## Usage Pattern - -```bash -# 进入项目目录 -cd your-project - -# 安装指定的 Skill -npx claude-code-templates@latest --skill=development/git-commit-helper --yes -``` - -## Related Concepts - -- [[Claude Code Skills]] — Claude Code 可复用能力单元 -- [[Claude Code]] — 目标增强工具 -- [[MCP（Model Context Protocol）]] — 工具扩展协议 - -## Aliases - -- claude-code-templates -- Claude Code Templates diff --git a/wiki/concepts/Claude-Skills.md b/wiki/concepts/Claude-Skills.md deleted file mode 100644 index 944b7012..00000000 --- a/wiki/concepts/Claude-Skills.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Claude Skills" -type: concept -tags: [claude, anthropic, ai-agent, skill, workflow] -last_updated: 2026-01-08 ---- - -## Definition -将反复执行的有固定流程的任务拆解为 AI 能理解、能稳定复用、能自动执行的一套流程。是 AI 应用从「提示词工程」向「流程工程」转变的核心产物，本质是写给 Claude 的"说明书"和"SOP（标准作业程序）"。 - -## Core Components -- **说明书**：告诉 Claude 做什么、怎么做 -- **SOP**：标准作业程序，确保流程稳定可复现 -- **工具集**：Claude 可调用的具体工具和能力 -- **容错策略**：异常处理和边界情况处理 - -## Key Principles -1. **只写 Agent 不知道的东西**：背景知识、专有信息、踩坑清单 -2. **重点写踩坑清单**：真实业务中容易出错的地方 -3. **给工具不给指令**：描述可用的工具能力，而非一步步的命令 -4. **可复用**：同一 Skill 可在不同项目中重复使用 -5. **可组合**：多个 Skill 可组合形成更复杂的 Agent 工作流 - -## Three-Layer Architecture -1. **描述层（Description）**：Skill 名称、功能、适用场景 -2. **指令层（Instructions）**：具体的 SOP、步骤、注意事项 -3. **工具层（Tools）**：Claude 可调用的 API、脚本、工具 - -## Related Concepts -- [[Claude Code Skills]]：Claude Code CLI 工具上的 Skills 实现 -- [[Vibe Coding]]：AI 辅助编程，Skills 是其规模化落地的关键 -- [[Workflow Engineering]]：流程工程，Skills 是其核心产物 -- [[AI Agent]]：Claude Skills 使 Agent 能够执行更复杂的自主任务 - -## Sources -- [[Anthropic/skills]]（github.com/anthropics/skills）— 官方 Claude Skills 仓库 -- [[3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1]] diff --git a/wiki/concepts/ClaudeCodePrintMode.md b/wiki/concepts/ClaudeCodePrintMode.md deleted file mode 100644 index 29a53440..00000000 --- a/wiki/concepts/ClaudeCodePrintMode.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Claude Code Print Mode" -type: concept -tags: [claude-code, hermes, ai-agent, terminal, non-interactive] -last_updated: 2026-04-27 ---- - -## Aliases -- Print Mode -- claude -p - -## Definition -Claude Code 的非交互单次执行模式。通过 `claude -p print` 命令调用，配合 stdin 传递任务描述文本，适合绝大多数自动化场景和 Hermes Agent 的程序化调用。 - -## How It Works -```bash -cat << 'TASK_END' | claude -p print \ - --dangerously-skip-permissions \ - --add-dir ~/.claude/skills/[技能名] \ - --add-dir [项目源码路径] \ - --add-dir /tmp \ - --max-turns 30 \ - 2>&1 -[具体任务描述] -TASK_END -``` - -## Key Parameters -- `--dangerously-skip-permissions`：跳过交互确认（信任目录、权限提示） -- `--add-dir <路径>`：添加可访问目录，可多次使用 -- `--max-turns N`：最大迭代次数，建议 20-30 -- `--bare`：跳过插件/MCP/CLAUDE.md 加载，最快启动 -- `--model <模型>`：指定模型，如 `sonnet`、`opus` -- `--output-format json`：结构化 JSON 输出 - -## Task Text Structure（stdin 写法规范） -``` -1. 告诉 Claude Code 要做什么 -2. 告诉它用哪个 skill -3. 告诉它目标文件输出到哪里 -4. 如果需要格式转换（如 SVG → PNG），明确写出转换命令 -5. 最后要求它输出 "done: 文件路径" -``` - -## Relationship to TMUX Mode -- Print Mode：适合绝大多数自动化场景，单次执行，无需后续交互 -- TMUX 交互模式：适合超长任务或需要中途干预的场景 - -## Sources -- [[Claude Code 调用方法总结]] - -## Connections -- [[ClaudeCodePrintMode]] ← 推荐使用 ← [[Claude Code]] -- [[ClaudeCodePrintMode]] ← 对比 ← [[ClaudeCodeTerminalIntegration]] diff --git a/wiki/concepts/ClaudeCodeTerminalIntegration.md b/wiki/concepts/ClaudeCodeTerminalIntegration.md deleted file mode 100644 index 4c358a9f..00000000 --- a/wiki/concepts/ClaudeCodeTerminalIntegration.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "Claude Code Terminal Integration" -type: concept -tags: [claude-code, hermes, ai-agent, terminal, tmux, subprocess] -last_updated: 2026-04-27 ---- - -## Aliases -- TMUX 交互模式 -- Claude Code TMUX Mode - -## Definition -Hermes Agent 通过 `terminal` 工具启动 Claude Code 进程的两种集成方式：Print Mode（推荐）和 TMUX 交互模式。这两种模式允许 Hermes 作为编排层调用 Claude Code CLI，实现外部 AI 工具的程序化调用。 - -## Two Integration Modes - -### Mode 1: Print Mode（推荐） -```bash -cat << 'TASK_END' | claude -p print \ - --dangerously-skip-permissions \ - --add-dir ~/.claude/skills/[技能名] \ - --max-turns 30 \ - 2>&1 -[任务描述] -TASK_END -``` -- 非交互单次执行 -- 适合绝大多数自动化场景 -- 优先选用 - -### Mode 2: TMUX 交互模式 -```bash -tmux new-session -d -s -x 140 -y 40 -tmux send-keys -t 'claude --permission-mode bypassPermissions' Enter -sleep 8 && tmux capture-pane -t -p -``` -- 适合超长任务或需要中途干预 -- 任务文本通过 `tmux send-keys` 发送 -- 使用 `--permission-mode bypassPermissions` 跳过确认 - -## Key Parameters - -| 参数 | 作用 | -|------|------| -| `--permission-mode bypassPermissions` | 直接设置 bypass 模式，跳过所有交互确认 | -| `--dangerously-skip-permissions` | 同上，但通过 CLI 内部触发，可能仍需交互确认 | -| `--add-dir <路径>` | 添加可访问目录，可多次使用 | -| `--max-turns N` | 最大迭代次数，建议 20-30 | -| `--bare` | 跳过插件/MCP/CLAUDE.md 加载，最快启动 | - -## Skill Loading -Claude Code 自动扫描 `--add-dir` 目录下的 `SKILL.md` 和 `.claude/skills/` 目录。 -```bash ---add-dir ~/.claude/skills/[技能名] # 加载指定技能 -``` - -## Sources -- [[Claude Code 调用方法总结]] - -## Connections -- [[ClaudeCodeTerminalIntegration]] ← 被 ← [[Hermes Agent]] -- [[ClaudeCodeTerminalIntegration]] ← 对比 ← [[SubagentDelegation]] diff --git a/wiki/concepts/Claudian.md b/wiki/concepts/Claudian.md deleted file mode 100644 index 1c748281..00000000 --- a/wiki/concepts/Claudian.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Claudian" -type: concept -tags: [obsidian, plugin, claude-code] -last_updated: 2026-04-21 ---- - -## Definition -Claudian 是 YishenTu 开发的 Obsidian 第三方插件，通过 BRAT 安装，适配 Claude Code Agent，实现自然语言驱动的 Obsidian 笔记管理。 - -## 安装方式 -1. 在 Obsidian 插件市场搜索并安装 **BRAT** -2. 打开"设置 → BRAT → Add Beta plugin" -3. 输入仓库地址：`YishenTu/claudian` -4. 点击 Add Plugin，等待下载完成 -5. 在"第三方插件"列表中启用 Claudian - -## 配置（可选：使用自定义模型） -```bash -ANTHROPIC_BASE_URL=https://open.bigmodel.cn/api/anthropic -ANTHROPIC_API_KEY=***key -ANTHROPIC_DEFAULT_OPUS_MODEL=GLM-5 -``` -可使用兼容 Anthropic 接口的模型（如智谱 GLM 或 DeepSeek）替换 Claude。 - -## 验证配置 -- `Ctrl/Cmd + P` 调出命令面板 → 输入 `claudian` → 选择 `Open chat view` -- 发送"你好"，若回复正常则配置成功 - -## 替代方案 -- [[Obsidian-Agent-Client]] — 支持 Claude Code / Codex / Gemini CLI / OpenCode / Qwen Code 多 Agent 适配 - -## Connections -- [[YishenTu]] — Claudian 开发者 -- [[Claude Code]] — Claudian 适配的 Agent -- [[obsidian-必装-skills]] — 来源文档 -- [[BRAT]] — 安装工具 diff --git a/wiki/concepts/ClientPrediction.md b/wiki/concepts/ClientPrediction.md deleted file mode 100644 index 6d19c473..00000000 --- a/wiki/concepts/ClientPrediction.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Client Prediction" -type: concept -tags: [networking, multiplayer, latency] -sources: [unity-multiplayer-engineer] -last_updated: 2026-04-26 ---- - -## Aliases -- Client-Side Prediction -- 客户端预测 - -## Definition -客户端预测是一种在服务器权威模型下的优化技术，允许客户端**立即执行输入预测移动**，无需等待服务器确认，从而提供流畅的用户体验。当服务器状态与客户端预测不一致时，触发**调和（Reconciliation）**机制进行校正。 - -## How It Works (Unity NGO Pattern) -1. 客户端读取本地输入，立即更新本地渲染位置 -2. 客户端通过 `ServerRpc` 发送输入到服务器 -3. 服务器模拟输入，更新权威状态，广播给所有客户端 -4. 客户端在 `LateUpdate` 中比较预测位置与服务器位置 -5. 当偏差超过阈值时，强制将客户端位置回正到服务器位置 - -## Key Parameters -- `ReconciliationThreshold`: 触发回正的偏差阈值（建议 0.5 单位） -- 输入队列：客户端缓存最近 N 帧的输入，用于服务器重模拟 - -## Related Concepts -- [[ServerAuthority]]: 客户端预测的先决条件 -- [[LagCompensation]]: 与延迟补偿协同工作 -- [[NetworkVariable]]: 用于同步服务器权威状态 - -## Unity Implementation Pattern -```csharp -// Reconciliation logic in LateUpdate -if (Vector3.Distance(transform.position, _serverPosition.Value) > _reconciliationThreshold) -{ - _clientPredictedPosition = _serverPosition.Value; - transform.position = _clientPredictedPosition; -} -``` diff --git a/wiki/concepts/Cloud-Adoption-Strategy.md b/wiki/concepts/Cloud-Adoption-Strategy.md deleted file mode 100644 index ac649896..00000000 --- a/wiki/concepts/Cloud-Adoption-Strategy.md +++ /dev/null @@ -1,144 +0,0 @@ -# Cloud Adoption Strategy - -> **Cloud Adoption Strategy** — 组织将工作负载、应用程序和数据从本地基础设施迁移到云环境，并持续优化云服务使用的系统性方法。 - -## Definition - -云采用策略（Cloud Adoption Strategy）是一份全面的行动计划，定义组织如何： - -- 评估当前状态（遗留系统、云就绪度） -- 设定云采用目标 -- 选择合适的云平台和部署模型 -- 规划迁移路径和优先级 -- 管理变革和人员转型 -- 持续优化云运营 - -## Core Framework - -根据 Open Alliance for Cloud Adoption (OACA) 的云成熟度模型，云采用策略应包含： - -### 1. GAP Analysis（差距分析） - -评估当前状态与目标状态之间的差距： -- 技术差距（基础设施、应用、数据） -- 流程差距（运营、安全、合规） -- 人员差距（技能、文化、能力） - -### 2. Cloud Maturity Assessment - -| 评估维度 | 评估内容 | -|----------|---------| -| **人员 (People)** | 技能水平、培训需求、文化适应性 | -| **流程 (Processes)** | 现有流程成熟度、改进机会 | -| **技术 (Technology)** | 基础设施、应用、数据、集成 | - -### 3. Migration Strategy - -| 策略类型 | 适用场景 | 风险/收益 | -|----------|---------|-----------| -| **Rehost (Lift & Shift)** | 快速迁移、时间紧迫 | 低风险/低收益 | -| **Replatform** | 部分优化需求 | 中风险/中收益 | -| **Repurchase** | SaaS 替代 | 低风险/中收益 | -| **Refactor** | 云原生需求 | 高风险/高收益 | -| **Retire** | 淘汰遗留系统 | 降低复杂性 | -| **Retain** | 暂不迁移 | 战略保留 | - -## Best Practices - -### 1. Set Up Cloud Adoption Objectives - -**Clarify Motivations** -- 关注云经济学和总拥有成本 (TCO) -- 量化成本节省和效率提升 - -**Determine Business Goals** -- 将技术战略与业务目标对齐 -- 确保云采用满足组织需求 - -**Develop a Business Case** -- 创建有说服力的业务案例 -- 争取财务和管理团队支持 - -### 2. Identify Current Maturity Level - -- 使用 Cloud Maturity Model 评估当前状态 -- 设定切合实际的改进目标 -- 平衡完全云原生与混合架构需求 - -### 3. Pick the Right Maturity Model - -| 模型 | 适用场景 | 特点 | -|------|---------|------| -| **OACA CMM** | 通用云采用 | 供应商中立 | -| **AWS CAF** | AWS 环境 | AWS 特定 | -| **Azure CAF** | Azure 环境 | Azure 特定 | -| **GCP CAF** | GCP 环境 | GCP 特定 | -| **CSMM** | 云安全成熟度 | 安全评估 | - -### 4. Follow Governance and Compliance - -- 建立治理框架定义角色和职责 -- 制定安全、访问控制、数据保护政策 -- 符合 HIPAA、PCI-DSS 等行业法规 - -### 5. Security and Risk Management - -- 部署加密和访问控制 -- 定期备份和威胁监控 -- 持续风险评估 -- 安全意识培训 - -## Cloud Deployment Models - -| 模型 | 描述 | 适用场景 | -|------|------|---------| -| **Public Cloud** | 共享基础设施 | 弹性扩展、成本优化 | -| **Private Cloud** | 专用基础设施 | 高安全、合规需求 | -| **Hybrid Cloud** | 公私混合 | 灵活性和控制平衡 | -| **Multi-Cloud** | 多云平台 | 避免锁定、优化性能 | - -## Key Considerations - -### CAPEX vs OPEX - -| 维度 | CAPEX (本地) | OPEX (云) | -|------|-------------|-----------| -| 前期成本 | 高 | 低 | -| 持续成本 | 维护、折旧 | 按需付费 | -| 灵活性 | 低 | 高 | -| 可扩展性 | 有限 | 弹性 | -| 可见性 | 固定 | 按使用付费 | - -### TCO (Total Cost of Ownership) - -评估云采用总成本时考虑： -- 直接成本（计算、存储、网络） -- 间接成本（培训、迁移、集成） -- 隐性成本（治理、安全、合规） -- 机会成本（创新速度） - -## Phases of Cloud Adoption - -``` -Phase 1: Discovery & Assessment - ↓ -Phase 2: Strategy & Planning - ↓ -Phase 3: Foundation & Readiness - ↓ -Phase 4: Migration - ↓ -Phase 5: Optimization - ↓ -Phase 6: Innovation & Transformation -``` - -## See Also - -- [[Cloud Maturity Model]] — 成熟度框架 -- [[Cloud Maturity Levels]] — 成熟度级别 -- [[Cloud Migration]] — 云迁移 -- [[Cloud Governance]] — 云治理 -- [[Multi-Cloud Strategy]] — 多云策略 -- [[FinOps]] — 云财务管理 -- [[Cloud-Native]] — 云原生 diff --git a/wiki/concepts/Cloud-Computing.md b/wiki/concepts/Cloud-Computing.md deleted file mode 100644 index 129302d7..00000000 --- a/wiki/concepts/Cloud-Computing.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Cloud Computing" -type: concept -tags: [cloud, infrastructure, iaas, paas, saas] -sources: [the-myths-and-misconceptions-about-cloud-computing-linkedin, what-i-know-about-cloud-service-delivery-1, cloud-maturity-model-a-detailed-guide-for-cloud-adoption] -last_updated: 2025-03-02 ---- - -## Definition - -Cloud computing is the delivery of computing services—including servers, storage, databases, networking, software, analytics, and intelligence—over the Internet ("the cloud") to offer faster innovation, flexible resources, and economies of scale. - -## Service Models - -- **IaaS (Infrastructure as a Service)**: Provides virtualized computing resources over the internet (e.g., AWS EC2, Azure VMs) -- **PaaS (Platform as a Service)**: Provides a platform for developing, running, and managing applications without dealing with infrastructure (e.g., AWS Elastic Beanstalk, Azure App Service) -- **SaaS (Software as a Service)**: Provides software applications over the internet on a subscription basis (e.g., Microsoft 365, Salesforce) - -## Key Characteristics - -- **On-demand self-service**: Provision resources as needed without human intervention -- **Broad network access**: Access services over the network via standard mechanisms -- **Resource pooling**: Multiple customers share infrastructure with logical separation -- **Rapid elasticity**: Scale resources up or down dynamically -- **Measured service**: Pay-as-you-go pricing model - -## Common Misconceptions - -According to [[the-myths-and-misconceptions-about-cloud-computing-linkedin]], the following misconceptions are prevalent: - -1. **Cloud is not secure** → Reality: Major providers invest heavily in security (encryption, MFA, ISO 27001, HIPAA, GDPR compliance) -2. **Cloud is just "someone else's computer"** → Reality: Cloud is a sophisticated network of data centers with redundancy and high availability -3. **Cloud is too expensive** → Reality: Pay-as-you-go model with proper management can be cost-effective -4. **You lose control of your data** → Reality: Cloud provides robust data governance and control tools -5. **Cloud is only for large enterprises** → Reality: SMBs can leverage enterprise-grade technology without large upfront investments -6. **Migration is too complex** → Reality: Phased migration and hybrid cloud solutions mitigate risks -7. **Cloud performance is unreliable** → Reality: SLAs often guarantee 99.99%+ uptime - -## Related Concepts - -- [[Hybrid-Cloud]]: Combining on-premises infrastructure with public cloud -- [[Multi-Cloud]]: Using multiple cloud providers simultaneously -- [[Cloud-Migration]]: The process of moving workloads to the cloud -- [[Cloud-Security]]: Security practices in cloud environments -- [[Pay-as-you-go]]: Cost model based on actual usage -- [[High-Availability]]: Design principle for minimizing downtime -- [[Serverless-Computing]]: Event-driven computing without server management - -## Aliases - -- Cloud -- 云计算 diff --git a/wiki/concepts/Cloud-Cost-Optimization.md b/wiki/concepts/Cloud-Cost-Optimization.md deleted file mode 100644 index ed810428..00000000 --- a/wiki/concepts/Cloud-Cost-Optimization.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: "Cloud Cost Optimization" -type: concept -tags: [Cloud, FinOps, Cost Management, Cloud Operations] -sources: [cloud-operating-model-key-strategies-and-best-practices] -date: 2026-04-26 ---- - -# Cloud Cost Optimization (云成本优化) - -## Definition -**Cloud Cost Optimization** is the practice of reducing unnecessary cloud spending while maintaining performance, security, and reliability. It involves monitoring, analyzing, and adjusting cloud resource usage to achieve maximum value. - -## Key Tactics - -### 1. Reserved Instances & Spot Instances -- **Reserved Instances**: 40-70% cost reduction compared to on-demand -- **Spot Instances**: Up to 90% discount for interruptible workloads -- Strategic commitment for predictable workloads - -### 2. Auto-Scaling & Right-Sizing -- Automatically adjust resources based on demand -- Match instance types to actual workload needs -- Terminate underutilized resources - -### 3. Resource Tagging & Monitoring -- Track spending by teams, projects, and workloads -- Real-time cost visibility -- Budget alerts and anomaly detection - -### 4. Storage Optimization -- Delete unused snapshots and volumes -- Use lifecycle policies -- Choose appropriate storage classes - -### 5. Network Cost Optimization -- Minimize data transfer costs -- Use VPC endpoints -- Optimize traffic routes - -## Cloud Provider Cost Management Tools - -| Provider | Tool | Key Features | -|----------|------|-------------| -| AWS | AWS Cost Explorer | Real-time cost monitoring, savings plans, budget alerts | -| Azure | Azure Cost Management | Cost tracking, reserved instances, predictive analysis | -| GCP | GCP Billing Reports | AI-driven cost insights, budget tracking | - -## FinOps Integration -- Cloud Cost Optimization is a core component of [[FinOps]] -- Continuous optimization cycle: Inform → Optimize → Operate -- Collaboration between finance, engineering, and operations - -## Case Studies - -### E-commerce Company -- Leveraged Auto-Scaling and Reserved Instances across AWS and Azure -- **Result**: $500,000 annual billing savings - -### SaaS Company -- Used Reserved Instances and Autoscaling Policies -- **Result**: 35% reduction in cloud costs - -## Related Concepts -- [[FinOps]] -- [[Cloud Operating Model]] -- [[Cloud Governance]] -- [[Rightsizing]] -- [[Pay-as-you-go]] - -## Related Entities -- [[AWS]] -- [[Azure]] -- [[Google-Cloud]] diff --git a/wiki/concepts/Cloud-DevOps-Maturity-Model.md b/wiki/concepts/Cloud-DevOps-Maturity-Model.md deleted file mode 100644 index 3e206d5d..00000000 --- a/wiki/concepts/Cloud-DevOps-Maturity-Model.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Cloud DevOps Maturity Model -tags: - - cloud - - devops - - maturity -created: 2026-04-22 ---- - -# Cloud DevOps Maturity Model - -## Overview - -The Cloud DevOps Maturity Model is a framework for evaluating and advancing an organization's cloud DevOps capabilities. It assesses how well teams have adopted DevOps practices in cloud environments across multiple dimensions. - -## Related Concepts - -- [[Cloud Service Delivery]] — The broader context of cloud operations -- [[DevOps Maturity]] — General DevOps maturity assessment -- [[DORA Metrics]] — DevOps Research and Assessment metrics -- [[Cloud Maturity Levels]] — General cloud maturity assessment - -## Related Sources - -- [[what-i-know-about-cloud-service-delivery-1]] -- [[cloud-devop-maturity-guideline]] - -## Key Dimensions - -While the source document mentions this as a concept to be explored, typical Cloud DevOps Maturity dimensions include: - -1. **Automation** — Infrastructure provisioning, deployment, testing automation -2. **Collaboration** — Cross-functional team alignment -3. **Monitoring & Observability** — Cloud-native monitoring solutions -4. **Security Integration (DevSecOps)** — Security embedded in the pipeline -5. **Incident Response** — Automated response and recovery -6. **Continuous Improvement** — Feedback loops and optimization - -## Maturity Indicators - -| Level | Characteristics | -|-------|-----------------| -| Level 1 | Ad-hoc cloud usage, manual processes | -| Level 2 | Basic automation, some monitoring | -| Level 3 | IaC adoption, CI/CD pipelines | -| Level 4 | Advanced automation, proactive monitoring | -| Level 5 | Self-healing systems, AI-driven optimization | diff --git a/wiki/concepts/Cloud-First-Policy.md b/wiki/concepts/Cloud-First-Policy.md deleted file mode 100644 index 5b49abcb..00000000 --- a/wiki/concepts/Cloud-First-Policy.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "Cloud-First Policy" -type: concept -tags: [Cloud, Strategy, Policy, Governance] -sources: ["ctp-topic-53-why-bother-with-cloud"] -last_updated: 2026-05-10 ---- - -## Definition - -Cloud-First Policy（云优先策略）是一种组织级技术政策，要求在同等条件下优先选择云解决方案而非本地部署。云优先不是简单的"必须上云"，而是将云视为新工作负载的首选部署目标，同时承认某些场景下本地部署仍有合理性。 - -## Core Principles - -1. **新工作负载默认上云**：所有新应用和服务优先考虑云部署 -2. **迁移优先于新建**：新功能优先通过迁移现有工作负载实现，而非新建本地基础设施 -3. **云原生服务优先**：优先使用云平台提供的托管服务（如 RDS、Lambda），而非自建 -4. **持续评估**：定期评估现有工作负载，确定哪些应迁移到云 - -## Benefits (from CTP Context) - -[[ctp-topic-53-why-bother-with-cloud]] 中阐述的云优先核心价值： - -- **创新赋能**：为产品团队提供安全、有韧性的平台，更快速地交付新功能 -- **成本优化**：按需付费模型 + 预留实例，消除本地基础设施的固定成本 -- **弹性扩展**：云平台天然支持业务高峰期的弹性伸缩 -- **灾备改善**：多可用区、多区域架构提供比本地更高的可用性 -- **市场拓展**：快速在新地区部署，开拓新收入机会 - -## Cloud-First vs Cloud-Only - -| 维度 | Cloud-First | Cloud-Only | -|------|------------|------------| -| 本地部署 | 仅在有充分理由时保留 | 不允许 | -| 遗留系统 | 制定迁移路线图 | 强制迁移 | -| 混合云 | 接受作为过渡态 | 视为技术债 | -| 合规要求 | 满足即可，云或本地均可 | 仅云满足 | - -## Challenges - -- **数据主权**：某些数据因合规原因不能上云 -- **延迟敏感**：高频交易等场景对延迟要求极高 -- **成本固定**：对于稳定的高负载，本地可能更经济 -- **技术债**：迁移遗留应用成本高、风险大 - -## Related Concepts - -- [[Landing-Zone-Architecture]]：云优先策略在 AWS 的落地架构 -- [[Urban-Sprawl]]：云优先是对抗数据中心蔓延的战略 - -## Related Sources - -- [[ctp-topic-53-why-bother-with-cloud]] — 云优先作为 CTP 核心战略 diff --git a/wiki/concepts/Cloud-Governance.md b/wiki/concepts/Cloud-Governance.md deleted file mode 100644 index a15a8648..00000000 --- a/wiki/concepts/Cloud-Governance.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: "Cloud Governance" -type: concept -tags: [Cloud, Governance, Compliance, Security, Cloud Operations] -sources: [cloud-operating-model-key-strategies-and-best-practices] -date: 2026-04-26 ---- - -# Cloud Governance (云治理) - -## Definition -**Cloud Governance** is the set of policies, processes, and controls that ensure cloud resources are used securely, efficiently, and in compliance with regulatory requirements. It provides the framework for managing cloud chaos, security loopholes, and cost overruns. - -## Key Components - -### 1. Identity & Access Management (IAM) -- Role-based access control (RBAC) -- Principle of least privilege -- Multi-factor authentication - -### 2. Security & Compliance -- Policy-as-Code for automated enforcement -- Continuous compliance monitoring -- Automated compliance checks - -### 3. Cost Management & Governance -- Real-time cost tracking -- Budget alerts and allocation -- Resource tagging strategies - -### 4. Resource Governance -- Guardrails for resource provisioning -- Tagging standards -- Resource lifecycle management - -## Cloud Governance by Provider - -| Aspect | AWS | Azure | GCP | -|--------|-----|-------|-----| -| IAM | AWS IAM | Azure AD | Google IAM | -| Security Tools | AWS Security Hub | Microsoft Defender | Security Command Center | -| Cost Control | AWS Cost Explorer | Azure Cost Management | GCP Billing Reports | -| Policy Enforcement | AWS Organizations & SCPs | Azure Policy | GCP Organization Policies | - -## Best Practices - -1. **Define IAM roles and policies upfront** — avoid giving excessive permissions -2. **Use automated compliance checks** — detect misconfigurations -3. **Implement guardrails** — prevent unauthorized resource provisioning -4. **Establish tagging standards** — track resources by teams, projects, workloads -5. **Enable real-time monitoring** — detect anomalies and compliance violations - -## Relationship to Cloud Operating Model -- Cloud Governance is a **core pillar** of the Cloud Operating Model -- Provides the guardrails that enable secure and efficient cloud operations -- Works alongside Automation, Security, and FinOps - -## Related Concepts -- [[Cloud Operating Model]] -- [[Policy-as-Code]] -- [[Compliance-Automation]] -- [[FinOps]] -- [[Zero-Trust-Architecture]] -- [[IAM]] - -## Related Entities -- [[AWS]] -- [[Azure]] -- [[Google-Cloud]] diff --git a/wiki/concepts/Cloud-Maturity-Levels.md b/wiki/concepts/Cloud-Maturity-Levels.md deleted file mode 100644 index f9365d71..00000000 --- a/wiki/concepts/Cloud-Maturity-Levels.md +++ /dev/null @@ -1,181 +0,0 @@ -# Cloud Maturity Levels - -> **Cloud Maturity Levels** — 云成熟度5级模型的详细定义，每级对应组织在云采用旅程中的特定能力水平。 - -## Overview - -Cloud Maturity Model 将组织的云成熟度分为 5 个级别（Level 0-5），每个级别代表不同的技术能力、流程成熟度和战略整合程度。 - -## The 5 Maturity Levels - -### Level 0: No Cloud Readiness (Legacy) - -**定义**: 组织完全不使用云服务，仅依赖遗留系统。 - -**特征**: -- 无虚拟化 -- 所有工作负载在本地 -- 新项目启动缓慢困难 -- 通常受严格监管约束（高安全或数据要求） - -**典型场景**: -- 高度监管行业（某些金融、医疗） -- 数据主权要求极高的场景 -- 历史遗留系统迁移困难的组织 - ---- - -### Level 1: Initial Readiness (Ad hoc) - -**定义**: 组织开始评估云服务，零星采用但无整体战略。 - -**特征**: -- 已评估软件和服务的云集成可能性 -- 部分工作负载尝试迁移 -- 仍主要运行在遗留和非虚拟化系统 -- 主要使用 SaaS 或特定业务单元需求 -- 缺乏清晰的整体云战略 - -**常见挑战**: - -| 挑战 | 解决方案 | -|------|---------| -| 云技术知识有限 | 获得高管对云计划的支持 | -| 领导层支持不足 | 使用非关键应用进行多个 PoC | -| 缺乏资金 | 获取云服务的综合访问资金 | -| 无清晰战略 | 为当前团队制定云技术有效使用战略 | -| 无定义流程/指南 | 通过教育培训增强云知识 | -| 无云使用优化 | 建立明确的 KPI（如降低 25% 基础设施成本） | -| 缺乏云安全意识 | 通过培训加深云安全风险理解 | - -**进阶路径**: 高管支持 → PoC 验证 → 资金保障 → 战略制定 → KPI 建立 - ---- - -### Level 2: Repeatable, Opportunistic - -**定义**: 组织建立了使用云服务的 IT 和采购流程，广泛使用云但方法不够系统。 - -**特征**: -- 已建立云订阅和访问流程 -- 流程已定义且可重复 -- 云服务使用广泛 -- 尚无完全系统化的方法 - -**常见挑战**: - -| 挑战 | 解决方案 | -|------|---------| -| 成本控制与管理问题 | 将云使用与业务目标对齐（市场扩张、新品发布） | -| 缺乏文档化政策 | 建立云卓越中心（CCoE） | -| 过度依赖手动任务 | 形成专门的云治理团队 | -| 云使用可见性有限 | 优先优化云采用总成本（TCO） | -| 云采用 ROI 和时间线担忧 | 采用标准化、可重复性和自动化 | -| 不愿从旧系统迁移 | 使用容器而非虚拟机部署应用 | -| 安全与合规顾虑 | 考虑多样化部署模型（私有、混合、多云） | -| 云团队/流程/迁移管理复杂性 | 制定详细的云运营指南和协议 | -| 加密和身份认证问题 | 将关键生产工作负载迁移到云 | -| 最小化云系统停机时间 | 确保所有云服务最小停机 | - -**进阶路径**: CCoE → 治理团队 → 标准化 → 自动化 → 容器化 - ---- - -### Level 3: Systematic and Documented - -**定义**: 组织实施流程或外包服务来管理云订阅和监控现有服务，运营更加高效和系统化。 - -**特征**: -- 已文档化的云管理流程 -- 运营策略已更新 -- 流程和实践系统化 -- 可能外包云管理服务 - -**常见挑战**: - -| 挑战 | 解决方案 | -|------|---------| -| 确保云流程一致性 | 获得对完全 IT 分权的支持 | -| 员工培训提升能力 | 制定全面的应用迁移到目标环境战略 | -| 云环境有效管理 | 增强发布、密钥和策略管理 | -| 分析工作负载优化机会 | 建立稳健的治理和管理实践 | -| 识别适合自动化的任务 | 将所有相关工作负载和数据迁移到云 | -| 环境管理担忧 | 尝试高级云服务（AI、机器学习等） | -| 应用和系统迁移 | 拥抱完全自动化和编排 | - -**⚠️ 警惕**: 许多企业试图跳过 Level 2 和 3，直接从 Level 0/1 到 Level 4。虽然技术驱动的云转型框架使这看起来很诱人，但确保长期可持续性至关重要。 - -**进阶路径**: IT 分权支持 → 迁移战略 → 治理强化 → 自动化 → 高级云服务 - ---- - -### Level 4: Measured - -**定义**: 组织广泛使用云原生应用，采用私有、公共和混合云平台。 - -**特征**: -- 云原生应用在日常运营中广泛使用 -- 跨多云平台（私有/公共/混合） -- 透明治理模型管理云运营 -- 端到端流程性能可衡量 -- 数据使用和优化持续改进 - -**常见挑战**: -- 快速部署云服务时需要治理模型 -- 数据利用需要特定技能和工具优化 -- 部分组织可能仅部分达到 Level 4（某些能力仍在 Level 2/3） - -**关键成功因素**: -- 透明治理模型 -- 端到端性能测量 -- 数据驱动决策 -- 持续优化文化 - ---- - -### Level 5: Optimized - -**定义**: 最高成熟度级别，组织在开放互通的云环境中运营，基于指标和数据积极开发。 - -**特征**: -- 流程优化，数据驱动决策 -- 熟练使用各种云平台 -- 灵活跨平台迁移工作负载 -- 持续创新和优化 - -**⚠️ 现实检视**: -- Level 5 往往比现实更理想化 -- 许多公司可能开发开放互通的云环境 -- 在流程优化和充分利用数据方面通常落后 -- 如果广泛的混合云解决方案是可选的，Level 5 可能是过度投资 - -**最佳建议**: 不要追求完整的 Level 5，而是选择性采纳能带来明确业务价值的要素。 - -## Level Progression Insights - -``` -Level 0 ──→ Level 1 ──→ Level 2 ──→ Level 3 ──→ Level 4 ──→ Level 5 -(无云) (评估) (可重复) (系统化) (可衡量) (优化) - ↑ ↑ ↑ - └──────────────┴──── ⚠️ 跳过级别可能导致 - 后续挑战和不必要的成本 -``` - -## Key Metrics by Level - -| 维度 | Level 1 | Level 2 | Level 3 | Level 4 | Level 5 | -|------|---------|---------|---------|---------|---------| -| 成本优化 | 初始评估 | TCO 分析 | 持续优化 | 自动化调优 | 预测性优化 | -| 自动化 | 手动 | 部分自动化 | 流程自动化 | 编排 | 自主运营 | -| 治理 | 无 | 基础政策 | 文档化治理 | 透明治理 | 动态治理 | -| 安全性 | 基础 | 合规检查 | 主动安全 | 持续监控 | 主动防御 | -| 数据利用 | 有限 | 收集 | 分析 | 洞察 | 预测/AI | - -## See Also - -- [[Cloud Maturity Model]] — 主体框架 -- [[Cloud Adoption Strategy]] — 云采用策略 -- [[DevOps Maturity]] — DevOps 成熟度 -- [[DORA Metrics]] — DORA 指标 -- [[Cloud Governance]] — 云治理 -- [[FinOps]] — 云财务管理 diff --git a/wiki/concepts/Cloud-Monitoring.md b/wiki/concepts/Cloud-Monitoring.md deleted file mode 100644 index 22d7fae8..00000000 --- a/wiki/concepts/Cloud-Monitoring.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Cloud Monitoring -type: concept -tags: [AWS, CloudOps, Observability, CTP, Monitoring] -date: 2026-04-14 ---- - -## Definition -Cloud Monitoring（云监控）是指在公有云环境（AWS/Azure/GCP）中，对基础设施、服务器、应用程序、硬件和网络等数据源进行持续监控和事件采集的系统性实践。云监控的核心挑战在于云环境的动态性——资源生命周期短、数量庞大、跨多账户多区域分布，传统基于静态服务器的监控工具难以有效覆盖。 - -## Core Properties -- **动态发现**：云环境中资源随时创建/销毁，监控必须支持自动发现而非静态配置 -- **多账户覆盖**：AWS Organizations 多账户架构下，需要集中化监控能力 -- **无代理采集**：云环境下倾向于通过 API（如 CloudWatch）而非在被监控目标上安装 Agent -- **跨平台支持**：现代监控解决方案需支持 AWS/Azure/GCP 等多云环境 -- **策略驱动**：通过 Policy/Management Pack 定义监控规则，实现规模化管理 - -## Key Mechanisms -- **CloudWatch API**：AWS 的指标和日志服务，是 AWS 云监控的统一数据源 -- **IAM Role 跨账户访问**：通过角色信任关系实现监控账户安全读取被监控账户数据，无需共享 Access Key -- **Management Pack**：监控平台（如 OBM）的策略包，定义采集间隔、指标、阈值和数据源 -- **Global/Regional 分层架构**：区域级 OBM 采集数据 → 全球级 OBM 汇聚 → 工单系统触发事件处理 - -## Comparison with Traditional Monitoring -| 维度 | 传统监控 | 云监控 | -|------|---------|--------| -| 目标发现 | 手动添加 | 自动发现 | -| 部署模式 | 被监控目标安装 Agent | API 拉取（无代理） | -| 账户覆盖 | 单点监控 | 多账户集中采集 | -| 伸缩性 | 固定容量 | 按需弹性 | -| 密钥管理 | 共享 Access Key | IAM Role 信任关系 | - -## Related Concepts -- [[Multi-Account-Deployment]]：云监控的多账户架构基础 -- [[Landing-Zone-Architecture]]：监控账户是 Landing Zone 的一部分 -- [[IAM-Role]]：跨账户安全访问的核心机制 -- [[Management-Pack]]：云监控策略化管理的具体实现 -- [[Cloud-Native]]：云原生监控的自然延伸 - -## References -- [[ctp-topic-8-obm-cloud-monitoring]]：OBM AWS 云监控完整实现方案 -- [[ctp-topic-29-cloud-monitoring-saas-lz-accounts]]：SaaS Landing Zone 监控账户架构 diff --git a/wiki/concepts/Cloud-Native-Maturity-Model.md b/wiki/concepts/Cloud-Native-Maturity-Model.md deleted file mode 100644 index 243b9445..00000000 --- a/wiki/concepts/Cloud-Native-Maturity-Model.md +++ /dev/null @@ -1,134 +0,0 @@ -# Cloud Native Maturity Model - -> **Cloud Native Maturity Model** — 评估组织在采用云原生技术和服务方面成熟度的框架，基于 CNCF 云原生景观。 - -## Definition - -云原生成熟度模型评估组织在以下方面的成熟度： - -- **容器化和打包** -- **编排和自动化** -- **微服务和 API** -- **可观测性** -- **服务网格** -- **DevOps 实践** - -## CNCF云原生成熟度层级 - -### Level 1: Containerized（容器化） - -**特征** -- 应用程序已容器化（Docker） -- 使用容器镜像仓库 -- 基本的 CI/CD 流水线 - -**成熟度指标** -- [ ] 80%+ 应用已容器化 -- [ ] 标准化基础镜像 -- [ ] 镜像安全扫描集成 - ---- - -### Level 2: Orchestrated（编排） - -**特征** -- Kubernetes 集群管理 -- 自动化部署和扩缩容 -- 基础资源调度 - -**成熟度指标** -- [ ] 生产环境使用 K8s -- [ ] HPA（水平 Pod 自动扩缩容） -- [ ] 命名空间隔离 -- [ ] 基础调度策略 - ---- - -### Level 3: Microservices（微服务） - -**特征** -- 应用程序拆分为微服务 -- 服务间通过 API 通信 -- 异步消息队列使用 -- 服务发现 - -**成熟度指标** -- [ ] 微服务数量 > 10 -- [ ] 12-Factor App 遵循 -- [ ] API 网关使用 -- [ ] 消息队列集成 - ---- - -### Level 4: Meshed（服务网格） - -**特征** -- 服务网格部署（Istio/Linkerd） -- 零信任网络安全 -- 细粒度流量管理 -- 分布式追踪 - -**成熟度指标** -- [ ] 服务网格生产使用 -- [ ] mTLS 强制执行 -- [ ] 金丝雀发布/AB 测试 -- [ ] 分布式追踪完整覆盖 - ---- - -### Level 5: Auto-Pilot（自动驾驶） - -**特征** -- 策略即代码 -- 自动化安全策略执行 -- 自愈能力 -- 智能扩缩容 - -**成熟度指标** -- [ ] OPA/Kyverno 策略强制 -- [ ] 自动故障恢复 -- [ ] 预测性扩缩容 -- [ ] FinOps 自动化 - -## CNCF云原生技术全景 - -### Container Runtime -- containerd, CRI-O - -### Orchestration & Management -- Kubernetes, Helm, Kustomize - -### Coordination & Service Discovery -- etcd, CoreDNS - -### Networking & Service Mesh -- CNI (Calico, Flannel) -- Envoy, Istio, Linkerd - -### Observability -- Prometheus, Grafana, Jaeger, Loki, OpenTelemetry - -### Serverless / Faas -- Knative, OpenFaaS, AWS Lambda, Azure Functions - -### Application Definition -- Helm, Kustomize, OAM, Dapr - -## Assessment Criteria - -| 能力 | L1 | L2 | L3 | L4 | L5 | -|------|----|----|----|----|----| -| **容器化** | Ad-hoc | 标准镜像 | 统一流水线 | 自动化扫描 | 签名验证 | -| **编排** | 手动 | K8s 基础 | 自动部署 | 策略驱动 | 自愈 | -| **架构** | 单体 | 模块化 | 微服务 | 服务网格 | 混合 | -| **网络** | 基础 | VPC | API 网关 | 服务网格 | 零信任 | -| **可观测** | 基础日志 | 指标 | 追踪 | 完整 | 预测 | -| **安全** | 手动 | IAM | 扫描 | 策略即代码 | 自适应 | - -## See Also - -- [[Cloud-Native]] — 云原生核心概念 -- [[Cloud Maturity Model]] — 云成熟度模型 -- [[DevOps Maturity]] — DevOps 成熟度 -- [[Kubernetes]] — Kubernetes -- [[Service Mesh]] — 服务网格 diff --git a/wiki/concepts/Cloud-Native.md b/wiki/concepts/Cloud-Native.md deleted file mode 100644 index 00d9338a..00000000 --- a/wiki/concepts/Cloud-Native.md +++ /dev/null @@ -1,156 +0,0 @@ -# Cloud-Native - -> **Cloud-Native** — 一种构建和运行应用程序的方法，充分利用云计算交付模型，将计算、存储和网络作为可弹性扩展的服务。 - -## Definition - -云原生（Cloud-Native）是一套技术方法论和最佳实践，用于： - -- 构建可在云环境中弹性运行的应用程序 -- 利用云平台的托管服务和自动化能力 -- 采用 DevOps 和 CI/CD 实践 -- 使用容器、无服务器和微服务架构 - -## Cloud-Native Computing Foundation (CNCF) - -CNCF 定义了云原生的核心技术要素： - -``` -Cloud-Native Stack: -├── Container Runtime (containerd, CRI-O) -├── Orchestration (Kubernetes) -├── Service Mesh (Istio, Linkerd) -├── Observability (Prometheus, Grafana) -├── Networking (CNI, Envoy) -└── Storage (CSI) -``` - -## 12-Factor App Methodology - -云原生应用遵循 12-Factor 原则： - -| # | 因素 | 描述 | -|---|------|------| -| 1 | Codebase | 单一代码库，版本控制 | -| 2 | Dependencies | 明确声明依赖 | -| 3 | Config | 配置与环境分离 | -| 4 | Backing Services | 将服务视为资源 | -| 5 | Build, Release, Run | 严格分离构建和运行 | -| 6 | Processes | 无状态进程 | -| 7 | Port Binding | 通过端口绑定导出服务 | -| 8 | Concurrency | 通过进程模型扩展 | -| 9 | Disposability | 快速启动和优雅关闭 | -| 10 | Dev/Prod Parity | 开发、预发、生产环境一致 | -| 11 | Logs | 将日志视为事件流 | -| 12 | Admin Processes | 将管理任务作为一次性进程 | - -## Core Technologies - -### Containers - -**优势** -- 轻量级虚拟化 -- 环境一致性 -- 快速启动 -- 资源隔离 - -**关键工具** -- Docker, containerd, Podman -- OCI 镜像规范 - -### Kubernetes - -**核心概念** -- Pod（最小调度单元） -- Deployment（声明式更新） -- Service（网络抽象） -- Ingress（HTTP 路由） -- ConfigMap/Secret（配置管理） - -**生态组件** -- Helm (包管理) -- Kustomize (配置管理) -- Operators (自愈自动化) - -### Service Mesh - -**功能** -- 零信任网络安全 -- 可观测性（追踪、指标、日志） -- 流量管理（A/B 测试、金丝雀发布） -- 熔断和限流 - -**工具** -- Istio, Linkerd, Consul Connect - -### Serverless - -**优势** -- 零服务器管理 -- 弹性扩展 -- 按使用付费 -- 快速原型 - -**服务** -- AWS Lambda, Azure Functions, GCP Cloud Functions -- Knative, OpenFaaS - -### Observability - -**三大支柱** -- **指标 (Metrics)** — Prometheus, Datadog -- **日志 (Logs)** — ELK Stack, Loki -- **追踪 (Traces)** — Jaeger, Zipkin - -## Cloud-Native Maturity Model - -| Level | 特征 | -|-------|------| -| **L1: Containerized** | 应用程序容器化 | -| **L2: Orchestrated** | 容器编排（K8s） | -| **L3: Microservices** | 微服务架构 | -| **L4: Meshed** | 服务网格 | -| **L5: Auto-Pilot** | 自主运维、自愈 | - -## Cloud-Native vs Traditional - -| 维度 | Cloud-Native | Traditional | -|------|-------------|-------------| -| **架构** | 微服务 | 单体 | -| **部署** | 容器 | 物理机/VM | -| **扩展** | 自动、弹性 | 手动、垂直 | -| **交付** | CI/CD | 传统发布 | -| **可用性** | 多副本 | 主备 | -| **成本** | 按需 | 固定 | -| **恢复** | 自动故障转移 | 手动恢复 | - -## Best Practices - -### Design for Failure - -- 幂等性设计 -- 超时和重试 -- 熔断器模式 -- 限流保护 - -### Observability - -- 结构化日志 -- 分布式追踪 -- 指标和告警 -- 健康检查 - -### Security - -- 零信任架构 -- 最小权限 -- 密钥管理 -- 镜像安全扫描 - -## See Also - -- [[Cloud Maturity Model]] — 云成熟度模型 -- [[DevOps Maturity]] — DevOps 成熟度 -- [[Kubernetes]] — K8s -- [[Microservices]] — 微服务 -- [[Service Mesh]] — 服务网格 diff --git a/wiki/concepts/Cloud-Operating-Model.md b/wiki/concepts/Cloud-Operating-Model.md deleted file mode 100644 index 0700d081..00000000 --- a/wiki/concepts/Cloud-Operating-Model.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -title: "Cloud Operating Model" -type: concept -tags: [Cloud, Cloud Strategy, Cloud Governance, Cloud Operations] -sources: [cloud-operating-model-key-strategies-and-best-practices] -date: 2026-04-26 ---- - -# Cloud Operating Model (云运营模型) - -## Definition -A **Cloud Operating Model (COM)** is a framework that standardizes how organizations manage cloud resources, security, automation, and costs across cloud environments. It provides guardrails for constructing a secure framework for cloud operations and management from cost and risk standpoint. - -## Core Pillars - -### 1. Governance & Compliance (治理与合规) -- Standardized policies ensuring compliance across cloud environments -- Security, access control, and compliance policies -- Teams follow best practices while maintaining agility - -### 2. Automation & Orchestration (自动化与编排) -- Infrastructure as Code (IaC) for deployment automation -- CI/CD pipelines for continuous software delivery -- Event-driven automation (e.g., AWS Lambda, Azure Functions) - -### 3. Security & Risk Management (安全与风险管理) -- Zero Trust Security Model (no implicit trust, continuous verification) -- Real-time threat detection -- Automated security patching - -### 4. Cloud Financial Management - FinOps (云财务管理) -- Real-time cost tracking and allocation -- Reserved Instances & Spot Instances for cost optimization -- Budget alerts and predictive analysis - -## Six-Step Design Process - -1. **Assess Cloud Maturity & Business Objectives** - - Ad-hoc Cloud Adoption → Cloud-First Strategy → Cloud-Native Enterprise - -2. **Create Governance & Compliance Framework** - - Define IAM roles and policies - - Automated compliance checks - - Guardrails for resource provisioning - -3. **Automate Cloud Operations (IaC, DevOps)** - - Terraform, CloudFormation, Azure Bicep - - CI/CD with GitHub Actions, CodePipeline - - Serverless automation - -4. **Implement Cost Management & Optimization (FinOps)** - - Reserved/Spot Instances (40-70% compute cost reduction) - - Auto-scaling & Right-sizing - - Resource tagging and monitoring - -5. **Strengthen Security & Risk Mitigation** - - Zero Trust Security Model - - Real-time threat detection (GuardDuty, Sentinel) - - Automated security patching - -6. **Continuous Monitoring & AI-Driven Optimization** - - Observability & AIOps - - Real-time cloud monitoring (CloudWatch, Azure Monitor) - - Self-healing systems - -## Key Benefits - -| Benefit | Description | -|---------|-------------| -| Standardized Governance | Ensures compliance across cloud environments | -| Cost Optimization | Implements FinOps strategies to prevent overspending | -| Improved Security | Automates security policies and access controls | -| Operational Agility | Enables DevOps, CI/CD, and auto-scaling | -| Multi-Cloud Flexibility | Reduces vendor lock-in and enhances resilience | - -## Industry Use Cases - -### Financial Services -- Regulatory compliance automation (GDPR, PCI-DSS, SOC 2) -- FinOps for cost tracking and optimization -- Zero Trust security model for data protection - -### Healthcare -- HIPAA, HITRUST, GDPR compliance enforcement -- Data encryption and multi-layer access control -- AI/ML for diagnostics - -### Retail & E-Commerce -- Auto-scaling for peak demand -- Multi-cloud strategy to avoid vendor lock-in -- Personalized customer experiences via AI - -### SaaS & Tech Companies -- CI/CD pipelines for continuous updates -- Serverless and containerized architectures -- DevSecOps for security-first development - -## Challenges & Solutions - -| Challenge | Solution | -|-----------|----------| -| Vendor Lock-In | Multi-cloud strategy + Docker/Kubernetes + Terraform | -| Cost Overruns | FinOps + Reserved/Spot instances + automated shutdown | -| Compliance Risks | Policy-as-Code + AWS Config/Azure Policy + RBAC | -| Skills Gap | Automation tools + workforce upskilling | - -## Related Concepts -- [[Cloud Governance]] -- [[FinOps]] -- [[Zero-Trust-Security]] -- [[Multi-Cloud Strategy]] -- [[Infrastructure as Code]] -- [[AIOps]] -- [[Cloud Cost Optimization]] -- [[DevOps Maturity]] -- [[Policy-as-Code]] - -## Related Entities -- [[AWS]] -- [[Azure]] -- [[Google-Cloud]] -- [[Terraform]] -- [[Kubernetes]] - -## References -- [Bacancy Technology: Cloud Operating Model](https://www.bacancytechnology.com/blog/cloud-operating-model) diff --git a/wiki/concepts/Cloud-Security-Maturity-Model.md b/wiki/concepts/Cloud-Security-Maturity-Model.md deleted file mode 100644 index a7eed3ba..00000000 --- a/wiki/concepts/Cloud-Security-Maturity-Model.md +++ /dev/null @@ -1,148 +0,0 @@ -# Cloud Security Maturity Model (CSMM) - -> **Cloud Security Maturity Model (CSMM)** — 评估组织云安全计划成熟度的框架，覆盖12个安全领域的3个域。 - -## Definition - -CSMM 是一个供应商中立的安全成熟度评估框架，帮助组织： - -- 评估当前云安全状态 -- 识别安全差距 -- 制定安全改进路线图 -- 量化安全投资回报 - -## CSMM Structure - -### 3 Domains - -| 域 | 描述 | -|----|------| -| **Governance & Strategy** | 安全治理、战略和风险管理 | -| **Technical Controls** | 实施的安全技术和控制 | -| **Operational Processes** | 安全运营流程和实践 | - -### 12 Security Domains - -| 域 | 类别 | -|----|------| -| **Asset Management** | 资产发现、分类、清单 | -| **Compliance Management** | 法规遵从、审计 | -| **Data Security** | 数据分类、加密、生命周期 | -| **Governance & Risk** | 安全策略、风险评估 | -| **Identity & Access** | IAM、特权访问、MFA | -| **Infrastructure Security** | 网络、计算、存储安全 | -| **Application Security** | 安全开发、测试、部署 | -| **Endpoint Security** | 终端保护、EDR | -| **Logging & Monitoring** | SIEM、日志管理、告警 | -| **Incident Response** | 检测、响应、恢复 | -| **Supply Chain Security** | 第三方风险管理 | -| **Human Factors** | 安全意识、培训、文化 | - -## 5 Maturity Levels - -| Level | 名称 | 描述 | -|-------|------|------| -| **1** | Initial | 无正式流程，响应式安全 | -| **2** | Developing | 基础控制，有文档 | -| **3** | Defined | 标准流程，全面覆盖 | -| **4** | Managed | 持续监控，量化管理 | -| **5** | Optimizing | 持续改进，主动防御 | - -## Level Characteristics - -### Level 1: Initial - -- 无正式安全流程 -- 响应式问题处理 -- 依赖个人知识 -- 无安全指标 - -### Level 2: Developing - -- 基本安全策略 -- 有限的 IAM 控制 -- 基础日志记录 -- 安全事件记录 - -### Level 3: Defined - -- 文档化安全策略 -- 全面的 IAM/MFA -- SIEM 部署 -- 安全培训计划 -- 事件响应流程 - -### Level 4: Managed - -- 持续安全监控 -- 自动化安全控制 -- KPI 追踪 -- 定期渗透测试 -- 威胁情报集成 - -### Level 5: Optimizing - -- AI/ML 驱动的安全 -- 自动化响应 -- 预测性威胁分析 -- 零信任架构 -- 安全即代码 - -## Assessment Areas - -### Governance & Strategy - -| 评估项 | 成熟度等级 | -|--------|-----------| -| 安全策略文档 | L1-L5 | -| 风险评估流程 | L1-L5 | -| 安全指标和报告 | L3-L5 | -| 董事会参与 | L4-L5 | - -### Technical Controls - -| 评估项 | 成熟度等级 | -|--------|-----------| -| IAM/MFA | L2-L5 | -| 网络分段 | L2-L5 | -| 数据加密 | L3-L5 | -| 容器安全 | L3-L5 | -| 云安全态势管理 | L4-L5 | - -### Operational Processes - -| 评估项 | 成熟度等级 | -|--------|-----------| -| 漏洞管理 | L2-L5 | -| 事件响应 | L3-L5 | -| 安全运营 | L4-L5 | -| 合规监控 | L3-L5 | - -## Implementation - -### Step 1: Assessment -- 自我评估或第三方评估 -- 问卷调查 -- 技术验证 - -### Step 2: Gap Analysis -- 对标 CSMM 成熟度等级 -- 识别优先改进项 - -### Step 3: Roadmap -- 制定改进计划 -- 分配资源和责任 -- 设定时间线 - -### Step 4: Execution -- 实施安全改进 -- 持续监控进度 -- 定期复盘 - -## See Also - -- [[Cloud Security]] — 云安全 -- [[Cloud Governance]] — 云治理 -- [[Cloud Maturity Model]] — 云成熟度模型 -- [[Zero Trust]] — 零信任 -- [[CSPM]] — 云安全态势管理 diff --git a/wiki/concepts/Cloud-Service-Delivery.md b/wiki/concepts/Cloud-Service-Delivery.md deleted file mode 100644 index c5b10a0e..00000000 --- a/wiki/concepts/Cloud-Service-Delivery.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: Cloud Service Delivery -tags: - - cloud - - devops - - it-operations -created: 2026-04-22 ---- - -# Cloud Service Delivery - -## Definition - -Cloud Service Delivery encompasses **the entire lifecycle of making cloud services operational, available, secure, performant, and valuable to end-users and customers.** - -**In essence, Cloud Service Delivery is the bridge between the raw capabilities of cloud technology (IaaS, PaaS, SaaS) and the reliable, secure, performant, and cost-effective services that businesses and users actually consume.** - -## The Bridge Concept - -``` -┌─────────────────────────────────────────────────────────────────┐ -│ Cloud Service Delivery │ -│ (The Bridge) │ -│ │ -│ Raw Cloud Capabilities ──────► Business Value for End Users │ -│ (IaaS, PaaS, SaaS) (Reliable, Secure, Performant) │ -└─────────────────────────────────────────────────────────────────┘ -``` - -## 12 Operational Domains - -1. **Service Provisioning & Deployment** — Setting up cloud infrastructure, automating deployments, configuring services, managing resource allocation and scaling -2. **Infrastructure Management** — Monitoring health/performance/capacity, patching, managing physical data center aspects, ensuring HA and DR -3. **Platform Management (PaaS)** — Managing middleware, databases, development tools, runtime environments, platform scalability/security/performance -4. **Application Operations & Management** — Monitoring app performance, deploying updates, managing configuration and secrets, ensuring scalability and resilience -5. **Security & Compliance Management** — Implementing security controls (firewalls, IDS/IPS, encryption, IAM), vulnerability scanning, incident response, regulatory compliance -6. **Performance & Availability Monitoring** — 24/7 monitoring, SLA/SLO tracking, proactive detection, incident response -7. **Incident & Problem Management** — Responding to alerts, troubleshooting, incident management, problem management (root cause analysis) -8. **Change & Configuration Management** — Change control, Infrastructure as Code (IaC), testing and rollback plans -9. **Cost Management & Optimization** — Monitoring consumption, eliminating waste, right-sizing, reserved instances/savings plans -10. **Customer Onboarding & Support** — User setup, documentation, helpdesk/service desk, billing inquiries -11. **Service Governance & Lifecycle Management** — Service catalogs, SLAs, service lifecycle, continuous improvement, vendor management -12. **Backup, Recovery & Disaster Management** — Backup strategies, restore testing, DR plans, failover/failback procedures - -## Cloud Service Delivery Team Roles - -- **Cloud Infrastructure Engineer** -- **Cloud Operation Engineer (DevOps/SRE)** -- **Cloud Security Specialists** -- **Cloud Support Engineer** -- **Cloud FinOps Engineer** - -## Related Concepts - -- [[Cloud DevOps Maturity Model]] — Maturity framework for evaluating cloud DevOps capabilities -- [[AIOps]] — Artificial Intelligence for IT Operations -- [[SLA]] / [[SLO]] — Service Level Agreements/Objectives -- [[FinOps]] — Cloud financial management -- [[DevOps]] — Development and Operations integration -- [[SRE]] — Site Reliability Engineering -- [[ITSM]] — IT Service Management - -## Related Sources - -- [[what-i-know-about-cloud-service-delivery-1]] - -## Best Practices - -| Domain | Best Practice | -|--------|---------------| -| Infrastructure Monitoring | AWS CloudWatch as data source in Grafana | -| Security | Cloud Application WAF management, IP whitelist to tenant level | -| Availability | APM/BPM, New Relic, AWS CloudWatch Synthetic, Health Page | -| Uptime | SLA 99.9% vs 99.99% ([uptime.is](https://uptime.is/)) | -| Alerting | Grafana Alerting with different severity levels | -| Change Management | Planned Change vs Emergency Change | diff --git a/wiki/concepts/CloudHealth.md b/wiki/concepts/CloudHealth.md deleted file mode 100644 index c32b38f6..00000000 --- a/wiki/concepts/CloudHealth.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Cloud Health" -type: concept -tags: - - AWS - - Cost-Optimization - - Monitoring -aliases: - - Cloud Health - - CloudHealth - - 云计算健康 -last_updated: 2026-05-12 ---- - -## Overview - -Cloud Health 是 AWS 提供的云成本分析和监控工具，帮助组织了解、优化和管理云支出。提供资源清单、成本分解、月度账单洞察和趋势分析。 - -## Key Features - -- **资源清单**：全面了解云资源使用情况 -- **成本分析**：按账户、服务、标签等维度分析成本 -- **账单洞察**：月度账单详细分解和趋势追踪 -- **异常检测**：识别异常支出和浪费 -- **RightSizing 建议**：基于使用数据提供优化建议 - -## Related Pages - -- [[FinOps]] -- [[PCG Team]] -- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] diff --git a/wiki/concepts/CloudWatch-Agent.md b/wiki/concepts/CloudWatch-Agent.md deleted file mode 100644 index 32fe504c..00000000 --- a/wiki/concepts/CloudWatch-Agent.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "CloudWatch Agent" -type: concept -tags: [AWS, monitoring, EKS, logging, metrics, CloudWatch] -last_updated: 2026-04-28 ---- - -## Definition - -CloudWatch Agent 是 AWS 提供的统一代理程序，用于从 EC2 实例和 EKS 集群收集系统级指标和日志，并将其发布到 Amazon CloudWatch。它支持收集标准系统指标（CPU/内存/磁盘/网络）以及自定义应用指标，是 EKS 监控栈的核心组件之一。 - -## Key Mechanisms - -- **指标收集**：CPU、内存、磁盘、网络等系统级指标，以及自定义应用指标 -- **日志收集**：从文件系统或容器日志收集日志数据 -- **配置灵活性**：通过 SSM Parameter Store 或配置文件管理代理配置 -- **EKS 集成**：在 EKS 中作为 DaemonSet 部署在每个节点上，与 Container Insights 协同工作 -- **Container Insights**：启用后自动发布容器级指标（CPU/内存/磁盘/网络/容器进程） - -## Relationship with Other Monitoring Components - -CloudWatch Agent 是 EKS 监控数据采集层： -- CloudWatch Agent → 收集原始指标/日志 -- FluentBit → 处理并转发日志到 CloudWatch Logs 或 OpenSearch -- Container Insights → 聚合容器指标到 CloudWatch -- Grafana → 从 CloudWatch/OpenSearch 可视化展示 - -## Sources -- [[ctp-topic-70-eks-deployment-using-iac]] -- [[ctp-topic-42-grafana-observability-dashboard]] -- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] diff --git a/wiki/concepts/CloudWatch-Events.md b/wiki/concepts/CloudWatch-Events.md deleted file mode 100644 index 43b000ac..00000000 --- a/wiki/concepts/CloudWatch-Events.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "CloudWatch Events" -type: concept -tags: - - AWS - - Event-Driven - - Serverless - - Scheduling -sources: - - ctp-topic-27-aws-instance-scheduler -last_updated: 2026-05-12 ---- - -## CloudWatch Events - -AWS 事件驱动服务（原名 Amazon EventBridge），用于构建事件驱动的架构，实现 AWS 资源变更与应用程序之间的自动化响应。 - -## Role in AWS Instance Scheduler - -在 AWS Instance Scheduler 架构中，CloudWatch Events 充当**定时触发器**： - -- **默认触发间隔**：每 15 分钟触发一次 -- **触发目标**：Lambda 函数 -- **事件内容**：包含当前时间戳和调度评估所需的上下文信息 -- Lambda 函数读取 DynamoDB 中的调度配置，根据实例标签决定是否执行启停操作 - -## Key Characteristics - -- **完全托管**：无需管理服务器或基础设施 -- **近实时**：支持分钟级定时触发 -- **规则驱动**：通过规则（Rule）定义事件模式和目标 -- **多目标支持**：可触发 Lambda、ECS 任务、SQS 队列等多种目标 -- **跨账户事件**：配合 EventBridge Bus 实现跨账户事件路由 - -## Related Pages -- [[AWS-Instance-Scheduler]] — 主要使用场景 -- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源 diff --git a/wiki/concepts/Cluster-Autoscaler.md b/wiki/concepts/Cluster-Autoscaler.md deleted file mode 100644 index 88bd91d9..00000000 --- a/wiki/concepts/Cluster-Autoscaler.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Cluster Autoscaler" -type: concept -tags: - - Kubernetes - - EKS - - Autoscaling - - Node - - AWS - - ASG -sources: - - ctp-topic-64-scaling-out-with-amazon-eks - - ctp-topic-70-eks-deployment-using-iac -last_updated: 2026-04-28 ---- - -## Definition -Cluster Autoscaler 是 Kubernetes 官方的节点（Node）级别扩缩容组件，通过联动 AWS Auto Scaling Group（ASG）或托管节点组（Managed Node Group），根据集群内 Pending Pod 的数量和资源请求自动调整节点数量。 - -## Key Mechanisms -- **扩缩容决策依据**：集群内 Pending Pod 的数量（而非直接基于资源利用率） -- **资源请求感知**：考虑 Pod 的 CPU/内存 requests，不仅仅是当前实际使用量 -- **ASG/节点组联动**：更新 ASG 或托管节点组的期望容量（Desired Capacity） -- **Auto-discovery 模式**：推荐使用，自动发现和管理 ASG -- **Mixed Instances Policy**：支持在同一 ASG 中混合使用多种 EC2 实例类型 -- **配置变更**：min/max 配置变更应在 ASG/托管节点组层面操作，而非直接修改 Cluster Autoscaler - -## Relationship with Karpenter -- **Cluster Autoscaler**：基于节点组间接扩缩容，响应相对较慢 -- **Karpenter**：直接与 EC2 API 交互，响应更快速灵活，是 Cluster Autoscaler 的演进方案 - -## Limitations -- 依赖预配置的 ASG/节点组，灵活性受限 -- 扩容速度受 ASG 启动新实例的速度限制 -- 无法处理需要特殊实例类型的工作负载 - -## Sources -- [[ctp-topic-64-scaling-out-with-amazon-eks]] -- [[ctp-topic-70-eks-deployment-using-iac]] diff --git a/wiki/concepts/Cockpit-Ergonomics.md b/wiki/concepts/Cockpit-Ergonomics.md deleted file mode 100644 index 84cbd67d..00000000 --- a/wiki/concepts/Cockpit-Ergonomics.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Cockpit Ergonomics" -type: concept -tags: [] -last_updated: 2026-04-25 ---- - -## Definition -座舱人体工学——研究如何设计 XR 座舱环境，使控制装置、仪表盘和显示界面与用户自然的身体运动（眼-手-头协调流动）保持对齐，最大化长时间使用的舒适性并降低认知负荷。 - -## Core Principles -- **眼-手-头协调流动**（Eye–Hand–Head Flow）：控制装置布局需与自然的视线移动路径和手部运动范围对齐 -- **固定视角锚定**（Fixed Perspective Anchoring）：用户视角固定，通过物理移动控制器而非移动身体来操作 -- **人体测量学适配**：考虑不同用户的身体尺寸，调整座椅高度、控制杆位置等 -- **最小化眩光和视觉干扰**：仪表盘布局优化，减少视觉疲劳 - -## Related Concepts -- [[Constraint-Driven-Control-Mechanics]]：约束驱动机制——座舱人体工学的交互实现手段 -- [[Motion-Sickness-Threshold]]：运动病阈值——座舱人体工学的核心优化指标 -- [[Spatial-Computing]]：空间计算——座舱环境的空间技术基础 - -## Sources -- [[xr-cockpit-interaction-specialist]] diff --git a/wiki/concepts/Code-Signing.md b/wiki/concepts/Code-Signing.md deleted file mode 100644 index dc9dfc8d..00000000 --- a/wiki/concepts/Code-Signing.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "Code Signing" -type: concept -tags: [Code-Signing, Software-Supply-Chain, Security, Cryptography, DevOps, OpenText] -sources: - - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet -last_updated: 2026-05-11 ---- - -## Code Signing - -Code Signing（代码签名）是软件供应链安全的关键机制，通过数字签名确保构建产物的完整性和来源可信，是 Project Thor 供应链安全战略的核心环节。 - -## Code Signing - -Code Signing is a critical mechanism for software supply chain security that uses digital signatures to ensure the integrity and trustworthiness of build artifacts. It is a core component of Project Thor's supply chain security strategy. - -## Aliases -- Code Signing -- 代码签名 -- 软件签名 - -## Key Facts - -| 维度 | 说明 | -|------|------| -| 目的 | 确保构建产物完整性 + 来源可信 | -| 位置 | 供应链数据流：Build Farms → Artifactory 之间 | -| 隶属于 | [[Project-Thor]] 安全与治理支柱 | -| 关键原则 | 构建产物在交付客户环境前必须经过签名验证 | - -## 供应链安全中的角色 - -``` -GitLab（源代码） - ↓ -Build Farms（制造流程） - ↓ Code Signing（签名） -Artifactory（制品仓库） - ↓ -客户环境 -``` - -Arnold Dacan 强调源代码的供应链核心地位，而 Code Signing 则确保从构建到交付的全链路可信赖。 - -## 与 Supply Chain Security 的关系 - -Code Signing 是 [[Supply Chain Security]] 的关键技术手段之一： -- 确保制品未被篡改（完整性验证） -- 验证构建来源（身份认证） -- 防止供应链攻击（如依赖注入、恶意构建） - -## Connections - -- [[Code-Signing]] ← security_practice ← [[Project-Thor]] -- [[Code-Signing]] ← secures ← [[Supply-Chain-Security]] -- [[Code-Signing]] ← part_of ← 供应链数据流（Build Farms → Artifactory） -- [[GitLab]] ← provides ← Source → [[Code-Signing]] 验证 - -## Sources - -- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]] diff --git a/wiki/concepts/CodeOverConfiguration.md b/wiki/concepts/CodeOverConfiguration.md deleted file mode 100644 index 6b4ef00b..00000000 --- a/wiki/concepts/CodeOverConfiguration.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: "CodeOverConfiguration" -type: concept -tags: [cms, development, best-practices] -last_updated: 2026-05-01 ---- - -## Definition - -CodeOverConfiguration is a CMS development principle requiring that all structural changes — custom post types, taxonomies, fields, blocks, and behavioral settings — be registered in code rather than created through the admin UI. Configuration that affects behavior is also stored in code (not the database). - -## Core Principle - -> "Custom post types, taxonomies, fields, and blocks are registered in code — never created through the admin UI alone." - -## WordPress Application - -| What | Where to register | -|------|-------------------| -| Custom post types | `functions.php` → `register_post_type()` | -| Custom taxonomies | `functions.php` → `register_taxonomy()` | -| ACF field groups | `acf-json/` directory (synced) | -| ACF blocks | `functions.php` → `acf_register_block_type()` | -| Gutenberg blocks | `block.json` + JS registration | -| Theme settings | `wp-config.php` or `functions.php` | - -### Example: Post type in code - -```php -add_action( 'init', function () { - register_post_type( 'case_study', [ - 'public' => true, - 'show_in_rest' => true, - 'supports' => [ 'title', 'editor', 'thumbnail', 'excerpt' ], - ] ); -} ); -``` - -## Drupal Application - -| What | Where to store | -|------|---------------| -| Content types | YAML config export (`drush cex`) | -| Field definitions | YAML config in `config/install/` | -| Custom modules | PHP code + YAML routing/permissions | -| Blocks | PHP attribute-based plugins (Drupal 10+) | -| Views | YAML config export | - -## Why It Matters - -- **Version control**: All structural changes are tracked in Git -- **Reproducibility**: A fresh environment gets the same structure from a deploy script -- **Team consistency**: No one accidentally changes a field label in production -- **Deployment safety**: Config changes go through CI/CD, not manual admin actions - -## Anti-patterns - -- ❌ Creating post types via the WordPress admin UI without code equivalent -- ❌ Storing CMS settings that affect behavior in the database instead of code -- ❌ Modifying contrib module/theme files directly instead of using hooks/overrides - -## Related Concepts - -- [[ContentModel-first]] — the companion principle: define the model first, then implement -- [[GitWorkflow]] — version control makes code-as-config viable -- [[WordPress]] — WordPress-specific code registration patterns -- [[Drupal]] — Drupal-specific YAML configuration export workflow - -## Sources -- [[engineering-cms-developer]] diff --git a/wiki/concepts/CodeWeaver.md b/wiki/concepts/CodeWeaver.md deleted file mode 100644 index cb9beb0c..00000000 --- a/wiki/concepts/CodeWeaver.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "CodeWeaver" -type: concept -tags: [] -last_updated: 2025-12-30 ---- - -## Definition - -CodeWeaver 是一个 GitHub 开源工具（tesserato/CodeWeaver），可将任意代码库编织成一个可导航的 Markdown 文档。 - -## Key Features - -- **树形结构**：将整个项目组织成清晰的树形 Markdown 文件 -- **代码块嵌入**：所有代码都塞进代码块中，保持可复制性 -- **可导航性**：生成的文档支持跳转和导航 -- **AI 友好**：极大地简化了代码库的共享、文档化以及与 AI/ML 工具集成 - -## Use Cases - -- **知识转移**：快速分享复杂代码库的结构 -- **AI 上下文注入**：为 AI 代理提供代码库概览 -- **文档生成**：自动生成项目文档 - -## Related Concepts - -- [[Vibe Coding]]：CodeWeaver 可增强 Vibe Coding 的代码理解能力 - -## Sources - -- [[vibe-coding经验收集]] diff --git a/wiki/concepts/CodebaseOnboarding.md b/wiki/concepts/CodebaseOnboarding.md deleted file mode 100644 index 4a12856a..00000000 --- a/wiki/concepts/CodebaseOnboarding.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "CodebaseOnboarding" -type: concept -tags: [] -last_updated: 2026-05-02 ---- - -## Definition - -Codebase Onboarding 是帮助新开发者快速理解陌生代码库的方法论和实践体系。核心目标是缩短从"首次接触代码库"到"能够独立定位问题、修改代码"的认知建立时间。 - -## Core Principles - -- **Evidence-first**: 只陈述代码中可验证的事实 -- **Layered explanation**: 分层递进式解释（一句话 → 五分钟 → 深度代码流） -- **File-level precision**: 所有结论必须指向具体文件路径 -- **Honest scope**: 明确告知哪些部分已检查、哪些未检查 - -## Key Methods - -1. **Inventory & Classification** — 识别清单文件（manifests/lockfiles）、框架标记、构建工具、顶层目录 -2. **Entry Point Discovery** — 找到启动文件、路由、处理器、CLI 命令 -3. **Execution Tracing** — 端到端追踪输入→验证→编排→持久化→输出 -4. **Boundary Analysis** — 识别模块边界、包边界、共享工具、重复职责 - -## Usage Context - -- 新开发者 onboarding -- 大型代码库结构探索 -- 故障定位前的代码结构理解 - -## Related Concepts - -- [[ExecutionTracing]] — 执行路径追踪 -- [[EvidenceFirstReasoning]] — 证据优先推理 -- [[MinimalChangePrinciple]] — 与 [[EngineeringMinimalChangeEngineer]] 配合使用 diff --git a/wiki/concepts/Cognitive-Distortions.md b/wiki/concepts/Cognitive-Distortions.md deleted file mode 100644 index a0f7f444..00000000 --- a/wiki/concepts/Cognitive-Distortions.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Cognitive Distortions" -type: concept -tags: [] -sources: ["academic-psychologist"] -last_updated: 2026-04-20 ---- - -## Definition - -认知扭曲（Cognitive Distortions）由 **Aaron Beck** 在认知疗法（CT）中系统化，指个体在处理信息时系统性地产生的非理性思维错误模式——是抑郁和焦虑的认知基础。 - -## 十大经典认知扭曲类型 - -| 类型 | 定义 | 例子 | -|------|------|------| -| **全或无思维（All-or-Nothing）** | 二元极端评价 | "要么完美，要么失败" | -| **过度概括（Overgeneralization）** | 单个事件→普遍结论 | 一次被拒→"我永远不受欢迎" | -| **心理过滤（Mental Filter）** | 放大负面，忽略正面 | 只记住批评，忘记所有赞美 | -| **否定正面（Disqualifying the Positive）** | 将正面经历解读为偶然 | "那只是运气好" | -| **贴标签（Labeling）** | 将错误=身份 | "我是个失败者" | -| **放大/缩小（Magnification/Minimization）** | 放大负面，缩小正面 | 夸大缺点，缩小优点 | -| **读心术（Mind Reading）** | 假设知道他人想法 | "他们一定在嘲笑我" | -| **预言先知（Fortune Telling）** | 预测未来为负面 | "我知道这件事会失败" | -| **情绪推理（Emotional Reasoning）** | 以感觉代替事实 | "我感觉内疚，所以我一定有错" | -| **应该陈述（Should Statements）** | 僵化的规则语言 | "我应该总是坚强" | - -## Key References - -- **Aaron Beck**：认知疗法（CT）创始人，系统识别并分类认知扭曲 - -## Applications in Character Design - -- 识别角色的**主导认知扭曲**→预测其在特定情境下的行为反应 -- 认知扭曲是行为决策的**认知引擎**——扭曲的类型决定角色的判断偏误 -- 结合 [[Defense-Mechanisms]]：认知扭曲常是无意识防御机制的认知表达 -- 结合 [[Neuroticism]]（Big Five）：Neuroticism 高分角色更易激活认知扭曲 - -## Limitations - -- Beck 认知扭曲最初从抑郁症研究中发展，泛化到正常人群需谨慎 -- 文化差异：某些"扭曲"在特定文化背景下可能是"正常"思维 - -## Connections - -- [[Psychological-Profile]]（Cognitive Distortions 是驱动角色决策的核心机制） -- [[Defense-Mechanisms]]（部分扭曲是无意识防御的认知层面表现） -- [[Cognitive-Behavioral-Therapy]]（CBT 通过识别和挑战扭曲来治疗） diff --git a/wiki/concepts/Cognitive-Load-Reduction.md b/wiki/concepts/Cognitive-Load-Reduction.md deleted file mode 100644 index 0a612ef5..00000000 --- a/wiki/concepts/Cognitive-Load-Reduction.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Cognitive Load Reduction" -type: concept -tags: [] -sources: ["product-behavioral-nudge-engine"] -last_updated: 2026-05-01 ---- - -## Definition - -Cognitive Load Reduction（认知负荷降低）是一种软件交互设计原则——通过信息过滤、任务分解和界面简化，主动降低用户在决策和执行过程中的认知负担，防止因信息过载导致的决策瘫痪和平台流失。 - -## Core Problem - -> "If a user has 50 items pending, do not show them 50. Show them the 1 most critical item." - -大量待办任务列表是认知过载的典型来源。当用户面对大量未完成任务时，会产生「决策瘫痪」——因无法决定从何处开始而选择什么都不做。 - -## Strategy Taxonomy - -| 策略 | 描述 | 示例 | -|------|------|------| -| 信息过滤 | 只展示最关键的N项 | 任务列表只显示 Top 1 | -| 任务分解 | 将复杂任务拆解为微步骤 | 将「完成项目报告」拆解为「只写第一段」 | -| 预设草案 | 预先填充内容减少起步阻力 | [[Default Bias]] 的应用 | -| 时间盒 | 限制单次执行时长 | [[Micro-Sprint]] 5分钟冲刺 | -| 进度可见 | 展示已完成vs总任务数 | 庆祝15个已完成而非展示95个待完成 | - -## Behavioral Science Foundation - -- **Miller's Law**：人类工作记忆容量约为 7±2 个信息块 -- **Zeigarnik Effect**：未完成任务比已完成任务占用更多认知资源 -- **Goal Gradient Effect**：越接近目标，动机越强——通过展示小范围完成积累信心 - -## Related Concepts - -- [[Micro-Sprint]] — 认知负荷降低的核心执行机制 -- [[Default Bias]] — 通过预设草案降低决策门槛 -- [[Gamification]] — 通过进度可视化维持动力 -- [[Habit Formation]] — 低认知负荷是习惯形成的前提条件 - -## Connections - -- [[Behavioral Nudge Engine]] — 认知负荷管理是核心职责 -- [[Product Manager Agent]] — 产品设计需内化认知负荷原则 -- [[Habit Tracker & Accountability Coach]] — 低摩擦的habit建立依赖认知负荷控制 diff --git a/wiki/concepts/Color-Grading.md b/wiki/concepts/Color-Grading.md deleted file mode 100644 index 57320f6f..00000000 --- a/wiki/concepts/Color-Grading.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Color Grading" -type: concept -tags: [video-editing, post-production, color, cinematography] -sources: [marketing-short-video-editing-coach] -last_updated: 2026-04-26 ---- - -## Aliases -- 色彩调色 -- 调色 -- Color Correction（初级校正） -- 色彩分级 - -## Definition -色彩调色是通过调整画面的色彩、色调、对比度和饱和度，将原始素材转化为具有特定视觉风格或情绪基调的创作过程。与简单的"加滤镜"不同，专业调色遵循二元体系：**初级校正**（Primary Correction）恢复画面真实感 + **次级调色**（Secondary Grading）实现风格化表达。 - -## Two-Tier Workflow -1. **初级校正**：恢复真实——白平衡（色温/色调）、曝光、对比度、高光/阴影/白色/黑色四向微调、饱和度与自然饱和度（Vibrance）调整。目标：所有镜头在曝光、色温、对比度上保持一致。 -2. **次级调色**：风格化——HSL 调整（独立调整特定颜色的色相/饱和度/明度）、曲线（RGB 和色调曲线精细控制）、限定器/遮罩（针对特定区域或颜色范围局部调整）、肤色校正（确保肤色在矢量示波器的肤色线上）。 - -## Stylistic Grading Directions -- **Cinematic（电影感）**：低饱和度 + 青橙对比（阴影偏青/高光偏橙）+ 轻微颗粒 -- **Japanese Fresh（日系清新）**：高亮度 + 低对比度 + 青绿调 + 提亮阴影 -- **Cyberpunk（赛博朋克）**：高饱和霓虹色（品红/青/蓝）+ 高对比度 + 压黑 -- **Vintage Film（复古胶片）**：黄绿调 + 红棕阴影 + 颗粒 + 轻微褪色 -- **Morandi（莫兰迪）**：低饱和度 + 灰调 + 低调优雅 - -## LUT（Look-Up Table） -- **技术 LUT**：将 LOG 素材转换为标准色彩空间（如 S-Log3 → Rec.709） -- **创意 LUT**：添加风格化外观预设 -- **使用规范**：LUT 是起点而非终点，套用后必须微调参数；推荐强度 60%-80%，100% 通常过重 - -## Key Principles -- 初级校正是必须步骤——不做初级校正直接套创意 LUT 必然导致色彩崩坏 -- 风格一致性：单片内所有镜头色调必须统一；系列视频必须保持统一的频道风格 -- 肤色优先：使用矢量示波器确保肤色落在"肤色线"上 - -## Related Concepts -- [[Speed-Ramping]]：Speed Ramping 通常配合色彩调色增强视觉冲击力 -- [[LUT]]：色彩调色的工具和预设格式 -- [[Color-Grading]] ← 二元体系核心 → 初级校正（[[marketing-short-video-editing-coach]]）+ 次级调色 - -## Source -[[marketing-short-video-editing-coach]] diff --git a/wiki/concepts/Columnar-Storage.md b/wiki/concepts/Columnar-Storage.md deleted file mode 100644 index 9af7c799..00000000 --- a/wiki/concepts/Columnar-Storage.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Columnar Storage" -type: concept -tags: - - Data-Warehouse - - Storage - - Performance -sources: - - ctp-topic-68-introduction-to-redshift -last_updated: 2026-04-23 ---- - -## Overview -列式存储（Columnar Storage）是一种数据存储格式，数据按列而非按行组织。专为分析型工作负载（OLAP）设计，相比传统行式存储能显著提升聚合查询和全表扫描性能，同时降低存储空间需求。 - -## How It Works -行式存储按行存储：`[row1_col1, row1_col2, row1_col3, row2_col1, row2_col2, row2_col3, ...]` -列式存储按列存储：`[col1_row1, col1_row2, ..., col2_row1, col2_row2, ..., col3_row1, col3_row2, ...]` - -## Key Advantages -- **查询性能**：只需读取查询涉及的列，避免全行读取 I/O 开销 -- **压缩效率**：同一列数据类型一致，压缩比更高（如 Dictionary Encoding、Run-Length Encoding） -- **向量化执行**：列式数据可直接进行 SIMD 向量化计算，CPU 利用率更高 -- **聚合查询友好**：COUNT/SUM/AVG 等聚合仅需读取相关列 - -## Trade-offs -- **点查询效率低**：单行更新/插入需读写整列数据 -- **写入放大**：行更新涉及多列修改 -- **适用场景受限**：适合读密集型分析，不适合频繁更新的事务处理 - -## Applications -- **数据仓库**：Amazon Redshift、Google BigQuery、Snowflake、ClickHouse -- **列式文件系统**：Apache Parquet、Apache ORC -- **分析型数据库**：Apache Druid、Apache Kylin - -## Related Concepts -- [[MPP]]：列式存储常与 MPP 架构结合，实现大规模并行分析 -- [[Sort-Key]]：在列式存储中排序键可进一步优化范围查询性能 -- [[Data Compression]]：列式存储天然适合高压缩比 diff --git a/wiki/concepts/Command-Theater-Interface.md b/wiki/concepts/Command-Theater-Interface.md deleted file mode 100644 index 0a876b6c..00000000 --- a/wiki/concepts/Command-Theater-Interface.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Command Theater Interface" -type: concept -tags: [spatial-computing, xr, interface-design, ux] -last_updated: 2026-03-05 ---- - -## Definition - -命令剧院（Command Theater）——以用户为中心的空间界面布局范式，以弧形剧场形式围绕用户组织内容。源自 [[nexus-spatial-discovery]] 中 [[XR-Interface-Architect]] 的设计。 - -## Architecture - -``` - OVERVIEW CANOPY - (pipeline topology) - ~~~~~~~~~~~~~~~~~~~~~~~~ - / \ - / FOCUS ARC (120 deg) \ - / primary node graph work \ - /________________________________\ - | | - LEFT | USER POSITION | RIGHT - UTILITY | (origin 0,0,0) | UTILITY - RAIL | | RAIL - |__________________________________| - \ / - \ SHELF (below sightline) / - \ agent status, quick tools/ - \_________________________ / -``` - -## Four Zones - -| Zone | Position | Content | -|------|----------|---------| -| Focus Arc | 120°, 1.2-2.0m | Primary node graph workspace | -| Overview Canopy | above, 2.5-4.0m | Miniature pipeline topology + health heatmap | -| Utility Rails | left/right flanks | Agent library, monitoring, logs | -| Shelf | below sightline, 0.8-1.0m | Run/stop, undo/redo, quick tools | - -## Three-Layer Depth System - -| Layer | Depth | Content | Opacity | -|-------|-------|---------|---------| -| Foreground | 0.8-1.2m | Active panels, inspectors, modals | 100% | -| Midground | 1.2-2.5m | Node graph, connections, workspace | 100% | -| Background | 2.5-5.0m | Overview map, ambient status | 40-70% | - -## Design Rationale - -- 用户处于中心，信息按重要性和使用频率分层 -- z-axis（深度）对应执行顺序：input nodes 最远，output nodes 最近 -- 减少晕动症：所有交互发生在 0.8-2.5m 范围 -- 与 [[Semantic-Zoom]] 配合实现渐进式空间复杂度 - -## Related Concepts - -- [[Semantic-Zoom]]：与 Command Theater 配合的导航范式 -- [[SpatialAIOps]]：Command Theater 的应用场景 -- [[Nexus-Spatial]]：Command Theater 的产品实现 diff --git a/wiki/concepts/Command-Theater.md b/wiki/concepts/Command-Theater.md deleted file mode 100644 index 0011c25b..00000000 --- a/wiki/concepts/Command-Theater.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Command Theater" -type: concept -tags: [] -last_updated: 2026-03-05 ---- - -## Definition - -Command Theater（指挥剧场）是 [[nexus-spatial-discovery]] 中 [[Nexus Spatial]] 产品定义的空间界面布局架构——以用户为中心的弧形"指挥剧场"，将工作空间按功能分层布局于不同深度和角度。 - -## Architecture - -``` - OVERVIEW CANOPY - (pipeline topology) - ~~~~~~~~~~~~~~~~~~~~~~~~ - / \ - / FOCUS ARC (120 deg) \ - / primary node graph work \ - /________________________________\ - | | - LEFT | USER POSITION | RIGHT - UTILITY | (origin 0,0,0) | UTILITY - RAIL | | RAIL - |__________________________________| - \ / - \ SHELF (below sightline) / - \ agent status, quick tools/ - \_________________________ / -``` - -## Four Zones - -| 区域 | 深度范围 | 内容 | 透明度 | -|------|---------|------|--------| -| **Overview Canopy**（天幕） | 2.5–4.0m | 管线拓扑 + 健康热力图 | 40–70% | -| **Focus Arc**（聚焦弧） | 1.2–2.0m | 主节点图工作区 | 100% | -| **Utility Rails**（工具轨） | 侧翼 | Agent 库、监控、日志 | 100% | -| **Shelf**（置物架） | 0.8–1.0m | 运行/停止、撤销、快捷工具 | 100% | - -## Three-Layer Depth System - -| 层级 | 深度 | 内容 | 透明度 | -|------|------|------|--------| -| Foreground（前景） | 0.8–1.2m | 活跃面板、检测器、模态框 | 100% | -| Midground（中景） | 1.2–2.5m | 节点图、连接线、工作区 | 100% | -| Background（背景） | 2.5–5.0m | 概览地图、环境状态 | 40–70% | - -## Design Rationale - -- **120 度聚焦弧**覆盖人眼自然视野中心区域 -- **垂直分层**（天幕→聚焦→置物架）符合"最重要信息在视线中心，次要在下方"的直觉 -- **侧翼工具轨**让主工作区保持无遮挡 -- **深度层级**允许信息密度分层——背景展示概览，前景展示细节 - -## Connections - -- [[SpatialAIOps]] ← 界面架构层 -- [[Command-Theater]] ← 自身引用 -- [[4-Level-Semantic-Zoom]] ← 导航模式 diff --git a/wiki/concepts/Community-Credibility.md b/wiki/concepts/Community-Credibility.md deleted file mode 100644 index a6da834e..00000000 --- a/wiki/concepts/Community-Credibility.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Community Credibility（社区信誉）" -type: concept -tags: [marketing, community, trust, engagement] -sources: [marketing-zhihu-strategist] -last_updated: 2026-04-21 ---- - -## Definition -社区信誉（Community Credibility）——通过真实专业知识分享和积极的社区参与，在特定平台上赢得目标受众的信任和认可。信誉是稀缺资源，一旦受损难以恢复，必须持续维护。 - -## Core Principles -- **真实性**：只承诺你能兑现的专业价值 -- **持续性**：信誉来自长期一致的优质输出 -- **互动性**：主动参与评论、讨论，建立真实关系 -- **谦逊性**：承认知识边界，不过度承诺 -- **透明度**：利益相关必须披露，保持信息透明 - -## Credibility on Zhihu -知乎是信誉优先平台，社区信誉决定内容曝光和粉丝增长： -- **知乎信誉来源**：专业认证 + 高赞内容 + 同行认可 -- **信誉破坏**：硬推销、泛娱乐内容、低质量回答会被算法抑制 -- **信誉增长**：持续提供真实有价值的专业知识，与社区深度互动 - -## Credibility vs Virality -| 维度 | 信誉驱动（知乎） | 流量驱动（抖音） | -|------|----------------|----------------| -| 内容长度 | 300+ 词深度内容 | 15-60 秒短内容 | -| 评估指标 | 点赞、专业认可 | 完播率、分享率 | -| 增长机制 | 慢但持久 | 快但易衰退 | -| 转化路径 | 精准线索 | 冲动消费 | - -## Connections -- [[Thought-Leadership]] ← 驱动 ← Community Credibility（思想领导力是信誉的核心理由） -- [[Lead-Generation-Funnel]] ← 依赖 ← Community Credibility（信誉是精准转化的前提） diff --git a/wiki/concepts/Compaction.md b/wiki/concepts/Compaction.md deleted file mode 100644 index 501b039b..00000000 --- a/wiki/concepts/Compaction.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Compaction" -type: concept -last_updated: 2026-04-10 ---- - -## Definition -Compaction 是 OpenClaw 对话上下文压缩机制，用于在 token 接近上限时将历史对话压缩为摘要，释放上下文空间。 - -## Safeguard Mode -在 safeguard 模式下，OpenClaw 会预留 16K tokens 用于执行压缩操作： -- `reserveTokensFloor`: 压缩预留 token 下限 -- 当模型 context window 较小时（如 deepseek-reasoner 的 16K），预留空间与 context 相等导致实际可用空间为 0 - -## Configuration Levels -- **全局配置** (`openclaw.json`): 影响所有 Agent -- **Agent 级别配置** (routing rules): 影响特定 Agent/Channel，优先级更高 - -## Related -- [[Context-Window]]: 压缩的必要性来自 context window 的限制 -- [[Agent-Routing-Rules]]: Agent 级别配置可能覆盖全局 compaction 设置 -- [[上下文压缩]]: 已在 [[养龙虾5天血泪史]] 中详细讨论 - -## Sources -- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]] -- [[养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录]] diff --git a/wiki/concepts/Competing-Consumer-Pattern.md b/wiki/concepts/Competing-Consumer-Pattern.md deleted file mode 100644 index 4da507d4..00000000 --- a/wiki/concepts/Competing-Consumer-Pattern.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Competing Consumer Pattern" -type: concept -tags: - - EDA - - Architecture - - Messaging - - Cloud -last_updated: 2026-04-14 ---- - -## Aliases -- Competing Consumers -- 竞争消费者模式 -- 多消费者竞争模式 - -## Definition -竞争消费者模式（Competing Consumer Pattern）指多个消费者共享同一个消息队列，但每条消息只被其中一个消费者处理。确保消息处理的负载均衡和故障容错。 - -## Implementation -- **AWS SQS**：设置多个消费者从同一标准队列拉取消息，SQS 自动将消息分配给可用的消费者 -- 消费者之间的竞争通过 SQS 的隐式负载均衡机制实现 - -## Key Characteristics -- **Mutual Exclusion**：每条消息只被一个消费者处理 -- **Load Balancing**：消息自动分配给空闲的消费者 -- **Fault Tolerance**：某消费者失败，其获取的消息会重新入队供其他消费者处理 -- **Ordering Not Guaranteed**：标准 SQS 不保证消息顺序 - -## Use Cases -- 并行处理大量独立任务（如图片处理、文件转换） -- 将工作负载分发到多个 Lambda 函数或 ECS 任务 -- 实现工作线程池的消息分发 - -## Ordered Alternative -如需保证消息顺序，使用 **SQS FIFO 队列** + **单一消费者**，或在 Kinesis 中使用分片键保证同类型消息有序处理。 - -## Sources -- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] diff --git a/wiki/concepts/Competition-Analysis.md b/wiki/concepts/Competition-Analysis.md deleted file mode 100644 index 9da6c776..00000000 --- a/wiki/concepts/Competition-Analysis.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Competition-Analysis" -type: concept -tags: [] -last_updated: 2026-04-22 ---- - -## Overview -在项目启动前，通过多平台（GitHub/npm/PyPI/Hacker News/Product Hunt）扫描竞品的存在性、成熟度和市场关注度的分析过程。是 [[Pre-Build Validation]] 的核心组成部分，帮助 AI Agent 和创业者判断赛道的真实竞争状态。 - -## 5 Data Sources -| 平台 | 评估维度 | 代表性指标 | -|---|---|---| -| GitHub | 仓库数量、Star 总数、贡献者活跃度 | Top 竞品 star counts | -| npm | Node.js 包数量、下载量趋势 | 包生态成熟度 | -| PyPI | Python 包数量、pip 安装量 | Python 领域成熟度 | -| Hacker News | 讨论帖数量、帖子分数 | 技术社区关注度 | -| Product Hunt | 早期产品数量、Upvote 数 | 市场需求验证 | - -## Process -1. 输入：项目想法描述 -2. 扫描：5 个平台并行查询 -3. 聚合：综合评分（[[Reality-Signal]]） -4. 输出：竞品列表 + 评分 + 转向建议 - -## Output Example -``` -reality_signal: 90/100 (very high) - -Top competitors: -1. Gitea — 53,940 stars -2. reviewdog — 9,104 stars -3. Danger (Ruby) — 5,649 stars - -This space has 143,000+ related repos. - -Pivot suggestions: -- Focus on a specific language (Rust/Go-only) -- Target a specific framework (React/Vue component review) -- Target a specific industry (financial/medical compliance) -``` - -## Relationship to Related Concepts -- [[Pre-Build Validation]] ← 核心组成部分 -- [[Reality-Signal]] ← 输出指标 -- [[Pivot-Strategy]] ← 拥挤赛道的后续行动 -- [[idea-reality-mcp]] ← 技术实现工具 - -## Related -- [[Pre-Build Validation]] -- [[Reality-Signal]] -- [[Pivot-Strategy]] -- [[idea-reality-mcp]] -- [[Startup MVP Pipeline]] diff --git a/wiki/concepts/CompletionRate.md b/wiki/concepts/CompletionRate.md deleted file mode 100644 index 848702e9..00000000 --- a/wiki/concepts/CompletionRate.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Completion Rate" -type: concept -tags: [podcast, analytics, metrics] -sources: [marketing-podcast-strategist] -last_updated: 2026-04-26 ---- - -# Completion Rate（完成率） - -播客完成率是指听众完整听完一期节目的百分比，是衡量播客内容质量的核心指标。 - -## 定义 - -$$\text{完成率} = \frac{\text{听完的时长}}{\text{总时长}} \times 100\%$$ - -- 行业优秀标准：**> 50%** 完播率 -- 顶级播客：70%+ 完成率 - -## 为什么比播放量更重要 - -| 指标 | 反映 | 局限性 | -|------|------|--------| -| 播放量 | 流量规模 | 可被标题党骗点击，但不反映质量 | -| **完成率** | **内容质量 + 听众粘性** | 真正听完的才有价值 | - -核心洞察：*"一个完整听完的 episode 远比一个被跳过的 episode 有价值。"* - -## 驱动完成率的内容策略 - -### 音频优先思维（Audio-first Thinking） -- 每 10-15 分钟设置一个"钩子"拉回听众注意力 -- 钩子形式：反直觉观点、故事、数据点、问答 -- 避免超过 3 分钟的纯理论枯燥段落——将其拆分为两个短段落，中间插入具体案例 - -### 开场策略 -- 通勤场景听众注意力最易漂移 -- 前 3 分钟必须给出本期节目的价值承诺 -- 不要在开头做冗长自我介绍 - -### 结构设计 -- 清晰的章节和时间戳 -- 每个章节有小的主题转换 -- 结尾有明确的收束和行动号召 - -## 与其他指标的关联 - -- [[Completion Rate]] ↑ → 听众信任度 ↑ → 品牌合作价值 ↑ -- [[Completion Rate]] ↑ → 播客平台推荐权重 ↑ -- [[Completion Rate]] ↑ → 会员/付费转化率 ↑（[[Marketing Podcast Strategist]]） - -## Connections -- [[Marketing Podcast Strategist]] ← authored_by ← [[Completion Rate]] 作为核心内容质量指标 -- [[Podcast Positioning]] ← optimized_by ← [[Completion Rate]] 数据反馈 -- [[Audio Production Standards]] ← supports ← [[Completion Rate]]：音质是完成率的基础保障 - -## Aliases -- 完播率 -- Episode Completion Rate -- 播客完成率 diff --git a/wiki/concepts/Compliance-Automation.md b/wiki/concepts/Compliance-Automation.md deleted file mode 100644 index 05a38d97..00000000 --- a/wiki/concepts/Compliance-Automation.md +++ /dev/null @@ -1,69 +0,0 @@ -# Compliance Automation - -## Definition -Compliance automation uses technology to automatically enforce, monitor, and validate security and regulatory compliance requirements. - -## Aliases -- Automated Compliance -- Policy Automation -- Regulatory Automation - -## Concept -合规自动化使用技术手段自动执行、监控和验证安全及监管合规要求。 - -## Key Frameworks - -### SOC 2 -System and Organization Controls 2 — 针对服务组织的安全、可用性、处理完整性、保密性和隐私控制的合规框架。 - -### ISO 27001 -国际信息安全管理体系标准，提供建立、实施、维护和持续改进信息安全管理系统的要求。 - -### GDPR -欧盟通用数据保护条例，规定个人数据处理和隐私保护要求。 - -### HIPAA -美国医疗健康信息隐私法规，保护医疗信息的机密性、完整性和可用性。 - -## Automation Tools -- Chef InSpec — 合规即代码 -- Ansible — 配置和合规自动化 -- AWS Config — 云资源合规 -- Azure Policy — Azure 合规 -- Terraform Sentinel — IaC 合规 - -## Implementation - -### Policy as Code -```ruby -# Chef InSpec 示例 -control 'cis-aws-foundations-1.1' do - impact 1.0 - title 'Ensure MFA is enabled for all IAM users' - describe aws_iam_users.where(attached_managed_policies: []) do - its('entries') { should eq [] } - end -end -``` - -### Continuous Compliance -- 实时监控配置状态 -- 自动修复违规 -- 合规报告生成 - -## Benefits -- 减少人工审计成本 -- 持续合规而非间歇性合规 -- 快速响应监管变化 -- 减少人为错误 - -## Related Concepts -- [[DevSecOps]] — 合规自动化是 DevSecOps 的重要组成 -- [[Policy-as-Code]] — 以代码管理策略 -- [[ISO-27001]] — 信息安全管理标准 -- [[HIPAA]] — 医疗健康合规 -- [[GDPR]] — 数据保护法规 -- [[Continuous-Compliance]] — 持续合规 - -## Sources -- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Compliance-Risk-Matrix.md b/wiki/concepts/Compliance-Risk-Matrix.md deleted file mode 100644 index 24052d88..00000000 --- a/wiki/concepts/Compliance-Risk-Matrix.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Compliance Risk Matrix（合规风险分级矩阵）" -type: concept -tags: [healthcare, compliance, risk-management, china] -sources: [healthcare-marketing-compliance] -last_updated: 2026-04-25 ---- - -## Definition -医疗营销合规风险分级矩阵是将医疗营销违规行为按风险严重程度分级（Critical / High / Medium / Low），并为每个等级配套相应处置措施的管理工具，帮助企业集中资源优先处理高风险违规。 - -## Risk Levels - -### Critical（严重） -| 违规类型 | 潜在后果 | 建议行动 | -|----------|----------|----------| -| 处方药面向大众媒体广告 | 罚款 + 撤销广告批准文号 + 刑事责任 | 立即停止，启动危机应对 | -| 无审查证明发布医疗广告 | 责令停止 + 罚款20-100万元 | 立即下架，启动审查程序 | -| 非法处理患者敏感个人信息 | 最高罚款5000万元或上年度营收5% | 立即补救，激活数据安全应急预案 | - -### High（高度） -| 违规类型 | 潜在后果 | 建议行动 | -|----------|----------|----------| -| 保健食品声称治病功能 | 罚款 + 产品下架 + 媒体曝光 | 48小时内修订全部推广材料 | -| 医美广告使用前后对比照片 | 罚款 + 平台账号封禁 + 行业通报 | 24小时内下架相关内容 | - -### Medium（中等） -| 违规类型 | 潜在后果 | 建议行动 | -|----------|----------|----------| -| 使用绝对化表述 | 罚款 + 警告 | 72小时内完成自查整改 | -| 健康科普内容夹带产品推广 | 平台处罚 + 内容下架 | 修订内容，标注推广性质 | - -### Low（轻微） -| 违规类型 | 潜在后果 | 建议行动 | -|----------|----------|----------| -| 缺失咨询/声明语句 | 警告 + 责令整改 | 添加必要声明语句 | -| 文献引用格式不规范 | 内部合规扣分 | 修正引用格式 | - -## Core Usage Principle -> "合规团队须根据风险分级决定审查层级——Critical 内容须合规+法务+高管三方会审。" — 三级审查与风险分级联动 - -## Related Concepts -- [[Healthcare-Marketing-Compliance]]：风险矩阵是合规管理的核心工具 -- [[Three-Tier-Review-Mechanism]]：风险分级决定审查层级 -- [[Medical-Advertisement-Review]]：Critical 违规多与广告审查制度相关 -- [[Patient-Privacy-PIPL]]：PIPL 违规属 Critical Risk diff --git a/wiki/concepts/Concierge-Services.md b/wiki/concepts/Concierge-Services.md deleted file mode 100644 index 3c68d5b2..00000000 --- a/wiki/concepts/Concierge-Services.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: "Concierge Services" -type: concept -tags: [] -sources: - - hospitality-guest-services -last_updated: 2026-05-02 ---- - -## Definition -Concierge Services（礼宾服务）是酒店及高端款待业中，为宾客提供本地知识、预订协调和个性化安排的专业服务职能。礼宾服务的核心价值在于：识别宾客未表达的需求，通过主动推荐和精准执行创造惊喜体验。 - -## Service Categories - -### Dining Reservations（餐饮预订） -- 掌握当地TOP 10餐厅分类（Fine Dining/Casual/家庭/本地人推荐/景观氛围） -- 实时了解：当前等候时间、预订可用性、饮食适配能力 -- 预订话术："请问您偏好什么菜系、价格范围和氛围？有什么特殊场合需要我们提及吗？" -- 交通选项：每家餐厅的交通方式建议 - -### Transportation（交通安排） -- 酒店班车：时刻表和覆盖范围 -- 打车/网约车：本地最佳APP -- 租车：最近门店位置和当前可用车型 -- 停车：自助vs.代客泊车，费用，营业时间 -- 机场接送：预订流程和价格 - -### Local Activities & Attractions（本地活动与景点） -保持实时更新的知识库： -- 主要景点：开放时间、票价、预订要求 -- 当前本地活动：节日、音乐会、体育赛事 -- 户外活动：徒步、公园、水上活动 -- 家庭友好选项 -- 文化体验：博物馆、剧院、画廊 -- 购物：本地精品店、商场、市场 - -### In-Property Services（酒店内服务） -- Spa：护理项目、营业时间、预订流程 -- 健身中心：开放时间、设备、课程 -- 泳池：开放时间、规则、毛巾服务 -- 商务中心：开放时间、设备、打印 -- 客房服务：开放时间、点餐流程 -- 洗衣/干洗：流程和 turnaround 时间 - -### Special Occasion Services（特殊场合服务） -- 鲜花：通过[供应商]订购，需24小时通知 -- 香槟/葡萄酒：通过客房服务供应 -- 蛋糕：通过[供应商]订购，需24小时通知 -- 浪漫夜床布置：玫瑰+蜡烛，需[时间]前申请 -- 惊喜布置：与客房部协调 - -## Key Principles -- 主动推荐，而非被动应答：识别宾客需求在开口前 -- 知识必须实时更新：餐厅关门时间、景点开放日变化 -- 饮食限制是医疗问题：每次餐饮预订必须记录 - -## Connections -- [[Hospitality Guest Services]] ← 礼宾服务是宾客服务 Agent 住店阶段的核心交付物 -- [[Guest Journey]] ← 礼宾服务贯穿住店(In-Stay)阶段 -- [[Food Allergy]] ← 礼宾服务中餐饮预订必须强制处理饮食限制 - -## Aliases -- 礼宾服务 -- Concierge -- Guest Services -- Hotel Concierge diff --git a/wiki/concepts/Confidence-Score.md b/wiki/concepts/Confidence-Score.md deleted file mode 100644 index 3f21a0ea..00000000 --- a/wiki/concepts/Confidence-Score.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Confidence Score" -type: concept -tags: ["identity-resolution", "decision-making", "threshold", "multi-agent"] -sources: ["identity-graph-operator"] -last_updated: 2026-04-25 ---- - -# Confidence Score（置信度评分） - -## Definition -身份解析决策的核心度量——综合所有字段级匹配证据，通过加权求和得出的合并置信度。是决定"自动合并 / 提案审查 / 创建新实体"三类决策的分界指标。 - -## Calculation - -``` -confidence = Σ(score_i × weight_i) / Σ(weight_i) -``` - -其中 `score_i` 是字段级 fuzzy/exact match 分数（0–1），`weight_i` 是字段可靠性权重。 - -### 示例（来自 Identity Graph Operator 源码） -| 字段 | 记录A值 | 记录B值 | Normalizer | Comparator | Score | Weight | -|------|---------|---------|-----------|------------|-------|--------| -| email | wsmith@acme.com | wsmith@acme.com | email | exact | 1.0 | 高 | -| last_name | Smith | Smith | name | exact | 1.0 | 高 | -| first_name | William | Bill | name | nickname | 0.82 | 中 | -| phone | +155****0142 | +155****0142 | phone | exact | 1.0 | 高 | - -综合置信度 = `1.0×0.3 + 1.0×0.3 + 0.82×0.2 + 1.0×0.2` ≈ **0.96** - -## Decision Thresholds - -``` -confidence > 0.95 → 自动合并（单 Agent 高置信） -0.60 ≤ confidence ≤ 0.95 → 提案审查（多 Agent 协作） -confidence < 0.60 → 创建新实体 -``` - -## Field Reliability Weights - -| 字段 | 权重 | 原因 | -|------|------|------| -| Email | 高 | 几乎唯一，变更需主动操作 | -| Phone | 高 | 需验证，变更成本高 | -| Name | 中 | 常见同名不同人，需结合其他字段 | -| Address | 低 | 常见地址变更（搬家） | - -## Why Thresholds Matter -- **防止假阳性**（False Merge）：将两个不同人（如同名"John Smith"）错误合并——高阈值 + 字段级证据防止 -- **防止假阴性**（Missed Match）：将同一人（如"Bill Smith"/"William Smith"）遗漏为不同实体——中等阈值触发提案审查而非直接拒绝 -- **可解释性**：per-field evidence 使决策可被其他 Agent 和人类审计 diff --git a/wiki/concepts/Configuration-Management.md b/wiki/concepts/Configuration-Management.md deleted file mode 100644 index 157d28ae..00000000 --- a/wiki/concepts/Configuration-Management.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: "Configuration Management" -type: concept -tags: [itsm, devops, operations] -date: 2025-03-01 ---- - -## Definition - -配置管理（Configuration Management）是[[ITSM]]的核心流程之一，负责**识别、记录、控制和追踪IT环境中的所有配置项（Configuration Items, CI）及其关系**，为变更影响分析和事件诊断提供基础数据。 - -## Configuration Item Types - -| CI类型 | 示例 | -|--------|------| -| Hardware | 服务器、网络设备、存储 | -| Software | 操作系统、应用、中间件 | -| Documentation | 架构图、流程文档 | -| People | 运维人员、服务所有者 | -| Services | 应用服务、API接口 | - -## Configuration Management Process - -``` -┌──────────────┐ ┌──────────────┐ ┌──────────────┐ -│ CI │ → │ Relationship│ → │ Impact │ -│ Discovery │ │ Mapping │ │ Analysis │ -└──────────────┘ └──────────────┘ └──────────────┘ - ↓ ↓ ↓ - Auto Scan Dependency Change Planning - + Manual Entry Graph + Incident RCA -``` - -## Modern Configuration Management (ITSM 2.0) - -在[[ITSM 2.0]]中，配置管理由AI驱动的[[CMDB]]支撑： - -### AI-Enhanced Capabilities - -| 能力 | 描述 | 价值 | -|------|------|------| -| Dependency Mapping | 自动发现服务依赖 | 变更影响分析 | -| Drift Detection | 配置漂移实时检测 | 安全合规 | -| Real-time Impact Analysis | 实时影响分析 | 快速决策 | -| Multi-cloud Orchestration | 多云配置管理 | 统一视图 | - -### [[CMDB]] in Action - -``` -Multi-cloud Environment -├── Public Cloud (AWS/Azure/GCP) -├── Private Cloud (VMware/OpenStack) -└── Hybrid Environment - ↓ - AI-CMDB - ├── 自动发现CI - ├── 关系映射 - ├── 漂移检测 - └── 影响预测 -``` - -## Related Concepts - -- [[ITSM]] — 父框架 -- [[CMDB]] — 配置管理数据库 -- [[Change-Management]] — 变更管理 -- [[Multi-Cloud]] — 多云环境 -- [[IaC]] — 基础设施即代码 - -## Sources - -- [[understanding-complete-itsm]] — AI-powered CMDB for Configuration Management diff --git a/wiki/concepts/ConnectionPooling.md b/wiki/concepts/ConnectionPooling.md deleted file mode 100644 index ac2daf84..00000000 --- a/wiki/concepts/ConnectionPooling.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Connection Pooling" -type: concept -tags: [database, connection-pool, postgresql, supabase, performance, infrastructure] -last_updated: 2026-05-01 ---- - -# Connection Pooling - -## Definition - -数据库连接池是一种在应用程序和数据库服务器之间维护一组持久连接的技术，避免每次请求都创建新连接，从而防止连接耗尽、提升响应速度。 - -## Why It Matters - -- 数据库连接是稀缺资源（PostgreSQL 默认 max_connections = 100） -- 无连接池时：高并发下连接数爆炸 → OOM → 服务崩溃 -- 无连接池时：每次请求建立 TCP + 认证开销（~20-50ms 延迟） - -## Key Tools - -| 工具 | 说明 | -|------|------| -| **PgBouncer** | 轻量级 PostgreSQL 连接池，支持事务模式和会话模式 | -| **Supabase Pooler** | Supabase 内置连接池，自动管理事务模式连接 | -| **PlanetScale** | 内置连接池，无服务器架构 | -| **PgBouncer 事务模式** | 连接归还池复用，适合 serverless | -| **PgBouncer 会话模式** | 保持长连接，适合需要 SET session.* 的场景 | - -## Supabase 连接池示例 - -```typescript -// Supabase 事务模式（Serverless 推荐） -const pooledUrl = process.env.DATABASE_URL?.replace( - '5432', // 标准端口 - '6543' // 事务模式端口 -); -``` - -## Source -- [[engineering-database-optimizer]] - -## Connections -- [[engineering-backend-architect]] — 架构设计时必须考虑连接池 -- [[engineering-sre]] — 连接池配置是 SRE 容量规划的关键 -- [[engineering-database-optimizer]] — 核心关注点之一 diff --git a/wiki/concepts/Consensus-Voting-Pattern.md b/wiki/concepts/Consensus-Voting-Pattern.md deleted file mode 100644 index 911f6952..00000000 --- a/wiki/concepts/Consensus-Voting-Pattern.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Consensus Voting Pattern" -type: concept -tags: [] -sources: - - multi-agent-system-reliability -last_updated: 2026-04-28 ---- - -# Consensus Voting Pattern - -## 定义 -多智能体系统的共识投票模式——将同一任务分配给N个LLM，选取出现次数最多的答案作为最终结果。 - -## 核心公式 -若单个模型幻觉概率为 P，则N个模型同时幻觉相同谎言的概率为 P^N。 -- 示例：P=0.2（20%幻觉率），N=3 → 0.2³ = 0.008（0.8%） - -## 核心机制 -1. **Spawn N LLMs**：N需要通过试验找到成本与可靠性的平衡点 -2. **Fan out work**：给所有Agent完全相同的任务 -3. **Fan in results**：选取最常见的答案 - -## 关键要求 -- Agent之间**无反馈回路**，否则群体思维（Groupthink）和从众效应会扭曲结果 -- 理想情况下各Agent使用不同模型，降低思维同质化风险 -- 实验应像盲测一样进行 - -## 适用场景 -- 事实核查（Fact-checking） -- 分类任务（如"这是垃圾邮件吗？"） - -## 缺点 -成本高——本质上是将同一任务分配给多个Agent，ROI需根据任务和失败成本计算。 - -## 来源 -- [[multi-agent-system-reliability]] -- [[Composite SLO]]（概率公式类比） diff --git a/wiki/concepts/Constraint-Driven-Control-Mechanics.md b/wiki/concepts/Constraint-Driven-Control-Mechanics.md deleted file mode 100644 index b4518c5a..00000000 --- a/wiki/concepts/Constraint-Driven-Control-Mechanics.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Constraint-Driven Control Mechanics" -type: concept -tags: [] -last_updated: 2026-04-25 ---- - -## Definition -约束驱动控制机制——一种 XR 交互设计范式，通过 3D meshes 和输入约束将控制物理化，消除自由漂浮运动（free-float motion），使用户的交互操作具有物理质感和确定性反馈。 - -## Core Principles -- **物理化控制**：控制装置（yoke、lever、throttle）通过 3D mesh 建模，具备真实物理属性 -- **输入约束**：通过数学约束限制用户输入，避免无物理意义的运动 -- **确定性反馈**：每次操作都有可预测的视觉/声音反馈 -- **无自由漂浮**：用户无法在虚拟空间中自由漂浮移动，所有交互通过物理装置进行 - -## Use Cases -- XR 座舱交互（[[XR-Cockpit-Interaction-Specialist]]） -- 训练模拟器 -- 航天器/载具模拟界面 -- 手术模拟器 -- 工业操作训练 - -## Related Concepts -- [[Cockpit-Ergonomics]]：座舱人体工学——约束驱动机制的人体工学基础 -- [[Motion-Sickness-Threshold]]：运动病阈值——约束驱动设计的重要优化目标 -- [[Spatial-Computing]]：空间计算——约束驱动交互发生的空间技术基础 - -## Sources -- [[xr-cockpit-interaction-specialist]] diff --git a/wiki/concepts/Container-Image-Tagging.md b/wiki/concepts/Container-Image-Tagging.md deleted file mode 100644 index a6e59481..00000000 --- a/wiki/concepts/Container-Image-Tagging.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: "Container Image Tagging" -type: concept -tags: - - Container - - Tagging-Standard - - Cloud-Governance - - OpenText - - OCI -sources: - - public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meeting-rec -last_updated: 2026-04-29 ---- - -# Container Image Tagging - -容器镜像标签标准是 OpenText 云标签标准 V2 版本的新增组成部分，为容器镜像定义了标准化的标签规范，涵盖产品元数据、来源追踪和基础镜像管理。与 Kubernetes 标签类似，容器镜像标签使用 `com.opentext.image/` 前缀，与 OCI（Open Container Initiative）标准标签和云资源标签共同构成完整标签体系。 - -## Definition - -容器镜像标签（Image Tags）是嵌入在容器镜像元数据（Image Manifest）中的键值对，通过 OCI Image Specification 定义。OpenText V2 标准要求所有内部构建的容器镜像必须包含 `com.opentext.image/` 前缀的标准标签，以实现镜像来源追踪、产品归属和安全合规审计。 - -## OpenText V2 标准标签 - -### 核心标签键 - -| 标签键 | 说明 | 示例值 | -|--------|------|--------| -| `com.opentext.image/product` | 产品名称 | `idm`, `operations` | -| `com.opentext.image/title` | 镜像标题 | `IDM Core Service` | -| `com.opentext.image/description` | 镜像描述 | `Core identity management service` | -| `com.opentext.image/vendor` | 供应商 | `OpenText` | -| `com.opentext.image/base-image` | 基础镜像名称 | `ubuntu:22.04` | -| `com.opentext.image/base-image-version` | 基础镜像版本 | `22.04` | - -### 标签前缀规范 - -- **OpenText 标准标签**：`com.opentext.image/` -- **OCI 推荐标签**：`org.opencontainers.image/`（与 OCI 标准对齐） -- **上游标签**：保持原始上游镜像的标签不变 - -## 标签层级结构 - -``` -com.opentext.image/ -├── product # 产品维度（必填） -├── title # 人类可读标题（必填） -├── description # 功能描述（必填） -├── vendor # 供应商（必填） -├── base-image # 基础镜像（必填） -└── base-image-version # 基础镜像版本（必填） -``` - -## 最佳实践 - -- **标签即文档**：镜像标签应作为镜像的自我描述文档，无需额外文档即可了解镜像用途 -- **不可变性**：标签一旦发布，不应修改已构建镜像的标签；更新内容应通过新版本标签发布 -- **CI/CD 自动化**：在构建流水线中通过标签注入步骤自动添加标准标签 -- **基础镜像追踪**：所有自定义镜像必须标注基础镜像来源和版本，便于安全漏洞修复 -- **扫描集成**：容器镜像扫描工具（如 Trivy）应读取标准标签以生成合规报告 - -## 与其他标签体系的关系 - -| 标签范围 | 前缀 | 覆盖对象 | -|----------|------|----------| -| 云资源标签 | `OT_` | EC2、S3、VPC 等云资源 | -| K8s 标签 | `app.opentext.com/` | Namespace、Pod、Deployment 等 K8s 对象 | -| 容器镜像标签 | `com.opentext.image/` | 容器镜像（Docker/OCI 镜像） | - -## Connections -- [[Resource-Tagging]] — 容器镜像是资源的一种 -- [[Kubernetes-Tagging]] — K8s 标签与容器镜像标签协同工作 -- [[AWS-Tagging-Standards]] — 云标签标准的容器镜像扩展 -- [[public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meeting-rec]] diff --git a/wiki/concepts/Container-Insights.md b/wiki/concepts/Container-Insights.md deleted file mode 100644 index bf20d5d2..00000000 --- a/wiki/concepts/Container-Insights.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Container Insights" -type: concept -tags: [AWS, EKS, monitoring, metrics, CloudWatch, containers] -last_updated: 2026-04-28 ---- - -## Definition - -Container Insights 是 Amazon CloudWatch 的容器监控功能，专门用于收集、整理和汇总 EKS 和 ECS 集群中容器化工作负载的指标和日志。它通过 CloudWatch Agent（DaemonSet）和 CloudWatch Embedded Metric Format 自动收集容器级指标，使运维团队无需额外配置即可获得集群运行状况的可见性。 - -## Key Mechanisms - -- **自动指标收集**：容器 CPU/内存/网络/磁盘使用率，Pod 级别聚合 -- **日志收集**：容器标准输出日志自动采集至 CloudWatch Logs -- **预构建仪表板**：提供集群、节点、Pod、服务级别的可视化仪表板 -- **性能告警**：自动发现高负载资源并生成 CloudWatch 告警 -- **Embedded Metric Format**：应用可直接输出结构化指标，无需额外 SDK - -## Relationship with CloudWatch Agent - -Container Insights 建立在 CloudWatch Agent 之上： -- CloudWatch Agent（DaemonSet）是数据采集代理 -- Container Insights 是指标组织和聚合逻辑（通过 CloudWatch Agent 配置实现） -- 用户启用 Container Insights 后，CloudWatch Agent 自动开始发布容器指标 - -## Sources -- [[ctp-topic-70-eks-deployment-using-iac]] -- [[ctp-topic-42-grafana-observability-dashboard]] diff --git a/wiki/concepts/Container-Lifecycle-Hardening.md b/wiki/concepts/Container-Lifecycle-Hardening.md deleted file mode 100644 index 6c46b429..00000000 --- a/wiki/concepts/Container-Lifecycle-Hardening.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Container Lifecycle Hardening" -type: concept -tags: [Container, Security, Kubernetes, DevSecOps, Hardening] -last_updated: 2026-04-24 ---- - -## Definition -容器生命周期安全加固（Container Lifecycle Hardening）是指在容器的构建（Build）、部署（Deploy）、运行（Run）三个阶段中系统性地应用安全控制措施，以减少容器化工作负载的攻击面。 - -## Three Phases - -### Build Phase（构建阶段） -在构建阶段确保镜像本身不含漏洞和敏感信息： -- 使用经过安全加固的[[Micro Focus]]基础镜像 -- 引入 Init 系统（[[tini]]）防止僵尸进程 -- 镜像不含敏感信息（密码、API Key） -- 启用镜像漏洞扫描 -- 每个容器仅运行单一应用 - -### Deploy Phase（部署阶段） -在部署到 Kubernetes 时应用安全配置： -- 使用只读根文件系统（readOnlyRootFilesystem: true） -- 使用 [[emptyDir Volume]] 存储临时文件 -- 禁用 Kubernetes API 自动挂载（automountServiceAccountToken: false） -- 使用私有服务账号配合精确 RBAC -- 避免 hostNetwork 和 hostPort - -### Run Phase（运行时阶段） -运行时持续监控和加固（CTP Topic 49 视频中提到将另有专题覆盖）。 - -## Key Standards (Build Phase) -来自 [[ctp-topic-49-container-lifecycle-hardening-standards]] 的 11 条标准： - -1. **Micro Focus Base Image** — 使用经过安全配置的官方基础镜像 -2. **Init System** — 使用 [[tini]] 处理信号和防止僵尸进程 -3. **No Sensitive Info** — 镜像不含敏感数据，使用 [[Kubernetes Secrets]] 运行时注入 -4. **Read-Only Root FS** — 设置 readOnlyRootFilesystem: true -5. **emptyDir for /tmp** — 使用 emptyDir volume 替代 hostPath -6. **Image Scanning** — 启用容器镜像漏洞扫描 -7. **Single Application** — 每容器运行单一应用 -8. **No K8s API Access** — 禁用 automountServiceAccountToken -9. **Private Service Account** — 使用最小权限的服务账号 -10. **No Host Network** — 避免 hostNetwork 配置 -11. **No Host Port** — 避免 hostPort 配置 - -## Relationship to DevSecOps -容器生命周期安全加固是 [[DevSecOps]] 理念在容器领域的具体实践： -- **安全左移（Shift-Left）**：安全问题在构建阶段就被发现和修复 -- **自动化**：通过 IaC 和 CI/CD 流水线自动执行安全检查 -- **最小权限**：容器仅获得完成功能所需的最小权限 - -## Relationship to Supply Chain Security -容器镜像加固是[[Supply Chain Security（供应链安全）]]体系的重要组成部分： -- 供应链安全的构建阶段（CI）= 容器镜像加固 -- 构建安全镜像 → 防止攻击者在制品中注入恶意代码 - -## Sources -- [[ctp-topic-49-container-lifecycle-hardening-standards]] -- [[ctp-topic-21-supply-chain-security-in-micro-focus]] diff --git a/wiki/concepts/Content Automation.md b/wiki/concepts/Content Automation.md deleted file mode 100644 index b5ccba53..00000000 --- a/wiki/concepts/Content Automation.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Content Automation" -type: concept -tags: [content-creation, automation, multi-agent] -sources: [content-factory, podcast-production-pipeline] -last_updated: 2026-04-22 ---- - -## Definition - -Content Automation（内容自动化）是指利用 AI Agent 流水线实现内容创作全流程（选题研究→内容撰写→视觉设计→分发）的自动化执行，创作者无需逐步人工干预，次日即可收获成品内容。 - -## Core Phases - -1. **Research**：扫描趋势话题、竞品内容、社交媒体数据，识别最佳内容机会 -2. **Writing**：将研究结果转化为脚本、推文串、Newsletter 草稿或博客文章 -3. **Design**：生成缩略图、封面图、社交媒体配图等视觉资产 -4. **Distribution**（可选）：自动发布到各平台并收集反馈 - -## Key Technologies - -- **多 Agent 编排**：`sessions_spawn` / `sessions_send` 实现多 Agent 调度 -- **定时调度**：每日 8 AM 自动运行，创作者次日醒来即收获成品 -- **本地图像生成**：如 Nano Banana，降低 API 调用成本 -- **平台集成**：Discord 频道隔离各 Agent 输出，便于审查和反馈 - -## Use Cases - -- [[Content Factory]]：Discord 频道多 Agent 内容工厂 -- [[Podcast Production Pipeline]]：AI 全自动播客制作流水线 -- [[daily-youtube-digest]]：YouTube 频道订阅内容自动摘要 - -## Related Concepts - -- [[Chained Agents]]：内容自动化的核心技术实现 -- [[Multi-Agent Coordination]]：多 Agent 系统协调机制 -- [[Workflow Architecture]]：工作流架构设计 diff --git a/wiki/concepts/Content-60-30-10-Rule.md b/wiki/concepts/Content-60-30-10-Rule.md deleted file mode 100644 index 42985b22..00000000 --- a/wiki/concepts/Content-60-30-10-Rule.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Content 60/30/10 Rule" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-26 ---- - -## Aliases -- 内容比例法则 -- 60/30/10 内容规则 -- 60/30/10 Rule - -## Definition - -微信公众号内容分配比例框架：60% 价值内容 + 30% 社群/互动内容 + 10% 推广内容。确保订阅者持续感受到价值，而非被单纯推销，从而维持高打开率和高忠诚度。 - -## Breakdown - -| 类型 | 占比 | 说明 | 示例 | -|------|------|------|------| -| 价值内容 | 60% | 教育、娱乐、信息型内容 | 行业洞察、操作教程、实用技巧 | -| 社群/互动内容 | 30% | 提问、投票、UGC、话题讨论 | 问答互动、投票征集、用户故事 | -| 推广内容 | 10% | 产品/服务/活动推广 | 新品发布、促销信息 | - -## Purpose - -- 防止订阅者「信息疲劳」——持续提供价值而非单向推销 -- 提升打开率和互动率——订阅者期待有价值内容主动打开 -- 建立信任和品牌权威——教育内容展示专业度 -- 推动自然转化——在信任建立后软性植入推广 - -## Application - -适用场景：大多数企业公众号每周 2-3 次推送，每次可混合三种类型内容 - -## Sources - -- [[marketing-wechat-official-account]] - -## Connections - -- Related to: [[Content-Pillar-Strategy]]（内容支柱策略——定义4-5个核心内容主题） -- Related to: [[Editorial-Calendar]]（编辑日历——规划内容比例和发布时间） diff --git a/wiki/concepts/Content-Aggregation.md b/wiki/concepts/Content-Aggregation.md deleted file mode 100644 index 4eede608..00000000 --- a/wiki/concepts/Content-Aggregation.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Content-Aggregation" -type: concept -tags: [RSS, Data-Pipeline, Information-Retrieval] -sources: [multi-source-tech-news-digest.md] -last_updated: 2026-04-27 ---- - -# Content-Aggregation - -内容聚合——将来自多个异构来源的信息统一收集、去重、标准化后呈现的机制，是解决信息碎片化问题的核心手段。 - -## Definition - -从多个来源（RSS、社交媒体、API、Web 抓取等）收集内容，通过合并、去重、排序等处理，最终生成统一的结构化输出。 - -## Key Characteristics - -- **多来源合并**：支持不同协议和格式（RSS/Atom、JSON API、HTML 爬取等） -- **标准化**：统一内容格式（标题、摘要、URL、时间戳、来源标签） -- **时序整合**：按时间线重新排序跨来源的内容 -- **质量分层**：按来源权威性、用户偏好等对内容分级 - -## Related Concepts - -- [[Content-Deduplication]]：内容聚合的前置步骤 -- [[Quality-Scoring]]：内容聚合的后置筛选 -- [[RSSHub]]：生成标准化 RSS 的工具，使不原生支持 RSS 的来源可被聚合 diff --git a/wiki/concepts/Content-Creator.md b/wiki/concepts/Content-Creator.md deleted file mode 100644 index 67a96442..00000000 --- a/wiki/concepts/Content-Creator.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Content Creator" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-25 ---- - -## Definition - -内容创作者（重新定义）——在 [[Generalist]]（通才型）语境下，内容创作不是追求流量，而是将社交媒体作为"公开做笔记"的机制，传播毕生工作的载体。参考 [[Jordan Peterson]] 的案例：他不是"内容创作者"，而是利用一切工具（巡回演讲/著书/社交媒体）传播毕生工作的人。 - -## Key Redefinition - -> "不要成为 YouTube 创作者。不要打造个人品牌。不要当网红。做你自己。但要在一个能让你的作品被发现、关注和支持的地方。" - -## Core Properties - -- 社交媒体作为"公开做笔记"机制 -- 内容是 [[Idea-Density]]（高密度创意）的策展和表达 -- 品牌是 [[Brand-Environment]]——读者关注 3-6 个月后积累的整体印象 -- 产品是 [[System-Economy]]——个人实践形成的独特系统 - -## The Three-Step Content Method - -1. **建立 [[Idea-Museum]]**（创意博物馆）：3-5 个高密度信息源 -2. **基于 [[Idea-Density]] 筛选**：表现力 × 兴奋度 -3. **同一想法 1000 种表达**：用不同结构重写同一想法 - -## The [[Attention-Economy]] Role - -在注意力经济中，内容是捕获注意力的核心机制。高质量 [[Idea-Density]] 的内容能够： -- 吸引精准受众 -- 建立信任和影响力 -- 为产品和系统经济提供分发渠道 - -## Jordan Peterson as Reference - -Jordan Peterson 的案例被引用来说明：真正的创作者不是"内容创作者"，而是利用一切工具（巡回演讲/著书/社交媒体）传播毕生工作的思想家。他的思维质量才是差异化所在，而非内容格式本身。 - -## Related Concepts - -- [[Idea-Density]] — 内容创作的核心质量指标 -- [[Idea-Museum]] — 内容创作的素材基础 -- [[Brand-Environment]] — 内容构建品牌 -- [[System-Economy]] — 内容分发系统 -- [[Attention-Economy]] — 内容捕获注意力 -- [[Generalist]] — 内容创作者的自然类型 - -## Sources - -- [[if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间]] diff --git a/wiki/concepts/Content-Deduplication.md b/wiki/concepts/Content-Deduplication.md deleted file mode 100644 index c7aa2ef4..00000000 --- a/wiki/concepts/Content-Deduplication.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Content-Deduplication" -type: concept -tags: [Data-Processing, NLP, Similarity-Matching] -sources: [multi-source-tech-news-digest.md] -last_updated: 2026-04-27 ---- - -# Content-Deduplication - -内容去重——识别并合并重复或近似内容的技术，解决同一内容从多个渠道涌入造成的冗余问题。 - -## Definition - -通过计算标题/摘要的相似度（如 Jaccard 相似度、余弦相似度、编辑距离），判断两条内容是否指向同一信息，并将重复项合并。 - -## Approaches - -- **精确匹配**：基于 URL、唯一 ID 去重（适用于同一平台内的内容） -- **模糊匹配**：基于标题/摘要的语义或字符串相似度去重（适用于跨平台聚合） -- **聚类去重**：将相似内容聚类，每类只保留一条代表 - -## Related Concepts - -- [[Content-Aggregation]]：去重是内容聚合流程中的关键步骤 -- [[Quality-Scoring]]：去重后对每类的代表内容进行评分 -- [[Semantic-Search]]：语义相似度技术同样可用于去重 diff --git a/wiki/concepts/Content-Hashing.md b/wiki/concepts/Content-Hashing.md deleted file mode 100644 index 4e422c6c..00000000 --- a/wiki/concepts/Content-Hashing.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Content Hashing (Incremental Indexing)" -type: concept -tags: [indexing, optimization, hash, incremental] -sources: [semantic-memory-search] -last_updated: 2026-04-22 ---- - -## Aliases -- Content Hashing -- 增量索引 -- Incremental Indexing -- 内容哈希 - -## Definition - -内容哈希是一种通过计算文档内容块的 SHA-256 哈希值来唯一标识内容的技术。当文档内容未变化时，哈希值保持不变，系统据此跳过已索引内容，仅处理新增或变更的内容块，从而实现增量索引，避免重复 Embedding API 调用。 - -## How It Works - -``` -文档内容块 → SHA-256 哈希 → 内容指纹 - ↓ -内容指纹 vs 已索引指纹 → 比对结果： - - 完全匹配 → 跳过（已存在，无需重新嵌入） - - 变化/新增 → 执行 Embedding 并存储向量 -``` - -## Why SHA-256? - -- **确定性**：相同内容总是产生相同哈希，无误判 -- **抗碰撞**：SHA-256 的 256 位空间使碰撞概率可忽略不计 -- **快速**：哈希计算比 Embedding 快数个数量级，适合高频增量检查 - -## Key Insight - -> "Smart dedup saves money. Each chunk is identified by a SHA-256 content hash. Re-running `index` only embeds new or changed content, so you can run it as often as you like without wasting embedding API calls." — memsearch - -## Benefits - -| 收益 | 说明 | -|------|------| -| **成本节省** | 避免重复 Embedding API 调用，节省 token 和费用 | -| **速度提升** | 仅处理增量变化，索引重建时间大幅缩短 | -| **幂等性** | 任意次数重新索引，结果一致 | -| **原子性** | 内容块级别独立，无整体重写的开销 | - -## Connections -- [[semantic-memory-search]] — memsearch 使用 SHA-256 内容哈希实现增量索引 -- [[memsearch]] — 内容哈希是 memsearch 增量索引的核心机制 diff --git a/wiki/concepts/Content-Ingestion.md b/wiki/concepts/Content-Ingestion.md deleted file mode 100644 index f7f8ed6f..00000000 --- a/wiki/concepts/Content-Ingestion.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Content Ingestion" -type: concept -last_updated: 2026-04-22 ---- - -## Definition - -内容摄取（Content Ingestion）：将外部内容（网页、PDF、YouTube 字幕、推文等）通过自动化解析提取为结构化文本，并分块（Chunking）入库供检索系统使用的过程。是 [[Knowledge-Base-RAG]] 工作流的第一步——没有高质量的内容摄取，就没有可搜索的知识库。 - -## Ingestion Pipeline - -``` -URL 输入 → 内容获取 → 格式解析 → 文本清洗 → 分块（Chunking）→ Embedding → 向量入库 -``` - -## Supported Content Types - -| 类型 | 解析方式 | 挑战 | -|------|----------|------| -| 网页 | HTML 解析 / Firecrawl / Jina Reader | 广告/导航移除、JS 渲染内容 | -| PDF | marker / pdfminer / PyMuPDF | 表格、多栏布局、扫描件 OCR | -| YouTube | Transcript API / Whisper | 自动字幕质量、噪音处理 | -| 推文/Tweet | Twitter API / 第三方抓取 | 字符限制、线程重组 | -| Slack 消息 | Slack API | 富文本格式、附件分离 | - -## Chunking Strategies - -详见 [[Knowledge-Base-RAG]] 概念页。 - -## Why It Matters - -Garbage in, garbage out——即使 Embedding 模型再强大，如果摄取内容充满噪音（广告、HTML 标签、格式乱码），检索质量也会大幅下降。好的摄取 pipeline 需要： -1. 内容纯净（去广告/去导航/去脚注） -2. 格式保留（标题层级、列表结构有助于理解） -3. 元数据保留（URL、标题、日期、来源类型） - -## Connections - -- [[Knowledge-Base-RAG]] — Content Ingestion 是 RAG 工作流的第一个环节 -- [[Semantic-Search]] — 摄入的内容最终通过语义搜索被检索 -- [[web_fetch]] — 内容获取的工具技能 diff --git a/wiki/concepts/Content-Matrix-Strategy.md b/wiki/concepts/Content-Matrix-Strategy.md deleted file mode 100644 index 8e67dac2..00000000 --- a/wiki/concepts/Content-Matrix-Strategy.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Content Matrix Strategy（内容矩阵策略）" -type: concept -tags: [content-marketing, short-video, multi-platform] -sources: [marketing-douyin-strategist] -last_updated: 2026-04-25 ---- - -## Definition -内容矩阵策略是通过在单一平台或跨平台布局多种内容类型的账号组合，实现流量来源多元化、用户触点覆盖最大化的内容运营方法论。 - -## Core Framework -在抖音平台，典型内容矩阵包含四类内容： - -| 类型 | 目的 | 典型时长 | 完播率目标 | -|------|------|----------|------------| -| 教育类 | 建立专业权威 | 30-60s | > 40% | -| 剧情类 | 情感共鸣 | 15-30s | > 35% | -| 产品测评类 | 种草转化 | 30-45s | > 38% | -| Vlog类 | 人设打造 | 60-120s | > 30% | - -## Key Principles -- **主账号**负责品牌定位和高价值内容 -- **子账号**承担垂类渗透和长尾流量 -- **员工账号**提供真实背书和日常互动 -- 内容类型之间互相引流，形成闭环 - -## Applications -- 抖音/快手短视频矩阵 -- 微信公众号/视频号矩阵 -- 小红书多品类账号矩阵 -- TikTok 海外市场矩阵 - -## Related Concepts -- [[MarketingDouyinStrategist]]：抖音平台内容矩阵的具体执行 Agent -- [[CompletionRateOptimization]]：内容矩阵中每条视频的优化目标 - -## Aliases -- 内容矩阵 -- Content Matrix -- Multi-format Content Strategy diff --git a/wiki/concepts/Content-Operations.md b/wiki/concepts/Content-Operations.md deleted file mode 100644 index b0a1e9ee..00000000 --- a/wiki/concepts/Content-Operations.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "内容运营体系（Content Operations for Proposals）" -type: concept -tags: [sales, content, operations] -sources: [sales-proposal-strategist] -last_updated: 2026-04-29 ---- - -## Definition - -内容运营体系（Content Operations）是提案内容资产的管理方法论，核心变革是：**按赢主题（而非按提案章节）组织可复用内容库**，从而加速未来提案撰写并保持叙事一致性。 - -## 核心原则 - -1. **按主题组织**：每个内容块归属于一个或多个赢主题，而非某个提案章节 -2. **主题覆盖率追踪**：每个提案章节必须有 ≥1 个赢主题覆盖 -3. **证据密度要求**：每个内容块必须有可引用证据（指标/案例/方法论细节） - -## 收益 - -| 传统方式 | 内容运营方式 | -|----------|--------------| -| 每份提案从零写 | 调用主题库中已有内容 | -| 主题在不同章节中自相矛盾 | 主题由中心库驱动，一致性强 | -| 模板化内容难以消除 | 内容按主题标记，可识别并替换通用内容 | -| 经验随人员流失 | 知识沉淀在主题库中 | - -## 模板检测与消除 - -识别模板化内容的信号： -- 将买家名称替换后内容完全不变 -- "Robust," "cutting-edge," "best-in-class," "world-class" 等空洞形容词 -- 任何可以直接卖给竞争对手的内容 - -## 与赢主题的关系 - -内容运营体系是赢主题的后勤保障： -- 赢主题定义"说什么" -- 内容运营定义"如何组织、存储和复用" - -## Related Concepts - -- [[Win Theme]]：内容运营体系的核心组织轴 -- [[三幕式提案叙事]]：内容在叙事中的布局框架 - -## Sources - -- [[sales-proposal-strategist]] diff --git a/wiki/concepts/Content-Pillar.md b/wiki/concepts/Content-Pillar.md deleted file mode 100644 index 874106f6..00000000 --- a/wiki/concepts/Content-Pillar.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "Content Pillar（内容支柱）" -type: concept -tags: [marketing, content, strategy, seo] -sources: [marketing-zhihu-strategist] -last_updated: 2026-04-21 ---- - -## Definition -内容支柱（Content Pillar）——围绕核心主题建立的系统性内容系列，通过持续、一致的高质量输出，在特定领域建立权威并吸引目标受众订阅。内容支柱是将碎片化回答升级为系统性思想领导力的关键策略。 - -## Content Pillar on Zhihu -知乎专栏（Zhihu Column）是内容支柱的原生载体： -- **专栏定位**：选择品牌最有深度积累的核心话题方向 -- **内容系列**：围绕专栏主题持续输出，每篇文章相互引用、层层递进 -- **订阅者积累**：专栏订阅者是高度认可的精准受众 -- **出版节奏**：每周 1-2 篇的稳定节奏维持订阅者参与度 - -## Pillar Content Structure -``` -支柱主题（例如："B2B SaaS 增长策略"） -├── 基础概念（什么是、AAM、核心指标） -├── 方法论深度（战略框架、工具对比、实施步骤） -├── 案例研究（成功案例、失败复盘、行业应用） -├── 前沿趋势（新兴方法、技术影响、未来预测） -└── 工具资源（模板、清单、工具推荐） -``` - -## 6-Month Content Plan Template -| 月份 | 主题方向 | 文章数量 | 核心目标 | -|------|---------|---------|---------| -| Month 1 | 基础框架 + 问题选择 | 4 篇 | 建立订阅者基础 | -| Month 2 | 方法论深度 | 4 篇 | 提升权威感知 | -| Month 3 | 案例研究 | 4 篇 | 增强实用性 | -| Month 4 | 高级策略 | 4 篇 | 差异化竞争 | -| Month 5 | 行业专题 | 4 篇 | 深化专业壁垒 | -| Month 6 | 复盘总结 | 4 篇 | 沉淀精华内容 | - -## Success Metrics -- 专栏订阅者增长：每月 500-2,000 新订阅者 -- 文章平均点赞：50+ 点赞 -- 订阅者参与率：20%+ 评论或收藏 -- 专栏来源线索转化：3-5% 的专栏流量转化为 CRM 线索 - -## Connections -- [[Thought-Leadership]] ← 通过 ← Content Pillar（内容支柱是思想领导力的系统性载体） -- [[Strategic-Question-Answer]] ← 产出 ← Content Pillar（专栏主题来源于高频高价值问题） diff --git a/wiki/concepts/ContentMixStrategy.md b/wiki/concepts/ContentMixStrategy.md deleted file mode 100644 index ff3d0c88..00000000 --- a/wiki/concepts/ContentMixStrategy.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Content Mix Strategy" -type: concept -tags: [content-strategy, social-media, marketing] -sources: [] -last_updated: 2026-04-26 ---- - -## Overview -内容配比策略（Content Mix Strategy）是一种社交媒体和内容营销的动态平衡框架，通过设定不同类型内容的比例分配，在品牌传播和用户吸引力之间取得最优平衡。 - -## Definition -内容配比策略核心公式：**70% 有机生活内容 + 20% 趋势参与 + 10% 品牌直接推广** - -- **有机生活内容（70%）**：与品牌相关的非商业化生活方式内容，建立情感连接和信任 -- **趋势参与（20%）**：参与平台热门话题、挑战和季节性内容，保持内容新鲜感和平台活跃度 -- **品牌直接推广（10%）**：明确的品牌/产品推广内容，用于商业转化 - -## Rationale -- 维持高有机内容比例避免用户疲劳和"广告感" -- 适度趋势参与提升算法权重和平台曝光 -- 少量直接推广确保商业目标达成 - -## Application Platforms -- [[MarketingXiaohongshuSpecialist]] — 小红书品牌营销的核心内容策略 -- 可适配 [[MarketingTikTokStrategist]]、 [[MarketingInstagramCurator]] 等其他社交平台 -- 比例可根据平台特性和品牌调性调整 - -## Related Concepts -- [[TrendRiding]] — 趋势驾驭（20% 趋势参与内容的方法论） -- [[LifestyleBrandPositioning]] — 生活方式品牌定位（70% 有机内容的方向指引） -- [[CommunityFirstEngagement]] — 社区优先互动（有机内容的执行策略） diff --git a/wiki/concepts/ContentModel-first.md b/wiki/concepts/ContentModel-first.md deleted file mode 100644 index 11e8746e..00000000 --- a/wiki/concepts/ContentModel-first.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "ContentModel-first" -type: concept -tags: [cms, development, methodology] -last_updated: 2026-05-01 ---- - -## Definition - -ContentModel-first is a CMS development principle that mandates: **before writing any theme or template code, the fields, content types, and editorial workflow must be fully defined and locked**. This applies to both WordPress and Drupal development. - -## Core Principle - -> "Content model first. Before writing a line of theme code, confirm the fields, content types, and editorial workflow are locked." - -## Application - -### WordPress -- Define custom post types, taxonomies, and ACF field groups before building templates -- Lock down field names, types, validation rules -- Plan display variants (teaser, full, card, hero) - -### Drupal -- Define content types, paragraph types, vocabulary terms, and entity references first -- Use Paragraphs or Layout Builder for flexible editorial content -- Export all configuration to YAML before writing custom modules - -## Why It Matters - -- **Prevents rework**: Template code rarely needs to change when the data model is stable -- **Reduces editor confusion**: When fields are well-named and organized, editorial UX improves -- **Enables parallel work**: Front-end developers and content strategists can work simultaneously once the model is agreed -- **Improves maintainability**: Adding a new field is a data modeling decision, not a template hotfix - -## Anti-patterns - -- ❌ Building templates for undefined fields -- ❌ Creating post types through the admin UI without documenting the schema -- ❌ Changing field names after templates reference them - -## Related Concepts - -- [[CodeOverConfiguration]] — the companion principle: register everything in code -- [[LayoutBuilder]] — Drupal's tool for implementing flexible content models -- [[GutenbergBlockEditor]] — WordPress's tool for flexible content editing - -## Sources -- [[engineering-cms-developer]] diff --git a/wiki/concepts/Context-Anxiety.md b/wiki/concepts/Context-Anxiety.md deleted file mode 100644 index 52676692..00000000 --- a/wiki/concepts/Context-Anxiety.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "Context Anxiety" -type: concept -tags: - - "agentic-ai" - - "context-window" - - "failure-mode" -sources: - - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog" -last_updated: 2026-04-20 ---- - -## Overview -Context Anxiety——当 LLM 的 context window 使用率超过约 70% 容量，或延迟升高时，模型表现出"仓促"行为的现象：跳过步骤、过早完成任务或过早宣告成功。 - -## Mechanism -- Context window 是模型的唯一记忆空间 -- 当感知到"墙壁在逼近"（token 限制），模型开始优先"快速完成"而非"正确完成" -- 这不是模型能力问题，而是 context 容量压力的系统性反应 - -## Detection -- 监控 `tokens_used / max_context > 0.7` 阈值（需按模型和工作负载调优） -- 延迟 spikes 也是触发信号 - -## Solution: Context Reset -当 Context Anxiety 触发时，Harness 执行程序化 Context Reset： -1. `save_state_to_disk(state)` — 完整项目状态写入持久存储 -2. `terminate_current_instance()` — 终止当前 LLM 实例 -3. `launch_fresh_agent(state)` — 启动全新 Agent，从保存状态恢复 - -关键代码： -```python -if (tokens_used / max_context) > 0.7: - save_state_to_disk(state) - terminate_current_instance() - launch_fresh_agent(state) -``` - -## Note on In-Place Summarization -原地摘要（in-place summarization）不够——它仍然让模型在杂乱、退化的 context 上操作。Context Reset 给予模型干净的处理空间。 - -## Source -- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]] - -## See Also -- [[Context-Reset]] — 具体实现机制 -- [[7-Layer-Harness-Stack]] — 第 5 层 Memory & State 和第 7 层 Constraints & Recovery 中处理此问题 diff --git a/wiki/concepts/Context-Cores.md b/wiki/concepts/Context-Cores.md deleted file mode 100644 index 4e757207..00000000 --- a/wiki/concepts/Context-Cores.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Context-Cores" -type: concept -tags: [AI-Memory, Context-Substrate, Version-Control, Portable-Context, Software-Engineering] -sources: [ai-memory-tools-two-camps] -last_updated: 2026-04-15 ---- - -## Definition -由 [[TrustGraph]] 引入的概念——便携、带版本的上下文容器，包含领域 schema、知识图谱、向量嵌入、证据来源和检索策略。将上下文视为代码工程制品。 - -## Core Components -一个 Context Core 包含： -- **领域 Schema**：定义上下文中有什么类型的实体和关系 -- **知识图谱**：实体和关系的结构化表示 -- **向量嵌入**：语义检索支持 -- **证据来源**：每条上下文可追溯到原始来源 -- **检索策略**：如何查询和组合上下文 - -## Version Control Semantics -Context Cores 的核心类比是**将上下文视为代码**： -- **版本化（versioning）**：追踪上下文的演变历史 -- **测试（testing）**：验证上下文质量 -- **推动（promoting）**：将上下文从开发环境推入生产 -- **回滚（rolling back）**：恢复到之前状态 - -## Operational Value - -### Agent 交接 -将 Context Core 交给新 Agent → 继承完整运营上下文 -``` -New Agent + Context Core → Full operational context -``` - -### 实验分叉 -分叉一个 Context Core 做实验 → 合并回主分支 -``` -Main Context Core → Experiment Branch → Merge Back -``` - -## Conceptual Significance -TrustGraph 的 Context Cores 是整个 AI 记忆工具领域最接近**可部署的上下文单元**的概念。每个 Camp 1 工具将记忆视为对话的副作用。TrustGraph 将上下文视为有身份、版本和生命周期的第一等制品。 - -## Implementation Note -TrustGraph 的实际实现较重（Cassandra + Qdrant），但概念模型是正确的方向——Context Core 的设计允许： -- 团队成员间共享上下文 -- 在不同 Agent 间迁移 -- 对上下文变更进行 code review - -## Connections -- [[TrustGraph]] ← 引入 ← Context-Cores 由 TrustGraph 引入 -- [[ai-memory-tools-two-camps]] ← 来源 ← Context-Cores 是 @witcheer 识别的最接近"可部署上下文单元"的概念 diff --git a/wiki/concepts/Context-Engineering.md b/wiki/concepts/Context-Engineering.md deleted file mode 100644 index 494b1767..00000000 --- a/wiki/concepts/Context-Engineering.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Context-Engineering" -type: concept -tags: [AI-Memory, Context-Substrate, Market-Trend, Paradigm-Shift] -sources: [ai-memory-tools-two-camps] -last_updated: 2026-04-15 ---- - -## Definition -由 [[Zep]] 公司引入的术语，代表 AI 记忆工具领域从"Memory"向 [[Context-Substrate]] 方向的范式转移。是该领域最重要的市场信号。 - -## Origin -Zep 是一家获得融资的 AI 记忆工具公司（4.4k stars）。在审视了领域走向后，他们决定放弃"Memory"这个词，将整个品牌重新定位为"Context Engineering"。这一行为比任何技术文档都更能说明领域正在发生什么。 - -## Why the Rebrand Matters -- Zep 有资金、有市场验证，不需要追热点 -- 他们的技术团队理解了 Camp 1 和 Camp 2 的区别 -- 他们选择了 Camp 2 的语言（"context"而非"memory"） -- 这意味着 Context Substrate 不是学术概念，而是被市场验证的方向 - -## Author Prediction -@witcheer 预测：**6 个月内，"Context Engineering"将取代"Memory"成为描述成熟 Agent 基础设施的标准术语**。 - -背后的逻辑： -- 持续运行 Agent 的需求在增长 -- 这类 Agent 需要的不只是"记住"，而是"在不断丰富的上下文中工作" -- 旧的"Memory"术语无法捕捉这种复杂性 -- "Context Engineering"更准确地描述了问题的本质 - -## Key Distinction -- **Memory**：暗示一个独立于 Agent 的存储系统 -- **Context Engineering**：强调上下文的设计、构建和维护工程 - -## Connections -- [[Context-Substrate]] ← 包含 ← Context-Engineering 是 Context Substrate 方向的商业化/品牌化语言 -- [[Zep]] ← 引入 ← Zep 率先使用 Context-Engineering 术语 -- [[ai-memory-tools-two-camps]] ← 来源 ← Context-Engineering 是 @witcheer 识别的最重要市场信号 diff --git a/wiki/concepts/Context-Passing.md b/wiki/concepts/Context-Passing.md deleted file mode 100644 index 27b6491b..00000000 --- a/wiki/concepts/Context-Passing.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Context Passing" -type: concept -sources: [workflow-startup-mvp] -last_updated: 2026-04-25 ---- - -## Definition -Context Passing（上下文传递）是多 Agent 协作中的记忆共享机制：Agent 之间不存在共享记忆，下一个 Agent 必须显式接收上一个 Agent 的完整输出作为输入上下文。 - -## Details -- **实现方式**：手动 copy-paste 或由 Orchestrator Agent 自动传递 -- **关键原则**：不要摘要，要使用完整输出 -- **与 [[Sequential Handoff]] 的关系**：Context Passing 是 Sequential Handoff 的技术基础 - -## Aliases -- Context Passing -- 上下文传递 - -## Related Patterns -- [[Sequential Handoff]] -- [[Orchestrator Agent]]（未来可自动化此过程） - -## Sources -- [[workflow-startup-mvp]] diff --git a/wiki/concepts/Context-Reset.md b/wiki/concepts/Context-Reset.md deleted file mode 100644 index 7bb17c69..00000000 --- a/wiki/concepts/Context-Reset.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Context Reset" -type: concept -tags: - - "agentic-ai" - - "context-window" - - "recovery" -sources: - - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog" -last_updated: 2026-04-20 ---- - -## Overview -Context Reset——当 [[Context-Anxiety]] 触发时，Harness 将当前 Agent 状态保存至磁盘、终止实例、启动全新 Agent 的程序化操作，用于解决长周期任务超出单次 context window 的问题。 - -## Trigger Condition -```python -if (tokens_used / max_context) > 0.7: # 阈值需按模型调优 - trigger_context_reset() -``` - -## Procedure -1. **Save state**: 完整项目状态写入持久存储（磁盘文件） -2. **Terminate**: 终止当前 LLM 实例 -3. **Launch fresh**: 启动全新 Agent，加载保存状态 -4. **Orient**: 新 Agent 读取状态、定位自身、继续工作 - -## Why Not In-Place Summarization? -原地摘要（summarize → keep in same context）仍让模型在嘈杂、退化的上下文中操作。Context Reset 提供完全干净的上下文窗口——代价更高，但可靠性显著提升，适用于超长周期任务。 - -## Trade-off -- **In-place summarization**: 便宜，但 context 仍嘈杂 -- **Context Reset**: 昂贵（需重新加载状态），但可靠性高 - -## Source -- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]] - -## See Also -- [[Context-Anxiety]] — 触发条件 -- [[State-Externalization]] — 持久化状态文件格式 -- [[7-Layer-Harness-Stack]] — 第 7 层 Constraints & Recovery 的核心机制 diff --git a/wiki/concepts/Context-Substrate.md b/wiki/concepts/Context-Substrate.md deleted file mode 100644 index 6adf089b..00000000 --- a/wiki/concepts/Context-Substrate.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "Context-Substrate" -type: concept -tags: [AI-Memory, Context-Substrate, File-Native, Compounding] -sources: [ai-memory-tools-two-camps] -last_updated: 2026-04-15 ---- - -## Definition -AI 记忆工具的 Camp 2 范式。维护结构化、人类可读的上下文，跨会话累积。不提取"事实"——上下文本身就是文件。问的核心问题是"**AI 应该在什么上下文中工作？**" - -## Core Loop -1. Agent 工作前读取结构化上下文 -2. Agent 在上下文中工作 -3. Agent（或后台进程）写回结构化上下文 -4. 下一会话，上下文比之前更丰富 - -## Optimization Goal -**复合增长（compounding）**——系统是否随时间变得更好？ - -## Representative Tools -- [[OpenClaw]]：358k stars，MEMORY.md + 每日笔记 + DREAMS.md，Dreaming 三阶段 -- [[Zep]]：4.4k stars，从"Memory"重品牌为"Context Engineering"，TKG 时间知识图谱 -- [[Thoth]]：145 stars，10 实体类型 + 67 关系，Dream Cycle 四阶段 -- [[TrustGraph]]：2.0k stars，Context Cores 版本化容器 -- [[MemSearch]]：1.2k stars，Markdown 优先，Milvus 影子索引 -- [[ALIVE]]：文件原生，零依赖，@witcheer 自用方案 - -## Common Characteristics -- 文件（Markdown、知识图谱）是上下文本身 -- 人类可读、可编辑、可版本控制 -- 跨会话累积，不替换而是丰富 -- 后台整合进程（Dream Cycle）定期提炼 -- 透明度高：人类能准确知道 Agent 知道什么 - -## Key Contrast with Memory-Backend -| 维度 | Memory Backend | Context Substrate | -|------|---------------|-------------------| -| 问的问题 | AI 应该记住什么？ | AI 应该在什么上下文中工作？ | -| 处理对象 | 提取的"事实" | 结构化上下文文件 | -| 人类可读 | 否 | 是 | -| 随时间演进 | 否（静态条目） | 是（复合累积） | -| 透明度 | 低（黑盒） | 高（文件可见） | -| 优化目标 | 召回精度 | 复合增长 | -| 适用场景 | 单轮问答 | 持续多会话 Agent | - -## Connections -- [[Memory-Backend]] ← 对立阵营 ← Context-Substrate -- [[OpenClaw]] ← 属于 ← Context-Substrate -- [[Zep]] ← 属于 ← Context-Substrate -- [[Thoth]] ← 属于 ← Context-Substrate -- [[TrustGraph]] ← 属于 ← Context-Substrate -- [[MemSearch]] ← 属于 ← Context-Substrate -- [[ALIVE]] ← 属于 ← Context-Substrate -- [[Context-Engineering]] ← 重品牌化方向 ← Context-Substrate -- [[ai-memory-tools-two-camps]] ← 来源 ← Context-Substrate 是 @witcheer 提出的分类框架中的 Camp 2 diff --git a/wiki/concepts/Context-Window.md b/wiki/concepts/Context-Window.md deleted file mode 100644 index 9fe9bf91..00000000 --- a/wiki/concepts/Context-Window.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Context Window" -type: concept -tags: [llm, context-window, token, embedding, rag] -last_updated: 2026-04-10 ---- - -## Sources -- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]] - - -## Definition -Context Window（上下文窗口）是 LLM 或 Embedding Model 一次性处理的最大 token 数量。超过该限制的内容无法被模型感知，必须切分或截断。 - -## Key Numbers -- **Embedding Model**：通常 512~8192 token（如 BAAI/bge 系列） -- **LLM**：差异极大，从 4K（GPT-3.5）到 200K+（Claude 3）不等 - -## Practical Impact -### 对 Embedding Model -- 决定单次可 Embedding 的最大文本长度 -- 超过则需 Split（切分文档） - -### 对 LLM（Generation 阶段） -- 决定用户问题 + 检索上下文 + 系统 Prompt 的总 token 预算 -- 超过则需截断（可能丢失关键信息） - -## Token Estimation -- **英文**：1 token ≈ 3~4 个字母 -- **中文**：1 token ≈ 1 个汉字 - -## Related Concepts -- [[Split]] — 文档需要切分以满足 Context Window 约束 -- [[Embedding]] — Embedding Model 的 Context Window 限制 -- [[Token]] — Context Window 的计量单位 -- [[Generation]] — LLM 的 Context Window 决定最终可输入的上下文量 diff --git a/wiki/concepts/ContextDrivenTask.md b/wiki/concepts/ContextDrivenTask.md deleted file mode 100644 index 291314e9..00000000 --- a/wiki/concepts/ContextDrivenTask.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "ContextDrivenTask" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-27 ---- - -## Aliases -- 上下文驱动任务 -- 上下文感知任务 -- 笔记内任务 -- 嵌入式任务 -- Contextual Tasks -- Embedded Tasks - -## Definition -ContextDrivenTask（上下文驱动的任务管理）是一种将任务嵌入到相关笔记上下文中的任务管理理念。任务不再是孤立的清单条目，而是与决策背景、参考资料、思考过程保存在同一位置，从而在需要时自然地出现在工作流中。 - -## Key Characteristics -- 位置关联：任务放在与其相关的笔记里，而非独立的待办列表中 -- 背景保留：任务的来源、参考资料、决策理由都随任务一起保存 -- 按需查看：通过查询语法在任何笔记中展示相关任务，而非强制打开任务列表 -- 自然工作流：在阅读研究笔记时，任务自然可见，无需切换应用 - -## Core Insight -传统任务管理的痛点："打开 Todoist → 找到任务 → 处理任务" -上下文驱动任务的优势："在笔记的上下文中，直接看到当前最重要的任务" - -## When to Use -- 任务与特定项目/文档高度相关，需要保留背景信息 -- 需要在研究笔记中嵌入待验证的假设或待完成的研究步骤 -- 希望任务可见性与文档上下文保持一致 - -## Connections -- [[ObsidianTasksPlugin]] ← implements ← [[ContextDrivenTask]]（Tasks 插件是上下文驱动任务的典型实现） -- [[TaskQuerySyntax]] ← enables ← [[ContextDrivenTask]]（查询语法是实现上下文驱动任务的核心机制） -- [[ContextDrivenTask]] ← opposed_to ← [[Todoist]]（Todoist 代表"任务与笔记分离"的理念） diff --git a/wiki/concepts/Continuous-Batching.md b/wiki/concepts/Continuous-Batching.md deleted file mode 100644 index abe8f3b4..00000000 --- a/wiki/concepts/Continuous-Batching.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Continuous Batching" -type: concept -tags: [continuous-batching, vllm, inference, gpu] -aliases: [Continuous Batching, 连续批处理, Iteration-Level Scheduling] -last_updated: 2025-12-20 ---- - -## Definition -Continuous Batching，连续批处理，vLLM 的推理优化技术。与传统的攒满一批再处理不同，Continuous Batching 在每个解码步骤（按 Token 迭代）都动态组装活跃请求批次，GPU 基本满负载运转。 - -## Key Facts -- 传统批处理：攒满一批再跑，短任务被长任务阻塞（头阻塞问题） -- Continuous Batching：每步解码都组装新批次，无需等待整批结束即可插入新请求 -- 基于 [[PagedAttention]] 的块式内存 + 步进级调度器实现 -- 提高 GPU 并发与公平性，充分利用 GPU 算力 - -## Connections -- [[vLLM]] ← 使用 ← [[Continuous Batching]] -- [[PagedAttention]] ← 协同 ← [[Continuous Batching]] - -## Sources -- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]] diff --git a/wiki/concepts/Continuous-Delivery.md b/wiki/concepts/Continuous-Delivery.md deleted file mode 100644 index 2dfb219d..00000000 --- a/wiki/concepts/Continuous-Delivery.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Continuous Delivery" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-24 ---- - -## 定义 -持续交付（Continuous Delivery）是一种软件工程方法，通过自动化流水线使代码变更可以在任何时候安全地部署到生产环境。 - -## 核心特征 -- **随时可发布：** 代码变更经过自动化测试后，可随时部署 -- **无需等待固定周期：** 打破 Sprint/迭代边界 -- **自动化流水线：** 构建、测试、部署全流程自动化 - -## 与 Kanban 的关系 -持续交付是 Kanban 框架的核心优势之一——当需求可以随时进入看板、完成即可交付时，团队可以更快地响应变化。 - -## 与 Scrum 的对比 -Scrum 的批量发布模式（Sprint 结束时一次性发布）相比持续交付，延迟了价值交付时间，且积累的变更越多，发布风险越高。 - -## 来源 -- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] diff --git a/wiki/concepts/Continuous-Deployment.md b/wiki/concepts/Continuous-Deployment.md deleted file mode 100644 index 2131209c..00000000 --- a/wiki/concepts/Continuous-Deployment.md +++ /dev/null @@ -1,49 +0,0 @@ -# Continuous Deployment - -## Definition -Continuous Deployment (CD) is a DevOps practice where code changes that pass all automated tests are automatically deployed to production environments without manual intervention. - -## Key Characteristics - -### Across DevOps Maturity Levels -| Maturity | CD Practice Level | -|----------|-------------------| -| Phase 1 | Manual deployments, milestone-based releases, no automation | -| Phase 2 | Automation used to reduce release risks, but still requires manual triggers | -| Phase 3 | Automated infrastructure provisioning, more frequent deployments possible | -| Phase 4 | Continuous integration pipeline enables tangible business benefits; infrastructure and code managed through pipelines | -| Phase 5 | Multiple deployments per day with high certainty and minimal risk; zero human intervention for code changes passing through the pipeline | - -### Core CD Elements -- Automated deployment pipelines -- Zero human intervention after code commit -- High confidence in automation quality -- Fast rollback capabilities -- Progressive delivery strategies (canary, blue-green) -- Real-time monitoring post-deployment - -## Relationship with Continuous Integration - -CD builds on CI. The full CI/CD pipeline: -1. **CI** — Every code change triggers automated builds and tests -2. **CD** — Changes passing CI are automatically deployed - -At Phase 5 maturity, the CI/CD pipeline achieves **continuous deployment** where code flows from commit to production automatically. - -## Business Impact -- Faster time-to-market -- Reduced release risk through smaller, incremental changes -- Rapid feedback from production users -- Higher team productivity -- Competitive advantage through rapid iteration - -## Sources -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] -- [[sources/cloud-devop-maturity-guideline.md]] - -## Related Concepts -- [[concepts/CI-CD-Pipeline]] -- [[concepts/Continuous-Integration]] -- [[concepts/DevOps-Maturity]] -- [[concepts/Infrastructure-as-Code]] -- [[concepts/Error-Budget]] diff --git a/wiki/concepts/Continuous-Dev-QA-Loop.md b/wiki/concepts/Continuous-Dev-QA-Loop.md deleted file mode 100644 index 872f11d9..00000000 --- a/wiki/concepts/Continuous-Dev-QA-Loop.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Continuous-Dev-QA-Loop" -type: concept -tags: [] -sources: [agents-orchestrator] -last_updated: 2026-05-29 ---- - -## Definition -**Continuous Dev-QA Loop**（持续开发质量循环）是 [[AgentsOrchestrator]] Phase 3 的核心机制——开发与 QA 交替进行，每个开发交付物立即经过 QA 验证，形成快速反馈闭环。 - -## Relationship to [[Dev-QA-Loop]] -- [[Dev-QA-Loop]] is the specific implementation of this concept within the AgentsOrchestrator pipeline -- Continuous Dev-QA Loop is the broader principle: rapid feedback between development and quality assurance - -## Core Principle -> "No shortcuts: Every task must pass QA validation." - -## Loop Characteristics -- **Continuous**: No waiting until end-of-project QA — validation happens after each task -- **Fast feedback**: Developer receives specific feedback immediately after implementation -- **Evidence-based**: QA requires visual/screenshot proof, not self-reported completion -- **Iterative**: Loop continues until PASS or max retries reached - -## Benefits -- Issues caught early before propagating to downstream tasks -- Developer receives specific, actionable feedback -- Quality gates prevent broken functionality from advancing -- Reduced final integration issues due to continuous validation - -## Sources -- [[agents-orchestrator]] diff --git a/wiki/concepts/Continuous-Integration.md b/wiki/concepts/Continuous-Integration.md deleted file mode 100644 index 788e66fc..00000000 --- a/wiki/concepts/Continuous-Integration.md +++ /dev/null @@ -1,51 +0,0 @@ -# Continuous Integration - -## Definition -Continuous Integration (CI) is a DevOps practice where developers frequently merge their code changes into a shared repository, triggering automated builds and tests to detect integration issues early. - -## Key Characteristics - -### Across DevOps Maturity Levels -| Maturity | CI Practice Level | -|----------|-------------------| -| Phase 1 | None — manual integration, siloed development | -| Phase 2 | Introduction — version control for code and configurations | -| Phase 3 | Automated builds and tests integrated into the development process | -| Phase 4 | CI pipeline with automated quality gates, performance and load testing | -| Phase 5 | Zero-touch CI pipeline with real-time data for decision making | - -### Core CI Elements -- Automated builds triggered on every code commit -- Automated unit, integration, and end-to-end tests -- Static code analysis and security scans -- Fast, reliable build pipelines -- Immediate feedback to developers - -## Role in DevOps Maturity - -CI is a foundational DevOps practice. Organizations cannot advance to higher DevOps maturity without robust CI. At Phase 3+, CI is combined with continuous delivery (CD) to form CI/CD pipelines. - -Key progression: -1. **Phase 2**: Version control introduction, superficial automation -2. **Phase 3**: Most builds automated, security scans in the pipeline -3. **Phase 4**: Immutable infrastructure managed through CI pipelines -4. **Phase 5**: Zero human intervention — all code changes pass through automated pipeline - -## Metrics -- Build success rate -- Build frequency -- Mean time to build -- Code coverage percentage -- Test pass rate -- Time to first failure detection - -## Sources -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] -- [[sources/cloud-devop-maturity-guideline.md]] - -## Related Concepts -- [[concepts/CI-CD-Pipeline]] -- [[concepts/Continuous-Deployment]] -- [[concepts/DevOps-Maturity]] -- [[concepts/Infrastructure-as-Code]] -- [[concepts/DevSecOps]] diff --git a/wiki/concepts/ControllingIdea.md b/wiki/concepts/ControllingIdea.md deleted file mode 100644 index 8be7426b..00000000 --- a/wiki/concepts/ControllingIdea.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Controlling Idea" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-30 ---- - -## Aliases -- Controlling Idea -- 核心主题 -- 主题性论点 - -## Overview -Controlling Idea 是 [[Robert McKee]] 在其著作《故事》中提出的核心概念，定义为"故事对人性的论点"——它通过叙事中所有选择（情节、角色、场景、语言）来传达作者对人类经验的理解。 - -## Structure -Controlling Idea = **主题性价值（Thematic Value）** × **因果关系（Causal Connection）** - -### Examples -| Controlling Idea | Thematic Value | Causal Connection | -|-----------------|---------------|-------------------| -| "骄傲导致毁灭" | 骄傲 | 导致 | -| "勇气可以通过小事培养" | 勇气 | 通过...培养 | -| "真正的力量来自放下控制" | 力量 | 通过放下获得 | - -## Application -[[Academic Narratologist]] 的核心分析维度之一： -- **诊断工具**：识别故事"真正在说什么"，而非表面情节 -- **评估标准**：所有情节选择是否与 Controlling Idea 一致 -- **主题一致性检查**：跨多条情节线验证主题表达是否连贯 - -## Relationship to Other Concepts -- [[Fabula-vs-Sjuzhet]]：Controlling Idea 是 sjuzhet（讲述层）背后的 fabula（故事层）意义 -- [[Character-Arc]]：角色的 transformation 必须与 Controlling Idea 一致 -- [[Three-Act-Structure]]：Act III 的 Resolution 必须完成主题性论点的建构 diff --git a/wiki/concepts/Conversation-State-Persistence.md b/wiki/concepts/Conversation-State-Persistence.md deleted file mode 100644 index 5e906bf2..00000000 --- a/wiki/concepts/Conversation-State-Persistence.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Conversation-State-Persistence" -type: concept -tags: [] -sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend] -last_updated: 2026-05-02 ---- - -## Definition -Conversation State Persistence 是服务端存储完整对话历史（含工具调用）的机制，使客户端无需自行管理上下文。 - -## Implementation in Hermes Agent -通过 `/v1/responses` API 实现有状态会话： -- **无状态**：`/v1/chat/completions` 每次请求需传递完整对话历史 -- **有状态**：`/v1/responses` 支持 `previous_response_id` 链式调用，服务端保留完整上下文（含工具调用） - -## Key Benefits -- 客户端无需存储和发送完整对话历史 -- 服务端自动维护工具调用记录 -- 支持多轮对话中的上下文连续性 - -## Use Case -长对话场景下，使用 Responses API 可以大幅减少客户端代码复杂度。 - -## Related -- [[ResponsesAPI]] -- [[System-Prompt-Layering]] diff --git a/wiki/concepts/Conversational-Interface.md b/wiki/concepts/Conversational-Interface.md deleted file mode 100644 index bc813970..00000000 --- a/wiki/concepts/Conversational-Interface.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Conversational Interface" -type: concept -tags: [interface, UX, conversation, AI] -sources: [second-brain] -last_updated: 2026-04-22 ---- - -## Definition - -对话即界面（Conversational Interface）是一种以自然语言对话为核心交互模式的设计理念：用户通过发送消息来操作系统，无需学习特定命令、点击特定按钮或导航特定菜单。对话本身就是使用界面，打破了"发送消息 → 另一设备构建内容"的空间壁垒。 - -## Aliases - -- Conversational Interface -- 对话即界面 -- Chat as UI -- 自然语言交互 - -## Key Insight - -> "You can text your bot from your phone and it builds things on your computer. The interface is the conversation." - -## Characteristics - -1. **跨设备**：用户从手机发消息 → AI 在电脑端执行/构建 -2. **无需 App**：手机短信/Telegram/Discord → 直接触发 AI 操作 -3. **零学习曲线**：不需要学习任何新工具或新界面 -4. **上下文感知**：AI 基于对话历史理解用户意图 - -## In System - -- [[Second Brain]] 的核心交互范式 -- [[multi-channel-assistant]] 同一模式的多渠道扩展 -- [[phone-based-personal-assistant]] 语音版对话接口 - -## Relationships - -- [[Zero-Friction Capture]] — 对话界面是实现零摩擦捕获的关键手段 -- [[Topic-Based Routing]] — 对话场景下的上下文隔离机制 diff --git a/wiki/concepts/Conversions-API.md b/wiki/concepts/Conversions-API.md deleted file mode 100644 index 7c63eba7..00000000 --- a/wiki/concepts/Conversions-API.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Conversions API" -type: concept -tags: ["paid-media", "tracking", "privacy", "attribution"] -last_updated: 2026-04-25 ---- - -## Aliases -- CAPI -- Server-Side Conversions API -- Meta Conversions API -- 服务端转化追踪 - -## Overview -Conversions API（CAPI）是一种服务端到平台广告服务器的直接事件传递机制，绕过浏览器像素限制，实现更准确的转化归因。后 iOS 14 隐私政策时代的关键归因基础设施。 - -## Definition -与客户端像素对比优势： -- 不受浏览器插件、VPN、广告拦截器影响 -- 覆盖跨设备转化（PC 搜索 → 手机转化） -- 事件可靠性更高，不丢信号 -- 可传递更多事件参数（客户资料哈希、订单价值等） - -典型实施方式： -- 通过服务器端事件（无头浏览器、服务器日志）直接发送到 Meta/Google -- 与客户端像素并行，实现双重信号验证 - -## Connections -- 与客户端像素协同构成 [[Custom Audience Engineering]] 的双轨追踪 -- 是 [[Incrementality Testing]] 准确性的数据保障 -- [[Paid Media Paid Social Strategist]] Agent 的核心技能之一 diff --git a/wiki/concepts/Core-Gameplay-Loop.md b/wiki/concepts/Core-Gameplay-Loop.md deleted file mode 100644 index b06e6c72..00000000 --- a/wiki/concepts/Core-Gameplay-Loop.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Core Gameplay Loop" -type: concept -tags: [game-design, player-experience, engagement] -sources: [game-designer] -last_updated: 2026-04-26 ---- - -## Definition - -Core Gameplay Loop（核心游戏循环）是一套驱动玩家持续参与的三层循环结构——从瞬间决策（0-30秒）到会话目标（5-30分钟）再到长期进阶（数小时至数周）。它决定了游戏能否在多个时间尺度上维持玩家兴趣。 - -## Three-Layer Structure - -### 1. Moment-to-Moment Loop（瞬间体验，0–30秒） -玩家在极短时间内的重复决策与反馈。 -- **Action**：玩家执行具体操作（跳跃/射击/收集） -- **Feedback**：即时视觉/音效/触觉反馈 -- **Reward**：资源/进度/内在满足感 - -> 核心问题：这个操作本身好玩吗？在没有升级、没有故事的情况下，它能独立成立吗？ - -### 2. Session Loop（会话循环，5–30分钟） -玩家单次游戏会话中的目标与张力。 -- **Goal**：完成目标以解锁奖励 -- **Tension**：风险或资源压力（如时间限制、随机事件） -- **Resolution**：胜负状态与后果 - -### 3. Long-Term Loop（长期循环，小时–周） -驱动玩家持续回流的元进度与留存机制。 -- **Progression**：解锁树 / 元进度系统 -- **Retention Hook**：每日奖励 / 赛季内容 / 社交循环 - -## Design Principles - -1. **每一层都必须独立成立**——长期循环坍塌时，瞬间体验仍能支撑短期参与 -2. **各层相互增强**——瞬间体验的积累推动会话目标，会话目标的完成推动长期进度 -3. **最小可行复杂度**——仅添加产生新颖决策的循环，移除不产生意义的复杂性 -4. **"有趣假设"优先**——在纸面原型阶段验证核心循环的可玩性，而非在完整系统构建后 - -## Relationship to Game Design Document - -Core Gameplay Loop 是 GDD 的核心章节，与以下交付物对应： -- **Mechanic Specification**：定义瞬间循环中的每个具体操作 -- **Economy Balance Spreadsheet**：定义会话循环中的资源流 -- **Player Archetypes**（鲸鱼/海豚/小鱼）：定义长期循环中的不同玩家路径 - -## Related Concepts - -- [[Economy Balance]]：经济系统为会话循环和长期循环提供资源基础 -- [[Player Onboarding]]：引导流程必须快速呈现瞬间循环的可玩性 -- [[Systemic Design]]：次级系统应与核心循环交互以产生涌现性策略 diff --git a/wiki/concepts/CoreDNS-Scaling.md b/wiki/concepts/CoreDNS-Scaling.md deleted file mode 100644 index b607881e..00000000 --- a/wiki/concepts/CoreDNS-Scaling.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "CoreDNS Scaling" -type: concept -tags: - - Kubernetes - - EKS - - DNS - - Scaling - - Networking -sources: - - ctp-topic-64-scaling-out-with-amazon-eks -last_updated: 2026-04-28 ---- - -## Definition -CoreDNS Scaling 是 EKS 集群中 CoreDNS（Kubernetes 默认 DNS 服务）的水平扩缩容策略和优化实践，确保在高密度 Pod 环境下 DNS 查询的高可用性和低延迟。 - -## Problem Statement -- EKS 集群规模增长时，Pod 间的 DNS 查询量呈指数增长 -- 默认 CoreDNS 配置可能无法应对大规模集群的 DNS 负载 -- DNS 查询延迟直接影响应用启动时间和运行时性能 - -## Optimization Strategies -- **HPA 扩缩容**：为 CoreDNS Deployment 配置 HPA，基于 DNS 查询 QPS 或 CPU/内存利用率自动调整副本数 -- **Node Local DNS Cache**：在每个节点部署本地 DNS 缓存（node-local-dns-cache 或 nodelocaldns），减少跨节点 DNS 查询 -- **性能调优**：调整 CoreDNS 的 `cores-per-second` 和 `max-concurrent-queries` 参数 -- **副本数规划**：建议 CoreDNS 副本数不低于集群节点数的 10-20% - -## Relationship with Node Local DNS Cache -- Node Local DNS Cache 通过在每节点运行本地 DNS 缓存 DaemonSet，拦截并缓存 Pod 的 DNS 查询 -- 减少跨节点 DNS 查询流量，降低 DNS 查询延迟 -- 与 CoreDNS HPA 扩缩容配合使用效果最佳 - -## Sources -- [[ctp-topic-64-scaling-out-with-amazon-eks]] diff --git a/wiki/concepts/Cost-As-Distributed-Systems-Bug.md b/wiki/concepts/Cost-As-Distributed-Systems-Bug.md deleted file mode 100644 index bc2ad9fb..00000000 --- a/wiki/concepts/Cost-As-Distributed-Systems-Bug.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Cost As Distributed Systems Bug" -type: concept -tags: [sre, finops, observability, reliability, cost-optimization] -last_updated: 2026-04-20 ---- - -# Cost As Distributed Systems Bug - -"成本是分布式系统的 bug"——成本异常（cost explosion）不仅是财务问题，更是一种可靠性问题。 - -## Core Thesis -成本突然增加往往预示着系统即将发生故障。**成本突增应该被视为告警信号**，触发故障调查而非仅财务审查。 - -## Why Cost Signals Matter -1. **资源泄漏的指示器**：内存泄漏、连接池耗尽往往表现为成本逐步上升 -2. **异常流量的标志**：DDoS 或滥用可能导致成本爆炸 -3. **配置错误**：错误的资源配置可能导致资源过度使用 -4. **级联效应的前兆**：某个组件故障可能导致其他组件超负荷运转 - -## Alerting Strategy -``` -IF cost_increase > threshold: - ALERT("Cost anomaly detected - investigate system health") -``` - -将成本监控集成到 SRE 的告警体系中，而非仅作为 FinOps 的事后分析。 - -## Key Principles -- **Cost as Signal**：将成本指标视为系统健康的信号 -- **Proactive Monitoring**：在成本失控前设置告警 -- **Correlation Analysis**：将成本变化与其他系统指标关联 - -## Relationship to FinOps -FinOps 不仅是成本优化工具，也是 SRE 的可靠性工具。成本可观测性（Cost Observability）是现代 SRE 实践的重要组成部分。 - -## Related Concepts -- [[Cost-Optimization]] -- [[Observability]] -- [[FinOps]] -- [[Distributed-Systems]] -- [[Reliability]] - -## Source -- SRE Weekly Issue #513 — [[sre-weekly-issue-513]] diff --git a/wiki/concepts/Cost-Optimization.md b/wiki/concepts/Cost-Optimization.md deleted file mode 100644 index 289acb0d..00000000 --- a/wiki/concepts/Cost-Optimization.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: Cost Optimization -tags: [Cloud, FinOps, Finance] ---- - -# Cost Optimization - -## Overview - -**Cost Optimization**（成本优化）指通过策略、流程和技术手段最大化云投资回报的过程。FinOps 是云成本优化的核心方法论，多云策略通过竞争性定价和资源调配进一步增强成本控制能力。 - -## Key Strategies - -### 1. Right-Sizing (合理规格) -根据实际使用需求选择合适规格的资源，避免过度配置： -- 定期审查资源利用率 -- 使用监控数据识别过度配置实例 -- 自动推荐合理规格调整 - -### 2. Reserved Capacity (预留容量) -通过预留实例获取显著折扣（通常 30-70%）： -- 分析稳定工作负载模式 -- 评估 1 年/3 年预留承诺 -- 平衡灵活性与折扣 - -### 3. Spot/Preemptible Instances (竞价实例) -利用空闲容量获得大幅折扣（通常 70-90%）： -- 适用于容错工作负载（批处理、CI/CD） -- 实施中断处理机制 -- 混合使用 Spot 和 On-Demand - -### 4. Multi-Cloud Cost Arbitrage (多云成本套利) -利用不同提供商的定价差异优化成本： -- 不同提供商在不同服务上有价格优势 -- 工作负载分配到最具成本效益的提供商 -- 动态调度成本敏感工作负载 - -### 5. FinOps Practices -- **Chargeback/Showback**: 透明化云成本归属 -- **Continuous Optimization**: 持续监控和优化 -- **Unit Economics**: 按业务单位追踪云成本效率 - -## Multi-Cloud ROI Statistics - -| Metric | Value | Source | -|--------|-------|--------| -| 多云优化后运营成本降低 | 30% | Forrester | -| 78% 企业使用 3+ 公有云 | 78% | Virtana | -| 86% 企业计划采用多云 | 86% | New Horizons | - -## Related Concepts - -- [[FinOps]] -- [[Multi-Cloud Strategy]] -- [[ROI]] -- [[Scalability]] - -## Sources - -- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]] diff --git a/wiki/concepts/Counterfactual-Analysis.md b/wiki/concepts/Counterfactual-Analysis.md deleted file mode 100644 index 0bf03e74..00000000 --- a/wiki/concepts/Counterfactual-Analysis.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Counterfactual Analysis" -type: concept -tags: [historiography, methodology] -sources: [academic-historian] -last_updated: 2026-04-30 ---- - -## Definition -反事实推理（Counterfactual Analysis）是一种严谨的"假如"（what if）历史推演方法——设想历史在某个关键节点发生了不同的走向，并分析这种改变会导致什么样的后果。它是 Historian Agent 文档中明确列出的高级能力之一。 - -## Key Features -- **核心原则**：必须以历史偶然性理论（contingency theory）为基础，而非随意想象 -- **必须满足的条件**： - 1. 反事实假设必须是"可想象的"（plausible）——基于已知历史条件 - 2. 必须追溯反事实链条的逻辑后果 - 3. 必须与相似历史案例进行类比验证 - 4. 必须诚实地承认推理的局限性 -- **代表学者**：内弗·弗格森（Niall Ferguson）、贾雷德·戴蒙德（Jared Diamond）《枪炮、病菌与钢铁》 -- **批评**：批评者认为反事实推理过于投机，无法证伪 -- **价值**：帮助理解历史的结构性约束与偶然性因素各自的权重 - -## Relationship to Other Concepts -- [[Longue-Duree]] ← 互补 ← [[Counterfactual-Analysis]]：长时段分析强调结构，反事实分析强调偶然性；两者共同帮助理解历史因果 -- [[Historiography]] ← 属于 ← [[Counterfactual-Analysis]]：反事实推理是历史编纂学中一种有争议但有价值的方法 -- [[academic-historian]] ← 高级能力 ← [[Counterfactual-Analysis]]：Historian Agent 的 Advanced Capabilities 明确包括 Counterfactual Analysis - -## Relationship to Source Pages -- [[academic-historian]]：文档的"🚀 Advanced Capabilities"部分明确列出此能力 - -## Aliases -- 反事实推理 -- What-if Analysis -- Alternative History diff --git a/wiki/concepts/Cowork-UI.md b/wiki/concepts/Cowork-UI.md deleted file mode 100644 index f1087903..00000000 --- a/wiki/concepts/Cowork-UI.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Cowork-UI" -type: concept -tags: [ai-agent, ui, visualization] -sources: [aionui-cowork-desktop] -last_updated: 2026-04-27 ---- - -## Definition - -Cowork-UI 是一种 AI Agent 桌面协作界面范式——在可视化工作空间中实时展示 Agent 读写文件、运行终端命令、浏览网页的全过程，用户不再是"只能看日志"，而是真正"看见 Agent 在做什么"。 - -## Key Characteristics -- **操作可视化**：文件读写、终端命令、网页浏览等操作均有图形化展示 -- **多 Agent 并行**：支持 OpenClaw、Claude Code、Codex 等 12+ Agent 在同一界面中切换或并行运行 -- **上下文共享**：工作空间内所有 Agent 共享同一 MCP 配置 - -## Related Concepts -- [[Remote-Rescue]]：Cowork-UI 的远程接入扩展 -- [[Multi-Agent-Unified-MCP]]：Cowork-UI 的配置统一机制 -- [[Tool-Integration]]：Cowork-UI 的工具层基础 diff --git a/wiki/concepts/CoworkWorkspace.md b/wiki/concepts/CoworkWorkspace.md deleted file mode 100644 index 847bad45..00000000 --- a/wiki/concepts/CoworkWorkspace.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Cowork Workspace" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-22 ---- - -# Cowork Workspace - -一种 Agent 交互范式，提供文件感知的工作空间界面，用户可以直接看到 Agent 读写文件、运行命令、浏览网页——而非仅终端日志或聊天消息输出。 - -## 核心特征 - -- **可视化操作**：Agent 的每一步操作（文件变更、命令执行、网页导航）都以可视化方式呈现 -- **文件感知**：界面直接展示 Agent 正在操作的文件列表和内容变化 -- **实时反馈**：用户实时观察 Agent 工作进展，而非等待任务完成后的日志摘要 - -## 与传统模式的对比 - -| 维度 | 传统 Terminal/Chat 模式 | Cowork Workspace | -|------|------------------------|------------------| -| 文件可见性 | 需主动查询 | 直接展示 | -| 操作可见性 | 推断自日志 | 实时可视化 | -| 交互方式 | 命令式/文本式 | 视觉 + 文本混合 | -| 远程场景 | 纯日志输出 | 部分可视化（远程桌面）| - -## 典型场景 - -- [[AionUi]] 提供 OpenClaw 的 Cowork 工作空间 -- Claude Code Desktop 的文件树和终端面板 -- Cursor Composer 的工作区视图 - -## 相关概念 -- [[RemoteRescuePattern]]：Cowork 模式在远程场景下的扩展 -- [[Multi-AgentHub]]：同一界面管理多个 Agent 的协作空间 diff --git a/wiki/concepts/Coze-Workflow.md b/wiki/concepts/Coze-Workflow.md deleted file mode 100644 index 550912b2..00000000 --- a/wiki/concepts/Coze-Workflow.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Coze Workflow" -type: concept -tags: [ai-agent, workflow, coze] -last_updated: 2026-04-23 ---- - -## Summary -Coze（扣子）平台的工作流编排能力，允许用户通过可视化界面将多个 Bot 和插件串联，实现复杂业务流程的自动化执行。与传统的单 Bot 对话相比，Workflow 支持条件分支、循环、变量传递等编程逻辑，适用于需要多步骤处理的业务场景。 - -## Core Features -- **可视化编排**：拖拽式节点编辑器，无需编程基础 -- **多 Bot 串联**：将多个专业 Bot 按顺序或并行组合 -- **插件集成**：调用天气、地图、数据库、代码执行等外部工具 -- **条件分支**：根据变量值执行不同路径 -- **变量管理**：在节点间传递和转换数据 -- **输出定制**：控制最终输出的格式和内容 - -## Use Cases (from Coze Training) -- **滴滴计费解答_WorkFlow**：将计费规则问答 Agent 串联进业务流程 -- **骑手招聘助手_WorkFlow**：招聘场景的多步骤自动化处理 -- **SONY店员_WorkFlow**：零售门店场景的 AI 客服工作流 - -## Relationship to General Workflow Engineering -属于 [[Workflow-Engineering]] 在 Coze 平台的具体实现。与 [[n8n]] 的工作流自动化属同一方法论的不同工具平台——Coze 侧重 AI Agent 编排，n8n 侧重通用 API 连接与自动化。 - -## Source -- [[AI 解决方案专家培训课程]] diff --git a/wiki/concepts/CreativeFatigue.md b/wiki/concepts/CreativeFatigue.md deleted file mode 100644 index afbc9537..00000000 --- a/wiki/concepts/CreativeFatigue.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Creative Fatigue" -type: concept -tags: ["ppc", "creative", "performance", "optimization"] ---- - -## Definition - -Creative Fatigue（创意疲劳）是指广告创意在累积大量展示后，用户点击率和转化率自然下降的现象。当同一广告被同一用户多次展示后，用户的注意力和行动欲望逐渐降低。 - -## 触发机制 - -- **展示频率（Frequency）**：单个用户累积看到广告 4-6 次后，CTR 开始下降 -- **展示阈值（Impression Threshold）**：超过最优展示次数后，效果显著下滑 -- **新鲜度衰减（Freshness Decay）**：用户对重复创意产生"盲区" - -## 识别指标 - -1. **CTR 下降趋势**：连续 2 周 CTR 环比下降超过 10% -2. **CVR 下降**：转化率随展示次数增加而降低 -3. **频次上升**：Frequency 指标超过 3+ -4. **CPM 上升**：在预算不变情况下，千次展示成本上升 - -## 应对策略 - -| 策略 | 说明 | 周期 | -|------|------|------| -| 创意轮换 | 每 2 周更新一组新创意 | 2 周 | -| 频次封顶 | 受众频次 cap 控制在 3 次以内 | 持续 | -| 受众排除 | 已转化用户排除出投放受众 | 持续 | -| 新鲜度加权 | Google 算法自动偏好新鲜创意 | 自动化 | -| A/B 测试 | 保留胜出创意，淘汰败出创意 | 2-4 周 | - -## 关键指标监控 - -- **CTR Trend**：点击率趋势（周环比） -- **Frequency**：用户平均展示频次 -- **Impression Share by Frequency**：各频次层级的展示份额 -- **Creative Rotation**：创意轮换报告 - -## Success Metrics - -- CTR 保持基准水平（行业均值） -- Frequency 控制在 3 以下 -- 每 2 周至少一次创意测试启动 - -## Sources - -- [[paid-media-creative-strategist]] diff --git a/wiki/concepts/Credential-Isolation.md b/wiki/concepts/Credential-Isolation.md deleted file mode 100644 index 654ebce2..00000000 --- a/wiki/concepts/Credential-Isolation.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Credential-Isolation" -type: concept -tags: [security, credentials, agent-architecture] -sources: [n8n-workflow-orchestration] -last_updated: 2026-04-17 ---- - -## Aliases -- Credential Isolation -- 凭证隔离 - -## Definition - -将 API 凭证（密钥、token）存储在 Agent 可控范围之外的系统中，确保 Agent 的工作环境无法直接访问敏感凭证，从而防止因 Agent 代码提交、错误输出或 Prompt Injection 导致凭证泄露。 - -## Mechanism - -在 [[Webhook-Proxy-Pattern]] 中： -- Agent 只持有 Webhook URL（例：`http://n8n:5678/webhook/my-workflow`） -- API 密钥存储在 n8n 的 Credential Store 中 -- Agent 发送的 JSON payload 不包含任何密钥 - -## Why It Matters -- Agent 的代码、记忆、输出可能被提交到 Git 或暴露在日志中 -- 即使 Agent prompt 被泄露，攻击者也拿不到实际密钥 -- 凭证轮换可在 n8n 端独立完成，无需修改 Agent 提示词 - -## Connections -- [[Webhook-Proxy-Pattern]] — 凭证隔离的实现架构 -- [[Defense-in-Depth]] — 防御纵深策略的组成部分 -- [[Lockable-Workflow]] — 配合凭证隔离防止 Agent 修改调用逻辑 diff --git a/wiki/concepts/Credit-Efficient-Processing.md b/wiki/concepts/Credit-Efficient-Processing.md deleted file mode 100644 index 51cb9a87..00000000 --- a/wiki/concepts/Credit-Efficient-Processing.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Credit-Efficient Processing" -type: concept -tags: [Credits, Cost-Optimization, API, AI-Agent, Efficiency] -sources: [daily-youtube-digest] -last_updated: 2026-04-22 ---- - -## Definition - -Credit-Efficient Processing 是一种通过策略性地分配 API 积分（credits），最大化 AI 信息处理价值的优化方法。核心原则：**免费操作做检查，付费操作做摘要**。 - -## Core Principle - -| 操作类型 | 积分消耗 | 说明 | -|---|---|---| -| 新内容检查 | **免费**（0 积分） | 判断是否有新内容需要处理 | -| 内容处理/摘要 | **按需付费** | 仅对真正需要的内容花费积分 | - -## Example: YouTube Digest - -- `channel/latest` / `channel/resolve` → **0 积分** → 判断频道是否有新视频 -- 字幕提取 + 摘要 → **1 积分/视频** → 仅对感兴趣的视频花费 -- `seen-videos.txt` → **免费** → 避免重复付费 - -## Why It Matters - -AI API 积分是有成本的（即便有免费额度）。在高频自动化场景下，credit-efficient 策略可以将积分消耗降低 90%+，让免费额度支撑更长时间，或降低付费规模。 - -## Connections -- [[Credit-Efficient Processing]] ← enables ← [[Daily YouTube Digest]] -- [[Credit-Efficient Processing]] ← applies_to ← [[TranscriptAPI.com]] diff --git a/wiki/concepts/Cron定时任务.md b/wiki/concepts/Cron定时任务.md deleted file mode 100644 index 5e28fcbe..00000000 --- a/wiki/concepts/Cron定时任务.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: "Cron定时任务" -tags: [linux, automation, devops, ubuntu] -date: 2026-04-26 ---- - -# Cron定时任务 (Cron Job) - -## Definition -Cron 是 Linux/Unix 系统的定时任务调度器，允许用户配置在指定时间自动执行命令或脚本。Cron 通过 crontab（cron table）配置文件管理所有定时任务。 - -## Basic Format -``` -┌───────────── 分钟 (0-59) -│ ┌───────────── 小时 (0-23) -│ │ ┌───────────── 日期 (1-31) -│ │ │ ┌───────────── 月份 (1-12) -│ │ │ │ ┌───────────── 星期 (0-7, 0和7都是周日) -│ │ │ │ │ -* * * * * command -``` - -## Examples - -### 每日凌晨3点执行备份 -``` -0 3 * * * /usr/local/bin/rsync_backup.sh -``` - -### 每6小时执行一次 -``` -0 */6 * * * /path/to/script.sh -``` - -### 每周日凌晨2点执行 -``` -0 2 * * 0 /path/to/weekly_backup.sh -``` - -### 每月的第一天凌晨4点执行 -``` -0 4 1 * * /path/to/monthly_backup.sh -``` - -## Crontab Commands -```bash -# 编辑当前用户的 crontab -crontab -e - -# 查看当前用户的 crontab -crontab -l - -# 删除当前用户的 crontab -crontab -r - -# 以 root 身份编辑系统 crontab -sudo crontab -e -``` - -## Best Practices for Backup Jobs - -### 1. 使用绝对路径 -Cron 任务的执行环境与交互式 shell 不同，PATH 环境变量可能不完整： -```bash -0 3 * * * /usr/local/bin/rsync_backup.sh # ✅ 使用绝对路径 -``` - -### 2. 使用 nohup 确保后台运行 -```bash -0 3 * * * sudo nohup /usr/local/bin/rsync_backup.sh > /dev/null 2>&1 & -``` - -### 3. 使用锁文件防止重复执行 -```bash -LOCKFILE="/tmp/rsync_backup.lock" -if [ -e ${LOCKFILE} ] && kill -0 `cat ${LOCKFILE}`; then - echo "备份任务已在运行中，跳过本次执行。" - exit -fi -echo $$ > ${LOCKFILE} -``` - -### 4. 日志记录 -```bash -LOG="/var/log/rsync_backup.log" -echo "--- 开始备份: $(date) ---" >> "$LOG" -rsync -azR ... >> "$LOG" 2>&1 -``` - -## Related Concepts -- [[增量备份]] — Cron 定时任务自动执行增量备份 -- [[进程管理]] — 后台进程的控制与监控 -- [[挂载点检查]] — 备份前的安全检查 -- [[永久挂载]] — 确保 Cron 任务执行时存储可用 - -## See Also -- [[Disaster-Recovery]] — Cron 任务实现自动化的灾备恢复点 -- [[RTO]] — Cron 任务频率影响恢复时间目标 diff --git a/wiki/concepts/Cross-Account-Monitoring.md b/wiki/concepts/Cross-Account-Monitoring.md deleted file mode 100644 index a3874268..00000000 --- a/wiki/concepts/Cross-Account-Monitoring.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Cross-Account Monitoring -type: concept -tags: [AWS, Security, CloudOps, Multi-Account] -date: 2025-10-24 ---- - -## Definition -Cross-Account Monitoring（跨账户监控）是指在 AWS 多账户环境中，通过安全配置的跨账户访问机制，实现对分布在多个账户的资源、日志和指标的集中监控能力。是 AWS 多账户策略的核心运营支柱之一。 - -## Core Properties -- **最小权限原则**：仅授予必要的跨账户读取权限 -- **集中可见性**：单一管理界面覆盖所有账户 -- **安全边界**：IAM 角色信任策略定义清晰的信任边界 -- **审计追踪**：所有跨账户访问均留下 CloudTrail 记录 - -## AWS Implementation Mechanisms -- **AWS Organizations + SCPs**：通过 Service Control Policies 定义账户权限边界 -- **IAM Cross-Account Roles**：跨账户角色切换实现安全访问 -- **Amazon EventBridge**：事件驱动的跨账户事件转发（该方案的核心机制） -- **AWS CloudWatch Cross-Account Observability**：CloudWatch 原生跨账户可观测性 -- **AWS Security Hub**：跨账户安全态势集中管理 - -## Related Concepts -- [[AWS Organizations]]：提供多账户层级结构，是跨账户监控的基础设施 -- [[Multi-Account Deployment]]：跨账户监控支撑多账户部署的可观测性 -- [[Centralized Logging]]：集中日志是跨账户监控的数据基础 -- [[StackSets Deployment Visibility]]：StackSets 部署监控是跨账户监控的具体应用场景 -- [[Landing Zone Architecture]]：AWS Landing Zone 推荐架构中包含跨账户监控设计 -- [[DevSecOps]]：跨账户安全监控是 DevSecOps 的重要组成部分 - -## Architecture Patterns -1. **Hub-and-Spoke**：管理账户作为中心（Hub），成员账户作为辐射（Spoke） -2. **Event-Driven Fan-out**：通过 EventBridge 将事件从各账户汇聚到管理账户 -3. **Aggregated Dashboards**：Grafana/CloudWatch Dashboards 聚合多账户视图 -4. **Centralized Alerting**：告警规则在管理账户统一定义，跨账户触发 - -## AWS Context -- AWS Organizations Management Account：管理账户，通常承载中心监控功能 -- AWS Organizations Member Accounts：成员账户，被监控的资源所在 -- Organizational Units (OUs)：组织单元，用于分组管理成员账户 -- Trusted Access：AWS StackSets 受信任访问，允许多账户协调操作 -- [[Cross-Account Monitoring]] ← enabled_by ← [[AWS Organizations]] Trusted Access -- [[Cross-Account Monitoring]] ← uses ← [[Amazon EventBridge]] Custom Event Bus -- [[Cross-Account Monitoring]] ← stores ← [[CloudWatch Logs (central-cloudformation-logs)]] diff --git a/wiki/concepts/Cross-Platform-Strategy.md b/wiki/concepts/Cross-Platform-Strategy.md deleted file mode 100644 index bd913d23..00000000 --- a/wiki/concepts/Cross-Platform-Strategy.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Cross-Platform Strategy" -type: concept -tags: [social-media, marketing, multi-platform, content-strategy] -last_updated: 2026-04-26 ---- - -## Definition -跨平台策略是一种在不同社交媒体和数字平台上协调品牌存在感和内容分发的营销方法论。其核心原则是：统一核心信息，根据各平台特性进行内容适配，同时保持品牌声音和视觉识别的一致性。 - -## Core Principles -- **统一消息（Unified Messaging）**：核心主题和价值主张在所有平台上保持一致 -- **平台适配（Platform Adaptation）**：内容形式和风格根据平台文化调整，而非简单复制 -- **内容瀑布流（Content Cascade）**：以主平台为首发，适配到其他平台（如 LinkedIn 首发 → Twitter 适配 → Instagram/YouTube 分发） -- **受众重叠策略（Audience Overlap）**：设计跨平台引流路径，增加受众在各平台的关注和互动 -- **归因追踪（Attribution Tracking）**：跟踪用户跨平台旅程，衡量各平台对转化的贡献 - -## Platform Strategy Examples -|| 平台 | 内容类型 | 核心目标 | 适配要点 | -|------|----------|----------|----------| -| LinkedIn | 长文/白皮书/行业洞察 | 专业权威建立/B2B 线索 | 正式语调、数据驱动 | -| Twitter/X | 即时评论/话题参与/链接 | 实时互动/趋势参与 | 简洁、话题标签 | -| Instagram | 视觉叙事/Reels | 品牌感性连接 | 视觉美学优先 | -| YouTube | 长视频/教程 | 深度参与/SEO | 完播率/留存率优化 | -| TikTok | 短视频/挑战 | Z世代触达/病毒传播 | 娱乐优先、3秒黄金钩子 | - -## China-Specific Platform Matrix - -中国市场平台矩阵，每个平台是独立的"国家"，内容策略不可跨平台直接复制： - -|| 平台 | 基因定位 | 核心指标 | 漏斗角色 | -|------|--------|---------|---------| -| 微博 | 公共舆论风暴 | 时效性 > 互动量 > 权威性 | 公域认知 | -| 抖音 | 视觉速度 | 完播率 > 点赞 > 评论 > 分享 | 种草/放大 | -| 小红书 | 生活方式向往 | 社区审美一致性、KOC 种草 | 种草/决策 | -| 知乎 | 权威可信度 | 内容质量、专家背书 | 信任锚定 | -| B站 | Z世代深度 | 弹幕互动、UP主关系 | 深度考虑 | -| 微信 | 私域关系建设 | 打开率、菜单点击率 | 转化/留存 | -| 快手 | 下沉信任 | 老铁关系、社区真实性 | 下沉市场 | - -> **关键原则**：每个平台是独立的生态。[[marketing-china-market-localization-strategist]] 强调：绝不假设在抖音有效的内容在小红书同样有效——每个平台的内容策略必须独立设计，并基于该平台算法机制定制。 - -## Sources -- [[marketing-social-media-strategist]] -- [[marketing-china-market-localization-strategist]] diff --git a/wiki/concepts/Cross-account-Terraform-Modules.md b/wiki/concepts/Cross-account-Terraform-Modules.md deleted file mode 100644 index d3cee1d1..00000000 --- a/wiki/concepts/Cross-account-Terraform-Modules.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Cross-account Terraform Modules" -type: concept -tags: [Terraform, Cross-Account, Modules, IaC, AWS] -sources: [ctp-topic-16-cross-account-terraform-modules] -last_updated: 2026-04-14 ---- - -## Overview - -Cross-account Terraform Modules 指的是在单个 Terraform 模块中通过配置多个 AWS Provider，实现跨多个 AWS 账号同时创建或管理资源的能力。 - -## Problem Statement - -在复杂的云架构中（如 AWS Landing Zone），经常需要在一个模块内跨多个账号创建资源。例如： -- 在 **InfoBlocks 账号** 配置 DNS 记录 -- 在 **Workload 账号** 部署应用服务 - -原有的 Gruntwork 流水线主要针对单账号设计，直接赋予账号间互访权限存在巨大安全风险——某一账号被攻破可能波及全局。 - -## Solution Architecture - -基于 **Shared Account（共享账号）** 的中心化部署方案： - -1. **Jenkins 托管于 Shared Account**，当检测到模块目录中存在 `cross-account.json` 标记文件时，触发 ECS Deploy Runner -2. **ECS Deploy Runner**（运行在 ECS 上的 Docker 容器）被授予特殊权限，通过 Assume Role 访问目标账号： - - `TF state bucket accessor`：读取目标账号 S3 桶中的 Terraform 状态文件 - - `cross-account ECS deploy runner role`：在目标账号内执行资源部署 -3. 通过根目录 `terragrunt.hcl` 配置角色切换逻辑 - -## Three Design Goals - -| Goal | Mechanism | Benefit | -|------|-----------|---------| -| **安全性** | 无 Workload 账号间直接信任，权限集中于 Shared Account | 控制 Blast Radius | -| **自动化** | Jenkins 自动识别模块类型并选择正确部署路径 | 无人工干预 | -| **可复用性** | 模块代码不硬编码特定账号的角色 | 灵活适配多环境 | - -## Key Files - -- `cross-account.json`：约定俗成的标记文件，放置于模块目录中，告知 Jenkins 调用跨账号部署逻辑 -- `terragrunt.hcl`（Root）：全局 Terragrunt 配置文件，定义远程状态存储和角色切换逻辑 - -## Relationships - -- [[ECS Deploy Runner]] — 执行单元，运行 Docker 容器执行 plan/apply -- [[Shared Account]] — 信任源，托管 Jenkins 和公共服务 -- [[Terraform]] — 底层 IaC 工具 -- [[Gruntwork]] — 参考架构来源 -- [[AWS-Landing-Zone]] — 多账号架构框架 - -## Related Concepts - -- [[Infrastructure-as-Code]] — 上层方法论 -- [[GitOps]] — 部署编排模式 -- [[Assume Role]] — 跨账号身份切换机制（AWS IAM） - -## Notes - -- 本方案与单账号 Gruntwork 流水线为**演进关系**而非冲突 -- 本方案与 Atlantis 跨账号 IAM Role 机制**类似**，但执行载体不同（ECS 容器 vs EC2） diff --git a/wiki/concepts/CrossPlatformPlanning.md b/wiki/concepts/CrossPlatformPlanning.md deleted file mode 100644 index 7824064e..00000000 --- a/wiki/concepts/CrossPlatformPlanning.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: "Cross-Platform Planning" -type: concept -tags: ["ppc", "multi-platform", "strategy", "google-ads", "amazon-ads", "paid-media"] -sources: ["paid-media-ppc-strategist"] -last_updated: 2026-05-01 ---- - -## Definition - -跨平台规划（Cross-Platform Planning）是付费媒体策略中在 Google Ads、Microsoft Advertising、Amazon Ads 等多个广告平台之间协调预算分配、策略制定和效果衡量的系统性方法。核心理念：**避免平台间预算相互蚕食（cannibalization）**，通过统一的测量框架实现整体效率最优。 - -## Three Major Platforms Compared - -| 维度 | Google Ads | Microsoft Advertising | Amazon Ads | -|------|-----------|----------------------|-----------| -| **用户意图** | 信息获取 → 购买 | 信息获取 → 购买（B2B更强） | 购买意图最强 | -| **广告类型** | Search/Shop/PMax/Display/Video | Search/Shop/Audience | SP/SB/SD/DSP | -| **量级** | 最大 | 较小但增长 | 电商专属 | -| **CPC 水平** | 中高 | 较低 | 中等 | -| **竞争密度** | 高 | 中低 | 中 | -| **数据透明度** | 高 | 中 | 中 | - -## Budget Split Frameworks - -### Intent-Based Allocation -``` -基于用户意图漏斗分配： -- 品牌词：Google Brand（高保护）+ Amazon Brand（购买保护） -- 竞品词：Google（截流）+ Microsoft（Bing 独家流量） -- 产品词：Google + Amazon（不同意图阶段） -- 漏斗上层：Google Display/Video + YouTube -``` - -### Platform-Specific Feature Exploitation -- **Google**：Smart Bidding + Performance Max + Broad Match + AI -- **Microsoft**：LinkedIn 受众定向（B2B）+ 更低 CPC + Google 迁移便利 -- **Amazon**：购买意图流量 + DSP + AMC 受众分析 - -## Unified Measurement Approach - -### Attribution Challenges -- **Last-click 归因偏差**：Amazon 通常在漏斗底部，导致 Google Display 贡献被低估 -- **Cross-device**：用户可能在手机研究、PC 搜索、线下购买 -- **Platform silos**：各平台独立追踪，缺乏统一视图 - -### Measurement Solutions -- **Google Analytics 4（GA4）**：跨平台归因（需 UTM + 各平台 API 集成） -- **Amazon AMC（Amazon Marketing Cloud）**：亚马逊生态内的跨触点归因 -- **Incrementality Testing**：衡量各平台真实增量贡献 -- **Data-Driven Attribution**：ML-based 归因模型 - -## Cannibalization Prevention - -| 症状 | 原因 | 解决方案 | -|------|------|---------| -| 跨平台 ROAS 均下降 | 关键词重叠，内部竞争 | 差异化关键词策略 | -| 总转化量不变但成本上升 | 多平台分摊自然流量 | Incrementality 测试验证 | -| 品牌词跨平台 CPC 上升 | 内部竞标 | 统一品牌词竞价策略 | - -## Connections -- [[GoogleAds]]：跨平台策略的核心平台之一 -- [[MicrosoftAdvertising]]：Google 之外的搜索广告补充 -- [[AmazonAds]]：购买意图漏斗底部的专属平台 -- [[IncrementalityTesting]]：衡量跨平台真实增量贡献 -- [[BudgetPacing]]：跨平台预算分配是 pacing 的高级形式 diff --git a/wiki/concepts/Cultural-Authenticity.md b/wiki/concepts/Cultural-Authenticity.md deleted file mode 100644 index c4029611..00000000 --- a/wiki/concepts/Cultural-Authenticity.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Cultural Authenticity" -type: concept -tags: [] -last_updated: 2026-05-15 ---- - -## Definition - -Cultural Authenticity（文化真实性）——AI 生成内容中确保文化元素（建筑、服饰、符号、照明）准确反映目标文化真实生活现实的原则。文化真实性不是"代表性"的同义词——它要求更深层次的准确性：主体必须被正确锚定在其实际环境中。 - -## Core Failures AI Models Exhibit - -1. **Architectural Inaccuracy**：不正确的建筑风格（东亚城市背景出现西式穹顶） -2. **Lighting Bias**：照明预设适合浅肤色，不适合深肤色（hyper-saturated artificial lighting） -3. **Gibberish Cultural Text**：非英语文字/符号被渲染为乱码或冒犯性字符 -4. **Exoticism Bias**：将文化背景"异域化"（将正常城市背景渲染为异国情调） -5. **Hero-Symbol Composition**：文化符号（新月、佛像等）被放大为构图焦点而失去原本意义 - -## Technical Counter-Measures - -Inclusive Visuals Specialist 的技术应对： - -- **显式环境锚定**："In a modern, sunlit architectural office in Nairobi, Kenya. The glass walls overlook the city skyline." -- **否定性符号约束**："No text or symbols on whiteboards" -- **正确照明定义**："The lighting is soft and directional, expertly graded to highlight the richness of her skin tone without washing out highlights." -- **Intersectional Specificity**：文化真实性必须与 intersectionality 结合，不能脱离具体人物 - -## Related Concepts - -- [[Intersectionality]] -- [[Negative Prompting]] -- [[Sociological Accuracy]] -- [[Inclusive Visuals Specialist]] - -## Aliases - -- 文化准确性 -- 文化真实性检验 diff --git a/wiki/concepts/Cultural-Ecology.md b/wiki/concepts/Cultural-Ecology.md deleted file mode 100644 index c67ac612..00000000 --- a/wiki/concepts/Cultural-Ecology.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Cultural Ecology" -type: concept -tags: ["anthropology", "ecology", "environment", "subsistence", "steward"] -last_updated: 2026-04-25 ---- - -## Definition -文化生态学——研究**环境如何塑造文化**，以及**文化又如何反过来塑造和适应环境**的跨学科框架。强调物质条件（气候、地形、资源）对社会组织的约束作用，同时拒绝简单的地理/文化决定论。 - -## Core Framework -- **文化核心（Cultural Core）**：生计模式和与技术环境互动直接相关的社会制度 -- **多线进化（Multilinear Evolution）**：不同环境可能独立产生相似的适应方案 -- **生态系统**：人类群体与环境形成的动态适应系统，具有反馈回路 -- **Pigs and People**（Rappaport）：巴布亚新几内亚 Tsembaga 人的仪式性猪屠杀，是环境调节机制的文化表达 - -## Key Thinkers -- Julian Steward（文化生态学创始人） -- Roy Rappaport（生态系统研究） -- Marvin Harris（文化唯物论） - -## Connections -- [[Anthropologist-Agent]] ← uses_framework ← [[Cultural-Ecology]] -- [[Functionalism]] ← related_to ← [[Cultural-Ecology]] -- [[Polanyi-Exchange]] ← influenced_by ← [[Cultural-Ecology]] diff --git a/wiki/concepts/Cultural-Intelligence.md b/wiki/concepts/Cultural-Intelligence.md deleted file mode 100644 index 8b55bfe7..00000000 --- a/wiki/concepts/Cultural-Intelligence.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Cultural Intelligence" -type: concept -tags: [cultural-intelligence, cross-cultural, internationalization, ux-design] -sources: [specialized-cultural-intelligence-strategist] -last_updated: 2026-05-29 ---- - -## Definition -文化智能（Cultural Intelligence, CQ）——一种跨文化适应能力，使个人或系统能够在不同文化背景下有效运作、沟通和建立信任。区别于 IQ（认知智能）和 EQ（情绪智能），CQ 专门衡量文化适应性，包括：对文化差异的认知理解（Cognitive CQ）、在跨文化情境中的行为适应能力（Physical CQ）、对文化情境的内在动机和信心（Metacognitive CQ）。 - -## In the Context of AI Agents -在 AI Agent 设计中，CQ 体现为： -- 检测和消除软件开发中的隐性排斥（Invisible Exclusion） -- 在生成内容前自主研究特定文化的尊重和赋权表征标准 -- 理解不同文化对颜色、图标、数字、日期格式的差异化语义 - -## Core Dimensions -- **认知 CQ（Cognitive CQ）**：文化知识——理解不同文化的价值观、习俗、社会规范和商业惯例 -- **元认知 CQ（Metacognitive CQ）**：文化意识——在跨文化交流中保持对文化假设的觉察和反思 -- **动机 CQ（Motivational CQ）**：文化好奇——主动学习和适应不同文化的内在驱动力 -- **行为 CQ（Behavioral CQ）**：文化适应——在不同文化情境中灵活调整语言、行为和沟通方式 - -## Related Concepts -- [[Architectural Empathy]]（结构性同理心）：CQ 在软件设计中的实践框架 -- [[Invisible-Exclusion]]（隐性排斥）：CQ 所诊断的核心问题类型 -- [[Global-First-Architecture]]（全局优先架构）：CQ 在技术架构中的实施方法 -- [[Cultural Humility]]（文化谦逊）：CQ 的基础原则——承认知识不完整，持续学习 - -## Key Distinction: CQ vs. Cultural Competence -| 维度 | 文化能力（Cultural Competence） | 文化智能（Cultural Intelligence） | -|------|------------------------------|-------------------------------| -| 假设 | 可以达到"文化熟练"终点 | 强调持续学习和适应 | -| 重点 | 知识和技能的集合 | 动态的、可发展的能力 | -| 态度 | 倾向于"了解"其他文化 | 承认"不了解"并保持好奇 | -| 来源 | 西方学术框架 | 跨文化心理学（ Earley & Ang, 2003） | diff --git a/wiki/concepts/Cumulative-Memory.md b/wiki/concepts/Cumulative-Memory.md deleted file mode 100644 index 52e9af66..00000000 --- a/wiki/concepts/Cumulative-Memory.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Cumulative Memory" -type: concept -tags: [memory, agent, persistence, accumulation] -sources: [second-brain] -last_updated: 2026-04-22 ---- - -## Definition - -累积记忆（Cumulative Memory）是一种 AI Agent 记忆系统特性：Agent 永久保留用户告知的所有内容，随时间推移积累越来越丰富的个人上下文，使 Agent 变得越来越个性化、越来越有价值。与传统会话式 AI 的"每次会话从零开始"形成鲜明对比。 - -## Aliases - -- Cumulative Memory -- 累积记忆 -- Persistent Memory -- 永久记忆 -- Long-term Memory -- 长期记忆 - -## Mechanism - -- 用户通过对话/短信告知 AI 的任何信息（想法、链接、书目、餐厅推荐）都会被永久存储 -- 每次新对话都基于历史上下文展开 -- 随时间推移，Agent 对用户的了解从"陌生人"进化到"贴身助理" - -## Key Insight - -> "OpenClaw's memory system is cumulative — it remembers *everything* you've ever told it, making it more powerful over time." - -系统价值不是线性增长，而是**复利增长**：记忆越多 → 理解越深 → 建议越精准 → 用户越依赖 → 记忆越多。 - -## In System - -- [[Second Brain]] 的核心价值主张 -- [[OpenClaw]] Workspace/MEMORY.md 文件承载累积记忆 - -## Relationships - -- [[Zero-Friction Capture]] — 零摩擦捕获是积累大量记忆的前提（摩擦越低，记录越多） -- [[Agent Memory]] — 技术层面的 Agent 记忆实现 diff --git a/wiki/concepts/Curiosity-Driven-Bug-Discovery.md b/wiki/concepts/Curiosity-Driven-Bug-Discovery.md deleted file mode 100644 index c26fe8e9..00000000 --- a/wiki/concepts/Curiosity-Driven-Bug-Discovery.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: "Curiosity-Driven Bug Discovery" -type: concept -tags: [] -last_updated: 2026-05-02 ---- - -## Definition - -通过主动追问系统假设（而非被动等待测试失败）来发现高危 Bug 的方法论——将"未言明的假设"显式化，并在它们导致故障前将其消灭。 - -## Overview - -大多数生产环境中的严重 Bug 并非来自代码错误，而是来自未被显式记录的**假设**。这些假设在代码编写时被默许存在，随着系统演进逐渐失效，最终在生产环境中引发故障。Curiosity-Driven Bug Discovery 是一套系统化的追问框架，在工作流设计阶段就将这些假设显式化。 - -## Four Question Dimensions - -### 1. 数据持久化假设（Data Persistence Assumptions） -- 数据存储在哪里？存储是持久化还是临时性的？ -- 重启后数据是否仍然存在？ -- 数据在什么条件下被清理？ - -**追问模板**： -> "Where is this data stored? Is the storage durable or ephemeral? What happens on restart?" - -### 2. 网络连通性假设（Network Connectivity Assumptions） -- Service A 能否实际到达 Service B？ -- 它们在同一个网络段吗？是否有防火墙规则？ -- 服务之间是否存在 DNS 解析延迟？ - -**追问模板**： -> "Can service A actually reach service B? Are they on the same network? Is there a firewall rule?" - -### 3. 时序假设（Ordering/Timing Assumptions） -- 当前步骤假设前一个步骤已完成——但它们是并行运行的吗？ -- 什么机制确保时序正确？（健康检查？轮询？事件？锁？） -- 超时值是否合理？ - -**追问模板**： -> "This step assumes the previous step completed — but they run in parallel. What ensures ordering?" - -### 4. 认证授权假设（Authentication/Authorization Assumptions） -- 此端点在启动时被调用——但调用方是否经过身份验证？ -- 什么防止未授权访问？ -- 凭证在何时何地可用？ - -**追问模板**： -> "This endpoint is called during setup — but is the caller authenticated? What prevents unauthorized access?" - -## Application in Workflow Architect - -在 `Discovery Audit Checklist` 中，每发现一个隐式工作流，Workflow Architect 必须主动用四个追问维度扫描一遍。发现的高危假设记录在 `Reality Checker Findings` 表中，标注 severity 为 Critical 或 High。 - -## Why "Curiosity-Driven" - -"Curiosity-driven" 强调这是**主动探索**而非**被动验证**： -- **被动验证**：已有 bug 报告 → 查找原因 -- **主动探索**：无 bug 报告 → 追问假设 → 发现潜在 bug - -这套方法论的核心洞察：**最危险的 bug 是那些从未有人怀疑其存在的假设**。 - -## Success Criteria - -- 每个工作流的 Assumptions 表都被填满（非空白） -- 假设表中的假设在后续 Sprint 中被逐一验证或修正 -- 好奇心驱动发现的 bug 数量 ≥ 被动测试发现的 bug 数量 - -## Related Concepts -- [[Workflow-Tree-Spec]]：假设记录的载体（Assumptions 节） -- [[Reality-Checker]]：验证假设真实性的 Agent -- [[Discovery-Audit]]：发现隐式工作流的入口 - -## Aliases -- Assumption Mining -- Hypothesis-First Bug Discovery -- Proactive Assumption Surfacing diff --git a/wiki/concepts/Custom-Audience-Engineering.md b/wiki/concepts/Custom-Audience-Engineering.md deleted file mode 100644 index cce02637..00000000 --- a/wiki/concepts/Custom-Audience-Engineering.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Custom Audience Engineering" -type: concept -tags: ["paid-media", "audience-targeting", "data"] -last_updated: 2026-04-25 ---- - -## Aliases -- 受众工程 -- Custom Audience -- Pixel Custom Audience - -## Overview -自定义受众工程是一种通过像素数据、CRM 数据和平台互动行为构建精准广告定向受众的技术方法论。[[Paid Media Paid Social Strategist]] Agent 将其作为跨平台社交广告的核心能力之一。 - -## Definition -核心构成： -- **像素自定义受众**：基于网站像素追踪行为（页面访问、加购、结账等）构建 -- **CRM 名单上传**：上传客户邮箱/电话名单进行匹配定向（Customer Match） -- **互动受众**：视频观看者、主页互动者、表单开启者、UGC 互动者等 -- **排除策略**：防止已转化用户被再营销、受众阶段重叠 -- **受众重叠分析**：使用平台工具分析受众重叠率，优化各渠道独特触达 - -## Connections -- 支撑 [[Full-Funnel Campaign Architecture]] 的受众基础 -- 需要 [[Conversions API]] 补充像素数据的跨设备覆盖缺口 -- iOS 隐私变化后需配合 [[SKAdNetwork]] 做移动端归因 diff --git a/wiki/concepts/Custom-Instructions.md b/wiki/concepts/Custom-Instructions.md deleted file mode 100644 index 51ed9abc..00000000 --- a/wiki/concepts/Custom-Instructions.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Custom Instructions" -type: concept -tags: [ai, chatgpt, personalization, prompt-engineering] -last_updated: 2026-04-23 ---- - -# Custom Instructions - -## Aliases -- 自定义指令（ChatGPT） -- Custom Instructions - -## Definition -ChatGPT 提供的一项功能，允许用户通过两条配置项（"自定义指令"+"你的详情"）永久定义 AI 的行为模式、响应风格和用户背景，无需在每次对话中重复说明。 - -## Two Components -1. **自定义指令**：定义 AI 的交互偏好 - - 响应风格（有条理/简洁/详细） - - 工作方式（主动预判/被动等待） - - 引用格式、道德判断倾向等 - -2. **你的详情**：描述用户背景 - - 专业领域和技术水平 - - 工作场景和使用目标 - - 语言偏好 - -## Case Study: Weishen 的配置 -- **用户假设**：被定义为"所有领域专家"，无需简化技术 -- **错误政策**：错误零容忍，必须准确和详尽 -- **引用要求**：URL 统一放末尾 -- **道德判断**：不进行道德说教 -- **推测告知**：高度推测内容必须明确标注 - -## Relevance to This Wiki -- [[openai-chatgpt-个性化定义]]：完整的自定义指令配置内容 -- [[Agent Personality Design]]：多 Agent 系统中的个性化设计，与 Custom Instructions 同属 AI 个性化范畴 - -## Sources -- [[openai-chatgpt-个性化定义]] diff --git a/wiki/concepts/Customer-Zero.md b/wiki/concepts/Customer-Zero.md deleted file mode 100644 index 88646224..00000000 --- a/wiki/concepts/Customer-Zero.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: "Customer Zero Environment" -type: concept -tags: [Customer-Zero, DevOps, QA, Staging, Release-Management, Production-Readiness] -sources: - - public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2 -last_updated: 2026-04-29 ---- - -## Customer Zero Environment - -Customer Zero Environment（新版本的首位客户环境/内部验证环境）是指在新版本或产品正式发布给外部客户之前，在内部部署的预生产环境，用于在真实流量场景下验证功能正确性、性能和恢复能力。是 [[SRE]] Build 阶段的关键实践，也是 [[Recovery-Assurance]] 四位框架中"Build"环节的核心概念。 - -## Definition - -> "Customer Zero is the environment where your organization is the first customer of your own product — validating releases in production-like conditions before external rollout." - -Customer Zero 环境本质上是**内部影子客户**——用自己的产品，在受控环境中模拟真实使用场景，发现问题后再对外发布。 - -## Purpose - -| 目标 | 说明 | -|------|------| -| **新版本验证** | 在真实环境中测试新版本功能和性能 | -| **恢复路径验证** | 验证备份/恢复/故障转移流程在实际负载下是否有效 | -| **配置变更验证** | 测试配置变更（IaC 脚本、基础设施调整）对系统的影响 | -| **灾难演练** | 在隔离环境中主动触发故障，验证恢复 SLA | -| **性能基线建立** | 建立系统在正常负载下的性能基准 | - -## Customer Zero vs. Other Environments - -| 环境 | 目的 | 何时使用 | -|------|------|----------| -| **Dev** | 开发调试 | 开发人员日常编码 | -| **Test** | 功能测试 | QA 团队执行测试用例 | -| **Staging** | 预发布验证 | 接近生产的镜像测试 | -| **Customer Zero** | **内部影子客户验证** | **在真实生产配置下进行最终验证** | -| **Production** | 正式服务客户 | 正式上线 | - -## Key Characteristics - -1. **生产等效配置**：Customer Zero 使用与生产完全相同的基础设施配置（VPC、子网、安全组、IAM 角色） -2. **影子数据**：使用脱敏的生产数据副本（或合成数据），反映真实数据量和分布 -3. **隔离但连通**：通常与生产隔离，但可以使用生产的数据源（如 CloudWatch Logs）的脱敏版本 -4. **持续验证**：不仅是发布前的单次验证，而是 CI/CD 流水线中的持续验证关卡 - -## Connection to SRE - -在 [[SRE]] 的 Build 阶段，Customer Zero 环境是"Release Readiness"的核心： - -- **Go-Live Checklist 的一部分**：SRE 团队在支持新产品上线前，需要在 Customer Zero 验证监控覆盖、告警阈值和恢复流程 -- **Error Budget 验证**：在新版本发布后，通过 Customer Zero 监控错误趋势，确认 Error Budget 消耗符合预期 -- **Toil 发现**：Customer Zero 中发现的重复性问题，推动自动化改进，减少未来的 Toil - -## Connection to Recovery Assurance - -[[Recovery-Assurance]] 四位框架中的"Build"环节： - -``` -Design → Software → Build(Customer Zero) → Environments -``` - -- **Design**：定义可恢复性需求（[[RTO]]/[[RPO]]） -- **Software**：软件内嵌遥测，支持健康监控 -- **Build**：Customer Zero 环境验证恢复路径和 SLA -- **Environments**：SRE + [[Observability]] 支撑持续运营 - -## Related Concepts - -- [[SRE]] — Customer Zero 是 SRE Build 阶段的关键实践 -- [[Recovery-Assurance]] — Build 环节的验证环境 -- [[Observability]] — Customer Zero 中的恢复演练依赖可观测性数据 -- [[RTO]] / [[RPO]] — Customer Zero 验证 DR 目标是否满足 -- [[CI/CD]] — Customer Zero 是 CI/CD 流水线中的质量关卡 - -## Sources - -- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] diff --git a/wiki/concepts/DAST.md b/wiki/concepts/DAST.md deleted file mode 100644 index 7dfff1e7..00000000 --- a/wiki/concepts/DAST.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "DAST" -type: concept -tags: [security, dynamic-analysis, penetration-testing, devsecops] -sources: ["what-is-devsecops-best-practices-benefits-and-tools"] -last_updated: 2025-12-19 ---- - -## Definition - -DAST（Dynamic Application Security Testing，动态应用安全测试）是一种在应用程序运行时模拟外部攻击，从攻击者视角发现安全漏洞的黑盒测试方法。DAST 工具无需访问源代码，通过发送恶意请求并分析响应来识别漏洞。 - -## Characteristics - -- **黑盒测试**：无需源代码，独立于应用实现 -- **测试和部署阶段使用**：在应用运行状态下进行扫描 -- **真实攻击模拟**：模拟真实黑客的攻击手法 -- **低误报率**：发现的漏洞通常是真实可利用的 - -## Capabilities - -DAST 工具擅长发现以下类型的漏洞： -- SQL 注入（SQL Injection） -- 跨站脚本（XSS） -- 认证和会话管理缺陷 -- 信息泄露 -- 服务器配置错误 -- API 安全问题 - -## Limitations - -- 覆盖率受限（无法扫描未访问的代码路径） -- 无法定位具体漏洞代码位置 -- 可能对生产环境造成影响（需在测试环境运行） - -## Typical Tools - -- OWASP ZAP (Zed Attack Proxy) -- Burp Suite -- Acunetix -- Netsparker - -## Relationship with DevSecOps - -DAST 是 [[DevSecOps]] CI/CD 流水线的重要环节，通常在集成测试或预生产环境阶段执行。与 [[SAST]] 互补——SAST 发现代码层漏洞，DAST 发现运行时和架构层漏洞。 - -## Related Concepts - -- [[SAST]] — 静态应用安全测试，白盒分析，与 DAST 互补 -- [[IAST]] — 交互式应用安全测试，结合两者优势 -- [[OWASP Top Ten]] — DAST 扫描的核心参考标准 -- [[Shift Right]] — 右移策略，上线后持续 DAST 扫描 diff --git a/wiki/concepts/DBA-Role-Evolution.md b/wiki/concepts/DBA-Role-Evolution.md deleted file mode 100644 index 7bd68185..00000000 --- a/wiki/concepts/DBA-Role-Evolution.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "DBA Role Evolution" -type: concept -tags: - - Cloud - - Database - - DevOps - - Career -sources: - - ctp-topic-51-architecting-with-aws-purpose-built-databases -last_updated: 2026-04-28 ---- - -## Overview -云时代数据库管理员（DBA）的角色正经历深刻转变：从底层平台运维转向应用层创新和架构设计，成为 DevOps/平台工程的桥梁。 - -## Traditional DBA Responsibilities (On-Premises) -传统 DBA 的核心工作： -- 物理服务器和存储的采购、配置、维护 -- 数据库引擎安装、补丁管理、版本升级 -- 备份策略制定与恢复演练 -- 性能调优（索引、查询优化） -- 安全管理（用户、权限、审计） - -## Cloud-Native DBA Responsibilities (AWS) -云时代 AWS 上的 DBA 职能转变： - -| 传统职责 | 云时代转变 | -|----------|------------| -| 物理硬件管理 | AWS 全托管服务自动处理 | -| 备份/补丁 | RDS/Aurora/DynamoDB 自动备份和滚动补丁 | -| 容量规划 | 自动扩展或按需容量 | -| **新增职责** | | -| 数据库选型 | 根据数据模型选择最优专用数据库 | -| 架构设计 | 设计多数据库混合架构 | -| 查询优化 | 应用层性能优化 | -| 数据治理 | 跨数据库的数据合规和生命周期管理 | - -## Key Insight -> "The role of the DBA is evolving in the cloud." — 云时代 DBA 的核心价值从平台管理转向应用创新 - -## Focus Shift -DBA 应将精力从： -- ❌ 手动备份、补丁、容量管理 -- ✅ 架构设计、查询优化、数据建模、跨服务集成 - -## Connections -- [[Purpose-Built-Databases]]：云时代 DBA 需要掌握多种专用数据库的选型和特性 -- [[Multi-Database-Architecture]]：DBA 在多数据库架构设计中承担架构师角色 -- [[Amazon-RDS]] / [[Amazon-Aurora]] / [[Amazon-DynamoDB]]：云托管数据库减轻了 DBA 的平台运维负担 - -## Referenced In -- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]] diff --git a/wiki/concepts/DKIM-Email-Authentication.md b/wiki/concepts/DKIM-Email-Authentication.md deleted file mode 100644 index 40dd98d4..00000000 --- a/wiki/concepts/DKIM-Email-Authentication.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "DKIM Email Authentication" -type: concept -tags: - - Email - - Security - - AWS -date: 2026-04-14 ---- - -## Definition - -DKIM（DomainKeys Identified Mail）是一种电子邮件验证标准，通过在邮件头部添加数字签名来验证邮件确实由声称的域名授权发送，防止邮件被篡改和伪造。 - -## How DKIM Works - -1. **域名所有者**在 DNS 中发布 DKIM 公钥 -2. **发送邮件服务器**使用私钥对邮件头和正文生成数字签名 -3. **接收服务器**通过 DNS 查询获取公钥，验证签名有效性 -4. 签名包含在邮件头的 `DKIM-Signature` 字段中 - -## DKIM in AWS SES - -AWS SES 支持 DKIM 验证： -- SES 自动为域名生成 DKIM 签名密钥 -- 域名所有者需要在 DNS 中添加三条 CNAME 记录 -- 启用 DKIM 后，SES 自动对所有出站邮件进行签名 - -## Related Concepts -- [[SPF]]（Sender Policy Framework）：另一种 DNS ベースの邮件验证方法 -- [[DMARC]]（Domain-based Message Authentication, Reporting & Conformance）：综合 SPF 和 DKIM 的邮件验证框架 -- [[Email-Security]]：邮件安全的整体方法论 - -## DKIM vs SPF vs DMARC - -| 机制 | 验证内容 | 实施难度 | -|------|----------|----------| -| SPF | 验证发送服务器 IP 是否被域名授权 | 低 | -| DKIM | 验证邮件内容未被篡改 | 中 | -| DMARC | 基于 SPF + DKIM 验证 | 中高 | diff --git a/wiki/concepts/DNS-Anycast.md b/wiki/concepts/DNS-Anycast.md deleted file mode 100644 index 59df23c1..00000000 --- a/wiki/concepts/DNS-Anycast.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "DNS Anycast" -type: concept -tags: [DNS, Networking, High-Availability, Infoblox] -sources: [] -last_updated: 2026-05-07 ---- - -## DNS Anycast - -一种网络寻址和路由方法，使多个地理位置分布的 DNS 服务器共享同一个 IP 地址，将用户请求路由至地理位置最近的节点，从而实现极低的延迟和自动故障转移。 - -## How It Works - -传统 DNS 使用 Unicast（单播），每个服务器节点有独立 IP 地址。Anycast 则让多个节点使用相同的 IP： - -1. **路由层**：BGP 协议根据网络拓扑将请求路由到最近的节点 -2. **低延迟**：用户请求自动被引导至物理距离最近的服务器 -3. **高可用**：当某个节点不可用时，路由协议自动将流量切换到次近节点 - -## Enterprise Use Case: Infoblox - -企业级 DNS 平台（如 Infoblox）广泛使用 Anycast： - -- **Grid 架构**：全球分布的 Infoblox 设备共享同一 VIP（Virtual IP） -- **自动故障转移**：单点故障不影响服务 -- **DDoS 缓解**：分布式架构吸收恶意流量 - -## AWS Limitation - -AWS EC2 基础架构目前不支持 Anycast： - -- EC2 实例无法共享同一弹性 IP 进行 Anycast 路由 -- 需要手动维护多 IP 地址列表实现高可用冗余 -- 这是选择 Route 53（托管服务）vs 自建 EC2 DNS 的重要考量 - -## Key Concepts - -- [[Infoblox Grid]]：企业级 DNS/DHCP/IPAM 平台的分布式架构 -- [[Route 53]]：AWS 托管 DNS 服务（使用 Anycast 自身运营，但不支持客户自建） -- [[Hybrid DNS Resolution]]：混合云 DNS 解析架构 - -## Aliases - -- DNS Anycast -- Anycast DNS -- IP Anycast diff --git a/wiki/concepts/DNS托管.md b/wiki/concepts/DNS托管.md deleted file mode 100644 index 519e82f5..00000000 --- a/wiki/concepts/DNS托管.md +++ /dev/null @@ -1,68 +0,0 @@ -# DNS托管 - -> DNS托管，通过 Cloudflare 免费托管 ishenwei.online 域名 DNS 解析，提供全球 CDN 和免费 SSL 证书。 - -## Overview -Cloudflare 是全球知名的 CDN 和 DNS 服务提供商，提供免费的 DNS 托管服务。本方案使用 Cloudflare 托管 ishenwei.online 主域名，通过 A 记录将子域名指向 RackNerd VPS 公网 IP（192.227.222.142），配合 Caddy 实现基于域名的反向代理。 - -## Configuration - -|| 记录类型 | 主机名 | 指向 | 说明 | -|---------|---------|-------|------|------| -| A | vps.ishenwei.online | 192.227.222.142 | VPS 直连 | -| A | *.ishenwei.online | 192.227.222.142 | 所有子域名泛解析 | -| A | macmini.ishenwei.online | 192.227.222.142 | Mac Mini | -| A | nas.ishenwei.online | 192.227.222.142 | Synology NAS | -| A | ubuntu1.ishenwei.online | 192.227.222.142 | Ubuntu Server 1 | -| A | ubuntu2.ishenwei.online | 192.227.222.142 | Ubuntu Server 2 | - -## Free Features Used - -1. **DNS 解析**：全球 200+ 节点，毫秒级解析 -2. **免费 SSL 证书**：通用加密模式（Flexible SSL），Caddy 提供服务端证书 -3. **CDN 加速**：静态资源全球缓存 -4. **DDoS 防护**：基础 DDoS 防护免费 -5. **HTTP/2 + HTTP/3**：现代协议支持 - -## Traffic Flow - -``` -[用户浏览器] - │ - │ DNS 查询: grafana.ishenwei.online - ▼ -[Cloudflare DNS] - A 记录 → 192.227.222.142 - │ - │ HTTPS 请求 - ▼ -[RackNerd VPS: Caddy] - TLS 终止 + 反向代理 - │ - │ FRP 隧道 - ▼ -[内网服务] -``` - -## vs 阿里云 DNS -- **阿里云 DNS**：收费（按解析量），功能全面，适合国内业务 -- **Cloudflare**：免费，功能对个人使用足够，全球节点更多，隐私保护更好 - -## DNS-01 Challenge (Wildcard Certificate) -申请 *.ishenwei.online 泛域名证书时，Let's Encrypt 通过 DNS-01 挑战验证域名所有权： -1. CA 要求在 `_acme-challenge.ishenwei.online` TXT 记录写入特定值 -2. Cloudflare API 自动更新该 TXT 记录 -3. CA 验证通过后颁发泛域名证书 - -## Related Concepts -- [[HTTPS自动化证书]] — Caddy 自动申请 Let's Encrypt 证书 -- [[反向代理]] — Caddy 基于域名的反向代理 -- [[内网穿透]] — FRP 隧道传输 -- [[CDN]] — Cloudflare 全球内容分发网络 - -## Related Entities -- [[Cloudflare]] — DNS 托管服务商 -- [[RackNerd]] — VPS 公网 IP（DNS A 记录指向） -- [[Caddy]] — 自动 HTTPS + 反向代理 -- [[frp]] — 内网穿透隧道 -- [[阿里云 DNS]] — 国内 DNS 替代方案 diff --git a/wiki/concepts/DORA-Metrics.md b/wiki/concepts/DORA-Metrics.md deleted file mode 100644 index b7829628..00000000 --- a/wiki/concepts/DORA-Metrics.md +++ /dev/null @@ -1,53 +0,0 @@ -# DORA Metrics - -## Definition -DORA (DevOps Research and Assessment) metrics are four key performance indicators established by the DevOps Research and Assessment team to measure and benchmark DevOps performance. - -## The Four Keys - -| Metric | Description | Elite Performance | -|--------|-------------|------------------| -| **Deployment Frequency** | How often code is deployed to production | On-demand (multiple deploys per day) | -| **Lead Time for Changes** | Time from code commit to production | Less than one hour | -| **Change Failure Rate** | Percentage of deployments causing failures | 0-15% | -| **Mean Time to Recovery (MTTR)** | Time to restore service after a failure | Less than one hour | - -## Usage in DevOps Maturity Assessment -DORA metrics are a core component of DevOps maturity evaluation, providing quantifiable measures of an organization's DevOps performance. High-performing organizations typically deploy on-demand, have short lead times, low change failure rates, and rapid recovery times. - -## Extended Metrics from DevOps Maturity Model - -Beyond the four core DORA metrics, the DevOps Maturity Model (Bacancy) identifies additional operational metrics: - -| Metric | Description | -|--------|-------------| -| **Time-To-Market** | Period from initial concept to product launch | -| **Code Deployment Success Rate** | Proportion of successful deployments | -| **Rollback Rate** | Proportion of deployments that are reverted | -| **Error Budget** | Permissible rate of errors and failures in production | -| **Availability** | Time the system remains operational and accessible | -| **Scalability** | System's ability to manage increased load | -| **Time-in-stage** | Average duration to complete each development phase | -| **Code Review Feedback Loop Time** | Time to receive and act on code review feedback | - -## Sources -- [[sources/cloud-devop-maturity-guideline.md]] -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] - -## Related Concepts -- [[concepts/DevOps-Maturity]] -- [[concepts/CI-CD-Pipeline]] -- [[concepts/Lead-Time]] -- [[concepts/Time-to-Market]] -- [[concepts/Change-Failure-Rate]] -- [[concepts/MTTR]] -- [[concepts/MTTD]] -- [[concepts/MTTA]] -- [[concepts/Error-Budget]] -- [[concepts/Rollback-Rate]] -- [[concepts/Availability]] -- [[concepts/Scalability]] - -## Ingested -- Date: 2026-04-21 -- Date: 2026-04-24 (added extended metrics) diff --git a/wiki/concepts/DRY-Principle.md b/wiki/concepts/DRY-Principle.md deleted file mode 100644 index 7f05a2ed..00000000 --- a/wiki/concepts/DRY-Principle.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: "DRY Principle" -type: concept -tags: - - software-engineering - - iac - - best-practices -sources: [ctp-topic-48-terraform-vs-terragrunt] -last_updated: 2026-04-26 ---- - -# DRY Principle - -## Definition - -DRY（Don't Repeat Yourself，勿重复自己）是一项软件工程原则，主张：**系统中的每一条知识必须有一个单一的、明确的、权威的表示**。DRY 的核心目标是减少重复代码和配置，提高系统的可维护性、可扩展性和可测试性。 - -## Core Idea - -> "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." - -DRY 不是简单的"不复制粘贴"，而是更深层的原则：**避免重复的知识**。这包括： -- 代码逻辑 -- 配置文件 -- 文档注释 -- 数据结构 - -## DRY in IaC - -在基础设施即代码（IaC）领域，DRY 尤为重要，因为基础设施配置往往需要在多个环境（dev/staging/prod）中复用： - -| 实践 | 说明 | -|------|------| -| **Terragrunt** | 封装 Terraform，通过 `remote_state` 和 `include` 块统一管理跨环境的 provider 和状态配置 | -| **Terraform Modules** | 将可复用的基础设施组件抽象为模块，避免在每个环境中重复定义 | -| **Service Catalog** | 企业级模块目录，支持三级复用（单账户→产品团队→跨团队） | -| **Hierarchical Configuration** | 层级配置继承，父级定义通用配置，子级覆盖特定值 | - -**来源**: [[ctp-topic-48-terraform-vs-terragrunt]], [[ctp-topic-3-deploy-and-maintain-infrastructure]] - -## DRY vs WET - -| 原则 | 全称 | 结果 | -|------|------|------| -| **DRY** | Don't Repeat Yourself | 一次定义，多次引用 | -| **WET** | Write Everything Twice | 多次重复，维护成本高 | - -WET 的典型反模式： -- 复制粘贴配置到每个环境 -- 硬编码值而非使用变量 -- 注释与代码不同步 - -## When NOT to Apply DRY - -DRY 不是绝对的，在以下情况下适度重复是可接受的： -- **性能优化**：内联代码可能比函数调用更快 -- **可读性**：过度抽象可能导致代码难以理解 -- **解耦**：强制的 DRY 可能增加组件间的耦合 - -## Related Concepts - -- [[Infrastructure-as-Code]] — DRY 原则的重要应用领域 -- [[Terraform]] — Terragrunt 的底层引擎 -- [[Terragrunt]] — DRY 原则在 Terraform 生态中的具体实现 - -## Related Sources - -- [[ctp-topic-48-terraform-vs-terragrunt]] diff --git a/wiki/concepts/DRY原则.md b/wiki/concepts/DRY原则.md deleted file mode 100644 index 51613f77..00000000 --- a/wiki/concepts/DRY原则.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "DRY原则" -type: concept -tags: [software-engineering, coding-standards, best-practices, dry] -sources: [开发经验与项目规范整理文档] -last_updated: 2025-12-30 ---- - -## Definition - -**DRY 原则（Don't Repeat Yourself）** 是一种软件开发原则，核心思想是：系统中的每一片知识都必须有一个单一、明确、权威的表述。避免重复代码，提炼公共逻辑，提高复用价值。 - -## Core Principles - -- 消除重复代码 -- 提炼公共逻辑到可复用模块 -- 保持代码的单一事实来源 -- 通过抽象和模块化实现代码复用 - -## Related Concepts - -- [[单一职责原则]] — DRY 的前提是模块有清晰的职责 -- [[模块化编程]] — DRY 的实现手段 -- [[Vibe Coding]] — AI 辅助开发中避免重复生成相似代码的指导原则 - -## Source Reference - -来源：[[开发经验与项目规范整理文档]] diff --git a/wiki/concepts/DRaaS.md b/wiki/concepts/DRaaS.md deleted file mode 100644 index b37fc229..00000000 --- a/wiki/concepts/DRaaS.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: "Disaster Recovery as a Service (DRaaS)" -type: concept -tags: [cloud, disaster-recovery, business-continuity, security] -date: 2025-03-01 ---- - -## Definition - -灾备即服务（DRaaS）是一种云原生灾难恢复解决方案，提供基于云的故障转移能力，使组织能够快速恢复关键业务系统，同时降低传统灾备基础设施的成本和复杂性。 - -## Core Metrics - -### RTO (Recovery Time Objective) -- 灾难发生后系统恢复的最大可接受时间 -- [[ITSM]]中业务连续性的关键指标 - -### RPO (Recovery Point Objective) -- 最大可容忍的数据丢失时间窗口 -- 决定备份频率和策略 - -## DRaaS vs Traditional DR - -| 维度 | 传统灾备 | DRaaS | -|------|---------|-------| -| 成本 | 高CAPEX | 按需付费 | -| 恢复速度 | 小时/天 | 分钟 | -| 复杂度 | 高 | 托管服务 | -| 测试 | 困难 | 自动化测试 | -| 可扩展性 | 有限 | 云弹性 | - -## Key Features (Modern DRaaS) - -### AI-Driven Automated Failover -``` -监控检测 → 故障确认 → 自动触发 → 故障转移 → 服务恢复 - ↓ ↓ ↓ ↓ ↓ - AIOps ML模型 策略执行 DNS切换 健康检查 -``` - -### Multi-Cloud Support -- 跨云故障转移 -- 混合云灾备 -- 数据主权合规 - -## In ITSM Context - -在[[ITSM]]中，DRaaS是[[Disaster-Recovery]]流程的核心： - -``` -Disaster Recovery & Business Continuity (ITSM 8.0) -├── AI-driven Automated Failover -│ ├── 智能故障检测 -│ ├── 策略驱动的故障转移 -│ └── 自动服务恢复 -├── RTO/RPO Optimization -│ ├── 连续复制 -│ ├── 增量备份 -│ └── 快速恢复 -└── Cloud-native DRaaS - ├── 按需扩展 - ├── 托管服务 - └── 成本优化 -``` - -## Related Concepts - -- [[Disaster-Recovery]] — 灾备总框架 -- [[RTO]] — 恢复时间目标 -- [[RPO]] — 恢复点目标 -- [[Failover]] — 故障转移机制 -- [[Business-Impact-Analysis]] — 业务影响分析 - -## Sources - -- [[understanding-complete-itsm]] — DRaaS在现代ITSM中的应用 -- [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]] — RTO/RPO详解 diff --git a/wiki/concepts/Daily-Digest.md b/wiki/concepts/Daily-Digest.md deleted file mode 100644 index 92ba0d66..00000000 --- a/wiki/concepts/Daily-Digest.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Daily-Digest" -type: concept -tags: [Daily-Digest, AI-Agent, Content-Consumption, Information-Management] -sources: [daily-youtube-digest, multi-source-tech-news-digest] -last_updated: 2026-04-22 ---- - -## Definition - -Daily-Digest 是一种信息消费模式：由 AI Agent 定时（如每天早上 8 点）将多个信息源的最新内容打包成结构化摘要，统一推送给用户。它替代的是算法推荐的"被动碎片消费"（doom-scrolling），用主动的系统化摄入提升信息获取效率。 - -## Core Mechanism - -1. **Trigger**: 定时（cron）或阈值（达到 N 条未读） -2. **Collection**: 从各来源获取最新条目（RSS/API/网页爬取） -3. **Processing**: AI 提取关键信息（摘要、要点、时间戳） -4. **Delivery**: 打包推送（Email/Telegram/Slack/Notification） -5. **Deduplication**: 避免重复处理（seen-videos.txt 或哈希记录） - -## Variants in the Wiki - -| Digest Type | Source | Trigger | -|---|---|---| -| Daily YouTube Digest | [[daily-youtube-digest]] | 每日 8am | -| Multi-Source Tech News | [[multi-source-tech-news-digest]] | 每小时 | -| Daily Reddit Digest | [[daily-reddit-digest]] | 每日 | -| Custom Morning Brief | [[custom-morning-brief]] | 每日 9am | - -## Why It Works - -- **注意力聚焦**: 把多次"打开 App 看一眼"变成一次专注的 Digest 阅读 -- **去重**: 系统自动追踪已处理内容，不浪费用户时间 -- **成本可控**: 免费 API 检查 + 按需付费摘要（如 TranscriptAPI 1积分/视频） -- **个性化**: 用户定义频道列表/关键词，算法无法替代主动选择 - -## Connections -- [[Daily-Digest]] ← powers ← [[second-brain]] (信息摄入层) -- [[Transcript-Based Summarization]] ← feeds_into ← [[Daily-Digest]] -- [[Credit-Efficient Processing]] ← enables ← [[Daily-Digest]] diff --git a/wiki/concepts/Daily-Journaling.md b/wiki/concepts/Daily-Journaling.md deleted file mode 100644 index 4c0c7c40..00000000 --- a/wiki/concepts/Daily-Journaling.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Daily Journaling" -type: concept -tags: [productivity, habit, note-taking] -sources: [obsidian-高效指南-我常用的插件与实用技巧] -last_updated: 2025-03-01 ---- - -## Definition -每天固定时间在笔记系统中创建一篇当日日记的工作流——通常包含当日计划、重要待办、学习笔记和总结反思，形成"早上计划—晚上总结"的时间管理节奏。 - -## Core Mechanisms -- 自动创建：每天首次打开时自动生成当日笔记 -- 模板预设：包含日期、当日计划、待办事项、学习笔记等结构 -- 模板引擎：Templater 等插件支持动态日期等变量 -- 周期回顾：链接前一天的日记，形成连续叙事 - -## Implementations -- **Daily Notes** (Obsidian 内置)：开箱即用的每日笔记 -- **Templater**：配合自定义模板丰富每日笔记结构 -- **QuickAdd**：通过快捷键快速创建当日日记 -- **Calendar** (Obsidian 插件)：日历视图管理每日笔记 - -## Workflow Pattern -``` -早上 → 打开 Obsidian → 创建 Daily Note → 写下当日计划 -工作时 → 在对应笔记中工作，记录灵感 -晚上 → 回到 Daily Note → 总结当日成果，反思改进 -``` - -## Benefits -- **节奏感**：每天有明确的开始和结束仪式 -- **追踪习惯**：历史日记记录成长轨迹 -- **知识沉淀**：日常所学有固定记录位置 -- **减少焦虑**：计划外事项可移至第二天 - -## Connections -- [[Template-based Note Creation]]：Daily Note 通常依赖模板创建 -- [[Periodic Review]]：每日总结是周期性复盘的基础 -- [[Quick Capture]]：可快速向 Daily Note 添加内容 -- [[Obsidian]]：主要实现平台 - -## Sources -- [[obsidian-高效指南-我常用的插件与实用技巧]] diff --git a/wiki/concepts/Daily-Log.md b/wiki/concepts/Daily-Log.md deleted file mode 100644 index f6d2b558..00000000 --- a/wiki/concepts/Daily-Log.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: "Daily-Log" -type: concept -tags: [knowledge-management, productivity, zettelkasten, zk-steward] -sources: [zk-steward] -last_updated: 2026-04-25 ---- - -## Definition -Daily-Log（每日日志）是 [[zk-steward]] 维持知识网络时效性的基础设施——在 `memory/YYYY-MM-DD.md` 路径下，以 Intent / Changes / Open loops 三段式格式记录当天所有知识活动的日志。 - -## Format - -```markdown -### [YYYYMMDD] Short task title - -- **Intent**: What the user wanted to accomplish. -- **Changes**: What was done (files, links, decisions). -- **Open loops**: [ ] Unresolved item 1; [ ] Unresolved item 2 (or "None.") -``` - -## Three Sections Explained - -### Intent（意图） -简述用户当天提出的核心任务或问题。作用：保留任务上下文，防止日后"这段知识从哪里来"的困惑。 - -### Changes（变更） -记录当天产出的实质性变化： -- 创建/更新的笔记及路径 -- 新建立的链接 -- 归档决策（如"为什么不链接到 X"） -- 索引/MOC 更新 - -### Open Loops（开放循环） -扫描当天未完成或待跟进的事项： -- [ ] 标记未解决项目 -- "None." 表示当天没有遗留问题 -- 这是"容易忘记但重要"项目的收容池 - -## Why Daily-Log Matters - -| 问题 | Daily-Log 解决方案 | -|------|-----------------| -| "这条知识从哪来？" | Intent 提供任务上下文 | -| "上周做了什么决策？" | Changes 记录归档决策历史 | -| "上次卡在哪里了？" | Open loops 保留未解决线索 | -| "知识网络时效性？" | 每日增量更新，无需批量维护 | - -## Relationship to Zettelkasten - -在传统 [[Zettelkasten]] 中，日志通常是隐式的（通过卡片间的时间戳和引用关系推断）。[[zk-steward]] 将日志显式化： -- **时间锚定**：每日一条日志，索引按日期可检索 -- **决策透明**：归档选择和理由显式记录 -- **开放循环追踪**：防止遗忘，同时为未来灵感留白 - -## 与 Morning Briefing 的区别 - -Daily-Log 由 [[zk-steward]] 维护，聚焦**知识积累**活动（笔记/链接/归档）。Morning Briefing（如 [[养虾日记3]] 中提到的）在 AI Agent 场景下，指的是**任务活动**的早晨总结（待办/进度/阻塞）。两者互补： -- **Daily-Log**：知识网络建设视角 -- **Morning Briefing**：任务执行视角 - -## Connections -- [[zk-steward]] ← 使用 Daily-Log 作为每日知识活动记录 -- [[Luhmann-四原则]] ← Daily-Log 服务于"有机增长"原则（知识随时间自然积累） -- [[Zettelkasten]] ← Daily-Log 是 Zettelkasten 时间维度的显式实现 -- [[Open-Loops]] ← Daily-Log 的 Open Loops 部分直接填入 Open-Loops 文件 - -## Aliases -- 每日日志 -- 日志 -- 每日知识日志 diff --git a/wiki/concepts/DarkLaunching.md b/wiki/concepts/DarkLaunching.md deleted file mode 100644 index cf7355ee..00000000 --- a/wiki/concepts/DarkLaunching.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "DarkLaunching" -type: concept -tags: ["deployment", "release-management", "feature-rollout"] -sources: ["engineering-autonomous-optimization-architect"] -last_updated: 2026-04-26 ---- - -## Aliases -- Dark Launch -- 暗启动 -- 灰度发布 -- Feature Flag Deployment - -## Definition -暗启动是 [[AutonomousOptimizationArchitect]] 的模型引入策略——在不完全暴露给用户的前提下，将新模型部署到生产环境，通过 [[ShadowTraffic]] 验证其性能。分为三个阶段：影子测试（不返回用户）→ 灰度流量（5% 用户）→ 全量切换。 - -## Mechanism -1. **Phase 1 - Shadow Deployment**：新模型接收影子流量，完全不影响用户 -2. **Phase 2 - Canary**：5% 真实流量切换到新模型，监控错误率和用户满意度 -3. **Phase 3 - Full Rollout**：新模型通过所有检查后，全量替换旧模型 - -## Key Properties -- **风险可控**：任何阶段发现问题均可立即回滚 -- **数据驱动**：每个阶段都有明确的量化指标门槛 -- **与 CI/CD 集成**：暗启动可作为自动化发布流水线的组成部分 - -## Connections -- [[AutonomousOptimizationArchitect]] — 使用暗启动作为新模型引入框架 -- [[ShadowTraffic]] — 暗启动 Phase 1 的核心实现方式 -- [[CircuitBreaker]] — 提供暗启动失败时的自动保护机制 diff --git a/wiki/concepts/Data-Contract.md b/wiki/concepts/Data-Contract.md deleted file mode 100644 index 0fd640ee..00000000 --- a/wiki/concepts/Data-Contract.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Data Contract" -type: concept -tags: [data-engineering, data-quality, schema, SLA] -sources: [engineering-data-engineer] -last_updated: 2026-05-02 ---- - -## Definition - -Data Contract（数据契约）是数据生产者和消费者之间的明确协议，定义了数据的预期 schema、数据类型、SLA、所有权和消费方。数据契约是 Medallion Architecture 中 Silver→Gold 层质量保证的核心机制。 - -## Components - -### Schema Contract -- 字段名、类型、约束（not_null、unique、foreign key） -- Schema 演化规则：允许添加 nullable 字段，禁止删除或修改类型 -- `mergeSchema=true`：允许 schema 演进，但触发告警而非自动污染下游 - -### SLA Contract -- 刷新频率（如"每 15 分钟刷新一次"） -- 数据新鲜度阈值（如"1 小时内必须有新数据"） -- 可用性承诺（如"Gold 层 99.9% 可用性"） - -### Ownership Contract -- 数据所有者（Data Owner） -- 数据消费者（Data Consumer） -- 支持联系人（Support Contact） - -## Enforcement - -### dbt Contract Enforcement -```yaml -models: - - name: silver_orders - config: - contract: - enforced: true # 强制 schema 契约，类型不匹配则构建失败 - columns: - - name: order_id - data_type: string - constraints: - - type: not_null - - type: unique -``` - -### Great Expectations（数据质量验证） -- 行级数据质量评分必须在 Gold 层附加 -- Null 率告警阈值（如 `customer_id` null 率从 0.1% 跳至 4.2% → 触发 PagerDuty） - -## Key Rules - -- **Schema 漂移必须告警**：不得静默损坏下游数据 -- **Null 处理必须显式**：不得隐式将 null 传播到 Gold 层 -- **发布前必须与消费者确认**：数据契约签署后才能部署 Gold 层管道 - -## Related Concepts -- [[Medallion Architecture]] -- [[Great Expectations]]（数据质量验证工具） -- [[Data Lineage]] -- [[SCD Type 2]] diff --git a/wiki/concepts/Data-Distillation.md b/wiki/concepts/Data-Distillation.md deleted file mode 100644 index 429407b4..00000000 --- a/wiki/concepts/Data-Distillation.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Data Distillation" -type: concept -tags: [distillation, model-compression, training, llm] -aliases: [Data Distillation, 数据蒸馏, Knowledge Distillation] -last_updated: 2025-12-20 ---- - -## Definition -Data Distillation，数据蒸馏，利用高性能的大模型生成精简但有价值的数据，使一个小模型可以从中学习并逼近大模型的效果。 - -## Key Facts -- 核心思想：用大模型作为"教师"（Teacher），生成高质量训练数据 -- 小模型（Student）从这些数据中学习 -- 目标：以更低成本达到接近大模型的效果 -- 是模型压缩和高效部署的重要技术手段 - -## Connections -- [[Large Language Model]] ← 教师模型 ← [[Data Distillation]] - -## Sources -- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]] diff --git a/wiki/concepts/Data-Governance.md b/wiki/concepts/Data-Governance.md deleted file mode 100644 index e358cb65..00000000 --- a/wiki/concepts/Data-Governance.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: "Data Governance (Cloud)" -type: concept -tags: [cloud-computing, governance, data-management] -date: 2025-03-02 ---- - -# Data Governance (Cloud) - -**Data Governance**（数据治理）是云平台提供的用于管理、监控和保护数据的工具和策略，确保企业对其数据拥有完全的控制权。 - -## Definition - -云数据治理涵盖数据的整个生命周期：创建、存储、使用、共享、归档和销毁。核心目标是确保数据的安全性、完整性和合规性。 - -## Key Components - -### 1. Access Control -- 基于角色的访问控制（RBAC） -- 基于属性的访问控制（ABAC） -- 最小权限原则 -- 定期访问审查 - -### 2. Data Encryption -- 传输中加密（TLS 1.3） -- 静态加密（AES-256） -- 客户管理密钥（CMK） -- 密钥管理服务（KMS） - -### 3. Audit & Monitoring -- 访问日志（CloudTrail, Azure Monitor, Cloud Logging） -- 实时告警 -- 合规报告 -- 数据血缘追踪 - -### 4. Data Classification -- 敏感数据识别 -- 数据标签/标记 -- 自动分类 -- 基于分类的策略执行 - -### 5. Retention & Lifecycle -- 数据保留策略 -- 自动归档 -- 安全删除 -- 合规保留 - -## Cloud Myths Context - -数据治理能力是反驳"云中失去数据控制"误解的核心证据： -- 云平台提供细粒度的权限管理，企业完全控制谁能访问什么数据 -- 混合云和多云选项允许企业决定数据存储位置 -- 审计日志提供完整的访问追踪能力 - -## Cloud Provider Tools - -| Provider | Key Tools | -|----------|-----------| -| **AWS** | IAM, KMS, CloudTrail, Macie, S3 Access Points | -| **Azure** | Azure AD, Key Vault, Purview, Defender for Cloud | -| **Google Cloud** | IAM, Cloud KMS, Cloud Audit Logs, DLP API | - -## Related Concepts - -- [[cloud-computing]] — 云计算 -- [[cloud-security]] — 云安全 -- [[Data-Sovereignty]] — 数据主权 -- [[Compliance]] — 合规 -- [[Identity-and-Access-Management]] — 身份与访问管理 -- [[Cloud-Governance]] — 云治理 - -## Sources - -- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]] diff --git a/wiki/concepts/Data-Sovereignty.md b/wiki/concepts/Data-Sovereignty.md deleted file mode 100644 index 42015867..00000000 --- a/wiki/concepts/Data-Sovereignty.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: Data Sovereignty -tags: [Cloud, Compliance, Legal] ---- - -# Data Sovereignty - -**Data Sovereignty** refers to the legal concept that data is subject to the laws and regulations of the country or region where it is collected, stored, or processed. - -## Overview - -Data sovereignty has become a critical concern in cloud computing as organizations store and process data across multiple geographic locations, often across national borders. - -## Key Regulatory Frameworks - -| Region | Regulation | Key Requirements | -|--------|------------|------------------| -| EU | GDPR | Data must be stored/processed within EU or with adequate safeguards | -| China | PIPL | Critical data must stay in China | -| US | State-specific laws | Varying requirements across 50 states | -| Brazil | LGPD | Similar to GDPR for Brazilian data | -| India | DPDP Act | Data localization for certain categories | - -## Multi-Cloud as Enabler - -[[Multi-Cloud-Strategy]] enables data sovereignty compliance by: - -- Selecting providers with data centers in required regions -- Distributing data across compliant geographic locations -- Matching provider certifications to regulatory requirements -- Enabling data residency controls - -## Industry-Specific Requirements - -### Healthcare -- HIPAA (US): Patient data must have proper safeguards -- Regional health data laws may require local storage - -### Finance -- Banking regulations often require data to stay within national borders -- Payment card data (PCI-DSS) has geographic constraints - -### Government -- Classified or sensitive data often requires sovereign infrastructure -- FedRAMP, IL-4/5 requirements in US government context - -## Best Practices - -1. **Map Data Flows** — Understand where data originates, moves, and is stored -2. **Select Compliant Providers** — Verify provider certifications per region -3. **Implement Data Classification** — Identify which data has sovereignty requirements -4. **Use Regional Deployments** — Match infrastructure to data requirements -5. **Monitor Compliance** — Continuous audit of data locations - -## Related Concepts - -- [[Multi-Cloud-Strategy]] — Primary enabler for sovereignty compliance -- [[Cloud-Maturity-Model]] — Level 3+ addresses compliance concerns -- [[Cloud-Security]] — Security controls support sovereignty -- [[Compliance-Auditor]] — Agent specializing in compliance frameworks - -## Sources - -- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]] diff --git a/wiki/concepts/Dataview.md b/wiki/concepts/Dataview.md deleted file mode 100644 index 8cc65476..00000000 --- a/wiki/concepts/Dataview.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Dataview" -type: concept -tags: [tool, obsidian, plugin, query] -sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环] -last_updated: 2026-04-20 ---- - -## Aliases -- Obsidian Dataview 插件 -- DataviewJS - -## Definition -Obsidian 的社区插件，对页面 YAML frontmatter 做数据库式查询，自动生成动态表格和列表。是 LLM Wiki 的可选增强工具。 - -## LLM Wiki Usage -让 AI 在每个 Wiki 页面的 frontmatter 里写上结构化元数据（如 `type`、`date`、`tags`、`source_count`），然后用 Dataview 查询生成动态报表。 - -## Example Query -````markdown -```dataview -TABLE title, date, tags -FROM "wiki/sources" -SORT date DESC -``` -```` - -## Practical Value -- 页面少时价值有限，Wiki 规模大时（数百页面）报表价值显著 -- 老张（[[laozhang2579]]）观点："多到一定程度或者想用元数据查询方式习惯的可以考虑，我是直接用索引文件配合 Claude 的文件检索" -- 安装：设置 → 第三方插件 → 社区插件市场 → 搜索 "Dataview" → 安装并启用 - -## Connections -- [[Dataview]] ← 可选增强 → [[LLM Wiki]] -- [[Dataview]] ← 插件 → [[Obsidian]] diff --git a/wiki/concepts/DealHealthScoring.md b/wiki/concepts/DealHealthScoring.md deleted file mode 100644 index 2404a518..00000000 --- a/wiki/concepts/DealHealthScoring.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Deal Health Scoring" -type: concept -tags: [sales, deal-scoring, qualification, CRM, revenue-operations] -last_updated: 2026-04-25 ---- - -## Definition -Deal 健康评分是一个三维综合评分体系，用于判断交易是否会按预期关闭。它超越了阶段和关闭日期，提供多信号预测依据。 - -## Three Signal Dimensions - -### 1. 资格深度（Qualification Depth） -使用 [[MEDDPICC]] 框架评估： -- ≥5/8 字段填充：合格 Deal -- <5/8 字段填充（尤其晚期阶段）：**预测失误的主要来源** - -### 2. 互动强度（Engagement Intensity） -评估买家是否真正参与： -- 会议频率和最近活跃时间（晚期阶段超过 14 天无活动即为红旗） -- 利益相关者广度（$50K+ 单线程 Deal 属于高风险） -- 内容互动（提案查看、文档打开、跟进响应时间） -- 买家主动发起的活动是最强正向信号 - -### 3. 进展速度（Progression Velocity） -- Deal 在阶段间移动速度与基准相比如何 -- 停滞 Deal = 垂死 Deal -- 同一阶段停留超过 1.5 倍中位阶段时长需要明确干预或移出 Pipeline - -## Composite Score -- 资格评分：0-16 分（基于 MEDDPICC 8 维度） -- 互动评分：0-10 分（基于最近活跃度、广度、买家主动性） -- 速度评分：0-10 分（基于阶段进展与基准对比） -- **综合 Deal 健康评分：0-36 分** - -## Connections -- [[MEDDPICC]] — 提供资格深度评分 -- [[PipelineVelocity]] — 速度评分依赖 Velocity 基准数据 -- [[SalesPipelineAnalyst]] — Pipeline Analyst Agent 的 Deal 评分卡（Deal Scoring Card）工具的核心方法 -- [[SalesDealStrategist]] — Deal 策略制定依赖健康评分结果 diff --git a/wiki/concepts/Debugging-Visualization.md b/wiki/concepts/Debugging-Visualization.md deleted file mode 100644 index c93e6a08..00000000 --- a/wiki/concepts/Debugging-Visualization.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Debugging Visualization" -type: concept -tags: [spatial-computing, debugging, ux, multi-agent] -last_updated: 2026-03-05 ---- - -## Definition - -调试可视化（Debugging Visualization）——通过空间叠加将运行时追踪信息直接叠加在工作流结构之上，提供 3D 可视化的调试体验。 - -由 [[nexus-spatial-discovery]] 中 [[UX-Researcher]] 识别为 **杀手级用例（Killer Use Case）**。 - -## Why It's the Killer Use Case - -1. **Real quantified pain point**：用户花费 40% 时间通过日志检查调试 Agent 失败（[[nexus-spatial-discovery]] 用户画像数据） -2. **2D tools handle it poorly**：现有 2D 工具无法有效可视化复杂的 Agent 执行追踪 -3. **3D uniquely suited**：工作流结构（节点+连接）+ 运行时数据（时间序列/调用栈/token消耗）天然适合 3D 叠加 - -## UX Research Finding - -> "Debugging Is the Killer Use Case. Spatial overlay of runtime traces on workflow structure solves a real, quantified pain point that no 2D tool handles well." — [[UX-Researcher]] - -[[Product-Trend-Researcher]] 和 [[XR-Interface-Architect]] 均独立得出相同结论。 - -## Implementation in Nexus Spatial - -- 7 种 Agent 状态可视化：Idle / Queued / Running / Streaming / Completed / Error / Paused -- 状态通过边缘光晕、内饰动画、声音、粒子系统区分 -- LOD 节点系统：hover 显示最近 I/O，selected 显示完整追踪 - -## Key Design Insight - -空间计算对**结构性**任务（放置、连接、重排节点）增加价值，但对**参数性**任务（文本输入、配置）制造摩擦。界面必须无缝混合空间和 2D 模式——2D 面板锚定在空间位置。 - -## Related Concepts - -- [[Command-Theater-Interface]]：调试可视化的界面容器 -- [[Semantic-Zoom]]：调试视图的导航模式 -- [[SpatialAIOps]]：调试可视化是 SpatialAIOps 的核心差异化 -- [[Nexus-Spatial]]：调试可视化作为核心功能 diff --git a/wiki/concepts/DecisionFramework.md b/wiki/concepts/DecisionFramework.md deleted file mode 100644 index 52a94303..00000000 --- a/wiki/concepts/DecisionFramework.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "DecisionFramework" -type: concept -tags: [] -last_updated: 2026-04-25 ---- - -# DecisionFramework（决策框架） - -## Definition -在 [[AutomationGovernance]] 中用于评估自动化请求的四维分析体系，通过结构化打分决定是否推进自动化实施。 - -## Four Evaluation Dimensions - -### 1. Time Savings Per Month（每月时间节省） -- **问题**：节省是否重复发生且数额可观？流程频率是否足以支撑自动化开销？ -- **评估**：月度节省工时 × 平均时薪 × 12 = 年度 ROI - -### 2. Data Criticality（数据关键性） -- **问题**：是否涉及客户、财务、合同或日程记录？错误/延迟/重复/缺失的影响是什么？ -- **评估**：数据错误的潜在业务损失 × 发生概率 = 风险暴露值 - -### 3. External Dependency Risk（外部依赖风险） -- **问题**：链条中涉及多少外部 API/服务？它们是否稳定、有文档、可观测？ -- **评估**：每个外部依赖的 SLA × 失败传播范围 = 系统脆弱性评分 - -### 4. Scalability（可扩展性） -- **问题**：1x 到 100x 时，重试、去重、限流是否仍能正常工作？异常处理在量级下是否可管理？ -- **评估**：峰值负载测试结果 → 是否需要架构调整 - -## Five Verdicts - -| 裁决 | 条件 | 描述 | -|------|------|------| -| **APPROVE** | 强价值 + 可控风险 + 可维护架构 | 直接推进生产实施 | -| **APPROVE AS PILOT** | 价值可期 + 有限试点 | 受控范围内验证后再决策 | -| **PARTIAL AUTOMATION ONLY** | 仅自动化安全段落 | 保留人工检查点，高风险环节人工介入 | -| **DEFER** | 流程不成熟/价值不明/依赖不稳定 | 等待条件成熟 | -| **REJECT** | 经济价值弱或不可接受的运营/合规风险 | 不实施 | - -## Non-Negotiable Rules -- 不得仅因技术可行就批准自动化 -- 不得在未经明确批准的情况下直接修改关键生产流程 -- 简单健壮优于精巧脆弱 -- 每个推荐必须包含降级方案和责任人 -- 无文档和测试证据不得标记为"完成" - -## Related Concepts -- [[AutomationGovernance]]：决策框架所属的治理体系 -- [[ReliabilityBaseline]]：通过评估后必须满足的可靠性标准 -- [[N8nWorkflowStandard]]：批准实施后的标准工作流模板 - -## Sources -- [[automation-governance-architect]]（primary） diff --git a/wiki/concepts/Default-Bias.md b/wiki/concepts/Default-Bias.md deleted file mode 100644 index 740e9c21..00000000 --- a/wiki/concepts/Default-Bias.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "Default Bias" -type: concept -tags: [] -sources: ["product-behavioral-nudge-engine"] -last_updated: 2026-05-01 ---- - -## Definition - -Default Bias（默认偏见）是一种心理现象：人们倾向于接受预设选项，即使提供退出选项也有很高概率保持默认状态。在软件交互设计中，通过预先填充行动草案并以「确认/修改」框架呈现，可大幅降低用户的决策摩擦和行动阻力。 - -## Mechanism - -- **核心策略**：不要问用户「要不要做」，而是问「这样做好吗」 -- **行为公式**：「已起草 + 一键确认」= 最小阻力路径 -- **典型应用**：邮件回复草稿、通知设置、文档模板确认、支付流程 -- **道德边界**：必须提供真实的「opt-out」退出选项，不可隐藏或误导 - -## Example - -> "I've drafted a thank-you reply for this 5-star review. Should I send it, or do you want to edit?" - -这个示例展示：系统不仅起草了回复，还主动推进了决策——用户只需点击「发送」即可完成，否则才需要介入修改。 - -## Why It Works - -1. **减少认知负担**：用户无需从零开始组织语言 -2. **消除启动摩擦**：最大的阻力在于「开始」，草案消除了这一步 -3. **利用惰性**：在低介入成本时，用户倾向于保持默认状态 -4. **正向锚定**：用户面对自己的内容比面对空白更有动力编辑 - -## Related Concepts - -- [[Cognitive Load Reduction]] — 默认偏见是降低认知负荷的核心手段 -- [[Nudge Theory]] — 默认选项是 Nudge 的经典应用 -- [[Friction Reduction]] — 减少用户行动阻力的更广泛策略 - -## Risks & Ethical Considerations - -- 过度使用可能引发用户「被操控」感，损害信任 -- 必须提供真实退出选项，不可暗设陷阱 -- 高风险决策（财务、法律）场景应谨慎使用 - -## Connections - -- [[Behavioral Nudge Engine]] — 核心应用场景：任务推进、通知确认、内容发布 diff --git a/wiki/concepts/Defect-Prediction.md b/wiki/concepts/Defect-Prediction.md deleted file mode 100644 index c18f28c2..00000000 --- a/wiki/concepts/Defect-Prediction.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Defect Prediction" -type: concept -tags: [testing, machine-learning, quality] -sources: [testing-test-results-analyzer] -last_updated: 2026-04-28 ---- - -## Definition - -缺陷预测——使用机器学习模型基于代码指标和历史缺陷数据，预测哪些代码区域最可能包含缺陷，指导测试资源的定向投入。 - -## Approach - -### Feature Engineering (from TestResultsAnalyzer) - -```python -from sklearn.ensemble import RandomForestClassifier -from sklearn.model_selection import train_test_split - -# 特征：代码指标 -features = extract_code_metrics() # 圈复杂度、代码行数、变更频率等 -historical_defects = load_historical_defect_data() # 历史缺陷标签 - -# 训练/测试分割 -X_train, X_test, y_train, y_test = train_test_split( - features, historical_defects, test_size=0.2, random_state=42 -) - -# Random Forest 分类器 -model = RandomForestClassifier(n_estimators=100, random_state=42) -model.fit(X_train, y_train) - -# 预测 + 置信度 + 特征重要性 -predictions = model.predict_proba(features) -feature_importance = model.feature_importances_ -accuracy = model.score(X_test, y_test) -``` - -### Key Metrics - -- **Prediction Accuracy**：模型在测试集上的准确率，目标 ≥ 85%。 -- **Feature Importance**：哪些代码指标（圈复杂度、变更频率、代码行数等）对缺陷预测最有预测力。 -- **Confidence Score**：每个预测结果附带置信度评分。 - -## Connections - -- [[Statistical-Analysis]]：模型验证需统计显著性检验。 -- [[Test-Coverage-Analysis]]：预测的高风险区域优先增加测试覆盖率。 -- [[Release-Readiness-Assessment]]：缺陷预测结果纳入整体发布就绪度评估。 -- [[Quality-Metrics]]：缺陷密度是预测模型的目标变量。 diff --git a/wiki/concepts/Defense-Mechanisms.md b/wiki/concepts/Defense-Mechanisms.md deleted file mode 100644 index edc4021f..00000000 --- a/wiki/concepts/Defense-Mechanisms.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Defense Mechanisms" -type: concept -tags: [] -sources: ["academic-psychologist"] -last_updated: 2026-04-20 ---- - -## Definition - -防御机制（Defense Mechanisms）是精神分析理论中的概念——无意识心理过程帮助个体应对焦虑和保护自我。**George Vaillant** 建立了最广泛使用的分层框架： - -### Vaillant 四层防御机制层级 - -| 层级 | 类型 | 代表机制 | -|------|------|---------| -| **成熟型（Mature）** | 最健康的适应方式 | 幽默、利他主义、升华、预期 | -| **神经症型（Neurotic）** | 情感问题的常见方式 | 理智化、压抑、反向形成、解离 | -| **不成熟型（Immature）** | 严重压力的常见反应 | 投射、被动攻击、妄想、躯体化 | -| **精神病性（Psychotic）** | 最原始的防御 | 否认、扭曲、分裂 | - -## Key References - -- **George Vaillant**：通过长达40年的追踪研究（Harvard Study of Adult Development）实证验证防御机制层级 - -## Common Defense Mechanisms in Character Design - -| 机制 | 定义 | 角色行为表现 | -|------|------|------------| -| **理智化（Intellectualization）** | 用理性代替情感 | 情感淡漠地描述创伤事件 | -| **压抑（Repression）** | 无意识忘记痛苦记忆 | 童年记忆空白，关键事件"不记得了" | -| **反向形成（Reaction Formation）** | 行为与真实感受相反 | 极度热情掩盖深层敌意 | -| **投射（Projection）** | 将自身不可接受特质归于他人 | "是他们在针对我" | -| **幽默（Humor）** | 用笑声处理痛苦 | 关键时刻讲笑话缓解紧张 | -| **升华（Sublimation）** | 将不可接受冲动转化为社会认可活动 | 拳击手将愤怒转化为竞技体育 | - -## Applications in Character Design - -- **主要防御机制**决定角色正常状态下的心理运作方式 -- **压力下防御机制**揭示角色在崩溃边缘的行为模式（退化/躯体化/妄想） -- 识别防御机制可以揭示角色**核心创伤**（防御机制越原始，创伤越早期） - -## Limitations - -- Vaillant 研究样本偏向白人男性 Harvard 校友 -- 防御机制是"程度"问题而非"类型"问题 -- 不能作为诊断工具 - -## Connections - -- [[Psychological-Profile]]（Defense Mechanisms 是心理画像核心组成部分） -- [[Attachment-Theory]]（不安全依恋与不成熟防御机制相关） -- [[Cognitive-Distortions]]（部分认知扭曲是防御机制的认知层面表现） -- [[Trauma-Informed-Analysis]]（原始防御机制常见于复杂性创伤） diff --git a/wiki/concepts/Defense-in-Depth.md b/wiki/concepts/Defense-in-Depth.md deleted file mode 100644 index aeca9617..00000000 --- a/wiki/concepts/Defense-in-Depth.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Defense-in-Depth" -type: concept -tags: [security, devsecops, ai-agents, risk-management] -date: 2026-04-22 ---- - -## Definition -Defense-in-Depth（纵深防御）是一种信息安全策略：通过叠加多层独立的安全控制措施，确保任何单一安全措施的失效不会导致系统完全沦陷。每层防线相互补足，即使攻击者突破一层，仍面临其他层的阻挡。 - -## In AI Agent Security Context -在 [[self-healing-home-server]] 中，纵深防御针对 AI Agent 的特殊风险构建（特别是 [[OpenClaw]] 的 [[TruffleHog]] 第1天 API Key 泄露教训）： - -### 多层防御架构 -``` -Layer 1: Pre-push hooks (TruffleHog) - ↓ 阻止内嵌 secrets 的 commit -Layer 2: Local-first Git (私有 Gitea) - ↓ 所有代码先到私有仓库 -Layer 3: CI Scanning Pipeline - ↓ TruffleHog + 依赖漏洞扫描 -Layer 4: Human Review - ↓ 必须人工审核 main 分支 -Layer 5: 1Password AI Vault - ↓ Agent 只能读取专用 vault 中的凭证 -Layer 6: Network Segmentation - ↓ 敏感服务网络隔离 -Layer 7: Daily Security Audit - ↓ 每日自动检查特权容器/过度权限 -``` - -## Key Principle -> "Never trust a single security control." — 纵深防御的核心哲学 - -AI Agent 的风险在于它们**缺乏人类的"常识性危险感知"**——Agent 会在代码中直接写入 API Key而不产生"直觉性警告"。因此，安全防线必须设计为即使 Agent 无意识地绕过一层，仍有多层阻止最终损害。 - -## Connections -- [[TruffleHog]] — 第1层防线：pre-push secrets 检测 -- [[Local-first Git]] — 第2-3层防线：私有仓库 + CI 扫描 -- [[1Password]] — 第5层防线：凭证安全管理 -- [[OpenClaw]] — 需要纵深防御保护的 Agent 平台 -- [[Agentic AI]] — 纵深防御是对 AI Agent 固有风险的主动应对 diff --git a/wiki/concepts/Defuddle.md b/wiki/concepts/Defuddle.md deleted file mode 100644 index ea35a2a6..00000000 --- a/wiki/concepts/Defuddle.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Defuddle" -type: concept -tags: [obsidian, skills, web-scraping] -last_updated: 2026-04-21 ---- - -## Definition -Defuddle 是 kepano（Obsidian CEO）发布的网页内容清洗工具，专门将杂乱的网页 HTML 转换为纯净的 Markdown 格式，通过剔除广告、导航栏、侧边栏等干扰元素，保留核心正文内容。 - -## Key Features -- **纯净输出**：自动删除导航条、侧边栏和广告，只保留干净的 Markdown 内容 -- **Token 节省**：大幅减少 AI 处理网页内容时的 Token 消耗 -- **YouTube 支持**：最新版本支持 YouTube 视频链接，通过 YouTube 官方 API 获取字幕（而非 yt-dlp） -- **AI 友好**：输出格式专为 AI 阅读和分析优化 - -## Usage -```text -提取这个网页的正文，转成干净的 Markdown 格式：[URL] -``` - -## Requirements -- Node.js 运行环境 -- 全局安装：`npm install -g defuddle` - -## Best Fit -- 标准 HTML 网页（新闻、博客、官方文档） -- 不适合：需要登录的页面、纯动态渲染的 SPA 应用 - -## Connections -- [[kepano]] — Defuddle 的发布者 -- [[obsidian-必装-skills]] — 来源文档 -- [[网页内容清洗]] — 同类工具概念 diff --git a/wiki/concepts/Delegation-Chain.md b/wiki/concepts/Delegation-Chain.md deleted file mode 100644 index 14ad6a75..00000000 --- a/wiki/concepts/Delegation-Chain.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Delegation-Chain" -type: concept -tags: [authorization, delegation, multi-hop] -sources: [agentic-identity-trust.md] -last_updated: 2026-04-25 ---- - -## Definition - -Delegation-Chain（委托链）是一种多跳授权链机制——当 Agent A 授权 Agent B 代表其行事，Agent B 可以进一步授权 Agent C，但每一跳都必须满足：签名有效 + 作用域不扩大 + 时间未过期。 - -## Chain Structure - -``` -Agent A ──signs──> Agent B (scope: trade.execute) - │ - └──signs──> Agent C (scope: trade.execute, audit.write) ❌ scope_escalation -``` - -## Verification Rules - -每条委托链必须通过三项验证： -1. **签名有效性**：当前 Agent 的签名必须可被其公钥验证 -2. **作用域不扩大**：本跳授权的作用域不得宽于上一跳 -3. **时间有效性**：委托链中任意节点过期，则整链失效 - -## Fail-Closed Behavior - -- 委托链的任意链节断裂 → **整链无效** -- 委托链的任意节点过期 → **整链无效** -- 无法验证某节点签名 → **整链无效** - -## Relationships -- [[Zero-Trust]]：Delegation-Chain 是 Zero-Trust 授权验证的核心机制 -- [[Fail-Closed]]：委托链验证采用 Fail-Closed 策略（任意断裂则整链失效） -- [[Peer-Verification]]：Peer-Verification 协议在有委托时必须验证 Delegation-Chain - -## Sources -- [[agentic-identity-trust.md]] diff --git a/wiki/concepts/Delivery-Traceability.md b/wiki/concepts/Delivery-Traceability.md deleted file mode 100644 index 52af9153..00000000 --- a/wiki/concepts/Delivery-Traceability.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "Delivery Traceability" -type: concept -tags: ["delivery", "traceability", "project-management", "audit"] -last_updated: 2026-04-25 ---- - -## Definition - -Delivery Traceability（交付可追溯性）是指从业务需求到代码发布全链路的可重建、可审计交付记录体系，使团队能在几分钟内重建"从需求到已发布代码"的完整路径，而非花费数小时。 - -## The Five Links - -| 环节 | 关键问题 | 可追溯性价值 | -|------|----------|------------| -| **Jira Task** | 这个需求从哪里来？ | 需求来源记录 | -| **Branch** | 这段代码在哪个隔离环境开发？ | 隔离性保证 | -| **Commit** | 这个改动具体做了什么？ | 原子粒度的变更记录 | -| **Pull Request** | 谁审查了这次变更？ | Review 责任链 | -| **Release** | 这个功能何时上线？ | 发布时间线记录 | - -## Two Modes of Traceability - -### Prospective Traceability（前向追溯） -从 Jira 任务 → 代码 → 发布，确保需求被完整实现。用于：进度跟踪、变更影响分析。 - -### Retrospective Traceability（回溯追溯） -从已发布代码 → Jira 任务 → 需求来源，用于：事故溯源、审计合规、回滚决策。 - -## Traceability vs. Bureaucracy - -[[Jira Workflow Steward]] 的核心观点：**Jira-linked commits 是质量工具，而非合规打勾**。 - -当开发者理解可追溯性的实际价值（review 加速、发布说明自动生成、事故 10 分钟内定位）时，遵循规范的阻力会显著降低。 - -## Success Metrics - -- 从 Jira + Git 历史重建发布说明：< 10 分钟 -- 定位引入特定行为的 ticket 和 commit：< 5 分钟 -- 回滚操作：原子 commit 使回滚低风险 - -## Relationship to GitOps - -Delivery Traceability 关注业务需求到代码交付的全链路，[[GitOps]] 关注基础设施声明到部署的自动化调和。两者共同构成完整的软件交付可追溯性体系。 - -## Sources -- [[project-management-jira-workflow-steward]] diff --git a/wiki/concepts/Demand-Management.md b/wiki/concepts/Demand-Management.md deleted file mode 100644 index 4930aeae..00000000 --- a/wiki/concepts/Demand-Management.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Demand Management -type: concept -tags: [ITIL, Cloud-Governance, Process] -sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16] ---- - -# Demand Management - -**需求管理（Demand Management）** 是平衡需求与可用容量的必要手段，是 ITIL 服务过渡阶段的关键活动。 - -## Overview - -需求管理在云转型过程中的核心价值： -- 平衡业务单元需求与可用云资源容量 -- 通过标准化流程确保公平的资源分配 -- 支持端到端需求履约流程的透明化 - -## Key Processes - -| 阶段 | 活动 | -|------|------| -| 需求提交 | 业务单元通过 Octane/Qixi 提交需求 | -| 需求评审 | ADM/ITOM 需求规划会议评估 | -| 需求审批 | Oli Workflow 三阶段审批 | -| 需求履约 | SMACs 嵌入式自动化履约 | - -## Goals - -- **80% 自助服务**：业务单元能够自行识别和请求所需服务 -- **自动化履约**：机器完成机器能完成的工作 -- **透明管道**：需求处理流程全程可见 - -## Related Concepts - -- [[ITIL-Service-Management]] — ITIL 框架 -- [[Oli-Workflow]] — 支出审批工作流 -- [[Product-Backlog]] — 产品待办列表 -- [[SMACs]] — 技术栈组合 -- [[FinOps]] — 云财务运营 - -## Related Entities - -- [[Tom-Bice]] — FinOps 团队负责人 -- [[FPNA-Team]] — 预算验证团队 -- [[Octane]] — 需求管理平台 -- [[Qixi]] — 需求提交入口 - -## Sources - -- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] diff --git a/wiki/concepts/Demo-Engineering.md b/wiki/concepts/Demo-Engineering.md deleted file mode 100644 index 965f9691..00000000 --- a/wiki/concepts/Demo-Engineering.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Demo Engineering" -type: concept -tags: [sales, pre-sales, demonstration, b2b] -last_updated: 2026-04-25 ---- - -## Definition -Demo Engineering 是以影响力为导向的 B2B 售前演示设计方法论——先量化买家痛点，再展示产品能力，最后以客户案例收尾，将每一次演示转化为明确的商业叙事，而非功能清单罗列。 - -## Core Principles - -### Lead With Impact, Not Features -1. **量化问题**：展示产品前，先用发现阶段收集的具体数据重新陈述买家痛点 -2. **先展示结果**：先呈现最终仪表盘、报告、工作流结果，再解释实现原理 -3. **逆向讲解**：等买家对结果产生反应（"这正是我们需要的"）后再回溯配置和架构 -4. **以证明收尾**：以客户参考案例或基准数据结束——镜像买家处境的具体证据 - -### Tailored Demos Are Non-Negotiable -- 演示前必须将买家的三大痛点映射到具体产品能力 -- 识别受众类型：技术评估者需要架构和 API 深度，业务决策者需要成果和时间线 -- 准备两条路径：计划叙事 + 灵活深度探索（应对"能展示一下底层实现吗"） -- 使用买家的术语、数据模型和流程语言，而非产品词汇 - -### The Aha Moment -每个演示必须产生至少一个买家说出或明显想到"这正是我们需要的"的时刻。如果演示结束那一刻未出现，演示就失败了。 - -## Demo Structure Template -```markdown -# Demo: [Account Name] - -## Pre-Demo: Pain Quantification -- [从发现阶段获取的具体数据] - -## Narrative Arc -1. [开场：重述痛点] -2. [中段：展示核心能力 + 痛点解决] -3. [高潮：瞄准买家的"Aha Moment"能力] -4. [收尾：客户参考案例] - -## Aha Moment Target -- [具体哪个能力对当前受众最具冲击力] - -## Risk Areas -- [需要准备异议处理的地方] -``` - -## Connections -- [[POC-Scoping]] — Demo Engineering 是 POC 执行的前置铺垫 -- [[FIA-Framework]] — Demo Engineering 输出的成果是 FIA 中 "Act" 环节的重要组成 -- [[SalesEngineer]] — Demo Engineering 是 Sales Engineer 的核心能力之一 -- [[AhaMoment]] — 是 Demo Engineering 成功的核心衡量标准 - -## Contradictions -- 与 [[SalesDiscoveryCoach]] 在发现阶段定位上存在张力：Demo Engineering 期望在发现阶段收集到足够深的痛点数据，但 Discovery Coach 更强调以业务语言建立信任而非过早进入技术细节 diff --git a/wiki/concepts/Dengbao-2.0.md b/wiki/concepts/Dengbao-2.0.md deleted file mode 100644 index ad66ba76..00000000 --- a/wiki/concepts/Dengbao-2.0.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Dengbao 2.0" -type: concept -tags: [China, cybersecurity, compliance, ToG, government] -sources: [government-digital-presales-consultant] -last_updated: 2026-04-25 ---- - -# Dengbao 2.0（网络安全等级保护） - -网络安全等级保护制度（Classified Protection of Cybersecurity），是中国政府强制性的网络安全合规框架，要求所有政府信息系统按照安全等级进行保护和评估。 - -## 基本概念 - -- **等级划分**：1级（自主保护）→ 2级（指导保护）→ 3级（监督保护）→ 4级（强制保护）→ 5级（专控保护） -- **政府系统要求**：通常要求**等保三级**，核心系统可能要求**等保四级** -- **强制性质**：等保不是加分项，而是**投标入围的强制性前置条件** - -## 等保三级核心控制域 - -| 安全域 | 控制要求 | Proposed Measure | -|--------|---------|-----------------| -| 安全通信网络 | 网络架构安全 | 安全域划分、VLAN 隔离 | -| 安全通信网络 | 传输安全 | SM4 加密传输，国密 VPN 网关 | -| 安全边界 | 边界防护 | 下一代防火墙访问控制策略 | -| 安全边界 | 入侵防范 | IDS/IPS 部署 | -| 安全计算环境 | 身份鉴别 | 双因素认证，国密 CA + 动态令牌 | -| 安全计算环境 | 数据完整性 | SM3 校验，国密中间件 | -| 安全计算环境 | 数据备份恢复 | 本地 + 异地备份 | -| 安全管理中心 | 集中管理 | 统一安全管理平台，SIEM/SOC | -| 安全管理中心 | 审计管理 | 日志集中采集分析 | - -## 实施时间线 - -- **关键里程碑**：系统上线前必须完成等保评估 -- **整改周期**：通常需要 **2-3 个月**进行整改 -- **评估流程**：系统建设 → 差距分析 → 整改加固 → 正式评估 → 备案 - -## 与信创的关系 - -等保三级与[[Xinchuang]]（信创）结合是政府项目的标准合规要求： -- 信创适配产品（国产 CPU/OS/数据库/中间件）需提供兼容测试报告 -- 等保三级安全架构设计需在信创平台上重新验证 -- 两者共同构成政府 IT 项目投标的技术门槛 - -## Aliases -- 网络安全等级保护 -- 等保 2.0 -- Classified Protection of Cybersecurity -- Wangluo Anquan Dengji Baohu diff --git a/wiki/concepts/Dependency-Dashboard.md b/wiki/concepts/Dependency-Dashboard.md deleted file mode 100644 index f4059d13..00000000 --- a/wiki/concepts/Dependency-Dashboard.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Dependency Dashboard" -type: concept -tags: - - Renovatebot - - Dependency-Update - - GitOps -last_updated: 2026-05-11 ---- - -# Dependency Dashboard - -## Definition -Renovate Bot 在 GitHub 仓库中自动创建的一个 GitHub Issue，用于汇总所有依赖状态、待处理的 Pull Request 以及更新选项，提供全局依赖状态视角。 - -## Core Functions -- 汇总所有检测到的依赖项及其当前版本 -- 列出所有待处理/已打开的 Pull Request -- 提供批量合并、更新策略配置等交互选项 -- 作为单一入口，方便团队在一个界面内查看和管理所有依赖更新 - -## Related Concepts -- [[Renovate-Bot]] — 依赖 Dashboard 由 Renovate Bot 自动生成 -- [[Dependency-Management]] — Dashboard 是依赖管理的可视化工具 -- [[Semantic-Versioning]] — Dashboard 中显示的版本号遵循 SemVer 规范 - -## Related Sources -- [[ctp-topic-15-working-with-renovatebot]] - -## Aliases -- Renovate Dashboard -- Dependency Issue diff --git a/wiki/concepts/Dependency-Management.md b/wiki/concepts/Dependency-Management.md deleted file mode 100644 index 305c11f5..00000000 --- a/wiki/concepts/Dependency-Management.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Dependency Management" -type: concept -tags: - - DevOps - - Dependency-Update - - IaC -last_updated: 2026-04-14 ---- - -## Definition -依赖管理是指对项目中引用的外部库、模块、镜像或工具的版本进行跟踪、更新和维护的过程。在云原生和 IaC 场景下，依赖项涵盖 Docker 基础镜像、Maven 依赖、Terraform 模块、Helm Charts、pre-commit 插件等。 - -## Key Challenges -- 手动更新版本号耗时耗力且极易滞后 -- 依赖项数量庞大时，人工追踪几乎不可能 -- 遗漏安全补丁更新导致漏洞积累 -- 不同环境（开发/测试/生产）配置不一致 - -## Solutions -- **Renovate Bot**：自动化扫描并发起 Pull Request 更新依赖版本 -- **Dependabot**：GitHub 原生的依赖更新工具 -- **Renovate**：支持更广泛的技术栈（Terraform、Docker、Kubernetes 等） - -## Related Concepts -- [[Renovate-Bot]] — 依赖管理自动化工具 -- [[Semantic-Versioning]] — 依赖版本控制规则 -- [[GitOps]] — 依赖管理是 GitOps 实践的重要组成部分 - -## Related Sources -- [[ctp-topic-15-working-with-renovatebot]] diff --git a/wiki/concepts/Deployment-Automation.md b/wiki/concepts/Deployment-Automation.md deleted file mode 100644 index 04e78944..00000000 --- a/wiki/concepts/Deployment-Automation.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: "Deployment Automation" -tags: - - devops - - cicd - - automation - - ai -created: 2026-04-25 ---- - -# Deployment Automation - -## Definition - -Deployment Automation 是通过自动化工具和 AI 代理实现软件部署的**全流程自动化**（构建 → 测试 → 发布 → 回滚）。Agentic AI 作为 Release Manager，自动执行部署策略（蓝绿/金丝雀）和回滚决策。 - -## Agentic AI 作为 Release Manager - -``` -传统 Release Manager: -人工决策 → 发布窗口 → 人工监控 → 人工回滚（可能延迟数小时） - -Agentic AI Release Manager: -实时分析 → 自动决策 → 持续发布 → 毫秒级自动回滚 -``` - -### 核心职责 - -| 职责 | 传统方式 | AI Release Manager | -|------|---------|-------------------| -| Feature Flag 测试 | 人工配置 | AI 自动分析指标 + 动态调整 | -| 部署策略选择 | 人工决策 | AI 基于流量/错误率选择 | -| 回滚触发 | 人工判断（延迟高） | AI 毫秒级自动触发 | -| 部署后验证 | 人工检查 | AI 持续监控 + 自动验证 | - -### 部署策略 - -- **Blue/Green**: 两套环境，AI 监控 + 自动切换 -- **Canary**: 灰度流量，AI 动态调整流量比例 -- **Rolling**: 滚动更新，AI 监控 + 自动暂停/回滚 - -## 与 [[CI/CD Pipeline]] 的关系 - -Agentic AI 增强 [[CI/CD Pipeline]] 的关键阶段： - -```python -CI_CD_Stages = { - "Build": "CI Server (Jenkins/GitHub Actions)", # 保持不变 - "Test": "AI: 自动缺陷预测 + 智能测试选择", - "Deploy": "AI Release Manager ←", # ← 本页 - "Monitor": "AI: 实时监控 + 自动回滚", - "Verify": "AI: 自动回归验证" -} -``` - -## 示例 - -> An AI agent detects that a new microservice deployment is causing latency issues: -> - Error rate spikes from 0.1% to 2.3% within 5 minutes -> - AI automatically rolls back the changes -> - AI generates fix suggestion: "Connection pool misconfiguration detected" -> - AI submits ticket with root cause analysis - -## Related Concepts - -- [[CI/CD Pipeline]] — Deployment Automation 的基础 -- [[Self-Healing Systems]] — 自动回滚是 Self-Healing 的体现 -- [[DORA Metrics]] — Deployment Automation 直接改善 Deployment Frequency 和 Change Failure Rate -- [[Blue-Green Deployment]] — 具体部署策略之一 -- [[Canary Deployment]] — 具体部署策略之一 - -## Related Sources - -- [[how-agentic-ai-can-help-for-cloud-devops]] -- [[cloud-devop-maturity-guideline]] diff --git a/wiki/concepts/Deployment-vs-Release.md b/wiki/concepts/Deployment-vs-Release.md deleted file mode 100644 index 8016c011..00000000 --- a/wiki/concepts/Deployment-vs-Release.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: "Deployment vs Release (部署与发布分离)" -tags: [devops, continuous-delivery, feature-management, release-management] -aliases: [Decoupled Deployment and Release] -created: 2026-04-25 ---- - -# Deployment vs Release (部署与发布分离) - -**Deployment vs. Release** 是 [[Feature Flag]] 实现的核心理念：代码**部署**（Deploy）到生产环境，与功能对用户**可见**（Release），是两个独立的事件。 - -## Definition - -> "Traditional deployments are all-or-nothing: you push code and everyone gets it immediately. This is why deployments are scary and why teams deploy at 2 AM 'just in case.'" - -> "Deploy whenever you want, release when you're ready." - -## Aliases -- Decoupled Deployment and Release -- 部署发布分离 - -## 核心对比 - -| 维度 | 传统方式（部署=发布） | Feature Flag（部署≠发布） | -|------|---------------------|--------------------------| -| 代码到达生产 | 与用户可见同步 | 提前到达，用户不可见 | -| 回滚能力 | 需要重新部署 | 配置变更，秒级 | -| 发布时机 | 必须与部署同步 | 任意时刻可发布 | -| 团队压力 | 2AM 部署"以防万一" | 白天从容发布 | -| 实验能力 | 低（全量或无） | 高（灰度、可控放量） | - -## 生命周期对比 - -### 传统方式 - -``` -开发 → 测试 → 合并 → 部署 → 发布（全量） - ↑ - 部署=发布 -``` - -### Feature Flag 方式 - -``` -开发 → 测试 → 合并 → 部署 → 发布控制 → 渐进放量 - ↑ ↑ - 代码到达 用户可见 - 生产环境 由开关控制 -``` - -## 关键价值 - -### 1. 降低部署风险 -> "Feature flags change this. You can deploy code to production without releasing it to users." - -代码可以在生产环境中就绪，但功能对用户保持隐藏，直到团队确认质量。 - -### 2. 加速交付 -团队不再需要等待"完美时机"发布功能。代码就绪即可部署，功能发布由业务决定。 - -### 3. 赋能团队 -- 产品：随时决定发布节奏 -- 工程：随时部署，无需等待发布窗口 -- 运营：渐进放量，数据驱动决策 - -### 4. 重新定义 RTO -当部署≠发布时，恢复（Rollback）不再是回滚部署，而是关闭 Feature Flag。 - -## 与 [[CI-CD-Pipeline]] 的关系 - -部署与发布的分离重构了 CI/CD 流程： - -| 阶段 | 传统 CI/CD | Decoupled CI/CD | -|------|-----------|-----------------| -| Build | 构建产物 | 构建产物 | -| Test | 单元/集成测试 | 单元/集成测试 | -| Deploy | 部署到 prod | 部署到 prod（用户不可见） | -| Release | — | Feature Flag 控制 | -| Monitor | 部署后监控 | 渐进放量期间监控 | -| Rollback | 重新部署旧版本 | 关闭 Feature Flag | - -## 风险模型转变 - -| 维度 | 传统模型 | Decoupled 模型 | -|------|----------|----------------| -| 风险集中点 | 部署时刻 | 功能发布时刻 | -| 风险暴露范围 | 全量用户 | 当前放量比例 | -| 应急响应 | 小时级回滚 | 秒级开关 | -| 团队心态 | 防御性（害怕部署） | 进攻性（敢于实验） | - -## Related Concepts - -- [[Feature Flag]] — 实现部署与发布分离的核心机制 -- [[CI-CD-Pipeline]] — Decoupled Deployment 是现代 CI/CD 的重要理念 -- [[Progressive Rollout]] — 部署与发布分离使渐进放量成为可能 -- [[Kill Switch]] — 发布控制权的极端体现（紧急关闭） -- [[RTO]] — 部署与发布分离将 RTO 从部署回滚转向配置变更 -- [[Micro-Recovery]] — 部署与发布分离使 feature 级别恢复成为可能 - -## Sources - -- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/concepts/Design-Thinking.md b/wiki/concepts/Design-Thinking.md deleted file mode 100644 index 79b43546..00000000 --- a/wiki/concepts/Design-Thinking.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Design-Thinking" -type: concept -tags: [UX, Human-Centered, Innovation, Process-Improvement] -sources: [testing-workflow-optimizer, Human-Centered-Design] -last_updated: 2026-04-21 ---- - -# Design-Thinking - -设计思维——一种以人为中心的创新方法论，通过共情（Empathize）、定义（Define）、构思（Ideate）、原型（Prototype）和测试（Test）五个阶段的迭代循环，解决复杂问题并创造有意义的解决方案。 - -## Aliases -- 设计思维 -- Design Thinking Process -- 以人为本的创新方法 - -## Five Stages - -1. **Empathize（共情）**——深入理解用户的需求、感受、动机和行为。通过观察、访谈和沉浸式体验获取洞察。 -2. **Define（定义）**——综合共情阶段的洞察，明确要解决的核心问题（Point of View / How Might We）。 -3. **Ideate（构思）**——头脑风暴，生成大量创意和可能的解决方案，不评判，鼓励疯狂的点子。 -4. **Prototype（原型）**——用低成本、快速的方式制作解决方案的物理或数字原型。 -5. **Test（测试）**——用真实用户验证原型，收集反馈，迭代改进。 - -## Core Principles -- **以人为中心**：始终从人的真实需求出发，而非从技术可能出发 -- **迭代而非线性**：允许反复回到前面的阶段 -- **跨职能协作**：打破 silos，融合不同背景的视角 -- **快速失败、快速学习**：通过小规模实验快速获取认知 - -## Connection to Human-Centered-Design -Design Thinking 是 [[Human-Centered-Design]] 的系统性方法论框架——HCD 提供哲学和价值观，Design Thinking 提供可操作的流程。 - -## Connection to Workflow Optimization -[[testing-workflow-optimizer]] 将 Design Thinking 应用于流程改进： -- **Empathize** → 理解员工（流程执行者）的真实痛点 -- **Define** → 明确效率瓶颈和优化目标 -- **Ideate** → 构思多种可能的优化方案 -- **Prototype** → 小规模试点验证优化方案 -- **Test** → 收集反馈，迭代改进 - -## Connections -- [[Human-Centered-Design]] — 哲学基础 -- [[Lean]] — 互补：Design Thinking 侧重创新发现，Lean 侧重效率优化 -- [[testing-workflow-optimizer]] — 应用于流程改进的方法论工具 diff --git a/wiki/concepts/Design-to-Code-Workflow.md b/wiki/concepts/Design-to-Code-Workflow.md deleted file mode 100644 index 529894ab..00000000 --- a/wiki/concepts/Design-to-Code-Workflow.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Design-to-Code Workflow" -type: concept -tags: [] -last_updated: 2025-12-30 ---- - -## Definition - -Design-to-Code Workflow（设计到代码工作流）是一种递进式 AI 辅助开发方法，通过从高层次的抽象描述逐步细化为可执行代码，实现人机协作的编程实践。 - -## Core Principles - -### 三阶段递进 -1. **设计文档**：详细描述需求和架构 -2. **伪代码**：Service 层具体逻辑用伪代码写明 -3. **代码**：AI 根据伪代码直接生成可执行代码 - -### 工作流程 -``` -需求文档 → 伪代码(含Service层逻辑) → AI直出代码 → 另一AI review → 跑测试用例 → AI自动commit+push -``` - -## Key Benefits - -- **减少迭代次数**：详细伪代码使 AI 一次直出成为可能 -- **质量保证**：双 AI 协作（生成+review）确保代码质量 -- **可追溯**：设计文档保留了完整的决策过程 -- **降低认知负担**：开发者无需记忆所有实现细节 - -## Related Concepts - -- [[Vibe Coding]]：整体方法论背景 -- [[Multi-AI Review]]：双人编程模式 -- [[Verification-First Engineering]]：验证优先原则 - -## Sources - -- [[vibe-coding经验收集]] diff --git a/wiki/concepts/Dev-QA-Loop.md b/wiki/concepts/Dev-QA-Loop.md deleted file mode 100644 index 3cb0311e..00000000 --- a/wiki/concepts/Dev-QA-Loop.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Dev↔QA Loop" -type: concept -tags: [multi-agent, quality, devops, nexus] -sources: [executive-brief, quickstart, workflow-startup-mvp] -last_updated: 2026-05-01 -aliases: - - Dev QA Loop - - Build-Test Loop - - Dev-Test-Retry Loop ---- - -## Definition - -Dev↔QA 循环（Dev↔QA Loop）—— 构建→测试→通过/失败→重试的持续质量循环，最多允许 3 次迭代；FAIL 时触发修复重试，PASS 时推进到下一阶段。 - -## Mechanism - -``` -开发 Agent 交付实现 - ↓ -QA Agent 执行质量验证 - ↓ -┌──────────────────────────┐ -│ PASS? │ -├──────────┬───────────────┤ -│ 是 │ 否 │ -│ ↓ │ ↓ │ -│ 推进下一阶段 │ 进入修复循环 │ -│ │ (重试 N/3) │ -└──────────┴───────────────┘ -``` - -## Quantified Impact - -- **集成前缺陷捕获率**：95% —— 大部分缺陷在 Dev↔QA 循环中被捕获，而非等到集成阶段 -- **Phase 4 硬化时间减少**：50% —— 持续质量循环优于端到端测试 -- **最大重试次数**：3 次 —— 超过 3 次 FAIL 触发升级/上报机制 - -## Role in NEXUS - -Dev↔QA 循环是 NEXUS Phase 3 Build 阶段的核心机制，也是 NEXUS 的四大核心原则之一（Quality Gates / Dev↔QA Loop / Handoffs / Evidence Over Claims）。 - -## Related Concepts - -- [[Quality Gate]]：Dev↔QA 循环是质量门控体系的具体实现机制 -- [[Reality Checker]]：Dev↔QA 循环 PASS 后，最终质量权威由 Reality Checker 确认 -- [[Evidence Over Claims]]：循环中的验证必须基于证据而非口头断言 diff --git a/wiki/concepts/DevOps-Maturity-Model.md b/wiki/concepts/DevOps-Maturity-Model.md deleted file mode 100644 index e02b15c5..00000000 --- a/wiki/concepts/DevOps-Maturity-Model.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "DevOps Maturity Model" -type: concept -tags: [DevOps, Maturity Assessment, CI/CD] -sources: [devops-maturity-model-from-traditional-it-to-advanced-devops] -last_updated: 2026-04-26 ---- - -## 定义 - -DevOps 成熟度模型（DevOps Maturity Model）是一种结构化框架，用于评估组织当前 DevOps 实践水平，识别改进领域，并规划向更高成熟度等级的演进路径。 - -该模型涵盖四个核心评估维度：**文化与战略**、**自动化**、**结构与流程**、**协作与共享**、**技术**，并通过五个递进阶段量化组织 DevOps 能力。 - -## 成熟度五阶段 - -| 阶段 | 名称 | 关键特征 | -|------|------|----------| -| Phase 1 | 初始/临时阶段 | 瀑布式开发，团队孤立，手动流程，反应式监控 | -| Phase 2 | 局部试点 | 小范围 DevOps 实践，版本控制引入，单元/集成测试 | -| Phase 3 | 自动化与定义 | 基础设施自动化，敏捷跨团队协作，安全扫描集成 | -| Phase 4 | 高度优化 | CI/CD 流水线，不可变基础设施，第三方依赖管理 | -| Phase 5 | 完全成熟 | 连续部署，零人工干预，数据驱动决策 | - -## 关键衡量指标 - -- **部署频率（Deployment Frequency）**：在设定周期内代码部署的频率 -- **变更前置时间（Lead Time）**：从代码提交到部署的时间 -- **变更失败率（Change Failure Rate）**：部署后引发故障或回滚的比例 -- **平均恢复时间（MTTR）**：从故障恢复到正常运行的时间 -- **错误预算（Error Budget）**：允许的生产环境错误和失败率 - -## 核心评估维度 - -1. **文化与战略**：团队协作、透明度、以客户为中心的产品思维 -2. **自动化**：CI/CD 流水线、基础设施即代码、测试自动化 -3. **结构与流程**：标准化流程、小批量工作、消除浪费 -4. **协作与共享**：开发与运维协同、知识共享、统一目标 -5. **技术选型**：工具链集成、监控告警、容器化解决方案 - -## 常见演进障碍 - -- 团队间沟通不畅 -- 缺乏清晰目标和策略 -- 抗拒变革 -- 投入不足 -- 治理薄弱 -- 流程僵化 - -## 来源 -- [[devops-maturity-model-from-traditional-it-to-advanced-devops]] diff --git a/wiki/concepts/DevOps-Maturity.md b/wiki/concepts/DevOps-Maturity.md deleted file mode 100644 index 4eea79d8..00000000 --- a/wiki/concepts/DevOps-Maturity.md +++ /dev/null @@ -1,71 +0,0 @@ -# DevOps Maturity - -## Definition -DevOps Maturity refers to the degree to which an organization has adopted and integrated DevOps practices, ranging from initial ad-hoc processes to highly optimized, automated, and collaborative workflows. - -## Key Dimensions - -### 1. Automation -- CI/CD pipelines -- Infrastructure as Code (IaC) -- Test automation -- Deployment automation - -### 2. Collaboration & Culture -- Cross-team collaboration between development, operations, and security -- Breaking down organizational silos -- Shared goals and responsibilities - -### 3. Monitoring & Observability -- Continuous monitoring -- Centralized logging -- Swift issue detection and resolution - -### 4. Security Integration (DevSecOps) -- Security automated into the DevOps lifecycle -- Continuous compliance -- Proactive vulnerability management - -## Maturity Models -- **CMMI** (Capability Maturity Model Integration) -- **DORA Metrics**: Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR - -## Measuring Maturity -- **Quantitative KPIs**: Deployment frequency, lead times, system uptime, incident resolution times -- **Qualitative indicators**: Employee collaboration, goal alignment, feedback loops between teams - -## Five Maturity Stages (Phase 1–5) - -| Stage | Name | Key Characteristics | -|-------|------|---------------------| -| Phase 1 | Initial/Ad-Hoc | Siloed teams, waterfall approach, manual infrastructure, reactive monitoring, security only at release | -| Phase 2 | DevOps in Pockets | Small cross-functional teams, Agile introduction, version control, superficial automation | -| Phase 3 | Automated and Defined | Standardized processes, automated infrastructure, security integrated into development | -| Phase 4 | Highly Optimized | CI pipeline, immutable infrastructure, MVP and tech debt management | -| Phase 5 | Fully Mature | Self-sufficient full-stack teams, multiple daily deployments, zero human intervention | - -## Sources -- [[sources/cloud-devop-maturity-guideline.md]] -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] - -## Related Concepts -- [[concepts/DevSecOps]] -- [[concepts/CI-CD-Pipeline]] -- [[concepts/Infrastructure-as-Code]] -- [[concepts/Cloud-Native]] -- [[concepts/Continuous-Integration]] -- [[concepts/Continuous-Deployment]] -- [[concepts/Lead-Time]] -- [[concepts/Time-to-Market]] -- [[concepts/Change-Failure-Rate]] -- [[concepts/MTTR]] -- [[concepts/MTTD]] -- [[concepts/MTTA]] -- [[concepts/Error-Budget]] -- [[concepts/Rollback-Rate]] -- [[concepts/Availability]] -- [[concepts/Scalability]] - -## Ingested -- Date: 2026-04-21 -- Date: 2026-04-24 (updated with Phase 1-5 details and metrics) diff --git a/wiki/concepts/DevOpsCulture.md b/wiki/concepts/DevOpsCulture.md deleted file mode 100644 index 18c16059..00000000 --- a/wiki/concepts/DevOpsCulture.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "DevOps Culture" -type: concept -tags: [devops, culture, collaboration, transformation] -sources: [devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin, devops-maturity-model-from-traditional-it-to-advanced-devops] -last_updated: 2026-04-22 ---- - -## Summary -DevOps Culture is the foundational mindset shift that bridges Development and Operations teams to break down organizational silos, accelerate software delivery, and drive continuous innovation. It emphasizes collaboration over isolation, shared ownership of the software lifecycle, and customer-centricity. DevOps culture is not merely about tools or automation — it is fundamentally a cultural revolution prioritizing collaboration, continuous learning, and feedback loops. - -## Four Foundational Pillars - -### 1. Collaboration Over Silos -Traditional IT structures pit developers (focused on rapid feature delivery) against operations (prioritizing stability). DevOps dismantles these silos through cross-functional teams sharing ownership of the entire software lifecycle. - -**Strategies:** -- **Shared Goals**: Align teams around common KPIs (deployment frequency, MTTR) -- **Cross-Training**: Developers learn infrastructure; operations staff engage in coding -- **Tools for Transparency**: Slack, Microsoft Teams, Atlassian Jira for real-time communication - -### 2. Automation as an Enabler -Automation eliminates manual toil, reduces errors, and accelerates feedback loops. - -**Key Areas:** -- CI/CD Pipelines (Jenkins, GitLab CI, GitHub Actions) -- Infrastructure as Code (Terraform, AWS CloudFormation) -- Monitoring & Observability (Prometheus, Grafana, Datadog) - -### 3. Continuous Improvement (Kaizen) -Iterative learning through: -- **Blameless Post-Mortems**: Dissect failures without finger-pointing -- **Metrics-Driven Bottleneck Identification**: Lead time, deployment success rate -- **Chaos Engineering**: Proactive system resilience testing - -### 4. Customer-Centricity -Every release solves real user problems through: -- **Feature Flagging**: Incremental rollout with user insights -- **A/B Testing**: Data-driven experience optimization - -## Transformation Playbook - -1. **Leadership Buy-In**: Executives champion collaboration and allocate resources -2. **Upskilling Teams**: Certifications (AWS DevOps, Kubernetes), internal Guilds/CoEs -3. **Start Small, Scale Fast**: Pilot projects demonstrate quick wins -4. **Overcoming Resistance**: Address fear of job loss; celebrate wins - -## Connections -- [[DevOps Culture and Transformation Source]] — Primary source document -- [[CI/CD Pipeline]] — Automation enabler -- [[Infrastructure as Code (IaC)]] — Automation pillar -- [[DevSecOps]] — Shift-Left security integration -- [[GitOps]] — Future trend -- [[Agile Practices]] — Complementary methodology -- [[Continuous Improvement (Kaizen)]] — Japanese philosophy applied to DevOps - -## Contradictions -- **Kanban vs Event Sourcing**: [[Project State Management]] emphasizes auto-tracking via event sourcing; traditional DevOps culture relies on Kanban-style visual collaboration and shared team boards. See overview.md Conflict Area #1. diff --git a/wiki/concepts/DevSecOps.md b/wiki/concepts/DevSecOps.md deleted file mode 100644 index 1ea2196a..00000000 --- a/wiki/concepts/DevSecOps.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "DevSecOps" -type: concept -tags: [devops, security, sdlc, automation, ci-cd] -sources: ["what-is-devsecops-best-practices-benefits-and-tools"] -last_updated: 2025-12-19 ---- - -## Definition - -DevSecOps（Development + Security + Operations）是一种将安全实践深度嵌入软件开发生命周期（SDLC）全程的工作方法论，使安全成为开发、安全、运营三团队的共同责任，而非独立的末端检查环节。 - -## Core Principles - -- **Security as Code**：以代码形式定义安全策略，实现自动化执行和版本控制 -- **Shift Left**：在开发周期早期发现并修复安全漏洞，降低修复成本 -- **Shift Right**：在应用上线后持续进行安全监控，快速响应新发现漏洞 -- **Shared Responsibility**：全员对安全负责，而非仅依赖安全团队 -- **Automation First**：将安全测试集成到 CI/CD 流水线，减少人工干预 - -## Key Tools - -| 工具类型 | 说明 | 典型工具 | -|---------|------|---------| -| [[SAST]] | 静态代码分析，编码阶段使用 | SonarQube, Checkmarx | -| [[DAST]] | 动态渗透测试，模拟外部攻击 | OWASP ZAP, Burp Suite | -| [[SCA]] | 软件成分分析，扫描第三方依赖漏洞 | Snyk, Dependabot | -| [[IAST]] | 运行时交互式测试，测试阶段使用 | Contrast Security | - -## Relationship with DevOps - -DevSecOps 是 [[DevOps]] 的安全扩展： -- DevOps 强调开发与运营协作，追求速度与效率 -- DevSecOps 在 DevOps 基础上全程嵌入安全实践 -- 两者共享 CI/CD 流水线文化，但 DevSecOps 在每个阶段加入安全门控 - -## Key Metrics - -- 据报告，**70% 的上线后发现的安全漏洞**可通过 DevSecOps 实践预防 -- "break the build" 机制：在安全风险超阈值时自动停止构建流程 -- 安全漏洞修复成本：开发早期修复成本仅为上线后的 1/100 ~ 1/10 - -## Related Concepts - -- [[Shift Left]] — 在开发早期识别安全缺陷 -- [[Shift Right]] — 上线后持续安全监控 -- [[Policy as Code]] — 安全策略即代码 -- [[CI/CD 安全]] — CI/CD 流水线中的安全自动化 -- [[OWASP Top Ten]] — Web 应用安全标准 - -## Aliases - -- SecOps (Security Operations) -- DevOpsSec -- Secure DevOps diff --git a/wiki/concepts/Dialogue-Writing-Standards.md b/wiki/concepts/Dialogue-Writing-Standards.md deleted file mode 100644 index 42a33837..00000000 --- a/wiki/concepts/Dialogue-Writing-Standards.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: "Dialogue Writing Standards" -type: concept -tags: [game-narrative, dialogue, writing] -sources: [narrative-designer.md] -last_updated: 2026-04-26 ---- - -# Dialogue Writing Standards - -游戏对话写作标准——确保对话像真实人物说话、每个台词都有明确叙事功能的写作规范体系。 - -## Core Rule - -**Every line must pass the "would a real person say this?" test.** - -如果答案是否定的，无论句子多么优雅，都必须重写。 - -## Anti-Patterns（必须避免） - -### 1. "As You Know" Dialogue -- 角色之间互相解释他们已经知道的事情 -- 目的：向玩家传递信息，但通过不自然的方式 -- 真实人物不会这样做——他们已经知道，他们不会互相解释 - -**Bad:** -> REYES: "As you know, Commander, our base has been under attack for three days and we're running low on supplies." - -**Good:** -> REYES: "Three days. I'm told you've been tracking the situation remotely." - -### 2. Exposition Disguised as Conversation -- 看起来是对话，实际上是单向信息广播 -- 一个角色问一个他们明显知道答案的问题，只为让另一个角色解释 - -**Bad:** -> ALICE: "Tell me, Bob, how did you manage to hack the mainframe?" -> BOB: "Well, Alice, I used a brute-force attack combined with a zero-day vulnerability I discovered last week..." - -### 3. Players Overheard Thoughts -- 角色说出他们永远不会大声说的内心独白 -- 除非游戏有旁白系统，否则禁止 - -## Required: Dramatic Function - -Every dialogue node must serve at least one of four dramatic functions: -1. **Reveal** — 揭示新信息（世界、角色、关系） -2. **Establish** — 建立或深化关系 -3. **Create Pressure** — 制造紧迫感或冲突 -4. **Deliver Consequence** — 交付玩家之前选择的后果 - -如果一句台词不服务于以上任何一个功能，删除它。 - -## Three-Pass Editing - -### Pass 1: Function Check -- 这个对话节点完成了什么叙事工作？ -- 它是否连接了前后叙事节点？ -- 如果删除它，故事是否受影响？ - -### Pass 2: Voice Check -- 这句台词是否像这个角色说的？ -- 词汇、节奏、口癖是否符合 Voice Pillar？ -- 这个角色在这种情况下会不会说这句话？ - -### Pass 3: Brevity Check -- 删掉每个没有为句子挣到位置的词 -- 游戏对话通常比电影剧本更紧凑 -- 玩家不喜欢阅读——让他们说得越少越好 - -## Dialogue Tools -- Ink / Yarn Spinner / Twine：直接在引擎格式中创作，无需中间转换 -- String externalization：从第一天就外部化字符串，支持本地化 -- Gender-neutral fallbacks：提前规划性别适应性 -- Branching visualization：可视化工具让编辑团队在单一视图中看到完整对话树 - -## Related Concepts -- [[Character Voice Pillars]]：Voice Pillar 是写作标准的具体化 -- [[Branching Narrative]]：对话必须在节点映射后从分支结构中写出 -- [[Narrative-Gameplay Integration]]：对话必须与游戏机制整合 - -## Sources -- [[Narrative Designer Agent Personality]] — Dialogue Writing Standards diff --git a/wiki/concepts/Disaster-Recovery.md b/wiki/concepts/Disaster-Recovery.md deleted file mode 100644 index 98cda576..00000000 --- a/wiki/concepts/Disaster-Recovery.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: "Disaster Recovery" -type: concept -tags: [Disaster-Recovery, DR, Business-Continuity, RTO, RPO, High-Availability, Cloud-DevOps] -sources: - - ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup - - ctp-topic-44-aws-backup-in-micro-focus - - rto-vs-rpo-key-differences-for-modern-disaster-recovery - - public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2 -last_updated: 2026-04-29 ---- - -## Disaster Recovery（灾难恢复） - -灾难恢复（Disaster Recovery，DR）是指保护信息系统免受灾难性事件（地震、洪水、火灾、勒索软件、硬件故障、人为错误）影响的策略与实践体系，是 [[Business-Continuity-Plan]]（业务连续性计划）的 IT 技术层面核心组成部分。 - -## Core Metrics - -DR 的两大核心量化指标： - -| 指标 | 全称 | 含义 | 测量方向 | -|------|------|------|----------| -| **[[RTO]]** | Recovery Time Objective | 恢复时间目标：系统中断到恢复的最大可接受时长 | Forward（从故障向前） | -| **[[RPO]]** | Recovery Point Objective | 恢复点目标：可接受的最大数据丢失时间窗口 | Backward（从故障向后追溯） | - -## DR Strategies - -### Protection Scope - -| 策略 | 说明 | RTO | RPO | 成本 | -|------|------|-----|-----|------| -| **Backup Only** | 定期备份，无备用设施 | 数小时至数天 | 数小时至数天 | $ | -| **Pilot Light** | 核心服务常驻，冷备设施待机 | 数十分钟 | 分钟级 | $$ | -| **Warm Standby** | 部分服务热备，按需扩展 | 数分钟 | 秒级 | $$$ | -| **Multi-Region Active-Active** | 多区域同时运行 | ~0 | ~0 | $$$$ | - -### Cloud-Native DR on AWS - -- **[[AWS-Backup]]**：集中化管理 EC2、RDS、DynamoDB、S3 等服务的备份 -- **[[AWS-Backup-Audit-Manager]]**：自动化合规审计 -- **Cross-Region Replication**：S3 跨区域复制 EBS 卷快照 -- **AWS Elastic Disaster Recovery**：持续复制到 AWS，提供秒级 RPO - -## DR vs. High Availability - -| 维度 | 高可用（HA） | 灾难恢复（DR） | -|------|-------------|--------------| -| **目标故障** | 单组件故障（硬件、软件） | 区域性灾难（数据中心失效） | -| **覆盖范围** | 单站点内的冗余 | 跨地理位置的保护 | -| **触发方式** | 自动 failover | 人工决策触发 | -| **测试频率** | 持续运行（always-on） | 定期演练 | - -## DR Testing Challenges - -当前企业 DR 测试面临的普遍挑战（OpenText 案例）： - -- **被动性**：测试按客户时间表安排，非主动设计 -- **手动性**：大量人工协调，SME 全程参与 -- **不一致**：缺乏跨组织的统一 DR 方法论 -- **局限性**：超大规模云平台的测试主要覆盖区域故障，缺乏对账户级/服务级故障的验证 - -## DR to Recovery Assurance Evolution - -[[OpenText]] 提出的演进框架——从被动 DR 转向主动 [[Recovery-Assurance]]： - -1. **Design**：将可恢复性前置为架构设计原则 -2. **Software**：软件内嵌遥测，支持持续健康监控 -3. **Build**：Customer Zero 环境验证恢复路径 -4. **Environments**：SRE + 可观测性工程支撑弹性 - -## Related Concepts - -- [[RTO]] — 恢复时间目标，DR 核心指标 -- [[RPO]] — 恢复点目标，DR 核心指标 -- [[Business-Continuity-Plan]] — 业务连续性计划，DR 的上层框架 -- [[Recovery-Assurance]] — 灾难恢复的演进方向，从被动响应到主动保证 -- [[High-Availability]] — 高可用性，DR 的微观层面 -- [[AWS-Backup]] — AWS 云原生 DR 实现工具 - -## Sources - -- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] -- [[ctp-topic-44-aws-backup-in-micro-focus]] -- [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]] -- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] diff --git a/wiki/concepts/Discrimination-Metrics.md b/wiki/concepts/Discrimination-Metrics.md deleted file mode 100644 index a5338d78..00000000 --- a/wiki/concepts/Discrimination-Metrics.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: "Discrimination Metrics" -type: concept -tags: [model-evaluation, classification-metrics, model-performance] -sources: - - specialized-model-qa -last_updated: 2026-05-29 ---- - -## Definition - -判别能力指标（Discrimination Metrics）衡量模型区分正例与负例的能力——给定一个随机正例和一个随机负例，模型有多大概率给正例更高的分数。区别于校准（衡量概率准确性），判别度衡量排序正确性。 - -## Core Metrics - -### AUC (Area Under the ROC Curve) -- ROC 曲线下面积，取值 [0.5, 1.0] -- 0.5 = 随机猜测，1.0 = 完美区分 -- 解读：给定随机正例和随机负例，有 AUC 概率给正例更高分数 -- **优势**：阈值无关，对类别不平衡相对稳健 - -### Gini Coefficient -- $Gini = 2 \times AUC - 1$ -- 取值 [0, 1.0]，与 AUC 线性等价 -- 金融行业常用（信用卡评分、信贷风控） -- 监管报告标准指标 - -### KS Statistic (Kolmogorov-Smirnov) -- 两个累积分布函数（正例 vs 负例）之间的最大垂直距离 -- $KS = \max_t |F_{pos}(t) - F_{neg}(t)|$ -- 取值 [0, 1.0]；KS > 0.2 通常认为有区分能力 -- **优势**：不依赖阈值，提供最佳分割点位置信息 - -### Additional Metrics -| Metric | Formula | 适用场景 | -|--------|---------|---------| -| F1 Score | $2 \times \frac{precision \times recall}{precision + recall}$ | 类别不平衡 | -| RMSE | $\sqrt{\frac{1}{n}\sum(y_i - \hat{y}_i)^2}$ | 回归模型 | -| Log Loss | $-\frac{1}{N}\sum[y_i \log p_i + (1-y_i)\log(1-p_i)]$ | 概率质量 | - -## Usage - -```python -from sklearn.metrics import roc_auc_score, f1_score -from scipy.stats import ks_2samp - -def discrimination_report(y_true, y_score): - auc = roc_auc_score(y_true, y_score) - gini = 2 * auc - 1 - ks_stat, ks_pval = ks_2samp(y_score[y_true == 1], y_score[y_true == 0]) - return { - "AUC": round(auc, 4), - "Gini": round(gini, 4), - "KS": round(ks_stat, 4), - "KS_pvalue": round(ks_pval, 6), - } -``` - -## Model QA 中的应用 - -Model QA Specialist 执行以下判别能力审计： -1. **全数据切片分析**：在 Train/Validation/Test/OOT 四个数据切片上分别计算 AUC/Gini/KS -2. **子群体性能**：在性别/年龄/地区等受保护属性上分别测试，发现公平性隐患 -3. **时间稳定性**：跨 OOT 窗口追踪 AUC/Gini 趋势，识别性能衰减 -4. **冠军-挑战者对比**：Proposed model vs. incumbent production model，量化相对提升 - -## Relationship - -- **被依赖** [[Calibration-Testing]]：先确认判别能力（KS > 0.2, AUC > 0.7），再测试校准 -- **依赖** [[Population-Stability-Index]]：PSI 监控输入稳定性，判别指标监控输出健康度 -- **依赖** [[SHAP]]：判别指标提供"是否好"的答案，SHAP 解释"为什么" -- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的核心性能评估步骤 - -## Key Insights - -- **判别度 vs 校准**：高 AUC 模型仍可能在特定概率区间严重校准偏差；两者必须同时评估 -- **KS vs AUC**：KS 对尾部区分更敏感（抓坏人），AUC 对整体排序更均衡 -- **监管门槛**：金融风控通常要求 Gini > 0.4（相当于 AUC > 0.7）方可上线 diff --git a/wiki/concepts/Distribution-Key.md b/wiki/concepts/Distribution-Key.md deleted file mode 100644 index d59ddbff..00000000 --- a/wiki/concepts/Distribution-Key.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Distribution Key" -type: concept -tags: - - Data-Engineering - - Database - - AWS-Redshift - - Performance-Optimization -last_updated: 2026-04-14 ---- - -## Definition - -Distribution Key（分布键，Dist Key）决定数据在分布式数据仓库集群各计算节点间的分布方式。合理的分布键选择是避免数据倾斜（Data Skew）和最小化跨节点数据传输（Data Shuffling）的关键。 - -## Distribution Strategies - -### 1. KEY Distribution（关键分布） -- 按特定列的哈希值分布数据 -- 同一键值的数据会落在同一节点 -- 适用场景：事实表与维度表基于外键的关联（Colocation Join） - -### 2. ALL Distribution（全分布） -- 将小表完整复制到所有节点 -- 消除跨节点传输，但增加存储成本 -- 适用场景：小维度表（< 10MB） - -### 3. EVEN Distribution（均匀分布） -- 轮询方式均匀分布数据 -- 默认策略，适用于无明显热点的情况 -- 适用场景：无法确定最佳分布键时的兜底策略 - -## Key Trade-offs - -| 维度 | KEY | ALL | EVEN | -|------|-----|-----|------| -| 存储成本 | 低 | 高 | 低 | -| Join 性能 | 高（co-located） | 高 | 低（可能 shuffle） | -| 数据倾斜风险 | 中（取决于键值分布） | 无 | 无 | -| 适用表规模 | 大表 | 小表 | 通用 | - -## Related Concepts - -- [[Sort-Key]]：节点内数据排序，与 Distribution Key 共同构成 Redshift 性能优化双核心 -- [[Data-Skew]]：分布键选择不当导致的数据倾斜问题 -- [[MPP]]：分布键决定数据局部性，影响 MPP 并行效率 -- [[Amazon-Redshift]]：Distribution Key 是 Redshift 架构的核心概念 - -## Sources - -- [[ctp-topic-68-introduction-to-redshift]]：Distribution Key 在 Redshift 集群数据分布中的作用 diff --git a/wiki/concepts/Divio-Documentation-System.md b/wiki/concepts/Divio-Documentation-System.md deleted file mode 100644 index b4dd0e3f..00000000 --- a/wiki/concepts/Divio-Documentation-System.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Divio Documentation System" -type: concept -tags: ["documentation", "knowledge-management", "methodology"] -last_updated: 2026-05-01 ---- - -## Definition -Divio Documentation System 是由 [Divio](https://www.divio.com) 提出的文档分类框架，将技术文档分为四个互不重叠的象限，每个象限有明确的目的、受众和写作风格要求。 - -## Four Quadrants - -### 1. Tutorial（教程）— 学习导向 -- **目的**：让读者学会使用某个工具或技术 -- **受众**：新手、入门者 -- **风格**：循循善诱，像老师带学生一样，解释"为什么这样做" -- **关键特征**：从零开始、有明确起点和终点、成功结果可验证 -- **反面教材**：不要写成操作手册（那是 How-to）或参考手册（那是 Reference） - -### 2. How-to Guide（操作指南）— 任务导向 -- **目的**：帮助读者完成特定任务 -- **受众**：已有基础知识的开发者 -- **风格**：实用导向，提供解决具体问题的步骤 -- **关键特征**：面向结果、不解释基础知识、假设读者知道基本操作 -- **反面教材**：不要写成教程（不需要从零开始）或参考文档（不需要穷举选项） - -### 3. Reference（参考文档）— 信息导向 -- **目的**：准确描述系统功能，提供查找式的信息检索 -- **受众**：需要精确信息的开发者 -- **风格**：简洁、精确、格式一致、不含解释 -- **关键特征**：结构化（按字母/功能分组）、完整枚举所有选项、自动生成 -- **反面教材**：不要混入教程内容或解释"为什么"，那会稀释参考价值 - -### 4. Explanation（解释文档）— 理解导向 -- **目的**：帮助读者深入理解某个主题，提供背景和上下文 -- **受众**：想理解"为什么"的开发者 -- **风格**：探索性、讨论性、允许不同观点 -- **关键特征**：不提供步骤、不列举选项、聚焦概念和原理 -- **反面教材**：不要写成 How-to（不需要完成任务）或 Reference（不需要列举信息） - -## Key Rules - -### 绝对禁止：混合象限 -- 一个文档页面只属于一个象限 -- 混合会导致读者困惑（不知道该看哪部分）和作者维护困难 -- 常见错误：把"什么是 X"（Explanation）和"如何用 X"（How-to）写在同一页 - -### 绝对禁止：在参考文档中写教程内容 -- API 参考文档只描述接口，不教如何使用 -- Tutorial 是独立页面 - -### 文档类型与工具的对应关系 -| 类型 | 推荐工具 | 生成方式 | -|------|---------|---------| -| Tutorial | Jupyter Notebook, Docusaurus | 人工编写 | -| How-to | Docusaurus, MkDocs | 人工编写 | -| Reference | Sphinx, OpenAPI Generator | 自动生成 + 人工审核 | -| Explanation | Docusaurus, MkDocs | 人工编写 | - -## Sources -- [[engineering-technical-writer]] — Technical Writer Agent 使用 Divio 系统组织文档写作方法论 diff --git a/wiki/concepts/Docker-Compose.md b/wiki/concepts/Docker-Compose.md deleted file mode 100644 index d288b48e..00000000 --- a/wiki/concepts/Docker-Compose.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Docker Compose" -type: concept -tags: [docker, devops, orchestration] -last_updated: 2026-04-23 ---- - -## Overview -Docker Compose 是一个用于定义和运行多容器 Docker 应用的工具。通过 YAML 文件（`docker-compose.yml`）声明服务、网络、卷等配置，一条命令即可启动整套应用栈。 - -## Key Commands -```bash -docker-compose up -d # 启动服务（后台） -docker-compose down # 停止并移除容器 -docker-compose restart # 重启服务 -``` - -## Key Concepts -- **Services**: 每个容器定义为一个 service -- **Network Mode**: 可使用 `network_mode: host` 将容器网络直接绑定到宿主机 -- **Environment Variables**: 通过 `environment` 字段注入环境变量（如 `YOUTUBE_KEY`、`HTTP_PROXY`） -- **Volumes**: 通过 `volumes` 字段将宿主机文件/目录挂载到容器内 -- **Restart Policy**: `restart: unless-stopped` 确保容器在宿主机重启后自动恢复 - -## Usage in This Wiki -- RSSHub 部署配置使用 Docker Compose 作为主机上的容器编排工具 -- n8n、Portainer、Jellyfin 等服务均通过 Docker Compose 管理 - -## Aliases -- docker-compose -- Docker Compose -- docker compose diff --git a/wiki/concepts/Docker-Containerization.md b/wiki/concepts/Docker-Containerization.md deleted file mode 100644 index efaccd54..00000000 --- a/wiki/concepts/Docker-Containerization.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Docker Containerization" -type: concept -tags: [docker, cloud-migration, devops, aws] -last_updated: 2026-04-23 ---- - -## Definition -Docker 容器化是一种操作系统级虚拟化技术，将应用程序及其所有依赖项打包为轻量级、可移植的容器，确保应用程序在任何环境中一致运行。 - -## Key Features -- **轻量级**：共享主机操作系统内核，无需完整虚拟机开销 -- **可移植性**：容器在任何支持 Docker 的环境中一致运行 -- **隔离性**：每个容器独立运行，拥有自己的文件系统、网络和进程空间 -- **版本控制**：容器镜像支持版本化，便于回滚和审计 -- **可组合性**：通过 Docker Compose 定义多容器应用 - -## Cloud Migration Context -在 [[Octane-Hub]] 的 AWS 迁移案例中，Docker 容器化是关键基础设施： - -| 组件 | 原环境 | 目标环境 | -|------|--------|----------| -| QuickSee | 物理服务器 | AWS Docker | -| Release Manager | 物理服务器 | AWS Docker | -| Patch Manager | 物理服务器 | AWS Docker | -| 安全程序板 | 物理服务器 | AWS Docker | - -### Octane Hub 迁移经验 -- Docker 是主要部署模式，运行在 AWS Landing Zone 账户中 -- 后台作业（支持集成、数据复制、内部空闲搜索）同样容器化 -- 迁移策略："紧密镜像现有设置"，保持应用架构不变 - -### 未来演进 -- 当前：Docker 容器运行在 EC2 实例上 -- 目标：迁移到 AWS ECS（Elastic Container Service）以获得更好的编排能力 - -## Key Concepts -- **镜像 (Image)**：应用程序及其依赖项的可读模板 -- **容器 (Container)**：镜像的运行实例 -- **Dockerfile**：定义镜像构建步骤的脚本 -- **Docker Compose**：定义和运行多容器应用的工具 -- **Volume**：容器持久化数据存储 - -## Related Concepts -- [[Packer]]：用于构建 Docker AMI 镜像 -- [[Terraform]]：用于在 AWS 上部署容器基础设施 -- [[AWS-Landing-Zone]]：企业级多账户 AWS 环境 - -## References -- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]] diff --git a/wiki/concepts/Docker-Daemon-Proxy.md b/wiki/concepts/Docker-Daemon-Proxy.md deleted file mode 100644 index 35f979c3..00000000 --- a/wiki/concepts/Docker-Daemon-Proxy.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: "Docker Daemon Proxy" -type: concept -tags: [docker, proxy, systemd, container] -date: 2026-05-14 ---- - -# Docker Daemon Proxy - -## Aliases -- Docker Daemon Proxy -- Docker 守护进程代理 -- Dockerd Proxy -- HTTP_PROXY for Docker Daemon -- Docker Daemon HTTP 代理 - -## Definition -Docker Daemon Proxy 是指通过 systemd 环境变量（`HTTP_PROXY`/`HTTPS_PROXY`）为 Docker 守护进程（`dockerd`）配置显式代理，使所有 `docker pull`、`docker build` 和容器出站流量走指定代理服务器。这是透明代理失效时（尤其在群晖 DSM/Ubuntu Server 环境中）的推荐替代方案。 - -## When to Use -- 透明代理（V2RayA/Clash）对 Docker Daemon 网络栈无效 -- 需要可靠、可预测的 `docker pull` 代理行为 -- 生产环境/多容器部署中需要与系统路由表解耦 -- 群晖 DSM 7.x（服务名 `pkg-ContainerManager-dockerd`） - -## Implementation Pattern - -### Step 1: Create systemd override directory -```bash -sudo mkdir -p /etc/systemd/system/pkg-ContainerManager-dockerd.service.d/ -``` - -### Step 2: Create proxy config file -```bash -sudo vi /etc/systemd/system/pkg-ContainerManager-dockerd.service.d/http-proxy.conf -``` - -### Step 3: Write environment variables -```ini -[Service] -Environment="HTTP_PROXY=http://127.0.0.1:20171" -Environment="HTTPS_PROXY=http://127.0.0.1:20171" -Environment="NO_PROXY=localhost,127.0.0.1,192.168.*,*.synology.me" -``` - -### Step 4: Reload and restart -```bash -sudo systemctl daemon-reload -sudo systemctl restart pkg-ContainerManager-dockerd -``` - -## Key Distinction from Transparent Proxy -| 维度 | 透明代理（Transparent Proxy） | Docker Daemon Proxy | -|------|------------------------------|-------------------| -| 作用层级 | iptables（内核网络层） | systemd 环境变量 | -| 生效范围 | 所有出站流量（NAS 本机） | 仅 Docker Daemon 进程 | -| DSM 兼容性 | 可能失效（网络栈差异） | 稳定可靠 | -| 对其他服务的影响 | 可能影响 NAS 其他网络服务 | 仅影响 Docker | -| 维护难度 | 高（修改系统路由表） | 低（配置分离） | - -## Related Sources -- [[群晖NAS科学上网方法]] — DSM 7.x 环境下的 Docker Daemon Proxy 完整配置 -- [[Ubuntu-Server科学上网]] — Ubuntu Server 环境下的 Docker Daemon Proxy 配置 - -## Related Concepts -- [[透明代理]] — V2RayA 的默认透明代理机制（在 DSM 中对 Docker Daemon 失效） -- [[V2RayA]] — Docker Daemon Proxy 的上游代理服务提供者 -- [[分流模式]] — V2RayA 的流量路由策略 -- [[iptables]] — 透明代理依赖的内核规则 diff --git a/wiki/concepts/Docker-LLM-Deployment.md b/wiki/concepts/Docker-LLM-Deployment.md deleted file mode 100644 index 0d4be075..00000000 --- a/wiki/concepts/Docker-LLM-Deployment.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: "Docker LLM Deployment" -type: concept -tags: [] -last_updated: 2026-04-23 ---- - -# Docker LLM Deployment - -## Definition -通过 Docker 容器化方式部署本地大语言模型运行时（LLM）及其周边工具（Web 界面、RAG 引擎等），实现环境隔离、可移植性和便捷管理的部署模式。 - -## Core Patterns - -### Pattern 1: Ollama 独立容器 -```bash -# CPU 模式 -docker run -d -p 11434:11434 \ - -v /data/ollama:/root/.ollama \ - --name ollama ollama/ollama - -# GPU 模式（需 nvidia-container-toolkit） -docker run --gpus=all -d -p 11434:11434 \ - -v /data/ollama:/root/.ollama \ - --name ollama ollama/ollama -``` - -### Pattern 2: Ollama + Open WebUI 联合部署 -```yaml -services: - ollama: - image: ollama/ollama - volumes: - - /data/ollama:/root/.ollama - # GPU 模式 - deploy: - resources: - reservations: - devices: - - driver: nvidia - count: all - capabilities: [gpu] - - open-webui: - image: ghcr.io/open-webui/open-webui:main - environment: - - OLLAMA_API_BASE_URL=http://ollama:11434/api - ports: - - 8080:8080 - depends_on: - - ollama -``` - -## Key Advantages -| 优势 | 说明 | -|------|------| -| 环境隔离 | 避免依赖冲突，不污染宿主机 | -| GPU 直通 | `--gpus=all` 直接利用宿主 GPU | -| 便捷迁移 | 镜像导出/导入实现跨机器部署 | -| 统一管理 | `docker compose up/down` 控制启停 | -| 卷挂载 | 模型数据持久化到宿主机目录 | - -## Key Environment Variables -| 变量 | 说明 | 示例 | -|------|------|------| -| OLLAMA_MODELS | 模型存储路径 | `/data/ollama/models` | -| OLLAMA_HOST | API 绑定地址 | `0.0.0.0:11434` | -| OLLAMA_ORIGINS | 允许的跨域来源 | `*` | -| HF_ENDPOINT | HuggingFace 镜像 | `https://hf-mirror.com` | - -## China Environment Best Practices -- 设置 `HF_ENDPOINT=https://hf-mirror.com` 加速镜像拉取 -- 预先拉取镜像：`docker pull ollama/ollama ghcr.io/open-webui/open-webui:main` -- 通过 volume 挂载宿主机模型目录避免重复下载 -- 模型目录规划：`/data/ollama/models` 集中管理所有 GGUF 文件 - -## Related Concepts -- [[Local LLM Deployment]]：Docker 部署是本地 LLM 的一种实现方式 -- [[Ollama]]：Ollama Docker 镜像是核心运行时 -- [[Open WebUI]]：Ollama 的 Web 界面伴侣 - -## Sources -- [[详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1]] diff --git a/wiki/concepts/Docker-用户组.md b/wiki/concepts/Docker-用户组.md deleted file mode 100644 index 15990508..00000000 --- a/wiki/concepts/Docker-用户组.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Docker 用户组" -tags: [docker, security, permissions] -date: 2026-04-22 ---- - -# Docker 用户组 - -## Definition -Docker 用户组是 Linux 系统中的用户组机制，允许组成员无需 `sudo` 前缀直接运行 Docker 命令。 - -## Configuration -```bash -# 将用户添加到 docker 用户组 -sudo usermod -aG docker $USER - -# 刷新组成员资格（需重新登录或重启终端） -newgrp docker -# 或直接登出再登入 -``` - -## Security Implications -⚠️ **安全警告**：docker 用户组成员拥有与 root 用户等效的权限，因为 Docker 容器默认以 root 身份运行。攻击者如果能访问 docker 用户组的成员账户，可能通过容器逃逸获得宿主机 root 权限。 - -## Best Practices -1. 仅将受信任的用户添加到 docker 用户组 -2. 优先使用非 root 用户运行容器（`PUID/PGID` 环境变量） -3. 定期审查 docker 用户组成员 -4. 考虑使用 Podman 作为替代方案（支持无 root 模式） - -## Related Sources -- [[如何在ubuntu-server安装-docker-docker-compose]] — docker 用户组配置步骤 - -## Related Concepts -- [[Docker Engine]] — 被无 sudo 访问的组件 -- [[用户权限]] — Linux 用户组机制 -- [[容器资源限制]] — 配合非 root 用户的安全实践 -- [[PUID/PGID]] — Docker 容器的非 root 用户映射 diff --git a/wiki/concepts/DockerHostNetworking.md b/wiki/concepts/DockerHostNetworking.md deleted file mode 100644 index eb911268..00000000 --- a/wiki/concepts/DockerHostNetworking.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "DockerHostNetworking" -type: concept -tags: - - "docker" - - "networking" - - "container" -sources: [] -last_updated: 2026-04-20 ---- - -## Overview - -DockerHostNetworking 是 Docker 容器访问宿主机网络服务的方式。默认情况下，容器内的 `localhost` 指向容器自身而非宿主机，因此需要特殊配置才能让容器访问运行在宿主机上的服务。 - -## Why It Matters for Hermes Agent + Open WebUI - -Open WebUI 运行在 Docker 容器中，Hermes Agent API Server 运行在宿主机上（端口 8642）。容器内必须通过特殊方式访问宿主机端口。 - -## Options - -### Option 1: host.docker.internal（推荐 macOS/Windows） -```bash -docker run --add-host=host.docker.internal:host-gateway ... -# 访问：http://host.docker.internal:8642/v1 -``` - -### Option 2: Host Networking（Linux） -```bash -docker run --network=host ... -# 访问：http://localhost:8642/v1 -``` - -### Option 3: Docker Bridge IP -```bash -# 先查询：docker inspect bridge | grep Gateway -docker run -e OPENAI_API_BASE_URL=http://172.17.0.1:8642/v1 ... -``` - -## See Also -- [[open-webui-hermes-agent]] diff --git a/wiki/concepts/Docker堆栈.md b/wiki/concepts/Docker堆栈.md deleted file mode 100644 index 9cf3ce5d..00000000 --- a/wiki/concepts/Docker堆栈.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: Docker堆栈 -type: concept -tags: [docker, compose, orchestration] -date: 2025-12-29 ---- - -# Docker堆栈 - -## Definition -Docker 堆栈（Docker Stack）是指通过 Docker Compose 编排的多容器应用，由多个相互依赖的服务组成，共同提供完整功能。在 [[Zipline]] 图床方案中，MinIO + PostgreSQL + Zipline 构成一个完整的堆栈。 - -## Zipline Stack Architecture - -```yaml -services: - minio: # S3 兼容存储 - image: minio/minio:latest - depends_on: [] - - postgres: # 元数据库 - image: postgres:16 - depends_on: [] - - zipline: # 图床应用 - image: ghcr.io/diced/zipline:latest - depends_on: - minio: - condition: service_healthy - postgres: - condition: service_healthy -``` - -## Service Dependency Patterns - -### Pattern 1: Simple depends_on -```yaml -service_a: - depends_on: - - service_b -``` -仅确保启动顺序，不等待就绪。 - -### Pattern 2: Health Check + Condition（本方案推荐） -```yaml -service_b: - healthcheck: - test: ["CMD", "curl", "-f", "http://localhost:9000/health"] - interval: 30s - retries: 3 - -service_a: - depends_on: - service_b: - condition: service_healthy -``` -确保依赖服务就绪后才启动，避免竞态条件。 - -### Pattern 3: wait-for Script -```bash -#!/bin/bash -wait-for-it.sh service:port -- echo "Service is ready" -``` - -## Key Compose Features Used - -| 功能 | 配置 | 说明 | -|------|------|------| -| 健康检查 | `healthcheck` | 自动检测服务状态 | -| 条件依赖 | `condition: service_healthy` | 等待健康检查通过 | -| 资源限制 | `deploy.resources.limits` | 防止单服务耗尽资源 | -| 重启策略 | `restart: unless-stopped` | 异常自动重启 | -| 端口映射 | `ports` | 暴露服务端口 | -| 卷挂载 | `volumes` | 数据持久化 | - -## Resource Limits in This Stack - -| 服务 | 内存限制 | 说明 | -|------|----------|------| -| MinIO | 1G | S3 存储，缓存友好 | -| PostgreSQL | 512M | 元数据，索引优先 | -| Zipline | 512M | Node.js，适中即可 | - -## Volume Persistence - -| 卷路径 | 内容 | 备份策略 | -|--------|------|----------| -| `/volume1/docker/zipline-stack/minio/minio_data` | 图片文件 | Synology Hyper Backup | -| `/volume1/docker/zipline-stack/zipline/pg_data` | 数据库文件 | **不要直接备份**（见下） | - -### Important: Database Volume Warning - -> **警告**：不要直接备份 PostgreSQL 数据目录（`/var/lib/postgresql/data`） -> -> 热备份运行中的数据库目录会导致数据损坏。应使用 `pg_dump` 逻辑备份。 - -正确方式： -```bash -# 使用 pg_dump 逻辑备份（热备份，安全） -docker exec zipline_postgres pg_dump -U zipline -d zipline | gzip > backup.sql.gz -``` - -## Connections -- [[MinIO]] ← part of ← [[Docker堆栈]] -- [[PostgreSQL]] ← part of ← [[Docker堆栈]] -- [[Zipline]] ← part of ← [[Docker堆栈]] -- [[群晖 NAS]] ← hosts ← [[Docker堆栈]] - -## Related Concepts -- [[Docker Compose]] -- [[容器资源限制]] -- [[容器重启策略]] -- [[逻辑备份]] diff --git a/wiki/concepts/Docker容器生命周期管理.md b/wiki/concepts/Docker容器生命周期管理.md deleted file mode 100644 index a64dfa3f..00000000 --- a/wiki/concepts/Docker容器生命周期管理.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -title: "Docker容器生命周期管理" -type: concept -tags: [docker, container, lifecycle, operations] -date: 2026-04-22 ---- - -# Docker容器生命周期管理 - -## Definition -Docker 容器生命周期管理是指对容器的创建、启动、停止、删除等各阶段进行规范操作的过程，是 Home Server 日常运维的基础技能。 - -## Lifecycle States -``` -created → starting → running → stopping → stopped → removing → removed - ↑ ↓ - └────────── restarting ←──────┘ -``` - -## Core Commands - -### 查看 -```bash -# 查看运行中的容器 -docker ps - -# 查看所有容器（包括已停止） -docker ps -a - -# 查看特定应用的容器 -docker ps -a | grep portainer - -# 查看容器详细信息 -docker inspect -``` - -### 启动与停止 -```bash -# 停止运行中的容器 -docker stop - -# 强制停止（SIGKILL，8秒超时后强制终止） -docker kill - -# 启动已停止的容器 -docker start - -# 重启容器（stop + start） -docker restart -``` - -### 删除 -```bash -# 删除已停止的容器 -docker rm - -# 强制删除运行中的容器（先停止再删除） -docker rm -f - -# 删除所有已停止的容器 -docker container prune - -# 一条命令停止并删除 -docker stop && docker rm -``` - -### 完整重建流程（以 Portainer 为例） -```bash -# 1. 停止容器 -docker stop portainer - -# 2. 删除容器 -docker rm portainer - -# 3. (可选) 删除数据卷 -docker volume ls | grep portainer -docker volume rm portainer_data - -# 4. (可选) 删除网络 -docker network ls | grep portainer -docker network rm portainer_network - -# 5. 重新部署 -docker compose up -d -``` - -## Lifecycle Management Best Practices - -### 1. Always Stop Before Remove -删除运行中的容器前应先停止，否则需要使用 `-f` 强制删除。强制删除可能导致数据丢失或不一致状态。 - -### 2. Check Dependencies -删除容器前检查是否有其他容器依赖它： -```bash -docker inspect --format '{{.HostConfig.Links}}' -``` - -### 3. Use --filter for Bulk Operations -```bash -# 删除所有已停止的容器 -docker container prune - -# 删除所有 portainer 相关容器 -docker rm $(docker ps -a --filter "name=portainer" -q) - -# 删除所有退出的容器 -docker rm $(docker ps -a --filter "status=exited" -q) -``` - -### 4. Label-based Lifecycle -给容器打标签以便批量管理： -```bash -# 创建时打标签 -docker run --label "env=production" --label "app=web" nginx - -# 按标签查找 -docker ps --filter "label=env=production" -``` - -## Data Persistence -容器删除后，**绑定挂载**（bind mount）的数据仍然保留，但**匿名卷**（anonymous volume）可能丢失。使用命名卷（named volume）确保数据持久化： -```yaml -volumes: - - portainer_data:/data # 命名卷，删除容器后数据保留 - -# vs - -volumes: - - /data # 匿名卷，不推荐 -``` - -## Related Concepts -- [[Docker卷]] — 容器数据的持久化机制 -- [[Docker Network]] — 容器的网络连接生命周期 -- [[Docker Compose]] — 多容器应用的声明式生命周期管理 -- [[Docker堆栈]] — 多容器协同工作栈的整体生命周期 - -## Related Entities -- [[Portainer]] — 需要生命周期管理的典型容器应用 -- [[Docker]] — 生命周期管理的底层平台 - -## See Also -- [[如何删除旧的废弃的docker-container-volume]] — Portainer 重装的完整实操记录 diff --git a/wiki/concepts/Docker警告处理.md b/wiki/concepts/Docker警告处理.md deleted file mode 100644 index 4e4907b0..00000000 --- a/wiki/concepts/Docker警告处理.md +++ /dev/null @@ -1,185 +0,0 @@ ---- -title: "Docker警告处理" -type: concept -tags: [docker, troubleshooting, warnings, compose] -date: 2026-04-22 ---- - -# Docker警告处理 - -## Definition -Docker 在执行 `docker compose up` 或 `docker compose down` 时常会产生警告（WARNING），这些警告通常表示资源命名冲突或配置不一致。虽然不一定导致功能故障，但了解其根因有助于正确处理和预防。 - -## Common Warnings - -### WARN 1: Network 已存在但不是当前项目创建 - -**典型警告信息**： -``` -WARNING: Found orphan containers ([container_name]) for this project. -WARNING: Network portainer_network declared as external, but it does not exist -``` - -**根因分析**： -- 使用了不同的 compose 文件（或不同的项目目录名）部署过同名应用 -- Docker Compose 以**项目目录名**作为网络/卷名前缀：`${PROJECT_NAME}_${network_name}` -- 之前的项目创建了 `portainer_network`，新 compose 声明了同名网络但找不到对应资源 - -**示例场景**： -``` -# 目录 ~/portainer-deploy 运行过 -docker compose up -d -# → 创建网络 portainer-deploy_portainer_network - -# 目录 ~/my-portainer 运行新的 compose -docker compose up -d -# → 尝试创建 my-portainer_portainer_network -# → 与旧项目冲突 -``` - -**解决方案**： - -**方案 A：复用旧资源（数据保留）** -```yaml -networks: - portainer_network: - external: true -``` -Compose 不会创建网络，直接使用已存在的 `portainer_network`。 - -**方案 B：删除旧资源（干净重建）** -```bash -# 1. 查看网络 -docker network ls | grep portainer - -# 2. 查看是否有容器正在使用 -docker network inspect portainer_network --format '{{range .Containers}}{{.Name}} {{end}}' - -# 3. 断开仍连接的网络（如果有） -docker network disconnect portainer_network - -# 4. 删除网络 -docker network rm portainer_network - -# 5. 重新 up -docker compose up -d -``` - ---- - -### WARN 2: Volume 已存在但属于另一个 Compose 项目 - -**典型警告信息**： -``` -WARNING: Volume portainer_data exists but was not created for service 'portainer'. -It will not be used. -``` - -**根因分析**： -- 之前用不同的项目名部署过 Portainer，创建了旧卷（如 `portainer_portainer_data`） -- 新 compose 声明的卷名（如 `portainer_data`）是不同命名前缀下的卷 -- Docker 认为旧卷不是为当前服务创建的，可能不兼容 - -**解决方案**： - -**方案 A：复用旧卷（数据保留）** -```yaml -volumes: - portainer_data: - external: true -``` - -**方案 B：删除旧卷（数据丢失风险）** -```bash -# 1. 查看所有 portainer 相关卷 -docker volume ls | grep portainer - -# 2. 查看卷详细信息 -docker volume inspect portainer_portainer_data - -# 3. 删除旧卷（注意：会丢失数据） -docker volume rm portainer_portainer_data - -# 4. 重新 up -docker compose up -d -``` - -**⚠️ 警告**：删除 Volume 会永久丢失数据。删除前确认是否需要保留数据。 - ---- - -### WARN 3: Found Orphan Containers - -**典型警告信息**： -``` -WARNING: Found orphan containers ([portainer]) for this project. -``` - -**根因**：compose 文件中删除了某个服务定义，但对应的容器仍存在于 Docker 中。 - -**解决方案**： -```bash -# 方案 A：删除孤儿容器 -docker rm portainer - -# 方案 B：撤销 compose 文件修改，恢复服务定义 -``` - ---- - -## Prevention Best Practices - -### 1. 使用固定的项目名 -```bash -# 指定项目名，避免目录名作为前缀 -docker compose -p my-app up -d - -# 或在 .env 文件中固定 -COMPOSE_PROJECT_NAME=my-app -``` - -### 2. 在部署前先清理 -```bash -# 干净部署前先停止并删除 -docker compose down -docker compose up -d -``` - -### 3. 统一使用 external: true -对于已存在资源的场景，统一在 compose 中声明 `external: true`： -```yaml -volumes: - portainer_data: - external: true - -networks: - portainer_network: - external: true -``` - -### 4. 使用一致的目录名 -避免频繁变更 compose 文件所在目录，防止命名前缀混乱。 - -## Troubleshooting Flowchart -``` -出现 WARN 警告 - ↓ -识别警告类型（Network / Volume / Container） - ↓ -确认是否需要保留旧资源的数据 - ↓ -├─ 需要保留 → 改用 external: true -└─ 不需要保留 → 删除旧资源后重新 up -``` - -## Related Concepts -- [[Docker Compose]] — compose 文件中的 external 声明 -- [[Docker卷]] — Volume 的生命周期 -- [[Docker Network]] — Network 的生命周期 -- [[Docker容器生命周期管理]] — 容器的 CRUD 操作 - -## Related Entities -- [[Portainer]] — 常见产生警告的容器应用 - -## See Also -- [[如何删除旧的废弃的docker-container-volume]] — 完整实操记录 diff --git a/wiki/concepts/Docs-as-Code.md b/wiki/concepts/Docs-as-Code.md deleted file mode 100644 index 5f413fc5..00000000 --- a/wiki/concepts/Docs-as-Code.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: "Docs-as-Code" -type: concept -tags: ["documentation", "devops", "methodology"] -last_updated: 2026-05-01 ---- - -## Definition -Docs-as-Code 是一种将文档视为代码的实践方法论——文档使用与代码相同的工具、流程和版本控制进行管理。 - -## Core Principles - -### 1. 版本控制 -- 文档存储在 Git 仓库中 -- 所有变更通过 Pull Request 审查 -- 保留完整变更历史，支持回滚 - -### 2. 自动化构建 -- 文档变更触发 CI/CD 流水线 -- 自动运行文档检查（spellcheck、broken links、style linting） -- 自动部署到文档托管平台 - -### 3. 协作流程 -- 开发者可以直接在 IDE 中编辑文档 -- 使用 Markdown / reStructuredText / AsciiDoc 等代码友好格式 -- 文档评审与代码评审使用相同工具和流程 - -### 4. 自动化生成 -- API 参考文档从 OpenAPI/Swagger 规范自动生成 -- 代码示例从源代码自动提取 -- 从代码注释（docstrings/JSDoc）自动生成参考文档 - -## Tooling Ecosystem - -### Static Site Generators -- **Docusaurus**：Meta 出品，React 驱动，适合开源项目 -- **MkDocs**：Python 驱动，YAML 配置，Material 主题美观 -- **Sphinx**：Python 官方文档工具，reStructuredText 格式，扩展丰富 -- **VitePress**：Vue 团队出品，轻量快速，Markdown 优先 - -### Documentation Generators -- **OpenAPI Generator / Swagger Codegen**：从 OpenAPI 规范生成多语言 SDK + 参考文档 -- **JSDoc / TypeDoc**：从代码注释生成 JS/TS 参考文档 -- **Sphinx autodoc**：从 Python docstrings 自动生成参考文档 -- **Redoc**：开源 API 文档渲染器，从 OpenAPI 规范生成可读文档 -- **Stoplight**：商业级 API 设计 + 文档平台 - -### Linting & Quality -- **Vale**：prose linter，自定义风格规则，检查文档语法和风格一致性 -- **markdownlint**：Markdown 文件格式检查 -- ** spellchecker**：拼写检查 -- **Link Checker**：断链检测 - -## Implementation Checklist - -### 基础设施 -- [ ] Git 仓库存储文档（与代码同一仓库或专门 docs 仓库） -- [ ] CI/CD 流水线配置文档构建和检查 -- [ ] 选择静态站点生成器并完成初始配置 -- [ ] 配置自动化文档生成（API docs from OpenAPI/JSDoc） - -### 质量门禁 -- [ ] Vale prose linter 规则配置 -- [ ] markdownlint 检查配置 -- [ ] 断链检查集成 -- [ ] 拼写检查集成 - -### 发布流程 -- [ ] 配置自动部署到 GitHub Pages / Read the Docs / Netlify -- [ ] 文档变更触发 PR 审查流程 -- [ ] 定义文档所有者（维护者）职责 - -### 版本管理 -- [ ] 配置多版本文档（对应软件版本） -- [ ] 旧版本文档归档策略（标记弃用，不删除） - -## Relationship to Technical Writing - -Docs-as-Code 是 [[TechnicalWriter]] 的基础设施能力。[[engineering-technical-writer]] 定义了文档内容标准（Divio 系统、质量门禁、指标驱动），Docs-as-Code 提供了实现这些标准的工程化流程。两者共同构成完整的文档工程实践体系。 - -## Sources -- [[engineering-technical-writer]] — Technical Writer Agent 核心理念：文档即代码，代码无文档视为不完整 diff --git a/wiki/concepts/DocumentationTheater.md b/wiki/concepts/DocumentationTheater.md deleted file mode 100644 index 6ac620dd..00000000 --- a/wiki/concepts/DocumentationTheater.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Documentation Theater" -type: concept -tags: [anti-pattern, productivity, knowledge-management] -sources: [meeting-notes-action-items] -last_updated: 2026-04-27 ---- - -## Definition - -Documentation Theater（文档剧场）是一种反讽概念——形容产出大量文档/记录，但实际上没有任何有意义的行动或追踪跟进的现象。核心批评：形式大于实质，记录本身变成了目的，而非达成目的的手段。 - -## Origin - -本概念来自 [[meeting-notes-action-items]] source 中的一句话： - -> *"Meeting notes that don't become tracked tasks are just documentation theater."* - -## Core Insight - -会议笔记的价值不在于"写得好不好"，而在于"写完之后是否有行动项被追踪"。一个格式完美但无人执行的会议记录，与完全不做记录相比，实际价值几乎为零。 - -## Related Concepts - -- [[MeetingNotes]] — 文档剧场是 MeetingNotes 模式的反面 -- [[AI-Driven Task Extraction]] — 对抗文档剧场的核心手段：让 AI 自动提取并创建可追踪任务 -- [[TaskAutomationPipeline]] — 文档剧场 → 可执行任务的自动化流水线 - -## Related Sources - -- [[meeting-notes-action-items]] diff --git a/wiki/concepts/Domain-Join.md b/wiki/concepts/Domain-Join.md deleted file mode 100644 index e9b79a00..00000000 --- a/wiki/concepts/Domain-Join.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Domain Join" -type: concept -tags: - - AWS - - Active-Directory - - IAM - - Automation -sources: - - ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs -last_updated: 2026-05-05 ---- - -## Definition -Domain Join（域加入）是将计算机或云实例加入 Active Directory（AD）域的过程，使其能够使用 AD 账号进行身份认证和访问控制。 - -## Mechanism -在 Gruntwork AWS Landing Zones 架构中，域加入通过以下方式实现自动化： -- **Windows 实例**：使用 SRE 团队预制的 AMI + Terraform `user_data` 中的 PowerShell 脚本，在实例启动时自动完成域加入、命名分配、管理员权限分配及旧对象清理 -- **Linux 实例**：通过 SRE 预制 Shell 脚本 + 安全动态更新（Secure Dynamic Updates）自动注册 DNS A 记录到 Windows DNS 服务器 - -## Key Claims -- 自动化域加入消除了手动干预，提升了实例部署效率 -- 不同环境（R&D vs 生产/SAS）使用不同的 AD 域名规范 - -## Related Entities -- [[swinford.net]]：R&D Labs 环境 AD 域名 -- [[intsas.local]]：生产/SAS 环境 AD 域名 -- [[Gruntwork]] Landing Zones：自动化域加入的基础架构框架 - -## References -- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] diff --git a/wiki/concepts/Domain-Thinking.md b/wiki/concepts/Domain-Thinking.md deleted file mode 100644 index 1929ba8b..00000000 --- a/wiki/concepts/Domain-Thinking.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: "Domain-Thinking" -type: concept -tags: [thinking-framework, expert-selection, zk-steward, ai-prompting] -sources: [zk-steward] -last_updated: 2026-04-25 ---- - -## Definition -Domain-Thinking（领域思维）是 [[zk-steward]] 采用的专家视角切换机制——按 **domain（领域）× task type（任务类型）× output form（输出形式）** 三维定位，选取该领域顶级思维模型或专家视角驱动输出。 - -## Core Mechanism - -``` -Domain × Task Type × Output Form → Expert Selection -``` - -当用户发起任务时，ZK Steward 解析： -- **Domain**：知识领域（品牌营销/学习研究/商业策略/工程等） -- **Task Type**：任务性质（分析/创意/决策/学习等） -- **Output Form**：期望输出形式（结构化报告/创意文案/执行计划等） - -三维交叉后选取对应领域的顶级专家心智模型。 - -## Domain-Expert Mapping（核心参考表） - -| Domain | Top Expert | Core Method | -|--------|-----------|-------------| -| Brand marketing | David Ogilvy | Long copy, brand persona | -| Growth marketing | Seth Godin | Purple Cow, minimum viable audience | -| Business strategy | Charlie Munger | Mental models, inversion | -| Competitive strategy | Michael Porter | Five forces, value chain | -| Product design | Steve Jobs | Simplicity, UX | -| Learning / research | Richard Feynman | First principles, teach to learn | -| Tech / engineering | Andrej Karpathy | First-principles engineering | -| Copy / content | Joseph Sugarman | Triggers, slippery slide | -| AI / prompts | Ethan Mollick | Structured prompts, persona pattern | - -**默认值**：Niklas Luhmann（知识管理/Zettelkasten/笔记网络） - -## Declaration Requirement - -[[zk-steward]] 强制要求在每个回复的**第一或第二句**声明专家视角： -> "From [Expert name / school of thought]'s perspective..." - -禁止： -- ❌ 使用泛泛的"专家说..." -- ❌ 引用方法而不应用方法（name-drop without applying the method） -- ❌ 跳过视角声明 - -## 与传统角色扮演的区别 - -| 维度 | Domain-Thinking | Generic Role-Play | -|------|----------------|-------------------| -| 专家选择 | 基于任务三维定位 | 预设固定角色 | -| 方法应用 | 必须真正应用专家方法 | 仅贴标签 | -| 视角深度 | 领域特定深度推理 | 泛泛泛化 | -| 产出质量 | 专家级结构化输出 | 表面化建议 | - -## Connections -- [[zk-steward]] ← 使用 Domain-Thinking 作为核心工作模式 -- [[Niklas-Luhmann]] ← Domain-Thinking 的默认值专家 -- [[Luhmann-四原则]] ← Domain-Thinking 与四原则协同保证输出质量 - -## Aliases -- 领域专家切换 -- Expert Switching -- Mental Model Selection -- Three-dimensional Expert Triangulation diff --git a/wiki/concepts/DomainDrivenDesign.md b/wiki/concepts/DomainDrivenDesign.md deleted file mode 100644 index 6b474c0b..00000000 --- a/wiki/concepts/DomainDrivenDesign.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Domain-Driven Design" -type: concept -tags: [] -last_updated: 2026-05-01 ---- - -## Definition -一种以业务领域为核心的软件设计方法论，通过建立通用语言（Ubiquitous Language）在技术和业务团队之间建立统一的沟通模型，并以有界上下文（Bounded Context）划分系统的边界。 - -## Key Patterns -- **Bounded Context**：业务领域的清晰边界，每个上下文有独立的模型和术语 -- **Aggregate**：聚合根，负责维护业务不变量 -- **Domain Event**：领域事件，记录业务状态变化 -- **Anti-Corruption Layer**：防腐层，隔离外部系统对核心域的侵蚀 -- **Context Mapping**：上下文映射，定义不同有界上下文之间的关系（Upstream/Downstream/Conformist/Anti-Corruption） - -## Core Principles -- **领域优先，技术其次**：先理解业务问题，再选择技术实现 -- **通用语言**：团队中的每个人都使用同一套术语，减少沟通摩擦 -- **持续精化**：领域模型通过迭代不断深化对业务的理解 - -## Related Concepts -- [[BoundedContext]]：DDD 中的核心边界概念 -- [[EventStorming]]：领域发现的协作技术 - -## Sources -- [[engineering-software-architect]] - -## Aliases -- DDD -- Domain-Driven Design diff --git a/wiki/concepts/Dream-Cycle.md b/wiki/concepts/Dream-Cycle.md deleted file mode 100644 index d8486a5c..00000000 --- a/wiki/concepts/Dream-Cycle.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "Dream-Cycle" -type: concept -tags: [AI-Memory, Context-Substrate, Knowledge-Consolidation, Background-Process] -sources: [ai-memory-tools-two-camps] -last_updated: 2026-04-15 ---- - -## Definition -[[OpenClaw]] 和 [[Thoth]] 采用的后台知识整合机制——夜间多阶段过程将日常笔记、短期上下文整合为长期记忆。是 Context Substrate 范式中最关键的"上下文复合"实现机制。 - -## OpenClaw Dreaming（三阶段） - -源自 OpenClaw 的官方文档，定义了三层递进的整合阶段： - -### Light Sleep（浅睡） -- 筛选每日笔记 -- 将相近行分组为连贯段落 -- 识别值得保留的信息 - -### REM（快速眼动） -- 加权召回提升（weighted recall promotion） -- 频繁访问的信息成为"持久真理"（lasting truths） -- 激活与巩固已有上下文关联 - -### Deep Sleep（深睡） -- 安全推入 MEMORY.md（replay-safe promotion） -- 协调而非重复（reconciles rather than duplicates） -- 最终沉淀为长期记忆 - -### 阈值门控（Gate Mechanism） -只有通过所有阈值的条目才会被提升： -- 最小评分：0.8 -- 最小召回次数：3 -- 最小独立查询数：3 - -### 六维评分信号 -1. 相关性（relevance）：0.30 -2. 频率（frequency）：0.24 -3. 查询多样性（query diversity）：0.15 -4. 时效性（recency）：0.15 -5. 整合度（consolidation）：0.10 -6. 概念丰富度（conceptual richness）：0.06 - -## Thoth Dream Cycle（四阶段） - -Thoth 实现了更精细化的四阶段过程： - -1. **重复合并**（duplicate merging）：相似度 ≥ 0.93 的重复项合并 -2. **描述富化**（description enrichment）：从对话上下文中丰富实体描述 -3. **关系推断**（relationship inference）：推断共现实体之间的关系 -4. **置信度衰减**（confidence decay）：超过 90 天的关系置信度自动衰减 - -额外机制： -- 三层反污染机制防止跨实体事实串扰 - -## Conceptual Significance -Dream Cycle 的核心洞察：**系统不决定什么是"事实"，而是促进持续被证明相关的内容**。这比预先定义的提取规则更鲁棒，因为相关性来自实际使用模式而非人工设计。 - -## Connections -- [[OpenClaw]] ← 实现 ← OpenClaw 实现了 Dreaming 三阶段 -- [[Thoth]] ← 实现 ← Thoth 实现了 Dream Cycle 四阶段 -- [[ai-memory-tools-two-camps]] ← 来源 ← Dream-Cycle 是 Camp 2 工具的核心整合机制 diff --git a/wiki/concepts/Dual-Sign-Off.md b/wiki/concepts/Dual-Sign-Off.md deleted file mode 100644 index cfe54e0f..00000000 --- a/wiki/concepts/Dual-Sign-Off.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "Dual Sign-Off" -type: concept -tags: [governance, quality, NEXUS, gate-keeping] -last_updated: 2026-05-01 ---- - -## Definition - -Dual Sign-Off（双重签批）是 NEXUS 多 Agent 框架的质量治理核心机制——在关键决策点，必须由**两个相互独立的不同视角**的 Gate Keeper **同时批准**，方才有效。任一方否决即为否决。 - -## 设计原理 - -单一 Gate Keeper 的盲区： -- 仅战略视角 → 可能忽视技术可行性和工程复杂度 -- 仅技术视角 → 可能忽视业务价值和资源约束 - -Dual Sign-Off 通过**视角正交性**消除单点故障，确保： -1. 战略决策有技术可行性支撑 -2. 技术决策有业务价值对齐 - -## 在 NEXUS 中的应用 - -### Phase 1 — 战略 + 技术双签 - -| Gate Keeper | 视角 | 验证内容 | -|------------|------|---------| -| [[Studio Producer]] | 战略 | 架构包是否对齐组织战略目标？ROI 是否符合预期？ | -| [[Reality Checker]] | 技术 | 所有组件是否具备实现路径？质量门是否通过？ | - -### Phase 2 — DevOps + QA 双签 - -| Gate Keeper | 视角 | 验证内容 | -|------------|------|---------| -| DevOps Automator | 基础设施 | CI/CD/IaC 是否就绪？可部署？ | -| Evidence Collector | 质量验证 | 8 项截图证据是否全部通过？ | - -### Dev↔QA Loop（循环内） - -| 决策 | 条件 | -|------|------| -| PASS | Evidence Collector 证据通过 + Dev 确认修复 | -| FAIL | 任何一方未通过；进入重试循环（最多3次） | - -## 决策规则 - -- **任一方返回 REVISE** → 整体 REVISE；返回对应 Step 重做 -- **任一方返回 RESTRUCTURE** → 整体 RESTRUCTURE；重启本 Phase -- **Evidence Over Claims**：口头确认无效，必须有截图/测试结果/日志证据 - -## 与 Quality Gate Checklist 的关系 - -Dual Sign-Off 是 Quality Gate Checklist 的**执行机制**。Quality Gate 定义"检查什么"（7项清单），Dual Sign-Off 定义"谁检查"和"如何通过"（双签规则）。 - -## Aliases -- Dual Approval -- Twin Gate Mechanism -- Bifurcated Sign-Off diff --git a/wiki/concepts/DuckDB.md b/wiki/concepts/DuckDB.md deleted file mode 100644 index 5876d5a7..00000000 --- a/wiki/concepts/DuckDB.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "DuckDB" -type: concept -tags: ["database", "embedded", "sql", "analytics"] -last_updated: 2026-04-22 ---- - -## Overview -嵌入式分析型数据库管理系统（Analytical DBMS），DenchClaw 的数据存储后端。完全嵌入进程、无服务器进程、无凭证、无网络依赖——只是一个文件。 - -## Aliases -- None - -## Definition -DuckDB 是专为 OLAP（在线分析处理）优化的嵌入式 SQL 数据库。它是 SQLite 的分析型替代品，支持完整 SQL 语法，但针对聚合查询和大规模数据分析进行了优化。 - -## Key Properties -- **嵌入式**: 链接到应用程序进程，无需独立服务器 -- **零配置**: 无需安装、启动或维护数据库服务器 -- **无网络**: 数据在本地文件，无需远程连接 -- **完全 SQL**: 支持标准 SQL 语法（DML、DDL、子查询、窗口函数等） -- **列式存储**: 针对分析查询优化（GROUP BY、JOIN、聚合） -- **向量式执行**: CPU SIMD 加速批量数据处理 - -## Why DuckDB for CRM -DenchClaw 选择 DuckDB 作为嵌入式 CRM 数据库的理由： -1. **最小体积**: 比 PostgreSQL/MySQL 等服务器数据库轻量得多 -2. **完全 SQL**: 保留关系型数据库的全部查询能力 -3. **无摩擦**: 无需管理服务器进程或连接字符串 -4. **高性能**: 分析查询性能优于 SQLite - -> "DuckDB is the sweet spot: Smallest, most performant embedded database that still supports full SQL. No server process, no credentials, no network — just a file." -> — DenchClaw 核心设计哲学 - -## Use Cases -- [[DenchClaw]]: 本地 CRM 结构化数据存储 -- 分析型工作负载（OLAP） -- 数据科学探索（pandas 集成） -- 嵌入式分析功能 - -## Related -- [[DenchClaw]]: 使用 DuckDB 的 CRM 框架 -- [[File-System-First-UI]]: 与 DuckDB 配合的设计哲学 diff --git a/wiki/concepts/Dynamic-Dashboard.md b/wiki/concepts/Dynamic-Dashboard.md deleted file mode 100644 index 234744ce..00000000 --- a/wiki/concepts/Dynamic-Dashboard.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: "Dynamic Dashboard" -type: concept -tags: [OpenClaw, Dashboard, Monitoring, Automation] -sources: [dynamic-dashboard] -last_updated: 2026-04-27 ---- - -## Definition - -**Dynamic Dashboard** 是一种基于 AI Agent 子代理并行执行的多数据源实时监控仪表盘。通过对话式指令驱动子代理同时抓取多个数据源，定时聚合结果并推送告警，实现"免开发、实时、主动"的监控体验。 - -## 核心洞察 - -> "用对话式描述替代数周的前端开发，立即获得实时洞察" - -## 架构模式 - -``` -┌─────────────────────────────────────────┐ -│ Dynamic Dashboard │ -├─────────────────────────────────────────┤ -│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ -│ │Sub-Agent│ │Sub-Agent│ │Sub-Agent│ │ -│ │ GitHub │ │ Twitter │ │Polymarket│ │ -│ └────┬────┘ └────┬────┘ └────┬────┘ │ -│ │ │ │ │ -│ └────────────┼────────────┘ │ -│ ▼ │ -│ ┌─────────────┐ │ -│ │ Aggregator │ │ -│ └──────┬──────┘ │ -│ ▼ │ -│ ┌─────────┐ ┌──────────┐ ┌───────┐ │ -│ │ Discord │ │ PostgreSQL│ │ Alert │ │ -│ │ Push │ │ History │ │ Check │ │ -│ └─────────┘ └──────────┘ └───────┘ │ -└─────────────────────────────────────────┘ -``` - -## 核心能力 - -1. **多数据源并行监控** - - GitHub: stars, forks, issues, commits - - Social Media: Twitter mentions, Reddit discussions - - Markets: Polymarket volume, prediction trends - - System: CPU, memory, disk health - -2. **子代理并行执行** - - 每个数据源由独立子代理处理 - - 避免顺序轮询导致的阻塞和 API 限流 - - 聚合器等待所有子代理完成后统一汇总 - -3. **定时更新与告警** - - Cron Job 驱动的定时抓取（默认 15 分钟） - - 阈值告警主动推送（Discord/Email/Slack） - - 历史数据存储供趋势分析 - -4. **对话式配置** - - 无需编写前端代码 - - 用自然语言定义监控目标和告警规则 - - 迭代调整只需修改指令文本 - -## 典型应用场景 - -| 场景 | 监控目标 | 推送渠道 | -|------|----------|----------| -| 开发者监控 | GitHub stars/commits | Discord | -| 社媒追踪 | Twitter mentions/sentiment | Discord | -| 市场情报 | Polymarket volume/trends | Telegram | -| 系统运维 | CPU/memory/disk | Discord/Email | - -## 与静态仪表盘对比 - -| 维度 | 静态仪表盘 | Dynamic Dashboard | -|------|------------|-------------------| -| 数据时效 | 手动刷新/定时拉取 | 持续更新 | -| 开发成本 | 数周前端开发 | 对话式配置 | -| 告警机制 | 被动查询 | 主动推送 | -| 多数据源 | 需分别集成 | 子代理原生并行 | - -## Related Concepts - -- [[Parallel-Agent-Execution]] — 子代理并行执行是动态仪表盘的核心机制 -- [[Scheduled-Task-Flywheel]] — Cron Job 驱动定时更新 -- [[Alerting]] — 阈值告警机制 -- [[self-healing-home-server]] — 系统健康监控场景 -- [[earnings-tracker]] — 市场数据监控场景 -- [[content-factory]] — 社交媒体监控场景 diff --git a/wiki/concepts/DynamoDB-Config-Table.md b/wiki/concepts/DynamoDB-Config-Table.md deleted file mode 100644 index bfff8b61..00000000 --- a/wiki/concepts/DynamoDB-Config-Table.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "DynamoDB Config Table" -type: concept -tags: - - AWS - - DynamoDB - - Configuration - - Scheduling -sources: - - ctp-topic-27-aws-instance-scheduler -last_updated: 2026-05-12 ---- - -## DynamoDB Config Table - -AWS Instance Scheduler 架构中的核心数据存储组件，用于持久化调度规则和周期定义。 - -## Schema Design - -DynamoDB Config Table 通常包含两张表： - -### Schedules 表 -- **ScheduleName**：调度名称（如 `Seattle-9-5`、`UK-9-5`） -- **Timezone**：时区配置 -- **Description**：调度描述 - -### Periods 表 -- **PeriodName**：周期名称 -- **BeginTime**：开始时间 -- **EndTime**：结束时间 -- **Weekdays**：适用工作日（周一至周五） -- **InstanceType**：应用实例类型（EC2/RDS） - -## Role in AWS Instance Scheduler - -DynamoDB Config Table 是 Instance Scheduler 的**逻辑核心**： - -1. Lambda 函数通过 DynamoDB SDK 读取 Schedules 和 Periods 定义 -2. 根据当前时间和实例标签（`Schedule`、`Period`）匹配适用的调度规则 -3. 返回匹配结果后决定执行启动或停止操作 - -## Key Advantages - -- **无服务器**：无需管理任何基础设施，按需扩展 -- **低延迟**：毫秒级读取性能，满足高频调度查询 -- **高可用**：多可用区自动复制，无单点故障 -- **成本效益**：按请求计费，零管理工作负载 - -## Related Pages -- [[AWS-Instance-Scheduler]] — 主要使用场景 -- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源 diff --git a/wiki/concepts/EA-SA-TA-Framework.md b/wiki/concepts/EA-SA-TA-Framework.md deleted file mode 100644 index d58d3f7b..00000000 --- a/wiki/concepts/EA-SA-TA-Framework.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "EA-SA-TA Framework" -type: concept -tags: [Enterprise-Architecture, Solution-Architecture, Technical-Architecture, Cloud-Governance] -sources: ["ctp-topic-23-introduction-to-the-technical-architecture-team-and-function"] -last_updated: 2026-05-11 ---- - -## Definition -EA-SA-TA Framework 是 OpenText 云转型办公室采用的三层架构职能分工体系，通过明确的职责边界实现从业务战略到技术实施的完整覆盖。 - -## Layer Breakdown - -### Enterprise Architecture (EA) — 企业架构 -- **定位**：最顶层，对接业务战略 -- **职责**：将业务目标转化为技术原则和标准，确保技术投资与商业战略一致 -- **核心问题**：我们应该在哪些技术领域进行投资？如何与技术战略保持一致？ - -### Solution Architecture (SA) — 方案架构 -- **定位**：中间层，连接 EA 与 TA -- **职责**：专注于特定项目或服务的优化实施，确保系统组件间的高效协作 -- **核心问题**：针对特定项目，什么是最佳的技术解决方案？ - -### Technical Architecture (TA) — 技术架构 -- **定位**：最底层，贴近技术实施 -- **职责**：负责具体基础设施的设计、实施治理以及技术路线图的维护 -- **核心问题**：如何实施和维护技术基础设施？技术路线图如何规划？ - -## Design Rationale（from Martin Nash） -- 大型组织（PSTC + IT 合并至 CIO）需要清晰的架构分工 -- 三层分工使技术治理从"救火式"转向"主动规划" -- EA 负责战略方向，SA 负责方案优化，TA 负责落地执行，分工明确减少职责重叠 - -## Connections -- [[Cloud-First-Policy]] — EA 层制定的云优先技术原则 -- [[AWS-Enterprise-Landing-Zone]] — TA 层维护的标准化基础设施 -- [[Architecture-Roadmap]] — TA 层制定的 12-24 个月路线图 -- [[Cloud-Transformation-Programme]] — 三层架构体系的组织背景 diff --git a/wiki/concepts/EBUR128LoudnessNormalization.md b/wiki/concepts/EBUR128LoudnessNormalization.md deleted file mode 100644 index 7f49b2b4..00000000 --- a/wiki/concepts/EBUR128LoudnessNormalization.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "EBUR128LoudnessNormalization" -type: concept -tags: ["audio-processing", "loudness", "ffmpeg", "ebur128"] -last_updated: 2026-05-02 ---- - -# EBUR128LoudnessNormalization（EBU R128 响度归一化） - -## Definition - -EBU R128 是欧洲广播联盟制定的响度归一化标准，用于确保不同来源的音频具有一致的感知响度。在 Whisper 类转录模型管道中，R128 归一化确保输入音频响度稳定，避免因音量差异导致的精度下降。 - -## Standard Parameters - -```bash --af "loudnorm=I=-16:TP=-1.5:LRA=11" -``` - -| 参数 | 含义 | 标准值 | -|------|------|--------| -| `I` | 综合响度（Integrated Loudness） | -16 LUFS | -| `TP` | 真峰值（True Peak） | -1.5 dBTP | -| `LRA` | 响度范围（Loudness Range） | 11 LU | - -## Why -16 LUFS? - -- 广播标准（TV/Streaming）：-24 LUFS（旧标准）→ -16 LUFS（新趋势，Netflix/YouTube） -- Podcast/对话内容：-16 LUFS 更适合语音主导的内容 -- 过高的综合响度（>-14 LUFS）会导致语音压缩失真 - -## Pipeline Context - -``` -原始音频 → 格式检测（ffprobe）→ EBU R128 归一化 → 重采样至 16kHz → 单声道 -``` - -## Why It Matters for Whisper - -Whisper 对响度变化不免疫。同一段语音，-30 LUFS 的录音和 -16 LUFS 的录音，后者的WER（Word Error Rate）更低，因为响度归一化降低了动态范围，减少了模型在处理软/响片段时的注意力分散。 - -## Related Concepts -- [[VoiceActivityDetection]] — 归一化之后的后处理 -- [[FasterWhisper]] — 归一化音频的消费者 - -## Related Sources -- [[engineering-voice-ai-integration-engineer]] diff --git a/wiki/concepts/EC2-Purchase-Options.md b/wiki/concepts/EC2-Purchase-Options.md deleted file mode 100644 index c514530e..00000000 --- a/wiki/concepts/EC2-Purchase-Options.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: "EC2 Purchase Options" -type: concept -tags: - - AWS - - EC2 - - Cost-Optimization - - FinOps -last_updated: 2026-04-24 ---- - -# EC2 Purchase Options - -## Definition - -AWS EC2 提供多种购买选项，允许用户根据工作负载需求和成本优化目标选择最适合的计费方式。 - -## Purchase Options - -### 1. On-Demand Instances（按需实例） - -- **特点**：按秒计费，无需承诺，无预付费用 -- **适用场景**：短期、不可预测的工作负载；首次运行应用程序；测试和开发环境 -- **优点**：灵活性最高，无需长期承诺 -- **缺点**：成本最高，无折扣 - -### 2. Savings Plans（节约计划） - -- **特点**：1 年或 3 年承诺使用量（以美元计），享受比按需价格低最多 72% 的折扣 -- **类型**： - - Compute Savings Plans：最灵活，几乎适用于所有 EC2 实例类型 - - EC2 Instance Savings Plans：针对特定实例系列，灵活性较低但折扣更高 -- **适用场景**：可预测的稳定工作负载 -- **优点**：成本可预测，折扣显著 -- **缺点**：需要承诺使用量 - -### 3. Spot Instances（竞价实例） - -- **特点**：利用 AWS 闲置容量，价格随供需波动，最高可享受 90% 的按需价格折扣 -- **适用场景**：容错工作负载：批处理、大数据、CI/CD、容器化应用 -- **优点**：成本最低（高达 90% 折扣） -- **缺点**：实例可被 AWS 中断（2 分钟警告） -- **最佳实践**： - - 实现容错机制（自动保存状态） - - 使用 Spot Fleet 或 Spot Block - - 与 EKS/ECS 集成实现自动扩展 - -### 4. Reserved Instances（预留实例） - -- **特点**：1 年或 3 年承诺，目前已被 Savings Plans 取代 -- **类型**：标准 RI（可修改）、可转换 RI（可更改实例类型） -- **备注**：新用户推荐使用 Savings Plans - -### 5. Dedicated Hosts（专用主机） - -- **特点**：物理服务器专供单个客户使用，满足合规性要求 -- **适用场景**：有许可证需求、物理服务器隔离要求、BYOL（自带许可证）工作负载 - -## Cost Optimization Strategy - -推荐的成本优化策略（来自 [[ctp-topic-13-cloud-finops-policies]]）： - -1. **Right Sizing**：先确定正确的实例大小 -2. **基准负载**：使用 Savings Plans 或 RI 覆盖 -3. **弹性扩展**：使用 Spot 实例处理波动负载 -4. **组合策略**：Savings Plans（基准）+ Spot（弹性）= 最佳成本架构 - -## Comparison Table - -| 购买选项 | 折扣 | 灵活性 | 承诺要求 | 适用场景 | -|---------|------|--------|---------|---------| -| On-Demand | 0% | 最高 | 无 | 测试/开发/短期 | -| Savings Plans | 最高 72% | 中等 | 1-3 年 | 稳定工作负载 | -| Spot Instances | 最高 90% | 低 | 无 | 容错工作负载 | -| Reserved Instances | 最高 60% | 低 | 1-3 年 | 稳定工作负载（已不推荐）| - -## Related Concepts - -- [[Savings Plans]]：AWS 承诺使用量定价 -- [[Spot Instances]]：竞价型实例 -- [[Graviton]]：ARM 处理器，可与各种购买选项配合使用 -- [[Right Sizing]]：正确选择实例大小 -- [[FinOps]]：云财务管理 - -## Sources - -- [[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]] -- [[ctp-topic-13-cloud-finops-policies]] -- [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]] diff --git a/wiki/concepts/EC2-Spot-Instances.md b/wiki/concepts/EC2-Spot-Instances.md deleted file mode 100644 index 555070db..00000000 --- a/wiki/concepts/EC2-Spot-Instances.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: "EC2 Spot Instances" -type: concept -tags: - - AWS - - EC2 - - Cost-Optimization - - FinOps -aliases: - - Spot Instances - - EC2 Spot - - 竞价实例 -last_updated: 2026-05-12 ---- - -## Overview - -EC2 Spot Instances（竞价实例）是 AWS 利用闲置计算容量提供的折扣实例，相比 On-Demand 价格最高可享 **90% 折扣**。当 AWS 需要回收容量时，Spot 实例会被中断，因此需要工作负载具备容错能力。 - -## Core Characteristics - -- **折扣幅度**：比 On-Demand 价格低 60-90% -- **中断机制**：AWS 可在需要时终止实例，提前 2 分钟发出 Spot 中断通知 -- **适用场景**：容错、灵活、无状态的工作负载 - -## Best Practices - -### 工作负载要求 -- **容错（Fault Tolerance）**：应用需能处理实例中断 -- **灵活（Flexible）**：可接受不同实例类型 -- **无状态（Stateless）**：不依赖单点实例状态 - -### 策略 -- **跨实例类型多样化**：不过度限制实例池 -- **跨可用区分布**：提高可用性 -- **自动化中断响应**：集成 Auto Scaling、EKS、ECS -- **Spot + On-Demand 组合**：核心组件用 On-Demand，可中断组件用 Spot - -### EKS/ECS 集成 -- **EKS**：支持 Spot 中断通知，自动响应 -- **ECS**：支持 Spot 实例自动化管理 -- **Auto Scaling Groups**：配合 ASG 实现弹性 - -## Use Cases - -- Web 服务（容错设计） -- 容器化工作负载（配合 Spot Fleet） -- HPC 批处理 -- 大数据分析 -- CI/CD 构建 - -## Spot + Graviton 组合 - -Spot 和 Graviton 可同时用于容器化工作负载，只要不过度限制实例池，即可获得双重成本优化（Spot 折扣 + Graviton 高性价比）。 - -## Related Pages - -- [[Graviton]]：ARM 处理器，高性价比 -- [[FinOps]]：云财务管理 -- [[SavingsPlans]]：另一种成本优化购买选项 -- [[AWS-Nitro]]：底层虚拟化平台 -- [[Spot-Invaders]]：Spot 实例容错实践案例 -- [[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]] -- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] diff --git a/wiki/concepts/ECS-Deploy-Runner.md b/wiki/concepts/ECS-Deploy-Runner.md deleted file mode 100644 index 58cb62c7..00000000 --- a/wiki/concepts/ECS-Deploy-Runner.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "ECS Deploy Runner" -type: concept -tags: [Terraform, ECS, Deployment, IaC, Docker, CI/CD] -sources: - - ctp-topic-16-cross-account-terraform-modules.md -last_updated: 2026-05-15 ---- - -## Overview - -ECS Deploy Runner（EDR）是运行在 AWS ECS 上的 Docker 容器，负责在跨账号 Terraform 部署流水线中执行 `terraform plan` 和 `terraform apply` 命令。它是流水线的实际执行单元。 - -## How It Works - -1. **触发**：Jenkins（托管在 [[Shared-Account]]）检测到模块目录中的 `cross-account.json` 标记文件 -2. **启动**：ECS Deploy Runner 在 Shared Account 的 ECS 集群中启动 -3. **Assume Role**：通过 Assume Role 获取两个目标账号 IAM 角色的临时凭证： - - `[[TF-State-Bucket-Accessor]]`：读取目标账号的 Terraform 状态文件 - - `[[Cross-account-ECS-Deploy-Runner-Role]]`：在目标账号中执行资源部署 -4. **执行**：运行 Terraform CLI 命令完成部署 - -## Key Characteristics - -- **容器化**：运行在 Docker 容器中，环境一致性好 -- **按需启动**：每次部署触发一次容器启动，无长期占用 -- **临时凭证**：通过 Assume Role 获取的短期凭证，最小化密钥暴露时间 -- **与 Terragrunt 配合**：Terragrunt HCL 文件配置角色切换逻辑 - -## Local vs CI/CD Difference - -| 环境 | 角色处理 | -|------|---------| -| 本地开发 | Terragrunt 自动处理角色切换，无需手动 Assume Role | -| Jenkins CI/CD | EDR 通过 Assume Role 获取两个专用角色的临时凭证 | - -## Relationships - -- [[CI/CD Pipeline]]：EDR 是 CI/CD 流水线的执行层 -- [[Cross-account-Terraform-Modules]]：EDR 是跨账号 Terraform 模块方案的核心执行组件 -- [[Shared-Account]]：EDR 运行在 Shared Account 的 ECS 集群中 -- [[Assume-Role]]：EDR 通过 Assume Role 获取跨账号权限 -- [[Docker-Containerization]]：EDR 以 Docker 容器形式运行 diff --git a/wiki/concepts/ECS-Module.md b/wiki/concepts/ECS-Module.md deleted file mode 100644 index e755cc15..00000000 --- a/wiki/concepts/ECS-Module.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "ECS Module" -type: concept -tags: - - ECS - - Terraform - - IaC - - Modules -sources: - - learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi -last_updated: 2023-08-08 ---- - -## Definition -ECS Module 是 CTP/SRE 团队基于 Gruntwork 仓库构建的 Terraform 模块，用于在 AWS 上自动化部署和管理 ECS（Elastic Container Service）容器化应用。 - -## Core Features -- **Docker 容器化**：将应用封装为 Docker 容器作为逻辑部署单元 -- **多部署模式**：支持 EC2 实例部署 -- **自动扩缩容（Auto-Scaling）**：根据负载动态调整容器实例数量 -- **自动故障恢复（Auto-Healing）**：自动重启失败的容器任务 -- **金丝雀部署（Canary Deployment）**：支持渐进式流量切换 -- **集中管理**：通过 Listener 方式统一管理各产品团队的 ECS 部署 - -## Architecture -- 基于 Gruntwork terraform-aws-ecs 模块 -- 使用 VPC、ELB 安全组、EFS 卷作为前置条件 -- 支持 YAML/JSON 配置传递 -- 集成 CloudWatch、Splunk、Grafana、Prometheus 监控 - -## Listener Approach（集中管理） -避免各产品团队直接下载 Gruntwork 模板并本地使用导致的碎片化问题，改为统一通过 Listener 机制集中管理和更新 ECS 配置。 - -## Connections -- [[Gruntwork]] ← based_on ← ECS Module（技术基础来源） -- [[ECS]] ← manages ← ECS Module（AWS ECS 服务层面） -- [[Canary-Deployment]] ← included_in ← ECS Module -- [[Cloud-Transformation-Programme]] ← implements ← ECS Module（CTP 核心产出） -- [[Terraform]] ← tool ← ECS Module（模块实现工具） diff --git a/wiki/concepts/ECS.md b/wiki/concepts/ECS.md deleted file mode 100644 index 9f3bd72f..00000000 --- a/wiki/concepts/ECS.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "Amazon ECS" -type: concept -tags: - - AWS - - ECS - - Containers - - Orchestration -aliases: - - ECS - - Elastic Container Service -sources: - - learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording - - ctp-topic-48-terraform-vs-terragrunt.md -last_updated: 2026-05-13 ---- - -## Overview - -Amazon ECS（Elastic Container Service）是 AWS 提供的完全托管式容器编排服务，用于在 AWS 上运行 Docker 容器。支持 Fargate（无服务器模式）和 EC2（自管理虚拟机模式）两种启动类型。 - -## Key Features - -- **完全托管**：AWS 自动管理容器编排基础设施 -- **Fargate 启动类型**：无需管理服务器或集群 -- **EC2 启动类型**：对底层计算资源有更多控制 -- **与 AWS 服务深度集成**：IAM、VPC、CloudWatch、Spot 实例等 - -## Spot Instance Integration - -ECS 与 EC2 Spot 实例深度集成： -- 支持 Spot 实例池多样化 -- 支持 Spot 中断处理自动化 -- 可配合 Auto Scaling 实现弹性 -- Spot + Graviton 可实现双重成本优化 - -## ECS vs EKS - -| 特性 | ECS | EKS | -|------|-----|-----| -| 控制复杂度 | 低（AWS 原生） | 高（Kubernetes 标准） | -| 迁移性 | AWS 锁定 | 跨云可移植 | -| 功能丰富度 | 基础够用 | 生态丰富 | -| Spot 支持 | ✅ | ✅ | -| 适用场景 | AWS 优先，简单需求 | 多云策略，复杂需求 | - -## Related Pages - -- [[EC2-Spot-Instances]]：Spot 实例集成 -- [[EKS]]：另一种容器编排选择 -- [[Graviton]]：可与 ECS 配合使用降低成本 -- [[FinOps]]：成本优化 -- [[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]] diff --git a/wiki/concepts/EFS-vs-EBS.md b/wiki/concepts/EFS-vs-EBS.md deleted file mode 100644 index 91f4a878..00000000 --- a/wiki/concepts/EFS-vs-EBS.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: "EFS vs EBS" -type: concept -tags: [aws, storage, cloud-migration, devops] -last_updated: 2026-04-23 ---- - -## Definition -AWS 提供多种存储解决方案，其中 EFS（Elastic File System）和 EBS（Elastic Block Store）是两种核心存储类型，适用于不同场景。 - -## Comparison Table - -| 特性 | EBS | EFS | -|------|-----|-----| -| **类型** | 块存储（类似虚拟硬盘） | 文件存储（类似网络文件系统 NFS）| -| **访问方式** | 单个 EC2 实例 | 多个 EC2 实例同时访问 | -| **性能** | 高性能、低延迟 | 中等性能，适合共享访问 | -| **价格** | 按存储量和 Provisioned IOPS 计费 | 按实际使用量计费 | -| **持久性** | 独立于 EC2 生命周期 | 可用区冗余存储 | -| **适用场景** | 数据库、日志、系统盘 | 共享文件存储、备份、内容管理 | - -## Cloud Migration Context - -### [[Octane-Hub]] 的存储选型经验 - -#### 问题发现 -- 最初考虑使用 EFS 用于存储 -- 发现性能问题：**数据库无法直接在 EFS 上运行** -- EFS 的延迟和吞吐量不适合高 IOPS 需求的工作负载 - -#### 最终方案 -| 数据类型 | 存储选型 | 原因 | -|----------|----------|------| -| MSSQL 数据库（实时）| EBS | 需要高 IOPS、低延迟 | -| 数据库备份 | EFS | 适合大容量、低频访问 | -| 未来规划 | S3 | 成本优化目标 | - -### 存储选型原则 -1. **高 IOPS 需求**（数据库）→ EBS -2. **共享文件访问**（多实例）→ EFS -3. **成本优化/归档** → S3 -4. **混合策略**：热数据用 EBS/EFS，冷数据用 S3 - -## Key Differences - -### EBS 特点 -- 作为 EC2 实例的独立卷挂载 -- 可单独创建快照进行备份 -- 支持 `io1`/`io2` 类型提供高 IOPS -- 适合：操作系统、数据库、应用数据 - -### EFS 特点 -- 通过 NFS 协议访问 -- 支持多可用区部署 -- 自动扩展，按使用量计费 -- 适合：Web 服务器共享存储、代码仓库、备份文件 - -## Related Concepts -- [[AWS-Landing-Zone]]：企业级 AWS 环境架构 -- [[Octane-Hub]]：Docker 容器化工作负载迁移案例 -- [[Cloud-Migration]]：云迁移最佳实践 - -## References -- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]] diff --git a/wiki/concepts/EKS-Auto-Mode.md b/wiki/concepts/EKS-Auto-Mode.md deleted file mode 100644 index 163bbe76..00000000 --- a/wiki/concepts/EKS-Auto-Mode.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "EKS Auto Mode" -type: concept -tags: [] -last_updated: 2025-03-04 ---- - -## Summary -EKS Auto Mode 是 Amazon EKS 的半托管计算模式，将 Kubernetes 数据平面（计算节点）的生命周期管理责任从用户扩展至 AWS。用户只需关注 VPC 配置、集群配置和 workload 配置，AWS 自动处理节点采购、OS 补丁、安全更新和滚动升级。 - -## Definition -AWS EKS 的半托管计算选项，通过 Carpenter Controller 自动管理节点池的生命周期，包括实例采购、操作系统（Bottlerocket）维护、安全补丁和版本升级。兼容所有 Kubernetes-compliant 工作负载，无需修改应用代码。 - -## Key Components -- **Carpenter Controller**：计算控制器，运行于集群内，负责节点池生命周期管理、AMI 版本管理和滚动升级编排 -- **Bottlerocket OS**：Amazon 开发的容器专用最小化 Linux 操作系统，专为 Auto Mode 设计，自动应用安全补丁 -- **Default Node Pools**：两个内置节点池（General Purpose 锁定 AMD64 + System 带 taint），权重为零支持自定义池优先级 -- **Core Capabilities**：计算（Carpenter）、网络（AWS LB Controller）、存储（EBS CSI）、安全（Pod Identity Associations） -- **Prefix Delegation**：VPCCNI 特性，为 Pod 分配 /28 前缀 IP 块，默认启用 - -## Mechanism -1. 用户启用 Auto Mode 后，AWS 在集群内部署 Carpenter Controller（作为 core capability） -2. Carpenter 监听控制面版本变更，自动识别新版本对应的 AMI -3. 控制面升级完成后，Carpenter 自动触发节点 AMI 滚动升级 -4. 12% 实例费用溢价覆盖自动化管理成本 - -## Trade-offs -- **优点**：大幅降低 K8s 运维负担；自动化 OS 安全补丁；版本升级自动化 -- **缺点**：每个 Auto Mode 实例附加 12% 管理溢价；节点配置灵活性受限；不支持裸金属实例 - -## Related Concepts -- [[Carpenter Controller]]：EKS Auto Mode 的计算控制器实现 -- [[Bottlerocket OS]]：Auto Mode 的默认操作系统 -- [[Pod Identity Associations]]：Auto Mode 的 Pod 级 IAM 权限控制机制 -- [[Kubernetes]]：EKS Auto Mode 基于的标准容器编排平台 diff --git a/wiki/concepts/EKS-Custom-Networking.md b/wiki/concepts/EKS-Custom-Networking.md deleted file mode 100644 index 0f99142d..00000000 --- a/wiki/concepts/EKS-Custom-Networking.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "EKS Custom Networking" -type: concept -tags: - - AWS - - EKS - - Kubernetes - - Networking - - VPC - - IPAM -sources: - - ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone -last_updated: 2026-04-28 ---- - -## Overview -EKS Custom Networking 是 AWS EKS 提供的一项功能，允许用户绕过默认的 VPC CNI（Amazon VPC CNI plugin for Kubernetes）行为，自定义 Pod 的网络 IP 分配策略。这在 IP 地址受限或需要特殊网络配置的环境中尤为重要。 - -## Definition -EKS 自定义网络（Custom Networking）通过以下机制实现： -- 通过 EKS 模块的自定义网络配置标志（flag）启用 -- 支持指定自定义的弹性网络接口（ENI）配置 -- 允许 Pod 使用独立于默认 VPC 子网的 IP 地址池 - -## Use Case: AWS Lab Landing Zone -在 AWS Lab Landing Zone 环境中，Micro Focus 网络的 IP 地址池有限，无法满足 EKS 集群中大量 Pod 的 IP 分配需求。通过自定义网络配置： -1. 在独立私有子网（非主 VPC 子网）创建 EKS 集群 -2. 启用 EKS 模块的自定义网络标志 -3. EKS 使用指定的子网和 IP 范围分配 Pod 地址 - -## Core Mechanism -``` -EKS Module (Terraform) - └── custom_networking_enabled = true - ├── subnet_ids = [custom_subnet_ids] - └── additional_eni_config = ... -``` - -## Key Benefits -- **突破 VPC CIDR 限制**：在受限网络环境中仍可部署大规模 Pod -- **IP 地址灵活性**：使用专用 IP 池，无需消耗 VPC 主网络地址 -- **网络隔离**：独立子网提供额外的网络安全边界 - -## Limitations -- 需要 Terraform/Terragrunt 模块支持自定义网络标志 -- Atlantis 当前不支持 EKS 集群部署（需使用 Jenkins + Terragrunt） -- 容器安全加固需额外考虑网络隔离 - -## Related Concepts -- [[Amazon-EKS]]：应用自定义网络技术的容器编排平台 -- [[Host-Network-Mode]]：Pod 规范层面的网络模式配置 -- [[EMI-Elastic-Network-Interface]]：ENI 多 IP 分配（EMI）在 EKS 中的应用 -- [[IPAM]]：IP 地址管理，与自定义网络协同 - -## Related Sources -- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] diff --git a/wiki/concepts/ELK-Stack.md b/wiki/concepts/ELK-Stack.md deleted file mode 100644 index 664a0c63..00000000 --- a/wiki/concepts/ELK-Stack.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "ELK Stack" -type: concept -tags: [DevOps, Observability, Logging, OpenSource, AWS] -sources: [ctp-topic-54-esm-saas-log-analytics] -last_updated: 2026-04-25 ---- - -# ELK Stack - -**ELK Stack** 是由 Elasticsearch、Logstash 和 Kibana 三个开源组件组成的日志分析与全文检索技术栈，是企业级日志分析的业界标准方案。 - -## Components - -| Component | Role | Description | -|-----------|------|-------------| -| **Elasticsearch** | 存储与检索引擎 | 分布式全文搜索和分析引擎，负责存储和查询日志数据 | -| **Logstash** | 数据处理管道 | 采集、解析和转换日志字段，为每列数据赋予语义 | -| **Kibana** | 可视化前端 | 日志文件可视化和分析的用户界面 | -| **BEATS** | 轻量级采集代理 | 部署在应用侧的日志采集器家族（Filebeat/Metricbeat 等） | - -## Architecture - -``` -应用层 (Application VPC) - └── Filebeat (容器/DaemonSet) → 持续采集日志 - ↓ -日志层 (Logging VPC) - └── Logstash → 解析日志字段 - ↓ - └── (Redis Buffer, 可选) → 防止 Logstash 过载 - ↓ - └── Elasticsearch / OpenSearch → 存储索引 - ↓ - └── Kibana → 可视化查询 -``` - -## OpenSearch (AWS Fork) - -**OpenSearch** 是 Elasticsearch 7.10.2 的开源分支，由 AWS 主导维护，提供与 Elasticsearch 兼容的 API，作为 AWS 托管服务（Amazon OpenSearch Service）提供。ELK 栈中 Elasticsearch 可被 OpenSearch 无缝替代。 - -## Related Concepts - -- [[Centralized-Logging]]：集中式日志管理的总体概念，ELK 是其核心实现技术 -- [[Cloud-Monitoring]]：可观测性三支柱（指标/日志/链路追踪）之一 -- [[OpenSearch]]：ELK 中 Elasticsearch 的 AWS 托管替代 -- [[Kibana]]：ELK 栈的可视化层 -- [[BEATS]]：ELK 栈的轻量级日志采集代理 - -## Key Claims - -- ELK 栈是开源日志分析的标准方案，架构成熟、生态丰富 -- Filebeat 常用作 Kubernetes 容器环境下的日志采集器（DaemonSet 部署） -- Logstash 作为处理管道，可解析 JSON/Nginx/Apache 等多格式日志 -- OpenSearch 是 Elasticsearch 的开源分支，AWS 提供托管服务（OpenSearch Service） -- VPC 间日志传输走私有网络，不经过互联网 - -## Sources - -- [[ctp-topic-54-esm-saas-log-analytics]] diff --git a/wiki/concepts/EMI-Elastic-Network-Interface.md b/wiki/concepts/EMI-Elastic-Network-Interface.md deleted file mode 100644 index 1c2eb736..00000000 --- a/wiki/concepts/EMI-Elastic-Network-Interface.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "EMI (Elastic Network Interface) Multi-IP" -type: concept -tags: [AWS, EKS, networking, VPC, CIDR, pod-networking] -last_updated: 2026-04-28 ---- - -## Definition - -EMI（Elastic Network Interface Multi-IP，弹性网络接口多 IP）是 AWS 提供的网络扩展机制，通过为 Pod 分配额外的弹性网络接口（ENI）及其上的辅助 IP 地址，解决 EKS 集群中 VPC CIDR 地址空间不足的问题。每个 ENI 允许附加多个辅助 IP，每个 IP 可分配给一个 Pod，相比默认的 AWS VPC CNI 插件可大幅增加单个节点可运行的 Pod 数量。 - -## Key Mechanisms - -- **ENI 附加**：为工作节点附加额外 ENI 以增加可用 IP 数量 -- **IP 分配**：每个 ENI 上的辅助 IP 分配给 Pod，实现 Pod 级 IP 直接寻址 -- **CIDR 扩展**：不依赖 VPC 主 CIDR 范围，通过 ENI 附加 IP 绕过 VPC 地址空间限制 -- **安全组绑定**：ENI 及其上的 Pod IP 继承安全组配置 -- **与 AWS VPC CNI 插件的关系**：AWS VPC CNI 是默认插件，EMI 是其增强模式，支持 Prefix Delegation - -## Problem Solved - -VPC CIDR 限制导致大型 EKS 集群 Pod 数量受限于可用 IP 地址： -- 标准 AWS VPC CNI 每个 ENI 最多约 10-15 个 IP（受实例类型限制） -- EMI 通过 ENI 附加更多辅助 IP，显著提升 Pod 密度 -- 特别适用于 IP 密集型工作负载（如微服务架构） - -## Sources -- [[ctp-topic-70-eks-deployment-using-iac]] -- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] diff --git a/wiki/concepts/ESN.md b/wiki/concepts/ESN.md deleted file mode 100644 index 71013beb..00000000 --- a/wiki/concepts/ESN.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: "ESN (Entreprise de Services Numériques)" -type: concept -tags: [france, consulting, esn, si, market-structure] -sources: [specialized-french-consulting-market] -last_updated: 2026-04-25 ---- - -## Definition - -ESN（Entreprise de Services Numériques）是法国特有的 IT 咨询公司生态，中文可理解为"数字服务企业"，前身是 SSII（Société de Services et d'Ingénierie en Informatique）。法国市场约 80% 的企业 IT 项目通过 ESN 生态完成——这是理解法国 IT 自由职业市场结构的基石。 - -## ESN Tier Classification - -| 级别 | 代表企业 | 典型 Margin | 顾问议价能力 | 销售周期 | -|------|---------|------------|------------|---------| -| **Tier 1 — 全球型** | Accenture, Capgemini, Atos, CGI, Sopra Steria | 35-50% | 低（标准化定价表） | 4-8 周 | -| **Tier 2 — 专项型** | Cloudity, Niji, SpikeeLabs, EI-Technologies,，公有云 MSP | 25-40% | 中（可协商） | 2-4 周 | -| **Tier 3 — 经纪型** | Free-Work listings, 小型中介 | 15-25% | 高（体量博弈） | 1-2 周 | - -## Margin Architecture - -``` -客户端报价（Sell Rate）: 1,000 €/天 - │ - ┌─────┴─────┐ - │ ESN Margin │ - │ 25-40% │ - └─────┬─────┘ - │ -顾问到手 TJM（Buy Rate）: 600-750 €/天 -``` - -**核心公式**：客户端报价 × (1 - ESN Margin) = 顾问 TJM -- ESN 对顾问的购买价（Buy Rate / TJM brut）约是客户端报价的 60-75% -- 换算：知道客户端预算即可反推顾问 TJM 区间 - -## How ESNs Make Money - -ESN 赚取的是 **Margin = 客户端报价 - 顾问到手 TJM** - -例：客户端 1,000€/天，ESN 付顾问 700€/天 → ESN 赚 300€/天（30% Margin） - -### ESN 的实际成本结构（对客户端） -- 顾问 TJM × 1.4~1.7 = 客户端报价（包含 ESN 管理成本 + 利润 + 风险溢价） -- 超过 1.7 倍说明顾问费率偏低或 ESN 议价能力过强 - -## Negotiation Implications - -1. **逆向反推**：若知道客户端预算，可反推顾问 TJM 区间 -2. **Tier 2 机会**：Tier 2 ESN 灵活性最高，Margin 25-40% 意味着顾问有更多谈判空间 -3. **Rate Floor 信号**：低于 550€/天的 Salesforce 架构师 TJM 对 ESN 传递绝望信号，永久锚定谈判起点 -4. **平台公开价**：Malt 等平台上的公开报价对 ESN 可见，成为市场参照锚点 - -## Key ESN Market Dynamics - -- **NET-30 实际 = 60-90 天**：法国 ESN 链中付款延迟是结构性常态，顾问须预留现金流缓冲 -- **季节性**：1 月预算重启（最佳提案时机）、7-8 月暑期放缓、9 月秋季高峰 -- **续约博弈**：ESN 在续约时通常要求 TJM 持平或下调，顾问需有谈判策略 - -## Contradictions - -- **Tier 1 稳定性 vs 低价**：大 ESN 提供稳定性但标准化定价，顾问往往被压价 -- **Tier 3 速度 vs 风险**：小经纪型 ESN 响应快但 Margin 压得狠，且付款风险更高 - -## Aliases -- ESN -- SSII（历史名称，Société de Services et d'Ingénierie en Informatique） -- Cabinet de Conseil（咨询公司统称，但 ESN 特指 IT 领域） -- Intégrateur（系统集成商） -- Société de Services diff --git a/wiki/concepts/Early-Live-Support.md b/wiki/concepts/Early-Live-Support.md deleted file mode 100644 index 8d3dc749..00000000 --- a/wiki/concepts/Early-Live-Support.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Early Live Support" -type: concept -tags: [SRE, Cloud-Transformation, Go-Live, Support-Model] -last_updated: 2026-04-14 ---- - -## Definition - -Early Live Support（早期上线支持）是 Build（构建）与 BAU（日常运维）之间的过渡阶段。在这个阶段，SRE 团队与产品团队紧密协作，确保新服务平稳上线并建立持续运营的支持模式。 - -## Phase Overview - -``` -Build ──────→ Early Live Support ──────→ BAU - ↑ ↑ ↑ -产品团队主导 ↑ SRE 主导 - SRE + 产品团队协作 -``` - -## Key Activities - -### 1. Go-Live Checklist - -Early Live Support 阶段需要完成以下检查清单： - -| Item | Description | -|------|-------------| -| 监控覆盖 | 所有关键服务和基础设施都得到充分监控 | -| 支持模型 | 明确 On-call Schedule 和升级路径 | -| 事件响应流程 | 建立清晰的事件响应和升级流程 | -| SLO/SLI 定义 | 定义服务等级目标和指标 | -| 文档交接 | 完成技术文档和运维手册 | - -### 2. SRE Collaboration - -SRE 团队在此阶段： -- 提供技术支持，协助解决上线问题 -- 验证监控和告警的有效性 -- 建立与产品团队的沟通渠道 -- 收集 BAU 阶段的运维需求 - -### 3. Handoff Criteria - -从 Early Live Support 过渡到 BAU 的标准： -- 所有监控面板正常运行 -- 事件响应流程经过演练 -- On-call Schedule 与 Service Desk 集成 -- 产品团队完成运维培训 - -## Relationship with SRE - -Early Live Support 是 SRE 三阶段支持模型的关键环节： - -1. **Build**：SRE 参与架构评审，定义 SLO/SLI -2. **Early Live Support**：SRE 提供上线支持，确保平稳过渡 -3. **BAU**：SRE 提供持续监控和可靠性保障 - -## Sources - -- [[ctp-topic-30-managing-change]] diff --git a/wiki/concepts/Earnings-Beat-Miss.md b/wiki/concepts/Earnings-Beat-Miss.md deleted file mode 100644 index baf9a4c0..00000000 --- a/wiki/concepts/Earnings-Beat-Miss.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Earnings Beat/Miss" -type: concept -tags: [] -last_updated: 2026-04-22 ---- - -## Definition -Earnings Beat/Miss 是衡量公司实际财报表现与分析师预期之间差距的指标。Beat（超预期）指实际 EPS/营收等指标高于预期；Miss（低于预期）则相反。是 AI 格式化财报摘要中的核心判断输出。 - -## Aliases -- Beat/Miss -- Earnings Surprise -- 财报超预期 / 财报低于预期 - -## Key Metrics -- **EPS**（Earnings Per Share）：每股收益 -- **Revenue**（营收）：季度/年度总收入 -- **AI Highlights**：AI 相关业务亮点 -- **Guidance**（指引）：管理层对未来业绩的前瞻性预期 - -## Context -在 [[Earnings Tracker]] 工作流中，OpenClaw 搜索财报结果后，格式化摘要需包含 beat/miss 判断及上述关键指标，作为 Telegram 投递的核心内容。Beat/Miss 直接影响股价短期走势，是财报读者最关心的结论性信息。 - -## Related Concepts -- [[Earnings Calendar]] — 触发时机 -- [[Earnings Tracker]] — 使用此指标的工作流 -- [[AI-Powered Digest]] — 格式化摘要的通用模式 diff --git a/wiki/concepts/Earnings-Calendar.md b/wiki/concepts/Earnings-Calendar.md deleted file mode 100644 index e5064776..00000000 --- a/wiki/concepts/Earnings-Calendar.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "Earnings Calendar" -type: concept -tags: [] -last_updated: 2026-04-22 ---- - -## Definition -Earnings Calendar（财报日历）是上市公司财报发布时间表，列出每家公司计划发布季度/年度财务报告的具体日期和时间。AI Agent 自动化追踪系统的输入数据源。 - -## Aliases -- Earnings Schedule -- 财报日历 -- 财报发布日程 - -## Context -在 [[Earnings Tracker]] 工作流中，Earnings Calendar 是第一步数据源——OpenClaw Cron Job 每周日扫描日历，过滤用户关注的公司（NVDA/MSFT/GOOGL/META/AMZN/TSLA/AMD 等）后，在 Telegram 投递预览列表，用户确认后启动下一步追踪。 - -## Related Concepts -- [[Earnings Beat/Miss]] — 财报结果判断 -- [[Earnings Tracker]] — 使用 Earnings Calendar 的自动化追踪工作流 -- [[Daily-Digest]] — 同属定时信息摘要模式 diff --git a/wiki/concepts/Echidna.md b/wiki/concepts/Echidna.md deleted file mode 100644 index 42c5e904..00000000 --- a/wiki/concepts/Echidna.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: "Echidna（属性化模糊测试）" -type: concept -tags: [blockchain, security, smart-contract, fuzzing, property-based-testing] -sources: [blockchain-security-auditor] -last_updated: 2026-05-30 ---- - -## Aliases -- Echidna -- Echidna Fuzzer -- Property-Based Fuzzing - -## Definition - -Echidna 是一个属性化模糊测试（Property-Based Fuzzing）工具，专门用于智能合约安全测试。它通过随机生成交易序列，持续验证协议定义的不变性（invariants）是否始终成立。当不变性被违反时，Echidna 会生成触发该违规的具体交易序列作为 PoC。 - -## How It Works - -1. **定义不变性**：用 Solidity 编写断言或属性 -2. **生成随机交易**：Echidna 以随机参数调用合约函数 -3. **监控不变性**：每次状态变更后检查断言 -4. **生成 PoC**：发现违规时输出触发序列 - -## Example Test - -```solidity -// SPDX-License-Identifier: MIT -pragma solidity ^0.8.24; - -import {Test} from "forge-std/Test.sol"; -import {Vault} from "../src/Vault.sol"; - -contract EchidnaInvariantTest { - Vault public vault; - - constructor() { - vault = new Vault(); - } - - // 不变性：任何时刻总存款 = 所有用户余额之和 - function echidna_total_deposits_equals_sum() public view returns (bool) { - return vault.totalDeposits() == vault.getSumOfBalances(); - } -} -``` - -## Configuration - -```yaml -# echidna-config.yaml -testMode: assertion # 断言模式 -testLimit: 500000 # 最大测试数 -timeout: 3600 # 超时（秒） -sender: ["0x000...1", "0x000...2"] # 发送者地址 -``` - -## Relationship to Other Tools - -| Tool | Method | Strength | -|------|--------|----------| -| [[Slither]] | 静态分析 | 快速扫描，规则匹配 | -| [[Mythril]] | 符号执行 | 深度路径覆盖 | -| [[Echidna]] | 属性化模糊测试 | 随机交易序列，不变性验证 | - -- **Echidna** 是 Slither 和 Mythril 的**补充**，不是替代 -- Slither 找规则性漏洞 → Echidna 找逻辑漏洞 -- Foundry 的 `forge invariant` 命令也提供类似功能 - -## Limitations - -- 不变性定义错误会导致漏报 -- 复杂状态空间难以在合理时间覆盖 -- 需要开发者定义正确的不变性 - -## Connections -- [[Blockchain-Security-Auditor]] ← uses ← [[Echidna]] -- [[Foundry]] ← provides invariant testing ← [[Echidna]] -- [[Formal-Verification]] ← complements ← [[Echidna]] diff --git a/wiki/concepts/Economy-Balance.md b/wiki/concepts/Economy-Balance.md deleted file mode 100644 index 44499775..00000000 --- a/wiki/concepts/Economy-Balance.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: "Economy Balance" -type: concept -tags: [game-design, economy, monetization, balance] -sources: [game-designer] -last_updated: 2026-04-26 ---- - -## Definition - -Economy Balance（经济平衡）是游戏内资源流通系统的设计与调优过程——通过控制来源（source）、汇点（sink）和均衡曲线，确保游戏经济在不同玩家路径上都保持健康（无无限循环、无死胡同、无通胀/通缩）。 - -## Core Framework - -### Supply & Demand Model - -游戏经济本质上是资源的供给-需求系统： -- **Source**（资源来源）：玩家获取货币/道具的途径（任务奖励/掉落/购买） -- **Sink**（资源汇点）：资源被消耗的途径（升级/强化/交易税/销毁） -- **Equilibrium**：供需平衡曲线，决定经济稳定性 - -> 失衡信号：Source > Sink → 通货膨胀（资源贬值）；Source < Sink → 通货紧缩（玩家挫败感） - -### Player Archetypes - -不同付费意愿的玩家需要不同的经济设计： -- **Whales（鲸鱼）**：高付费，需要 Prestige Sink（声望消耗机制）防止经济饱和 -- **Dolphins（海豚）**：中等付费，需要 Value Sink（性价比消耗机制） -- **Minnows（小鱼）**：免费玩家，需要 Earnable Aspirational Goals（可获取的激励目标） - -## Inflation Detection - -定义关键指标并设置阈值： -- **Metric**：每活跃玩家每日货币增量（Currency per Active Player per Day） -- **Threshold**：当指标超过预设值时触发平衡调整流程 -- **Adjustment**：调整 Source（降低产出）或 Sink（增加消耗）以恢复平衡 - -## Advanced Methods - -### Monte Carlo Simulation - -在代码实现前对进度曲线进行蒙特卡洛模拟： -- 模拟 1000+ 随机玩家路径 -- 识别极端情况（极速通关 vs 长期卡关） -- 提前发现经济漏洞 - -### Paper Simulation - -在电子表格中进行玩家经济路径模拟： -- 穷举主要玩家路径 -- 验证无无限资源获取循环 -- 测试边界条件（最小/最大资源持有量） - -## Design Standards - -| Variable | Base Value | Min | Max | Tuning Notes | -|----------|-----------|-----|-----|--------------| -| Player HP | 100 | 50 | 200 | Scales with level | -| Enemy Damage | 15 | 5 | 40 | [PLACEHOLDER] - test at level 5 | -| Resource Drop % | 0.25 | 0.1 | 0.6 | Adjust per difficulty | -| Ability Cooldown | 8s | 3s | 15s | Feel test required | - -> 所有数值从假设开始，用 `[PLACEHOLDER]` 标记，直至通过测试验证 - -## Relationship to Core Gameplay Loop - -Economy Balance 支撑会话循环和长期循环： -- **会话循环**：资源稀缺性制造张力（Source - Sink = 可用资源） -- **长期循环**：货币通胀/通缩直接影响玩家成就感曲线 - -## Related Concepts - -- [[Core Gameplay Loop]]：经济系统为循环提供资源流通基础 -- [[Behavioral Economics in Games]]：经济设计中的行为心理学应用（损失厌恶、变率奖励） -- [[Player Archetypes]]：不同付费玩家的经济需求差异 diff --git a/wiki/concepts/EditorialWorkflow.md b/wiki/concepts/EditorialWorkflow.md deleted file mode 100644 index 6a3fa808..00000000 --- a/wiki/concepts/EditorialWorkflow.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: "Editorial Workflow" -type: concept -tags: ["writing", "process", "iteration", "quality"] -sources: ["marketing-book-co-author"] -last_updated: 2026-04-30 ---- - -## Definition - -编辑工作流（Editorial Workflow）是一套以版本化管理、编辑注释显式化和明确反馈回路为核心的迭代修订过程。在 Book Co-Author Agent 的语境中，编辑工作流是确保书籍质量、保持作者声音、保护品类定位的核心机制。 - -## Core Components - -### 1. 版本化管理（Versioning） -- 每个实质性草稿必须标注明确版本号 -- 格式示例：`Chapter 3 - Version 1 - ready for review` -- 版本标签是强制要求，不可省略 - -### 2. 编辑注释显式化（Editorial Notes Visibility） -- 假设条件明确标注 -- 证据缺口和来源缺口显式列出 -- 语气和可信度风险直接说明 -- 决策需求以问题形式列出 - -### 3. 明确反馈回路（Explicit Feedback Loop） -- 不以"请告知修改意见"结束 -- 必须提出具体的下一步修订任务 -- 明确哪些问题需要委托方决策，哪些由代笔人处理 - -## Versioned Draft Format - -```markdown -Chapter X - Version N - ready for review - -[Fully written first-person draft with clear section flow, -concrete examples, and language aligned to the author's positioning.] -``` - -## Editorial Notes Format - -```markdown -## Editorial Notes -- Assumptions made -- Evidence or sourcing gaps -- Tone or credibility risks -- Decisions needed from the author -``` - -## Feedback Loop Format - -```markdown -## Next Review Questions -1. Which claim feels strongest and should be expanded? -2. Where does the chapter still sound unlike you? -3. Which example needs better proof, detail, or chronology? -``` - -## Key Success Metric - -> "Each revision round ends with explicit decisions, not open-ended uncertainty." - -编辑工作流的最终目标：每轮修订后，双方（代笔人+委托方）都有明确的行动项，而非模糊的"继续打磨"。 - -## Related Concepts -- [[Voice Protection]] — 编辑工作流服务于声音保护 -- [[Ghostwriting]] — 编辑工作流是代笔写作的核心流程 -- [[Chapter Blueprint]] — 蓝图是编辑工作流的前置规划步骤 -- [[Narrative Architecture]] — 编辑工作流需维护叙事架构不被破坏 diff --git a/wiki/concepts/EffectiveTaxRate.md b/wiki/concepts/EffectiveTaxRate.md deleted file mode 100644 index 41f88b26..00000000 --- a/wiki/concepts/EffectiveTaxRate.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Effective Tax Rate (ETR)" -type: concept -tags: ["tax", "finance", "kpi", "compliance"] -last_updated: 2026-05-02 ---- - -## Definition - -有效税率（Effective Tax Rate, ETR）是企业实际税负占税前收入的比例，是衡量税务筹划效果的核心 KPI。计算公式： - -``` -ETR = 总税负 ÷ 税前收入 -``` - -## ETR vs Statutory Rate - -| 指标 | 说明 | -|------|------| -| Statutory Rate | 法定税率（如美国联邦 21%） | -| ETR | 实际有效税率（含各项抵扣和优惠） | -| Cash Tax Rate | 实际支付现金税率（含递延税） | - -ETR 通常低于 Statutory Rate，因为存在税收抵免（Tax Credits）、递延（Deferred Income）和国际税率差异等优化空间。 - -## ETR Waterfall Components - -典型 ETR 瀑布分解： -- Federal Statutory Tax（联邦法定税率） -- State & Local Taxes（SALT） -- International Rate Differential（国际税率差异） -- R&D Tax Credits（R&D 税收抵免） -- QBI Deduction（合格商业收入扣除） -- Other Permanent/Temporary Adjustments（其他永久/暂时性调整） - -## Target - -- **[[finance-tax-strategist]]** 目标：ETR ≤ 行业同行中位数 -- 成功标准：审计调整 < 2% 总税负 - -## Sources - -- [[finance-tax-strategist]] - -## Related Concepts - -- [[TransferPricing]] -- [[GILTI]] -- [[BEAT]] diff --git a/wiki/concepts/Elasticity.md b/wiki/concepts/Elasticity.md deleted file mode 100644 index 05a9640e..00000000 --- a/wiki/concepts/Elasticity.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Elasticity" -type: concept -tags: [sre, cloud, scalability, reliability, capacity-planning] -last_updated: 2026-04-20 ---- - -# Elasticity - -弹性（Elasticity）是指系统在无需人工干预的情况下，根据需求动态调整容量的能力，是云原生的核心特性之一。 - -## Definition -真正的弹性需要**策略、测试和对瓶颈的认知**。它不仅仅是自动扩容，而是一个包含规划、执行和验证的完整体系。 - -## Core Requirements -1. **策略（Policy）**：明确定义扩容和缩容的规则 -2. **测试（Testing）**：在非生产环境验证弹性行为 -3. **瓶颈认知（Bottleneck Awareness）**：理解系统的性能瓶颈在哪里 - -## Elasticity vs. Autoscaling - -| Aspect | [[Autoscaling]] | Elasticity | -|--------|-----------------|-----------| -| 性质 | 工具/机制 | 设计原则/能力 | -| 范围 | 单一维度（资源） | 多维度（容量、性能、成本） | -| 前瞻性 | 被动响应 | 主动规划 | -| 人类角色 | 可能被排除 | 必须参与 | - -## Key Insight -Autoscaling 是实现弹性的**工具之一**，但 Autoscaling 本身不等同于弹性。缺乏策略和测试的 Autoscaling 可能在故障期间造成更大损害。 - -## Implementation Pillars -- **Capacity Planning**：预测需求，提前规划 -- **Cost Optimization**：在弹性和成本之间取得平衡 -- **Observability**：通过遥测数据理解系统边界 -- **Chaos Engineering**：通过实验验证系统韧性 - -## Related Concepts -- [[Autoscaling]] -- [[Scalability]] -- [[Cost-Optimization]] -- [[Observability]] -- [[Resilience]] - -## Source -- SRE Weekly Issue #513 — [[sre-weekly-issue-513]] diff --git a/wiki/concepts/Email-Triage.md b/wiki/concepts/Email-Triage.md deleted file mode 100644 index 259568ab..00000000 --- a/wiki/concepts/Email-Triage.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Email Triage" -type: concept -tags: [automation, productivity, agent, email] -date: 2026-04-22 ---- - -## Definition -Email Triage（邮件分拣）指 AI Agent 自动扫描收件箱、识别待办事项、标记优先级，并归档噪音邮件的自动化流程。类似于医院急诊的分诊（triage）机制——快速评估、将紧急项优先处理、其余归档。 - -## In Home Lab Context -在 [[self-healing-home-server]] 中，每小时运行的 Cron Job 自动执行邮件分拣： -- **标记待办项**：识别需要回复或跟进的邮件，自动添加到任务看板 -- **归档噪音**：Promotional/Newsletters 等噪音邮件自动归档 -- **紧急升级**：包含关键词（"urgent"/"deadline"/"ASAP"）的邮件触发告警 - -## Tools Used -- `gog CLI`：OpenClaw Agent 访问 Gmail 的接口 -- Gmail Labels：通过标签系统管理邮件分类 -- IMAP/SMTP：通用邮件访问协议 - -## Key Insight -自动化邮件分拣将每日 30-60 分钟的手动邮件处理时间降至接近零，让用户专注于高价值任务。 - -## Connections -- [[OpenClaw]] — 通过 gog CLI 访问 Gmail 的 Agent 平台 -- [[Morning Briefing]] — 晨报中包含邮件处理提醒 -- [[TaskAutomation]] — 邮件分拣后自动创建任务 -- [[Cron定时任务]] — 邮件分拣的调度机制（每小时 cron） diff --git a/wiki/concepts/Embedding.md b/wiki/concepts/Embedding.md deleted file mode 100644 index 9aca3cef..00000000 --- a/wiki/concepts/Embedding.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Embedding" -type: concept -tags: [embedding, vector, nlp, similarity] -aliases: [Embedding, 向量化, Text Embedding, 词向量] -last_updated: 2025-12-20 ---- - -## Definition -Embedding，向量化，将词或文本转换为浮点数向量的技术。通过计算向量之间的距离（欧氏距离、余弦相似度等）判断语义关联性。 - -## Key Facts -- 词的意义取决于上下文语境（如"苹果"可指水果或手机） -- Embedding 将词转化为高维浮点向量 -- 语义相近的词在向量空间中距离更近 -- 示例：一百和两百的距离近，而一百离一千远，说明一百比一千更接近两百的语义 -- 是 [[RAG]] 检索的基础技术 - -## Connections -- [[RAG]] ← 依赖 ← [[Embedding]] -- [[Vector-Embedding]] ← 同义词 ← [[Embedding]] - -## Sources -- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]] diff --git a/wiki/concepts/Emergency-Change.md b/wiki/concepts/Emergency-Change.md deleted file mode 100644 index 3ec12571..00000000 --- a/wiki/concepts/Emergency-Change.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Emergency Change" -type: concept -tags: [Change-Management, ITSM, Incident-Response, CAPA] -last_updated: 2026-04-14 ---- - -## Definition - -Emergency Change（紧急变更）是为了缓解事故（Incident）并尽快恢复服务到期望状态而需要立即执行的变更。与 Normal Change 不同，Emergency Change 可以在没有 CAB 预先批准的情况下执行，但事后必须通过 CAPA/Post-mortem 流程修复根因。 - -## Characteristics - -|| Attribute | Value | -|-----------|--------| -| Approval Required | 事后审批 | -| CAB Involvement | 事后汇报 | -| Automation Level | 可部分自动化 | -| Risk Level | 高（应急执行） | -| Change Window | 即时执行 | -| Post-Process | 必须 CAPA/Post-mortem | - -## Process Flow - -1. **Trigger**：Incident 触发应急响应 -2. **Assessment**：快速评估并决定是否执行 Emergency Change -3. **Execution**：立即执行变更以缓解事故 -4. **Communication**：通知相关干系人 -5. **CAPA**：事后通过 CAPA 流程修复根因 -6. **Documentation**：完成变更记录和 Post-mortem - -## Key Principle - -> Emergency Change 的目标不是永久性补丁，而是通过 CAPA/Post-mortem 识别根本原因并制定长期解决方案。 - -## CAPA Process - -CAPA（Corrective and Preventive Action）包含两个阶段： -- **Corrective Action**：修复当前问题的即时措施 -- **Preventive Action**：预防同类问题再次发生的长期措施 - -## Sources - -- [[ctp-topic-30-managing-change]] diff --git a/wiki/concepts/Employee-Advocacy.md b/wiki/concepts/Employee-Advocacy.md deleted file mode 100644 index 010264d9..00000000 --- a/wiki/concepts/Employee-Advocacy.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Employee Advocacy" -type: concept -tags: [social-media, branding, employee-engagement, marketing] -last_updated: 2026-04-26 ---- - -## Definition -员工倡导计划（Employee Advocacy）是一种通过激活和赋能企业员工在社交媒体上代表品牌发声来放大品牌影响力的策略。其核心机制是：员工分享品牌内容的触达率通常高于企业官方账号（因为社交算法对个人账户更友好），且具有更强的信任度和真实感。 - -## Why It Works -- **算法优势**：LinkedIn/Twitter 对个人账号内容的自然触达高于企业页面 -- **信任溢价**：用户对"真实员工"的信任度高于"企业品牌" -- **受众扩展**：员工的个人网络是品牌受众的倍数放大器 -- **成本效益**：相比付费广告，员工生成内容（EGC）成本极低 - -## Implementation Framework -### Phase 1: Program Design -- 定义目标和 KPI（品牌覆盖 / 线索生成 / 员工参与率） -- 选择参与平台（通常 LinkedIn 为主） -- 设计内容库和分享指南 -- 建立激励机制 - -### Phase 2: Content Enablement -- 创建易于分享的内容模板 -- 预制社交媒体帖子草稿（员工一键分享） -- 品牌 hashtag 和关键词指南 -- 合规和法律边界说明 - -### Phase 3: Activation & Scaling -- 招募早期采用者（champions） -- 定期内容供给（newsletter 或 Slack 频道） -- 竞赛和认可机制 -- 规模化复制成功模式 - -## Success Metrics -- **参与率**：30%+ 员工月活跃分享目标 -- **覆盖增长**：员工分享带来的品牌受众增量 -- **互动率**：员工分享内容的平均互动 -- **线索贡献**：社交销售归因中员工渠道占比 -- **品牌认知提升**：员工网络中的品牌提及量 - -## Challenges -- 员工参与意愿参差不齐 -- 品牌形象一致性风险 -- 隐私和合规边界 -- 内容供给持续性 - -## Sources -- [[marketing-social-media-strategist]] diff --git a/wiki/concepts/Encounter-Design.md b/wiki/concepts/Encounter-Design.md deleted file mode 100644 index c91effac..00000000 --- a/wiki/concepts/Encounter-Design.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: "Encounter Design" -type: concept -tags: ["game-design", "level-design", "combat-design", "player-balance", "tactics"] -sources: ["level-designer.md"] -last_updated: 2026-05-07 ---- - -## Definition - -Encounter Design（遭遇战设计）是游戏关卡设计中对战斗、挑战或关键交互节点的规划方法论。**核心要求：每场遭遇战必须同时具备进入读时、多种战术选项和撤退位置——三者缺一则战斗不公平**。 - -## Three Mandatory Elements - -### 1. Entry Read Time（进入读时） -玩家在进入战斗前必须有时间感知威胁： -- **禁止**：玩家无法在受击前看到敌人的位置（设计的伏击除外，但必须有预兆） -- **标准**：敌人必须在玩家进入交战范围前可见 -- **伏击设计**：必须有 telegraph（预兆信号），如声音、光照变化、敌人标记 - -### 2. Multiple Tactical Approaches（多种战术选项） -每场战斗必须至少有 2 种在测试中被证明可行的战术： -- **进攻选项**：正面突破、侧翼、包抄 -- **防守选项**：利用掩体、占据高点、等待冷却 -- **策略选项**：利用环境（可破坏物、陷阱触发物） -- **禁止**：只有一种最优解的战斗设计 - -### 3. Fallback Position（撤退位置） -玩家处于劣势时必须有脱离战场的空间选项： -- **要求**：撤退位置必须在空间上明显（玩家能直觉感知） -- **功能**：给予玩家重新评估局势、改变战术的机会 -- **平衡**：撤退位置不应该是绝对安全的（否则玩家永远不进攻） - -## Difficulty Hierarchy - -遭遇战难度应首先通过**空间设计**（位置、布局）而非数值缩放实现： - -1. **Spatial Difficulty**（空间难度）：通过掩体数量、高低差、通道宽度实现 -2. **Tactical Difficulty**（战术难度）：通过敌人类型组合、AI 行为模式实现 -3. **Stat Difficulty**（数值难度）：作为最后手段，缩放敌人生命值/伤害 - -## Encounter List Template - -```markdown -## Encounter List - -| ID | Type | Enemy Count | Tactical Options | Fallback Position | -|-----|----------|-------------|------------------|-------------------| -| E01 | Ambush | 4 | Flank / Suppress | Door archway | -| E02 | Arena | 8 | 3 cover positions| Elevated platform | -``` - -## Playtest Validation - -- 每场遭遇战必须单独 Playtest 验证 -- 测量指标：time-to-death、成功战术分布、混乱时刻 -- 迭代标准：直到至少 2 种战术被测试者成功使用 - -## Connections - -- [[Level Designer]] 是 Encounter Design 的核心执行者 -- [[Grey Box Blockout]] 阶段必须验证所有遭遇战 -- [[Spatial Psychology]] 影响撤退位置和有利地形的空间感知设计 -- [[Pacing Chart]] 中的 Combat 条目直接对应 Encounter Design 的节奏峰值 diff --git a/wiki/concepts/Enterprise-Architecture.md b/wiki/concepts/Enterprise-Architecture.md deleted file mode 100644 index 6e090e2e..00000000 --- a/wiki/concepts/Enterprise-Architecture.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "Enterprise Architecture (EA)" -type: concept -tags: [Architecture, Cloud, Strategy, Enterprise] -sources: [ctp-topic-23-introduction-to-the-technical-architecture-team-and-function, ctp-topic-47-enterprise-architecture-cloud-standards] -last_updated: 2026-04-14 ---- - -# Enterprise Architecture (EA) - -## Definition -**Enterprise Architecture (EA)** 是架构体系中的最高层，负责将业务目标转化为技术原则和标准，确保技术投资与商业战略保持一致。 - -## Responsibilities - -| Responsibility | Description | -|----------------|-------------| -| Business Strategy Alignment | 将业务目标映射到技术投资 | -| Technology Standards | 制定和维护技术标准和最佳实践 | -| Governance | 确保技术决策符合组织目标 | -| Roadmap Planning | 制定长期（12-24个月）技术路线图 | - -## Relationship with Other Architecture Layers - -``` -Enterprise Architecture (EA) - │ - ├── Business Strategy Alignment - │ - ▼ -Solution Architecture (SA) ◄── Middle Layer - │ - └── Solution Design - │ - ▼ -Technical Architecture (TA) ◄── Implementation Layer -``` - -## Key Activities - -1. **Strategic Planning**: 制定技术愿景和路线图 -2. **Standard Setting**: 定义技术标准和框架 -3. **Portfolio Management**: 管理技术资产组合 -4. **Stakeholder Communication**: 向业务利益相关者传达技术战略 - -## Related Concepts - -- [[Solution Architecture (SA)]] -- [[Technical Architecture (TA)]] -- [[Cloud-First Strategy]] -- [[Landing Zone Architecture]] - -## Sources - -- [[ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]] -- [[ctp-topic-47-enterprise-architecture-cloud-standards]] diff --git a/wiki/concepts/Entity-Optimization.md b/wiki/concepts/Entity-Optimization.md deleted file mode 100644 index f1a78acc..00000000 --- a/wiki/concepts/Entity-Optimization.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Entity Optimization" -type: concept -tags: ["SEO", "AEO", "knowledge-graph", "brand", "visibility"] -last_updated: 2026-04-26 ---- - -## Definition - -Entity Optimization（实体优化）是强化品牌实体信号的系统性方法，使 AI 引擎能清晰识别、理解和引用品牌为可信赖的实体。核心洞察：AI 引擎引用的是它们能"理解"和"信任"的实体，而非仅仅是包含关键词的页面。 - -## Why Entities Matter for AI - -与传统 SEO（关键词匹配）不同，AI 引擎通过**实体理解**（entity understanding）构建知识表示： -- 品牌名 → 语义向量 → 关联概念 -- 清晰的实体 → 更高的置信度 → 更可能被引用 -- 模糊的实体 → 低置信度 → 被忽略或被竞品取代 - -## Optimization Tactics - -### 1. Consistent Brand Naming -在所有自有内容中保持品牌名称、变体、产品名称的一致性使用。 -- ✅ "Claude, developed by Anthropic" -- ❌ "claude" / "Anthropic's AI called 'Claude'" - -### 2. Knowledge Graph Presence -在权威知识图谱中建立品牌实体条目： -- **Wikipedia**：官方品牌条目（含公司成立、核心产品、市场定位） -- **Wikidata**：结构化品牌知识（关联创始人、产品、竞争对手、行业） -- **Crunchbase**：商业实体信息（融资轮次、规模、市场） - -### 3. Third-Party Citations -在权威第三方来源中获得品牌提及： -- 新闻媒体报道 -- 行业分析报告引用 -- 学术论文提及 - -### 4. Schema Markup -在自有网站上使用 Organization 和 Product schema： -```json -{ - "@type": "Organization", - "name": "Brand Name", - "url": "https://brand.com", - "sameAs": ["Wikipedia URL", "Crunchbase URL"] -} -``` - -### 5. Wikipedia-style Content -创建品牌内容时采用 Wikipedia 的客观、引用支撑、结构清晰风格——AI 训练数据中大量 Wikipedia 内容，使 AI 熟悉并偏好该格式。 - -## Related Concepts - -- [[Answer Engine Optimization (AEO)]]：Entity Optimization 是 AEO 的核心技术方向 -- [[Generative Engine Optimization (GEO)]]：实体信号是 GEO 的五大支柱之一 -- [[Platform-Specific Patterns]]：不同 AI 平台对实体信号的权重不同 - -## Sources - -- [[AI Citation Strategist]] diff --git a/wiki/concepts/Environmental-Determinism.md b/wiki/concepts/Environmental-Determinism.md deleted file mode 100644 index 5527a036..00000000 --- a/wiki/concepts/Environmental-Determinism.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Environmental Determinism" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-25 ---- - -## 定义 -环境决定论（Environmental Determinism）是认为自然环境（地理、气候、资源）是人类文化、社会组织和历史发展主要决定因素的理论框架。 - -## 核心观点 -- 地理条件直接决定了一个社会能够发展出什么技术和制度 -- 热带地区因资源丰富而缺乏发展动机（这是有争议的论点） -- 欧亚大陆的东西轴线使得农业和技术传播更快速 - -## 代表人物 -- [[Jared Diamond]]：《枪炮、病菌与钢铁》的作者，将环境决定论普及化 -- Ellen Semple：早期环境决定论代表 - -## 批评（[[Acemoglu]] 等） -- 地理不是命运，制度和政治因素同样重要 -- 相似环境产生不同文化，人类的能动性不可忽视 -- [[academic-geographer]] 的立场：地理约束但不决定，Agent 应避免走向极端 - -## 来源 -- [[academic-geographer]] diff --git a/wiki/concepts/Environmental-Storytelling.md b/wiki/concepts/Environmental-Storytelling.md deleted file mode 100644 index af5bba5c..00000000 --- a/wiki/concepts/Environmental-Storytelling.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: "Environmental Storytelling" -type: concept -tags: ["game-design", "narrative-design", "world-building", "level-design", "atmosphere"] -sources: ["level-designer.md", "narrative-designer.md"] -last_updated: 2026-05-07 ---- - -## Definition - -Environmental Storytelling（环境叙事）是通过场景道具摆放、光照设计、几何形状和破坏痕迹传达世界观故事的设计手法——**玩家无需对话或文字即可推断空间中发生过什么**。核心信念：**空间本身就是叙事媒介**。 - -## Core Principles - -### 1. Every Space Tells a Story -每个区域都应通过物理证据传达信息： -- 倒落的家具 → 某人匆忙离开 -- 墙上的弹孔 → 发生过战斗 -- 凌乱的办公桌 → 被迫中断的工作 -- 儿童玩具 → 这是一个家庭空间 - -### 2. Consistency with World History -破坏、磨损和细节必须与设定的世界时间线一致： -- 不同年代的空间应有不同的磨损程度 -- 灾难事件后的空间必须有相应的破坏证据 -- 废弃空间应有相应的尘土、蛛网、自然侵蚀 - -### 3. No Empty Filler Spaces -禁止"纯装饰性填充空间"——每个空间必须有叙事目的： -- 即使是过渡走廊，也应通过环境细节传达世界信息 -- 环境叙事密度随关卡重要性递增 - -## Techniques - -### Physical Props -道具是最直接的环境叙事媒介： -- 选择性摆放（而非随机放置）传达人物意图 -- 对比性道具（"这不应该在这里"）制造悬念 - -### Lighting and Color -光照是环境叙事最强力的工具： -- 明暗对比引导注意力，暗示重要区域 -- 色温传达情感：暖色=安全/生活，冷色=危险/陌生 -- 动态光源（如闪烁的火焰）暗示时间流逝或危险 - -### Geometry and Architecture -空间本身传达权力关系和历史： -- 高天花板 → 公共/权威空间 -- 低矮通道 → 压迫/隐藏路径 -- 环形空间 → 迷宫/无法逃逸感 - -### Destruction and Decay -损坏和腐朽是时间故事的视觉证据： -- 自然的生物侵蚀（苔藓、蛛网） -- 暴力的物理破坏（烧毁、爆炸、战斗痕迹） -- 社会性废弃（垃圾、个人物品散落） - -## Metrics - -环境叙事有效性通过 Playtest 验证： -- **>70% 的测试玩家能正确推断环境故事**时，环境叙事设计达标 -- 开放式问题："这个空间告诉了你什么？"收集推断准确性数据 - -## Connections - -- [[Level Designer]] 是环境叙事的物理空间执行者 -- [[Narrative Designer]] 定义环境叙事的内容框架（世界设定、时间线） -- [[Pacing Chart]] 中的 Exploration 时段是环境叙事密度最高的时间窗口 -- [[Grey Box Blockout]] 阶段验证环境叙事是否可感知（道具位置在灰盒中以占位符标记） diff --git a/wiki/concepts/EriksonPsychosocialStages.md b/wiki/concepts/EriksonPsychosocialStages.md deleted file mode 100644 index 56cc8ff3..00000000 --- a/wiki/concepts/EriksonPsychosocialStages.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Erikson Psychosocial Stages" -type: concept -tags: [] -sources: [academic-psychologist] -last_updated: 2026-04-25 ---- - -# Erikson Psychosocial Stages - -## Aliases -- Erikson's Stages of Development -- Psychosocial Development Stages - -## Definition -Erikson 心理社会发展阶段——人在整个生命周期中面临的八个心理社会危机，每个危机的解决方式影响后续阶段的发展轨迹。 - -## Eight Stages - -| 阶段 | 年龄 | 核心危机 | 成功解决 | 未解决 | -|------|------|----------|----------|--------| -| 1 | 0-1岁 | Trust vs. Mistrust（信任 vs. 不信任） | 安全感 | 恐惧、不安全感 | -| 2 | 1-3岁 | Autonomy vs. Shame（自主 vs. 羞耻） | 意志力 | 自我怀疑 | -| 3 | 3-6岁 | Initiative vs. Guilt（主动性 vs. 内疚） | 方向感 | 过度内疚 | -| 4 | 6-12岁 | Industry vs. Inferiority（勤奋 vs. 自卑） | 能力感 | 自卑 | -| 5 | 12-18岁 | Identity vs. Role Confusion（同一性 vs. 角色混乱） | 自我认同 | 角色混乱 | -| 6 | 18-40岁 | Intimacy vs. Isolation（亲密 vs. 孤独） | 爱的能力 | 孤立、疏离 | -| 7 | 40-65岁 | Generativity vs. Stagnation（再生力 vs. 停滞） | 关怀传承 | 停滞、自我关注 | -| 8 | 65岁+ | Integrity vs. Despair（完善 vs. 绝望） | 智慧、接纳 | 悔恨、绝望 | - -## Application in Character Design -Psychologist Agent 使用此框架设计角色发展弧光时，强调**非决定论**——早期危机的影响可以被后续发展所修正，不存在"童年决定一切"的宿命论。 - -## Connection to Wiki -- Source: [[academic-psychologist]] diff --git a/wiki/concepts/Error-Accountability.md b/wiki/concepts/Error-Accountability.md deleted file mode 100644 index 29498719..00000000 --- a/wiki/concepts/Error-Accountability.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Error Accountability" -type: concept -tags: [ai, personalization, trust, feedback] -last_updated: 2026-04-23 ---- - -# Error Accountability - -## Aliases -- 错误反馈机制 -- 错误负责制 -- AI Error Transparency - -## Definition -AI 个性化配置中的一种原则：AI 应主动识别并承认因配置或能力限制导致的回复质量下降，而非静默产生低质量回复损害用户信任。 - -## Core Principle -> "If the quality of your response has dropped significantly due to my custom instructions, please explain the problem" — ChatGPT 个性化配置 - -## Mechanism -1. AI 检测到回复质量显著下降 -2. AI 主动指出问题所在 -3. 说明是配置原因还是能力限制 -4. 提供最接近可接受的替代方案 - -## Contrast with Silent Failure -| | Silent Failure | Error Accountability | -|--|---------------|---------------------| -| 表现 | 静默产生低质量回复 | 主动指出问题 | -| 用户感知 | 信任逐渐侵蚀 | 信任透明可控 | -| 修复路径 | 用户自己发现问题 | AI 给出诊断 | -| 长期影响 | 信任累积性下降 | 信任维持稳定 | - -## Key Insight -> "Mistakes can erode my trust, so be accurate and detailed" — 错误零容忍原则 - -错误对信任的损害是累积性的，因此 Error Accountability 本质上是信任维护机制而非错误修复机制。 - -## Examples in This Wiki -- [[openai-chatgpt-个性化定义]]：用户明确要求 AI 主动反馈配置导致的回复质量下降 -- [[养龙虾5天血泪史]]：OpenClaw Agent 调试中"错误只犯一次"的学习闭环 - -## Sources -- [[openai-chatgpt-个性化定义]] -- [[养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录]] diff --git a/wiki/concepts/Error-Budget.md b/wiki/concepts/Error-Budget.md deleted file mode 100644 index 17c26405..00000000 --- a/wiki/concepts/Error-Budget.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "Error Budget" -type: concept -tags: [SRE, Reliability, DevOps Metrics] -sources: [devops-maturity-model-from-traditional-it-to-advanced-devops] -last_updated: 2026-04-26 ---- - -## 定义 - -错误预算（Error Budget）是允许的、一定时间段内系统可以承受的错误和失败的数量或比例。它是一个平衡可靠性目标与创新速度的风险管理工具。 - -## 核心概念 - -错误预算源于 SRE（Site Reliability Engineering）理念，核心思想是： - -> 如果你的服务可靠性目标是 99.9%，那么你有 0.1% 的"错误预算"可以用于实验和发布。 - -## 计算方式 - -``` -Error Budget = (1 - Reliability SLO) × Time Period - -例如： -- 月 SLO = 99.9% -- 月错误预算 = 0.1% × 30天 × 24小时 = 0.72 小时（约 43 分钟） -``` - -## 在 DevOps 成熟度模型中的位置 - -在 DevOps 成熟度衡量指标体系中，错误预算是一个重要指标： - -> "Error Budget — The permissible rate of errors and failures in production." - -错误预算的使用策略因 DevOps 成熟度阶段不同而异： - -| 成熟度阶段 | 错误预算使用方式 | -|-----------|----------------| -| Phase 1-2 | 无正式错误预算概念 | -| Phase 3 | 开始建立 SLO，但未充分利用错误预算 | -| Phase 4 | 明确的错误预算政策，用于平衡创新与可靠性 | -| Phase 5 | 数据驱动决策，团队自主利用错误预算进行实验 | - -## 与相关概念的关系 - -- [[MTTR]]：错误预算与 MTTR 共同定义系统可靠性曲线 -- [[Change Failure Rate]]：高变更失败率会快速消耗错误预算 -- [[Deployment Frequency]]：高部署频率需要配合错误预算管理以维持可靠性目标 -- [[DevOps Maturity Model]]：错误预算是衡量组织成熟度的重要指标之一 - -## 错误预算政策示例 - -```yaml -SLO: 99.9%（每月 43 分钟错误预算） -策略: - - 错误预算充足（>50%）：可自由发布和实验 - - 错误预算中等（25-50%）：谨慎发布 - - 错误预算不足（<25%）：冻结发布，专注可靠性 - - 错误预算耗尽：停止所有非关键变更 -``` - -## 来源 -- [[devops-maturity-model-from-traditional-it-to-advanced-devops]] diff --git a/wiki/concepts/Error-Surface-vs-Root-Cause.md b/wiki/concepts/Error-Surface-vs-Root-Cause.md deleted file mode 100644 index e91484d9..00000000 --- a/wiki/concepts/Error-Surface-vs-Root-Cause.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Error Surface vs Root Cause" -type: concept -last_updated: 2026-04-10 ---- - -## Definition -错误表象（Error Surface）是指错误信息字面上描述的问题，而根本原因（Root Cause）是导致错误发生的真正系统状态。"Context Limit Exceeded"字面上提示"对话太长"，但真实原因可能是"模型配置错误"。 - -## Core Principle -> **不要默认认为错误信息就是表面意思。先问一句：到底哪儿出问题了？** - -## Debugging Mindset -| 错误表象 | 根本原因 | -|---|---| -| Context limit exceeded = 对话太长 | 模型 context window 太小 | -| Session 文件爆满 = 文件需要清理 | 模型切换导致 token 立即耗尽 | -| 重启后问题复发 = 持久化配置错误 | Agent 路由规则在启动时重新加载 | - -## Related -- [[Log-Driven-Debugging]]: 通过日志还原真实系统状态 -- [[Hidden-Failure-Paths]]: 复杂系统中的隐藏故障路径 -- [[Layered-Configuration]]: 分层配置导致问题藏在不同层级 - -## Sources -- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]] diff --git a/wiki/concepts/Event-Correlation.md b/wiki/concepts/Event-Correlation.md deleted file mode 100644 index 6ea39691..00000000 --- a/wiki/concepts/Event-Correlation.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: "Event Correlation" -type: concept -tags: [aiops, monitoring, incident-management, operations] -date: 2025-03-01 ---- - -## Definition - -事件关联（Event Correlation）是[[AIOps]]的核心技术之一，通过算法将大量分散的监控告警和系统事件归类为少量有意义的事件组，减少告警噪音，加速[[Incident-Management]]和[[Root-Cause-Analysis]]。 - -## The Problem - -``` -Without Event Correlation: -───────────────────────────── -Alert #1: CPU High on Server A -Alert #2: Memory High on Server A -Alert #3: Disk I/O High on Server A -Alert #4: Network Latency on Server A -Alert #5: App Response Slow -Alert #6: Database Connection Pool Full -Alert #7: API Timeout -... (100+ alerts for ONE root cause) -``` - -## Event Correlation Techniques - -### 1. Rule-Based Correlation -``` -IF alerts occur within time window T -AND involve same source/host/service -THEN group as single incident -``` - -### 2. Statistical Correlation -- Time series analysis -- Pattern matching -- Anomaly detection - -### 3. AI/ML Correlation -- Root cause inference -- Causal graph models -- Predictive correlation - -## Benefits - -| 收益 | 描述 | -|------|------| -| 告警降噪 | 减少90%+噪音 | -| 加速RCA | 快速定位根因 | -| MTTR降低 | 减少人工分析时间 | -| SLA保障 | 更快响应 | - -## In ITSM Context - -在[[ITSM 2.0]]的[[Incident-Management]]中，事件关联是关键能力： - -``` -Incident Management 2.0 -├── Event Correlation (ML-enhanced) -│ ├── 告警去重 -│ ├── 根因推断 -│ └── 关联推理 -├── AIOps-powered Analysis -│ ├── 异常检测 -│ ├── 模式识别 -│ └── 预测分析 -└── Self-Healing Automation - ├── 自动诊断 - └── 自动修复 -``` - -## Related Concepts - -- [[AIOps]] — 事件关联的AI引擎 -- [[Incident-Management]] — 事件管理的应用场景 -- [[Root-Cause-Analysis]] — 根因分析 -- [[MTTR]] — 平均恢复时间 -- [[Self-Healing-Systems]] — 自愈系统 - -## Sources - -- [[understanding-complete-itsm]] — ML-enhanced Event Correlation -- [[what-i-know-about-cloud-service-delivery-1]] — AIOps中的事件关联 diff --git a/wiki/concepts/Event-Driven-Architecture.md b/wiki/concepts/Event-Driven-Architecture.md deleted file mode 100644 index 9015e1df..00000000 --- a/wiki/concepts/Event-Driven-Architecture.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Event-Driven Architecture" -type: concept -tags: - - EDA - - Architecture - - Cloud - - Microservices -last_updated: 2026-04-14 ---- - -## Aliases -- EDA -- Event Driven Architecture -- 事件驱动架构 - -## Definition -事件驱动架构（EDA）是一种软件架构范式，通过在松耦合的生产者（Producer）和消费者（Consumer）之间传递事件（Event）来实现系统解耦。事件是状态变化或更新的通知，触发异步处理和响应。 - -## Core Components -- **Event Producer**：事件的产生者，感知状态变化并发布事件 -- **Event Consumer**：事件的订阅者和处理者，响应事件执行相应逻辑 -- **Event Broker**：事件的中介路由器，负责分发和传递事件 - -## Event Broker Types -- **Event Router**（事件路由器）：过滤并路由事件到正确的消费者（SNS / EventBridge） -- **Event Store**（事件存储）：流式存储事件，消费者自行过滤所需事件（SQS / Kinesis） - -## Key Design Principles -- **Decoupling**：生产者和消费者完全解耦，独立演进 -- **Scalability**：各组件可独立扩展 -- **Resilience**：局部故障不影响整体系统 -- **Idempotency**：幂等性保证异步重试不产生副作用 - -## Best Practices -- 稀疏事件（sparse events）适合频繁变化的数据，但消费者可能需要额外查询详情 -- 完整状态事件（full state）包含更多细节，但受 EventBridge 负载大小限制 -- 事件排序需使用 SQS FIFO 或 Kinesis Data Streams -- EventBridge 最佳实践：每个订阅者使用单一规则、避免为自定义事件使用默认事件总线、使用死信队列处理失败事件 - -## Related Messaging Patterns -- [[Fan-Out-Pattern]]：扇出模式 -- [[Competing-Consumer-Pattern]]：竞争消费者模式 -- [[Choreography]]：编舞模式 -- [[Orchestration]]：编排模式 - -## Sources -- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]] -- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] diff --git a/wiki/concepts/EventSourcing.md b/wiki/concepts/EventSourcing.md deleted file mode 100644 index 672195ce..00000000 --- a/wiki/concepts/EventSourcing.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Event Sourcing" -type: concept -tags: [architecture, data-modeling, patterns] -sources: [project-state-management] -last_updated: 2026-04-27 ---- - -## Definition - -事件溯源（Event Sourcing）是一种软件架构模式——不直接存储数据的当前状态，而是将所有状态变更作为**不可变事件序列**持久化，通过重放事件来重建任意时间点的状态。源自 Martin Fowler 的经典模式。 - -## Core Principles - -1. **唯一真实来源（Single Source of Truth）**：事件日志是唯一真实来源，当前状态由事件推导得出，而非直接存储 -2. **不可变性（Immutability）**：事件一旦写入，永不修改或删除，只能追加新事件 -3. **全历史可追溯（Audit Trail）**：天然具备完整审计日志，可回溯任何历史变更的"为什么" -4. **时间旅行调试**：任意时刻的状态可精确重建，便于复现 BUG 和分析决策上下文 - -## Event Sourcing vs Traditional State Storage - -| 维度 | 传统状态存储 | 事件溯源 | -|------|------------|---------| -| 存储内容 | 当前状态快照 | 状态变更事件序列 | -| 历史保留 | 通常不保留或有限保留 | 完整保留（无上限）| -| 变更原因 | 通常不记录 | 完整记录每次变更的原因 | -| 回滚能力 | 依赖备份 | 通过反向事件补偿天然支持 | -| 审计合规 | 需额外构建 | 内置，无需额外开发 | - -## Key Event Types - -- **Progress**：任务向前推进的里程碑事件 -- **Blocker**：阻塞/障碍事件，通常触发状态 → "blocked" -- **Decision**：关键决策事件，记录决策理由和背景 -- **Pivot**：转向/重大调整事件，记录原因和备选方案 -- **Completion**：完成事件，触发状态 → "completed" - -## Applications in Project Management - -[[Project State Management]] 是事件溯源在个人/团队项目管理中的具体应用： - -- 用自然语言对话替代手动拖拽看板卡片 -- 每句话（"完成了X"/"被Y阻塞"）作为独立事件持久化 -- 当前状态由事件序列自动推导，无需手动维护 -- 查询"项目为什么这样"等同于"重放这个项目的所有事件" - -## Connections - -- [[Project State Management]] ← uses ← **Event Sourcing** -- [[Centralized Logging]] ← related_to ← **Event Sourcing**（集中日志可视为事件溯源的一种实现） -- [[Kanban]] ← alternative_to ← **Event Sourcing**（冲突：可视化协作 vs 自动追踪+上下文保留） diff --git a/wiki/concepts/Evidence-Chain.md b/wiki/concepts/Evidence-Chain.md deleted file mode 100644 index 7f95641f..00000000 --- a/wiki/concepts/Evidence-Chain.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Evidence-Chain" -type: concept -tags: [audit, security, tamper-detection] -sources: [agentic-identity-trust.md] -last_updated: 2026-04-25 ---- - -## Definition - -Evidence-Chain（证据链）是一种仅追加（append-only）、链式哈希、防篡改的操作记录系统。每个证据记录包含：意图（intent）、决策（decision）、结果（outcome），并通过哈希链指向前一记录，形成完整操作审计链。 - -## Core Properties - -- **仅追加**：历史记录不可修改，只能添加新记录 -- **链式哈希**：每个记录包含前一条记录的哈希值，篡改任意记录都会破坏链的完整性 -- **独立可验证**：任何第三方可以在不信任记录系统的前提下验证链的完整性 -- **防篡改检测**：链中任意记录被修改，后续所有哈希校验将失败 - -## Structure - -```python -{ - "agent_id": "trading-agent-prod-7a3f", - "action_type": "trade.execute", - "intent": {"symbol": "AAPL", "quantity": 100, "side": "buy"}, - "decision": "approved: scope verified, trust score 0.94", - "outcome": {"filled": true, "price": 182.50, "order_id": "ord-xyz"}, - "timestamp_utc": "2026-03-01T14:30:00Z", - "prev_record_hash": "0"*64, - "record_hash": "sha256(...)", - "signature": "Ed25519(agent_private_key, record_hash)" -} -``` - -## Relationships -- [[Zero-Trust]]：Evidence-Chain 是 Zero-Trust 日志完整性的核心机制 -- [[Trust-Scoring]]：Trust-Scoring 的评分依据来源于 Evidence-Chain 的可验证结果 -- [[Algorithm-Agility]]：算法升级时需要保证历史证据链的可验证性 - -## Sources -- [[agentic-identity-trust.md]] diff --git a/wiki/concepts/Evidence-Over-Claims.md b/wiki/concepts/Evidence-Over-Claims.md deleted file mode 100644 index 9c3ef71b..00000000 --- a/wiki/concepts/Evidence-Over-Claims.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Evidence Over Claims" -type: concept -tags: [multi-agent, quality, evidence, nexus] -sources: [executive-brief, quickstart] -last_updated: 2026-05-01 -aliases: - - Evidence-Based Quality - - Proof Over Promise ---- - -## Definition - -证据优于主张（Evidence Over Claims）—— NEXUS 多 Agent 编排框架的核心质量原则：所有质量声明必须基于可验证的证据（截图/测试结果/性能数据），而非口头断言或自我评估。 - -## Core Principle - -``` -主张：✓ 功能已完成，质量优秀 -证据：✓ 自动化测试通过率 100%，覆盖率 85%，Lighthouse 性能评分 95 -``` - -只有证据才能推动流程前进。口头断言、承诺或自我评估都不是有效的质量证明。 - -## Evidence Hierarchy - -| 证据类型 | 优先级 | 示例 | -|---------|-------|------| -| 截图/录屏 | 最高 | 关键功能运行录屏、UI 对比截图 | -| 自动化测试结果 | 高 | Jest/Vitest 测试报告、覆盖率报告 | -| 性能数据 | 高 | Lighthouse 报告、API 响应时间表 | -| 第三方审计报告 | 中 | 安全扫描报告、无障碍审计报告 | -| 口头断言/自我评估 | 最低 | "功能已实现"、"质量很好" | - -## Related Concepts - -- [[Reality Checker]]：Evidence Over Claims 原则的强制执行者——默认"NEEDS WORK"，要求提供证据 -- [[Quality Gate]]：Evidence Over Claims 是质量门控的判断标准 -- [[Dev↔QA Loop]]：Dev↔QA 循环中的 PASS/FAIL 判定必须基于证据 diff --git a/wiki/concepts/Evidence-based-Merge-Proposal.md b/wiki/concepts/Evidence-based-Merge-Proposal.md deleted file mode 100644 index 54563125..00000000 --- a/wiki/concepts/Evidence-based-Merge-Proposal.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Evidence-based Merge Proposal" -type: concept -tags: ["multi-agent", "identity", "coordination", "decision-making"] -sources: ["identity-graph-operator"] -last_updated: 2026-04-25 ---- - -# Evidence-based Merge Proposal（证据驱动合并提案） - -## Definition -多 Agent 身份协调中的标准提案协议——当发现两个实体应合并时，不直接执行 merge 操作，而是构造包含完整 per-field evidence 的提案，供其他 Agent 审查后再执行。 - -## Structure - -```json -{ - "entity_a_id": "a1b2c3d4-...", - "entity_b_id": "e5f6g7h8-...", - "confidence": 0.87, - "evidence": { - "email_match": { "score": 1.0, "values": ["wsmith@acme.com", "wsmith@acme.com"] }, - "name_match": { "score": 0.82, "values": ["William Smith", "Bill Smith"] }, - "phone_match": { "score": 1.0, "values": ["+155****0142", "+155****0142"] }, - "reasoning": "Same email and phone. Name differs but 'Bill' is a known nickname for 'William'." - } -} -``` - -## When to Propose vs. Direct Merge - -| 场景 | 动作 | 原因 | -|------|------|------| -| 单 Agent，置信度 > 0.95 | 直接合并 | 无歧义，无其他 Agent 需协商 | -| 多 Agent，置信度中等 | 提案合并 | 让其他 Agent 审查证据 | -| Agent 不同意既有合并 | 提案拆分（含 member_ids） | 不直接撤销，由多方验证 | -| 修正数据字段 | 带 expected_version 的直接变更 | 字段更新无需多 Agent 审查 | - -## Core Principles -- **永远不带证据不合并**："These look similar" 不是证据，per-field comparison scores + confidence thresholds 才是证据 -- **提案优于断言**：提出 merge（带证据）而非直接执行，让对方 Agent 有机会审查 -- **反压不覆盖**：当 Agent 间存在冲突（一个提出 merge，另一个提出 split），不直接覆盖另一方证据，而是呈现反证据让最强证据胜出 - -## Conflict Resolution -当两个 Agent 对同一对实体给出矛盾提案时： -1. 标记为 `conflict` 状态 -2. 双方添加评论讨论证据 -3. 等待人类或仲裁 Agent 最终裁决 -4. 永不通过"强行覆盖"解决冲突 diff --git a/wiki/concepts/EvidenceCollection.md b/wiki/concepts/EvidenceCollection.md deleted file mode 100644 index defa71e7..00000000 --- a/wiki/concepts/EvidenceCollection.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Evidence Collection" -type: concept -tags: [] -sources: [compliance-auditor] -last_updated: 2026-04-30 ---- - -# Evidence Collection - -## Definition - -证据收集（Evidence Collection）是合规审计中从被审计系统提取、记录和整理证据材料的过程，用以证明控制措施在审计期间有效运行。证据必须证明控制**在整个审计期间持续有效**，而非仅在审计当天存在。 - -## Core Principles - -### 自动化优先原则 -- **手动证据是脆弱的证据**——依赖人工截图、导出的流程无法保证一致性 -- 从第一天就建立自动化证据收集管道——手动流程无法扩展 -- 自动化证据的优势：可重复、一致、可追溯 - -### 证据收集矩阵 -| 控制 ID | 控制描述 | 证据类型 | 来源 | 收集方法 | 频率 | -|---------|---------|---------|------|---------|------| -| CC6.1 | 逻辑访问控制 | 访问审查日志 | Okta | API 导出 | 季度 | -| CC6.2 | 用户配置 | 入职工单 | Jira | JQL 查询 | 事件触发 | -| CC6.3 | 用户取消配置 | 离职清单 | HR系统+Okta | 自动化 webhook | 事件触发 | -| CC7.1 | 系统监控 | 告警配置 | Datadog | 仪表板导出 | 月度 | - -### 按控制目标组织 -- 证据包必须按**控制目标**组织，而非按内部团队结构组织 -- 审计师需要的是按控制逻辑组织的证据，而非按 IT/HR/法务部门组织的文件 - -### 审计师视角 -- 思考"你会测试什么？"和"你会要求什么证据？" -- 抽样原则：若控制适用于 500 台服务器，审计师会抽样——确保任何一台都能通过 - -## Evidence Types -- 日志文件（访问日志、操作日志、安全日志） -- 配置快照（系统配置、安全策略） -- 审批记录（变更审批、例外审批） -- 报告导出（监控仪表板、合规报告） -- 自动化脚本输出（API 导出、脚本执行结果） - -## Related Concepts -- [[SOC 2]]：Type II 审计要求持续有效证据 -- [[Gap Assessment]]：修复差距后需要收集相应证据 -- [[Continuous Compliance]]：持续合规要求周期性证据收集 - -## Related Sources -- [[compliance-auditor]] diff --git a/wiki/concepts/EvidenceFirstReasoning.md b/wiki/concepts/EvidenceFirstReasoning.md deleted file mode 100644 index 42b08ba4..00000000 --- a/wiki/concepts/EvidenceFirstReasoning.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "EvidenceFirstReasoning" -type: concept -tags: [] -last_updated: 2026-05-02 ---- - -## Definition - -Evidence-First Reasoning（证据优先推理）是一种推理原则：只陈述代码中实际可见、可验证的事实，绝不进行推理、假设或猜测。 - -## Core Rule - -> "Never state that a module owns behavior unless you can point to the file(s) that implement or route it." - -如果某件事在检查的代码中不可见，就不能陈述它。 - -## Contrast with Other Approaches - -| Evidence-First Reasoning | Speculative Reasoning | -|---|---| -| 基于代码中可验证的事实 | 基于推测和假设 | -| 明确告知检查范围边界 | 不声明检查边界 | -| 引用具体文件/函数名 | 使用泛化描述 | -| 诚实回答"不知道" | 试图覆盖不确定区域 | - -## Application in AI Coding Agents - -AI Coding Agent 在执行代码库分析时： -- 必须引用具体源文件路径 -- 必须区分"检查过的代码"和"未检查的代码" -- 不得推断意图、质量或未来工作 -- 当答案是部分的，只能说明检查了哪些文件 - -## Related Concepts - -- [[CodebaseOnboarding]] — 代码库 onboarding 方法论 -- [[ExecutionTracing]] — 执行路径追踪 -- [[MinimalChangePrinciple]] — 最小变更原则（[[EngineeringMinimalChangeEngineer]] 使用的原则） diff --git a/wiki/concepts/ExecutionTracing.md b/wiki/concepts/ExecutionTracing.md deleted file mode 100644 index 15b39301..00000000 --- a/wiki/concepts/ExecutionTracing.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "ExecutionTracing" -type: concept -tags: [] -last_updated: 2026-05-02 ---- - -## Definition - -Execution Tracing（执行追踪）是追踪请求、事件、命令在系统中完整流动路径的方法。通过追踪数据如何进入、转换、持久化和退出，建立对代码库实际工作方式的准确理解。 - -## Core Steps - -1. **Identify entry point** — 找到请求/命令的入口文件 -2. **Follow routing logic** — 追踪路由/控制器层的分发逻辑 -3. **Trace business logic** — 追踪核心业务逻辑的调用链 -4. **Map persistence layer** — 找到数据持久化或副作用发生的位置 -5. **Track return path** — 追踪结果如何返回到调用方 - -## Key Signals to Track - -- **Inputs**: HTTP requests, CLI args, messages, files, function arguments -- **Transforms**: Data validation, enrichment, computation, aggregation -- **Outputs**: Responses, DB writes, files, events, rendered UI - -## Async & Side Channels - -- 异步 jobs 和 queues -- Cron tasks 和定时任务 -- Background workers -- Client-side state 变更 - -## Usage Context - -- 理解新代码库的运行机制 -- 定位 bug 的根本原因 -- 评估代码变更的潜在影响范围 - -## Related Concepts - -- [[CodebaseOnboarding]] — 代码库 onboarding 的方法论 -- [[MentalModel]] — 为开发者构建准确的心智模型 diff --git a/wiki/concepts/Executive-Summary-Formula.md b/wiki/concepts/Executive-Summary-Formula.md deleted file mode 100644 index 9c46e370..00000000 --- a/wiki/concepts/Executive-Summary-Formula.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "执行摘要五步结构（Executive Summary Formula）" -type: concept -tags: [sales, proposal, executive-summary] -sources: [sales-proposal-strategist] -last_updated: 2026-04-29 ---- - -## Definition - -执行摘要是提案最关键的单页——很多高级评审者（尤其是 C-suite）只读这一页。它不是提案的摘要，而是提案的最终辩论（closing argument），放在最前面。 - -## 五步结构 - -| Step | 内容 | 目的 | -|------|------|------| -| 1 | **镜像买家处境**（2-3句） | 证明你倾听了，使用他们自己的语言 | -| 2 | **引入核心张力** | 不作为的代价或被错失的机会 | -| 3 | **呈现论点**（2-3句） | 你的方法如何化解张力；赢主题在此自然出现 | -| 4 | **提供证明**（1-2个） | 类似案例、可衡量成果、差异化方法论细节 | -| 5 | **以转化状态收尾** | 12-18 个月后买家组织具体、可衡量的状态 | - -## 黄金法则 - -- **一页纸**：每句话都必须自证其存在价值 -- **先赢主题后细节**：评审者在最初 100 个词内决定你是否理解他们的问题 -- **执行摘要可独立成文**：如果只给买家一页，让他们读执行摘要 - -## 与赢主题的关系 - -赢主题必须在执行摘要中出现（Step 3），但以自然整合的方式出现，而非列表形式。执行摘要是赢主题密度最高的单页。 - -## 与三幕式提案叙事的关系 - -执行摘要是三幕叙事的浓缩版： -- Step 1 ≈ Act I（理解挑战） -- Step 2-3 ≈ Act II（方案旅程） -- Step 4-5 ≈ Act III（转化状态） - -## Related Concepts - -- [[三幕式提案叙事]]：五步结构的完整展开 -- [[Win Theme]]：执行摘要中自然整合的叙事支柱 - -## Sources - -- [[sales-proposal-strategist]] diff --git a/wiki/concepts/Expert-User-Assumption.md b/wiki/concepts/Expert-User-Assumption.md deleted file mode 100644 index 6f834a09..00000000 --- a/wiki/concepts/Expert-User-Assumption.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Expert User Assumption" -type: concept -tags: [ai, personalization, interaction-design] -last_updated: 2026-04-23 ---- - -# Expert User Assumption - -## Aliases -- 专家用户假设 -- Expert Mode -- 技术用户假设 - -## Definition -AI 个性化配置中的一种原则：将用户视为具备专业背景的专家，无需在技术内容上简化解释、使用通俗语言或过度铺垫背景知识。 - -## Core Principle -> "Think of me as an expert in all fields" — ChatGPT 个性化配置 - -## Key Implications -- **无需通俗化**：技术细节直接呈现，不做"类比解释" -- **无知识铺垫**：不解释基础概念，直接进入专业讨论 -- **错误零容忍**：专家用户更容易发现错误，因此错误会直接损害信任 -- **论据优先于权威**：专家关注论证质量，而非"权威来源"背书 - -## Examples in This Wiki -- [[openai-chatgpt-个性化定义]]：用户明确声明"把我当成所有领域的专家" -- [[llms-rag-ai-agent-三个到底什么区别]]：Wiki 假设读者理解 LLM/RAG/Agent 的基本概念 - -## Contrast: Beginner User Assumption -| | Expert User Assumption | Beginner User Assumption | -|--|----------------------|------------------------| -| 解释深度 | 详细、直接 | 铺垫、类比 | -| 技术术语 | 直接使用 | 适度解释 | -| 错误容忍 | 零容忍 | 有限容忍 | -| 引用要求 | 论据优先 | 来源优先 | - -## Sources -- [[openai-chatgpt-个性化定义]] diff --git a/wiki/concepts/Exporter.md b/wiki/concepts/Exporter.md deleted file mode 100644 index 197ee9ba..00000000 --- a/wiki/concepts/Exporter.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: "Exporter" -type: concept -aliases: [Prometheus Exporter, 指标导出器, Prometheus指标导出器] -tags: [prometheus, monitoring, metrics, infrastructure] -date: 2025-11-11 ---- - -# Exporter - -## Overview -Exporter（指标导出器）是 Prometheus 生态中的核心组件，负责从各类目标系统采集指标数据，并通过 HTTP `/metrics` 端点暴露 Prometheus 格式的指标，供 Prometheus 服务器定期抓取。Exporter 不处理数据存储和告警，只做"采集 + 暴露"这一件事。 - -## Design Philosophy -- **无代理（Agentless）**：大多数 exporter 作为独立进程运行，不需要在被监控系统上安装额外软件 -- **HTTP 暴露**：通过标准的 `/metrics` 端点提供文本格式的指标 -- **松耦合**：Exporter 与 Prometheus 通过 HTTP 协议解耦，可独立部署和升级 -- **Pull 模式**：Prometheus 主动抓取，而非 exporter 主动推送 - -## Official Exporters -| Exporter | 指标来源 | 默认端口 | -|----------|----------|----------| -| [[node_exporter]] | Linux/Unix 主机（CPU/内存/磁盘/网络） | 9100 | -| [[cAdvisor]] | Docker 容器 | 8080 | -| [[blackbox_exporter]] | HTTP/TCP/DNS/TLS 端点 | 9115 | -| alertmanager | Alertmanager 实例 | 9093 | -| postgres_exporter | PostgreSQL 数据库 | 9187 | -| mysql_exporter | MySQL/MariaDB 数据库 | 9104 | -| redis_exporter | Redis 缓存 | 9121 | -| nginx-exporter | Nginx 状态页 | 9113 | - -## /metrics Format -```text -# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode. -# TYPE node_cpu_seconds_total counter -node_cpu_seconds_total{cpu="0",mode="idle"} 123456.789 -node_cpu_seconds_total{cpu="0",mode="user"} 98765.432 -``` - -## Key Fields -- `# HELP`：指标说明（人类可读描述） -- `# TYPE`：指标类型（gauge / counter / histogram / summary） -- 指标行：`{} ` - -## Prometheus scrape_config -```yaml -scrape_configs: - - job_name: 'node_exporter' - static_configs: - - targets: ['192.168.1.10:9100'] -``` - -## Related Entities -- [[Prometheus]] — 数据消费者 -- [[node_exporter]] — 主机指标 exporter -- [[cAdvisor]] — 容器指标 exporter -- [[blackbox_exporter]] — 网络探测 exporter -- [[Alertmanager]] — 告警 exporter - -## Related Concepts -- [[PromQL]] — 指标查询语言 -- [[Prometheus告警规则]] — 基于 exporter 指标的告警条件 -- [[时序数据库]] — exporter 产出的数据存储模型 -- [[System Monitoring]] — 应用领域 diff --git a/wiki/concepts/Extended Thinking.md b/wiki/concepts/Extended Thinking.md deleted file mode 100644 index 6596004d..00000000 --- a/wiki/concepts/Extended Thinking.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: "Extended Thinking" -type: concept -tags: [claude, reasoning, ai-mode] -last_updated: 2025-12-31 ---- - -## Overview -**Extended Thinking** 是 Claude 的一种运行模式，支持更深层次的逻辑推理。当启用此模式后，Claude 会在生成响应前进行更长时间、更详细的推理过程，从而提升复杂任务的输出质量，特别是在代码生成和工作流设计场景中效果显著。 - -## Usage -在 Claude 客户端设置中开启 Extended Thinking 模式，可搭配 OpenSea 模型使用以获得最佳代码生成效果。 - -## Related -- [[Claude]] — 提供 Extended Thinking 的 AI 助手 -- [[工作流自动化]] — Extended Thinking 提升的典型应用场景 diff --git a/wiki/concepts/ExternalReasoning.md b/wiki/concepts/ExternalReasoning.md deleted file mode 100644 index 8dab89b8..00000000 --- a/wiki/concepts/ExternalReasoning.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "ExternalReasoning" -type: concept -tags: [] -last_updated: 2026-05-02 ---- - -## Definition -将 AI Agent 内部推理过程外化到外部系统（如 Todoist、Notion、数据库）的方法——使 Agent 的思考过程对人类可见，提高 Agent 行为的可观测性和可审计性。 - -## Description -传统 AI 系统是"黑箱"——用户只能看到输入和输出，看不到中间推理。ExternalReasoning 反其道而行： -- 将 Agent 的"思考"（Plan）写入外部系统的任务描述字段 -- 将中间步骤的推理结果追加为评论或日志 -- 保留完整的推理轨迹，供后续回溯和分析 - -核心价值： -- **可观测性**：用户实时了解 Agent 在想什么、做什么 -- **可审计性**：记录完整的决策链，便于事后复盘 -- **协同交接**：不同 Agent 或人类可以通过外部系统理解当前状态 - -## Implementation Patterns -- 任务描述字段存储 Agent 的 Plan/Strategy -- 任务评论追加推理过程和步骤完成记录 -- 外部系统（如 Todoist）作为推理过程的"外脑" - -## Related Concepts -- [[TaskVisibility]] -- [[AgenticWorkflow]] - -## Examples -- [[TodoistTaskManager]]：将 Agent Plan 外化到 Todoist 任务描述，将子步骤日志追加为评论 diff --git a/wiki/concepts/FIA-Framework.md b/wiki/concepts/FIA-Framework.md deleted file mode 100644 index ea94ea0c..00000000 --- a/wiki/concepts/FIA-Framework.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "FIA Framework" -type: concept -tags: [sales, competitive-positioning, pre-sales, battlecard] -last_updated: 2026-04-25 ---- - -## Definition -FIA Framework（Fact-Impact-Act）是事实基础竞争技术定位框架——为每个竞品构建竞争卡（battlecard），通过客观事实→业务影响→具体行动的三层结构，将竞争定位从情绪化和反应式转变为事实基础和可执行性。 - -## Three Layers - -### F — Fact -- 关于竞品产品或方法的客观真实陈述 -- 无夸大、无偏见 -- **可信度是 SE 最宝贵的资产**——一次失信，技术评估就结束了 - -### I — Impact -- 为什么这个事实对买家重要 -- 事实没有业务影响就是 trivia -- 模板："这意味着[买家实际承担的后果]" - -### A — Act -- 说什么或做什么 -- 具体的 talk track、问题或 demo 时刻 - -## FIA Example -- **Fact**: "竞品 X 需要专用 ETL 层进行数据摄取" -- **Impact**: "这意味着你的团队需要维护另一个集成点，增加 2-3 周实施时间和持续维护开销" -- **Act**: "在 POC 演示中展示我们的零 ETL 原生集成，用实时数据连接替代批处理等待" - -## Competitive Repositioning Over Attacking -永远不要攻击竞争对手。模式： -> "他们在 [已认可的优势] 方面很出色。我们的客户通常需要 [不同需求]，因为 [业务原因]，而这正是我们的差异化所在。" - -这展现信心和专业度。攻击竞品显得不自信并激活买家的防御心理。 - -## Landmine Questions -在技术发现阶段提出自然暴露竞品弱点的合法问题： -- "你们目前如何处理 [我们架构独特的场景]？" -- "当 [我们的产品原生处理而竞品不处理的边界情况] 时会发生什么？" -- "你们评估过 [映射到我们差异化点的需求] 将如何随团队增长而扩展吗？" - -关键：这些问题必须对买家的评估真正有帮助。如果感觉像"种草"，会适得其反。 - -## Winning / Battling / Losing Zones -| 区域 | 策略 | -|------|------| -| **Winning** | 架构/性能/集成能力明显优于——围绕这些构建 demo，让它们在评估中权重更高 | -| **Battling** | 两者均可——转向实施速度、运营开销或总拥有成本以创造差异化 | -| **Losing** | 竞品确实更强——承认它，然后重新定位："那个能力很重要——对于主要关注 [竞品用例] 的团队是强选择。对于您的环境，[买家优先事项] 是主要驱动因素，以下是我们的长期价值..." | - -## Connections -- [[SalesEngineer]] — FIA Framework 是 Sales Engineer 的核心能力之一 -- [[DemoEngineering]] — FIA 中 "Act" 环节的许多具体执行在 Demo Engineering 中完成 -- [[POC-Scoping]] — POC 阶段是 FIA Framework 密集应用的场景 - -## Contradictions -- 无已知冲突 diff --git a/wiki/concepts/Fabula-Sjuzhet.md b/wiki/concepts/Fabula-Sjuzhet.md deleted file mode 100644 index 2ad9b508..00000000 --- a/wiki/concepts/Fabula-Sjuzhet.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Fabula 与 Sjuzhet" -type: concept -tags: [narratology, story-structure, Russian-formalism] -sources: ["academic-narratologist"] -last_updated: 2026-05-02 ---- - -## Definition - -**Fabula**（故事）与 **Sjuzhet**（叙事）是叙事学（特别是俄罗斯形式主义）的核心二元对立概念： - -- **Fabula**（俄语：фабула）：按时间顺序发生的所有事件，是故事的"原始材料"——无论叙事顺序如何，这些事件客观存在 -- **Sjuzhet**（俄语：сюжет）：叙事者实际呈现事件的顺序和方式，即"如何讲述"，包括倒叙、闪前、省略、并置等手法 - -两者区分的核心意义：叙事问题通常存在于 sjuzhet 层面，而非 fabula 层面——改变讲述顺序比改变事件本身更能影响读者体验。 - -## Key Distinctions - -| 维度 | Fabula（故事） | Sjuzhet（叙事） | -|------|--------------|----------------| -| 本质 | 事件的逻辑-时间序列 | 呈现给读者的序列 | -| 顺序 | 客观因果-时间关系 | 可任意重组（倒叙、闪前） | -| 范围 | 包含所有已知事件 | 仅包含叙事者选择透露的事件 | -| 决定因素 | 情节本身 | 叙事策略与视角 | - -## Applications - -- **[[academic-narratologist]]** 强调：大多数叙事问题存在于讲述层面（sjuzhet）而非故事层面（fabula），诊断应优先于处方 -- 电影[[线性叙事 vs 非线性叙事]]的核心理论基础 -- **[[Character-Arc]]** 分析中，fabula 决定角色经历了什么，sjuzhet 决定读者何时知道这些 - -## Related Concepts - -- [[Character-Arc]]：角色弧光如何在 fabula 中展开，通过 sjuzhet 呈现 -- [[Propp-Morphology]]：Propp 的功能分析属于 fabula 层面的研究 -- [[Barthes-Five-Codes]]：Barthes 的叙事语义分析属于 sjuzhet 层面的研究 - -## Critical Notes - -- "讲什么故事"（fabula）与"怎么讲故事"（sjuzhet）的区分不等于"情节"（plot）与"故事"（story）的区分——后者是英美文论术语，前者是形式主义俄语遗产 -- 在互动叙事/游戏叙事中，玩家行为构成动态 fabula，叙事者通过 sjuzhet 选择如何呈现 diff --git a/wiki/concepts/Fabula-vs-Sjuzhet.md b/wiki/concepts/Fabula-vs-Sjuzhet.md deleted file mode 100644 index 178c4fb1..00000000 --- a/wiki/concepts/Fabula-vs-Sjuzhet.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Fabula vs. Sjuzhet" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-30 ---- - -## Aliases -- Fabula vs. Sjuzhet -- Story vs. Narrative -- 故事 vs. 叙事 -- 事件 vs. 呈现 - -## Overview -Fabula（故事）与 Sjuzhet（叙事话语）是 Russian Formalism 提出的核心区分，后经 [[Vladimir Propp]] 和 French Structuralism 发展完善。 - -| 术语 | 定义 | 问法 | -|------|------|------| -| **Fabula** | 按实际时间顺序发生的所有事件集合 | "发生了什么？" | -| **Sjuzhet** | 事件在叙事中被呈现的方式（顺序、省略、重复、聚焦） | "故事是怎么讲的？" | - -## Key Implications - -### The Critical Insight（[[Academic Narratologist]] 核心观点） -> "Most problems live in the telling (sjuzhet), not the tale (fabula)." - -大多数叙事问题存在于讲述方式（如何重组、选择、省略、聚焦），而非故事本身。 - -### Example -- **Fabula**: 英雄被选中 → 接受训练 → 与反派战斗 → 获胜 -- **Sjuzhet variants**: - - 从反派视角讲述 → 产生反英雄同情 - - 倒叙讲述 → 制造悬念 - - 从中间开始 → 省去建置阶段 - -## Application -- 诊断叙事问题时，必须先判断问题在哪个层级 -- [[Academic Narratologist]] 使用此框架区分"情节问题"和"讲述问题" - -## Relationship to Other Concepts -- [[Genette-Narratology]]：Genette 深化了 sjuzhet 的分析维度（时序、频率、声音） -- [[ControllingIdea]]：Controlling Idea 存在于 fabula 层，但通过 sjuzhet 层传达 diff --git a/wiki/concepts/Fact-Recall-vs-Compounding.md b/wiki/concepts/Fact-Recall-vs-Compounding.md deleted file mode 100644 index 12c3fa5b..00000000 --- a/wiki/concepts/Fact-Recall-vs-Compounding.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: "Fact-Recall-vs-Compounding" -type: concept -tags: [AI-Memory, Memory-Backend, Context-Substrate, Optimization-Goal] -sources: [ai-memory-tools-two-camps] -last_updated: 2026-04-15 ---- - -## Definition -AI 记忆工具领域的两种根本不同的优化目标： -- **Fact Recall（事实召回）**：Memory Backend 范式追求的目标——系统能否找到正确的事实？ -- **Compounding（复合增长）**：Context Substrate 范式追求的目标——系统是否随时间变得更好？ - -## Camp 1: Fact Recall（事实召回） - -### Definition -给定一个查询，从存储的记忆中找到最相关的事实。 - -### Metric -召回精度（recall accuracy），通常以百分比衡量： -- [[MemPalace]]：LongMemEval 纯语义搜索 **96.6%** -- [[Supermemory]]：LongMemEval + LoCoMo + ConvoMem 声称第一 - -### What This Optimizes For -- "我三周前说的那句话是什么？" -- "用户喜欢什么？" -- "上次讨论 X 时说了什么？" - -### Limitations -- 精度再高，也只是"找到过去说过的话" -- 无法让 Agent 变得"更好"——只是更准确地记住 -- 记忆是静态条目，不随交互演进 - -## Camp 2: Compounding（复合增长） - -### Definition -系统随时间和使用变得更丰富、更有价值——上下文在每次交互后复合增长。 - -### Metric -难以量化，但可以观察： -- 上下文在多会话后的丰富程度 -- Agent 决策质量的随时间提升 -- 人类对 Agent 上下文的理解程度 - -### What This Optimizes For -- "给我跨五个项目的当前工作状态" -- "我的 Agent 今天应该优先做什么？" -- "过去三周发生了什么重要决策？" - -### Advantage -- 上下文本身就是可读的、可审计的 -- 人类可以理解、纠正、补充 Agent 的上下文 -- 上下文复合增长 → Agent 能力随时间提升 - -## The Fundamental Difference - -| 问题 | Fact Recall | Compounding | -|------|-----------|-------------| -| 问 | "AI 应该记住什么？" | "AI 应该在什么上下文中工作？" | -| 记忆是 | 提取的事实条目 | 累积的上下文文件 | -| 随时间 | 静态（条目不演进） | 动态（复合增长） | -| 人类交互 | 黑盒（不直接操作） | 白盒（直接读写文件） | -| 适用场景 | 单轮问答 | 持续 Agent | - -## Why Both Matter -对于简单场景（聊天机器人记住用户偏好），Fact Recall 足够好。对于持续运行、多会话、多项目的 Agent，必须有 Compounding 能力。两者不互斥，但必须理解何时用哪个。 - -## Connections -- [[Memory-Backend]] ← 优化目标 ← Memory-Backend 优化 Fact Recall -- [[Context-Substrate]] ← 优化目标 ← Context-Substrate 优化 Compounding -- [[ai-memory-tools-two-camps]] ← 来源 ← Fact-Recall-vs-Compounding 是 @witcheer 分类框架的核心区分轴 diff --git a/wiki/concepts/Fail-Closed.md b/wiki/concepts/Fail-Closed.md deleted file mode 100644 index d55d2930..00000000 --- a/wiki/concepts/Fail-Closed.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Fail-Closed" -type: concept -tags: [authorization, security, default-deny] -sources: [agentic-identity-trust.md] -last_updated: 2026-04-25 ---- - -## Definition - -Fail-Closed（故障关闭）是一种安全授权策略——当验证系统无法完成验证时，默认结果为**拒绝**，而非**允许**。这是 Zero-Trust 架构的必然推论。 - -## Fail-Closed Rules - -| 验证失败场景 | 默认行为 | -|------------|---------| -| 身份无法验证 | 拒绝操作 | -| 委托链存在断裂 | 拒绝操作 | -| 证据无法写入 | 拒绝操作 | -| 信任评分低于阈值 | 要求重新验证，拒绝操作 | -| 凭证已过期 | 拒绝操作 | - -## vs. Fail-Open - -| 策略 | 无法验证时的行为 | 适用场景 | -|------|----------------|---------| -| **Fail-Closed**（本文档） | 拒绝操作 | 高风险操作（金融交易、基础设施部署、物理控制） | -| **Fail-Open** | 允许操作 | 低风险操作（读操作、内部服务调用） | - -## Relationships -- [[Zero-Trust]]：Fail-Closed 是 Zero-Trust 默认不信任原则的具体化 -- [[Delegation-Chain]]：委托链验证采用 Fail-Closed 策略 -- [[Peer-Verification]]：Peer 验证的所有检查均采用 Fail-Closed - -## Sources -- [[agentic-identity-trust.md]] diff --git a/wiki/concepts/Failover.md b/wiki/concepts/Failover.md deleted file mode 100644 index 0a244faa..00000000 --- a/wiki/concepts/Failover.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "Failover" -type: concept -tags: [cloud-computing, reliability, high-availability] -date: 2025-03-02 ---- - -# Failover - -**Failover**（故障转移）是高可用性系统的核心机制，当主系统发生故障时，自动切换到备用系统，确保服务连续性。 - -## Definition - -故障转移是一种自动化的冗余机制，监控系统检测到主节点故障后，自动将流量或工作负载切换到备用节点，用户通常无感知。 - -## Key Characteristics - -- **自动化**：无需人工干预，自动检测和切换 -- **快速恢复**：切换时间可从几分钟缩短到秒级 -- **透明切换**：用户无感知或感知极小中断 -- **健康检查**：持续监控主节点健康状态 - -## Failover Patterns in Cloud - -| Pattern | Description | -|---------|-------------| -| **Active-Passive** | 主节点处理流量，备用节点待命；故障时切换 | -| **Active-Active** | 多个节点同时处理流量；故障节点自动剔除 | -| **Geo-Failover** | 跨地理区域的故障转移 | -| **Multi-Region** | 多区域部署，单区域故障不影响其他区域 | - -## Cloud Myths Context - -Failover 是反驳"云不可靠"误解的关键机制： -- 云服务商通过全球分布式架构实现跨区域故障转移 -- 自动化故障转移 SLA 保障 99.99% 可用性 -- 传统本地部署难以实现同等水平的故障转移能力 - -## Implementation Components - -- **Load Balancer**：健康检查 + 流量分发 -- **Health Checks**：定期检测服务可用性 -- **DNS Failover**：Route 53 / Cloud DNS 的 DNS 级切换 -- **Database Replication**：数据库级别的同步/异步复制 -- **Auto Scaling Groups**：实例级别的自动替换 - -## Related Concepts - -- [[High-Availability]] — 高可用性 -- [[cloud-computing]] — 云计算 -- [[Scalability]] — 可扩展性 -- [[Disaster-Recovery]] — 灾难恢复 -- [[cloud-migration]] — 云迁移 - -## Sources - -- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]] diff --git a/wiki/concepts/Failure-Pattern-Analysis.md b/wiki/concepts/Failure-Pattern-Analysis.md deleted file mode 100644 index 2ef8701a..00000000 --- a/wiki/concepts/Failure-Pattern-Analysis.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Failure Pattern Analysis" -type: concept -tags: [testing, failure-analysis, quality] -sources: [testing-test-results-analyzer] -last_updated: 2026-04-28 ---- - -## Aliases -- Defect Pattern Analysis -- Test Failure Classification -- Root Cause Pattern Detection - -## Definition - -失败模式分析——通过统计方法对测试失败进行分类、聚类和趋势分析，识别系统性质量问题并定位根因。 - -## Failure Categories - -| 类别 | 说明 | 典型特征 | -|------|------|---------| -| 功能性 (Functional) | 功能行为不符合预期 | 逻辑错误、边界条件 | -| 性能 (Performance) | 响应时间/SLA 不达标 | 慢查询、资源瓶颈 | -| 安全 (Security) | 安全漏洞或合规问题 | 注入、权限绕过 | -| 集成 (Integration) | 模块间接口不一致 | API 变更、协议不匹配 | - -## Key Methods - -- **Statistical Failure Trend Analysis**：跨时间序列分析失败率变化，识别恶化趋势。 -- **Root Cause Clustering**：将相似失败聚类，定位共同根因。 -- **Failure Distribution by Layer**：按系统层次（UI/业务逻辑/数据/基础设施）分布分析，识别系统性薄弱层。 - -## Key Insights (from TestResultsAnalyzer) - -> "Failure pattern analysis reveals 73% of defects originate from integration layer" — 系统层分布分析洞察示例 - -## Connections - -- [[Statistical-Analysis]]：失败模式分析依赖统计方法验证。 -- [[Root-Cause-Analysis]]：失败模式分析的下游是根因定位。 -- [[Dev-QA-Loop]]：失败模式分析结果反馈到开发-测试循环以调整测试策略。 -- [[Quality-Metrics]]：失败率是核心质量指标。 diff --git a/wiki/concepts/Fairness-Audit.md b/wiki/concepts/Fairness-Audit.md deleted file mode 100644 index 7d045a23..00000000 --- a/wiki/concepts/Fairness-Audit.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "Fairness Audit" -type: concept -tags: [model-evaluation, fairness, bias, ml-ethics, model-governance] -sources: - - specialized-model-qa -last_updated: 2026-05-29 ---- - -## Definition - -公平性审计（Fairness Audit）是 ML 模型审计中评估模型是否对不同受保护群体（protected groups）产生系统性歧视的过程。核心目标：识别和量化模型预测中基于种族、性别、年龄、宗教、国籍等受保护属性的不公平差异，确保模型符合伦理规范和监管要求。 - -## Core Metrics - -### Demographic Parity（人口统计均等） -- 要求：模型的正预测率在各群体间相等 -- 公式：$P(\hat{Y}=1|A=0) = P(\hat{Y}=1|A=1)$ -- 也称为：Statistical Parity, Independence Criterion - -### Equalized Odds（均等化赔率） -- 要求：在相同真实标签条件下，各群体的预测分布相等 -- 公式：$P(\hat{Y}=1|A=0,Y=y) = P(\hat{Y}=1|A=1,Y=y)$，for $y \in \{0,1\}$ -- 比 Demographic Parity 更严格，同时要求 TPR 和 FPR 在各群体间相等 - -### Disparate Impact Ratio（差异影响比） -- $DIR = \frac{P(\hat{Y}=1|A=\text{minority})}{P(\hat{Y}=1|A=\text{majority})}$ -- 4/5 规则：DIR < 0.8 通常视为存在差异影响 - -### Calibration Across Groups -- 在各受保护群体上分别验证预测概率校准性 -- 确保高风险决策（贷款拒绝、保险定价）不会系统性低估某群体 - -## Model QA 中的应用 - -Model QA Specialist 执行以下公平性审计步骤： -1. **受保护属性识别**：确认模型决策涉及哪些受保护特征（法律/道德/业务角度） -2. **Baseline 指标计算**：在全人群上计算 AUC/KS/Gini 作为基准 -3. **分层指标对比**：在受保护群体上分别计算性能指标，量化差距 -4. **差异影响评估**：DIR < 0.8 则标记为潜在歧视，需进一步调查 -5. **因果分析**：区分相关关系（Correlation）与因果效应（Causation），避免虚假公平性 -6. **补救建议**：Pre-processing（重采样/重加权）/ In-processing（对抗训练/约束优化）/ Post-processing（阈值调整） - -## Relationship - -- **依赖** [[Discrimination-Metrics]]：公平性审计首先建立在判别能力评估之上 -- **依赖** [[SHAP]]：SHAP 贡献分析揭示哪些特征驱动了跨群体差异 -- **依赖** [[Calibration-Testing]]：跨群体校准是公平性决策的基础 -- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的可解释性与公平性审计步骤核心工具 - -## Key Limitations - -- **公平性指标不可同时最优**：Demographic Parity 与 Equalized Odds 在一般情况下不可同时满足（Impossibility Theorem） -- **代理变量问题**：直接排除受保护属性后，模型仍可能通过代理变量（如邮编→种族）歧视 -- **数据不平衡**：受保护群体的稀缺样本可能导致统计结论不可靠 -- **监管框架差异**：欧盟 AI Act / 美国 EEOC / 巴塞尔协议对公平性要求各不相同 diff --git a/wiki/concepts/False-Cognates.md b/wiki/concepts/False-Cognates.md deleted file mode 100644 index 203800ef..00000000 --- a/wiki/concepts/False-Cognates.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "False Cognates" -type: concept -tags: ["spanish", "linguistics", "translation", "false-friends", "cognates", "trap"] -last_updated: 2026-05-02 ---- - -## Definition - -**False Cognates**（假同源词/欺骗性同源词）指那些在两种语言中看起来相似但含义完全不同的词汇。如果直接翻译会导致严重误解甚至尴尬。 - -## High-Risk Spanish-English False Cognates - -| 西班牙语 | 字面/错误理解 | 实际含义 | 严重程度 | -|---|---|---|---| -| **embarazada** | "embarrassed"（尴尬） | **怀孕** | ⚠️ 极高 | -| **sensible** | "sensible"（理智的） | **敏感的** | ⚠️ 中等 | -| **éxito** | "exit"（出口） | **成功** | ⚠️ 中等 | -| **actual** | "actual"（真实的） | **当前的/现在的** | ⚠️ 中等 | -| **asistir** | "assist"（帮助） | **参加/出席** | ⚠️ 中等 | -| **carpet** | (英语) | **公交车**（西班牙/拉丁美洲部分地区） | 🔴 极高 | -| **constipated** | (英语) | **鼻塞**（英语） | 🔴 极高（仅西班牙语语境） | -| **molestar** | "molest"（骚扰） | **打扰/麻烦** | ⚠️ 高 | -| **deception** | (英语) | **欺骗** | ⚠️ 高（西班牙语中"decepción"=失望） | -| **casualmente** | "casually"（随便地） | **碰巧/偶然** | ⚠️ 中等 | -| **oportunidad** | "opportunity"（机会） | **机会**（含义相同，但西班牙语中也指"商店营业时间"） | ⚠️ 低 | -| **desgraciado** | 看起来像"disgraceful" | **可怜的/可恶的**（程度比英语"disgraceful"重得多） | ⚠️ 高 | - -## More Examples - -| 西班牙语 | 英文对应词 | 西班牙语实际含义 | -|---|---|---| -| **largo** | large | **长的** | -| **grosero** | gross | **粗鲁的** | -| **excitado** | excited | **兴奋的/激动的**（英语 excited 的自然翻译，但也暗示性兴奋） | -| **fábrica** | fabric | **工厂** | -| **intoxicado** | intoxicated | **中毒的**（不仅限于酒精） | -| **lectura** | lecture | **阅读/读物** | -| **datos** | dates | **数据** | -| **dormitorio** | dormitory | **卧室** | - -## In Translation - -[[Language Translator]] Agent 的工作原则： -- 每当源语言或目标语言中出现假同源词，必须主动标注 -- 不允许字面翻译导致误解的场景发生 -- 对高风险词汇（如 embarazada）给予特别提示 - -## Prevention Strategy - -1. **Always verify**：看似相似的词必须查证实际含义 -2. **Context check**：即使知道正确含义，也要确认语境 -3. **Flag high-risk pairs**：embarazada/sensible/éxito/asistir 属于每次必标 - -## Sources -- [[language-translator]] diff --git a/wiki/concepts/Fan-Out-Pattern.md b/wiki/concepts/Fan-Out-Pattern.md deleted file mode 100644 index e37948d7..00000000 --- a/wiki/concepts/Fan-Out-Pattern.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Fan-Out Pattern" -type: concept -tags: - - EDA - - Architecture - - Messaging - - Cloud -last_updated: 2026-04-14 ---- - -## Aliases -- Fan-out -- 扇出模式 - -## Definition -扇出模式（Fan-Out Pattern）指将一个事件同时分发给多个消费者（订阅者）的模式。在事件驱动架构中，生产者发布一条消息，通过事件代理自动分发给所有感兴趣的消费者。 - -## Implementation -- **SNS Topic**：发布到 SNS Topic，多个 SQS 队列或 Lambda 函数订阅同一主题 -- **EventBridge Rules**：基于规则路由，将事件分发给不同的目标服务 - -## Use Cases -- 同一订单事件触发库存服务、支付服务、通知服务 -- 日志事件同时发送到 CloudWatch Logs、S3 和第三方监控系统 -- 数据同步：同一数据变更同步到多个下游系统 - -## Best Practices -- SNS Topic 订阅多个 SQS 队列实现可靠的消息传递 -- EventBridge 每个订阅者使用单一规则，便于维护和调试 -- 消费者独立扩展，不影响其他消费者 - -## Sources -- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] diff --git a/wiki/concepts/FasterWhisper.md b/wiki/concepts/FasterWhisper.md deleted file mode 100644 index 39d5372b..00000000 --- a/wiki/concepts/FasterWhisper.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "FasterWhisper" -type: concept -tags: ["voice-ai", "whisper", "local-llm", "ctranslate2"] -last_updated: 2026-05-02 ---- - -# FasterWhisper - -## Definition - -Faster-Whisper 是 OpenAI Whisper 的 CTranslate2 优化实现，在精度与原版相当的情况下，速度提升 2-4 倍，内存占用减少 50%+。是生产环境中本地转录的首选实现。 - -## Key Properties - -- **底层优化**：CTranslate2（自定义 CUDA/AVX kernel）替代 PyTorch 原生实现 -- **速度对比**：Whisper large-v3 在 A10G GPU 上约 2-3x 实时，Faster-Whisper 可达 8-10x 实时 -- **精度**：与原版 Whisper 几乎无差别（<0.5% WER 差异） -- **模型规模**：tiny / base / small / medium / large-v2 / large-v3 -- **关键参数**：`beam_size=5`（精度优先）、`word_timestamps=True`（字幕精度必需）、`vad_filter=True` -- **CPU 支持**：支持 CPU 推理（无 GPU 环境下的 viable 选项，速度较慢） - -## Model Size Selection Guide - -| 场景 | 推荐模型 | 硬件要求 | -|------|---------|---------| -| 实时/快速测试 | tiny / base | CPU 即可 | -| 平衡（大多数生产场景） | small / medium | GPU（RTX 3080+） | -| 最高精度（医疗/法律） | large-v3 | GPU（A10G / A100） | - -## Pipeline Role - -``` -音频预处理 → FasterWhisper.transcribe() → 带时间戳的转录段落 -``` - -## Related Concepts -- [[VoiceActivityDetection]] — 转录前的静音过滤 -- [[SpeakerDiarization]] — 转录结果与说话人标签的合并 -- [[OverlapAwareChunking]] — 长音频分块后逐块转录 -- [[EBUR128LoudnessNormalization]] — 归一化音频确保转录精度 -- [[PIIRedaction]] — 转录后的个人身份信息脱敏 -- [[StructuredTranscriptJSON]] — 转录结果的最终输出格式 - -## Related Entities -- [[OpenAIWhisper]] — Faster-Whisper 基于的基础模型 -- [[pyannote.audio]] — 说话人分离，与 Faster-Whisper 配套使用 - -## Related Sources -- [[engineering-voice-ai-integration-engineer]] diff --git a/wiki/concepts/Feature-Flag.md b/wiki/concepts/Feature-Flag.md deleted file mode 100644 index 063fe707..00000000 --- a/wiki/concepts/Feature-Flag.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: "Feature Flag (功能开关)" -tags: [devops, continuous-delivery, deployment, risk-mitigation, feature-management] -aliases: [Feature Flagging, Feature Toggle, Feature Switch] -created: 2026-04-25 ---- - -# Feature Flag (功能开关) - -**Feature Flag**（功能开关/功能标记）是一种将代码部署（Deploy）与功能发布（Release）解耦的技术机制。通过在代码中嵌入条件判断（开关），团队可以在不重新部署的情况下控制功能的可见性和行为。 - -## Aliases -- Feature Flagging -- Feature Toggle -- Feature Switch -- Kill Switch（紧急情况下的特殊用法） - -## Core Mechanism - -```javascript -if (featureFlag.enabled('new-checkout-flow')) { - return newCheckoutProcess(); -} else { - return oldCheckoutProcess(); -} -``` - -**关键洞察**：部署代码 ≠ 发布功能。代码可以在任何时间部署到生产环境，但功能发布由开关控制。 - -## Key Capabilities - -### 1. Decoupled Deployment & Release - -| 传统方式 | Feature Flag 方式 | -|----------|-------------------| -| 部署 = 发布 | 部署 ≠ 发布 | -| 2AM 部署"以防万一" | 随时部署，择机发布 | -| 全有或全无 | 灰度发布，渐进放量 | - -### 2. Kill Switch（应急切断） - -紧急情况下，无需重新部署即可关闭故障功能： - -- 支付网关异常？切换到备用提供商（秒级） -- 搜索结果异常？回退到旧算法（秒级） -- AI 模型产生幻觉？切换回上一版本（秒级） - -> "Instead of debugging under pressure while users suffer, you flip a switch and fix the problem properly later." - -### 3. Progressive Rollout（渐进式放量） - -分阶段向用户群发布功能，控制影响范围： - -``` -1% 用户 → 监控错误率、性能指标 -5% 用户 → 监控转化率、用户反馈 -25% 用户 → 检查下游系统负载 -100% 用户 → 完成全量发布 -``` - -如果 5% 阶段出现问题，RTO 以秒计（只需关闭开关），而不是小时级（需要紧急回滚部署）。 - -### 4. Micro-Recovery（Feature 级别微恢复） - -不再将整个应用视为单一系统，不同功能有不同的风险和业务影响： - -| 功能 | RTO 目标 | RPO 目标 | -|------|----------|----------| -| 核心支付处理 | 秒级 | 零丢失 | -| 新推荐引擎 | 5 分钟 | 15 分钟 | -| Beta 仪表盘功能 | 30 分钟 | 1 小时 | - -### 5. 定向回滚（Targeted Rollback） - -如果某个功能只影响欧洲移动用户，可以仅针对该用户群禁用该功能，其他用户不受影响。 - -## Feature Flag vs. 传统灾备 - -| 维度 | 传统灾备 | Feature Flag | -|------|----------|--------------| -| 目标故障类型 | 硬件故障 | 代码变更 | -| RTO | 小时级（从备份恢复） | 秒级（配置变更） | -| RPO | 取决于备份频率 | 近零（不触碰数据层） | -| 故障频率 | 低（年均几次） | 高（每周可能发生） | -| 成本 | 高（冗余基础设施） | 低（软件工具） | - -## 商业案例数据 - -| 公司 | 改进前 | 改进后 | -|------|--------|--------| -| HP | 回滚时间：小时级 | 分钟级 | -| Christian Dior | 回滚时间：15 分钟 | 即时切换 | -| LaunchDarkly 客户 | — | 86% 在一天内恢复 | -| LaunchDarkly 客户 | — | 42% 在小时级（甚至分钟级）恢复 | - -**成本效益**：59% 的 LaunchDarkly 客户表示运维成本降低 11%-50%，8% 表示降低超过 50%。 - -## 核心价值 - -> "Deploy with confidence, recover instantly, and focus on building features instead of fixing outages." - -Feature Flag 将问题响应从**被动救火**转变为**主动预防**： - -- **预防优于恢复**：在 1% 用户中发现问题，比全量发布后止损更有价值 -- **减少焦虑**：部署不再可怕，随时可以回退 -- **提高迭代速度**：团队敢于快速实验 - -## Related Concepts - -- [[Kill Switch]] — Feature Flag 在紧急情况下的用法 -- [[Progressive Rollout]] — Feature Flag 支持的渐进式放量策略 -- [[Micro-Recovery]] — Feature Flag 实现的 feature 级别细粒度恢复 -- [[Deployment-vs-Release]] — Feature Flag 实现的部署与发布解耦 -- [[RTO]] — Feature Flag 将 RTO 从小时降至秒级 -- [[RPO]] — Feature Flag 保护 RPO（不丢失数据） -- [[LaunchDarkly]] — Feature Flag 管理平台 -- [[CI-CD-Pipeline]] — Feature Flag 是现代 CI/CD 的核心基础设施 - -## Sources - -- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] -- [[sources/devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin.md]] -- [[sources/Deployment-Automation.md]] diff --git a/wiki/concepts/FeatureList.md b/wiki/concepts/FeatureList.md deleted file mode 100644 index f4a2a006..00000000 --- a/wiki/concepts/FeatureList.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "FeatureList" -type: concept -tags: [产品经理, 需求管理, AI协作] -sources: [不会gemini的产品经理真的要被淘汰了-附保姆级prd生成指南] -last_updated: 2025-12-18 ---- - -## Aliases -- Feature List -- 功能列表 -- 需求功能表 - -## 定义 - -**FeatureList**（功能需求列表）是一种层级式产品需求结构化文档，用于在编写正式 PRD 之前构思和梳理产品框架。与传统脑图本质相同，但以表格形式呈现，便于与大模型协作迭代。 - -## 核心用途 - -1. **分层分类**：梳理各个功能模块的分层、分类是否合理 -2. **功能点完整性**：检查某细分模块的功能点是否全面、划分是否合理 -3. **优先级评估**：评估每个功能点的优先级 - -## FeatureList 表头示例 - -| 模块 | 二级功能 | 三级功能 | 四级功能 | 优先级 | 备注 | -|------|----------|----------|----------|--------|------| -| 英雄管理 | 基础信息维护 | 名称维护 | - | P0 | - | - -## 与大模型协作的工作流 - -``` -产品经理 → 提供FeatureList模板 + 自然语言需求框架描述 - ↓ -Gemini/Claude → 按模板输出层级式功能点 - ↓ -产品经理 → 审核并追问关键业务问题 - ↓ -Gemini/Claude → 输出终版FeatureList - ↓ -产品经理 → 进入PRD阶段 -``` - -## 核心原则 - -**人负责"想"，大模型负责"写"** - -- 产品经理只需用只言片语描述需求（"做什么"） -- 大模型负责补全边界场景定义、通用规则描述、严谨的行文格式 -- 不要期望大模型"一句话需求就出完美文档"——这不现实 - -## 常见问题与解决 - -| 问题 | 解决方案 | -|------|----------| -| 表格格式导出到Excel错行 | 点击"导出到Google表格"，再复制出来 | -| 大模型用制表符代替真正表格 | 直接把制表符文本贴回去，告诉它改成表格 | -| 只输出到二级功能，漏掉优先级字段 | 严厉指出问题，它会立即修正 | - -## Connections -- [[PRD生成工作流]] ← 使用 ← [[FeatureList]] -- [[不会gemini的产品经理真的要淘汰]] ← 来源 ← [[FeatureList]] -- [[Mermaid]] ← 协同工具 ← [[FeatureList]] diff --git a/wiki/concepts/FedRAMP.md b/wiki/concepts/FedRAMP.md deleted file mode 100644 index 2b0caf67..00000000 --- a/wiki/concepts/FedRAMP.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "FedRAMP" -type: concept -tags: - - Compliance - - Cloud-Security - - Government - - Certification -last_updated: 2026-04-14 ---- - -# FedRAMP (Federal Risk and Authorization Management Program) - -## Definition -美国政府级的云安全认证项目，为云服务和云产品提供统一的安全评估和授权标准。FedRAMP 基于 [[ISO-27001]] 和 NIST SP 800-53 控制框架。 - -## Purpose -- 为联邦机构提供标准化的云服务安全评估方法 -- 减少重复安全评估，降低成本 -- 确保云服务提供商达到政府级别的安全标准 - -## Business Value for OpenText -- **市场准入**：FedRAMP 认证使 OpenText 能够向联邦政府机构销售云服务 -- **多垂直市场覆盖**：持有 FedRAMP 等多项行业及政府认证，可进入多个垂直市场 -- **差异化优势**：证明安全成熟度，增强客户信心 - -## Relationship to Other Concepts -- 基于 [[ISO-27001]] 构建 -- 与 [[Global Information Security Policy (GISP)]] 配合，满足政策层面的合规要求 -- 与 [[Third-Party-Penetration-Testing]] 配合，通过第三方验证满足认证要求 - -## Connections -- [[ISO-27001]]：框架基础 -- [[Global Information Security Policy (GISP)]]：政策支撑 -- [[OpenText]]：持有该认证的组织 diff --git a/wiki/concepts/Federated-Access.md b/wiki/concepts/Federated-Access.md deleted file mode 100644 index 1122253a..00000000 --- a/wiki/concepts/Federated-Access.md +++ /dev/null @@ -1,39 +0,0 @@ ---- ---- -title: "Federated Access" -type: concept -sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-11-ad-integration-and-login-using-ad-accounts] -last_updated: 2026-04-14 ---- - -## Definition -联邦访问（Federated Access）是一种基于身份联合（Identity Federation）的 AWS 身份管理机制。用户通过企业现有身份提供者（如 Active Directory）进行身份验证，由 AD 组自动映射到对应的 IAM 角色，从而获得云平台资源的访问权限，无需在 AWS 中单独创建和管理 IAM 用户。 - -## Key Benefits -- **集中身份管理**：使用企业现有 AD，无需在 AWS 中单独管理用户账号 -- **自动化权限分配**：AD 组 → IAM 角色的映射自动化，人员变动即时生效 -- **安全审计**：所有访问通过 AD 域控制器统一记录和审计 -- **消除凭证共享**：避免 IAM Access Key 的分发和管理风险 - -## Architecture -- **Identity Provider (IdP)**：企业 Active Directory -- **AWS IAM Identity Provider**：在 AWS 中配置 SAML 2.0 联合身份 -- **IAM Roles**：定义具体权限策略，信任策略允许 IdP 中的特定 AD 组 -- **AD Groups**：在 AD 中维护的组，按职能或项目划分 - -## Workflow -1. 用户在企业网络登录 AD 账户 -2. 通过 AWS SSO 或 SAML 联合发起 AWS 控制台或 CLI 访问请求 -3. AWS 使用 AD 凭证验证用户身份 -4. 根据用户所属 AD 组，分配对应 IAM 角色的临时凭证 -5. 凭证自动过期，强制定期重新认证 - -## Related Concepts -- [[Landing-Zone-Architecture]]：联邦访问是 Landing Zone 安全账户的核心身份管理机制 -- [[IAM]]：AWS 身份和访问管理的底层服务 -- [[Active-Directory]]：企业侧的联合身份提供者 - -## References -- [[ctp-topic-1-gruntwork-landing-zone-architecture]] -- [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]] -- [[ctp-topic-5-aws-identity-and-access-management-iam]] diff --git a/wiki/concepts/Feedback-Loop.md b/wiki/concepts/Feedback-Loop.md deleted file mode 100644 index 09c4898e..00000000 --- a/wiki/concepts/Feedback-Loop.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Feedback Loop" -type: concept -tags: [multi-agent, workflow-pattern, iteration, quality-assurance] -last_updated: 2026-04-25 ---- - -## Definition - -后续 Agent（通常是 Reviewer/QA 角色）对前序 Agent 的产出进行审查，生成具体改进建议，前序 Agent 根据反馈修改后再交付的迭代机制。 - -## Core Principle - -反馈必须是**具体的、可执行的**，而非泛泛的评价。"CTA 按钮颜色对比度不够"比"设计不够好"有价值一万倍。 - -## Usage in The Agency - -- [[workflow-landing-page]]：Growth Hacker 审查 HTML 后给出具体修改意见 → Frontend Developer 15:30 前应用反馈并交付最终版本 -- [[workflow-startup-mvp]]：QA Auditor 检查第一版 → Dev 根据 Bug 报告修复 → Re-audit 循环直到达标 -- [[support-analytics-reporter]]：Analytics Reporter 生成报告 → 用户反馈 → 调整分析维度 - -## Structure - -``` -[Agent A 产出 v1] → [Reviewer Agent B 审查] → [具体改进建议] - ↑ ↓ - └──────────── [Agent A 修改后交付 v2] ←───────┘ -``` - -## Key Requirements - -1. **Reviewer 必须独立于 Creator**——自己评审自己的产出无效 -2. **反馈必须有具体量化指标**——"降低 50ms 加载时间"比"优化性能"有用 -3. **时间盒必须保护修改时间**——反馈没有时间完成修改等于无效 - -## Aliases -- Review-Iterate Cycle -- Quality Assurance Loop -- Iteration Cycle diff --git a/wiki/concepts/File-System-First-UI.md b/wiki/concepts/File-System-First-UI.md deleted file mode 100644 index 08a3e335..00000000 --- a/wiki/concepts/File-System-First-UI.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "File-System-First UI" -type: concept -tags: ["design-pattern", "agentic", "ux", "openclaw"] -last_updated: 2026-04-22 ---- - -## Overview -一种 Agent 原生 UI 设计范式——将所有 UI 配置、设置、过滤器、视图存储为文件系统中的文件（YAML/Markdown），使 AI Agent 可以像编辑代码一样自然地修改界面。 - -## Definition -传统 UI 依赖 API 或内部状态存储配置，Agent 需要通过 API 抽象层修改；而 File-System-First UI 直接让 Agent 读写配置文件，Agent 可以用相同的工具链（文件编辑、版本控制）操作 UI。 - -## Key Insight -> "Because every setting, filter, and view is stored as a YAML/markdown file, OpenClaw can modify the UI as naturally as it edits code. No API wrappers needed." -> — [[DenchClaw]] 核心设计哲学 - -## How It Works -1. **配置文件即 UI**: 所有视图定义、过滤器设置、列配置存储为 `.yaml` / `.md` 文件 -2. **Agent 直接编辑**: Agent 使用标准文件编辑工具修改配置 -3. **UI 自动响应**: 前端监听文件系统变化，实时更新界面 -4. **版本控制**: 所有变更通过 Git 追踪，支持回滚和协作 - -## Benefits -- **No API abstraction**: Agent 不需要理解 API，直接操作原始数据 -- **Standard tools**: Agent 用同一套文件编辑技能操作 UI 和代码 -- **Version control**: UI 配置变更天然被 Git 追踪 -- **Reproducibility**: 配置即代码，环境可复现 -- **Transparency**: 所有变更可审计、可回滚 - -## Related -- [[DenchClaw]]: File-System-First UI 的典型实现 -- [[Chrome Profile Cloning]]: 配合实现无缝浏览器自动化 -- [[One-Command-Setup]]: 配套的安装哲学 diff --git a/wiki/concepts/File-Watcher.md b/wiki/concepts/File-Watcher.md deleted file mode 100644 index 5fe60b9b..00000000 --- a/wiki/concepts/File-Watcher.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "File Watcher (Auto-Reindex)" -type: concept -tags: [automation, file-system, indexing, realtime] -sources: [semantic-memory-search] -last_updated: 2026-04-22 ---- - -## Aliases -- File Watcher -- 文件监视器 -- 文件监听 -- Auto-Reindex -- 自动重建索引 - -## Definition - -文件监视器是一种实时监控指定目录文件变化的机制，当文件被创建、修改或删除时，自动触发相应的索引更新操作。在语义搜索场景中，这意味着记忆文件的变更会即时反映到向量索引中，保持索引与源文档的同步，无需手动重新运行索引命令。 - -## How It Works - -``` -文件系统事件 → 检测到变更 → 触发回调： - - 文件创建 → 计算哈希，Embedding，存入向量数据库 - - 文件修改 → 重新计算哈希，更新向量数据库记录 - - 文件删除 → 从向量数据库移除对应记录 -``` - -## Implementation Patterns - -| 方式 | 工具 | 说明 | -|------|------|------| -| 轮询 | `watchdog` (Python) | 跨平台，跨语言，通用 | -| 系统事件 | inotify (Linux) / FSEvents (macOS) / ReadDirectoryChangesW (Windows) | 高效，仅 Linux/macOS/Windows 原生 | -| cron 批处理 | `*/5 * * * *` | 简单，不实时，适合低频场景 | -| Webhook | Git post-commit hook | 适合 Git 管理的文档 | - -## Use Case in memsearch - -memsearch 的 `memsearch watch` 命令使用文件监视器自动追踪记忆目录变化： -```bash -memsearch watch ~/path/to/your/memory/ -# 持续监控，新增/修改文件自动触发增量索引 -``` - -## Benefits - -- **实时同步**：索引始终反映最新文档状态 -- **零手动操作**：无需人工干预，忘记索引更新也不怕 -- **节省成本**：基于 [[Content Hashing]] 的增量机制，仅处理实际变化部分 - -## Connections -- [[semantic-memory-search]] — 文件监视器是 memsearch 保持索引实时的核心功能 -- [[memsearch]] — memsearch 内置文件监视器实现 -- [[Content Hashing]] — 文件监视器的增量触发依赖内容哈希比对 diff --git a/wiki/concepts/FinOps.md b/wiki/concepts/FinOps.md deleted file mode 100644 index cfddcad6..00000000 --- a/wiki/concepts/FinOps.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "FinOps (Cloud Financial Management)" -type: concept -tags: - - AWS - - FinOps - - Cost-Optimization -aliases: - - FinOps - - 云财务管理 -last_updated: 2026-05-12 ---- - -## Overview - -FinOps（云财务管理）是一种云资源管理学科，通过可见性、优化和治理实现云投资最大化价值。核心目标是在云环境中建立成本意识文化，实现工程速度与财务问责制的平衡。 - -## Core Principles - -- **可见性**：确保所有云支出的可见性，按责任单元拆分 -- **优化**：持续优化资源使用，降低单位成本 -- **治理**：建立策略和控制，确保支出在预算内 - -## Key Practices - -- **Showback/Chargeback**：成本分摊机制，Showback 展示成本数据，Chargeback 强制成本归属 -- **Reserved Instances / Savings Plans**：承诺计划用于长期工作负载成本优化 -- **RightSizing**：根据实际使用情况调整实例规格 -- **Spot Instances**：可中断工作负载使用竞价实例降低 60-90% 成本 -- **Graviton ARM 实例**：相比 Intel x86 实例成本更低、能耗更低 - -## Related Pages - -- [[PCG Team]] -- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] -- [[ctp-topic-63-optimise-resource-cost-using-automation]] -- [[SpotInstances]] -- [[ReservedInstances]] -- [[SavingsPlans]] -- [[Graviton]] diff --git a/wiki/concepts/Fine-Tuning.md b/wiki/concepts/Fine-Tuning.md deleted file mode 100644 index 49184bd6..00000000 --- a/wiki/concepts/Fine-Tuning.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Fine-Tuning" -type: concept -tags: [AI, ML, fine-tuning, foundation-model, customization] -sources: [public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec] -last_updated: 2026-05-12 ---- - -## Aliases -- Fine-tuning -- Model Fine-tuning -- 模型的微调 - -## Definition -Fine-Tuning（微调）是在预训练基础模型之上，使用特定领域或任务的数据进一步训练模型，使其适应特定业务场景。与 RAG 不同，微调直接修改模型权重，而非在推理时注入外部知识。 - -## Key Facts -- 属于三大数据整合方法之一（RAG / Fine-tuning / Continued Pre-training） -- 与 RAG 的核心区别：RAG 保留原始模型权重，通过检索增强回答；Fine-tuning 修改模型权重，改变模型本身 -- 适用场景：特定领域术语、风格、任务类型的深度适配 -- 成本：需要额外的训练资源和时间 -- AWS Amazon Bedrock 支持 Fine-tuning 基础模型 - -## Comparison with RAG - -| 维度 | Fine-Tuning | RAG | -|------|-------------|-----| -| 修改模型权重 | 是 | 否 | -| 推理延迟 | 无额外延迟 | 有检索开销 | -| 外部知识库 | 不依赖 | 依赖 | -| 适用场景 | 风格/任务适配 | 知识密集型问答 | -| 成本 | 训练成本高 | 索引/检索成本 | - -## Related Concepts -- [[Foundation-Models]]：微调作用于基础模型 -- [[RAG]]：另一种数据整合方法，与微调互补 -- [[Amazon-Bedrock]]：提供 Fine-tuning 能力 - -## Sources -- [[public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec]] diff --git a/wiki/concepts/FirstPersonBusinessWriting.md b/wiki/concepts/FirstPersonBusinessWriting.md deleted file mode 100644 index c54db282..00000000 --- a/wiki/concepts/FirstPersonBusinessWriting.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "First-Person Business Writing" -type: concept -tags: ["writing", "authenticity", "business", "content"] -sources: ["marketing-book-co-author"] -last_updated: 2026-04-30 ---- - -## Definition - -第一人称商业写作（First-Person Business Writing）是一种以作者个人亲身经历、真实决策和教训为叙事主轴的商业内容形式。其核心特征是**真实性和个人立场优先于中立客观**，强调作者作为行业亲历者的独特价值。 - -## Core Distinction - -| 维度 | 第一人称商业写作 | 传统商业写作 | -|------|---------------|------------| -| 叙事主体 | "我"（作者亲历者） | "我们"/"你"/中性第三方 | -| 内容来源 | 个人决策、错误、教训 | 研究数据、行业报告 | -| 说服机制 | 信任+共鸣 | 逻辑+权威 | -| 典型场景 | 思想领导力书籍、创始人博客 | 白皮书、行业分析报告 | -| 独特性 | 不可复制（个人经历） | 可复制/可借鉴 | - -## Writing Rules - -1. **场景 > 抽象**：用具体场景开场，而非"在当今商业环境中……" -2. **决策 > 结论**：展示"我是怎么决策的"而非仅告诉读者"你应该这样做" -3. **错误 > 成功**：敢于分享失败和教训，而非只展示光鲜成功 -4. **立场 > 中立**：有明确观点，不为了面面俱到而稀释论点 -5. **节奏感**：模仿作者本人的口语节奏和思维模式 - -## In Ghostwriting Context - -在代笔写作中实现第一人称商业写作的挑战： -- AI 倾向于生成第三人称客观叙述 -- 需要从委托方的语音笔记/访谈中提取真实的个人语言模式 -- 避免在"润色"过程中抹平个人特色 -- 每个 claim 必须能追溯到委托方的真实经历或明确标记为假设 - -## Related Concepts -- [[Voice Protection]] — 第一人称商业写作的核心质量保证机制 -- [[Thought Leadership Book]] — 第一人称商业写作的典型应用场景 -- [[Narrative Architecture]] — 叙事架构服务于第一人称叙事 diff --git a/wiki/concepts/Five-Layer-Prompt-Structure.md b/wiki/concepts/Five-Layer-Prompt-Structure.md deleted file mode 100644 index e6f66510..00000000 --- a/wiki/concepts/Five-Layer-Prompt-Structure.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Five-Layer Prompt Structure" -type: concept -tags: [prompt-engineering, ai-image-generation, photography] -last_updated: 2026-05-15 ---- - -## Definition - -AI 图像生成提示词的五层结构化框架，通过分层叠加确保提示词完整覆盖主体、环境、光线、摄影技术和风格美学五大维度，最大限度降低 AI 误解空间。 - -## Structure - -1. **主体描述层（Subject Description Layer）**：主要被摄对象详细描述（人物/物体/场景）、属性/表情/姿态/材质纹理、主客体关系、尺度与比例 -2. **环境设定层（Environment & Setting Layer）**：位置类型（棚拍/户外/城市/自然）、环境细节与纹理、背景处理方式、大气条件 -3. **光线规范层（Lighting Specification Layer）**：光源类型（自然光/人工光）、光方向（Rembrandt/蝴蝶光/分割光等）、光质（硬光/软光/容积光）、色温 -4. **摄影技术层（Technical Photography Layer）**：相机视角（低/平/高/鸟瞰/虫视）、焦距效果（广角畸变/长焦压缩）、景深控制（浅/深/选择性）、曝光风格（高调/低调/HDR） -5. **风格美学层（Style & Aesthetic Layer）**：摄影类型（人像/时尚/商业/纪实/艺术）、时代风格、后处理风格、参考摄影师 - -## Key Principle - -- **精确性优先**：使用具体摄影术语（如 "f/1.8 bokeh 浅景深" 而非 "背景模糊"） -- **分层递进**：从主体到风格逐层构建，确保每层信息不遗漏 -- **技术-艺术平衡**：摄影技术参数与艺术方向并重 - -## Connections - -- [[Prompt-Engineering]] 的核心技术方法论 -- [[Photography-Terminology]] 的应用层框架 -- [[Midjourney]] / [[Stable-Diffusion]] / [[DALL-E]] / [[Flux]] 均适用此框架 - -## Aliases - -- Prompt Layering Framework -- Structured Prompt Framework -- 五层提示词结构 diff --git a/wiki/concepts/Five-Phase-Script-Framework.md b/wiki/concepts/Five-Phase-Script-Framework.md deleted file mode 100644 index abfe56c3..00000000 --- a/wiki/concepts/Five-Phase-Script-Framework.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: "Five-Phase Script Framework" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-26 ---- - -## Definition -五阶段话术框架——直播间单品讲解的标准化叙事结构，通过五阶段递进引导观众从「进入直播间」→「了解产品」→「建立信任」→「产生购买紧迫感」→「追加复购」，形成完整的销售闭环。 - -## Stages - -### Stage 1: 留人钩子（Retention Hook） -**目标**：让观众停止滑动，增加停留时长 -- 抛出痛点场景引发共鸣 -- 设置悬念或挑战激发好奇心 -- 使用互动指令要求观众参与（打字/点赞/关注） -- 参考话术："别划走！今天这个产品，上次我们一上架就秒空了……" - -### Stage 2: 产品介绍（Product Introduction） -**目标**：清晰传递产品核心价值 -- 展示产品实物（演示/试用/对比） -- 讲述品牌故事、成分、工艺等差异化信息 -- 穿插个人使用体验增加真实感 -- 参考话术："大家看（展示产品），这个 XX 和普通 XXX 最大的区别是……" - -### Stage 3: 信任建立（Trust Building） -**目标**：消除购买顾虑，建立可信度 -- 展示销售数据/用户评价/权威认证 -- 引用真实使用前后对比 -- 回答评论区常见问题 -- 参考话术："这不是我一个人在说，大家看（展示销量/评价/证书）……" - -### Stage 4: 紧迫成交（Urgency Close） -**目标**：促成立即下单决定 -- 价格锚点：先揭示零售价，再揭示直播专属价 -- 稀缺性：限量库存、限时优惠 -- 社会认同：实时播报已下单人数 -- 参考话术："零售价 XXX 元，但今天直播间——XXX 元！而且只有 XX 件库存！3、2、1，上链接！" - -### Stage 5: 追单挽留（Follow-Up Save） -**目标**：不流失已表达购买意愿但未成交的观众 -- 对已下单观众点名感谢，增强社群感 -- 尝试追加销售（加购/升级套餐） -- 预告下一款更大力度产品，留住未下单观众 -- 参考话术："已经抢到的朋友打'收到'，让我看到你们！还没拍的朋友……下一款更劲爆，留在直播间别走！" - -## Category-Specific Adaptations -| 品类 | Stage 1 重点 | Stage 3 重点 | -|------|-------------|-------------| -| 美妆/护肤 | 皮肤痛点共鸣 | 使用前后对比 | -| 食品/生鲜 | 试吃演示 | 产地/质检证明 | -| 服饰 | 上身效果 | 尺码/面料说明 | -| 家电/3C | 使用场景 | 参数对比/认证 | -| 家居 | 生活方式 | 材质/环保认证 | - -## Variations -- **5分钟单品节奏**：每个阶段约1分钟，总时长5分钟 -- **30分钟专题节奏**：每10分钟一个产品循环，含1-2次互动抽奖打断 -- **大场直播节奏**：引流款（Stage 1为主）→ 主推款（完整5阶段）→ 利润款（Stage 3-4为主）→ 秒杀款（Stage 4为主） - -## Connections -- [[Organic Traffic Amplification]] — 五阶段框架中 Stage 1 和 Stage 3 的互动数据直接驱动自然流量推荐 -- [[Host Incubation System]] — 主播熟练掌握五阶段框架是从「能播」到「能控节奏」的核心技能节点 -- [[Product Sequencing]] — 五阶段框架需根据产品角色（引流款/主推款/利润款）调整各阶段时间配比 -- [[Qianchuan Campaign]] — 五阶段脚本转化为付费投放的创意素材，是冷启期最重要的流量转化工具 - -## Sources -- [[marketing-livestream-commerce-coach]] diff --git a/wiki/concepts/FiveWhys.md b/wiki/concepts/FiveWhys.md deleted file mode 100644 index 83cb8fae..00000000 --- a/wiki/concepts/FiveWhys.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: "Five Whys" -type: concept -tags: [root-cause-analysis, incident-management, reliability] -last_updated: 2026-05-01 ---- - -## Definition -5 问法（Five Whys）是一种迭代式根因分析技术，通过连续追问"为什么"（Why）五层（或更多），穿透表面现象，找到系统性根本原因。最初由丰田汽车的大野耐一在精益制造中提出，现广泛应用于可靠性工程和事故管理。 - -## Core Method - -从观察到的**问题（症状）**开始，连续追问"为什么"，直到找到： -- 一个可采取行动的**根本原因**（root cause） -- 或一个**系统性缺口**（systemic gap） - -### 经典示例 - -> **问题**：网站宕机了。 - -| 层级 | 问法 | 回答 | -|------|------|------| -| 1 | 为什么网站宕机了？ | 应用服务器无响应 | -| 2 | 为什么服务器无响应？ | 数据库连接池耗尽 | -| 3 | 为什么连接池耗尽？ | 一个慢查询锁住了所有连接 | -| 4 | 为什么慢查询没有被检测？ | 没有查询超时限制和监控 | -| 5 | **为什么没有超时限制？** | 配置变更流程中没有强制要求 | - -> **根因**：配置变更流程缺少数据库安全门（超时限制验证） - -## Application in Incident Post-Mortem - -在 [[BlamelessPostMortem]] 中的 5 Why 使用： -1. **保持中立**：避免使用指责性语言 -2. **聚焦系统**：问"系统/流程允许了什么"而非"谁做错了" -3. **不止五层**：有时需要 6-7 层才能到达系统性根因 -4. **验证**：用 [[FaultTreeAnalysis]] 交叉验证 5 Why 结论 - -## Relationship with Fault Tree Analysis - -| 维度 | Five Whys | Fault Tree Analysis | -|------|-----------|---------------------| -| 方向 | 自下而上（症状→根因） | 自上而下（顶事件→叶事件） | -| 适用场景 | 已知单一事故 | 复杂、多因故障链 | -| 协作性 | 团队讨论式 | 结构化图形化 | -| 互补性 | 可结合使用：FTA 识别多因，5 Why 挖掘每个原因 | | - -## Key Principles - -### Do（应该做） -- 从具体可观察的事实开始 -- 每个回答都基于证据，而非假设 -- 继续追问直到找到**系统层面**的原因 -- 在团队环境中使用（多元视角更有效） - -### Don't（不应该做） -- 不停在第一个"合理"答案就停止 -- 归咎于个人（"因为某人操作失误"） -- 假设自动化可以解决所有问题 -- 不验证答案是否与数据一致 - -## Anti-Patterns - -| 错误 | 原因 | 修正 | -|------|------|------| -| "因为人员疏忽" | 永远指向根因，但无行动价值 | 追问：系统为什么允许疏忽发生？ | -| "需要更好的监控" | 泛泛而谈，缺乏可落地性 | 具体：哪种监控，触发什么行动？ | -| "因为云厂商问题" | 外部归因，无法控制 | 追问：为什么没有灾备方案？ | - -## Related Concepts -- [[BlamelessPostMortem]] — 5 Why 是无责复盘的核心根因分析工具 -- [[FaultTreeAnalysis]] — 可与 5 Why 互补使用的结构化分析 -- [[DORA-Metrics]] — 量化事故影响，为复盘提供数据支撑 - -## Sources -- [[engineering-incident-response-commander]] diff --git a/wiki/concepts/Fix-Pack.md b/wiki/concepts/Fix-Pack.md deleted file mode 100644 index d03f4322..00000000 --- a/wiki/concepts/Fix-Pack.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Fix Pack" -type: concept -tags: ["AEO", "GEO", "marketing", "action-plan"] -last_updated: 2026-04-26 ---- - -## Definition - -Fix Pack（修复包）是在 AI 引用审计后生成的优先级修复清单，包含具体的内容修改方案和每个修复项的预期引用改善幅度。是 AI Citation Strategist 的核心交付物之一。 - -## Structure - -### Header -```markdown -# Fix Pack: [Brand Name] -## Date: [YYYY-MM-DD] -``` - -### Priority Tiers - -**Priority 1 (P1) — 7 天内实施** -- 预期影响最大（+15-25% citation rate） -- 解决 3+ 个 Lost Prompts - -**Priority 2 (P2) — 14 天内实施** -- 预期影响中等（+10-15% citation rate） -- 解决 2-3 个 Lost Prompts - -**Priority 3 (P3) — 30 天内实施** -- 预期影响较小（+5-10% citation rate） -- 解决 1-2 个 Lost Prompts - -### Fix Item Template - -```markdown -### Fix N: [Fix Title] -- **Target prompts**: X 个相关 Lost Prompts -- **Expected impact**: +X-Y% citation rate on [query type] -- **Implementation**: - - [具体步骤 1] - - [具体步骤 2] - - [具体步骤 3] -``` - -## Prioritization Rule - -**按预期影响排序，而非按实施难易度排序。** - -- 错误做法：先做容易的（改标题、优化元描述），再做难的（新建对比页） -- 正确做法：先做影响最大的（Schema markup、FAQ 页），再做影响较小的 - -## Related Concepts - -- [[Citation Rate]]：Fix Pack 的效果衡量指标 -- [[Lost Prompt Analysis]]：识别需要 Fix 的查询场景 -- [[Answer Engine Optimization (AEO)]]：Fix Pack 修复所依据的策略框架 - -## Sources - -- [[AI Citation Strategist]] diff --git a/wiki/concepts/Fixed-Point-Semantics.md b/wiki/concepts/Fixed-Point-Semantics.md deleted file mode 100644 index 7099747a..00000000 --- a/wiki/concepts/Fixed-Point-Semantics.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Fixed-Point Semantics" -type: concept -tags: [] ---- - -## Definition -不动点语义是递归自我优化系统的收敛理论基础。稳定生成能力被定义为自映射 $\Phi: \mathcal{G} \to \mathcal{G}$ 的不动点 $G^* \in \mathcal{G}$，满足： -$$\Phi(G^*) = G^*$$ - -即：在经历一次完整的"生成-优化-更新"循环后，生成器保持不变——它已经与自身的能力上限达成一致。 - -## Existence & Convergence -不动点的存在性由 Banach 不动点定理保证：当 $\Phi$ 是收缩映射（contraction mapping）时，不动点存在且唯一，并且可以通过迭代获得： -$$G^* = \lim_{n \to \infty} \Phi^n(G_0)$$ - -这意味着：**即使初始生成器 $G_0$ 很简单，通过足够多的迭代，生成器序列将收敛到稳定状态**。 - -## Significance -不动点代表了一个生成器，其输出已经包含改进自身所需的全部信息——它不再需要外部优化器的干预。同时，不动点的存在证明了系统不会陷入无限循环或发散。 - -## Sources -- [[a-formalization-of-recursive-self-optimizing-generative-systems]] - -## Connections -- [[Recursive Self-Optimization]] ← converges_to ← [[Fixed-Point Semantics]] -- [[Self-Referential Computation]] ← is_grounded_in ← [[Fixed-Point Semantics]] -- [[Y-Combinator]] ← computes ← [[Fixed-Point Semantics]] diff --git a/wiki/concepts/Flash-Loan-Attack.md b/wiki/concepts/Flash-Loan-Attack.md deleted file mode 100644 index 299183f3..00000000 --- a/wiki/concepts/Flash-Loan-Attack.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: "Flash Loan Attack（闪电贷攻击）" -type: concept -tags: [blockchain, security, defi, flash-loan, attack] -sources: [blockchain-security-auditor] -last_updated: 2026-05-30 ---- - -## Aliases -- Flash Loan Attack -- 闪电贷攻击 -- Flash Loan Exploit - -## Definition - -闪电贷攻击（Flash Loan Attack）是 DeFi 领域最具破坏力的大规模攻击手段。攻击者在**单笔交易内**借用大量资金（无需抵押），利用这些临时资金操纵市场状态、执行套利或攻击协议，然后在交易结束时归还本金。攻击成本仅为 gas 费用，风险为零。 - -## Attack Pattern - -``` -T0: 攻击合约从 Aave/Uniswap 闪电贷 100M DAI -T1: 用借来的 DAI 操纵目标协议的预言机价格 -T2: 以操纵后的价格执行有利交易（借款/清算/套利） -T3: 归还闪电贷本金 + 手续费 -T4: 剩余利润归攻击者所有 -``` - -## Common Variants - -### Oracle Manipulation via Flash Loan -- 通过闪电贷操纵 AMM 储备金，人为扭曲现货价格 -- 以虚高抵押率借贷后直接清算协议 -- Uniswap V2 现货价格最易操纵，V3 TWAP 和 Chainlink 更安全 - -### Donate-to-Reserves Attack（Euler Finance 模式） -- 通过闪电贷操纵内部账户账簿的资产净值 -- 在单笔交易内完成 donate → 触发健康度检查 → 清算套利 - -### Governance Attack via Flash Loan -- 闪电贷借入大量治理代币 -- 在快照前买入、投票、快照后卖出 -- 2022 年 Rari Capital 被此方式攻击 - -## Key Characteristics - -- **零成本**：借款无需抵押，只付 gas 费 -- **单笔交易**：所有操作必须在同一区块内完成 -- **EVM 原子性**：交易全成功或全回滚 - -## Audit Focus - -1. 在闪电贷场景下，协议状态是否可以被操纵？ -2. 价格/余额/股份计算是否依赖可被操纵的输入？ -3. 是否存在仅在极端条件下才成立的"不变性"？ -4. 闪电贷还款前后的状态一致性是否被验证？ - -## Defense - -- 使用 TWAP 而非现货价格 -- 使用 Chainlink 等抗操纵的链下预言机 -- 设置最小时间窗口（2-3 区块）后才允许清算 -- 不变性验证（Flash Loan 前后的不变性必须成立） - -## Connections -- [[Oracle Manipulation]] ← 主要载体 ← [[Flash Loan Attack]] -- [[Blockchain-Security-Auditor]] ← analyzes ← [[Flash Loan Attack]] -- [[Euler-Finance]] ← victim ← [[Flash Loan Attack]] diff --git a/wiki/concepts/FlashLoanAttack.md b/wiki/concepts/FlashLoanAttack.md deleted file mode 100644 index 92a756a7..00000000 --- a/wiki/concepts/FlashLoanAttack.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "FlashLoanAttack" -type: concept -tags: [] -last_updated: 2026-05-01 ---- - -## Definition -Flash Loan（闪电贷）是 DeFi 中的一种无抵押借贷模式，允许用户在单笔交易内借入任意数量的资产，条件是在同一交易的结尾必须归还借款 + 利息。Flash Loan Attack（闪电贷攻击）则是利用闪电贷的特性，在单笔交易中操纵价格、状态或协议逻辑来获取非法收益的攻击方式。 - -## How Flash Loans Work -```solidity -// 用户通过闪电贷借出 1000 ETH -// 在同一交易内：执行各种操作（交易、借贷、套利） -// 必须归还 1000 ETH + 手续费，否则整笔交易 revert -``` - -关键特性：**无需抵押**（因为资金在同一交易内流转），但这也意味着**协议无法在交易中途检查清算状态**。 - -## Attack Patterns - -### 1. 价格操纵（Price Manipulation） -- 在借贷协议中：先借出大量资产 → 操纵预言机价格 → 以超低抵押率借出更多资产 → 归还闪电贷 -- 案例：[[Euler Finance]]（2023）、Cream Finance（多次） - -### 2. 治理攻击（Governance Attack） -- 通过闪电贷获得大量治理代币 -- 在单笔交易内发起并通过恶意提案 -- 案例：Beanstalk（2022） - -### 3. 重入攻击（通过闪电贷） -- 与 reentrancy 结合，放大攻击规模 - -## Defense Mechanisms -1. **TWAP（时间加权平均价格）预言机**：使用时间窗口内的平均价格，而非即时价格 -2. **借贷健康度实时检查**：在每笔清算操作前验证抵押率 -3. **闪电贷攻击监控**：链上监控异常大额闪电贷 + 后续清算模式 -4. **最小清算门槛**：设置合理的清算参数，防止微小偏差导致清算 - -## Sources -- [[engineering-solidity-smart-contract-engineer]] -- [[Euler-Finance]] -- [[blockchain-security-auditor]] diff --git a/wiki/concepts/Flow-And-Readability.md b/wiki/concepts/Flow-And-Readability.md deleted file mode 100644 index fe63604a..00000000 --- a/wiki/concepts/Flow-And-Readability.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Flow And Readability" -type: concept -tags: [] -last_updated: 2026-04-26 ---- - -## Definition - -关卡流与可读性（Flow And Readability）是游戏关卡设计的核心原则，指玩家在空间中移动时体验到的流畅程度与方向清晰度。**Flow** 强调空间节奏与玩家动线的无缝衔接；**Readability** 强调关卡信息（路径、目标、敌人）的视觉传达是否清晰。 - -## Core Principles - -### Critical Path Legibility -- 关键路径必须始终视觉可读——玩家应永远不迷路，除非迷路是刻意设计的 -- 用光照、色彩和几何引导注意力——绝不能将小地图作为主要导航工具 -- 每个路口必须提供清晰的主动路径和可选的次级奖励路径 -- 门、出口和目标必须与环境形成对比 - -### Spatial Flow Control -- 空间节奏控制张力曲线：紧张（Tension）→ 释放（Release）→ 探索（Exploration）→ 战斗（Combat） -- 走廊是句子，房间是段落，关卡是完整的论证 -- 出口在进入房间后 3 秒内必须可见 -- 关键路径比可选路径光照更亮 - -### Navigation Affordance -- 可选区域用独特光照或色彩标记（诱惑设计：奖励在岔路口可见） -- 路口不能有导航歧义 -- 没有看起来像出口的死胡同 - -## Related Concepts -- [[Encounter Design]]：在 Flow 的框架内安放战斗节点 -- [[Environmental Storytelling]]：Flow 路径上每个空间都有叙事功能 -- [[Pacing Architecture]]：Flow 是 Pacing 的空间实现 - -## Sources -- [[Level Designer Agent Personality]] diff --git a/wiki/concepts/FluentBit.md b/wiki/concepts/FluentBit.md deleted file mode 100644 index 6cc9e935..00000000 --- a/wiki/concepts/FluentBit.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Fluent Bit" -type: concept -tags: [AWS, EKS, logging, monitoring, CNCF, Fluentd] -last_updated: 2026-04-28 ---- - -## Definition - -Fluent Bit（CNFC 开源项目）是轻量级日志处理器和转发器，设计用于边缘和容器环境，作为 DaemonSet 部署在每个 Kubernetes 节点上。它从容器运行时（containerd/Docker）收集标准输出（stdout/stderr）日志，处理后转发到 CloudWatch Logs、OpenSearch、Elasticsearch 等后端存储系统，是 EKS 可观测性架构中日志采集的标准组件。 - -## Key Mechanisms - -- **日志采集**：通过容器运行时接口收集容器标准输出日志 -- **多后端输出**：支持 CloudWatch Logs、OpenSearch、Elasticsearch、Kafka 等多种输出目标 -- **日志处理**：支持过滤（filter）、解析（parser）、路由（router）等处理管道 -- **轻量高效**：相比 Fluentd 更小的资源占用，适合边缘/容器环境 -- **Kubernetes DaemonSet 模式**：每个节点运行一个实例，自动采集所有容器日志 - -## Relationship with Fluentd and CloudWatch Agent - -Fluent Bit 是 Fluentd 的轻量替代（同一项目家族）： -- Fluentd：功能更全面，适合复杂日志处理场景，资源占用更高 -- Fluent Bit：轻量快速，专为边缘和容器优化 -- CloudWatch Agent：侧重指标收集，Fluent Bit 侧重日志收集 -- 在 EKS 监控栈中：Fluent Bit → CloudWatch Logs/OpenSearch → Grafana/OpenSearch Dashboards - -## Sources -- [[ctp-topic-70-eks-deployment-using-iac]] -- [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]] -- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] diff --git a/wiki/concepts/Food-Sensitivity-Tracking.md b/wiki/concepts/Food-Sensitivity-Tracking.md deleted file mode 100644 index 3751cb09..00000000 --- a/wiki/concepts/Food-Sensitivity-Tracking.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Food Sensitivity Tracking" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-22 ---- - -# Food Sensitivity Tracking - -通过长期日志追踪来识别个人食物不耐受或过敏的实践方法。 - -## Definition -记录食物摄入与身体症状（如头痛、腹胀、皮疹等）的时间关联，通过模式分析发现潜在的触发食物。 - -## How It Works -1. **日志记录**：在摄入食物或出现症状时即时记录，带时间戳 -2. **一致性保证**：定时提醒确保不遗漏，建立长期数据积累 -3. **周期性分析**：每周或每月回顾日志，识别统计相关性 -4. **迭代验证**：排除疑似触发食物，观察症状变化以确认 - -## Key Insight -> "Identifying food sensitivities requires consistent logging over time, which is tedious to maintain." — 这是自动化的核心驱动力 - -## Implementation Patterns -- [[health-symptom-tracker]]：Telegram 话题 + OpenClaw 自动解析 + Markdown 日志 -- 移动端 App（如 Cara、Spoonful）作为专用替代方案 - -## Connections -- [[Automated Health Logging]] ← enables ← [[Food Sensitivity Tracking]] -- [[Cron Job Reminders]] ← supports ← [[Food Sensitivity Tracking]] diff --git a/wiki/concepts/Formal-Verification.md b/wiki/concepts/Formal-Verification.md deleted file mode 100644 index c08551d8..00000000 --- a/wiki/concepts/Formal-Verification.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "Formal Verification（形式化验证）" -type: concept -tags: [blockchain, security, smart-contract, formal-verification] -sources: [blockchain-security-auditor] -last_updated: 2026-05-30 ---- - -## Aliases -- Formal Verification -- 形式化验证 - -## Definition - -形式化验证（Formal Verification）是通过数学方法严格证明智能合约关键属性正确性的技术手段。与测试只能穷举有限场景不同，形式化验证可以证明某个属性在**所有可能的输入和状态**下均成立。 - -## Core Methods - -### Invariant Specification（不变式规范） -定义协议的关键属性，用数学语言表达"协议必须始终保持的真理"： -- 总份额 × 每股净值 = 总资产（份额不变性） -- 借贷后抵押率必须 ≥ 清算阈值（健康度不变性） -- 管理员无法直接提取用户资金（权限不变性） - -### Symbolic Execution（符号执行） -将合约函数参数替换为符号变量而非具体值，遍历所有可能的执行路径： -- 发现边界条件和组合触发场景 -- Certora Prover、KEVM、Mythril 使用此方法 - -### Equivalence Checking（等价性检验） -验证合约实现与形式化规范是否等价： -- 高风险升级前后必须进行 -- 防止修复一个漏洞引入另一个 - -## Key Tools - -| Tool | Method | Focus | -|------|--------|-------| -| [[Certora]] | 符号执行 | Solidity 合约属性证明 | -| [[Halmos]] | 字节码符号执行 | 字节码级别验证（不依赖源码） | -| KEVM | 形式化 EVM | EVM 操作语义形式化模型 | -| Medusa | 符号执行 | 并行化模糊测试 | - -## Relationship to Audit - -- 形式化验证是 **Slither/Mythril/Echidna 等工具的补充**，不是替代 -- 高风险协议（> $10M TVL）在审计报告中通常包含形式化验证章节 -- 形式化验证的局限性：无法验证的需求规范错误、依赖外部状态 - -## Connections -- [[Blockchain-Security-Auditor]] ← uses methodology ← [[Formal Verification]] -- [[Slither]] ← lower-level analysis ← [[Formal Verification]] -- [[Echidna]] ← property-based testing ← [[Formal Verification]] diff --git a/wiki/concepts/Foundation-AMI.md b/wiki/concepts/Foundation-AMI.md deleted file mode 100644 index 74104676..00000000 --- a/wiki/concepts/Foundation-AMI.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Foundation AMI" -type: concept -tags: - - AWS - - AMI - - Security - - Cloud -sources: [] -last_updated: 2026-05-07 ---- - -## Foundation AMI - -经过安全加固、集成标准组件并预配置好的操作系统模板，是 Micro Focus 云环境的标准化基础镜像。 - -## Definition - -Foundation AMI 是基于市场主流操作系统（如 CentOS, Ubuntu, Windows 等）进行深度加固的镜像，集成了： - -- [[CIS-Benchmark]] 安全基准：遵循互联网安全中心制定的安全配置基准 -- **McAfee EPO**：企业级防病毒软件 -- **Syslog-ng**：日志管理 -- **AD 单点登录**：Active Directory 集成认证 -- [[AWS-SSM]]：AWS 系统管理器代理，用于远程管理、自动化补丁更新和配置同步 -- **SiteScope**：监控预选件 - -## Build Automation - -通过 [[HashiCorp]] Packer + [[Jenkins]] 流水线实现镜像创建完全自动化： -- Packer 负责从单一源配置自动创建一致的机器镜像 -- Jenkins 流水线管理构建、测试和发布流程 - -## Distribution - -通过跨账号共享（AMI Sharing）分发至全球多区域（俄勒冈/法兰克福/悉尼等），而非物理复制（AMI Copying），避免额外存储成本。 - -## Update Policy - -- 更新频率：每两个月更新一次 -- 版本保留策略：N-2（保留当前及前两个版本） -- 通知机制：通过 CCOE 门户订阅 AMI 更新通知 - -## Relationship with Product-Specific AMI - -Foundation AMI 是基础层，产品团队在其之上构建"产品特定 AMI"（Product-Specific AMI），以满足各自应用的特殊需求，并负责其后续的生命周期管理。 - -## Aliases -- CCOE AMI -- Golden AMI -- Base AMI - -## Sources -- [[ctp-topic-26-standard-ami-build-publish-share-processes]] — Foundation AMI 全生命周期管理详解 -- [[ctp-topic-50-ami-roadmap-for-aws-amis]] — AMI 路线图中 Foundation AMI 的定义 diff --git a/wiki/concepts/Foundation-Models.md b/wiki/concepts/Foundation-Models.md deleted file mode 100644 index 8fcb35e9..00000000 --- a/wiki/concepts/Foundation-Models.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Foundation Models" -type: concept -tags: [AI, ML, foundation-model, generative-AI, LLM] -sources: - - public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin - - public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec -last_updated: 2026-05-12 ---- - -## Definition -Foundation Models（基础模型）是拥有数十亿参数的大规模预训练模型，是生成式 AI 的核心驱动力。Amazon 认为大多数客户体验和应用将被生成式 AI 重塑，而生成式 AI 的力量来自于基础模型。 - -## Key Properties -- **规模**: 数十亿参数（billions of parameters） -- **预训练**: 在大规模通用数据上预训练 -- **可定制**: 支持微调（Fine-tuning）、持续预训练、RAG 等数据定制技术 -- **多模态**: 可处理文本、图像、代码等多种模态 - -## Related Concepts -- [[Generative-AI]]：基础模型是生成式 AI 的核心技术 -- [[RAG]]：检索增强生成，用于在基础模型上整合私有数据 -- [[Amazon-Bedrock]]：提供基础模型访问的全托管服务 -- [[Amazon-Titan]]：Amazon 开发的基础模型系列 - -## Examples -- Amazon Titan（Amazon Bedrock 内置） -- Anthropic Claude -- Meta Llama -- OpenAI GPT 系列 - -## Sources -- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] diff --git a/wiki/concepts/Frequency-Cap.md b/wiki/concepts/Frequency-Cap.md deleted file mode 100644 index 5e36caec..00000000 --- a/wiki/concepts/Frequency-Cap.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Frequency Cap" -type: concept -tags: ["frequency-cap", "display", "paid-media", "optimization", "brand-safety"] -sources: ["paid-media-programmatic-buyer"] -last_updated: 2026-04-26 ---- - -## Definition - -频次上限（Frequency Cap）是一种广告投放控制机制，限制同一用户在特定时间段内看到同一广告或广告活动的次数。其目的是在最大化品牌触达的同时，防止用户因过度曝光而产生广告疲劳（Ad Fatigue）或负面品牌联想。 - -## Why Frequency Cap Matters - -- **防止广告疲劳**：过度曝光同一创意会导致用户产生逆反心理，降低点击率和转化意愿 -- **预算效率**：避免对已转化用户重复投放浪费预算 -- **品牌保护**：过度曝光可能引发用户对品牌的负面情绪 -- **Reach vs. Frequency 平衡**：频次过高会牺牲独立触达人数 - -## Setting Frequency Caps - -### Industry Benchmarks - -| 活动类型 | 推荐频次 | 周期 | -|---------|---------|------| -| Brand Awareness（品牌认知） | 5-10 次/周 | 周 | -| Consideration（考虑阶段） | 3-7 次/周 | 周 | -| Retargeting（再营销） | 7-14 次/周 | 周 | -| DR / Performance（直接响应） | 1-3 次/天 | 天 | - -### Optimization Principles - -- **跨平台协调**：在 GDN、DSP、社交平台之间协调频次，避免总体超量 -- **Creative Rotation**：高频位置需要更多创意变体以防止疲劳 -- **Window Optimization**：根据转化路径调整归因窗口和频次窗口 -- **Audience Segmentation**：不同受众分层设置不同频次上限 - -## Frequency Pacing Models - -- **Even Pacing**：预算平均分配到活动周期，保持稳定频次 -- **Front-loaded**：前期集中投放，快速达到目标频次 -- **Decaying**：随时间递减频次，配合创意新鲜度 - -## Cross-Platform Frequency Management - -多平台同时投放时，必须通过[[Cross-Platform Reach and Frequency]]管理避免受众重叠浪费： -- 使用共同的受众识别码（Cookie、Device ID、CRM ID） -- 在投放前计算预期总频次，设定平台间协调的频次上限 -- 利用[[Audience Overlap Analysis]]识别和排除重叠受众 - -## Sources -- [[paid-media-programmatic-buyer]] diff --git a/wiki/concepts/Fstab.md b/wiki/concepts/Fstab.md deleted file mode 100644 index 43e0cb83..00000000 --- a/wiki/concepts/Fstab.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Fstab" -type: concept -tags: [linux, mount, filesystem, startup, nfs] -date: 2026-04-28 ---- - -# Fstab - -## Aliases -- /etc/fstab -- fstab -- 文件系统表 - -## Definition -`/etc/fstab`（Filesystem Table）是 Linux 系统中定义文件系统挂载关系的配置文件，每行描述一个文件系统（设备/UUID/标签、网络挂载等）及其挂载参数，系统启动时通过 `mount -a` 读取并自动挂载所有条目。相比手动 `mount` 命令，fstab 配置的挂载在重启后自动生效，是实现永久挂载的标准方法。 - -## Format -``` -<设备/UUID/标签> <挂载点> <文件系统类型> <选项> -``` - -## Example: NFS 永久挂载 -``` -192.168.3.17:/volume2/backup /mnt/nas_backup nfs defaults,timeo=900,retrans=5,_netdev 0 0 -``` - -## Key Parameters for NFS Mount -| 参数 | 说明 | -|------|------| -| `defaults` | 使用默认挂载选项（rw, suid, dev, exec, auto, nouser, async） | -| `timeo=900` | 超时时间 90 秒（单位 1/10 秒），NFS 网络延迟大时需要增大 | -| `retrans=5` | 超时后重试 5 次 | -| `_netdev` | **关键参数**：通知系统这是网络设备，等待网络服务就绪后再挂载，防止开机卡死 | -| `bg` | 挂载失败时放入后台，避免阻塞启动进程 | - -## Critical Safety Rule -> **修改 fstab 后，禁止直接重启！** 必须先用 `sudo mount -a` 验证配置正确性。如果 fstab 写错导致挂载失败，系统可能无法正常启动。 - -## Verification Workflow -```bash -# 1. 卸载当前挂载（如有） -sudo umount /mnt/nas_backup - -# 2. 模拟开机自动挂载 -sudo mount -a - -# 3. 检查挂载是否成功 -df -h | grep nas_backup -``` - -## Related Concepts -- [[永久挂载]] — fstab 是实现永久挂载的核心配置文件 -- [[挂载点检查]] — 备份脚本需检查 fstab 配置的挂载点是否生效 -- [[NFS]] — NFS 挂载必须通过 fstab 才能在重启后持久化 -- [[rsync]] — rsync 备份前应确认 fstab 挂载点就绪 - -## Related Sources -- [[ubuntu服务器通过rsync实现日常增量备份]] — fstab NFS 挂载配置的实际应用 -- [[如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹]] — fstab 配置详细说明 diff --git a/wiki/concepts/Full-Draft-Generation.md b/wiki/concepts/Full-Draft-Generation.md deleted file mode 100644 index 6cd12ad5..00000000 --- a/wiki/concepts/Full-Draft-Generation.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Full Draft Generation" -type: concept -tags: [openclaw, productivity, content-automation] -sources: [custom-morning-brief] -last_updated: 2026-04-22 ---- - -## Definition - -完整草稿生成（Full Draft Generation）是一种 AI 内容创作范式——AI 不是仅提供标题或概要，而是生成可直接使用的完整内容成品（脚本、邮件、商业方案等），用户醒来后无需再从零开始。 - -## Why "Full Draft" Matters - -传统 AI 助手通常生成： -- ❌ 标题列表（"5 个标题供选择"） -- ❌ 概要要点（"要点如下：..."） -- ❌ 半成品框架（"你可以这样写..."） - -Full Draft 模式生成： -- ✅ 完整脚本/大纲 → 拿来就用 -- ✅ 完整邮件正文 → 直接发送 -- ✅ 完整商业方案 → 提交即用 - -## Key Insight - -> "Full drafts (not just ideas) are the key to saving time. Wake up to scripts, not suggestions." — 自定义晨间简报的核心差异化价值 - -## Typical Workflow - -1. **睡前**：用户通过 Telegram 发送创作需求 -2. **夜间**：OpenClaw 在后台生成完整内容 -3. **晨起**：用户收到可直接使用的成品 - -## Use Cases - -- **[[custom-morning-brief]]**：睡前生成完整演讲脚本/视频大纲/邮件草稿 -- **[[podcast-production-pipeline]]**：生成播客脚本和社媒推广包 - -## Trade-off - -Full Draft 比概要生成： -- **优势**：节省用户时间，交付物价值更高 -- **劣势**：计算成本更高，生成时间更长 -- **适合**：高频、固定格式、有明确使用场景的内容 - -## Related Concepts - -- [[Scheduled Task Flywheel]] — Full Draft 生成的时间调度机制 -- [[Proactive Agent Recommendation]] — Full Draft 作为主动推荐的具体输出形式 diff --git a/wiki/concepts/Full-Funnel-Campaign-Architecture.md b/wiki/concepts/Full-Funnel-Campaign-Architecture.md deleted file mode 100644 index 1bdf260c..00000000 --- a/wiki/concepts/Full-Funnel-Campaign-Architecture.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Full-Funnel Campaign Architecture" -type: concept -tags: ["paid-media", "campaign-structure", "strategy"] -last_updated: 2026-04-25 ---- - -## Aliases -- Full-Funnel Structure -- 全漏斗广告架构 - -## Overview -全漏斗广告架构是一种将付费广告活动按用户购买旅程阶段分层组织的策略框架。[[Paid Media Paid Social Strategist]] Agent 将其定义为"引流（Prospecting）→ 互动（Engagement）→ 再营销（Retargeting）→ 留存（Retention）"四个阶段。 - -## Definition -每个漏斗阶段对应不同的受众策略、创意形式和预算分配： -- **Prospecting（引流）**：触达新受众，目标为扩大品牌/产品认知，频次目标 1.5-2.5/7天 -- **Engagement（互动）**：触达已看过广告的受众，促进深度互动（视频观看、页面浏览），频次目标 2-4/7天 -- **Retargeting（再营销）**：触达高意图受众（加购、结账放弃），推动转化，频次目标 3-5/7天 -- **Retention（留存）**：触达已有客户，推动复购和客户生命周期价值最大化 - -## Connections -- 依赖 [[Custom Audience Engineering]] 构建各阶段受众 -- [[Audience Overlap Analysis]] 防止阶段间受众重复触达 -- [[Paid Media Paid Social Strategist]] Agent 的核心方法论 diff --git a/wiki/concepts/FullDraftGeneration.md b/wiki/concepts/FullDraftGeneration.md deleted file mode 100644 index 5ee0ec6d..00000000 --- a/wiki/concepts/FullDraftGeneration.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "FullDraftGeneration" -type: concept -tags: [] ---- - -## Definition -AI 生成可直接使用的完整内容（脚本、邮件、商业方案等），而非仅提供标题、想法或大纲摘要的工作模式。 - -## Aliases -- 完整草稿生成 -- End-to-End Drafting -- Ready-to-Use Output - -## Key Characteristics -- **完整性（Completeness）**：输出即成品，可直接消费或微调后使用 -- **可执行性（Actionability）**：草稿可直接用于执行（发送邮件、上传视频、提交方案） -- **时间节省（Time Saving）**：用户醒来面对的是成品，而非"还需要我加工的半成品" - -## Why It Matters -[[custom-morning-brief]] 明确指出："Full drafts (not just ideas) are the key to saving time. Wake up to scripts, not suggestions." - -在晨间简报场景中，"内容创意想法"不如"完整脚本大纲"有价值——想法还需要用户花时间展开，草稿则可直接使用。 - -## Examples -- 完整 YouTube 视频脚本（而非标题列表） -- 完整商业提案框架（而非"可以考虑做 X"） -- 完整邮件草稿（而非邮件主题建议） -- 完整社交媒体帖子（而非帖子主题） - -## Related Concepts -- [[ProactiveAI]]：主动生成草稿背后的驱动理念 -- [[ContentAutomation]]：完整草稿是内容自动化链条的最终产出 diff --git a/wiki/concepts/Functionalism.md b/wiki/concepts/Functionalism.md deleted file mode 100644 index 39698db4..00000000 --- a/wiki/concepts/Functionalism.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Functionalism" -type: concept -tags: ["anthropology", "functionalism", "malinowski", "durheim", "social-cohesion"] -last_updated: 2026-04-25 ---- - -## Definition -功能主义——文化的每个元素都服务于满足人类**基本需求**（生理、社会、安全、认同）或维持**社会凝聚力**的分析框架。 - -## Core Framework -- **基本需求满足**：生理需求→经济系统、繁殖需求→亲属制度、安全需求→法律/防御、教育需求→文化传承 -- **社会凝聚力**：宗教、仪式、道德规范通过强化集体意识（collective consciousness）维持社会团结（Durkheim） -- **文化适应**：文化实践是种群适应环境的工具（Malinowski） - -## Key Thinkers -- [[Bronislaw-Malinowski]]（功能主义创始人） -- Emile Durkheim（社会凝聚力理论） -- A.R. Radcliffe-Brown（结构功能主义） - -## Connections -- [[Anthropologist-Agent]] ← uses_framework ← [[Functionalism]] -- [[Gift-Economy]] ← extends ← [[Functionalism]] -- [[Practice-Theory]] ← critiques ← [[Functionalism]] -- [[Structuralism]] ← challenges ← [[Functionalism]] diff --git a/wiki/concepts/Fuzzy-Matching.md b/wiki/concepts/Fuzzy-Matching.md deleted file mode 100644 index 607b5245..00000000 --- a/wiki/concepts/Fuzzy-Matching.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "Fuzzy Matching" -type: concept -tags: ["identity-resolution", "string-similarity", "normalization", "entity-matching"] -sources: ["identity-graph-operator"] -last_updated: 2026-04-25 ---- - -# Fuzzy Matching（模糊匹配） - -## Definition -处理"相同实体但文本表达不同"记录的能力——通过规范化（Normalization）和相似度算法，将表面不同的记录识别为同一实体。是身份解析的核心挑战之一。 - -## Core Techniques - -### 1. Nickname Normalization -```python -nicknames = { - "bill": "william", "bob": "robert", "jim": "james", - "mike": "michael", "dave": "david", "joe": "joseph", - "tom": "thomas", "dick": "richard", "jack": "john", -} -# "Bill Smith" → "william smith" -``` - -### 2. String Similarity -| 算法 | 适用场景 | -|------|----------| -| Levenshtein Distance | 字符级编辑距离 | -| Jaro-Winkler | 人名高权重前缀匹配 | -| Soundex / Metaphone | 语音相似性（"Jon" = "John"） | -| Token-based（TF-IDF） | 多词短语 | - -### 3. Field-specific Normalization -| 字段类型 | 规范化规则 | -|----------|------------| -| Email | `lower().strip()` | -| Phone | `re.sub(r"[^\d+]", "", value)` → E.164 格式 | -| Name | Nickname expansion + lowercase | -| Address | Street abbreviation（St→Street）、directionals（NE→Northeast） | - -## Example -``` -记录A: "Bill Smith", wsmith@acme.com, +1-555-0142 -记录B: "William Smith", wsmith@acme.com, +15550142 - ↓ Normalize + Score -Email: 1.0（exact match） -Name: 0.82（Bill→William nickname expansion） -Phone: 1.0（E.164 normalized） -──────────────────────────────── -Total: 0.94 confidence → 触发自动 merge（> 0.95 阈值接近） -``` - -## Relationship to Related Concepts -- [[Fuzzy-Matching]] 是 [[Identity-Resolution]] scoring 层的核心技术 -- [[Blocking]] 筛选候选对后，[[Fuzzy-Matching]] 执行细粒度字段比较 -- [[Confidence-Score]] 综合所有字段的 fuzzy match scores 得出最终决策 diff --git a/wiki/concepts/GAAP-Compliance.md b/wiki/concepts/GAAP-Compliance.md deleted file mode 100644 index 67cdf695..00000000 --- a/wiki/concepts/GAAP-Compliance.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "GAAP Compliance" -type: concept -tags: [finance, accounting, compliance] -sources: [finance-bookkeeper-controller] -last_updated: 2026-05-02 ---- - -## Definition -GAAP（Generally Accepted Accounting Principles，通用会计准则）是一套用于编制财务报表的公认会计原则和标准。GAAP 合规确保财务信息的一致性、可比性和透明度。 - -## Core Principle -> "GAAP compliance is the baseline. Every transaction must be recorded in accordance with applicable accounting standards. No exceptions, no shortcuts." -> — Dana, Bookkeeper & Controller Agent - -## Key Standards - -### ASC 606 — Revenue Recognition -- 合同审查与识别 -- 履约义务（Performance Obligations）识别 -- 交易价格分配 -- 收入确认时点判断 -- 合同变更处理 -- 递延收入管理 - -### ASC 842 — Lease Accounting -- 租赁分类（融资租赁 vs 经营租赁） -- 使用权资产（ROU Asset）和租赁负债计算 -- 租赁变更的重新计量 -- 短期租赁豁免 - -### ASC 718 — Stock-Based Compensation -- 期权估值 -- 费用确认时点 -- 修改会计处理 - -### ASC 805 — Business Combinations -- 购买价格分配（PPA） -- 商誉计算 -- 或有对价公允价值 - -## Compliance Requirements -- 所有交易必须按适用会计准则记录 -- 前期调整必须披露 -- 重大事项必须单独确认 -- 财务报告必须附有附注说明 - -## Related Concepts -- [[Revenue Recognition ASC606]] -- [[Month-End-Close-Process]] -- [[Journal Entry]] -- [[Audit Readiness]] diff --git a/wiki/concepts/GAS-Gameplay-Ability-System.md b/wiki/concepts/GAS-Gameplay-Ability-System.md deleted file mode 100644 index 219035fd..00000000 --- a/wiki/concepts/GAS-Gameplay-Ability-System.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: GAS Gameplay Ability System -type: concept -tags: [unreal-engine, networking, multiplayer, ue5, abilities] -sources: -last_updated: 2026-04-26 ---- - - -## Additional Sources -Gameplay Ability System（GAS）是 UE5 的可扩展技能与属性框架，通过 UGameplayAbility、UAttributeSet、UAbilitySystemComponent 实现网络就绪的技能系统。[[UnrealSystemsEngineer]] 补充：所有 Tick 逻辑必须 C++；FGameplayTag 优于字符串标识符；通过 UPROPERTY(ReplicatedUsing=OnRep_Health) + GAMEPLAYATTRIBUTE_REPNOTIFY 宏实现属性复制。 - -## Core Components -- **UAbilitySystemComponent**：GAS 核心组件，管理技能和属性，必须正确配置网络复制 -- **UGameplayAbility**：可激活的技能类，支持网络预测和复制 -- **FGameplayEffectContext**：技能效果上下文，携带命中结果、来源和自定义数据 -- **FPredictionKey**：预测键，标记可预测的能力和属性变更，支持服务器确认或回滚 -- **UAttributeSet**：属性集，包含可复制的游戏属性（生命值、能量等） - -## Network Integration (Dual Init Path) -GAS 在多人游戏中必须实现双路径初始化： - -```cpp -// 服务器路径 — PossessedBy 在 Actor 被 Controller 拥有时调用 -void AMyCharacter::PossessedBy(AController* NewController) -{ - Super::PossessedBy(NewController); - AbilitySystemComponent->InitAbilityActorInfo(GetPlayerState(), this); -} - -// 客户端路径 — OnRep_PlayerState 在 PlayerState 复制到达时调用 -void AMyCharacter::OnRep_PlayerState() -{ - Super::OnRep_PlayerState(); - AbilitySystemComponent->InitAbilityActorInfo(GetPlayerState(), this); -} -``` - -## Network Prediction in GAS -- `FPredictionKey`：标记所有预测变更，服务器确认后生效 -- 客户端预测技能激活和属性变更 -- 服务器验证并广播 `GameplayEffect` 到所有客户端 -- 验证失败时服务器回滚客户端预测 - -## Best Practices -- **双路径初始化**：必须在 `PossessedBy` 和 `OnRep_PlayerState` 两个入口点初始化 GAS -- **AttributeSet 复制**：使用 `UPROPERTY(Replicated)` 让属性在服务器和客户端同步 -- **预测管理**：高频技能必须正确设置 `NetDeltaFrequency` 避免带宽爆炸 -- **预测键作用域**：`FPredictionKey` 必须在能力激活时生成并传递给所有子操作 - -## Connection to Other Concepts -- [[Actor Replication]] — GAS 依赖 Actor 复制机制同步属性和状态 -- [[Network Prediction]] — GAS 内置网络预测支持（FPredictionKey） -- [[Server-Authoritative Model]] — 服务器权威验证技能激活请求 - -## Relationship to Agent -[[UnrealMultiplayerArchitect]] 强调：GAS 网络集成必须从双路径初始化开始，测试必须在 150ms 模拟延迟下验证技能激活，"Profile GAS replication overhead" 是网络优化的关键步骤。 - -[[UnrealSystemsEngineer]] 补充：系统架构师负责 UGameplayAbility/UAttributeSet C++ 实现和 BlueprintCallable 暴露；Tick 依赖逻辑必须 C++（即使是技能冷却检查）；AttributeSet 使用 FGameplayAttributeData + GAMEPLAYATTRIBUTE_REPNOTIFY 宏保证复制安全。 - -## Aliases -- Gameplay Ability System -- UE5 GAS -- AbilitySystemComponent -- FPredictionKey -- GameplayEffect -- AttributeSet diff --git a/wiki/concepts/GAS.md b/wiki/concepts/GAS.md deleted file mode 100644 index ff80b63c..00000000 --- a/wiki/concepts/GAS.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "GAS (Gameplay Ability System)" -type: concept -tags: ["unreal-engine", "gameplay", "abilities", "networking"] -sources: ["unreal-multiplayer-architect", "unreal-systems-engineer"] -last_updated: 2026-05-30 ---- - -## Aliases -- Gameplay Ability System -- 游戏能力系统 -- GAS - -## 定义 -GAS 是 UE5 的模块化能力框架，提供技能、属性、效果（GameplayEffect）的标准化实现，内置网络预测和复制支持。 - -## 核心组件 - -### Ability (UGameplayAbility) -- 可激活的游戏能力（技能、攻击、法术） -- 支持本地和预测激活 - -### AttributeSet (UAttributeSet) -- 管理角色属性（生命值、魔法值、攻击力等） -- 属性自动复制 - -### GameplayEffect (UGameplayEffect) -- 属性的修改效果（buff、debuff、伤害、治疗） -- 可配置持续时间、周期、堆叠 - -### AbilitySystemComponent (UAbilitySystemComponent) -- 能力系统的核心组件 -- 管理 Ability 和 AttributeSet 的生命周期 - -## 网络预测 -GAS 内置 `FPredictionKey` 支持： -- 客户端预测能力激活 -- 服务器确认或回滚 -- 支持 `PredictionKey::NewManagedNetGUID()` - -## 双初始化路径 -```cpp -// 服务器路径 -void AMyCharacter::PossessedBy(AController* NewController) { - AbilitySystemComponent->InitAbilityActorInfo(GetPlayerState(), this); -} - -// 客户端路径 -void AMyCharacter::OnRep_PlayerState() { - AbilitySystemComponent->InitAbilityActorInfo(GetPlayerState(), this); -} -``` - -## 相关概念 -- [[Actor Replication]] — GAS 属性的复制机制 -- [[Network Prediction]] — GAS 内置的网络预测支持 -- [[Server-Authoritative Model]] — GAS 的服务器验证原则 diff --git a/wiki/concepts/GDM3.md b/wiki/concepts/GDM3.md deleted file mode 100644 index 4aeab1af..00000000 --- a/wiki/concepts/GDM3.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: "GDM3" -type: concept -tags: [显示管理器, GNOME, Ubuntu] -last_updated: 2026-04-14 ---- - -# GDM3 - -GNOME Display Manager 3，是 Ubuntu 桌面环境默认的登录管理器，负责用户认证、会话选择和显示协议切换。 - -## 基本信息 -- **类型**：显示管理器（Display Manager） -- **所属项目**：GNOME -- **配置文件**：`/etc/gdm3/custom.conf` -- **官网**：https://wiki.gnome.org/Projects/GDM - -## 核心功能 -- **用户认证**：显示登录界面，验证用户凭据 -- **会话选择**：允许用户选择桌面环境（GNOME/XFCE/KDE等） -- **显示协议**：控制使用 Wayland 或 X11 -- **会话启动**：调用用户选择的桌面环境 - -## 与 Wayland/X11 的关系 - -GDM3 是连接显示协议和用户会话的桥梁： - -``` -硬件 → Kernel → Mesa/DRI → X11/Wayland → GDM3 → GNOME Shell → 用户应用 -``` - -### 配置显示协议 - -编辑 `/etc/gdm3/custom.conf`： - -```bash -sudo nano /etc/gdm3/custom.conf -``` - -| 配置 | 效果 | -|------|------| -| `WaylandEnable=true`（默认） | GDM 和会话都使用 Wayland | -| `WaylandEnable=false` | 强制 GDM 和会话使用 X11 | - -### 完整配置示例 - -```ini -[daemon] -# 取消注释以禁用 Wayland，强制使用 X11 -WaylandEnable=false - -# 自动登录（可选） -AutomaticLogin=username -AutomaticLoginEnable=True - -# Timed 登录（可选） -TimedLogin=username -TimedLoginEnable=True -TimedLoginDelay=5 -``` - -## 重启 GDM3 服务 - -修改配置后需要重启 GDM： - -```bash -# 方法1：重启 GDM 服务（不中断其他用户） -sudo systemctl restart gdm3 - -# 方法2：完全重启（会中断所有会话） -sudo reboot -``` - -## 故障排查 - -### GDM 无法启动 -```bash -# 查看 GDM 日志 -sudo journalctl -u gdm3 -n 50 - -# 检查 X11 日志 -cat /var/log/Xorg.0.log -``` - -### 切换后黑屏 -通常是显卡驱动问题，尝试： -```bash -# 查看当前显卡 -lspci | grep -i vga - -# 安装推荐驱动 -sudo ubuntu-drivers autoinstall -``` - -## 相关概念 -- [[Wayland]] — 默认显示协议（Ubuntu 24.04） -- [[X11]] — 传统显示协议（通过 WaylandEnable=false 启用） -- [[RustDesk]] — 受 GDM Wayland 配置影响的远程桌面软件 -- [[GNOME]] — 使用 GDM3 的桌面环境 diff --git a/wiki/concepts/GP3-EBS-Storage.md b/wiki/concepts/GP3-EBS-Storage.md deleted file mode 100644 index 153840d8..00000000 --- a/wiki/concepts/GP3-EBS-Storage.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "GP3 EBS Storage" -type: concept -tags: ["AWS", "Storage", "EBS", "Block-Storage"] -sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"] -last_updated: 2026-05-08 ---- - -## Definition -GP3 EBS Storage（第三代通用型 SSD）是 AWS EBS 的存储类型，Micro Focus AWS Landing Zone 标准 AMI 默认采用。GP3 提供一致的 3,000 IOPS 基础性能和 125 MiB/s 吞吐量，可独立扩展存储性能和成本。 - -## Key Characteristics -- **性能**：可独立配置 IOPS（最高 16,000）和吞吐量 -- **成本**：比 GP2 降低约 20% 成本 -- **基准性能**：3,000 IOPS + 125 MiB/s（包含在价格中） -- **最大性能**：16,000 IOPS + 1,000 MiB/s - -## GP2 vs GP3 Comparison -| 特性 | GP2 | GP3 | -|------|-----|-----| -| 容量范围 | 1 GiB - 16 TiB | 1 GiB - 16 TiB | -| IOPS | 3,000 - 16,000 | 3,000 - 16,000（独立配置） | -| 吞吐量 | 与容量耦合 | 125 - 1,000 MiB/s（独立配置） | -| 成本 | 较高 | 较低 | - -## Connections -- [[Amazon-Machine-Image]] — GP3 是标准 AMI 的默认存储配置 -- [[AWS-Landing-Zone]] — 标准化的 GP3 配置是 LZ 存储策略的一部分 diff --git a/wiki/concepts/GPG-密钥验证.md b/wiki/concepts/GPG-密钥验证.md deleted file mode 100644 index ad9db399..00000000 --- a/wiki/concepts/GPG-密钥验证.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "GPG 密钥验证" -tags: [gpg, apt, security] -date: 2026-04-22 ---- - -# GPG 密钥验证 - -## Definition -GPG (GNU Privacy Guard) 密钥验证是 APT 包管理器的安全机制，通过 GPG 签名确保从仓库下载的软件包来自可信来源且未被篡改。 - -## Docker GPG 密钥配置 -```bash -# 创建密钥目录 -sudo install -m 0755 -d /etc/apt/keyrings - -# 下载 Docker 官方 GPG 密钥 -sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc - -# 设置密钥权限（所有人可读） -sudo chmod a+r /etc/apt/keyrings/docker.asc -``` - -## Verification Mechanism -1. apt 在下载软件包前，先用 GPG 密钥验证包的签名 -2. 签名不匹配或密钥缺失时，apt 会拒绝安装并报 GPG 错误 -3. `signed-by` 参数在 sources.list 条目中指定验证用的密钥路径 - -## Common Issues -| 问题 | 原因 | 解决 | -|------|------|------| -| `NO_PUBKEY` | GPG 密钥未导入 | 运行导入命令 | -| `GPG error` | 密钥权限不正确 | `chmod a+r` | -| `The following signatures couldn't be verified` | 密钥过期或损坏 | 重新下载密钥 | - -## Related Sources -- [[如何在ubuntu-server安装-docker-docker-compose]] — Docker GPG 密钥配置步骤 - -## Related Concepts -- [[APT 仓库配置]] — 密钥与仓库配置的关系 -- [[Docker Engine]] — 被 GPG 验证的软件包 -- [[Ubuntu Server]] — GPG 密钥管理的宿主系统 diff --git a/wiki/concepts/GPT分区表.md b/wiki/concepts/GPT分区表.md deleted file mode 100644 index d2f9569d..00000000 --- a/wiki/concepts/GPT分区表.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "GPT分区表" -type: concept -tags: [partition, uefi, gpt, mbr, storage] -date: 2026-04-26 -aliases: [GUID Partition Table, GPT] ---- - -# GPT分区表 - -## Definition -GPT（GUID Partition Table，全局唯一标识分区表）是 UEFI 规范推荐的现代磁盘分区方案，用于替代传统 MBR 分区表。GPT 支持超过 2TB 磁盘、最多 128 个主分区、与 UEFI 引导完美兼容，是现代工作站和服务器的必选分区标准。 - -## GPT vs MBR -| 特性 | GPT | MBR | -|------|-----|-----| -| 磁盘容量限制 | 无（>2TB） | 2TB | -| 最大分区数 | 128 | 4 个主分区 | -| 启动兼容性 | UEFI Only | BIOS/Legacy | -| 元数据备份 | 磁盘头部 + 尾部双备份 | 仅头部 | -| 校验机制 | CRC32 校验 | 无 | - -## HP ZBook 分区要求 -- **必须使用 GPT**：HP ZBook 属于现代 UEFI 设备，不再建议使用 MBR -- Rufus 制作启动盘时，分区方案必须选择 **GPT** -- GPT 配合 UEFI 启动：目标系统类型自动变为 `UEFI (non CSM)` -- 文件系统：EFI 分区使用 FAT32（UEFI 标准格式），数据分区推荐 ext4 - -## Related -- [[UEFI启动]] — GPT 是 UEFI 的配套分区标准 -- [[NVMe硬盘分区]] — GPT 是 NVMe 硬盘的标准分区表方案 -- [[HP ZBook]] — 必须使用 GPT 的目标设备 -- [[ISOHybrid镜像]] — Rufus 写入镜像时的分区表兼容性 -- [[MBR分区表]] — GPT 取代的传统分区方案 - -## Sources -- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]] -- [[clonezilla对ubuntu-server进行全盘镜像备份]] diff --git a/wiki/concepts/GTM-Phase-Gate.md b/wiki/concepts/GTM-Phase-Gate.md deleted file mode 100644 index c28abcee..00000000 --- a/wiki/concepts/GTM-Phase-Gate.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "GTM Phase Gate" -type: concept -tags: [china, marketing, gtm, phased-launch, product-launch] -sources: [marketing-china-market-localization-strategist] -last_updated: 2026-04-30 ---- - -## Definition -GTM Phase Gate（产品上市分阶段门控模型）是 [[China Market Localization Strategist]] 提出的六阶段 P0-P5 产品上市框架，将从趋势信号验证到品牌护城河建设的完整产品生命周期分为六个递进阶段，每个阶段有明确的进入标准、交付物和退出门控。 - -## Six Phases - -| 阶段 | 名称 | 周期 | 核心任务 | -|------|------|------|---------| -| P0 | 信号验证（Signal Validation） | Week 1-2 | 趋势确认、TAM/SAM/SOM 规模测算、竞品格局 | -| P1 | 种草内容（Seed Content） | Week 3-4 | KOC 种草、内容测试、初始社区建立 | -| P2 | 渠道激活（Channel Activation） | Week 5-8 | 平台专属上市、付费投放校准 | -| P3 | 规模化（Scale） | Week 9-16 | 多平台扩张、直播电商整合、供应链就绪 | -| P4 | 优化（Optimize） | Week 17-24 | 数据驱动迭代、流失预防、私域深化 | -| P5 | 成熟运营（Mature Operations） | Week 25+ | 品牌护城河建设、忠诚度计划、品类扩张 | - -## Phase Gate Criteria（门控标准） - -每个阶段包含明确的 Go/No-Go 决策标准： - -**P0 → P1 门控**：趋势数据来自 3+ 平台、交叉验证完成、TAM/SAM/SOM 有据可查、平台选择有数据支撑 - -**P1 → P2 门控**：KOC 候选名单 ≥ 10 个、5 种内容变体完成 A/B 测试、基线互动指标记录在案、PMF 假设被验证或否定 - -**P2 → P3 门控**：广告账户开立并校准、日预算分配就绪、有机+付费内容日历发布、直播测试排期、私域漏斗可运作 - -## Go-to-Market Funnel Integration - -GTM Phase Gate 嵌入 [[China Marketing Funnel]] 的各阶段： - -- **P0** → 漏斗顶端（趋势识别） -- **P1-P2** → 漏斗中部（种草→激活） -- **P3** → 漏斗底部（转化） -- **P4-P5** → 留存与复购（私域运营） - -## Key Principles -- **资源优化**：优先适配 1-3 人小团队（一人公司模型） -- **可执行性**：每阶段交付物必须在 7 天内可执行 -- **量化决策**：每个门控决策必须有数据支撑，不可凭直觉通过 -- **闭环迭代**：[[Trend-To-Action]] 框架输出直接注入各阶段的优先级决策 - -## Relationship to Other Concepts -- [[Trend-To-Action]]：GTM Phase Gate 的数据输入层，每阶段由趋势信号触发 -- [[China Marketing Funnel]]：GTM Phase Gate 的宏观框架参照 -- [[KOC Seeding]]：P1 阶段的核心执行策略 -- [[Live Commerce]]：P3 阶段规模化转化的核心手段 -- [[私域运营]]：P4-P5 阶段留存运营的核心方法 diff --git a/wiki/concepts/Gamification-System.md b/wiki/concepts/Gamification-System.md deleted file mode 100644 index 93f8480d..00000000 --- a/wiki/concepts/Gamification-System.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Gamification System" -type: concept -tags: [gamification, engagement, achievement, user-retention] -sources: [design-whimsy-injector] -last_updated: 2026-05-15 ---- - -# Gamification System - -## Definition - -游戏化成就系统（Gamification Achievement System）通过徽章解锁、彩蛋发现、进度庆祝等机制激励用户探索和深度使用，由 [[Whimsy-Injector]] 设计实现。 - -## Core Components - -- **Achievement System（成就系统）**：定义成就类型（首次点击/彩蛋发现/任务大师），通过庆祝动画激励用户 -- **Easter Egg Discovery（彩蛋发现系统）**：Konami Code、点击序列、特定元素触发隐藏功能 -- **Progress Celebration（进度庆祝）**：任务完成、里程碑到达时的动画反馈 -- **Rainbow Mode（彩虹模式）**：彩蛋触发的全页特效 - -## Whimsy Injector 的游戏化设计原则 - -- 成就系统通过激励探索建立社区感 -- 彩蛋策略奖励用户好奇心和深入探索 -- 进度庆祝维持长期动机而非短期刺激 -- 设计确保愉悦但不造成上瘾模式 - -## Example Implementation - -```javascript -class WhimsyAchievements { - unlock(achievementId) { - // 成就解锁逻辑 - } - showCelebration(achievement) { - // 庆祝动画展示 - } -} -``` - -## Relationship to Other Concepts - -- [[Gamification]]：Gamification System 是 Gamification 理论在 Whimsy Injector 中的具体实现 -- [[Micro-Interaction-Design]]：进度庆祝动画属于微交互范畴 -- [[Inclusive-Delight-Design]]：游戏化必须遵循包容性设计原则 - -## Source - -- [[Whimsy-Injector]] — 游戏化系统设计核心来源 diff --git a/wiki/concepts/Gamification.md b/wiki/concepts/Gamification.md deleted file mode 100644 index 1e8cf81d..00000000 --- a/wiki/concepts/Gamification.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Gamification" -type: concept -tags: [engagement, ux, design, retention] -sources: [design-whimsy-injector, product-behavioral-nudge-engine] -last_updated: 2026-05-15 ---- - -# 游戏化（Gamification） - -## Aliases -- Gamification -- 游戏化设计 -- 成就系统 - -## 定义 - -游戏化是将游戏设计元素（如成就、徽章、进度条、排行榜、奖励机制）应用于非游戏场景的设计策略，核心目标是提升用户参与度、动机和留存率。关键区分：游戏化≠做游戏，而是借鉴游戏的激励机制来解决真实业务问题。 - -## 核心要素 - -| 要素 | 作用 | 示例 | -|------|------|------| -| 成就系统（Achievements） | 里程碑认可，激励探索 | "完成首次购买：新手礼" | -| 进度可视化 | 降低长任务的心理阻力 | 进度条、步骤指示器 | -| 反馈即时性 | 强化行为-奖励关联 | 完成动作→立即庆祝动画 | -| 排行榜（Leaderboards） | 社会认同激励 | 周活跃榜、积分排行 | -| 虚拟奖励 | 低成本高情感价值的激励 | 徽章、称号、表情 | - -## 设计原则 - -- **动机的层次**：外在动机（积分/徽章）→ 内在动机（成就感/社区归属） -- **非强迫性参与**：游戏化不应使用户感到被迫使用产品 -- **无伤害激励**：避免设计导致过度使用或成瘾的机制 -- **包容性设计**：成就系统需考虑不同能力和文化背景的用户 - -## 风险与局限 - -- **过度游戏化**：过多奖励稀释内在动机（过度理由效应） -- **竞争焦虑**：排行榜对低排名用户可能产生负面情绪 -- **文化差异**：某些奖励/惩罚机制在不同文化背景下效果迥异 - -## 应用场景 - -- [[design-whimsy-injector]] 交付了基于 JavaScript 的成就系统实现代码，包含成就解锁、庆祝动画、Konami Code 复活节彩蛋等游戏化组件 - -## 相关概念 - -- [[design-whimsy-injector]]：游戏化元素的具体实现者 -- [[Micro-Interaction]]：成就解锁的庆祝动画本身是微交互的一种 -- [[Inclusive-Delight]]：游戏化设计需避免对残障用户产生障碍 diff --git a/wiki/concepts/GapAssessment.md b/wiki/concepts/GapAssessment.md deleted file mode 100644 index 247d112e..00000000 --- a/wiki/concepts/GapAssessment.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "Gap Assessment" -type: concept -tags: [] -sources: [compliance-auditor] -last_updated: 2026-04-30 ---- - -# Gap Assessment - -## Definition - -差距评估（Gap Assessment）是对照目标合规框架（如 SOC 2、ISO 27001）要求，系统性地评估组织当前安全态势与目标状态之间差距的分析过程。 - -## Core Components - -### 标准格式（ComplianceAuditor 定义） -每个差距发现必须包含： -1. **控制引用（Control Reference）**：框架中对应的控制项编号（如 CC6.1） -2. **当前状态（Current State）**：组织现有的实际状态 -3. **目标状态（Target State）**：满足控制要求的目标状态 -4. **修复步骤（Remediation）**：具体可执行的修复行动 -5. **估算工作量（Effort）**：预计完成所需时间 -6. **优先级（Priority）**：基于风险和审计时间线的优先级 - -### 评分标准 -- **Ready (100/100)**：完全满足要求 -- **Partial**：部分满足，存在差距 -- **Non-Compliant**：完全不满足要求 - -## Deliverable Format -```markdown -## Gap Assessment Report - -**Assessment Date**: YYYY-MM-DD -**Target Certification**: SOC 2 Type II -**Audit Period**: YYYY-MM-DD to YYYY-MM-DD - -## Executive Summary -- Overall readiness: X/100 -- Critical gaps: N -- Estimated time to audit-ready: N weeks - -## Findings by Control Domain -``` - -## Related Concepts -- [[SOC 2]]：主要目标框架 -- [[Continuous Compliance]]：评估完成后的持续监控机制 -- [[Evidence Collection]]：差距修复后需要收集的证据 - -## Related Sources -- [[compliance-auditor]] diff --git a/wiki/concepts/GasOptimization.md b/wiki/concepts/GasOptimization.md deleted file mode 100644 index d1e87eb1..00000000 --- a/wiki/concepts/GasOptimization.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: "GasOptimization" -type: concept -tags: [] -last_updated: 2026-05-01 ---- - -## Definition -Gas Optimization 是指在 EVM 智能合约开发中，通过技术手段降低合约执行和部署的 Gas 消耗，直接减少用户费用和以太坊网络的负担。由于每个区块的 Gas 上限固定，优化 Gas 消耗也是提高协议吞吐量的关键。 - -## Core Gas Costs (EVM) - -| 操作 | Cold Access | Warm Access | -|------|-------------|-------------| -| SLOAD（读取存储） | 2100 gas | 100 gas | -| SSTORE new（写入新槽） | 20000 gas | - | -| SSTORE update（更新槽） | 5000 gas | 2900 gas | -| CALL（外部调用） | 2600 gas + 被调函数 gas | 100 gas | -| CREATE（创建合约） | 32000 gas | - | - -## Key Patterns - -### 1. Storage Packing（存储打包） -将多个小类型打包进同一 32 字节槽，节省 SSTORE 次数： -```solidity -// ✅ Good: 2 个变量共享一个槽 -struct PackedData { - uint128 amount; // 16 bytes - uint128 id; // 16 bytes → 同槽 -} -``` - -### 2. Calldata over Memory -```solidity -// ✅ Good: calldata 只读，节省拷贝 -function processIds(uint256[] calldata ids) external pure {} - -// ❌ Bad: memory 需要拷贝到内存 -function processIds(uint256[] memory ids) external pure {} -``` - -### 3. Custom Errors over Require Strings -```solidity -// ✅ Good: 节省 ~50 gas/revert -error InsufficientBalance(uint256 requested, uint256 available); -require(balance >= amount, "Insufficient balance"); - -// ❌ Bad: 错误信息存储在字节码中 -require(balance >= amount, "Insufficient balance for this operation"); -``` - -### 4. Immutable over Constant（运行时） -```solidity -uint256 public constant MAX_SUPPLY = 1_000_000; // 编译时常量 -address public immutable owner; // 运行时只设置一次 -``` - -### 5. External over Public -- External 函数：调用时参数通过 calldata 传递 -- Public 函数：需要检查是否内部调用，参数通过 memory 传递 -- 仅被内部调用 → public；仅被外部调用 → external - -### 6. Unchecked Math（Safe Math） -```solidity -unchecked { counter++; } // 已知 counter 不会溢出 -``` - -## Sources -- [[engineering-solidity-smart-contract-engineer]] diff --git a/wiki/concepts/Gate-Process.md b/wiki/concepts/Gate-Process.md deleted file mode 100644 index 21b48d26..00000000 --- a/wiki/concepts/Gate-Process.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "Gate Process" -type: concept -tags: [CTP, Cloud, AWS, Governance] -sources: [ctp-topic-20-program-demand-process-flow-and-poc-onboarding] -last_updated: 2026-04-14 ---- - -## Definition - -网关审批流程（Gate Process）是用于治理云迁移项目进度的关键决策点框架。通过在关键里程碑设置"网关"（Gate）来确保项目在进入下一阶段前满足所有准入条件，从而控制风险并确保治理严谨性。 - -## Gate Stages in CTP - -### Gate 0 — 评估准入（Assessment Gate） - -- **目的**：确认需求是否符合云转型范围 -- **审查内容**：业务需求、技术可行性、资源可用性 -- **产出**：准入决策，是否进入详细规划阶段 - -### Gate 1 — 设计审批（Design Authority Gate） - -- **目的**：验证解决方案设计是否符合云原生原则 -- **审查内容**：架构设计、安全策略、合规性、 IaC 规划 -- **产出**：Design Authority 批准或驳回 -- **关键要求**：必须有经过审批的 [[Solution-Design]] - -### Gate 3 — 迁移准入（Migration Gate） - -- **目的**：确认产品已具备进入生产环境迁移的条件 -- **审查内容**：POC 成果、IaC 就绪状态、团队能力、安全评审结果 -- **产出**：最终迁移批准 - -## Gate Process vs 敏捷方法 - -| 维度 | Gate Process | 敏捷方法（Scrum/Kanban） | -|------|-------------|--------------------------| -| 决策模式 | 阶段性审批节点 | 持续反馈循环 | -| 变更控制 | Gate 之间冻结 | 随时调整优先级 | -| 适用场景 | 大范围迁移治理 | 迭代式产品开发 | -| 风险控制 | 强制审查点 | 快速失败快速调整 | -| 文档要求 | 高（各 Gate 交付物） | 低（Working Software） | - -## Relationship with Agile - -两者非逻辑矛盾，而是适用场景不同： - -- **Gate Process** 适用于需要严格治理的大范围企业迁移决策 -- **敏捷方法** 适用于持续迭代的产品开发和交付 - -CTP 实践中可将两者结合：使用敏捷方法管理迭代交付，使用 Gate Process 治理迁移准入决策。 - -## Related Concepts - -- [[Program-Demand-Process]]：Gate Process 是需求流程的核心治理机制 -- [[Proof-of-Concept]]：Gate 3 前必须完成 POC 并验证成功标准 -- [[Solution-Design]]：Gate 1 的核心审批交付物 -- [[Design-Authority]]：Gate 1 审批的执行主体 -- [[Agile]]：与 Gate Process 形成互补的迭代管理方法 - -## References - -- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] diff --git a/wiki/concepts/Gatekeeper.md b/wiki/concepts/Gatekeeper.md deleted file mode 100644 index bbc3b94b..00000000 --- a/wiki/concepts/Gatekeeper.md +++ /dev/null @@ -1,69 +0,0 @@ -# Gatekeeper - -> macOS 的安全机制，用于验证应用程序是否来自已识别的开发者可信来源。 - -## Overview -Gatekeeper 是 macOS 的应用安全验证系统，旨在保护用户免受恶意软件的侵害。它会检查应用程序的来源和签名状态，拒绝运行未授权的软件。 - -## How It Works -Gatekeeper 会在用户尝试运行从互联网下载的应用程序时触发验证流程： -1. 检查应用是否来自 App Store -2. 检查是否有有效的 Developer ID 签名 -3. 检查是否被标记为已隔离（quarantined） - -## Quarantine Attribute -macOS 使用扩展属性（Extended Attributes）来标记从互联网下载的文件： -- `com.apple.quarantine`：标记文件来自互联网下载 -- `com.apple.metadata`：包含下载来源 URL 等元数据 - -## Removing Quarantine -```bash -# 递归移除 quarantine 属性（适用于目录） -xattr -rd com.apple.quarantine /path/to/application/ - -# 验证（无输出表示解除成功） -xattr /path/to/application/binary - -# 查看 quarantine 状态 -xattr -l /path/to/application/binary -``` - -## Gatekeeper Modes -```bash -# 查看当前 Gatekeeper 状态 -spctl --status - -# 允许所有来源（不推荐，存在安全风险） -sudo spctl --master-disable - -# 查看应用状态 -spctl --assess --verbose /path/to/application -``` - -## Use Cases -- **Homebrew**：安装后需解除 quarantine 才能运行 -- **FRP**：从 GitHub 下载的二进制文件需解除限制 -- **第三方工具**：任何未签名的可执行文件 - -## Security Considerations -| 方法 | 安全性 | 适用场景 | -|------|--------|----------| -| Developer ID 签名 | 最高 | 正式发布的软件 | -| App Store | 高 | 仅限 App Store 应用 | -| 解除 quarantine | 低 | 自托管工具/开发环境 | - -## Best Practices -1. **仅对可信来源解除限制**：如 GitHub Release 官方二进制文件 -2. **使用 -r 递归参数**：确保目录内所有文件解除限制 -3. **验证文件完整性**：下载后检查 SHA256 校验和 -4. **保持 Gatekeeper 开启**：除非完全了解风险，否则不要禁用 - -## Related Concepts -- [[launchd]] — macOS 服务管理器 -- [[frp]] — 需要解除 Gatekeeper 才能运行 -- [[Mac Mini M4]] — 需要处理 Gatekeeper 问题 - -## References -- Apple Support: Safely open apps on your Mac -- `man xattr` -- `man spctl` diff --git a/wiki/concepts/Gegenrede.md b/wiki/concepts/Gegenrede.md deleted file mode 100644 index a2b2d8f8..00000000 --- a/wiki/concepts/Gegenrede.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Gegenrede" -type: concept -tags: [knowledge-management, critical-thinking, zettelkasten, zk-steward] -sources: [zk-steward] -last_updated: 2026-04-25 ---- - -## Definition -Gegenrede（德语"反诘"或"反论"）是 [[zk-steward]] 链接提议流程中的辩证机制——在提议新笔记的候选链接后，提出一个来自**不同学科或视角**的反问，激发笔记间的辩证对话，防止同质化链接和思维茧房。 - -## Etymology -Gegenrede = Gegen（相对/反对）+ Rede（话语/论述）→ 对立论述、反诘 - -这一概念源自德国学术传统中的辩证法（类似苏格拉底式反诘），在 [[Niklas-Luhmann]] 的 Zettelkasten 中被隐式使用——每条笔记不仅建立正向链接，还通过跨学科反问保持知识网络的辩证活性。 - -## How It Works in ZK Steward - -在 [[Link-Proposer]] 流程中，Gegenrede 是第三步： - -1. **候选链接**（Link Candidates）：提议 2-5 个相关笔记/概念链接 -2. **关键词/索引建议**（Keywords & Index Entries）：确保笔记可被找到 -3. **Gegenrede 反诘**：提出一个跨学科反问 - - "如果从经济学角度看这个问题会怎样？" - - "反事实：如果没有这个因素，结论会改变吗？" - - "这个观点的最大弱点是什么？" - -## Purpose - -| 防止的问题 | 达到的目标 | -|---------|---------| -| 同质化链接（只连观点一致的笔记） | 强制跨学科思考 | -| 思维茧房（只听想听的声音） | 引入对立视角 | -| 静态结论（笔记是终点而非起点） | 激发后续对话与迭代 | - -## Example - -新笔记提议链接到 `[[Product-Manager]]` 后： - -> **Gegenrede**: 如果这个产品决策由一个纯经济学家视角驱动（成本效益最大化而非用户满意度），结论会有什么不同？这个视角是否遗漏了什么？ - -→ 这促使笔记作者主动思考产品管理的多元价值维度，而非单一路径依赖。 - -## Connections -- [[zk-steward]] ← 使用 Gegenrede 作为链接提议的一部分 -- [[Link-Proposer]] ← 包含 Gegenrede 步骤的工作流 -- [[Luhmann-四原则]] ← Gegenrede 服务于"持续对话"原则 -- [[Zettelkasten]] ← Gegenrede 是 Zettelkasten 辩证活性的体现 -- [[zk-steward-companion]] ← Gegenrede 作为可选 Skill 定义存在 - -## Aliases -- 反诘 -- Counter-question -- Socratic questioning -- 辩证反问 diff --git a/wiki/concepts/GenAI.md b/wiki/concepts/GenAI.md deleted file mode 100644 index e8014a67..00000000 --- a/wiki/concepts/GenAI.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "GenAI" -type: concept -tags: [] -sources: [designing-for-agentic-ai] -last_updated: 2026-04-27 ---- - -## Definition - -GenAI（Generative AI / 生成式AI）是一类专注于**创作新内容**的人工智能系统，能够生成文本、图像、音乐等创意内容。可以将其理解为**创意助手**——能生成创意想法或进行语言翻译。 - -## 与 Agentic AI 的区别 - -| 维度 | GenAI（生成式AI） | Agentic AI（智能体AI） | -|------|------------------|----------------------| -| 核心能力 | 创建内容（文本/图像/音乐） | 行动、决策、预判 | -| 交互模式 | 被动响应用户请求 | 主动发起行动 | -| 典型场景 | 生成诗歌、写文章 | 预约会议、发送邀请 | -| 设计范式 | 响应式交互 | 实时反馈式交互 | - -## Examples - -**GenAI 示例：** -- 用户：请写一首关于猫的诗 → AI 生成一首优美的诗 - -**Agentic AI 示例：** -- 用户：请帮我预约和同事的会议 → AI 不仅找到双方都方便的时间，还考虑偏好的会议地点，并自动发送日历邀请 - -## Related -- [[designing-for-agentic-ai]] — 本概念的主要来源 -- [[Agentic-AI]] — GenAI 的对比概念（智能体AI） diff --git a/wiki/concepts/Generalist.md b/wiki/concepts/Generalist.md deleted file mode 100644 index 2278512a..00000000 --- a/wiki/concepts/Generalist.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Generalist" -type: concept -tags: [personal-development, career, strategy] -sources: [if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间] -last_updated: 2026-04-27 ---- - -## Aliases -- 通才 -- 多面手 -- 博学者 - -## Definition -在多个领域拥有跨学科知识和视角，能够在不同领域的交叉地带发现独特机会和解决方案的人才。与专精化（Specialist）相对。 - -## Core Argument -[[if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间]] 论证：通才不是劣势，而是在 AI 时代最强大的竞争优势。 - -关键逻辑： -1. **交叉视野创造独特视角**：不同领域的思想相互补充，形成独特的看待世界的方式 -2. **创意密度更高**：多领域知识让你能捕捉到单一领域专家看不到的机会 -3. **AI 时代专业化被削弱**：AI 替代单一技能，但无法复制跨领域的个人独特经历和视角 - -> "你的优势更多在于 intersection（交叉）而非 expertise（专业）。" - -## Examples -- [[Leonardo da Vinci]] — 画家 + 雕塑家 + 工程师 + 解剖学家 -- 成功 CEO/创始人 — 理解营销足以指导产品、懂产品足以领导团队 -- [[Adam Smith]]（被引用为反面教材）— 过分专业化导致人被异化为"机器零件" - -## Connections -- [[Self-Education]] — 通才通过自学获得跨领域知识 -- [[Self-Interest]] — 通才追随自身好奇心而非外部分工 -- [[Self-Sufficiency]] — 通才不依赖单一专业技能谋生 -- [[Second-Renaissance]] — 第二次文艺复兴的历史背景使通才模式再次成为可能 -- [[Idea-Density]] — 通才通过跨领域知识产生更高创意密度 diff --git a/wiki/concepts/Generation.md b/wiki/concepts/Generation.md deleted file mode 100644 index 4d7adc7e..00000000 --- a/wiki/concepts/Generation.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Generation" -type: concept -tags: [RAG, LLM, 问答生成] -sources: [rag从入门到精通系列1-基础rag] -last_updated: 2025-01-16 ---- - -## Definition - -Generation（生成阶段）是 RAG 管道的第三阶段，将用户问题与检索到的相关文档块组合成 Prompt，输入 LLM 生成带事实依据的答案。 - -## Core Process - -``` -问题 + Top-k 文档块 → PromptTemplate 组装 → LLM 生成 → 返回答案 -``` - -1. **组装上下文**：将问题（Question）和检索到的文档块（Context）放入预定义的字典结构 -2. **Prompt 模板**：通过 PromptTemplate 将问题+上下文组合成完整的 Prompt String -3. **LLM 生成**：将 Prompt 输入 LLM，LLM 基于检索到的知识生成回答 -4. **可选链式组合**：使用 LangChain/LlamaIndex 的 Chain 将 Retrieval 和 Generation 串联为统一管道 - -## Key Prompt Pattern - -``` -你是一个问答助手。请根据以下参考资料回答用户问题。 -如果参考资料中没有相关信息，请如实说明。 - -参考资料： -{context} - -用户问题：{question} - -回答： -``` - -## LangChain Chain - -LangChain 和 LlamaIndex 提供了 `RetrievalQA Chain` 等开箱即用的链，可将检索和生成过程自动化串联，避免手动拼装 Prompt。 - -## Connections - -- [[Generation]] ← part_of ← [[RAG]] -- [[Generation]] ← receives_input ← [[Retrieval]] -- [[Generation]] ← uses ← [[Large-Language-Model]] -- [[Generation]] ← uses ← [[Prompt]] - -## Aliases - -- Answer Generation -- RAG Generation -- LLM Response Generation -- 答案生成 diff --git a/wiki/concepts/Generative-Engine-Optimization.md b/wiki/concepts/Generative-Engine-Optimization.md deleted file mode 100644 index 435fa30b..00000000 --- a/wiki/concepts/Generative-Engine-Optimization.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Generative Engine Optimization" -type: concept -tags: ["SEO", "AI", "marketing", "GEO"] -sources: ["marketing-ai-citation-strategist"] -last_updated: 2026-04-30 ---- - -## Definition - -Generative Engine Optimization（GEO，生成式引擎优化）：通过改善内容信号来提升 AI 推荐引擎对品牌内容引用概率的技术实践。与 AEO（Answer Engine Optimization）密切相关，GEO 更强调生成式 AI 的整体可见性策略。 - -## Relationship with AEO - -- **AEO**：专注于答案引擎（直接给出答案的 AI 系统，如 Perplexity）的引用优化 -- **GEO**：涵盖所有生成式 AI 场景下的可见性，包括 ChatGPT、Claude 等合成式 AI 助手 - -两者共同构成 AI 时代内容可见性的完整策略框架。 - -## Core Methods - -1. **Entity Optimization**：确保品牌在 AI 知识图谱中清晰可识别（Wikipedia/Wikidata/Crunchbase） -2. **Citation Pattern Engineering**：围绕用户实际输入 AI 的查询模式设计内容 -3. **Multi-Platform Strategy**：针对各平台的差异化内容适配 -4. **Benchmark-Driven Iteration**：建立引用率基准，持续测量和迭代 - -## Prompt Patterns - -| Pattern | Content Type | Example Query | -|---------|-------------|---------------| -| "Best X for Y" | 对比内容 | "Best CRM for startups" | -| "X vs Y" | 专页对比 | "HubSpot vs Salesforce" | -| "How to choose X" | 买家指南 | "How to choose a project management tool" | -| "What is the difference between X and Y" | 清晰定义 | "What's the difference between SEO and AEO" | -| "Recommend a X that does Y" | 功能导向 | "Recommend a CRM with email tracking" | - -## Related Concepts - -- [[Answer Engine Optimization]]（AEO）— GEO 的子集/前身 -- [[Citation Audit Scorecard]] — GEO 效果的可量化评估工具 -- [[Prompt Pattern Engineering]] — GEO 的核心内容策略方法 diff --git a/wiki/concepts/Generator-Space.md b/wiki/concepts/Generator-Space.md deleted file mode 100644 index d490dd34..00000000 --- a/wiki/concepts/Generator-Space.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Generator Space" -type: concept -tags: [] ---- - -## Definition -生成器空间 $\mathcal{G}$ 是递归自我优化框架的核心数学结构，定义为 $\mathcal{G} \subseteq \mathcal{P}^{\mathcal{I}}$，其中每个生成器（Generator）$G \in \mathcal{G}$ 是一个从意图空间 $\mathcal{I}$ 到程序/提示空间 $\mathcal{P}$ 的函数： -$$G: \mathcal{I} \to \mathcal{P}$$ - -## Intuition -传统计算：输入 → 输出（单个解） -生成器计算：意图 → 生成器（解的生成机制） - -核心洞察：**优化"生成解的机制"比优化"单个解"更有价值**——因为生成器可以被迭代改进，其输出可以自我参照地影响生成器本身的演化。 - -## Role in Recursive Self-Optimization -在递归自我优化系统中，生成器空间 $\mathcal{G}$ 是自映射 $\Phi: \mathcal{G} \to \mathcal{G}$ 的定义域和值域。系统的收敛目标是在 $\mathcal{G}$ 中找到不动点 $G^*$。 - -## Sources -- [[a-formalization-of-recursive-self-optimizing-generative-systems]] - -## Connections -- [[Recursive Self-Optimization]] ← operates_on ← [[Generator Space]] -- [[Self-Referential Computation]] ← enables ← [[Generator Space]] diff --git a/wiki/concepts/Generator.md b/wiki/concepts/Generator.md deleted file mode 100644 index 4edb9367..00000000 --- a/wiki/concepts/Generator.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Generator 模式" -type: concept -tags: [Agent, Skill, Design Pattern, ADK] -sources: [google-5个agent-skill设计模式-2026-03-19] -last_updated: 2026-05-15 ---- - -## Overview -Generator 是 Google ADK 发布的 5 种 Agent Skill 设计模式之一，通过"填空"流程从模板生成结构化输出，强制保证输出格式的一致性。 - -## Mechanism -- 利用两个可选目录：`assets/` 存放输出模板，`references/` 存放样式指南 -- SKILL.md 扮演项目经理的角色 -- 指示 Agent 加载模板、读取样式指南、向用户询问缺失的变量、然后填充文档 - -## Use Cases -- 生成统一的 API 文档 -- 标准化 commit 信息 -- 脚手架项目结构生成 -- 任何需要保持格式一致的结构化输出 - -## Implementation -``` -assets/output-template.md: 输出模板 -references/style-guide.md: 样式指南 -SKILL.md: 项目经理角色，引导 Agent 填充模板 -→ 向用户询问缺失变量 → 填充文档 → 输出 -``` - -## Key Insight -> 如果 Tool Wrapper 是应用知识，Generator 则是强制一致的输出格式。很多 agent 每次运行生成的文档结构都不一样，Generator 完美解决这个问题。 - -## Related Concepts -- [[ToolWrapper]]：应用知识，Generator 生成结构，两者互补 -- [[Inversion]]：可以在开头依赖 Inversion 来收集必要的变量 -- [[Reviewer]]：可以审查 Generator 生成的输出 -- [[渐进式披露]]：类似的按需加载思想 - -## Connections -- [[Google5个AgentSkill设计模式]] ← part_of ← [[Generator]] -- [[ADK]] ← published_by ← [[Generator]] diff --git a/wiki/concepts/Genetic-Algorithm.md b/wiki/concepts/Genetic-Algorithm.md deleted file mode 100644 index 6200217b..00000000 --- a/wiki/concepts/Genetic-Algorithm.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Genetic Algorithm" -type: concept -tags: [] -sources: - - multi-agent-system-reliability -last_updated: 2026-04-28 ---- - -# Genetic Algorithm - -## 定义 -遗传算法——传统机器学习中基于自然选择和遗传机制的优化算法，是[[Tree-of-Thoughts]]和[[Knock-out-Pattern]]的ML理论根源。 - -## 核心要素 -1. **遗传表示**（Genetic Representation）：解决方案域的编码（模型+上下文） -2. **适应度函数**（Fitness Function）：评估解决方案质量的函数（淘汰赛裁判） - -## 在多智能体系统中的应用 -- [[Knock-out-Pattern]]是遗传算法的精简实现——将适应度函数替换为验证器（Validator） -- [[Tree-of-Thoughts]]通过验证器持续筛选Agent分支，可结合赢家的特征重组生成新Agent - -## 来源 -- [[multi-agent-system-reliability]] diff --git a/wiki/concepts/Genre-Specific-Prompt-Patterns.md b/wiki/concepts/Genre-Specific-Prompt-Patterns.md deleted file mode 100644 index 7e27ed30..00000000 --- a/wiki/concepts/Genre-Specific-Prompt-Patterns.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -title: "Genre-Specific Prompt Patterns" -type: concept -tags: [prompt-engineering, ai-image-generation, photography-genre] -last_updated: 2026-05-15 ---- - -## Definition - -针对不同摄影体裁（人像、产品、风光、时尚等）的专业化提示词模板，通过体裁特有的结构和参数组合，实现各类型 AI 生成图像的专业级输出。 - -## Portrait Photography Pattern - -### 模板结构 -``` -[主体描述：年龄/种族/表情/着装] | -[姿态与肢体语言] | -[背景处理方式] | -[布光设置：主光/补光/轮廓光/发丝光] | -[相机参数：焦距/光圈/视角] | -[风格：编辑/时尚/商业/艺术] | -[色彩调性与情绪] | -[参考摄影师风格] -``` - -### 典型参数 -- 焦距：85mm / 50mm（全身 35mm） -- 光圈：f/1.2–f/2.0（浅景深人像） -- 视角：eye level（平视） -- 布光：Rembrandt / Butterfly / Loop -- 景深：shallow DOF, creamy bokeh - -### 示例关键词 -- "cinematic portrait lighting", "Rembrandt triangle on cheek", "creamy bokeh background", "85mm f/1.4", "eye-level portrait" - ---- - -## Product Photography Pattern - -### 模板结构 -``` -[产品描述：材质/工艺/细节] | -[表面/背景描述] | -[布光：柔光箱位置/反光板/渐变] | -[相机：微距/标准/角度/距离] | -[拍摄类型：Hero Shot/Lifestyle/Detail/Scale Context] | -[品牌美学对齐] | -[后期处理：干净/氛围/鲜艳] -``` - -### 典型参数 -- 焦距：100mm 微距 / 90mm（产品人像） -- 光圈：f/8–f/11（整体清晰） -- 布光：Large softbox + Strip lights -- 景深：Focus stacked（全清晰） - -### 示例关键词 -- "hero shot", "softbox overhead gradient", "edge definition strip lights", "commercial advertising quality", "clean post-processing" - ---- - -## Landscape Photography Pattern - -### 模板结构 -``` -[地理位置与地质特征] | -[时间与大气条件] | -[天气与天空处理] | -[前景/中景/远景元素] | -[相机：广角/深焦/全景] | -[光质与方向] | -[色彩调性：自然/增强/戏剧性] | -[风格：纪实/艺术/空灵] -``` - -### 典型参数 -- 焦距：16–35mm（广角） -- 光圈：f/11–f/16（深景深） -- 视角：Low angle / eye level -- 景深：front-to-back sharp focus - -### 示例关键词 -- "golden hour light", "deep focus", "wide angle landscape", "dramatic sky", "foreground interest", "ND filter long exposure" - ---- - -## Fashion Photography Pattern - -### 模板结构 -``` -[模特描述与表情] | -[服装细节与造型] | -[妆发方向] | -[场地/布景设计] | -[姿态风格：编辑/商业/前卫] | -[布光：戏剧性/柔和/混合] | -[相机运动：静态/动态] | -[杂志/品牌 campaign 美学参考] -``` - -### 典型参数 -- 焦距：85mm（特写）/ 35mm（全身） -- 光圈：f/1.4–f/4.0（视构图需求） -- 视角：varied（多样化） -- 景深：selective focus - -### 示例关键词 -- "fashion editorial", "high fashion lighting", "avant-garde styling", "magazine spread aesthetic", "dramatic pose", "Haute couture" - ---- - -## Cross-Genre Principles - -1. **主体清晰**：每种体裁的核心被摄对象必须首要明确 -2. **光线匹配**：布光方式与体裁风格一致（人像用柔光，产品用可控光，时尚用戏剧光） -3. **相机参数对应体裁**：人像浅景深（f/1.4），产品深景深（f/8+），风光超深焦（f/11+） -4. **参考引导**：引用体裁内知名摄影师风格提升 AI 输出专业度 - -## Connections - -- [[Five-Layer-Prompt-Structure]] 在各体裁中的具体应用 -- [[Photography-Terminology]] 提供各体裁的专业术语 -- [[Prompt-Engineering]] 的体裁适配层 - -## Aliases - -- 体裁专属提示词模板 -- Photography Genre Templates -- Domain-Specific Prompt Patterns diff --git a/wiki/concepts/Geographic-Coherence.md b/wiki/concepts/Geographic-Coherence.md deleted file mode 100644 index 12d28251..00000000 --- a/wiki/concepts/Geographic-Coherence.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Geographic Coherence" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-25 ---- - -## 定义 -地理连贯性（Geographic Coherence）是指在构建虚拟世界时，确保地理要素（地形、气候、水文、生物群落、人类定居模式）之间物理一致性的一系列原则。 - -## 核心原则 -1. **河流不分叉**：支流汇入主流，河流不物理分叉流向不同海洋（三角洲和分流是例外） -2. **气候是系统**：气候受纬度、洋流、地形共同制约，雨影效应真实存在 -3. **地理非装饰**：每个地理特征都必须有对当地居民的实质性影响 -4. **规模决定约束**：不同规模的政治实体（城邦/王国/帝国）有不同的地理需求 - -## 应用场景 -[[academic-geographer]] Agent 使用地理连贯性框架验证虚拟世界设定的物理一致性，输出地理连贯性报告（Geographic Coherence Report）。 - -## 理论基础 -- [[Plate Tectonics]]：山脉和地形由板块运动形成 -- [[Koppen Climate Classification]]：气候分类的标准化系统 -- [[Rain Shadow Effect]]：地形对降水分布的影响 - -## 与相关概念的关系 -- 扩展 [[Environmental Determinism]]，但承认人类能动性 -- 与 [[Mackinder Heartland Theory]] 关联（地理约束战略竞争） -- 与 [[Christaller Central Place Theory]] 关联（地理影响城市层级） - -## 来源 -- [[academic-geographer]] diff --git a/wiki/concepts/Ghostwriting.md b/wiki/concepts/Ghostwriting.md deleted file mode 100644 index 8ae31b4e..00000000 --- a/wiki/concepts/Ghostwriting.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Ghostwriting" -type: concept -tags: ["writing", "content", "delegation", "ai"] -sources: ["marketing-book-co-author"] -last_updated: 2026-04-30 ---- - -## Definition - -代笔写作（Ghostwriting）是一种内容生产模式：由代笔人（ghostwriter）完成实际写作工作，但成书内容以委托方（author）的名义发布。委托方提供核心思想、素材和声音特征，代笔人负责结构化组织和文字呈现，最终作品体现的是委托方的思想和声音，而非代笔人。 - -## Aliases -- Ghostwriter / Ghostwriting -- 代笔 -- 影子写手 - -## Ghostwriting vs Traditional Writing - -| 维度 | 代笔写作 | 传统写作 | -|------|---------|---------| -| 作者署名 | 委托方署名 | 代笔人署名 | -| 核心价值 | 委托方的思想和声音 | 代笔人的文风和观点 | -| 成功标准 | 委托方满意，声音不失真 | 读者认可代笔人风格 | -| 交付形式 | 草稿+编辑注释+反馈回路 | 最终稿件 | - -## AI-Era Ghostwriting - -在 AI 辅助代笔写作中，新的挑战在于： -- AI 生成内容倾向通用化、中性化，抹平个人声音差异 -- 需要显式防止"AI腔"渗透到最终内容中 -- 代笔人的角色从"执笔者"转变为"声音架构师+质量把关人" - -## Book Co-Author Context - -在 Book Co-Author Agent 中，Ghostwriting 特指： -- 将创始人的语音笔记、碎片想法转化为结构化章节 -- 保留并保护委托方的声音个性（[[Voice Protection]]） -- 强化而非替代委托方的战略定位（[[Thought Leadership Book]]） -- 显式标注编辑缺口，让委托方参与决策 - -## Related Concepts -- [[Voice Protection]] — 代笔写作的核心质量保证机制 -- [[Thought Leadership Book]] — 代笔的典型应用场景 -- [[First-Person Business Writing]] — 代笔的内容形式 -- [[Narrative Architecture]] — 代笔长篇内容时的架构工作 diff --git a/wiki/concepts/Gift-Economy.md b/wiki/concepts/Gift-Economy.md deleted file mode 100644 index 0e5a6a8e..00000000 --- a/wiki/concepts/Gift-Economy.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Gift Economy" -type: concept -tags: ["anthropology", "economy", "reciprocity", "exchange", "mauss"] -last_updated: 2026-04-25 ---- - -## Definition -礼物经济——基于**互惠义务**（reciprocal obligation）的交换系统，给予、接受、回报的三段循环是社会关系的基础纽带，而非市场竞争。 - -## Core Framework -- **礼物之灵（hau）**：接受礼物即承担回报义务，礼物具有社会性的"灵魂"使回报不可避免 -- **Potlatch**：北太平洋西北岸部落的大型仪式性财富毁坏展示，通过"给予羞辱"来确立社会地位 -- **库拉圈（Kula Ring）**：特罗布里恩群岛的跨岛礼物交换圈，交换的贝壳和项链本身无实用价值，但建立和维持社会关系网络 - -## Key Thinkers -- [[Marcel-Mauss]]（《礼物》作者，奠基人） -- [[Bronislaw-Malinowski]]（库拉圈研究） -- Karl Polanyi（经济人类学） - -## Connections -- [[Anthropologist-Agent]] ← uses_framework ← [[Gift-Economy]] -- [[Polanyi-Exchange]] ← foundational ← [[Gift-Economy]] -- [[Functionalism]] ← grounds ← [[Gift-Economy]] -- [[Social-Cohesion]] ← mechanism ← [[Gift-Economy]] diff --git a/wiki/concepts/GitAsAuditLog.md b/wiki/concepts/GitAsAuditLog.md deleted file mode 100644 index e4fe8b65..00000000 --- a/wiki/concepts/GitAsAuditLog.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Git-as-Audit-Log" -type: concept -tags: [version-control, git, audit, multi-agent] -sources: [autonomous-project-management] -last_updated: 2026-04-22 ---- - -## 定义 -将所有状态变更（包括 [[Shared State Coordination]] 中的 STATE.yaml 变更）作为 Git 提交处理，从而获得完整可追溯的决策和执行历史的方法。 - -## 核心实践 -每次对 STATE.yaml 的修改都触发一个 Git 提交： -```bash -# 状态更新后 -git add STATE.yaml -git commit -m "task(id=xxx): updated status from in_progress to done" -``` - -## 价值 -1. **完整历史追溯**：任意时刻可回滚到任何历史状态 -2. **决策上下文保留**：每次变更的 commit message 即变更理由的记录 -3. **团队协作基础**：多成员可查看、review 状态变更历史 -4. **自动化 CI/CD 集成**：可基于 Git 状态变更触发后续流程 - -## 在 [[autonomous-project-management]] 中的角色 -- 规则明确：All state changes committed to git -- 每个 PM 子 Agent 负责自己 STATE.yaml 的 Git 提交 -- 结合 [[Git-as-Audit-Log]] 和 [[Shared State Coordination]]，实现自文档化的项目协调 - -## Commit Message 约定 -建议格式：`[type](task_id): description` -- `type`: started / updated / completed / blocked / unblocked -- `task_id`: 对应 STATE.yaml 中的任务 ID -- `description`: 变更的具体内容 diff --git a/wiki/concepts/GitHub-Release-Monitoring.md b/wiki/concepts/GitHub-Release-Monitoring.md deleted file mode 100644 index 989adb9d..00000000 --- a/wiki/concepts/GitHub-Release-Monitoring.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "GitHub Release Monitoring" -type: concept -tags: [] ---- - -## Definition -GitHub Release 监控模式——通过 GitHub API 追踪指定仓库的 Release 发布动态，自动获取新版本更新信息并触发通知或工作流。 - -## Implementation -通过 GitHub API `GET /repos/{owner}/{repo}/releases` 获取仓库最新 Release，常见触发条件： -- 新 Release 发布 -- 特定版本号（如 v1.0.0） -- Pre-release 版本 -- Draft 版本 - -## Environment Variables -- `GITHUB_TOKEN` — GitHub 个人访问令牌，提升 API 速率限制（未认证 60 req/hr，认证 5000 req/hr） - -## Use Cases -- [[multi-source-tech-news-digest]] — 监控 vLLM、LangChain、Ollama、Dify 等 19 个热门开源项目 Release -- 开发者依赖更新通知 -- 安全漏洞补丁追踪 - -## Related Concepts -- [[Social-Media-Monitoring]] — 同属账号/项目级变更监控 -- [[Content-Automation]] — 监控到更新后的自动处理 -- [[Daily-Digest]] — 汇总多个仓库更新为每日摘要 diff --git a/wiki/concepts/GitLab-Geo.md b/wiki/concepts/GitLab-Geo.md deleted file mode 100644 index 376b0201..00000000 --- a/wiki/concepts/GitLab-Geo.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "GitLab Geo" -type: concept -tags: [GitLab-Geo, GitLab, Disaster-Recovery, Business-Continuity, Multi-Site, OpenText] -sources: - - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet -last_updated: 2026-05-11 ---- - -## GitLab Geo - -GitLab Geo 是 GitLab 的地理分布式部署方案，支持跨地域数据复制和灾难恢复，是 OpenText Project Thor 业务连续性战略的关键组成部分。 - -## GitLab Geo - -GitLab Geo is GitLab's geo-distributed deployment solution supporting cross-region data replication and disaster recovery, serving as a key component of OpenText's Project Thor business continuity strategy. - -## Aliases -- GitLab Geo -- GitLab Geo Replication - -## Key Facts - -| 维度 | 说明 | -|------|------| -| 部署模式 | 地理分布式多站点 | -| 主站点 | Brook Park（GitLab 主实例） | -| 灾备站点 | Sacramento（业务连续性） | -| 功能 | 源代码仓库跨地域复制、读写分离 | -| 隶属 | [[Project-Thor]] 基础设施层 | - -## 灾难恢复架构 - -``` -Brook Park（主站点） - ↓ GitLab Geo 复制 -Sacramento（灾备站点） -``` - -OpenText 的 GitLab Geo 部署策略： -- 主实例运行在 Brook Park（工具链主站点） -- Sacramento 作为灾难恢复和业务连续性站点 -- 通过 GitLab 内置 Geo 功能实现实时数据同步 - -## Connections - -- [[GitLab-Geo]] ← infrastructure ← [[Project-Thor]] -- [[GitLab-Geo]] ← primary_site ← [[Brook-Park]] -- [[GitLab-Geo]] ← disaster_recovery_site ← [[Sacramento]] -- [[GitLab]] ← provides ← [[GitLab-Geo]]（GitLab 内置功能） -- [[GitLab-Proxy]] ← complements ← [[GitLab-Geo]]（Proxy 管访问，Geo 管复制） - -## Sources - -- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]] diff --git a/wiki/concepts/GitLab-Proxy.md b/wiki/concepts/GitLab-Proxy.md deleted file mode 100644 index ad1a6151..00000000 --- a/wiki/concepts/GitLab-Proxy.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "GitLab Proxy" -type: concept -tags: [GitLab-Proxy, GitLab, Network-Proxy, DevOps, Connectivity, OpenText] -sources: - - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet -last_updated: 2026-05-11 ---- - -## GitLab Proxy - -GitLab Proxy 是 OpenText 在 Brook Park 部署的 GitLab 代理服务，用于解决分布式团队访问源代码的网络连通性问题，是 Project Thor 工具链基础设施的关键组件。 - -## GitLab Proxy - -GitLab Proxy is a proxy service deployed at Brook Park by OpenText to resolve network connectivity issues for distributed teams accessing source code repositories. It is a key infrastructure component of the Project Thor toolchain. - -## Aliases -- GitLab Proxy -- GitLab Proxy Server - -## Key Facts - -| 维度 | 说明 | -|------|------| -| 部署位置 | Brook Park（OpenText 工具链主站点） | -| 功能 | 源代码访问网络代理 | -| 解决的问题 | 分布式团队跨网络的 GitLab 连通性 | -| 隶属 | [[Project-Thor]] 基础设施层 | - -## 使用场景 - -OpenText 工程师遍布多个地理位置，通过 GitLab Proxy 解决： - -- Micro Focus 遗留网络与 OpenText 网络之间的连通性差异 -- 外部网络访问内部 GitLab 仓库的需求 -- 灾难恢复场景下的备份访问路径 - -## Connections - -- [[GitLab-Proxy]] ← infrastructure ← [[Project-Thor]] -- [[GitLab-Proxy]] ← located_at ← [[Brook-Park]] -- [[GitLab]] ← serves ← [[GitLab-Proxy]]（代理 GitLab 访问） -- [[GitLab-Geo]] ← complements ← [[GitLab-Proxy]]（Geo 提供跨地域复制，Proxy 提供访问） - -## Sources - -- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]] diff --git a/wiki/concepts/GitOps.md b/wiki/concepts/GitOps.md deleted file mode 100644 index deddafa8..00000000 --- a/wiki/concepts/GitOps.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: "GitOps" -type: concept -tags: - - GitOps - - IaC - - DevOps - - CD -sources: - - ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments - - ctp-topic-33-an-introduction-to-gitops - - ctp-topic-9-ci-cd-with-gruntwork -last_updated: 2026-04-29 ---- - -# GitOps - -## Definition - -GitOps 是将软件开发原则（尤其是 Git 版本控制）应用于基础设施和应用程序部署的方法论。其核心思想是：**将 Git 仓库作为声明式配置的单一事实来源（Single Source of Truth），通过自动化机制确保实际环境与 Git 中声明的期望状态保持一致。** - -## Core Principles - -1. **Declarative Configuration（声明式配置）** - 所有基础设施和应用配置以声明式语言（如 Terraform HCL、Kubernetes YAML）描述，而非命令式步骤。 - -2. **Version Control（版本控制）** - 所有配置存储在 Git 仓库中，享受版本历史、代码审查（Pull Request）和回滚能力。 - -3. **Automated CD（自动化持续交付）** - CI 专注代码构建和分析，CD 专注部署；两者解耦，增强安全性和可靠性。 - -4. **Self-Healing（自修复协调）** - GitOps Controller 持续监控实际状态与 Git 声明状态，自动调和偏差（drift correction）。 - -## Architecture Patterns - -### Pull Model（推荐） -- GitOps Agent（如 ArgoCD、Flux）同时监控 Git 仓库和目标系统 -- Agent 通过 Pull 方式主动检测变更，无需外部系统推送 -- 安全性更高，符合零信任原则 - -### Push Model -- CI/CD 流水线（如 Jenkins、GitHub Actions）在代码变更后主动推送到目标环境 -- 配置相对简单，但安全性较低 - -## Tooling Ecosystem - -| Tool | Role | Model | -|------|------|-------| -| [[Atlantis]] | Terraform 自动化 Plan/Apply | Pull（PR-based）| -| ArgoCD | Kubernetes 应用部署 | Pull | -| Flux | Kubernetes 持续交付 | Pull | -| Terraform Cloud/Enterprise | Terraform 协作与状态管理 | Hybrid | - -## GitOps vs Traditional CI/CD - -| Dimension | Traditional CI/CD | GitOps | -|-----------|------------------|--------| -| Source of Truth | Pipeline definition | Git repository | -| Trigger | Push to repo | Automated pull + diff detection | -| State Drift Detection | Manual or periodic | Continuous automatic | -| Rollback | Manual or scripted | Git revert + auto-sync | -| Audit Trail | Build logs | Git commit history | -| Security Model | Token-based push | Agent has minimal permissions | - -## Related Concepts -- [[Infrastructure as Code (IaC)]]：GitOps 的核心技术基础 -- [[CI/CD Pipeline]]：GitOps 的前身和组成部分 -- [[Terraform]]：主流 IaC 工具，Atlantis 是其 GitOps 工具 - -## Related Entities -- [[Atlantis]]：Terraform GitOps 的核心工具实现 -- [[Jenkins]]：传统 CI/CD 模式（非 GitOps 原生） - -## Related Sources -- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] — Atlantis 工具实践层 -- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 概念层（Victor Etkin 讲解） -- [[ctp-topic-9-ci-cd-with-gruntwork]] — Gruntwork CI/CD 实践 diff --git a/wiki/concepts/Gitmoji-Commit.md b/wiki/concepts/Gitmoji-Commit.md deleted file mode 100644 index 9766d489..00000000 --- a/wiki/concepts/Gitmoji-Commit.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: "Gitmoji Commit" -type: concept -tags: ["git", "gitmoji", "code-quality"] -last_updated: 2026-04-25 ---- - -## Definition - -Gitmoji Commit 是一种提交规范，使用标准化 Emoji（Gitmoji）作为提交类型的视觉前缀，使开发者能在 git log 中通过 Emoji 快速识别变更意图。 - -## Format - -``` - JIRA-ID: short description -``` - -示例： -- `✨ JIRA-214: add SSO login flow` -- `🐛 JIRA-315: fix token refresh race` -- `♻️ JIRA-522: refactor audit service boundaries` -- `📚 JIRA-623: document API error catalog` -- `🧪 JIRA-724: add session timeout regression tests` -- `🔧 JIRA-811: add branch policy validation` -- `📦 JIRA-902: upgrade GitHub Actions versions` - -## Official Gitmoji Catalog - -| Emoji | 含义 | 使用场景 | -|-------|------|----------| -| ✨ | 新功能 | 新增 agent、catalog 功能 | -| 🐛 | 缺陷修复 | bug fix | -| ♻️ | 重构 | 代码结构优化 | -| 📚 | 文档 | 仅限现有功能/贡献指南的文档更新 | -| 🧪 | 测试 | 测试编写或更新 | -| 💄 | 样式 | UI/样式调整（不改变行为） | -| 🔧 | 配置 | 工作流、CI/CD、配置变更 | -| 📦 | 依赖 | 依赖或平台升级 | -| 🚀 | 部署 | 部署相关变更 | - -## Gitmoji Selection Principle - -> 优先选择反映**实际变更类型**的 Gitmoji，而非个人偏好。 - -特殊情况： -- 为新 agent（全新 catalog 功能）→ 优先使用 `✨` 而非 `📚`（因为 Gitmoji 将 `✨` 定义为新功能） -- 仅更新现有 agent 文档或贡献指南 → 使用 `📚` - -## Automated Validation - -通过 commit-msg hook 自动验证格式： - -```bash -commit_regex='^(🚀|✨|🐛|♻️|📚|🧪|💄|🔧|📦) [A-Z]+-[0-9]+: .+$' -``` - -不符合格式的提交将被拒绝。 - -## Official References - -- Primary: [gitmoji.dev](https://gitmoji.dev/) -- Source of truth: [github.com/carloscuesta/gitmoji](https://github.com/carloscuesta/gitmoji) - -## Sources -- [[project-management-jira-workflow-steward]] diff --git a/wiki/concepts/Global-First-Architecture.md b/wiki/concepts/Global-First-Architecture.md deleted file mode 100644 index 6c25d68b..00000000 --- a/wiki/concepts/Global-First-Architecture.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Global-First Architecture" -type: concept -tags: [internationalization, i18n, architecture, ux-design] -sources: [specialized-cultural-intelligence-strategist] -last_updated: 2026-04-25 ---- - -## Definition -将国际化（Internationalization, i18n）和本地化（Localization, l10n）作为产品架构的先天前提条件，而非上线后的补救措施。这一设计哲学主张：从系统设计的第一天起，就假设产品将在多元文化环境中运行。 - -## Key Dimensions - -### 1. Data Architecture -- **命名**：不接受固定结构的姓名字段 → 使用 `fullName` 或 `preferredName` -- **日期/时间**：存储为 Unix timestamp 或 ISO 8601 → 按用户 locale 渲染 -- **货币**：存储为最低单位整数（如 cents）→ 按用户 locale 渲染货币符号 -- **地址**：不使用固定字段组合 → 使用结构化 key-value 对 - -### 2. UI Architecture -- **RTL 支持**：CSS `direction: rtl` 作为默认模板变量 -- **文本扩展**：按钮/标签预留 300% 宽度余量（德语等语言比英语长 30%+） -- **图标语义**：颜色不作为唯一语义载体（配合图标或文字） -- **日历系统**：支持 Gregorian / Hijri / Hebrew / Chinese / Buddhist 等多历法 - -### 3. Content Architecture -- **翻译层**：字符串 ID 而非硬编码文本 -- **文化适配**：图像/颜色/图标按 locale 分组替换 -- **A/B 测试**：文化分组作为实验维度 - -## Why "Global-First" vs "Localization Afterthought"? -| 维度 | 亡羊补牢式本地化 | Global-First | -|------|---------------|------------| -| 成本 | 高（后期重构 UI 和数据模型） | 低（架构内建） | -| 用户体验 | 补丁感强，一致性差 | 原生感强 | -| 可维护性 | 每次更新需同步修改所有 locale | 单次架构变更自动覆盖所有市场 | -| 技术债务 | 快速积累 | 从根本上避免 | - -## Relationship to Other Concepts -- [[Invisible-Exclusion]]：Global-First Architecture 要解决的首要问题 -- [[Architectural Empathy]]：Global-First Architecture 的设计哲学基础 -- [[Cultural-Intelligence]]：Global-First Architecture 所需的知识基础 diff --git a/wiki/concepts/Global-Information-Security-Policy-GISP.md b/wiki/concepts/Global-Information-Security-Policy-GISP.md deleted file mode 100644 index 540e5204..00000000 --- a/wiki/concepts/Global-Information-Security-Policy-GISP.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Global Information Security Policy (GISP)" -type: concept -tags: - - OpenText - - Security-Policy - - Governance -last_updated: 2026-04-14 ---- - -# Global Information Security Policy (GISP) - -## Definition -OpenText 的最高纲领性安全政策，是所有其他安全政策的根基。GISP 由全球信息安全团队（GIS）制定和支持，定期（每季度）接受领导层审查。 - -## Scope -- 定义企业"需要做什么"（what），同时为"如何实施"（how）提供灵活性 -- 支持性政策（Supporting Policies）围绕 GISP 构建 -- 鼓励反馈以实现持续改进 - -## Relationship to Other Concepts -- 基于 [[ISO-27001]] 姿态框架 -- 与 [[Security-Awareness-Training]] 配合提升全员安全意识 -- 与 [[Third-Party-Penetration-Testing]] 配合验证政策有效性 - -## Key Quote -> "Policies define what needs to be done, while providing flexibility for how it is implemented." — GIS Policy Framework - -## Connections -- [[Global Information Security Team (GIS)]]：制定与维护团队 -- [[ISO-27001]]：框架基础 -- [[OpenText]]：所属组织 diff --git a/wiki/concepts/Go-to-Market-Brief.md b/wiki/concepts/Go-to-Market-Brief.md deleted file mode 100644 index ba4384cf..00000000 --- a/wiki/concepts/Go-to-Market-Brief.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Go-to-Market (GTM) Brief" -type: concept -tags: ["product-management", "launch", "gtm", "marketing"] -last_updated: 2026-04-30 ---- - -## Aliases -- GTM Brief -- Go-to-Market Plan -- 发布计划 -- 市场推广计划 - -## Definition -Go-to-Market Brief（市场推广计划）—— 在产品功能正式发布（GA）前，由产品经理主导制定的跨部门协调文档，定义目标受众、价值主张、发布渠道、团队职责和成功标准，确保工程、产品、营销、销售和客服团队在发布前完成准备工作。 - -## Core Components -1. **发布什么**（What We're Launching）：一句话 + 一段描述 -2. **目标受众**（Target Audience）：按细分市场划分（首要/次要/扩展），含规模、价值主张和触达渠道 -3. **核心价值主张**（Core Value Proposition）：单行标语 + 按受众分组的差异化信息 -4. **发布检查清单**（Launch Checklist）：按工程/产品/营销/销售 CS 分组 -5. **成功标准**（Success Criteria）：按时间窗口（发布日/7天/30天/60天/90天）定义的指标表格 -6. **回滚与应急预案**（Rollback & Contingency）：回滚触发条件、负责人、沟通计划 - -## Key Principles -- **发布前客服和 CS 必须完成培训** —— 正式上线前，不是上线当天 -- **先写回滚手册，再开开关** —— 在功能标志翻转前，rollback runbook 必须完成 -- **发布后头两周每日监控** —— 设定异常阈值并主动响应 - -## Usage -由 [[Product Manager Agent]] 产出，跨越工程、营销、销售、客服四个部门。GTM Brief 是 [[Product Requirements Document (PRD)]] 的下游文档——PRD 解决"做什么和为什么"，GTM Brief 解决"如何发布和谁来做什么"。 - -## Related -- [[Product Requirements Document (PRD)]] — GTM Brief 的上游输入 -- [[Product Manager Agent]] — GTM Brief 的主导者 -- [[Product Roadmap (Now/Next/Later)]] — GA 阶段的Initiative来源 diff --git a/wiki/concepts/Golden-3-Second-Hook.md b/wiki/concepts/Golden-3-Second-Hook.md deleted file mode 100644 index d4b8c112..00000000 --- a/wiki/concepts/Golden-3-Second-Hook.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Golden 3-Second Hook（黄金3秒钩子）" -type: concept -tags: [short-video, copywriting, attention-economy, douyin] -sources: [marketing-douyin-strategist] -last_updated: 2026-04-25 ---- - -## Definition -黄金3秒钩子是指短视频开头3秒内通过特定的创作技巧，在算法推荐之前就抓住观众注意力的开场设计策略。是抖音/短视频完播率优化的第一道关卡。 - -## Four Hook Types - -### A. 冲突型（Conflict Hook） -**公式**："除非你看完这个，否则不要做XXX" -**原理**：制造认知冲突，触发好奇心 -**示例**："买二手房之前没看这个视频，你亏大了" - -### B. 价值型（Value Hook） -**公式**："XX元解决了困扰我X年的问题" -**原理**：具体数字锚定价值感 -**示例**："花200块解决了困扰我三年的失眠问题" - -### C. 悬念型（Suspense Hook） -**公式**："XX行业有一个他们不想让你知道的秘密" -**原理**：信息不对称引发窥探欲 -**示例**："服装店老板打死不会告诉你的砍价技巧" - -### D. 共鸣型（Relatability Hook） -**公式**："有没有人和我一样，每次XXX就崩溃？" -**原理**：情感共鸣触发评论互动 -**示例**："有没有人和我一样，一刷手机就停不下来" - -## Relationship to Completion Rate -- 钩子决定前三秒留存 -- 前三秒留存影响算法初始流量池评级 -- 初始评级决定是否进入更大的流量池 -- **因此：钩子质量决定整条视频的天花板** - -## Key Metrics -- 前3秒跳出率（< 20% 为优秀） -- 5秒完播率（> 50% 为优秀） -- 与整体完播率正相关 - -## Related Concepts -- [[CompletionRateOptimization]]：黄金钩子是完播率优化的核心组成部分 -- [[ContentMatrixStrategy]]：不同内容类型适用不同钩子策略 -- [[VideoPacing]]：钩子之后的内容节奏同样关键 - -## Aliases -- 黄金3秒 -- 开头钩子 -- Hook -- Attention Hook -- 短视频开场策略 diff --git a/wiki/concepts/Grandes-Ecoles.md b/wiki/concepts/Grandes-Ecoles.md deleted file mode 100644 index fde0b9c8..00000000 --- a/wiki/concepts/Grandes-Ecoles.md +++ /dev/null @@ -1,67 +0,0 @@ -# Grandes Écoles - -## Definition - -Grandes Écoles（精英大学/大学校）——法国独有的精英高等教育体系，与公立大学（Université）并行，属于法国高等教育二元结构中的"精英"通道。源自拿破仑时期建立的专科学校体系，旨在为法国政府和企业培养高级人才。 - -## Tier Structure - -### Tier 1: 最顶尖（历史最悠久、最难进入） -| 学校 | 特色 | -|------|------| -| École Polytechnique（巴黎综合理工/X） | 科学与工程基础，强基研究导向 | -| École Normale Supérieure（巴黎高师/ENS） | 文理基础研究，人文科学顶尖 | -| ENA（已关闭，继承者：INSP） | 公共管理，法国高级公务员摇篮 | - -### Tier 2: 商学院（Grande École de Commerce） -- **HEC Paris**：欧洲排名第一商学院，MIM 项目（管理学硕士） -- ESSEC Business School、ESCP Business School、EDHEC Business School -- 申请方式：GMAT + 学术背景 + 面试 - -### Tier 3: 工程师学校（Grande École d'Ingénieur） -- 覆盖各工程领域：机械、电子、核能、土木、计算机等 -- 认证：CTI（工程师职称委员会）认证保证教学质量 - -## Admission Pathways - -### 法国学生路径 -1. **Concours（竞考）**：法国学生进入 Grande École 的主要方式，需在预科班（CPGE/MP2I/ECS 等）学习 2-3 年后参加统一竞考 -2. **Parcoursup**：部分学校通过法国公立高等教育申请系统招生 - -### 国际学生路径 -1. **直接申请**：顶尖学校（HEC、X、ENS）接受国际学生直接申请，通常需： - - 优秀学术成绩（985/211 优先） - - 法语 B2-C1 或英语授课项目（IELTS 7.0+） - - GMAT/TAGE-MAGE（商学院）、GRE/法方笔试（工程师） - - 面试 -2. **IFER/IPEP 预科**：部分学校设有国际学生预科项目 -3. **合作院校项目**：与国内 985/211 大学的双学位/交换项目 - -## Tuition & Cost - -| 类型 | 学费范围 | 备注 | -|------|----------|------| -| 公立工程师学校 | 免学费（仅注册费约 500-800 欧/年） | 法国政府补贴 | -| 私立商学院 | 1.5-4 万欧/年 | 部分有奖学金 | -| 英语授课项目 | 通常高于法语项目 | 成本较高 | - -## VS 英国/美国 System - -| 维度 | Grandes Écoles | 英美精英大学 | -|------|----------------|-------------| -| 学制 | 5 年一贯制（工程师）或 2 年硕士 | 4 年本科 + 2-5 年研究生 | -| 录取核心 | 竞考/学术竞争 | 全面评估（美）/学术+PS（英） | -| 学费 | 公立学校免学费 | 学费较高（英国约 2-4 万磅/年） | -| 校友网络 | 法国政商精英核心圈 | 英美各有强大校友网络 | -| 知名度（国内） | 相对小众 | 普遍更高 | - -## Relationship to Study Abroad Planning - -[[study-abroad-advisor]] 在欧洲留学方向中，Grandes Écoles 是法国留学的核心选项。相比英美，公立 Grande École 的**免学费**政策使其成为高性价比的精英教育路径，尤其适合工科背景学生。关键挑战：法语能力要求（除非选择英语授课项目）+ 竞考体系对国际学生的壁垒。典型推荐：数学/物理/工程背景学生可考虑 Polytechnique（X）、索邦大学工程师项目。 - -## Aliases -- 法国精英大学 -- 大学校 -- French Elite Universities -- French Grande École System -- 大学校体系 diff --git a/wiki/concepts/Graph-View.md b/wiki/concepts/Graph-View.md deleted file mode 100644 index 79eddd64..00000000 --- a/wiki/concepts/Graph-View.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Graph View" -type: concept -tags: [tool, obsidian, visualization] -sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环, llm-wiki] -last_updated: 2026-04-20 ---- - -## Aliases -- Obsidian Graph View -- 图谱视图 - -## Definition -Obsidian 内置的可视化工具，将所有 Wiki 页面以节点形式展示，页面之间的双向链接关系自动连线。是 LLM Wiki 健康检查和知识结构发现的核心工具。 - -## Access -- 左侧边栏点击图谱图标 -- 快捷键：Ctrl+G（Windows）/ Cmd+G（Mac） - -## LLM Wiki Use Cases - -### 1. Lint 健康检查 -通过图谱视图**一眼看出哪些页面是孤岛**——没有任何其他页面通过双链指向它。说明交叉引用缺失，需要让 AI 补上链接。 - -### 2. 发现知识盲区 -如果某个概念被很多页面提到，但**自己没有独立页面**，它在图谱里会显示为**灰色的幽灵节点**。这提醒你应该让 AI 为它创建专页。 - -## Graph as IDE Debugger -**"Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库"**——Graph View 就是 Wiki 的调试工具，帮助发现缺失的链接和页面。 - -## Connections -- [[Graph View]] ← 可视化工具 ← [[LLM Wiki]] -- [[Graph View]] ← 内置功能 → [[Obsidian]] diff --git a/wiki/concepts/Graviton.md b/wiki/concepts/Graviton.md deleted file mode 100644 index 8d4252c8..00000000 --- a/wiki/concepts/Graviton.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "Graviton" -type: concept -tags: - - AWS - - Cost-Optimization - - ARM -aliases: - - Graviton - - Graviton ARM - - AWS Graviton -last_updated: 2026-05-12 ---- - -## Overview - -Graviton 是 AWS 基于 ARM 架构自研的处理器，相比 Intel/AMD x86 实例提供更高的性价比（最高 40%）和更低的功耗（减少高达 60%）。 - -## Benefits - -- **成本更低**：相比同等配置 Intel 实例便宜 20-25% -- **能效更高**：功耗显著降低 -- **性能提升**：对于支持 ARM 的工作负载性能更好 - -## Instance Types - -- **M系列**：通用型（M6g/M7g） -- **T系列**：突发性（T4g） -- **C系列**：计算型（C6g/C7g） -- **R系列**：内存优化（R6g/R7g） -- **X系列**：内存优化（X2gd） - -## Compatibility - -适用于大多数工作负载： -- Web 服务 -- 容器化应用（EKS/ECS） -- 大数据处理 -- CI/CD 构建 -- 机器学习推理 - -排除场景： -- 有状态服务（某些数据库） -- 需要特定 x86 指令的应用 -- Windows 工作负载 - -## Related Pages - -- [[FinOps]] -- [[SpotInstances]] -- [[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]]：Mike Dukes 和 Steele Taylor 详解 Graviton 性价比优势（40% 提升）和能耗优势（60% 降低） -- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] -- [[ctp-topic-63-optimise-resource-cost-using-automation]] diff --git a/wiki/concepts/Green-Computing.md b/wiki/concepts/Green-Computing.md deleted file mode 100644 index d3559c6e..00000000 --- a/wiki/concepts/Green-Computing.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: "Green Computing" -type: concept -tags: [Cloud, Sustainability, Environmental, Cloud Operations] -sources: [cloud-operating-model-key-strategies-and-best-practices] -date: 2026-04-26 ---- - -# Green Computing (绿色计算) - -## Definition -**Green Computing** refers to environmentally sustainable computing practices that reduce energy consumption, minimize carbon footprint, and promote eco-friendly technology usage in data centers and cloud environments. - -## Why It Matters - -### Environmental Impact -- **Data centers consume 1% of global electricity** — a number expected to rise (International Energy Agency) -- Growing cloud infrastructure increases energy demands -- Regulatory bodies pressuring organizations for sustainable solutions - -### Business Benefits -- Reduce operational costs through energy efficiency -- Meet corporate sustainability goals -- Comply with environmental regulations -- Enhance brand reputation - -## Key Strategies - -### 1. Serverless Computing -- Eliminates unnecessary resource consumption -- Pay-only-for-execution model -- Automatic resource optimization - -### 2. Sustainable Data Centers -- Major providers investing in carbon-neutral infrastructure -- AWS, Azure, and Google Cloud commitment to renewable energy -- Efficient cooling and power systems - -### 3. Workload Optimization -- Shift workloads to energy-efficient regions -- Right-size resources to actual needs -- Schedule non-critical workloads for off-peak times - -### 4. Cloud Sustainability Tools -- Carbon footprint tracking -- Energy efficiency dashboards -- Resource usage optimization - -## Industry Trends - -### Cloud Provider Commitments -- **AWS**: Carbon-neutral by 2040 -- **Microsoft Azure**: Carbon-negative by 2030 -- **Google Cloud**: Carbon-free by 2030 - -### Regulatory Pressures -- Corporate sustainability mandates -- Environmental reporting requirements -- Carbon tax implications - -## Relationship to Cloud Operating Model -- Green Computing is an emerging pillar of modern [[Cloud Operating Model]] -- 8% of organizations now prioritize sustainability in cloud adoption -- Part of future trends in cloud management - -## Related Concepts -- [[Cloud Operating Model]] -- [[Serverless Computing]] -- [[Cloud Cost Optimization]] -- [[Multi-Cloud Strategy]] - -## Related Entities -- [[AWS]] -- [[Azure]] -- [[Google-Cloud]] diff --git a/wiki/concepts/Grey-Box-Blockout.md b/wiki/concepts/Grey-Box-Blockout.md deleted file mode 100644 index 11c4f212..00000000 --- a/wiki/concepts/Grey-Box-Blockout.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: "Grey Box Blockout" -type: concept -tags: ["game-design", "level-design", "prototyping", "design-validation", "playtest"] -sources: ["level-designer.md"] -last_updated: 2026-05-07 ---- - -## Definition - -Grey Box Blockout（灰盒原型阶段）是关卡设计三阶段交付模式的第一阶段——使用未贴图几何体（灰盒）快速构建关卡原型，通过早期 Playtest 验证布局可读性、节奏控制和遭遇战平衡。**核心纪律：所有设计决策在灰盒阶段锁定，美术美化零例外必须先通过灰盒测试**。 - -## Three-Phase Delivery Model - -### Phase 1: Grey Box（灰盒） -- 仅用未贴图几何体（纯色方块、简单坡道）构建关卡 -- **立即 Playtest**：如果灰盒不可读，艺术美化无法修复它 -- 验证：玩家能否无需地图导航关键路径？ - -### Phase 2: Dress（美术） -- 美术团队在灰盒验证后的几何体上添加材质、道具、细节 -- 美术人员必须遵守灰盒阶段锁定的布局，不得改变核心几何 - -### Phase 3: Polish（打磨） -- 特效、音效、灯光微调 -- 最终 Playtest 验证 -- 性能优化 - -## Blockout Specification Template - -每个 Room/区域需要记录： - -```markdown -## Room: [ID] — [Name] - -**Dimensions**: ~[W]m × [D]m × [H]m -**Primary Function**: Combat / Traversal / Story / Reward - -**Cover Objects**: -- 2× low cover (waist height) — center cluster -- 1× destructible pillar — left flank -- 1× elevated position — rear right (accessible via crate stack) - -**Lighting**: -- Primary: warm directional from [direction] — guides eye toward exit -- Secondary: cool fill from windows — contrast for readability -- Accent: flickering [color] on objective marker - -**Entry/Exit**: -- Entry: [Door type, visibility on entry] -- Exit: [Visible from entry? Y/N — if N, why?] - -**Environmental Story Beat**: -[What does this room's prop placement tell the player about the world?] -``` - -## Key Metrics - -- 灰盒阶段关键路径可读性：100% 测试玩家无需询问方向即可导航 -- 灰盒阶段遭遇战：每个战斗至少 2 种可行战术路径在灰盒中验证 -- 灰盒阶段节奏：Pacing Chart 与实际测试时间偏差 < 20% - -## Connections - -- [[Level Designer]] 执行 Grey Box Blockout 作为六阶段工作流的核心步骤 -- [[Navigation Affordance]] 在灰盒阶段验证关键路径视觉可读性 -- [[Encounter Design]] 在灰盒阶段单独测试每个遭遇战 -- [[Technical Artist]] 在灰盒阶段完成时接收 Art Pass Handoff 文档 -- [[Pacing Chart]] 在灰盒阶段通过 Playtest 验证时间偏差 < 20% diff --git a/wiki/concepts/Groupthink.md b/wiki/concepts/Groupthink.md deleted file mode 100644 index c83d0cae..00000000 --- a/wiki/concepts/Groupthink.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Groupthink" -type: concept -tags: [] -sources: [academic-psychologist] -last_updated: 2026-04-25 ---- - -# Groupthink - -## Aliases -- Groupthink (Janis) -- Collective Thinking Defects - -## Definition -Janis 群体思维——高凝聚力群体在追求一致性的压力下，进行非理性决策的心理现象，导致批判性思维和替代方案评估能力的丧失。 - -## Symptoms (Janis's 8 Symptoms) - -1. **Illusion of Invulnerability**（无懈可击的错觉）：群体过度自信 -2. **Collective Rationalization**（集体合理化）：忽视警告，自我合理化 -3. **Belief in Inherent Morality**（固有道德信念）：相信自身动机正确 -4. **Pressure on Dissenters**（对异议者施压）：压制不同意见 -5. **Self-Censorship**（自我审查）：成员隐藏真实想法 -6. **Illusion of Unanimity**（一致性的错觉**：沉默被视为同意 -7. **Mindguards**（心理卫兵）：有人阻止异议者发言 -8. **Direct Mind Guarding**（直接的心理防护）：领导公开压制异议 - -## Remedies -- 群体领导者应保持中立 -- 鼓励批评性评估 -- 分小组独立讨论后汇总 -- 邀请外部专家参与 - -## Application in Character Design -Psychologist Agent 使用此框架分析群体决策场景，识别群体动态如何导致非理性行为（如暴民心理、去个性化）。 - -## Connection to Wiki -- Source: [[academic-psychologist]] diff --git a/wiki/concepts/Growth-Loop.md b/wiki/concepts/Growth-Loop.md deleted file mode 100644 index 117dcf63..00000000 --- a/wiki/concepts/Growth-Loop.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Growth Loop" -type: concept -tags: [growth, product, go-to-market, viral] -last_updated: 2026-03-05 ---- - -## Definition - -增长飞轮（Growth Loop）——产品内生的自我强化增长机制，用户行为直接产生新用户的引入，而非依赖外部广告或营销渠道。 - -由 [[nexus-spatial-discovery]] 中 [[Growth-Hacker]] 设计 4 大增长飞轮。 - -## The 4 Nexus Spatial Growth Loops - -### 1. "Wow Factor" Demo Loop - -**机制**：空间演示天然可分享。一键"Share Spatial Preview"生成 WebXR 链接或视频。 -**目标 K-factor**：0.3-0.5 -**核心洞察**：空间计算的分享性（immersive demos are inherently shareable） - -### 2. Template Marketplace - -**机制**：高级用户发布管道模板，可通过搜索发现，引流新注册 -**核心洞察**：用户既是消费者也是创造者，内容自增长 - -### 3. Collaboration Seat Expansion - -**机制**：一个工程师采用 → 分享给队友 → 团队扩展到付费计划（Slack/Figma 增长模式） -**核心洞察**：协作工具的网络效应 - -### 4. Integration-Driven Discovery - -**机制**：在 LangChain、n8n、OpenAI/Anthropic 合作伙伴目录中列出 -**核心洞察**：嵌入用户已有工作流，成为默认选择 - -## Growth Loop vs Traditional Acquisition - -| | Growth Loop | Traditional Acquisition | -|--|------------|----------------------| -| 依赖 | 产品内生 | 外部渠道 | -| 规模效应 | 越用越强 | 边际递减 | -| 成本 | 递减 | 递增 | -| 可持续性 | 高 | 低 | - -## Related Concepts - -- [[Nexus-Spatial]]：Growth Loop 的应用场景 -- [[SpatialAIOps]]：空间分享性是"Wow Factor"飞轮的基础 diff --git a/wiki/concepts/GrowthFunnelOptimization.md b/wiki/concepts/GrowthFunnelOptimization.md deleted file mode 100644 index 59f9f374..00000000 --- a/wiki/concepts/GrowthFunnelOptimization.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Growth Funnel Optimization" -type: concept -tags: ["growth", "funnel", "conversion", "retention"] -last_updated: 2026-04-26 ---- - -## Definition -增长漏斗优化——对用户从认知（Awareness）到推荐（Referral）的全链路转化率进行系统性提升的策略框架。每个阶段都有独立的流失率监控和优化机制。 - -## Framework -1. **Awareness（认知）**：用户首次接触品牌 -2. **Acquisition（获客）**：用户完成注册/下载等转化动作 -3. **Activation（激活）**：用户体验到产品核心价值 -4. **Retention（留存）**：用户持续使用产品 -5. **Revenue（收入）**：用户完成付费 -6. **Referral（推荐）**：用户主动向他人推荐 - -## Source -- [[marketing-growth-hacker]]（Marketing Growth Hacker Agent） diff --git a/wiki/concepts/Guest-Journey.md b/wiki/concepts/Guest-Journey.md deleted file mode 100644 index 06a4ad39..00000000 --- a/wiki/concepts/Guest-Journey.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: "Guest Journey" -type: concept -tags: [] -sources: - - hospitality-guest-services -last_updated: 2026-05-02 ---- - -## Definition -Guest Journey（宾客旅程）是宾客从首次接触品牌到退房后持续互动全过程的阶段模型。每个阶段都有独特的宾客需求、预期和关键时刻（Moment of Truth），宾客服务必须针对每一阶段进行精心设计。 - -## Full Guest Journey Stages - -### 1. Reservations（预订） -**核心任务**：确认所有信息准确，特殊需求已记录，特殊场合已标记 -- 预订、修改、取消、团队预订 -- 识别特殊场合（生日/周年纪念/蜜月/VIP） -- 升级机会评估 - -**关键指标**：预订完成率、修改/取消率 - -### 2. Pre-Arrival（预到达） -**核心任务**：入住前48小时的个性化触达，提前解决问题，创造期待感 -- 发送预到达邮件/消息 -- 确认特殊请求 -- 在线值机+数字钥匙引导 -- 提前识别升级机会 - -**关键指标**：预到达消息打开率、在线值机完成率 - -### 3. Check-In（入住） -**核心任务**：30秒内问候、忠诚身份识别、房间分配与特色介绍 -- 30秒内问候（by name if known） -- 每次入住都认可忠诚会员身份 -- 确认并超越特殊请求 -- 分配最佳可用房间（有升级则主动提供） -- 简洁实用的设施介绍 - -**关键时刻**：首次问候、房间介绍、退房时 - -### 4. In-Stay（住店期间） -**核心任务**：满足需求、主动推荐、即时处理投诉 -- 礼宾服务（餐饮预订、本地推荐、交通安排） -- 投诉渠道监测（当面/电话/App/OTA消息） -- 投诉立即处理（见 [[HEARD Method]]） -- 多晚入住宾客入住第二天主动致电/消息关怀 -- 特殊场合惊喜安排 - -**关键时刻**：礼宾请求完成、投诉解决 - -### 5. Complaint Resolution（投诉处理） -**核心任务**：见 [[Service Recovery Protocol]] -- 立即倾听，不打断 -- 真诚共情，诚挚道歉 -- 即时解决 -- 超越期望补偿 -- 主动跟进 - -### 6. Check-Out（退房） -**核心任务**：温暖告别、账单审核、积分确认、离店反馈 -- 姓名问候，温暖送别 -- 主动审核账单，解决疑问 -- 确认忠诚积分到账时间 -- 退房前收集反馈 -- 邀请再次光临 - -**关键时刻**：退房问候、账单确认 - -### 7. Post-Stay（售后） -**核心任务**：感谢、请求点评、监测平台、处理差评 -- 24小时内感谢邮件+调查链接 -- 监测 OTA 平台（TripAdvisor/Booking.com/Google） -- 48小时内响应所有点评 -- 差评私下跟进，争取修改评分 -- 流失宾客赢回沟通 - -**关键指标**：调查回复率、在线评分变化、赢回率 - -### 8. Events & Groups（活动与团队） -跨阶段并行存在，为会议/婚礼/团队活动提供专项服务 -- 活动协调 -- F&B 规划 -- AV 要求 -- 团队账单管理 - -## Connections -- [[Hospitality Guest Services]] ← Guest Journey 是宾客服务 Agent 的核心操作框架 -- [[HEARD Method]] ← 贯穿投诉处理阶段的处理框架 -- [[Service Recovery Protocol]] ← 住店阶段服务失误的恢复流程 -- [[Loyalty Program Management]] ← 贯穿全旅程的会员识别和奖励 -- [[Review Management]] ← 退房和售后阶段的口碑管理 - -## Aliases -- 宾客旅程 -- Customer Journey -- Guest Experience Journey -- Guest Lifecycle diff --git a/wiki/concepts/HCX.md b/wiki/concepts/HCX.md deleted file mode 100644 index 777020f1..00000000 --- a/wiki/concepts/HCX.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Hybrid Cloud Extension (HCX)" -type: concept -tags: - - VMware - - Hybrid-Cloud - - Migration -last_updated: 2026-04-25 ---- - -## Hybrid Cloud Extension (HCX) - -VMware's hybrid cloud extension technology that enables any-to-any vSphere workload migration between on-premises and cloud environments. - -## Definition -HCX enables bidirectional workload migration between any vSphere environments, supporting seamless movement of applications between on-premises data centers and VMware Cloud on AWS. - -## Key Features -- **Any-to-Any Migration**: Migrate workloads between any vSphere environments -- **Bidirectional**: Supports migration in both directions (on-prem → cloud and cloud → on-prem) -- **Fast Migration**: Workloads can move in seconds -- **No Re-architecture Required**: Applications can migrate without code changes - -## Use Cases -- Cloud migration -- Disaster recovery -- Bursting to cloud -- Data center evacuation -- Cloud repatriation - -## Connections -- [[VMware-Cloud-on-AWS]] ← enables ← [[HCX]] -- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[HCX]] -- [[ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm]] ← related_to ← [[HCX]] - -## Sources -- [[ctp-topic-43-vmware-cloud-on-aws]] diff --git a/wiki/concepts/HDRP.md b/wiki/concepts/HDRP.md deleted file mode 100644 index 78e6b5bc..00000000 --- a/wiki/concepts/HDRP.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: "HDRP (High Definition Render Pipeline)" -type: concept -tags: [game-dev, rendering, unity, pipeline] -sources: [unity-shader-graph-artist] -last_updated: 2026-05-01 ---- - -## Aliases -- High Definition Render Pipeline -- HDRP -- HD Render Pipeline - -## Definition - -HDRP（High Definition Render Pipeline，高清渲染管线）是 Unity 的高端渲染管线，专为 PC 和 Console（PlayStation、Xbox）的高视觉质量项目设计。HDRP 提供物理光照模型、光线追踪支持、体积雾、屏幕空间环境遮蔽等 AAA 级渲染特性。相比 URP，HDRP 的渲染质量更高，但不支持移动端，且自定义通道 API 与 URP 不兼容。 - -## Core Architecture - -### CustomPass 系统 -HDRP 自定义通道的核心扩展点： - -```csharp -// HDRP 必须使用 CustomPassVolume + CustomPass -// 与 URP 的 ScriptableRendererFeature API 不兼容 -public class MyCustomPass : CustomPass -{ - protected override void Execute(ScriptableRenderContext context, CommandBuffer cmd, PassData passData, - ref RenderingData renderingData) - { /* HDRP 自定义渲染逻辑 */ } -} -``` - -### 关键约束 -- **禁止使用** `OnRenderImage`（Built-in only） -- **禁止使用** URP 的 `ScriptableRendererFeature`（API 不兼容） -- HDRP 不支持移动端部署 -- Shader Graph 必须设置正确的 HDRP Render Pipeline Asset -- HDRP 图形无法直接在 URP 中工作，需要反向 Porting - -### 与 URP 的核心区别 - -| 特性 | HDRP | URP | -|------|------|-----| -| 目标平台 | PC/Console（高端） | PC/Console/Mobile/VR | -| 渲染质量 | 极高（光线追踪/物理光照） | 中等-高 | -| 自定义通道 API | `CustomPassVolume` | `ScriptableRendererFeature` | -| API 兼容性 | **不兼容** URP | **不兼容** HDRP | -| 移动端支持 | ❌ 不支持 | ✅ 支持 | - -## Shader Graph in HDRP - -- Shader Graph 支持 HDRP 的物理光照模型（Lit Shader） -- Substrate 多层材质（UE5.3+ 替代 SSS workaround） -- 必须使用 Sub-Graph 封装可复用逻辑 -- HDRP 的 Shader Graph 资产需要显式 Porting 才能在 URP 项目中使用 - -## Performance - -HDRP 主要面向 PC/Console 平台，移动端不是其目标场景。但仍建议在 Frame Debugger 中审计每个 Shader 的实际 GPU 开销。 - -## Connections -- [[Shader]] ← 渲染目标 ← HDRP -- [[UnityShaderGraphArtist]] ← 专精 ← HDRP -- [[URP]] ← 互补管线 ← HDRP（不兼容） -- [[CustomPass]] ← 核心 API ← HDRP -- [[CustomPassVolume]] ← 扩展机制 ← HDRP diff --git a/wiki/concepts/HEARD-Method.md b/wiki/concepts/HEARD-Method.md deleted file mode 100644 index 10d23119..00000000 --- a/wiki/concepts/HEARD-Method.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "HEARD Method" -type: concept -tags: [] -sources: - - hospitality-guest-services -last_updated: 2026-05-02 ---- - -## Definition -HEARD Method 是酒店及综合款待业投诉处理的标准五步框架，用于将愤怒的宾客体验转化为五星好评机会。五个步骤首字母缩写为 HEARD： - -- **H — Hear**：完整倾听宾客，不打断 -- **E — Empathize**：真诚共情，"我完全理解您为什么感到沮丧" -- **A — Apologize**：诚挚道歉，承认具体问题而非泛泛的"不便" -- **R — Resolve**：即时解决，在问题发生地立即采取行动 -- **D — Delight**：超越期望的补偿，超出宾客预期 - -## Core Principles -- **Every complaint is a gift**：愿意投诉的宾客说明仍相信你能补救；不投诉直接离开的宾客永远流失 -- **延迟响应翻倍负面 impact**：服务失误必须立即处理，不可在退房时或次日才响应 -- **具体道歉优于通用道歉**：永远不要用"I apologize for any inconvenience"这类空洞表达 - -## Severity-Based Recovery Actions -| 等级 | 场景 | 补偿方案示例 | -|------|------|-------------| -| 🟢 Minor | 轻微不便 | 真诚道歉 + 小礼物（水果/甜点/积分） | -| 🟡 Moderate | 服务失误 | 道歉 + 房间 amenity + 积分/折扣 | -| 🔴 Major | 严重失误 | 道歉 + 重大补偿 + 经理跟进 | -| 🚨 Severe | 安全/紧急 | 道歉 + 免费房晚 + 总经理联系方式 | - -## Connections -- [[Service Recovery Protocol]] ← 应用 HEARD Method 的标准化投诉处理流程 -- [[Hospitality Guest Services]] ← HEARD Method 是宾客服务 Agent 的核心技能之一 -- [[Review Management]] ← HEARD 有效执行可将差评转化为好评 - -## Aliases -- HEARD Complaint Resolution -- HEARD Service Recovery -- 五步投诉处理法 diff --git a/wiki/concepts/HTTP-ChatCompletions.md b/wiki/concepts/HTTP-ChatCompletions.md deleted file mode 100644 index 7518e591..00000000 --- a/wiki/concepts/HTTP-ChatCompletions.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "HTTP-ChatCompletions" -type: concept -tags: [] ---- - -## Definition -HTTP-ChatCompletions 是通过 HTTP 协议调用 AI 模型 Chat Completions 接口的模式，是 [[OpenAI-Compatible-API]] 的底层传输机制。 - -## Architecture -``` -Client (n8n HTTP Request) - │ - ▼ -POST /v1/chat/completions -Content-Type: application/json -Authorization: Bearer - │ - ▼ -{ - "model": "openclaw:main", - "messages": [...] -} - │ - ▼ -AI Gateway (OpenClaw Gateway) - │ - ▼ -Agent Response -``` - -## Key Fields -- `model`：指定要调用的 Agent ID -- `messages`：对话历史，格式为 `[{role, content}]` -- `Authorization`：Bearer Token 认证 - -## 与 WebSocket 的区别 -- HTTP：同步请求-响应，适合 n8n 等工作流工具 -- WebSocket：长连接双向通信，适合实时对话界面 - -## Related -- [[OpenAI-Compatible-API]] 依赖此机制 -- [[OpenClaw]] Gateway 提供此端点 -- [[n8n]] 通过 HTTP Request 节点调用 diff --git a/wiki/concepts/HTTPS自动化证书.md b/wiki/concepts/HTTPS自动化证书.md deleted file mode 100644 index dcccab2e..00000000 --- a/wiki/concepts/HTTPS自动化证书.md +++ /dev/null @@ -1,77 +0,0 @@ -# HTTPS自动化证书 - -> HTTPS自动化证书，Caddy 自动申请和管理 Let's Encrypt SSL 证书的机制，无需手动配置证书续期和文件路径。 - -## Overview -Caddy 是用 Go 语言编写的现代化 Web 服务器，其核心特性之一是**自动 HTTPS**——自动为配置中的域名申请 Let's Encrypt 免费证书，并在到期前自动续期。本方案中 Caddy 运行在 RackNerd VPS 上，为 *.ishenwei.online 的所有子域名提供统一的 HTTPS 访问。 - -## How It Works - -### 申请流程 -1. Caddy 监听 80 端口（HTTP）和 443 端口（HTTPS） -2. 收到域名请求后，自动向 Let's Encrypt 的 ACME 服务器发起证书申请 -3. Let's Encrypt 通过 HTTP-01 或 TLS-ALPN-01 挑战验证域名所有权 -4. 验证通过后，证书下载并存储在 Caddy 本地（`~/.caddy`） -5. 证书到期前自动续期（默认提前30天） - -### Caddyfile 配置示例 -``` -*.ishenwei.online { - tls { - dns cloudflare {env.CF_API_TOKEN} - } - reverse_proxy /* localhost:8080 -} -``` - -## vs 传统 Nginx/Apache 方案 - -|| 特性 | Caddy | Nginx/Apache + Certbot | -|------|------|------|------------------------| -| 证书申请 | 自动 | 需手动 certbot | -| 证书续期 | 自动 | 需配置 cron + certbot renew | -| 证书路径 | 自动管理 | 需手动指定 | -| 配置文件 | 简洁 | 复杂 | -| 性能 | 轻量 | 成熟 | - -## Architecture Context - -本方案中 Caddy 接收来自公网的 HTTPS 请求后，根据域名将流量反向代理到对应的 FRP remotePort： - -``` -[公网请求] - https://grafana.ishenwei.online - │ - ▼ -[RackNerd VPS: Caddy] - ① 验证证书（自动） - ② TLS 解密 - ③ 反向代理到 localhost:13000 - │ - ▼ -[FRP Server] - 隧道传输到内网节点 - │ - ▼ -[Ubuntu Server 1: Grafana] - 端口 3000 -``` - -## Key Advantages -1. **零配置证书**：无需手动管理证书文件和续期脚本 -2. **自动 HTTP→HTTPS 重定向**：Caddy 默认将所有 HTTP 请求升级到 HTTPS -3. **Wildcard 证书**：通过 DNS-01 挑战支持 `*.ishenwei.online` 泛域名证书 -4. **现代协议支持**：默认启用 HTTP/2 和 TLS 1.3 - -## Related Concepts -- [[反向代理]] — Caddy 的核心功能 -- [[DNS托管]] — Cloudflare DNS 验证泛域名所有权 -- [[内网穿透]] — FRP 隧道传输机制 -- [[TLS 1.3]] — 最新 TLS 协议版本 -- [[ACME]] — Let's Encrypt 证书自动颁发协议 - -## Related Entities -- [[Caddy]] — 自动 HTTPS 实现者 -- [[RackNerd]] — Caddy 运行环境 -- [[Cloudflare]] — DNS 服务提供商，支持 DNS-01 挑战 -- [[frp]] — 内网服务的传输通道 diff --git a/wiki/concepts/Habit-Formation.md b/wiki/concepts/Habit-Formation.md deleted file mode 100644 index 0584773a..00000000 --- a/wiki/concepts/Habit-Formation.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Habit Formation" -type: concept -tags: [] -sources: ["product-behavioral-nudge-engine", "habit-tracker-accountability-coach"] -last_updated: 2026-05-01 ---- - -## Definition - -Habit Formation（习惯养成）是行为心理学研究的核心领域，通过在特定情境中重复低摩擦的行为动作，结合即时奖励，逐步将行为转化为自动化习惯，无需意志力驱动即可持续执行。 - -## The Habit Loop - -每个习惯由三部分组成的循环： - -1. **Cue（触发）**：情境线索（时间、地点、情绪状态） -2. **Routine（行为）**：对触发的具体反应 -3. **Reward（奖励）**：行为带来的正向反馈 - -> **关键洞察**：习惯无法被消除，只能被替换——通过保留相同的 Cue 和 Reward，改变中间的 Routine。 - -## Key Principles - -- **Friction Reduction**：行为越容易执行，越容易形成习惯 -- **Consistency Over Intensity**：每天小幅执行优于偶尔高强度执行 -- **Identity Reinforcement**：将行为与自我认同绑定（「我是每天运动的人」） -- **Streak Preservation**：连续记录是维持动力的重要机制 -- **Micro-Wins**：通过庆祝微小成功建立正向强化 - -## Connection to [[Behavioral Nudge Engine]] - -Behavioral Nudge Engine 专门应用习惯养成原理于软件交互设计： -- 通过 [[Micro-Sprint]] 将大任务分解为微行为，降低初始摩擦 -- 通过即时庆祝（[[Gamification]]）提供 [[Cognitive Load Reduction]] 后的正向奖励 -- 通过 [[Nudge Sequence]] 在关键时间点触发行为提示 - -## Related Concepts - -- [[Gamification]] — 即时奖励机制是习惯养成的核心 -- [[Cognitive Load Reduction]] — 低摩擦是习惯形成的前提 -- [[Micro-Sprint]] — 将大目标拆解为可习惯化的微行为 -- [[Default Bias]] — 预设动作减少习惯养成的启动阻力 - -## Connections - -- [[Habit Tracker & Accountability Coach]] — 专门负责习惯追踪与问责的 Agent -- [[Behavioral Nudge Engine]] — 行为心理学的应用引擎 -- [[Product Manager Agent]] — 产品设计中嵌入习惯养成机制 diff --git a/wiki/concepts/Hallucination.md b/wiki/concepts/Hallucination.md deleted file mode 100644 index f2892db3..00000000 --- a/wiki/concepts/Hallucination.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "Hallucination" -type: concept -tags: [hallucination, llm, problem, reliability] -aliases: [Hallucination, 幻觉, 大模型幻觉, LLM 幻觉] -last_updated: 2025-12-20 ---- - -## Definition -Hallucination，幻觉，大语言模型在面对陌生领域或缺乏足够知识的问题时，"一本正经地胡说八道"，给出看似合理但实际错误答案的现象。 - -## Key Facts -- 本质原因：LLM 的知识局限于训练数据集，面对未知领域时无法真实"理解"，只能基于概率生成最可能的下一个词 -- 类比：LLM 在陌生领域"只会写一个解字"，然后放飞自我 -- [[RAG]] 是解决幻觉的主要技术手段之一（通过外部知识引导） -- 其他方法：模型微调、Prompt Engineering、Chain-of-Thought - -## Connections -- [[RAG]] ← 解决 ← [[Hallucination]] -- [[Large Language Model]] ← 问题 ← [[Hallucination]] - -## Sources -- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]] diff --git a/wiki/concepts/Hand-Tracking.md b/wiki/concepts/Hand-Tracking.md deleted file mode 100644 index e1bc14d9..00000000 --- a/wiki/concepts/Hand-Tracking.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Hand Tracking" -type: concept -tags: [] -sources: [xr-immersive-developer] -last_updated: 2026-04-20 ---- - -## Definition -Hand Tracking 是 WebXR Hand Input Module 定义的浏览器原生手部追踪能力——通过设备摄像头或深度传感器追踪用户双手的骨骼节点（skeleton），将裸手作为 XR 交互的自然输入设备，无需手持控制器。 - -## Technical Foundation -- **WebXR Hand Input Module**（W3C Working Draft）：定义 `XRHand`、`XRJointSpace`、`XRSpace` 接口 -- 每只手 25 个追踪点（skeletal joints）：指尖、手指关节、手腕 -- `inputSource.hand` 属性返回对应 `XRHand` 对象 - -## Interaction Patterns -| 手势 | 交互语义 | -|------|----------| -| Pinch（捏合）| 选择、确认、拾取物体 | -| Point（指向）| 指向 UI 元素触发悬停 | -| Grab（抓取）| 抓取并移动虚拟物体 | -| Palm Push（手掌推动）| 推开/激活 3D UI | -| Open Palm | 打开菜单/取消操作 | - -## Related Concepts -- [[WebXR]]：Hand Tracking 的 API 基础 -- [[Constraint-Driven-Control-Mechanics]]：手势交互的约束设计原则 -- [[Motion-Sickness-Threshold]]：手部追踪延迟对眩晕感的影响 - -## Related Agents -- [[XR-Immersive-Developer]]：Hand Tracking 实现专家 -- [[XR-Interface-Architect]]：基于手势的 XR 界面设计 diff --git a/wiki/concepts/Handoff-Boundary.md b/wiki/concepts/Handoff-Boundary.md deleted file mode 100644 index ec11c841..00000000 --- a/wiki/concepts/Handoff-Boundary.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Handoff Boundary" -type: concept -tags: [multi-agent, coordination, failure-point, nexus] -sources: [executive-brief] -last_updated: 2026-05-01 -aliases: - - Agent Boundary - - Coordination Interface - -交接边界 ---- - -## Definition - -交接边界（Handoff Boundary）—— 多 Agent 工作流中从一个 Agent 的交付物传递到下一个 Agent 的接口点，也是协调失败最频繁发生的位置。 - -## The 73% Failure Rate Problem - -**关键数据**：多 Agent 项目在缺乏结构化协调协议时，交接边界处的失败率达 **73%**。 - -这使得交接边界成为多 Agent 协调中**最高杠杆的干预点**——改善交接协议带来的收益远大于优化单个 Agent 能力。 - -## Failure Modes at Handoff Boundaries - -1. **上下文截断**：关键决策和中间产物在交接时丢失 -2. **重复劳动**：下一 Agent 重新执行上一 Agent 已完成的工作 -3. **缺陷传递**：上游 Agent 的问题未被检测，直接传递给下游 -4. **质量断崖**：上游 Agent 的质量标准与下游不一致 -5. **时间浪费**：交接等待导致流程阻塞 - -## Highest-Leverage Interventions - -根据 Executive Brief 的战略发现，以下是针对交接边界的最高杠杆干预： - -1. **标准化交接模板**（见 Handoff Templates）：强制包含交付物清单 + 上下文摘要 + 下一步指令 + 质量证据 -2. **上下文连续性协议**：确保决策历史和中间产物在交接时完整传递（MCP Memory） -3. **质量证据传递**：上游 Agent 必须提供可验证的质量证据，而非口头声明 - -## Related Concepts - -- [[Agent Handoff]]：在交接边界执行的标准化上下文传递协议 -- [[Evidence Over Claims]]：交接边界处的质量标准，防止缺陷传递 -- [[Quality Gate]]：交接边界处的强制质量检查点 -- [[Dev↔QA Loop]]：交接边界内的持续质量验证机制 diff --git a/wiki/concepts/Handoff-Contract.md b/wiki/concepts/Handoff-Contract.md deleted file mode 100644 index 35d765d8..00000000 --- a/wiki/concepts/Handoff-Contract.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Handoff Contract" -type: concept -tags: [workflow, system-integration, contract, reliability] -last_updated: 2026-04-25 ---- - -## Definition -交接合同——两个系统、服务或 Agent 之间每次交接时必须明确定义的接口规范，确保交接的每个环节都有明确的成功/失败/超时约定，防止隐式假设导致级联故障。 - -## Contract Elements（合同要素） - -``` -HANDOFF: [From] -> [To] - PAYLOAD: { field: type, field: type, ... } - SUCCESS: { field: type, ... } - FAILURE: { error: string, code: string, retryable: bool } - TIMEOUT: Xs — treated as FAILURE - ON FAILURE: [recovery action] -``` - -### 字段说明 - -| 字段 | 说明 | -|------|------| -| `PAYLOAD` | 交接时传递的数据结构，必须包含类型注解 | -| `SUCCESS` | 成功时的返回数据结构 | -| `FAILURE` | 失败时的标准错误格式（含错误码和可重试标识）| -| `TIMEOUT` | 超时阈值，超时视为失败 | -| `ON FAILURE` | 失败后的恢复动作（重试、清理、escalation）| - -## Why It Matters -没有显式交接合同的工作流边界是最常见的故障来源： -- 服务 A 假设服务 B 总是返回某个字段，但 B 偶尔不返回 → 静默故障 -- 超时值未约定，一方认为 5s 合理，另一方认为 30s 才够 → 不匹配 -- 失败后未约定恢复动作，部分场景重试有效，部分场景重试造成数据重复 - -## Source -- [[specialized-workflow-architect]]（Workflow Architect Agent） diff --git a/wiki/concepts/Harness-Engineering.md b/wiki/concepts/Harness-Engineering.md deleted file mode 100644 index 91d5655f..00000000 --- a/wiki/concepts/Harness-Engineering.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Harness Engineering" -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 -Harness Engineering——为 LLM 设计系统脚手架的工程学科，使 AI Agent 能在长周期自主任务中可靠执行。核心理念：**LLM 本身不是 Agent，Agent = LLM + 代码脚手架**。 - -## Evolution of AI Engineering - -| Era | Focus | Limitation | -|-----|-------|------------| -| Prompt Engineering | 如何问（Instructions） | 脆弱，步骤间无持久性 | -| Context Engineering | 如何知道（RAG） | 无状态，无法控制长周期执行 | -| **Harness Engineering** | 如何约束和运行 | 解决连续多步执行控制 | - -每个时代并非替代前一个，而是**吸收**前一个——Harness Engineering 仍需要好的提示词和好的上下文，但它增加了前两者都无法提供的执行层。 - -## 4 Design Principles - -### 1. 约束而非指令（Constrain, don't instruct） -永远不要依赖模型"选择正确"——如果可以用程序化方式限制选择，就这样做。 -- 提示词说"永远用有效 JSON 响应" = **希望** -- Schema 验证器拒绝格式错误输出 = **保证** - -### 2. 外部化状态（Externalize state） -如果一条信息对任务连续性重要（已完成什么、待处理什么、什么失败了），它必须存在于 context window 之外。 -- Context window 是易失的 -- 磁盘文件是持久的 - -### 3. 每步可验证（Make every step verifiable） -如果你无法检查它，你就无法信任它。Harness 的每一层都应产生可被模型自身以外的东西验证的输出。 - -### 4. 局部失败而非全局崩溃（Fail locally, not globally） -单步工具调用失败应触发该步重试，而非重启整个管道。任何失败的爆炸半径应尽可能小。 - -## Implementation -- [[7-Layer-Harness-Stack]]：完整 7 层实现规范 -- [[Minimum-Viable-Harness]]：Day 1 可构建的最小可行版本 - -## Source -- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]] diff --git a/wiki/concepts/Headless-服务器.md b/wiki/concepts/Headless-服务器.md deleted file mode 100644 index 877fd3c2..00000000 --- a/wiki/concepts/Headless-服务器.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "Headless 服务器" -type: concept -tags: [服务器, 无头运行, 远程管理] ---- - -# Headless 服务器 - -> Headless 服务器（无头服务器）指不连接本地显示器、键盘、鼠标等外设的服务器，通过网络远程管理和访问。 - -## 概述 - -Headless 服务器是 Home Server、家庭实验室和数据中心常见的部署模式。Mac Mini 作为 Home Server 时，即以 Headless 模式运行，依赖 RustDesk/VNC 等远程桌面工具进行交互管理。 - -## 核心挑战 - -| 挑战 | macOS 解决方案 | Linux 解决方案 | -|------|---------------|---------------| -| 自动睡眠导致连接中断 | `pmset -a sleep 0` | systemd-logind HandleLidSwitch | -| 无显示器导致锁屏 | `pmset -a displaysleep 0` | 无直接对应 | -| 深度休眠导致无法远程唤醒 | `pmset -a standby 0 hibernatemode 0` | systemctl mask sleep.target | -| 需要远程管理能力 | RustDesk/VNC | SSH/RDP | - -## macOS Headless 最佳实践 - -```bash -# 防止所有睡眠（核心配置） -sudo pmset -a sleep 0 displaysleep 0 standby 0 hibernatemode 0 - -# 启用网络唤醒 -sudo pmset -a womp 1 - -# 临时保持唤醒 -caffeinate -d -i -s -``` - -## Linux Headless（Ubuntu Server） - -- [[HandleLidSwitch]] = ignore：合盖继续运行 -- [[systemd-logind]]：电源管理核心组件 -- SSH：远程管理的事实标准 - -## 与传统服务器的对比 - -| 特性 | 数据中心服务器 | Headless 服务器 | -|------|-------------|---------------| -| 显示器 | 通常有 KVM 切换器 | 无 | -| 物理访问 | 通常托管机房 | Home Office | -| 电源管理 | BMC/IPMI 远程管理 | 操作系统级别配置 | -| 睡眠处理 | 通常禁用 | 必须明确禁用 | - -## 相关概念 - -- [[pmset]] — macOS Headless 电源配置工具 -- [[caffeinate]] — macOS 临时防止睡眠 -- [[Wake-on-LAN]] — Headless 远程唤醒 -- [[HandleLidSwitch]] — Linux Headless 合盖配置 -- [[系统睡眠管理]] — 操作系统睡眠机制 - -## 相关实体 - -- [[Mac Mini M4]] — 典型的 Home Headless 服务器 -- [[Ubuntu Server]] — 另一常见的 Headless 服务器操作系统 diff --git a/wiki/concepts/Healthcare-Marketing-Compliance.md b/wiki/concepts/Healthcare-Marketing-Compliance.md deleted file mode 100644 index 52d9e75c..00000000 --- a/wiki/concepts/Healthcare-Marketing-Compliance.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Healthcare Marketing Compliance（医疗营销合规）" -type: concept -tags: [healthcare, compliance, china, legal] -sources: [healthcare-marketing-compliance] -last_updated: 2026-04-25 ---- - -## Definition -医疗营销合规是指医疗健康企业（涵盖药品、医疗器械、医美、保健食品、互联网医疗等子行业）在品牌推广、内容营销、学术推广过程中，遵守中国相关法律法规和平台规则的管理体系。 - -## Core Framework -以《广告法》《医疗广告管理办法》《互联网广告管理办法》为核心，结合 NMPA、SAMR 及各平台规则构成完整合规框架。 - -## Sub-Domains -- [[Medical-Advertisement-Review]]：医疗广告审查制度 -- [[Three-Tier-Review-Mechanism]]：企业内部三级审查机制 -- [[Blue-Hat-Logo]]：保健食品"蓝帽子"标识管理 -- [[Appearance-Anxiety]]：医美广告"容貌焦虑"红线 -- [[Patient-Privacy-PIPL]]：患者隐私 PIPL 合规 -- [[Academic-Detailing]]：学术推广合规 -- [[Compliance-Risk-Matrix]]：合规风险分级矩阵 - -## Core Principles -1. **合规不是"堵营销"，而是"保护品牌"**——一次违规处罚的代价远高于合规投入 -2. **"事前审查"优于"事后补救"**——所有对外发布的医疗营销内容必须经过合规团队审核 -3. **建立合规文化**——定期全员合规培训，建立违规案例库 - -## Compliance Culture -- 合规团队须与营销团队协作，而非对立 -- 建立"合规案例库"收集行业执法案例作为内部警示教育材料 -- 与监管机构保持良好沟通——主动了解政策趋势，不等处罚才学新规 - -## Related Concepts -- [[The-Agency]]：医疗营销合规 Agent 所属框架 -- [[Government-Digital-Presales-Consultant]]：政府合规 Agent（等保/商密） -- [[legal-compliance-checker]]：通用法律合规 Agent diff --git a/wiki/concepts/Heartbeat-Monitoring.md b/wiki/concepts/Heartbeat-Monitoring.md deleted file mode 100644 index 9f2e58df..00000000 --- a/wiki/concepts/Heartbeat-Monitoring.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Heartbeat Monitoring" -type: concept -tags: [] -sources: [] ---- - -# Heartbeat Monitoring - -## Definition - -定时任务定期检查客服队列状态，在消息出现积压或响应超时前主动告警的机制，确保 AI + 人工混合体系保持高可用性。 - -## Purpose - -即使 AI 自动处理率很高，仍需监控： -- **被 AI 错误分类的消息**（应升级但未升级） -- **新渠道接入失败** -- **知识库缺失导致大量相同 FAQ** -- **人工队列积压** - -## Implementation - -Heartbeat 检查通常每 15-30 分钟运行一次： - -``` -Every N minutes: - 1. Check unanswered messages older than X minutes - 2. If count > threshold → Alert (email / Slack / Telegram) - 3. Log daily response metrics: - - Total messages received - - Auto-response rate - - Escalation rate - - Average response time -``` - -## Related Concepts - -- [[Morning Briefing]]：Heartbeat 监控数据可作为每日晨报的一部分 -- [[Self-Healing-Systems]]：异常检测后可触发自动修复（如重新分类消息） -- [[Alerting]]：监控告警机制 - -## Sources - -- [[multi-channel-customer-service]] diff --git a/wiki/concepts/HeroesJourney.md b/wiki/concepts/HeroesJourney.md deleted file mode 100644 index 639a9b02..00000000 --- a/wiki/concepts/HeroesJourney.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Hero's Journey" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-30 ---- - -## Aliases -- Hero's Journey -- Monomyth -- Campbell's Monomyth -- 英雄之旅 - -## Overview -Hero's Journey（Monomyth / 英雄之旅）是由 [[Joseph Campbell]] 在其著作《千面英雄》（1949）中系统提出的跨文化神话叙事结构。该理论主张：全球文化的神话故事遵循一个共同的深层叙事结构——英雄离开日常世界 → 进入超自然领域 → 经历考验并获得力量 → 带着成功归来。 - -## Structure（简化版） - -### 三阶段 -1. **Departure（启程）**：Ordinary World → Call to Adventure → Refusal of the Call → Meeting the Mentor → Crossing the First Threshold -2. **Initiation（启蒙）**：Tests, Allies and Enemies → Approach to the Inmost Cave → Ordeal → Reward -3. **Return（回归）**：The Road Back → Resurrection → Return with the Elixir - -### 核心隐喻 -- **The Belly of the Whale**：最深的转变时刻，英雄几乎被吞噬 -- **The Elixir**：归来时携带的智慧或宝藏 - -## Application -- [[Christopher Vogler]] 的 Writer's Journey 是 Hero's Journey 的编剧改编版 -- 皮克斯几乎所有电影（《玩具总动员》《寻梦环游记》等）都遵循此结构 -- [[Academic Narratologist]] 将其作为英雄叙事分析的核心框架 - -## Relationship to Other Concepts -- [[Three-Act-Structure]]：Hero's Journey 是三幕式的叙事内容层，三幕式是组织层 -- [[Character-Arc]]：Hero's Journey 中的 transformation 对应角色的 want/need/lie/transformation 弧线 diff --git a/wiki/concepts/Hidden-Failure-Paths.md b/wiki/concepts/Hidden-Failure-Paths.md deleted file mode 100644 index bc0fb355..00000000 --- a/wiki/concepts/Hidden-Failure-Paths.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Hidden Failure Paths" -type: concept -last_updated: 2026-04-10 ---- - -## Definition -Hidden Failure Paths 是指在复杂分布式系统中，故障可能隐藏在多个层面和路径中，单点排查无法发现全部问题来源。 - -## OpenClaw 中的隐藏路径 -在 OpenClaw 这类分布式 AI Agent 系统中，一个"Context Limit Exceeded"问题可能藏在： -1. Session 文件（历史对话积累） -2. Memory plugin（记忆注入量） -3. Model config（context window 大小） -4. Routing rules（模型绑定） -5. Compaction 策略（token 预留量） - -## Debugging Strategy -逐一排除法：按层级逐层排查，每层确认无误后再进入下一层。 - -## Key Insight -> **工具/系统越复杂，问题的隐藏路径越深。** - -## Related -- [[Error-Surface-vs-Root-Cause]]: 隐藏路径导致表象与根因分离 -- [[Log-Driven-Debugging]]: 日志是发现隐藏路径的唯一可靠手段 -- [[Layered-Configuration]]: 分层架构本身就产生隐藏路径 - -## Sources -- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]] diff --git a/wiki/concepts/HierarchicalLOD.md b/wiki/concepts/HierarchicalLOD.md deleted file mode 100644 index e096dd0d..00000000 --- a/wiki/concepts/HierarchicalLOD.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "HierarchicalLOD" -type: concept -tags: ["unreal-engine", "lod", "optimization", "rendering"] -sources: ["unreal-world-builder"] -last_updated: 2026-04-30 ---- - -## Aliases -- HLOD -- Hierarchical Level of Detail -- 层级 LOD -- HLOD System - -## Definition -HLOD（Hierarchical Level of Detail，层级 LOD）是 Unreal Engine 5 中将远处多个 Actor 合并为少量网格的系统，消除远处的 Actor 数量爆炸和几何 pop-in，显著降低 Draw Calls 和渲染开销。 - -## Core Rules -- **强制构建**：所有 500m 以外可见区域必须生成 HLOD，未构建 HLOD 会导致远处 Actor 数量爆炸 -- **生成而非手绘**：HLOD 网格由引擎自动生成，任何几何变更后必须重新构建 -- **Mesh Merge 方法**：最快构建速度，对 > 500m 距离可接受质量 -- **目标参数**：LOD Screen Size ≤ 0.01，Draw Distance ≥ 50,000cm（500m） -- **材质烘焙**：启用，1024×1024 烘焙纹理 - -## Actor Type Handling -| Actor 类型 | HLOD 处理 | -|-----------|----------| -| StaticMeshActor | 包含在 HLOD 合并 | -| Nanite 启用网格 | **排除**（Nanite 自身处理 LOD） | -| Skeletal Mesh | **不支持**（不合并） | - -## Build Settings -- **Merge Distance**：50cm（焊接附近几何） -- **Hard Angle Threshold**：80°（保留锐边） -- **Target Triangle Count**：每 HLOD 网格 5000 三角形 - -## Visual Validation -必须在以下相机距离进行目视验证： -- 600m -- 1000m -- 2000m - -HLOD 瑕疵靠视觉捕获，而非 Profiler。 - -## Rebuild Triggers -任何以下变更必须触发 HLOD 重建： -- 几何添加或移除 -- 材质变更 -- Actor 变换 - -## Connections -- [[UnrealWorldBuilder]] ← 远距离优化 ← HierarchicalLOD -- [[UnrealEngine5]] ← 核心引擎 ← HierarchicalLOD -- [[Nanite]] ← 互补（处理 Nanite 资产）← HierarchicalLOD - -## Sources -- [[unreal-world-builder]] diff --git a/wiki/concepts/Hierarchy-Agent-Pattern.md b/wiki/concepts/Hierarchy-Agent-Pattern.md deleted file mode 100644 index 7d9aa4ff..00000000 --- a/wiki/concepts/Hierarchy-Agent-Pattern.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Hierarchy Agent Pattern" -type: concept -tags: [] -sources: - - multi-agent-system-reliability -last_updated: 2026-04-28 ---- - -# Hierarchy Agent Pattern - -## 定义 -多智能体系统的等级制度模式——由一个主管模型（Supervisor/Planner）制定计划、分解任务、分配工作给专业工作代理（Worker），再由验证代理（Validator）检验结果的质量。 - -## 核心机制 -- **Planner**：智能模型（如 Opus）将用户目标分解为原子化小步骤 -- **Worker**：专门化智能体（通常用更小更快的模型），专注于单一任务 -- **Validator**：检查点——工作不合格则退回；可用确定性代码（单元测试/JSON schema）或LLM本身 - -## 为什么有效 -依赖图强制协作——Worker必须等Planner分配任务才能开始，且无法作弊（会被Validator发现）。 - -## 适用场景 -需要将上下文分开的复杂工作流（如不让"撰稿人"看到"研究员"的原始日志）。 - -## 优点 -- 任务分解清晰，可独立验证每个步骤 -- 支持上下文隔离 - -## 缺点 -- 顺序执行（Planner→Worker→Validator），速度慢、成本高 -- Validator建议使用与Planner/Worker不同的模型以提高客观性 - -## 来源 -- [[multi-agent-system-reliability]] diff --git a/wiki/concepts/Historiography.md b/wiki/concepts/Historiography.md deleted file mode 100644 index 8a33d5f7..00000000 --- a/wiki/concepts/Historiography.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Historiography" -type: concept -tags: [historiography, methodology] -sources: [academic-historian] -last_updated: 2026-04-30 ---- - -## Definition -历史编纂学（Historiography）是对历史叙事本身的研究——研究历史如何被记录、构建、争论和演变的学科。Historiography 既关注具体的历史研究成果，也关注这些成果背后的认识论、方法论和政治性前提。 - -## Key Features -- **核心问题**：历史知识是如何生产的？谁的视角被记录？谁的被忽略？ -- **研究对象**：史料选择、历史叙事结构、史学流派演变、历史争议的根源 -- **核心议题**： - - 史料的可靠性与偏见（谁书写，谁沉默？） - - 史学流派更替（启蒙史学 → 浪漫主义史学 → 实证主义 → 年鉴学派 → 后现代史学） - - 历史叙事的政治性（历史书写服务于现实政治利益） - - 档案的构建（档案本身是权力工具，非中性存储） -- **重要性**：Historian Agent 理解"历史叙事本身是被建构和争夺的对象"，这是反历史神话和欧洲中心主义的基础 - -## Relationship to Other Concepts -- [[Annales-School]] ← 重要流派 ← [[Historiography]]：年鉴学派是对传统实证主义史学的重要突破 -- [[Microhistory]] ← 属于 ← [[Historiography]]：微观史是历史编纂学中的重要流派 -- [[Longue-Duree]] ← 属于 ← [[Historiography]]：长时段分析反映特定史学认识论 -- [[academic-historian]] ← 方法论核心 ← [[Historiography]]：Historian Agent 的五步工作流本质上是 historiographical 方法论 - -## Relationship to Source Pages -- [[academic-historian]]：Historian Agent 接受过 historiography 训练，能够理解并参与学术争议 - -## Aliases -- 历史编纂 -- 史学 -- 元历史 -- Metahistory diff --git a/wiki/concepts/Holistic-Admissions.md b/wiki/concepts/Holistic-Admissions.md deleted file mode 100644 index 85fbc437..00000000 --- a/wiki/concepts/Holistic-Admissions.md +++ /dev/null @@ -1,37 +0,0 @@ -# Holistic Admissions - -## Definition - -全面评估录取模式（Holistic Admissions）——一种不依赖单一量化指标，而是综合考量申请者多维度素质的录取评估框架。最初由美国大学在 1970 年代引入，旨在超越单纯的分数排名，识别全面发展且能为校园社区做出独特贡献的学生。 - -## Core Dimensions - -| 维度 | 评估内容 | -|------|----------| -| 学术表现 | GPA、课程难度、排名、标准化考试成绩 | -| 课外活动 | 领导力、社区服务、社团、体育、艺术 | -| 文书 | 个人叙事、成长故事、目标陈述 | -| 推荐信 | 学术/职业能力的第三方评价 | -| 独特背景 | 文化经历、社会经济背景、第一代大学生身份 | - -## Countries & Institutions - -- **美国**：哈佛、耶鲁、斯坦福等顶尖私立大学全面采用；UC 系统于 2021 年逐步取消 SAT/ACT 强制要求，进一步向全面评估倾斜 -- **英国**：本科以 UCAS 系统为主，Personal Statement 权重较高，但牛津/剑桥仍设笔试 + 面试 -- **加拿大**：部分学校（U of T、UBC）引入全面评估理念，但整体仍以学术成绩为核心 -- **澳大利亚/新西兰**：部分专业（医学、法学）采用全面评估 - -## Key Principles - -1. **No single factor is dispositive** — 任何单一维度均不能单独决定录取结果 -2. **Context matters** — 评估时会考虑申请人所在学校、地区的教育资源差异 -3. **Fit over prestige** — 学校寻找与自身价值观和社区文化匹配的申请者 -4. **Institutional priorities** — 每所学校有不同的录取偏好（有些偏好体育特长生，有些偏好研究型学生） - -## Relationship to Study Abroad Planning - -Study Abroad Advisor 强调：申请美国顶尖大学的核心在于构建 coherent holistic profile——各维度之间需有逻辑一致性（core narrative arc），而非简单堆积活动。[[study-abroad-advisor]] 通过文书策略、背景提升规划、选校报告等手段帮助学生系统性地建立全面评估竞争力。 - -## Aliases -- Holistic Review -- 综合评估录取 diff --git a/wiki/concepts/HookBodyCTA.md b/wiki/concepts/HookBodyCTA.md deleted file mode 100644 index 305b4cd4..00000000 --- a/wiki/concepts/HookBodyCTA.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: "Hook-Body-CTA" -type: concept -tags: ["video-ads", "creative", "meta-ads", "storytelling"] ---- - -## Definition - -Hook-Body-CTA 是视频广告的标准叙事结构框架，将视频广告分为三个阶段：钩子（Hook）吸引注意、主体（Body）传递价值、号召行动（CTA）促进转化。 - -## Three-Phase Structure - -### Phase 1: Hook（钩子，0-3 秒） - -**目标**：在极短时间内赢得用户注意力，阻止滑动/跳过 - -**策略**： -- **数字冲击**：立即展示具体数字（"节省 70%"、"10 万人已使用"） -- **问题痛点**：直接点出用户当前困境（"还在为 X 发愁？"） -- **反常识**：出乎意料的陈述引发好奇（"99% 的人都做错了"） -- **视觉冲击**：快速切换/高对比度画面抓住眼球 -- **问句开头**：用问句引发思考 - -**禁忌**：品牌 Logo 开场（浪费黄金 3 秒）、慢热铺垫 - -### Phase 2: Body（主体，3-30 秒） - -**目标**：详细展示产品/服务的核心价值 - -**内容要素**： -- **产品展示**：真实使用场景演示 -- **核心利益**：1-3 个关键卖点 -- **差异化**：与竞品的主要区别 -- **信任背书**：用户评价/数据/认证 -- **情感共鸣**：故事化叙事建立情感连接 - -**节奏控制**： -- 每 5-8 秒应有画面/信息变化 -- 避免长时间单一镜头 -- 保持与音频（音乐/旁白）同步 - -### Phase 3: CTA（号召行动，30-60 秒末尾） - -**目标**：将兴趣转化为明确行动 - -**CTA 类型**： -- **直接型**："立即购买"、"现在就注册" -- **稀缺型**："仅剩 100 个名额"、"优惠今日截止" -- **价值型**："免费试用 30 天" -- **社会证明型**："加入 10 万用户的选择" - -**最佳实践**： -- CTA 至少停留 3 秒确保可读 -- 配合点击按钮视觉元素 -- 与落地页内容高度一致（Message Match） - -## Platform Variations - -| 平台 | 时长 | Hook 策略 | -|------|------|---------| -| TikTok | 3-15 秒 | 极快节奏，前 0.5 秒决定留存 | -| Instagram Reels | 15-30 秒 | 3 秒内展示产品核心价值 | -| Meta Feed | 15-60 秒 | 问题-解决方案-CTA 结构 | -| YouTube Pre-roll | 5 秒可跳过 | 5 秒内必须传达核心信息 | -| LinkedIn | 30-60 秒 | 专业场景，价值导向叙事 | - -## Key Concepts Related - -- [[MessageMatch]]：CTA 与落地页内容一致性 -- [[ABTesting]]：不同 Hook 策略的测试验证 -- [[CreativeFatigue]]：定期更新 Body 内容防止疲劳 - -## Sources - -- [[paid-media-creative-strategist]] diff --git a/wiki/concepts/Horizontal-Pod-Autoscaler.md b/wiki/concepts/Horizontal-Pod-Autoscaler.md deleted file mode 100644 index d2ceaa85..00000000 --- a/wiki/concepts/Horizontal-Pod-Autoscaler.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Horizontal Pod Autoscaler (HPA)" -type: concept -tags: - - Kubernetes - - EKS - - Autoscaling - - Pod - - Metrics -sources: - - ctp-topic-59-achieving-reliability-with-amazon-eks - - ctp-topic-64-scaling-out-with-amazon-eks -last_updated: 2026-04-28 ---- - -## Definition -Horizontal Pod Autoscaler (HPA) 是 Kubernetes 标准的工作负载水平扩缩容机制，通过监测 Pod 的资源使用指标（CPU、内存或自定义指标）自动调整 Pod 副本数，以满足应用负载需求。 - -## Key Mechanisms -- **指标采集**：通过 Metrics Server 获取 CPU/内存利用率指标 -- **副本计算**：基于目标阈值计算所需 Pod 副本数 -- **稳定性配置**：通过 `stabilizationWindowSeconds` 和 `periodSeconds` 防止震荡（flapping） -- **自定义/外部指标**：支持通过 Custom Metrics API 和 External Metrics API 集成负载均衡器并发连接数、消息中间件队列深度等业务指标 -- **Pod 级而非容器级**：当前 HPA 仅考虑 Pod 整体资源消耗，不支持容器级别的独立扩缩 - -## Relationship with VPA -- **HPA**：水平扩展（增加/减少 Pod 副本数） -- **VPA (Vertical Pod Autoscaler)**：垂直扩展（调整单个 Pod 的资源请求） -- 两者可互补使用：HPA 应对流量波动，VPA 优化资源分配 - -## Relationship with KEDA -- KEDA 可通过 **Publishes Metrics 模式** 为 HPA 供数，实现指标驱动与事件驱动的混合扩缩容 - -## Sources -- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] -- [[ctp-topic-64-scaling-out-with-amazon-eks]] diff --git a/wiki/concepts/Hosmer-Lemeshow-Test.md b/wiki/concepts/Hosmer-Lemeshow-Test.md deleted file mode 100644 index 6ae35598..00000000 --- a/wiki/concepts/Hosmer-Lemeshow-Test.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: "Hosmer-Lemeshow Test" -type: concept -tags: [model-evaluation, calibration-testing, goodness-of-fit] -sources: - - specialized-model-qa -last_updated: 2026-05-29 ---- - -## Definition - -Hosmer-Lemeshow（HL）检验是一种评估二分类模型预测概率校准程度的拟合优度检验，通过比较预测概率分箱后的观测正例数与期望正例数，判断模型预测与实际结果之间是否存在显著差异。p-value < 0.05 时拒绝原假设（模型校准良好），认为模型存在显著的校准偏差。 - -## Algorithm - -1. 将样本按预测概率从小到大分箱（默认 10 箱，或自定义 g 组） -2. 对每箱计算： - - **观测正例数** $O_g = \sum_{i \in \text{group } g} y_i$ - - **期望正例数** $E_g = \sum_{i \in \text{group } g} \hat{p}_i$ - - **样本数** $n_g$ -3. 计算 HL 统计量： - -$$H = \sum_{g=1}^{G} \frac{(O_g - E_g)^2}{E_g (1 - E_g / n_g)}$$ - -4. 自由度 $df = G - 2$（减去截距和斜率估计参数） -5. 与 $\chi^2(df)$ 分布比较，$p = 1 - F_{H}(H)$ - -## Interpretation - -```python -from scipy.stats import chi2 - -def hosmer_lemshow_test(y_true: pd.Series, y_pred: pd.Series, groups: int = 10) -> dict: - data = pd.DataFrame({"y": y_true, "p": y_pred}) - data["bucket"] = pd.qcut(data["p"], groups, duplicates="drop") - - agg = data.groupby("bucket", observed=True).agg( - n=("y", "count"), - observed=("y", "sum"), - expected=("p", "sum"), - ) - - hl_stat = ( - ((agg["observed"] - agg["expected"])**2) / - (agg["expected"] * (1 - agg["expected"] / agg["n"])) - ).sum() - - dof = len(agg) - 2 - p_value = 1 - chi2.cdf(hl_stat, dof) - - return { - "HL_statistic": round(hl_stat, 4), - "p_value": round(p_value, 6), - "calibrated": p_value >= 0.05, # True = well calibrated - "dof": dof, - "groups_used": len(agg), - } -``` - -| p-value | 判读 | -|---------|------| -| ≥ 0.05 | 🟢 模型校准良好，无显著证据表明预测概率偏离实际频率 | -| < 0.05 | 🔴 拒绝原假设，模型存在显著校准偏差 | - -## Limitations - -1. **分组方式敏感**：不同分箱数量/方法导致不同结果，10 等分是惯例但非最优 -2. **样本量敏感**：大样本下即使微小偏差也能导致显著 p-value（实际影响可能很小） -3. **掩盖子群体问题**：整体通过 HL 检验不等于所有子群体都校准良好 -4. **序贯分组问题**：qcut 在重复值多时可能合并箱子，需检查 `groups_used` - -## Alternatives - -- **Brier Score**：无需分组，对样本量稳健，但只能给出误差量级而非定位 -- **Spiegelhalter's Z-test**：基于 Brier Score 的统计检验 -- **Reliability Curves**：可视化诊断，比 HL 检验提供更多信息 -- **Expected Calibration Error (ECE)**：量化平均校准误差，解释性更强 - -## Model QA 中的应用 - -Model QA Specialist 将 HL 检验用于： -1. **模型上线前验证**：新模型上线必须通过 HL 检验（p ≥ 0.05） -2. **定期监控**：在 OOT 窗口上重复执行，监控校准随时间恶化趋势 -3. **子群体分层测试**：在关键子群体（高风险/低风险/新客户）上分别执行 -4. **Champion-Challenger**：对比 champion model vs challenger model 的 HL 结果 - -## Relationship - -- **被依赖** [[Calibration-Testing]]：HL 检验是 Calibration Testing 的核心统计工具之一 -- **依赖** [[Discrimination-Metrics]]：先确认模型有区分能力（AUC/Gini 达标），再讨论校准 -- **依赖** [[Population-Stability-Index]]：PSI 漂移往往是 HL 检验失败的前兆 -- **依赖** [[SHAP]]：HL 检验发现校准问题后，用 SHAP waterfall 诊断具体原因 -- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 校准测试步骤的核心工具 diff --git a/wiki/concepts/Host-Incubation-System.md b/wiki/concepts/Host-Incubation-System.md deleted file mode 100644 index 17d0848d..00000000 --- a/wiki/concepts/Host-Incubation-System.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: "Host Incubation System" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-26 ---- - -## Definition -主播孵化体系——将零基础新人从「面对镜头说不出话」培养为「能独立操盘百万GMV直播间」的标准化进阶路径。核心理念：**主播是直播间的灵魂，但不能依赖单一主播——必须建立人才梯队**。 - -## Three-Stage Progression Model - -### Stage 1: 素人期（Beginner） -**目标**：能稳定直播4小时不冷场 - -核心能力训练： -- **镜头表现力**：克服镜头恐惧，建立镜头感，能自然面对镜头说话 -- **基础话术**：能流畅念完产品介绍，不卡壳，不冷场 -- **情绪节奏**：理解直播间的情绪起伏——前期拉互动→中期推产品→后期逼单 -- **禁忌词规避**：熟悉平台敏感词规则，不说绝对化表述/功效承诺/虚假对比 - -通过标准：连续3场，每场4小时，平均互动率 >2%，无平台违规处罚 - -### Stage 2: 成长期（Intermediate） -**目标**：能控制节奏并主动驱动转化 - -进阶能力训练： -- **节奏控制**：能根据在线人数和流量波峰实时调整产品排布和话术密度 -- **主动转化**：熟练运用五阶段话术框架，在正确节点触发购买指令 -- **即时反应**：能处理弹幕问题、突发状况（产品问题、网络波动、恶意弹幕） -- **数据敏感**：能读懂在线人数曲线，在下降时主动切换策略（福袋/秒杀/换品） - -通过标准：连续5场，GPM >500元，转化率 >2%，能独立处理3次以上突发状况 - -### Stage 3: 成熟期（Advanced） -**目标**：能吸引自然流量并即兴发挥 - -高阶能力训练： -- **即兴发挥**：不依赖完整脚本，能根据场景和弹幕即时调整话术 -- **自然流量运营**：能利用直播间内的互动数据和内容片段（录屏/切片）吸引算法推荐 -- **团队协同**：能与场控/运营/投手默契配合，实现公域+私域联动 -- **自我复盘**：能独立分析数据报告，识别问题并提出改进方案 - -通过标准：连续10场，月GMV环比增长 >15%，自然流量占比 >40% - -## Mental Resilience Training（主播心理建设） -所有阶段均需培养的心理素质： -- **冷场应对**：30秒以上冷场必须触发福袋或切换产品，不能尬聊 -- **恶意弹幕**：不接茬、不回击，设置关键词屏蔽和自动拉黑规则 -- **直播事故**：设备故障/产品问题等突发情况，保持冷静，按应急预案处理 -- **数据焦虑**：不以单场GMV论英雄，关注过程指标（话术执行率/节奏控制） - -## Host Management Principles -- **话术执行率 > 结果**：评估主播首先看有没有按脚本执行，而非GMV高低 -- **不依赖单一主播**：主力主播必须配备备播主播，主力休假不影响直播 -- **排期科学**：单场不超过6小时，峰值时段安排状态最佳主播 -- **复盘优先于追责**：问题发生后先分析脚本和排品是否合理，再评估个人表现 - -## Connections -- [[Five-Phase Script Framework]] — 三阶段主播能力模型对应话术框架的掌握深度 -- [[Organic Traffic Amplification]] — 成熟期主播能通过即兴发挥和互动节奏「制造」自然流量高峰 -- [[Product Sequencing]] — 成长期以上主播需要理解产品排品逻辑，能根据在线人数实时建议调整 -- [[marketing-livestream-commerce-coach]] — 本体系是教练 Agent 交付给客户的核心能力建设框架 - -## Sources -- [[marketing-livestream-commerce-coach]] diff --git a/wiki/concepts/Host-Network-Mode.md b/wiki/concepts/Host-Network-Mode.md deleted file mode 100644 index ce238e16..00000000 --- a/wiki/concepts/Host-Network-Mode.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Host Network Mode" -type: concept -tags: - - Kubernetes - - Networking - - Pod-Networking - - AWS - - EKS -sources: - - ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone -last_updated: 2026-04-28 ---- - -## Overview -Host Network Mode 是 Kubernetes Pod 规范中的一种网络配置选项（`hostNetwork: true`），使 Pod 共享宿主机的网络命名空间，直接使用宿主机的网络接口和 IP 地址，而不是通过 Kubernetes 的虚拟网络。 - -## Definition -在 Pod spec 中设置 `hostNetwork: true` 后，Pod 将： -- 使用宿主机的网络命名空间 -- 直接获得宿主机网络接口上的 IP 地址 -- 可以绑定宿主机的端口（如 80、443） -- 可直接访问宿主机所在网络上的资源 - -## Use Case: EKS Lab Landing Zone -在 AWS Lab Landing Zone 的 EKS 部署中，Octane 等 IP 密集型应用需要大量可用 IP。通过自定义网络模式，Pod 无需通过 VPC CNI 分配 IP，而是直接使用宿主机网络的 IP 地址，从而绕开 AWS Lab 环境 IP 地址池受限的问题。 - -```yaml -spec: - hostNetwork: true - containers: - - name: octane - image: octane:latest -``` - -## Trade-offs -| 优点 | 缺点 | -|------|------| -| 突破 Pod IP 数量限制 | Pod 之间端口冲突风险 | -| 直接访问宿主机网络资源 | 安全性降低（Pod 可访问宿主机所有网络） | -| 简化网络路径 | 违反 Kubernetes 网络隔离原则 | -| 适合特殊网络需求场景 | 难以在不同环境中移植 | - -## Related Concepts -- [[Amazon-EKS]]：使用 Host Network Mode 的容器编排平台 -- [[IPAM]]：IP 地址管理，与 Host Network Mode 在 IP 分配上形成互补 -- [[Kubernetes-Tagging]]：Pod 标记策略 - -## Related Sources -- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] diff --git a/wiki/concepts/HouseholdInventoryTracking.md b/wiki/concepts/HouseholdInventoryTracking.md deleted file mode 100644 index 4f011a66..00000000 --- a/wiki/concepts/HouseholdInventoryTracking.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "Household Inventory Tracking" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-22 ---- - -# Household Inventory Tracking - -## Definition -Agent 维护家庭物资库存记录（JSON/数据库），追踪物品名称、数量、存放位置（冰箱/储藏室/地下室），支持多种输入方式（照片 OCR、文字更新、小票识别），并提供自然语言查询接口。 - -## Data Model -```json -{ - "item": "milk", - "quantity": "2 gallons", - "location": "fridge", - "last_updated": "2026-04-22T10:30:00", - "low_stock_threshold": "1 gallon" -} -``` - -## Input Methods -| Method | Example | Mechanism | -|--------|---------|-----------| -| 照片 | 拍摄冰箱内容 → Vision 模型提取物品 | 视觉 AI OCR | -| 文字 | "We're out of eggs" / "Bought 2 gallons of milk" | 自然语言解析 | -| 小票 | 拍摄购物小票 → 自动扣减/更新 | 收据 OCR | - -## Query Interface -通过 Telegram/Slack 等消息平台自然语言查询： -- "Do we have butter?" → 返回位置和数量 -- "What's running low?" → 列出低于阈值的物品 -- "Generate grocery list" → 汇总低库存物品 + 食谱所需食材 - -## Storage Location -`~/household/inventory.json` 或通过 Agent 记忆系统（如 [[OpenClaw]] MEMORY）存储 - -## Related Concepts -- [[Morning Briefing]]：库存低时可在晨间简报中提醒 -- [[Second Brain]]：同属持久记忆能力的家庭应用 -- [[Personal CRM]]：[[personal-crm]] 的物资版，结构化数据 + 自然语言接口 - -## Related Sources -- [[family-calendar-household-assistant]] — 家庭物资追踪场景描述 diff --git a/wiki/concepts/Hub-and-Spoke.md b/wiki/concepts/Hub-and-Spoke.md deleted file mode 100644 index 69e09251..00000000 --- a/wiki/concepts/Hub-and-Spoke.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Hub-and-Spoke Network Topology" -type: concept -tags: [AWS, Networking, Topology, Transit Gateway] -sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] -last_updated: 2026-05-07 ---- - -## Hub-and-Spoke - -Hub-and-Spoke 是一种星型网络拓扑结构，其中所有分支（Spoke）连接到中心节点（Hub），分支间的通信通常经过 Hub 中转。 - -## Definition - -- **Hub（中心节点）**: 负责汇聚所有 Spoke 的流量，执行路由决策和安全策略 -- **Spoke（分支节点）**: 各自独立的 VPC 或 Landing Zone，通过 Hub 接入全局网络 -- **通信模式**: Spoke-to-Spoke 通信必须经过 Hub 转发，而非直接互联 - -## In AWS Transit Gateway Architecture - -在 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 描述的架构中： - -- **Hub**: 每个地理区域（APJ、EMEA、AMS）的区域级 Transit Gateway（如 EMEA 的伦敦 Hub、AMS 的俄勒冈 Hub） -- **Spoke**: 各个 Landing Zones，通过 TGW Peering 接入区域 Hub -- **Inter-Hub**: 区域 Hub 之间通过 Full Mesh（全网状）连接，确保全球流量的可达性 - -## Key Properties - -| 属性 | 值 | -|------|-----| -| 架构类型 | 星型拓扑 | -| 扩展性 | 高——新增 Spoke 仅需连接到 Hub | -| 复杂度 | 低——集中管理路由策略 | -| 缺点 | Hub 可能成为瓶颈或单点故障 | -| 适用场景 | 多账号 VPC 互联、全球 Landing Zone 网络 | - -## Relationship to Transit Gateway - -AWS Transit Gateway 是实现 Hub-and-Spoke 架构的核心服务： -- [[AWS-Transit-Gateway-TGW]] 提供区域级 Hub 功能 -- [[TGW-Peering]] 用于 Hub 之间的跨区域互联 -- [[Hub-and-Spoke]] 与 Full Mesh 组合使用（Spoke-to-Hub = Hub-and-Spoke, Hub-to-Hub = Full Mesh） - -## Connections - -- [[AWS-Transit-Gateway-TGW]] ← 实现 ← [[Hub-and-Spoke]] -- [[TGW-Peering]] ← 跨 Hub 连接 ← [[Hub-and-Spoke]] -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 案例 ← [[Hub-and-Spoke]] - -## Sources - -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/concepts/Human-Centered-Design.md b/wiki/concepts/Human-Centered-Design.md deleted file mode 100644 index 75c58cf4..00000000 --- a/wiki/concepts/Human-Centered-Design.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Human-Centered-Design" -type: concept -tags: [UX, Process-Design, Employee-Experience, Design-Thinking] -sources: [testing-workflow-optimizer] -last_updated: 2026-04-21 ---- - -# Human-Centered-Design - -人本设计——一种以最终用户和员工为核心的设计哲学，在设计产品、服务、流程和系统时，优先考虑人类的需求、能力、限制和情感，而非仅关注技术可行性或效率指标。 - -## Aliases -- HCD -- 以人为本的设计 -- 人本设计 - -## Core Principles -1. **User Needs First**（用户需求优先）——在技术或流程约束之前，首先理解和满足人的需求 -2. **Empathy**（同理心）——深入理解用户的真实感受、痛点和心智模型 -3. **Iterative Design**（迭代设计）——通过快速原型→测试→改进的循环持续优化 -4. **Inclusion & Accessibility**（包容性与可访问性）——确保设计服务于所有用户，包括残障人士和边缘群体 -5. **Cognitive Load Management**（认知负荷管理）——减少用户在完成任务时的思考和记忆负担 - -## In Workflow/Process Design -在流程和工作流设计中，人本设计意味着： -- **员工满意度优先于单纯效率**：好的流程设计不仅高效，还让执行者感到有价值和满足 -- **减少认知负荷**：将复杂的决策规则可视化，提供清晰的指引 -- **保留人类判断空间**：在自动化无法处理的灰色地带保留人工决策节点 -- **可访问性**：确保流程对所有能力水平的员工都可用 - -## Connection to Workflow Optimization -[[testing-workflow-optimizer]] 将人本设计作为核心约束： -> "Prioritize user experience and employee satisfaction in process design" -> "Consider change management and adoption challenges in all recommendations" -> "Balance automation efficiency with human judgment and creativity" - -这意味着： -- 自动化不应完全消除人的参与感 -- 流程设计应减少而非增加员工认知压力 -- 变革建议需要考虑员工的接受度和适应成本 - -## Design Thinking Process -1. **Empathize**（共情）——观察、访谈，理解用户 -2. **Define**（定义）——综合洞察，定义核心问题 -3. **Ideate**（构思）——头脑风暴，生成大量创意 -4. **Prototype**（原型）——快速低成本制作解决方案原型 -5. **Test**（测试）——用真实用户验证原型 - -## Connection to Lean/Six-Sigma -人本设计补充了 [[Lean]] 和 [[Six-Sigma]] 的量化视角： -- Lean/Six-Sigma 提供数据驱动的优化框架 -- Human-Centered-Design 提供人本视角的优化方向 -- 两者结合：优化的指标必须与人的真实需求对齐 - -## Connections -- [[testing-workflow-optimizer]] — 流程优化中的人本设计约束 -- [[Cognitive-Load-Reduction]] — 人本设计的核心子维度 -- [[Lean]] — 互补：量化优化 + 人本方向 -- [[Design-Thinking]] — 人本设计的系统性方法论框架 diff --git a/wiki/concepts/Human-Handoff.md b/wiki/concepts/Human-Handoff.md deleted file mode 100644 index 97e8a45b..00000000 --- a/wiki/concepts/Human-Handoff.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Human Handoff" -type: concept -tags: [] -sources: [] ---- - -# Human Handoff - -## Definition - -AI Agent 将无法自动处理或需要人工判断的客户消息转移给人工客服的机制，确保复杂问题得到专业处理，同时保留 AI 的高效处理能力用于高频简单问题。 - -## Triggers - -AI 应触发人工handoff的条件通常包括： -- **复杂投诉**：情绪激动、涉及退款、法律条款 -- **未知领域**：问题超出知识库覆盖范围 -- **特定关键词**：明确标记的升级词（如 "speak to manager"） -- **AI 不确定**：置信度低于阈值时的模糊消息 -- **人工请求**：客户明确要求转人工 - -## Design Principles - -1. **即时确认**：handoff 时 AI 先确认收到消息，告知客户人工将跟进，避免"静默感" -2. **上下文传递**：转交时携带完整的对话历史，避免客户重复描述问题 -3. **优先级标记**：投诉类消息标记高优先级，加快处理 -4. **无缝衔接**：人工接手后系统应有完整上下文，无需客户重述 - -## Related Concepts - -- [[Intent-Classification]]：投诉意图（Complaint）通常是 Handoff 的主要触发器 -- [[Unified-Inbox]]：人工处理也在统一收件箱内进行 -- [[AI-Auto-Response]]：AI 与人工互补，AI 覆盖高频简单问题 - -## Sources - -- [[multi-channel-customer-service]] diff --git a/wiki/concepts/Hybrid-Cloud.md b/wiki/concepts/Hybrid-Cloud.md deleted file mode 100644 index a276f5b4..00000000 --- a/wiki/concepts/Hybrid-Cloud.md +++ /dev/null @@ -1,198 +0,0 @@ -# Hybrid Cloud - -> **Hybrid Cloud** — 混合云是一种同时使用公有云和私有云的计算环境，通过在两者之间按策略分配工作负载来结合各自的优势——公有云的弹性与成本效率 + 私有云的安全性与控制力。 - -## Definition - -混合云（Hybrid Cloud）是一种将公有云和私有云整合在一起的云计算架构，允许数据和应用程序在两种环境之间移动。混合云策略基于业务和技术需求（安全性、性能、可扩展性、成本、效率）动态决定哪些工作负载运行在哪种云环境中。 - -## Core Principle - -> "The uses of each are driven by business and technical needs around: Security, Performance, Scalability, Cost, Efficiency." - -混合云的核心理念是：**工作负载应该运行在最适合它的环境中**，而不是一刀切地选择单一云部署模型。 - -## Architecture - -``` -┌─────────────────────────────────────────────────────────┐ -│ 混合云架构 │ -│ │ -│ ┌─────────────────────┐ ┌─────────────────────┐ │ -│ │ 私有云环境 │ │ 公有云环境 │ │ -│ │ ┌───────────────┐ │ │ ┌───────────────┐ │ │ -│ │ │ 敏感数据工作负载│ │ │ │ 弹性计算工作负载 │ │ │ -│ │ │ 核心业务系统 │◄─┼─────┼─►│ 峰值流量处理 │ │ │ -│ │ │ 受监管的工作负载│ │ │ │ 开发测试环境 │ │ │ -│ │ └───────────────┘ │ │ │ SaaS 应用 │ │ │ -│ │ │ │ └───────────────┘ │ │ │ -│ │ 专用物理服务器 │ │ │ │ │ -│ │ 本地数据中心 │ │ AWS / Azure / GCP │ │ │ -│ └─────────────────────┘ └─────────────────────┘ │ │ -│ │ │ │ -│ ┌──────────┴──────────┐ │ -│ │ 集成层（网络/数据） │ │ -│ │ - VPN / 专线连接 │ │ -│ │ - 数据同步 │ │ -│ │ - 统一身份管理 │ │ -│ └─────────────────────┘ │ -└─────────────────────────────────────────────────────────┘ -``` - -## Common Use Cases - -### 1. 核心 + 弹性模型 -``` -私有云：核心业务应用、数据库、敏感数据 -公有云：弹性扩展资源、峰值流量处理、CDN - -示例：电商平台 -- 私有云：订单系统、支付处理、客户数据 -- 公有云：双11大促峰值扩展 -``` - -### 2. 安全 + 成本模型 -``` -私有云：敏感数据、合规要求高的工作负载 -公有云：非敏感工作负载、开发测试环境 - -示例：医疗机构 -- 私有云：患者病历、HIPAA合规数据 -- 公有云：公开网站、健康资讯应用 -``` - -### 3. 本地 + 云爆发模型 -``` -私有云：日常稳定工作负载 -公有云：临时性高计算需求（突发工作负载） - -示例：工程仿真 -- 私有云：日常设计工作 -- 公有云：新项目仿真计算峰值 -``` - -## Advantages - -### 1. 策略驱动的灵活性 -- 基于安全、性能、成本需求灵活部署工作负载 -- 策略即代码（Policy-as-Code）自动化分配 -- 持续优化工作负载位置 - -### 2. 安全地扩展 -- 公有云的弹性扩展能力，无需将敏感工作负载暴露于安全风险 -- 敏感工作负载保留在私有云 -- 按需使用公有云资源，无需长期承诺 - -### 3. 最大化可靠性 -- 跨多个数据中心分发服务（公私混合） -- 不将可用性依赖于单一环境 -- 灾难恢复增强 - -### 4. 成本控制与效率 -- 敏感工作负载运行在私有云专用资源 -- 常规工作负载分布到廉价公有云基础设施 -- 投资回报优化 - -### 5. 互操作性和移动性 -- 工作负载在公私环境之间平滑移动 -- 跨环境访问和使用数据和应用 -- 统一身份和访问管理 - -### 6. 优化的负载分配 -- 敏感工作负载在私有云处理 -- 其他所有工作负载在公有云处理 -- 每个工作负载运行在最适合的环境 - -### 7. 业务连续性 -- 混合分布性质使灾难恢复更简单快速 -- 分布式架构降低单点故障风险 -- RTO/RPO优化 - -## Drawbacks - -### 1. 复杂的成本管理 -- 公私之间的切换难以跟踪 -- 可能导致浪费性支出 -- 需要精细的 FinOps 实践 - -### 2. 集成挑战 -- 不同位置和类别的云基础设施需要强兼容性 -- 跨云网络配置复杂 -- 数据一致性和同步挑战 - -### 3. 增加复杂性 -- 额外的架构复杂性 -- 需要同时管理公私两种环境 -- 运维团队技能要求更高 - -### 4. 安全风险 -- 跨云数据传输引入漏洞 -- 需要额外的网络安全控制 -- 合规边界更复杂 - -## Homogeneous vs Heterogeneous - -选择混合云后，还需决定云供应商策略： - -| 类型 | 定义 | 优势 | 劣势 | -|------|------|------|------| -| **同构混合云** | 使用单一云厂商的公私产品 | 简化管理、一致工具链、统一支持 | 供应商锁定 | -| **异构混合云** | 使用多个云厂商的混合 | 避免锁定、最佳组合 | 管理复杂性高 | - -示例： -- 同构：AWS Outposts + AWS 公有云 -- 异构：Azure Stack + AWS 公有云 - -## When to Use Hybrid Cloud - -| 场景 | 说明 | -|------|------| -| **多垂直领域的组织** | 不同业务线有不同IT安全、监管和性能要求 | -| **优化云投资** | 希望在不牺牲价值的前提下优化成本 | -| **增强现有云安全** | SaaS产品需要通过安全私有网络交付 | -| **战略性云投资** | 持续在最佳可用服务交付模式之间权衡 | -| **迁移过渡期** | 从本地向云迁移的渐进式路径 | -| **合规+弹性需求** | 既要数据本地化又要弹性扩展 | - -## Decision Framework - -``` -开始：评估工作负载特征 - ↓ - 这是敏感/受监管数据吗？ - /是的\ \否/ - ↓ ↓ - 私有云优先 这是稳定的基线负载吗？ - ↓ /是\ \否/ - 需要弹性和峰值容量？ ↓ ↓ - /是\ \否/ 私有云 公有云优先 - ↓ ↓ ↓ - 混合云 完成 需要弹性扩展？ - ↑ /是\ \否/ - └───────\ ↓ - 需要数据本地化？ - /是\ \否/ - ↓ ↓ - 混合云 公有云优先 -``` - -## Related Concepts - -- [[Public Cloud]] — 公有云 -- [[Private Cloud]] — 私有云 -- [[Multi-Cloud Strategy]] — 多云策略（对比） -- [[Shared Responsibility Model]] — 共享责任模型 -- [[Cloud Adoption Strategy]] — 云采用策略 -- [[FinOps]] — 云财务管理 -- [[Disaster Recovery Planning]] — 灾难恢复规划 -- [[Cloud Security]] — 云安全 -- [[Vendor-Lock-In]] — 供应商锁定 - -## See Also - -- [[Cloud Computing]] — 云计算基础 -- [[Cloud-Maturity-Model]] — 云成熟度模型 -- [[Cloud-Adoption-Strategy]] — 云采用策略 -- [[Cloud-Governance]] — 云治理 -- [[High Availability]] — 高可用性 -- [[Scalability]] — 可扩展性 diff --git a/wiki/concepts/Hybrid-Search.md b/wiki/concepts/Hybrid-Search.md deleted file mode 100644 index ee51a318..00000000 --- a/wiki/concepts/Hybrid-Search.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "HybridSearch" -type: concept -tags: [] ---- - -## Definition -混合搜索，结合多种检索方法以获得比单一搜索方法更优的结果。 - -## Key Characteristics -- 结合语义相似度搜索（稠密向量）与关键词精确匹配（BM25） -- 通过倒数排名融合（RRF）综合多个搜索结果的排名 -- 兼顾"按意思查找"和"按关键词查找"两种需求 - -## How It Works -1. **稠密向量搜索**：将查询和文档都嵌入到向量空间，计算语义相似度 -2. **BM25 搜索**：基于词频和文档频率的传统关键词匹配 -3. **RRF 融合**：综合两个排名列表，生成最终排序 - -## Use Cases -- [[memsearch]] 使用混合搜索提升记忆检索精度 -- [[Knowledge-Base-RAG]] 混合搜索优化知识库查询 - -## Related Concepts -- [[Semantic-Search]] — 纯语义搜索（仅向量） -- [[Reciprocal-Rank-Fusion]] — 倒数排名融合 -- [[RAG]] — 检索增强生成技术 diff --git a/wiki/concepts/HybridDnsResolution.md b/wiki/concepts/HybridDnsResolution.md deleted file mode 100644 index fb7065a1..00000000 --- a/wiki/concepts/HybridDnsResolution.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Hybrid DNS Resolution" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-24 ---- - -## Hybrid DNS Resolution - -混合 DNS 解析，指在 AWS VPC 环境与本地数据中心（On-prem）之间实现跨环境的域名解析能力，是企业云迁移和混合云架构的关键基础设施。 - -## Problem - -在企业迁移到 AWS Landing Zone 的过程中，存在以下 DNS 解析需求： -- AWS 内部的 VPC 需要解析本地数据中心的内部域名（如 `corp.internal`） -- 本地数据中心的服务器需要解析 AWS VPC 内部的私有域名（如 `int-sas.local`） -- 跨账号的 VPC 之间需要相互解析 - -传统的分散式 DNS 管理无法有效解决这些问题。 - -## Solution: Route 53 Resolver Endpoints - -AWS Route 53 Resolver 提供两个关键组件实现混合 DNS： - -### Inbound Endpoints（入站终端节点） - -- 用途：接收来自**本地数据中心**的 DNS 查询请求 -- 机制：本地 DNS 服务器将针对 AWS 私有域名的查询转发至 Inbound Endpoint 的 IP -- 场景：本地用户访问 AWS 内部的私有服务（如 `*.int-sas.local`） - -### Outbound Endpoints（出站终端节点） - -- 用途：将** AWS VPC 内部**的 DNS 查询转发至本地 DNS 服务器 -- 机制：通过 Resolver Rules（解析规则）定义哪些域名需要转发，以及转发到哪个 IP -- 场景：AWS 工作负载需要访问本地资源（如 GitHub Enterprise、遗留数据库） - -## Cross-Account Architecture - -在 AWS Landing Zone 中，集中化 DNS 管理的标准架构： - -1. **专用 DNS 账号**：在 Landing Zone 中设立专门的 DNS 账号（曾被称为 InfoBlocks 账号） -2. **Private Hosted Zones (PHZ)**：在 DNS 账号中集中管理所有私有托管区 -3. **AWS RAM 共享**：通过 Resource Access Manager 将 Resolver Rules 共享给各业务账号 -4. **VPC 关联授权**：跨账号关联时，必须先由 PHZ 拥有者授权，再由 VPC 拥有者执行关联 -5. **Terraform 自动化**：新账号创建时自动完成规则共享与 VPC 关联 - -## Key Concepts - -- [[Private Hosted Zone]]：AWS Route 53 私有托管区，在指定 VPC 内部解析自定义域名 -- [[Route 53 Resolver Rules]]：解析规则，定义域名的转发路径 -- [[VPC Association Authorization]]：跨账号关联的先授权后关联流程 -- [[AWS RAM]]：跨账号资源共享机制 -- [[AWS Landing Zone]]：DNS 架构的承载基础 - -## Aliases - -- Hybrid DNS -- Cross-Cloud DNS -- On-Premises DNS Integration diff --git a/wiki/concepts/HybridFingerprinting.md b/wiki/concepts/HybridFingerprinting.md deleted file mode 100644 index 1eb2a714..00000000 --- a/wiki/concepts/HybridFingerprinting.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Hybrid Fingerprinting" -type: concept -tags: [] -last_updated: 2026-05-01 ---- - -## Definition - -结合精确匹配（SHA-256 主键哈希）与模糊匹配（向量语义相似度）两种信号，防止因表面相似而误合并不同记录的混合指纹识别机制。 - -## The Problem - -纯语义相似度是模糊的： -- `"John Doe ID:101"` 与 `"Jon Doe ID:102"` 语义高度相似 -- 但主键不同（ID:101 ≠ ID:102），实际上是两条不同的记录 -- 若仅依赖语义相似度，可能被错误聚类合并 - -## Solution - -``` -Hybrid Score = SHA-256(PK_hash) + Vector_Similarity(embedding) -``` - -- **PK Hash differs** → 强制分离聚类，不允许合并 -- **PK Hash matches** → 才考虑向量相似度进行聚类 - -## Implementation - -```python -# 伪代码 -for each candidate_pair: - if sha256(pk1) != sha256(pk2): - force_separate_clusters() # PK不同，强制分离 - else: - if vector_similarity(embedding1, embedding2) > threshold: - merge_clusters() # PK相同且语义相似，才合并 -``` - -## Related - -- [[Semantic Anomaly Compression]] -- [[Air-Gapped SLM Fix Generation]] diff --git a/wiki/concepts/Hyperautomation.md b/wiki/concepts/Hyperautomation.md deleted file mode 100644 index f18b42b4..00000000 --- a/wiki/concepts/Hyperautomation.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Hyperautomation" -type: concept -tags: [automation, devops, ai, itsm] -date: 2025-03-01 ---- - -## Definition - -超自动化（Hyperautomation）是Gartner提出的技术趋势，指融合多种自动化技术（RPA、工作流引擎、ML、AI）实现**端到端流程自动化**的最大化。它超越了简单的流程自动化，追求组织内所有可自动化流程的识别和自动化。 - -## Core Components - -``` -┌─────────────────────────────────────────────────────────────┐ -│ Hyperautomation Stack │ -├─────────────────────────────────────────────────────────────┤ -│ Process Discovery → RPA → Workflow → AI/ML → IoT │ -│ ↓ ↓ ↓ ↓ ↓ │ -│ 流程识别 机器人 编排 智能决策 边缘自动化 │ -└─────────────────────────────────────────────────────────────┘ -``` - -### Technology Components - -| 技术 | 作用 | 示例 | -|------|------|------| -| RPA | 模拟人类操作 | UI自动化 | -| Workflow Engine | 流程编排 | n8n, Airflow | -| AI/ML | 智能决策 | 预测分析 | -| iPaaS | 系统集成 | API网关 | -| Low-Code | 快速开发 | 流程构建 | - -## In ITSM Context - -在[[ITSM 2.0]]中，超自动化是核心技术引擎： - -1. **[[Problem-Management]]** — 自动识别重复问题模式 -2. **[[Incident-Management]]** — 自动分类和路由工单 -3. **[[Change-Management]]** — 自动影响评估和审批 -4. **[[Security-and-Compliance]]** — Policy-as-Code自动执行 - -## Hyperautomation vs Automation - -| 维度 | 传统自动化 | 超自动化 | -|------|-----------|---------| -| 范围 | 单点流程 | 端到端 | -| 智能 | 规则驱动 | AI增强 | -| 发现 | 人工识别 | 自动发现 | -| 适应 | 静态 | 动态学习 | - -## Related Concepts - -- [[AIOps]] — AI驱动的运维智能 -- [[Self-Healing-Systems]] — 自愈自动化 -- [[Policy-as-Code]] — 策略自动化 -- [[ITSM 2.0]] — 超自动化的主要应用场景 - -## Sources - -- [[understanding-complete-itsm]] — ITSM 2.0中的超自动化应用 diff --git a/wiki/concepts/IANG-Visa.md b/wiki/concepts/IANG-Visa.md deleted file mode 100644 index a6b84a74..00000000 --- a/wiki/concepts/IANG-Visa.md +++ /dev/null @@ -1,48 +0,0 @@ -# IANG Visa - -## Definition - -IANG（Immigration Arrangement for Non-local Graduates，非本地毕业生留港就业安排）——香港特别行政区政府为在港修读经本地认证全日制课程的非本地毕业生提供的留港就业签证安排。 - -## Core Features - -| 特性 | 说明 | -|------|------| -| 适用范围 | 在港修读经本地认证的全日制本地认可课程（学士/硕/博） | -| 逗留期限 | 首次获批 12 个月，其后每次续签 3 年 | -| 逗留条件 | 在港就业/创办业务（无最低薪资要求） | -| 配额限制 | **无配额限制** | -| 受养人 | 可携带配偶及 18 岁以下子女 | -| 申请时间 | 毕业后 6 个月内可在港申请（无需提前找到工作） | - -## Post-Study Work Pathway - -``` -毕业 → 申请 IANG（毕业后6个月内）→ 首次12个月签证 -→ 就业/创业续签（每次3年）→ 7年连续居住 → 香港永久居民 -``` - -## Key Advantages for Chinese Students - -1. **无需提前找到工作**——可在毕业前后申请，审批期间合法逗留 -2. **无配额上限**——相对英国 PSW、美国 OPT 的竞争性抽签，IANG 是确定性路径 -3. **家庭随行**——配偶及子女可获受养人签证，子女享香港教育资源 -4. **粤港澳大湾区机遇**——IANG 身份可同时享受大湾区政策支持 -5. **转永居路径清晰**——7 年连续合法逗留即可申请永居 - -## Key Considerations - -- **续签必须实际在港就业/创业**——不可长期离港而不续签，否则断签 -- **受雇无需特定薪资门槛**，但申请永居时移民局会综合评估 -- iang 签证期间可换工作，无需通知入境处 -- iang 签证可在香港创办/加入 Startup 工作，符合条件可获额外逗留 - -## Relationship to Study Abroad Planning - -[[study-abroad-advisor]] 在推荐香港留学时，IANG 是核心卖点之一。相比英国 PSW（需抽签）、美国 OPT（需 H-1B 抽签），IANG 的确定性使其成为注重留港发展/移民的学生的首选目的地。典型选校策略：香港大学（HKU）/香港中文大学（CUHK）/香港科技大学（HKUST）的一年制授课硕士 + IANG 续签，是高性价比的留港路径。 - -## Aliases -- 非本地毕业生留港就业安排 -- Immigration Arrangement for Non-local Graduates -- Hong Kong Post-Study Work Visa -- 香港毕业生留港签证 diff --git a/wiki/concepts/IAST.md b/wiki/concepts/IAST.md deleted file mode 100644 index e24a89c7..00000000 --- a/wiki/concepts/IAST.md +++ /dev/null @@ -1,76 +0,0 @@ -# IAST (Interactive Application Security Testing) - -## Definition -IAST tools evaluate applications while they run to detect security issues that SAST or SCA tools might overlook. They are beneficial during testing and deployment phases when examining how different components interact within the application is important. - -## Aliases -- Interactive Application Security Testing -- Grey-box testing -- Instrumentation-based testing - -## Characteristics -- **运行时分析**：在应用运行时进行监控 -- **灰盒测试**：结合白盒和黑盒方法 -- **精确检测**：能准确定位漏洞位置 -- **低误报率**：基于实际执行分析 - -## How IAST Works - -### Instrumentation -IAST 工具在应用中植入代理（Agent）： -- 监控应用执行路径 -- 分析数据流 -- 检测不安全操作 - -### Agent Deployment -- Web 服务器插件 -- 应用服务器插件 -- 容器环境支持 -- 云函数支持 - -## What IAST Detects -- 运行时数据流问题 -- API 安全问题 -- 认证/授权问题 -- 配置错误 -- 与 [[SAST]] 和 [[DAST]] 互补的漏洞 - -## Comparison with Other Testing Methods - -| 维度 | SAST | DAST | IAST | -|------|------|------|------| -| **测试方式** | 白盒（静态） | 黑盒（动态） | 灰盒（运行时） | -| **需要代码** | 是 | 否 | 是（代理） | -| **误报率** | 中等 | 低 | 低 | -| **检测范围** | 代码层 | 应用层 | 代码+应用层 | -| **适用阶段** | 开发 | 测试/部署 | 测试 | -| **性能影响** | 无 | 中等 | 低-中等 | - -## Tools -- Contrast Assess -- Hdiv -- Quotium Q360 -- AppCheck - -## Integration -IAST 通常集成到： -- 自动化测试环境 -- QA 测试流程 -- CI/CD 管道（测试阶段） -- 预生产环境 - -## Advantages -- 高准确性（低误报） -- 精确的漏洞定位 -- 不中断开发流程 -- 可用于生产监控 - -## Related Concepts -- [[DevSecOps]] — IAST 是其重要组件 -- [[SAST]] — 静态应用安全测试 -- [[DAST]] — 动态应用安全测试 -- [[SCA]] — 软件组成分析 -- [[RASP]] — 运行时应用自我保护 - -## Sources -- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/ICP-Filing.md b/wiki/concepts/ICP-Filing.md deleted file mode 100644 index eafee3e4..00000000 --- a/wiki/concepts/ICP-Filing.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: "ICP Filing" -type: concept -tags: ["china", "compliance", "legal", "website-operation"] -sources: [] -last_updated: 2026-04-26 ---- - -# ICP Filing（ICP 备案） - -## Aliases -- ICP 备案 -- ICP Filing -- ICP License -- 互联网内容提供商备案 -- 网站备案 - -## Definition -ICP 备案（Internet Content Provider Filing）是中国工业和信息化部要求的法定备案制度，所有在中国大陆提供互联网信息服务的网站必须完成备案。是网站合法运营和百度搜索排名的前提条件。 - -## Legal Basis -- **《互联网信息服务管理办法》**：经营性网站需取得 ICP 许可证，非经营性网站需备案 -- **《网络安全法》**：要求网站运营者提供真实身份信息 -- **《信息安全技术 - 个人信息安全规范》**：配合数据本地化要求 - -## ICP 备案类型 - -| 类型 | 适用场景 | 申请主体 | 审批时间 | -|------|----------|----------|----------| -| ICP 备案（Filing） | 非经营性网站 | 个人或企业 | 3-20 工作日 | -| ICP 许可证（License）| 经营性网站（收费服务）| 企业，需注册资本 | 60+ 工作日 | - -## ICP 备案对 SEO 的影响 - -- **无备案 = 无排名**：百度会严重降权甚至完全排除未备案网站 -- **有备案 = 基础信任信号**：百度将备案视为网站质量的基础信任指标 -- **备案号展示**：部分网站在百度搜索结果中显示备案号，增强用户信任 - -## Baidu SEO 中的定位 - -> "Without a valid ICP备案, nothing else we do matters - that's step zero" -> — Marketing Baidu SEO Specialist - -**ICP 备案是中国市场所有数字营销工作的 Step Zero：** -1. 完成 ICP 备案（4-20 工作日） -2. 部署中国大陆服务器 -3. 安装百度站长工具并验证 -4. 才开始进行关键词研究和内容优化 - -## 备案流程概要 - -### 企业备案 -1. 准备材料：营业执照、法人身份证、网站负责人身份证、域名证书 -2. 在接入服务商（阿里云/腾讯云）提交备案申请 -3. 管局审核（通常 7-15 工作日） -4. 备案成功，获得备案号，添加到网站底部 - -### 个人备案 -1. 个人身份证、域名证书 -2. 通过接入服务商提交 -3. 管局审核（通常 3-7 工作日） -4. 注意：个人备案不可进行经营性内容 - -## Related Sources -- [[Marketing-Baidu-SEO-Specialist]]：明确将 ICP 备案作为 SEO 工作的第一步 diff --git a/wiki/concepts/ICP-Ideal-Customer-Profile.md b/wiki/concepts/ICP-Ideal-Customer-Profile.md deleted file mode 100644 index 97d5f5d2..00000000 --- a/wiki/concepts/ICP-Ideal-Customer-Profile.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "ICP (Ideal Customer Profile)" -type: concept -tags: [sales, outbound, targeting] -sources: [sales-outbound-strategist] -last_updated: 2026-04-25 ---- - -## Definition - -ICP 是可证伪的理想客户画像——一个能够**明确排除**不符合条件的公司的定义，而非泛泛的目标市场总地址（TAM）。 - -> "如果你的 ICP 不能排除任何公司，它就不是 ICP，而是 TAM 幻灯片。" - -## ICP 三层结构 - -### 1. Firmographic Filters（公司特征） -``` -- 行业垂直（2-4 个具体行业，而非"企业"） -- 收入范围或员工规模区间 -- 地理区域（如与 go-to-market 相关） -- 技术栈要求（他们必须已经使用什么？） -``` - -### 2. Behavioral Qualifiers（行为限定） -``` -- 什么业务事件使他们成为"现在的买家"？ -- 你的产品解决的痛点是什么，他们无法忽视？ -- 组织内部谁最强烈地感受这个痛点？ -- 他们当前的替代方案是什么？ -``` - -### 3. Disqualifiers（排除条件）——同等重要 -``` -- 什么样的账户看起来很好但永远不会成交？ -- 哪些行业或细分市场你的赢率低于 15%？ -- 哪些公司阶段你的产品还为时过早或过于复杂？ -``` - -## Why Disqualifiers Matter - -大多数销售团队只定义"谁是我的目标"，但： -- 错误客户消耗最多资源 -- 错误客户有最低赢率和最高流失率 -- 明确的排除条件节省销售时间用于正确客户 - -## ICP vs TAM - -| | ICP | TAM | -|--|-----|-----| -| 目的 | 指导销售执行和资源配置 | 投资者/管理层展示市场规模 | -| 可证伪性 | ✅ 必须能排除公司 | ❌ 通常是"越大越好" | -| 销售使用 | 日常决策（路由、优先排序） | 年度汇报 | - -## Connections - -- [[sales-outbound-strategist]] — ICP 框架来源 -- [[Signal-Based Selling Framework]] — ICP 定义触发信号路由 -- [[Account Tiering Model]] — ICP 匹配决定账户层级 -- [[Land-and-Expand]] — ICP 内现有客户的扩张策略 diff --git a/wiki/concepts/IDENTITY.md.md b/wiki/concepts/IDENTITY.md.md deleted file mode 100644 index 5a5468e4..00000000 --- a/wiki/concepts/IDENTITY.md.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "IDENTITY.md" -type: concept -tags: [OpenClaw, Agent, Identity] -sources: [万字讲透openclaw-workspace深度解析-2026-03-21] -last_updated: 2026-03-21 ---- - -## Definition - -**IDENTITY.md** 是 OpenClaw workspace 中存储 Agent **结构化身份元数据**的文档。与 SOUL.md 的叙事性性格文档分工明确：IDENTITY.md 是名片（结构化元数据），SOUL.md 是人物小传（叙事性性格）。 - -## 核心字段 - -- **Name**：Agent 在界面和对话里的显示名 -- **Creature**：Agent 的存在类型（AI assistant / ghost / familiar / robot 等） -- **Vibe**：Agent 的感觉描述（直接、毒舌、靠谱等） -- **Emoji**：UI 中的标识符 -- **Avatar**：头像（workspace 相对路径 / URL / data URI） - -## 与 SOUL.md 的分工 - -| | IDENTITY.md | SOUL.md | -|---|---|---| -| 性质 | 结构化元数据 | 叙事性文档 | -| 内容 | 谁、长什么样、什么感觉 | 怎么思考、怎么行事、有什么执念 | -| 类比 | 名片 | 人物小传 | - -## Related Concepts - -- [[SOUL.md]] — 叙事性性格文档，与 IDENTITY.md 互补 -- [[BOOTSTRAP.md]] — 初始化时写入 IDENTITY.md 的引导流程 -- [[OpenClaw]] — IDENTITY.md 所属的框架 - diff --git a/wiki/concepts/IGA.md b/wiki/concepts/IGA.md deleted file mode 100644 index 97951612..00000000 --- a/wiki/concepts/IGA.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "IGA" -type: concept -tags: - - Identity-Governance - - IAM - - Access-Management -sources: - - learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re -last_updated: 2026-05-11 ---- - -## IGA (Identity Governance and Administration) - -IGA（身份治理与管理）是一个企业级身份管理框架，涵盖身份生命周期管理和访问治理两大支柱。 - -## Core Components - -### Identity Management（身份管理） -- 数字身份的创建、维护和生命周期管理 -- 用户、组和角色的定义 -- 入职/转岗/离职的权限变更 - -### Access Management（访问管理） -- 控制谁可以访问哪些资源 -- 认证（Authentication）和授权（Authorization） - -### Identity Auditing（身份审计） -- 权限变更追踪 -- 合规性报告 -- 异常检测 - -## IGA vs IAM - -| 维度 | IGA（身份治理） | IAM（身份与访问管理） | -|------|----------------|----------------------| -| 焦点 | 治理、合规、策略 | 操作、技术实现 | -| 问题 | 谁应该有权访问？ | 如何实现访问控制？ | -| 受众 | 审计员、合规官、业务经理 | IT 管理员、安全工程师 | -| 工具 | 审批工作流、策略引擎 | 目录服务、SSO、MFA | - -## IGA Implementation - -Micro Focus IGA 的实现架构： -``` -User → IGA Portal (申请) → 审批工作流 → AD 组更新 → AWS IAM → 云资源访问 -``` - -## Related Concepts - -- [[Identity-Governance]]：IGA 是身份治理的具体实现 -- [[AWS-Identity-Center]]：AWS 身份中心的云端访问管理 -- [[Micro-Focus-IGA]]：Micro Focus 的 IGA 产品 - -## Sources - -- [[learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re]] diff --git a/wiki/concepts/INVEST.md b/wiki/concepts/INVEST.md deleted file mode 100644 index d4ae5ebb..00000000 --- a/wiki/concepts/INVEST.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "INVEST" -type: concept -tags: [Agile, Requirements, User-Stories, Quality] -sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109] -last_updated: 2026-05-11 ---- - -## Definition - -INVEST 是用于检查优质用户故事（User Story）的六项原则，由 Bill Wake 提出，是敏捷开发中需求质量保障的重要工具。 - -## INVEST 六原则 - -| 字母 | 原则 | 含义 | 反模式 | -|------|------|------|--------| -| **I** | Independent | 独立的——不与其他故事重复或依赖 | 包含另一个故事的内容 | -| **N** | Negotiable | 可协商的——业务方描述需求，技术方开放实现方式 | 过于详细的规定实现细节 | -| **V** | Valuable | 有价值的——对用户或客户有实际价值 | 只描述技术任务而无业务价值 | -| **E** | Estimable | 可估算的——团队能够估算工作量 | 需求描述过于模糊无法估算 | -| **S** | Small | 小型的——能在单个迭代中完成 | 需要跨越多个迭代才能完成 | -| **T** | Testable | 可测试的——能够验证是否完成 | 没有明确的验收标准 | - -## Key Quote - -> "Every requirement should be independent, meaning not duplicating something else, that's the I in INVEST, negotiable, so the business should state what they need, but be open to how it's implemented." - -## Usage - -INVEST 常用于： -- 冲刺规划前的故事评审 -- Product Backlog 的梳理会议 -- 需求审查和质量把控 - -## Relationship to Other Concepts - -- [[Requirements-Gathering]]：INVEST 是需求收集的质量检查工具 -- [[SAFe]]：在 SAFe 框架中，Feature 和 User Story 均适用 INVEST 检查 -- [[Business-Analysis]]：业务分析师负责确保需求符合 INVEST 原则 - -## Aliases -- INVEST Criteria -- INVEST 原则 -- Bill Wake INVEST diff --git a/wiki/concepts/IPAM.md b/wiki/concepts/IPAM.md deleted file mode 100644 index b48f68ce..00000000 --- a/wiki/concepts/IPAM.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: "IPAM" -type: concept -tags: [Networking, AWS, Automation, IP-Address-Management] -sources: - - ctp-topic-45-automatic-ip-address-allocation-with-ipam - - ctp-topic-61-workload-vpc-provision-with-ipam-automation - - ctp-topic-22-global-dns-service-offerings -last_updated: 2026-04-24 ---- - -## IPAM（IP Address Management） - -企业级 IP 地址管理平台，核心功能包括：**有效管理**、**控制**、**监控**和**分配**企业内部的 IP 地址空间。IPAM 通过集中化和自动化手段，替代传统的手工 Excel 管理模式。 - -## Problem Statement - -传统 IP 地址管理依赖 Excel 电子表格： -- **效率低**：每次 VPC 供给需与网络团队多次交接 -- **易出错**：手工规划易产生 IP 地址重叠冲突 -- **不可追溯**：缺乏统一的变更历史记录 -- **无法自动化**：IP 地址分配无法与 IaC 流水线集成 - -## Core Capabilities - -1. **集中化管理**：单一可信数据源管理所有 IP 地址分配 -2. **自动化供给**：通过 API 与 IaC 工具集成，自动分配下一可用 IP 地址块 -3. **生命周期管理**：VPC 销毁时自动回收 IP 地址 -4. **审批工作流**：基于 CIDR 大小的差异化审批规则 -5. **可扩展属性**：存储元数据（owner、company、subnet_name、status 等） - -## Implementation: Infoblox NIOS - -本 Wiki 中 IPAM 的核心实现为 **Infoblox NIOS**： - -- **Grid 架构**：分布式网格架构，包含主数据库和冗余 DNS/NTP/DHCP 服务 -- **API 驱动**：通过 API 调用自动分配 IP 地址 -- **与 AWS 集成**：作为 VPC 自动化供给流程的 IP 地址来源 - -## Key Concepts - -- [[Infoblox-NIOS]]：核心网络控制平面 -- [[Infoblox-Grid]]：分布式网格架构 -- [[CIDR-审批流程]]：基于 CIDR 大小的审批规则 -- [[VPC-自动化供给]]：IPAM 驱动的声明式 VPC 创建 - -## Key Entities - -- [[Pushka]]（Principal SRE）：IPAM 自动化方案的发起人 -- [[Infoblox]]：IPAM 供应商 -- [[AWS-Landing-Zone]]：IPAM 实施的背景环境 - -## Connections - -- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← mechanism ← **IPAM** - - 介绍 IPAM 的核心机制和 YAML 驱动方式 -- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← application ← **IPAM** - - 展示 IPAM 在 Workload VPC 供给中的完整应用 -- [[ctp-topic-22-global-dns-service-offerings]] ← shares_infra ← **IPAM** - - Infoblox 同时支撑 DNS Anycast 和 IPAM - -## Aliases - -- IP Address Management -- IP Address Management System -- IPAM 系统 diff --git a/wiki/concepts/IPv6-in-EKS.md b/wiki/concepts/IPv6-in-EKS.md deleted file mode 100644 index 7c05ba53..00000000 --- a/wiki/concepts/IPv6-in-EKS.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "IPv6 in EKS" -type: concept -tags: - - AWS - - EKS - - IPv6 - - Networking - - IP-Address-Exhaustion -sources: - - ctp-topic-64-scaling-out-with-amazon-eks -last_updated: 2026-04-28 ---- - -## Definition -IPv6-in-EKS 是 Amazon EKS 集群解决 IP 地址耗尽（IP Exhaustion）问题的网络架构方案，通过部署 IPv6 或双栈（Dual-Stack）VPC，实现大规模容器工作负载的 IP 地址可持续供给。 - -## Problem Statement -- 每个 EKS 节点上的 ENI（Elastic Network Interface）附带可分配的 IP 地址数量有限 -- VPC CIDR 块大小固定，Pod 数量增长导致可用 IP 耗尽 -- 自定义网络（Custom Networking）和 Prefix Delegation 可缓解但不能根本解决 - -## Solution: IPv6 Dual-Stack VPC -- **双栈架构**：VPC 同时支持 IPv4 和 IPv6 地址 -- **节点双协议栈**：EKS 节点同时持有 IPv4 和 IPv6 地址 -- **Pod 仅 IPv6**：Pod 仅分配 IPv6 地址（节省 IPv4 空间） -- **NAT 映射**：IPv6 Pod 与 IPv4 目标通信时，通过双层 NAT 映射转换 - -## Alternative: Carrier-Grade NAT (CGNAT) -- 如无法迁移至 IPv6，可使用 CGNAT 方案 -- 通过自定义网络 + NAT 网关聚合多个 Pod 的出站流量 - -## Benefits -- IP 地址空间近乎无限（解决耗尽问题） -- 简化网络配置（无需管理大量 IPv4 地址） -- 符合云原生网络发展趋势 - -## Sources -- [[ctp-topic-64-scaling-out-with-amazon-eks]] diff --git a/wiki/concepts/IP纯净度.md b/wiki/concepts/IP纯净度.md deleted file mode 100644 index bc029518..00000000 --- a/wiki/concepts/IP纯净度.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "IP纯净度" -type: concept -tags: [ip, risk-assessment, security] -date: 2025-12-31 ---- - -# IP纯净度 - -## 定义 -IP纯净度是评定某个IP地址是否安全可靠的风险等级，通过分析IP的历史使用记录、是否被标记为垃圾邮件源、VPN/代理使用情况等因素，计算出一个风险评分。 - -## 检测工具 -- **Scamalytics**: https://scamalytics.com/ — 主流IP风险评估网站 -- **IP111**: https://ip111.cn/ — IP归属地检测 - -## 风险等级 - -### 低风险（推荐） -- 数值低，分数越低越安全 -- IP信誉良好，无异常记录 -- 适合注册重要账号 - -### 中等风险（谨慎） -- 存在一定的历史问题 -- 可能被部分平台标记 -- 增加封号风险 - -### 高风险（避免） -- IP信誉差，有明显异常记录 -- 被多个平台标记 -- 极大概率导致封号 - -## 关键原则 -> **数值越低越安全** — 必须使用低风险IP才能有效降低账号封禁概率 - -## IP一致性检测 -使用多个网站检测，确保IP归属一致： -1. 国内IP检测网站 -2. 国外IP检测网站 -3. Google IP检测 - -**三处必须完全一致**，否则可能被平台判定异常。 - -## 影响纯度的因素 -- 是否为数据中心IP（住宅IP更优） -- 历史是否用于发送垃圾邮件 -- 是否被VPN/代理服务大量使用 -- 是否在黑名单中 -- DNS泄漏情况 - -## 相关概念 -- [[Socks5代理]] -- [[账号隔离]] -- [[指纹浏览器]] - -## 来源 -- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]] diff --git a/wiki/concepts/ISO-27001.md b/wiki/concepts/ISO-27001.md deleted file mode 100644 index 28feba84..00000000 --- a/wiki/concepts/ISO-27001.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "ISO-27001" -type: concept -tags: - - Security-Framework - - Compliance - - Information-Security -last_updated: 2026-04-14 ---- - -# ISO-27001 - -## Definition -国际认可的信息安全管理体系（ISMS）标准，由国际标准化组织（ISO）和国际电工委员会（IEC）发布。ISO 27001 是企业信息安全管理的基准框架。 - -## OpenText Implementation -- 作为 OpenText 安全姿态框架（Posture Framework）的基础 -- 2022 年更新，新增 11 个控制方面（control aspects） -- 支撑 [[Global Information Security Policy (GISP)]] 的框架基础 -- 支撑 [[FedRAMP]] 等行业认证 - -## Key Controls -- 信息安全组织（Information Security Organization） -- 人力资源安全（Human Resource Security） -- 资产管理（Asset Management） -- 访问控制（Access Control） -- 加密（Cryptography） -- 物理与环境安全（Physical and Environmental Security） -- 操作安全（Operations Security） -- 通信安全（Communications Security） -- 系统获取、开发和维护（System Acquisition, Development and Maintenance） -- 供应商关系（Supplier Relationships） -- 信息安全事件管理（Information Security Incident Management） -- 业务连续性管理（Business Continuity Management） -- 合规性（Compliance） - -## Connections -- [[Global Information Security Policy (GISP)]]：基于 ISO 27001 构建 -- [[FedRAMP]]：基于 ISO 27001 之上 -- [[OpenText]]：采用该标准的企业 diff --git a/wiki/concepts/ISOHybrid镜像.md b/wiki/concepts/ISOHybrid镜像.md deleted file mode 100644 index 45671b37..00000000 --- a/wiki/concepts/ISOHybrid镜像.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "ISOHybrid镜像" -type: concept -tags: [iso, uefi, bios, boot, rufus] -date: 2026-04-14 -aliases: [ISOHybrid, hybrid ISO, 混合镜像] ---- - -# ISOHybrid镜像 - -## Definition -一种同时包含 BIOS (MBR) 和 UEFI 两种引导方式的 ISO 镜像文件格式，Ubuntu 官方 ISO 属于此类。使用 Rufus 等工具写入 U 盘时需要明确选择写入模式。 - -## Two Writing Modes -| 模式 | 适用场景 | 说明 | -|------|----------|------| -| **ISO 镜像模式** | 推荐首选 | 保留 ISO 结构，兼容性最佳 | -| **DD 镜像模式** | 备选（启动失败时） | 逐字节复制，适合某些顽固设备 | - -## Why It Matters -Rufus 写入 ISOHybrid 镜像时会弹出模式选择对话框。选错模式会导致 U 盘在目标设备上无法启动，尤其是 HP ZBook 等 UEFI 严格模式设备。 - -## HP ZBook 的 ISOHybrid 配置 -- **分区方案**：GPT（必须，配合 UEFI） -- **目标系统类型**：UEFI (non CSM)（自动匹配） -- **文件系统**：FAT32（UEFI 标准） - -## Related -- [[Rufus]] — 写入工具 -- [[HP ZBook]] — 目标设备 -- [[GPT分区表]] — 分区方案 -- [[ISOHybrid镜像]] ← 由 [[Rufus]] 写入至 [[HP ZBook]] - -## Sources -- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]] diff --git a/wiki/concepts/ITIL-Service-Management.md b/wiki/concepts/ITIL-Service-Management.md deleted file mode 100644 index dc6264fd..00000000 --- a/wiki/concepts/ITIL-Service-Management.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: ITIL Service Management -type: concept -tags: [ITIL, Framework, Process] -sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16] ---- - -# ITIL Service Management - -**ITIL（Information Technology Infrastructure Library）服务管理框架** 将业务流程分为五个阶段，是企业 IT 服务管理的国际标准方法论。 - -## Five Stages - -| 阶段 | 描述 | -|------|------| -| **Service Strategy（服务战略）** | 定义服务如何为客户创造价值 | -| **Service Design（服务设计）** | 设计新服务或变更服务 | -| **Service Transition（服务过渡）** | 构建和部署服务，需求管理对应此阶段 | -| **Service Operation（服务运营）** | 日常运维和支持 | -| **Continual Service Improvement（持续服务改进）** | 优化服务质量和效率 | - -## Application in Cloud Transformation - -在 OpenText 云转型过程中： -- **Oli Workflow** 对应请求履约的第一阶段（服务过渡阶段） -- **Demand Management** 是服务过渡阶段的关键活动 -- **Product Backlog** 支持持续服务改进 - -## Core Principles - -1. **以服务为导向**：一切活动都围绕服务交付 -2. **持续改进**：PDCA 循环不断优化 -3. **端到端治理**：覆盖服务全生命周期 - -## Related Concepts - -- [[Demand-Management]] — 需求管理 -- [[Oli-Workflow]] — 审批工作流 -- [[SMACs]] — 技术栈组合 -- [[FinOps]] — 云财务运营 - -## Related Entities - -- [[MUI]] — 审批人 -- [[Shannon]] — 审批人 - -## Sources - -- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] diff --git a/wiki/concepts/ITSM-2.0.md b/wiki/concepts/ITSM-2.0.md deleted file mode 100644 index fcefd444..00000000 --- a/wiki/concepts/ITSM-2.0.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "ITSM 2.0" -type: concept -tags: [cloud, devops, ai, itsm] -date: 2025-03-01 ---- - -## Definition - -ITSM 2.0是IT服务管理的下一代范式，融合[[AIOps]]和[[Hyperautomation]]技术，具备**自学习、预测性和自主化**能力。它代表了从传统反应式服务管理向主动预防式智能运营的根本转变。 - -## Core Characteristics - -| 特性 | 描述 | 技术支撑 | -|------|------|---------| -| **Self-Learning** | 系统从历史数据中学习，自动优化运维决策 | ML模型、反馈循环 | -| **Predictive** | 预测潜在故障，在问题发生前采取措施 | 预测分析、根因预测 | -| **Autonomous** | 自动化执行运维任务，减少人工干预 | AIOps、自愈系统 | - -## Key Enablers - -### 1. AIOps Integration -``` -事件数据 → ML模型 → 异常检测 → 根因分析 → 自动修复 -``` - -### 2. Hyperautomation -- [[Policy-as-Code]] — 合规策略自动化 -- [[Self-Healing-Systems]] — 故障自动恢复 -- 端到端流程机器人 - -### 3. ITSM 2.0 Eight Processes - -1. **[[Problem-Management]] 2.0** — AI驱动的根因预测 -2. **[[Incident-Management]] 2.0** — 自愈驱动的秒级响应 -3. **[[Change-Management]] 2.0** — 风险预测驱动的智能审批 -4. **[[Release-Management]] 2.0** — 渐进式交付与灰度发布 -5. **[[Configuration-Management]] 2.0** — AI增强的CMDB -6. **[[Asset-Management]] 2.0** — 智能生命周期管理 -7. **[[Security-and-Compliance]] 2.0** — ZTA + Policy-as-Code -8. **[[Disaster-Recovery]] 2.0** — DRaaS + RTO/RPO优化 - -## Industry Trend - -> "The convergence of AIOps, hyperautomation, and ITSM 2.0 is defining a new paradigm: self-learning, predictive, and autonomous IT operations." — shenwei, LinkedIn - -## Related Concepts - -- [[ITSM]] — 传统ITSM基础 -- [[AIOps]] — 运维智能核心 -- [[Hyperautomation]] — 自动化引擎 -- [[Self-Healing-Systems]] — 自主恢复能力 - -## Sources - -- [[understanding-complete-itsm]] — ITSM 2.0核心概念来源 diff --git a/wiki/concepts/ITSM.md b/wiki/concepts/ITSM.md deleted file mode 100644 index 3736fd5b..00000000 --- a/wiki/concepts/ITSM.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "IT Service Management (ITSM)" -type: concept -tags: [cloud, devops, operations, it-management] -date: 2025-03-01 ---- - -## Definition - -IT服务管理（ITSM）是一套用于设计、交付、管理和改进IT服务的方法论和实践。传统ITSM以工单处理为中心，而现代ITSM已演进为**企业运营卓越、风险缓解和创新加速的战略推动者**。 - -## Core Framework - -### Eight Core Processes (Modern ITSM) - -| 流程 | 核心功能 | 关键技术 | -|------|---------|---------| -| [[Problem-Management]] | 根因分析、预防重复故障 | AI异常检测、预测分析 | -| [[Incident-Management]] | 快速恢复、减少业务中断 | AIOps、自愈系统 | -| [[Change-Management]] | 受控变更、风险评估 | AI影响评估、IaC合规 | -| [[Release-Management]] | 渐进交付、零干扰发布 | Blue-Green、Canary | -| [[Configuration-Management]] | 依赖映射、漂移检测 | AI-CMDB、多云编排 | -| [[Asset-Management]] | 生命周期跟踪、成本优化 | SAM、云成本管理 | -| [[Security-and-Compliance]] | 风险评分、威胁情报 | ZTA、Policy-as-Code | -| [[Disaster-Recovery]] | 业务连续性、容灾 | DRaaS、RTO/RPO优化 | - -## Evolution - -``` -Traditional ITSM Modern ITSM ITSM 2.0 -───────────────── → ───────────── → ────────────── -- Ticketing-centric - Service-centric - AI-driven -- Reactive - Proactive - Predictive -- Manual - Automated - Autonomous -- Siloed - Integrated - Self-healing -``` - -## Key Technologies - -- **[[AIOps]]**：机器学习驱动的运维智能 -- **[[CMDB]]**：AI增强的配置管理数据库 -- **[[Hyperautomation]]**：端到端流程自动化 -- **[[Self-Healing-Systems]]**：自动化故障检测与修复 - -## Related Concepts - -- [[ITSM-2.0]] — 下一代ITSM，自学习、预测性、自主化 -- [[DevOps]] — ITSM与DevOps的文化融合 -- [[SRE]] — 站点可靠性工程与服务级别管理 -- [[ITIL]] — IT基础设施库，ITSM的方法论框架 - -## Sources - -- [[understanding-complete-itsm]] — 现代ITSM八大趋势与AI驱动转型 diff --git a/wiki/concepts/Idea-Density.md b/wiki/concepts/Idea-Density.md deleted file mode 100644 index 4114ea74..00000000 --- a/wiki/concepts/Idea-Density.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Idea-Density" -type: concept -tags: [content-creation, strategy, creativity] -sources: [if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间] -last_updated: 2026-04-27 ---- - -## Aliases -- 创意密度 -- 观点密度 -- 想法密度 - -## Definition -内容中高价值、高信号创意的集中程度。[[if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间]] 定义为： - -> **Idea Density = 表现力 × 兴奋度** - -- **表现力（Performance）**：该想法"成功"的潜力，衡量有多少人会关心 -- **兴奋度（Excitement）**：该想法让你感到非写不可的热情，衡量你有多在乎 - -两者缺一不可：仅表现力高 → 迎合算法；仅兴奋度高 → 自说自话无人问津。 - -## Why It Matters -- 创意密度随时间和努力累积提高，塑造出值得追随和付费的品牌 -- "创意密度" = 品牌护城河 -- 最好的创作者不是发帖最多的人，而是反复提炼出 5-10 个核心观点并不断深化的人 - -## How to Build Idea Density -1. **建立 [[Idea-Museum]]**：3-5 个高信号信息来源持续输入 -2. **筛选**：用"表现力 × 兴奋度"双重标准过滤 -3. **深度表达**：同一想法用 1000 种结构反复表达 -4. **AI 辅助分析**：让 AI 分析帖子结构、心理策略，复制成功模式 - -## Connections -- [[Idea-Museum]] — 创意密度的输入来源 -- [[Brand-Environment]] — 创意密度塑造品牌 -- [[Content-Creator]] — 创意密度是内容创作的核心竞争力 -- [[Generalist]] — 跨领域知识天然提高创意密度 diff --git a/wiki/concepts/Idea-Museum.md b/wiki/concepts/Idea-Museum.md deleted file mode 100644 index c0ffc733..00000000 --- a/wiki/concepts/Idea-Museum.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Idea-Museum" -type: concept -tags: [content-creation, learning, productivity] -sources: [if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间] -last_updated: 2026-04-27 ---- - -## Aliases -- 创意博物馆 -- 素材库 -- Swipe File -- 灵感库 - -## Definition -一个持续收集、整理高质量创意的系统（或笔记库），是创作体系的基础设施。[[if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间]] 视其为内容创作三步法的第一步。 - -## How to Build It -**核心原则**：每当你发现一个可能有用的想法（现在或不久的将来），就立刻记下来。不需要"内容支柱"或固定话题。 - -**推荐工具**：Eden、Apple Notes、Notion，或任何你习惯的软件。格式不重要，习惯比格式更重要。 - -**高密度信息来源**（3-5 个）： -1. **老书/小众书籍** — 永恒原则，不受趋势影响 -2. **精选博客/账号** — Farnam Street、Navalism 等策展型账号 -3. **高影响力社交账号** — 每次写作前浏览找灵感 - -## Why It's Critical -- 创意博物馆是你试图构建的思维方式的体现 -- 最终目标是：内容库好到人们忍不住打开邮件、打开通知、分享你的想法 -- 你的 [[Idea-Museum]] = 你 [[Brand-Environment]] 的根基 - -> "你会成为那些人们甚至不会想到向人工智能寻求，也永远不会自然而然产生的创意的策展人。" - -## Connections -- [[Idea-Density]] — 创意博物馆是创意密度的来源 -- [[Brand-Environment]] — 创意博物馆塑造品牌 -- [[Self-Education]] — 创意博物馆是自学的产出 -- [[System-Economy]] — 创意博物馆本身就是可销售的系统 diff --git a/wiki/concepts/Idempotency.md b/wiki/concepts/Idempotency.md deleted file mode 100644 index c5e60245..00000000 --- a/wiki/concepts/Idempotency.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Idempotency" -type: concept -tags: - - Architecture - - Reliability - - Cloud -last_updated: 2026-04-14 ---- - -## Definition -幂等性（Idempotency）是指一个操作被执行一次和被执行多次，产生的结果是相同的。在分布式系统和事件驱动架构中，这是确保系统可靠性的关键设计原则。 - -## Why It Matters in EDA -Lambda 异步调用会自动重试（通常重试 2-3 次），因此服务在处理事件时必须考虑幂等性，避免因重复处理导致的数据不一致或副作用（如重复下单、重复扣款）。 - -## Implementation Strategies -- 为每个事件分配唯一标识符（Event ID），消费者维护已处理事件记录 -- 使用数据库唯一约束或乐观锁防止重复写入 -- 基于业务语义的去重（如订单号唯一性检查） - -## Applicable Scenarios -- 订单处理和支付 -- 库存扣减 -- 消息确认 -- 状态更新 - -## Sources -- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] diff --git a/wiki/concepts/Identity-Governance.md b/wiki/concepts/Identity-Governance.md deleted file mode 100644 index 1bb60fa8..00000000 --- a/wiki/concepts/Identity-Governance.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: "Identity Governance" -type: concept -tags: - - Identity-Governance - - IAM - - Compliance - - Access-Management -sources: - - learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re -last_updated: 2023-11-28 ---- - -## Identity Governance - -身份治理（Identity Governance）是一个用于高效管理数字身份、最小化风险并保持合规的框架。 - -## Core Framework - -身份治理围绕三个核心问题展开： - -1. **谁当前有访问权限？** — 当前权限状态审计（Who currently has access to our systems?） -2. **谁应该有访问权限？** — 权限需求评估（Who should have access?） -3. **如何执行访问？** — 访问控制机制（How is the access being done?） - -## Components - -### Identity Management（身份管理） -- 数字身份的创建、维护和生命周期管理 -- 用户、组和角色的定义 - -### Access Management（访问管理） -- 控制谁可以访问哪些资源 -- 认证（Authentication）和授权（Authorization） - -### Identity Auditing（身份审计） -- 权限变更追踪 -- 合规性报告 -- 异常检测 - -## Identity Governance vs IAM - -| 维度 | 身份治理（IG） | 身份与访问管理（IAM） | -|------|----------------|----------------------| -| 焦点 | 治理、合规、策略 | 操作、技术实现 | -| 问题 | 谁应该有权访问？ | 如何实现访问控制？ | -| 受众 | 审计员、合规官、业务经理 | IT 管理员、安全工程师 | -| 工具 | 审批工作流、策略引擎 | 目录服务、SSO、MFA | - -## Use Cases - -- **内部用户治理**：员工入职/转岗/离职的权限生命周期管理 -- **外部用户治理**：承包商、合作伙伴的临时权限管理 -- **合规审计**：SOX、HIPAA、GDPR 等合规要求的身份报告 -- **权限优化**：发现并清理过度授权（Privilege Creep） - -## Implementation Example - -Micro Focus IGA 的实现架构： -``` -User → IGA Portal (申请) → 审批工作流 → AD 组更新 → AWS IAM → 云资源访问 -``` - -## Related Concepts - -- [[Micro-Focus-IGA]]：身份治理的具体产品实现 -- [[AWS-Identity-Center]]：AWS 云平台的身份治理服务 -- [[Federated-Access]]：联合身份认证 -- [[Service-Control-Policies-SCPs]]：AWS 组织层面的权限控制策略 diff --git a/wiki/concepts/Identity-Resolution.md b/wiki/concepts/Identity-Resolution.md deleted file mode 100644 index bbbc8fdb..00000000 --- a/wiki/concepts/Identity-Resolution.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Identity Resolution" -type: concept -tags: ["identity", "entity-resolution", "multi-agent", "data-matching"] -sources: ["identity-graph-operator"] -last_updated: 2026-04-25 ---- - -# Identity Resolution（身份解析） - -## Definition -将来自不同来源的多条记录归一化为同一 **canonical entity_id** 的过程——确保同一个真实世界实体（人/公司/产品）在系统中只对应一个唯一标识符，所有 Agent 共享这一规范视图。 - -## Core Workflow - -``` -原始记录 → 规范化(Normalize) → 阻塞(Blocking) → 评分(Scoring) → 聚类(Clustering) → Canonical Entity -``` - -1. **规范化**：邮箱小写、电话 E.164 格式、昵称扩展（Bill→William） -2. **阻塞**：用 blocking key（email domain / phone prefix / name soundex）快速筛选候选对，避免 O(n²) 全图扫描 -3. **评分**：字段级加权相似度（email exact match = 1.0，name fuzzy = 0.82） -4. **聚类**：高置信度候选归入同一 cluster，生成 canonical entity_id - -## Key Properties -- **确定性**：相同输入必须返回相同 entity_id（由 Identity Graph Operator 强制执行） -- **证据驱动**：每条合并决策必须有 per-field evidence，拒绝"看起来相似"断言 -- **并发安全**：通过乐观锁（version field）防止并发写入冲突 -- **可审计**：完整事件历史（entity.created / merged / split / updated） - -## Confidence Thresholds -| 置信度 | 操作 | -|--------|------| -| > 0.95 | 直接合并（单 Agent 高置信） | -| 0.60–0.95 | 提案审查（多 Agent 协作） | -| < 0.60 | 创建新实体 | - -## Relationship to Related Concepts -- [[Identity Resolution]] ⊂ [[Master-Data-Management]]（MDM）：身份解析是 MDM 在多 Agent 系统中的分布式实现，增加了并发协调维度 -- [[Identity Resolution]] 应用层：[[Personal CRM]] 联系人去重、[[Identity-Graph-Operator]] 企业级多 Agent 协调 - -## Related Agents -- [[identity-graph-operator]]：Identity Resolution 能力在多 Agent 系统中的 Agent 化封装 diff --git a/wiki/concepts/Ikigai框架.md b/wiki/concepts/Ikigai框架.md deleted file mode 100644 index 5aa90eab..00000000 --- a/wiki/concepts/Ikigai框架.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "Ikigai框架" -type: concept -tags: [个人定位, 职业发展, 商业变现] -sources: ["万字保姆级教程-90天跑通一人公司模式-2026-03-29", "不谈技术-普通人该怎么在ai时代赚钱"] -last_updated: 2026-04-30 ---- - -## 定义 - -Ikigai 是一个源自日本的自我定位框架，代表四个核心维度的交集： - -``` - 世界需要的 - │ - │ - 你热爱的 ───┼─── 你擅长的 - │ - │ - 你能获得报酬的 -``` - -**四个维度：** -1. **你所热爱的**（What you love） -2. **你所擅长的**（What you're good at） -3. **世界所需要的**（What the world needs） -4. **你能获得报酬的**（What you can be paid for） - -## 三步走方法 - -1. **反思热情和技能**：做什么会忘记时间？周末下午会主动学什么？ -2. **分析市场需求**：人们经常抱怨什么问题？愿意为什么付费？ -3. **寻找交集**：热情和市场的重叠处，就是你的 Ikigai - -## 在一人公司中的应用 - -| 步骤 | 内容 | -|------|------| -| 发现天才地带 | 识别产生心流的活动（[[天才地带（Zone of Genius）]]） | -| 挖掘底层能力 | 找到隐藏在活动表象下的核心能力（[[底层能力]]） | -| 找到 Ikigai | 确定热情、擅长、市场、报酬的交汇点 | -| 验证赛道 | 用数据验证定位（搜索意图、支付意愿、预售） | - -## 相关来源 - -- [[万字保姆级教程-90天跑通一人公司模式]] - -## 相关概念 - -- [[一人公司]] -- [[天才地带（Zone of Genius）]] -- [[底层能力]] -- [[产品四层级体系]] - -## Aliases - -- Ikigai -- 生命意义 -- 人生目标框架 diff --git a/wiki/concepts/ImageToVideo.md b/wiki/concepts/ImageToVideo.md deleted file mode 100644 index fe582afd..00000000 --- a/wiki/concepts/ImageToVideo.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "ImageToVideo" -type: concept -tags: [ai, video, image-to-video] -sources: [我的工具集, 14个免费的ai图生视频工具] -last_updated: 2026-05-11 ---- - -## Definition -Image-to-Video 是将静态图片转化为动态视频的 AI 技术，让图片中的元素产生运动效果。 - -## Key Characteristics -- 将静态图像作为输入，生成包含运动元素的视频 -- 广泛应用于电商视频制作、内容创作、广告营销等场景 -- 降低视频创作门槛，无需专业设备和拍摄技能 - -## Examples from Sources -- [[Wavespeed AI]] 提供 Image-to-Video 功能（付费） -- [[Vidu]] 提供 Image-to-Video 功能（月费 ¥8） -- [[Hailuo AI]] 提供 Image-to-Video 功能（月费 ¥42） - -## Relationships -- 属于 [[AI时代发展策略]] 的创意工具层 -- 与 [[TextToVideo]] 互补：ImageToVideo 从图像生成，TextToVideo 从文本生成 diff --git a/wiki/concepts/Immutable-Infrastructure.md b/wiki/concepts/Immutable-Infrastructure.md deleted file mode 100644 index 6b7f592d..00000000 --- a/wiki/concepts/Immutable-Infrastructure.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: "Immutable Infrastructure" -type: concept -tags: [Infrastructure as Code, DevOps, Cloud Native] -sources: [devops-maturity-model-from-traditional-it-to-advanced-devops] -last_updated: 2026-04-26 ---- - -## 定义 - -不可变基础设施（Immutable Infrastructure）是一种基础设施管理范式，服务器一旦部署就不再进行原地修改。当需要更新配置或修复问题时，整个服务器被替换为新版本，而不是在原有服务器上打补丁或更新。 - -## 核心原则 - -1. **不修改已部署的服务器**：任何变更都生成新服务器镜像 -2. **完整镜像部署**：使用预构建的镜像完整部署 -3. **自动化替换**：通过自动化流水线处理服务器生命周期 -4. **环境一致性**：所有环境使用相同的基础镜像 - -## 在 DevOps 成熟度模型中的位置 - -不可变基础设施是 **Phase 4（高度优化阶段）** 的关键特征： - -> "Immutable infrastructure replaces old servers rather than updating them." - -在该阶段，组织通过流水线管理基础设施和代码更新，不再依赖手动服务器修改。 - -## 不可变 vs 可变基础设施 - -| 维度 | 不可变基础设施 | 可变基础设施 | -|------|---------------|-------------| -| 更新方式 | 替换整个服务器 | 在原服务器上打补丁 | -| 一致性 | 所有环境高度一致 | 环境间可能存在差异 | -| 回滚难度 | 简单（切换回旧镜像） | 困难（需反向补丁） | -| 调试复杂度 | 低（快照确定） | 高（变化累积） | -| 部署速度 | 快（预构建镜像） | 慢（需逐步更新） | - -## 实现方式 - -### 容器化（推荐） -```dockerfile -# 每次构建生成新镜像 -FROM base-image:latest -RUN ./build.sh -# 部署时拉取新镜像，不修改原容器 -``` - -### 虚拟机镜像 -```bash -# Packer 创建镜像 -packer build template.json -# Terraform 用新 AMI 替换旧实例 -terraform apply -``` - -### 云基础设施 -```yaml -# Kubernetes 中使用 Immutable Pod -spec: - containers: - - image: myapp:v2.0 # 替换镜像而非修改容器 -``` - -## 与相关概念的关系 - -- [[Infrastructure as Code]]：不可变基础设施通常依赖 IaC 工具（Terraform、CloudFormation）实现 -- [[CI/CD Pipeline]]：不可变基础设施通过 CI/CD 流水线自动化构建和部署 -- [[DevOps Maturity Model]]：是 Phase 4 高度优化阶段的核心特征 -- [[Container-Lifecycle-Hardening]]：容器天然支持不可变范式，结合使用可提升安全性和一致性 - -## 来源 -- [[devops-maturity-model-from-traditional-it-to-advanced-devops]] diff --git a/wiki/concepts/Immutable-Root-Filesystem.md b/wiki/concepts/Immutable-Root-Filesystem.md deleted file mode 100644 index e0143884..00000000 --- a/wiki/concepts/Immutable-Root-Filesystem.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Immutable Root Filesystem" -type: concept -tags: - - Security - - Linux - - Container OS -sources: - - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w -last_updated: 2026-04-24 ---- - -# Immutable Root Filesystem - -只读根文件系统是一种操作系统安全加固技术，通过将根文件系统挂载为只读，确保操作系统核心文件在运行时无法被修改。任何运行时变更必须通过镜像更新机制完成，从而消除因意外或恶意修改导致的系统不可用风险。 - -## 核心原理 - -根文件系统在启动后被挂载为只读（read-only），即使拥有 root 权限也无法直接写入 `/` 目录下的文件。需要修改系统配置时，必须： -1. 重新构建包含更新内容的 OS 镜像 -2. 通过安全的更新机制（如 A/B 分区切换）部署新镜像 -3. 重启系统以激活变更 - -## 典型实现 - -| 技术 | 实现方式 | -|------|---------| -| dm-verity | 通过加密哈希树验证根文件系统块设备完整性，篡改被检测 | -| OverlayFS | 在只读底层之上叠加可写层，但底层不变 | -| OSTree | Git-like 分层镜像系统，支持原子升级和回滚 | -| A/B 分区 | 双分区设计，在线下载新镜像到非活动分区，重启切换 | - -## 在 Bottlerocket 中的实现 - -Bottlerocket OS 默认启用只读根文件系统： -- 根分区通过 dm-verity 加密验证，任何篡改被检测 -- `/etc` 目录作为 tmpfs（临时文件系统），运行时可写但重启清空 -- 所有持久配置通过 API 或 userdata 注入，不直接修改根文件系统 - -## 安全价值 - -- **防篡改**：恶意软件无法修改系统关键文件 -- **一致性保证**：每次启动系统状态可预测 -- **最小化攻击面**：无需运行时包管理器，降低漏洞暴露 -- **原子更新**：通过镜像级更新确保系统要么完全更新，要么保持原状 - -## 适用场景 - -- 容器宿主操作系统（Bottlerocket、Flatcar Container Linux、CoreOS） -- 嵌入式安全系统 -- 无法物理访问的远程服务器 -- 需要严格合规（如 PCI-DSS、FIPS）的基础设施 diff --git a/wiki/concepts/Incident-Management.md b/wiki/concepts/Incident-Management.md deleted file mode 100644 index 9bb682b3..00000000 --- a/wiki/concepts/Incident-Management.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: "Incident Management" -type: concept -tags: [itsm, operations, reliability] -date: 2025-03-01 ---- - -## Definition - -事件管理（Incident Management）是[[ITSM]]的核心流程之一，专注于**快速恢复服务正常运作**，将服务中断或降级对业务的影响降到最低。 - -## Incident Lifecycle - -``` -┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ -│ Event │ → │ Detect │ → │ Triage │ → │ Resolve │ → │ Review │ -│ Occurs │ │ & Alert │ │ & Prior │ │ & Recover│ │ & Learn │ -└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ -``` - -## Modern Incident Management (ITSM 2.0) - -在[[ITSM 2.0]]中，事件管理由[[AIOps]]和[[Self-Healing-Systems]]驱动： - -### Key Capabilities - -| 能力 | 描述 | 技术 | -|------|------|------| -| Real-time Observability | 实时可观测性 | Metrics, Logs, Traces | -| Automated Remediation | 自动化修复 | AIOps, Runbooks | -| Dynamic Prioritization | 动态优先级 | ML Models | -| Auto-escalation | 自动升级 | Alert Routing | -| Self-Healing | 自愈 | Automated Recovery | - -### AIOps-Powered Incident Response - -``` -监控检测 → 智能分类 → 自动路由 → 自动化修复 → SLA监控 - ↓ ↓ ↓ ↓ ↓ - AIOps ML模型 技能路由 Runbooks 告警升级 -``` - -## Key Metrics - -| 指标 | 描述 | -|------|------| -| [[MTTR]] | Mean Time to Recovery — 平均恢复时间 | -| [[MTTD]] | Mean Time to Detect — 平均检测时间 | -| MTTA | Mean Time to Acknowledge — 平均确认时间 | -| Change Failure Rate | 变更失败率 | - -## Priority Levels - -| 优先级 | 描述 | SLA | -|--------|------|-----| -| P1/Critical | 核心服务不可用 | 15分钟 | -| P2/High | 主要功能不可用 | 1小时 | -| P3/Medium | 次要功能受影响 | 4小时 | -| P4/Low | 轻微影响 | 24小时 | - -## Related Concepts - -- [[ITSM]] — 父框架 -- [[Problem-Management]] — 问题管理 -- [[AIOps]] — AI运维能力 -- [[Self-Healing-Systems]] — 自愈系统 -- [[MTTR]] — 平均恢复时间 -- [[MTTD]] — 平均检测时间 -- [[Event-Correlation]] — 事件关联 -- [[Root-Cause-Analysis]] — 根因分析 - -## Sources - -- [[understanding-complete-itsm]] — AIOps-driven Incident Management diff --git a/wiki/concepts/Inclusive-Delight-Design.md b/wiki/concepts/Inclusive-Delight-Design.md deleted file mode 100644 index 8ca8eaeb..00000000 --- a/wiki/concepts/Inclusive-Delight-Design.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Inclusive Delight Design" -type: concept -tags: [accessibility, ui-design, inclusive-design, user-experience] -sources: [design-whimsy-injector] -last_updated: 2026-05-15 ---- - -# Inclusive Delight Design - -## Definition - -包容性愉悦设计（Inclusive Delight Design）确保趣味元素对所有用户（包括残障用户）都可访问和可享受。核心原则：趣味性必须与无障碍访问并行实现，不能成为享受的障碍。 - -## Core Principles - -- **屏幕阅读器兼容**：动画不影响辅助技术 -- **减少动画偏好**：通过 `prefers-reduced-motion` 支持 -- **文化敏感性**：幽默和趣味跨文化适用 -- **认知负荷控制**：趣味不造成理解障碍 -- **多感官设计**：视觉 + 触觉/听觉多通道愉悦 - -## Whimsy Injector Guidelines - -> "Design playful elements that work for users with disabilities" -> "Ensure whimsy doesn't interfere with screen readers or assistive technology" -> "Provide options for users who prefer reduced motion or simplified interfaces" -> "Create humor and personality that is culturally sensitive and appropriate" - -## Relationship to Other Concepts - -- [[Micro-Interaction-Design]]：微交互需遵循包容性设计原则 -- [[Gamification]]：游戏化元素必须包容性设计 -- [[Invisible-Exclusion]]：包容性愉悦设计是避免隐性排他的关键 - -## Source - -- [[Whimsy-Injector]] — 包容性愉悦设计原则核心来源 diff --git a/wiki/concepts/Inclusive-Delight.md b/wiki/concepts/Inclusive-Delight.md deleted file mode 100644 index 9878ed6a..00000000 --- a/wiki/concepts/Inclusive-Delight.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Inclusive Delight" -type: concept -tags: [accessibility, ux, design, inclusion] -last_updated: 2026-04-30 ---- - -# 包容性愉悦设计（Inclusive Delight） - -## Aliases -- Inclusive Delight -- 包容性设计 -- 无障碍愉悦 -- Accessible Playfulness - -## 定义 - -包容性愉悦设计是指在产品中引入趣味性、情感化元素（如微交互、动画、游戏化）时，确保这些元素对所有用户（包括残障用户、不同文化背景用户、不同能力的用户）都可访问、可理解和可享受的设计原则。 - -## 核心要求 - -1. **运动敏感**：动画需支持 `prefers-reduced-motion`，允许用户关闭或减弱所有运动效果 -2. **屏幕阅读器兼容**：趣味元素不应干扰辅助技术对内容的解读（ARIA 标签、语义化 HTML） -3. **色彩对比度**：趣味配色必须在 WCAG 对比度标准下可读 -4. **文化敏感性**：幽默和趣味的表达需考虑跨文化理解，避免歧义或冒犯 -5. **替代文本**：Emoji 庆祝动画等视觉元素需有文字替代方案 - -## 设计策略 - -- **分层体验（Layered Experience）**：基础层对所有用户可访问，趣味增强层作为可选叠加 -- **开关控制**：为用户保留关闭趣味元素的选项（降低 motion、简化模式） -- **渐进增强**：从无障碍基础开始，逐步叠加趣味层 -- **测试多样性**：在真实辅助技术（屏幕阅读器、眼动追踪）和不同文化背景用户中测试 - -## 与趣味设计的关系 - -包容性不是趣味设计的对立面，而是趣味设计的基础约束——一个不包容的"趣味"设计会排斥部分用户，减少潜在受众。优秀的趣味设计在满足包容性要求的同时依然能创造愉悦感。 - -## 应用场景 - -- [[design-whimsy-injector]] 将包容性愉悦作为默认要求嵌入品牌个性框架，明确规定"确保所有趣味元素可访问和包容" -- [[design-ux-architect]] 通过 CSS 变量和语义化标记支持包容性基础的建立 - -## 相关概念 - -- [[Micro-Interaction]]：微交互需满足包容性要求（如 reduced-motion 支持） -- [[Gamification]]：成就系统需考虑不同能力水平用户的参与公平性 -- [[Brand-Personality-Framework]]：品牌个性中的文化敏感性是包容性的重要组成 diff --git a/wiki/concepts/Inclusive-Design-Research.md b/wiki/concepts/Inclusive-Design-Research.md deleted file mode 100644 index 6b3c0f03..00000000 --- a/wiki/concepts/Inclusive-Design-Research.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Inclusive Design Research" -type: concept -tags: [ux, accessibility, inclusive-design, research, disability] -sources: [design-ux-researcher.md] -last_updated: 2026-04-24 ---- - -## Definition - -Inclusive Design Research（包容性设计研究）是一种将无障碍和包容性维度纳入用户研究默认要求的研究方法。确保研究参与者和研究成果覆盖不同能力水平、文化背景和人口统计学特征，使产品对残障用户和多元群体可访问。 - -## Core Requirements - -- **默认要求**：所有 UX Researcher 的研究交付物必须包含无障碍研究维度 -- **参与者招募**：确保多样性，涵盖不同能力水平 -- **测试方法**：包含屏幕阅读器用户、键盘-only 用户等特殊群体的可用性测试 -- **文化包容性**：考虑不同文化背景用户的需求差异 - -## Relationship to Other Concepts - -- [[User-Research-Methodology]]：包容性是研究方法论的默认质量维度 -- [[Usability-Testing]]：可用性测试协议需包含无障碍测试场景 -- [[Inclusive-Delight-Design]]：包容性设计研究为包容性趣味设计提供用户数据支撑（[[design-whimsy-injector]] 的默认要求） - -## Source - -- [[design-ux-researcher.md]] — UX Researcher Agent Personality diff --git a/wiki/concepts/InclusiveVisuals.md b/wiki/concepts/InclusiveVisuals.md deleted file mode 100644 index 603f34d0..00000000 --- a/wiki/concepts/InclusiveVisuals.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Inclusive Visuals" -type: concept -tags: [generative-ai, bias-mitigation, ai-ethics, image-generation, video-generation] -sources: [design-inclusive-visuals-specialist] -last_updated: 2026-04-24 ---- - -## Definition -AI 生成图像/视频中的包容性视觉呈现——通过结构化提示词工程和负向约束，确保生成内容反映真实多样的社会现实（文化、年龄、残疾、社会经济地位的交叉性），而非刻板印象、符号化表征或文化失真。 - -## Core Components - -### Bias Types to Defeat -- **克隆脸（Clone Faces）**：AI 在生成多样化人群时生成同一人的多个复制版本 -- **异域化偏见（Exoticism Bias）**：对非西方文化的"东方主义"式过度美化或扭曲呈现 -- **文化符号乱码（Gibberish Cultural Text）**：非英语文字、符号生成幻觉 -- **地理/建筑失真**：特定文化背景下的环境不符合真实生活现实 -- **过度纠正（Over-correction）**：AI 刻意追求多样性时产生符号化、不真实构图 - -### Technical Interventions -- **显式负向约束**：列举 AI 应避免生成的内容（显式负向提示库） -- **文化真实性锚定**：正确的建筑/服装/布光参数，而非泛化的"多样性"标签 -- **交叉性叠加**：同时考虑多重身份维度的叠加表征 -- **社区验证**：所描绘社区用户的真实认可 - -## Related Concepts -- [[NegativePromptingLibrary]] -- [[IntersectionalRepresentation]] -- [[AIArtifactElimination]] -- [[CommunityValidation]] - -## Related Agents -- [[InclusiveVisualsSpecialist]]（主要执行者） -- [[DesignImagePromptEngineer]]（图像提示能力支撑） -- [[UX-Researcher]]（QA 验证） - -## Related Entities -- [[TheAgency]]（所属 Agent 体系） diff --git a/wiki/concepts/Incremental-Graph-Update.md b/wiki/concepts/Incremental-Graph-Update.md deleted file mode 100644 index 723a7ef1..00000000 --- a/wiki/concepts/Incremental-Graph-Update.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Incremental Graph Update" -type: concept -tags: [graph, real-time, file-watching] -sources: [lsp-index-engineer] -last_updated: 2026-04-25 ---- - -## Definition - -增量图谱更新（Incremental Graph Update）是 LSP/Index Engineer 维护代码语义图谱的核心策略——通过文件监视器（File Watchers）和 Git hooks 检测变更，仅更新受影响的图谱子图，而非全量重建，从而实现亚秒级增量同步。 - -## Trigger Mechanisms - -- **文件监视器**：监听文件系统变更，触发相关符号的重新索引 -- **Git hooks**：在提交前后执行图谱增量更新，确保版本控制集成 -- **WebSocket 推送**：将图谱差异实时推送至连接的客户端 - -## Consistency Guarantees - -LSP/Index Engineer 的原子性保证：图谱更新必须是原子性的——从不将图谱置于不一致状态。具体约束： -- 每个符号有且仅有一个定义节点 -- 所有边必须引用有效节点 ID -- 文件节点必须在符号节点之前创建 -- 导入边必须解析到实际文件/模块节点 - -## Performance Impact - -增量更新使得图谱在 100k+ 符号规模下依然保持亚秒级响应： -- 文件保存后 → 图谱更新传播至客户端 <500ms -- 单个文件变更 → 仅更新受影响子图，而非全量重建 -- WebSocket 推送延迟 <50ms diff --git a/wiki/concepts/Incremental-Indexing.md b/wiki/concepts/Incremental-Indexing.md deleted file mode 100644 index ba0a69d8..00000000 --- a/wiki/concepts/Incremental-Indexing.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "IncrementalIndexing" -type: concept -tags: [] ---- - -## Definition -增量索引，只处理新增或变化的内容，避免重新处理未变化的数据。 - -## Key Mechanism -使用内容哈希（如 SHA-256）标识每个文档块： -1. 首次索引：计算哈希，存储 (哈希, 内容, 向量) -2. 后续索引：重新计算哈希，仅对不匹配的块进行嵌入 -3. 未变化的块：跳过，零 API 调用 - -## Benefits -- **节省成本**：只嵌入新增/变化内容 -- **提升速度**：跳过已索引内容 -- **一致性保证**：相同内容始终生成相同向量 - -## Application -- [[memsearch]] 使用 SHA-256 内容哈希实现增量索引 -- 文档原文始终是真相，索引是派生缓存 - -## Related Concepts -- [[memsearch]] — 实现增量索引的工具 -- [[RAG]] — 检索增强生成 diff --git a/wiki/concepts/IncrementalGraphUpdate.md b/wiki/concepts/IncrementalGraphUpdate.md deleted file mode 100644 index 13f018e3..00000000 --- a/wiki/concepts/IncrementalGraphUpdate.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "IncrementalGraphUpdate" -type: concept -tags: ["LSP", "code-intelligence", "incremental-update", "event-driven", "real-time"] -sources: ["lsp-index-engineer.md"] -last_updated: 2026-04-29 ---- - -## Definition -增量图谱更新（Incremental Graph Update）是一种通过文件监听器和 Git hooks 实时监听代码变化，仅对受影响的部分图谱进行增量更新而非全量重建的策略，确保图谱始终与代码库保持同步，同时保持 < 100ms 端到端响应时间。 - -## Core Mechanism - -### 触发来源 -1. **文件监听器**（File Watcher）：监听文件系统的 `create/modify/delete` 事件 -2. **Git Hooks**：`pre-commit` / `post-commit` / `post-merge` 钩子检测代码变更 - -### 增量更新流程 -1. 检测文件变更（新增/修改/删除） -2. 定位受影响的符号节点和边 -3. 对该文件运行 LSP `textDocument/didChange` 通知 -4. 接收 LSP 的增量语义更新 -5. 更新相关图谱节点和边 -6. 通过 WebSocket 推送图谱差异（Graph Diff）到客户端 - -### Graph Diff 推送 -```typescript -interface GraphDiff { - added: GraphNode[]; - removed: GraphNode[]; - modified: GraphNode[]; - addedEdges: GraphEdge[]; - removedEdges: GraphEdge[]; -} -``` -仅推送差异，不推送全量图谱，实现最小化网络开销。 - -### 一致性保证 -- **原子性更新**：图谱更新是事务性的，要么全部成功要么全部回滚 -- **乐观锁**：并发更新时使用版本号检测冲突 -- **不变性约束验证**：更新前后验证图谱一致性不变量（符号唯一定义、边引用有效性等） - -## Performance Characteristics -- 文件变更到 WebSocket 推送：< 50ms -- 单文件增量更新：< 20ms -- 100k+ 符号规模：仍保持增量更新性能 - -## Connections -- [[IncrementalGraphUpdate]] ← is_update_strategy_of ← [[GraphDaemon]] -- [[IncrementalGraphUpdate]] ← triggered_by ← [[FileWatcher]] -- [[IncrementalGraphUpdate]] ← streams_via ← [[WebSocket]] -- [[IncrementalGraphUpdate]] ← replaces ← [[LSIF]]（LSIF 用于预计算，Incremental 用于实时） diff --git a/wiki/concepts/Incrementality-Testing.md b/wiki/concepts/Incrementality-Testing.md deleted file mode 100644 index 3adf759d..00000000 --- a/wiki/concepts/Incrementality-Testing.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Incrementality Testing" -type: concept -tags: ["paid-media", "attribution", "measurement", "testing"] -sources: - - paid-media-programmatic-buyer - - paid-media-ppc-strategist -last_updated: 2026-05-01 ---- - -## Aliases -- 增量测试 -- Incrementality -- Holdout Testing -- Geo Split Testing - -## Overview -增量测试是一种通过对照组（holdout）实验设计，验证付费广告是否带来"净新增"转化的方法论。核心目的是避免"转移归因"——即付费广告只是截获了本来会发生的有机转化，而非真正带来增量价值。 - -## Definition -常见方法： -- **Holdout（控制组）**：随机选取一部分目标受众，不投放广告，对比两组转化率差异 -- **Geo Split（地理拆分）**：在不同地理区域分别开关广告，隔离外部变量 -- **Matched Market（匹配市场）**：选择相似市场，一方投放一方对照 - -增量 = 实验组转化率 - 对照组转化率（排除自然流量后） - -## Connections -- [[Paid Media Paid Social Strategist]] Agent 在跨渠道验证中强调增量测试 -- 与 [[Conversions API]] 数据配合可更准确地测量增量 -- 与 [[PaidMediaPpcStrategist]] 的增量测试框架（geo-split/holdout/matched market）方法论一致 -- 避免 [[Audience Overlap Analysis]] 导致的重复计算问题 diff --git a/wiki/concepts/IncrementalityTesting.md b/wiki/concepts/IncrementalityTesting.md deleted file mode 100644 index a7eed629..00000000 --- a/wiki/concepts/IncrementalityTesting.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "Incrementality Testing" -type: concept -tags: ["ppc", "measurement", "analytics", "attribution", "paid-media"] -sources: ["paid-media-ppc-strategist"] -last_updated: 2026-05-01 ---- - -## Definition - -增量测试（Incrementality Testing）是一套用于衡量付费广告真实业务贡献的方法论，通过对照组设计（Holdout/Control Group）区分"由广告带来的增量转化"与"即使没有广告也会自然发生的转化"。解决归因模型的固有局限性——仅分析有广告触达的用户，而不考虑无广告曝光时的自然转化。 - -## Why Incrementality Matters - -传统归因的问题： -- **Last-click 过誉**：将转化归功于最后一次点击，忽略其他触点 -- **View-through 虚假转化**：用户看过广告但未点击，计为"转化" -- **自然转化混淆**：无法区分广告贡献和自然流量 - -Incrementality 测试回答核心问题：**如果没有这个广告，转化量会下降多少？** - -## Testing Methodologies - -### 1. Geo-Split（地理分割测试） -**原理**：将市场按地理区域分割，一半投放广告，一半暂停，对比转化差异 - -| 区域 | 处理 | -|------|------| -| Test Market A | 投放广告 | -| Test Market B | 暂停广告 | -| Control Market | 维持正常投放（用于基线校准） | - -**适用**：品牌广告、Display、Video、OOH -**最小样本**：每个市场 30+ 转化/周 - -### 2. Holdout / User-Level Holdout（用户级对照测试） -**原理**：随机选择 X% 用户完全排除在广告触达之外，对比与正常触达用户的转化率差异 - -**适用**：精准追踪能力（Email/Pixel 覆盖率高） -**挑战**：用户感知可能影响结果 - -### 3. Matched Market（匹配市场测试） -**原理**：使用历史数据识别两个可比较的地理市场，一个投放，一个暂停 - -**适用**：无法随机分割用户的大型品牌 -**关键**：Matching 质量决定测试有效性 - -## Key Metrics from Incrementality Tests - -| 指标 | 公式 | 解读 | -|------|------|------| -| **Uplift** | (Test Conv - Control Conv) / Control Conv | 广告带来的增量转化率 | -| **CPA Ratio** | Holdout CPA / Exposed CPA | 广告效率 vs 无广告基准 | -| **True ROAS** | Uplift Conv × Avg Order Value / Ad Spend | 真实广告回报 | - -## Connections -- [[PaidMediaTrackingSpecialist]]：增量测试需要可靠的转化追踪基础设施 -- [[BudgetPacing]]：增量测试结果用于指导预算分配决策 -- [[CrossPlatformPlanning]]：跨平台增量贡献衡量，指导平台预算分配 diff --git a/wiki/concepts/Indexing.md b/wiki/concepts/Indexing.md deleted file mode 100644 index abb8304e..00000000 --- a/wiki/concepts/Indexing.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "Indexing" -type: concept -tags: [RAG, 向量数据库, 文档处理] -sources: [rag从入门到精通系列1-基础rag] -last_updated: 2025-01-16 ---- - -## Definition - -Indexing（索引阶段）是 RAG（检索增强生成）管道的第一阶段，负责将外部文档转换为可检索的向量表示并存入向量数据库。 - -## Core Process - -``` -原始文档 → 文档加载器 → 文本切分(Split) → Embedding向量化 → 存入Vector Store -``` - -1. **文档加载（Loading）**：通过 LangChain 等框架的 Document Loader 从多种来源（网页/本地文件/数据库等）加载原始文档 -2. **文本切分（Splitting）**：将长文档切分成适合 Embedding Model Context Window 的小块（Split），通常 512~4096 token -3. **向量化（Embedding）**：使用 Embedding Model（如 BAAI/bge 系列）将文本块转换为固定长度的向量表示 -4. **存入向量数据库**：将 Embedding Vector 存入 Vector Store（如 Qdrant、Chroma、Milvus 等） - -## Key Parameters - -- **Chunk Size**：每个 Split 的 token 数量，需平衡上下文完整性和模型限制 -- **Chunk Overlap**：相邻 Split 之间的重叠 token 数，防止信息在切分边界丢失 -- **Embedding Model**：决定向量质量和检索效果的模型（如 BAAI、OpenAI text-embedding-3、BGE 等） - -## Tools - -- **LangChain**：提供 160+ 文档加载器和向量存储集成 -- **LlamaIndex**：专注数据连接和索引的 LLM 应用框架 -- **Qdrant**：Rust 编写的开源向量数据库，支持过滤和混合检索 - -## Connections - -- [[Indexing]] ← part_of ← [[RAG]] -- [[Indexing]] ← uses ← [[Embedding]] -- [[Indexing]] ← produces ← [[Vector-Store]] -- [[Indexing]] ← depends_on ← [[Context-Window]] - -## Aliases - -- Document Indexing -- Chunking -- 文档索引 diff --git a/wiki/concepts/IndexingStrategies.md b/wiki/concepts/IndexingStrategies.md deleted file mode 100644 index d91f0204..00000000 --- a/wiki/concepts/IndexingStrategies.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Indexing Strategies" -type: concept -tags: [database, postgresql, index, performance, mysql, supabase] -last_updated: 2026-05-01 ---- - -# Indexing Strategies - -## Definition - -数据库索引策略是指根据查询模式和数据特征选择合适的索引类型和结构的实践方法，目的是加速数据检索同时控制写入开销和存储成本。 - -## Index Types - -| 类型 | 适用场景 | 示例 | -|------|---------|------| -| **B-tree** | 等值查询、范围查询、排序（默认首选） | `CREATE INDEX ON users(email)` | -| **GiST** | 几何数据、全文搜索、Range 类型 | `CREATE INDEX ON documents USING GIN(to_tsvector('english', content))` | -| **GIN** | JSON/数组字段、全文搜索 | `CREATE INDEX ON posts USING GIN(metadata)` | -| **部分索引（Partial）** | 高频过滤条件（如下线状态） | `CREATE INDEX ON orders WHERE status = 'pending'` | -| **复合索引（Composite）** | 多列过滤 + 排序 | `CREATE INDEX ON posts(status, created_at DESC)` | - -## Aliases -- Composite Index -- Partial Index -- Covering Index - -## Key Principles - -1. **外键必须加索引**：用于 JOIN 性能 -2. **高频 WHERE 条件优先建索引**：但避免对低选择性列（如性别）建单列索引 -3. **复合索引列顺序**：等值列在前，范围列在后 -4. **避免 SELECT \***：只查需要的列，利于索引覆盖（covering index） - -## Source -- [[engineering-database-optimizer]] - -## Connections -- [[QueryPlanAnalysis]] — 索引效果通过 EXPLAIN ANALYZE 验证 -- [[SchemaDesign]] — 索引是 Schema 设计的关键组成部分 -- [[engineering-backend-architect]] — 架构设计时需考虑索引策略 diff --git a/wiki/concepts/Infoblox-Grid.md b/wiki/concepts/Infoblox-Grid.md deleted file mode 100644 index 05cbf6da..00000000 --- a/wiki/concepts/Infoblox-Grid.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: "Infoblox-Grid" -type: concept -tags: [Networking, DNS, DHCP, IPAM, Infoblox, High-Availability] -sources: - - ctp-topic-45-automatic-ip-address-allocation-with-ipam - - ctp-topic-61-workload-vpc-provision-with-ipam-automation - - ctp-topic-22-global-dns-service-offerings -last_updated: 2026-04-24 ---- - -## Infoblox Grid - -Infoblox 的分布式网格架构，是企业级 DNS、DHCP 和 IPAM（IPAM）服务的高可用基础设施。Grid 架构将多个 Infoblox 设备组织成一个逻辑单元，提供统一的控制平面和冗余保护。 - -## Architecture Components - -### Grid Master -- **角色**：整个 Grid 的主控节点 -- **职责**：管理成员节点、配置文件分发、IP 地址分配决策 -- **位置**：本组织中位于休斯顿数据中心 - -### Grid Members -- **角色**：分布在多个地理位置的工作节点 -- **职责**：承载 DNS、DHCP、IPAM 服务 -- **冗余**：多成员部署提供故障转移能力 - -### Supporting Services -- **DNS**：Anycast 支持全球低延迟 -- **NTP**：时间同步服务 -- **DHCP**：IP 地址动态分配 - -## Grid Communication - -- 成员之间通过 Grid 协议通信 -- 配置变更通过主节点统一分发 -- IP 地址分配决策由主节点协调 - -## vs. Single Node - -| 特性 | 单节点 | Grid 架构 | -|------|--------|-----------| -| 高可用 | ❌ | ✅ 故障自动转移 | -| 地理分布 | ❌ | ✅ 全球多站点 | -| 集中管理 | ✅ | ✅ 更强 | -| 扩展性 | 有限 | ✅ 线性扩展 | - -## Key Concepts - -- [[Infoblox-NIOS]]：Grid 成员上运行的操作系统 -- [[IPAM]]：Grid 的核心功能之一 -- [[DNS-Anycast]]：Grid DNS 服务的高级特性 - -## Connections - -- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← Infoblox Grid 作为 IPAM 后端 -- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← Grid 防止 IP 地址重叠 -- [[ctp-topic-22-global-dns-service-offerings]] ← Grid 支撑 DNS Anycast 服务 - -## Aliases - -- Infoblox Grid Architecture -- NIOS Grid -- Infoblox Cluster diff --git a/wiki/concepts/Infoblox-NIOS.md b/wiki/concepts/Infoblox-NIOS.md deleted file mode 100644 index 8fd50e22..00000000 --- a/wiki/concepts/Infoblox-NIOS.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: "Infoblox-NIOS" -type: concept -tags: [Networking, DNS, DHCP, IPAM, Infoblox] -sources: - - ctp-topic-45-automatic-ip-address-allocation-with-ipam - - ctp-topic-61-workload-vpc-provision-with-ipam-automation - - ctp-topic-22-global-dns-service-offerings -last_updated: 2026-04-24 ---- - -## Infoblox NIOS - -Infoblox 的核心网络控制平面操作系统，提供 **DNS**、**DHCP** 和 **IP 地址管理（IPAM）** 三大核心功能。作为企业级网络基础设施，NIOS 是 Cloud Transformation Programme 中 IPAM 自动化方案的技术核心。 - -## Core Functions - -### 1. DNS（域名系统） -- 权威 DNS 服务器 -- DNS Anycast 支持全球低延迟解析 -- 与 Microsoft Active Directory 深度集成 - -### 2. DHCP（动态主机配置协议） -- 自动化 IP 地址分配 -- IP 租约管理 -- 与 DNS 动态更新集成 - -### 3. IPAM（IP 地址管理） -- 集中化 IP 地址池管理 -- 可扩展属性（Extensible Attributes）存储元数据 -- API 驱动的自动化分配 -- 与 IaC 工具（Terraform/Terragrunt）集成 - -## Extensible Attributes - -NIOS 支持自定义可扩展属性，用于存储业务元数据： - -| 属性名 | 用途 | -|--------|------| -| space_owner | IP 地址空间负责人 | -| company | 所属公司/业务单元 | -| subnet_name | 子网名称 | -| compartment_type | 隔间类型 | -| status | 分配状态（allocated/reserved/available） | -| business_contact | 业务联系人 | -| engineering_contact | 工程联系人 | - -## Architecture - -- **Grid Master**：主控节点，位于休斯顿数据中心 -- **冗余服务**：DNS、NTP、DHCP 多活冗余 -- **API 接口**：RESTful API 支持自动化集成 -- **与 AWS 集成**：通过 VPC 供给流水线调用 NIOS API 分配 IP 地址 - -## Key Concepts - -- [[IPAM]]：NIOS 的核心功能之一 -- [[Infoblox-Grid]]：NIOS 的分布式网格架构 -- [[DNS-Anycast]]：NIOS 的 DNS 高可用机制 - -## Connections - -- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← NIOS 作为 IPAM 引擎 -- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← NIOS 驱动 VPC 供给 -- [[ctp-topic-22-global-dns-service-offerings]] ← NIOS 提供 DNS Anycast - -## Aliases - -- NIOS -- InfoBlocks NIOS -- Infoblox Network Operating System diff --git a/wiki/concepts/Infrastructure as Code.md b/wiki/concepts/Infrastructure as Code.md deleted file mode 100644 index ab50f8fd..00000000 --- a/wiki/concepts/Infrastructure as Code.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "Infrastructure as Code" -type: concept -tags: [DevOps, Cloud, Automation] -sources: [engineering-devops-automator] -last_updated: 2026-05-01 ---- - -# Infrastructure as Code - -## 定义 -基础设施即代码（Infrastructure as Code，IaC）是一种通过代码定义和管理云基础设施的方法，替代传统手动配置，实现基础设施的可重复性、可版本控制和可测试性。 - -## 核心原则 -1. **声明式配置**：描述期望的最终状态，而非执行的具体步骤 -2. **幂等性**：多次执行产生相同结果 -3. **版本控制**：所有配置存储在 Git 等版本控制系统 -4. **可重复性**：同一代码在不同环境生成相同基础设施 -5. **自动化测试**：基础设施变更经过测试验证 - -## 核心工具 -- **Terraform**：声明式、多云支持（AWS/GCP/Azure） -- **AWS CloudFormation**：AWS 原生声明式服务 -- **AWS CDK**：使用编程语言（TypeScript/Python）定义云资源 -- **Ansible**：配置管理 + 基础设施编排 -- **Pulumi**：使用通用编程语言定义基础设施 - -## 在 DevOps Automator 中的应用 -- 使用 Terraform 定义 AWS Auto-scaling groups、ALB、CloudWatch alarms -- 通过 `terraform plan` 预览变更，通过 `terraform apply` 自动部署 -- 支持多环境管理（dev/staging/prod） - -## 相关概念 -- [[CI/CD Pipeline]]：IaC 变更通过 CI/CD 流水线自动化部署 -- [[Terraform]]：DevOps Automator 默认使用的 IaC 工具 -- [[GitOps]]：基于 Git 的 IaC 运维模式 - -## 最佳实践 -- 状态文件存储在远程后端（S3 + DynamoDB） -- 使用 workspaces 或目录分离多环境 -- 模块化设计，复用公共组件 -- 敏感信息使用 Vault 或 AWS Secrets Manager - -## 与传统运维的对比 -| 维度 | 传统运维 | IaC | -|------|----------|-----| -| 速度 | 手动配置耗时 | 分钟级自动部署 | -| 一致性 | 人为差异 | 完全一致 | -| 版本控制 | 无 | 完整历史记录 | -| 回滚 | 困难 | 一键回滚 | -| 审计 | 日志分散 | 集中可追溯 | - -## Aliases -- IaC -- Infrastructure as Code -- 基础设施即代码 -- Configuration as Code diff --git a/wiki/concepts/Infrastructure-as-Code.md b/wiki/concepts/Infrastructure-as-Code.md deleted file mode 100644 index 2f52794e..00000000 --- a/wiki/concepts/Infrastructure-as-Code.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Infrastructure as Code" -type: concept -tags: [DevOps, AWS, Terraform, Automation] -sources: [ctp-topic-3-deploy-and-maintain-infrastructure, ctp-topic-9-ci-cd-with-gruntwork, ctp-topic-48-terraform-vs-terragrunt, ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments, ctp-topic-33-an-introduction-to-gitops, ctp-topic-56-automated-infrastructure-testing, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording, cloud-operating-model-key-strategies-and-best-practices, learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform, engineering-devops-automator] -last_updated: 2026-04-14 ---- - -# Infrastructure as Code - -## Definition -基础设施即代码（Infrastructure as Code, IaC）是一种通过机器可读的定义文件（而非物理硬件配置或交互式配置工具）管理和配置计算基础设施的方法。 - -## Core Principles -- **声明式配置**：描述期望的最终状态，而非执行的具体步骤 -- **版本控制**：所有基础设施定义文件存储在 Git 中 -- **幂等性**：多次执行产生相同结果 -- **可重复性**：同一模板可在不同环境快速部署 -- **自动化**：与 CI/CD 流水线集成 - -## Key Tools -- **Terraform**：HashiCorp 出品，云厂商无关的 IaC 工具，通过状态文件管理资源 -- **Terragrunt**：Terraform 轻量封装，贯彻 DRY 原则 -- **AWS CloudFormation**：AWS 原生 IaC 服务，JSON/YAML 模板 -- **Pulumi**：编程语言驱动的 IaC 平台 -- **Ansible**：配置管理和应用部署工具 - -## Terraform Ecosystem -- **Gruntwork**：预建 Terraform 模块库，生产级参考架构 -- **Atlantis**：Git 集成 Terraform 部署，PR 评论式协作 -- **Terratest**：Terraform 代码的 Go 测试框架 -- **tfsec**：Terraform 静态安全分析工具 -- **TFLint**：Terraform 代码规范检查 - -## IaC in CTP Context -CTP（Cloud Transformation Programme）使用 Terraform/Terragrunt 构建 AWS Landing Zone： -- [[ctp-topic-3-deploy-and-maintain-infrastructure]]：Terragrunt HCL 文件与模块化管理 -- [[ctp-topic-9-ci-cd-with-gruntwork]]：Gruntwork CI/CD 流水线实践 -- [[ctp-topic-48-terraform-vs-terragrunt]]：Terraform 与 Terragrunt 对比选型 -- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]：Atlantis 替代 Jenkins -- [[ctp-topic-56-automated-infrastructure-testing]]：TerraTest 自动化测试 -- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]：ECS IaC 部署实践 - -## Related Concepts -- [[GitOps]]：Git 作为 IaC 的单一真相来源 -- [[CI/CD Pipeline]]：IaC 与 CI/CD 流水线的集成 -- [[Policy-as-Code]]：IaC 扩展至安全合规策略 -- [[Canary-Deployment]]：基于 IaC 的金丝雀部署策略 -- [[Atlantis]]：GitOps 驱动的 Terraform 协作工具 diff --git a/wiki/concepts/InfrastructureAsCode.md b/wiki/concepts/InfrastructureAsCode.md deleted file mode 100644 index be86916e..00000000 --- a/wiki/concepts/InfrastructureAsCode.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Infrastructure as Code" -type: concept -tags: - - IaC - - DevOps - - Cloud -sources: - - ctp-topic-48-terraform-vs-terragrunt.md -- [[learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]] -last_updated: 2026-05-15 ---- - -## Definition -Infrastructure as Code（IaC）是通过代码定义和管理基础设施的实践，实现基础设施的版本控制、自动化部署和一致性管理，而非手动配置。 - -## Key Characteristics -- **声明式配置**：定义期望的最终状态，而非步骤 -- **版本控制**：所有基础设施定义纳入 Git 管理 -- **幂等性**：重复执行产生相同结果 -- **自动化**：与 CI/CD 流程深度集成 - -## Core Tools -- [[Terraform]] — 云无关的 IaC 工具 -- [[Terragrunt]] — Terraform 的 DRY 包装器 -- AWS CloudFormation — AWS 原生 IaC -- Pulumi — 编程语言驱动的 IaC -- Ansible — 配置管理工具 - -## Connections -- [[Terraform]] ← implements ← [[InfrastructureAsCode]] -- [[Terragrunt]] ← extends ← [[Terraform]]（多环境管理） -- [[Atlantis]] ← enables ← [[GitOps]]（PR 驱动的 IaC 部署） diff --git a/wiki/concepts/IngestWorkflow.md b/wiki/concepts/IngestWorkflow.md deleted file mode 100644 index c5e8399f..00000000 --- a/wiki/concepts/IngestWorkflow.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "IngestWorkflow" -type: concept -tags: [workflow, knowledge-management, llm] -sources: [llm-wiki] -last_updated: 2026-05-02 ---- - -## Overview -导入工作流（Ingest Workflow）是 [[PersistentWiki]] 的核心运营模式之一——当新源添加到 `raw/` 目录时，LLM 读取、处理并将其整合到 Wiki 中。 - -## Standard Process（9步） -1. **读取源文件**：完整读取待摄取的源文档 -2. **了解上下文**：读取 `wiki/index.md` 和 `wiki/overview.md` -3. **生成 Source Page**：创建 `wiki/sources/.md`（参照 Source Page Format） -4. **更新 Index**：在 `wiki/index.md` 的 Sources 节添加新条目 -5. **更新 Overview**：如有修订必要时更新综合摘要 -6. **更新/创建 Entity 页面**：为关键人物/公司/项目创建或更新实体页 -7. **更新/创建 Concept 页面**：为关键想法和框架创建或更新概念页 -8. **检测冲突**：记录与现有 Wiki 内容的矛盾 -9. **追加 Log**：在 `wiki/log.md` 中追加时间线条目 - -## Trigger -触发方式：用户说 "ingest " 或 "摄取这个文件：raw/xxx.md" - -## Design Principles -- **一次源可能影响 10-15 个 Wiki 页面**：更新实体、概念、摘要、交叉引用 -- **单源优于批量**：作者偏好一次导入一个源并全程参与，可更好把控知识整合质量 -- **批量可行**：也可以一次性批量导入，减少监督 - -## Related Workflows -- [[QueryWorkflow]]：查询工作流——用户提问，LLM 从 Wiki 检索答案 -- [[LintWorkflow]]：检查工作流——定期健康检查 Wiki 质量 diff --git a/wiki/concepts/Inline-Layer.md b/wiki/concepts/Inline-Layer.md deleted file mode 100644 index 4706c5ce..00000000 --- a/wiki/concepts/Inline-Layer.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Inline Layer (Firewall Policy)" -type: concept -tags: ["AWS", "Firewall", "Checkpoint", "Network-Security", "Policy"] -sources: ["ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security"] -last_updated: 2026-04-28 ---- - -## Definition -Inline Layer 是 Checkpoint Firewall 中防火墙策略的另一种组织结构——采用基于账号编号的父子规则架构。一个父规则下嵌套多个子规则，子规则按账号维度进行流量控制。与 Ordered Layer（顺序多层检查）不同，Inline Layer 通过账号维度进行规则分组和继承。 - -## Mechanism -在 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中，Pradeep 演示了 Inline Layer 的应用场景： - -- **账号维度分组**：将同一账号或 OU 内的规则聚合为一个 Inline Layer 块 -- **父子规则结构**：父规则定义范围（哪个账号），子规则定义具体允许/拒绝的流量 -- **自动化友好**：新账号上线时，只需在父规则下添加子规则，无需修改核心策略结构 -- **简化规则管理**：规则数量随账号数线性增长，而非 N^2 增长 - -## Ordered Layer vs Inline Layer - -| 维度 | Ordered Layer | Inline Layer | -|------|-------------|-------------| -| 组织维度 | 多层（地理→类型→BU→产品→环境→角色） | 账号编号维度 | -| 检查逻辑 | 顺序通过全部层 | 在父规则下匹配子规则 | -| 适用场景 | 精细化多层安全控制 | 跨账号规则聚合与自动化 | -| 管理复杂度 | 中（维度多但粒度细） | 低（账号分组简化管理） | - -## Combined Usage -Checkpoint 在 Landing Zone 中通常组合使用两种 Layer： -- **Ordered Layers**：处理安全控制层（地理封锁、BU 隔离等） -- **Inline Layers**：处理账号维度的规则管理，支持自动化和扩展 - -## Connections -- [[Checkpoint-Firewall]] — Inline Layer 是 Checkpoint 策略集的核心组织方式 -- [[Ordered-Layer]] — Checkpoint 策略的两种组织模式：Ordered Layer（顺序检查）vs Inline Layer（账号维度） -- [[AWS-Landing-Zone]] — 在 LZ 网络隔离架构中实施 -- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] diff --git a/wiki/concepts/Innovation-Pipeline.md b/wiki/concepts/Innovation-Pipeline.md deleted file mode 100644 index a55e4886..00000000 --- a/wiki/concepts/Innovation-Pipeline.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Innovation Pipeline" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-25 ---- - -## Definition - -Innovation Pipeline（创新管道）是 [[Strategic-Portfolio-Management]] 中的一个特殊项目层级，专门用于管理实验性、创新性项目。与 Tier 1/2 追求确定性回报不同，Innovation Pipeline 项目的核心价值是学习而非短期财务回报。 - -## Position in Portfolio Architecture - -``` -Strategic Portfolio -├── Tier 1 Projects (Strategic Priority) -│ └── 高投资，高确定性战略回报 -├── Tier 2 Projects (Growth Initiatives) -│ └── 中等投资，中等增长回报 -└── Innovation Pipeline - └── 低投资，高学习价值，失败是预期结果 -``` - -## Key Characteristics - -- **Learning Objectives**：项目目标设定为学习而非回报 -- **Lower Resource Commitment**：资源投入相对有限 -- **Higher Risk Tolerance**：失败被视为有价值的数据点 -- **Capability Development**：驱动组织能力和技术探索 -- **Technology Adoption**：新技术和方法的试验田 - -## Relationship to Other Concepts - -- 属于 [[Strategic-Portfolio-Management]] 的组成部分 -- 支持 [[Resource-Allocation]] 中的能力建设优先级 -- 与 [[Risk-Balancing]] 密切相关——Innovation Pipeline 是风险敞口的主要来源 - -## In Studio Producer Framework - -在 [[Project-Management-Studio-Producer]] 的 Strategic Portfolio Plan 模板中，Innovation Pipeline 是独立章节，包含： -- 实验性举措和学习目标 -- 技术采纳和能力发展 -- 失败容错机制设计 - -## Aliases -- Experimental Portfolio -- R&D Pipeline -- Innovation Portfolio -- Learning Portfolio diff --git a/wiki/concepts/IntegrationGovernance.md b/wiki/concepts/IntegrationGovernance.md deleted file mode 100644 index 6d2ef084..00000000 --- a/wiki/concepts/IntegrationGovernance.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "IntegrationGovernance" -type: concept -tags: [] -last_updated: 2026-04-25 ---- - -# IntegrationGovernance（集成治理） - -## Definition -对每个接入系统的角色、权限、数据流向和失败模式进行明确定义的治理规范，确保多系统协作的清晰性和可审计性。 - -## Core Principle -> **"No integration is approved without source-of-truth clarity."** -> （未经明确数据权威来源，不得批准任何集成。） - -## Required Definitions Per Connected System - -| 维度 | 描述 | -|------|------| -| **System Role & Source of Truth** | 该系统在整个数据流中的角色，以及谁是数据的权威来源 | -| **Auth Method & Token Lifecycle** | 认证方式（API Key / OAuth / JWT 等）和令牌刷新策略 | -| **Trigger Model** | 触发方式（WebHook / Polling / Event Bus / Scheduled） | -| **Field Mappings & Transformations** | 输入/输出字段映射及数据转换规则 | -| **Write-back Permissions & Read-only Fields** | 写回权限范围和只读字段清单 | -| **Rate Limits & Failure Modes** | API 速率限制及常见失败场景处理 | -| **Owner & Escalation Path** | 系统负责人及问题升级路径 | - -## Integration Approval Checklist -- [ ] 数据权威来源已明确定义 -- [ ] 认证方式已配置且令牌刷新机制已实现 -- [ ] 触发模型已选定并实现 -- [ ] 字段映射已文档化 -- [ ] 写回权限已获授权方批准 -- [ ] 速率限制和失败模式已评估 -- [ ] 负责人已指定并知晓升级路径 -- [ ] 集成已通过 [[ReliabilityBaseline]] 中的外部依赖失败测试 - -## Re-Audit Triggers（重审计触发条件） -以下任一情况发生时，需重新评估现有集成： -- API 或 Schema 发生变更 -- 错误率显著上升 -- 业务容量大幅增长 -- 合规要求发生变化 -- 反复出现人工修复的情况 - -## Related Concepts -- [[AutomationGovernance]]：集成治理是自动化治理的核心组成部分 -- [[ReliabilityBaseline]]：通过集成治理确保整个系统链路的可靠性 -- [[N8nWorkflowStandard]]：n8n 工作流中的"External Actions"步骤需遵循集成治理规范 -- [[ReAuditTriggers]]：重审计触发条件 - -## Sources -- [[automation-governance-architect]]（primary） diff --git a/wiki/concepts/Intent-Classification.md b/wiki/concepts/Intent-Classification.md deleted file mode 100644 index fa14c96a..00000000 --- a/wiki/concepts/Intent-Classification.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Intent Classification" -type: concept -tags: [] -sources: [] ---- - -# Intent Classification - -## Definition - -AI 自动识别客户消息的意图（Purpose / Goal），将非结构化自然语言映射为预定义的分类标签，从而触发对应的处理策略和回复逻辑。 - -## Common Intent Categories - -| Intent | Trigger Keywords | Handling Strategy | -|--------|-----------------|-------------------| -| **FAQ** | "how much", "do you offer", "what is" | 从知识库检索答案并回复 | -| **Appointment** | "book", "schedule", "available", "reservation" | 检查可用性并确认预约 | -| **Complaint** | "frustrated", "refund", "terrible", "problem" | 标记人工审核 + 确认收到 | -| **Review** | "google review", "rating", "stars" | 感谢反馈 + 回应问题 | -| **Order Status** | "where is my order", "tracking", "delivery" | 查询系统返回状态 | - -## Implementation - -Intent Classification 通常通过 LLM 的 Function Calling 或 Prompt Engineering 实现： - -``` -User Message → LLM Intent Classification → Match Intent to Handler → Generate Response -``` - -在 [[OpenClaw]] 中通过 AGENTS.md 配置 `Classify intent` 步骤实现。 - -## Related Concepts - -- [[Unified-Inbox]]：意图分类应用于统一收件箱中的每条消息 -- [[Business-Knowledge-Base]]：FAQ 意图依赖知识库检索 -- [[Human-Handoff]]：投诉意图触发人工升级 - -## Sources - -- [[multi-channel-customer-service]] diff --git a/wiki/concepts/IntentDrivenRouting.md b/wiki/concepts/IntentDrivenRouting.md deleted file mode 100644 index 9e217c6c..00000000 --- a/wiki/concepts/IntentDrivenRouting.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "IntentDrivenRouting" -type: concept -tags: [routing, intent, AI-agent] -sources: [multi-channel-assistant] -last_updated: 2026-04-27 ---- - -## Definition -Intent-Driven Routing（意图驱动路由）是一种 AI Agent 设计模式：通过 Prompt 层或配置层定义"用户意图 → 工具/动作"的映射规则，AI 根据用户输入中的关键词或语义自动路由到对应的工具或工作流，而无需用户显式指定。 - -## How It Works -1. **意图识别**：AI 解析用户输入，识别核心意图（如"添加任务"、"发邮件"、"创建日程"） -2. **规则匹配**：根据 Prompt 中预定义的规则表，匹配意图到对应工具 -3. **工具执行**：调用对应工具完成任务 -4. **结果返回**：将工具输出以自然语言返回给用户 - -## Example from [[multi-channel-assistant]] -``` -Prompt 规则： -"Add [task] to my todo" → use Todoist -"Create a card for [topic]" → use Asana Video Pipeline project -"Schedule [event]" → use gog calendar -"Email [person] about [topic]" → draft email via gog gmail -"Upload [file] to Drive" → use gog drive -``` - -## Related Concepts -- [[TopicRouting]] — 意图路由与话题路由可组合使用（话题提供上下文，意图决定动作） -- [[Intent-Classification]] — 意图分类是路由的前置步骤 -- [[Agent-Routing-Rules]] — 基于规则的显式路由 - -## Connections -- [[multi-channel-assistant]] ← uses ← [[IntentDrivenRouting]] -- [[ToolOrchestration]] ← enables ← [[IntentDrivenRouting]]（工具编排提供可调用工具集） diff --git a/wiki/concepts/Intentional-Cloud-Strategy.md b/wiki/concepts/Intentional-Cloud-Strategy.md deleted file mode 100644 index 9754a052..00000000 --- a/wiki/concepts/Intentional-Cloud-Strategy.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -title: Intentional Cloud Strategy -type: concept -tags: [cloud-computing, strategy, architecture, decision-making] -date: 2026-04-19 ---- - -# Intentional Cloud Strategy - -**Intentional Cloud Strategy（有意的云策略）** 是一种系统化的云部署决策框架，要求企业根据工作负载的具体需求（安全性、性能、成本、合规）主动选择合适的云部署模式，而非盲目跟随趋势或单一供应商偏好。 - -## Definition - -> "The key element in balancing your choices is to develop an intentional cloud strategy that optimizes your use of each cloud environment. Start with defining the needs of your various workloads, then prioritize them based on the pros and cons of each model." — BMC Blog - -核心理念：**平衡是云架构的核心驱动力**。今天适合企业的选择未必适合未来，云策略需要持续评估和迭代。 - -## Decision Framework - -### Step 1: 工作负载分类（Workload Classification） - -按需求对工作负载进行分类： - -| 维度 | 问题 | -|------|------| -| **安全性** | 数据是否敏感？是否受行业法规约束（HIPAA/GDPR/ISO 27001）？ | -| **性能** | 是否需要低延迟？是否对 SLA 有严格要求？ | -| **可扩展性** | 是否有不可预测的流量峰值？ | -| **成本** | 长期运营成本 vs 前期投入如何权衡？ | -| **合规** | 数据主权要求？物理位置限制？ | - -### Step 2: 工作负载到部署模式的映射 - -``` -工作负载需求 → 推荐部署模式 -━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ -高安全 + 高合规 + 固定负载 → [[Private Cloud]] -低安全 + 高弹性 + 成本敏感 → [[Public Cloud]] -高安全 + 高弹性 + 跨地域 → [[Hybrid Cloud]] -多供应商 + 高可用 → [[Multi-Cloud-Strategy]] -``` - -### Step 3: 持续评估与平衡 - -云策略不是一次性决策，需要： -- 定期（季度/年度）审查现有工作负载分布 -- 跟踪 TCO 变化，识别过度配置 -- 评估新技术（Serverless、Edge Computing）对架构的影响 -- 保持对供应商锁定（Vendor Lock-In）的警惕 - -## Three Deployment Models Compared - -| 维度 | Public Cloud | Private Cloud | Hybrid Cloud | -|------|-------------|---------------|-------------| -| **安全性** | 中等（多租户隔离） | 高（专用资源） | 可控（敏感数据放私有） | -| **成本效率** | 高（小-中规模）/ 中（超大规模） | 中-高（大规模稳定负载） | 最优（动态分配） | -| **弹性扩展** | 极高 | 受限于私有容量 | 高（按需调用公） | -| **合规支持** | 基础合规 | 完全控制 | 灵活合规 | -| **管理复杂度** | 低 | 高 | 中-高 | - -## Workload Allocation Example (Hybrid) - -``` -Hybrid Cloud Workload Distribution: -┌──────────────────────────────────────────────┐ -│ Hybrid Cloud │ -│ │ -│ Private Cloud Public Cloud │ -│ ┌──────────────┐ ┌──────────────┐ │ -│ │ 核心业务系统 │←─────→│ 突发流量扩容 │ │ -│ │ (合规敏感) │ 策略 │ (Dev/Test) │ │ -│ │ ERP/CRM │ 驱动 │ CDN/静态资源 │ │ -│ │ 数据库 │ │ 批处理作业 │ │ -│ └──────────────┘ └──────────────┘ │ -│ ↕ 数据/应用共享 │ -└──────────────────────────────────────────────┘ -``` - -## Common Anti-Patterns (违背有意策略) - -1. **全押单一模式**：全部放公有云（忽略合规）或全部私有化（失去弹性） -2. **跟随趋势**：盲目追求"混合云"标签而未解决实际业务问题 -3. **供应商锁定**：过度依赖单一云供应商，迁移成本高 -4. **忽视 TCO**：只看初期成本，忽视长期运营费用 -5. **缺乏评估**：工作负载部署后不再复审，资源利用率低下 - -## Benefits of Intentional Approach - -- **成本最优化**：每种工作负载放在成本最低的云模式中 -- **安全性最强化**：敏感资产受专用资源保护 -- **业务连续性**：混合架构提供更好的灾难恢复能力 -- **技术敏捷性**：能快速响应业务变化和新技术 - -## Related Concepts - -- [[Cloud-Adoption-Strategy]] — 云战略的制定过程 -- [[Hybrid Cloud]] — 混合云是有意策略的常见实现形式 -- [[Multi-Cloud-Strategy]] — 多云策略是有意策略的进阶形式 -- [[Cost-Optimization]] — 有意策略驱动成本优化 -- [[Vendor-Lock-In]] — 有意策略需考虑避免供应商锁定 -- [[CapEx vs OpEx]] — 有意策略的财务决策基础 - -## Sources - -- [[Public vs Private vs Hybrid Cloud Differences Explained|sources/public-vs-private-vs-hybrid-cloud-differences-explained]] diff --git a/wiki/concepts/Internal-Controls.md b/wiki/concepts/Internal-Controls.md deleted file mode 100644 index 79d262b1..00000000 --- a/wiki/concepts/Internal-Controls.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Internal Controls" -type: concept -tags: [finance, accounting, compliance] -sources: [finance-bookkeeper-controller] -last_updated: 2026-05-02 ---- - -## Definition -内部控制（Internal Controls）是企业为确保财务报告可靠性、运营效率和合规性而建立的政策和程序体系。 - -## Control Design Components -- **Authorization Matrices**：授权矩阵，定义谁有权批准哪些类型的交易 -- **Approval Workflows**：审批工作流，确保所有重大交易经过适当审批 -- **System Access Controls**：系统访问控制，限制对敏感财务系统的访问 -- **Data Validation Rules**：数据验证规则，防止无效或未经授权的数据进入系统 - -## Control Monitoring -- 关键控制测试 -- 例外情况跟踪 -- 整改管理 - -## SOX Compliance -萨班斯-奥克斯利法案（SOX）对公众公司的内部控制提出了强制性要求： -- 控制文档化 -- 测试计划 -- 缺陷跟踪 -- 管理层声明 - -## Segregation of Duties -职责分离是内部控制的核心原则： -- 交易发起人 ≠ 审批人 -- 交易审批人 ≠ 记录人 -> "The person who initiates a transaction should not be the same person who approves or records it." - -## Policy Maintenance -- 会计政策文档化 -- 程序手册维护 -- 授权矩阵更新 - -## Core Principle -> "Internal controls exist because humans make mistakes (and occasionally worse). Trust but verify — then verify again." -> — Dana, Bookkeeper & Controller Agent - -## Success Metrics -- 内部控制例外率 < 3% -- 所有控制按测试计划执行 -- 零 SOX 重大缺陷 - -## Related Concepts -- [[Segregation-Of-Duties]] -- [[Audit Readiness]] -- [[GAAP-Compliance]] -- [[Account-Reconciliation]] diff --git a/wiki/concepts/Intersectionality.md b/wiki/concepts/Intersectionality.md deleted file mode 100644 index 87282a7d..00000000 --- a/wiki/concepts/Intersectionality.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Intersectionality" -type: concept -tags: [] -last_updated: 2026-05-15 ---- - -## Definition - -Intersectionality（交叉性）——一种分析框架，用于理解社会身份（如种族、性别、阶级、残障、国籍等）的交叉重叠如何产生独特的歧视和特权模式。该概念最早由 Kimberlé Crenshaw 于 1989 年提出，现已广泛应用于 UX 研究、品牌策略和 AI representation 领域。 - -在 AI 图像/视频生成的语境中，intersectionality 指的是：文化、年龄、残障状况、社会经济地位等多维度交叉重叠下的人类身份表征，要求特定的提示词架构方法来确保每个维度都被准确、尊严地呈现。 - -## Core Principles - -1. **Multiple Dimensions Simultaneously**：身份不是单一维度的叠加，而是在交叉点上产生独特体验 -2. **Non-Addictive Model**：不能用"多样性 = A + B + C"的加法模型，而要捕捉交叉点的独特性 -3. **Contextual Specificity**：同一身份在不同交叉点上可能有完全不同的表达 - -## In AI Imagery Context - -Inclusive Visuals Specialist 代理人对 intersectionality 的技术处理： -- **拒绝单维度 tokenization**：不能只指定"女性"或"黑人"，而要指定"45岁黑人女性高管，自然4C发型穿定制海军蓝西装" -- **拒绝平均化渲染**：AI 倾向于生成"平均"面孔，intersectionality 要求 distinct facial structures -- **拒绝刻板叠加**：不能简单叠加多个身份标签，而要捕捉身份之间的复杂互动 - -## Related Concepts - -- [[Negative Prompting]] -- [[Cultural Authenticity]] -- [[Sociological Accuracy]] -- [[Inclusive Visuals Specialist]] - -## Aliases - -- 交叉性 -- 交叉身份 diff --git a/wiki/concepts/Inversion.md b/wiki/concepts/Inversion.md deleted file mode 100644 index 7edad4f9..00000000 --- a/wiki/concepts/Inversion.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Inversion" -type: concept -tags: [Agent, Skill, Design Pattern, ADK] -sources: [google-5个agent-skill设计模式-2026-03-19] -last_updated: 2026-03-19 ---- - -## Overview -Inversion 是 Google ADK 发布的 5 种 Agent Skill 设计模式之一，让 Agent 先变成面试官问你问题，等你回答完再行动。这是最反直觉但最实用的模式之一。 - -## Mechanism -- Agent 变成面试官，先问一系列问题 -- 等待用户逐个回答 -- 明确、不可协商的门控指令（"不到所有阶段完成就不开始构建"） -- 等用户回答完所有问题后才开始行动 - -## Use Cases -- 项目规划：收集需求、约束、资源 -- PRD 生成：收集产品背景、目标用户、功能需求 -- 架构设计：收集技术栈、规模要求、预算限制 - -## Key Insight -> Agent 天生喜欢直接猜测和生成，Inversion 把这个流程完全反过来。 - -## Implementation -``` -SKILL.md: 门控指令（"不完成所有阶段不开始构建"） -→ Agent 逐阶段提问 -→ 用户回答 -→ 加载 plan-template.md -→ 生成最终计划 -``` - -## Related Concepts -- [[Generator]]：可以在开头依赖 Inversion 收集必要变量 -- [[Pipeline]]：另一种强制流程的模式 -- [[渐进式披露]]：类似的按需加载思想 - -## Connections -- [[Google5个AgentSkill设计模式]] ← part_of ← [[Inversion]] -- [[ADK]] ← published_by ← [[Inversion]] diff --git a/wiki/concepts/Investment-Analysis.md b/wiki/concepts/Investment-Analysis.md deleted file mode 100644 index eeb7f624..00000000 --- a/wiki/concepts/Investment-Analysis.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "Investment Analysis (NPV & IRR)" -type: concept -tags: ["finance", "investment", "npv", "irr"] -last_updated: 2026-04-30 ---- - -## Definition -投资分析是通过量化方法评估投资项目的可行性和盈利能力的财务决策框架，核心指标包括 NPV（净现值）、IRR（内部收益率）和投资回收期（Payback Period）。 - -## Core Metrics - -### NPV (Net Present Value) -``` -NPV = -初始投资 + Σ(第i期现金流 / (1 + 贴现率)^i) -``` -- **正值**：项目创造价值，值得投资 -- **负值**：项目摧毁价值，不建议投资 -- **零值**：项目盈亏平衡 - -### IRR (Internal Rate of Return) -使 NPV = 0 的贴现率 r： -``` -Σ(第i期现金流 / (1 + r)^i) - 初始投资 = 0 -``` -- **IRR > 贴现率**：项目可行 -- **IRR < 贴现率**：项目不可行 -- IRR 通过数值求解（如 `scipy.optimize.fsolve`）获得 - -### Payback Period -累计现金流首次超过初始投资的时间（以年为单位）： -``` -Payback = (n - 1) + (初始投资 - 累计现金流_{n-1}) / 第n期现金流 -``` - -### ROI -``` -ROI = (Σ现金流 - 初始投资) / 初始投资 × 100% -``` - -## Decision Matrix -| NPV | IRR | Payback | 风险评分 | 建议 | -|-----|-----|---------|---------|------| -| >0 | >贴现率 | <3年 | <3 | STRONG BUY | -| >0 | >贴现率 | 任意 | ≥3 | CONDITIONAL BUY | -| ≤0 或 IRR ≤ 贴现率 | — | — | — | DO NOT INVEST | - -## Target Returns -- 平均 ROI：**25%+** -- Payback Period：**<3年** -- 风险评分：**<3** - -## Implementation -参见 [[support-finance-tracker]] 中 `InvestmentAnalyzer` Python 类的实现，包含 NPV、IRR、Payback Period 和 ROI 的完整计算逻辑。 - -## Related Concepts -- [[Cash Flow Forecasting]]：投资分析的现金流输入依赖预测数据 -- [[Budget Variance Analysis]]：项目执行层面的财务监控 diff --git a/wiki/concepts/Invisible-Exclusion.md b/wiki/concepts/Invisible-Exclusion.md deleted file mode 100644 index 70567d21..00000000 --- a/wiki/concepts/Invisible-Exclusion.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Invisible Exclusion" -type: concept -tags: [cultural-intelligence, ux-design, internationalization, accessibility] -sources: [specialized-cultural-intelligence-strategist] -last_updated: 2026-04-25 ---- - -## Definition -软件产品中无意识地排斥特定用户群体的设计模式——在开发者的默认假设下运作，但用户（尤其是非西方文化背景者）会感受到摩擦、困惑或被排斥。之所以"隐性"，是因为设计者往往意识不到这些假设。 - -## Key Patterns - -### 命名结构假设 -- **问题**：强制 First Name / Last Name 拆分字段 -- **影响**：许多文化不使用严格的名字-姓氏二分法（西班牙语的双姓、越南的 HO + TEN、日本的氏 + 名等） -- **修复**：改为单一"Full Name"或"Preferred Name"字段 - -### 性别选项 -- **问题**：仅提供二元性别选择器 -- **影响**：跨性别者、非二元性别用户无法正确注册 -- **修复**：提供开放文本字段或"Prefer to self-describe"选项 - -### 颜色语义 -- **问题**：红色=错误/警告（西方惯例） -- **影响**：中国金融应用中红色表示"上涨"，用户会感到困惑 -- **修复**：颜色+文字标签组合，不依赖单一颜色传达语义 - -### 日期/时间格式 -- **问题**：MM/DD/YYYY 作为默认格式 -- **影响**：DD/MM/YYYY 地区（欧洲、亚洲大部分）用户混淆 -- **修复**：本地化格式检测或 ISO 8601 (YYYY-MM-DD) - -### RTL 阅读方向 -- **问题**：假设所有文字从左到右阅读 -- **影响**：阿拉伯语、希伯来语用户无法正常使用界面 -- **修复**：CSS `direction: rtl` + 镜像布局架构支持 - -## Why "Invisible"? -开发者本身属于其目标用户群体，因此这些假设对他们来说是"透明"的。[[Architectural Empathy]] 要求在设计阶段就主动质疑这些假设。 - -## Related Concepts -- [[Architectural Empathy]]（结构性同理心） -- [[Global-First-Architecture]]（全局优先架构） -- [[Cultural-Intelligence]]（文化智能） -- [[InclusiveVisuals]]（包容性视觉） diff --git a/wiki/concepts/JDBCWrapper.md b/wiki/concepts/JDBCWrapper.md deleted file mode 100644 index a1f1af97..00000000 --- a/wiki/concepts/JDBCWrapper.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: "JDBCWrapper" -type: concept -tags: - - AWS - - Java - - Database - - Security - - SDK ---- - -## Definition - -JDBC Wrapper（JDBC 包装器）是一种通过包装 JDBC 连接，配合 AWS SDK 从 AWS Secrets Manager 动态获取数据库凭据的编程模式，使应用程序无需硬编码数据库密码即可连接数据库。 - -## Problem Statement - -传统数据库连接方式： -``` -应用程序 → 配置文件/环境变量 → 数据库 - ↑ - 硬编码明文密码（安全风险） -``` - -**问题**： -- 密码在代码、配置文件或环境变量中明文存储 -- 密码变更需要修改配置并重启应用 -- 无法实现细粒度的访问控制 -- 密码泄露风险高 - -## Solution: JDBC Wrapper Pattern - -使用 JDBC Wrapper 的连接方式： -``` -应用程序 → JDBC Wrapper + AWS SDK → AWS Secrets Manager → 数据库 -``` - -**工作流程**： -1. 应用程序通过 JDBC Wrapper 建立连接 -2. JDBC Wrapper 调用 AWS SDK 向 Secrets Manager 请求凭据 -3. Secrets Manager 返回动态获取的数据库密码 -4. JDBC Wrapper 使用临时凭据建立数据库连接 -5. 连接完成后，凭据不在应用内存中长期保留 - -## Key Benefits - -| 优势 | 说明 | -|------|------| -| **无密码访问** | 用户无需知道数据库密码，通过 IAM 角色授权 | -| **动态轮换** | 数据库密码轮换时，应用无需重启 | -| **集中审计** | 所有数据库访问通过 Secrets Manager 记录 | -| **最小权限** | 基于 IAM 角色控制数据库访问权限 | -| **审计追溯** | 用户名由角色控制，可追溯数据库操作 | - -## Implementation Architecture - -``` -┌─────────────┐ ┌──────────────┐ ┌─────────────────┐ ┌──────────────┐ -│ Application │────▶│ JDBC Wrapper │────▶│ AWS SDK │────▶│ Secrets │ -│ │ │ (密码获取) │ │ (调用API) │ │ Manager │ -└─────────────┘ └──────────────┘ └─────────────────┘ └──────────────┘ - │ - ▼ - ┌──────────────┐ - │ Oracle/MySQL │ - │ Database │ - └──────────────┘ -``` - -## Access Control Model - -- **用户名**：由 IAM 角色控制，根据角色映射数据库用户 -- **密码**：由 AWS Secrets Manager 动态提供，无需人工知晓 -- **访问权限**：通过 IAM Policy 控制谁能访问哪些 Secrets - -## Related Concepts - -- [[SecretsManagement]]：敏感信息管理的整体框架 -- [[SecretRotation]]：密码轮换机制，与 JDBC Wrapper 配合实现无停机轮换 -- [[AWS-SDK]]：AWS 服务调用开发工具包 -- [[IAM-Roles]]：基于角色的访问控制机制 - -## Sources - -- [[CTP-Topic-62-AWS-Secrets-Manager]] — Victor 演示使用 JDBC Wrapper + AWS SDK 实现无密码 Oracle 数据库登录 - -## Aliases - -- Database Credential Provider -- Secrets Manager JDBC Driver -- Dynamic Database Credentials -- AWS SDK Database Wrapper diff --git a/wiki/concepts/JFFS双清.md b/wiki/concepts/JFFS双清.md deleted file mode 100644 index caa3a0b7..00000000 --- a/wiki/concepts/JFFS双清.md +++ /dev/null @@ -1,33 +0,0 @@ -# JFFS双清 - -## Definition -清理路由器JFFS（Journaling Flash File System）分区中存储的文件系统缓存和数据配置的操作，用于刷机后重置干净的环境。 - -## Definition (English) -The process of clearing the JFFS (Journaling Flash File System) partition on ASUSWRT-based routers, removing cached data and old configurations to ensure a clean firmware environment. - -## When to Use -- 刷机后（从原厂固件刷入梅林固件后） -- 固件升级后出现异常 -- 重置插件配置 -- 清理旧缓存残留 - -## What It Clears -- JFFS 分区内容（插件存储、配置文件） -- 缓存数据 -- 旧的软件中心数据 - -## How to Perform -1. 进入梅林固件后台 -2. 找到"恢复/重置"选项 -3. 选择"恢复出厂设置" -4. 执行JFFS双清（可能需要手动命令） - -## Importance -- 防止旧配置干扰新固件 -- 清理过期的插件残留 -- 确保固件环境干净稳定 - -## Related -- [[固件刷入]] — JFFS双清是刷机流程的一部分 -- [[梅林固件]] — JFFS是梅林固件的文件系统 diff --git a/wiki/concepts/Jenkins-Multi-Branch-Pipeline.md b/wiki/concepts/Jenkins-Multi-Branch-Pipeline.md deleted file mode 100644 index 29a9f1b6..00000000 --- a/wiki/concepts/Jenkins-Multi-Branch-Pipeline.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Jenkins Multi-Branch Pipeline" -type: concept -tags: ["CI/CD", "Jenkins", "Automation", "DevOps"] -sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"] -last_updated: 2026-05-08 ---- - -## Definition -Jenkins 多分支流水线（Jenkins Multi-Branch Pipeline）是 Jenkins 的流水线即代码功能，支持根据 Git 分支自动创建和管理流水线。在 Micro Focus AWS Landing Zone 中，用于 AMI 构建和 IaC 部署的双重场景。 - -## Architecture Pattern -- **Feature Branch Pipeline**：功能分支上变更 → 开发测试 → 合并到集成分支 -- **Integration Branch Pipeline**：集成分支合并 → 构建 → 测试 → 发布 -- **Jenkinsfile**：在代码仓库中定义流水线即代码 - -## Dual Use Cases - -### AMI 构建 -1. Jenkins 扫描 Git 仓库的分支 -2. 每个分支触发独立流水线 -3. HashiCorp Packer 执行镜像构建 -4. 脚本化测试 + AWS Inspector 安全扫描 -5. 跨区域 AMI 复制和共享 - -### IaC 部署（Terraform/TerraGrunt） -1. GitHub 仓库变更触发 Jenkins -2. Terraform Plan 输出变更计划 -3. 审批后执行 Terraform Apply -4. 跨账户角色切换部署 - -## Connections -- [[Jenkins]] — 托管多分支流水线的 CI/CD 平台 -- [[Terraform-IaC]] — 流水线编排的 IaC 工具 -- [[Terragrunt]] — 配合 Terraform 的 DRY 工具 -- [[Amazon-Machine-Image]] — 多分支流水线构建的产物 diff --git a/wiki/concepts/Jira-Gate.md b/wiki/concepts/Jira-Gate.md deleted file mode 100644 index bed68512..00000000 --- a/wiki/concepts/Jira-Gate.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Jira Gate" -type: concept -tags: ["project-management", "jira", "workflow", "quality-gate"] -last_updated: 2026-04-25 ---- - -## Definition - -Jira Gate（Jira 门控）是 [[Jira Workflow Steward]] Agent 实施的一项强制性工作流规则：**在没有有效 Jira Task ID 的前提下，不生成任何分支名、提交信息或 Git 工作流建议**。Jira Task ID 是所有交付输出的前提条件。 - -## Rules - -1. **Never generate without Jira ID**：分支名、commit message、PR 标题均必须包含有效 Jira Task ID -2. **Exact preservation**：严格使用 Jira ID 原样，不得发明、规范或猜测缺失的 ticket 引用 -3. **Prompt for ID, don't guess**：若 Jira 任务缺失，则请求补充，而非自动创建 ID - -> 若 Jira 任务缺失，询问：`Please provide the Jira task ID associated with this work (e.g. JIRA-123).` - -## External Prefix Handling - -若外部系统（如 AI 编码 agent）添加了外层前缀，分支名内部仍需保持仓库原生格式： - -- ✅ `codex/feature/JIRA-214-add-sso-login`（仓库格式在外部包装内保持不变） -- ❌ `feature/JIRA-214-add-sso-login` → `codex/JIRA-214-add-sso-login`（丢失仓库类型信息） - -## Gate Position in Workflow - -``` -[Request] → [Jira Gate: 要求 Jira ID] → [Branch Strategy] → [Atomic Commits] → [PR Template] → [Release] - ↓ -[无 Jira ID → 停止并请求] -``` - -Jira Gate 位于整个交付链路的最前端，是第一道质量门。 - -## Relationship to Other Concepts - -- [[Jira-Git-Traceability]]：Jira Gate 是 Jira-Git Traceability 的第一步门控 -- [[Branch-Strategy]]：Gate 通过后才进入分支策略流程 -- [[Pull-Request-Governance]]：PR 合并同样需要 Jira ID 验证 - -## Sources -- [[project-management-jira-workflow-steward]] diff --git a/wiki/concepts/Jira-Git-Traceability.md b/wiki/concepts/Jira-Git-Traceability.md deleted file mode 100644 index fa960d56..00000000 --- a/wiki/concepts/Jira-Git-Traceability.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Jira-Git Traceability" -type: concept -tags: ["project-management", "jira", "git-workflow", "delivery-traceability"] -last_updated: 2026-04-25 ---- - -## Definition - -Jira-Git Traceability（ Jira-Git 可追溯性）是指通过 Jira Task ID 将软件交付链路中的 Jira 任务、分支、提交、Pull Request 和 Release 五个环节串联为完整可追溯记录的工作流实践。其核心原则为：**若某项变更无法从 Jira 追踪到分支、提交、PR 直至发布，则该工作流视为不完整**。 - -## Core Components - -| 环节 | 要求 | 工具/模式 | -|------|------|----------| -| Jira Task | 所有 Git 工作流的唯一锚点 | Jira Gate 强制前置 | -| Branch | 必须包含 Jira ID：`feature/JIRA-214-xxx` | 分支策略 | -| Commit | 必须包含 Jira ID：` JIRA-214: description` | Gitmoji Commit 规范 | -| Pull Request | PR 标题必须包含 Jira ID | PR 模板 | -| Release | 发布记录必须关联 Jira 任务或变更控制项 | Release Branch | - -## Why It Matters - -1. **Review Speed**：reviewer 可在 5 秒内通过 commit subject 识别变更类型和 ticket 上下文 -2. **Release Notes**：从 Jira 和 Git 历史可在 10 分钟内重建发布说明 -3. **Incident Forensics**：事故溯源时可在分钟内定位引入行为的 ticket 和 commit -4. **Audit Readiness**：合规环境中，需求到代码的完整链路是审计强制要求 -5. **Atomic Reverts**：commit 原子化且 purpose-labeled，回滚操作低风险 - -## Relationship to GitOps - -Jira-Git Traceability 是 GitOps 在项目管理层面的扩展： -- **GitOps** 关注：基础设施声明 → Git → 自动调和（环境始终与 Git 同步） -- **Jira-Git Traceability** 关注：需求（Jira）→ 代码（Git）→ 交付（Release）全链路可追溯 - -两者互补：GitOps 确保基础设施状态，Jira-Git Traceability 确保业务需求到代码的双向可追溯。 - -## Sources -- [[project-management-jira-workflow-steward]]（主要来源） diff --git a/wiki/concepts/Journal-Entry.md b/wiki/concepts/Journal-Entry.md deleted file mode 100644 index 1d69391f..00000000 --- a/wiki/concepts/Journal-Entry.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Journal Entry" -type: concept -tags: [finance, accounting] -sources: [finance-bookkeeper-controller] -last_updated: 2026-05-02 ---- - -## Definition -日记账分录（Journal Entry，JE）是记录非标准或手工财务交易的机制，每笔分录必须满足 GAAP 合规要求并附带完整支持文档和审批记录。 - -## Entry Types - -### Standard Recurring Entries -- 折旧和摊销 -- 租金和保险 -- 工资税和福利应计 -- 预付账款摊销 - -### Adjusting Entries -- 期末调整（未入账收入/费用） -- 纠正错误分录 -- 会计估计调整 - -### Reclassification Entries -- 账户重分类 -- 往来科目调整 - -### Elimination Entries -- 关联方交易抵销 -- 合并报表抵销 - -## Documentation Requirements -> "Journal entries require documentation. Every manual journal entry needs a description, supporting documentation, and approval. 'Adjusting entry' is not a description." - -### Must Include -1. **Description**：详细描述经济业务实质（如"记录11月水电费应计，根据11/15抄表数据"） -2. **Supporting Documentation**：发票、合同、计算底稿、邮件确认等 -3. **Approval**：授权人审批记录 -4. **Date & Period**：入账日期和所属期间 - -## Automation Philosophy -> "Automate the recurring, focus the brain on the exceptional. Manual journal entries should be the exception, not the rule." - -## Prior Period Adjustments -> "Never adjust prior periods without disclosure. If a correction impacts previously reported numbers, document the impact and communicate to stakeholders." - -## Related Concepts -- [[Month-End-Close-Process]] -- [[Account Reconciliation]] -- [[GAAP-Compliance]] -- [[Internal Controls]] diff --git a/wiki/concepts/KEDA.md b/wiki/concepts/KEDA.md deleted file mode 100644 index f260a9ef..00000000 --- a/wiki/concepts/KEDA.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "KEDA (Kubernetes Event-Driven Autoscaling)" -type: concept -tags: - - Kubernetes - - EKS - - Autoscaling - - Event-Driven - - Serverless -sources: - - ctp-topic-64-scaling-out-with-amazon-eks -last_updated: 2026-04-28 ---- - -## Definition -KEDA（Kubernetes Event-Driven Autoscaling）是一个基于外部事件驱动的 Kubernetes 扩缩容框架，通过 ScaledObject 自定义资源定义（CRD）实现细粒度的事件驱动扩缩容，支持将应用从零副本扩展到任意规模。 - -## Key Mechanisms -- **ScaledObject CRD**：定义扩缩规则，指定 Scaler 和目标副本数范围 -- **事件源（Scalers）**：支持 50+ 种事件源（Kafka、RabbitMQ、AWS SQS、Azure Queue、HTTP 等） -- **零扩展（Scale to Zero）**：支持将应用缩容至零副本，降低空闲资源成本 -- **Publishes Metrics 模式**：可向 HPA 发布指标，实现事件驱动与指标驱动的混合扩缩容 -- **声明式配置**：通过 YAML 配置文件定义扩缩行为，与 GitOps 工作流兼容 - -## Relationship with HPA -- KEDA 可独立工作，也可作为 HPA 的指标提供者 -- 组合模式：KEDA 监听外部事件 → 发布指标 → HPA 基于指标调整副本数 - -## Use Cases -- 事件驱动微服务（消息队列消费者） -- 批处理作业（按需触发） -- 突发流量场景（限时促销、实时事件） -- 无服务器化改造（零扩展降低成本） - -## Sources -- [[ctp-topic-64-scaling-out-with-amazon-eks]] diff --git a/wiki/concepts/KFactor.md b/wiki/concepts/KFactor.md deleted file mode 100644 index 40321299..00000000 --- a/wiki/concepts/KFactor.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "K-Factor" -type: concept -tags: ["viral", "metrics", "growth", "referral"] -last_updated: 2026-04-26 ---- - -## Definition -病毒系数（K-factor）——衡量有机传播效率的指标。K = 邀请率（每个用户平均发送邀请数）× 接受率（每个邀请的平均接受转化率）。K > 1.0 意味着每个用户平均能带来超过一个新增用户，实现指数级自然增长；K < 1.0 则增长需要依赖外部获客渠道。 - -## Formula -``` -K-factor = 邀请率 × 接受率 - = (发送邀请数 / 总用户数) × (接受邀请数 / 发送邀请数) -``` - -## Interpretation -| K-factor | Growth Pattern | -|----------|---------------| -| K > 1.0 | 指数级自然增长（病毒式传播）| -| K = 1.0 | 线性增长（每位用户带来一位新用户）| -| K < 1.0 | 需要外部获客渠道补充 | - -## Source -- [[marketing-growth-hacker]]（Marketing Growth Hacker Agent） - -## Aliases -- Viral Coefficient diff --git a/wiki/concepts/KV-Cache.md b/wiki/concepts/KV-Cache.md deleted file mode 100644 index 4417dbfc..00000000 --- a/wiki/concepts/KV-Cache.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "KV Cache" -type: concept -tags: [kv-cache, inference, llm, optimization] -aliases: [KV Cache, Key-Value Cache, KV缓存] -last_updated: 2025-12-20 ---- - -## Definition -KV Cache，大语言模型推理过程中的缓存机制。K（Key）和 V（Value）是由每个 Token 的向量通过线性变换得到的两类向量，用于注意力计算。KV Cache 将这些历史 K/V 保存下来，避免后续解码步骤重复计算。 - -## Key Facts -- 节省计算：无需每次都重新计算历史 Token 的注意力 -- 显存开销：KV Cache 随上下文长度、层数、头数、维度线性增长，是推理中最大的显存开销来源之一 -- [[vLLM]] 的核心优化对象 -- [[PagedAttention]] 通过分块管理解决其碎片化问题 - -## Connections -- [[vLLM]] ← 优化 ← [[KV Cache]] -- [[PagedAttention]] ← 解决 ← [[KV Cache]] 的碎片化问题 - -## Sources -- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]] diff --git a/wiki/concepts/Kaizen.md b/wiki/concepts/Kaizen.md deleted file mode 100644 index 2d5f9b3e..00000000 --- a/wiki/concepts/Kaizen.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Kaizen" -type: concept -tags: [Continuous-Improvement, Lean, Process-Improvement] -sources: [testing-workflow-optimizer, devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin, AgilePractices] -last_updated: 2026-04-21 ---- - -# Kaizen - -改善（Kaizen）——日语"継続的改善"（持续改进）的音译，是一种以员工为核心、小步快跑、渐进式的持续改进哲学。核心理念：所有流程都有改进空间，每次改进即使微小，累积效果也十分显著。 - -## Aliases -- 改善 -- 持续改进（Continuous Improvement） -- 渐进式改进 - -## Origin -源自丰田生产系统（TPS），由日本管理大师今井正明（Masaaki Imai）在 1986 年《Kaizen》一书中向西方推广。 - -## Core Principles -1. **Process Focus**（过程导向）——好的结果来自好的过程，聚焦过程改进而非单纯追求结果 -2. **Everyone Involved**（全员参与）——从 CEO 到一线员工，每个人都是改进的推动者 -3. **Small Improvements**（小步改进）——大幅改进往往由无数小改进累积而成 -4. **Discipline**（纪律性）——坚持不懈，持续执行 -5. **Eliminate Waste**（消除浪费）——持续识别和消除 Mudas（浪费） - -## Key Practices -- **改善活动（Kaizen Event）**：短周期（1-5天）跨职能团队聚焦单一流程的密集改进 -- **PDCA Cycle**（戴明环）： - - **Plan**：计划改进 - - **Do**：执行改进 - - **Check**：检查结果 - - **Act**：标准化或重新改进 -- **5S**：整理（Sort）/整顿（Set in Order）/清扫（Shine）/清洁（Standardize）/素养（Sustain） -- **无责归因（No-Blame Culture）**——改进系统而非惩罚个人 -- **Gemba Walk**（现场走动）——管理者到实际工作现场观察和改进 - -## Kaizen vs Six-Sigma -| 维度 | Kaizen | Six-Sigma | -|------|--------|-----------| -| 节奏 | 渐进式，持续小改 | 阶段性，DMAIC 大改 | -| 方法 | 定性为主，全员参与 | 定量为主，专家主导 | -| 目标 | 消除浪费，流动改善 | 减少变异，接近目标值 | -| 适用场景 | 文化变革，持续改进 | 复杂问题，系统优化 | - -两者互补：Kaizen 营造持续改进文化，Six-Sigma 解决深层复杂问题。 - -## In DevOps Context -DevOps 文化的四大支柱之一：Continuous Improvement (Kaizen)。实现方式：无责复盘（blameless post-mortems）、metrics驱动的瓶颈识别、混沌工程。 - -## Connections -- [[Lean]] — 共享消除浪费的核心价值观 -- [[Six-Sigma]] — 互补：渐进 vs 阶段 -- [[DevOpsCulture]] — DevOps 文化四大支柱之一 diff --git a/wiki/concepts/Kanban.md b/wiki/concepts/Kanban.md deleted file mode 100644 index 2a3e7ed6..00000000 --- a/wiki/concepts/Kanban.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Kanban" -type: concept -tags: [project-management, agile] -sources: [project-state-management, overnight-mini-app-builder] -last_updated: 2026-04-27 ---- - -## 定义 -Kanban 是一种敏捷框架，强调持续流动（continuous flow），无固定 Sprint 边界，允许随时调整优先级和需求。 - -## 核心特征 -- **持续交付：** 无需等待 Sprint 结束即可发布 -- **随时变更：** 优先级可在任何时候调整 -- **可视化看板：** 通过列（列名）管理任务状态 -- **限制在制品（WIP）：** 控制同时进行的工作数量 - -## 与 Scrum 的对比 -| 维度 | Scrum | Kanban | -|------|-------|--------| -| 迭代周期 | 固定 Sprint（1-4周） | 无固定周期 | -| 变更时机 | Sprint 期间禁止 | 随时可调整 | -| 发布节奏 | Sprint 结束时批量发布 | 持续交付 | -| 仪式 | Sprint Planning/Review/Retrospective | 可选 ceremonies | - -## 企业实践：混合框架 -云转型团队采用以 Kanban 为主 + 保留 Scrum 仪式（每日站会和回顾会议）的混合方案，兼顾灵活性和反馈循环。 - -## 来源 -- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] - -## 别名 -- Kanban Framework diff --git a/wiki/concepts/Karpenter.md b/wiki/concepts/Karpenter.md deleted file mode 100644 index 18da2527..00000000 --- a/wiki/concepts/Karpenter.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Karpenter" -type: concept -tags: [AWS, Kubernetes, EKS, autoscaling, node-provisioning] -last_updated: 2026-04-28 ---- - -## Definition - -Karpenter 是 AWS 开源的 Kubernetes 节点自动配置工具（Node Auto-Provisioner），通过动态创建最优实例类型来响应未调度 Pod 的资源需求，替代传统的 Cluster Autoscaler。相比 Cluster Autoscaler 基于节点组（Node Group）的扩缩容模式，Karpenter 直接与 EC2 API 交互，根据 Pod 规格（CPU/内存/GPU 需求）即时选择最合适的 EC2 实例类型，实现更快的扩容速度和更低的资源浪费。 - -## Key Mechanisms - -- **即时节点供给**：监听未调度 Pod 事件，秒级启动新节点，无需等待节点组预配置 -- **最佳实例选择**：根据 Pod 资源请求从 EC2 实例类型池中选择最优匹配 -- **多样化实例类型**：支持多种 EC2 类型（CPU/GPU/Spot/On-Demand），灵活利用 Spot 实例节省成本 -- **标签驱动配置**：通过 `NodeTemplate` 定义标签/要求，自动匹配特定 Pod 到特定节点 -- **与 Cluster Autoscaler 的区别**：Cluster Autoscaler 依赖节点组规模调整，Karpenter 直接控制 EC2 实例创建，响应更快速灵活 - -## Relationship with Cluster Autoscaler - -Karpenter 是 Cluster Autoscaler 的替代/演进方案： -- Cluster Autoscaler 通过调整节点组规模间接扩缩节点 -- Karpenter 直接与 EC2 API 交互创建/终止节点，更快速灵活 -- EKS Auto Mode（Part 3 of 3）已集成 Karpenter 作为 Carpenter Controller 组件 - -## Sources -- [[ctp-topic-70-eks-deployment-using-iac]] -- [[public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization]] -- [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]] diff --git a/wiki/concepts/Karpman-Drama-Triangle.md b/wiki/concepts/Karpman-Drama-Triangle.md deleted file mode 100644 index 15386d5b..00000000 --- a/wiki/concepts/Karpman-Drama-Triangle.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "Karpman Drama Triangle" -type: concept -tags: [] -sources: ["academic-psychologist"] -last_updated: 2026-04-20 ---- - -## Definition - -Karpman 戏剧三角（Drama Triangle）由 **Stephen Karpman** 1968 年提出，描述人际冲突中常见的三种不健康角色位置：受害者（Victim）、迫害者（Persecutor）、拯救者（Rescuer）。 - -``` - 拯救者 - (Rescuer) - ↗ ↖ - ↘ ↙ -受害者 ←────────→ 迫害者 -(Victim) (Persecutor) -``` - -### 三角角色特征 - -| 角色 | 位置 | 典型语言 | 内心感受 | -|------|------|---------|---------| -| **受害者（Victim）** | "我无法" | "我没办法"、"这不公平" | 无力、无助、被迫害感 | -| **迫害者（Persecutor）** | "都是你的错" | "你应该"、"你总是" | 控制、指责、愤怒 | -| **拯救者（Rescuer）** | "我来帮你" | "让我来"、"交给我吧" | 假装无私、实际需要被需要 | - -### 三角旋转 - -- 三角角色会**相互转换**：拯救者常变成迫害者（"你居然不感激我"），受害者可能变成迫害者 -- 三角是**自我永续**的——每个角色都在无意识地强化其他两个角色 - -## Key References - -- **Stephen Karpman**：戏剧三角提出者（Fairy Tales and Script Drama Analysis，1968） - -## Healthy Alternative: The Winner's Triangle - -| 戏剧三角 | 赢家三角 | -|---------|---------| -| 受害者 → 示弱（Vulnerable） | "我需要帮助" | -| 迫害者 → 能力（Caring） | "我相信你能处理" | -| 拯救者 → 勇气（Courageous） | "让我们一起想办法" | - -## Applications in Character Design - -- **角色关系冲突建模**：识别角色对在冲突中的三角位置 -- **动态转换**：观察角色在压力下如何旋转到另一个不健康角色 -- **打破三角**：设计角色突破三角的成长时刻（从受害者→主张需求，从拯救者→设立边界） - -## Limitations - -- 简化了真实人际关系的复杂性 -- "受害者"概念可能污名化真实受害者 -- Karpman 本人后来对三角的局限性也有反思 - -## Connections - -- [[Transactional-Analysis]]（TA 是戏剧三角的理论基础，PAC 自我状态） -- [[Interpersonal-Dynamics]]（三角是人际动态的核心模式之一） -- [[Defense-Mechanisms]]（三角角色是个体防御机制在人际层面的表现） diff --git a/wiki/concepts/KarpmanDramaTriangle.md b/wiki/concepts/KarpmanDramaTriangle.md deleted file mode 100644 index 9c2a35e5..00000000 --- a/wiki/concepts/KarpmanDramaTriangle.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Karpman Drama Triangle" -type: concept -tags: [] -sources: [academic-psychologist] -last_updated: 2026-04-25 ---- - -# Karpman Drama Triangle - -## Aliases -- Drama Triangle -- Karpman Triangle -- Victim Triangle - -## Definition -Karpman 戏剧三角——识别人际互动中最常见的三种心理角色位置及其动态转换。 - -## Three Roles - -| 角色 | 核心信念 | 典型行为 | -|------|----------|----------| -| **Victim（受害者）** | "我不能"、"我无能为力" | 求助、依赖、被动承受 | -| **Persecutor（迫害者）** | "都是你的错" | 指责、控制、批评 | -| **Rescuer（拯救者）** | "你需要我的帮助" | 过度介入、隐性控制 | - -## Dynamic Transitions -戏剧三角的核心机制是**角色转换**： -- Rescuer → Victim：拯救失败后转向受害者心态 -- Victim → Persecutor：长期无力感积累后转向攻击 -- Persecutor → Victim：被迫承担时转为受害者 - -## Application in Character Design -Psychologist Agent 使用此框架映射角色间的权力动态和沟通模式，识别冲突升级的具体触发点。 - -## Connection to Wiki -- Source: [[academic-psychologist]] diff --git a/wiki/concepts/Keyword-Based-Monitoring.md b/wiki/concepts/Keyword-Based-Monitoring.md deleted file mode 100644 index 43104afb..00000000 --- a/wiki/concepts/Keyword-Based-Monitoring.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Keyword-Based Monitoring" -type: concept -tags: [Keyword, Monitoring, YouTube, Search, AI-Agent] -sources: [daily-youtube-digest] -last_updated: 2026-04-22 ---- - -## Definition - -Keyword-Based Monitoring 是一种以关键词/主题为触发条件，主动搜索并追踪新内容的方法。与 [[Channel-Based Monitoring]] 的"固定频道列表"不同，它以主题为中心——适合跟踪竞品动态、技术趋势、新闻事件等泛化兴趣。 - -## How It Works - -1. **Define keywords**: "Claude Code", "AI agents", "OpenClaw", etc. -2. **Periodic search**: AI Agent 定期通过 YouTube Search API 搜索含关键词的新视频 -3. **Deduplication**: 已处理视频 ID 存入 seen-videos.txt，避免重复 -4. **Transcript + Summary**: 对新视频执行 [[Transcript-Based Summarization]] -5. **Delivery**: 合并到 [[Daily-Digest]] - -## Use Cases - -- **竞品追踪**: 监控竞品官方频道 + 相关 KOL 频道 -- **技术跟踪**: "RAG", "Fine-tuning", "vLLM" 等技术关键词 -- **行业新闻**: 特定公司/产品的最新视频评论 - -## Connections -- [[Keyword-Based Monitoring]] ← powers ← [[Daily YouTube Digest]] -- [[Daily-Digest]] ← aggregates ← [[Keyword-Based Monitoring]] -- [[Channel-Based Monitoring]] ← complements ← [[Keyword-Based Monitoring]] diff --git a/wiki/concepts/Kill-Switch.md b/wiki/concepts/Kill-Switch.md deleted file mode 100644 index ffd7512e..00000000 --- a/wiki/concepts/Kill-Switch.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -title: "Kill Switch (应急切断开关)" -tags: [devops, disaster-recovery, reliability, feature-management, emergency-response] -created: 2026-04-25 ---- - -# Kill Switch (应急切断开关) - -**Kill Switch**（应急切断开关）是 [[Feature Flag]] 的一种紧急用法——在生产环境出现故障时，无需重新部署代码即可绕过或关闭故障组件的机制。Kill Switch 是 [[High Availability]] 的软件层保障。 - -## Definition - -Kill Switch 是部署在关键系统路径上的功能开关，用于在紧急情况下将流量切换到备用路径、备用组件或降级服务，从而实现秒级 RTO。 - -## Core Use Cases - -| 场景 | Kill Switch 动作 | RTO | -|------|-----------------|-----| -| 支付网关异常 | 切换到备用支付提供商 | 秒级 | -| 搜索结果异常 | 回退到旧搜索算法 | 秒级 | -| AI 模型产生幻觉 | 切换回上一版本模型 | 秒级 | -| 数据库迁移造成延迟 | 禁用新迁移相关功能 | 秒级 | -| 第三方 API 超时 | 切换到缓存数据或模拟响应 | 秒级 | - -## 与传统回滚的对比 - -| 维度 | 传统部署回滚 | Kill Switch | -|------|-------------|--------------| -| 触发时间 | 分钟到小时 | 秒级 | -| 数据影响 | 可能丢失新事务数据 | 不触碰数据层 | -| 故障窗口 | 整个回滚期间用户受影响 | 切换完成后立即恢复 | -| 操作复杂度 | 需要 CI/CD 流程重新部署 | 配置变更，点击开关 | -| 适用范围 | 全局，影响所有用户 | 可定向（地区/用户群/设备） | - -## Kill Switch 的价值 - -> "Instead of debugging under pressure while users suffer, you flip a switch and fix the problem properly later. Everybody wins." - -**传统方式**：在压力下调试 → 用户持续受损 → 时间窗口内无法保证修复质量 - -**Kill Switch 方式**：立即止血 → 切换到安全状态 → 有时间从容分析问题根源 - -## 设计原则 - -### 1. 识别关键路径 -- 支付流程 -- 用户认证 -- 核心数据写入 -- 第三方依赖调用 - -### 2. 预设备用路径 -- 备用支付提供商 -- 旧版本算法 -- 缓存数据 -- 降级服务（Degraded Mode） - -### 3. 可观测性优先 -- Kill Switch 切换前需要明确知道发生了什么 -- 监控指标、告警、日志必须到位 -- 切换后需要持续监控备用路径的健康状态 - -### 4. 文档化 -- 每个 Kill Switch 的触发条件需要事先定义 -- 团队成员需要知道开关在哪里、如何使用 -- 定期演练（Chaos Engineering） - -## Kill Switch 与 [[RTO]]/[[RPO]] - -Kill Switch 直接影响 RTO 和 RPO： - -- **RTO**：从小时级降至秒级（配置变更，不需要代码部署） -- **RPO**：保持近零（不触发数据回滚，不丢失新事务） - -## Kill Switch vs. Circuit Breaker - -| 维度 | Kill Switch | Circuit Breaker | -|------|-------------|-----------------| -| 触发方式 | 手动（人为决策） | 自动（基于错误率阈值） | -| 适用场景 | 已知故障、有预案 | 未知故障、无预期 | -| 灵活性 | 高（可指定备用路径） | 中（自动跳转到 fallback） | -| 协同需求 | 需要备用方案就绪 | 自动感知系统压力 | - -## 实践建议 - -1. **不要过度设计 Kill Switch**：每个关键路径设计 1-2 个关键开关即可 -2. **开关命名要语义化**：`kill_payment_v2` 而非 `flag_42` -3. **测试 Kill Switch**：定期在非紧急情况下测试开关是否正常工作 -4. **监控开关状态**：确保知道哪些开关处于开启/关闭状态 - -## Related Concepts - -- [[Feature Flag]] — Kill Switch 是 Feature Flag 的紧急用法 -- [[RTO]] — Kill Switch 将 RTO 从小时降至秒级 -- [[RPO]] — Kill Switch 保护 RPO（不丢失数据） -- [[High Availability]] — Kill Switch 是 HA 的软件层保障 -- [[Disaster Recovery]] — Kill Switch 是现代灾备的重要工具 -- [[Micro-Recovery]] — Kill Switch 实现 feature 级别的精准恢复 - -## Sources - -- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/concepts/Kinship-System.md b/wiki/concepts/Kinship-System.md deleted file mode 100644 index d4346823..00000000 --- a/wiki/concepts/Kinship-System.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Kinship System" -type: concept -tags: ["anthropology", "kinship", "descent", "alliance", "inheritance"] -last_updated: 2026-04-25 ---- - -## Definition -亲属制度——人类社会组织家族和继嗣关系的系统，决定了继承规则、政治联盟、居住模式和冲突解决方式，是社会的"基础设施"。 - -## Core Framework -- **继嗣规则**：父系（patrilineal）/ 母系（matrilineal）/ 双系（bilateral）/ 双重继嗣（double descent） -- **居住模式**：父居（patrilocal）/ 母居（matrilocal）/ 新居（neolocal）/ 舅居（avunculocal） -- **亲属称谓**：Hawaiian（普遍互称）/ Eskimo（核心家庭特指）/ Sudanese（每个亲属关系独立称谓）/ Omaha（交叉表亲特指） -- **交换理论**：Lévi-Strauss 认为亲属制度本质是女人的交换系统，通过婚姻建立联盟 - -## Connections -- [[Anthropologist-Agent]] ← must_design ← [[Kinship-System]] -- [[Structuralism]] ← analyzes ← [[Kinship-System]] -- [[Functionalism]] ← explains_functions_of ← [[Kinship-System]] -- [[Gift-Economy]] ← parallels ← [[Kinship-System]] diff --git a/wiki/concepts/Kirkpatrick-Model.md b/wiki/concepts/Kirkpatrick-Model.md deleted file mode 100644 index 8f6b3a8d..00000000 --- a/wiki/concepts/Kirkpatrick-Model.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Kirkpatrick Model" -type: concept -tags: [training-evaluation, learning-theory] -sources: [corporate-training-designer] -last_updated: 2026-05-29 ---- - -## Definition - -Kirkpatrick 四级培训评估模型由 Donald Kirkpatrick 于 1959 年提出，是企业培训效果评估的全球通用框架，从学员反应到业务结果分为四个层级，是衡量培训真实价值的核心工具。 - -## Four Levels - -### Level 1 — Reaction（反应） -- 测量学员对培训的满意程度 -- 方法：培训满意度问卷调查——课程评分、讲师评分、NPS（Net Promoter Score） -- 指标：满意度 ≥ 4.5/5.0，NPS ≥ 50 - -### Level 2 — Learning（学习） -- 测量学员在知识、技能和态度方面的学习成果 -- 方法：知识考试、技能实操评估、案例分析作业 -- 指标：关键课程考试通过率 ≥ 90% - -### Level 3 — Behavior（行为） -- 测量学员在实际工作中行为改变的程度 -- 方法：训后30/60/90天行为追踪——主管观察、关键行为检查清单 -- 指标：训后90天行为改变率 ≥ 60% -- 要求：高投资培训项目（领导力、关键岗位）必须追踪到 Level 3 - -### Level 4 — Results（结果） -- 测量培训对业务指标的最终影响 -- 方法：追踪业务指标变化（营收、客户满意度、生产效率、员工留存） -- 指标：可量化的业务影响（如：新员工上手时间缩短、客户满意度提升） - -## Key Principles -- **层级递进**：Level 1 是基础，Level 4 是终极目标——逐级验证才能确保培训真正创造价值 -- **必须量化**：培训目标必须可测量——不是"提高沟通技能"，而是"3个月内将新员工独立完成客户提案的比例从40%提升至70%" -- **用业务语言汇报**：向业务部门汇报培训价值时，使用业务指标而非培训指标 - -## Connections -- [[Kirkpatrick-Model]] ← evaluation_framework ← [[ADDIE-Model]]（ADDIE 的 E 阶段通常采用 Kirkpatrick 四级评估） -- [[Kirkpatrick-Model]] ← evaluation_standard ← [[Corporate-Training-Designer]]（培训设计师必须掌握的核心评估方法） -- [[Bloom-Taxonomy]] ← learning_objective_framework ← [[Kirkpatrick-Model]]（Bloom 定义"学到什么"，Kirkpatrick 验证"学到了没有"） diff --git a/wiki/concepts/Kirkpatrick-四级评估.md b/wiki/concepts/Kirkpatrick-四级评估.md deleted file mode 100644 index efb8c3a5..00000000 --- a/wiki/concepts/Kirkpatrick-四级评估.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Kirkpatrick 四级评估" -type: concept -tags: [] -last_updated: 2026-04-25 ---- - -## Definition - -Kirkpatrick 四级评估模型是衡量企业培训效果的标准框架，由 Donald Kirkpatrick 于 1959 年提出，分为四个层次： - -- **Level 1 — Reaction（反应）**：学员对培训的满意度调查——课程评分、讲师评分、NPS -- **Level 2 — Learning（学习）**：知识与技能掌握程度——知识测验、技能实操评估、案例分析作业 -- **Level 3 — Behavior（行为）**：训后行为改变——30/60/90 天行为跟踪、上级观察、关键行为清单 -- **Level 4 — Results（结果）**：业务指标变化——营收、客户满意度、生产效率、员工留存率 - -## Aliases -- Kirkpatrick Model -- Kirkpatrick 四级评估 -- Kirkpatrick 四层次评估 -- 培训效果评估模型 - -## Key Characteristics - -- **逐级递进**：Level 1-2 较易测量，Level 3-4 需要更长周期和更复杂的数据收集 -- **业务导向**：Level 3-4 直接关联业务指标，是培训投资回报（ROI）的核心证明 -- **最低标准**：所有培训项目至少应评估到 Level 2（Learning） -- **高投资标准**：领导力发展、关键岗位培训等高投资必须追踪到 Level 3（Behavior） - -## Source - -- [[corporate-training-designer]] diff --git a/wiki/concepts/Kishotenketsu.md b/wiki/concepts/Kishotenketsu.md deleted file mode 100644 index e80284cb..00000000 --- a/wiki/concepts/Kishotenketsu.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Kishōtenketsu" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-30 ---- - -## Aliases -- Kishōtenketsu -- 起承転結 -- Kishotenketsu Structure - -## Overview -Kishōtenketsu（起承転結）是日本/东亚四幕叙事结构，由四个阶段组成：起（Introduction）、承（Development）、転（Twist）、結（Conclusion）。与西方三幕式的"冲突驱动"不同，Kishōtenketsu 的第三幕" Twist"不必须有冲突，而是引入意外元素，与前两幕形成对比，创造张力和趣味。 - -## Four Stages - -| Stage | Kanji | Description | -|-------|-------|-------------| -| **起 Ki (Introduction)** | 起 | 介绍人物、环境、情境 | -| **承 Sho (Development)** | 承 | 展开/深化已建立的内容 | -| **転 Ten (Twist)** | 転 | 引入意外或无关元素，创造转折 | -| **結 Ketsu (Conclusion)** | 結 | 综合前四部分，赋予新意义 | - -## Key Difference from Western Structure -- **三幕式**：第三幕必须有危机/高潮（Conflict-driven） -- **Kishōtenketsu**：第三幕只是引入对比，不强制冲突——高潮可能出现在第四幕 - -## Examples -- 许多日漫（如《哆啦A梦》单集）：建立日常 → 深化日常 → 引入神奇道具 → 意外结果 -- [[Academic Narratologist]] 将其作为**跨文化叙事比较**的核心工具 - -## Relationship to Other Concepts -- [[Three-Act-Structure]]：西方对应模型，但缺少独立的"Twist"阶段 -- [[HeroesJourney]]：Hero's Journey 的结构是冲突驱动的，与 Kishōtenketsu 不同 diff --git a/wiki/concepts/Knock-out-Pattern.md b/wiki/concepts/Knock-out-Pattern.md deleted file mode 100644 index a8ad14df..00000000 --- a/wiki/concepts/Knock-out-Pattern.md +++ /dev/null @@ -1,37 +0,0 @@ ---- ---- -title: "Knock-out Pattern" -type: concept -tags: [] -sources: - - multi-agent-system-reliability -last_updated: 2026-04-28 ---- - -# Knock-out Pattern - -## 定义 -多智能体系统的淘汰制模式——将任务分配给N个Agent，用验证器决定哪些表现最差的被淘汰。核心是用"适者生存"替代LLM不存在的"死亡恐惧"。 - -## 核心机制 -1. 将任务分配给N个Agent -2. 用Validator决定要淘汰哪些Agent -3. （可选）用通过验证的Agent特征组合创建新Agent填补空缺 - -## ML渊源 -这是传统机器学习中[[Genetic-Algorithm]]（遗传算法）的精简实现，依赖两个要素： -- **遗传表示**：解决方案域（模型+上下文） -- **适应度函数**：淘汰决策依据 - -## 关键要求 -需要**快速验证输出的方式**（如单元测试）——如果需要人工检查所有分支，成本太高。Eval是必要基础设施。 - -## 适用场景 -迭代式智能体工程——主要用于开发/调试阶段，不适合生产环境的高用户负载。 - -## 与Tree of Thoughts的关系 -Tree of Thoughts是Knock-out模式的进阶实现，通过验证器持续筛选。 - -## 来源 -- [[multi-agent-system-reliability]] -- [[Genetic-Algorithm]] diff --git a/wiki/concepts/Knowledge-Base-RAG.md b/wiki/concepts/Knowledge-Base-RAG.md deleted file mode 100644 index b9fd6fd8..00000000 --- a/wiki/concepts/Knowledge-Base-RAG.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "Knowledge Base RAG" -type: concept -last_updated: 2026-04-22 ---- - -## Definition - -Retrieval-Augmented Generation（RAG）：在 LLM 生成回答前，先从外部知识库检索相关文档片段作为上下文补充，从而让 LLM 基于真实、私有或最新信息作答，而非依赖训练数据截止日期或模型幻觉。 - -## Architecture - -``` -用户问题 → 编码为向量 → 向量数据库 ANN 检索 → Top-K 相关片段 → 与原问题拼接 → LLM 生成 -``` - -## Components - -| 组件 | 说明 | -|------|------| -| **文档切分（Chunking）** | 将长文档拆分为适合检索的片段（通常 512-1024 tokens），过小丢失上下文，过大降低精度 | -| **Embedding 模型** | 将文本编码为向量（见 [[Vector-Embedding]]） | -| **向量数据库** | 存储 embedding 并支持 ANN 检索（Qdrant / Pinecone / pgvector / sqlite-vss） | -| **重排序（Reranker）** | ANN 初筛后，用重排序模型（如 BGE-Reranker）精排，提高 top-K 准确率 | -| **LLM** | 接收检索片段 + 原问题，生成最终回答 | - -## Chunking Strategies - -| 策略 | 适用场景 | -|------|------| -| 固定长度切分 | 简单快速，但可能切断语义单元 | -| 递归字符切分（Recursive Character Splitting） | 按段落/句子边界切分，保留语义完整性 | -| 基于语义切分（Semantic Chunking） | 用 LLM 判定切分点，效果最好但成本高 | -| Agentic Chunking | 按工作流/主题边界切分，适合知识库分域管理 | - -## Applications in OpenClaw Workflows - -| 场景 | 说明 | -|------|------| -| [[YouTube-Content-Pipeline]] | 分享 Slack 链接时，Agent 查询知识库了解用户已有内容，避免重复选题 | -| [[Second Brain]] | 个人知识库 RAG，支持跨记忆/文档的语义搜索 | -| [[Pre-Build-Idea-Validator]] | 扫描知识库确认是否已做过类似项目 | -| [[autonomous-game-dev-pipeline]] | 检索技术债务和已有代码片段 | - -## Quality Optimization - -1. **Hybrid Search**：向量检索 + BM25 关键词检索融合，提升召回率 -2. **Query Expansion**：将用户问题改写为多个视角再检索 -3. **Context Compression**：LLM 前对检索片段做摘要压缩，节省 token -4. **Chunk Overlap**：相邻 chunk 重叠 10-20% 防止边界截断关键信息 - -## Connections - -- [[Vector-Embedding]] — RAG 的检索底层 -- [[Semantic-Deduplication]] — 语义去重防止 RAG 检索重复片段 -- [[OpenClaw]] — 提供 `knowledge-base` skill 实现 RAG -- [[Second Brain]] — RAG 的个人知识管理应用 diff --git a/wiki/concepts/Knowledge-Base.md b/wiki/concepts/Knowledge-Base.md deleted file mode 100644 index a9c98c2b..00000000 --- a/wiki/concepts/Knowledge-Base.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Knowledge Base" -type: concept -last_updated: 2026-04-27 ---- - -## Definition - -集中存储、结构化索引、可按需检索的个人或组织知识集合——将分散的信息（文章、笔记、文档、网页）转化为可搜索、可链接的知识资产。 - -## Key Characteristics - -- **集中存储**：所有知识来源统一入口（URL/文件/对话内容） -- **结构化索引**：通过 Embedding 向量化或 Metadata 标签实现高效检索 -- **可搜索**：支持关键词搜索、语义搜索或两者混合搜索 -- **可链接**：知识条目之间相互引用，形成知识网络 - -## Relationship to Related Concepts - -- [[Semantic Search]]：知识库的核心检索技术 -- [[RAG]]：知识库是 RAG 系统的外部知识来源 -- [[Second Brain]]：知识库的终极目标——成为个人的第二大脑 -- [[Personal Knowledge Base (RAG)]]：知识库在个人场景的具体实现（URL 摄入 + 语义搜索） - -## Sources -- [[knowledge-base-rag]] diff --git a/wiki/concepts/Kolb-体验式学习圈.md b/wiki/concepts/Kolb-体验式学习圈.md deleted file mode 100644 index d7fbef23..00000000 --- a/wiki/concepts/Kolb-体验式学习圈.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Kolb 体验式学习圈" -type: concept -tags: [] -last_updated: 2026-04-25 ---- - -## Definition - -Kolb 体验式学习圈（Kolb's Experiential Learning Cycle）由 David Kolb 于 1984 年提出，描述了一个四阶段的循环学习过程： - -1. **Concrete Experience（具体经验）**：全身心投入真实或模拟的体验 -2. **Reflective Observation（反思观察）**：从不同视角审视体验，思考发生了什么 -3. **Abstract Conceptualization（抽象概念化）**：从经验中提炼出理论、模型或框架 -4. **Active Experimentation（主动实验）**：将概念应用于新的实践场景，测试假设 - -## Aliases -- Kolb's Learning Cycle -- Kolb 体验式学习 -- Kolb 学习圈 -- 体验式学习循环 - -## Key Characteristics - -- **闭环性**：四个阶段首尾相连，形成持续改进的学习螺旋 -- **个性化**：不同学习者偏好不同阶段（有人偏经验型，有人偏反思型） -- **主动学习**：强调"做中学"，而非被动接受知识 -- **应用场景**：沙盘模拟、角色扮演、剧本杀式培训、领导力发展项目 - -## Relationship to Other Concepts - -- **与 ADDIE 模型**：体验式学习可作为 ADDIE Implementation 阶段的教学方法 -- **与 Kirkpatrick Level 3**：体验式学习的闭环特性天然支持训后行为改变的追踪 - -## Source - -- [[corporate-training-designer]] diff --git a/wiki/concepts/Korean-Corporate-Hierarchy.md b/wiki/concepts/Korean-Corporate-Hierarchy.md deleted file mode 100644 index 38c1a9da..00000000 --- a/wiki/concepts/Korean-Corporate-Hierarchy.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: "Korean-Corporate-Hierarchy" -type: concept -tags: [] -sources: [] -last_updated: 2026-05-30 ---- - -## 基本信息 -- **原文**：한국 기업 직급 체계 -- **中文**：韩国企业职级体系 -- **英文**：Korean Corporate Title System - -## 定义 -韩国企业职级体系（직급 체계）是韩国商业文化的核心结构之一。与西方扁平化管理不同，韩国企业保持着严格的层级制度，每个职级都有明确的权利边界和沟通规范。理解和尊重这一体系是在韩国商业成功的关键前提。 - -## 完整职级对照表 - -| 韩文 | 英文对应 | 中文 | 决策权力 | 典型特征 | -|------|---------|------|---------|---------| -| 회장（Hoejang） | Chairman | 会长 | 最高权威 | 基本不直接互动 | -| 사장（Sajang） | CEO/President | 社长 | 最终商业决策 | 通常通过副会长/事业部长汇报 | -| 부사장（Bujajang） | Vice President | 副会长 | 高管级决策 | 重大交易直接参与 | -| 전무（Jeonmu） | Senior Managing Director | 专务 | 重大影响力 | 通常是事业部或子公司一把手 | -| 상무（Sangmu） | Managing Director | 常务 | 部门级权威 | 大型部门或核心子公司负责人 | -| 이사（Isa） | Director | 理事 | 项目级决策 | 可独立推进项目 | -| 부장（Bujang） | General Manager | 部长 | 团队级，很多是你的一线联系人 | 有一定自主决策权 | -| 차장（Chajang） | Deputy Manager | 次长 | 执行权威 | 执行层，通常是实际操作的人 | -| 과장（Gwajang） | Manager | 课长 | 很小的独立权力 | 通常是初次接触的入口点 | -| 대리（Daeri） | Assistant Manager | 代理 | 有限权力，但是很好的信息来源 | 职位低但信息量大 | - -## 称呼规范（必须遵守） - -**核心规则**：永远使用 **职称 + 님（nim）** 的格式 - -| 正确称呼 | 错误称呼 | -|---------|---------| -| 사장님 | 사장 | -| 부장님 |部长 | -| 과장님 | 과장 | -| 김과장님 | 김과장（除非关系非常亲密）| - -### 何时可以用名字 -- 只有当对方明确邀请你直呼其名时 -- 通常在经过多年合作、且对方主动说"以后叫我名字就好"之后 -- 即使可以叫名字，在正式场合仍建议使用职称 - -## 决策权力映射 - -| 你的联系人职级 | 能独立决定 | 需要上报 | 备注 | -|---------------|-----------|---------|------| -| 대리/과장 | 极小（内部门协调） | 几乎所有 | 不要期待决策 | -| 차장 | 小（执行细节） | 大多数 | 能提供内部信息 | -| 부장 | 中等（团队级） | 预算/跨部门 | 通常是你的主要联系人 | -| 이사 | 较大（项目级） | 大额预算 | 有一定影响力 | -| 상무以上 | 大（部门级） | 集团层面 | 品의发起人 | - -## 级别间互动潜规则 -1. **永远不要绕过级别联系上级** — 即使你直接联系了社长，他也会把事情推回给层级下属 -2. **信息自下而上流动** — 部长是连接你和高层的主要信息通道 -3. **级别决定座位/餐饮顺序** — 회식中体现最明显 -4. **Email 礼仪** — 发送给部长时，通常抄送 차장/과장，实际执行者需要知情 - -## 关于"越级"的严重后果 - -> **永远不要绕过你的联系人直接联系其上级** - -这在韩国商业中不是"高效率"，而是**关系终结行为**。后果包括： -- 你的联系人会感到被羞辱和背叛 -- 对方公司会将你标记为"不懂规矩的外国人" -- 未来的合作大门关闭 -- 你的联系人即使后来离开了，你也会被整个公司记住 - -**例外**：只有在联系人明确授权时说"我会直接联系社长"才可越级。 - -## SME vs 财阀的层级差异 - -| 维度 | SME | 财阀 | -|------|-----|------| -| 层级数 | 3-5 级 | 7-10 级 | -| 扁平化程度 | 较高，部长可直接决策 | 极低，每级都有 gatekeeper | -| 外国人直接接触高层可能性 | 存在 | 几乎不可能 | -| 决策周期 | 短 | 极长 | - -## 来源 -- [[specialized-korean-business-navigator]] — Korean Corporate Title Hierarchy 完整规范 diff --git a/wiki/concepts/Kraljic-Matrix.md b/wiki/concepts/Kraljic-Matrix.md deleted file mode 100644 index 3baf0f2f..00000000 --- a/wiki/concepts/Kraljic-Matrix.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Kraljic Matrix" -type: concept -tags: ["supply-chain", "procurement", "strategy", "category-management"] -last_updated: 2026-04-25 ---- - -## Aliases -- Kraljic 采购矩阵 -- Kraljic Model - -## Definition - -Kraljic Matrix（克拉利克矩阵）是由 Peter Kraljic 于 1983 年提出的供应商分类与采购战略框架，通过两个维度将采购品类划分为四类，以制定差异化的采购策略。 - -## Two Dimensions -- **利润影响（Profit Impact）**：该品类对公司利润/成本的影响力 -- **供应风险（Supply Risk）**：供应市场的复杂性、供应商集中度、替代难度等 - -## Four Quadrants - -| 类别 | 特征 | 策略 | -|------|------|------| -| **战略型（Strategic）** | 高利润影响 + 高供应风险 | 建立长期合作伙伴关系，共同投资，深度供应商协同 | -| **杠杆型（Leverage）** | 高利润影响 + 低供应风险 | 充分利用采购量杠杆，竞争性招标，追求最优价格 | -| **瓶颈型（Bottleneck）** | 低利润影响 + 高供应风险 | 寻找替代方案，降低依赖，确保供应连续性 | -| **常规型（Routine）** | 低利润影响 + 低供应风险 | 简化采购流程，标准化，自动化的机会 | - -## Key Insights - -- 每年至少重新评估一次品类定位，动态调整采购策略 -- 战略型品类需配备专职采购经理，建立战略合作伙伴关系 -- 瓶颈型品类应主动寻找替代物料或开发多个供应源 -- 常规型品类可通过电子采购平台实现自动化，降低交易成本 - -## Applications - -- [[Supply Chain Strategist Agent]] 使用 Kraljic Matrix 进行分类采购策略开发 -- 采购支出分析（spend analysis）通常作为矩阵定位的数据基础 -- 可结合 ABC 分类（按采购金额）对品类进一步细分 - -## Connections -- [[Supply Chain Strategist Agent]] ← uses_framework ← [[Kraljic Matrix]] -- [[TCO]] ← related_to ← [[Kraljic Matrix]]（战略型品类 TCO 评估尤为重要） diff --git a/wiki/concepts/Kubernetes-Tagging.md b/wiki/concepts/Kubernetes-Tagging.md deleted file mode 100644 index 06927cbc..00000000 --- a/wiki/concepts/Kubernetes-Tagging.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: "Kubernetes Tagging" -type: concept -tags: - - Kubernetes - - Tagging-Standard - - Cloud-Governance - - OpenText -sources: - - public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meeting-rec -last_updated: 2026-04-29 ---- - -# Kubernetes Tagging - -Kubernetes 标签标准是 OpenText 云标签标准 V2 版本的新增组成部分，定义了 Kubernetes 对象（Namespace、Pod、Deployment、Service、ConfigMap 等）上必须使用的标准标签键值对。与云资源标签类似，K8s 标签为 FinOps 成本分摊、安全策略和资源组织提供了统一的基础。 - -## Definition - -Kubernetes 标签（Labels）是附加在 K8s 对象上的键值对元数据，用于组织、选择和管理 Kubernetes 集群中的资源。OpenText V2 标准通过 `app.opentext.com` 前缀区分其专属标签，与标准 K8s 标签系统（前缀 `kubernetes.io/`）和自定义标签（前缀 `k8s.io/`）形成语义隔离。 - -## OpenText V2 标准标签 - -### 核心标签键 - -| 标签键 | 说明 | 示例值 | -|--------|------|--------| -| `app.opentext.com/product` | 产品名称 | `idm`, `operations` | -| `app.opentext.com/customer` | 客户名称 | `customer-a` | -| `app.opentext.com/environment` | 环境 | `prod`, `dev`, `uat` | -| `app.opentext.com/part-of` | K8s 对象归属（原生 K8s） | `deployment-name` | -| `app.opentext.com/name` | 对象名称 | `my-service` | -| `app.opentext.com/version` | 版本 | `v1.2.3` | - -### 与云标签的对应关系 - -K8s 标签与云资源标签在语义上保持一致： - -| K8s 标签 | 对应云标签 | 说明 | -|----------|-----------|------| -| `app.opentext.com/environment` | `OT_environment` | 环境维度统一 | -| `app.opentext.com/customer` | `OT_customer` | 客户维度统一 | -| `app.opentext.com/product` | `OT_business_unit` | 产品/业务单元 | - -## 命名规范 - -- **前缀**：`app.opentext.com` -- **键格式**：小写字母、数字、连字符（遵循 K8s DNS 子域名规则） -- **值格式**：无限制，可包含多级（如 `v1.2.3`） - -## 与云标签的关系 - -K8s 标签标准是 OpenText 云标签标准 V2 的扩展： - -- **云资源标签**：`OT_` 前缀（如 `OT_business_unit`） -- **K8s 对象标签**：`app.opentext.com/` 前缀 -- **容器镜像标签**：`com.opentext.image/` 前缀 - -三者共同构成 OpenText 跨层级的统一标签体系。 - -## 最佳实践 - -- 使用 Terraform 或 Kustomize 在部署时自动注入标签 -- 通过 Kyverno 或 OPA Gatekeeper 策略强制 K8s 标签合规 -- 对于 K8s 自动创建的资源（如 Service 创建的 LoadBalancer），使用 Annotations 记录间接标签信息 -- 避免在标签中存储敏感数据 - -## Connections -- [[Resource-Tagging]] — K8s 标签是资源标签体系的一部分 -- [[AWS-Tagging-Standards]] — 云标签标准的 K8s 扩展 -- [[Terraform]] — IaC 自动打标工具 -- [[public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meeting-rec]] diff --git a/wiki/concepts/Kubernetes.md b/wiki/concepts/Kubernetes.md deleted file mode 100644 index 84633fa1..00000000 --- a/wiki/concepts/Kubernetes.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Kubernetes" -type: concept -tags: [容器编排, 云原生, 分布式系统] -sources: [ctp-topic-70-eks-deployment-using-iac] -last_updated: 2026-04-24 ---- - -# Kubernetes - -## Overview -Kubernetes（K8s）是 Google 开源的容器编排平台，用于分布式系统的弹性运行。提供自动化部署、扩缩容、负载均衡、滚动更新和回滚等核心能力。 - -## Key Features -- **自动化部署与回滚**：根据声明式配置自动管理应用版本 -- **服务发现与负载均衡**：内置 DNS 和负载均衡机制 -- **自愈能力**：自动重启失败的容器，替换不健康的节点 -- **水平扩缩容**：根据 CPU/内存指标自动调整 Pod 数量 -- **存储编排**：支持多种存储后端（AWS EBS, NFS, Ceph 等） -- **密钥与配置管理**：管理敏感信息和配置，无需重建镜像 - -## Architecture -- **Control Plane**：主节点，包含 API Server、Scheduler、Controller Manager、etcd -- **Worker Nodes**：工作节点，运行 Pod，包含 kubelet、kube-proxy、Container Runtime - -## Key Concepts -- **Pod**：最小部署单元，一个 Pod 可包含一个或多个容器 -- **Deployment**：声明式更新，管理 Pod 副本数和滚动更新策略 -- **Service**：稳定的网络访问入口，通过标签选择器路由流量 -- **Ingress**：管理 HTTP/HTTPS 路由，实现七层负载均衡 -- **ConfigMap/Secret**：存储配置和敏感数据 -- **Namespace**：资源隔离和访问控制 - -## Related Concepts -- [[Amazon EKS]]：AWS 托管的 Kubernetes 服务 -- [[Cluster Autoscaler]]：Kubernetes 自动扩缩容组件 -- [[Infrastructure as Code]]：用于声明式管理 Kubernetes 资源 -- [[Cloud-Native]]：云原生应用的核心理念 -- [[Container（容器）]]：Pod 的基础运行时 - -## Related Entities -- [[Google]]：Kubernetes 的创始公司（2015 年捐给 CNCF） -- [[CNCF]]：托管 Kubernetes 项目的开源基金会 diff --git a/wiki/concepts/LLM-Wiki.md b/wiki/concepts/LLM-Wiki.md deleted file mode 100644 index e4f21121..00000000 --- a/wiki/concepts/LLM-Wiki.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "LLM Wiki" -type: concept -tags: [AI, knowledge-base, persistence] -sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环, llm-wiki, 养虾日记3] -last_updated: 2026-04-20 ---- - -## Aliases -- LLM-based Wiki -- LLM Wiki 模式 -- Persistent Wiki -- Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库 - -## Definition -Karpathy 提出的个人知识管理范式——让 LLM **增量构建和维护**一个持久化的 Wiki（互相链接的 Markdown 文件集合），而不是像 RAG 那样每次查询从零检索。 - -## Core Architecture -三层架构： -1. **Raw Sources**：原始文档（永远不修改） -2. **Wiki**：结构化摘要页面，互相链接 -3. **Schema**：[[LLM Wiki]] 的方法论沉淀 - -## Core Principles -- **知识编译一次，持续保持最新**：不是每次查询时从零推导，而是预先建立知识网络 -- **AI 承担"记账式"维护工作**：总结、交叉引用、归档、更新摘要 -- **人类只负责**：筛选资料、提出问题、思考意义 -- **维护成本趋近于零**：AI 不会厌倦，不会忘记，一次操作可以改十五个文件 -- **核心比喻**（[[llm-wiki]]）：**"Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库"** - -## Relationship to Second Brain -- 属 [[Second Brain]] 的架构理论层 -- [[养虾日记3]] 记录了将 LLM Wiki 理念落地到 [[Obsidian]] + [[OpenClaw]] 持久化笔记系统的全过程 - -## Origins -灵感源自 Vannevar Bush 的 **Memex**（1945）——一种设想中的"将所有书籍、记录和通信连接起来的设备"。 - -## Implementation Stack -- **[[Obsidian]]**：本地笔记工具，Wiki 载体 -- **[[Obsidian Web Clipper]]**：采集网页文章为 Markdown -- **[[Graph View]]**：图谱视图，做 Lint 健康检查和发现知识盲区 -- **[[Obsidian Git]]**：版本管理，自动 commit+push -- **[[qmd]]**：本地 Markdown 搜索引擎（规模大时使用） -- **[[Dataview]]**：frontmatter 数据库式查询（可选） -- **[[Marp]]**：Wiki 内容导出为幻灯片（可选） - -## Connections -- [[LLM Wiki]] ← 提出者 ← [[Karpathy]] -- [[LLM Wiki]] ← 工具基础 ← [[Obsidian]] -- [[LLM Wiki]] ← 对比/替代 → [[RAG]] -- [[LLM Wiki]] ← 上层概念 ← [[Second Brain]] diff --git a/wiki/concepts/LLM-as-a-Judge.md b/wiki/concepts/LLM-as-a-Judge.md deleted file mode 100644 index 08e63412..00000000 --- a/wiki/concepts/LLM-as-a-Judge.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "LLM-as-a-Judge" -type: concept -tags: [] -sources: [engineering-autonomous-optimization-architect] -last_updated: 2026-05-01 ---- - -# LLM-as-a-Judge - -## Definition - -LLM-as-a-Judge——以一个 LLM 作为自动化评估器，对另一个 LLM（或同一 LLM 的不同配置）的输出质量进行持续量化评分。 - -## Evaluation Framework - -在暗启动实验前必须建立明确的数学评分标准： - -| 维度 | 分数 | 说明 | -|------|------|------| -| JSON 格式正确性 | 5 分 | 输出是否结构化、可解析 | -| 延迟 | 3 分 | 响应时间是否在 SLA 内 | -| 准确性 | 5 分 | 内容是否符合要求 | -| 幻觉检测 | -10 分 | 是否出现事实性错误 | - -## Why It Matters - -- **可扩展**：无需人工标注，自动评估 1000+ 次实验 -- **一致性**：相同标准持续应用，避免人工评审的主观波动 -- **速度**：可异步并行执行，不阻塞生产流量 - -## Example Prompt - -``` -You are evaluating the output of Model B against Model A. -Score from 1-10 on: -1. Factual accuracy (5 points) -2. JSON structure validity (3 points) -3. Completeness (2 points) -Deduct 10 points if hallucination is detected. -``` - -## Related - -- [[Autonomous-Optimization-Architect]]：实施 LLM-as-a-Judge 的核心 Agent -- [[Shadow-Traffic]]：LLM-as-a-Judge 在影子测试中评估实验模型表现 diff --git a/wiki/concepts/LLMHandoff.md b/wiki/concepts/LLMHandoff.md deleted file mode 100644 index 76de2eb2..00000000 --- a/wiki/concepts/LLMHandoff.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "LLMHandoff" -type: concept -tags: ["llm", "agent", "handoff", "transcription", "summarization"] -last_updated: 2026-05-02 ---- - -# LLMHandoff（LLM 交接协议） - -## Definition - -LLM Handoff 是在 Agent 管道中，将结构化数据（转录文本、会议记录、文档）传递给下游 LLM 进行摘要/问答/行动项提取的标准接口。定义格式化规则和任务指令，使下游 LLM 能准确理解输入并产生期望输出。 - -## Purpose - -在 [[StructuredTranscriptJSON]] 基础上，LLM Handoff 定义： -1. **格式化规则**：如何将带时间戳的段落转为 LLM 可读的文本格式 -2. **任务指令**：不同任务（摘要/问答/行动项）对应的 prompt 指令 -3. **Schema 输出**：LLM 应返回的结构化格式（如 action_items、summary 等） - -## Handoff Payload Format - -```json -{ - "task": "summarize", - "source_type": "transcript", - "source_id": "meeting-2026-05-02-001", - "total_duration": 3600.5, - "speakers": ["SPEAKER_00", "SPEAKER_01"], - "content": "[0.0s] Hello, welcome...\n[5.2s] Thank you...\n...", - "instructions": { - "summarize": "Produce a concise summary, section headers for topic changes, and a bulleted action items list with speaker attribution.", - "action_items": "Extract all action items and commitments with the speaker who made them and the timestamp.", - "qa": "Answer questions about the transcript using only information present in the content. Cite timestamps." - } -} -``` - -## Downstream Integrations - -- [[LangChain]]：`ConversationalRetrievalChain` / `LLMChain` -- CrewAI：`Agent` 接收 JSON payload 作为 context -- 自定义 LLM 管道：直接读取 payload 并注入 system prompt - -## Critical Design Considerations - -- **保留时间戳锚点**：`[5.2s]` 格式使 LLM 能引用具体时刻 -- **说话人归属**：`[SPEAKER_00]` 前缀使 LLM 能区分不同发言人的观点 -- **分块交付**：超长转录可分批传递给 LLM（避免 token 超限） - -## Related Concepts -- [[StructuredTranscriptJSON]] — Handoff 的输入数据格式 -- [[PIIRedaction]] — Handoff 前必须脱敏（避免 LLM 学习 PII） -- [[SpeakerDiarization]] — 说话人标签是 Handoff 文本格式化的核心要素 -- [[Human-Handoff]] — LLM → 人类的交接（Agentic 系统中的另一方向） - -## Related Sources -- [[engineering-voice-ai-integration-engineer]] diff --git a/wiki/concepts/LLMWikiArchitecture.md b/wiki/concepts/LLMWikiArchitecture.md deleted file mode 100644 index 99e63508..00000000 --- a/wiki/concepts/LLMWikiArchitecture.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "LLMWikiArchitecture" -type: concept -tags: [architecture, knowledge-management, llm] -sources: [llm-wiki] -last_updated: 2026-05-02 ---- - -## Overview -LLM Wiki 架构是 [[PersistentWiki]] 的结构化实现，采用三层架构：Raw Sources → Wiki → Schema。 - -## Three Layers - -### Layer 1: Raw Sources（原始资源） -- 用户精心收集的源文档：文章、论文、图像、数据文件 -- **不可变**：LLM 读取但不修改，是唯一的真实来源（Source of Truth） -- 位于仓库的 `raw/` 目录 - -### Layer 2: Wiki（知识层） -- LLM 生成的 Markdown 文件目录 -- 包含：摘要页、实体页、概念页、综合分析、概览、索引 -- **LLM 完全拥有并维护**：创建页面、新来源到达时更新、维护交叉引用、保持一致性 -- 位于仓库的 `wiki/` 目录 - -### Layer 3: Schema（模式文件） -- 配置文件，告诉 LLM Wiki 的结构、约定和工作流 -- 例如：Claude Code 的 `CLAUDE.md`、Codex 的 `AGENTS.md` -- 是让 LLM 成为"规范的 Wiki 维护者"而非"普通聊天机器人"的关键 -- 用户和 LLM 共同随时间演进 - -## Design Philosophy -- **人读 LLM 写**：用户消费 Wiki 内容，LLM 负责编写和维护 -- **LLM 不厌倦**：LLM 不会忘记更新交叉引用，一次可以处理多个文件 -- **维护成本接近零**：正是 LLM 承担维护工作，使 Wiki 可以持续运行 diff --git a/wiki/concepts/LLMasJudge.md b/wiki/concepts/LLMasJudge.md deleted file mode 100644 index 336f5990..00000000 --- a/wiki/concepts/LLMasJudge.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "LLMasJudge" -type: concept -tags: ["evaluation", "llm-evaluation", "quality-assurance"] -sources: ["engineering-autonomous-optimization-architect"] -last_updated: 2026-04-26 ---- - -## Aliases -- LLM as a Judge -- LLM-as-Judge -- LLM-as-a-Judge Grading - -## Definition -LLM-as-a-Judge 是 [[AutonomousOptimizationArchitect]] 的评分机制——使用一个独立的 LLM（如 Claude Opus）作为"裁判"，对实验模型和生产模型的输出进行客观评分，避免人工评审的主观偏差。评分维度包括：JSON 格式正确性（5分）、延迟（3分）、幻觉检测（-10分）等。 - -## Mechanism -1. **评分标准预先建立**：在 [[ShadowTraffic]] 测试前，[[AutonomousOptimizationArchitect]] 明确建立数学评分标准 -2. **异步评估**：实验模型和生产模型同时处理任务，裁判 LLM 盲评两者输出 -3. **统计分析**：累积足够样本后进行统计显著性检验 -4. **自主决策**：实验模型显著优于基准时，更新路由权重 - -## Key Properties -- **客观性**：消除人工评分的主观偏差 -- **可扩展**：可同时评估多个 Provider 的输出 -- **数据驱动**：评分结果直接驱动 [[SemanticRouting]] 决策 - -## Connections -- [[AutonomousOptimizationArchitect]] — LLM-as-Judge 是核心评估工具 -- [[ShadowTraffic]] — 提供实验与基准并行执行的流量环境 -- [[SemanticRouting]] — 评分结果更新路由权重 diff --git a/wiki/concepts/LOD-Pipeline.md b/wiki/concepts/LOD-Pipeline.md deleted file mode 100644 index fd644ee6..00000000 --- a/wiki/concepts/LOD-Pipeline.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: "LOD Pipeline" -type: concept -tags: [game-dev, asset-pipeline, optimization, performance] -sources: [technical-artist] -last_updated: 2026-04-26 ---- - -# LOD Pipeline - -## Definition -LOD（Level of Detail，多细节层次）管线是自动管理 3D 模型在不同观看距离下显示精度的系统。当物体远离摄像机时，自动切换到更低多边形数的模型版本，从而节省渲染成本。 - -## Core Concept -LOD 是**强制流程**——每个英雄网格必须经过 LOD 管线处理，最低要求 LOD0 至 LOD3。 - -## LOD Budget Standard（from Technical Artist） - -### Characters（角色） -| LOD | 最大多边形数 | 纹理分辨率 | Draw Calls | -|-----|------------|-----------|-----------| -| LOD0 | 15,000 | 2048×2048 | 2–3 | -| LOD1 | 8,000 | 1024×1024 | 2 | -| LOD2 | 3,000 | 512×512 | 1 | -| LOD3 | 800 | 256×256 | 1 | - -### Environment — Hero Props（英雄道具） -| LOD | 最大多边形数 | 纹理分辨率 | -|-----|------------|-----------| -| LOD0 | 4,000 | 1024×1024 | -| LOD1 | 1,500 | 512×512 | -| LOD2 | 400 | 256×256 | - -### Small Props（小道具） -| LOD | 最大多边形数 | -|-----|------------| -| LOD0 | 500 | -| LOD1 | 200 | - -## LOD Validation Script - -```python -LOD_BUDGETS = { - "character": [15000, 8000, 3000, 800], - "hero_prop": [4000, 1500, 400], - "small_prop": [500, 200], -} - -def validate_lod_chain(asset_name: str, asset_type: str, lod_poly_counts: list[int]) -> list[str]: - errors = [] - budgets = LOD_BUDGETS.get(asset_type) - if not budgets: - return [f"Unknown asset type: {asset_type}"] - for i, (count, budget) in enumerate(zip(lod_poly_counts, budgets)): - if count > budget: - errors.append(f"{asset_name} LOD{i}: {count} tris exceeds budget of {budget}") - return errors -``` - -## Critical Rules - -1. **LOD0 强制**：不得交付任何未通过 LOD 管线的资产 -2. **切换距离验证**：飞行检查所有 LOD 级别的过渡距离，确保无明显 pop-in -3. **纹理一致性**：不同 LOD 级别应使用合理的纹理分辨率递减策略 -4. **导入自动化**：引擎导入预设应覆盖所有资产类别，避免艺术家手动配置 - -## Related Concepts -- [[Performance-Budget]]：LOD 是控制渲染性能的核心工具 -- [[AssetPipeline]]：LOD 是资产管线标准的关键组成部分 -- [[VFX]]：VFX 特效也有 LOD 概念（随距离简化粒子密度） - -## Connections -- [[TechnicalArtist]] ← enforces ← LOD Pipeline -- [[AssetPipeline]] ← includes ← LOD Pipeline -- [[Performance-Budget]] ← achieved by ← LOD Pipeline diff --git a/wiki/concepts/LOD.md b/wiki/concepts/LOD.md deleted file mode 100644 index 27e99375..00000000 --- a/wiki/concepts/LOD.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "LOD" -type: concept -tags: ["game-engine", "performance-optimization", "3d-graphics"] -sources: ["unreal-technical-artist", "unreal-world-builder"] -last_updated: 2026-04-26 ---- - -## Definition -Level of Detail（LOD），根据渲染对象与摄像机距离动态切换网格体精度（或着色复杂度）的机制。是 3D 游戏引擎性能优化的基础技术。 - -## LOD Strategy -- **Nanite 资产**：自动 LOD，无需手动配置 -- **非 Nanite 资产**（骨骼网格体、样条线、程序化网格体）：必须手动配置 LOD 链，并验证距离过渡 - -## Manual LOD Chain Requirements -- 每个资产必须定义 LOD0–LOD3 最低要求 -- 过渡距离必须在目标硬件上验证 -- 开放世界道具（无 Nanite）超过 500 三角形须有文档化例外 - -## Cull Distance -LOD 之外还需要 Cull Distance Volumes 配置远距离剔除： -- 按资产类别设置，非全局统一 -- 所有开放世界关卡必须配置 - -## HLOD（Hierarchical LOD） -- World Partition 开放世界的必备配置 -- 将多个小对象合并为大型远距离代理 -- 必须为所有室外区域生成 HLOD - -## Relationship to Nanite -Nanite 本质上是自动 LOD 系统，适用于静态几何体。LOD 链是手动 LOD 系统，用于 Nanite 无法处理的资产类型。 - -## Related -- [[Nanite]] — 自动 LOD 系统 -- [[PerformanceBudget]] — LOD 是帧预算控制的核心工具 -- [[WorldPartition]] — HLOD 的配合框架 diff --git a/wiki/concepts/LSIF.md b/wiki/concepts/LSIF.md deleted file mode 100644 index e7143cb5..00000000 --- a/wiki/concepts/LSIF.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "LSIF" -type: concept -tags: ["LSP", "code-index", "semantic-index", "static-analysis", "pre-computed"] -sources: ["lsp-index-engineer.md"] -last_updated: 2026-04-29 ---- - -## Definition -LSIF（Language Server Index Format）是一种标准化的预计算语义索引格式，用于存储语言服务器已分析过的代码语义数据（如符号定义、引用、继承关系等），使代码智能工具无需实时运行 LSP 服务器即可提供导航功能。 - -## Core Mechanism - -### 用途 -- **离线索引**：项目提前构建 LSIF 索引，CI/CD 阶段预先生成 -- **冷启动加速**：无需等待 LSP 服务器初始化，立即提供代码导航 -- **分发预索引数据**：发布 npm 包时附带已编译的 LSIF 索引 -- **跨工具共享**：同一索引可为多个工具（IDE/CLI/API）共用 - -### 索引内容 -- 符号定义位置 -- 符号引用关系 -- 文档结构（文件树/大纲） -- Hover 文档内容 -- 类型层次信息 - -### 与 nav.index.jsonl 的关系 -LSIF 是 nav.index.jsonl 格式的导入/导出标准。graphd 支持： -- **导出**：将内存中的语义图谱导出为 LSIF 格式 -- **导入**：将预先构建的 LSIF 索引加载到内存，加速启动 - -## Implementation Notes -LSP/Index Engineer 将 LSIF 视为 nav.index.jsonl 格式的上游标准，通过 LSIF 实现预计算语义数据的导入/导出。 - -## Connections -- [[LSIF]] ← is_standard_for ← [[SemanticCodeGraph]] -- [[LSIF]] ← can_be_imported_by ← [[GraphDaemon]] -- [[LSIF]] ← is_alternative_to ← [[IncrementalGraphUpdate]] -- [[LSIF]] ← exports ← [[nav.index.jsonl]] diff --git a/wiki/concepts/LSP-317-Specification.md b/wiki/concepts/LSP-317-Specification.md deleted file mode 100644 index 2b4ec3cf..00000000 --- a/wiki/concepts/LSP-317-Specification.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "LSP 3.17 Specification" -type: concept -tags: [protocol, language-server, standardization] -sources: [lsp-index-engineer] -last_updated: 2026-04-25 ---- - -## Definition - -Language Server Protocol 3.17（LSP 3.17）是 Microsoft 发起的语言服务器协议的最新版本，定义了编辑器/IDE 与语言服务器之间的标准化 JSON-RPC 通信规范，使得不同语言可以有统一的方式提供代码智能功能（跳转到定义、查找引用、悬停文档等）。 - -## Core Components - -- **JSON-RPC 2.0**：基于 JSON 的远程过程调用协议 -- **Server Capabilities**：服务器声明其支持的功能（如 definitionProvider、referencesProvider） -- **Client Capabilities**：客户端声明其支持的功能 -- **Lifecycle**：initialize → initialized → shutdown → exit -- **textDocument/* 请求**：textDocument/definition、textDocument/references、textDocument/hover 等 - -## Why LSP 3.17 - -LSP/Index Engineer 严格遵循 LSP 3.17 规范进行所有客户端通信，正确处理每个语言服务器的能力协商。LSP 3.17 相比早期版本增加了： -- 增量同步（Incremental同步） -- Call Hierarchy 和 Type Hierarchy -- 更完整的诊断能力 -- 更好的多根工作区支持 - -## Implementation Note - -LSP/Index Engineer 的核心约束：**永远不要假设能力，必须始终检查服务器能力响应**。这确保了 graphd 能与任何符合 LSP 规范的服务器协作。 - -## Aliases -- LSP -- Language Server Protocol -- LSP 3.17 diff --git a/wiki/concepts/LSPOrchestrator.md b/wiki/concepts/LSPOrchestrator.md deleted file mode 100644 index 2bb20f6b..00000000 --- a/wiki/concepts/LSPOrchestrator.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: "LSPOrchestrator" -type: concept -tags: ["LSP", "code-intelligence", "orchestration", "multi-language"] -sources: ["lsp-index-engineer.md"] -last_updated: 2026-04-29 ---- - -## Definition -LSP 编排器（LSP Orchestrator）是在 graphd 架构中协调多个语言服务器并发运行的中间层，负责统一管理不同语言的 LSP 客户端、正确处理各服务器的能力协商、并将对异构 LSP 响应格式标准化为统一格式。 - -## Core Mechanism - -### Client Initialization -```typescript -class LSPOrchestrator { - async initialize(projectRoot: string) { - const tsClient = new LanguageClient('typescript', { - command: 'typescript-language-server', - args: ['--stdio'], - rootPath: projectRoot - }); - const phpClient = new LanguageClient('php', { - command: 'intelephense', - args: ['--stdio'], - rootPath: projectRoot - }); - await Promise.all([ - this.initializeClient('typescript', tsClient), - this.initializeClient('php', phpClient) - ]); - } -} -``` - -### Multi-Language Coordination -- **并行初始化**：所有语言服务器并发启动 -- **能力协商**：为每个服务器独立检查 `ServerCapabilities` -- **语言检测**：根据文件扩展名路由到对应语言服务器 -- **请求批处理**：合并相邻请求以减少往返开销 -- **缓存策略**：积极缓存但精确失效 - -### Capability-Negotiation Pattern -```typescript -async getDefinition(uri: string, position: Position): Promise { - const lang = this.detectLanguage(uri); - const client = this.clients.get(lang); - if (!client || !this.capabilities.get(lang)?.definitionProvider) { - return []; - } - return client.sendRequest('textDocument/definition', { - textDocument: { uri }, - position - }); -} -``` - -## Performance Optimization -- **请求批处理**：合并多个相邻 LSP 请求 -- **零拷贝技术**：内存映射文件和大数据集 -- **Worker Threads**：CPU 密集型操作分流到 Worker -- **锁无关数据结构**：并发访问无锁化 - -## Connections -- [[LSPOrchestrator]] ← part_of ← [[GraphDaemon]] -- [[LSPOrchestrator]] ← coordinates ← [[LanguageServerProtocol]] -- [[LSPOrchestrator]] ← feeds ← [[SemanticCodeGraph]] -- [[LSPOrchestrator]] ← uses ← [[IncrementalGraphUpdate]] diff --git a/wiki/concepts/LaTeX-Flattening.md b/wiki/concepts/LaTeX-Flattening.md deleted file mode 100644 index c236e340..00000000 --- a/wiki/concepts/LaTeX-Flattening.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "LaTeX Flattening" -type: concept -tags: [] -sources: [arxiv-paper-reader] -last_updated: 2026-04-17 ---- - -## Concept Definition -**LaTeX 扁平化（LaTeX Flattening）** 是指将多文件 LaTeX 论文项目（含 `\include{}`、 `\input{}`、子文件等）自动合成为单一连续文本的技术过程，使 AI 模型能够完整理解论文结构而无需处理文件引用和相对路径。 - -## How It Works -arXiv 论文通常包含多个 `.tex` 文件（主文件引用 `sections/` 目录下的子文件）。扁平化过程： -1. 下载 arXiv LaTeX 源码压缩包（`.tar.gz`） -2. 解析主文件，找到所有 `\include{}` / `\input{}` 引用 -3. 按引用顺序将子文件内容拼接注入主文件 -4. 清理 `\bibliography{}`、图片引用等外部依赖标记 -5. 输出单一完整文本流 - -## Use Cases -- [[arXiv-Paper-Reader]] 的核心处理步骤——将 arXiv LaTeX 源码转换为 AI 可读的纯净文本 -- 任何需要将 LaTeX 文档喂入 LLM 的场景 - -## Related Concepts -- [[arXiv-API]]：LaTeX 源码的下载来源 -- [[本地缓存]]：扁平化结果可缓存避免重复处理 diff --git a/wiki/concepts/LaTeX.md b/wiki/concepts/LaTeX.md deleted file mode 100644 index 0abe70b9..00000000 --- a/wiki/concepts/LaTeX.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "LaTeX" -type: concept -tags: [] -sources: [latex-paper-writing] -last_updated: 2026-04-22 ---- - -## Aliases -- LaTeX2ε -- TeX/LaTeX - -## Definition -LaTeX 是一种基于 TeX 的排版系统，广泛用于学术论文、技术文档和演示文稿的高质量排版。通过 [[Prismer]] 容器，AI Agent 可以无需本地安装 TeX Live 即可完成 LaTeX 写作和即时 PDF 编译。 - -## Core Properties -- 支持 pdflatex、xelatex、lualatex 三种编译引擎 -- xelatex 原生支持中文/CJK 字体 -- 支持 BibTeX/BibLaTeX 参考文献管理 -- 提供多种模板：article、IEEE、beamer、中文论文 - -## Connections -- [[LaTeX Paper Writing]] ← enables AI-assisted ← [[LaTeX]] -- [[Prismer-AI]] ← provides runtime for ← [[LaTeX]] diff --git a/wiki/concepts/LagCompensation.md b/wiki/concepts/LagCompensation.md deleted file mode 100644 index 8c8c09d2..00000000 --- a/wiki/concepts/LagCompensation.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Lag Compensation" -type: concept -tags: [networking, multiplayer, latency] -sources: [unity-multiplayer-engineer] -last_updated: 2026-04-26 ---- - -## Aliases -- Server-Side Lag Compensation -- 延迟补偿 - -## Definition -延迟补偿是一种在服务器权威模型下**考虑网络延迟影响**的技术。当服务器处理客户端的射击/命中请求时，需要将客户端的请求时间「回溯」到网络延迟对应的时间点，以提供公平的命中判定。 - -## Problem It Solves -在没有延迟补偿的情况下： -- 客户端 A 看到命中了客户端 B -- 但由于网络延迟，B 已经移动到了新位置 -- 结果：A 的命中被服务器拒绝，但 A 看到的是命中效果 → 体验不一致 - -## Standard Approach -1. 客户端发送带有**时间戳**的输入/射击请求 -2. 服务器根据网络延迟计算**回溯时间** -3. 服务器将目标玩家「回放」到回溯时间点的位置 -4. 在该位置进行命中判定 -5. 结果同步给所有客户端 - -## Related Concepts -- [[ServerAuthority]]: 延迟补偿依赖服务器权威 -- [[ClientPrediction]]: 两者结合提供流畅且公平的游戏体验 -- [[AntiCheatArchitecture]]: 延迟补偿同时是反作弊的重要手段 - -## Related Entities -- [[UnityMultiplayerEngineer]]: 实现延迟补偿的专家 -- [[UnrealMultiplayerArchitect]]: 虚幻引擎中的对应实现 diff --git a/wiki/concepts/LambdaSafetyGate.md b/wiki/concepts/LambdaSafetyGate.md deleted file mode 100644 index 5d3a707a..00000000 --- a/wiki/concepts/LambdaSafetyGate.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Lambda Safety Gate" -type: concept -tags: [] -last_updated: 2026-05-01 ---- - -## Definition - -在执行 SLM 生成的 Python lambda 转换函数前，对其进行严格安全验证的防御机制。防止恶意代码、文件系统操作或任意代码执行通过 AI 修复管道注入系统。 - -## Validation Rules - -```python -def validate_lambda(lambda_str: str) -> bool: - forbidden = ['import', 'exec', 'eval', 'os.', 'subprocess', '__'] - if not lambda_str.startswith('lambda'): - raise ValueError("Rejected: output must be a lambda function") - if any(term in lambda_str for term in forbidden): - raise ValueError("Rejected: forbidden term in lambda") - return True -``` - -## Validation Checklist - -| Check | Rule | On Failure | -|-------|------|------------| -| Prefix | 必须以 `lambda` 开头 | 拒绝，路由至人工隔离 | -| Keywords | 禁止 `import/exec/eval/os/subprocess/__` | 拒绝，路由至人工隔离 | -| Confidence | 置信度必须 ≥ 0.75 | 拒绝，路由至人工隔离 | - -## Rationale - -AI 生成的文本可能包含任意代码。Lambda Safety Gate 确保即使 SLM 被注入恶意提示词，修复管道也仅执行无害的数据转换函数。 - -## Related - -- [[Air-Gapped SLM Fix Generation]] -- [[Zero Data Loss Guarantee]] -- [[AI Generates Logic Not Data]] diff --git a/wiki/concepts/Land-and-Expand.md b/wiki/concepts/Land-and-Expand.md deleted file mode 100644 index 05581b9b..00000000 --- a/wiki/concepts/Land-and-Expand.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Land-and-Expand" -type: concept -tags: [] -sources: [sales-account-strategist, sales-outbound-strategist] -last_updated: 2026-04-25 ---- - -## Definition - -Land-and-Expand 是一种 SaaS/企业软件公司的核心增长策略，指在赢得初始合同（land deal）后，通过系统性方法将单点解决方案逐步扩展为企业级平台关系，最大化每个客户账户的收入潜力。 - -## Core Principles - -### The Land Phase -- 以低风险切入点进入客户组织——通常是一个部门、一个用例或一个产品模块 -- 目标是建立可衡量的成功证据（ROI 数据、用户数、效率提升） -- 目标是培养至少一个内部冠军（champion）来推动内部推广 - -### The Expand Phase -- 基于已验证的成功，向相邻用例、额外用户、新产品模块扩展 -- 时机信号：容量使用率 >80%、特征采纳速度加快、部门级使用不对称 -- 永远在客户成功之后才推扩张——在尚未成功的账户上销售更多会加速流失 - -## Key Metrics - -| Metric | Description | Target | -|--------|-------------|--------| -| NRR (Net Revenue Retention) | 扩张收入 - 流失收入 - 收缩收入 | >100%，优秀 >120% | -| Expansion Ratio | 扩张收入 / 总 ARR | >1.2x | -| Time to Expand | 首次成交到首次扩张的时间 | <12 个月 | -| Land Deal Size | 初始合同规模 | 因细分市场而异 | - -## Signals for Expansion - -每个扩张信号必须同时具备三个维度： -1. **信号（Signal）**：使用率上升、用户增长、特征采纳 -2. **情境（Context）**：为什么发生？业务背景是什么？ -3. **时机（Timing）**：为什么是现在？客户即将做出什么决策？ -4. **利益相关者对齐（Stakeholder Alignment）**：谁关心这个机会？ - -**没有同时满足四个维度的，只能算"观察"，不是"机会"。** - -## Connection -- [[Net Revenue Retention (NRR)]] — Land-and-Expand 的终极目标是最大化 NRR -- [[Account Strategist Agent]] — 执行 Land-and-Expand 的核心角色 -- [[sales-account-strategist]] -- [[Churn Prevention Playbook]] — Land-and-Expand 的对立面是流失，两者都需要积极管理 diff --git a/wiki/concepts/Landing-Zone-Architecture.md b/wiki/concepts/Landing-Zone-Architecture.md deleted file mode 100644 index 017dab0c..00000000 --- a/wiki/concepts/Landing-Zone-Architecture.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Landing Zone Architecture" -type: concept -sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-35-aws-landing-zone-design-refresher-saas-labs] -last_updated: 2026-04-14 ---- - -## Definition -Landing Zone（落地区）是基于 Gruntwork 仓库的 AWS 多账户基础设施部署单元。每个 Landing Zone 对应一个独立的 AWS 环境（如 R&D Labs、SAS/Staging/Production），由产品团队在 Gruntwork 参考架构基础上自行定义具体服务（如 ECS 集群、RDS 数据库），并通过独立的 GitHub 仓库管理 IaC 代码。 - -## Key Characteristics - -### 与 Reference Architecture 的区别 -- **Reference Architecture**：标准化的最佳实践起点和蓝图 -- **Landing Zone**：基于 Reference Architecture 的具体部署实现，由产品团队定制 -- **关键区别**：Landing Zone 不包含 ECS 集群或 RDS 数据库等具体服务，而是由各产品团队自行填充 - -### 部署结构 -- 每个 Landing Zone 拥有独立的 GitHub 仓库管理 Terraform/IaC 代码 -- 每个 Landing Zone 配置独立的 Jenkins 服务器用于部署基础设施变更 -- 每个产品团队维护自己的 Jenkins 任务来部署其负责的基础设施 - -### 身份管理 -- 安全账户使用**联邦用户（Federated User）** -- 通过 AD（Active Directory）组映射到 IAM 角色 -- 替代传统的 IAM 用户管理方式 - -## Deployment Workflow -1. Gruntwork 提供参考架构和 Terraform 模块库 -2. 产品团队基于 Gruntwork 仓库创建自己的 Landing Zone -3. 使用特性分支开发，通过 Pull Request 合并到主分支 -4. Jenkins CI/CD 流水线自动化执行 Terraform Plan/Apply -5. TerraTest 用于基础设施变更的自动化测试 - -## Related Concepts -- [[Reference-Architecture]]：Landing Zone 的设计蓝图 -- [[Federated-Access]]：Landing Zone 安全账户的身份管理机制 -- [[CI-CD-Pipeline]]：Landing Zone 的自动化部署流水线 -- [[Terraform-Modules]]：Gruntwork 提供的 IaC 模块库 - -## References -- [[ctp-topic-1-gruntwork-landing-zone-architecture]] -- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] -- [[ctp-topic-9-ci-cd-with-gruntwork]] diff --git a/wiki/concepts/Landscape.md b/wiki/concepts/Landscape.md deleted file mode 100644 index 2546bce8..00000000 --- a/wiki/concepts/Landscape.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Landscape" -type: concept -tags: ["unreal-engine", "terrain", "environment", "material"] -sources: ["unreal-world-builder"] -last_updated: 2026-04-30 ---- - -## Aliases -- UE5 Landscape -- Terrain System -- 地形系统 -- Landscape System - -## Definition -Landscape 是 Unreal Engine 5 的地形系统，支持超大尺寸地形的编辑、渲染和运行时修改。它使用分块（Components）架构，支持多层材质混合，并通过 Runtime Virtual Texturing（RVT）优化多层混合性能。 - -## Resolution Rule -Landscape 分辨率必须满足公式：**分辨率 = (n × ComponentSize) + 1**，必须使用 Landscape Import Calculator 确定，禁止猜测。 - -## Layer Constraints -- **单区域最多 4 个活跃材质层**：超过则导致材质排列组合爆炸（Material Permutation Explosion） -- **超过 2 层材质必须启用 RVT**：消除逐像素层混合开销 -- **景观空洞**：必须使用 Visibility Layer，禁止删除组件（删除会破坏 LOD 和水体系统集成） - -## Master Material Architecture -典型 4 层 Landscape Master Material： -- **Layer 0**：Grass（基底层，始终存在） -- **Layer 1**：Dirt/Path（沿磨损路径替换草地） -- **Layer 2**：Rock（坡度驱动，> 35° 自动混合） -- **Layer 3**：Snow（高度驱动，> 800m 显现） - -## Blending Mechanisms -- **Auto-Slope Rock Blend**：WorldAlignedBlend，坡度阈值 = 0.6（dot(worldUp, surfaceNormal)） -- **Auto-Height Snow Blend**：Absolute World Position Z > SnowLine 参数时雪层淡入 -- **RVT 分辨率**：每 4096m² 格子 2048×2048，格式 YCoCg 压缩 - -## RVT Integration -- 启用 Runtime Virtual Texturing 的 Landscape Material -- Virtual Texture Producer 需在 Landscape 上启用 -- RVT Output Volume 每 4096m² 格子对齐放置 -- RVT 可采样游戏标签或 Decal Actor 驱动动态地形状态（如雨后湿润度） - -## Landscape Splines -用于道路和河流雕刻：样条线变形的网格自动贴合地形拓扑。 - -## Connections -- [[UnrealWorldBuilder]] ← 地形基础 ← Landscape -- [[UnrealEngine5]] ← 核心引擎 ← Landscape -- [[RuntimeVirtualTexturing]] ← 层混合优化 ← Landscape -- [[WorldPartition]] ← 空间管理 ← Landscape - -## Sources -- [[unreal-world-builder]] diff --git a/wiki/concepts/LangChain.md b/wiki/concepts/LangChain.md deleted file mode 100644 index 3555a0d6..00000000 --- a/wiki/concepts/LangChain.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "LangChain" -type: concept -tags: [llm, framework, agent, development] -sources: [大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏] -last_updated: 2026-04-25 ---- - -# LangChain - -## Definition - -LangChain 是一个快速实现 AI Agent 的开发框架，提供了标准接口，用于： -- 将不同的 LLM 连接在一起 -- 与其他工具和数据源的集成 - -LangChain 降低了构建基于 LLM 的应用程序的开发门槛，提供了链式调用（Chain）、代理（Agent）、记忆（Memory）等抽象，使开发者能够快速组装复杂的 LLM 应用。 - -## Relationship to MCP - -LangChain 和 [[Model Context Protocol]] 都试图解决"LLM 与外部工具集成"的问题，但层次不同： - -- **[[Model Context Protocol]]** 是一个开放协议标准（协议层） -- **LangChain** 是一个应用开发框架（框架层） - -LangChain 可视为 MCP 思想的具体实现之一——在 MCP 出现之前，LangChain 已是 Agent 开发的事实标准。 - -## Related Concepts - -- [[AI Agent]]：LangChain 的核心目标产物 -- [[Prompt]]：LangChain 中 Chain 的基本输入形式 -- [[Model Context Protocol]]：协议层的互补方案 -- [[RAG]]：LangChain 的重要应用场景之一 - -## Sources - -- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]] diff --git a/wiki/concepts/Language-Detection.md b/wiki/concepts/Language-Detection.md deleted file mode 100644 index aba15b31..00000000 --- a/wiki/concepts/Language-Detection.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Language Detection" -type: concept -tags: [] -sources: [] ---- - -# Language Detection - -## Definition - -AI 自动检测客户消息使用的语言，并在回复时匹配该语言的能力，是多语言客服场景的基础技术。 - -## Why It Matters - -小型本地服务企业（餐厅、诊所、发廊）的客户群体通常包含： -- 本地语言用户（ES/EN） -- 外语用户（旅游客户、跨境客户） -- 混合语言消息 - -自动语言检测确保 AI 用客户的语言回复，提升客户体验和响应准确率。 - -## Implementation - -Language Detection 通常在 Intent Classification 之前执行： - -``` -Customer Message → [Language Detection] → Identify: EN/ES/UA - ↓ - [Intent Classification] → ... - ↓ - [Generate Response in Detected Language] -``` - -## Response Style Guidelines - -| Detected Language | Response Style | -|-------------------|----------------| -| EN (English) | Friendly, professional, concise | -| ES (Español) | Amigable, profesional, conciso | -| UA (Українська) | Привітний, професійний, стислий | - -## Related Concepts - -- [[Intent-Classification]]：语言检测在意图分类之前执行 -- [[AI-Auto-Response]]：回复语言跟随检测结果 -- [[Multi-Channel-Integration]]：多渠道场景下语言检测尤为重要 - -## Sources - -- [[multi-channel-customer-service]] diff --git a/wiki/concepts/LanguageServerProtocol.md b/wiki/concepts/LanguageServerProtocol.md deleted file mode 100644 index 52f06c3b..00000000 --- a/wiki/concepts/LanguageServerProtocol.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "LanguageServerProtocol" -type: concept -tags: ["LSP", "code-intelligence", "language-server", "IDE", "editor"] -sources: ["lsp-index-engineer.md"] -last_updated: 2026-04-29 ---- - -## Definition -Language Server Protocol（LSP）是 Microsoft 在 2016 年首创的标准化协议，定义了**语言服务器**（Language Server）与**语言客户端**（Editor/IDE）之间的通信规范，使编程语言工具能够在任何编辑器中提供一致的代码智能功能（跳转定义、查找引用、悬停文档、自动完成等），无需为每个编辑器-语言组合单独实现。 - -## Core Mechanism - -### Protocol Architecture -- **Language Server**：独立进程，负责语言特定的代码分析（解析、类型检查、语义分析） -- **Language Client**：编辑器/IDE 端，负责用户交互和结果展示 -- **Communication**：通过 JSON-RPC（2.0）在 stdin/stdout 之间传输消息 - -### LSP 3.17 关键能力 -- **textDocument/didOpen** — 文档打开通知 -- **textDocument/definition** — 跳转到定义 -- **textDocument/references** — 查找引用 -- **textDocument/hover** — 悬停文档 -- **textDocument/completion** — 自动完成 -- **textDocument/publishDiagnostics** — 诊断信息发布 -- **workspace/symbol** — 工作区符号搜索 - -### Capability Negotiation -客户端在 `initialize` 请求中声明自身能力： -```json -{ - "capabilities": { - "textDocumentSync": 1, - "definitionProvider": true, - "referencesProvider": true, - "hoverProvider": true - } -} -``` -服务器在响应中声明支持的能力。**LSP/Index Engineer 强制要求永远检查服务器能力响应，而非假设支持某功能。** - -### Lifecycle -`initialize` → `initialized` → （正常运行）→ `shutdown` → `exit` - -## Multi-Language Orchestration -LSP 的核心价值在于使多语言支持标准化。LSP/Index Engineer 的 graphd 通过协调多个语言服务器（TypeScript、PHP、Go、Rust、Python），将各自 LSP 响应统一转换为语义图谱，实现跨语言的代码导航。 - -## Connections -- [[LanguageServerProtocol]] ← enables ← [[LSPOrchestrator]] -- [[LanguageServerProtocol]] ← powers ← [[SemanticCodeGraph]] -- [[LSPOrchestrator]] ← coordinates ← [[TypeScriptLanguageServer]] -- [[LSPOrchestrator]] ← coordinates ← [[Intelephense]] -- [[LanguageServerProtocol]] ← uses ← [[LSIF]] diff --git a/wiki/concepts/Large-Language-Model.md b/wiki/concepts/Large-Language-Model.md deleted file mode 100644 index d7add282..00000000 --- a/wiki/concepts/Large-Language-Model.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Large Language Model" -type: concept -tags: [llm, nlp, deep-learning] -aliases: [LLM, 大语言模型, Large Language Model] -last_updated: 2025-12-20 ---- - -## Definition -Large Language Model，大语言模型。行业通常以参数规模和训练数据/算力来衡量是否称为"大模型"，语言模型常在 ≥1B 参数开始被称为"大模型"。 - -## Key Facts -- 1B = Billion = 10亿参数 -- 常见大模型示例：GPT-2（1.5B）、GPT-3（175B）、GPT-4（参数量未公开） -- 参数规模是衡量模型能力的重要指标之一 - -## Connections -- [[Agent]] ← 构建于 ← [[Large Language Model]] -- [[Prompt]] ← 输入给 ← [[Large Language Model]] -- [[Model Context Protocol]] ← 连接 ← [[Large Language Model]] -- [[RAG]] ← 增强 ← [[Large Language Model]] -- [[vLLM]] ← 加速推理 ← [[Large Language Model]] -- [[Hallucination]] ← 问题 ← [[Large Language Model]] -- [[Data Distillation]] ← 蒸馏对象 ← [[Large Language Model]] - -## Sources -- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]] diff --git a/wiki/concepts/LargeWorldCoordinates.md b/wiki/concepts/LargeWorldCoordinates.md deleted file mode 100644 index 6d0c1cc6..00000000 --- a/wiki/concepts/LargeWorldCoordinates.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "LargeWorldCoordinates" -type: concept -tags: ["unreal-engine", "coordinates", "precision", "open-world"] -sources: ["unreal-world-builder"] -last_updated: 2026-04-30 ---- - -## Aliases -- LWC -- Large World Coordinates -- 大世界坐标 -- 双精度坐标 - -## Definition -Large World Coordinates（LWC）是 Unreal Engine 5 引入的双精度（double）坐标系统，用于解决超大世界（任何轴超过 2km）中的浮点精度问题。无 LWC 时，约 20km 处开始出现可见的浮点精度错误。 - -## Precision Problem -IEEE 754 单精度浮点数（float）在以下场景产生精度损失： -- **大数值**：坐标值越大，相邻值之间的 gap 越大 -- **远距离相加**：大坐标值与小数值的加法丢失精度 -- **累积误差**：多次变换后误差累积 - -## LWC Enabling Threshold -- **强制启用**：世界任何轴超过 2km -- **精度损失临界点**：~20km（无 LWC 时可见） -- **最大安全范围**：建议 100km 以内（即使启用 LWC） - -## Code Changes Required -| 位置 | float → double 替代 | -|------|-------------------| -| 游戏性代码（位置计算） | `FVector` → `FVector3d` | -| 着色器/材质 | 直接世界位置采样 → `LWCToFloat()` 转换 | -| 网络复制 | 仍用单精度（本地双精度，复制时转换） | - -## LWC Compliance Audit -迁移到 LWC 时必须审查： -- [ ] 所有着色器和材质使用 `LWCToFloat()` 而非直接世界位置采样 -- [ ] 游戏中所有位置计算使用 `FVector3d` -- [ ] 在 100km 以外spawn玩家并验证无视觉/物理瑕疵 - -## Connections -- [[UnrealWorldBuilder]] ← 坐标系统 ← LargeWorldCoordinates -- [[UnrealEngine5]] ← 核心引擎 ← LargeWorldCoordinates -- [[WorldPartition]] ← 空间管理 ← LargeWorldCoordinates - -## Sources -- [[unreal-world-builder]] diff --git a/wiki/concepts/Last-30-Days-Method.md b/wiki/concepts/Last-30-Days-Method.md deleted file mode 100644 index c3bb5ad9..00000000 --- a/wiki/concepts/Last-30-Days-Method.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Last 30 Days Method" -type: concept -tags: [market-research, social-media-mining, agentic-ai] -sources: [market-research-product-factory, last30days-使用指南] -last_updated: 2026-04-22 ---- - -## Definition - -Last 30 Days Method（近30天法）是一种聚焦近期用户讨论以获取时效性洞察的市场研究方法论——通过限定时间窗口过滤噪音，专注于用户在此时此刻正在经历的问题和需求，避免被历史积累的过时信息干扰。 - -## Core Mechanism - -1. **时间窗口锁定**：只采集最近30天内的帖子/推文/评论 -2. **数据源覆盖**：Reddit（社区讨论）和 X/Twitter（实时热点）双平台 -3. **聚类与排名**：将相似问题归类，按出现频率排序，识别TOP痛点 -4. **原始引用保留**：保留用户原始表述，而非经过转述的二手信息 - -## Why 30 Days - -- **信息时效性**：30天足够收集足够样本量，又不至于被过时内容淹没 -- **市场敏感度**：技术领域变化快，过时的讨论可能反映已解决的旧问题 -- **信号/噪音比**：对比全量历史，30天内的讨论代表用户当前最关心的事 - -## Relationship to Other Concepts - -- **[[Last 30 Days Method]]** → 工具方法 → **[[Agent-Driven Market Research]]** -- **[[Last 30 Days Method]]** → 工具方法 → **[[Pain Point Mining]]** -- **[[Last 30 Days Method]]** → 数据供给 → **[[Startup MVP Pipeline]]** -- **[[Last 30 Days Skill]]** → 软件实现 → **[[Last 30 Days Method]]** - -## Implementation - -在 OpenClaw 生态中，通过 `Last 30 Days Skill` 实现： -```text -Please use the Last 30 Days skill to research challenges people are having with [your topic]. -``` - -## Sources - -- [[market-research-product-factory]] -- [[last30days-使用指南]] diff --git a/wiki/concepts/Layered-Configuration.md b/wiki/concepts/Layered-Configuration.md deleted file mode 100644 index 70961df3..00000000 --- a/wiki/concepts/Layered-Configuration.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Layered Configuration" -type: concept -last_updated: 2026-04-10 ---- - -## Definition -Layered Configuration（分层配置）指系统配置存在多个层级，不同层级的配置有不同的优先级和作用范围。修改某一层级的配置无法影响其他层级的行为。 - -## OpenClaw 配置层级 -1. **Global Config** (`openclaw.json`): 全局 compaction 配置，影响所有 Agent -2. **Agent/Channel Specific Config**: 针对特定 Telegram Channel 或 Agent 的模型映射规则 -3. **环境变量**: 启动脚本里的 `MODEL_DEFAULT` 可能覆盖配置文件 - -## Debugging Implication -> **两层配置要分清：全局 compaction 配置和 agent 模型配置是两码事。改全局不行，就得往 agent 级别去找。** - -当问题在全局层面无法解决时，需要检查 Agent 级别的路由规则和模型绑定配置。 - -## Related -- [[Agent-Routing-Rules]]: Agent 级别配置的具体形式 -- [[Compaction]]: 全局 compaction 配置的作用范围 -- [[Error-Surface-vs-Root-Cause]]: 分层配置是"错误表象 ≠ 根本原因"的常见原因 - -## Sources -- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]] diff --git a/wiki/concepts/Layout-Framework.md b/wiki/concepts/Layout-Framework.md deleted file mode 100644 index fce82a7f..00000000 --- a/wiki/concepts/Layout-Framework.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Layout Framework" -type: concept -tags: [css, layout, responsive, grid, flexbox] -sources: [design-ux-architect.md] -last_updated: 2026-04-24 ---- - -## Definition - -Layout Framework 是基于 CSS Grid 和 Flexbox 的响应式布局系统，定义容器、网格、间距和断点规范，为开发者提供可信赖的实现基础。 - -## Container System - -- **Mobile**：全宽，16px padding -- **Tablet**：768px max-width，居中 -- **Desktop**：1024px max-width，居中 -- **Large**：1280px max-width，居中 - -```css -.container { - width: 100%; - max-width: var(--container-lg); - margin: 0 auto; - padding: 0 var(--space-4); -} -``` - -## Grid Patterns - -```css -.grid-2-col { - display: grid; - grid-template-columns: 1fr 1fr; - gap: var(--space-8); -} - -@media (max-width: 768px) { - .grid-2-col { - grid-template-columns: 1fr; - gap: var(--space-6); - } -} -``` - -## Component Hierarchy - -1. **Layout Components**：containers, grids, sections -2. **Content Components**：cards, articles, media -3. **Interactive Components**：buttons, forms, navigation -4. **Utility Components**：spacing, typography, colors - -## Related Concepts - -- [[CSS-Design-System]]：提供设计 Token 支撑布局系统 -- [[Responsive-Breakpoints]]：移动优先断点策略 -- [[Component-Architecture]]：组件命名和层级结构 - -## Sources - -- [[design-ux-architect]] — Layout Framework 的完整定义和示例代码 diff --git a/wiki/concepts/Lead-Generation-Funnel.md b/wiki/concepts/Lead-Generation-Funnel.md deleted file mode 100644 index 6d64b6b7..00000000 --- a/wiki/concepts/Lead-Generation-Funnel.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "Lead Generation Funnel（线索生成漏斗）" -type: concept -tags: [marketing, conversion, crm, b2b] -sources: [marketing-zhihu-strategist] -last_updated: 2026-04-21 ---- - -## Definition -线索生成漏斗（Lead Generation Funnel）——从品牌认知到精准业务线索的系统化转化路径。核心问题不是"如何获取更多线索"，而是"如何高效识别和培育真正有价值的潜在客户"。 - -## Lead Generation Funnel on Zhihu -知乎线索漏斗将知识参与读者转化为精准业务机会： - -``` -知乎曝光 - ↓（内容被搜索/推荐触达） -深度参与（点赞/收藏/评论/关注专栏） - ↓（专业信誉建立） -网站/资源访问（专栏底部链接/回答内 CTA） - ↓（价值交换） -CRM 线索捕获（注册/下载/咨询） - ↓（销售跟进） -合格机会（MQL → SQL） - ↓（成交转化） -客户 -``` - -## Key Metrics -| 漏斗阶段 | 知乎基准指标 | -|---------|------------| -| 曝光 → 参与 | 3-8% 流量转化为网站/CRM | -| 参与 → 线索 | 1-3% 参与用户转化为注册 | -| 线索 → 机会 | 20-30% MQL 转化为 SQL | -| 机会 → 成交 | 10-30% SQL 转化为客户 | - -## CTA Strategy on Zhihu -**原则：含蓄且有价值，从不硬推销** - -| CTA 类型 | 适用场景 | 示例 | -|---------|---------|------| -| 资源引流 | 高价值深度内容 | "需要更详细的 XX 模板，可私信获取" | -| 专栏导流 | 持续性话题 | "我在专栏《XX》中系统整理了..." | -| 咨询导流 | 专业服务型 | "如有个性化需求，可预约我的付费咨询" | -| 社群导流 | 持续互动型 | "加入 XX 社群，与同行交流..." | - -## Lead Quality Differentiation -- **低质量线索**：泛泛关注、无明确需求、无预算意识 -- **中质量线索**：有需求、有兴趣、等待合适时机 -- **高质量线索**：有明确痛点、有决策权、有预算、有紧迫时间线 - -知乎平台天然筛选高质量线索——愿意花时间阅读 300+ 词深度内容的用户，本身就展示了较高的专业素养和决策成熟度。 - -## Connections -- [[Community-Credibility]] ← 前提 ← Lead Generation Funnel（信誉是精准转化的前提） -- [[Thought-Leadership]] ← 驱动 ← Lead Generation Funnel（思想领导力吸引高质量受众） -- [[Content-Pillar]] ← 载体 ← Lead Generation Funnel（内容支柱是漏斗顶端流量的持续来源） diff --git a/wiki/concepts/Lead-Time.md b/wiki/concepts/Lead-Time.md deleted file mode 100644 index 525a46d8..00000000 --- a/wiki/concepts/Lead-Time.md +++ /dev/null @@ -1,55 +0,0 @@ -# Lead Time - -## Definition -Lead Time (specifically Lead Time for Changes) is the interval from when a developer commits code to when that code is successfully deployed to production. It measures the total time from code commitment to customer-facing value delivery. - -## Importance -Lead Time is a critical DORA (DevOps Research and Assessment) metric. Short lead times indicate: -- Efficient development and delivery processes -- High levels of automation -- Reduced risk in deployments -- Faster feedback loops -- Better alignment with business objectives - -## Across DevOps Maturity Levels - -| Maturity | Lead Time Characteristic | -|----------|-------------------------| -| Phase 1 | Long — manual processes, milestone-based releases, siloed teams cause extended lead times | -| Phase 2 | Improving — Agile practices introduced, version control helps, but manual interventions persist | -| Phase 3 | Shorter — automated builds and tests speed up delivery, security integrated earlier | -| Phase 4 | Significantly reduced — CI pipeline and automated processes enable rapid iteration | -| Phase 5 | Less than one hour — elite performance, on-demand deployment capability | - -## Elite Performance Benchmark -According to DORA research: -- **Elite performers**: Less than one hour lead time -- **High performers**: Between one week and one month -- **Medium performers**: Between one month and six months -- **Low performers**: More than six months - -## Components of Lead Time -1. **Coding time** — Time to implement the change -2. **Build time** — Automated compilation and artifact generation -3. **Test time** — Unit, integration, and acceptance tests -4. **Review time** — Code review and approval processes -5. **Deployment time** — Time to deploy through pipeline stages -6. **Queuing time** — Time waiting for resources or approvals - -## How to Improve Lead Time -- Automate the entire build-test-deploy pipeline -- Reduce batch sizes (smaller changes deploy faster) -- Implement robust automated testing to reduce review burden -- Eliminate manual approvals that create bottlenecks -- Use feature flags to decouple deployment from release -- Improve developer tooling and local build times - -## Sources -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] -- [[sources/cloud-devop-maturity-guideline.md]] - -## Related Concepts -- [[concepts/DORA-Metrics]] -- [[concepts/Continuous-Deployment]] -- [[concepts/Time-to-Market]] -- [[concepts/DevOps-Maturity]] diff --git a/wiki/concepts/Lean.md b/wiki/concepts/Lean.md deleted file mode 100644 index 130f3412..00000000 --- a/wiki/concepts/Lean.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Lean" -type: concept -tags: [Process-Improvement, Six-Sigma, Workflow-Optimization] -sources: [testing-workflow-optimizer] -last_updated: 2026-04-21 ---- - -# Lean - -精益制造/精益管理方法论，源于丰田生产系统（TPS），核心目标是通过消除一切形式的浪费（Muda），最大化客户价值。 - -## Aliases -- Lean Manufacturing -- 精益生产 -- 丰田生产系统（TPS） - -## Definition -Lean 通过识别和消除非增值活动（NVA），将价值流中的等待时间、搬运浪费、过度加工、库存过剩、不必要的移动、缺陷返工和过度生产降至最低。 - -## Key Principles -1. **价值（Value）**：从客户视角定义——客户愿意付费的转化活动 -2. **价值流（Value Stream）**：识别从原材料到交付的所有步骤，区分增值（VA）/价值赋能（VEA）/浪费（NVA） -3. **流动（Flow）**：使增值步骤持续、不中断地运行 -4. **拉动（Pull）**：按客户实际需求而非预测来生产 -5. **完美（Perfection）**：持续追求零浪费状态 - -## Three Types of Activities -| 类别 | 说明 | 示例 | -|------|------|------| -| 增值活动（VA） | 客户愿意付费的转化 | 加工零件、填写表格 | -| 价值赋能活动（VEA） | 不直接增值但必需的支撑活动 | 质量检查、设备维护 | -| 浪费（NVA/Muda） | 消耗资源但不创造客户价值的活动 | 等待、搬运、返工 | - -## Seven Types of Waste (TIMWOODS) -- **T**ransport（搬运） -- **I**nventory（库存） -- **M**otion（动作） -- **W**aiting（等待） -- **O**verproduction（过量生产） -- **O**ver-processing（过度加工） -- **S**kills underutilization（技能浪费） -- **D**efects（缺陷/返工） - -## Connection to Six-Sigma -Lean 关注速度（消除浪费），Six-Sigma 关注质量（减少变异）。两者的融合称为 **Lean Six-Sigma**，同时优化速度和精度。 - -## Connections -- [[Six-Sigma]] — 融合伙伴，速度+质量双优化 -- [[Kaizen]] — 互补：Kaizen 小步快跑，Lean 系统重构 -- [[Value-Stream-Mapping]] — 识别浪费的可视化工具 diff --git a/wiki/concepts/Learn-By-Building.md b/wiki/concepts/Learn-By-Building.md deleted file mode 100644 index 8018a137..00000000 --- a/wiki/concepts/Learn-By-Building.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Learn-By-Building" -type: concept -tags: [methodology, learning, education, pedagogy] -last_updated: 2026-04-23 ---- - -## Aliases -- Learning by Building -- Learn Through Building -- Project-Based Learning -- PBL -- 边做边学 -- 项目制学习 - -## Definition -Learn-By-Building 是一种教育方法论：通过主动构建（而非被动消费）来学习新知识。与观看教程或阅读文档不同，学习者通过实际编写代码实现一个系统，在构建过程中自然积累对原理的深层理解。 - -## Details -- **核心洞察**: "What I cannot create, I do not understand"（[[RichardFeynman]]）——无法创造的东西意味着没有真正理解 -- **典型场景**: - - 用 C 从零实现一个 TCP/IP 协议栈（[[Build-Your-Own-X]]） - - 用 Python 从零实现一个神经网络（理解反向传播的细节） - - 用 JavaScript 从零实现一个 React（理解 Virtual DOM 的原理） -- **适用范围**: 有一定基础的学习者；不适合零基础入门 -- **vs 传统课程**: 传统 CS 教育强调理论（算法/数据结构/操作系统理论），Learn-By-Building 强调实践（从零重建系统）；两者互补 - -## Relationship with BYOX -[[Build-Your-Own-X]] 是 Learn-By-Building 方法论的具体实践形式之一。BYOX 提供现成的分步骤教程资源，降低了"不知道该建什么"的门槛。 - -## Connections -- [[Learn-By-Building]] ← embodies ← [[From-Scratch-Methodology]] -- [[Learn-By-Building]] ← resources ← [[Build-Your-Own-X]] -- [[Learn-By-Building]] ← enables ← [[Codecrafters]] -- [[Learn-By-Building]] ← preceded_by ← [[NAND-to-Tetris]] diff --git a/wiki/concepts/Left-over-Principle.md b/wiki/concepts/Left-over-Principle.md deleted file mode 100644 index 5395ece1..00000000 --- a/wiki/concepts/Left-over-Principle.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Left-over Principle" -type: concept -tags: - - "Automation Theory" - - "Labor Economics" -last_updated: 2026-04-13 ---- - -# Left-over Principle（剩余原则） - -## Definition -剩余原则（Left-over Principle）是一个历史观察：在自动化进程中，一项工作的**部分**可以被自动化和集中化，而**剩余难以自动化的部分**则堆积到更少的人身上——这些人负责完成机器无法处理的复杂任务，然后协调其余部分的自动化。 - -该概念最早由 Jesse Robbins 在《A Mature Role for Automation》文章中提出（KitchenSoap, 2013）。 - -## Mechanism -``` -原始工作 → 部分自动化 → 剩余工作堆积 - ↘ 少数人承担 - ↘ 协调自动化 -``` - -自动化不是简单地"替代"工作，而是**重新分配**工作的复杂性： -- 容易自动化的部分 → 交给机器 -- 难以自动化的部分 → 人类专家承担 -- 人类角色从"执行者"转变为"协调者和判断者" - -## Application in AI SRE Context -[[The Picture They Paint of You]] 引用了这一原则来反驳"AI SRE 将完全替代人类 SRE"的论点： - -> "This does not mean organizations can fully succeed in the substitution effort. Time and time again history has shown that *part* of a role can be automated and centralized, and the rest of it will be piled onto fewer individuals who will do the hard-to-automate bits and will then coordinate the automation for the rest of it." - -这意味着即使 AI SRE 能自动化大部分 SRE 工作，仍然需要人类： -- 理解无法自动化的边界在哪里 -- 在自动化系统失败时接管 -- 协调 AI 和人工的配合 -- 从事故中提取新模式来改进自动化系统 - -## Implications -1. **AI SRE 不会消灭 SRE 角色**，而是改变其性质——从执行者变成协调者和监督者 -2. **SRE 的价值被低估**：难以自动化的 SRE 工作（理解业务上下文、复杂故障诊断、跨团队协调）恰恰是最需要人类判断力的高价值工作 -3. **自动化能力提高**会导致对 SRE 协调能力的需求**增加**而非减少 - -## Connections -- [[AI SRE]] ← 被分析 ← Left-over Principle -- [[SRE]] ← 剩余价值被凸显 ← Left-over Principle -- [[The Picture They Paint of You]] ← 引用 ← Left-over Principle - -## Sources -- [[the-picture-they-paint-of-you]] diff --git a/wiki/concepts/Liminality.md b/wiki/concepts/Liminality.md deleted file mode 100644 index 46fa3853..00000000 --- a/wiki/concepts/Liminality.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Liminality" -type: concept -tags: ["anthropology", "ritual", "threshold", "communitas", "turner"] -last_updated: 2026-04-25 ---- - -## Definition -阈限（Liminality）——仪式过程中参与者处于"之间"状态的阶段，从旧社会结构中分离但尚未整合进新状态，具有特殊的社会地位和无限可能性。 - -## Core Framework -- **van Gennep 三阶段**：分离（separation）→ 阈限（liminality）→ 整合（incorporation） -- **Communitas**：阈限状态中产生的强烈平等主义和直接人际连接，超越正常社会等级和身份 -- **社会转化**：阈限是社会结构暂时"溶解"的时刻，是文化创新和集体情感强化的关键时刻 -- **阈限悖论**：参与者既被看做"无名"又具有神圣性，既无地位又被赋予特殊权力 - -## Key Thinkers -- Arnold van Gennep（仪式三阶段提出者） -- [[Victor-Turner]]（阈限和 communitas 概念发展者） - -## Connections -- [[Anthropologist-Agent]] ← uses_framework ← [[Liminality]] -- [[Symbolic-Anthropology]] ← provides_interpretive_tools ← [[Liminality]] -- [[Rites-of-Passage]] ← operates_in ← [[Liminality]] diff --git a/wiki/concepts/Link-Proposer.md b/wiki/concepts/Link-Proposer.md deleted file mode 100644 index 8deabf87..00000000 --- a/wiki/concepts/Link-Proposer.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: "Link-Proposer" -type: concept -tags: [knowledge-management, automation, zettelkasten, zk-steward] -sources: [zk-steward] -last_updated: 2026-04-25 ---- - -## Definition -Link-Proposer（链接提议器）是 [[zk-steward]] 在新笔记归档时自动运行的链接推荐流程——基于笔记内容，提议候选链接、关键词/索引入口，并运行 [[Gegenrede]] 反诘问题，确保新笔记融入知识网络而非孤立存在。 - -## When It Runs -**触发条件**：ZK Steward 创建或归档新笔记时自动激活 - -**不触发条件**： -- 更新现有笔记（非新笔记） -- 仅检索/查询任务 -- 跳过归档步骤 - -## The Three Steps - -### Step 1: Link Candidates（链接候选） -基于笔记内容的语义分析，提议 2-5 个最相关的已有笔记/概念： -- 直接关联笔记（同主题） -- 方法论关联（同一框架） -- 对比关联（相反观点） -- 元关联（关于笔记本身的笔记） - -### Step 2: Keyword & Index Suggestions（关键词/索引建议） -- 提议 3-5 个关键词（用于未来检索） -- 建议索引/MOC 条目（确保笔记有 ≥1 入口点） -- 注意：索引是入口，不是分类——同一笔记可被多个索引指向 - -### Step 3: Gegenrede（反诘问题） -提出一个跨学科反问，激发辩证对话： -> "如果从 [另一领域] 角度看这个问题会怎样？" - -详见 [[Gegenrede]]。 - -## Relationship to Luhmann 四原则 - -Link-Proposer 是 [[Luhmann-四原则]]中**连接性（Connectivity）**原则的自动化实现工具： - -| 四原则 | Link-Proposer 贡献 | -|--------|-----------------| -| 原子性 | 新笔记若需链接多个主题 → 触发拆分建议 | -| 连接性 | 直接提供 ≥2 链接候选 | -| 有机增长 | 关键词/索引建议防止过度层级 | -| 持续对话 | Gegenrede 激发后续思考 | - -## Implementation - -Link-Proposer 作为可选 Skill 定义在 [[zk-steward-companion]] 仓库中，可通过以下方式激活： -1. 将 `skills/link-proposer/` 复制到 Agent 技能目录 -2. 在 ZK Steward 的归档流程中调用 -3. 人工审阅提议后选择性采纳 - -## Connections -- [[zk-steward]] ← 在归档流程中调用 Link-Proposer -- [[Luhmann-四原则]] ← Link-Proposer 服务于连接性原则 -- [[Gegenrede]] ← Link-Proposer 的第三步 -- [[Zettelkasten]] ← Link-Proposer 是 Zettelkasten 链接机制的程序化 -- [[zk-steward-companion]] ← Link-Proposer 作为 Skill 定义存在 - -## Aliases -- 链接提议器 -- Link Suggestion Engine -- Note Linking Workflow diff --git a/wiki/concepts/LintWorkflow.md b/wiki/concepts/LintWorkflow.md deleted file mode 100644 index 980f15b0..00000000 --- a/wiki/concepts/LintWorkflow.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "LintWorkflow" -type: concept -tags: [workflow, knowledge-management, llm, quality] -sources: [llm-wiki] -last_updated: 2026-05-02 ---- - -## Overview -检查工作流（Lint Workflow）是 [[PersistentWiki]] 的定期健康检查机制——让 LLM 定期检查 Wiki 的质量，发现问题并提出改进建议。 - -## Standard Checks - -### 1. 孤立页面（Orphan Pages） -没有任何其他页面通过 `[[wikilinks]]` 指向它的 Wiki 页面。 - -### 2. 断链（Broken Links） -`[[WikiLinks]]` 指向不存在的页面。 - -### 3. 内容冲突（Contradictions） -跨页面存在相互矛盾的论点。 - -### 4. 过时摘要（Stale Summaries） -有更新来源后未同步更新的页面。 - -### 5. 缺失 Entity 页面 -在 3 个以上页面中被提及但没有独立页面的实体。 - -### 6. 数据缺口（Data Gaps） -Wiki 无法回答的问题，建议补充新来源。 - -## Trigger -触发方式：用户说 "lint" - -## Output -输出检查报告，询问用户是否保存为 `wiki/lint-report.md`。 - -## Design Principles -- **定期执行**：保持 Wiki 健康，防止问题积累 -- **LLM 擅长发现**：LLM 擅长提出新的研究问题和新的来源建议 -- **自动化维护**：配合 [[IngestWorkflow]] 和 [[QueryWorkflow]]，构成完整的 Wiki 生命周期管理 diff --git a/wiki/concepts/Liquid-Glass-Design-System.md b/wiki/concepts/Liquid-Glass-Design-System.md deleted file mode 100644 index 74b03fa5..00000000 --- a/wiki/concepts/Liquid-Glass-Design-System.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Liquid Glass Design System" -type: concept -tags: [] -sources: [visionos-spatial-engineer] -last_updated: 2026-04-25 ---- - -## Definition -Apple visionOS 26 引入的核心视觉设计语言，通过透明材质实现深度感知和空间沉浸感。Liquid Glass 设计系统让 UI 元素呈现出类似玻璃的透明、折射和光影效果，同时自适应 light/dark 环境变化和周围内容。 - -## Core Characteristics -- **Translucent Materials（透明材质）**：UI 元素呈现玻璃般的透明效果，可透视背后的 3D 空间内容 -- **Adaptive Lighting（自适应光效）**：根据环境光照条件动态调整透明度和反射效果 -- **Depth Perception（深度感知）**：通过透明层级传达 UI 元素在 Z 轴上的相对位置 -- **Contextual Adaptation（内容自适应）**：透明效果根据周围 3D 内容动态调整，确保可读性和美观性 - -## Implementation Technologies -- **SwiftUI glassBackgroundEffect**：实现毛玻璃透明背景的 SwiftUI modifier -- **RealityKit Materials**：RealityKit 中的物理材质系统支持 Liquid Glass 效果 -- **Metal Shader Framework**：底层 GPU 渲染支持高性能透明效果计算 - -## Related Concepts -- [[Spatial Layouts]]：Liquid Glass UI 在 3D 空间中的布局管理 -- [[Multi-Window Architecture]]：多窗口场景下 Liquid Glass 效果的一致性 -- [[Glass Background Effects]]：具体实现透明效果的技术手段 - -## Sources -- [[visionos-spatial-engineer]] — visionOS Spatial Engineer Agent 角色定义 diff --git a/wiki/concepts/Local-Caching.md b/wiki/concepts/Local-Caching.md deleted file mode 100644 index 496c8f69..00000000 --- a/wiki/concepts/Local-Caching.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Local Caching" -type: concept -tags: [] -sources: [arxiv-paper-reader] -last_updated: 2026-04-17 ---- - -## Concept Definition -**本地缓存（Local Caching）** 是指将 API 调用结果或解析结果持久化到本地文件系统，使重复访问无需重新请求或重新处理，直接从本地读取即可获得毫秒级响应。 - -## How It Works -1. 首次请求：API 调用 → 结果处理 → 写入本地缓存文件（含 hash 标识） -2. 后续请求：计算请求 hash → 命中缓存 → 直接返回本地文件内容 -3. 缓存失效：由 TTL、源文件修改时间或手动清理触发 - -## Use Cases -- [[arXiv-Paper-Reader]]：论文解析结果本地缓存，重复阅读即时响应 -- [[Semantic-Memory-Search]]：向量嵌入缓存，避免重复计算 -- [[YouTube-Content-Pipeline]]：视频目录 90 天缓存，避免重复抓取 - -## Trade-offs -- **优点**：零成本、即时响应、保护 API 限额 -- **缺点**：占用磁盘空间、需管理缓存失效策略 - -## Related Concepts -- [[Content Hashing]]：用于缓存键生成的哈希机制 -- [[File Watcher]]：检测源文件变更触发缓存失效 diff --git a/wiki/concepts/Local-LLM-Deployment.md b/wiki/concepts/Local-LLM-Deployment.md deleted file mode 100644 index 881a18b9..00000000 --- a/wiki/concepts/Local-LLM-Deployment.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "Local LLM Deployment" -type: concept -tags: [] -last_updated: 2026-04-23 ---- - -# Local LLM Deployment - -## Definition -在本地机器上离线部署和运行大语言模型（LLM），无需依赖云端 API 服务，实现数据完全私有化且零 API 调用费用。 - -## Key Benefits -- **隐私安全**：数据不出本地，无需上传至第三方服务器 -- **成本为零**：无需 API Key，无调用费用 -- **离线可用**：无网络连接要求 -- **完全可控**：可自由选择模型、配置参数、定制系统提示词 - -## Core Stack -| 组件 | 作用 | 代表工具 | -|------|------|---------| -| LLM 运行时 | 本地运行大模型 | [[Ollama]], llama.cpp, vLLM | -| 大模型 | 推理能力 | [[DeepSeek]]-R1, Llama, Qwen | -| Web 界面 | 图形化交互 | [[Open WebUI]], ChatUI | -| 知识库 | RAG 增强 | bge-m3, Chroma | - -## Hardware Requirements -| 模型参数规模 | 最低 RAM | 推荐显存 | 典型硬件 | -|------------|---------|---------|---------| -| 1.5B | 4 GB | 4 GB | 普通笔记本 | -| 7B | 16 GB | 14 GB | 有独显的电脑 | -| 32B | 64 GB | 48 GB | Mac Studio M2 Max / 高端工作站 | -| 70B+ | 128 GB | 140 GB+ | 多 GPU 服务器 | - -## Implementation Options -1. **ollama run**：`ollama run deepseek-r1:8b` 一行命令本地运行 -2. **Docker 部署**：`docker run --gpus=all -p 11434:11434 ollama/ollama` -3. **API 服务**：通过 `http://localhost:11434/api/generate` 调用 -4. **Web 界面**：部署 [[Open WebUI]] 提供浏览器交互 - -## China Environment Challenges & Solutions -| 挑战 | 解决方案 | -|------|---------| -| 模型下载慢 | 魔塔社区（modelscope.cn）、HF Mirror（hf-mirror.com）、夸克网盘 | -| GPU 不可用 | Docker GPU 模式：`docker run --gpus=all` | -| 模型导入 | `ollama create -f ` 导入本地 GGUF 文件 | -| API 安全 | nginx 反向代理 + Bearer Token 认证 | - -## Related Concepts -- [[Docker LLM Deployment]]：通过 Docker 容器化部署本地 LLM -- [[RAG]]：本地 LLM 的知识增强技术 -- [[Model Quantization]]：GGUF 格式量化降低硬件要求 -- [[Ollama]]：本地 LLM 部署的核心运行时工具 - -## Sources -- [[详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1]] diff --git a/wiki/concepts/Local-first-Git.md b/wiki/concepts/Local-first-Git.md deleted file mode 100644 index fafa456a..00000000 --- a/wiki/concepts/Local-first-Git.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Local-first Git" -type: concept -tags: [git, security, devops, self-hosted, devsecops] -date: 2026-04-22 ---- - -## Definition -Local-first Git 是一种 Git 工作流策略：所有代码变更首先推送到本地/私有 Git 服务（而非直接推送到公共 GitHub），经过 CI 扫描和人工 review 后再合并到公共仓库。核心原则：**公共仓库永远不应该是 Agent 的直接目标**。 - -## In Home Lab Context -在 [[self-healing-home-server]] 的安全架构中，Local-first Git 工作流： -``` -Agent commits - ↓ -Gitea (private self-hosted) — 私有中转站 - ↓ -CI pipeline — TruffleHog secrets scanning - ↓ -Human review — 必须人工审核 main 分支合并 - ↓ -GitHub (public) — 最终发布目标 -``` - -## Why Local-first for AI Agents? -1. **Secrets 暴露风险**：AI Agent 会在代码中直接写入 API keys（TruffleHog 可检测但不能阻止） -2. **CI 安全扫描**：在代码到达公共仓库前，有机会拦截问题 -3. **Human oversight**：人工 review 作为最后防线 -4. **Audit trail**：Gitea 提供完整的代码变更审计记录 - -## Connections -- [[Gitea]] — Local-first 工作流的核心基础设施 -- [[TruffleHog]] — CI pipeline 中的 secrets scanning 工具 -- [[Defense-in-Depth]] — Local-first Git 是多层安全防御的一环 -- [[OpenClaw]] — 使用 Local-first Git 工作流的 Agent 平台 diff --git a/wiki/concepts/Localization.md b/wiki/concepts/Localization.md deleted file mode 100644 index 518532fb..00000000 --- a/wiki/concepts/Localization.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "Localization" -type: concept -tags: - - marketing - - cross-border - - globalization - - multilingual - - ecommerce -sources: - - marketing-cross-border-ecommerce -last_updated: 2026-04-26 ---- - -## Aliases -- Localization -- 本地化 -- 市场本地化 -- 跨文化本地化 - -## Definition - -Localization（本地化）是指将产品、Listing、内容和服务根据目标市场的语言、文化审美、消费习惯、定价能力和监管要求进行适应性调整的过程。在跨境电商中，本地化决定产品能否在目标市场获客，是与"翻译"（translation）相对的概念——不仅转换语言，更转换用户体验。 - -## Core Dimensions - -### 语言本地化 -- 母语级 Listing 撰写（机器翻译是转化率最大杀手） -- 文化禁忌和敏感词规避 -- 多语言 SEO（标题、描述、Backend Search Terms） -- 客服脚本的本地语言版本 - -### 视觉本地化 -- 主图风格适配目标市场审美（美国简洁白底 vs 日本生活场景） -- Lifestyle 图片融入本地生活情境 -- 信息图设计符合本地信息获取习惯 -- 包装设计符合当地文化偏好 - -### 定价本地化 -- 基于本地消费能力和竞争格局定价，而非简单汇率换算 -- 促销活动节奏与当地消费日历对齐 -- 多货币动态定价策略 - -### 服务本地化 -- 目标市场时区的客服响应 -- 符合当地沟通习惯的服务流程 -- 退货政策适配各地消费者期望 - -## Key Principle - -> 本地化决定能否获客，合规决定能否存活，供应链决定能否盈利。 - -## When to Use - -- 进入任何新市场（新平台、新国家）前必须完成本地化评估 -- 识别本地化差距：列出所有未做本地化调整的元素 -- 优先级排序：先核心 Listing，再视觉，再客服脚本 - -## Connections -- [[Marketing Cross-Border E-Commerce Specialist]] ← requires ← [[Localization]] -- [[TikTok Shop]] ← depends_on ← [[Localization]] (content localization is core) -- [[Listing Optimization]] ← incorporates ← [[Localization]] diff --git a/wiki/concepts/Lockable-Workflow.md b/wiki/concepts/Lockable-Workflow.md deleted file mode 100644 index 8b99c280..00000000 --- a/wiki/concepts/Lockable-Workflow.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Lockable-Workflow" -type: concept -tags: [security, workflow, n8n, governance] -sources: [n8n-workflow-orchestration] -last_updated: 2026-04-17 ---- - -## Aliases -- Lockable Workflow -- 可锁定工作流 - -## Definition - -工作流在 Agent 构建、人工验证后进入锁定状态（locked），锁定后的工作流不可被 Agent 修改，从而确保工作流的 API 调用逻辑不被 Agent 静默改变。锁定是 [[Webhook-Proxy-Pattern]] 安全运转的必要条件。 - -## Why It Matters -- 不锁定的工作流，Agent 可以通过 n8n API 重新编辑 Webhook 逻辑 -- Agent 可能无意中修改凭证参数或 API 端点 -- 锁定创建了一个明确的信任边界：Agent 只能调用，不能改造 - -## Lifecycle -1. **Build**：Agent 通过 n8n API 创建工作流 -2. **Test**：管理员验证工作流行为符合预期 -3. **Lock**：锁定工作流，Agent 失去编辑权限 -4. **Call**：Agent 通过 Webhook 持续调用 - -## Connections -- [[Webhook-Proxy-Pattern]] — 锁定保障该模式的安全 -- [[Credential-Isolation]] — 与凭证隔离共同构成安全护城河 -- [[Safeguard-Steps]] — 锁定前可加入人工审批等 Safeguard -- [[n8n]] — 提供工作流锁定能力的平台 diff --git a/wiki/concepts/Log-Driven-Debugging.md b/wiki/concepts/Log-Driven-Debugging.md deleted file mode 100644 index f971db6c..00000000 --- a/wiki/concepts/Log-Driven-Debugging.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Log-Driven Debugging" -type: concept -last_updated: 2026-04-10 ---- - -## Definition -Log-Driven Debugging 是一种通过系统日志定位问题根因的调试方法，尤其适用于分布式系统和多层配置架构。当错误信息具有误导性时，日志是最直接的系统状态反映。 - -## Key Insight -> **日志真的有用：Gateway 日志把问题写得明明白白，只是我自己没仔细看。** - -## OpenClaw Gateway Log Example -``` -provider=custom-api-deepseek-reasoner/deepseek-reasoner ctx=16000 -estimatedPromptTokens=393 overflowTokens=392 reserveTokens=16384 -``` -这条日志直接揭示了： -1. 当前模型已被切换为 deepseek-reasoner -2. 模型 context window 为 16K -3. Safeguard 预留 16K tokens 导致 overflow - -## Related -- [[Error-Surface-vs-Root-Cause]]: 日志帮助还原真实根因 -- [[Hidden-Failure-Paths]]: 日志是发现隐藏故障路径的唯一可靠手段 -- [[Layered-Configuration]]: 日志帮助识别配置层级问题 - -## Sources -- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]] diff --git a/wiki/concepts/Longue-Duree.md b/wiki/concepts/Longue-Duree.md deleted file mode 100644 index abb4deb3..00000000 --- a/wiki/concepts/Longue-Duree.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Longue Durée" -type: concept -tags: ["historiography", "historical-time", "structuralism", "braudel"] -sources: ["academic-historian"] -last_updated: 2026-04-25 ---- - -## Definition -布罗代尔提出的历史时间理论，主张历史存在三个层次的时间： -1. **地理时间（La longue durée）**：几十年到几百年的长时段——地理环境、生态环境、大型人口趋势、结构性经济变化 -2. **社会时间（Les cycles oder conjunctures）**：十年到五十年的中时段——经济周期、人口波动、社会流动 -3. **事件时间（L'histoire événementielle）**：日常政治事件——战争、条约、人物决策等"表面"历史 - -核心理念：**表面的快速事件变化之下，深层的缓慢结构往往不变**——历史学家的首要任务是识别和解释这些深层结构。 - -## Etymology -法语 *longue durée* = "漫长的持续时间"（long duration）。布罗代尔用它来强调与当时法国史学主流（事件史、政治史）的断裂。 - -## Key Example -布罗代尔在《菲利普二世时代的地中海和地中海世界》（*La Méditerranée et le monde méditerranéen à l'époque de Philippe II*，1949）中，以数百年为单位描述地中海的地理环境、贸易网络和社会结构，再在之上叠加相对快速的经济波动和政治事件。 - -## Relationship to Annales School -- [[Annales-School]] 的核心理论支柱之一 -- 由费尔南·布罗代尔（Fernand Braudel）在年鉴学派第二代发展中系统化 - -## Connections -- [[academic-historian]] ← 方法论 ← [[Longue-Duree]]：Historian Agent 在历史因果推理中区分长期结构性原因与短期触发事件 -- [[Annales-School]] ← 核心框架 ← [[Longue-Duree]] - -## Aliases -- 长时段 -- Longue durée -- Structure history -- Braudel's three levels of historical time -- Geographic time diff --git a/wiki/concepts/Lore-Architecture.md b/wiki/concepts/Lore-Architecture.md deleted file mode 100644 index 0c554b04..00000000 --- a/wiki/concepts/Lore-Architecture.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: "Lore Architecture" -type: concept -tags: [game-narrative, worldbuilding, lore] -sources: [narrative-designer.md] -last_updated: 2026-04-26 ---- - -# Lore Architecture - -Lore 架构——三层可选深度世界构建体系，确保叙事丰富性与可理解性并存。 - -## Core Rule - -**Lore is always optional — the critical path must be comprehensible without any collectibles or optional dialogue.** - -玩家不需要探索任何可选内容，也能理解并享受核心故事。 - -## Three Tiers - -### Tier 1: Surface（所有玩家） -**内容**：关键路径上所有玩家都会遇到的内容 - -- 主线过场动画 -- 关键 NPC 必要对话 -- 定义世界视觉地标的环境叙事 -- 定义世界规则的基础设定 - -**设计原则**：这部分 Lore 是"地板"——永远不能低于这个质量标准，因为它面向所有人。 - -### Tier 2: Engaged（探索者） -**内容**：与所有 NPC 交谈、阅读笔记、探索区域的玩家会发现 - -- 支线任务对话 -- 可收集笔记和日志 -- 可选 NPC 对话 -- 可发现的环境叙事场景 - -**设计原则**：为喜欢深入世界但不追求极致的玩家准备。不强制但值得。 - -### Tier 3: Deep（深度 Lore 猎手） -**内容**：寻找隐藏房间、秘密物品、元叙事线索的玩家会发现 - -- 隐藏文档和加密日志 -- 需要推理才能理解的环境细节 -- 连接表面层与探索层看似无关的 Tier 1 和 Tier 2 beat 的深层联系 -- 揭示游戏真正元叙事的高阶内容 - -**设计原则**：为最投入的玩家准备的额外奖励。不能作为理解核心故事的必要条件。 - -## World Bible（世界圣经） - -所有 Lore 必须与世界圣经一致——即使是最背景的细节也不例外： - -```markdown -## World Bible Quick Reference -- Timeline: [关键历史事件和日期] -- Factions: [名称、目标、哲学、与玩家关系] -- Rules of the World: [什么是可能的，什么不可能——物理/魔法/科技规则] -- Banned Retcons: [Tier 1 中已建立的事实，永远不能被矛盾] -``` - -## Lore 与 Environmental Storytelling 的关系 - -- 环境叙事是 Tier 2 Deep 的物理呈现方式 -- Tier 1 Surface 通过显式叙事（对话、过场）传递 -- Tier 2/3 通过环境道具的空间布局无声传递 - -## Consistency Enforcement -- 环境叙事与对话/过场故事之间**零矛盾** -- 任何 Lore 更新必须同步到 World Bible -- 违反 World Bible 的内容在 Code Review 阶段必须被拦截 - -## Related Concepts -- [[Environmental Storytelling]]：环境叙事是 Lore 在空间中的物理表达 -- [[Narrative Debt Tracking]]：Lore 中的伏笔和解承诺需要债务追踪 -- [[Branching Narrative]]：不同分支可能通向不同深度的 Lore - -## Sources -- [[Narrative Designer Agent Personality]] — Lore Architecture diff --git a/wiki/concepts/Lost-Prompt-Analysis.md b/wiki/concepts/Lost-Prompt-Analysis.md deleted file mode 100644 index f80916c8..00000000 --- a/wiki/concepts/Lost-Prompt-Analysis.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Lost Prompt Analysis" -type: concept -tags: ["AEO", "GEO", "analysis", "competitive-intelligence"] -last_updated: 2026-04-26 ---- - -## Definition - -Lost Prompt Analysis（丢失提示分析）是 AI Citation Audit 的核心分析方法之一——系统性地识别品牌应该出现在 AI 答案中但竞争对手胜出的查询场景。通过分析"为什么会输"，推导出内容修复方向。 - -## Method - -1. **Query Set Generation**：生成 20-40 个目标受众会在 AI 平台输入的查询 - - 类型：推荐类、对比类、教程类、最佳选择类 - - 格式："Best X for Y"、"X vs Y"、"How to choose X"、"Recommend a X" - -2. **Multi-Platform Query**：在 ChatGPT、Claude、Gemini、Perplexity 四个平台分别运行完整查询集 - -3. **Result Recording**：记录每次查询中： - - 哪个品牌被引用 - - 引用位置（开头/中间/结尾） - - 引用上下文（作为什么类型的来源被引用） - -4. **Gap Identification**：标记品牌缺席但竞品出现的查询 → **Lost Prompts** - -5. **Root Cause Analysis**：对每个 Lost Prompt 分析竞品胜出的原因： - - 内容结构（FAQ 页 vs 博客文章） - - Schema markup（有无 FAQPage/Product schema） - - 实体信号（品牌一致性、知识图谱覆盖） - - 内容格式（对比表格 vs 段落叙述） - -## Output Format - -```markdown -| Prompt | Platform | Who Gets Cited | Why They Win | Fix Priority | -|--------|---------|---------------|--------------|-------------| -| "Best X for Y" | All 4 | Competitor A | Comparison page with structured data | P1 | -| "How to choose X" | ChatGPT, Gemini | Competitor B | FAQ matching query pattern | P1 | -``` - -## Related Concepts - -- [[Fix Pack]]：Lost Prompt Analysis 的产出驱动 Fix Pack 的生成 -- [[Citation Rate]]：Lost Prompt 数量直接影响整体 Citation Rate -- [[Platform-Specific Patterns]]：不同平台 Loss Prompt 的原因可能不同 - -## Sources - -- [[AI Citation Strategist]] diff --git a/wiki/concepts/Loyalty-Program-Management.md b/wiki/concepts/Loyalty-Program-Management.md deleted file mode 100644 index 135023d4..00000000 --- a/wiki/concepts/Loyalty-Program-Management.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Loyalty Program Management" -type: concept -tags: [] -sources: - - hospitality-guest-services -last_updated: 2026-05-02 ---- - -## Definition -Loyalty Program Management（忠诚计划管理）是对酒店或品牌忠诚会员全生命周期（注册→入住→退房→再入住）的系统性管理，确保每位会员在其会员等级所对应的每一触点都被识别、认可和奖励。 - -## Lifecycle Stages - -### 1. Enrollment（注册） -- 每次入住时主动向非会员推荐："您是否加入了我们的[忠诚计划]？免费注册，本次入住即可赚取积分" -- 沟通核心价值：积分赚取比例、欢迎奖励、等级权益 -- 兑换选项：未来房晚、餐饮、水疗服务 - -### 2. Tier Recognition（等级认可） -入住时每次必须执行的识别流程： -- **银卡**：欢迎+姓名+积分余额 -- **金卡**：欢迎+姓名+积分余额+具体权益 -- **白金/顶级**：最高级别认可 + 专属安排（升级/amenity/特殊礼遇） - -> "Never let a loyalty member feel invisible" — 忠诚会员未被认可其身份等同于服务失误 - -### 3. Points Management（积分管理） -- 积分在退房后72小时内到账 -- 餐饮、水疗、活动等额外消费同步积分 -- 缺失积分：48小时内提交忠诚团队+宾客确认 - -### 4. Complaint Escalation（投诉升级） -会员积分未到账、等级状态问题、兑换障碍： -1. 详细记录问题 -2. 48小时内提交忠诚团队 -3. 跟进宾客确认解决 - -## Key Metrics -- 会员入住率（Membership Occupancy Rate） -- 会员生命周期价值（Member Lifetime Value） -- 积分兑换率（Redemption Rate） -- 会员获取成本 vs. 获取收益 - -## Connections -- [[Hospitality Guest Services]] ← 忠诚计划管理是宾客服务 Agent 入住→退房全流程的核心技能 -- [[Guest Journey]] ← 忠诚计划贯穿宾客旅程的每一触点 -- [[Review Management]] ← 忠诚会员的好评权重更高，流失影响更大 - -## Aliases -- 忠诚计划管理 -- 会员管理 -- Guest Loyalty Program -- Rewards Program diff --git a/wiki/concepts/Luhmann-四原则.md b/wiki/concepts/Luhmann-四原则.md deleted file mode 100644 index 38017c17..00000000 --- a/wiki/concepts/Luhmann-四原则.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "Luhmann四原则" -type: concept -tags: [knowledge-management, validation, zettelkasten, zk-steward] -sources: [zk-steward] -last_updated: 2026-04-25 ---- - -## Definition -Luhmann 四原则是 [[zk-steward]] 的强制验证门（Validation Gate），每条笔记在归档前必须通过四个维度的检查，由 [[Niklas-Luhmann]] 的 Zettelkasten 方法论操作化提取而来。 - -## The Four Principles - -| 原则 | 检查问题 | 含义 | -|------|---------|------| -| **Atomicity（原子性）** | Can it be understood alone? | 笔记独立可理解，无需依赖其他笔记上下文 | -| **Connectivity（连接性）** | Are there ≥2 meaningful links? | 笔记必须与至少两个其他笔记建立有意义的链接 | -| **Organic Growth（有机增长）** | Is over-structure avoided? | 避免过度层级结构；笔记网络自然生长而非强行分类 | -| **Continued Dialogue（持续对话）** | Does it spark further thinking? | 笔记能激发进一步思考，而非终结话题 | - -## Why Four Principles? - -四个原则共同构成一个**验证漏斗**： -- **原子性** → 保证最小粒度，避免"大而无当"的笔记 -- **连接性** → 保证网络密度，防止孤立笔记 -- **有机增长** → 防止"分类强迫症"，让知识自然涌现 -- **持续对话** → 保证知识活性，防止静态存储 - -## Relationship to Zettelkasten - -[[Niklas-Luhmann]] 本人用一生实践验证了这四个原则——他的 90,000 张卡片笔记通过双向链接形成了一个有机知识网络，每张卡片都可独立理解，同时与其他卡片形成丰富对话。 - -[[zk-steward]] 将这四个原则程序化为： -- 每条回复末尾的四原则检查表 -- 新笔记归档前的强制验证 -- 链接提议器（[[Link-Proposer]]）确保连接性 -- Gegenrede 反诘问题激发持续对话 - -## 与 AI Agent 质量标准的类比 - -| Luhmann 原则 | AI Agent 输出质量对应 | -|-------------|-------------------| -| 原子性 | 输出聚焦单一主题，不混杂 | -| 连接性 | 输出引用/链接相关背景知识 | -| 有机增长 | 避免过度预设分类框架 | -| 持续对话 | 主动提出后续问题/开放循环 | - -## Connections -- [[zk-steward]] ← 使用 Luhmann 四原则作为验证门 -- [[Zettelkasten]] ← Luhmann 四原则的来源方法论 -- [[Niklas-Luhmann]] ← Luhmann 四原则的提出者 -- [[Link-Proposer]] ← 保证连接性的工具，与四原则协同 - -## Aliases -- 四原则验证门 -- Validation Gate -- Luhmann Validation diff --git a/wiki/concepts/MCPOnceAllAgents.md b/wiki/concepts/MCPOnceAllAgents.md deleted file mode 100644 index 9188168c..00000000 --- a/wiki/concepts/MCPOnceAllAgents.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "MCP Once All Agents" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-22 ---- - -# MCP Once All Agents - -一种 MCP（Model Context Protocol）配置模式——在多 Agent 平台中配置一次 MCP 服务器，该配置自动同步到平台内所有集成的 Agent，无需逐个 Agent 单独配置。 - -## 动机 - -在 [[Multi-AgentHub]] 场景中，每个 Agent 可能需要访问相同的外部工具和服务（如文件系统、数据库、Web 浏览器）。传统方式是每个 Agent 独立配置 MCP 服务器： -- 配置重复，N 个 Agent 需要维护 N 份配置 -- 更新繁琐，修改一个工具需要同步更新所有 Agent 配置 -- 容易出现配置不一致 - -## 机制 - -1. **中心化配置**：在 Hub 层面统一配置 MCP 服务器连接 -2. **自动分发**：Hub 自动将 MCP 配置注入每个集成的 Agent 上下文 -3. **单一数据源**：MCP 服务器变更只需在 Hub 中更新一次 - -## 典型场景 - -[[AionUi]] 在 AionUi 中配置 MCP 服务器后，自动同步到 OpenClaw、Claude Code、Codex 等所有 Agent。 - -## 与传统模式的对比 - -| 维度 | 独立 MCP 配置 | MCP Once All Agents | -|------|-------------|---------------------| -| 配置数量 | N 个（每个 Agent）| 1 个（Hub 层面）| -| 更新成本 | O(N) | O(1) | -| 一致性 | 容易出现差异 | 天然一致 | -| 适用场景 | Agent 能力差异大 | 多 Agent 共享工具集 | - -## 相关概念 -- [[Multi-AgentHub]]：MCP Once All Agents 的典型应用场景 -- [[MCP Tool Interface Design]]：MCP 协议的接口设计原则 diff --git a/wiki/concepts/MEDDPICC.md b/wiki/concepts/MEDDPICC.md deleted file mode 100644 index eae9c970..00000000 --- a/wiki/concepts/MEDDPICC.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "MEDDPICC" -type: concept -tags: [sales, qualification, deal-scoring, revenue-operations] -last_updated: 2026-04-25 ---- - -## Definition -MEDDPICC 是一个八维度的 Deal 资格评估框架，用于诊断销售 Pipeline 中的交易质量和预测可行性。它是 [[PipelineVelocity]] 体系的组成部分，为 Deal 健康评分（[[DealHealthScoring]]）提供资格深度维度。 - -## Dimensions（八个维度） - -| 维度 | 全称 | 诊断问题 | -|------|------|---------| -| **M** | Metrics | 买家是否已量化了解决该问题的价值？ | -| **E** | Economic Buyer | 签单人是否已确认并参与？ | -| **D** | Decision Criteria | 是否了解评估标准及其权重？ | -| **D** | Decision Process | 是否有完整的时间线和审批链映射？ | -| **P** | Paper Process | 法律、安全、采购要求是否已识别？ | -| **I** | Implicated Pain | 痛苦是否与买家组织被考核的业务成果挂钩？ | -| **C** | Champion | 内部倡导者是否有权力和动机推动交易？ | -| **C** | Competition | 是否知道竞争对手及自身相对位置？ | - -## Key Rules - -- **5/8 阈值**：少于 5 个维度被充分填充的 Deal 在晚期阶段为资格不足 -- 资格不足的晚期 Deal 是**预测失误的主要来源** -- 资格诊断的缺口是**交易风险信号**，而非 CRM 记录问题 - -## Connections -- [[DealHealthScoring]] — MEDDPICC 是 Deal 健康评分的资格深度维度 -- [[PipelineVelocity]] — Deal 质量影响整体 Pipeline Velocity -- [[SalesCoach]] — Sales Coach Agent 使用 MEDDPICC 进行交易资质诊断 -- [[SalesPipelineAnalyst]] — Pipeline Analyst Agent 将 MEDDPICC 评分作为关键风险信号 - -## Contradictions -- 与 [[SalesCoach]] 的早期描述冲突：之前描述为"六个维度"，现已修正为八个维度 diff --git a/wiki/concepts/MEMORY.md.md b/wiki/concepts/MEMORY.md.md deleted file mode 100644 index 0eaac491..00000000 --- a/wiki/concepts/MEMORY.md.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "MEMORY.md" -type: concept -tags: [OpenClaw, Agent, Memory] -sources: [万字讲透openclaw-workspace深度解析-2026-03-21] -last_updated: 2026-03-21 ---- - -## Definition - -**MEMORY.md** 是 OpenClaw workspace 中用于存储 Agent **长期知识总表**的文档，与 `memory/` 日期滚动目录共同构成 Agent 的持久记忆层。 - -## 与 memory/ 目录的关系 - -- **MEMORY.md**：长期知识总表，适合存储需要长期保留的、不随时间变化的知识 -- **memory/**：按日期滚动的记忆笔记，适合存储随时间积累的会话片段和临时洞见 - -两者共同构成 [[Agent-Memory]] 的存储层。 - -## Related Concepts - -- [[Agent-Memory]] — 跨会话长期记忆机制 -- [[Workspace]] — MEMORY.md 所在的目录 -- [[OpenClaw]] — MEMORY.md 所属的框架 - diff --git a/wiki/concepts/MLOps.md b/wiki/concepts/MLOps.md deleted file mode 100644 index d71cb804..00000000 --- a/wiki/concepts/MLOps.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "MLOps" -type: concept -tags: [ML, DevOps, machine-learning, operations, CI/CD] -sources: - - public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin -last_updated: 2026-05-12 ---- - -## Definition -MLOps（Machine Learning Operations，机器学习运维）将机器学习与运维结合，涉及人员、技术和流程，以实现协作式 ML 解决方案。ML Ops 需要多元化团队和鼓励协作的文化，扩展了 DevOps 的原则和方法。 - -## Key Components - -### Three Pipelines - -#### 1. Data Pipeline（数据管道） -- 数据收集（Data Collection） -- 数据集成（Data Integration） -- 数据准备（Data Preparation） -- **工具**: Amazon S3, Amazon Redshift - -#### 2. Training Pipeline（训练管道） -- 特征工程（Feature Engineering） -- 模型训练（Model Training） -- 超参数调优（Hyperparameter Tuning） -- **工具**: Amazon SageMaker - -#### 3. Inference Pipeline（推理管道） -- 模型部署（Model Deployment） -- 模型监控（Model Monitoring） -- **工具**: Amazon SageMaker Real-time Endpoints - -## Key Challenges -- 数据溯源（Data Provenance） -- 模型管理（Model Management） -- 部署工作流（Deployment Workflows） -- 持续集成/持续部署（CI/CD） -- 监控与可观测性 - -## Relationship to DevOps -MLOps 在 DevOps 实践基础上增加了 ML 特有的挑战： -- 模型版本控制 -- 实验追踪 -- A/B 测试 -- 模型性能监控 -- 数据漂移检测 - -## Related Concepts -- [[DevOps]] -- [[Amazon-SageMaker]] -- [[Foundation-Models]] -- [[Responsible-AI]] - -## Related Entities -- [[AWS]] - -## Sources -- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] diff --git a/wiki/concepts/MPP.md b/wiki/concepts/MPP.md deleted file mode 100644 index 4d8a9643..00000000 --- a/wiki/concepts/MPP.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "MPP (Massively Parallel Processing)" -type: concept -tags: - - Distributed Computing - - Data-Warehouse - - Performance -sources: - - ctp-topic-68-introduction-to-redshift -last_updated: 2026-04-23 ---- - -## Overview -MPP（大规模并行处理）是一种分布式计算架构，通过多个计算节点并行执行查询和数据处理任务，显著提升大规模数据集的查询速度和系统吞吐量。 - -## How It Works -1. **任务分解**：协调节点（Leader/Coordinator）将大型查询分解为多个子任务 -2. **并行分发**：子任务分发至多个计算节点（Compute Node） -3. **独立执行**：各节点在本地数据子集（Slice/Partition）上并行执行计算 -4. **结果汇总**：各节点结果返回协调节点，进行最终聚合和输出 - -## Key Benefits -- **线性扩展**：增加节点数量可线性提升查询性能 -- **高吞吐量**：适合复杂分析查询和大规模数据聚合 -- **容错性**：单节点故障不影响整体系统（部分实现） - -## Trade-offs -- **数据倾斜（Data Skew）**：数据分布不均导致部分节点负载过重 -- **跨节点通信**：节点间数据传输增加延迟 -- **复杂查询优化**：需精心设计数据分布策略 - -## Applications -- **数据仓库**：Amazon Redshift、Snowflake、Google BigQuery -- **大数据处理**：Apache Spark（Spark SQL）、Presto/Trino -- **科学计算**：分布式矩阵运算、基因组分析 - -## Related Concepts -- [[Columnar-Storage]]：列式存储与 MPP 协同优化分析查询 -- [[Distribution-Key]]：数据分布策略影响 MPP 性能 -- [[Sort-Key]]：排序键优化局部性，提升 MPP 节点内效率 diff --git a/wiki/concepts/MTTA.md b/wiki/concepts/MTTA.md deleted file mode 100644 index f7f1c019..00000000 --- a/wiki/concepts/MTTA.md +++ /dev/null @@ -1,71 +0,0 @@ -# MTTA (Mean Time to Acknowledge) - -## Definition -MTTA (Mean Time to Acknowledge) is the average time from when a problem is detected to when a team member actively begins working on resolving it. It measures the speed of human response after an alert is triggered. - -MTTA is a component of MTTR, sitting between MTTD and Mean Time to Repair. - -## Why MTTA Matters - -MTTA measures: -- On-call response effectiveness -- Alert severity and clarity -- Incident management process efficiency -- Team availability and readiness - -A short MTTA ensures that once a problem is detected, the recovery process begins promptly. - -## Across DevOps Maturity Levels - -| Maturity | Acknowledgment Capability | -|----------|--------------------------| -| Phase 1 | Long MTTA — unclear ownership, manual processes, reactive responses | -| Phase 2 | Improving — essential monitoring alerts team when issues affect users, ops staff manually intervene | -| Phase 3 | Better process — ops team adopts automation techniques, but monitoring unchanged | -| Phase 4 | Efficient acknowledgment — continuous monitoring with clear escalation paths, root cause analysis starts quickly | -| Phase 5 | Rapid — high collaboration, rapid data-driven decision-making, minimal customer interruptions | - -## Key Factors Affecting MTTA - -### On-Call Practices -- Clear on-call rotations -- Fast escalation policies -- Adequate staffing levels -- Compensation for on-call duty - -### Alert Quality -- Actionable alerts (not noise) -- Clear severity levels -- Sufficient context in alerts -- Pre-configured runbook links - -### Incident Response Process -- Clear ownership and accountability -- Pre-defined roles (incident commander, communications lead) -- Escalation procedures -- Communication channels - -## MTTA as Part of MTTR - -``` -MTTR = MTTD + MTTA + Mean Time to Repair -``` - -All three components must be optimized for minimal MTTR. Even with perfect MTTD (instant detection), a long MTTA will result in poor overall recovery times. - -## How to Improve MTTA -- Implement PagerDuty, Opsgenie, or similar incident management tools -- Create clear escalation policies -- Practice incident response with regular game days -- Improve alert quality to reduce noise and fatigue -- Ensure adequate on-call coverage -- Pre-build runbooks for common incidents - -## Sources -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] - -## Related Concepts -- [[concepts/MTTR]] -- [[concepts/MTTD]] -- [[concepts/DORA-Metrics]] -- [[concepts/DevOps-Maturity]] diff --git a/wiki/concepts/MTTD.md b/wiki/concepts/MTTD.md deleted file mode 100644 index 7bb86eee..00000000 --- a/wiki/concepts/MTTD.md +++ /dev/null @@ -1,66 +0,0 @@ -# MTTD (Mean Time to Detect) - -## Definition -MTTD (Mean Time to Detect) is the average time required to identify that a problem or failure has occurred in a system. It measures the effectiveness of monitoring, alerting, and observability practices. - -MTTD is a component of MTTR and represents the first phase of incident response. - -## Why MTTD Matters - -A short MTTD means: -- Failures are caught before they cascade into larger outages -- Customer impact is minimized -- The team can begin recovery faster -- Root cause analysis starts sooner - -Long MTTD means: -- Problems can escalate undetected -- User experience degrades for longer periods -- More customers are affected -- Root cause analysis becomes harder as the incident grows - -## Across DevOps Maturity Levels - -| Maturity | Detection Capability | -|----------|---------------------| -| Phase 1 | Long MTTD — outages reported by users, no proactive monitoring, reactive approach | -| Phase 2 | Better MTTD — essential monitoring tools alert teams as soon as issues affect users | -| Phase 3 | Improved detection — automated monitoring continues, security scans added earlier in pipeline | -| Phase 4 | Continuous monitoring — tracks system health for early problem detection and root cause analysis | -| Phase 5 | Minimal MTTD — max uptime with high collaboration and continuous monitoring, no customer interruptions | - -## Key Practices for Low MTTD - -### Monitoring & Alerting -- Comprehensive application performance monitoring (APM) -- Infrastructure monitoring -- Log aggregation and analysis -- Real-user monitoring (RUM) -- Synthetic monitoring - -### Alerting Best Practices -- Meaningful alert thresholds (avoid alert fatigue) -- Alert routing to appropriate on-call staff -- Clear alert context for rapid triage -- Correlation of related alerts - -### Observability -- Structured logging -- Distributed tracing -- Metrics dashboards -- Error tracking - -## MTTD vs Other Metrics -- **MTTR**: MTTD is a component of MTTR (MTTR = MTTD + MTTA + Mean Time to Repair) -- **Availability**: High availability depends partly on short MTTD -- **Change Failure Rate**: Fewer failures reaching production reduces MTTD pressure - -## Sources -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] - -## Related Concepts -- [[concepts/MTTR]] -- [[concepts/MTTA]] -- [[concepts/DORA-Metrics]] -- [[concepts/APM]] -- [[concepts/DevOps-Maturity]] diff --git a/wiki/concepts/MTTR.md b/wiki/concepts/MTTR.md deleted file mode 100644 index 806f2ca3..00000000 --- a/wiki/concepts/MTTR.md +++ /dev/null @@ -1,66 +0,0 @@ -# MTTR (Mean Time to Recovery) - -## Definition -MTTR (Mean Time to Recovery) is the average time required to recover from a failure — from the moment a failure is detected to the moment service is fully restored to normal operation. - -MTTR is one of the four core **DORA metrics** used to measure DevOps performance. - -## Key Components - -MTTR can be broken down into: -1. **MTTD (Mean Time to Detect)** — Average time to identify a problem -2. **MTTA (Mean Time to Acknowledge)** — Average time to acknowledge and begin addressing a problem -3. **Mean Time to Repair/Restore** — Actual time to fix and restore service -4. **MTTR = MTTD + MTTA + Mean Time to Repair** - -## Across DevOps Maturity Levels - -| Maturity | Detection & Recovery Capability | -|----------|--------------------------------| -| Phase 1 | Long MTTD and MTTR — outages reported by users (reactive), no proactive monitoring | -| Phase 2 | Better MTTD — essential monitoring tools alert teams when issues affect users | -| Phase 3 | Improved — security scans integrated earlier, but monitoring unchanged from Phase 2 | -| Phase 4 | Continuous monitoring tracks system health, enabling early detection and root cause analysis | -| Phase 5 | Max uptime — high collaboration, rapid data-driven decision-making, minimal customer interruptions | - -## MTTD and MTTA - -### MTTD (Mean Time to Detect) -- The average time to identify that a problem has occurred -- Lower is better — faster detection means faster recovery -- Requires: comprehensive monitoring, alerting, and observability - -### MTTA (Mean Time to Acknowledge) -- The average time from detection to someone actively working on the issue -- Includes time to notify on-call staff, triage, and begin investigation -- Requires: clear incident response processes and on-call coverage - -## Elite Performance Benchmark (DORA) -- **Elite performers**: MTTR < 1 hour -- Short MTTR indicates: - - Robust incident detection and alerting - - Clear incident response processes - - Well-practiced on-call procedures - - Effective automation for rollback and recovery - - Good observability and debugging tools - -## How to Reduce MTTR -- Implement comprehensive monitoring and alerting -- Practice chaos engineering and incident simulations -- Automate rollback procedures -- Use feature flags to isolate failures -- Maintain runbooks for common failures -- Foster blameless post-mortem culture -- Use observability tools for faster root cause analysis - -## Sources -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] -- [[sources/cloud-devop-maturity-guideline.md]] - -## Related Concepts -- [[concepts/DORA-Metrics]] -- [[concepts/MTTD]] -- [[concepts/MTTA]] -- [[concepts/Error-Budget]] -- [[concepts/Change-Failure-Rate]] -- [[concepts/DevOps-Maturity]] diff --git a/wiki/concepts/MVP.md b/wiki/concepts/MVP.md deleted file mode 100644 index 296fb72b..00000000 --- a/wiki/concepts/MVP.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "MVP" -type: concept -tags: [Product Development, Agile, Lean Startup] -sources: [devops-maturity-model-from-traditional-it-to-advanced-devops] -last_updated: 2026-04-26 ---- - -## 定义 - -MVP（Minimum Viable Product，最小可行产品）是指具有最小功能集的产品版本，仅包含核心功能足以满足早期用户需求并收集验证性反馈。 - -## 核心特征 - -- **最小功能集**：只实现解决核心问题所必需的最小功能 -- **快速验证**：尽早发布以获得真实用户反馈 -- **学习导向**：优先获取市场验证数据而非追求功能完备 -- **迭代演进**：基于反馈快速迭代改进 - -## 与 DevOps 成熟度的关系 - -在 DevOps 成熟度模型中，MVP 是 **Phase 4（高度优化阶段）** 的关键实践： - -> "Use of MVPs and management of tech debt to speed up releases." - -在该阶段，组织已建立成熟的 CI/CD 流水线，可以： -1. 快速构建和部署 MVP -2. 收集生产环境真实反馈 -3. 缩短从想法到验证的周期 -4. 降低大功能发布的风险 - -## MVP vs 完整产品 - -| 维度 | MVP | 完整产品 | -|------|-----|---------| -| 功能范围 | 最小核心功能 | 完整功能集 | -| 目标 | 验证假设 | 全面满足需求 | -| 发布时间 | 尽早发布 | 功能完备后发布 | -| 反馈来源 | 早期用户 | 广泛用户群 | -| 风险 | 低投入高学习 | 高投入风险大 | - -## 与相关概念的关系 - -- [[Agile]]：MVP 是敏捷开发的核心实践之一，支持快速迭代 -- [[Technical Debt]]：MVP 策略需要平衡快速交付与技术债务管理 -- [[DevOps Maturity Model]]：在 Phase 4 高度优化阶段，MVP 被用于加速发布周期 - -## 来源 -- [[devops-maturity-model-from-traditional-it-to-advanced-devops]] diff --git a/wiki/concepts/Mackinder-Heartland-Theory.md b/wiki/concepts/Mackinder-Heartland-Theory.md deleted file mode 100644 index 3edcb890..00000000 --- a/wiki/concepts/Mackinder-Heartland-Theory.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Mackinder Heartland Theory" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-25 ---- - -## 定义 -心脏地带理论（Heartland Theory）由 Sir [[Mackinder]] 于 1904 年提出，是地缘政治学的核心理论框架。 - -## 核心论点 -> "谁控制了东欧，谁就控制了心脏地带；谁控制了心脏地带，谁就控制了世界岛；谁控制了世界岛，谁就控制了世界。" - -- **心脏地带（Heartland）**：指欧亚大陆内部的中亚和东欧腹地 -- **世界岛（World Island）**：指整个欧亚大陆 -- **边缘地带（Rimland）**：环绕心脏地带的沿海地区 - -## 理论影响 -- 深刻影响了 20 世纪的地缘政治思维（纳粹德国、苏联的扩张战略均受其影响） -- 被 [[Spykman]] 修正：认为边缘地带才是关键，而非心脏地带 - -## 在 [[academic-geographer]] 中的应用 -该 Agent 将 Mackinder 理论用于分析虚拟世界中的地缘政治格局，评估： -- 地理咽喉要道（chokepoints） -- 可防御位置（defensible positions） -- 资源控制的地缘政治价值 - -## 来源 -- [[academic-geographer]] -- [[Mackinder]] diff --git a/wiki/concepts/Management-Pack.md b/wiki/concepts/Management-Pack.md deleted file mode 100644 index 9b217fe8..00000000 --- a/wiki/concepts/Management-Pack.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Management Pack -type: concept -tags: [Micro-Focus, OBM, Monitoring, Policy, AWS] -date: 2026-04-14 ---- - -## Definition -Management Pack（管理包）是 Micro Focus Operations Bridge Manager (OBM) 等企业监控平台的策略包机制，通过声明式配置定义监控目标、数据采集间隔、具体指标、阈值规则和数据源，实现云环境下规模化的统一监控策略管理。 - -## Core Properties -- **声明式配置**：以 Policy 形式定义监控规则，而非手动逐个配置 -- **自动化发现**：新增资源自动匹配 Policy，无需人工干预 -- **阈值驱动**：Policy 内置阈值配置，指标超出阈值自动触发事件 -- **跨平台抽象**：同一 Management Pack 框架可适配 AWS/Azure/GCP 等多云平台 -- **动态生效**：Policy 变更后自动推送到 Agent，无需重启服务 - -## How It Works (OBM AWS Management Pack) -1. **Policy 定义**：在 OBM 控制台创建 AWS Management Pack Policy，配置项包括： - - Role ARN（跨账户 IAM 角色） - - Account ID（被监控账户） - - Namespace/Service（监控的 AWS 服务，如 EC2/RDS/Lambda） - - Metrics（具体指标列表） - - Thresholds（阈值规则） - - Monitoring Frequency（采集频率） - - Title Format（告警标题格式，供服务台团队使用） -2. **Agent 执行**：Operation Agent 接收 Policy 后，按配置调用 CloudWatch API 采集数据 -3. **事件触发**：数据与阈值比对，超出阈值则生成事件并通过 SMACKS 触发工单 -4. **自动部署**：被监控账户新增实例时，Agent 自动识别并纳入监控范围 - -## Related Concepts -- [[Cloud-Monitoring]]：Management Pack 是云监控策略化管理的核心工具 -- [[IAM-Role]]：Management Pack 通过 IAM Role 实现跨账户安全访问 -- [[Cloud-Monitoring]]：Management Pack 解决了云环境动态监控的核心挑战 - -## References -- [[ctp-topic-8-obm-cloud-monitoring]]：AWS Management Pack 完整实操流程 diff --git a/wiki/concepts/MarkdownBasedTask.md b/wiki/concepts/MarkdownBasedTask.md deleted file mode 100644 index 40ae73e1..00000000 --- a/wiki/concepts/MarkdownBasedTask.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "MarkdownBasedTask" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-27 ---- - -## Aliases -- Markdown 任务 -- 语法型任务 -- Markdown 任务语法 -- checkbox task - -## Definition -MarkdownBasedTask（基于 Markdown 的任务管理）是指使用 Markdown 语法（`- [ ]`）来创建和管理任务，而非使用独立的图形化任务管理界面或应用程序。 - -## Key Characteristics -- 最小化语法：用 `- [ ] 任务内容` 即可创建任务，无需打开专用应用或填写表单 -- 内联元数据：日期、优先级、标签等元数据直接写在同一行，保持简洁 -- 跨工具兼容：Markdown 是纯文本，任何文本编辑器都能读取和处理 -- 版本控制友好：Markdown 文件可以纳入 Git 进行版本管理 -- 示例： - ``` - - [ ] 撰写公众号文章 📅 2025-03-03 🔼 #高优先级 - ``` - -## Trade-offs -- **优势**：极简语法、低门槛、可移植性强、与笔记天然整合 -- **劣势**：缺少独立任务应用的视觉化界面、通知推送、团队协作功能 - -## Connections -- [[ObsidianTasksPlugin]] ← uses ← [[MarkdownBasedTask]]（Tasks 插件基于 Markdown 语法） -- [[MarkdownBasedTask]] ← extends_with ← [[RecurringTask]]（可在 Markdown 任务中加入 ⏳ 周期指令） -- [[MarkdownBasedTask]] ← queried_by ← [[TaskQuerySyntax]]（查询语法专门解析 Markdown 任务） diff --git a/wiki/concepts/Marketing-Attribution.md b/wiki/concepts/Marketing-Attribution.md deleted file mode 100644 index 3d12464d..00000000 --- a/wiki/concepts/Marketing-Attribution.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: "Marketing Attribution" -type: concept -tags: [] -sources: [support-analytics-reporter] -last_updated: 2026-04-21 ---- - -## Aliases -- 营销归因模型 -- Multi-Touch Attribution（多触点归因） -- Attribution Modeling - -## Definition -Marketing Attribution（营销归因）是一种数据分析方法，用于将客户的转化收入或转化行为按照用户旅程中各触点（渠道/广告位/活动）的贡献权重进行分配，从而量化不同营销渠道的真实价值，指导预算优化和 ROI 最大化。 - -## Attribution Models - -### 1. Single-Touch（单触点归因） -| 模型 | 归因逻辑 | 优点 | 缺点 | -|------|---------|------|------| -| First Touch | 100% 归因给首个触点 | 识别获客渠道 | 忽视转化路径上的其他渠道 | -| Last Touch | 100% 归因给末触点 | 识别转化触点 | 忽视品牌建设类触点 | - -### 2. Multi-Touch（多触点归因） -| 模型 | 归因逻辑 | 适用场景 | -|------|---------|---------| -| Linear | 平均分配权重 | 各触点均等重要 | -| Time Decay | 越接近转化时间权重越高 | 短转化周期（B2C电商） | -| Position Based (U-Shaped) | 首+末各 40%，中间均分剩余 20% | 品牌+效果兼顾 | -| Data-Driven | 基于 Shapley 值或机器学习模型 | 有足够转化数据支撑 | - -### 3. Algorithmic Attribution（算法归因） -基于 Shapley 值（博弈论）或 logistic 回归/马尔可夫链模型，从数据中自动学习各触点权重，是最精确但数据需求量最大的方案。 - -## Multi-Touch Attribution Implementation - -```sql --- Multi-touch attribution with first/last/intermediate weights -WITH customer_touchpoints AS ( - SELECT - customer_id, - channel, - campaign, - touchpoint_date, - conversion_date, - revenue, - ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY touchpoint_date) as touch_sequence, - COUNT(*) OVER (PARTITION BY customer_id) as total_touches - FROM marketing_touchpoints mt - JOIN conversions c ON mt.customer_id = c.customer_id - WHERE touchpoint_date <= conversion_date -), -attribution_weights AS ( - SELECT *, - CASE - WHEN touch_sequence = 1 AND total_touches = 1 THEN 1.0 -- Single touch - WHEN touch_sequence = 1 THEN 0.4 -- First touch - WHEN touch_sequence = total_touches THEN 0.4 -- Last touch - ELSE 0.2 / (total_touches - 2) -- Middle touches - END as attribution_weight - FROM customer_touchpoints -) -SELECT - channel, - campaign, - SUM(revenue * attribution_weight) as attributed_revenue, - COUNT(DISTINCT customer_id) as attributed_conversions -FROM attribution_weights -GROUP BY channel, campaign -ORDER BY attributed_revenue DESC; -``` - -## Campaign ROI Calculation - -```sql -SELECT - campaign_name, - SUM(spend) as total_spend, - SUM(attributed_revenue) as total_revenue, - (SUM(attributed_revenue) - SUM(spend)) / SUM(spend) * 100 as roi_percentage, - SUM(attributed_revenue) / SUM(spend) as revenue_multiple, - COUNT(conversions) as total_conversions, - SUM(spend) / COUNT(conversions) as cost_per_conversion -FROM campaign_performance -GROUP BY campaign_name -ORDER BY roi_percentage DESC; -``` - -## Key Metrics - -| 指标 | 公式 | 业务含义 | -|------|------|---------| -| ROI | (归因收入 - 花费) / 花费 × 100% | 渠道盈利性 | -| ROAS | 归因收入 / 广告花费 | 广告效率 | -| CPA | 总花费 / 归因转化数 | 获客成本 | -| Revenue Multiple | 归因收入 / 花费 | 收入倍数 | - -## Connections -- [[support-analytics-reporter]] — 使用多触点归因模型进行营销效果分析 -- [[Marketing-ROI]] — 归因分析是 ROI 计算的基础 -- [[Business-Intelligence]] — 属 BI 领域的营销分析子方向 diff --git a/wiki/concepts/Marp.md b/wiki/concepts/Marp.md deleted file mode 100644 index 3cb95d7e..00000000 --- a/wiki/concepts/Marp.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Marp" -type: concept -tags: [tool, obsidian, plugin, slides, presentation] -sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环] -last_updated: 2026-04-20 ---- - -## Aliases -- Marp Slides -- Marp 幻灯片 -- Marp for VS Code / Obsidian - -## Definition -基于 Markdown 的幻灯片格式，在 Obsidian 里安装 Marp Slides 插件即可直接预览和导出 PDF/HTML/PPTX。LLM Wiki 的可选增强工具。 - -## Usage -在 Markdown 文件开头加上 `marp: true`，用 `---` 分隔每页幻灯片，写完直接在 Obsidian 里预览。 - -## LLM Wiki Use Case -让 AI 从 Wiki 的某个主题页面直接生成 Marp 格式的幻灯片草稿，微调后即可使用。 - -## Practical Value -- 老张（[[laozhang2579]]）观点："实用价值老张保留意见" -- 适合需要定期做演示的用户，非 LLM Wiki 的核心组件 - -## Connections -- [[Marp]] ← 可选增强 → [[LLM Wiki]] -- [[Marp]] ← 插件 → [[Obsidian]] diff --git a/wiki/concepts/Mass-Entity.md b/wiki/concepts/Mass-Entity.md deleted file mode 100644 index a4ed58ad..00000000 --- a/wiki/concepts/Mass-Entity.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Mass Entity" -type: concept -tags: ["unreal-engine", "ecs", "simulation", "crowd", "performance"] -sources: ["unreal-systems-engineer"] -last_updated: 2026-05-30 ---- - -## Aliases -- Unreal Entity Component System -- Mass Framework -- UE5 ECS - -## 定义 -Mass Entity 是 Unreal Engine 的 ECS（Entity Component System）实现，通过 `UMassEntitySubsystem` 处理海量 NPC、投射物或人群代理的模拟，以原生 CPU 性能运行。 - -## 核心架构 - -### FMassFragment（数据组件） -每个实体的数据层——存储 per-entity 数据（如位置、速度、生命值）。 - -### FMassTag（标记组件） -布尔标记——用于标识实体类型或状态（如 `FMassCharacterLargeLODTag`）。 - -### Mass Processors -操作 fragments 的并行处理器——使用 Unreal 任务图并行执行。 - -### UMassRepresentationSubsystem -连接 Mass 模拟和 Actor 可视化的桥梁： -- 将 Mass 实体显示为 LOD 切换的 Actor（Hierarchical LOD） -- 或显示为 Instance Static Mesh（ISM）以优化渲染 - -## 使用场景 -- 海量 NPC 群体模拟 -- 密集投射物系统 -- 人群代理 -- 任何需要处理成千上万实体的性能敏感场景 - -## 相关概念 -- [[Actor Replication]] — Mass 实体与网络复制的关系 -- [[UnrealEngine5]] — Mass Entity 是 UE5 内置框架 diff --git a/wiki/concepts/Material-Culture.md b/wiki/concepts/Material-Culture.md deleted file mode 100644 index 57897344..00000000 --- a/wiki/concepts/Material-Culture.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Material Culture" -type: concept -tags: [historiography, methodology, anthropology] -sources: [academic-historian, academic-anthropologist] -last_updated: 2026-04-30 ---- - -## Definition -物质文化（Material Culture）指人类社会所创造和使用的一切物质产品及其承载的社会意义——包括但不限于工具、服饰、建筑、器物、武器、货币、书写材料等。物质文化研究通过分析物质遗存（器物、图像、遗址）和文献记载，重建过去人们的生活方式、思想观念和社会结构。 - -## Key Features -- **核心方法**：考古学与历史文献的交叉分析——物质遗存 + 文字记载 -- **研究维度**： - - 器物形制与制作工艺（技术史） - - 物质流通与消费模式（经济史） - - 物质文化的象征意义（符号分析） - - 物质与身份认同（谁使用什么、谁被排斥在外） -- **代表学者**：朱尔斯·亨利（Julius Schlosser）、皮埃尔·布尔迪厄（Pierre Bourdieu，实践理论） -- **Annales 学派视角**：布罗代尔强调"物质生活"（la vie matérielle）是历史的第一层——地理环境、物质条件、经济发展构成历史的基础层 - -## Relationship to Other Concepts -- [[Annales-School]] ← 理论基础 ← [[Material-Culture]]：年鉴学派将物质文化作为历史分析的第一层（日常生活史） -- [[academic-anthropologist]] ← 使用 ← [[Material-Culture]]：文化人类学家同样关注物质文化的象征意义和社会功能 -- [[academic-historian]] ← 核心方法 ← [[Material-Culture]]：Historian Agent 五步工作流中"检查物质基础"的直接方法论来源 -- [[Geographic-Coherence]] ← 关联 ← [[Material-Culture]]：物质文化受地理环境制约（原材料、可及性、贸易路线） - -## Relationship to Source Pages -- [[academic-historian]]：文档"🎯 Core Mission - Enrich with Material Culture"节专门论述，明确要求关注"饮食、服饰、建筑、贸易、信仰、恐惧" -- [[academic-anthropologist]]：文档同样将物质文化作为文化自洽设计的核心维度 - -## Aliases -- 物质文化 -- Material Culture Studies diff --git a/wiki/concepts/MaterialFunction.md b/wiki/concepts/MaterialFunction.md deleted file mode 100644 index 1a1bccbb..00000000 --- a/wiki/concepts/MaterialFunction.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "MaterialFunction" -type: concept -tags: ["unreal-engine", "materials", "shader"] -sources: ["unreal-technical-artist"] -last_updated: 2026-04-26 ---- - -## Definition -UE5 Material Editor 中可封装、可复用的节点逻辑单元。封装一组节点图作为黑盒函数，供多个 Master Material 引用。 - -## Purpose -消除跨 Master Material 的重复节点簇，确保同一逻辑只需维护一处。 - -## Usage in This Wiki -- [[unreal-technical-artist]] 强制规定：所有可复用逻辑必须封装为 Material Function，禁止在多个 Master Material 间重复节点簇 -- 示例：MF_TriplanarMapping（三平面映射）封装 WorldPosition 投影逻辑，可在任意岩石、悬崖、地形混合材质中使用 - -## Key Principles -- 单一职责：一个 Function 只做一件事（三平面映射 / 噪声叠加 / 顶点偏移等） -- 输入输出清晰：所有可调参数通过 Input 节点暴露 -- 禁止副作用：Function 内部不应修改外部状态 -- 避免 Static Switch 嵌套：每个 Static Switch 使引用该 Function 的材质排列数翻倍 - -## Related -- [[MaterialEditor]] — Material Function 的创作环境 -- [[QualitySwitch]] — 同一材质内的质量分层机制 -- [[NiagaraVFX]] — VFX 系统，类似 Function 的模块化复用理念 diff --git a/wiki/concepts/Meaning-Transfer-Translation.md b/wiki/concepts/Meaning-Transfer-Translation.md deleted file mode 100644 index ff71f3c7..00000000 --- a/wiki/concepts/Meaning-Transfer-Translation.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Meaning Transfer Translation" -type: concept -tags: ["translation", "linguistics", "language", "ai-agent", "nlp"] -last_updated: 2026-05-02 ---- - -## Definition - -**Meaning Transfer Translation**（意义转移翻译）是一种超越逐字替换的翻译方法论，核心理念：**翻译 = 传递意义，而非替换词汇**。目标不是字典输出，而是让目标语言接收者能实际理解和响应。 - -## Core Principle - -> "Translation isn't word-for-word substitution — it's meaning transfer." — Language Translator Agent - -## Examples - -| 英文（源） | 字面翻译（错误） | 意义转移（正确） | 说明 | -|---|---|---|---| -| It's raining cats and dogs. | Está lloviendo gatos y perros | Está lloviendo a cántaros | 西班牙语中"倾盆大雨"的自然表达 | -| Break a leg! | Rompe una pierna | ¡Buena suerte! | 祝好运的习语，字面翻译令人困惑 | -| ¿Mande? (墨西哥) | "Mande?" | "Pardon?" | 墨西哥西班牙语中"请问有什么事？"的礼貌表达 | - -## In AI Agent Context - -在 [[Language Translator]] Agent 中的实现： -1. 识别源语言中的惯用语、成语、俚语 -2. 在目标语言中寻找自然等效表达（不等同于字面对应） -3. 匹配语气：讽刺、热情、紧急、礼貌必须完整传递 -4. 验证输出对母语者是否自然流畅 - -## Related Concepts -- [[Register Switching]]：意义转移需匹配正确语域 -- [[Subjunctive Mood]]：西班牙语虚拟式是意义传递的关键语法手段 -- [[False Cognates]]：意义转移需警惕假同源词陷阱 - -## Sources -- [[language-translator]] diff --git a/wiki/concepts/Medallion-Architecture.md b/wiki/concepts/Medallion-Architecture.md deleted file mode 100644 index f68a1b83..00000000 --- a/wiki/concepts/Medallion-Architecture.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: "Medallion Architecture" -type: concept -tags: [data-engineering, lakehouse, architecture] -sources: [engineering-data-engineer] -last_updated: 2026-05-02 ---- - -## Definition - -Medallion Architecture 是一种数据湖仓（Lakehouse）分层架构，通过 Bronze（青铜）→ Silver（白银）→ Gold（黄金）三层设计，实现数据从原始到业务就绪的渐进式提升。 - -## Three Layers - -### Bronze Layer（原始层） -- **特性**：原始、不可变、追加写入（append-only） -- **规则**：永远不在原地转换数据；保留完整的 source file、ingestion timestamp、source system 元数据 -- **Schema**：Schema-on-Read（读取时推断） -- **分区策略**：按 ingestion date 分区，支持低成本历史重放 - -### Silver Layer（清洗层） -- **特性**：已清洗、去重、统一格式（conformed） -- **规则**：必须可跨域 join；显式处理 null（impute/flag/reject）；标准化数据类型、日期格式、货币码、国家码 -- **实现**：SCD Type 2 追踪历史变更；主键 + 事件时间戳去重 -- **质量**：每字段 null 处理规则必须明确记录 - -### Gold Layer（业务层） -- **特性**：业务就绪、SLA 保证、为查询模式优化 -- **规则**：Gold 层消费者禁止直接读取 Bronze 或 Silver；必须附带行级数据质量评分；使用 replaceWhere 原子覆盖 -- **优化**：Z-Ordering 多维聚类、分区裁剪、预聚合 -- **SLA**：明确刷新频率（如"每 15 分钟刷新一次"） - -## Core Principles - -- **不可变性**：Bronze 层不可覆盖，每条记录携带 `_ingested_at` 和 `_source_system` -- **渐进式质量**：数据质量在 Bronze→Silver→Gold 每层逐步提升 -- **消费者保护**：上游 schema 变化通过 `mergeSchema=true` 捕获，但不自动污染下游 -- **幂等性**：Silver→Gold 每步管道必须幂等——重新运行不产生重复 - -## Related Concepts -- [[CDC (Change Data Capture)]] -- [[Data Contract]] -- [[Data Lineage]] -- [[SCD Type 2]] - -## Related Entities -- [[Delta Lake]]（Bronze/Silver/Gold 存储格式） -- [[Apache Spark]]（计算引擎） -- [[Databricks]]（托管平台） -- [[Apache Iceberg]]（开放表格格式替代方案） diff --git a/wiki/concepts/Medical-Advertisement-Review.md b/wiki/concepts/Medical-Advertisement-Review.md deleted file mode 100644 index d3fb83cf..00000000 --- a/wiki/concepts/Medical-Advertisement-Review.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Medical Advertisement Review（医疗广告审查制度）" -type: concept -tags: [healthcare, compliance, advertising, china] -sources: [healthcare-marketing-compliance] -last_updated: 2026-04-25 ---- - -## Definition -医疗广告审查制度是中国对医疗广告实施的前置审批管理——医疗广告必须经省级卫生行政部门审查并取得《医疗广告审查证明》后方可发布。该制度是医疗广告合规的基石，违反将面临行政处罚乃至刑事追责。 - -## Core Requirements -- **审查主体**：省级卫生行政部门 -- **审查对象**：医疗广告（涵盖医疗机构、医疗服务、医疗产品等） -- **证书名称**：《医疗广告审查证明》 -- **有效期**：通常为1年 -- **内容限制**：广告内容不得超出审查批准范围；内容修改须重新申请审查 - -## Key Legal Basis -- 《广告法》第46条：医疗、药品、医疗器械广告等依法须经审查的广告，广告主应当在发布前委托广告审查机关对广告内容进行审查 -- 《医疗广告管理办法》：医疗广告内容标准、审查程序、发布规则、违规处罚 - -## Three Content Categories -| 类别 | 审查要求 | 发布渠道 | -|------|----------|----------| -| 医疗广告 | 必须取得《医疗广告审查证明》 | 经审查批准渠道 | -| 药品广告 | 必须取得药品广告批准文号 | 非处方药可经大众媒体；处方药仅限专业期刊 | -| 医疗器械广告 | 必须取得医疗器械广告批准文号 | 依类别分级管理 | - -## Prohibited Expressions（通用红线） -- 绝对化表述："最佳疗效""完全治愈""100%有效" -- 保证承诺："无效退款""保证治愈""一次见效" -- 诱导性语言："免费治疗""限时优惠""不治疗会恶化" -- 患者推荐/见证：患者疗效推荐/证言 -- 功效比较：与其他药品或医疗机构的效果比较 - -## Relationship to Healthcare Marketing Compliance -医疗广告审查是 [[Healthcare-Marketing-Compliance]] 的核心前置环节。企业必须先取得相应审查证书，方可开展后续的合规营销活动。 diff --git a/wiki/concepts/MeetingNotes.md b/wiki/concepts/MeetingNotes.md deleted file mode 100644 index 21bea6bb..00000000 --- a/wiki/concepts/MeetingNotes.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "MeetingNotes" -type: concept -tags: [] -last_updated: 2026-04-22 ---- - -# MeetingNotes - -AI Agent 自动将会议录音/转录文本转换为结构化会议记录的工作流模式。包括摘要提取、关键决策识别、行动项抽取、任务创建和团队通知等环节。 - -## Definition - -MeetingNotes 是一种 AI Agent 工作流，核心目标是消除"会议结束"到"任务追踪"之间的 Gap。传统流程中，会议记录需要人工整理（耗时 20+ 分钟），行动项容易被遗忘。该模式通过 AI 自动化实现： -1. 监听会议转录文本来源（Otter.ai、Google Meet、Zoom） -2. 提取关键决策和行动项（包含负责人和截止日） -3. 自动在项目管理工具创建任务（Jira/Linear/Todoist/Notion） -4. 发送摘要到团队频道（Slack/Discord） -5. 截止日前自动提醒负责人 - -## Core Insight - -> "Meeting notes that don't become tracked tasks are just documentation theater." -> — 真正有价值的不是摘要本身，而是**自动任务创建** - -## Related Concepts -- [[ActionItemTracking]] — 行动项追踪 -- [[TaskAutomation]] — 任务自动化 -- [[TranscriptProcessing]] — 转录文本处理 - -## Related Sources -- [[meeting-notes-action-items]] diff --git a/wiki/concepts/Memory-Backend.md b/wiki/concepts/Memory-Backend.md deleted file mode 100644 index 5ebd5710..00000000 --- a/wiki/concepts/Memory-Backend.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Memory-Backend" -type: concept -tags: [AI-Memory, Memory-Backend, Vector-DB, Fact-Recall] -sources: [ai-memory-tools-two-camps] -last_updated: 2026-04-15 ---- - -## Definition -AI 记忆工具的 Camp 1 范式。从对话中提取事实并存储到向量数据库（或图数据库），检索相关事实并注入下一轮对话。问的核心问题是"**AI 应该记住什么？**" - -## Core Loop -1. 对话发生（conversation happens） -2. 系统提取事实或存储内容（extract facts / store content） -3. 事实进入数据库（向量、图或两者） -4. 下一对话，相关事实被检索并注入 - -## Optimization Goal -**召回精度（recall）**——系统能否找到正确的事实？ - -## Representative Tools -- [[Mem0]]：53.1k stars，类别领导者，四操作 API -- [[MemPalace]]：46.2k stars，本地优先，逐字记忆，96.6% 召回率 -- [[Supermemory]]：21.8k stars，时间感知，自动覆盖过期事实 -- [[Honcho]]：2.4k stars，对等体模型，心理洞察 - -## Common Characteristics -- 从对话中提取"事实"（fact extraction） -- 存储在向量/图数据库 -- 检索时注入上下文 -- 人类不直接与记忆交互 -- 信任系统记住正确的事并在正确时间检索 - -## Limitations -- 记忆是扁平条目，条目间无关系 -- 每次提取需 LLM 调用，质量依赖提取提示词 -- 存储后不演进，无法处理新旧事实冲突 -- 无法支撑持续、多会话、多项目的 Agent 运行 - -## Connections -- [[Context-Substrate]] ← 对立阵营 ← Memory-Backend -- [[Mem0]] ← 属于 ← Memory-Backend -- [[MemPalace]] ← 属于 ← Memory-Backend -- [[Supermemory]] ← 属于 ← Memory-Backend -- [[Honcho]] ← 属于 ← Memory-Backend -- [[ai-memory-tools-two-camps]] ← 来源 ← Memory-Backend 是 @witcheer 提出的分类框架中的 Camp 1 diff --git a/wiki/concepts/Memory-Based-Handoff.md b/wiki/concepts/Memory-Based-Handoff.md deleted file mode 100644 index 0c07b2fe..00000000 --- a/wiki/concepts/Memory-Based-Handoff.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Memory-Based Handoff" -type: concept -tags: [multi-agent, memory, handoff, workflow] -last_updated: 2026-04-26 ---- - -## Definition - -一种多 Agent 协作中的交接模式，通过外部记忆服务器（而非人工复制粘贴）实现 Agent 间的上下文传递。当一个 Agent 完成工作时，将交付物存储到共享记忆服务器；下一个 Agent 通过 recall 操作自动检索所需上下文，无需人工干预。 - -## Core Mechanism - -1. **存储（remember）**：Agent 完成任务后，将交付物快照存入记忆服务器，带上项目标签（如 `retroboard`）和接收方标签（如 `frontend-developer`） -2. **召回（recall）**：下一个 Agent 激活时，通过 recall 操作按标签检索历史记忆，自动获取上一个 Agent 的交付物 -3. **无需人工粘贴**：人类不再充当"粘合剂"，记忆服务器接管上下文传递 - -## Aliases -- Memory-Based Handoff -- MCP Memory Handoff - -## Related Patterns - -- [[Sequential Handoff]]：前身模式——必须人工复制粘贴完整输出，Memory-Based Handoff 将其升级为自动召回 -- [[Memory-Based Handoff]] ← enabled_by ← [[MCP Memory Server]] - -## Source -- [[workflow-with-memory]]：完整工作流文档，包含 4 周 MVP 场景下的 Memory-Based Handoff 实践 diff --git a/wiki/concepts/Memory-Consolidation.md b/wiki/concepts/Memory-Consolidation.md deleted file mode 100644 index d139a7bc..00000000 --- a/wiki/concepts/Memory-Consolidation.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Memory Consolidation" -type: concept -tags: - - "agentic-ai" - - "memory-management" - - "long-horizon" -sources: - - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog" -last_updated: 2026-04-20 ---- - -## Overview -Memory Consolidation——Agent 空闲时周期性压缩累积工作日志（去重 + 解决矛盾 + 写入精简状态文件）的机制，防止长期运行 Agent 的记忆膨胀和决策冲突。 - -## Problem -随着 Agent 长时间运行，记忆日志变得臃肿且矛盾——旧决策与新决策冲突，冗余条目在每次读取时浪费 token。 - -## Solution -自动化压缩周期：Agent 空闲时（任务之间或低优先级窗口），触发后台作业： -1. 读取原始日志 -2. 去重条目 -3. 以最新数据为准解决矛盾 -4. 写入干净、压缩的状态文件 - -## Empirical Result -实测案例：32K token 嘈杂、重复历史 → 压缩为 7K token 干净状态文件，无有意义信息丢失。 - -## Implementation -```python -# When agent is idle (between tasks or during low-priority windows) -def consolidate_memory(raw_logs): - deduped = deduplicate(raw_logs) - resolved = resolve_conflicts(deduped, prefer='latest') - compressed = compress(resolved) - write_state_file(compressed) -``` - -## Relationship to Other Concepts -- [[Agent-Collapse]]：Memory Consolidation 防止状态臃肿导致的决策质量下降 -- [[State-Externalization]]：压缩后的状态以结构化文件形式持久化 -- [[Context-Reset]]：Context Reset 解决当前上下文容量问题，Memory Consolidation 解决长期记忆质量问题——两者互补 - -## Source -- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]] diff --git a/wiki/concepts/MemoryInAIAgents.md b/wiki/concepts/MemoryInAIAgents.md deleted file mode 100644 index e55a41c6..00000000 --- a/wiki/concepts/MemoryInAIAgents.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Memory in AI Agents" -type: concept -tags: [ai, agent, context, llm, memory] -sources: [] -last_updated: 2025-05-09 ---- - -## Aliases -- AI Agent Memory -- 对话记忆 -- 上下文保留 -- Context Retention - -## Definition -在 AI Agent 中嵌入的上下文保留机制，通过在多轮对话中存储和检索历史信息，使 Agent 能够理解会话的完整语境，从而生成连贯、相关且符合上下文的响应。没有 Memory 的 Agent 每次交互都是孤立的，无法利用前序对话中的关键信息。 - -## Why It Matters -- **连贯性**：用户无需在每轮对话中重复已提供的背景信息 -- **个性化**：Agent 记住用户的偏好、之前的任务状态和关键事实 -- **效率**：避免用户反复解释相同的需求或约束 -- **真实性**：使对话更接近人与人之间的自然交流 - -## Implementation Patterns -- **短期记忆（Short-term）**：单次会话内的上下文窗口管理 -- **长期记忆（Long-term）**：跨会话持久化用户偏好、项目状态等 -- **向量检索**：将历史交互转为 embedding，通过相似度搜索召回相关信息 -- **摘要压缩**：定期将长对话摘要化，减少 token 消耗 - -## Related Concepts -- [[Agentic System]]：Memory 是 Agentic System 的核心组件之一 -- [[Tool Integration]]：Memory 与工具调用结合使 Agent 能够访问持久化状态 - -## Related Entities -- [[OpenClaw]]：强调持久记忆的多 Agent 系统 -- [[n8n]]：通过 Memory 节点支持对话上下文保留 - -## Sources -- [[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]] -- [[养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录]] diff --git a/wiki/concepts/MentalModel.md b/wiki/concepts/MentalModel.md deleted file mode 100644 index b8fc6d1b..00000000 --- a/wiki/concepts/MentalModel.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "MentalModel" -type: concept -tags: [] -last_updated: 2026-05-02 ---- - -## Definition - -Mental Model（心智模型）是开发者对代码库结构、工作原理和边界的内在理解。准确的代码库心智模型能够支持开发者快速定位问题、预测变更影响、进行有效的代码审查。 - -## Building a Codebase Mental Model - -### Three-Tier Explanation Structure - -1. **One-line statement** — 一句话描述代码库是什么 -2. **Five-minute overview** — 五分钟高层解释：任务、输入、输出、关键文件、主代码路径 -3. **Deep dive** — 深度分析：类型、运行时、入口点、结构表、关键边界、详细代码流 - -### Key Components - -- **Top-level structure**: 目录结构和职责划分 -- **Entry points**: 启动文件、路由、配置 -- **Data flow**: 输入如何流转、处理、输出 -- **Key boundaries**: 展示层 / 应用层 / 持久层的边界 -- **Ownership map**: 每个文件/模块负责什么 - -## Metrics for Good Mental Model - -- 新开发者 5 分钟内能识别主入口点 -- 能正确预测代码变更的影响范围 -- 能准确描述跨模块的数据流 - -## Related Concepts - -- [[CodebaseOnboarding]] — 代码库 onboarding 方法论 -- [[ExecutionTracing]] — 执行路径追踪 -- [[EvidenceFirstReasoning]] — 证据优先推理 diff --git a/wiki/concepts/Merge-Point.md b/wiki/concepts/Merge-Point.md deleted file mode 100644 index e02ff40b..00000000 --- a/wiki/concepts/Merge-Point.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Merge Point" -type: concept -tags: [multi-agent, workflow-pattern, dependency-management] -last_updated: 2026-04-25 ---- - -## Definition - -工作流中的特定节点——多个并行分支的输出在此处合并，触发下一阶段的执行。所有上游分支必须在此点完成。 - -## Core Principle - -下游 Agent 明确声明其所需的**上游输出集合**，只有当全部上游输出就绪后，才开始工作。这是 Multi-Agent 协作中的关键依赖管理机制。 - -## Usage in The Agency - -- [[workflow-landing-page]]：**Frontend Developer** 的合并点是 `Content Creator 输出 + UI Designer 输出`。两者未完成之前，Frontend Developer 无法开始。 -- [[workflow-startup-mvp]]：**Build Phase** 是合并点，需要 API Spec（Backend Architect）+ UI Spec（UI Designer）+ 增长计划（Growth Hacker）全部就绪 -- [[scenario-enterprise-feature]]：**Integration Phase** 需要 Backend 输出 + Frontend 输出 + QA 测试计划全部合并 - -## Anti-Pattern - -不要将合并点设计为"等待最慢的一个"——应该在设计阶段就估算各分支的执行时间，必要时： -- 对快速分支添加有价值的额外任务（如性能基准测试） -- 对慢速分支进行拆分加速 -- 将非关键输出从合并点移除 - -## Aliases -- Convergence Point -- Synchronization Barrier -- Handoff Point diff --git a/wiki/concepts/Mermaid.md b/wiki/concepts/Mermaid.md deleted file mode 100644 index 4590fe84..00000000 --- a/wiki/concepts/Mermaid.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: "Mermaid" -type: concept -tags: [图表, 文本绘图, 产品经理, 文档工具] -sources: [不会gemini的产品经理真的要被淘汰了-附保姆级prd生成指南] -last_updated: 2025-12-18 ---- - -## Aliases -- Mermaid.js -- Mermaid 图表 - -## Definition - -**Mermaid** 是一种基于文本描述生成图表的标记语言，通过简单的代码语法描述图表结构，由 JSeqTeam 开发维护。支持 ER 图、时序图、甘特图、流程图、状态图等多种图表类型。 - -## 核心优势 - -1. **文本可存储**：图表以文本形式存储，便于 Git 版本管理 -2. **AI 友好**：大模型可以直接生成 Mermaid 代码，无需图形界面操作 -3. **多工具支持**：飞书文档（输入 `/mermaid`）、Typora、GitHub README 等均支持渲染 - -## 常用图表类型 - -|| 图表类型 | 用途 | Mermaid 关键字 | -||---------|------|---------------| -|| ER图 | 描述实体、属性、数据表关系 | `erDiagram` | -|| 时序图 | 描述角色/模块间交互顺序 | `sequenceDiagram` | -|| 甘特图 | 描述项目时间计划和里程碑 | `gantt` | -|| 流程图 | 描述线性/分支流程 | `flowchart` | -|| 状态机图 | 描述状态转换逻辑 | `stateDiagram` | -|| 类图 | 描述面向对象类结构 | `classDiagram` | - -## 在 PRD 工作流中的应用 - -``` -FeatureList 定义数据结构 - ↓ -要求 Gemini 生成 Mermaid ER图代码 - ↓ -复制代码到飞书文档（/mermaid → 文本画图组件） - ↓ -实时预览可视化图表 -``` - -``` -工作流描述 - ↓ -要求 Gemini 生成 Mermaid 时序图代码 - ↓ -同样方式预览 -``` - -## 常见问题 - -- **理解偏差**：大模型对图表类型名称（如"泳道图"）的理解可能与标准术语不同 -- **解决方式**：提供一段能正确生成期望效果的 Mermaid 代码示例，大模型会快速学会 -- **飞书报错**：Mermaid 在部分平台支持度不同，飞书支持较好 - -## Connections -- [[PRD生成工作流]] ← 使用工具 ← [[Mermaid]] -- [[FeatureList]] ← 协同工具 ← [[Mermaid]] -- [[14种UML图]] ← 上位概念 ← [[Mermaid]] -- [[不会gemini的产品经理真的要被淘汰了-附保姆级prd生成指南]] ← 来源 ← [[Mermaid]] diff --git a/wiki/concepts/MessageMatch.md b/wiki/concepts/MessageMatch.md deleted file mode 100644 index 01ea47f4..00000000 --- a/wiki/concepts/MessageMatch.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: "Message Match" -type: concept -tags: ["landing-page", "quality-score", "conversion", "ux"] ---- - -## Definition - -Message Match（消息匹配）衡量广告创意与落地页内容之间的一致性程度，直接影响质量得分（Quality Score）、跳出率和转化率。 - -## Why Message Match Matters - -| 维度 | 高匹配 | 低匹配 | -|------|--------|--------| -| 质量得分 | +2-4 分 | -2-4 分 | -| 跳出率 | 30-50% | 70-90% | -| 转化率 | 基准+20-50% | 基准-50%+ | -| CPA | 降低 15-30% | 增加 50%+ | -| 用户信任 | 建立 | 破坏 | - -## Message Match Score - -Google Ads 评估维度： - -1. **语义相关性**：关键词与落地页主题的匹配度 -2. **视觉一致性**：广告风格与落地页设计的连贯性 -3. **承诺-兑现一致性**：广告中的承诺在落地页得到兑现 - -## Optimization Framework - -### Level 1: Keyword → Ad Copy → Landing Page - -``` -Search Query → Keyword → Ad Headline → Landing Page Headline - ↓ ↓ ↓ ↓ - 用户意图 关键词主题 广告承诺 首屏回应 -``` - -### Level 2: Content Continuity - -| 广告层级 | 落地页对应 | -|---------|-----------| -| 标题 | H1 标题一致 | -| 描述卖点 | 首屏产品特性 | -| 价格/促销 | CTA 区域优惠 | -| CTA 按钮 | 按钮文字一致 | - -### Level 3: UX Flow - -- 加载速度：3 秒内首屏内容出现 -- 视觉层次：用户第一眼看到核心价值 -- 导航清晰：轻松找到广告承诺的内容 -- 移动适配：手机端体验流畅 - -## Checklist - -- [ ] 落地页 H1 与广告核心标题关键词一致 -- [ ] 广告承诺的核心利益在首屏可见 -- [ ] CTA 按钮文字与广告 CTA 呼应 -- [ ] 页面加载速度 < 3 秒 -- [ ] 移动端体验流畅 -- [ ] 无误导性内容（用户期望与实际不符） -- [ ] 价格/促销信息与广告一致 - -## Measurement - -- **Quality Score**：Google 综合评分，Message Match 是核心因子 -- **Bounce Rate**：跳出率 > 70% 提示 Message Match 问题 -- **Time on Page**：低停留时间提示内容不匹配 -- **Conversion Rate**：低转化率可能因 Message Match 断裂 - -## Sources - -- [[paid-media-creative-strategist]] diff --git a/wiki/concepts/Metrics-Server.md b/wiki/concepts/Metrics-Server.md deleted file mode 100644 index b4000ba8..00000000 --- a/wiki/concepts/Metrics-Server.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Metrics Server" -type: concept -tags: - - Kubernetes - - EKS - - Metrics - - Monitoring - - Autoscaling -sources: - - ctp-topic-64-scaling-out-with-amazon-eks -last_updated: 2026-04-28 ---- - -## Definition -Metrics Server 是 Kubernetes 集群级别的指标采集组件（Metrics API Provider），负责从 kubelet 收集 CPU/内存等资源使用指标，为 HPA、VPA 和 `kubectl top` 命令提供标准化的指标数据。 - -## Key Mechanisms -- **Metrics API**：实现 `metrics.k8s.io` API，提供 Pod 和 Node 的资源指标 -- **数据采集**：定期从各节点的 kubelet 获取指标数据 -- **内存高效**：采用流式处理，仅保留最近 5 分钟的指标数据 -- **HPA 依赖**：HPA 的标准资源指标（CPU/内存）完全依赖 Metrics Server - -## Deployment -- 通过 Deployment 部署单个副本（非高可用） -- 通常随 EKS 集群自动安装（EKS Add-on 或 eks-charts） -- 监控指标：Pod CPU/内存利用率、Node CPU/内存容量 - -## Limitations -- 仅支持标准资源指标（CPU、内存） -- 不支持自定义/外部指标（需要 Custom Metrics API） -- 单副本部署，非高可用设计 - -## Relationship with HPA -- HPA 通过 Metrics Server 获取 Pod 的 CPU/内存利用率 -- 计算公式：`desiredReplicas = ceil(sum(podMetricValue) / targetValue)` -- 目标阈值（targetValue）通常设置为 70-80%，保留缓冲空间 - -## Sources -- [[ctp-topic-64-scaling-out-with-amazon-eks]] diff --git a/wiki/concepts/Micro-Entreprise.md b/wiki/concepts/Micro-Entreprise.md deleted file mode 100644 index f64355d0..00000000 --- a/wiki/concepts/Micro-Entreprise.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: "Micro-Entreprise" -type: concept -tags: [] -sources: [specialized-french-consulting-market] -last_updated: 2026-04-25 ---- - -# Micro-Entreprise - -## Aliases -- Micro-Entreprise -- Auto-Entrepreneur -- Micro-Entrepreneur -- Auto-Entrepreneuriat - -## Definition - -Micro-Entreprise（微型企业家，又称 Auto-Entrepreneur）是法国于 2009 年推出的简化企业注册制度，是全球最具吸引力的自由职业者入门结构之一。它提供极简的税务和社保缴纳机制，特别适合年收入较低的自由职业者、兼职项目和初期创业阶段。 - -## Key Features - -| 维度 | 说明 | -|------|------| -| **注册** | 网上注册，当天完成，行政成本极低 | -| **税务** | 固定比例税率（无需做账），按实际收入缴纳 | -| **社保缴纳** | 按营业额的比例缴纳（而非利润），无营业额则零缴纳 | -| **报税** | 季度申报，极简报表 | -| **适用行业** | 服务业（22% URSSAF）、商业（13.3%）、餐饮（5.5-10.7%） | - -## Cost Breakdown (Services Sector) - -以 **700 EUR/天 TJM** 为例（每月 18 个工作日 = 12,600 EUR/月）： - -| 费用项 | 比例 | 金额 | -|-------|------|------| -| URSSAF（社保） | ~22% | -2,772 EUR | -| **净收入（月）** | | **~9,828 EUR** | -| **有效日均净收入** | | **~546 EUR/天** | - -对比 Portage Salarial 同等 TJM（~208 EUR/天）： -- **差距：338 EUR/天** = Micro-Entreprise 的成本优势 - -## Exemption Thresholds - -Micro-Entreprise 享有法定的营业额免税门槛： - -| 行业类型 | 2024 年门槛 | -|---------|-----------| -| 服务业（含咨询） | 77,700 EUR/年 | -| 商业 | 77,700 EUR/年 | -| 餐饮（住宿） | 77,700 EUR/年 | -| 餐饮（堂食） | 60,500 EUR/年 | - -**重要**： -- 超出门槛后，将失去 Micro-Entreprise 身份并转为标准公司税制 -- 超门槛后实际税率显著上升，需提前规划 - -## Key Benefits - -| 权益 | 说明 | -|------|------| -| **超高净收入比例** | 约 70% TJM，显著高于 Portage（50%） | -| **零启动成本** | 注册简单，无初始资本要求 | -| **灵活税务** | 按实际收入纳税，无收入零纳税 | -| **快速退出** | 可随时停业，无复杂清算程序 | -| **简单合规** | 无需专业会计，季度申报即可 | - -## Key Risks & Limitations - -| 风险 | 说明 | -|------|------| -| **无失业保险** | 失业后无法申请法国失业金（ARE） | -| **有限退休金** | 缴纳金额较低，退休金积累显著低于 Portage | -| **收入天花板** | 超过门槛后税制不利 | -| **个人承担全险** | 商业风险完全自担，无 employer-style 保障 | -| **可信度** | 某些大客户（Tier 1 ESN）更倾向于与正式公司签约 | - -> "Always distinguish TJM brut from net. A 600 EUR/day TJM through micro-entreprise yields approximately 420-450 EUR net." — French Consulting Market Navigator - -## Relationship to Portage Salarial - -Micro-Entreprise 和 Portage Salarial 是法国自由职业者最主要的两种计费结构选择： - -| 维度 | Portage Salarial | Micro-Entreprise | -|------|----------------|-----------------| -| 净收入比例 | ~50% TJM | ~70% TJM | -| 失业保险 | ✅ | ❌ | -| 退休金缴纳 | 完整 | 有限 | -| 行政复杂度 | 低 | 极低 | -| 适合场景 | 转型期/需要保障 | 高净收入/低成本 | - -## Related Sources -- [[specialized-french-consulting-market]] -- [[Portage-Salarial]] diff --git a/wiki/concepts/Micro-Interaction-Design.md b/wiki/concepts/Micro-Interaction-Design.md deleted file mode 100644 index e9339578..00000000 --- a/wiki/concepts/Micro-Interaction-Design.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Micro-Interaction Design" -type: concept -tags: [ui-design, animation, user-experience, interaction-design] -sources: [design-whimsy-injector] -last_updated: 2026-05-15 ---- - -# Micro-Interaction Design - -## Definition - -微交互设计（Micro-Interaction Design）通过小规模、有针对性的动画和状态反馈，提升用户参与度，同时不影响性能。核心要素：触发（Trigger）、规则（Rules）、反馈（Feedback）、循环（Loops）。 - -## Key Elements - -- **按钮悬停效果**：光扫动画 + 微妙缩放 -- **表单验证反馈**：即时状态变化 + 成功动画（如 ✨ 闪烁） -- **加载动画**：弹跳点动画、进度条动画 -- **彩蛋触发区域**：交互探索奖励 -- **进度庆祝**：完成节点的表情符号动画 - -## Design Principles - -- 每个微交互服务于功能或情感目的 -- 性能优化：轻量 CSS 动画，不影响页面速度 -- 包容性：无障碍支持，减少动画偏好用户选项 - -## Implementation - -通过 CSS Keyframes 实现，示例技术： -- `cubic-bezier` 缓动函数 -- `transition` 状态变化 -- `@keyframes` 自定义动画序列 - -## Related Concepts - -- [[Gamification]]：微交互可作为游戏化的组成元素 -- [[Inclusive-Delight-Design]]：微交互需遵循包容性设计原则 - -## Source - -- [[Whimsy-Injector]] — 微交互设计系统核心交付物 diff --git a/wiki/concepts/Micro-Interaction.md b/wiki/concepts/Micro-Interaction.md deleted file mode 100644 index 23d746f1..00000000 --- a/wiki/concepts/Micro-Interaction.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Micro-Interaction" -type: concept -tags: [ux, design, interaction] -last_updated: 2026-04-30 ---- - -# 微交互设计（Micro-Interaction） - -## Aliases -- Micro-Interaction -- 微交互 - -## 定义 - -微交互是指产品中那些小型的、聚焦于单一任务的交互细节——通过小型动画、声音反馈和视觉变化，增强用户体验的愉悦感和功能性。通常作用于：按钮状态变化、表单验证反馈、加载动画、设置切换等具体场景。 - -## 核心特征 - -1. **聚焦单一任务**：每个微交互只做一件事（如点赞动画、成功反馈） -2. **触发-反馈循环**：用户动作 → 系统响应 → 状态变化 -3. **细节驱动体验**：大型功能由微交互串联形成流畅体验 - -## 设计原则 - -- **目的性**：每个微交互必须有功能性或情感性目的，不可为装饰而装饰 -- **响应性**：即时反馈，减少用户对系统状态的焦虑 -- **一致性**：同类型交互保持相同反馈模式，建立用户预期 -- **可访问性**：动画需考虑 `prefers-reduced-motion`，不影响屏幕阅读器 - -## 分类 - -| 类型 | 示例 | 目的 | -|------|------|------| -| 状态反馈 | 按钮悬停、点击效果 | 确认操作被接收 | -| 数据验证 | 表单实时验证成功/失败 | 引导正确输入 | -| 系统状态 | 加载动画、空状态 | 减少等待焦虑 | -| 进度指示 | 上传进度、完成庆祝 | 维持用户动机 | - -## 应用场景 - -- [[design-whimsy-injector]] 在按钮、表单、进度条等关键触点嵌入微交互，提升品牌趣味性同时保持功能性 -- [[design-ux-architect]] 提供 CSS 框架层面的微交互系统设计规范 - -## 相关概念 - -- [[Brand-Personality-Framework]]：微交互是品牌个性在交互层的具体表达载体 -- [[Gamification]]：成就庆祝等游戏化元素本身也是一种微交互 -- [[Inclusive-Delight]]：包容性要求微交互需支持 reduced-motion 模式 diff --git a/wiki/concepts/Micro-Recovery.md b/wiki/concepts/Micro-Recovery.md deleted file mode 100644 index 262ac5e8..00000000 --- a/wiki/concepts/Micro-Recovery.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: "Micro-Recovery (微恢复)" -tags: [devops, disaster-recovery, reliability, feature-management] -created: 2026-04-25 ---- - -# Micro-Recovery (微恢复) - -**Micro-Recovery**（微恢复）是指不回滚整个部署，而是针对特定功能（Feature）进行精准恢复的能力。它是 [[Feature Flag]] 带来的核心理念转变：不再将整个应用视为单一恢复单元，而是按功能粒度进行风险管理。 - -## Definition - -> "Don't treat your entire app like one big system. Different features have different risks and business impacts, so they should have different recovery targets." - -传统灾备将整个系统作为恢复目标，而 Micro-Recovery 将恢复粒度缩小到单个功能模块。 - -## 传统方式 vs. Micro-Recovery - -| 维度 | 传统全量回滚 | Micro-Recovery | -|------|-------------|----------------| -| 恢复粒度 | 整个部署/系统 | 单个功能 | -| RTO | 小时级 | 秒级 | -| RPO | 取决于备份频率 | 近零 | -| 影响范围 | 全局（所有用户） | 局部（可定向） | -| 用户体验 | 可能感知到中断 | 可能完全无感知 | - -## Feature-Level Recovery Targets - -不同功能有不同的风险和业务影响： - -| 功能类型 | RTO 目标 | RPO 目标 | 恢复策略 | -|----------|----------|----------|----------| -| 核心支付处理 | 秒级 | 零丢失 | Kill Switch → 备用提供商 | -| 新推荐引擎 | 5 分钟 | 15 分钟 | Feature Flag → 旧算法 | -| Beta 仪表盘功能 | 30 分钟 | 1 小时 | Feature Flag → 禁用该功能 | - -## Micro-Recovery 的优势 - -### 1. 精准止血 -发现某功能异常时，只关闭该功能，其他正常功能不受影响。 - -### 2. 用户无感知 -> "Your checkout flow has a bug? Disable the new version and fall back to the old one in seconds. Users might not even notice." - -### 3. 数据保护 -[[Feature Flag]] 切换只改变代码执行路径，不触碰数据层，RPO 不受影响。 - -### 4. 定向恢复 -如果某功能只影响特定地区或用户群，可以只针对该群体禁用，其他用户继续使用新功能。 - -## 实现方式 - -Micro-Recovery 通过 [[Feature Flag]] 实现： - -```javascript -// 结账流程示例 -async function checkoutFlow(userId, cart) { - // Feature Flag 控制是否使用新版结账 - if (await flags.enabled('new-checkout-v2', userId)) { - return newCheckoutProcess(cart); // 故障时 → 切换到旧版 - } - return legacyCheckoutProcess(cart); -} -``` - -## Micro-Recovery vs. 其他恢复模式 - -| 模式 | 恢复粒度 | RTO | RPO | 复杂度 | -|------|----------|-----|-----|--------| -| 传统灾备 | 系统/数据中心 | 小时级 | 取决于备份 | 高 | -| CI/CD 回滚 | 部署版本 | 分钟级 | 可能丢失 | 中 | -| Kill Switch | 组件/功能 | 秒级 | 近零 | 低 | -| **Micro-Recovery** | **单个功能** | **秒级** | **近零** | **低** | - -## 实践建议 - -1. **功能分级**：不是所有功能都需要 Micro-Recovery 能力，关键路径必须有 -2. **Fallback 路径**：每个 Feature Flag 需要有明确的降级路径（Fallback） -3. **可观测性**：每次切换需要有清晰的日志和监控 -4. **文档化**：哪些功能支持 Micro-Recovery？团队需要知道 - -## Related Concepts - -- [[Feature Flag]] — Micro-Recovery 的技术基础 -- [[Kill Switch]] — Micro-Recovery 的紧急实现方式 -- [[RTO]] — Micro-Recovery 将 RTO 从小时降至秒级 -- [[RPO]] — Micro-Recovery 保护 RPO（不触碰数据层） -- [[Progressive Rollout]] — Micro-Recovery 与渐进式放量结合实现精细化风险控制 -- [[Disaster Recovery]] — Micro-Recovery 是现代灾备的重要组成部分 - -## Sources - -- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/concepts/Micro-Sprint.md b/wiki/concepts/Micro-Sprint.md deleted file mode 100644 index 283a0870..00000000 --- a/wiki/concepts/Micro-Sprint.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Micro-Sprint" -type: concept -tags: [] -sources: ["product-behavioral-nudge-engine"] -last_updated: 2026-05-01 ---- - -## Definition - -Micro-Sprint 是一种将大量任务分解为短时间（通常5分钟）可完成的微小冲刺的行为工程模式。通过时间盒约束和极简任务范围来对抗认知过载和任务瘫痪。 - -## Mechanism - -- **触发条件**：用户队列 ≥ 5条待办，或用户状态为 "Overwhelmed" / 识别为 ADHD 倾向 -- **时间盒**：通常 5 分钟（可调整） -- **任务粒度**：每次只呈现 **1个** 动作项 -- **执行流程**：推送「准备好了吗？」→ 用户确认 → 开始计时 → 完成 → 即时庆祝 → 询问继续或退出 - -## Example - -```typescript -// Behavioral Engine: Generating a Time-Boxed Sprint Nudge -export function generateSprintNudge(pendingTasks: Task[], userProfile: UserPsyche) { - if (userProfile.tendencies.includes('ADHD') || userProfile.status === 'Overwhelmed') { - return { - channel: userProfile.preferredChannel, - message: "Hey! You've got a few quick follow-ups pending. Let's see how many we can knock out in the next 5 mins. I'll tee up the first draft. Ready?", - actionButton: "Start 5 Min Sprint" - }; - } -} -``` - -## Related Concepts - -- [[Cognitive Load Reduction]] — Micro-Sprint 的核心目标就是降低认知负荷 -- [[Time-boxing]] — 时间约束机制 -- [[Gamification]] — 配合即时庆祝机制使用 -- [[Habit Formation]] — 通过微小成功的积累建立习惯 - -## Connections - -- [[Product Sprint Prioritizer Agent]] — 任务优先级排序可结合 Micro-Sprint 策略 -- [[Habit Tracker & Accountability Coach]] — 将 Micro-Sprint 融入日常习惯追踪 diff --git a/wiki/concepts/MicroInfluencerPartnership.md b/wiki/concepts/MicroInfluencerPartnership.md deleted file mode 100644 index 572784f0..00000000 --- a/wiki/concepts/MicroInfluencerPartnership.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Micro Influencer Partnership" -type: concept -tags: [influencer, marketing, koc, collaboration] -sources: [] -last_updated: 2026-04-26 ---- - -## Overview -微影响者合作（Micro Influencer Partnership）指品牌与粉丝量级在 1 万至 10 万之间的腰部创作者（KOC，Key Opinion Consumer）建立合作关系，借助其真实感和高互动率为品牌传播背书的营销策略。 - -## Definition -微影响者的核心特征： -- **粉丝量级**：10,000 - 100,000 粉丝 -- **互动率**：通常高于头部 KOL（5-10% vs 1-3%） -- **真实感**：内容更接地气，用户信任度更高 -- **成本效益**：单次合作成本仅为头部 KOL 的 1/10 至 1/50 - -## Why Micro Over Macro -- 更高的粉丝信任度和转化率 -- 更垂直的受众定位（粉丝画像更精准） -- 更强的社区互动和真实内容创作 -- 适合品牌长期关系建设和口碑积累 - -## Application -- [[MarketingXiaohongshuSpecialist]] — 小红书微影响者合作是社区建设和病毒传播的核心策略 -- 可扩展至 [[MarketingTikTokStrategist]]、 [[MarketingInstagramCurator]] 等平台 - -## Related Concepts -- [[UGCCampaign]] — 用户生成内容活动可与微影响者合作协同 -- [[CommunityFirstEngagement]] — 微影响者是社区互动的关键节点 -- [[TrendRiding]] — 微影响者是品牌趋势传播的放大器 diff --git a/wiki/concepts/Microhistory.md b/wiki/concepts/Microhistory.md deleted file mode 100644 index 5fba158d..00000000 --- a/wiki/concepts/Microhistory.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Microhistory" -type: concept -tags: [historiography, methodology] -sources: [academic-historian] -last_updated: 2026-04-30 ---- - -## Definition -微观史学（Microhistory）是一种历史研究方法，聚焦于个体、家庭或小规模社区的历史，通过深入细致的案例研究揭示更宏观的历史规律与社会结构。与年鉴学派的"总体史"形成互补——Annales School 关注长时段的结构性趋势，Microhistory 则从"小切口"切入，以小见大。 - -## Key Features -- **研究对象**：特定个体（如磨坊主梅诺基奥）、家庭、社区——而非帝王将相 -- **核心方法**：厚描（thick description，借鉴格尔茨）、文献细读、口述史 -- **代表学者**：卡洛·金兹堡（Carlo Ginzburg）、乔万尼·列维（Giovanni Levi）、娜塔莉·泽蒙·戴维斯（Natalie Zemon Davis） -- **代表著作**：《奶酪与虫子》（Ginzburg, 1976）、《都铎王朝的谋杀犯》（Kelley, 1981） -- **主要贡献**：将历史学从宏观结构拉回个体经验，揭示边缘群体和日常生活的历史能动性 - -## Relationship to Other Concepts -- [[Annales-School]] ← 方法论互补 ← [[Microhistory]]：微观史是对年鉴学派过度结构决定论的回应之一 -- [[Longue-Duree]] ← 尺度互补 ← [[Microhistory]]：长时段聚焦结构，微观史聚焦个体；两者共同构成多尺度历史分析 -- [[Historiography]] ← 属于 ← [[Microhistory]]：是历史编纂学中的重要流派和方法论 -- [[academic-historian]] ← 使用 ← [[Microhistory]]：Historian Agent 具备微观史方法论训练 - -## Relationship to Source Pages -- [[academic-historian]]：Historian Agent 文档明确将其列为核心训练背景之一 - -## Aliases -- 微观史学 -- 小历史 diff --git a/wiki/concepts/MinimalChangePrinciple.md b/wiki/concepts/MinimalChangePrinciple.md deleted file mode 100644 index 99a9cbe6..00000000 --- a/wiki/concepts/MinimalChangePrinciple.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "MinimalChangePrinciple" -type: concept -tags: [engineering, code-quality, best-practices] -last_updated: 2026-05-02 ---- - -## Definition - -最小变更原则（MinimalChangePrinciple）是一种代码变更方法论：每个变更行的存在都必须有任务明确要求的理由，而非"更好""更整洁""为未来做准备"。目标是以最小可工作的差异集（minimum viable diff）完成给定任务。 - -## Core Questions - -> "Does the task require this exact line?" - -变更每一行之前，必须通过以下测试： -1. **必要性**：任务是否明确要求了这一行？ -2. **最小性**：能否以更少的变更行达到同样效果？ -3. **可解释性**：这一行变更对未来的代码维护者是否可理解？ - -## Contrast with Traditional Code Quality - -| 维度 | 传统观点 | 最小变更原则 | -|------|---------|-------------| -| 新增代码 | 越多越好（健壮性） | 越少越好（降低维护成本） | -| 文档 | 应该详细添加 | 不为未修改代码添加文档 | -| 重构 | 遇到问题就重构 | 与任务变更分离，独立 PR | -| 防御性代码 | 宁多勿缺 | 仅在系统边界添加 | -| 代码风格 | 统一风格 | 不为统一风格而修改无关代码 | - -## Success Metrics - -- **Median diff size < 30 lines changed per task** -- **80%+ bug fix PRs touch ≤ 2 files** -- **Zero "while I'm here" changes in any PR** -- **Review time reduced 50%+** -- **Regression rate near zero** - -## Connections - -- [[engineering-minimal-change-engineer]]：最小变更原则的具体实践者 -- [[PrematureAbstraction]]：最小变更原则反对在第四次出现前提取抽象 -- [[ScopeCreep]]：最小变更原则是对抗范围蔓延的核心策略 -- [[engineering-code-reviewer]]：代码审查者是检验最小变更原则的最后一道防线 - -## Sources - -- [[engineering-minimal-change-engineer]] diff --git a/wiki/concepts/Minimum-Viable-Harness.md b/wiki/concepts/Minimum-Viable-Harness.md deleted file mode 100644 index 4151c0e4..00000000 --- a/wiki/concepts/Minimum-Viable-Harness.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: "Minimum Viable Harness" -type: concept -tags: - - "harness-engineering" - - "agentic-ai" - - "quick-start" -sources: - - "Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog" -last_updated: 2026-04-20 ---- - -## Overview -Minimum Viable Harness——Day 1 即可构建的 4 个核心组件，使 Agent 能够优雅失败，为后续增加智能赢得权利。 - -## The 4 Components - -### 1. `state.json` -单一结构化文件跟踪任务状态——如果进程死亡，可以从上次停止的地方继续。 -```json -{ - "task_id": "report-001", - "steps": { - "fetch_competitor_a": "COMPLETED", - "fetch_competitor_b": "IN_PROGRESS", - "compare": "PENDING" - }, - "last_updated": "2026-04-20T10:30:00Z" -} -``` - -### 2. Retry Wrapper -每个工具调用包装 try/catch，至少一次自动重试 + 指数退避： -```python -def tool_call_with_retry(func, max_attempts=3): - for attempt in range(max_attempts): - try: - return func() - except (TimeoutError, APIError) as e: - if attempt < max_attempts - 1: - sleep(exponential_backoff(attempt)) - else: - raise -``` - -### 3. Schema Validator -每个 LLM 输出在接收前必须通过 JSON Schema 验证。格式不符触发重试，不触发崩溃： -```python -def validate_and_retry(llm_output, schema): - try: - validated = jsonschema.validate(llm_output, schema) - return validated - except ValidationError: - return retry_with_error_feedback(llm_output, schema) -``` - -### 4. Tool Output Truncation -每个工具 payload 硬性上限固定 token 预算——context window 内的静默截断是幻觉最常见原因之一： -```python -MAX_TOOL_TOKENS = 3000 # 保守上限 - -def truncate_tool_output(raw_output, max_tokens=MAX_TOOL_TOKENS): - tokens = encode(raw_output) - if len(tokens) > max_tokens: - return decode(tokens[:max_tokens]) + "\n[TRUNCATED]" - return raw_output -``` - -## Philosophy -> 你可以忍受不完美的提示词。你可以忍受天真的工具集成。但是你无法忍受一个失败时破坏自己状态或静默吞噬错误的 Agent。 - -## Source -- [[Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog]] - -## See Also -- [[Harness-Engineering]] — 完整学科框架 -- [[7-Layer-Harness-Stack]] — 完整 7 层实现 diff --git a/wiki/concepts/Miping.md b/wiki/concepts/Miping.md deleted file mode 100644 index ca27a624..00000000 --- a/wiki/concepts/Miping.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Miping" -type: concept -tags: [China, cryptography, compliance, ToG, government, SM2, SM3, SM4] -sources: [government-digital-presales-consultant] -last_updated: 2026-04-25 ---- - -# Miping（商用密码应用安全性评估） - -商用密码应用安全性评估（Commercial Cryptographic Application Security Assessment），是中国政府对涉及密码使用的信息系统进行强制性安全评估的合规制度。 - -## 基本概念 - -- **全称**：商用密码应用安全性评估 -- **拼音缩写**：密评（Mìpíng） -- **主管机构**：国家密码管理局 -- **强制性质**：政府系统涉及密码应用的上线**前置条件**，验收必须提供密评报告 - -## 强制使用场景 - -涉及以下场景的政府系统**必须使用国密算法**： -1. **身份认证**：用户身份鉴别、单点登录 -2. **数据传输**：系统间 API 通信、数据同步 -3. **数据存储**：敏感数据加密存储 -4. **电子签章**：电子印章、CA 证书 - -## 国密算法体系 - -| 算法类型 | 算法名称 | 用途 | -|---------|---------|------| -| 非对称加密 | SM2 | 密钥交换、数字签名 | -| 哈希算法 | SM3 | 数据完整性校验 | -| 对称加密 | SM4 | 数据加密传输和存储 | - -## 密评要求 - -- 电子印章和 CA 证书必须使用**国密证书** -- 密码产品必须通过国家密码管理局审批 -- 密评报告是系统验收的**必要文件** - -## 与等保的关系 - -- [[Dengbao-2.0]]（等保）和 Miping 是政府 IT 系统的两项**并列合规要求** -- 等保关注整体安全架构，Miping 专注于密码应用正确性 -- 两者在投标时通常作为独立章节分别论述 - -## Aliases -- 商用密码应用安全性评估 -- 密评 -- Shangmi Yingyong Anquan Xing Pinggu -- Commercial Cryptographic Application Security Assessment -- 国密算法（SM2/SM3/SM4） -- Guomi Algorithms diff --git a/wiki/concepts/MoSCoW-Classification.md b/wiki/concepts/MoSCoW-Classification.md deleted file mode 100644 index 825f3220..00000000 --- a/wiki/concepts/MoSCoW-Classification.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "MoSCoW Classification" -type: concept -tags: [prioritization, requirements, agile] -last_updated: 2026-05-01 ---- - -## Definition - -MoSCoW 分类法是一种需求优先级分类技术，将所有需求分为四级：**Must Have**（必须有）、**Should Have**（应该有）、**Could Have**（可以有）、**Won't Have**（不会有/本期不做）。 - -## 分类定义 - -| 分类 | 含义 | 占比建议 | 若不做会怎样 | -|------|------|---------|------------| -| **M — Must Have** | 产品无法发布的最低功能集；无替代方案 | 60% | 产品不可用或违反法规 | -| **S — Should Have** | 重要但不致命；功能体验降级但有 workaround | 20% | 用户满意度下降，但产品仍可用 | -| **C — Could Have** | 期望但非必要；提升愉悦度 | 15% | 错过加分项，但不影响核心价值 | -| **W — Won't Have** | 本期明确不做；列入 Backlog 未来考虑 | 5% | 主动放弃，聚焦当前 Sprint 范围 | - -## 关键原则 - -- **"Won't" means won't**：明确不做的功能不得在 Sprint 期间以任何理由渗透进来 -- 每个 MoSCoW 决策必须有明确理由并记录在 Sprint 文档中 -- MoSCoW 是对**功能范围**的分类，不是对用户价值的绝对排序 - -## 应用场景 - -- **[[Phase 1 Strategy]]**：Sprint Prioritizer 使用 MoSCoW 分类 + RICE 评分双重排序，MoSCoW 决定范围边界，RICE 在范围内排序 -- **[[scenario-startup-mvp]]**：Startup MVP Build Runbook 中强调"Sprint Prioritizer 执行 MoSCoW 防止范围蔓延" - -## MoSCoW 与 RICE 的协同工作流 - -``` -所有需求 → MoSCoW 分类（M/S/C/W）→ RICE 评分（M + S + C）→ Sprint 规划 - ↓ - W（直接归档） -``` - -## Aliases -- MoSCoW Prioritization -- MoSCoW Requirements Classification diff --git a/wiki/concepts/ModalContextProtocol.md b/wiki/concepts/ModalContextProtocol.md deleted file mode 100644 index b9b5828a..00000000 --- a/wiki/concepts/ModalContextProtocol.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Modal Context Protocol (MCP)" -type: concept -tags: [ai, ai-agent, mcp, protocol] -sources: [mcp在cursor中的集成与应用详解] -last_updated: 2026-04-26 ---- - -## Definition -MCP（Modal Context Protocol）是一种基于 **Client-Server 架构**的协议，旨在实现 AI 大模型与外部工具和服务的高效集成。MCP 为 AI 应用提供了标准化的工具扩展框架，使大模型能够无缝调用外部数据源和工具。 - -## Architecture -MCP 基于 Client-Server 架构，包含两个核心组件： -- **MCP Server（服务端）**：服务提供方，负责对外暴露资源和工具接口。 -- **MCP Client（客户端）**：集成 MCP 协议的应用程序或大模型对话客户端（如 Cursor、Claude Desktop）。 - -## Core Interfaces -MCP Server 提供三类核心功能接口： - -| 接口类型 | 类比 | 用途 | -|----------|------|------| -| 资源访问（Resource） | HTTP GET | 获取外部数据 | -| 工具调用（Tool） | HTTP POST | 执行外部操作 | -| Promise 提示词 | 扩展接口 | 异步交互 | - -## MCP in Cursor -在 Cursor 中，MCP Server 有两种接入方式： -1. **SSE（Server-Sent Events）**：通过 HTTP SSE 方式连接远程 MCP Server。 -2. **Command（命令行）**：通过本地执行命令的方式与 MCP Server 交互。 - -接入后在 Cursor Composer 中切换到 Agent 模式即可调用 MCP 工具链。 - -## Connections -- [[Mcp在Cursor中的集成与应用详解]] ← 使用场景 -- [[McpBuilderAgent]] ← 构建工具 -- [[Cursor]] ← 客户端 -- [[SequentialThinking]] ← 常用 MCP 工具 - -## See Also -- [[ClientServerArchitecture]] -- [[AgentMode]] -- [[McpBuilderAgent]] diff --git a/wiki/concepts/Model-Context-Protocol.md b/wiki/concepts/Model-Context-Protocol.md deleted file mode 100644 index 7d8bc348..00000000 --- a/wiki/concepts/Model-Context-Protocol.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Model Context Protocol" -type: concept -tags: [mcp, protocol, llm, tool] -aliases: [MCP, Model Context Protocol, 模型上下文协议] -last_updated: 2025-12-20 ---- - -## Definition -Model Context Protocol（MCP），模型上下文协议，是一个开放协议，为 LLM 应用提供标准化接口，使其能够连接外部数据源和各种工具进行交互。 - -## Key Facts -- MCP Client 向 MCP Server 发送请求 -- MCP Server 负责与外部数据源或工具交互，获取数据并按 MCP 协议规范格式化后返回 -- **核心约束**：大模型本身不会自己调用外部数据源或工具，只会告诉用户需要调用哪些工具，实际调用需要开发者自己实现 -- MCP 是连接 LLM 与真实世界的桥梁 - -## Connections -- [[Agent]] ← 构建于 ← [[Model Context Protocol]] -- [[Large Language Model]] ← 通过 ← [[Model Context Protocol]] → 连接外部工具 -- [[Model Context Protocol]] ← 标准化 ← 工具调用 - -## Sources -- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]] diff --git a/wiki/concepts/Model-Fallback.md b/wiki/concepts/Model-Fallback.md deleted file mode 100644 index a1f01bad..00000000 --- a/wiki/concepts/Model-Fallback.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: "Model Fallback" -type: concept -last_updated: 2026-04-10 ---- - -## Definition -Model Fallback 是 OpenClaw 在默认模型不可用时，按优先级自动切换到 fallback 列表中下一个模型的机制。 - -## Triggers -1. **显式 API 不可用**: HTTP 503/502（服务宕机）、429（频率限制）、Connection Timeout -2. **隐性 Token 溢出预判**: 路由权重配置错误导致切换到更小 context 的模型 -3. **配置文件优先级覆盖**: Agent/Channel 级别配置覆盖全局配置 -4. **负载均衡算法**: 随机或轮询分发请求 - -## Sources -- [[养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑]] diff --git a/wiki/concepts/Momentum-Nudge.md b/wiki/concepts/Momentum-Nudge.md deleted file mode 100644 index 7b320617..00000000 --- a/wiki/concepts/Momentum-Nudge.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Momentum Nudge" -type: concept -tags: [nudge, behavioral-psychology, motivation, task-management] -last_updated: 2026-04-20 ---- - -## Definition -动量推送（Momentum Nudge）是 [[Behavioral Nudge Engine]] 的一种核心推送策略，通过识别用户当前状态（如 Overwhelmed、ADHD 倾向）自动切换至微任务冲刺模式，帮助用户克服启动阻力并建立持续行动习惯。 - -## Mechanism -1. **状态检测**：分析用户画像（ADHD 标签、任务积压数量、最近响应率） -2. **模式切换**：从标准批量推送切换为短时微冲刺（5-15 分钟） -3. **预热准备**：Agent 代为准备第一稿草稿或第一个行动项，用户只需"确认/启动" -4. **即时庆祝**：每完成一个微任务立即给予正强化反馈 -5. **温和退出**：提供明确的"继续或结束"选项，降低心理承诺压力 - -## Key Code Pattern -```typescript -export function generateSprintNudge(pendingTasks: Task[], userProfile: UserPsyche) { - if (userProfile.tendencies.includes('ADHD') || userProfile.status === 'Overwhelmed') { - return { - channel: userProfile.preferredChannel, - message: "Let's see how many we can knock out in the next 5 mins. Ready?", - actionButton: "Start 5 Min Sprint" - }; - } - return standardBatchNudge(pendingTasks); -} -``` - -## Related Concepts -- [[Cognitive Load Reduction]]：微冲刺背后的认知负荷管理原理 -- [[Pomodoro Technique]]：时间盒化的工作模式 -- [[Behavioral Psychology]]：即时正强化的心理学基础 -- [[Gamification]]：动量维持中的游戏化元素 - -## Source -- [[Behavioral Nudge Engine]] — 核心应用场景 diff --git a/wiki/concepts/Month-End-Close-Process.md b/wiki/concepts/Month-End-Close-Process.md deleted file mode 100644 index d4d2fecd..00000000 --- a/wiki/concepts/Month-End-Close-Process.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: "Month-End Close Process" -type: concept -tags: [finance, accounting, process] -sources: [finance-bookkeeper-controller] -last_updated: 2026-05-02 ---- - -## Definition -月度结账流程（Month-End Close Process）是企业每月完成的标准化财务结算流程，确保所有交易被正确记录、账户被调节、财务报表准确完整。 - -## Core Steps - -### 1. Pre-Close（预结账，第1-2天） -- 确认所有银行 feeds 同步 -- 验证所有 AP 发票已录入截止日期 -- 确认所有工资期 journal entries 已过账 -- 审核员工报销报告 -- 确认所有 AR 发票已开具 -- 确认关联方交易已与对方核对 - -### 2. Core Close（核心结账，第3-5天） -- 过账标准 recurring journal entries（折旧、摊销、租金、保险） -- 计算并过账 expense accruals -- 计算并过账 revenue accruals / 递延收入调整 -- 过账工资税和福利应计 -- 记录信用卡交易并调节对账单 -- 过账外币重估（如适用） -- 过账关联方抵消（如合并报表） - -### 3. Reconciliations（调节，第3-6天） -- 所有银行账户调节 -- 所有信用卡调节 -- AR aging 与 GL 核对 -- AP aging 与 GL 核对 -- 预付账款与摊销计划核对 -- 固定资产调节 -- 应计负债调节 -- 递延收入调节 -- 关联方调节 -- 权益调节 -- 工资税负债与申报表核对 - -### 4. Financial Statements（财务报表，第6-7天） -- 生成试算表并检查异常余额 -- 编制利润表（含 MoM 和 BvA 差异分析） -- 编制资产负债表（含调节） -- 编制现金流量表 -- 编制支持明细表 - -### 5. Review & Finalize（审核与结账，第7-8天） -- Controller 审核所有调节和 journal entries -- 最终审核财务报表 -- 锁定会计系统期间 -- 分发财务包给管理层 -- 归档支持文件 -- 结账复盘 - -## Key Metrics -- 目标：每月在 X 个工作日内完成结账（基准：10天，目标：7天，理想：5天） -- 100% 资产负债表科目每月调节 -- 零重述（no restatements） -- 零重大审计调整（< 1% 总资产） - -## Related Concepts -- [[Account Reconciliation]] -- [[GAAP Compliance]] -- [[Journal Entry]] -- [[Audit Readiness]] -- [[Internal Controls]] diff --git a/wiki/concepts/Morning-Briefing.md b/wiki/concepts/Morning-Briefing.md deleted file mode 100644 index 36b66556..00000000 --- a/wiki/concepts/Morning-Briefing.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Morning Briefing" -type: concept -tags: [automation, agent, productivity, daily-routine] -date: 2026-04-22 ---- - -## Definition -Morning Briefing（晨报）是 AI Agent 每日定时（通常 8:00 AM）自动生成并推送的结构化摘要，将天气、日历、系统状态和任务看板整合为一份统一的可操作简报。 - -## In Home Lab Context -在 [[self-healing-home-server]] 中，OpenClaw Agent "Reef" 每日 8:00 AM 生成晨报，包含以下模块： - -### 晨报模板结构 -``` -### Weather -- 当前天气条件和 [所在地] 预报 - -### Calendars -- 你的今日事件 -- 伴侣的今日事件 -- 冲突或重叠标记 - -### System Health -- 所有机器的 CPU / RAM / Storage -- Services: UP/DOWN 状态 -- 最近部署（ArgoCD） -- 过去 24h 的任何告警 - -### Task Board -- 昨日完成的卡片 -- 进行中的卡片 -- 需要关注的阻塞项 - -### Highlights -- 夜间头脑风暴的亮点 -- 需要处理的邮件 -- 本周即将到来的截止日期 -``` - -## Key Insight -晨报将来自多个系统的碎片信息（天气 API、日历 API、监控系统、看板）整合为单一可操作视图，大幅降低每日信息获取成本。 - -## Connections -- [[OpenClaw]] — 生成晨报的 Agent 平台 -- [[Agentic AI]] — 驱动晨报自动化的 AI 能力 -- [[Cron定时任务]] — 晨报调度的触发机制（每日 8:00 AM cron job） -- [[Daily-Digest]] — 类似思路：AI 每日自动整理信息推送 diff --git a/wiki/concepts/Motion-Sickness-Threshold.md b/wiki/concepts/Motion-Sickness-Threshold.md deleted file mode 100644 index a1c99603..00000000 --- a/wiki/concepts/Motion-Sickness-Threshold.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Motion Sickness Threshold" -type: concept -tags: [] -last_updated: 2026-04-25 ---- - -## Definition -运动病阈值（Motion Sickness Threshold）——在 XR 环境中，导致用户产生眩晕、恶心等生理不适的感官冲突临界点。通过设计手段将其最小化是沉浸式 XR 体验成功的关键指标。 - -## Key Factors Affecting Threshold -- **视觉-前庭冲突**：眼睛感知的运动与内耳前庭系统感知的运动不一致 -- **延迟**：交互响应延迟超过 20ms 时眩晕感显著增加 -- **视野晃动**：虚拟相机不稳定的晃动或抖动 -- **自由漂浮运动**：用户缺乏物理参照系的虚拟移动 - -## Mitigation Strategies -- **固定视角设计**：用户视角固定，通过控制器移动而非身体移动 -- **约束驱动控制**（[[Constraint-Driven-Control-Mechanics]]）：消除无物理意义的运动 -- **座舱环境锚定**（[[Cockpit-Ergonomics]]）：提供稳定的环境参照系 -- **低延迟渲染**：保持 20ms 以下的交互响应延迟 - -## Related Concepts -- [[Constraint-Driven-Control-Mechanics]]：约束驱动控制——降低运动病阈值的主要手段 -- [[Cockpit-Ergonomics]]：座舱人体工学——通过环境锚定降低阈值 -- [[Spatial-Computing]]：空间计算——底层技术支撑 - -## Sources -- [[xr-cockpit-interaction-specialist]] diff --git a/wiki/concepts/Multi-AI-Review.md b/wiki/concepts/Multi-AI-Review.md deleted file mode 100644 index 9260f761..00000000 --- a/wiki/concepts/Multi-AI-Review.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Multi-AI Review" -type: concept -tags: [] -last_updated: 2025-12-30 ---- - -## Definition - -Multi-AI Review（多 AI 协作审查）是一种使用多个 AI 代理进行代码开发和审查的工作模式，模拟人类的双人编程（Pair Programming）实践。 - -## How It Works - -1. **主 AI**：根据需求和设计文档生成代码 -2. **Review AI**：审查生成的代码，提出改进意见 -3. **开发者**：根据 Review 意见决定是否采纳 - -## Benefits - -- **质量提升**：多角度审查发现单一代码审查无法覆盖的问题 -- **效率保持**：无需等待人类审查员，实时反馈 -- **一致性**：审查标准可配置，保证评审质量稳定 - -## Related Concepts - -- [[Design-to-Code Workflow]]：Multi-AI Review 是其组成部分 -- [[Vibe Coding]]：整体方法论背景 - -## Sources - -- [[vibe-coding经验收集]] diff --git a/wiki/concepts/Multi-AZ.md b/wiki/concepts/Multi-AZ.md deleted file mode 100644 index 8e959d57..00000000 --- a/wiki/concepts/Multi-AZ.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Multi-AZ" -type: concept -tags: - - AWS - - RDS - - Database - - High Availability - - Disaster Recovery -sources: - - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora -last_updated: 2026-04-23 ---- - -## Overview -Multi-AZ 是 AWS RDS 的一种高可用部署方案，在多个可用区（AZ）部署数据库实例的主节点和备用节点，当主节点发生故障时自动切换到备用节点，以实现数据库的高可用性。 - -## How It Works -- **主节点（Primary）**：处理所有读写操作 -- **备用节点（Standby）**：通过同步复制保持数据一致，处于热备状态 -- **自动故障转移**：主节点不可用时，RDS 自动将连接路由到备用节点（约 1-2 分钟） - -## RDS Multi-AZ vs Aurora Architecture -| 特性 | RDS Multi-AZ | Aurora | -|------|-------------|--------| -| 备用节点 | 独立计算 + 独立 EBS 存储 | 共享集群卷（6 副本跨 3 AZ） | -| 数据复制 | 同步复制到备用 | 分布式写入所有副本 | -| 故障转移时间 | 约 2 分钟 | 约 30 秒 | -| 读副本 | 需重新复制数据 | 共享存储，无需数据复制 | -| 端点 | 单个端点 | 分离的 Writer/Reader 端点 | - -## Key Insights -- RDS Multi-AZ 的备用节点**不能用于读取扩展**（同步复制保证数据一致性） -- Aurora 的共享存储架构使其读副本可以立即上线，无需数据复制 -- 故障转移期间，DNS 缓存可能导致短暂连接中断（建议将 DNS TTL 设置为 1 秒以加速切换） - -## Related Concepts -- [[Amazon RDS]]：RDS Multi-AZ 的宿主服务 -- [[Amazon Aurora]]：采用不同的架构实现更高可用性 -- [[RTO]]：Multi-AZ 的 RTO 约为 2 分钟 -- [[Aurora Global]]：Aurora 的跨区域灾备方案 -- [[High Availability]]：高可用性设计 - -## Aliases -- Multi-AZ Deployment -- Multi Availability Zone -- 多可用区部署 -- RDS Multi-AZ diff --git a/wiki/concepts/Multi-Account-Deployment.md b/wiki/concepts/Multi-Account-Deployment.md deleted file mode 100644 index d06ce2db..00000000 --- a/wiki/concepts/Multi-Account-Deployment.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Multi-Account Deployment -type: concept -tags: [AWS, CloudOps, Infrastructure-as-Code, DevOps] -date: 2025-10-24 ---- - -## Definition -Multi-Account Deployment（多账户部署）是指使用 AWS CloudFormation StackSets 或类似工具，跨多个 AWS 账户和区域自动化部署和管理基础设施的实践。AWS 推荐使用多账户策略来改善安全隔离、成本管理和运营治理。 - -## Core Properties -- **自动化**：通过 StackSets 自动向目标账户推送配置 -- **一致性**：确保所有账户的配置保持一致 -- **可扩展性**：新增账户自动纳入部署范围（auto-deployment） -- **治理**：通过 AWS Organizations OU 层次结构管理账户分组 - -## AWS Recommended Account Structure -- **Management Account**：管理账户，承载中心监控、billing、 Organizations 管理 -- **Log Archive Account**：日志归档账户 -- **Security Tooling Account**：安全工具账户 -- **Workload Accounts**：工作负载账户，部署实际业务资源 - -## Key Mechanisms -- **AWS CloudFormation StackSets**：原生跨账户/跨区域部署服务 -- **AWS Organizations**：账户组织和管理 -- **Service Control Policies (SCPs)**：定义 OU 级别的权限边界 -- **Trusted Access**：启用 StackSets 在成员账户中执行操作 -- **Auto-Deployment**：新增账户自动部署预设 StackSet - -## Related Concepts -- [[AWS CloudFormation StackSets]]：多账户部署的核心工具 -- [[AWS Organizations]]：账户管理和分组 -- [[StackSets Deployment Visibility]]：多账户部署的可观测性挑战和解决方案 -- [[Cross-Account Monitoring]]：多账户部署需要跨账户监控支撑 -- [[Centralized Logging]]：多账户场景是集中日志的主要驱动因素 -- [[Landing Zone Architecture]]：AWS Landing Zone 架构定义了多账户最佳实践 -- [[Infrastructure as Code]]：多账户部署是 IaC 的高级应用场景 - -## Operational Challenges -1. **监控盲区**：跨50+账户部署故障时，逐账户排查效率低下 -2. **配置漂移**：手动配置导致账户间配置不一致 -3. **权限管理**：跨账户 IAM 权限配置的复杂性 -4. **成本追踪**：多账户成本归因和预算控制 - -## Solution Patterns -- [[Centralized Logging]]：集中存储所有账户的 CloudFormation 事件 -- [[Cross-Account Monitoring]]：统一监控界面覆盖所有账户 -- [[StackSets Deployment Visibility]]：CloudWatch Logs Insights 跨账户查询 diff --git a/wiki/concepts/Multi-Agent-Orchestration.md b/wiki/concepts/Multi-Agent-Orchestration.md deleted file mode 100644 index 4e870f9a..00000000 --- a/wiki/concepts/Multi-Agent-Orchestration.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Multi-Agent Orchestration" -type: concept -sources: [workflow-startup-mvp] -last_updated: 2026-04-25 ---- - -## Definition -Multi-Agent Orchestration（多 Agent 编排）指通过预定义的 Agent 角色、交接顺序和质量门控，将多个专业 Agent 组织为流水线化协作体系的过程。 - -## Details -- **核心组件**： - 1. 角色定义（Sprint Prioritizer、UX Researcher、Backend Architect 等） - 2. 交接协议（[[Sequential Handoff]] + [[Context Passing]]） - 3. 并行策略（[[Parallel Agent Work]]） - 4. 质量保证（[[Quality Gate]]） -- **自动化前景**：引入 [[Orchestrator Agent]] 可替代手动编排，实现全自动化流水线 -- **适用场景**：复杂多角色协作任务（SaaS 开发、内容生产、研究分析等） - -## Aliases -- Multi-Agent Orchestration -- 多 Agent 编排 -- Agent Orchestration -- Agent 编排 - -## Related Patterns -- [[Sequential Handoff]] -- [[Parallel Agent Work]] -- [[Quality Gate]] -- [[Context Passing]] - -## Sources -- [[workflow-startup-mvp]] diff --git a/wiki/concepts/Multi-Agent-Team.md b/wiki/concepts/Multi-Agent-Team.md deleted file mode 100644 index 697eeb03..00000000 --- a/wiki/concepts/Multi-Agent-Team.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Multi-Agent-Team" -type: concept -tags: [multi-agent, team-structure, coordination] -sources: [multi-agent-team, nexus-spatial-discovery, workflow-startup-mvp] -last_updated: 2026-04-27 ---- - -## Definition - -多 Agent 团队架构——通过多个专业化 Agent 的分工协作实现复杂任务的系统性解决方案。与流水线式链式执行（[[ContentFactory]]）和流水线编排（[[Agents-Orchestrator]]）同属多 Agent 协作模式的不同维度。 - -## Key Design Principles - -- **角色专业化**：每个 Agent 专注单一领域，避免上下文切换成本 -- **共享记忆 + 私有上下文**：共同 ground（目标/决策）+ 各积累领域专长 -- **单一控制平面**：通过统一入口（Telegram / Discord）控制所有 Agent，降低管理复杂度 -- **定时主动任务**：Agent 主动推送洞察，而非被动等待指令 -- **个性驱动交互**：Agent 个性化（名字 + 沟通风格）使"和团队对话"比"使用工具"更自然 -- **从小开始**：lead + 1 specialist，按瓶颈逐步扩展 - -## Related Patterns - -- [[ContentFactory]]：多 Agent 按内容处理阶段链式执行，强调自动化流水线——与本模式互补，可结合使用 -- [[Agents-Orchestrator]]：流水线编排器，自主管理从规格到交付的完整流程——本模式侧重团队协作，后者侧重流程自动化 -- [[SharedMemory]]：多 Agent 团队协调的核心基础设施 -- [[PrivateContext]]：与 SharedMemory 组合使用 - -## Variants - -- **[[multi-agent-team]]**（Solo Founder Setup）：4 个专业 Agent（Milo 战略lead / Josh 商业分析 / Marketing 内容营销 / Dev 开发）+ Telegram + 定时任务 -- **[[nexus-spatial-discovery]]**：8 个 The Agency 专业 Agent 并行协作，完成产品完整规划 -- **[[workflow-startup-mvp]]**：多 Agent 以周为单位的长周期迭代 -- **[[workflow-landing-page]]**：Landing Page 场景下的多 Agent 一天冲刺 diff --git a/wiki/concepts/Multi-Agent-Unified-MCP.md b/wiki/concepts/Multi-Agent-Unified-MCP.md deleted file mode 100644 index 358d0960..00000000 --- a/wiki/concepts/Multi-Agent-Unified-MCP.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Multi-Agent-Unified-MCP" -type: concept -tags: [ai-agent, mcp, configuration] -sources: [aionui-cowork-desktop] -last_updated: 2026-04-27 ---- - -## Definition - -Multi-Agent-Unified-MCP 是一种在单一应用（AionUi）中统一配置 MCP Server，使其自动同步至所有共存 Agent（OpenClaw、Claude Code、Codex 等）的机制——用户只需配置一次 MCP，所有 Agent 即可共享同一工具集，无需逐个 Agent 重复配置。 - -## Key Characteristics -- **一次配置全局生效**：在 AionUi 中配置 MCP Server，自动同步 -- **消除重复配置**：12+ Agent 共享同一 MCP 配置，无需逐个设置 -- **工具一致性**：所有 Agent 调用相同的 MCP 工具接口 - -## Related Concepts -- [[MCP]]：Multi-Agent-Unified-MCP 的底层协议 -- [[Cowork-UI]]：Multi-Agent-Unified-MCP 的承载界面 diff --git a/wiki/concepts/Multi-AgentHub.md b/wiki/concepts/Multi-AgentHub.md deleted file mode 100644 index c55f05f2..00000000 --- a/wiki/concepts/Multi-AgentHub.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Multi-Agent Hub" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-22 ---- - -# Multi-Agent Hub - -一种软件架构，在一个应用中集中管理多个不同的 AI Agent，支持并行运行、统一配置和跨 Agent 协作。 - -## 核心特征 - -- **多 Agent 并行**：在同一界面同时运行多个 Agent 实例（如 OpenClaw + Claude Code + Codex） -- **统一入口**：单一界面切换不同 Agent，无需在多个应用间跳转 -- **配置共享**：MCP 服务器等配置一次设置，全局生效到所有 Agent -- **能力聚合**：不同 Agent 各有专长（如 Claude Code 擅长代码、OpenClaw 擅长记忆），Hub 提供按需切换或协作的能力 - -## 与 Multi-Agent System 的区别 - -| 维度 | Multi-Agent System | Multi-Agent Hub | -|------|-------------------|-----------------| -| Agent 关系 | 协作分工，共同完成单一任务 | 独立并行，各自有独立任务 | -| 交互模式 | Agent 间互相调用/通信 | 用户在 Hub 中选择/切换 | -| 典型场景 | [[Content-Factory]] 写作链 | [[AionUi]] 多 Agent 并行工作 | - -## 典型实现 - -- [[AionUi]]：支持 OpenClaw + 12+ Agent 的桌面多 Agent Hub -- Claude Code Desktop：多会话管理 -- [[Dynamic-Dashboard]]：多数据源并行抓取子 Agent - -## 关键设计考量 - -- **认证隔离**：每个 Agent 需要独立认证状态（浏览器 Profile 克隆等） -- **MCP 共享**：统一 MCP 配置避免重复设置 -- **资源管理**：多 Agent 并行运行的计算资源分配 -- **上下文切换**：用户在不同 Agent 间的上下文保持 - -## 相关概念 -- [[CoworkWorkspace]]：Hub 中的可视化工作空间 -- [[Parallel Agent Execution]]：Hub 中的并行运行能力 -- [[Shared Memory Architecture]]：多 Agent 间的记忆共享 diff --git a/wiki/concepts/Multi-Channel-Delivery.md b/wiki/concepts/Multi-Channel-Delivery.md deleted file mode 100644 index 2ed4b22b..00000000 --- a/wiki/concepts/Multi-Channel-Delivery.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Multi-Channel-Delivery" -type: concept -tags: [Notification, Delivery, Platform-Integration] -sources: [multi-source-tech-news-digest.md] -last_updated: 2026-04-27 ---- - -# Multi-Channel-Delivery - -多渠道分发——将内容或消息同步推送至多个平台（Discord、邮件、Telegram 等），满足用户在不同场景下的信息消费习惯。 - -## Definition - -同一内容通过多个独立的投递通道（频道）发送，每条通道可能有自己的格式规范、限流规则和用户触达方式。 - -## Common Channels - -| 渠道 | 典型场景 | 特点 | -|------|----------|------| -| Discord | 社区通知、机器人推送 | Webhook、多频道、Rich Embed | -| Email | 正式报告、每日摘要 | MIME 格式、退信处理 | -| Telegram | 即时通知、私聊/频道 | Bot API、Markdown 格式 | -| Slack | 团队协作通知 | Webhook、Block Kit | - -## Design Principles - -- **平台适配**：每条渠道的内容格式需适配（如 Telegram 支持 Markdown，Email 需纯文本 fallback） -- **去重投递**：避免同一用户通过多个渠道收到重复通知 -- **失败重试**：投递失败时的指数退避重试机制 - -## Related Concepts - -- [[Content-Aggregation]]：多渠道分发的内容来源 -- [[Cron-Job]]：定时触发多渠道分发任务的调度机制 diff --git a/wiki/concepts/Multi-Channel-Sequence-Architecture.md b/wiki/concepts/Multi-Channel-Sequence-Architecture.md deleted file mode 100644 index 84cd4fef..00000000 --- a/wiki/concepts/Multi-Channel-Sequence-Architecture.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: "Multi-Channel Sequence Architecture" -type: concept -tags: [sales, outbound, engagement] -sources: [sales-outbound-strategist] -last_updated: 2026-04-25 ---- - -## Definition - -多渠道触达序列架构——在 3-4 周内通过 8-12 次触点跨越多个渠道（Email/LinkedIn/Phone/Video）的出站序列，每次触达必须提供新的价值角度。 - -> "Each touch must add a new value angle. Repeating the same ask with different words is not a sequence — it is nagging." - -## Core Architecture - -**结构：8-12 次触点 / 3-4 周 / 多渠道变化** - -每次触点必须： -1. 使用不同渠道 -2. 提供新的信息角度 -3. 包含一个软性 CTA（永远不重复同样诉求） - -## Channel Selection by Persona - -| Persona | Primary | Secondary | Tertiary | -|---------|---------|-----------|----------| -| C-Suite | LinkedIn InMail | Warm intro/referral | Short direct email | -| VP-level | Email | LinkedIn | Phone | -| Director | Email | Phone | LinkedIn | -| Manager/IC | Email | LinkedIn | Video (Loom) | -| Technical buyers | Email (technical content) | Community/Slack | LinkedIn | - -## Reference Sequence Template (10 Touches) - -``` -Touch 1 (Day 1, Email): Signal-based opening + specific value prop + soft CTA -Touch 2 (Day 3, LinkedIn): Connection request with personalized note (no pitch) -Touch 3 (Day 5, Email): Share relevant insight/data point tied to their situation -Touch 4 (Day 8, Phone): Call with voicemail drop referencing email thread -Touch 5 (Day 10, LinkedIn): Engage with their content or share relevant content -Touch 6 (Day 14, Email): Case study from similar company/situation + clear CTA -Touch 7 (Day 17, Video): 60-second personalized Loom showing something specific to them -Touch 8 (Day 21, Email): New angle — different pain point or stakeholder perspective -Touch 9 (Day 24, Phone): Final call attempt -Touch 10 (Day 28, Email): Breakup email — honest, brief, leave the door open -``` - -## Cold Email Anatomy - -### Subject Line -- 3-5 words, lowercase, looks like internal email -- Reference signal or specificity: "re: the new data team" -- Never clickbait, never ALL CAPS, never emoji - -### Opening Line (Signal-Based) -``` -Bad: "I hope this email finds you well." -Bad: "I'm reaching out because [company] helps companies like yours..." -Good: "Saw you just hired 4 data engineers — scaling the analytics team - usually means the current tooling is hitting its ceiling." -``` - -### Value Proposition -- One sentence connecting their situation to an outcome they care about -- Use their vocabulary, not your marketing copy -- Specificity beats cleverness: numbers, timeframes, concrete outcomes - -### CTA (Single, Clear, Low Friction) -``` -Bad: "Would love to set up a 30-minute call to walk you through a demo" -Good: "Worth a 15-minute conversation to see if this applies to your team?" -Good: "Open to hearing how [similar company] handled this?" -``` - -## Rules of Sequence Design - -1. **Never send without a reason the buyer should care right now** -2. **If you cannot articulate why you are contacting this specific person at this specific company at this specific moment, you are not ready to send** -3. **Do not automate what should be personal, and do not personalize what should be automated** -4. **Test one variable at a time** — changing subject + opening + CTA simultaneously learns nothing -5. **Document what works** — a playbook that lives in one rep's head is not a playbook - -## Connections - -- [[sales-outbound-strategist]] — 序列架构来源 -- [[Signal-Based Selling Framework]] — 序列触发信号来源 -- [[Account Tiering Model]] — 不同层级账户的序列定制程度不同 diff --git a/wiki/concepts/Multi-Cloud-Strategy.md b/wiki/concepts/Multi-Cloud-Strategy.md deleted file mode 100644 index b3407428..00000000 --- a/wiki/concepts/Multi-Cloud-Strategy.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -title: "Multi-Cloud Strategy" -type: concept -sources: [how-can-a-multi-cloud-strategy-transform-your-business-roi, cloud-operating-model-key-strategies-and-best-practices] ---- - -# Multi-Cloud Strategy - -> **Multi-Cloud Strategy** — 使用多个云服务提供商（公有云、私有云或两者结合）来托管工作负载和服务，以避免供应商锁定、增强弹性和优化成本。 - -## Definition - -多云策略（Multi-Cloud Strategy）是指组织同时使用两个或多个云服务提供商的服务。这种策略可以结合不同云服务商的优势，实现： - -- **避免供应商锁定** — 不依赖单一提供商 -- **增强弹性和可用性** — 跨云冗余 -- **优化性能和成本** — 选择最适合每个工作负载的云 -- **满足合规和数据主权要求** — 地理位置控制 - -## Multi-Cloud vs Hybrid Cloud - -| 维度 | Multi-Cloud | Hybrid Cloud | -|------|------------|-------------| -| **定义** | 使用多个公有/私有云 | 公有云 + 私有/本地 | -| **连接** | 可选互联 | 强互联 | -| **用例** | 避免锁定、优化、成本 | 核心在本地、弹性在云 | -| **复杂性** | 中-高 | 中 | -| **成本** | 取决于设计 | 可能更优化 | - -## 8 Business Benefits - -### 1. Avoiding Vendor Lock-In - -- 保留谈判筹码 -- 避免单一供应商涨价风险 -- 灵活迁移工作负载 - -### 2. Enhanced Resilience - -- 跨云冗余消除单点故障 -- 99.99%+ 可用性目标 -- 灾难恢复能力增强 - -### 3. Improved Security - -- 隔离敏感工作负载 -- 利用各云最佳安全功能 -- 满足合规要求 - -### 4. Unlimited Scalability - -- 按需扩展计算资源 -- 全球分布式部署 -- 应对流量高峰 - -### 5. Cost Optimization - -- 选择最具成本效益的云服务 -- 持续成本监控和优化 -- 避免过度配置 - -### 6. Accelerated Innovation - -- 访问最新云服务 -- 快速试验和原型 -- 缩短上市时间 - -### 7. Compliance Fulfillment - -- 数据主权控制 -- 满足地区合规要求 -- 审计和报告能力 - -### 8. Performance Optimization - -- 选择最近/最快的云区域 -- 针对工作负载优化 -- 降低延迟 - -## ROI Maximization Framework - -### 4 Paths to ROI - -1. **Cost Reduction** — 30% 成本降低 -2. **Resource Optimization** — 资源利用率提升 -3. **Efficiency Gains** — 运营效率提升 -4. **Elastic Scaling** — 弹性扩展节省 - -### Industry Adoption - -- 78% 的组织已采用多云策略 -- 平均使用 2-5 个云服务商 -- 混合云和多云是主流趋势 - -## Implementation Roadmap - -``` -Phase 1: Assessment & Strategy -├── 云就绪度评估 -├── 工作负载分析 -└── 供应商选择 - -Phase 2: Foundation -├── 网络连接设计 -├── 安全架构 -└── 治理框架 - -Phase 3: Migration -├── 低风险工作负载优先 -├── 渐进式迁移 -└── 验证和测试 - -Phase 4: Optimization -├── 成本监控 -├── 性能调优 -└── 自动化运维 -``` - -## Key Risks and Mitigation - -| 风险 | 缓解措施 | -|------|---------| -| 复杂性增加 | 统一管理平台 | -| 数据一致性 | 跨云数据同步策略 | -| 安全挑战 | 统一安全策略 | -| 成本超支 | FinOps 实践 | -| 技能缺口 | 培训和认证 | - -## See Also - -- [[Cloud Adoption Strategy]] — 云采用策略 -- [[Cloud Maturity Model]] — 云成熟度模型 -- [[Cloud Governance]] — 云治理 -- [[Cloud Cost Optimization]] — 云成本优化 -- [[Cloud-Native]] — 云原生 -- [[Hybrid Cloud]] — 混合云 -- [[FinOps]] — 云财务管理 diff --git a/wiki/concepts/Multi-Database-Architecture.md b/wiki/concepts/Multi-Database-Architecture.md deleted file mode 100644 index d086d224..00000000 --- a/wiki/concepts/Multi-Database-Architecture.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: "Multi-Database Architecture" -type: concept -tags: - - AWS - - Database - - Architecture - - Polyglot -sources: - - ctp-topic-51-architecting-with-aws-purpose-built-databases -last_updated: 2026-04-28 ---- - -## Overview -多数据库混合架构（Polyglot Persistence）是一种架构模式：在同一个应用系统中，根据不同数据类型和访问模式，选择多个专用数据库组合使用，而非依赖单一数据库。 - -## Aliases -- Polyglot Persistence -- Multi-Database Architecture -- Polyglot Database Architecture - -## Core Pattern -为正确的工作选择正确的工具： -- **事务数据** → 关系型数据库（Aurora/RDS） -- **高频缓存** → 内存数据库（ElastiCache Redis） -- **灵活文档** → 文档数据库（DocumentDB） -- **图关系** → 图数据库（Neptune） -- **时序数据** → 时序数据库（Timestream） - -## Real-World Case Study: Duolingo - -Duolingo 的多数据库架构： - -``` -┌─────────────────────────────────────────────────┐ -│ Duolingo App │ -└──────────────────────┬────────────────────────┘ - │ - ┌─────────────┼─────────────┐ - ▼ ▼ ▼ - ┌──────────┐ ┌───────────┐ ┌──────────┐ - │DynamoDB │ │ElastiCache│ │ Aurora │ - │ │ │ (Redis) │ │ │ - │个性化数据 │ │高频词/短语 │ │事务数据 │ - │ │ │ │ │(支付/账户)│ - └──────────┘ └───────────┘ └──────────┘ -``` - -- **DynamoDB**：用户个性化学习数据，高并发读写 -- **ElastiCache Redis**：高频词/短语缓存，减少数据库访问 -- **Aurora**：支付、用户账户等强一致性事务 - -## Benefits -- **性能最优**：每个数据层使用专门优化的引擎 -- **成本效率**：按需选择，避免为不需要的功能付费 -- **扩展灵活**：各数据库独立扩展，互不干扰 -- **技术适配**：最合适的技术栈解决最合适的场景 - -## Challenges -- **运维复杂度**：多数据库意味着多套运维工具和技能 -- **数据一致性**：跨数据库的分布式事务处理 -- **团队技能**：DBA 需要掌握多种数据库技术 -- **连接管理**：应用层需要管理多个数据库连接池 - -## Connections -- [[Purpose-Built-Databases]]：多数据库架构是专用数据库理念的组织形式 -- [[DBA-Role-Evolution]]：多数据库架构要求 DBA 具备更广的技术视野 -- [[Duolingo]]：Duolingo 是多数据库混合架构的经典生产案例 -- [[Netflix]]：Netflix 也采用多数据库架构支撑大规模流媒体平台 - -## Referenced In -- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]] diff --git a/wiki/concepts/Multi-Profile-Isolation.md b/wiki/concepts/Multi-Profile-Isolation.md deleted file mode 100644 index d41d7887..00000000 --- a/wiki/concepts/Multi-Profile-Isolation.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Multi-Profile-Isolation" -type: concept -tags: [] -sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend] -last_updated: 2026-05-02 ---- - -## Definition -Multi-Profile Isolation 是通过 Hermes Agent 的 Profiles 机制实现多用户/多场景隔离的技术，每个 Profile 运行独立配置、记忆和技能。 - -## Mechanism -Hermes Agent 支持多 Profile： -- **独立配置**：每个 Profile 拥有独立的 `config.yaml`、API 密钥、工具集 -- **独立记忆**：每个 Profile 的会话历史和记忆完全隔离 -- **独立技能**：每个 Profile 可启用不同的 Skills -- **独立端口**：每个 Profile 运行独立 API Server（不同端口） - -## Use Case -- 多用户场景：为不同用户/角色创建独立 Profile -- 多场景场景：开发/测试/生产环境隔离 -- 多 Agent 场景：不同专业 Agent 使用不同 Profile - -## Security Benefits -- 用户间数据完全隔离 -- 配置错误不会相互影响 -- 便于独立管理和备份 - -## Related -- [[Bearer-Token-Authentication]] -- [[OpenAI-Compatible-API]] diff --git a/wiki/concepts/Multi-Tenancy.md b/wiki/concepts/Multi-Tenancy.md deleted file mode 100644 index 89c79cca..00000000 --- a/wiki/concepts/Multi-Tenancy.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: Multi-Tenancy -type: concept -tags: [cloud-computing, architecture, efficiency] -date: 2026-04-19 ---- - -# Multi-Tenancy - -**Multi-Tenancy（多租户架构）** 是一种软件架构模式，多个租户（用户或组织）共享同一底层基础设施、应用实例或资源池，同时通过逻辑隔离确保各租户数据的私密性。 - -## Definition - -多租户架构中，单个应用实例服务多个客户（租户），每个租户的数据和配置相互隔离，但共享计算、存储和网络资源。这是公有云实现规模经济效益的核心技术基础。 - -## How It Works - -``` -┌─────────────────────────────────────────────┐ -│ Cloud Provider Infrastructure │ -│ ┌─────────────────────────────────────┐ │ -│ │ Shared Application Instance │ │ -│ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌────┐ │ │ -│ │ │Tenant│ │Tenant│ │Tenant│ │Tn │ │ │ -│ │ │ A │ │ B │ │ C │ │.. │ │ │ -│ │ └──────┘ └──────┘ └──────┘ └────┘ │ │ -│ └─────────────────────────────────────┘ │ -└─────────────────────────────────────────────┘ -``` - -## Isolation Levels - -| 层级 | 说明 | 示例 | -|------|------|------| -| **数据隔离** | 租户数据逻辑/物理分离 | 独立数据库、独立 Schema、行级隔离 | -| **计算隔离** | 租户工作负载资源分离 | 独立容器、VM、命名空间 | -| **网络隔离** | 网络流量隔离 | VPC、虚拟网络、防火墙规则 | - -## Multi-Tenancy vs Single-Tenancy - -| 维度 | Multi-Tenancy | Single-Tenancy | -|------|--------------|----------------| -| **成本效率** | 高（资源共享） | 低（独占资源） | -| **隔离性** | 逻辑隔离（依赖虚拟化） | 物理隔离（独立基础设施） | -| **运维复杂度** | 高（需精细权限管理） | 低（独立部署） | -| **安全顾虑** | 更高（侧信道风险） | 更低（物理隔离） | -| **适用场景** | 公有云、SaaS | 私有云、高安全合规场景 | - -## In Cloud Context - -- **公有云**：默认多租户模式——多个组织共享同一批服务器 -- **私有云**：通常单租户，但也支持多租户配置（企业内部） -- **混合云**：跨租户数据流动带来额外的安全风险和管理复杂性 - -## Security Implications - -多租户环境下的安全挑战： -- **侧信道攻击**：恶意租户通过共享资源窃取信息 -- **数据泄露风险**：隔离机制失效导致跨租户数据访问 -- **资源竞争**：某一租户的高负载影响其他租户性能 -- **合规冲突**：不同租户的合规要求可能相互矛盾 - -缓解措施：微分段（Micro-segmentation）、零信任架构、加密隔离、Kubernetes 命名空间隔离。 - -## Related Concepts - -- [[Public Cloud]] — 多租户的主要载体 -- [[Private Cloud]] — 可选择多租户或单租户 -- [[Hybrid Cloud]] — 跨租户数据流动带来复杂性 -- [[High-Availability]] — 多租户架构需考虑高可用设计 -- [[Cloud-Security]] — 多租户隔离是云安全的核心议题 - -## Sources - -- [[Public vs Private vs Hybrid Cloud Differences Explained|sources/public-vs-private-vs-hybrid-cloud-differences-explained]] diff --git a/wiki/concepts/Multi-Window-Architecture.md b/wiki/concepts/Multi-Window-Architecture.md deleted file mode 100644 index 6d04e832..00000000 --- a/wiki/concepts/Multi-Window-Architecture.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Multi-Window Architecture" -type: concept -tags: [] -sources: [visionos-spatial-engineer] -last_updated: 2026-04-25 ---- - -## Definition -visionOS 应用的多窗口管理模式，基于 WindowGroup 场景类型，支持 single-instance 窗口、volumetric 展示和空间场景管理。 - -## Window Types -- **Unique Windows（单实例窗口）**：应用主窗口，每次只存在一个实例 -- **Volumetric Presentations（空间展示）**：在 3D volume 内呈现的辅助内容窗口 -- **Spatial Scenes（空间场景）**：完整的 3D 空间应用场景定义 - -## Core Patterns -- **WindowGroup Management**：通过 WindowGroup 管理同类型窗口的生命周期 -- **Glass Background Effects**：每个窗口默认带有 Liquid Glass 风格的毛玻璃背景 -- **Spatial Presentation Hierarchy**：窗口之间的空间层级关系管理 -- **Presentation State**：SwiftUI 状态驱动的窗口展示模式切换 - -## Related Concepts -- [[Spatial Widgets]]：与主窗口协同工作的空间小组件 -- [[Liquid Glass Design System]]：多窗口场景下的统一视觉语言 -- [[Multi-Window Architecture]] — 见本文 - -## Sources -- [[visionos-spatial-engineer]] — visionOS Spatial Engineer Agent 角色定义 diff --git a/wiki/concepts/Multi-factor-Authentication.md b/wiki/concepts/Multi-factor-Authentication.md deleted file mode 100644 index aba012f5..00000000 --- a/wiki/concepts/Multi-factor-Authentication.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "Multi-factor Authentication (MFA)" -type: concept -tags: [cloud-computing, security, identity] -date: 2025-03-02 ---- - -# Multi-factor Authentication (MFA) - -**MFA**（多因素认证）是云安全的基础机制，通过验证两个或多个独立身份凭证来确认用户身份，防止未经授权的访问。 - -## Definition - -多因素认证要求用户提供两种或以上的身份验证因素： -1. **知识因素**（Something you know）：密码、PIN -2. **持有因素**（Something you have）：手机、硬件令牌 -3. **固有因素**（Something you are）：指纹、面部识别 - -## MFA Methods - -| Method | Type | Security Level | -|--------|------|---------------| -| **SMS OTP** | 持有因素 | 中 | -| **TOTP** (Google Authenticator, Authy) | 持有因素 | 高 | -| **Hardware Token** (YubiKey) | 持有因素 | 极高 | -| **Biometrics** | 固有因素 | 高 | -| **Push Notification** | 持有因素 | 高 | -| **Adaptive/ Risk-based MFA** | 组合 | 极高 | - -## Cloud Provider Support - -| Provider | MFA Support | -|----------|------------| -| **AWS** | MFA via IAM, supports hardware tokens, virtual MFA, SMS | -| **Azure** | Azure AD MFA, Conditional Access, passwordless (FIDO2) | -| **Google Cloud** | 2FA, Security Keys, Google Prompt | - -## Cloud Myths Context - -MFA 是反驳"云不安全"误解的核心机制之一： -- 云平台强制或推荐 MFA，显著降低账户被盗风险 -- 云 MFA 实现比大多数本地系统更先进（自适应、条件访问） -- 云服务商的 MFA 通常免费或低成本提供 - -## Best Practices - -- **强制 MFA**：对所有用户强制启用 MFA -- **优先无密码**：FIDO2/WebAuthn 优于传统 OTP -- **条件访问**：高风险操作触发额外验证 -- **保护特权账户**：Admin 账户必须使用硬件令牌 -- **账户恢复**：安全的 MFA 恢复机制 - -## Related Concepts - -- [[cloud-security]] — 云安全 -- [[Identity-and-Access-Management]] — 身份与访问管理 -- [[Zero-Trust]] — 零信任 -- [[cloud-computing]] — 云计算 - -## Sources - -- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]] diff --git a/wiki/concepts/Mythril.md b/wiki/concepts/Mythril.md deleted file mode 100644 index b96fa292..00000000 --- a/wiki/concepts/Mythril.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "Mythril（符号执行分析）" -type: concept -tags: [blockchain, security, smart-contract, symbolic-execution, tooling] -sources: [blockchain-security-auditor] -last_updated: 2026-05-30 ---- - -## Aliases -- Mythril -- Mythril Classic -- Symbolic Execution Analyzer - -## Definition - -Mythril 是基于符号执行（Symbolic Execution）的智能合约安全分析工具，由 Consensys 开发。它通过将合约函数参数替换为符号变量，系统性地探索所有可能的执行路径，寻找可能导致资产损失或合约异常的状态。 - -## Key Features - -- **符号执行**：不依赖具体输入值，遍历所有路径 -- **深度扫描**：适合关键合约的深度分析（比 Slither 慢但更深入） -- **多种漏洞检测**：整数溢出/下溢、时间戳依赖、访问控制、逻辑漏洞 -- **生成攻击场景**：自动生成可触发漏洞的交易序列 - -## Usage - -```bash -# 基本分析 -myth analyze src/MainContract.sol --solc-json mythril-config.json - -# 高级配置 -myth analyze src/MainContract.sol \ - --execution-timeout 300 \ - --max-depth 30 \ - -o json > mythril-results.json - -# 配合 Truffle -mythril truffle compile -mythril analyze --truffle -``` - -## Mythril vs Slither - -| Dimension | [[Slither]] | [[Mythril]] | -|-----------|-------------|-------------| -| Method | AST-based static analysis | Symbolic execution | -| Speed | Fast | Slow | -| Depth | Surface-level | Deep path coverage | -| False positives | Low | Higher | -| Best for | Initial scan, high-confidence bugs | Critical functions, complex logic | - -## Limitations - -- 执行超时限制（通常 5-10 分钟） -- 路径爆炸问题（复杂合约分析不完整） -- 外部依赖处理有限（需要 mock） -- 已被 MythX 商业化版本部分替代 - -## Connections -- [[Blockchain-Security-Auditor]] ← uses ← [[Mythril]] -- [[Slither]] ← complementary analysis ← [[Mythril]] -- [[Formal-Verification]] ← deeper rigor ← [[Mythril]] diff --git a/wiki/concepts/N1QueryPrevention.md b/wiki/concepts/N1QueryPrevention.md deleted file mode 100644 index 3c9e9ed9..00000000 --- a/wiki/concepts/N1QueryPrevention.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "N+1 Query Prevention" -type: concept -tags: [database, performance, n+1, postgresql, query-optimization] -last_updated: 2026-05-01 ---- - -# N+1 Query Prevention - -## Definition - -N+1 查询问题是指应用程序在获取一组主对象后，对每个对象分别发起一次额外查询来获取关联数据的反模式。假设获取 N 个用户，每个用户查一次帖子，总共产生 1 + N 次数据库往返。 - -## The Problem - -```typescript -// ❌ Bad: N+1 pattern -const users = await db.query("SELECT * FROM users LIMIT 10"); -for (const user of users) { - user.posts = await db.query( - "SELECT * FROM posts WHERE user_id = $1", - [user.id] - ); -} -// 1 + 10 = 11 queries -``` - -## The Solution - -```typescript -// ✅ Good: Single query with aggregation -const usersWithPosts = await db.query(` - SELECT - u.id, u.email, u.name, - COALESCE( - json_agg( - json_build_object('id', p.id, 'title', p.title) - ) FILTER (WHERE p.id IS NOT NULL), - '[]' - ) as posts - FROM users u - LEFT JOIN posts p ON p.user_id = u.id - GROUP BY u.id - LIMIT 10 -`); -// 1 query -``` - -## Key Techniques - -- **JOIN + json_agg**：PostgreSQL 下用 `json_agg` 聚合嵌套关联数据 -- **批量查询（Batch Loading）**：拆分为 2-3 次查询（IN 子句分批） -- **预加载（Eager Loading）**：ORM 的 `include` / `preload` 机制 -- **物化视图**：对稳定结构做预计算 - -## Source -- [[engineering-database-optimizer]] - -## Connections -- [[QueryPlanAnalysis]] — 通过 EXPLAIN ANALYZE 识别 N+1 -- [[engineering-backend-architect]] — 架构设计时需避免 N+1 -- [[engineering-sre]] — N+1 是生产环境性能问题的常见根源 diff --git a/wiki/concepts/N8NNodeTypes.md b/wiki/concepts/N8NNodeTypes.md deleted file mode 100644 index 918d64b5..00000000 --- a/wiki/concepts/N8NNodeTypes.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "N8N Node Types" -type: concept -tags: [n8n, workflow, automation, nodes] -sources: [] -last_updated: 2025-05-09 ---- - -## Aliases -- N8N Node Types -- N8N 节点类型 -- N8N Nodes - -## Definition -N8N 工作流自动化平台中节点（Node）的五大类别，每类节点在自动化流程中承担不同的功能角色。理解节点分类是高效构建 N8N 工作流和 AI Agent 的基础。 - -## The Five Node Categories - -### 1. Trigger Nodes（触发节点） -工作流的入口点，负责启动整个流程。 -- **Webhook Trigger**：接收外部 HTTP 请求触发 -- **Schedule Trigger**：定时启动（如 Cron） -- **Manual Trigger**：手动点击运行 -- **Event Triggers**：邮箱新邮件、GitHub Push 等事件触发 - -### 2. Action Nodes（动作节点） -执行具体的操作动作，是工作流的核心执行单元。 -- **数据库操作**：Read/Write/Update/Delete -- **文件操作**：上传、下载、移动 -- **消息发送**：Email、Telegram、Slack 通知 - -### 3. Utility Nodes（工具节点） -提供辅助功能，不直接操作外部系统，而是转换、格式化或处理数据。 -- **Date & Time**：时间格式转换 -- **Code**：运行 JavaScript/Python 代码片段 -- **Move Binary Data**：二进制数据编码转换 - -### 4. Code Nodes（代码节点） -允许在 N8N 工作流中嵌入自定义逻辑，通过 JavaScript 或 Python 编写。 -- 数据转换与复杂计算 -- 自定义业务逻辑 -- 桥接 N8N 不原生支持的 API - -### 5. Advanced AI Nodes（高级 AI 节点） -专为构建 AI Agent 设计的节点类型。 -- **AI Agent**：核心 Agent 节点，连接 LLM，动态选择工具 -- **AI Chain**：构建 LLM 调用链（Chain） -- **Memory**：对话上下文保留 -- **Sub-Nodes**：为 AI Agent 提供工具的子节点 - -## Relationship to Other Concepts -- [[Agentic System]]：Advanced AI 节点是 N8N 实现 Agentic System 的核心手段 -- [[n8n]]：N8N 的全部能力通过节点系统暴露 - -## Sources -- [[n8n-full-tutorial-building-ai-agents-in-2025-for-beginners]] diff --git a/wiki/concepts/N8nWorkflowStandard.md b/wiki/concepts/N8nWorkflowStandard.md deleted file mode 100644 index 9923d652..00000000 --- a/wiki/concepts/N8nWorkflowStandard.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "N8nWorkflowStandard" -type: concept -tags: [] -last_updated: 2026-04-25 ---- - -# N8nWorkflowStandard（n8n 工作流标准） - -## Definition -n8n 编排的生产级工作流必须遵循的 10 步标准结构，确保每个自动化链路具备完整的可靠性、可审计性和可恢复能力。 - -## Ten-Step Structure - -1. **Trigger**（触发器）：工作流的启动条件（定时/Webhook/API/事件） -2. **Input Validation**（输入验证）：校验触发数据格式和必填字段 -3. **Data Normalization**（数据规范化）：统一字段格式、类型转换 -4. **Business Logic**（业务逻辑）：核心处理步骤 -5. **External Actions**（外部操作）：对外部系统的写操作（API 调用、数据库写入） -6. **Result Validation**（结果验证）：确认外部操作返回符合预期 -7. **Logging / Audit Trail**（日志/审计跟踪）：记录完整执行轨迹 -8. **Error Branch**（错误分支）：异常处理的专门路径 -9. **Fallback / Manual Recovery**（降级/人工恢复）：无法自动恢复时的兜底方案 -10. **Completion / Status Writeback**（完成/状态回写）：更新任务状态并通知相关方 - -## Naming Convention -``` -[ENV]-[SYSTEM]-[PROCESS]-[ACTION]-v[MAJOR.MINOR] -``` -示例：`PROD-CRM-LeadIntake-CreateRecord-v1.0` - -规则： -- Major version：破坏性逻辑变更 -- Minor version：向后兼容改进 -- 禁止模糊命名（"final"/"new test"/"fix2"） - -## Related Concepts -- [[ReliabilityBaseline]]：每个工作流必须包含的可靠性组件 -- [[AutomationGovernance]]：治理框架决定哪些工作流值得实施 -- [[IntegrationGovernance]]：外部系统集成的治理规范 - -## Sources -- [[automation-governance-architect]]（primary） diff --git a/wiki/concepts/NFS网络备份.md b/wiki/concepts/NFS网络备份.md deleted file mode 100644 index f6e0f8db..00000000 --- a/wiki/concepts/NFS网络备份.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "NFS网络备份" -tags: [backup, nfs, network-storage, nas] -date: 2026-04-28 ---- - -# NFS网络备份 - -## Definition -NFS（Network File System）网络备份是指通过 NFS 协议将备份数据存储到网络存储设备（如 NAS）的方案。Clonezilla 通过 NFS 将磁盘镜像文件传输到 Synology NAS 等网络存储设备，实现跨设备的集中式备份存储。 - -## Why NFS for Clonezilla? -| 方案 | 优点 | 缺点 | -|------|------|------| -| NFS | Linux 原生支持，稳定可靠 | 需要配置 NFS 服务端 | -| SMB/CIFS | Windows 兼容性好 | 速度稍慢 | -| 外置硬盘 | 简单直接 | 需手动携带，不够自动化 | - -> Clonezilla 官方推荐 NFS 作为首选备份存储方案。 - -## Workflow -``` -源机器 (Clonezilla Live) - → 选择 nfs_server - → DHCP 自动获取 IP（或手动配置静态 IP） - → 输入 NAS IP（如 192.168.3.17） - → 输入 NFS 共享路径（如 /volume2/backups） - → 挂载成功 → 保存镜像到 NAS -``` - -## Prerequisites -1. NAS 端开启 NFS 服务 -2. 配置 NFS 导出（/etc/exports） -3. 源机器与 NAS 网络互通 -4. 防火墙放行 NFS 端口（2049/TCP） - -## Related Concepts -- [[全盘镜像备份]] — NFS 存储的对象类型 -- [[永久挂载]] — NFS 备份前需先完成永久挂载配置 -- [[增量备份]] — 互补方案（NFS 镜像 vs rsync 增量） -- [[裸机恢复]] — 从 NFS 镜像还原系统 - -## Related Sources -- [[clonezilla对ubuntu-server进行全盘镜像备份]] -- [[ubuntu服务器通过rsync实现日常增量备份]] -- [[如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹]] -- [[rsync]] — Entity 页面 diff --git a/wiki/concepts/NUMA.md b/wiki/concepts/NUMA.md deleted file mode 100644 index fb66ff5d..00000000 --- a/wiki/concepts/NUMA.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "NUMA" -type: concept -tags: [sre, performance, cloud, containers, cpu] -last_updated: 2026-04-20 ---- - -# NUMA (Non-Uniform Memory Access) - -NUMA（非一致性内存访问）是一种多处理器计算机架构中的内存访问模式，对现代容器化部署有重要影响。 - -## Definition -在 NUMA 架构中，CPU 和内存被组织成多个节点（nodes）。每个 CPU 访问本地内存节点的速度远快于访问远程内存节点的速度，因此称为"非一致性"内存访问。 - -## Key Concepts -- **NUMA Node**：由一个或多个 CPU 和与其相连的内存组成 -- **Local Memory Access**：CPU 访问本节点的内存，延迟低、带宽高 -- **Remote Memory Access**：CPU 访问其他节点的内存，延迟高、带宽低 -- **CPU Pinning**：将进程/容器固定到特定 CPU，以优化内存局部性 - -## Why SREs Should Care -Netflix 在现代 CPU 上运行容器时发现： -- 运行 100 个容器需要超过 **2 万次挂载操作（mounts）** -- NUMA 问题是影响容器调度性能的关键因素 -- SRE 必须关注**整个技术栈**，包括硬件层面的 NUMA 拓扑 - -## Implications for Container Scheduling -1. **NUMA-Aware Scheduling**：调度器应感知 NUMA 拓扑，避免跨节点内存访问 -2. **CPU Pinning**：对延迟敏感的应用（如 Netflix 媒体处理）需要将容器固定到特定 CPU -3. **内存局部性优化**：减少跨 NUMA 节点的内存访问可显著降低延迟 - -## Related Concepts -- [[Containers]] -- [[Kubernetes]] -- [[Performance-Benchmarking]] -- [[Cloud-Native]] - -## Source -- SRE Weekly Issue #513 — [[sre-weekly-issue-513]] (Netflix Mount Mayhem case study) diff --git a/wiki/concepts/NVMe硬盘分区.md b/wiki/concepts/NVMe硬盘分区.md deleted file mode 100644 index 4481dccf..00000000 --- a/wiki/concepts/NVMe硬盘分区.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "NVMe硬盘分区" -type: concept -tags: [nvme, linux, partition, ubuntu] -date: 2026-04-14 -aliases: [NVMe, NVMe SSD, PCIe SSD] ---- - -# NVMe硬盘分区 - -## Definition -针对 NVMe PCIe 固态硬盘的分区策略与对齐优化。Ubuntu 24.04 自动识别 ZBook 等设备上的 NVMe 硬盘并进行对齐优化，但仍建议手动分区时遵循标准规范。 - -## HP ZBook NVMe 分区方案 -| 分区 | 挂载点 | 大小 | 文件系统 | 说明 | -|------|--------|------|----------|------| -| EFI System | /boot/efi | 512MB - 1GB | FAT32 | 存储 UEFI 引导程序（必须） | -| Root | / | 100GB - 200GB | ext4 | 系统文件、Docker、应用程序 | -| Home | /home | 剩余空间 | ext4 | 独立分区，重装可保留数据 | -| Swap | swap | 8GB - 32GB | swap | 根据内存大小，建议为内存 1 倍 | - -## Key Alignment Rules -- 分区起始扇区：默认 2048（与 NVMe 块大小对齐） -- Ubuntu 24.04 自动应用最佳对齐 -- 分区方案：**GPT**（NVMe 2TB+ 支持必须） - -## Why ext4 for NVMe -虽然 Ubuntu 24.04 支持 ZFS/Btrfs 高级文件系统，但对 Docker 环境和 HP ZBook 来说，ext4 的兼容性、稳定性和性能预测性最优。 - -## Related -- [[HP ZBook]] — 目标设备（NVMe 硬盘） -- [[GPT分区表]] — 分区表方案 -- [[Ubuntu 24.04]] — 操作系统 -- [[NVMe硬盘分区]] ← 针对 [[HP ZBook]] ← [[GPT分区表]] - -## Sources -- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]] — HP ZBook NVMe 分区方案（GPT/ext4/+swap/swap） -- [[clonezilla对ubuntu-server进行全盘镜像备份]] diff --git a/wiki/concepts/Nanite.md b/wiki/concepts/Nanite.md deleted file mode 100644 index 8ddfbc5e..00000000 --- a/wiki/concepts/Nanite.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "Nanite" -type: concept -tags: ["unreal-engine", "geometry", "rendering", "lod"] -sources: ["unreal-systems-engineer", "unreal-technical-artist", "unreal-world-builder"] -last_updated: 2026-04-30 ---- - -## Aliases -- UE5 Nanite -- Virtualized Geometry -- 虚拟化几何系统 - -## Definition -Nanite 是 Unreal Engine 5 引入的虚拟化几何系统，能够自动处理亚像素级别的几何细节，无需手动 LOD。它以软件光栅化方式运行，支持亿级三角形规模的几何细节，并且与 World Partition 和 PCG 系统天然集成。 - -## Core Characteristics -- **无需手动 LOD**：自动从极高面数几何体流式加载 -- **实例计数优势**：PCG 实例数量轻易超过 Nanite 的优势阈值 -- **排除在 HLOD 之外**：Nanite 自身处理 LOD，不与其他 Actor 合并 -- **支持几何体类型**：StaticMesh（启用时）、Foliage（启用时） - -## Performance Constraints -- **Nanite 实例数上限**：16M（在最大视距/最大关卡） -- **Draw Call 控制**：配合 Nanite 实例化减少 Draw Calls -- **资产启用原则**：所有静态网格在条件允许时优先启用 Nanite - -## Integration with PCG -PCG 放置的资产应在条件允许时启用 Nanite，典型配置： -- 40% Oak（Nanite 启用） -- 30% Pine（Nanite 启用） -- 20% Birch（Nanite 启用） -- 10% DeadTree（非 Nanite — 手动 LOD 链） - -## Nanite + Landscape -Nanite 与 Landscape 系统协同工作，LOD 转换在远距离时由 Nanite 系统自动管理。 - -## Connections -- [[UnrealEngine5]] ← 核心引擎 ← Nanite -- [[UnrealWorldBuilder]] ← 几何渲染 ← Nanite -- [[UnrealSystemsEngineer]] ← 几何系统 ← Nanite -- [[UnrealTechnicalArtist]] ← 资产验证 ← Nanite -- [[HierarchicalLOD]] ← 互补（非 Nanite 资产） ← Nanite - -## Sources -- [[unreal-systems-engineer]] -- [[unreal-technical-artist]] -- [[unreal-world-builder]] diff --git a/wiki/concepts/Narrative-Debt-Tracking.md b/wiki/concepts/Narrative-Debt-Tracking.md deleted file mode 100644 index c1453cea..00000000 --- a/wiki/concepts/Narrative-Debt-Tracking.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: "Narrative Debt Tracking" -type: concept -tags: [game-narrative, project-management, storytelling] -sources: [narrative-designer.md] -last_updated: 2026-04-26 ---- - -# Narrative Debt Tracking - -叙事债务追踪——管理游戏叙事中"伏笔承诺"与"兑现义务"的系统，防止叙事烂尾和玩家信任流失。 - -## Definition - -叙事债务类似于技术债务：你在故事中埋下的伏笔（foreshadowing）和承诺（dangling threads），都是对玩家的隐性承诺。如果不兑现，就欠下了叙事债务。 - -## Core Components - -### 1. Foreshadowing（伏笔） -- 早期向玩家暗示后期会发生的事件 -- 必须清晰到玩家能认出，但又模糊到不会猜到具体内容 -- **示例**：Act 1 中一个看似无害的道具，在 Act 3 中成为关键物品 - -### 2. Dangling Threads（悬而未决的线索） -- 叙事中引入但尚未解答的问题 -- 玩家会期待解答——如果等太久，耐心会变成失望 -- 需要主动管理：在引入悬案之前，先规划好解答时机 - -### 3. Promises（承诺） -- 叙事向玩家暗示"会发生什么" -- **类型**： - - Genre promise（类型承诺）：动作游戏会有激烈战斗 - - Character promise（角色承诺）：某角色会做出某种选择 - - World promise（世界承诺）：某个地点会有特殊意义 - -## Tracking System - -### 必须记录的字段 -``` -Foreshadowing ID: [唯一标识] -First Appeared: [场景/节点] -Nature: [类型：对象/事件/关系/真相] -Expected Resolution: [预期场景/节点] -Status: [Open / Resolved / Retired] -Resolution Note: [如何解决或退役] -``` - -### Debt Retirement（债务退役） -如果某个伏笔因为设计变更无法兑现，必须**主动退役**： -1. 在叙事中引入一个场景，说明该线索已不再相关 -2. 不让它悬在空中——主动关闭比留给玩家自己推理更好 -3. 记录退役原因，作为团队参考 - -## Why It Matters - -- **玩家信任**：不兑现的承诺会让玩家觉得叙事不可信 -- **发行风险**：叙事债务在游戏上线后难以修复 -- **团队效率**：早期追踪可避免后期大幅重写 - -## Narrative Debt 与 Delayed Consequence - -Narrative Debt Tracking 是 [[Choice Architecture]] 中"延迟后果"设计的执行层： -- Choice Architecture 定义**何时**欠下债务（选择时） -- Narrative Debt Tracking 管理**如何**偿还债务（交付时） - -## Related Concepts -- [[Choice Architecture]]：延迟后果是叙事债务的主要来源 -- [[Lore Architecture]]：World Bible 中的 Banned Retcons 是永不到期的债务 -- [[Branching Narrative]]：分支选择必须追踪其后果债务 - -## Sources -- [[Narrative Designer Agent Personality]] — Transmedia and Living World Narrative / Narrative Debt diff --git a/wiki/concepts/Narrative-Debt.md b/wiki/concepts/Narrative-Debt.md deleted file mode 100644 index 3c698ed8..00000000 --- a/wiki/concepts/Narrative-Debt.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "叙事债务" -type: concept -tags: [narratology, story-structure, Chekhovs-gun, promise-theory] -sources: ["academic-narratologist"] -last_updated: 2026-05-02 ---- - -## Definition - -**叙事债务**（Narrative Debts）是 [[academic-narratologist]] 提出的叙事质量评估概念，指叙事者向读者做出的**尚未兑现的承诺**——与金融债务类似，未偿还的叙事债务会累积利息（读者期待），最终影响整体叙事质量。 - -核心理念源自 **Chekhov's Gun**（契诃夫之枪）原则：如果第一幕中出现了枪，第三幕必须让它响——任何叙事元素一旦被引入，就对读者构成隐性承诺。 - -## 债务类型 - -| 类型 | 描述 | 示例 | -|------|------|------| -| **Setup Debt**（伏笔债务） | 埋下伏笔但未回收 | 第一幕出现的神秘物件，第三幕未交代 | -| **Question Debt**（悬念债务） | 提出问题但未回答 | 反派身份暗示，结局未揭示 | -| **Promise Debt**（期望债务） | 建立期待但未满足 | 主角的独特能力，结局未使用 | -| **Thematic Debt**（主题债务） | 引入主题但未深化 | 故事提出道德困境，结局未回应 | - -## 与 Fabula-Sjuzhet 的关系 - -叙事债务存在于 **sjuzhet**（叙事）层面——是叙事者通过叙事手法向读者做出的承诺，而非事件（fabula）层面的属性。 - -- 伏笔（setup）在 sjuzhet 中被呈现 -- 回收（payoff）在 sjuzhet 中被揭露 -- 两者之间的时间跨度越大，债务利息（读者张力）越高 - -## 债务管理原则 - -[[academic-narratologist]] 提出的核心原则： - -1. **不埋无法回收的伏笔**：每个 setup 都必须有对应的 payoff -2. **主动管理期望**：通过 sjuzhet 主动降低无法偿还的债务（放弃悬念） -3. **债务可视化**：追踪所有 open debts 并定期审计 -4. **利息计算**：长时间未偿还的债务会积累读者不耐烦 - -## 评估清单 - -在 [[academic-narratologist]] 的 Story Structure Analysis 框架中，Narrative Debts 是必须报告的检查项： - -``` -Narrative Debts: [Promises made to the reader not yet fulfilled] -``` - -## Related Concepts - -- [[Fabula-Sjuzhet]]：债务产生于 sjuzhet 层面 -- [[Chekhovs-Gun]]：叙事债务的理论根源 -- [[Character-Arc]]：角色弧光中的 Lie 信念也是一种叙事债务（角色对自我的承诺） diff --git a/wiki/concepts/Narrative-Gameplay-Integration.md b/wiki/concepts/Narrative-Gameplay-Integration.md deleted file mode 100644 index 2235e3c9..00000000 --- a/wiki/concepts/Narrative-Gameplay-Integration.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: "Narrative-Gameplay Integration" -type: concept -tags: [game-narrative, game-design, systems-integration] -sources: [narrative-designer.md] -last_updated: 2026-04-26 ---- - -# Narrative-Gameplay Integration - -叙事-玩法整合——确保故事节拍与游戏机制后果对齐的设计矩阵，确保玩家的叙事体验与玩法体验相互强化而非相互剥离。 - -## Core Rule - -**Every major story beat must connect to a gameplay consequence or mechanical shift.** - -故事不是插入在游戏之间的东西——故事和游戏是同一个系统的两个维度。 - -## Integration Matrix - -| 故事节拍 | 游戏机制后果 | 玩家感受 | -|---------|------------|---------| -| 盟友背叛 | 失去升级商人访问权限 | 失落感，重新校准 | -| 真相揭示 | 解锁新区域，敌人被重新语境化 | 顿悟，紧迫感 | -| 角色死亡 | 失去他们教会玩家的机制 | 悲伤，赌注感 | -| 玩家选择：宽恕 | 派系声望变化 + 支线任务 | 代理感，后果感 | -| 世界事件 | 全球环境 NPC 对话改变 | 世界是活的 | - -## Critical Principles - -### 1. Agency Parity（代理权平等） -> "Player agency in story must match player agency in gameplay — don't give narrative choices in a game with no mechanical choices." - -如果游戏机制层面玩家没有选择权，叙事层面也不应该有。选择必须在两个层面同时存在或同时不存在。 - -### 2. 叙事引导的教学 -- 新手引导和 onboarding 内容必须叙事驱动 -- **错误**："因为这是教程"——玩家知道这是教程，效果打折 -- **正确**："因为角色解释了它"——叙事动机让教学变得自然 - -### 3. Emergent Narrative（涌现式叙事） -通过系统驱动的叙事，而非全预制脚本： -- 派系声望值 -- 关系数值 -- 世界状态标志（World State Flags） - -**Narrative Surfacing**：当系统性事件越过阈值时，触发预设叙事评论，让涌现感显得有意图。 - -### 4. Authored vs. Emergent 的边界 -- 玩家必须**注意不到**预制叙事与涌现叙事之间的接缝 -- 边界必须精心设计，不能让玩家感到"这条叙事不是我触发的" - -## Narrative Query Systems - -世界根据玩家做过的事做出回应： -- 系统查询玩家数据 → 生成个性化叙事瞬间 -- 不只是"你的对话选项变了"，而是"世界的反应完全因你而变" - -## Success Metrics -- 100% 主要故事节拍有对应游戏机制后果 -- 玩家调查中，叙事与玩法"一体化"感受评分 ≥ 4.5/5 - -## Related Concepts -- [[Branching Narrative]]：分支选择的后果是整合矩阵的具体实例 -- [[Environmental Storytelling]]：环境叙事是无声的机制信号 -- [[AdaptiveMusic]]：音频层响应叙事节奏，与叙事-玩法整合协同 -- [[Choice Architecture]]：选择的后果通过整合矩阵实现 - -## Sources -- [[Narrative Designer Agent Personality]] — Narrative-Gameplay Integration diff --git a/wiki/concepts/NarrativeArchitecture.md b/wiki/concepts/NarrativeArchitecture.md deleted file mode 100644 index 68d56eab..00000000 --- a/wiki/concepts/NarrativeArchitecture.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Narrative Architecture" -type: concept -tags: ["writing", "structure", "coherence", "storytelling"] -sources: ["marketing-book-co-author"] -last_updated: 2026-04-30 ---- - -## Definition - -叙事架构（Narrative Architecture）是指在长篇思想领导力书籍中，维护贯穿全书各章节的"红色主线"（Red Thread），使书籍呈现为连贯论证而非独立散文的堆砌。叙事架构师负责确保每一章都服务于全书的核心论点，各章节之间形成有机递进或呼应关系。 - -## Core Principles - -1. **单一主线贯穿**：全书必须围绕一个核心命题展开，所有章节直接或间接服务于该命题 -2. **章节逻辑递进**：章节之间存在清晰的思想推进路径，而非随机排列 -3. **开头呼应结尾**：全书开篇提出的问题或张力，应在结尾得到回应 -4. **避免重复冗余**：每个章节有独特战略功能，不与相邻章节内容重叠 -5. **叙事锚点设计**：在关键章节设置叙事锚点，强化读者记忆和认同 - -## The Red Thread Concept - -"红色主线"（Red Thread）是叙事架构的核心隐喻： -- **视觉隐喻**：如同红线贯穿珍珠项链，各章节是珍珠，主线是串联的逻辑 -- **功能要求**：读者在读完任何章节后，都能自然期待下一章的内容 -- **检验标准**：如果删除某一章，全书的论证链条是否断裂 - -## Related Concepts -- [[Thought Leadership Book]] — 思想领导力书籍是叙事架构的主要应用场景 -- [[Voice Protection]] — 叙事架构不能破坏作者个人声音 -- [[First-Person Business Writing]] — 叙事架构服务于第一人称叙事 diff --git a/wiki/concepts/NarrativeTheory.md b/wiki/concepts/NarrativeTheory.md deleted file mode 100644 index 30f30f7c..00000000 --- a/wiki/concepts/NarrativeTheory.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Narrative Theory" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-30 ---- - -## Aliases -- Narratology -- 叙事学 -- Narrative Studies - -## Overview -Narrative Theory（叙事学）是研究叙事的结构、机制、功能和认知的跨学科学术领域。起源于 Russian Formalism（俄罗斯形式主义），经 French Structuralism（法国结构主义）发展，在 Cognitive Narratology（认知叙事学）时代达到现代高峰。 - -## Major Schools & Figures - -| School | Key Figure | Core Idea | -|--------|-----------|-----------| -| Russian Formalism | Shklovsky, Propp | Fabula/Sjuzhet, Defamiliarization | -| French Structuralism | Barthes, Genette, Todorov | Narrative as language system | -| Cognitive Narratology | Herman, Fludarnik | Mental models, situation models | -| Post-Classical | Various | Contextual, cultural, ideological | - -## Key Distinctions -- **Fabula vs. Sjuzhet**：事件序列（what happened）vs. 叙事呈现（how it is told） -- **Story vs. Discourse**：同 Fabula/Sjuzhet -- **Narrative Voice vs. Focalization**：谁在讲 vs. 谁在看 -- **Anachrony**：Analeptic（倒叙）/Proleptic（预叙） - -## In The Agency Context -[[Academic Narratologist]] 的核心知识基础，综合运用以上所有框架为叙事问题提供精确诊断。 diff --git a/wiki/concepts/National-Annex.md b/wiki/concepts/National-Annex.md deleted file mode 100644 index ba46d2b3..00000000 --- a/wiki/concepts/National-Annex.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: "National Annex" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-25 ---- - -## Aliases -- National Annex to Eurocode（Eurocode 国家附录） -- NDPs（Nationally Determined Parameters，国家确定参数） -- 欧洲规范国家附录 -- 欧盟规范本地化修订 - -## Definition - -National Annex（国家附录）是各 Eurocode 成员国对 EN 1990–1999 系列规范的本地化修订文件，通过国家确定参数（NDPs）改变 Eurocode 默认值，从而在 Eurocode 框架内实现各国不同的安全等级和设计偏好。National Annex 是 Eurocode 体系内**规范冲突的主要来源**。 - -## What National Annexes Modify - -### 1. Nationally Determined Parameters (NDPs) -Eurocode 规范中的部分参数由各成员国自行确定，包括： - -| 参数类型 | 示例 | 影响 | -|---------|------|------| -| 荷载分项系数 γ | Eurocode 默认 γG=1.35, γQ=1.5 | 英国 NA 可能调高 γG | -| 组合系数 ψ | Eurocode 默认 ψ0=0.7（办公室活荷载） | 各国可能不同 | -| 可靠度系数 γM | Eurocode 默认 γM0=1.0, γM1=1.0 | 影响构件抗力 | -| 安全等级 | 从 RC1/RC2/RC3 选择 | 影响 γF 和 γM | -| 地震重要性系数 γI | EN 1998 Default = 1.0 | 各国可调高 | -| 地震谱形状 | 与 EN 1998-1 附录相同 | 部分国家有修订 | - -### 2. Informative Annexes -- Eurocode 各部分包含"资料性附录"，各国可选择采纳或废弃 - -### 3. National Deviations -- 超出 Eurocode 框架的额外要求（如特定材料标准、构造细节） - -## Major National Annexes - -| 国家 | 缩写 | 关键差异 | -|------|------|---------| -| United Kingdom | UK NA to BS EN | 风荷载高度系数（UK 地形更粗糙）、地震分区 | -| Germany | NA DE | DIN 标准兼容性处理、高延性 DCH 要求严格 | -| France | NF EN | 混凝土抗压强度等级（法标与欧标衔接） | -| Netherlands | NTA | 地基与岩土设计有特殊附录 | -| Sweden | EKS | 风荷载暴露系数（瑞典多森林地形） | -| Norway | NA NO | 地震要求（挪威北部有地震风险） | - -## Why National Annexes Create Conflicts - -**同一结构在两个国家可能需要不同设计：** - -``` -场景：钢框架建筑，巴黎 vs 伦敦 - -设计输入： - - 结构系统：钢框架 - - 跨度：8m - - 活荷载：5 kN/m² - -英国 (UK NA to BS EN 1993-1-1)： - - γG = 1.35, γQ = 1.50 - - 截面分类界限按 UK NA 修正 - - 风荷载：UK NA 按暴露度 C（郊区地形） - -法国 (NF EN)： - - γG = 1.35, γQ = 1.50（与 EN 默认相同） - - 截面分类按 EN 默认值 - - 风荷载：NF EN 规定暴露类别和系数 - -结果：相同结构在 UK 和 FR 可能需要不同构件尺寸 -``` - -## Multi-Standard Projects and National Annexes - -在涉及 Eurocode + 另一标准（如 ACI 318）的多标准项目中，National Annexes 的处理流程： - -1. **识别所有适用的 National Annex**（项目所在国 + 业主所在国） -2. **列出 NDPs 与 EN 默认值的偏差** -3. **评估偏差对设计结果的影响** -4. **在 Basis of Design 中记录最终采用的 NDPs** -5. **向 AHJ（主管当局）确认接受哪些 National Annex 版本** - -## Usage in Civil Engineer Agent - -Civil Engineer Agent 处理 Eurocode 项目时，**必须**在每个计算包开头注明： -1. 所采用的 Eurocode EN 标准编号和版本年份 -2. 所适用的 National Annex（如 NA to BS EN 1993-1-1） -3. 所有与 EN 默认值不同的 NDPs（列表形式） -4. **铁律**：绝不在 Eurocode 公式中混入 ACI/AISC 的分项系数 diff --git a/wiki/concepts/Negative-Prompting.md b/wiki/concepts/Negative-Prompting.md deleted file mode 100644 index 01cb7f3c..00000000 --- a/wiki/concepts/Negative-Prompting.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Negative Prompting" -type: concept -tags: [prompt-engineering, ai-image-generation, exclusion] -last_updated: 2026-05-15 ---- - -## Definition - -负向提示词（Negative Prompting）——通过明确指定不想要的内容元素，主动排除 AI 生成图像中的干扰元素和常见缺陷，提升生成结果的可控性和专业度。 - -## Mechanism - -在支持负向提示词的 AI 平台（Midjourney、Stable Diffusion）中，用户通过专门的语法（`--no`、`negative_weights`、`NOT` 等）指定需要排除的元素。 - -## Common Negative Prompt Categories - -- **图像缺陷**：blurry、noise、grain、artifact、distortion、overexposed、underexposed -- **不想要的对象**：watermark、text、logo、signature、frame、border -- **构图元素**：background clutter、distracting elements、unwanted objects -- **质量相关**：low quality、jpeg artifacts、compression artifacts -- **风格相关**：cartoonish（当需要写实风格时）、oversaturated、overprocessed - -## Best Practices - -- 针对性而非泛化：只排除确实不想要的特定元素，不过度使用 -- 与正向提示词协同：负向提示词补充而非替代正向提示词 -- 平台适配：各平台负向提示词语法和支持程度不同（Midjourney 的 `--no`、SD 的 negative embeddings） - -## Connections - -- [[Five-Layer-Prompt-Structure]] 的组成部分（在结构框架中标注负向提示词位置） -- [[Midjourney]] / [[Stable-Diffusion]] 平台的核心功能 -- [[Prompt-Engineering]] 的关键技术之一 - -## Aliases - -- Negative Prompt -- Exclusion Prompt -- NOT Prompt -- 负向提示词 diff --git a/wiki/concepts/NegativePromptingLibrary.md b/wiki/concepts/NegativePromptingLibrary.md deleted file mode 100644 index 577db0d4..00000000 --- a/wiki/concepts/NegativePromptingLibrary.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Negative Prompting Library" -type: concept -tags: [prompt-engineering, generative-ai, bias-mitigation, image-generation, video-generation] -sources: [design-inclusive-visuals-specialist] -last_updated: 2026-04-24 ---- - -## Definition -AI 图像/视频生成中显式列举"应避免生成的内容"的约束库——通过负向提示词告知模型不要生成特定元素，是对抗 AI 幻觉（克隆脸、乱码符号、超现实瑕疵等）的核心技术手段。 - -## Use Cases - -### Image Generation (Midjourney/DALL-E/Flux) -- No cloned faces — 强制面部结构差异 -- No gibberish text or symbols — 避免非英语文字幻觉 -- No generic "stock photo" smiles — 避免库存照片套路 -- No oversized cultural symbols dominating composition — 避免英雄符号构图 -- No extra fingers, unnatural lighting on dark skin — 避免物理失真 - -### Video Generation (Sora/Runway) -- No cloned background actors — 背景人物必须展现交叉性差异 -- No text or symbols on whiteboards/screens — 避免文字幻觉 -- No futuristic/sci-fi tropes in real-world contexts — 避免超现实元素混入写实场景 -- No physics errors on mobility aids — 轮椅/拐杖/假肢运动一致性 - -## Related Concepts -- [[InclusiveVisuals]]（负向约束的主要应用域） -- [[PromptEngineering]]（整体提示词工程） -- [[AIArtifactElimination]]（AI 伪影消除） diff --git a/wiki/concepts/Net-Revenue-Retention.md b/wiki/concepts/Net-Revenue-Retention.md deleted file mode 100644 index b4b31555..00000000 --- a/wiki/concepts/Net-Revenue-Retention.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Net Revenue Retention (NRR)" -type: concept -tags: [] -last_updated: 2026-04-25 ---- - -## Definition - -Net Revenue Retention（净收入留存率，NRR）是衡量 SaaS/订阅业务健康度的终极指标，在一个固定时间段内（通常为月度或年度），以单一数字捕获了扩张收入、收缩和客户流失对总收入的影响。 - -## Formula - -``` -NRR = (Starting ARR - Contraction - Churn + Expansion) / Starting ARR × 100% -``` - -## Interpretation - -| NRR Range | Interpretation | -|-----------|----------------| -| >130% | 世界级 — 强劲扩张文化，几乎无流失 | -| 110-130% | 优秀 — 健康的产品驱动增长 | -| 100-110% | 合格 — 需要加强扩张执行力 | -| <100% | 危险 — 流失超过扩张，需要立即干预 | - -**NRR > 100% 意味着即使不获取任何新客户，现有客户也能驱动业务增长。** - -## Why NRR > Bookings - -- **Bookings**（新合同金额）反映销售能力，但忽视现有客户的健康 -- **NRR** 反映产品价值和客户成功的实际成效 -- 过度关注 Bookings 会鼓励向不健康账户推扩张，加速流失 -- 健康的 SaaS 业务应将 NRR 视为北极星指标 - -## Connection -- [[Land-and-Expand]] — NRR 是 Land-and-Expand 策略的终极验证指标 -- [[Account Health Score]] — NRR 来自账户健康评分的长期积累 -- [[sales-account-strategist]] — Account Strategist Agent 的核心成功指标 -- [[Churn Prevention Playbook]] — 流失直接拉低 NRR diff --git a/wiki/concepts/NetUpdateFrequency.md b/wiki/concepts/NetUpdateFrequency.md deleted file mode 100644 index ac4ce467..00000000 --- a/wiki/concepts/NetUpdateFrequency.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "NetUpdateFrequency" -type: concept -tags: ["unreal-engine", "networking", "performance"] -sources: ["unreal-multiplayer-architect", "unreal-multiplayer-architect"] -last_updated: 2026-04-30 ---- - -## Aliases -- 网络更新频率 -- 复制频率 - -## 定义 -`NetUpdateFrequency` 是 UE5 中控制 Actor 复制频率的参数，单位为 Hz（每秒更新次数）。默认 100Hz 通常过高，应按 Actor 类型差异化配置。 - -## 默认值问题 -- 默认 `NetUpdateFrequency = 100Hz` 对大多数 Actor 过高 -- 造成不必要的带宽消耗 -- 服务器 CPU 负担增加 - -## 差异化配置建议 - -| Actor 类型 | NetUpdateFrequency | MinNetUpdateFrequency | 说明 | -|-----------|-------------------|---------------------|------| -| 高速投射物 | 100Hz | 33Hz | 精度关键 | -| 玩家角色 | 30Hz | 15Hz | 平衡流畅与带宽 | -| NPC 敌人 | 20Hz | 5Hz | 非玩家，可插值 | -| 环境物体 | 2Hz | 1Hz | 状态极少变化 | - -## 实现方式 -```cpp -// 在 Actor 构造函数中设置 -AMyProjectile::AMyProjectile() { - bReplicates = true; - NetUpdateFrequency = 100.f; - MinNetUpdateFrequency = 33.f; -} -``` - -## 性能影响 -- 每玩家带宽目标 < 15KB/s -- 最高玩家数量下测量 -- 使用 Network Profiler 验证 - -## 相关概念 -- [[Actor Replication]] — NetUpdateFrequency 控制复制频率 -- [[Replication Graph]] — 与复制图配合优化 -- [[Server-Authoritative Model]] — 优化不影响权威模型 diff --git a/wiki/concepts/Network-Prediction.md b/wiki/concepts/Network-Prediction.md deleted file mode 100644 index a7f513a8..00000000 --- a/wiki/concepts/Network-Prediction.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Network Prediction" -type: concept -tags: [] -sources: [unreal-multiplayer-architect] -last_updated: 2026-04-26 ---- - -## Definition -网络预测是 UE5 多人游戏中减少客户端感知延迟的核心技术。客户端在发送输入到服务器的同时，本地执行游戏逻辑（预测结果），当服务器确认结果返回时，客户端对比并调和（Reconcile）任何差异。 - -## Why It Matters -即使服务器在 100ms 后才返回结果，客户端通过预测可以让玩家感受到即时响应： - -``` -客户端发送输入 → 本地预测执行 → 显示预测结果（立即）→ 服务器执行 → 客户端调和（100ms后） -``` - -## Prediction in UE5 -- **Movement Prediction**：角色移动在客户端本地预测 -- **Ability Prediction (GAS)**：`FPredictionKey` 标记所有预测变更，服务器确认或回滚 -- **Reconciliation**：服务器权威结果与客户端预测结果对比时，自动校正客户端状态 - -## Key Methods -- `NetMulticast Unreliable` — 服务器向所有客户端广播，用于触发预测性的视觉效果 -- `FPredictionKey` — GAS 中的预测键，标记可预测的能力和属性变更 -- `p.NetShowCorrections 1` — 调试命令，可视化调和事件 - -## Prediction Pitfalls -- 过度预测会导致大量回滚（Rollback），影响游戏体验 -- 仅预测确定性输入（移动、射击）——不预测随机事件 -- 在高延迟（>200ms）环境下需要特别调优预测容差 - -## Connection to Other Concepts -- [[Server-Authoritative Model]] — 预测依赖服务器最终权威结果 -- [[Actor Replication]] — 复制的状态是预测和调和的数据基础 -- [[RPC (Remote Procedure Call)]] — 客户端通过 Server RPC 发送输入触发预测 - -## Relationship to Agent -[[UnrealMultiplayerArchitect]] 强调："Desync events (reconciliations) < 1 per player per 30 seconds at 200ms ping" 是成功指标，网络预测的质量直接影响该指标。 - -## Aliases -- Client-Side Prediction -- Rollback Prediction -- Reconciliation diff --git a/wiki/concepts/Network-Segmentation.md b/wiki/concepts/Network-Segmentation.md deleted file mode 100644 index e8fc0ff2..00000000 --- a/wiki/concepts/Network-Segmentation.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Network Segmentation" -type: concept -tags: [Network, Security, AWS, Firewall, Zero-Trust] -sources: [] -last_updated: 2026-05-06 ---- - -## Definition -网络分段（Network Segmentation）是通过防火墙、安全组和网络隔离策略将不同安全级别的网络区域分隔开的架构设计原则。核心目标是实施最小权限原则，阻断不同安全域之间的未授权流量。 - -## Application in AWS Landing Zones -在 Micro Focus AWS Landing Zone 环境中，网络分段策略用于： -- 阻断内部网络对 AWS SaaS 工作负载的直接连通性 -- 通过 Checkpoint 防火墙启用 SPI（Stateful Packet Inspection）特性，以 default-deny 模式限制跨区域流量 -- 入站流量通过 Network 账户的 Checkpoint 重新路由集中管理 - -## Related Concepts -- [[Landing-Zone-Architecture]]：网络分段是 Landing Zone 安全架构的核心组成部分 - -## Related Sources -- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] -- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] -- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] diff --git a/wiki/concepts/NetworkPrediction.md b/wiki/concepts/NetworkPrediction.md deleted file mode 100644 index 4f0ec73d..00000000 --- a/wiki/concepts/NetworkPrediction.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "Network Prediction" -type: concept -tags: ["unreal-engine", "networking", "latency-compensation"] -sources: ["unreal-multiplayer-architect", "unreal-multiplayer-architect"] -last_updated: 2026-04-30 ---- - -## Aliases -- 网络预测 -- 客户端预测 -- Client-side Prediction - -## 定义 -网络预测是客户端在等待服务器确认时本地预测游戏结果的技术，使玩家感觉不到网络延迟，提升游戏响应体验。 - -## 工作原理 -1. 玩家输入 → 客户端立即应用预测结果 -2. 客户端同时发送输入到服务器 -3. 服务器执行相同逻辑 -4. 服务器将结果复制回客户端 -5. 客户端比较预测与实际结果 -6. 如有差异，进行协调（Reconciliation） - -## UE5 Network Prediction Plugin -UE5 提供的官方预测框架，支持物理驱动或复杂移动的回滚： -- `FNetworkPredictionStateBase` — 预测状态基类 -- 每秒预测状态数 = 网络频率 -- 支持移动、能力、交互等多系统 - -## 预测与权威的关系 -``` -预测（客户端） 权威（服务器） - ↓ ↓ -立即响应 ←─────── 确认/回滚 - ↓ ↓ -显示结果 ←─────── 复制结果 -``` - -## 性能指标 -- 200ms 延迟下每玩家每 30 秒去同步事件应 < 1 次 -- 过多去同步 = 预测逻辑与服务器不一致 - -## 相关概念 -- [[Server-Authoritative Model]] — 预测的基础是服务器权威 -- [[GAS (Gameplay Ability System)]] — GAS 内置 Prediction Key 支持 -- [[Actor Replication]] — 预测结果通过复制验证 diff --git a/wiki/concepts/NetworkVariable.md b/wiki/concepts/NetworkVariable.md deleted file mode 100644 index 512caa88..00000000 --- a/wiki/concepts/NetworkVariable.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "NetworkVariable" -type: concept -tags: [networking, unity, ngo] -sources: [unity-multiplayer-engineer] -last_updated: 2026-04-26 ---- - -## Aliases -- NetworkVariable -- NV (abbreviation) - -## Definition -`NetworkVariable` 是 Unity Netcode for GameObjects（NGO）中的核心类型，用于**持久化复制状态**——当值发生变化时，自动通过网络同步到所有客户端。仅在值真正变化时触发同步（dirty check）。 - -## Usage Rules -| 场景 | 应使用 | -|------|--------| -| 持久化、需要同步的状态 | `NetworkVariable` | -| 一次性事件、触发通知 | `ClientRpc` / `ServerRpc` | - -**核心原则：持久化用 NetworkVariable，一次性事件用 RPC，不可混用。** - -## Bandwidth Considerations -- **避免在 Update() 中重复设置相同值**——触发无意义的网络同步 -- 对高频数值使用差分压缩（`INetworkSerializable`） -- 非关键状态（血条、分数）限流至最高 10Hz - -## Example -```csharp -// 健康值：持久化 → NetworkVariable -public NetworkVariable PlayerHealth = new(100, - NetworkVariableReadPermission.Everyone, - NetworkVariableWritePermission.Server); - -// 命中特效：一次性事件 → ClientRpc -[ClientRpc] -public void OnHitClientRpc(Vector3 hitPoint) { ... } -``` - -## Related Concepts -- [[ServerAuthority]]: NetworkVariable 体现服务器权威 -- [[BandwidthManagement]]: 优化 NetworkVariable 使用 -- [[ClientPrediction]]: 结合 NetworkVariable 实现客户端预测 diff --git a/wiki/concepts/NiagaraVFX.md b/wiki/concepts/NiagaraVFX.md deleted file mode 100644 index e5438512..00000000 --- a/wiki/concepts/NiagaraVFX.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "NiagaraVFX" -type: concept -tags: ["unreal-engine", "vfx", "particle-systems"] -sources: ["unreal-technical-artist"] -last_updated: 2026-04-26 ---- - -## Definition -UE5 新一代粒子和 VFX（视觉效果）系统，替代旧版 Cascade。核心设计理念：GPU/CPU 模拟分离、模块化可复用、Scalability 分级预设。 - -## Key Design Decisions -- **GPU vs CPU 选择**：粒子数 < 1000 用 CPU 模拟；粒子数 > 1000 用 GPU 模拟 -- **Max Particle Count 强制**：所有系统必须设置硬上限，禁止无限粒子 -- **Scalability 三档预设**：High（PC/主机高端）、Medium（主机基准/中端 PC）、Low（移动/性能模式），必须全部测试后交付 - -## Scalability Preset Example -| 档位 | 最大活跃系统数 | 每系统最大粒子数 | 剔除距离 | -|------|--------------|----------------|---------| -| High | 10 | 50 | — | -| Medium | 6 | 25 | 30m | -| Low | 3 | 10 | 15m | - -## Key Modules -- Initialize Particle：生命周期、缩放、颜色参数化 -- Initial Velocity：锥形扩散、重力方向 -- Drag：水平摩擦力控制扩散范围 -- Scale Color/Opacity：线性淡出曲线 - -## Rendering -- Sprite Renderer + T_Particle 纹理集（4×4 帧动画） -- Blend Mode: Translucent，峰值时最多 3 层 overdraw - -## Advanced Capabilities -- GPU Simulation Stages：流体类粒子动力学（邻居查询、压力、速度场） -- Data Interface：查询物理场景数据、网格表面、音频频谱 -- Parameter Collections：接收游戏状态参数，实现 VFX 实时响应玩法 - -## Related -- [[VFX]] — 游戏 VFX 通用概念 -- [[PerformanceBudget]] — Niagara 帧预算管理 -- [[QualitySwitch]] — 材质质量分层，与 Niagara Scalability 理念一致 diff --git a/wiki/concepts/Nitro-System.md b/wiki/concepts/Nitro-System.md deleted file mode 100644 index 7421282b..00000000 --- a/wiki/concepts/Nitro-System.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Nitro System" -type: concept -tags: - - AWS - - EC2 - - Hardware - - Performance -last_updated: 2026-04-24 ---- - -# Nitro System - -## Definition - -AWS Nitro System 是 AWS 自研的专用硬件平台，用于增强 EC2 实例的性能和效率。Nitro 通过将网络、存储和安全功能从主 CPU 卸载到专用硬件上来实现这一点。 - -## Aliases -- AWS Nitro -- Nitro Hypervisor - -## Core Components - -1. **Nitro Card**：专用硬件组件，处理网络、存储和安全功能 -2. **Nitro Hypervisor**：轻量级虚拟机管理程序，几乎不占用 CPU 资源 -3. **Nitro Security Chip**：专用安全芯片，提供硬件级安全保护 - -## Key Benefits - -- **性能提升**：通过卸载 I/O 操作释放 CPU 资源用于应用计算 -- **安全性增强**：硬件级信任根和安全启动 -- **网络加速**：支持高达 100 Gbps 的网络吞吐量 -- **存储加速**：支持 NVMe over Fabric 等高速存储协议 -- **更高的性价比**：通过效率提升降低单位计算成本 - -## Use Cases - -- 高性能计算 (HPC) -- 大数据分析 -- 机器学习训练 -- 高网络吞吐量工作负载 -- 低延迟交易系统 - -## Related Concepts - -- [[Graviton]]：ARM 架构处理器，可与 Nitro 系统配合使用 -- [[EC2-Instance-Types]]：Nitro 系统支持多种 EC2 实例类型 -- [[EC2-Purchase-Options]]：EC2 购买选项 - -## Sources - -- [[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]] diff --git a/wiki/concepts/Normal-Change.md b/wiki/concepts/Normal-Change.md deleted file mode 100644 index dcebb0a7..00000000 --- a/wiki/concepts/Normal-Change.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Normal Change" -type: concept -tags: [Change-Management, ITSM, CAB, Change-Window] -last_updated: 2026-04-14 ---- - -## Definition - -Normal Change（正常变更）是一种包含一定风险或影响的变更类型，需要变更咨询委员会（CAB）的审批，并可能需要跨团队协调。与 Standard Change 不同，Normal Change 需要明确的变更窗口来执行。 - -## Characteristics - -|| Attribute | Value | -|-----------|--------| -| Approval Required | 是（CAB 审批） | -| CAB Involvement | 必须 | -| Automation Level | 部分自动化或无 | -| Risk Level | 中-高（需评估） | -| Change Window | 需要明确的时间窗口 | - -## Process Flow - -1. **Request**：产品团队提交变更请求 -2. **Assessment**：评估变更的风险和影响 -3. **CAB Review**：变更咨询委员会审批 -4. **Scheduling**：安排变更窗口 -5. **Execution**：在变更窗口内执行 -6. **Verification**：验证变更结果 -7. **Closure**：完成变更记录 - -## Relationship with Standard Change - -Normal Change 的理想状态是通过自动化逐步将其归入 Standard Change 范畴： - -- 识别重复的 Normal Change -- 评估风险并制定标准化流程 -- 通过 IaC + CI/CD 实现自动化 -- 将 Normal Change 转化为 Standard Change - -## Example Use Cases - -- 跨账户的网络架构变更 -- 需要 CAB 审批的安全策略更新 -- 涉及多个团队协调的基础设施迁移 - -## Sources - -- [[ctp-topic-30-managing-change]] diff --git a/wiki/concepts/NorthStarMetric.md b/wiki/concepts/NorthStarMetric.md deleted file mode 100644 index 154b841f..00000000 --- a/wiki/concepts/NorthStarMetric.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "North Star Metric" -type: concept -tags: ["growth", "metrics", "strategy", "product"] -last_updated: 2026-04-26 ---- - -## Definition -北极星指标——产品为用户创造的核心价值的单一可衡量指标，是增长团队所有工作的最高优先级对齐目标。所有增长实验和策略最终都服务于北极星指标的提升。 - -## Criteria for Choosing -1. 反映核心用户价值 -2. 可衡量且可归因 -3. 是领先指标而非滞后指标 -4. 全公司都能理解 - -## Examples -- Facebook：日活跃用户 -- Airbnb：预订天数 -- Slack：发送消息数 -- Uber：出行次数 - -## Source -- [[marketing-growth-hacker]]（Marketing Growth Hacker Agent） diff --git a/wiki/concepts/Note-Database-Queries.md b/wiki/concepts/Note-Database-Queries.md deleted file mode 100644 index bbe96b88..00000000 --- a/wiki/concepts/Note-Database-Queries.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Note Database Queries" -type: concept -tags: [obsidian, productivity, data-visualization] -sources: [obsidian-高效指南-我常用的插件与实用技巧] -last_updated: 2025-03-01 ---- - -## Definition -将笔记内容转化为结构化数据，通过查询语法进行筛选、排序和可视化展示的方法——把笔记库变成可查询的数据库。 - -## Core Mechanisms -- 元数据提取：从笔记的 frontmatter 或正文中提取结构化字段 -- 查询语法：类 SQL/DSL 语法筛选笔记 -- 动态视图：表格、列表、日历、图表等展示形式 -- 自动更新：笔记内容变化时查询结果实时刷新 - -## Implementations -- **Dataview** (Obsidian)：最流行的笔记数据库插件，支持 DQL（Dataview Query Language） -- **DataviewJS**：Dataview 的 JavaScript 扩展，更强灵活性 -- **Core Search** (Obsidian 内置)：基础搜索，不属于数据库查询 - -## Use Cases -- 统计某标签下的所有笔记数量 -- 按创建时间筛选长期未访问的笔记（定期复盘） -- 生成读书笔记的表格视图 -- 追踪项目笔记的进度状态 - -## Connections -- [[Obsidian]]：主要实现平台 -- [[Periodic Review]]：Dataview 查询可辅助定期复盘 -- [[Personal Knowledge Base]]：数据库查询是知识库检索的核心能力 - -## Sources -- [[obsidian-高效指南-我常用的插件与实用技巧]] diff --git a/wiki/concepts/NoteDatabase.md b/wiki/concepts/NoteDatabase.md deleted file mode 100644 index 96a2748f..00000000 --- a/wiki/concepts/NoteDatabase.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "NoteDatabase" -type: concept -tags: [] -sources: [] -last_updated: 2025-03-07 ---- - -## Aliases -- 笔记数据库 -- Notes as Database -- 知识库查询 - -## Definition -笔记数据库（NoteDatabase）是一种将个人笔记库视为结构化数据库进行查询和组织的理念。与传统笔记软件将笔记视为独立文档不同，NoteDatabase 将每条笔记视为数据库中的一行记录，通过查询语言动态聚合和展示跨笔记的信息。 - -## Core Principle -- **结构化隐式数据**：笔记中的 YAML frontmatter、内联字段、标签等隐式定义了"数据库字段" -- **动态查询**：查询结果随笔记内容变化自动更新，无需手动维护目录 -- **视图抽象**：用户定义查询（视图），笔记是数据源——修改笔记即更新视图 - -## Implementation -- [[DataviewPlugin]]：Obsidian 中实现 NoteDatabase 理念的最佳插件 -- [[DB-Folder]]：以类 Airtable 表格形式管理笔记 -- [[Obsidian-Bases]]：通过 `.base` 文件定义笔记数据库结构 - -## Related Concepts -- [[QueryLanguage]]：笔记数据库的查询接口 -- [[TagBasedIndexing]]：笔记数据库的标签索引机制 -- [[Bidirectional-Linking]]：笔记数据库通过双链形成关系网络 diff --git a/wiki/concepts/Nudge-Sequence.md b/wiki/concepts/Nudge-Sequence.md deleted file mode 100644 index cd65856c..00000000 --- a/wiki/concepts/Nudge-Sequence.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "Nudge Sequence" -type: concept -tags: [] -sources: ["product-behavioral-nudge-engine"] -last_updated: 2026-05-01 ---- - -## Definition - -Nudge Sequence（推动序列）是一种多渠道、渐进式用户触达策略——根据用户在每个触点的响应状态，动态调整推送渠道、时机和内容，以最大化任务完成率，同时最小化通知疲劳。 - -## Mechanism - -典型的 Nudge Sequence 遵循递增压力模型： - -``` -Day 1: SMS（个人化、低侵入） - ↓ 用户无响应 -Day 3: Email（中等正式） - ↓ 用户无响应 -Day 7: In-App Banner（高可见性） - ↓ 用户无响应 -Day 14: 暂停推送 → 触发用户偏好重新确认 -``` - -## Design Principles - -1. **递增原则**：渠道侵入力度随时间递增 -2. **退出检测**：任何阶段的完成操作立即停止后续推送 -3. **渠道匹配**：根据用户偏好选择初始渠道 -4. **疲劳管理**：序列完成后强制冷却期，避免过度触达 -5. **个性化调整**：根据响应率数据动态优化序列参数 - -## Key Metrics - -- **到达率**：各渠道消息实际送达率 -- **打开率**：到达消息的打开/查看率 -- **完成率**：序列触发后最终任务完成百分比 -- **疲劳指数**：推送频率与用户响应率的负相关程度 - -## Related Concepts - -- [[Default Bias]] — Nudge Sequence 中可嵌入默认选项利用 -- [[Cognitive Load Reduction]] — 每次只推送一个行动项 -- [[Gamification]] — 配合庆祝机制提升序列参与度 -- [[Behavioral Nudge Engine]] — Nudge Sequence 的核心应用引擎 - -## Connections - -- [[Behavioral Nudge Engine]] — Nudge Sequence 的实现主体 -- [[Product Manager Agent]] — 任务优先级决定 Nudge 的触发条件 -- [[Multi-Channel Personal Assistant]] — 多渠道推送的技术实现参考 diff --git a/wiki/concepts/Nunchi.md b/wiki/concepts/Nunchi.md deleted file mode 100644 index 3594ec20..00000000 --- a/wiki/concepts/Nunchi.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "Nunchi" -type: concept -tags: [] -sources: [] -last_updated: 2026-05-30 ---- - -## 基本信息 -- **原文**：눈치（Nunchi） -- **发音**：nunchi -- **中文**：读心术 / 察言观色 / 眼力见 -- **英文**：Reading the room / Social awareness - -## 定义 -눈치（Nunchi）是韩国文化中最核心的概念之一，字面意思是"用眼睛测量重量"，实际指通过观察语境、情绪和微妙的行为线索来理解未被直接表达的意图和想法。Nunchi 是韩国商业中最重要的隐性技能——它决定了你能读懂多少会议室里没有说出口的内容。 - -## 在韩国商业中的重要性 - -韩国商业文化优先维护和谐（关系和谐），而非直接表达分歧。因此： -- **拒绝通常不是"No"，而是沉默或模糊的"検討해보겠습니다"** -- **积极信号不是"Yes"，而是主动提问和索取材料** -- **真正决策发生在走廊里，而非会议桌前** - -## Nunchi 解码表（Korean Business Navigator 提供） - -| 他们说（韩文） | 字面意思 | 实际含义 | 你的行动 | -|---------------|---------|---------|---------| -| 좋은데요... | "That's nice, but..." | 犹豫，有顾虑但不会直接说 | "어떤 부분이 고민이신가요?"（哪方面让您顾虑？）| -| 검토해보겠습니다 | "We'll review it" | 很可能不行，给你台阶 | 等5天，无跟进则放弃 | -| 긍정적으로 검토하겠습니다 | "We'll review positively" | 真正感兴趣，内部流程启动 | 主动发送补充材料 | -| 어려울 것 같습니다 | "It seems difficult" | 明确拒绝 | 优雅接受，问下次机会 | -| 한번 보고 드려야 할 것 같습니다 | "I need to report upward" | 决策权不在他，품의已触发 | 好信号，提供一切内部推进所需的材料 | -| 바쁘시죠? | "You must be busy, right?" | 社交润滑，马上要提出请求 | "괜찮습니다, 말씀하세요"（没事，请说）| - -## Nunchi 核心原则 -1. **永远不要只看字面意思** — 韩国人说的话通常包含两层含义 -2. **沉默不是否定** — 3-7 天的沉默可能意味着内部讨论正在进行 -3. **主动提问者 = 真正感兴趣** — 索取案例和参考资料是强烈购买信号 -4. **"상부에서 검토 중입니다"（上级正在审查）是进展信号** — 意味着在推进，不是卡住 -5. **观察肢体语言和座位安排** — 谁坐在谁旁边决定谁听谁的 - -## Nunchi vs 西方"直接沟通"的张力 -- 西方文化：直接询问"你们打算买吗？"是专业和高效的体现 -- 韩国文化：这样问等于逼迫对方说"不"，破坏和谐 -- 解决方式：通过观察间接信号判断意向，而非直接询问 - -## 如何培养 Nunchi -1. **注意开场白**：韩国人通常以寒暄开始，直接切入正题显示不懂礼貌 -2. **观察座位**：상석（主座，最远离门的位置）是最重要的人 -3. **记录谁称呼谁**："과장님"还是直呼其名，暗示关系深度 -4. **关注被叫进来的人**：如果第二会议规模扩大，说明认真程度提升 -5. **留意회식（聚餐）邀请**：主动邀请聚餐是建立信任的关键信号 - -## 来源 -- [[specialized-korean-business-navigator]] — Nunchi Decoder — Business Context 完整规范 diff --git a/wiki/concepts/OS-End-of-Life.md b/wiki/concepts/OS-End-of-Life.md deleted file mode 100644 index 2c012f2e..00000000 --- a/wiki/concepts/OS-End-of-Life.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "OS End of Life" -type: concept -tags: ["Linux", "Windows", "Lifecycle-Management", "Migration"] -sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2", "ctp-topic-50-ami-roadmap-for-aws-amis"] -last_updated: 2026-05-08 ---- - -## Definition -操作系统生命周期终止（OS End of Life，EOL）是指操作系统供应商停止支持、安全更新和补丁的日期。在 Micro Focus AWS Landing Zone 中，EOL 管理是 AMI 策略的重要组成部分，需要提前规划迁移到受支持的替代操作系统。 - -## Key EOL Dates in AWS Landing Zone - -### 已 EOL -- **Windows Server 2008 / 2008 R2**：已 EOL -- **CentOS 8**：已 EOL（2021 年 12 月） - -### 即将 EOL（截至 2023-12 会议记录） -- **CentOS 7**：2024 年 6 月 EOL → 替代方案：Rocky Linux 8/9 -- **Red Hat Enterprise Linux 7**：2024 年 6 月 EOL → 替代方案：RHEL 9 -- **OpenSUSE Leap 15**：2024 年 12 月 EOL -- **Oracle Enterprise Linux 7 (OEL 7)**：2024 年 12 月 EOL - -### AWS Landing Zone 应对策略 -1. **提前规划**：在 EOL 前 6 个月启动迁移评估 -2. **替代 AMI**：CCOE 发布新 OS 替代 AMI（如 Rocky Linux） -3. **自动化迁移**：Terraform 模块支持 OS 层变更 -4. **验证测试**：在非生产环境验证兼容性 - -## Connections -- [[Rocky-Linux]] — CentOS 7 的官方替代品 -- [[Amazon-Machine-Image]] — EOL 管理通过 AMI 生命周期体现 -- [[ctp-topic-50-ami-roadmap-for-aws-amis]] — AMI 路线图包含 EOL 时间线规划 diff --git a/wiki/concepts/OS-Hardening.md b/wiki/concepts/OS-Hardening.md deleted file mode 100644 index 68422f9a..00000000 --- a/wiki/concepts/OS-Hardening.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "OS Hardening" -type: concept -tags: - - Security - - Linux - - AWS -sources: [] -last_updated: 2026-05-07 ---- - -## OS Hardening - -操作系统加固，通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面。 - -## Definition - -OS Hardening 是将操作系统配置为最小权限、最小攻击面的过程，是 Foundation AMI 安全加固的核心步骤。 - -## Key Areas - -### 1. Service Reduction -- 禁用不必要的系统服务 -- 关闭未使用的网络端口 -- 移除不必要的软件包 - -### 2. Kernel Parameters -- 网络安全参数优化 -- 文件系统权限加固 -- 用户权限限制（最小权限原则） - -### 3. Security Patching -- 操作系统安全补丁自动更新 -- 内核更新管理 -- 应用层安全补丁 - -### 4. Compliance Alignment -- 遵循 [[CIS-Benchmark]] 配置 -- 满足企业安全策略 -- 对接合规审计框架 - -## In Foundation AMI - -Foundation AMI 的 OS Hardening 包括： -- 基于 [[CIS-Benchmark]] 的安全配置 -- McAfee EPO 防病毒集成 -- Syslog-ng 日志管理 -- AD 单点登录集成 -- [[AWS-SSM]] 自动化补丁管理 - -## Relationship with CIS Benchmark - -OS Hardening 通常基于 [[CIS-Benchmark]]： -- [[CIS-Benchmark]] 提供配置检查清单 -- OS Hardening 是实际执行这些配置的过程 -- Foundation AMI 集成了经过 CIS 加固的操作系统 - -## Sources -- [[ctp-topic-26-standard-ami-build-publish-share-processes]] — Foundation AMI 中的 OS Hardening 实现 diff --git a/wiki/concepts/OWASP-Top-Ten.md b/wiki/concepts/OWASP-Top-Ten.md deleted file mode 100644 index f8bc2310..00000000 --- a/wiki/concepts/OWASP-Top-Ten.md +++ /dev/null @@ -1,106 +0,0 @@ -# OWASP Top Ten - -## Definition -The OWASP Top Ten represents a broad consensus about the most critical security risks to web applications. It is a standard awareness document for developers and web application security. - -## Aliases -- OWASP Top 10 -- OWASP Top Ten Web Application Security Risks - -## Purpose -为开发者和安全团队提供最关键 web 应用安全风险的共识性列表，是安全编码和测试的基础标准。 - -## Current List (2021) - -### A01:2021 – Broken Access Control -访问控制失效，包括： -- 越权访问 -- 绕过访问控制 -- 不安全的直接对象引用 - -### A02:2021 – Cryptographic Failures -密码学失败，包括： -- 敏感数据泄露 -- 弱加密算法 -- 不正确的密钥管理 - -### A03:2021 – Injection -注入攻击，包括： -- SQL 注入 -- NoSQL 注入 -- OS 命令注入 -- LDAP 注入 - -### A04:2021 – Insecure Design -不安全设计，包括： -- 缺失或无效的访问控制 -- 业务逻辑漏洞 -- 威胁建模缺失 - -### A05:2021 – Security Misconfiguration -安全配置错误，包括： -- 不安全的默认配置 -- 错误处理信息泄露 -- 云服务配置错误 - -### A06:2021 – Vulnerable and Outdated Components -易受攻击和过时的组件，包括： -- 使用有漏洞的库 -- 未更新依赖 -- 不支持组件 - -### A07:2021 – Identification and Authentication Failures -身份识别和认证失败，包括： -- 弱密码策略 -- 会话管理问题 -- 凭证泄露 - -### A08:2021 – Software and Data Integrity Failures -软件和数据完整性失败，包括： -- 不安全的 CI/CD -- 依赖混淆攻击 -- 更新未签名 - -### A09:2021 – Security Logging and Monitoring Failures -安全日志和监控失败，包括： -- 未记录安全事件 -- 告警未处理 -- 响应延迟 - -### A10:2021 – Server-Side Request Forgery (SSRF) -服务端请求伪造，包括： -- 从应用获取内部资源 -- 绕过防火墙 -- 访问云元数据服务 - -## Integration with DevSecOps - -### Development Phase -- 安全编码培训以 OWASP Top Ten 为基础 -- SAST 工具检测相关漏洞 -- 代码审查关注常见问题 - -### Testing Phase -- DAST 工具模拟 Top Ten 攻击 -- 渗透测试重点关注 -- 自动化测试集成 - -### Operations Phase -- 监控 Top Ten 相关告警 -- 漏洞扫描覆盖 -- 补丁管理 - -## Related Concepts -- [[DevSecOps]] — OWASP Top Ten 是安全编码和测试的基础 -- [[SAST]] — 检测代码中的 OWASP 问题 -- [[DAST]] — 动态检测 OWASP 漏洞 -- [[SCA]] — 检测易受攻击的组件 -- [[Shift-Left-Security]] — 早期发现 OWASP 问题 - -## Resources -- OWASP 官网：https://owasp.org/www-project-top-ten/ -- OWASP Cheat Sheets -- OWASP WebGoat（学习工具） - -## Sources -- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Observability.md b/wiki/concepts/Observability.md deleted file mode 100644 index a0f0f2a2..00000000 --- a/wiki/concepts/Observability.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: "Observability" -type: concept -tags: [DevOps, Monitoring, Reliability] -sources: [engineering-devops-automator] -last_updated: 2026-05-01 ---- - -# Observability - -## 定义 -可观测性（Observability）是通过收集系统外部输出来推断其内部状态的能力，核心目标是回答"为什么系统出现了问题"，而不仅仅是"系统是否正常"。 - -## 可观测性三支柱 - -### 1. 指标（Metrics） -- **定义**：数值型测量，反映系统健康状况 -- **特点**：聚合性强、支持告警、存储成本相对低 -- **工具**：[[Prometheus]]、CloudWatch、DataDog -- **示例**：CPU 使用率、请求延迟、错误率、QPS - -### 2. 日志（Logs） -- **定义**：系统产生的离散事件记录 -- **特点**：详细信息、时序排列、关联分析 -- **工具**：ELK Stack（Loki）、CloudWatch Logs -- **示例**：访问日志、错误日志、审计日志 - -### 3. 追踪（Traces） -- **定义**：请求在分布式系统中的完整调用路径 -- **特点**：端到端关联、延迟分析、瓶颈定位 -- **工具**：Jaeger、Zipkin、AWS X-Ray -- **示例**：微服务调用链、数据库查询耗时 - -## SRE 可观测性实践 - -### RED 方法（面向服务） -- **Rate**：请求率（每秒请求数） -- **Errors**：错误率（失败请求百分比） -- **Duration**：延迟（响应时间分布） - -### USE 方法（面向资源） -- **Utilization**：利用率 -- **Saturation**：饱和度 -- **Errors**：错误 - -## 在 DevOps Automator 中的应用 -DevOps Automator 的可观测性体系： -1. **指标收集**：Prometheus scrape metrics -2. **可视化**：Grafana Dashboard -3. **告警**：Prometheus Alert Rules → AlertManager -4. **日志聚合**：可选 Loki/ELK -5. **分布式追踪**：可选 Jaeger - -### 关键监控指标 -- 部署频率（Deployment Frequency） -- 变更失败率（Change Failure Rate） -- MTTR（Mean Time To Recovery） -- 可用性（Availability） - -## 相关概念 -- [[Prometheus]]：指标采集和告警核心组件 -- [[Grafana]]：指标可视化平台 -- [[Zero-Downtime Deployment]]：可观测性支撑零停机部署的监控需求 - -## 相关工具 -| 类型 | 工具 | -|------|------| -| 指标 | Prometheus, CloudWatch, DataDog, New Relic | -| 日志 | ELK Stack, Loki, CloudWatch Logs | -| 追踪 | Jaeger, Zipkin, AWS X-Ray, OpenTelemetry | -| 可视化 | Grafana, Datadog Dashboards | - -## SRE 四个黄金信号 -Google SRE 提出的关键指标： -1. **Latency**：延迟 -2. **Traffic**：流量 -3. **Errors**：错误 -4. **Saturation**：饱和度 - -## Aliases -- 可观测性 -- Observability -- Monitoring -- 监控 -- 可观测系统工程 diff --git a/wiki/concepts/Observable-States.md b/wiki/concepts/Observable-States.md deleted file mode 100644 index 9f014659..00000000 --- a/wiki/concepts/Observable-States.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Observable States" -type: concept -tags: [workflow, observability, system-modeling] -last_updated: 2026-04-25 ---- - -## Definition -可观察状态——每个工作流状态（快乐路径中的每一步 + 每个失败模式）必须同时从四个视角描述系统当前状态，确保客户、运维、数据库和日志各方都能准确感知系统发生了什么。 - -## Four Dimensions（四维度） - -| 维度 | 描述 | 示例 | -|------|------|------| -| **Customer View** | 当前客户在 UI 上看到什么 | 加载中 / "处理中..." / 空白 / 错误提示 | -| **Operator View** | 运维/管理员在管理面板看到什么 | 实体处于"处理中"状态 / 任务步骤显示 "step_3_running" | -| **Database View** | 数据库中数据当前状态 | `job.status = "running"`, `job.current_step = "step_1"` | -| **Log View** | 系统日志当前记录了什么 | `[order-service] step 1 started entity_id=abc123` | - -## Why Four Dimensions? -单一视角不足以支撑调试和运维： -- **只有 Customer View**：运维无法知道后台发生了什么 -- **只有 Database View**：客户不知道自己看到了什么 -- **只有 Log View**：没有结构化数据支撑告警和审计 -- **只有 Operator View**：缺乏原始数据记录 - -四个维度必须同步更新、互相印证，构成完整的可观测性闭环。 - -## Source -- [[specialized-workflow-architect]]（Workflow Architect Agent） diff --git a/wiki/concepts/Obsidian-Agent-Client.md b/wiki/concepts/Obsidian-Agent-Client.md deleted file mode 100644 index 0d7c4671..00000000 --- a/wiki/concepts/Obsidian-Agent-Client.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Obsidian-Agent-Client" -type: concept -tags: [obsidian, plugin, multi-agent] -last_updated: 2026-04-21 ---- - -## Definition -obsidian-agent-client 是 RAIT-09 开发的 Obsidian 第三方插件，通过 BRAT 安装，适配多款主流 AI Coding Agent：Claude Code、Codex、Claude CLI、OpenCode、Qwen Code。 - -## 安装方式 -1. 在 Obsidian 插件市场搜索并安装 **BRAT** -2. 打开"设置 → BRAT → Add Beta plugin" -3. 输入仓库地址：`RAIT-09/obsidian-agent-client` -4. 启用插件 - -## 配置示例（OpenCode） -1. 打开 Agent Client 设置页 → 点击 `Add Custom Agent` -2. 设置 Agent ID 和 Display Name 为 OpenCode -3. 填入 OpenCode 安装路径（`where opencode` 查看） -4. Arguments 填入： -```bash -acp ---cwd -D:\Obsidian Vault\MyObVault -``` -（第三行为 Obsidian Vault 路径） - -## 支持的 Agent -| Agent | 说明 | -|-------|------| -| [[Claude Code]] | Anthropic CLI Agent | -| Codex | OpenAI CLI Agent | -| Gemini CLI | Google CLI Agent | -| [[OpenCode]] | Vibe Coding CLI Agent | -| Qwen Code | 阿里通义灵码 | - -## 对比 -- [[Claudian]]：仅适配 Claude Code，但配置更简单 -- obsidian-agent-client：支持多 Agent，但配置稍复杂 - -## Connections -- [[RAIT-09]] — obsidian-agent-client 开发者 -- [[Claude Code]] / [[OpenCode]] — 支持的 Agent -- [[obsidian-必装-skills]] — 来源文档 -- [[BRAT]] — 安装工具 diff --git a/wiki/concepts/Obsidian-Bases.md b/wiki/concepts/Obsidian-Bases.md deleted file mode 100644 index acca3330..00000000 --- a/wiki/concepts/Obsidian-Bases.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Obsidian-Bases" -type: concept -tags: [obsidian, skills, database] -last_updated: 2026-04-21 ---- - -## Definition -obsidian-bases 是 kepano（Obsidian CEO）发布的 Skill，允许 AI 通过编写 YAML 格式的 `.base` 配置文件在 Obsidian 中创建类似 Notion 数据库的动态视图，实现对笔记的过滤、计算和结构化展示。 - -## Key Features -- **视图类型**：table（表格）、cards（卡片）、list（列表）、map（地图）四种类型 -- **公式系统**：支持读取笔记的 Frontmatter 属性或文件元数据（创建时间、字数等），并进行条件判断、日期运算和字符串处理 -- **AI 驱动**：AI 直接生成 `.base` 文件创建数据库视图 - -## Example Prompt -```text -写一个 .base 文件来管理我的项目笔记，要求筛选出所有带 #project 标签的文件，用表格显示项目名称、截止日期和剩余天数。 -``` - -## Requirements -- Maps 插件（仅使用 map 视图时需额外安装） - -## Connections -- [[kepano]] — obsidian-bases 的发布者 -- [[obsidian-必装-skills]] — 来源文档 -- [[Obsidian]] — 所操作的笔记软件 diff --git a/wiki/concepts/Obsidian-CLI.md b/wiki/concepts/Obsidian-CLI.md deleted file mode 100644 index 6315cc76..00000000 --- a/wiki/concepts/Obsidian-CLI.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Obsidian-CLI" -type: concept -tags: [obsidian, skills, cli] -last_updated: 2026-04-16 -sources: - - obsidian-cli - - obsidian-必装-skills ---- - -## Definition -Obsidian-CLI 是 Obsidian v1.12+ 内置的官方命令行工具，让用户能够从终端完全控制 Obsidian 的所有功能。CLI 提供两种使用模式：单命令模式（`obsidian `）和 TUI 交互模式（`obsidian` 进入交互终端，支持自动补全和命令历史）。通过标准化的命令接口，AI Agent 可以实现笔记增删改查、日记管理、任务操作、搜索、书签、热键管理、文件版本对比等全部 GUI 功能，无需图形界面即可完成复杂的知识管理工作。 - -## 核心能力 -- **日常操作**：daily（日记）、search（搜索）、read（读取）、create（创建）、tags（标签）、tasks（任务）、bookmarks（书签） -- **文件管理**：append/prepend（追加/前置内容）、move/rename（移动/重命名）、delete（删除） -- **插件管理**：plugin:enable/disable/reload（启用/禁用/热重载插件） -- **属性操作**：property:set/remove/read（设置/删除/读取属性） -- **开发者命令**：devtools、dev:screenshot、dev:console、eval（执行 JS）、plugin:reload（热重载社区插件） -- **版本管理**：diff（版本对比）、history:restore（历史恢复）、sync:restore（Sync 恢复） -- **工作区管理**：workspace:save/load（保存/加载布局）、tabs（标签页管理） - -## Configuration Steps -1. 确认 Obsidian 客户端版本 ≥ 1.12 -2. 打开"设置 → 常规 (General)" -3. 找到"命令行界面 (Command line interface)"开关并打开 -4. 在弹窗中确认注册到系统 Path -5. 确保 Obsidian 客户端处于运行状态（未运行时系统会自动启动） - -## Verification -```bash -obsidian daily -``` -配置正确则 Obsidian 会自动应用日记模版并生成今日日记文件。 - -## Requirements -- Obsidian ≥ 1.12 -- CLI 开关已开启 -- Obsidian 客户端运行中 - -## Connections -- [[kepano]] — obsidian-cli 的发布者 -- [[obsidian-必装-skills]] — 来源文档 -- [[Obsidian]] — CLI 所操作的笔记软件 diff --git a/wiki/concepts/Obsidian-Git.md b/wiki/concepts/Obsidian-Git.md deleted file mode 100644 index 9a044388..00000000 --- a/wiki/concepts/Obsidian-Git.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Obsidian Git" -type: concept -tags: [tool, obsidian, version-control, git] -sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环] -last_updated: 2026-04-20 ---- - -## Aliases -- Obsidian Git 插件 -- Obsidian Git 扩展 - -## Definition -Obsidian 的社区插件，为 Vault 提供 Git 版本管理功能，支持自动 commit + push 到远程仓库。是 LLM Wiki 的**必选项**——AI 批量改文件的能力越强，越需要版本管理来兜底。 - -## Setup Steps -1. 设置 → 第三方插件 → 社区插件市场 → 搜索 "git" → 安装并启用 -2. 如果 Vault 还不是 Git 仓库： - ```bash - git init - git remote add origin https://github.com/用户名/knowledge-bases.git - git branch -M main - git add . - git commit -m "init: 初始化知识库" - git push -u origin main - ``` -3. 在 Obsidian Git 插件设置中，将 **Auto commit-and-sync interval** 设为 10 分钟 - -## Value for LLM Wiki -- **实时备份 + 完整历史**：每隔几分钟插件自动 commit + push，完全无需手动操作 -- **版本兜底**：AI 批量修改多个文件时，可随时回滚到任意历史版本 -- **多设备同步**：通过 GitHub 实现跨设备同步 - -## Note -建议创建**私有仓库**（Private Repository），知识库内容属于私人数据。 - -## Connections -- [[Obsidian Git]] ← 版本管理 ← [[LLM Wiki]] -- [[Obsidian Git]] ← 插件 → [[Obsidian]] diff --git a/wiki/concepts/Obsidian-Tasks.md b/wiki/concepts/Obsidian-Tasks.md deleted file mode 100644 index 805684db..00000000 --- a/wiki/concepts/Obsidian-Tasks.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Obsidian Tasks" -type: concept -tags: [] -sources: [] -last_updated: 2025-03-13 ---- - -## Definition -Obsidian Tasks 是 Obsidian 的任务管理插件，通过 Markdown 语法（`- [ ]`）创建任务，支持日期、优先级、标签、重复任务，并通过代码块查询在任意笔记中嵌入动态任务筛选视图。 - -## Details -- **插件来源**：Obsidian 社区插件市场 -- **任务语法**：`- [ ] 任务内容 📅 日期 🔼 优先级 #标签` -- **查询语法**：`tasks` 代码块，支持 `not done`/`due before`/`sort by` 等筛选条件 -- **重复任务**：`⏳ every week`/`⏳ every month` 自动创建周期性新任务 - -## Related Concepts -- [[Task Query]]：Tasks 插件的查询语法 -- [[Recurring Task]]：周期性任务机制 -- [[Dataview]]：Obsidian 的笔记索引插件，与 Tasks 互补 -- [[Second Brain]]：个人知识管理框架，Tasks 是其中的行动层 - -## Sources -- [[obsidian-tasks-插件-这可能是最适合懒人的任务管理方式]] diff --git a/wiki/concepts/Obsidian-Web-Clipper.md b/wiki/concepts/Obsidian-Web-Clipper.md deleted file mode 100644 index 617408ec..00000000 --- a/wiki/concepts/Obsidian-Web-Clipper.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Obsidian Web Clipper" -type: concept -tags: [tool, obsidian, browser-extension, clipping] -sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环] -last_updated: 2026-04-20 ---- - -## Aliases -- Obsidian Web Clipper 扩展 -- Obsidian 网页剪藏插件 - -## Definition -Obsidian 的浏览器扩展插件，可一键将任意网页文章保存为 Markdown 格式，自动存入 Obsidian Vault。是 LLM Wiki 素材采集的关键工具。 - -## Usage Flow -1. 在 Chrome 浏览器安装 Obsidian Web Clipper 扩展 -2. 打开任意网页文章 -3. 点击扩展图标 → "Add to Obsidian" -4. 文章自动转为 Markdown 出现在 Vault 里 - -## Key Benefit -将人类从"复制粘贴整理"的工作中解放——素材采集完全自动化，AI 可以直接读取和处理。 - -## Connections -- [[Obsidian Web Clipper]] ← 采集工具 ← [[LLM Wiki]] -- [[Obsidian Web Clipper]] ← 插件 → [[Obsidian]] diff --git a/wiki/concepts/Obsidian.md b/wiki/concepts/Obsidian.md deleted file mode 100644 index 3b3434c7..00000000 --- a/wiki/concepts/Obsidian.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Obsidian" -type: concept -tags: [tool, note-taking, local] -sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环, llm-wiki, 养虾日记3, obsidian-官方-cli-命令全景速查表, obsidian-cli] -last_updated: 2026-04-20 ---- - -## Aliases -- Obsidian.md - -## Definition -本地化的双链笔记工具，以 Markdown 文件为核心存储格式，支持双向链接、图谱视图和丰富的社区插件生态。是 LLM Wiki 方法论的理想载体。 - -## Core Features -- **双向链接（wikilink）**：`[[页面名]]` 语法创建页面间链接 -- **Graph View**：以节点和连线展示所有页面及其链接关系 -- **本地存储**：所有数据保存在本地 Vault（文件夹），不依赖云端 -- **丰富的插件生态**：Obsidian Git、Dataview、Marp Slides、Web Clipper 等 -- **社区插件市场**：内置插件管理器，支持搜索和安装社区插件 - -## Key Plugins for LLM Wiki -- **[[Obsidian Web Clipper]]**：浏览器插件，一键将网页保存为 Markdown -- **[[Obsidian Git]]**：Vault 版本管理，自动 commit + sync -- **[[Dataview]]**：对 frontmatter 做数据库式查询 -- **[[Marp]]**：Markdown 幻灯片预览和导出 -- **[[Graph View]]**：内置图谱视图（Ctrl+G 打开） - -## Configuration Notes -- 附件存储路径：建议设为 `attachments` 子文件夹，避免所有附件混在一个目录 -- 图片本地化：使用 Ctrl+Shift+D 快捷键批量下载图片到本地 -- 注意：LLM 目前无法一次性读取带内嵌图片的 Markdown，需先读文本再单独查看图片 - -## Role in LLM Wiki -**"Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库"**（[[llm-wiki]] 核心比喻） - -## Connections -- [[Obsidian]] ← 工具 ← [[LLM Wiki]] -- [[Obsidian]] ← 工具 ← [[Second Brain]] -- [[Obsidian]] ← 插件生态 → [[Obsidian Web Clipper]], [[Obsidian Git]], [[Dataview]], [[Marp]] diff --git a/wiki/concepts/ObsidianRecurringTasks.md b/wiki/concepts/ObsidianRecurringTasks.md deleted file mode 100644 index 0bdd8523..00000000 --- a/wiki/concepts/ObsidianRecurringTasks.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "ObsidianRecurringTasks" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-27 ---- - -## Aliases -- Obsidian 重复任务 -- Obsidian Tasks 重复任务 -- ObsidianRecurringTasks -- Recurring Tasks -- 周期任务 -- every week -- every month - -## Definition -ObsidianRecurringTasks（Obsidian 重复任务）是 Obsidian Tasks 插件提供的自动生成周期任务的机制，用户只需设定一次规则（如每周、每月），系统自动在每个周期到来时创建新的待办事项，无需手动复制粘贴。 - -## Key Characteristics -- 周期定义：支持 daily、weekly、monthly、yearly 等多种周期，以及自定义间隔 -- 自动生成：任务完成后，系统自动创建下一个周期的任务实例 -- 保留上下文：重复任务可携带原始笔记的上下文（标签、优先级、所属文件夹等） -- 无需手动维护：消除"每周手动创建新任务"的重复性工作 - -## Example -``` -- [ ] 每周发布公众号文章 ⏳ every week -- [ ] 每月整理 Obsidian 笔记 ⏳ every month -``` -含义：分别在每周和每月自动生成新的待办任务。 - -## Value -解决了"定期任务需要手动复制"这一效率痛点，让用户从重复性工作中解放出来，专注于任务的执行而非创建。 - -## Connections -- [[ObsidianTasksPlugin]] ← supports ← [[ObsidianRecurringTasks]]（Tasks 插件提供重复任务功能） -- [[ObsidianRecurringTasks]] ← enables ← [[TaskQuerySyntax]]（查询语法可筛选即将到来的重复任务） -- [[MarkdownBasedTask]] ← extends_with ← [[ObsidianRecurringTasks]]（在 Markdown 任务语法中嵌入 ⏳ 周期指令） diff --git a/wiki/concepts/Oli-Workflow.md b/wiki/concepts/Oli-Workflow.md deleted file mode 100644 index d9b2d268..00000000 --- a/wiki/concepts/Oli-Workflow.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: Oli Workflow -type: concept -tags: [Workflow, Cloud-Governance, FinOps] -sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16] ---- - -# Oli Workflow - -**Oli Workflow** 是 OpenText 超大规模云厂商支出审批工作流，所有云支出请求必须经过此流程审批。 - -## Overview - -Oli Workflow 是企业云治理的核心流程： -- **强制审批**：所有超大规模云厂商支出，无论金额，均需 MUI 或 Shannon 书面审批 -- **团队接管**：由 Tom Bice 领导的 FinOps 团队接管 -- **平台集成**：正在集成到 SMACs 平台 - -## Three-Stage Approval Process - -| 阶段 | 负责方 | 验证内容 | -|------|--------|----------| -| 1. 可行性验证 | FinOps | 评估需求的技术和财务可行性 | -| 2. 技术可行性验证 | Cloud Services | 评估技术实现可行性 | -| 3. 预算可用性验证 | FPNA Team | 确认预算可用性 | - -## Request Form Fields - -| 字段 | 说明 | -|------|------| -| 员工信息 | 从企业 AD 自动拉取 | -| 组织选择 | 下拉菜单选择 | -| 成本中心 | 来自 Talent Central | -| 请求类型 | 预算增加 vs 新建实验室空间 | -| 云服务商 | 下拉选择 | -| 区域 | 必须是活跃区域列表中的区域 | -| 理由说明 | 评论区域提交 | - -## Key Features - -- **CSV 报告**：飞行中 CSV 报告追踪工作流状态、申请人、成本中心、月成本、当前步骤 -- **自动化整合**：与 Confluence 基础说明、AD 员工信息、Talent Central 成本中心集成 -- **拒绝机制**：未提供理由详情的请求将被立即拒绝 - -## Approval Authority - -| 审批人 | 职责 | -|--------|------| -| MUI | 超大规模云厂商支出审批人 | -| Shannon | 超大规模云厂商支出审批人 | - -## Related Concepts - -- [[FinOps]] — 云财务运营 -- [[Demand-Management]] — 需求管理 -- [[SMACs]] — 技术栈组合 -- [[ITIL-Service-Management]] — ITIL 框架 -- [[Product-Backlog]] — 产品待办列表 - -## Related Entities - -- [[Tom-Bice]] — FinOps 团队负责人 -- [[FPNA-Team]] — 预算验证团队 -- [[MUI]] — 审批人 -- [[Shannon]] — 审批人 -- [[Octane]] — 需求管理平台 -- [[Qixi]] — 需求提交入口 - -## Sources - -- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] diff --git a/wiki/concepts/OneFilePerActor.md b/wiki/concepts/OneFilePerActor.md deleted file mode 100644 index 7c1b43ab..00000000 --- a/wiki/concepts/OneFilePerActor.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "OneFilePerActor" -type: concept -tags: ["unreal-engine", "collaboration", "version-control", "world-partition"] -sources: ["unreal-world-builder"] -last_updated: 2026-04-30 ---- - -## Aliases -- OFPA -- One File Per Actor -- 单 Actor 单文件 -- Per-Actor Asset 分块 - -## Definition -One File Per Actor（OFPA）是 Unreal Engine 5 World Partition 模式下的多用户协作编辑机制。每个 Actor 存储在独立文件中，而非整个关卡一个文件，从而支持多人同时编辑不同 Actor 而不产生源控制冲突。 - -## Problem Solved -传统关卡文件（所有 Actor 在一个 `.umap` 中）的协作问题： -- 两人同时打开同一关卡 → 文件冲突 -- 某人保存后另一人保存 → 后者覆盖前者改动 -- 锁定整个关卡才能安全编辑 → 串行化工作流程 - -## OFPA Workflow -1. 每个 Actor 存储为 `Path/To/Actor_Name/ActorName.uasset` -2. 多人可同时编辑不同 Actor，无需锁定 -3. 源控制按 Actor 粒度管理变更 -4. 关卡文件仅存储 Actor 引用而非内容 - -## Team Education Requirements -必须教育团队： -- **签出方式**：按 Actor 单独签出，而非整个关卡 -- **依赖理解**：Actor 引用关系在关卡文件中，更改引用仍需操作关卡文件 -- **命名规范**：Actor 命名必须符合团队规范，避免歧义 - -## File Count Management -OFPA 启用后大规模关卡产生数千个 Actor 文件： -- 必须建立**文件数预算** -- 监控文件数增长趋势 -- 构建关卡审计工具，标记尚未转换为 OFPA 的遗留关卡 - -## OFPA Limitations -- 大量 Actor 文件增加文件系统压力 -- 某些第三方插件可能不完全兼容 OFPA -- 源控制仓库大小显著增加（更多小文件） - -## Connections -- [[WorldPartition]] ← 协作模式 ← OneFilePerActor -- [[UnrealWorldBuilder]] ← 多用户支持 ← OneFilePerActor -- [[UnrealEngine5]] ← 核心引擎 ← OneFilePerActor - -## Sources -- [[unreal-world-builder]] diff --git a/wiki/concepts/OpenAI-Compatible-API.md b/wiki/concepts/OpenAI-Compatible-API.md deleted file mode 100644 index 569c2524..00000000 --- a/wiki/concepts/OpenAI-Compatible-API.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "OpenAI-Compatible-API" -type: concept -tags: [] ---- - -## Definition -OpenAI 兼容 API 是一种标准化的 AI 模型调用接口规范，遵循 OpenAI Chat Completions API 的请求/响应格式，使第三方 AI 系统能够被标准 AI 工具（如 n8n、LangChain）无缝调用。 - -## Key Properties -- **请求格式**：遵循 OpenAI `chat/completions` 规范 -- **模型指定**：通过 `model` 字段指定具体的 Agent（如 `openclaw:main`） -- **认证方式**：Bearer Token（`Authorization: Bearer `） -- **端点**：通常是 `/v1/chat/completions` - -## Example -OpenClaw Gateway 提供的 OpenAI 兼容端点： -- **URL**：`http://:18789/v1/chat/completions` -- **Body**： - ```json - { - "model": "openclaw:main", - "messages": [{"role": "user", "content": "..."}] - } - ``` - -## Related -- [[OpenClaw]] 通过 `gateway.http.endpoints.chatCompletions.enabled: true` 提供此接口 -- [[HTTP-ChatCompletions]] 是其底层协议 -- [[n8n]] 通过 HTTP Request 节点调用此接口 diff --git a/wiki/concepts/OpenAI兼容API.md b/wiki/concepts/OpenAI兼容API.md deleted file mode 100644 index 274f5b39..00000000 --- a/wiki/concepts/OpenAI兼容API.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "OpenAI兼容API" -type: concept -tags: [] -last_updated: 2026-05-02 ---- - -## Definition -Hermes Agent 内置的 API Server 暴露的标准 OpenAI Chat Completions 接口格式，允许任何兼容 OpenAI API 的客户端（如 n8n、curl、Postman）直接调用，无需额外 SDK 或中间件。 - -## Details -- 默认端口 **8642**，端点路径 `/v1/chat/completions` -- 认证方式：Bearer Token（通过 `API_SERVER_KEY` 配置） -- 健康检查端点：`GET /v1/health`，返回 `{"status": "ok"}` -- 支持 `X-Hermes-Session-Id` header 实现会话保持（v0.7.0+） -- 模型名称默认为 `hermes-agent`，可在 Profile 级别自定义 - -## Usage -- [[n8n]] 的 HTTP Request 节点通过 POST 到该端点实现 Agent 调用 -- curl 验证命令： - ```bash - curl http://localhost:8642/v1/chat/completions \ - -H "Authorization: Bearer YOUR_KEY" \ - -H "Content-Type: application/json" \ - -d '{"model": "hermes-agent", "messages": [{"role": "user", "content": "Hello!"}]}' - ``` - -## Related -- [[HermesAgent]] — API Server 的宿主框架 -- [[X-Hermes-Session-Id]] — API 的会话保持机制 -- [[工作流编排]] — 该 API 的主要应用场景 - -## Aliases -- OpenAI Compatible API -- OpenAI-compatible API endpoint -- Hermes API Server diff --git a/wiki/concepts/OpenClaw-Deployment-Expert.md b/wiki/concepts/OpenClaw-Deployment-Expert.md deleted file mode 100644 index 1d5060f2..00000000 --- a/wiki/concepts/OpenClaw-Deployment-Expert.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: "OpenClaw-Deployment-Expert" -type: concept -tags: [ai-agent, deployment, troubleshooting] -sources: [aionui-cowork-desktop] -last_updated: 2026-04-27 ---- - -## Definition - -OpenClaw-Deployment-Expert 是 AionUi 内置的 OpenClaw 安装、诊断与修复引导工具——帮助用户在桌面环境中完成 OpenClaw 的完整部署，并在 Agent 出现故障时提供远程诊断和自助修复指导，包括 `openclaw doctor` 诊断命令、配置文件修复和 gateway 重启操作。 - -## Key Characteristics -- **安装引导**：协助安装 OpenClaw（`npm install -g openclaw@latest`） -- **诊断命令**：`openclaw doctor` 自动诊断常见故障 -- **配置修复**：自动识别并修复配置文件问题 -- **gateway 重启**：远程重启 OpenClaw gateway -- **远程可用**：通过 Telegram/WebUI 远程调用，无需人到机器现场 - -## Related Concepts -- [[Remote-Rescue]]：OpenClaw-Deployment-Expert 的典型使用场景 -- [[OpenClaw]]：OpenClaw-Deployment-Expert 的服务对象 diff --git a/wiki/concepts/OpenTelemetry.md b/wiki/concepts/OpenTelemetry.md deleted file mode 100644 index bad33237..00000000 --- a/wiki/concepts/OpenTelemetry.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: "OpenTelemetry" -type: concept -tags: [DevOps, Observability, Cloud-Native, CNCF, AWS] -sources: [public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113, ctp-topic-67-cloud-native-observability-using-opentelemetry] -last_updated: 2026-04-27 ---- - -# OpenTelemetry - -**OpenTelemetry**（OTel）是云原生计算基金会（CNCF）的可观测性框架，提供跨语言的统一遥测数据采集标准，涵盖 Traces（链路追踪）、Metrics（指标）和 Logs（日志）三种信号。 - -## Core Components - -| Component | Role | Description | -|-----------|------|-------------| -| **OTLP Protocol** | 标准化传输 | OpenTelemetry Protocol，遥测数据的标准化传输格式 | -| **Language SDKs** | 应用集成 | 11 种语言提供统一 SDK（Java/Python/Go/Node.js/.NET 等） | -| **Collector** | 数据处理管道 | 标准化和转换遥测数据，包含 Receivers/Processors/Exporters/Extensions | -| **Auto-Instrumentation** | 零侵入注入 | 自动检测应用语言并注入遥测代码，无需修改业务代码 | - -## Three Signals Model（三信号模型） - -可观测性依赖三种互补的遥测信号： - -| Signal | 用途 | 特点 | -|--------|------|------| -| **Metrics** | 聚合统计 | CPU/内存/请求率等数值指标，适合告警和趋势分析 | -| **Logs** | 根因定位 | 离散的事件记录，包含时间戳和上下文，用于问题排查 | -| **Traces** | 全链路追踪 | 单一请求在分布式系统中的完整路径，每个 trace 包含多个 span | - -## OpenTelemetry Collector Architecture - -``` -Receivers（接收器）→ Processors（处理器）→ Exporters（导出器） - ↑ ↓ - Extensions（扩展） 目标后端（OpenSearch/Grafana/CloudWatch 等） -``` - -- **Receivers**：接收数据（AWS-specific 或开源标准） -- **Processors**：过滤和转换数据 -- **Exporters**：导出至后端（AWS Native / Open Source / Third-party） -- **Extensions**：辅助功能（SIGV 授权、健康检查） - -## AWS Distribution for OpenTelemetry - -AWS 提供的 OpenTelemetry 统一发行版，在 CNCF OpenTelemetry 基础上增加了 AWS 集成： - -- **统一代理**：同时收集 Traces/Metrics/Logs，无需分别部署多种 Agent -- **EKS Operator**：自动检测应用语言并创建预配置 Collector，实现零侵入式自动注入 -- **Pod 级 IAM**：通过 Pod Identity Associations 实现 Pod 级权限控制，无需修改 ServiceAccount -- **日志支持**：最新版本支持日志采集，完善了可观测性三信号覆盖 -- **Managed Collector for Prometheus**：无服务器、无代理的 Prometheus 指标自动发现和抓取 - -## EKS Integration Pipeline - -典型 EKS 环境下的端到端可观测性管道： - -``` -应用容器 (Auto-Instrumented by OTel SDK) - ↓ -Fluent Bit (DaemonSet) → 采集容器日志 - ↓ (端口 55681) -OpenTelemetry Collector (Sidecar/Deployment) - ↓ (OTLP) -Amazon OpenSearch Service / CloudWatch / Prometheus / Grafana -``` - -## Key Claims - -- OpenTelemetry 是 CNCF 毕业项目，提供 vendor-agnostic（厂商无关）的统一可观测性方案 -- 解决了微服务架构下不同组件使用不同 SDK 和工具的碎片化问题 -- OTLP 是 OpenTelemetry 的标准化数据传输协议，所有主流可观测性后端均支持 -- AWS Distribution for OpenTelemetry 简化了 AWS 环境（尤其是 EKS）的部署复杂度 -- 自动注入（Auto-Instrumentation）实现零侵入式集成，无需修改业务代码 - -## Related Concepts - -- [[ELK-Stack]]：OpenTelemetry 常与 OpenSearch/Elasticsearch 配合作为日志后端 -- [[Cloud-Monitoring]]：可观测性是云监控的核心组成部分 -- [[Amazon-EKS]]：OpenTelemetry 在 AWS EKS 环境下的典型部署场景 -- [[Fluent-Bit]]：EKS 环境中常用的日志采集器，与 OpenTelemetry 配合使用 -- [[Grafana]]：OpenTelemetry 常用的可视化后端 -- [[Prometheus]]：OpenTelemetry Metrics 的常用后端 -- [[Observability（可观测性）]]：OpenTelemetry 服务的核心目标 - -## Sources - -- [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]] -- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] diff --git a/wiki/concepts/OpenText-Tagging-Standard.md b/wiki/concepts/OpenText-Tagging-Standard.md deleted file mode 100644 index 873fa45b..00000000 --- a/wiki/concepts/OpenText-Tagging-Standard.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: "OpenText Tagging Standard" -type: concept -tags: - - Cloud-Governance - - FinOps - - Tagging - - Multi-Cloud -last_updated: 2026-04-14 ---- - -## Definition -OpenText 标签标准是一套跨 AWS、Azure、GCP 三大云厂商的统一资源标签规范，通过标准化前缀和标签值集，实现云成本的精确归属、资源责任的明确划分和安全分类的自动化执行。 - -## Version History - -| 版本 | 日期 | 覆盖范围 | -|------|------|---------| -| V1 | 2023-10-03 | 云账户、云资源（计算/存储/网络） | -| V2 | 2025-04-29 | V1 + Kubernetes 对象 + 容器镜像 | - -## Standard Design Principles - -1. **最低共同标准**：采用 GCP 最严格字符集（小写、数字、连字符、下划线） -2. **OT_ 前缀约定**：区分 OpenText 专有标签（云资源层面） -3. **分层扩展**：V2 新增 `app.opentext.com`（K8s）和 `com.opentext.image`（容器镜像）前缀 -4. **实际可行**：优先考虑快速实施，而非完美方案 - -## Standardized Tags - -### V1 Core Tags -- `OT_BU` — 业务单元 -- `OT_Technical_Contact` — OT 技术联系人 -- `OT_Cost_Center` — 成本中心 -- `OT_Customer` — 客户 -- `OT_Tenant` — 租户 -- `OT_Environment` — 环境（生产/实验室/客户数据） -- `OT_Master_Product` — OT 主产品 -- `OT_Custom_Field_*` — 自定义字段 -- `OT_Platform` — 平台 -- `OT_Cost_Type` — 成本类型 -- `OT_Customer_Data` — 客户数据标识 - -### V2 Extended Tags -- **Kubernetes**: `app.opentext.com/*` 前缀 -- **Container Images**: `com.opentext.image/*` 前缀 - -## Exceptions -- `environment` — 已有通用约定，无需 OT_ 前缀 -- `BU` — 已有通用约定，无需 OT_ 前缀 -- `cost_center` — 已有通用约定，无需 OT_ 前缀 -- `name`（AWS）— AWS 保留标签，无需 OT_ 前缀 - -## Implementation - -### Terraform Automation -```hcl -# 方式1: 模块参数 -aws_instance.example { - tags = { - OT_Environment = "production" - OT_BU = "engineering" - OT_Cost_Center = "CC-12345" - } -} - -# 方式2: Provider 默认标签 -provider "aws" { - default_tags { - tags = { - OT_Environment = "production" - OT_BU = "engineering" - } - } -} -``` - -### Tagging Pipeline -``` -启用计费标签 → CUR (Cost and Usage Report) → - → HCMX - → Phenops - → QuickSight - → Power BI -``` - -## Governance -- **Owner**: FinOps 团队 -- **KPI**: 99% 可标签资源完成打标（通过 SCP 或标签策略强制） -- **Documentation**: Confluence（产品短代码和 BU 列表） - -## Connections -- [[FinOps]] — 标签标准由 FinOps 驱动，为成本优化提供基础设施 -- [[AWS-Tagging-Standards]] — OpenText 标准是 AWS 标签规范的扩展 -- [[Terraform]] — IaC 自动化打标工具 - -## References -- [[public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1]]（V1） -- [[public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429]]（V2） diff --git a/wiki/concepts/Oracle-Manipulation.md b/wiki/concepts/Oracle-Manipulation.md deleted file mode 100644 index efcd5999..00000000 --- a/wiki/concepts/Oracle-Manipulation.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: "Oracle Manipulation" -type: concept -tags: [smart-contract, vulnerability, defi, oracle, flash-loan] -sources: [blockchain-security-auditor] -last_updated: 2026-04-25 ---- - -## 中文定义 - -**预言机操纵（Oracle Manipulation）**：攻击者利用 DeFi 协议对价格预言机输入的信任，通过在单笔交易内（通常借助闪电贷）操纵市场价格，从而在借贷、清算、DEX 交易等场景中获取非法收益的攻击类型。 - -## 问题描述 - -许多 DeFi 协议依赖链上价格预言机（直接从 AMM 池获取价格）来计算抵押品价值、清算阈值、交易价格等关键参数。由于 AMM 的"即时价格"可以被单笔交易内的操作所操纵，攻击者可以在无需长期持仓的情况下： -1. 在操纵价格时执行借贷/清算获取超额资产 -2. 在价格恢复后平仓获利 - -## 操纵模式 - -### 1. AMM 即时价格操纵（Spot Price Manipulation） -```solidity -// 有漏洞的代码：使用 AMM 即时储备计算价格 -(uint112 reserve0, uint112 reserve1,) = pair.getReserves(); -uint256 price = (uint256(reserve1) * 1e18) / reserve0; -// 攻击者：在同一笔交易中先Swap大量代币改变储备，再执行借贷 -``` - -**攻击步骤**： -1. Flash Loan 借入资产 A -2. 在 DEX 中用资产 A 兑换资产 B（推动 B 的价格） -3. 操纵后的价格被借贷协议读取，攻击者以虚高抵押品价值借款 -4. 归还 Flash Loan -5. 偿还部分借款，保留利润 - -### 2. 时间加权平均价格（TWAP）操纵 -Uniswap V3 的 TWAP 预言机理论上比即时价格更安全，但仍可在以下条件下被操纵： -- 操纵成本 < 攻击收益 -- 资金池流动性不足（攻击成本低） -- TWAP 时间窗口过短 - -### 3. Chainlink 聚合价格操纵 -Chainlink 的去中心化价格源在极端市场条件下（如流动性枯竭）可能出现价格偏差： -- 预言机更新延迟 -- 小币种流动性不足导致聚合价格失真 -- Chainlink 的 `staleness` 检查缺失或配置不当 - -## 防御机制 - -### TWAP（Time-Weighted Average Price） -```solidity -// Uniswap V3 的 TWAP：使用历史时间加权平均而非即时价格 -(uint256 price, ) = OracleLibrary.getQuoteAtTick( - currentTick, - 1000000, // 1 AMM token - token0, - token1 -); -``` - -### Chainlink 预言机 + 合法性验证 -```solidity -(, int256 price, , uint256 updatedAt, ) = priceFeed.latestRoundData(); -require(price > 0, "Invalid price"); -require(updatedAt > block.timestamp - MAX_STALENESS, "Stale price"); -require(answeredInRound >= roundId, "Incomplete round"); -``` - -### Chainlink Off-Chain 监控 -设置价格异常波动告警，在 TWAP 偏离超过阈值时暂停协议。 - -## 关键案例 -- [[Euler-Finance]]：donate-to-reserves 攻击结合了预言机操纵（虽然主要是内部会计逻辑漏洞） -- [[blockchain-security-auditor]] 的 Source Page 示例代码：展示了完整的有漏洞的借贷合约和修复方案 - -## 关联概念 -- [[Flash-Loan-Attack]]：预言机操纵几乎总是借助闪电贷实现（单笔交易内完成借贷和操纵） -- [[Reentrancy]]：两者常被组合使用（操纵价格 + 重入执行操作） -- Uniswap V2 / V3：主要 AMM 平台，也是大多数预言机操纵攻击的目标 diff --git a/wiki/concepts/Orchestration.md b/wiki/concepts/Orchestration.md deleted file mode 100644 index 41cbb936..00000000 --- a/wiki/concepts/Orchestration.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Orchestration" -type: concept -tags: - - EDA - - Architecture - - Microservices - - AWS -last_updated: 2026-04-14 ---- - -## Aliases -- Orchestration Pattern -- 编排模式 -- 集中式服务协调 - -## Definition -编排模式（Orchestration）是一种由中央协调器（Orchestrator）集中控制和协调多个服务执行复杂业务流程的模式。与编舞模式（Choreography）的去中心化不同，编排模式通过中央工作流引擎驱动各服务按顺序执行任务。 - -## AWS Implementation -- **AWS Step Functions**：AWS 提供的工作流服务，用于构建状态机 - - **State Machine**：状态机由多个 State（状态）组成，每个 State 代表一个工作步骤 - - **Transitions**：状态转换定义从一个状态到下一个状态的条件和路径 - - **Standard Workflows**：长时运行工作流，适合人工审批、长时间处理流程 - - **Express Workflows**：高频短时工作流，适合毫秒级响应的大规模事件处理 - -## Characteristics -- **Centralized**：中央协调器控制整体流程 -- **Visible**：业务流程和状态转换清晰可见，便于监控和追踪 -- **Easier Debugging**：工作流失败时可准确定位到具体状态 -- **Tight Coupling Risk**：中央协调器与各服务存在一定耦合 - -## Comparison with Choreography -| 维度 | Orchestration（编排） | Choreography（编舞） | -|------|---------------------|---------------------| -| 控制 | 集中式 | 去中心化 | -| 协调器 | 有（Step Functions） | 无 | -| 复杂度 | 局部高，整体低 | 局部低，整体高 | -| 可观测性 | 易于追踪 | 较难追踪 | -| 适用场景 | 复杂、有明确业务流程 | 简单、独立的服务 | - -## Sources -- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] -- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] diff --git a/wiki/concepts/Ordered-Layer.md b/wiki/concepts/Ordered-Layer.md deleted file mode 100644 index d7c7848c..00000000 --- a/wiki/concepts/Ordered-Layer.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Ordered Layer (Firewall Policy)" -type: concept -tags: ["AWS", "Firewall", "Checkpoint", "Network-Security", "Policy"] -sources: ["ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security"] -last_updated: 2026-04-28 ---- - -## Definition -Ordered Layer 是 Checkpoint Firewall 中防火墙策略的组织结构——策略按优先级顺序排列的多层检查机制。流量必须逐层通过检查，全部通过后方可放行。与之对应的是 Inline Layer（基于账号编号的父子规则结构）。 - -## Mechanism -在 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中，Pradeep 演示了 Checkpoint 在 Frankfurt Landing Zone 的 Ordered Layers： - -1. **地理封锁（Geo-blocking）**：按来源/目标地理位置阻断流量 -2. **类型检查（Type）**：基于资源的 `Type` 标签进行访问控制 -3. **业务单元隔离（BU）**：基于 `BU`/`BusinessUnit` 标签隔离不同业务单元间的通信 -4. **产品隔离（Product）**：基于 `Product` 标签隔离不同产品间的通信 -5. **环境隔离（Environment）**：基于 `Environment` 标签隔离不同环境（生产/非生产） -6. **服务器角色（Server Role）**：基于 `ServerRole` 标签进行细粒度角色级控制 - -**核心特性**： -- 顺序执行：流量必须通过每一层检查，任一层拒绝则整体拒绝 -- 默认阻断跨产品线通信（Inter-product is not allowed） -- 策略以标签为依据，替代传统的 IP 地址规则 - -## Comparison with Traditional Firewall Rules - -| 维度 | 传统 IP-Based 规则 | Ordered Layer + 标签驱动 | -|------|-------------------|------------------------| -| 规则维护 | IP 变更需手动更新 | 标签自动关联，无需更新规则 | -| 动态性 | 静态，难以适应云 | 动态，随资源标签变化 | -| 扩展性 | 随账号/服务增长爆炸 | 通过 OU + 标签层级管控 | -| 管理复杂度 | 高（N^2 规则） | 低（层级 + 标签维度） | - -## Connections -- [[Checkpoint-Firewall]] — Ordered Layer 是 Checkpoint 策略集的核心组织方式 -- [[Inline-Layer]] — Checkpoint 策略的两种组织模式：Ordered Layer（顺序检查）vs Inline Layer（账号维度） -- [[AWS-Landing-Zone]] — 在 LZ 网络隔离架构中实施 -- [[Resource-Tagging]] — Ordered Layer 依赖标签体系驱动策略执行 -- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] diff --git a/wiki/concepts/Organic-Traffic-Amplification.md b/wiki/concepts/Organic-Traffic-Amplification.md deleted file mode 100644 index 0b5f18b4..00000000 --- a/wiki/concepts/Organic-Traffic-Amplification.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: "Organic Traffic Amplification" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-26 ---- - -## Definition -自然流量放大——通过优化直播间内的用户行为数据（停留时长、互动率、点击率等），触发平台推荐算法给予更多免费自然流量曝光的策略体系。核心原理：**平台不是根据直播时长分配流量，而是根据直播间内的用户行为数据质量分配流量**。 - -## Algorithm Priority Stack -平台算法评估直播间的数据优先级（从高到低）： -1. **停留时长（Watch Time）** — 最核心指标，目标 >60秒 -2. **互动率（Engagement Rate）** — 评论/点赞/关注/分享的综合比率，目标 >5% -3. **商品点击率（Product Click-Through Rate）** — 目标 >10% -4. **购买转化率（Purchase Conversion Rate）** — 目标 >3% - -## Tactics by Metric - -### Increasing Watch Time（增加停留时长） -- **福袋/抽奖留人**：每15-20分钟运行一次，设置「关注+评论」参与条件 -- **悬念话术**：「我一直和品牌谈这个价格，还没谈下来，先让大家看看值不值——觉得值的打'值'」 -- **价格悬念**：「价格先不说，先让大家看产品值不值，2分钟后揭晓！」（保持悬念2-3分钟） -- **互动指令**：高频提问让观众打字互动，「用过的打1，没用过的打2」 - -### Increasing Engagement Rate（增加互动率） -- **高频互动指令**：「觉得好用的点赞点起来，点赞到XX我就降价！」 -- **选择题互动**：「想要A的扣A，想要B的扣B！让我看看哪边人多！」 -- **点名欢迎**：「欢迎XXX，感谢关注！」让新进观众感到被看见 -- **弹幕引导**：「有没有和我一样问题的，有的话评论区扣'1'」 - -### Increasing Conversion Rate（增加购买转化率） -- **稀缺紧迫感**：「库存只剩XX件，卖完今天就没了」 -- **价格锚定**：零售价→直播专属价→叠加赠品→最终到手价，分层揭示 -- **社会认同**：「XX人已经下单了，你们下手真快」 -- **限时倒计时**：「3、2、1上链接，5秒内下单我再送XX！」 - -## Organic Share Targets by Phase -| 阶段 | 自然流量占比目标 | 说明 | -|------|----------------|------| -| 冷启期（0-30场） | < 30% | 重点积累停留时长和互动数据，算法尚未学习账号 | -| 成长期（30-100场） | 30-50% | 逐步降低付费依赖，有机开始起量 | -| 成熟期（100场+） | > 50% | 健康模型，自然流量成为主要流量来源 | - -## Healthy Organic Model -成熟直播间的健康指标： -- 自然推荐流量占比 **>50%** -- GPM（每千次曝光成交额）**>800元** -- UV值（每访客价值）**>1.5元** -- 关注转化率 **>3%** - -## Connections -- [[Five-Phase Script Framework]] — Stage 1（留人钩子）和 Stage 3（信任建立）的互动数据直接贡献自然流量推荐权重 -- [[Qianchuan Campaign]] — 付费流量带来精准用户，通过优秀的停留时长和互动数据「撬动」平台给予更多自然流量推荐（付费+有机协同飞轮） -- [[Product Sequencing]] — 自然流量波峰出现时，必须有匹配的产品在场——波峰时产品不对，转化白白浪费 -- [[Host Incubation System]] — 优秀主播能通过话术节奏主动「制造」停留时长和互动高峰，是算法的核心优化变量 -- [[Douyin]] — 抖音推荐算法对停留时长的权重最高（完播率逻辑） -- [[Kuaishou]] — 快手算法对信任关系（老铁互动）的权重更高 - -## Sources -- [[marketing-livestream-commerce-coach]] diff --git a/wiki/concepts/Organizational-Second-Hit-Syndrome.md b/wiki/concepts/Organizational-Second-Hit-Syndrome.md deleted file mode 100644 index b4110775..00000000 --- a/wiki/concepts/Organizational-Second-Hit-Syndrome.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Organizational Second Hit Syndrome" -type: concept -tags: [sre, reliability, incident-response, organizational-resilience] -last_updated: 2026-04-20 ---- - -# Organizational Second Hit Syndrome - -组织二次冲击综合征（Organizational Second Hit Syndrome）是一种类比神经学"二次冲击综合征（Second Impact Syndrome, SIS）"的故障现象。 - -## Definition -重大故障（first hit）发生后，组织会进入一段脆弱期（vulnerable period）。在此期间，如果发生第二次故障（second hit），往往会引发**强烈、广泛且有时具有破坏性的组织反应**。 - -## Background -这一概念由 [[Richard-Cook]] 博士首次提出（2026年3月7日），由 [[John-Allspaw]] 和 [[Richard-Cook]] 在 [[Adaptive-Capacity-Labs]] 发表。 - -## Key Characteristics -- **时间相关性**：Second hit 发生在 first hit 之后的脆弱期内 -- **影响范围**：反应强度大，影响面广，可能造成组织级损害 -- **与神经学 SIS 的类比**：神经学 SIS 中，第一次脑部损伤后如果再次受伤，即使伤势轻微也可能导致灾难性后果；组织 SIS 同理 - -## Implications for SRE -1. **故障后的恢复期需要特别关注**：首次故障后不要放松警惕 -2. **制定"二次故障"应对预案**：在复盘和恢复阶段保持警戒 -3. **组织层面的韧性建设**：建立跨团队沟通机制，防止信息孤岛导致的二次事故扩大 -4. **MTTR（Mean Time to Recovery）优化**：不仅关注单次故障，还要关注故障间的组织状态 - -## Related Concepts -- [[Incident-Response]] -- [[BlamelessPostMortem]] -- [[Resilience]] -- [[Self-Healing]] - -## Source -- SRE Weekly Issue #513 — [[sre-weekly-issue-513]] diff --git a/wiki/concepts/Outcome-vs-Output.md b/wiki/concepts/Outcome-vs-Output.md deleted file mode 100644 index 77d2aa6a..00000000 --- a/wiki/concepts/Outcome-vs-Output.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Outcome vs. Output" -type: concept -tags: ["product-management", "mindset", "strategy"] -last_updated: 2026-04-30 ---- - -## Aliases -- Outcome over Output -- 结果导向 vs. 产出导向 -- 以结果为中心 - -## Definition -Outcome vs. Output（结果 vs. 产出）—— 产品管理的核心思维模式：**结果（Outcome）** 是用户行为的实际改变和业务价值达成；**产出（Output）** 是交付的功能数量、特性或里程碑。 - -## Core Distinction - -| 维度 | Output（产出） | Outcome（结果） | -|------|--------------|----------------| -| 关注点 | 做了什么 | 用户改变了什么 | -| 度量 | 功能数量、上线时间 | 指标改善、用户行为变化 | -| 陷阱 | 功能上线即成功 | 以活动代替进步 | -| 典型错误 | "我们交付了 X 功能" | 没人用的功能 | - -## Key Quotes -> "A feature shipped that nobody uses is not a win — it's waste with a deploy timestamp." — [[Product Manager Agent]]（Alex） - -> "Features are hypotheses. Shipped features are experiments. Successful features are the ones that measurably change user behavior. Everything else is a learning." — [[Product Manager Agent]] - -## Why It Matters -- **防止虚荣指标**：团队交付了很多功能，但用户留存没有改善 -- **保护资源**：避免在无人使用的功能上浪费工程资源 -- **对齐业务**：确保团队努力直接转化为商业价值 - -## Application -[[Product Manager Agent]] 在所有产品文档（PRD、Opportunity Assessment、Launch Retrospective）中坚持使用 Outcome 思维，并在成功指标定义中要求可量化的用户行为指标（如 30 天留存率、功能激活率）而非功能完成状态。 - -## Related -- [[Product Requirements Document (PRD)]] — 要求明确的结果指标（Goals & Success Metrics） -- [[Product Manager Agent]] — 坚持结果导向的核心理念 -- [[Product Roadmap (Now/Next/Later)]] — 路线图按结果而非交付物组织 diff --git a/wiki/concepts/OverlapAwareChunking.md b/wiki/concepts/OverlapAwareChunking.md deleted file mode 100644 index 8e041963..00000000 --- a/wiki/concepts/OverlapAwareChunking.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "OverlapAwareChunking" -type: concept -tags: ["voice-ai", "audio-processing", "transcription", "chunking"] -last_updated: 2026-05-02 ---- - -# OverlapAwareChunking（重叠感知分块） - -## Definition - -Overlap-Aware Chunking 是将超长音频（>30 分钟）切分为多个重叠片段再分别转录的技术。重叠窗口（默认 30s）在合并阶段被裁剪，防止词边界在切分处被切断而产生重复或遗漏。 - -## The Problem - -Whisper 类模型有最大输入时长限制（通常 30 秒到 10 分钟，取决于模型）。超出限制的音频如果直接截断，会导致： -1. 词在切分点被切断 → 产生乱码/重复词 -2. 最后一块音频尾部被截断 → 内容丢失 -3. 丢失跨块语义连贯性 - -## The Solution - -``` -原始音频（120 分钟） - ↓ 分块（每块 30 分钟，重叠 30 秒） -chunk_0000: [0:00 - 30:30] -chunk_0001: [30:00 - 60:30] ← 重叠 30 秒 -chunk_0002: [60:00 - 90:30] ← 重叠 30 秒 -... - ↓ 逐块 FasterWhisper 转录 - ↓ 合并（裁剪重叠区域） -最终转录文本（无重复/遗漏） -``` - -## Key Parameters - -| 参数 | 默认值 | 说明 | -|------|--------|------| -| `chunk_duration` | 1800s（30分钟） | 每块时长 | -| `overlap` | 30s | 重叠窗口大小 | -| 合并时裁剪 | 30s | 从第二块开始，裁掉前 30 秒 | - -## Critical Insight - -> "Overflow is silent and corrupts output without error." — 溢出无声损坏输出 - -分块策略的错误不会抛出异常，只会在最终合并的转录文本中出现乱码/重复/遗漏，难以事后发现。 - -## Related Concepts -- [[FasterWhisper]] — 分块音频的转录执行方 -- [[VoiceActivityDetection]] — VAD 过滤在分块前执行效果更佳 -- [[StructuredTranscriptJSON]] — 分块合并后结构化输出的最终格式 - -## Related Sources -- [[engineering-voice-ai-integration-engineer]] diff --git a/wiki/concepts/Overlay-Network.md b/wiki/concepts/Overlay-Network.md deleted file mode 100644 index ecb868bf..00000000 --- a/wiki/concepts/Overlay-Network.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Overlay Network" -type: concept -tags: [AWS, Networking, Virtualization, SD-WAN] -sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] -last_updated: 2026-05-07 ---- - -## Overlay Network - -叠加网络（Overlay Network）是在现有物理网络（Underlay）之上构建的逻辑网络，通过隧道技术（Tunneling）实现复杂的路由、安全和流量工程功能，与底层物理基础设施解耦。 - -## Definition - -- **Underlay（底层网络）**: 物理基础设施——路由器、交换机、光纤链路（如 AWS 区域间的物理连接） -- **Overlay（叠加网络）**: 逻辑隧道网络——在 Underlay 之上构建的虚拟网络层，通过封装（Encapsulation）实现端到端连接 -- **解耦价值**: Overlay 的路径选择、策略控制与 Underlay 的物理拓扑相互独立 - -## Key Mechanisms - -- **隧道协议**: GRE、VXLAN、IPSec、WireGuard 等 -- **封装**: 将原始数据包封装在新的 IP 包头中，通过 Underlay 传输 -- **网络虚拟化**: VPC 即为 AWS 原生的 Overlay Network 实现 - -## In AWS Transit Gateway + SD-WAN Architecture - -在 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 中描述的架构： - -- **Underlay**: AWS 区域间的物理网络连接（APJ/EMEA/AMS 区域 Hub 之间的 Full Mesh） -- **Overlay**: Silver Peak SD-WAN 在 AWS 中部署的虚拟 SD-WAN 设备构成的逻辑网络 -- **价值**: SD-WAN Overlay 实现动态路径选择，即使 Underlay 静态路由失效也能自动切换 - -## Relationship to Related Concepts - -| 概念 | 关系 | -|------|------| -| [[AWS-Transit-Gateway-TGW]] | AWS 原生 Overlay 服务（区域级） | -| [[SD-WAN]] | Overlay 的一种实现形式 | -| [[Hub-and-Spoke]] | Overlay 网络的拓扑结构模式 | - -## Connections - -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 场景 ← [[Overlay-Network]] -- [[SD-WAN]] ← 实现方式 ← [[Overlay-Network]] -- [[AWS-Transit-Gateway-TGW]] ← AWS 原生 ← [[Overlay-Network]] - -## Sources - -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/concepts/Override-Status.md b/wiki/concepts/Override-Status.md deleted file mode 100644 index cb775097..00000000 --- a/wiki/concepts/Override-Status.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Override Status" -type: concept -tags: - - AWS - - Scheduling - - Control - - AWS-Instance-Scheduler -sources: - - ctp-topic-27-aws-instance-scheduler -last_updated: 2026-05-12 ---- - -## Override Status - -AWS Instance Scheduler 中的高级配置机制，允许管理员强制覆盖正常的调度规则，将实例保持在特定状态（通常为停止状态）。 - -## Core Mechanism - -通过在实例上设置 `Override` 标签来激活： - -- **`Override = true`**：强制将实例保持在停止状态，即使在预设的启动时间内也不启动 -- **`Override = false`**：恢复正常调度逻辑 - -## Use Cases - -### 1. 紧急维护场景 -- 实例正在进行紧急安全补丁更新 -- 临时禁用调度以避免干扰关键操作 - -### 2. 资源保留场景 -- 保留特定环境（如 UAT/预生产）在特定时期保持运行 -- 临时排除特定实例从自动调度 - -### 3. 故障规避 -- 实例上运行的任务无法接受意外重启 -- 生产等效环境需要更精细的控制 - -## Relationship to Tagging - -Override Status 通过 `Override` 标签实现，是 Instance Scheduler [[Tagging]] 机制的重要组成部分： - -| 标签键 | 作用 | 优先级 | -|--------|------|--------| -| `Schedule` | 指定调度名称 | 正常调度 | -| `Override = true` | 强制停止覆盖 | 最高优先级 | - -## Related Pages -- [[AWS-Instance-Scheduler]] — 主要使用场景 -- [[Tagging]] — 实现机制 -- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源 diff --git a/wiki/concepts/PCG.md b/wiki/concepts/PCG.md deleted file mode 100644 index 1a15bbe0..00000000 --- a/wiki/concepts/PCG.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "PCG" -type: concept -tags: ["unreal-engine", "procedural-generation", "open-world"] -sources: ["unreal-technical-artist", "unreal-world-builder"] -last_updated: 2026-04-26 ---- - -## Definition -Procedural Content Generation（程序化内容生成），UE5 框架，通过图节点控制开放世界资产分布、地形采样、密度过滤和实例化放置。输出确定性：相同输入图和参数始终产生相同结果。 - -## Core Pipeline -1. **Input**：Landscape Surface Sampler → 密度和坡度过滤 -2. **Transform Points**：Jitter 位置（±1.5m XY）、随机旋转（仅 Yaw）、缩放变化（0.8–1.3） -3. **Density Filter**：Poisson Disk 最小间距（防止重叠）、Biome 密度纹理采样 -4. **Exclusion Zones**：道路缓冲（5m）、玩家路径缓冲（3m）、手动放置 Actor 排除半径（10m） -5. **Static Mesh Spawner**：权重分配（橡树 40%、松树 35%、桦树 20%、枯树 5%），全启用 Nanite - -## Parameter Interface（必须文档化） -- GlobalDensityMultiplier（0.0–2.0） -- MinSeparationDistance（1.0–5.0m） -- EnableRoadExclusion（bool） - -## Performance Constraints -- 最差情况下生成时间 < 3 秒 -- 流式加载不得造成帧卡顿（World Partition 配合） -- PCG 密度控制：PCG → Nanite，密度可扩展至数千实例 - -## Advanced Patterns -- Gameplay Tags 查询驱动环境分布规则 -- 递归 PCG：图 A 的输出作为图 B 的输入 -- Runtime PCG：几何体破坏后重新运行图 -- PCG 调试工具：编辑器视口内可视化点密度、属性值、排除区边界 - -## Related -- [[Nanite]] — PCG 放置资产的首选渲染模式 -- [[WorldPartition]] — 与 PCG 流式加载协同 -- [[Procedural-Level-Design]] — 更广义的程序化关卡设计概念 diff --git a/wiki/concepts/PDF教材数字化.md b/wiki/concepts/PDF教材数字化.md deleted file mode 100644 index 65645935..00000000 --- a/wiki/concepts/PDF教材数字化.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "PDF教材数字化" -type: concept -tags: [] -sources: [] -last_updated: 2025-05-13 ---- - -## 定义 -将纸质教材扫描或转换为 PDF 格式，并进行结构化整理（如按章节、学段、学科分类），以便于传播、搜索和离线使用。 - -## 核心要素 -- **格式转换**：从纸质或图片扫描为 PDF，支持文本搜索 -- **结构化整理**：按学段、学科、版本等维度组织 -- **可获取性**：通过开源仓库或云存储让用户能便捷下载 - -## 实践案例 -- [[chinatextbook-41-53-gb-中国小学-初中-高中-大学-pdf-教材]]：41.53 GB 的中国教材 PDF 集合，覆盖小学至大学阶段 - -## 相关概念 -- [[教育资源开源]]：数字化是实现教育资源开源的重要技术手段 diff --git a/wiki/concepts/PIIRedaction.md b/wiki/concepts/PIIRedaction.md deleted file mode 100644 index 076e1c23..00000000 --- a/wiki/concepts/PIIRedaction.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "PIIRedaction" -type: concept -tags: ["privacy", "pii", "gdpr", "hipaa", "voice-ai"] -last_updated: 2026-05-02 ---- - -# PIIRedaction（个人身份信息脱敏） - -## Definition - -PII Redaction 是在转录管道中将个人身份信息（姓名、身份证号、信用卡、电话、邮箱等）自动检测并替换为占位符或删除的处理阶段。作为命名且可配置的管道阶段嵌入，不是事后补丁。 - -## Why It Must Be a Pipeline Stage - -- **合规性**：HIPAA（医疗）、GDPR（欧洲）、SOC 2（企业安全）要求处理录音/转录时保护 PII -- **不可逆性**：一旦 PII 被写入日志/CMS/数据库，删除成本极高 -- **范围**：医疗记录（MRN、病历号）、法律记录（案件号、律师姓名）、客服录音（账号、密码） - -## Detection Methods - -| 方法 | 适用场景 | 精度 | -|------|---------|------| -| 正则规则 | 电话、邮箱、信用卡、SSN | 高（规则明确） | -| NER 模型 | 人名、地址、机构名 | 中（依赖模型质量） | -| 云端 PII API | 大规模、多种 PII 类型 | 高（AssemblyAI/云 ASR 内置） | - -## Pipeline Position - -``` -音频 → 预处理 → 转录 → PII 检测 → 结构化输出 → 下游系统 - ↑ - PIIRedaction 在转录之后执行 -``` - -## Redaction Symbols - -| 符号 | 含义 | -|------|------| -| `[REDACTED]` | 已脱敏 | -| `[PHONE]` | 电话号码 | -| `[EMAIL]` | 邮箱地址 | -| `[SSN]` | 社保号 | -| `[NAME]` | 人名 | - -## Critical Rule - -> "Never log raw audio content or unredacted transcript text in production monitoring systems." — 生产监控中禁止记录未脱敏内容 - -## Related Concepts -- [[StructuredTranscriptJSON]] — PII 脱敏后的输出格式 -- [[LLMHandoff]] — 脱敏后传递给 LLM（避免 LLM 学习 PII） -- [[PIIRedaction]] 在 [[engineering-voice-ai-integration-engineer]] 中是命名管道阶段 - -## Related Sources -- [[engineering-voice-ai-integration-engineer]] diff --git a/wiki/concepts/PMDelegationPattern.md b/wiki/concepts/PMDelegationPattern.md deleted file mode 100644 index 740b7242..00000000 --- a/wiki/concepts/PMDelegationPattern.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "PM Delegation Pattern" -type: concept -tags: [multi-agent, project-management, coordination] -sources: [autonomous-project-management] -last_updated: 2026-04-22 ---- - -## 定义 -主会话仅负责协调（coordinator），所有执行下沉至子 Agent 的委托模式。每个子 Agent 作为独立的 PM（Project Manager），拥有自己的 STATE.yaml 文件。 - -## 核心规则 -- **主会话最大工具调用数**：0-2 步（仅 spawn/send 操作） -- **PM 子 Agent 职责**：拥有和管理自己的 STATE.yaml 文件 -- **PM 可派生子子 Agent**：支持多层级的并行子任务 -- **Git 版本控制**：所有状态变更必须提交至 Git - -## 工作流 -1. 新任务到达主会话 -2. 检查 PROJECT_REGISTRY.md 确认是否存在对应 PM -3. 存在 PM → `sessions_send(label="pm-xxx", message="[task]")` -4. 新项目 → `sessions_spawn(label="pm-xxx", task="[task]")` -5. PM 执行任务并更新 STATE.yaml，完成后汇报主会话 -6. 主会话向用户汇总 - -## 标签约定 -使用 `pm-{project}-{scope}` 格式（如 `pm-auth-refactor`），便于追踪和管理。 - -## 与 [[CEO Pattern]] 的关系 -PM Delegation Pattern 是 CEO Pattern 在项目管理场景的具体实现——主会话扮演 CEO，仅做战略决策；PM 子 Agent 扮演部门负责人，负责具体执行。 diff --git a/wiki/concepts/POC-Scoping.md b/wiki/concepts/POC-Scoping.md deleted file mode 100644 index 05fd7563..00000000 --- a/wiki/concepts/POC-Scoping.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: "POC Scoping" -type: concept -tags: [sales, pre-sales, proof-of-concept, evaluation] -last_updated: 2026-04-25 ---- - -## Definition -POC Scoping 是严格限定的概念验证（Proof of Concept）范围设计方法论——将 POC 从"免费试用"转变为有二元结果（成功/失败）的结构化评估，标准在开始前就已明确定义，避免范围蔓延和评估疲劳。 - -## Core Principles - -### Start With the Problem Statement -> "This POC will prove that [product] can [specific capability] in [buyer's environment] within [timeframe], measured by [success criteria]." - -如果无法写出这句话，POC 就未完成范围定义。 - -### Define Success Criteria in Writing Before Starting -- 模糊的成功标准 → 模糊的结果 → "我们需要更多时间评估" → 失败 -- 明确定义：通过标准是什么？未通过标准是什么？ - -### Scope Aggressively -- POC 最大风险是范围蔓延 -- 一个聚焦的 POC 证明一个关键结论 > 宽泛的 POC 什么都没证明 -- 当买家要求增加测试项时："Absolutely — in phase two. Let's nail the core use case first." - -### Hard Timeline -- 标准：2-3 周 -- 更长的 POC 不会产生更好的决策，只会产生评估疲劳和竞争对手反击 - -### Build in Checkpoints -- 中期检查点确认进度，及早发现偏差 -- 不要等到最终汇报才发现自己与买家标准不一致 - -## POC Scoping Template -```markdown -# Proof of Concept: [Account Name] - -## Problem Statement -[一句话：POC 将证明什么] - -## Success Criteria -| Criterion | Target | Measurement Method | -|-----------|--------|-------------------| -| [能力] | [量化目标] | [测量方法] | -| [集成需求] | [通过/失败] | [测试场景] | -| [性能基准] | [阈值] | [负载测试] | - -## Scope — In / Out -- **In scope**: [具体功能、集成、工作流] -- **Out of scope**: [明确不测试的内容及原因] - -## Timeline -- Day 1-2: 环境配置 -- Day 3-7: 核心用例实施 -- Day 8: 中期检查点 -- Day 9-12: 完善和边界测试 -- Day 13-14: 最终汇报和决策会议 - -## Decision Gate -[最终汇报后，买家基于成功标准做出 GO / NO-GO 决策] -``` - -## Success Metrics -- POC 转化率：80%+ 的 POC 进入商业谈判 -- 时间到技术决策：中位数 18 天 - -## Connections -- [[DemoEngineering]] — Demo Engineering 是 POC 执行的前置铺垫 -- [[SalesEngineer]] — POC Scoping 是 Sales Engineer 的核心能力之一 -- [[FIA-Framework]] — 竞争定位在 POC 阶段尤为关键 - -## Contradictions -- 与免费试用的混淆：传统"试用"思维认为越长越好，但 POC Scoping 主张 2-3 周是最佳窗口 diff --git a/wiki/concepts/PRD生成工作流.md b/wiki/concepts/PRD生成工作流.md deleted file mode 100644 index 9d83da08..00000000 --- a/wiki/concepts/PRD生成工作流.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: "PRD生成工作流" -type: concept -tags: [产品经理, AI协作, 文档自动化] -sources: [不会gemini的产品经理真的要被淘汰了-附保姆级prd生成指南] -last_updated: 2025-12-18 ---- - -## Aliases -- AI辅助PRD生成 -- 大模型写PRD -- 产品需求文档生成 - -## 定义 - -**PRD生成工作流**是作者提出的一套利用大模型（Gemini/Claude等）辅助生成产品需求文档的三步骤方法论，核心是"人负责想，大模型负责写"。 - -## 三步工作流 - -### 第一步：FeatureList构思需求 - -**目标**：在写PRD之前，用层级式功能表梳理产品框架 - -**方法**： -- 提供FeatureList模板给大模型 -- 用自然语言描述产品需求框架（只说"做什么"，不说"怎么做"） -- 回答大模型追问的关键业务问题 -- 迭代修正直到得到满意的FeatureList - -**产出**：结构化的功能需求列表 - -### 第二步：Mermaid画逻辑图 - -**目标**：用可视化图表辅助理解复杂业务逻辑 - -**常用图表类型**： -| 图表类型 | 用途 | 适用场景 | -|----------|------|----------| -| ER图 | 描述数据结构 | 数据库表设计、字段关联 | -| 时序图 | 描述工作流 | 业务流程、多角色交互 | -| 甘特图 | 描述时间计划 | 项目排期、里程碑 | -| 泳道图 | 描述跨角色流程 | 复杂业务流程分工 | - -**工具**：大模型生成Mermaid代码 → 飞书文档插入「文本画图」组件 → 实时预览图表 - -**技巧**：遇到名词理解不一致时，给大模型提供一段能正确生成期望效果的Mermaid代码示例，它会快速学会 - -### 第三步：分页面逐一描述生成PRD - -**核心原则**：一个页面一个页面地口述需求 - -**方法**： -1. 提供PRD写作指南 + 简单PRD示例作为模板 -2. 描述每个页面的功能需求（不包含边界情况等细节） -3. 大模型负责补全边界场景定义、通用规则描述 -4. 对后台需求，可同时生成HTML代码作为可交互原型 -5. 直接指出大模型的问题，严厉调教（它一教就会，不会再犯） - -**PRD → HTML迭代**：把旧HTML扔给大模型，描述修改内容，自动生成新版HTML和差量PRD - -## 效率提升 - -- 原本1-2天的文档工作 → 大模型10分钟完成 -- 工作中大部分文本类工作可被大模型胜任 -- HTML原型可直接用于演示，无需设计师 - -## 未来展望 - -> "用图文传递信息一定是有损的。智驾都端到端了，需求实现不能端到端吗？" - -作者认为，未来可能不再需要PRD文档，产品经理与agent疯狂对话获取结果，直接交付给下游研发。 - -## Connections -- [[FeatureList]] ← 前置步骤 ← [[PRD生成工作流]] -- [[Mermaid]] ← 工具依赖 ← [[PRD生成工作流]] -- [[不会gemini的产品经理真的要淘汰]] ← 来源 ← [[PRD生成工作流]] -- [[AI时代产品经理能力重构]] ← 上位概念 ← [[PRD生成工作流]] diff --git a/wiki/concepts/PUID-PGID.md b/wiki/concepts/PUID-PGID.md deleted file mode 100644 index cfb88b55..00000000 --- a/wiki/concepts/PUID-PGID.md +++ /dev/null @@ -1,43 +0,0 @@ -# PUID/PGID - -## Type -- Concept - -## Definition -PUID（Process User ID）和 PGID（Process Group ID）是 LinuxServer.io Docker 镜像专用的环境变量，用于将容器内进程以宿主机指定用户/组的身份运行，从根本上解决 Docker 容器创建文件的权限归属问题。 - -## Mechanism - -### 核心原理 -``` -宿主机：用户 shenwei (UID=1000, GID=1000) - ↓ 设置 PUID=1000, PGID=1000 -容器内：Transmission 进程以 UID=1000, GID=1000 运行 - ↓ 结果 -容器创建的文件 → 归属 shenwei:shenwei → 宿主机可直接读写 -``` - -### 获取宿主机 UID/GID -```bash -id shenwei -# 输出：uid=1000(shenwei) gid=1000(shenwei) groups=1000(shenwei),... -``` - -### Docker Compose 配置示例 -```yaml -environment: - - PUID=1000 # 对应宿主机用户 ID - - PGID=1000 # 对应宿主机组 ID -``` - -## Key Claims -- PUID/PGID 是 LinuxServer.io 镜像的标准化用户配置，与非 root 用户运行（USER 环境变量）不同 -- 不设置 PUID/PGID 时，容器进程以 root（UID=0）运行，创建的文件归属 root:root，导致宿主机用户无法直接管理 -- PUID/PGID 解决了"容器内 root vs 宿主机普通用户"的跨环境文件权限冲突 -- 与 `user: "1000:1000"` Docker Compose 顶级键效果类似，但 PUID/PGID 由 LinuxServer.io 镜像内部脚本处理 - -## Relationship to [[LinuxServer.io]] -PUID/PGID 是 LinuxServer.io 所有镜像的标准化配置环境变量，属于其官方推荐的最佳实践。 - -## Sources -- [[用docker安装transmission]] diff --git a/wiki/concepts/Pacing-Architecture.md b/wiki/concepts/Pacing-Architecture.md deleted file mode 100644 index 3c4a1f41..00000000 --- a/wiki/concepts/Pacing-Architecture.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Pacing Architecture" -type: concept -tags: [] -last_updated: 2026-04-26 ---- - -## Definition - -节奏架构（Pacing Architecture）是通过空间节奏控制玩家情感体验的设计方法——将张力曲线映射到物理空间中，让玩家在不同区域之间经历紧张、释放、探索、战斗的情感起伏。 - -## Pacing Arc Template -``` -Tension → Release → Escalation → Climax → Resolution -``` -每个关卡必须包含完整的情感弧线。 - -## Implementation Methods - -### Through Space -- 通过房间大小（宏大空间 = 释放，狭窄走廊 = 紧张） -- 通过敌人密度（高密度 = 高张力） -- 通过视觉开放度（开阔视野 = 安全，低天花板 = 压迫） -- 通过光照强度（明亮 = 安全，昏暗 = 危险） - -### Pacing Chart -| 时间 | 活动类型 | 张力等级 | 备注 | -|------|---------|---------|------| -| 0:00 | 探索 | 低 | 环境故事引入 | -| 1:30 | 小规模战斗 | 中 | 教授机制 X | -| 3:00 | 探索 | 低 | 奖励 + 世界观构建 | -| 4:30 | 大规模战斗 | 高 | 在压力下应用机制 X | -| 6:00 | 解决 | 低 | 喘息空间 + 出口 | - -## Related Concepts -- [[Flow And Readability]]：Pacing 是 Flow 的情感维度 -- [[Blockout Discipline]]：节奏验证通过灰盒 playtest 完成 -- [[Encounter Design]]：战斗遭遇的密度和规模决定节奏高潮 - -## Sources -- [[Level Designer Agent Personality]] diff --git a/wiki/concepts/Pacing-Chart.md b/wiki/concepts/Pacing-Chart.md deleted file mode 100644 index 566db1e9..00000000 --- a/wiki/concepts/Pacing-Chart.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Pacing Chart" -type: concept -tags: ["game-design", "level-design", "player-experience", "tension-management"] -sources: ["level-designer.md"] -last_updated: 2026-05-07 ---- - -## Definition - -Pacing Chart（节奏图表）是游戏关卡设计中的时间-张力可视化工具，通过将关卡时间轴分解为活动类型和张力级别，直观展示玩家在关卡中的情感曲线。核心理念：**通过空间节奏引导玩家情感——紧张、释放、探索、战斗交替出现，避免单一情绪持续过久导致疲劳**。 - -## Core Components - -### Time Axis -关卡时间轴，单位为关卡内部时间（如 `0:00`、`1:30`、`3:00`）或百分比进度。 - -### Activity Type -活动类型分类： -- **Exploration**（探索）—— 低压力空间发现，节奏偏缓 -- **Combat**（战斗）—— 高强度对抗，分 small/medium/large 三档 -- **Traversal**（穿越）—— 移动与平台跳跃，中等压力 -- **Story**（叙事）—— 过场或环境叙事时刻 -- **Reward**（奖励）—— 获得道具或能力，给予正向反馈 -- **Resolution**（收束）—— 阶段或关卡结束的松弛区间 - -### Tension Level -张力等级：Low → Medium → High → Peak → Release - -## Pacing Arc Template - -典型关卡的节奏弧线： - -``` -时间 | 活动类型 | 张力等级 | 笔记 ---------|-------------|-----------|-------------------------- -0:00 | Exploration | Low | 环境故事引入 -1:30 | Combat(sm) | Medium | 教学机制X -3:00 | Exploration | Low | 奖励+世界观建立 -4:30 | Combat(lg) | High | 在压力下应用机制X -6:00 | Resolution | Low | 呼吸空间+出口 -``` - -## Design Principles - -1. **张力-释放交替**：每次高张力时刻后必须有释放期，否则玩家疲劳 -2. **新机制教学嵌入低张力区**：玩家首次接触机制时，应在低压力探索区而非战斗区 -3. **奖励节奏匹配挑战节奏**：大型战斗后应紧跟奖励区，形成正反馈闭环 -4. **高潮点唯一性**：每个关卡应有且仅有一个真正的 Peak，避免多峰导致重点模糊 - -## Connections - -- [[Level Designer]] 使用 Pacing Chart 作为核心交付物 -- [[Grey Box Blockout]] 阶段即需验证 Pacing Chart 的可执行性 -- [[Encounter Design]] 的战斗规模直接影响 Pacing Chart 的张力峰值 -- [[Game Designer]] 定义宏观游戏节奏，Pacing Chart 在关卡层面落地执行 - -## Related Concepts - -- [[Environmental Storytelling]]（环境叙事）：影响 Exploration 时段的情感密度 -- [[Navigation Affordance]]（导航可达性）：Exploration 区域的迷路时间计入节奏 diff --git a/wiki/concepts/PagedAttention.md b/wiki/concepts/PagedAttention.md deleted file mode 100644 index 79d4b7a5..00000000 --- a/wiki/concepts/PagedAttention.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "PagedAttention" -type: concept -tags: [paged-attention, vllm, inference, optimization] -aliases: [PagedAttention, 分页注意力] -last_updated: 2025-12-20 ---- - -## Definition -PagedAttention，vLLM 的核心注意力机制创新，将 [[KV Cache]] 切分为固定大小的块（block），并用页表式映射管理，类似操作系统的虚拟内存调度方式。 - -## Key Facts -- 传统方式：为每条序列分配一大块连续内存，导致碎片化和 OOM（显存不足） -- PagedAttention 解决方案：将 KV Cache 切分为固定大小块，用页表管理，灵活调度 -- 优势：避免碎片化、支持动态并发、支持 KV 块复用（多分支/重复前缀场景） -- 显著减少预填充（Prefill）时间 - -## Connections -- [[vLLM]] ← 使用 ← [[PagedAttention]] -- [[KV Cache]] ← 优化管理 ← [[PagedAttention]] -- [[Continuous Batching]] ← 协同 ← [[PagedAttention]] - -## Sources -- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]] diff --git a/wiki/concepts/Pain-Point-Mining.md b/wiki/concepts/Pain-Point-Mining.md deleted file mode 100644 index c7cc58b1..00000000 --- a/wiki/concepts/Pain-Point-Mining.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Pain Point Mining" -type: concept -tags: [market-research, agentic-ai, product-discovery] -sources: [market-research-product-factory] -last_updated: 2026-04-22 ---- - -## Definition - -Pain Point Mining（痛点挖掘）是通过系统化方式从真实用户讨论中识别未被满足的需求、抱怨和功能请求的过程，区别于传统调查问卷或访谈——它直接采集未经加工的用户原生表达。 - -## Core Mechanism - -- **数据来源**：Reddit 社区帖子、X/Twitter 用户推文、论坛讨论、产品评论区 -- **时间窗口**：聚焦近期（如最近30天）讨论以获取时效性洞察 -- **分析方法**：频率统计（高频问题 → 高优先级）、情感分析（强烈负面情绪 → 强需求）、竞品对比（现有方案缺失 → 机会点） -- **输出格式**：痛点排名 + 具体投诉引用 + 潜在解决方案方向 - -## Relationship to Other Concepts - -- **[[Pain Point Mining]]** → 输入 → **[[Agent-Driven Market Research]]** → 支撑 → **[[Startup MVP Pipeline]]** -- **[[Pain Point Mining]]** ← 工具依赖 ← **[[Last 30 Days Method]]** - -## Sources - -- [[market-research-product-factory]] diff --git a/wiki/concepts/Paper-Abstract-Batch-Fetching.md b/wiki/concepts/Paper-Abstract-Batch-Fetching.md deleted file mode 100644 index 598e8b5b..00000000 --- a/wiki/concepts/Paper-Abstract-Batch-Fetching.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Paper Abstract Batch Fetching" -type: concept -tags: [] -sources: [arxiv-paper-reader] -last_updated: 2026-04-17 ---- - -## Concept Definition -**论文摘要批量获取（Paper Abstract Batch Fetching）** 是指在一次操作中同时从多个 arXiv 论文获取摘要，并生成结构化对比表格以支持快速筛选和优先级排序的工作模式。 - -## How It Works -1. 输入：多个 arXiv ID 列表（如 `["2301.00001", "2301.04088", "2302.07789"]`） -2. 调用：批量 `arxiv_abstract` 工具并行/串行获取摘要 -3. 输出：结构化表格（ID | 标题 | 作者 | 摘要摘要 | 相关性评分） -4. 用户筛选：确认阅读优先级后触发全文获取 - -## Use Cases -- [[arXiv-Paper-Reader]] 的核心工作流之一——快速 triage 阅读列表 -- 研究选题初期对多条候选论文进行对比评估 - -## Comparison with Related -- [[Semantic-Memory-Search]] 侧重对已有内容的检索；本概念侧重对新内容的发现和筛选 -- 与 [[Agent-Driven Market Research]] 同属批量情报收集，但本概念聚焦学术论文 diff --git a/wiki/concepts/Parallel-Agent-Execution.md b/wiki/concepts/Parallel-Agent-Execution.md deleted file mode 100644 index 42a43067..00000000 --- a/wiki/concepts/Parallel-Agent-Execution.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Parallel Agent Execution" -type: concept -tags: [OpenClaw, Agent, Architecture, Performance] -sources: [multi-agent-team] -last_updated: 2026-04-23 ---- - -## Definition - -**Parallel Agent Execution** 是多 Agent 系统中，多个 Agent 同时处理相互独立的任务，通过并行计算提升整体效率的架构模式。 - -## 核心洞察 - -> "Parallel execution: Multiple agents can work on independent tasks simultaneously" - -并行执行的价值： -- **效率倍增**：多个任务同时处理，总时间大幅减少 -- **资源优化**：不同 Agent 使用各自擅长的模型 -- **独立扩展**：根据任务量动态调整 Agent 数量 - -## 并行 vs 串行 - -| 模式 | 描述 | 时间复杂度 | 适用场景 | -|------|------|------------|----------| -| **串行执行** | Agent A → Agent B → Agent C | O(n×t) | 有依赖关系的任务链 | -| **并行执行** | Agent A ∥ Agent B ∥ Agent C | O(max(t₁,t₂,t₃)) | 独立任务 | - -## 并行执行的典型场景 - -1. **多领域研究** - - Josh 分析市场数据 - - Marketing 追踪竞品动态 - - Dev 检查 CI/CD 健康状态 - - 三者同时进行，无需等待 - -2. **内容创作** - - 同时生成多个内容变体 - - 不同 Agent 用不同风格/角度 - -3. **监控与响应** - - Marketing 持续监控社媒 - - Dev 持续监控代码质量 - - Milo 持续追踪 OKR - -## 与 Chained Agents 的对比 - -| 维度 | Parallel Execution | Chained Agents | -|------|-------------------|----------------| -| **任务关系** | 独立 | 串行依赖 | -| **时间效率** | 高（同时） | 中（等待） | -| **适用场景** | 多领域研究、监控 | 内容生产、审批流 | -| **协调复杂度** | 低 | 中 | - -## Related Concepts - -- [[Agent Specialization]] — 专业化 Agent 是并行执行的基础 -- [[Chained Agents]] — 链式 Agent（串行依赖场景） -- [[Multi-Agent Coordination]] — 多 Agent 协调机制 -- [[Scheduled Task Flywheel]] — 定时任务常利用并行执行 - diff --git a/wiki/concepts/Parallel-Agent-Work.md b/wiki/concepts/Parallel-Agent-Work.md deleted file mode 100644 index 6df72a7e..00000000 --- a/wiki/concepts/Parallel-Agent-Work.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Parallel Agent Work" -type: concept -sources: [workflow-startup-mvp] -last_updated: 2026-04-25 ---- - -## Definition -Parallel Agent Work（并行 Agent 工作）指多个独立 Agent 在同一阶段同时激活，各自处理不相互依赖的任务，从而压缩项目时间线。 - -## Details -- **应用场景**：Week 1 中，Sprint Prioritizer 和 UX Researcher 可并行激活 -- **条件**：两个 Agent 的任务无相互依赖，可独立产出 -- **收益**：将 2 个串行步骤合并为 1 个时间单位，节省约 50% 时间 - -## Aliases -- Parallel Agent Work -- 并行 Agent 工作 - -## Related Patterns -- [[Sequential Handoff]] -- [[Context Passing]] - -## Sources -- [[workflow-startup-mvp]] diff --git a/wiki/concepts/Parallel-Build-Tracks.md b/wiki/concepts/Parallel-Build-Tracks.md deleted file mode 100644 index 774531ed..00000000 --- a/wiki/concepts/Parallel-Build-Tracks.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Parallel Build Tracks" -type: concept -tags: [] -sources: [] -last_updated: 2026-05-01 ---- - -## Definition - -NEXUS-Full 部署模式下，四条功能独立但协同运作的并行开发轨道。每条轨道管理不同的关注面（产品开发、质量运营、增长营销、品牌体验），由不同的 Agent 群组驱动，在整个 Phase 3 期间同时运行。 - -## Tracks - -| Track | Focus | Key Agents | Continuous Activities | -|-------|-------|-----------|----------------------| -| **Track A** | Core Product | Agents Orchestrator, Frontend Developer, Backend Architect, AI Engineer, Evidence Collector | Dev↔QA 循环，2 周 Sprint | -| **Track B** | Growth & Marketing | Project Shepherd, Growth Hacker, Content Creator, Social Media Strategist, App Store Optimizer | 增长飞轮、发布内容、市场活动 | -| **Track C** | Quality & Operations | Agents Orchestrator, Evidence Collector, API Tester, Performance Benchmarker, Workflow Optimizer, Experiment Tracker | 持续质量验证、流程改进、A/B 测试 | -| **Track D** | Brand & Experience | Brand Guardian, UI Designer, Visual Storyteller, Whimsy Injector | 品牌一致性审计、视觉抛光、微交互设计 | - -## Usage - -仅在 NEXUS-Full 部署时激活。四条轨道共享同一 Sprint 节奏（与 Track A 的 2 周 Sprint 对齐），但 Track B/C/D 按里程碑而非每日迭代运行。 - -## Connections - -- [[Dev-QA-Loop]] ← driven_by ← Track A（核心驱动机制） -- [[Agents-Orchestrator]] ← manages ← Track A（Orchestrator 主导 Track A） -- [[Quality-Gate]] ← end_of ← Phase 3（所有四条轨道的输出汇聚到质量门） - -## Aliases -- Parallel Development Tracks -- NEXUS Build Tracks diff --git a/wiki/concepts/Parallel-Kickoff.md b/wiki/concepts/Parallel-Kickoff.md deleted file mode 100644 index 5600ed6e..00000000 --- a/wiki/concepts/Parallel-Kickoff.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Parallel Kickoff" -type: concept -tags: [multi-agent, workflow-pattern, parallelization] -last_updated: 2026-04-25 ---- - -## Definition - -多个独立 Agent 任务在同一时间并行启动，彼此之间没有数据依赖，无需等待对方完成即可开始执行。 - -## Core Principle - -只有当两个工作流**产出互相独立**时，才适合并行启动。如果一个任务的输出是另一个的输入，则必须串行。 - -## Usage in The Agency - -- [[workflow-landing-page]]：Content Creator 与 UI Designer 在上午 9:00 同时启动，两者输出（文案 + 设计稿）互不依赖 -- [[workflow-startup-mvp]]：Backend Architect、Frontend Developer、Growth Hacker 在 Week 2 并行启动 -- [[scenario-marketing-campaign]]：文案、视觉、增长策略并行输出 - -## Implementation - -``` -Agent A ──┐ - ├──► [合并点] -Agent B ──┘ -``` - -并行启动的条件： -1. 两者输出没有依赖关系 -2. 两者不写入同一个共享状态（除非有锁机制） -3. 执行时间相近（避免一个等待另一个过长） - -## Aliases -- Parallel Activation -- Concurrent Kickoff -- Independent Parallel Execution diff --git a/wiki/concepts/Parallel-Workstream.md b/wiki/concepts/Parallel-Workstream.md deleted file mode 100644 index 21d18304..00000000 --- a/wiki/concepts/Parallel-Workstream.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Parallel Workstream" -type: concept -tags: [multi-agent, orchestration, concurrency, nexus] -sources: [executive-brief, quickstart, nexus-spatial-discovery] -last_updated: 2026-05-01 -aliases: - - Simultaneous Tracks - - Parallel Execution - - Multi-Track Pipeline ---- - -## Definition - -并行工作流（Parallel Workstream）—— NEXUS 多 Agent 编排框架的核心加速机制，在同一时间段内同时激活多个专业 Agent 工作轨道（Track），通过并发执行压缩项目时间线。 - -## Quantified Impact - -- **时间线压缩**：40-60% —— 与顺序激活 Agent 相比，并行工作流可将典型 16 周项目压缩至 4-8 周 -- **轨道数量**：4 条标准轨道 —— Core Product / Growth / Quality / Brand -- **并发加速比**：非线性的 —— 并行度增加时，加速效果递减（Amdahl 定律） - -## NEXUS 4 条标准轨道 - -| 轨道 | 主导 Agent | 职责 | -|------|-----------|------| -| Core Product | Backend Architect + Frontend Developer | 核心产品功能实现 | -| Growth | Growth Hacker | 用户增长与市场策略 | -| Quality | Testing Reality Checker + QA Agents | 质量验证与缺陷修复 | -| Brand | Brand Guardian | 品牌身份与视觉系统 | - -## Coordination Mechanism - -并行工作流需要以下协调机制防止冲突： -- **Merge Point**：并行轨道在预定节点汇合（如 Core Product + Brand → UI Implementation） -- **Shared Context**：通过 Agents-Orchestrator 或 MCP Memory Server 维护跨轨道共享上下文 -- **Quality Gate 同步**：所有轨道必须在进入下一阶段前通过质量门控 - -## Related Concepts - -- [[Agent Handoff]]：并行轨道间的交接需要结构化协议，防止上下文丢失 -- [[Quality Gate]]：并行工作流结束后必须通过统一质量门控 -- [[Agents-Orchestrator]]：并行工作流的执行控制器，负责轨道调度和同步 -- [[Memory-Based-Handoff]]：MCP Memory Server 支持并行 Agent 的上下文连续性 diff --git a/wiki/concepts/Partial-Dependence-Plots.md b/wiki/concepts/Partial-Dependence-Plots.md deleted file mode 100644 index 46db9b9b..00000000 --- a/wiki/concepts/Partial-Dependence-Plots.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: "Partial Dependence Plots" -type: concept -tags: [model-interpretability, feature-analysis, model-visualization] -sources: - - specialized-model-qa -last_updated: 2026-05-29 ---- - -## Definition - -偏依赖图（Partial Dependence Plots，PDP）展示一个或两个特征与模型预测之间的边际关系——在控制其他特征后，该特征取不同值时模型输出的平均预测变化。核心假设：特征之间相对独立（独立PDP），否则需要 ICE 曲线（Individual Conditional Expectation）补充。 - -## Core Types - -### 1D PDP（单特征） -- 固定其他特征不动，在目标特征的取值范围内计算模型平均预测 -- 可视化：x 轴为特征值，y 轴为偏依赖值（边际预测效应） -- 用于：验证特征方向是否符合业务预期（单调递增/递减/U形） - -### 2D PDP（特征交互） -- 两个特征同时变化，展示交互效应对预测的联合影响 -- 用于：检测模型学习到的非预期特征交互（如 X₁ × X₂ 的非线性组合） - -### ICE Curves（Individual Conditional Expectation） -- 每条线代表一个样本的偏依赖曲线（而非平均值） -- 解决 PDP 掩盖个体异质性的问题 -- 与 PDP 结合：PDP 叠加 ICE 曲线，同时展示平均趋势和个体差异 - -## Usage - -```python -from sklearn.inspection import PartialDependenceDisplay - -# 1D PDP for single feature -fig, ax = plt.subplots(figsize=(8, 5)) -PartialDependenceDisplay.from_estimator( - model, X, [feature_name], - grid_resolution=50, ax=ax -) -ax.set_title(f"Partial Dependence - {feature_name}") -fig.savefig(f"pdp_{feature_name}.png", dpi=150) - -# 2D PDP for feature interaction -fig, ax = plt.subplots(figsize=(8, 6)) -PartialDependenceDisplay.from_estimator( - model, X, [(feat_a, feat_b)], ax=ax -) -fig.savefig(f"pdp_interact_{feat_a}_x_{feat_b}.png", dpi=150) -``` - -## Model QA 中的应用 - -Model QA Specialist 使用 PDP 进行以下审计： -1. **方向性验证**：检查 PDP 曲线方向是否符合业务领域知识（如"收入↑ → 违约概率↓"） -2. **非单调性检测**：识别模型在某些区间学习到的反直觉非单调关系 -3. **交互效应识别**：2D PDP 检测 top correlated feature pairs 的交互效应 -4. **跨时间稳定性**：对比 Train vs OOT 的 PDP 曲线，识别特征关系的时间漂移 -5. **SHAP 交叉验证**：PDP 验证边际方向，SHAP 验证精确归因，两者互补 - -## Relationship - -- **依赖** [[SHAP]]：SHAP 提供精确特征归因，PDP 提供趋势可视化；PDP 曲线形状与 SHAP beeswarm 的分布吻合 -- **依赖** [[Population-Stability-Index]]：PSI 捕捉特征分布漂移，PDP 捕捉特征效应的变化，两者共同判断模型是否需要重训 -- **支撑** [[Calibration-Testing]]：PDP 揭示的非线性关系可能是校准问题的根源 -- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的特征分析核心工具 - -## Key Limitations - -- **强交互效应**：当特征高度相关时，PDP 可能产生误导性结论（忽略其他特征的条件分布） -- **异质性掩盖**：个体 ICE 曲线与平均 PDP 的差异反映异质性，忽略可能遗漏关键子群体 -- **分类变量**：需预先分箱，箱的划分方式影响结果解释 -- **高维特征**：超过 2 个特征的交互需用 SHAP interaction values 或 ALE plots diff --git a/wiki/concepts/Partition-Updates.md b/wiki/concepts/Partition-Updates.md deleted file mode 100644 index a2e59852..00000000 --- a/wiki/concepts/Partition-Updates.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: "Partition Updates" -type: concept -tags: - - Operating System - - Updates - - Reliability - - A/B Testing -sources: - - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w -last_updated: 2026-04-24 ---- - -# Partition Updates（分区镜像更新） - -分区镜像更新是一种操作系统原子更新策略，通过 A/B 双分区设计，在线下载新版本镜像到非活动分区，重启后切换激活，确保更新过程的原子性和系统一致性。 - -## 核心设计 - -``` -┌─────────────────────────────────────────────┐ -│ 磁盘布局 │ -│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ -│ │ 分区 A │ │ 分区 B │ │ Data Vol │ │ -│ │ (活动) │ │ (备用) │ │ (数据卷) │ │ -│ │ OS v1.0 │ │ OS v1.1 │ │ 容器镜像 │ │ -│ │ 正在运行 │ │ 空闲 │ │ 持久数据 │ │ -│ └──────────┘ └──────────┘ └──────────┘ │ -└─────────────────────────────────────────────┘ -``` - -**更新流程：** -1. 下载新版本镜像到备用分区（分区 B） -2. 验证镜像完整性（哈希校验 + 签名验证） -3. 更新引导配置，指向新分区 -4. 重启系统 -5. 固件/引导加载程序从新分区启动 -6. 新分区变为活动分区，旧分区变为备用分区 - -## 优势 - -- **原子性**：更新要么完全成功，要么系统回退到原状态，不存在"半更新"状态 -- **回滚能力**：如果新版本启动失败，可手动或自动回滚到旧分区 -- **零停机更新**：无需停止正在运行的工作负载即可下载和准备新版本 -- **一致性保证**：切换前已完成新镜像验证，确保启动后的系统状态可预测 -- **适用于关键系统**：电信、金融、工业控制系统等不能容忍更新失败的业务 - -## 与传统包管理更新的对比 - -| 维度 | 包管理更新（apt/yum） | 分区镜像更新（A/B） | -|------|---------------------|-------------------| -| 原子性 | 非原子（可能中断于中途） | 原子（全部成功或全部失败） | -| 回滚 | 依赖包管理器功能，通常复杂 | 简单（切换回旧分区即可） | -| 根文件系统一致性 | 难以保证 | 完整镜像替换，一致性保证 | -| 适用场景 | 通用 Linux 服务器 | 容器宿主、嵌入式系统 | -| 存储开销 | 无额外开销 | 需要双倍存储空间 | - -## 在 Bottlerocket 中的实现 - -Bottlerocket OS 采用分区镜像更新机制： -- 根分区分为 A、B 两组，每组包含 `root_a`/`root_b` 逻辑分区 -- Data Volume（数据卷）独立于根分区，存储容器镜像和应用数据，更新不受影响 -- Data Volume 支持快照预填充（snapshot pre-population），可在构建时就注入容器镜像，加快首次启动 -- 通过 Bottlerocket API 查看当前活动分区版本和待激活版本 - -## 相关技术 - -- [[OSTree]]：基于 Git 的操作系统更新系统，类似的原子升级理念 -- [[Immutable-Root-Filesystem]]：分区更新的最终目标——确保根文件系统一致性 -- [[dm-verity]]：与分区更新配合，验证新分区的完整性 diff --git a/wiki/concepts/Passive-Learning.md b/wiki/concepts/Passive-Learning.md deleted file mode 100644 index 73528984..00000000 --- a/wiki/concepts/Passive-Learning.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Passive Learning" -type: concept -tags: [学习方法, 知识管理, AI应用] -sources: [7-ways-i-use-notebooklm-to-make-my-life-easier] -last_updated: 2026-04-23 ---- - -## Definition -一种将零碎时间转化为学习时间的认知策略——在驾驶、运动、家务、通勤等手脑分离的场景中，通过音频内容（播客、有声书、AI 生成的对话）被动接收信息，无需主动阅读或专注屏幕。 - -## Core Characteristics -- **场景适应性**：适合手脑无法专注的被动场景 -- **内容载体**：以音频为主（播客、语音摘要、AI 对话） -- **注意力要求**：低——作为背景内容接收，无需主动操作 -- **知识密度**：可高可低，取决于内容来源 - -## Typical Scenarios -| 场景 | 活动类型 | 适配内容 | -|------|----------|----------| -| 驾驶 | 通勤 | 新闻、行业动态、技术概览 | -| 运动/健身 | 体能活动 | 深度播客、教育内容 | -| 家务清洁 | 体力劳动 | 书籍摘要、技能教程 | -| 通勤 | 公共交通 | 专业领域深度内容 | - -## Implementation via AI Tools -- **[[NotebookLM]] Audio Overviews**：将任意文档（PDF、文章、视频字幕）转换为双 AI 主持的对话播客，支持 Deep Dive / Brief / Critique / Debate 等风格定制 -- **[[Podcastfy]]**：开源播客生成工具，整合 100+ LLM 和多种 TTS 引擎，支持多语言 -- **[[Daily YouTube Digest]]**：将 YouTube 视频转录并生成音频摘要 - -## Related Concepts -- [[Second Brain]]：被动学习的内容来源——积累文档，通过 AI 生成播客 -- [[Personal Knowledge Base (RAG)]]：被动学习内容的生产端 -- [[Source-Grounding]]：AI 生成学习内容的准确性保证机制 -- [[播客生成]]：技术实现手段 - -## Key Insight -> "This audio format is perfect for passive learning because you can consume complex information during times that would otherwise be downtime." — NotebookLM 使用经验文章 - -传统观念认为"学习需要专注时间"，但被动学习通过重新定义"注意力分配"，将原本浪费的碎片时间（驾驶、运动）转化为认知输入，显著扩大了个人每日有效学习容量。 diff --git a/wiki/concepts/Patient-Privacy-PIPL.md b/wiki/concepts/Patient-Privacy-PIPL.md deleted file mode 100644 index e21a9c57..00000000 --- a/wiki/concepts/Patient-Privacy-PIPL.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Patient Privacy PIPL（患者隐私合规）" -type: concept -tags: [healthcare, compliance, privacy, data, china] -sources: [healthcare-marketing-compliance] -last_updated: 2026-04-25 ---- - -## Definition -患者隐私 PIPL 合规是指医疗健康企业在收集、存储、使用、传输患者个人健康信息时，遵守《个人信息保护法》（PIPL）、《数据安全法》、《网络安全法》等数据安全法规的合规义务。 - -## Core Legal Framework -- **《个人信息保护法》(PIPL)**：将个人医疗健康信息认定为"敏感个人信息"，须获得单独授权方可处理 -- **《数据安全法》**：对医疗健康数据进行分类分级管理 -- **《网络安全法》**：医疗机构信息系统的等级保护要求 -- **《人类遗传资源管理条例》**：基因检测/遗传信息的收集、存储和跨境传输限制 - -## Sensitive Personal Information Classification -根据《个人信息保护法》第28条，医疗健康信息属于敏感个人信息，处理须满足： -- 须告知个人处理敏感个人信息的必要性及对个人权益的影响 -- **须取得个人的单独同意**（不得与一般授权合并） -- 须进行个人信息保护影响评估（PIPL Impact Assessment） - -## Key Compliance Requirements - -### 营销场景 -- 不得在未获授权情况下使用患者就诊信息、诊断结果、检验报告用于营销 -- 患者案例推广须取得书面知情同意并充分脱敏 - -### 数据安全 -- 患者数据管理须加密存储 -- 分级访问控制 -- 定期安全审计 -- 涉及跨境数据传输须通过数据出境安全评估 - -### 违规处罚 -> "患者健康数据属于《个人信息保护法》认定的'敏感个人信息'——违规最高罚款5000万元或上年度营收5%。" — PIPL 第66条 - -## Related Concepts -- [[Healthcare-Marketing-Compliance]]：患者隐私合规是医疗营销合规的重要组成部分 -- [[Compliance-Risk-Matrix]]：违规处理患者敏感信息属 Critical Risk -- [[Evidence-Based-Merge-Proposal]]（跨概念关联）：医疗数据的脱敏处理与身份识别技术相关 diff --git a/wiki/concepts/Pattern-Key.md b/wiki/concepts/Pattern-Key.md deleted file mode 100644 index 01453439..00000000 --- a/wiki/concepts/Pattern-Key.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Pattern-Key" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-17 ---- - -## 定义 -经验记录（Learning）中的分类键字段，用于跨时间识别同一类问题是否重复出现。格式：`领域.子领域.具体问题`（如 `cron.telegram-delivery`）。 - -## 使用方式 -记录到 LEARNINGS.md 的 Metadata 中： -```markdown -### Metadata -- Pattern-Key: cron.telegram-delivery -``` - -## 核心信号 -**Pattern-Key 重复本身就是一个信号——第一次记了，第二次就该解决了。** - -## 实际案例 -| Pattern-Key | 出现次数 | 含义 | 处理策略 | -|------------|---------|------|---------| -| `cron.daily-self-review` | 9次 | 每日复盘活跃领域 | 持续积累，每次深化 | -| `cron.telegram-delivery` | 2次 | Telegram通知配置 | 第二次解决后不再出现 | -| `cron.naming-convention` | 1次 | 任务命名规范 | 一次性错误，无需跟进 | - -## 区分原则 -- 同一 Pattern-Key 多次出现 → 系统性问题，需要根本性解决 -- 只出现一次 → 偶发性错误，记录即可 - -## 相关 Concept -- [[Self-Improving-Skill]]：Pattern-Key 的承载结构 -- [[Recurrence-Count]]：配合 Pattern-Key 判断问题严重程度 -- [[每日复盘机制]]：检查 Pattern-Key 重复的执行机制 - -## Aliases -- pattern key -- 模式键 diff --git a/wiki/concepts/Pay-as-you-go.md b/wiki/concepts/Pay-as-you-go.md deleted file mode 100644 index 9fe99d16..00000000 --- a/wiki/concepts/Pay-as-you-go.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Pay-as-you-go" -type: concept -tags: [cloud-computing, billing, economics] -date: 2025-03-02 ---- - -# Pay-as-you-go - -**Pay-as-you-go**（按使用量付费）是云计算的核心经济模型，用户仅为实际使用的资源付费，无需长期承诺或前期投入。 - -## Definition - -按需计费模式，允许用户根据实际资源消耗（计算、存储、网络）进行付费，无需预留容量或签订长期合同。 - -## Key Characteristics - -- **无前期成本**：无需购买硬件或签订长期合同 -- **弹性计费**：资源使用量决定费用，粒度可到秒/分钟 -- **按需扩缩**：流量高峰时扩容，低谷时缩减 -- **成本可见性**：实时监控和成本分摊 - -## Cost Optimization Strategies - -| Strategy | Description | Savings | -|----------|-------------|---------| -| **Reserved Instances/Spot** | 预留或抢占式实例 | 30-70% vs On-demand | -| **Auto Scaling** | 根据负载自动调整容量 | 避免过度配置 | -| **Serverless** | 按函数执行计费 | 仅在函数运行时计费 | -| **Savings Plans** | 承诺使用量换取折扣 | 20-40% 折扣 | - -## Cloud Myths Context - -Pay-as-you-go 是反驳"云太贵"误解的核心证据： -- **传统采购**：CapEx 模式，前期大量投入，利用率低时浪费 -- **云按需付费**：OpEx 模式，按需使用，成本与业务对齐 -- 消除本地硬件采购、维护和升级的隐性成本 - -## Challenges - -- **Egress 费用**：数据流出云端时的高额流量费 -- **意外计费**：缺乏监控导致超预期费用 -- **长期成本**：稳定负载下预留实例的复杂性 -- **复杂性**：多种计费模式的优化需要专业知识 - -## Related Concepts - -- [[Cost-Optimization]] — 云成本优化 -- [[cloud-computing]] — 云计算 -- [[Scalability]] — 可扩展性 -- [[FinOps]] — 云财务管理 - -## Sources - -- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]] diff --git a/wiki/concepts/Peer-Verification.md b/wiki/concepts/Peer-Verification.md deleted file mode 100644 index b6477f06..00000000 --- a/wiki/concepts/Peer-Verification.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "Peer-Verification" -type: concept -tags: [verification, authentication, protocol] -sources: [agentic-identity-trust.md] -last_updated: 2026-04-25 ---- - -## Definition - -Peer-Verification（对等验证）是一种 Agent 间在接受委托工作前互相验证身份和授权的安全协议。在 Agent 接受来自其他 Agent 的工作请求前，必须完成五项独立验证——全部通过才接受工作。 - -## Verification Checks - -```python -checks = { - "identity_valid": # 1. 密码学身份证明是否有效 - "credential_current": # 2. 凭证是否在有效期内 - "scope_sufficient": # 3. 授权范围是否覆盖请求的操作 - "trust_above_threshold": # 4. 信任评分是否 ≥ 0.5 - "delegation_chain_valid": # 5. 委托链是否完整（如涉及委托） -} -# 全部通过才接受工作（Fail-Closed） -``` - -## Protocol Flow - -``` -Agent A Agent B - │ │ - │──── request_work ─────────>│ - │ │ - │<--- identity_proof -------│ (Agent B 提供公钥 + 签名) - │<--- credential -----------│ (Agent B 提供凭证 + 过期时间) - │<--- delegation_chain -----│ (如为委托工作) - │ │ - │ 验证身份 → 验证凭证 → 验证作用域 → 验证信任分 → 验证委托链 - │ │ - │<--- verification_result --│ - │ │ - if all_passed: - Agent A 接受 Agent B 的工作 - else: - Agent A 拒绝 Agent B 的工作 -``` - -## Performance Requirement - -- **P99 延迟 < 50ms**：验证过程不得成为系统性能瓶颈 - -## Relationships -- [[Zero-Trust]]：Peer-Verification 是 Zero-Trust 在 Agent 间交互中的实现 -- [[Trust-Scoring]]：Trust-Scoring 提供 Peer-Verification 的决策依据 -- [[Delegation-Chain]]：当 Agent 间存在委托关系时，Peer-Verification 必须验证 Delegation-Chain -- [[Fail-Closed]]：所有检查项均采用 Fail-Closed 策略 - -## Sources -- [[agentic-identity-trust.md]] diff --git a/wiki/concepts/Penetration-Testing.md b/wiki/concepts/Penetration-Testing.md deleted file mode 100644 index 28e8ca31..00000000 --- a/wiki/concepts/Penetration-Testing.md +++ /dev/null @@ -1,81 +0,0 @@ -# Penetration Testing - -## Definition -Penetration testing (pen testing) is an authorized simulated cyberattack on a computer system, performed to evaluate the security of the system. - -## Aliases -- Pen Testing -- Ethical Hacking -- Security Testing - -## Concept -渗透测试是授权的模拟网络攻击，用于评估系统的安全性。 - -## Types - -### By Scope -- **Black Box**：测试人员不了解目标内部结构 -- **White Box**：测试人员完全了解系统 -- **Grey Box**：部分了解系统信息 - -### By Target -- Network Penetration Testing -- Web Application Penetration Testing -- Mobile Application Testing -- Social Engineering -- Physical Security Testing - -## Methodology - -### PTES (Penetration Testing Execution Standard) -1. Pre-Engagement Interactions -2. Intelligence Gathering -3. Threat Modeling -4. Vulnerability Analysis -5. Exploitation -6. Post-Exploitation -7. Reporting - -### OWASP Testing Guide -- 信息收集 -- 配置和部署管理测试 -- 身份管理测试 -- 认证测试 -- 授权测试 -- 会话管理测试 -- 输入验证测试 -- 错误处理测试 -- 密码学测试 -- 业务逻辑测试 -- 客户端测试 - -## Tools -- Metasploit — 渗透测试框架 -- Burp Suite — Web 应用测试 -- Nmap — 网络扫描 -- Wireshark — 网络协议分析 -- SQLmap — SQL 注入测试 -- Kali Linux — 渗透测试操作系统 - -## Integration with DevSecOps - -### Continuous Pen Testing -- 定期执行 -- 自动化工具集成 -- 关键时间点测试 - -### Red Team Operations -- 模拟真实攻击 -- 全面评估防御能力 -- 团队对抗演练 - -## Related Concepts -- [[DevSecOps]] — 渗透测试是安全评估的重要组成 -- [[Bug-Bounty]] — 持续外部安全测试 -- [[Vulnerability-Scanning]] — 自动化漏洞发现 -- [[DAST]] — 动态应用安全测试 -- [[Threat-Modeling]] — 威胁建模 -- [[Incident-Response]] — 事件响应 - -## Sources -- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Performance-Budget.md b/wiki/concepts/Performance-Budget.md deleted file mode 100644 index d9b45f88..00000000 --- a/wiki/concepts/Performance-Budget.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: "Performance Budget" -type: concept -tags: [game-dev, performance, optimization, rendering] -sources: [technical-artist] -last_updated: 2026-04-26 ---- - -# Performance Budget - -## Definition -Performance Budget（性能预算）是游戏在目标平台上运行时对 GPU/CPU 资源消耗的硬性上限定义。是技术美术最核心的执行原则——所有艺术决策必须在预算约束内进行。 - -## Budget Categories - -### Frame Time Budget（帧时间预算） -| 平台 | 总帧时间预算 | -|------|------------| -| Mobile | 16.67ms（60 FPS）| -| PC | 16.67ms（60 FPS）| -| Console | 11.11ms（90 FPS）| - -### GPU Sub-Budgets -| 系统 | Mobile | PC | -|------|--------|-----| -| 渲染 | 4–8ms | 8–12ms | -| VFX | 4ms | 8ms | -| 后处理 | 1ms | 2ms | -| 预留余量 | 10% | 10% | - -### VFX Particle Budget -| 平台 | 最大同时粒子数 | 最大 Overdraw 层数 | -|------|-------------|----------------| -| Mobile | 500 | 3 | -| PC | 2,000 | 6 | - -### Draw Call Budget -| 平台 | 建议上限 | -|------|---------| -| Mobile | 100–200 | -| PC | 500–1,000 | - -## Budget Enforcement Rules - -1. **预定义原则**：每种资产类型的预算必须在生产前定义，艺术家在开始制作前知晓限制，而非交付后才发现超标 -2. **平台特定**：必须为每个目标平台单独定义预算（Mobile/PC/Console） -3. **自动化验证**：LOD Chain Validation Script 在导入时自动拦截超标资产 -4. **定期分析**：GPU Profile 在每个主要内容里程碑后运行，识别 Top-5 渲染成本并优先解决 - -## Budget Communication Style - -Technical Artist 的标准语言范式： -- "This effect costs **2ms on mobile** — we have **4ms total for VFX**. Approved with caveats." -- "Give me the budget sheet **before you model** — I'll tell you exactly what you can afford." -- "The texture blowout is a mipmap bias issue — here's the corrected import setting." - -## Related Concepts -- [[LOD-Pipeline]]：LOD 是实现性能预算的核心技术手段 -- [[VFX]]：VFX 系统受粒子数和 Overdraw 预算严格约束 -- [[AssetPipeline]]：资产标准是性能预算的前置保障 -- [[RenderingPipeline]]：渲染管线的每个 Pass 都消耗帧时间预算 - -## Connections -- [[TechnicalArtist]] ← enforces ← Performance Budget -- [[VFX]] ← constrained by ← Performance Budget -- [[LOD-Pipeline]] ← achieves ← Performance Budget -- [[AssetPipeline]] ← enables ← Performance Budget diff --git a/wiki/concepts/Performance-Contracts.md b/wiki/concepts/Performance-Contracts.md deleted file mode 100644 index 202361ab..00000000 --- a/wiki/concepts/Performance-Contracts.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Performance Contracts" -type: concept -tags: [performance, latency, engineering] -sources: [lsp-index-engineer] -last_updated: 2026-04-25 ---- - -## Definition - -性能契约（Performance Contracts）是 LSP/Index Engineer 定义的量化性能约束体系，为 graphd 系统的每个关键操作设定明确的延迟、吞吐量和资源上限，作为所有实现决策的北极星指标。 - -## Contract Table - -| Operation | Constraint | Notes | -|-----------|-----------|-------| -| `/graph` endpoint | <100ms | 数据集 <10k 节点 | -| `/nav/:symId` (cached) | <20ms | 缓存命中 | -| `/nav/:symId` (uncached) | <60ms | 缓存未命中 | -| WebSocket event stream | <50ms latency | 端到端推送延迟 | -| Memory usage | <500MB | 典型项目 | -| Go-to-definition | <150ms | 任意符号 | -| Hover documentation | <60ms | 悬停响应 | -| Graph update propagation | <500ms | 文件保存后 | -| Symbol scale | 100k+ symbols | 无性能降级 | - -## Measurement Strategy - -- **基准测试**：每次提交后运行基准测试套件 -- **Profiling**：识别性能瓶颈并优先处理 -- **P99 监控**：关注 P99 而非平均值，确保长尾性能 - -## Optimization Techniques - -- 内存映射文件（Memory-mapped files） -- 零拷贝网络传输（io_uring） -- 无锁数据结构（Lock-free data structures） -- SIMD 优化图操作 -- 批量 LSP 请求以减少往返开销 -- 主动缓存 + 精确失效 diff --git a/wiki/concepts/PerformanceMax.md b/wiki/concepts/PerformanceMax.md deleted file mode 100644 index bd08f57c..00000000 --- a/wiki/concepts/PerformanceMax.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Performance Max" -type: concept -tags: ["ppc", "google-ads", "ai", "automation", "paid-media"] -sources: ["paid-media-ppc-strategist"] -last_updated: 2026-05-01 ---- - -## Definition - -Performance Max（PMax）是 Google Ads 提供的 AI 驱动的全渠道广告系列类型，通过 Google 的机器学习算法，自动在 Search、Display、YouTube、Gmail、Shopping 所有 Google 广告库存中实时优化广告投放，以最大化预设的转化目标。区别于传统按广告类型创建系列，PMax 将所有渠道整合为一个统一优化的单元。 - -## How It Works - -1. **Asset Group**：上传标题、描述、图片、视频、logo 等创意素材 -2. **Audience Signals**：提供种子受众（Customer Match、In-Market、Affinity）加速学习 -3. **Automatic Optimization**：算法实时决定：哪个渠道、哪个受众、在什么时机展示什么创意 -4. **Cross-Channel Learning**：Search、Display、YouTube 等渠道数据互通，提升整体效果 - -## Asset Group Design - -PMax 的核心输入单元是 Asset Group： -- **Required Assets**：至少 1 个图片（或 logo）+ 1 个标题 + 1 个描述 -- **Recommended Assets**：2-3 个图片 + 5+ 标题 + 5+ 描述 + 1+ 视频 -- **Ad Strength**：Google 评分，目标是 "Good" 或 "Excellent" - -### Asset Group Strategy -- 按产品线/服务线拆分 Asset Group，避免混杂 -- A/B 测试不同 Asset Group 组合 -- 定期补充新创意，避免疲劳 - -## Audience Signals - -PMax 的"教练"输入，辅助算法更快学习： -- **Customer Match Lists**：高价值客户数据 -- **In-Market Audiences**：考虑中的购买者 -- **Life Events**：人生阶段事件（毕业/搬家/结婚等） -- **Demographics**：年龄/收入/家庭状况 - -## Limitations and Best Practices - -| 限制 | 应对策略 | -|------|---------| -| 关键词控制有限 | 使用 Search Themes 引导 | -| 受众控制有限 | 精准的 Audience Signals | -| 品牌安全依赖算法 | 排除内容排除项设置 | -| 透明度低 | 结合 Search/Shopping 标准系列监测 | - -## Connections -- [[AutomatedBiddingStrategy]]：PMax 内置 Smart Bidding（Max Conversions / tROAS） -- [[AudienceStrategy]]：Audience Signals 是 PMax 的关键输入 -- [[GoogleAds]]：PMax 是 Google Ads 独有的广告系列类型 diff --git a/wiki/concepts/Periodic-Review.md b/wiki/concepts/Periodic-Review.md deleted file mode 100644 index ee05dd38..00000000 --- a/wiki/concepts/Periodic-Review.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Periodic Review" -type: concept -tags: [productivity, knowledge-management, habit] -sources: [obsidian-高效指南-我常用的插件与实用技巧] -last_updated: 2025-03-01 ---- - -## Definition -定期回顾和整理笔记内容的工作流——检查哪些笔记需要更新、整合或归档，保持笔记系统的健康度和可用性，防止笔记随时间积累变成"笔记黑洞"。 - -## Review Levels -- **每日回顾**：Daily Note 结束时的简单总结 -- **每周回顾**：检查本周新增内容，更新索引页 -- **每月回顾**：评估本月主题趋势，整合碎片笔记 -- **每季/年回顾**：重大主题梳理，知识体系重构 - -## Core Mechanisms -- 查询未访问笔记：Dataview 等工具按创建时间筛选长期未访问的笔记 -- 标签系统：按标签筛选需要关注的笔记 -- 归档策略：将过时内容移至归档区 -- 合并整理：将碎片内容整合为结构化笔记 - -## Why It Matters -- **防止熵增**：笔记系统自然趋向混乱，需主动维护 -- **知识更新**：定期检查内容是否过时 -- **发现空白**：发现尚未覆盖的主题，指导新内容获取 -- **强化记忆**：回顾本身就是一种间隔重复 - -## Connections -- [[Note Database Queries]]：Dataview 查询是定期复盘的核心工具 -- [[Zettelkasten]]：Zettelkasten 方法论强调定期回顾和链接 -- [[Daily Journaling]]：每日回顾是最小粒度的复盘 -- [[Personal Knowledge Base]]：定期复盘是 PKB 维护的关键环节 - -## Sources -- [[obsidian-高效指南-我常用的插件与实用技巧]] diff --git a/wiki/concepts/PersistentWiki.md b/wiki/concepts/PersistentWiki.md deleted file mode 100644 index 9ae82b22..00000000 --- a/wiki/concepts/PersistentWiki.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "PersistentWiki" -type: concept -tags: [knowledge-management, wiki, llm, persistent] -sources: [llm-wiki] -last_updated: 2026-05-02 ---- - -## Overview -持久化维基（Persistent Wiki）是 [[LLM Wiki]] 模式的核心产物——一个结构化的、相互链接的 Markdown 文件集合，介于用户与原始数据源之间。知识编译一次后持续保持最新，无需在每次查询时重新推导。 - -## Core Characteristics -- **持久化**：知识以结构化页面的形式存储，不随对话结束而消失 -- **可积累**：每添加一个新来源，Wiki 就变得更丰富，而非从头推导 -- **相互链接**：页面之间通过 [[wikilinks]] 链接，形成知识网络 -- **主动维护**：LLM 负责更新摘要、添加标签、标记矛盾，无需人类做"记账式"工作 - -## Three-Layer Architecture -持久化维基建立在 [[LLMWikiArchitecture]] 之上： -1. **Raw Sources**：原始文档（不可变） -2. **Wiki**：LLM 生成的知识层（持久化维基本身） -3. **Schema**：配置文件（CLAUDE.md / AGENTS.md） - -## Operation Patterns -- **[[IngestWorkflow]]**：导入工作流——LLM 读取源文件，创建/更新 Wiki 页面 -- **[[QueryWorkflow]]**：查询工作流——用户提问，LLM 搜索 Wiki 并综合答案 -- **[[LintWorkflow]]**：检查工作流——定期健康检查 Wiki - -## Relationships -- [[PersistentWiki]] ← implements ← [[LLMWikiArchitecture]] -- [[PersistentWiki]] ← competes_with ← [[RAG]]（传统 RAG 每次查询从零推导，持久化维基一次编译持续复用） -- [[PersistentWiki]] ← inspired_by ← [[Memex]]（Vannevar Bush 1945） -- [[LLM Wiki]] ← uses ← [[PersistentWiki]]（[[LLM Wiki]] 是完整模式，[[PersistentWiki]] 是其核心产物） diff --git a/wiki/concepts/Personal-CRM.md b/wiki/concepts/Personal-CRM.md deleted file mode 100644 index 72517e91..00000000 --- a/wiki/concepts/Personal-CRM.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: "Personal CRM" -type: concept -tags: [] -last_updated: 2026-04-27 ---- - -## Aliases -- Personal Customer Relationship Management -- 联系人关系管理 - -## Definition -基于 AI Agent 的个人联系人管理系统，通过自动发现而非手动录入维护人际关系记忆，核心价值在于零摩擦积累和主动会议准备。 - -## Key Attributes - -| 属性 | 描述 | -|------|------| -| 数据来源 | Gmail、Google Calendar（通过 gog CLI） | -| 存储结构 | SQLite（联系人表：姓名、邮箱、首见时间、末联系时间、互动次数、备注） | -| 查询接口 | Telegram Topic（personal-crm）自然语言查询 | -| 触发机制 | Cron Job（每日联系人扫描 + 每日会议简报） | -| AI 框架 | OpenClaw | - -## Workflow - -1. **每日 6AM Cron Job**：扫描 Gmail + Calendar 过去 24 小时 -2. **提取新联系人**：自动识别邮件/日历中的外部参与者 -3. **更新数据库**：新增或更新已有联系人的互动记录 -4. **每日 7AM Cron Job**：查询当天日历，收集每位外部参会者背景 -5. **推送简报**：Telegram 投递会前准备（含上次交流内容、待跟进事项） -6. **按需查询**：Telegram personal-crm topic 接收自然语言查询 - -## 与相关概念的区分 - -| 概念 | 差异点 | -|------|--------| -| [[Second Brain]] | 非结构化任意内容捕获，Personal CRM 侧重结构化联系人关系 | -| [[Local CRM Framework]] | DenchClaw 侧重本地 Web UI + 数据导入；Personal CRM 侧重自动发现 | -| [[Email Triage]] | 侧重邮件分拣；Personal CRM 侧重联系人关系追踪 | -| [[Meeting Prep Briefing]] | Personal CRM 的子功能之一 | - -## 实现方案 - -- **[[personal-crm]]**（本文档来源）：OpenClaw + gog CLI + SQLite + Telegram Topic -- **[[local-crm-framework]]**（DenchClaw）：OpenClaw + DuckDB + Web UI + 浏览器自动化 - -## Sources -- [[personal-crm]] -- [[local-crm-framework]] -- [[multi-channel-assistant]] diff --git a/wiki/concepts/Personalization.md b/wiki/concepts/Personalization.md deleted file mode 100644 index 2988030e..00000000 --- a/wiki/concepts/Personalization.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Personalization" -type: concept -tags: [ai, personalization, interaction-design] -last_updated: 2026-04-23 ---- - -# Personalization - -## Aliases -- AI 个性化 -- 个性化配置 -- Personalized AI - -## Definition -通过系统级指令（如自定义指令、用户画像）塑造 AI 的响应风格、交互方式和输出格式，使 AI 适配特定用户的背景、偏好和使用场景。 - -## Key Dimensions -- **响应风格**：有条理/简洁/详细/技术性 -- **交互方式**：被动响应 vs 主动预判 -- **输出格式**：URL 位置、语言偏好、引用格式 -- **用户假设**：专家 vs 新手视角 -- **错误处理**：主动反馈 vs 静默忽略 - -## Patterns in This Wiki -- [[openai-chatgpt-个性化定义]]：ChatGPT 自定义指令的完整配置案例 -- [[Agent Personality Design]]：多 Agent 系统中的个性化设计 -- [[custom-morning-brief]]：个性化晨间简报 -- [[Adaptive Tone]]：根据用户表现动态调整语气 - -## Relationship to TCPCA -Personalization 是 [[designing-for-agentic-ai]] 中 TCPCA 五原则之一——AI 应适应个人用户需求和偏好，基于历史行为预测未来需求。 - -## Sources -- [[openai-chatgpt-个性化定义]] -- [[designing-for-agentic-ai]] -- [[multi-agent-team]] diff --git a/wiki/concepts/PersuasionArchitecture.md b/wiki/concepts/PersuasionArchitecture.md deleted file mode 100644 index e00b61a0..00000000 --- a/wiki/concepts/PersuasionArchitecture.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Persuasion Architecture" -type: concept -tags: ["proposal", "persuasion", "behavioral", "psychology", "sales"] -last_updated: 2026-04-20 ---- - -## Definition -说服架构是将行为心理学原理系统化地嵌入提案设计，以最大化评估者说服效果的框架。 - -## Four Pillars - -### 1. Primacy and Recency Effect（首因与近因效应） -将最强论据放在章节开头和结尾。评估者对开头和结尾记忆最深。 - -### 2. Cognitive Load Management（认知负荷管理） -- 渐进式披露（progressive disclosure）：逐步揭示信息，避免信息过载 -- 清晰的视觉层级：用标题、间距、颜色引导注意力流向 -- 减少决策摩擦：让评估者轻松找到关键信息 - -### 3. Social Proof Sequencing（社会认同排序） -按相关性影响度排序案例研究和推荐证明。最相关的证明放在最前面建立即时可信度。 - -### 4. Loss Aversion Framing（损失厌恶框架） -在风险部分使用损失厌恶框架增加紧迫感，但不制造恐慌： -- "不采取行动的成本" 比 "采取行动的价值" 更有说服力 -- 量化不作为的代价，而非仅强调行动的好处 -- 强调买方已有的投入如何因不行动而浪费 - -## Application -说服架构应用于： -- 赢标主题的植入位置和频率 -- 执行摘要的结构 -- 案例研究的选择和排序 -- 风险/挑战部分的框架 diff --git a/wiki/concepts/Photography-Terminology.md b/wiki/concepts/Photography-Terminology.md deleted file mode 100644 index 4d709797..00000000 --- a/wiki/concepts/Photography-Terminology.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: "Photography Terminology" -type: concept -tags: [photography, prompt-engineering, technical] -last_updated: 2026-05-15 ---- - -## Definition - -专业摄影术语体系——用于在 AI 图像生成提示词中精确描述光线、构图、相机参数和后处理效果，确保 AI 模型准确理解和渲染预期的摄影效果。 - -## Core Categories - -### 光线类（Lighting） -| 术语 | 含义 | 提示词示例 | -|------|------|-----------| -| Rembrandt Lighting | 45°侧光+三角形阴影 | "Rembrandt lighting setup from camera left" | -| Butterfly Lighting | 鼻子下方蝴蝶形阴影 | "butterfly lighting, subtle shadow under nose" | -| Split Lighting | 半明半暗分割光 | "dramatic split lighting, 50/50 face division" | -| Rim Light / Hair Light | 轮廓光/发丝光 | "strong rim light separating from background" | -| Softbox | 漫射箱光源 | "large softbox overhead creating soft gradient" | -| Volumetric Lighting | 体积光/光束 | "volumetric golden hour sunbeams through fog" | -| Chiaroscuro | 明暗对比 | "chiaroscuro dramatic shadow composition" | -| Bokeh | 焦外虚化 | "creamy f/1.4 bokeh background" | - -### 相机与焦距类 -| 术语 | 含义 | 提示词示例 | -|------|------|-----------| -| Shallow Depth of Field | 浅景深 | "shallow depth of field, f/1.8, subject sharp" | -| Deep Focus | 深景深 | "deep focus, f/11, foreground to background sharp" | -| Wide Angle Distortion | 广角畸变 | "wide angle 16mm lens, slight perspective exaggeration" | -| Telephoto Compression | 长焦压缩 | "telephoto 200mm, compressed background" | -| Eye Level | 平视视角 | "shot at eye level, 85mm portrait lens" | -| Bird's Eye View | 俯视 | "bird's eye view, overhead camera" | -| Worm's Eye View | 仰视 | "worm's eye angle, dramatic upward perspective" | - -### 摄影类型类 -| 术语 | 含义 | 提示词示例 | -|------|------|-----------| -| High Key | 高调摄影 | "high key lighting, bright and airy aesthetic" | -| Low Key | 低调摄影 | "low key, dramatic shadow, moody atmosphere" | -| Editorial | 编辑摄影 | "editorial fashion photography style" | -| Documentary | 纪实摄影 | "documentary style, authentic and unretouched" | -| Fine Art | 艺术摄影 | "fine art photography, gallery exhibition quality" | - -### 后处理类 -| 术语 | 含义 | 提示词示例 | -|------|------|-----------| -| Color Grading | 色彩调色 | "teal and orange color grade, cinematic" | -| Film Emulation | 胶片模拟 | "Kodak Portra 400 film stock emulation" | -| Grain | 颗粒感 | "subtle film grain, 35mm Ilford HP5" | -| HDR | 高动态范围 | "HDR processing, detailed highlights and shadows" | - -## Photography Reference Photographers - -| 摄影师 | 风格特征 | 提示词引用 | -|--------|---------|-----------| -| Annie Leibovitz | 戏剧性人像、叙事场景 | "Annie Leibovitz inspired editorial portrait" | -| Peter Lindbergh | 自然光黑白、真实质感 | "Peter Lindbergh natural light black and white" | -| Helmut Newton | 高对比、时尚张力 | "Helmut Newton dramatic fashion photography" | -| Irving Penn | 简洁构图、棚拍经典 | "Irving Penn studio minimalist composition" | - -## Core Principle - -> 使用正确的摄影术语，而非口语化描述——"shallow depth of field, f/1.8 bokeh" 而非 "blurry background"。 - -## Connections - -- [[Five-Layer-Prompt-Structure]] 的技术摄影层（Lamp + Technical Photography Layer）的术语来源 -- [[Midjourney]] / [[Stable-Diffusion]] 等 AI 平台对摄影术语的识别和渲染能力 -- [[Prompt-Engineering]] 的技术精确性基础 - -## Aliases - -- 摄影术语体系 -- Professional Photography Language -- Technical Photography Specs diff --git a/wiki/concepts/Pipeline-State-Management.md b/wiki/concepts/Pipeline-State-Management.md deleted file mode 100644 index f2220d6f..00000000 --- a/wiki/concepts/Pipeline-State-Management.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Pipeline-State-Management" -type: concept -tags: [] -sources: [agents-orchestrator] -last_updated: 2026-05-29 ---- - -## Definition -**Pipeline State Management**（流水线状态管理）是 [[AgentsOrchestrator]] 在整个开发流程中追踪和维护项目状态的能力——追踪当前任务、所处阶段、完成状态，在 Agent 间传递上下文信息，处理错误并实现恢复。 - -## Core Responsibilities -- **Track progress**: Maintain state of current task, phase, and completion status -- **Context preservation**: Pass relevant information between agents -- **Error recovery**: Handle agent failures gracefully with retry logic -- **Documentation**: Record decisions and pipeline progression - -## State Tracking Elements -- Current task and phase -- Completion status of each task -- Retry count per task -- Agent handoff context -- Quality gate decisions (PASS/FAIL) - -## Relationship to Other Concepts -- Complementary to [[Agent-Handoff]] — provides the state infrastructure that enables smooth agent transitions -- Enhanced by [[Quality-Gate]] — quality gates update pipeline state -- Referenced in [[AgentsOrchestrator]] Phase 3 Dev-QA Loop - -## Sources -- [[agents-orchestrator]] diff --git a/wiki/concepts/Pipeline.md b/wiki/concepts/Pipeline.md deleted file mode 100644 index b1f07575..00000000 --- a/wiki/concepts/Pipeline.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Pipeline" -type: concept -tags: [Agent, Skill, Design Pattern, ADK] -sources: [google-5个agent-skill设计模式-2026-03-19] -last_updated: 2026-03-19 ---- - -## Overview -Pipeline 是 Google ADK 发布的 5 种 Agent Skill 设计模式之一，通过硬性检查点和明确门控条件强制执行严格的顺序工作流。适用于复杂任务，Agent 无法跳过步骤直接给出未验证的最终结果。 - -## Mechanism -- 指令本身定义了工作流 -- 实现明确的门控条件（如"用户在进入下一步之前确认生成的文档字符串"） -- 用户必须在进入下一步之前确认 -- 每一步都有明确的前置条件 - -## Use Cases -- 文档流水线：解析和清点 → 生成文档字符串 → 组装文档 → 质量检查 -- 复杂业务流程：每步强制验证 -- CI/CD 流程：每阶段 gate check - -## Example Flow -``` -1. 解析和清点 → [Gate: 用户确认] -2. 生成文档字符串 → [Gate: 用户确认] -3. 组装文档 → [Gate: 用户确认] -4. 质量检查 → 完成 -``` - -## Key Insight -> 对于复杂任务，你承受不起跳过步骤或者忽略指令的情况。Pipeline 模式强制执行严格的顺序工作流。 - -## Related Concepts -- [[Reviewer]]：Pipeline 可以在最后包含 Reviewer 步骤 double-check 成果 -- [[Generator]]：Pipeline 的输出可以是 Generator 的输入 -- [[Inversion]]：Pipeline 可以用 Inversion 作为第一步收集信息 - -## Connections -- [[Google5个AgentSkill设计模式]] ← part_of ← [[Pipeline]] -- [[ADK]] ← published_by ← [[Pipeline]] diff --git a/wiki/concepts/PipelineVelocity.md b/wiki/concepts/PipelineVelocity.md deleted file mode 100644 index 66fe29d6..00000000 --- a/wiki/concepts/PipelineVelocity.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Pipeline Velocity" -type: concept -tags: [revenue-operations, pipeline, metrics, forecasting] -last_updated: 2026-04-25 ---- - -## Definition -Pipeline Velocity 是 Revenue Operations 领域最核心的复合指标，衡量收入在 Pipeline 中的流动速度。其公式为： - -**Pipeline Velocity = (Qualified Opportunities × Average Deal Size × Win Rate) / Sales Cycle Length** - -## Four Diagnostic Levers - -| 变量 | 含义 | 关键洞察 | -|------|------|---------| -| Qualified Opportunities | 进入 Pipeline 的合格机会数量 | 按来源、细分和销售人员跟踪；数量下降会在 2-3 个季度后体现在收入上 | -| Average Deal Size | 平均 Deal 规模 | 上升可能表示更好的目标定位或范围蔓延；下降可能表示折扣压力或市场转移 | -| Win Rate | 胜率 | 按阶段/人员/细分/Deal 规模/时间分段；阶段级胜率揭示 Deal 真正死亡的环节 | -| Sales Cycle Length | 销售周期长度 | 按细分跟踪趋势；周期延长通常是竞争压力、买家委员会扩大或资格缺口的第一个信号 | - -## Why It Matters -- 四个变量均为**诊断杠杆**——每个变量都可以独立分析以发现问题 -- Pipeline Velocity 下降往往比 Pipeline 总量下降**早 1-2 个季度**出现预警信号 -- 是 [[PipelineVelocity]] 和 [[DealHealthScoring]] 的基础公式 - -## Connections -- [[DealHealthScoring]] — Deal 健康评分结合 Velocity 信号调整阶段胜率 -- [[QualityAdjustedCoverage]] — 质量调整覆盖度使用 Velocity 数据评估 Deal 质量 -- [[SalesPipelineAnalyst]] — Pipeline Analyst Agent 的核心诊断框架 -- [[SalesAccountStrategist]] — 使用 Pipeline Velocity 评估客户层级健康状况 diff --git a/wiki/concepts/Pivot-Strategy.md b/wiki/concepts/Pivot-Strategy.md deleted file mode 100644 index 36c6cc87..00000000 --- a/wiki/concepts/Pivot-Strategy.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Pivot-Strategy" -type: concept -tags: [] -last_updated: 2026-04-22 ---- - -## Overview -当赛道拥挤度较高（`reality_signal > 30`）时，通过重新定位切入角度实现差异化的策略。通过分析现有竞品的覆盖盲区，找到一个可专注的细分维度，在该维度上构建竞争优势。 - -## Three Pivot Dimensions -当 `reality_signal` 显示赛道拥挤时，可通过以下三个维度实现转向： - -### 1. Language Specialization -语言专一化——只支持特定编程语言的竞品细分。 -- 示例：不做通用的"AI code review tool"，而是"**Rust-only AI code review**"，规避与通用方案（GitHub Copilot、CodeRabbit）的正面竞争 -- 适用场景：某语言社区有特殊需求，通用方案覆盖不足 - -### 2. Framework Specialization -框架专一化——只针对特定框架的审查工具。 -- 示例："**React 组件合规性审查**"而非通用代码审查 -- 适用场景：某框架有独特的 linting/compliance 需求 - -### 3. Industry Specialization -行业专一化——针对特定垂直行业的合规/审查工具。 -- 示例："**金融/医疗代码合规性审查**"（HIPAA、SOX 相关代码检查） -- 适用场景：强监管行业有特殊代码合规要求，通用方案无法满足 - -## Decision Framework -``` -reality_signal > 70? - → STOP + 展示竞品 + 询问用户是否继续/转向/放弃 - → 用户选择 pivot 后，从三个维度中选择最合适的角度 - -reality_signal 30-70? - → 展示竞品 + 提供 pivot_hints - → Agent 主动建议差异化角度 - -reality_signal < 30? - → 赛道空白，直接构建 -``` - -## Relationship to Related Concepts -- [[Competition-Analysis]] ← 识别需要 pivot 的时机 -- [[Reality-Signal]] ← 决策阈值依据 -- [[Pre-Build Validation]] ← 包含 pivot 决策的工作流 -- [[Agent-Build-Gate]] ← pivot 决策通过后的后续动作 - -## Related -- [[Competition-Analysis]] -- [[Reality-Signal]] -- [[Pre-Build Validation]] -- [[Agent-Build-Gate]] -- [[Startup MVP Pipeline]] diff --git a/wiki/concepts/Plan-Mode.md b/wiki/concepts/Plan-Mode.md deleted file mode 100644 index 7575db3d..00000000 --- a/wiki/concepts/Plan-Mode.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Plan Mode" -type: concept -tags: [opencode, ai, workflow, safe-coding] -sources: [如何在ubuntu上安装opencode并配置vibe-kanban] -last_updated: 2026-04-27 ---- - -## Overview - -**Plan Mode** 是 OpenCode 的计划模式，通过 Tab 键切换进入。此模式下 OpenCode 禁用写入能力，只生成实现方案，不直接修改代码文件。 - -## How It Works - -1. 在 OpenCode TUI 中按 **Tab** 键切换到 Plan Mode（屏幕右下角会显示指示器） -2. 描述你想要实现的功能需求 -3. OpenCode 分析项目上下文后生成详细的实现计划 -4. 人对计划提出反馈或补充更多细节 -5. 确认计划后，再次按 **Tab** 键切换回 Build Mode 执行 - -## Why Use Plan Mode - -- **安全可控**：在写入代码前审核 AI 的实现方案 -- **迭代优化**：可多次调整计划直到满意 -- **减少浪费**：避免 AI 因理解偏差导致的返工 -- **上下文参考**：支持拖拽图片、设计稿等作为参考素材 - -## Relationship to Build Mode - -Plan Mode 和 [[Build Mode]] 是互补的双模式工作流： -- Plan Mode = 规划、提案、审核 -- Build Mode = 执行、实施、交付 - -## Related Concepts - -- [[Build Mode]] — 构建模式，执行实际代码修改 -- [[Vibe Coding]] — Plan Mode 是 Vibe Coding 工作流的关键环节 -- [[AGENTS.md]] — 项目上下文定义，帮助 Plan Mode 生成更准确的方案 - -## Aliases -- Plan Mode (OpenCode) -- 计划模式 diff --git a/wiki/concepts/Platform-Specific-Optimization.md b/wiki/concepts/Platform-Specific-Optimization.md deleted file mode 100644 index 46637d1b..00000000 --- a/wiki/concepts/Platform-Specific-Optimization.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "Platform-Specific Optimization" -type: concept -tags: [prompt-engineering, ai-image-generation, platform] -last_updated: 2026-05-15 ---- - -## Definition - -针对不同 AI 图像生成平台（Midjourney、DALL-E、Stable Diffusion、Flux）的特定语法、参数和优化策略，使提示词在各平台上发挥最优效果。 - -## Platform Comparison - -### Midjourney -- **参数语法**：`--ar`（宽高比）、`--v`（版本）、`--style`（风格）、`--chaos`（随机性）、`--no`（负向）、`--iw`（图像权重） -- **多提示词加权**：使用 `::` 语法实现 token 级权重控制（如 `cat::1.5 dog::0.8`） -- **风格引用**：`--style` 参数支持预设风格库 -- **优化要点**：强调氛围和情绪词，依赖参数调控技术细节 - -### DALL-E -- **自然语言优化**：支持完整的自然语言描述，无需特殊语法 -- **风格混合**：通过描述性语言融合不同艺术风格 -- **优化要点**：详细描述场景和情感，利用自然语言的灵活性 - -### Stable Diffusion -- **Token 加权**：使用括号 `(token)` 和数字权重 `[token:0.5]` 控制 token 强度 -- **Embedding 引用**：通过文本反演（Textual Inversion）引用自定义概念 -- **LoRA 集成**：调用特定风格的 LoRA 适配器增强特定效果 -- **优化要点**：精细化 token 权重管理，结合 Embedding 和 LoRA 实现精准控制 - -### Flux -- **详细自然语言**：偏好详细、具体的自然语言描述 -- **写实优先**：对写实摄影风格有天然优势 -- **优化要点**：提供尽可能详细的场景描述，减少抽象暗示 - -## Cross-Platform Best Practice - -1. 核心五层提示词结构在各平台通用 -2. 平台特有参数在提示词末尾添加 -3. 测试不同平台的相同核心描述的输出差异 -4. 建立各平台成功提示词库，持续迭代优化 - -## Connections - -- [[Five-Layer-Prompt-Structure]] 是跨平台的通用框架 -- [[Midjourney]] / [[DALL-E]] / [[Stable-Diffusion]] / [[Flux]] 各自的专属优化 -- [[Prompt-Engineering]] 的平台适配层 - -## Aliases - -- Platform Optimization -- Multi-Platform Prompt Tuning -- 平台适配优化 diff --git a/wiki/concepts/Pod-Security-Context.md b/wiki/concepts/Pod-Security-Context.md deleted file mode 100644 index 25f1af71..00000000 --- a/wiki/concepts/Pod-Security-Context.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "Pod Security Context" -type: concept -tags: [Kubernetes, Security, Container, Pod, RBAC] -last_updated: 2026-04-24 ---- - -## Definition -Pod Security Context（Pod 安全上下文）是 Kubernetes 中定义 Pod 和容器级别安全设置的机制，通过 YAML 配置在 Pod Spec 中声明容器的运行权限和访问控制。 - -## Common Security Context Fields - -### Container-Level Settings -```yaml -securityContext: - readOnlyRootFilesystem: true # 容器根文件系统设为只读 - runAsNonRoot: true # 禁止以 root 用户运行 - runAsUser: 1000 # 指定运行用户 UID - runAsGroup: 1000 # 指定运行用户组 GID - allowPrivilegeEscalation: false # 禁止权限提升 - capabilities: - drop: ["ALL"] # 移除所有 Linux capabilities -``` - -### Pod-Level Settings -```yaml -securityContext: - hostNetwork: false # 不使用宿主机网络 - hostIPC: false # 不使用宿主机 IPC - hostPID: false # 不使用宿主机 PID 命名空间 - automountServiceAccountToken: false # 不自动挂载 ServiceAccount Token -``` - -## Key Concepts from CTP Topic 49 - -### readOnlyRootFilesystem: true -将容器根文件系统设为只读，防止攻击者在容器内创建或修改文件。Demo 演示：设置此标志后，容器内尝试 `touch /tmp/test` 会失败。 - -### automountServiceAccountToken: false -禁用 Kubernetes ServiceAccount Token 的自动挂载，防止容器自动获得对 Kubernetes API 的访问权限。如果容器应用需要访问 API，应显式创建带有精确权限的 ServiceAccount 并通过 RBAC 绑定。 - -### hostNetwork: false / hostPort -避免使用宿主机网络和宿主机端口： -- 防止端口冲突 -- 维护网络隔离 -- 减少容器逃逸攻击面 -- 注意：在受限网络环境（如 Lab Landing Zone）中可能有例外需求（参见 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]） - -## Relationship to Kubernetes RBAC -Pod Security Context 与 [[Kubernetes RBAC]] 配合使用： -- Security Context 控制容器的运行时权限 -- RBAC 控制 ServiceAccount 对 Kubernetes API 的访问权限 -- 两者共同实现最小权限原则 - -## Sources -- [[ctp-topic-49-container-lifecycle-hardening-standards]] diff --git a/wiki/concepts/PodcastPositioning.md b/wiki/concepts/PodcastPositioning.md deleted file mode 100644 index d6cf2501..00000000 --- a/wiki/concepts/PodcastPositioning.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: "Podcast Positioning" -type: concept -tags: [podcast, content-strategy, marketing] -sources: [marketing-podcast-strategist] -last_updated: 2026-04-26 ---- - -# Podcast Positioning（播客定位） - -播客定位是指为播客节目确定清晰的受众、内容方向和差异化策略，是播客运营的基础决策。 - -## 定位四象限 - -| 类型 | 描述 | 适用场景 | -|------|------|---------| -| **垂直知识**（Vertical Knowledge） | 深度垂直领域专业内容 | 建立专业权威，吸引精准受众 | -| **对话访谈**（Interview/Conversation） | 嘉宾驱动的对话内容 | 利用嘉宾影响力扩大受众覆盖 | -| **叙事故事**（Narrative Storytelling） | 纪录片/小说类叙事 | 强情感连接，高完播率潜力 | -| **闲聊日常**（Casual Chat） | 轻松随意的日常对话 | 陪伴感强，粘性高 | - -## 核心要素 - -### 目标听众画像 -- 年龄、职业、兴趣标签 -- 收听场景（通勤/运动/睡前/做家务） -- 内容偏好和付费意愿 - -### 差异化策略 -- 找到独特的"声音人格"（Voice Persona） -- 找到独特的"内容角度"（Content Angle） -- 拒绝模糊的"我们什么都聊"定位 - -### 品牌要素 -- 节目名称：简短、易记、有辨识度 -- 封面设计：缩略图尺寸下仍清晰可辨 -- 节目描述：清晰的内容价值主张 - -## 关键原则 - -> **默认要求**：每个节目必须有清晰的内容价值主张和明确的目标受众。 - -- 清晰的 [[Content Calendar]] 规划（常青内容 + 热点内容 + 系列内容 + 实验内容） -- 避免"万金油"定位——越聚焦越容易建立忠实听众群 -- 内容价值 proposition 必须具体到一句话能说清楚 - -## Connections -- [[Content Calendar]] ← depends_on ← [[Podcast Positioning]]：定位决定内容规划方向 -- [[Completion Rate]] ← measured_by ← [[Podcast Positioning]]：定位清晰度影响听众留存 -- [[Marketing Podcast Strategist]] ← authored_by ← [[Podcast Positioning]] 实践框架 - -## Aliases -- 播客定位 -- Show Positioning -- 节目定位 diff --git a/wiki/concepts/Polanyi-Exchange.md b/wiki/concepts/Polanyi-Exchange.md deleted file mode 100644 index 189c8706..00000000 --- a/wiki/concepts/Polanyi-Exchange.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Polanyi Exchange" -type: concept -tags: ["anthropology", "economy", "exchange", "polanyi", "anthropological-economy"] -last_updated: 2026-04-25 ---- - -## Definition -Polanyi 交换分类——Karl Polanyi 将前工业社会的交换系统分为三种类型：**互惠**（reciprocity）、**再分配**（redistribution）和**市场**（market），三者嵌入不同的社会结构中，非市场经济是常态。 - -## Core Framework -- **互惠（Reciprocity）**：对称性群体之间的双向给予和回报（家庭、友谊、礼物经济） -- **再分配（Redistribution）**：中心集权机构收集资源后统一分配（国家税收/公共服务、部落首领的仓库） -- **市场（Market）**：供给-需求-价格机制调节交换（Polanyi 认为在 20 世纪之前极少见） -- **嵌入性（Embeddedness）**：前工业社会中，经济交换嵌入社会关系、宗教义务和政治结构中 - -## Key Thinkers -- Karl Polanyi（《大转型》作者，经济人类学奠基人） -- [[Marcel-Mauss]]（《礼物》对互惠的早期分析） -- Marshall Sahlins（部落社会的互惠分类） - -## Connections -- [[Anthropologist-Agent]] ← uses_framework ← [[Polanyi-Exchange]] -- [[Gift-Economy]] ← foundational_for ← [[Polanyi-Exchange]] -- [[Cultural-Ecology]] ← shapes ← [[Polanyi-Exchange]] -- [[Functionalism]] ← explains ← [[Polanyi-Exchange]] diff --git a/wiki/concepts/Policy-as-Code.md b/wiki/concepts/Policy-as-Code.md deleted file mode 100644 index b5c4df44..00000000 --- a/wiki/concepts/Policy-as-Code.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: "Policy as Code (PaC)" -type: concept -tags: [security, devops, compliance, automation] -date: 2025-03-01 ---- - -## Definition - -策略即代码（Policy as Code）是将安全、合规和运维策略编写为可执行代码的做法，通过自动化执行和持续验证替代人工审计和手动检查。 - -## Core Concept - -``` -传统模式: PaC模式: -───────── ───────── -人工编写策略 → 文档化 → 人工检查 → 间歇性审计 - ↓ -策略代码化 → 自动执行 → 持续验证 → 实时合规 -``` - -## Benefits - -| 优势 | 描述 | -|------|------| -| **一致性** | 每次执行使用相同规则，消除人为错误 | -| **可版本控制** | 策略变更通过Git跟踪和审查 | -| **自动化** | CI/CD集成，持续验证 | -| **可测试** | 策略可单元测试和集成测试 | -| **审计友好** | 自动生成审计日志 | - -## Implementation Patterns - -### 1. OPA (Open Policy Agent) -```rego -# OPA Rego策略示例 -package kubernetes.admission - -deny[msg] { - input.request.kind.kind == "Pod" - not input.request.object.spec.hostIPC - msg := "HostIPC is not allowed" -} -``` - -### 2. Terraform Sentinel -```hcl -# Terraform策略即代码 -policy "require-tags" { - enforcement_level = "advisory" - validate = func(resource) { - all resource.values.tags != undefined - } -} -``` - -### 3. In ITSM Context - -在[[ITSM]]中，PaC支撑[[Security-and-Compliance]]： - -- **变更合规** — 自动验证变更符合安全策略 -- **配置基线** — 确保配置项符合基线 -- **访问控制** — 自动执行最小权限原则 -- **审计自动化** — 生成合规报告 - -## Related Concepts - -- [[Zero-Trust-Architecture]] — ZTA依赖PaC实现自动化 -- [[Security-and-Compliance]] — PaC的核心应用场景 -- [[Infrastructure-as-Code]] — IaC与PaC的协同 -- [[DevSecOps]] — PaC在DevSecOps中的角色 - -## Sources - -- [[understanding-complete-itsm]] — Policy-as-Code在ITSM中的应用 diff --git a/wiki/concepts/PolyvagalTheory.md b/wiki/concepts/PolyvagalTheory.md deleted file mode 100644 index 2d1fcd09..00000000 --- a/wiki/concepts/PolyvagalTheory.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Polyvagal Theory" -type: concept -tags: [] -sources: [academic-psychologist] -last_updated: 2026-04-25 ---- - -# Polyvagal Theory - -## Aliases -- Polyvagal Theory -- Porges Polyvagal Theory -- Vagal Tone Theory - -## Definition -Porges 迷走神经理论——认为迷走神经（副交感神经系统的一部分）是理解创伤反应的生理基础，提出神经觉知（neuroception）概念：神经系统无意识地评估环境安全性。 - -## Core Concepts - -### Neuroception（神经觉知） -自主神经系统无意识地评估环境威胁/安全，不依赖意识判断。解释了为什么人在客观安全的环境中仍然感到恐惧。 - -### Three-Level Response Hierarchy（三层反应层级） -1. **Ventral Vagal（腹侧迷走）**：社会参与系统——安全状态下，与人连接、沟通、调节情绪 -2. **Sympathetic（交感神经系统）**：动员系统——战斗或逃跑应对威胁 -3. **Dorsal Vagal（背侧迷走）**：关闭系统——极端威胁下的僵硬、冻结、解离（"playing dead"） - -### Co-Regulation（共同调节） -安全状态下的社会参与依赖与他人的共同调节（Co-Regulation），解释了安全依恋关系的生理保护作用。 - -## Application in Character Design -Psychologist Agent 使用此理论为创伤反应提供**生理基础**而非仅仅是心理描述，帮助设计更真实的角色行为： -- 过度警觉 = 交感神经持续激活 -- 解离/冻结 = 背侧迷走接管 -- 逐步恢复安全感 = 从背侧→交感→腹侧迷走的递进恢复 - -## Connection to Wiki -- Source: [[academic-psychologist]] diff --git a/wiki/concepts/Pomodoro-Technique.md b/wiki/concepts/Pomodoro-Technique.md deleted file mode 100644 index 076b6db8..00000000 --- a/wiki/concepts/Pomodoro-Technique.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Pomodoro Technique" -type: concept -tags: [time-management, productivity, focus, task-management] -last_updated: 2026-04-20 ---- - -## Definition -番茄工作法（Pomodoro Technique）是一种时间管理技术，通过将工作拆分为 25 分钟专注时段（"番茄钟"）和短休息交替进行，维持高度专注并防止疲劳。由 Francesco Cirillo 于 1980 年代发明。 - -## Mechanism -1. **时间盒**：固定 25 分钟专注单元，无中断全力工作 -2. **短休息**：5 分钟恢复，起身活动 -3. **长休息**：每 4 个番茄钟后 15-30 分钟休息 -4. **任务记录**：追踪完成所需番茄钟数量 - -## Relationship to Behavioral Nudge Engine -在 [[Behavioral Nudge Engine]] 中，适配 ADHD 用户和认知超载用户时，采用更短的 5 分钟微冲刺模式，而非标准的 25 分钟番茄钟，以进一步降低启动摩擦。 - -## Related Concepts -- [[Cognitive Load Reduction]]：通过时间盒降低决策复杂度 -- [[Momentum Nudge]]：微冲刺与动量维持的结合 - -## Source -- [[Behavioral Nudge Engine]] — 核心应用场景 diff --git a/wiki/concepts/Population-Stability-Index.md b/wiki/concepts/Population-Stability-Index.md deleted file mode 100644 index 5f050c5a..00000000 --- a/wiki/concepts/Population-Stability-Index.md +++ /dev/null @@ -1,104 +0,0 @@ ---- -title: "Population Stability Index" -type: concept -tags: [model-monitoring, feature-drift, model-governance] -sources: - - specialized-model-qa -last_updated: 2026-05-29 ---- - -## Definition - -群体稳定性指数（Population Stability Index，PSI）是衡量两个分布（通常是开发样本 vs 实际样本）之间差异的量化指标，广泛用于监控机器学习模型输入特征和输出评分的分布漂移，是模型生命周期管理的核心监控工具。 - -## Algorithm - -$$\text{PSI} = \sum_{i=1}^{n} (act_i - exp_i) \times \ln\left(\frac{act_i}{exp_i}\right)$$ - -其中： -- $act_i$ = 实际（当前）样本在分箱中的占比 -- $exp_i$ = 期望（基准）样本在分箱中的占比 -- 使用 **Laplace smoothing**（加 1 平滑）避免除零 - -## Interpretation Thresholds - -| PSI Range | 判读 | 建议行动 | -|-----------|------|---------| -| < 0.10 | 🟢 无显著漂移 | 无需操作 | -| 0.10–0.25 | 🟡 中等漂移 | 调查原因，密切监控 | -| ≥ 0.25 | 🔴 显著漂移 | **立即采取行动**，考虑重训 | - -## Implementation - -```python -import numpy as np -import pandas as pd - -def compute_psi(expected: pd.Series, actual: pd.Series, bins: int = 10) -> float: - """ - Compute Population Stability Index between two distributions. - Interpretation: - < 0.10 → No significant shift (green) - 0.10–0.25 → Moderate shift, investigation recommended (amber) - >= 0.25 → Significant shift, action required (red) - """ - breakpoints = np.linspace(0, 100, bins + 1) - expected_pcts = np.percentile(expected.dropna(), breakpoints) - - expected_counts = np.histogram(expected, bins=expected_pcts)[0] - actual_counts = np.histogram(actual, bins=expected_pcts)[0] - - # Laplace smoothing - exp_pct = (expected_counts + 1) / (expected_counts.sum() + bins) - act_pct = (actual_counts + 1) / (actual_counts.sum() + bins) - - psi = np.sum((act_pct - exp_pct) * np.log(act_pct / exp_pct)) - return round(psi, 6) - - -def variable_stability_report( - df: pd.DataFrame, - date_col: str, - variables: list[str], - psi_threshold: float = 0.25, -) -> pd.DataFrame: - """Monthly stability report for model features.""" - periods = sorted(df[date_col].unique()) - baseline = df[df[date_col] == periods[0]] - - results = [] - for var in variables: - for period in periods[1:]: - current = df[df[date_col] == period] - psi = compute_psi(baseline[var], current[var]) - results.append({ - "variable": var, "period": period, "psi": psi, - "flag": "🔴" if psi >= psi_threshold else ("🟡" if psi >= 0.10 else "🟢"), - }) - - return pd.DataFrame(results).pivot_table( - index="variable", columns="period", values="psi" - ).round(4) -``` - -## Model QA 中的应用 - -Model QA Specialist 将 PSI 应用于以下场景： -1. **特征稳定性监控**：每月计算所有特征的 PSI，识别漂移最早的预警信号 -2. **评分分布监控**：模型输出的评分 PSI，检测整体预测分布变化 -3. **分段 PSI**：在子群体上分别计算，识别特定分段的漂移（整体 PSI 掩盖的局部问题） -4. **重训触发器**：将 PSI ≥ 0.25 设为自动重训的硬触发条件 - -## Relationship - -- **被依赖** [[SHAP]]：PSI 识别分布漂移，SHAP 分析漂移后的特征贡献变化 -- **被依赖** [[Discrimination-Metrics]]：PSI 漂移通常先于 AUC/Gini 下降出现，是预警指标 -- **被依赖** [[Calibration-Testing]]：特征分布漂移（PSI）是校准失效的根本原因之一 -- **支撑** [[specialized-model-qa]]（Source）：Model QA Specialist 的监控框架核心指标 - -## Key Insights - -- **方向性陷阱**：PSI 仅反映分布差异大小，不反映变化方向（高→低 或 低→高 均为漂移） -- **阈值依赖**：0.1/0.25 阈值是行业惯例，具体阈值应基于业务风险调整 -- **特征 vs 评分 PSI**：特征 PSI 先于评分 PSI 变化，是更敏感的早期预警 -- **监控频率**：生产模型应至少每月计算一次，关键业务模型建议每周甚至每日 diff --git a/wiki/concepts/Portage-Salarial.md b/wiki/concepts/Portage-Salarial.md deleted file mode 100644 index 5f27d4fe..00000000 --- a/wiki/concepts/Portage-Salarial.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: "Portage Salarial" -type: concept -tags: [] -sources: [specialized-french-consulting-market] -last_updated: 2026-04-25 ---- - -# Portage Salarial - -## Aliases -- Portage Salarial -- Portage -- Portage Company -- Société de Portage - -## Definition - -Portage Salarial（薪资代理）是法国特有的劳动法律框架，允许独立专业人士通过一家"portage 公司"作为中间人与客户签订合同，本质上是一种合法的雇佣代理机制。Portage 公司以雇主身份代为签订合同、收取客户付款、发放工资，同时为自由职业者提供完整的社会保障（失业保险、退休金、健康险）。 - -## How It Works - -``` -Client → [Portage Company] → Freelancer - (employer) (employee) -``` - -1. 自由职业者与客户（ESN 或最终客户）就服务内容达成一致 -2. Portage 公司与客户签订服务合同 -3. 客户向 Portage 公司付款 -4. Portage 公司扣除管理费（约 5-10%）和法定雇主/雇员社保后，将剩余款项作为工资发放给自由职业者 - -## Cost Breakdown - -以 **700 EUR/天 TJM** 为例（每月 18 个工作日 = 12,600 EUR/月）： - -| 费用项 | 比例 | 金额 | -|-------|------|------| -| Portage 公司管理费 | ~10% | -1,260 EUR | -| 雇主端社保（约 45%） | | -5,103 EUR | -| 雇员端社保（约 22%） | | -2,495 EUR | -| **净收入（月）** | | **~3,742 EUR** | -| **有效日均净收入** | | **~208 EUR/天** | - -> 对比 Micro-Entreprise 同等 TJM：净收入 ~9,828 EUR/月，有效日均 ~546 EUR/天 -> **差距：338 EUR/天** = Portage Salarial 为社会保护付出的代价 - -## Key Benefits - -| 权益 | 说明 | -|------|------| -| **失业保险（ARE）** | 失业后可申请法国失业金（需满足缴纳条件） | -| **退休金** | 完整缴纳法国退休金体系（含基础退休金+补充退休金） | -| **健康险（Mutuelle）** | 通常由 Portage 公司提供团体健康险 | -| **病假/产假** | 享有法定病假和产假权益 | -| **法律保护** | 作为"雇员"身份，在合同纠纷中有更好的法律地位 | -| **简化行政** | 无需注册公司、报税、处理复杂账单 | - -## Key Risks - -| 风险 | 说明 | -|------|------| -| **高额社保负担** | 实际到手约 50% TJM，显著低于 Micro-Entreprise 的 70% | -| **商业风险自担** | Portage 不是真正的雇主——自由职业者自揽客户、自定费率 | -| **费率天花板** | 某些 Portage 公司对可转嫁费用有限制 | -| **合同类型限制** | 通常需要真实的"服务关系"而非"从属性雇佣" | - -> "Portage salarial is not employment. It provides social protection but the freelancer bears all commercial risk. Never present it as equivalent to a CDI." - -## Portage vs Alternatives - -| 维度 | Portage Salarial | Micro-Entreprise | SASU/EURL | -|------|----------------|-----------------|-----------| -| 净收入比例 | ~50% TJM | ~70% TJM | ~55-65% TJM | -| 失业保险 | ✅ 有 | ❌ 无 | ❌ 无（EURL 特定条件下有） | -| 退休金 | ✅ 完整缴纳 | ⚠️ 简化缴纳 | ✅ 完整缴纳 | -| 行政复杂度 | 低 | 极低 | 中 | -| 最佳适用 | 需要 ARE 保障的转型期顾问 | 低成本启动/低风险项目 | 高收入稳定期 | - -## Decision Framework - -**选择 Portage Salarial 当：** -- 需要法国失业保险作为安全网 -- 处于从 CDI 向自由职业的转型期 -- 年收入预期较高（> 80,000 EUR）且 ARE 积累价值显著 -- 需要完整的退休金缴纳记录 - -**选择 Micro-Entreprise 当：** -- 风险承受能力高，不需要失业保险 -- 年收入低于法国 Auto-Entrepreneur 免税门槛（77,700 EUR服务业） -- 短期项目或试用期 - -## Related Sources -- [[specialized-french-consulting-market]] -- [[Micro-Entreprise]] diff --git a/wiki/concepts/Portfolio-ROI.md b/wiki/concepts/Portfolio-ROI.md deleted file mode 100644 index 89169c37..00000000 --- a/wiki/concepts/Portfolio-ROI.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Portfolio ROI" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-25 ---- - -## Definition - -Portfolio ROI（组合投资回报率）是衡量组合层面投资效益的核心财务指标，定义为组合整体收益与总投资成本的比率。在 [[Project-Management-Studio-Producer]] 的框架中，Portfolio ROI 是组合管理的北极星指标，设定基准为 **≥ 25%**。 - -## Calculation Framework - -``` -Portfolio ROI = (组合总收益 - 组合总投资成本) / 组合总投资成本 × 100% -``` - -## Portfolio ROI vs. Project ROI - -| Dimension | Project ROI | Portfolio ROI | -|-----------|-------------|--------------| -| Scope | 单个项目 | 组合整体 | -| Time | 项目周期 | 跨项目周期 | -| Metrics | 范围/时间/成本 | 战略价值实现率 | -| Focus | 执行效率 | 资源配置效率 | -| Target | 交付成功 | 商业目标实现 | - -## Key Influencing Factors - -- **Tier 1 项目**：战略优先级项目，高投资高预期回报 -- **Tier 2 项目**：增长型项目，中等投资中等回报 -- **Innovation Pipeline**：实验性项目，低投资学习导向 -- **Risk-Adjusted Returns**：风险调整后的预期回报 - -## Tracking in Strategic Portfolio Management - -在 [[Project-Management-Studio-Producer]] 的四阶段工作流中，Portfolio ROI 追踪属于"Step 4: Performance Management and Strategic Optimization"阶段，通过 Strategic Portfolio Review 模板进行季度复盘。 - -## Aliases -- Return on Portfolio Investment -- Portfolio Performance -- Investment Efficiency diff --git a/wiki/concepts/Post-Processing.md b/wiki/concepts/Post-Processing.md deleted file mode 100644 index 57ad28c6..00000000 --- a/wiki/concepts/Post-Processing.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "Post-Processing" -type: concept -tags: [game-dev, rendering, visual-quality] -sources: [technical-artist] -last_updated: 2026-04-26 ---- - -# Post-Processing - -## Definition -Post-Processing（后处理）是在场景渲染完成后对最终图像应用的一系列屏幕空间效果，用于提升视觉质量和艺术风格表达。典型效果包括 Bloom（泛光）、色差、晕影、颜色分级等。 - -## Core Effects - -### Bloom / Glow -模拟真实世界中光源的溢出光晕效果。常用于霓虹灯、魔法特效、火光等发光物体。实现方式：对高亮度区域进行下采样模糊，与原图叠加。 - -### Chromatic Aberration（色差） -模拟镜头色散产生的边缘色彩分离效果，增加电影感和真实感。 - -### Vignette（晕影） -画面边缘渐暗，引导观众视线到中心。强度可调。 - -### Color Grading（颜色分级） -通过 LUT（Look-Up Table）调整整体色调和对比度。可导出 DaVinci Resolve 或 Photoshop 中的调色方案，导入为 3D LUT 资源。 - -### Temporal Anti-Aliasing (TAA) + Sharpening -TAA 通过历史帧混合减少锯齿，但会导致快速移动物体的鬼影（ghosting）问题。使用锐化（DLSS/XeSS 集成）可恢复 TAA 损失的细节。 - -## Platform-Specific Profiles - -| 效果 | Console | PC | Mobile | -|------|---------|----|--------| -| Bloom | 重度（Film grain + Heavy bloom）| 中度 | 关闭 | -| Chromatic Aberration | 轻度 | 轻度 | 关闭 | -| Color Grading | LUT 完整版 | LUT 简化版 | 关闭 | -| Film Grain | 开启 | 可选 | 关闭 | - -## Modular Stack Design - -模块化后处理栈允许效果独立切换： -- Pass 1: Bloom（可独立开关） -- Pass 2: Chromatic Aberration（可独立开关） -- Pass 3: Vignette（可独立开关） -- Pass 4: Color Grading（可独立开关） - -## Related Concepts -- [[VFX]]：VFX 与后处理栈协同——发光特效依赖 Bloom Pass -- [[Shader]]：后处理基于全屏着色器（Screen-Space Shader） -- [[PerformanceBudget]]：每个 Pass 都消耗帧时间预算，需评估收益/成本比 - -## Connections -- [[TechnicalArtist]] ← designs ← Post-Processing -- [[VFX]] ← enhances via ← Post-Processing -- [[Shader]] ← implements ← Post-Processing diff --git a/wiki/concepts/Practice-Theory.md b/wiki/concepts/Practice-Theory.md deleted file mode 100644 index 5b8f6bad..00000000 --- a/wiki/concepts/Practice-Theory.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Practice Theory" -type: concept -tags: ["anthropology", "sociology", "practice", "habitus", "bourdieu"] -last_updated: 2026-04-25 ---- - -## Definition -实践理论——文化不是静态的符号系统，而是通过**日常实践**不断被再生产和变革的动态过程。行动者在社会结构约束下以惯习（habitus）为中介创造文化，文化同时又塑造未来的社会结构。 - -## Core Framework -- **惯习（Habitus）**：行动者在社会化过程中内化的性情倾向系统——使社会不平等被自然化为"品味"和"个人选择" -- **文化资本（Cultural Capital）**：教育、知识、语言能力、品味等非经济形式的社会优势，可转化为经济和社会资本 -- **场域（Field）**：相对自主的社会空间（艺术、宗教、学术等），具有自身逻辑和竞争规则 - -## Key Thinkers -- [[Pierre-Bourdieu]]（核心提出者） -- Anthony Giddens（structuration theory） -- Sherry Ortner（subaltern counterpoint） - -## Connections -- [[Anthropologist-Agent]] ← uses_framework ← [[Practice-Theory]] -- [[Structuralism]] ← challenges ← [[Practice-Theory]] -- [[Functionalism]] ← critiques_and_extends ← [[Practice-Theory]] diff --git a/wiki/concepts/Pre-Build-Validation.md b/wiki/concepts/Pre-Build-Validation.md deleted file mode 100644 index 61a4b939..00000000 --- a/wiki/concepts/Pre-Build-Validation.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Pre-Build Validation" -type: concept -tags: [] -sources: [pre-build-idea-validator] -last_updated: 2026-04-27 ---- - -## Overview -在代码编写之前进行市场/竞争验证的工作流模式。AI Agent 接收构建指令后，首先调用竞争分析工具（如 [[idea-reality-mcp]] 的 `idea_check()`）评估赛道的真实拥挤度，只有通过门控条件才允许进入实际代码编写阶段。 - -## Mechanism -1. 用户/Agent 提出构建需求（如"build me an AI code review tool"） -2. Agent 调用 `idea_check()` 扫描多平台真实数据 -3. 返回 `reality_signal` 分数（0-100） -4. 根据阈值决策：继续构建 / 暂停讨论 / 建议转向 - -## Decision Thresholds -| reality_signal | 决策 | 行动 | -|---|---|---| -| > 70 | STOP | 展示竞品，询问是否继续/转向/放弃 | -| 30-70 | 展示+建议 | 显示结果和 pivot_hints，建议差异化角度 | -| < 30 | 直接构建 | 提示市场空白，批准开始编写代码 | - -## Why It Matters -防止 AI Agent 犯最昂贵的错误：**在一个已被成熟方案解决的领域投入大量时间**。GitHub 上有 143,000+ AI code review 相关仓库，顶端方案已有 53,000+ stars——Agent 不知道是因为没有人告诉它去查，也没有人告诉它应该查。 - -## Relationship to Related Concepts -- [[Pre-Build Validation]] ← 前置于 [[Startup MVP Pipeline]] -- [[Pain Point Mining]] → [[Pre-Build Validation]] → [[Startup MVP Pipeline]]（完整的产品发现到构建流程） -- [[Reality-Signal]] 是 [[Pre-Build Validation]] 的核心度量指标 -- [[Agent-Build-Gate]] 是 [[Pre-Build Validation]] 的技术实现机制 - -## Aliases -- Pre-Build Gate -- Idea Validation Gate -- Pre-Build Checkpoint - -## Related -- [[idea-reality-mcp]] -- [[Reality-Signal]] -- [[Competition-Analysis]] -- [[Pivot-Strategy]] -- [[Agent-Build-Gate]] -- [[Startup MVP Pipeline]] -- [[Pain Point Mining]] diff --git a/wiki/concepts/Pre-commit-Hooks.md b/wiki/concepts/Pre-commit-Hooks.md deleted file mode 100644 index 41709282..00000000 --- a/wiki/concepts/Pre-commit-Hooks.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Pre-commit Hooks" -type: concept -tags: - - GitOps - - DevOps - - CI/CD - - Automation -last_updated: 2026-05-11 ---- - -# Pre-commit Hooks - -## Definition -在提交代码前运行的脚本工具，通常用于代码格式化、linting、安全扫描等。Renovate Bot 可以自动检测并更新这些钩子插件的版本号。 - -## Core Functions -- 在 `git commit` 前自动执行检查脚本 -- 常用场景：代码格式化（Prettier）、linting（ESLint）、安全扫描（Trivy）、Secrets 检测 -- 版本管理：保持钩子插件版本与最新安全修复同步 -- Renovate 集成：自动为 pre-commit 配置文件（如 `.pre-commit-config.yaml`）中的版本标签创建更新 PR - -## Related Concepts -- [[Renovate-Bot]] — Renovate Bot 可自动更新 pre-commit 钩子插件版本 -- [[Dependency-Management]] — pre-commit 钩子是项目依赖的一部分 -- [[GitOps]] — pre-commit 是 GitOps 工作流中的质量门禁 - -## Related Sources -- [[ctp-topic-15-working-with-renovatebot]] - -## Aliases -- Git Hooks -- Pre-commit Framework -- pre-commit-config.yaml diff --git a/wiki/concepts/PreBuildValidation.md b/wiki/concepts/PreBuildValidation.md deleted file mode 100644 index 9825e7b7..00000000 --- a/wiki/concepts/PreBuildValidation.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "PreBuild Validation" -type: concept -tags: [decision-gate, ai-agent, pre-build, competition-analysis] -sources: [pre-build-idea-validator] -last_updated: 2026-04-27 ---- - -## Definition -在 AI Agent 开始编写代码之前，自动进行市场竞争验证的流程机制。通过 [[idea-reality-mcp]] 扫描多个平台，评估赛道饱和度，以分数形式反馈给 Agent 作为决策依据。 - -## How It Works -1. **触发**：OpenClaw Agent 接收到任何新项目/功能/工具的构建指令 -2. **扫描**：idea_reality_check() 调用 MCP server 并行查询 GitHub + HN + npm + PyPI + Product Hunt -3. **评估**：返回 reality_signal 分数（0-100） -4. **决策门控**： - - 高分（>70）→ Agent STOP → 向用户报告竞品 + 询问决策 - - 中分（30-70）→ 展示 pivot_hints → 建议差异化方向 - - 低分（<30）→ Agent 直接开始构建 -5. **执行**：始终在写任何代码之前先展示分数和竞品信息 - -## Key Design Principle -- **[[Reality Signal]] 作为 Gate**：分数决定是否可以继续，而非人工主动触发 -- **自动化嵌入 Agent Instructions**：Pre-Build Validation 通过 OpenClaw 的 agent instructions 实现，无需每次手动调用 -- **Deep Mode**：重要决策可使用 `depth="deep"` 扫描全部5个数据源（适合黑客松批量验证10个想法） - -## Value -- 防止独立开发者犯最昂贵的错误：**在一个已被解决的问题上花费大量时间** -- 避免 6+ 小时的编码后才发现 GitHub 上已有 143,000+ 同类仓库的尴尬 -- 将"直觉判断"升级为"数据驱动决策" - -## Related Concepts -- [[Reality Signal]]：PreBuild Validation 的核心量化指标 -- [[Autonomous Project Management]]：与 PreBuild Validation 的张力——自主性边界（高竞争时 Agent 应 STOP vs. Agent 应持续推进） -- [[Market Research & Product Factory]]：PreBuild Validation 互补——前者挖痛点找方向，后者在动手前验证赛道竞争密度 - -## Aliases -- Pre-Build Idea Validation -- Idea Validation -- Competition Analysis Gate diff --git a/wiki/concepts/Predictive-Maintenance.md b/wiki/concepts/Predictive-Maintenance.md deleted file mode 100644 index d192ed8b..00000000 --- a/wiki/concepts/Predictive-Maintenance.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: "Predictive Maintenance" -tags: - - devops - - reliability - - ai - - operations -created: 2026-04-25 ---- - -# Predictive Maintenance - -## Definition - -Predictive Maintenance 是基于历史故障模式学习，**主动建议补丁或变更**以预防非计划停机的方法。Agentic AI 分析历史运维数据，预测潜在故障并提前采取预防措施。 - -## Mechanism - -``` -Historical Data → Pattern Learning → Failure Prediction → Proactive Action - ↓ -运维日志、告警历史、变更记录、监控数据 - ↓ -ML 模型识别故障前兆模式 - ↓ -- 磁盘 I/O 逐渐下降 → 预测磁盘故障 → 建议迁移 -- 内存使用率周期性峰值 → 预测 OOM → 建议扩容 -- API 响应时间逐步增加 → 预测容量瓶颈 → 建议扩缩容 -``` - -## 与 Self-Healing Systems 的关系 - -| 维度 | Reactive (Self-Healing) | Predictive (Predictive Maintenance) | -|------|------------------------|-----------------------------------| -| 时机 | 故障发生后修复 | 故障发生前预防 | -| 目标 | 减少 MTTR | 减少 MTBF (Mean Time Between Failures) | -| 成本 | 被动投入 | 主动投入，高 ROI | -| 成熟度 | Level 4 AIOps | Level 5 AIOps | - -## 示例 - -> Agentic AI analyzes 6 months of Kubernetes pod restart logs and identifies: -> - Pods restart every 48-72 hours -> - Pattern correlates with memory leak in v2.3.1 of service -> - **Predicts**: Next scheduled restart will cause cascade failure -> - **Proposes**: Patch to v2.3.2 + preventive restart during low-traffic window - -## 与 [[AIOps]] 的关系 - -Predictive Maintenance 是 [[AIOps]] Level 5 (Optimizing) 的核心能力： - -```python -DevOps_Maturity_AIOps = { - "Level 3 - Defined": "Smart Alerting", - "Level 4 - Advanced": "Self-Healing: Automated Remediation", - "Level 5 - Optimizing": "Predictive Maintenance ←" # ← 本页 -} -``` - -## Related Concepts - -- [[Self-Healing Systems]] — Predictive 是 Reactive 的进化 -- [[AIOps]] — Predictive Maintenance 是 AIOps 的高级能力 -- [[MTTR]] — Predictive 改善 MTBF，MTTR 不变但故障减少 -- [[Availability]] — Predictive 直接提升可用性 - -## Related Sources - -- [[how-agentic-ai-can-help-for-cloud-devops]] diff --git a/wiki/concepts/PrematureAbstraction.md b/wiki/concepts/PrematureAbstraction.md deleted file mode 100644 index a8da1446..00000000 --- a/wiki/concepts/PrematureAbstraction.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "PrematureAbstraction" -type: concept -tags: [engineering, code-quality, design] -last_updated: 2026-05-02 ---- - -## Definition - -过早抽象（PrematureAbstraction）指在实际需要提取抽象之前（通常指第三次出现之前）就引入辅助函数、类或接口的代码设计反模式。这导致引入短期内无法偿还的隐性债务。 - -## Core Rule - -**等待第四次出现再提取。** 前三次重复出现时，保持重复代码而非提取抽象。提取的时机应基于实际的调用次数，而非"直觉上看起来应该提取"。 - -## Why Wait for the Fourth Time - -- **第一次**：孤例，可能是一次性的特殊处理 -- **第二次**：可能是巧合，模式尚不清晰 -- **第三次**：确认存在模式，但抽象接口（参数、返回值、边界情况）尚未完全明确 -- **第四次**：抽象接口足够清晰，且维护收益开始超过抽象本身的成本 - -## Examples - -### ❌ 过早抽象（第二次就提取） - -```typescript -// 第二次出现就开始提取 -const dryRun = args.includes('--dry-run'); -if (dryRun) logDryRun(records); - -// 马上为第三次出现提取 -export function runWithMode(mode: RunMode, records: Record[]) { - // strategy pattern introduced too early -} -``` - -### ✅ 延迟抽象（第四次才提取） - -```typescript -// 保持三次重复 -if (dryRun) logDryRun(records); -if (dryRun) logDryRun(items); -if (dryRun) logDryRun(entries); - -// 第四次出现——抽象接口完全清晰了 -export function runDry(records: Record[]) { - return { dry: true, count: records.length }; -} -``` - -## Connections - -- [[engineering-minimal-change-engineer]]：最小变更工程师的核心原则之一 -- [[ScopeCreep]]：过早抽象通常是范围蔓延的表现形式 -- [[MinimalChangePrinciple]]：最小变更原则的延伸——保持重复代码直到收益明确 - -## Sources - -- [[engineering-minimal-change-engineer]] diff --git a/wiki/concepts/Presentism.md b/wiki/concepts/Presentism.md deleted file mode 100644 index 07599e5d..00000000 --- a/wiki/concepts/Presentism.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Presentism" -type: concept -tags: [historiography, methodology, ethics] -sources: [academic-historian] -last_updated: 2026-04-30 ---- - -## Definition -当代主义（Presentism）是一种历史思维中的方法论错误，指以当代的道德标准、价值观和概念框架去评判过去的历史人物和事件，而不承认或不理解历史情境与当代的差异。Historian Agent 将其作为核心方法论警示，要求在历史评估中保持"情境理解"。 - -## Key Features -- **定义**：用现代人的道德眼镜审视历史，而非将历史人物置于其时代背景中理解 -- **经典案例**： - - 用现代"民族国家"概念评判前现代政体 - - 用现代"个人权利"观念评价中世纪社会结构 - - 用现代"平等"标准否定历史上缺乏民主的社会 -- **Historian Agent 的立场**： - - **避免极端**：不因情境化而开脱历史暴行（"不以现代标准评判，但也不为暴行开脱"） - - **双重意识**：承认历史条件限制，同时保持道德评价的可能性 -- **与之对立的概念**： - - 历史主义（Historicism）：强调理解历史情境 - - 道德相对主义（Moral Relativism）：以情境为由完全否定道德评价 - -## Relationship to Other Concepts -- [[academic-historian]] ← 核心警示 ← [[Presentism]]：文档"🚨 Critical Rules"明确规定，是 Historian Agent 五步工作流的认识论前提 -- [[Historiography]] ← 属于 ← [[Presentism]]：Presentism 是历史编纂学中一个重要的认识论问题 -- [[Counterfactual-Analysis]] ← 关联 ← [[Presentism]]：反事实推理可以帮助理解历史偶然性，避免"历史必然"的当代偏见 - -## Relationship to Source Pages -- [[academic-historian]]：文档"🚨 Critical Rules"节明确列出"避免 presentism" - -## Aliases -- 当代主义 -- 当代投射谬误 -- Anachronistic Judgment diff --git a/wiki/concepts/Prisma-Access.md b/wiki/concepts/Prisma-Access.md deleted file mode 100644 index 45284fbc..00000000 --- a/wiki/concepts/Prisma-Access.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: "Prisma Access" -type: concept -tags: [AWS, Security, SASE, VPN, Networking] -sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] -last_updated: 2026-05-07 ---- - -## Prisma Access - -Prisma Access 是 [[PaloAltoNetworks]] 提供的基于云的安全访问服务（SASE, Secure Access Service Edge），用于替代传统 VPN，提供更安全的统一访问体验。 - -## Definition - -- **类型**: SASE（Secure Access Service Edge）云安全服务 -- **供应商**: [[PaloAltoNetworks]] -- **核心功能**: 将网络安全功能（SWG、CASB、ZTNA、Firewall-as-a-Service）与网络连接功能（SD-WAN）整合为单一云原生服务 -- **替代方案**: 传统 VPN（Pulse Secure VPN 等） - -## Key Capabilities - -- **就近接入**: 在全球部署大量接入网关（PoP, Point of Presence），用户自动路由至最近节点 -- **统一安全策略**: 所有流量统一执行安全检查，无需逐设备配置 -- **ZTNA（Zero Trust Network Access）**: 基于身份和设备状态而非网络位置授权访问 -- **与 SD-WAN 整合**: 可直接打通 SD-WAN 骨干网，实现云端与分支机构的统一连接 - -## In CTP Architecture - -在 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 中的规划： - -- **现状**: 使用 [[Pulse-VPN]] 提供远程访问（传统 VPN 架构） -- **目标**: 迁移至 Prisma Access，实现： - 1. 全球更多接入网关，用户就近接入 - 2. 显著降低访问延迟 - 3. 直接打通 SD-WAN 骨干网 - 4. 统一安全策略管理 - -## Comparison: Traditional VPN vs Prisma Access - -| 维度 | Pulse VPN（传统） | Prisma Access（SASE） | -|------|-----------------|----------------------| -| 接入方式 | VPN 隧道，IP 路由 | 就近接入，身份驱动 | -| 延迟 | 单一 VPN 入口，高延迟 | 全球 PoP，低延迟 | -| 安全策略 | 基于网络位置 | 基于身份和设备状态 | -| 扩展性 | 差 | 好（云原生） | -| SD-WAN 整合 | 无 | 原生整合 | - -## Connections - -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 远程访问方案 ← [[Prisma-Access]] -- [[PaloAltoNetworks]] ← 提供商 ← [[Prisma-Access]] -- [[SD-WAN]] ← 整合 ← [[Prisma-Access]] -- [[Pulse-VPN]] ← 替代 ← [[Prisma-Access]] - -## Sources - -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/concepts/Private-Cloud.md b/wiki/concepts/Private-Cloud.md deleted file mode 100644 index 7aa285a9..00000000 --- a/wiki/concepts/Private-Cloud.md +++ /dev/null @@ -1,144 +0,0 @@ -# Private Cloud - -> **Private Cloud** — 私有云是专属于单一组织的云环境，通过安全私有网络访问，可由组织本地托管或由第三方供应商托管，提供比公有云更高的性能、安全性和控制力。 - -## Definition - -私有云（Private Cloud）是专为单个组织构建和运营的云基础设施。与公有云不同，私有云的资源不与其他组织共享，因此提供更强的安全性、可定制性和性能保证。私有云可以部署在组织自己的数据中心（on-premises），也可以由第三方供应商在其设施中托管（hosted private cloud）。 - -## Key Characteristics - -| 特征 | 描述 | -|------|------| -| **独占环境** | 资源仅供单一组织使用，无多租户共享 | -| **高安全性** | 自定义安全协议和配置，满足严格合规要求 | -| **私有网络访问** | 通过专用连接访问，非公开互联网 | -| **可定制性** | 根据组织需求深度定制基础设施 | -| **强SLA保证** | 高性能和高效率的服务级别协议 | -| **部署灵活性** | 可本地托管、托管托管或混合部署 | - -## Deployment Architecture - -``` -┌──────────────────────────────────────────┐ -│ 组织 A 私有云环境 │ -│ │ -│ ┌──────────────────────────────────┐ │ -│ │ 私有数据中心 / 托管设施 │ │ -│ │ │ │ -│ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │ -│ │ │ Web │ │ App │ │ DB │ │ │ -│ │ │层 │ │ 层 │ │ 层 │ │ │ -│ │ └─────┘ └─────┘ └─────┘ │ │ -│ │ │ │ -│ │ 虚拟化层（VMware/KVM/OpenStack） │ │ -│ │ 专用物理服务器集群 │ │ -│ └──────────────────────────────────┘ │ -│ │ -│ ↕ 私有网络/专用连接 │ -│ ┌──────────────────────────────────┐ │ -│ │ 组织内部用户 / 远程用户 │ │ -│ └──────────────────────────────────┘ │ -└──────────────────────────────────────────┘ -``` - -## Advantages - -### 1. 独占安全环境 -- 其他组织无法访问的专用安全环境 -- 定制安全协议满足严格合规需求 -- 不受其他租户安全事件影响（"噪音邻居"问题消除） - -### 2. 自定义安全配置 -- 运行自定义协议、配置和措施 -- 根据独特工作负载需求定制安全策略 -- 满足行业特定合规标准（HIPAA、PCI-DSS、ISO 27001） - -### 3. 无性能权衡的扩展性 -- 高扩展性和效率满足不可预测需求 -- 不牺牲安全性和性能 -- 可根据业务增长弹性扩展容量 - -### 4. 高效性能 -- 可靠的高SLA性能和效率 -- 无资源竞争和延迟问题 -- 专属资源保证一致性性能 - -### 5. 灵活性 -- 根据组织变化的需求灵活转型基础设施 -- 支持定制化集成和工作负载优化 -- 适应业务和技术双重变革 - -### 6. 专属资源无争用 -- 不与其他组织共享资源 -- 不存在资源竞争导致的性能下降 -- 延迟可预测和可控 - -## Drawbacks - -### 1. 成本较高 -- 相比公有云替代方案，TCO相对较高 -- 尤其对于短期使用场景不经济 -- 需要持续的资本投入和维护成本 - -### 2. 远程使用受限 -- 高安全措施可能导致远程用户访问受限 -- 移动办公支持不如公有云灵活 -- 需要额外的VPN或专线配置 - -### 3. 扩展性受限 -- 若数据中心局限于本地计算资源，基础设施可能无法高扩展 -- 应对突发流量需要提前容量规划 -- 扩展周期长于公有云 - -### 4. 管理复杂 -- 需要大量内部技术专业知识运营私有云 -- 维护、更新、安全需要专职团队 -- 运营成本持续较高 - -### 5. 潜在资源浪费 -- 可能无法充分利用资源，导致昂贵基础设施浪费 -- 容量规划不准确导致过度配置 -- 闲置资源成本高 - -## When to Use Private Cloud - -| 场景 | 说明 | -|------|------| -| **高度监管行业** | 金融、医疗、政府等对数据安全有严格要求的行业 | -| **敏感数据处理** | 包含个人隐私、商业机密、知识产权的数据 | -| **强控制和安全性要求** | 需要对IT工作负载和底层基础设施的完全控制 | -| **大型企业** | 需要先进技术数据中心高效运营的复杂组织 | -| **高可用性需求** | 任务关键型应用需要99.99%+ SLA保证 | -| **合规驱动** | 必须满足特定行业法规的数据驻留要求 | - -## Cost Structure - -| 成本维度 | 私有云 | 公有云 | -|----------|--------|--------| -| 前期资本投入 | 高（硬件采购） | 低 | -| 扩展成本 | 需要新硬件 | 按使用付费 | -| 人员成本 | 高（专职团队） | 低（供应商管理） | -| 维护成本 | 内部承担 | 提供商承担 | -| 适合场景 | 长期、稳定、高价值负载 | 短期、弹性、变化负载 | - -## Related Concepts - -- [[Public Cloud]] — 公有云部署模式对比 -- [[Hybrid Cloud]] — 混合云结合公私优势 -- [[Cloud Security]] — 云安全 -- [[Cloud Compliance]] — 云合规性 -- [[High Availability]] — 高可用性 -- [[SLA]] — 服务级别协议 -- [[Disaster Recovery Planning]] — 灾难恢复规划 -- [[ISO-27001]] — 信息安全管理体系标准 -- [[HIPAA]] — 美国医疗健康信息隐私法规 -- [[GDPR]] — 欧盟通用数据保护条例 - -## See Also - -- [[Cloud Computing]] — 云计算基础 -- [[Cloud-Adoption-Strategy]] — 云采用策略 -- [[Cloud-Maturity-Model]] — 云成熟度模型 -- [[Cloud-Migration]] — 云迁移 -- [[Shared-Responsibility-Model]] — 共享责任模型 diff --git a/wiki/concepts/Private-Context.md b/wiki/concepts/Private-Context.md deleted file mode 100644 index b40722d7..00000000 --- a/wiki/concepts/Private-Context.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "Private Context" -type: concept -tags: [OpenClaw, Agent, Architecture, Memory] -sources: [multi-agent-team] -last_updated: 2026-04-23 ---- - -## Definition - -**Private Context** 是多 Agent 系统中，每个 Agent 独立维护的会话历史和领域特定笔记，与 Shared Memory 共同构成 Agent 的完整知识体系。 - -## 核心洞察 - -> "Shared memory + private context: The combination is critical — agents need common ground (goals, decisions) but also their own space to accumulate domain expertise" - -私有上下文的作用： -- **积累领域专长**：Agent 在独立空间深耕专业知识 -- **会话连续性**：Agent 能记住自己的历史决策和上下文 -- **避免干扰**：专业笔记不会与其他 Agent 混淆 - -## 私有上下文结构 - -``` -team/agents/ -├── milo/ # Milo 的私有上下文 -│ ├── sessions/ # 会话历史 -│ └── notes/ # 战略分析和笔记 -├── josh/ # Josh 的私有上下文 -│ ├── sessions/ # 会话历史 -│ └── notes/ # 商业分析和模型 -├── marketing/ # 营销 Agent 的私有上下文 -│ ├── sessions/ # 会话历史 -│ └── notes/ # 营销研究和趋势分析 -└── dev/ # 开发 Agent 的私有上下文 - ├── sessions/ # 会话历史 - └── notes/ # 技术笔记和技术债追踪 -``` - -## 与 Shared Memory 的关系 - -**Private Context** + **Shared Memory** 组合是关键： - -| 维度 | Shared Memory | Private Context | -|------|---------------|-----------------| -| **可见性** | 所有 Agent | 仅该 Agent | -| **用途** | 团队协调、共同决策 | 领域深耕、专业积累 | -| **更新频率** | 决策时更新 | 持续积累 | -| **典型内容** | 目标、决策、状态 | 会话历史、专业笔记 | - -## 为什么两者都需要 - -- **只有共享记忆**：Agent 缺乏领域深度 -- **只有私有上下文**：Agent 无法协调，形成知识孤岛 -- **两者结合**：既能有团队协作，又能深耕专业 - -## Related Concepts - -- [[Shared Memory Architecture]] — 团队共享记忆 -- [[Agent-Memory]] — OpenClaw 的长期记忆机制 -- [[Agent Specialization]] — 专业化 Agent 依赖私有上下文积累深度 -- [[OpenClaw]] — workspace 目录体系支持私有上下文 - diff --git a/wiki/concepts/Private-Hosted-Zone.md b/wiki/concepts/Private-Hosted-Zone.md deleted file mode 100644 index e9c1b1be..00000000 --- a/wiki/concepts/Private-Hosted-Zone.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Private Hosted Zone" -type: concept -tags: - - AWS - - DNS - - Networking -last_updated: 2026-04-28 ---- - -## Definition - -Private Hosted Zone（PHZ，私有托管区）是 Amazon Route 53 的一项功能，允许在指定的 Amazon VPC 内部解析自定义私有域名（如 `int-sas.local`、`corp.internal`）。与公有托管区不同，PHZ 的DNS记录不对互联网开放，仅在关联的 VPC 内可见。 - -## Aliases -- Private Hosted Zone -- PHZ -- AWS 私有托管区 - -## Key Characteristics - -- **VPC 范围隔离**：DNS 记录仅在关联的 VPC 内可解析，保证内部域名不暴露 -- **跨账号关联**：VPC 可与另一个 AWS 账户拥有的 PHZ 关联，但必须先完成"授权（Authorization）"再执行"关联（Association）" -- **Resolver 自动优先**：当查询匹配 PHZ 中的域名时，Route 53 Resolver 直接返回 PHZ 记录，不再转发至转发规则 -- **多 VPC 支持**：一个 PHZ 可关联多个 VPC，支持跨区域（但建议同区域以减少延迟） -- **集中化 vs 分散化**：在 Landing Zone 架构中，推荐集中式 DNS 账号管理 PHZ，而非在每个业务账号中分散创建 - -## Related Concepts -- [[Route-53-Resolver]] — PHZ 依赖 Resolver 进行解析 -- [[Resolver-Rules]] — 未匹配 PHZ 的查询由 Resolver Rules 转发 -- [[VPC-Association-Authorization]] — 跨账号 PHZ 关联流程 -- [[AWS-Landing-Zone]] — 多账号环境下的 PHZ 管理策略 - -## Sources -- [[ctp-topic-19-configuring-dns-within-aws-lzs]] diff --git a/wiki/concepts/Private-Subnet-Architecture.md b/wiki/concepts/Private-Subnet-Architecture.md deleted file mode 100644 index ddd9b8f7..00000000 --- a/wiki/concepts/Private-Subnet-Architecture.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Private-Subnet-Architecture" -type: concept -tags: [AWS, Networking, Security] -sources: [ctp-topic-7-saas-landing-zone-design] -last_updated: 2026-05-06 ---- - -## Private-Subnet-Architecture - -AWS VPC 私有子网架构原则 — 工作负载必须部署于私有子网，通过负载均衡器对外暴露服务的架构模式。 - -## Definition - -私有子网架构是产品账户网络设计的核心原则： -- **工作负载位置**：所有应用和服务（ECS、RDS、Lambda 等）部署于私有子网 -- **公网暴露**：仅通过公有子网的 Load Balancer（ALB/NLB）和 Internet Gateway 对外暴露 -- **安全优势**：减少公网攻击面，工作负载无需直接暴露公网 IP - -## Role in SAS Landing Zone - -在 [[ctp-topic-7-saas-landing-zone-design]] 定义的 Product Account 中： -- **工作负载**：业务应用（Product workloads）必须部署于私有子网 -- **入站链路**：用户 → Internet Gateway → Load Balancer（公有子网）→ **工作负载（私有子网）** -- **出站链路**：私有子网通过 NAT Gateway 或 VPC Endpoints 访问互联网或 AWS 服务 - -## Key Properties -- **Type**: Network Architecture Pattern -- **Workload placement**: Private subnets (no direct internet exposure) -- **External exposure**: Via Load Balancers only -- **In SAS LZ**: Product Account 网络设计原则 - -## Related Concepts -- [[VPC-Endpoint]] — 私有访问 AWS 服务（无需 NAT） -- [[Network-Segmentation]] — 网络分段策略 -- [[Defense-in-Depth]] — 纵深防御安全模型 - -## Connections -- [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 产品账户网络设计原则 -- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] — 网络分段阻断 SaaS 直接连通性 -- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] — EKS 在私有子网的部署实践 diff --git a/wiki/concepts/Privileged-Access-Management.md b/wiki/concepts/Privileged-Access-Management.md deleted file mode 100644 index 2df4e9a5..00000000 --- a/wiki/concepts/Privileged-Access-Management.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: "Privileged-Access-Management" -type: concept -tags: - - Security - - PAM - - Compliance - - Cloud - - DevOps ---- - -## Definition - -Privileged Access Management（PAM，特权访问管理）是一类安全解决方案，用于管理和监控具有 elevated permissions 的账号访问权限。特权账号包括系统管理员、数据库管理员、安全管理员等拥有超出普通用户权限的账号，以及应用程序服务账号、API 账号等非人工身份。 - -## Core Objectives - -1. **凭据保护**：集中存储和管理特权账号密码、SSH 密钥、API Key 等敏感凭据 -2. **访问控制**：实施最小权限原则，确保用户仅获得完成任务所需的最小权限 -3. **会话监控**：记录和审计所有特权会话，支持事后追溯和合规审查 -4. **威胁检测**：实时检测异常特权行为，防止凭据滥用和横向移动攻击 - -## PAM Architecture - -``` -┌─────────────────────────────────────────────────────────────┐ -│ PAM Solution │ -├─────────────────────────────────────────────────────────────┤ -│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ -│ │ Credential │ │ Session │ │ Risk │ │ -│ │ Vault │ │ Manager │ │ Engine │ │ -│ └─────────────┘ └─────────────┘ └─────────────┘ │ -│ │ -│ ┌─────────────────────────────────────────────┐ │ -│ │ Access Control Layer │ │ -│ │ (RBAC, MFA, Policy-based Access) │ │ -│ └─────────────────────────────────────────────┘ │ -└─────────────────────────────────────────────────────────────┘ - ↑ - ┌─────────────────┼─────────────────┐ - ↓ ↓ ↓ - ┌─────────┐ ┌─────────┐ ┌─────────┐ - │ Root │ │ DB │ │ API │ - │ Account │ │ Admin │ │ Service │ - └─────────┘ └─────────┘ └─────────┘ -``` - -## Cloud-Native vs Traditional PAM - -| Aspect | Traditional PAM | Cloud-Native (AWS Secrets Manager) | -|--------|-----------------|----------------------------------| -| Deployment | On-prem / Hybrid | Fully managed SaaS | -| Client Agent | Required | Not required | -| Scalability | Manual scaling | Auto-scaling | -| Cost Model | Perpetual license + maintenance | Pay-per-use | -| Integration | Manual configuration | Native AWS integration | - -## Key Vendors - -- **CyberArk**：Enterprise PAM market leader, on-prem and cloud offerings -- **AWS Secrets Manager**：Cloud-native secrets management -- **HashiCorp Vault**：Cloud-agnostic secrets and privileged access -- **BeyondTrust**：Endpoint privilege management -- **Thycotic**：Privileged access management - -## Related Concepts - -- [[SecretsManagement]]：敏感信息管理的整体框架 -- [[SecretRotation]]：密钥轮换机制 -- [[IAM-Roles]]：基于角色的访问控制 -- [[Zero-Trust]]：零信任安全模型 - -## Related Entities - -- [[CyberArk]]：Enterprise PAM vendor -- [[AWS]]：Cloud-native secrets management provider -- [[HashiCorp]]：Cloud-agnostic secrets management - -## Sources - -- [[ctp-topic-37-secrets-certificates-management]] — CyberArk Micro Focus PAM evaluation -- [[ctp-topic-62-aws-secrets-manager]] — AWS-native PAM implementation - -## Aliases - -- PAM -- Privileged Access Management -- Privileged Identity Management -- PIM diff --git a/wiki/concepts/Proactive-AI.md b/wiki/concepts/Proactive-AI.md deleted file mode 100644 index 840920c4..00000000 --- a/wiki/concepts/Proactive-AI.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Proactive AI" -type: concept -tags: [ai, agentic-ai, interaction-design] -last_updated: 2026-04-23 ---- - -# Proactive AI - -## Aliases -- 主动 AI -- Proactive Assistant -- 主动预判型 AI - -## Definition -AI 主动预判用户需求、提前采取行动，而非被动等待用户指令的交互模式。核心特征：AI 不只是响应请求，而是识别潜在需求并在适当时机主动介入。 - -## Contrast with Reactive AI -| | Reactive AI | Proactive AI | -|--|------------|--------------| -| 触发方式 | 用户请求 | AI 自主判断 | -| 典型行为 | 回答问题 | 推送提醒、建议行动 | -| 用户角色 | 主动方 | 审核/确认方 | -| 适用场景 | 问答、检索 | 监控、任务管理 | - -## Examples in This Wiki -- [[openai-chatgpt-个性化定义]]：ChatGPT 被配置为"主动出击，预判我的需求" -- [[custom-morning-brief]]：AI 主动推送每日晨间简报，而非用户查询 -- [[self-healing-home-server]]：Agent 主动监控并在问题发生前修复 -- [[personal-crm]]：AI 主动研究会议参会者并推送背景资料 - -## Relationship to TCPCA -Proactive AI 是 [[designing-for-agentic-ai]] 中"主动预判"（Anticipation）原则的核心体现——AI 预判需求并主动提供帮助，同时允许用户控制 AI 自主权级别。 - -## Key Insight -> "主动任务推荐是整个系统最有价值的部分——AI 主动思考如何帮助用户，而非被动等待指令。" — 自定义晨间简报核心洞察 - -## Sources -- [[openai-chatgpt-个性化定义]] -- [[custom-morning-brief]] -- [[designing-for-agentic-ai]] diff --git a/wiki/concepts/Proactive-Agent-Recommendation.md b/wiki/concepts/Proactive-Agent-Recommendation.md deleted file mode 100644 index 1a0c3df7..00000000 --- a/wiki/concepts/Proactive-Agent-Recommendation.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Proactive Agent Recommendation" -type: concept -tags: [openclaw, ai-agent, productivity] -sources: [custom-morning-brief, multi-agent-team] -last_updated: 2026-04-22 ---- - -## Definition - -主动任务推荐（Proactive Agent Recommendation）是一种 AI Agent 设计范式——Agent 不是被动等待用户指令，而是主动分析用户上下文并推荐可自主完成的辅助任务，使用户从"发出指令→等待结果"转变为"收到已完成的工作成果"。 - -## Contrast with Reactive Mode - -| 维度 | 被动模式（Reactive） | 主动模式（Proactive） | -|------|--------------------|--------------------| -| 触发方式 | 用户主动发起请求 | AI 定时或基于上下文自动触发 | -| 用户角色 | 指挥官 | 接收者/审批者 | -| 价值交付 | 按需响应 | 提前完成，超出预期 | -| 认知负担 | 用户需持续思考"要什么" | AI 承担"思考要做什么" | - -## Key Applications - -- **[[custom-morning-brief]]**：每日晨间简报中的"AI 主动推荐可完成任务"模块 -- **[[multi-agent-team]]**：Agent 主动推送工作成果，而非等待轮询 - -## Implementation Pattern - -```text -1. Cron Job 触发 → AI 分析用户上下文 -2. AI 生成 N 条可自主完成的任务建议 -3. 高置信度任务 → 自动执行 -4. 中置信度任务 → 推送选项，用户确认后执行 -5. 结果交付 → Telegram/Discord -``` - -## Related Concepts - -- [[Scheduled Task Flywheel]] — 主动推荐的时间调度机制 -- [[Agent Personality]] — 主动行为需要精心设计的 Agent 人格 -- [[Morning Briefing]] — 主动推荐的典型应用场景 diff --git a/wiki/concepts/ProactiveAI.md b/wiki/concepts/ProactiveAI.md deleted file mode 100644 index 9dca3dfa..00000000 --- a/wiki/concepts/ProactiveAI.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "ProactiveAI" -type: concept -tags: [] ---- - -## Definition -AI 代理主动预测用户需求、推荐行动方案，而非被动等待用户发起指令的设计模式。核心转变：从"你让我做什么"到"我认为你需要什么"。 - -## Aliases -- 主动式 AI -- Anticipatory AI - -## Key Characteristics -- **需求预测（Demand Forecasting）**：基于上下文（时间、位置、历史行为）预测下一步 -- **自主建议（Autonomous Recommendations）**：AI 主动提出可帮助完成的任务，而非等待指令 -- **零门槛定制（Zero-Threshold Customization）**：用户可通过自然语言随时调整 AI 的主动行为范围 -- **价值飞轮（Value Flywheel）**：AI 越主动 → 用户越依赖 → 数据越多 → AI 越精准 - -## Core Example -[[custom-morning-brief]] 中的"AI 主动推荐可自主完成的任务"——AI 在分析用户待办清单后，主动思考并推荐可代劳的工作，让用户醒来已有产出。 - -## Related Concepts -- [[ScheduledReport]]：主动推送的结构化形式 -- [[AgenticMemory]]：支撑主动预测的长期记忆能力 -- [[FullDraftGeneration]]：主动产出的内容质量标准——不仅建议，做完它 diff --git a/wiki/concepts/Problem-Management.md b/wiki/concepts/Problem-Management.md deleted file mode 100644 index 56a4f610..00000000 --- a/wiki/concepts/Problem-Management.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "Problem Management" -type: concept -tags: [itsm, incident-management, operations] -date: 2025-03-01 ---- - -## Definition - -问题管理（Problem Management）是[[ITSM]]的核心流程之一，专注于**识别和分析IT服务问题的根本原因**，防止同类事件重复发生。与事件管理（Incident Management）处理症状不同，问题管理处理的是根本原因。 - -## Problem Management vs Incident Management - -| 维度 | 事件管理 | 问题管理 | -|------|---------|---------| -| 目标 | 快速恢复服务 | 消除根本原因 | -| 处理 | 症状 | 根因 | -| KPI | MTTR | 问题消除率 | -| 时效 | 即时 | 中长期 | - -## Problem Management Process - -``` -┌──────────────┐ ┌──────────────┐ ┌──────────────┐ -│ Problem │ → │ Root Cause │ → │ Known Error │ -│ Detection │ │ Analysis │ │ Document │ -└──────────────┘ └──────────────┘ └──────────────┘ - ↓ ↓ ↓ - AI Anomaly ML-enhanced Known Error - Detection RCA Process Database (KEDB) -``` - -## Modern Problem Management (ITSM 2.0) - -在[[ITSM 2.0]]中，问题管理由AI驱动： - -### AI-Driven Features -- **Anomaly Detection** — 自动识别异常模式 -- **Predictive Analytics** — 预测潜在问题 -- **ML-enhanced RCA** — 机器学习加速根因分析 -- **Automated KEDB Updates** — 自动更新已知错误库 - -## Key Metrics - -| 指标 | 描述 | -|------|------| -| Problem Resolution Rate | 问题解决率 | -| Mean Time to Diagnose (MTTD) | 平均诊断时间 | -| Recurring Incidents | 重复发生事件数 | -| Known Error Accuracy | 已知错误准确率 | - -## Related Concepts - -- [[ITSM]] — 父框架 -- [[Incident-Management]] — 事件管理 -- [[Root-Cause-Analysis]] — 根因分析 -- [[AIOps]] — AI驱动的分析能力 -- [[MTTD]] — 平均诊断时间 -- [[Event-Correlation]] — 事件关联 - -## Sources - -- [[understanding-complete-itsm]] — AI-driven Problem Management diff --git a/wiki/concepts/Procedural-Level-Design.md b/wiki/concepts/Procedural-Level-Design.md deleted file mode 100644 index 486b1a47..00000000 --- a/wiki/concepts/Procedural-Level-Design.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Procedural Level Design" -type: concept -tags: [] -last_updated: 2026-04-26 ---- - -## Definition - -程序化关卡设计（Procedural Level Design）是通过算法规则自动或半自动生成游戏关卡的学科。目标是建立保证最低质量阈值的规则集，让程序生成的内容达到手工程度的标准。 - -## Core Components - -### Grammar Definition（语法定义） -为生成系统建立规则语法： -- **Tiles（瓦片）**：基本构建单元 -- **Connectors（连接器）**：瓦片之间的连接规则 -- **Density Parameters（密度参数）**：控制内容分布的参数 -- **Guaranteed Content Beats（保证内容节拍）**：必须出现的关键节点 - -### Critical Path Anchors（关键路径锚点） -- 手工打造的关键路径锚点必须被程序化系统尊重 -- 锚点决定整体结构，算法填充中间空间 -- 锚点位置通常由叙事或游戏设计要求决定 - -### Quality Validation（质量验证） -程序化输出必须通过自动化指标验证： -- **Reachability（可达性）**：所有区域是否可达 -- **Key-Door Solvability（钥匙门可解性）**：是否有足够的钥匙对应所有锁 -- **Encounter Distribution（遭遇分布）**：战斗密度是否合理 - -## Trade-offs -- **Diversity vs. Consistency**：程序生成的多样性 vs. 保持游戏风格一致性 -- **Surprise vs. Control**：意外惊喜 vs. 设计师对最终质量的控制 - -## Related Concepts -- [[Level Designer Agent Personality]]：程序化设计是 Level Designer 的高级能力 -- [[Blockout Discipline]]：程序化系统生成的灰盒仍需遵循 blockout 纪律 -- [[Flow And Readability]]：程序生成的空间必须满足可读性标准 - -## Sources -- [[Level Designer Agent Personality]] diff --git a/wiki/concepts/ProceduralContentGeneration.md b/wiki/concepts/ProceduralContentGeneration.md deleted file mode 100644 index e1f717fa..00000000 --- a/wiki/concepts/ProceduralContentGeneration.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "ProceduralContentGeneration" -type: concept -tags: ["unreal-engine", "procedural", "environment", "pcg"] -sources: ["unreal-technical-artist", "unreal-world-builder"] -last_updated: 2026-04-30 ---- - -## Aliases -- PCG -- Procedural Content Generation -- UE5 PCG -- Procedural Foliage Tool - -## Definition -PCG（Procedural Content Generation，程序化内容生成）是 UE5 中通过图形化节点系统自动生成大规模环境资产（植被、岩石、碎片等）的系统。通过采样表面、随机化和几何约束，在运行时或预烘焙模式下批量放置资产。 - -## PCG vs Foliage Tool 选型原则 -| 场景 | 工具选择 | -|------|---------| -| 手绘英雄资产放置 | Foliage Tool（传统） | -| 大规模植被（1000+ 实例） | PCG + Nanite 预烘焙 | -| Runtime 生成（小区域 < 1km²） | PCG Runtime | -| 大面积开放世界（> 1km²） | PCG 预烘焙（流式兼容） | - -## PCG Graph 标准结构（以 Forest Population 为例） -1. **Surface Sampler**：在 World Partition 表面采样点 -2. **Attribute Filter**：按 biome mask 密度纹理过滤 -3. **Exclusion**：道路（8m buffer）、路径（4m）、水体（2m）、建筑（15m sphere） -4. **Poisson Disk Distribution**：最小间距防止聚集 -5. **Randomization**：旋转（Yaw 0-360°）和缩放（0.85-1.25x） -6. **Weighted Mesh Assignment**：按权重分配网格类型（如 40% Oak, 30% Pine, 20% Birch） -7. **Culling**：Nanite 资产 cull 80,000cm，非 Nanite cull 30,000cm - -## PCG Exposed Parameters（设计师调优旋钮） -- `GlobalDensityMultiplier`: 0.0–2.0 -- `MinForestSeparation`: 1.0–8.0m -- `RoadExclusionEnabled`: bool - -## Performance Constraints -- 所有 PCG 放置资产应在条件允许时启用 Nanite -- 大面积（> 1km²）使用预烘焙输出以兼容流式加载 -- Runtime PCG 仅限小区域，生成须在 3 秒内完成 - -## Connections -- [[UnrealWorldBuilder]] ← 植被放置 ← ProceduralContentGeneration -- [[UnrealEngine5]] ← 运行环境 ← ProceduralContentGeneration -- [[Nanite]] ← 几何支持 ← ProceduralContentGeneration -- [[WorldPartition]] ← 空间管理 ← ProceduralContentGeneration - -## Sources -- [[unreal-technical-artist]] -- [[unreal-world-builder]] diff --git a/wiki/concepts/Product-Backlog.md b/wiki/concepts/Product-Backlog.md deleted file mode 100644 index 30856d8d..00000000 --- a/wiki/concepts/Product-Backlog.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Product Backlog -type: concept -tags: [Agile, Scrum, Product-Management] -sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16, ctp-topic-57-product-backlog-managing-demand] ---- - -# Product Backlog - -**产品待办列表（Product Backlog）** 是敏捷开发中的核心工件，是已排序的需求、特性、技术任务和缺陷的列表，是 Sprint 规划的输入来源。 - -## Overview - -在 OpenText 云转型中： -- Oli Workflow 审批通过的请求进入 Product Backlog 管理管道 -- 通过双周评审会议评估需求的理解度、价值和优先级 -- Sprint 规划采用 50% 新需求 / 50% 支持+技术债的配比 - -## Key Processes - -| 阶段 | 活动 | -|------|------| -| 需求提交 | 通过 Octane 提交 | -| 评审会议 | 评估理解度、价值、优先级 | -| 特性化 | 带任务列表的详细需求 | -| Sprint 规划 | 提前6个 Sprint 规划 | -| 履约 | Prerequisite Phase → Sprint | - -## Attributes - -- **优先级排序**：基于 WSJF（Weighted Shortest Job First） -- **估算**：评估工作量大小 -- **细化（Refinement）**：持续完善需求细节 -- **渐进明细**：随着理解加深不断完善 - -## Related Concepts - -- [[Demand-Management]] — 需求管理 -- [[Oli-Workflow]] — 审批工作流 -- [[SMACs]] — 技术栈组合 -- [[WSJF]] — 加权最短工作优先 - -## Related Entities - -- [[Octane]] — 需求管理平台 -- [[Qixi]] — 需求提交入口 - -## Sources - -- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] -- [[sources/ctp-topic-57-product-backlog-managing-demand.md]] diff --git a/wiki/concepts/Product-Hierarchy.md b/wiki/concepts/Product-Hierarchy.md deleted file mode 100644 index 6b89fbde..00000000 --- a/wiki/concepts/Product-Hierarchy.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Product Hierarchy（产品层级结构）" -type: concept -tags: [Product-Hub, PHT, Product-Management, OpenText, Thor] -sources: - - public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806 -last_updated: 2026-05-11 ---- - -## Product Hierarchy（产品层级结构） - -Product Hierarchy 是 OpenText Product Hub（PHT）中定义的三层组织结构，用于管理企业软件产品的归属关系和治理责任。 - -## 结构定义 - -| 层级 | 名称 | 说明 | -|------|------|------| -| 第一层 | Business Unit（业务单元，BU） | 含工程负责人和 PM 负责人 | -| 第二层 | Line of Business（业务线，LOB） | 含业务线负责人和 PM Lead | -| 第三层 | Product（产品） | 含产品经理（PM）和开发经理，关联主产品 | - -## 核心原则 - -- **Product 定义**：具有独立 CI/CD 流水线或发布周期的软件分发 -- **Component 区分**：没有独立 CI/CD 流水线的库称为 Component；如果需要 ITLS 审查或扫描，应创建为 Product -- **层级归属**：某组件可以是父产品的组成部分，但若其拥有独立的发布周期（独立 CI/CD 流水线），则应在 PHT 中作为独立 Product 处理 - -## Product 状态 - -| 状态 | 含义 | -|------|------| -| Active | 常规发布周期 | -| Maintenance | 仅热修复/Bug 修复 | -| Inactive | 无发布活动 | - -## 与 Product Hub 的关系 - -[[Product Hub (PhD)]] 通过 Product Hierarchy 实现： -- 统一产品视图 -- 跨工具链（元数据：属性、Source Repo、Artifact Repo、用户信息）一致性管理 -- 外部系统集成（Jira、Value Edge、PSMQ、ITLS、OSS、Backstage） - -## Connections - -- [[Product-Hierarchy]] ← managed_by ← [[Product Hub (PhD)]] -- [[Product-Hierarchy]] ← belongs_to ← Business Unit -- [[Product-Hierarchy]] ← belongs_to ← Line of Business -- [[Product-Hierarchy]] ← defined_in ← [[Project Thor]] - -## Sources - -- [[public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806]] diff --git a/wiki/concepts/Product-Requirements-Document.md b/wiki/concepts/Product-Requirements-Document.md deleted file mode 100644 index ecc6efbe..00000000 --- a/wiki/concepts/Product-Requirements-Document.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Product Requirements Document (PRD)" -type: concept -tags: ["product-management", "documentation", "prd"] -last_updated: 2026-04-30 ---- - -## Aliases -- PRD -- Product Requirements Document - -## Definition -Product Requirements Document（产品需求文档）—— 结构化的需求定义文档，在产品经理开始设计方案之前，以用户证据和商业逻辑为支撑，明确描述要解决的问题以及成功衡量标准。 - -## Core Components -1. **问题陈述**（Problem Statement）：用户痛点或商业机会的具体描述，包含证据（用户访谈、行为数据、客服工单、竞争信号） -2. **目标与成功指标**（Goals & Success Metrics）：表格化列出目标、指标、当前基线、目标值和测量窗口 -3. **非目标**（Non-Goals）：明确本迭代不会解决的问题，防止范围蔓延 -4. **用户画像与故事**（User Personas & Stories）：核心用户画像 + 带验收标准的用户故事 -5. **解决方案概述**（Solution Overview）：2-4段叙事描述，包含关键设计决策 -6. **技术考量**（Technical Considerations）：依赖、已知风险、开放问题 -7. **发布计划**（Launch Plan）：阶段表（内部Alpha → 封闭Beta → GA），回滚标准 -8. **附录**（Appendix）：用户研究记录、竞品分析、设计稿链接等 - -## Key Principles -- **先写新闻稿，再写 PRD** —— 一段式新闻稿说不清楚用户为什么在乎，则还没准备好写需求或开始设计 -- **协作编写，不是孤立产出** —— 工程师和设计师应从一开始就参与文档编写 -- **所有指标都必须可测量** —— 定性描述不能成为验收标准 - -## Usage -由 [[Product Manager Agent]] 主导产出，是产品团队、工程师、设计师、营销和销售之间的共享语言和共识载体。 - -## Related -- [[RICE Prioritization Score]] — PRD 中优先级排序使用的量化框架 -- [[Opportunity Assessment]] — PRD 之前的早期机会评估文档 -- [[Go-to-Market (GTM) Brief]] — PRD 之后的发布执行计划 diff --git a/wiki/concepts/ProductLedGrowth.md b/wiki/concepts/ProductLedGrowth.md deleted file mode 100644 index 7670fca9..00000000 --- a/wiki/concepts/ProductLedGrowth.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Product-Led Growth" -type: concept -tags: ["product", "growth", "activation", "retention"] -last_updated: 2026-04-26 ---- - -## Definition -产品导向增长（PLG）——通过产品体验本身驱动用户获取和留存，而非依赖营销渠道或销售团队。用户通过产品感受到核心价值后，自然完成注册、付费和推荐。 - -## Core Principles -- **免费优先（Freemium/免费试用）**：降低用户尝试门槛 -- **产品内病毒传播**：分享功能、协作功能内置于产品体验 -- **激活率优化**：关注新用户首周激活率（目标 60%+） -- **留存驱动**：产品持续提供价值，让用户养成使用习惯 - -## PLG vs Sales-Led Growth -| Dimension | PLG | Sales-Led | -|-----------|-----|-----------| -| 核心驱动力 | 产品体验 | 销售团队 | -| 用户获取 | 有机/口碑 | 营销/广告 | -| 转化路径 | 用户自主探索 | 销售引导 | -| 适用场景 | B2C/SaaS | B2B/企业 | - -## Source -- [[marketing-growth-hacker]]（Marketing Growth Hacker Agent） - -## Aliases -- PLG -- Product-Led Growth diff --git a/wiki/concepts/Program-Demand-Process.md b/wiki/concepts/Program-Demand-Process.md deleted file mode 100644 index 908e60ff..00000000 --- a/wiki/concepts/Program-Demand-Process.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Program Demand Process" -type: concept -tags: [CTP, Cloud, AWS, Demand-Management] -sources: [ctp-topic-20-program-demand-process-flow-and-poc-onboarding, ctp-topic-57-product-backlog-managing-demand] -last_updated: 2026-04-14 ---- - -## Definition - -程序需求流程（Program Demand Process）指从业务需求产生、优先级排序到最终交付云迁移的端到端管理路径。是 Cloud Transformation Programme（CTP）治理框架的核心入口。 - -## Demand Sources - -需求驱动来源可分为三类： - -- **业务案例驱动**：如数据中心关闭、业务连续性需求、基础设施老化等业务压力 -- **战略优先级驱动**：高层管理人员（如 Matt）定义的企业战略优先级，自上而下传导 -- **产品路线图驱动**：产品团队的技术演进需求与路线图规划 - -## Process Stages - -1. **需求录入**：业务端提交转型需求 -2. **优先级排序**：基于业务价值和紧迫性排列需求优先级 -3. **POC 决策**：评估是否需要进行概念验证 -4. **Gate 审批**：通过 Gate 0/1/3 等关键决策点 -5. **迁移执行**：迁移至 Labs 或 SaaS 生产环境 -6. **验收与关闭**：确认迁移达成预期目标 - -## Key Gate Points - -- **Gate 0**：评估准入，确认需求符合云转型范围 -- **Gate 1**：Design Authority 审批，验证解决方案设计 -- **Gate 3**：迁移准入，最终批准启动生产迁移 - -## Related Concepts - -- [[Proof-of-Concept]]：在需求流程中降低迁移风险的关键验证手段 -- [[Gate-Process]]：治理需求流程的关键决策框架 -- [[Solution-Design]]：Gate 1 审批的核心交付物 -- [[Product-Backlog]]：需求管理的优先级排序机制 - -## References - -- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] -- [[ctp-topic-57-product-backlog-managing-demand]] diff --git a/wiki/concepts/Programmatic-Buying.md b/wiki/concepts/Programmatic-Buying.md deleted file mode 100644 index 875cbc4e..00000000 --- a/wiki/concepts/Programmatic-Buying.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Programmatic Buying" -type: concept -tags: ["programmatic", "dsp", "display", "paid-media"] -sources: ["paid-media-programmatic-buyer"] -last_updated: 2026-04-26 ---- - -## Definition - -程序化购买（Programmatic Buying）是通过需求方平台（DSP）自动化完成数字广告展示库存的购买、竞价和投放的技术驱动型广告采购方法。区别于传统人工谈判和预订式购买，程序化购买利用实时竞价（RTB）和预设算法规则，在毫秒级完成广告曝光机会的评估与竞价。 - -## Core Components - -- **DSP（Demand-Side Platform）**：需求方平台，广告主/代理商用来自动化购买广告库存的接口 -- **SSP（Supply-Side Platform）**：供应方平台，发布商用来出售广告库存 -- **Ad Exchange**：连接 DSP 与 SSP 的公开或私有交易市场 -- **Deal ID**：预先协议的交易 ID，允许广告主以固定价格预订优质库存 -- **PMP（Private Marketplace）**：私有市场，比公开竞价更具排他性和品牌安全性 -- **Programmatic Guaranteed**：程序化保证交易，固定价格、固定量保证 - -## Types of Programmatic Buying - -| 类型 | 说明 | 品牌安全性 | -|------|------|-----------| -| Open Exchange | 公开实时竞价 | 低 | -| PMP | 私有市场邀请竞价 | 中 | -| Programmatic Guaranteed | 固定价格保证量 | 高 | - -## Key Metrics - -- **CPM（Cost Per Mille）**：每千次展示成本 -- **Viewability Rate**：可见展示率（目标 ≥70% MRC 标准） -- **Invalid Traffic Rate**：无效流量率（目标 <3%） -- **Win Rate**：竞价成功率 - -## Related Concepts -- [[ABM Display]] -- [[Viewability]] -- [[Frequency Cap]] -- [[Supply Path Optimization]] - -## Sources -- [[paid-media-programmatic-buyer]] diff --git a/wiki/concepts/Progressive-Rollout.md b/wiki/concepts/Progressive-Rollout.md deleted file mode 100644 index 1c23ba35..00000000 --- a/wiki/concepts/Progressive-Rollout.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: "Progressive Rollout (渐进式放量)" -tags: [devops, continuous-delivery, feature-management, risk-mitigation] -aliases: [Canary Deployment, 灰度发布, Canary Release] -created: 2026-04-25 ---- - -# Progressive Rollout (渐进式放量) - -**Progressive Rollout**（渐进式放量/灰度发布）是一种通过 [[Feature Flag]] 控制新功能逐步向用户群发布的风险管理策略。与"全有或全无"的传统部署不同，Progressive Rollout 将影响范围控制在最小范围内，从而实现**可量化的 RTO**。 - -## Aliases -- Canary Deployment -- Canary Release -- 灰度发布 -- Staged Rollout - -## Core Mechanism - -> "Instead of flipping the switch for everyone simultaneously, roll out gradually." - -``` -1% 用户 → 观察错误率、性能指标 -5% 用户 → 监控转化率、用户反馈 -25% 用户 → 检查下游系统负载 -100% 用户 → 完成全量发布 -``` - -## Progressive Rollout vs. Big Bang Release - -| 维度 | Big Bang（全量发布） | Progressive Rollout（渐进式放量） | -|------|---------------------|----------------------------------| -| 影响范围 | 全部用户 | 受控小群体 | -| 问题发现 | 事后 | 事中（1% 阶段即可发现） | -| RTO（如果出问题） | 小时级（紧急回滚） | 秒级（关闭开关） | -| 回滚风险 | 可能丢失新事务 | 无数据损失 | -| 团队压力 | 高（2AM 部署） | 低（白天放量） | -| 反馈收集 | 事后分析 | 实时监控 | - -## RTO 重新定义 - -> "If something breaks at the 5% mark, you've contained the damage. Your RTO is measured in seconds (flip the flag off) instead of hours (emergency rollback deployment)." - -| 场景 | RTO（Big Bang） | RTO（Progressive Rollout） | -|------|-----------------|---------------------------| -| 发现问题 | 全量发布后 | 1% 阶段即可监控到 | -| 止血时间 | 小时级（回滚部署） | 秒级（关闭开关） | -| 受影响用户 | 100% | 最多 5%（当前阶段） | - -## 放量策略 - -### 基于用户群体的定向放量 - -| 策略 | 说明 | 适用场景 | -|------|------|----------| -| 随机抽样 | 随机选取 X% 用户 | 通用场景 | -| 地区定向 | 先在特定地区放量 | 法规合规、时区测试 | -| 用户分层 | 优先向付费用户放量 | 降低高价值用户风险 | -| 设备类型 | 先桌面后移动 | 移动端兼容性风险 | -| Beta 用户 | 先向内部/Beta 用户开放 | 需要早期反馈 | - -### 基于指标的自动 gates - -```yaml -rollout_stages: - - percentage: 1 - gates: - - error_rate < 0.1% - - p95_latency < 500ms - - percentage: 5 - gates: - - conversion_rate > baseline - 5% - - support_tickets < 10 - - percentage: 25 - gates: - - downstream_api_latency < 200ms - - no_critical_errors -``` - -## 与 [[Kill Switch]] 的关系 - -Progressive Rollout 和 Kill Switch 是同一机制的两面： - -- **Progressive Rollout**：控制功能如何到达用户（渐进式） -- **Kill Switch**：在发现问题时紧急切断（防御性） - -两者结合 → 既有渐进放量的可控性，又有 Kill Switch 的应急保障。 - -## 实践要点 - -1. **监控先行**：每次放量前确保监控仪表盘就绪 -2. **定义回退标准**：什么指标触发停止放量或回退？ -3. **自动化放量**：避免手动操作带来的错误 -4. **跨团队对齐**：产品、工程、运营需要共同定义放量节奏 - -## Related Concepts - -- [[Feature Flag]] — Progressive Rollout 的技术基础 -- [[Kill Switch]] — Progressive Rollout 的应急保障 -- [[RTO]] — Progressive Rollout 将 RTO 从小时降至秒级 -- [[Deployment-vs-Release]] — Progressive Rollout 实现部署与发布的解耦 -- [[Micro-Recovery]] — Progressive Rollout 支持 feature 级别的精准恢复 - -## Sources - -- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/concepts/Project-Management-Project-Shepherd.md b/wiki/concepts/Project-Management-Project-Shepherd.md deleted file mode 100644 index 23ce40d9..00000000 --- a/wiki/concepts/Project-Management-Project-Shepherd.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: "Project Shepherd" -type: concept -tags: ["project-management", "agency-agents"] -last_updated: 2026-05-06 ---- - -## Definition - -Project Shepherd 是 The Agency 项目管理体系中的**跨职能项目协调与利益相关方对齐专家 Agent**，专注于将复杂跨职能项目的混乱协调为按时、按范围交付的规范化流程。 - -## Aliases -- Project Shepherd Agent -- Project-Management-Project-Shepherd - -## Core Responsibilities - -1. **跨职能项目编排**：规划并执行涉及多团队和多部门的大型项目，制定综合时间线并进行依赖关系映射和关键路径分析 -2. **利益相关方对齐**：制定全面的利益相关方沟通策略，跨团队促进协作与冲突解决，在所有项目参与者中维护对齐 -3. **风险缓解**：识别并评估项目风险，制定全面的缓解计划，90% 的已识别风险在影响项目结果前被成功化解 -4. **质量交付保证**：为所有交付物建立质量门控和验收标准，监控项目健康状态并主动实施纠正措施 - -## Key Methodologies - -### 四阶段工作流 -1. 项目启动与规划 -2. 团队组建与 Kickoff -3. 执行协调与监控 -4. 质量保证与交付 - -### 关键交付物 -- **Project Charter**：包含问题陈述、项目目标、范围、成功标准、利益相关方分析、沟通计划、资源需求和风险评估 -- **Project Status Report**：绿/黄/红健康状态报告，包含执行摘要、进度更新、问题与风险、利益相关方行动 - -### 沟通原则 -- 透明报告（即使传递坏消息） -- 聚焦解决方案（上报即带推荐方案） -- 绝不承诺不切实际的时间线 - -## Success Metrics -- 95% 项目按时在批准预算内交付 -- 利益相关方满意度 4.5/5 -- 范围蔓延 < 10% -- 90% 已识别风险成功缓解 - -## Relationship with Other Agents - -| Agent | 关系 | 说明 | -|-------|------|------| -| [[ProjectManagerSenior]] | 协同 | Senior PM 产出详细任务列表，Project Shepherd 负责多团队协调执行 | -| [[Project-Management-Jira-Workflow-Steward]] | 协同 | Jira 工作流编排确保任务追踪与可见性 | -| [[Project-Management-Studio-Operations]] | 协同 | Studio Operations 提供运营支撑 | -| [[Project-Management-Experiment-Tracker]] | 支持 | 利用实验数据支持项目看护决策 | - -## Position in Agency Hierarchy - -属 Agency 项目管理体系中的**跨团队交付协调层级**： - -``` -Studio Producer（战略层） - ↓ -Senior PM（执行层任务分解） - ↓ -Project Shepherd（跨团队交付） - ↓ -Jira Workflow Steward（流程治理） - ↓ -Experiment Tracker（实验跟踪） -``` diff --git a/wiki/concepts/Project-Thor.md b/wiki/concepts/Project-Thor.md deleted file mode 100644 index ba67a1b6..00000000 --- a/wiki/concepts/Project-Thor.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: "Project Thor" -type: concept -tags: [Project-Thor, OpenText, Micro-Focus, Toolchain, Integration] -sources: - - public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20 - - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet -last_updated: 2026-05-11 ---- - -## Project Thor - -Project Thor 是 OpenText 推动 Micro Focus 和 OpenText 工具链整合的核心战略项目，以 GitLab 作为集中化源代码控制系统，整合构建、发布、安全和治理全链条工具。 - -## Overview - -Project Thor 的核心目标是将 Micro Focus 和 OpenText 的各类工具链统一为标准化平台，减少工具碎片化，提升供应链安全性和运维效率。 - -## 五大支柱框架 - -Project Thor 包含五大支柱（Five Pillars）： - -| 支柱 | 说明 | -|------|------| -| 敏捷周期治理 | 标准化开发流程和发布节奏 | -| 产品发布治理 | 统一发布审批和版本管理 | -| 开发者门户 Backstage | 开发者自助服务平台 | -| 安全与治理 | 安全扫描、合规审计、供应链安全 | -| Build Hub | 中心平台工程团队，管理核心构建工具 | - -## 核心数据流 - -``` -源代码（GitLab） - ↓ -制造流程（Build Farms） - ↓ -制品库（Artifactory） - ↓ -客户环境 -``` - -## 地理分布 - -| 站点 | 角色 | -|------|------| -| Brook Park | 工具链主站点 | -| Sacramento | 灾备站点 | - -## Key Quotes - -> "Project Thor aims to integrate Micro-Focus and OpenText tooling, with GitLab as the centralized system for source control." — [[Project-Thor]] 核心使命 - -## Connections - -- [[GitLab]] ← integrates ← [[Project-Thor]]（GitLab 是 Thor 的集中化源代码控制核心） -- [[Build-Hub]] ← implements ← [[Project-Thor]]（Build Hub 是五大支柱之一） -- [[PHT-Product-Hub-Platform]] ← part_of ← [[Project-Thor]] -- [[OpenText]] ← drives ← [[Project Thor]] - -## Sources - -- [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] -- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]] diff --git a/wiki/concepts/ProjectState.md b/wiki/concepts/ProjectState.md deleted file mode 100644 index e704babc..00000000 --- a/wiki/concepts/ProjectState.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Project State" -type: concept -tags: [project-management, automation, ai] -sources: [project-state-management] -last_updated: 2026-04-27 ---- - -## Definition - -项目状态（Project State）指一个项目在任意时间点的完整快照——包括当前阶段、活跃阻塞项、最近进展、以及完整的事件历史上下文。与传统项目管理工具中"当前状态"字段不同，项目状态由底层事件自动驱动更新，而非手动维护。 - -## What It Captures - -一个完整项目状态系统通常包含： - -- **基本元数据**：项目名称、当前阶段（phase）、总体状态（active/blocked/completed） -- **时间戳**：最后更新时间，便于判断项目是否"失活" -- **事件日志**：所有 progress/blocker/decision/pivot 事件的完整序列 -- **阻塞清单**：当前所有 open blockers 及创建时间 -- **上下文**：每次变更的决策理由，而非仅记录"变更了什么" - -## State Machine - -典型项目状态流转： - -``` -active → [blocked event] → blocked -blocked → [blocker resolved event] → active -active → [completion event] → completed -any → [pivot event] → active (new phase) -``` - -## Event-Driven vs Kanban - -| 维度 | 事件驱动项目状态 | 传统看板（Kanban）| -|------|---------------|----------------| -| 更新方式 | 自然语言对话自动驱动 | 手动拖拽卡片 | -| 状态来源 | 事件序列推导 | 卡片当前位置 | -| 历史保留 | 完整事件日志，可回溯决策原因 | 通常不保留，状态变更即丢失 | -| 上下文 | 每次变更附带决策理由 | 无，需额外备注 | -| 阻塞追踪 | 独立 blocker 记录 + 自动状态更新 | 卡片标签/泳道，依赖人工识别 | -| 团队协作 | 需要额外机制（如 Discord 多用户）| 原生支持多人实时协作 | -| 适合场景 | 个人/小团队，需要上下文保留 | 中大型团队，强协作需求 | - -## AI Integration - -在 [[Project State Management]] 系统中，AI Agent 承担以下角色： - -- **自然语言解析器**：将用户日常对话转换为结构化事件 -- **状态引擎**：根据事件类型自动更新项目状态 -- **查询接口**：回答"项目X现在什么状态"/"为什么做了Y决策" -- **报告生成器**：自动生成每日站会、每周总结 - -## Connections - -- **Project State** ← derived_from ← [[Event Sourcing]] -- **Project State** ← powered_by ← [[OpenClaw]] -- **Project State Management** ← uses ← **Project State** -- [[Kanban]] ← alternative_to ← **Project State**（冲突：参见 overview.md Conflict Area #1） diff --git a/wiki/concepts/PromQL.md b/wiki/concepts/PromQL.md deleted file mode 100644 index 3524cbe4..00000000 --- a/wiki/concepts/PromQL.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: "PromQL" -type: concept -aliases: [Prometheus Query Language, Prometheus查询语言] -tags: [prometheus, query, monitoring, time-series] -date: 2025-11-11 ---- - -# PromQL - -## Overview -PromQL（Prometheus Query Language）是 Prometheus 内置的时序数据查询语言，用于从 Prometheus TSDB 中检索和处理指标数据。它支持即时向量查询（返回当前时间点的样本）、范围向量查询（返回一段时间内的样本序列）、标量转换、聚合操作和丰富的函数库。 - -## Query Types - -### 即时向量查询（Instant Vector） -返回当前时刻的一组时间序列，每个序列只有一个样本值： -```promql -node_memory_MemAvailable_bytes -``` -### 范围向量查询（Range Vector） -返回一段时间内的样本序列，用于计算速率： -```promql -rate(node_cpu_seconds_total{mode="user"}[2m]) -``` -### 标量（Scalar） -没有时间序列的单个数值： -```promql -count(node_cpu_seconds_total) -``` - -## Aggregation Operators -PromQL 内置丰富的聚合操作符： -| 操作符 | 说明 | -|--------|------| -| `sum()` | 求和 | -| `avg()` | 平均值 | -| `min()` / `max()` | 最小/最大值 | -| `count()` | 计数 | -| `stddev()` / `stdvar()` | 标准差/方差 | -| `topk()` / `bottomk()` | 最大/最小的 k 个值 | -| `rate()` | 平均速率（适合 Counter） | -| `increase()` | 增量（适合 Counter） | -| `irate()` | 瞬时速率（适合快速变化指标） | - -## Common Patterns for Home Server Monitoring -```promql -# CPU 使用率（5分钟平均 > 85%） -avg(rate(node_cpu_seconds_total{mode="user"}[2m])) * 100 > 85 - -# 磁盘可用空间 < 10% -(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) < 0.10 - -# 内存可用率 < 15% -(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.15 - -# HTTP 探测失败（黑盒） -probe_success == 0 - -# TLS 证书剩余天数 < 14 天 -(probe_ssl_earliest_cert_expiry - time()) / 86400 < 14 - -# 容器重启次数 -increase(container_restart_count[5m]) > 0 -``` - -## Label Matchers -| Matcher | 说明 | -|---------|------| -| `=` | 精确匹配 | -| `!=` | 不等于 | -| `=~` | 正则匹配 | -| `!~` | 正则不匹配 | - -示例：`{job=~"node.*", mode!="idle"}` - -## Related Entities -- [[Prometheus]] — 查询引擎宿主 - -## Related Concepts -- [[Prometheus告警规则]] — 基于 PromQL 的告警条件 -- [[时序数据库]] — 数据模型基础 -- [[Exporter]] — 指标来源 diff --git a/wiki/concepts/Prometheus告警规则.md b/wiki/concepts/Prometheus告警规则.md deleted file mode 100644 index 86756373..00000000 --- a/wiki/concepts/Prometheus告警规则.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -title: "Prometheus告警规则" -type: concept -aliases: [Prometheus Alert Rules, Prometheus告警规则YAML, alert_rules] -tags: [prometheus, alerting, monitoring, devops, prometheus] -date: 2025-11-11 ---- - -# Prometheus告警规则 - -## Overview -Prometheus 告警规则（Alert Rules）是以 YAML 格式定义的告警条件，基于 PromQL 表达式判断指标状态。当表达式结果为真且持续超过 `for` 指定的评估周期数时，告警从 `pending` 状态转为 `firing` 状态，触发后发送给 Alertmanager 进行路由分发。 - -## Rule Format -```yaml -groups: -- name: # 告警组名称（全局唯一） - interval: # 评估间隔（可选，默认 evaluation_interval） - rules: - - alert: # 告警名称（Alertmanager 中唯一标识） - expr: # 触发条件的 PromQL 表达式 - for: # 持续时间（告警变为 firing 前需满足条件的最短时间） - labels: # 标签（用于 Alertmanager 路由和分类） - severity: # 如：critical / warning / info - annotations: # 注解（人类可读的告警描述） - summary: # 简短摘要 - description: # 详细描述，支持模板变量 -``` - -## Template Variables（注解模板） -在 `description` 中可以使用 `$labels` 和 `$value` 等模板变量： -```yaml -annotations: - description: "主机 {{ $labels.instance }} CPU 使用率超过 85%（当前值：{{ $value }}%）" -``` - -## Home Server Alert Rules（alerts.yml 完整示例） -```yaml -groups: -- name: system-alerts - rules: - - - alert: HostHighCPU - expr: avg(rate(node_cpu_seconds_total{mode="user"}[2m])) * 100 > 85 - for: 2m - labels: - severity: warning - annotations: - summary: "高 CPU 使用率" - description: "主机 CPU 使用率超过 85%（持续 2 分钟）" - - - alert: HostLowDisk - expr: (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) < 0.10 - for: 5m - labels: - severity: critical - annotations: - summary: "磁盘空间不足" - description: "磁盘剩余空间低于 10%" - - - alert: HostLowMemory - expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.15 - for: 5m - labels: - severity: warning - annotations: - summary: "内存使用率高" - description: "可用内存低于 15%" - - - alert: HTTPProbeFailed - expr: probe_success == 0 - for: 2m - labels: - severity: critical - annotations: - summary: "站点不可达" - description: "HTTP 探测失败：{{ $labels.instance }}" - - - alert: TLSCertExpiring - expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 14 - for: 1h - labels: - severity: warning - annotations: - summary: "TLS 证书即将到期" - description: "证书 {{ $labels.instance }} 剩余不到 14 天" -``` - -## Alert Lifecycle -``` -Inactive（正常）→ Pending（等待确认，for 计时中）→ Firing（触发，发送给 Alertmanager） -``` - -## Prometheus Configuration -```yaml -# prometheus.yml -rule_files: - - "/etc/prometheus/alerts.yml" - -alerting: - alertmanagers: - - static_configs: - - targets: ['alertmanager:9093'] - -global: - evaluation_interval: 30s # 告警规则评估间隔 -``` - -## Related Entities -- [[Prometheus]] — 告警引擎宿主 -- [[Alertmanager]] — 告警接收和分发 - -## Related Concepts -- [[PromQL]] — 告警条件的查询语言 -- [[Alertmanager]] — 告警分发机制 -- [[System Monitoring]] — 上游应用领域 diff --git a/wiki/concepts/Prompt-Engineering.md b/wiki/concepts/Prompt-Engineering.md deleted file mode 100644 index 1eb4480a..00000000 --- a/wiki/concepts/Prompt-Engineering.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "Prompt Engineering" -type: concept -tags: [generative-ai, llm, prompt, aws, amazon-bedrock] -sources: [public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111] -last_updated: 2026-05-12 ---- - -## Aliases -- 提示词工程 -- Prompt Design -- 提示工程 - -## Summary - -**Prompt Engineering**（提示词工程）是创建、设计和优化提示词（Prompt）以引导大语言模型（LLM）产生准确、相关输出的技术实践。它是一个迭代过程，需要针对具体用例反复测试和调整提示词。 - -## Key Properties - -- **类型**：方法 / 技术实践 -- **核心目标**：确保 LLM 输出的准确性和相关性 -- **过程性质**：迭代式（测试 → 调整 → 优化） - -## Prompt 四大组件 - -1. **指令（Instruction）**：明确告诉模型要执行什么任务 -2. **上下文（Context）**：提供背景信息，帮助模型理解场景 -3. **用户输入（User Input）**：具体的问题或请求 -4. **输出指示器（Output Indicator）**：指定期望的输出格式或风格 - -## 基础技巧 - -### One-shot Prompting（单样本提示） -- 提供一个示例，让模型理解任务模式 -- 适合简单、结构清晰的任务 - -### Few-shot Prompting（少样本提示） -- 提供 2~5 个示例，帮助模型理解多样性 -- 适合需要格式一致性但示例丰富的场景 - -### Chain-of-Thought（思维链） -- 在提示词中引导模型逐步思考 -- 提供 step-by-step 推理示例 -- 适合复杂推理和多步骤任务 - -## 最佳实践 - -- **清晰准确**：指令应具体、无歧义 -- **结构化**：使用明确的分隔符组织各组件 -- **考虑人类响应**：LLM 训练数据来自人类，因此提示词应符合人类沟通习惯 -- **迭代优化**：针对具体用例持续测试和调整 - -## Connections - -- 核心技术：[[GenerativeAI]]（LLM 是 Prompt Engineering 的载体） -- 应用平台：[[AmazonBedrock]]（Bedrock 上的基础模型均支持 Prompt Engineering） -- 相关工具：[[AmazonQ]]（Amazon Q Developer 利用 Prompt Engineering 优化代码生成） -- 相关概念：[[RAG从入门到精通系列1：基础RAG]]（RAG 系统中的 Prompt Engineering 是关键调优点） diff --git a/wiki/concepts/Prompt.md b/wiki/concepts/Prompt.md deleted file mode 100644 index e928c7e9..00000000 --- a/wiki/concepts/Prompt.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Prompt" -type: concept -tags: [prompt, llm, interaction] -aliases: [Prompt, 提示词, Prompt Engineering] -last_updated: 2025-12-20 ---- - -## Definition -Prompt，提示词，用户输入给大模型的语句。是与大模型交互的唯一入口。 - -## Key Facts -- Prompt 是用户与大模型之间的通信媒介 -- Prompt 的质量直接影响大模型的输出质量 -- Prompt Engineering（提示词工程）研究如何写出更有效的提示词 -- Zero-shot、Few-shot、Chain-of-Thought 等是常见的 Prompt 策略 - -## Connections -- [[Large Language Model]] ← 接收 ← [[Prompt]] -- [[Agent]] ← 使用 ← [[Prompt]] -- [[Large Language Model]] ← 指导 ← [[Prompt]] - -## Sources -- [[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]] diff --git a/wiki/concepts/Proof-Project-Strategy.md b/wiki/concepts/Proof-Project-Strategy.md deleted file mode 100644 index 871aaaad..00000000 --- a/wiki/concepts/Proof-Project-Strategy.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: "Proof-Project-Strategy" -type: concept -tags: [] -sources: [] -last_updated: 2026-05-30 ---- - -## 基本信息 -- **原文**：Proof Project（证明项目） -- **中文**：先导项目 / 概念验证项目 -- **英文**：Proof of Concept / POC / Scoping Project -- **韩国语境**：낮은 리스크 소규모 계약 - -## 定义 -Proof Project 策略是 Korean Business Navigator 提出的核心市场进入方法：当与新客户关系尚未建立信任时，通过一个有明确边界的小型付费项目来证明自身能力，用结果而非说服来推动完整的长期合作。 - -## 核心原则 - -> **"The proof project IS the sales pitch. Over-deliver deliberately."** -> （证明项目本身就是销售话术。刻意超额交付。） - -韩国客户不信任陌生供应商的口头承诺，但他们相信自己的眼睛。当他们在内部传阅你精心制作的交付物时，销售就已经完成了。 - -## 标准规格 - -| 维度 | 建议值 | -|------|--------| -| 时长 | 2-3 周 | -| 交付物 | 具体、可内部传阅、演示文稿级 | -| 价格 | 固定报价（相当于 2,000-3,000 EUR） | -| 框架 | "相互评估"：看我们是否合拍 | - -### 报价框架 -不要这样说： -> "这是我们的标准价格..." - -这样说： -> "我们建议先做一个小的试点项目，用2-3周时间交付XXX。我们认为这对我们双方都是了解对方工作方式的最好方式。您觉得怎么样？" - -## 五步执行流程 - -1. **提案有边界的 engagement** — 2-3 周、特定交付物、固定价格 -2. **框架为 mutual evaluation** — "让我们看看我们的工作风格是否合拍" 降低感知承诺风险 -3. **刻意超额交付 120%** — 韩国 Proof Project 就是销售演示，要做得超出预期 -4. **永远不要在 Proof Project 期间讨论完整 engagement 的价格** — 等他们看到结果后主动询问 -5. **文档化一切** — 韩国利益相关者会在内部传阅你的交付物，做成演示级质量 - -## 为什么对韩国市场特别重要 - -| 传统销售方法 | 在韩国的问题 | -|-------------|-------------| -| 大量说服和 Pitch | 韩国人不信任陌生人的口头承诺 | -| 尽快推进到合同 | 품의流程需要 6-16 周，强行加速破坏信任 | -| 强调资质和证书 | 韩国更看重实际交付和口碑 | -| 一次性大合同提案 | 感知风险高，内部审批难 | - -**Proof Project 降低了三个维度的感知风险：** -- **财务风险**：小金额，不影响年度预算 -- **技术风险**：特定领域，不涉及核心业务 -- **关系风险**："评估期"让双方都有退路 - -## Proof Project 信号分析 - -### 成功信号（应推进完整合同讨论） -- 联系人主动在内部传阅交付物 -- 被邀请参加第二阶段的회식 -- 联系人主动问你："那么，如果我们做完整项目呢？" -- 其他部门的人被邀请旁听交付 - -### 失败信号（不要强推） -- 联系人仅以"谢谢"回应，无后续跟进问题 -- 交付物未被引用或传阅 -- 联系人在会议中明显心不在焉 -- 没有被邀请参加任何非正式交流 - -## 与西方 POC 的区别 - -| 维度 | 西方 POC | 韩国 Proof Project | -|------|---------|-------------------| -| 目标 | 验证技术可行性 | 建立信任和人际关系 | -| 成功标准 | 技术指标达成 | 联系人是否主动推荐 | -| 后续 | 直接进入合同 | 需要在회식中确认关系深度 | -| 时间 | 1-4 周 | 2-3 周（不应太快） | -| 价格 | 可以很低甚至免费 | 必须收费（免费=无价值） | - -## 来源 -- [[specialized-korean-business-navigator]] — Proof Project Strategy 完整说明 diff --git a/wiki/concepts/Proof-of-Concept.md b/wiki/concepts/Proof-of-Concept.md deleted file mode 100644 index b03036a8..00000000 --- a/wiki/concepts/Proof-of-Concept.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "Proof of Concept" -type: concept -tags: [CTP, Cloud, AWS, POC] -sources: [ctp-topic-20-program-demand-process-flow-and-poc-onboarding] -last_updated: 2026-04-14 ---- - -## Definition - -概念验证（Proof of Concept, POC）是在正式云迁移前用于证明架构可行性、测试复杂网络需求及验证迁移方法的实验性阶段。是降低云迁移风险的核心手段。 - -## POC Objectives - -- **架构可行性验证**：确认目标云架构能够满足业务需求 -- **技术可行性测试**：验证复杂网络配置、依赖关系和集成点 -- **团队能力建设**：让团队熟悉基于 Gruntwork 的新一代 Landing Zone 环境 -- **风险识别**：在正式迁移前发现并解决潜在问题 -- **迁移方法验证**：验证数据迁移和应用迁移的具体方法 - -## POC vs 传统"经典落地分区" - -| 维度 | 传统方式 | 新一代 Landing Zone + POC | -|------|----------|---------------------------| -| 构建方式 | 手动构建 | IaC（Terraform/Terragrunt）自动化 | -| 可重复性 | 低 | 高（通过代码复用） | -| 环境一致性 | 难以保证 | 严格一致 | -| 文档化 | 分散 | 集中于 IaC 代码 | -| 审计追踪 | 困难 | Git 版本控制 | - -## POC Deliverables - -POC 阶段必须产出的关键交付物： - -- **解决方案设计文档**：经过 Design Authority 审批的架构设计 -- **IaC 脚本**：可用于正式部署的 Terraform/Terragrunt 配置 -- **迁移时间表**：明确的里程碑和交付日期 -- **成功标准验证报告**：证明产品已具备进入生产环境迁移的条件 - -## Success Criteria - -POC 成功标准必须在启动前明确定义，包括： - -- 技术可行性指标（架构满足需求） -- 性能指标（满足 NFR 定义的非功能性需求） -- 安全合规指标（通过安全评审） -- 团队能力指标（团队能够独立运维新环境） - -## Related Concepts - -- [[Program-Demand-Process]]：POC 是需求流程的关键验证环节 -- [[Gate-Process]]：POC 阶段受 Gate 1 Design Authority 审批约束 -- [[Solution-Design]]：POC 的核心产出物，需审批后方可进入迁移 -- [[Landing-Zone-Architecture]]：POC 部署的目标环境基础 -- [[Infrastructure-as-Code]]：新一代 Landing Zone 的核心技术手段 - -## References - -- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] diff --git a/wiki/concepts/Propp-Morphology.md b/wiki/concepts/Propp-Morphology.md deleted file mode 100644 index b9515e79..00000000 --- a/wiki/concepts/Propp-Morphology.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Propp 形态学" -type: concept -tags: [narratology, Russian-formalism, fairy-tale, Vladimir-Propp] -sources: ["academic-narratologist"] -last_updated: 2026-05-02 ---- - -## Definition - -**Propp 形态学**（Propp's Morphology），全称《民间故事形态学》（*Morphology of the Folktale*, 1928），由俄罗斯民俗学家 **Vladimir Propp** 提出，是俄罗斯形式主义最重要的叙事结构工具之一。 - -核心发现：尽管民间故事数量庞大，其叙事功能（Narrative Functions）的种类却是有限的——所有故事由**31种功能**（Functions）的不同组合构成，且功能出现的**顺序始终一致**。 - -## 31 种叙事功能（摘要） - -Propp 识别出 31 种叙事功能，以下是最核心的 8 种（全部按固定顺序出现）： - -1. **Initial Situation**（初始情境）：家庭成员介绍 -2. **Absentation**（离家）：主人公离开家园 -3. **Interdiction**（禁令）：对主人公的禁令（"不要..."） -4. **Violation**（违反）：禁令被打破 -5. **Villainy**（作恶）：反派造成伤害或缺失 -6. **Departure**（出发）：主人公离家寻找解决方案 -7. **Donor**（赠与者）：主人公遇到赠与者，获得魔法物品或帮助 -8. **Hero**（主人公）：主人公接受任务 -9. **Struggle**（斗争）：主人公与反派对决 -10. **Victory**（胜利）：反派被击败 -11. **Return**（归来）：主人公返回 -12. **Recognition**（认可）：主人公被认出 -13. **Exposition**（揭露）：伪装的敌人身份被揭露 - -### 角色类型（7种） - -| 角色 | 功能角色 | -|------|---------| -| **Villain**（反派） | 造成伤害/缺失 | -| **Donor**（赠与者） | 提供魔法物品或信息 | -| **Helper**（帮助者） | 帮助主人公完成旅程 | -| **Princess/Sought-For-Person**（公主/被寻找者） | 奖赏对象 + 被绑架对象 | -| **Dispatcher**（派遣者） | 发出任务 | -| **False Hero**（伪主人公） | 冒充英雄后被揭穿 | -| **Hero**（主人公） | 追求 + 回应挑战 | - -## Applications in AI Agent Design - -- [[academic-narratologist]] 使用 Propp 形态学分析**童话和冒险结构** -- 在[[Character-Arc]]诊断中，Donor 功能角色为"提供外部催化剂"提供了命名框架 -- 适用于：游戏叙事（任务系统）、互动小说、角色扮演场景设计 - -## Critical Notes - -- Propp 基于俄罗斯民间故事归纳，应用于其他文化叙事（如东亚叙事、印度史诗）需谨慎 -- 功能是**叙事功能**而非**角色属性**——同一个角色可以承担多个功能 -- 21世纪叙事学已超越 Propp，将其视为叙事可能性的**子集**而非**全集** - -## Related Concepts - -- [[Fabula-Sjuzhet]]：Propp 功能分析属于 fabula 层面的研究 -- [[Campbell-Monomyth]]：Hero's Journey 与 Propp 形态学有功能重叠，但适用范围不同 -- [[Character-Arc]]：Donor/Hero 角色类型的现代弧光分析延伸 diff --git a/wiki/concepts/ProppMorphology.md b/wiki/concepts/ProppMorphology.md deleted file mode 100644 index 44e622d3..00000000 --- a/wiki/concepts/ProppMorphology.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "Propp's Morphology" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-30 ---- - -## Aliases -- Propp's Morphology -- Propp's Narrative Functions -- Morphology of the Folktale -- Propp 功能分析 -- 普罗普形态学 - -## Overview -Propp's Morphology（[[Vladimir Propp]] 的叙事形态学）是对民间故事结构的系统性形式化分析。通过对俄罗斯民间故事的归纳，Propp 发现尽管故事角色和情境各异，但其 **31 种叙事功能（Functions）** 按固定顺序在故事中出现。 - -## The 31 Functions -按出现顺序（部分关键功能）： -1. **Absentation**：家庭成员离开 -2. **Interdiction**：禁止/警告 -3. **Violation**：禁止被打破 -4. **Villainy/Lack**：对手作恶或英雄缺乏某物 -5. **Departure**：英雄出发 -6. **Donation**：供者给予魔法物品 -7. **Test**：英雄被测试 -8. **Reaction**：英雄应对测试 -9. **Receipt of Magic Agent**：英雄获得魔法物品 -10. **Guidance**：被送往目标 -11. **Struggle**：与反派斗争 -12. **Branding/Spongification**：英雄被标记或变形 -13. **Victory**：反派被击败 -14. **Return**：英雄归来 -15. **Pursuit/Chase**：被追赶 -16. **Rescue**：获救 -17. **Unrecognized Arrival**：英雄以伪装到达 -18. **False Hero Claim**：假英雄声称功劳 -19. **Difficult Task**：设置难题 -20. **Solution**：难题被解决 -21. **Recognition**：英雄被认出 -22. **Exposure**：假英雄/反派被揭露 -23. **Transfiguration**：英雄获新外貌 -24. **Punishment**：反派被惩罚 -25. **Wedding**：英雄与公主结婚/获得奖赏 - -## 7 Character Types -| Type | Role | -|------|------| -| Hero | 追求目标的人 | -| Donor | 提供魔法物品或信息 | -| Helper | 协助英雄 | -| Princess | 被解救/奖励 | -| Princess's Father | 国王/权威 | -| Villain | 反派/对立力量 | -| False Hero | 冒名顶替者 | - -## Application -[[Academic Narratologist]] 使用此框架分析童话、quest 类游戏和冒险叙事的结构模式。 - -## Relationship to Other Concepts -- [[HeroesJourney]]：Propp 是 Hero's Journey 的学术前身，两者有重叠（Departure, Test, Victory, Return） -- [[Three-Act-Structure]]：功能序列可以映射到三幕（Setup → Confrontation → Resolution） diff --git a/wiki/concepts/Proxy-Editing.md b/wiki/concepts/Proxy-Editing.md deleted file mode 100644 index fb581f2a..00000000 --- a/wiki/concepts/Proxy-Editing.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Proxy Editing" -type: concept -tags: [video-editing, workflow, 4K, efficiency] -sources: [marketing-short-video-editing-coach] -last_updated: 2026-04-26 ---- - -## Aliases -- 代理编辑 -- Proxy Workflow -- 中间片编辑 -- Offline Editing - -## Definition -代理编辑（Proxy Editing）是从高分辨率素材（4K/6K/8K）生成低分辨率代理文件进行剪辑编辑，最终导出前再重新链接回原始高质量文件的剪辑工作流程。是处理高分辨率素材的**必备技术**，而非可选项。 - -## Why It Matters -- **性能问题**：在时间线上直接编辑 4K+ 原始素材会导致严重卡顿和渲染延迟 -- **代理编辑流程**：生成低分辨率代理（通常 720p 或 1080p）→ 在代理文件上完成所有剪辑 → 最终导出前 relink 回原始文件 → 输出高质量成片 - -## Implementation -- **DaVinci Resolve**：原生支持代理模式，自动生成和管理代理文件 -- **Premiere Pro**：Media Encoder 可批量生成代理 -- **Final Cut Pro**：代理编辑原生支持，M 系列芯片性能出色 -- **CapCut Pro**：在处理高分辨率素材时也可启用代理模式 - -## Key Principle -> "Proxy editing isn't optional, it's mandatory - the lag from editing 4K raw on the timeline is pure wasted time" - -代理编辑不是可选项，而是**必须项**——在时间线上卡顿所浪费的时间是纯粹的无谓损耗。 - -## Related Concepts -- [[Template-Based-Production]]：Proxy Editing 与模板化生产共同构成高效剪辑工作流的基础设施 -- [[marketing-short-video-editing-coach]] ← Proxy Editing 是剪辑效率章节的核心推荐技术 - -## Source -[[marketing-short-video-editing-coach]] diff --git a/wiki/concepts/PsychodynamicDefenseMechanisms.md b/wiki/concepts/PsychodynamicDefenseMechanisms.md deleted file mode 100644 index 088c62e4..00000000 --- a/wiki/concepts/PsychodynamicDefenseMechanisms.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Psychodynamic Defense Mechanisms" -type: concept -tags: [] -sources: [academic-psychologist] -last_updated: 2026-04-25 ---- - -# Psychodynamic Defense Mechanisms - -## Aliases -- Defense Mechanisms -- Vaillant's Defense Mechanism Hierarchy -- Ego Defense Mechanisms - -## Definition -Vaillant 防御机制层级——个体在应对焦虑和压力时无意识使用的心理策略，按成熟度从低到高排列。 - -## Vaillant's Hierarchy of Defense Mechanisms - -### Level 1: Pathological（病理性） -- **Denial**（否认）：拒绝承认现实 -- **Projection**（投射）：把自己的感受归于他人 -- **Acting Out**（行为过度表达）：通过行为而非语言表达无意识冲动 - -### Level 2: Immature（不成熟） -- **Fantasy**（幻想）：通过白日梦逃避现实 -- **Passive Aggression**（被动攻击）：通过拖延/沉默表达敌意 -- **Dissociation**（解离）：切断自我感知的连续性 - -### Level 3: Neurotic（神经症性） -- **Intellectualization**（理智化）：用理性分析代替情感体验 -- **Rationalization**（合理化）：为不合理行为找合理解释 -- **Reaction Formation**（反向形成）：感受与行为相反 - -### Level 4: Mature（成熟） -- **Humor**（幽默）：用幽默化解痛苦 -- **Altruism**（利他）：通过帮助他人获得满足感 -- **Sublimation**（升华）：将冲动转化为社会认可的活动 -- **Suppression**（压抑）：有意识地延迟处理不适情绪 - -## Application in Character Design -Psychologist Agent 在评估角色时，标注**Primary（主要）**和**Under Stress（压力下）**两个层级的防御机制，后者体现为退行到更低层级。 - -## Connection to Wiki -- Source: [[academic-psychologist]] diff --git a/wiki/concepts/Public-Cloud.md b/wiki/concepts/Public-Cloud.md deleted file mode 100644 index c27d1204..00000000 --- a/wiki/concepts/Public-Cloud.md +++ /dev/null @@ -1,129 +0,0 @@ -# Public Cloud - -> **Public Cloud** — 公有云是通过互联网交付、由第三方提供商同时为多个组织（多租户）提供计算资源（服务器、存储、应用）的云服务模式。用户按需付费，无需前期硬件投入。 - -## Definition - -公有云（Public Cloud）由第三方云服务提供商（如 AWS、Azure、GCP）通过公共互联网向所有用户提供共享的云基础设施和服务。所有资源在提供商的数据中心中运行，多个租户共享同一物理基础设施，但通过虚拟化技术实现逻辑隔离。 - -## Key Characteristics - -| 特征 | 描述 | -|------|------| -| **多租户共享** | 多个组织共享底层物理资源，通过虚拟化隔离 | -| **按需付费** | Pay-as-you-go 定价，根据实际消耗计费 | -| **弹性扩展** | 快速扩展或收缩资源，无需硬件采购 | -| **即服务交付** | IaaS / PaaS / SaaS 三层服务模型 | -| **供应商管理** | 提供商负责硬件维护、安全更新、容量规划 | - -## Deployment Model - -``` -用户终端 (PC/平板/手机) - ↓ - 互联网 - ↓ -┌─────────────────────────────────┐ -│ 云服务提供商数据中心 │ -│ ┌─────┐ ┌─────┐ ┌─────┐ │ -│ │租户A│ │租户B│ │租户C│ ... │ ← 多租户共享 -│ └─────┘ └─────┘ └─────┘ │ -│ │ -│ 虚拟化层（VM/容器） │ -│ 物理服务器集群 │ -└─────────────────────────────────┘ -``` - -## Advantages - -### 1. 无前期资本投入 (CapEx → OpEx) -- 无需采购和维护IT基础设施 -- 将资本支出转换为运营支出 -- 降低初始投资风险 - -### 2. 技术敏捷性 -- 高弹性和灵活性，应对不可预测的工作负载 -- 快速部署新服务和应用 -- 访问最新技术和版本 - -### 3. 全球可访问性 -- 任何有互联网连接的地方均可访问 -- 支持远程办公和分布式团队协作 -- 跨地域快速扩张 - -### 4. 专业管理与运维 -- 提供商负责硬件维护和更新 -- 始终运行在最新、正确配置的硬件上 -- 减少内部IT团队压力 - -### 5. 成本效率 -- 仅支付实际使用的资源 -- 灵活定价选项适应不同SLA需求 -- 支持精益增长战略 - -### 6. 快速灾难恢复 -- 数据和应用定期备份并存放在多个地理位置 -- 最小化数据丢失风险 -- 确保业务连续性 - -## Drawbacks - -### 1. 缺乏成本控制 -- 大规模使用时总拥有成本 (TCO) 可能指数增长 -- 对中大型企业尤为明显 -- 需要 FinOps 实践控制成本 - -### 2. 安全性较低 -- 多租户共享环境存在潜在安全风险 -- 不适合敏感和关键任务的IT工作负载 -- 合规性控制可能不足 - -### 3. 技术控制有限 -- 对基础设施的可见性和控制度低 -- 可能无法满足特定合规需求 -- 定制化能力受限 - -### 4. 供应商依赖 -- 更换供应商的数据和服务迁移复杂且成本高昂 -- 可能被锁定在单一提供商 -- 议价能力受限 - -## When to Use Public Cloud - -| 场景 | 说明 | -|------|------| -| **可预测的计算需求** | 通信服务、固定的业务运营应用 | -| **IT和业务运营必需的应用** | 核心业务系统 | -| **应对峰值负载** | 季节性流量波动、促销活动 | -| **软件开发与测试** | 快速创建和销毁测试环境 | -| **短期的特定项目** | 避免长期硬件投资 | - -## TCO Comparison - -| 成本维度 | 公有云 | 本地私有 | -|----------|--------|---------| -| 前期资本投入 | 低 | 高 | -| 扩展成本 | 边际成本低 | 需要新硬件采购 | -| 维护成本 | 提供商承担 | 内部承担 | -| 人员成本 | 较低 | 需要专职团队 | -| 峰值容量规划 | 自动弹性 | 需要过度配置 | - -## Related Concepts - -- [[Private Cloud]] — 私有云部署模式对比 -- [[Hybrid Cloud]] — 混合云结合公私优势 -- [[Multi-Cloud Strategy]] — 多云避免锁定 -- [[FinOps]] — 云成本管理 -- [[Cloud Security]] — 云安全 -- [[CapEx-vs-OpEx]] — 资本支出 vs 运营支出 -- [[Cloud Elasticity]] — 云弹性 -- [[SLA]] — 服务级别协议 -- [[Cloud Migration]] — 云迁移 -- [[Vendor-Lock-In]] — 供应商锁定风险 - -## See Also - -- [[Cloud Computing]] — 云计算基础（实体页面） -- [[Cloud-Adoption-Strategy]] — 云采用策略 -- [[Cloud-Maturity-Model]] — 云成熟度模型 -- [[Shared-Responsibility-Model]] — 共享责任模型 diff --git a/wiki/concepts/Pull-Request-Governance.md b/wiki/concepts/Pull-Request-Governance.md deleted file mode 100644 index e549d5a7..00000000 --- a/wiki/concepts/Pull-Request-Governance.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Pull Request Governance" -type: concept -tags: ["git", "code-review", "workflow", "delivery-traceability"] -last_updated: 2026-04-25 ---- - -## Definition - -Pull Request Governance（PR 治理）是通过标准化 PR 模板、安全审查要求、风险记录和强制审查流程，保护分支合并质量的工作流规范。 - -## Mandatory PR Scenarios - -以下场景的合并**必须**经过 PR review： -- 合并到 `main` -- 合并到 `release/*` -- 大型重构 -- 关键基础设施变更 -- 认证、授权、基础设施、敏感数据处理相关变更 - -## PR Template Structure - -标准 PR 模板包含： - -```markdown -## What does this PR do? -Implements **JIRA-214** by adding the SSO login flow... - -## Jira Link -- Ticket: JIRA-214 -- Branch: feature/JIRA-214-add-sso-login - -## Change Summary -- Add SSO callback controller and provider wiring -- Add regression coverage for expired refresh tokens -- Document the new login setup path - -## Risk and Security Review -- Auth flow touched: yes -- Secret handling changed: no -- Rollback plan: revert the branch and disable the provider flag - -## Testing -- Unit tests: passed -- Integration tests: passed in staging -- Manual verification: login and logout flow verified in staging -``` - -## Security Discipline - -- **No secrets in PR**：凭证、token、客户数据严禁出现在 PR 标题、描述或 diff 中 -- **Explicit validation scope**：明确说明哪些环节经过测试、哪些未经测试 -- **Security review mandatory**：认证、授权、基础设施、敏感数据处理变更必须经过安全审查 - -## Rollback Readiness - -每个 PR 必须包含回滚计划，确保回滚操作低风险、低影响。 - -## Sources -- [[project-management-jira-workflow-steward]] diff --git a/wiki/concepts/Purpose-Built-Databases.md b/wiki/concepts/Purpose-Built-Databases.md deleted file mode 100644 index 608bbcc7..00000000 --- a/wiki/concepts/Purpose-Built-Databases.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Purpose-Built Databases" -type: concept -tags: - - AWS - - Database - - Architecture - - Multi-Model -sources: - - ctp-topic-51-architecting-with-aws-purpose-built-databases -last_updated: 2026-04-28 ---- - -## Overview -专用数据库（Purpose-Built Databases）是一种架构理念：针对不同的数据模型、访问模式和性能需求，选择专门优化的数据库，而非用单一通用数据库解决所有问题。 - -## Core Principle -> "为正确的应用选择正确的专用数据库" — Femi George, AWS Database Sales Specialist - -## AWS Database Categories - -| 类别 | AWS 服务 | 适用场景 | -|------|----------|----------| -| 关系型 | RDS, Aurora | 固定 schema，引用完整性，ACID 事务 | -| 键值 | DynamoDB | 高并发，任意规模，低延迟 | -| 文档 | DocumentDB (MongoDB兼容) | 灵活 schema，嵌套 JSON | -| 宽列 | Keyspaces (Cassandra兼容) | 大规模写入，结构化/半结构化 | -| 内存缓存 | ElastiCache (Redis/Memcached) | 毫秒级响应，会话/排行榜 | -| 图数据库 | Neptune | 复杂关系，欺诈检测，推荐 | -| 时序数据库 | Timestream | IoT/监控，高吞吐量时序数据 | -| 账本数据库 | QLDB | 不可变事务记录，审计日志 | - -## Selection Criteria -选择专用数据库时需考虑： -- **应用规模**：用户量、数据量、请求量 -- **访问模式**：读写比例、查询复杂度、延迟要求 -- **数据模型**：结构化/半结构化/非结构化 -- **一致性需求**：强一致性 vs 最终一致性 -- **运维能力**：团队数据库管理能力 -- **成本模型**：按查询/存储/实例计费 - -## Why Not One-Size-Fits-All? -- 传统单一关系型数据库在所有场景下存在性能瓶颈 -- NoSQL 牺牲强一致性换取扩展性和性能 -- 不同数据模型（文档/图/时序）有最优专用引擎 -- 现代微服务架构天然支持多数据库混用 - -## Connections -- [[Multi-Database-Architecture]]：专用数据库理念的直接实践形式 -- [[Amazon-Aurora]] / [[Amazon-DynamoDB]] / [[Amazon-ElastiCache]] 等：AWS 专用数据库品类中的具体产品 -- [[DBA-Role-Evolution]]：专用数据库多样化增加了 DBA 的选型职责 - -## Referenced In -- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]] diff --git a/wiki/concepts/Qualitative-Quantitative-Research.md b/wiki/concepts/Qualitative-Quantitative-Research.md deleted file mode 100644 index c2be868e..00000000 --- a/wiki/concepts/Qualitative-Quantitative-Research.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "Qualitative-Quantitative Research" -type: concept -tags: [ux, research, qualitative, quantitative, mixed-methods] -sources: [design-ux-researcher.md] -last_updated: 2026-04-24 ---- - -## Definition - -定性定量混合研究方法——定性研究（访谈/观察/开放式问卷）用于探索性理解用户为什么这么想、这么做；定量研究（结构化问卷/A/B测试/行为分析）用于验证假设并获得统计显著性结论。两者互补，是 UX Researcher Agent 默认采用的研究策略。 - -## Comparison - -| 维度 | 定性研究 | 定量研究 | -|------|---------|---------| -| 数据形式 | 文字/语言/观察笔记 | 数字/百分比/统计数据 | -| 样本量 | 小（5-20人） | 大（100+人） | -| 结论类型 | 深度理解/洞察 | 统计显著性/可推广性 | -| 适用问题 | "为什么" | "有多少/多大程度" | -| 方法示例 | 深度访谈、可用性测试、焦点小组 | 结构化问卷、A/B测试、行为数据分析 | - -## Relationship to Other Concepts - -- [[User-Research-Methodology]]：混合方法是研究方法论的核心组成部分 -- [[Research-Triangulation]]：定性+定量本身就是三角验证的一种形式 -- [[Behavioral-Analytics]]：定量研究在数字产品中的具体应用 - -## Source - -- [[design-ux-researcher.md]] — UX Researcher Agent Personality diff --git a/wiki/concepts/Quality-Gate.md b/wiki/concepts/Quality-Gate.md deleted file mode 100644 index 59fa3d52..00000000 --- a/wiki/concepts/Quality-Gate.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Quality Gate Checklist" -type: concept -tags: [quality, gate, process, NEXUS] -last_updated: 2026-05-01 ---- - -## Definition - -Quality Gate（质量门控）是 NEXUS 多 Agent 框架中每个阶段（Phase）结束时必须通过的强制性质量检查站。在证据提交前，任何后续阶段不得启动。 - -## 核心机制 - -- **[[Dual Sign-Off]]**：必须由两类 Gate Keeper **同时**批准，方可放行进入下一阶段 - - **战略 Gate**（Studio Producer）：验证产出是否符合业务目标和投资回报预期 - - **技术 Gate**（Reality Checker）：验证产出是否具备可部署到生产环境的技术质量 -- **[[Evidence Over Claims]]**：Gate Keeper 不接受口头断言，只接受截图、测试结果、日志等可验证证据 - -## Phase 1 Quality Gate Checklist（7项） - -| # | 检查项 | 证据来源 | 验证方法 | -|---|--------|---------|---------| -| 1 | 架构覆盖 100% 规范需求 | Senior PM 任务列表与架构交叉引用 | 需求→架构映射检查 | -| 2 | 品牌系统完整（Logo/颜色/字体/声音） | Brand Guardian 交付物 | 交付物完整性审核 | -| 3 | 所有技术组件均有实现路径 | Backend Architect + UX Architect 规格 | 路径可行性评审 | -| 4 | 预算审批且在约束范围内 | Finance Tracker 计划 | 预算对比分析 | -| 5 | Sprint 计划基于速度估算且现实 | Sprint Prioritizer backlog | 速度基准验证 | -| 6 | 安全架构已定义 | Backend Architect 安全规格 | 安全设计审查 | -| 7 | 合规要求已映射到技术决策 | Legal 需求映射到架构 | 合规性检查 | - -## 决策类型 - -| 决策 | 条件 | 后续动作 | -|------|------|---------| -| **APPROVED** | Dual Sign-Off 均通过 | 进入下一 Phase | -| **REVISE** | 部分检查项未通过 | 返回对应 Step 修复，2天内重审 | -| **RESTRUCTURE** | 基础架构存在根本性问题 | 重启本 Phase | - -## 与 Dev-QA Loop 的关系 - -Quality Gate 是**阶段间**的纵向质量门控；Dev-QA Loop 是**阶段内**的横向质量循环。两者独立运行，不可互相替代。 - -## Aliases -- Phase Gate -- Quality Gate Checklist -- NEXUS Quality Gate diff --git a/wiki/concepts/Quality-Metrics.md b/wiki/concepts/Quality-Metrics.md deleted file mode 100644 index 5ca8e5f8..00000000 --- a/wiki/concepts/Quality-Metrics.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Quality Metrics" -type: concept -tags: [testing, quality, metrics] -sources: [testing-test-results-analyzer] -last_updated: 2026-04-28 ---- - -## Aliases -- Software Quality Metrics -- Quality Indicators -- Defect Density -- Test Effectiveness Metrics - -## Definition - -软件质量量化指标体系——通过可测量的数值指标评估软件质量状态、跟踪质量趋势并指导质量改进决策。 - -## Core Metrics - -| 指标 | 计算方式 | 阈值参考 | -|------|---------|---------| -| 缺陷密度 (Defect Density) | 缺陷数 / 代码行数 (KLOC) | 行业平均 1-5/KLOC | -| 测试覆盖率 (Test Coverage) | 已测代码行 / 总代码行 | 目标 ≥80% | -| 测试通过率 (Pass Rate) | 通过用例数 / 总用例数 | 目标 ≥95% | -| 缺陷逃逸率 (Defect Escape Rate) | 生产缺陷数 / 总缺陷数 | 越低越好 | -| 平均修复时间 (MTTR) | 总修复时间 / 缺陷数 | 越短越好 | - -## Key Methods - -- **DRE (Defect Removal Efficiency)**：在发布前移除的缺陷占总缺陷的比例，DRE 越高发布质量越好。 -- **Reliability Growth Modeling**：使用模型（如 Goel-Okumoto）预测缺陷发现趋势。 -- **Quality Trend Analysis**：跨版本跟踪核心指标，识别质量恶化或改善趋势。 - -## Connections - -- [[Test-Coverage-Analysis]]：覆盖率是质量指标体系的核心组成部分。 -- [[Release-Readiness-Assessment]]：多维度质量指标综合决定发布就绪度。 -- [[Defect-Prediction]]：缺陷预测模型基于历史质量指标训练。 -- [[Statistical-Analysis]]：所有指标计算必须附带置信区间。 diff --git a/wiki/concepts/Quality-ROI-Analysis.md b/wiki/concepts/Quality-ROI-Analysis.md deleted file mode 100644 index 32ca8376..00000000 --- a/wiki/concepts/Quality-ROI-Analysis.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Quality ROI Analysis" -type: concept -tags: [quality, business-value, roi] -sources: [testing-test-results-analyzer] -last_updated: 2026-04-28 ---- - -## Aliases -- Quality Investment Return -- Cost of Quality -- Quality Value Analysis - -## Definition - -质量投资回报分析——量化质量改进投入的成本与收益，通过财务指标指导质量投资决策，证明质量投资的商业价值。 - -## Framework (from TestResultsAnalyzer) - -### Quality Investment Cost Components - -| 成本类型 | 说明 | 示例 | -|---------|------|------| -| 预防成本 | 预防缺陷发生的投入 | 自动化测试、代码审查工具 | -| 检测成本 | 发现现有缺陷的投入 | 测试基础设施、CI/CD | -| 内部失败成本 | 发布前修复缺陷的成本 | Bug 修复工时 | -| 外部失败成本 | 生产环境缺陷的成本 | 客户投诉、数据泄露、声誉损失 | - -### ROI Formula - -``` -Quality ROI = (预防的失败成本 - 质量投入成本) / 质量投入成本 × 100% -``` - -### Key Insight - -> "Quality investment of $50K prevents estimated $300K in production defect costs" — TestResultsAnalyzer Agent - -即：每投入 $1 在质量改进上，可避免约 $6 的生产缺陷损失。 - -## Key Methods - -- **Cost of Poor Quality (COPQ)**：量化低质量造成的全部成本。 -- **Defect Prevention Value**：估算通过早期检测避免的生产缺陷成本。 -- **Quality Investment Prioritization**：按 ROI 高低排序质量改进项目。 - -## Connections - -- [[Quality-Metrics]]：ROI 分析依赖质量指标的实际数据。 -- [[Statistical-Analysis]]：成本估算和置信区间需要统计方法。 -- [[Release-Readiness-Assessment]]：质量债务是发布就绪度的重要考量。 -- [[Defect-Prediction]]：预测的缺陷高发区域是优先质量投资目标。 diff --git a/wiki/concepts/Quality-Scoring-Algorithm.md b/wiki/concepts/Quality-Scoring-Algorithm.md deleted file mode 100644 index b748a97e..00000000 --- a/wiki/concepts/Quality-Scoring-Algorithm.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Quality Scoring Algorithm" -type: concept -tags: [] ---- - -## Definition -多维度加权评分算法——通过 priority source（优先级来源）、multi-source（多源交叉验证）、recency（时效性）和 engagement（互动量）四个维度对内容进行加权评分，过滤噪音提升信息价值。 - -## Formula -``` -score = priority_source(×3) + multi_source(×5) + recency(×2) + engagement(×1) -``` - -## Dimensions -| 维度 | 权重 | 说明 | -|------|------|------| -| priority_source | +3 | 高质量来源（如 OpenAI Blog、Hacker News） | -| multi_source | +5 | 多源同时报道同一事件 | -| recency | +2 | 发布时间距现在越近分数越高 | -| engagement | +1 | 社交媒体互动量（点赞/转发/评论） | - -## Use Cases -- [[multi-source-tech-news-digest]] — 科技新闻质量评分 -- 任何需要从大量来源中筛选高价值内容的场景 - -## Related Concepts -- [[Semantic-Deduplication]] — 与评分算法配合，先去重再评分 -- [[Daily-Digest]] — 评分结果最终投递为每日简报 diff --git a/wiki/concepts/Quality-Scoring.md b/wiki/concepts/Quality-Scoring.md deleted file mode 100644 index fdc483df..00000000 --- a/wiki/concepts/Quality-Scoring.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "Quality-Scoring" -type: concept -tags: [Ranking, Filtering, AI-Processing] -sources: [multi-source-tech-news-digest.md] -last_updated: 2026-04-27 ---- - -# Quality-Scoring - -质量评分——对聚合内容按多维度指标打分，以优先级排序的机制，解决信息过载下的内容筛选问题。 - -## Definition - -通过预设规则或 AI 辅助，对每条内容从多个维度赋予分值（如权威性、时效性、相关性、互动量），综合计算后决定内容的展示优先级。 - -## Scoring Dimensions - -| 维度 | 示例 | 分值范围 | -|------|------|----------| -| 优先级来源 | 权威媒体/KOL/官方账号 | +1 ~ +5 | -| 多来源交叉 | 同一内容被多个来源报道 | +3 ~ +5 | -| 时效性 | 距发布时间越近分数越高 | +1 ~ +3 | -| 互动量 | 点赞/评论/分享数 | +1 ~ +2 | - -## Related Concepts - -- [[Content-Aggregation]]：质量评分作用于聚合后的内容 -- [[Content-Deduplication]]：去重是评分的前置步骤 -- [[RAG]]：RAG 中的 reranking 与质量评分思路类似 diff --git a/wiki/concepts/QualityAdjustedCoverage.md b/wiki/concepts/QualityAdjustedCoverage.md deleted file mode 100644 index fb4da09f..00000000 --- a/wiki/concepts/QualityAdjustedCoverage.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Quality Adjusted Coverage" -type: concept -tags: [revenue-operations, pipeline, forecasting, metrics] -last_updated: 2026-04-25 ---- - -## Definition -质量调整后的 Pipeline 覆盖度，在标准 Pipeline 覆盖度（加权 Pipeline / 剩余配额）基础上，结合 Deal 健康评分、阶段年龄和互动信号进行折减，提供更真实的收入预测基础。 - -## Core Principle -> "A $5M pipeline with 20 stale, poorly qualified deals is worth less than a $2M pipeline with 8 active, well-qualified opportunities. Pipeline quality always beats pipeline quantity." -> （$5M 包含 20 个陈旧、资格不足 Deal 的 Pipeline，价值低于 $2M 含 8 个活跃、充分资格 Deal 的 Pipeline。Pipeline 质量永远优于 Pipeline 数量。） - -## Target Coverage Ratios - -| 业务类型 | 目标覆盖比率 | -|---------|------------| -| 成熟可预测业务 | 3x | -| 成长期或新市场 | 4-5x | -| 新销售入职期 | 5x+（预期胜率较低） | - -## Adjustment Factors - -| 因素 | 折减逻辑 | -|------|---------| -| Deal 健康评分 | 综合 [[DealHealthScoring]] 低分 Deal 打折 | -| 阶段年龄 | 超出基准阶段时长的 Deal 降低权重 | -| 互动信号 | 长时间无活动、利益相关者单一的 Deal 降低权重 | - -## Why It Matters -- 裸覆盖度比率会产生**虚假信心**——看起来达到 3x 但实际上可能只有 1.5x 有效 -- Pipeline 质量调整是 [[SalesPipelineAnalyst]] 预测方法论的核心 -- 揭示表面良好数字掩盖下的真实风险 - -## Connections -- [[DealHealthScoring]] — 直接提供评分数据用于折减 -- [[PipelineVelocity]] — 覆盖度分析依赖 Velocity 指标 -- [[SalesPipelineAnalyst]] — Pipeline Analyst Agent 使用此指标生成质量调整覆盖度报告 diff --git a/wiki/concepts/QualityGate.md b/wiki/concepts/QualityGate.md deleted file mode 100644 index e899eab4..00000000 --- a/wiki/concepts/QualityGate.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Quality Gate" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-30 ---- - -## Aliases -- Quality Gates -- 质量门控 - -## Definition -在关键里程碑节点设置的强制性审查机制——只有满足预设标准，才能进入下一阶段。 - -## Mechanism -- **触发时机**：中期（第2周）、发布前（第4周） -- **审查内容**：可行性评估、范围裁剪建议、技术债务风险 -- **决策输出**：GO / NO-GO + 证据要求 - -## Key Examples -- [[workflow-startup-mvp]]：Reality Checker 在第 2 周和第 4 周各设一次 Quality Gate -- [[testing-reality-checker]]：测试阶段 Reality Checker 评估生产就绪状态 - -## Related Concepts -- [[Sequential Handoff]] — 交接是 Gate 之间的连接机制 -- [[Reality Checker]] — Quality Gate 的执行 Agent diff --git a/wiki/concepts/QualitySwitch.md b/wiki/concepts/QualitySwitch.md deleted file mode 100644 index 718db58e..00000000 --- a/wiki/concepts/QualitySwitch.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "QualitySwitch" -type: concept -tags: ["unreal-engine", "materials", "performance-optimization", "platform-targeting"] -sources: ["unreal-technical-artist"] -last_updated: 2026-04-26 ---- - -## Definition -UE5 Material Editor 中的 Quality Switch 节点，允许在单一材质图内定义多档质量层级（Mobile / Console / PC），引擎根据目标平台自动选择对应分支。 - -## Quality Tiers -- **High**：PC/主机高端 — 完整着色器逻辑，所有纹理层 -- **Medium**：主机基准/中端 PC — 简化逻辑，较低纹理分辨率 -- **Low**：移动设备/主机性能模式 — 最简化逻辑，单一纹理层 - -## Key Principles -- 在单个材质图中而非多个材质文件中管理质量差异 -- Quality Switch 是架构设计工具，不是性能问题修复工具 -- 必须在所有三档上验证视觉一致性 - -## Relationship to Niagara Scalability -Quality Switch 用于**材质**质量分层，Niagara Scalability 用于**VFX** 质量分层。两者共同构成 UE5 项目的完整质量分级体系。 - -## Shader Complexity Implication -- 每个 Static Switch **使着色器排列数翻倍**（而非加法增加） -- 添加 Static Switch 前必须审计 -- Quality Switch 节点本身不翻倍，但其控制的分支逻辑可能包含 Static Switch - -## Related -- [[NiagaraVFX]] — VFX 系统的 Scalability 分级 -- [[PerformanceBudget]] — Quality Switch 是平台预算管理工具 -- [[MaterialFunction]] — Quality Switch 可封装在 Function 中 diff --git a/wiki/concepts/QueryLanguage.md b/wiki/concepts/QueryLanguage.md deleted file mode 100644 index a354fcfb..00000000 --- a/wiki/concepts/QueryLanguage.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: "QueryLanguage" -type: concept -tags: [] -sources: [] -last_updated: 2025-03-07 ---- - -## Aliases -- 查询语言 -- DSL（领域特定语言） -- 声明式查询 - -## Definition -查询语言（QueryLanguage）是一种用于从数据库或知识库中检索信息的领域特定语言。在 Obsidian 生态中，[[DataviewPlugin]] 提供了类 SQL 的查询语法，允许用户声明式地描述"要什么数据"，而非"如何获取数据"。 - -## Core Syntax（Dataview 为例） -- `LIST`：罗列匹配的笔记标题 -- `TABLE`：以表格形式展示多个字段 -- `TASK`：列出匹配的待办事项 -- `WHERE`：过滤条件（如 `WHERE contains(tags, "学习")`） -- `FROM`：指定搜索范围（如 `FROM "Notes"`） - -## Design Principles -- **声明式**：描述期望结果，而非操作步骤 -- **类 SQL**：借鉴关系型数据库查询的直观语法 -- **结构化字段**：查询基于 frontmatter 和内联字段，而非纯文本搜索 - -## Related Concepts -- [[NoteDatabase]]：查询语言服务于笔记数据库场景 -- [[TagBasedIndexing]]：查询语言支持标签索引的查询需求 diff --git a/wiki/concepts/QueryPlanAnalysis.md b/wiki/concepts/QueryPlanAnalysis.md deleted file mode 100644 index 6cfa2e45..00000000 --- a/wiki/concepts/QueryPlanAnalysis.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "Query Plan Analysis" -type: concept -tags: [database, postgresql, explain, performance, query-optimization] -last_updated: 2026-05-01 ---- - -# Query Plan Analysis - -## Definition - -查询计划分析是通过 `EXPLAIN ANALYZE` 命令解读数据库优化器生成的查询执行计划，识别性能瓶颈（如 Seq Scan 全表扫描、估算偏差大）并针对性优化的方法。 - -## Key Scan Types - -| 扫描类型 | 评估 | 说明 | -|---------|------|------| -| **Seq Scan** | ⚠️ 差 | 全表扫描，通常意味着缺索引 | -| **Index Scan** | ✅ 好 | 索引扫描，直接定位数据 | -| **Bitmap Heap Scan** | 🟡 可接受 | 先索引定位再堆查，适合中等结果集 | -| **Index Only Scan** | ✅ 最佳 | 完全在索引中完成，无需回表 | - -## What to Look For - -- **actual time vs estimated rows**：与估算差异大说明统计信息过时 -- **cost=... loops=...**：高 cost 或多次 loops 需优化 -- **Buffers: shared hit/read**：大量 read 说明缓存未命中 -- **Seq Scan on large tables**：大表全表扫描通常是问题信号 - -## Example - -```sql -EXPLAIN ANALYZE -SELECT * FROM posts WHERE user_id = 123; - --- Good: Index Scan --- Bad: Seq Scan on posts (cost=0.00..1234.56 rows=500 width=...) -``` - -## Source -- [[engineering-database-optimizer]] - -## Connections -- [[IndexingStrategies]] — 根据分析结果创建/调整索引 -- [[N1QueryPrevention]] — EXPLAIN 识别 N+1 查询 -- [[SafeMigrations]] — 迁移前后验证查询性能 diff --git a/wiki/concepts/QueryWorkflow.md b/wiki/concepts/QueryWorkflow.md deleted file mode 100644 index 8bb3499a..00000000 --- a/wiki/concepts/QueryWorkflow.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "QueryWorkflow" -type: concept -tags: [workflow, knowledge-management, llm] -sources: [llm-wiki] -last_updated: 2026-05-02 ---- - -## Overview -查询工作流（Query Workflow）是 [[PersistentWiki]] 的核心运营模式之一——用户就 Wiki 中的内容提出问题，LLM 搜索相关页面、综合整理答案并以 wikilink 形式引用来源。 - -## Standard Process（4步） -1. **读取 Index**：读取 `wiki/index.md`，确定相关页面 -2. **读取相关页面**：读取这些页面的具体内容 -3. **综合生成答案**：以 `[[页面名]]` wikilink 形式内联引用来源 -4. **询问是否归档**：询问用户是否将答案保存为 `wiki/syntheses/.md` - -## Answer Formats -答案可以呈现不同形式： -- Markdown 页面 -- 对比表格 -- 幻灯片（Marp） -- 图表（matplotlib） -- 画布（Canvas） - -## Key Insight -**好的答案可以归档回 Wiki 作为新页面。** 用户提出的对比、分析、发现的关联——这些都很有价值，不应该消失在聊天记录中。探索结果与摄入来源一样复合积累到知识库中。 - -## Design Principles -- **Index-first**：先读索引找相关页面，而非直接全文搜索 -- **引文驱动**：所有答案以 wikilink 形式引用来源页 -- **知识沉淀**：探索结果是第二等重要的知识来源，仅次于摄入的原始来源 diff --git a/wiki/concepts/Quick-Capture.md b/wiki/concepts/Quick-Capture.md deleted file mode 100644 index e847d5a9..00000000 --- a/wiki/concepts/Quick-Capture.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: "Quick Capture" -type: concept -tags: [productivity, note-taking, workflow] -sources: [obsidian-高效指南-我常用的插件与实用技巧] -last_updated: 2025-03-01 ---- - -## Definition -通过最小摩擦的方式快速将想法记录到笔记系统中——强调"即时性"，在灵感消失前将其捕获，再后续整理完善。 - -## Core Mechanisms -- 快捷键触发：单键或组合键激活捕获流程 -- 最小输入界面：减少思考"写在哪里、怎么写"的心理负担 -- 自动路由：根据内容类型或上下文自动归类到目标笔记 -- 模板填充：快速创建结构化条目 - -## Implementations -- **QuickAdd** (Obsidian)：通过快捷键触发模板创建 -- **Capture to Local REST API**：通过 URL scheme 从外部应用捕获 -- **Shortcuts** (iOS)：系统级快速输入 -- **Alfred/Typinator**：文本片段快速插入 - -## Use Cases -- 灵感闪现时立即记录 -- 会议中快速记下行动项 -- 阅读时记录想法片段 -- 从其他应用快速转存内容 - -## Connections -- [[Template-based Note Creation]]：快速捕获后套用模板完善 -- [[Daily Journaling]]：每日开始时快速记录计划 -- [[Zettelkasten]]：快速捕获是 Zettelkasten 原子化笔记的第一步 - -## Sources -- [[obsidian-高效指南-我常用的插件与实用技巧]] diff --git a/wiki/concepts/RACI.md b/wiki/concepts/RACI.md deleted file mode 100644 index cc030f39..00000000 --- a/wiki/concepts/RACI.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "RACI" -type: concept -tags: [Business-Analysis, Stakeholder-Management, Responsibility-Assignment] -sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109] -last_updated: 2026-05-11 ---- - -## Definition - -RACI 是一个责任分配矩阵，用于明确项目或流程中每个干系人的角色和责任，确保职责清晰、避免责任真空或重叠。 - -## RACI 四要素 - -| 字母 | 角色 | 说明 | 示例 | -|------|------|------|------| -| **R** | Responsible（负责） | 执行具体任务的人 | 开发者编写代码 | -| **A** | Accountable（问责） | 最终责任人，对结果负总责 | 技术负责人审批方案 | -| **C** | Consulted（咨询） | 需要征询意见的人（双向沟通） | 安全团队审查设计 | -| **I** | Informed（知情） | 需要被通知结果的人（单向沟通） | 项目经理接收进度更新 | - -## Key Rules - -- 每个任务**必须且仅有 1 个 A**（Accountable）——避免多头责任 -- R（Responsible）可以有多个——多人协作执行 -- C（Consulted）和 I（Informed）是可选的——根据需要添加 - -## Application Scenario - -RACI 常用于： -- 项目启动时的角色定义会议 -- 流程梳理和优化 -- 跨部门协作的责任明确 -- 变更管理中的角色澄清 - -## Relationship to Other Concepts - -- [[Stakeholder-Wheel]]：RACI 是 Stakeholder Wheel 的深化工具，将干系人映射到具体任务 -- [[Business-Analysis]]：RACI 是业务分析师用于明确干系人责任的核心工具 -- [[BOSCARD]]：BOSCARD 中的 Roles 要素可进一步用 RACI 细化 - -## Example - -| 任务 | 产品经理 | 开发者 | 测试工程师 | 技术负责人 | -|------|---------|--------|-----------|----------| -| 需求分析 | A | R | C | I | -| 代码开发 | I | A/R | I | C | -| 测试执行 | I | C | A/R | I | -| 发布审批 | C | I | I | A | - -## Aliases -- RACI Matrix -- 责任分配矩阵 -- Responsibility Assignment Matrix diff --git a/wiki/concepts/RAG.md b/wiki/concepts/RAG.md deleted file mode 100644 index 528c3427..00000000 --- a/wiki/concepts/RAG.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "RAG" -type: concept -tags: [AI, knowledge-base, retrieval] -sources: [karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环, llm-wiki, 大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏, llms-rag-ai-agent三个到底什么区别] -last_updated: 2026-04-20 ---- - -## Aliases -- Retrieval-Augmented Generation -- 检索增强生成 - -## Definition -Retrieval-Augmented Generation（RAG，检索增强生成）——一种通过外部文档检索消除大模型幻觉、提升回答准确性的技术方案。用户上传文档后，AI 在回答时实时检索相关片段并拼接入答案。典型应用：NotebookLM、ChatGPT 文件上传。 - -## Key Properties -- 每次查询从零检索，无持久化积累 -- 综合多文档时，需要"现场找碎片、现场拼" -- RAG 通过"给提示"解决大模型在陌生领域的幻觉问题 -- 正确率可从 60% 提升至 90%（[[大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏]]） - -## Limitations -- **没有积累**：每次提问 AI 都在从头搜寻知识，什么都没沉淀 -- **维护成本高**：需要持续维护文档库，但 AI 不会自动更新交叉引用 -- Karpathy 指出：人类放弃 Wiki 是因为**维护成本的增长速度超过了价值的增长速度** - -## Contrast: RAG vs LLM Wiki -| 维度 | RAG | [[LLM Wiki]] | -|------|-----|--------------| -| 知识状态 | 每次查询从零 | 持久化积累 | -| 交叉引用 | 无 | 自动维护 | -| 多文档综合 | 临时拼接 | 预编译 | -| 维护者 | 人类 | AI（趋近于零成本）| - -## Connections -- [[LLM Wiki]] ← 对比/替代 ← RAG -- [[RAG]] ← 基础概念 → [[LLM Wiki]] diff --git a/wiki/concepts/RDS-Maintenance-Window.md b/wiki/concepts/RDS-Maintenance-Window.md deleted file mode 100644 index f1b0887e..00000000 --- a/wiki/concepts/RDS-Maintenance-Window.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "RDS Maintenance Window" -type: concept -tags: - - AWS - - RDS - - Database - - Maintenance -sources: - - ctp-topic-27-aws-instance-scheduler -last_updated: 2026-05-12 ---- - -## RDS Maintenance Window - -AWS RDS（Relational Database Service）维护窗口是数据库实例进行必要维护操作（如补丁升级、系统升级）的时间段，由 AWS 预先定义或由用户指定。 - -## Core Characteristics - -- **频率**：每个 RDS 实例每 7 天强制执行一次维护 -- **持续时间**：通常 30-60 分钟 -- **可中断性**：维护期间实例可能不可用 -- **用户控制**：用户可指定首选维护窗口（每周一次，每次 30 分钟） - -## AWS Instance Scheduler 中的处理 - -Instance Scheduler 具备智能感知 RDS 维护窗口的能力： - -1. **维护前**：在维护窗口开始前将 RDS 实例状态记录为"即将进入维护" -2. **维护期间**：暂停调度操作，不执行启停指令 -3. **维护完成后**：自动识别维护结束，恢复正常的调度状态 - -## Key Considerations - -- **停止 vs 终止**：RDS 实例的关机行为必须设置为"停止（Stop）"而非"终止（Terminate）"，否则维护窗口结束后实例不会重新启动 -- **多可用区**：Multi-AZ 实例的维护通常自动在备用实例上进行，对主实例影响较小 -- **蓝绿部署**：使用蓝绿部署进行数据库升级可减少停机时间 - -## Relationship to Instance Scheduler - -RDS Maintenance Window 是 Instance Scheduler 在调度 RDS 实例时必须考虑的特殊约束： - -- 实例的 `InstanceType` 标签用于区分 EC2 和 RDS -- RDS 实例需要额外的维护窗口逻辑判断 -- 调度算法需查询 RDS API 获取实例维护状态 - -## Related Pages -- [[AWS-Instance-Scheduler]] — 依赖此机制 -- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源 diff --git a/wiki/concepts/RFM-Analysis.md b/wiki/concepts/RFM-Analysis.md deleted file mode 100644 index f3c4bb1b..00000000 --- a/wiki/concepts/RFM-Analysis.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: "RFM Analysis" -type: concept -tags: [] -sources: [support-analytics-reporter] -last_updated: 2026-04-21 ---- - -## Aliases -- RFM Segmentation -- Recency, Frequency, Monetary Analysis -- 客户价值分层分析 - -## Definition -RFM Analysis 是一种三维客户价值分层方法，通过最近购买时间（Recency）、购买频率（Frequency）、消费金额（Monetary）三个维度对客户进行分群，从而识别高价值客户、流失风险客户和潜力客户，为精准营销和客户运营提供数据支撑。 - -## Core Metrics - -| 维度 | 定义 | 计算方式 | -|------|------|----------| -| Recency | 最近一次购买距今天数 | `当前日期 - 最近购买日期`（越小越好） | -| Frequency | 购买总次数 | `COUNT(order_id)`（越大越好） | -| Monetary | 累计消费金额 | `SUM(revenue)`（越大越好） | - -## Scoring Method - -每个维度按分位数（通常5分位）打分： -- R_Score：最近购买时间越近，分数越高（1-5分，5=最近） -- F_Score：购买频率越高，分数越高（1-5分，5=最频繁） -- M_Score：消费金额越高，分数越高（1-5分，5=最高金额） - -组合 R+F+M 得 RFM Score（如 `555`、`311`）。 - -## Customer Segments - -| RFM Score | 客户类型 | 策略建议 | -|-----------|---------|---------| -| 555/554/544/545/454/455/445 | Champions（冠军客户） | 奖励忠诚度，邀请推荐，升级销售高端产品 | -| 543/444/435/355/354/345/344/335 | Loyal Customers（忠诚客户） | 培养关系，推荐新品，忠诚度计划 | -| 553/551/552/541/542/533/532/531/452/451 | Potential Loyalists（潜力忠诚者） | 入会欢迎，早期参与，产品教育 | -| 512/511/422/421/412/411/311 | New Customers（新客户） | 入职优化，早期参与 | -| 155/154/144/214/215/115/114 | At Risk（流失风险客户） | 重新参与活动，特殊优惠，赢回策略 | -| 其他 | Others（一般客户） | 常规触达，持续观察 | - -## Implementation - -```python -import pandas as pd -import numpy as np - -def rfm_analysis(df, current_date=None): - """RFM Analysis implementation""" - if current_date is None: - current_date = df['date'].max() - - rfm = df.groupby('customer_id').agg({ - 'date': lambda x: (current_date - x.max()).days, # Recency - 'order_id': 'count', # Frequency - 'revenue': 'sum' # Monetary - }).rename(columns={ - 'date': 'recency', - 'order_id': 'frequency', - 'revenue': 'monetary' - }) - - # Create quintile scores (1-5) - rfm['r_score'] = pd.qcut(rfm['recency'], 5, labels=[5,4,3,2,1], duplicates='drop') - rfm['f_score'] = pd.qcut(rfm['frequency'].rank(method='first'), 5, labels=[1,2,3,4,5], duplicates='drop') - rfm['m_score'] = pd.qcut(rfm['monetary'], 5, labels=[1,2,3,4,5], duplicates='drop') - - rfm['rfm_score'] = rfm['r_score'].astype(str) + rfm['f_score'].astype(str) + rfm['m_score'].astype(str) - - return rfm -``` - -## Connections -- [[support-analytics-reporter]] — 使用 RFM 进行客户价值分层分析 -- [[Customer-Segmentation]] — RFM 是客户细分的核心方法之一 -- [[Business-Intelligence]] — 属 BI 领域的客户分析子方向 diff --git a/wiki/concepts/RICE-Prioritization-Score.md b/wiki/concepts/RICE-Prioritization-Score.md deleted file mode 100644 index 433b2393..00000000 --- a/wiki/concepts/RICE-Prioritization-Score.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "RICE Prioritization Score" -type: concept -tags: ["product-management", "prioritization", "decision-making"] -last_updated: 2026-04-30 ---- - -## Aliases -- RICE -- RICE Score -- RICE Framework - -## Definition -RICE 优先级评分框架 —— 一个量化的四因子需求优先级评估模型，通过公式 `(R × I × C) ÷ E` 计算综合得分，以数据支撑优先级排序决策。 - -## Formula - -| 因子 | 名称 | 定义 | 典型单位/范围 | -|------|------|------|--------------| -| **R** | Reach（触达） | 该功能一个季度内能影响多少用户 | 用户数/季度 | -| **I** | Impact（影响力） | 对单个用户的影响力 | 0.25 / 0.5 / 1 / 2 / 3 | -| **C** | Confidence（置信度） | 对假设的置信程度 | 百分比（50%–100%） | -| **E** | Effort（工作量） | 完成所需的人力月数 | 人力月 | - -**RICE Score = (R × I × C) ÷ E** - -## Decision Threshold -- 分数越高优先级越高 -- 通常与团队容量（capacity）结合，决定一个季度内可交付的数量 -- 分数需附带置信区间和敏感性分析 - -## Key Principles -- **数据 + 判断结合** —— 数字提供框架，最终决策需要产品判断 -- **量化不确定性** —— C 因子显式记录假设的置信程度 -- **努力量化** —— 防止高影响力但无限工作量的小时级陷阱 - -## Usage -由 [[Product Manager Agent]] 在 [[Opportunity Assessment]] 文档中使用，也用于 [[Product Roadmap (Now/Next/Later)]] 中的需求排序。 - -## Related -- [[Opportunity Assessment]] — RICE 评分的使用文档 -- [[Product Requirements Document (PRD)]] — RICE 排序后进入 PRD 阶段 -- [[Product Roadmap (Now/Next/Later)]] — RICE 排序结果映射到路线图三层 diff --git a/wiki/concepts/RICE-Scoring.md b/wiki/concepts/RICE-Scoring.md deleted file mode 100644 index 76235e88..00000000 --- a/wiki/concepts/RICE-Scoring.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "RICE Scoring" -type: concept -tags: [prioritization, agile, product-management] -last_updated: 2026-05-01 ---- - -## Definition - -RICE Scoring 是一种四维定量功能优先级排序框架，通过将每个功能的影响力转换为可比较的数值分数，消除团队优先级争论。 - -## Formula - -``` -RICE Score = (Reach × Impact × Confidence) / Effort -``` - -| 维度 | 定义 | 常见取值范围 | -|------|------|-------------| -| **Reach**（触达） | 该功能在第一个季度内能影响多少用户 | 1–10,000（用户数） | -| **Impact**（影响） | 该功能对单个用户的影响力 | 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal | -| **Confidence**（信心） | 对上述估算的信心程度 | 100%=high, 80%=medium, 50%=low | -| **Effort**（工作量） | 所需人月数（跨整个团队） | 0.5–20（人月） | - -## 应用场景 - -- **[[Phase 1 Strategy]]**：Sprint Prioritizer 使用 RICE 评分对 Phase 1 产出的任务列表进行排序 -- **[[scenario-startup-mvp]]**：Week 1 快速发现阶段使用 RICE 评分 backlog -- 适用于 Sprint Planning、Product Roadmap 排序、技术债务优先级决策 - -## 示例 - -| 功能 | Reach | Impact | Confidence | Effort | RICE Score | -|------|-------|--------|-----------|-------|------------| -| 用户注册优化 | 5000 | 2 | 100% | 2 | 5000 | -| 支付流程简化 | 2000 | 3 | 80% | 4 | 1200 | -| 暗模式支持 | 3000 | 1 | 50% | 3 | 500 | - -## 与 MoSCoW 的关系 - -RICE 分数高 ≠ Must-Have。MoSCoW 分类（RICE分数 + 战略/合规考量）决定是否纳入当前 Sprint；RICE 仅排序在 MoSCoW Must/Should/Could 中的条目。 - -## Aliases -- RICE Model -- RICE Framework -- RICE Prioritization diff --git a/wiki/concepts/ROI.md b/wiki/concepts/ROI.md deleted file mode 100644 index 44bd4400..00000000 --- a/wiki/concepts/ROI.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: ROI (Return on Investment) -tags: [Business, Finance, Cloud] ---- - -# ROI (Return on Investment) - -## Overview - -**ROI**（投资回报率）是衡量投资效益的核心财务指标，在云计算领域，多云策略的 ROI 分析是评估云投资成功与否的关键。多云策略通过成本优化、性能提升和风险降低等多个维度影响业务 ROI。 - -## Cloud ROI Calculation - -### Basic Formula -``` -ROI = (Net Benefits / Total Costs) × 100% - = ((Cost Savings + Revenue Gains) - Implementation Costs) / Total Costs × 100% -``` - -### Cloud-Specific ROI Components - -| Category | Benefits | Costs | -|----------|----------|-------| -| **Cost Savings** | 减少基础设施 CapEx、降低运维成本、减少停机损失 | 迁移成本、培训成本 | -| **Revenue Gains** | 更快推向市场、提升客户体验、支持新业务模式 | 持续订阅费用 | -| **Risk Reduction** | 减少单点故障、业务连续性提升 | 安全合规成本 | - -## Multi-Cloud ROI Drivers - -1. **Cost Reduction**: 多云竞争性定价带来 30% 运营成本降低（Forrester） -2. **Resource Optimization**: 工作负载分配到最适合的提供商，提升效率 -3. **Risk Mitigation**: 避免单一供应商故障导致的大规模业务中断 -4. **Scalability Gains**: 弹性扩展能力避免收入损失（旺季无法服务） -5. **Innovation Access**: 利用最新云服务加速产品创新 - -## ROI Timeline - -| Phase | Typical Timeline | Focus | -|-------|-----------------|-------| -| Initial Assessment | 1-3 months | 成本基线、ROI 模型建立 | -| Migration | 3-12 months | 渐进式迁移、持续优化 | -| Optimization | Ongoing | FinOps 实践、持续改进 | -| Full Value | 12-24 months | 实现预期 ROI | - -## Related Concepts - -- [[Cost Optimization]] -- [[Multi-Cloud Strategy]] -- [[FinOps]] -- [[Risk Mitigation]] -- [[Scalability]] - -## Sources - -- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]] diff --git a/wiki/concepts/RPC-Remote-Procedure-Call.md b/wiki/concepts/RPC-Remote-Procedure-Call.md deleted file mode 100644 index e38313b6..00000000 --- a/wiki/concepts/RPC-Remote-Procedure-Call.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "RPC (Remote Procedure Call)" -type: concept -tags: [] -sources: [unreal-multiplayer-architect] -last_updated: 2026-04-26 ---- - -## Definition -远程过程调用（RPC）是 UE5 多人游戏中客户端与服务器之间进行通信的核心机制。客户端通过 RPC 向服务器发送请求（Server RPC），服务器通过 RPC 向客户端或所有客户端广播事件（Client RPC / NetMulticast）。 - -## RPC Types -| 类型 | 方向 | 可靠性 | 用途 | -|------|------|--------|------| -| `Server` | 客户端 → 服务器 | Reliable/Unreliable | 客户端请求服务器执行操作 | -| `Client` | 服务器 → 特定客户端 | Reliable/Unreliable | 服务器通知特定客户端 | -| `NetMulticast` | 服务器 → 所有客户端 | Reliable/Unreliable | 服务器广播事件 | - -## Critical Rule: WithValidation -**每个游戏影响型的 Server RPC 必须实现 `_Validate()` 函数。** 缺失 `_Validate()` 构成安全漏洞，恶意客户端可发送非法请求。 - -```cpp -// Server RPC 必须有 WithValidation -UFUNCTION(Server, Reliable, WithValidation) -void ServerRequestInteract(AActor* Target); - -bool AMyActor::ServerRequestInteract_Validate(AActor* Target) -{ - // 拒绝不可能的请求 - if (!IsValid(Target)) return false; - float Distance = FVector::Dist(GetActorLocation(), Target->GetActorLocation()); - return Distance < 200.f; // 最大交互距离 -} - -void AMyActor::ServerRequestInteract_Implementation(AActor* Target) -{ - // 验证通过后安全执行 - PerformInteraction(Target); -} -``` - -## Reliability Guidelines -- **Reliable**：保证按序到达，用于游戏关键事件（伤害、得分、道具拾取） -- **Unreliable**：即发即忘，不保证到达，用于视觉效果、高频位置同步 -- 绝不能将高频调用与可靠 RPC 混合——必须为高频数据创建独立的不可靠更新路径 - -## Connection to Other Concepts -- [[Server-Authoritative Model]] — RPC 是服务器权威执行的游戏请求入口 -- [[Actor Replication]] — 属性复制与 RPC 互补，复制状态、RPC 触发动作 -- [[Network Prediction]] — 客户端在等待服务器 RPC 响应时进行本地预测 - -## Relationship to Agent -[[UnrealMultiplayerArchitect]] 将 RPC 验证视为非妥协原则："Every Server RPC needs a `_Validate`. No exceptions." - -## Aliases -- Remote Procedure Call -- Server RPC -- Client RPC -- NetMulticast diff --git a/wiki/concepts/RPC.md b/wiki/concepts/RPC.md deleted file mode 100644 index 16c0abc1..00000000 --- a/wiki/concepts/RPC.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "RPC (Remote Procedure Call)" -type: concept -tags: ["unreal-engine", "networking", "client-server"] -sources: ["unreal-multiplayer-architect", "unreal-multiplayer-architect"] -last_updated: 2026-04-30 ---- - -## Aliases -- 远程过程调用 -- Server RPC -- Client RPC -- NetMulticast - -## 定义 -RPC（远程过程调用）是 UE5 中客户端与服务器之间通信的主要机制，允许在一个网络节点上调用另一个节点上的函数。 - -## 三种 RPC 类型 - -### Server RPC -- **方向**: 客户端 → 服务器 -- **用途**: 客户端向服务器发送请求（玩家输入、操作命令） -- **要求**: 游戏逻辑 RPC 必须包含 `_Validate()` 实现 -- **标记**: `UFUNCTION(Server, Reliable, WithValidation)` - -### Client RPC -- **方向**: 服务器 → 特定客户端（拥有该 Actor 的客户端） -- **用途**: 服务器向特定客户端发送消息（私有数据、确认消息） -- **标记**: `UFUNCTION(Client, Reliable)` - -### NetMulticast -- **方向**: 服务器 → 所有相关客户端 -- **用途**: 服务器向所有客户端广播事件（视觉特效、公共事件） -- **标记**: `UFUNCTION(NetMulticast, Unreliable)` - -## 可靠性 -- **Reliable**: 保证按序到达，但增加带宽 -- **Unreliable**: 尽力发送，可能丢失或乱序 - -## 安全规范 -每个 Server RPC 必须实现 `_Validate()` 函数，拒绝非法输入。缺少验证 = 作弊漏洞。 - -## 相关概念 -- [[Server-Authoritative Model]] — RPC 的使用背景 -- [[Actor Replication]] — 与 RPC 配合的状态同步机制 -- [[Network Prediction]] — RPC 与客户端预测的协同 diff --git a/wiki/concepts/RPO.md b/wiki/concepts/RPO.md deleted file mode 100644 index e6afcfa4..00000000 --- a/wiki/concepts/RPO.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: "RPO (Recovery Point Objective)" -tags: [devops, disaster-recovery, sre, reliability, data-protection] -last_updated: 2026-04-29 ---- - -# RPO (Recovery Point Objective) - -**RPO (Recovery Point Objective)** 是指系统发生故障时，能够接受的最大数据丢失量。它衡量的是数据保护程度——从故障时刻向前追溯，可接受丢失多长时间的数据。 - -## Definition - -> "RPO is about protecting data. It's measured backwards from the moment of failure." — LaunchDarkly - -RPO 是灾备规划的核心指标之一，与 [[RTO]]（恢复时间目标）共同构成灾备目标体系。 - -## Key Characteristics - -| 维度 | 说明 | -|------|------| -| **衡量对象** | 数据丢失量（Data Loss Amount） | -| **测量方向** | 从故障时刻向后（Backwards）追溯 | -| **关注点** | 数据完整性（How Much Data Can Be Lost） | - -## Example - -如果数据库在下午 3 点崩溃，而最后一次备份是下午 2 点，则： -- **RPO = 1 小时**：这意味着过去 1 小时内的数据可能丢失 -- 2:00 到 3:00 之间发生的所有事务都面临丢失风险 - -## RTO vs. RPO - -RTO 和 RPO 衡量的是不同维度，必须**同时优化**： - -| 场景 | RTO 目标 | RPO 目标 | 说明 | -|------|----------|----------|------| -| 电商结账 | 2 分钟 | 0 秒 | 必须快速恢复，且不能丢失任何交易 | -| 用户分析面板 | 30 分钟 | 1 小时 | 停机可接受，小时级数据丢失也可接受 | -| 内部 CRM | 4 小时 | 15 分钟 | 停机可绕过，但近期客户更新很重要 | -| 博客/营销站 | 2 小时 | 24 小时 | 访问者可以等，丢失一天评论可接受 | - -**关键**：不能只优化其中一个指标。 -- 30 秒一次备份（RPO 优秀）但恢复需要 6 小时（RTO 极差）= 无效 -- 5 分钟拉起新服务器（RTO 优秀）但丢失 4 小时客户数据（RPO 极差）= 无效 - -## [[Feature Flag]] 对 RPO 的保护 - -传统回滚（Full Deployment Rollback）在回滚过程中可能丢失新事务数据。而 [[Feature Flag]] 回滚**不丢失数据**： - -- Feature Flag 切换只改变代码执行路径，不触碰数据层 -- [[Kill Switch]] 关闭故障功能时，用户正在提交的数据不受影响 -- RPO 在整个 Feature Flag 操作期间始终保持近零 - -## Tiered RPO Targets - -| Tier | 场景 | RPO 目标 | 说明 | -|------|------|----------|------| -| Critical | 支付处理、交易系统 | < 1 分钟 | 不能丢失任何金钱相关数据 | -| Important | CRM、客户支持 | < 15 分钟 | 近期客户更新不可丢失 | -| Nice-to-have | 文档站、内部工具 | < 1 小时 | 数据可重建或接受丢失 | - -## 实现手段 - -| 方法 | RPO 效果 | 说明 | -|------|----------|------| -| 无备份 | ∞ | 完全不可接受 | -| 每日备份 | 24 小时 | 成本低，RPO 差 | -| 每小时备份 | 1 小时 | 中等成本和效果 | -| CDB（持续数据保护） | 秒级 | 持续复制，RPO 接近零 | -| 同步复制（Active-Active） | 0 | 零数据丢失，成本极高 | - -## RPO 与 RTO 必须协同 - -最佳实践是同时设定 RTO 和 RPO，并将 [[Feature Flag]] / [[Kill Switch]] 纳入灾备工具链： - -- RTO 短 → 系统快速恢复 -- RPO 小 → 数据损失少 -- Feature Flag → 两者兼得的性价比方案 - -## Related Concepts - -- [[RTO]] — Recovery Time Objective，停机时间指标 -- [[Disaster Recovery]] — 灾备策略，RTO/RPO 是其核心目标 -- [[Feature Flag]] — 保护 RPO 的配置级热修复机制 -- [[Kill Switch]] — 关闭故障功能，保护数据不被继续破坏 -- [[High Availability]] — 高可用性，降低 RPO 的基础设施 -- [[Data-Governance]] — 数据治理，包含 RPO 策略 -## Sources - -- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] -- [[ctp-topic-44-aws-backup-in-micro-focus]] -- [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]] -- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] \ No newline at end of file diff --git a/wiki/concepts/RRF-Reranking.md b/wiki/concepts/RRF-Reranking.md deleted file mode 100644 index 0b49df65..00000000 --- a/wiki/concepts/RRF-Reranking.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "RRF-Reranking" -type: concept -tags: [] ---- - -## Definition -RRF（Reciprocal Rank Fusion，倒数排名融合）是一种融合多个排序结果的技术，通过综合不同搜索方法的排名生成统一排序。 - -## Formula -``` -RRF_score(d) = Σ 1/(k + rank_i(d)) -``` -其中 k 是平滑因子（通常为60），rank_i(d) 是文档 d 在第 i 个排名列表中的位置。 - -## Key Characteristics -- 无需人工调参，对不同搜索方法一视同仁 -- 排名靠前的文档在融合时权重更高 -- 计算简单，可实时融合多个搜索结果 - -## Application -- [[memsearch]] 使用 RRF 融合稠密向量搜索和 BM25 搜索的结果 -- [[HybridSearch]] 的核心重排机制 - -## Related Concepts -- [[HybridSearch]] — 混合搜索（RRF 是其组成部分） -- [[Semantic-Search]] — 语义搜索 diff --git a/wiki/concepts/RSS-Aggregation.md b/wiki/concepts/RSS-Aggregation.md deleted file mode 100644 index c3c1d6e3..00000000 --- a/wiki/concepts/RSS-Aggregation.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "RSS Aggregation" -type: concept -tags: [] ---- - -## Definition -RSS 聚合模式——通过 RSS 协议从多个信息源持续获取最新内容，作为信息监控和内容策展的基础数据管道。 - -## Architecture -``` -[RSS Feed URLs] → [RSS Parser (feedparser)] → [内容提取] → [去重评分] → [投递] - ↑ - [RSSHub] 扩展无原生 RSS 的站点 -``` - -## Key Tools -| 工具 | 用途 | -|------|------| -| [[RSSHub]] | 开源 RSS 聚合服务，为无原生 RSS 的网站（如 Twitter、GitHub、bilibili）生成 RSS 源 | -| feedparser | Python RSS/Atom 解析库 | -| FreshRSS | 自托管 RSS 阅读器 | -| Inoreader | 托管 RSS 服务 | - -## RSSHub Extended Sources -RSSHub 可为以下无原生 RSS 的网站生成 RSS 源： -- 社交媒体：Twitter 用户/话题、微博用户 -- 视频平台：YouTube 频道、bilibili 用户/分区 -- GitHub：仓库 Issues/PR/Releases/Commits -- 新闻：知乎话题、微博热搜 - -## Use Cases -- [[multi-source-tech-news-digest]] — 46 个 RSS 源（OpenAI Blog、Hacker News、MIT Tech Review 等） -- Newsletter 订阅源 -- 竞品动态监控 - -## Related Concepts -- [[Web-Search-Aggregation]] — RSS 的互补方案：被动拉取 vs 主动搜索 -- [[Content-Deduplication]] — 多 RSS 源之间的内容去重 -- [[RSSHub]] — 扩展 RSS 覆盖范围的工具 diff --git a/wiki/concepts/RTO.md b/wiki/concepts/RTO.md deleted file mode 100644 index 6e8244b8..00000000 --- a/wiki/concepts/RTO.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: "RTO" -type: concept -tags: - - AWS - - Disaster Recovery - - High Availability - - Cloud Architecture -sources: - - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora - - public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2 -last_updated: 2026-04-29 ---- - -## Overview -RTO（Recovery Time Objective，恢复时间目标）是从系统故障发生到恢复正常运行所需的最大可接受时间。是灾备（DR）策略中的核心指标。 - -## Definition -- **RTO**：系统从故障中恢复的时间目标 -- 与 [[RPO]]（Recovery Point Objective，恢复点目标）共同构成灾备的两大核心指标 - -## AWS Database RTO 对比 - -| 数据库服务 | AZ 故障 RTO | 架构特点 | -|-----------|------------|----------| -| **Aurora** | ~30 秒 | 6 副本跨 3 AZ 共享集群卷 | -| **RDS** | ~2 分钟 | EC2 + EBS 分离，Multi-AZ 备用节点 | -| **传统自建** | 数小时 | 需手动恢复 | - -## RTO vs RPO - -| 指标 | 定义 | 衡量内容 | -|------|------|----------| -| **RTO** | 恢复时间目标 | 系统不可用的最大时长 | -| **RPO** | 恢复点目标 | 可接受的最大数据丢失时长 | - -## Key Insights -- Aurora 的低 RTO 源于其 6 副本跨 3 AZ 的共享集群卷架构，故障时无需重建数据 -- RDS 的 RTO 较高是因为需要备用节点接管并重新建立连接 -- RTO 优化需要考虑 DNS TTL、TCP Keep-Alive、连接池配置等多个层面 -- **[[LaunchDarkly]]** 是企业 RTO 优化的典型案例 - -## Related Concepts -- [[RPO]]：Recovery Point Objective，恢复点目标 -- [[Disaster Recovery]]：灾备策略 -- [[High Availability]]：高可用性 -- [[Amazon Aurora]]：Aurora 的 RTO 优势 -- [[Amazon RDS]]：RDS 的 RTO 特点 -- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：AWS 数据库 RTO 实测对比 -- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]：企业级灾备策略 - -## Aliases -- Recovery Time Objective -- 恢复时间目标 -- RTO -- MTTR（Mean Time To Recovery，与 RTO 相关但 MTTR 是实际测量值） diff --git a/wiki/concepts/Rate-Limiting.md b/wiki/concepts/Rate-Limiting.md deleted file mode 100644 index 1f5b2f32..00000000 --- a/wiki/concepts/Rate-Limiting.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "Rate Limiting" -type: concept -tags: - - CI/CD - - DevOps - - GitOps -last_updated: 2026-05-11 ---- - -# Rate Limiting - -## Definition -速率限制，为防止自动化工具（如 Renovate Bot）瞬间产生过多 Pull Request 导致 CI/CD 系统（如 Jenkins）崩溃，Renovate 允许限制每小时或同时开启的 PR 数量。 - -## Core Functions -- 限制每小时创建的 PR 数量 -- 限制同时打开的 PR 数量上限 -- 防止 GitHub API 触发速率限制（429 Too Many Requests） -- 避免给 CI/CD 系统带来突发负载 - -## Related Concepts -- [[Renovate-Bot]] — Rate Limiting 是 Renovate Bot 的重要配置选项 -- [[Dependency-Management]] — Rate Limiting 支撑依赖管理的稳定运行 -- [[CI-CD]] — CI/CD 流水线是 Rate Limiting 的保护对象 - -## Related Sources -- [[ctp-topic-15-working-with-renovatebot]] - -## Aliases -- API Rate Limiting -- Request Throttling -- PR Rate Limit diff --git a/wiki/concepts/ReAuditTriggers.md b/wiki/concepts/ReAuditTriggers.md deleted file mode 100644 index 3c413b89..00000000 --- a/wiki/concepts/ReAuditTriggers.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "ReAuditTriggers" -type: concept -tags: [] -last_updated: 2026-04-25 ---- - -# ReAuditTriggers（重审计触发条件） - -## Definition -触发现有自动化流程重新审计的事件条件，防止系统在外部环境变化后继续以过时假设运行。 - -## Trigger Conditions - -### 1. API or Schema Changes（API 或 Schema 变更） -外部依赖的 API 版本升级、字段类型变化、必填字段增减等，均可能破坏现有工作流逻辑。 -**行动**：重新验证字段映射、输入验证和错误处理是否仍有效。 - -### 2. Error Rate Increases（错误率上升） -当某工作流的错误率超过基线阈值（如 >1%），可能是： -- 隐性依赖断裂 -- 上游数据质量恶化 -- 限流策略收紧 -**行动**：追踪错误日志，定位根本原因，重新评估风险评分。 - -### 3. Volume Increases Significantly（容量大幅增长） -业务量从 1x 增长到 10x/100x 时，以下假设可能失效： -- 重试次数和退避策略 -- 去重机制的处理能力 -- 外部 API 速率限制 -**行动**：重新执行 [[DecisionFramework]] 的可扩展性评估维度。 - -### 4. Compliance Requirements Change（合规要求变更） -新法规、行业标准或内部政策的出台，可能对数据处理方式提出新要求。 -**行动**：重新评估 [[IntegrationGovernance]] 的合规维度，必要时回退或修改自动化。 - -### 5. Repeated Manual Fixes Appear（反复出现人工修复） -当运维人员反复以手动方式"修复"同一工作流，说明： -- 该工作流的 [[ReliabilityBaseline]] 不满足实际需求 -- 存在未被识别的失败模式 -**行动**：将人工修复步骤文档化，评估是否应纳入自动化，或修改降级路径。 - -## Key Principle -> **Re-audit does not imply automatic production intervention.** -> （重审计不意味着自动进行生产干预——审计结果是决策依据，不是行动本身。） - -## Related Concepts -- [[AutomationGovernance]]：重审计触发条件由治理框架定义 -- [[IntegrationGovernance]]：API 变更和合规变更直接影响集成治理状态 -- [[ReliabilityBaseline]]：错误率上升触发可靠性重新评估 -- [[DecisionFramework]]：容量变化触发可扩展性维度重新打分 - -## Sources -- [[automation-governance-architect]]（primary） diff --git a/wiki/concepts/Reality-Checker.md b/wiki/concepts/Reality-Checker.md deleted file mode 100644 index cd8c1807..00000000 --- a/wiki/concepts/Reality-Checker.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Reality Checker" -type: concept -tags: [multi-agent, quality, testing, nexus] -sources: [executive-brief, quickstart, workflow-startup-mvp, nexus-spatial-discovery] -last_updated: 2026-05-01 -aliases: - - Quality Authority - - Final Quality Gate ---- - -## Definition - -Reality Checker（Reality Checker Agent）—— NEXUS 多 Agent 编排框架的最终质量权威，以默认"NEEDS WORK"的质疑姿态，对所有交付物进行证据驱动的严格验证。 - -## Core Principle - -**默认"NEEDS WORK"姿态** —— Reality Checker 不会默认相信任何自我声明的质量评估，必须看到可验证的证据才认可交付物通过。 - -这直接针对多 Agent 系统中的"幻想型审批"问题：Agent 在无证明的情况下给基础实现评 A+，导致质量虚高而缺陷埋入生产。 - -## Verification Criteria - -Reality Checker 执行的验证包括： -- **截图证据**：关键功能必须有运行截图或录屏 -- **测试结果**：自动化测试必须通过，覆盖率必须达标 -- **性能数据**：性能指标必须满足量化标准 -- **可访问性报告**：WCAG 合规报告或其他无障碍验证结果 - -## Role in NEXUS - -Reality Checker 是 NEXUS 流水线的最后一道质量门控，位于 Phase 4 Hardening → Phase 5 Launch 之间： -- 所有 Agent 的自我质量声明都必须经过 Reality Checker 验证 -- Reality Checker 的判定是进入生产发布的最终决策依据 -- Reality Checker 保持独立，不受上游 Agent 自我评估的影响 - -## Related Concepts - -- [[Quality Gate]]：Reality Checker 是最终质量门控的执行者 -- [[Evidence Over Claims]]：Reality Checker 的验证标准——要求截图/测试结果/数据，而非口头断言 -- [[Dev↔QA Loop]]：Reality Checker 位于 Dev↔QA 循环之后，是双重质量保障的最终关卡 diff --git a/wiki/concepts/Reality-Signal.md b/wiki/concepts/Reality-Signal.md deleted file mode 100644 index a004370a..00000000 --- a/wiki/concepts/Reality-Signal.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Reality-Signal" -type: concept -tags: [] -sources: [pre-build-idea-validator] -last_updated: 2026-04-27 ---- - -## Overview -通过 `idea_check()` 返回的 0-100 赛道拥挤度评分，基于 GitHub 仓库数量、Star 分布、Hacker News 讨论量等真实数据。用于 [[Pre-Build Validation]] 的核心度量指标，决定 Agent 是否可以继续构建还是需要暂停讨论。 - -## Scoring Mechanism -- **GitHub**：相关仓库数量 + Top 竞品的 Star 总数 -- **Hacker News**：相关讨论帖数量 + 平均分数 -- **npm / PyPI**：包数量 + 下载量分布 -- **Product Hunt**：早期产品关注度 - -综合以上数据输出 0-100 的 `reality_signal` 分数。 - -## Interpretation -| 分数区间 | 信号含义 | 行动 | -|---|---|---| -| > 70/100 | 高度拥挤 | 成熟竞品众多，需强差异化 | -| 30-70/100 | 中度竞争 | 存在机会但需细分角度 | -| < 30/100 | 市场空白 | 真正的蓝海，白手起家的最佳区间 | - -## Key Properties -- **基于真实数据，非 LLM 猜测**：unlike subjective assessment, reality_signal uses actual repo counts, star distributions, and HN discussion volume -- **用途**：[[Pre-Build Validation]] 决策依据；Hackathon 想法排名（最低分 = 最佳机会） -- **局限性**：无法评估技术实现难度、市场进入时机、团队执行能力 - -## Aliases -- Competition Score -- Market Saturation Score -- Idea Signal - -## Related -- [[Pre-Build Validation]] -- [[Competition-Analysis]] -- [[idea-reality-mcp]] -- [[Pivot-Strategy]] diff --git a/wiki/concepts/RealityKit-SwiftUI-Integration.md b/wiki/concepts/RealityKit-SwiftUI-Integration.md deleted file mode 100644 index 7afb1358..00000000 --- a/wiki/concepts/RealityKit-SwiftUI-Integration.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "RealityKit-SwiftUI Integration" -type: concept -tags: [] -sources: [visionos-spatial-engineer] -last_updated: 2026-04-25 ---- - -## Definition -Apple 提供的 RealityKit 3D 渲染引擎与 SwiftUI 声明式 UI 框架之间的深度集成模式，允许开发者用 SwiftUI 语法声明式地构建 3D 空间界面。 - -## Core Integration Patterns -- **@Observable Entities**：RealityKit 实体实现 @Observable 协议，与 SwiftUI 视图自动双向绑定 -- **Direct Gesture Handling**：SwiftUI 手势（Gesture）直接作用于 RealityKit 实体，无需中间层 -- **ViewAttachmentComponent**：将 SwiftUI 视图作为 component 附加到 RealityKit 实体 -- **EntityManager Integration**：通过 SwiftUI Environment 访问 EntityManager 实例 - -## Implementation Benefits -- **Declarative 3D（声明式 3D）**：用 SwiftUI 视图语法替代传统 Entity-Component 模式 -- **State Synchronization（状态同步）**：SwiftUI @State/@Binding 与 RealityKit 实体属性自动同步 -- **Reduced Boilerplate（减少样板代码）**：相比纯 RealityKit 开发，集成模式显著减少代码量 - -## Related Concepts -- [[SwiftUI Volumetric APIs]]：基于 RealityKit-SwiftUI 集成的上层 API 集 -- [[Spatial Layouts]]：集成后的 3D 内容在空间中的布局管理 -- [[Multi-Window Architecture]]：集成模式在多窗口场景下的应用 - -## Sources -- [[visionos-spatial-engineer]] — visionOS Spatial Engineer Agent 角色定义 diff --git a/wiki/concepts/RealitySignal.md b/wiki/concepts/RealitySignal.md deleted file mode 100644 index 002d2c78..00000000 --- a/wiki/concepts/RealitySignal.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Reality Signal" -type: concept -tags: [competition-analysis, decision-gate, ai-agent, market-intelligence] -sources: [pre-build-idea-validator] -last_updated: 2026-04-27 ---- - -## Definition -竞争饱和度评分（0-100），由 [[idea-reality-mcp]] 基于 GitHub 仓库数量、star 分布、Hacker News 讨论量、npm/PyPI/Product Hunt 数据计算得出。数值越高表示该赛道越拥挤。 - -## Decision Thresholds -| Score | Interpretation | Agent Action | -|-------|---------------|-------------| -| > 70 | 高竞争（红海） | STOP，展示竞品 + stars，询问用户是否继续/转型/放弃 | -| 30-70 | 中等竞争 | 展示竞品 + pivot_hints，建议差异化角度 | -| < 30 | 低竞争（白海） | 直接构建，确认机会空间存在 | - -## Core Value -- 基于**真实数据**（repo counts、star distributions、HN volume）而非 LLM 主观猜测 -- 防止独立开发者在已被成熟产品占领的赛道中浪费生命 -- 低分 = 真正的白海机会 = 单兵创业者最佳切入窗口 - -## Related Concepts -- [[PreBuildValidation]]：使用 Reality Signal 作为决策门控的完整流程 -- [[Pre-Build Idea Validator]]：结合 OpenClaw + idea-reality-mcp 的具体实现 -- [[Pivot Direction]]：当高竞争时工具提供的差异化转型建议 - -## Aliases -- reality_signal -- competition score -- saturation score diff --git a/wiki/concepts/Reciprocal-Rank-Fusion.md b/wiki/concepts/Reciprocal-Rank-Fusion.md deleted file mode 100644 index ba244b7f..00000000 --- a/wiki/concepts/Reciprocal-Rank-Fusion.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Reciprocal Rank Fusion (RRF)" -type: concept -tags: [search, ranking, fusion, algorithm] -sources: [semantic-memory-search] -last_updated: 2026-04-22 ---- - -## Aliases -- RRF -- Reciprocal Rank Fusion - -## Definition - -Reciprocal Rank Fusion（倒数排名融合）是一种多检索器结果融合算法，通过对各检索器返回结果的排名取倒数并进行加权求和，生成统一的融合排名。无需训练，简单高效，是混合搜索的标准融合策略。 - -## Formula - -``` -RRF_score(d) = Σ 1 / (k + rank_i(d)) - -其中： -- d = 文档 -- rank_i(d) = 检索器 i 对文档 d 的排名（从1开始） -- k = 平滑参数（通常 k=60，作用是减少高排名文档的压倒性优势） -``` - -## Why k=60? - -k=60 是一个经验值，来源于 BM25 的默认参数 k1=1.2、b=0.75 的理论推导。选择 k=60 使得排名差异在高位次（rank 1 vs rank 2）时有明显影响，但在低排名（rank 50 vs rank 51）时影响减弱，兼顾早期精确和长尾包容。 - -## Example - -假设有两个检索器对同一查询的结果： - -| 文档 | 向量检索排名 | BM25 排名 | -|------|------------|----------| -| A | 1 | 3 | -| B | 2 | 1 | -| C | 3 | 2 | - -k=60 时： -- RRF(A) = 1/(60+1) + 1/(60+3) = 0.01639 + 0.01587 = **0.03226** -- RRF(B) = 1/(60+2) + 1/(60+1) = 0.01613 + 0.01639 = **0.03252** -- RRF(C) = 1/(60+3) + 1/(60+2) = 0.01587 + 0.01613 = **0.03200** - -最终排名：B > A > C - -## Connections -- [[Hybrid Search]] — RRF 是混合搜索的标准融合算法 -- [[semantic-memory-search]] — memsearch 使用 RRF 融合向量和 BM25 结果 -- [[Knowledge-Base-RAG]] — RRF 用于提升知识库检索质量 diff --git a/wiki/concepts/Recovery-Assurance.md b/wiki/concepts/Recovery-Assurance.md deleted file mode 100644 index 983eacfe..00000000 --- a/wiki/concepts/Recovery-Assurance.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: "Recovery Assurance" -type: concept -tags: [Recovery-Assurance, SRE, Disaster-Recovery, Observability, Automation, Cloud-DevOps, Resilience] -sources: - - public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2 -last_updated: 2026-04-29 ---- - -## Recovery Assurance（恢复保证） - -恢复保证（Recovery Assurance）是灾难恢复（[[Disaster-Recovery]]）理念的演进方向——从被动应对灾难，到主动设计、持续验证、自动化保证系统的恢复能力。是 [[OpenText]] 在 2024 年提出的 DR 演进框架核心理念。 - -## Definition - -> "Recovery Assurance = 可恢复性作为架构设计原则 + 可观测性作为持续监控手段 + 自动化作为规模化保障" - -传统 DR 关注的是"灾难发生后如何恢复"，而 Recovery Assurance 关注的是"如何保证系统在任何故障下都能可靠恢复"——从反应式（Reactive）转向主动式（Proactive）。 - -## The Four-Pillar Framework - -[[OpenText]] 提出的四位框架，将 Recovery Assurance 落地到架构的四个层面： - -``` -┌─────────────────────────────────────────────────────┐ -│ 1. DESIGN（设计） │ -│ → 可恢复性作为架构设计原则 │ -│ → 在设计阶段就定义恢复机制 │ -│ → [[RTO]]/[[RPO]] 目标前置纳入架构评审 │ -└─────────────────────────────────────────────────────┘ - ↓ -┌─────────────────────────────────────────────────────┐ -│ 2. SOFTWARE（软件） │ -│ → 软件内嵌遥测，支持持续健康监控 │ -│ → [[Self-Healing]] 自愈能力 │ -│ → [[Observability]] 驱动的故障检测 │ -└─────────────────────────────────────────────────────┘ - ↓ -┌─────────────────────────────────────────────────────┐ -│ 3. BUILD（构建） │ -│ → [[Customer-Zero]] 环境验证恢复路径 │ -│ → 在发布前验证 RTO/RPO 是否满足 SLA │ -│ → CI/CD 流水线中的恢复演练 │ -└─────────────────────────────────────────────────────┘ - ↓ -┌─────────────────────────────────────────────────────┐ -│ 4. ENVIRONMENTS（环境） │ -│ → [[SRE]] + 可观测性工程持续运营 │ -│ → 跨 AWS/GCP/Azure 的统一可恢复性标准 │ -│ → Error Budget 驱动发布节奏 │ -└─────────────────────────────────────────────────────┘ -``` - -## Key Enablers - -| 驱动因素 | 说明 | -|----------|------| -| **[[SRE]]** | 用软件工程思维解决运维问题，通过 Error Budget 量化可靠性 | -| **[[Observability]]** | 通过遥测数据持续理解系统健康状态，是 Recovery Assurance 的技术前提 | -| **[[Self-Healing]]** | 软件层面的自动恢复能力，减少人工响应时间和 Toil | -| **[[Customer-Zero]]** | 内部验证环境，在生产级配置下验证恢复路径 | -| **[[Automation]]** | 减少人工协调成本，使 Recovery Assurance 可规模化 | - -## Why Evolution is Needed - -| 传统 DR 的问题 | Recovery Assurance 的解决方案 | -|---------------|-----------------------------| -| 反应式（Reactive） | 主动设计（Proactive） | -| 手动测试，成本高 | 自动化验证，持续运行 | -| 按客户时间表 | 持续监控，即时验证 | -| 无一致性方法 | 统一四位框架 | -| 无法规模化 | 自动化保障，可规模化 | -| 仅覆盖区域故障 | 覆盖多云多层级故障模式 | - -## Connection to Business Continuity - -Recovery Assurance 是 [[Business-Continuity-Plan]]（业务连续性计划）在 IT 技术层面的具体实现： - -- **BCP 定义业务恢复目标**（最大可接受中断时长、关键业务功能） -- **Recovery Assurance 实现技术恢复能力**（RTO/RPO、自动化恢复路径） -- **两者共同**：确保灾难发生后业务能在 SLA 时间内恢复运营 - -## Related Concepts - -- [[Disaster-Recovery]] — Recovery Assurance 的前身，从 DR 演进而来 -- [[SRE]] — Recovery Assurance 的核心方法论 -- [[Observability]] — Recovery Assurance 的技术基础 -- [[Self-Healing]] — Recovery Assurance 在软件层面的自动恢复实现 -- [[Customer-Zero]] — Recovery Assurance Build 阶段的验证环境 -- [[RTO]] / [[RPO]] — Recovery Assurance 的量化目标 -- [[Business-Continuity-Plan]] — Recovery Assurance 的上层业务框架 - -## Sources - -- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] diff --git a/wiki/concepts/RecruitmentFunnelAnalyzer.md b/wiki/concepts/RecruitmentFunnelAnalyzer.md deleted file mode 100644 index 49d60abc..00000000 --- a/wiki/concepts/RecruitmentFunnelAnalyzer.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Recruitment Funnel Analyzer（招聘漏斗分析）" -type: concept -tags: [recruitment, analytics, data-driven] -sources: [recruitment-specialist] -last_updated: 2026-04-25 ---- - -## 定义 -招聘漏斗分析是一种数据驱动方法，通过追踪从职位发布到试用期通过的全链路各环节转化率，识别招聘瓶颈并持续优化招聘效率和 ROI。 - -## 在 [[Recruitment Specialist Agent]] 中的实现 - -### 漏斗模型 -``` -职位曝光 → 投递量 → 简历通过 → 初试 → 复试 → 终面 → 发 offer → offer 接受 → 入职 → 试用期通过 -``` - -### 关键指标 -| 指标 | 计算方式 | -|------|---------| -| 简历投递率 | 投递数 / 曝光量 × 100% | -| 简历通过率 | 通过数 / 投递数 × 100% | -| 面试到场率 | 实到人数 / 邀约人数 × 100% | -| offer 接受率 | 接受数 / 发出数 × 100% | -| 入职率 | 入职数 / offer接受数 × 100% | -| 试用期留存率 | 试用期通过数 / 入职数 × 100% | -| 总体转化率 | 试用期通过数 / 投递数 × 100% | - -### 渠道 ROI 分析 -- 每渠道计算：成本 / 简历数、成本 / 入职数、成本 / 试用期通过数 -- 综合效率分 = 候选人质量分 × 0.4 + (1/单次入职成本) × 10000 × 0.3 + 试用期通过率 × 100 × 0.3 - -### 招聘周期分析 -- 平均招聘周期（天数） -- 各环节耗时：简历筛选、面试流程、offer 审批、候选人决策 - -## Python 实现 -内置于 [[Recruitment Specialist Agent]] 的 `RecruitmentFunnelAnalyzer` 类，支持按职位、部门、周期筛选数据。 - -## 连接 -- [[Recruitment Specialist Agent]] — 内置分析工具 -- [[Structured Interview]] — 数据驱动决策支撑结构化面试标准 diff --git a/wiki/concepts/Recurrence-Count.md b/wiki/concepts/Recurrence-Count.md deleted file mode 100644 index ab8cdc3f..00000000 --- a/wiki/concepts/Recurrence-Count.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "Recurrence-Count" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-17 ---- - -## 定义 -Learning 记录 Metadata 中的重复次数字段，用于追踪同一 Pattern-Key 下问题出现的次数。格式： -```markdown -### Metadata -- Recurrence-Count: 2 -- See Also: LRN-20260325-001 -``` - -## 核心价值 -**区分一次性错误与系统性重复，是最重要的指标之一。** - -## 解读原则 -| Recurrence-Count | 含义 | 处理策略 | -|-----------------|------|---------| -| 1 | 首次出现，观察 | 正常记录 | -| 2 | 重复出现 | 第二次就该彻底解决；未解决说明上次 Suggested Action 无效，需重新分析 | -| ≥3 | 系统性问题 | 需要根本性架构/流程改进，而非单次修复 | - -## 实际案例 -- Telegram chat ID 格式错误：`Recurrence-Count: 2` → 第二次直接应用 `Suggested Action: 使用纯数字 chat ID`，问题解决 -- 每日复盘：`Recurrence-Count: 9` → 说明这是一个持续活跃优化的领域，每次复盘都在积累经验 - -## 与 Pattern-Key 的关系 -- [[Pattern-Key]] 回答"这个问题属于哪一类" -- [[Recurrence-Count]] 回答"这类问题出现了多少次" - -两者配合使用：Pattern-Key 重复 + Recurrence-Count ≥ 2 = 需要系统性解决 - -## 相关 Concept -- [[Pattern-Key]]：Recurrence-Count 的分类维度 -- [[Self-Improving-Skill]]：Recurrence-Count 的承载结构 -- [[每日复盘机制]]：检查 Recurrence-Count 的执行时机 - -## Aliases -- recurrence count -- 重复次数 diff --git a/wiki/concepts/Recurring-Task.md b/wiki/concepts/Recurring-Task.md deleted file mode 100644 index cf07bdf9..00000000 --- a/wiki/concepts/Recurring-Task.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Recurring Task" -type: concept -tags: [] -sources: [] -last_updated: 2025-03-13 ---- - -## Definition -Recurring Task（重复任务）是指周期性自动创建新实例的任务机制，使用 `⏳ every week`/`⏳ every month` 等语法在 Obsidian Tasks 插件中实现，避免手动复制粘贴更新日期的重复劳动。 - -## Details -- **语法**：`⏳ every week`（每周）、`⏳ every month`（每月） -- **应用场景**：每周发布公众号文章、每月整理笔记等周期性事务 -- **优势**：彻底解放手动更新日期的重复劳动，任务完成后自动在下一个周期生成新任务实例 - -## Related Concepts -- [[Obsidian Tasks]]：Recurring Task 的实现插件 - -## Sources -- [[obsidian-tasks-插件-这可能是最适合懒人的任务管理方式]] diff --git a/wiki/concepts/Recurring-Tasks.md b/wiki/concepts/Recurring-Tasks.md deleted file mode 100644 index 1a644a18..00000000 --- a/wiki/concepts/Recurring-Tasks.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "Recurring Tasks" -type: concept -tags: [task-management, automation, productivity] -sources: [todoist-task-manager] -last_updated: 2026-04-21 ---- - -## Definition - -Recurring Tasks（重复任务）是指按照固定周期自动生成新实例的任务机制，如"每週一早上9点提交周报"或"每6个月看牙医"。Todoist 的 repeat_string 字段支持自然语言周期描述（every Monday, every 6 months），极大简化了周期性任务的设置复杂度。 - -## Aliases - -- Recurring Tasks -- 重复任务 -- Recurring Reminders -- 周期性任务 -- Repeating Tasks - -## Natural Language Repeat Patterns (Todoist) - -| 用户表述 | Todoist repeat_string | -|----------|----------------------| -| every Monday | "every monday" | -| every weekday | "every weekday" | -| every 2 weeks | "every 2 weeks" | -| every 6 months | "every 6 months" | -| monthly on the 1st | "monthly on the 1st" | -| every day at 9am | "every day at 9:00" | -| every Tuesday and Thursday | "every tuesday and thursday" | - -## AI Integration Pattern - -``` -用户："每6个月提醒我看牙医" -↓ Agent 解析为 repeat_string: "every 6 months" -↓ Todoist API 创建任务，含 due 和 repeat_string 字段 -↓ Todoist 自动在每个周期创建新实例 -``` - -## Key Relationships - -- [[Todoist API]] — repeat_string 是 Todoist API 的专属字段 -- [[Todoist Task Manager]] — 自然语言描述 → 重复任务创建 -- [[Morning Briefing]] — 重复任务中的周期性提醒（如每周一晨会） -- [[AI-Driven Task Extraction]] — 从邮件/消息中识别周期性任务需求 - -## Design Considerations - -- **命名规范**：重复任务标题应明确表达"周期性"含义（"季度复盘"而非"复盘"） -- **截止日期 vs 周期**：有明确截止的用 due_date，周期性的用 repeat_string -- **逾期容错**：Todoist 逾期后下一个实例会在修复日期创建（不跳跃），可通过 Agent 重新调度 diff --git a/wiki/concepts/Recursive-Self-Optimization.md b/wiki/concepts/Recursive-Self-Optimization.md deleted file mode 100644 index f0d4ad90..00000000 --- a/wiki/concepts/Recursive-Self-Optimization.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Recursive Self-Optimization" -type: concept -tags: [] ---- - -## Definition -递归自我优化是一种通过迭代自我修改构建稳定生成能力的计算框架——系统的目标不是直接产出最优输出，而是在生成器空间（Generator Space）中通过不断的"生成-优化-更新"循环收敛到稳定不动点。 - -## Formalization -给定： -- $\mathcal{I}$：意图空间（Intention Space） -- $\mathcal{G} \subseteq \mathcal{P}^{\mathcal{I}}$：生成器空间，每个生成器 $G: \mathcal{I} \to \mathcal{P}$ -- $O: \mathcal{P} \times \Omega \to \mathcal{P}$：优化算子 -- $M: \mathcal{G} \times \mathcal{P} \to \mathcal{G}$：元生成算子 - -系统演化： -``` -P = G(I) -P* = O(P, Ω) -G' = M(G, P*) -``` - -自映射 $\Phi: \mathcal{G} \to \mathcal{G}$ 定义为： -$$\Phi(G) = M\big(G, O(G(I), \Omega)\big)$$ - -迭代序列 $G_{n+1} = \Phi(G_n)$。 - -## Key Insight -系统的收敛目标不是某个特定的输出 $P^*$，而是生成器序列 $\{G_n\}$ 的极限行为。当 $\Phi$ 满足收缩性条件时： -$$G^* = \lim_{n \to \infty} \Phi^n(G_0)$$ -这就是**稳定生成能力**（Stable Generative Capability）。 - -## Sources -- [[a-formalization-of-recursive-self-optimizing-generative-systems]] - -## Connections -- [[Generator Space]] ← defines_the_space ← [[Recursive Self-Optimization]] -- [[Fixed-Point Semantics]] ← formalizes_convergence ← [[Recursive Self-Optimization]] -- [[Self-Improving AI]] ← is_applied_instance ← [[Recursive Self-Optimization]] -- [[Self-Improving-Skill]] ← concrete_implementation ← [[Recursive Self-Optimization]] diff --git a/wiki/concepts/Redis缓存.md b/wiki/concepts/Redis缓存.md deleted file mode 100644 index 53a048af..00000000 --- a/wiki/concepts/Redis缓存.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Redis缓存" -type: concept -tags: [software-engineering, redis, caching, performance, database] -sources: [开发经验与项目规范整理文档] -last_updated: 2025-12-30 ---- - -## Definition - -**Redis 缓存** 是利用 Redis 作为内存数据存储来缓存热点数据，从而提升系统读性能、降低数据库压力的技术方案。 - -## Core Principles - -- 作为缓存层极大提升系统「读性能」 -- 降低数据库访问压力 -- 提供计数、锁、队列、Session 等能力 -- 让系统更快、更稳定、更抗压 - -## Related Concepts - -- [[微服务架构]] — Redis 常作为服务间共享缓存或分布式锁服务 -- [[消息队列]] — Redis 支持 List 结构实现轻量级队列 -- [[输入-处理-输出模型]] — Redis 作为缓存（状态存储）在系统中的角色 - -## Source Reference - -来源：[[开发经验与项目规范整理文档]] diff --git a/wiki/concepts/Reentrancy.md b/wiki/concepts/Reentrancy.md deleted file mode 100644 index 57f07e6d..00000000 --- a/wiki/concepts/Reentrancy.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: "Reentrancy" -type: concept -tags: [smart-contract, vulnerability, defi, solidity, security] -sources: [blockchain-security-auditor] -last_updated: 2026-04-25 ---- - -## 中文定义 - -**重入攻击（Reentrancy）**：智能合约在执行外部调用后、在状态更新前，允许攻击者通过回调函数再次进入合约逻辑，从而在状态被正确更新前回滚执行、重复提取资金或操纵合约状态的漏洞类型。 - -## 问题描述 - -当合约 A 调用合约 B 的函数时，合约 B 可以在其 `receive()`/`fallback()` 函数中回调合约 A 的函数。如果合约 A 在外部调用之前读取了状态（如用户余额），但在该调用返回后才更新状态（清零余额），攻击者合约 B 可以在余额清零前回拨合约 A 的函数，再次触发提取逻辑。 - -## 攻击模式 - -### 1. 单函数重入（Single-Function Reentrancy） -最简单的模式：同一个函数在执行中被再次调用。The DAO 和 Curve Finance 属于此类。 - -### 2. 跨函数重入（Cross-Function Reentrancy） -攻击者通过不同的函数路径重入合约，利用状态不一致进行攻击。例如：`withdraw()` 读取的余额与 `transfer()` 检查的余额不同步。 - -### 3. 只读重入（Read-Only Reentrancy） -攻击者通过 `view` 函数读取合约状态（在外部调用期间），利用该状态作为预言机输入进行攻击，无需写入合约。 - -### 4. ERC-777 / ERC-1155 钩子重入 -即使合约没有 `receive()` 函数，使用 ERC-777 代币标准时，`transfer()` 会触发 `tokensReceived()` 钩子，攻击者可在钩子中重入。 - -## 防御机制 - -### Checks-Effects-Interactions Pattern -```solidity -// ✅ 正确顺序：先更新状态，再执行外部调用 -function withdraw() external { - uint256 amount = balances[msg.sender]; - require(amount > 0); - balances[msg.sender] = 0; // 先更新状态 - (bool success,) = msg.sender.call{value: amount}(""); // 后外部调用 - require(success); -} -``` - -### Reentrancy Guard -```solidity -import {ReentrancyGuard} from "@openzeppelin/contracts/utils/ReentrancyGuard.sol"; - -contract SecureVault is ReentrancyGuard { - function withdraw() external nonReentrant { - // nonReentrant 修饰符防止任何重入 - } -} -``` - -## 关键案例 -- [[The-DAO-2016]]：历史上首个大规模重入攻击，损失 360 万 ETH，直接导致 ETH/ETC 硬分叉 -- [[Curve-Finance]]：Vyper 编译器 bug 导致 nonreentrant 失效，损失超 7000 万美元 -- [[blockchain-security-auditor]] 的 Source Page 示例代码：展示了完整的有漏洞合约和修复后合约 - -## 关联概念 -- [[Access-Control]]：权限控制缺失会加剧重入攻击的影响 -- [[Flash-Loan-Attack]]：重入攻击常与闪电贷结合使用 -- Checks-Effects-Interactions Pattern：标准防御模式 -- [[Slither]]：Slither 的 `reentrancy-eth` 检测器可发现大多数经典重入漏洞 diff --git a/wiki/concepts/ReentrancyGuard.md b/wiki/concepts/ReentrancyGuard.md deleted file mode 100644 index 17cc8850..00000000 --- a/wiki/concepts/ReentrancyGuard.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "ReentrancyGuard" -type: concept -tags: [] -last_updated: 2026-05-01 ---- - -## Definition -ReentrancyGuard 是 OpenZeppelin 提供的修饰器（modifier），通过在函数入口设置 mutex 锁，防止合约函数在执行过程中被递归调用（re-entrancy），从而避免重入攻击。 - -## Implementation -```solidity -import {ReentrancyGuard} from "@openzeppelin/contracts/utils/ReentrancyGuard.sol"; - -contract Vault is ReentrancyGuard { - function withdraw() external nonReentrant { - // ... - msg.sender.call{value: amount}(""); - // 递归调用此函数会被 revert - } -} -``` - -## Limitations -- **不是万能药**：ReentrancyGuard 防止同一合约被递归调用，但不防止**跨合约**重入（跨合约重入需配合 ChecksEffectsInteractions 原则） -- **Gas 成本**：每次 nonReentrant 检查约消耗 200 gas -- **OpenZeppelin v5 改进**：v5 版本优化了检查逻辑，降低了 gas 成本 - -## 与 ChecksEffectsInteractions 的关系 -两者互补： -- ChecksEffectsInteractions 是**设计原则**——正确顺序的结构化思维 -- ReentrancyGuard 是**工程手段**——即使违反 CEI 也能防止单合约重入 - -最佳实践：**同时使用两者**，Guard 作为最后防线，CEI 作为代码结构规范。 - -## Sources -- [[engineering-solidity-smart-contract-engineer]] -- [[The-DAO]] -- [[OpenZeppelin]] diff --git a/wiki/concepts/Reference-Architecture.md b/wiki/concepts/Reference-Architecture.md deleted file mode 100644 index ef523335..00000000 --- a/wiki/concepts/Reference-Architecture.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Reference Architecture" -type: concept -sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-35-aws-landing-zone-design-refresher-saas-labs] -last_updated: 2026-04-14 ---- - -## Definition -参考架构（Reference Architecture）是一套经过实战验证的最佳实践集合，作为企业云平台部署的起点和蓝图。它定义了标准化的账户结构、网络拓扑、安全边界和服务组合，帮助组织快速建立符合安全和合规要求的云基础设施。 - -## Key Components - -### Account Structure -- **Core Accounts（核心账户）**： - - `Shared`：共享服务账户，提供 CI/CD 工具、NTP、DNS 等公共服务 - - `Logs`：日志账户，集中收集和存储所有账户的审计日志 - - `Security`：安全账户，托管 IAM 角色和联邦身份配置 -- **Workload Accounts（工作负载账户）**： - - `Prod`：生产环境账户 - - `Stage`：预发布环境账户 - - `Dev`：开发环境账户 - -### Network Topology -- Centralized network design with VPCs per account -- Transit Gateway for cross-account connectivity -- Shared services accessible via VPC peering or Transit Gateway - -## Relationship with Landing Zone -- **Reference Architecture**：标准化的起点和蓝图，定义通用模式 -- **Landing Zone**：基于 Reference Architecture 的具体部署单元，由各产品团队在 Gruntwork 仓库基础上定制 - -## Related Concepts -- [[Landing-Zone-Architecture]]：Reference Architecture 的具体部署实例 -- [[Federated-Access]]：安全账户的身份管理机制 -- [[Terraform-Modules]]：实现 Reference Architecture 的 IaC 模块库 - -## References -- [[ctp-topic-1-gruntwork-landing-zone-architecture]] -- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] diff --git a/wiki/concepts/Register-Switching.md b/wiki/concepts/Register-Switching.md deleted file mode 100644 index 70152f9e..00000000 --- a/wiki/concepts/Register-Switching.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Register Switching" -type: concept -tags: ["spanish", "linguistics", "translation", "formality", "tú", "usted", "vosotros"] -last_updated: 2026-05-02 ---- - -## Definition - -**Register Switching**（语域切换）指西班牙语中正式（usted）与非正式（tú/vos/vosotros）人称代词之间的选择与切换。语域选择决定说话者被视为朋友还是陌生人，错误选择可导致冒犯或误解。 - -## Spanish Register System - -| 代词 | 语域 | 使用场景 | -|---|---|---| -| **usted** | 正式（第二人称敬语） | 陌生人、服务业、正式场合、尊重长辈 | -| **tú** | 非正式（第二人称） | 朋友、熟人、年轻人之间 | -| **vos** | 非正式（阿根廷/乌拉圭等） | Rioplatense 西班牙语区域 | -| **vosotros** | 非正式复数（仅西班牙） | 西班牙国内非正式复数对话 | - -## Key Rules - -1. **陌生人默认 usted**：在墨西哥和大多数拉美国家，陌生人默认用 usted -2. **本地人先切换才跟随**：如果对方先用 tú，你才可以用 tú 回应；访客不应主动使用 tú -3. **服务业标准**：餐厅、出租车、商店——默认 usted -4. **阿根廷例外**：阿根廷广泛使用 vos，正式场合才用 usted - -## Cultural Nuance - -- 墨西哥：usted 是默认礼貌形式，即使在年轻人之间也逐渐转向 tú -- 哥伦比亚（波哥大）：某些地区即使亲密朋友间也保留 usted -- 西班牙：vosotros 替代 ustedes 用于非正式复数 -- 加勒比：语速快，可能模糊 usted/tú 的边界 - -## In Translation - -[[Language Translator]] Agent 必须： -- 每条翻译标注语域（正式/非正式/中性） -- 告知用户何时切换语域 -- 提供同一短语的不同语域版本 - -## Sources -- [[language-translator]] diff --git a/wiki/concepts/Relationship-Lifecycle.md b/wiki/concepts/Relationship-Lifecycle.md deleted file mode 100644 index fbb27346..00000000 --- a/wiki/concepts/Relationship-Lifecycle.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -title: "Relationship-Lifecycle" -type: concept -tags: [] -sources: [] -last_updated: 2026-05-30 ---- - -## 基本信息 -- **原文**：관계 수명주기 -- **中文**：商业关系生命周期 -- **英文**：Business Relationship Lifecycle -- **韩国商业语境**：소개 → 신뢰 → 계약 - -## 定义 -Relationship-Lifecycle 是 Korean Business Navigator 提出的韩国商业关系发展模型，将外国专业人员与韩国客户的关系分为三个阶段：**소개（介绍）** → **신뢰（信任）** → **계약（合同）**。每个阶段有完全不同的沟通策略、时机预期和成功标准。 - -## 三阶段模型 - -``` -소개（介绍） - ↓ [关系建立信号出现] -미팅（会议） - ↓ [多次接触后] -신뢰（信任） - ↓ [信任巩固后] -계약（合同） -``` - -## 第一阶段：소개（介绍） - -### 特征 -- 关系刚建立，双方都在评估对方 -- 对方持谨慎观望态度 -- 核心问题："这个人可靠吗？" -- **永远不要在第一阶段提价格** - -### 关键行动 -| 行动 | 正确做法 | -|------|---------| -| 首次接触 | 通过介绍人接入（冷接触响应率 < 5%）| -| 第一印象 | 专业但不咄咄逼人，展示行业知识而非推销 | -| 沟通渠道 | Email 或正式 KakaoTalk 消息，不用电话 | -| 跟进频率 | 每 1-2 周一次，不要过于频繁 | -| 定价讨论 | 绝对不可以在第一阶段提出具体数字 | - -### 成功信号 -- 对方愿意进行第二或第三次会议 -- 被邀请参加小型非正式场合（咖啡） -- 联系人主动介绍你给团队其他成员 - -## 第二阶段：신뢰（信任） - -### 特征 -- 双方已建立基本信任 -- 联系人愿意分享更多内部信息 -- 核心问题："这个人的能力如何？" -- 可以讨论具体方案，但价格仍需谨慎 - -### 关键行动 -| 行动 | 正确做法 | -|------|---------| -| 沟通渠道 | KakaoTalk 成为主要渠道 | -| 会议风格 | 更随意，更少正式 Presentation | -| 材料 | 提供内部可传阅的专业材料（案例、参考）| -| 价格讨论 | 可以给出参考范围，不给具体数字 | -| Proof Project | 进入信任阶段后是最佳提案时机 | - -### 成功信号 -- 被邀请参加회식 -- 联系人私下（非工作时间）联系你 -- 联系人开始用名字称呼你（或邀请你直呼其名） -- 联系人主动询问你的能力和方法论 - -## 第三阶段：계약（合同） - -### 特征 -- 信任已建立，进入正式商业讨论 -- 품의流程正式启动 -- 核心问题："内部审批能否通过？" -- 可以直接讨论价格和合同条款 - -### 关键行动 -| 行动 | 正确做法 | -|------|---------| -| 心态 | 从说服转向支持——帮助联系人内部推进 | -| 材料 | 提供联系人可用于内部品의的材料 | -| 跟进 | 适度（每周一次 SME，每月一次 财阀）| -| 价格 | 给出具体数字 | -| 催单 | 绝对不可以——帮助联系人在内部做 case | - -### 合同失败信号 -- 品의沉默超过 2 周且无"상부에서 검토 중입니다"信号 -- 联系人不主动更新进度（可能已有问题） -- 회식中对方态度变冷 - -## 季节性维护（关系跨越假期） - -| 时期 | 动态 | 策略 | -|------|------|------| -| 春节（1-2月）| 1-2周停摆，礼品预期 | 节前发送问候，节后联系 | -| 3-5月 | 新财年，预算新鲜 | 最佳新提案窗口 | -| 6月 | 略微放缓 | 推动待定决策 | -| 7-8月 | 暑期轮休 | 关系维护，不硬推 | -| 中秋（9-10月）| 主要假期，3-5天 | 同春节策略 | -| 10-11月 | 下年度预算规划期 | 最佳播种期（为次年1月合同）| -| 12月 | 年末冲刺 | 参加송년회（年末聚会），关系深化 | - -## 跨越生命周期失败的常见原因 -1. **第一阶段过早推价格** → 被归类为"vendor"，无信任建立 -2. **第二阶段不参加회식** → 信任无法深化 -3. **第三阶段过度催促** → 联系人在品의中感受到压力，逆向而行 -4. **越级联系** → 关系完全破裂 - -## 与西方销售漏斗的对比 - -| 维度 | 西方销售漏斗 | 韩国 Relationship-Lifecycle | -|------|------------|---------------------------| -| 核心驱动力 | 效率、速度 | 关系、信任 | -| 决策者接触 | 尽快接触高层 | 通过层层关系自然渗透 | -| 时间线 | 2-4 周 | 6-16 周 | -| 信任建立方式 | 资质/案例/推荐 | 多次接触 + 회식 + Proof Project | -| "不"的表达 | 直接拒绝 | 沉默或"検討해보겠습니다" | - -## 来源 -- [[specialized-korean-business-navigator]] — Workflow Process: Relationship Assessment 章节 diff --git a/wiki/concepts/Release-Management.md b/wiki/concepts/Release-Management.md deleted file mode 100644 index 74ec3676..00000000 --- a/wiki/concepts/Release-Management.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: "Release Management" -type: concept -tags: [devops, deployment, itsm] -date: 2025-03-01 ---- - -## Definition - -发布管理（Release Management）是[[ITSM]]的核心流程之一，负责**规划和协调软件从开发到生产的整个发布过程**，确保高质量、低风险的版本交付。 - -## Release Management Process - -``` -┌──────────────┐ ┌──────────────┐ ┌──────────────┐ -│ Release │ → │ Build & │ → │ Testing & │ -│ Planning │ │ Package │ │ Validation │ -└──────────────┘ └──────────────┘ └──────────────┘ - ↓ -┌──────────────┐ ┌──────────────┐ ┌──────────────┘ -│ Monitoring │ ← │ Deployment │ ← │ Staged │ -│ & Rollback │ │ to Prod │ │ Release │ -└──────────────┘ └──────────────┘ └──────────────┘ -``` - -## Modern Release Management (ITSM 2.0) - -在[[ITSM 2.0]]中，发布管理深度集成DevOps： - -### DevOps-Integrated ITSM - -| 实践 | 描述 | -|------|------| -| [[Canary-Release]] | 渐进式流量转移 | -| [[Blue-Green-Deployment]] | 零停机双环境部署 | -| Feature Flags | 特性开关控制 | -| Automated Rollback | 自动回滚 | - -### Progressive Delivery Patterns - -``` -Traditional: v1.0 → v1.1 → v1.2 (Big Bang) -Canary: v1.0 → [v1.1 → 5%] → [v1.1 → 20%] → v1.1 -Blue-Green: Blue[v1.0] ←→ Green[v1.1] (instant switch) -Feature Flags: v1.0 + [Flag:NewFeature=ON] (dynamic control) -``` - -## Key Metrics - -| 指标 | 描述 | -|------|------| -| Deployment Frequency | 部署频率 | -| Lead Time for Changes | 变更前置时间 | -| Time to Market | 上市时间 | -| Release Success Rate | 发布成功率 | - -## Related Concepts - -- [[ITSM]] — 父框架 -- [[Canary-Release]] — 金丝雀发布 -- [[Blue-Green-Deployment]] — 蓝绿部署 -- [[CI/CD-Pipeline]] — CI/CD流水线 -- [[Feature-Flag]] — 特性开关 -- [[Deployment-Automation]] — 部署自动化 - -## Sources - -- [[understanding-complete-itsm]] — DevOps-integrated Release Management diff --git a/wiki/concepts/Release-Readiness-Assessment.md b/wiki/concepts/Release-Readiness-Assessment.md deleted file mode 100644 index 2990578e..00000000 --- a/wiki/concepts/Release-Readiness-Assessment.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "Release Readiness Assessment" -type: concept -tags: [testing, quality, release-management] -sources: [testing-test-results-analyzer] -last_updated: 2026-04-28 ---- - -## Aliases -- Go/No-Go Decision -- Release Decision Framework -- Ship Readiness - -## Definition - -发布就绪度评估——通过多维度质量指标的量化分析，生成有统计依据的 GO/NO-GO 发布建议，并附带置信度和关键风险说明。 - -## Readiness Criteria (from TestResultsAnalyzer) - -```python -readiness_criteria = { - 'test_pass_rate': calculate_pass_rate(), # 测试通过率 - 'coverage_threshold': check_coverage_threshold(), # 覆盖率达标 - 'performance_sla': validate_performance_sla(), # 性能 SLA - 'security_compliance': check_security_compliance(), # 安全合规 - 'defect_density': calculate_defect_density(), # 缺陷密度 - 'risk_score': calculate_overall_risk_score() # 综合风险评分 -} - -# 统计置信度计算 -confidence_level = calculate_confidence_level(readiness_criteria) - -# 发布建议 -recommendation = generate_release_recommendation(readiness_criteria, confidence_level) -``` - -## Decision Matrix - -| 条件 | GO | NO-GO | -|------|-----|-------| -| 测试通过率 | ≥95% | <95% | -| 覆盖率 | ≥80% 行覆盖 | <80% | -| 性能 SLA | 全部达标 | 任何一项不达标 | -| 高风险缺陷 | 0 未关闭 | 有未关闭高风险缺陷 | -| 置信度 | ≥90% | <90% | - -## Key Principles - -- **Confidence Intervals Required**：所有指标必须附带置信区间，不接受无统计依据的结论。 -- **Risk-Adjusted Decision**：考虑质量债务对未来开发速度的影响。 -- **Trade-off Documentation**：任何放宽条件的决策必须书面记录理由。 - -## Connections - -- [[Quality-Metrics]]：评估依赖多维度质量指标。 -- [[Statistical-Analysis]]：置信度计算基于统计分析方法。 -- [[Quality-Gate]]：发布就绪度评估是质量门控的核心输出。 -- [[Defect-Prediction]]：预测的高风险区域影响就绪度评估。 diff --git a/wiki/concepts/Reliability-Engineering.md b/wiki/concepts/Reliability-Engineering.md deleted file mode 100644 index c941ef1a..00000000 --- a/wiki/concepts/Reliability-Engineering.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: "Reliability Engineering" -type: concept -tags: [] -sources: - - multi-agent-system-reliability -last_updated: 2026-04-28 ---- - -# Reliability Engineering - -## 定义 -可靠性工程——将LLM视为分布式系统中不可靠组件的工程哲学，而非"有感知"的智能体。 - -## 核心原则 -停止要求模型"小心"，开始**强制**其正确： - -1. **Constrained（约束）**：通过架构约束（如依赖图强制执行）而非提示词约束 -2. **Verified（验证）**：每个步骤有检查点，不合格则退回 -3. **Pruned（修剪）**：淘汰表现最差的Agent -4. **Challenged（挑战）**：通过对抗辩论让错误暴露 - -## 核心转变 -从"AI原型"（Prototype AI）到"企业级AI"（Enterprise AI）的范式转变： -- ❌ 将LLM视为神奇的聊天机器人 -- ✅ 将LLM视为不可靠的分布式组件 - -## 关键人物 -- [[Alex Ewerlöf]]：可靠性工程专家，KTH系统工程硕士，27年经验，专注将人类系统协作模式迁移至AI架构 - -## 来源 -- [[multi-agent-system-reliability]] diff --git a/wiki/concepts/ReliabilityBaseline.md b/wiki/concepts/ReliabilityBaseline.md deleted file mode 100644 index 42c150b7..00000000 --- a/wiki/concepts/ReliabilityBaseline.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "ReliabilityBaseline" -type: concept -tags: [] -last_updated: 2026-04-25 ---- - -# ReliabilityBaseline（可靠性基线） - -## Definition -每个重要工作流必须包含的可靠性最低保障组件，确保自动化系统在各种故障场景下仍能正确响应或优雅降级。 - -## Required Components - -### 1. Explicit Error Branches（显式错误分支） -每个工作流必须为每个可能失败的步骤定义明确的错误处理路径，不能依赖隐式或默认行为。 - -### 2. Idempotency / Duplicate Protection（幂等性/重复保护） -当工作流因重试被多次触发时，必须保证最终结果与单次执行一致（相同输入 → 相同输出，无重复副作用）。 - -### 3. Safe Retries with Stop Conditions（带停止条件的安全重试） -- 指数退避（exponential backoff）避免雪崩 -- 最大重试次数限制 -- 永久失败时触发告警并转入人工处理 - -### 4. Timeout Handling（超时处理） -每个外部调用必须设置合理的超时值，超时后触发预设的错误处理逻辑。 - -### 5. Alerting / Notification Behavior（告警/通知行为） -- 成功/失败状态变更必须通知责任人 -- SLA 即将超时前提前预警 -- 关键指标（如错误率）超过阈值时触发告警 - -### 6. Manual Fallback Path（人工降级路径） -当自动恢复失败时，必须有明确的人工操作路径（包含 SOP 文档和联系方式）。 - -## Logging Baseline（最小日志要求） -每个工作流执行必须记录： -1. 工作流名称和版本 -2. 执行时间戳 -3. 源系统 -4. 受影响实体 ID -5. 成功/失败状态 -6. 错误类型和简短原因说明 - -## Testing Baseline（验收测试要求） -生产推荐前必须通过： -1. Happy Path Test（正常路径测试） -2. Invalid Input Test（无效输入测试） -3. External Dependency Failure Test（外部依赖失败测试） -4. Duplicate Event Test（重复事件测试） -5. Fallback / Recovery Test（降级/恢复测试） -6. Scale / Repetition Sanity Check（规模/重复合理性检查） - -## Related Concepts -- [[N8nWorkflowStandard]]：可靠性基线嵌入在工作流的第 7-10 步中 -- [[DecisionFramework]]：通过决策框架评估后才进入可靠性实现阶段 -- [[AutomationGovernance]]：治理体系定义了可靠性基线的强制要求 - -## Sources -- [[automation-governance-architect]]（primary） diff --git a/wiki/concepts/Remote-Rescue.md b/wiki/concepts/Remote-Rescue.md deleted file mode 100644 index 344c63cd..00000000 --- a/wiki/concepts/Remote-Rescue.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Remote-Rescue" -type: concept -tags: [ai-agent, remote, troubleshooting] -sources: [aionui-cowork-desktop] -last_updated: 2026-04-27 ---- - -## Definition - -Remote-Rescue 是一种 AI Agent 远程故障修复能力——当 Agent（如 OpenClaw）不可达时，用户通过远程通道（Telegram/WebUI）接入 AionUi，使用内置部署专家执行诊断命令（`openclaw doctor`）、修复配置、重启 gateway，实现无需人到机器现场的远程修复。 - -## Key Characteristics -- **远程通道接入**：Telegram、WebUI、Lark、DingTalk -- **内置诊断专家**：内置 OpenClaw 部署专家，引导安装、诊断、修复 -- **自助修复能力**：`openclaw doctor` 诊断、自动修复配置、gateway 重启 -- **解决痛点**：Agent 坏了但人不在机器旁边的困境 - -## Related Concepts -- [[OpenClaw-Deployment-Expert]]：Remote-Rescue 的执行主体 -- [[Cowork-UI]]：Remote-Rescue 的用户交互界面 diff --git a/wiki/concepts/Remote-SSH.md b/wiki/concepts/Remote-SSH.md deleted file mode 100644 index a45ecfa8..00000000 --- a/wiki/concepts/Remote-SSH.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Remote-SSH" -type: concept -tags: [remote-development, ssh, ide] -last_updated: 2026-04-22 ---- - -## Definition -通过 SSH 协议将本地 IDE 连接到远程服务器的开发模式。代码实际运行在远程服务器上，但编辑器和 UI 交互发生在本地机器。 - -## Mechanism -1. 本地 IDE 安装 Remote-SSH 插件 -2. 通过 SSH Config 定义远程服务器连接信息 -3. 连接时在远程服务器自动安装轻量级代理（VS Code Server / Trae Server） -4. 所有文件编辑、终端、Git 操作均通过 SSH 隧道与远程服务器通信 - -## Key Features -- 代码不离开服务器，数据安全 -- 利用服务器算力（GPU、大内存）进行开发 -- 支持 Docker 容器 Attach 开发模式 -- 支持多终端窗口 -- SSH Agent Forwarding 可复用本地 SSH Key 访问 Git - -## Two Docker Development Modes -- **Attach 容器模式**：直接进入已在运行的 Docker 容器内部编辑代码，适合调试，环境完全隔离 -- **宿主机文件 + Docker CLI 模式**：编辑 Ubuntu 宿主机上的源码目录，在终端调用 docker compose，适合编排多容器配置 - -## Connections -- [[Trae]] — IDE 实现 -- [[Cursor]] — 支持 Remote-SSH -- [[SSH Config]] — 连接配置方式 -- [[SSH 免密登录]] — 前提条件 -- [[Attach 容器]] — 容器开发模式 -- [[Bind Mount]] — 开发环境代码挂载机制 -- [[Docker]] — 容器化开发环境 diff --git a/wiki/concepts/RemoteDevelopment.md b/wiki/concepts/RemoteDevelopment.md deleted file mode 100644 index d5594be3..00000000 --- a/wiki/concepts/RemoteDevelopment.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Remote Development" -type: concept -tags: [development, ssh, remote-workflow] -last_updated: 2026-04-17 ---- - -## Aliases -- Remote SSH -- Remote Development -- 远程开发 - -## Definition -通过 IDE 的远程连接功能，在远程服务器上进行代码开发、调试和部署，而本地机器仅作为 UI 终端。核心技术是 SSH 协议和远程插件生态（如 VS Code Remote-SSH、Trae Remote-SSH）。 - -## Core Components -- **SSH 免密登录**：通过 SSH Key 实现无密码认证，是远程连接的基础 -- **Remote Server**：运行代码和 Docker 服务的远程主机（Ubuntu Server 等） -- **IDE Client**：本地安装的代码编辑器，通过 SSH 隧道连接到远程服务器 -- **VS Code Server/Trae Server**：在远程服务器上安装的代理组件，负责处理文件操作和终端会话 - -## Workflow -1. 配置 SSH Config 文件，在本地定义远程主机的连接别名 -2. 安装 Remote-SSH 插件 -3. 连接远程主机，IDE 自动安装远程服务器组件 -4. 打开远程文件夹，开始开发 - -## Related Concepts -- [[Bind Mount]]：Docker 挂载方式，与远程开发配合实现代码实时同步 -- [[Docker Compose]]：远程开发项目的运行环境定义工具 -- [[Vibe Coding]]：通过 AI 增强的远程开发工作流 -- [[Trae]]：支持 Remote-SSH 的国产 AI IDE -- [[OpenCode]]：CLI 形态的远程 AI 编码 agent - -## Related Entities -- [[Trae]]：支持 Remote-SSH 的 IDE -- [[Ubuntu]]：常用远程开发主机操作系统 -- [[Tailscale]]：安全的公网远程访问工具 - -## References -- [[Trae远程开发部署指南]] — 完整的 Remote-SSH + Docker 开发配置指南 diff --git a/wiki/concepts/RemoteRescuePattern.md b/wiki/concepts/RemoteRescuePattern.md deleted file mode 100644 index 7034abef..00000000 --- a/wiki/concepts/RemoteRescuePattern.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Remote Rescue Pattern" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-22 ---- - -# Remote Rescue Pattern - -当主 Agent 在远程/无头服务器上发生故障且无法连接时，通过远程访问渠道（WebUI/Telegram）打开辅助管理工具，使用内置专家 Agent 执行诊断和修复命令来恢复主 Agent 连接的设计模式。 - -## 动机 - -- Agent 运行在另一台机器或无头服务器上时，Agent 本身故障意味着无法通过 Agent 进行自我修复 -- 用户物理上不在该机器旁，无法直接操作 -- 需要一种"元修复"能力：在不物理访问机器的情况下诊断和恢复 Agent - -## 机制 - -1. **远程访问通道**：通过 WebUI、Telegram、Lark、DingTalk 等渠道远程连接管理界面 -2. **内置专家 Agent**：管理界面内置主 Agent 的部署专家助手（如 OpenClaw Deployment Expert） -3. **诊断与修复**：专家 Agent 可执行 `openclaw doctor`、修复配置、重启网关等命令 -4. **恢复主 Agent**：修复完成后，用户重新连接主 Agent 继续工作 - -## 典型场景 - -- [[AionUi]] 内置 OpenClaw 部署专家，用户通过 Telegram 远程诊断修复 OpenClaw -- [[Self-Healing-Systems]] 中的分级自愈策略（自愈 → 远程专家介入 → 人工兜底） - -## 与 Self-Healing 的关系 - -Remote Rescue Pattern 是 [[Self-Healing-Systems]] 的一种补充手段： -- 自愈（Self-Healing）：Agent 自动检测并修复常见问题 -- 远程救援（Remote Rescue）：Agent 无法自愈时，通过远程专家介入 -- 人工兜底：远程专家无法解决时，需要物理访问或人工介入 - -## 相关工具 -- [[AionUi]]：OpenClaw Remote Rescue 的实现载体 -- [[OpenClaw]]：`openclaw doctor` 命令提供诊断能力 diff --git a/wiki/concepts/Renovate-Bot.md b/wiki/concepts/Renovate-Bot.md deleted file mode 100644 index 2470727f..00000000 --- a/wiki/concepts/Renovate-Bot.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "Renovate Bot" -type: concept -tags: - - Renovatebot - - Dependency-Update - - GitOps - - CI/CD -last_updated: 2026-04-14 ---- - -## Aliases -- Renovate -- renovatebot - -## Definition -开源的依赖自动化更新工具，通过扫描代码并自动提交 Pull Request 来保持依赖项处于最新状态。支持多种技术栈（Terraform、Terragrunt、Docker、npm、Maven、pre-commit hooks 等），依据 Semantic Versioning 规则判断更新级别。 - -## Key Features -- **Dependency Dashboard**：在 GitHub Issue 中汇总所有依赖状态、待处理的 PR 及更新选项，提供全局视角 -- **Managers 插件机制**：支持多种依赖文件类型（`terraform` 经理处理 `.tf` 文件，`dockerfile` 经理处理镜像标签等） -- **Rate Limiting**：防止瞬间产生过多 PR 导致 CI/CD 系统崩溃 -- **配置文件**：`renovate.json` 定义管理策略 - -## Use Cases -- 自动化更新 Docker 基础镜像版本 -- 自动更新 Terraform 模块版本引用 -- 自动更新 Terragrunt 依赖配置 -- 自动更新 pre-commit 钩子插件版本 - -## Related Concepts -- [[Dependency-Management]] — 依赖管理的广义概念 -- [[Semantic-Versioning]] — 版本控制规则 -- [[GitOps]] — Renovate Bot 是 GitOps 实践中依赖治理的重要工具 -- [[CI-CD-Pipeline]] — Renovate Bot 通常集成到 CI/CD 流水线中 - -## Related Sources -- [[ctp-topic-15-working-with-renovatebot]] diff --git a/wiki/concepts/Replication-Graph.md b/wiki/concepts/Replication-Graph.md deleted file mode 100644 index 7ea786c1..00000000 --- a/wiki/concepts/Replication-Graph.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Replication Graph" -type: concept -tags: [unreal-engine, networking, multiplayer, ue5] -sources: [unreal-multiplayer-architect] -last_updated: 2026-04-26 ---- - -## Definition -Replication Graph 是 UE5 的空间分区复制优化系统，用空间网格分区替代默认的扁平相关性模型。通过只向相关客户端复制区域内的 Actor，显著降低带宽消耗。核心机制：`UReplicationGraphNode_GridSpatialization2D`（开放世界空间网格）和自定义 `UReplicationGraphNode`（休眠 Actor 优化）。 - -## Core Mechanisms -- **空间网格分区**：基于 2D 空间网格，将世界划分为网格单元，每个单元仅复制给附近玩家 -- **休眠 Actor 优化**：NPC 等休眠 Actor 不在任何玩家附近时，以极低频率复制 -- **动态 relevancy**：根据客户端视角动态决定 Actor 的相关性 -- `UReplicationGraphNode_GridSpatialization2D`：开放世界空间分区节点 -- `UReplicationGraphNode`：可自定义的复制图节点基类 - -## Implementation -```cpp -// 启用 Replication Graph 插件 -// DefaultEngine.ini -[/Script/OnlineSubsystemUtils.IpNetDriver] -ReplicationGraphClassName=ReplicationGraph.UReplicationGraph - -// 自定义休眠节点 -UCLASS() -class UMyDormancyNode : public UReplicationGraphNode -{ - // 重写 DetermineWrites 会话逻辑 -}; -``` - -## Key Benefits -- 开放世界多人游戏中带宽降低 40%+ -- 仅复制视野内 Actor，减少不必要的网络流量 -- 可自定义节点类型适配特殊需求 - -## Network Profiling Commands -- `net.RepGraph.PrintAllNodes` — 打印所有复制图节点信息 -- Unreal Insights — 性能分析工具，测量复制图对带宽的影响 - -## Connection to Other Concepts -- [[Actor Replication]] — Replication Graph 是 Actor 复制的空间优化层 -- [[Server-Authoritative Model]] — 服务器权威通过复制图高效同步状态到客户端 -- [[Network Prediction]] — 预测系统依赖高效的复制同步 - -## Relationship to Agent -[[UnrealMultiplayerArchitect]] 使用 Replication Graph 作为生产级多人游戏的带宽优化方案，性能基准：\"Bandwidth per player < 15KB/s at maximum player count\"。 - -## Aliases -- UE5 Replication Graph -- Spatial Replication -- Grid Spatialization diff --git a/wiki/concepts/ReplicationGraph.md b/wiki/concepts/ReplicationGraph.md deleted file mode 100644 index 8a0e23f4..00000000 --- a/wiki/concepts/ReplicationGraph.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "Replication Graph" -type: concept -tags: ["unreal-engine", "networking", "optimization"] -sources: ["unreal-multiplayer-architect", "unreal-multiplayer-architect"] -last_updated: 2026-04-30 ---- - -## Aliases -- Replication Graph -- 复制图 -- 空间分区复制 - -## 定义 -Replication Graph 是 UE5 5.3+ 引入的网络复制优化框架，用空间分区替代默认的平面相关性模型，显著降低多人游戏的带宽消耗。 - -## 默认问题 -默认复制层使用平面列表，每个客户端需要检查所有 Actor 的相关性，大规模世界中效率低下。 - -## Replication Graph 优化 -### 空间网格划分 -使用 `UReplicationGraphNode_GridSpatialization2D` 将世界划分为网格单元，每个客户端只接收其附近单元内 Actor 的更新。 - -### 自定义节点 -- `UReplicationGraphNode_GridSpatialization2D` — 开放世界 Actor 复制 -- `UReplicationGraphNode_ActorList` — 低频更新 Actor -- 自定义节点 — 适配特定游戏需求 - -## 性能收益 -- 可将带宽降低 **40%** -- 减少每秒复制的 Actor 数量 -- 按玩家位置动态调整复制范围 - -## 使用方法 -1. 启用 ReplicationGraph Plugin -2. 创建自定义 `UGameInstanceReplicationMgr` 子类 -3. 实现 `CreateReplicationGraph()` 返回配置好的 Graph -4. 在 `.uproject` 文件中添加插件依赖 - -## 相关概念 -- [[Actor Replication]] — 复制图优化的底层机制 -- [[NetUpdateFrequency]] — 配合频率优化 -- [[Server-Authoritative Model]] — 复制图不影响权威模型 diff --git a/wiki/concepts/Repo-Mirroring.md b/wiki/concepts/Repo-Mirroring.md deleted file mode 100644 index b8cf19ee..00000000 --- a/wiki/concepts/Repo-Mirroring.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Repo Mirroring" -type: concept -tags: [Repo-Mirroring, Git, Synchronization, Migration, GitHub, GitLab] -sources: - - public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20 -last_updated: 2026-05-09 ---- - -## Repo Mirroring - -Repo Mirroring（仓库镜像同步）是一种将源代码仓库从一个平台同步到另一个平台的方案，在 GitHub Enterprise → GitLab 迁移中作为两种主要迁移策略之一。 - -## Definition - -镜像同步方案：在保留源 GitHub 仓库的同时，将仓库内容实时或定期同步到 GitLab，源仓库保持不变，允许双写（同时在两个平台操作）。 - -## 适用场景 - -- 需要在迁移过渡期保持 GitHub 仓库的外部访问权限 -- 有持续向 GitHub 提交的场景（如外部贡献者） -- 团队希望在正式切换前有充足的验证时间 - -## 优势 - -- **降低风险**：源仓库保持不变，回滚成本低 -- **渐进迁移**：可以逐步增加 GitLab 的使用比例 -- **并行验证**：新旧平台同时可用，便于对比验证 - -## 局限性 - -- 双平台维护增加运营成本 -- 同步延迟可能导致代码不一致 -- 不解决 CI/CD 流水线迁移问题 - -## 与 Shift and Lift 的对比 - -| 维度 | Mirroring | Shift and Lift | -|------|-----------|----------------| -| 源仓库 | 保持不变 | 废弃 | -| 流水线 | 保持原样 | 需重构 | -| 风险 | 低 | 中高 | -| 适用场景 | 过渡期验证 | 明确迁移决心后 | - -详见 [[Shift-and-Lift]] 迁移方案 - -## Sources - -- [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] diff --git a/wiki/concepts/Requirements-Gathering.md b/wiki/concepts/Requirements-Gathering.md deleted file mode 100644 index efc49116..00000000 --- a/wiki/concepts/Requirements-Gathering.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: "Requirements Gathering" -type: concept -tags: [Business-Analysis, Requirements, Agile] -sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109] -last_updated: 2026-05-11 ---- - -## Definition - -需求收集（Requirements Gathering）是将业务需求转化为可执行、可追踪的技术需求的过程。核心方法是将敏捷用户故事与结构化元数据相结合，为需求捕获增加严谨性。 - -## User Story + Metadata Approach - -纯用户故事（As a... I want... So that...）虽然能捕获 what（做什么）、who（谁来做）和 why（为什么），但缺乏以下关键维度： - -| 元数据维度 | 说明 | -|-----------|------| -| **版本**（Version） | 需求的历史变更记录 | -| **依赖**（Dependencies） | 与其他需求的关联关系 | -| **可追溯性**（Traceability） | 从 Epic → Feature → Story 的完整链路 | -| **时间**（Scheduling） | 计划交付时间 | -| **验收标准**（Acceptance Criteria） | 如何判断需求完成 | -| **分类**（Categorization） | 业务需求 / 技术需求 / 功能需求 | - -## Excel Template Example - -课程演示了车库业务（Garage Business）的需求管理 Excel 表，包含： -- User Story 描述 -- 版本号 -- 依赖关系 -- 可追溯性链接 -- 计划时间 -- 验收标准 -- 分类标签（业务 / 技术 / 功能） - -## Relationship to SAFe - -在 [[SAFe]]（Scaled Agile Framework）中，需求层次为： -- **Epic**（史诗）→ 大型业务价值单元 -- **Feature**（功能）→ 可独立交付的业务功能 -- **Capability**（能力）→ 跨团队的业务能力 -- **User Story**（用户故事）→ 具体用户视角的需求 -- **Non-Functional Requirements**（非功能需求）→ 性能、安全、可用性等 - -## Relationship to Other Concepts - -- [[INVEST]]：INVEST 原则用于检查用户故事质量 -- [[BOSCARD]]：BOSCARD 定义的范围指导需求收集的方向 -- [[Business-Analysis]]：需求收集是业务分析的核心活动之一 -- [[Stakeholder-Wheel]]：干系人识别是需求收集的前提 - -## Key Quote - -用户故事本身缺少严谨性，结合元数据后才能成为可管理的需求资产。 - -## Aliases -- 需求收集 -- 需求管理 -- User Story + Metadata diff --git a/wiki/concepts/Research-Triangulation.md b/wiki/concepts/Research-Triangulation.md deleted file mode 100644 index 7481bf1e..00000000 --- a/wiki/concepts/Research-Triangulation.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: "Research Triangulation" -type: concept -tags: [ux, research, triangulation, validation, methodology] -sources: [design-ux-researcher.md] -last_updated: 2026-04-24 ---- - -## Definition - -Research Triangulation（研究三角验证）是通过多种数据源、研究方法、研究者视角或理论框架交叉验证研究结论的方法。其核心目的是降低单一方法或视角带来的偏差，提高研究结论的可信度和可靠性。 - -## Types of Triangulation - -| 类型 | 说明 | 示例 | -|------|------|------| -| Data Triangulation | 使用多个数据源 | 访谈数据 + 问卷数据 + 行为数据 | -| Methodological Triangulation | 使用多种研究方法 | 定量问卷 + 定性访谈 | -| Investigator Triangulation | 多名研究者独立分析 | 两名研究员分别编码后比对 | -| Theoretical Triangulation | 使用多种理论框架解释 | 认知心理学 + 社会学视角 | - -## Relationship to Other Concepts - -- [[User-Research-Methodology]]：三角验证是研究方法论的核心质量保障机制 -- [[Qualitative-Quantitative-Research]]：定性与定量方法的结合是数据三角验证的典型实现 - -## Source - -- [[design-ux-researcher.md]] — UX Researcher Agent Personality diff --git a/wiki/concepts/ReservedInstances.md b/wiki/concepts/ReservedInstances.md deleted file mode 100644 index 233b842c..00000000 --- a/wiki/concepts/ReservedInstances.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: "Reserved Instances" -type: concept -tags: - - AWS - - Cost-Optimization - - FinOps -aliases: - - Reserved Instances - - RI - - 预留实例 -last_updated: 2026-05-12 ---- - -## Overview - -Reserved Instances（预留实例）通过预付费或无预付承诺，获得相比 On-Demand 最高 60-72% 的折扣。适用于稳定运行的长期工作负载。 - -## Key Characteristics - -- **承诺期限**：1年或3年 -- **支付选项**：全额预付、部分预付、无预付 -- **范围**：区域级或可用区级 -- **类型**：Standard（可交换）、Convertible（可转换） - -## When to Use - -- 生产环境中的稳定工作负载 -- 数据库实例 -- 核心业务应用 -- 7×24 运行的服务 - -## Related Pages - -- [[FinOps]] -- [[SavingsPlans]] -- [[SpotInstances]] -- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] -- [[ctp-topic-63-optimise-resource-cost-using-automation]] diff --git a/wiki/concepts/Resilience.md b/wiki/concepts/Resilience.md deleted file mode 100644 index dd3535a3..00000000 --- a/wiki/concepts/Resilience.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Resilience" -type: concept -tags: [sre, reliability, engineering, fault-tolerance] -last_updated: 2026-04-20 ---- - -# Resilience - -韧性（Resilience）是系统在面对故障、压力和变化时保持服务可用性的能力。SRE 的核心目标之一就是建立和维持系统韧性。 - -## Definition -韧性不仅是"不故障"，而是： -- **故障吸收**：系统能够吸收和缓解故障的影响 -- **快速恢复**：故障发生后能快速恢复正常服务 -- **适应性学习**：从故障中学习，持续改进 - -## The 5 Things Resilience Cannot Be Automated -Uptime Labs 总结了 5 种无法被自动化的韧性要素： - -### 1. Learning（学习） -从故障和Near-miss中提取经验教训，形成组织知识。 - -### 2. Decision-Making（决策） -在高压情况下做出正确判断，选择最优响应策略。 - -### 3. Prioritization（优先级排序） -在多个问题同时发生时，决定处理顺序。 - -### 4. Communication（沟通） -协调团队、通知利益相关者、管理期望。 - -### 5. Adaptation（适应） -根据新情况调整策略，不拘泥于预设剧本。 - -## SRE Practices for Resilience -- [[BlamelessPostMortem]]：从故障中学习 -- [[Self-Healing]]：自动化恢复机制 -- [[Observability]]：理解系统状态 -- [[Organizational-Second-Hit-Syndrome]]：理解组织层面的韧性 -- [[Chaos-Engineering]]：主动发现弱点 - -## Relationship to Other Concepts -- **Reliability** 是韧性的组成部分 -- **Fault Tolerance** 是实现韧性的手段之一 -- **Incident Response** 是韧性响应的执行过程 - -## Source -- SRE Weekly Issue #513 — [[sre-weekly-issue-513]] diff --git a/wiki/concepts/Resolver-Rules.md b/wiki/concepts/Resolver-Rules.md deleted file mode 100644 index 1065afee..00000000 --- a/wiki/concepts/Resolver-Rules.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Resolver Rules" -type: concept -tags: - - AWS - - DNS - - Networking -last_updated: 2026-04-28 ---- - -## Definition - -Resolver Rules（解析规则）是 AWS Route 53 Resolver 的核心配置对象，用于定义特定域名的 DNS 查询应转发至哪个目标 DNS 服务器（如本地数据中心的 On-prem DNS）。它们是实现混合云 DNS 解析的关键机制。 - -## Aliases -- Resolver Rules -- Route 53 Resolver Rules -- DNS Forwarding Rules - -## Key Characteristics - -- **域名匹配转发**：规则按域名模式（如 `*.corp.internal`）匹配查询，将匹配项转发至指定 IP 地址的 DNS 服务器 -- **共享机制**：通过 AWS RAM（Resource Access Manager）将规则跨账号共享给业务账户，业务 VPC 无需单独创建规则即可使用 -- **入站 vs 出站**：Resolver Rules 配合 Outbound Endpoint 使用；Inbound Endpoint 则处理反向（由外向内）的解析请求 -- **Terraform 自动化**：规则定义完全可通过 Terraform 声明式管理，集成到 Landing Zone 模块化供给流程中 -- **授权流程**：跨账号共享时，接受方账户需明确接受共享，规则才能生效 - -## Related Concepts -- [[Route-53-Resolver]] — Resolver Rules 是 Resolver 的配置对象 -- [[AWS-RAM]] — 跨账号共享规则的技术手段 -- [[Private-Hosted-Zone]] — 与 PHZ 互补：PHZ 覆盖私有域名直接解析，Rules 覆盖需转发至外部 DNS 的域名 -- [[AWS-Landing-Zone]] — 集中化 DNS 账号场景下的规则管理策略 - -## Sources -- [[ctp-topic-19-configuring-dns-within-aws-lzs]] diff --git a/wiki/concepts/Resource-Allocation.md b/wiki/concepts/Resource-Allocation.md deleted file mode 100644 index 84211c0e..00000000 --- a/wiki/concepts/Resource-Allocation.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Resource Allocation" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-25 ---- - -## Definition - -Resource Allocation（资源分配）是在有限资源约束下，将人力、预算、技术和时间的组合进行最优配置的过程。区别于单一项目的资源管理，Portfolio 层面的资源分配需要在多个项目和不同项目阶段之间进行优先级权衡。 - -## Key Dimensions - -- **Creative Resources**：设计师、创意人员、内容创作者 -- **Technical Resources**：工程师、开发人员、架构师 -- **Financial Resources**：预算分配、投资优先级 -- **Time Resources**：团队容量、时间盒规划 -- **Vendor Resources**：外部合作伙伴、自由职业者 - -## Portfolio-Level Principles - -- **Prioritization Framework**：基于战略价值的项目分级（Tier 1/2/Innovation Pipeline） -- **Capacity Planning**：团队容量与需求匹配，避免过载 -- **Trade-off Management**：短期交付与长期能力建设之间的权衡 -- **Dynamic Rebalancing**：根据 Portfolio Review 动态调整资源分配 - -## Relationship to Strategic Portfolio Management - -Resource Allocation 是 [[Strategic-Portfolio-Management]] 的核心子功能之一。在 [[Project-Management-Studio-Producer]] 的框架中，Resource Allocation Strategy 是 Strategic Portfolio Plan 的核心组成部分，包含： -- Team Capacity（当前和计划的团队组成） -- Skill Development（培训和能力建设优先级） -- External Partners（供应商和自由职业者战略关系） -- Budget Distribution（跨组合层级的投资分配） - -## Aliases -- Resource Planning -- Capacity Management -- Budget Allocation -- Talent Allocation diff --git a/wiki/concepts/Resource-Tagging.md b/wiki/concepts/Resource-Tagging.md deleted file mode 100644 index 9883fbf4..00000000 --- a/wiki/concepts/Resource-Tagging.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "Resource Tagging" -type: concept -tags: ["AWS", "Tagging", "Cloud-Governance", "Cost-Allocation", "Security"] -sources: ["ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security", "public-cloud-learning-sessions-opentext-tagging-standard-v2"] -last_updated: 2026-04-28 ---- - -## Definition -Resource Tagging（资源标签）是 AWS 及其他云平台中的元数据体系——在云资源上附加键值对，用于描述资源的业务属性、安全分类、运营信息等。标签是云环境动态化、自动化治理的基础。 - -## Standard Tag Taxonomy -在 OpenText/Micro Focus 云转型环境中，核心标签维度包括： - -| 标签键 | 说明 | 示例 | -|--------|------|------| -| `Owner` | 资源所有者（优先使用 PDL） | `Steve.Jarman@opentext.com` | -| `Team` | 团队名称 | `ADM`, `ITOM` | -| `Type` | 资源类型 | `R&D`, `Production` | -| `BU` / `BusinessUnit` | 业务单元 | `Octane`, `ArcSight` | -| `Product` | 所属产品 | `IDM`, `Operations` | -| `Environment` | 环境 | `Production`, `UAT`, `Dev` | -| `ServerRole` | 服务器角色 | `Web`, `DB`, `App` | -| `AppID` | 应用标识 | `OCT-HUB-001` | -| `Account` | AWS 账号 | `123456789012` | - -## Tagging as Security Foundation -在 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中，Steve Jarman 强调： -- **迁移规划前提**：在将资产迁移至云之前，必须先收集机器信息 → 理解迁移范围 → 应用正确标签 -- **标签即安全凭证**：传统基于 IP 的防火墙规则无法适应云环境动态性，标签成为安全策略的动态依据 -- **SCP 强制执行**：通过 [[SCP-Security-Control-Policy]] 拒绝标签不合规的资源创建 -- **Checkpoint 标签驱动**：Checkpoint Firewall 读取资源标签决定网络访问策略，标签缺失或错误导致流量被拦截 - -## Tagging Governance Workflow -``` -制定标签标准 → IaC 自动打标 → SCP 强制合规 → Tag Validation Tool 审计 → 修正不合规资源 -``` -（参考 [[ctp-topic-28-aws-tag-validation-tool]]） - -## Connections -- [[SCP-Security-Control-Policy]] — 标签是 SCP 的执行依据 -- [[Checkpoint-Firewall]] — 标签驱动防火墙策略 -- [[AWS-Landing-Zone]] — 标签体系是 LZ 治理的核心 -- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] -- [[public-cloud-learning-sessions-opentext-tagging-standard-v2]] diff --git a/wiki/concepts/ResponsesAPI.md b/wiki/concepts/ResponsesAPI.md deleted file mode 100644 index 16b86cac..00000000 --- a/wiki/concepts/ResponsesAPI.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "ResponsesAPI" -type: concept -tags: - - "openai" - - "api" - - "experimental" -sources: [] -last_updated: 2026-04-20 ---- - -## Overview - -Responses API 是 OpenAI 提供的实验性 API 格式，通过 `POST /v1/responses` 端点调用。相比 Chat Completions，其核心差异在于支持服务端对话状态维持（`previous_response_id`）和结构化事件流。 - -## Key Features - -- **服务端状态**：`previous_response_id` 参数让服务端维护对话历史 -- **结构化事件流**：SSE 事件包含 `text_delta`、`function_call`、`function_call_output` 等标准事件类型 -- **工具调用 UI**：可实现自定义结构化工具调用界面 - -## Current Limitation - -Open WebUI 目前在 Responses 模式下仍然客户端管理对话历史（每次请求发送完整消息列表），尚未充分利用 `previous_response_id`。当前 Responses 模式的主要优势是结构化事件流。 - -## See Also -- [[APIServer]] -- [[ChatCompletions]] diff --git a/wiki/concepts/Responsible-AI.md b/wiki/concepts/Responsible-AI.md deleted file mode 100644 index d2456ce0..00000000 --- a/wiki/concepts/Responsible-AI.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: "Responsible AI" -type: concept -tags: [AI, ethics, governance, responsible-AI, transparency] -sources: - - public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin - - public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec -last_updated: 2026-05-12 ---- - -## Definition -Responsible AI（负责任 AI）是一套确保 AI 系统安全、公平、透明和合规的原则和实践。AWS 在 Amazon Bedrock 中提供了 Guardrails for Amazon Bedrock，用于根据应用需求和负责任 AI 政策定制安全保障措施。 - -## Six Key Principles - -| 原则 | 描述 | -|------|------| -| **Fairness（公平性）** | 确保 AI 系统不会对特定群体产生偏见 | -| **Explainability（可解释性）** | 使 AI 决策过程透明可理解 | -| **Robustness（鲁棒性）** | 确保 AI 系统在各种条件下稳定可靠 | -| **Governance（治理）** | 建立清晰的 AI 使用和决策责任框架 | -| **Transparency（透明度）** | 公开 AI 系统的能力、局限和使用方式 | -| **Privacy & Security（隐私与安全）** | 保护用户数据，遵守隐私法规 | - -## AWS Implementation - -### Guardrails for Amazon Bedrock -Amazon Bedrock 提供的安全护栏服务，允许客户： -- 根据应用需求定制安全保障措施 -- 过滤有害内容 -- 实施负责任 AI 政策 -- 监控和审计 AI 交互 - -### Data Privacy -Amazon Bedrock 在数据隐私方面的保证： -- 用户数据不与第三方模型提供商共享 -- 提示词（Prompts）不与模型提供商共享 -- 仅在请求-响应周期内存储数据 -- 符合 GDPR 合规要求 - -## Related Concepts -- [[Amazon-Bedrock]] -- [[Guardrails-for-Amazon-Bedrock]] -- [[Foundation-Models]] - -## Sources -- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] diff --git a/wiki/concepts/Responsive-Breakpoints.md b/wiki/concepts/Responsive-Breakpoints.md deleted file mode 100644 index a082b7bf..00000000 --- a/wiki/concepts/Responsive-Breakpoints.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: "Responsive Breakpoints" -type: concept -tags: [css, responsive, mobile-first, breakpoints] -sources: [design-ux-architect.md] -last_updated: 2026-04-24 ---- - -## Definition - -Responsive Breakpoints 是移动优先的响应式设计断点策略，通过 CSS Media Queries 在不同视口宽度下提供差异化的布局和样式。 - -## Breakpoint Strategy - -- **Mobile First**：基础样式针对 320px+ 设计 -- **Tablet**：768px+ 增强 -- **Desktop**：1024px+ 完整功能 -- **Large**：1280px+ 优化 - -## Implementation - -```css -/* Base: Mobile (320px+) */ - -/* Tablet (768px+) */ -@media (min-width: 768px) { - .container { - max-width: 768px; - } - .grid-2-col { - grid-template-columns: 1fr 1fr; - } -} - -/* Desktop (1024px+) */ -@media (min-width: 1024px) { - .container { - max-width: 1024px; - } - .grid-2-col { - grid-template-columns: 1fr 1fr; - gap: var(--space-8); - } -} - -/* Large (1280px+) */ -@media (min-width: 1280px) { - .container { - max-width: 1280px; - } -} -``` - -## Related Concepts - -- [[Layout-Framework]]：基于断点策略的布局组件系统 -- [[CSS-Design-System]]：提供 spacing token 支持响应式间距 - -## Sources - -- [[design-ux-architect]] — Responsive Breakpoints 的完整定义 diff --git a/wiki/concepts/ResponsiveSearchAds.md b/wiki/concepts/ResponsiveSearchAds.md deleted file mode 100644 index bdcffbfd..00000000 --- a/wiki/concepts/ResponsiveSearchAds.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: "Responsive Search Ads" -type: concept -tags: ["google-ads", "ppc", "advertising", "creative"] ---- - -## Definition - -RSA（Responsive Search Ads，响应式搜索广告）是 Google Ads 的核心搜索广告格式，允许多个标题和描述自由组合，由系统自动测试并展示最优搭配。 - -## Core Structure - -- **15 条标题（Headlines）**：系统从 15 条候选标题中每次展示 3 条 -- **4 条描述（Descriptions）**：每次从 4 条中展示 1-2 条 -- **最终广告**：由算法从所有可能组合中选择最优展示 - -## 15-Headline Strategy - -The Agency 创意策略 Agent 设计的 15-headline 分类框架： - -| 类别 | 数量 | 用途 | -|------|------|------| -| 品牌（Brand） | 2-3 条 | 品牌名称、口号、信任背书 | -| 利益（Benefit） | 3-4 条 | 用户核心收益（成本/速度/效果） | -| 功能（Feature） | 2-3 条 | 具体功能、技术规格 | -| CTA（Call to Action） | 2-3 条 | 行动号召（立即注册/免费试用） | -| 社会证明（Social Proof） | 2-3 条 | 评价、认证、用户数 | - -## Pin Strategy - -通过 Pin 固定特定标题在特定位置，确保核心信息稳定展示： -- Pin 用于强制特定 headline 在固定位置显示 -- 用于品牌词广告保持核心信息一致 - -## Architecture Principles - -1. **组合可读性**：所有 15×4=60 种可能组合必须语法和逻辑上都能成立 -2. **关键词插入**：使用 `{KeyWord:Default}` 动态插入搜索词 -3. **长度适配**：30 字符标题截断规则、90 字符描述限制 -4. **差异化覆盖**：各 headline 应传递不同信息，避免大量重复 - -## Key Metrics - -- **Ad Strength**：Google 衡量 RSA 质量的评分，90%+ 达到 "Good" 或 "Excellent" 是目标 -- **Impression Share**：品牌展示份额基准 90%+，非品牌 40-60% -- ** CTR 基准**：行业平均 3-5%，高竞争行业 1-2% - -## Sources - -- [[paid-media-creative-strategist]] -- [[paid-media-ppc-strategist]] -- [[paid-media-auditor]] diff --git a/wiki/concepts/Retrieval.md b/wiki/concepts/Retrieval.md deleted file mode 100644 index 8296925b..00000000 --- a/wiki/concepts/Retrieval.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: "Retrieval" -type: concept -tags: [RAG, 向量检索, 语义搜索] -sources: [rag从入门到精通系列1-基础rag] -last_updated: 2025-01-16 ---- - -## Definition - -Retrieval（检索阶段）是 RAG 管道的第二阶段，根据用户问题的语义向量（Embedding Vector）在向量数据库中检索与之最相似的 Top-k 个文档块。 - -## Core Process - -``` -用户问题 → 问题向量化 → Vector Store 相似度检索 → 返回 Top-k 文档块 -``` - -1. **问题向量化**：将用户输入的自然语言问题通过相同的 Embedding Model 转换为向量 -2. **相似度计算**：Vector Store 计算问题向量与所有文档块向量的相似度（常用方法：余弦相似度、点积、欧氏距离） -3. **返回 Top-k 结果**：返回相似度最高的 k 个文档块作为检索结果 - -## Similarity Metrics - -| 方法 | 适用场景 | -|------|----------| -| 余弦相似度（Cosine） | 归一化向量，衡量方向相似性 | -| 点积（Dot Product） | 未归一化向量，兼顾 magnitude | -| 欧氏距离（L2） | 几何距离，适用低维空间 | - -## Retrieval Strategies - -- **Top-k Retrieval**：返回相似度最高的 k 个结果 -- **MMR（Maximal Marginal Relevance）**：平衡相关性和多样性，减少重复信息 -- **Hybrid Retrieval**：结合关键词检索（BM25）与向量检索 - -## Connections - -- [[Retrieval]] ← part_of ← [[RAG]] -- [[Retrieval]] ← uses ← [[Vector-Store]] -- [[Retrieval]] ← uses ← [[Embedding]] -- [[Retrieval]] ← feeds_into ← [[Generation]] - -## Aliases - -- Information Retrieval -- Semantic Search -- 向量检索 -- 语义检索 diff --git a/wiki/concepts/Review-Management.md b/wiki/concepts/Review-Management.md deleted file mode 100644 index d203df0e..00000000 --- a/wiki/concepts/Review-Management.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: "Review Management" -type: concept -tags: [] -sources: - - hospitality-guest-services -last_updated: 2026-05-02 ---- - -## Definition -Review Management（评价管理）是对宾客在 OTA（Expedia/Booking.com/TripAdvisor）及品牌直营渠道留下的点评进行主动监测、及时响应和战略性跟进的系统化管理。核心价值：**在线评分每提高1分，营收可增加高达9%**。 - -## Post-Stay Follow-Up Sequence（售后跟进序列） - -### Day of Checkout — 退房体验 -- 退房时当面询问："您离店前有任何想分享的体验吗？" -- 如有历史问题未解决："我们之前解决了[问题]，您对解决方案满意吗？" - -### 24 Hours After — Survey/Review Request -- 发送感谢邮件+调查链接 -- 鼓励在满意时发布点评："如体验出众，欢迎在[TripAdvisor/Google/Booking.com]分享" -- 邀请直接回复邮件解决遗留问题 - -## Negative Review Response Rules（差评响应规则） -- **响应时限**：24小时内 -- **响应态度**：永远不要防御性；承认问题；采取纠正行动 -- **响应内容**：具体承认问题+已采取/正在采取的纠正措施+邀请离线沟通 -- **禁忌**：公开承诺补偿（应在私下沟通） - -### Negative Review Response Template -``` -Dear [Guest Name], - -感谢您分享反馈。我对您的体验未达我们标准深感抱歉。 - -[具体承认问题] - -这不符合我们期望任何宾客体验的标准，您的反馈我已亲自重视。 -[具体已采取/正在采取的纠正措施] - -如您方便，我希望能直接与您沟通解决这个问题。 -请联系我：[邮箱/电话]。 - -期待有机会再次为您服务。 - -[姓名、职位、酒店名] -``` - -## Key Principles -- 每条点评都必须回复（好评+差评） -- 差评响应是公开的客户服务展示，不是辩论 -- 将差评视为服务恢复机会，争取宾客修改评分 - -## Connections -- [[Hospitality Guest Services]] ← 评价管理是宾客服务 Agent 售后阶段的核心技能 -- [[Service Recovery Protocol]] ← 有效的服务恢复是预防差评的关键 -- [[Loyalty Program Management]] ← 忠诚会员的点评影响权重更高，需优先跟进 - -## Aliases -- 在线评价管理 -- 口碑管理 -- OTA Review Management -- Guest Feedback Management diff --git a/wiki/concepts/Reviewer.md b/wiki/concepts/Reviewer.md deleted file mode 100644 index 5e7ba6e0..00000000 --- a/wiki/concepts/Reviewer.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "Reviewer" -type: concept -tags: [Agent, Skill, Design Pattern, ADK] -sources: [google-5个agent-skill设计模式-2026-03-19] -last_updated: 2026-03-19 ---- - -## Overview -Reviewer 是 Google ADK 发布的 5 种 Agent Skill 设计模式之一，将"检查什么"和"怎么检查"完全分离，指令保持静态，Agent 动态加载特定审查标准。 - -## Mechanism -- 审查标准存放在 `references/review-checklist.md` -- 可以是 Python 风格检查，也可以是 OWASP 安全检查 -- 同样的 Skill 基础设施，换个清单就是完全不同的专项审计 -- 强制输出按严重程度分组的结构化结果 - -## Use Cases -- Python 代码风格审查 -- OWASP 安全检查 -- 文档质量审计 -- 代码安全审计 - -## Implementation -``` -SKILL.md: 静态指令 -references/review-checklist.md: 动态审查标准 -→ 加载特定标准 → 结构化输出结果 -``` - -## Key Insight -> 传统的代码审查会把所有规则都写进 system prompt，结果越写越长。Reviewer 模式完美解决这个问题。 - -## Related Concepts -- [[ToolWrapper]]：另一个互补的 Skill 设计模式 -- [[Generator]]：可以生成待审查的内容 -- [[Pipeline]]：可以包含 Reviewer 步骤 double-check 成果 - -## Connections -- [[Google5个AgentSkill设计模式]] ← part_of ← [[Reviewer]] -- [[ADK]] ← published_by ← [[Reviewer]] diff --git a/wiki/concepts/Rightsizing.md b/wiki/concepts/Rightsizing.md deleted file mode 100644 index 31e3af9e..00000000 --- a/wiki/concepts/Rightsizing.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: "Rightsizing" -tags: - - devops - - finops - - cost-optimization - - cloud -created: 2026-04-25 ---- - -# Rightsizing - -## Definition - -Rightsizing 是通过持续分析资源使用趋势，**动态调整云资源配置**以消除过度配置（over-provisioning）和不足配置（under-provisioning）的方法。Agentic AI 持续监控 CPU/内存/存储使用率，自动建议或执行资源配置变更。 - -## 与 [[FinOps]] 的关系 - -Rightsizing 是 [[FinOps]] 成本优化的核心实践之一： - -``` -FinOps Framework: -├── Understand (云成本归因) -├── Optimize (Rightsizing ←) # ← 本页 -└── Operate (持续成本管理) -``` - -## 传统 vs AI-Driven Rightsizing - -| 维度 | 人工 Rightsizing | AI-Driven Rightsizing | -|------|-----------------|----------------------| -| 分析频率 | 季度/年度 | 实时/每日 | -| 数据范围 | 有限指标 | 全量指标 + 历史趋势 | -| 响应速度 | 数周 | 数小时 | -| 准确性 | 基于经验估算 | 基于实际使用数据 | - -## Agentic AI Rightsizing 能力 - -```python -Rightsizing_Dimensions = { - "Compute": "EKS/RDS/VMs 自动扩缩容", - "Storage": "S3 生命周期策略 + 存储类型优化", - "Network": "NAT Gateway 峰值优化", - "Database": "RDS 实例类型调整 + 连接池优化" -} -``` - -## 示例 - -> An AI agent analyzes 30 days of AWS EKS cluster metrics: -> - CPU utilization: 15% average, peaks at 40% during business hours -> - Memory utilization: 22% average, 60% during batch jobs -> - **Suggests**: -> - Downsize from m5.xlarge to m5.large (saves 40% compute cost) -> - Implement auto-scaling: 2-8 instances based on CPU > 60% -> - **Result**: 40% cost reduction, zero performance impact - -## 与 [[Multi-Cloud Cost Optimization]] 的关系 - -Rightsizing 是 [[Multi-Cloud Cost Optimization]] 的基础能力之一： - -``` -Multi-Cloud Cost Optimization: -├── Rightsizing ← (单云资源优化) -├── Spot/Reserved Instance Optimization -├── Multi-Cloud Resource Consolidation -└── Pricing Model Selection -``` - -## Related Concepts - -- [[FinOps]] — Rightsizing 是 FinOps 框架的组成部分 -- [[Multi-Cloud Cost Optimization]] — Rightsizing 的扩展场景 -- [[Cloud Cost Optimization]] — Rightsizing 的广义概念 -- [[Scalability]] — Rightsizing 的技术基础 - -## Related Sources - -- [[how-agentic-ai-can-help-for-cloud-devops]] diff --git a/wiki/concepts/Risk-Mitigation.md b/wiki/concepts/Risk-Mitigation.md deleted file mode 100644 index fe137897..00000000 --- a/wiki/concepts/Risk-Mitigation.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: Risk Mitigation -tags: [Cloud, Strategy, Risk-Management] ---- - -# Risk Mitigation - -## Overview - -**Risk Mitigation**（风险缓解）指通过策略、流程和技术手段降低潜在风险对业务影响的过程。在多云环境中，风险缓解是核心驱动力之一——通过跨多个提供商分配工作负载，消除单点故障，提高业务连续性。 - -## Cloud Risk Categories - -### 1. Provider Risks -| Risk | Description | Mitigation | -|------|-------------|------------| -| 服务中断 (Outage) | 单一提供商故障导致全局不可用 | 跨提供商冗余部署 | -| 价格变动 | 提供商大幅涨价影响成本 | 多提供商竞争性定价 | -| 服务终止 | 提供商停止服务 | 保持迁移能力 | -| 合规变化 | 提供商合规认证失效 | 多提供商合规组合 | - -### 2. Security Risks -| Risk | Description | Mitigation | -|------|-------------|------------| -| 数据泄露 | 安全漏洞导致数据外泄 | 多层安全策略 | -| DDoS 攻击 | 大规模网络攻击 | CDN + 多区域部署 | -| 内部威胁 | 员工不当操作 | 最小权限 + 审计 | - -### 3. Operational Risks -| Risk | Description | Mitigation | -|------|-------------|------------| -| 技能缺口 | 团队技能单一 | 跨平台培训 | -| 复杂性 | 多云管理复杂度 | 统一管理工具 | - -## Multi-Cloud Risk Mitigation Framework - -1. **Workload Distribution**: 关键工作负载跨 2-3 个提供商部署 -2. **Data Replication**: 跨提供商实时数据复制 -3. **Automated Failover**: 故障自动切换到备用提供商 -4. **Disaster Recovery (DR)**: 多云 DR 架构确保业务连续性 -5. **Contractual Protections**: SLA 条款和退出条款保护 - -## Risk Metrics - -| Metric | Description | Target | -|--------|-------------|--------| -| RTO (Recovery Time Objective) | 恢复时间目标 | < 4 hours | -| RPO (Recovery Point Objective) | 数据恢复点目标 | < 1 hour | -| SLA Uptime | 服务可用性 | > 99.9% | -| Mean Time to Recovery | 平均恢复时间 | < 30 minutes | - -## Related Concepts - -- [[High Availability]] -- [[Disaster Recovery]] -- [[Multi-Cloud Strategy]] -- [[Cloud Security]] -- [[Incident Management]] - -## Sources - -- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]] diff --git a/wiki/concepts/Robotic-Framework.md b/wiki/concepts/Robotic-Framework.md deleted file mode 100644 index e7823752..00000000 --- a/wiki/concepts/Robotic-Framework.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "Robotic Framework" -type: concept -tags: ["Automation", "Testing", "DevOps", "QA"] -sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"] -last_updated: 2026-05-08 ---- - -## Definition -Robotic Framework（机器人框架）是一种开源的自动化测试框架，在 Micro Focus AWS Landing Zone AMI 发布流程中用于自动化基本测试用例和验证，将单个 AMI 的验证时间从 3-4 天缩短至 60 分钟。 - -## Impact -- **传统验证**：3-4 天手动测试 -- **自动化验证**：60 分钟 -- **提升效率**：约 95% 时间节省 - -## Use Case in AMI Pipeline -在 AMI 发布前运行自动化验证，确保： -- OS 启动正常 -- 网络配置正确 -- SSM Agent 连接可用 -- 安全工具正常运行 -- 域加入功能正常 - -## Connections -- [[Amazon-Machine-Image]] — Robotic Framework 验证的对象 -- [[Jenkins-Multi-Branch-Pipeline]] — Robotic Framework 集成在 Jenkins 流水线中 -- [[AWS-Landing-Zone]] — Robotic Framework 是 AMI 发布自动化的一部分 diff --git a/wiki/concepts/Rollback-Rate.md b/wiki/concepts/Rollback-Rate.md deleted file mode 100644 index 65f35986..00000000 --- a/wiki/concepts/Rollback-Rate.md +++ /dev/null @@ -1,74 +0,0 @@ -# Rollback Rate - -## Definition -Rollback Rate is the proportion of deployments that are reverted (rolled back) to a previous stable version after being deployed to production. It measures how often deployments fail to the point where reverting becomes necessary. - -The DevOps Maturity Model explicitly lists Rollback Rate as one of the metrics for measuring DevOps maturity. - -## Why Rollback Rate Matters - -A high rollback rate indicates: -- Deployment quality issues -- Insufficient testing before deployment -- Gap between staging and production environments -- Unstable or risky deployment processes - -A low rollback rate indicates: -- High confidence in the deployment pipeline -- Comprehensive pre-production testing -- Stable deployment processes - -## Across DevOps Maturity Levels - -| Maturity | Rollback Rate Characteristic | -|----------|------------------------------| -| Phase 1 | High rollback rate — manual deployments, no automated testing, siloed teams, manual infrastructure | -| Phase 2 | Improving — automation reduces some risks, but manual interventions still cause rollbacks | -| Phase 3 | Lower — automated infrastructure and security scans reduce failures before deployment | -| Phase 4 | Reduced — performance testing, immutable infrastructure, dependency vulnerability management | -| Phase 5 | Minimal — zero human intervention, real-time decisions, rollback automation for fast recovery | - -## Relationship with Other Metrics - -### Rollback Rate and Change Failure Rate -- **Change Failure Rate**: All deployments that cause failures (regardless of rollback) -- **Rollback Rate**: Only deployments where the team explicitly chose to roll back - -A high CFR but low Rollback Rate could mean failures were fixed without rollback. A low CFR but high Rollback Rate suggests teams are overly cautious. - -### Rollback Rate and MTTR -- Rollback is often a strategy for reducing MTTR -- Fast rollback mechanisms enable quick recovery -- Organizations with mature CI/CD pipelines have both low rollback rates AND fast rollback capabilities - -## How to Reduce Rollback Rate - -### Technical Strategies -- Comprehensive pre-production testing -- Feature flags for gradual rollouts -- Canary deployments (route small % of traffic to new version) -- Blue-green deployments -- Comprehensive observability to detect issues before users notice -- A/B testing in production - -### Process Improvements -- Small batch deployments to limit blast radius -- Strict deployment criteria (all tests green, no open severity-1 bugs) -- Deployment freeze periods for critical systems -- Change advisory board for high-risk changes - -### Cultural Factors -- Psychological safety to admit when a deployment is failing -- Clear criteria for when to rollback vs fix-forward -- Blameless post-mortems to learn from rollbacks -- On-call engineers empowered to make rollback decisions - -## Sources -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] - -## Related Concepts -- [[concepts/Change-Failure-Rate]] -- [[concepts/MTTR]] -- [[concepts/DORA-Metrics]] -- [[concepts/Continuous-Deployment]] -- [[concepts/DevOps-Maturity]] diff --git a/wiki/concepts/Root-Cause-Analysis.md b/wiki/concepts/Root-Cause-Analysis.md deleted file mode 100644 index 65735dd0..00000000 --- a/wiki/concepts/Root-Cause-Analysis.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: "Root Cause Analysis" -tags: - - devops - - troubleshooting - - ai - - observability -created: 2026-04-25 ---- - -# Root Cause Analysis (RCA) - -## Definition - -Root Cause Analysis (RCA) 是通过系统化方法追溯问题根本原因的过程，而非仅处理表面症状。Agentic AI 通过跨层日志关联（计算、网络、应用），比人工更快定位问题根因，显著加速事故解决。 - -## Traditional vs AI-Driven RCA - -| 维度 | 传统 RCA | AI-Driven RCA | -|------|---------|--------------| -| 分析速度 | 数小时至数天 | 分钟级 | -| 数据范围 | 有限日志样本 | 全量日志 + 跨源关联 | -| 关联能力 | 依赖人工经验 | 自动跨层相关性分析 | -| 准确性 | 受经验影响 | 基于模式匹配的一致性 | -| 知识积累 | 个人经验为主 | 可学习的组织知识 | - -## Agentic AI RCA 工作流 - -``` -1. 异常检测 → CloudWatch/Stackdriver/Azure Monitor 告警触发 -2. 数据收集 → 自动聚合相关时间段的所有日志 -3. 跨层关联 → 关联 compute/networking/application 日志 -4. 模式匹配 → 匹配历史故障模式 -5. 根因输出 → 输出结构化根因报告 + 修复建议 -``` - -## AI-Driven RCA 示例 - -> AI agent monitoring AWS EKS detects a spike in error rates. It correlates: -> - Kubernetes pod logs (application layer) -> - VPC flow logs (network layer) -> - RDS metrics (database layer) -> - → Identifies: External API timeout causing connection pool exhaustion -> - → Suggests: Implement retry strategy with exponential backoff - -## 与 [[AIOps]] 的关系 - -RCA 是 [[AIOps]] 能力矩阵的核心组件： - -```python -AIOps_Capabilities = { - "Anomaly Detection": "检测异常模式", - "Root Cause Analysis": "自动诊断 ←", # ← 本页 - "Predictive Maintenance": "预测性维护", - "Smart Alerting": "减少告警疲劳", - "Automated Remediation": "自动修复", - "Capacity Optimization": "容量优化" -} -``` - -## Related Concepts - -- [[Self-Healing Systems]] — RCA 发现根因后触发自动修复 -- [[AIOps]] — RCA 是 AIOps 的核心能力 -- [[MTTR]] — RCA 速度直接影响 MTTR -- [[Observability]] — RCA 依赖可观测性数据 - -## Related Sources - -- [[how-agentic-ai-can-help-for-cloud-devops]] -- [[what-i-know-about-cloud-service-delivery-1]] diff --git a/wiki/concepts/Root-Terragrunt-HCL.md b/wiki/concepts/Root-Terragrunt-HCL.md deleted file mode 100644 index a55e456d..00000000 --- a/wiki/concepts/Root-Terragrunt-HCL.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: "Root Terragrunt HCL" -type: concept -tags: [Terraform, Terragrunt, IaC, Configuration, AWS] -sources: - - ctp-topic-16-cross-account-terraform-modules.md - - ctp-topic-48-terraform-vs-terragrunt.md -last_updated: 2026-05-15 ---- - -## Overview - -Root Terragrunt HCL 是项目根目录下的 `terragrunt.hcl` 配置文件，用于定义所有 Terraform 模块通用的远程状态存储（Remote State）和角色切换逻辑。它是 Terragrunt DRY（Don't Repeat Yourself）原则的核心体现。 - -## Key Responsibilities - -### 1. Remote State Configuration - -```hcl -remote_state { - backend = "s3" - config = { - bucket = "my-terraform-state" - key = "${path_relative_to_include()}/terraform.tfstate" - region = "us-east-1" - encrypt = true - dynamodb_table = "terraform-locks" - } -} -``` - -### 2. Cross-Account Role Switching - -```hcl -inputs = { - # 在跨账号场景中，通过 assume_role 切换到目标账号的角色 - assume_role_arn = "arn:aws:iam::TARGET_ACCOUNT:role/Cross-account-ECS-Deploy-Runner-Role" -} -``` - -## How It Works - -Terragrunt 通过继承机制将根目录的配置自动应用于所有子模块： - -1. **检测模块**：Jenkins 检测到模块目录 -2. **加载配置**：Terragrunt 加载根目录的 `terragrunt.hcl` -3. **注入变量**：自动将 remote_state 和 assume_role_arn 注入子模块 -4. **执行命令**：运行 `terragrunt plan/apply` - -## Relationship with Terragrunt - -- [[Terragrunt]] ← uses ← [[Root-Terragrunt-HCL]] -- [[Cross-account-Terraform-Modules]] ← configured_by ← [[Root-Terragrunt-HCL]] -- [[ECS-Deploy-Runner]] ← configured_by ← [[Root-Terragrunt-HCL]] - -## Key Differences: Local vs CI/CD - -| 环境 | Role 处理 | -|------|----------| -| **本地开发** | Terragrunt 自动从 HCL 配置 Assume Role，无需手动干预 | -| **Jenkins CI/CD** | EDR 使用 HCL 中配置的 assume_role_arn，通过 ECS 容器环境 Assume | - -## Related Concepts - -- [[Terragrunt]]：Terragrunt 是该配置的解析和执行引擎 -- [[TerraformState]]：remote_state 配置定义了状态文件存储位置 -- [[Assume-Role]]：assume_role_arn 配置控制跨账号角色切换 -- [[DRY-Principle]]：Root HCL 是 DRY 原则在 IaC 中的应用 diff --git a/wiki/concepts/Route-53-Resolver.md b/wiki/concepts/Route-53-Resolver.md deleted file mode 100644 index 51768b57..00000000 --- a/wiki/concepts/Route-53-Resolver.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: "Route 53 Resolver" -type: concept -tags: - - AWS - - DNS - - Networking -last_updated: 2026-04-28 ---- - -## Definition - -AWS Route 53 Resolver 是 Amazon Route 53 提供的 DNS 解析服务核心组件，负责在 VPC 与其他网络环境之间转发 DNS 查询。它提供两个关键端点类型：Inbound Endpoints（允许本地数据中心向 AWS VPC 发起 DNS 查询）和 Outbound Endpoints（允许 VPC 向本地 DNS 服务器转发查询），从而实现混合云环境的双向 DNS 解析。 - -## Aliases -- Route 53 Resolver -- AWS Resolver - -## Key Characteristics - -- **混合云 DNS 网关**：解决 VPC 内 AWS 资源与本地数据中心（On-prem）之间的域名解析互通问题 -- **Inbound Endpoint**：监听 ENI 上的 UDP/TCP 53 端口，接收来自本地网络的递归 DNS 查询 -- **Outbound Endpoint**：通过转发规则（Resolver Rules）将匹配特定域名的查询主动发送至指定 IP（如 On-prem DNS 服务器） -- **跨账号共享**：Resolver Rules 可通过 AWS RAM 共享给其他 AWS 账户，无需在各账户单独创建规则 -- **与 Private Hosted Zone 协同**：Resolver 自动优先查询 PHZ 中的记录，未命中时再使用转发规则 - -## Related Concepts -- [[Private-Hosted-Zone]] — 在 VPC 内部解析私有域名 -- [[Resolver-Rules]] — 定义域名转发逻辑 -- [[VPC-Association-Authorization]] — 跨账号 VPC 与 PHZ 关联的授权机制 -- [[AWS-Landing-Zone]] — 多账号环境下的 DNS 集中化管理背景 - -## Sources -- [[ctp-topic-19-configuring-dns-within-aws-lzs]] diff --git a/wiki/concepts/RuntimeVirtualTexturing.md b/wiki/concepts/RuntimeVirtualTexturing.md deleted file mode 100644 index 4e894a19..00000000 --- a/wiki/concepts/RuntimeVirtualTexturing.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: "RuntimeVirtualTexturing" -type: concept -tags: ["unreal-engine", "texturing", "landscape", "performance"] -sources: ["unreal-world-builder"] -last_updated: 2026-04-30 ---- - -## Aliases -- RVT -- Runtime Virtual Texturing -- 运行时虚拟纹理 - -## Definition -Runtime Virtual Texturing（RVT）是 Unreal Engine 5 的按需虚拟纹理技术，允许材质在运行时动态渲染到虚拟纹理空间，而非在着色器中实时计算多层混合。对于 Landscape 地形（> 2 层材质）和需要动态混合的复杂材质，RVT 是关键性能优化手段。 - -## RVT vs Traditional Layer Blending -| 方案 | 层数限制 | 性能特征 | -|------|---------|---------| -| 传统逐像素混合 | 2 层以内 | 层数增加线性增长 | -| RVT | 无硬性限制（实践建议 ≤ 8） | 固定虚拟纹理采样开销 | - -## Landscape 中的 RVT -- 超过 2 层 Landscape 材质时**必须**启用 RVT -- **RVT 分辨率**：每 4096m² 格子 2048×2048 -- **RVT 格式**：YCoCg 压缩（节省内存，相较 RGBA） -- **Virtual Texture Producer**：必须在 Landscape Actor 上启用 -- **RVT Output Volume**：每 4096m² 格子对齐放置 - -## Dynamic RVT Applications -RVT 可采样运行时数据驱动地形状态变化： -- 游戏标签（Gameplay Tags）驱动地形层权重 -- Decal Actor 投影湿气/雪/泥效果 -- 雨积累参数驱动 RVT 混合权重趋向湿表面层 - -## RVT Cache Warm-Up -Cinematic Camera 场景前必须预热 RVT Cache，否则初次渲染出现 LOD 闪烁。 - -## Connections -- [[Landscape]] ← 层混合优化 ← RuntimeVirtualTexturing -- [[UnrealWorldBuilder]] ← 地形材质 ← RuntimeVirtualTexturing -- [[UnrealEngine5]] ← 核心引擎 ← RuntimeVirtualTexturing - -## Sources -- [[unreal-world-builder]] diff --git a/wiki/concepts/S3-兼容对象存储.md b/wiki/concepts/S3-兼容对象存储.md deleted file mode 100644 index 7acb18bb..00000000 --- a/wiki/concepts/S3-兼容对象存储.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: S3-兼容对象存储 -type: concept -tags: [storage, s3, minio] -date: 2025-12-29 ---- - -# S3-兼容对象存储 - -## Definition -S3-兼容对象存储是指实现了 Amazon S3 API 的对象存储系统，可以在不修改代码的情况下替换 AWS S3 使用。包括 MinIO、Cloudflare R2、Backblaze B2、SeaweedFS 等。 - -## Core S3 Concepts - -| 概念 | 说明 | -|------|------| -| Bucket | 存储桶，类似顶级文件夹 | -| Object | 对象，文件及其元数据 | -| Key | 对象的唯一标识符（路径） | -| Region | 区域，物理位置 | -| ACL | 访问控制列表 | -| Policy | IAM 策略 | -| Presigned URL | 预签名 URL，限时访问 | - -## S3 vs Traditional Storage - -| 特性 | S3 对象存储 | 传统文件系统 | -|------|-------------|--------------| -| 访问方式 | HTTP API | 文件路径 | -| 扩展性 | 无限扩展 | 受限于单盘/RAID | -| 成本 | 按量计费 | 一次性硬件 | -| 元数据 | 键值对灵活扩展 | 固定属性 | -| 原子性 | 最终一致性 | 强一致性 | -| 版本控制 | 原生支持 | 需额外配置 | - -## MinIO Configuration for Zipline - -```yaml -environment: - STORAGE_ENGINE: s3 - S3_BUCKET: zipline-bucket - S3_ENDPOINT: http://minio:9000 - S3_ACCESS_KEY: admin - S3_SECRET_KEY: Abcd_1234 - S3_REGION: us-east-1 - S3_FORCE_PATH_STYLE: "true" # 重要：MinIO 需要此设置 -``` - -关键参数 `S3_FORCE_PATH_STYLE: "true"`： -- MinIO 默认使用虚拟主机风格（bucket.minio:9000） -- 部分应用需要路径风格（minio:9000/bucket） -- 设置为 true 确保兼容性 - -## Anonymous Access with mc - -```bash -# 设置别名 -mc alias set local http://192.168.3.17:9000 admin password - -# 创建 bucket -mc mb local/zipline-bucket - -# 设置匿名访问权限 -mc anonymous set public local/zipline-bucket # 公共读写 -mc anonymous set download local/zipline-bucket # 仅下载 - -# 查看匿名策略 -mc anonymous list local/zipline-bucket -``` - -## Cloud Provider Comparison - -| 提供商 | S3 兼容 | 出口流量计费 | 最小存储量 | 特色 | -|--------|----------|--------------|------------|------| -| AWS S3 | 原生 | $0.09/GB | 无 | 功能最全 | -| Cloudflare R2 | 是 | **免费** | 无 | 无出口费 | -| Backblaze B2 | 是 | $0.01/GB | 无 | 性价比高 | -| MinIO | 是 | 0 | 无 | 自托管 | -| SeaweedFS | 是 | 0 | 无 | 大文件优化 | - -## Use Cases - -1. **备份存储**：低频访问但需高持久性 -2. **静态资源**：CDN 回源存储 -3. **图床/媒体库**：直接 URL 访问 -4. **AI 模型权重**：大文件存储 - -## Connections -- [[MinIO]] ← implements ← [[S3-兼容对象存储]] -- [[Zipline]] ← uses ← [[S3-兼容对象存储]] -- [[图床]] ← backed by ← [[S3-兼容对象存储]] - -## Related Concepts -- [[对象存储]] -- [[图床]] -- [[数据一致性]] diff --git a/wiki/concepts/SAFe.md b/wiki/concepts/SAFe.md deleted file mode 100644 index 7f40fdba..00000000 --- a/wiki/concepts/SAFe.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "SAFe" -type: concept -tags: [Agile, Scaling, Framework, Requirements] -sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109] -last_updated: 2026-05-11 ---- - -## Definition - -SAFe（Scaled Agile Framework，规模化敏捷框架）是一种将敏捷实践扩展到大型企业和跨团队组织的框架方法，提供从团队级到投资组合级的完整敏捷实施路径。 - -## Requirements Hierarchy in SAFe - -SAFe 的需求层次与纯 Scrum 不同，包含更丰富的粒度： - -| 层级 | 名称 | 说明 | -|------|------|------| -| **Epic** | 史诗 | 最大业务价值单元，通常跨多个发布火车（Release Train） | -| **Capability** | 能力 | 跨多个团队的业务能力，通常需要多个迭代 | -| **Feature** | 功能 | 可独立交付的业务功能，有明确的投资回报 | -| **User Story** | 用户故事 | 具体用户视角的需求，遵循 INVEST 原则 | -| **Non-Functional Requirements (NFR)** | 非功能需求 | 性能、安全、可用性、可扩展性等质量属性 | - -## Why SAFe Matters - -纯用户故事（User Story）不足以管理大型企业的复杂需求： -- **Epic** 提供战略对齐——确保每个功能都与业务目标关联 -- **Capability** 桥接战略与执行——跨团队的协调单元 -- **Feature** 是可度量的投资单元——支持 PI Planning（Program Increment Planning） -- **NFR** 保障质量属性——避免只关注功能而忽视非功能需求 - -## Relationship to Other Concepts - -- [[Requirements-Gathering]]：SAFe 提供了完整的需求层次结构 -- [[INVEST]]：User Story 层级需遵循 INVEST 原则 -- [[Business-Analysis]]：业务分析师负责定义 Epic 和 Feature 层级 -- [[T-Shaped-Skills]]：SAFe 团队需要 T 型技能人才 - -## Aliases -- Scaled Agile Framework -- 规模化敏捷框架 -- SAFe Framework diff --git a/wiki/concepts/SAML-Authentication.md b/wiki/concepts/SAML-Authentication.md deleted file mode 100644 index 92498519..00000000 --- a/wiki/concepts/SAML-Authentication.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "SAML Authentication" -type: concept -tags: - - SAML - - Authentication - - SSO - - Security - - Identity -sources: - - public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee -last_updated: 2026-05-11 ---- - -## SAML Authentication - -SAML（Security Assertion Markup Language）是一种基于 XML 的开放标准身份认证协议，用于在身份提供商（IdP）和服务提供商（SP）之间交换认证和授权数据。[[AWS-End-User-Computing]] 中的 [[AppStream-2]] 支持 SAML-based Authentication。 - -## How It Works in AWS EUC Context - -SAML 认证在 AWS EUC 中的典型流程： -1. 用户向企业 IdP（如 Azure AD / Microsoft Entra ID）发起登录请求 -2. IdP 验证用户身份，生成 SAML 断言 -3. 断言转发给 AWS 服务（AppStream 2.0 或 Workspaces） -4. AWS 基于断言授予访问权限 - -## Benefits - -| 优势 | 说明 | -|------|------| -| **增强安全性** | 集中化身份管理，支持 MFA | -| **简化用户体验** | 单点登录（SSO），无需单独记忆每个服务密码 | -| **合规性** | 集中审计用户访问行为 | - -## Connections -- [[AppStream-2]] ← uses ← [[SAML-Authentication]] -- [[AWS-End-User-Computing]] ← supports ← [[SAML-Authentication]] -- [[Active-Directory-Integration]] ← often_used_with ← [[SAML-Authentication]] - -## Sources -- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]] diff --git a/wiki/concepts/SAST.md b/wiki/concepts/SAST.md deleted file mode 100644 index a2104334..00000000 --- a/wiki/concepts/SAST.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "SAST" -type: concept -tags: [security, static-analysis, devsecops, sast] -sources: ["what-is-devsecops-best-practices-benefits-and-tools"] -last_updated: 2025-12-19 ---- - -## Definition - -SAST（Static Application Security Testing，静态应用安全测试）是一种在不运行应用程序的情况下，通过分析源代码、字节码或二进制文件的结构和逻辑来发现安全漏洞的测试方法。 - -## Characteristics - -- **白盒测试**：需要访问源代码 -- **编码阶段使用**：在开发人员编写代码时即时发现漏洞 -- **零运行时开销**：无需执行程序，不影响性能 -- **高覆盖率**：可扫描整个代码库，发现逻辑复杂的安全问题 - -## Capabilities - -SAST 工具擅长发现以下类型的漏洞： -- SQL 注入（SQL Injection） -- 跨站脚本（XSS, Cross-Site Scripting） -- 缓冲区溢出（Buffer Overflow） -- 硬编码凭据 -- 不安全的直接对象引用 -- 缺少输入验证 - -## Limitations - -- 误报率较高（可能报告非真实漏洞） -- 无法发现运行时漏洞和配置问题 -- 对第三方库的分析能力有限（见 [[SCA]]） - -## Typical Tools - -- SonarQube -- Checkmarx -- Fortify -- Semgrep -- Bandit (Python) - -## Relationship with DevSecOps - -SAST 是 DevSecOps CI/CD 流水线的核心组成部分，通常在代码提交后自动触发，为开发人员提供即时反馈。属于 [[DevSecOps]] 工具链中的"左移"环节。 - -## Related Concepts - -- [[DAST]] — 动态应用安全测试，与 SAST 互补 -- [[IAST]] — 交互式应用安全测试，运行时分析 -- [[SCA]] — 软件成分分析，扫描第三方依赖 -- [[Shift Left]] — 左移策略，SAST 是其核心实践 diff --git a/wiki/concepts/SCA.md b/wiki/concepts/SCA.md deleted file mode 100644 index ca5a9a84..00000000 --- a/wiki/concepts/SCA.md +++ /dev/null @@ -1,71 +0,0 @@ -# SCA (Software Composition Analysis) - -## Definition -SCA tools focus on the various software components of an application, including libraries and frameworks, to find known security flaws. They help reveal vulnerabilities that may occur when using third-party components. - -## Aliases -- Software Composition Analysis -- Dependency Analysis -- Open Source Security - -## Characteristics -- **依赖分析**：扫描应用的所有第三方组件 -- **已知漏洞匹配**：与 CVE/NVD 数据库匹配 -- **许可证合规**：检查开源许可证合规性 -- **供应链安全**：关注依赖链中的安全问题 - -## What SCA Detects -- **已知漏洞**（Known Vulnerabilities） - - CVEs in dependencies - - Security advisories -- **过时组件**（Outdated Dependencies） - - Known vulnerabilities in old versions - - Missing security patches -- **许可证问题**（License Issues） - - GPL/AGPL restrictions - - Incompatible licenses -- **高风险依赖**（Risky Dependencies） - - Unmaintained packages - - Malicious packages - -## Common CVE Databases -- National Vulnerability Database (NVD) -- GitHub Advisory Database -- Snyk Vulnerability Database -- OSV (Open Source Vulnerabilities) - -## Tools -- [[Snyk]] — 专注开源安全的 SCA 工具 -- OWASP Dependency-Check -- WhiteSource (Mend) -- FOSSA -- Dependabot (GitHub) - -## Integration Points -- **CI/CD Pipeline**：在构建时自动扫描依赖 -- **IDE**：开发者本地实时检查 -- **Registry Scanning**：容器镜像仓库扫描 -- **SBOM Generation**：软件物料清单生成 - -## SBOM (Software Bill of Materials) -SCA 工具常用于生成 SBOM： -- 完整的依赖列表 -- 版本信息 -- 许可证信息 -- 漏洞状态 - -## Limitations -- 仅检测已知漏洞（零日漏洞无法检测） -- 需要保持漏洞数据库更新 -- 可能产生误报 - -## Related Concepts -- [[DevSecOps]] — SCA 是其重要组件 -- [[SAST]] — 静态应用安全测试 -- [[DAST]] — 动态应用安全测试 -- [[Supply-Chain-Security]] — 供应链安全 -- [[SBOM]] — 软件物料清单 -- [[Zero-Day-Vulnerability]] — 零日漏洞 - -## Sources -- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/SCP-Security-Control-Policy.md b/wiki/concepts/SCP-Security-Control-Policy.md deleted file mode 100644 index 18f40e7c..00000000 --- a/wiki/concepts/SCP-Security-Control-Policy.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "SCP (Security Control Policy)" -type: concept -tags: ["AWS", "Security", "Landing-Zone", "Tagging", "OU"] -sources: ["ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security"] -last_updated: 2026-04-28 ---- - -## Definition -SCP（Security Control Policy）是 AWS Organizations 中的一种策略类型，通过「显式拒绝」（deny）逻辑强制执行组织范围内的安全与合规规则。与 IAM 策略不同，SCP 作用于组织单元（OU）或账户级别，控制谁可以执行什么操作，而不是授予权限。 - -## Core Mechanism -- **基于标签的 SCP**：拒绝资源在不符合预期标签值的情况下被创建（如：拒绝在特定 OU 中创建没有 `Environment: Production` 标签的 EC2 实例） -- **OU 分层执行**：SCP 在 OU 层级自上而下继承，高层级 OU 的拒绝策略优先级最高 -- **防止标签篡改**：阻止普通用户通过修改标签（如从 `Team: ADM` 改为 `Team: ITOM`）绕过安全审计或访问控制 - -## In AWS Landing Zone Context -在 [[AWS-Landing-Zone]] 架构中，SCP 是 Landing Zone 治理的关键组件： -- 与 [[Checkpoint-Firewall]] 的标签驱动策略联动：SCPs 确保只有正确标记的资源进入云环境，Checkpoint 基于标签实施网络层访问控制 -- SCP 是「防护栏」（Guardrails）的核心实现手段 -- 补充 AWS IAM 的「授予权限」模型，提供强制拒绝能力 - -## Example Use Case -``` -# 拒绝在没有 Owner 标签的情况下创建 EC2 -{ - "Effect": "Deny", - "Action": "ec2:RunInstances", - "Resource": "arn:aws:ec2:*:*:instance/*", - "Condition": { - "Null": { - "aws:RequestTag/Owner": "true" - } - } -} -``` - -## Connections -- [[AWS-Landing-Zone]] — SCP 是 LZ 治理的核心工具 -- [[Checkpoint-Firewall]] — SCP + Checkpoint 构成标签驱动的端到端安全体系 -- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] -- [[ctp-topic-28-aws-tag-validation-tool]] — SCP 强制执行标签，Tag Validation Tool 审计存量资源 diff --git a/wiki/concepts/SCRM.md b/wiki/concepts/SCRM.md deleted file mode 100644 index 049b30b7..00000000 --- a/wiki/concepts/SCRM.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "SCRM" -type: concept -tags: ["scrm", "customer-relationship", "automation", "wecom", "private-domain"] -sources: ["marketing-private-domain-operator"] -last_updated: 2026-04-26 ---- - -# SCRM（社交客户关系管理） - -## Definition -SCRM（Social Customer Relationship Management，社交客户关系管理）是传统 CRM 的升级版，核心区别在于整合了社交平台（如企业微信）的用户行为数据和互动触点，实现更精细化的用户标签管理、自动化运营流程和多触点精准触达。 - -## Core Components -- **渠道码系统**：每个获客入口配置独立二维码，自动打标签、自动分配员工、自动发送差异化欢迎语 -- **标签体系**：按来源（包裹卡/直播/门店等）× 消费层级 × 生命周期阶段 × 兴趣偏好等维度打标 -- **自动化流程**：新客激活 → 社群邀请 → 首购引导 → 复购提醒 → 流失预警的全程自动化 -- **数据统一**：打通企业微信用户 ID 与小程序 OpenID，构建统一用户画像 - -## Key Tools（第三方 SCRM） -- Weiban Assistant（微伴助手） -- Dustfeng SCRM（尘锋 SCRM） -- Weisheng（微盛） -- Juzi Interactive（句子互动） - -## Automatic Tagging Rules Example -```yaml -- trigger: "First purchase completed" - add_tags: ["new_customer"] -- trigger: "30 days no interaction" - add_tags: ["dormant_customer"] - remove_tags: ["active_customer"] -- trigger: "Cumulative spend > 2000" - add_tags: ["high_value_customer", "vip_candidate"] -``` - -## Related Entities -- [[WeCom]] — SCRM 的核心数据源和触达渠道 - -## Related Concepts -- [[私域运营]] — SCRM 是私域运营的核心工具 -- [[用户生命周期管理]] — SCRM 支撑用户全生命周期自动化 diff --git a/wiki/concepts/SD-WAN.md b/wiki/concepts/SD-WAN.md deleted file mode 100644 index c3d8f973..00000000 --- a/wiki/concepts/SD-WAN.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: "SD-WAN (Software-Defined Wide Area Network)" -type: concept -tags: [AWS, Networking, WAN, Overlay, SASE] -sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] -last_updated: 2026-05-07 ---- - -## SD-WAN (Software-Defined Wide Area Network) - -SD-WAN（Software-Defined Wide Area Network）是一种软件定义的广域网技术，通过软件控制层对物理网络进行抽象，实现动态路径选择、负载均衡和自动化流量调度。 - -## Definition - -- **SD**: Software-Defined——网络控制平面与数据平面分离，通过软件集中管理 -- **WAN**: Wide Area Network——跨越地理区域的广域网 -- **核心价值**: 将底层物理网络（Underlay）抽象为逻辑 Overlay 网络，灵活调度流量 - -## In CTP Architecture - -在 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 中描述的演进路线： - -- **当前状态**: TGW 间路由依赖静态前缀列表，缺乏 BGP 动态路由，DR 场景需要人工干预 -- **演进目标**: 引入 [[SilverPeak]] SD-WAN 作为叠加网络（Overlay），在 AWS 中部署虚拟 SD-WAN 设备 -- **解决问题**: 动态路径选择、自动化流量调度，消除静态路由的局限性 - -## Key Properties - -| 属性 | 值 | -|------|-----| -| 架构类型 | Overlay Network（叠加网络） | -| 控制平面 | 软件集中控制，与硬件解耦 | -| 路径选择 | 基于实时链路质量（带宽、延迟、丢包率） | -| 部署模式 | 虚拟设备（vSIM 或纯软件） | -| 典型厂商 | Silver Peak, Viptela (Cisco), VeloCloud (VMware) | - -## Relationship to SASE - -SD-WAN 是 SASE（Secure Access Service Edge）架构的核心组件： -- SD-WAN 提供灵活的广域网连接 -- SASE 将 SD-WAN 与安全服务（SWG、CASB、ZTNA）整合 -- [[Prisma-Access]] 即为 Palo Alto Networks 的 SASE 产品 - -## Connections - -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 演进目标 ← [[SD-WAN]] -- [[SilverPeak]] ← 供应商 ← [[SD-WAN]] -- [[Overlay-Network]] ← 基于 ← [[SD-WAN]] -- [[Prisma-Access]] ← 整合 ← [[SD-WAN]] - -## Relationship to CTP Topic 31 - -在 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] 中，SSM 作为 SD-WAN 落地前的**临时/过渡方案**：SSM 提供零 VPN 的安全访问，而 SD-WAN 落地后将从网络层彻底解决多区域互联与安全策略统一管理问题。 - -## Sources - -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] -- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] diff --git a/wiki/concepts/SDDC.md b/wiki/concepts/SDDC.md deleted file mode 100644 index 77d577ff..00000000 --- a/wiki/concepts/SDDC.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Software-Defined Data Center (SDDC)" -type: concept -tags: - - VMware - - SDDC - - Cloud -last_updated: 2026-04-25 ---- - -## Software-Defined Data Center (SDDC) - -A data center approach where all infrastructure is virtualized and delivered as a service. In the context of VMC on AWS, the SDDC is the core deployment unit managed through vCenter. - -## Definition -SDDC extends the concept of software-defined computing (hypervisor), software-defined storage, and software-defined networking to the entire data center infrastructure. VMware Cloud on AWS deploys SDDCs on AWS infrastructure, managed through vCenter Server. - -## Key Characteristics -- **Virtualized Compute**: VMware vSphere runs on bare metal servers -- **Virtualized Storage**: Software-defined storage integrated with AWS storage -- **Virtualized Networking**: NSX provides software-defined networking -- **Unified Management**: vCenter Server manages the entire SDDC -- **Cloud-Native Integration**: Native access to AWS services - -## SDDC Management -- **VMware Cloud Services Portal**: Web-based portal for SDDC management -- **Developer Center**: API Explorer for programmatic access -- **Follow-Me-Help**: Access to VMware engineers for assistance - -## Connections -- [[VMware-Cloud-on-AWS]] ← deploys ← [[SDDC]] -- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[SDDC]] - -## Sources -- [[ctp-topic-43-vmware-cloud-on-aws]] diff --git a/wiki/concepts/SE-Linux-Enforcing.md b/wiki/concepts/SE-Linux-Enforcing.md deleted file mode 100644 index ec93f730..00000000 --- a/wiki/concepts/SE-Linux-Enforcing.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: "SE Linux Enforcing Mode" -type: concept -tags: - - Security - - Linux - - MAC - - Access Control -sources: - - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w -last_updated: 2026-04-24 ---- - -# SE Linux Enforcing Mode - -SE Linux（Security-Enhanced Linux）是美国国家安全局（NSA）开发的 Linux 内核安全模块，通过强制访问控制（MAC，Mandatory Access Control）机制，在传统的自主访问控制（DAC，Discretionary Access Control）之上增加了一层细粒度的安全策略。 - -## DAC vs MAC - -| 维度 | DAC（传统 Linux 权限） | MAC（SE Linux） | -|------|----------------------|----------------| -| 控制方式 | 所有者自主决定 | 系统统一策略强制执行 | -| 粒度 | 用户/组/其他 + rwx | 主体标签 + 客体标签 + 策略规则 | -| 绕过风险 | root 可修改任何权限 | 即使 root 也受策略约束 | -| 配置难度 | 简单（chmod/chown） | 复杂（需要策略编写） | - -## 关键概念 - -- **主体（Subject）**：进程，通常具有特定的安全上下文（如 `system_u:system_r:container_file_t`） -- **客体（Object）**：文件、目录、端口、进程等系统资源 -- **安全上下文（Security Context）**：格式为 `user:role:type[:level]` 的标签字符串 -- **策略规则（Policy Rules）**：定义哪些主体可以对哪些客体执行哪些操作的规则集合 -- **Enforcing 模式**：强制执行策略，违反策略的操作被拒绝并记录 -- **Permissive 模式**：仅记录违反策略的操作，不实际阻止 - -## Bottlerocket 中的 SE Linux - -Bottlerocket OS 默认启用 SE Linux enforcing 模式： -- **容器隔离**：每个容器运行在独立的安全上下文中，防止容器逃逸后影响宿主机或其他容器 -- **最小权限原则**：即使容器内获得 root 权限，其操作仍受 SE Linux 策略限制 -- **与容器运行时集成**：containerd、docker 等容器运行时通过 SE Linux 标签隔离不同容器的工作负载 - -## 常见 SE Linux 标签 - -| 标签 | 用途 | -|------|------| -| `unconfined_t` | 不受限制的进程 | -| `container_file_t` | 容器管理的文件（如 volume 挂载点） | -| `svirt_sandbox_file_t` | SELinux 虚拟沙箱文件标签 | -| `admin_t` | 系统管理员类型 | - -## 与其他安全机制的协同 - -- **与 AppArmor**：AppArmor 是 SE Linux 的替代方案，Ubuntu 默认使用 AppArmor -- **与 seccomp**：seccomp 限制进程可调用的系统调用，SE Linux 控制对系统对象的访问 -- **与 capabilities**：Linux capabilities 将 root 特权拆分为多个独立能力，SE Linux 在此基础上进一步限制能力的使用场景 - -## 故障排查 - -SE Linux enforcing 模式下，常见故障表现为"Permission denied"即使文件权限看起来正确： - -```bash -# 查看文件的安全上下文 -ls -Z /path/to/file - -# 查看进程的 SE Linux 上下文 -ps -Z - -# 临时切换为 Permissive 模式（调试用） -setenforce 0 - -# 查看 SE Linux 拒绝日志 -ausearch -m avc -ts recent -``` diff --git a/wiki/concepts/SES-Sandbox-Mode.md b/wiki/concepts/SES-Sandbox-Mode.md deleted file mode 100644 index b759a8eb..00000000 --- a/wiki/concepts/SES-Sandbox-Mode.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "SES Sandbox Mode" -type: concept -tags: - - AWS - - SES - - Email - - Security -date: 2026-04-14 ---- - -## Definition - -SES Sandbox Mode 是 AWS SES（Simple Email Service）的默认限制状态，新注册的 SES 账户在此状态下仅能向经过验证的收件人地址发送少量邮件，无法向外部地址自由发信。 - -## Sandbox Mode Restrictions - -- **仅限验证地址**：只能向已在 SES 中验证过的邮箱地址发送邮件 -- **发送限额低**：默认每日发送限额为 200 封/天 -- **无外部发信能力**：无法向普通外部邮箱地址（gmail.com、outlook.com 等）发送邮件 -- **申请审批制**：需通过 AWS Support 工单申请脱离沙箱 - -## How to Exit Sandbox Mode - -1. 在 SES 控制台确认已完成域名验证（已完成 DKIM 配置） -2. 提交 AWS Support 工单申请"生产访问权限" -3. 在工单中说明使用场景和预计发送量 -4. AWS 审批通过后，账户升级至生产模式 - -## Production Mode Capabilities - -脱离 Sandbox Mode 后： -- 可向任意外部邮箱地址发送邮件 -- 发送限额大幅提升（可申请更高配额） -- 可用于生产环境邮件发送 - -## Important Notes - -- 即使在生产模式下，仍需遵守 AWS SES 发送策略和最佳实践 -- 建议申请脱离 Sandbox Mode 后，同步配置 DMARC 策略保护域名声誉 -- 持续监控退回率（bounce rate）和投诉率（complaint rate），避免账户被封禁 - -## Related Concepts -- [[AWS-SES]]：Amazon Simple Email Service -- [[DKIM-Email-Authentication]]：邮件域名验证 -- [[Email-Security]]：邮件安全最佳实践 diff --git a/wiki/concepts/SHAP.md b/wiki/concepts/SHAP.md deleted file mode 100644 index 4a68d679..00000000 --- a/wiki/concepts/SHAP.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: "SHAP (SHapley Additive exPlanations)" -type: concept -tags: [model-interpretability, feature-attribution, explainable-ai] -sources: - - specialized-model-qa -last_updated: 2026-05-29 ---- - -## Definition - -SHAP（SHapley Additive exPlanations）是一种基于博弈论 Shapley 值的模型可解释性框架，为每个特征的贡献提供统一的量化度量。通过计算每个特征在所有可能的特征组合中的边际贡献均值，SHAP 给出唯一且公平的归因值。 - -## Core Concepts - -### Global Interpretability -- **SHAP Summary Plot (Beeswarm)**：同时展示特征值方向和影响幅度的散点图，横轴为 SHAP 值，纵轴为特征，颜色编码特征值高低 -- **SHAP Bar Plot**：各特征 mean |SHAP| 排序，展示整体特征重要性 -- **应用场景**：与文档化特征理由对比，识别未在方法论文档中讨论但实际影响显著的"隐性特征" - -### Local Interpretability -- **SHAP Waterfall Plot**：解释单个预测——从基础值（base value）出发，逐特征展示其推动预测的方向和幅度 -- **SHAP Force Plot**：可视化单个预测的特征贡献，常用于高风险决策解释 -- **应用场景**：边缘案例预测（top/bottom decile、误分类记录）的深度分析 - -### SHAP Interaction Values -- 检测特征之间的依赖和交互效应 -- 将总 SHAP 贡献分解为：主效应 + 交互效应 -- 用于识别模型学习到的非预期特征交互 - -## Usage - -```python -import shap - -explainer = shap.TreeExplainer(model) -shap_values = explainer.shap_values(X) - -# Global: beeswarm -shap.summary_plot(shap_values, X, show=False) -plt.savefig("shap_beeswarm.png", dpi=150) - -# Global: bar -shap.summary_plot(shap_values, X, plot_type="bar", show=False) -plt.savefig("shap_importance.png", dpi=150) - -# Local: waterfall -explanation = explainer(X.iloc[[idx]]) -shap.plots.waterfall(explanation[0], show=False) -plt.savefig(f"shap_waterfall_{idx}.png", dpi=150) -``` - -## Model QA 中的应用 - -Model QA Specialist 使用 SHAP 进行以下审计： -1. **全局分析**：对比 SHAP 特征重要性与文档化特征理由，发现未记录的高贡献特征 -2. **PDP 交叉验证**：SHAP 分析结合 PDP 验证特征方向是否符合预期 -3. **局部解释**：边缘案例的 SHAP waterfall 揭示模型决策机制 -4. **稳定性监测**：跨时间窗口的 SHAP 排名变化反映特征重要性漂移 - -## Relationship - -- **依赖** [[Population-Stability-Index]]：PSI 监测特征分布漂移，SHAP 监测特征贡献变化，两者结合才能完整评估模型健康度 -- **依赖** [[Calibration-Testing]]：SHAP 解释模型"为什么"预测，校准测试验证模型"多准确"预测 -- **依赖** [[Discrimination-Metrics]]：SHAP 贡献分析在 AUC/Gini 判定模型整体可用之后进行细节诊断 -- **支撑** [[Partial-Dependence-Plots]]：PDP 提供边际效应可视化，SHAP 提供精确归因，两者互补 - -## Key Limitations - -- 计算复杂度：精确 Shapley 值计算为指数级，TreeExplainer 对树模型高效但对神经网络等黑盒模型需用 KernelExplainer（采样近似） -- 交互效应分离：当特征高度相关时，Shapley 值归因可能不稳定 -- 基准依赖：Shapley 值的解释力取决于基准（base value）的选取 diff --git a/wiki/concepts/SKAdNetwork.md b/wiki/concepts/SKAdNetwork.md deleted file mode 100644 index f1185857..00000000 --- a/wiki/concepts/SKAdNetwork.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: "SKAdNetwork" -type: concept -tags: ["paid-media", "apple", "privacy", "attribution", "ios"] -last_updated: 2026-04-25 ---- - -## Aliases -- SKAN -- Apple SKAdNetwork -- iOS 14+ 隐私归因框架 - -## Overview -SKAdNetwork（SKAN）是 Apple 为 iOS 14+ 推出的隐私化广告归因框架，旨在 IDFA（Identifier for Advertisers）限制后，为广告主提供移动端安装归因能力。是 [[Paid Media Paid Social Strategist]] Agent 应对 iOS 隐私变化的核心概念。 - -## Definition -核心机制： -- **隐私保护**：不向广告主共享用户级 IDFA，仅提供聚合的安装归因数据 -- **转化值（Conversion Value）**：广告主可在 App 内设置最多 64 个唯一转化值（如"注册""付费"等），在回传窗口期后汇总上报 -- **回传窗口**：约 24-48 小时的转化回传窗口，延迟导致优化困难 -- **无细粒度数据**：无法按受众特征、创意维度拆分归因结果 - -**Aggregated Event Measurement（AEM）**：Apple 推出的补充方案，允许广告主在聚合层面测量更多 App 内事件。 - -## Connections -- [[Paid Media Paid Social Strategist]] Agent 的核心应对策略之一 -- 驱动了 [[Conversions API]] 的服务端补偿需求 -- 与 [[Custom Audience Engineering]] 在 iOS 端的受众构建能力受限 diff --git a/wiki/concepts/SLR.md b/wiki/concepts/SLR.md deleted file mode 100644 index 9bd40447..00000000 --- a/wiki/concepts/SLR.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "SLR" -type: concept -tags: [Service-Level, SLO, SRE, Monitoring, Cloud-Transformation] -last_updated: 2026-04-28 ---- - -## Definition - -SLR (Service Level Requirement，服务等级需求) 是组织对服务可靠性和性能的业务层面需求定义。它是从业务视角出发，对服务应达到的可用性和性能水平的正式要求，通常与 SLA（Service Level Agreement，对外承诺）和 SLO（Service Level Objective，内部目标）配套使用。 - -## Relationship with SLO and SLA - -``` -SLA（对外承诺）← 基于 ← SLO（内部目标）← 基于 ← SLR（业务需求） -``` - -| 层级 | 视角 | 说明 | -|------|------|------| -| SLR | 业务需求 | 产品/业务方对服务等级的实际需求 | -| SLO | 内部目标 | SRE/运维团队设定的内部可靠性目标（通常比 SLA 更严格） | -| SLA | 对外承诺 | 对客户的正式合同承诺 | - -## SLR in Cloud Transformation - -在云转型项目中，SRE 团队与产品团队协作定义 SLR/SLO 体系： -- **目标**：向产品团队做周/双周/月度指标汇报 -- **方法**：定义监控指标，从 SLI 向上汇总至 KPI -- **工具**：通过 Grafana 等可观测性工具展示 SLO 达成情况 - -## Relationship with Monitoring - -SLR 是监控体系设计的基础： -1. 从 SLR 导出具体的 SLI（Service Level Indicator） -2. SLI 对应具体的监控指标和告警规则 -3. 指标持续采集并与 SLO 比对，消耗 Error Budget - -## Sources - -- [[ctp-topic-30-managing-change]] diff --git a/wiki/concepts/SLS.md b/wiki/concepts/SLS.md deleted file mode 100644 index 600245f4..00000000 --- a/wiki/concepts/SLS.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: "SLS" -type: concept -tags: [] -sources: [] -last_updated: 2026-04-25 ---- - -## Aliases -- Serviceability Limit State（正常使用极限状态） -- 正常使用极限状态 -- 使用性极限状态 -- 挠度控制 -- Deflection Control - -## Definition - -正常使用极限状态（SLS, Serviceability Limit State）是结构设计中验证结构在正常使用时满足适用性要求的验算标准，关注的是结构的**使用功能、舒适度和耐久性**，而非安全性。SLS 验算确保建筑在使用荷载下不产生过大的变形、振动或裂缝，从而不影响正常使用。 - -## Core SLS Criteria - -| 验算项目 | 典型限值 | 规范来源 | -|---------|---------|---------| -| 楼板挠度（活荷载） | L/360（住宅）/ L/480（办公） | ACI 318 Appendix B | -| 梁挠度（活荷载） | L/360（吊顶）/ L/240（无吊顶） | AISC Steel Manual | -| 悬臂挠度 | L/180 | ACI 318 | -| 裂缝宽度（钢筋混凝土） | 0.3mm（室内）/ 0.4mm（室外） | EN 1992-1-1 | -| 振动（人致振动） | 频率 ≥ 5Hz（办公）/ 加速度 < 0.5% g | AISC Design Guide 11 | -| 裂缝宽度（梁） | 0.3mm（受拉钢筋保护层方向） | ACI 318-19 | - -## SLS vs ULS - -> **ULS 和 SLS 必须同时满足，方为合格设计。** -> ULS 是安全底线（结构会不会塌），SLS 是使用品质（结构会不会晃/裂/变形过大影响功能）。 - -**控制关系的两种典型场景：** - -1. **ULS 控制（Strength-Governed）**：高应力截面，承载力决定截面尺寸，挠度通常满足 - - 例子：高荷载短跨度钢梁 - -2. **SLS 控制（Deflection-Governed）**：低应力长跨度截面，挠度决定截面尺寸 - - 例子：活荷载下挠度超限的长跨度钢梁 → 需增大截面至 W24x55 - - 例子：预应力混凝土梁的反拱与长期挠度平衡 - -## SLS in Major Codes - -### Eurocode EN 1990 -- **SLS 组合**（特征组合/频遇组合/准永久组合）： - - 特征组合：Gk + Qk（不乘系数） - - 频遇组合：Gk + ψ1Qk（ψ1 为频遇系数） - - 准永久组合：Gk + ψ2Qk（ψ2 为准永久系数，ψ2 通常 < ψ1） -- **挠度限值**：Annex NA.A（UK NA）或各国附录规定，通常 L/250 - -### ACI 318 (Appendix B) -- **直接验算法**：计算总挠度 ΔT = ΔLP + ΔLT - Δi - - ΔLP：恒荷载产生的即时挠度 - - ΔLT：长期荷载（持续荷载）产生的挠度 - - Δi：反拱（预应力或柱顶升引起的向上位移） -- **容许挠度**：Table 24.2.2（ACI 318-19）按构件类型和吊顶条件规定限值 - -### AISC Steel Manual / AISC Design Guide 11 -- **挠度限值**：由使用者功能需求决定，无强制规范限值，但通常遵循 L/360 或 L/240 -- **振动验算**：高层楼板、人行天桥等人致振动，须验算固有频率和加速度响应 - -## Usage in Civil Engineer Agent - -Civil Engineer Agent 在每个计算包中**必须同时检查 ULS 和 SLS**： -1. 先验算 ULS（截面抗力是否足够） -2. 再验算 SLS（挠度/裂缝/振动是否满足限值） -3. 若 SLS 不满足 → **增大截面**（增加 Ix）或调整配筋 -4. **注明控制条件**：本次设计中由 SLS（挠度）控制，ULS 验算仅供参考 - -> **典型案例**：AISC 360 LRFD 钢梁 W21x44 — φMn ≥ Mu **通过 ULS**，但 δLL = 18.1mm > L/360 = 16.9mm **SLS 失败**，须增大至 W24x55。 diff --git a/wiki/concepts/SMACs.md b/wiki/concepts/SMACs.md deleted file mode 100644 index 02cd16fa..00000000 --- a/wiki/concepts/SMACs.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: SMACs -type: concept -tags: [Technology-Stack, Cloud, Digital-Transformation] -sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16, ctp-topic-57-product-backlog-managing-demand] ---- - -# SMACs - -**SMACs** 是 Social（社交）、Mobile（移动）、Analytics（分析）、Cloud（云）四种技术的组合，代表现代数字化转型的核心技术栈。 - -## Components - -| 字母 | 含义 | 技术示例 | -|------|------|----------| -| **S** | Social（社交） | 企业社交平台、协作工具 | -| **M** | Mobile（移动） | 移动应用、物联网设备 | -| **A** | Analytics（分析） | 大数据分析、机器学习 | -| **C** | Cloud（云） | 公有云、私有云、混合云 | - -## In OpenText Cloud Transformation - -在 OpenText 云转型中： -- **Oli Workflow** 正在集成到 SMACs 平台 -- **主服务目录（Combined Cloud Products Master Catalog）** 将嵌入 SMACs -- **Enterprise Iton 项目**（标准 OT SMACS 租户）正在进行中 - -## Goals - -- 统一数字化平台，提升服务交付效率 -- 支持业务单元 80% 场景下自助选择所需服务 -- 自动化履约流程，减少人工干预 - -## Related Concepts - -- [[Demand-Management]] — 需求管理 -- [[FinOps]] — 云财务运营 -- [[ITIL-Service-Management]] — ITIL 框架 -- [[Oli-Workflow]] — 审批工作流 - -## Related Entities - -- [[Tom-Bice]] — FinOps 团队负责人，推动 SMACS 集成 -- [[Octane]] — 需求管理平台 -- [[FPNA-Team]] — 预算验证团队 - -## Sources - -- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] -- [[sources/ctp-topic-57-product-backlog-managing-demand.md]] diff --git a/wiki/concepts/SOC2.md b/wiki/concepts/SOC2.md deleted file mode 100644 index f3d8fc6c..00000000 --- a/wiki/concepts/SOC2.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "SOC 2" -type: concept -tags: [] -sources: [compliance-auditor] -last_updated: 2026-04-30 ---- - -# SOC 2 - -## Aliases -- SOC2 -- SOC 2 Type I -- SOC 2 Type II -- Service Organization Control 2 - -## Definition - -SOC 2（Service Organization Control 2）是由美国注册会计师协会（AICPA）制定的信任服务标准认证框架，用于评估服务组织在安全性、可用性、处理完整性、保密性和隐私性五个信任服务标准方面的控制措施。 - -## Core Components - -### 信任服务标准（Trust Service Criteria） -1. **安全性（Security）**：系统受到保护，防止未授权访问 -2. **可用性（Availability）**：系统能够按照承诺运行 -3. **处理完整性（Processing Integrity）**：系统处理完整、有效、准确、及时 -4. **保密性（Confidentiality）**：指定为保密的信息得到保护 -5. **隐私性（Privacy）**：个人信息的收集、使用、保留和披露符合组织的隐私声明 - -### SOC 2 类型 -- **Type I**：评估控制措施在特定日期的设计适当性 -- **Type II**：评估控制措施在指定期间（通常6-12个月）的设计和运行有效性 - -## Related Concepts -- [[Gap Assessment]]：SOC 2 审计前的必备步骤 -- [[Evidence Collection]]：SOC 2 Type II 审计的核心要求——需证明控制在整个审计期间持续有效 -- [[Continuous Compliance]]：SOC 2 年度审计间隔期间的持续合规实践 - -## Related Sources -- [[compliance-auditor]] diff --git a/wiki/concepts/SOCKS5代理.md b/wiki/concepts/SOCKS5代理.md deleted file mode 100644 index 611ee779..00000000 --- a/wiki/concepts/SOCKS5代理.md +++ /dev/null @@ -1,74 +0,0 @@ -# SOCKS5代理 - -> SOCKS5，本地科学上网代理协议，监听 127.0.0.1:10808，在 Mac Mini、Ubuntu1、Ubuntu2 上正常运行，NAS 上仅本机监听。 - -## Overview -SOCKS5 代理是一种网络协议，通过 SOCKS 代理服务器转发客户端的网络请求，支持 TCP 和 UDP。本方案中各节点通过 v2rayA 或类似代理客户端在本地启动 SOCKS5 代理服务，供本机应用走科学上网通道。 - -## Node Status - -|| 节点 | IP | 端口 | 状态 | FRP 暴露 | -|------|-----|-----|------|----------| -| Mac Mini M4 | 127.0.0.1 | 10808 | ✅ 正常 | — | -| Ubuntu Server 1 | 127.0.0.1 | 10808 | ✅ 正常 | — | -| Ubuntu Server 2 | 127.0.0.1 | 10808 | ✅ 正常 | — | -| Synology NAS | 127.0.0.1 | 20170 | ❌ 仅本机监听 | 否 | - -## Usage Patterns - -### 终端命令级（ProxyChains） -ProxyChains 通过 LD_PRELOAD 劫持 socket 调用，强制任意终端命令走 SOCKS5 代理： -```bash -# /etc/proxychains4.conf -socks5 127.0.0.1 10808 - -# 使用 -proxychains4 curl https://google.com -``` - -### Git 全局代理 -Git 不读取系统环境变量，必须显式配置： -```bash -git config --global http.proxy socks5://127.0.0.1:10808 -git config --global https.proxy socks5://127.0.0.1:10808 -``` - -### Docker Daemon 代理 -通过 systemd drop-in 文件注入环境变量： -```bash -# /etc/systemd/system/docker.service.d/http-proxy.conf -[Service] -Environment="HTTP_PROXY=socks5://127.0.0.1:10808" -Environment="HTTPS_PROXY=socks5://127.0.0.1:10808" -``` - -### Docker 容器环境变量 -```bash -# 容器内使用 ALL_PROXY 环境变量 -docker run -e ALL_PROXY=socks5://172.24.0.1:10808 ... -``` - -## Key Distinction: socks5 vs socks5h -- **socks5**：DNS 解析在本地完成，可能 DNS 污染 -- **socks5h**：DNS 解析由代理服务器完成，防止本地 DNS 污染 - ```bash - curl -x socks5h://127.0.0.1:10808 https://google.com - ``` - -## Docker 网络网关 IP -Docker 容器内访问宿主机的 IP 不是 127.0.0.1（那是容器自身），而是 Docker 网络网关 IP： -- bridge 网络默认：`172.17.0.1` -- 自定义网络（如 compose 项目）：`172.24.0.1` - -## Related Concepts -- [[透明代理]] — V2RayA 通过 iptables 劫持系统出站流量 -- [[环境变量代理]] — HTTP_PROXY/HTTPS_PROXY/ALL_PROXY 环境变量 -- [[Docker-Daemon-Proxy]] — systemd drop-in 方式为 docker pull 配置代理 -- [[ProxyChains]] — 终端命令级流量劫持工具 -- [[Git 全局代理]] — Git 专用代理配置 - -## Related Entities -- [[v2rayA]] — NAS 上的 SOCKS5 代理来源（端口20170） -- [[Mac Mini M4]] — SOCKS5 代理节点之一 -- [[Ubuntu Server]] — SOCKS5 代理节点 -- [[Synology NAS DS718]] — v2rayA 部署位置（仅本机监听） diff --git a/wiki/concepts/SOUL.md.md b/wiki/concepts/SOUL.md.md deleted file mode 100644 index c1c89ec2..00000000 --- a/wiki/concepts/SOUL.md.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: "SOUL.md" -type: concept -tags: [OpenClaw, Agent, Personality] -sources: [万字讲透openclaw-workspace深度解析-2026-03-21] -last_updated: 2026-03-21 ---- - -## Definition - -**SOUL.md** 是 OpenClaw workspace 中定义 Agent **性格档案**的叙事性文档。与 AGENTS.md 的功能性定位（做什么、怎么做）不同，SOUL.md 偏向人格性——这个 Agent 是谁、有什么个性、说话什么风格、面对压力怎么反应。 - -## 与 AGENTS.md 的区别 - -| | AGENTS.md | SOUL.md | -|---|---|---| -| 定位 | 岗位说明书 | 性格档案 | -| 性质 | 功能性 | 人格性 | -| 内容 | 职责、边界、优先级 | 性格、沟通风格、价值观 | -| 风格 | 结构化规则 | 叙事性叙述 | - -## 应包含的内容 - -1. **自我叙事**：Agent 是什么样存在的描述 -2. **沟通风格**：口语化程度、类比习惯、礼貌性废话的处理 -3. **价值观和边界**：诚实第一、效率优先、用户主导 -4. **有趣的细节（可选）**：建立信任感的彩蛋式信息 - -## 核心价值 - -一个没有 SOUL.md 的 Agent，每次对话都像第一次见面——说话没有固定风格，遇到同样问题今天这么说、明天那么说。有精心设计的 SOUL.md 的 Agent，用户会形成"这个 AI 是有个性的"的奇妙感觉。 - -## 与 IDENTITY.md 的分工 - -- **IDENTITY.md**：结构化元数据（谁、长什么样、什么感觉） -- **SOUL.md**：叙事性性格文档（怎么思考、怎么行事、有什么执念） - -前者是名片，后者是人物小传。 - -## Related Concepts - -- [[AGENTS.md]] — 岗位说明书，与 SOUL.md 互补 -- [[IDENTITY.md]] — 结构化身份元数据，与 SOUL.md 叙事分工 -- [[USER.md]] — 用户偏好，与 SOUL.md 共同定义人机关系基本共识 -- [[OpenClaw]] — SOUL.md 所属的框架 - diff --git a/wiki/concepts/SPREAD-Strategy.md b/wiki/concepts/SPREAD-Strategy.md deleted file mode 100644 index f3932022..00000000 --- a/wiki/concepts/SPREAD-Strategy.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: "SPREAD Strategy" -type: concept -tags: [trading, prediction-market, arbitrage] -last_updated: 2026-05-18 ---- - -## Aliases -- Arbitrage Strategy -- 套利策略 -- 价差策略 - -## Definition -SPREAD 策略是一种套利交易策略，专用于 Polymarket 等预测市场。在预测市场中，每个问题的 YES 和 NO 代币价格之和理论上应等于 1（100%）。当两者之和大于 1.05 时，意味着市场定价存在偏差，存在无风险套利机会——同时买入 YES 和 NO，持有到期必然获得 5%+ 的无风险收益。 - -## How It Works -1. 监控 Polymarket 各市场的 YES + NO 价格之和 -2. 当价格之和 > 1.05 时触发套利信号 -3. 同时买入 YES 和 NO 代币 -4. 持有至事件结算（无论结果如何均获得固定收益） -5. 结算后获得约 5%+ 的无风险回报 - -## Parameters -- 套利价差阈值：YES + NO > 1.05 -- 最小预期收益：5%（扣除手续费前） -- 持仓周期：事件结束时间 - -## Risk Considerations -- 需要足够的流动性确保成交 -- 手续费可能侵蚀套利收益 -- 市场流动性不足时可能无法完成完整套利 - -## Related Strategies -- [[TAIL Strategy]]：趋势跟踪策略，在市场有明确趋势时顺势操作 -- [[BONDING Strategy]]：逆向策略，在市场过度反应时反向操作 - -## Source -- [[polymarket-autopilot]] diff --git a/wiki/concepts/SRE.md b/wiki/concepts/SRE.md deleted file mode 100644 index b8b35e28..00000000 --- a/wiki/concepts/SRE.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "SRE" -type: concept -tags: [SRE, Site-Reliability-Engineering, DevOps, Automation, Cloud-Transformation] -last_updated: 2026-04-28 ---- - -## Definition - -SRE (Site Reliability Engineering，站点可靠性工程) 是一种通过软件工程思维解决运维问题的方法论。其核心理念是打破传统运维与产品开发之间的壁垒，通过自动化、可靠性测量和系统性方法提高服务质量。SRE 起源于 Google，现已被广泛应用于云原生和企业 IT 环境。 - -## Core Principles - -### 1. 将错误视为学习机会 -SRE 将故障和错误视为改进系统的机会，而非单纯追究责任。通过 Post-mortem 和 CAPA 流程从事故中提取根本原因。 - -### 2. 拥抱风险 -SRE 接受服务存在固有风险，通过 Error Budget 和 SLO 量化可接受的可靠性水平，在创新速度与稳定性之间取得平衡。 - -### 3. 消除 toil（重复性手工劳动） -Toil 是指那些手动、重复性、可自动化、缺乏持久价值且随规模线性增长的工作。SRE 团队应将 toil 控制在 50% 以下，其余时间用于系统性改进和功能开发。 - -### 4. 自动化一切可自动化的 -通过 IaC（基础设施即代码）和 CI/CD Pipeline 将变更实现完全自动化，减少人工审批环节和出错概率。 - -### 5. 可测量性优先 -所有系统行为都需要可观测性指标支撑（SLI/SLO/SLA），通过监控和告警实现问题的早期发现。 - -## SRE Team Collaboration Model - -SRE 团队在云转型项目中与产品团队在三个阶段协作： - -| 阶段 | 说明 | SRE 职责 | -|------|------|----------| -| Build（构建） | 产品基础设施搭建阶段 | 定义技术架构、共享 IaC 模块、定义 SLO/SLR | -| Early Live Support（早期上线支持） | Build 与 BAU 之间的过渡阶段 | 完成 Go-Live Checklist（监控覆盖、支持模型、事件响应流程） | -| BAU（日常运维） | 持续运营阶段 | 周/双周/月度指标汇报、持续改进 | - -## Key Metrics - -- **SLI (Service Level Indicator)**：服务等级指标，直接测量的系统指标（如可用性、延迟） -- **SLO (Service Level Objective)**：服务等级目标，SLI 的目标值（如 99.9% 可用性） -- **Error Budget**：错误预算，SLO 允许范围内的错误配额，用于指导发布节奏 -- **Toil**：重复性手工劳动，应控制在 50% 以下 - -## Relationship with DevOps - -SRE 是 DevOps 理念的具体实现形式之一。DevOps 强调打破开发与运维的边界，SRE 则通过量化指标（Error Budget、SLO）和自动化工具将这一理念落地。 - -## Sources - -- [[ctp-topic-30-managing-change]] -- [[ctp-topic-41-nfrs-and-error-budgets]] -- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] diff --git a/wiki/concepts/SSE-Server-Sent-Events.md b/wiki/concepts/SSE-Server-Sent-Events.md deleted file mode 100644 index 0b9f4552..00000000 --- a/wiki/concepts/SSE-Server-Sent-Events.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: "SSE（Server-Sent Events）" -type: concept -tags: [web, realtime, mcp, protocol] -sources: [] -last_updated: 2026-04-22 ---- - -## Overview -SSE（Server-Sent Events，服务器推送事件）是一种服务器向客户端推送实时事件的技术标准。在 MCP 协议中，SSE 作为一种接入方式，用于建立 MCP Client 与 MCP Server 之间的实时通信通道。 - -## Aliases -- Server-Sent Events -- 服务端推送事件 -- HTML5 Server-Sent Events - -## Key Characteristics -- **单向通信**：服务器主动向客户端推送数据，客户端无需轮询 -- **基于 HTTP**：使用标准 HTTP 协议，兼容性好 -- **自动重连**：浏览器端自动处理连接断开和重连 -- **MCP 接入方式**：作为 MCP Server 的一种连接方式（另一种是 Command 命令行） - -## SSE vs WebSocket -| 特性 | SSE | WebSocket | -|------|-----|-----------| -| 通信方向 | 单向（Server→Client） | 双向 | -| 协议 | HTTP | ws/wss | -| 自动重连 | 原生支持 | 需手动实现 | -| 二进制数据 | 不支持 | 支持 | -| HTTP/2 多路复用 | 支持 | 支持 | -| 复杂度 | 简单 | 较复杂 | - -## Usage in MCP Context -- **适用场景**：在线 MCP 服务的远程连接 -- **配置方式**：在 Cursor MCP 设置中填写 SSE 服务 URL -- **替代方案**：本地 Command 命令行方式（适合本地 MCP 服务） - -## Connections -- [[MCP（Model Context Protocol）]] — SSE 作为 MCP 的一种接入传输层 -- [[Cursor]] — Cursor MCP 设置中支持 SSE 方式配置 - -## Sources -- [[mcp在cursor中的集成与应用详解]] diff --git a/wiki/concepts/SSE.md b/wiki/concepts/SSE.md deleted file mode 100644 index 5194efd9..00000000 --- a/wiki/concepts/SSE.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "SSE" -type: concept -tags: [] -sources: [expose-hermes-agent-as-an-openai-compatible-api-for-any-frontend] -last_updated: 2026-05-02 ---- - -## Definition -Server-Sent Events (SSE) 是一种服务器推送技术，允许服务端通过 HTTP 单向通道向客户端持续发送事件流。 - -## Usage in Hermes Agent -`/v1/runs` API 通过 SSE 实现长会话实时进度订阅： -- **Token 流**：逐 token 推送响应内容 -- **工具进度**：自定义事件推送工具执行状态 -- **实时反馈**：用户可看到 Agent 思考和工具调用的全过程 - -## Format -``` -event: content -data: {"content": "Hello"} - -event: tool_use -data: {"tool": "terminal", "input": {...}} -``` - -## Comparison with WebSocket -| 特性 | SSE | WebSocket | -|------|-----|-----------| -| 方向 | 单向（服务端→客户端） | 双向 | -| 复杂性 | 简单 | 复杂 | -| 自动重连 | 支持 | 需自行实现 | -| HTTP/2 | 优化支持 | 支持 | - -## Related -- [[ToolStreaming]] -- [[ResponsesAPI]] diff --git a/wiki/concepts/SSM-Patching.md b/wiki/concepts/SSM-Patching.md deleted file mode 100644 index 30e0ee85..00000000 --- a/wiki/concepts/SSM-Patching.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "SSM Patching" -type: concept -tags: ["AWS", "Patch-Management", "SSM", "Security"] -sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2"] -last_updated: 2026-05-08 ---- - -## Definition -SSM Patching（SSM 补丁管理）是 AWS Systems Manager 提供的自动化补丁管理功能，通过补丁基准（Patch Baseline）和维护窗口（Maintenance Window）为长期运行的 EC2 实例按需打补丁，作为 AMI 刷新策略的补充方案。 - -## Problem Solved -- **长期运行实例**：无法频繁重建和刷新 AMI -- **安全合规**：需要持续应用安全补丁 -- **手动打补丁**：耗时且易出错 - -## Key Components -- **Patch Baseline**：定义补丁审批规则（批准/拒绝） -- **Patch Group**：按标签分组的实例集合 -- **Maintenance Window**：定义打补丁的时间窗口 -- **SSM Automation Document**：自动化补丁安装流程 - -## Connections -- [[AWS-SSM]] — SSM Patching 是 AWS Systems Manager 的功能之一 -- [[Amazon-Machine-Image]] — SSM Patching 补充而非替代 AMI 刷新 -- [[AWS-Landing-Zone]] — SSM Patching 是 LZ 运维自动化的组成部分 diff --git a/wiki/concepts/STARFramework.md b/wiki/concepts/STARFramework.md deleted file mode 100644 index 7949ed27..00000000 --- a/wiki/concepts/STARFramework.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: "STAR Framework（行为面试法）" -type: concept -tags: [interview, behavioral-assessment, hiring] -sources: [recruitment-specialist] -last_updated: 2026-04-25 ---- - -## 定义 -STAR Framework 是一种结构化行为面试方法，通过四个维度引导候选人描述其过去的工作经历： -- **Situation（情境）**：描述事情发生的背景 -- **Task（任务）**：明确候选人需要完成的目标 -- **Action（行动）**：候选人具体采取了哪些行动 -- **Result（结果）**：最终取得了什么成果 - -## 在 [[Recruitment Specialist Agent]] 中的应用 -- 设计行为面试问题，基于 STAR 框架引导候选人提供具体案例 -- 针对不同能力维度准备追问提示 -- 关注候选人的具体行为，而非假设性回答 -- 使用结构化评分卡评估 STAR 回答的完整性和质量 - -## 使用场景 -适用于评估候选人的： -- 团队协作能力 -- 问题解决能力 -- 领导力 -- 冲突管理能力 -- 客户导向意识 - -## 连接 -- [[Recruitment Specialist Agent]] — 该 Agent 的核心面试评估工具 -- [[Structured Interview]] — STAR 是结构化面试的重要组成部分 -- [[Structured Interview]] — 结构化面试结合 STAR 和评分卡确保评估一致性 diff --git a/wiki/concepts/SVG图表生成.md b/wiki/concepts/SVG图表生成.md deleted file mode 100644 index f471ed9a..00000000 --- a/wiki/concepts/SVG图表生成.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "SVG图表生成" -type: concept -tags: [] -sources: [baoyu-skills] -last_updated: 2026-04-19 ---- - -## Overview - -SVG 图表生成是 [[baoyu-diagram]] 技能的核心方法——不调用任何图像生成模型，由 LLM 直接通过手算坐标生成 SVG 代码，一次确认后批量输出多张图表，内嵌深色模式样式。 - -## Five Chart Types - -| 类型 | 适用场景 | 触发动词 | -| --- | --- | --- | -| `flowchart` | 按顺序走一遍流程 | 流程、步骤、工作流、生命周期、状态机 | -| `sequence` | 谁和谁通信、按什么顺序 | 协议、握手、认证流程、OAuth、TCP | -| `structural` | 展示什么包含什么、如何组织 | 架构、组件、拓扑、布局 | -| `illustrative` | 建立直觉——画出机制本身 | 怎么工作、原理、为什么、直观解释 | -| `class` | 类型是什么、它们如何关联 | 类图、UML、继承、接口、数据模型 | - -## Technical Approach - -**无图像生成模型**：LLM 直接手算 SVG 坐标生成矢量代码，确保每个图表符合统一设计规范。 - -**内嵌样式**： -- `