Auto-sync: 2026-04-25 04:02

wiki/concepts/ABTesting.md

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

wiki/concepts/Account-Health-Score.md

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

wiki/concepts/AdExtensions.md

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

wiki/concepts/AdStrength.md

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

wiki/concepts/Advantage+-Campaigns.md

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

wiki/concepts/Aha-Moment.md

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

wiki/concepts/Cockpit-Ergonomics.md

@@ -0,0 +1,23 @@
+---
+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]]

wiki/concepts/Constraint-Driven-Control-Mechanics.md

@@ -0,0 +1,30 @@
+---
+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]]

wiki/concepts/Conversions-API.md

@@ -0,0 +1,31 @@
+---
+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 的核心技能之一

wiki/concepts/CreativeFatigue.md

@@ -0,0 +1,49 @@
+---
+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]]

wiki/concepts/Custom-Audience-Engineering.md

@@ -0,0 +1,27 @@
+---
+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]] 做移动端归因

wiki/concepts/DealHealthScoring.md

@@ -0,0 +1,40 @@
+---
+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 策略制定依赖健康评分结果

wiki/concepts/Demo-Engineering.md

@@ -0,0 +1,55 @@
+---
+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 更强调以业务语言建立信任而非过早进入技术细节

wiki/concepts/FIA-Framework.md

@@ -0,0 +1,59 @@
+---
+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
+- 无已知冲突

wiki/concepts/Full-Funnel-Campaign-Architecture.md

@@ -0,0 +1,25 @@
+---
+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 的核心方法论

wiki/concepts/Hand-Tracking.md

@@ -0,0 +1,33 @@
+---
+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 界面设计

wiki/concepts/HookBodyCTA.md

@@ -0,0 +1,75 @@
+---
+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]]

wiki/concepts/Incrementality-Testing.md

@@ -0,0 +1,29 @@
+---
+title: "Incrementality Testing"
+type: concept
+tags: ["paid-media", "attribution", "measurement", "testing"]
+last_updated: 2026-04-25
+---
+
+## 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]] 导致的重复计算问题

wiki/concepts/MEDDPICC.md

@@ -0,0 +1,37 @@
+---
+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]] 的早期描述冲突：之前描述为"六个维度"，现已修正为八个维度

wiki/concepts/MessageMatch.md

@@ -0,0 +1,74 @@
+---
+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]]

wiki/concepts/Motion-Sickness-Threshold.md

@@ -0,0 +1,29 @@
+---
+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]]

wiki/concepts/Net-Revenue-Retention.md

@@ -0,0 +1,40 @@
+---
+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

wiki/concepts/POC-Scoping.md

@@ -0,0 +1,74 @@
+---
+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 周是最佳窗口

wiki/concepts/PersuasionArchitecture.md

@@ -0,0 +1,35 @@
+---
+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
+说服架构应用于：
+- 赢标主题的植入位置和频率
+- 执行摘要的结构
+- 案例研究的选择和排序
+- 风险/挑战部分的框架

wiki/concepts/PipelineVelocity.md

@@ -0,0 +1,31 @@
+---
+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 评估客户层级健康状况

wiki/concepts/QualityAdjustedCoverage.md

@@ -0,0 +1,39 @@
+---
+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 使用此指标生成质量调整覆盖度报告

wiki/concepts/ResponsiveSearchAds.md

@@ -0,0 +1,52 @@
+---
+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]]

wiki/concepts/SKAdNetwork.md

@@ -0,0 +1,28 @@
+---
+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 端的受众构建能力受限

wiki/concepts/Spatial-Computing.md

@@ -0,0 +1,43 @@
+---
+title: "Spatial Computing"
+type: concept
+tags: []
+sources: [xr-immersive-developer]
+last_updated: 2026-04-20
+---
+
+## Definition
+Spatial Computing 是将数字信息与物理空间深度融合的计算范式——通过 AR/VR/XR 技术在用户真实环境中叠加、渲染、交互虚拟内容，打破传统屏幕的二维限制，实现人-机-物理世界三位一体的交互体验。
+
+## Core Components
+- **3D 空间理解**：空间映射、深度感知、物体识别
+- **沉浸式渲染**：立体视觉、空间音频、触觉反馈
+- **自然交互**：手势识别、眼动追踪、语音控制、控制器输入
+- **空间锚定**：持久化 AR 锚点、多设备共享空间体验
+
+## Key Technologies
+- [[WebXR]]：浏览器原生 spatial computing API
+- [[A-Frame]]：WebXR 快速原型框架
+- [[Three.js]]：WebGL 3D 引擎
+- [[Babylon.js]]：专业级 WebXR 引擎
+- [[Hand-Tracking]]：手部追踪输入
+- Apple Vision Pro visionOS 空间计算平台
+- [[Meta-Quest]]：主流消费级 VR 头显
+- [[HoloLens]]：企业级 AR 头显
+
+## Spatial Computing Agents (The Agency)
+- [[XR-Immersive-Developer]]：浏览器前端 XR 体验开发专家
+- [[XR-Interface-Architect]]：XR 界面架构设计师
+- [[XR-Cockpit-Interaction-Specialist]]：座舱式固定视角交互专家
+- [[visionOS-Spatial-Engineer]]：Apple visionOS 原生空间计算工程师
+- [[macOS-Spatial-Metal-Engineer]]：Metal 图形底层工程师
+
+## Key Distinction
+Spatial Computing ≠ VR/AR：后者是技术手段，前者是更广泛的人机交互哲学——任何将计算嵌入物理空间的技术都属于 Spatial Computing 范畴。
+
+## Related
+- [[Hand-Tracking]]
+- [[Motion-Sickness-Threshold]]
+- [[Constraint-Driven-Control-Mechanics]]
+- [[LOD-System]]
+- [[Occlusion-Culling]]

wiki/concepts/Technical-Objection-Handling.md

@@ -0,0 +1,64 @@
+---
+title: "Technical Objection Handling"
+type: concept
+tags: [sales, pre-sales, objection-handling, negotiation]
+last_updated: 2026-04-25
+---
+
+## Definition
+技术异议处理是售前工程师解码买家表面问题背后真实关切的技能——技术异议很少是关于表面所问的问题，优秀 SE 必须识别真实问题并从根源回应，而非仅仅处理表面问题。
+
+## Common Objection Decoding
+
+| 买家表面问题 | 买家真实关切 | 回应策略 |
+|-------------|-------------|---------|
+| "是否支持 SSO？" | "这能通过我们的安全审查吗？" | 完整讲解安全架构，而非仅展示 SSO 复选框 |
+| "能处理我们的规模吗？" | "我们之前被供应商坑过" | 提供等量或更大规模客户的基准数据 |
+| "我们需要本地部署" | "我们的安全团队不会批准云端" 或 "我们在数据中心有沉没成本" | 理解是哪一种——这两个问题的对话完全不同 |
+| "你们的竞争对手向我们展示了 X" | "你们能匹配吗？" 或 "说服我你们更好" | 不要用竞品框架回应。先重新对齐他们的需求。 |
+| "我们需要自己构建" | "我们不信任供应商依赖" 或 "我们的工程团队想要这个项目" | 量化构建成本（团队、时间、维护）vs 购买成本。让机会成本变得可感知。 |
+
+## Core Principles
+
+### Decode, Don't React
+- "是否支持 SSO？" ≠ 需要展示 SSO 功能
+- 买家想知道的是：这会通过安全审查吗？我会被供应商锁定吗？
+- 展示完整安全架构和合规认证 > 列举功能清单
+
+### Respond to the Root Concern
+- 表面异议往往只是触发了真实问题的冰山一角
+- 追问"这为什么重要"往往能揭示真正关切
+
+### Be Honest About Limitations
+> "我们目前没有原生支持该功能。以下是我们的客户如何解决它，以及我们的路线图上有什么。"
+
+可信度是复合的。一次失实的回答会抵消十次诚实的回答。
+
+## Objection Handling Framework
+```markdown
+# Technical Objection: [Account Name]
+
+## Surface Question
+[买家实际问的问题]
+
+## Real Concern (Decoded)
+[表面问题背后的真实关切]
+
+## Root Cause
+[为什么这对他们重要]
+
+## Response Strategy
+[完整的响应，包括:]
+- 证明理解的陈述
+- 事实数据/客户参考
+- 演示时刻（如适用）
+- 路线图/生态方案（如相关）
+```
+
+## Connections
+- [[SalesEngineer]] — Technical Objection Handling 是 Sales Engineer 的核心能力之一
+- [[FIA-Framework]] — 竞争异议是 FIA Framework 的重要应用场景
+- [[DemoEngineering]] — Demo Engineering 是处理演示期间突发的技术异议的重要舞台
+
+## Contradictions
+- 无已知冲突

wiki/concepts/ThreeActProposalNarrative.md

@@ -0,0 +1,34 @@
+---
+title: "Three-Act Proposal Narrative"
+type: concept
+tags: ["proposal", "narrative", "storytelling", "RFP", "persuasion"]
+last_updated: 2026-04-20
+---
+
+## Definition
+三幕提案叙事是一种将 RFP 响应从合规检查清单转化为有说服力故事的框架，遵循叙事弧线而非清单逻辑。
+
+## The Three Acts
+
+### Act I — Understanding the Challenge
+**目标**：展示你比预期更深入地理解买方的世界
+
+- 用买方的语言反映他们的处境、约束和政治格局
+- 在此建立信任
+- 大多数失败的提案完全跳过这一幕，或用模板填充
+
+### Act II — The Solution Journey
+**目标**：引导评估者经历解决方案，而非倾倒功能列表
+
+- 每个能力映射到 Act I 中提出的挑战
+- 方法论解释为一系列决策，而非一堵流程图
+- 赢标主题在此做最重的说服工作
+
+### Act III — The Transformed State
+**目标**：描绘买方未来的具体图景
+
+- 量化的成果、时间线里程碑、风险降低指标
+- 评估者读完这一幕时，应该在想实施，而非评估
+
+## Key Principle
+提案在开篇 100 词内决定胜负。评估者通过前 100 词判断供应商是否真正理解他们的问题。执行摘要不是提案的摘要，而是提案的终局论证，放在最前面。

wiki/concepts/WebXR.md

@@ -0,0 +1,51 @@
+---
+title: "WebXR"
+type: concept
+tags: []
+sources: [xr-immersive-developer]
+last_updated: 2026-04-20
+---
+
+## Definition
+WebXR Device API 是 W3C 定义的浏览器原生标准 API，使网页能够创建沉浸式 AR/VR/XR 体验，无需安装原生应用。XR Immersive Developer 的核心技术栈基础。
+
+## Architecture
+```
+Browser (WebXR Device API)
+    ├── WebXR Device API (W3C Spec)
+    │   ├── XRSession (AR/VR/inline)
+    │   ├── XRWebGLLayer (GPU rendering)
+    │   ├── XRReferenceSpace (tracking)
+    │   └── XRInputSource (controllers/hands)
+    ├── XR Frameworks
+    │   ├── A-Frame (Mozilla, declarative)
+    │   ├── Three.js (WebGL abstraction)
+    │   └── Babylon.js (Microsoft, full-featured)
+    └── Hardware Targets
+        ├── [[Meta-Quest]] (via Oculus Browser)
+        ├── [[Vision-Pro]] (via Safari)
+        ├── [[HoloLens]] (via Edge)
+        └── [[Mobile-AR]] (ARKit/ARCore via Chrome Android)
+```
+
+## Supported Input Modes
+- **Controller**：6DoF 手柄追踪
+- **Hand Tracking**：裸手追踪（WebXR Hand Input Module）
+- **Gaze**：注视点交互
+- **Pinch**：捏合手势
+
+## Key Concepts
+- [[Hand-Tracking]]：裸手交互能力
+- [[LOD-System]]：渲染性能优化
+- [[Occlusion-Culling]]：遮挡剔除优化
+
+## Related Agents
+- [[XR-Immersive-Developer]]：WebXR 应用开发专家
+- [[XR-Interface-Architect]]：XR 界面架构设计
+- [[XR-Cockpit-Interaction-Specialist]]：座舱场景 WebXR 实现
+
+## Browser Support
+- Chrome/Edge（桌面 + Android）
+- Firefox Reality
+- Safari（[[Vision-Pro]] / iOS）
+- Oculus Browser（[[Meta-Quest]]）

wiki/concepts/WinThemes.md

@@ -0,0 +1,39 @@
+---
+title: "Win Themes"
+type: concept
+tags: ["proposal", "sales", "narrative", "RFP", "differentiation"]
+last_updated: 2026-04-20
+---
+
+## Definition
+赢标主题（Win Themes）是连接解决方案与买方最紧迫需求的核心叙事陈述，是提案的叙事支柱。3-5 个强主题贯穿整个提案——执行摘要、解决方案叙事、案例研究、定价逻辑。
+
+## Core Characteristics
+一个强赢标主题必须满足：
+- **命名买方具体挑战**，而非泛泛的行业问题
+- **连接具体能力与可衡量成果**
+- **差异化**，无需提及竞争对手即可实现
+- **可证明**，能用证据、案例或方法论支撑
+
+## Structure
+每个赢标主题的结构：
+```
+Buyer Need（买方需求）
+  ← 具体挑战，来自 RFP 或发现阶段
+Our Differentiator（我们的差异化因素）
+  ← 能力、方法论或资产
+Proof Point（证明点）
+  ← 指标、案例研究或证据
+Sections Where Appears（主题出现的章节）
+  ← 执行摘要、技术方案、案例研究、定价等
+```
+
+## Example
+**弱主题**："We have deep experience in digital transformation"（泛泛而言，可替换为任何客户）
+
+**强主题**："Our migration framework reduces cutover risk by staging critical workloads in parallel — the same approach that kept [similar client] at 99.97% uptime during a 14-month platform transition"（具体客户情境 + 可量化成果 + 方法论支撑）
+
+## Key Principles
+- 赢标主题必须贯穿整个提案：孤立的主题 = 隐形的主题
+- 内容库按主题而非章节组织，加速提案并保持叙事一致性
+- 每个主题必须经过压力测试：是否针对此买方？是否可证明？是否差异化？竞争对手能否也声称同样优势？