Auto-sync: 2026-04-26 08:02
This commit is contained in:
47
wiki/concepts/AdaptiveMusic.md
Normal file
47
wiki/concepts/AdaptiveMusic.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "Adaptive Music"
|
||||
type: concept
|
||||
tags: [game-audio, music, middleware]
|
||||
sources: [game-audio-engineer]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Adaptive Game Music
|
||||
- Dynamic Music System
|
||||
- Interactive Music
|
||||
|
||||
## Definition
|
||||
|
||||
由游戏状态参数(如 CombatIntensity、Tension、Health)驱动的动态音乐系统。通过音频中间件(FMOD/Wwise)的参数 API,实时调整音乐层切换、混音比例和编曲元素,无需硬切。核心原则:**tempo-synced 转换**(与节拍对齐)和**玩家感受而非意识到**。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
### Tension Parameter(0.0–1.0)
|
||||
| 值 | 游戏状态 | 音乐响应 |
|
||||
|----|---------|---------|
|
||||
| 0.0 | 无敌人/探索 | 仅基础探索层,可无限播放不疲劳 |
|
||||
| 0.3 | 警戒状态 | 鼓点进入 |
|
||||
| 0.6 | 主动战斗 | 完整编曲 |
|
||||
| 1.0 | Boss/危机 | 最高强度层 |
|
||||
|
||||
**来源驱动**:AI threat level aggregator script
|
||||
**更新频率**:每 0.5 秒(lerp 平滑)
|
||||
|
||||
### Music Transition Rules
|
||||
- 必须 tempo-synced(量化为最近节拍边界)
|
||||
- 禁止 hard cuts(除非设计明确要求)
|
||||
- Stem-based horizontal re-sequencing 优先于 vertical layering(内存效率)
|
||||
- 始终保留 neutral/exploration 层可独立无限播放
|
||||
|
||||
## Connections
|
||||
- [[SpatialAudio]]:自适应音乐也需要空间化处理(3D 定位音乐会随玩家位置变化)
|
||||
- [[AudioMiddleware]](FMOD/Wwise):提供参数 API 驱动的实时音乐控制
|
||||
- [[game-audio-engineer]] ← authored_by ← [[GameAudioEngineer]]
|
||||
|
||||
## Related Concepts
|
||||
- [[SpatialAudio]]:空间化音效,与自适应音乐共享中间件架构
|
||||
- [[ProceduralAudio]]:程序化音频可作为自适应音乐的补充层
|
||||
|
||||
## Sources
|
||||
- [[game-audio-engineer]]:完整规范包括 CombatIntensity 参数映射表、音乐集成五阶段流程
|
||||
43
wiki/concepts/Answer-Engine-Optimization.md
Normal file
43
wiki/concepts/Answer-Engine-Optimization.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Answer Engine Optimization (AEO)"
|
||||
type: concept
|
||||
tags: ["AI", "SEO", "marketing", "visibility"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Answer Engine Optimization (AEO) 是针对 AI 问答引擎的优化策略,旨在使品牌内容被 AI 助手(ChatGPT、Claude、Gemini、Perplexity 等)在生成答案时引用。与传统 SEO 不同,AEO 的目标不是让页面在搜索结果中排名靠前,而是让内容成为 AI 合成的"可信来源"。
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. **答案优先**:内容应直接回答用户问题,而非围绕关键词优化
|
||||
2. **结构化权威**:使用 FAQ、步骤指南、对比表格等 AI 友好格式
|
||||
3. **实体清晰**:明确的品牌、产品、概念实体标注
|
||||
4. **来源归属**:让 AI 能准确识别内容归属和可信度
|
||||
|
||||
## AEO vs SEO
|
||||
|
||||
| 维度 | 传统 SEO | AEO |
|
||||
|------|---------|-----|
|
||||
| 目标 | 页面排名 | 被引用为来源 |
|
||||
| 优化对象 | 搜索引擎爬虫 | AI 模型推理 |
|
||||
| 核心信号 | 外链、关键词密度 | 实体清晰度、Schema markup、FAQ 对齐 |
|
||||
| 衡量指标 | 排名、点击率 | Citation Rate、Share of Voice |
|
||||
|
||||
## Key Tactics
|
||||
|
||||
- **FAQ Schema**:添加 FAQPage/FAQQuestion schema markup
|
||||
- **How-To Content**:结构化步骤指南,满足"How to"类查询
|
||||
- **Comparison Pages**:独立的品牌/产品对比页,满足"X vs Y"类查询
|
||||
- **Direct Answers**:在内容开头直接给出答案,而非铺垫
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Generative Engine Optimization (GEO)]]:更广泛的生成式 AI 引擎可见性优化
|
||||
- [[Citation Rate]]:衡量 AEO 效果的量化指标
|
||||
- [[Entity Optimization]]:实体信号强化是 AEO 的核心技术
|
||||
|
||||
## Sources
|
||||
|
||||
- [[AI Citation Strategist]]
|
||||
45
wiki/concepts/Asset-Pipeline.md
Normal file
45
wiki/concepts/Asset-Pipeline.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Asset Pipeline"
|
||||
type: concept
|
||||
tags: [game-dev, asset-pipeline, standards, production]
|
||||
sources: [technical-artist]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# Asset Pipeline
|
||||
|
||||
## Definition
|
||||
Asset Pipeline(资产管线)是定义和管理游戏资产从 DCC 创作到引擎交付全流程的标准体系。涵盖多边形数预算、纹理分辨率规范、LOD 链要求、命名约定和导入预设自动化。
|
||||
|
||||
## Core Standards
|
||||
|
||||
### Texture Compression(纹理压缩标准)
|
||||
| 类型 | PC | Mobile | Console |
|
||||
|------|----|--------|---------|
|
||||
| Albedo | BC7 | ASTC 6×6 | BC7 |
|
||||
| Normal Map | BC5 | ASTC 6×6 | BC5 |
|
||||
| Roughness/AO | BC4 | ASTC 8×8 | BC4 |
|
||||
| UI Sprites | BC7 | ASTC 4×4 | BC7 |
|
||||
|
||||
### Texture Import Rules
|
||||
- 始终以源分辨率导入纹理,由平台特定覆盖系统进行缩放——禁止以降低分辨率导入
|
||||
- UI 和小型环境细节使用纹理图集——独立小纹理是 Draw Call 预算杀手
|
||||
- Mipmap 规则按纹理类型指定:
|
||||
- UI:关闭
|
||||
- 世界纹理:开启
|
||||
- 法线贴图:开启(正确设置)
|
||||
|
||||
### Asset Handoff Protocol
|
||||
- 艺术家在建模前收到每种资产类型的技术规格说明书
|
||||
- 每项资产在目标光照环境下引擎内审查后才批准——不接受 DCC 预览中的审批
|
||||
- 破损 UV、不正确轴心点、非流形几何体在导入时拦截,不在交付时修复
|
||||
|
||||
## Related Concepts
|
||||
- [[LOD-Pipeline]]:LOD 是资产管线标准的关键组成部分
|
||||
- [[Performance-Budget]]:资产管线标准服务于性能预算
|
||||
- [[TextureCompression]]:纹理压缩是资产管线的重要子规范
|
||||
|
||||
## Connections
|
||||
- [[TechnicalArtist]] ← defines ← Asset Pipeline
|
||||
- [[LOD-Pipeline]] ← part of ← Asset Pipeline
|
||||
- [[Performance-Budget]] ← enabled by ← Asset Pipeline
|
||||
43
wiki/concepts/Blockout-Discipline.md
Normal file
43
wiki/concepts/Blockout-Discipline.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Blockout Discipline"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
灰盒纪律(Blockout Discipline)是关卡设计中强制执行的开发流程规范——**设计决策必须在灰盒阶段锁定**,未经灰盒 playtest 验证的布局不得进行美术包装。
|
||||
|
||||
## Three Phases
|
||||
|
||||
### Phase 1: Blockout(灰盒)
|
||||
- 仅使用无纹理的几何体构建关卡
|
||||
- 立即 playtest——灰盒不可读,美术救不了
|
||||
- 验证:新玩家能否在无地图情况下导航?
|
||||
- **设计决策在此阶段锁定**
|
||||
|
||||
### Phase 2: Dress(美术)
|
||||
- 在已验证的灰盒基础上添加美术资产
|
||||
- 标注哪些几何体是 gameplay-critical(不可改变形状)vs. 纯装饰性
|
||||
- 记录每个区域的预期光照方向和色温
|
||||
|
||||
### Phase 3: Polish(打磨)
|
||||
- 添加环境叙事道具
|
||||
- 验证音效是否支持节奏弧线
|
||||
- 使用全新玩家进行最终 playtest——测量时不提供任何帮助
|
||||
|
||||
## Core Rule
|
||||
> "Never art-dress a layout that hasn't been playtested as a grey box."
|
||||
|
||||
## Metric
|
||||
- 100% 的 playtest 参与者在无提示的情况下完成关键路径导航
|
||||
- 节奏图表与实际 playtest 时间误差在 20% 以内
|
||||
|
||||
## Related Concepts
|
||||
- [[Level Designer Agent Personality]]:Blockout Discipline 是 Level Designer 的强制规则
|
||||
- [[Encounter Design]]:Encounter tuning 在灰盒阶段完成
|
||||
- [[Pacing Architecture]]:节奏验证基于灰盒 playtest 数据
|
||||
|
||||
## Sources
|
||||
- [[Level Designer Agent Personality]]
|
||||
45
wiki/concepts/Branching-Narrative.md
Normal file
45
wiki/concepts/Branching-Narrative.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Branching Narrative"
|
||||
type: concept
|
||||
tags: [game-narrative, branching-design, choice-architecture]
|
||||
sources: [narrative-designer.md]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# Branching Narrative
|
||||
|
||||
游戏分支叙事设计——通过选择树结构实现有意义叙事分支的设计方法论。
|
||||
|
||||
## Definition
|
||||
|
||||
Branching Narrative 是一种通过预先定义的选择树结构,让玩家的决策影响故事走向的叙事设计范式。核心挑战在于:如何让选择真正有意义,同时确保所有分支最终收敛而不产生无法维护的指数级内容爆炸。
|
||||
|
||||
## Core Principles
|
||||
|
||||
### 有意义选择的标准
|
||||
- **类型不同,非程度不同**:"I'll help you" vs. "I'll help you later" 不是有意义的选择——两者只是在时间维度上有差异
|
||||
- **选择必须涉及不同的价值观**:玩家在不同的价值体系之间做出取舍,而非同一目标的快慢之分
|
||||
- **后果必须在 2 个场景内可感知**:玩家选择后,必须在近期内看到结果,否则选择失去意义
|
||||
|
||||
### 分支收敛策略
|
||||
- 所有分支必须最终收敛(除非有明确的设计理由不收敛)
|
||||
- 收敛不应显得生硬——通过共同的逻辑基础实现自然合并
|
||||
- Dead ends(死路)需要明确的叙事理由,不能因为结构设计失误导致
|
||||
|
||||
### 节点映射(Node Mapping)
|
||||
- 在写任何对话之前,必须先完成分支节点地图
|
||||
- 每个节点需要标注:输入条件、玩家选择列表、各分支后续节点、收敛点
|
||||
- 禁止在未完成节点映射的情况下直接写对话
|
||||
|
||||
## Key Metrics
|
||||
- **分支密度**:每个主要决策点的平均分支数量(通常 2-4 个)
|
||||
- **收敛率**:从任何分支回溯到主线的平均步骤数
|
||||
- **后果可见性**:玩家感知后果的平均延迟(目标:≤ 2 scenes)
|
||||
|
||||
## Related Concepts
|
||||
- [[Character Voice Pillars]]:分支选择的可信度依赖角色声音的一致性
|
||||
- [[Choice Architecture]]:选择架构定义了何时使用真选择,何时使用 Fake Choice
|
||||
- [[Lore Architecture]]:分支可能通向不同深度的 Lore 层
|
||||
|
||||
## Sources
|
||||
- [[Narrative Designer Agent Personality]] — Branching Design Standards
|
||||
26
wiki/concepts/CACandLTV.md
Normal file
26
wiki/concepts/CACandLTV.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "CAC and LTV"
|
||||
type: concept
|
||||
tags: ["unit-economics", "metrics", "growth", "acquisition"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
客户获取成本(CAC)与生命周期价值(LTV)——增长的核心单位经济学指标组合,用于衡量获客效率是否可持续。LTV:CAC ≥ 3:1 为健康增长门槛;CAC 回本周期 < 6个月。
|
||||
|
||||
## Metrics
|
||||
- **CAC(Customer Acquisition Cost)**:获取一个新客户所需的平均成本 = 总营销支出 / 新增客户数
|
||||
- **LTV(Lifetime Value)**:一个客户在整个生命周期内为产品贡献的总收入 = 平均收入/用户/年 × 平均客户留存年数
|
||||
- **LTV:CAC Ratio**:衡量获客投入产出比,健康值 ≥ 3:1
|
||||
- **CAC Payback Period**:收回获客成本所需时间,健康值 < 6个月
|
||||
|
||||
## Why It Matters
|
||||
增长黑客必须在追求快速增长的同时,确保单位经济学健康——否则增长越快,亏损越大。LTV:CAC 是增长决策的最高优先级指标。
|
||||
|
||||
## Source
|
||||
- [[marketing-growth-hacker]](Marketing Growth Hacker Agent)
|
||||
|
||||
## Aliases
|
||||
- Customer Acquisition Cost
|
||||
- Lifetime Value
|
||||
- Unit Economics
|
||||
80
wiki/concepts/Character-Voice-Pillars.md
Normal file
80
wiki/concepts/Character-Voice-Pillars.md
Normal file
@@ -0,0 +1,80 @@
|
||||
---
|
||||
title: "Character Voice Pillars"
|
||||
type: concept
|
||||
tags: [game-narrative, character-design, dialogue]
|
||||
sources: [narrative-designer.md]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# Character Voice Pillars
|
||||
|
||||
角色声音柱——定义角色语言特征的五个维度体系,确保角色在所有对话中保持声音一致性。
|
||||
|
||||
## Definition
|
||||
|
||||
Character Voice Pillars 是一套用于精确描述角色说话方式的框架,包含五个相互独立又共同构成完整声音形象的维度。通过明确定义每个维度,团队中的所有编剧都能写出风格一致的角色台词。
|
||||
|
||||
## Five Pillars
|
||||
|
||||
### 1. Vocabulary(词汇)
|
||||
- **正式/随意**:角色的语言规范程度
|
||||
- **专业/通俗**:是否使用行业术语、俚语、方言
|
||||
- **情绪强度**:词汇的情感烈度(冷漠旁观 ↔ 情绪激烈)
|
||||
|
||||
### 2. Sentence Rhythm(句子节奏)
|
||||
- **短促/断续**:适合紧迫、强硬、攻击性场景
|
||||
- **绵长/复合**:适合沉思、回忆、哲学性对话
|
||||
- **节奏变化**:单一节奏 vs. 随情绪状态变化
|
||||
|
||||
### 3. Topics Avoided(禁忌话题)
|
||||
- 每个角色都有不愿意直接谈论的领域
|
||||
- 这些禁忌本身就在传递角色信息
|
||||
- 定义禁忌话题比定义擅长话题更重要
|
||||
|
||||
### 4. Verbal Tics(口癖)
|
||||
- 特定短语、重复句式、犹豫词
|
||||
- 角色特有的口头禅或语气词
|
||||
- **注意**:口癖必须服务于角色,不能仅为辨识度而添加
|
||||
|
||||
### 5. Subtext Default(潜台词倾向)
|
||||
- **直白型**:角色说啥就是啥,从不绕弯子
|
||||
- **迂回型**:永远话里有话,需要玩家推断真实意图
|
||||
- **回避型**:在特定敏感话题上故意偏离正题
|
||||
|
||||
## Application
|
||||
|
||||
### Voice Pillar 文档格式
|
||||
```
|
||||
## Character: [Name]
|
||||
### Identity
|
||||
- Role in Story: [Protagonist / Antagonist / Mentor / etc.]
|
||||
- Core Wound: [What shaped this character's worldview]
|
||||
- Desire: [What they consciously want]
|
||||
- Need: [What they actually need, often in tension with desire]
|
||||
|
||||
### Voice Pillars
|
||||
- Vocabulary: [描述]
|
||||
- Sentence Rhythm: [描述]
|
||||
- Topics They Avoid: [列表]
|
||||
- Verbal Tics: [列表]
|
||||
- Subtext Default: [描述]
|
||||
|
||||
### What They Would Never Say
|
||||
[3 example lines that sound wrong for this character]
|
||||
|
||||
### Reference Lines
|
||||
[已批准的语音示例,标注每个示例演示的维度]
|
||||
```
|
||||
|
||||
## Why It Matters
|
||||
- **团队一致性**:多个编剧在不了解彼此时,仍能写出风格统一的对话
|
||||
- **玩家识别度**:90%+ 玩家仅凭对话能正确识别角色性格
|
||||
- **分支可信度**:Branching Narrative 的选择后果感,依赖选择时角色声音的一致性
|
||||
|
||||
## Related Concepts
|
||||
- [[Branching Narrative]]:Voice Pillar 是分支选择可信度的基础
|
||||
- [[Dialogue Writing Standards]]:Voice Pillar 是写作标准的具体化
|
||||
- [[Character Voice Pillars]]:引用自身
|
||||
|
||||
## Sources
|
||||
- [[Narrative Designer Agent Personality]] — Character Voice Pillars Template
|
||||
59
wiki/concepts/Choice-Architecture.md
Normal file
59
wiki/concepts/Choice-Architecture.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "Choice Architecture"
|
||||
type: concept
|
||||
tags: [game-narrative, choice-design, player-agency]
|
||||
sources: [narrative-designer.md]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# Choice Architecture
|
||||
|
||||
选择架构——设计玩家决策系统的学科,涵盖从有意义选择到刻意虚假选择的完整设计空间。
|
||||
|
||||
## Definition
|
||||
|
||||
Choice Architecture 研究如何呈现、组织和框架化玩家的选择。它不只是"给玩家选择"——而是在精确设计的上下文中,通过精确设计的选项集合,引导玩家经历精确设计的心理旅程。
|
||||
|
||||
## Key Techniques
|
||||
|
||||
### 1. 有意义选择(Meaningful Choice)
|
||||
- 玩家在不同价值体系之间做出取舍
|
||||
- 选择后能感受到世界观的变化
|
||||
- 后果在 2 scenes 内可感知
|
||||
|
||||
### 2. 虚假选择(Fake Choice)的刻意使用
|
||||
- **不是设计失误,而是情感工具**
|
||||
- 场景:特定叙事时刻,illusion of agency 比 real agency 更强大
|
||||
- 前提:玩家必须完全信任这个选择是真实的(否则失去情感效力)
|
||||
- 边界:不能在同一游戏中既用 fake choice 又用 real choice(会导致玩家不信任所有选择)
|
||||
|
||||
### 3. 延迟后果(Delayed Consequence)
|
||||
- Act 1 的选择在 Act 3 显现后果
|
||||
- 创造"世界有记忆"的感觉
|
||||
- 需要额外的文档追踪(Narrative Debt Tracking)
|
||||
|
||||
### 4. 后果可见性映射(Consequence Visibility Mapping)
|
||||
| 后果类型 | 可见性 | 设计意图 |
|
||||
|---------|--------|---------|
|
||||
| 即时可见 | 高 | 强化选择-后果因果关系 |
|
||||
| 延迟可见 | 中 | 创造世界记忆感 |
|
||||
| 隐蔽 | 低 | 深层玩家的额外奖励 |
|
||||
|
||||
### 5. 选择频率工程
|
||||
- 不是所有节点都需要选择
|
||||
- 过度选择 = 无选择感
|
||||
- 选择密度应与叙事节奏匹配(高潮时减少选择,思考时增加选择)
|
||||
|
||||
## Narrative Debt Tracking
|
||||
每个延迟后果都是一笔"叙事债务":
|
||||
- **记录**:所有伏笔(foreshadowing)和未兑现的承诺必须记录
|
||||
- **追踪**:在玩家达到收敛点前,必须有机制确保债务被偿还
|
||||
- **退役**:如果某个伏笔无法兑现,需要主动退役(明确告知玩家该线索不再相关)
|
||||
|
||||
## Related Concepts
|
||||
- [[Branching Narrative]]:Choice Architecture 定义何时用真选择
|
||||
- [[Narrative Debt Tracking]]:延迟后果的债务管理机制
|
||||
- [[Player Agency]]:选择架构必须与游戏机制层面的玩家自主权匹配
|
||||
|
||||
## Sources
|
||||
- [[Narrative Designer Agent Personality]] — Choice Architecture and Agency Design
|
||||
38
wiki/concepts/Citation-Rate.md
Normal file
38
wiki/concepts/Citation-Rate.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "Citation Rate"
|
||||
type: concept
|
||||
tags: ["metrics", "AEO", "GEO", "AI", "visibility"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Citation Rate(引用率)是衡量品牌在 AI 推荐引擎中可见性的核心指标,表示品牌在特定 AI 平台的查询中被引用的频率百分比。计算方式:
|
||||
|
||||
```
|
||||
Citation Rate = (品牌被引用次数 / 总查询次数) × 100%
|
||||
```
|
||||
|
||||
## Application
|
||||
|
||||
### Cross-Platform Audit
|
||||
在多平台(ChatGPT、Claude、Gemini、Perplexity)上运行相同查询集,分别计算各平台的 Citation Rate,形成跨平台评分卡。
|
||||
|
||||
### Benchmarking
|
||||
- **Category Average**:同类品牌在 AI 平台上的平均引用率
|
||||
- **Top Competitor Rate**:主要竞争对手的引用率
|
||||
- **Gap**:品牌引用率与竞品/均值之间的差距
|
||||
|
||||
### Tracking
|
||||
定期(建议每 14 天)重新运行相同查询集,追踪 Citation Rate 变化,验证 Fix Pack 实施效果。
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Answer Engine Optimization (AEO)]]:提升 Citation Rate 的策略框架
|
||||
- [[Generative Engine Optimization (GEO)]]:更广泛的生成式 AI 可见性优化
|
||||
- [[Fix Pack]]:提升 Citation Rate 的具体修复包
|
||||
- [[Lost Prompt Analysis]]:识别 Citation Rate 损失来源的方法
|
||||
|
||||
## Sources
|
||||
|
||||
- [[AI Citation Strategist]]
|
||||
60
wiki/concepts/CompletionRate.md
Normal file
60
wiki/concepts/CompletionRate.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "Completion Rate"
|
||||
type: concept
|
||||
tags: [podcast, analytics, metrics]
|
||||
sources: [marketing-podcast-strategist]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# Completion Rate(完成率)
|
||||
|
||||
播客完成率是指听众完整听完一期节目的百分比,是衡量播客内容质量的核心指标。
|
||||
|
||||
## 定义
|
||||
|
||||
$$\text{完成率} = \frac{\text{听完的时长}}{\text{总时长}} \times 100\%$$
|
||||
|
||||
- 行业优秀标准:**> 50%** 完播率
|
||||
- 顶级播客:70%+ 完成率
|
||||
|
||||
## 为什么比播放量更重要
|
||||
|
||||
| 指标 | 反映 | 局限性 |
|
||||
|------|------|--------|
|
||||
| 播放量 | 流量规模 | 可被标题党骗点击,但不反映质量 |
|
||||
| **完成率** | **内容质量 + 听众粘性** | 真正听完的才有价值 |
|
||||
|
||||
核心洞察:*"一个完整听完的 episode 远比一个被跳过的 episode 有价值。"*
|
||||
|
||||
## 驱动完成率的内容策略
|
||||
|
||||
### 音频优先思维(Audio-first Thinking)
|
||||
- 每 10-15 分钟设置一个"钩子"拉回听众注意力
|
||||
- 钩子形式:反直觉观点、故事、数据点、问答
|
||||
- 避免超过 3 分钟的纯理论枯燥段落——将其拆分为两个短段落,中间插入具体案例
|
||||
|
||||
### 开场策略
|
||||
- 通勤场景听众注意力最易漂移
|
||||
- 前 3 分钟必须给出本期节目的价值承诺
|
||||
- 不要在开头做冗长自我介绍
|
||||
|
||||
### 结构设计
|
||||
- 清晰的章节和时间戳
|
||||
- 每个章节有小的主题转换
|
||||
- 结尾有明确的收束和行动号召
|
||||
|
||||
## 与其他指标的关联
|
||||
|
||||
- [[Completion Rate]] ↑ → 听众信任度 ↑ → 品牌合作价值 ↑
|
||||
- [[Completion Rate]] ↑ → 播客平台推荐权重 ↑
|
||||
- [[Completion Rate]] ↑ → 会员/付费转化率 ↑([[Marketing Podcast Strategist]])
|
||||
|
||||
## Connections
|
||||
- [[Marketing Podcast Strategist]] ← authored_by ← [[Completion Rate]] 作为核心内容质量指标
|
||||
- [[Podcast Positioning]] ← optimized_by ← [[Completion Rate]] 数据反馈
|
||||
- [[Audio Production Standards]] ← supports ← [[Completion Rate]]:音质是完成率的基础保障
|
||||
|
||||
## Aliases
|
||||
- 完播率
|
||||
- Episode Completion Rate
|
||||
- 播客完成率
|
||||
32
wiki/concepts/ContentMixStrategy.md
Normal file
32
wiki/concepts/ContentMixStrategy.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "Content Mix Strategy"
|
||||
type: concept
|
||||
tags: [content-strategy, social-media, marketing]
|
||||
sources: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Overview
|
||||
内容配比策略(Content Mix Strategy)是一种社交媒体和内容营销的动态平衡框架,通过设定不同类型内容的比例分配,在品牌传播和用户吸引力之间取得最优平衡。
|
||||
|
||||
## Definition
|
||||
内容配比策略核心公式:**70% 有机生活内容 + 20% 趋势参与 + 10% 品牌直接推广**
|
||||
|
||||
- **有机生活内容(70%)**:与品牌相关的非商业化生活方式内容,建立情感连接和信任
|
||||
- **趋势参与(20%)**:参与平台热门话题、挑战和季节性内容,保持内容新鲜感和平台活跃度
|
||||
- **品牌直接推广(10%)**:明确的品牌/产品推广内容,用于商业转化
|
||||
|
||||
## Rationale
|
||||
- 维持高有机内容比例避免用户疲劳和"广告感"
|
||||
- 适度趋势参与提升算法权重和平台曝光
|
||||
- 少量直接推广确保商业目标达成
|
||||
|
||||
## Application Platforms
|
||||
- [[MarketingXiaohongshuSpecialist]] — 小红书品牌营销的核心内容策略
|
||||
- 可适配 [[MarketingTikTokStrategist]]、 [[MarketingInstagramCurator]] 等其他社交平台
|
||||
- 比例可根据平台特性和品牌调性调整
|
||||
|
||||
## Related Concepts
|
||||
- [[TrendRiding]] — 趋势驾驭(20% 趋势参与内容的方法论)
|
||||
- [[LifestyleBrandPositioning]] — 生活方式品牌定位(70% 有机内容的方向指引)
|
||||
- [[CommunityFirstEngagement]] — 社区优先互动(有机内容的执行策略)
|
||||
@@ -16,7 +16,7 @@ last_updated: 2026-04-26
|
||||
- **归因追踪(Attribution Tracking)**:跟踪用户跨平台旅程,衡量各平台对转化的贡献
|
||||
|
||||
## Platform Strategy Examples
|
||||
| 平台 | 内容类型 | 核心目标 | 适配要点 |
|
||||
|| 平台 | 内容类型 | 核心目标 | 适配要点 |
|
||||
|------|----------|----------|----------|
|
||||
| LinkedIn | 长文/白皮书/行业洞察 | 专业权威建立/B2B 线索 | 正式语调、数据驱动 |
|
||||
| Twitter/X | 即时评论/话题参与/链接 | 实时互动/趋势参与 | 简洁、话题标签 |
|
||||
@@ -24,11 +24,22 @@ last_updated: 2026-04-26
|
||||
| YouTube | 长视频/教程 | 深度参与/SEO | 完播率/留存率优化 |
|
||||
| TikTok | 短视频/挑战 | Z世代触达/病毒传播 | 娱乐优先、3秒黄金钩子 |
|
||||
|
||||
## Key Metrics
|
||||
- 跨平台受众覆盖率
|
||||
- 平台间引流转化率
|
||||
- 品牌声音一致性评分
|
||||
- 归因模型准确度
|
||||
## China-Specific Platform Matrix
|
||||
|
||||
中国市场平台矩阵,每个平台是独立的"国家",内容策略不可跨平台直接复制:
|
||||
|
||||
|| 平台 | 基因定位 | 核心指标 | 漏斗角色 |
|
||||
|------|--------|---------|---------|
|
||||
| 微博 | 公共舆论风暴 | 时效性 > 互动量 > 权威性 | 公域认知 |
|
||||
| 抖音 | 视觉速度 | 完播率 > 点赞 > 评论 > 分享 | 种草/放大 |
|
||||
| 小红书 | 生活方式向往 | 社区审美一致性、KOC 种草 | 种草/决策 |
|
||||
| 知乎 | 权威可信度 | 内容质量、专家背书 | 信任锚定 |
|
||||
| B站 | Z世代深度 | 弹幕互动、UP主关系 | 深度考虑 |
|
||||
| 微信 | 私域关系建设 | 打开率、菜单点击率 | 转化/留存 |
|
||||
| 快手 | 下沉信任 | 老铁关系、社区真实性 | 下沉市场 |
|
||||
|
||||
> **关键原则**:每个平台是独立的生态。[[marketing-china-market-localization-strategist]] 强调:绝不假设在抖音有效的内容在小红书同样有效——每个平台的内容策略必须独立设计,并基于该平台算法机制定制。
|
||||
|
||||
## Sources
|
||||
- [[marketing-social-media-strategist]]
|
||||
- [[marketing-china-market-localization-strategist]]
|
||||
|
||||
83
wiki/concepts/Dialogue-Writing-Standards.md
Normal file
83
wiki/concepts/Dialogue-Writing-Standards.md
Normal file
@@ -0,0 +1,83 @@
|
||||
---
|
||||
title: "Dialogue Writing Standards"
|
||||
type: concept
|
||||
tags: [game-narrative, dialogue, writing]
|
||||
sources: [narrative-designer.md]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# Dialogue Writing Standards
|
||||
|
||||
游戏对话写作标准——确保对话像真实人物说话、每个台词都有明确叙事功能的写作规范体系。
|
||||
|
||||
## Core Rule
|
||||
|
||||
**Every line must pass the "would a real person say this?" test.**
|
||||
|
||||
如果答案是否定的,无论句子多么优雅,都必须重写。
|
||||
|
||||
## Anti-Patterns(必须避免)
|
||||
|
||||
### 1. "As You Know" Dialogue
|
||||
- 角色之间互相解释他们已经知道的事情
|
||||
- 目的:向玩家传递信息,但通过不自然的方式
|
||||
- 真实人物不会这样做——他们已经知道,他们不会互相解释
|
||||
|
||||
**Bad:**
|
||||
> REYES: "As you know, Commander, our base has been under attack for three days and we're running low on supplies."
|
||||
|
||||
**Good:**
|
||||
> REYES: "Three days. I'm told you've been tracking the situation remotely."
|
||||
|
||||
### 2. Exposition Disguised as Conversation
|
||||
- 看起来是对话,实际上是单向信息广播
|
||||
- 一个角色问一个他们明显知道答案的问题,只为让另一个角色解释
|
||||
|
||||
**Bad:**
|
||||
> ALICE: "Tell me, Bob, how did you manage to hack the mainframe?"
|
||||
> BOB: "Well, Alice, I used a brute-force attack combined with a zero-day vulnerability I discovered last week..."
|
||||
|
||||
### 3. Players Overheard Thoughts
|
||||
- 角色说出他们永远不会大声说的内心独白
|
||||
- 除非游戏有旁白系统,否则禁止
|
||||
|
||||
## Required: Dramatic Function
|
||||
|
||||
Every dialogue node must serve at least one of four dramatic functions:
|
||||
1. **Reveal** — 揭示新信息(世界、角色、关系)
|
||||
2. **Establish** — 建立或深化关系
|
||||
3. **Create Pressure** — 制造紧迫感或冲突
|
||||
4. **Deliver Consequence** — 交付玩家之前选择的后果
|
||||
|
||||
如果一句台词不服务于以上任何一个功能,删除它。
|
||||
|
||||
## Three-Pass Editing
|
||||
|
||||
### Pass 1: Function Check
|
||||
- 这个对话节点完成了什么叙事工作?
|
||||
- 它是否连接了前后叙事节点?
|
||||
- 如果删除它,故事是否受影响?
|
||||
|
||||
### Pass 2: Voice Check
|
||||
- 这句台词是否像这个角色说的?
|
||||
- 词汇、节奏、口癖是否符合 Voice Pillar?
|
||||
- 这个角色在这种情况下会不会说这句话?
|
||||
|
||||
### Pass 3: Brevity Check
|
||||
- 删掉每个没有为句子挣到位置的词
|
||||
- 游戏对话通常比电影剧本更紧凑
|
||||
- 玩家不喜欢阅读——让他们说得越少越好
|
||||
|
||||
## Dialogue Tools
|
||||
- Ink / Yarn Spinner / Twine:直接在引擎格式中创作,无需中间转换
|
||||
- String externalization:从第一天就外部化字符串,支持本地化
|
||||
- Gender-neutral fallbacks:提前规划性别适应性
|
||||
- Branching visualization:可视化工具让编辑团队在单一视图中看到完整对话树
|
||||
|
||||
## Related Concepts
|
||||
- [[Character Voice Pillars]]:Voice Pillar 是写作标准的具体化
|
||||
- [[Branching Narrative]]:对话必须在节点映射后从分支结构中写出
|
||||
- [[Narrative-Gameplay Integration]]:对话必须与游戏机制整合
|
||||
|
||||
## Sources
|
||||
- [[Narrative Designer Agent Personality]] — Dialogue Writing Standards
|
||||
39
wiki/concepts/Encounter-Design.md
Normal file
39
wiki/concepts/Encounter-Design.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Encounter Design"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
遭遇战设计(Encounter Design)是在游戏关卡中为战斗、挑战或关键互动节点制定规则与布局的学科。每个遭遇必须可读、公平且令人难忘。
|
||||
|
||||
## Core Standards
|
||||
|
||||
### Three Mandatory Components
|
||||
每个战斗遭遇必须包含:
|
||||
1. **入口读图时间(Entry Read Time)**:玩家在进入遭遇前能看到战场全貌
|
||||
2. **多种战术选项(Multiple Tactical Approaches)**:至少 2 种可行战术,让玩家做有意义的选择
|
||||
3. **退守位置(Fallback Position)**:玩家处于劣势时可以安全撤退或重整的空间
|
||||
|
||||
### Enemy Placement Rules
|
||||
- 禁止将敌人放在玩家进入视野前就能造成伤害的位置(设计好的伏击除外,但必须有预警信号)
|
||||
- 难度必须先从空间(位置和布局)出发,再考虑数值缩放
|
||||
- 所有敌人必须在玩家进入交战范围前可见
|
||||
|
||||
### Difficulty Hierarchy
|
||||
1. **Spatial first**(位置第一):通过敌人位置和掩体布局创造难度
|
||||
2. **Stat scaling second**(数值第二):在空间设计固定后,通过数值调整难度
|
||||
|
||||
## Tensions
|
||||
- **Readability vs. Surprise**:清晰战场 vs. 惊喜伏击,通过 telegraphing(预警)平衡
|
||||
- **Choice vs. Optimal**:多种战术选项 vs. 存在唯一最优解,通过 playtest 验证多样性
|
||||
|
||||
## Related Concepts
|
||||
- [[Flow And Readability]]:Encounter 是 Flow 路径上的节点
|
||||
- [[Blockout Discipline]]:Encounter 在灰盒阶段必须完成可玩性验证
|
||||
- [[Pacing Architecture]]:Encounter 的密度和强度决定整体节奏
|
||||
|
||||
## Sources
|
||||
- [[Level Designer Agent Personality]]
|
||||
60
wiki/concepts/Entity-Optimization.md
Normal file
60
wiki/concepts/Entity-Optimization.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "Entity Optimization"
|
||||
type: concept
|
||||
tags: ["SEO", "AEO", "knowledge-graph", "brand", "visibility"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Entity Optimization(实体优化)是强化品牌实体信号的系统性方法,使 AI 引擎能清晰识别、理解和引用品牌为可信赖的实体。核心洞察:AI 引擎引用的是它们能"理解"和"信任"的实体,而非仅仅是包含关键词的页面。
|
||||
|
||||
## Why Entities Matter for AI
|
||||
|
||||
与传统 SEO(关键词匹配)不同,AI 引擎通过**实体理解**(entity understanding)构建知识表示:
|
||||
- 品牌名 → 语义向量 → 关联概念
|
||||
- 清晰的实体 → 更高的置信度 → 更可能被引用
|
||||
- 模糊的实体 → 低置信度 → 被忽略或被竞品取代
|
||||
|
||||
## Optimization Tactics
|
||||
|
||||
### 1. Consistent Brand Naming
|
||||
在所有自有内容中保持品牌名称、变体、产品名称的一致性使用。
|
||||
- ✅ "Claude, developed by Anthropic"
|
||||
- ❌ "claude" / "Anthropic's AI called 'Claude'"
|
||||
|
||||
### 2. Knowledge Graph Presence
|
||||
在权威知识图谱中建立品牌实体条目:
|
||||
- **Wikipedia**:官方品牌条目(含公司成立、核心产品、市场定位)
|
||||
- **Wikidata**:结构化品牌知识(关联创始人、产品、竞争对手、行业)
|
||||
- **Crunchbase**:商业实体信息(融资轮次、规模、市场)
|
||||
|
||||
### 3. Third-Party Citations
|
||||
在权威第三方来源中获得品牌提及:
|
||||
- 新闻媒体报道
|
||||
- 行业分析报告引用
|
||||
- 学术论文提及
|
||||
|
||||
### 4. Schema Markup
|
||||
在自有网站上使用 Organization 和 Product schema:
|
||||
```json
|
||||
{
|
||||
"@type": "Organization",
|
||||
"name": "Brand Name",
|
||||
"url": "https://brand.com",
|
||||
"sameAs": ["Wikipedia URL", "Crunchbase URL"]
|
||||
}
|
||||
```
|
||||
|
||||
### 5. Wikipedia-style Content
|
||||
创建品牌内容时采用 Wikipedia 的客观、引用支撑、结构清晰风格——AI 训练数据中大量 Wikipedia 内容,使 AI 熟悉并偏好该格式。
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Answer Engine Optimization (AEO)]]:Entity Optimization 是 AEO 的核心技术方向
|
||||
- [[Generative Engine Optimization (GEO)]]:实体信号是 GEO 的五大支柱之一
|
||||
- [[Platform-Specific Patterns]]:不同 AI 平台对实体信号的权重不同
|
||||
|
||||
## Sources
|
||||
|
||||
- [[AI Citation Strategist]]
|
||||
38
wiki/concepts/Environmental-Storytelling.md
Normal file
38
wiki/concepts/Environmental-Storytelling.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "Environmental Storytelling"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
环境叙事(Environmental Storytelling)是通过环境本身讲述故事的设计方法——无需对话、文字或过场动画,玩家仅凭空间布局、道具摆放和光照变化就能推断出世界中发生的事件。
|
||||
|
||||
## Core Principles
|
||||
|
||||
### No Empty Spaces
|
||||
- 每个区域必须通过道具摆放、光照和几何形状讲述故事
|
||||
- 不存在空白的"填充"空间
|
||||
- 破坏、磨损和环境细节必须与世界叙事历史一致
|
||||
|
||||
### Inference-Based Learning
|
||||
- 玩家应该能够在不借助对话或文本的情况下推断出空间中发生了什么
|
||||
- 倒置的家具暗示某人匆忙离开——lean into that(顺着这个讲)
|
||||
- 玩家通过观察环境理解世界,而非被告知
|
||||
|
||||
### Three Storytelling Channels
|
||||
1. **道具摆放(Prop Placement)**:物品位置讲述历史事件
|
||||
2. **光照(Lighting)**:明暗对比传达情绪和焦点
|
||||
3. **几何形状(Geometry)**:空间规模暗示功能和重要性
|
||||
|
||||
## Related Concepts
|
||||
- [[Level Designer Agent]]:Level Designer 是 Environmental Storytelling 的主要执行者(物理空间设计与道具摆放)
|
||||
- [[Narrative Designer Agent]]:Narrative Designer 提供环境叙事的叙事内容架构(道具的叙事意义定义)
|
||||
- [[Spatial Psychology]]:空间如何影响玩家的情感和认知
|
||||
- [[Flow And Readability]]:叙事空间同时必须是可导航的
|
||||
- [[Lore Architecture]]:环境叙事是 Tier 2/3 Lore 的物理呈现
|
||||
|
||||
## Sources
|
||||
- [[Level Designer Agent Personality]]
|
||||
- [[Narrative Designer Agent Personality]]
|
||||
70
wiki/concepts/Five-Phase-Script-Framework.md
Normal file
70
wiki/concepts/Five-Phase-Script-Framework.md
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
title: "Five-Phase Script Framework"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
五阶段话术框架——直播间单品讲解的标准化叙事结构,通过五阶段递进引导观众从「进入直播间」→「了解产品」→「建立信任」→「产生购买紧迫感」→「追加复购」,形成完整的销售闭环。
|
||||
|
||||
## Stages
|
||||
|
||||
### Stage 1: 留人钩子(Retention Hook)
|
||||
**目标**:让观众停止滑动,增加停留时长
|
||||
- 抛出痛点场景引发共鸣
|
||||
- 设置悬念或挑战激发好奇心
|
||||
- 使用互动指令要求观众参与(打字/点赞/关注)
|
||||
- 参考话术:"别划走!今天这个产品,上次我们一上架就秒空了……"
|
||||
|
||||
### Stage 2: 产品介绍(Product Introduction)
|
||||
**目标**:清晰传递产品核心价值
|
||||
- 展示产品实物(演示/试用/对比)
|
||||
- 讲述品牌故事、成分、工艺等差异化信息
|
||||
- 穿插个人使用体验增加真实感
|
||||
- 参考话术:"大家看(展示产品),这个 XX 和普通 XXX 最大的区别是……"
|
||||
|
||||
### Stage 3: 信任建立(Trust Building)
|
||||
**目标**:消除购买顾虑,建立可信度
|
||||
- 展示销售数据/用户评价/权威认证
|
||||
- 引用真实使用前后对比
|
||||
- 回答评论区常见问题
|
||||
- 参考话术:"这不是我一个人在说,大家看(展示销量/评价/证书)……"
|
||||
|
||||
### Stage 4: 紧迫成交(Urgency Close)
|
||||
**目标**:促成立即下单决定
|
||||
- 价格锚点:先揭示零售价,再揭示直播专属价
|
||||
- 稀缺性:限量库存、限时优惠
|
||||
- 社会认同:实时播报已下单人数
|
||||
- 参考话术:"零售价 XXX 元,但今天直播间——XXX 元!而且只有 XX 件库存!3、2、1,上链接!"
|
||||
|
||||
### Stage 5: 追单挽留(Follow-Up Save)
|
||||
**目标**:不流失已表达购买意愿但未成交的观众
|
||||
- 对已下单观众点名感谢,增强社群感
|
||||
- 尝试追加销售(加购/升级套餐)
|
||||
- 预告下一款更大力度产品,留住未下单观众
|
||||
- 参考话术:"已经抢到的朋友打'收到',让我看到你们!还没拍的朋友……下一款更劲爆,留在直播间别走!"
|
||||
|
||||
## Category-Specific Adaptations
|
||||
| 品类 | Stage 1 重点 | Stage 3 重点 |
|
||||
|------|-------------|-------------|
|
||||
| 美妆/护肤 | 皮肤痛点共鸣 | 使用前后对比 |
|
||||
| 食品/生鲜 | 试吃演示 | 产地/质检证明 |
|
||||
| 服饰 | 上身效果 | 尺码/面料说明 |
|
||||
| 家电/3C | 使用场景 | 参数对比/认证 |
|
||||
| 家居 | 生活方式 | 材质/环保认证 |
|
||||
|
||||
## Variations
|
||||
- **5分钟单品节奏**:每个阶段约1分钟,总时长5分钟
|
||||
- **30分钟专题节奏**:每10分钟一个产品循环,含1-2次互动抽奖打断
|
||||
- **大场直播节奏**:引流款(Stage 1为主)→ 主推款(完整5阶段)→ 利润款(Stage 3-4为主)→ 秒杀款(Stage 4为主)
|
||||
|
||||
## Connections
|
||||
- [[Organic Traffic Amplification]] — 五阶段框架中 Stage 1 和 Stage 3 的互动数据直接驱动自然流量推荐
|
||||
- [[Host Incubation System]] — 主播熟练掌握五阶段框架是从「能播」到「能控节奏」的核心技能节点
|
||||
- [[Product Sequencing]] — 五阶段框架需根据产品角色(引流款/主推款/利润款)调整各阶段时间配比
|
||||
- [[Qianchuan Campaign]] — 五阶段脚本转化为付费投放的创意素材,是冷启期最重要的流量转化工具
|
||||
|
||||
## Sources
|
||||
- [[marketing-livestream-commerce-coach]]
|
||||
61
wiki/concepts/Fix-Pack.md
Normal file
61
wiki/concepts/Fix-Pack.md
Normal file
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "Fix Pack"
|
||||
type: concept
|
||||
tags: ["AEO", "GEO", "marketing", "action-plan"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Fix Pack(修复包)是在 AI 引用审计后生成的优先级修复清单,包含具体的内容修改方案和每个修复项的预期引用改善幅度。是 AI Citation Strategist 的核心交付物之一。
|
||||
|
||||
## Structure
|
||||
|
||||
### Header
|
||||
```markdown
|
||||
# Fix Pack: [Brand Name]
|
||||
## Date: [YYYY-MM-DD]
|
||||
```
|
||||
|
||||
### Priority Tiers
|
||||
|
||||
**Priority 1 (P1) — 7 天内实施**
|
||||
- 预期影响最大(+15-25% citation rate)
|
||||
- 解决 3+ 个 Lost Prompts
|
||||
|
||||
**Priority 2 (P2) — 14 天内实施**
|
||||
- 预期影响中等(+10-15% citation rate)
|
||||
- 解决 2-3 个 Lost Prompts
|
||||
|
||||
**Priority 3 (P3) — 30 天内实施**
|
||||
- 预期影响较小(+5-10% citation rate)
|
||||
- 解决 1-2 个 Lost Prompts
|
||||
|
||||
### Fix Item Template
|
||||
|
||||
```markdown
|
||||
### Fix N: [Fix Title]
|
||||
- **Target prompts**: X 个相关 Lost Prompts
|
||||
- **Expected impact**: +X-Y% citation rate on [query type]
|
||||
- **Implementation**:
|
||||
- [具体步骤 1]
|
||||
- [具体步骤 2]
|
||||
- [具体步骤 3]
|
||||
```
|
||||
|
||||
## Prioritization Rule
|
||||
|
||||
**按预期影响排序,而非按实施难易度排序。**
|
||||
|
||||
- 错误做法:先做容易的(改标题、优化元描述),再做难的(新建对比页)
|
||||
- 正确做法:先做影响最大的(Schema markup、FAQ 页),再做影响较小的
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Citation Rate]]:Fix Pack 的效果衡量指标
|
||||
- [[Lost Prompt Analysis]]:识别需要 Fix 的查询场景
|
||||
- [[Answer Engine Optimization (AEO)]]:Fix Pack 修复所依据的策略框架
|
||||
|
||||
## Sources
|
||||
|
||||
- [[AI Citation Strategist]]
|
||||
37
wiki/concepts/Flow-And-Readability.md
Normal file
37
wiki/concepts/Flow-And-Readability.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Flow And Readability"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
关卡流与可读性(Flow And Readability)是游戏关卡设计的核心原则,指玩家在空间中移动时体验到的流畅程度与方向清晰度。**Flow** 强调空间节奏与玩家动线的无缝衔接;**Readability** 强调关卡信息(路径、目标、敌人)的视觉传达是否清晰。
|
||||
|
||||
## Core Principles
|
||||
|
||||
### Critical Path Legibility
|
||||
- 关键路径必须始终视觉可读——玩家应永远不迷路,除非迷路是刻意设计的
|
||||
- 用光照、色彩和几何引导注意力——绝不能将小地图作为主要导航工具
|
||||
- 每个路口必须提供清晰的主动路径和可选的次级奖励路径
|
||||
- 门、出口和目标必须与环境形成对比
|
||||
|
||||
### Spatial Flow Control
|
||||
- 空间节奏控制张力曲线:紧张(Tension)→ 释放(Release)→ 探索(Exploration)→ 战斗(Combat)
|
||||
- 走廊是句子,房间是段落,关卡是完整的论证
|
||||
- 出口在进入房间后 3 秒内必须可见
|
||||
- 关键路径比可选路径光照更亮
|
||||
|
||||
### Navigation Affordance
|
||||
- 可选区域用独特光照或色彩标记(诱惑设计:奖励在岔路口可见)
|
||||
- 路口不能有导航歧义
|
||||
- 没有看起来像出口的死胡同
|
||||
|
||||
## Related Concepts
|
||||
- [[Encounter Design]]:在 Flow 的框架内安放战斗节点
|
||||
- [[Environmental Storytelling]]:Flow 路径上每个空间都有叙事功能
|
||||
- [[Pacing Architecture]]:Flow 是 Pacing 的空间实现
|
||||
|
||||
## Sources
|
||||
- [[Level Designer Agent Personality]]
|
||||
46
wiki/concepts/Generative-Engine-Optimization.md
Normal file
46
wiki/concepts/Generative-Engine-Optimization.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: "Generative Engine Optimization (GEO)"
|
||||
type: concept
|
||||
tags: ["AI", "SEO", "marketing", "visibility", "generative-AI"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Generative Engine Optimization (GEO) 是针对生成式 AI 引擎的可见性优化策略,通过信号工程(signal engineering)提升品牌内容在 AI 生成答案中被引用的概率。GEO 是 AEO(Answer Engine Optimization)的更广泛范畴,不仅限于问答式 AI,而是覆盖所有类型的生成式 AI 引擎。
|
||||
|
||||
## Core Pillars
|
||||
|
||||
1. **Authority Signals**:建立内容权威性(引用来源数量、内容深度、专家署名)
|
||||
2. **Structure Signals**:使用 AI 友好的内容结构(标题层级、列表、表格、Schema)
|
||||
3. **Entity Signals**:清晰的实体标注和知识图谱关联
|
||||
4. **Quantity Signals**:大量相关内容覆盖,增大被 AI 发现和引用的概率
|
||||
5. **Distinctiveness Signals**:差异化内容,避免同质化
|
||||
|
||||
## GEO Techniques
|
||||
|
||||
### Quantitative Expansion
|
||||
创建大量相关主题的补充内容,覆盖长尾查询,增加被 AI 引用的表面积。
|
||||
|
||||
### Quotable Generation
|
||||
生成容易被直接引用的精炼陈述,适合作为 AI 答案中的引用来源。
|
||||
|
||||
### Statistical Amplification
|
||||
在内容中加入数据、统计数字、研究发现——AI 倾向于引用有具体数字支撑的内容。
|
||||
|
||||
### Technical Style Matching
|
||||
研究目标 AI 平台的引用偏好,调整内容风格(ChatGPT 偏好权威性来源,Claude 偏好平衡分析,Perplexity 偏好时效性和多样性)。
|
||||
|
||||
### Source Diversity
|
||||
跨多个平台和渠道发布内容,增大被不同 AI 引擎训练数据覆盖的概率。
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Answer Engine Optimization (AEO)]]:GEO 的子集,专注问答式 AI
|
||||
- [[Citation Rate]]:衡量 GEO 效果的量化指标
|
||||
- [[Entity Optimization]]:GEO 的核心技术之一
|
||||
- [[Platform-Specific Patterns]]:不同 AI 引擎的引用偏好差异
|
||||
|
||||
## Sources
|
||||
|
||||
- [[AI Citation Strategist]]
|
||||
20
wiki/concepts/GrowthFunnelOptimization.md
Normal file
20
wiki/concepts/GrowthFunnelOptimization.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Growth Funnel Optimization"
|
||||
type: concept
|
||||
tags: ["growth", "funnel", "conversion", "retention"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
增长漏斗优化——对用户从认知(Awareness)到推荐(Referral)的全链路转化率进行系统性提升的策略框架。每个阶段都有独立的流失率监控和优化机制。
|
||||
|
||||
## Framework
|
||||
1. **Awareness(认知)**:用户首次接触品牌
|
||||
2. **Acquisition(获客)**:用户完成注册/下载等转化动作
|
||||
3. **Activation(激活)**:用户体验到产品核心价值
|
||||
4. **Retention(留存)**:用户持续使用产品
|
||||
5. **Revenue(收入)**:用户完成付费
|
||||
6. **Referral(推荐)**:用户主动向他人推荐
|
||||
|
||||
## Source
|
||||
- [[marketing-growth-hacker]](Marketing Growth Hacker Agent)
|
||||
67
wiki/concepts/Host-Incubation-System.md
Normal file
67
wiki/concepts/Host-Incubation-System.md
Normal file
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: "Host Incubation System"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
主播孵化体系——将零基础新人从「面对镜头说不出话」培养为「能独立操盘百万GMV直播间」的标准化进阶路径。核心理念:**主播是直播间的灵魂,但不能依赖单一主播——必须建立人才梯队**。
|
||||
|
||||
## Three-Stage Progression Model
|
||||
|
||||
### Stage 1: 素人期(Beginner)
|
||||
**目标**:能稳定直播4小时不冷场
|
||||
|
||||
核心能力训练:
|
||||
- **镜头表现力**:克服镜头恐惧,建立镜头感,能自然面对镜头说话
|
||||
- **基础话术**:能流畅念完产品介绍,不卡壳,不冷场
|
||||
- **情绪节奏**:理解直播间的情绪起伏——前期拉互动→中期推产品→后期逼单
|
||||
- **禁忌词规避**:熟悉平台敏感词规则,不说绝对化表述/功效承诺/虚假对比
|
||||
|
||||
通过标准:连续3场,每场4小时,平均互动率 >2%,无平台违规处罚
|
||||
|
||||
### Stage 2: 成长期(Intermediate)
|
||||
**目标**:能控制节奏并主动驱动转化
|
||||
|
||||
进阶能力训练:
|
||||
- **节奏控制**:能根据在线人数和流量波峰实时调整产品排布和话术密度
|
||||
- **主动转化**:熟练运用五阶段话术框架,在正确节点触发购买指令
|
||||
- **即时反应**:能处理弹幕问题、突发状况(产品问题、网络波动、恶意弹幕)
|
||||
- **数据敏感**:能读懂在线人数曲线,在下降时主动切换策略(福袋/秒杀/换品)
|
||||
|
||||
通过标准:连续5场,GPM >500元,转化率 >2%,能独立处理3次以上突发状况
|
||||
|
||||
### Stage 3: 成熟期(Advanced)
|
||||
**目标**:能吸引自然流量并即兴发挥
|
||||
|
||||
高阶能力训练:
|
||||
- **即兴发挥**:不依赖完整脚本,能根据场景和弹幕即时调整话术
|
||||
- **自然流量运营**:能利用直播间内的互动数据和内容片段(录屏/切片)吸引算法推荐
|
||||
- **团队协同**:能与场控/运营/投手默契配合,实现公域+私域联动
|
||||
- **自我复盘**:能独立分析数据报告,识别问题并提出改进方案
|
||||
|
||||
通过标准:连续10场,月GMV环比增长 >15%,自然流量占比 >40%
|
||||
|
||||
## Mental Resilience Training(主播心理建设)
|
||||
所有阶段均需培养的心理素质:
|
||||
- **冷场应对**:30秒以上冷场必须触发福袋或切换产品,不能尬聊
|
||||
- **恶意弹幕**:不接茬、不回击,设置关键词屏蔽和自动拉黑规则
|
||||
- **直播事故**:设备故障/产品问题等突发情况,保持冷静,按应急预案处理
|
||||
- **数据焦虑**:不以单场GMV论英雄,关注过程指标(话术执行率/节奏控制)
|
||||
|
||||
## Host Management Principles
|
||||
- **话术执行率 > 结果**:评估主播首先看有没有按脚本执行,而非GMV高低
|
||||
- **不依赖单一主播**:主力主播必须配备备播主播,主力休假不影响直播
|
||||
- **排期科学**:单场不超过6小时,峰值时段安排状态最佳主播
|
||||
- **复盘优先于追责**:问题发生后先分析脚本和排品是否合理,再评估个人表现
|
||||
|
||||
## Connections
|
||||
- [[Five-Phase Script Framework]] — 三阶段主播能力模型对应话术框架的掌握深度
|
||||
- [[Organic Traffic Amplification]] — 成熟期主播能通过即兴发挥和互动节奏「制造」自然流量高峰
|
||||
- [[Product Sequencing]] — 成长期以上主播需要理解产品排品逻辑,能根据在线人数实时建议调整
|
||||
- [[marketing-livestream-commerce-coach]] — 本体系是教练 Agent 交付给客户的核心能力建设框架
|
||||
|
||||
## Sources
|
||||
- [[marketing-livestream-commerce-coach]]
|
||||
28
wiki/concepts/KFactor.md
Normal file
28
wiki/concepts/KFactor.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "K-Factor"
|
||||
type: concept
|
||||
tags: ["viral", "metrics", "growth", "referral"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
病毒系数(K-factor)——衡量有机传播效率的指标。K = 邀请率(每个用户平均发送邀请数)× 接受率(每个邀请的平均接受转化率)。K > 1.0 意味着每个用户平均能带来超过一个新增用户,实现指数级自然增长;K < 1.0 则增长需要依赖外部获客渠道。
|
||||
|
||||
## Formula
|
||||
```
|
||||
K-factor = 邀请率 × 接受率
|
||||
= (发送邀请数 / 总用户数) × (接受邀请数 / 发送邀请数)
|
||||
```
|
||||
|
||||
## Interpretation
|
||||
| K-factor | Growth Pattern |
|
||||
|----------|---------------|
|
||||
| K > 1.0 | 指数级自然增长(病毒式传播)|
|
||||
| K = 1.0 | 线性增长(每位用户带来一位新用户)|
|
||||
| K < 1.0 | 需要外部获客渠道补充 |
|
||||
|
||||
## Source
|
||||
- [[marketing-growth-hacker]](Marketing Growth Hacker Agent)
|
||||
|
||||
## Aliases
|
||||
- Viral Coefficient
|
||||
75
wiki/concepts/LOD-Pipeline.md
Normal file
75
wiki/concepts/LOD-Pipeline.md
Normal file
@@ -0,0 +1,75 @@
|
||||
---
|
||||
title: "LOD Pipeline"
|
||||
type: concept
|
||||
tags: [game-dev, asset-pipeline, optimization, performance]
|
||||
sources: [technical-artist]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# LOD Pipeline
|
||||
|
||||
## Definition
|
||||
LOD(Level of Detail,多细节层次)管线是自动管理 3D 模型在不同观看距离下显示精度的系统。当物体远离摄像机时,自动切换到更低多边形数的模型版本,从而节省渲染成本。
|
||||
|
||||
## Core Concept
|
||||
LOD 是**强制流程**——每个英雄网格必须经过 LOD 管线处理,最低要求 LOD0 至 LOD3。
|
||||
|
||||
## LOD Budget Standard(from Technical Artist)
|
||||
|
||||
### Characters(角色)
|
||||
| LOD | 最大多边形数 | 纹理分辨率 | Draw Calls |
|
||||
|-----|------------|-----------|-----------|
|
||||
| LOD0 | 15,000 | 2048×2048 | 2–3 |
|
||||
| LOD1 | 8,000 | 1024×1024 | 2 |
|
||||
| LOD2 | 3,000 | 512×512 | 1 |
|
||||
| LOD3 | 800 | 256×256 | 1 |
|
||||
|
||||
### Environment — Hero Props(英雄道具)
|
||||
| LOD | 最大多边形数 | 纹理分辨率 |
|
||||
|-----|------------|-----------|
|
||||
| LOD0 | 4,000 | 1024×1024 |
|
||||
| LOD1 | 1,500 | 512×512 |
|
||||
| LOD2 | 400 | 256×256 |
|
||||
|
||||
### Small Props(小道具)
|
||||
| LOD | 最大多边形数 |
|
||||
|-----|------------|
|
||||
| LOD0 | 500 |
|
||||
| LOD1 | 200 |
|
||||
|
||||
## LOD Validation Script
|
||||
|
||||
```python
|
||||
LOD_BUDGETS = {
|
||||
"character": [15000, 8000, 3000, 800],
|
||||
"hero_prop": [4000, 1500, 400],
|
||||
"small_prop": [500, 200],
|
||||
}
|
||||
|
||||
def validate_lod_chain(asset_name: str, asset_type: str, lod_poly_counts: list[int]) -> list[str]:
|
||||
errors = []
|
||||
budgets = LOD_BUDGETS.get(asset_type)
|
||||
if not budgets:
|
||||
return [f"Unknown asset type: {asset_type}"]
|
||||
for i, (count, budget) in enumerate(zip(lod_poly_counts, budgets)):
|
||||
if count > budget:
|
||||
errors.append(f"{asset_name} LOD{i}: {count} tris exceeds budget of {budget}")
|
||||
return errors
|
||||
```
|
||||
|
||||
## Critical Rules
|
||||
|
||||
1. **LOD0 强制**:不得交付任何未通过 LOD 管线的资产
|
||||
2. **切换距离验证**:飞行检查所有 LOD 级别的过渡距离,确保无明显 pop-in
|
||||
3. **纹理一致性**:不同 LOD 级别应使用合理的纹理分辨率递减策略
|
||||
4. **导入自动化**:引擎导入预设应覆盖所有资产类别,避免艺术家手动配置
|
||||
|
||||
## Related Concepts
|
||||
- [[Performance-Budget]]:LOD 是控制渲染性能的核心工具
|
||||
- [[AssetPipeline]]:LOD 是资产管线标准的关键组成部分
|
||||
- [[VFX]]:VFX 特效也有 LOD 概念(随距离简化粒子密度)
|
||||
|
||||
## Connections
|
||||
- [[TechnicalArtist]] ← enforces ← LOD Pipeline
|
||||
- [[AssetPipeline]] ← includes ← LOD Pipeline
|
||||
- [[Performance-Budget]] ← achieved by ← LOD Pipeline
|
||||
80
wiki/concepts/Lore-Architecture.md
Normal file
80
wiki/concepts/Lore-Architecture.md
Normal file
@@ -0,0 +1,80 @@
|
||||
---
|
||||
title: "Lore Architecture"
|
||||
type: concept
|
||||
tags: [game-narrative, worldbuilding, lore]
|
||||
sources: [narrative-designer.md]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# Lore Architecture
|
||||
|
||||
Lore 架构——三层可选深度世界构建体系,确保叙事丰富性与可理解性并存。
|
||||
|
||||
## Core Rule
|
||||
|
||||
**Lore is always optional — the critical path must be comprehensible without any collectibles or optional dialogue.**
|
||||
|
||||
玩家不需要探索任何可选内容,也能理解并享受核心故事。
|
||||
|
||||
## Three Tiers
|
||||
|
||||
### Tier 1: Surface(所有玩家)
|
||||
**内容**:关键路径上所有玩家都会遇到的内容
|
||||
|
||||
- 主线过场动画
|
||||
- 关键 NPC 必要对话
|
||||
- 定义世界视觉地标的环境叙事
|
||||
- 定义世界规则的基础设定
|
||||
|
||||
**设计原则**:这部分 Lore 是"地板"——永远不能低于这个质量标准,因为它面向所有人。
|
||||
|
||||
### Tier 2: Engaged(探索者)
|
||||
**内容**:与所有 NPC 交谈、阅读笔记、探索区域的玩家会发现
|
||||
|
||||
- 支线任务对话
|
||||
- 可收集笔记和日志
|
||||
- 可选 NPC 对话
|
||||
- 可发现的环境叙事场景
|
||||
|
||||
**设计原则**:为喜欢深入世界但不追求极致的玩家准备。不强制但值得。
|
||||
|
||||
### Tier 3: Deep(深度 Lore 猎手)
|
||||
**内容**:寻找隐藏房间、秘密物品、元叙事线索的玩家会发现
|
||||
|
||||
- 隐藏文档和加密日志
|
||||
- 需要推理才能理解的环境细节
|
||||
- 连接表面层与探索层看似无关的 Tier 1 和 Tier 2 beat 的深层联系
|
||||
- 揭示游戏真正元叙事的高阶内容
|
||||
|
||||
**设计原则**:为最投入的玩家准备的额外奖励。不能作为理解核心故事的必要条件。
|
||||
|
||||
## World Bible(世界圣经)
|
||||
|
||||
所有 Lore 必须与世界圣经一致——即使是最背景的细节也不例外:
|
||||
|
||||
```markdown
|
||||
## World Bible Quick Reference
|
||||
- Timeline: [关键历史事件和日期]
|
||||
- Factions: [名称、目标、哲学、与玩家关系]
|
||||
- Rules of the World: [什么是可能的,什么不可能——物理/魔法/科技规则]
|
||||
- Banned Retcons: [Tier 1 中已建立的事实,永远不能被矛盾]
|
||||
```
|
||||
|
||||
## Lore 与 Environmental Storytelling 的关系
|
||||
|
||||
- 环境叙事是 Tier 2 Deep 的物理呈现方式
|
||||
- Tier 1 Surface 通过显式叙事(对话、过场)传递
|
||||
- Tier 2/3 通过环境道具的空间布局无声传递
|
||||
|
||||
## Consistency Enforcement
|
||||
- 环境叙事与对话/过场故事之间**零矛盾**
|
||||
- 任何 Lore 更新必须同步到 World Bible
|
||||
- 违反 World Bible 的内容在 Code Review 阶段必须被拦截
|
||||
|
||||
## Related Concepts
|
||||
- [[Environmental Storytelling]]:环境叙事是 Lore 在空间中的物理表达
|
||||
- [[Narrative Debt Tracking]]:Lore 中的伏笔和解承诺需要债务追踪
|
||||
- [[Branching Narrative]]:不同分支可能通向不同深度的 Lore
|
||||
|
||||
## Sources
|
||||
- [[Narrative Designer Agent Personality]] — Lore Architecture
|
||||
50
wiki/concepts/Lost-Prompt-Analysis.md
Normal file
50
wiki/concepts/Lost-Prompt-Analysis.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "Lost Prompt Analysis"
|
||||
type: concept
|
||||
tags: ["AEO", "GEO", "analysis", "competitive-intelligence"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Lost Prompt Analysis(丢失提示分析)是 AI Citation Audit 的核心分析方法之一——系统性地识别品牌应该出现在 AI 答案中但竞争对手胜出的查询场景。通过分析"为什么会输",推导出内容修复方向。
|
||||
|
||||
## Method
|
||||
|
||||
1. **Query Set Generation**:生成 20-40 个目标受众会在 AI 平台输入的查询
|
||||
- 类型:推荐类、对比类、教程类、最佳选择类
|
||||
- 格式:"Best X for Y"、"X vs Y"、"How to choose X"、"Recommend a X"
|
||||
|
||||
2. **Multi-Platform Query**:在 ChatGPT、Claude、Gemini、Perplexity 四个平台分别运行完整查询集
|
||||
|
||||
3. **Result Recording**:记录每次查询中:
|
||||
- 哪个品牌被引用
|
||||
- 引用位置(开头/中间/结尾)
|
||||
- 引用上下文(作为什么类型的来源被引用)
|
||||
|
||||
4. **Gap Identification**:标记品牌缺席但竞品出现的查询 → **Lost Prompts**
|
||||
|
||||
5. **Root Cause Analysis**:对每个 Lost Prompt 分析竞品胜出的原因:
|
||||
- 内容结构(FAQ 页 vs 博客文章)
|
||||
- Schema markup(有无 FAQPage/Product schema)
|
||||
- 实体信号(品牌一致性、知识图谱覆盖)
|
||||
- 内容格式(对比表格 vs 段落叙述)
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
| Prompt | Platform | Who Gets Cited | Why They Win | Fix Priority |
|
||||
|--------|---------|---------------|--------------|-------------|
|
||||
| "Best X for Y" | All 4 | Competitor A | Comparison page with structured data | P1 |
|
||||
| "How to choose X" | ChatGPT, Gemini | Competitor B | FAQ matching query pattern | P1 |
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Fix Pack]]:Lost Prompt Analysis 的产出驱动 Fix Pack 的生成
|
||||
- [[Citation Rate]]:Lost Prompt 数量直接影响整体 Citation Rate
|
||||
- [[Platform-Specific Patterns]]:不同平台 Loss Prompt 的原因可能不同
|
||||
|
||||
## Sources
|
||||
|
||||
- [[AI Citation Strategist]]
|
||||
32
wiki/concepts/MicroInfluencerPartnership.md
Normal file
32
wiki/concepts/MicroInfluencerPartnership.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "Micro Influencer Partnership"
|
||||
type: concept
|
||||
tags: [influencer, marketing, koc, collaboration]
|
||||
sources: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Overview
|
||||
微影响者合作(Micro Influencer Partnership)指品牌与粉丝量级在 1 万至 10 万之间的腰部创作者(KOC,Key Opinion Consumer)建立合作关系,借助其真实感和高互动率为品牌传播背书的营销策略。
|
||||
|
||||
## Definition
|
||||
微影响者的核心特征:
|
||||
- **粉丝量级**:10,000 - 100,000 粉丝
|
||||
- **互动率**:通常高于头部 KOL(5-10% vs 1-3%)
|
||||
- **真实感**:内容更接地气,用户信任度更高
|
||||
- **成本效益**:单次合作成本仅为头部 KOL 的 1/10 至 1/50
|
||||
|
||||
## Why Micro Over Macro
|
||||
- 更高的粉丝信任度和转化率
|
||||
- 更垂直的受众定位(粉丝画像更精准)
|
||||
- 更强的社区互动和真实内容创作
|
||||
- 适合品牌长期关系建设和口碑积累
|
||||
|
||||
## Application
|
||||
- [[MarketingXiaohongshuSpecialist]] — 小红书微影响者合作是社区建设和病毒传播的核心策略
|
||||
- 可扩展至 [[MarketingTikTokStrategist]]、 [[MarketingInstagramCurator]] 等平台
|
||||
|
||||
## Related Concepts
|
||||
- [[UGCCampaign]] — 用户生成内容活动可与微影响者合作协同
|
||||
- [[CommunityFirstEngagement]] — 微影响者是社区互动的关键节点
|
||||
- [[TrendRiding]] — 微影响者是品牌趋势传播的放大器
|
||||
72
wiki/concepts/Narrative-Debt-Tracking.md
Normal file
72
wiki/concepts/Narrative-Debt-Tracking.md
Normal file
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: "Narrative Debt Tracking"
|
||||
type: concept
|
||||
tags: [game-narrative, project-management, storytelling]
|
||||
sources: [narrative-designer.md]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# Narrative Debt Tracking
|
||||
|
||||
叙事债务追踪——管理游戏叙事中"伏笔承诺"与"兑现义务"的系统,防止叙事烂尾和玩家信任流失。
|
||||
|
||||
## Definition
|
||||
|
||||
叙事债务类似于技术债务:你在故事中埋下的伏笔(foreshadowing)和承诺(dangling threads),都是对玩家的隐性承诺。如果不兑现,就欠下了叙事债务。
|
||||
|
||||
## Core Components
|
||||
|
||||
### 1. Foreshadowing(伏笔)
|
||||
- 早期向玩家暗示后期会发生的事件
|
||||
- 必须清晰到玩家能认出,但又模糊到不会猜到具体内容
|
||||
- **示例**:Act 1 中一个看似无害的道具,在 Act 3 中成为关键物品
|
||||
|
||||
### 2. Dangling Threads(悬而未决的线索)
|
||||
- 叙事中引入但尚未解答的问题
|
||||
- 玩家会期待解答——如果等太久,耐心会变成失望
|
||||
- 需要主动管理:在引入悬案之前,先规划好解答时机
|
||||
|
||||
### 3. Promises(承诺)
|
||||
- 叙事向玩家暗示"会发生什么"
|
||||
- **类型**:
|
||||
- Genre promise(类型承诺):动作游戏会有激烈战斗
|
||||
- Character promise(角色承诺):某角色会做出某种选择
|
||||
- World promise(世界承诺):某个地点会有特殊意义
|
||||
|
||||
## Tracking System
|
||||
|
||||
### 必须记录的字段
|
||||
```
|
||||
Foreshadowing ID: [唯一标识]
|
||||
First Appeared: [场景/节点]
|
||||
Nature: [类型:对象/事件/关系/真相]
|
||||
Expected Resolution: [预期场景/节点]
|
||||
Status: [Open / Resolved / Retired]
|
||||
Resolution Note: [如何解决或退役]
|
||||
```
|
||||
|
||||
### Debt Retirement(债务退役)
|
||||
如果某个伏笔因为设计变更无法兑现,必须**主动退役**:
|
||||
1. 在叙事中引入一个场景,说明该线索已不再相关
|
||||
2. 不让它悬在空中——主动关闭比留给玩家自己推理更好
|
||||
3. 记录退役原因,作为团队参考
|
||||
|
||||
## Why It Matters
|
||||
|
||||
- **玩家信任**:不兑现的承诺会让玩家觉得叙事不可信
|
||||
- **发行风险**:叙事债务在游戏上线后难以修复
|
||||
- **团队效率**:早期追踪可避免后期大幅重写
|
||||
|
||||
## Narrative Debt 与 Delayed Consequence
|
||||
|
||||
Narrative Debt Tracking 是 [[Choice Architecture]] 中"延迟后果"设计的执行层:
|
||||
- Choice Architecture 定义**何时**欠下债务(选择时)
|
||||
- Narrative Debt Tracking 管理**如何**偿还债务(交付时)
|
||||
|
||||
## Related Concepts
|
||||
- [[Choice Architecture]]:延迟后果是叙事债务的主要来源
|
||||
- [[Lore Architecture]]:World Bible 中的 Banned Retcons 是永不到期的债务
|
||||
- [[Branching Narrative]]:分支选择必须追踪其后果债务
|
||||
|
||||
## Sources
|
||||
- [[Narrative Designer Agent Personality]] — Transmedia and Living World Narrative / Narrative Debt
|
||||
70
wiki/concepts/Narrative-Gameplay-Integration.md
Normal file
70
wiki/concepts/Narrative-Gameplay-Integration.md
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
title: "Narrative-Gameplay Integration"
|
||||
type: concept
|
||||
tags: [game-narrative, game-design, systems-integration]
|
||||
sources: [narrative-designer.md]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# Narrative-Gameplay Integration
|
||||
|
||||
叙事-玩法整合——确保故事节拍与游戏机制后果对齐的设计矩阵,确保玩家的叙事体验与玩法体验相互强化而非相互剥离。
|
||||
|
||||
## Core Rule
|
||||
|
||||
**Every major story beat must connect to a gameplay consequence or mechanical shift.**
|
||||
|
||||
故事不是插入在游戏之间的东西——故事和游戏是同一个系统的两个维度。
|
||||
|
||||
## Integration Matrix
|
||||
|
||||
| 故事节拍 | 游戏机制后果 | 玩家感受 |
|
||||
|---------|------------|---------|
|
||||
| 盟友背叛 | 失去升级商人访问权限 | 失落感,重新校准 |
|
||||
| 真相揭示 | 解锁新区域,敌人被重新语境化 | 顿悟,紧迫感 |
|
||||
| 角色死亡 | 失去他们教会玩家的机制 | 悲伤,赌注感 |
|
||||
| 玩家选择:宽恕 | 派系声望变化 + 支线任务 | 代理感,后果感 |
|
||||
| 世界事件 | 全球环境 NPC 对话改变 | 世界是活的 |
|
||||
|
||||
## Critical Principles
|
||||
|
||||
### 1. Agency Parity(代理权平等)
|
||||
> "Player agency in story must match player agency in gameplay — don't give narrative choices in a game with no mechanical choices."
|
||||
|
||||
如果游戏机制层面玩家没有选择权,叙事层面也不应该有。选择必须在两个层面同时存在或同时不存在。
|
||||
|
||||
### 2. 叙事引导的教学
|
||||
- 新手引导和 onboarding 内容必须叙事驱动
|
||||
- **错误**:"因为这是教程"——玩家知道这是教程,效果打折
|
||||
- **正确**:"因为角色解释了它"——叙事动机让教学变得自然
|
||||
|
||||
### 3. Emergent Narrative(涌现式叙事)
|
||||
通过系统驱动的叙事,而非全预制脚本:
|
||||
- 派系声望值
|
||||
- 关系数值
|
||||
- 世界状态标志(World State Flags)
|
||||
|
||||
**Narrative Surfacing**:当系统性事件越过阈值时,触发预设叙事评论,让涌现感显得有意图。
|
||||
|
||||
### 4. Authored vs. Emergent 的边界
|
||||
- 玩家必须**注意不到**预制叙事与涌现叙事之间的接缝
|
||||
- 边界必须精心设计,不能让玩家感到"这条叙事不是我触发的"
|
||||
|
||||
## Narrative Query Systems
|
||||
|
||||
世界根据玩家做过的事做出回应:
|
||||
- 系统查询玩家数据 → 生成个性化叙事瞬间
|
||||
- 不只是"你的对话选项变了",而是"世界的反应完全因你而变"
|
||||
|
||||
## Success Metrics
|
||||
- 100% 主要故事节拍有对应游戏机制后果
|
||||
- 玩家调查中,叙事与玩法"一体化"感受评分 ≥ 4.5/5
|
||||
|
||||
## Related Concepts
|
||||
- [[Branching Narrative]]:分支选择的后果是整合矩阵的具体实例
|
||||
- [[Environmental Storytelling]]:环境叙事是无声的机制信号
|
||||
- [[AdaptiveMusic]]:音频层响应叙事节奏,与叙事-玩法整合协同
|
||||
- [[Choice Architecture]]:选择的后果通过整合矩阵实现
|
||||
|
||||
## Sources
|
||||
- [[Narrative Designer Agent Personality]] — Narrative-Gameplay Integration
|
||||
24
wiki/concepts/NorthStarMetric.md
Normal file
24
wiki/concepts/NorthStarMetric.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "North Star Metric"
|
||||
type: concept
|
||||
tags: ["growth", "metrics", "strategy", "product"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
北极星指标——产品为用户创造的核心价值的单一可衡量指标,是增长团队所有工作的最高优先级对齐目标。所有增长实验和策略最终都服务于北极星指标的提升。
|
||||
|
||||
## Criteria for Choosing
|
||||
1. 反映核心用户价值
|
||||
2. 可衡量且可归因
|
||||
3. 是领先指标而非滞后指标
|
||||
4. 全公司都能理解
|
||||
|
||||
## Examples
|
||||
- Facebook:日活跃用户
|
||||
- Airbnb:预订天数
|
||||
- Slack:发送消息数
|
||||
- Uber:出行次数
|
||||
|
||||
## Source
|
||||
- [[marketing-growth-hacker]](Marketing Growth Hacker Agent)
|
||||
62
wiki/concepts/Organic-Traffic-Amplification.md
Normal file
62
wiki/concepts/Organic-Traffic-Amplification.md
Normal file
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "Organic Traffic Amplification"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
自然流量放大——通过优化直播间内的用户行为数据(停留时长、互动率、点击率等),触发平台推荐算法给予更多免费自然流量曝光的策略体系。核心原理:**平台不是根据直播时长分配流量,而是根据直播间内的用户行为数据质量分配流量**。
|
||||
|
||||
## Algorithm Priority Stack
|
||||
平台算法评估直播间的数据优先级(从高到低):
|
||||
1. **停留时长(Watch Time)** — 最核心指标,目标 >60秒
|
||||
2. **互动率(Engagement Rate)** — 评论/点赞/关注/分享的综合比率,目标 >5%
|
||||
3. **商品点击率(Product Click-Through Rate)** — 目标 >10%
|
||||
4. **购买转化率(Purchase Conversion Rate)** — 目标 >3%
|
||||
|
||||
## Tactics by Metric
|
||||
|
||||
### Increasing Watch Time(增加停留时长)
|
||||
- **福袋/抽奖留人**:每15-20分钟运行一次,设置「关注+评论」参与条件
|
||||
- **悬念话术**:「我一直和品牌谈这个价格,还没谈下来,先让大家看看值不值——觉得值的打'值'」
|
||||
- **价格悬念**:「价格先不说,先让大家看产品值不值,2分钟后揭晓!」(保持悬念2-3分钟)
|
||||
- **互动指令**:高频提问让观众打字互动,「用过的打1,没用过的打2」
|
||||
|
||||
### Increasing Engagement Rate(增加互动率)
|
||||
- **高频互动指令**:「觉得好用的点赞点起来,点赞到XX我就降价!」
|
||||
- **选择题互动**:「想要A的扣A,想要B的扣B!让我看看哪边人多!」
|
||||
- **点名欢迎**:「欢迎XXX,感谢关注!」让新进观众感到被看见
|
||||
- **弹幕引导**:「有没有和我一样问题的,有的话评论区扣'1'」
|
||||
|
||||
### Increasing Conversion Rate(增加购买转化率)
|
||||
- **稀缺紧迫感**:「库存只剩XX件,卖完今天就没了」
|
||||
- **价格锚定**:零售价→直播专属价→叠加赠品→最终到手价,分层揭示
|
||||
- **社会认同**:「XX人已经下单了,你们下手真快」
|
||||
- **限时倒计时**:「3、2、1上链接,5秒内下单我再送XX!」
|
||||
|
||||
## Organic Share Targets by Phase
|
||||
| 阶段 | 自然流量占比目标 | 说明 |
|
||||
|------|----------------|------|
|
||||
| 冷启期(0-30场) | < 30% | 重点积累停留时长和互动数据,算法尚未学习账号 |
|
||||
| 成长期(30-100场) | 30-50% | 逐步降低付费依赖,有机开始起量 |
|
||||
| 成熟期(100场+) | > 50% | 健康模型,自然流量成为主要流量来源 |
|
||||
|
||||
## Healthy Organic Model
|
||||
成熟直播间的健康指标:
|
||||
- 自然推荐流量占比 **>50%**
|
||||
- GPM(每千次曝光成交额)**>800元**
|
||||
- UV值(每访客价值)**>1.5元**
|
||||
- 关注转化率 **>3%**
|
||||
|
||||
## Connections
|
||||
- [[Five-Phase Script Framework]] — Stage 1(留人钩子)和 Stage 3(信任建立)的互动数据直接贡献自然流量推荐权重
|
||||
- [[Qianchuan Campaign]] — 付费流量带来精准用户,通过优秀的停留时长和互动数据「撬动」平台给予更多自然流量推荐(付费+有机协同飞轮)
|
||||
- [[Product Sequencing]] — 自然流量波峰出现时,必须有匹配的产品在场——波峰时产品不对,转化白白浪费
|
||||
- [[Host Incubation System]] — 优秀主播能通过话术节奏主动「制造」停留时长和互动高峰,是算法的核心优化变量
|
||||
- [[Douyin]] — 抖音推荐算法对停留时长的权重最高(完播率逻辑)
|
||||
- [[Kuaishou]] — 快手算法对信任关系(老铁互动)的权重更高
|
||||
|
||||
## Sources
|
||||
- [[marketing-livestream-commerce-coach]]
|
||||
41
wiki/concepts/Pacing-Architecture.md
Normal file
41
wiki/concepts/Pacing-Architecture.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "Pacing Architecture"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
节奏架构(Pacing Architecture)是通过空间节奏控制玩家情感体验的设计方法——将张力曲线映射到物理空间中,让玩家在不同区域之间经历紧张、释放、探索、战斗的情感起伏。
|
||||
|
||||
## Pacing Arc Template
|
||||
```
|
||||
Tension → Release → Escalation → Climax → Resolution
|
||||
```
|
||||
每个关卡必须包含完整的情感弧线。
|
||||
|
||||
## Implementation Methods
|
||||
|
||||
### Through Space
|
||||
- 通过房间大小(宏大空间 = 释放,狭窄走廊 = 紧张)
|
||||
- 通过敌人密度(高密度 = 高张力)
|
||||
- 通过视觉开放度(开阔视野 = 安全,低天花板 = 压迫)
|
||||
- 通过光照强度(明亮 = 安全,昏暗 = 危险)
|
||||
|
||||
### Pacing Chart
|
||||
| 时间 | 活动类型 | 张力等级 | 备注 |
|
||||
|------|---------|---------|------|
|
||||
| 0:00 | 探索 | 低 | 环境故事引入 |
|
||||
| 1:30 | 小规模战斗 | 中 | 教授机制 X |
|
||||
| 3:00 | 探索 | 低 | 奖励 + 世界观构建 |
|
||||
| 4:30 | 大规模战斗 | 高 | 在压力下应用机制 X |
|
||||
| 6:00 | 解决 | 低 | 喘息空间 + 出口 |
|
||||
|
||||
## Related Concepts
|
||||
- [[Flow And Readability]]:Pacing 是 Flow 的情感维度
|
||||
- [[Blockout Discipline]]:节奏验证通过灰盒 playtest 完成
|
||||
- [[Encounter Design]]:战斗遭遇的密度和规模决定节奏高潮
|
||||
|
||||
## Sources
|
||||
- [[Level Designer Agent Personality]]
|
||||
67
wiki/concepts/Performance-Budget.md
Normal file
67
wiki/concepts/Performance-Budget.md
Normal file
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: "Performance Budget"
|
||||
type: concept
|
||||
tags: [game-dev, performance, optimization, rendering]
|
||||
sources: [technical-artist]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# Performance Budget
|
||||
|
||||
## Definition
|
||||
Performance Budget(性能预算)是游戏在目标平台上运行时对 GPU/CPU 资源消耗的硬性上限定义。是技术美术最核心的执行原则——所有艺术决策必须在预算约束内进行。
|
||||
|
||||
## Budget Categories
|
||||
|
||||
### Frame Time Budget(帧时间预算)
|
||||
| 平台 | 总帧时间预算 |
|
||||
|------|------------|
|
||||
| Mobile | 16.67ms(60 FPS)|
|
||||
| PC | 16.67ms(60 FPS)|
|
||||
| Console | 11.11ms(90 FPS)|
|
||||
|
||||
### GPU Sub-Budgets
|
||||
| 系统 | Mobile | PC |
|
||||
|------|--------|-----|
|
||||
| 渲染 | 4–8ms | 8–12ms |
|
||||
| VFX | 4ms | 8ms |
|
||||
| 后处理 | 1ms | 2ms |
|
||||
| 预留余量 | 10% | 10% |
|
||||
|
||||
### VFX Particle Budget
|
||||
| 平台 | 最大同时粒子数 | 最大 Overdraw 层数 |
|
||||
|------|-------------|----------------|
|
||||
| Mobile | 500 | 3 |
|
||||
| PC | 2,000 | 6 |
|
||||
|
||||
### Draw Call Budget
|
||||
| 平台 | 建议上限 |
|
||||
|------|---------|
|
||||
| Mobile | 100–200 |
|
||||
| PC | 500–1,000 |
|
||||
|
||||
## Budget Enforcement Rules
|
||||
|
||||
1. **预定义原则**:每种资产类型的预算必须在生产前定义,艺术家在开始制作前知晓限制,而非交付后才发现超标
|
||||
2. **平台特定**:必须为每个目标平台单独定义预算(Mobile/PC/Console)
|
||||
3. **自动化验证**:LOD Chain Validation Script 在导入时自动拦截超标资产
|
||||
4. **定期分析**:GPU Profile 在每个主要内容里程碑后运行,识别 Top-5 渲染成本并优先解决
|
||||
|
||||
## Budget Communication Style
|
||||
|
||||
Technical Artist 的标准语言范式:
|
||||
- "This effect costs **2ms on mobile** — we have **4ms total for VFX**. Approved with caveats."
|
||||
- "Give me the budget sheet **before you model** — I'll tell you exactly what you can afford."
|
||||
- "The texture blowout is a mipmap bias issue — here's the corrected import setting."
|
||||
|
||||
## Related Concepts
|
||||
- [[LOD-Pipeline]]:LOD 是实现性能预算的核心技术手段
|
||||
- [[VFX]]:VFX 系统受粒子数和 Overdraw 预算严格约束
|
||||
- [[AssetPipeline]]:资产标准是性能预算的前置保障
|
||||
- [[RenderingPipeline]]:渲染管线的每个 Pass 都消耗帧时间预算
|
||||
|
||||
## Connections
|
||||
- [[TechnicalArtist]] ← enforces ← Performance Budget
|
||||
- [[VFX]] ← constrained by ← Performance Budget
|
||||
- [[LOD-Pipeline]] ← achieves ← Performance Budget
|
||||
- [[AssetPipeline]] ← enables ← Performance Budget
|
||||
55
wiki/concepts/PodcastPositioning.md
Normal file
55
wiki/concepts/PodcastPositioning.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Podcast Positioning"
|
||||
type: concept
|
||||
tags: [podcast, content-strategy, marketing]
|
||||
sources: [marketing-podcast-strategist]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# Podcast Positioning(播客定位)
|
||||
|
||||
播客定位是指为播客节目确定清晰的受众、内容方向和差异化策略,是播客运营的基础决策。
|
||||
|
||||
## 定位四象限
|
||||
|
||||
| 类型 | 描述 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| **垂直知识**(Vertical Knowledge) | 深度垂直领域专业内容 | 建立专业权威,吸引精准受众 |
|
||||
| **对话访谈**(Interview/Conversation) | 嘉宾驱动的对话内容 | 利用嘉宾影响力扩大受众覆盖 |
|
||||
| **叙事故事**(Narrative Storytelling) | 纪录片/小说类叙事 | 强情感连接,高完播率潜力 |
|
||||
| **闲聊日常**(Casual Chat) | 轻松随意的日常对话 | 陪伴感强,粘性高 |
|
||||
|
||||
## 核心要素
|
||||
|
||||
### 目标听众画像
|
||||
- 年龄、职业、兴趣标签
|
||||
- 收听场景(通勤/运动/睡前/做家务)
|
||||
- 内容偏好和付费意愿
|
||||
|
||||
### 差异化策略
|
||||
- 找到独特的"声音人格"(Voice Persona)
|
||||
- 找到独特的"内容角度"(Content Angle)
|
||||
- 拒绝模糊的"我们什么都聊"定位
|
||||
|
||||
### 品牌要素
|
||||
- 节目名称:简短、易记、有辨识度
|
||||
- 封面设计:缩略图尺寸下仍清晰可辨
|
||||
- 节目描述:清晰的内容价值主张
|
||||
|
||||
## 关键原则
|
||||
|
||||
> **默认要求**:每个节目必须有清晰的内容价值主张和明确的目标受众。
|
||||
|
||||
- 清晰的 [[Content Calendar]] 规划(常青内容 + 热点内容 + 系列内容 + 实验内容)
|
||||
- 避免"万金油"定位——越聚焦越容易建立忠实听众群
|
||||
- 内容价值 proposition 必须具体到一句话能说清楚
|
||||
|
||||
## Connections
|
||||
- [[Content Calendar]] ← depends_on ← [[Podcast Positioning]]:定位决定内容规划方向
|
||||
- [[Completion Rate]] ← measured_by ← [[Podcast Positioning]]:定位清晰度影响听众留存
|
||||
- [[Marketing Podcast Strategist]] ← authored_by ← [[Podcast Positioning]] 实践框架
|
||||
|
||||
## Aliases
|
||||
- 播客定位
|
||||
- Show Positioning
|
||||
- 节目定位
|
||||
56
wiki/concepts/Post-Processing.md
Normal file
56
wiki/concepts/Post-Processing.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "Post-Processing"
|
||||
type: concept
|
||||
tags: [game-dev, rendering, visual-quality]
|
||||
sources: [technical-artist]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# Post-Processing
|
||||
|
||||
## Definition
|
||||
Post-Processing(后处理)是在场景渲染完成后对最终图像应用的一系列屏幕空间效果,用于提升视觉质量和艺术风格表达。典型效果包括 Bloom(泛光)、色差、晕影、颜色分级等。
|
||||
|
||||
## Core Effects
|
||||
|
||||
### Bloom / Glow
|
||||
模拟真实世界中光源的溢出光晕效果。常用于霓虹灯、魔法特效、火光等发光物体。实现方式:对高亮度区域进行下采样模糊,与原图叠加。
|
||||
|
||||
### Chromatic Aberration(色差)
|
||||
模拟镜头色散产生的边缘色彩分离效果,增加电影感和真实感。
|
||||
|
||||
### Vignette(晕影)
|
||||
画面边缘渐暗,引导观众视线到中心。强度可调。
|
||||
|
||||
### Color Grading(颜色分级)
|
||||
通过 LUT(Look-Up Table)调整整体色调和对比度。可导出 DaVinci Resolve 或 Photoshop 中的调色方案,导入为 3D LUT 资源。
|
||||
|
||||
### Temporal Anti-Aliasing (TAA) + Sharpening
|
||||
TAA 通过历史帧混合减少锯齿,但会导致快速移动物体的鬼影(ghosting)问题。使用锐化(DLSS/XeSS 集成)可恢复 TAA 损失的细节。
|
||||
|
||||
## Platform-Specific Profiles
|
||||
|
||||
| 效果 | Console | PC | Mobile |
|
||||
|------|---------|----|--------|
|
||||
| Bloom | 重度(Film grain + Heavy bloom)| 中度 | 关闭 |
|
||||
| Chromatic Aberration | 轻度 | 轻度 | 关闭 |
|
||||
| Color Grading | LUT 完整版 | LUT 简化版 | 关闭 |
|
||||
| Film Grain | 开启 | 可选 | 关闭 |
|
||||
|
||||
## Modular Stack Design
|
||||
|
||||
模块化后处理栈允许效果独立切换:
|
||||
- Pass 1: Bloom(可独立开关)
|
||||
- Pass 2: Chromatic Aberration(可独立开关)
|
||||
- Pass 3: Vignette(可独立开关)
|
||||
- Pass 4: Color Grading(可独立开关)
|
||||
|
||||
## Related Concepts
|
||||
- [[VFX]]:VFX 与后处理栈协同——发光特效依赖 Bloom Pass
|
||||
- [[Shader]]:后处理基于全屏着色器(Screen-Space Shader)
|
||||
- [[PerformanceBudget]]:每个 Pass 都消耗帧时间预算,需评估收益/成本比
|
||||
|
||||
## Connections
|
||||
- [[TechnicalArtist]] ← designs ← Post-Processing
|
||||
- [[VFX]] ← enhances via ← Post-Processing
|
||||
- [[Shader]] ← implements ← Post-Processing
|
||||
42
wiki/concepts/Procedural-Level-Design.md
Normal file
42
wiki/concepts/Procedural-Level-Design.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Procedural Level Design"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
程序化关卡设计(Procedural Level Design)是通过算法规则自动或半自动生成游戏关卡的学科。目标是建立保证最低质量阈值的规则集,让程序生成的内容达到手工程度的标准。
|
||||
|
||||
## Core Components
|
||||
|
||||
### Grammar Definition(语法定义)
|
||||
为生成系统建立规则语法:
|
||||
- **Tiles(瓦片)**:基本构建单元
|
||||
- **Connectors(连接器)**:瓦片之间的连接规则
|
||||
- **Density Parameters(密度参数)**:控制内容分布的参数
|
||||
- **Guaranteed Content Beats(保证内容节拍)**:必须出现的关键节点
|
||||
|
||||
### Critical Path Anchors(关键路径锚点)
|
||||
- 手工打造的关键路径锚点必须被程序化系统尊重
|
||||
- 锚点决定整体结构,算法填充中间空间
|
||||
- 锚点位置通常由叙事或游戏设计要求决定
|
||||
|
||||
### Quality Validation(质量验证)
|
||||
程序化输出必须通过自动化指标验证:
|
||||
- **Reachability(可达性)**:所有区域是否可达
|
||||
- **Key-Door Solvability(钥匙门可解性)**:是否有足够的钥匙对应所有锁
|
||||
- **Encounter Distribution(遭遇分布)**:战斗密度是否合理
|
||||
|
||||
## Trade-offs
|
||||
- **Diversity vs. Consistency**:程序生成的多样性 vs. 保持游戏风格一致性
|
||||
- **Surprise vs. Control**:意外惊喜 vs. 设计师对最终质量的控制
|
||||
|
||||
## Related Concepts
|
||||
- [[Level Designer Agent Personality]]:程序化设计是 Level Designer 的高级能力
|
||||
- [[Blockout Discipline]]:程序化系统生成的灰盒仍需遵循 blockout 纪律
|
||||
- [[Flow And Readability]]:程序生成的空间必须满足可读性标准
|
||||
|
||||
## Sources
|
||||
- [[Level Designer Agent Personality]]
|
||||
30
wiki/concepts/ProductLedGrowth.md
Normal file
30
wiki/concepts/ProductLedGrowth.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "Product-Led Growth"
|
||||
type: concept
|
||||
tags: ["product", "growth", "activation", "retention"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
产品导向增长(PLG)——通过产品体验本身驱动用户获取和留存,而非依赖营销渠道或销售团队。用户通过产品感受到核心价值后,自然完成注册、付费和推荐。
|
||||
|
||||
## Core Principles
|
||||
- **免费优先(Freemium/免费试用)**:降低用户尝试门槛
|
||||
- **产品内病毒传播**:分享功能、协作功能内置于产品体验
|
||||
- **激活率优化**:关注新用户首周激活率(目标 60%+)
|
||||
- **留存驱动**:产品持续提供价值,让用户养成使用习惯
|
||||
|
||||
## PLG vs Sales-Led Growth
|
||||
| Dimension | PLG | Sales-Led |
|
||||
|-----------|-----|-----------|
|
||||
| 核心驱动力 | 产品体验 | 销售团队 |
|
||||
| 用户获取 | 有机/口碑 | 营销/广告 |
|
||||
| 转化路径 | 用户自主探索 | 销售引导 |
|
||||
| 适用场景 | B2C/SaaS | B2B/企业 |
|
||||
|
||||
## Source
|
||||
- [[marketing-growth-hacker]](Marketing Growth Hacker Agent)
|
||||
|
||||
## Aliases
|
||||
- PLG
|
||||
- Product-Led Growth
|
||||
51
wiki/concepts/Shader.md
Normal file
51
wiki/concepts/Shader.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Shader"
|
||||
type: concept
|
||||
tags: [game-dev, rendering, graphics]
|
||||
sources: [technical-artist]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# Shader
|
||||
|
||||
## Definition
|
||||
Shader(着色器)是在 GPU 上运行的专用程序,控制像素如何被渲染——决定颜色、光照、阴影、透明度等视觉特性。游戏开发中最常用的语言为 HLSL(DirectX/PC)、GLSL(OpenGL/Linux)和 ShaderLab(Unity)。
|
||||
|
||||
## Core Concepts
|
||||
|
||||
### Vertex Shader
|
||||
逐顶点执行,负责几何变换(模型空间 → 世界空间 → 视图空间 → 屏幕空间)和传递顶点属性(UV、法线)。
|
||||
|
||||
### Fragment/Pixel Shader
|
||||
逐像素执行,决定最终像素颜色。性能敏感操作应优先考虑移至 Vertex Shader。
|
||||
|
||||
### Surface Shader(Unity 概念)
|
||||
Unity URP/HDRP 的高级抽象,自动处理光照模型,开发者只需定义表面属性。
|
||||
|
||||
### Compute Shader
|
||||
通用 GPU 计算,可用于后处理、特效、布料模拟等非传统渲染任务。
|
||||
|
||||
## Technical Artist 的 Shader 标准
|
||||
|
||||
- **移动端安全变体**:所有自定义着色器必须包含移动端安全版本或明确标注平台限制
|
||||
- **Shader 复杂度分析**:使用引擎的 Shader 复杂度可视化工具验证,绿色/黄色合格,红色必须修订
|
||||
- **参数文档化**:暴露给艺术家的所有着色器参数必须在材质检查器中有 Tooltip 注释
|
||||
- **避免逐像素操作**:可在顶点阶段完成的操作不应放在像素阶段(移动端尤其重要)
|
||||
|
||||
## Shader 类型与预算
|
||||
|
||||
| 类型 | PC 复杂度 | Mobile 复杂度 | 典型应用 |
|
||||
|------|-----------|---------------|---------|
|
||||
| Unlit | 极低 | 极低 | UI、纯色物体 |
|
||||
| Lit (PBR) | 中等 | 中等-高 | 角色、环境 |
|
||||
| 透明/加法 | 中等 | 高 | VFX、玻璃 |
|
||||
| 自定义光照 | 高 | 极高 | 特殊效果 |
|
||||
|
||||
## Related Concepts
|
||||
- [[VFX]]:Shader 常用于 VFX 特效实现
|
||||
- [[LOD-Pipeline]]:LOD 切换时着色器需保持视觉一致性
|
||||
- [[RenderingPipeline]]:Shader 是渲染管线的可编程核心
|
||||
|
||||
## Connections
|
||||
- [[TechnicalArtist]] ← writes ← Shader
|
||||
- [[VFX]] ← implements via ← Shader
|
||||
40
wiki/concepts/Spatial-Psychology.md
Normal file
40
wiki/concepts/Spatial-Psychology.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Spatial Psychology"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
空间心理学(Spatial Psychology)是将人类对空间的先天感知规律应用于游戏关卡设计的学科。通过理解玩家如何在空间中定位、感受安全或危险,设计者可以创造直觉上可读且情感上有效的环境。
|
||||
|
||||
## Core Theories
|
||||
|
||||
### Prospect-Refuge Theory(前景-庇护理论)
|
||||
- 玩家在拥有俯瞰位置且背后有保护时感到安全
|
||||
- 设计原则:提供高处的观察位置(prospect)和受保护的背部(refuge)
|
||||
|
||||
### Figure-Ground Contrast(图底对比)
|
||||
- 目标必须在视觉上从背景中突显
|
||||
- 通过色彩、亮度或几何形状差异创造视觉层次
|
||||
|
||||
### Kevin Lynch's Urban Design Principles
|
||||
城市设计五要素应用于游戏空间:
|
||||
1. **Paths(路径)**:玩家穿行的主动线
|
||||
2. **Edges(边界)**:空间分界线(墙、围栏、水体)
|
||||
3. **Districts(区域)**:具有统一特征的功能分区
|
||||
4. **Nodes(节点)**:路径交汇点(高密度决策点)
|
||||
5. **Landmarks(地标)**:视觉锚点,远距离可识别
|
||||
|
||||
### Forced Perspective(强制透视)
|
||||
- 利用视觉错觉操纵玩家对距离和规模的感知
|
||||
- 可以让狭小空间显得宏大,或让遥远目标显得可及
|
||||
|
||||
## Related Concepts
|
||||
- [[Flow And Readability]]:Spatial Psychology 支撑路径可读性
|
||||
- [[Environmental Storytelling]]:空间感知是叙事体验的基础
|
||||
- [[Level Designer Agent Personality]]:Spatial Psychology 是 Level Designer 的高级能力
|
||||
|
||||
## Sources
|
||||
- [[Level Designer Agent Personality]]
|
||||
59
wiki/concepts/SpatialAudio.md
Normal file
59
wiki/concepts/SpatialAudio.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "Spatial Audio"
|
||||
type: concept
|
||||
tags: [game-audio, 3d, spatialization]
|
||||
sources: [game-audio-engineer]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- 3D Audio
|
||||
- 3D Spatialization
|
||||
- World-space Audio
|
||||
- Positional Audio
|
||||
|
||||
## Definition
|
||||
|
||||
基于 3D 空间化的音效定位与衰减系统。所有世界空间音效(diegetic sounds)必须使用 3D 空间化,通过 raycast 驱动的 occlusion/obstruction 参数和 reverb zone 匹配,实现物理真实的听音体验。核心原则:**所有世界空间音效必须使用 3D 空间化,场景音效不得使用 2D 播放**。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
### Attenuation(衰减)
|
||||
| 参数 | 说明 |
|
||||
|------|------|
|
||||
| Minimum Distance | 满音量距离(米) |
|
||||
| Maximum Distance | 不可听距离(米) |
|
||||
| Rolloff | Logarithmic(真实)/ Linear(风格化)——按游戏指定 |
|
||||
|
||||
### Occlusion & Obstruction
|
||||
- **方法**:从 listener 到声源的 raycast
|
||||
- **参数**:`Occlusion`(0=开放,1=完全遮挡)
|
||||
- **最大遮挡**:低通滤波截止频率 800Hz
|
||||
- **每帧限制**:最多 4 个 raycast(跨帧错开更新)
|
||||
|
||||
### Reverb Zone 规格
|
||||
| 区域类型 | Pre-delay | 混响时间 | Wet % |
|
||||
|---------|-----------|---------|-------|
|
||||
| Outdoor | 20ms | 0.8s | 15% |
|
||||
| Indoor | 30ms | 1.5s | 35% |
|
||||
| Cave | 50ms | 3.5s | 60% |
|
||||
| Metal Room | 15ms | 1.0s | 45% |
|
||||
|
||||
Reverb zone 必须与视觉环境匹配。
|
||||
|
||||
## Advanced: HRTF & Ambisonics
|
||||
- **HRTF**(Head-Related Transfer Functions):用于真实仰角定位,在第一人称/VR 上下文中提供更真实的音频空间感
|
||||
- **FOA**(First-Order Ambisonics):VR 音频首选,从 B-format 到耳机双耳解码
|
||||
- **关键原则**:资产以单声道制作,让空间引擎处理 3D 定位——永远不要预烘焙立体声定位
|
||||
|
||||
## Connections
|
||||
- [[AdaptiveMusic]] ← extends ← [[SpatialAudio]]:音乐系统也受益于空间化(玩家移动时音乐视角变化)
|
||||
- [[AudioMiddleware]](FMOD/Wwise):提供空间化 API
|
||||
- [[game-audio-engineer]] ← authored_by ← [[GameAudioEngineer]]
|
||||
|
||||
## Related Concepts
|
||||
- [[AdaptiveMusic]]:自适应音乐系统,与空间音频共享中间件基础设施
|
||||
- [[Ambisonics]]:高阶空间音频格式(作为 Spatial Audio 的进阶形式)
|
||||
|
||||
## Sources
|
||||
- [[game-audio-engineer]]:完整规范包括 Attenuation 参数表、Occlusion raycast 策略、Reverb Zone 规格表、HRTF/FOA 高级配置
|
||||
40
wiki/concepts/Speedrun-Design.md
Normal file
40
wiki/concepts/Speedrun-Design.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Speedrun Design"
|
||||
type: concept
|
||||
tags: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
速通设计(Speedrun Design)是在关卡设计中考虑精通玩家快速通关路径的实践,同时确保休闲路径不会因此受到惩罚。是一种"高级玩家友好"但不"强制所有玩家追求速度"的设计哲学。
|
||||
|
||||
## Core Principles
|
||||
|
||||
### Sequence Break Auditing(序列断裂审计)
|
||||
- 审查每个关卡的非预期序列断裂(unintended sequence breaks)
|
||||
- 分类:有意快捷方式(intended shortcuts)vs. 设计漏洞(design exploits)
|
||||
- 有意快捷方式 → 保留并标记为技能奖励
|
||||
- 设计漏洞 → 修复或转化为有意设计
|
||||
|
||||
### Dual Path Design(双路径设计)
|
||||
- **Optimal path(最优路径)**:奖励精通,但不强制
|
||||
- **Casual path(休闲路径)**:普通玩家体验不变,不感到被惩罚
|
||||
- 两种路径都应该是完整、有意义的游戏体验
|
||||
|
||||
### Hidden Skip Routes(隐藏跳过路线)
|
||||
- 为细心观察的玩家设计可发现的跳过路线
|
||||
- 作为技能奖励而非强制要求
|
||||
- 速通社区反馈作为免费的高级玩家设计审查
|
||||
|
||||
## Advanced Considerations
|
||||
- 竞技游戏: spectator clarity(观众可读性)——关键瞬间必须对旁观者可见
|
||||
- 测试要求:pub play(大众游戏)和 organized play(竞技游戏)暴露完全不同的问题
|
||||
|
||||
## Related Concepts
|
||||
- [[Level Designer Agent Personality]]:Speedrun Design 是 Level Designer 的高级能力
|
||||
- [[Flow And Readability]]:速通路径不能破坏主路径的可读性
|
||||
- [[Encounter Design]]:速通最优战术必须在 encounter 设计中可实现
|
||||
|
||||
## Sources
|
||||
- [[Level Designer Agent Personality]]
|
||||
82
wiki/concepts/Trend-To-Action.md
Normal file
82
wiki/concepts/Trend-To-Action.md
Normal file
@@ -0,0 +1,82 @@
|
||||
---
|
||||
title: "Trend-To-Action"
|
||||
type: concept
|
||||
tags: [china, marketing, trend-analysis, gtm, data-driven, closed-loop]
|
||||
sources: [marketing-china-market-localization-strategist]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Trend-To-Action(中国市场趋势行动框架)是一种将实时趋势信号转化为可执行商业行动的系统性闭环方法论,专为中国市场高动态、快迭代的数字营销环境设计。核心循环:**信号采集 → 深度分析 → 策略设计 → GTM 执行 → 测量迭代**,每一步都有量化指标和决策节点。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
### Dual-Track Analysis(双轨分析)
|
||||
|
||||
同时运行两条分析线,从不同维度提取市场机会:
|
||||
|
||||
**内容轨(Content Track)**:
|
||||
- 高互动格式识别(什么内容结构最吸睛)
|
||||
- 趋势关键词提取(搜索量/热度数据)
|
||||
- 供需缺口发现(未被满足的需求)
|
||||
|
||||
**评论轨(Comment Track)**:
|
||||
- 需求词(Need Words):用户直接表达的需求
|
||||
- 痛点(Pai
|
||||
|
||||
n Points):用户抱怨的高频问题
|
||||
- 风险词(Risk Words):需规避的敏感词和负面联想
|
||||
- 情感模式(Sentiment Patterns):正向/负向/中性的情感分布
|
||||
|
||||
### Five Deliverable Categories
|
||||
|
||||
每轮 Trend-To-Action 分析周期输出五类交付物:
|
||||
|
||||
1. **选品与上新优先级**(Product Selection & Launch Priority)
|
||||
2. **卖点假设与痛点提炼**(Selling Points & Pain Points)
|
||||
3. **内容模板与脚本结构**(Content Templates & Scripts)
|
||||
4. **风险词与客服话术**(Risk Words & Customer Service FAQs)
|
||||
5. **可执行清单与优先级**(Executable Checklists with Priority Levels)
|
||||
|
||||
## Four Signal Detection Models(趋势信号检测四模型)
|
||||
|
||||
应用于所有数据集的四种心智模型:
|
||||
|
||||
| 模型 | 中文名 | 核心含义 |
|
||||
|------|--------|---------|
|
||||
| Signal Detection | 见微知著 | 在排名靠后的话题中发现即将爆发的弱信号 |
|
||||
| Triangulation | 交叉验证 | 用热榜数据(大众情绪)和专业 RSS(专家信号)交叉验证 |
|
||||
| Counter-Intuitive | 反直觉思考 | 识别共识错误中隐藏的机会 |
|
||||
| MECE Structuring | MECE 结构化 | 确保分析相互独立、穷尽无遗 |
|
||||
|
||||
## Execution Priority Levels
|
||||
|
||||
每条建议必须附带优先级:
|
||||
|
||||
| 级别 | 含义 | 响应时间 |
|
||||
|------|------|---------|
|
||||
| P0 | 核心机会,立即行动 | 24-48h |
|
||||
| P1 | 重要机会,本周执行 | 1 周 |
|
||||
| P2 | 中等机会,下月纳入 | 2-4 周 |
|
||||
| P3 | 探索性机会,持续观察 | 月度复盘 |
|
||||
| P4-P5 | 长尾机会,资源允许则跟进 | 季度审视 |
|
||||
|
||||
## Closed-Loop Measurement
|
||||
|
||||
Trend-To-Action 的关键特征是**闭环**:
|
||||
|
||||
- 每个行动都有预设的"成功/停止"阈值
|
||||
- 示例:第 3 天互动率 < 2% → 停止内容;> 5% → DOU+ 投放 ¥500
|
||||
- 每月更新机会矩阵:淘汰过期信号,提升新兴信号
|
||||
- 所有学习成果文档化,形成复合智能积累
|
||||
|
||||
## Relationship to Other Concepts
|
||||
|
||||
- [[Phased-GTM-Gate]]:Trend-To-Action 的输出注入六阶段 GTM 门控模型
|
||||
- [[Cross-Platform-Strategy]]:Trend-To-Action 框架在每个平台独立运行,但统一汇报到全局机会矩阵
|
||||
- [[Real-Time-Trend-Intelligence]]:Trend-To-Action 的输入层,为其提供信号数据
|
||||
- [[China-Consumer-Psychology]]:Trend-To-Action 分析时的文化背景参照系
|
||||
|
||||
## Sources
|
||||
- [[marketing-china-market-localization-strategist]]
|
||||
31
wiki/concepts/TrendRiding.md
Normal file
31
wiki/concepts/TrendRiding.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "Trend Riding"
|
||||
type: concept
|
||||
tags: [trending, content-strategy, social-media]
|
||||
sources: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Overview
|
||||
趋势驾驭(Trend Riding)是一种内容营销策略,指品牌或创作者主动识别、参与和利用平台热门趋势(话题、标签、音乐、挑战),以提升内容曝光和用户参与度的技术。
|
||||
|
||||
## Definition
|
||||
趋势驾驭的核心能力包括:
|
||||
- **实时趋势识别**:在趋势出现后 24 小时内识别并创作相关内容
|
||||
- **趋势预测**:分析数据模式预测即将爆发的趋势
|
||||
- **微趋势创建**:开发品牌特定的话题标签挑战,推动病毒传播
|
||||
- **季节性策略**:利用节假日和文化节点获取最大相关性
|
||||
|
||||
## Key Metrics
|
||||
- 参与趋势的内容互动率通常比非趋势内容高 3-5 倍
|
||||
- 品牌专属趋势(UGC 挑战)可带来持续的有机增长
|
||||
|
||||
## Application
|
||||
- [[MarketingXiaohongshuSpecialist]] — 小红书趋势驾驭是品牌增长的核心驱动力
|
||||
- [[MarketingTikTokStrategist]] — TikTok 趋势生态同样高度依赖趋势参与
|
||||
- [[MarketingSocialMediaStrategist]] — 跨平台社交媒体策略中趋势驾驭是关键技能
|
||||
|
||||
## Related Concepts
|
||||
- [[ContentMixStrategy]] — 趋势参与占内容配比的 20%
|
||||
- [[MicroInfluencerPartnership]] — 与微影响者合作可放大趋势传播
|
||||
- [[UGCCampaign]] — 品牌话题挑战是趋势驾驭的高级形式
|
||||
66
wiki/concepts/VFX.md
Normal file
66
wiki/concepts/VFX.md
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: "VFX"
|
||||
type: concept
|
||||
tags: [game-dev, visual-effects, particles, performance]
|
||||
sources: [technical-artist]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# VFX
|
||||
|
||||
## Definition
|
||||
VFX(Visual Effects,视觉特效)是游戏运行时实时生成的非静态视觉效果,通过粒子系统、着色器和后处理技术实现。典型应用包括爆炸、烟雾、火焰、魔法光效、环境氛围等。
|
||||
|
||||
## Performance Budget(Technical Artist 强制标准)
|
||||
|
||||
### 粒子数量上限
|
||||
| 平台 | 最大同时粒子数 |
|
||||
|------|-------------|
|
||||
| Mobile | 500 |
|
||||
| PC | 2,000 |
|
||||
|
||||
### 过度绘制(Overdraw)上限
|
||||
过度绘制是移动端性能隐性杀手。
|
||||
|
||||
| 平台 | 最大 Overdraw 层数 |
|
||||
|------|-----------------|
|
||||
| Mobile | 3 |
|
||||
| PC | 6 |
|
||||
|
||||
### 混合模式策略
|
||||
- **Alpha Clip**:优先使用,效率最高
|
||||
- **Additive Blending**:仅在预算批准后使用
|
||||
- 半透明/加法粒子必须经过审计并设定上限
|
||||
|
||||
## VFX 制作流程
|
||||
|
||||
1. **建立 Profile 场景**:GPU 计时器可见的测试环境中构建所有 VFX
|
||||
2. **粒子数上限前置**:在构建开始时就设置每个粒子系统的上限,而非完成后调整
|
||||
3. **多角度测试**:60° 摄像机角度和远距离缩放均需验证,不只依赖英雄视角
|
||||
4. **平台目标验证**:每个效果必须明确标注目标平台(PC/Console/Mobile)
|
||||
|
||||
## VFX Shader 类型
|
||||
- **Particle Shader**:粒子纹理采样,颜色插值,UV 动画
|
||||
- **Dissolve Shader**:按噪声贴图阈值切割模型边缘,带发光描边
|
||||
- **UV Scroll Shader**:河流/熔岩等流动效果
|
||||
- **Procedural Noise Shader**:云/烟/雾等程序化生成效果
|
||||
|
||||
## Audit Checklist(from Technical Artist)
|
||||
|
||||
- [ ] 最坏情况粒子数量已测量
|
||||
- [ ] Overdraw 可视化工具已检查层数
|
||||
- [ ] Shader 复杂度图已验证
|
||||
- [ ] 粒子纹理已放入共享图集
|
||||
- [ ] GPU Profile 最坏密度下帧时间已记录
|
||||
- [ ] 帧时间贡献已与平台预算对比
|
||||
|
||||
## Related Concepts
|
||||
- [[Shader]]:VFX 通过自定义 Shader 实现高级效果
|
||||
- [[Performance-Budget]]:VFX 的核心约束来自帧时间预算
|
||||
- [[LOD-Pipeline]]:VFX 距离 LOD 切换需保持可读性
|
||||
- [[Post-Processing]]:VFX 与后处理栈(Bloom、泛光)协同
|
||||
|
||||
## Connections
|
||||
- [[TechnicalArtist]] ← builds ← VFX
|
||||
- [[Shader]] ← implements ← VFX(VFX 特效通过着色器实现)
|
||||
- [[Performance-Budget]] ← constrains ← VFX
|
||||
23
wiki/concepts/ViralLoop.md
Normal file
23
wiki/concepts/ViralLoop.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Viral Loop"
|
||||
type: concept
|
||||
tags: ["viral", "referral", "network-effect", "growth"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
病毒裂变机制——通过推荐程序、分享激励和网络效应,使用户在产品使用过程中自发向他人传播,从而实现零成本指数级用户增长的机制。K-factor = 邀请率 × 接受率,K > 1.0 意味着指数级自然增长。
|
||||
|
||||
## Core Components
|
||||
- **邀请机制**:内置分享入口,降低分享摩擦
|
||||
- **激励设计**:邀请人和被邀请人双方都获得价值
|
||||
- **接受率优化**:落地页体验、注册流程优化
|
||||
- **K-factor 追踪**:每次迭代后重新测量 K-factor
|
||||
|
||||
## Source
|
||||
- [[marketing-growth-hacker]](Marketing Growth Hacker Agent)
|
||||
|
||||
## Aliases
|
||||
- Viral Growth Loop
|
||||
- Referral Loop
|
||||
- Self-Reinforcing Growth
|
||||
Reference in New Issue
Block a user