Auto-sync: 2026-04-21 04:02

wiki/concepts/Analytics-Reporter.md

@@ -0,0 +1,32 @@
+---
+title: "Analytics Reporter"
+type: concept
+tags: []
+last_updated: 2026-04-21
+---
+
+## Definition
+数据分析与商业智能专家智能体，将原始数据转化为可操作的业务洞察。
+
+## Core Capabilities
+- 统计分析与假设检验
+- 仪表盘设计与 KPI 监控
+- RFM 客户分层分析
+- 营销归因建模
+- 预测模型构建（A/B 测试、流失预测、增长预测）
+
+## Key Metrics
+- 分析准确率目标：95%+
+- 业务建议采纳率目标：70%+
+- 仪表盘月活用户：95%+
+- KPI 提升目标：20%+
+
+## Related Concepts
+- [[Data-Driven Decision Making]]
+- [[RFM Analysis]]
+- [[Customer Lifetime Value]]
+- [[Statistical Significance Testing]]
+
+## Source
+- [[support-analytics-reporter]]
+

wiki/concepts/BCG-Pyramid-Principle.md

@@ -0,0 +1,23 @@
+---
+title: "BCG Pyramid Principle"
+type: concept
+tags: [consulting, strategic-communication, framework]
+sources: []
+last_updated: 2026-04-21
+---
+
+## Definition
+波士顿咨询集团的自上而下逻辑表达原则，先给出核心论点再分层展开支撑论据
+
+## Core Concept
+- **核心论点（Key Message）**：首先传达最重要的结论
+- **支撑论据（Supporting Arguments）**：按重要性排序的次级论点
+- **数据支撑（Data/Evidence）**：每项论据的具体证据
+
+## Application
+用于 Executive Summary Generator 的第二步"关键发现"，确保发现按业务影响排序
+
+## Related Concepts
+- [[McKinsey SCQA Framework]]
+- [[Bain Action-Oriented Model]]
+- [[Executive Summary]]

wiki/concepts/Book-Co-Author-Agent.md

@@ -0,0 +1,41 @@
+---
+title: "Book Co-Author Agent"
+type: concept
+tags: [agent, writing, the-agency]
+sources: [sources/workflow-book-chapter.md]
+last_updated: 2026-04-21
+---
+
+## 定义
+The Agency 项目中的书籍共创智能体，将源素材（语音笔记、片段、战略笔记）转化为版本化章节草稿，并附带编辑注释和下一步问题。
+
+## 核心职责
+- 将粗糙素材转化为战略性第一人称书籍章节草稿
+- 保持作者声音一致性
+- 强化品类定位
+- 暴露开放编辑决策
+
+## 工作流程
+1. 接收原始素材（voice memo、notes、story fragment、positioning angle）
+2. 产出章节目标和战略角色
+3. 提出澄清问题
+4. 生成版本化草稿
+5. 提供编辑注释（假设和证据缺口）
+6. 明确下一步修订请求
+
+## 输出格式
+1. Target Outcome（目标结果）
+2. Chapter Draft（章节草稿）
+3. Editorial Notes（编辑注释）
+4. Feedback Loop（反馈循环）
+5. Next Step（下一步）
+
+## 质量标准
+- 草稿保持第一人称声音
+- 章节有一个清晰的承诺和内部逻辑
+- 声明与源素材关联或标记为假设
+- 移除通用激励语言
+- 输出以明确修订问题结束
+
+## Aliases
+- Book Co-Author

wiki/concepts/BudgetFramework.md

@@ -0,0 +1,15 @@
+---
+title: "Budget Framework"
+type: concept
+tags: [finance]
+sources: [support-finance-tracker]
+last_updated: 2026-04-21
+---
+
+定义：组织年度预算的结构化方法，包含按部门/类别拆分、季度差异分析、偏差分类与再分配规则，用于把控支出与指导战略资源分配。
+
+## Typical Components
+- 部门与类别分解
+- 季度/月度差异分析
+- 偏差触发与纠正流程
+- 预算再分配规范

wiki/concepts/CashFlowManagement.md

@@ -0,0 +1,15 @@
+---
+title: "Cash Flow Management"
+type: concept
+tags: [finance]
+sources: [support-finance-tracker]
+last_updated: 2026-04-21
+---
+
+定义：系统化的现金收支预测与优化方法，包含滚动预测、季节性因子、低现金预警规则与支付时点优化，用以保证短中期流动性并发现投资机会。
+
+## Typical Components
+- 收入与付款模式分析
+- 滚动预测（12 个月示例）
+- 低现金阈值与行动建议
+- 支付优先级与折扣收益优化

wiki/concepts/Context-Passing.md

@@ -0,0 +1,41 @@
+---
+title: "Context Passing"
+type: concept
+tags: [multi-agent, workflow, communication]
+last_updated: 2026-04-21
+---
+
+## Definition
+上下文传递（Context Passing）是一种多智能体通信模式，在智能体之间传递完整的上下文信息，而非摘要或压缩版本。
+
+## Core Principle
+**"Copy-paste agent outputs between steps — don't summarize, use the full output"**
+
+## Problem It Solves
+- 摘要会丢失关键细节
+- 压缩可能遗漏重要上下文
+- 智能体不具备共享记忆
+
+## Best Practices
+1. **完整复制**：将上一智能体的输出完整粘贴到下一智能体的输入
+2. **不要摘要**：即使很长也要完整传递
+3. **不要解释**：让接收智能体自己解析和处理完整信息
+4. **包含所有内容**：原始输出、元数据、证据、决策理由等
+
+## Example
+在 Multi-Agent Workflow: Startup MVP 中：
+```
+Sprint Prioritizer 输出 → [完整粘贴] → Backend Architect 输入
+UX Researcher 输出 → [完整粘贴] → Backend Architect 输入
+Backend Architect 输出 → [完整粘贴] → Frontend Developer 输入
+```
+
+## Trade-offs
+- **优点**：最大化信息保留，便于接收智能体做出完整判断
+- **缺点**：消耗更多上下文窗口，可能需要更长的处理时间
+
+## Related Concepts
+- [[Sequential Handoffs]]：顺序交接模式
+- [[Parallel Work]]：并行工作模式
+- [[Quality Gates]]：质量门控
+- [[Multi-Agent Team]]：多智能体团队

wiki/concepts/Customer-Lifetime-Value.md

@@ -0,0 +1,26 @@
+---
+title: "Customer Lifetime Value"
+type: concept
+tags: []
+last_updated: 2026-04-21
+---
+
+## Definition
+客户生命周期价值，衡量客户在整个关系周期内为企业贡献的总收入。
+
+## Calculation Method
+CLV = Average Order Value × Purchase Frequency × Customer Lifespan
+
+## Application
+- 客户分层与优先级排序
+- 客户获取成本（CAC）决策依据
+- 个性化营销策略制定
+- 客户流失预警基准
+
+## Related Concepts
+- [[RFM Analysis]]
+- [[Predictive Modeling]]
+
+## Source
+- [[support-analytics-reporter]]
+

wiki/concepts/Customer-Success.md

@@ -0,0 +1,35 @@
+---
+id: customer-success
+title: "Customer Success"
+type: concept
+tags: [customer-service, retention, lifecycle]
+sources: [support-support-responder.md]
+last_updated: 2026-04-21
+---
+
+## Definition
+客户成功（Customer Success），从被动式客户支持向主动式客户成功干预转变的管理方法论，目标是最大化客户生命周期价值并预防客户流失。
+
+## Core Mission
+- Onboarding Optimization：新客户快速上手和功能采用
+- Feature Adoption Guidance：引导客户发现和使用核心功能
+- Proactive Outreach：基于数据的主动干预（高风险客户识别）
+- Feedback Collection：产品改进和客户洞察生成
+
+## Success Metrics
+| Metric | Target |
+|--------|--------|
+| CSAT Score | ≥ 4.5/5 |
+| First Contact Resolution | ≥ 80% |
+| Customer Retention | ≥ 95% |
+| NPS Score | ≥ 50 |
+
+## Proactive Outreach Triggers
+- 30 天内提交 ≥ 3 次工单的高频用户
+- 7 天内 CSAT ≤ 3 的低满意度客户
+- 超过 48 小时未解决的工单
+
+## Connections
+- [[Support Responder]] — 实现客户成功的核心执行者
+- [[Support Analytics]] — 提供数据驱动的干预依据
+- [[Multi-Channel Support Framework]] — 客户触达的渠道

wiki/concepts/Data-Driven-Decision-Making.md

@@ -0,0 +1,30 @@
+---
+title: "Data-Driven Decision Making"
+type: concept
+tags: []
+last_updated: 2026-04-21
+---
+
+## Definition
+基于数据而非直觉或经验进行业务决策的方法论，强调用证据和量化分析指导战略选择。
+
+## Core Principles
+- 数据质量优先：验证数据准确性再分析
+- 统计显著性：结论需经假设检验确认
+- 可复现性：分析流程需版本控制和文档化
+- 行动导向：连接分析结果与业务行动
+- 持续迭代：基于反馈循环优化决策
+
+## Implementation
+1. 建立数据治理标准
+2. 定义关键业务指标（KPI）
+3. 构建可复现的分析工作流
+4. 建立反馈机制评估决策效果
+
+## Related Concepts
+- [[Statistical Significance Testing]]
+- [[KPI Tracking]]
+
+## Source
+- [[support-analytics-reporter]]
+

wiki/concepts/Disaster-Recovery.md

@@ -0,0 +1,28 @@
+---
+title: "Disaster Recovery"
+type: concept
+tags: [infrastructure, resilience, backup]
+last_updated: 2026-04-21
+---
+
+## Definition
+Disaster Recovery（灾难恢复）是一套在灾难性事件后恢复 IT 系统和数据的策略与流程，确保业务连续性。
+
+## Core Metrics
+- **RTO（Recovery Time Objective）**：系统允许的最大停机时间
+- **RPO（Recovery Point Objective）**：可接受的最大数据丢失量
+
+## Key Components
+- **备份策略**：定期创建加密备份，存储于 S3
+- **恢复流程**：经过测试的恢复程序文档
+- **自动化恢复**：通过脚本实现自动故障切换
+
+## Implementation
+The Agency 项目中的 [[Support Infrastructure Maintainer]] 实现：
+- 自动化备份脚本（GPG 加密 + S3 上传）
+- 30 天本地保留 + S3 生命周期管理
+- Backup verification 和 Slack 通知
+
+## Related Concepts
+- [[Feature Flag（特性开关）]]：控制代码路径而不需要重新部署，实现秒级回滚
+- [[ITSM（IT 服务管理）]]：从工单系统演进为战略推动者，实现运营卓越和风险缓解

wiki/concepts/Editorial-Notes.md

@@ -0,0 +1,25 @@
+---
+title: "Editorial Notes"
+type: concept
+tags: [writing, editing, review]
+sources: [sources/workflow-book-chapter.md]
+last_updated: 2026-04-21
+---
+
+## 定义
+编辑注释是对章节草稿中假设和证据缺口的明确标注，帮助作者识别需要补充的内容区域。
+
+## 核心内容
+- 假设声明：标记未经证实的声明
+- 证据缺口：指出需要引用或数据支持的位置
+- 品类定位评估：检查内容是否强化目标定位
+- 声音一致性检查：确认是否保持作者风格
+
+## 作用
+- 为作者提供明确的修订方向
+- 区分 AI 生成内容和作者贡献
+- 保持内容可信度
+
+## Aliases
+- 编辑注释
+- 编辑笔记

wiki/concepts/Executive-Summary.md

@@ -1,27 +1,31 @@
 ---
 title: "Executive Summary"
 type: concept
-tags: [Proposal, Sales, Strategy]
-last_updated: 2026-04-20
+tags: [Proposal, Sales, Strategy, consulting, decision-making, c-suite]
+sources: []
+last_updated: 2026-04-21
 ---
 
 ## Definition
-执行摘要是提案最关键的部分，许多评估者尤其是高级利益相关者只阅读此部分。它不是提案的总结，而是放在最前面的结束论证。
+执行摘要，一种针对 C-suite 决策者的结构化简报格式，要求在 325-475 字内传达复杂业务信息的核心要点。提案中的执行摘要是最关键的部分，许多评估者尤其是高级利益相关者只阅读此部分。
 
-## Structure
-1. **Mirror the buyer's situation**（2-3 句，证明你倾听并理解了他们的处境）
+## Format Requirements
+- **长度**：325-475 words（≤ 500 max）
+- **量化**：每个关键发现必须包含 ≥ 1 个量化或比较数据点
+- **结构**：5 部分（SITUATION OVERVIEW / KEY FINDINGS / BUSINESS IMPACT / RECOMMENDATIONS / NEXT STEPS）
+- **可操作性**：建议必须包含 Owner + Timeline + Expected Result
+
+## Format for C-suite Decision Making
+1. **Mirror the buyer's situation**（2-3 句）
 2. **Introduce the central tension**—不行动的成本或错失的机会
-3. **Present your thesis**—你的方法如何解决这个矛盾（制胜主题在此出现）
-4. **Offer proof**—一个或两个具体证据点（指标、类似案例、差异化因素）
-5. **Close with the transformed state**—他们可以期望的具体结果
+3. **Present your thesis**—你的方法如何解决这个矛盾
+4. **Offer proof**—具体证据点
+5. **Close with the transformed state**—具体结果
 
-## Key Principles
-- 保持在一页以内
-- 每一句都必须有其存在的价值
-- 从买家的语言出发，不是从你的解决方案出发
-- 制胜主题必须在此部分出现
+## Frameworks Used
+- [[McKinsey SCQA Framework]]
+- [[BCG Pyramid Principle]]
+- [[Bain Action-Oriented Model]]
 
-## Connections
-- [[Executive Summary]] ← critical_section_of ← [[Proposal Strategy]]
-- [[Executive Summary]] ← contains ← [[Win Theme]]
-- [[Executive Summary]] → leads_to → [[Three-Act Proposal Narrative]]
+## Related Entities
+- [[Executive Summary Generator]]

wiki/concepts/Feedback-Loop.md

@@ -0,0 +1,30 @@
+---
+title: "Feedback Loop"
+type: concept
+tags: [workflow, revision, iteration]
+sources: [sources/workflow-book-chapter.md]
+last_updated: 2026-04-21
+---
+
+## 定义
+反馈循环是 Book Co-Author Agent 提供的结构化修订请求机制，通过明确的编辑注释和下一步问题驱动草稿迭代改进。
+
+## 组成要素
+- Editorial Notes：假设和证据缺口标注
+- Next Step：具体可执行的修订请求
+- 开放问题：暴露需要作者决策的编辑问题
+
+## 目的
+- 将模糊的"需要改进"转化为具体行动项
+- 维持修订过程的可追溯性
+- 确保作者声音和品类定位不被稀释
+
+## 与版本化草稿的关系
+反馈循环支撑版本化草稿的演进：
+- 每一版本的反馈循环定义下一版本的改进方向
+- 版本编号与反馈循环轮次对应
+- 作者通过反馈循环保持对内容的控制权
+
+## Aliases
+- 反馈循环
+- 修订循环

wiki/concepts/Infrastructure-as-Code.md

@@ -0,0 +1,27 @@
+---
+title: "Infrastructure as Code (IaC)"
+type: concept
+tags: [infrastructure, devops, automation]
+last_updated: 2026-04-21
+---
+
+## Definition
+Infrastructure as Code（基础设施即代码）是一种通过代码实现基础设施管理的方法论，替代传统手动配置，实现一致性、版本控制和自动化部署。
+
+## Core Principles
+- **声明式配置**：定义期望状态而非步骤
+- **版本控制**：所有基础设施变更通过 Git 管理
+- **自动化部署**：通过 CI/CD 流水线实现一键部署
+- **幂等性**：重复执行结果一致
+
+## Key Tools
+- [[Terraform]]：HashiCorp 开发的跨平台 IaC 工具
+- Terragrunt：Terraform 包装工具，提供模块化和变量共享
+- CloudFormation：AWS 原生 IaC 服务
+
+## Related Concepts
+- [[CI/CD 流水线]]：自动化测试、集成和部署的持续交付管道
+- [[Infrastructure Maintainer]]：使用 IaC 进行基础设施管理的智能体角色
+
+## Application
+The Agency 项目中的 [[Support Infrastructure Maintainer]] 使用 Terraform 实现 AWS 基础设施声明式管理，包括 VPC、子网、Auto Scaling Group、RDS 等资源。

wiki/concepts/InvestmentAnalysis.md

@@ -0,0 +1,15 @@
+---
+title: "Investment Analysis"
+type: concept
+tags: [finance]
+sources: [support-finance-tracker]
+last_updated: 2026-04-21
+---
+
+定义：用于评估资本项目经济性的量化框架，常用指标包括净现值（NPV）、内部收益率（IRR）、回收期与风险评分，结合敏感性分析与决策规则给出投资建议。
+
+## Typical Components
+- NPV 计算与折现率设定
+- IRR 估算与收敛性检测
+- 回收期计算
+- 风险评分与投资建议规则

wiki/concepts/KPI-Tracking.md

@@ -0,0 +1,30 @@
+---
+title: "KPI Tracking"
+type: concept
+tags: []
+last_updated: 2026-04-21
+---
+
+## Definition
+关键绩效指标监控，通过量化指标评估业务目标达成情况。
+
+## Dashboard Design Principles
+- 针对特定利益相关者需求定制
+- 清晰的分层结构（战略→运营→执行）
+- 实时或近实时数据更新
+- 异常自动告警机制
+- 可下钻的钻取能力
+
+## Common KPI Categories
+- **收入指标**：月收入、ARR、客单价、转化率
+- **客户指标**：NPS、流失率、终身价值
+- **运营指标**：处理时间、错误率、库存周转
+- **营销指标**：CAC、ROI、触点转化率
+
+## Related Concepts
+- [[Data-Driven Decision Making]]
+- [[Predictive Modeling]]
+
+## Source
+- [[support-analytics-reporter]]
+

wiki/concepts/Keyboard-Navigation-Audit.md

@@ -0,0 +1,54 @@
+---
+title: "Keyboard Navigation Audit"
+description: 纯键盘导航测试，验证所有交互元素的可访问性
+tags: [accessibility, testing, keyboard]
+---
+
+## Definition
+Keyboard Navigation Audit 是验证所有交互功能是否可以通过纯键盘（不使用鼠标）完成操作的测试方法。这是无障碍测试的核心环节。
+
+## 全局导航检查清单
+- [ ] 所有交互元素可通过 Tab 键到达
+- [ ] Tab 顺序遵循视觉布局逻辑
+- [ ] 存在 Skip Navigation（跳转导航）链接
+- [ ] 无键盘陷阱（始终可以通过 Tab 离开）
+- [ ] 每个交互元素的焦点指示器始终可见
+- [ ] Escape 键关闭模态框、下拉菜单和浮层
+- [ ] 关闭模态框/浮层后焦点返回触发元素
+
+## 组件特定模式
+
+### Tabs
+- [ ] Tab 键在 Tab 列表和活动面板内容之间移动
+- [ ] 方向键在 Tab 按钮之间移动
+- [ ] Home/End 键移动到第一个/最后一个 Tab
+- [ ] 选中 Tab 通过 aria-selected 指示
+
+### Menus
+- [ ] 方向键在菜单项之间导航
+- [ ] Enter/Space 激活菜单项
+- [ ] Escape 关闭菜单并将焦点返回触发器
+
+### Carousels/Sliders
+- [ ] 方向键在幻灯片之间移动
+- [ ] 暂停/停止控制可通过键盘操作
+- [ ] 当前位置被宣布
+
+### Data Tables
+- [ ] 表头通过 scope 或 headers 属性与单元格关联
+- [ ] Caption 或 aria-label 描述表格用途
+- [ ] 可排序列可通过键盘操作
+
+## 结果指标
+- **总交互元素数**：
+- **键盘可访问**：（百分比）
+- **键盘陷阱数**：
+- **缺失焦点指示器数**：
+
+## Related Concepts
+- [[WCAG 2.2]]
+- [[Screen Reader Testing]]
+- [[POUR Principles]]
+
+## Source
+- [[Accessibility Auditor]]

wiki/concepts/Marketing-Attribution-Modeling.md

@@ -0,0 +1,50 @@
+---
+title: "Marketing Attribution Modeling"
+type: concept
+tags: []
+last_updated: 2026-04-21
+---
+
+## Definition
+多触点归因模型，将转化功劳分配给营销漏斗中的不同触点（首次点击、末次点击、中间触点）。
+
+## Attribution Models
+| Model | First Touch | Last Touch | Middle Touches |
+|-------|------------|------------|----------------|
+| First Touch | 100% | - | - |
+| Last Touch | - | 100% | - |
+| Linear | - | - | 平均分配 |
+| Time Decay | 较低 | 较高 | 随时间递减 |
+| Position Based | 40% | 40% | 20% 均分 |
+| Data-Driven | 基于算法 | 基于算法 | 基于算法 |
+
+## Multi-Touch Attribution SQL
+```sql
+WITH customer_touchpoints AS (
+  SELECT customer_id, channel, campaign,
+    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
+),
+attribution_weights AS (
+  SELECT *,
+    CASE
+      WHEN touch_sequence = 1 AND total_touches = 1 THEN 1.0
+      WHEN touch_sequence = 1 THEN 0.4
+      WHEN touch_sequence = total_touches THEN 0.4
+      ELSE 0.2 / (total_touches - 2)
+    END as attribution_weight
+  FROM customer_touchpoints
+)
+SELECT channel, SUM(revenue * attribution_weight) as attributed_revenue
+FROM attribution_weights
+GROUP BY channel;
+```
+
+## Related Concepts
+- [[Data-Driven Decision Making]]
+- [[KPI Tracking]]
+
+## Source
+- [[support-analytics-reporter]]
+

wiki/concepts/McKinsey-SCQA-Framework.md

@@ -0,0 +1,24 @@
+---
+title: "McKinsey SCQA Framework"
+type: concept
+tags: [consulting, strategic-communication, framework]
+sources: []
+last_updated: 2026-04-21
+---
+
+## Definition
+Situation-Complication-Question-Answer，麦肯锡的结构化叙事框架，通过四步引导读者从情境到解决方案
+
+## Structure
+- **Situation**：设定背景，描述当前状态
+- **Complication**：揭示挑战或障碍
+- **Question**：提出核心问题
+- **Answer**：给出解决方案或答案
+
+## Application
+用于 Executive Summary Generator 的第一步"情境概述"，帮助建立叙事逻辑
+
+## Related Concepts
+- [[BCG Pyramid Principle]]
+- [[Bain Action-Oriented Model]]
+- [[Executive Summary]]

wiki/concepts/Merge-Point.md

@@ -0,0 +1,24 @@
+---
+title: "Merge Point"
+type: concept
+tags: [multi-agent, workflow, synchronization]
+last_updated: 2026-04-21
+---
+
+## Definition
+Merge Point 是多智能体工作流中的关键同步节点，多个输入在此汇合后触发下一阶段。常见于一个 Agent 依赖多个前置 Agent 输出时的场景。
+
+## Usage Scenario
+在 landing page sprint 中，Frontend Developer 需要 Content Creator 和 UI Designer 的输出才能开始构建：
+
+```
+Content Creator ─┐
+                 ├──→ Merge Point → Frontend Developer
+UI Designer ─────┘
+```
+
+## Connections
+- [[Multi-Agent Workflow]]：所属工作流模式
+- [[Parallel Kickoff]]：前置启动模式
+- [[Sequential Handoffs]]：相关交接概念
+

wiki/concepts/Multi-Agent-Workflow.md

@@ -0,0 +1,28 @@
+---
+title: "Multi-Agent Workflow"
+type: concept
+tags: [multi-agent, workflow, coordination]
+last_updated: 2026-04-21
+---
+
+## Definition
+Multi-Agent Workflow 是一种多智能体协作架构，多个专业 Agent 通过分阶段并行工作实现复杂任务交付。每个 Agent 有独立角色、人格、优化的模型，通过共享内存+私有上下文实现协同。
+
+## Key Components
+- **独立角色**：每个 Agent 承担特定专业职责
+- **并行工作**：独立任务同时执行
+- **顺序交接**：依赖任务按序传递
+- **共享上下文**：通过共享内存保持信息一致性
+
+## Pattern Types
+- Parallel Kickoff：多个工作流同时启动
+- Merge Point：多输入汇合触发下一阶段
+- Feedback Loop：审查后迭代修改
+- Quality Gates：设置检查点确保质量
+
+## Connections
+- [[Multi-Agent Team]]：相关概念
+- [[Parallel Kickoff]]：并行启动模式
+- [[Merge Point]]：合并依赖点
+- [[Feedback Loop]]：反馈迭代机制
+

wiki/concepts/Multi-Channel-Support.md

@@ -0,0 +1,36 @@
+---
+id: multi-channel-support
+title: "Multi-Channel Support Framework"
+type: concept
+tags: [customer-service, support, framework]
+sources: [support-support-responder.md]
+last_updated: 2026-04-21
+---
+
+## Definition
+全渠道客户支持框架（Multi-Channel Support Framework），跨 email、live chat、phone、social media、in-app messaging 统一提供一致服务质量的客户支持架构。
+
+## Support Channels
+| Channel | Response Time SLA | Key Features |
+|---------|------------------|--------------|
+| Email | 2 hours | 优先级路由、工单跟踪 |
+| Live Chat | 30 seconds | 并发限制 3、自动化路由 |
+| Phone | 3 rings | 回拨选项、优先级队列 |
+| Social Media | 1 hour | 关键词监控、私下升级 |
+| In-App Messaging | 即时 | 上下文帮助、主动触发 |
+
+## Core Components
+- Support Tiers：Tier 1（通用）、Tier 2（技术）、Tier 3（专家）的分层支持
+- Priority Routing：企业客户 > 计费问题 > 技术紧急情况
+- SLA Compliance：响应时间和解决时间的双重 SLA 监控
+
+## Key Metrics
+- First Response Time：首次响应平均时间
+- Resolution Time：从创建到解决的总时间
+- First Contact Resolution Rate：首次联系解决百分比
+- Customer Satisfaction (CSAT)：客户满意度评分
+
+## Connections
+- [[Support Responder]] — 实现该框架的核心智能体
+- [[Customer Success]] — 框架的服务目标
+- [[Knowledge Base Management]] — 框架的支持系统

wiki/concepts/Multi-Jurisdictional-Compliance.md

@@ -0,0 +1,28 @@
+---
+title: "Multi-Jurisdictional Compliance"
+type: concept
+tags: [compliance, legal, multi-jurisdiction, regulatory]
+sources: [support-legal-compliance-checker]
+last_updated: 2026-04-21
+---
+
+## Concept Summary
+多司法管辖区合规指企业在多个国家/地区运营时，需要同时满足不同司法管辖区的法律法规要求的管理方法。
+
+## Key Dimensions
+- **监管框架**：GDPR（欧盟）、CCPA（加州）、HIPAA（医疗）、SOX（财务）、PCI-DSS（支付）
+- **数据保护**：数据主体权利（访问、更正、删除、可携带）、数据本地化要求
+- **跨境传输**：Standard Contractual Clauses、adequacy decisions、数据驻留要求
+- **审计追踪**：决策文档化、法规引用、审批流程
+
+## Compliance Assessment Template
+监管合规评估报告包含：
+1. Executive Summary（合规状态概述、风险评估总结）
+2. Detailed Compliance Analysis（数据保护、行业特定合规、合同审查）
+3. Risk Mitigation Strategies（关键风险领域、框架改进）
+4. Implementation Roadmap（30天/90天/180+天阶段）
+
+## Relationship to Related Concepts
+- [[Privacy Policy Generator]]：多辖区合规的具体实施工具
+- [[Contract Review System]]：跨境合同风险评估
+- [[GDPR Compliance Framework]]：欧盟数据保护核心框架

wiki/concepts/POUR-Principles.md

@@ -0,0 +1,79 @@
+---
+title: "POUR Principles"
+description: WCAG 无障碍设计的四大核心原则：Perceivable、Operable、Understandable、Robust
+tags: [accessibility, wcag, design-principles]
+---
+
+## Definition
+POUR 是 WCAG（Web Content Accessibility Guidelines）无障碍设计的四大核心原则的首字母缩写，是评估数字产品无障碍性的基础框架。
+
+## 四大原则
+
+### P — Perceivable（可感知）
+**核心要求**：所有信息都必须以用户可感知的方式呈现
+
+具体要求：
+- 提供文本替代方案（alt 文本、字幕）
+- 提供音频描述
+- 内容可以以不同方式呈现（放大、高对比度）
+- 区分前后景（足够对比度）
+
+技术要点：
+- 图像 alt 文本
+- 视频字幕
+- 音频转录
+- 颜色对比度 ≥ 4.5:1
+
+### O — Operable（可操作）
+**核心要求**：所有功能都必须可以通过键盘操作
+
+具体要求：
+- 所有功能可通过键盘使用
+- 用户有足够时间阅读和使用内容
+- 不以可能引发癫痫的方式设计内容
+- 提供帮助用户导航和找到内容的机制
+
+技术要点：
+- 键盘可访问性
+- 跳过链接
+- 无键盘陷阱
+- 焦点指示器
+
+### U — Understandable（可理解）
+**核心要求**：信息和操作必须是可理解的
+
+具体要求：
+- 文本可读且可理解
+- 内容以可预测的方式出现和操作
+- 帮助用户避免和纠正错误
+
+技术要点：
+- 清晰的标签
+- 错误建议
+- 一致的导航
+- 简单语言
+
+### R — Robust（健壮）
+**核心要求**：内容必须能被各种用户代理可靠解释
+
+具体要求：
+- 使用标准兼容的技术
+- 状态信息可被辅助技术识别
+- 提供状态和变化的机器可读通知
+
+技术要点：
+- 语义 HTML
+- ARIA 正确使用
+- 标准化技术
+
+## 与 Accessibility Auditor 的关系
+[[Accessibility Auditor]] 智能体默认验证所有四个 POUR 原则，确保测试产品达到 WCAG 2.2 AA 级别合规。
+
+## Related Concepts
+- [[WCAG 2.2]]
+- [[Screen Reader Testing]]
+- [[Keyboard Navigation Audit]]
+
+## Source
+- [[Accessibility Auditor]]
+- W3C WCAG 2.2

wiki/concepts/Parallel-Kickoff.md

@@ -0,0 +1,29 @@
+---
+title: "Parallel Kickoff"
+type: concept
+tags: [multi-agent, workflow, parallel]
+last_updated: 2026-04-21
+---
+
+## Definition
+Parallel Kickoff 是一种多智能体工作流启动模式，多个独立工作流同时开始执行，适用于相互之间无依赖关系的任务。
+
+## Usage Scenario
+在 landing page sprint 中，Content Creator 和 UI Designer 可同时开始工作，因二者相互独立：
+- Content Creator 编写文案
+- UI Designer 设计规格
+
+二者输出合并后交付给 Frontend Developer。
+
+## Example
+```
+Morning (9:00)
+├── Content Creator → 编写文案（并行）
+└── UI Designer → 设计规格（并行）
+```
+
+## Connections
+- [[Multi-Agent Workflow]]：所属工作流模式
+- [[Merge Point]]：后续合并节点
+- [[Parallel Work]]：相关概念
+

wiki/concepts/Parallel-Work.md

@@ -0,0 +1,46 @@
+---
+title: "Parallel Work"
+type: concept
+tags: [multi-agent, workflow, concurrency]
+last_updated: 2026-04-21
+---
+
+## Definition
+并行工作（Parallel Work）是一种多智能体协作模式，其中多个智能体同时执行任务，通过独立工作减少总体完成时间。
+
+## Core Principle
+相互独立的任务可以同时由不同智能体处理，无需等待彼此完成。
+
+## Workflow Pattern
+```
+Agent A ─┬─→ [独立任务 A]
+         │
+Agent B ─┴─→ [独立任务 B]
+```
+
+## Example
+在 Multi-Agent Workflow: Startup MVP 中：
+- Week 1：Sprint Prioritizer 和 UX Researcher **并行运行**
+- Week 2：Frontend Developer 和 Rapid Prototyper **并行构建**
+- Week 3：Frontend Developer 继续 + Growth Hacker **启动策略规划**
+
+## Key Requirements
+- 任务必须相互独立，无依赖关系
+- 需要明确的输入和输出定义
+- 输出最终需要合并或由协调者整合
+
+## Advantages
+- 减少总体执行时间
+- 充分利用并行处理能力
+- 加快 MVP 交付速度
+
+## Disadvantages
+- 增加了协调复杂度
+- 需要清晰的边界定义
+- 合并输出可能产生冲突
+
+## Related Concepts
+- [[Sequential Handoffs]]：顺序交接模式
+- [[Quality Gates]]：质量门控
+- [[Context Passing]]：上下文传递
+- [[Multi-Agent Team]]：多智能体团队

wiki/concepts/Predictive-Modeling.md

@@ -21,3 +21,16 @@ last_updated: 2026-04-20
 - 采用率预测（Adoption Rate Predictions）
 - 置信区间（Confidence Intervals）
 - 情景概率权重（Probability Weighting）
+
+## Analytics Reporter Applications
+- **客户流失预测**：识别高流失风险客户
+- **需求预测**：预测产品需求量，优化库存
+- **增长预测**：基于趋势外推预测收入增长
+
+## Related Concepts
+- [[Customer Lifetime Value]]
+- [[Statistical Significance Testing]]
+
+## Sources
+- [[raw/Agent/agency-agents/product/product-trend-researcher.md]]
+- [[support-analytics-reporter]]

wiki/concepts/Quality-Gates.md

@@ -0,0 +1,38 @@
+---
+title: "Quality Gates"
+type: concept
+tags: [multi-agent, quality, workflow]
+last_updated: 2026-04-21
+---
+
+## Definition
+质量门控（Quality Gates）是多智能体工作流中的关键检查点，在进入下一阶段前对当前输出进行生产就绪评估。
+
+## Core Principle
+在关键节点设置质量门槛，只有满足所有标准才能继续推进。
+
+## Quality Gate Points
+在 Multi-Agent Workflow: Startup MVP 中设置了两个质量门控：
+
+### Gate 1: Week 2 中点评估
+- 评估当前进度是否可达成目标
+- 识别需要削减的范围
+- 识别会，影响 Launch 的技术债务
+
+### Gate 2: Week 4 最终评估
+- 评估产品 Launch 就绪状态
+- 检查错误监控、数据库备份等运维就绪
+- 要求证据支持每个验收标准
+- 提供 GO / NO-GO 决策
+
+## Decision Outcomes
+- **GO**：满足所有标准，可以进入下一阶段
+- **NO-GO**：不满足标准，需要修复后重新评估
+- **NEEDS WORK**：默认决策，保守策略
+
+## Related Concepts
+- [[Reality Checker]]：质量门控的执行者
+- [[Sequential Handoffs]]：顺序交接模式
+- [[Parallel Work]]：并行工作模式
+- [[Context Passing]]：上下文传递
+- [[Multi-Agent Team]]：多智能体团队

wiki/concepts/RFM-Analysis.md

@@ -0,0 +1,46 @@
+---
+title: "RFM Analysis"
+type: concept
+tags: []
+last_updated: 2026-04-21
+---
+
+## Definition
+客户价值分析的经典方法，通过三个维度评估客户：Recency（最近购买时间）、Frequency（购买频率）、Monetary（消费金额）。
+
+## Scoring Method
+- R Score：最近购买距离当前天数，越小分数越高（1-5 分）
+- F Score：购买次数排名分位数（1-5 分）
+- M Score：消费总额分位数（1-5 分）
+- RFM Score：三个分数组合形成 555-111 的客户评分
+
+## Customer Segments
+| RFM Score | Segment | Strategy |
+|-----------|---------|----------|
+| 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 | 再激活活动，特别优惠 |
+
+## Implementation
+```python
+# RFM Analysis Python Implementation
+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'
+})
+```
+
+## Related Concepts
+- [[Customer Lifetime Value]]
+- [[Data-Driven Decision Making]]
+
+## Source
+- [[support-analytics-reporter]]
+

wiki/concepts/Screen-Reader-Testing.md

@@ -0,0 +1,51 @@
+---
+title: "Screen Reader Testing"
+description: 使用屏幕阅读器验证网页内容可访问性的测试方法
+tags: [accessibility, testing, assistive-technology]
+---
+
+## Definition
+Screen Reader Testing 是使用屏幕阅读器软件（如 VoiceOver、NVDA、JAWS）验证网页内容是否对视力障碍用户可访问的测试方法。
+
+## 主要屏幕阅读器
+| 软件 | 平台 | 特点 |
+|------|------|------|
+| VoiceOver | macOS/iOS | Apple 设备内置，免费 |
+| NVDA | Windows | 开源免费，社区活跃 |
+| JAWS | Windows | 商业软件，功能全面 |
+| TalkBack | Android | Android 内置 |
+| VoiceOver | Safari (iOS) | 移动端测试 |
+
+## 测试协议
+### 导航测试
+- Heading Structure（标题层级）
+- Landmark Regions（地标区域）
+- Skip Links（跳转链接）
+- Tab Order（Tab 顺序）
+- Focus Visibility（焦点可见性）
+
+### 组件测试
+- Buttons（按钮角色和标签）
+- Links（链接描述）
+- Forms（表单标签和错误提示）
+- Modals（焦点陷阱）
+- Custom Widgets（自定义组件 ARIA）
+
+### 动态内容测试
+- Live Regions（实时区域）
+- Loading States（加载状态）
+- Error Messages（错误消息）
+- Toast/Notifications（通知）
+
+## Key Findings Format
+| 组件 | 屏幕阅读器行为 | 预期行为 | 状态 |
+|------|--------------|---------|------|
+| Name | 实际宣布内容 | 应该宣布的内容 | PASS/FAIL |
+
+## Related Concepts
+- [[WCAG 2.2]]
+- [[Keyboard Navigation Audit]]
+- [[ARIA Patterns]]
+
+## Source
+- [[Accessibility Auditor]]

wiki/concepts/Sequential-Handoffs.md

@@ -0,0 +1,44 @@
+---
+title: "Sequential Handoffs"
+type: concept
+tags: [multi-agent, workflow, coordination]
+last_updated: 2026-04-21
+---
+
+## Definition
+顺序交接（Sequential Handoffs）是一种多智能体工作流模式，其中每个智能体的输出直接作为下一个智能体的输入，按顺序依次传递。
+
+## Core Principle
+每个智能体的完整输出（而非摘要）成为下一个智能体的输入，确保信息完整性和上下文连贯性。
+
+## Workflow Pattern
+```
+Agent A → [完整输出] → Agent B → [完整输出] → Agent C
+```
+
+## Key Rules
+- **不摘要，只复制粘贴**：不要总结上一智能体的输出，直接使用完整输出
+- **保持完整性**：确保所有上下文、细节、证据都传递给下一个智能体
+- **按顺序执行**：必须等待前一个智能体完成后才能启动下一个
+
+## Example
+在 Multi-Agent Workflow: Startup MVP 中：
+1. Sprint Prioritizer 完成冲刺计划
+2. 完整计划直接传给 Backend Architect
+3. Backend Architect 完整输出传给 Frontend Developer
+
+## Advantages
+- 最大化信息保留
+- 减少上下文丢失
+- 便于追溯和审计
+
+## Disadvantages
+- 可能增加处理时间
+- 需要更多上下文窗口
+- 顺序执行无法并行加速
+
+## Related Concepts
+- [[Parallel Work]]：并行工作模式
+- [[Quality Gates]]：质量门控
+- [[Context Passing]]：上下文传递
+- [[Multi-Agent Team]]：多智能体团队

wiki/concepts/Statistical-Significance-Testing.md

@@ -0,0 +1,28 @@
+---
+title: "Statistical Significance Testing"
+type: concept
+tags: []
+last_updated: 2026-04-21
+---
+
+## Definition
+统计显著性检验，用于验证分析结论是否具有统计意义，而非随机偶然。
+
+## Key Principles
+- P-value < 0.05：结果具有统计显著性
+- 95% 置信区间：标准置信水平
+- 样本量验证：确保样本量足够检测预期效应
+- 效应量（Effect Size）：实际显著性而非仅统计显著性
+
+## Application in Analytics
+- A/B 测试结果验证
+- 营销活动效果评估
+- 趋势识别确认
+- 预测模型准确性验证
+
+## Related Concepts
+- [[Data-Driven Decision Making]]
+
+## Source
+- [[support-analytics-reporter]]
+

wiki/concepts/Support-Analytics.md

@@ -0,0 +1,45 @@
+---
+id: support-analytics
+title: "Support Analytics"
+type: concept
+tags: [customer-service, analytics, metrics]
+sources: [support-support-responder.md]
+last_updated: 2026-04-21
+---
+
+## Definition
+支持分析（Support Analytics），客户支持团队的数据驱动性能监控和优化框架，计算响应时间、解决率、CSAT 等关键指标并识别改进机会。
+
+## Key Metrics
+
+### Response Time Metrics
+- **Average First Response Time**：从创建工单到首次响应平均耗时
+- **Average Resolution Time**：从创建到完全解决的平均耗时
+- **SLA Compliance Rate**：满足响应/解决 SLA 的百分比
+
+### Quality Metrics
+- **First Contact Resolution Rate**：首次联系解决百分比（目标 ≥ 80%）
+- **Customer Satisfaction Score**：CSAT 平均分（目标 ≥ 4.5/5）
+- **Ticket Volume by Channel**：各渠道工单分布
+
+### Agent Performance
+- **Tickets Handled**：单个 agent 处理工单数
+- **Average Resolution Time per Agent**：Agent 级平均解决时间
+- **CSAT Score per Agent**：Agent 级客户满意度
+
+## Trend Analysis
+- **Volume Trend**：日均工单量环比变化
+- **Top Issues**：高频问题分类统计
+- **Satisfaction Trend**：月度 CSAT 环比变化
+- **Response Time Trend**：周均响应时间环比变化
+
+## Improvement Recommendations
+基于数据分析的优化建议，优先级分类：
+- **HIGH**：影响 SLA 或关键指标的改进
+- **MEDIUM**：效率提升机会
+- **LOW**：渐进优化
+
+## Connections
+- [[Support Responder]] — 分析数据的生成者
+- [[Customer Success]] — 分析驱动的主动干预目标
+- [[Knowledge Base Management]] — 分析揭示的知识缺口

wiki/concepts/Support-Tiers.md

@@ -0,0 +1,53 @@
+---
+id: support-tiers
+title: "Support Tiers"
+type: concept
+tags: [customer-service, support, escalation]
+sources: [support-support-responder.md]
+last_updated: 2026-04-21
+---
+
+## Definition
+支持层级（Support Tiers），分层客户服务架构，根据问题复杂度和客户类型将请求分配到不同专业级别的支持团队。
+
+## Tier Structure
+
+### Tier 1 — General Support
+**Capabilities**：
+- Account Management：账户创建、修改、恢复
+- Basic Troubleshooting：常见问题诊断和解决
+- Product Information：产品功能和使用指导
+- Billing Inquiries：账单查询和基本计费问题
+
+**Escalation Criteria**：
+- 技术复杂度超出基础知识范围
+- 政策例外请求需要管理层批准
+- 客户表达不满且一线无法解决
+
+### Tier 2 — Technical Support
+**Capabilities**：
+- Advanced Troubleshooting：复杂技术问题诊断
+- Integration Support：API 和系统集成支持
+- Custom Configuration：定制化配置指导
+- Bug Reproduction：问题复现和日志分析
+
+**Escalation Criteria**：
+- 需要工程团队介入的代码级别问题
+- 安全相关问题需要安全团队
+- 数据恢复需要 DBA 支持
+
+### Tier 3 — Specialist Support
+**Capabilities**：
+- Enterprise Support：企业级客户专属支持
+- Custom Development：定制开发需求评估
+- Security Incidents：安全事件响应
+- Data Recovery：重大数据恢复操作
+
+**Escalation Criteria**：
+- C-Level 管理层涉及
+- 法律咨询需求
+- 需要产品团队深度协作
+
+## Connections
+- [[Multi-Channel Support Framework]] — 层级嵌入的框架
+- [[Support Responder]] — 层级执行的主体

wiki/concepts/TCO-Total-Cost-of-Ownership.md

@@ -0,0 +1,36 @@
+---
+title: "TCO (Total Cost of Ownership)"
+type: concept
+tags: [cost-analysis, roi, tool-evaluation]
+sources: []
+last_updated: 2026-04-21
+---
+
+## Summary
+总拥有成本（TCO）是一种综合成本分析方法，计算工具或系统的全生命周期成本，支持长期投资决策。
+
+## Definition
+TCO 包含以下成本组成部分：
+- 许可费用（licensing）
+- 实施成本（implementation）
+- 培训成本（training）
+- 维护成本（maintenance）
+- 集成成本（integration）
+- 迁移成本（migration）
+- 支持成本（support）
+
+## Formula
+```
+TCO = (年许可费 × 年数) + 实施费 + 培训费 + (年维护费 × 年数) + 集成费 + 迁移费 + (年支持费 × 年数)
+```
+
+## Application
+- 工具选择决策
+- 预算规划
+- ROI 计算
+- 供应商比较
+
+## Related Concepts
+- [[Tool Evaluation Framework]]
+- [[ROI Analysis]]
+- [[Vendor Management]]

wiki/concepts/Time-boxed.md

@@ -0,0 +1,30 @@
+---
+title: "Time-boxed"
+type: concept
+tags: [workflow, time-management, scope-control]
+last_updated: 2026-04-21
+---
+
+## Definition
+Time-boxed 是一种时间管理机制，为单一任务设置最大时长限制，防止范围蔓延和无限期延误。
+
+## Purpose
+- 防止范围蔓延（scope creep）
+- 确保交付时间线
+- 提高专注度
+- 加速决策
+
+## Example
+Landing page sprint 时间表：
+| Time | Activity | Agent |
+|------|----------|-------|
+| 9:00 | Copy + design kick off | Content Creator + UI Designer |
+| 11:00 | Build starts | Frontend Developer |
+| 14:00 | First version ready | — |
+| 15:30 | Apply feedback | Frontend Developer |
+| 16:30 | Ship | Deploy |
+
+## Connections
+- [[Multi-Agent Workflow]]：所属工作流模式
+- [[Sprint Planning]]：相关时间规划概念
+

wiki/concepts/Tool-Evaluation-Framework.md

@@ -0,0 +1,33 @@
+---
+title: "Tool Evaluation Framework"
+type: concept
+tags: [tool-evaluation, framework, methodology]
+sources: []
+last_updated: 2026-04-21
+---
+
+## Summary
+工具评估框架是一种结构化的定量评估方法，通过加权评分体系对工具进行多维度评估，支持企业级工具选择决策。
+
+## Definition
+采用多准则决策分析（MCDA），通过七个核心维度对工具进行全面评估：
+- 功能性（functionality）
+- 可用性（usability）
+- 性能（performance）
+- 安全性（security）
+- 集成（integration）
+- 支持（support）
+- 成本（cost）
+
+## Key Metrics
+- 功能性测试：required features 80% + optional features 20%
+- 性能测试：平均响应时间、P95 响应时间
+- TCO 计算：许可 + 实施 + 培训 + 维护 + 集成 + 迁移 + 支持
+
+## Application
+用于企业工具选择、供应商评估、投资回报分析等场景。
+
+## Related Concepts
+- [[TCO（Total Cost of Ownership）]]
+- [[ROI Analysis]]
+- [[Vendor Management]]

wiki/concepts/Versioned-Draft.md

@@ -0,0 +1,25 @@
+---
+title: "Versioned Draft"
+type: concept
+tags: [writing, workflow, revision]
+sources: [sources/workflow-book-chapter.md]
+last_updated: 2026-04-21
+---
+
+## 定义
+版本化草稿是通过迭代修订循环产生的带版本号的章节草稿，每一版本基于前版本的编辑注释进行改进。
+
+## 核心特征
+- 带版本编号（如 Version 1、Version 2）
+- 基于反馈进行渐进改进
+- 记录编辑决策和假设
+- 暴露开放编辑问题供作者决策
+
+## 与反馈循环的关系
+版本化草稿依赖反馈循环机制：
+- Feedback Loop 提供结构化修订请求
+- Editorial Notes 标注假设和证据缺口
+- Next Step 定义下一版本的改进方向
+
+## Aliases
+- 版本化草稿

wiki/concepts/WCAG-2-2.md

@@ -0,0 +1,45 @@
+---
+title: "WCAG 2.2"
+description: Web Content Accessibility Guidelines 2.2，网页内容无障碍指南的国际标准
+tags: [accessibility, standards, wcag]
+---
+
+## Definition
+WCAG 2.2（Web Content Accessibility Guidelines 2.2）是 W3C 发布的网页内容无障碍指南标准，是国际公认的网站无障碍设计规范。最新版本于 2023 年 10 月正式发布。
+
+## POUR Principles（四大原则）
+### Perceivable（可感知）
+- 所有信息都必须以用户可感知的方式呈现
+- 包括文本替代、字幕、放大功能等
+
+### Operable（可操作）
+- 所有功能都必须可以通过键盘操作
+- 不能依赖特定设备或输入方式
+
+### Understandable（可理解）
+- 信息和操作必须是可理解的
+- 避免歧义，提供清晰的错误提示
+
+### Robust（健壮）
+- 内容必须能被各种用户代理可靠解释
+- 包括辅助技术和未来兼容性
+
+## Conformance Levels
+- **Level A**：最低要求，必须满足
+- **Level AA**：标准要求，大多数合规标准以此为准
+- **Level AAA**：最高要求，适用于特定场景
+
+## Key Success Criteria
+- 1.4.3 Contrast Minimum（对比度最低 4.5:1）
+- 2.1.1 Keyboard（所有功能可键盘操作）
+- 2.4.7 Focus Visible（焦点可见性）
+- 4.1.2 Name, Role, Value（名称、角色、值可机器读取）
+
+## Related Concepts
+- [[Screen Reader Testing]]
+- [[Keyboard Navigation Audit]]
+- [[POUR Principles]]
+
+## Source
+- [[Accessibility Auditor]]
+- W3C WCAG 2.2 Official