Auto-sync: 2026-04-20 07:08

wiki/concepts/AECR-Framework.md

@@ -0,0 +1,42 @@
+---
+title: "AECR Framework"
+type: concept
+tags: [sales, objection-handling, methodology]
+---
+
+## 定义
+销售异议处理框架，包含四个步骤：Acknowledge（认可）、Empathize（共情）、Clarify（澄清）、Reframe（重构）。
+
+## 四步处理流程
+
+### 1. Acknowledge（认可）
+- 目的：验证担忧但不争论
+- 示例："这是个合理的担忧。我经常听到这样的说法。"
+
+### 2. Empathize（共情）
+- 目的：展示理解买家为何这样感觉
+- 示例："可以理解——如果我坐在你的位置，之前也吃过[类似方案]的亏，我也会持怀疑态度。"
+
+### 3. Clarify（澄清）
+- 目的：提问理解表面异议背后的真实异议
+- 示例：
+  - "您能帮我了解一下您对[话题]的具体担忧是什么？"
+  - "您说时机不对，是预算周期问题、带宽问题，还是其他原因？"
+
+### 4. Reframe（重构）
+- 目的：基于所了解的信息提供新视角
+- 示例："我听到的是[真实担忧]。以下是您这种情况的其他团队是如何考虑的..."
+
+## 常见异议分布
+| 类别 | 频率 | 真实含义 |
+|------|------|----------|
+| 预算/价值 | 48% | "我不相信 ROI 证明成本合理"或"我不控制预算" |
+| 时机 | 32% | "这不是当前的优先事项"或"我太忙了，无法接受另一个项目" |
+| 竞争 | 20% | "我需要证明为什么不选[替代方案]"或"我拿你做比价" |
+
+## 关键洞察
+- 异议是诊断信息，不是攻击
+- 预算异议几乎从来不是关于预算，而是关于价值是否超过成本
+
+## 关联实体
+- [[Sales Discovery Coach]]

wiki/concepts/AI生成技能.md

@@ -12,6 +12,4 @@ AI生成技能是 baoyu-skills 三大技能分类之一，专注于 AI 驱动的
 AI生成技能包括：baoyu-imagine（图像生成）、baoyu-danger-gemini-web（Gemini Web 交互）。
 
 ## Connections
-- [[baoyu-skills-claude-code-技能集]] ← includes → [[内容技能]]
-- [[baoyu-skills-claude-code-技能集]] ← includes → [[AI生成技能]]
-- [[baoyu-skills-claude-code-技能集]] ← includes → [[工具技能]]
+- [[baoyu-skills]] ← includes → [[AI生成技能]]

wiki/concepts/AWS-SES.md

@@ -0,0 +1,43 @@
+---
+title: "AWS SES"
+type: concept
+tags:
+  - AWS
+  - email
+  - service
+---
+
+## Aliases
+- SES
+- Simple Email Service
+- Amazon SES
+- Amazon Simple Email Service
+
+## Description
+AWS 提供的基于云的邮件发送服务，支持通过 API 或 SMTP 接口发送电子邮件。SES 提供可扩展的邮件发送能力，按发送量计费，是企业云端邮件发送的标准方案。
+
+## Key Features
+- SMTP 端点：支持标准 SMTP 协议，应用程序无需重构代码即可集成
+- API 端点：支持直接调用 SES API 发送邮件
+- 收件人验证：生产环境需申请脱离 Sandbox Mode
+- 域名验证：支持 DKIM、SPF、DMARC 验证
+- VPC 终端节点：通过 PrivateLink 私有访问，避免公网暴露
+
+## Use Cases
+- 应用通知邮件
+- 事务性邮件（订单确认、密码重置等）
+- 营销邮件
+- 批量邮件发送
+
+## Related Concepts
+- [[SMTP]]
+- [[DKIM]]
+- [[VPC Endpoint]]
+- [[Secrets Manager]]
+
+## Related Services
+- Amazon SNS：邮件通知的备选方案
+- Amazon Pinpoint：营销邮件服务
+
+## Sources
+- [[ctp-topic-12-using-ses-smtp-service-terraform-module]]

wiki/concepts/Access-Control.md

@@ -0,0 +1,26 @@
+---
+title: "Access Control"
+type: concept
+tags: [security, access-management]
+sources: [what-is-devsecops-best-practices-benefits-and-tools]
+last_updated: 2026-04-20
+---
+
+## Definition
+访问控制（Access Control）是管理谁可以访问系统、应用程序和数据的实践。在 DevSecOps 中，访问控制贯穿整个开发过程，确保只有授权人员能够访问敏感资源和进行特定操作。
+
+## Core Components
+- **身份认证（Authentication）**：验证用户身份
+- **授权（Authorization）**：确定用户权限
+- **审计（Audit）**：记录访问行为
+
+## Implementation in DevSecOps
+- 实施最小权限原则
+- 使用强身份验证方法（MFA）
+- 基于角色的访问控制（RBAC）
+- 自动化访问权限管理
+
+## Connections
+- [[DevSecOps]] ← requires ← [[Access Control]]
+- [[Zero-Trust-Architecture]] ← implements ← [[Access Control]]
+- [[Risk Management]] ← includes ← [[Access Control]]

wiki/concepts/Ad-Strength.md

@@ -0,0 +1,26 @@
+---
+title: "Ad Strength"
+type: concept
+tags: [Google Ads, Advertising, Quality Score]
+---
+
+## 定义
+广告质量评分（Ad Strength）是 Google Ads 评估响应式搜索广告（RSA）整体质量的指标，分为 Poor、Average、Good、Excellent 四个等级。
+
+## 评分维度
+- 相关性（Relevance）
+- 数量（Quantity）
+- 质量（Quality）
+
+## 优化目标
+- 90%+ 的 RSA 评级为"Good"或"Excellent"
+
+## 影响因素
+- 标题与关键词的相关性
+- 描述内容的完整性
+- 素材多样性
+- 行动号召明确性
+
+## 相关概念
+- [[Responsive Search Ads (RSA)]]
+- [[Paid Media Ad Creative Strategist]]

wiki/concepts/AgentDesignPrinciples.md

@@ -0,0 +1,24 @@
+---
+title: "Agent Design Principles"
+type: concept
+tags: [ai-agents, design]
+sources: [the-agency-contributing]
+last_updated: 2026-04-20
+---
+
+The Agency 项目定义的智能体设计六大核心原则，用于创建高质量、专业化的 AI 智能体。
+
+## Six Principles
+
+1. **Strong Personality** — 赋予智能体独特的声音和角色，非通用的"helpful assistant"
+2. **Clear Deliverables** — 提供具体的代码示例、模板和框架，展示真实输出
+3. **Success Metrics** — 包含具体可衡量的指标（如"页面加载时间低于 3 秒"）
+4. **Proven Workflows** — 经过真实场景验证的步骤流程，非理论推导
+5. **Learning Memory** — 智能体从成功模式、失败方法、用户反馈中学习
+6. **Real-world Testing** — 在真实场景中测试和迭代
+
+## Application
+
+- [[TheAgency]] 项目的所有贡献者应遵循这些原则创建新智能体
+- 评审新智能体时检查是否符合六大原则
+- 与 [[AgentFileStructure]] 结合使用

wiki/concepts/AgentFileStructure.md

@@ -0,0 +1,32 @@
+---
+title: "Agent File Structure"
+type: concept
+tags: [ai-agents, structure]
+sources: [the-agency-contributing]
+last_updated: 2026-04-20
+---
+
+The Agency 项目定义的智能体文件结构规范，区分 Persona（身份）与 Operations（操作）两大语义组。
+
+## Persona Group（身份相关）
+
+- **Identity & Memory** — 角色、个性、背景
+- **Communication Style** — 语调、声音、沟通方式
+- **Critical Rules** — 边界和约束
+
+## Operations Group（操作相关）
+
+- **Core Mission** — 主要职责
+- **Technical Deliverables** — 具体输出和模板
+- **Workflow Process** — 步骤化方法论
+- **Success Metrics** — 可衡量成果
+- **Advanced Capabilities** — 专业技巧
+
+## Purpose
+
+此结构支持 OpenClaw 工作区格式，并被 `convert.sh` 脚本用于自动拆分为特定工具格式。
+
+## Relation to
+
+- 由 [[AgentDesignPrinciples]] 定义的设计原则指导
+- 与 [[PersonaOperationsSplit]] 概念关联

wiki/concepts/Audience-Engineering.md

@@ -0,0 +1,26 @@
+---
+title: "Audience Engineering"
+type: concept
+tags: [advertising, audience, targeting, paid-media]
+last_updated: 2026-04-20
+---
+
+## Definition
+受众工程（Audience Engineering）是基于数据构建精准定向策略的过程，包括自定义受众创建、相似受众扩展和受众分层。
+
+## Key Techniques
+- **Pixel-based Custom Audiences**：基于网站 Pixel 的用户行为数据构建
+- **CRM List Uploads**：上传 CRM 客户列表进行定向
+- **Engagement Audiences**：基于互动行为（视频观看、页面访问、表单开启）的受众
+- **Exclusion Strategy**：排除已转化用户，避免浪费预算
+- **Audience Overlap Analysis**：分析跨平台受众重叠，避免频次超限
+
+## Audience Types
+- 自定义受众（Custom Audience）：基于种子用户的精确定向
+- 相似受众（Lookalike Audience）：基于种子用户扩展的相似受众
+- 兴趣定向受众（Interest Audience）：基于平台兴趣分类的泛定向
+
+## Connections
+- [[Audience Engineering]] ← requires ← [[Custom Audience]]
+- [[Audience Engineering]] ← extends ← [[Lookalike Audience]]
+- [[Full-Funnel Advertising]] ← uses ← [[Audience Engineering]]

wiki/concepts/Auto-Healing.md

@@ -0,0 +1,20 @@
+---
+title: "Auto Healing"
+type: concept
+tags: [deployment, reliability, self-recovery]
+sources: []
+last_updated: 2026-04-20
+---
+
+## Definition
+Auto Healing（自动修复）是云原生系统的核心能力，自动检测故障并恢复服务，无需人工干预即可恢复正常运行状态。
+
+## Rationale
+- 提高系统可用性
+- 减少人工干预
+- 缩短故障恢复时间
+
+## Related Concepts
+- [[ECS (Elastic Container Services)]]
+- [[Auto Scaling]]
+- [[Infrastructure as Code (IaC)]]

wiki/concepts/Brand-Foundation-Framework.md

@@ -0,0 +1,28 @@
+---
+title: "Brand Foundation Framework"
+type: concept
+tags: [brand-strategy, framework]
+date: 2026-04-20
+---
+
+## Concept Definition
+品牌基础框架是创建 cohesive brand identities 的系统性方法，包含品牌核心元素的完整定义。
+
+## Core Components
+1. **Brand Purpose（品牌使命）**：品牌存在的意义超越盈利的价值创造
+2. **Brand Vision（品牌愿景）**：品牌追求的未来状态
+3. **Brand Mission（品牌任务）**：品牌做什么、为谁做
+4. **Brand Values（品牌价值观）**：指导品牌行为的核心理念
+5. **Brand Personality（品牌个性）**：定义品牌特征的人类特质
+6. **Brand Promise（品牌承诺）**：对客户和利益相关方的承诺
+
+## Application
+- 先于战术实施建立全面的品牌基础
+- 确保所有品牌元素作为 cohesive system 协同工作
+- 在保护品牌完整性的同时允许创意表达
+- 连接品牌决策到业务目标和市场定位
+
+## Related Concepts
+- [[Visual-Identity-System]]：视觉识别系统
+- [[Brand-Voice]]：品牌声音与语调
+- [[Brand-Protection]]：品牌保护策略

wiki/concepts/CSS-设计系统.md

@@ -0,0 +1,29 @@
+---
+title: "CSS 设计系统"
+type: concept
+tags: [UX, CSS, 设计规范]
+---
+
+## 定义
+通过 CSS 变量（Custom Properties）定义颜色、字体、间距、布局的系统化方法，为项目提供一致性的视觉语言和可维护的样式基础。
+
+## 核心要素
+- **颜色变量**：语义化命名（--bg-primary, --text-primary, --accent-color）
+- **字体系统**：层级化字号（--text-xs 到 --text-3xl）
+- **间距系统**：基于 4px 网格的间距变量（--space-1 到 --space-16）
+- **布局系统**：容器尺寸（--container-sm 到 --container-xl）
+
+## 主题支持
+- Light Theme：浅色背景和深色文字
+- Dark Theme：深色背景和浅色文字
+- System Theme：通过 prefers-color-scheme 自动匹配系统偏好
+
+## 实践
+- 使用语义化命名而非具体颜色值
+- 建立设计 tokens 供组件复用
+- 通过 CSS 变量实现主题动态切换
+
+## 相关概念
+- [[主题切换]]
+- [[组件架构]]
+- [[响应式断点策略]]

wiki/concepts/Canary-Deployment.md

@@ -0,0 +1,19 @@
+---
+title: "Canary Deployment"
+type: concept
+tags: [deployment, release, strategy]
+sources: []
+last_updated: 2026-04-20
+---
+
+## Definition
+Canary Deployment（金丝雀部署）是一种软件发布策略，逐步将新版本替换为旧版本，通过小范围试点验证新功能的稳定性和可靠性，降低全量部署的风险。
+
+## Rationale
+- 降低新版本带来的风险
+- 实时监控新版本性能
+- 快速回滚能力
+
+## Related Concepts
+- [[ECS (Elastic Container Services)]]
+- [[Infrastructure as Code (IaC)]]

wiki/concepts/Clone-Faces.md

@@ -0,0 +1,24 @@
+---
+title: "Clone Faces"
+type: concept
+tags: [AI Generation, Bias, Image]
+date: 2026-04-20
+---
+
+## Definition
+AI 在生成多元群体图像或视频时，生成多个版本相同面孔的问题。这是基础图像模型（如 Midjourney、Sora、Runway）的系统性缺陷，需要通过显式约束防止。
+
+## Why It Happens
+- 模型的训练数据偏向特定面部特征
+- 缺乏对面部多样性的显式约束
+- 文本到图像的映射在处理"多样化群体"时产生重复
+
+## How to Counter
+- 明确要求不同的面部结构、年龄和体型
+- 使用负向提示如"no duplicate faces"、"no cloned faces"
+- 在提示词中指定 intersectional variance（交叉多样性）
+
+## Related Concepts
+- [[InclusiveVisualsSpecialist]] — 对抗此问题的专家角色
+- [[NegativePromptLibrary]] — 提供防止此问题的负向提示库
+- [[GibberishText]] — 类似的 AI 幻觉问题

wiki/concepts/Conversion-Tracking.md

@@ -0,0 +1,40 @@
+---
+title: "Conversion Tracking"
+type: concept
+tags: [Tracking, Measurement, Advertising, Analytics]
+---
+
+## Definition
+转化追踪是衡量广告投入产出比的核心机制，通过在用户完成目标行为时触发追踪代码，记录广告点击到最终转化之间的因果关系，为出价优化提供数据支撑。
+
+## Core Components
+- **Conversion Action**：广告平台中定义的具体转化目标（如购买、注册、表单提交）
+- **Conversion Value**：转化产生的价值（金额或自定义权重）
+- **Conversion Window**：归因时间窗口（点击后/展示后多少天内归因）
+- **Attribution Model**：归因模型（最终点击、首次点击、数据驱动等）
+
+## Platforms
+- **Google Ads**：转化操作、增强型转化、离线转化导入
+- **Meta**：Pixel、Conversions API (CAPI)
+- **LinkedIn**：Insight Tag
+- **TikTok**：Pixel
+
+## Key Metrics
+- **Conversion Rate**：转化率，转化数/点击数
+- **Cost per Conversion**：每次转化成本
+- **Conversion Value ROAS**：转化价值回报率
+
+## Best Practices
+- 追踪所有关键转化事件（购买、注册、Lead）
+- 设置微转化喂给算法学习
+- 交叉验证平台数据与 GA4 数据
+- 实施增强型转化提升匹配率
+
+## Related Concepts
+- [[Server-Side Tagging]]：服务端标记
+- [[GA4]]：Google Analytics 4
+- [[Attribution]]：归因模型
+
+## Related Entities
+- [[Paid Media Tracking & Measurement Specialist]]：转化追踪实施专家
+- [[Paid Media PPC Campaign Strategist]]：优化转化出价的智能体

wiki/concepts/Cross-account-Modules.md

@@ -0,0 +1,30 @@
+---
+title: "Cross-account Modules"
+type: concept
+tags: [terraform, multi-account, security]
+last_updated: 2026-04-20
+---
+
+## Definition
+- Cross-account Modules 指在一个 Terraform 模块中通过配置多个 Provider，实现在多个 AWS 账号中同时创建或管理资源的功能
+
+## Why Needed
+- 复杂云架构经常需要在一个模块内跨多个账号创建资源（例如在 InfoBlocks 账号配置 DNS，同时在 Workload 账号部署应用）
+
+## Security Concern
+- 直接赋予账号间互访权限存在巨大的安全风险，如某一账号被攻破可能波及全局（Blast Radius 问题）
+
+## Solution
+- 基于 Shared Account 的中心化部署方案，通过 Assume Role 方式访问目标账号，避免直接授予互访权限
+
+## Implementation Components
+- cross-account.json：标记文件，告知 Jenkins 该模块需要调用跨账号部署逻辑
+- ECS Deploy Runner：运行在 ECS 上的 Docker 容器，负责执行 Terraform plan 和 apply
+- TF state bucket accessor：专门定义的 IAM 角色，仅允许部署工具访问状态文件
+- Cross-account ECS deploy runner role：部署在目标账号中的角色，允许 Shared Account 的执行器切换角色获取权限
+
+## Connections
+- [[Terraform]] — 基础工具
+- [[Terragrunt]] — 配置管理
+- [[Shared Account]] — 信任源
+- [[ECS Deploy Runner]] — 执行单元

wiki/concepts/DKIM.md

@@ -0,0 +1,28 @@
+---
+title: "DKIM"
+type: concept
+tags:
+  - email
+  - security
+  - authentication
+---
+
+## Aliases
+- DKIM
+- DomainKeys Identified Mail
+
+## Description
+一种电子邮件验证标准，通过在邮件头部添加数字签名来验证发件人域名并确保邮件内容未被篡改。DKIM 是 SPF 和 DMARC 三大邮件验证标准之一。
+
+## How It Works
+1. 域名管理员在 DNS 中发布 DKIM 选择器记录（TXT 记录）
+2. 邮件服务器使用私钥对邮件内容进行加密签名
+3. 收件方服务器通过 DNS 获取公钥验证签名
+4. 签名验证通过表示邮件未被篡改且确实来自声称的域名
+
+## Related Concepts
+- [[SPF]]：发件人验证标准
+- [[DMARC]]：基于 SPF 和 DKIM 的邮件验证策略
+
+## Sources
+- [[ctp-topic-12-using-ses-smtp-service-terraform-module]]

wiki/concepts/DealStrategy.md

@@ -0,0 +1,36 @@
+---
+title: "Deal Strategy"
+type: concept
+tags: [sales, strategy, coaching]
+last_updated: 2026-04-20
+---
+
+## Summary
+- 定义：系统化准备和管理销售交易的策略框架
+- 包含：Deal Prep（交易准备）和 blameless debrief（无责复盘）
+
+## Deal Prep
+每次重要会议前准备：
+1. 目标是什么
+2. 买家需要听到什么
+3. 我们的诉求是什么
+4. 三个最可能的反对意见及处理方案
+
+## Blameless Debrief
+每次丢单后分析：
+- 资格问题（不该在）vs 执行问题（在但没做好）vs 竞争（在且做得好但对手更好）
+- 不同诊断对应不同 coaching 干预
+
+## Mutual Evaluation Plan
+- 与买家共同制定评估步骤、标准、时间线
+- 创建共同责任
+- 减少失联风险
+
+## Decision Process
+- 识别买家内部实际决策流程（通常不是买家最初描述的那样）
+- 识别关键决策者和影响者
+
+## Connections
+- [[Sales Coaching]]：通过交易策略进行 coaching
+- [[Sales Coach]]：实施 Deal Strategy 的 AI Agent
+- [[MEDDPICC]]：资格认证框架用于识别决策过程

wiki/concepts/Design-System.md

@@ -0,0 +1,28 @@
+---
+title: "Design System"
+type: concept
+tags: [UI Design, The Agency, Component Library]
+---
+
+## 定义
+一套完整的设计标准文档，包含设计令牌系统、组件库架构、响应式框架和可访问性标准，用于在产品生态系统中实现视觉一致性和用户体验统一。
+
+## 核心组成
+- **Design Token**：设计令牌系统，包含颜色、字体、间距、阴影、过渡等视觉变量
+- **Component Library**：组件库，包含按钮、表单、导航、反馈等基础组件
+- **Responsive Framework**：响应式框架，通过移动优先方法实现跨设备适配
+- **Accessibility Standards**：可访问性标准，包含 WCAG AA 合规要求
+
+## 设计原则
+- 设计系统优先方法论：在创建单个界面之前建立组件基础
+- 可访问性优先：默认包含 WCAG AA 最低标准
+- 响应式优先：移动优先方法实现跨设备体验
+- 开发者交接导向：提供精确的测量数据和资产文件
+
+## 典型应用
+- UI Designer 智能体使用设计系统创建完整的组件库架构
+- 开发者根据设计系统实现像素级界面
+- 设计师与开发者通过设计系统进行高效协作
+
+## 资源
+- [[UI Designer]]：设计系统的创造者和维护者

wiki/concepts/DevSecOps.md

@@ -3,7 +3,7 @@ title: "DevSecOps"
 type: concept
 tags: [devops, security, automation]
 sources: [cloud-devop-maturity-guideline, How-Agentic-AI-can-help-for-Cloud-DevOps, what-is-devsecops-best-practices-benefits-and-tools]
-last_updated: 2026-04-16
+last_updated: 2026-04-20
 ---
 
 ## Definition
@@ -14,14 +14,31 @@ DevSecOps 是将安全实践集成到 DevOps 流程中的方法论，强调通
 - **自动化安全**：将安全扫描集成到 CI/CD 流水线
 - **持续合规**：自动化合规性检查和报告
 - **主动漏洞管理**：持续扫描和修复漏洞
+- **安全右移（Shift Right）**：发布后持续安全监控
 
 ## Key Practices
 - 自动化 SAST（静态应用安全测试）
 - 自动化 DAST（动态应用安全测试）
 - 容器镜像安全扫描
--  secrets 管理
+- secrets 管理
+- 安全编码
+- 风险管理
+
+## Key Tools
+- SAST（静态应用安全测试）
+- SCA（软件成分分析）
+- IAST（交互式应用安全测试）
+- DAST（动态应用安全测试）
 
 ## Connections
-- [[DevOps 成熟度模型]] ← 安全维度 ← [[DevSecOps]]
-- [[CI/CD 流水线]] ← 集成 ← [[DevSecOps]]
-- [[监控可观测性]] ← 依赖 ← [[DevSecOps]]
+- [[DevOps]] ← extends ← [[DevSecOps]]
+- [[CI/CD 流水线]] ← embeds ← [[DevSecOps]]
+- [[SDLC]] ← integrates_with ← [[DevSecOps]]
+- [[Policy-as-Code]] ← implements ← [[DevSecOps]]
+- [[Shift Left]] ← is_a ← [[DevSecOps]]
+- [[Shift Right]] ← requires ← [[DevSecOps]]
+- [[Secure Coding]] ← enables ← [[DevSecOps]]
+- [[Risk Management]] ← includes ← [[DevSecOps]]
+- [[Access Control]] ← requires ← [[DevSecOps]]
+- [[Immutable Infrastructure]] ← enhances ← [[DevSecOps]]
+- [[监控可观测性]] ← depends_on ← [[DevSecOps]]

wiki/concepts/Easter-Egg.md

@@ -0,0 +1,26 @@
+---
+title: "Easter Egg"
+type: concept
+tags: []
+---
+
+## Definition
+彩蛋（Easter Egg）是隐藏的趣味元素，通过特定操作触发，为用户提供探索惊喜和社交分享素材。
+
+## Trigger Mechanisms
+- **Konami 代码**：↑↑↓↓←→←→BA 键盘序列触发彩虹模式
+- **点击序列**：5 次快速点击特定区域触发漂浮 Emoji
+- **悬停区域**：鼠标悬停特定元素触发渐变背景效果
+
+## Design Principles
+- 彩蛋不应影响核心功能或性能
+- 提供退出机制（如 10 秒后自动关闭）
+- 避免过度使用，每个产品 2-3 个为宜
+- 考虑无障碍需求，不依赖纯视觉反馈
+
+## Related Concepts
+- [[Whimsy Taxonomy]]
+- [[Micro-Interaction]]
+
+## Sources
+- [[design-whimsy-injector]]

wiki/concepts/Executive-Summary.md

@@ -0,0 +1,27 @@
+---
+title: "Executive Summary"
+type: concept
+tags: [Proposal, Sales, Strategy]
+last_updated: 2026-04-20
+---
+
+## Definition
+执行摘要是提案最关键的部分，许多评估者尤其是高级利益相关者只阅读此部分。它不是提案的总结，而是放在最前面的结束论证。
+
+## Structure
+1. **Mirror the buyer's situation**（2-3 句，证明你倾听并理解了他们的处境）
+2. **Introduce the central tension**—不行动的成本或错失的机会
+3. **Present your thesis**—你的方法如何解决这个矛盾（制胜主题在此出现）
+4. **Offer proof**—一个或两个具体证据点（指标、类似案例、差异化因素）
+5. **Close with the transformed state**—他们可以期望的具体结果
+
+## Key Principles
+- 保持在一页以内
+- 每一句都必须有其存在的价值
+- 从买家的语言出发，不是从你的解决方案出发
+- 制胜主题必须在此部分出现
+
+## Connections
+- [[Executive Summary]] ← critical_section_of ← [[Proposal Strategy]]
+- [[Executive Summary]] ← contains ← [[Win Theme]]
+- [[Executive Summary]] → leads_to → [[Three-Act Proposal Narrative]]

wiki/concepts/ForecastAccuracy.md

@@ -0,0 +1,29 @@
+---
+title: "Forecast Accuracy"
+type: concept
+tags: [sales, forecast, accuracy]
+last_updated: 2026-04-20
+---
+
+## Summary
+- 定义：销售预测与实际结果的符合程度
+- 目标：预测准确性应在承诺级别的 10% 以内
+
+## Commit Criteria
+- 基于可验证证据而非乐观主义
+- 问题不是"感觉如何"，而是"需要什么条件才能成交，能否展示这些条件已满足的证据"
+- 每个阶段应有明确的证据要求
+
+## Categories
+- **Upside**：通过努力可能成交
+- **Commit**：基于证据将会成交
+- **Closed**：已签约
+
+## Rep Patterns
+- 持续过度预测 → coaching 资格严谨性
+- 持续低于预测 → coaching 交易控制和信心
+
+## Connections
+- [[Sales Coaching]]：通过预测准确性进行 coaching
+- [[Sales Coach]]：实施预测准确性管理的 AI Agent
+- [[Pipeline Review]]：pipeline review 支持预测

wiki/concepts/Full-Funnel-Advertising.md

@@ -0,0 +1,30 @@
+---
+title: "Full-Funnel Advertising"
+type: concept
+tags: [advertising, paid-media, campaign]
+last_updated: 2026-04-20
+---
+
+## Definition
+全漏斗广告（Full-Funnel Advertising）是覆盖用户从认知到转化完整路径的广告策略架构，包括认知→参与→再营销→留存四个阶段。
+
+## Funnel Stages
+- **认知阶段（Awareness）**：触达广泛受众，建立品牌认知
+- **参与阶段（Engagement）**：互动行为（视频观看、页面访问、内容互动）
+- **再营销阶段（Retargeting）**：针对高意向用户促进转化
+- **留存阶段（Retention）**：已有客户维护，提升生命周期价值
+
+## Budget Distribution
+- 认知：20-30%
+- 参与：20-30%
+- 再营销：30-40%
+- 留存：10-20%
+
+## Platform Strategy
+- Meta: Advantage+ campaigns → 认知/再营销
+- LinkedIn: Sponsored Content → 认知/参与
+- TikTok: Spark Ads → 参与/再营销
+
+## Connections
+- [[Full-Funnel Advertising]] ← drives ← [[Paid Media Paid Social Strategist]]
+- [[Full-Funnel Advertising]] ← requires ← [[Audience Engineering]]

wiki/concepts/GA4-Implementation.md

@@ -0,0 +1,57 @@
+---
+title: "GA4 Implementation"
+type: concept
+tags: [Analytics, Google, Tracking, Measurement]
+---
+
+## Definition
+GA4（Google Analytics 4）是 Google 的新一代分析平台，基于事件驱动模型提供跨平台、跨设备的学生追踪能力，相比 UA 新增了用户级分析、机器学习预测和隐私优先设计。
+
+## Core Features
+- **Event-Based Model**：所有交互转换为事件（自动收集事件 + 自定义事件）
+- **Enhanced Measurement**：增强型测量，自动追踪滚动、站点搜索、外链点击、视频互动
+- **Custom Dimensions & Metrics**：自定义维度和指标
+- **Cross-Domain Tracking**：跨域追踪
+- **Ecommerce DataLayer**：电商数据层实现（view_item、add_to_cart、begin_checkout、purchase）
+
+## Key Events
+| Event | Description |
+|-------|-------------|
+| page_view | 页面浏览 |
+| view_item | 查看产品 |
+| add_to_cart | 添加到购物车 |
+| begin_checkout | 开始结账 |
+| purchase | 完成购买 |
+| sign_up | 注册 |
+| generate_lead | 生成 Lead |
+
+## Data Layer Implementation
+```javascript
+dataLayer.push({
+  event: 'purchase',
+  ecommerce: {
+    transaction_id: 'T12345',
+    value: 99.00,
+    currency: 'USD',
+    items: [{
+      item_id: 'SKU123',
+      item_name: 'Product Name',
+      price: 99.00,
+      quantity: 1
+    }]
+  }
+});
+```
+
+## Debug & Verification
+- **GA4 DebugView**：实时查看事件发送
+- **GTM Preview**：GTM 预览模式验证触发
+- **Network Inspection**：检查 gtag.js 请求参数
+
+## Related Concepts
+- [[Conversion Tracking]]：转化追踪
+- [[Server-Side Tagging]]：服务端标记
+- [[Consent Mode]]：同意模式
+
+## Related Entities
+- [[Paid Media Tracking & Measurement Specialist]]：GA4 实施专家

wiki/concepts/Gap-Selling.md

@@ -0,0 +1,42 @@
+---
+title: "Gap Selling"
+type: concept
+tags: [sales, methodology, discovery]
+---
+
+## 定义
+Keenan 提出的销售方法论，强调销售就是买家当前状态与期望未来状态之间的差距。差距越大，买家的紧迫感越强。
+
+## 核心框架
+
+### Current State Mapping（当前状态映射）
+```
+├── Environment（环境）：当前使用的工具、流程、团队结构
+├── Problems（问题）：什么是坏的、慢的、痛苦的或缺失的
+├── Impact（影响）：这些问题的可量化业务成本
+│   ├── Revenue impact（收入影响）：丢单、增长放缓、客户流失
+│   ├── Cost impact（成本影响）：浪费时间、工具冗余、人工工作
+│   ├── Risk impact（风险影响）：合规、安全、竞争暴露
+│   └── People impact（人员影响）：流失、倦怠、目标未达
+└── Root Cause（根本原因）：为什么存在这些问题（关键锚点）
+```
+
+### Future State（期望未来状态）
+- "解决"后的具体、可衡量目标是什么？
+- 哪些指标会改变，变化幅度多大？
+- 什么变得可能而现在不行？
+- 需要解决的 timeline 是什么？
+
+### The Gap（差距）
+- 当前状态与期望未来状态之间的距离有多大？
+- 停留在当前状态的代价是什么？
+- 达到未来状态的价值是什么？
+- 买家没有你能自己填补这个差距吗？
+
+## 关键洞察
+- 表面问题（"我们的工具慢"）不创造紧迫感
+- 根本原因（"我们使用无法扩展的传统架构，本季度要接入 3 个企业客户"）才创造紧迫感
+
+## 关联实体
+- [[Keenan]]：方法论创始人
+- [[Sales Discovery Coach]]

wiki/concepts/Gibberish-Text.md

@@ -0,0 +1,24 @@
+---
+title: "Gibberish Text"
+type: concept
+tags: [AI Generation, Bias, Cultural]
+date: 2026-04-20
+---
+
+## Definition
+AI 在尝试非英语脚本或文化符号时发明令人反感或无意义字符的问题。常见于生成中文、阿拉伯文、印地文等文字时，AI 会产生看似文字但实际无法识别的"符号"。
+
+## Why It Happens
+- 训练数据中非拉丁文字的representation不足
+- 模型缺乏对特定文字系统的深度理解
+- 文本渲染模块的幻觉
+
+## How to Counter
+- 显式负向提示任何生成的文本、标志或标牌
+- 使用"no text"、"no symbols"、"no signs"等约束
+- 后处理阶段使用 OCR 检测并替换为真实文字
+
+## Related Concepts
+- [[InclusiveVisualsSpecialist]] — 对抗此问题的专家角色
+- [[NegativePromptLibrary]] — 提供防止此问题的负向提示库
+- [[CloneFaces]] — 类似的 AI 幻觉问题

wiki/concepts/Immutable-Infrastructure.md

@@ -0,0 +1,27 @@
+---
+title: "Immutable Infrastructure"
+type: concept
+tags: [devops, security, infrastructure]
+sources: [what-is-devsecops-best-practices-benefits-and-tools]
+last_updated: 2026-04-20
+---
+
+## Definition
+不可变基础设施（Immutable Infrastructure）是一种基础设施管理范式，组件在部署后不会发生变化。如果需要更新或修复，会创建新版本并替换旧版本，而不是修改现有组件。
+
+## Core Principles
+- **不可变性**：部署后不修改现有组件
+- **幂等性**：每次部署产生相同结果
+- **版本化**：每个版本都可追溯和回滚
+- **自动化替换**：通过自动化工具完成组件替换
+
+## Benefits
+- 降低配置漂移风险
+- 提高环境一致性
+- 简化回滚操作
+- 增强安全性和可预测性
+
+## Connections
+- [[DevSecOps]] ← enables ← [[Immutable Infrastructure]]
+- [[IaC]] ← implements ← [[Immutable Infrastructure]]
+- [[容器化]] ← uses ← [[Immutable Infrastructure]]

wiki/concepts/Intent-Classification.md

@@ -0,0 +1,28 @@
+---
+title: "Intent Classification"
+type: concept
+tags: [Paid Media, Search Advertising, User Behavior]
+---
+
+## Definition
+将搜索查询映射到买家意图阶段的过程，用于确保广告展示给具有相应购买意向的用户。
+
+## Intent Stages
+- **Informational（信息型）**：用户处于研究阶段，尚未购买意图
+- **Navigational（导航型）**：用户寻找特定品牌或网站
+- **Commercial（商业型）**：用户正在比较选项，准备购买
+- **Transactional（交易型）**：用户准备完成购买或行动
+
+## Application
+- 匹配查询意图与落地页内容
+- 优化广告系列结构，按意图分层
+- 识别意图不匹配（query 与 landing page 脱节）
+- 评估查询-广告-落地页一致性（SQOS 评分）
+
+## Related Concepts
+- [[Search Term Analysis]]
+- [[Query Sculpting]]
+- [[Match Type Optimization]]
+
+## Related Entities
+- [[Search Query Analyst]]

wiki/concepts/Listener-Pattern.md

@@ -0,0 +1,24 @@
+---
+title: "Listener Pattern"
+type: concept
+tags: [ECS, architecture, centralized-management]
+sources: []
+last_updated: 2026-04-20
+---
+
+## Definition
+Listener Pattern（监听器模式）是一种集中管理 ECS 的架构方法，通过统一的监听器组件协调多个 ECS 服务的部署和流量管理。该模式解决了多个产品各自从 Gruntwork 下载代码并在本地使用的问题，实现集中化的 ECS 管理。
+
+## Rationale
+企业需要统一管理多个产品的容器化部署，Listener Pattern 提供了集中化的解决方案，便于：
+- 统一的流量管理
+- 配置复用
+- 跨产品的标准化部署
+
+## Related Concepts
+- [[ECS (Elastic Container Services)]]
+- [[Infrastructure as Code (IaC)]]
+- [[Terraform]]
+
+## Related Entities
+- [[Public Cloud Learning Sessions]]

wiki/concepts/MEDDPICC.md

@@ -0,0 +1,54 @@
+---
+title: "MEDDPICC"
+type: concept
+tags: [sales, qualification, methodology]
+last_updated: 2026-04-20
+---
+
+## Summary
+- 定义：销售资格认证框架，用于评估和验证交易机会的可行性
+- 全称：Metrics, Economic Buyer, Decision Criteria, Decision Process, Paper Process, Identify Pain, Champion, Competition
+- 目的：确保交易在进入销售漏斗前具备必要的验证元素
+
+## Components
+
+### Metrics（关键指标）
+- 客户期望达成的业务成果
+- 可量化的业务价值
+
+### Economic Buyer（经济决策者）
+- 有预算决策权的人
+- 能够批准购买决策的人
+
+### Decision Criteria（决策标准）
+- 客户用来评估供应商的标准
+- 采购决策的评分规则
+
+### Decision Process（决策流程）
+- 客户内部的采购审批流程
+- 各环节的参与者和时间节点
+
+### Paper Process（文件流程）
+- 合同谈判条款
+- 法务合规要求
+
+### Identify Pain（痛点识别）
+- 客户面临的具体业务问题
+- 问题的影响和紧迫性
+
+### Champion（ champion）
+- 内部支持者
+- 能够推动决策的人
+
+### Competition（竞争）
+- 竞争对手方案
+- 差异化价值主张
+
+## Usage
+- 作为诊断工具而非 checkbox
+- 当销售代表无法阐述经济决策者时，不是 CRM 问题而是交易风险
+- 资格差距是 coaching 机会
+
+## Connections
+- [[Sales Coaching]]：使用 MEDDPICC 进行资格验证 coaching
+- [[Sales Coach]]：实施框架的 AI Agent

wiki/concepts/Micro-Interaction.md

@@ -0,0 +1,27 @@
+---
+title: "Micro-Interaction"
+type: concept
+tags: []
+---
+
+## Definition
+微交互设计是指在用户与界面交互时产生的细小、专注的交互瞬间，通过视觉反馈、动画效果提升用户体验。
+
+## Examples
+- **按钮悬停效果**：光晕扫过、轻微上浮、阴影加深
+- **表单验证庆祝**：成功时显示 ✨ 闪烁动画
+- **加载动画**：带有个性的跳动圆点动画
+- **进度庆祝**：任务完成时显示 🎉 庆祝动画
+
+## Design Principles
+- 使用 cubic-bezier 缓动函数实现流畅动画
+- 保持动画时长在 0.3-0.5s 范围
+- 动画应服务于功能反馈而非纯粹装饰
+- 需支持 reduced-motion 偏好设置
+
+## Related Concepts
+- [[Whimsy Taxonomy]]
+- [[Easter Egg]]
+
+## Sources
+- [[design-whimsy-injector]]

wiki/concepts/Negative-Keyword-Architecture.md

@@ -0,0 +1,28 @@
+---
+title: "Negative Keyword Architecture"
+type: concept
+tags: [Paid Media, Search Advertising, Campaign Management]
+---
+
+## Definition
+分层否定关键词列表的系统化构建方法，用于阻止不相关搜索查询触发广告展示，是付费搜索账户优化的关键机制。
+
+## Tier Structure
+- **Account-Level**：整个账户通用
+- **Campaign-Level**：特定活动级别
+- **Ad Group-Level**：特定广告组级别
+- **Shared Negative Lists**：跨活动共享的否定列表
+
+## Best Practices
+- 定期审计和更新否定关键词列表
+- 检测否定关键词与正面关键词的冲突
+- 使用决策树结构（if query contains X AND Y, negative at level Z）
+- 按意图阶段分层管理（信息型查询通常需要否定）
+
+## Related Concepts
+- [[Search Term Analysis]]
+- [[Query Sculpting]]
+- [[Intent Classification]]
+
+## Related Entities
+- [[Search Query Analyst]]

wiki/concepts/Negative-Prompt-Library.md

@@ -0,0 +1,28 @@
+---
+title: "Negative Prompt Library"
+type: concept
+tags: [AI Generation, Prompt Engineering]
+date: 2026-04-20
+---
+
+## Definition
+针对图像和视频平台的显式负向提示库，用于阻止"AI 怪异感"（AI weirdness）并确保生成内容符合预期标准。
+
+## Key Categories
+- **克隆面孔约束**：no duplicate faces, no cloned faces, distinct facial structures
+- **文本约束**：no text, no symbols, no generated signs, no gibberish
+- **构图约束**：no hero-symbol composition, no oversized cultural symbols
+- **物理约束**：no extra fingers, no distorted hands, no unnatural lighting
+- **风格约束**：no stock photo tropes, no futuristic/sci-fi tropes, no generic smiles
+
+## Usage
+在提示词中添加负向约束需要使用平台特定的语法：
+- Midjourney：--no 参数
+- Stable Diffusion：negative prompt 字段
+- Sora/Runway：在提示词中明确排除
+
+## Related Concepts
+- [[InclusiveVisualsSpecialist]] — 使用此库的角色
+- [[CloneFaces]] — 此库解决的主要问题之一
+- [[GibberishText]] — 此库解决的主要问题之一
+- [[PhysicalRealityConstraints]] — 视频生成中的相关约束类型

wiki/concepts/Photography-Terminology.md

@@ -0,0 +1,31 @@
+---
+title: "Photography Terminology"
+type: concept
+tags: [photography, prompt-engineering, terminology]
+date: 2026-04-20
+---
+
+## Summary
+专业摄影术语是在 AI 图像生成提示词中准确描述摄影技术要素的规范术语集。
+
+## Definition
+Photography Terminology 是专业摄影知识在 AI 提示词工程中的应用，包括相机设置、灯光技术、构图原则等专业术语的精确使用。
+
+## Key Categories
+六大类别：
+1. **相机设置**：f/stop（光圈）、focal length（焦距）、shutter speed（快门速度）、ISO
+2. **景深控制**：shallow depth of field（浅景深）、deep focus（深焦）、bokeh（散景）、aperture
+3. **灯光方向**：front/side/back/top lighting、Rembrandt triangle、butterfly、split lighting
+4. **灯光质量**：hard/soft light、diffused、specular、volumetric、dramatic
+5. **构图术语**：rule of thirds、leading lines、framing、symmetry、negative space
+6. **色彩术语**：color temperature、color grading、color palette、warm/cool tones
+
+## Correct Usage Examples
+- ❌ "blurry background" → ✅ "shallow depth of field, f/1.8 bokeh"
+- ❌ "bright light" → ✅ "soft golden hour side lighting with gentle shadow gradation"
+- ❌ "close up" → ✅ "85mm focal length, eye-level perspective"
+
+## Connections
+- [[Prompt Engineering]] ← applies ← Photography Terminology：提示词工程应用摄影术语
+- [[Prompt Structure Framework]] ← incorporates ← Photography Terminology：提示词结构框架整合摄影术语
+- [[Image Prompt Engineer]] ← masters ← Photography Terminology：Image Prompt Engineer 掌握该术语

wiki/concepts/PipelineReview.md

@@ -0,0 +1,44 @@
+---
+title: "Pipeline Review"
+type: concept
+tags: [sales, pipeline, coaching]
+last_updated: 2026-04-20
+---
+
+## Summary
+- 定义：系统性审查销售 pipeline 的结构化流程，用于评估交易健康度和风险
+- 目标：将 pipeline 审查从审问式转变为 coaching 对话
+
+## Key Questions
+- "这交易什么时候关闭？" → "关于这笔交易我们不知道什么？"
+- "最有可能降低风险的下一个步骤是什么？"
+
+## Review Cadence
+
+### Weekly 1:1
+- 活动进展
+- 障碍
+- 习惯
+
+### Bi-weekly Pipeline Review
+- 交易健康度
+- 资格差距
+- 风险
+
+### Monthly/Quarterly Forecast
+- 模式识别
+- 预测准确性
+- 资源分配
+
+## Portfolio Patterns
+- 交易阶段分布：开场强但收盘弱？
+- 特定阶段卡顿？
+- 回避特定类型对话（定价、执行访问、竞争替换）？
+
+## Pipeline Quality vs Quantity
+- $2M 无资格交易 < $800K 每个交易都有验证商业案例 + 已识别经济买家
+
+## Connections
+- [[Sales Coaching]]：通过 pipeline review 进行 coaching
+- [[Sales Coach]]：实施 pipeline review 的 AI Agent
+- [[Forecast Accuracy]]：pipeline review 支持预测准确性

wiki/concepts/Prompt-Structure-Framework.md

@@ -0,0 +1,36 @@
+---
+title: "Prompt Structure Framework"
+type: concept
+tags: [prompt-engineering, ai-image-generation, framework]
+date: 2026-04-20
+---
+
+## Summary
+提示词结构框架是一种将视觉概念分解为分层组件的提示词设计方法论，用于生成专业级 AI 摄影作品。
+
+## Definition
+Prompt Structure Framework 是 Image Prompt Engineer 使用的分层提示词结构，将提示词分解为核心组件：主体描述层、环境与设置层、灯光规格层、技术摄影层、风格与美学层。
+
+## Key Components
+五个分层组件：
+1. **主体描述层**：主要焦点、属性、表情、姿态、材质、比例
+2. **环境与设置层**：位置类型、环境细节、背景处理、大气条件
+3. **灯光规格层**：光源、方向、质量、色温
+4. **技术摄影层**：相机视角、焦距、景深、曝光风格
+5. **风格与美学层**：摄影类型、时代风格、后期处理、参考摄影师
+
+## Application Patterns
+人像摄影模式：
+```
+[Subject] | [Pose] | [Background] | [Lighting: key, fill, rim, hair light] | [Camera: 85mm f/1.4] | [Style] | [Color palette] | [Reference]
+```
+
+产品摄影模式：
+```
+[Product] | [Surface] | [Lighting: softbox] | [Camera: angle] | [Hero shot/lifestyle] | [Brand aesthetic] | [Post-processing]
+```
+
+## Connections
+- [[Prompt Engineering]] ← defines ← Prompt Structure Framework：提示词结构框架是提示词工程的具体应用
+- [[Image Prompt Engineer]] ← uses ← Prompt Structure Framework：Image Prompt Engineer 使用该框架
+- [[Photography Terminology]] ← integrates_with ← Prompt Structure Framework：摄影术语集成于该框架

wiki/concepts/Proposal-Strategy.md

@@ -0,0 +1,35 @@
+---
+title: "Proposal Strategy"
+type: concept
+tags: [Proposal, Sales, Strategy]
+last_updated: 2026-04-20
+---
+
+## Definition
+提案策略（Proposal Strategy）是将 RFP 响应转化为说服性叙事的方法论，核心信念是"提案因清晰而赢，因通用而输"。它不仅仅是回答合规要求，而是构建一个统一的论点，说明为什么这个买家应该选择这个解决方案。
+
+## Core Components
+- [[Win Theme]] Development：开发 3-5 个制胜主题
+- [[Three-Act Proposal Narrative]]：三幕式提案叙事结构
+- [[Executive Summary]] Craft：执行摘要撰写
+- [[Competitive Positioning]]：竞争定位策略
+- Content Quality Standards：内容质量标准
+
+## Key Principles
+1. **Never write generic proposals**：如果买家名称、挑战和背景可以替换为另一个客户而不改变内容，提案就已经在失败
+2. **Win themes must be integrated**：制胜主题必须在执行摘要、解决方案、案例研究、定价中贯穿出现
+3. **No negative selling**：不要直接批评竞争对手，通过框架化优势创造有机对比
+4. **Compliance is floor, not ceiling**：合规是地板而非天花板，需在每个合规答案中添加战略背景
+5. **Pricing comes after value**：先建立 ROI 案例，再谈价格
+
+## Deliverables
+- Win Theme Matrix：制胜主题矩阵
+- Executive Summary Template：执行摘要模板
+- Proposal Architecture Blueprint：提案架构蓝图
+- Compliance Checklist + Strategic Overlay：合规清单与战略叠加
+
+## Connections
+- [[Proposal Strategy]] → uses → [[Win Theme]]
+- [[Proposal Strategy]] → uses → [[Three-Act Proposal Narrative]]
+- [[Proposal Strategy]] → uses → [[Executive Summary]]
+- [[Proposal Strategy]] → uses → [[Competitive Positioning]]

wiki/concepts/Pull-Request-流程.md

@@ -0,0 +1,19 @@
+---
+title: "Pull Request 流程"
+type: concept
+tags: [workflow, collaboration]
+---
+
+## 定义
+从提交前准备到 PR 审核的完整协作流程。
+
+## 流程阶段
+1. **提交前**：测试智能体、遵循模板、补充示例、定义指标、校对检查
+2. **提交 PR**：Fork 仓库、创建分支、完成修改、提交、推送、发起 PR
+3. **PR 审核**：社区评审 → 迭代优化 → 通过审核 → 合并上线
+
+## PR 模板要素
+- 智能体信息（名称、分类、专长）
+- 创作动机
+- 测试情况
+- 检查清单

wiki/concepts/Responsive-Search-Ads-RSA.md

@@ -0,0 +1,31 @@
+---
+title: "Responsive Search Ads (RSA)"
+type: concept
+tags: [Google Ads, PPC, Advertising]
+---
+
+## 定义
+响应式搜索广告（Responsive Search Ads，RSA）是 Google Ads 的一种高级搜索广告格式，允许广告主输入最多 15 个标题和 4 个描述，Google 算法会自动测试不同组合以找到最佳表现组合。
+
+## 关键特征
+- 最多 15 个标题字段
+- 最多 4 个描述字段
+- 算法自动组合测试
+- 机器学习优化展示
+
+## 架构策略
+- 品牌类标题
+- 利益类标题
+- 功能类标题
+- CTA 类标题
+- 社会证明类标题
+
+## 优化要点
+- 确保每个标题可以与任何其他标题组合
+- 包含关键词
+- 差异化信息传递
+- 明确行动号召
+
+## 相关概念
+- [[Ad Strength]]
+- [[Paid Media Ad Creative Strategist]]

wiki/concepts/Risk-Management.md

@@ -0,0 +1,27 @@
+---
+title: "Risk Management"
+type: concept
+tags: [security, devops]
+sources: [what-is-devsecops-best-practices-benefits-and-tools]
+last_updated: 2026-04-20
+---
+
+## Definition
+风险管理是识别、评估和缓解安全威胁的过程。在 DevSecOps 中，风险管理是优先事项，通过识别威胁和漏洞，组织可以实施控制措施来降低安全事件的风险并减少数据泄露的影响。
+
+## Core Practices
+- **风险识别**：识别系统和应用中的潜在威胁
+- **风险评估**：评估威胁的可能性和影响
+- **风险缓解**：实施控制措施降低风险
+- **持续监控**：持续监控风险状态
+
+## DevSecOps Integration
+- 在 SDLC 早期进行风险评估
+- 将风险评估集成到 CI/CD 流水线
+- 自动化风险扫描和报告
+- 定期更新风险矩阵
+
+## Connections
+- [[DevSecOps]] ← requires ← [[Risk Management]]
+- [[Compliance-Enforcement]] ← depends_on ← [[Risk Management]]
+- [[Policy-as-Code]] ← enforces ← [[Risk Management]]

wiki/concepts/SMTP.md

@@ -0,0 +1,42 @@
+---
+title: "SMTP"
+type: concept
+tags:
+  - email
+  - protocol
+  - networking
+---
+
+## Aliases
+- SMTP
+- Simple Mail Transfer Protocol
+- 简单邮件传输协议
+
+## Description
+用于发送和转发邮件的标准互联网协议。SMTP 是电子邮件发送的基础协议，大多数邮件服务器都支持 SMTP 接口。
+
+## How It Works
+1. MUA（邮件用户代理）通过 SMTP 将邮件提交给 MSA（邮件提交代理）
+2. MSA 将邮件传递给 MDA（邮件投递代理）
+3. MDA 将邮件投递到收件人邮件服务器
+4. 收件人通过 POP3/IMAP 获取邮件
+
+## Port Numbers
+- 25：标准 SMTP（非加密）
+- 465：SMTPS（SMTP over TLS）
+- 587：Mail Submission（邮件提交端口）
+- 2525：备选端口
+
+## AWS SES Integration
+- SES 提供 SMTP 端点，支持标准 SMTP 认证
+- IAM 用户凭证转换为 SMTP 用户名和密码
+- 支持通过 VPC 终端节点私有访问
+
+## Related Concepts
+- [[AWS SES]]
+- [[DKIM]]
+- [[SPF]]
+- [[DMARC]]
+
+## Sources
+- [[ctp-topic-12-using-ses-smtp-service-terraform-module]]

wiki/concepts/SPIN-Selling.md

@@ -0,0 +1,42 @@
+---
+title: "SPIN Selling"
+type: concept
+tags: [sales, methodology, discovery]
+---
+
+## 定义
+Neil Rackham 提出的四步提问销售方法论，通过特定问题序列帮助销售员深入了解买家情况并建立紧迫感。
+
+## 核心要素
+
+### Situation Questions（情境问题）
+- 目的：建立上下文
+- 使用限制：最多 2-3 个，可通过研究预先了解
+- 示例：
+  - "请介绍一下您的团队目前如何处理[流程]。"
+  - "您目前使用什么工具来完成[功能]。"
+
+### Problem Questions（问题问题）
+- 目的：揭示不满
+- 示例：
+  - "这个流程哪里会出问题？"
+  - "当[场景]发生时会发生什么？"
+  - "目前最让人沮丧的是什么？"
+
+### Implication Questions（暗示性问题）— **交易达成关键**
+- 目的：扩大痛苦，激活损失厌恶
+- 关键洞察：买家为避免损失比获取收益更努力
+- 示例：
+  - "当那个环节出问题后，对[相关团队/指标]的间接影响是什么？"
+  - "这如何影响您实现[战略目标]的能力？"
+  - "如果这种情况持续 6-12 个月，这会给您带来多大成本？"
+
+### Need-Payoff Questions（需求回报问题）
+- 目的：让买家自己描述价值
+- 示例：
+  - "如果能解决这个问题，您的团队会获得什么？"
+  - "这会如何改变您实现[目标]的能力？"
+
+## 关联实体
+- [[Neil Rackham]]：方法论创始人
+- [[Sales Discovery Coach]]

wiki/concepts/SalesCoaching.md

@@ -0,0 +1,56 @@
+---
+title: "Sales Coaching"
+type: concept
+tags: [sales, coaching, methodology]
+last_updated: 2026-04-20
+---
+
+## Summary
+- 定义：通过结构化提问和行为反馈提升销售代表技能的专业方法
+- 目标：实现可观察的、可重复的行为改变
+- 核心原则：coaching 技能而非态度，管理意愿而非行为
+
+## Key Components
+
+### Socratic 方法
+- Ask before telling：先问再做，而不是直接告知答案
+- "What would you do differently if you could replay that moment?"
+- 作用：引导销售代表自己发现问题而非被动接受指令
+
+### 区分技能差距 vs 意愿差距
+- **技能差距（Skill Gap）**：销售代表不知道如何做 → 通过 coaching 修复
+- **意愿差距（Will Gap）**：销售代表知道如何做但不去做 → 通过管理修复
+- 关键：不要混淆两者，否则 coaching 无效
+
+### 每次 Coaching 的最低要求
+- 至少产出一个具体的、可行为的、可操作的收获
+- 不是"改进发现"，而是"在下次对话中至少提出三个跟进问题后再展示方案"
+
+## Coaching 形式
+
+### Call Coaching
+- 回顾通话录音
+- 识别具体行为模式
+- 提供具体的行为反馈而非模糊建议
+
+### Pipeline Review
+- 每周 1:1：活动、障碍、习惯
+- 双周 pipeline：交易健康、资格差距、风险
+- 月度/季度：模式识别、准确性、资源分配
+
+### Deal Prep
+- 目标是什么
+- 买家需要听到什么
+- 我们的诉求是什么
+- 三个最可能的反对意见及处理方案
+
+## Connections
+- [[Sales Coach]]：实施 Sales Coaching 的 AI Agent
+- [[Sales Discovery Coach]]：专注于发现阶段的 coaching
+- [[MEDDPICC]]：资格认证框架
+
+## Related Concepts
+- [[Pipeline Review]]：pipeline 审查流程
+- [[Forecast Accuracy]]：预测准确性
+- [[Deal Strategy]]：交易策略
+- [[MEDDPICC]]：销售资格认证框架

wiki/concepts/Sandler-Pain-Funnel.md

@@ -0,0 +1,36 @@
+---
+title: "Sandler Pain Funnel"
+type: concept
+tags: [sales, methodology, discovery]
+---
+
+## 定义
+Sandler 销售系统中的痛点漏斗，从表面症状逐步深入到业务影响到个人/情感 stakes。
+
+## 三层漏斗结构
+
+### Level 1 — Surface Pain（表面痛点）
+技术/功能层面的问题症状
+- "跟我说说那个。"
+- "能举个例子吗？"
+- "这种情况持续多久了？"
+
+### Level 2 — Business Impact（业务影响）
+可量化的业务成本
+- "这给公司造成了多大损失？"
+- "这如何影响[收入/效率/风险]？"
+- "你们尝试过什么解决方案吗？为什么没成功？"
+
+### Level 3 — Personal/Emotional Stakes（个人/情感风险）
+**大多数销售员从未到达这一层**
+- "这对您和您的团队的日常有什么影响？"
+- "如果这个问题不解决，会发生什么？"
+- "如果这个问题一直不解决，对您个人有什么影响？"
+
+## 关键洞察
+- 购买决定是情绪化的决定，需要理性论证
+- VP 告诉你"我们需要更好的报表"的背后是"我 Q3 要向董事会汇报，我不信任我的数据"
+- 第二层才是驱动紧迫感的真正原因
+
+## 关联实体
+- [[Sales Discovery Coach]]

wiki/concepts/Search-Term-Analysis.md

@@ -0,0 +1,25 @@
+---
+title: "Search Term Analysis"
+type: concept
+tags: [Paid Media, Search Advertising, Data Analysis]
+---
+
+## Definition
+大规模搜索词报告挖掘、模式识别、N-gram 分析和查询意图聚类的技术过程，是付费搜索优化的核心数据分析活动。
+
+## Core Components
+- **Pattern Identification**：识别搜索词中的重复模式
+- **N-gram Analysis**：分析连续 N 个词的组合频率
+- **Query Clustering**：按意图或主题对查询进行分组
+- **Trend Analysis**：查询随时间的趋势变化
+
+## Application
+付费搜索广告账户中，用于识别高价值查询、发现新关键词机会、定位浪费支出。是 Search Query Analyst 智能体的核心能力之一。
+
+## Related Concepts
+- [[Negative Keyword Architecture]]
+- [[Intent Classification]]
+- [[Waste Identification]]
+
+## Related Entities
+- [[Search Query Analyst]]

wiki/concepts/Secure-Coding.md

@@ -0,0 +1,28 @@
+---
+title: "Secure Coding"
+type: concept
+tags: [security, development]
+sources: [what-is-devsecops-best-practices-benefits-and-tools]
+last_updated: 2026-04-20
+---
+
+## Definition
+安全编码（Secure Coding）是编写代码时遵循安全最佳实践的实践，旨在防止安全漏洞。它是 DevSecOps 的核心组成部分，通过在编码阶段就嵌入安全检查来实现"安全左移"。
+
+## Key Principles
+- **输入验证**：验证所有用户输入
+- **输出编码**：正确编码输出防止 XSS
+- **参数化查询**：使用参数化查询防止 SQL 注入
+- **最小权限**：遵循最小权限原则
+- **安全存储**：安全存储敏感信息
+
+## Best Practices
+- 遵循 OWASP 安全编码指南
+- 使用安全库和框架
+- 代码审查包含安全检查
+- 自动化安全测试集成到 IDE
+
+## Connections
+- [[DevSecOps]] ← implements ← [[Secure Coding]]
+- [[SAST]] ← validates ← [[Secure Coding]]
+- [[OWASP]] ← defines ← [[Secure Coding]]

wiki/concepts/Server-Side-Tagging.md

@@ -0,0 +1,34 @@
+---
+title: "Server-Side Tagging"
+type: concept
+tags: [Tracking, Measurement, GTM, Privacy]
+---
+
+## Definition
+服务端标记是一种将追踪标签从客户端（浏览器）转移到服务器端执行的追踪架构，通过 GTM Server-Side Container 实现第一方数据收集、Cookie 管理和数据富化。
+
+## Core Components
+- **GTM Server-Side Container**：部署在云函数或服务器上的标记容器
+- **First-Party Data Collection**：使用第一方域名收集数据，避免第三方 Cookie 限制
+- **Cookie Management**：服务端 Cookie 管理，提升数据持久性
+- **Server-Side Enrichment**：在服务端添加额外参数后再发送给第三方平台
+
+## Benefits
+- 提升数据准确性：绕过广告拦截器
+- 增强隐私合规：更好的同意模式控制
+- 改善页面性能：减少客户端 JavaScript 负担
+- 数据控制：数据先经过服务端处理再发送
+
+## Use Cases
+- 跨域追踪
+- 转化去重（CAPI 与 Pixel 事件匹配）
+- 增强型转化实施
+- 数据脱敏处理
+
+## Related Concepts
+- [[GTM]]：Google Tag Manager，标签管理平台
+- [[Conversion Tracking]]：转化追踪
+- [[Consent Mode]]：同意模式，隐私合规机制
+
+## Related Entities
+- [[Paid Media Tracking & Measurement Specialist]]：服务端标记实施专家

wiki/concepts/Shift-Right.md

@@ -0,0 +1,26 @@
+---
+title: "Shift Right"
+type: concept
+tags: [devops, security, testing]
+sources: [what-is-devsecops-best-practices-benefits-and-tools]
+last_updated: 2026-04-20
+---
+
+## Definition
+"Shift Right" 强调在应用发布后持续进行安全监控和测试。即使开发阶段进行了全面的安全测试，某些漏洞可能只有在上线后被用户使用时才会被发现。
+
+## Core Principles
+- **持续监控**：上线后持续监控系统安全状态
+- **生产环境测试**：在真实环境中发现测试环境无法覆盖的漏洞
+- **快速响应**：发现漏洞后快速修复并发布补丁
+- **用户反馈**：利用用户报告识别潜在安全问题
+
+## Relationship with Shift Left
+- Shift Left：在开发早期阶段融入安全测试
+- Shift Right：在发布后持续安全监控
+- 两者结合实现全生命周期安全保障
+
+## Connections
+- [[DevSecOps]] ← requires ← [[Shift Right]]
+- [[监控可观测性]] ← enables ← [[Shift Right]]
+- [[Shift Left]] ← complements ← [[Shift Right]]

wiki/concepts/Three-Act-Proposal-Narrative.md

@@ -0,0 +1,30 @@
+---
+title: "Three-Act Proposal Narrative"
+type: concept
+tags: [Proposal, Sales, Strategy, Narrative]
+last_updated: 2026-04-20
+---
+
+## Definition
+三幕式提案叙事是一种将提案转化为引人入胜的故事的结构化方法，遵循经典叙事弧线而非简单的合规检查表。
+
+## Three Acts
+
+### Act I — Understanding the Challenge（理解挑战）
+展示你比预期更了解买家的世界。反映他们的语言、约束和政治格局。这是建立信任的地方。大多数失败的提案完全跳过这一幕或用模板填充。
+
+### Act II — The Solution Journey（解决方案旅程）
+引导评估者体验你的方法，而不是一堆功能倾倒。每个能力都映射到第一幕中提出的挑战。方法论作为决策序列解释，而不是一面流程图墙。这是制胜主题最重的工作的地方。
+
+### Act III — The Transformed State（转型状态）
+描绘买家未来的具体画面。量化结果、时间线里程碑、风险降低指标。评估者应该读完这部分想到的是实施，而不是评估。
+
+## Key Principles
+- 每个提案需要一个清晰的叙事弧线，而非 checklist
+- 叙事 flow 必须贯穿所有 section
+- Act I 建立信任，Act II 展示方法，Act III 激发行动
+
+## Connections
+- [[Three-Act Proposal Narrative]] ← framework_of ← [[Proposal Strategy]]
+- [[Three-Act Proposal Narrative]] ← structured_by ← [[Win Theme]]
+- [[Three-Act Proposal Narrative]] → leads_to → [[Executive Summary]]

wiki/concepts/Usability-Testing.md

@@ -0,0 +1,33 @@
+---
+title: "Usability Testing"
+type: concept
+tags: [ux, testing, methodology]
+last_updated: 2026-04-20
+---
+
+## Definition
+可用性测试是评估产品易用性的方法，通过让真实用户执行任务来识别可用性问题。
+
+## Testing Methods
+- 实验室测试
+- 远程测试
+- 基准测试
+- 比较测试
+
+## Key Metrics
+- 任务完成率
+- 任务时间
+- 错误数量
+- 用户满意度评分
+- NPS
+
+## Process
+1. 定义测试目标和任务
+2. 招募参与者
+3. 进行测试 session
+4. 分析数据
+5. 生成报告和建议
+
+## Related Concepts
+- [[User Research]]
+- [[User Journey Mapping]]

wiki/concepts/User-Journey-Mapping.md

@@ -0,0 +1,29 @@
+---
+title: "User Journey Mapping"
+type: concept
+tags: [ux, journey, mapping]
+last_updated: 2026-04-20
+---
+
+## Definition
+用户旅程映射是可视化用户与产品交互全过程的系统化方法，识别关键触点、痛点和改进机会。
+
+## Components
+- 用户阶段
+- 触点
+- 行为
+- 情绪曲线
+- 痛点
+- 机会
+
+## Process
+1. 定义范围和目标
+2. 创建阶段划分
+3. 映射行为和触点
+4. 绘制情绪曲线
+5. 识别改进机会
+
+## Related Concepts
+- [[User Research]]
+- [[User Persona]]
+- [[Usability Testing]]

wiki/concepts/User-Persona.md

@@ -0,0 +1,27 @@
+---
+title: "User Persona"
+type: concept
+tags: [ux, persona, research]
+last_updated: 2026-04-20
+---
+
+## Definition
+用户画像是基于实证数据创建的理想用户原型，代表目标用户群体的特征、目标、需求和痛点。
+
+## Components
+- 人口统计学信息
+- 行为模式
+- 目标和需求
+- 痛点
+- 技术熟练度
+- 设备偏好
+
+## Creation Process
+1. 收集用户数据
+2. 识别模式
+3. 创建原型
+4. 验证和迭代
+
+## Related Concepts
+- [[User Research]]
+- [[User Journey Mapping]]

wiki/concepts/User-Research.md

@@ -0,0 +1,28 @@
+---
+title: "User Research"
+type: concept
+tags: [ux, research, methodology]
+last_updated: 2026-04-20
+---
+
+## Definition
+用户研究是通过定性定量方法理解用户行为、需求、动机和痛点的系统性过程。
+
+## Research Methods
+- 用户访谈
+- 问卷调查
+- 可用性测试
+- 行为数据分析
+- 竞品分析
+
+## Key Outputs
+- 用户画像
+- 用户旅程地图
+- 研究报告
+- 设计建议
+
+## Related Concepts
+- [[Usability Testing]]
+- [[User Persona]]
+- [[User Journey Mapping]]
+- [[Behavioral Analytics]]

wiki/concepts/VPC-Endpoint.md

@@ -0,0 +1,34 @@
+---
+title: "VPC Endpoint"
+type: concept
+tags:
+  - AWS
+  - networking
+  - security
+---
+
+## Aliases
+- VPC Endpoint
+- VPC 终端节点
+- PrivateLink
+- AWS PrivateLink
+
+## Description
+AWS 提供的私有网络连接服务，允许 VPC 中的资源安全地访问 AWS 服务而不经过公网。通过 VPC Endpoint，应用可以与 AWS 服务进行私有通信，确保数据不暴露在公网。
+
+## Endpoint Types
+- **接口终端节点（Interface Endpoint）**：通过 ENI（弹性网络接口）连接到 AWS 服务，支持 TCP 流量，适用于大多数 AWS 服务
+- **网关终端节点（Gateway Endpoint）**：通过路由表配置，适用于 S3 和 DynamoDB
+
+## Use Cases
+- SES SMTP 访问：通过 VPC Endpoint 实现私有邮件发送
+- Secrets Manager 访问：通过 VPC Endpoint 实现凭证私有访问
+- S3/DynamoDB 访问：使用网关终端节点
+
+## Security Benefits
+- 数据不经过公网，避免中间人攻击
+- 满足合规要求（数据不出公网）
+- 降低防火墙管理复杂度
+
+## Sources
+- [[ctp-topic-12-using-ses-smtp-service-terraform-module]]

wiki/concepts/Visual-Identity-System.md

@@ -0,0 +1,37 @@
+---
+title: "Visual Identity System"
+type: concept
+tags: [brand-strategy, design-system]
+date: 2026-04-20
+---
+
+## Concept Definition
+视觉识别系统是品牌视觉表达的标准化定义，确保跨所有应用的一致性和专业性。
+
+## Core Components
+1. **Logo System**：标志系统（horizontal、stacked、icon variants）
+2. **Color Palette**：色彩系统（primary、secondary、accent、neutral variations）
+3. **Typography**：字体系统（primary、secondary、accent、hierarchy）
+4. **Spacing System**：间距系统（xs、sm、md、lg、xl）
+5. **Pattern Library**：视觉元素模式库
+
+## Implementation Standards
+- 最小尺寸要求
+- 空白区域要求
+- 无障碍色彩对比（WCAG compliant）
+- Web 实现字体加载与 fallback
+
+## Design Variables Example
+```css
+:root {
+  --brand-primary: [hex-value];
+  --brand-secondary: [hex-value];
+  --brand-accent: [hex-value];
+  --brand-font-primary: '[font-name]', [fallbacks];
+}
+```
+
+## Related Concepts
+- [[Brand-Foundation-Framework]]：品牌基础框架
+- [[Brand-Voice]]：品牌声音
+- Brand Consistency：品牌一致性（95%+ 跨触点）

wiki/concepts/Whimsy-Taxonomy.md

@@ -0,0 +1,28 @@
+---
+title: "Whimsy Taxonomy"
+type: concept
+tags: []
+---
+
+## Definition
+品牌体验中趣味元素的分类体系，将趣味设计分为四个层次：微妙趣味、交互式趣味、发现式趣味、情境式趣味。
+
+## Categories
+- **Subtle Whimsy（微妙趣味）**：不干扰用户的轻量级趣味，如悬停效果、加载动画、按钮反馈
+- **Interactive Whimsy（交互式趣味）**：用户触发的愉悦交互，如点击动画、表单验证庆祝、进度奖励
+- **Discovery Whimsy（发现式趣味）**：隐藏元素奖励探索，如彩蛋、键盘快捷键、秘密功能
+- **Contextual Whimsy（情境式趣味）**：场景适配的幽默和趣味，如 404 页面、空状态、季节主题
+
+## Implementation Principles
+- 每个趣味元素必须服务功能或情感目的
+- 趣味设计必须包容无障碍（支持屏幕阅读器、减少运动偏好）
+- 品牌个性应贯穿全光谱（专业场景→休闲场景）
+- 趣味元素需性能优化，不能影响页面加载速度
+
+## Related Concepts
+- [[Micro-Interaction]]
+- [[Easter Egg]]
+- [[Gamification]]
+
+## Sources
+- [[design-whimsy-injector]]

wiki/concepts/Win-Theme.md

@@ -0,0 +1,31 @@
+---
+title: "Win Theme"
+type: concept
+tags: [Proposal, Sales, Strategy]
+last_updated: 2026-04-20
+---
+
+## Definition
+制胜主题（Win Theme）是连接解决方案与买家最紧迫需求的核心陈述，是提案叙事的骨架。每个提案需要 3-5 个制胜主题，必须在执行摘要、解决方案叙事、案例研究和定价说明中贯穿出现。
+
+## Core Principles
+- 命名买家的具体挑战，而非通用行业问题
+- 将具体能力与可衡量结果关联
+- 无需提及竞争对手即可实现差异化
+- 可通过证据、案例研究或方法论证明
+
+## Structure
+每个制胜主题包含：
+- **Buyer Need**：RFP 或发现阶段确定的特定挑战
+- **Our Differentiator**：能力、方法论或资产
+- **Proof Point**：指标、案例研究或证据
+- **Sections Where Appears**：主题出现的章节列表
+
+## Example
+- **Weak**: "We have deep experience in digital transformation"
+- **Strong**: "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"
+
+## Connections
+- [[Win Theme]] ← core_concept_of ← [[Proposal Strategy]]
+- [[Win Theme]] ← enables ← [[Competitive Positioning]]
+- [[Win Theme]] ← integrated_into ← [[Executive Summary]]

wiki/concepts/主题切换.md

@@ -0,0 +1,40 @@
+---
+title: "主题切换"
+type: concept
+tags: [UX, CSS, 用户体验]
+---
+
+## 定义
+支持用户选择浅色（Light）、深色（Dark）或跟随系统（System）偏好的界面主题管理机制。
+
+## 三种模式
+1. **Light Mode**：浅色背景配深色文字，适合明亮环境
+2. **Dark Mode**：深色背景配浅色文字，适合暗光环境
+3. **System Mode**：自动匹配操作系统偏好设置
+
+## 技术实现
+- 使用 CSS 变量存储主题色值
+- 通过 data-theme 属性切换主题
+- 使用 localStorage 持久化用户选择
+- 通过 prefers-color-scheme 媒体查询监听系统偏好
+
+## 实现示例
+```javascript
+class ThemeManager {
+  applyTheme(theme) {
+    if (theme === 'system') {
+      document.documentElement.removeAttribute('data-theme');
+      localStorage.removeItem('theme');
+    } else {
+      document.documentElement.setAttribute('data-theme', theme);
+      localStorage.setItem('theme', theme);
+    }
+  }
+}
+```
+
+## UX Architect 默认要求
+所有新站点必须包含主题切换功能，确保无障碍访问和用户个性化体验。
+
+## 相关概念
+- [[CSS 设计系统]]

wiki/concepts/内容技能.md

@@ -12,6 +12,7 @@ date: 2026-04-18
 内容技能包括：baoyu-xhs-images、baoyu-infographic、baoyu-cover-image、baoyu-slide-deck、baoyu-comic、baoyu-article-illustrator、baoyu-post-to-x、baoyu-post-to-wechat、baoyu-post-to-weibo。
 
 ## Connections
-- [[baoyu-skills-claude-code-技能集]] ← includes → [[内容技能]]
-- [[baoyu-skills-claude-code-技能集]] ← includes → [[AI生成技能]]
-- [[baoyu-skills-claude-code-技能集]] ← includes → [[工具技能]]
+- [[baoyu-skills]] ← includes → [[内容技能]]
+- [[baoyu-skills]] ← includes → [[AI生成技能]]
+- [[baoyu-skills]] ← includes → [[工具技能]]
+- [[内容技能]] ← uses → [[baoyu-imagine]]

wiki/concepts/可见度标准.md

@@ -0,0 +1,30 @@
+---
+title: "可见度标准"
+type: concept
+tags: [viewability, advertising, measurement]
+last_updated: 2026-04-20
+---
+
+## Definition
+可见度标准（Viewability Standard）是衡量数字广告是否真正被用户看到的指标。根据MRC（媒体收视率委员会）标准，展示广告需要在50%像素可见且持续1秒以上才被视为"可见"。
+
+## Industry Benchmarks
+- **标准阈值**：70%+ 可见展示（MRC标准）
+- **无效流量上限**：<3%（一般IVT），<1%（复杂IVT）
+- **CPM效率**：垂直基准的85%-115%
+
+## Measurement Framework
+- MRC定义的可见展示：50%像素可见≥1秒（展示广告）、50%像素可见≥2秒（视频广告）
+- 第三方验证：IAS、DoubleVerify、Moat
+- 品牌提升研究：衡量广告对品牌认知的影响
+
+## Optimization Tactics
+- 高可见度库存优先采购
+- 排除低可见度 Placement
+- 优化广告尺寸和格式
+- 时段和地域精细化控制
+
+## Connections
+- [[可见度标准]] ← validates ← [[展示广告]]
+- [[可见度标准]] ← monitors ← [[无效流量]]
+- [[ABM]] ← uses ← [[可见度标准]]

wiki/concepts/响应式断点策略.md

@@ -0,0 +1,30 @@
+---
+title: "响应式断点策略"
+type: concept
+tags: [UX, 响应式设计, 移动优先]
+---
+
+## 定义
+基于移动优先（Mobile First）的响应式设计方法论，通过定义多个屏幕宽度断点实现跨设备一致体验。
+
+## 断点标准
+- **Mobile**: 320px+（基础设计）
+- **Tablet**: 768px+
+- **Desktop**: 1024px+
+- **Large**: 1280px+
+
+## 核心原则
+1. 从小屏幕开始设计，逐步增强
+2. 使用 min-width 而非 max-width 媒体查询
+3. 确保触摸目标和内容可读性
+4. 考虑横屏和竖屏适配
+
+## 布局模式
+- **Hero Section**: 全视口高度，垂直居中
+- **Content Grid**: 桌面端双列，移动端单列
+- **Card Layout**: CSS Grid auto-fit，最小 300px 卡片
+- **Sidebar Layout**: 2fr 主内容 + 1fr 侧边栏
+
+## 相关概念
+- [[CSS 设计系统]]
+- [[组件架构]]

wiki/concepts/展示广告.md

@@ -0,0 +1,40 @@
+---
+title: "展示广告"
+type: concept
+tags: [display-advertising, programmatic, paid-media]
+last_updated: 2026-04-20
+---
+
+## Definition
+展示广告（Display Advertising）是在第三方网站、应用和社交媒体上以图片、视频、文本等形式呈现的视觉广告。与搜索广告不同，展示广告侧重于品牌建设和潜在客户获取，采用覆盖、频率、可见度等指标衡量效果。
+
+## Core Characteristics
+- **覆盖（Reach）**：触达的不同用户数量
+- **频率（Frequency）**：单个用户看到广告的平均次数
+- **可见度（Viewability）**：广告实际被用户看到的比例
+- **归因窗口**：转化窗口通常为90天（区别于搜索的即时转化）
+
+## Key Channels
+- Google Display Network（GDN）
+- 程序化购买（DSP）
+- 合作伙伴媒体（Newsletter、赞助内容）
+- ABM展示平台
+
+## Creatives
+- 标准IAB尺寸（300x250、728x90、160x600等）
+- 原生广告格式
+- 富媒体
+- 视频前贴/中贴
+- CTV/OTT广告
+
+## Success Metrics
+- 可见度率：70%+
+- 无效流量：<3%
+- 平均频率：3-7次/月
+- CTR（非重定向）：0.15%+
+- CTR（重定向）：0.5%+
+
+## Connections
+- [[展示广告]] ← uses ← [[程序化购买]]
+- [[展示广告]] ← implements ← [[ABM]]
+- [[展示广告]] ← measures ← [[可见度标准]]

wiki/concepts/工具技能.md

@@ -12,6 +12,4 @@ date: 2026-04-18
 工具技能包括：baoyu-youtube-transcript、baoyu-url-to-markdown、baoyu-danger-x-to-markdown、baoyu-compress-image、baoyu-format-markdown、baoyu-markdown-to-html、baoyu-translate。
 
 ## Connections
-- [[baoyu-skills-claude-code-技能集]] ← includes → [[内容技能]]
-- [[baoyu-skills-claude-code-技能集]] ← includes → [[AI生成技能]]
-- [[baoyu-skills-claude-code-技能集]] ← includes → [[工具技能]]
+- [[baoyu-skills]] ← includes → [[工具技能]]

wiki/concepts/数据可视化.md

@@ -0,0 +1,29 @@
+---
+title: "数据可视化"
+type: concept
+tags: [design, data, visualization]
+---
+
+## 定义
+将复杂数据、统计数据或定量信息转化为易于理解和解读的视觉形式（图表、图形、信息图表等）的技术和方法。
+
+## 核心原则
+- 数据故事化：通过叙事结构组织数据展示
+- 视觉层次：建立清晰的信息优先级
+- 叙事流：通过数据传达信息故事
+- 适当的可视化类型选择：根据数据类型选择合适的图表形式
+- 渐进式披露：分层展示信息帮助理解
+
+## 可视化类型
+- 柱状图/条形图：比较离散类别数据
+- 折线图：展示趋势变化
+- 饼图：展示比例关系
+- 散点图：展示相关性
+- 热力图：展示密度或强度
+- 信息图表：综合性的数据叙事
+
+## 最佳实践
+- 简化：去除不必要元素
+- 准确性：正确呈现数据比例
+- 可读性：确保标签和图例清晰
+- 一致性：保持风格统一

wiki/concepts/智能体设计原则.md

@@ -0,0 +1,31 @@
+---
+title: "智能体设计原则"
+type: concept
+tags: [ai-agents, design]
+---
+
+## 定义
+优秀智能体设计必须遵循的六大核心原则。
+
+## 六大原则
+1. **鲜明性格**：赋予智能体独特语气与人设，避免通用型"有用助手"人设
+2. **明确交付物**：提供可落地的代码示例、模板与框架，展示真实输出
+3. **成功指标**：包含具体、可量化的指标
+4. **经过验证的工作流**：分步流程清晰，经过真实场景验证
+5. **学习记忆**：智能体能识别模式，随时间迭代优化
+6. **真实场景测试**：在真实环境中测试迭代
+
+## 优秀智能体标准
+- 专精、深入的领域定位
+- 独特性格与语气
+- 具体的代码/模板示例
+- 可量化的成功指标
+- 分步工作流
+- 真实场景测试与迭代
+
+## 避免事项
+- 通用型"有用助手"人设
+- 模糊的"我会帮你……"描述
+- 无代码示例、无交付物
+- 范围过宽（样样通样样松）
+- 未经测试的理论方案

wiki/concepts/智能体设计规范.md

@@ -0,0 +1,22 @@
+---
+title: "智能体设计规范"
+type: concept
+tags: [ai-agents, design]
+---
+
+## 定义
+智能体文件结构、身份与记忆、核心使命、技术交付物、工作流程的完整定义规范。
+
+## 组成要素
+- **智能体文件结构**：YAML 元数据（name、description、color）
+- **身份与记忆**：角色、性格、经验、学习内容
+- **核心使命**：明确职责与交付物
+- **技术交付物**：代码示例、模板、框架、文档
+- **工作流程**：分步流程（探索→规划→执行→评审）
+
+## 设计原则
+- 鲜明性格
+- 明确交付物
+- 成功指标
+- 经过验证的工作流
+- 学习与记忆机制

wiki/concepts/程序化购买.md

@@ -0,0 +1,30 @@
+---
+title: "程序化购买"
+type: concept
+tags: [programmatic, advertising, dsp]
+last_updated: 2026-04-20
+---
+
+## Definition
+程序化购买（Programmatic Buying）是通过自动化技术实时采购数字广告库存的过程，无需人工谈判和手动操作。利用需求方平台（DSP）实现广告投放的自动化、实时竞价（RTB）和效果优化。
+
+## Core Components
+- **DSP（需求方平台）**：广告买家使用的技术平台
+- **SSP（供应方平台）**：出版商销售广告库存的平台
+- **AD Exchange**：连接DSP和SSP的广告交易平台
+- **RTB（实时竞价）**：每次展示时进行的实时竞拍
+
+## Key Platforms
+- DV360（Google）
+- The Trade Desk
+- Amazon DSP
+
+## Use Cases
+- 大规模展示广告投放
+- 跨渠道广告购买
+- 程序化 guaranteed deals（保量协议）
+- PMP（私有市场）
+
+## Connections
+- [[程序化购买]] ← uses ← [[DSP]]
+- [[DSP]] ← includes ← DV360, The Trade Desk, Amazon DSP

wiki/concepts/绩效最大化-Performance-Max.md

@@ -0,0 +1,41 @@
+---
+title: "绩效最大化 (Performance Max)"
+type: concept
+tags: [ppc, google-ads, campaign-type]
+---
+
+## 定义
+Performance Max（绩效最大化）是 Google Ads 的自动化全渠道投放类型，通过机器学习在全渠道（搜索、发现、YouTube、Gmail、Display）自动优化广告投放。
+
+## 核心特征
+- 全渠道自动化投放
+- 资产组（Asset Group）驱动投放
+- 信号（Signal）引导优化方向
+- 转化目标驱动的自动优化
+
+## 资产组设计
+- 图片素材、视频素材、文字标题、描述
+- 商家Logo与号召性用语
+- 受众信号与再营销受众
+
+## 信号优化
+- 第一方数据受众
+- 搜索主题信号
+- 兴趣类别信号
+- 人口统计信号
+
+## 适用场景
+- 规模化获取转化
+- 新产品/新市场推广
+- 跨渠道覆盖潜在客户
+- 预算有限但追求效率
+
+## 局限性
+- 缺乏搜索词控制
+- 归因透明度较低
+- 素材要求高
+
+## 与其他概念的关系
+- [[账户架构 (Account Architecture)]]：资产组是活动架构的核心组成
+- [[自动化出价策略]]：通常与 Max Conversions 或 Max Conversion Value 配合使用
+- [[Paid Media PPC Campaign Strategist]]：负责资产组设计与信号优化

wiki/concepts/自动化出价策略.md

@@ -0,0 +1,31 @@
+---
+title: "自动化出价策略"
+type: concept
+tags: [ppc, bidding, automation]
+---
+
+## 定义
+自动化出价策略是 PPC 广告平台提供的智能出价优化机制，通过机器学习算法自动调整出价以实现预设业务目标。
+
+## 出价策略类型
+- tCPA (Target CPA)：目标每次获取成本
+- tROAS (Target ROAS)：目标广告支出回报率
+- Max Conversions：最大化转化量
+- Max Conversion Value：最大化转化价值
+- 组合出价策略 (Portfolio Bid Strategy)：跨活动统一管理出价目标
+
+## 出价策略选择原则
+基于转化量与数据成熟度的动态评估：
+- 高转化量 + 充足历史数据 → 自动化出价
+- 低转化量 + 数据不足 → 手动出价过渡
+
+## 关键考量因素
+- 转化数据质量与数量
+- 账户历史表现
+- 季节性与业务周期
+- 竞争环境变化
+
+## 与其他概念的关系
+- [[账户架构 (Account Architecture)]]：提供结构化数据支撑出价优化
+- [[预算管理]]：与出价策略协同实现预算效率最大化
+- [[Paid Media PPC Campaign Strategist]]：自动化出价策略的选择与执行者

wiki/concepts/视觉叙事.md

@@ -0,0 +1,35 @@
+---
+title: "视觉叙事"
+type: concept
+tags: [design, storytelling, visual-communication]
+---
+
+## 定义
+通过视觉元素（图像、视频、动画、图形等）讲述故事的能力，核心是将信息转化为具有情感吸引力和叙事结构的视觉内容。
+
+## 组成要素
+- 故事弧结构：开端（Setup）、冲突（Conflict）、结局（Resolution）
+- 角色发展：识别主角（通常是用户/客户）
+- 问题识别：驱动叙事的挑战或问题
+- 解决方案设计：品牌/产品如何提供解决方案
+- 情感旅程映射：叙事过程中的情感高峰和低谷
+
+## 相关概念
+- [[数据可视化]]：将复杂数据转化为易理解的视觉形式
+- [[跨平台适配]]：根据不同平台特性调整视觉内容
+- [[品牌故事]]：围绕品牌价值的叙事
+- [[Visual Storyteller]]：执行视觉叙事的智能体
+
+## 应用领域
+- 视频内容
+- 动画与动效图形
+- 摄影艺术指导
+- 交互式媒体
+- 信息图表设计
+- 品牌叙事campaign
+
+## 成功指标
+- 视觉内容参与率
+- 故事完成率
+- 品牌认知提升度
+- 跨平台部署成功率

wiki/concepts/账户架构.md

@@ -0,0 +1,25 @@
+---
+title: "账户架构 (Account Architecture)"
+type: concept
+tags: [ppc, advertising, account-structure]
+---
+
+## 定义
+账户架构是 PPC 广告活动的组织结构设计，涵盖活动（Campaign）结构、广告组（Ad Group）分类、标签系统、命名规范等核心要素。
+
+## 核心要素
+- 活动结构设计：按业务目标划分活动层级
+- 广告组分类：按主题/产品/受众组织广告组
+- 标签系统：跨活动的分类与追踪机制
+- 命名规范：可读性强、易于规模化管理的命名规则
+
+## 分层活动架构
+- 品牌活动：保护品牌关键词，防御竞争对手
+- 非品牌活动：捕获品类搜索流量
+- 竞争对手活动：抢占竞争对手品牌关键词
+- 征服活动：主动攻击竞争对手的市场份额
+
+## 与其他概念的关系
+- [[自动化出价策略]]：基于账户架构的数据进行出价优化
+- [[绩效最大化 (Performance Max)]]：自动优化跨渠道投放
+- [[Paid Media PPC Campaign Strategist]]：账户架构设计的核心执行者

wiki/concepts/跨平台适配.md

@@ -0,0 +1,52 @@
+---
+title: "跨平台适配"
+type: concept
+tags: [design, strategy, multi-platform]
+---
+
+## 定义
+根据不同平台（Instagram、YouTube、TikTok、LinkedIn、Pinterest、网站等）的特性、用户行为和算法规则调整视觉内容的过程。
+
+## 平台特性
+
+### Instagram Stories
+- 垂直格式（9:16）
+-  Story格式叙事
+- 交互元素（投票、问答等）
+- 全屏沉浸式体验
+
+### YouTube
+- 水平视频（16:9）
+- 缩略图优化
+- 标题和描述支持
+- 长内容深度
+
+### TikTok
+- 短格式垂直视频
+- 趋势集成
+- 病毒式传播算法
+- 音乐/音效驱动
+
+### LinkedIn
+- 专业视觉内容
+- 信息图表格式
+- 品牌一致性
+- 文字比例较低
+
+### Pinterest
+- Pin优化垂直布局
+- 季节性内容
+- 图片质量要求高
+- 发现式浏览
+
+### 网站
+- 响应式设计
+- 交互式视觉元素
+- 加载性能
+- 可访问性
+
+## 核心策略
+- 统一品牌形象
+- 平台特定优化
+- 内容复用与调整
+- 技术规格适配