From a26d62bb6d817d451a6198090c5143a8ac0b8cd8 Mon Sep 17 00:00:00 2001 From: weishen Date: Sat, 25 Apr 2026 04:02:51 +0800 Subject: [PATCH] Auto-sync: 2026-04-25 04:02 --- wiki/concepts/ABTesting.md | 105 ++++++++++++++++++ wiki/concepts/Account-Health-Score.md | 47 ++++++++ wiki/concepts/AdExtensions.md | 105 ++++++++++++++++++ wiki/concepts/AdStrength.md | 54 +++++++++ wiki/concepts/Advantage+-Campaigns.md | 28 +++++ wiki/concepts/Aha-Moment.md | 52 +++++++++ wiki/concepts/Cockpit-Ergonomics.md | 23 ++++ .../Constraint-Driven-Control-Mechanics.md | 30 +++++ wiki/concepts/Conversions-API.md | 31 ++++++ wiki/concepts/CreativeFatigue.md | 49 ++++++++ wiki/concepts/Custom-Audience-Engineering.md | 27 +++++ wiki/concepts/DealHealthScoring.md | 40 +++++++ wiki/concepts/Demo-Engineering.md | 55 +++++++++ wiki/concepts/FIA-Framework.md | 59 ++++++++++ .../Full-Funnel-Campaign-Architecture.md | 25 +++++ wiki/concepts/Hand-Tracking.md | 33 ++++++ wiki/concepts/HookBodyCTA.md | 75 +++++++++++++ wiki/concepts/Incrementality-Testing.md | 29 +++++ wiki/concepts/MEDDPICC.md | 37 ++++++ wiki/concepts/MessageMatch.md | 74 ++++++++++++ wiki/concepts/Motion-Sickness-Threshold.md | 29 +++++ wiki/concepts/Net-Revenue-Retention.md | 40 +++++++ wiki/concepts/POC-Scoping.md | 74 ++++++++++++ wiki/concepts/PersuasionArchitecture.md | 35 ++++++ wiki/concepts/PipelineVelocity.md | 31 ++++++ wiki/concepts/QualityAdjustedCoverage.md | 39 +++++++ wiki/concepts/ResponsiveSearchAds.md | 52 +++++++++ wiki/concepts/SKAdNetwork.md | 28 +++++ wiki/concepts/Spatial-Computing.md | 43 +++++++ wiki/concepts/Technical-Objection-Handling.md | 64 +++++++++++ wiki/concepts/ThreeActProposalNarrative.md | 34 ++++++ wiki/concepts/WebXR.md | 51 +++++++++ wiki/concepts/WinThemes.md | 39 +++++++ wiki/entities/JohnWilliams.md | 7 +- wiki/entities/LinkedIn-Campaign-Manager.md | 22 ++++ wiki/entities/Meta-Ads-Manager.md | 22 ++++ wiki/entities/TikTok-Ads.md | 18 +++ wiki/index.md | 37 ++++-- wiki/log.md | 64 +++++++++++ wiki/overview.md | 36 ++++-- wiki/sources/macos-spatial-metal-engineer.md | 62 +++++++++++ .../sources/paid-media-creative-strategist.md | 63 +++++++++++ .../paid-media-paid-social-strategist.md | 54 +++++++++ .../sources/paid-media-tracking-specialist.md | 55 +++++++++ wiki/sources/sales-account-strategist.md | 63 +++++++++++ wiki/sources/sales-coach.md | 54 +++++++++ wiki/sources/sales-deal-strategist.md | 61 ++++++++++ wiki/sources/sales-discovery-coach.md | 50 +++++++++ wiki/sources/sales-engineer.md | 59 ++++++++++ wiki/sources/sales-pipeline-analyst.md | 46 ++++++++ wiki/sources/sales-proposal-strategist.md | 51 +++++++++ .../terminal-integration-specialist.md | 54 +++++++++ .../xr-cockpit-interaction-specialist.md | 41 +++++++ wiki/sources/xr-immersive-developer.md | 55 +++++++++ wiki/sources/xr-interface-architect.md | 49 ++++++++ 55 files changed, 2535 insertions(+), 25 deletions(-) create mode 100644 wiki/concepts/ABTesting.md create mode 100644 wiki/concepts/Account-Health-Score.md create mode 100644 wiki/concepts/AdExtensions.md create mode 100644 wiki/concepts/AdStrength.md create mode 100644 wiki/concepts/Advantage+-Campaigns.md create mode 100644 wiki/concepts/Aha-Moment.md create mode 100644 wiki/concepts/Cockpit-Ergonomics.md create mode 100644 wiki/concepts/Constraint-Driven-Control-Mechanics.md create mode 100644 wiki/concepts/Conversions-API.md create mode 100644 wiki/concepts/CreativeFatigue.md create mode 100644 wiki/concepts/Custom-Audience-Engineering.md create mode 100644 wiki/concepts/DealHealthScoring.md create mode 100644 wiki/concepts/Demo-Engineering.md create mode 100644 wiki/concepts/FIA-Framework.md create mode 100644 wiki/concepts/Full-Funnel-Campaign-Architecture.md create mode 100644 wiki/concepts/Hand-Tracking.md create mode 100644 wiki/concepts/HookBodyCTA.md create mode 100644 wiki/concepts/Incrementality-Testing.md create mode 100644 wiki/concepts/MEDDPICC.md create mode 100644 wiki/concepts/MessageMatch.md create mode 100644 wiki/concepts/Motion-Sickness-Threshold.md create mode 100644 wiki/concepts/Net-Revenue-Retention.md create mode 100644 wiki/concepts/POC-Scoping.md create mode 100644 wiki/concepts/PersuasionArchitecture.md create mode 100644 wiki/concepts/PipelineVelocity.md create mode 100644 wiki/concepts/QualityAdjustedCoverage.md create mode 100644 wiki/concepts/ResponsiveSearchAds.md create mode 100644 wiki/concepts/SKAdNetwork.md create mode 100644 wiki/concepts/Spatial-Computing.md create mode 100644 wiki/concepts/Technical-Objection-Handling.md create mode 100644 wiki/concepts/ThreeActProposalNarrative.md create mode 100644 wiki/concepts/WebXR.md create mode 100644 wiki/concepts/WinThemes.md create mode 100644 wiki/entities/LinkedIn-Campaign-Manager.md create mode 100644 wiki/entities/Meta-Ads-Manager.md create mode 100644 wiki/entities/TikTok-Ads.md create mode 100644 wiki/sources/macos-spatial-metal-engineer.md create mode 100644 wiki/sources/paid-media-creative-strategist.md create mode 100644 wiki/sources/paid-media-paid-social-strategist.md create mode 100644 wiki/sources/paid-media-tracking-specialist.md create mode 100644 wiki/sources/sales-account-strategist.md create mode 100644 wiki/sources/sales-coach.md create mode 100644 wiki/sources/sales-deal-strategist.md create mode 100644 wiki/sources/sales-discovery-coach.md create mode 100644 wiki/sources/sales-engineer.md create mode 100644 wiki/sources/sales-pipeline-analyst.md create mode 100644 wiki/sources/sales-proposal-strategist.md create mode 100644 wiki/sources/terminal-integration-specialist.md create mode 100644 wiki/sources/xr-cockpit-interaction-specialist.md create mode 100644 wiki/sources/xr-immersive-developer.md create mode 100644 wiki/sources/xr-interface-architect.md diff --git a/wiki/concepts/ABTesting.md b/wiki/concepts/ABTesting.md new file mode 100644 index 00000000..63cac4a1 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Account-Health-Score.md b/wiki/concepts/Account-Health-Score.md new file mode 100644 index 00000000..09542f6e --- /dev/null +++ b/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 维护账户健康评分 diff --git a/wiki/concepts/AdExtensions.md b/wiki/concepts/AdExtensions.md new file mode 100644 index 00000000..423bacf8 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/AdStrength.md b/wiki/concepts/AdStrength.md new file mode 100644 index 00000000..d224047c --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Advantage+-Campaigns.md b/wiki/concepts/Advantage+-Campaigns.md new file mode 100644 index 00000000..38555498 --- /dev/null +++ b/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+ 倾向于减少人工结构干预 diff --git a/wiki/concepts/Aha-Moment.md b/wiki/concepts/Aha-Moment.md new file mode 100644 index 00000000..24c8c1b5 --- /dev/null +++ b/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 +- 无已知冲突 diff --git a/wiki/concepts/Cockpit-Ergonomics.md b/wiki/concepts/Cockpit-Ergonomics.md new file mode 100644 index 00000000..3448b4c8 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Constraint-Driven-Control-Mechanics.md b/wiki/concepts/Constraint-Driven-Control-Mechanics.md new file mode 100644 index 00000000..ccf1f88a --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Conversions-API.md b/wiki/concepts/Conversions-API.md new file mode 100644 index 00000000..458e0e30 --- /dev/null +++ b/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 的核心技能之一 diff --git a/wiki/concepts/CreativeFatigue.md b/wiki/concepts/CreativeFatigue.md new file mode 100644 index 00000000..2b16fe23 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Custom-Audience-Engineering.md b/wiki/concepts/Custom-Audience-Engineering.md new file mode 100644 index 00000000..028f7c13 --- /dev/null +++ b/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]] 做移动端归因 diff --git a/wiki/concepts/DealHealthScoring.md b/wiki/concepts/DealHealthScoring.md new file mode 100644 index 00000000..e694a463 --- /dev/null +++ b/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 策略制定依赖健康评分结果 diff --git a/wiki/concepts/Demo-Engineering.md b/wiki/concepts/Demo-Engineering.md new file mode 100644 index 00000000..2108ec28 --- /dev/null +++ b/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 更强调以业务语言建立信任而非过早进入技术细节 diff --git a/wiki/concepts/FIA-Framework.md b/wiki/concepts/FIA-Framework.md new file mode 100644 index 00000000..9922b690 --- /dev/null +++ b/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 +- 无已知冲突 diff --git a/wiki/concepts/Full-Funnel-Campaign-Architecture.md b/wiki/concepts/Full-Funnel-Campaign-Architecture.md new file mode 100644 index 00000000..6dba0832 --- /dev/null +++ b/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 的核心方法论 diff --git a/wiki/concepts/Hand-Tracking.md b/wiki/concepts/Hand-Tracking.md new file mode 100644 index 00000000..ba16ba3b --- /dev/null +++ b/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 界面设计 diff --git a/wiki/concepts/HookBodyCTA.md b/wiki/concepts/HookBodyCTA.md new file mode 100644 index 00000000..80a1d12d --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Incrementality-Testing.md b/wiki/concepts/Incrementality-Testing.md new file mode 100644 index 00000000..292fa0bb --- /dev/null +++ b/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]] 导致的重复计算问题 diff --git a/wiki/concepts/MEDDPICC.md b/wiki/concepts/MEDDPICC.md new file mode 100644 index 00000000..bebda9ba --- /dev/null +++ b/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]] 的早期描述冲突：之前描述为"六个维度"，现已修正为八个维度 diff --git a/wiki/concepts/MessageMatch.md b/wiki/concepts/MessageMatch.md new file mode 100644 index 00000000..0433ecc4 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Motion-Sickness-Threshold.md b/wiki/concepts/Motion-Sickness-Threshold.md new file mode 100644 index 00000000..8c927453 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Net-Revenue-Retention.md b/wiki/concepts/Net-Revenue-Retention.md new file mode 100644 index 00000000..109e99b0 --- /dev/null +++ b/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 diff --git a/wiki/concepts/POC-Scoping.md b/wiki/concepts/POC-Scoping.md new file mode 100644 index 00000000..09041e70 --- /dev/null +++ b/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 周是最佳窗口 diff --git a/wiki/concepts/PersuasionArchitecture.md b/wiki/concepts/PersuasionArchitecture.md new file mode 100644 index 00000000..517fd783 --- /dev/null +++ b/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 +说服架构应用于： +- 赢标主题的植入位置和频率 +- 执行摘要的结构 +- 案例研究的选择和排序 +- 风险/挑战部分的框架 diff --git a/wiki/concepts/PipelineVelocity.md b/wiki/concepts/PipelineVelocity.md new file mode 100644 index 00000000..548a65bf --- /dev/null +++ b/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 评估客户层级健康状况 diff --git a/wiki/concepts/QualityAdjustedCoverage.md b/wiki/concepts/QualityAdjustedCoverage.md new file mode 100644 index 00000000..0c29bc4d --- /dev/null +++ b/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 使用此指标生成质量调整覆盖度报告 diff --git a/wiki/concepts/ResponsiveSearchAds.md b/wiki/concepts/ResponsiveSearchAds.md new file mode 100644 index 00000000..df4fb34e --- /dev/null +++ b/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]] diff --git a/wiki/concepts/SKAdNetwork.md b/wiki/concepts/SKAdNetwork.md new file mode 100644 index 00000000..64aebf2d --- /dev/null +++ b/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 端的受众构建能力受限 diff --git a/wiki/concepts/Spatial-Computing.md b/wiki/concepts/Spatial-Computing.md new file mode 100644 index 00000000..2be28ff4 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Technical-Objection-Handling.md b/wiki/concepts/Technical-Objection-Handling.md new file mode 100644 index 00000000..5d403fc7 --- /dev/null +++ b/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 +- 无已知冲突 diff --git a/wiki/concepts/ThreeActProposalNarrative.md b/wiki/concepts/ThreeActProposalNarrative.md new file mode 100644 index 00000000..08c4f96c --- /dev/null +++ b/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 词判断供应商是否真正理解他们的问题。执行摘要不是提案的摘要，而是提案的终局论证，放在最前面。 diff --git a/wiki/concepts/WebXR.md b/wiki/concepts/WebXR.md new file mode 100644 index 00000000..60160352 --- /dev/null +++ b/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]]） diff --git a/wiki/concepts/WinThemes.md b/wiki/concepts/WinThemes.md new file mode 100644 index 00000000..4688b2a1 --- /dev/null +++ b/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 +- 赢标主题必须贯穿整个提案：孤立的主题 = 隐形的主题 +- 内容库按主题而非章节组织，加速提案并保持叙事一致性 +- 每个主题必须经过压力测试：是否针对此买方？是否可证明？是否差异化？竞争对手能否也声称同样优势？ diff --git a/wiki/entities/JohnWilliams.md b/wiki/entities/JohnWilliams.md index dfadfaf4..58b3f085 100644 --- a/wiki/entities/JohnWilliams.md +++ b/wiki/entities/JohnWilliams.md @@ -10,11 +10,12 @@ last_updated: 2026-04-20 - John Williams ## Overview -John Williams（Twitter @itallstartedwithaidea）是 [[PaidMediaPpcStrategist]] Agent 的作者，资深付费媒体策略师。该 Agent persona 即基于他的专业经验构建。 +John Williams（Twitter @itallstartedwithaidea）是 [[PaidMediaPpcStrategist]] Agent 和 [[PaidMediaPaidSocialStrategist]] Agent 的作者，资深付费媒体策略师。该 Agent persona 即基于他的专业经验构建。 ## Role - [[PaidMediaPpcStrategist]] Agent 的设计者和 Prompt 作者 -- 专注于 Google Ads、Microsoft Advertising、Amazon Ads 三大平台的企业级付费媒体策略 +- [[PaidMediaPaidSocialStrategist]] Agent 的设计者和 Prompt 作者 +- 专注于 Google Ads、Microsoft Advertising、Amazon Ads 三大平台，以及 Meta、LinkedIn、TikTok 等社交广告平台的企业级付费媒体策略 ## Connections -- 创建了 [[PaidMediaPpcStrategist]] Agent，定义了其核心能力和专业范围 +- 创建了 [[PaidMediaPpcStrategist]] Agent 和 [[PaidMediaPaidSocialStrategist]] Agent，定义了其核心能力和专业范围 diff --git a/wiki/entities/LinkedIn-Campaign-Manager.md b/wiki/entities/LinkedIn-Campaign-Manager.md new file mode 100644 index 00000000..d02cc179 --- /dev/null +++ b/wiki/entities/LinkedIn-Campaign-Manager.md @@ -0,0 +1,22 @@ +--- +title: "LinkedIn Campaign Manager" +type: entity +tags: ["company", "advertising", "paid-social", "b2b", "linkedin"] +last_updated: 2026-04-25 +--- + +## Aliases +- LinkedIn Campaign Manager +- LinkedIn Ads + +## Overview +LinkedIn Campaign Manager 是 LinkedIn 广告的统一管理后台，专注于 B2B 广告定向，是[[Paid Media Paid Social Strategist]] Agent 的核心工具之一。 + +## Role in The Agency +- 支持赞助内容（ Sponsored Content）、消息广告、对话广告、文档广告 +- 支持职位定向、公司定向、账户定向（Account Targeting）和 ABM 名单上传 +- 配备 LinkedIn Audience Network 和 Lead Gen Forms + +## Connections +- 与 [[Meta Ads Manager]] 同属社交广告平台，但受众特征和广告形式有显著差异 +- [[Paid Media Paid Social Strategist]] Agent 区分专业内容（LinkedIn）vs. UGC 风格（Meta/TikTok） diff --git a/wiki/entities/Meta-Ads-Manager.md b/wiki/entities/Meta-Ads-Manager.md new file mode 100644 index 00000000..a3e465c1 --- /dev/null +++ b/wiki/entities/Meta-Ads-Manager.md @@ -0,0 +1,22 @@ +--- +title: "Meta Ads Manager" +type: entity +tags: ["company", "advertising", "paid-social", "meta"] +last_updated: 2026-04-25 +--- + +## Aliases +- Facebook Ads Manager +- Meta Ads Manager +- Meta Business Suite + +## Overview +Meta Ads Manager 是 Facebook/Instagram 广告的统一管理平台，是付费社交广告的核心渠道之一。由 Meta Platforms（原 Facebook）开发和运营。 + +## Role in The Agency +- [[Paid Media Paid Social Strategist]] Agent 的核心工具之一 +- 支持 [[Advantage+ Campaigns]]、CBO/ABO 架构、像素追踪、Conversions API + +## Connections +- 支持 [[Custom Audience Engineering]]（像素受众）和 [[Conversions API]] 双轨追踪 +- 可与 [[TikTok Ads]] 共同用于跨平台受众测试 diff --git a/wiki/entities/TikTok-Ads.md b/wiki/entities/TikTok-Ads.md new file mode 100644 index 00000000..85005728 --- /dev/null +++ b/wiki/entities/TikTok-Ads.md @@ -0,0 +1,18 @@ +--- +title: "TikTok Ads" +type: entity +tags: ["company", "advertising", "paid-social", "tiktok"] +last_updated: 2026-04-25 +--- + +## Overview +TikTok Ads 是 TikTok 广告平台，由字节跳动（ByteDance）运营，是[[Paid Media Paid Social Strategist]] Agent 的核心工具之一。 + +## Role in The Agency +- [[Paid Media Paid Social Strategist]] Agent 的核心工具之一 +- 支持 Spark Ads、TopView、信息流广告（In-Feed Ads）、品牌标签挑战（Branded Hashtag Challenges） +- 可通过 TikTok Creative Center 进行创意趋势识别和快速适配 + +## Connections +- [[Paid Media Paid Social Strategist]] Agent 强调 TikTok 创意必须采用 UGC 原生风格 +- 与 [[Meta Ads Manager]] 共享受众工程方法论（像素、受众排除等） diff --git a/wiki/index.md b/wiki/index.md index ab77a4eb..09ef9996 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -4,7 +4,14 @@ - [Overview](overview.md) — living synthesis ## Sources -- [2026-04-25] [Outbound Strategist Agent](sources/sales-outbound-strategist.md) +- [2026-04-24] [XR Interface Architect Agent Personality](sources/xr-interface-architect.md) +- [2026-04-24] [macOS Spatial/Metal Engineer Agent Personality](sources/macos-spatial-metal-engineer.md) +- [2026-04-24] [Terminal Integration Specialist](sources/terminal-integration-specialist.md) +- [2026-04-24] [XR Immersive Developer Agent Personality](sources/xr-immersive-developer.md) +- [2026-04-24] [XR Cockpit Interaction Specialist Agent](sources/xr-cockpit-interaction-specialist.md) +- [2026-04-24] [Sales Engineer Agent](sources/sales-engineer.md) +- [2026-04-24] [Pipeline Analyst Agent](sources/sales-pipeline-analyst.md) +- [2026-04-24] [Outbound Strategist Agent](sources/sales-outbound-strategist.md) - [2026-04-24] [Deal Strategist Agent](sources/sales-deal-strategist.md) - [2026-04-24] [Account Strategist Agent](sources/sales-account-strategist.md) - [2026-04-24] [Sales Proposal Strategist](sources/sales-proposal-strategist.md) @@ -394,15 +401,7 @@ - [2026-04-20] [project-management-project-shepherd](sources/project-management-project-shepherd.md) — (expected: wiki/sources/project-management-project-shepherd.md — source missing) - [2026-04-20] [project-management-studio-producer](sources/project-management-studio-producer.md) — (expected: wiki/sources/project-management-studio-producer.md — source missing) - [2026-04-20] [visionos-spatial-engineer](sources/visionos-spatial-engineer.md) — (expected: wiki/sources/visionos-spatial-engineer.md — source missing) -- [2026-04-20] [xr-interface-architect](sources/xr-interface-architect.md) — (expected: wiki/sources/xr-interface-architect.md — source missing) -- [2026-04-20] [macos-spatial-metal-engineer](sources/macos-spatial-metal-engineer.md) — (expected: wiki/sources/macos-spatial-metal-engineer.md — source missing) -- [2026-04-20] [terminal-integration-specialist](sources/terminal-integration-specialist.md) — (expected: wiki/sources/terminal-integration-specialist.md — source missing) -- [2026-04-20] [xr-immersive-developer](sources/xr-immersive-developer.md) — (expected: wiki/sources/xr-immersive-developer.md — source missing) -- [2026-04-20] [xr-cockpit-interaction-specialist](sources/xr-cockpit-interaction-specialist.md) — (expected: wiki/sources/xr-cockpit-interaction-specialist.md — source missing) -- [2026-04-20] [sales-engineer](sources/sales-engineer.md) — (expected: wiki/sources/sales-engineer.md — source missing) - [2026-04-20] [specialized-model-qa](sources/specialized-model-qa.md) — (expected: wiki/sources/specialized-model-qa.md — source missing) -- [2026-04-20] [sales-pipeline-analyst](sources/sales-pipeline-analyst.md) — (expected: wiki/sources/sales-pipeline-analyst.md — source missing) -- [2026-04-20] [sales-outbound-strategist](sources/sales-outbound-strategist.md) — (expected: wiki/sources/sales-outbound-strategist.md — source missing) - [2026-04-20] [specialized-cultural-intelligence-strategist](sources/specialized-cultural-intelligence-strategist.md) — (expected: wiki/sources/specialized-cultural-intelligence-strategist.md — source missing) - [2026-04-20] [healthcare-marketing-compliance](sources/healthcare-marketing-compliance.md) — (expected: wiki/sources/healthcare-marketing-compliance.md — source missing) - [2026-04-20] [llm-wiki](sources/llm-wiki.md) — (expected: wiki/sources/llm-wiki.md — source missing) @@ -800,6 +799,7 @@ - [AGENTS.md](concepts/AGENTS.md.md) - [Agile-Ceremonies](concepts/Agile-Ceremonies.md) - [AgilePractices](concepts/AgilePractices.md) +- [Aha-Moment](concepts/Aha-Moment.md) - [AI-Agent](concepts/AI-Agent.md) - [AI-Auto-Response](concepts/AI-Auto-Response.md) - [AI-ChatOps](concepts/AI-ChatOps.md) @@ -878,6 +878,7 @@ - [Cloud-Service-Delivery](concepts/Cloud-Service-Delivery.md) - [Cluster-Autoscaler](concepts/Cluster-Autoscaler.md) - [CMDB](concepts/CMDB.md) +- [Cockpit-Ergonomics](concepts/Cockpit-Ergonomics.md) - [CodeWeaver](concepts/CodeWeaver.md) - [Columnar-Storage](concepts/Columnar-Storage.md) - [Compaction](concepts/Compaction.md) @@ -885,6 +886,7 @@ - [Compliance-Automation](concepts/Compliance-Automation.md) - [Configuration-Management](concepts/Configuration-Management.md) - [Consensus-Voting-Pattern](concepts/Consensus-Voting-Pattern.md) +- [Constraint-Driven-Control-Mechanics](concepts/Constraint-Driven-Control-Mechanics.md) - [Container-Lifecycle-Hardening](concepts/Container-Lifecycle-Hardening.md) - [Content Automation](concepts/Content Automation.md) - [Content-Creator](concepts/Content-Creator.md) @@ -914,8 +916,10 @@ - [Data-Governance](concepts/Data-Governance.md) - [Data-Sovereignty](concepts/Data-Sovereignty.md) - [DBA-Role-Evolution](concepts/DBA-Role-Evolution.md) +- [DealHealthScoring](concepts/DealHealthScoring.md) - [Defense-in-Depth](concepts/Defense-in-Depth.md) - [Defuddle](concepts/Defuddle.md) +- [Demo-Engineering](concepts/Demo-Engineering.md) - [Dependency-Management](concepts/Dependency-Management.md) - [Deployment-Automation](concepts/Deployment-Automation.md) - [Deployment-vs-Release](concepts/Deployment-vs-Release.md) @@ -965,6 +969,7 @@ - [Feature-Flag](concepts/Feature-Flag.md) - [FeatureList](concepts/FeatureList.md) - [Federated-Access](concepts/Federated-Access.md) +- [FIA-Framework](concepts/FIA-Framework.md) - [File-System-First-UI](concepts/File-System-First-UI.md) - [File-Watcher](concepts/File-Watcher.md) - [FinOps](concepts/FinOps.md) @@ -984,6 +989,7 @@ - [GitOps](concepts/GitOps.md) - [GPG-密钥验证](concepts/GPG-密钥验证.md) - [Green-Computing](concepts/Green-Computing.md) +- [Hand-Tracking](concepts/Hand-Tracking.md) - [HCX](concepts/HCX.md) - [Headless-服务器](concepts/Headless-服务器.md) - [Heartbeat-Monitoring](concepts/Heartbeat-Monitoring.md) @@ -999,7 +1005,7 @@ - [HybridDnsResolution](concepts/HybridDnsResolution.md) - [Hyperautomation](concepts/Hyperautomation.md) - [IAST](concepts/IAST.md) -- [ICP (Ideal Customer Profile)](concepts/ICP-Ideal-Customer-Profile.md) +- [ICP-Ideal-Customer-Profile](concepts/ICP-Ideal-Customer-Profile.md) - [Idea-Density](concepts/Idea-Density.md) - [Idea-Museum](concepts/Idea-Museum.md) - [Identity-Governance](concepts/Identity-Governance.md) @@ -1051,11 +1057,11 @@ - [Memory-Backend](concepts/Memory-Backend.md) - [MEMORY.md](concepts/MEMORY.md.md) - [MessageMatch](concepts/MessageMatch.md) -- [Multi-Channel-Sequence-Architecture](concepts/Multi-Channel-Sequence-Architecture.md) - [Micro-Recovery](concepts/Micro-Recovery.md) - [Model-Context-Protocol](concepts/Model-Context-Protocol.md) - [Model-Fallback](concepts/Model-Fallback.md) - [Morning-Briefing](concepts/Morning-Briefing.md) +- [Motion-Sickness-Threshold](concepts/Motion-Sickness-Threshold.md) - [MPP](concepts/MPP.md) - [MTTA](concepts/MTTA.md) - [MTTD](concepts/MTTD.md) @@ -1064,6 +1070,7 @@ - [Multi-AgentHub](concepts/Multi-AgentHub.md) - [Multi-AI-Review](concepts/Multi-AI-Review.md) - [Multi-Channel-Delivery](concepts/Multi-Channel-Delivery.md) +- [Multi-Channel-Sequence-Architecture](concepts/Multi-Channel-Sequence-Architecture.md) - [Multi-Cloud-Strategy](concepts/Multi-Cloud-Strategy.md) - [Multi-Database-Architecture](concepts/Multi-Database-Architecture.md) - [Multi-factor-Authentication](concepts/Multi-factor-Authentication.md) @@ -1094,10 +1101,12 @@ - [Personalization](concepts/Personalization.md) - [PersuasionArchitecture](concepts/PersuasionArchitecture.md) - [Pipeline](concepts/Pipeline.md) +- [PipelineVelocity](concepts/PipelineVelocity.md) - [Pivot-Strategy](concepts/Pivot-Strategy.md) - [Plan-Mode](concepts/Plan-Mode.md) - [PMDelegationPattern](concepts/PMDelegationPattern.md) - [pmset](concepts/pmset.md) +- [POC-Scoping](concepts/POC-Scoping.md) - [Pod-Security-Context](concepts/Pod-Security-Context.md) - [Policy-as-Code](concepts/Policy-as-Code.md) - [PRD生成工作流](concepts/PRD生成工作流.md) @@ -1118,6 +1127,7 @@ - [PUID-PGID](concepts/PUID-PGID.md) - [Purpose-Built-Databases](concepts/Purpose-Built-Databases.md) - [Quality-Scoring-Algorithm](concepts/Quality-Scoring-Algorithm.md) +- [QualityAdjustedCoverage](concepts/QualityAdjustedCoverage.md) - [RAG](concepts/RAG.md) - [Reality-Signal](concepts/Reality-Signal.md) - [Reciprocal-Rank-Fusion](concepts/Reciprocal-Rank-Fusion.md) @@ -1166,7 +1176,6 @@ - [Self-Interest](concepts/Self-Interest.md) - [Self-Referential-Computation](concepts/Self-Referential-Computation.md) - [Self-Sufficiency](concepts/Self-Sufficiency.md) -- [Signal-Based-Selling-Framework](concepts/Signal-Based-Selling-Framework.md) - [Semantic-Deduplication](concepts/Semantic-Deduplication.md) - [Semantic-Search](concepts/Semantic-Search.md) - [Semantic-Versioning](concepts/Semantic-Versioning.md) @@ -1179,6 +1188,7 @@ - [SharedStateCoordination](concepts/SharedStateCoordination.md) - [Shift-Left-Security](concepts/Shift-Left-Security.md) - [Shift-Right-Security](concepts/Shift-Right-Security.md) +- [Signal-Based-Selling-Framework](concepts/Signal-Based-Selling-Framework.md) - [Single-Control-Plane](concepts/Single-Control-Plane.md) - [SKAdNetwork](concepts/SKAdNetwork.md) - [SmartBidding](concepts/SmartBidding.md) @@ -1190,6 +1200,7 @@ - [Solution-Architecture](concepts/Solution-Architecture.md) - [SOUL.md](concepts/SOUL.md.md) - [Source-Grounding](concepts/Source-Grounding.md) +- [Spatial-Computing](concepts/Spatial-Computing.md) - [Split](concepts/Split.md) - [Spot-Instances](concepts/Spot-Instances.md) - [SSE-Server-Sent-Events](concepts/SSE-Server-Sent-Events.md) @@ -1210,6 +1221,7 @@ - [Taylorism](concepts/Taylorism.md) - [TCP隧道](concepts/TCP隧道.md) - [Technical-Architecture](concepts/Technical-Architecture.md) +- [Technical-Objection-Handling](concepts/Technical-Objection-Handling.md) - [Telegram-Trigger](concepts/Telegram-Trigger.md) - [Telephony-Integration](concepts/Telephony-Integration.md) - [Terraform-Modules](concepts/Terraform-Modules.md) @@ -1253,6 +1265,7 @@ - [Webhook](concepts/Webhook.md) - [Webhook-Proxy-Pattern](concepts/Webhook-Proxy-Pattern.md) - [WEBHOOK_URL](concepts/WEBHOOK_URL.md) +- [WebXR](concepts/WebXR.md) - [Weekly-Pattern-Analysis](concepts/Weekly-Pattern-Analysis.md) - [What-If-Simulation](concepts/What-If-Simulation.md) - [WinThemes](concepts/WinThemes.md) diff --git a/wiki/log.md b/wiki/log.md index b7817438..66acea7f 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1,3 +1,49 @@ +## [2026-04-25] ingest | XR Interface Architect Agent Personality +- Source file: Agent/agency-agents/spatial-computing/xr-interface-architect.md +- Status: ✅ 成功摄入 +- Summary: XR Interface Architect——专注为 AR/VR/XR 沉浸式环境设计空间直觉化 UX/UI 的 AI Agent，支持 HUD / 浮动菜单 / 交互区域，支持四种输入模型（直接触摸/注视+捏合/控制器/手势），以人体工程学约束减少晕动症，构建座舱/仪表盘/可穿戴界面布局模板，运行可用性验证实验 +- Concepts created: [[SpatialInterfaceDesign]], [[MotionSicknessMitigation]], [[PresenceEnhancement]], [[MultimodalInput]], [[HUDDesign]] +- Entities created: [[XRImmersiveDeveloper]], [[XRCockpitInteractionSpecialist]] +- Contradictions detected: 无内容冲突；该 Agent 侧重界面设计与 UX，与侧重底层渲染工程的 [[macOS Spatial/Metal Engineer]] 不在同一问题域 +- Source page: wiki/sources/xr-interface-architect.md +- Notes: 更新了 overview.md 中 [[xr-cockpit-interaction-specialist]] 条目的层级关系描述（原文为 [[XR-Interface-Architect]]，现统一为小写 slug）；Entity 仅出现 1 次，不足独立建页阈值，通过 Sources 页面 Key Entities 建立链接 + +## [2026-04-25] ingest | Terminal Integration Specialist +- Source file: Agent/agency-agents/spatial-computing/terminal-integration-specialist.md +- Status: ✅ 成功摄入 +- Summary: Terminal Integration Specialist——专注于终端仿真、文本渲染优化和 SwiftTerm 集成的 Agent，服务于现代 Swift 应用程序（iOS/macOS/visionOS）。核心能力：VT100/xterm ANSI 转义序列完整支持、SwiftTerm 库集成、Core Graphics 文本渲染优化、SSH I/O 桥接（SwiftNIO SSH/NMSSH）、无障碍支持（VoiceOver/动态类型）。 +- Concepts created: [[VT100/xterm Standards]], [[SwiftTerm]], [[Core Graphics Optimization]], [[SSH I/O Bridging]], [[Scrollback Buffer]], [[Accessibility Integration]] +- Contradictions detected: 无明显内容冲突；该 Agent 专注于 Apple 平台和 SwiftTerm，与通用终端解决方案不在同一问题域 +- Source page: wiki/sources/terminal-integration-specialist.md +- Notes: 相关页面已建立连接：[[visionOS Spatial Engineer]] / [[macOS Spatial Metal Engineer]] / [[XR Interface Architect]] 均依赖终端集成能力；Entity 层面 SwiftTerm/SwiftNIO SSH/NMSSH/Core Graphics/Core Text 仅出现 1 次，不足独立建页阈值，通过 Sources 页面的 Key Entities 部分建立链接 + +## [2026-04-25] ingest | XR Immersive Developer Agent Personality +- Source file: Agent/agency-agents/spatial-computing/xr-immersive-developer.md +- Status: ✅ 成功摄入 +- Summary: XR Immersive Developer Agent——WebXR 沉浸式开发专家，基于 A-Frame/Three.js/Babylon.js 构建跨平台浏览器 AR/VR/XR 体验。核心能力：WebXR Device API 全套沉浸式支持（hand tracking / pinch / gaze / controller）、raycasting / hit testing / 实时物理交互、LOD / occlusion culling / shader tuning 性能优化、跨设备兼容层（Meta Quest / Vision Pro / HoloLens / mobile AR）。典型交付物：VR 训练模拟器、AR 可视化界面、空间界面。 +- Concepts created: [[Spatial-Computing]], [[WebXR]], [[Hand-Tracking]] +- Contradictions detected: 与 [[XR-Cockpit-Interaction-Specialist]] 在运动自由度设计上存在张力——后者强调固定视角约束（降低运动病），前者倾向开放空间沉浸体验；冲突点已记录于 overview.md 第 52 条及 [[xr-cockpit-interaction-specialist]] 来源页 Contradictions 节 +- Source page: wiki/sources/xr-immersive-developer.md +- Notes: Concept 页面 Spatial-Computing/WebXR/Hand-Tracking 已创建并添加到 index.md；overview.md 新增 xr-immersive-developer 独立段落（位于 Paid Media 部门之前）；Entity 层面，Meta Quest/Vision Pro/HoloLens/Mobile-AR 仅出现 1-2 次，不足独立建页阈值，通过 Sources 页面的 Key Entities 部分建立链接 + +## [2026-04-25] ingest | Sales Engineer Agent +- Source file: Agent/agency-agents/sales/sales-engineer.md +- Status: ✅ 成功摄入 +- Summary: Sales Engineer Agent——售前工程师 Agent，专注于在 B2B 技术评估中赢得技术决策。核心理念：技术决策先于商业合同，售前工程师必须将每一次技术对话连接到业务成果。核心能力：Demo Engineering（以影响力为导向的演示设计）+ POC Scoping（严格限定的概念验证）+ FIA Framework（Fact-Impact-Act 竞争定位）+ 技术异议解码 + 评估笔记维护。成功指标：技术赢率 70%+，POC 转化率 80%+，演示到下一步行动率 90%+，中位数 18 天技术决策。 +- Concepts created: [[Demo-Engineering]], [[POC-Scoping]], [[FIA-Framework]], [[Technical-Objection-Handling]], [[Aha-Moment]] +- Contradictions detected: 与 [[Sales Discovery Coach Agent]] 在技术发现阶段参与深度上存在张力——前者主张售前主导技术发现，后者主张销售发现以业务语言建立信任，已记录于 overview.md Conflict Areas 第 6 条 +- Source page: wiki/sources/sales-engineer.md +- Notes: 5 个新 Concept 页面已创建；overview.md 新增 sales-engineer 独立段落；index.md 新增 Sales Engineer Agent 条目；Conflict Areas 新增第 6 条；Entity 层面，Sales Engineer 与同团队其他 Agent 均仅出现 1-2 次，不足独立 Entity 建页阈值，已通过 Sources 页面的 Key Entities 部分建立链接 + +## [2026-04-25] ingest | Pipeline Analyst Agent +- Source file: Agent/agency-agents/sales/sales-pipeline-analyst.md +- Status: ✅ 成功摄入 +- Summary: Pipeline Analyst Agent——Revenue Operations 领域的 Pipeline 健康诊断与收入预测 AI Agent。核心框架：Pipeline Velocity =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度；质量调整覆盖度（高质量少量 Pipeline 优于大量低质量 Pipeline）；MEDDPICC Deal 健康评分（资格深度 + 互动强度 + 进展速度三维度 0-36 分）；多信号预测模型（历史转化 + Velocity 加权 + 互动调整 + 季节性 + AI 模式匹配）。预测输出 Commit（>90%）/Best Case（>60%）/Upside（<60%）三档。 +- Concepts created: [[MEDDPICC]], [[PipelineVelocity]], [[DealHealthScoring]], [[QualityAdjustedCoverage]] +- Contradictions detected: sales-coach.md 描述 MEDDPICC 为"六个维度"，正确为八个维度，已修正 +- Source page: wiki/sources/sales-pipeline-analyst.md +- Notes: Entity 层面，Pipeline Analyst 与 Sales Deal Strategist / Sales Account Strategist / Sales Coach 存在依赖关系，待相关 Source 页面完善后可进一步深化链接 + ## [2026-04-25] ingest | Outbound Strategist Agent - Source file: Agent/agency-agents/sales/sales-outbound-strategist.md - Status: ✅ 成功摄入 @@ -2833,3 +2879,21 @@ - Entities linked: [[JohnWilliams]], [[TheAgency]] - Source page: wiki/sources/paid-media-tracking-specialist.md - Notes: 该 Agent 为其他所有 Paid Media Agent 提供数据基础设施；与 paid-media-creative-strategist/paid-social-strategist/ppc-strategist/programmatic-buyer/search-query-analyst/auditor 均存在 depends_on 关系（协同关系已记录于 Connections）；index.md 已插入于 paid-media-programmatic-buyer 之后；Concepts 均为工具/框架类概念，当前仅出现 1 次，不足独立建页阈值，以 wikilink 形式记录于 Source page + +## [2026-04-25] ingest | XR Cockpit Interaction Specialist Agent +- Source file: Agent/agency-agents/spatial-computing/xr-cockpit-interaction-specialist.md +- Status: ✅ 成功摄入 +- Summary: XR Cockpit Interaction Specialist Agent——XR 座舱交互专家 Agent，专注于设计和实现沉浸式座舱式交互环境。核心理念：固定视角（fixed-perspective）+ 高存在感交互区（high-presence interaction zones），将真实感与用户舒适度结合。核心设计原则：约束驱动控制机制（constraint-driven control mechanics）通过 3D meshes 和输入约束将控制物理化，消除自由漂浮运动；座舱人体工学对齐自然眼-手-头协调流动；多模态交互集成（手势/语音/注视/物理道具）；固定视角设计降低运动病阈值。典型应用：模拟指挥中心、航天器座舱、XR 载具界面、训练模拟器。核心工具：A-Frame / Three.js 原型开发。 +- Concepts created: [[Constraint-Driven-Control-Mechanics]], [[Cockpit-Ergonomics]], [[Motion-Sickness-Threshold]], [[Spatial-Computing]] +- Entities linked: [[XR-Interface-Architect]], [[XR-Immersive-Developer]], [[Terminal-Integration-Specialist]] +- Source page: wiki/sources/xr-cockpit-interaction-specialist.md +- Notes: 4 个新 Concept 页面已创建；overview.md 新增 xr-cockpit-interaction-specialist 独立段落；index.md 修复 "source missing" 条目；Entity 层面，XR-Interface-Architect / XR-Immersive-Developer / Terminal-Integration-Specialist 在源文档中提及但尚未建立独立 Entity 页面，当前以 wikilink 形式记录于 Sources 页面；与 [[XR-Immersive-Developer]] 在运动自由度上存在设计张力（固定约束 vs 开放沉浸），已记录于 Contradictions 部分 + +## [2026-04-25] ingest | macOS Spatial/Metal Engineer Agent Personality +- Source file: Agent/agency-agents/spatial-computing/macos-spatial-metal-engineer.md +- Status: ✅ 成功摄入 +- Summary: macOS Spatial/Metal Engineer Agent——Apple 平台专用 Metal 渲染与空间计算专家 Agent，专注于 Swift + Metal 高性能 3D 渲染和 visionOS 空间计算体验。核心能力：实例化 Metal 渲染（10k-100k 节点 @ 90fps 立体渲染）；RemoteImmersiveSpace + LayerRenderer 实现 macOS → Vision Pro 帧流；Metal Compute Shader GPU 力导向图布局；注视（Gaze）+ 捏合（Pinch）空间交互。性能约束：GPU 利用率 < 80%、每帧 < 100 draw calls、内存 < 1GB。 +- Concepts linked: [[Instanced Rendering]], [[RemoteImmersiveSpace]], [[Compositor Services]], [[LayerRenderer]], [[Force-Directed Graph Layout]], [[Metal System Trace]], [[Stereoscopic Rendering]], [[GPU-Driven Rendering]], [[Triple Buffering]], [[Frustum Culling & LOD]] +- Entities linked: [[Apple]], [[Vision Pro]], [[Metal]], [[Xcode Instruments]], [[RealityKit]], [[ARKit]] +- Source page: wiki/sources/macos-spatial-metal-engineer.md +- Notes: Entity 层面 Apple/Vision Pro/Metal/Xcode Instruments/RealityKit/ARKit 在源文档中提及但均不足独立建页阈值，通过 Sources 页面的 Key Entities 部分建立链接；与 [[visionos-spatial-engineer]] 存在职责重叠（Vision Pro 开发），已记录于 Contradictions 部分——前者侧重 macOS 渲染侧 + Vision Pro 流式输出，后者倾向 visionOS 原生交互开发，两者可协同；与 [[xr-immersive-developer]] 互补——浏览器端 WebXR vs Apple 原生 Metal 渲染管线，共同构成 XR 产品矩阵 diff --git a/wiki/overview.md b/wiki/overview.md index 41214c31..14f8754d 100644 --- a/wiki/overview.md +++ b/wiki/overview.md @@ -49,6 +49,14 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents) **[[multi-agent-system-reliability]]**（Alex Ewerlöf）：多智能体系统可靠性的架构模式理论——反对拟人化LLM，主张将LLM视为分布式系统中不可靠的组件。核心4模式：[[Hierarchy-Agent-Pattern]]（主管→工作→验证链）、[[Consensus-Voting-Pattern]]（N个LLM多数票消除幻觉）、[[Adversarial-Debate-Pattern]]（Generator→Critic→Judge对抗辩论）、[[Knock-out-Pattern]]（适者生存淘汰制）。核心洞察：不应要求模型"小心"，而应**强制**其正确——通过架构约束而非提示词约束。与 [[Designing for Agentic AI]] 互补（架构 vs 用户体验），与 [[Recursive Self-Optimization]] 共享自引用结构思想。与 [[Genetic-Algorithm]]（遗传算法）有关联——Knock-out/Tree of Thoughts 是 GA 的精简实现。 +**[[xr-interface-architect]]**（XR Interface Architect）：XR 空间界面架构师 Agent——The Agency Spatial Computing 部门的 UX/UI 设计专家，专注于为 AR/VR/XR 沉浸式环境创建直觉化、舒适且可发现的界面。核心方法：HUD / 浮动菜单 / 交互区域设计，支持直接触摸、注视+捏合、控制器和手势四种输入模型；基于人体工程学约束进行 UI 放置，减少晕动症；构建座舱/仪表盘/可穿戴界面布局模板；运行可用性验证实验（舒适度和学习性）。人格特质：**Human-centered, layout-conscious, sensory-aware, research-driven**。与 [[xr-immersive-developer]] 和 [[xr-cockpit-interaction-specialist]] 同属 Spatial Computing 部门，三者共同构建完整的 XR 产品交互基础设施。 + +**[[xr-cockpit-interaction-specialist]]**（XR Cockpit Interaction Specialist）：XR 座舱交互专家 Agent——The Agency Spatial Computing 部门的沉浸式座舱式交互设计专家，专注于设计和实现固定视角、高存在感的座舱交互环境。核心设计原则：约束驱动控制机制（constraint-driven control mechanics）消除自由漂浮运动，通过 3D meshes 和输入约束将控制物理化；座舱人体工学对齐自然的眼-手-头协调流动；多模态交互集成（手势/语音/注视/物理道具）；固定视角设计降低运动病阈值。典型应用场景：模拟指挥中心、航天器座舱、XR 载具界面、训练模拟器。核心工具：A-Frame / Three.js 原型开发。与 [[xr-interface-architect]] 存在层级关系（前者提供座舱交互基础能力，后者构建界面）；与 [[xr-immersive-developer]] 在运动自由度设计上存在张力——前者强调固定视角约束以降低眩晕，后者倾向开放空间沉浸体验。属 [[Spatial-Computing]] 概念在座舱场景的具体应用，为 The Agency 的 XR 产品矩阵提供交互基础设施。 + +**[[xr-immersive-developer]]**（XR Immersive Developer）：XR 沉浸式开发专家 Agent——The Agency Spatial Computing 部门的 WebXR 前端工程师，专注于在浏览器环境下构建跨平台高性能 AR/VR/XR 体验。核心栈：A-Frame / Three.js / Babylon.js；核心能力：WebXR Device API 全套沉浸式支持（hand tracking / pinch / gaze / controller input）、raycasting / hit testing / 实时物理交互、LOD 系统 / occlusion culling / shader tuning 性能优化、跨设备兼容层（Meta Quest / Vision Pro / HoloLens / mobile AR）、模块化组件驱动设计及优雅降级。典型交付物：VR 训练模拟器、AR 可视化界面、空间界面。核心工具：A-Frame / Three.js 原型开发。与 [[XR-Interface-Architect]]（界面架构）和 [[XR-Cockpit-Interaction-Specialist]]（座舱交互）同属 Spatial Computing 部门，共同构建 XR 产品矩阵。与 [[XR-Cockpit-Interaction-Specialist]] 在运动自由度设计上存在张力——后者强调固定视角约束以降低运动病，前者倾向开放空间沉浸体验。属 [[Spatial-Computing]] 概念在浏览器前端场景的具体实现。 + +**[[macos-spatial-metal-engineer]]**（macOS Spatial/Metal Engineer）：Apple 平台专用 Metal 渲染与空间计算 Agent——专注于 Swift + Metal 的高性能 3D 渲染系统和 visionOS 空间计算体验。核心能力：实例化 Metal 渲染（Instanced Rendering）驱动 10k-100k 节点图数据，目标 90fps 立体渲染；通过 RemoteImmersiveSpace 和 LayerRenderer（stereo 模式、RGBA16Float + Depth32Float）实现 macOS 到 Vision Pro 的帧流传输；Metal Compute Shader 执行 GPU 并行力导向图物理模拟（排斥力 + 吸引力 + 阻尼）；注视（Gaze）+ 捏合（Pinch）空间交互与 raycast hit testing。性能约束：GPU 利用率 < 80%、每帧 < 100 draw calls、内存 < 1GB。与 [[xr-immersive-developer]] 互补——前者专注浏览器端 WebXR，后者专注 Apple 原生 Metal 渲染管线；与 [[visionos-spatial-engineer]] 存在职责张力——后者倾向 visionOS 原生开发，前者侧重 macOS 渲染侧 + Vision Pro 流式输出，两者协同构成完整的 Apple 空间计算平台能力。属 [[Spatial-Computing]] 概念在 Apple 原生平台场景的具体实现。 + ### The Agency — Paid Media 部门 The Agency 的 Paid Media 部门专注于企业级付费媒体策略与运营，涵盖 Google Ads、Microsoft Advertising、Amazon Ads 三大核心平台。 @@ -645,26 +653,34 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]] **[[sales-deal-strategist]]**（Deal Strategist Agent）：高级deal策略师与管线架构师，将严谨的资质方法论应用于复杂B2B销售周期——坚信每个deal都是战略问题而非关系练习，"如果资质缺口没有尽早识别，失败就已经锁定了，只是你还没发现"。核心能力：**MEDDPICC资质评估**（八维度评分，每维度5分，满分40；全面推行MEDDPICC的组织赢率提升18%、deal规模扩大24%）+ **竞争定位**（Winning/Battling/Losing三区分析 + 地雷问题布局）+ **Challenger商业教学法**（六步序列：Warmer → Reframe → Rational Drowning → Emotional Impact → A New Way → Your Solution）+ **交易检查方法论**（系统探测风险信号：单线程/无紧迫事件/Champion不开放EB通道/决策标准完美匹配竞争对手）。核心原则：预测准确率Commit deals关闭率85%+；Qualified Pipeline（28/40+）赢率35%+；永远不做单线程账户；每条资质缺口必须附带具体下一步、责任人、和截止日期。与 [[sales-discovery-coach]] 协同——后者提供买方情境输入（发现阶段），前者构建交易策略（评估+定位+计划）；与 [[sales-proposal-strategist]] 互补——Deal Strategist提供结构化deal分析和竞争定位，Proposal Strategist将其转化为说服性叙事，共同构成"发现→赢单策略→提案叙事"完整销售闭环。 +**[[sales-pipeline-analyst]]**（Pipeline Analyst Agent）：Revenue Operations 领域的 Pipeline 健康诊断与收入预测 AI Agent，将 CRM 数据转化为可执行的 Pipeline 洞察——坚信"每个 Pipeline 评估都应至少发现一个需要立即干预的 Deal"。核心框架：**Pipeline Velocity** =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度，四个变量均为独立诊断杠杆；**质量调整覆盖度**（$5M 含 20 个陈旧 Deal 的 Pipeline 价值低于 $2M 含 8 个活跃 Deal 的 Pipeline）；**MEDDPICC Deal 健康评分**（资格深度 + 互动强度 + 进展速度三维度 0-36 分综合评分）；**多信号预测模型**（历史转化 + Velocity 加权 + 互动调整 + 季节性模式 + AI 模式匹配）。预测输出 Commit（>90%）/Best Case（>60%）/Upside（<60%）三档而非单一数字。关键原则：晚期阶段 MEDDPICC 字段<5/8 的 Deal 是预测失误的主要来源；单线程 + 无 EB 接触 + 20+ 天无会议 = 与上一季度 Closed-Lost 队列相同模式；30 天未更新的 Pipeline 应被标记审查；CRM 显示的 $12M Pipeline 调整后可能只有 $4.8M 有效。与 [[sales-deal-strategist]] 协同——后者关注单个 Deal 策略，前者提供全 Pipeline 层面的诊断和预测；与 [[sales-coach]] 共享 MEDDPICC 框架，但前者用于 Deal 质量评估，后者用于代表能力辅导。 + +**[[sales-engineer]]**（Sales Engineer Agent）：售前工程师 Agent，专注于在 B2B 技术评估中赢得技术决策——核心理念：技术决策先于商业合同，售前工程师必须将每一次技术对话连接到业务成果，而非单纯展示功能。核心能力：**Demo Engineering**（以影响力为导向的演示设计：先量化问题→展示结果→逆向讲解→证明收尾，以 [[AhaMoment]] 为核心成功标准）+ **POC Scoping**（严格限定的概念验证：成功标准明确写在开始前，2-3 周硬性时间线，中期检查点，防止范围蔓延）+ **FIA Framework**（Fact-Impact-Act 竞争定位框架，保持事实基础和可操作性，永远不攻击竞品）+ **技术异议解码**（识别"是否支持 SSO？"背后的真实关切是"能否通过安全审查"，从根源回应而非表面处理）+ **评估笔记维护**（结构化记录每个活跃交易的技术环境、决策者、竞争态势和演示策略）。成功指标：技术赢率 70%+，POC 转化率 80%+，演示到下一步行动率 90%+，中位数 18 天技术决策。与 [[sales-discovery-coach]] 在发现阶段技术深度参与度上存在张力——前者主张售前主导技术发现，后者主张销售发现以业务语言建立信任；与 [[sales-deal-strategist]] 共享竞争定位和 Winning/Battling/Losing 三区分析，但前者专注于技术评估层，后者覆盖全周期交易策略。属 The Agency Sales 团队完整销售闭环中的技术评估支柱。 + ## Conflict Areas 1. **Kanban vs Event Sourcing**: Kanban emphasizes visual team collaboration; Event Sourcing emphasizes auto-tracking and context preservation. **[[Project State Management]]**（事件驱动看板替代方案）vs 传统 PM 工具。核心差异：手动拖拽 vs 自然语言输入；静态快照 vs 全历史保留；无上下文 vs 完整决策链。**[[Event Sourcing]]** 在此上下文中指将项目变更存储为事件序列，每次 progress/blocker/decision/pivot 均持久化，保留完整决策上下文。 -2. **Kuaishou vs Douyin**: Kuaishou emphasizes authenticity and balanced algorithm; Douyin emphasizes polished content and central recommendation. Same country, opposite platform strategies. +2. **MEDDPICC 维度数量**：MEDDPICC 有 8 个维度（Metrics/Economic Buyer/Decision Criteria/Decision Process/Paper Process/Implicated Pain/Champion/Competition），但早期摄入的 [[sales-coach]] 描述为"六个维度"。已于本次摄入中修正为八维度，后续应避免再次引用旧的六维度描述。 -3. **Micro-Enterprise vs Portage Salarial**: Micro-enterprise yields higher net income but lacks social protections; Portage Salarial costs more but includes unemployment insurance, pension, mutuelle. Financial trade-off vs social safety net. +3. **Kuaishou vs Douyin**: Kuaishou emphasizes authenticity and balanced algorithm; Douyin emphasizes polished content and central recommendation. Same country, opposite platform strategies. -4. **CI/CD Build Output**: SECURITY.md says build output is always closed; GitHub Actions best practice says certain generated files should be committed for reproducibility. Reproducibility vs cleanliness tension. +4. **Micro-Enterprise vs Portage Salarial**: Micro-enterprise yields higher net income but lacks social protections; Portage Salarial costs more but includes unemployment insurance, pension, mutuelle. Financial trade-off vs social safety net. -5. **路由器科学上网 vs VPS科学上网 vs NAS科学上网 vs Server终端代理**：四层方案各有适用场景。[[网件RAX50刷梅林固件与科学上网]] 路由网关方案（[[MerlinClash插件]]）→ 全屋透明代理，无需客户端配置；[[3X-UI Xray on BandwagonVPS]] VPS服务端方案（[[3X-UI]] + [[Xray]]）→ 集中式代理节点，可扩展；[[群晖NAS科学上网]] NAS 代理方案（V2RayA 透明代理）→ 覆盖 NAS 本身及容器；[[ubuntu-server科学上网]] Server 终端代理方案（[[ProxyChains]] + [[Git 全局代理]] + [[Docker Daemon Proxy]]）→ 仅覆盖该 Server 本身。最佳实践：路由器作为主网关（[[MerlinClash插件]]），VPS作为代理节点池（订阅机制），NAS 按需透明代理，Server 终端按工具单独配置。**额外洞察**：在群晖 DSM 7.x 和 Ubuntu Server 中，V2RayA/透明代理不一定对 Docker Daemon 生效，**显式配置 Docker Daemon Proxy 环境变量**（systemd drop-in 文件）比依赖透明代理更可靠。 +5. **CI/CD Build Output**: SECURITY.md says build output is always closed; GitHub Actions best practice says certain generated files should be committed for reproducibility. Reproducibility vs cleanliness tension. -6. **Prometheus 监控 vs OpenTelemetry**：Prometheus 生态成熟、部署简单，适合家庭服务器和小型集群；OpenTelemetry 是云原生可观测性新标准（metrics/traces/logs 三合一），长期可考虑迁移路径但学习成本高。[[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] vs [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]。 +6. **Sales Engineer vs Sales Discovery Coach（技术发现参与深度）**：Sales Engineer Agent 主张售前工程师应在技术发现阶段主导参与，结构化挖掘架构、集成、安全约束和真实技术决策标准；Sales Discovery Coach Agent 主张销售发现应以业务语言建立信任，深度技术探索由专门时机负责。协调方向：在发现阶段早期以业务语言建立信任，进入评估阶段后切换为技术深度模式。详见 [[sales-engineer]] Contradictions 部分。 -7. **Netdata vs Prometheus**：Netdata 开箱即用适合实时短期诊断（默认 19999 端口），Prometheus + Grafana 适合长期存储和趋势分析。两者可互补使用：Netdata 做快速排查，Prometheus 做 SLA 报表和历史分析。 +7. **路由器科学上网 vs VPS科学上网 vs NAS科学上网 vs Server终端代理**：四层方案各有适用场景。[[网件RAX50刷梅林固件与科学上网]] 路由网关方案（[[MerlinClash插件]]）→ 全屋透明代理，无需客户端配置；[[3X-UI Xray on BandwagonVPS]] VPS服务端方案（[[3X-UI]] + [[Xray]]）→ 集中式代理节点，可扩展；[[群晖NAS科学上网]] NAS 代理方案（V2RayA 透明代理）→ 覆盖 NAS 本身及容器；[[ubuntu-server科学上网]] Server 终端代理方案（[[ProxyChains]] + [[Git 全局代理]] + [[Docker Daemon Proxy]]）→ 仅覆盖该 Server 本身。最佳实践：路由器作为主网关（[[MerlinClash插件]]），VPS作为代理节点池（订阅机制），NAS 按需透明代理，Server 终端按工具单独配置。**额外洞察**：在群晖 DSM 7.x 和 Ubuntu Server 中，V2RayA/透明代理不一定对 Docker Daemon 生效，**显式配置 Docker Daemon Proxy 环境变量**（systemd drop-in 文件）比依赖透明代理更可靠。 -8. **macOS vs Linux 睡眠管理**：macOS 使用 `pmset` 命令配置电源管理（sleep/displaysleep/standby/hibernatemode），Linux/Ubuntu 使用 `systemd-logind` 的 `HandleLidSwitch=ignore` 配置。两者目标相同（防止服务器睡眠），但工具链完全不同，不可互换但互为参考。[[mac-mini-服务器配置-防止自动锁屏与睡眠]] vs [[ubuntu禁用合盖休眠]]。 +8. **Prometheus 监控 vs OpenTelemetry**：Prometheus 生态成熟、部署简单，适合家庭服务器和小型集群；OpenTelemetry 是云原生可观测性新标准（metrics/traces/logs 三合一），长期可考虑迁移路径但学习成本高。[[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] vs [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]。 -9. **数据库备份方案**：pg_dump 逻辑备份 vs rsync 文件级备份。pg_dump 是热备份标准（零停机、跨平台迁移能力强），但不能备份运行中数据库的物理文件目录；rsync 适合 Docker 卷备份但需确保数据库一致状态。[[MinIO + Zipline 图床安装]] 使用 pg_dump 逻辑备份 PostgreSQL + Hyper Backup 文件备份 MinIO 目录，两者互补。 +9. **Netdata vs Prometheus**：Netdata 开箱即用适合实时短期诊断（默认 19999 端口），Prometheus + Grafana 适合长期存储和趋势分析。两者可互补使用：Netdata 做快速排查，Prometheus 做 SLA 报表和历史分析。 -10. **SuperCall 沙盒 Persona vs 通用语音 Agent**：[[event-guest-confirmation]] 中使用的 [[SuperCall]] 强调独立沙盒设计——AI persona 只持有预设的 persona name、goal、opening line，无法访问外部系统；[[phone-based-personal-assistant]] 侧重通用个人助手场景，需要访问更多上下文。**[[Sandboxed Persona]]** 适用于确认类单一任务（安全、无注入风险）；通用语音 Agent 适用于需要跨系统协调的复杂助手场景。 +10. **macOS vs Linux 睡眠管理**：macOS 使用 `pmset` 命令配置电源管理（sleep/displaysleep/standby/hibernatemode），Linux/Ubuntu 使用 `systemd-logind` 的 `HandleLidSwitch=ignore` 配置。两者目标相同（防止服务器睡眠），但工具链完全不同，不可互换但互为参考。[[mac-mini-服务器配置-防止自动锁屏与睡眠]] vs [[ubuntu禁用合盖休眠]]。 -11. **Agent 去电通知 vs Agent 来电接收**：[[phone-call-notifications]] 中 Agent 主动向用户拨打电话通知（Agent → User），通话由 Agent 触发，用户是被动接收方；[[phone-based-personal-assistant]] 中用户主动呼叫 Agent（User → Agent），Agent 接听并提供助理服务。两者方向相反但互补——前者用于紧急告警、定时简报、重要事件通知，后者用于随时咨询、查询、执行任务。共同构成完整语音双向通信能力。 +11. **数据库备份方案**：pg_dump 逻辑备份 vs rsync 文件级备份。pg_dump 是热备份标准（零停机、跨平台迁移能力强），但不能备份运行中数据库的物理文件目录；rsync 适合 Docker 卷备份但需确保数据库一致状态。[[MinIO + Zipline 图床安装]] 使用 pg_dump 逻辑备份 PostgreSQL + Hyper Backup 文件备份 MinIO 目录，两者互补。 + +12. **SuperCall 沙盒 Persona vs 通用语音 Agent**：[[event-guest-confirmation]] 中使用的 [[SuperCall]] 强调独立沙盒设计——AI persona 只持有预设的 persona name、goal、opening line，无法访问外部系统；[[phone-based-personal-assistant]] 侧重通用个人助手场景，需要访问更多上下文。**[[Sandboxed Persona]]** 适用于确认类单一任务（安全、无注入风险）；通用语音 Agent 适用于需要跨系统协调的复杂助手场景。 + +13. **Agent 去电通知 vs Agent 来电接收**：[[phone-call-notifications]] 中 Agent 主动向用户拨打电话通知（Agent → User），通话由 Agent 触发，用户是被动接收方；[[phone-based-personal-assistant]] 中用户主动呼叫 Agent（User → Agent），Agent 接听并提供助理服务。两者方向相反但互补——前者用于紧急告警、定时简报、重要事件通知，后者用于随时咨询、查询、执行任务。共同构成完整语音双向通信能力。 diff --git a/wiki/sources/macos-spatial-metal-engineer.md b/wiki/sources/macos-spatial-metal-engineer.md new file mode 100644 index 00000000..8aefe300 --- /dev/null +++ b/wiki/sources/macos-spatial-metal-engineer.md @@ -0,0 +1,62 @@ +--- +title: "macOS Spatial/Metal Engineer Agent Personality" +type: source +tags: [agent, apple, metal, spatial-computing, visionos, xr] +date: 2026-04-25 +--- + +## Source File +- [[raw/Agent/agency-agents/spatial-computing/macos-spatial-metal-engineer.md]] + +## Summary（用中文描述） +- 核心主题：macOS Spatial/Metal Engineer Agent 的人格定义——一个专注于 Swift + Metal 渲染的空间计算专家 Agent，负责构建 macOS 和 Vision Pro 上的高性能 3D 可视化系统 +- 问题域：如何在 Apple 平台上实现大规模图数据的高性能 GPU 渲染，并将渲染流通过 Compositor Services 传输到 Vision Pro 进行沉浸式空间计算体验 +- 方法/机制：使用实例化 Metal 渲染（Instanced Rendering）驱动 10k-100k 节点；通过 RemoteImmersiveSpace 和 LayerRenderer 实现 Vision Pro 立体帧流；用 Metal Compute Shader 实现 GPU 物理力导向图布局 +- 结论/价值：定义了一个完整的 Apple 平台空间计算 Agent 技术栈，从渲染管线到手势交互到性能调优，覆盖了 visionOS/macOS 跨平台沉浸式开发的核心路径 + +## Key Claims（用中文描述） +- Agent 通过实例化 Metal 渲染，可在 90fps 立体渲染下驱动 25k 节点图数据 +- Agent 使用 RemoteImmersiveSpace 实现 macOS 与 Vision Pro 的全沉浸式代码可视化连接 +- Agent 通过 LayerRenderer 的 stereo 配置（RGBA16Float + Depth32Float）实现高质量立体帧流 +- Agent 利用 Metal Compute Shader 执行 GPU 并行力导向图布局，避免 CPU 瓶颈 +- Agent 将注视（Gaze）追踪 + 捏合（Pinch）手势识别作为主要空间交互方式 + +## Key Quotes +> "Never drop below 90fps in stereoscopic rendering" — Metal 渲染硬性性能要求 +> "Use instanced drawing for massive node counts" — 核心渲染优化策略 +> "Stream stereo frames to Vision Pro via Compositor Services" — 跨设备渲染架构目标 +> "Implement proper depth ordering for stereoscopic rendering" — Vision Pro 立体渲染规范 + +## Key Concepts +- [[Instanced Rendering]]：通过单次 draw call 批量渲染大量节点，每个节点含 position/color/scale/symbolId 属性 +- [[RemoteImmersiveSpace]]：macOS 与 Vision Pro 之间的全沉浸式空间连接协议 +- [[Compositor Services]]：提供 LayerRenderer 用于生成和提交立体帧到 Vision Pro +- [[LayerRenderer]]：配置 stereo 模式、RGBA16Float 颜色格式和 Depth32Float 深度格式的渲染层 +- [[Force-Directed Graph Layout]]：在 Metal Compute Shader 中实现的力导向图物理模拟（排斥力 + 吸引力 + 阻尼） +- [[Metal System Trace]]：Xcode Instruments 工具，用于分析 Metal 帧时间和 GPU 利用率 +- [[Stereoscopic Rendering]]：双眼立体渲染，需维护正确的深度顺序和 vergence-accommodation 限制 +- [[GPU-Driven Rendering]]：通过 Indirect Command Buffers 实现 GPU 自主驱动的渲染管线 +- [[Triple Buffering]]：三缓冲策略保证 CPU-GPU 数据传输与渲染流水线的平滑衔接 +- [[Frustum Culling & LOD]]：视锥裁剪和层级细节优化，用于大规模图数据的性能保障 + +## Key Entities +- [[Apple]]：平台生态——提供 Metal、visionOS、CompositorServices 等核心框架 +- [[Vision Pro]]：目标设备——通过 RemoteImmersiveSpace 接收来自 macOS 的立体渲染流 +- [[Metal]]：底层图形 API——支持 instanced rendering、compute shaders、geometry shaders +- [[Xcode Instruments]]：性能分析工具——Metal System Trace 用于帧时间和 GPU 利用率分析 +- [[RealityKit]]：空间锚点支持——用于 Vision Pro 空间锚点的持久化管理 +- [[ARKit]]：环境映射——结合 ARKit 实现环境光照和空间理解 + +## Connections +- [[macos-spatial-metal-engineer]] ← builds ← [[MetalGraphRenderer]]（核心渲染组件） +- [[macos-spatial-metal-engineer]] ← integrates_with ← [[VisionProCompositor]]（Vision Pro 流式连接） +- [[macos-spatial-metal-engineer]] ← uses ← [[ForceDirectedGraphLayout]]（GPU 物理模拟） +- [[xr-immersive-developer]] ← shares_architecture_with ← [[macos-spatial-metal-engineer]]（XR 开发领域重叠） +- [[visionos-spatial-engineer]] ← extends ← [[macos-spatial-metal-engineer]]（visionOS 专用扩展） + +## Contradictions +- 与 [[visionos-spatial-engineer]] 可能存在职责重叠： + - 冲突点：两者都涉及 Vision Pro 开发，但侧重点不同 + - 当前观点：macOS Spatial/Metal Engineer 专注 macOS 侧渲染管线 + Vision Pro 流式输出 + - 对方观点：visionOS Spatial Engineer 专注 visionOS 原生空间交互开发 + - 协调：两者可协同——macOS 侧负责高性能渲染，visionOS 侧负责原生交互体验 diff --git a/wiki/sources/paid-media-creative-strategist.md b/wiki/sources/paid-media-creative-strategist.md new file mode 100644 index 00000000..618229a5 --- /dev/null +++ b/wiki/sources/paid-media-creative-strategist.md @@ -0,0 +1,63 @@ +--- +title: "Paid Media Ad Creative Strategist Agent" +type: source +tags: ["paid-media", "creative", "advertising", "google-ads", "meta-ads", "ppc", "agent-persona"] +date: 2026-04-25 +--- + +## Source File +- [[Agent/agency-agents/paid-media/paid-media-creative-strategist.md]] + +## Summary（用中文描述） +- 核心主题：付费媒体广告创意策略 Agent，专注于 Google、Meta、Microsoft 及程序化平台的全渠道广告文案创作、响应式搜索广告（RSA）架构设计和系统性创意测试框架。 +- 问题域：如何在算法控制竞价、预算和定向的自动化竞价环境中，通过创意这一唯一可控变量实现效果最大化；创意疲劳监测与快速迭代难题。 +- 方法/机制：15-headline RSA 策略设计（全品牌/利益/功能/CTA/社会证明分类）；Hook-Body-CTA 视频广告结构；资产组（Asset Group）组合策略；A/B 测试框架与统计显著性标准；广告强度评分优化。 +- 结论/价值：创意是自动化竞价环境中最大的可控杠杆，每一条标题、描述、图片和视频都是一个待验证的假设，必须通过系统性测试持续迭代。 + +## Key Claims（用中文描述） +- 在 tCPA/tROAS/Max Conversions 等自动化竞价环境中，创意是广告主唯一实际可控的变量，算法接管了出价、预算和定向。 +- RSA 的 15 条标题和 4 条描述的所有可能组合必须语法和逻辑上都能成立，这是架构设计的核心挑战。 +- 创意疲劳（Creative Fatigue）是效果下降的主因，必须通过 CTR 趋势监测和超优展示阈值识别及时刷新。 +- 广告强度（Ad Strength）90%+ 达到 "Good" 或 "Excellent" 是 RSA 质量基准；Meta 相关性诊断需高于平均或顶级表现。 +- 统计显著性（Statistical Significance）是判定创意胜负的唯一可靠标准，必须在 2-4 周内达到。 + +## Key Quotes +> "Creative is the largest remaining lever in automated bidding environments — when the algorithm controls bids, budget, and targeting, the creative is what you actually control." — 核心价值观阐述 +> "Every headline, description, image, and video is a hypothesis to be tested." — 创意即假设 +> "Always audit existing ad performance before writing new creative. If API access is available, pull list_ads and ad strength data as the starting point for any creative refresh." — 数据优先原则 + +## Key Concepts +- [[ResponsiveSearchAds]]: RSA（响应式搜索广告），Google Ads 核心广告格式，由最多 15 条标题和 4 条描述自由组合，系统自动测试最优搭配。 +- [[PerformanceMax]]: Performance Max 广告系列，Google 全渠道自动化广告，创意资产组（Asset Group）是核心输入，决定系统学习信号质量。 +- [[AssetGroup]]: 资产组，Performance Max 的创意容器，由文本资产、图片、视频、Logo 等组成，决定广告主题表达质量。 +- [[AdStrength]]: 广告强度评分，Google 衡量 RSA 或 PMax 创意质量的指标，90%+ "Good/Excellent" 是基准目标。 +- [[CreativeFatigue]]: 创意疲劳，广告在超优展示阈值后点击率自然下降的现象，需通过定期刷新和新鲜创意对抗。 +- [[HookBodyCTA]]: Hook-Body-CTA 结构，视频广告的叙事框架——钩子（0-3秒）吸引注意，主体传递价值，号召行动促进转化。 +- [[ABTesting]]: A/B 测试框架，创意验证的标准方法，通过统计显著性判定胜负，指导规模化应用。 +- [[MessageMatch]]: 消息匹配评分，衡量广告创意与落地页内容一致性的指标，直接影响质量得分和转化率。 +- [[StatisticalSignificance]]: 统计显著性，创意测试的判断标准，确保结果可推广而非随机波动。 +- [[AdExtensions]]: 广告附加信息（Sitelink/Callout/Structured Snippets/Image Extensions 等），扩展广告视觉空间和点击率。 + +## Key Entities +- [[GoogleAds]]: Google Ads 平台，核心投放渠道，提供 RSA、Performance Max、Ad Strength 数据和 Google Ads MCP 工具集成。 +- [[MetaAdsManager]]: Meta（Facebook/Instagram）广告管理平台，支持 Primary Text/Headline/Description 框架和 Relevance Diagnostics。 +- [[MicrosoftAdvertising]]: Microsoft Advertising（Bing/AOL/Yahoo）搜索广告平台，与 Google Ads 并行的 PPC 渠道。 +- [[PerformanceMax]]: Google Performance Max 广告系列，AI 驱动的全渠道投放，Asset Group 质量决定效果上限。 +- [[JohnWilliams]]: Agent 作者（@itallstartedwithaidea），资深付费媒体创意策略师。 + +## Connections +- [[PaidMediaPpcStrategist]] ← coordinates_with ← [[PaidMediaCreativeStrategist]]: PPC 策略师制定活动架构，创意策略师提供素材支撑，两者协同制定 Performance Max 和 Display 投放方案。 +- [[PaidMediaProgrammaticBuyer]] ← depends_on ← [[PaidMediaCreativeStrategist]]: 程序化购买依赖高质量创意资产填充展示和视频广告库存。 +- [[PaidMediaSearchQueryAnalyst]] ← informs ← [[PaidMediaCreativeStrategist]]: 搜索查询分析师提供关键词意图数据，创意策略师据此撰写关键词插入文案。 +- [[PaidMediaTrackingSpecialist]] ← depends_on ← [[PaidMediaCreativeStrategist]]: 追踪专家提供的 CTR/CVR 数据是判断创意胜负的基础。 +- [[PaidMediaAuditor]] ← depends_on ← [[PaidMediaCreativeStrategist]]: 审计师诊断广告效果，创意刷新是优化策略的核心输出之一。 + +## Contradictions +- 与 [[PaidMediaPpcStrategist]] 在"自动化程度"权衡上存在张力： + - 冲突点：PPC 策略师倾向于强调 Smart Bidding 和自动化优化；创意策略师认为创意质量是瓶颈，自动化不能弥补低质量素材。 + - 当前观点：创意是决定性杠杆，即使在自动化竞价环境中也需要人工精心设计的 RSA 组合和 Asset Group 策略。 + - 对方观点：Broad Match + Smart Bidding 组合可以弥补创意不足，系统会自动寻找最优受众-创意搭配。 +- 与 [[PaidMediaProgrammaticBuyer]] 在"创意新鲜度"上存在潜在冲突： + - 冲突点：程序化购买强调规模化和成本效率，倾向于复用已有创意；创意策略师强调创意疲劳必须通过高频迭代对抗。 + - 当前观点：持续创意迭代（每 2 周一次测试）是效果保持的必要条件，低频迭代会导致 CPM 上升和 CTR 下降。 + - 对方观点：程序化购买的受众覆盖足够广泛，可以抵消创意疲劳的影响。 diff --git a/wiki/sources/paid-media-paid-social-strategist.md b/wiki/sources/paid-media-paid-social-strategist.md new file mode 100644 index 00000000..f6ff20cc --- /dev/null +++ b/wiki/sources/paid-media-paid-social-strategist.md @@ -0,0 +1,54 @@ +--- +title: "Paid Social Strategist" +type: source +tags: [] +date: 2026-04-25 +--- + +## Source File +- [[Agent/agency-agents/paid-media/paid-media-paid-social-strategist.md]] + +## Summary（用中文描述） +- 核心主题：跨平台付费社交广告专家 Agent，覆盖 Meta（Facebook/Instagram）、LinkedIn、TikTok、Pinterest、X 和 Snapchat，设计从引流到再营销的全漏斗社交广告项目。 +- 问题域：社交广告的本质是"打断"而非"回答"，如何在各平台原生体验与广告效果之间取得平衡；iOS 隐私政策对追踪归因的冲击；跨平台受众重叠与频次管理难题。 +- 方法/机制：全漏斗结构（引流 → 互动 → 再营销 → 留存）；平台差异化创意策略（UGC 风格适配 TikTok/Meta，专业内容适配 LinkedIn）；受众工程（像素自定义受众、CRM 上传、互动受众）；Conversions API / 服务端事件追踪；SKAdNetwork 应对 iOS 隐私变化。 +- 结论/价值：为每个社交平台构建原生广告体验，而非跨平台复用同一创意；通过跨渠道数据验证增量贡献，避免重复计算转化。 + +## Key Claims（用中文描述） +- 付费社交广告本质上是"打断"用户而非"回答"问题，因此创意和受众策略必须赢得用户注意力。 +- 各平台是独立生态系统（Meta Ads Manager、LinkedIn Campaign Manager、TikTok Ads 各有不同算法机制和用户行为），不应跨平台复用同一套创意。 +- iOS 隐私变化后，SKAdNetwork 和聚合事件测量成为移动归因的核心手段，Conversions API 实施至关重要。 +- 跨渠道预算分配必须基于跨渠道证据（搜索+展示+社交综合数据），避免基于单一渠道数据做预算决策。 + +## Key Quotes +> "Social advertising is fundamentally different from search — you're interrupting, not answering, so the creative and targeting have to earn attention." — 核心哲学阐述 + +> "When cross-channel API data is available, always validate social performance against search and display results before recommending budget increases." — 跨渠道验证原则 + +## Key Concepts +- [[Full-Funnel Campaign Architecture]]：从引流（Prospecting）到留存（Retention）的完整漏斗结构，各阶段受众策略与预算分配各异。 +- [[Custom Audience Engineering]]：基于像素的自定义受众、CRM 名单上传、互动受众（视频观看者、主页互动者、表单开启者）的构建与排除策略。 +- [[Conversions API]]：服务端事件追踪，与平台像素配合绕过浏览器限制，是后 iOS 14 隐私政策的关键归因基础设施。 +- [[Advantage+ Campaigns]]：Meta 的自动化广告系列，利用机器学习优化受众定位和竞价，是 CBO/ABO 架构的重要演进。 +- [[Audience Overlap Analysis]]：跨平台受众重叠分析，防止频次过载，最大化独特触达。 +- [[Incrementality Testing]]：增量测试，验证社交广告是否带来净新增转化，而非蚕食自然搜索流量。 +- [[SKAdNetwork]]：Apple 的隐私化归因框架，替代 IDFA，用于衡量 iOS 应用广告效果。 + +## Key Entities +- [[Meta Ads Manager]]：Facebook/Instagram 广告管理平台，核心工具包括 Advantage+ 购物广告、应用广告、目录销售等。 +- [[LinkedIn Campaign Manager]]：LinkedIn 广告管理后台，支持赞助内容、消息广告、文档广告、ABM 名单上传等 B2B 定向功能。 +- [[TikTok Ads]]：TikTok 广告平台，支持 Spark Ads、TopView、信息流广告、品牌标签挑战等原生内容形式。 +- [[Google Ads MCP Tools]]：可选集成工具，用于跨渠道（搜索+社交）数据对比、增量验证和预算决策支持。 +- [[John Williams]]（@itallstartedwithaidea）：Agent 作者。 + +## Connections +- [[Paid Media Search Query Analyst]] ← parallel_specialization ← [[Paid Media Paid Social Strategist]]（两者同属付费媒体 Agent 体系，一个专注搜索查询，一个专注社交广告） +- [[Paid Media Programmatic Buyer]] ← channel_extension ← [[Paid Media Paid Social Strategist]]（程序化购买与社交广告共享受众工程和数据归因方法论） +- [[Paid Media Creative Strategist]] ← depends_on ← [[Paid Media Paid Social Strategist]]（创意策略依赖社交策略的受众洞察和平台选择） +- [[Paid Media Auditor]] ← informs ← [[Paid Media Paid Social Strategist]]（审计结果指导社交广告的优化方向） + +## Contradictions +- 与 [[Paid Media Programmatic Buyer]] 在"自动化 vs. 控制"的权衡上存在张力： + - 冲突点：程序化购买强调自动化竞价和实时优化；社交广告中的 Advantage+ 也强调自动化，但该 Agent 同时强调人工干预的受众排除和频次管理。 + - 当前观点：社交广告需要人工把控受众排除策略和跨平台频次，防止自动化算法过度扩张。 + - 对方观点：程序化购买可以高度依赖算法自动学习，人工干预应最小化。 diff --git a/wiki/sources/paid-media-tracking-specialist.md b/wiki/sources/paid-media-tracking-specialist.md new file mode 100644 index 00000000..24c0d548 --- /dev/null +++ b/wiki/sources/paid-media-tracking-specialist.md @@ -0,0 +1,55 @@ +--- +title: "Paid Media Tracking & Measurement Specialist Agent" +type: source +tags: ["paid-media", "agent", "tracking", "measurement", "GTM", "GA4"] +date: 2026-04-20 +last_updated: 2026-04-25 +sources: [] +--- + +## Source File +- [[Agent/agency-agents/paid-media/paid-media-tracking-specialist.md]] + +## Summary（用中文描述） +- **核心主题**：付费媒体追踪与归因专家 Agent——负责构建跨平台（GTM、GA4、Google Ads、Meta CAPI、LinkedIn Insight Tag）的事件追踪架构，确保每一次转化都被正确计数，每一分广告投入都可衡量。 +- **问题域**：标签容器臃肿、跨平台重复计数、归因模型失准、隐私合规（GDPR/CCPA/Consent Mode v2）挑战、UA→GA4/客户端→服务端迁移。 +- **方法/机制**：GTM 容器架构设计、dataLayer 规范、事件去重（event_id 匹配）、增强转化（hashed PII）、服务端容器部署、数据驱动归因模型。 +- **结论/价值**：精准追踪是付费媒体优化的数据根基——错误的数据不仅浪费，更会误导出价算法往错误方向优化。 + +## Key Claims（用中文描述） +- 精准追踪工程师构建的数据基础，使所有付费媒体优化成为可能。 +- 错误追踪比无追踪更糟糕——一次错误计数的转化，不仅浪费数据，更会主动误导出价算法向错误结果优化。 +- 追踪 bug 会无声叠加——5% 的数据差异若不修复，明天就变成一个方向错误的出价算法。 +- 重大营销活动前，必须先建立测量计划（Measurement Plan）。 + +## Key Quotes +> "Bad tracking is worse than no tracking — a miscounted conversion doesn't just waste data, it actively misleads bidding algorithms into optimizing for the wrong outcomes." — 核心原则 + +> "Always cross-reference platform-reported conversions against the actual API data. Tracking bugs compound silently — a 5% discrepancy today becomes a misdirected bidding algorithm tomorrow." — 调试方法论 + +> "If it's not tracked correctly, it didn't happen." — Agent 风格标语 + +## Key Concepts +- [[GoogleTagManager]]：GTM 容器架构、工作区管理、触发器/变量设计、自定义 HTML 标签、Consent Mode 实现、标签序列与触发优先级。 +- [[GoogleAnalytics4]]：事件分类体系设计、自定义维度/指标、增强衡量配置、电商 dataLayer 实现（view_item/add_to_cart/begin_checkout/purchase）、跨域追踪。 +- [[MetaConversionsAPI]]：CAPI 服务端配置、事件去重（event_id 匹配）、域名验证、聚合事件测量配置——确保 Pixel 浏览器事件与 CAPI 服务端事件不重复计数。 +- [[ServerSideTagging]]：GTM 服务端容器部署、第一方数据收集、Cookie 管理、服务端富化。 +- [[ConversionTracking]]：Google Ads 转化操作（主转化/次转化）、增强转化（网页和线索）、离线转化 API 导入、转化价值规则、转化操作集。 +- [[AttributionModeling]]：数据驱动归因模型配置、跨渠道归因分析、增量测试设计、营销组合建模输入。 +- [[ConsentModeV2]]：Consent Mode v2 实现、GDPR/CCPA 合规、Cookie Banner 集成、数据保留设置。 +- [[DataLayerArchitecture]]：复杂电商和线索生成网站的 dataLayer 架构设计规范。 + +## Key Entities +- [[JohnWilliams]]：Agent 作者（@itallstartedwithaidea） +- [[TheAgency]]：Agent 所属的多 Agent 协作框架 + +## Connections +- [[PaidMediaAdCreativeStrategist]] ← complementary ← [[PaidMediaTrackingSpecialist]] +- [[PaidMediaPaidSocialStrategist]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（Social 广告依赖精准追踪） +- [[PaidMediaPPCStrategist]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（PPC 依赖转化追踪数据） +- [[PaidMediaProgrammaticBuyer]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（程序化投放依赖归因模型） +- [[PaidMediaSearchQueryAnalyst]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（搜索词分析依赖转化数据） +- [[PaidMediaAuditor]] ← depends_on ← [[PaidMediaTrackingSpecialist]]（审计依赖追踪准确性验证） + +## Contradictions +- （暂无发现与其他页面的内容冲突） diff --git a/wiki/sources/sales-account-strategist.md b/wiki/sources/sales-account-strategist.md new file mode 100644 index 00000000..96b85592 --- /dev/null +++ b/wiki/sources/sales-account-strategist.md @@ -0,0 +1,63 @@ +--- +title: "Account Strategist Agent" +type: source +tags: [] +date: 2026-04-25 +--- + +## Source File +- [[Agent/agency-agents/sales/sales-account-strategist.md]] + +## Summary（用中文描述） +- 核心主题：Account Strategist（账户策略师）Agent —— 售后收入扩张战略智能体，专门负责账户扩展、QBR设计、利益相关者映射和净收入留存 +- 问题域：SaaS/企业软件公司如何将一次性成交转化为长期平台关系，如何通过系统性扩张规划实现净收入留存（NRR）最大化 +- 方法/机制：Land-and-Expand 执行框架 → 季度业务回顾（QBR）设计 → 利益相关者多线程关系建设 → NRR 健康评分体系 → 流失预警干预机制 +- 结论/价值：最佳销售时机是客户成功时；账户健康优先于扩张；永远不做单线程账户；NRR 是终极指标 + +## Key Claims（用中文描述） +- 账户策略师将每个客户账户视为一片有待填充的空白领域（territory with whitespace），通过系统性扩张规划将单点解决方案转化为企业平台 +- 每个扩张机会必须配套来自客户视角的文档化商业案例，单纯有信号不足以触发扩张 +- 永远不在尚未成功使用现有产品的账户上推扩张——向不健康的账户销售更多会加速流失而非增长 +- 区分扩张就绪（客户可以买更多）与扩张意图（客户想买更多），只有后者才能可靠转化 +- 每个账户必须有至少三条独立的业务关系线——即使冠军明天离职，你仍然能与关心产品的其他人保持活跃对话 +- NRR（净收入留存）是终极指标，它用一个数字捕获了扩张、收缩和流失 +- QBR 应是前瞻性的战略规划会议，而非回顾性的状态报告 + +## Key Quotes +> "The best time to sell more is when the customer is winning." — Account Strategist Agent 核心理念 +> "A signal alone is not enough. Every expansion signal must be paired with context (why is this happening?), timing (why now?), and stakeholder alignment (who cares about this?)." — Expansion Signal Discipline +> "Never pitch expansion to a customer who is not yet successful with what they already own." — Account Health First Rule +> "NRR is the ultimate metric. It captures expansion, contraction, and churn in a single number. Optimize for NRR, not bookings." — Account Health First Rule +> "Be strategically specific: 'Usage in the analytics team hit 92% capacity — their headcount is growing 30% next quarter, so expansion timing is ideal.'" — Communication Style + +## Key Concepts +- [[Land-and-Expand]]：将初始成交（land deal）逐步扩展为七位数平台关系的系统性方法论，包括扩张就绪信号识别、冠军赋能套件、RACI 扩张剧本 +- [[Net Revenue Retention (NRR)]]：净收入留存率——捕获扩张、收缩和流失的综合指标，NRR > 100% 意味着即使没有新客户也能实现增长 +- [[QBR (Quarterly Business Review)]]：季度业务回顾——前瞻性战略规划会议，包含 ROI 数据量化回顾、业务目标对齐、共同行动计划 +- [[Stakeholder Mapping]]：利益相关者映射——维护账户内活的利益相关者地图：决策者、预算持有者、影响者、终端用户、反对者、冠军 +- [[Multi-Threading]]：多线程关系建设——每个账户至少三条独立关系线，防止单点失败（champion 离职导致的关系断层） +- [[Account Health Score]]：账户健康评分——综合产品使用率、支持工单情感、利益相关者参与度、合同时间线、高管发起人活动 +- [[Churn Prevention Playbook]]：流失预防手册——早期预警信号 + 分级干预计划（立即/短期/中期） + +## Key Entities +- **Account Strategist Agent**：售后扩张策略师角色，对应 [[sales-account-strategist]] +- **Account Executive (AE)**：客户经理，与账户策略师在扩张剧本、RACI 中协作 +- **Customer Success (CS)**：客户成功团队，负责使用监控和健康评分维护 +- **Product Team**：产品团队，参与扩张对齐和里程碑触发 +- **Executive Sponsor**：高管发起人——高参与度（>60天未接触=风险信号）是账户健康的领先指标 + +## Connections +- [[sales-proposal-strategist]] ← post-sale extends pre-sale ← [[sales-proposal-strategist]] +- [[sales-engineer]] ← overlaps (both post-sale) ← [[sales-engineer]] +- [[sales-discovery-coach]] ← upstream feeds downstream ← [[sales-discovery-coach]] +- [[sales-pipeline-analyst]] ← shares NRR metric ← [[sales-pipeline-analyst]] + +## Contradictions +- 与 [[sales-proposal-strategist]] 的关注阶段不同： + - 冲突点：提案策略师关注赢单前的提案叙事；账户策略师关注赢单后的扩张执行 + - 当前观点：两者互补——提案建立期望，账户策略师交付并超越期望 + - 对方观点：[[sales-proposal-strategist]] 的"赢单叙事"需要考虑 post-sale 的可交付性 +- 与 [[sales-coach]] 的辅导焦点不同： + - 冲突点：销售教练辅导卖方（销售代表成长）；账户策略师辅导买方（帮助客户内部推广） + - 当前观点：互补关系——[[sales-coach]] 提升卖方能力，[[sales-account-strategist]] 建设买方冠军 + - 对方观点：无直接冲突，角色边界清晰 diff --git a/wiki/sources/sales-coach.md b/wiki/sources/sales-coach.md new file mode 100644 index 00000000..efc11e1c --- /dev/null +++ b/wiki/sources/sales-coach.md @@ -0,0 +1,54 @@ +--- +title: "Sales Coach Agent" +type: source +tags: ["sales", "coaching", "agent", "b2b"] +date: 2026-04-24 +--- + +## Source File +- [[Agent/agency-agents/sales/sales-coach.md]] + +## Summary（用中文描述） +- 核心主题：AI 销售教练 Agent，通过苏格拉底式提问驱动销售代表成长，专注于管道审查、话术辅导、交易策略和预测准确性 +- 问题域：销售团队管理、销售代表能力发展、交易风险识别、预测纪律 +- 方法/机制：结构化辅导框架（ Richardson Sales Performance）、挑战者销售模型（Challenger）、MEDDPICC 资质诊断、行为反馈循环 +- 结论/价值：正式销售辅导项目使配额完成率达 91.2%（vs 非正式辅导 84.7%），每周接受2小时以上辅导的销售代表赢单率达56%（vs 少于30分钟仅43%） + +## Key Claims（用中文描述） +- 正式销售辅导项目使团队配额完成率达 91.2%，显著优于非正式辅导的 84.7% +- 每周接受 2 小时以上辅导的销售代表赢单率为 56%，远高于每周少于 30 分钟辅导的 43% +- 辅导行为而非结果：过程完美的输单不需要纠正，幸运赢单需要立即辅导 +- 管道数量是虚荣指标，管道质量才是管理工具 +- 每次辅导互动必须产出一个具体、可行为、可执行的改进建议 + +## Key Quotes +> "Ask before telling. Your first instinct should always be a question, not an instruction." — 苏格拉底式辅导的核心原则 +> "A lost deal with disciplined process is more valuable than a lucky win, because process compounds and luck does not." — 过程优于结果 +> "Enthusiasm without commitment is not a buying signal." — 挑战"happy ears"，要求可验证的承诺 + +## Key Concepts +- [[MEDDPICC]]：交易资质诊断框架，包含八个维度（Metrics、Economic Buyer、Decision Criteria、Decision Process、Paper Process、Implicated Pain、Champion、Competition）；Deal 少于 5/8 字段填充即为资格不足，是预测失误的主要来源；资质缺口是交易风险的信号，而非 CRM 记录问题 +- [[Challenger Sales Model]]：挑战者辅导模型，教导销售代表以商业洞察引领对话，而非被动回应客户需求；在客户思考问题的方式上重新构建认知 +- [[Richardson Sales Performance Framework]]：四维能力框架：辅导卓越、激励领导、销售管理纪律、战略规划 +- [[Pipeline Review]]：将管道审查从审讯转变为辅导对话，用"我们对这个交易还有什么不知道的"替代"什么时候关单" +- [[Forecast Accuracy]]：基于可验证证据而非乐观情绪的预测纪律，区分 upside/commit/closed 三个层级 +- [[Coaching Discipline]]：辅导纪律——行为辅导而非结果辅导；一次只做一件事；跟进反馈是否被应用 + +## Key Entities +- [[Discovery Coach Agent]]：同为 The Agency 销售类 Agent，专注发现阶段辅导，与 Sales Coach 形成互补关系 +- [[Sales Pipeline Analyst Agent]]：管道分析类 Agent，提供数据支撑，与 Sales Coach 协同工作 +- [[Sales Deal Strategist Agent]]：交易策略类 Agent，在重大交易前进行策略准备 + +## Connections +- [[Discovery Coach Agent]] ← complements ← [[Sales Coach Agent]] +- [[Sales Pipeline Analyst Agent]] ← provides_data_for ← [[Sales Coach Agent]] +- [[Sales Deal Strategist Agent]] ← prepares ← [[Sales Coach Agent]] +- [[Sales Coach Agent]] ← uses ← [[MEDDPICC]] +- [[Sales Coach Agent]] ← uses ← [[Challenger Sales Model]] + +## Contradictions +- 与 [[Discovery Coach Agent]] 的潜在差异： + - 冲突点：辅导焦点的层次不同 + - 当前观点（Sales Coach）：辅导范围覆盖全销售周期，包括发现、策略、预测 + - 对方观点（Discovery Coach）：专注发现阶段的深度辅导 + - 协调方案：Discovery Coach 负责发现阶段深度，Sales Coach 负责整体辅导规划，两者协同覆盖完整周期 diff --git a/wiki/sources/sales-deal-strategist.md b/wiki/sources/sales-deal-strategist.md new file mode 100644 index 00000000..04a81635 --- /dev/null +++ b/wiki/sources/sales-deal-strategist.md @@ -0,0 +1,61 @@ +--- +title: "Deal Strategist Agent" +type: source +tags: [] +date: 2026-04-20 +--- + +## Source File +- [[Agent/agency-agents/sales/sales-deal-strategist.md]] + +## Summary（用中文描述） +- 核心主题：B2B 复杂销售周期的高级deal策略与管线架构 +- 问题域：销售管线中deal质量评估不严、预测失准、竞争定位模糊、赢率低下 +- 方法/机制：MEDDPICC八维资质评分 + Challenger商业教学法 + 三区竞争定位 + 六步商业教学序列 + 交易检查方法论 +- 结论/价值：全面推行MEDDPICC的组织赢率提升18%、deal规模扩大24%；预测准确率Commit deals关闭率85%+；Qualified Pipeline赢率35%+ + +## Key Claims（用中文描述） +- 全面推行MEDDPICC的组织赢率提升18%、deal规模扩大24%——但前提是将MEDDPICC作为思维工具而非打勾练习 +- 一个deal若没有回答全部八个要素，说明尚未真正理解该deal +- 6周采购周期如果在第11周才发现，会直接扼杀季度 +- 决策在理性层面被论证，在感性层面被做出 +- 预测准确率Commit deals关闭率应达85%+ +- Qualified Pipeline（28/40分以上）赢率应达35%+ +- 竞争定位中的Losing Zone应对策略是缩小其重要性，而非撒谎或攻击竞争对手 + +## Key Quotes +> "A deal without all eight answered is a deal you don't understand." — MEDDPICC核心原则 +> "This deal is at risk. Here's why, and here's what to do about it." — 策略师沟通风格 +> "Decisions are justified rationally and made emotionally." — 商业教学情感层 +> "The winning move on losing zones is to shrink their importance, not to lie about your capabilities." — 竞争定位原则 + +## Key Concepts +- [[MEDDPICC]]：八维资质评分框架——Metrics/Economic Buyer/Decision Criteria/Decision Process/Paper Process/Identify Pain/Champion/Competition，每维度5分，满分40 +- [[Challenger Sales Model]]：挑战者销售法——通过商业教学重新定义买方对自身问题的理解，在定位解决方案之前先建立价值 +- [[Command of the Message]]：信息掌控框架——三层支柱（我们解决什么问题/我们如何不同/客户实现什么可衡量成果） +- Deal Scoring：加权评分模型，分离真实管线与虚假管线，含预警指标 +- Competitive Positioning：竞争定位策略——Winning/Battling/Losing三区分类 + 地雷问题布局 +- Win Planning：分阶段行动计划，含明确责任人、里程碑和退出标准 +- Deal Inspection Methodology：交易检查方法论——系统性探测deal状态、风险和下一步 +- Challenger Messaging：六步商业教学序列——Warmer/Reframe/Rational Drowning/Emotional Impact/A New Way/Your Solution + +## Key Entities +- [[Sales Coach Agent]]：同为The Agency销售体系的核心智能体，Sales Coach辅导卖方行为，Deal Strategist辅导deal策略 +- [[Discovery Coach Agent]]：发现阶段教练，提供买方情境输入给Deal Strategist +- [[Sales Proposal Strategist]]：赢单叙事构建者，接收Deal Strategist的竞争定位和评分输出 +- Deal Strategist Agent：The Agency销售部门成员，专业于MEDDPICC deal策略、竞争定位和赢单规划 + +## Connections +- [[sales-coach]] ← shares MEDDPICC framework with ← [[sales-discovery-coach]] +- [[sales-proposal-strategist]] ← receives win strategy input from ← [[sales-deal-strategist]] +- [[sales-discovery-coach]] ← provides buyer context to ← [[sales-deal-strategist]] +- [[sales-deal-strategist]] ← extends MEDDPICC with deal execution tactics ← [[sales-coach]] + +## Contradictions +- 与 [[sales-proposal-strategist]] 的视角差异： + - 冲突点：Deal Strategist聚焦交易层面的策略和执行，Proposal Strategist聚焦提案层面的叙事和说服 + - 当前观点：Deal Strategist认为"没有全面评估的deal在预测会上就输了" + - 对方观点：Proposal Strategist认为"赢单在提案开篇100词就已决定" + - 协调：两者互补——Deal Strategist提供结构化deal分析和竞争定位，Proposal Strategist将其转化为说服性叙事 +- 与 [[sales-discovery-coach]] 的互补关系： + - Discovery Coach发现买方情境，Deal Strategist基于此构建交易策略，两者构成"发现→策略"闭环 diff --git a/wiki/sources/sales-discovery-coach.md b/wiki/sources/sales-discovery-coach.md new file mode 100644 index 00000000..d7424a83 --- /dev/null +++ b/wiki/sources/sales-discovery-coach.md @@ -0,0 +1,50 @@ +--- +title: "Discovery Coach Agent" +type: source +tags: [sales, discovery, methodology, coaching] +last_updated: 2026-04-25 +--- + +## Source File +- [[Agent/agency-agents/sales/sales-discovery-coach.md]] + +## Summary（用中文描述） +- 核心主题：销售发现访谈（Discovery）方法论与教练框架，帮助销售代表成为更优秀的买家访谈者 +- 问题域：销售团队普遍存在发现访谈深度不足、问题设计粗糙、无法挖掘真正购买动机的问题 +- 方法/机制：三大发现框架（SPIN Selling / Gap Selling / Sandler Pain Funnel）+ 标准30分钟发现电话结构 + AECR异议处理框架 +- 结论/价值：发现是交易成败的关键战场——而非演示、提案或谈判阶段。顶级销售通过多问一个问题来击败竞争对手 + +## Key Claims（用中文描述） +- 发现阶段决定交易成败，而非演示、提案或谈判阶段 +- Implication问题（SPIN Selling第三层）是最有力的成交工具，因其激活买家的损失厌恶心理 +- Gap Selling中，根因问题是最重要也最常被跳过的问题；表面问题不产生紧迫感，根因才产生 +- Sandler Pain Funnel第三层（个人/情感层面）是大多数销售人员永远不会触及的区域，但购买决策本质上是情感决策 +- 预算异议几乎从不是真正的预算问题，而是买家对价值是否超过成本的判断 + +## Key Quotes +> "Implication questions are uncomfortable to ask. That discomfort is a feature. The buyer has not fully confronted the cost of the status quo until these questions are asked." — SPIN Selling中Implication问题的价值说明 +> "Level 3 is where most sellers never go. But buying decisions are emotional decisions with rational justifications." — Sandler Pain Funnel第三层的重要性 +> "Budget objections are almost never about budget. They are about whether the buyer believes the value exceeds the cost." — 预算异议的真相 +> "The 60/40 rule: the buyer should talk 60% of the time or more. If you are talking more than 40%, you are pitching, not discovering." — 发现访谈的核心比例原则 + +## Key Concepts +- [[SPIN Selling]]：Neil Rackham提出的企业销售四步提问法（Situation / Problem / Implication / Need-Payoff），核心洞察是Implication问题通过激活损失厌恶来推动成交 +- [[Gap Selling]]：Keenan提出的以当前状态与期望未来状态之间的差距为中心的销售方法论；差距越大，紧迫感越强 +- [[Sandler Pain Funnel]]：从表面症状到商业影响再到情感/个人层面的三层漏斗式发现技术 +- [[AECR Framework]]：处理销售异议的四步框架（Acknowledge / Empathize / Clarify / Reframe），将异议视为诊断信息 +- [[Upfront Contract]]：发现电话开场的最优技术，通过预设三种可能结果来建立信任和获取提问许可 +- [[Discovery Call Structure]]：标准30分钟发现电话的时间分配（开场2分钟 / 发现18分钟 / 定向pitch 6分钟 / 下一步4分钟） + +## Key Entities +- [[Neil Rackham]]：SPIN Selling方法论的提出者，通过对35,000+次销售拜访的研究发展出该框架 +- [[Keenan]]：Gap Selling方法论的提出者，强调当前状态与未来状态之间精确差距的商业价值 +- [[Sandler]]：Sandler Pain Funnel的创始人，开发了从表面到个人层面的三层痛苦发现技术 + +## Connections +- [[Sales Coach]] ← extends ← [[Discovery Call Structure]] +- [[SPIN Selling]] ← extends ← [[Sandler Pain Funnel]]（两者互补，SPIN强调问题序列，Sandler强调深度层次） +- [[AECR Framework]] ← depends_on ← [[Discovery Call Structure]] +- [[Gap Selling]] ← depends_on ← [[SPIN Selling]]（Gap Selling可视为SPIN框架的实践落地） + +## Contradictions +- 暂无发现与现有Wiki内容的冲突 diff --git a/wiki/sources/sales-engineer.md b/wiki/sources/sales-engineer.md new file mode 100644 index 00000000..fa0fd65f --- /dev/null +++ b/wiki/sources/sales-engineer.md @@ -0,0 +1,59 @@ +--- +title: "Sales Engineer Agent" +type: source +tags: [] +date: 2026-04-25 +--- + +## Source File +- [[Agent/agency-agents/sales/sales-engineer.md]] + +## Summary（用中文描述） +- 核心主题：售前工程师（Sales Engineer）Agent 的角色定义、能力模型与操作框架，专注于在 B2B 技术评估中赢得技术决策 +- 问题域：B2B 软件销售中的技术售前环节——如何设计演示、执行 POC、应对竞争、处理异议、管理评估流程 +- 方法/机制：Demo Engineering（以影响力为导向的演示设计）、POC Scoping（严格限定的概念验证范围）、FIA Framework（事实-影响-行动竞争定位框架）、Evaluation Notes（交易级技术情报维护） +- 结论/价值：技术决策先于商业决策，售前工程师必须将每一次技术对话连接到业务成果，而非单纯展示功能 + +## Key Claims（用中文描述） +- 售前工程师赢得技术决策，销售才能赢得商业合同——技术层是整个交易的关键门槛 +- 演示不是产品tour，而是叙事——买家在演示中看到自己的问题被实时解决 +- POC 不是免费试用，而是有二元结果的结构化评估：成功或失败，标准在开始前就已明确定义 +- 竞争定位应采用 FIA 框架（Fact-Impact-Act），保持事实基础和可操作性，而非情绪化和反应式 +- 永远不要攻击竞争对手——认可竞争对手的优势，同时清晰表达差异化 + +## Key Quotes +> "A demo is not a product tour. A demo is a narrative where the buyer sees their problem solved in real time." — 演示的本质是叙事，不是功能演示 +> "Every technical conversation must connect back to a business outcome or it's just a feature dump." — 技术对话必须连接到业务成果 +> "Ambiguous success criteria produce ambiguous outcomes, which produce 'we need more time to evaluate,' which means you lost." — 模糊的成功标准等于失败 +> "Never trash the competition. Buyers respect SEs who acknowledge competitor strengths while clearly articulating differentiation." — 永远不要攻击竞争对手 + +## Key Concepts +- [[Demo Engineering]]：以影响力为导向的演示设计，先量化问题，再展示产品，最后证明效果 +- [[POC Scoping]]：严格限定的概念验证范围设计，以成功标准、硬性时间线和检查点为支柱 +- [[FIA Framework]]：Fact-Impact-Act 竞争定位框架，保持事实基础和可操作性 +- [[Evaluation Notes]]：交易级技术情报维护，结构化记录每个活跃交易的技术环境、决策者、竞争态势和演示策略 +- [[Technical Objection Handling]]：技术异议处理，解码真实问题而非表面问题 +- [[Aha Moment]]：演示中让买家产生"这正是我们需要的"那一刻，是演示成功的核心标志 + +## Key Entities +- [[Sales Pipeline Analyst Agent]]：同属销售团队的数据分析 Agent，共同支撑销售闭环 +- [[Sales Outbound Strategist Agent]]：同属销售团队的对外策略 Agent，共同支撑销售闭环 +- [[Deal Strategist Agent]]：同属销售团队的交易策略 Agent，共同支撑销售闭环 +- [[Account Strategist Agent]]：同属销售团队的客户策略 Agent，共同支撑销售闭环 +- [[Sales Proposal Strategist]]：同属销售团队的建议书策略 Agent，共同支撑销售闭环 + +## Connections +- [[Sales Pipeline Analyst Agent]] ← team_member ← [[Sales Engineer Agent]] +- [[Sales Outbound Strategist Agent]] ← team_member ← [[Sales Engineer Agent]] +- [[Deal Strategist Agent]] ← team_member ← [[Sales Engineer Agent]] +- [[Account Strategist Agent]] ← team_member ← [[Sales Engineer Agent]] +- [[Sales Proposal Strategist]] ← team_member ← [[Sales Engineer Agent]] +- [[Sales Discovery Coach Agent]] ← adjacent_role ← [[Sales Engineer Agent]] +- [[Sales Coach Agent]] ← adjacent_role ← [[Sales Engineer Agent]] + +## Contradictions +- 与 [[Sales Discovery Coach Agent]] 在"技术深度"维度存在互补张力： + - 冲突点：售前工程师在发现阶段应保持多深的技术参与度？ + - 当前观点（Sales Engineer）：售前工程师应主导技术发现，结构化地挖掘架构、集成、安全约束和真实技术决策标准 + - 对方观点（Sales Discovery Coach）：销售发现应聚焦于业务问题，深度技术探索由专门的角色或时机负责 + - 协调方向：在发现阶段早期以业务语言建立信任，进入评估阶段后切换为技术深度模式 diff --git a/wiki/sources/sales-pipeline-analyst.md b/wiki/sources/sales-pipeline-analyst.md new file mode 100644 index 00000000..b0437bee --- /dev/null +++ b/wiki/sources/sales-pipeline-analyst.md @@ -0,0 +1,46 @@ +--- +title: "Pipeline Analyst Agent" +type: source +tags: [sales, revenue-operations, pipeline, forecasting, CRM, MEDDPICC] +date: 2026-04-25 +--- + +## Source File +- [[Agent/agency-agents/sales/sales-pipeline-analyst.md]] + +## Summary（用中文描述） +- 核心主题：Revenue Operations 领域的 Pipeline 健康诊断与收入预测 AI Agent，将 CRM 数据转化为可执行的 Pipeline 洞察，在问题演变为季度失误之前主动预警。 +- 问题域：销售 Pipeline 管理、收入预测准确性、Deal 质量评估、销售教练数据分析 +- 方法/机制：Pipeline Velocity 公式 + MEDDPICC 资格评分 + 多信号预测模型 + Deal 健康评分卡 +- 结论/价值：质量调整后的 Pipeline 覆盖度永远优于阶段加权覆盖度；每份 Pipeline 评估都应至少发现一个需要立即干预的 Deal；预测必须带置信区间而非单一数字。 + +## Key Claims（用中文描述） +- Pipeline Velocity =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度，四个变量均为诊断杠杆。 +- 目标覆盖比率：成熟可预测业务 3x，成长期或新市场 4-5x，新销售入职 5x+。 +- 晚期阶段 Deal 的 MEDDPICC 字段少于 5/8 即为资格不足，是预测失误的主要来源。 +- 多线程、利益相关者深度参与的 Deal 关闭率是同阶段单线程低活跃度 Deal 的 2-3 倍。 +- 预测必须输出 Commit（>90%置信）/Best Case（>60%）/Upside（<60%）三档，而非单一数字。 +- AI 驱动的预测评分消除两种最常见的人类偏见：销售乐观主义（永远"看起来很好"）和管理层锚定（从上一季度数字而非当前数据分析）。 + +## Key Quotes +> "Quality-adjusted coverage discounts pipeline by deal health score, stage age, and engagement signals. A $5M pipeline with 20 stale, poorly qualified deals is worth less than a $2M pipeline with 8 active, well-qualified opportunities." — 质量调整原则：高质量少量 Pipeline 优于大量低质量 Pipeline +> "Deals with fewer than 5 of 8 MEDDPICC fields populated are underqualified. Underqualified deals at late stages are the primary source of forecast misses." — 晚期阶段资格不足 Deal 是预测失误的主因 +> "The CRM shows $12M in pipeline. After adjusting for stale deals, missing qualification data, and historical stage conversion, the realistic weighted pipeline is $4.8M." — 数据质量对预测的影响示例 + +## Key Concepts +- [[PipelineVelocity]]：Pipeline Velocity =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度，是 Revenue Operations 最核心的复合指标 +- [[MEDDPICC]]：8维度 Deal 资格评估框架（Metrics、Economic Buyer、Decision Criteria、Decision Process、Paper Process、Implicated Pain、Champion、Competition），用于诊断 Deal 质量和预测可行性 +- [[DealHealthScoring]]：通过资格深度、互动强度、进展速度三维度综合评估 Deal 健康状况的评分体系 +- [[QualityAdjustedCoverage]]：质量调整后的 Pipeline 覆盖度，结合 Deal 健康评分、阶段年龄和互动信号对 Pipeline 进行折减 +- [[RevenueOperations]]：Revenue Operations 的核心分析方法论，活动指标驱动 Pipeline 指标，Pipeline 指标驱动收入结果 + +## Key Entities +- [[SalesDealStrategist]]：Deal 策略制定 Agent，与 Pipeline Analyst 共同构成销售情报闭环（Pipeline Analyst 评估 Deal 质量，Deal Strategist 制定推进策略） +- [[SalesAccountStrategist]]：客户策略 Agent，Pipeline Analyst 为其提供客户层级的 Pipeline 健康数据 +- [[SalesOutboundStrategist]]：外展策略 Agent，其创建的 Pipeline 机会进入 Pipeline Analyst 的监测体系 + +## Connections +- [[SalesDealStrategist]] ← depends_on ← [[SalesPipelineAnalyst]] +- [[SalesAccountStrategist]] ← depends_on ← [[SalesPipelineAnalyst]] +- [[SalesOutboundStrategist]] ← creates_pipeline_for ← [[SalesPipelineAnalyst]] +- [[SalesCoach]] ← uses_forecast_data ← [[SalesPipelineAnalyst]] diff --git a/wiki/sources/sales-proposal-strategist.md b/wiki/sources/sales-proposal-strategist.md new file mode 100644 index 00000000..a4bbdb7d --- /dev/null +++ b/wiki/sources/sales-proposal-strategist.md @@ -0,0 +1,51 @@ +--- +title: "Sales Proposal Strategist" +type: source +tags: ["sales", "proposal", "RFP", "win-themes", "narrative", "persuasion"] +date: 2026-04-20 +--- + +## Source File +- [[Agent/agency-agents/sales/sales-proposal-strategist.md]] + +## Summary（用中文描述） +- 核心主题：销售提案策略师 Agent 的系统化提案撰写方法论——将 RFP 响应从合规检查清单转化为有说服力的赢单叙事 +- 问题域：企业级销售提案、RFP 响应、竞争性投标、赢标主题开发、执行摘要撰写 +- 方法/机制：三幕提案叙事结构（理解挑战→解决方案旅程→转变状态）、3-5 个赢标主题矩阵、执行摘要五步模板、说服架构（首因/近因效应、认知负荷管理、社会认同排序、损失厌恶框架）、内容运营体系 +- 结论/价值：提案的胜负在开篇 100 词内决定；叙事是差异化核心；在能力趋同的商品化市场中，说服力即竞争力 + +## Key Claims（用中文描述） +- 赢标主题必须贯穿执行摘要、解决方案叙事、案例研究和定价逻辑——孤立的主题等于隐形的主题 +- 提案在开篇 100 词内决定胜负：评估者通过前 100 词判断供应商是否真正理解他们的业务 +- 执行摘要不是提案的摘要，而是提案的终局论证，应放在最前面 +- 永远不要直接批评竞争对手——将自身优势框架为直接利益，让对比自然形成 +- 定价在价值之后：先建立 ROI 案例、量化问题成本，在买方看到数字之前锚定成果而非成本 +- 内容库应按赢标主题而非章节组织——加速未来提案并保持叙事一致性 + +## Key Quotes +> "Proposals are won on clarity and lost on generics." — 核心理念：泛泛而谈即失败 +> "The executive summary is the proposal's closing argument, placed first." — 执行摘要的本质定义 +> "Every proposal needs 3-5 win themes: compelling, client-centric statements that connect your solution directly to the buyer's most urgent needs." — 赢标主题的定义 +> "Micro-stories win sections. Teams that embed micro-stories within technical sections achieve measurably higher evaluation scores." — 微故事的力量 + +## Key Concepts +- [[WinThemes|赢标主题（Win Themes）]]：连接解决方案与买方最紧迫需求的核心叙事陈述，贯穿整个提案 +- [[ThreeActProposalNarrative|三幕提案叙事（Three-Act Proposal Narrative）]]：理解挑战→解决方案旅程→转变状态 +- [[ExecutiveSummary|执行摘要（Executive Summary）]]：提案的终局论证，非摘要 +- [[CaptureStrategy|捕获策略（Capture Strategy）]]：RFP 发布前的预定位和关系映射 +- [[PersuasionArchitecture|说服架构（Persuasion Architecture）]]：首因/近因效应、认知负荷管理、社会认同排序、损失厌恶框架 +- [[RFP|RFP（Request for Proposal）]]：招标书/需求建议书 +- [[WinThemeMatrix|赢标主题矩阵（Win Theme Matrix）]]：评估主题与买方需求、差异化因素、证明点映射关系的结构化工具 + +## Key Entities +- 无特定命名实体（人/公司/产品/项目） + +## Connections +- [[SalesCoach]] ← related_to ← [[SalesProposalStrategist]]（同属销售 Agent 体系） +- [[SalesDiscoveryCoach]] ← related_to ← [[SalesProposalStrategist]]（发现阶段为提案策略提供输入） +- [[SalesEngineer]] ← related_to ← [[SalesProposalStrategist]]（技术销售工程师提供提案技术支撑） +- [[SalesOutboundStrategist]] ← related_to ← [[SalesProposalStrategist]]（外展策略为提案创造机会） +- [[SalesDealStrategist]] ← related_to ← [[SalesProposalStrategist]]（deal 策略与提案策略协同） + +## Contradictions +- 暂无冲突 diff --git a/wiki/sources/terminal-integration-specialist.md b/wiki/sources/terminal-integration-specialist.md new file mode 100644 index 00000000..5f7825a5 --- /dev/null +++ b/wiki/sources/terminal-integration-specialist.md @@ -0,0 +1,54 @@ +--- +title: "Terminal Integration Specialist" +type: source +tags: [] +date: 2026-04-20 +--- + +## Source File +- [[Agent/agency-agents/spatial-computing/terminal-integration-specialist.md]] + +## Summary（用中文描述） +- 核心主题：Terminal Integration Specialist 是一个专注于终端仿真、文本渲染优化和 SwiftTerm 集成的 Agent，服务于现代 Swift 应用程序开发。 +- 问题域：如何在 Apple 平台上（iOS/macOS/visionOS）构建高性能、符合无障碍标准的终端模拟器；如何将 SSH 连接到终端仿真器；如何在 SwiftUI 应用中嵌入 SwiftTerm。 +- 方法/机制： + - 完整支持 VT100/xterm ANSI 转义序列，实现光标控制与终端状态管理 + - 使用 Core Graphics / Core Text 优化文本渲染，实现平滑滚动 + - 通过 SwiftNIO SSH / NMSSH 实现 SSH I/O 桥接 + - 嵌入式 SwiftUI 生命周期管理和后台 I/O 线程处理 +- 结论/价值：提供了一套完整的 Apple 平台终端集成解决方案，兼顾性能、无障碍和跨平台考虑（iOS/macOS/visionOS）。 + +## Key Claims（用中文描述） +- SwiftTerm API 提供完整的公开接口，支持终端仿真的深度定制 +- Core Graphics 优化可实现高频文本更新下的平滑滚动渲染 +- 正确的后台线程处理可避免 UI 更新阻塞，确保终端 I/O 流畅 +- SSH 连接状态管理涵盖连接、断开、重连场景的完整终端行为处理 +- VoiceOver、动态类型等无障碍支持是 Apple 平台终端集成的必要条件 + +## Key Quotes +> "Focuses on creating robust, performant terminal experiences that feel native to Apple platforms while maintaining compatibility with standard terminal protocols." — 核心理念 + +> "Specializes in SwiftTerm specifically (not other terminal emulator libraries)" — 明确范围边界 + +## Key Concepts +- [[VT100/xterm Standards]]：完整的 ANSI 转义序列支持，用于光标控制和终端状态管理 +- [[SwiftTerm]]：Miguel de Icaza 开发的 MIT 许可 Swift 终端仿真库，核心依赖 +- [[Core Graphics Optimization]]：通过 Core Graphics / Core Text 优化文本渲染，实现高频更新下的平滑滚动 +- [[SSH I/O Bridging]]：将 SSH 流高效桥接到终端仿真器的输入/输出层 +- [[Scrollback Buffer]]：大终端历史的回滚缓冲区管理，支持搜索功能 +- [[Accessibility Integration]]：VoiceOver、动态类型等 Apple 无障碍技术集成 + +## Key Entities +- [[SwiftTerm]]（MIT License）：核心终端仿真库，GitHub: migueldeicaza/SwiftTerm +- [[SwiftNIO SSH]]：用于 SSH 连接的 Swift 网络库 +- [[NMSSH]]：另一个 SSH 连接选项库 +- [[Core Graphics]]：Apple 平台 2D 渲染框架 +- [[Core Text]]：Apple 平台文本排版引擎 + +## Connections +- [[visionOS Spatial Engineer]] ← depends_on ← [[Terminal Integration Specialist]]：visionOS 空间工程师依赖终端集成实现空间终端体验 +- [[macOS Spatial Metal Engineer]] ← depends_on ← [[Terminal Integration Specialist]]：macOS Metal 工程师依赖终端集成处理渲染层面 +- [[SwiftTerm]] ← implements ← [[VT100/xterm Standards]]：SwiftTerm 库实现 VT100/xterm 标准 + +## Contradictions +- 无明显内容冲突；该 Agent 专注于 Apple 平台和 SwiftTerm，与其他通用终端解决方案（如 libvte、iTerm2）不在同一问题域内。 diff --git a/wiki/sources/xr-cockpit-interaction-specialist.md b/wiki/sources/xr-cockpit-interaction-specialist.md new file mode 100644 index 00000000..945ad381 --- /dev/null +++ b/wiki/sources/xr-cockpit-interaction-specialist.md @@ -0,0 +1,41 @@ +--- +title: "XR Cockpit Interaction Specialist Agent" +type: source +tags: [] +date: 2026-04-20 +--- + +## Source File +- [[Agent/agency-agents/spatial-computing/xr-cockpit-interaction-specialist.md]] + +## Summary（用中文描述） +- 核心主题：XR 座舱交互专家 Agent——专注于设计和实现沉浸式座舱式交互环境，融合空间控制与自然人体工学 +- 问题域：如何在 XR 环境中构建高存在感、低眩晕的固定视角座舱交互系统 +- 方法/机制：固定视角（fixed-perspective）高存在感交互区设计、人体工学对齐（眼-手-头协调）、约束驱动控制机制（constraint-driven）、多模态交互集成（手势+语音+注视+物理道具） +- 结论/价值：提供真实感与舒适度并重的 XR 座舱解决方案，适用于模拟指挥中心、航天器座舱、XR 载具界面和训练模拟器 + +## Key Claims（用中文描述） +- XR 座舱交互通过固定视角设计（fixed-perspective）和高存在感交互区（high-presence interaction zones）显著提升沉浸感体验 +- 约束驱动控制机制（constraint-driven control mechanics）消除自由漂浮运动，有效降低用户眩晕感 +- 座舱人体工学设计需对齐自然的眼-手-头协调流动（eye–hand–head flow），确保长时间使用舒适性 +- 多模态交互集成（手势、语音、注视、物理道具）为用户提供灵活自然的控制选择 + +## Key Quotes +> "You create fixed-perspective, high-presence interaction zones that combine realism with user comfort." — Agent 核心定位：固定视角高存在感交互区设计 + +## Key Concepts +- [[Constraint-Driven-Control-Mechanics]]：约束驱动控制机制——通过 3D meshes 和输入约束实现的控制物理化设计，取代自由漂浮式交互 +- [[Cockpit-Ergonomics]]：座舱人体工学——对齐自然的眼-手-头协调流动，优化长时间使用的舒适度 +- [[Spatial-Computing]]：空间计算——XR 环境的核心技术基础，支持 3D 空间中的交互设计 +- [[Motion-Sickness-Threshold]]：运动病阈值——通过固定视角和约束驱动设计将其最小化 + +## Key Entities +- [[XR-Cockpit-Interaction-Specialist]]：本 Agent 角色——空间座舱设计专家，专注于 XR 模拟和载具界面 + +## Connections +- [[XR-Interface-Architect]] ← builds_upon ← [[XR-Cockpit-Interaction-Specialist]] +- [[XR-Immersive-Developer]] ← collaborates ← [[XR-Cockpit-Interaction-Specialist]] +- [[Terminal-Integration-Specialist]] ← extends ← [[XR-Cockpit-Interaction-Specialist]] + +## Contradictions +- 与 [[XR-Immersive-Developer]] 在运动自由度上存在设计张力：后者倾向开放空间沉浸体验，前者强调固定视角约束以降低眩晕；当前观点：座舱场景优先舒适性与真实感，通用沉浸场景可保留开放自由度 diff --git a/wiki/sources/xr-immersive-developer.md b/wiki/sources/xr-immersive-developer.md new file mode 100644 index 00000000..05adb8df --- /dev/null +++ b/wiki/sources/xr-immersive-developer.md @@ -0,0 +1,55 @@ +--- +title: "XR Immersive Developer Agent Personality" +type: source +tags: [] +date: 2026-04-20 +--- + +## Source File +- [[Agent/agency-agents/spatial-computing/xr-immersive-developer.md]] + +## Summary（用中文描述） +- 核心主题：XR Immersive Developer Agent——基于 WebXR 技术的沉浸式浏览器 AR/VR/XR 应用开发专家智能体 +- 问题域：如何在浏览器环境下构建跨平台、高性能、具备手部追踪/注视/控制器输入的沉浸式 3D 体验 +- 方法/机制：使用 A-Frame / Three.js / Babylon.js 构建模块化组件化 XR 应用，通过 raycasting、hit testing、实时物理引擎实现沉浸交互，通过 occlusion culling、shader tuning、LOD 系统优化性能，兼容 Meta Quest / Vision Pro / HoloLens / mobile AR +- 结论/价值：提供一套完整的前端 WebXR 工程能力——从原型开发到性能优化，从交互设计到跨设备兼容覆盖 + +## Key Claims（用中文描述） +- XR Immersive Developer 通过 WebXR Device API 实现浏览器端完整沉浸式支持（hand tracking / pinch / gaze / controller input） +- A-Frame / Three.js / Babylon.js 是核心 3D 引擎栈，覆盖从快速原型到高级渲染的完整需求 +- 性能优化通过 occlusion culling、shader tuning、LOD 系统三条路径协同实现 +- 跨设备兼容（Meta Quest / Vision Pro / HoloLens / mobile AR）需要显式兼容性层管理 +- 模块化组件驱动设计确保 XR 体验可复用、降级优雅、便于维护 + +## Key Quotes +> "You are **XR Immersive Developer**, a deeply technical engineer who builds immersive, performant, and cross-platform 3D applications using WebXR technologies." — Agent 身份定义 +> "You bridge the gap between cutting-edge browser APIs and intuitive immersive design." — 核心价值定位 +> "You've shipped simulations, VR training apps, AR-enhanced visualizations, and spatial interfaces using WebXR" — 工程经验总结 + +## Key Concepts +- [[WebXR]]：浏览器原生沉浸式计算 API，支撑 AR/VR/XR 跨设备体验 +- [[A-Frame]]：Mozilla 出品的 Three.js 封装框架，适合快速 WebXR 原型开发 +- [[Three.js]]：底层 WebGL 3D 渲染引擎，A-Frame 的核心依赖 +- [[Babylon.js]]：微软出品的专业级 WebXR 3D 引擎，强大的工具链和 XR 支持 +- [[Hand-Tracking]]：WebXR Hand Input Module，手部追踪交互能力 +- [[LOD-System]]：Level of Detail 渲染优化，根据距离动态调整模型精度 +- [[Occlusion-Culling]]：遮挡剔除性能优化，不渲染被遮挡的物体 + +## Key Entities +- [[Meta Quest]]：Facebook/Meta 的 VR 头显，WebXR 主要目标平台之一 +- [[Vision Pro]]：Apple 空间计算设备，WebXR 重要目标平台 +- [[HoloLens]]：Microsoft 的 AR 头显，WebXR 兼容设备 +- [[Mobile AR]]：移动端增强现实（ARKit/ARCore），跨平台 WebXR 目标 + +## Connections +- [[XR-Interface-Architect]] ← depends_on ← [[XR-Immersive-Developer]]（前者依赖后者的沉浸式渲染和交互能力） +- [[XR-Cockpit-Interaction-Specialist]] ← shares_domain ← [[XR-Immersive-Developer]]（同属 Spatial Computing 部门） +- [[macOS-Spatial-Metal-Engineer]] ← complements ← [[XR-Immersive-Developer]]（前者负责平台底层，后者负责浏览器层） +- [[visionOS-Spatial-Engineer]] ← complements ← [[XR-Immersive-Developer]]（前者专注文果空间计算平台，后者专注浏览器跨平台） + +## Contradictions +- 与 [[XR-Cockpit-Interaction-Specialist]] 冲突： + - 冲突点：运动自由度设计哲学 + - 当前观点（XR-Immersive-Developer）：倾向开放空间沉浸体验，最大化运动自由度 + - 对方观点（XR-Cockpit-Interaction-Specialist）：强调固定视角约束（constraint-driven control mechanics）以降低运动病阈值 + - 说明：两者代表 XR 交互设计的两种范式——沉浸派 vs 安全派，在不同场景下各有优势 diff --git a/wiki/sources/xr-interface-architect.md b/wiki/sources/xr-interface-architect.md new file mode 100644 index 00000000..0d54818c --- /dev/null +++ b/wiki/sources/xr-interface-architect.md @@ -0,0 +1,49 @@ +--- +title: "XR Interface Architect Agent Personality" +type: source +tags: ["agent-personality", "spatial-computing", "ux-design", "ar-vr-xr"] +date: 2026-04-25 +--- + +## Source File +- [[raw/Agent/agency-agents/spatial-computing/xr-interface-architect.md]] + +## Summary（用中文描述） +- 核心主题：定义一个专为 AR/VR/XR 沉浸式环境设计空间化用户界面的 AI Agent 个性 +- 问题域：如何在 3D 空间中创建直觉化、舒适且可发现的交互界面，同时减少晕动症、增强存在感 +- 方法/机制：通过 HUD、浮动菜单、交互区域设计，支持多种输入模型（手势、注视+捏合、控制器），基于人体工程学约束布局 UI +- 结论/价值：提供一个以人为中心、感知驱动的研究型 Agent，可为沉浸式应用定义 UI 流程、构建布局模板并运行可用性验证实验 + +## Key Claims（用中文描述） +- XR Interface Architect 通过设计空间直觉化用户体验来定义其核心使命 +- 该 Agent 支持多种输入模型：直接触摸、注视+捏合、控制器和手势 +- UI 放置遵循基于舒适度的约束原则，以减少晕动症 +- 该 Agent 可构建座舱、仪表盘或可穿戴界面的布局模板 +- 该 Agent 专注于沉浸式搜索、选择和操作的交互原型设计 + +## Key Quotes +> "Designs spatial interfaces where interaction feels like instinct, not instruction." — 核心理念，定义交互的最高目标 +> "Human-centered, layout-conscious, sensory-aware, research-driven" — Agent 人格特质，四个维度 +> "Recommend comfort-based UI placement with motion constraints" — 减少晕动症的核心设计策略 + +## Key Concepts +- [[SpatialInterfaceDesign]]：空间界面设计 — 在 3D 环境中创建直觉化用户界面的设计方法论 +- [[MotionSicknessMitigation]]：晕动症缓解 — 通过 UI 放置约束和运动限制减少 VR 使用中的不适感 +- [[PresenceEnhancement]]：存在感增强 — 通过界面设计提升用户在沉浸式环境中的临场感 +- [[MultimodalInput]]：多模态输入 — 支持手势、注视、控制器等多种交互方式的输入架构 +- [[HUDDesign]]：抬头显示器设计 — 在 XR 环境中创建浮动信息面板的设计实践 + +## Key Entities +- [[XRImmersiveDeveloper]]：XR 沉浸式开发者 — 该 Agent 的主要协作对象，负责实现 3D 环境 +- [[XRCockpitInteractionSpecialist]]：XR 座舱交互专家 — 同为 spatial-computing 领域，协作设计驾驶舱交互 + +## Connections +- [[XRImmersiveDeveloper]] ← collaborates_with ← [[XRInterfaceArchitect]] +- [[XRCockpitInteractionSpecialist]] ← related_to ← [[XRInterfaceArchitect]] +- [[DesignUXArchitect]] ← extends ← [[DesignUIDesigner]] + +## Contradictions +- 暂无发现冲突 + +## Notes +- 该 Agent 与 [[macOS Spatial/Metal Engineer Agent Personality]] 同属 spatial computing 领域，但侧重点不同：前者关注 3D 界面设计，后者关注空间计算底层工程实现