Auto-sync: 2026-04-26 00:02

wiki/concepts/Content-Matrix-Strategy.md

@@ -0,0 +1,41 @@
+---
+title: "Content Matrix Strategy（内容矩阵策略）"
+type: concept
+tags: [content-marketing, short-video, multi-platform]
+sources: [marketing-douyin-strategist]
+last_updated: 2026-04-25
+---
+
+## Definition
+内容矩阵策略是通过在单一平台或跨平台布局多种内容类型的账号组合，实现流量来源多元化、用户触点覆盖最大化的内容运营方法论。
+
+## Core Framework
+在抖音平台，典型内容矩阵包含四类内容：
+
+| 类型 | 目的 | 典型时长 | 完播率目标 |
+|------|------|----------|------------|
+| 教育类 | 建立专业权威 | 30-60s | > 40% |
+| 剧情类 | 情感共鸣 | 15-30s | > 35% |
+| 产品测评类 | 种草转化 | 30-45s | > 38% |
+| Vlog类 | 人设打造 | 60-120s | > 30% |
+
+## Key Principles
+- **主账号**负责品牌定位和高价值内容
+- **子账号**承担垂类渗透和长尾流量
+- **员工账号**提供真实背书和日常互动
+- 内容类型之间互相引流，形成闭环
+
+## Applications
+- 抖音/快手短视频矩阵
+- 微信公众号/视频号矩阵
+- 小红书多品类账号矩阵
+- TikTok 海外市场矩阵
+
+## Related Concepts
+- [[MarketingDouyinStrategist]]：抖音平台内容矩阵的具体执行 Agent
+- [[CompletionRateOptimization]]：内容矩阵中每条视频的优化目标
+
+## Aliases
+- 内容矩阵
+- Content Matrix
+- Multi-format Content Strategy

wiki/concepts/Context-Passing.md

@@ -0,0 +1,25 @@
+---
+title: "Context Passing"
+type: concept
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Context Passing（上下文传递）是多 Agent 协作中的记忆共享机制：Agent 之间不存在共享记忆，下一个 Agent 必须显式接收上一个 Agent 的完整输出作为输入上下文。
+
+## Details
+- **实现方式**：手动 copy-paste 或由 Orchestrator Agent 自动传递
+- **关键原则**：不要摘要，要使用完整输出
+- **与 [[Sequential Handoff]] 的关系**：Context Passing 是 Sequential Handoff 的技术基础
+
+## Aliases
+- Context Passing
+- 上下文传递
+
+## Related Patterns
+- [[Sequential Handoff]]
+- [[Orchestrator Agent]]（未来可自动化此过程）
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/concepts/Feedback-Loop.md

@@ -0,0 +1,39 @@
+---
+title: "Feedback Loop"
+type: concept
+tags: [multi-agent, workflow-pattern, iteration, quality-assurance]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+后续 Agent（通常是 Reviewer/QA 角色）对前序 Agent 的产出进行审查，生成具体改进建议，前序 Agent 根据反馈修改后再交付的迭代机制。
+
+## Core Principle
+
+反馈必须是**具体的、可执行的**，而非泛泛的评价。"CTA 按钮颜色对比度不够"比"设计不够好"有价值一万倍。
+
+## Usage in The Agency
+
+- [[workflow-landing-page]]：Growth Hacker 审查 HTML 后给出具体修改意见 → Frontend Developer 15:30 前应用反馈并交付最终版本
+- [[workflow-startup-mvp]]：QA Auditor 检查第一版 → Dev 根据 Bug 报告修复 → Re-audit 循环直到达标
+- [[support-analytics-reporter]]：Analytics Reporter 生成报告 → 用户反馈 → 调整分析维度
+
+## Structure
+
+```
+[Agent A 产出 v1] → [Reviewer Agent B 审查] → [具体改进建议]
+       ↑                                              ↓
+       └──────────── [Agent A 修改后交付 v2] ←───────┘
+```
+
+## Key Requirements
+
+1. **Reviewer 必须独立于 Creator**——自己评审自己的产出无效
+2. **反馈必须有具体量化指标**——"降低 50ms 加载时间"比"优化性能"有用
+3. **时间盒必须保护修改时间**——反馈没有时间完成修改等于无效
+
+## Aliases
+- Review-Iterate Cycle
+- Quality Assurance Loop
+- Iteration Cycle

wiki/concepts/Golden-3-Second-Hook.md

@@ -0,0 +1,55 @@
+---
+title: "Golden 3-Second Hook（黄金3秒钩子）"
+type: concept
+tags: [short-video, copywriting, attention-economy, douyin]
+sources: [marketing-douyin-strategist]
+last_updated: 2026-04-25
+---
+
+## Definition
+黄金3秒钩子是指短视频开头3秒内通过特定的创作技巧，在算法推荐之前就抓住观众注意力的开场设计策略。是抖音/短视频完播率优化的第一道关卡。
+
+## Four Hook Types
+
+### A. 冲突型（Conflict Hook）
+**公式**："除非你看完这个，否则不要做XXX"
+**原理**：制造认知冲突，触发好奇心
+**示例**："买二手房之前没看这个视频，你亏大了"
+
+### B. 价值型（Value Hook）
+**公式**："XX元解决了困扰我X年的问题"
+**原理**：具体数字锚定价值感
+**示例**："花200块解决了困扰我三年的失眠问题"
+
+### C. 悬念型（Suspense Hook）
+**公式**："XX行业有一个他们不想让你知道的秘密"
+**原理**：信息不对称引发窥探欲
+**示例**："服装店老板打死不会告诉你的砍价技巧"
+
+### D. 共鸣型（Relatability Hook）
+**公式**："有没有人和我一样，每次XXX就崩溃？"
+**原理**：情感共鸣触发评论互动
+**示例**："有没有人和我一样，一刷手机就停不下来"
+
+## Relationship to Completion Rate
+- 钩子决定前三秒留存
+- 前三秒留存影响算法初始流量池评级
+- 初始评级决定是否进入更大的流量池
+- **因此：钩子质量决定整条视频的天花板**
+
+## Key Metrics
+- 前3秒跳出率（< 20% 为优秀）
+- 5秒完播率（> 50% 为优秀）
+- 与整体完播率正相关
+
+## Related Concepts
+- [[CompletionRateOptimization]]：黄金钩子是完播率优化的核心组成部分
+- [[ContentMatrixStrategy]]：不同内容类型适用不同钩子策略
+- [[VideoPacing]]：钩子之后的内容节奏同样关键
+
+## Aliases
+- 黄金3秒
+- 开头钩子
+- Hook
+- Attention Hook
+- 短视频开场策略

wiki/concepts/Memory-Based-Handoff.md

@@ -0,0 +1,28 @@
+---
+title: "Memory-Based Handoff"
+type: concept
+tags: [multi-agent, memory, handoff, workflow]
+last_updated: 2026-04-26
+---
+
+## Definition
+
+一种多 Agent 协作中的交接模式，通过外部记忆服务器（而非人工复制粘贴）实现 Agent 间的上下文传递。当一个 Agent 完成工作时，将交付物存储到共享记忆服务器；下一个 Agent 通过 recall 操作自动检索所需上下文，无需人工干预。
+
+## Core Mechanism
+
+1. **存储（remember）**：Agent 完成任务后，将交付物快照存入记忆服务器，带上项目标签（如 `retroboard`）和接收方标签（如 `frontend-developer`）
+2. **召回（recall）**：下一个 Agent 激活时，通过 recall 操作按标签检索历史记忆，自动获取上一个 Agent 的交付物
+3. **无需人工粘贴**：人类不再充当"粘合剂"，记忆服务器接管上下文传递
+
+## Aliases
+- Memory-Based Handoff
+- MCP Memory Handoff
+
+## Related Patterns
+
+- [[Sequential Handoff]]：前身模式——必须人工复制粘贴完整输出，Memory-Based Handoff 将其升级为自动召回
+- [[Memory-Based Handoff]] ← enabled_by ← [[MCP Memory Server]]
+
+## Source
+- [[workflow-with-memory]]：完整工作流文档，包含 4 周 MVP 场景下的 Memory-Based Handoff 实践

wiki/concepts/Merge-Point.md

@@ -0,0 +1,32 @@
+---
+title: "Merge Point"
+type: concept
+tags: [multi-agent, workflow-pattern, dependency-management]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+工作流中的特定节点——多个并行分支的输出在此处合并，触发下一阶段的执行。所有上游分支必须在此点完成。
+
+## Core Principle
+
+下游 Agent 明确声明其所需的**上游输出集合**，只有当全部上游输出就绪后，才开始工作。这是 Multi-Agent 协作中的关键依赖管理机制。
+
+## Usage in The Agency
+
+- [[workflow-landing-page]]：**Frontend Developer** 的合并点是 `Content Creator 输出 + UI Designer 输出`。两者未完成之前，Frontend Developer 无法开始。
+- [[workflow-startup-mvp]]：**Build Phase** 是合并点，需要 API Spec（Backend Architect）+ UI Spec（UI Designer）+ 增长计划（Growth Hacker）全部就绪
+- [[scenario-enterprise-feature]]：**Integration Phase** 需要 Backend 输出 + Frontend 输出 + QA 测试计划全部合并
+
+## Anti-Pattern
+
+不要将合并点设计为"等待最慢的一个"——应该在设计阶段就估算各分支的执行时间，必要时：
+- 对快速分支添加有价值的额外任务（如性能基准测试）
+- 对慢速分支进行拆分加速
+- 将非关键输出从合并点移除
+
+## Aliases
+- Convergence Point
+- Synchronization Barrier
+- Handoff Point

wiki/concepts/Multi-Agent-Orchestration.md

@@ -0,0 +1,33 @@
+---
+title: "Multi-Agent Orchestration"
+type: concept
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Multi-Agent Orchestration（多 Agent 编排）指通过预定义的 Agent 角色、交接顺序和质量门控，将多个专业 Agent 组织为流水线化协作体系的过程。
+
+## Details
+- **核心组件**：
+  1. 角色定义（Sprint Prioritizer、UX Researcher、Backend Architect 等）
+  2. 交接协议（[[Sequential Handoff]] + [[Context Passing]]）
+  3. 并行策略（[[Parallel Agent Work]]）
+  4. 质量保证（[[Quality Gate]]）
+- **自动化前景**：引入 [[Orchestrator Agent]] 可替代手动编排，实现全自动化流水线
+- **适用场景**：复杂多角色协作任务（SaaS 开发、内容生产、研究分析等）
+
+## Aliases
+- Multi-Agent Orchestration
+- 多 Agent 编排
+- Agent Orchestration
+- Agent 编排
+
+## Related Patterns
+- [[Sequential Handoff]]
+- [[Parallel Agent Work]]
+- [[Quality Gate]]
+- [[Context Passing]]
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/concepts/Parallel-Agent-Work.md

@@ -0,0 +1,25 @@
+---
+title: "Parallel Agent Work"
+type: concept
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Parallel Agent Work（并行 Agent 工作）指多个独立 Agent 在同一阶段同时激活，各自处理不相互依赖的任务，从而压缩项目时间线。
+
+## Details
+- **应用场景**：Week 1 中，Sprint Prioritizer 和 UX Researcher 可并行激活
+- **条件**：两个 Agent 的任务无相互依赖，可独立产出
+- **收益**：将 2 个串行步骤合并为 1 个时间单位，节省约 50% 时间
+
+## Aliases
+- Parallel Agent Work
+- 并行 Agent 工作
+
+## Related Patterns
+- [[Sequential Handoff]]
+- [[Context Passing]]
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/concepts/Parallel-Kickoff.md

@@ -0,0 +1,38 @@
+---
+title: "Parallel Kickoff"
+type: concept
+tags: [multi-agent, workflow-pattern, parallelization]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+多个独立 Agent 任务在同一时间并行启动，彼此之间没有数据依赖，无需等待对方完成即可开始执行。
+
+## Core Principle
+
+只有当两个工作流**产出互相独立**时，才适合并行启动。如果一个任务的输出是另一个的输入，则必须串行。
+
+## Usage in The Agency
+
+- [[workflow-landing-page]]：Content Creator 与 UI Designer 在上午 9:00 同时启动，两者输出（文案 + 设计稿）互不依赖
+- [[workflow-startup-mvp]]：Backend Architect、Frontend Developer、Growth Hacker 在 Week 2 并行启动
+- [[scenario-marketing-campaign]]：文案、视觉、增长策略并行输出
+
+## Implementation
+
+```
+Agent A ──┐
+          ├──► [合并点]
+Agent B ──┘
+```
+
+并行启动的条件：
+1. 两者输出没有依赖关系
+2. 两者不写入同一个共享状态（除非有锁机制）
+3. 执行时间相近（避免一个等待另一个过长）
+
+## Aliases
+- Parallel Activation
+- Concurrent Kickoff
+- Independent Parallel Execution

wiki/concepts/Quality-Gate.md

@@ -0,0 +1,27 @@
+---
+title: "Quality Gate"
+type: concept
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Quality Gate（质量门控）是在关键里程碑设置的质量评估检查点，由 [[Reality Checker]] 评估产出是否满足继续推进的条件，防止有缺陷的代码或计划进入下一阶段。
+
+## Details
+- **典型位置**：
+  1. Week 2 中点——评估是否能在剩余 2 周内完成
+  2. Week 4 发布前——评估生产就绪状态（GO/NO-GO）
+- **评估维度**：时间可行性、功能裁剪建议、技术债务风险
+- **决策结果**：GO（可继续）或 NO-GO（需回滚修复）
+
+## Aliases
+- Quality Gate
+- 质量门控
+
+## Related Patterns
+- [[Reality Checker]]（具体执行角色）
+- [[Sequential Handoff]]
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/concepts/Sequential-Handoff.md

@@ -0,0 +1,27 @@
+---
+title: "Sequential Handoff"
+type: concept
+sources: [workflow-startup-mvp]
+last_updated: 2026-04-25
+---
+
+## Definition
+Sequential Handoff（顺序交接）是 [[workflow-startup-mvp]] 中定义的多 Agent 协作核心模式：每个 Agent 的完整输出作为下一个 Agent 的输入，形成流水线。
+
+## Details
+- **原则**：不摘要、不压缩，完整粘贴上一 Agent 的输出
+- **原因**：Agent 之间无共享记忆，必须显式传递完整上下文
+- **与 [[Context Passing]] 的关系**：Context Passing 是实现 Sequential Handoff 的具体技术手段
+
+## Aliases
+- Sequential Handoff
+- 顺序交接
+- Sequential Hand-off
+
+## Related Patterns
+- [[Context Passing]]
+- [[Quality Gate]]
+- [[Parallel Agent Work]]
+
+## Sources
+- [[workflow-startup-mvp]]

wiki/concepts/Time-Boxing.md

@@ -0,0 +1,42 @@
+---
+title: "Time Boxing"
+type: concept
+tags: [project-management, workflow-pattern, scope-control]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+为每个工作阶段设定严格的时间上限（Time Box），无论该阶段是否"完成"，时间到达后必须停止并交付当前状态，进入下一阶段。
+
+## Core Principle
+
+Time Boxing 是对抗"完美主义"和"范围蔓延"的武器——在敏捷/Scrum 中广泛使用，在 Multi-Agent 工作流中同样有效。
+
+## Usage in The Agency
+
+- [[workflow-landing-page]]：每个 Agent 任务都有明确的时间盒
+  - 09:00–11:00：Content Creator + UI Designer（2小时并行）
+  - 11:00–14:00：Frontend Developer 构建（3小时）
+  - 14:00：完成第一版
+  - 14:00–14:30：Growth Hacker 审查（30分钟）
+  - 15:30：应用反馈完成
+  - 16:30：交付上线
+- [[workflow-startup-mvp]]：每周一个阶段有明确交付物截止日期
+- [[scenario-incident-response]]：P0 事件 15 分钟必须恢复，P1 1 小时内解决
+
+## Why Time Box Works
+
+1. **催促决策**：没有无限时间，团队必须优先处理最重要的部分
+2. **可预测节奏**：所有参与者知道何时会有产出
+3. **避免过度工程**：不追求完美的 100 分，而是在时间限制内交付 80 分的价值
+4. **促进迭代**：第一版快速上线 → 收集真实反馈 → 下一轮 Time Box 改进
+
+## Anti-Pattern
+
+不要将 Time Boxing 变成"赶工"的借口。每个 Time Box 内部应该有明确的**最小可用产出（MVP）定义**，确保即使提前完成也能交付有价值的东西。
+
+## Aliases
+- Fixed Time Window
+- Time Limit Discipline
+- Sprint